Personal data linking system and personal data linking method

Abstract

Linking personal data across multiple relying parties. [Solution] The personal data linkage system 600 includes a general-personal authentication system 200 that registers an account of an ID provider 210, generates a base ID, and registers the base ID in association with the account; a general-personal authentication system linkage unit 302 that registers the linkage between the servicer 300 and the base ID in an ID conversion table; a permission management unit 205 that updates the data of the permission request to "approved" when permission for the permission request is obtained from the user's terminal; a personal data acquisition request unit 304 that causes the servicer 300 to make a data acquisition request to the servicer 400; a permission confirmation unit 413 that confirms the servicer 400's permission for the servicer 300 in the permission management table; and a personal data provision unit 414 that responds with the requested data for the data acquisition request when the servicer 400 has permission for the servicer 300.

Description

[Technical field]

[0001] The present invention relates to a personal data linking system and a personal data linking method. [Background technology]

[0002] Conventionally, in order to receive a specific service in a smartphone or personal computer application, an account corresponding to the specific service is required. For example, an ID (identification) and password for logging in to the account corresponding to the specific service are entered, and the corresponding specific service can be received when authentication is successful.

[0003] In recent years, authentication systems have been considering using the OpenID Connect protocol to provide multiple services by logging in using one ID. Here, linking multiple services using one ID is also called ID federation. As the number of services provided by ID federation increases, users will be able to use multiple services across the board.

[0004] Here, as an example of an authentication system, an authentication system that "achieves cooperation between authentication servers with a relatively simple configuration" is disclosed.

[0005] The abstract of Patent Document 1 discloses that "The authentication system 1 comprises service providing systems 10-40, a global ID platform 50, and a terminal device 70 owned by a user 71. The service providing system 10 includes an authentication server 11 and a backend server 12. The backend server 12 provides a first service. The service providing system 20 includes an authentication server 21 and a backend server 22. The backend server 22 provides a third service. The user 71 is registered as a member of the first service and has a user ID for the first service. When the user 71 requests global login to the third service, the global ID platform 50 relays the request from the authentication server 21 to the authentication server 11, and relays the authentication result of authentication server 11 in response to the request from the authentication server 11 to the authentication server 21." [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2022-165546 A Summary of the Invention [Problem to be solved by the invention]

[0007] The authentication system of Patent Document 1 includes a terminal device, a first server that stores identification information for identifying a user, a second server that does not store identification information, and a platform. In the authentication system of Patent Document 1, an authentication server exists for each service, and when there are multiple services, multiple authentication servers exist.

[0008] In such an authentication system, when a terminal device makes an authentication request to the second server, the platform relays the authentication request to the first server because the second server does not store information for identifying the user, and the platform then relays the authentication result of the first server to the second server.

[0009] In this way, the first server stores information for identifying a user, whereas the second server does not store information for identifying a user. Therefore, when an authentication request is made to the second server, the authentication system of Patent Document 1 needs to relay the authentication request to the first server.

[0010] The present invention has been made in consideration of the above circumstances, and has an object to link personal data across a plurality of relying party apps without relaying an authentication request. [Means for solving the problem]

[0011] The personal data linkage system according to the present invention includes a pan-authentication system that, in response to a request from a terminal of a user who uses a first relying party via a first relying party app, registers an account of an ID provider held by the user, generates a base ID that can uniquely identify the user, and links and registers the base ID and the account; a pan-personal authentication system linkage unit that, upon receipt of a linkage request from the first relying party app and when the pan-personal authentication system authenticates the user at the ID provider using the account, registers the linkage between the first relying party and the base ID in an ID conversion table; and a pan-personal authentication system linkage unit that receives a permission request from the first relying party app for linkage with a second relying party and registers the permission request. the data of the first relying party to the second relying party via the base ID; a permission confirmation unit, when a data acquisition request from the first relying party is received, confirming the second relying party's permission for the first relying party in the permission management table; and a data providing unit, when the second relying party has permission for the first relying party in the permission management table, responding with the requested data for the data acquisition request. Effect of the Invention

[0012] According to the present invention, personal data can be linked across a plurality of relying party applications without relaying an authentication request. [Brief description of the drawings]

[0013] [Figure 1] 1 is a block diagram showing an outline of a personal data linking system according to an embodiment of the present invention. [Diagram 2] 1 is a configuration diagram showing an overview of the overall configuration of a personal data linkage system according to an embodiment of the present invention. [Diagram 3] FIG. 2 is an explanatory diagram showing four processes for linking personal data between servicers in the personal data linking system according to the present embodiment. [Figure 4] 1 is a configuration diagram showing an account registration process for a user who uses a mobile terminal in a personal data linkage system. [Diagram 5] 1 is a configuration diagram showing the linking process between a servicer and a general personal authentication system in a personal data linking system. [Figure 6] A configuration diagram showing the release of the link between a servicer and a general personal authentication system in a personal data linkage system. [Figure 7] 1 is a configuration diagram showing a permission request from a servicer and permission acquisition processing in a personal data linkage system. [Figure 8] 11 is a configuration diagram showing the process of canceling the target permission from the servicer in the personal data linkage system. [Figure 9] 1 is a configuration diagram showing data linking processing between a servicer 300 and a servicer 400 in a personal data linking system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings. In the description of the drawings, the same elements are given the same reference numerals, and duplicated description will be omitted as appropriate.

[0015] <Outline of personal data linking system> FIG. 1 is a block diagram showing an outline of a personal data linkage system 600 according to this embodiment.

[0016] 1, the personal data linkage system 600 includes a mobile terminal (terminal) 100, a personal data linkage management system 250, an ID provider 210, a servicer 300, a servicer 400, and a P2P (Peer to Peer) network 500. Security is ensured in the P2P network 500.

[0017] The servicer 300 is a first relying party that is used by the user's mobile terminal 100 via a service application 301. The service application 301 is a first relying party application.

[0018] The servicer 400 is a second relying party that is used by the user's mobile terminal 100 via a service application 401. The service application 401 is a second relying party application.

[0019] The mobile terminal 100 is a mobile terminal owned and used by an end user. The mobile terminal 100 is an example of a user's terminal, and corresponds to, for example, a mobile information terminal such as a smartphone or a PDA (Personal Digital Assistant), a notebook computer which is a notebook-type personal computer, a personal computer, or other information processing device. A relying party application that enjoys a service by accessing a relying party is installed in the mobile terminal 100.

[0020] The personal data linkage management system 250 includes a general personal authentication system 200 , a permission management unit 205 , and a communication unit 206 .

[0021] The general-personal authentication system 200 cooperates with the ID provider 210 to authenticate an end user who uses the mobile terminal 100. The general-personal authentication system 200 cooperates with, for example, a servicer 300 that embodies a first relying party and a servicer 400 that embodies a second relying party.

[0022] Specifically, the general-personal authentication system 200 registers an account of the ID provider 210 owned by the user in response to a request from the mobile terminal 100 of the user who uses the servicer 300 via the service application 301. The service application 301 is a first relying party application. At the same time, the general-personal authentication system 200 generates a base ID that can uniquely identify the user based on the information of the account received from the ID provider 210. Furthermore, the general-personal authentication system 200 registers the generated base ID in association with the account.

[0023] Furthermore, the general-personal authentication system 200 registers an account of the ID provider 210 owned by the user in response to a request from the mobile terminal 100 of the user who uses the servicer 400 via the service application 401. The service application 401 is a second relying party application. At the same time, the general-personal authentication system 200 generates a base ID that can uniquely identify the user based on the information of the account received from the ID provider 210. Furthermore, the general-personal authentication system 200 registers the generated base ID in association with the account.

[0024] The permission management unit 205 accepts a permission request from the servicer 300 to cooperate with the servicer 400, and registers the data of the permission request in the permission management table 203. Then, when the permission management unit 205 acquires permission for the permission request from the mobile terminal 100 of the user, it updates the data of the permission request to "approved."

[0025] Furthermore, the permission management unit 205 can also cancel the obtained permission for cooperation between the servicer 300 and the servicer 400 by the mobile terminal 100 of the user.

[0026] The communication unit 206 is a network interface that connects the personal data link management system 250 to the mobile terminal 100 via the Internet.

[0027] The ID provider 210 is, for example, a system or server that provides a service for storing and managing authentication information for logging in to a cloud service. The ID provider 210 is an ID provider that supports the general-purpose personal authentication system 200, and provides authentication that complies with the corresponding OIDC (OpenID Connect) standard to each of the servicers 300 and 400. Note that the method by which the ID provider 210 authenticates the servicers 300 and 400 is not limited to the method that complies with the OIDC standard.

[0028] The servicer 300 and the servicer 400 are each authenticated by the ID provider 210 via the general-purpose personal authentication system 200, and thereby provide a predetermined service to the mobile terminal 100.

[0029] The servicer 300 is a server device that cooperates with the mobile terminal 100 by executing a service application 301 installed in the mobile terminal 100. The service application 301 is a first relying party application. The servicer 300 is a first relying party. The servicer 300 provides a first relying party service to a user.

[0030] The servicer 400 is a server device that cooperates with the mobile terminal 100 by executing a service application 401 installed in the mobile terminal 100. The service application 401 is a second relying party application. The servicer 400 is a second relying party. The servicer 400 provides a second relying party service to a user.

[0031] Moreover, the servicer 300 and the servicer 400 have the same configuration. That is, each of the servicers 300 and 400 has the same platform. In this embodiment, the function of the servicer 300 to request acquisition of personal data will be described, and the function of the servicer 400 to confirm permission for cooperation and provide personal data will be described. Note that the functions of the servicer 300 and the servicer 400 are mutually interchangeable because they have the same functions.

[0032] The servicer 300 is configured to include a general-personal authentication system cooperating unit 302 , a permission requesting unit 303 , a permission confirming unit 313 , a personal data acquisition requesting unit 304 , a personal data providing unit 314 , and a communication unit 305 .

[0033] The servicer 400 is configured to include a general-personal authentication system cooperating unit 402 , a permission requesting unit 403 , a permission confirming unit 413 , a personal data acquisition requesting unit 404 , a personal data providing unit 414 , and a communication unit 405 .

[0034] When a linkage request is received from the service application 301 and the general personal authentication system 200 authenticates the user at the ID provider 210 using the account, the general personal authentication system linkage unit 302 registers the linkage between the servicer 300 and the base ID in the ID conversion table 307. The service application 301 is a first relying party application. The servicer 300 is a first relying party.

[0035] The service application 301 constituting the servicer 300 redirects the user to an association screen on the mobile terminal 100, and then performs user authentication on the ID provider 210 corresponding to the user. After that, the service application 301 registers association with the servicer 300 in an ID conversion table 307 (to be described later) using an association API, and registers information necessary for this association.

[0036] When a linkage request is received from the service application 401 and the general personal authentication system 200 authenticates the user at the ID provider 210 using the account, the general personal authentication system linkage unit 402 registers the linkage between the servicer 400 and the base ID in the ID conversion table 407. The service application 401 is a second relying party application. The servicer 400 is a second relying party.

[0037] The service application 401 constituting the servicer 400 redirects the user to an association screen on the mobile terminal 100, and then performs user authentication on the ID provider 210 corresponding to the user. After that, the service application 401 registers association with the servicer 400 in an ID conversion table 407 (to be described later) using an association API, and registers information necessary for this association.

[0038] Furthermore, the general-personal authentication system cooperation units 302 and 402 can release the cooperation between the servicers 300 and 400 and the general-personal authentication system 200, respectively.

[0039] The relying party refers to an entity that requests authentication from the ID provider 210 and provides a service to a user by trusting the authentication information. In this embodiment, the relying party refers to a site or service that can be logged in with OpenID, and is also called a service provider or servicer. According to the present invention, personal data can be transferred between two relying parties that provide services of completely different business entities, for example, between the servicers 300 and 400, based on the user's permission. The relying party app refers to a functional unit that is embodied by being executed by the processor of the user's mobile terminal 100, for example.

[0040] This allows the servicer 300 and the servicer 400 to provide the user of the mobile terminal 100 with predetermined services provided by completely different business entities via the P2P network 500.

[0041] The permission request unit 303 receives a permission request for cooperation with the servicer 400 from the servicer 300. The permission request unit 303 registers data of the permission request for cooperation in a permission management table 203 of the personal data linkage management system 250 described later via the permission management unit 205 of the personal data linkage management system 250.

[0042] The permission request unit 403 receives a permission request for cooperation with the servicer 300 from the servicer 400. The permission request unit 403 registers data of the cooperation permission request in the permission management table 203 of the personal data linkage management system 250 described later via the permission management unit 205 of the personal data linkage management system 250.

[0043] When the permission confirmation unit 313 receives a data acquisition request from the servicer 400 , it confirms the state of the permission of the servicer 300 to cooperate with the servicer 400 in the permission management table 203 of the personal data cooperation management system 250 .

[0044] When the permission confirmation unit 413 receives a data acquisition request from the servicer 300 , it checks the permission management table 203 of the personal data linkage management system 250 to see whether the servicer 400 has granted permission to link with the servicer 300 .

[0045] The personal data acquisition request unit 304 allows the servicer 300 to make a request to the servicer 400 to acquire data from the servicer 400 via the base ID.

[0046] A personal data acquisition request unit 404 makes a data acquisition request from the servicer 400 to the servicer 300 via the base ID.

[0047] If the permission management table 203 of the personal data linkage management system 250 indicates that the servicer 300 has permission to link with the servicer 400, the personal data providing unit 314 responds to the data acquisition request with the requested data.

[0048] If the permission management table 203 of the personal data linkage management system 250 indicates that the servicer 400 has permission to link with the servicer 300, the personal data providing unit 414 responds to the data acquisition request with the requested data.

[0049] The communication units 305 and 405 are network interfaces that connect to the personal data linkage management system 250 via the P2P network 500 .

[0050] The P2P network 500 is, for example, a highly confidential tool built using electronic solutions. In other words, the P2P network 500 corresponds to a network with extremely high security. The P2P network 500 is configured with, for example, a center server, a security server, an information system, a time stamp authority, a certification authority, a configuration proxy, an operation monitoring daemon, and the like, all of which are not shown.

[0051] Specifically, the P2P network 500 is configured as a mesh-type P2P (Peer to Peer). The P2P network 500 is formed as a closed network, and is a private network that can be connected only from within a specific base or by limited users. Therefore, unlike a line that can be used by an unspecified number of users such as the Internet, the P2P network 500 cannot be connected to any system other than a specific system that can cooperate with the general-purpose personal authentication system 200. In this embodiment, the P2P network 500 is limited to connections between the general-purpose personal authentication system 200, the servicer 300, and the servicer 400, and cannot be connected to any other device.

[0052] <Features of the personal data linkage management system> The personal data linkage management system 250 of the personal data linkage system 600 in FIG. 1 has the following four features.

[0053] First, the personal data linkage management system 250 has a function of linking with the ID provider 210 through the general personal authentication system 200. This allows the personal data linkage management system 250 to perform authentication using an account of the ID provider 210 already held, without creating a new ID, and to provide a predetermined service.

[0054] Secondly, the personal data linkage management system 250 has an identity verification function (eKYC: electronic Know Your Customer). The personal data linkage management system 250 can verify the identity of a person using an official ID card and can link identity verification information.

[0055] Thirdly, the personal data linkage management system 250 has a linkage service management function by the general personal authentication system 200. The general personal authentication system 200 can link with a plurality of relying parties, which are various services with different business entities and responsible entities. Therefore, the personal data linkage management system 250 does not care about the industry or business form of the relying party that can link. In other words, the linkage by the general personal authentication system 200 in the personal data linkage management system 250 is not limited to the industry or business form. In addition, the linkage by the general personal authentication system 200 in the personal data linkage management system 250 may be a linkage across borders. In other words, the general personal authentication system 200 can link with a predetermined relying party across borders without being limited to the user's residential area.

[0056] Fourthly, the personal data linkage management system 250 has a permission management function by the permission management unit 205. This allows the personal data linkage based on permission to be realized securely in the personal data linkage management system 250. In other words, the personal data linkage management system 250 allows permission or cancellation at the user's will via the P2P network 500.

[0057] <Overall configuration of personal data linkage system> 2 is a block diagram showing an overview of the overall configuration of the personal data linkage system 600 according to this embodiment. In this embodiment, the servicer 300 will be described below using only the necessary components in order to explain the function of requesting acquisition of personal data. Similarly, the servicer 400 will be described below using only the necessary components in order to explain the function of confirming permission for linkage and providing personal data.

[0058] As shown in FIG. 2, the personal data linkage system 600 includes a mobile terminal 100, an ID provider 210, a personal data linkage management system 250, a servicer 300, a servicer 400, and a P2P network 500.

[0059] The mobile terminal 100 can receive a predetermined service from the servicer 300 or the servicer 400 by signing in to the servicer 300 or the servicer 400. The mobile terminal 100 is also configured to include a service application utilization unit 101, a general-personal authentication system cooperative authentication unit 102, and an acceptance response unit 103.

[0060] The mobile terminal 100 can receive a predetermined service provided by the service application 301 of the servicer 300, for example, by signing in to the servicer 300 and being authenticated by the service application utilization unit 101. Next, the mobile terminal 100 can make an authentication request to the general-personal authentication system 200 by logging in to the personal data linkage management system 250 from the general-personal authentication system linkage authentication unit 102. Thus, the general-personal authentication system 200 can make an authentication request to the corresponding ID provider 210. When the authentication is OK, the mobile terminal 100 can link the general-personal authentication system 200 and the servicer 300 by the general-personal authentication system linkage unit 302.

[0061] Furthermore, the permission response unit 103 grants or denies a permission request for cooperation from the servicer 300 to the permission management unit 205 of the personal data cooperation management system 250. After granting permission in response to a permission request for cooperation, the permission response unit 103 can also cancel the permission.

[0062] The personal data linkage management system 250 is configured to include a general personal authentication system 200, a relying party link table 201 that manages the whole system, an ID conversion table 202 that indicates conversion with a base ID, a permission management table 203, a user master 204 that stores the base ID, a permission management unit 205, and a communication unit 206. In this embodiment, the personal data linkage management system 250 is characterized by including the general personal authentication system 200, the permission management table 203, and the permission management unit 205.

[0063] The servicer 300 is configured to include a service application 301, a general personal authentication system linking unit 302, a permission requesting unit 303, a personal data acquisition requesting unit 304, a communication unit 305, a user master 306 that manages existing IDs, an ID conversion table 307 that manages base IDs only for the servicer's company, and a service application database 308. The servicer 300 is characterized by including the general personal authentication system linking unit 302 and the ID conversion table 307. In the ID conversion table 307, existing IDs and base IDs are linked to each other.

[0064] The servicer 400 is configured to include a service application 401, a general personal authentication system linking unit 402, a permission confirmation unit 413, a personal data providing unit 414, a communication unit 405, a user master 406 that manages existing IDs, an ID conversion table 407 that manages base IDs only for the servicer's company, and a service application database 408. The servicer 400 is characterized by including the general personal authentication system linking unit 402 and the ID conversion table 407. In the ID conversion table 407, existing IDs and base IDs are linked to each other.

[0065] Each of the servicer 300 and the servicer 400 is connected to the personal data link management system 250 via a P2P network 500 .

[0066] The P2P network 500 connects the personal data link management system 250, the servicer 300, and the servicer 400 to each other.

[0067] In this embodiment, the servicer 400 has the same configuration as the servicer 300. The servicer 300 constitutes, for example, a personal data reference company. Meanwhile, the servicer 400 constitutes a personal data providing company. The servicer 300 and the servicer 400 can exchange their functions. The personal data linkage system 600 includes a plurality of servicers 300 and 400, and the general personal authentication system 200 links with each of the plurality of servicers 300 and 400, so that each of the plurality of servicers 300 and 400 can link personal data with each other.

[0068] <Permission-based data integration process for personal data integration system> The permission-based data linking process of the personal data linking system 600 having the configurations of FIGS. 1 and 2 will be described with reference to FIG.

[0069] FIG. 3 is an explanatory diagram showing four processes for linking personal data between the servicer 300 and the servicer 400 in the personal data linking system 600 according to this embodiment.

[0070] The personal data linkage system 600 is composed of an account registration process for the general-personal authentication system 200 in step S11, linkage processing for the general-personal authentication system 200 at each servicer 300, 400 in step S21, a permission request and permission acquisition process from the servicer 300 in step S31, and a personal data linkage process in step S41.

[0071] In the "account registration process for the universal personal authentication system 200" in step S11 of Figure 3, the user 700 operates the mobile terminal 100 (step S13) and generates a base ID in the universal personal authentication system 200 of the personal data linkage management system 250, thereby registering an account in the universal personal authentication system 200 (step S15).

[0072] In the "integration processing of the general-personal authentication system 200 at each servicer 300, 400" in step S21 of Figure 3, the user 700 operates the mobile terminal 100 to log in to the servicer 300 (step S23) and presses a link button (not shown) for linking with the general-personal authentication system 200, thereby enabling the servicer 300 to link with the general-personal authentication system 200 (step S25).

[0073] Similarly, in step S21, in the case of the servicer 400, the user 700 operates the mobile terminal 100 to log in to the servicer 400 (step S27) and presses a link button (not shown) for linking with the universal personal authentication system 200, thereby enabling the servicer 400 to link with the universal personal authentication system 200 (step S29).

[0074] The cancellation of the link with the general-personal authentication system 200 will be described later with reference to FIG.

[0075] In the “permission request from servicer 300 and permission acquisition process” in step S31 of FIG. 3, an appropriate process of the servicer 300 makes a permission request to the personal data linkage management system 250 (step S33), and the user operates the permission screen of the mobile terminal 100 to grant permission (step S35).

[0076] The cancellation of the obtained permission for cooperation will be described later with reference to FIG.

[0077] In the "personal data linking process" in step S41 in Fig. 3, the servicer 300 makes a request to the servicer 400 to obtain personal data (step S43). If the link between the servicer 300 and the servicer 400 has been approved, the servicer 400 provides the personal data to the servicer 300 (step S45). The servicer 300 uses the personal data of the servicer 400 to provide a predetermined service of the servicer 300 to the user 700 who uses the mobile terminal 100 (step S47).

[0078] Next, steps S11, S21, S31, and S41 shown in FIG. 3 will be described in more detail with reference to FIG. 4 to FIG.

[0079] <Step S11 in FIG. 3> The "account registration process of the general-purpose personal authentication system 200" in step S11 in FIG. 3 will be described with reference to the configuration diagram of the personal data linkage system 600 in FIG.

[0080] Fig. 4 is a configuration diagram showing the account registration process of a user 700 who uses a mobile terminal 100 in a personal data linkage system 600. Note that, since the configuration of the personal data linkage system 600 is basically the same as the configuration of Fig. 2, the explanation will be omitted as appropriate. Also, the mobile terminal 100 is an optional component, and will be supplemented as appropriate to clarify the embodiment in the explanation of the invention.

[0081] 4 is realized by, for example, a CPU of the mobile terminal 100 executing an application program provided by a local government, etc. The account creation unit 104 of the mobile terminal 100 causes, for example, a Web application screen of the general-personal authentication system 200 to be displayed on the display unit (step S111).

[0082] Then, the general-purpose individual authentication system 200 makes an OIDC authentication request to the corresponding ID provider 210, and creates an account of the general-purpose individual authentication system 200 for the user 700 (step S113). Note that the OIDC authentication request is merely an example, and is not limited to this.

[0083] Then, the general-purpose personal authentication system 200 associates the provider information of the ID provider 210 used for the OIDC authentication with the base ID of the user master 204 and writes it into the ID conversion table 202 (step S115).

[0084] <Step S21 in FIG. 3> The "coordination process of the general personal authentication system 200 in each servicer 300, 400" in step S21 in FIG. 3 will be described with reference to the configuration diagram of a personal data coordinating system 600 in FIG.

[0085] 5 is a configuration diagram showing a linking process between the servicer 300 and the general-purpose personal authentication system 200 in the personal data linking system 600. The same applies to the case where the servicer 400 and the general-purpose personal authentication system 200 perform linking process.

[0086] As shown in FIG. 5, the user 700 logs in to the servicer 300 using the service application using unit 101 of the mobile terminal 100, and then presses a link button (not shown) for linking with the general-personal authentication system 200 (step S211). As a result, the general-personal authentication system linking unit 302 makes a link request to the general-personal authentication system 200 via the service application 301, and the display screen of the mobile terminal 100 is redirected to a link screen of the general-personal authentication system 200 (step S213). Then, the general-personal authentication system 200 performs user authentication with the corresponding ID provider 210 (step S215). In this case, the general-personal authentication system 200 accepts an input of authentication information from the general-personal authentication system linking authentication unit 102 of the mobile terminal 100 (step S216). Here, the corresponding ID provider 210 is the ID provider selected by the user on the link screen of the general-personal authentication system 200.

[0087] The general-personal authentication system cooperation unit 302 performs cooperation registration of the servicer 300 in the relying party link table 201 via the service application 301 by a cooperation API (Application Programming Interface) that cooperates with the general-personal authentication system 200 (step S217). In addition, the general-personal authentication system cooperation unit 302 writes necessary information into the ID conversion table 307, and displays the cooperation state with the general-personal authentication system 200 on the display unit of the mobile terminal 100 (step S219). In this case, the ID conversion table 307 links the base ID with the company's existing ID.

[0088] 6 is a configuration diagram showing the release of the link between the servicer 300 and the general personal authentication system 200 in the personal data linkage system 600. The same applies to the case where the servicer 400 and the general personal authentication system 200 release the link.

[0089] As shown in FIG. 6, on the application screen displayed by the service application utilization unit 101 of the mobile terminal 100, the user 700 taps a release button (not shown) for releasing the link with the general-personal authentication system 200 (step S231).

[0090] As a result, the service application utilization unit 101 of the mobile terminal 100 accepts a tap of a release button (not shown) for releasing the link with the general-personal authentication system 200 in the service application 301 of the servicer 300. Here, when the general-personal authentication system linking unit 302 releases the link with the general-personal authentication system 200 via the service application 301, all related permission data is deleted from the relying party link table 201. Therefore, the service application utilization unit 101 should confirm in advance with the user that the user will no longer be able to receive the benefits of various data links.

[0091] Then, the general-personal authentication system cooperation unit 302 transmits a cooperation cancellation request to the relying party link table 201 via the service application 301 by using a cooperation API that cooperates with the general-personal authentication system 200 (step S233).

[0092] Moreover, the general-personal authentication system cooperation unit 302 also deletes all the target records from the ID conversion table 307 of the servicer 300 (step 235).

[0093] <Step S31 in Fig. 3> The "license request from the servicer 300 and permission acquisition process" in step S31 in FIG. 3 will be described with reference to the configuration diagram of the personal data linkage system 600 in FIG.

[0094] Fig. 7 is a configuration diagram showing a permission request from the servicer 300 and permission acquisition processing in the personal data linkage system 600. Note that the permission request from the servicer 400 and permission acquisition processing are performed in the same manner as in Fig. 7. Also, the following description is based on the assumption that the mobile terminal 100 used by the user 700 is logged in to the personal data linkage management system 250.

[0095] 7, the service application 301 of the servicer 300 appeals to the user 700 of the mobile terminal 100 about the purpose of use of personal data that is the target of the other company and the merits of using the personal data, and urges consent (step S311). In this case, the target of the other company corresponds to, for example, the service application 401 of the servicer 400.

[0096] The permission request unit 303 uses the permission request registration API to register the permission request data in the permission management table 203 via the service application 301 and the permission management unit 205 (step S313). When the permission management unit 205 registers the permission request data in the permission management table 203, the permission request unit 303 transitions the screen of the mobile terminal 100 to a permission acquisition screen of the general-personal authentication system 200.

[0097] Thereby, the permission request unit 303 makes a permission request for cooperation of the servicer 400 in response to a data acquisition request from the servicer 300 to the service application 401 of the servicer 400, for example.

[0098] The user 700 operates the permission response unit 103 of the mobile terminal 100, and the permission management unit 205 acquires permission for linkage on the permission acquisition screen of the general-personal authentication system 200 (step S315). In this case, the permission management unit 205 changes the status of the data that is the subject of the permission request registered in the permission management table 203 to "approved" (step S317).

[0099] Thereby, the personal data linkage system 600 can, for example, grant permission for linkage between the servicer 400 and the servicer 300, and can respond to a data acquisition request from the servicer 300 to the servicer 400.

[0100] Fig. 8 is a configuration diagram showing the process of canceling the permission from the servicer 300 in the personal data linkage system 600. Note that the process of canceling the permission from the servicer 400 is similar to that shown in Fig. 8.

[0101] 8, the user 700 connects the permission response unit 103 of the mobile terminal 100 to the permission management unit 205. Then, the user 700 selects cancellation of the permission for the target relying party by displaying the service screen of the general-personal authentication system 200 on the display unit of the mobile terminal 100 (step S331). For example, the user 700 selects cancellation of the permission of the servicer 400 to the servicer 300.

[0102] In this case, the permission response unit 103 acquires the cancellation of permission from the user 700 and transmits it to the permission management unit 205. As a result, the permission management unit 205 accepts the cancellation of permission for the relevant relying party. In principle, the cancellation of permission is performed on the service screen displayed by the general-personal authentication system 200.

[0103] The permission management unit 205 changes the status and the permission flag of the record related to the target relying party in the permission management table 203 (step S333). For example, the permission management unit 205 cancels the permission of the servicer 400 to the servicer 300.

[0104] <Step S41 in Fig. 3> The "personal data linking process" in step S41 in FIG. 3 will be described with reference to the configuration diagram of a personal data linking system 600 in FIG.

[0105] FIG. 9 is a configuration diagram showing data linking processing between the servicer 300 and the servicer 400 in the personal data linking system 600. As shown in FIG.

[0106] As shown in FIG. 9, when the user 700 operates the mobile terminal 100, the service application 301 provides a data service to the service application usage unit 101 using the personal data of the user 700 stored in the service application database 308 (step S411).

[0107] Here, in order to further obtain from the servicer 400 the personal data of the user 700 stored in the service application database 408 of the servicer 400, the personal data acquisition request unit 304 sends a data acquisition request to the permission confirmation unit 413 of the servicer 400 (step S413).

[0108] In this case, the permission confirmation unit 413 of the servicer 400 confirms the state of the permission of the servicer 400 to the servicer 300 in the permission management table 203 of the personal data linkage management system 250 via the P2P network 500 (step S415).

[0109] Here, if the permission management table 203 indicates that the servicer 400 is permitted to cooperate with the servicer 400, the personal data providing unit 414 transmits the personal data of the user 700 stored in the service application database 408 to the service application 301 of the servicer 300 (step S417). On the other hand, if the permission management table 203 indicates that the servicer 400 is not permitted to cooperate with the servicer 400, the personal data providing unit 414 returns an error to the service application 301.

[0110] If the permission management table 203 does not contain permission for cooperation with the servicer 400, the personal data providing unit 414 may return an error indicating that the permission does not exist, and may perform the permission request for cooperation and permission acquisition process (third process) shown in Fig. 7. The permission confirmation unit 413 may return an error indicating that the permission does not exist to the personal data acquisition request unit 304.

[0111] This allows the servicer 300 to further provide a data service to the service application use unit 101 by using the personal data of the user 700 stored in the service application database 408 of the servicer 400 .

[0112] Even if the functions of the servicer 300 and the servicer 400 are interchanged, the servicer 300 can transmit personal data related to the desired user 700 of the servicer 400 to the servicer 400 .

[0113] In this way, the personal data linking system 600 can link the personal data of the servicer 300 and the servicer 400 with each other, so that personal data can be linked across multiple servicers 300, 400 (relying party applications).

[0114] As described above, the personal data linkage system 600 of this embodiment is configured to include the general-personal authentication system 200, the general-personal authentication system linkage units 302, 402, the permission management unit 205, the personal data acquisition request unit 304, the permission confirmation unit 413, and the personal data provision unit 414.

[0115] In response to a request from the mobile terminal 100 of a user 700 who uses a servicer 300 (first relying party) via a service application 301 (first relying party application), the general-personal authentication system 200 registers an account of the ID provider 210 held by the user 700 and generates a base ID that can uniquely identify the user 700. The general-personal authentication system 200 also registers the base ID and the account of the ID provider 210 in association with each other.

[0116] When a linkage request is received from the service application 301 and the general-personal authentication system 200 authenticates the user at the ID provider 210 using the account, the general-personal authentication system linkage unit 302 registers the linkage between the servicer 300 and the base ID in the ID conversion table 307.

[0117] When a linkage request is received from the service application 401 and the general-personal authentication system 200 authenticates the user at the ID provider 210 using the account, the general-personal authentication system linkage unit 402 registers the linkage between the servicer 400 and the base ID in the ID conversion table 407.

[0118] The permission management unit 205 accepts a permission request for cooperation with the servicer 400 from the servicer 300, and registers data of the permission request in the permission management table 203. Then, when the permission management unit 205 acquires permission for cooperation in response to the permission request from the mobile terminal 100 of the user, the permission management unit 205 updates the data of the permission request for cooperation to "permitted."

[0119] The personal data acquisition request unit 304 allows the servicer 300 to make a request to the servicer 400 to acquire data from the servicer 400 via the base ID.

[0120] When a data acquisition request is received from the servicer 300 , the permission confirmation unit 413 of the servicer 400 checks the status of the permission of the servicer 400 to cooperate with the servicer 300 in the permission management table 203 of the personal data cooperation management system 250 .

[0121] If the permission management table 203 of the personal data linkage management system 250 indicates that the servicer 400 has permission to link with the servicer 300, the personal data providing unit 414 responds to the data acquisition request with the requested personal data.

[0122] In the personal data linkage system 600 of this embodiment, when the servicer 300 makes a data acquisition request from the servicer 400 and the permission management table 203 indicates permission for the servicer 400 to link with the servicer 300, the personal data providing unit 414 of the servicer 400 transmits the personal data in the service app database 408 to the service app 301 of the servicer 300.

[0123] This allows the servicer 300 to provide the data service of the service application 301 to the service application use unit 101 by using the personal data of the user 700 stored in the service application database 408 of the servicer 400 .

[0124] In this manner, in the personal data linking system 600, the servicer 300 can link with the personal data of the servicer 400 by the servicer 300 making a data acquisition request to the servicer 400.

[0125] Therefore, the personal data linking system 600 according to this embodiment can link personal data across, for example, the servicer 300 and the servicer 400 without relaying an authentication request.

[0126] In addition, in the personal data linkage system 600, the permission management table 203 permits linkage with many relying parties in the general personal authentication system 200. This allows the user 700 to link personal data to the use of multiple services, such as the servicer 300 for rental cars, the servicer 400 for shopping, the servicer 300 for restaurants, and the servicer 400 for hotels, by simply authenticating to the general personal authentication system 200 once.

[0127] Each of the general-personal authentication system cooperation units 302 and 402 can cancel cooperation between the servicers 300 and 400 and the general-personal authentication system 200 .

[0128] Furthermore, the permission management unit 205 of the personal data linkage management system 250 can cancel the obtained permission for linkage in response to an instruction from the mobile terminal 100 of the user 700.

[0129] Furthermore, when the servicer 400 does not have permission for the servicer 300, the permission confirmation unit 413 or the personal data provision unit 414 responds with an error to the effect that there is no permission. Furthermore, when there is no permission for cooperation with each of the servicers 300 and 400, step S31 in FIG. 3 may be executed to prompt each of the servicers 300 and 400 to request permission and perform permission acquisition processing. [Explanation of symbols]

[0130] 100 Mobile devices (terminals) 101 Service Application User Section 102 Universal Personal Authentication System Collaboration Authentication Unit 103 Acceptance Response Section 104 Account Creation Department 200 Universal Personal Authentication System 201 Relying Party Link Table 202 ID conversion table 203 Permission Management Table 204 User Master 205 Permission Management Department 206 Communications Department 210 Identity Provider 250 Personal Data Linkage Management System 300 Servicer (First Relying Party) 400 Servicer (Second relying party) 301,401 Service Apps 302,402 Universal Personal Authentication System Collaboration Department 303,403 Permission Request Department 313,413 Permission Verification Department 304, 404 Personal data acquisition request unit (data acquisition request unit) 314,414 Personal Data Provision Department (Data Provision Department) 305,405 Communications Department 306,406 User Master 307,407 ID conversion table 308,408 service app database 500 P2P Network 600 Personal Data Linkage System 700 users

Claims

1. a general personal authentication system that, in response to a request from a terminal of a user who uses a first relying party via a first relying party app, registers an account of an ID provider held by the user, generates a base ID that can uniquely identify the user, and associates the base ID with the account and registers the base ID; a general personal authentication system linking unit that registers, when a linking request is received from the first relying party application and the general personal authentication system authenticates the user at the ID provider using the account, a link between the first relying party and the base ID in an ID conversion table; a permission management unit that receives a permission request from the first relying party for cooperation with a second relying party, registers data of the permission request in a permission management table, and updates the data of the permission request to "permitted" when permission for the permission request is obtained from the user's terminal; a data acquisition request unit configured to send a data acquisition request from the second relying party to the second relying party via the base ID of the first relying party; a permission confirmation unit that, when receiving a data acquisition request from the first relying party, confirms a state of permission of the second relying party to the first relying party in the permission management table; a data providing unit that responds with requested data in response to the data acquisition request when the second relying party has permission for the first relying party in the permission management table; A personal data linking system comprising:

2. The general personal authentication system linking unit includes: canceling the link between the first relying party and the general personal authentication system; The personal data linking system according to claim 1 .

3. The permission management unit Releasing the acquired permission through the user's terminal; The personal data linking system according to claim 1 .

4. The permission confirmation unit or the data provision unit, if the second relying party does not have permission to the first relying party, respond with an error indicating that permission does not exist; The personal data linking system according to claim 1 .

5. a step in which the general-personal authentication system, in response to a request from a terminal of a user who uses a first relying party via a first relying party app, registers an account of an ID provider held by the user, generates a base ID that can uniquely identify the user, and associates the base ID with the account and registers the base ID; a step of registering, in an ID conversion table, a link between the first relying party and the base ID, when a link request is received from the first relying party application and the general personal authentication system authenticates the user at the ID provider using the account, by a general personal authentication system linking unit; a permission management unit receiving a permission request from the first relying party for cooperation with a second relying party, registering data of the permission request in a permission management table, and updating the data of the permission request to "permitted" when permission for the permission request is obtained from the user's terminal; a data acquisition request unit, which transmits a data acquisition request from the first relying party to the second relying party via the base ID; a permission confirmation unit, when receiving a data acquisition request from the first relying party, confirming the permission of the second relying party to the first relying party in the permission management table; a data providing unit responding with the requested data in response to the data acquisition request when the second relying party has given permission to the first relying party in the permission management table; A data integration method for a personal data integration system that executes the above.

Images