JP2019219782A - Service providing system and service providing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a service accompanied by target confirmation on SNS only by disclosing the minimum necessary personal information. A service providing system includes a personal terminal 71 including an SNS application unit 711 and an IMS application unit 712, an SNS side service providing unit 721 that provides a service to a user using an SNS platform, and an IMS. The service server 72 includes the target confirmation service unit 722 and the target confirmation service unit 722 that confirms the target of the user using the platform of the IMS application unit 712, and the IMS application unit 712 uses the function provided by the SNS platform to the target confirmation service unit 722. The SNS_ID acquired in the above steps and information that can identify the target confirmation result of the user are transmitted, and the target confirmation service unit 722 corresponds to the received SNS_ID and the target confirmation result of the user specified by the SNS_ID. Then, the service providing unit 721 on the SNS side is notified. [Selection diagram] FIG. 28

Description

  The present invention relates to a service providing system and a service providing method for providing a service to a user using personal information.

  In a service providing place, a service providing side (hereinafter referred to as a “vendor”) may provide a service after confirming whether the requesting user is the user himself or herself. For example, the vendor requests the requesting user to disclose personal information, and confirms whether or not the user is the user based on the disclosed personal information. Generally, confirming that a certain person is the person is called “personal identification” or “identity verification.” Personal information used for personal identification includes, for example, a license (More specifically, an information set included in the information set; the same applies hereinafter), an insurance card (more specifically, an information set included in the information set, the same applies hereinafter), and a passport (more specifically, an information set included therein. The same), a credit card (more specifically, an information set included in the information, the same applies hereinafter), biometric information, my number, etc. In some cases, two or more predetermined information such as a set of an ID and a password may be used. Combinations are also included in such personal information.

  Also, for example, the vendor requests the requesting user for user identification information and authentication information in order to confirm that the requesting user is an authorized user of the vendor, and the obtained information is registered in advance. By checking the information with the user, it is determined whether the user is a legitimate user of the vendor. Confirming that a person who has declared a particular user to a certain system is the particular user, that is, one legitimate user, is called "User authentication". Here, confirming that the user is a legitimate user means, more specifically, that the filer who has declared that the user is a specific user for a certain system is the same person as the specific user in the system or is equivalent to the same user. It is to confirm that you have the eligibility. Identity verification confirms that the filer is the filer, while user authentication only confirms that the filer can be considered the same as a pre-registered user. Although the required level is different, user authentication can be regarded as a type of identity verification in each system.

  Another case where personal information is used is “eligibility verification”, which confirms that the requester who requested the provision of a service is qualified to receive the service. . Here, the services include all services such as provision of goods and services regardless of whether they are paid or free.

  Hereinafter, performing at least one of identity verification, user authentication, and eligibility verification for a service requester using personal information is referred to as target verification. In other words, target verification is defined as a concept that includes identity verification, user authentication, and eligibility verification.

  Regarding such a technology of providing a service after confirming an object based on personal information, for example, Patent Document 1 discloses that a management device uses a face image taken by a product providing device such as a vending machine to allow a user to use a management device. There is described a product providing system capable of providing a product without authentication by performing authentication.

  Patent Document 2 discloses an identity authentication system that can identify an individual without using a dedicated card and a dedicated device such as an IC card and a reader thereof and without using an arbitrary ID set by the individual. I have. The personal authentication system described in Patent Literature 2 stores a terminal ID as information for identifying a user and information for authentication (such as a set of biometric information and position information) in advance in an authentication server in association with each other. In the information server, the terminal ID and the personal information of the user are stored in association with each other. Then, the terminal device holding the terminal ID transmits a command for requesting the user's personal information together with the verification information (biological information and position information) acquired by the terminal device to the information server via the reader / writer. I do. The information server analyzes the received command, compares the information for verification received from the terminal device with the information for authentication stored in the authentication server, performs user authentication, and then performs the personal authentication of the received user. Transmit the information to the terminal device.

  Non-Patent Document 1 discloses a personal authentication service using a personal information management system (Identity Management System: IMS) provided by ShoCard as one of systems for performing identity verification using a blockchain. ShoBadge ”is introduced. ShoCard also offers a personal authentication service application, "ShoCard," for personal devices. Hereinafter, regardless of the actual service name or application name, the IMS by ShoCard is referred to as “ShoCard”, and the platform and personal terminal application used in the IMS are referred to as “ShoCard platform” and “ShoCard APP”.

JP-A-2017-162191 JP-A-2017-102842

"SHOBADGE Secure Enterprise Identity Authentication Built Using the Blockchain (White paper)", [online], 2017, ShoCard Inc., [Search April 6, 2018], Internet <URL: https://shocard.com/shobadge / ＞

  The problem is that it is desired to perform services including target confirmation from an SNS (Social Networking Service) while ensuring the confidentiality of personal information.

  Generally, in IMS, personal information for each user is managed using an ID uniquely assigned to each user. For example, in the above-mentioned “ShoCard”, a request for disclosure of personal information of a user is made using a ShoCard ID assigned to each user when using a terminal application, and the identity of the disclosed information is verified by verifying the authenticity of the disclosed information. .

  On the other hand, the SNS basically does not require information other than the ID used in the SNS in order to enhance the anonymity of the individual, and cannot identify the user terminal using the service outside the SNS. Often it is.

  Therefore, in order to provide a service including target confirmation such as personal identification on the SNS, it is necessary to link the SNS with the IMS. When linking the SNS and the IMS, it is necessary to associate both the user ID of the SNS and the user ID on the IMS. However, there is no concrete method for linking the SNS with the IMS, and each system of the service provider has not been provided. Simply retained and used the information required to verify the identity required to provide the service.

  For example, in the methods described in Patent Literature 1 and Patent Literature 2, it is necessary to manage a set of ID and authentication information for each service or to perform a procedure for confirming an object. Therefore, in order to receive provision of various services, a user needs to manage IDs, authentication information, and information used for a procedure for confirming an object which are different for each service or vendor, which is complicated.

  In addition, each vendor has to maintain and manage the user's personal information by himself / herself, so that there is a problem that not only the risk of leakage but also the cost for information management including defense against attacks increases.

  It is also conceivable that the personal information of the user is not managed by the vendor, but is presented to the user each time a service is requested. However, this method requires the user to present information necessary for object confirmation each time object confirmation is performed, which is troublesome for the user. In addition, this method has to present the entire certificate, even if it is sufficient to present only a part of the certificate, such as a driver's license, for certifying the user in the target confirmation. For example, when there is no control, it is not possible to control such that only the minimum necessary information is disclosed for each purpose or purpose, and the protection of personal information is not sufficient.

  The present invention has been made in view of the above-described problems, and provides a service providing system and a service providing method capable of providing a service with target confirmation on an SNS with only necessary minimum disclosure of personal information. Aim.

  A service providing system according to the present invention includes a service server for providing a predetermined service, and a personal terminal used by a user to whom the service is provided, and the personal terminal uses a predetermined SNS by the user. An SNS application unit that provides various processes and interfaces for performing various processes and an interface, and an IMS application unit that provides various processes and interfaces for a user to use a predetermined IMS. The service server uses an SNS platform. Object confirmation for confirming the target of the user by exchanging information with the SNS side service providing unit that provides the service to the user by exchanging information with the SNS application unit and the IMS application unit using the IMS platform Service department and the IMS application The service unit provides the target confirmation service unit with information that the SNS-side service providing unit can identify the user on the SNS platform by using a predetermined method at least using the function provided by the SNS platform. A certain SNS_ID is transmitted together with information that can specify the result of the user's target confirmation, and the target confirmation service unit transmits the SNS_ID received from the IMS application unit and the result of the user's target confirmation specified by the SNS_ID. The SNS-side service providing unit is notified in association with the correspondence.

  Further, the service providing system according to the present invention includes a personal terminal used by a user, a service providing device for providing a predetermined service to the user, and a license issued by the service providing device and indicating a qualification for receiving the service. The personal terminal includes an SNS application unit that provides various processes and an interface for the user to use a predetermined SNS, The service providing device includes an IMS application unit that provides various processes and an interface for using the IMS. The service providing device provides an SNS that provides a service to a user by exchanging information with the SNS application unit using an SNS platform. Side service providing unit and IMS application using IMS platform The first object confirmation service unit for confirming the object of the user by exchanging information with the application unit, and the license judging device is an application for admission from the user or an application for receiving the profit obtained by the permit. Upon receiving the information, the second object confirmation service unit for confirming the object of the user by exchanging information with the IMS application unit using the IMS platform, and based on the result of the object confirmation by the second object confirmation unit. The IMS application unit obtains at least the first target confirmation service unit using at least a function provided from the SNS platform by a predetermined method. The SNS-side service providing unit uses the SNS_ID, which is information that can identify the user on the SNS platform, The first target confirmation service unit associates the SNS_ID received from the IMS application unit with the result of the target confirmation of the user identified by the SNS_ID, by transmitting the result of the user's target confirmation together with the identifiable information. To the SNS side service providing unit, and the SNS side service providing unit provides a service to the user based on the result of the user's target confirmation notified from the first target confirmation service unit. Two or more nodes constituting a block chain to which a new block is added through a process according to a predetermined consensus algorithm in which the above nodes participate, and personal information disclosed by a user to the block chain, Hash value of the target confirmation information, which is the personal information necessary for predetermined target confirmation, which is either identity verification, user authentication or eligibility verification A registration unit that registers the first block including the first block, and verifies the validity of the target confirmation information disclosed by the user using the blocks in the block chain, and performs the target confirmation based on the disclosed target confirmation information. An object confirmation unit, and a record registration unit for registering a second block including a record of object confirmation or service provision in the block chain, wherein the IMS application unit has a registration unit as a part of the IMS, Each of the first object confirmation service unit and the second object confirmation service unit has an object confirmation unit and a record registration unit as part of the IMS, and the IMS application unit uses the object confirmation unit and the block chain via the registration unit for the blockchain. The identifier of the user, the hash value of the first target confirmation information that is the biometric information disclosed by the user, and the predetermined personal information disclosed by the user. The first block including the hash value of the second object confirmation information is registered, and the first object confirmation service unit requests the user to disclose the second object confirmation information via the object confirmation unit. Then, the target confirmation is performed based on the obtained information, and the second target confirmation service unit provides the user with the information capable of specifying the second block and the information at the time of registration of the first block through the target confirmation unit. A request may be made to disclose the first target confirmation information and the current first target confirmation information, and a predetermined eligibility check including personal identification may be performed based on the disclosed information.

  A service providing method according to the present invention is a personal terminal used by a user to whom a service is provided, an SNS application unit that provides various processes and interfaces for the user to use a predetermined SNS, An IMS application unit provided in a personal terminal including an IMS application unit that provides various processes and an interface for a user to use a predetermined IMS is a service server that provides a service, and an SNS application using an SNS platform. Object confirmation service unit that confirms the target of the user by exchanging information with the SNS side service providing unit that provides the service to the user by exchanging information with the IMS application unit using the IMS platform Services with The SNS side service providing unit obtains information by the server's target confirmation service unit using at least a function provided by the SNS platform by a predetermined method, and is information that can identify a user on the SNS platform. The SNS_ID is transmitted together with information that can specify the result of the user's target confirmation, and the target confirmation service unit associates the SNS_ID received from the IMS application unit with the result of the user's target confirmation specified by the SNS_ID. In addition, the SNS side service providing unit is notified, and the SNS side service providing unit provides a service based on the result of the user's target confirmation notified from the target confirmation service unit.

  According to the present invention, it is possible to provide a service with target confirmation on the SNS only by disclosing the minimum necessary personal information.

FIG. 1 is a block diagram illustrating an example of a service providing system according to a first embodiment. FIG. 9 is an explanatory diagram showing an outline of a specific example of a first ID transfer method using LINE and ShoCard. FIG. 11 is a sequence diagram of a specific example of a first ID transfer method using LINE and ShoCard. FIG. 11 is an explanatory diagram showing an outline of a specific example of a second ID transfer method using LINE and ShoCard. FIG. 11 is a sequence diagram of a specific example of a second ID passing method using LINE and ShoCard. It is an explanatory view showing the outline of the example of the 3rd ID transfer method using LINE and ShoCard. It is a sequence diagram of a specific example of the third ID transfer method using LINE and ShoCard. It is an explanatory view showing an example of holding of various information in a personal information management system of a second embodiment. FIG. 11 is an explanatory diagram showing another example of a method for signing registration information in a registration block. FIG. 11 is an explanatory diagram showing another example of a method for signing registration information in a registration block. FIG. 9 is an explanatory diagram illustrating an example of a confirmation recording block. It is a lineblock diagram showing the main composition of the personal information management system of a 2nd embodiment. FIG. 3 is a block diagram illustrating a configuration example of a checking unit 202. 3 is a block diagram illustrating a configuration example of a ledger management node 301. FIG. It is a flowchart which shows an example of operation | movement in the registration phase of the personal information management system of 2nd Embodiment. It is a flowchart which shows the other example of operation | movement in the registration phase of the personal information management system of 2nd Embodiment. It is a flowchart which shows an example of operation | movement in the confirmation phase of the personal information management system of 2nd Embodiment. It is a flowchart which shows an example of operation | movement in the confirmation phase of the personal information management system of 2nd Embodiment. It is a flowchart which shows the example of an operation | movement of the confirmation institution side system in a confirmation phase. It is a schematic structure figure of the ticket service system of a 3rd embodiment. It is a flow chart which shows an outline of operation of a ticket service system of a 3rd embodiment. FIG. 14 is a sequence diagram illustrating an example of a flow of processing at the time of personal registration according to the third embodiment. It is a sequence figure (1) which shows an example of the flow of the processing at the time of the purchase application of a 3rd embodiment. It is a sequence figure (2) which shows an example of the flow of the processing at the time of the purchase application of a 3rd embodiment. It is a sequence diagram showing an example of the flow of processing at the time of entrance application of the third embodiment. It is a block diagram showing other examples of the ticket service system of a 3rd embodiment. FIG. 2 is a schematic block diagram illustrating a configuration example of a computer according to each embodiment of the present invention. It is a block diagram showing the outline of the service providing system of the present invention.

Embodiment 1 FIG.
Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram illustrating an example of a service providing system according to the first embodiment. The service providing system 600 shown in FIG. 1 includes a personal terminal 61, an SNS platform 62, an IMS platform 63, and a service server 64.

  The personal terminal 61 is a terminal used by an individual, and includes an SNS application unit (hereinafter, referred to as an SNSAPP unit) 611 and an IMS application unit (hereinafter, referred to as an IMSAPP unit) 612.

  The SNSAPP unit 611 provides the user of the personal terminal 61 with various processes and interfaces for using a predetermined SNS. The SSNSP unit 611 is, specifically, a processing unit serving as an operation subject of an application (SNSAPP) for an individual user of a predetermined SNS. The SSNSP unit 611 provides the user of the personal terminal 61 with an interface for using a predetermined SNS and performs various processes by operating the SSNSP on the personal terminal 61.

  Here, the predetermined SNS is not particularly limited. For example, “LINE” (registered trademark), “Ameba” (registered trademark), “Facebook” (registered trademark), “Google+” (registered trademark), “GREE” ( (Registered trademark), “Instagram” (registered trademark), “LinkedIn” (registered trademark), “mixi” (registered trademark), “skype” (registered trademark), “Twitter” (registered trademark), and the like.

  The IMSAPP unit 612 provides the user of the personal terminal 61 with various processes and interfaces for using a target confirmation service provided by a predetermined IMS. The IMSAPP unit 612 is, specifically, a processing unit serving as an operation subject of a predetermined IMS personal user application (IMSAPP). By operating the IMSAPP on the personal terminal 61, the IMSAPP unit 612 provides an interface for using a target confirmation service provided by a predetermined IMS to the user of the personal terminal 61 and performs various processes.

  Here, the predetermined IMS is not particularly limited, but may be, for example, the “ShoCard” described above or a personal information management system described later. It should be noted that the target confirmation service is not limited to the target confirmation service using a block chain as provided by these IMSs.

  The SSNSP and the IMSAPP are stored in the personal terminal 61 in advance, for example.

  The SNS platform 62 is a platform that provides a predetermined SNS. The SNS platform 62 is a part of a system that provides SNS, and includes, for example, functions for SNS users (for example, transmission / reception of a message using a user ID, a timeline function, a user mutual link function, a questionnaire function, and a user search function). , Community functions, etc.). The SNS platform 62 is specifically realized by hardware and software for realizing various functions in the SNS.

  The IMS platform 63 is a platform that provides a predetermined IMS. The IMS platform 63 is a part of a system that provides a target confirmation service such as management and collation of personal information. For example, a function for a user of the target confirmation service (for example, a target confirmation using a user ID, personal information for that purpose). Registration and collation functions). The IMS platform 63 is specifically realized by, for example, hardware and software for realizing various functions in the target confirmation service.

  The service server 64 is a server that performs processing for providing a predetermined service including target confirmation on the SNS. The service server 64 includes an SNS side service providing unit 641, a target confirmation service unit 642, and an ID cooperation information storage unit 643. Including.

  The SNS-side service providing unit 641 exchanges information with the SNSAPP unit 611 using the SNS platform 62 to provide a predetermined service with target confirmation on the SNS (more specifically, on the SNS platform 62). This is a processing unit. Note that the target confirmation is performed via a target confirmation service unit 642 described later.

  The target confirmation service unit 642 uses the IMS platform 63 to exchange information with the IMSAPP unit 612, and the SNS-side service providing unit 641 provides the information on the IMS (more specifically, on the IMS platform 63). For the user of the service, a target required for providing the service is confirmed.

  Further, the target confirmation service unit 642 has a function of notifying the SNS side service providing unit 641 of the result of the target confirmation. At this time, the target confirmation service unit 642 of the present embodiment uses the identifier (hereinafter, referred to as SNS_ID) by which the SNS-side service providing unit 641 can specify the user of the service providing destination of the present system on the SNS platform 62. Notify the result of target confirmation.

  The target confirmation service unit 642 according to the present embodiment includes, on the IMS platform 63, an IMS_ID which is an identifier capable of identifying a user to which a service of the present system is provided, and an SNS_ID corresponding to the IMS_ID (at least an SNS-side service providing unit). After acquiring the user (identifier capable of specifying the user) on the SNS platform 62, the 641 performs a predetermined target confirmation for the user specified by the IMS_ID.

  Note that the target confirmation service unit 642 is a process performed by the confirmation-side user application (confirmation-side IMSAPP) for the system including a function of requesting a designated user to perform target confirmation using the IMS platform 63. Part. That is, the target confirmation service unit 642 operates the confirmation-side IMSAPP on the service server 64 to acquire the IMS_ID and the SNS_ID for the user of the service provided by the SNS-side service provision unit 641 on the IMS. Check the target.

  The SNS_ID and the IMS_ID may be any information that can specify a corresponding user on a target platform in a processing unit using the ID. In other words, the SNS_ID may be any information that allows the SNS-side service providing unit 641 to identify the corresponding user on the SNS platform 62, and the IMS_ID is the information that the SNS-side service providing unit 641 specifies the corresponding user on the IMS platform 63. Any information may be used as long as the information can be specified. As an example, the SNS_ID is not only information that can identify a user who always applies on the target platform (such as a user ID that is always open on the target platform), but also a use that corresponds to the target platform such as a session ID. The information may be information that can identify the corresponding user by collating with information temporarily held by a server or the like during a session with the user.

  The ID cooperation information storage unit 643 stores, as necessary, ID cooperation information that is information in which the SNS_ID of the user to whom the service is provided and the IMS_ID are associated with each other.

  In the present embodiment, in order to enable the ID linkage between the IMS_ID and the SNS_ID in the service server 64, the SNS_ID of the corresponding user is transferred from the SNSAPP to the IMSAPP and from the IMSAPP to the target confirmation service unit 642. Specific methods of such ID transfer include, for example, the following three methods.

(First ID delivery method)
The first ID transfer method uses a response message to the personal terminal 61 for a message transmitted from an individual user who wants to use this service to the SNS side service providing unit 641 using SNSAPP, and This is done by activating IMSAPP on 61. Specifically, at the time of startup, the SNS_ID is notified to the IMSAPP as an SNS_ID of an ID capable of specifying a service providing user on the SNS platform, and the SNS_ID notified at the time of startup together with the IMS_ID assigned to itself from the IMSAPP. To the target confirmation service unit 642 corresponding to the operation subject of the confirmation IMSAPP on the service server 64.

  Many SNS platforms provide an API (Application Programming Interface) (hereinafter referred to as a message API) for exchanging (transmitting / receiving) messages between an individual user and an arbitrary server (so-called chatbot or the like). . By using such an API, an arbitrary message can be automatically transmitted to the transmission source user.

  Further, automatic startup of IMSAPP from the SNS side can be realized, for example, as follows. First, the SNS-side service providing unit 641 of the service server 64 uses a mechanism such as a webhook to transmit a POST request to a specified URL (Uniform Resource Locator) when a predetermined event occurs, and the message including the SNS_ID of the individual user. To be able to receive. Then, a custom URL scheme (also called a deep link) is embedded in the link of the Web page transmitted in the response sequence to the message reception.

  Not only can deep links be used to transition to a specific screen of an application, but if you define your own scheme, you can transition between applications, such as launching another application or passing information to that application. It can be carried out.

  In the first ID transfer method, the SNS-side service providing unit 641 of the service server 64 uses a message API on the SNS to transmit a message requesting the provision of this service to a personal user terminal (personal terminal). 61), a response message for this service is transmitted. At this time, a code for executing a predetermined inter-application cooperation function is embedded in the response message. Thus, when the user selects the execution of the function, the IMSAPP for the service can be automatically activated on the personal terminal 61. Further, at this time, the SNS_ID of the individual user is included in the startup parameter of the IMSAPP. This allows the IMSAPP unit 612 to acquire not only the IMS_ID of the individual user but also the SNS_ID.

  The IMSAPP unit 612, for example, under the permission of the user, sends the IMS_ID assigned to itself and the SNS_ID acquired at the time of application startup to the target confirmation service unit 642 of the service server 64 corresponding to the operation entity of the confirmation IMSAPP in the present system. Notify. It is assumed that the activated IMSAPP is an application in which such a notification function is implemented for the present service in advance, and knows the destination information of the notification destination. At the time of starting the IMSAPP, it is also possible to transfer information (URL or the like) of the service server 64 as destination information of the notification destination together with the SNS_ID. The notification of the IMS_ID and the SNS_ID from the IMSAPP unit 612 to the target confirmation service unit 642 can also be performed using the IMS platform 63.

  When notified of the IMS_ID and SNS_ID of the service requesting user from IMSAPP, the target confirmation service unit 642 stores them in the ID cooperation information storage unit 643 in association with each other, and then uses the IMS platform 63. The target confirmation sequence is started with the IMSAPP on the personal terminal 61 of the notification source, and the result of the target confirmation is received.

  The target confirmation sequence itself may be performed using an API or the like provided from the IMS platform 63. For example, the IMS platform 63 sends a target confirmation request specifying the IMS_ID to a user-side application (in this example, the target confirmation service unit 642 of the service server 64) that has the authority to request the target confirmation by a contract or the like in advance. Provide an API that accepts

  The IMS platform 63 receives, through such an API, a target confirmation request in which the IMS_ID to be the target of the target confirmation is specified. Upon receiving the target confirmation request, the IMS platform 63 transmits a message requesting disclosure of personal information necessary for target confirmation to the IMSAPP on the personal terminal 61 of the individual user specified by the designated IMS_ID. . Upon receiving a message requesting disclosure of personal information, the IMSAPP on the personal terminal 61 (corresponding to the IMSAPP unit 612 in this example) notifies the user of this. After that, IMSAPP transmits the requested personal information to the IMS platform 63 according to the user operation.

  The IMS platform 63 collates the personal information received from the IMSAPP with the personal information of the user owned by the IMS platform 63, etc., and confirms the target currently requested by the API to the user currently operating the IMSAPP. Do. The IMS platform 63 determines, for example, whether the user currently operating the IMSAPP is the user identified by the designated IMS_ID as a result of the verification, and whether the user satisfies a predetermined condition as necessary. Is determined, and the result is transmitted to the requesting confirming IMSAPP (the target confirmation service unit 642 of the service server 64).

  Upon receiving the result of the target confirmation for the individual user specified by the IMS_ID from the IMS platform 63, the target confirmation service unit 642 associates the result with the SNS side service providing unit 641 and associates the result with the IMS_ID in the ID linkage information storage unit 643. Notify with the attached SNS_ID.

  In addition, when the target confirmation is successful, the target confirmation service unit 642 embeds the custom URL scheme in a link of a Web page transmitted to the IMSAPP as a response message, thereby displaying the original service screen of the SNSAPP in response to a user operation. You may be able to return.

  2 and 3 show a specific example of the first ID transfer method. FIG. 2 is an explanatory diagram showing an outline of a specific example of the first ID transfer method, and FIG. 3 is a sequence diagram of this specific example. 2 and 3 show specific examples in which “LINE” is used as the SNS and “ShoCard” is used as the IMS.

  In this example, the delivery of the ID and the identification of the user of the service providing destination are performed as follows. In this example, the LINE Bot corresponds to the SNS-side service providing unit 641 and the LINE APP corresponds to the SNSAPP unit 611. The ShoCard APP corresponds to the IMSAPP unit 612, and the ShoCard service corresponds to the target confirmation service unit 642. In this example, the LINE Bot is an application created for this creation using, for example, the Messaging API or other SDK provided by the LINE platform. The ShoCard APP and the ShoCard service are, for example, applications created for this system using the ShoCard SDK provided by ShoCard. The LINE APP may be a general personal LINE application. The same applies to other examples.

-LINE Bot adds a rich menu for this system to the LINE APP of the user who sent the message to itself (1 to 4 in the figure). When the rich menu is selected, the ShoCard APP, which is an application for personal identification on the personal terminal, is changed to a userId (LINE platform used by the LINE platform) corresponding to the SNS_ID of the user (LINE APP on the terminal side in this case). This is a menu configured to transfer an internal identification ID (ID) and automatically start the same.
-When the rich menu is selected, the LINE APP automatically starts the ShoCard APP on the personal terminal according to the menu (5 in the figure).
The activated ShoCard APP acquires the userId as the activation parameter (6 in the figure).
The ShoCard APP that has acquired the userId notifies the user of the userId to the server-side ShoCard service together with its own ShoCardID (equivalent to IMS_ID) (7 in the figure).
-The ShoCard service notified of the ShoCardID and the userId stores them in a predetermined storage unit in association with each other (8 in the figure), and then starts the identity verification sequence from the server side (9 to 12 in the figure). ).
-When the identity verification sequence is completed, the ShoCard service notifies the LINE Bot of the confirmation result (14 in the figure), or stores the confirmation result in a predetermined storage unit and waits for an inquiry from the LINE Bot (Fig. 13, 14).

  As a method of automatically starting a specified application on a personal terminal, for example, a method of embedding a custom URL scheme in a Web service screen transiting from a rich menu can be cited.

  Next, data exchange in the present method will be described in more detail with reference to FIG. In the example shown in FIG. 3, first, the user operates the LINE APP on his / her own terminal to transmit a use start message to the LINE Bot via the LINE platform (steps S601 to S603).

  At this time, the webhook of the user's LINE message is acquired by the Messaging API, and a request is sent from the LINE platform to the webhook URL of the LINE Bot of the system specified by the destination. At this time, JSON data including a unique internal identification ID (userId) on the LINE platform is passed to the LINE Bot as information for identifying the transmission source user.

  Upon receiving the request related to the use start message, the LINE Bot transmits a predetermined HTTP response message to the LINE APP, and adds a menu for the present system to the rich menu and displays the menu (steps S604 and S605).

  When the user selects the menu, a request for a Web page is transmitted to a specific URL of the service server (steps S606 and S607). In this example, an example is shown in which the LINE Bot receives a request, but a method of implementing a process for the request is not particularly limited. For example, the ShoCard service may be accepted, or another service (such as a common Web server service on a service server) may be accepted.

  The service server that has received the request returns a Web page in which the custom URL scheme is embedded in the link as a response message (steps S608 and S609). The custom URL scheme is configured such that when a link is tapped, the ShoCard APP is activated on the personal terminal 61 and the userId is passed as an activation parameter.

  The LINE APP of the personal terminal 61 that has received the Web page from the service server displays the received Web page (Step S610).

  When the user taps the link displayed on the web page, the ShoCard APP is activated on the personal terminal 61 according to the custom URL scheme embedded in the link, and the userId is passed as an activation parameter (step S611). ).

  The ShoCard APP notifies the ShoCard service of the service server of the pair of the userId and the own ShoCardID received as the startup parameters (Step S612).

  When notified of the pair of the userId and the ShoCardID from the ShoCard APP, the ShoCard service of the service server stores them in a predetermined storage unit in association with each other (step S613), and starts an identity verification sequence (steps S614 to S614). Step S629).

  The identity confirmation sequence in the figure is an example of a case where the identity confirmation sequence is started from the service server side.

  First, the ShoCard service of the service server requests the ShoCard APP to disclose information for identity verification via the ShoCard platform (Steps S614 and S615). At this time, the message from the ShoCard service to the ShoCard platform includes "toShoCardID" which is an identifier for identifying the user to be confirmed on the ShoCard platform. On the other hand, the message sent from the ShoCard platform to the ShoCard APP includes senderShoCardID, which is a ShoCard ID for identifying the user who has requested confirmation on the ShoCard platform.

  Upon receiving a request for information disclosure for identity verification, the ShoCard APP performs identity verification by face authentication (steps S616 to S622). If the identity of the request from the server has been completed in the past, the process is omitted, and the information necessary for the identity verification held by the user is stored together with the information of the record on the ShoCard platform. It may be returned (step S623 to step S624).

  In step S616, for example, the face of the user is photographed using a camera device provided in the personal terminal 61, and a photograph of the face of the current user is acquired as personal information for personal identification.

  In steps S617 to S619, the acquired face photograph (or information based thereon) is used to collate with the information on the ShoCard platform, and the holder of the information (face photograph) is specified by the designated ShoCardID. Verify whether or not the user is the user and obtain the result.

  Steps S620 to S622 are processing for recording the result of the self-identification on the ShoCard platform.

  When the self-identification is completed in this way, the ShoCard APP transmits information necessary for identity verification (or object confirmation) in providing the service of the present system to the ShoCard service as necessary (step S623). , Step S624). The information is not particularly limited as long as a desired target can be confirmed by referring to the information on the provided side. For example, biometric information such as a face photograph may be used, personal information issued by a predetermined certification body such as a license image, or a service subscriber of the present system stored in advance on the ShoCard platform. Information (contractor identification ID, etc.) may be used. Alternatively, the identifier of the record of the result of the self-identification held in the ShoCard platform may be used.

  The ShoCard service uses the received information to check against the information on the ShoCard platform, and determines whether the sender of the information is the user identified by the specified ShoCard ID Is verified, and the result is obtained (steps S625 to S627). The processing in steps S625 to S627 is the same as that in steps S617 to S619.

  In addition, the ShoCard service transmits the result of confirming the disclosed information to the ShoCard APP that has transmitted the information (Steps S628 and S629). Although not shown, in the ShoCard service, for example, the result of the personal identification is stored in a predetermined storage unit together with the ShoCard ID so that it can be referred to when making an inquiry from the LINE Bot.

  The ShoCard APP may return the processing to the LINE APP from which it is activated, based on the result of the identity verification performed by itself and the server.

(Second ID delivery method)
The second ID transfer method uses a response message to the personal terminal 61 in response to a message transmitted to the SNS side service providing unit 641 using the SNSAPP, and activates the IMSAPP on the personal terminal 61 using the response message. Is the same as the first ID transfer method. In the second ID passing method, at the time of startup, the SNS platform service providing unit 641 includes, in the IMSAPP, the IMS_ID of the server as the notification destination of the result of the identification and the SNS_ID of the user of the service destination. A session ID capable of identifying the user is notified. Then, the personal identification sequence is started from IMSAPP which is an application on the terminal side, and the result is notified to the server side (the target confirmation service unit 642 of the service server 64) together with the session ID using the IMS_ID notified at the time of startup. . Upon receiving the result of the identity confirmation from the IMSAPP, the target confirmation service unit 642 notifies the SNS side service providing unit 641 together with the session ID.

  In the second delivery method, the service server 64 does not associate the IMS_ID of the user to which the service is provided with the SNS_ID, and does not hold the ID cooperation information.

  4 and 5 show specific examples of the first ID transfer method. FIG. 4 is an explanatory diagram showing an outline of a specific example of the first ID transfer method, and FIG. 5 is a sequence diagram of this specific example. Also in this example, "LINE" is used as SNS, and "ShoCard" is used as IMS.

In this example, the delivery of the ID and the identification of the user of the service providing destination are performed as follows.
-Until the ShoCard APP is activated by the custom URL scheme, it is the same as the first ID transfer method (1 to 4 in the figure).
・ However, when the ShoCard APP starts, the rich menu is configured to deliver the ShoCardID (senderShoCardID) on the server side and the sessionId assigned for exchanging messages with the service provider user on the SNS platform ( (3 in the figure: in the custom URL scheme).
When the rich menu is selected, the LINE APP automatically starts the ShoCard APP on the personal terminal 61 according to the menu (5 in the figure).
The activated ShoCard APP acquires the server-side ShoCardID and sessionId as startup parameters (6 in the figure).
-The ShoCard APP starts an identity verification sequence (7 in the figure). At this time, the ShoCard APP may disclose information for identity verification to the ShoCard service on the server side as necessary (8 in the figure).
-When the identity verification sequence is completed, the ShoCard APP notifies the confirmation result to senderShoCardID acquired at startup (9 in the figure). At this time, the sessionId acquired at startup is also notified.
-Upon receiving the identification result including the sessionId from the ShoCard APP, the ShoCard service notifies the LINE Bot of the identification result (11 in the figure). At this time, the ShoCard service may notify the LINE Bot after confirming that the confirmation record of the notified confirmation result is recorded on the ShoCard platform.

  Next, data exchange in the present method will be described in more detail with reference to FIG. In the example illustrated in FIG. 5, steps S601 to S611 are basically the same as the first ID transfer method, and thus description thereof will be omitted.

  In this example, it is assumed that the LINE Bot manages not only the userId but also the sessionId included in the JSON data as information for specifying the transmission source user.

  In this example, a custom URL scheme configured such that when a link is tapped in steps S608 and S609, the ShoCard APP is activated on the personal terminal 61 and the senderShoCardID and sessionId are passed as activation parameters. Reply the embedded web page as a response message.

  When the ShoCard APP is activated on the personal terminal 61 in step S611, the ShoCard APP starts an identity verification sequence (steps S614 to S629).

  The identity confirmation sequence in the figure is an example in the case where the identity confirmation sequence is started from the terminal side. The difference is that steps S614 and S615 are omitted, but it is basically the same as the identity verification sequence in the first ID transfer method.

  Also in this method, when the self-identification is completed, the ShoCard APP transmits, to the ShoCard service, information necessary for the identity confirmation in providing the service of the present system as needed (steps S623 and S624).

  The ShoCard service uses the received information to check against the information on the ShoCard platform, and determines whether the sender of the information is the user identified by the specified ShoCard ID Is verified, and the result is obtained (steps S625 to S627). In addition, the ShoCard service transmits the result of confirming the disclosed information to the ShoCard APP that has transmitted the information (Steps S628 and S629).

  In this way, the ShoCard APP, upon receiving the result of the identity verification on its own and the server side, notifies the result together with the sessionId to the senderShoCardID received as the startup parameter (Step S630).

  After that, the ShoCard APP may return the processing to the LINE APP that has started.

(Third ID delivery method)
In the third ID passing method, using the SNS login service provided by the SNS platform for other applications, IMSAPP obtains the SNS_ID of the user and sends it to the target confirmation service unit 642 together with its own IMS_ID. Notice.

  In this method, a user is logged in from IMSAPP to a predetermined SNS which is a place for providing services in the present system. By logging in to the SNS using the SNS login service, the user can know the SNS_ID (for example, the above-mentioned userId) used on the SNS platform. The IMSAPP may cause the user to log in to a predetermined SNS, for example, by outputting a message or the like prompting the user to log in to the SNS. Note that the timing of logging in from the IMSAPP to the SNS is not particularly limited. It is possible to start the use of the IMSAPP for this system, or to prompt the user to log in by transmitting a message to that effect each time the user requests a service from the SNS side service providing unit 641. is there.

  Upon acquiring the user's SNS_ID using the SNS login service, the IMSAPP notifies the target confirmation service unit 642 of the service server 64 together with the IMS_ID of the user. As the notification method, notification may be performed immediately after acquisition as in the first ID transfer method, or notification may be performed after completion of personal identification as in the second ID transfer method. The method of notification is not particularly limited.

  In addition, the target confirmation service unit 642 that has received the notification stores the received IMS_ID and SNS_ID in the ID cooperation information storage unit 643 in association with each other. Thus, in response to an inquiry about the identity confirmation from the SNS side service providing unit 641 specified by the SNS_ID, the result of the identity confirmation of the corresponding user can be returned.

  6 and 7 show specific examples of the third ID transfer method. FIG. 6 is an explanatory diagram showing an outline of a specific example of the third ID transfer method, and FIG. 7 is a sequence diagram of this specific example. Also in this example, "LINE" is used as SNS, and "ShoCard" is used as IMS. Note that FIG. 6A shows an outline of a process up to ID cooperation, and FIG. 6B shows an outline of a process after ID cooperation.

In this example, the delivery of the ID and the identification of the user of the service providing destination are performed as follows.
-When ShoCard APP is started by the user, the user is required to log in to LINE. The ShoCard APP performs LINE login using the LINE login service in response to a user operation, and obtains the userId of the user as a result (1 to 3 in the figure).
-After acquiring the userId, the ShoCard APP registers the personal information required for the service of this system according to the user's operation (4 in the figure), and then pairs the user's acquired ShodID with the ShoCard ID in the ShoCard service (5 in the figure).
When the ShoCard service is notified of the pair of the ShoCardID and the userId, they are stored in a predetermined storage unit in association with each other (6 in the figure).

-The LINE APP sends a message to the LINE Bot of this system in response to a user operation (7 in the figure).
-When the LINE Bot receives a message addressed to itself (8 in the figure), or after receiving the message, it specifies the userId of the user to the ShoCard service while exchanging messages with the LINE APP of the sender user Inquiry of the identity verification is performed (9 in the figure).
-The ShoCard service acquires the identity verification status of the user based on the ID linkage information stored in the predetermined storage unit in response to an inquiry from the LINE Bot (10 in the figure). At this time, if the personal identification has been completed, the fact is notified, and if not, the server starts the personal identification sequence (11 to 14 in the figure).
-When the identity verification sequence is completed, the ShoCard service notifies the LINE Bot of the confirmation result (15 in the figure).

  Next, data exchange in the present method will be described in more detail with reference to FIG. In the example shown in FIG. 7, first, the user activates the ShoCard APP on his / her own terminal and performs LINE login (step S641). The ShoCard APP acquires the userId as a login result (step S642).

  The ShoCard APP that has obtained the userId notifies the ShoCard service of a pair of its own ShoCardID and the obtained userId (step S643).

  When notified of the pair of the userId and the ShoCardID from the ShoCard APP, the ShoCard service stores them in a predetermined storage unit in association with each other (step S644), and starts an identity verification sequence specifying the notified ShoCardID. (Step S645). Note that the identity confirmation sequence may be the same as the identity confirmation sequence shown in FIG. The result of the personal identification at this time may be stored in a predetermined storage unit in association with at least the ShoCard ID.

  Next, the user operates the LINE APP on his / her own terminal to transmit a use start message to the LINE Bot via the LINE platform (steps S651 to S653).

  Upon receiving the request related to the use start message, the LINE Bot returns an OK to the LINE APP (step S654), and inquires of the ShoCard service for an identity verification specifying the userId (step S655).

  The ShoCard service that has received the inquiry about the identity verification checks whether or not the result of the identity verification is registered with reference to a predetermined storage unit (step S656). If the result is not registered, the ShoCard service uses the corresponding ShoCard ID. The personal identification sequence is started (step S657). Note that the identity confirmation sequence may be the same as the identity confirmation sequence shown in FIG.

  When the identity verification is completed, the ShoCard service notifies the LINE Bot of the result using the corresponding userId (step S658).

  The LINE Bot, upon receiving the identification result from the ShoCard service, transmits a response message to the LINE APP specified by the userId (Steps S659 to S661). The response message may be a message related to the provision of the service of the present system. The response message may be, for example, a message indicating a ticket reservation result when a ticket reservation is requested in step S651 or the subsequent exchange.

  Note that, in the above example, a method of delivering an ID when providing a service including identity verification to a user on an arbitrary SNS to which the service is provided has been described. The pre-processing may be, for example, user authentication or eligibility confirmation, or a combination thereof, in addition to identity verification.

  Further, in the specific example of the method of transferring the ID, an example in which “LINE” and “ShoCard” are used has been described, but the SNS and IMS to be used are not limited to these.

  As described above, according to the present embodiment, the target confirmation service unit 642 of the service server 64 can obtain the SNS_ID together with the IMS_ID of the service providing user. Can be linked. Since the user's IMS_ID and SNS_ID can be linked on the server that provides the service on the SNS, the service including target confirmation can be provided by simply requesting the minimum disclosure of personal information required for the service provision on the server. can do.

Embodiment 2. FIG.
In the following embodiment, a personal information management system that can be used as an IMS in a service providing system including the above-described SNS client cooperation will be described.

  First, the technical concept of the personal information management system according to the present invention will be briefly described.

  In the personal information management system according to the present invention, one personal ID is assigned as identification information for associating various personal information with a user. More specifically, various personal information used for object confirmation is securely managed in association with one personal ID assigned to each user. The personal ID is preferably associated with all the personal information owned by the user, but it is sufficient that the personal ID is associated with at least the personal information managed by the personal information management system provided by the present invention. Also in this case, the personal ID can be said to be one piece of identification information associated with various types of personal information used for object confirmation in the personal information management system, that is, an aggregated identification number.

  In the personal information management system according to the present invention, a block chain is used as a mechanism for managing personal information of a user. Here, the block chain is obtained by arranging a data group having a predetermined data structure called a block in a time-series manner, and has a role as a ledger in which transaction contents are described. Each block includes information of one or more previous blocks (hereinafter referred to as a previous block) and information for detecting the presence or absence of tampering (nonce, signature, etc.) in addition to data to be recorded in the block such as transaction details. And The nonce is a value in a certain data area, which is set so that a value obtained when processing data in the area by the one-way function satisfies a predetermined rule. . A new block is added to the block chain through processing according to a predetermined consensus algorithm in which two or more nodes participate. For example, in PoW (Proof of Work), which is one of consensus algorithms, for each block (data group) including the information of the previous block and the nonce, “the Hash value of the block is equal to or less than the threshold value (target value). A rule such as "thing" is predetermined, and when a block is added, a process in which a plurality of nodes search for a nonce that satisfies such a rule simultaneously and in parallel is performed. There is a consensus algorithm such as BFT (Byzantine fault tolerance) other than PoW.

  However, the hash value of the personal information is recorded in the blockchain in association with the hash value of the personal ID without recording the personal information as it is. At this time, a signature of the person who created the hash value (creating source) is attached to the hash value. The signature is, for example, a signature of the person who owns the personal information, or a signature of a third party (hereinafter, referred to as a confirmation organization) that has confirmed that the personal information is correct (Correctness). As the signature, a digital signature obtained by encrypting the information to be signed (in this case, a hash value) with the signer's private key can be used. By attaching the signature of the creator to the hash value, the reliability (reliability) of the hash value, more specifically, the hash value is created by the signer himself (certification of the creator) and the signature The side referencing the hash value can confirm that the hash value has not been falsified (non-falsification proof). By performing such hash value creator proof and non-tampering proof, the information whose hash value, which is registered information, is reliable, that is, the information possessed by the authorized owner or the confirmation authority checks the validity. It is possible to confirm from the signature that the information is created from the obtained information. Note that it is also possible to perform encryption instead of the process of adding a signature.

  Note that the reliability of the information (hash value and the signature attached to the hash value) registered in the block chain itself is ensured by the difficulty of falsification of the block chain.

  On the other hand, the personal information, which is the original data of the hash value, is held in a secure environment so as to be hidden from anyone other than the person. For example, the personal information may be stored in a secure area in a device owned by the user (hereinafter, referred to as a client device), or may be encrypted and stored in a distributed file server. The user can control whether to freely disclose personal information placed in such a secure environment, and if so, which personal information to disclose.

  In the personal information management system according to the present invention, in a block chain that can be referred to by a third party, personal information of a user associated with the personal ID (personal ID that is the original data of the hash value of the personal ID in the block) By storing only the information indicating the correctness of the personal information, confidentiality of the personal information is secured. Also, at this time, the identification information for identifying the owner of the personal information is combined into one, so that the procedure for confirming the target, which has been different for each application, is designated by one identification information (personal ID). That can be performed by unified processing.

  Further, in the personal information management system according to the present invention, when the target confirmation is performed using the hash value of the personal information of the user stored in the block chain, the block indicating the record of the confirmation is stored in the block chain. To be added. In this way, by leaving a record of the confirmation record in the blockchain, the result of the past target confirmation can be used for the target confirmation of the same purpose without disclosing specific personal information. For example, for a user whose target has been confirmed for the same purpose in the past, even if the user is not required to disclose the personal information, the user is compared with the information in the blockchain using the hash value of the personal information. Alone, it is possible to give a result similar to the result of the past object confirmation. This minimizes disclosure of personal information.

  In the personal information management system according to the present invention, a personal ID is used as information for linking a user and personal information, but the personal ID is a unique device such as a mobile phone, an IC card, and an authentication device. Since it is not managed in association with each other, even if a device or the like is lost, recovery can be performed without rewriting registered information.

  Next, an embodiment of the personal information management system according to the present invention will be described while presenting a specific system configuration.

  FIG. 8 is an explanatory diagram illustrating an example of holding various types of information in the personal information management system according to the second embodiment. FIG. 8 shows the client device 1 owned by the user, the confirmation institution device 2 owned by the confirmation institution, and the blockchain 3.

  In FIG. 8, the client device 1 holds a key pair (a secret key 11D and a public key 12D) for the signature of the user and a personal ID 13D assigned to the user from the personal information management system. In the client device 1, the personal ID 13D is associated with one or more personal information 14D.

  Further, the confirmation authority device 2 holds a key pair (a secret key 21D and a public key 22D) for signature of the confirmation authority.

  The block chain 3 holds the following registered blocks and confirmation recording blocks.

  For example, when a certain individual starts using the personal information management system, a personal ID 13D is assigned to the individual as a user, and a key pair for signature (a secret key 11D and a public key 12D) is generated. When the personal ID 13D is allocated and the key pair is generated, the user operates the client device 1 to obtain the hash value of the personal ID 13D and the personal information 14D to be registered (particularly, personal information used for object confirmation). A hash value is calculated, a personal information management block including them is created, and added to the block chain.

  FIG. 8 illustrates a block n−1 as an example of a registered block added to the block chain 3. The registration block includes a personal ID_Hash31D (corresponding to the hash value of the personal ID 13D), personal information Hash32D (corresponding to the hash value of the personal information 14D), and a signature 33D of the person who created them. It is. Here, the signature 33D of the principal is a signature for indicating that the personal ID_Hash31D and the personal information Hash32D included in the block are created by the user who is the authorized owner of the original data.

  The personal information Hash32D is preferably calculated for each unit in which the user who owns the personal information discloses the personal information (see FIG. 9A). At this time, it is also possible to add a signature 33D of the person to each piece of personal information Hash32D (see FIG. 9B). FIG. 9 is an explanatory diagram showing another example of a method for signing registration information in a registration block. In FIG. 9, the dotted line represents the signature target data of the signature 33D of the person.

  When there are a plurality of pieces of personal information to be registered, the user can add the hash values to the block chain 3 as separate registered blocks. In any case, in the registration block, the personal ID_Hash31D of the user and the personal information Hash32D may be associated with the signature of the creator. Note that the personal ID can also be regarded as one of the personal information. In this case, the registration block includes the hash values of two or more personal information of the personal ID and the other personal information together with the signature of the creator. It should just be.

  Although not shown, each block may include, in addition to the above, information indicating the public key of the signature creation source, the type of the block, the type of each registered information, and the like.

  In addition, each block constituting the block chain 3 has control information required for the block to constitute a part of the block chain, such as a hash value of a previous block, a signature of a person who added the block, and the like. Etc. are included. These pieces of control information are determined by the specifications of the block chain to be used.

  Hereinafter, a case where a license is registered as personal information will be described as an example. The license contains multiple pieces of personal information such as name, address, face photo, date of birth, license number, and expiration date, but the user has taken the entire license as personal information used for target confirmation A license image may be used. In this case, a registration block including the hash value of the license image as personal information Hash32D is registered in the blockchain 3. Note that the license image itself, which is personal information, may be held in the secure area of the client device 1 or may be divided / encrypted and held in the distributed file system.

  When registering a license as personal information, besides making the whole license into one image, you can also divide the license into units you want to control disclosure and make multiple partial images, or set the unit you want to control disclosure For each unit, only that part is processed to make it identifiable to make a plurality of processed images. If information that can be input as text (address, date of birth, name, etc.) is converted to data by text input, etc., these are combined as appropriate May be registered as personal information. In this case, the license image (entire), the partial image, the processed image, and the text data can be stored as different types of personal information.

  For example, when the user wants to register an image (partial image or processed image described above) in which only the area on which the date of birth of the license is described can be registered as the date of birth, which is one of the personal information. Calculates the hash value of the user's personal ID and the hash value of the date of birth data, puts each of them or them together into one, and applies the signature of the user, and adds the signature of the user. A registered block in which the registered hash value is registered may be added to the block chain 3.

  Next, a case will be described in which a user is confirmed using information registered in the blockchain 3. The confirmation institution device 2 of the confirmation institution that wants to perform the object confirmation acquires the personal ID 13D and the personal information 14D (hereinafter, referred to as first personal information) used for the object confirmation from the client device 1 of the user to be confirmed. . Then, the confirmation institution device 2 acquires a registration block in which the hash value of the first personal information is registered in association with the hash value of the personal ID 13D. The registration block may be obtained by searching the block chain 3 using the hash value calculated from the personal ID 13D and the hash value calculated from the first personal information as keys, or a user as described later. May be obtained by obtaining a hash value or the like of the registered block obtained from the block registration history or the like held by the server and searching the block chain 3 using the hash value as a key. It suffices if the search can be performed based on at least information published in the blockchain 3. When the corresponding registration block is searched, the confirmation institution device 2 determines that the information (personal ID_Hash31D or personal information Hash32D) registered in the registration block is the user itself (in this case, the disclosing person who disclosed the personal information). ), And that the information has not been tampered with since the signature (non-tampering proof), the signature 33D of the person attached to the information and the public key 12D of the user who is the signer. Confirm using (Confirmation of registration information reliability). Further, the confirmation institution device 2 collates the personal information Hash32D in the searched registration block with the hash value calculated from the first personal information acquired from the user (conformity check of the original data). Note that the matching of the original data is omitted when the registered block is searched using the hash value calculated from the first personal information as a key.

  When these two confirmation results are both OK, the confirmation institution device 2 converts the first personal information obtained from the disclosing person into the personal information 14D of the user himself indicated by the personal ID 13D obtained from the disclosing person. Is determined, and based on the disclosed first personal information, the confirmation institution performs necessary object confirmation (identification, user authentication, and eligibility confirmation).

  As an example, suppose that the confirmation institution device 2 performs the age confirmation of the service requesting user as a condition of eligibility for service. In this case, the confirmation institution device 2 sends the personal ID 13D and the date of birth data (for example, a partial image of a license image, a processed image, or text data) as the first personal information to the client device 1 of the user. May be required to be disclosed. Note that the date of birth data used as the first personal information is the one whose at least its hash value is registered in the registration block together with the hash value calculated from the user's personal ID 13D, that is, the personal information in the registration block. It is assumed that the data is Hash32D original data.

  Upon obtaining these pieces of information, the confirmation institution device 2 acquires a registration block in which the hash value of the disclosed date of birth data of the user indicated by the disclosed personal ID 13D is registered. Upon acquiring the registration block, the confirmation institution device 2 creates the hash value (personal information Hash32D) of the date of birth data included in the registration block and the signature 33D of the individual attached to the individual ID_Hash31D (the user himself / herself). Decryption using the public key 12D, and confirming the reliability of the obtained decrypted data (the hash value to be signed) (confirming the reliability of the registration information). Here, the public key of the creator may be the one in the block, or the public key of the disclosing person who disclosed the first personal information as the user may be used.

  The verification institution device 2 checks the personal information Hash32D included in the registration block, if necessary, with a hash value created from the date of birth disclosed by the user, and determines whether the two match. Check (conformity check of original data). As described above, the consistency check of the original data is replaced by the search process when the registered block is searched using the hash value calculated from the disclosed personal information as a key (the search process is performed). Blocks match the original data).

  If both the confirmation of the reliability of the registration information and the confirmation of the consistency of the original data are OK, the confirmation institution device 2 discloses that the disclosed date of birth is the user identified by the disclosed personal ID. The age is confirmed based on the date of birth as the correct personal information of the disclosing person. As a result, the confirmation institution device 2 may provide, for example, an age-restricted service. In this manner, the confirmation institution device 2 obtains only the personal ID 13D and the date of birth from the service request source, and determines whether the date of birth is the date of birth of the disclosing person. It is possible to perform target confirmation (age confirmation) on the basis of the disclosed date of birth data without having to perform the identity verification itself.

  Further, when the confirmation authority device 2 performs the target confirmation using the information in the block chain 3, the confirmation authority device 2 registers a confirmation record block indicating the record of the confirmation in the block chain 3.

  FIG. 8 shows a block n or a block n + 1 as an example of the confirmation recording block added to the block chain 3. The confirmation record block includes at least a personal ID_Hash 31D (corresponding to a hash value calculated from the personal ID 13D disclosed by the user) and a signature 35D of a confirmation organization that created the personal ID_Hash 31D. Note that, as shown as a block n, the confirmation recording block may further include confirmation information 34D.

  Here, the confirmation information 34D may include, for example, information on the confirmation institution (confirmation institution ID or the like) or information indicating confirmation items. By registering such confirmation information 34D, it is possible to eliminate the need to perform redundant processing when performing target confirmation for the same purpose. For example, the information of the confirmation institution may be, for example, a confirmation institution ID for identifying the confirmation institution. In addition, the confirmation items include, for example, information on the block used for the target confirmation (hash value and type of the personal information used for the target confirmation are known), and a result of the target confirmation (variables performed during the target confirmation). And the type of service provided as a result of the target confirmation, the type of eligibility required by the service, and the like.

  If such a confirmation record block is included in the blockchain 3, the confirmation institution will thereafter enter the personal ID disclosed by the user without disclosing specific personal information (for example, date of birth data). Based on the hash values of the personal information, the user can be given a confirmation result equivalent to the confirmation result indicated by the confirmation information 34D of the past confirmation recording block specified from the hash values. In addition, the user can prevent unnecessary disclosure of personal information.

  In the case of the above example, without disclosing the date of birth data, it is necessary to determine the type of service previously given to the user from the personal ID of the user and the hash value of the date of birth data. Service and eligibility equivalent to the type of eligibility described above can be given to the user. Note that, for example, when the purpose of use and the institution used are limited, it is possible to identify what kind of personal information was used and what kind of object confirmation was performed for the user from the signature 35D of the confirmation institution. Can provide the same result of the target confirmation to the user without the confirmation information 34D. Even in this case, it is assumed that the reliability of the registration information of the confirmation record block, which is the confirmation record of the user, is confirmed based on the signature.

  It is to be noted that the client device 1 of the user wants to hold the key information (the hash value of the block, etc.) in the block chain 3 of the block in which the information (at least the personal ID_Hash31D) of the user is recorded as a registration history, and use it when confirming the target. It is also possible to specify the key information of the block.

  By the way, the reliability judgment of the above-mentioned registration information is based on the judgment that the personal ID, the personal information and the secret key of the user are kept secret from a third party, and the signer (the person who created their hash value) has the correct personal ID and personal information. It is assumed that a hash value is created from personal information. However, if a legitimate user intentionally performs fraud (falsification of personal information, etc.), only the signature of the person attached to the registration information (in this case, the hash value of the personal ID and the hash value of the personal information) Then, the validity of the original data (personal ID itself and personal information itself) is not guaranteed.

  For example, when the first personal information used for object confirmation is information derived from the living body of the user such as a face photograph or biometric information, the first personal information is created from the hash value created from the disclosed first personal information and the disclosed personal ID 13D. The disclosed first personal information or disclosure is determined based on a correspondence relationship with the hash value and a similarity relationship between the disclosed first personal information and equivalent information (current biometric information or the like) obtained from the disclosing person. The validity of the original data of the hash value of the obtained first personal information, that is, the validity of the disclosing person who disclosed the personal ID 13D as the personal information of the user himself indicated by the personal ID 13D can be confirmed.

  However, if the disclosed first personal information is information other than information derived from the living body of the user (for example, attribute information such as name, address, and date of birth), the reliability of the personal information Hash32D included in the registration block The confirmation alone cannot confirm the validity of the first personal information as the original data.

  Therefore, a registration block may be added after a predetermined checking organization checks the validity of the personal information in consideration of the intentional fraud of the user. At this time, a signature 35D of the confirmation organization may be added to the personal information Hash32D instead of the signature 33D of the principal or together with the signature 33D of the principal. Even when the signature 35D of the confirming organization is added instead of the signature 33D of the principal, there is no particular problem because the signature 33D of the principal is attached to the personal ID_Hash 31D. When the signature 33D of the principal and the signature 35D of the confirming organization are added together, a nested structure may be adopted such that the data to be signed with one signature is regarded as one data and the other signature is added. Each of the two signature target data may be signed.

  FIG. 10 is an explanatory diagram showing another example of a method for signing registration information in a registration block. In FIG. 10, the dotted line represents the signature target data of the signature 33D of the principal, and the dashed line represents the signature target data of the signature 35D of the confirming organization. FIG. 10A shows an example of a case where a signature 35D of a confirmation organization is added to the personal information Hash32D instead of the signature 33D of the principal. FIGS. 10B to 10F show an example in which a signature 33D of the principal and a signature 35D of the confirmation organization are added to the personal information Hash32D. In the example shown in FIG. 10B, the signature 33D of the principal and the signature 35D of the confirmation organization are added to the personal information Hash32D, which is the data to be signed, respectively, and the examples shown in FIGS. In this example, the signature 33D of the principal and the signature 35D of the confirmation organization are attached in a nested structure. Here, the “nested structure” means that one signature is first attached to the signature target data, and the data including the signature is made new signature target data and the other signature is attached. The signer who signs later can include the signature target data and other data in addition to the previously attached signature. In any case, when confirming the reliability of the registration information in the object confirmation, it is necessary to determine in advance what kind of structure and what signature is attached to which data or information in the block. It is assumed that As a result, if another confirming institution can obtain the hash value of the personal ID, the hash value of the personal information, the public key of the principal, and the public key of the confirming institution, the reliability of the registered information (this includes the (Including the reliability of the signature 35D of the confirming authority that has confirmed the validity).

  For example, in the example shown in FIG. 10C, a signature 33D of the principal is added to personal information Hash32D, which is one of the registration information, and the signature 33D of the principal and the signature target data (personal information Hash32D) are added. Is the new signature target data, and the signature 35D of the confirmation organization is added. For example, in the example shown in FIG. 10D, a personal ID_Hash31D and personal information Hash32D, which are two pieces of registration information, have a signature 33D of the principal first, and the signature 33D of the principal and the signature target data (personal ID_Hash31D and personal information Hash32D) are used as new data to be signed, and a signature 35D of the confirmation organization is attached. In FIGS. 10 (c) to 10 (d), the confirming institution can use only the signature 33D of the person who is the previous signature as new signature target data and add the signature 35D of the confirming institution. Also, for example, in the example shown in FIG. 10E, a signature 35D of the confirmation organization is first added to the personal information Hash32D, which is one of the registration information, and the signature 35D of the confirmation organization and the previous signature target data (personal The information Hash32D) is used as new signature target data, and a signature 33D of the principal is added. In addition, the principal can use only the signature 35D of the confirmation organization as new signature target data and attach the signature 33D of the principal. Further, for example, in the example shown in FIG. 10F, a signature 35D of the confirmation organization is first added to the personal information Hash32D, which is one of the registration information, and the signature 35D of the confirmation organization and the previous signature target data (personal The information Hash32D) and other registration information (personal ID_Hash31D) are used as new signature target data, and a signature 33D of the person is added.

  In the personal information management system, as shown in FIG. 9 and FIG. 10, there is a case where the signature of the person or the confirmation organization is not attached one-to-one with registration information (for example, personal ID_Hash31D or personal information Hash32D). If the signature target data of the signature contains the registration information intended for the signature or another signature that uses the registration information as the signature target data (including the case where the signature information is included in a nested structure), The registered information is regarded as having a certain signature.

  Therefore, when registering certain registration information with the signature of the principal, the registration information with the signature of the principal together with the other registration information, the registration information with the signature target data of the other signature The signature of the principal is added to the data to be signed including the other signature attached to the registration information to which the other signature is attached, and the signature of the principal is The signature information includes the signature of the person attached to the registration information attached earlier and data to which another signature is attached as signature target data.

  For example, the confirming organization device 2 of the confirming organization requested to confirm the validity of the first personal information transmits the first personal information and the correctness of the first personal information from the client device 1 to the confirming organization. Second personal information that can be confirmed may be obtained. Then, after confirming that the first personal information is correct based on the second personal information, the confirmation institution device 2 calculates the hash value (personal information Hash32D) of the first personal information and obtains the hash value. The hash value is returned to the client device 1 with its own signature (signature 35D of the confirmation authority). When the client device 1 receives the hash value of the personal information with the signature of the confirmation authority, the client device 1 creates a registration block with the hash value of the personal ID (personal ID_Hash31D) with the signature 33D of the principal, and creates a blockchain 3 May be added.

  The confirming organization that checks the validity of the personal information may be, for example, the organization that issued the personal information (for example, a police institution for license information). In this case, for example, the checking institution device 2 of the checking institution as an issuer transmits information (such as a license number, a face photograph, a credit card number, and a password) that can be used for identity verification or user authentication in the checking institution. After acquiring as the second personal information and confirming whether or not they match the authentication information held by the user, the first personal information issued by the user and the first personal information requested to be confirmed are obtained. The validity may be determined by confirming whether. If the validity can be confirmed, a hash value of the first personal information acquired from the user may be calculated, and the hash value may be returned to the client device 1 with its own signature. Hereinafter, the second personal information obtained by the checking organization that checks the validity of personal information may be referred to as validity checking information.

  It is also possible to create a registration block and add it to the blockchain 3 on the confirmation organization side without replying to the client device 1. In this case, the confirmation institution device 2 may further obtain, from the client device 1, the personal ID_Hash 31D to which the signature 33D of the user himself is added. If necessary, the personal information Hash32D with the signature 33D of the principal, or the personal ID_Hash31D and the personal information Hash32D as registration information with the signature 33D of the principal may be acquired.

  If such a registered block is included in the blockchain 3, the checking organization thereafter does not need to check the validity of the first personal information disclosed by the user by itself, and the registration information in the block is not necessary. (Personal ID_Hash31D and personal information Hash32D) can be used for target confirmation only by confirming the reliability and confirming the consistency of the original data. However, in the verification of the credibility of the registration information, in addition to the proof of origin of the data to be signed (in this case, the proof of registration) and the non-falsification proof, the verification authority Of the signature target data (in this case, the registration source proof) and the non-tamper proof of the signature target data with the signature 35D.

  The timing of confirming the validity of the personal information which is the original data of the personal information Hash32D of the registration block is not limited to the time of registration of the registration block. For example, it is possible to have a predetermined confirmation organization confirm the validity of the personal information after the registration of the registration block. In such a case, the confirming organization performs object verification (identification or user confirmation) including verification of the validity of the original data of the registration information (more specifically, the first personal information whose consistency with the original data of the registration information has been confirmed). (Authentication), for example, a confirmation recording block as shown in FIG. The confirmation recording block shown in FIG. 11 includes, in the confirmation information 34D, personal information Hash32D included in the registration information obtained by confirming the validity of the original data of the registration information, the result of the identification (OK), and the validity of the original data. It contains information on the result of confirmation (OK).

  The object confirmation including the validity confirmation of the personal information which is the original data of the registration information is performed, for example, in the above-described object confirmation processing, the confirmation institution device 2 further transmits the disclosed personal information (first personal information) from the client device 1. Information) can be realized by acquiring second personal information that can be confirmed by the confirmation organization. The method of confirming the validity of the first personal information from the second personal information is as described above. When the validity of the first personal information can be confirmed by visual confirmation or the like from the first personal information at the confirmation institution, the acquisition of the second personal information is omitted.

  It is also possible for a confirmation organization other than the source of the personal information to confirm the validity of the personal information. In that case, the confirmation institution device 2 of the confirmation institution is the second personal information including, in a part thereof, the first personal information or information indicating the same content as the first personal information in the above-described target confirmation processing, The personal information (second personal information) may be acquired by the confirmation organization or the present system to confirm that the personal information is correct. Regardless of which institution confirms the validity, if the institution can confirm the validity of the first personal information from the first personal information visually or the like, the acquisition of the second personal information is omitted. Is done.

When a confirming organization other than the issuer checks the validity of personal information, for example, personal information that satisfies any of the following conditions (1) to (3) is used as second personal information (validity confirmation information). May be used.
(1) (a) “(a1)“ Original information including at least one piece of first personal information or information indicating the same content ”and (a2)“ identifiable information ”or It must be a copy of the original.
(2) (b1) "Information including at least (a1)" first personal information or information indicating the same content "" and (b2) "Issued for the original data of the hash value The block with the signature of the original confirmation authority is the information registered in the blockchain. "
(3) (c) "a set of information capable of identifying a user and an authentication information capable of performing user authentication in an institution holding authorized first personal information (authorized information holding institution)".

  It is assumed that the condition (1) is, for example, the case of (a) = (a1) an original license or a copy image of the license including the birth date data and (a2) the face image integrated. In such a case, if (a2) in the disclosed (a) is visually confirmed or collated with information equivalent to (a2) obtained from the current user, and it is confirmed that the disclosing person is the principal, (A1) can also be regarded as personal information. Then, (a1) in the disclosed (a) may be compared with the disclosed first personal information. At this time, the copied image may be obtained from the original at the time of object confirmation. The collation between (a1) in the disclosed (a) and the disclosed first personal information includes collation between image data and text data. Further, when information equivalent to (a2) is further obtained from the current user to confirm the validity of the second personal information, the information may be referred to as third personal information. In this case, the personal identification information including the third personal information may be called.

  For condition (2), for example, consider the case where (b1) = (a1) an insurance card image (entire) including birth date data. In such a case, if a block in which the signature of the issuing authority has been added to the disclosed original data of the hash value of (b1) is registered in the blockchain 3, the registration information of the block If the reliability and the consistency between the disclosed (b1) and the original data of the hash value in the block are confirmed, the disclosed (b1) is confirmed valid. After that, (a1) in the disclosed (b1) may be compared with the disclosed first personal information.

  Also, for condition (3), if (c) = a set of such user identification information and authentication information, (c) is transmitted to the authorized information holding organization together with the first personal information, and (c) is After performing user authentication on the basis of, based on the first personal information sent and collated with the first legitimate personal information of the user that is held by the legitimate information holding organization, by returning a result, The validity of the disclosed first personal information can be confirmed.

  For example, if the hash value (personal information Hash32D) of the personal information included in the registration block or confirmation record block of the user is not signed with the signature 35D of the confirming authority that has confirmed the validity of the original data, The confirmation institution device 2 may perform the target confirmation including the validity confirmation of the first personal information used for the target confirmation. Specifically, the confirmation institution device 2 may further request disclosure of the second personal information as described above when confirming the target.

  Further, the personal information management system may perform the above-described processing after performing user authentication for the personal ID when the user discloses the personal ID, if necessary. The user authentication can use an existing authentication technology.

  In addition, specific processing (addition of personal information and secret key) to the above-described addition of a registration block, addition of a confirmation recording block, confirmation of reliability of registration information in a block, confirmation of consistency of original data, confirmation of validity of original data, and the like. Is performed by the personal information management system using a UI (User Interface) or an API (Application Program Interface) provided by the personal information management system.

  Next, a main configuration of the personal information management system will be described with reference to FIG. The personal information management system 100 shown in FIG. 12 includes a data storage unit 101, a registration unit 102, a disclosure unit 103, an authentication unit 104, a data storage unit 201, a confirmation unit 202, a ledger management node 301, a data storage unit 501, and a personal ID assignment. A unit 502 is provided. As shown in FIG. 12, the personal information management system 100 is roughly divided into a user-side system 10, a confirmation institution side system 20, a ledger management system 30, and a management-side system 50.

  12, the data storage unit 101, the registration unit 102, the disclosure unit 103, and the authentication unit 104 belong to the user system 10. The data storage unit 201 and the confirmation unit 202 belong to the confirmation institution side system 20. The ledger management node 301 belongs to the ledger management system 30. The data storage unit 501 and the personal ID assignment unit 502 belong to the management system 50. Note that the authentication unit 104 can belong to the management system when performing user authentication using authentication information held in the management system.

  However, this classification is based on information access authority and does not limit the actual operating environment of the program. For example, the functions of a part of the registration unit 102 (excluding access to the data storage unit 101) and a part of the confirmation unit 202 (except for access to the data storage unit 201) are implemented in an apparatus included in the management-side system 50. May be done.

  Although not shown, the user side system 10 includes at least the client device 1. Further, the confirmation institution side system 20 includes at least the confirmation institution device 2.

  The respective processing units except the data storage unit 101, the data storage unit 201, and the data storage unit 501 are connected via the network 40. Note that the network 40 may include a plurality of different networks such as the Internet and an Ethereum network. The data storage unit 101 only needs to be connected to the registration unit 102, the disclosure unit 103, and the authentication unit 104. Further, the data storage unit 201 only needs to be connected to the confirmation unit 202. Further, the data storage unit 501 only needs to be connected to the personal ID assignment unit 502.

  The data storage unit 101 holds information required by each processing unit belonging to the user-side system 10 and information disclosed to other systems as user information. The data storage unit 101 stores, for example, personal information 14D of the user, a personal ID 13D assigned by the personal information management system 100, and a signature pair key (a secret key 11D and a public key 12D). In the present embodiment, at least a part of the data storage unit 101 is accessed from a storage device having a secure area provided in a device (for example, the client device 1) provided in the user side system 10 or a device provided in the user side system 10. This is realized by a possible divided file system.

  The registration unit 102 has a registration block including a hash value of the user's personal ID 13D, a hash value of the personal information 14D to be registered, and a necessary signature (including at least the signature of the user) in response to an instruction from the user. Is registered in the blockchain 3. Note that the actual registration is performed by a ledger management node 301, which will be described later, through a predetermined procedure. Therefore, the registration unit 102 performs processing for adding a registered block to the blockchain 3 via the ledger management node 301. Note that the registration unit 102 only needs to provide a procedure for registering such a registration block in the blockchain 3 to the user.

  For example, when the user specifies the personal information 14D to be registered, the registration unit 102 reads the specified personal information 14D from the data storage unit 101 and calculates a hash value thereof. Then, the obtained hash value of the personal information (personal information Hash32D) and the hash value of the personal ID 13D (personal ID_Hash31D) are given at least one signature 33D of the principal, and the registered block of the registered block is registered. An addition request (block addition request) is transmitted to the ledger management node 301 described later.

  In addition, the registration unit 102 may transmit a request for confirming the validity of the personal information 14D as the original data together with the personal information 14D to the confirmation unit 202 of a predetermined confirmation organization as necessary. Thereby, at least the signature 35D of the confirming organization for the personal information Hash32D may be obtained. Then, the registration unit 102 requests the registration block to add the registration information including the personal information Hash32D, the personal ID_Hash31D, the signature 35D of the confirmation organization for at least the personal information Hash32D, and the signature 33D of the principal to the personal ID_Hash31D. (Block addition request) may be transmitted to the ledger management node 301 described later.

  In addition, the registration unit 102 may transmit a request to confirm the validity of the personal information 14D and a registration request of the registration block to the confirmation unit 202 of the predetermined confirmation organization together with at least the personal ID_Hash 31D with the signature 33D of the principal. In this case, the confirmation unit 202 requests the registration block to add the registration information including the personal information Hash32D, the personal ID_Hash31D, the signature 35D of the confirmation organization for at least the personal information Hash32D, and the signature 33D of the principal to the personal ID_Hash31D as the registration information ( (A block addition request) may be transmitted to the ledger management node 301 described later.

  The disclosure unit 103 outputs the designated personal information 14D or its hash value to the outside according to an instruction from the user. Here, the output to the outside may include display (output to a display device) and transmission (output to a designated destination). For example, when the disclosure unit 103 receives a disclosure request in which the personal information 14D is specified from the confirmation unit 202, the disclosure unit 103 inquires of the user whether or not the personal information 14D is to be disclosed, and then specifies the specified personal information 14D or its hash value. The data is output to the output destination (the request source confirmation unit 202, the display unit, or the like). If the hash value of the personal information 14D is registered in the blockchain 3 as a confirmation record block or a registration block together with the result of the target confirmation for the same purpose or the signature of the confirmation organization, the disclosure unit 103 specifies the designated personal information. Instead of 14D, a hash value of the designated personal information 14D can be output. At this time, the disclosure unit 103 may output the specified information after inquiring the user which information to disclose, or may output the hash value preferentially without making an inquiry. Good. When outputting the hash value of the personal information instead of the personal information, the disclosure unit 103 may also output the information of the confirmation recording block at that time.

  The authentication unit 104 performs user authentication for the current user when another processing unit accesses the personal ID 13D. For example, upon detecting access to the personal ID 13D, the authentication unit 104 requests the current user to input authentication information, compares the input authentication information with authentication information stored in advance, and checks the current authentication information. Perform user authentication of the user. Note that when user authentication for the personal ID 13D is unnecessary in the user system 10, the authentication unit 104 may be omitted.

  In the present embodiment, the registration unit 102, the disclosure unit 103, and the authentication unit 104 are realized by, for example, a CPU or the like that can access the data storage unit 101, such as being installed in a device included in the user system 10.

  Note that the authentication unit 104 can also operate as a processing unit that performs user authentication for the personal ID 13D disclosed by the disclosure unit 103 in the management-side system 50. In this case, the authentication unit 104 requests the current user (discloser) of the disclosure unit 103, which has disclosed the personal ID 13D, to input authentication information in response to a request from the confirmation unit 202 described later. The information and the authentication information stored in advance in the data storage unit 501 and the like are collated to perform user authentication of the discloser. In this case, the authentication unit 104 is realized by a CPU or the like mounted so as to access the data storage unit 501.

  The data storage unit 201 holds information required by each processing unit belonging to the confirmation institution side system 20 and information disclosed to other systems included in the personal information management system 100 as information on the confirmation institution. The data storage unit 201 stores, for example, a confirming institution ID and a signature pair key (a secret key 21D and a public key 22D). In the present embodiment, at least a part of the data storage unit 201 includes a storage device having a secure area included in a device (for example, the confirmation institution device 2) provided in the confirmation institution side system 20 and a device provided in the confirmation institution side system 20. This is realized by an accessible divided file system.

  The confirmation unit 202 confirms the target of the user in response to an instruction from the confirmation organization requested for the service by the user. The confirmation unit 202, for example, based on the information acquired from the disclosure unit 103 of the designated user and the information registered in the blockchain 3 (the information in the registration block and the confirmation recording block). Confirm the target.

  The confirmation unit 202 requests, for example, the disclosure unit 103 of the designated user to disclose the personal ID 13D and the personal information 14D used for target confirmation or a hash value thereof (personal information Hash32D). In addition, the confirmation unit 202 searches for a registration block or a confirmation recording block of the user based on the obtained information and the registration history of the blocks held by the user system 10. Then, by using the obtained registration block or confirmation record block of the user, the above-described confirmation of the reliability of the registration information, the consistency of the original data, and the validity of the personal information are performed. The results are output and the target is confirmed based on the confirmation results. In addition, the target confirmation itself is performed by confirming the reliability of the registered information, confirming the consistency of the original data, confirming the validity of the personal information, or outputting the result of determining the validity of the disclosed information determined based on a combination thereof. On the basis of this, the user of the confirmation organization may perform the operation. In this case, the confirmation unit 202 receives the result of the object confirmation performed by the user.

  Further, the confirmation unit 202 creates a confirmation recording block indicating the record of the target confirmation as necessary, and performs a process for adding the confirmation recording block to the block chain 3. The confirmation record block includes at least a hash value (individual ID_Hash31D) of the personal ID 13D of the user who has performed the object confirmation, and a signature 35D of the confirmation organization for the hash value.

  Note that the confirmation unit 202 only needs to be able to provide such a confirmation of the target and a registration procedure of such a confirmation record block to the block chain 3 to the confirmation organization. In the present embodiment, the confirmation unit 202 is realized by, for example, a CPU or the like that can access the data storage unit 201, such as being installed in a device included in the confirmation institution side system 20.

  Note that FIG. 12 shows only one user-side system 10 and one confirmation-institution-side system 20. However, the user-side system 10 is provided for each user, and the confirmation-institution-side system 20 is also connected to the confirmation-institution. It is provided for each.

  The ledger management system 30 is a system in which a blockchain is used as a ledger, and the ledger is shared and managed by a plurality of nodes. As a system for managing the blockchain, a ledger management system is exemplified, but a ledger that can execute processing according to a predetermined consensus algorithm (hereinafter, referred to as consensus processing) and is difficult to falsify is shared by terminals in the system. The system is not limited to the ledger management system.

  The ledger management node 301 is a node that executes a consensus process in the ledger management system 30. Each of the ledger management nodes 301 holds a copy of the blockchain 3 through the execution of the consensus process.

  In FIG. 12, the user side system 10 and the ledger management system 30 are separately illustrated, and the confirmation institution side system 20 and the ledger management system 30 are separately illustrated. May have the function of the ledger management node 301.

  The data storage unit 501 holds information required by each processing unit belonging to the management-side system 50 and information disclosed to other systems included in the personal information management system 100 as information of the management-side system 50, if any. I do. The data storage unit 501 may store, for example, information (such as an execution code) that implements a procedure performed by a processing unit of another system included in the personal information management system 100, such as information on a personal ID assigned to a user. Good. In the present embodiment, at least a part of the data storage unit 501 is realized by a storage device having a secure area provided in the management system 50 or a divided file system accessible from a device provided in the management system 50.

  The personal ID assigning unit 502 assigns a personal ID 13D to a user. In the present embodiment, the personal ID assigning unit 502 is realized by, for example, a CPU or the like that can access the data storage unit 501, such as being installed in a device included in the management system 50.

  FIG. 13 is a block diagram illustrating a configuration example of the checking unit 202. As shown in FIG. 13, the confirmation unit 202 includes a data acquisition unit 221, a registration information reliability confirmation unit 222, an original data consistency confirmation unit 223, a personal information validity confirmation unit 224, and a result output unit 225. , And a confirmation record registration unit 226.

  The data acquisition unit 221 transmits the information (for example, the personal information 14D or its hash value, and the past confirmation record block of the user) necessary for the object confirmation together with the personal ID 13D from the user side system 10 (in particular, the disclosure unit 103). Information, etc.). In addition, the data acquisition unit 221 searches the blockchain 3 based on the information acquired from the user side system 10 and obtains information on the user (especially, personal information 14D required for target confirmation or its hash value, A block including a record (confirmation information 34D and the like) indicating that the target confirmation has been performed is acquired using the block.

  For example, when acquiring the personal ID 13D and the personal information 14D from the user system 10, the data acquiring unit 221 blocks the latest block including the hash value of the personal ID 13D and the hash value of the personal information 14D. It may be obtained from the chain 3. Further, for example, when the data acquisition unit 221 acquires the personal ID 13D and the hash value of the personal information 14D from the user system 10, the hash value calculated from the personal ID 13D and the hash value of the personal information 14D May be obtained from the blockchain 3. Further, for example, when acquiring the personal ID 13D from the user-side system 10, the data acquiring unit 221 may acquire the latest block including the hash value calculated from the personal ID 13D from the block chain 3. Further, for example, when the data acquisition unit 221 acquires the hash value of the personal ID 13D and the information of the past confirmation record block from the user side system 10, the data acquisition unit 221 acquires the latest confirmation record block from the block chain 3. Is also good.

  The data acquisition unit 221 may determine what information to acquire from the user system 10 from the confirmation record of the user.

  The registration information reliability check unit 222 checks the reliability of the information (registration information) in the block acquired by the data acquisition unit 221 based on the signature attached to the registration information. When a plurality of signatures are included in the block, the registration information credibility check unit 222 checks the credibility of the data to be signed with the specified signature by comparing the data with the decryption result of the signature. . At this time, if the signature specified in the nested structure is attached in the nested structure, the decryption process is performed in the reverse order of the encryption process when the signature is attached, and the signature target data of each signature is obtained. The final reliability may be checked by comparing the result with the decryption result of the signature.

  When the data acquisition unit 221 acquires the user's personal information 14D and acquires a block including the personal information Hash32D that is a hash value of the personal information 14D, the original data matching unit 223 It confirms the consistency between the personal information serving as the original data of the personal information Hash32D and the acquired personal information 14D. For example, the original data consistency check unit 223 compares the hash value calculated from the personal information 14D obtained by the data acquisition unit 221 with the personal information Hash32D in the block, thereby obtaining the original information Hash32D in the block. What is necessary is just to confirm the consistency between the personal information used as the data and the acquired personal information 14D.

  The personal information validity confirmation unit 224 confirms the validity of the first personal information when the data acquisition unit 221 obtains personal information (first personal information) used for object confirmation. The personal information validity checking unit 224 checks that the first personal information such as the biometric information of the current user (discloser), “information that can be identified”, and “information that can be authenticated by the user” is correct. Is further obtained by the data acquisition unit 221 that can be confirmed by the confirmation organization, and the validity of the first personal information is confirmed based on the second personal information.

  The result output unit 225 includes a confirmation result by the registration information reliability confirmation unit 222, the original data consistency confirmation unit 223, and the personal information validity confirmation unit 224, and the validity of the disclosed information determined based on them. It outputs the judgment result and the final result of object confirmation. The final target confirmation is performed by the confirmation result by the registration information reliability confirmation unit 222, the original data consistency confirmation unit 223, and the personal information validity confirmation unit 224, and the validity of the disclosed information determined based on them. The user of the confirmation organization may perform the determination based on the output of the gender determination result. In this case, the confirmation unit 202 receives the result of the object confirmation performed by the user.

  The confirmation record registration unit 226 registers the confirmation record block in the block chain 3 based on the result obtained by the result output unit 225. Further, the confirmation record registration unit 226 outputs information of the confirmation record block to the user system 10 as necessary.

  FIG. 14 is a block diagram illustrating a configuration example of the ledger management node 301. The ledger management node 301 shown in FIG. 14 includes a registration information receiving unit 311, a block generation unit 312, a block sharing unit 313, an information storage unit 314, and a block verification unit 315.

  The registration information receiving unit 311 receives, from an external node, information to be recorded in a ledger which is a block chain managed by the ledger management system 30. In the present embodiment, the registration information receiving unit 311 receives, for example, the contents of a registration block (block data) and the contents of a confirmation recording block (block data) as information to be recorded in a ledger.

  The block generation unit 312 generates a block to be added to the block chain based on the information (block data) received by the registration information reception unit 311. The block generation unit 312 generates a block including the information based on the previous block and the information received by the registration information reception unit 311. Further, the block generation unit 312 performs, for example, a process of searching for a nonce as a predetermined consensus process on a block generated by itself or a block generated by another ledger management node 301 via a block sharing unit 313 described below. After performing a process of adding a signature and a signature, a block is added to a block chain managed by itself (corresponding to a copy of the block chain 3). A block obtained by performing a predetermined consensus process by a plurality of ledger management nodes 301 on a block generated by the block generation unit 312 is a block finally added to the block chain 3.

  The block sharing unit 313 exchanges information between the ledger management nodes 301 belonging to the ledger management system 30. More specifically, the block sharing unit 313 transmits the information received by the registration information receiving unit 311, the block generated by the block generation unit 312, the block received from another ledger management node 301, and the like to another ledger as appropriate. Send it to the management node 301. As a result, the information and the latest blockchain 3 are shared by all ledger management nodes 301 as much as possible.

  The information storage unit 314 stores a copy of the block chain 3. The information storage unit 314 may store, for example, information necessary for a verification process in a block verification unit 315 described below, in addition to the copy of the block chain 3.

  When a block is added to a block chain held by itself, the block verification unit 315 verifies information in the block. Usually, the block to be added is the block that satisfies the rule first in the ledger management node 301 group including the own node. However, in consideration of the case where the malicious ledger management node 301 is included, etc. It may be verified whether the rule is actually satisfied.

  Note that the configuration in FIG. 14 is merely an example, and the ledger management node 301 can execute a predetermined consensus process for sharing and managing the block chain 3 that is difficult to falsify with a plurality of nodes. Any specific configuration can be used as long as it is a node that can add information to the ledger and refer to the ledger in response to a request from.

  Next, the operation of the present embodiment will be described. The operation of this embodiment is roughly divided into two phases: a registration phase for registering a registered block in a blockchain, and a confirmation phase for performing target confirmation based on a registered block registered in the blockchain and a past confirmation record block. . Further, the confirmation phase includes a first confirmation phase in which the user is made to disclose personal information and the object is confirmed based on the registered block in the blockchain 3, and a blockchain in which the user is not disclosed personal information. The second is a second confirmation phase in which the target is confirmed based on the confirmation record block in 3.

  First, the operation of the personal information management system in the registration phase will be described with reference to FIG. FIG. 15 is a flowchart illustrating an example of an operation in the registration phase of the personal information management system according to the present embodiment. The registration phase shown in FIG. 15 is an example of a case where a registration block is registered without confirming the validity of the personal information used as the original data by the checking organization.

  In the example shown in FIG. 15, first, the registration unit 102 of the user side system 10 reads the personal ID 13D and the personal information 14D to be registered from the data storage unit 101, calculates a hash value for each of them, and obtains the personal ID_Hash 31D and the personal information. Hash32D is obtained (step S101). The registration unit 102 may access the personal ID 13D and the personal information 14D after performing user authentication.

  Next, the registration unit 102 adds the signature 33D of the principal to the personal ID_Hash31D and the personal information Hash32D obtained in this way, and registers the personal ID_Hash31D and the personal information Hash32D with the signature 33D of the principal. A block is created (Step S102).

  Next, the registration unit 102 requests the ledger management node 301 to add the created registration block, and registers the registration block in the blockchain 3 (step S103). At this time, the registration unit 102 may acquire the key information of the registered block that has been registered from the ledger management node 301, and may store the key information in the data storage unit 101 as a registration history.

  In this way, the personal ID_Hash31D, which is the hash value of the user's personal ID 13D, and the personal information Hash32D, which is the hash value of the user's personal information 14D, with the signature 33D of the user himself / herself, are registered in the blockchain 3. A registration block containing information is added.

  FIG. 16 is a flowchart illustrating another example of the operation in the registration phase of the personal information management system according to the present embodiment. Note that the registration phase shown in FIG. 16 is an example of the case where the registration block is registered after the validity of the personal information used as the original data is confirmed by the confirmation organization.

  In the example shown in FIG. 16, first, the registration unit 102 of the user system 10 reads out the personal information 14D (first personal information) to be registered from the data storage unit 101 (step S111).

  Next, the registration unit 102 transmits a request for confirming the validity of the personal information including the first personal information and, if necessary, the second personal information to the confirmation unit 202 of the confirmation institution side system 20 of the issuer. (Step S112).

  Upon receiving the request for confirming the validity of the personal information, the confirmation unit 202 (for example, the personal information validity confirmation unit 224) confirms the validity of the first personal information included in the request based on the second personal information. (Step S113). When the validity of the first personal information can be confirmed, the confirmation unit 202 calculates the hash value (personal information Hash32D), attaches the signature 35D of the confirmation organization to the obtained hash value, It is transmitted to the request source together with the confirmation result (steps S114 to S116).

  When the validity of the personal information is obtained, the registration unit 102 calculates the hash value of the personal ID 13D (personal ID_Hash31D) (step S117), and adds the signature 33D of the person to the obtained hash value. Then, a registration block is created in which the personal ID_Hash 31D with the signature 33D of the principal and the personal information Hash 32D with the signature 35D of the confirmation organization are registered (step S118). The process of registering the created registration block in the block chain 3 may be the same as in step S103.

  Next, the operation of the personal information management system in the confirmation phase will be described with reference to FIG. FIG. 17 is a flowchart illustrating an example of an operation in the confirmation phase of the personal information management system according to the present embodiment. Note that the confirmation phase shown in FIG. 17 is an example of a first confirmation phase in which the user is made to disclose personal information and the target is confirmed based on the registered blocks in the blockchain 3.

  In the example shown in FIG. 17, first, the confirmation unit 202 (for example, the data acquisition unit 221) of the confirmation institution side system 20 transmits a request for disclosure of a personal ID to the user side system 10 (step S201).

  The disclosure unit 103 of the user-side system 10 that has received the request for disclosure of the personal ID reads the personal ID 13D from the data storage unit 101 and transmits it to the request source (step S202, step S203).

  The confirmation unit 202 (for example, the data acquisition unit 221) of the confirmation institution side system 20 that has received the personal ID 13D searches the block chain 3 for a confirmation recording block including the hash value of the obtained personal ID 13D (step S204). In step S203, the data acquisition unit 221 may acquire the information of the confirmation recording block indicating the recording of the target confirmation of the same purpose from the disclosure unit 103 together with the personal ID 13D, and may search the confirmation recording block based on the acquired information. Note that the disclosure unit 103 may obtain such block information from the registration history held by the user system 10, for example.

  As a result of the search, if a desired confirmation recording block (for example, a confirmation recording block including the confirmation information 34D indicating the confirmation result for the same purpose) is not found, the data acquisition unit 221 further determines an individual required for the object confirmation. The information disclosure request is transmitted to the disclosure unit 103 (step S205). The request for disclosure may include the type of the requested personal information.

  Upon receiving the personal information disclosure request, the disclosure unit 103 reads out the requested type of personal information (here, the first personal information) and transmits it to the request source (steps S206 and S207). At this time, the disclosure unit 103 may transmit the personal information to the request source after obtaining permission for the user to disclose the personal information.

  Upon acquiring the first personal information, the data acquiring unit 221 searches the block chain 3 for a registered block in which personal information Hash32D (hereinafter, referred to as personal information Hash32D-1), which is a hash value thereof, is registered (step S208). ). In step S207, the data acquisition unit 221 may acquire, from the disclosure unit 103, information of the registered block in which the hash value is registered together with the personal information, and may search for the registered block based on the acquired information.

  When a desired registration block is obtained as a result of the search, the registration information credibility check unit 222 of the check unit 202 checks at least the personal ID_Hash31D and the personal information Hash32D-1 included in the registration block based on the signature attached to them. Next, the reliability is confirmed (step S209: reliability confirmation of registration information). The method for confirming the reliability of the registration information is as described above.

  In addition, the original data consistency check unit 223 of the check unit 202 determines that the personal data of the personal ID_Hash31D and the personal information Hash32D-1 included in the registration block match the acquired personal ID 13D and the first personal information. Is checked by comparing the hash values (Step S210: Checking the consistency of the original data). The method of confirming the consistency of the original data is as described above.

  In step S208, the data acquisition unit 221 may search for a confirmation record block indicating a record of confirming the validity of the first personal information.

  In this case, in the reliability check processing of the registration information in step S209, the reliability of the personal ID_Hash 31D and the check information 34D included in the check record block may be checked based on the signature attached thereto. In the process of confirming the consistency of the original data in step S210, the personal information Hash32D-1 to be compared with the disclosed first personal information may be obtained based on the confirmation information 34D of the confirmation recording block. For example, the data acquisition unit 221 may acquire a hash value (personal information Hash32D-1) which is a validity confirmation target indicated in the confirmation information 34D. Also, for example, the data acquisition unit 221 includes, in the confirmation information 34D, information (TxID or the like described later) of a registered block in which the hash value (personal information Hash32D-1) to be verified is registered. If so, the registered block may be searched from the information to obtain the personal information Hash32D-1 included in the searched registered block.

  If the desired registration block or confirmation record block is not found as a result of the search, the fact that the personal information used for object confirmation has not been registered is transmitted to the user-side system 10, and the processing is terminated. May be.

  In addition, the confirmation unit 202 (for example, the personal information validity confirmation unit 224) adds a signature 35D of a confirmation organization that satisfies predetermined conditions such as an issuer or a legitimate information holding organization to the personal information Hash32D-1 included in the registration block. If not, the first personal information may be checked for validity.

  For example, the personal information validity confirmation unit 224 transmits a disclosure request for information (validity confirmation information) necessary for validity confirmation to the disclosure unit 103 (step S211). The request for disclosure may include the type of the requested personal information.

  Upon receiving the request to disclose the validity confirmation information, the disclosure unit 103 reads out the requested type of personal information (here, the second personal information that is regarded as validity confirmation information) and transmits it to the request source (step S10). S212, step S213). As in step S206, the disclosure unit 103 may transmit the personal information to the request source after obtaining permission for the user to disclose the personal information.

  Upon acquiring the second personal information as the validity confirmation information, the personal information validity confirmation unit 224 confirms the validity of the first personal information based on the second personal information (step S214: personal information Validation). The method of confirming the reliability of the personal information is as described above. Here, the data acquisition unit 221 may further acquire a registered block in which the hash value of the second personal information is registered, biometric information of the current user, and the like.

  Note that the processing in steps S211 to S214 is performed when the personal information Hash32D-1 is registered with the signature 35D of a confirmation organization that satisfies a predetermined condition in the registration block in which the personal information Hash32D-1 is registered. Omitted. In this case, the confirmation unit 202 may just accept the confirmation result of the validity of the personal information in step S214 as confirmation OK.

  Next, the result output unit 225 of the confirmation unit 202 outputs the result of the determination of the validity of the disclosed first personal information and the result of the final target confirmation from the processing results so far (step S215).

  The result output unit 225 is disclosed, for example, when the results of the reliability check of the registration information in step S209, the consistency check of the original data in step S210, and the validity check of the personal information in step S214 are all OK. The first personal information may be a disclosing person, and may determine that the disclosed personal ID is correct information of the corresponding user. If any of the confirmation results is NG, it may be determined that the disclosed first personal information is a disclosing person and the disclosed personal ID is not correct information of the corresponding user. . In addition, for example, the result output unit 225 determines that the disclosed first personal information is correct when the disclosed personal ID is correct information of the corresponding user who is the disclosed personal ID. On the basis of the personal information of (1), the confirmation organization may perform target confirmation and output the confirmation result. Examples of object confirmation include age confirmation and service eligibility confirmation. Here, as an example of the service eligibility confirmation, there is a collation with user information (payment information or the like) in the confirmation institution side system specified by the disclosed first personal information.

  Next, the confirmation institution side system 20 (for example, a service providing unit not shown) determines the validity (including identity verification) of the disclosed first personal information output from the result output unit 225 and the target A service may be provided to the user based on the confirmation result (step S216).

  Next, the confirmation record registration unit 226 creates a confirmation record block indicating the record of the current confirmation, and registers the block in the block chain 3 (step S217, step S218). The confirmation record registration unit 226 generates, for example, confirmation information 34D indicating that a predetermined target confirmation is OK or personal identification OK for the personal information Hash32D-1 in the above-described registration block. Further, the confirmation record registration unit 226 calculates, for example, a hash value (personal ID_Hash31D) of the personal ID 13D acquired in step S203. Then, a signature 35D of the confirmation organization is generated for the personal ID_Hash 31D and the confirmation information 34D obtained as described above, and a confirmation recording block including the personal ID_Hash 31D and the confirmation information 34D with the signature 35D of the confirmation organization is created. May be. Note that the block registration processing may be the same as step S103.

  In this way, for example, when the first object confirmation is performed, the blockchain 3 confirms the confirmation result for the personal ID_Hash31D and the personal information Hash32D-1 with the signature 35D of the confirming organization that performed the object confirmation. A confirmation recording block including the information 34D is added.

  Next, the operation of the personal information management system in the confirmation phase will be described with reference to FIG. FIG. 18 is a flowchart illustrating an example of an operation in the confirmation phase of the personal information management system according to the present embodiment. Note that the confirmation phase shown in FIG. 18 is an example of a second confirmation phase in which a target is confirmed based on the confirmation recording block in 3 in the blockchain without disclosing personal information to the user.

  In the example shown in FIG. 18 as well, first, the confirmation unit 202 (for example, the data acquisition unit 221) of the confirmation institution side system 20 transmits a request to disclose the personal ID to the user side system 10 (step S201). Note that the processing from step S201 to step S204 may be the same as in the first confirmation phase.

  In this example, as a result of the search, a desired confirmation recording block (for example, a confirmation recording block including confirmation information 34D indicating the confirmation result for the same purpose) is obtained.

  Next, the registration information reliability confirmation unit 222 of the confirmation unit 202 confirms the reliability of the personal ID_Hash 31D and the confirmation information 34D included in the confirmation record block based on the signature 35D of the confirmation organization attached to them. (Step S209: Confirmation of reliability of registration information).

  Next, the result output unit 225 of the confirmation unit 202 outputs the final result of the object confirmation from the processing results so far (Step S215). In this example, if the result of the reliability check of the registration information in step S209 is OK, the result output unit 225 outputs that the check result included in the check information 34D of the check recording block has been obtained in the past. Alternatively, the past target confirmation result may be directly used. At this time, the result output unit 225 outputs the confirmation institution that has performed the object confirmation and the contents of the confirmation without directly using the confirmation institution when the confirmation record is a confirmation record by a confirmation institution other than the confirmation institution. An inquiry may be made as to whether or not the target confirmation result can be used.

  If it is acceptable, the confirmation institution side system 20 (for example, a service providing unit not shown) may provide a service to the user based on the target confirmation result (step S216). If it cannot be used, the processing after step S205 shown in FIG. 17 may be performed.

  Also in this example, the confirmation record registration unit 226 may create a confirmation record block indicating the record of the current confirmation, and register the block in the block chain 3 (steps S217 and S218). The confirmation record registration unit 226 attaches, for example, a signature 35D of the confirmation organization to the acquired hash value of the personal ID 13D (personal ID_Hash31D) and confirmation information 34D indicating the information of the confirmation record block used and the result of the target confirmation. Then, a confirmation recording block may be generated.

  In this way, for example, when the target confirmation is performed for the second time, the personal ID_Hash 31D, which is a hash value of the user's personal ID 13D and has the signature 35D of the confirming organization that has performed the target confirmation, is added to the blockchain 3. A confirmation record block including the signature 35D of the confirmation organization is added to the information of the confirmation record block used and the confirmation information 34D indicating the target confirmation result.

  After the third time, for example, after confirming the reliability of the registration information of the confirmation record block indicating the record of the second object confirmation, the object confirmation result obtained from the information indicated by the confirmation information 34D is used. can do. For example, when the information of the used confirmation recording block (the confirmation recording block indicating the record of the first object confirmation in the case of the third time) is acquired, the acquired confirmation recording block is further acquired, and The reliability of the registration information and the verification of the confirmation information may be checked, and an inquiry may be made as to whether or not to use the information.

  FIG. 19 is a flowchart summarizing the operation of the confirmation institution side system 20 in the confirmation phase. As shown in FIG. 19, the data acquisition unit 221 of the confirmation unit 202 first acquires the personal ID 13D from the user (more specifically, the user system 10) (step S301).

  Next, the data acquisition unit 221 searches the block chain 3 for a past confirmation record block of the user (step S302).

  If there is a confirmation recording block indicating the confirmation recording for the same purpose (Yes in step S303), the process proceeds to step S310 after acquiring the registration information of the confirmation recording block.

  When such a confirmation recording block does not exist (No in step S303), the data acquisition unit 221 requests the user to disclose personal information (first personal information) used for object confirmation (step S303). .

  When the first personal information is acquired, a confirmation record indicating a record of performing a personal identification on the registered block in which the personal information Hash32D-1 is registered or the original data of the registered personal information Hash32D-1 from the block chain 3. A block is searched (step S304).

  When such a registered block or a confirmation recording block is confirmed, the process proceeds to step S305 after acquiring the registration information of the block.

  In step S305, the block chain 3 is determined from the presence or absence of the signature 35D of the confirmation organization attached to the personal information Hash32D-1 in the acquired registration information and the confirmation result of the confirmation information 34D included in the acquired registration information. It confirms whether the validity of the original data (first personal information) has been confirmed in the past with respect to the personal information Hash32D-1 registered in.

  If the validity of the original data (first personal information) has not been confirmed (No in step S305), the data acquisition unit 221 checks the validity of the first personal information with the second personal information (validity). The user is further requested to disclose the confirmation information (step S306).

  Then, the personal information validity confirmation unit 224 confirms the validity of the first personal information acquired from the user based on the acquired second personal information (step S307). When the validity of the first personal information has been confirmed, the process proceeds to step S311.

  On the other hand, if the validity of the original data (first personal information) has been confirmed (Yes in step S305), the data acquisition unit 221 confirms the validity of the original data registered in the blockchain 3. After acquiring the personal information Hash32D-1 that is, the process proceeds to step S308.

  In step S308, the original data consistency check unit 223 sets the first personal information (the personal information at the time of registration) as the original data of the personal information Hash32D-1 for which the validity of the original data in the blockchain 3 has been confirmed. ) And the first personal information acquired from the user. The original data consistency check unit 223 calculates a hash value from the first personal information obtained from the user, and matches the hash value with the personal information Hash32D-1 in which the validity of the original data in the blockchain 3 has been confirmed. You just need to confirm.

  If the matching with the original data of the personal information Hash32D-1 whose validity has been confirmed has not been confirmed (No in step S309), the process directly proceeds to step S311.

  On the other hand, when it is confirmed that the personal information Hash32D-1 whose validity has been confirmed matches the original data (Yes in step S309), the process proceeds to step S310.

  In step S310, the registration information reliability confirmation unit 222 acquires the registration information from which the information used for the determination so far is acquired (the confirmation recording block in step S303, the registration block in step S304, or the registration information of the confirmation recording block). , The credibility is confirmed using the signature attached thereto. Note that, when acquiring part of the registered information, the registered information credibility check unit 222 performs credibility check on at least the information and the personal ID_Hash 31D associated with the information.

  Also, in this example, an example is shown in which the validity of the personal information is determined first, and then the validity of the personal information is confirmed, or the consistency with the original data and the reliability of the registered information are confirmed. However, the order of these confirmations is not particularly limited. For example, each time information (confirmation information 34D, personal information Hash32D-1 or the like) is acquired from block registration information, a signature attached to the information and a personal ID_Hash31D associated therewith in the same block is added. It may be used to confirm the reliability.

  In step S311, the result of the previous confirmation, the result of the determination of the validity of the disclosed information based on the result, and the result of the final target confirmation are output. When a confirmation recording block for the same purpose is found, an inquiry may be made as to whether or not the confirmation result is used. After outputting the result of the previous confirmation and the result of determining the validity of the disclosed information, the target confirmation result may be received from the user of the confirmation organization.

  In addition, when a plurality of pieces of personal information are necessary for the target confirmation, the confirmation unit 202 does not complete the target confirmation, such as when there is unacquired information or information whose validity has not been confirmed (No in step S312). Returns to step S303. Then, a request for necessary personal information may be made to the user. Note that the confirmation unit 202 may determine whether or not the target confirmation has been completed by receiving from the confirmation institution side user.

  On the other hand, when the target confirmation is completed (Yes in step S312), the confirmation unit 202 creates a confirmation recording block indicating the record of the current confirmation, registers the confirmation recording block in the block chain 3, and ends the processing (step S314). ).

  As described above, according to the present embodiment, the confirmation record of the validity of the original data and the confirmation records for various purposes are registered in the blockchain 3, so that only one personal ID is disclosed. , You will be able to identify yourself in place of your license or passport. For this reason, the user does not need to perform the procedure of identity verification for each purpose and purpose.

  For example, simply by disclosing the personal ID, it is not possible to confirm the identity of the owner of the personal ID or the right to receive the requested service (eligibility to receive). However, according to the present embodiment, for example, in the first disclosure of the personal ID, it is necessary to confirm whether the user is eligible for the service and, if necessary, who owns the personal ID (identification). The personal information associated with the personal ID is confirmed based on the personal information, and a hash value indicating the correctness of the information used for the confirmation and the result thereof are recorded in the block chain 3 together with the signature of the confirmer. Then, in the second and subsequent scenes in which the same service is used, the service provider checks the past confirmation results and verifies the contents, so that the same confirmation results can be given.

  For example, a certain user has a predetermined confirmation organization confirm the validity (the correct information of the user indicated by the personal ID) with respect to the information on the date of birth or whether or not an adult is age information. Above, it is assumed that the hash value is registered in the block chain in association with the hash value of the personal ID.

  In such a case, in a scene of purchasing alcohol at a certain store A, at first, a request for disclosure of age information is made after disclosure of the personal ID, and the birth date or Information on whether or not the person is an adult is disclosed to the store.

  In store A, the validity of the disclosed information can be confirmed based on the record of the blockchain. For this reason, at store A, it is possible to provide the liquor by confirming the age only with the disclosed information (information on the date of birth and whether or not an adult). At this time, the store A records the result of the age confirmation (the result of confirming that the person is an adult) together with the hash value of the disclosed personal ID, with its own signature, in the blockchain.

  Next, in a case where alcohol is purchased at another store B, in a case where the same kind of age confirmation is performed for the second time, if the personal information is disclosed and then the store B requests age information disclosure, the user Can disclose the information of the confirmation record block in which the result of the first age confirmation is recorded instead of disclosing the age information. Store B obtains the first age check result from the blockchain based on the disclosed information, so that this personal ID has already been verified at Store A with the same type of age and has received service provision. Can be confirmed. Note that the store B may request the disclosure of the personal identification information not only in the disclosure of the confirmation record but also in the second confirmation. These are determined by the policy of the service providing side. However, if the same service is provided, the second disclosure may be the disclosure of the confirmation record in many cases.

  In this way, when using the service, instead of disclosing information including multiple pieces of personal information such as a license for identity verification, the user associates various personal information with each other via hash values of each other. By disclosing only one personal ID, it is possible to receive the same benefits as disclosing personal information associated with the personal ID or a confirmation record using the personal information. Therefore, if the services of the present system are shared by a plurality of vendors and services, it is possible to prevent an increase in information for identifying an individual for each service or each vendor.

  Further, according to the present embodiment, once the validity of the original personal information has been confirmed and the record has been registered in the blockchain, the information (date of birth) necessary for the age confirmation can be obtained even in the first time. The disclosure of unnecessary personal information (license number, name, address, etc.) unrelated to age confirmation in order to confirm the legitimacy of the date can be prevented. As described above, according to the present embodiment, it is possible to selectively disclose the personal information associated with the personal ID, so that it is possible to control such that only the minimum information necessary for confirmation is disclosed.

  In this embodiment, since the hash value of the personal ID is registered in each block, the personal ID issued at the time of starting use is limited due to the characteristics of a block chain in which the service is not expected to be stopped due to a server down or the like. Unless invalidated by the user or administrator, it can be used permanently.

  This means that, when the personal ID is associated with the authentication information in the client device, the record registered due to the loss of the client device is not rewritten. Therefore, if the client device is lost, the personal ID may be recovered by the following method.

  As a first method, there is a method of registering a plurality of authentication members for a set of the personal ID and a device ID as the authentication information when the personal ID is assigned at the start of use of the present system. If the device is lost, the user notifies the authentication member of a new device ID. At this time, the personal ID may be reusable with a new device ID by approval of a certain number of authentication members. The method may be implemented using a blockchain ID management platform called uPort.

  More specifically, a permanent ID called uPortID, which is an address of a proxy contract, is prepared as a user key in the blockchain network for the user. Note that uPortID is created from UserAddress using PrivateKey. Here, the UserAddress corresponds to an EOA (Ethernet account) address corresponding to the user device key. In this example, the uPort device corresponding to the client device has a UserAddress (EOA) paired with the device ID and a secret key.

  Using such an Ethereum blockchain network, for example, when a user loses a uPort device, the user first connects to Ethereum with a new device and obtains a new UserAddress. Then, the new UserAddress is notified to an authentication member (a real delete member or the like) registered in advance.

  The authentication member authenticates the new UserAddress by calling the Recovery contract and confirming the user. As a result of the authentication, if a certain number or more of approvals are obtained, the new UserAddress is notified to the Controller contract and is rewritten with the old UserAddress.

  As a result, it is possible to change only the EOA corresponding to the actual device ID without changing the PortID that functions as the identification information of the client device in the Proxy contract. In this way, by dividing the EOA corresponding to the device ID and the proxy address corresponding to the data on the block chain, the connectivity with the existing data can be maintained even when the client device is replaced due to a lost device or the like. Here, uPortID corresponds to the personal ID described above.

  As another method, when a personal ID is assigned at the start of use of the present system, a registration block in which a hash value of personal information that can be used for personal identification and user authentication is registered in association with the hash value of the personal ID. There is a method of adding it to the block chain. In the method, when such personal information and a personal ID when the personal information is registered are registered in a new device, user authentication is performed on the new device using registration information equivalent to the personal information. , The personal ID in a new device may be made reusable.

  For example, SMS authentication for a telephone number, mail transmission to the mail address for a mail address, comparison with the biometric information of the current user for biometric information, and the like, enable user authentication with a new device. For example, the personal ID may be reusable by a new device.

Embodiment 3 FIG.
Next, some specific utilization examples of the above-described second personal information management system will be described. In the present embodiment, a ticket service system will be described as an example in which the above service providing system and personal information management system are used to prevent resale of tickets. FIG. 20 is a schematic configuration diagram of the ticket service system according to the third embodiment. The ticket service system shown in FIG. 20 includes a personal terminal 10A, a service providing device 21A, an entrance device 22A, and a blockchain network (hereinafter, blockchain NW) 30A.

  Here, the personal terminal 10A corresponds to the above-described user system 10. Note that the personal terminal 10A as the user system 10 of the present example may further include the functions of the above-described personal terminal 61 (such as the SNNAPP unit 611 and the IMSAPP unit 612). Further, the service providing device 21A and the entrance device 22A correspond to the above-described confirmation institution side system 20. The service providing device 21A and the entrance device 22A as the checking institution side system 20 of this example further include the functions of the service server 64 (for example, the SNS side service providing unit 641 and the target confirmation service unit 642). Is also good. More specifically, the service providing device 21A corresponds to the confirmation institution side system 20 of the institution (ticket sales company or the like) that issued the ticket information. The entrance apparatus 22A corresponds to the confirmation institution side system 20 of an institution (concert operating company or the like) that checks the entrance / exit of the ticket purchaser to the place (event venue or the like) based on the ticket information. The entrance device 22A is installed, for example, at a place where a ticket issued by the service providing device 21A is used. Note that the service providing device 21A and the entrance device 22A may belong to the confirmation institution side system 20 of the same institution.

  The blockchain NW 30A corresponds to a part of the IMS platform 63 or the ledger management system 30. Although not shown, the blockchain NW 30A implements the functions of the management system 50 (assignment of personal ID, generation of pair key, etc.) in addition to mounting the blockchain 3 usable in the present system. . In the present example, an identifier (such as uPortID described above) for identifying the creator of the block in the block chain 3 also serves as the personal ID 13D. In this case, the function of the management system 50 may be included in the personal terminal 10A.

  In this example, a ticket purchase application for performing a procedure for a user to receive a ticket purchase service using the present system is downloaded to the personal terminal 10A as a user-side application in this example. The ticket purchase application operates on the CPU of the personal terminal 10A, and causes the personal terminal 10A to execute a predetermined process of the user system 10 in the present system. In this example, it is assumed that the personal ID is assigned and the key pair is generated when the ticket purchase application is downloaded.

  It is also assumed that a ticket information management application is mounted in the service providing apparatus 21A in advance as a first service providing application in this example. Here, the ticket information management application sells to the user in response to the purchase application from the user, while examining the purchase eligibility of the ticket including the identity verification using the information in the blockchain 3 and confirming the payment, and the like. Is an application that performs procedures for The application operates on, for example, the CPU of the service providing apparatus 21A, and causes the service providing apparatus 21A to execute a predetermined process of the confirmation institution side system 20 in the present system.

  Also, it is assumed that a ticket information confirmation application is mounted in advance as a second service providing application in the present example on the entrance device 22A. Here, the ticket information confirmation application manages the entrance and exit of the user while checking the entrance and exit qualification including the identity verification using the information in the blockchain 3 in response to the entrance and exit application from the user. Is an application that performs procedures for The application operates on, for example, the CPU of the entrance device 22A, and causes the entrance device 22A to execute a predetermined process of the confirmation institution side system 20 in the present system.

  Next, the operation of the ticket service system of the present example will be described. FIG. 21 is a flowchart showing an outline of the operation of the ticket service system of the present embodiment. As shown in FIG. 21, in the ticket service system of the present example, first, a user performs personal registration with the present system (step S401A).

  In step S401A, in response to an instruction from the user, the personal terminal 10A acquires biometric information (for example, a face photograph or the like) for personal identification performed at the time of ticket purchase and at least at the time of entering the venue, Read personal information (for example, address, name, credit card number, etc.) required at the time of ticket purchase. Then, the personal terminal 10A calculates a hash value for each of these or a predetermined disclosure unit which is a combination thereof, and calculates a hash value for the personal ID 13D assigned to the user. It should be noted that individual ID 13D instead of individual ID_Hash 31D may be used as it is as information for identifying an individual in each block. In that case, the personal ID_hash 31D may be replaced with the personal ID in the subsequent processing, and the reliability confirmation processing for the personal ID_hash 31D may be omitted. The same applies to the above embodiment.

  In this example, it is assumed that a set of an address and a name is used as user information at the time of ticket purchase in a ticket purchase service provided by the service providing apparatus 21A, and that a credit card number is used as settlement information in the service. I have. As described above, it is assumed that the biometric information is used as personal identification information performed at the time of ticket purchase and at least at the time of entering the venue.

  Hereinafter, in order to simplify the description, a set of an address and a name may be described as personal information 14D (1), and the hash value thereof may be described as personal information Hash32D (1). Further, the credit card number as the settlement information may be described as personal information 14D (2), and the hash value thereof may be described as personal information Hash32D (2). Further, the biometric information may be described as personal information 14D (3), and the hash value thereof may be described as personal information Hash32D (3).

  When the personal terminal 10A calculates hash values (personal information Hash32D (1), (2), (3)) for the personal information 14D (1), (2), (3) and the personal ID 13D, respectively, The block chain NW 30A requests the block chain NW 30A to add a registration block using the attached personal signature 33D as registration information, and causes the block chain 3 to register the request.

  When a block is registered in the block chain 3, the personal terminal 10A receives, from the block chain NW 30A, a transaction ID (TxID) for identifying a block of information related to the personal ID 13D in the block chain 3. In step S401A, TxID = 1 indicating that this is the first registered block in the personal ID 13D is received.

  In the ticket service system of the present example, a block in the block chain 3 is specified using this TxID. Therefore, the personal terminal 10A holds the TxID in its own personal ID 13D obtained from the blockchain NW 30A as a registration history. The personal terminal 10A may hold, for example, the TxID of the registration block and at least the TxID of the latest confirmation recording block as the registration history.

  In this way, when the registration block in which the hash value of the personal information including the biometric information is associated with the hash value of the personal ID 13D together with the signature 33D of the individual is registered in the blockchain 3, the personal registration is completed.

  When the personal registration is completed, the user then applies for a ticket purchase to the service providing apparatus 21A (step S402A). In step S402A, the personal terminal 10A transmits, for example, a ticket purchase application including the personal ID 13D and information on the ticket to be purchased to the service providing apparatus 21A.

  The service providing apparatus 21A, which has received the ticket purchase application, uses the user's registration information in the blockchain 3 based on the personal ID 13D included in the ticket purchase application and the personal information directly disclosed by the applicant to make a purchase. The qualification is confirmed (step S403A). The purchase qualification at the personal information management system level in this example includes the personal information necessary for ticket purchase, the hash value of which is registered in the blockchain 3 together with the biometric information used for identity verification. The information (the above-described personal information 14D (1) (2)) is disclosed. However, some of the personal information (in this example, the personal information 14D (1)) can be replaced by disclosure of a past purchase record registered in the blockchain 3. It should be noted that the purchase qualification at the ticket service system level further includes information that the settlement is normally performed by the disclosed information.

  Also, for example, if you want to confirm your identity not only at the time of admission but also at the time of purchase, the above-mentioned purchase qualification and the personal information disclosed to the applicant or the individual disclosed at the time of past purchase It is also possible to add that the identity of the information can be confirmed. Note that these are merely examples, and may be freely determined by the service provider.

  The service providing apparatus 21A of the present example provides the requesting user (applicant) with at least one time of the personal information 14D (1) including the past purchase record as the purchase qualification confirmation processing of the present example. At least a request for disclosure and disclosure of personal information 14D (2) at the time of purchase is made, and the validity of the disclosed information is confirmed (step S403A). The service providing device 21A may check the disclosed information with registered information (including a confirmation record) in the blockchain 3 to confirm the validity of the information. Note that the collation with the registration information includes the confirmation of the consistency of the original data and the confirmation of the reliability of the registration information itself as described above.

  It should be noted that the service providing apparatus 21A can also confirm the identity of the applicant (more specifically, the disclosing person who disclosed the above two pieces of personal information) in the purchase qualification confirmation process. In this case, the service providing device 21A further causes the personal terminal 10A to further disclose the current biometric information of the applicant, and compares the hash value with the personal information Hash32D (3) registered in the registration block. Identity verification may be performed. Note that, depending on the biometric information, the information at the time of registration and the current information may not completely match, and it may be difficult to compare and match with a hash value. In such a case, the original data (biometric information at the time of registration) of the personal information Hash32D (3), which is a hash value of the registered biometric information, is disclosed, and collation with the current biometric information of the applicant is performed. Just do it. Note that the above-described identity confirmation can be performed on the personal terminal 10A (more specifically, a ticket purchase application including a part of the function of the confirmation unit 202 of the confirmation institution side system).

  The service providing device 21A issues a ticket to the applicant when the applicant's purchase eligibility is confirmed in this way. When the service providing apparatus 21A issues the ticket after the purchase qualification is confirmed, the ticket providing information (for example, information that the ticket has been issued, the issued ticket information, and the confirmation record of the purchase qualification at the time of the ticket issuance) is used as the confirmation information 34D as the confirmation information 34D. The confirmation recording block including the information shown in FIG. 4 is registered in the block chain 3 (step S404A). The confirmation record block includes a hash value (personal ID_Hash31D) of the disclosed personal ID 13D, and a signature 35D of a confirming organization that is a ticket information issuing source is attached to the personal ID_Hash31D and the confirmation information 34D. You. The issued ticket information itself may be held on the service providing apparatus 21A side, and an identifier (service ID) for identifying the ticket information may be registered in the confirmation recording block.

  When the registration of the confirmation record block is completed, the service providing apparatus 21A returns the service ID and the TxID of the confirmation record block in which the service ID is recorded as issued ticket information to the requesting personal terminal 10A.

  Next, consider a case where the user enters the venue using the ticket issued in this manner. In this example, the user only has to make an entry application to the entrance device 22A (step S405A). In step S405A, the personal terminal 10A sends an admission application including, for example, the personal ID 13D and the ticket information (the service ID and the TxID of the confirmation recording block in which the information is recorded) received from the service providing apparatus 21A to the admission apparatus. 22A.

  The admission device 22A that has received the admission application confirms the admission qualification by using the registration information in the user's blockchain 3 based on the information included therein (step S406A). As the entrance qualification at the personal information management system level in this example, the confirmation record block including the ticket issuance information for the user is registered in the blockchain 3 and is disclosed or referred to the applicant at the time of purchase. It says that the identity of the owner of personal information can be confirmed. Note that these are merely examples, and may be freely determined by the service provider.

  The admission device 22A checks the presence / absence of a confirmation record block including ticket issuance information from the disclosed ticket information and the validity of the registration information, as well as confirms the identity of the applicant from the applicant as the admission qualification confirmation processing of this example. I do. The validity of the registration information of the confirmation recording block may be confirmed using the public key of the confirmation organization that is the issuer of the ticket information. The method of identity verification may be the same as the method described above.

  When the entrance qualification of the applicant is confirmed in this way, the entrance apparatus 22A performs an entrance process such as opening a gate (not shown) or outputting information indicating entrance permission. When the entrance qualification is confirmed and the entrance process is performed, the entrance device 22A may register a confirmation record block including the entrance information indicating that the entrance process has been performed in the block chain 3 as the confirmation information 34D (step S407A). ). The confirmation record block includes a hash value (personal ID_Hash31D) of the disclosed personal ID 13D, and a signature 35D of a confirming organization that is a ticket information issuing source is attached to the personal ID_Hash31D and the confirmation information 34D. You.

  In addition, at the time of re-entry, the entry processing may be performed after confirming the identity in the same manner as in the entry application. Note that it is also possible to register the exit record in the blockchain 3 when exiting halfway, and to perform a collation process with the information.

  FIG. 22 to FIG. 25 are sequence diagrams showing an example of the flow of processing at the time of personal registration, at the time of purchase application, and at the time of entrance application.

  FIG. 22 is a sequence diagram showing an example of the flow of processing at the time of personal registration. It is assumed that the personal ID 13D is assigned and the pair key is issued before the personal registration.

  In the example shown in FIG. 22, first, the user issues a personal information registration instruction to the personal terminal 10A (step S501). When the personal information registration instruction is received, the personal terminal 10A acquires the personal information 14D (1) (2) (3), calculates a hash value for each of them, and obtains the personal information Hash32D (1) (2) ( 3) is obtained (step S502).

  Next, the personal terminal 10A transmits a block addition request including the personal ID 13D, the personal information Hash32D (1) (2) (3), and the signature 33D of the principal to the blockchain NW 30A (step S503). .

  In the block chain NW 30A, a block (registered block) including information included in the block addition request as registration information is added to the block chain 3 (step S504).

  Upon receiving the block addition response from the block chain NW 30A (step S505), the personal terminal 10A holds the TxID of the added block (in this example, TxID = 1) in the registration history and prepares for the subsequent disclosure request. Then, the personal information at the time of registration, that is, the personal information 14D (1) (2) (3), which is the original data at the time of registration of the registration block, is stored (step S506). Thereafter, a completion notification is given to the user (step S507).

  FIGS. 23 and 24 are sequence diagrams illustrating an example of the flow of processing at the time of purchase application. FIG. 24 is a continuation of FIG. In the example shown in FIGS. 23 and 24, first, the user issues a purchase application instruction to the personal terminal 10A (step S511). At this time, information on a ticket to be purchased may be specified.

  Upon receiving the purchase application instruction, personal terminal 10A transmits a purchase application including personal ID 13D to service providing apparatus 21A (step S512).

  The service providing apparatus 21A that has received the purchase application from the personal terminal 10A transmits a personal information disclosure request A specifying the personal information 14D (1) to the requesting personal terminal 10A (step S513).

  Upon receiving the personal information disclosure request A, the personal terminal 10A, for example, searches the registration history to disclose the personal information 14D (1) in the ticket service system in the past and confirm the equivalent target confirmation (this In the example, purchase qualification may be confirmed).

  If there is no disclosure of the personal information 14D (1) in the past and no equivalent target confirmation, the personal terminal 10A discloses the personal information 14D (1) with the permission of the user. In this example, the personal terminal 10A provides personal information disclosure including the personal information 14D (1) and the TxID of the registration block including the information indicating the validity (the personal information Hash32D (1) and the signature 33D of the person). The response A is transmitted to the service providing apparatus 21A (step S514).

  The service providing apparatus 21A that has received the personal information disclosure response A acquires a registration block of the personal information 14D (1) based on the TxID included in the personal information disclosure response A (step S515). Then, the service providing apparatus 21A checks the reliability of the registration information of the registration block and the consistency of the original data (between the disclosed personal information 14D (1) and the original data of the personal information Hash32D (1) in the registration block). Confirmation of consistency is performed to confirm the validity of the disclosed personal information 14D (1) (step S516). At this time, the service providing apparatus 21A registers the record of the purchase qualification confirmation A indicating that the personal information 14D (1) has been disclosed and its validity has been confirmed as a confirmation record block and registers it in the block chain 3. May be. As a result, the TxID of the confirmation recording block (TxID = 2 in this example) is received (steps S517 and S518).

  On the other hand, if personal information 14D (1) has been disclosed in the past or an equivalent target confirmation (purchase qualification confirmation in this example) has been made in the past, personal terminal 10A replaces personal information 14D (1) with the confirmation at that time. The personal information disclosure response A including the TxID of the recording block (for example, TxID = 2 described above or TxID = 4 described later) is transmitted to the service providing apparatus 21A (step S519).

  The service providing apparatus 21A that has received the personal information disclosure response A, based on the TxID included in the personal information disclosure response A, confirms the validity of the personal information 14D (1) and the equivalent service qualification (ticket purchase qualification). Is obtained (step S520). Then, the service providing apparatus 21A verifies the reliability of the registration information of the confirmation recording block, and verifies (conjugates) the confirmation result indicated by the registration information (step S521).

  In this example, the disclosure of the personal information 14D (1) can be omitted if the reliability of the registered information is confirmed (author certification and non-falsification certification) for the confirmation record block registered by the own institution. I do. Regarding the confirmation in step S521, the service providing apparatus 21A also stores the record of the purchase qualification confirmation A indicating that the validity of the personal information 14D (1) has been confirmed by the confirmation result of the designated confirmation record block in the confirmation record block. May be registered in the blockchain 3. As a result, the TxID of the confirmation recording block is received (step S522, step S523).

  When the disclosure and / or validity check of the personal information 14D (1) is completed, the service providing apparatus 21A discloses the personal information specifying the personal information 14D (2) as the payment information to the requesting personal terminal 10A. The request B is transmitted (step S524). In this example, disclosure of the personal information 14D (2) as the settlement information in the confirmation record is not permitted.

  Upon receiving the personal information disclosure request B, the personal terminal 10A discloses the personal information 14D (2) with the permission of the user. Also in this example, the personal terminal 10A provides the personal information disclosure including the personal information 14D (2) and the TxID of the registration block including the information indicating the validity (such as the personal information Hash32D (2) and the signature 33D of the person). The response B is transmitted to the service providing apparatus 21A (step S525).

  The service providing apparatus 21A that has received the personal information disclosure response A performs the same validity confirmation as when the personal information 14D (1) is received, and adds the record to the blockchain 3 (steps S526 to S529).

  The service providing apparatus 21A completes the confirmation of the purchase qualification in response to the fact that the validity of the personal information 14D (1) has been confirmed at least in this way and the valid personal information 14D (2) has been obtained. Then, the service providing apparatus 21A issues the specified ticket to the user (step S530). At this time, the service providing apparatus 21A registers a confirmation recording block including ticket issuance information indicating that the ticket has been issued in the block chain 3 (step S531). As a result, the TxID of the confirmation recording block (for example, TxID = 3) is received (step S532).

  The ticket issuance information includes information related to the issuance of the current ticket in the service providing apparatus 21A (information of the user of the issuance destination, TxID of a block required at the time of entry, etc. (issue record TxID, block registered in the issuance process, It is assumed that a service ID associated with the referenced block (TxID) or personal information) is included. In addition, the service providing apparatus 21A holds information related to the issue of the current ticket in association with such a service ID (step S533).

  When the above processing is completed, the service providing apparatus 21A sets the purchase permission for the purchase application, the service ID for identifying information relating to the issuance of the current ticket, and the TxID in which the issuance record of the current ticket is registered. A reply is sent to the requesting personal terminal 10A together with the (issue record TxID in the figure) (step S534).

  The personal terminal 10A that has received the purchase permission stores the service ID and the issuance record TxID received together with the purchase permission as ticketing ticket information (step S535). Thereafter, a completion notification is given to the user (step S536).

  FIG. 25 is a sequence diagram illustrating an example of the flow of a process at the time of applying for entrance. In the example shown in FIG. 25, first, the user issues an entry application instruction to the personal terminal 10A (step S541). At this time, a service ID may be specified as ticketing ticket information for applying for admission.

  Upon receiving the entry request, the personal terminal 10A transmits an entry request including the personal ID 13D and the service ID to the entry device 22A (step S542). This may be performed by information communication by touching a reader device included in the entrance device 22A actually installed in the venue.

  The admission device 22A that has received the purchase application from the personal terminal 10A transmits a service ID validity confirmation including the personal ID 13D and the service ID to the service providing device 21A (step S543). Note that the service ID validity check may further include information on an event or a venue that is being held.

  The service providing device 21A that has received the service ID validity confirmation from the entrance device 22A confirms the validity of the service ID (step S544). The service providing apparatus 21A may confirm whether information relating to issuance of a ticket for an event in which the entrance apparatus 22A is installed is registered for the received service ID.

  Then, the service providing apparatus 21A acquires the confirmation record block in which the issue record is registered based on the issue record TxID associated with the service ID held by itself, and confirms the reliability of the registration information. Then, the validity of the issuance record is confirmed (step S545 to step S546). When the validity of the issuance record in the confirmation record block is confirmed, the service providing device 21A returns a service ID validity result (OK) to the entrance device 22A (step S547). If the service providing apparatus 21A cannot confirm the validity of the issuance record, it returns a service ID validity result (NG) to the entrance apparatus 22A.

  If the service ID validity result is NG, the entrance device 22A that has received the service ID validity result returns an entry prohibition to the personal terminal 10A (step S548). At this time, the entrance device 22A may also transmit that the service ID is invalid. The personal terminal 10A, which has received the entry prohibition, notifies the user of the prohibition and ends the process (step S549).

  On the other hand, if the service ID validity result is OK, the entrance device 22A transmits the biometric authentication request D to the personal terminal 10A (step S550). Note that the following example is an example in which the personal terminal 10A uses the biometric authentication in the blockchain 3 to perform identity verification, but the same processing may be performed by the entrance device 22A or the like.

  The personal terminal 10A that has received the biometric authentication request D searches the registration history held by itself and acquires the TxID of the registration block registered at the time of personal registration (step S551), and obtains the registration information (particularly, The personal information Hash32D (3), which is the hash value of the biometric information, is obtained.

  Then, the personal terminal 10A confirms the reliability of the acquired registration information (step S552) and confirms the consistency between the personal information at the time of registration held by itself and the original data of the registration information (step S553). It confirms that the personal information 14D (3) held by the user is the biometric information when registered in the blockchain 3. In this confirmation, a registration information reference request in which the TxID of the registered block is designated as the reference TxID and the hash value calculated from the biometric information at the time of registration as the comparison target is designated as the comparison source is transmitted to the block chain NW 30A. It is also possible to do this.

  When the legitimacy (personal registration authentication) of the personal information 14D (3) held by itself is confirmed in this way, the personal terminal 10A further transmits the current (at the time of application for admission) the biometric information of the user. It acquires and confirms the identity of both (step S554). Note that the personal terminal 10A may collate the two in the form of a hash value. Then, the personal terminal 10A returns the result of step S554 to the entrance device 22A as a biometric authentication result (step S555).

  If the biometric authentication result is received, the entrance device 22A returns an entry prohibition to the personal terminal 10A if the biometric authentication result is NG (step S556). At this time, the entrance device 22A may also transmit a message indicating that there is a biometric authentication error. The personal terminal 10A that has received the entry prohibition notifies the user of the prohibition and ends the process (step S557).

  On the other hand, if the biometric authentication result is OK, the entrance device 22A adds the current authentication record to the block chain 3 as a confirmation record block (steps S558 and S559), and returns an entry permission to the personal terminal 10A. (Step S560). The personal terminal 10A that has received the entry permission notifies the user of the permission and ends the process (step S561).

  As described above, according to the present embodiment, a ticket service including identity verification can be realized reliably and quickly without omission. In addition, since it is not necessary to visit the staff to confirm the identity, it leads to cost reduction.

  In the present embodiment, personal information for performing a target confirmation including a personal identification by using information in the blockchain 3 associated with one personal ID in a series of ticket services from ticket sales to entrance determination. The example in which the management system is applied has been described. However, when a service is to be provided using the SNS platform, the service can be provided by using the ID transfer method described in the service providing system of the first embodiment when providing the service. , SNS and IMS can be linked with each other.

  FIG. 26 is a block diagram illustrating another configuration example of the ticket service system according to the present embodiment. The ticket service system shown in FIG. 26 includes a personal terminal 10B, a service providing device 21B, an entrance device 22B, and a blockchain NW 30B.

  The personal terminal 10B includes an SNS application unit 711B and an IMS application unit 712B.

  The service providing apparatus 21B includes an SNS-side service providing unit 721B and a first target confirmation service unit 722B.

  The entrance device 22B includes a second target confirmation service unit 731B and a determination unit 732B.

  The SNS application unit 711B performs processing performed by the SNSAPP unit 611 according to the first embodiment and processing related to service provision performed by the personal terminal 10A according to the third embodiment (an object corresponding to the processing performed by the confirmation unit 202). Processing other than the processing related to confirmation and record registration). Specifically, the SNS application unit 711B provides various processes and interfaces for a user of the personal terminal 10B and a user of the present system to use a predetermined SNS.

  The IMS application unit 712B performs a corresponding process performed by the IMSAPP unit 612 of the first embodiment, and a process related to target confirmation and record registration performed by the personal terminal 10A of the third embodiment. The IMS application unit 712B specifically provides various processes and interfaces for a user of the personal terminal 10B and a user of the present system to use a predetermined IMS.

  The SNS-side service providing unit 721B performs processing other than the target confirmation, out of the processing related to the service provision performed by the service providing apparatus 21A of the third embodiment. Note that the SNS-side service providing unit 721B of this example provides a ticket service on the SNS. Specifically, the SNS-side service providing unit 721B provides a service to the user by exchanging information with the SNS application unit 711B using the SNS platform.

  The first target confirmation service unit 722B performs processing related to target confirmation among processing related to service provision performed by the service providing apparatus 21A of the third embodiment. Specifically, the first target confirmation service unit 722B confirms the target of the user by exchanging information with the IMS application unit 712B using the IMS platform.

  The second target confirmation service unit 731B performs processing related to target confirmation among the processing related to service provision performed by the entrance device 22A of the third embodiment. Specifically, the second target confirmation service unit 731B confirms the target of the user by exchanging information with the IMS application unit 712B using the IMS platform.

  The determination unit 732B performs a process other than the target confirmation, out of the process related to the service provision performed by the entrance device 22A of the third embodiment. The determination unit 732B determines whether or not the user can enter based on the result of the target confirmation by the second target confirmation service unit 731B, for example.

  In such a configuration, the IMS application unit 712B causes at least the first target confirmation service unit 722B to acquire the SNS-side service providing unit 721B acquired using at least a function provided by the SNS platform by a predetermined method. May transmit SNS_ID, which is information that can identify a user on the SNS platform, together with information that can identify the result of user target confirmation.

  The first target confirmation service unit 722B associates the SNS_IDB received from the IMS application unit 712B with the result of the target confirmation of the user specified by the SNS_ID and notifies the SNS side service providing unit 721B of the correspondence. Is also good.

  Further, the SNS-side service providing unit 721B may provide a ticket purchase service to the user based on the result of the user's target confirmation notified from the first target confirmation service unit 722B.

  In this example, the IMS includes two or more nodes 301B, a registration unit 102B, a disclosure unit 103B, a target confirmation unit 2021B, and a record registration unit 2022B.

  The node 301B corresponds to the ledger management node 301, and includes a block chain (more specifically, a block chain NW30B) to which a new block is added through processing according to a predetermined consensus algorithm in which two or more nodes participate. Constitute.

  The registration unit 102B stores, in the blockchain, target confirmation information that is personal information disclosed by the user and that is necessary for predetermined target confirmation, which is any of personal identification, user authentication, and eligibility confirmation. Register the first block including the hash value.

  Upon receiving the request for disclosure of personal information, the disclosure unit 103B reads out the requested type of personal information from a predetermined storage unit (not shown) and transmits it to the request source. Alternatively, instead of the requested type of personal information, information capable of specifying the second block including the record of the past target confirmation performed using the personal information may be transmitted.

  The target confirmation unit 2021B verifies the validity of the target confirmation information disclosed by the user using a block in the block chain, and then performs the target confirmation based on the disclosed target confirmation information.

  The record registration unit 2022B registers a second block including a record of object confirmation or service provision in the block chain.

  In this example, the IMS application unit 712B has a registration unit 102B as a part of the IMS, and the first target confirmation service unit 722B and the second target confirmation service unit 731B are each configured as a part of the IMS. Assume that it has a confirmation unit 2021B and a record registration unit 2022B.

  In such a configuration, the IMS application unit 712B stores the identifier of the user and the hash value of the first target confirmation information that is the biometric information disclosed by the user in the blockchain via the registration unit 102B. A first block including a hash value of second target confirmation information, which is predetermined personal information disclosed by the user, may be registered.

  Further, the first target confirmation service unit 722B may request the user to disclose the second target confirmation information via the target confirmation unit 2021B, and perform the target confirmation based on the obtained information. .

  Further, when the second target confirmation service unit 731B receives the entrance application from the user, the second target confirmation service unit 731B provides the user with the information capable of specifying the second block and the second block at the time of the first block registration via the target confirmation unit 2021B. The disclosure of the first target confirmation information and the current first target confirmation information may be requested, and a predetermined eligibility check including a personal identification may be performed based on the disclosed information.

  In addition, when the first target confirmation service unit 722B and the second target confirmation service unit 731B provide the target confirmation and some services, the first target confirmation service unit 722B and the second target confirmation service unit 731B transmit the target confirmation or the service provision to the block chain via the record registration unit 2022B. A second block including a record may be registered.

  According to such a configuration, it is possible to provide a ticket service with target confirmation on the SNS with only necessary minimum disclosure of personal information. The other points are the same as those of the service providing system of the first embodiment and the ticket service system of the third embodiment.

  Further, the service to which the application is applied is not limited to the ticket service.

  For example, using a smart key to lock / unlock facilities and rooms, issuing a smart key and managing entry / exit facilities, a wearable device or mobile terminal in which biometric information is registered, etc. A voting service, a commuter pass fare management service at a ticket gate using a wearable device or mobile terminal in which biometric information is registered, and the like are also conceivable.

Examples of a method of applying the personal information management system to the facility management service include the following.
-At the start of use, a hash value of biometric information for personal identification is registered in a blockchain together with a personal ID together with personal information required for the service (personal registration).
-At the time of reservation, issue an electronic key after confirming the identity and register the record in the blockchain.
・ At check-in, the electronic key issued after confirming the identity is validated and its record is registered in the blockchain.
At the time of electronic unlocking / locking, the record is registered in the blockchain via a locking device or the like.
・ At check-out, the issued electronic key will be invalidated and liquidation will be performed based on the records on the blockchain.

As a method of applying the personal information management system to the above voting service, for example, the following method can be mentioned.
-At the start of use, a hash value of biometric information for personal identification is registered in a blockchain together with a personal ID together with personal information required for the service (personal registration).
-When applying for an electronic voting right, confirm the identity and information required for issuing the electronic voting right, issue the electronic voting right, and register the issuance record in the blockchain.
-At the time of voting, the voting device accepting the voting accepts the voting after confirming the identity and the issuance record. In addition, a voting record including voting contents (encryption) is registered in the blockchain.
-At the time of counting votes, the counting device performs counting based on the voting records on the blockchain.

Examples of a method of applying the personal information management system to the commuter pass fare management service include the following.
-At the start of use, biometric information is registered in the wearable device or mobile terminal owned by the user.
At the time of applying for a commuter pass, an issuance record including a device ID for which biometric information is registered and commuter pass issuance information is registered in the blockchain. At this time, the device ID may be regarded as a personal ID or may be separately assigned.
-When passing a ticket gate (boarding), check the issuance record on the blockchain and the immediately preceding record based on the device ID obtained from the wearable device or mobile terminal that has been biometrically authenticated and the personal ID notified when the commuter pass is issued. , To determine the admission. Also, the entry record is registered in the blockchain.
-When passing through a ticket gate (getting off), check the issuance record on the blockchain and the immediately preceding record based on the device ID obtained from the wearable device or mobile terminal that has been biometrically authenticated and the personal ID notified when the commuter pass is issued. It is determined whether participation is possible. Also, the entry record is registered in the blockchain.

  In the example shown above, the entrance device receives an application for entrance from the user, and based on the result of the target confirmation, an example in which the admission device determines whether or not the application of the user is acceptable is described. It is also possible to replace with a license judging device installed at a place where a license issued by the service providing device and indicating the eligibility of receiving the service is used. In such a case, as shown in FIG. 26, in the permit judging device, the second object confirmation service unit receives an application for admission or an application for receiving the profit obtained by the permit from the user, and Alternatively, whether or not the user can apply may be determined based on the result of the target confirmation by the second target confirmation unit. Here, the permit may be an electronic ticket, an electronic key, an electronic voting ticket, or a commuter pass.

  FIG. 27 is a schematic block diagram illustrating a configuration example of a computer according to each embodiment of the present invention. The computer 1000 includes a CPU 1001, a main storage device 1002, an auxiliary storage device 1003, an interface 1004, a display device 1005, and an input device 1006.

  Servers and other devices included in the systems of the above embodiments may be implemented in the computer 1000. In that case, the operation of each device may be stored in the auxiliary storage device 1003 in the form of a program. The CPU 1001 reads out a program from the auxiliary storage device 1003, expands the program in the main storage device 1002, and performs a predetermined process in each embodiment according to the program. Note that the CPU 1001 is an example of an information processing device that operates according to a program, and in addition to a CPU (Central Processing Unit), for example, an MPU (Micro Processing Unit), an MCU (Memory Control Unit), a GPU (Graphics Processing Unit), and the like. May be provided.

  The auxiliary storage device 1003 is an example of a non-transitory tangible medium. Other examples of the non-transitory tangible medium include a magnetic disk, a magneto-optical disk, a CD-ROM, a DVD-ROM, and a semiconductor memory connected via the interface 1004. When the program is distributed to the computer 1000 via a communication line, the computer that has received the program may load the program into the main storage device 1002 and execute a predetermined process in each embodiment.

  Further, the program may be for realizing a part of a predetermined process in each embodiment. Furthermore, the program may be a difference program that implements a predetermined process in each embodiment in combination with another program already stored in the auxiliary storage device 1003.

  The interface 1004 transmits and receives information to and from another device. The display device 1005 presents information to the user. Further, the input device 1006 receives input of information from a user.

  In addition, some components of the computer 1000 can be omitted depending on the processing content in the embodiment. For example, if the computer 1000 does not present information to the user, the display device 1005 can be omitted. For example, if the computer 1000 does not accept information input from a user, the input device 1006 can be omitted.

  In addition, some or all of the components of the above embodiments are implemented by a general-purpose or dedicated circuit (Circuitry), a processor, or a combination thereof. These may be constituted by a single chip, or may be constituted by a plurality of chips connected via a bus. In addition, some or all of the components of each of the above embodiments may be realized by a combination of the above-described circuit and the like and a program.

  When some or all of the components of each of the above embodiments are implemented by a plurality of information processing devices and circuits, the plurality of information processing devices and circuits may be centrally arranged or distributed. It may be arranged. For example, the information processing device, the circuit, and the like may be implemented as a form in which each is connected via a communication network, such as a client and server system or a cloud computing system.

  Next, the outline of the present invention will be described. FIG. 28 is a block diagram showing an outline of the service providing system of the present invention. As shown in FIG. 28, the service providing system of the present invention includes a personal terminal 71 and a service server 72.

  The personal terminal 71 includes an SNS application unit 711 and an IMS application unit 712. Further, the service server 72 includes an SNS-side service providing unit 721 and a target confirmation service unit 722.

  The SNS application unit 711 (for example, the SNSAPP unit 611) provides various processes and interfaces for a user to use a predetermined SNS.

  The IMS application unit 712 (for example, the IMSAPP unit 612) provides various processes and interfaces for a user to use a predetermined IMS.

  The SNS side service providing unit 721 (for example, the SNS side service providing unit 641) provides a service to the user by exchanging information with the SNS application unit 711 using the SNS platform.

  The target confirmation service unit 722 (for example, the target confirmation service unit 642) confirms the target of the user by exchanging information with the IMS application unit 712 using the IMS platform.

  In such a configuration, the IMS application unit 712 causes the target confirmation service unit 722 to acquire the SNS-side service providing unit 721 acquired using at least a function provided from the SNS platform by a predetermined method. The SNS_ID that is the information that can identify the user is transmitted together with the information that can identify the result of the user's target confirmation. Then, the target confirmation service unit 722 notifies the SNS side service providing unit 721 of the SNS_ID received from the IMS application unit 712 and the result of the target confirmation of the user specified by the SNS_ID in association with each other.

  As a result, it is possible to provide a service with target confirmation on the SNS only by disclosing necessary minimum personal information.

  As described above, the present invention has been described with reference to the exemplary embodiments and examples, but the present invention is not limited to the exemplary embodiments and examples. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.

  According to the present invention, any one that provides a service to a user after performing one of identity confirmation, user authentication, and eligibility confirmation can be suitably applied.

600 service providing system 61 personal terminal 611 SNSAPP unit 612 IMSAPP unit 62 SNS platform 63 IMS platform 64 service server 641 SNS side service providing unit 642 target confirmation service unit 643 ID cooperation information storage unit 1 client device 2 confirming organization device 3 block chain 4 Network 11D, 21D Private key 12D, 22D Public key 13D Personal ID
14D personal information 31D personal ID_Hash
32D Personal Information Hash
33D Signature of the person 34D Confirmation information 35D Signature of the confirmation organization 100 Personal information management system 10 User side system 101 Data storage unit 102 Registration unit 103 Disclosure unit 104 Authentication unit 20 Verification institution side system 201 Data storage unit 202 Confirmation unit 221 Data acquisition Part 222 registration information reliability confirmation part 223 original data consistency confirmation part 224 personal information validity confirmation part 225 result output part 226 confirmation record registration part 30 ledger management system 301 ledger management node 311 registration information reception part 312 block generation part 313 block Sharing unit 314 Information storage unit 315 Block verification unit 40 Network 50 Management system 501 Data storage unit 502 Personal ID allocation unit 10A, 10B Personal terminal 21A, 21B Service providing device 22A, 22B Entrance device 30A , 30B Blockchain NW
711B SNS application unit 712B IMS application unit 721B SNS side service providing unit 722B First target confirmation service unit 731B Second target confirmation service unit 732B Judgment unit 102B Registration unit 103B Disclosure unit 2021B Target confirmation unit 2022B Record registration unit 301B Node 1000 Computer 1001 CPU
1002 Main storage device 1003 Auxiliary storage device 1004 Interface 1005 Display device 1006 Input device 71 Personal terminal 711 SNS application unit 712 IMS application unit 72 Service server 721 SNS side service providing unit 722 Target confirmation service unit

A service providing system according to the present invention includes a service server for providing a predetermined service, and a personal terminal used by a user to whom the service is provided, and the personal terminal uses a predetermined SNS by the user. An SNS application unit that provides various processes and interfaces for performing various processes and an interface, and an IMS application unit that provides various processes and interfaces for a user to use a predetermined IMS. The service server uses an SNS platform. Object confirmation for confirming the target of the user by exchanging information with the SNS side service providing unit that provides the service to the user by exchanging information with the SNS application unit and the IMS application unit using the IMS platform Service department and the IMS application The service unit provides the target confirmation service unit with information that the SNS-side service providing unit can identify the user on the SNS platform by using a predetermined method at least using the function provided by the SNS platform. A certain SNS_ID is transmitted together with information that can specify the result of the user's target confirmation, and the target confirmation service unit transmits the SNS_ID received from the IMS application unit and the result of the user's target confirmation specified by the SNS_ID. The IMS notifies the SNS side service providing unit in association with the two or more nodes that constitute a block chain in which a new block is added through processing according to a predetermined consensus algorithm in which two or more nodes participate, The personal information disclosed by the user to the blockchain, A registration unit for registering a first block including a hash value of the target confirmation information, which is personal information necessary for predetermined target confirmation, which is either authentication or eligibility confirmation; and a validity check of the target confirmation information disclosed by the user. And a target confirmation unit that performs target confirmation based on the disclosed target confirmation information after verifying the property using the blocks in the block chain. The IMS application unit includes a registration unit as a part of the IMS. The object confirmation service unit has an object confirmation unit as a part of the IMS, and the IMS further includes a record registration unit for registering a second block including a record of the object confirmation in the block chain. When the confirmation unit requests the user to disclose the target confirmation information, and the user discloses information that can specify the second block instead of the target confirmation information, the disclosed information is displayed. Performed target confirmation with reference to the target confirmation of recording in the second block to be al identified, target confirmation service unit is characterized by further comprising a recording registration unit as part of the IMS.

Further, the service providing system according to the present invention includes a personal terminal used by a user, a service providing device for providing a predetermined service to the user, and a license issued by the service providing device and indicating a qualification for receiving the service. The personal terminal includes an SNS application unit that provides various processes and an interface for the user to use a predetermined SNS, The service providing device includes an IMS application unit that provides various processes and an interface for using the IMS. The service providing device provides an SNS that provides a service to a user by exchanging information with the SNS application unit using an SNS platform. Side service providing unit and IMS application using IMS platform The first object confirmation service unit for confirming the object of the user by exchanging information with the application unit, and the license judging device is an application for admission from the user or an application for receiving the profit obtained by the permit. Upon receiving the information, the second object confirmation service unit for confirming the object of the user by exchanging information with the IMS application unit using the IMS platform, and based on the result of the object confirmation by the second object confirmation unit. The IMS application unit obtains at least the first target confirmation service unit using at least a function provided from the SNS platform by a predetermined method. The SNS-side service providing unit uses the SNS_ID, which is information that can identify the user on the SNS platform, The first object confirmation service unit associates the SNS_ID received from the IMS application unit with the result of the object confirmation of the user identified by the SNS_ID, and transmits the result of the user's object confirmation together with the identifiable information. To the SNS side service providing unit, and the SNS side service providing unit provides a service to the user based on the result of the user's target confirmation notified from the first target confirmation service unit. Two or more nodes constituting a block chain to which a new block is added through a process according to a predetermined consensus algorithm in which the above nodes participate, and personal information disclosed by a user to the block chain, Hash value of the target confirmation information, which is the personal information necessary for predetermined target confirmation, which is either identity verification, user authentication or eligibility verification A registration unit that registers the first block including the first block, and verifies the validity of the target confirmation information disclosed by the user using the blocks in the block chain, and performs the target confirmation based on the disclosed target confirmation information. An object confirmation unit, and a record registration unit for registering a second block including a record of object confirmation or service provision in the block chain, wherein the IMS application unit has a registration unit as a part of the IMS, Each of the first object confirmation service unit and the second object confirmation service unit has an object confirmation unit and a record registration unit as part of the IMS, and the IMS application unit uses the object confirmation unit and the block chain via the registration unit for the blockchain. The identifier of the user, the hash value of the first target confirmation information that is the biometric information disclosed by the user, and the predetermined personal information disclosed by the user. The first block including the hash value of the second object confirmation information is registered, and the first object confirmation service unit requests the user to disclose the second object confirmation information via the object confirmation unit. Then, the target confirmation is performed based on the obtained information, and the second target confirmation service unit provides the user with the information capable of specifying the second block and the information at the time of registration of the first block through the target confirmation unit. Requests the disclosure of the first target confirmation information and the current first target confirmation information, performs a predetermined eligibility check including identity verification based on the disclosed information, and the target confirmation unit notifies the user As a result of requesting disclosure of the target confirmation information, when information that can specify the second block is disclosed by the user instead of the target confirmation information, the target confirmation in the second block specified from the disclosed information is disclosed. Object confirmation may be performed with reference to the record .

A service providing method according to the present invention is a personal terminal used by a user to whom a service is provided, an SNS application unit that provides various processes and interfaces for the user to use a predetermined SNS, Process and interface for a user to use a predetermined IMS including two or more nodes constituting a block chain in which a new block is added through a process according to a predetermined consensus algorithm in which two or more nodes participate An IMS application unit included in a personal terminal including an IMS application unit that provides a service is provided to a user by exchanging information with an SNS application unit that is a service server that provides a service and uses an SNS platform. Provide SNS services And a target confirmation service unit for confirming the target of the user by exchanging information with the IMS application unit using the IMS platform. The SNS-side service providing unit transmits SNS_ID, which is information that can identify the user on the SNS platform, obtained using at least the function provided by the user, together with information that can identify the result of the user's target confirmation. Then, the target confirmation service unit associates the SNS_ID received from the IMS application unit with the result of the target confirmation of the user specified by the SNS_ID, notifies the SNS side service provision unit, and notifies the SNS side service provision unit. , Based on the result of the user confirmation IMS is the personal information disclosed by the user to the blockchain, and is the personal information necessary for a predetermined target confirmation, which is either identity verification, user authentication or eligibility verification. The first block including the hash value of the target confirmation information is registered, the validity of the target confirmation information disclosed by the user is verified using the blocks in the block chain, and then the first block is verified based on the disclosed target confirmation information. The target is confirmed, and the IMS registers the second block including the record of the target confirmation in the blockchain, and requests the user to disclose the target confirmation information. As a result, the user replaces the target confirmation information with the second block. When the information that can specify is disclosed, the target confirmation is performed with reference to the record of the target confirmation in the second block specified from the disclosed information .

Claims (10)

A service server that provides a predetermined service, and a personal terminal used by a user to whom the service is provided,
The personal terminal comprises:
An SNS application unit that provides various processes and interfaces for the user to use a predetermined SNS;
An IMS application unit that provides various processes and interfaces for the user to use a predetermined IMS.
The service server comprises:
An SNS-side service providing unit that provides the user with the service by exchanging information with the SNS application unit using the SNS platform;
A target confirmation service unit for confirming the target of the user by exchanging information with the IMS application unit using the IMS platform;
The IMS application unit obtains the target confirmation service unit using at least a function provided by the SNS platform by a predetermined method, and the SNS-side service providing unit performs the use on the SNS platform by the SNS side. Transmitting SNS_ID, which is information that can identify a user, together with information that can identify the result of the user's target confirmation,
The object confirmation service unit notifies the SNS side service providing unit of the SNS_ID received from the IMS application unit and the result of the object confirmation of the user specified by the SNS_ID in association with each other. Service providing system. The IMS application unit uses a transmission / reception function of a message provided by the SNS platform to transmit the IMS application unit from a start parameter passed when the self application is started from a link of a Web page received from the SNS side service providing unit. The service providing according to claim 1, wherein the SNS_ID of the user is obtained, or the SNS_ID of the user is obtained by using a login service to the SNS from another application provided from the platform of the SNS. system. The IMS application unit uses a message transmission / reception function provided by the SNS platform to transmit / receive a message from a link of a web page received from the SNS side service providing unit. The service provision according to claim 2, wherein information including a session ID capable of specifying the user as the SNS_ID and a destination IMS_ID that is information capable of specifying the target confirmation service unit on the IMS platform is acquired. system. The IMS application unit associates the SNS_ID of the user with the IMS_ID, which is information that can identify the user on the IMS platform held by the user, and transmits the IMS_ID to the target confirmation service unit. The service providing system according to any one of claims 1 to 3. The IMS application unit transmits the SNS_ID of the user and the result of the target confirmation of the user performed using the IMS platform to the target confirmation service unit in association with each other. The service providing system according to claim 3. The IMS comprises:
Two or more nodes constituting a block chain to which a new block is added through processing according to a predetermined consensus algorithm in which two or more nodes participate;
The block chain includes a hash value of target confirmation information, which is personal information disclosed by a user and necessary for predetermined target confirmation, which is one of identity verification, user authentication, and eligibility verification. A registration unit for registering the first block;
A target confirmation unit that verifies the validity of the target confirmation information disclosed by the user using blocks in the block chain, and performs the target confirmation based on the disclosed target confirmation information. And
The IMS application unit has the registration unit as a part of the IMS,
The service providing system according to claim 1, wherein the target confirmation service unit includes the target confirmation unit as a part of the IMS. The IMS comprises:
The block chain further includes a record registration unit that registers a second block including the record of the target confirmation,
The target confirmation unit is disclosed when, as a result of requesting the user to disclose the target confirmation information, information that can specify the second block is disclosed from the user instead of the target confirmation information. Performing the target confirmation by referring to the record of the target confirmation in the second block specified from the information that has been obtained,
The service providing system according to claim 6, wherein the target confirmation service unit further includes the record registration unit as a part of the IMS. Permission to be installed at the place where the personal terminal used by the user, the service providing device for providing the user with the predetermined service, and the license issued by the service providing device indicating the eligibility for the service are used Certificate identification device,
The personal terminal comprises:
An SNS application unit that provides various processes and interfaces for the user to use a predetermined SNS;
An IMS application unit that provides various processes and interfaces for the user to use a predetermined IMS.
The service providing device includes:
An SNS-side service providing unit that provides the user with the service by exchanging information with the SNS application unit using the SNS platform;
A first target confirmation service unit for confirming the target of the user by exchanging information with the IMS application unit using the IMS platform;
The permit determination device,
When an application for admission or an application for receipt of profits obtained by the permit is received from the user, the target confirmation of the user is performed by exchanging information with the IMS application unit using the IMS platform. 2 subject confirmation service department,
A determination unit that determines whether the user can apply for a request based on a result of the target confirmation by the second target confirmation service unit,
The IMS application unit obtains at least the first target confirmation service unit by using a function provided by the SNS platform at least by a predetermined method. Transmitting SNS_ID, which is information capable of identifying the user, together with information capable of identifying the result of the target confirmation of the user,
The first target confirmation service unit notifies the SNS side service providing unit of the SNS_ID received from the IMS application unit and the result of the target confirmation of the user identified by the SNS_ID,
The SNS-side service providing unit provides the service to the user based on a result of the user's target confirmation notified from the first target confirmation service unit,
The IMS comprises:
Two or more nodes constituting a block chain to which a new block is added through processing according to a predetermined consensus algorithm in which two or more nodes participate;
The block chain includes a hash value of target confirmation information, which is personal information disclosed by a user and necessary for predetermined target confirmation, which is one of identity verification, user authentication, and eligibility verification. A registration unit for registering the first block;
After verifying the validity of the target confirmation information disclosed by the user using a block in the block chain, a target confirmation unit that performs the target confirmation based on the disclosed target confirmation information,
A record registration unit for registering a second block including a record of the target confirmation or the provision of the service in the block chain,
The IMS application unit has the registration unit as a part of the IMS,
The first target confirmation service unit and the second target confirmation service unit each include the target confirmation unit and the record registration unit as a part of the IMS,
The IMS application unit stores, in the blockchain, the identifier of the user, a hash value of first target confirmation information that is biometric information disclosed by the user, and the user Register the first block including the hash value of the second target confirmation information which is the predetermined personal information disclosed from
The first target confirmation service unit requests the user to disclose the second target confirmation information via the target confirmation unit, and performs the target confirmation based on the obtained information;
The second object confirmation service unit provides, via the object confirmation unit, the user with information capable of specifying the second block, first object confirmation information at the time of the first block registration, Requesting the disclosure of the first target confirmation information, and performing a predetermined eligibility check including an identity verification based on the disclosed information. The service providing system according to any one of claims 1 to 8, wherein the service is one of a ticket service, a facility management service, a voting service, and a commuter pass fare management service. An SNS application unit which is a personal terminal used by a user to whom a service is provided and which provides various processes and interfaces for the user to use a predetermined SNS; An IMS application unit provided in a personal terminal including an IMS application unit that provides various processes and interfaces for use is provided by a service server that provides the service, the SNS application unit using the SNS platform. The information exchange between the SNS-side service providing unit that provides the service to the user and the IMS application unit using the IMS platform enables the user to confirm the target of the user. Confirmation service department The object confirmation service unit of the service server obtained by using the function provided by the SNS platform in a predetermined manner, and the SNS side service providing unit acquires the user on the SNS platform. SNS_ID, which is identifiable information, is transmitted together with the identifiable information on the result of the user's target confirmation,
The target confirmation service unit notifies the SNS side service providing unit of the SNS_ID received from the IMS application unit and the result of the target confirmation of the user identified by the SNS_ID,
A service providing method, wherein the SNS-side service providing unit provides the service based on a result of the user's target confirmation notified from the target confirmation service unit.

Images