Systems, methods, and information processing devices

Abstract

To reduce work for linking a plurality of services used by users.SOLUTION: A system includes a plurality of service providing servers, a plurality of data holding servers, and a server providing a platform. The platform server acquires, for a first user, a graph having an account as a node, a first linkage between accounts at different service providing servers as a first edge, and a second linkage between an account at the service providing server and an account at the data holding server as a second edge. When it is possible, in the graph, to reach a second account of the first user at a first data holding server from a first account of the first user at a first service providing server by tracing the first edge and the second edge, the platform server notifies the first service providing server of information enabling the first service providing server to acquire data corresponding to the second account from the first data holding server.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure relates to account linking among a plurality of services.

Background Art

[0002] When different service providers each provide an ID to a single user, it has been disclosed to register a plurality of the user's IDs in association with one service (for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] One aspect of the disclosure aims to provide a system, a method, and an information processing apparatus capable of reducing the work for linking accounts among a plurality of services used by an end user.

Means for Solving the Problems

[0005] One aspect of the present disclosure is a plurality of service-providing servers that provide services, a plurality of data-holding servers that hold data, obtaining a graph created for a first user, the graph having accounts as nodes, a first link set between accounts of different service-providing servers as a first edge, and a second link set between an account in a service-providing server and an account in a data-holding server as a second edge; In the graph, if it is possible to reach the first account of the first user at the first service provider server from the first account of the first user at the first data storage server by following one or more of the first edges and one of the second edges, then the first service provider server is notified of first information that enables it to obtain data corresponding to the second account from the first data storage server. A control unit that performs the following: It is a system equipped with [this feature].

[0006] Another aspect of this disclosure is Computers Obtain a graph created for the first user, where each account in multiple service delivery servers providing services and multiple data retention servers holding data are nodes, the first connection established between accounts in different service delivery servers is the first edge, and the second connection established between accounts in service delivery servers and accounts in data retention servers is the second edge. In the graph, if it is possible to reach the first account of the first user at the first service provider server from the first account of the first user at the first data storage server by following one or more of the first edges and one of the second edges, then the first service provider server is notified of first information that enables it to obtain data corresponding to the second account from the first data storage server. This is how to do it.

[0007] Another aspect of this disclosure is Obtain a graph created for the first user, where each account in multiple service delivery servers providing services and multiple data retention servers holding data are nodes, the first connection established between accounts in different service delivery servers is the first edge, and the second connection established between accounts in service delivery servers and accounts in data retention servers is the second edge. In the graph, if it is possible to reach the first account of the first user at the first service provider server from the first account of the first user at the first data storage server by following one or more of the first edges and one of the second edges, then the first service provider server is notified of first information that enables it to obtain data corresponding to the second account from the first data storage server. A control unit that executes This is an information processing device equipped with [a specific feature / feature]. [Effects of the Invention]

[0008] According to one aspect of this disclosure, it is possible to reduce the effort required to link accounts across multiple services used by end users. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 shows an example of the system configuration of the account linking system according to the first embodiment. [Figure 2] Figure 2 shows an example of the process performed in the account linking system. [Figure 3] Figure 3 shows an example of the platform's hardware configuration. [Figure 4] Figure 4 shows an example of the platform's functional configuration. [Figure 5] Figure 5 shows an example of a service account graph and data request information. [Figure 6] Figure 6 shows an example of the functional configuration of a service provider and the authorization and authentication server associated with the service provider. [Figure 7] Figure 7 shows an example of authorization information stored in the authorization information database. [Figure 8] Figure 8 shows an example of the functional configuration of a data holder. [Figure 9] Figure 9 is an example of a graph showing the status of account linkages managed by the data holder. [Figure 10] Figure 10 is an example of the functional configuration of the user terminal. [Figure 11] Figure 11 is an example of the access token information held in the access token storage unit. [Figure 12] Figure 12 is a flowchart of the login process of the user terminal to the base service. [Figure 13] Figure 13 is an example of a flowchart of the comprehensive consent request process of the user terminal. [Figure 14] Figure 14 is an example of a flowchart of the login control process in the authorization authentication server. [Figure 15A] Figure 15A is an example of a flowchart of the account linking process of the user terminal. [Figure 15B] Figure 15B is an example of a flowchart of the account linking process of the user terminal. [Figure 16] Figure 16 is an example of a flowchart of the scope registration process of the authorization authentication server. [Figure 17] Figure 17 is an example of a flowchart of the login control process of the data holder. [Figure 18] Figure 18 is an example of a flowchart of the service account graph creation process of the platform. [Figure 19] Figure 19 is an example of a flowchart of the cooperation information providing process of the service provider. [Figure 20] Figure 20 is an example of a flowchart of the data acquisition process of the service provider from the data holder. [Figure 21] Figure 21 is an example of a flowchart of the data request information notification process of the platform. [Figure 22] Figure 22 is an example of a flowchart of the data providing process of the data holder. [Figure 23] Figure 23 is a diagram showing an example of the sequence in the process of (1) login and obtaining comprehensive consent. [Figure 24]Figure 24 shows an example of the processing sequence related to setting up account linkage between a service provider and a data holder. [Figure 25] Figure 25 shows an example of the processing sequence related to setting up account linking between service providers. [Figure 26] Figure 26 shows an example of the sequence in the (3) service account graph creation process. [Figure 27] Figure 27 shows an example of a sequence in the (4) data acquisition process. [Figure 28] Figure 28 shows an example of the system configuration of the account linking system according to the second embodiment. [Figure 29] Figure 29 shows an example of the functional configuration of a service provider according to the second embodiment. [Figure 30] Figure 30 shows the block creation process of the blockchain node of the service provider according to the second embodiment. [Figure 31] Figure 31 is an example of a flowchart of the data request information notification process of the information notification unit of the service provider according to the second embodiment. [Modes for carrying out the invention]

[0010] By linking multiple services, it becomes possible to combine the data held by each service, which can create new value. For example, if multiple service providers want to use data held by multiple data holders for a single end user, the end user needs to perform the task of linking accounts between each data holder and each service provider. For example, if accounts need to be linked between m data holders and n service providers, assuming that each data holder and each service provider has one account for the end user, the end user will perform this task m × n times.

[0011] In one aspect of this disclosure, for example, even if account linking is not established between service provider A and data holder B for user X, if account linking is established between service provider A and service provider C, and between service provider C and data holder B, it is determined that service provider A can obtain user X's data from data holder B. This reduces the number of account linking operations performed by the user between multiple service providers and multiple data holders when multiple service providers use data held by multiple data holders for a given user to provide a predetermined service.

[0012] Specifically, one aspect of this disclosure is a system comprising a plurality of service-providing servers that provide services, a plurality of data-holding servers that hold data, and a control unit. The control unit acquires a graph created for a first user. In the graph, for the first user, accounts are nodes, first connections established between accounts on different service-providing servers are first edges, and second connections established between accounts on service-providing servers and accounts on data-holding servers are second edges. In the graph for the first user, if the control unit can reach the first account of the first user on the first service-providing server from the first account of the first user on the first service-providing server to the second account of the first user on the first data-holding server by following one or more first edges and one second edge, the control unit notifies the first service-providing server of first information that enables it to acquire data corresponding to the second account of the first user from the first data-holding server. The control unit is, for example, a processor such as a CPU (Central Processing Unit) and a DSP (digital signal processor), or an integrated circuit such as an FPGA (Field-Programmable Gate Array), which are provided in a predetermined device.

[0013] According to one aspect of this disclosure, in the graph, if it is possible to reach the first user's second account in the first data storage server from the first user's first account in the first service provider server, first information is notified that enables the first service provider server to obtain data corresponding to the first user's second account from the first data storage server. That is, even if the first account in the first service provider server does not have a second link established between it and the second account in the first data storage server, if the first link is established directly or indirectly between the first account in the first service provider server and an account in another service provider server that has a second link established between it and the second account in the first data storage server, the first service provider server can use the first information to obtain the first user's data in the first data storage server. As a result, when there are m data storage servers and n service provision servers, the first user only needs to perform a minimum of m account linking operations between data storage servers and service provision servers, and n-1 account linking operations between service provision servers, so that any service provision server can retrieve the first user's data from any data holder. This reduces the number of account linking operations that the first user must perform between service provision servers and between service providers and data holders. It also reduces the amount of communication data involved in setting up account linking between service provision servers and between service providers and data holders by the first user.

[0014] In one aspect of this disclosure, the control unit may notify the first service provider server of the third account of the first user at the second service provider server as first information. The third account of the first user at the second service provider server is an account that can be reached from the first account of the first user at the first service provider server by following one or more first edges in the graph for the first user, and is connected to the second account of the first user at the first data storage server by a second edge. In this case, the first service provider server may notify the first data storage server of the third account of the first user at the second service provider server and obtain data corresponding to the second account of the first user from the first data storage server.

[0015] In one aspect of this disclosure, the first service provider server is notified of the second account of the first user in the first data retention server and the third account of the first user in the second service provider server, which is configured with the second linkage. This allows the first service provider server to directly retrieve data of the first user from the first data retention server, which is not configured with the second linkage. Therefore, according to one aspect of this disclosure, the first service provider server can directly retrieve data of the first user from the first data retention server, which is not configured with the second linkage. Retrieving data from the first user to the server can be achieved with less data transmission and reception throughout the entire system.

[0016] In one aspect of this disclosure, each service provider server may maintain, for a first user's account, first linkage information relating to a first linkage between the account and other service provider servers, and second linkage information relating to a second linkage between the account and a data storage server. The control unit may obtain the first linkage information and the second linkage information from each service provider server and create a graph for the first user. The first linkage information may include, for example, the identification information of each of the two service provider servers on which the first linkage is set, and the user's account information at each of the two service provider servers. The second linkage information may include, for example, the identification information of the service provider server on which the second linkage is set, the user's account information at that service provider server, and the identification information of the data storage server on which the second linkage is set between that service provider server and the second linkage. Since both the first linkage information and the second linkage information are text data and the amount of data is small, the amount of communication required in the system to create the graph can be kept low.

[0017] In one aspect of this disclosure, the control unit may notify the first service provider server of the first information if it determines that the second service provider server holds second information indicating that blanket consent has been obtained from the first user. On the other hand, if the control unit determines that the second service provider server does not hold the second information, it may not notify the first service provider server of the first information. Blanket consent is, for example, consent to another service provider server acquiring data associated with the first user's account in a data storage server where the second linkage is set up, using the first user's third account in the second service provider server. The second linkage setup operation performed by the user can also be said to be the operation in which the user consents to the account linkage between the data storage server and the service provider server. In other words, by obtaining blanket consent in advance, it can be considered that consent has been obtained for the acquisition of the user's data between the data storage server and the service provider server, even though the user has not directly consented to the second linkage. This reduces the number of user configuration tasks required for account linking between the service provider server and the data storage server.

[0018] The determination of whether the second information is held in the second service provider server, that is, whether comprehensive consent has been obtained from the first user, may be made, for example, using an access token. As a mechanism for using an access token, a protocol that grants authorization, such as OpenID Connect Core 1.0 and OAuth 2.0, may be used. For example, a system according to one aspect of this disclosure may further include an authorization server that performs authorization and corresponds to the second service provider server. The authorization server may issue an access token associated with the second information to the first user's terminal. In this case, the first user's terminal may access the first service provider server with the access token. When the control unit receives an access token from the first service provider along with a request for notification of the first information necessary to obtain the first user's data from the first data holder, it may send a request to the authorization server corresponding to the second service provider server to verify the access token. Based on the response from the authorization server to the verification request, the control unit may determine whether the second information is held in the second service provider server. By adopting a mechanism that uses access tokens to determine whether or not comprehensive consent has been obtained from the first user, the management of comprehensive consent permissions can be made easier.

[0019] In one aspect of this disclosure, the control unit comprises a plurality of service provision servers and a plurality of data The information processing device may be located on an information processing device independent of the data holding server. In this case, the system according to one aspect of this disclosure is a centralized management system that manages graphs on the information processing device. The information processing device is, for example, a server that provides a platform.

[0020] In one aspect of this disclosure, the control unit may be provided in each of the multiple service-providing servers, or in each of the multiple information processing devices, which include multiple service-providing servers and multiple data-holding servers. When the control unit is provided in multiple devices, the system according to one aspect of this disclosure becomes a distributed management system in which the graph is managed by the multiple devices. In this case, each of the multiple devices equipped with the control unit may manage the graph using, for example, a technology such as blockchain. However, the technology used when the multiple devices equipped with the control unit manage the graph is not limited to blockchain.

[0021] Another aspect of this disclosure can be specified as a method by which devices included in the system perform the processing in the system. Another aspect of this disclosure can also be specified as an information processing device comprising a control unit in the system. Another aspect of this disclosure can also be specified as a program for causing a computer to perform the processing of the information processing device. Another aspect of this disclosure can also be specified as a computer-readable and non-temporary recording medium for the program.

[0022] Embodiments of this disclosure will be described below with reference to the drawings. The configurations of the following embodiments are illustrative, and this disclosure is not limited to the configurations of these embodiments.

[0023] <First Embodiment> Figure 1 shows an example of the system configuration of the account linking system 100 according to the first embodiment. The account linking system 100 is a system that makes data about a user held by one service available to different services by linking a user's account across multiple services. Hereinafter, linking accounts between different services will be referred to as account linking.

[0024] The account linking system 100 includes a platform 1, multiple service providers 2, multiple authorization and authentication servers 3 associated with each service provider 2, multiple data holders 4, and user terminals 5. When referring to the service providers 2, authorization and authentication servers 3, and data holders 4 individually, a hyphen and a code shall be added after the code. When not distinguishing between them, they shall simply be referred to as service providers 2, authorization and authentication servers 3, and data holders 4. Although the account linking system 100 may include multiple user terminals 5, only one is shown in Figure 1 for illustrative purposes.

[0025] Platform 1, service provider 2, authorization and authentication server 3, data holder 4, and user terminal 5 are each connected to network D1 and can communicate with each other through network D1. Network D1 is, for example, a public network such as the internet.

[0026] Service provider 2 is a server that provides a predetermined web service to the user. Authorization and authentication server 3 is a server that performs authentication and authorization processing for the web service provided by service provider 2. Data holder 4 is a server that holds information about a predetermined category of user. Data holder 4 also provides the service of holding data. Therefore, service provider 2 and data holder 4 are each From the perspective of providing a service, the service provider 2 and the authorization authentication server 3 are collectively referred to simply as the "service." Service provider 2 is an example of a "service provider server." Data holder 4 is an example of a "data holder server." Platform 1 is an example of an "information processing device" in the first embodiment.

[0027] User terminal 5 is a device owned by a user who has registered with each service provider 2 and each authorization authentication server 3. User terminal 5 can be, for example, a smartphone, a tablet, or a PC (Personal Computer).

[0028] The user performs the setup of account linking between service providers 2 and between service provider 2 and data holder 4 through user terminal 5. Account linking between service providers 2 may be referred to as "service linking" below. Account linking between service provider 2 and data holder 4 may be referred to as "data linking" below. When service linking and data linking are not distinguished, they are simply referred to as "account linking". Account linking is not set up without the user's consent, so the setup of account linking can also be said to be the process by which the user consents to the linking of accounts between different services. Service linking is an example of "first linking". Data linking is an example of "second linking".

[0029] Platform 1 is a server that manages the account linkage status in the account linkage system 100 on an account-by-account basis and provides a platform that enables data acquisition between the service provider 2 and the data holder 4 based on the account linkage status. The account linkage status refers to, for example, whether or not account linkage is set up between two different services. Hereinafter, the setting up of account linkage may simply be referred to as "account linkage available," "account linked," "linked," or "linked." The absence of account linkage may be referred to as "no account linkage," or "no linkage," etc.

[0030] In the account linking system 100 according to the first embodiment, the processes related to authentication, authorization, and obtaining consent for account linking are carried out in accordance with protocols that enable limited access to HTTP services by third parties, such as OpenID Connect 1.0 and OAuth 2.0. Therefore, the service provider 2 and data holder 4 are HTTP servers in the first embodiment. However, the service provider 2 and data holder 4 are not limited to these. In the first embodiment, the authorization authentication server 3 operates as an OpenID provider for OpenID Connect 1.0 and / or an authorization server for OAuth 2.0. However, in the first embodiment, the data holder 4 does not have functions such as an OpenID provider for OpenID Connect 1.0 or an authorization server for OAuth 2.0 implemented, and it is assumed that user authentication is performed using account information and a password. The user terminal 5 operates as a user agent in OpenID Connect 1.0 or OAuth 2.0 through an application program such as a browser. Therefore, the user terminal 5 is sometimes referred to as the user agent 5.

[0031] Based on the above premise, the accounts linked in the account linking system 100 according to the first embodiment are account IDs used in OpenID Connect 1.0 or OAuth 2.0 for each service. The account ID is an identification number for identifying a user. Note that a user may have multiple accounts for a single service. Note that the protocols used for authentication, authorization, and consent acquisition in the account linking system 100 are not limited to OpenID Connect 1.0 or OAuth 2.0. Hereinafter, A When referring to a "Count ID," it should indicate account information used in OpenID Connect 1.0 or OAuth 2.0. The Account ID is an example of account information.

[0032] Figure 2 shows an example of the processes performed in the account linking system 100. In Figure 2, the lines connecting the service providers 2 and the service provider 2 and the data holder 4 indicate that account linking is configured. The processes performed in the account linking system 100 can be broadly classified into (1) login and comprehensive consent acquisition processes, (2) account linking processes, (3) service account graph creation processes, and (4) data acquisition processes.

[0033] (1) The login and blanket consent acquisition process involves logging in to one service provider 2 and obtaining blanket consent from the user for service provider 2. In Figure 2, among the multiple service providers 2, user agent 5 logs in to service provider 2-1. Hereafter, service provider 2-1, to which the user has logged in, will be the central focus of the account linking for explanatory purposes. In the first embodiment, when login to service provider 2-1 is successful, user agent 5 displays, for example, a screen requesting blanket consent, and when the user inputs an operation to acknowledge blanket consent, blanket consent is obtained from the user. The user's operation to acknowledge blanket consent is, for example, selecting the "YES" button displayed on the screen requesting blanket consent.

[0034] In the system shown in Figure 2, blanket consent means that a service provider other than service provider 2-1 may use the user's account at service provider 2-1 to obtain the user's data from all data holders 4 that are linked to service provider 2-1's account. The process of obtaining blanket consent from the user and information indicating that blanket consent has been obtained from the user are maintained by the authorization authentication server 3-1 associated with service provider 2-1.

[0035] (2) The account linking process is the process of setting up account linking between services. The account linking process includes logging into the linked service via the source service and obtaining consent from the user regarding account linking between the source service and the linked service.

[0036] For example, in Figure 2, when setting up account linking between service provider 2-1 and data holder 4-1, user agent 5 logs in to service provider 2-1 and then logs in to data holder 4-1 for account linking. If the login is successful, user agent 5 displays a screen requesting consent for account linking between service provider 2-1 and data holder 4-1. When the user inputs an action to consent, consent for account linking between service provider 2-1 and data holder 4-1 is obtained. Once consent for account linking is obtained from the user, account linking between service provider 2-1 and data holder 4-1 is set up. Data linking information indicating that account linking has been set up between service provider 2-1 and data holder 4-1 is maintained by service provider 2-1 and authorization authentication server 3-1. The data linking information includes the identification information of service provider 2-1 and the user's account information in service provider 2-1, and the identification information of data holder 4, for which data linking has been set up.

[0037] For example, the same process is performed for account linking between service provider 2-1 and service provider 2-2. Service linking information indicating that account linking has been set up between service provider 2-1 and service provider 2-2 is recognized as being from service provider 2-1. This information is maintained by the authentication server 3-1. The service linkage information includes the identification information of service provider 2-1 and the user's account information at service provider 2-1, and the identification information of service provider 2-2 and the user's account information at service provider 2-2, for which service linkage is configured. The account linkage process is performed for each combination of two services to link accounts. The service linkage information is an example of "first linkage information". The data linkage information is an example of "second linkage information".

[0038] (3) The service account graph creation process is the process related to the creation of the service account graph. The service account graph is a graph that shows the status of account linkage between services for one user. Details of the service account graph will be described later. Platform 1 collects information on configured account linkage from each service provider 2 and creates a service account graph based on that information. Information on account linkage includes service linkage information and data linkage information. Hereinafter, the service account graph may be simply referred to as the graph.

[0039] (4) The data acquisition process is the process by which the service provider 2 acquires data of a predetermined user from the data holder 4. In the first embodiment, when the service provider 2 acquires data from the data holder 4, it is notified of data request information from the platform 1. The data request information includes the information necessary for the service provider 2 to acquire the data of the target user from the data holder 4 to whom the data is requested. The data request information is an example of the "first information".

[0040] Platform 1 generates data request information when it can trace account linkages from the target user's account in Service Provider 2, the source of the data acquisition request, to the user's account in Data Holder 4, the destination of the data acquisition request, in the service account graph for the target user. The data request information includes the target user's account in Service Provider 2, with which data linkages are set up. Data Holder 4 receives the data request information along with the data acquisition request from Service Provider 2, identifies the target user's account in Data Holder 4 according to the received data request information, and provides the target user's data to Service Provider 2.

[0041] For example, as shown in Figure 2, suppose that account linking has been established between each service provider 2 and between each service provider 2 and each data holder 4 for user A. In Figure 2, let's explain the case where service provider 2-N retrieves user A's data held by data holder 4-M as an example. Account linking for user A's account is not set up between service provider 2-N and data holder 4-M. Account linking for user A's account is set up between service provider 2-1 and data holder 4-M. Account linking for user A's account is not set up between service provider 2-1 and service provider 2-N. However, it is possible to reach user A's account in service provider 2-1 from user A's account in service provider 2-N via other service providers 2, each of which has account linking set up for user A's account. That is, it is possible to reach data holder 4-M from user A's account #N in service provider 2-N via user A's account #1 in service provider 2-1. Therefore, platform 1 generates data request information for service provider 2-N, which is the information necessary to obtain user A's data from data holder 4-M. This data request information includes user A's account #1 at the service provider 2-1 through which the data is transmitted.

[0042] Data holder 4-M receives data request information along with a data acquisition request from service provider 2-N. Data holder 4-M identifies user A's account #M, which is associated with user A's account #1 at service provider 2-1, as included in the data request information, and sends the data associated with user A's account #M to service provider 2-N.

[0043] Although account linking is not set up between service provider 2-N and data holder 4-M, user A is not required to set up or consent to such account linking. This is because user A has given blanket consent to service provider 2-1. According to the first embodiment, if it is possible to reach data holder 4 from the account in service provider 2 in the service account graph, so that service provider 2-N can retrieve user A's data held by data holder 4-M, data can be retrieved even between service provider 2 and data holder 4 where account linking is not set up. As a result, the user does not have to perform the account linking setup work such as the account linking process in (2) above between all service providers 2 and data holder 4, and the number of account linking operations between data holders 4 and between service provider 2 and data holder 4 can be reduced. For example, if there are N service providers 2 and M data holders 4, in the first embodiment, the user can reduce the number of account linking setup operations to a minimum of N+M-1. On the other hand, if the account linking setup process is performed between all service providers 2 and data holders 4, the user will have to perform the account linking setup process N x M times.

[0044] <Device Configuration> Figure 3 shows an example of the hardware configuration of Platform 1. Platform 1 comprises a CPU 101, memory 102, auxiliary storage device 103, and communication unit 104. Memory 102 and auxiliary storage device 103 are examples of computer-readable recording media.

[0045] The auxiliary storage device 103 stores various programs and data used by the CPU 101 when each program is executed. The auxiliary storage device 103 is, for example, an HDD (Hard Disk Drive) and an SSD (Solid State Drive). The programs held in the auxiliary storage device 103 include, for example, the OS (Operating System) and several other programs.

[0046] Memory 102 is a memory device that provides the CPU 101 with a memory area and a work area for loading programs stored in the auxiliary storage device 103, and is also used as a buffer. Memory 102 is, for example, ROM (Read Only Memory), RAM (Random This includes semiconductor memory such as Access Memory.

[0047] The CPU 101 performs various processes by loading the OS and various other programs stored in the auxiliary storage device 103 into memory 102 and executing them. There may be more than one 101. The CPU 101 is an example of a "control unit".

[0048] The communication unit 104 is a module that connects, for example, a LAN (Local Area Network) card and network cables such as optical modules, and includes a signal processing circuit. The communication unit 104 is not limited to a circuit that can connect to a wired network, but may also be a wireless signal processing circuit that can process wireless signals from a wireless communication network such as WiFi. Note that the hardware configuration of platform 1 is not limited to that shown in Figure 3.

[0049] The service provider 2, the authorization and authentication server 3, and the data holder 4 are equipped with a CPU, memory, auxiliary storage device, and communication unit in the same hardware configuration as platform 1.

[0050] User terminal 5 is, for example, a tablet device, a smartphone, or a PC. User terminal 5 includes a CPU, memory, auxiliary storage device, wireless communication unit, touch panel display, speaker, and microphone as its hardware configuration. For example, a predetermined browser application program is installed in the auxiliary storage device of user terminal 5, and through the execution of this browser, user terminal 5 operates as a user agent.

[0051] Figure 4 shows an example of the functional configuration of platform 1. Platform 1 comprises a graph management unit 11, an information notification unit 12, and a graph information storage unit 13 as its functional configuration. Processing by these functional components is achieved, for example, by the CPU 101 of platform 1 executing a predetermined program held in the auxiliary storage device 103.

[0052] The graph management unit 11 manages the service account graph for each user. For example, the graph management unit 11 collects service linkage information and data linkage information from each service provider 2 at predetermined intervals and stores it in the graph information storage unit 13. When service linkage information and data information are referred to collectively, they are called linkage information. The linkage information collected from each service provider 2 may be differential information or all the linkage information held by each service provider 2. If the linkage information collected from each service provider 2 is differential information, the graph management unit 11 updates the information held in the graph information storage unit 13 with the collected linkage information. If the linkage information collected from each service provider 2 is all the linkage information held by each service provider 2, the graph management unit 11 overwrites the information held in the graph information storage unit 13 with the collected linkage information.

[0053] Furthermore, the graph management unit 11 creates a service account graph based on the information stored in the graph information storage unit 13. The graph management unit 11 may, for example, create a service account graph at predetermined intervals, or it may create a service account graph for a target user in response to a request from the information notification unit 12.

[0054] The information notification unit 12 receives an information notification request from the service provider 2 requesting notification of data request information. Along with the information notification request, the information notification unit 12 also receives from the service provider 2, for example, the identification information of the service provider 2 that requested the data, the account of the target user at the service provider 2 that requested the data, and the identification information of the data holder 4 that the data is requested from.

[0055] When the information notification unit 12 receives an information notification request from the service provider 2, it determines whether it is possible to reach the data holder 4, the destination of the data request, by tracing the account linkage from the account at the service provider 2, the source of the data request, in the service account graph created based on the account at the service provider 2, the source of the data request. The service account graph is obtained by requesting it from the graph management unit 11.

[0056] In the service account graph, if it is possible to trace the data request from the service provider 2 account (the data request source) to the data holder 4 (the data request destination), the information notification unit 12 generates and notifies the service provider 2 of the data request information. The data request information includes, for example, the identification information of the requesting service provider 2 and the data holder 4 (the data request destination). This includes the identification information of person 4, the identification information of the intermediary service provider, and account information at the intermediary service provider.

[0057] In the service account graph, if the account of service provider 2, which is the data request source, cannot reach data holder 4, which is the data request destination, service provider 2 sends "Information generation impossible" as a response to the information notification request. Upon receiving "Information generation impossible," service provider 2 may, for example, send a request to user terminal 5 to configure account linkage between service provider 2 and data holder 4, thereby requesting the user to configure account linkage between service provider 2 and data holder 4.

[0058] The graph information storage unit 13 is created, for example, in the storage area of ​​the auxiliary storage device 103 of platform 1. The graph information storage unit 13 holds configuration information of the service account graph based on the cooperation information collected from each service provider 2. The data structure of the service account graph configuration information is not limited to a specific structure. Details of the information held in the graph information storage unit 13 will be described later. Note that the functional configuration of platform 1 is not limited to the functional configuration shown in Figure 4. Also, the device equipped with the graph management unit 11 and the graph information storage unit 13 may be different devices from the device equipped with the information notification unit 12.

[0059] Figure 5 shows an example of a service account graph and data request information. The service account graph shown in Figure 5 is a graph based on user A's account ID: SP1_A in service provider #1. In the service account graph shown in Figure 5, accounts are represented as nodes, and service collaboration between service providers 2 is represented as an edge connecting the nodes. In addition, in the service account graph shown in Figure 5, data holder 4, which has account collaboration set up with service provider 2, is shown as an attribute of service provider 2. In Figure 5, the data holder is shown as "DH". The service account graph is an example of a "graph".

[0060] In the example shown in Figure 5, User A has two accounts each with Service Provider #1, Service Provider #n1, and Service Provider #n2. In Figure 5, accounts with account linking configured are shown with solid lines. In Figure 5, accounts without account linking configured are shown with dashed lines. However, this is for convenience only; in reality, accounts without account linking configured are not included in the service account graph.

[0061] Here, for example, if the service account graph is formed as shown in the example in Figure 5, the graph information storage unit 13 stores the correspondence between two nodes connected by an edge and the attribute information of the node as configuration information of the service account graph. The correspondence between two nodes connected by an edge is, for example, the correspondence between the identification information of service provider #1 and the account information of service provider #1, and the identification information of service provider #n1, and the account information of service provider #n1, using service provider #1 and service provider #n1, for which service cooperation is set in Figure 5. The attribute information of the node is, for example, the correspondence between the identification information of service provider #1 and the account information of service provider #1, and the identification information of data holder #1, using service provider #1 and data holder #1, for which data cooperation is set in Figure 5.

[0062] The configuration information of the service account graph held in the graph information storage unit 13 is not limited to what is described above. For example, the graph information storage unit 13 may hold a list for each account in each service provider 2 that includes the identification information of other service providers 2 with whom account linkage is set, the account information of said other service providers 2, and the identification information of the data holder 4.

[0063] The graph management unit 11 collects collaboration information from each service provider 2, and for example, converts the collected collaboration information into a format corresponding to the data structure held in the graph information storage unit 13 to obtain service account configuration information, which is then stored in the graph information storage unit 13. The graph management unit 11 also creates a service account graph by searching for nodes connected by edges, starting from a node corresponding to one account of a predetermined service provider 2, based on the service account graph configuration information held in the graph information storage unit 13.

[0064] For example, in the example shown in Figure 5, account ID: SPn2_A in service provider #n2 can reach account ID: SP1_A in service provider #1 by traversing the edge. Account ID: SP1_A in service provider #1 has an attribute that indicates account linkage with data holder #1. Therefore, the information notification unit 12 can generate data request information for service provider #n2 to obtain data held by data holder #1 for the user of account ID: SPn2_A. The data request information generated at this time includes the identification information of service provider #n2 as the requester, the identification information of data holder #1 as the request destination, the identification information of service provider #1 as the intermediary service provider, and account ID: SP1_A in service provider #1 as the account ID in the intermediary service.

[0065] In addition to the above, in the example shown in Figure 5, the information notification unit 12 can generate the following data request information. (A) Data request information that can be generated in response to an information notification request from service provider #1 regarding account ID: SP1_A (Data Request Information #1) • Requester: Service Provider #1 • Requested by: Data holder #1 • Service provider via: Service provider #1 • Service account ID via: SP1_A (Data Request Information #2) • Requester: Service Provider #1 • Requested by: Data holder #2 • Service provider via: Service provider #n1 • Service account ID via: SPn1_AX (Data Request Information #3) • Requester: Service Provider #1 • Requested by: Data holder #3 • Service provider via: Service provider #n1 • Service account ID via: SPn1_A

[0066] (B) Data request information that can be generated in response to an information notification request from service provider #n1 regarding account IDs: SPn1_A and SPn1_AX. (Data Request Information #4) • Requester: Service Provider #n1 • Requested by: Data holder #1 • Service provider via: Service provider #1 • Service account ID via: SP1_A (Data Request Information #5) • Requester: Service Provider #n1 • Requested by: Data holder #2 • Service provider via: Service provider #n1 • Service account ID via: SPn1_AX (Data Request Information #6) • Requester: Service Provider #n1 • Requested by: Data holder #3 • Service provider via: Service provider #n1 • Service account ID via: SPn1_A

[0067] (C) Data request information that can be generated in response to an information notification request from service provider #n2 regarding account ID:SP2_A (Data request information targeting data holder #1 has already been explained above and is therefore omitted) (Data Request Information #7) • Requester: Service Provider #n2 • Requested by: Data holder #2 • Service provider via: Service provider #n1 • Service account ID via: SPn1_AX (Data Request Information #8) • Requester: Service Provider #n2 • Requested by: Data holder #3 • Service provider via: Service provider #n1 • Service account ID via: SPn1_A

[0068] On the other hand, in the example shown in Figure 5, the information notification unit 12 does not generate data requests for information notification requests from service provider #1 for account ID: SP1_B and from service provider #n2 for account ID: SPn2_C. This is because these accounts cannot be traced back to any of the data holders #1 to #3.

[0069] Note that the service account graph shown in Figure 5 is just one example, and the service account graph is not limited to this. For example, the service account graph may have the data holder itself as one node, and the accounts and account linkages at the service provider as one edge. An edge corresponding to account linkages between service providers is an example of a "first edge." An edge corresponding to account linkages between a service provider and a data holder is an example of a "second edge."

[0070] Furthermore, although the service account graph shown in Figure 5 is an undirected graph, the service account graph may also be a directed graph. If the service account graph is a directed graph, the edges are arrows that point from the node corresponding to the account at the source service provider to the node corresponding to the account at the destination service provider. Also, in the case of a directed graph, the configuration information of the service account graph held in the graph information storage unit 13 is, for example, for account linkage between two service providers, held as a list of correspondences between the identification information and account ID of the source service provider 2 and the identification information and account ID of the destination service provider 2. The direction of a directed service account graph may be ignored when generating data request information. For example, in data acquisition, a directed service account graph may be used when providing an incentive to the service provider 2 that initiated the account linkage with the intermediary service provider. Depending on how the service account graph is configured, the configuration of the service account graph configuration information held in the graph information storage unit 13 can also be changed.

[0071] Figure 6 shows an example of the functional configuration of service provider 2 and the authorization authentication server 3 associated with service provider 2. Service provider 2 has a functional configuration consisting of a control unit 21 and a linkage information It includes a report database 22. Processing of the control unit 21 and the linked information database 22 is achieved, for example, by the CPU of the service provider 2 executing a predetermined program.

[0072] The control unit 21 performs processing related to a predetermined service provided by the service provider 2. In the first embodiment, when the control unit 21 receives a request to acquire collaboration information from the platform 1, it sends the collaboration information held in the collaboration information DB 22 (described later) to the platform 1. The control unit 21 also executes the processing related to the data acquisition process described in (4) above when it receives a request to acquire data from the user terminal 5. In the data acquisition process described in (4), the control unit 21 sends an information notification request to the platform 1, and when it receives data request information from the platform 1, it sends the data request information along with a data acquisition request to the data holder 4, which is the data request destination, and acquires the data.

[0073] The linkage information DB 22 is created within the storage area of ​​the auxiliary storage device of service provider 2. Service provider 2 holds service linkage information and data linkage information for account linkages set in the account of service provider 2. The service linkage information and data linkage information are transmitted from the authorization authentication server 3 (described later) when consent for account linkage is obtained from the user, received by the control unit 21, and stored in the linkage information DB 22.

[0074] Next, the authorization authentication server 3 comprises, as a functional configuration, an authentication control unit 31, an authorization control unit 32, and an authorization information DB 33. 33 is achieved, for example, by the CPU of each authorization authentication server 3 executing a predetermined program.

[0075] The authentication control unit 31 performs authentication processing when a user logs in. The authentication control unit 31 is achieved, for example, by the CPU of the authorization authentication server 3 executing a program for the OpenID provider of OpenID Connect. When the authentication control unit 31 receives a login request from the user terminal 5, it performs user authentication according to the login information received with the request. In the first embodiment, if authentication is successful, the authentication control unit 31 issues an access token to the user terminal 5 that grants access to the corresponding service provider 2. The access token is, for example, a randomly generated string of a predetermined length. When the user terminal 5 accesses the service provider 2, it also transmits the access token.

[0076] The authorization control unit 32 grants the user permission to perform actions on service provider 2 and other service providers 2 with whom account linkage is configured. This is achieved, for example, by the CPU of the authorization authentication server 3 executing a program for the OAuth 2.0 authorization server.

[0077] For example, in the first embodiment, when the authorization control unit 32 receives consent information from the user terminal 5 indicating that consent has been obtained from the user for blanket consent or account linking with other services, the authorization control unit 32 updates the scope of authority for the user and issues an access token for the user. At this time, if new account linking is set up, the authorization control unit 32 sends linking information about the account linking to the service provider 2. The consent information indicating that blanket consent has been obtained is an example of the "second information".

[0078] Furthermore, if the authorization control unit 32 receives a verification request from another device requesting verification of the authenticity of an access token issued by the authorization control unit 32, it will, for example, refer to the authorization information DB 33 (described later) and respond with the authorization information corresponding to the access token (described later). It will be sent as a response. Details of the processing by the authorization control unit 32 will be described later.

[0079] The authorization information DB 33 is created, for example, in the storage area of ​​the auxiliary storage device of the authorization authentication server 3. The authorization information DB 33 holds authorization information for each account. Details of the information held in the authorization information DB 33 will be described later. Note that the functional configuration of the service provider 2 and the authorization authentication server 3 shown in Figure 6 is an example and is not limited to the example shown in Figure 6. Also, the service provider 2 and the authorization authentication server 3 may be configured as a single server.

[0080] Figure 7 shows an example of authorization information stored in the authorization information DB 33. The authorization information includes, for example, the account ID, access token, and scope of the service provider 2. The scope is the range of privileges granted to the user who has the account. One access token is issued for each account ID. If there is a change in the scope, the authorization control unit 32 issues a new access token, and the access token corresponding to that account ID stored in the authorization information DB 33 is overwritten with the newly issued access token.

[0081] The scope includes the identification information and account ID of another service provider 2 whose account has been linked with the user corresponding to the account ID, and the identification information of data holder #1. The scope also includes information indicating that blanket consent has been obtained from the user (in Figure 7, “Blank Consent”).

[0082] Scope changes occur upon receipt of a scope registration request from user terminal 5, as will be described in detail later. Furthermore, when the authorization control unit 32 receives a verification request from another device for an access token issued by the authorization control unit 32, it refers to the authorization information DB 33 and sends the authorization information corresponding to the access token to the device that sent the verification request. The device that sent the verification request determines the authenticity of the access token depending on whether it is included in the scope corresponding to the access token. Note that the above access token verification process is an example, and the process for verifying the access token will vary depending on the format of the access token adopted in the account linkage system 100.

[0083] Furthermore, the user terminal 5 stores the access token issued by the authorization authentication server 3. Whenever a new account linkage is set up, the authorization authentication server 3 issues an access token, and the user terminal 5 overwrites the access token it already holds for the relevant service account with the new access token. If the user terminal 5 accesses the authorization authentication server 3 and then wants to access another service provider 2 or other service provider with which it has already linked its account, it sends the access token to the device it is accessing. This allows the user terminal 5 to access the device with which it has already linked its account. Note that the information included in the authorization information is not limited to the example shown in Figure 7.

[0084] Figure 8 shows an example of the functional configuration of data holder 4. The login control unit 41 comprises the login control unit 41, data provision unit 42, account linkage information DB 43, and user information DB 44. The functions of the login control unit 41, data provision unit 42, account linkage information DB 43, and user information DB 44 are achieved, for example, by the CPU of the linkage information DB 43 executing a predetermined program.

[0085] The login control unit 41 controls logins to services provided by the data holder 4. The login control unit 41 receives login requests from the user terminal 5. Along with the login request, login information is also received. The login control unit 41 processes the received login information. The system uses login information to authenticate the user and returns a response to the user terminal 5 based on the authentication result. Login information includes, for example, account information and password.

[0086] In the account linking system 100, it is assumed that HTTP will be used for communication between each device. The login control unit 41 can determine whether a login from the user terminal 5 is a direct login to the data holder 4 or a login via the linking service for account linking based on the accessed URL. Furthermore, if the login is via the linking service for account linking, the accessed URL in the login request message from the user terminal 5 contains the identification information of the linking service and the account information. If the login request is a login via the linking service for account linking, the login control unit 41 associates the account information of the data holder 4 (linked account information) contained in the login information with the account information of the service provider 2 (linked account information) contained in the accessed URL and registers it in the account linking information DB 43.

[0087] When the data provision unit 42 receives a data acquisition request from the service provider 2, it reads the relevant data from the user information DB 44 and provides it. When data request information is received along with the data acquisition request from the service provider 2, the data provision unit 42 refers to the account linkage information DB 43 (described later) and determines whether there is an account in the data holder 4 that is associated with the account ID of the intermediary service provider included in the data request information. If there is an account in the data holder 4 that is associated with the account ID of the intermediary service provider, the service provider 2 reads the data associated with that account from the user information DB 44 and sends it to the service provider 2.

[0088] The account linkage information DB 43 and the user information DB 44 are created within the storage area of ​​the auxiliary storage device of the data holder 4. The account linkage information DB 43 holds account linkage information. The account linkage information includes, for example, the mapping between accounts in the data holder 4 and the identification information and account information of the service provider 2 that has been linked to the data holder 4. The user information DB 44 holds information about users for each account in the data holder 4. The content of the user information held in the user information DB 44 depends on the services provided by the data holder 4. Note that the functional configuration of the data holder 4 is not limited to that shown in Figure 8.

[0089] Figure 9 shows an example of the account linkage status managed by data holder 4. In Figure 9, the account linkage status managed by data holder 4, based on the account linkage information held in the account linkage information DB 43, is represented as a graph. In this graph, accounts are represented as nodes and data linkages as edges. When the data provision unit 42 receives data request information from service provider 2 along with a data acquisition request, it identifies the account in data holder 4 from the account information of service provider 2 included as an account in the transit service in the data request information. The data provision unit 42 reads the data corresponding to the identified account from user information DB 44 and sends the data to service provider 2, the source of the data request.

[0090] For example, one user may have multiple accounts at data holder #1. Furthermore, as shown in the example in Figure 9, account linkage may be set up between one of the user's service provider #1 accounts: SP1_A and multiple accounts at data holder #1: DH1_A, DH1_AX. When data request information is received that includes account ID: SP1_A at service provider #1 as an account in the transit service, the data provision unit 42 will set up account linkage at service provider #1. The Count ID: SP1_A is associated with the accounts DH1_A and DH1_AX, which are identified as such. The data provision unit 42 reads the data associated with the identified accounts DH1_A and DH1_AX from the user information DB 44 and sends it to the service provider 2 that requested the data.

[0091] Figure 10 shows an example of the functional configuration of the user terminal 5. The user terminal 5 comprises a control unit 51 and an access token storage unit 52 as its functional configuration. In the first embodiment, the functions of the control unit 51 and the access token storage unit 52 are achieved by the CPU of the user terminal 5 executing a web browser application program. The control unit 51, for example, accesses the service provider 2 according to the user's operation input on the screen displayed on the display, and outputs the screen according to instructions from the service provider 2. When the control unit 51 receives an access token from the service provider 2, it overwrites and saves it in the access token storage unit 52.

[0092] The access token storage unit 52 is created, for example, in a storage area within the memory of the user terminal 5. The access token storage unit 52 holds the access token issued by the service provider 2. Details of the information held in the access token storage unit 52 will be described later. Note that the functional configuration of the user terminal 5 shown in Figure 10 is just one example, and the mechanical configuration of the user terminal 5 is not limited to the functional configuration shown in Figure 10.

[0093] Figure 11 shows an example of access token information held in the access token storage unit 52. The access token information includes the identification information of the issuing service provider 2, the account ID at the issuing service provider 2, and the access token. When the user terminal 5 accesses the issuing service provider 2, it also transmits the corresponding access token. In addition, since one access token is issued for one account in one service, if a new access token is issued by the service provider 2, the existing one is overwritten. Note that the information held in the access token storage unit 52 is not limited to the example shown in Figure 11.

[0094] <Processing flow> The processing flow in each device will be explained by dividing it into the above-mentioned (1) login and blanket consent acquisition process, (2) account linking process, (3) service account graph creation process, and (4) data acquisition process. Figures 12 to 14 are flowcharts of the processing of user terminal 5 and authorization authentication server 3 related to (1) login and blanket consent acquisition process, respectively. Hereinafter, the service that user terminal 5 logs into first and which becomes the source of account linking will be referred to as the base service.

[0095] Figure 12 is a flowchart of the login process to the base service from user terminal 5. The process shown in Figure 12 starts, for example, when user input for accessing the base service's web page is entered on user terminal 5. The execution entity for the process shown in Figure 12 is the CPU of user terminal 5, but for convenience, it will be explained mainly in terms of functional components. The same applies to the following explanation of the flowchart of the process related to user terminal 5. In the first embodiment, the communication between user terminal 5 and service provider 2 or authorization authentication server 3 is conducted in accordance with HTTP. User terminal 5 is running a web browser application program, and basically user terminal 5 executes the following processes in accordance with the instructions contained in the HTTP message received from service provider 2 or authorization authentication server 3.

[0096] In OP101, the control unit 51 sends an access request to the base service provider 2. In OP102, the control unit 51 sends an access request to the base service provider 2. The system then receives a response to the access request. This response includes instructions to redirect to the login page.

[0097] In OP103, the control unit 51 accesses the login page of the base service and displays the login page on the display. In OP104, the control unit 51 determines whether or not a login operation has been entered. A login operation is entered into the user terminal 5, for example, by selecting the "Login" button included in the login page. If a login operation is entered (OP104: YES), the process proceeds to OP105. Until a login operation is entered (OP104: NO), the control unit 51 remains in a waiting state.

[0098] In OP105, the control unit 51 sends a login request to the base service authorization and authentication server 3. The URL for accessing the base service authorization and authentication server 3 is included, for example, in the data of the login page. Login information is also sent along with the login request. The login information includes, for example, account information and password.

[0099] In OP106, the control unit 51 determines whether or not a response indicating successful login has been received from the authorization authentication server 3. If a response indicating successful login is received (OP106: YES), the process proceeds to OP107. If a response indicating successful login is not received (OP106: NO), the process shown in Figure 12 ends. However, this is not limited to this; for example, the process may return to OP103, and the control unit 51 may display the login page again.

[0100] In OP107, the control unit 51 determines whether a blanket consent request has been received along with the response from the authorization authentication server 3. A blanket consent request is a message requesting blanket consent from the user. The blanket consent request may also include an instruction to redirect to a page displaying a message requesting blanket consent in the response from the authorization authentication server. If a blanket consent request has been received along with the response from the authorization authentication server 3 (OP107: YES), processing proceeds to OP108. In OP108, the blanket consent request processing, which is the process for obtaining blanket consent from the user, is executed. Details of the blanket consent request processing will be described later.

[0101] If a blanket consent request has not been received along with the response from the authorization authentication server 3 (OP107: NO), the process proceeds to OP109. In this case, blanket consent has already been obtained from the user, and the authorization authentication server 3 receives an access token along with a response indicating successful login. In OP109, the control unit 51 overwrites the access token received from the authorization authentication server 3 in the access token storage unit 52.

[0102] In OP110, since the login to the base service was successful, the control unit 51 displays the top page of the base service. After that, the process shown in Figure 12 is completed.

[0103] Figure 13 is an example of a flowchart for processing a blanket consent request on user terminal 5. The process shown in Figure 13 is initiated when user terminal 5 receives a blanket consent request.

[0104] In OP201, the control unit 51 displays a message on the display requesting blanket consent from the user. In OP202, the control unit 51 determines whether or not a user operation acknowledging blanket consent has been entered. User operation acknowledging blanket consent is entered into the user terminal 5, for example, by selecting the "YES" button that indicates acknowledging blanket consent, which is displayed on the screen along with the message requesting blanket consent. If (OP202:YES), the process proceeds to OP203.

[0105] If a user action is entered that rejects blanket consent or instructs the user to process it later (OP202:NO), the process shown in Figure 13 will terminate. A user action that rejects blanket consent is entered into the user terminal 5, for example, by selecting the "NO" button that appears on the screen along with a message requesting blanket consent. A user action that instructs the user to process it later is entered into the user terminal 5, for example, by selecting the "Process Later" button that appears on the screen along with a message requesting blanket consent.

[0106] In OP203, the control unit 51 sends a scope registration request to the authorization authentication server 3, requesting that the blanket consent be registered in the scope. Along with the scope registration request, OP203 also sends consent information indicating that blanket consent has been obtained to the authorization authentication server 3.

[0107] In OP204, the control unit 51 receives a response to the scope registration request and a newly issued access token from the authorization authentication server 3. In OP205, the control unit 51 overwrites the received access token in the access token storage unit 52. In OP206, the control unit 51 displays a message on the screen indicating the success of the blanket consent. After that, the process shown in Figure 13 is completed.

[0108] Figure 14 is an example of a flowchart of the login control process in the authorization authentication server 3. The process shown in Figure 14 is executed repeatedly, for example, at a predetermined interval. The entity executing the process shown in Figure 14 is the CPU of the authorization authentication server 3, but for convenience, the explanation will focus on the functional configuration. The same applies to the following explanation of the flowchart of the authorization authentication server 3.

[0109] In OP301, the authentication control unit 31 determines whether or not a login request has been received from the user terminal 5. If a login request is received (OP301: YES), the process proceeds to OP302. If no login request is received (OP301: NO), the process shown in Figure 14 ends.

[0110] In OP302, the authentication control unit 31 performs authentication using the login information received along with the login request and determines whether the login was successful. If the login is successful (OP302: YES), the process proceeds to OP303. If the login fails (OP302: NO), the process proceeds to OP304.

[0111] In OP303, the authentication control unit 31 determines whether the login request received in OP301 is a login request for account linking. The determination in OP303 is based on the content of the HTTP message received as a login request from the user terminal 5. If it is a login request for account linking (OP303: YES), processing proceeds to OP304. If it is not a login request for account linking, i.e., a login request as a base service (OP303: NO), processing proceeds to OP305.

[0112] In OP304, the authentication control unit 31 sends a response to the user terminal 5 based on the login authentication result in OP302. After that, the process shown in Figure 14 is completed.

[0113] In OP305, the authorization control unit 32 refers to the authorization information DB 33, for example, to determine whether comprehensive consent has already been obtained from the user of the relevant account. If comprehensive consent has already been obtained from the user (OP305: YES), the process proceeds to OP309. If comprehensive consent has not been obtained from the user (OP305:NO), the process proceeds to OP306.

[0114] In OP306, the authorization control unit 32 sends a blanket consent request to the user terminal 5 along with a login success response. In OP307, the authorization control unit 32 determines whether or not a scope registration request for blanket consent has been received from the user terminal 5. If a scope registration request for blanket consent has been received from the user terminal 5 (OP307: YES), the process proceeds to OP308. In OP308, a scope registration process is executed for the account corresponding to the user on the user terminal 5, which adds a new account link to the scope. Details of the scope registration process will be described later. Note that in the scope registration process executed in OP308, "blanket consent" is added to the scope of the authorization information for the relevant account. After the scope registration process is completed, the process shown in Figure 14 is completed.

[0115] If no scope registration request for blanket consent is received from user terminal 5 (OP307: NO), processing proceeds to OP309. For example, if a message indicating that blanket consent is not accepted, or a message indicating that it will be processed later, is received from user terminal 5, the determination in OP307 will be negative.

[0116] In OP309, the authorization control unit 32 issues a new access token because the login was successful. At this time, the authorization control unit 32 overwrites the authorization information for the corresponding account with the access token. In OP310, the authorization control unit 32 sends a response indicating the success of the login request and the access token to the user terminal 5. After that, the process shown in Figure 14 is completed.

[0117] Next, Figures 15A to 17 are flowcharts of the processes performed by the user terminal 5, the authorization authentication server 3, and the data holder 4, respectively, in relation to (2) account linking processing. Figures 15A and 15B are examples of flowcharts for the account linking process on the user terminal 5. The processes shown in Figures 15A and 15B are initiated, for example, after successful login to the base service and are repeatedly executed at predetermined intervals while accessing the base service.

[0118] In OP401, the control unit 51 determines whether or not a user operation for account linking has been entered. A user operation for account linking is entered, for example, by selecting a button on the screen of the user terminal 5 that instructs the user to link accounts between the base service and other service providers 2 or data holders 4. If a user operation for account linking has been entered (OP401: YES), the process proceeds to OP402. If a user operation for account linking has not been entered (OP401: NO), the process shown in Figure 15A ends.

[0119] In OP402, the control unit 51 sends an access request to the service provider 2 or data holder 4 to which the account is linked. The access information to the service provider 2 or data holder 4 to which the account is linked is included, for example, in the source data of the screen where the button instructing account linking is displayed. In OP403, the control unit 51 receives a response from the service provider 2 or data holder 4 to which the account is linked. In OP404, the control unit 51 displays the login page of the service provider 2 or data holder 4 to which the account is linked on the display, for example, according to the redirect included in the response from the service provider 2 or data holder 4 to which the account is linked.

[0120] In OP405, the control unit 51 determines whether or not a user operation for login has been entered. If a user operation for login has been entered (OP405: YES), processing proceeds to OP40 Proceed to 6. The control unit 51 remains in standby mode until user input for login is received.

[0121] In OP406, the control unit 51 sends a login request to the authorization authentication server 3 or the data holder 4 of the linked account, which corresponds to the service provider 2. Login information is also sent along with the login request. The access destination of the authorization authentication server 3, which corresponds to the service provider 2 of the linked account, is included, for example, in the source data of the login page.

[0122] In OP407, the control unit 51 determines whether it has received a response indicating successful login from the authorization authentication server 3 or the data holder 4 of the linked account, corresponding to the service provider 2. If a response indicating successful login is received (OP407: YES), the process proceeds to OP408 in Figure 15B. If the login is successful, the control unit 51 saves the session with the linked account service provider 2 or data holder 4.

[0123] If a response indicating successful login is not received (OP407:NO), the process shown in Figure 15A terminates. Cases where a response indicating successful login is not received include, for example, when a response indicating login failure is received, and when no response is received after a predetermined time has elapsed. If a response indicating successful login is not received, the process may proceed to OP404, and the user may be asked to log in again.

[0124] In OP408 of Figure 15B, the control unit 51 sends a scope registration request for account linking to the base service authorization authentication server 3. In OP409, the control unit 51 receives a response from the base service authorization authentication server 3. Along with the response, the authorization authentication server 3 also receives an account linking consent request requesting the user's consent for the new account linking. In OP410, the control unit 51 displays a message on the display requesting consent for the new account linking with the account linking destination.

[0125] In OP411, the control unit 51 determines whether a user operation has been entered to consent to a new account link with the account linking partner. A user operation to consent to a new account link with the account linking partner is entered into the user terminal 5, for example, by selecting the "YES" button that indicates consent to the new account link, which is displayed on the screen along with a message requesting consent to the new account link with the account linking partner. If a user operation to consent to a new account link is entered (OP411: YES), the process proceeds to OP412.

[0126] If a user action indicating that they do not consent to new account linking is entered (OP411:NO), the process shown in Figure 15B terminates. A user action indicating that they do not consent to new account linking is entered into the user terminal 5, for example, by selecting the "NO" button that is displayed on the screen along with a message requesting consent to new account linking.

[0127] In OP412, the control unit 51 sends a scope registration request and consent information indicating that consent has been obtained for the new account linking with the account linking partner to the base service authorization authentication server 3. If the new account linking partner is service provider 2, the identification information and account information of service provider 2 are also sent to the base service authorization authentication server 3. If the new account linking partner is data holder 4, the identification information of data holder 4 is also sent to the base service authorization authentication server 3.

[0128] In OP413, the control unit 51 receives a response from the base service authorization authentication server 3 indicating the success of the scope registration request and a newly issued access token. In OP414, the control unit 51 overwrites the received access token in the access token storage unit 52. In OP415, the control unit 51 displays a message on the screen indicating the success of account linking with the new account destination. After that, the process shown in Figure 15B is completed.

[0129] Figure 16 is an example of a flowchart for the scope registration process of the authorization authentication server 3. The process shown in Figure 16 is executed repeatedly at predetermined intervals.

[0130] In OP501, the authorization control unit 32 determines whether or not a scope registration request has been received from the user terminal 5. If a scope registration request has been received (OP501:YES), the process proceeds to OP502. If a scope registration request has not been received (OP501:NO), the process shown in Figure 16 ends.

[0131] In OP502, the authorization control unit 32 determines whether the scope registration request is a request for blanket consent. The nature of the scope registration request may be determined, for example, based on a code or flag included in the scope registration request message. Alternatively, it may be determined based on whether consent information indicating approval of blanket consent or consent information indicating consent to account linking is received along with the request.

[0132] If the scope registration request is a request for blanket consent (OP502: YES), processing proceeds to OP503. If the scope registration request is not a request for blanket consent (OP502: NO), processing proceeds to OP506.

[0133] OP503 to OP505 handle cases where the scope registration request is a request for blanket consent. In OP503, the authorization control unit 32 records "blanket consent" in the scope of the authorization information for the target account. The target account can be identified because a session has been established between the authorization authentication server 3 and the user terminal 5.

[0134] In OP504, the authorization control unit 32 issues a new access token for the target account. The authorization control unit 32 overwrites and updates the access token included in the authorization information of the target account with the issued access token. In OP505, the authorization control unit 32 sends a registration success response and the newly issued access token to the user terminal 5. After that, the process shown in Figure 16 is completed.

[0135] In OP506, the authorization control unit 32 determines whether the scope registration request is a request for account linking. If the scope registration request is a request for account linking (OP506:YES), the process proceeds to OP507. If the scope registration request is not a request for account linking (OP506:NO), the corresponding process is executed, and the process shown in Figure 16 ends.

[0136] The processing from OP507 to OP510 is for cases where the scope registration request is a request for account linking. In OP507, the authorization control unit 32 sends a response and an account linking consent request to the user terminal 5, requesting the user's consent for new account linking.

[0137] In OP508, the authorization control unit 32 receives a scope registration request again from the user terminal 5. At the same time, it is determined whether consent information indicating that consent has been obtained for the new account linking with the linked account has been received. If the scope registration request and the consent information are received from the user terminal 5 (OP508:YES), the process proceeds to OP509. For example, if the scope registration request and the consent information are not received from the user terminal 5 even after a predetermined time has elapsed (OP508:NO), the process shown in Figure 16 ends.

[0138] In OP509, the authorization control unit 32 records information about the linked party for which a new account link has been set in the scope of the authorization information of the target account. If the new account linked party is service provider 2, the identification information and account information of service provider 2, the new account linked party, are recorded in the scope. If the new account linked party is data holder 4, the identification information of data holder 4 is recorded in the scope.

[0139] In OP510, the authorization control unit 32 notifies the corresponding service provider 2 of the linking information regarding the new account linking. In service provider 2, the control unit 21 registers the received linking information in 22. The process then proceeds to OP504, where an access token is issued, and in OP505, the response and access token are sent to the user terminal 5, completing the process shown in Figure 16.

[0140] Figure 17 is an example of a flowchart for the login control process of data holder 4. The process shown in Figure 17 is executed repeatedly, for example, at a predetermined interval. The entity executing the process shown in Figure 17 is the CPU of data holder 4, but for convenience, the functional components will be described as the main components. The same applies to the flowchart of the data holder 4 process described below.

[0141] In OP601, the login control unit 41 determines whether or not a login request has been received from the user terminal 5. If a login request is received from the user terminal 5 (OP601: YES), the process proceeds to OP602. If a login request is not received from the user terminal 5 (OP601: NO), the process shown in Figure 17 ends.

[0142] In OP602, the login control unit 41 performs authentication using the login information received along with the login request and determines whether the login was successful. If the login is successful (OP602:YES), the process proceeds to OP603. If the login fails (OP602:NO), for example, a login failure response is sent to the user terminal 5, and the process shown in Figure 17 ends.

[0143] In OP603, the login control unit 41 determines whether the login request received in OP601 is a login request for account linking. The determination in OP603 is based on the content of the HTTP message received as a login request from the user terminal 5. If it is a login request for account linking (OP603: YES), processing proceeds to OP604. If it is not a login request for account linking, i.e., a normal login request (OP603: NO), processing proceeds to OP605.

[0144] In OP604, the login control unit 41 adds account linkage information to the account linkage information DB 43, including the mapping between the account information of the data holder 4 and the base service identification information and account information contained in the HTTP message received as a login request. In OP605, the login control unit 41 sends a response to the user terminal 5 indicating successful login. After that, the process shown in Figure 17 is completed.

[0145] Next, Figures 18 and 19 are examples of flowcharts showing the processing of Platform 1 and Service Provider 2 related to (3) the service account graph creation process, respectively. Figure 8 is an example of a flowchart for the service account graph creation process of platform 1. The process shown in Figure 18 is executed repeatedly at predetermined intervals. The interval of the process shown in Figure 18 can be arbitrarily set by the administrator of the account linkage system 100, for example, in seconds, minutes, hours, and days. The CPU 101 is the main execution entity for the process shown in Figure 18, but for convenience, the functional components will be described as the main components.

[0146] In OP701, the graph management unit 11 sends a request to each service provider 2 to obtain collaboration information. In OP702, the graph management unit 11 determines whether or not it has received collaboration information from all service providers 2. If collaboration information has been received from all service providers 2 (OP702: YES), the process proceeds to OP703. The graph management unit 11 remains in a waiting state until collaboration information has been received from all service providers 2.

[0147] In OP703, the configuration information of the service account graph held in the graph information storage unit 13 is updated based on the coordination information received from each service provider 2. After that, the process shown in Figure 18 is completed. Note that the graph management unit 11 may update the configuration information of the service account graph each time coordination information is received from each service provider 2, without waiting for coordination information to be received from all service providers 2 in OP702.

[0148] Figure 19 is an example of a flowchart for the information provision process of service provider 2. The process shown in Figure 19 is executed repeatedly at predetermined intervals.

[0149] In OP801, the control unit 21 determines whether or not it has received a request to acquire cooperation information from platform 1. If a request to acquire cooperation information is received from platform 1 (OP801: YES), the process proceeds to OP802. If a request to acquire cooperation information is not received from platform 1 (OP801: NO), the process shown in Figure 19 ends.

[0150] In OP802, the control unit 21 reads the linkage information from the linkage information DB 22 and sends it to platform 1. The linkage information sent to platform 1 in OP802 may be differential information or all of the linkage information. After that, the process shown in Figure 19 is completed.

[0151] Next, Figures 20 to 22 are examples of flowcharts for the processing of each device involved in (4) data acquisition processing. Figure 20 is an example of a flowchart for the data acquisition process from data holder 4 by service provider 2. The processing shown in Figure 20 is executed at predetermined intervals.

[0152] In OP901, the control unit 21 determines whether or not a data acquisition request has been received from the user terminal 5. Along with the data acquisition request, the user terminal 5 also receives information about the data destination and an access token. If a data acquisition request is received from the user terminal 5 (OP901: YES), the process proceeds to OP902. If a data acquisition request is not received from the user terminal 5 (OP901: NO), the process shown in Figure 20 ends.

[0153] In OP902, the control unit 21 sends a verification request along with the access token to the authorization authentication server 3, which is the issuer of the access token. Information about the issuer of the access token is received, for example, along with the access token.

[0154] In OP903, the control unit 21 receives a response to the verification request from the authorization authentication server 3, which is the issuer of the access token, and determines whether the access token is valid or not based on the response. For example, the response to the verification request may be When authorization information corresponding to the access token is received, the control unit 21 determines that the access token is valid because the scope within the authorization information includes the service provider 2's own identification information. If the access token is valid (OP903:YES), the process proceeds to OP904. If the access token is not valid (OP903:NO), the process shown in Figure 20 ends. At this time, the control unit 21 may send an error message to the user terminal 5.

[0155] In OP904, the control unit 21 sends an information notification request to platform 1. Along with the information notification request, the following are also sent: the identification information of the service provider 2 which is the requesting party, the account information of the service provider 2, the identification information of the data holder 4 which is the recipient of the data request, and an access token.

[0156] In OP905, the control unit 21 determines whether or not data request information has been received from platform 1. If data request information has been received from platform 1 (OP905: YES), processing proceeds to OP906. In OP906, the control unit 21 sends a data acquisition request and data request information to data holder 4, the data request destination. In OP907, the control unit 21 determines whether or not data has been received from data holder 4, the data request destination. If data has been received from data holder 4, the data request destination (OP907: YES), the processing shown in Figure 20 is completed. The control unit 21 performs predetermined processing on the acquired data. The control unit 21 remains in a waiting state until data is received from data holder 4, the data request destination. For example, if data is not received from data holder 4 after a predetermined time has elapsed, the control unit 21 may return an error to the user terminal 5.

[0157] In OP905, if data request information is not received from platform 1 (OP905:NO), processing proceeds to OP908. Reasons for not receiving data request information from platform 1 include, for example, the lack of comprehensive consent from the user in question, and the inability to reach data holder 4 (the recipient of the data request) by tracing account linkage from the service provider 2's account. If data request information is not received from platform 1, a response containing information indicating the reason is received from platform 1.

[0158] In OP908, platform 1 sends a message to user terminal 5 requesting blanket consent for the base service, or a message requesting account linking between the data holder and the service provider 2 or the base service, based on the reason why data request information is not generated. Subsequently, the process shown in Figure 20 is completed.

[0159] Figure 21 is an example of a flowchart for the data request information notification process of Platform 1. The process shown in Figure 21 is executed repeatedly, for example, at a predetermined interval.

[0160] In OP1001, the information notification unit 12 determines whether or not it has received an information notification request from the service provider 2. Along with the information notification request, it also receives the access token, the identification information of the data holder 4 (the recipient of the data request), the identification information of the service provider 2 (the source of the data request), and the account information of the service provider 2 (the source of the data request). If an information notification request is received (OP1001:YES), the process proceeds to OP1002. If an information notification request is not received (OP1001:NO), the process shown in Figure 21 ends.

[0161] In OP1002, the information notification unit 12 is the authorization that issued the received access token. The Information Notification Unit 12 sends a verification request to the Authentication Server 3 regarding the received access token and determines whether the access token is legitimate based on the response. For example, if authorization information corresponding to the access token is received as a response to the verification request, the Information Notification Unit 12 determines that the access token is legitimate because the scope of the authorization information includes "blanket consent". If the scope of the authorization information does not include "blanket consent", the Information Notification Unit 12 determines that the access token is not legitimate. If the access token is legitimate (OP1002: YES), the process proceeds to OP1004.

[0162] If the access token is not valid (OP1002:NO), the process proceeds to OP1003. In OP1003, the information notification unit 12 sends a response to the service provider 2 indicating that the access token is invalid. After that, the process shown in Figure 21 is completed.

[0163] In OP1004, the information notification unit 12 determines, by referring to the graph information storage unit 13, whether or not a node exists that corresponds to the account of the service provider 2, which is the source of the data request. If a node does not exist that corresponds to the account of the data requester, it indicates that no account linkage has been set up with any other services for that account. If a node exists that corresponds to the account of the data requester (OP1004: YES), the process proceeds to OP1005.

[0164] If there is no node corresponding to the account requesting the data (OP1004:NO), the process proceeds to OP1009. In OP1009, the information notification unit 12 sends a response to the service provider 2 indicating that it is not possible to generate data request information. After that, the process shown in Figure 21 ends.

[0165] In OP1005, the information notification unit 12 refers to a service account graph based on the account information of the service provider 2, which is the data requester, and determines whether an account linkage is set up between the service provider 2, which is the data requester, and the data holder 4, which is the data recipient. If an account linkage is set up between the service provider 2, which is the data requester, and the data holder 4, which is the data recipient (OP1005:YES), the process proceeds to OP1007. If an account linkage is not set up between the service provider 2, which is the data requester, and the data holder 4, which is the data recipient (OP1005:NO), the process proceeds to OP1006.

[0166] In OP1006, the information notification unit 12 refers to the service account graph and determines whether it is possible to reach the data holder 4, the data destination, from the account information of the service provider 2, the data request source. If it is possible to reach the data holder 4, the data destination, from the account information of the service provider 2 (OP1006: YES), the process proceeds to OP1007. In OP1007, the information notification unit 12 generates data request information for the service provider 2. In OP1008, the information notification unit 12 sends the data request information to the service provider 2. After that, the process shown in Figure 21 is completed.

[0167] If the account information of service provider 2, the source of the data request, cannot be traced back to data holder 4, the destination of the data request (OP1006: NO), the process proceeds to OP1009. In OP1009, the information notification unit 12 sends a response to service provider 2 indicating that it is not possible to generate data request information. After that, the process shown in Figure 21 ends.

[0168] Figure 22 is an example of a flowchart of the data provision process for data holder 4. The process shown in Figure 22 is executed repeatedly, for example, at a predetermined interval.

[0169] In OP1101, the data provision unit 42 determines whether or not it has received a data acquisition request and data request information from the service provider 2. If the data acquisition request and data request information have been received (OP1101: YES), the process proceeds to OP1102. If the data acquisition request and data request information have not been received (OP1101: NO), the process shown in Figure 22 ends.

[0170] In OP1102, the data provision unit 42 refers to the account linkage information DB 43 to identify the account in data holder 4 that is associated with the account in service provider 2, which is the intermediary service provider included in the received data request information. In OP1103, the data provision unit 42 reads the data associated with the identified account from the user information DB 44. In OP1104, the data provision unit 42 sends the read data to the requesting service provider 2. After that, the process shown in Figure 22 is completed.

[0171] Note that the processes shown in Figures 15A to 22 can all be modified as appropriate depending on the implementation method. For example, in Figure 20, when service provider 2 receives a data acquisition request from user terminal 5, it sends an information notification request to platform 1. However, if data linkage is set up between data holder 4, which is the data request destination, and service provider 2, service provider 2 may not send an information notification request to platform 1, but instead directly send a data acquisition request and the user's account information from service provider 2 to data holder 4, and acquire the data from data holder 4.

[0172] Next, the processing sequence in the account linking system 100 will be explained with reference to Figures 23 to 27. In Figures 23 to 27, the user agent is denoted as "UA". The service provider is denoted as "SP App". The authorization authentication server is denoted as "SP Auth". The data holder is denoted as "DH". The platform is denoted as "PF".

[0173] Figure 23 shows an example sequence of the process of (1) login and obtaining comprehensive consent. In Figure 23, among the devices included in the account linking system 100, the devices involved in the process of (1) login and obtaining comprehensive consent are shown to be the user terminal 5, service provider 2-1, and authorization authentication server 3-1. In Figure 23, the user terminal 5 logs in to the service of service provider 2-1 as the base service. Note that in the initial state of Figure 23, it is assumed that the user of user terminal 5 has not set up account linking between any services.

[0174] In S11, user terminal 5 receives input from a user, for example, to access the web page of service provider 2-1's service, and sends an access request to service provider 2-1 (OP101 in Figure 12). In S12, service provider 2-1 receives the access request from user terminal 5 and sends a response that includes a redirect to the login web page. In S13, user terminal 5 receives the response (OP102 in Figure 12) and displays the login page (OP103 in Figure 12).

[0175] In S14, user terminal 5 receives login input from the user (OP104:YES in Figure 12) and sends a login request to authorization authentication server 3-1 (OP105 in Figure 12). Login information is also sent to authorization authentication server 3-1 along with the login request. In S15, authorization authentication server 3-1 receives the login request from user terminal 5. The data is received (OP301 in Figure 14: YES), and authentication is performed. This allows the user on user terminal 5 to successfully log in to the base service (OP302 in Figure 14: YES). In Figure 23, this login is a normal login (OP303 in Figure 14: NO), and blanket consent has not been obtained for the account on user terminal 5 (OP305 in Figure 14: NO). Therefore, in S16, the authorization authentication server 3-1 sends a blanket consent request to user terminal 5 along with a response indicating successful login (OP306 in Figure 14).

[0176] In S21, user terminal 5 receives a response from authorization authentication server 3-1 indicating successful login and a blanket consent request (OP106:YES, OP107:YES in Figure 12), and displays a message on the display requesting blanket consent from the user (OP201 in Figure 13). In S22, user terminal 5 receives user input acknowledging blanket consent (OP202:YES in Figure 13). In S23, user terminal 5 sends a scope registration request for blanket consent to authorization authentication server 3-1 (OP203 in Figure 12). Along with the scope registration request, consent information indicating that blanket consent has been obtained is also sent to authorization authentication server 3-1.

[0177] In S24, the authorization authentication server 3-1 receives a scope registration request for blanket consent from the user terminal 5 (OP307:YES in Figure 14, OP501:YES and OP502:YES in Figure 16), and records "blanket consent" in the scope of the authorization information corresponding to the user account on the user terminal 5 (OP503 in Figure 16). In S25, the authorization authentication server 3-1 issues an access token for the user account on the user terminal 5 (OP504 in Figure 16), and sends a registration success response and the access token to the user terminal 5 (OP505 in Figure 16).

[0178] In S26, user terminal 5 receives a response and access token from authorization authentication server 3-1 (OP204 in Figure 13) and saves the access token (OP205 in Figure 13). In S27, user terminal 5 displays a message on the screen indicating the success of blanket consent (OP206 in Figure 13).

[0179] Figures 24 and 25 are diagrams illustrating examples of the account linking process, respectively. Figure 24 is an example of the process sequence for setting up account linking between service provider 2-1 and data holder 4-m. Figure 24 shows the user terminal 5, service provider 2-1, authorization authentication server 3-1, and data holder 4-m involved in setting up account linking between service provider 2-1 and data holder 4-m.

[0180] In S31, user terminal 5 receives user input indicating an instruction to link accounts with data holder 4-m (OP401:YES in Figure 15A). In S32, user terminal 5 sends an access request to data holder 4-m (OP402 in Figure 15A). In S33, data holder 4-m receives the access request from user terminal 5 and sends a response to user terminal 5 that includes a redirect to the login page.

[0181] In S34, user terminal 5 receives a response from data holder 4-m (OP403 in Figure 15A) and displays the login page for data holder 4-m (OP404 in Figure 15A). In S35, user terminal 5 receives login input from the user (OP405: YES in Figure 15A) and sends a login request to data holder 4-m (OP406 in Figure 15A). Login information is also sent to data holder 4-m along with the login request.

[0182] In S36, data holder 4-m receives a login request from user terminal 5 (OP601:YES in Figure 17) and performs authentication. This allows the user data on user terminal 5 to be authenticated. Login to data holder 4-m is successful (OP602 in Figure 17: YES). Since data holder 4-m is logging in for account linking (OP603 in Figure 17: YES), a mapping is added to the account linking information DB 43 between the user's account in data holder 4-m (in the figure, "DHm_A") and the user's account in service provider 2-1 (in the figure, "SP1_A") (OP604 in Figure 17). In S37, data holder 4-m sends a response to user terminal 5 indicating successful login (OP605 in Figure 17). In S38, user terminal 5 receives a response from data holder 4-m indicating successful login and saves the session (OP407 in Figure 15A: YES).

[0183] In S41, user terminal 5 sends a scope registration request for account linking to authorization authentication server 3-1 (OP408 in Figure 15B). In S42, authorization authentication server 3-1 receives the scope registration for account linking from user terminal 5 (OP501:YES, OP502:NO, OP503:YES in Figure 16) and sends a response to user terminal 5 (OP507 in Figure 16). Along with the response, user terminal 5 also receives an account linking consent request requesting the user's consent for the new account linking.

[0184] In S43, user terminal 5 receives a response and an account linking consent request from authorization authentication server 3-1 (OP409 in Figure 15B), and displays a message requesting consent for account linking with data holder 4-m (OP410 in Figure 15B). In S44, user terminal 5 receives user input to consent to new account linking with data holder 4-m (OP411: YES in Figure 15B). In S45, user terminal 5 sends a scope registration request and consent information indicating that consent for account linking with data holder 4-m has been obtained to authorization authentication server 3-1 (Figure 15B OP412). Along with the scope registration request, the identification information of the data holder 4-m, which is the access partner, is also sent to the authorization authentication server 3-1.

[0185] In S46, the authorization authentication server 3-1 receives consent information from the user terminal 5 indicating that consent has been obtained for account linking with data holder 4-m (OP508 in Figure 16), and records the identification information of data holder 4-m in the scope of the authorization information for the user's account on the user terminal 5 (OP509 in Figure 16). In S47, the authorization authentication server 3-1 notifies the service provider 2-1 of the linking information, including the correspondence between the user's account on the user terminal 5 and the identification information of data holder 4-m at the service provider 2-1 (OP510 in Figure 16). The service provider 2-1 stores the received linking information in the linking information DB 22.

[0186] In S48, the authorization authentication server 3-1 issues an access token for the user account of user terminal 5 (OP504 in Figure 16) and sends it to user terminal 5 along with a response indicating successful registration (OP505 in Figure 16). The authorization authentication server 3-1 overwrites the access token in the authorization information of the user account of user terminal 5. In S49, user terminal 5 receives the access token from the authorization authentication server 3-1 along with a response indicating successful registration (OP413 in Figure 15B) and overwrites the access token (OP414 in Figure 15B). Account linking between service provider 2-1 and other data holders 4 is processed in the same way as the sequence shown in Figure 24.

[0187] Figure 25 shows an example of the processing sequence for setting up account linkage between service provider 2-1 and service provider 2-n. Figure 25 shows the user terminal 5, service provider 2-1, authorization authentication server 3-1, service provider 2-n, and authorization authentication server 3-n involved in setting up account linkage between service provider 2-1 and service provider 2-n. .

[0188] In S51, user terminal 5 receives user input indicating an instruction to link accounts with service provider 2-n (OP401:YES in Figure 15A). In S52, user terminal 5 sends an access request to service provider 2-n (OP402 in Figure 15A). In S53, service provider 2-n receives the access request from user terminal 5 and sends a response including the login page to user terminal 5.

[0189] In S54, user terminal 5 receives a response from service provider 2-n (OP403 in Figure 15A) and displays the login page for service provider 2-n (OP404 in Figure 15A). In S55, user terminal 5 receives login input from the user (OP405: YES in Figure 15A) and sends a login request to authorization authentication server 3-n (OP406 in Figure 15A). Login information is also sent to authorization authentication server 3-n along with the login request.

[0190] In S56, the authorization authentication server 3-n receives a login request from user terminal 5 (OP301 in Figure 14: YES) and performs authentication. This allows user terminal 5 to successfully log in to service provider 2-n (OP302 in Figure 14: YES). Since this is a login for account linking (OP303 in Figure 14: YES), service provider 2-n sends a response to user terminal 5 indicating successful login (OP304 in Figure 14). In S57, user terminal 5 receives a response from service provider 2-n indicating successful login and saves the session (OP407 in Figure 15A: YES).

[0191] In S61, user terminal 5 sends a scope registration request for account linking to authorization authentication server 3-1 (OP408 in Figure 15B). In S62, authorization authentication server 3-1 receives the scope registration for account linking from user terminal 5 (OP501:YES, OP502:NO, OP503:YES in Figure 16) and sends a response to user terminal 5 (OP507 in Figure 16). Along with the response, user terminal 5 also receives an account linking consent request requesting the user's consent for the new account linking.

[0192] In S63, user terminal 5 receives a response and an account linking consent request from authorization authentication server 3-1 (OP409 in Figure 15B) and displays a message requesting consent for account linking with service provider 2-n (OP410 in Figure 15B). In S64, user terminal 5 receives user input to consent to the new account linking with service provider 2-n (OP411: YES in Figure 15B). In S65, user terminal 5 sends a scope registration request and consent information indicating that consent for account linking with service provider 2-n has been obtained to authorization authentication server 3-1 (OP412 in Figure 15B). Along with the scope registration request, authorization authentication server 3-1 also sends identification information of service provider 2-n, the access linking destination, and account information at service provider 2-n.

[0193] In S66, the authorization authentication server 3-1 receives consent information from the user terminal 5 indicating that consent has been obtained for account linking with service provider 2-n (OP508 in Figure 16), and records the identification information of service provider 2-n and the account information in service provider 2-n within the scope of the authorization information for the user's account on the user terminal 5 (OP509 in Figure 16). In S67, the authorization authentication server 3-1 notifies service provider 2-1 of the linking information, which includes the correspondence between the user's account on the user terminal 5, the identification information of service provider 2-n, and the user's account in service provider 2-n (OP510 in Figure 16). Service provider 2-1 then links the received linking information. Stored in the mobile information database 22.

[0194] In S68, the authorization authentication server 3-1 issues an access token for the user account of user terminal 5 (OP504 in Figure 16) and sends it to user terminal 5 along with a response indicating successful registration (OP505 in Figure 16). The authorization authentication server 3-1 overwrites the access token in the authorization information of the user account of user terminal 5. In S69, user terminal 5 receives the access token from the authorization authentication server 3-1 along with a response indicating successful registration (OP413 in Figure 15B) and overwrites the access token (OP414 in Figure 15B). Account linking between service provider 2-1 and other service providers 2 is processed in the same way as the sequence shown in Figure 25.

[0195] Figure 26 is a diagram showing an example of the sequence in the (3) service account graph creation process. In Figure 26, among the devices included in the account linkage system 100, the devices related to the (3) service account graph creation process are shown as service provider 2-1, authorization authentication server 3-1, service provider 2-n, authorization authentication server 3-n, and platform 1.

[0196] In S71, Platform 1 sends a request to each service provider 2 to retrieve integration information (OP701 in Figure 18). In S72, each service provider 2 receives a request to retrieve integration information from Platform 1 (OP801 in Figure 19: YES) and sends the integration information it holds to Platform 1 (OP802 in Figure 19). In S73, Platform 1 receives integration information from each service provider 2 (OP702 in Figure 18: YES) and updates the configuration information of the service account graph based on the integration information received from each service provider 2 (OP703 in Figure 18).

[0197] Figure 27 is a diagram illustrating an example of a sequence in the (4) data acquisition process. In Figure 27, among the devices included in the account linking system 100, the devices related to the (4) data acquisition process are shown to be user terminal 5, service provider 2-1, authorization authentication server 3-1, service provider 2-n, authorization authentication server 3-n, data holder 4-1, and platform 1. Figure 27 explains the process using the example of service provider 2-n acquiring data held by data holder 4-1. In Figure 27, it is assumed that user terminal 5 is logged in to service provider 2-1 as the base service. In Figure 27, it is assumed that account linkage exists between service provider 2-1 and data holder 4-1 for the user of user terminal 5. In Figure 27, it is assumed that account linkage exists between service provider 2-1 and service provider 2-n for the user of user terminal 5. In Figure 27, it is assumed that there is no account linkage between service provider 2-n and data holder 4-1 for the user of user terminal 5.

[0198] In S81, user terminal 5 receives user input, for example, an instruction from service provider 2-n to retrieve user data of user terminal 5 held by data holder 4-1. In S82, user terminal 5 sends a data retrieval request and an access token for the user account of user terminal 5 at service provider 2-n.

[0199] In S83, service provider 2-n receives a data acquisition request from user terminal 5 (OP901:YES in Figure 20), and sends a verification request to authorization authentication server 3-1, the issuer of the access token received from user terminal 5 (OP902 in Figure 20). In S84, authorization authentication server 3-1 receives the access token verification request from service provider 2-n and sends authorization information corresponding to the access token as a response. Then send it to service provider 2-n.

[0200] In S91, service provider 2-n determines that the scope of the authorization information received from authorization authentication server 3-1 includes the service provider 2-n's own identification information and that the access token is valid (OP903: YES in Figure 20). Therefore, it sends an information notification request and the user's access token from user terminal 5 to platform 1 (OP904 in Figure 20). Along with the information notification request, the service provider 2-n's identification information, account information for service provider 2-n, and the data holder 4-1's identification information are also sent.

[0201] In S92, platform 1 receives an information notification request from service provider 2-n (OP1001:YES in Figure 21) and sends a verification request to authorization authentication server 3-1, the issuer of the received access token. In S93, authorization authentication server 3-1 receives a verification request from platform 1 for the access token of the user account of user terminal 5 at service provider 2-1 and sends authorization information corresponding to that account to platform 1.

[0202] In S94, Platform 1 determines that the access token is legitimate because "blanket consent" is recorded in the scope of the authorization information received from the authorization authentication server 3-1 (OP1004: YES in Figure 21). Platform 1 determines that it can trace from the account of service provider 2-n, which is the source of the data request, to data holder 4-1, which is the destination of the data request, in the service account graph starting from the account of service provider 2-n, which is the source of the data request (OP1006: YES in Figure 21).

[0203] In S95, platform 1 generates data request information (OP1007 in Figure 21). This data request information includes the identification information of service provider 2-n as the requester, the identification information of data holder 4-1 as the request destination, the identification information of service provider 2-1 as the intermediary service provider, and the account ID of the user of user terminal 5 at service provider 2-1 as the intermediary service account ID. In S96, platform 1 sends the data request information to service provider 2-n (OP1008 in Figure 21).

[0204] In S101, service provider 2-n receives data request information from platform 1 (OP905 in Figure 20: YES) and sends a data acquisition request and data request information to data holder 4-1 (OP906 in Figure 20). In S102, data holder 4-1 receives a data acquisition request and data request information from service provider 2-n (OP1201 in Figure 22: YES). Data holder 4-1 identifies the account in data holder 4-1 corresponding to the transit service account ID included in the data request information (OP1102 in Figure 22), reads the data associated with the identified account (OP1103 in Figure 22), and sends it to service provider 2-n (OP1104 in Figure 22).

[0205] In S103, service provider 2-n receives data from data holder 4-1 (OP907:YES in Figure 20) and performs a predetermined process using the data. In S104, service provider 2-n sends the result of the process as a response to user terminal 5.

[0206] <Effects of the First Embodiment> According to the first embodiment, even if there is no account linking between the service provider 2 and the data holder 4, any other service provider 2 can link with the data holder 4 and the other service provider 2. If there is an account linkage between service provider 2 and the service provider 2, service provider 2 can obtain data of users whose accounts are linked from data holder 4. This reduces the number of times users have to perform the account linkage setup operation between service providers 2 and between service provider 2 and data holder 4. Furthermore, by reducing the number of times users have to perform the account linkage setup operation between service providers 2 and between service provider 2 and data holder 4, the bandwidth used for communication in the account linkage system 100 related to account linkage setup can be reduced. In addition, the amount of storage space used by each service provider 2, authorization authentication server 3, and data holder 4 for storing information related to account linkage can be reduced.

[0207] In the first embodiment, platform 1 collects account information from each service provider 2 as linkage information for services where account linking is configured. When a service provider 2 obtains data from a data holder 4, the data request information includes the account information of the requesting service provider 2 and the account information of the intermediary service provider as an intermediary service account ID, and is exchanged between platform 1, service provider 2, and data holder 4. OpenID Connect and the like stipulate that the account ID, which is one of the account information items, is not personal information. Therefore, according to the first embodiment, accounts can be linked between different services without disclosing the user's personal information.

[0208] According to the first embodiment, service providers 2 and data holders 4 can participate in the account linking system 100 while maintaining their original account management mechanisms. This allows more service providers 2 and data holders 4 to participate in the account linking system 100 in a scale-free manner.

[0209] In the first embodiment, even if a user has multiple accounts within a single service, the system can accommodate this by having the user perform account linking work for each account.

[0210] <Second Embodiment> The account linking system 100 according to the first embodiment is a centrally managed system in which platform 1 collects linking information from each service provider 2 and manages the service account graph. Alternatively, the account linking system 100B according to the second embodiment is a distributed management system in which each service provider 2 and each data holder 4 manages the service account graph. In the second embodiment, explanations common to the first embodiment are omitted.

[0211] Figure 28 shows an example of the system configuration of the account linking system 100B according to the second embodiment. Unlike the account linking system 100 according to the first embodiment, the account linking system 100B does not include a platform 1, but includes multiple service providers 2B, an authorization authentication server 3, and multiple data holders 4. In the second embodiment, it is assumed that each service provider 2B has the functions of the platform 1 according to the first embodiment, manages the service account graph, and generates and notifies data request information. The service provider 2B manages the service account graph using, for example, a blockchain algorithm. In the second embodiment, the service provider 2B is an example of an "information processing device" equipped with a "control unit".

[0212] In the second embodiment, (1) the process of obtaining login and comprehensive consent, and (2) the account linking process are the same as in the first embodiment. In the second embodiment, (3) the service account linking process The creation process involves service provider 2B creating a block containing configuration information for the service account graph based on the account linkage information when a new account linkage is established between services, and sharing this block among the service providers 2B. In the second embodiment, in (4) data acquisition process, each service provider 2B restores the configuration information for the service account graph from the block to create a service account graph, and generates and notifies the data request information it will use based on the service account graph. The configuration of the service account graph, the method for determining whether or not data request information can be generated, the content of the data request information, and the method of using it in the second embodiment are the same as in the first embodiment.

[0213] Figure 29 shows an example of the functional configuration of service provider 2B according to the second embodiment. Service provider 2B comprises a control unit 21, a linkage information DB 22, a blockchain node 23, a block DB 24, and an information notification unit 25 as its functional configuration. The blockchain node 23 and the block DB 24 are achieved by the CPU of service provider 2 executing a program for the blockchain node. The information notification unit 25 is achieved by executing a program for the platform.

[0214] The control unit 21 and the linked information DB 22 are the same as in the first embodiment. However, in the second embodiment, the recipient to whom the control unit 21 sends an information notification request and receives the service account information is the information notification unit 25.

[0215] Blockchain node 23 creates differential information for the service account graph configuration information from differential information for the service account graph, for example, at predetermined intervals or when new collaboration information is registered in the collaboration information DB 22. Blockchain node 23 creates a block containing the differential information for the service account graph configuration information and sends it to each service provider 2B for sharing. Blockchain node 23 also stores the created block and the blocks received from other service providers 2B in block DB 24.

[0216] The block DB 24 is created in the storage area of ​​the auxiliary storage device of the service provider 2. The block DB 24 holds blocks of the blockchain that record the configuration information of the service account graph. The blockchain node 23, for example, in accordance with instructions from the information notification unit 25, arranges the blocks held in the block DB 24 in sequence number order to restore the configuration information of the service account graph and passes it to the information notification unit 25.

[0217] When an information notification request is input from the control unit 21, the information notification unit 25 creates a service account graph based on the user account of the user terminal 5 at the service provider 2B. At this time, the information notification unit 25 obtains the configuration information of the service account graph restored from the blockchain from the blockchain node 23 and creates the service account graph. Thereafter, similar to the information notification unit 12 in the first embodiment, the information notification unit 25 notifies the data request information and outputs it to the control unit 21 if it is possible to reach the data holder 4, which is the data request destination, from the user account of the user terminal 5 at the service provider 2B in the service account graph.

[0218] Figure 30 shows the block creation process of the blockchain node 23 of the service provider 2B according to the second embodiment. The process shown in Figure 30 is one of the processes executed by the service provider 2B in the (3) service account graph creation process in the second embodiment. The process shown in Figure 30 is executed, for example, at predetermined intervals or when the cooperation information held in the cooperation information DB 22 is updated.

[0219] In OP1201, blockchain node 23 retrieves collaborative information from collaborative information DB 22. The difference information is obtained. In OP1202, the blockchain node 23 obtains the difference information of the service account graph configuration information from the obtained difference information of the linkage information. In OP1203, the blockchain node 23 creates a block containing the difference information of the service account graph configuration information and stores it in the block DB 24. The method of creating the block is the same as the method of creating the blockchain. In OP1204, the blockchain node 23 sends the created block to each service provider 2B (node). After that, the process shown in Figure 30 is completed. Note that although this explanation focuses on the distributed management of the service account graph, other processes executed on the blockchain are also executed in parallel in the account linkage system 100B.

[0220] Figure 31 is an example of a flowchart of the data request information notification process of the information notification unit 25 of the service provider 2B according to the second embodiment. The process shown in Figure 31 is one of the processes executed in (4) data acquisition process in the second embodiment. The process shown in Figure 31 is executed repeatedly, for example, at a predetermined interval.

[0221] In OP1301, the information notification unit 25 determines whether or not an information notification request has been received from the control unit 21. Along with the information notification request, the information notification unit 25 also receives the identification information of the data holder 4, the data requesting party, the identification information of the service provider 2B itself, and the account information of the service provider 2B itself, the data requesting party. If an information notification request has been received (OP1301:YES), the process proceeds to OP1302. If no information notification request has been received (OP1301:NO), the process shown in Figure 31 ends.

[0222] In OP1302, the information notification unit 25 obtains the configuration information of the service account graph from the blockchain node 23. In OP1303, the information notification unit 25 obtains the service account graph based on the relevant account within the service provider 2B itself, using the configuration information of the service account graph as the starting point.

[0223] In OP1304, the information notification unit 25 refers to the service account graph based on the account in the service provider 2B, which is the data requester, and determines whether an account linkage is set up between the service provider 2B, which is the data requester, and the data holder 4, which is the data recipient. If an account linkage is set up between the service provider 2B, which is the data requester, and the data holder 4, which is the data recipient (OP1304:YES), the process proceeds to OP1306. If an account linkage is not set up between the service provider 2B, which is the data requester, and the data holder 4, which is the data recipient (OP1304:NO), the process proceeds to OP1305.

[0224] In OP1305, the information notification unit 25 refers to the service account graph and determines whether it is possible to reach the data holder 4, the data destination, from the account in the service provider 2B, which is the data requesting party. If it is possible to reach the data holder 4, the data destination, from the account in the service provider 2B, which is the data requesting party (OP1305: YES), the process proceeds to OP1306. In OP1306, the information notification unit 25 generates data request information. In OP1307, the information notification unit 25 outputs the data request information to the control unit 21. After that, the process shown in Figure 31 is completed.

[0225] If the service provider 2B, which is the data requesting party, cannot reach the data holder 4, which is the data requesting party, from its own account (OP1305: NO), the process proceeds to OP1308. In OP1308, the information notification unit 25 outputs a response to the control unit 21 indicating that it is not possible to generate data request information. After that, the process shown in Figure 31 ends. .

[0226] According to the second embodiment, even in a system where the service account graph is managed in a distributed manner across multiple devices, account linking between services can be achieved. In the second embodiment, service provider 2B participates in the blockchain that manages the service account graph, but it is also possible for devices other than service provider 2B to participate.

[0227] Furthermore, in the second embodiment, each service provider 2B is equipped with the functions of platform 1 and performs the creation of a service account graph and the notification of data request information, but is not limited to this. The creation of the service account graph and the generation and notification of data request information may be performed by different devices. For example, a service provider may manage and create the service account graph on a blockchain, and another device may obtain the service account graph from the service provider and generate data request information. In this case, if service provider 2 wants to be notified of data request information, it may solicit applications from devices that will generate the data request information. If multiple devices apply, service provider 2 selects the device with the lowest incentive or the device with the fastest response speed and sends the information notification request.

[0228] <Other variations> The embodiments described above are merely examples, and this disclosure may be modified as appropriate without departing from its essence.

[0229] In the first embodiment, when service provider 2 receives a request from platform 1 to obtain integration information, it sends the integration information to platform 1. However, service provider 2 may also send integration information about a new account integration to platform 1 when a new account integration is configured. In this case, platform 1 may update the configuration information of the service account graph each time it receives integration information from service provider 2. This allows changes in the status of account integrations to be reflected in the service account graph on platform 1 in real time.

[0230] In the first embodiment, the service provider 2 and the authorization authentication server 3 were different devices, but this is not limited to them. A single device may perform the processing for both the service provider 2 and the authorization authentication server 3.

[0231] In the first embodiment, it was assumed that the data holder 4 did not have functions such as an OpenID Connect 1.0 OpenID provider or an OAuth 2.0 authorization server implemented, but this is not limited to the first embodiment. The data holder 4 may also have functions such as an OpenID Connect 1.0 OpenID provider or an OAuth 2.0 authorization server. In that case, the data holder 4 may perform the same processing as the authorization authentication server 3 in setting up login authentication and account linking.

[0232] The account linking system 100 according to the first embodiment and the account linking system 100B according to the second embodiment can be applied to services such as those in which a service provider makes insurance proposals by acquiring data from data holders who hold information on the user's health status, data holders who hold information on financial assets, and data holders who hold information on owned vehicles, etc. Furthermore, for products manufactured by combining multiple parts produced by multiple companies, data can be collected from multiple data holders who hold information on the parts held by the manufacturers of each part, allowing the service provider to perform traceability of the product. This is applicable to services that acquire information about T.

[0233] The processes and methods described in this disclosure can be freely combined and implemented, provided that no technical inconsistencies arise.

[0234] Furthermore, a process described as being performed by a single device may be divided and executed by multiple devices. Conversely, a process described as being performed by different devices may be executed by a single device. In a computer system, the hardware configuration (server configuration) by which each function is implemented can be flexibly changed.

[0235] The present disclosure can also be realized by supplying a computer program that implements the functions described in the above embodiments to a computer and causing one or more processors included in the computer to read and execute the program. Such a computer program may be provided to the computer by a non-transitory computer-readable storage medium that can be connected to the system bus of the computer, or may be provided to the computer via a network. The non-transitory computer-readable storage medium includes, for example, any type of disk such as a magnetic disk (e.g., a floppy (registered trademark) disk, a hard disk drive (HDD), etc.), an optical disk (e.g., a CD-ROM, a DVD disk, a Blu-ray disk, etc.), a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic card, a flash memory, an optical card, and any type of medium suitable for storing electronic instructions.

Explanation of Signs

[0236] 1 ··· Platform 2 ··· Service Provider 3 ··· Authorization Authentication Server 4 ··· Data Holder 5 ··· User Terminal 11 ··· Graph Management Unit 12 ··· Information Notification Unit 13 ··· Graph Information Storage Unit 21 ··· Control Unit 22 ··· Cooperation Information DB 23 ··· Blockchain Node 24 ··· Block DB 25 ··· Information Notification Unit 31 ··· Authentication Control Unit 32 ··· Authorization Control Unit 33 ··· Authorization Information DB 41 ··· Login Control Unit 42 ··· Data Provision Unit 43 ··· Account Cooperation Information DB 44 ··· User Information DB 51 ··· Control Unit 52 ··· Access Token Storage Unit 100 Account Linking System 101··CPU 102...memory 103...Auxiliary storage device 104. Communications Department

Claims

1. Multiple service-providing servers that provide services, Multiple data storage servers that hold data, Obtain a graph created for the first user, where the account is a node, the first connection established between accounts on different service provision servers is the first edge, and the second connection established between the account on the service provision server and the account on the data retention server is the second edge. In the graph, if it is possible to reach the first account of the first user in the first service provision server from the first account of the first user in the first data retention server by following one or more of the first edges and one of the second edges, then first information is notified to the first service provision server to enable it to obtain data corresponding to the second account from the first data retention server. A control unit that performs the following: A system equipped with these features.

2. The control unit notifies the first service provider server of the third account of the first user in the second service provider server, as first information, which can be reached from the first account of the first user in the first service provider server by following one or more first edges in the graph for the first user, and which is connected to the second account in the first data storage server by the second edge. The first service provider server notifies the first data storage server of the third account in the second service provider server, and obtains the data corresponding to the second account from the first data storage server. The system according to claim 1.

3. Each of the aforementioned service provision servers maintains, for the first user account, first linkage information relating to the first linkage between the account and the account on the other service provision server, and second linkage information relating to the second linkage between the account and the account on the data retention server. The control unit receives the first cooperation information and the second information from the plurality of service provision servers. Obtain the linked information and create the aforementioned graph. The first linkage information includes the identification information of each of the two service provision servers on which the first linkage is set and the user account information for each of the two service provision servers. The second linkage information includes identification information of the service provider server on which the second linkage is set, user account information on the service provider server, and identification information of the data storage server on which the service provider server and the second linkage are set. The system according to claim 1.

4. The control unit, In the graph for the first user, if it is determined that a second service provider server corresponding to the first user's third account, which can be reached from the first user's first account on the first service provider server by following one or more first edges, and is connected to the second account on the first data retention server via a second edge, holds second information indicating that the first user has given comprehensive consent to other service provider servers to acquire data associated with the first user's account on the data retention server where the third account and the second linkage are configured, then the first information is notified. If the second service provider server determines that the second information is not held, it will not notify the first information. The system according to claim 2.

5. The system further includes an authorization server that performs authorization, which corresponds to the second service provider server described above. The authorization server issues an access token associated with the second information to the terminal of the first user. When the first service provider server receives access accompanied by the access token from the terminal of the first user, it sends the access token along with a request for notification of the first information. When the control unit receives the access token along with a request for notification of the first information from the first service provider server, it sends a request to the authorization server to verify the access token, and determines whether or not the second information is held in the second service provider server based on the response from the authorization server to the verification request. The system according to claim 4.

6. The control unit is provided in an information processing device that is independent of the plurality of service provision servers and the plurality of data storage servers. The system according to any one of claims 1 to 5.

7. The control unit is provided in each of the plurality of service provision servers, or in each of the plurality of information processing devices including the plurality of service provision servers and the plurality of data storage servers. The system according to any one of claims 1, 2, 4, or 5.

8. Each of the multiple information processing devices, which includes the multiple service provision servers and the control unit, obtains the graph from the blockchain, The multiple service-providing servers create a block containing information about the difference in the graph resulting from the addition or deletion of the first and second collaborations, and add it to the blockchain. The system according to claim 7.

9. Computers Obtain a graph created for a first user, in which the accounts in each of the multiple service provision servers that provide services and the multiple data retention servers that hold data are nodes, the first connection set up between accounts in different service provision servers is the first edge, and the second connection set up between accounts in the service provision servers and accounts in the data retention servers is the second edge. In the graph, if it is possible to reach the first account of the first user in the first service provision server from the first account of the first user in the first data retention server by following one or more of the first edges and one of the second edges, then first information is notified to the first service provision server that enables it to obtain data corresponding to the second account from the first data retention server. How to do it.

10. The computer notifies the first service provider server, as first information, of the third account of the first user in the second service provider server, which can be reached from the first account of the first user in the first service provider server by following one or more first edges in the graph for the first user, and is connected to the second account in the first data storage server by the second edge. The first service provider server notifies the first data storage server of the third account in the second service provider server, and retrieves the data corresponding to the second account from the first data storage server. The method according to claim 9.

11. Each of the aforementioned service provision servers maintains, for the first user account, first linkage information relating to the first linkage between the account and other service provision servers, and second linkage information relating to the second linkage between the account and data retention server. The computer obtains the first and second collaboration information from the multiple service provision servers and creates the graph. The first linkage information includes the identification information of each of the two service provision servers on which the first linkage is set and the user account information for each of the two service provision servers. The second linkage information includes identification information of the service provider server on which the second linkage is set, user account information on the service provider server, and identification information of the data storage server on which the service provider server and the second linkage are set. The method according to claim 9.

12. The aforementioned computer, In the graph for the first user, if it is determined that a second service provider server corresponding to the first user's third account, which can be reached from the first user's first account on the first service provider server by following one or more first edges, and is connected to the second account on the first data retention server via a second edge, holds second information indicating that the first user has given comprehensive consent to other service provider servers to acquire data associated with the first user's account on the data retention server where the third account and the second linkage are configured, then the first information is notified. If the second service provider server determines that the second information is not held, it will not notify the first information. The method according to claim 10.

13. An authorization server corresponding to the second service provider server issues an access token associated with the second information to the first user's terminal, and when the first service provider server receives access accompanied by the access token from the first user's terminal, it sends the access token along with a request for notification of the first information. When the computer receives the access token along with a request to obtain the first information from the first service provider server, it sends a request to the authorization server to verify the access token, and determines whether or not the second information is held in the second service provider server based on the response from the authorization server to the verification request. The method according to claim 12.

14. The computer is a device independent of the multiple service provision servers and the multiple data storage servers. The method according to any one of claims 9 to 13.

15. The computer is provided in each of the multiple service provision servers, or in each of the multiple information processing devices including the multiple service provision servers and the multiple data storage servers. The method according to any one of claims 9, 10, 12, or 13.

16. Each of the multiple service provision servers and the multiple information processing devices comprising the computers acquires the graph from the blockchain, The multiple service-providing servers create a block containing information about the difference in the graph resulting from the addition or deletion of the first and second collaborations, and add it to the blockchain. The method according to claim 15.

17. Obtain a graph created for a first user, in which the accounts in each of the multiple service provision servers that provide services and the multiple data retention servers that hold data are nodes, the first connection set up between accounts in different service provision servers is the first edge, and the second connection set up between accounts in the service provision servers and accounts in the data retention servers is the second edge. In the graph, if it is possible to reach the first account of the first user in the first service provision server from the first account of the first user in the first data retention server by following one or more of the first edges and one of the second edges, then first information is notified to the first service provision server that enables it to obtain data corresponding to the second account from the first data retention server. A control unit that executes An information processing device equipped with the following features.

18. The control unit, as first information, provides the first service provider server with the first account of the first user in the first service provider server, which can be reached by following one or more first edges in the graph for the first user, and is connected to the second account in the first data storage server by the second edge, and is connected to the third account of the first user in the second service provider server. We will notify you of the The first service provider server notifies the first data storage server of the third account in the second service provider server, and obtains the data corresponding to the second account from the first data storage server. The information processing apparatus according to claim 17.

19. Each of the aforementioned service provision servers maintains, for the first user account, first linkage information relating to the first linkage between the account and the account on the other service provision server, and second linkage information relating to the second linkage between the account and the account on the data retention server. The control unit obtains the first and second collaboration information from the plurality of service provision servers and creates the graph. The first linkage information includes the identification information of each of the two service provision servers on which the first linkage is set and the user account information for each of the two service provision servers. The second linkage information includes identification information of the service provider server on which the second linkage is set, user account information on the service provider server, and identification information of the data storage server on which the service provider server and the second linkage are set. The information processing apparatus according to claim 17.

20. The control unit, In the graph for the first user, if it is determined that a second service provider server corresponding to the first user's third account, which can be reached from the first user's first account on the first service provider server by following one or more first edges, and is connected to the second account on the first data retention server via a second edge, holds second information indicating that the first user has given comprehensive consent to other service provider servers to acquire data associated with the first user's account on the data retention server where the third account and the second linkage are configured, then the first information is notified. If the second service provider server determines that the second information is not held, it will not notify the first information. The information processing apparatus according to claim 18.

Images