Personal data sharing system and personal data sharing method

Abstract

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

Description

Technical Field

[0001] The present invention relates to a personal data connection system and a personal data connection method.

Background Art

[0002] Conventionally, in applications of smartphones or personal computers, in order to receive a predetermined service, an account corresponding to the predetermined service is required respectively. For an account corresponding to a predetermined service, for example, an ID (identification) for logging in and a password are input, and when authentication is successful, the corresponding predetermined service can be received.

[0003] In recent years, in authentication systems, it has been considered that when logging in using one ID using the protocol of OpenID Connect, multiple services can be received. Here, linking one ID to multiple services is also referred to as ID linking. As the number of services provided by ID linking increases, users can use services across multiple services.

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

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

[0006] [Patent Document 1] Japanese Patent Publication No. 2022-165546 [Overview of the Initiative] [Problems that the invention aims to solve]

[0007] The authentication system described in Patent Document 1 comprises 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 this authentication system of Patent Document 1, there is an authentication server for each service, and if there are multiple services, there are multiple authentication servers.

[0008] In such an authentication system, when an authentication request is sent from a terminal device to a second server, the platform relays the authentication request to the first server because the second server does not store information to identify the user. The platform then relays the authentication result from the first server to the second server.

[0009] Thus, the first server stores information for identifying the user, while the second server does not. Therefore, when an authentication request is made to the second server, the authentication system described in Patent Document 1 needs to relay that authentication request to the first server.

[0010] This invention has been made in view of the above circumstances, and aims to link personal data across multiple relying party applications without relaying authentication requests. [Means for solving the problem]

[0011] The personal data linkage system according to the present invention includes a general authentication system that, in response to a request from a terminal of a user using the first relying party via the first relying party application, registers the user's ID provider account, generates a base ID that can uniquely identify the user, and links the base ID with the account; a general personal authentication system linkage unit that, upon receiving a linkage request from the first relying party application and if the general personal authentication system authenticates the user with 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 request for permission to link with the second relying party from the first relying party, and the request for permission to link with the second relying party. The system includes: a license management unit that registers the data in a license management table and updates the data of the license request to "licensed" when a license for the license request is obtained from the user's terminal; a data acquisition request unit that the first relying party requests the second relying party to acquire data from the second relying party via the base ID; a license confirmation unit that, upon receiving a data acquisition request from the first relying party, confirms the second relying party's license to the first relying party in the license management table; and a data provision unit that, if the license management table shows that the second relying party has granted a license to the first relying party, responds with the requested data in response to the data acquisition request. [Effects of the Invention]

[0012] According to the present invention, personal data can be linked across multiple relying party applications without the need to relay authentication requests. [Brief explanation of the drawing]

[0013] [Figure 1] This is a block diagram illustrating the outline of the personal data linkage system according to this embodiment. [Figure 2] This is a diagram showing an overview of the overall configuration of the personal data linkage system according to this embodiment. [Figure 3] This diagram illustrates four processes for linking personal data between service providers in the personal data linkage system according to this embodiment. [Figure 4] This diagram illustrates the account registration process for users using mobile devices within the personal data linkage system. [Figure 5] This diagram illustrates the configuration of the personal data linkage system, showing the linkage process between the servicer and the general personal authentication system. [Figure 6] This diagram illustrates the decoupling of the servicer from the general personal authentication system within the personal data sharing system. [Figure 7] This diagram illustrates the configuration of a personal data sharing system, showing the process of obtaining and receiving permission from a service provider. [Figure 8] This diagram illustrates the process for revoking permission from the servicer within the personal data sharing system. [Figure 9] This is a diagram illustrating the data sharing process between Servicer 300 and Servicer 400 in the personal data sharing system. [Modes for carrying out the invention]

[0014] Hereinafter, embodiments of the present invention will be described with reference to the attached drawings. In the description of the drawings, the same reference numerals are assigned to the same elements, and duplicate descriptions will be omitted as appropriate.

[0015] <Schematic Configuration of Personal Data Linkage System> FIG. 1 is a block diagram showing an overview of a personal data linkage system 600 according to the present embodiment.

[0016] As shown in FIG. 1, the personal data linkage system 600 includes a mobile terminal (terminal) 100, a personal data linkage management system 250, an ID provider (Identity Provider) 210, a service provider 300, a service provider 400, and a P2P (Peer to Peer) network 500. The P2P network 500 is secured.

[0017] The service provider 300 is a first relaying party used from the user's mobile terminal 100 via the service application 301. The service application 301 is a first relaying party application.

[0018] The service provider 400 is a second relaying party used from the user's mobile terminal 100 via the service application 401. The service application 401 is a second relaying party application.

[0019] The mobile terminal 100 is a mobile terminal owned and used by an end user. Note that the mobile terminal 100 is an example of a user's terminal, and for example, a portable information terminal such as a smartphone or a PDA (Personal Digital Assistant), a notebook personal computer which is a notebook type personal computer, and an information processing device such as a personal computer are applicable. A relaying party application for enjoying services by accessing a relaying party is installed on the mobile terminal 100.

[0020] The personal data linkage management system 250 is comprised of a general personal authentication system 200, an authorization management unit 205, and a communication unit 206.

[0021] The general personal authentication system 200 works in conjunction with the ID provider 210 to authenticate end users using the mobile terminal 100. The general personal authentication system 200 works, for example, with 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 the user's ID provider 210 account in response to a request from the user's mobile terminal 100 that uses the servicer 300 via the service application 301. The service application 301 is the first relying party application. At the same time, the general personal authentication system 200 generates a base ID that uniquely identifies the user based on the account information 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 the user's ID provider 210 account in response to a request from the user's mobile terminal 100 that 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 account information 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 authorization management unit 205 receives authorization requests from servicer 300 for linking with servicer 400 and registers the data of the authorization request in the authorization management table 203. Then, when the authorization management unit 205 obtains authorization for the authorization request from the user's mobile terminal 100, it updates the data of the authorization request to "authorized".

[0025] Furthermore, the authorization management unit 205 can also revoke the authorization for the linkage between the acquired servicer 300 and servicer 400 via the user's mobile terminal 100.

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

[0027] ID provider 210 is, for example, a system or server that provides a service for storing and managing authentication information for logging into cloud services. ID provider 210 is an ID provider compatible with the general personal authentication system 200, and provides authentication to each servicer 300 and servicer 400 in accordance with the corresponding OIDC (OpenID Connect) standard. However, the method by which ID provider 210 authenticates to servicers 300 and 400 is not limited to a method compliant with the OIDC standard.

[0028] Servicers 300 and 400 provide predetermined services to the mobile terminal 100 after being authenticated by the ID provider 210 via the general personal authentication system 200.

[0029] Servicer 300 is a server device that collaborates with the mobile terminal 100 by executing a service application 301 installed on the mobile terminal 100. Service application 301 is the first relying party application. Servicer 300 is the first relying party. Servicer 300 provides the user with the services of the first relying party.

[0030] Servicer 400 is a server device that collaborates with the mobile terminal 100 by executing a service application 401 installed on the mobile terminal 100. Service application 401 is a second relying party application. Servicer 400 is the second relying party. Servicer 400 provides the user with the services of the second relying party.

[0031] Furthermore, Servicer 300 and Servicer 400 have the same configuration. That is, Servicer 300 and Servicer 400 each have the same platform. In this embodiment, the function of Servicer 300 for requesting the acquisition of personal data will be described, and the function of Servicer 400 for confirming permission for linkage and providing personal data will be described. Note that since the functions of Servicer 300 and Servicer 400 are identical, they can be interchanged.

[0032] The servicer 300 is comprised of a general personal authentication system linkage unit 302, a permission request unit 303, a permission confirmation unit 313, a personal data acquisition request unit 304, a personal data provision unit 314, and a communication unit 305.

[0033] The servicer 400 is comprised of a general personal authentication system linkage unit 402, a permission request unit 403, a permission confirmation unit 413, a personal data acquisition request unit 404, a personal data provision unit 414, and a communication unit 405.

[0034] The General Personal Authentication System Integration Unit 302 registers the integration between the servicer 300 and the base ID in the ID conversion table 307 when it receives an integration request from the service application 301 and the General Personal Authentication System 200 authenticates the user using the account at the ID provider 210. The service application 301 is the first relying party application. The servicer 300 is the first relying party.

[0035] The service application 301, which constitutes the servicer 300, redirects the user to a linkage screen on the user's mobile device 100, and then performs user authentication with the ID provider 210 corresponding to this user. Subsequently, the service application 301 uses the linkage API to register the linkage with the servicer 300 in the ID conversion table 307, which will be described later, and registers the information necessary for this linkage.

[0036] The General Personal Authentication System Integration Unit 402 registers the integration between the servicer 400 and the base ID in the ID conversion table 407 when it receives an integration request from the service application 401 and the General Personal Authentication System 200 authenticates the user using the account at the ID provider 210. The service application 401 is a second relying party application. The servicer 400 is a second relying party.

[0037] The service application 401, which constitutes the servicer 400, redirects the user to a linkage screen on the user's mobile device 100, and then performs user authentication with the ID provider 210 corresponding to this user. Subsequently, the service application 401 uses the linkage API to register the linkage with the servicer 400 in the ID conversion table 407, which will be described later, and registers the information necessary for this linkage.

[0038] Furthermore, the general personal authentication system linkage units 302 and 402 can each disconnect the linkage between the servicers 300 and 400 and the general personal authentication system 200.

[0039] A relying party is an entity that requests authentication from the ID provider 210 and provides services to the user based on that authentication information. In this embodiment, a relying party means a site or service that can be logged into using OpenID, and is also called a service provider or servicer. The present invention makes it possible to transfer personal data between two relying parties providing services with completely different business entities, for example, between servicers 300 and 400, based on the user's consent. A relying party application is a functional unit that is realized, for example, by being executed by the processor of the user's mobile terminal 100.

[0040] This allows servicers 300 and 400 to provide users of mobile terminals 100 with predetermined services from completely different service providers via the P2P network 500.

[0041] The authorization request unit 303 receives authorization requests from servicer 300 for linking with servicer 400. The authorization request unit 303 registers the data of the linking authorization request in the authorization management table 203 of the personal data linking management system 250, which will be described later, via the authorization management unit 205 of the personal data linking management system 250.

[0042] The authorization request unit 403 receives an authorization request from servicer 400 for linking with servicer 300. The authorization request unit 403 registers the data of the linking authorization request in the authorization management table 203 of the personal data linking management system 250, which will be described later, via the authorization management unit 205 of the personal data linking management system 250.

[0043] When the authorization confirmation unit 313 receives a data acquisition request from the servicer 400, it checks the authorization status of the servicer 300's authorization to the servicer 400 in the authorization management table 203 of the personal data linkage management system 250.

[0044] When the authorization confirmation unit 413 receives a data acquisition request from the servicer 300, it checks the authorization status of the servicer 400's authorization to link with the servicer 300 in the authorization management table 203 of the personal data linkage management system 250.

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

[0046] The personal data acquisition request unit 404 receives a request from servicer 400 to servicer 300 via the base ID for servicer 400 to acquire data from servicer 400.

[0047] The personal data provision unit 314 responds to a data acquisition request with the requested data if the permission management table 203 of the personal data linkage management system 250 has permission from servicer 300 to link with servicer 400.

[0048] The personal data provision unit 414 responds to a data acquisition request with the requested data if the permission management table 203 of the personal data linkage management system 250 has permission from servicer 400 to link with servicer 300.

[0049] 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 a highly secure tool built using, for example, electronic solutions. In other words, the P2P network 500 is equivalent to an extremely secure network. The P2P network 500 is composed of, for example, a central server, security servers, information systems, a timestamp authority, a certification authority, a configuration proxy, and an operational monitoring daemon, etc. (not shown in the diagram).

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

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

[0053] Firstly, the personal data linkage management system 250 has the function of linking with the ID provider 210 via the general personal authentication system 200. As a result, the personal data linkage management system 250 can authenticate using an existing account with the ID provider 210 without creating a new ID, and provide the specified services.

[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 perform identity verification using official identification documents and can link identity verification information.

[0055] Thirdly, the personal data linkage management system 250 has a linkage service management function through the general personal authentication system 200. The general personal authentication system 200 can link with multiple relying parties, which are various services with different business entities and responsible entities. Therefore, the personal data linkage management system 250 is not limited by the industry or business type of the relying parties it can link with. In other words, the linkage by the general personal authentication system 200 in the personal data linkage management system 250 is not limited by industry or business type. Furthermore, the linkage by the general personal authentication system 200 in the personal data linkage management system 250 may cross national borders. That is, the general personal authentication system 200 can link with designated relying parties across national borders without being limited by the user's place of residence.

[0056] Fourthly, the personal data linkage management system 250 has a permission management function through the permission management unit 205. This allows the personal data linkage management system 250 to securely implement permission-based personal data linkage. In other words, the personal data linkage management system 250 allows users to grant or revoke permission via the P2P network 500.

[0057] <Overall structure of the personal data linkage system> Figure 2 is a configuration 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 using only the necessary components in order to explain its function of requesting the acquisition of personal data. Similarly, the servicer 400 will be described using only the necessary components in order to explain its function of confirming permission for linkage and providing personal data.

[0058] As shown in Figure 2, the personal data linkage system 600 is comprised of 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 servicer 300 or servicer 400 by signing in to servicer 300 or servicer 400. The mobile terminal 100 is also configured to include a service application usage unit 101, a general personal authentication system linked authentication unit 102, and an acceptance response unit 103.

[0060] For example, the mobile terminal 100 can receive a predetermined service from the servicer 300's service application 301 by signing in and authenticating with the servicer 300 via the service application usage unit 101. Next, the mobile terminal 100 can request authentication from the general personal authentication system 200 by logging into the personal data linkage management system 250 via the general personal authentication system linkage authentication unit 102. Thus, the general personal authentication system 200 can request authentication from the corresponding ID provider 210. If authentication is successful, the mobile terminal 100 can link the general personal authentication system 200 with the servicer 300 via the general personal authentication system linkage unit 302.

[0061] Furthermore, the permission response unit 103 grants or denies the permission request for linking from the servicer 300 to the permission management unit 205 of the personal data linking management system 250. The permission response unit 103 can also revoke permission after granting it.

[0062] The personal data linkage management system 250 comprises a general personal authentication system 200, a relying party link table 201 for overall management, an ID conversion table 202 showing conversions with a base ID, a permission management table 203, a user master 204 for storing base IDs, a permission management unit 205, and a communication unit 206. In this embodiment, the personal data linkage management system 250 is characterized by comprising a general personal authentication system 200, a permission management table 203, and a permission management unit 205.

[0063] Servicer 300 is comprised of a service application 301, a general personal authentication system integration unit 302, a permission request unit 303, a personal data acquisition request unit 304, a communication unit 305, a user master 306 for managing existing IDs, an ID conversion table 307 for managing base IDs unique to the company, and a service application database 308. Servicer 300 is characterized by the inclusion of a general personal authentication system integration unit 302 and an ID conversion table 307. In the ID conversion table 307, existing IDs and base IDs are linked.

[0064] Servicer 400 is comprised of a service application 401, a general personal authentication system integration unit 402, a consent confirmation unit 413, a personal data provision unit 414, a communication unit 405, a user master 406 for managing existing IDs, an ID conversion table 407 for managing base IDs unique to the company, and a service application database 408. Servicer 400 is characterized by the inclusion of a general personal authentication system integration unit 402 and an ID conversion table 407. In the ID conversion table 407, existing IDs and base IDs are linked.

[0065] Servicer 300 and Servicer 400 are each connected to the personal data linkage management system 250 via the P2P network 500.

[0066] The P2P network 500 interconnects the personal data linkage management system 250, servicer 300, and servicer 400.

[0067] In this embodiment, Servicer 400 has the same configuration as Servicer 300. Servicer 300 constitutes, for example, a personal data referencing company. On the other hand, Servicer 400 constitutes a personal data providing company. Note that the functions of Servicer 300 and Servicer 400 can be swapped. Furthermore, the personal data linkage system 600 comprises multiple Servicers 300 and Servicer 400, and the general personal authentication system 200 cooperates with each of the multiple Servicers 300 and Servicer 400, so that each of the multiple Servicers 300 and Servicer 400 can link personal data with each other.

[0068] <Consent-based data linkage process for personal data linkage systems> The permission-based data linkage process of the personal data linkage system 600, which has the configurations shown in Figures 1 and 2, will be explained using Figure 3.

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

[0070] The personal data linkage system 600 consists of the account registration process of the general personal authentication system 200 in step S11, the linkage process of the general personal authentication system 200 at each servicer 300 and 400 in step S21, the authorization request and authorization acquisition process from servicer 300 in step S31, and the personal data linkage process in step S41.

[0071] In step S11 of Figure 3, "Account registration process for the general personal authentication system 200," user 700 operates the mobile terminal 100 (step S13) and registers an account with the general personal authentication system 200 of the personal data linkage management system 250 by generating a base ID (step S15).

[0072] In step S21 of Figure 3, "Integration process of the general personal authentication system 200 at each servicer 300, 400," user 700 operates the mobile terminal 100 to log in to servicer 300 (step S23), and by pressing an integration button (not shown) to integrate with the general personal authentication system 200, servicer 300 can integrate with the general personal authentication system 200 (step S25).

[0073] Similarly, in step S21, in the case of servicer 400, user 700 operates the mobile terminal 100 to log in to servicer 400 (step S27), and by pressing an unillustrated linking button that links with the general personal authentication system 200, servicer 400 can link with the general personal authentication system 200 (step S29).

[0074] The process of disconnecting from the general personal authentication system 200 will be described later using Figure 6.

[0075] In step S31 of Figure 3, "Permission request and permission acquisition process from servicer 300," the appropriate process of servicer 300 requests permission from the personal data linkage management system 250 (step S33), and the user grants permission by operating the permission screen on the mobile terminal 100 (step S35).

[0076] The process of revoking the acquired linkage permission will be described later using Figure 8.

[0077] In step S41 of Figure 3, "Personal Data Linkage Processing," Servicer 300 requests Servicer 400 to acquire personal data (step S43). If the linkage between Servicer 300 and Servicer 400 is authorized, Servicer 400 provides personal data to Servicer 300 (step S45). Servicer 300 uses Servicer 400's personal data to provide Servicer 300's predetermined services to the user 700 using the mobile terminal 100 (step S47).

[0078] Next, steps S11, S21, S31, and S41 shown in Figure 3 will be explained in more detail using Figures 4 to 9.

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

[0080] Figure 4 is a diagram illustrating the account registration process for a user 700 using a mobile terminal 100 in the personal data linkage system 600. Note that the configuration of the personal data linkage system 600 is basically the same as that in Figure 2, and therefore explanations will be omitted as appropriate. Furthermore, the mobile terminal 100 is an optional component, and supplementary information will be provided as appropriate to clarify the embodiment in the description of the invention.

[0081] The account creation unit 104 of the mobile terminal 100 shown in Figure 4 is realized by the CPU of the mobile terminal 100 executing an application program provided by, for example, a local government. The account creation unit 104 of the mobile terminal 100 displays, for example, the web application screen of the general personal authentication system 200 on the display unit (step S111).

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

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

[0084] <Step S21 in Figure 3> The "cooperation processing of the general personal authentication system 200 at each servicer 300 and 400" in step S21 of Figure 3 will be explained with reference to the configuration diagram of the personal data linkage system 600 in Figure 5.

[0085] Figure 5 is a diagram illustrating the integration process between the servicer 300 and the general personal authentication system 200 in the personal data linkage system 600. The same configuration applies when the servicer 400 and the general personal authentication system 200 perform the integration process.

[0086] As shown in Figure 5, user 700 logs in to servicer 300 using service application usage unit 101 of mobile terminal 100, and then presses a link button (not shown) to link with the general personal authentication system 200 (step S211). As a result, the general personal authentication system link unit 302 sends a link request to the general personal authentication system 200 via service application 301, and the display screen of mobile terminal 100 is redirected to the link screen of the general personal authentication system 200 (step S213). The general personal authentication system 200 then performs user authentication with the corresponding ID provider 210 (step S215). In this case, the general personal authentication system 200 accepts authentication information input from the general personal authentication system link authentication unit 102 of 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 integration unit 302, via the service application 301, registers the integration of the servicer 300 in the relying party link table 201 using an integration API (Application Programming Interface) that integrates with the general personal authentication system 200 (step S217). The general personal authentication system integration unit 302 also writes the necessary information to the ID conversion table 307 and displays the integration status 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 IDs.

[0088] Figure 6 is a diagram illustrating the disconnection of the link between the servicer 300 and the general personal authentication system 200 in the personal data linkage system 600. The same procedure applies when the servicer 400 and the general personal authentication system 200 disconnect.

[0089] As shown in Figure 6, on the application screen displayed by the service application user unit 101 of the mobile terminal 100, the user 700 taps a release button (not shown) to disconnect from the general personal authentication system 200 (step S231).

[0090] As a result, the service application user unit 101 of the mobile terminal 100 receives a tap of a release button (not shown) within the service application 301 of the servicer 300 to release the link with the general personal authentication system 200. Here, when the general personal authentication system linkage 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 user unit 101 should confirm with the user in advance that they will no longer be able to receive the benefits of various data linkages.

[0091] Then, the general personal authentication system integration unit 302 sends a request to disconnect the link to the relying party link table 201 via the service application 301 using the integration API that integrates with the general personal authentication system 200 (step S233).

[0092] Furthermore, the General Personal Authentication System Integration Unit 302 also deletes all target records in the ID conversion table 307 of the Servicer 300 (step 235).

[0093] <Step S31 in Figure 3> Step S31 in Figure 3, "Permission request and permission acquisition process from servicer 300," will be explained with reference to the configuration diagram of the personal data linkage system 600 in Figure 7.

[0094] Figure 7 is a diagram illustrating the process of obtaining permission from servicer 300 in the personal data linkage system 600. The process for obtaining permission from servicer 400 is the same as in Figure 7. Furthermore, this explanation assumes that the mobile terminal 100 used by user 700 is logged into the personal data linkage management system 250.

[0095] As shown in Figure 7, the service application 301 of servicer 300 appeals to the user 700 of the mobile terminal 100 about the purpose of use of personal data belonging to another company and the benefits of using that personal data, and encourages consent (step S311). In this case, the target of the other company is, for example, the service application 401 of 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). Here, once the permission management unit 205 has registered the permission request data in the permission management table 203, the permission request unit 303 transitions the screen of the mobile terminal 100 to the permission acquisition screen of the general personal authentication system 200.

[0097] As a result, the authorization request unit 303, for example, requests authorization for the cooperation of servicer 400 in response to a data acquisition request from servicer 300 to service application 401 of servicer 400.

[0098] User 700 operates the authorization response unit 103 of the mobile terminal 100, and the authorization management unit 205 obtains authorization for linkage on the authorization acquisition screen of the general personal authentication system 200 (step S315). In this case, the authorization management unit 205 changes the status of the data subject to the authorization request registered in the authorization management table 203 to authorized (step S317).

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

[0100] Figure 8 is a diagram illustrating the process for revoking permission from Servicer 300 in the personal data linkage system 600. The process for revoking permission from Servicer 400 is the same as shown in Figure 8.

[0101] As shown in Figure 8, user 700 connects to the authorization management unit 205 from the authorization response unit 103 of the mobile terminal 100. Then, user 700 displays the service screen of the general personal authentication system 200 on the display unit of the mobile terminal 100 and selects to revoke the authorization for the target relying party (step S331). For example, user 700 selects to revoke the authorization of servicer 400 to servicer 300.

[0102] In this case, the authorization response unit 103 obtains the authorization cancellation from the user 700 and transmits it to the authorization management unit 205. The authorization management unit 205 then accepts the authorization cancellation for the relevant relying party. Authorisation cancellation is, in principle, performed on the service screen displayed by the general personal authentication system 200.

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

[0104] <Step S41 in Figure 3> The "Personal Data Linkage Processing" in step S41 of Figure 3 will be explained with reference to the configuration diagram of the personal data linkage system 600 in Figure 9.

[0105] Figure 9 is a configuration diagram showing the data linkage process between servicer 300 and servicer 400 in the personal data linkage system 600.

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

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

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

[0109] If permission for servicer 400 to connect is granted in the permission management table 203, the personal data provision unit 414 sends the personal data of user 700 stored in the service application database 408 to service application 301 of servicer 300 (step S417). On the other hand, if permission for servicer 400 to connect is not granted in the permission management table 203, the personal data provision unit 414 returns an error to service application 301.

[0110] Furthermore, if the personal data provision unit 414 does not have permission for the servicer 400 to link up in the permission management table 203, it may return an error indicating that such permission is not granted and may also perform the linking permission request and permission acquisition process (third process) shown in Figure 7. Alternatively, the permission confirmation unit 413 may return the error indicating that such permission is not granted to the personal data acquisition request unit 304.

[0111] As a result, servicer 300 can use the personal data of user 700 stored in servicer 400's service application database 408 to provide further data services to service application utilization unit 101.

[0112] Furthermore, even if the functions of Servicer 300 and Servicer 400 are swapped, Servicer 300 can still transmit personal data concerning the desired user 700 to Servicer 400.

[0113] In this way, the personal data linkage system 600 can link the personal data of servicers 300 and 400 with each other, so it can link personal data across multiple servicers 300 and 400 (relying party apps).

[0114] As described above, the personal data linkage system 600 according to this embodiment comprises a general personal authentication system 200, general personal authentication system linkage units 302, 402, authorization management unit 205, personal data acquisition request unit 304, authorization confirmation unit 413, and personal data provision unit 414.

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

[0116] The general personal authentication system integration unit 302 receives an integration request from the service application 301, and if the general personal authentication system 200 authenticates the user using the account at the ID provider 210, it registers the integration between the servicer 300 and the base ID in the ID conversion table 307.

[0117] The general personal authentication system integration unit 402 receives an integration request from the service application 401, and if the general personal authentication system 200 authenticates the user using the account at the ID provider 210, it registers the integration between the servicer 400 and the base ID in the ID conversion table 407.

[0118] The authorization management unit 205 receives a request from servicer 300 for authorization to link with servicer 400 and registers the data of the authorization request in the authorization management table 203. Then, when the authorization management unit 205 obtains authorization for the link from the user's mobile terminal 100, it updates the data of the link authorization request to "authorized".

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

[0120] When servicer 400 receives a data acquisition request from servicer 300, the authorization confirmation unit 413 of servicer 400 checks the authorization status of servicer 400's authorization to servicer 300 in the authorization management table 203 of the personal data linkage management system 250.

[0121] The personal data provision unit 414 responds to a data acquisition request with the requested personal data if the permission management table 203 of the personal data linkage management system 250 has permission from servicer 400 to link with servicer 300.

[0122] In this embodiment, the personal data linkage system 600 works as follows: When servicer 300 requests data acquisition from servicer 400, and the permission management table 203 has permission for servicer 400 to link with servicer 300, the personal data provision unit 414 of servicer 400 transmits the personal data from the service application database 408 to the service application 301 of servicer 300.

[0123] As a result, servicer 300 can use the personal data of user 700 stored in servicer 400's service application database 408 to provide the service application utilization unit 101 with the data service application 301.

[0124] In this way, the personal data linkage system 600 can link with the personal data of servicer 400 when servicer 300 requests data acquisition from servicer 400.

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

[0126] Furthermore, the personal data linkage system 600 authorizes the linkage of many relying parties to the authorization management table 203 in the general personal authentication system 200. As a result, the user 700 only needs to authenticate with the general personal authentication system 200 once to link their personal data to use multiple services, such as a car rental service provider 300, a shopping service provider 400, a restaurant service provider 300, and a hotel service provider 400.

[0127] Furthermore, each of the general personal authentication system linkage units 302 and 402 can disconnect the linkage between the servicers 300 and 400 and the general personal authentication system 200.

[0128] Furthermore, the authorization management unit 205 of the personal data linkage management system 250 can revoke the acquired linkage authorization based on instructions from the user 700's mobile terminal 100.

[0129] Furthermore, if Servicer 400 does not have permission from Servicer 300, the permission confirmation unit 413 or the personal data provision unit 414 will respond with an error indicating that such permission is not granted. In addition, if there is no permission for cooperation from each Servicer 300 and 400, step S31 in Figure 3 may be executed to prompt each Servicer 300 and 400 to request permission and obtain permission. [Explanation of Symbols]

[0130] 100 Mobile devices (devices) 101 Service Application User Section 102 General Personal Authentication System Integration and Authentication Department 103 Permission Response Section 104 Account Creation Section 200 General Personal Authentication Systems 201 Relying Party Link Table 202 ID Conversion Table 203 Permission Management Table 204 User Master 205 Permission Management Department 206 Communications Department 210 ID providers 250 Personal Data Linking Management System 300 Servicers (First Relying Party) 400 Servicers (Second Relying Party) 301,401 Service Apps 302,402 General Personal Authentication System Integration Department 303,403 Permission Request Department 313,413 Permission Confirmation 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 Application Databases 500 P2P Network 600 Personal Data Linking System 700 users

Claims

1. A general personal authentication system that, in response to a request from a user's terminal using the first relying party via the first relying party application, registers the user's ID provider account, generates a base ID that uniquely identifies the user, and registers the base ID and the account in association; When a linkage 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, the general personal authentication system linkage unit registers the linkage between the first relying party and the base ID in the ID conversion table. A permission management unit receives a permission request from the first relying party to cooperate with the second relying party, registers the data of the permission request in the permission management table, and updates the data of the permission request to "approved" when permission for the permission request is obtained from the user's terminal. The first relying party makes a data acquisition request to the second relying party via the base ID, and When a data acquisition request is received from the first relying party, the license confirmation unit checks the license status of the second relying party to the first relying party in the license management table, If the permission management table contains permission from the second relying party to the first relying party, the data provision unit responds to the data acquisition request with the requested data, A personal data sharing system equipped with the following features.

2. The aforementioned general personal authentication system integration unit is: The link between the first relying party and the general personal authentication system is terminated. The personal data linkage system according to claim 1.

3. The aforementioned licensing management unit, The acquired license is revoked by the user's device. The personal data linkage system according to claim 1.

4. The aforementioned license confirmation unit or the aforementioned data provision unit If the second relying party does not have permission from the first relying party, an error indicating that such permission is not granted will be returned. The personal data linkage system according to claim 1.

5. The general personal authentication system, in response to a request from a terminal of a user using the first relying party via the first relying party application, registers the user's ID provider account, generates a base ID that can uniquely identify the user, and registers the base ID and the account in association. The Universal Personal Authentication System Integration Unit receives an integration request from the first relying party application, and the Universal Personal Authentication System authenticates the user at the ID provider using the account, then registers the integration between the first relying party and the base ID in the ID conversion table. The licensing management unit receives a licensing request from the first relying party for cooperation with the second relying party, registers the data of the licensing request in the licensing management table, and when it obtains permission for the licensing request from the user's terminal, updates the data of the licensing request to "licensed". The data acquisition request unit includes the step of the first relying party making a data acquisition request from the second relying party to the second relying party via the base ID, When the permission confirmation unit receives a data acquisition request from the first relying party, it confirms the permission granted by the second relying party to the first relying party in the permission management table, The data provision unit, if the permission management table contains permission from the second relying party to the first relying party, responds to the data acquisition request with the requested data, A method for linking data in a personal data linking system.

Images