System and storage media

Abstract

This system provides reliable data sharing between service providers with different identity verification and authentication procedures. [Solution] The distribution control server controls data sharing for the second service server to obtain user data from the first service server. The distribution control server stores the first requirements for the first service server to transmit the stored user data to the second service server. The distribution control server stores the second requirements for the second service server to receive the user data transmitted from the first service server. When the distribution control server receives a data sharing request regarding user data from the second service server, and if the stored first and second requirements are met, it instructs the first service server to transmit the user data to the second service server.

Description

Technical Field

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

Background Art

[0002] There exists a technique related to identity verification of a user who uses a system.

[0003] For example, Patent Document 1 describes that a trust service model capable of supporting various assurance levels is provided. The electronic authentication system of Patent Document 1 includes: an ID provider that verifies the identity of a user and then issues a digital ID to the user; a first certificate authority that issues a first electronic certificate to the user; and a second certificate authority that issues a second electronic certificate to the user. The first certificate authority and the second certificate authority associate the same digital ID issued to the user by the ID provider with the first electronic certificate and the second electronic certificate.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of Invention

Problems to be Solved by the Invention

[0005] With the advancement of systems represented by smart cities and the like, it is expected that services utilizing personal data (user data) collected via a plurality of data collaboration platforms will increase. Along with such an increase in services, there is a growing need for a connection scheme between data collaboration platforms that reduces the risk of privacy leakage, and in particular, a collaboration scheme for the trust layer (identity verification, personal authentication).

[0006] In this context, the content of identity verification and authentication often differs among data sharing platforms (each service provider). In such cases, the question arises whether data obtained by a service provider that performs strict identity verification from a service provider that does not. Alternatively, the question arises as to whether data provided by a service provider that performs strict authentication to a service provider that does not is being used for the benefit of the correct individual.

[0007] The primary objective of this invention is to provide a system and method that contribute to achieving highly reliable data linkage between service providers with different identity verification and authentication procedures. [Means for solving the problem]

[0008] According to a first aspect of the present invention, a system is provided comprising: a first service server managed by a first service provider and storing user data relating to a user; a second service server managed by a second service provider and providing services to the user using the user data; and a distribution control server that controls data sharing for the second service server to obtain the user data from the first service server, wherein the distribution control server stores first requirements for the first service server to transmit the stored user data to the second service server, stores second requirements for the second service server to receive the user data transmitted from the first service server, and when it receives a request for data sharing relating to the user data from the second service server, it instructs the first service server to transmit the user data to the second service server if the stored first and second requirements are met.

[0009] A second aspect of the present invention provides a method comprising: a first service server managed by a first service provider and storing user data relating to a user; a second service server managed by a second service provider and providing services to the user using the user data; and a distribution control server that controls data sharing for the second service server to obtain the user data from the first service server, wherein the distribution control server stores first requirements for the first service server to transmit the stored user data to the second service server, stores second requirements for the second service server to receive user data transmitted from the first service server, and when it receives a request for data sharing relating to the user data from the second service server, it instructs the first service server to transmit the user data to the second service server if the stored first and second requirements are met. [Effects of the Invention]

[0010] From each perspective of the present invention, a system and method are provided that contribute to achieving highly reliable data linkage between service providers with different identity verification and authentication procedures. However, the effects of the present invention are not limited to those described above. The present invention may also produce other effects in lieu of or in conjunction with these effects. [Brief explanation of the drawing]

[0011] [Figure 1] Figure 1 is a diagram illustrating the outline of one embodiment. [Figure 2] Figure 2 is a flowchart showing an example of operation in one embodiment. [Figure 3] Figure 3 is a diagram showing an example of the schematic configuration of the information distribution system related to this disclosure. [Figure 4] Figure 4 is a diagram illustrating the operation of the information distribution system related to this disclosure. [Figure 5]Figure 5 is a diagram for explaining the operation of the information distribution system according to the present disclosure. [Figure 6] Figure 6 is a diagram for explaining the operation of the information distribution system according to the present disclosure. [Figure 7] Figure 7 is a diagram for explaining the operation of the information distribution system according to the present disclosure. [Figure 8] Figure 8 is a diagram for explaining the operation of the information distribution system according to the present disclosure. [Figure 9] Figure 9 is a diagram showing an example of base information according to the present disclosure. [Figure 10] Figure 10 is a diagram for explaining the operation of the information distribution system according to the present disclosure. [Figure 11] Figure 11A and Figure 11B are diagrams showing an example of the linked data category according to the present disclosure. [Figure 12] Figure 12A and Figure 12B are diagrams showing an example of the reception policy definition and the transmission policy definition according to the present disclosure. [Figure 13] Figure 13A and Figure 13B are diagrams showing an example of the reception policy definition and the transmission policy definition according to the present disclosure. [Figure 14] Figure 14 is a diagram for explaining the operation of the information distribution system according to the present disclosure. [Figure 15] Figure 15 is a diagram showing an example of the sharing definition according to the present disclosure. [Figure 16] Figure 16 is a diagram showing an example of the consent information according to the present disclosure. [Figure 17] Figure 17 is a diagram for explaining the operation of the information distribution system according to the present disclosure. [Figure 18] Figure 18A and Figure 18B are diagrams showing an example of the connection definition according to the present disclosure. [Figure 19] Figure 19 is a diagram for explaining the operation of the information distribution system according to the present disclosure. [Figure 20] Figure 20 is a diagram for explaining the operation of the information distribution system according to the present disclosure. [Figure 21] Figure 21 is a diagram showing an example of the processing configuration of the distribution control server according to the present disclosure. [Figure 22] Figure 22 is a diagram illustrating an example of a part of a user information database according to the present disclosure. [Figure 23] Figure 23 is a diagram illustrating an example of a location information database according to the present disclosure. [Figure 24] Figure 24 is a diagram illustrating an example of a processing configuration of a service server according to the present disclosure. [Figure 25] Figure 25 is a diagram illustrating an example of a customer information database according to the present disclosure. [Figure 26] Figure 26 is a diagram illustrating an example of a hardware configuration of a distribution control server according to the present disclosure. [Mode for Carrying Out the Invention]

[0012] First, an overview of one embodiment will be described. Note that the reference numerals of the drawings appended to this overview are provisionally assigned to each element as an example to facilitate understanding, and the description of this overview is not intended to be limiting in any way. Unless otherwise specified, the blocks illustrated in each drawing do not represent a configuration in hardware units, but a configuration in functional units. Connection lines between blocks in each figure include both bidirectional and unidirectional connections. A unidirectional arrow schematically shows the main flow of signals (data), and does not exclude bidirectionality. In the present specification and drawings, elements that can be described in the same manner are denoted by the same reference numerals, whereby redundant descriptions may be omitted.

[0013] A system according to one embodiment includes a first service server 101, a second service server 102, and a distribution control server 103 (see Figure 1). The first service server 101 is managed by the first service provider and stores user data relating to users. The second service server 102 is managed by the second service provider and provides services to users using the user data. The distribution control server 103 controls data sharing for the second service server 102 to acquire user data from the first service server 101. The distribution control server 103 stores a first requirement for the first service server 101 to transmit the stored user data to the second service server 102 (step S1 in Figure 2). The distribution control server 103 stores a second requirement for the second service server 102 to receive the user data transmitted from the first service server 101 (step S2). When the distribution control server 103 receives a request from the second service server 102 for data sharing regarding user data, if the stored first and second requirements are met, it instructs the first service server 101 to send the user data to the second service server 102 (user data transmission instruction; step S3).

[0014] When the second service server 102 requests data sharing, the distribution control server 103 determines whether the first requirement for the first service server 101, the data sharing source, to send user data has been met. The distribution control server 103 also determines whether the second requirement for the second service server 102, the data sharing destination, to receive user data has been met. In other words, the distribution control server 103 realizes data sharing only when predetermined requirements (for example, trust level requirements such as identity verification and authentication) are met on both the sending and receiving sides in data sharing. The service providers involved in data sharing can set requirements as the first and second requirements that allow data transmission and reception to service providers with different identity verification and authentication procedures. As a result, highly reliable data linkage is achieved.

[0015] Specific embodiments will be described in more detail below with reference to the drawings.

[0016] [First Embodiment] The first embodiment will be described in more detail with reference to the drawings.

[0017] [System Configuration] Figure 3 is a diagram showing an example of the schematic configuration of an information distribution system according to the embodiment disclosed herein. As shown in Figure 3, the participating members (actors) of the information distribution system include an information distribution business operator and multiple service providers X to Z.

[0018] An information distribution service provider is a business that provides a platform for data distribution services (information distribution services) of user data accumulated by service providers. The information distribution service provider controls the data distribution between service providers. The information distribution service provider is equipped with a distribution control server 10.

[0019] The distribution control server 10 is a server device that controls (realizes) data distribution between service providers. The distribution control server 10 realizes the information distribution service of user data held by each service provider.

[0020] A service provider is an entity that provides services to individuals. Service providers can be private businesses or public institutions. Examples of service providers include medical institutions (hospitals, pharmacies, etc.) that provide medical services to users, retailers, and educational institutions that teach languages, sports, arts, etc. to customers.

[0021] Each service provider may offer multiple services to users. For example, a hospital may offer a "health advice" service in addition to medical services, providing users with advice on their health.

[0022] Each service provider has a service server 20 for providing services to customers. The service server 20 is managed and operated by the service provider. The service server 20 holds (stores) data generated by the service provider providing services to users, data necessary for providing services to users, etc. The service provider also holds user data related to the services provided to users.

[0023] Service server 20 also serves as a server that provides the infrastructure for sharing user data with other service providers. In other words, service providers are also infrastructure providers that provide the infrastructure for data distribution (data linkage).

[0024] The service provider and the infrastructure provider may be the same entity or different entities. The service server 20 may be managed and operated by both the service provider and the infrastructure provider. Alternatively, one service server 20 may be shared by multiple service providers. In the above example, a service provider that provides medical services and a service provider that provides health advice may share the service server 20.

[0025] In the following explanation, the infrastructure of service provider X (infrastructure provider X) will be referred to as infrastructure X, the infrastructure of service provider Y (infrastructure provider Y) will be referred to as infrastructure Y, and the infrastructure of service provider Z (infrastructure provider Z) will be referred to as infrastructure Z.

[0026] The service server 20 is equipped with a function to authenticate users (personal authentication function) and a function to link data with other infrastructures (data linkage function). For example, the personal authentication function implements an authentication site for authenticating users who wish to receive the service. For example, the data linkage function enables the sharing of user data by utilizing an information distribution platform provided by an information distribution business operator.

[0027] Users of the information distribution system possess terminal 30.

[0028] The devices shown in Figure 3 are interconnected via a network. For example, the distribution control server 10 and the service server 20 are connected by wired or wireless communication means and are configured to communicate with each other.

[0029] The configuration shown in Figure 3 is illustrative and is not intended to limit the configuration of the information distribution system disclosed in this application. For example, an information distribution business operator may include two or more distribution control servers 10. Also, an information distribution system may include four or more service providers.

[0030] [System Overview] Next, we will describe the general operation of the information distribution system according to the first embodiment.

[0031] Users enter into individual contracts with service providers from whom they wish to receive services. For example, a user provides their name and other information to a service provider and requests to enter into a new contract (a contract to receive services) with that service provider.

[0032] For example, a user accesses a service server 20 operated by an e-commerce (EC) business and creates an account. At that time, the service provider verifies the user's identity in accordance with its own security policy, etc. For example, the service provider may perform online identity verification using official identification documents or face-to-face identity verification.

[0033] Furthermore, user accounts may be created online by the user, or they may be created together with the user by staff of the service provider. Additionally, the created accounts may be shared by multiple service providers. In the example above, users receiving medical services and health advice may be managed under the same account.

[0034] The service provider generates a "personal identification ID" to identify new customers (users). For example, an e-commerce business generates a membership number or similar as a personal identification ID for managing customers. The service server 20 stores the generated personal identification ID (e.g., membership number) in a database or similar.

[0035] Once a personal identification ID is generated, the user can receive services from the service provider. For example, the user logs into an account on an e-commerce site. At that time, the service provider authenticates the user according to its own security policy, etc. For example, the service server 20 performs authentication using an ID and password, or multi-factor authentication.

[0036] In order for user data generated by service providers providing services to users to be included in data distribution, "storage" of the data is necessary. Data storage is the process by which service providers (sources of user data) register user data in the information distribution system as data that can be provided to third parties. The distribution control server 10 controls the data storage necessary to include data related to services provided by data storage providers (service providers) to users in data distribution.

[0037] The accumulated data becomes subject to data distribution. Furthermore, the accumulation of user data requires the consent of the user (the user who generated the user data) (agreement to data accumulation).

[0038] "Sharing" is a means of data distribution in information distribution systems.

[0039] "Sharing" is a means for service providers to acquire data accumulated by other service providers. For example, data exchange through "sharing" is used when an e-commerce business acquires data generated by a hospital providing services to its users. The e-commerce business then uses the data acquired from the hospital through data sharing to provide better services to its users.

[0040] <System Account Generation> A user of the information distribution system needs to complete pre-registration (user registration, system registration) in advance. More specifically, the user accesses the distribution control server 10 to perform procedures for account generation. In the following description, an account generated in the information distribution system is referred to as a "system account".

[0041] To generate a system account, the user operates their own terminal 30 to access the distribution control server 10. In response to the access from the terminal 30, the distribution control server 10 displays a web page for generating a system account.

[0042] The user performs an operation for generating a system account (for example, pressing a predetermined button) to generate the system account. At that time, the distribution control server 10 acquires information necessary for the user to generate the system account. Specifically, the distribution control server 10 acquires the user's login information (login ID, password) and personal information (name, date of birth, contact information, account information, etc.).

[0043] Upon acquiring the login information, personal information and the like, the distribution control server 10 generates a user ID (Identifier) for uniquely identifying the user in the information distribution system.

[0044] The distribution control server 10 associates and stores the generated user ID of the user, the login information, the personal information (for example, name, date of birth, contact information) and the like. The distribution control server 10 stores these pieces of information in a "user information database". Details of the user information database will be described later.

[0045] The distribution control server 10 issues the generated user ID to the user (terminal 30). The terminal 30 stores the issued user ID.

[0046] <ID Cooperation> As mentioned above, in order for user data held by service providers to be included in data distribution, "data storage" is necessary. To achieve data storage, it is necessary to link the system account ID (user ID) with the ID (personal identification ID) generated by the service provider.

[0047] For example, as shown in Figure 4, the user informs a hospital staff member at the hospital's reception desk that they wish to use the user data held by the hospital (they apply for data utilization). The hospital staff member then enters the user's personally identifiable information, the user's personal identification ID (e.g., patient ID number), and the business code into the hospital terminal 31.

[0048] Personally identifiable information is information used to identify a user. Examples of personally identifiable information include the user's name, or a combination of name and date of birth.

[0049] Furthermore, the business code is an identification information (ID) used to identify service providers participating in the information distribution system. For example, hospitals and e-commerce businesses are assigned different codes. Business codes are shared among system participants (information distribution providers and service providers) by any means necessary. For example, when a service provider joins the information distribution system, the information distribution provider generates a business code to assign to that service provider. The information distribution provider then notifies the service provider of the generated business code.

[0050] The hospital terminal 31 sends an "ID linkage request" containing the acquired personal identification information, personal identification ID, and business code to the distribution control server 10.

[0051] Alternatively, users who wish to utilize the user data of an e-commerce business operator can operate terminal 30 to access the e-commerce business operator's service server 20 (see Figure 5). The user logs into the e-commerce business operator's account and submits an application for data utilization through that account. In response to this application, the service server 20 sends an "ID linkage request" containing the user's personally identifiable information, personal identification ID, and business code to the distribution control server 10.

[0052] The distribution control server 10 obtains the personal identification information of the person requesting ID linkage, the personal identification ID, and the business code of the service provider (for example, a hospital or e-commerce business) that is the target of the ID linkage from the hospital terminal 31 or the service server 20.

[0053] The distribution control server 10 identifies the service provider that is subject to ID linkage from the business code. The distribution control server 10 also identifies the user registered in the system account from the personal identification information and associates the service provider with the personal identification ID in the account of the identified user.

[0054] Once a personal identification ID is registered to a system account (i.e., ID linking is complete), the service provider involved in the ID linking can "store" the user data of users who wish to utilize that data.

[0055] Furthermore, a user's "application for data utilization" to a service provider can be interpreted as consent (agreement) to the service provider accumulating user data.

[0056] <Data storage> When a service provider provides a service to a user, it stores the user's personal identification ID and user data (personal data) in association with each other.

[0057] The service provider sends "location information" to the distribution control server 10 each time it stores user data (data generated as a result of service provision, data necessary for service provision) for users who have completed ID linkage (users who have applied for data utilization).

[0058] For example, as shown in Figure 6, when a hospital provides medical services to each of users U1 to U3, the hospital maintains the results for each user. For example, the hospital maintains the examination results (disease name; for example, data such as stomach cancer or lung cancer) for each of users U1 to U3.

[0059] The service provider (service server 20) stores each user's personal identification ID in association with the user data obtained as a result of service provision. For example, in the example in Figure 6, the service server 20 uses the "customer information database" to store each user U1 to U3's personal identification ID in association with their medical examination results. Details of the customer information database will be described later.

[0060] Each time a service provider stores user data relating to a user who has consented to data storage, it sends "location information" to the distribution control server 10. Location information is information about the storage location of the user data (data storage entity; service provider), etc. Location information includes personal identification ID, business code, type of data held, etc.

[0061] The distribution control server 10 stores the acquired location information in the "location information database." Details of the location information database will be described later. The location information database stores personal identification IDs, business codes, and data types in association with each other.

[0062] <Data Sharing> Service providers who wish to acquire data accumulated by other service providers (user data resulting from services provided by other service providers to users) can acquire such data through "sharing".

[0063] Here, referring to Figure 7, we will explain the case in which e-commerce business B obtains user U1's data (medical examination results) stored at hospital A through "sharing".

[0064] EC business operator B (service server 20) sends a "sharing request" to the distribution control server 10 (step S11).

[0065] Based on the sharing request, the distribution control server 10 identifies user U1, who is the target of the data distribution, and the data storage entity (hospital A) of the data to be distributed. The distribution control server 10 sends an inquiry regarding data sharing to the terminal 30 held by the identified target (step S12).

[0066] Terminal 30, upon receiving a data sharing inquiry, obtains user U1's consent regarding data sharing. For example, terminal 30 obtains user U1's consent using a GUI (Graphical User Interface). In the example above, terminal 30 displays a GUI with content such as, "By sharing your hospital examination results with the e-commerce business, you can receive better service. Do you want to share?" and obtains user U1's consent (agree or disagree to data sharing).

[0067] Terminal 30 sends a response to the data sharing inquiry (agree to data sharing or refuse data sharing) to the distribution control server 10 (step S13).

[0068] If user U1 consents, the distribution control server 10 sends a sharing instruction to the data accumulator (hospital A) (step S14).

[0069] Upon receiving the sharing instruction, Hospital A (service server 20) refers to the customer information database and sends the medical examination results of the target user U1 to the designated data sharing destination service server 20 (step S15).

[0070] Next, we will explain how the system operates when the methods for verifying user identity and authenticating the user differ among service providers.

[0071] <Definitions of Receiving Policy and Transmitting Policy>

[0072] The distribution control server 10 has a policy definition function that manages "linked data categories," "transmission policies," and "reception policies" for each data linkage platform. The distribution control server 10 also has a function to check (verify) policy violations in the "shared definitions." The linked data categories and other related details are described below.

[0073] Infrastructure providers (service providers) participating in the information distribution platform must first register as a provider (infrastructure registration). Specifically, a representative of the infrastructure provider accesses the distribution control server 10 using an infrastructure terminal 32 such as a personal computer and performs infrastructure registration (Figure 8, step S21). For example, the distribution control server 10 accepts infrastructure registration through a dedicated site for infrastructure registration.

[0074] More specifically, the person in charge inputs the name of the infrastructure provider, infrastructure identification information (business code), etc., into the distribution control server 10. Furthermore, the person in charge registers information regarding user identity verification and authentication with the distribution control server 10. More specifically, the person in charge registers two things with the distribution control server 10: the "identity verification level" and the "person authentication level".

[0075] The identity verification level refers to the level of rigor (content) with which the infrastructure provider (service provider) verifies the user's identity when creating a user account. A higher identity verification level indicates that stricter identity verification is performed.

[0076] For example, the identity verification level is "1" when identity verification is based on self-declaration. Alternatively, the identity verification level is "2" when online identity verification is performed using official documents. Alternatively, the identity verification level is "3" when face-to-face identity verification is performed using official documents.

[0077] The user authentication level refers to the level of strength (content) of authentication performed by the infrastructure provider (service provider) when a user logs into their account. A higher user authentication level indicates stricter authentication.

[0078] For example, the authentication level is "1" when single-factor authentication is performed using an ID and password. Alternatively, the authentication level is "2" when multiple-factor authentication is performed. The authentication level is "3" when authentication is performed using a tamper-resistant device (e.g., an IC (Integrated Circuit) card) in addition to multiple-factor authentication.

[0079] In the following explanation, the identity verification level and the person authentication level will be collectively referred to as the "trust level."

[0080] When the distribution control server 10 obtains the name and trust level of the underlying business operator, it stores the obtained information as "underlying information." For example, as shown in Figure 9, the distribution control server 10 stores the identity verification level and the person authentication level for each underlying business operator (business operator code).

[0081] Once the infrastructure information is stored, the distribution control server 10 generates a "connector" that is responsible for controlling the data distribution of the newly registered infrastructure. For example, the distribution control server 10 generates virtual machines and containers corresponding to the new infrastructure in which the infrastructure information has been registered as "connectors".

[0082] For example, when a new board Z is registered, the distribution control server 10 generates a "connector" specifically for that board Z. In the following explanation, connectors corresponding to boards will be indicated together with the board name. For example, the connector corresponding to board Z will be indicated as connector Z.

[0083] Here, the distribution control server 10 includes a function to manage each connector in an integrated manner. This function to manage each connector in an integrated manner is referred to as the "Connector SV (Supervisor)". The Connector SV and each connector have a one-to-many relationship as shown in Figure 10. As shown in Figure 10, connectors are generated corresponding to each board, and no information is sent or received between connectors. The Connector SV issues various instructions to each connector, enabling data distribution between boards.

[0084] A single connector SV is installed for the entire system. Each connector is installed for each infrastructure (data integration infrastructure) and connects to the connector SV. The connectors cooperate with each other based on the enabled and disabled status of the connection definition described later.

[0085] Once infrastructure information is registered, the infrastructure provider registers the types of data handled by its infrastructure with the distribution control server 10. In other words, the distribution control server 10 collects the types of data handled by the infrastructure provider that has registered the infrastructure.

[0086] Specifically, the person in charge at the infrastructure provider registers the types of data handled by their infrastructure with the distribution control server 10 (data registration; step S22 in Figure 8). For example, the person in charge at infrastructure provider Z registers information such as "disease name" and "prescription drug" as the types of data handled by their infrastructure with the distribution control server 10.

[0087] The connector SV registers the acquired data types in the infrastructure information (see Figure 9). Once the connector SV collects the data types handled by the newly registered infrastructure, it provides the infrastructure information and data types handled by other infrastructures to the newly registered infrastructure provider. Through this information provision, the connector SV requests the infrastructure provider to categorize the data circulating on the information distribution platform (categorization request; step S23 in Figure 8).

[0088] For example, when a new base Z is registered, the connector SV provides the base information and data types handled by base X and base Y to base provider Z, and requests base provider Z to categorize the various data. The connector SV then transmits the base information and data types of base X and base Y to the base terminal 32.

[0089] The person in charge categorizes the data (data types) exchanged on the information distribution platform, including the data handled on their own infrastructure. For example, the person in charge classifies each data into one of three categories (Category 1 to 3). The person in charge categorizes the data considering its characteristics, importance, etc.

[0090] For example, data that is not deeply related to an individual's privacy and is of low importance is classified as Category 1. For instance, "step count" is classified as Category 1. Conversely, data that is deeply related to an individual's privacy and is of high importance is classified as Category 3. For example, "disease name" is classified as Category 3. The importance of data classified as Category 2 is intermediate between Category 1 and Category 3 data. For example, data such as "vital signs" and "test results" are classified as Category 2.

[0091] The person in charge categorizes the data to be distributed and registers the results in the distribution control server 10. The person in charge registers the data types belonging to each category and the information of the infrastructure that stores the data corresponding to that data type in the distribution control server 10 (category registration; step S24 in Figure 8).

[0092] Connector SV passes the acquired information to the corresponding connector on the infrastructure. For example, if the above information (data types belonging to each category and infrastructure information) is acquired from the person in charge at infrastructure provider Z, Connector SV passes the acquired information to Connector Z.

[0093] Connector Z stores the acquired information as a "linked data category." For example, Connector Z stores the information shown in Figure 11A as the linked data category for board Z. Similarly, Connector X stores the information shown in Figure 11B as the linked data category for board X. Linked data categories manage data types in association with board information.

[0094] Furthermore, when a connector SV requests a platform provider to categorize the target data, it may suggest as candidates definitions of other platforms with a trust level similar to that of the platform provider (categorization results from other platforms). Alternatively, for new data (data types), the connector SV may suggest categories of other similar data types based on the data name or summary.

[0095] Once data categorization is complete, the infrastructure provider's representative registers the data transmission and reception policy (data sharing policy) with the distribution control server 10 (policy registration; step S25 in Figure 8).

[0096] More specifically, the person in charge registers a request regarding the trust level of another infrastructure when acquiring data from that infrastructure through data sharing with the distribution control server 10 as a "receiving policy." Alternatively, the person in charge registers a request regarding the trust level of another infrastructure when providing data to that infrastructure through data sharing with the distribution control server 10 as a "transmission policy."

[0097] The receiving policy and transmitting policy describe the requirements necessary to accept or provide data for each category. For example, the person in charge of infrastructure Z registers the receiving policy shown in Figure 12A and the transmitting policy shown in Figure 12B with the distribution control server 10.

[0098] The Category 1 acceptance policy shown in Figure 12A includes requirements regarding the trust level difference and the frequency of checking the trust level difference. The trust level difference requirement stipulates that for infrastructure Z to accept data classified as Category 1, successful authentication of the user in an infrastructure with a trust level one level lower than infrastructure Z's trust level is required. The requirement regarding the frequency of checking the trust level difference indicates that the period during which the above requirement regarding the trust level difference is considered fulfilled is 7 days. Specifically, "every 7 days" in the acceptance policy indicates that after 7 days have passed since the date and time the trust level difference requirement for Category 1 was met, the requirement for checking the trust level difference must be checked again.

[0099] The Category 2 receiving policy indicates that for base Z to accept data classified as Category 2, it is necessary to verify daily that there is no difference in trust levels between base Z and the data sharing source. The Category 3 receiving policy indicates that for base Z to accept data classified as Category 3, it is necessary that base Z and the data sharing source have the same trust level.

[0100] The transmission policies for categories 1 and 2 shown in Figure 12B have the same requirements as the reception policies for categories 1 and 2 on board Z. The transmission policy for category 3 indicates that board Z cannot share (transmit) data classified as category 3 to other boards.

[0101] Thus, the receiving policy and the transmitting policy also concern the extent to which differences in trust levels (identity verification level, person authentication level) will be aligned (tolerated) for each category of data exchanged between infrastructures.

[0102] Connector SV passes the received policy and transmitted policy obtained from the infrastructure operator (infrastructure terminal 32) to the corresponding connector. In the example above, connector SV passes the received policy and transmitted policy to connector Z. The connector stores the obtained received policy as a received policy definition and the transmitted policy as a transmitted policy definition.

[0103] Each infrastructure provider (service provider) participating in the information distribution platform registers its receiving policy and transmitting policy with the distribution control server 10. For example, infrastructure X registers the receiving policy definition shown in Figure 13A and the transmitting policy definition shown in Figure 13B with the distribution control server 10.

[0104] Once the receiving policy and sending policy are registered, the service provider configures the settings for acquiring the data necessary to provide the service to the customer. Specifically, the service provider's representative determines the data (data type) and data source necessary for providing the service. More specifically, the representative determines the data that can be prepared on their own infrastructure and the data that needs to be acquired from other infrastructures, and registers this information with the service server 20 via the service terminal 33 (service registration; step S31 in Figure 14).

[0105] For example, if service provider Z plans to provide a "health advice" service, the person in charge will input the information shown in Figure 15 into the service server 20. In the following explanation, the information regarding the data necessary for providing the service and its source (data source) will be referred to as "shared definitions." The person in charge of the service provider registers the shared definitions with the service server 20.

[0106] The service server 20, having obtained the shared definition, requests the distribution control server 10 to perform a policy check on the shared definition (policy check request; step S32 in Figure 14). The service server 20 then sends the shared definition shown in Figure 15 to the distribution control server 10.

[0107] Connector SV instructs connectors corresponding to boards other than the same board that are included as data sources in the shared definition to determine whether or not data subject to data sharing can be sent and received. Connector SV identifies the boards (sending board, receiving board) to which policy checks should be instructed based on the data type of the target data. In the example in Figure 15, Connector SV instructs Connector X and Connector Z to determine whether or not data types "vitals" and "steps" can be sent and received. Connector SV also instructs Connector Y and Connector Z to determine whether or not data types "inspection results" and "measured values" can be sent and received.

[0108] Each connector verifies, for example, whether the transmission of data that is required to be sent to another board is prohibited.

[0109] The connector notifies the connector SV of the verification results (check results; step S33 in Figure 14). The service server 20 notifies the person in charge of the check results by the connector (step S34). The person in charge modifies the shared definition as necessary. For example, the person in charge removes data that has been determined to be untransmittable from the shared definition. The modified shared definition is then subjected to a policy check by the corresponding connector via the service server 20 and the connector SV.

[0110] Shared definitions that pass the policy check are stored in the service server 20 along with information about the services provided.

[0111] <Connection Definition> The distribution control server 10 has a connection definition function that, triggered by an individual's consent to a shared definition, generates connection definitions between connectors corresponding to the data sharing source and data sharing destination infrastructures, and provides data transmission and reception authorization functions to the data linkage infrastructure.

[0112] Once a shared definition is registered, the service provider becomes ready to provide services to users. Users who wish to receive the service access the service provider's service server 20 and apply for the service. For example, a user logs into service provider Z's account and applies for "health advice." The following explanation describes the case where user A applies for health advice.

[0113] Upon receiving a service application, the service server 20 presents the shared definition for the service to user A and notifies user A that obtaining the data described in the shared definition is necessary for the service to be provided. For example, the service server 20 presents user A with a shared definition as shown in Figure 15 and obtains user A's consent to obtain and use the data described in the shared definition.

[0114] User A inputs to the service server 20 whether or not they consent to the acquisition and use of data described in the shared definition. At this time, User A can also refuse to acquire or use certain data. For example, in the example in Figure 15, User A refuses to acquire "vitals" from another source.

[0115] The service server 20 identifies the data that user A has consented to (data listed in the shared definition that the user has consented to use for the service). For example, the service server 20 obtains information as shown in Figure 16. In the following explanation, information regarding data that the user has consented to use when receiving the service, as shown in Figure 16, will be referred to as "consent information." Figure 16 is a diagram showing an example of consent information for user A of the health advice service in infrastructure Z.

[0116] The service server 20 transmits the acquired consent information to the distribution control server 10 (step S41 in Figure 17). By transmitting the consent information to the distribution control server 10, the service server 20 requests the distribution control server 10 to generate a "connection definition". The connector SV stores the received consent information from user A.

[0117] Here, a connection definition is information prepared for each user receiving the service, and is referenced by the connector when the user's user data is sent and received. For each piece of data (data type), a connection definition is generated in both the connector corresponding to the data sharing source infrastructure and the connector corresponding to the data sharing destination infrastructure.

[0118] For example, if data B relating to user A is provided from infrastructure X to infrastructure Z through data sharing, connector X generates a connection definition (user A; data B; X → Z), and connector Z generates a connection definition (user A; data B; Z ← X).

[0119] In the following explanation, as in the example above, the user information and data types targeted by the connection definition will be indicated in parentheses, and the direction of data sharing will be described following the data. Furthermore, the user information included in the connection definition will include the user's personal identification ID as an example.

[0120] When Connector SV obtains user A's consent information, it instructs the connectors of both the data sharing source and the data sharing destination to generate connection definitions for each data item described in the consent information.

[0121] For example, in the case of the data type "steps" in the consent information of user A shown in Figure 16, connector SV instructs connector X, which corresponds to the data sharing source infrastructure X, to generate a connection definition (user A; steps; X → Z). Connector SV also instructs connector Z, which corresponds to the data sharing destination infrastructure Z, to generate a connection definition (user A; steps; Z ← X).

[0122] The connector that receives the instructions generates a connection definition.

[0123] Here, we will explain using the example where connector X and connector Z generate connection definitions related to user A's "step count".

[0124] Connector X refers to the linked data categories of the base X and identifies the step count category described in the consent information. For example, Connector X refers to the linked data categories of the base X shown in Figure 11B and identifies "Category 1" as the "step count" category.

[0125] Next, Connector X refers to the transmission policy definition of Base X as shown in Figure 13B and obtains the transmission policy for the category identified above. Connector X obtains "Identity Verification Level: All Allowed, User Authentication Level: All Allowed" as the transmission policy for "Steps" classified as Category 1. Connector X generates the obtained transmission policy as a connection definition for User A's "Steps" in Base X.

[0126] For example, connector X generates a connection definition (user A; step count; X → Z) related to user A's "step count" as shown in Figure 18A.

[0127] Next, we will explain how connector Z, which is the data sharing destination, generates a connection definition related to user A's "step count".

[0128] Connector Z, which corresponds to the data sharing destination, Base Z, refers to the linked data categories of Base Z and identifies the "steps" category. For example, Connector Z refers to the linked data categories of Base Z shown in Figure 11A and identifies "Category 1" as the step category.

[0129] Next, Connector Z refers to the receiving policy definition of Base Z as shown in Figure 12A and obtains the receiving policy for the category identified above. Connector Z obtains "Identity verification level; level difference of 1 every 7 days, person authentication level; level difference of 1 every 7 days" as the receiving policy for "steps" classified as Category 1. Connector Z generates the obtained receiving policy as a connection definition for user A's "steps" in Base Z.

[0130] For example, connector Z generates a connection definition (user A; step count; Z←X) related to user A's "step count" as shown in Figure 18B.

[0131] <Authentication Integration> The distribution control server 10 is equipped with an authentication linkage function that controls the validity or invalidity of connection information by matching the identity verification level and the person authentication level in response to requests from the connection definition function (connector). This authentication linkage function uses the "authentication site" provided by each platform (data linkage platform) as a means of level matching.

[0132] User A logs into the service provider's account to receive the service. For example, in the health advice example above, User A operates terminal 30 to access service provider Z's service server 20 and undergoes authentication (accessing the authentication site; step S51 in Figure 19).

[0133] When the service server 20 successfully authenticates user A, it notifies the distribution control server 10 of the successful authentication of user A and information regarding the services to be provided to user A. In the example above, the service server 20 sends an authentication success notification to the distribution control server 10 that includes user A's personal identification ID and the name of the service to be provided, "Health Advice" (authentication success notification; step S52).

[0134] Connector SV requests that the connectors of both the data sharing source and the data sharing destination verify the connection definition for the data that is subject to data sharing in the consent information regarding user A's health advice.

[0135] This section describes the case where connector X, which corresponds to infrastructure X, the data source for user A's "step count," and connector Z, which corresponds to infrastructure Z, the data recipient for user A's "step count," each verify the connection definition.

[0136] First, let's explain the case where Connector X verifies the connection definition (User A; Steps; X→Z). In this case, the connection definition (User A; Steps; X→Z) states "All Allowed" for both the identity verification level and the user authentication level (see Figure 18A). Therefore, Connector X determines that the connection definition (User A; Steps; X→Z) is valid. Connector X then notifies Connector SV of the result (valid).

[0137] Next, we will explain the case where connector Z verifies the connection definition (User A; Steps; Z←X). In this case, the connection definition (User A; Steps; Z←X) states "Level difference of 1 every 7 days," so connector Z refers to the base information of base X and base Z and calculates the level difference of the trust level. In this case, the level difference is calculated to be "2".

[0138] The requirement regarding the level difference of the trust level described in the connection definition is "level difference 1," so connector Z determines that it does not meet the requirement regarding the level difference of the trust level. Therefore, connector Z determines whether or not the requirement regarding the frequency of checking the level difference is met. Specifically, connector Z determines that the connection definition (user A; step count; Z←X) is valid if 7 days have not passed since the last time it was determined to be valid. If 7 days have passed since the last time the connection definition (user A; step count; Z←X) was determined to be valid, connector Z determines that the connection definition is invalid.

[0139] Here, we consider a case where the requirement regarding the frequency of checking the level difference is also not met. In this case, the connection definition (User A; Steps; Z←X) is determined to be invalid. Connector Z notifies Connector SV of the verified connection definition (User A; Steps; Z←X) along with the determination result (invalid). Connector Z requests Connector SV to activate the invalid connection definition (User A; Steps; Z←X). Connector Z requests Connector SV to ensure consistency in the trust levels of both ends of the connection (Base X, Base Z) in data sharing of data type "Steps".

[0140] The connector SV performs a process to activate connection definitions (User A; Steps; Z←X) that have been determined to be invalid based on the verification results. The connector SV then performs the above trust level alignment. Specifically, the connector SV sets up an "authentication flow" to satisfy the requirements described in the invalid connection definition and requests the user to perform the configured authentication flow.

[0141] Specifically, the connector SV identifies the board with the higher trust level among the boards at both ends of the connection (board Z and board X in the example above) as described in the connection definition. In the example above, the connector SV refers to the board information and identifies board Z as the board with the higher trust level.

[0142] Next, connector SV identifies a board with a trust level that is one level lower than the trust level of the identified board, as specified in the connection definition. In the example above, the level difference specified in the connection definition is "1", so board Y, which is one level lower than the trust level of board Z ("3"), is identified.

[0143] Connector SV generates an authentication flow that starts with authentication by the identified board and ends with authentication by the board with the lower trust level among the boards at both ends of the connection as described in the connection definition. In the example above, an authentication flow is generated in which authentication by board Y is the starting point and authentication by board X is the ending point.

[0144] Once an authentication flow is generated, the connector SV requests user A to perform the generated authentication flow. Specifically, the connector SV sends an "authentication request notification" to user A's terminal 30 (step S53 in Figure 19). For example, the connector SV sends the authentication request notification to user A's email address, etc.

[0145] Here, the authentication request notification contains the URL (Uniform Resource Locator) of the trust level matching site. Terminal 30 accesses the trust level matching site using this URL (step S54). The trust level matching site is implemented by the connector SV of the distribution control server 10.

[0146] When terminal 30 accesses the trust level matching site, connector SV redirects terminal 30's connection in the order of the authentication flow generated above. In the example above, connector SV redirects terminal 30's connection to the authentication site of base Y, which is the starting point of the authentication flow (redirect to base Y; step S55).

[0147] User A is authenticated at the authentication site of infrastructure Y. If the service server 20 of infrastructure Y successfully authenticates user A, it redirects the connection of terminal 30 to the trust level matching site.

[0148] When the connection of terminal 30 is redirected from the authentication site (service server 20) of infrastructure Y, connector SV redirects the connection of terminal 30 to the authentication site of infrastructure X, which is the endpoint of the authentication flow (redirection to infrastructure X; step S56).

[0149] The user is authenticated at the authentication site of infrastructure X. When the service server 20 of infrastructure X successfully authenticates user A, it redirects the connection of terminal 30 to the trust level consistent site.

[0150] When the connection to terminal 30 is redirected from the authentication site of base X, connector SV determines that the authentication flow for user A has been completed.

[0151] Once the authentication flow is complete, connector SV notifies connector Z. Upon receiving notification of the completion of the authentication flow, the connector determines that the previously invalid connection definition has been activated. In the example above, connector Z determines that the connection definition (User A; Steps; Z←X) has been activated. Connector Z remembers the date of activation.

[0152] When the connection definitions for each data item described in user A's consent information are activated within a predetermined time, the connector SV notifies the service server 20 that each connection definition for user A has been activated (step S57). In other words, when authentication at each authentication site included in the authentication flow is successful within a certain time, the connector SV determines that the trust level has been aligned and notifies the service server 20 that it is ready to acquire the data through data sharing.

[0153] Furthermore, each connector may reset (deactivate) its enabled connection definition according to the policy (policy regarding verification frequency) described in that connection definition. This reset reduces the risk of impersonation.

[0154] <Transmission and Reception Authorization> The distribution control server 10 has a transmission and reception authorization function that returns the validity or invalidity of the connection definition in response to a request from the infrastructure.

[0155] When each connection definition for user A becomes active, the service provider acquires the information necessary to provide the service (health advice) to user A. Specifically, the service server 20 of service provider Z acquires the data shown in Figure 16. For disease names and prescribed medications, the service server 20 uses data stored on infrastructure Z.

[0156] The service server 20 obtains step count, test results, and measurement values ​​from base X and base Y through data sharing.

[0157] The service server 20 sends a sharing request to the distribution control server 10 for each of the following: step count, inspection results, and measured values ​​(see Figure 7).

[0158] Upon receiving the sharing request, the connector SV of the distribution control server 10 queries the connectors X and Y corresponding to the data source infrastructures X and Y for the status of the connection definitions for each data item described in user A's consent information. The connector SV also queries the connector Z corresponding to the data sharing destination infrastructure Z for the status of the connection definitions described in user A's consent information (see Figure 20).

[0159] Each connector notifies the connector SV of the status (enabled or disabled) of user A's connection definition. Typically, each connector notifies the connector SV that the connection definition is enabled.

[0160] When each connector notifies that user A's connection definition is valid, connector SV obtains consent from the user regarding data sharing and sends a sharing instruction to the service server 20 that is the source of the data sharing.

[0161] In the example above, the connector authorizes data transmission and reception but does not directly access the linked data (data to be shared). However, the target data may be transmitted from board X to board Z via the connector. In this case, the connector will handle tasks such as identifying the source and destination boards and converting personal identification IDs during data transmission, thereby reducing the infrastructure's response costs.

[0162] As described above, the information distribution system includes a first service server 20, a second service server 20, and a distribution control server 10. The first service server 20 is managed by the first service provider and stores user data about users. The second service server 20 is managed by the second service provider and provides services to users using the user data. The distribution control server 10 controls data sharing for the second service server 20 to obtain user data from the first service server 20. The distribution control server 10 stores the first requirements (for example, a transmission policy as shown in Figure 18A) for when the first service server 20 transmits the stored user data to the second service server 20. The distribution control server 10 also stores the second requirements (for example, a reception policy as shown in Figure 18B) for when the second service server 20 receives the user data transmitted from the first service server 20. When the distribution control server 10 receives a request from the second service server 20 for data sharing regarding user data, if the stored first and second requirements are met, it instructs the first service server 20 to send the user data to the second service server 20.

[0163] Furthermore, the distribution control server 10 stores the first and second requirements for each category classified according to the characteristics of the data shared between the first service server 20 and the second service server 20 (see Figures 12A, 12B, 13A, and 13B). Also, as shown in Figures 12A and 12B, the first or second requirements include requirements regarding the trust level, which is the level of user identity verification and authentication at the first and second service providers.

[0164] The second requirement includes a requirement regarding the difference in trust levels. The distribution control server 10 generates an authentication flow if the difference in trust levels between the first service provider and the second service provider does not satisfy the requirement regarding the difference in trust levels included in the second requirement. The distribution control server 10 generates an authentication flow corresponding to the difference in trust levels included in the second requirement and requests the user to perform the generated authentication flow. The authentication flow specifies the service providers (authentication sites) through which the user will be authenticated in order.

[0165] Furthermore, if the trust level of the second service provider is higher than that of the first service provider, the distribution control server 10 generates an authentication flow starting with a third service provider whose trust level is lower by a certain level than that of the second service provider, and ending with the first service provider.

[0166] The second requirement includes a requirement regarding the frequency of checking the level difference in trust levels. The distribution control server 10 generates the above authentication flow if the requirement regarding the frequency of checking the level difference is also not met.

[0167] Next, we will describe the details of each device included in the information distribution system according to the first embodiment.

[0168] [Distribution control server] Figure 21 is a diagram showing an example of the processing configuration (processing module) of the distribution control server 10 according to the embodiment disclosed herein. Referring to Figure 21, the distribution control server 10 comprises a communication control unit 201, a user registration unit 202, an ID linkage unit 203, a location information management unit 204, a data sharing control unit 205, a connector management unit 206, a connector implementation unit 207, and a storage unit 208.

[0169] The communication control unit 201 is a means for controlling communication with other devices. For example, the communication control unit 201 receives data (packets) from the service server 20. The communication control unit 201 also transmits data to the service server 20. The communication control unit 201 passes the data received from other devices to other processing modules. The communication control unit 201 transmits the data obtained from other processing modules to other devices. In this way, other processing modules send and receive data with other devices via the communication control unit 201. The communication control unit 201 has the function of a receiving unit that receives data from other devices and the function of a transmitting unit that transmits data to other devices.

[0170] The user registration unit 202 is a means of realizing the aforementioned user registration (system registration of users). The user registration unit 202 obtains personal information (name, date of birth, contact information, etc.) from the user's terminal 30.

[0171] When the user registration unit 202 obtains the personal information, it generates a user ID to identify the user. For example, the user registration unit 202 assigns a unique value each time a user registers with the system, and uses this assigned value as the user ID.

[0172] The user registration unit 202 stores the user ID and personal information in the user information database (see Figure 22). As shown in Figure 22, the user information database stores the user ID, personal information, and personal identification ID for each service provider in association. The user information database shown in Figure 22 is an example and is not intended to limit the items to be stored. For example, the date and time of user registration may also be registered in the user information database.

[0173] The user registration unit 202 sends the generated user ID to the terminal 30.

[0174] The ID linking unit 203 is a means of realizing the aforementioned ID linking. The ID linking unit 203 receives an "ID linking request" from the service provider's terminal (for example, a hospital terminal 31) or the service server 20. The ID linking request includes the user's personal identification information, personal identification ID, and business code, who wishes to link their ID (register with the service provider).

[0175] The ID linking unit 203 searches the user information database using personally identifiable information (such as the user's name or a combination of name and date of birth) as a key to identify the corresponding user. The ID linking unit 203 sets the personally identifiable ID included in the ID linking request in the field corresponding to the business code among the personally identifiable ID fields of the identified user. In other words, the ID linking unit 203 identifies the user registered in the system account from the personally identifiable information and associates the service provider and the personally identifiable ID in the account of the identified user.

[0176] The location information management unit 204 is a means of managing location information obtained from service providers (infrastructure providers). The location information management unit 204 stores the location information obtained from each service server 20 in the location information database (see Figure 23). As shown in Figure 23, the location information database stores personal identification IDs, business codes, and data types in association.

[0177] Please note that the location information database shown in Figure 23 is an example and is not intended to limit the items to be stored. For example, the date and time the location information was registered may also be registered in the location information database. Also, in the diagrams including Figure 23, the business operator code is represented using the name of the service provider for ease of understanding.

[0178] The data sharing control unit 205 is a means for controlling data sharing.

[0179] The data sharing control unit 205 receives a sharing request from the service server 20. The sharing request includes the personal identification ID of the user whose data is to be acquired, the business code of the sender of the sharing request, and the type of data to be acquired. In the example in Figure 7, the sharing request includes the personal identification ID generated by EC business B (service server 20) for user U1, the business code of EC business B, and "disease name" as the data type. The sharing request may also include the business code of the data accumulator (data sharer).

[0180] The data sharing control unit 205 identifies the recipients of the data distribution based on the personal identification ID and business code included in the sharing request. Specifically, the data sharing control unit 205 refers to the user information database shown in Figure 22 to identify the recipients. In the example above, when the data sharing control unit 205 receives a sharing request from EC business B that includes the personal identification ID "EC01", it recognizes from the first entry in Figure 22 that user U1 is a recipient of the data distribution.

[0181] Subsequently, the data sharing control unit 205 identifies the service provider that stores the necessary data using the identified user's personal identification ID and the data type included in the sharing request. Specifically, the data sharing control unit 205 refers to the location information database shown in Figure 23 and identifies the service provider (infrastructure provider) that stores data corresponding to the data type included in the sharing request. In the above example, hospital A is identified based on user U1's personal identification ID "HL01" and the data type "disease name" included in the sharing request.

[0182] Furthermore, if the combination of the user's personal identification ID and the data type included in the sharing request is not stored in the location information database, the data sharing control unit 205 sends a negative response to the sender of the sharing request indicating that data sharing is not possible. In the example above, if the combination of user U1's personal identification ID "HL01" and data type "disease name" is not registered in the location information database, a negative response is sent to EC business operator B (service server 20).

[0183] Once the data recipients and data accumulators are identified, the data sharing control unit 205 notifies the connector management unit 206 of the information of the data recipients, the target data, the information of the data accumulator (data sharing source), and the information of the data sharing destination. For example, in the above example, the data sharing control unit 205 notifies the connector management unit 206 of user A's personal identification ID, "steps" as the target data, the business code of base X (data sharing source), and the business code of base Z (data sharing destination). The data sharing control unit 205 then queries the connector management unit 206 about the status of user A's connection definition for each data included in user A's consent information.

[0184] When the connector management unit 206 notifies the data sharing control unit 205 that the connection definition is invalid, the data sharing control unit 205 sends a negative response to the sender of the sharing request indicating that data sharing is not possible.

[0185] When the connector management unit 206 notifies the data that the connection definition is valid for each data, the data sharing control unit 205 sends a data sharing inquiry to the data recipient. Specifically, the data sharing control unit 205 sends an inquiry regarding data sharing to the contact information of the data recipient. In the example above, the inquiry is sent to the terminal 30 owned by user U1.

[0186] The data sharing inquiry includes information such as the source of the data sharing request, the data storage entity, and the type of data to be shared. The data sharing control unit 205 receives the response to the data sharing inquiry from the terminal 30.

[0187] If the user refuses to share data, the data sharing control unit 205 notifies the data sharing requestor that data sharing is not possible.

[0188] If the user agrees to data sharing, the data sharing control unit 205 sends a sharing instruction to the data storage entity (data sharing source).

[0189] A sharing instruction includes a personal identification ID generated by the data accumulator, information about the data sharing destination, and the type of data to be shared. In the example above, a sharing instruction containing user U1's personal identification ID "HL01", the address of EC business B's service server 20, and the data type "disease name" is sent to hospital A's service server 20.

[0190] In this manner, the data sharing control unit 205 transmits a sharing instruction that includes the personal identification ID of the user (target person) who has consented to data sharing, which is a personal identification ID generated by the data accumulator.

[0191] The connector management unit 206 is a means for managing connectors. The connector management unit 206 implements the functions of the connector SV described above.

[0192] The connector implementation unit 207 is a means for implementing a connector. The connector implementation unit 207 implements the functions of the connector described above.

[0193] The connector management unit 206 obtains infrastructure information from the infrastructure provider's representative. When the connector management unit 206 obtains the infrastructure provider's name, provider code, trust level, etc., it stores the obtained information as "infrastructure information". For example, the connector management unit 206 obtains infrastructure information as shown in Figure 9.

[0194] Once the infrastructure information is stored, the connector management unit 206 instructs the connector implementation unit 207 to generate a connector corresponding to the newly registered infrastructure. For example, the connector management unit 206 passes the name and code of the infrastructure provider to the connector implementation unit 207 and instructs it to generate a connector corresponding to that infrastructure provider (infrastructure).

[0195] In response to the instruction, the connector implementation unit 207 generates a connector corresponding to the new substrate. For example, the connector implementation unit 207 generates a virtual machine or container and implements the connector function described above using the generated virtual machine or container.

[0196] The connector management unit 206 (connector SV) collects data handled by infrastructure operators. For example, the connector management unit 206 obtains the types of data handled by infrastructure operator Z from the person in charge (infrastructure terminal 32) of infrastructure operator Z. The connector management unit 206 registers the obtained data types in the infrastructure information of the corresponding infrastructure.

[0197] Furthermore, the connector management unit 206 provides the newly registered infrastructure provider with infrastructure information and data types handled by other infrastructures, and requests that infrastructure provider categorize the data distributed on the information distribution platform. Specifically, the connector management unit 206 transmits the infrastructure information for each infrastructure, as shown in Figure 9, to the infrastructure terminal 32 of the infrastructure provider that registered the infrastructure.

[0198] The connector management unit 206 obtains the results of categorizing the data to be distributed from the base terminal 32. The connector management unit 206 then passes the obtained results to the corresponding connector (connector implementation unit 207).

[0199] The connector implementation unit 207 (connector) stores the acquired information as a "linked data category". For example, each connector implementation unit 207 stores the received information as a linked data category (see Figures 11A and 11B).

[0200] The connector management unit 206 obtains the receive policy definition and the transmit policy definition related to data transmission and reception from the infrastructure operator's representative (the infrastructure terminal 32 used by the representative). For example, the connector management unit 206 obtains the receive policy definition and the transmit policy definition as shown in Figures 12A and 12B.

[0201] The connector management unit 206 passes the acquired receive policy definition and transmit policy definition to the corresponding connector implementation unit 207. The connector implementation unit 207 (each connector) stores the acquired receive policy definition and transmit policy definition (see Figures 12A, 12B, 13A, and 13B).

[0202] The connector management unit 206 obtains the shared definition from the service provider's service terminal 33. The connector management unit 206 instructs the connector implementation unit 207 to perform a policy check on the obtained shared definition. The connector management unit 206 hands over the obtained shared definition to the connector implementation unit 207.

[0203] The connector implementation unit 207 determines whether it is possible to send and receive data that is subject to data sharing in a connector that corresponds to a data source included in the shared definition but is not on the same board. For example, the connector implementation unit 207 (each connector) verifies whether the transmission of data that is required to be shared with other boards is prohibited.

[0204] The connector implementation unit 207 (connector) notifies the connector management unit 206 of the verification results (policy check results). The connector management unit 206 sends the notified check results to the service server 20.

[0205] The connector management unit 206 obtains user consent information from the service server 20. Upon obtaining the consent information, the connector management unit 206 instructs the connectors (connector implementation unit 207) of both the data sharing source and data sharing destination for each data item described in the consent information to generate connection definitions.

[0206] The connector implementation unit 207 (each connector) refers to the corresponding infrastructure's linked data category and identifies the data type category described in the consent information. The connector implementation unit 207 refers to the corresponding infrastructure's receive policy definition and transmit policy definition and obtains the receive policy and transmit policy for the identified category. The connector implementation unit 207 generates a connection definition using the obtained receive policy and transmit policy.

[0207] The connector management unit 206 receives an authentication success notification from the service server 20, which includes the user's personal identification ID and service name. The connector management unit 206 instructs the connector implementation unit 207 (each corresponding connector) to verify the connection definition for the data that is subject to data sharing in the user's consent information, corresponding to the personal identification ID and the received service name.

[0208] The connector implementation unit 207 (each connector) identifies the connection definition of the user to be verified using a personal identification ID, etc., and determines whether the requirements described in the identified connection definition are met. The connector implementation unit 207 also determines whether the requirements regarding the level difference of the trust level and the requirements regarding the frequency of checking the level difference are met.

[0209] The connector implementation unit 207 (each connector) notifies the connector management unit 206 (connector SV) of the verification result (valid or invalid connection definition). If the connection definition is invalid, the connector implementation unit 207 passes the invalid connection definition to the connector management unit 206 and requests the connector management unit 206 (connector SV) to activate the connection definition.

[0210] The connector management unit 206 executes a process to activate an invalid connection definition. Specifically, the connector management unit 206 sets up an "authentication flow" to satisfy the requirements described in the invalid connection definition and requests the user to perform the configured authentication flow.

[0211] When the connector management unit 206 generates the authentication flow described above, it requests the user to perform the authentication flow. Specifically, the connector management unit 206 sends an "authentication request notification" containing the URL of the trust level matching site to the user's terminal 30.

[0212] When terminal 30 accesses the trust level matching site, the connector management unit 206 redirects the terminal 30's connection in the order of the authentication flow generated above. When the terminal 30's connection is redirected from the infrastructure authentication site at the end of the authentication flow, the connector management unit 206 determines that the user's authentication flow has been completed (successfully executed).

[0213] Once the authentication flow is completed, the connector management unit 206 notifies the connector implementation unit 207 (the corresponding connector) of this fact. Upon notification of the completion of the authentication flow, the connector implementation unit 207 (the connector that requested the activation of the connection definition) determines that the previously invalid connection definition has been activated. The connector implementation unit 207 (the corresponding connector) sets the status of the activated connection definition to "enabled" and stores the date of activation.

[0214] When the authentication flow is successfully completed, the connector management unit 206 notifies the service server 20 that each connection definition has become valid.

[0215] The connector management unit 206 obtains information on the data distribution target, target data, data storage entity (data sharing source), and data sharing destination from the data sharing control unit 205. Upon obtaining this information, the connector management unit 206 hands over the obtained information to the connector implementation unit 207 and queries the connector implementation unit 207 for the status of the connection definition of the data distribution target.

[0216] The connector implementation unit 207 (corresponding connector) identifies the connection definition to be verified based on the personal identification ID, the business code of the data sharing source, etc., and notifies the connector management unit 206 of the status (enabled, disabled) of the identified connection definition.

[0217] The connector management unit 206 notifies the data sharing control unit 205 of notifications (connection definition status) from each connector.

[0218] The memory unit 208 stores information necessary for the operation of the distribution control server 10.

[0219] [Service Server] Figure 24 is a diagram showing an example of the processing configuration (processing module) of the service server 20 according to the embodiment disclosed herein. Referring to Figure 24, the service server 20 comprises a communication control unit 301, an account control unit 302, an ID linkage control unit 303, a service control unit 304, a data storage control unit 305, a data sharing unit 306, and a storage unit 307.

[0220] The communication control unit 301 is a means for controlling communication with other devices. For example, the communication control unit 301 receives data (packets) from the distribution control server 10. The communication control unit 301 also transmits data to the distribution control server 10. The communication control unit 301 passes the data received from other devices to other processing modules. The communication control unit 301 transmits the data acquired from other processing modules to other devices. In this way, other processing modules send and receive data with other devices via the communication control unit 301. The communication control unit 301 has the function of a receiving unit that receives data from other devices and the function of a transmitting unit that sends data to other devices.

[0221] The account control unit 302 is a means for performing controls related to a user's account.

[0222] The account control unit 302 performs identity verification and authentication as predetermined by the service provider (infrastructure provider). The account control unit 302 performs identity verification according to the identity verification level determined by the service provider. If identity verification is successful, the account control unit 302 creates an account for the user and stores the personal identification ID, etc., in the created account.

[0223] Please note that a detailed explanation regarding identity verification will be omitted, as the specific details of identity verification are inconsistent with the purpose of this disclosure.

[0224] The ID linkage control unit 303 is a means for controlling user ID linkage. The ID linkage control unit 303 obtains ID linkage requests from users who are logged into their accounts using a GUI (Graphical User Interface), etc. In response to the user's request, the ID linkage control unit 303 sends an "ID linkage request" to the distribution control server 10, which includes personally identifiable information (such as the logged-in user's name), a personal identification ID (such as the user's membership number), and a business code.

[0225] Furthermore, the user's personal identification ID, personal identification information, and user data are managed using the customer information database (see Figure 25). As shown in Figure 25, the customer information database holds information (flags) indicating whether or not the user's ID linking has been completed. When the ID linking control unit 303 completes the ID linking, it sets a flag in the corresponding user's ID linking status field (in Figure 25, "○" is set).

[0226] The service control unit 304 is a means for controlling services provided to users.

[0227] For example, the service control unit 304 obtains information regarding the data (data type) and data source (data source) necessary for providing the service from the service terminal 33 as a shared definition. After obtaining the shared definition, the service control unit 304 sends the obtained shared definition to the distribution control server 10 to request a policy check of the shared definition.

[0228] The service control unit 304 notifies the person in charge of the results of the policy check. The service control unit 304 accepts the modification of the shared definition by the person in charge and requests the distribution control server 10 to perform a policy check on the modified shared definition again.

[0229] The service control unit 304 stores the shared definitions that have passed the policy check.

[0230] The service control unit 304 presents a shared definition corresponding to the service to a user who wishes to receive the service. The service control unit 304 identifies data that the user refuses to be used in providing the service. The service control unit 304 removes the data that the user refuses to use from the shared definition and generates the user's consent information (shared definition for the user).

[0231] The service control unit 304 sends the generated shared definition and the user's personal identification ID, etc., to the distribution control server 10 and requests the generation of the user's "connection definition".

[0232] The service control unit 304 has a function to authenticate users attempting to log in to an account. The service control unit 304 performs authentication processing according to a predetermined authentication level. The service control unit 304 implements an authentication site for authenticating users.

[0233] Detailed explanations regarding the identity verification process are omitted, as the specific details of the identity verification process differ from the intent of this disclosure.

[0234] When authentication is successful for a user who has accessed the authentication site using terminal 30 that has not been redirected from a trust level-aligned site, the service control unit 304 notifies the distribution control server 10 of the user's information and information regarding the services to be provided to that user. Specifically, the service control unit 304 sends an authentication success notification to the distribution control server 10, which includes the user's personal identification ID and the name of the services to be provided.

[0235] When authentication is successful for a user who accessed the authentication site using terminal 30 redirected from the trust level matching site, the service control unit 304 redirects the connection of terminal 30 to the trust level matching site.

[0236] When the distribution control server 10 notifies the service control unit 304 that the user's connection definition is valid, the service control unit 304 obtains the information necessary to provide the service to the user.

[0237] Specifically, the service control unit 304 refers to the customer information database and retrieves data stored on its own infrastructure. For data not stored on its own infrastructure, the service control unit 304 retrieves it through data sharing. Specifically, the service control unit 304 sends a sharing request to the distribution control server 10 that includes the personal identification ID of the user whose data is to be retrieved, the business code of its own infrastructure, and the type of data to be retrieved.

[0238] The service control unit 304 provides services to users using the acquired data. A detailed explanation of the specific service provision methods is omitted here, as they differ from the intent of this disclosure.

[0239] The data storage control unit 305 is a means for controlling the storage of user data that results from providing services to users. The data storage control unit 305 stores the user's personal identification ID and the user's user data (data resulting from providing services to the user, or data necessary for the services provided to the user) in the customer information database.

[0240] As shown in Figure 25, the data storage control unit 305 stores user data (stores specific data content) in fields corresponding to the type of data generated.

[0241] Here, for users whose ID linkage has been completed, the data storage control unit 305 sends location information to the distribution control server 10 each time it stores user data in the customer information database. For example, when a service is provided to a user with personal identification ID "HL01" and disease name data is generated as a result of the examination, location information including personal identification ID "HL01", business code "Hospital A", and data type "Disease Name" is sent to the distribution control server 10.

[0242] The data sharing unit 306 is a means of realizing data distribution through "sharing". The data sharing unit 306 processes the "sharing instruction" received from the distribution control server 10.

[0243] When a sharing instruction is received, the data sharing unit 306 refers to the customer information database and identifies the entry corresponding to the personal identification ID and data type included in the sharing instruction. For example, when a sharing instruction is received that includes the personal identification ID "HL01" and the data type "Disease Name", the data sharing unit 306 identifies the entry shown at the top of Figure 25.

[0244] The data sharing unit 306 sends the user data described in the corresponding data type field of the identified entry to the data sharing destination specified in the sharing instruction. In the example in Figure 7, "stomach cancer" is sent to the service server 20 of EC business operator B.

[0245] The memory unit 307 stores information necessary for the operation of the service server 20.

[0246] [Terminals, hospital terminals, infrastructure terminals, service terminals] Examples of terminals 30 include mobile devices such as smartphones and tablets, and computers (personal computers, laptops). Terminals 30 can be any device or equipment as long as they can receive user input and communicate with the distribution control server 10, etc. Furthermore, the configuration of terminals 30, etc. is obvious to those skilled in the art, so a detailed explanation is omitted.

[0247] As described above, in the information distribution system according to the first embodiment, a policy is defined for each category of data shared between infrastructures, specifying the extent to which differences in trust levels (identity verification level, user authentication level) are acceptable. If this policy is not met, data sharing (sending and receiving data) will not occur. As a result, the risk of privacy leakage is reduced according to the confidentiality of the data. In other words, the information distribution system according to the first embodiment provides a mechanism that allows service providers on infrastructures with a high level of identity verification to trust the accuracy of data received from infrastructures with a low level of identity verification. Furthermore, the information distribution system provides a mechanism that ensures that data transmitted by service providers on infrastructures with a high level of user authentication to infrastructures with a low level of user authentication has been correctly received by the intended user (and used for the benefit of the intended user).

[0248] Furthermore, the information distribution system generates the minimum necessary authentication flow using the authentication sites held by each data linkage platform in order to reconcile the different trust levels (content of identity verification and authentication) between platforms. As a result, the burden on users for reconciliation is optimized. In addition, the authentication flow starts with an authentication site with a high trust level, and the distribution control server 10 requires users to be authenticated at that authentication site. This rule is set based on the prediction that a person who has been correctly authenticated on a platform with a high trust level is unlikely to be a malicious person because their identity is clear.

[0249] Furthermore, an authentication flow is periodically executed to align the trust level (authentication level) according to the sending and receiving policies, thus reducing the risk of impersonation on a low-trust-level infrastructure.

[0250] Next, we will describe the hardware of each device that makes up the information distribution system. Figure 26 shows an example of the hardware configuration of the distribution control server 10.

[0251] The distribution control server 10 can be configured using an information processing device (a so-called computer), and has the configuration illustrated in Figure 26. For example, the distribution control server 10 includes a processor 311, memory 312, input / output interface 313, and communication interface 314, etc. The components of the processor 311, etc., are connected by an internal bus or the like and are configured to communicate with each other.

[0252] However, the configuration shown in Figure 26 is not intended to limit the hardware configuration of the distribution control server 10. The distribution control server 10 may include hardware not shown, and it may not have to have an input / output interface 313 if necessary. Also, the number of processors 311 etc. included in the distribution control server 10 is not intended to be limited to the example in Figure 26; for example, multiple processors 311 may be included in the distribution control server 10.

[0253] The processor 311 is a programmable device such as a CPU (Central Processing Unit), MPU (Micro Processing Unit), or DSP (Digital Signal Processor). Alternatively, the processor 311 may be a device such as an FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit). The processor 311 executes various programs, including an operating system (OS).

[0254] Memory 312 includes RAM (Random Access Memory), ROM (Read Only Memory), HDD (Hard Disk Drive), SSD (Solid State Drive), etc. Memory 312 stores the OS program, application programs, and various data.

[0255] The input / output interface 313 is an interface for a display device or input device (not shown). The display device is, for example, a liquid crystal display. The input device is, for example, a device that accepts user input such as a keyboard or mouse.

[0256] The communication interface 314 is a circuit, module, etc., that communicates with other devices. For example, the communication interface 314 includes a NIC (Network Interface Card), etc.

[0257] The functions of the distribution control server 10 are realized by various processing modules. These processing modules are realized, for example, by the processor 311 executing a program stored in memory 312. The program can also be recorded on a computer-readable storage medium. The storage medium can be a non-transitory medium such as semiconductor memory, hard disk, magnetic recording medium, or optical recording medium. In other words, the present invention can also be embodied as a computer program product. Furthermore, the program can be downloaded via a network or updated using the storage medium on which the program is stored. Moreover, the processing module may be realized by a semiconductor chip.

[0258] Furthermore, the service server 20 and other similar devices can also be configured using information processing equipment, just like the distribution control server 10. Since their basic hardware configuration is identical to that of the distribution control server 10, a detailed explanation will be omitted.

[0259] The distribution control server 10, which is an information processing device, is equipped with a computer, and its functions can be realized by having the computer execute a program. Furthermore, the distribution control server 10 executes its control method using this program.

[0260] [Differentiation] The configuration and operation of the information distribution system described in the above embodiment are illustrative examples and are not intended to limit the system's configuration.

[0261] In the above embodiment, the case in which the user information database is configured inside the distribution control server 10 was described, but the database may be built on an external database server or the like. In other words, some functions of the distribution control server 10 may be implemented on another server. More specifically, it is sufficient that the "data sharing control unit (data sharing control means)" etc. described above is implemented on any device included in the system.

[0262] The form of data transmission and reception between each device (e.g., distribution control server 10, service server 20) is not particularly limited, but the data transmitted and received between these devices may be encrypted. Personal information of users is transmitted and received between these devices, and in order to properly protect this information, it is desirable that encrypted data be transmitted and received.

[0263] In the flowcharts (sequence diagrams) used in the above description, multiple processes (processes) are shown in order, but the execution order of the processes performed in the embodiment is not limited to the order in which they are shown. In the embodiment, the order of the illustrated processes can be changed to the extent that it does not impair the content, for example, by executing each process in parallel.

[0264] The embodiments described above are explained in detail to facilitate understanding of the disclosure, and it is not intended that all the configurations described above are necessary. Furthermore, when multiple embodiments are described, each embodiment may be used individually or in combination. For example, it is possible to replace parts of the configuration of one embodiment with those of another embodiment, or to add configurations from other embodiments to the configuration of one embodiment. In addition, it is possible to add, delete, or replace parts of the configuration of one embodiment with those of another.

[0265] From the above description, the industrial applicability of the present invention is clear, and the present invention can be suitably applied to an information distribution system that distributes accumulated data related to services provided to users, and the like.

[0266] Part or all of the above-described embodiments may also be described as in the following appendices, but are not limited to the following.

[0267] [Appendix 1] a first service server managed by a first service provider and configured to store user data related to a user; a second service server managed by a second service provider and configured to provide a service to the user using the user data; a distribution control server configured to control data sharing for the second service server to acquire the user data from the first service server; comprising, wherein the distribution control server stores a first requirement for when the first service server transmits the stored user data to the second service server; stores a second requirement for when the second service server receives the user data transmitted from the first service server; upon receiving a data sharing request related to the user data from the second service server, instructs the first service server to transmit the user data to the second service server when the stored first and second requirements are satisfied.

[0268] [Appendix 2] The system according to Appendix 1, wherein the distribution control server stores the first and second requirements for each category classified according to characteristics of data shared between the first service server and the second service server.

[0269] [Appendix 3] The system according to Appendix 2, wherein the first requirement or the second requirement includes a requirement relating to a trust level that is a level of identity verification and a level of personal authentication of the user at the first service provider and the second service provider.

[0270] [Appendix 4] The second requirement includes a requirement relating to a level difference of the trust level, When a level difference between the trust level of the first service provider and the trust level of the second service provider does not satisfy the requirement relating to the level difference of the trust level included in the second requirement, the distribution control server generates an authentication flow corresponding to the level difference of the trust level included in the second requirement, and requests the user to execute the generated authentication flow, The system according to Appendix 3, wherein the authentication flow defines service providers for the user to sequentially undergo authentication.

[0271] [Appendix 5] The system according to Appendix 4, wherein when the trust level of the second service provider is higher than the trust level of the first service provider, the distribution control server generates the authentication flow starting from a third service provider having a trust level lower than the trust level of the second service provider by the level difference and ending at the first service provider.

[0272] [Appendix 6] The system according to Appendix 4 or 5, wherein the second requirement includes a requirement relating to a confirmation frequency of the level difference of the trust level.

[0273] [Appendix 7] a first service server that is managed by a first service provider and stores user data relating to a user; a second service server that is managed by a second service provider and provides a service to the user using the user data; and A distribution control server controls data sharing for the second service server to acquire the user data from the first service server, Includes, The distribution control server, The first service server stores the first requirements for transmitting the stored user data to the second service server. The system stores the second requirement for when the second service server receives user data transmitted from the first service server. A method for receiving a data sharing request regarding user data from the second service server, and instructing the first service server to transmit the user data to the second service server if the stored first and second requirements are met.

[0274] Furthermore, some or all of the configurations described in Appendices 2 to 6, which are dependent on Appendice 1 above, may also be dependent on Appendice 7 in the same manner as those described in Appendices 2 to 6. Moreover, not limited to Appendices 1 and 7, some or all of the configurations described as appendices may also be dependent on various hardware, software, various recording means for recording software, or systems, without departing from the embodiments described above.

[0275] Furthermore, each disclosure of the above-mentioned prior art documents cited herein is incorporated herein by reference. Although embodiments of the present invention have been described above, the present invention is not limited to these embodiments. It will be understood by those skilled in the art that these embodiments are merely illustrative and that various modifications are possible without departing from the scope and spirit of the present invention. That is, the present invention naturally includes the entire disclosure, including the claims, and various modifications and alterations that can be made by those skilled in the art in accordance with the technical idea. [Explanation of Symbols]

[0276] 10 Distribution control server 20 Service Servers 30 devices 31 Hospital terminals 32 Base Terminals 33 Service Terminals 101 First Service Server 102 Second service server 103 Distribution control server 201 Communication Control Unit 202 User Registration Section 203 ID Linking Department 204 Location Information Management Department 205 Data Sharing Control Unit 206 Connector Management Department 207 Connector Implementation Section 208 Storage section 301 Communication Control Unit 302 Account Control Unit 303 ID Linkage Control Unit 304 Service Control Unit 305 Data Storage Control Unit 306 Data Sharing Section 307 Storage section 311 Processors 312 memory 313 Input / Output Interfaces 314 Communication Interface

Claims

1. A first service server, managed by the first service provider and storing user data about the user, A second service server, managed by a second service provider, provides services to the user using the user data, A distribution control server controls data sharing for the second service server to acquire the user data from the first service server, Includes, The aforementioned distribution control server is The first service server stores the first requirements for transmitting the stored user data to the second service server. The second requirement for the second service server to receive user data transmitted from the first service server is stored. A system that, upon receiving a data sharing request regarding user data from the second service server, instructs the first service server to transmit the user data to the second service server if the stored first and second requirements are met.

2. The system according to claim 1, wherein the distribution control server stores the first and second requirements for each category classified according to the characteristics of the data shared between the first service server and the second service server.

3. The system according to claim 2, wherein the first or second requirement includes a requirement relating to the trust level, which is the level of identity verification and authentication of the user at the first and second service providers.

4. The second requirement mentioned above includes a requirement relating to the level difference of the trust level, If the difference in trust levels between the first service provider and the second service provider does not satisfy the requirements regarding the difference in trust levels included in the second requirement, the distribution control server will... Generate an authentication flow corresponding to the level difference of the trust level included in the second requirement, and request the user to perform the generated authentication flow. The system according to claim 3, wherein the authentication flow specifies the service providers from whom the user is authenticated in order.

5. The system according to claim 4, wherein the distribution control server generates the authentication flow starting with a third service provider having a trust level lower by the amount of the trust level difference from the second service provider, and ending with the first service provider, if the trust level of the second service provider is higher than the trust level of the first service provider.

6. The system according to claim 4 or 5, wherein the second requirement includes a requirement regarding the frequency of checking the level difference of the trust level.

7. A first service server, managed by the first service provider and storing user data about the user, A second service server, managed by a second service provider, provides services to the user using the user data, A distribution control server controls data sharing for the second service server to acquire the user data from the first service server, Includes, The distribution control server, The first service server stores the first requirements for transmitting the stored user data to the second service server. The second requirement for the second service server to receive user data transmitted from the first service server is stored. A method in which, upon receiving a data sharing request regarding user data from the second service server, the first service server is instructed to transmit the user data to the second service server if the stored first and second requirements are met.

Images