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

Abstract

PROBLEM TO BE SOLVED: To provide a service with object confirmation on an SNS only by minimum disclosure of personal information. SOLUTION: 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 IMS application unit 712 uses the function provided by the SNS platform for the target confirmation service unit 722 and the service server 72 including the target confirmation service unit 722 for performing user target confirmation using the platform Then, the SNS_ID acquired and the information that can identify the result of the target confirmation of the user are transmitted, and the target confirmation service unit 722 corresponds the received SNS_ID and the target confirmation result of the user specified by the SNS_ID. Then notify the SNS service provision unit 721 That. [Selected figure] Figure 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 the service providing place, a side providing a service (hereinafter referred to as a vendor) may provide a service after confirming whether the request source user is the user himself or herself. For example, the vendor requests the request source user to disclose personal information, and based on the disclosed personal information, confirms whether the user is the user. In general, to confirm that a person is the person himself is called “personal identification” or “identity verification.” As personal information used for identification, for example, a driver's license (More specifically, an information set included in it. The same applies to the following.), A health insurance card (more specifically, an information set included in it. The same applies to the following), a passport (more specifically, an information set included in it. Similar), credit card (more specifically, an information set included in it. The same applies hereinafter), biometric information, my number, etc. In addition, in some cases, predetermined two or more pieces of information such as a combination of an ID and a password Combinations are also included in such personal information.

  Also, for example, in order to confirm that the request source user is an authorized user of the vendor, the vendor requests the request source user for user identification information and authentication information, and is registered in advance with the obtained information. By collating with existing information, it is confirmed whether the user is a legitimate user of the vendor. It is called "user authentication" to confirm that a person who declares a particular user to a certain system is that particular user, that is, a legitimate one user. Here, to confirm that the user is a legitimate user means, more specifically, that a filer who declares a particular user to a certain system is the same person as or equivalent to that particular user in that system. It is to confirm that you are qualified to be considered. While the verification of the identity confirms that the declarant is the declarator himself, the user authentication remains in confirming that the declarator can be regarded as identical to the user registered in advance. Although different levels are required for user authentication, user authentication can also be considered as a type of authentication within an individual system.

  Another example of using personal information is “eligibility verification,” which confirms that the requester who requested the provision of a service is eligible for the service. . Here, the service includes all services such as provision of goods and services without charge / free.

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

  The technology of providing a service after subject confirmation based on such personal information is disclosed. For example, in Patent Document 1, a management apparatus is a user using a face image captured by a product providing apparatus such as a vending machine. A product providing system capable of providing a product without requiring time and effort of a user by performing authentication is described.

  Further, Patent Document 2 describes a person authentication system capable of specifying an individual without using a dedicated card and a dedicated device such as an IC card and its reader, and without using an arbitrary ID set by the individual. There is. The person authentication system described in Patent Document 2 associates and holds in advance a terminal ID as information for identifying a user in an authentication server and information for authentication (such as a set of biometric information and position information). In the information server, the terminal ID and the personal information of the user are associated and held. Then, the terminal device holding the terminal ID transmits a command for requesting personal information of the user via the reader / writer to the information server together with the information for verification (biometric information and position information) acquired by itself. Do. The information server analyzes the received command, compares the information for verification received from the terminal apparatus with the information for authentication stored in the authentication server, performs user authentication, and then receives the personal information of the received user. Send information to the terminal.

  In addition, Non-Patent Document 1 is a personal authentication service by a personal information management system (Identity Management Sysmtem: IMS) provided by ShoCard as one of the systems for performing identity verification using a block chain. ShoBadge "is introduced. In addition, ShoCard also offers "ShoCard", an application for personal identification service, to personal terminals. In the following, regardless of the actual service name or application name, IMS by ShoCard is referred to as "ShoCard", and platforms and personal terminal applications used in that IMS are referred to as "ShoCard platform" and "ShoCard APP".

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

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

  The problem is that it is desirable to perform services including object confirmation from SNS (Social Networking Service) while securing the confidentiality of personal information.

  In general, IMS manages personal information for each user using an ID uniquely assigned to each user. For example, in the above-mentioned "ShoCard", the disclosure request of the user's personal information is requested or the identity of the disclosed information is verified by using the ShoCard ID assigned to each user when using the terminal application. .

  One SNS does not basically need information other than the ID used in the SNS to improve the anonymity of an individual, but a mechanism that can not specify the user terminal using the service outside the SNS It is often

  Therefore, in order to provide a service including object confirmation such as identity confirmation on the SNS, it is necessary to link the SNS and the IMS. When SNS and IMS are linked, it is necessary to associate both the SNS user ID and the user ID on IMS, but there has been no specific method for linking SNS and IMS so far, and each system of the service provider Independently, they only hold and use the information for identity verification necessary for the service provision.

  For example, in the methods described in Patent Document 1 and Patent Document 2, it is necessary to manage, for each service, a pair of an ID and authentication information or to perform a procedure for object confirmation. Therefore, in order to receive various services, the user is required to manage different IDs and authentication information for each service or vendor, and information used in procedures for object confirmation, which is cumbersome.

  In addition, each vendor also has to keep and manage the user's personal information by themselves, and not only bears the risk of leakage but also increases the cost for information management including defense against attacks.

  It is also conceivable that the vendor side does not manage the personal information of the user, and makes the user present it each time a service is requested. However, this method is complicated for the user because the information necessary for object confirmation must be presented each time in object confirmation. In addition, this method is, for example, forced to present the entire certificate even if it is sufficient to present only a part of the information of the certificate for certifying the user, such as a license, in the object confirmation. If it is not, it can not be controlled to disclose only the minimum necessary information for each purpose or application, and it is not sufficient in terms of protection of personal information.

  In view of the problems described above, the present invention provides a service providing system and a service providing method capable of providing a service with object confirmation on an SNS only by the minimum disclosure of personal information. To 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 who is a service provider, and the personal terminal uses the predetermined SNS by the user. The service server includes an SNS application unit that provides various processes and an interface for performing the process, and an IMS application unit that provides various processes and an interface for the user to use a predetermined IMS. Exchange of information with the SNS application unit allows the user to confirm the target of the user by exchanging information between the SNS service providing unit that provides services to the user and the IMS application unit that uses the IMS platform IMS application including the service department The SNS unit acquires information by using the function provided by the SNS platform at least in a predetermined manner in the target confirmation service unit, and the SNS-side service providing unit can identify the user on the SNS platform. The SNS_ID transmits the SNS_ID of the user together with the information that can identify the target confirmation of the user, and the target confirmation service unit transmits the SNS_ID received from the IMS application unit and the result of the target confirmation of the user specified by the SNS_ID. Two or more nodes forming a block chain to which a new block is added after processing in accordance with a predetermined consensus algorithm in which two or more nodes participate by notifying the SNS side service providing unit in association , The personal information disclosed by the user in the block chain, and the identity verification, the user A registration unit for registering a first block including a hash value of target confirmation information which is personal information necessary for predetermined target confirmation which is either authentication or qualification confirmation, and legitimacy of target confirmation information disclosed by the user And the target confirmation unit that performs target confirmation based on the disclosed target confirmation information after verifying the flexibility using the blocks in the block chain, and the IMS application unit performs the registration unit as part of the IMS. The target confirmation service unit further includes a record registration unit having the target confirmation unit as part of the IMS, and the IMS registering the second block including the record of the target confirmation in the block chain, the target Information disclosed when the confirmation unit requests the user to disclose the target confirmation information and, as a result, the information that can specify the second block from the user is disclosed instead of the target confirmation information 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, a 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 permit indicating an eligibility for the service issued by the service providing device. The personal terminal is provided with an SNS application unit that provides various processing and an interface for the user to use a predetermined SNS, and the user is provided with a predetermined device. The service providing apparatus includes an IMS application unit that provides various processes and interfaces for using IMS, and the service providing apparatus is a SNS that provides a service to a user by exchanging information with the SNS application unit using a SNS platform. Application that uses the service provider and IMS platform Including a first object confirmation service unit for confirming the object of the user by exchanging information with the application department, and the permit judging device is an application for admission from the user or an application for receipt of the profit obtained by the permit The second target confirmation service unit performs target confirmation of the user by exchanging information with the IMS application unit using the IMS platform based on the result of the target confirmation by the second target confirmation unit. The IMS application unit acquires at least the function provided by the SNS platform to at least the first object confirmation service unit using a predetermined method; SNS_ID, which is information that enables the SNS-side service provider to identify users on the SNS platform, The result of the target confirmation of the person is transmitted together with the identifiable information, and 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 specified by the SNS_ID. The SNS-side service provider notifies the user of the service based on the result of the target confirmation of the user notified from the first target confirmation service unit, and the IMS 2 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 the above nodes participate, and personal information disclosed by the user in the block chain, Hash value of target confirmation information, which is personal information necessary for predetermined target confirmation, which is either identity confirmation, user authentication, or eligibility confirmation After verifying the legitimacy of the object confirmation information disclosed by the user using the registration unit that registers the first block including the data, using the blocks in the block chain, the object confirmation is performed based on the disclosed object confirmation information. The object confirmation unit, and the record registration unit that registers the second block including the record of the provision of the object confirmation or the service in the block chain, and the IMS application unit has the registration unit as a part of IMS, The first object confirmation service unit and the second object confirmation service unit respectively have an object confirmation unit and a record registration unit as a part of IMS, and the IMS application unit uses the block chain via the registration unit. The identifier of the person, the hash value of the first target confirmation information which 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 target confirmation information is registered, and the first target confirmation service unit requests the user to disclose the second target confirmation information via the target confirmation unit. The second object confirmation service unit performs the object confirmation based on the obtained information, and the user can specify the second block to the user via the object confirmation unit, and the information at the time of the first block registration. The disclosure of the first object confirmation information and the current first object confirmation information is requested, and based on the disclosed information, predetermined eligibility confirmation including identity confirmation is performed, and the object confirmation unit instructs the user As a result of requesting the disclosure of the target confirmation information, when the information capable of specifying the second block is disclosed by the user instead of the target confirmation information, the target confirmation in the second block identified from the disclosed information The target confirmation may be performed with reference to the record .

The service providing method according to the present invention is a personal terminal used by a user who is a service providing destination, and an SNS application unit that provides various processes and an interface for the user to use a predetermined SNS. Processing and interface for using a predetermined IMS comprising two or more nodes forming 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 IMS application unit included in the personal terminal provided with the IMS application unit providing the service is a service server providing the service, and the user is provided with the service by exchanging information with the SNS application unit using the SNS platform. SNS side service offer And the target confirmation service unit of the service server provided with the target confirmation service unit for performing user target confirmation by exchanging information with the IMS application unit using the IMS platform, the SNS platform in a predetermined method SNS_ID, which is information obtained by using at least the functions provided by the SNS-side service provider and which can identify the user on the SNS platform, is transmitted together with information which 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 target confirmation of the user specified by the SNS_ID and notifies the SNS side service providing unit, and the SNS side service providing unit , Based on the result of the target confirmation of the user notified from the target confirmation service unit , And IMS is the personal information disclosed by the user in the block chain, and is the personal information necessary for the predetermined subject confirmation that is either identity verification, user authentication or qualification check. The first block including the hash value of the target confirmation information is registered, and the legitimacy of the target confirmation information disclosed by the user is verified using the blocks in the block chain, and then based on the disclosed target confirmation information. As a result of performing object confirmation and registering the second block including the record of the object confirmation in the block chain and requesting the user to disclose the object confirmation information, the second block from the user instead of the object confirmation information Is disclosed, the object confirmation is performed with reference to the record of the object confirmation in the second block specified from the disclosed information .

  According to the present invention, it is possible to provide a service with object confirmation on the SNS only by the minimum disclosure of personal information.

It is a block diagram showing an example of a service offer system of a 1st embodiment. It is explanatory drawing which shows the outline | summary of the specific example of the 1st ID delivery method using LINE and ShoCard. It is a sequence diagram of the example of the 1st ID passing method using the LINE and ShoCard. It is explanatory drawing which shows the outline | summary of the specific example of the 2nd ID delivery method using LINE and ShoCard. FIG. 20 is a sequence diagram of a specific example of a second ID passing method using LINE and ShoCard. It is explanatory drawing which shows the outline | summary of the specific example of the 3rd ID delivery method using LINE and ShoCard. FIG. 20 is a sequence diagram of a specific example of a third ID passing method using LINE and ShoCard. It is explanatory drawing which shows the example of holding | maintenance of the various information in the personal information management system of 2nd Embodiment. It is explanatory drawing which shows the other example of the signature method of the registration information in a registration block. It is explanatory drawing which shows the other example of the signature method of the registration information in a registration block. It is explanatory drawing which shows the example of a confirmation recording block. It is a block diagram which shows the main structures of the personal-information management system of 2nd Embodiment. FIG. 6 is a block diagram showing an exemplary configuration of a confirmation unit 202. FIG. 6 is a block diagram showing a configuration example of a ledger management node 301. It is a flowchart which shows an example of the 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 the operation | movement in the registration phase of the personal-information management system of 2nd Embodiment. It is a flowchart which shows an example of the operation | movement in the confirmation phase of the personal-information management system of 2nd Embodiment. It is a flowchart which shows an example of the operation | movement in the confirmation phase of the personal-information management system of 2nd Embodiment. It is a flowchart which shows the operation example of the confirmation engine side system in a confirmation phase. It is a schematic block diagram of the ticket service system of 3rd Embodiment. It is a flowchart which shows the outline | summary of operation | movement of the ticket service system of 3rd Embodiment. It is a sequence diagram which shows an example of the flow of the process at the time of principal registration of 3rd Embodiment. It is a sequence diagram (1) which shows an example of the flow of the process at the time of the purchase application of 3rd Embodiment. It is a sequence diagram (2) which shows an example of the flow of the process at the time of the purchase application of 3rd Embodiment. It is a sequence diagram which shows an example of the flow of the process at the time of the entrance application of 3rd Embodiment. It is a block diagram which shows the other example of the ticket service system of 3rd Embodiment. It is a schematic block diagram showing an example of composition of a computer concerning each embodiment of the present invention. It is a block diagram which shows the outline | summary of the service provision system of this invention.

Embodiment 1
Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram showing an example of a service providing system according to the first embodiment. The service providing system 600 illustrated 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 SNSAPP unit) 611 and an IMS application unit (hereinafter, referred to as IMSAPP unit) 612.

  The SNS APP unit 611 provides the user of the personal terminal 61 with various processes and an interface for using a predetermined SNS. Specifically, the SNS APP unit 611 is a processing unit that is an operation subject of an application (SNS APP) for a predetermined SNS directed to an individual user. The SNS APP unit 611 operates the SNS APP on the personal terminal 61 to provide the user of the personal terminal 61 with an interface for using a predetermined SNS and perform various processing.

  Here, although the predetermined SNS is not particularly limited, for example, “LINE” (registered trademark), “Ameba” (registered trademark), “Facebook” (registered trademark), “Google+” (registered trademark), “GREE” (registered trademark) It may be a registered trademark, "Instagram" (registered trademark), "LinkedIn" (registered trademark), "mixi" (registered trademark), "skype" (registered trademark), "Twitter" (registered trademark) and the like.

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

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

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

  The SNS platform 62 is a platform that provides a predetermined SNS. The SNS platform 62 is a part of a system that provides an SNS, for example, functions for SNS users (for example, sending and receiving messages using a user ID, timeline function, user mutual link function, questionnaire function, user search function Provide community functions, etc.). Specifically, the SNS platform 62 is 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 an object confirmation service such as management and collation of personal information. For example, a function for the user of the object confirmation service (for example, object confirmation using a user ID, personal information therefor) Provide registration / collation function etc. Specifically, the IMS platform 63 is realized by 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 object confirmation on the SNS, and includes the SNS-side service providing unit 641, the object confirmation service unit 642, and the ID federation information storage unit 643. Including.

  The SNS side service providing unit 641 exchanges information with the SNS APP unit 611 using the SNS platform 62, and provides a predetermined service with object confirmation on the SNS (more specifically, on the SNS platform 62). Processing unit. In addition, about object confirmation, it is performed via the object confirmation service part 642 mentioned later.

  The target confirmation service unit 642 exchanges information with the IMS APP unit 612 using the IMS platform 63, and provided by the SNS side service providing unit 641 on IMS (more specifically, on the IMS platform 63). The service user is required to confirm the target required to provide the service.

  Further, the target confirmation service unit 642 has a function of notifying the SNS-side service providing unit 641 of the result of target confirmation. At this time, the target confirmation service unit 642 according to the present embodiment uses an 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 this system on the SNS platform 62. Report the result of target confirmation.

  The target confirmation service unit 642 according to the present embodiment is IMS_ID, which is an identifier that can identify the user of the service providing destination of the system on the IMS platform 63, and the SNS_ID corresponding to the IMS_ID (at least SNS service providing unit After 641 acquires the identifier that can identify the user on the SNS platform 62, a predetermined target confirmation is performed on the user identified by the IMS_ID.

  In addition, the target confirmation service unit 642 is a process that is an operation subject of the confirmation side user application (confirmation side IMSAPP) for this system including a function of requesting the target user to confirm the target using the IMS platform 63. It corresponds to the department. That is, the target confirmation service unit 642 operates the confirmation side IMSAPP on the service server 64 to acquire IMS_ID and SNS_ID for the user of the service provided by the SNS-side service provision unit 641 on the IMS. Confirm the target.

  The SNS_ID and IMS_ID may be any information that can identify the corresponding user on the target platform in the processing unit that uses that ID. That is, the SNS_ID may be any information as long as the SNS side service providing unit 641 can identify the corresponding user on the SNS platform 62, and the IMS_ID is a user corresponding to the SNS side service providing unit 641 on the IMS platform 63 As long as it can identify the information. As an example, SNS_ID is not only information that can always identify the corresponding user on the target platform (user ID etc. that is always open on the target platform), but also uses corresponding to the target platform, such as session ID. The information may be information that can identify the corresponding user by collating with information temporarily held by the server or the like in a session with the person.

  The ID federation information storage unit 643 stores, as necessary, ID federation information which is information in which the SNS_ID of the user of the service providing destination is associated with the IMS_ID.

  In the present embodiment, in order to enable the ID server of the IMS_ID and the SNS_ID in the service server 64, the SNS_ID of the corresponding user is passed from the SNSAPP to the IMSAPP and the IMSAPP to the target confirmation service unit 642. As a specific method of such ID transfer, for example, the following three methods may be mentioned.

(First ID passing method)
The first ID passing method is a personal terminal using a response message to the personal terminal 61 to a message sent to the SNS side service providing unit 641 from the individual user who wants to use this service using the SNS APP. 61 by activating IMSAPP. Specifically, at the time of activation, the IMSAPP is notified of an ID capable of specifying the service provision destination user on the SNS platform as the SNS_ID, and the IMSAPP is notified of the IMS_ID assigned to itself and the SNS_ID notified at the time of activation. Is notified to the target confirmation service unit 642 corresponding to the operation subject of the confirmation side IMSAPP on the service server 64.

  Many SNS platforms provide an API (Application Programming Interface) (hereinafter referred to as an API for messages) for exchanging (transmitting and receiving) messages between an individual user and an arbitrary server (so-called chat bot etc.) . By using such an API, it is possible to automatically transmit an arbitrary message to the transmission source user.

  Also, the automatic activation of IMSAPP from the SNS side can be realized, for example, as follows. First, using a mechanism such as webhook that sends a POST request to a URL (Uniform Resource Locator) specified at the occurrence of a predetermined event, the SNS-side service provider 641 of the service server 64 sends a message containing the SNS_ID of an individual user. To be able to receive Then, a custom URL scheme (also called deep link) is embedded in the link of the web page sent in the response sequence to the message reception.

  With deep linking, not only can you transition to a specific screen of an application, but defining your own scheme allows you to transition between applications, such as launching other applications and passing information to the application. It can be carried out.

  In the first ID passing method, the terminal (personal terminal) of an individual user who has sent a message requesting the provision of the service using the SNS side service providing unit 641 of the service server 64 using the message API on the SNS. 61) Send a response message for this service. At this time, code for executing a predetermined inter-application cooperation function is embedded in the response message. Thereby, when the user selects execution of the function, IMSAPP for this service can be automatically activated on the personal terminal 61. Furthermore, at this time, the SNS_ID of the individual user is included in the activation parameter of IMSAPP. This enables the IMSAPP unit 612 to acquire not only the IMS_ID of the individual user but also the SNS_ID.

  The IMS APP unit 612, for example, receives the IMS_ID assigned to itself, the SNS_ID acquired at the time of starting the application, and the target confirmation service unit 642 of the service server 64 corresponding to the operation subject of the confirmation side IMSAPP in this system. To notify. It is assumed that the activated IMSAPP is an application in which such a notification function is implemented in advance for this service, and that the destination information of the notification destination is known. In addition, it is also possible to pass information (URL etc.) of the service server 64 as destination information of a notification destination together with the SNS_ID at the time of IMSAPP startup. The notification of IMS_ID and SNS_ID from the IMS APP unit 612 to the target confirmation service unit 642 can also be performed using the IMS platform 63.

  When the IMSAPP notifies the IMS_ID and SNS_ID of the user of the service request source from the IMSAPP, the target confirmation service unit 642 associates these and stores them in the ID federation information storage unit 643, and then uses the IMS platform 63. A subject confirmation sequence is started with the IMS APP on the personal terminal 61 of the notification source, and the result of the subject confirmation is received.

  The object confirmation sequence itself may be performed using an API or the like provided by the IMS platform 63. For example, the IMS platform 63 requests a target confirmation in which the IMS_ID is specified to a user-side application (in this example, the target confirmation service unit 642 of the service server 64 corresponds) that has the authority to request target confirmation by contract or the like. Provide an API to accept

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

  The IMS platform 63 collates the personal information received from the IMSAPP with the personal information of the user possessed by itself, etc., and confirms the target confirmation requested by the API to the user currently operating the IMSAPP. Do. For example, as a result of collation, the IMS platform 63 determines whether or not the user currently operating the IMSAPP is the user identified by the designated IMS_ID, and meets predetermined conditions as necessary. And the like is transmitted, and the result is sent to the requesting IMSAPP (target confirmation service unit 642 of the service server 64).

  When the target confirmation service unit 642 receives 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 641 corresponds the result to the SNS service provision unit 641 and the ID linkage information storage unit 643 with the IMS_ID. It notifies with attached SNS_ID.

  Note that, when the target confirmation is successful, the target confirmation service unit 642 embeds the custom URL scheme in the link of the Web page to be sent to IMSAPP as the response message, and the original service screen of SNSAPP can be displayed according to the user operation. It may be possible to return.

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

  In this example, the ID delivery and identity verification for the service provider 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 IMS APP unit 612, and the ShoCard service corresponds to the target confirmation service unit 642. In this example, LINE Bot is, for example, an application created for this creation using the Messaging API provided by the LINE platform or another SDK. The ShoCard APP and ShoCard services are, for example, applications created for this system using ShoCardSDK provided by ShoCard. The LINE APP may be a general personal LINE application. The other examples are also the same.

The 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). In addition, when the rich menu is selected, the ShoCard APP which is an application for identity verification on the personal terminal is used by the userId (LINE platform) corresponding to the SNS_ID of the self (in this case, the LINE APP on the terminal side) Internal identification ID) to be automatically activated.
When the rich menu is selected, the LINE APP automatically activates the ShoCard APP on the personal terminal according to the menu (5 in the figure).
-The activated ShoCard APP acquires userId as an activation parameter (6 in the figure).
The ShoCard APP that has acquired the userId reports the userId to the server-side ShoCard service together with the ShoCard ID (corresponding to IMS_ID) of its own (7 in the diagram).
-The ShoCard service notified of ShoCardID and userId stores these in association with each other in a predetermined storage unit (8 in the figure), and starts an identity verification sequence from the server side (9-12 in the figure). ).
・ ShoCard service notifies LINE Bot of confirmation result (14 in the figure) when identity verification sequence is completed, or stores confirmation result in predetermined storage unit and waits for inquiry from LINE Bot (figure 13, 14).

  As a method of automatically starting an application specified on the personal terminal, for example, there is a method of embedding a custom URL scheme in a Web service screen transitioning from a rich menu.

  The exchange of data in the method will now 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 own terminal, and transmits a usage start message addressed to LINE Bot via the LINE platform (steps S601 to S603).

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

  When the LINE Bot receives the request for the usage start message, it sends a predetermined HTTP response message to the LINE APP, and adds a menu for this system to the rich menu and displays it (Steps S604 and S605).

  When the user selects the menu, a Web page request is transmitted to a specific URL of the service server (steps S606 and S607). In this example, the LINE Bot receives the request, but the implementation method of the process for the request is not particularly limited. For example, the ShoCard service may accept, or another service (a common web server service on a service server, etc.) may accept.

  The service server that has received the request returns, as a response message, a Web page in which a custom URL scheme is embedded in the link (steps S608 and S609). The custom URL scheme is configured such that upon tapping the link, the ShoCard APP is activated on the personal terminal 61, and the userId is handed over 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 handed over as an activation parameter (step S611). ).

  The ShoCard APP notifies the ShoCard service of the service server of the pair of the userId and its own ShoCardID received as the activation parameter (step S612).

  The ShoCard service of the service server, when notified of the pair of userId and ShoCardID from the ShoCard APP, associates these and stores them in a predetermined storage unit (step S613), and starts an identity verification sequence (step S614 to S614). Step S629).

  The identity verification sequence in the figure is an example of the case where the identity verification 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 of the confirmation destination on the ShoCard platform. On the other hand, the message from the ShoCard platform to the ShoCard APP includes a senderShoCardID, which is a ShoCard ID for identifying a user who has requested confirmation on the ShoCard platform.

  When receiving a request for information disclosure for identity verification, the ShoCard APP performs identity verification by face authentication (steps S616 to S622). If personal identification has been completed in response to a request from the server in the past, the process is omitted and the information necessary for the personal identification held by itself is stored together with the information of the record on the ShoCard platform. You may return (step S623-step S624).

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

  In step S617 to step S619, the acquired face picture (or information based thereon) is used to collate with the information on the ShoCard platform, and the holder of the information (face picture) is identified by the designated ShoCardID. It verifies whether the user is the user and obtains the result.

  Steps S620 to S622 are processing for recording the result of the identity verification of oneself on the ShoCard platform.

  In this way, when the identity verification of the user is completed, the ShoCard APP transmits information necessary for the identity verification (or object verification) in the service provision of the system to the ShoCard service as necessary (step S623). , Step S624). The information is not particularly limited as long as the desired object confirmation can be performed by referring to the information on the provided side. For example, it may be biometric information such as a photograph of the face, personal information issued by a predetermined authentication institution such as a license image, or the service subscriber of this system stored in advance in the ShoCard platform. It may be information (contractor identification ID etc.) to be shown. Also, it may be an identifier of the record of the result of the identification of oneself held in the ShoCard platform.

  The ShoCard service uses the received information to compare with the information on the ShoCard platform, and the sender user who is the holder of the information is the user identified by the specified ShoCardID. The result is verified (steps S625 to S627). The process of steps S625 to S627 is similar to that of steps S617 to S619.

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

  The ShoCard APP may return processing to the LINE APP from which it is activated, based on the result of self-identification on the server side and the server side.

(Second ID passing method)
The second ID passing method is to activate IMSAPP on the personal terminal 61 using a response message to the personal terminal 61 in response to a message sent to the SNS-side service providing unit 641 using SNSAPP. Is similar to the first ID passing method. In the second ID passing method, the SNS side service providing unit 641 serves as the SNS platform as an IMS APP on the server side as the notification destination of the result of the identity verification and the SNS_ID of the user of the service providing destination at the time of activation. Informing a session ID that can identify the user at the top. Then, the personal identification sequence is started from IMSAPP, which is an application on the terminal side, and the result is notified together with the session ID to the server side (target confirmation service unit 642 of service server 64) using IMS_ID notified at startup. . When the target confirmation service unit 642 receives the result of the user 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 and SNS_ID of the user of the service providing destination, and does not hold the ID federation information.

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

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

  The exchange of data in the method will now be described in more detail with reference to FIG. In the example shown in FIG. 5, since steps S601 to S611 are basically the same as the first ID passing method, the description will be omitted.

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

  Also, in this example, when the user taps the link in steps S608 and S609, the ShoCard APP is activated on the personal terminal 61, and the custom URL scheme is configured so that senderShoCardID and sessionId are delivered as activation parameters. Reply embedded web page as 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 verification sequence in the figure is an example of the case where the identity verification sequence is started from the terminal side. Although steps S 614 and S 615 are omitted, they are basically the same as the identity verification sequence in the first ID passing method.

  Also in this method, when personal identification of the user is completed, the ShoCard APP transmits information necessary for the personal identification in the service provision of the system to the ShoCard service as necessary (steps S623 and S624).

  The ShoCard service uses the received information to compare with the information on the ShoCard platform, and the sender user who is the holder of the information is the user identified by the specified ShoCardID. The result is verified (steps S625 to S627). In addition, the ShoCard service transmits the confirmation result of the disclosed information to the ShoCard APP of the transmission source of the information (steps S628 and S629).

  In this way, when receiving the result of the self-identification on the server side and the ShoCard APP, the ShoCard APP notifies the senderShoCardID received as the start-up parameter together with the sessionId (step S630).

  Then, ShoCard APP may return processing to the LINE APP from which it was launched.

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

  In this method, the user is logged in from IMSAPP to a predetermined SNS which is a place of service provision in the present system. By logging in to the SNS using the SNS login service, it is possible to know the SNS_ID (for example, the userId described above) that the user uses on the SNS platform. The IMS APP 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. The timing of login from IMSAPP to SNS is not particularly limited. It may be at the start of use of IMSAPP for this system, or every time the user requests a service from the SNS service provider 641, a message to that effect may be sent to prompt the user to log in. is there.

  When the IMS APP acquires the SNS_ID of the user using the SNS login service, it notifies the target confirmation service unit 642 of the service server 64 together with its own IMS_ID. The notification method may be notified immediately after acquisition as in the first ID passing method, or may be notified after completion of the identity verification as in the second ID passing method. The method of notification is not particularly limited.

  Further, the target confirmation service unit 642 that has received the notification associates the received IMS_ID with the SNS_ID, and stores the result in the ID federation information storage unit 643. Thereby, in response to the inquiry of the identity confirmation from the SNS side service providing unit 641 designated by the SNS_ID, the identity confirmation result of the corresponding user can be returned.

  6 and 7 show a specific example of the third ID passing method. FIG. 6 is an explanatory view showing an outline of a specific example of the third ID passing method, and FIG. 7 is a sequence diagram of this specific example. Also in this example, "LINE" is used as the SNS, and "ShoCard" is used as the IMS. 6 (a) shows an outline of processing up to ID collaboration, and FIG. 6 (b) shows an outline of processing after ID collaboration.

In this example, the ID delivery and identity verification for the service provider are performed as follows.
When the ShoCard APP is launched by the user, the user is required to log in to the LINE. ShoCard APP performs LINE login using LINE login service according to user operation, and acquires userId of a user as a result (1-3 in the figure).
・ ShoCard APP which has acquired userId performs registration of personal information etc. necessary for the service of this system according to user operation (4 in the figure), and pairs ShoCard ID with own ShoCard ID and acquired userId in ShoCard service. Is notified (5 in the figure).
When the ShoCard service is notified of the ShoCardID-userId pair, the ShoCard service associates them and stores them in a predetermined storage unit (6 in the figure).

The LINE APP sends a message to the LINE Bot of this system in response to user operation (7 in the figure).
-When LINE Bot receives a message for itself (8 in the figure) or exchanges it with LINE APP of the sending user after receiving it, specify userID of the user to ShoCard service Make an inquiry about the identity verification (9 in the figure).
The ShoCard service obtains the identity confirmation status of the user based on the ID federation 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 identity verification is completed, the fact is notified, and if not completed, the identity verification sequence is started from the server side (11 to 14 in the figure).
• The ShoCard service notifies the LINE Bot of the confirmation result when the personal identification sequence is completed (15 in the figure).

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

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

  When the ShoCard service is notified of the pair of userId and ShoCardID from the ShoCard APP, the user associates these and stores them in a predetermined storage unit (step S644), and starts the identity verification sequence specifying the notified ShoCardID. (Step S645). The personal identification sequence may be the same as the personal identification sequence shown in FIG. The result of the identity verification 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 terminal, and transmits a usage start message to the LINE Bot via the LINE platform (steps S651 to S653).

  When the LINE Bot receives the request for the usage start message, it returns OK to the LINE APP (step S654), and inquires for identity verification specifying the userId to the ShoCard service (step S655).

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

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

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

  In the above example, the method of passing the ID when providing the service including the identity verification to the user on any SNS designated as the service providing destination has been described, but the service provision performed on the IMS The pre-processing may be, for example, user authentication or eligibility confirmation other than the identity verification, or a combination thereof.

  Moreover, although the example using "LINE" and "ShoCard" was shown in the specific example of the delivery method of said ID, SNS and IMS to utilize 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 acquire the SNS_ID in combination with the IMS_ID of the user of the service providing destination. Can be linked. Since the user's IMS_ID and SNS_ID can be linked on the server that provides the service on SNS, the server can provide the service including object confirmation only by requesting the disclosure of the minimum personal information necessary for providing the service. can do.

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

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

  In the personal information management system in the present invention, one personal ID is assigned as identification information that associates 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 personal information owned by the user, but may be associated at least with 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 identification information associated with various 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 the personal information of the user. Here, the block chain is a data group having a predetermined data structure called a block arranged in time series, and has a role as a ledger in which the contents of the transaction are described. In addition to the data desired to be recorded in the block, such as transaction details, 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 (nonces, signatures, etc.) And. A nonce is a value in a data area in which a value obtained when data in the area is processed by a 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 the consensus algorithm, “Hash value of block is less than or equal to threshold value (target value)” for each block (data group) including information of previous block and nonce A rule such as "is determined in advance, and when adding a block, processing is performed in which a plurality of nodes search simultaneously and in parallel a nonce that satisfies such a rule. Besides PoW, there is a consensus algorithm such as BFT (Byzantine fault tolerance).

  However, without storing personal information as it is in the block chain, the hash value of the personal information is recorded in association with the hash value of the personal ID. At this time, the signature of the person who created the hash value (generation source) is attached to the hash value. The signature is, for example, the signature of the person who is the owner of the personal information, or the signature of a third party organization (hereinafter referred to as a verification organization) which has confirmed that the personal information is correct. As a signature, a digital signature obtained by encrypting information to be signed (in this case, a hash value) with a signer's private key can be used. By adding a signature of the creation source to the hash value, the reliability of the hash value, more specifically, the hash value is the one created by the signer (the creation source certificate) and the signature It is possible for the party who refers to the hash value to confirm that the data has not been tampered with from the time (non-falsified certificate). By performing a creator certificate and a non-falsification certificate of such a hash value, the hash value which is registered information can be trusted, that is, the information possessed by a legitimate owner or a verification agency confirms its legitimacy Make it possible to confirm from the signature that it is the information created from the stored information. In addition, it is also possible to perform encryption instead of the process of attaching a signature.

  The reliability of the information (hash value and the signature attached to it) itself registered in the block chain is secured by the tamper resistance of the block chain.

  On the other hand, personal information which is the original data of the hash value is held in a secure environment so as to be hidden by persons other than the principal. For example, 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, in the case of disclosure, which personal information is to be disclosed.

  In the personal information management system according to the present invention, the block chain to which a third party can refer is the personal information of the 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 that indicates the correctness of the personal information, the secrecy of personal information is secured. Also, at that time, by combining identification information for identifying the owner of personal information into one, the procedure of object confirmation which has been different for each application is designated by one identification information (personal ID). Be able to do this by a uniform process.

  Furthermore, in the personal information management system according to the present invention, when object confirmation is performed using the hash value of the user's personal information stored in the block chain, the block chain indicating the record of the confirmation is used as the block chain. Add to Thus, by leaving the history of the record of confirmation in the block chain, it is possible to use the result of the object confirmation in the past for object confirmation of the same purpose without the disclosure of specific personal information. For example, for a user whose target has been checked for the same purpose in the past, the information in the block chain is collated using the hash value of the personal information without requiring the disclosure of personal information. Just to be able to give results similar to the results of past object confirmations. This will minimize the 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 with personal information, but the personal ID is a single device such as a mobile phone, an IC card or an authentication device. Since they are not managed in association, 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 in the present invention will be described while presenting a specific system configuration.

  FIG. 8 is an explanatory view showing an example of holding various information in the personal information management system of the second embodiment. FIG. 8 shows the client device 1 possessed by the user, the verification agency device 2 possessed by the verification agency, and the block chain 3.

  In FIG. 8, the client device 1 holds a key pair (the secret key 11D and the public key 12D) for signature of the user, and the 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 verification authority device 2 holds a key pair (secret key 21D and public key 22D) for signature of the verification authority.

  In addition, the block chain 3 holds a registration block and a confirmation recording block as described below.

  For example, when an individual starts using the personal information management system, the personal ID 13D is assigned to the individual who is the user, and a key pair for signing (secret key 11D and public key 12D) is generated. When the personal ID 13D is assigned and the key pair is generated, the user operates the client device 1 to select a hash value of the personal ID 13D and personal information 14D (especially, personal information used for object confirmation) to be registered. Calculate a hash value, create a personal information management block including them, and add it to the block chain.

  In FIG. 8, a block n−1 is shown as an example of the registration block added to the block chain 3. The registration block includes personal ID_Hash 31D (corresponding to the hash value of the personal ID 13D described above), personal information Hash32D (corresponding to the hash value of the personal information 14D described above), and the signature 33D of the person who created them. Be Here, the signature 33D of the principal is a signature for indicating that the personal ID_Hash 31D and the personal information Hash 32D included in the block are those created by the user who is the legitimate owner of the original data.

  The personal information Hash 32D is preferably calculated for each unit where the user who is the owner of the personal information discloses the personal information (see FIG. 9A). At that time, it is also possible to attach the personal signature 33D to each personal information Hash 32D (see FIG. 9B). FIG. 9 is an explanatory view showing another example of the signature method of the registration information in the registration block. In FIG. 9, dotted lines represent signature target data of the signature 33D of the user.

  If there is a plurality of pieces of personal information that the user wants to register, the user can add those hash values to the block chain 3 as separate registration blocks. In any case, in the registration block, the personal ID_Hash 31D of the user and the personal information Hash 32D may be associated with the signature of the creation source. Note that the personal ID can also be regarded as one of the personal information, in which case the registration block includes the hash value of the personal ID and other personal information of two or more personal information together with the signature of the creator. It should just be.

  Although not shown, each block may include, besides the above, information indicating the public key of the signature creation source, the type of the block, the type of each registration information, and the like.

  In addition, control information required for the block to form a part of the block chain, for example, the hash value of the previous block or the signature of the person who added the block, is added to each block constituting the block chain 3 Etc. are included. The control information is determined by the specifications of the block chain used.

  Hereinafter, the case where a license is registered as personal information will be described using an example. The license includes multiple personal information such as name, address, face picture, date of birth, license number, and expiration date, but the user photographed the entire license as personal information used for object confirmation. A license image may be used. In that case, a registration block including the hash value of the license image as the personal information Hash32D is registered in the block chain 3. The license image itself, which is personal information, may be held in the secure area of the client device 1, or may be divided and encrypted and held in the distributed file system.

  When registering a license as personal information, besides dividing the entire license into one image, it is divided into units for which disclosure is desired to be controlled into multiple partial images, or units for which the disclosure is to be controlled are set. For each unit, only the part is identifiably processed into a plurality of processed images, or if it is information that allows text input (such as address, date of birth, name, etc.), it is converted to data by text input etc. May be registered as personal information. In that case, it is also possible to hold the license image (whole), the partial image, the processed image, and the text data as personal information of different types.

  For example, when the user wants to register an image (the above partial image or processed image) which can identify only the area in which the date of birth of the license is described as date of birth data which is one of personal information. Calculates the hash value of the personal ID of the user and the hash value of the date of birth data, and combines them individually or collectively into a single signature and attaches the signature of the individual A registration block in which the registered hash value is registered may be added to the block chain 3.

  Next, the case where user's object confirmation is performed using the information registered in the block chain 3 will be described. The confirmation organization device 2 of the confirmation organization that wants to confirm the object acquires the personal ID 13D and the personal information 14D (hereinafter referred to as the first personal information) used for the object confirmation from the client device 1 of the confirmation target user . Then, the verification engine 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 a key, or the user as described later The hash value or the like of the registered block obtained from the block registration history or the like held by may be obtained, and may be obtained by searching the block chain 3 using the key. It is only necessary to be able to search based on the information published in at least the block chain 3. When the corresponding registration block is searched, the verification agency device 2 is the disclosing person who disclosed the personal information (in this case, the user (in this case, the personal information), the information (personal ID_Hash 31D or personal information Hash 32D) registered in the registration block. ) And that it has not been tampered with since the time of signing (non-falsified proof), the signature 33D of the principal attached to the information, and the public key 12D of the user identified as the signer To confirm (reliability confirmation of registration information). Further, the verification engine device 2 collates the personal information Hash32D in the retrieved registration block with the hash value calculated from the first personal information acquired from the user (consistency confirmation of the original data). The confirmation of 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.

  The verification agency device 2 indicates that the personal information 14D of the user indicated by the personal ID 13D obtained from the disclosing person is the first personal information obtained from the disclosing person if the two confirmation results are both OK. Then, based on the disclosed first personal information, the necessary confirmation (identification, user authentication, and eligibility confirmation) is performed in the confirmation organization.

  As an example, consider that the verification agency device 2 performs age verification of the service request source user as a condition of service qualification. In this case, the verification agency device 2 sends the personal ID 13D to the client device 1 of the user, and date of birth data as the first personal information (for example, a partial image of a license image, a processed image or text data) You may require the disclosure of The date of birth data to be the first personal information has at least its hash value registered in the registration block together with the hash value calculated from the personal ID 13D of the user, that is, the personal information in the registration block It is assumed that it is the original data of Hash32D.

  Having obtained these pieces of information, the verification agency device 2 acquires a registration block in which the hash value of the disclosed birth date data of the user indicated by the disclosed personal ID 13D is registered. Upon acquiring the registration block, the verification authority device 2 is a creator (user principal) of the hash value (personal information Hash32D) of the date of birth data included in the registration block and the signature 33D of the principal attached to the personal ID_Hash 31D. The decryption is performed using the public key 12D, and the reliability of the obtained decrypted data (the hash value to be signed) is confirmed (reliability confirmation of the registration information). Here, as the creation source public key, the one in the block may be used, or the public key of the discloser who disclosed the first personal information may be used as the user.

  In addition, the verification agency device 2 collates the personal information Hash32D included in the registration block with the hash value created from the date of birth data disclosed by the user as necessary, and determines whether the both match each other. Confirm (Consistency check of the original data). As already described above, when the registered block is searched using the hash value calculated from the disclosed personal information as a key, the consistency check of the original data is substituted for the search processing (search Block matches the original data).

  When the reliability check of the registered information and the consistency check of the original data are both OK, the verification agency device 2 is the user identity indicated by the disclosed personal ID of the disclosed date of birth data Age confirmation is performed based on the date of birth data as it is correct personal information of the discloser. As a result, the verification agency device 2 may provide, for example, services with age restrictions. In this way, the verification agency device 2 obtains the personal ID 13D and the date of birth data from the requester of the service only, and whether the date of birth data is the date of birth data of the disclosing person or not Even if the identity verification is not performed by itself, it is possible to perform the identity confirmation (age confirmation) based on the disclosed date of birth data.

  Further, when the verification engine device 2 performs object verification using the information in the block chain 3, the verification organization device 2 registers the verification recording block indicating the recording of the verification in the block chain 3.

  In FIG. 8, block n and block n + 1 are shown as examples of the confirmation recording block added to the block chain 3. The confirmation recording block includes at least the personal ID_Hash 31D (corresponding to the hash value calculated from the personal ID 13D disclosed by the user) and the signature 35D of the confirmation organization that is the creation source. 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 of a confirmation agency (confirmation agency ID etc.) or information indicating a confirmation item. By registering such confirmation information 34D, it is possible to eliminate the need to perform duplicate processing when performing object confirmation for the same purpose thereafter. For example, the information on the confirmation agency may be, for example, a confirmation agency ID identifying the confirmation agency. In addition, the confirmation items include, for example, information of blocks used for object confirmation (this makes it possible to know the hash value and type of personal information used for object confirmation), results of object confirmation (various operations performed during object confirmation And the type of service provided as a result of target confirmation, the type of eligibility that the service requires, and the like.

  If such a confirmation recording block is included in the block chain 3, the confirmation organization will subsequently receive the personal ID disclosed by the user without the disclosure of specific personal information (for example, date of birth data). Based on the hash value of the personal information, it is possible to give the user 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. Also, the user can prevent unnecessary disclosure of personal information.

  In the above example, the type of service given to the user in the past and that are required from the personal ID of the user and the hash value of the date of birth without receiving the disclosure of the date of birth data It is possible to give its users the same services and qualifications as the types of qualifications to be made. In addition, for example, when the purpose of use and the use organization are limited, it is possible to specify what kind of personal information has been used for the user from the signature 35D of the confirmation institution and what kind of object confirmation is performed. It is also possible to give the result of the same object confirmation to the user even without the confirmation information 34D. Even in such a case, it is assumed that the reliability confirmation based on the signature is performed on the registration information of the confirmation recording block which is regarded as the confirmation recording of the user.

  In addition, the client device 1 of the user holds key information (block hash value etc.) in the block chain 3 of the block in which his / her information (at least personal ID_Hash 31 D) is recorded as registration history and wants to use it at object confirmation It is also possible to specify block key information.

  By the way, the above-mentioned credibility judgment of the registered information is that the personal ID of the user, the personal information and the secret key are in a state of secrecy from the third party, and the signer (the person who created their hash value) is correct personal ID and It is assumed that a hash value is created from personal information. However, if a legitimate user intentionally tampers (such as falsification of personal information), 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) However, the legitimacy of the original data (personal ID itself and personal information itself) is not guaranteed.

  For example, in the case where the first personal information used for object confirmation is information derived from the user's living body such as a face picture or biological information, it is generated from the hash value generated from the disclosed first personal information and the disclosed personal ID 13D. The first disclosed personal information or disclosure from the correspondence relationship with the hash value and the similarity between the disclosed first personal information and the equivalent information obtained from the disclosing person (such as current biometric information) It is possible to confirm the legitimacy of the original data of the hash value of the first personal information, that is, the legitimacy of the disclosing person who disclosed the personal ID 13D as personal information of the user himself indicated by the personal ID 13D.

  However, in the case where the disclosed first personal information is information other than information derived from the user's living body (for example, attribute information such as name, address, date of birth, etc.), the reliability of personal information Hash32D included in the registration block The confirmation alone can not confirm the legitimacy of the first personal information which is the original data.

  Therefore, the registration block may be added after having a predetermined confirmation organization confirm the legitimacy of the personal information in consideration of the intentional fraud of the user. At this time, the signature 35D of the verification organization may be added to the personal information Hash 32D instead of or together with the signature 33D of the principal. Even when the signature 35D of the verification organization is attached instead of the signature 33D of the principal, the signature 33D of the principal is attached to the personal ID_Hash 31D, which causes no problem. In addition, when the signature 33D of the principal and the signature 35D of the verification organization are combined, the signature target data with one signature attached may be regarded as one data, and the other signature may be attached, or the like. Each of the signature target data may be signed.

  FIG. 10 is an explanatory view showing another example of the signature method of the registration information in the registration block. In FIG. 10, the dotted line represents the signature target data of the signature 33D of the user, and the dashed line represents the signature target data of the signature 35D of the verification organization. FIG. 10A shows an example of the case where the signature 35D of the verification organization is attached to the personal information Hash 32D instead of the signature 33D of the user. 10 (b) to 10 (f) show an example in which the personal information Hash 32D is combined with the signature 33D of the user and the signature 35D of the verification organization. In the example shown in FIG. 10 (b), the signature 33D of the user and the signature 35D of the verification organization are attached to the personal information Hash 32D which is the signature target data, and the example shown in FIGS. 10 (c) to 10 (f). In the nested structure, the signature 33D of the user and the signature 35D of the verification organization are attached. Here, “nested structure” means that one signature is attached to the signature target data first, and data including the signature is used as new signature target data and the other signature is attached. Note that the signer who signs later may include the data to be signed or other data in addition to the previously attached signature. In any case, when checking the reliability of the registration information in the target confirmation, in which structure and in which data the signature is attached to whom the information is attached in advance or in the block, etc. It shall be understood from As a result, if another verification agency can obtain the hash value of the personal ID, the hash value of the personal information, the public key of the person, and the public key of the verification institution, the reliability of the registered information Enable verification of the authenticity of the signature 35D of the verification agency that has confirmed the legitimacy).

  For example, in the example shown in FIG. 10 (c), the personal information Hash 32D, which is one of the registration information, is first attached with the signature 33D of the person, and the signature 33D of the person and the signature target data (personal information Hash 32D) As a new signature target data and attached with the signature 35 D of the verification organization. Further, for example, in the example shown in FIG. 10 (d), the personal ID_Hash 31D and the personal information Hash 32D, which are two pieces of registration information, are first attached with the signature 33D of the person, and the signature 33D of the person and the data to be signed (the person ID_Hash 31D and personal information (Hash 32D) are used as new signature target data, and the signature 35D of the verification organization is attached. In FIGS. 10 (c) to 10 (d), it is possible that the verification organization adds the signature 35D of the verification organization as new signature target data with only the signature 33D of the person who is the previous signature. For example, in the example shown in FIG. 10 (e), the signature 35D of the verification organization is attached to the personal information Hash 32D, which is one of the registration information, first, and the signature 35D of the verification organization and the signature target data (personal The information Hash 32D) is used as new signature target data, and the signature 33D of the person is attached. It is also possible for the principal to add only the signature 35D of the verification organization as new signature target data and to attach the signature 33D of the principal. For example, in the example shown in FIG. 10 (f), the signature 35D of the checking organization is attached to the personal information Hash 32D, which is one of the registration information, first, and the signature 35D of the checking organization and the signature target data (personal The information Hash32D) and other registration information (personal ID_Hash31D) are used as new signature target data, and the signature 33D of the user is attached.

  In the personal information management system, as shown in FIG. 9 and FIG. 10, there is a one-on-one correspondence with the registered information (for example, personal ID_Hash 31D or personal information Hash 32D) even if the signature of the person or the confirmation organization is not attached. If the signature target data of the signature includes the registration information that is the purpose of the signature or another signature that uses the registration information as the signature target data (including the case where the signature information is included by the nested structure) The registration information is regarded as having a certain signature attached thereto.

  Therefore, when a certain registration information is to be registered by adding the signature of the person, the registration information which is integrated with the other registration information and which has the signature of the person, and which is the signature target data of the other signature The signature target data including the signature added to the principal, the signature subject data including the other signature attached to the registration information preceded by the other signature, the signature added to the signature of the principal Also included are those to which the signature of the person in question attached to the registration information attached earlier is used as the signature target data and to which another signature is attached.

  For example, the confirmation organization device 2 of the confirmation organization requested to confirm the legitimacy of the first personal information is, from the client device 1, the first personal information and the fact that the first personal information is correct. You may acquire the 2nd personal information which can be confirmed. Then, after confirming that the first personal information is correct based on the second personal information, the verification organization device 2 calculates and obtains the hash value (personal information Hash32D) of the first personal information. The hash value is returned to the client device 1 with its own signature (signature 35D of the verification authority). When the client device 1 receives the hash value of the personal information with the signature of the verification authority, the client device 1 creates a registration block by combining it with the hash value of the personal ID with the signature 33D of the principal (personal ID_Hash31D), and then the block chain 3 May be added to

  For example, the confirmation organization that performs the legitimacy confirmation of the personal information may be an organization that issued the personal information (for example, a police agency or the like in the case of license information). In that case, the verification organization device 2 of the verification organization as the issuer, for example, information (identification number, face photograph, credit card number, password, etc.) that can be identified or authenticated by the verification organization. The first personal information issued by the user and the first personal information requested for confirmation after acquiring as the second personal information and checking whether they match the authentication information held by the self. The legitimacy may be determined by confirming whether or not there is a match. Then, if the legitimacy can be confirmed, a hash value of the first personal information acquired from the user may be calculated, and the hash value may be added with its own signature and sent back to the client device 1. Hereinafter, the second personal information acquired by the verification organization that performs the legitimacy confirmation of the personal information may be referred to as the legitimacy confirmation information.

  In addition, it is also possible to create a registration block and add it to the block chain 3 on the side of the confirmation organization without replying to the client device 1. In that case, the verification agency device 2 may further acquire from the client device 1 the personal ID_Hash 31D to which the signature 33D of the user is attached. The personal information Hash32D with the signature 33D of the person in question or the personal ID_Hash31D as registration information with the signature 33D of the person in question may be acquired as necessary.

  If such a registration block is included in the block chain 3, the verification authority thereafter does not need to confirm the legitimacy of the first personal information disclosed by the user, and the registration information in the block is The personal information can be used for object confirmation only by performing the reliability check of (personal ID_Hash 31D and personal information Hash 32D) and the consistency check of the original data. However, the verification agency is the verification authority of the registration information, in addition to the creation source certificate (in this case, the registration source certificate) and the non-falsification certificate of the signature target data with the signature by the signature 33D of the principal. The certification of the signature target data with the signature 35D by the signature 35D of the signature target data (in this case, the registration source certificate) and the non-tamper proof.

  The timing of confirming the legitimacy 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, after registration of the registration block, it is possible to have a predetermined confirmation organization confirm the legitimacy of the personal information. In that case, the verification organization checks the validity of the original data of the registration information (more specifically, the first personal information whose identity with the original data of the registration information is confirmed) (identity confirmation or user confirmation) Assuming that authentication is performed, for example, a confirmation recording block as shown in FIG. 11 may be registered in the block chain 3. The confirmation record block shown in FIG. 11 includes, in the confirmation information 34D, personal information Hash32D included in the registration information in which the validity of the original data of the registration information has been confirmed, the result (OK) of the identity verification, and the validity of the original data. It contains information on the confirmation result (OK).

  The object confirmation including the confirmation of the legitimacy of the personal information which is the original data of the registration information is, for example, personal information disclosed by the client device 1 of the confirmation agency device 2 in the process of the object confirmation described above (first individual This can be realized by acquiring second personal information that can be confirmed by the confirmation agency that the information is correct. The method of confirming the legitimacy of the first personal information from the second personal information is as described above. When the legitimacy of the first personal information can be confirmed by visual inspection or the like from the first personal information in the confirmation organization, the acquisition of the second personal information is omitted.

  In addition, it is also possible for confirmation organizations other than the issuer of the personal information to confirm the legitimacy of the personal information. In that case, the confirmation agency device 2 of the confirmation agency is the second personal information including in its part the first personal information or the information indicating the equivalent content thereof in the process of the above object confirmation, and further the second personal information You may acquire what can confirm in the confirmation agency or this system that the personal information (2nd personal information) is correct. In addition, even if any organization confirms the legitimacy, acquisition of the second personal information is omitted when the legitimacy of the first personal information can be confirmed by visual inspection or the like from the first personal information in the organization. Be done.

When a verification organization other than the issuer checks the validity of the personal information, for example, personal information satisfying any of the following conditions (1) to (3) as the second personal information (validity confirmation information): You may use.
・ (1) (a) “(a1)“ the information indicating the first personal information or the same content ”and (a2)“ the original copy of the information including at least the information that can be identified ”or It is a copy of the original.
(2) (b1) “Information including at least (a1)“ information indicating the first personal information or the same content ”” and (b2) “issuance to the original data of the hash value The block to which the signature of the original confirmation agency is attached is the information registered in the block chain.
(3) (c) “A set of information capable of identifying the user in an organization (legal information holding institution) that holds legitimate first personal information and authentication information capable of user authentication”.

  For the condition (1), for example, consider the case where the original license or the copied image of the license including (a) = (a1) birth date data and (a2) face image in an integrated manner. In such a case, if it is confirmed that the disclosing person is the person by visual inspection or comparison with information similar to (a2) acquired from the current user regarding (a2) in the disclosed (a), (A1) can also be regarded as the information of the person. After that, (a1) in the disclosed (a) may be compared with the disclosed first personal information. At this time, a copy image may be obtained from the original at the time of object confirmation. The comparison between (a1) in the disclosed (a) and the disclosed first personal information includes the comparison between image data and text data. When information equivalent to (a2) is further acquired from the current user in order to confirm the legitimacy of the second personal information, the information may be referred to as third personal information. In this case, the personal identification information may be referred to as personal identification information including the third personal information.

  Further, for the condition (2), for example, it is assumed that the health insurance card image (whole) including (b1) = (a1) date of birth data. In such a case, if a block in which the signature of the verification authority of the issuing source is attached to the original data of the disclosed hash value of (b1) is registered in the block chain 3, If the reliability and the match between the disclosed (b1) and the original data of the hash value in the block are confirmed, the correctness of the disclosed (b1) is confirmed. Thereafter, (a1) in the disclosed (b1) may be compared with the disclosed first personal information.

  In addition, for condition (3), if (c) = a combination of such user identification information and authentication information, (c) is sent to the authorized information holding organization together with the first personal information, and (c) is By performing user authentication on the basis of the user, the user is sent back the result of comparison between the transmitted first personal information and the legitimate first personal information of the user held by the legal information holding organization. The legitimacy 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 recording block of the user is not attached with the signature 35D of the confirmation organization that has confirmed the legitimacy of the original data, The confirmation authority device 2 may perform object confirmation including validity confirmation of the first personal information used for object confirmation. Specifically, the verification agency device 2 may further request the disclosure of the second personal information as described above at the time of object verification.

  In addition, the personal information management system may perform the above processing after performing user authentication on the personal ID when the user discloses the personal ID, as necessary. User authentication can use existing authentication technology.

  In addition, the above-mentioned addition of the registration block, addition of the confirmation recording block, the reliability check of the registration information in the block, the consistency check of the original data, the concrete process in the legitimacy check of the original data, etc. Is performed by the personal information management system using a user interface (UI) or an application program interface (API) provided by the personal information management system.

  Next, the 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 organization side system 20, a ledger management system 30, and a management side system 50.

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

  However, this classification is based on the access authority of information, and does not limit the operating environment of an actual program. For example, the functions of a part of the registration unit 102 (except for 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 the devices included in the management system 50. It may be done.

  Although not shown, the user side system 10 includes at least the client device 1. Also, the verification authority system 20 includes at least the verification authority device 2.

  The processing units excluding the data storage unit 101, the data storage unit 201, and the data storage unit 501 are connected via the network 40, respectively. The network 40 may include a plurality of different networks such as the Internet and the Ethereum network. The data storage unit 101 may be connected to the registration unit 102, the disclosure unit 103, and the authentication unit 104. Further, the data storage unit 201 may be connected to the confirmation unit 202. Further, the data storage unit 501 may 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 in another system 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 pair key for signing (the secret key 11D and the 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 included in an apparatus (for example, the client device 1) included in the user side system 10 or an apparatus included in the user side system 10 It is realized by a possible split file system.

  The registration unit 102 is a registration block having 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) according to an instruction from the user. Is registered in block chain 3. Since the actual registration is performed by a ledger management node 301 described later through a predetermined procedure, the registration unit 102 performs processing for adding a registered block to the block chain 3 via the ledger management node 301. The registration unit 102 only needs to be able to provide the user with a procedure for registering such a registration block in the block chain 3.

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

  The registration unit 102 may transmit a request for confirming the legitimacy of the personal information 14D, which is the original data, together with the personal information 14D to the confirmation unit 202 of the predetermined confirmation organization as necessary. Thereby, at least the signature 35D of the verification agency for the personal information Hash 32D may be obtained. Furthermore, the registration unit 102 requests addition of a registration block including personal information Hash32D, personal ID_Hash31D, at least the signature 35D of the confirmation agency for the personal information Hash32D, and at least the signature 33D of the person for personal ID_Hash31D as registration information. The (block addition request) may be transmitted to the ledger management node 301 described later.

  In addition, the registration unit 102 may transmit, to the confirmation unit 202 of the predetermined confirmation organization, a request to confirm the legitimacy of the personal information 14D and to register the registration block together with at least the personal ID_Hash 31D to which the signature 33D of the person is attached. In that case, the confirmation unit 202 requests addition of a registration block including the personal information Hash32D, the personal ID_Hash31D, at least the signature 35D of the confirmation organization for the personal information Hash32D, and the person's signature 33D for the personal ID_Hash31D as registration information ( The block addition request may be transmitted to a ledger management node 301 described later.

  The disclosure unit 103 outputs the designated personal information 14D or the hash value thereof 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 designated from the confirmation unit 202, the disclosure unit 103 inquires of the user whether or not the disclosure is made, and then the designated personal information 14D or the hash value thereof is designated. Output to the output destination (the confirmation unit 202 or the display unit of the request source). In addition, when the hash value of the personal information 14D is registered in the block chain 3 as the confirmation recording block or the registration block together with the result of the target confirmation for the same purpose and the signature of the confirmation organization, the disclosure unit 103 designates the specified personal information. Instead of 14D, it is also possible to output a hash value of the designated personal information 14D. At that time, the disclosure unit 103 may output designated information after inquiring of the user which information to disclose, or may output the hash value with priority without making an inquiry. Good. When the hash value of the personal information is output instead of the personal information, the disclosure unit 103 may output the information of the confirmation recording block at that time.

  The authentication unit 104 performs user authentication on the current user when another processing unit accesses the personal ID 13D. For example, when detecting the access to the personal ID 13D, the authentication unit 104 requests the current user to input the authentication information, collates the input authentication information with the authentication information held in advance, Perform user authentication of the user. In addition, when the user authentication with respect to personal ID 13D is unnecessary in the user side 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 capable of accessing the data storage unit 101, for example, installed in an apparatus included in the user side system 10.

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

  The data storage unit 201 holds information required by each processing unit belonging to the confirmation organization side system 20 and information disclosed in another system included in the personal information management system 100 as information of the confirmation organization. The data storage unit 201 stores, for example, a verification agency ID and a pair key for signing (secret key 21D and public key 22D). In the present embodiment, at least a part of the data storage unit 201 is from a storage device having a secure area included in an apparatus (for example, the verification engine device 2) included in the verification engine system 20 or an apparatus included in the verification engine system 20 It 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 whose service has been requested by the user. The confirmation unit 202 is a user based on, for example, the information acquired from the disclosure unit 103 of the designated user and the information registered in the block chain 3 (information in the registration block and the confirmation recording block). Confirm the target of

  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 object confirmation or its hash value (personal information Hash 32D). Further, the confirmation unit 202 searches the registration block or the confirmation recording block of the user based on the obtained information and the registration history of the block held by the user side system 10. Then, using the obtained registration block or confirmation recording block of the user, the reliability check of the registration information as described above, the consistency check of the original data, and the validity check of the personal information are performed, and those checks are performed. Output the results or perform object confirmation based on those confirmation results. In addition, target confirmation itself is output of the judgment result of the validity of the disclosed information judged based on the reliability check of registration information, the consistency check of original data, the validity check of personal information, or a combination thereof. Based on this, the user of the verification organization may perform. In that case, the confirmation unit 202 receives the object confirmation result performed by the user.

  In addition, the confirmation unit 202 creates a confirmation recording block indicating the recording of the target confirmation as necessary, and performs processing for adding it to the block chain 3. The confirmation recording block includes at least the hash value (personal ID_Hash 31D) of the personal ID 13D of the user who has made the target confirmation, and the signature 35D of the confirmation agency for it.

  The confirmation unit 202 only needs to be able to provide the confirmation organization with such an object confirmation and a registration procedure of such a confirmation recording block in the block chain 3. In the present embodiment, the confirmation unit 202 is realized by, for example, a CPU or the like capable of accessing the data storage unit 201, such as being installed in a device provided in the confirmation organization side system 20.

  Although only one user side system 10 and one confirmation organization side system 20 are shown in FIG. 12, the user side system 10 is provided for each user, and the confirmation organization side system 20 is also a confirmation organization. Provided for each

  The ledger management system 30 is a system in which a block chain is used as a ledger, and a plurality of nodes share and manage the ledger. Although a ledger management system is exemplified as a system for managing block chains, terminals in the system that can execute processing according to a predetermined consensus algorithm (hereinafter referred to as "consensus processing") and which can not be easily tampered are shared 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 block chain 3 through the execution of the consensus process.

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

  The data storage unit 501 holds information necessary for each processing unit belonging to the management side system 50 and information disclosed as information of the management side system 50 to other systems included in the personal information management system 100, if any. Do. The data storage unit 501 may store, for example, information of a personal ID assigned to a user, or a program (such as an execution code) in which a procedure performed by a processing unit of another system included in the personal information management system 100 is implemented. 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 included in the management side system 50 or a divided file system accessible from devices included in the management side system 50.

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

  FIG. 13 is a block diagram showing a configuration example of the confirmation unit 202. As shown in FIG. 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 matching unit 223, a personal information validity confirmation unit 224, and a result output unit 225. , And a confirmation record registration unit 226 may be included.

  The data acquisition unit 221 receives information necessary for object confirmation from the user side system 10 (in particular, the disclosure unit 103) together with the personal ID 13D (for example, personal information 14D or its hash value, or the user's past confirmation record block Get information etc.) In addition, the data acquisition unit 221 searches the block chain 3 based on the information acquired from the user side system 10, and the information of the user (in particular, personal information 14D required for object confirmation or its hash value, The block including the record (confirmation information 34D etc.) to the effect that object confirmation was performed using it is acquired.

  For example, when acquiring the personal ID 13D and the personal information 14D from the user side system 10, the data acquisition 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. Also, 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 side system 10, the hash value calculated from the personal ID 13D and the hash value of the personal information 14D And may be obtained from the block chain 3. Also, 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. Also, for example, when the data acquisition unit 221 acquires the hash value of the personal ID 13D and the information of the past confirmation recording block from the user side system 10, the data acquisition unit 221 acquires the latest confirmation recording block from the block chain 3. It is also good.

  The data acquisition unit 221 may determine what kind of information to be acquired from the user side system 10 from the confirmation record of the user.

  The registration information reliability confirmation unit 222 confirms 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 the block includes a plurality of signatures, the registration information reliability check unit 222 verifies the reliability of the signature target data of the designated signature by checking each signature with the decryption result of the signature. . At this time, when a signature specified in a nested structure is attached in a nested structure, decryption processing is performed in the opposite direction to the order of encryption processing when the signature is attached, and the signature target data of each signature And the decryption result of the signature may be verified to confirm the final reliability.

  When the data acquisition unit 221 acquires the personal information 14D of the user and acquires a block including the personal information Hash 32D which is the hash value of the personal information 14D, the original data matching unit 223 checks the inside of the block. The matching between the personal information that is the original data of the personal information Hash32D and the acquired personal information 14D is confirmed. For example, the original data matching unit 223 checks the hash value calculated from the personal information 14D obtained by the data acquisition unit 221 against the personal information Hash32D in the block, thereby generating the original of the personal information Hash32D in the block. The consistency between the personal information to be data and the acquired personal information 14D may be confirmed.

  When the data acquisition unit 221 obtains personal information (first personal information) used for object confirmation, the personal information validity confirmation unit 224 confirms the legitimacy of the first personal information. The personal information legitimacy confirmation unit 224 is to be sure that the first personal information such as the biometric information of the current user (disclosure person), "information capable of personal identification", "information capable of user authentication in this system", etc. is correct The second acquiring unit 221 further causes the data acquiring unit 221 to acquire the second personal information that can be confirmed in the confirmation organization, and based on them, confirms the legitimacy of the first personal information.

  The result output unit 225 is a check result of the registration information reliability check unit 222, the original data consistency check unit 223, the personal information validity check unit 224, and the validity of the disclosed information judged based on them. Outputs the judgment result and the final object confirmation result. The final object confirmation is the confirmation result of the registration information reliability confirmation unit 222, the original data consistency confirmation unit 223, the personal information validity confirmation unit 224, and the validity of the disclosed information determined based on them. Based on the output of the sex determination result, the user of the verification organization may perform. In that case, the confirmation unit 202 receives the object confirmation result 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. In addition, the confirmation record registration unit 226 outputs the information of the confirmation record block to the user side system 10 as necessary.

  FIG. 14 is a block diagram showing a configuration example of the ledger management node 301. The ledger management node 301 shown in FIG. 14 includes a registration information reception 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 the registration block (block data) and the contents of the confirmation recording block (block data) as the information to be recorded in the 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. Also, the block generation unit 312 searches nonces, for example, as predetermined consensus processing for blocks generated by itself or blocks generated by another ledger management node 301 via the block sharing unit 313 described later. And add a block to a block chain (corresponding to a copy of block chain 3) managed by itself after processing for giving a signature. A block obtained by the plurality of ledger management nodes 301 performing predetermined consensus processing on the block generated by the block generation unit 312 is the block to be 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 appropriately selects information received by the registration information receiving unit 311, a block generated by the block generation unit 312, a block received from another ledger management node 301, and the like as appropriate. It transmits to the management node 301. Thereby, all the ledger management nodes 301 share the information and the latest block chain 3 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 required for verification processing in the block verification unit 315 described later, in addition to copying of the block chain 3.

  The block verification unit 315 verifies the information in the block when adding the block to the block chain held by itself. Usually, the block to be added is the block whose rule is satisfied earliest in the group of ledger management nodes 301 including the own node, but in consideration of the case where the malicious ledger management node 301 is included, etc. It may be verified whether the rules are actually satisfied.

  The configuration of FIG. 14 is merely an example, and the ledger management node 301 can execute predetermined consensus processing for sharing and managing the block chain 3 difficult to be tampered with by a plurality of nodes, and an external node The specific configuration is not limited as long as it is a node that can add information to the ledger and refer to the ledger according to the request from the server.

  Next, the operation of this embodiment will be described. The operation of the present embodiment is roughly divided into a registration phase of registering registration blocks in a block chain and a confirmation phase of performing object confirmation based on registration blocks registered in the block chain and past confirmation recording blocks. . Furthermore, in the confirmation phase, the user is made to disclose personal information, and the first confirmation phase in which the object is confirmed based on the registration block in the block chain 3, and without making the user disclose personal information, the block chain In the second confirmation phase, the target confirmation is performed based on the confirmation recording 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 flow chart showing an example of the operation in the registration phase of the personal information management system of this embodiment. In addition, the registration phase shown in FIG. 15 is an example in the case of registering a registration block, without performing the legitimacy confirmation of the personal information made into original data by the confirmation 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, personal ID_Hash 31D and personal information Hash32D is obtained (step S101). The registration unit 102 may perform access to the personal ID 13D and the personal information 14D after performing user authentication.

  Next, the registration unit 102 adds the signature 33D of the user to the personal ID_Hash 31D and the personal information Hash 32D obtained as described above, and registers the personal ID_Hash 31D and the personal information Hash 32D to which the signature 33D of the user is attached. 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 block chain 3 (step S103). At this time, the registration unit 102 may acquire key information of the registered registration block from the ledger management node 301 and hold the key information in the data storage unit 101 as a registration history.

  In this way, the block chain 3 is registered with the personal ID_Hash 31D which is the hash value of the user's personal ID 13D and the personal information Hash 32D which is the hash value of the user's personal information 14D. A registration block is added which is included as information.

  Moreover, FIG. 16 is a flowchart which shows the other example of the operation | movement in the registration phase of the personal-information management system of this embodiment. The registration phase shown in FIG. 16 is an example of the case where the registration block is registered after confirming the legitimacy of the personal information regarded as the original data by the confirmation organization.

  In the example shown in FIG. 16, first, the registration unit 102 of the user side system 10 reads 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 legitimacy of personal information, including the first personal information and, if necessary, the second personal information, to the confirmation unit 202 of the issuing agency's confirmation organization side system 20. (Step S112).

  When the confirmation unit 202 (for example, the personal information legitimacy confirmation unit 224) receives the request to confirm the legitimacy of the personal information, it confirms the legitimacy of the first personal information contained therein based on the second personal information. (Step S113). Further, when the verification unit 202 can confirm the legitimacy of the first personal information, the verification unit 202 calculates the hash value (personal information Hash32D), adds the signature 35D of the verification agency to the obtained hash value, It transmits to a request origin with a confirmation result (step S114-step S116).

  When confirmation of the legitimacy of the personal information is obtained, the registration unit 102 calculates a hash value (personal ID_Hash 31D) of the personal ID 13D (step S117), and attaches the signature 33D of the user to the obtained hash value. Then, a registration block is created in which the personal ID_Hash 31D to which the signature 33D of the person is attached and the personal information Hash32D to which the signature 35D of the verification organization is attached (step S118). In addition, the registration process to the block chain 3 of the created registration block may be the same as that of 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 flow chart showing an example of the operation in the confirmation phase of the personal information management system of this embodiment. 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 object confirmation is performed based on the registration block in the block chain 3.

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

  The disclosure unit 103 of the user side system 10 that has received the disclosure request 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 organization side system 20 that has received the personal ID 13D searches the block chain 3 for a confirmation recording block including the obtained hash value of the personal ID 13D (step S204). The data acquiring unit 221 may acquire information of the confirmation recording block indicating the recording of the target confirmation of the same purpose together with the personal ID 13D from the disclosure unit 103 in step S203, and may search the confirmation recording block based on them. Note that the disclosure unit 103 may obtain, for example, such block information from the registration history held by the user side system 10.

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

  When the disclosure unit 103 receives the disclosure request of the personal information, the disclosure unit 103 reads 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 to the request source after obtaining the permission of the disclosure of the personal information to the user.

  When 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 the hash value, is registered (step S208). ). The data acquisition unit 221 may acquire the personal information and the information of the registration block in which the hash value is registered from the disclosure unit 103 in step S207, and search for the registration block based on them.

  When the desired registration block is obtained as a result of the search, the registration information reliability confirmation unit 222 of the confirmation unit 202 uses the signatures attached to at least the personal ID_Hash 31D and the personal information Hash 32D-1 included in the registration block. In step S209, the reliability of the registration information is confirmed. In addition, the confirmation method of the reliability of registration information is as having mentioned above.

  In addition, the original data matching unit 223 of the checking unit 202 matches the original data of the personal ID_Hash 31D and the personal information Hash 32D-1 included in the registration block with the acquired personal ID 13D and the first personal information. Is checked by checking the hash values with each other (step S210: confirmation of matching of the original data). Note that the method of checking the consistency of the original data is as described above.

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

  In that case, in the process of confirming the reliability of the registration information in step S209, the reliability of the personal ID_Hash 31D and the confirmation information 34D included in the confirmation recording block may be confirmed based on the signature attached to them. Further, in the consistency confirmation processing of the original data in step S210, personal information Hash 32D-1 to be compared with the disclosed first personal information may be acquired based on the confirmation information 34D of the confirmation recording block. For example, the data acquisition unit 221 may acquire the hash value (personal information Hash32D-1) that is the verification target of the validity indicated in the confirmation information 34D. Also, for example, the data acquisition unit 221 includes, in the confirmation information 34D, information (such as TxID described later) of the registered block in which the hash value (personal information Hash32D-1) whose validity is to be confirmed is registered. If it is, the registration block may be searched from the information, and personal information Hash32D-1 included in the searched registration block may be acquired.

  If the desired registration block or confirmation recording block is not found as a result of the search, the fact that personal information used for object confirmation is not registered is transmitted to the user side system 10, and the process is ended. May be

  In addition, the confirmation unit 202 (for example, the personal information validity confirmation unit 224) uses the personal information Hash 32D-1 included in the registration block, for example, the signature 35D of the confirmation organization that satisfies a predetermined condition such as the issuer or the official information holding organization. If is not affixed, the legitimacy check may be performed on the first personal information.

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

  When receiving the disclosure request for 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 the validity confirmation information) and transmits it to the request source (Step S212, step S213). Similar to step S206, the disclosure unit 103 may transmit to the request source after obtaining the permission of disclosure of the personal information to the user.

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

  In the process of steps S211 to S214, if the personal information Hash32D-1 is attached with the signature 35D of the checking organization that satisfies the predetermined condition in the registration block in which the personal information Hash32D-1 is registered, It is omitted. In that case, the confirmation unit 202 may simply set the confirmation result of the legitimacy of the personal information in step S214 as confirmation OK.

  Next, the result output unit 225 of the confirmation unit 202 outputs the determination result of the legitimacy of the disclosed first personal information and the final result of object confirmation from the processing results up to now (step S215).

  The result output unit 225 is disclosed, for example, when the reliability check of the registration information of step S209, the consistency check of the original data of step S210, and the validity check of the personal information of step S214 are all OK. The first personal information may be determined as the disclosing person and 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 not the correct information of the user who is the disclosing person and the disclosed personal ID corresponds. . Also, for example, in the case where the result output unit 225 determines that the disclosed first personal information is correct as the disclosing person and the disclosed personal ID is the correct information of the corresponding user, Based on the personal information of 1, the confirmation target object may be confirmed by the confirmation organization, and the confirmation result may be output. Examples of object confirmation include age confirmation and eligibility confirmation of service. Here, as an example of confirmation of receipt qualification of service, collation with user information (settlement information and the like) in the checking organization side system specified by the disclosed first personal information can be mentioned.

  Next, the verification organization side system 20 (for example, a service providing unit (not shown)) outputs the determination result of the validity (including the personal identification) of the disclosed first personal information, which is output from the result output unit 225, The 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 present confirmation, and registers the block in the block chain 3 (steps S217 and S218). The confirmation record registration unit 226 generates, for example, confirmation information 34D indicating the effect of predetermined target confirmation OK for the personal information Hash 32D-1 in the registration block and the effect of the person confirmation OK. Further, the confirmation record registration unit 226 calculates, for example, the hash value (personal ID_Hash 31D) of the personal ID 13D acquired in step S203. Then, a signature 35D of the confirmation organization is generated with respect to the personal ID_Hash 31D and the confirmation information 34D thus obtained, and a confirmation recording block including the personal ID_Hash 31D and the confirmation information 34D to which the signature 35D of the confirmation organization is attached is created. You may The block registration process may be the same as step S103.

  Thus, for example, when the first object confirmation is performed, the confirmation indicating the confirmation result for the personal ID_Hash 31D and the personal information Hash32D-1 to which the signature 35D of the confirmation organization which has made the object confirmation is added to the block chain 3 A verification record block is added which includes the information 34D.

  Next, the operation of the personal information management system in the confirmation phase will be described with reference to FIG. FIG. 18 is a flow chart showing an example of the operation in the confirmation phase of the personal information management system of this embodiment. The confirmation phase shown in FIG. 18 is an example of a second confirmation phase in which the target confirmation is performed based on the confirmation recording block in 3 in the block chain without making the user disclose personal information.

  Also in the example illustrated in FIG. 18, the confirmation unit 202 (for example, the data acquisition unit 221) of the confirmation organization side system 20 first transmits a personal ID disclosure request to the user side system 10 (step S201). 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 recording 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 target confirmation from the processing results so far (step S215). In this example, the result output unit 225 outputs that the confirmation result included in the confirmation information 34D of the confirmation recording block is obtained in the past, if the result of the reliability confirmation of the registration information in step S209 is OK. Or you may use the past object confirmation result as it is. At this time, if the result output unit 225 is a confirmation record by a confirmation organization other than itself, the result output unit 225 outputs the confirmation organization that performed the object confirmation and the confirmation content thereof without using it as it is, You may inquire whether or not to use the target confirmation result.

  If it can be incorporated, the verification organization 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). In addition, what is necessary is just to perform the process after step S205 shown in FIG.

  Also in this example, the confirmation record registration unit 226 may create a confirmation record block indicating the record of the present confirmation, and register the block in the block chain 3 (steps S217 and S218). The confirmation record registration unit 226 adds the signature 35D of the confirmation organization to, for example, the hash value of the acquired personal ID 13D (individual ID_Hash 31D) and the confirmation information 34D indicating the information of the confirmation recording block used and the object confirmation result. And a confirmation recording block may be generated.

  Thus, for example, when the second target confirmation is performed, the block chain 3 is attached with the signature 35D of the confirmation organization that has performed the target confirmation, personal ID_Hash 31D which is a hash value of the user personal ID 13D, A confirmation recording block including the signature 35D of the confirmation organization is added to the information on the confirmation recording block used and the confirmation information 34D indicating the target confirmation result.

  In addition, after the third time, for example, after confirming the reliability of the registration information of the confirmation recording block indicating the recording of the second object confirmation, the object confirmation result etc. obtained from the information shown in the confirmation information 34D is used. can do. For example, when the information of the incorporated confirmation recording block (for the third time, the confirmation recording block indicating the recording of the first target confirmation) is acquired, the incorporated confirmation recording block is further acquired, and It is also possible to verify the reliability of the registered information and verify the confirmed information, and to inquire whether or not to use it.

  FIG. 19 is a flowchart summarizing the operation of the verification engine side system 20 in the verification 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 side system 10) (step S301).

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

  If the confirmation recording block indicating the confirmation recording for the same purpose is present (Yes in step S303), the registration information of the confirmation recording block is acquired, and then the process proceeds to step S310.

  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 from the block chain 3 a record in which an identity check is performed on the registered block in which the personal information Hash32D-1 is registered or the original data of the registered personal information Hash32D-1 A block is searched (step S304).

  When such a registration block or confirmation recording block is confirmed, registration information of the block is acquired, and then the process proceeds to step S305.

  In step S305, the block chain 3 is obtained based on the presence or absence of the signature 35D of the confirmation organization attached to the personal information Hash 32D-1 in the acquired registration information, the confirmation result of the confirmation information 34D included in the acquired registration information, and the like. With regard to the personal information Hash32D-1 registered in, it is checked whether the legitimacy of the original data (first personal information) has been confirmed in the past.

  If the legitimacy of the original data (first personal information) has not been confirmed (No in step S305), the data acquisition unit 221 can confirm the validity of the first personal information (a second personal information (legitimate) Further, the user is requested to disclose the confirmation information (step S306).

  Then, the personal information legitimacy confirmation unit 224 confirms the legitimacy of the first personal information acquired from the user based on the acquired second personal information (step S307). When the confirmation of the legitimacy of the first personal information is completed, the process proceeds to step S311.

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

  In step S308, the original data matching unit 223 checks the first personal information as the original data of the personal information Hash 32D-1 whose validity of the original data in the block chain 3 has already been confirmed (personal information at the time of registration ) And the consistency of the first personal information acquired from the user. The original data matching unit 223 calculates a hash value from the first personal information acquired from the user, and matches it with the personal information Hash32D-1 whose legitimacy of the original data in the block chain 3 has already been confirmed. You just need to confirm.

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

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

  In step S310, the registration information (the confirmation recording block in step S303, the registration information in the registration block or confirmation recording block in step S304, and the like) which is the acquisition destination of the information used for the determination so far. And the credibility check using the signature attached to it. When acquiring the partial information of the registration information, the registration information reliability confirmation unit 222 checks the reliability of at least the information and the personal ID_Hash 31D associated with the information.

  Moreover, in this example, after determining the presence or absence of the legitimacy confirmation of the personal information first, the example of performing the legitimacy confirmation of the personal information or the consistency check with the original data and the reliability check of the registered information However, the order of these confirmations does not matter. For example, each time information (confirmation information 34D, personal information Hash32D-1, etc.) is acquired from block registration information, a signature attached to the information and the personal ID_Hash31D associated therewith in the block is It may be used to verify the reliability.

  Further, in step S311, the determination result up to now, the determination result of the legitimacy of the disclosed information based on it, and the final result of object confirmation are output. In addition, when the confirmation recording block for the same purpose is discovered, you may inquire the use presence or absence of the confirmation result. Moreover, after outputting the confirmation result of the past and the determination result of the legitimacy of the disclosed information, the target confirmation result may be received from the confirmation organization side user.

  In addition, when a plurality of pieces of personal information are required for object confirmation, the confirmation unit 202 does not complete the object confirmation, such as unacquired information or information about unconfirmed legitimacy (No in step S312). The process 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 object confirmation has been completed by receiving from the confirmation organization side user.

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

  As described above, according to the present embodiment, only one individual ID is disclosed by the fact that the confirmation record of the validity of the original data and the confirmation record for various purposes are registered in the block chain 3. Will be able to carry out identity verification in place of licenses and passports. For this reason, the user does not need to perform the procedure of the identity verification for each purpose or application.

  For example, simply disclosing the personal ID can not confirm the identity of the owner of the personal ID and the presence or absence of the right to receive the requested service (eligibility). However, according to the present embodiment, for example, in the first disclosure of the personal ID, it is confirmed whether the user is eligible for the service and, if necessary, who the owner of the personal ID is (identity confirmation) Then, based on the personal information associated with the personal ID, the block chain 3 is recorded together with the hash value indicating the correctness of the information used for the confirmation and the result thereof along with the signature of the confirmer. Then, in a scene where the same service is used for the second time or later, the service provider confirms the past confirmation result and verifies the content thereof to give the same confirmation result.

  For example, a certain user was made to confirm the legitimacy (that it is the correct information of the user himself / herself indicated by the personal ID) with respect to the information of birth date which is age information and whether or not an adult is a certain user Above, it is assumed that the hash value is associated with the hash value of the personal ID and registered in the block chain.

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

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

  Next, in the case where alcohol is purchased at another store B, in the case where it is the second time for age confirmation of the same type, the user is requested to disclose age information by the store B after the personal ID is disclosed. Can disclose the information of the confirmation recording block in which the result of the first age confirmation is recorded instead of the disclosure of the age information. In store B, based on the disclosed information, by acquiring the result of the first age confirmation from the block chain, this personal ID has already been subjected to age confirmation of the same type in store A and has received service provision You can check In addition, the store B can also request information disclosure of the personal identification also in the second confirmation, not the disclosure of the confirmation record. Although these are determined by the service provider's policy, it is conceivable in many cases that the second disclosure may be the disclosure of the confirmation record if similar services are provided.

  In this way, 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 a hash value when using the service. By disclosing only one individual ID, it is possible to receive the same benefit as disclosing the personal information associated with the individual ID or the confirmation record using it. Therefore, by sharing the service of the present system among a plurality of vendors and services, it is possible to prevent the increase of information for identifying an individual for each service and each vendor.

  Further, according to the present embodiment, if the legitimacy of the original personal information is confirmed once and the record is registered in the block chain, the information necessary for age confirmation also in the first time It is possible to prevent the disclosure of unnecessary personal information (license number, name, address, etc.) that is not related to age confirmation in order to confirm the legitimacy of the day etc.). As described above, according to the present embodiment, it is possible to selectively disclose personal information associated with an individual ID, and therefore, control can be performed such that only information minimally required for confirmation is disclosed.

  In the present embodiment, since the hash value of the personal ID is registered in each block, the personal ID issued at the start of use is, due to the characteristics of the block chain where stopping of service due to server down is not expected, It can be used permanently unless it is invalidated by the user or administrator.

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

  As a first method, when assigning a personal ID at the start of use of the present system, there is a method of registering a plurality of authentication members for a pair of the personal ID and a device ID as its authentication information. When the user loses the device, 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 the approval of a fixed number of authentication members. The method may be implemented using a block chain identity management platform called uPort.

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

  Using such an Ehtereum block chain network, for example, when a user loses a uPort device, it first connects to Ethereum with a new device and acquires a new User Address. Then, the new User Address is notified to the pre-registered authentication member (real delegate member, etc.).

  The authentication member authenticates a new User Address by calling a Recovery contract, performing user confirmation, and the like. If a certain number or more of approvals are obtained as a result of authentication, a new UserAdress is notified to the Controller contract and is rewritten with the old UserAdress.

  As a result, only the EOA corresponding to the actual device ID can be changed without changing the UPort ID functioning as the identification information of the client device in the Proxy contract. As described above, by separating the device ID from the corresponding EOA and the data on the block chain from the corresponding Proxy address, connectivity with existing data can be maintained even when the client device is exchanged due to device loss or the like. Here, uPortID corresponds to the above-mentioned personal ID.

  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 capable of personal identification and user authentication can be registered in association with the hash value of the personal ID. There is a method to add to the block chain. In this method, when such personal information and a personal ID at the time of registration are registered in a new device, user authentication using registration information equivalent to the personal information for the new device To make the personal ID in the new device reusable.

  For example, if the phone number is SMS authentication, if it is an e-mail address, e-mail transmission to the e-mail address; if it is biometric information, the user authentication on the new device passes by comparison with the current user's biometric information. For example, the personal ID may be reusable on a new device.

Embodiment 3
Next, some specific examples of utilization of the second personal information management system described above will be described. In this embodiment, a ticket service system will be described as an example in which the above-described service providing system and personal information management system are used to prevent the resale of tickets. FIG. 20 is a schematic configuration diagram of a 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 block chain network (hereinafter referred to as a block chain NW) 30A.

  Here, the personal terminal 10A corresponds to the user side system 10 described above. The personal terminal 10A as the user-side system 10 of this example may further include the function of the personal terminal 61 (SNNAPP unit 611, IMSAPP unit 612, etc.). Further, the service providing device 21A and the entrance device 22A correspond to the above-described verification engine side system 20. Note that the service providing device 21A and the entrance device 22A as the confirmation organization side system 20 of this example further include the functions of the service server 64 described above (for example, the SNS side service providing unit 641 and the object confirmation service unit 642). It is also good. More specifically, the service providing device 21A corresponds to the confirmation organization side system 20 of an agency (ticket sales company or the like) who has issued ticket information. The entrance device 22A corresponds to the confirmation organization side system 20 of an organization (such as a company operating a concert) that checks entry and exit of the ticket purchaser to the place (event venue etc.) based on the ticket information. The entrance device 22A is installed, for example, at a place where the 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 organization side system 20 of the same organization.

  The block chain NW 30A corresponds to part of the IMS platform 63 described above or the ledger management system 30 described above. Although not shown, the block chain NW 30A implements the function (assignment of personal ID, generation of pair key, etc.) of the management side system 50 in addition to mounting the block chain 3 usable in this system. . In this example, an identifier (the above uPort ID or the like) for identifying the creator of the block in the block chain 3 doubles as the personal ID 13D. In this case, the personal terminal 10A may have the function of the management side system 50.

  In this example, a ticket purchase application for performing a procedure for the user to receive a ticket purchase service using the present system is downloaded to the personal terminal 10A as the user side application in the present example. The ticket purchase application operates on the CPU of the personal terminal 10A to cause the personal terminal 10A to execute predetermined processing of the user side system 10 in the present system. In the present example, it is assumed that assignment of a personal ID and generation of a key pair are performed at the time of download of a ticket purchase application.

  Further, it is assumed that a ticket information management application is implemented in advance in the service providing apparatus 21A as a first service providing side application in this example. Here, the ticket information management application sells to the user while performing examination and payment confirmation of ticket purchase qualification including identity verification using information in the block chain 3 in response to a purchase application from the user. It is an application that performs the procedure for The application operates, for example, on the CPU of the service providing device 21A, and causes the service providing device 21A to execute predetermined processing of the verification authority side system 20 in the present system.

  Further, it is assumed that a ticket information confirmation application is implemented in advance in the entrance device 22A as a second service providing side application in this example. Here, the ticket information confirmation application manages the entry / exit of the user while performing the examination of entry / exit qualification including the identity verification using the information in the block chain 3 according to the entry / exit application from the user It is an application that performs the procedure for The application operates, for example, on the CPU of the entrance device 22A to cause the entrance device 22A to execute predetermined processing of the verification engine side system 20 in the present system.

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

  In step S401A, in response to an instruction from the user, the personal terminal 10A acquires biometric information (for example, a photograph of a face, etc.) for identity verification performed at the time of ticket purchase and at least entrance to the hall. Read out personal information (for example, address, name, credit card number, etc.) required at the time of ticket purchase. And personal terminal 10A calculates a hash value about personal ID13D assigned to the user concerned while computing a hash value about a predetermined unit of disclosure which is each of those, or those combination. In addition, it is also possible to use not personal ID_Hash31D but personal ID13D as information for specifying an individual in each block as it is. In that case, the personal ID_hash 31D may be read as the personal ID in the subsequent processing, and the process of confirming the reliability of 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 address and name is used as user information at the time of ticket purchase in the ticket purchase service provided by the service providing device 21A, and that a credit card number is used as payment information in the same service. There is. In addition, as already demonstrated, it is assumed that biometrics information is used as identity verification information performed at the time of ticket purchase and at least entrance to a meeting place.

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

  The personal terminal 10A calculates hash values (personal information Hash 32D (1), (2), (3)) for the personal information 14D (1), (2), (3) and the personal ID 13D respectively, The block chain NW 30A is requested to add an additional registration block having the attached personal signature 33D as registration information, and the block chain 3 is registered.

  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) that identifies a block of information related to the personal ID 13D in the block chain 3. In step S401A, TxID = 1 is received, which indicates that this is a first registration block in the personal ID 13D.

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

  Thus, 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 person is registered in the block chain 3, the personal registration is completed.

  When the personal registration is completed, the user then applies for 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 the information of the ticket to be purchased to the service providing apparatus 21A.

  The service providing apparatus 21A that has received the ticket purchase application uses the registration information in the user's block chain 3 based on the personal ID 13D included in the application and the personal information directly disclosed by the applicant, and makes a purchase The qualification is confirmed (step S403A). As the purchase qualification at the personal information management system level of this example, an individual who is personal information necessary for ticket purchase and whose hash values are registered in the block chain 3 together with biometric information used for identification Information (the personal information 14D (1) (2) described above) is disclosed. However, partial personal information (in this example, personal information 14D (1) in this example) can be replaced by the disclosure of the past purchase records registered in the block chain 3. The ticket service system level purchase qualification additionally includes that the settlement is normally performed by the disclosed information.

  Further, for example, if it is desired to carry out identity verification not only at the time of admission but also at the time of purchase, the above-mentioned purchase qualification, personal information disclosed to the applicant or an individual disclosed at the time of past purchase It is also possible to add that identity verification as the owner of the information can be taken. Note that these are merely examples and may be freely determined by the service provider.

  The service providing apparatus 21A of the present example, as the confirmation process of the purchase qualification of the present example, sends the request source user (applicant) at least once of the personal information 14D (1) including the past purchase record. At least the disclosure and the disclosure of the personal information 14D (2) of the degree of purchase are requested, and the legitimacy of the disclosed information is confirmed (step S403A). The service providing device 21A may check the validity of the disclosed information by checking the registered information (including the confirmation record) in the block chain 3 with the registered information. The comparison with the registered information also includes the above-described verification of the consistency of the original data and the verification of the reliability of the registered information itself.

  Note that the service providing device 21A can also perform identity verification on the applicant (more specifically, the discloser who disclosed the above two pieces of personal information) in the purchase qualification confirmation process. In that case, the service providing apparatus 21A causes the personal terminal 10A to further disclose the applicant's current biometric information, and compares the hash value with the personal information Hash32D (3) registered in the registration block. You may check your identity. Depending on the biometric information, the registered information and the current information may not completely match, and it may be considered that comparison and verification using hash values are difficult. In such a case, the original data of the personal information Hash32D (3), which is the hash value of the registered biometric information (the biometric information at the time of registration) is disclosed, and comparison with the applicant's current biometric information is performed. It is good. In addition, it is also possible to perform the above-mentioned personal identification on the side of the personal terminal 10A (more specifically, a ticket purchase application including a part of functions of the confirmation unit 202 of the confirmation organization side system).

  When the applicant's eligibility for purchase is confirmed in this manner, the service providing device 21A issues a ticket to the applicant. When the service providing device 21A confirms the purchase qualification and issues a ticket, the ticket issuance information (for example, the ticket issuance information, the issued ticket information, the confirmation record of the purchase qualification at the time of ticket issuance) is confirmed as confirmation information 34D. The confirmation recording block including the information shown) is registered in the block chain 3 (step S404A). The confirmation record block includes the hash value of the disclosed personal ID 13D (personal ID_Hash 31D), and the personal ID_Hash 31D and the confirmation information 34D are attached with the signature 35D of the confirmation agency that is the ticket information issuer. Ru. The issued ticket information itself may be held by the service providing apparatus 21A, and an identifier (service ID) for identifying the ticket information may be registered in the confirmation recording block.

  When the registration of the confirmation recording block is completed, the service providing device 21A returns the service ID and the TxID of the confirmation recording block in which it is recorded as the issued ticket information to the personal terminal 10A of the request source.

  Next, consider the case where the user enters the hall using the ticket issued in this way. In this example, the user may apply for admission to the admission device 22A (step S405A). In step S405A, the personal terminal 10A enters, for example, an entrance application including the personal ID 13D and ticket information (a service ID, a TxID of a confirmation recording block in which it is recorded, etc.) received from the service providing device 21A. Send to 22A.

  The admission device 22A that has accepted the admission application uses the registration information in the block chain 3 of the user to confirm the admission qualification based on the information contained therein (step S406A). For admission qualification at the personal information management system level in this example, a confirmation recording block including ticket issuance information is registered in block chain 3 for the user, and disclosed or referred to the applicant at the time of purchase. It is said that identity verification as the owner of personal information can be taken. Note that these are merely examples and may be freely determined by the service provider.

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

  When the admission qualification of the applicant is confirmed in this manner, the entrance device 22A performs entrance processing such as opening a gate (not shown) or outputting information indicating admission permission. The entrance device 22A may register a confirmation recording block including entrance information indicating that the entrance processing has been performed in the block chain 3 as the confirmation information 34D when the entrance qualification is confirmed and the entrance processing is performed (step S407A). ). The confirmation record block includes the hash value of the disclosed personal ID 13D (personal ID_Hash 31D), and the personal ID_Hash 31D and the confirmation information 34D are attached with the signature 35D of the confirmation agency that is the ticket information issuer. Ru.

  In addition, also at the time of re-entry, you may perform an entrance process on an identity confirmation by the method similar to an entrance application. It is also possible to register an exit record in the block chain 3 when leaving on the way, and to further collate the information with that information.

  22 to 25 are sequence diagrams showing an example of the flow of processing at the time of the above-mentioned person registration, at the time of purchase application, and at the time of admission application.

  FIG. 22 is a sequence diagram showing an example of the flow of processing at the time of person registration. It is assumed that assignment of the personal ID 13D and issuance of a pair key are performed prior to the personal registration.

  In the example shown in FIG. 22, the user first instructs the personal terminal 10A to register personal information (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 transmits the personal information Hash32D (1) (2) (2) ( 3) is obtained (step S502).

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

  The block chain NW 30A adds a block (registration block) including the information included in the block addition request as registration information to the block chain 3 (step S504).

  When the personal terminal 10A receives the block addition response from the block chain NW 30A (step S505), the personal terminal 10A holds the TxID (in this example, TxID = 1) of the added block in the registration history and prepares for the subsequent disclosure request. Personal information at the time of registration, that is, 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, the user is notified of the completion (step S507).

  Moreover, FIGS. 23-24 is a sequence diagram which shows an example of the flow of the process at the time of purchase application. FIG. 24 is a continuation of FIG. In the example shown in FIGS. 23-24, the user first instructs the personal terminal 10A to apply for a purchase (step S511). At this time, information of a ticket to be purchased may be designated.

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

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

  The personal terminal 10A that has received the personal information disclosure request A, for example, searches the registration history to disclose the personal information 14D (1) in the ticket service system in the past, and the equivalent target confirmation accompanying this In the example, it may be confirmed whether or not there is purchase qualification confirmation.

  If there is neither disclosure of personal information 14D (1) nor the same object confirmation in the past, personal terminal 10A will disclose personal information 14D (1) with the permission of the user. In this example, personal information terminal 10A includes personal information 14D (1), and personal information disclosure including TxID of a registration block including information indicating the legitimacy (personal information Hash 32 D (1) and signature 33 D of the person in question). The response A is transmitted to the service providing device 21A (step S514).

  The service providing device 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 check 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). Consistency confirmation is performed to confirm the legitimacy of the disclosed personal information 14D (1) (step S516). At this time, the service providing device 21A registers the record of the purchase qualification confirmation A indicating that the personal information 14D (1) is disclosed and the correctness is confirmed in the block chain 3 as a confirmation recording block. May be As a result, the TxID of the confirmation recording block (in this example, TxID = 2) is received (steps S517 and S518).

  On the other hand, if there has been disclosure of personal information 14D (1) or an equivalent object confirmation (purchase qualification confirmation in this example) in the past, personal terminal 10A is replaced with personal information 14D (1), and the confirmation at that time The personal information disclosure response A including the TxID (for example, the above TxID = 2 or TxID = 4 described later, etc.) of the recording block 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 legitimacy confirmation result about the personal information 14D (1) and the equivalent service qualification (ticket purchase qualification) Is obtained (step S520). Then, the service providing apparatus 21A confirms the reliability of the registration information of the confirmation recording block, and verifies the confirmation result indicated by the registration information (judgment determination) (step S521).

  In this example, if the confirmation record block registered by the own organization is subjected to the credibility confirmation (creator proof and non-falsification proof) of the registered information, the disclosure of the personal information 14D (1) can be omitted. Do. Also in the confirmation of step S521, the service providing device 21A confirms the recording of purchase qualification confirmation A indicating that the validity of the personal information 14D (1) is confirmed by the confirmation result of the designated confirmation recording block, the confirmation recording block And may be registered in the block chain 3. As a result, the TxID of the confirmation recording block is received (steps S522 and S523).

  When the disclosure and / or the verification of the validity of the personal information 14D (1) are completed, the service providing device 21A discloses the personal information specifying the personal information 14D (2) as the payment information to the request-use personal terminal 10A. The request B is sent (step S524). In this example, disclosure of personal information 14D (2) as payment information in the confirmation record is not recognized.

  The personal terminal 10A having received the personal information disclosure request B discloses personal information 14D (2) with the permission of the user. Also in this example, the personal information terminal 10A discloses personal information disclosure including personal information 14D (2) and a TxID of a registration block including information indicating the legitimacy (personal information Hash 32 D (2) and the signature 33 D of the user). The response B is transmitted to the service providing device 21A (step S525).

  The service providing device 21A that has received the personal information disclosure response A performs the same legitimacy check as in the case of receiving the personal information 14D (1), and adds the record to the block chain 3 (steps S526 to S529).

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

  In the ticket issue information, information related to the issue of the ticket this time in the service providing apparatus 21A (the information of the user of the issue destination and the TxID of the block necessary for admission etc. (issue record TxID, blocks registered in the issue process, It is assumed that the service ID associated with TxID of the block referred to and personal information etc. is included. Further, the service providing device 21A holds information related to the issue of the ticket this time in association with such a service ID (step S533).

  When the above process is completed, the service providing apparatus 21A accepts the purchase permission for the purchase application, the service ID for identifying the information related to the issue of the current ticket, and the TxID in which the issue record of the current ticket is registered. (The issue record TxID in the figure) is sent back to the personal terminal 10A of the request source (step S534).

  The personal terminal 10A receiving the purchase permission stores the service ID and the issue record TxID received together with the purchase permission as ticketing ticket information (step S535). Thereafter, the user is notified of the completion (step S536).

  FIG. 25 is a sequence diagram showing an example of the flow of processing at the time of admission application. In the example shown in FIG. 25, the user first instructs the personal terminal 10A to apply for admission (step S541). At this time, a service ID may be designated as ticketing ticket information for applying for admission.

  When the instruction for admission application is received, the personal terminal 10A transmits an admission application including the personal ID 13D and the service ID to the admission device 22A (step S542). This may be performed by information communication by touch on the reader device provided in the entrance device 22A actually installed in the hall.

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

  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 device 21A may check the received service ID as to whether or not the information related to the issuance of a ticket for the event in which the entrance device 22A is installed is registered.

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

  If the service ID validity result is “NG”, the entrance device 22A that has received the service ID validity result returns an admission disapproval to the personal terminal 10A (step S548). At this time, the entrance device 22A may also transmit that the service ID is incorrect. The personal terminal 10A that has received the non-entry notice notifies the user of the non-entry 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). Although the example shown below is an example in which personal identification is performed on the personal terminal 10A side using biometrics authentication in the block chain 3, the same process may be performed by the entrance device 22A or the like.

  The personal terminal 10A having received the biometric authentication request D searches the registration history held by itself and acquires the TxID of the registered block registered at the time of the principal registration (step S551), and the registration information (in particular, Personal information Hash32D (3), which is a hash value of biometric information, is acquired.

  Then, the personal terminal 10A confirms the reliability of the acquired registration information (step S552) and confirms the matching between the personal information held at the time of registration and the original data of the registration information (step S553). It is confirmed that the personal information 14D (3) held by itself is biometric information when registered in the block chain 3. This confirmation is performed by specifying the block ID of the registered block as the reference TxID in the block chain NW30A, and transmitting a registration information reference request specifying the hash value calculated from the biometric information at the time of registration as the confirmation target as the comparison source. It is also possible to do it.

  Thus, when the legitimacy (identification authentication of the personal information) of the personal information 14D (3) held by itself is confirmed, the personal terminal 10A further displays the biometric information of the current user (at the time of admission application). It acquires and confirms the identity of both (step S554). The personal terminal 10A may collate both 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 result of biometric authentication (step S555).

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

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

  As described above, according to the present embodiment, it is possible to realize a ticket service including personal identification without any leak and surely and quickly. In addition, it does not have to be on the site of personnel for identification, which leads to cost reduction.

  In the present embodiment, personal information is subjected to object confirmation including personal identification using information in the block chain 3 associated with one personal ID in a series of ticket services from ticket sales to entrance determination. Although an example in which the management system is applied is shown, when it is desired to provide a service using an SNS platform, by using an ID passing method as described in the service providing system of the first embodiment when providing a service. , ID can be coordinated between SNS and IMS.

  FIG. 26 is a block diagram showing another configuration example of the ticket service system of this 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 block chain NW 30B.

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

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

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

  The SNS application unit 711B is a process performed by the SNSAPP unit 611 of the first embodiment and a process related to service provision performed by the personal terminal 10A of the third embodiment (target equivalent to a process performed by the confirmation unit 202) Perform processing other than processing related to confirmation and record registration). Specifically, the SNS application unit 711B is a user of the personal terminal 10B and provides various processes and an interface for the user of the present system to use a predetermined SNS.

  The IMS application unit 712B performs the processing corresponding to the processing performed by the IMSAPP unit 612 of the first embodiment and the processing for object confirmation and record registration performed by the personal terminal 10A of the third embodiment. Specifically, the IMS application unit 712B is a user of the personal terminal 10B and provides various processes and interfaces for the user of this system to use a predetermined IMS.

  The SNS-side service providing unit 721B performs processing other than target confirmation among the processing related to service provision performed by the service providing device 21A of the third embodiment. 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 object confirmation service unit 722B performs object confirmation processing among the processing related to service provision performed by the service providing apparatus 21A of the third embodiment. Specifically, the first target confirmation service unit 722B performs target confirmation of the user by exchanging information with the IMS application unit 712B using the platform of IMS.

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

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

  In such a configuration, the IMS application unit 712B acquires the SNS-side service providing unit 721B acquired by using at least the function provided by the SNS platform in at least the first target confirmation service unit 722B according to a predetermined method. You may transmit SNS_ID which is information which can specify a user on the platform of SNS with the information which can specify the result of object confirmation of a user.

  Also, the first target confirmation service unit 722B associates the SNS_IDB received from the IMS application unit 712B with the result of target confirmation of the user specified by the SNS_ID, and notifies the SNS side service providing unit 721B. It 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 object confirmation notified from the first object confirmation service unit 722B.

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

  The node 301B corresponds to the ledger management node 301, and a block chain (more specifically, 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. Configure.

  In the block chain, the registration unit 102B is personal information disclosed by the user, and is object confirmation information that is personal information necessary for predetermined object confirmation that is either identity verification, user authentication, or eligibility confirmation. Register the first block containing the hash value.

  When the disclosure unit 103B receives the disclosure request for personal information, the disclosure unit 103B reads the requested type of personal information from a predetermined storage unit (not shown) and transmits the read personal information to the request source. Alternatively, instead of the requested type of personal information, information that can specify a second block including a record of past object confirmation performed using the personal information may be transmitted.

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

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

  In this example, the IMS application unit 712B includes the registration unit 102B as part of the IMS, and the first target confirmation service unit 722B and the second target confirmation service unit 731B are targets as part of the IMS. It is assumed that the confirmation unit 2021B and the recording registration unit 2022B are included.

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

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

  In addition, when the second object confirmation service unit 731B receives an entry application from the user, the second object confirmation service unit 731B via the object confirmation unit 2021B allows the user to specify information that can specify the second block, and the first block registration time. Disclosure of the first target confirmation information and the first target confirmation information may be requested, and predetermined eligibility confirmation including identity confirmation may be performed based on the disclosed information.

  When the first object confirmation service unit 722B and the second object confirmation service unit 731B provide object confirmation or some service, the object registration service or the service is provided to the block chain via the record registration unit 2022B. A second block containing a record may be registered.

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

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

  For example, a facility management service for locking / unlocking facilities and rooms using smart keys, facility management services for smart key issuance and entry / exit management, wearable devices and portable terminals registered with biometric information, etc. A voting service, a commuter pass fare management service with a ticket gate using a wearable device or a portable terminal with biometric information registered, etc. may be considered.

As an application method of the personal information management system to the above-mentioned facility management service, for example, the following can be mentioned.
-At the start of use, register the hash value of the biometric information for identity verification together with the personal information required for this service in the block chain (identity registration) with the personal ID.
・ When making a reservation, issue an electronic key upon identification and register the record in the block chain.
• At check-in, validate the electronic key issued upon identification and register the record in the block chain.
・ When electronically unlocking / locking, register the record in the block chain via a locking device etc.
-At checkout, the issued electronic key will be invalidated and clearing will be performed based on the record on the block chain.

As an application method of the personal information management system to the above-mentioned voting service, for example, the following can be mentioned.
-At the start of use, register the hash value of the biometric information for identity verification together with the personal information required for this service in the block chain (identity registration) with the personal ID.
・ When applying for electronic voting right, after confirming the information necessary for identity verification and electronic voting right issuance, issue the electronic voting right and register the issue record in the block chain.
-At the time of voting, the voting device that receives the vote accepts the vote after confirming the identity verification and the issue record. Also, a voting record including voting contents (encryption) is registered in the block chain.
-At the time of sheet counting, the sheet counting device counts the sheet based on the voting record on the block chain.

As an application method of the personal information management system to the above-mentioned commuter pass fare management service, for example, the following can be mentioned.
-At the start of use, biometric information is registered in the wearable device or portable terminal possessed by the user.
-When applying for a commuter pass, register the issue record including the device ID in which the biometric information is registered and the commuter pass issue information in the block chain. At this time, the device ID may be regarded as a personal ID or may be separately assigned.
・ When passing a ticket (boarding), check the issue record on the block chain and the record immediately before based on the device ID acquired from the biometric device or mobile terminal with biometric authentication or the personal ID notified when issuing the commuter pass. , Determine the admission. Also, register the entry record in the block chain.
・ At the time of ticket passing (disembarking), check the issue record on the block chain and the record immediately before based on the device ID acquired from the biometric device or mobile terminal with biometric authentication or the personal ID notified at the time of issuing the commuter pass. , Determine whether to participate. In addition, the participation record is registered in the block chain.

  In the example shown above, the entrance apparatus receives an application for entrance from the user, and determines the availability of the user's application based on the result of the target confirmation. It is also possible to replace it with a permit determination device installed at a place where a permit issued by the service providing device and indicating the qualification for the service is used. In such a case, as shown in FIG. 26, in the permit determination device, the second object confirmation service unit receives an application for admission from the user or an application for receipt of a profit obtained by the permit, and the determination unit The availability of the user's application may be determined based on the result of the object confirmation by the second object 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 showing a configuration example of a computer according to each embodiment of the present invention. The computer 1000 includes a CPU 1001, a main storage unit 1002, an auxiliary storage unit 1003, an interface 1004, a display unit 1005, and an input device 1006.

  The server and other devices included in the system of each of the above-described 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 a program from the auxiliary storage device 1003 and develops the program in the main storage device 1002, and performs predetermined processing in each embodiment according to the program. The CPU 1001 is an example of an information processing apparatus that operates according to a program, and in addition to a central processing unit (CPU), for example, a micro processing unit (MPU), a memory control unit (MCU), or a graphics processing unit (GPU) May be provided.

  The auxiliary storage device 1003 is an example of a non-temporary tangible medium. Other examples of non-transitory tangible media include magnetic disks connected via an interface 1004, magneto-optical disks, CD-ROMs, DVD-ROMs, semiconductor memories, and the like. Further, when this program is distributed to the computer 1000 by a communication line, the distributed computer may expand the program in the main storage device 1002 and execute predetermined processing in each embodiment.

  Also, the program may be for realizing a part of predetermined processing in each embodiment. Furthermore, the program may be a difference program that implements predetermined processing in each embodiment in combination with other programs already stored in the auxiliary storage device 1003.

  The interface 1004 exchanges information with other devices. In addition, the display device 1005 presents information to the user. Also, the input device 1006 receives input of information from the user.

  Moreover, depending on the processing content in the embodiment, some elements of the computer 1000 can be omitted. 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 receive information input from the user, the input device 1006 can be omitted.

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

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

  Next, an outline of the present invention will be described. FIG. 28 is a block diagram showing an overview of a service providing system of the present invention. As shown in FIG. 28, the service providing system of the present invention comprises 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 SNS APP unit 611) provides various processes and an interface for the user to use a predetermined SNS.

  The IMS application unit 712 (for example, the IMS APP unit 612) provides various processes and interfaces for the 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) performs target confirmation of the user by exchanging information with the IMS application unit 712 using the platform of IMS.

  In such a configuration, the IMS application unit 712 acquires to the target confirmation service unit 722 at least using the function provided by the SNS platform by a predetermined method, the SNS-side service providing unit 721 is the SNS platform SNS_ID which is information which can specify a user above is transmitted with the information which can specify the result of object confirmation of a user. Then, the target confirmation service unit 722 associates the SNS_ID received from the IMS application unit 712 with the result of target confirmation of the user specified by the SNS_ID, and notifies the SNS-side service providing unit 721.

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

  As mentioned above, although this invention was demonstrated with reference to this embodiment and an Example, this invention is not limited to the said embodiment and an Example. The configurations and details of the present invention can be modified in various ways that can be understood by those skilled in the art within the scope of the present invention.

  According to the present invention, the present invention can be suitably applied as long as the service is provided to the user after any one of identity verification, user authentication and qualification is performed.

600 service providing system 61 personal terminal 611 SNSAPP section 612 IMS APP section 62 SNS platform 63 IMS platform 64 service server 641 SNS side service providing section 642 target confirmation service section 643 ID linkage information storage section 1 client device 2 confirmation agency 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 Person's signature 34D Confirmation information 35D Verification agency's signature 100 Personal information management system 10 User side system 101 Data storage unit 102 Registration unit 103 Disclosure unit 104 Authentication unit 20 Verification agency side system 201 Data storage unit 202 Confirmation unit 221 Data acquisition Part 222 Registered 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 acceptance part 312 Block generation part 313 Block Shared unit 314 Information storage unit 315 Block verification unit 40 Network 50 Management side system 501 Data storage unit 502 Personal ID allocation unit 10A, 10B Personal terminal 21A, 21B Service providing device 22A, 22B Entrance device 30A , 30 B block chain 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 determination unit 102B registration unit 103B disclosure unit 2021B target confirmation unit 2022B record registration unit 301B node 1000 Computer 1001 CPU
1002 main storage unit 1003 auxiliary storage unit 1004 interface 1005 display unit 1006 input device 71 personal terminal 711 SNS application unit 712 IMS application unit 72 service server 721 SNS service providing unit 722 target confirmation service unit

Claims (8)

A service server for providing a predetermined service; and a personal terminal used by a user to whom the service is provided;
The personal terminal is
An SNS application unit that provides various processes and an interface 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 is
An SNS-side service providing unit that provides the service to the user by exchanging information with the SNS application unit using the SNS platform;
A target confirmation service unit for performing target confirmation of the user by exchanging information with the IMS application unit using the IMS platform;
The IMS application unit acquires the target confirmation service unit using at least a function provided by the SNS platform in a predetermined method, and the SNS side service providing unit uses the SNS platform on the SNS platform Sending SNS_ID, which is information that can identify the person, together with information that can identify the result of the user's target confirmation,
The target confirmation service unit associates the SNS_ID received from the IMS application unit with the result of target confirmation of the user specified by the SNS_ID, and notifies the SNS-side service providing unit of the correspondence .
The IMS is
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 object confirmation information which is personal information disclosed by the user and which is personal information necessary for predetermined object confirmation which is any of identity confirmation, user authentication or qualification confirmation. A registration unit that registers the first block;
And a target confirmation unit that performs target confirmation based on the disclosed target confirmation information after verifying the legitimacy of the target confirmation information disclosed by the user using a block in the block chain. Yes,
The IMS application unit includes the registration unit as part of the IMS.
The target confirmation service unit includes the target confirmation unit as part of the IMS.
The IMS is
The block chain further includes a record registration unit that registers a second block including a 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 from the user is disclosed instead of the target confirmation information. Performing the object confirmation with reference to the record of the object confirmation in the second block identified from the stored information;
The service providing system, wherein the target confirmation service unit further includes the record registration unit as a part of the IMS . The IMS application unit uses the transmission / reception function of the SNS platform to transmit the activation parameter from the link of the Web page received from the SNS service providing unit when the IMS application is activated. The service provision according to claim 1, wherein the SNS_ID of the user is acquired, or the SNS_ID of the user is acquired using a login service to the SNS from another application provided by the SNS platform. system. The IMS application unit uses a message transmission / reception function provided by the SNS platform from the activation parameter delivered when the IMS application unit is activated from the link of the Web page received from the SNS-side service providing unit, The service provision according to claim 2, wherein information including a session ID that can specify the user as the SNS_ID, and a transmission destination IMS_ID that is information that can specify the target confirmation service unit on the platform of the IMS is acquired. system. The IMS application unit transmits the SNS_ID of the user and the IMS_ID, which is information that can identify the user on the platform of the IMS held by itself, to the target confirmation service unit. The service providing system according to any one of claims 1 to 3. The IMS application unit correlates the SNS_ID of the user with the result of the target confirmation of the user performed using the platform of the IMS, and transmits the result to the target confirmation service unit. The service providing system according to any one of claims 3 to 10. A personal terminal used by a user, a service providing apparatus for providing a predetermined service to the user, and a permission to be installed at a place where a license issued by the service providing apparatus is used to indicate the eligibility for the service And a certificate determination device,
The personal terminal is
An SNS application unit that provides various processes and an interface 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
An SNS-side service providing unit that provides the service to the user by exchanging information with the SNS application unit using the SNS platform;
A first target confirmation service unit that performs target confirmation of the user by exchanging information with the IMS application unit using the IMS platform;
The permit judging device is
When receiving an application for admission from the user or an application for receiving the benefit obtained by the permit, 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 or not the user can apply based on the result of the object confirmation by the second object confirmation service unit,
The IMS application unit acquires at least the first object confirmation service unit using at least a function provided by the SNS platform by a predetermined method, the SNS-side service providing unit is the SNS platform Transmitting the SNS_ID, which is information that can identify the user, with the information that can identify the result of the object confirmation of the user,
The first target confirmation service unit associates the SNS_ID received from the IMS application unit with the result of target confirmation of the user specified by the SNS_ID, and notifies the SNS side service providing unit of the correspondence.
The SNS-side service providing unit provides the service to the user based on the result of the target confirmation of the user notified from the first target confirmation service unit.
The IMS is
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 object confirmation information which is personal information disclosed by the user and which is personal information necessary for predetermined object confirmation which is any of identity confirmation, user authentication or qualification confirmation. A registration unit that registers the first block;
A target confirmation unit that performs the target confirmation based on the disclosed target confirmation information after verifying the legitimacy of the target confirmation information disclosed by the user using a block in the block chain;
The block chain further includes a record registration unit that registers a second block including a record of the target confirmation or the provision of the service,
The IMS application unit includes the registration unit as part of the IMS.
The first object confirmation service unit and the second object confirmation service unit each have the object confirmation unit and the record registration unit as part of the IMS.
The IMS application unit transmits the identifier of the user, the hash value of first target confirmation information which is biometric information disclosed by the user, and the user to the block chain via the registration unit. Register a first block including a hash value of second target confirmation information which is predetermined personal information disclosed by
The first object confirmation service unit requests the user to disclose the second object confirmation information via the object confirmation unit, and performs the object confirmation based on the obtained information.
The second object confirmation service unit causes the user to specify the second block, the first object confirmation information at the time of the first block registration, and the current via the object confirmation unit. first requires disclosure of target confirmation information, based on the disclosed information, have rows predetermined qualification including identification of,
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 from the user is disclosed instead of the target confirmation information. The service providing system, wherein the object confirmation is performed with reference to the record of the object confirmation in the second block identified from the information . The service providing system according to any one of claims 1 to 6 , wherein the service is any 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 who is a service provision destination, and which provides various processes and an interface for the user to use a predetermined SNS, and the user has two or more An IMS application unit that provides various processes and interfaces for using a predetermined IMS including two or more nodes forming a block chain to which a new block is added through processing according to a predetermined consensus algorithm in which nodes participate And the IMS application unit included in the personal terminal is a service server for providing the service, and the user receives the service by exchanging information with the SNS application unit using the SNS platform. SNS side service offer And the target confirmation service unit of the service server provided with the target confirmation service unit for performing the target confirmation of the user by exchanging information with the IMS application unit using the platform of the IMS by a predetermined method The SNS_ID acquired by using at least a function provided by the SNS platform, the SNS side service providing unit being information that can identify the user on the SNS platform, the target confirmation of the user Send the results of the
The target confirmation service unit associates the SNS_ID received from the IMS application unit with the result of target confirmation of the user specified by the SNS_ID, and notifies the SNS-side service providing unit of the correspondence.
The SNS-side service providing unit provides the service based on the result of the target confirmation of the user notified from the target confirmation service unit ,
The IMS
The block chain includes a hash value of object confirmation information which is personal information disclosed by the user and which is personal information necessary for predetermined object confirmation which is any of identity confirmation, user authentication or qualification confirmation. Register the first block,
After verifying the legitimacy of the object confirmation information disclosed by the user using blocks in the block chain, the object confirmation is performed based on the disclosed object confirmation information;
The IMS
Registering a second block including a record of the object confirmation in the block chain;
As a result of requesting the user to disclose the target confirmation information, the information is identified from the disclosed information when the information capable of specifying the second block is disclosed by the user instead of the target confirmation information. A service providing method, wherein the target confirmation is performed with reference to the record of the target confirmation in the second block .

Images