JP5090425B2 - Information access control system and method - Google Patents

Description

  The present invention provides information access for realizing a service in which the user or a third party authorized by the person accesses and acquires user information stored in a database held by, for example, a medical institution, health-related institution, or local government. The present invention relates to a control system and method.

In recent years, EHR (Electronic Health Record) aims to provide integrated medical services and health services by interconnecting and sharing information related to medical care and health held by multiple medical institutions, health-related organizations, and local governments via communication networks. ) A system has been proposed.
The EHR system handles medical and health related information related to personal privacy. Privacy-related information can lead to serious damage to individuals, and its distribution and disclosure must be kept to a minimum. For this reason, in a conventional system that handles personal information, the identity verification is performed by the authentication technique, and the information related to the principal is basically referred to only by the principal.

  However, in order for everyone in the country to be able to use EHR, it is not sufficient that only the person can view information related to the person. For example, in the case of an infant, an elderly person, etc., it is necessary to allow a proxy delegated by the principal to operate on behalf of the principal. Also, in a situation where only the person can view medical and health related information, it is difficult to utilize the medical and health related information, and it is difficult to realize an integrated medical service rooted in the region aimed at in modern Japan. For example, it is not possible to obtain useful information from the viewer after having the other person browse the information, for example, having a doctor fully browse his / her information and receiving diagnosis and guidance. In order to make use of the information related to the medical health of the person, the person who wants to disclose information needs to have a mechanism that can be disclosed easily and without error.

  Therefore, the inventors set an access control rule that defines the disclosure conditions for the medical health related information for each user, and sets the identifier of the third party user who has permitted the disclosure of the medical health related information in the access control rule. A system for registering and determining whether or not to disclose information based on the access control rule when an information acquisition request is sent from a third party user is proposed.

  However, in order to access personal information, it is necessary to acquire the identification information (user ID) of the owner by some method. Also, when registering a user ID of a third party permitted to disclose information, the user ID of the third party must be acquired by some method.

As a method for acquiring a third party user ID, for example, the following method is available. That is, when a business user list (for example, a list of patients in charge) such as doctors and public health nurses is prepared like EHR, the user himself / herself browses his / her medical / health related information from the business user list. The user ID is selected and the user ID is registered in the access control list. However, an unspecified number of users, such as general citizens, can obtain a user ID by specifying a doctor, a public health nurse, etc. from a business user list whose use range is limited to only within the system. It is not allowed from the viewpoint of protecting the teacher's user ID. Therefore, it is difficult to specify a user safely within the system.
On the other hand, when the general public designates his / her agent, it cannot be searched from the business user list as described above. In addition, searching for other citizens by name or the like from the user list managed by the system is not permitted from the viewpoint of personal information protection. Even if the search results are handled after narrowing down to one case, for example, when there is a user with the same surname and the same name, there is a possibility of an erroneous search, which is very undesirable.

  Another method for specifying a registered user on the system is to specify a third-party user in the groupware. This method assumes that only a specific user who can be trusted such as a company uses, and assumes that each user discloses his / her login ID, name, affiliation, etc., and allows other users to refer to it. For this reason, a third party user on the system can be specified by directly specifying a name and a login ID (see, for example, Non-Patent Document 1).

  Further, as another method, there is an other user designation method in an SNS (Social Network Service) service. In this method, a large number of unspecified users disclose their personal information (profiles) such as their nicknames, names, genders, and photos, and allow others to refer to them. For this reason, it becomes possible to search the other user etc. with the taste close | similar to oneself based on a profile etc. (for example, refer nonpatent literature 2).

Cybozu, Internet <URL: http://manual.cybozu.co.jp/office8/user/ GREE, Internet <URL: http://www.gree.co.jp/privacy/

  However, the method described in Non-Patent Document 1 is based on the premise that a registered user can be trusted, and a service used by an unspecified number of unknown users has a problem in terms of safety with respect to personal information. Can not. Further, the method described in Non-Patent Document 2 can be used only for a service such as SNS, which is intended for the exchange between users and on the premise that a part of personal information is disclosed.

  The present invention has been made paying attention to the above circumstances, and the object of the present invention is to safely designate a desired user on the system without disclosing information for identifying the user or allowing an unlimited search. It is an object of the present invention to provide an information access control system and method that make it possible.

In order to achieve the above object, a first aspect of the present invention provides information for identifying the first user from the terminal of the second user with respect to the personal information of the first user stored in the server device. In order to specify the first user for the access in response to the issue request transmitted from the terminal of the first user, the information access control system is accessed using Issue an encrypted temporary user specifier to use. In this temporary user designator, in addition to the information for identifying the user of the issue request source, the attribute information of the issue request source user and the server device from which the issuer of the temporary user specifier is issued are specified. At least one of identification information and presentation information to be presented to the solution requesting user is included. Next, in response to a resolution request transmitted from the terminal of the second user, the encrypted temporary user specifier included in the resolution request is decrypted to identify the first user The information is converted into information, and the personal information of the first user is accessed using the converted information for identifying the first user.

Accordingly, the information for identifying the first user necessary for accessing the personal information of the first user is issued as a temporary user designator in response to the request of the first user himself / herself. Can be safely passed from the first user to the second user without being retrieved or retrieved. By requesting the system to resolve the passed temporary user specifier, the second user can reliably specify the first user on the system and access the personal information.
In addition to the information for identifying the user of the issue request source, the temporary user specifier specifies the attribute information of the issue request source user and the server device that is the issue source of the temporary user specifier. And at least one of identification information to be presented and presentation information to be presented to the solution requesting user. For this reason, when the user attribute is included, for example, when setting information for identifying the second user in the access control rule, the user attribute information of the second user, for example, the organization or qualification, etc. It is possible to set information to represent. In addition, when the identification information for identifying the server device that is the issuer of the temporary user specifier is included, not only the server of the temporary user specifier issuer but also any server that has been linked with the authentication It is possible to accept a solution request. Further, when presentation information to be presented to the solution request source user is included, for example, a nickname or a question input from the issuer user is presented to the solution request source user during the temporary user designator resolution process. It is possible to make confirmations and request answers to questions.

  On the other hand, according to a second aspect of the present invention, access to the personal information is permitted from the terminal of the first user according to an access control rule defined for the personal information of the first user stored in the server device. An information access control system having a function of setting information for identifying a second user, and first identifying the second user in response to an issuance request transmitted from the terminal of the second user An encrypted temporary user designator that is used by the first user to designate the second user for setting information to be issued is issued. Next, in response to a resolution request transmitted from the terminal of the first user, the encrypted temporary user specifier included in the resolution request is decrypted to identify the second user The information is converted into information, and the information for identifying the converted second user is set in the access control rule.

  Therefore, the identification information of the second user for setting in the access control rule corresponding to the personal information of the first user is issued as a temporary user designator in response to the request of the second user. For this reason, the identification information of the second user is safely passed to the first user without being disclosed or searched. In addition, the first user requests the resolution of the passed temporary user specifier, so that the second user is surely specified on the system and the identification information is set in the access control rule of the first user. can do.

The first and second aspects of the present invention are characterized by comprising the following aspects.
In the first aspect, the issuing means issues a temporary user designator that encrypts the pseudonym associated with the identifier of the user who issued the issue request on the system, and the solving means sends the issued encrypted temporary After the user specifier is decrypted and converted into the kana, the converted kana is converted into the identifier of the user who issued the issue request.
In this way, even if the secret key used to decrypt the encrypted temporary user designator leaks and the temporary user designator is decrypted by a third party, the actual key used on the system is It is possible to avoid a risk that the ID (user ID or login ID) is known to a third party.

According to a second aspect, the issuing means includes information representing the validity period in the temporary user designator, and the solving means uses the information representing the validity period included in the decrypted temporary user designator based on the information representing the validity period. The temporary user designator is determined to be valid or invalid.
If it does in this way, the effective period can be set according to the use of a temporary user designator. For example, in the case of a doctor or the like, since there are a plurality of recipients to whom a temporary user designator is passed, by issuing a temporary user designator with a long expiration date, a temporary user designation is made for each of a plurality of partners each time. Compared with the case where a child is issued, the burden on the user can be reduced.

In a third aspect, the resolving means is provided with a revocation list storage means, and in response to a revocation registration request transmitted from the terminal, the temporary user designator designated by the revocation registration request is stored in the revocation list storage means. . Then, when the resolution request is received, it is determined whether or not the temporary user specifier decrypted in response to the request is stored in the revocation list storage means. Is made invalid.
In this way, when the temporary user designator is lost or misused, the temporary user designator can be suspended or abolished.

In a fourth aspect, the resolution means further includes a function of deleting the temporary user designator designated by the revocation deletion request from the revocation list storage means in response to the revocation deletion request transmitted from the terminal. It is a thing.
If it does in this way, it will become possible to restart use of the temporary user designator which suspended use temporarily.

In the fifth aspect, the issuing means signs the temporary user designator using the private key owned by the issuing means, and the resolution means pairs the decrypted temporary user designator signature with the private key. The verification is performed using the public key to be made.
In this way, it is possible to perform signature verification for the temporary user designator during the resolution process, thereby improving security when the temporary user designator is lost.

  In other words, according to the present invention, there is provided an information access control system and method capable of safely specifying a desired user on the system without disclosing information for identifying the user or allowing an unlimited search. be able to.

It is a block diagram which shows the function structure of the system for enforcing the user designation | designated method concerning one Embodiment of this invention. It is a figure which shows the component of the temporary user designator (TUS) used with the system shown in FIG. It is a figure which shows the kind of temporary user designator (TUS) used with the system shown in FIG. It is a figure which shows the function structure of the TUS issuing means provided in the Web cooperation server of the system shown in FIG. It is a figure which shows the function structure of the TUS solution means provided in the Web cooperation server of the system shown in FIG. It is a flowchart which shows the TUS issue processing procedure in the system shown in FIG. 1, and its content (in the case of utilization scene A). It is a flowchart which shows the TUS delivery processing procedure in the system shown in FIG. 1, and its content (in the case of utilization scene A). It is a flowchart which shows the TUS solution process in the system shown in FIG. 1, its utilization procedure, and its content (in the case of utilization scene A). It is a flowchart which shows the TUS issue processing procedure in the system shown in FIG. 1, and its content (in the case of utilization scene B). It is a flowchart which shows the TUS delivery processing procedure in the system shown in FIG. 1, and its content (in the case of utilization scene B). It is a flowchart which shows the TUS solution process in the system shown in FIG. 1, its utilization procedure, and its content (in the case of utilization scene B). It is a flowchart which shows the TUS revocation process procedure in the system shown in FIG. 1, and its content. It is a flowchart which shows the expired TUS validation processing procedure in the system shown in FIG. 1, and its content. It is a figure which shows an example of the user identifier which each server holds in the system shown in FIG. 1, and its interserver delivery process. It is a figure which shows the operation | movement content in a Web cooperation server when the TUS issue processing procedure shown in FIG. 6 or FIG. 9 is performed. It is a figure which shows the operation | movement content in a Web cooperation server and an authentication server when the TUS solution process sequence shown in FIG. 8 or FIG. 11 is performed. It is a figure which shows the operation | movement content in a user support center and an authentication server when the TUS revocation process procedure shown in FIG. 12 is performed. It is a figure which shows the component of the record of the TUS revocation list used in order to perform the TUS revocation process procedure shown in FIG. It is a flowchart which shows the procedure and content of a TUS solution process in the case of having the function which manages issued TUS concerning other embodiment of this invention.

Embodiments according to the present invention will be described below with reference to the drawings.
1 is a functional block diagram showing an overall configuration of an information access control system according to an embodiment of the present invention.
The information access control system according to this embodiment includes a plurality of data provider servers DPS1 to DPSn, a plurality of Web linkage servers WFS1 to WFSm, and an authentication server IDP that are operated by medical institutions, health related institutions, exercise related facilities, etc. And a user support center USC, which connect these servers and between these servers and user terminals (not shown) via a communication network.

  The communication network includes, for example, an IP network represented by the Internet and a plurality of access networks for accessing the IP network. As the access network, for example, a local area network (LAN), a wireless LAN, a mobile phone network, a wired telephone network, and a cable television (CATV) network are used.

  The user terminal includes a general user terminal used by a general user such as a patient at home, and a professional user such as a doctor, a public health nurse, or a pharmacist to obtain medical information of the patient at the request of the patient. In addition, a business terminal used for proxy setting of access control rules and an operator console terminal provided in the user support center USC are included. Personal computers are generally used for these terminals, but mobile terminals such as mobile phones and PDAs (Personal Digital Assistants) can also be used as general user terminals and professional user terminals.

  The data provider servers DPS1 to DPSn are obtained by connecting a program memory, a data memory for storing various databases, and a communication interface to a central control unit (CPU) via a bus. The authentication cooperation module 11, the information distribution module 12, the information provision module 13, and the access control rule management module 14 are provided. Any of these functional modules is realized by causing the CPU to execute a program stored in the program memory.

  As the database, a medical related information database 15, an access control rule database 16, and a local user database 17 are provided. The local user database 17 stores user information for identifying and managing each user. The user information includes a local user ID uniquely used by the data provider servers DPS1 to DPSn for each user, basic user information, user attributes, and the like. In the medical related information database 15, personal information of each user, for example, medical health related information such as health guidance information and health diagnosis information is stored in association with the user ID.

  The access control rule database 16 stores information representing access control rules that define the disclosure conditions of the information regarding the medical health related information of the user stored in the medical related information database 15. In the access control rule, a plurality of rule items representing information disclosure conditions are described. This rule item includes, for example, a data owning user (managed by a user ID or the like) indicating the owner of medical health related information, a data item to be an access control target (“target data-item”), and from what time to what time. "Target data-period" which is information indicating whether the data registered in the period is subject to access control, "target user" indicating who is subject to access restriction or permission, and which organization is restricted. Or “target user-affiliated organization” indicating whether it is a target of permission, “target user-role” indicating what kind of qualification is a target of access restriction or permission, and information owner It is composed of “target user-relationship” indicating what kind of human relationship a person is subject to access restriction or permission for personal information or access control rules. “Target data-item” includes, for example, disease name, medication name, weight, allergy information. In addition to the above rule items, the access control rule represents an item indicating whether or not the user can read the medical health related information stored in the application database 19 and whether or not the medical health related information can be written. Items are listed.

  In addition, an item (“target user-authentication unit”) that limits an authentication unit that permits access is included, for example, access is permitted only when a user who is an access control target is authenticated with an IC card and a password. It is also possible to In addition, a “rule effective period” item indicating the effective period of the access control rule itself is included, whereby information can be disclosed / not disclosed only in a specific period.

  The authentication collaboration module 11 executes a process for single sign-on based on the user information stored in the local user database 17. As a result, the user can access another server without re-authentication by logging in once. The information distribution module 12 accepts requests from the Web cooperation servers WFS1 to WFSm, passes them to the information providing module, receives processing results, and returns them to the requesting Web cooperation servers WFS1 to WFSm. Between the Web linkage servers WFS1 to WFSm and the data provider servers DPS1 to DPSn, secure data distribution is performed using the authentication information acquired from the IDP and the ID linkage information stored in the local user database 17.

  When the information distribution module 12 receives the information acquisition request transmitted from the Web cooperation servers WFS1 to WSFm that are authenticated and linked, the information providing module 13 stores information stored in the medical related information database 15 in response to the request, that is, The medical related information managed in association with the local ID is selectively read and transmitted to the request source. Further, when accessing the medical related information, the information providing module 13 determines the request source based on the user ID stored in the local user database 17 and the corresponding access control rule stored in the access control rule database 16. It is determined whether or not the user satisfies the disclosure condition.

  When the access control rule management module 14 receives a request for requesting registration, update, or deletion of an access control rule transmitted from the Web cooperation servers WFS1 to WFSm, the access control rule database 14 is based on the received request. A rule registration, update, or deletion process is performed on the access control rule stored in FIG.

  Each of the Web cooperation servers WFS1 to WFSm is configured by connecting a program memory, a data memory including a local user database 28, and a user interface 21 that performs communication between a user terminal (not shown) to a CPU via a bus. The local user database 28 stores local user IDs uniquely used by the Web cooperation servers WFS1 to WFSm for identifying and managing each user.

  The functional modules include an authentication collaboration module 22, an information distribution module 23, an access control rule management request module 24, and an information acquisition request module 25, and further include a TUS issue module 26 and a TUS resolution request module 27. Yes. Any of these functional modules is realized by causing the CPU to execute a program stored in the program memory.

  The authentication cooperation module 22 entrusts authentication processing to the authentication server IDP when receiving a login request from the user terminal, and receives authentication result information from the authentication server IDP. When the user interface 21 receives an information acquisition request transmitted from the user terminal after authentication, the information acquisition request module 25 transmits the received information acquisition request from the information distribution module 23 to the data provider servers DPS1 to DPSn. And when the information distribution module 23 receives the medical related information returned from the data provider servers DPS1 to DPSn in response to the information acquisition request, a process of transmitting from the received medical related information user interface 21 to the requesting user terminal I do.

  When the user interface 21 receives the access control rule setting request transmitted from the user terminal, the access control rule management request module 24 sends the information distribution module 22 to the data provider servers DPS1 to DPSn in response to the received setting request. Process to request registration, update or deletion of access control rules.

  When the user interface 21 receives an issuance request from a user terminal, the TUS issuance module 26 performs temporary user designators (hereinafter referred to as TUS: Temporary) in the Web cooperation servers WFS1 to WFSm without inquiring other servers. (Referred to as User Specifier), and includes a TUS character string generation processing unit 261 and an encryption processing unit 262 as shown in FIG.

  The TUS character string generation processing unit 261 generates a TUS character string including information for identifying the user who has requested the issuance of TUS, information indicating the valid period of the TUS, and a random number. In addition, the TUS character string may include user attributes, provider IDs of the Web cooperation servers WFS1 to WFSm that are the issuers, and a display name.

  FIG. 2 shows the components of TUS. As information for identifying the issue request source user, a system user ID, a pseudonym, or the like is used. The random number consists of a random number of 8 digits. The effective period is represented by an expiration date start date and time and an end date and time. The user attribute is composed of organization information and role information of the login user. The affiliation organization information includes information indicating the organization (hospital, clinic, local government, etc.) to which the login user belongs. The role information includes a role (such as a medical worker qualification) possessed by the login user.

  Embedding user attributes in the TUS is particularly useful when a professional user who has medical professional qualification issues a TUS. For example, if a general user wants to describe a rule “disclose his / her information to the doctor at hospital A” in his / her access control rule, the organization and role are included in the TUS, so that the user belongs as well as the user ID setting. Organization and role information can be set. That is, TUS can be properly used according to its purpose. FIG. 3 shows the type of TUS for each purpose. Also, by embedding the provider ID in the TUS, it becomes possible to accept the TUS solution other than the Web cooperation servers WFS1 to WFSm of the TUS issuer.

  Furthermore, when a display name such as a nickname or a question / answer is embedded in the TUS, the nickname embedded in the TUS may be displayed on the user terminal of the solution request source to confirm the issuing user during the TUS resolution process described later. it can. Further, by requesting an answer to the question, it is possible to make the user who issued the issue request confirm with the user terminal that is the solution requester that the user is the intended TUS of the other party. That is, the user terminal of the solution request source can confirm whether the user identification information embedded in the TUS really points to an actual person who has been passed the TUS.

  The encryption processing unit 262 encrypts the generated TUS character string using the public key of the authentication server IDP. At that time, in order to further strengthen the security, a signature is given to the TUS character string using the secret keys of the Web cooperation servers WFS1 to WFSm. The TU that has been subjected to the encryption process is returned from the user interface 21 to the user terminal that issued the request.

  When the user interface 21 receives an encrypted TUS resolution request transmitted from a user terminal, the TUS resolution request module 27 requests the TUS resolution by transferring the encrypted TUS received from the user to the authentication server IDP. To do. Then, the TUS converted by the solution processing is received from the authentication server IDP and returned from the user interface 21 to the requesting user terminal.

  The authentication server IDP is obtained by connecting a program memory, a data memory for storing a database, and a communication interface to a CPU via a bus in the same manner as the Web cooperation servers WFS1 to WFSm. And an authentication collaboration module 32, an information distribution module 33, and a management process reception module 34, and a TUS resolution module 35 and a TUS revocation management module 36. Any of these functional modules is realized by causing the CPU to execute a program stored in the program memory.

  As a database, a system user database 37 and a TUS revocation list database 38 are provided. The system user database 37 stores a system user ID of a user registered in the system, a system login ID, and a pseudonym associated with these IDs, that is, a cooperation ID used for data transmission / reception between servers. Further, user attribute information is also stored in association with the user ID as necessary.

  The TUS revocation list database 38 stores a TUS revocation list. The TUS revocation list includes a system user ID and TUS. In addition to this, it is also possible to add a revocation date, a revocation operator, a revocation reason, etc. to the TUS revocation list according to requirements. The revocation date and revocation operator can be used for confirmation at the time of auditing, etc., and the revocation reason can be used as a judgment material when reviving a revoked TUS.

  When the user transmits a login, an information acquisition request, and an access control rule access request, the authentication module 31 performs an authentication process for the requesting user. Specifically, when an authentication request is sent from the Web cooperation servers WFS1 to WFSm, the user information stored in the system user database 37 is referred to authenticate the validity of the requesting user. As an authentication method, various authentication methods such as ID / password authentication, IC card authentication, public key cryptography authentication, and multi-factor authentication can be used. The authentication cooperation module 32 returns the result of the authentication process by the authentication module 21 to the Web cooperation servers WFS1 to WFSm.

  When the information distribution module 33 performs information distribution, that is, transmission of medical related information and access control rule management request / response, between the Web cooperation servers WFS1 to WFSm and the data provider servers DPS1 to DPSn, the WEB cooperation In response to requests from the servers WFS1 to WFSm, the locations (directories) of the data provider servers DPS1 to DPSn are notified, and mediation for establishing information distribution between the two servers is performed. The management process reception module 34 receives a request from a user support center USC, which will be described later, and registers, updates, or deletes user information in the system user database 37. Also, a TUS revocation list management request (addition / deletion) is accepted and passed to the TUS revocation management module 36.

  The TUS resolution module 35 performs processing for resolving the TUS received from the Web cooperation servers WFS1 to WFSm and converting it to an identifier on the system of the issuing user, and has the following functions. FIG. 5 is a block diagram showing the functional configuration. That is, the TUS resolution module 35 includes a decryption processing unit 351, and decrypts the TUS received from the Web cooperation servers WFS1 to WFSm using a secret key possessed by the authentication server IDP. If the signature is given to the TUS, the signature is verified using the public keys of the Web cooperation servers WFS1 to WFSm as the issuing source prior to decryption.

  That is, since TUS is encrypted with the secret key of authentication server IDP, TUS can be resolved only by authentication server IDP. Also, the system function related to the user indicated by TUS, for example, adding the user to the access control rule, cannot be used unless the TUS is resolved and converted into a user identifier on the system.

  Next, the TUS resolution module 35 determines whether or not the current time is within the period represented by the validity period information included in the decoded TUS in the validity period determination unit 352. If the current time is within the valid period as a result of this determination, the revocation list determination unit 353 determines whether or not the decrypted TUS exists in the TUS revocation list database 38. If it does not exist, the conversion unit 354 converts the decrypted TUS into a user identifier (system user ID or pseudonym or the like) on the system, and converts the converted user identifier into the requesting Web cooperation server WFS1. Return to WFSm.

  When the TUS revocation management module 36 receives a TUS revocation request or revocation cancellation request from the user support center USC, which will be described later, via the management process reception module 34, the TUS revocation list database 38 corresponds to the contents of these requests. A process for adding a revocation target TUS or deleting a reusable TUS from the revocation list database 38 is performed.

  Similarly to the authentication server IDP and the like, the user support center USC has a program memory, a data memory, and a user interface 41 connected to a CPU via a bus. , A TUS revocation management request module 43 is provided. Any of these functional modules is realized by causing the CPU to execute a program stored in the program memory.

  The management processing request module 42 makes the authentication server IDP register, update, or delete the system user database 37 and the pseudonym managed by the authentication server IDP in response to a request transmitted from an unillustrated operator (system administrator) terminal. Perform the requested process. In addition, the data provider servers DPS1 to DPSn and the Web cooperation servers WFS1 to WFSm also have a function of converting a pseudonym uniquely used to a system common user ID or from a system common user ID to each pseudonym. Further, it has a function of transferring a request from the TUS revocation management request module 43 to the authentication server IDP.

  When the user interface 41 receives a TUS revocation request or revocation cancellation request transmitted from an operator terminal (not shown), the TUS revocation management request module 43 performs a management process on the received TUS revocation request or revocation cancellation request. A process of transferring to the authentication server IDP via the request module 42 is performed.

Next, the operation of the system configured as described above will be described.
(1) User registration to access control rules (use scene A)
Here, for example, a case where a user B who is a family member of the user A or a doctor in charge is registered as a user who permits access to the medical related information in the access control rule set for the medical related information of the user A, for example. Let's take an example. FIGS. 6 to 8 are diagrams illustrating the sequence, and FIG. 14 is a diagram illustrating an example of control data transferred between servers in the process from issuing a TUS to registering user information in the access control rule.

(1-1) Issuance of TUS User B who requests registration of user information first logs in to the system as shown in FIG. 6 at his user terminal (step S61). Then, the authentication server IDP performs the login user authentication process (step S62), and when the login user is validated, a response is returned to the login source user terminal.

  In this state, it is assumed that user B performs an operation for requesting issuance of TUS at the user terminal (step S63). For example, at this time, an operation screen as shown by G1 in FIG. 14 is displayed on the user terminal, and the user B selects “TUS issue” from the displayed menu. Then, each component (parameter) shown in FIG. 2 to be included in the TUS is arbitrarily input. Then, a TUS issue request is generated at the user terminal, and this TUS issue request is transmitted to the Web cooperation server WFS1.

When receiving the above TUS issue request, the Web cooperation server WFS1 issues a TUS in step S64 and returns it to the requesting user terminal. FIG. 15 shows the processing procedure and contents.
In the figure, a TUS issue request is received by the user interface 21 and transferred to the TUS issue module 26. When receiving the TUS issue request, the TUS issue module 26 checks the input parameters (item numbers 3 to 7 in FIG. 2) included in the TUS issue request. Then, the information distribution module 23 is called and the authentication result information of the request source user managed by the information distribution module 23 is acquired.

  For example, first, when role information (role ID) or affiliation organization information (affiliation organization code) is specified by an input parameter, it is determined whether or not these exist in the authentication result information. If the result of this determination is included in the authentication result information, the local user database 28 is accessed using the local user ID of the Web collaboration server WFS1 and the provider ID of the authentication server IDP as search keys, and a pseudonym corresponding to the local user ID Is read. FIG. 14 illustrates a case where “Bwfs1” is read.

  Subsequently, the information distribution module 23 is called, and the provider ID of the Web cooperation server (own provider) WFS1 managed by the information distribution module 23 is acquired. And each component which produces | generates TUS, ie, the input parameter received from the said user terminal, the acquired said pseudonym, and a random number are connected. Each component is in Key = Value format, and Value performs URL encoding.

Next, the constituent elements of the linked TUS are encrypted with the public key of the authentication server IDP. For example, a character string is generated using BASE64 encoding. Then, the generated encrypted character string is concatenated with the provider ID of the authentication server IDP and the acquired provider ID of the Web cooperation server WFS1 as TUS. Note that RSA encryption or the like is used for encryption. Finally, the generated encrypted TUS is returned from the user interface 21 to the requesting user terminal.
If user B performs a logout operation after receiving the above TUS (step S65), the authentication server IDP accepts logout and performs logout processing (step S66).

(1-2) Delivery of Issued TUS The TUS sent from the Web cooperation server WFS1 is transmitted from the user terminal of the user B to the user terminal of the user A as shown in FIG. , S72). The delivery of the TUS may be performed by storing the TUS in a storage medium such as an FD or a USB memory, and handing this storage medium from the user B to the user A.

The following can be considered as specific examples of delivery of TUS.
(1-2-1) Delivery of a TUS with a short-term expiration date issued by a citizen When a citizen passes a TUS with a short-term expiration date to his / her family, only the issued TUS or A URL in which the URL of the Web cooperation server WFS1 that issued the TUS and the issued TUS are embedded is created, and an e-mail describing this URL is transmitted from the user B terminal to the user A terminal.

(1-2-2) Delivery of a TUS issued by a doctor with a long-term expiration date A professional user who needs to disclose information by using the system in business, such as a doctor (need to pass his own TUS) If there is more than one person, for the sake of convenience, set the TUS expiration date to a long period (for example, the period of time working at the same hospital) and deliver the TUS in the following manner Can be considered.

  That is, in the case where a patient first visits a doctor and then the patient registers the doctor in the access control rule at home, the business card is a TUS (character string) issued by the doctor or the contents of the TUS converted into a two-dimensional barcode or the like. A method of printing and distributing it to patients (who wants to disclose information to doctors) can be considered.

  In hospitals, when a patient registers a doctor with his / her access control rules before the visit, a barcode including the TUS issued by the doctor is handed over at the reception, and the patient is systemized by a dedicated terminal installed in the hospital. Log in to read the barcode and register the doctor in the access control rules.

  Note that TUS is a “designator indicating the user who wants to be disclosed”, and in the case of a professional user such as a doctor who uses the system for business, it does not have its own medical information, so it is effective for a long time. Even if a TUS with a set deadline is distributed to multiple people, the risk of misuse is very small.

(1-3) Solution and Use of TUS User A who wants to register other person's user information in his / her access control rule first logs in to the system as shown in FIG. Step S81). Then, the authentication server IDP performs the authentication process for the login user (step S82), and when the validity of the login user is recognized, the response is returned to the login user terminal.

  In this state, it is assumed that the user A performs an operation for requesting the resolution of the TU passed from the user B on the user terminal (step S83). Then, a TUS resolution request is generated at the user terminal, and this TUS resolution request is transmitted to the Web cooperation server WFS2. When the Web cooperation server WFS2 receives the TUS resolution request, it transfers the TUS resolution request to the authentication server IDP in step S84. The authentication server IDP resolves the transferred TUS (step S85) and returns the result to the user terminal of the user A who made the request. FIG. 16 shows the processing procedure and contents.

  When the Web cooperation server WFS2 receives the TUS resolution request transmitted from the user terminal via the user interface 21, the TUS resolution request module 27 checks the input parameters included in the requested TUS. Then, the information distribution module 23 is called and the authentication result information of the request source user managed by the information distribution module 23 is acquired. Subsequently, a TU resolution request message to be sent to the authentication server IDP is created, and the information distribution module 23 is called with the obtained authentication result of the requesting user and the created TU resolution request message as arguments, and the authentication server IDP. Send a TUS resolution request message.

  When the authentication server IDP receives the TUS resolution request message transmitted from the Web cooperation server WFS2 by the information distribution module 33, the TUS resolution module 35 checks the received TUS resolution request message. Then, the TUS is acquired from the TUS resolution request message and decrypted with the secret key of the authentication server IDP.

  Next, the TUS resolution module 35 checks the expiration date of the decrypted TUS. As a result of this check, if the expiration date / time is not set, it is assumed that the solution processing has already started. Also, if the expiration date / time is not set, it is treated as indefinite.

  Subsequently, the TUS resolution module 35 determines whether or not the decrypted TUS is stored in the TUS revocation list database 38. That is, it is confirmed whether or not the decrypted TUS has expired. As a result of this determination, if the TUS requested to be resolved has not expired, the decrypted TUS pseudonym and the provider ID of the Web collaboration server WFS2 of the TUS issuer included in the TUS resolution request message are used as search keys. The system user database 37 is accessed via the information distribution module 33, and the system user ID corresponding to the pseudonym and the provider ID is acquired. For example, if the pseudonym is “Bwfs1” and the provider ID is “Wfs1”, “B @ idp” is obtained as the system user ID as shown in FIG.

  Subsequently, the TUS resolution module 35 uses the acquired system user ID and the provider ID of the Web cooperation server WFS2 of the TUS resolution request source in the TUS resolution request message as a search key in the system user database via the information distribution module 33. 37 is accessed, thereby obtaining a pseudonym corresponding to the system user ID. With this process, the TUS solution request can be made even in the Web cooperation server WFS2 different from the Web cooperation server WFS1 of the TUS issuer.

  Subsequently, the TUS resolution module 35 creates a response message including the acquired pseudonym, role information (role ID) extracted from the TUS, affiliation organization information (affiliation organization code), and display name. Then, the created response message is returned from the information distribution module 33 to the requesting Web cooperation server WFS2.

  When the response message is received from the authentication server IDP, the TUS resolution request module 27 of the Web cooperation server WFS2 acquires a pseudonym, organization information, role information, and display name that are constituent elements of the TUS from the received TUS resolution response message. , The user identifier of the user who issued the TUS is generated. Then, the generated user identifier of the user who issued the TUS is returned from the user interface 21 to the user terminal that is the solution request source.

  Upon receiving the user identifier of the user who issued the TUS, the user A performs an operation for registering the received user identifier in its own access control rule (step S86). For example, at this time, an operation screen as shown in G2 of FIG. 14 is displayed on the user terminal, and the user A selects “access control rule setting” from the displayed menu. Then, an access control rule setting request is generated at the user terminal, and this access control rule setting request is transmitted to the Web cooperation server WFS2.

  When the Web cooperation server WFS2 receives the access control rule setting request transmitted from the user terminal through the user interface 21, the access control rule management request module 24 receives the authentication result information of the user A and the received access control rule. Using the user identifier of user B included in the setting request as an argument, the identifiers of user A and user B for the data provider server are acquired from the authentication server IDP via the information distribution module 23. Then, based on the acquired identifiers of the user A and the user B for the data provider server, an access control rule setting request is transmitted from the information distribution module 23 to the data provider server DPS1 to be accessed (step S88).

  When the data supply server DPS1 receives the setting request transmitted from the Web cooperation server WFS2 by the information distribution module 12, the access control rule management module 14 responds to the request from the local user database 17 to the local user of the corresponding user A. Read the ID. Then, the access control rule database 16 is accessed based on the read local user ID, and the access control rule corresponding to the user A includes the setting target included in the received access control rule setting request. The user ID and the like are additionally registered (step S88).

  When the registration process is completed, the response is sent back from the information distribution module 12 of the data provider server DPS1 to the information distribution module 23 of the request source Web cooperation server WFS2. Further, the response is transferred from the user interface 21 to the user terminal of the user A under the control of the access control rule management request module 24 of the Web cooperation server WFS2.

(2) Acquisition of user's medical information by others (use scene B)
Here, for example, the case where the user B who is the family or the doctor in charge acquires the medical related information of the user A managed by the data provider server DPS1 will be described as an example. 9 to 11 are diagrams showing the sequence.

(2-1) Issuance of TUS User A who intends to acquire medical-related information first logs into the system as shown in FIG. 9 at his / her user terminal (step S91). Then, the authentication server IDP performs the login user authentication process (step S92), and when the login user is validated, a response is returned to the login source user terminal.

  In this state, it is assumed that the user A performs an operation for requesting the issuance of TUS at the user terminal (step S93). Similarly to the case of registering user information in the access control rule described in (1) above, this requesting operation also displays an operation screen on the user terminal, and user A displays “TUS” in the displayed menu. Select “Publish”. Then, each component (parameter) shown in FIG. 2 to be included in the TUS is arbitrarily input. Then, a TUS issue request is generated at the user terminal, and this TUS issue request is transmitted to the Web cooperation server WFS2.

When receiving the above TUS issue request, the Web cooperation server WFS2 issues a TUS in step S94 and returns it to the requesting user terminal. This TUS issuance process is performed as follows.
That is, when the Web cooperation server WFS2 receives the TUS issue request transmitted from the user terminal by the user interface 21, the TUS issue module 26 first inputs the input parameters (item number 3 in FIG. 2) included in the received TUS issue request. Check ~ 7). Then, the information distribution module 23 is called and the authentication result information of the request source user managed by the information distribution module 23 is acquired.

  For example, first, when role information (role ID) or affiliation organization information (affiliation organization code) is specified by an input parameter, it is determined whether or not these exist in the authentication result information. If the result of this determination is included in the authentication result information, the local user database 28 is accessed using the local user ID of the Web collaboration server WFS2 and the provider ID of the authentication server IDP as search keys, and a pseudonym corresponding to the local user ID Is read. Subsequently, the information distribution module 23 is called, and the provider ID of the Web cooperation server (own provider) WFS2 managed by the information distribution module 23 is acquired. And each component which produces | generates TUS, ie, the input parameter received from the said user terminal, the acquired said pseudonym, and a random number are connected.

Next, the constituent elements of the linked TUS are encrypted with the public key of the authentication server IDP. Then, the generated encrypted character string is concatenated with the provider ID of the authentication server IDP and the acquired provider ID of the own Web cooperation server WFS2 to be TUS. Note that RSA encryption or the like is used for encryption. Finally, the generated encrypted TUS is returned from the user interface 21 to the requesting user terminal.
If user B performs a logout operation after receiving the above TUS (step S95), the authentication server IDP accepts logout and performs logout processing (step S96).

(2-2) Delivery of issued TUS The TUS sent from the Web cooperation server WFS2 is transmitted from the user terminal of the user A to the user terminal of the user B, for example, by e-mail as shown in FIG. 12 (step S101). , S102). The delivery of the TUS may be performed by storing the TUS in a storage medium such as an FD or a USB memory and handing the storage medium from the user A to the user B. As a specific example of delivery of this TUS, a URL in which only the issued TUS or the URL of the Web cooperation server WFS2 that issued the TUS and the issued TUS are embedded is created, and an email describing this URL is sent to the user A's Transmit from the terminal to the terminal of user B.

(2-3) Solution and Use of TUS The user B who wants to acquire the medical-related information of the user A first logs in to the system as shown in FIG. 11 at his user terminal (step S111). Then, the authentication server IDP performs the login user authentication process (step S112), and if the login user is validated, a response is returned to the login source user terminal.

  In this state, it is assumed that the user B performs an operation for requesting the solution of the TU passed from the user A at the user terminal (step S113). Then, a TUS resolution request is generated at the user terminal, and this TUS resolution request is transmitted to the Web cooperation server WFS1. When the Web cooperation server WFS1 receives the TUS resolution request, it transfers the TUS resolution request to the authentication server IDP in step S114. The authentication server IDP resolves the transferred TUS (step S115) and returns the result to the user terminal of the requesting user B.

  When the Web interface server WFS1 receives the TUS resolution request transmitted from the user terminal through the user interface 21, the TUS resolution request module 27 checks the input parameters included in the requested TUS. Then, the information distribution module 23 is called and the authentication result information of the request source user managed by the information distribution module 23 is acquired. Subsequently, a TU resolution request message to be sent to the authentication server IDP is created, and the information distribution module 23 is called with the obtained authentication result of the requesting user and the created TU resolution request message as arguments, and the authentication server IDP. Send a TUS resolution request message.

  When the authentication server IDP receives the TUS resolution request message transmitted from the Web cooperation server WFS1 by the information distribution module 33, the TUS resolution module 35 checks the received TUS resolution request message. Then, the TUS is acquired from the TUS resolution request message and decrypted with the secret key of the authentication server IDP.

  Next, the TUS resolution module 35 checks the expiration date of the decrypted TUS. As a result of this check, if the expiration date / time is not set, it is assumed that the solution processing has already started. Also, if the expiration date / time is not set, it is treated as indefinite.

  Subsequently, the TUS resolution module 35 determines whether or not the decrypted TUS is stored in the TUS revocation list database 38. That is, it is confirmed whether or not the decrypted TUS has expired. As a result of this determination, if the TUS requested to be resolved has not expired, the decrypted TUS pseudonym and the provider ID of the Web collaboration server WFS2 of the TUS issuer included in the TUS resolution request message are used as search keys. The system user database 37 is accessed via the information distribution module 33, and the system user ID corresponding to the pseudonym and the provider ID is acquired.

  Subsequently, the TUS resolution module 35 uses the acquired system user ID and the provider ID of the Web collaboration server WFS1 of the TUS resolution request source in the TUS resolution request message as a search key in the system user database via the information distribution module 33. 37 is accessed, thereby obtaining a pseudonym corresponding to the system user ID. By this processing, the TUS solution request can be made even in the Web cooperation server WFS1 different from the Web cooperation server WFS2 of the TUS issuer.

  Subsequently, the TUS resolution module 35 creates a response message including the acquired pseudonym, role information (role ID) extracted from the TUS, affiliation organization information (affiliation organization code), and display name. Then, the created response message is returned from the information distribution module 33 to the requesting Web cooperation server WFS1.

  When the response message is received from the authentication server IDP, the TUS resolution request module 27 of the Web cooperation server WFS1 acquires the pseudonym, organization information, role information, and display name that are constituent elements of the TUS from the received TUS resolution response message. , The user identifier of the user who issued the TUS is generated. Then, the generated user identifier of the user who issued the TUS is returned from the user interface 21 to the user terminal that is the solution request source.

  When receiving the user identifier of the user who issued the TUS, the user B performs an operation for acquiring the medical related information of the user A based on the received user identifier (step S116). For example, at this time, the operation screen is displayed on the user terminal, and the user B selects “information acquisition” from the displayed menu. Then, an information acquisition request is generated at the user terminal, and this information acquisition request is transmitted to the Web cooperation server WFS1.

  When the Web cooperation server WFS1 receives the information acquisition request transmitted from the user terminal via the user interface 21, the information acquisition request module 25 displays the authentication result information of the user B and the user included in the received information acquisition request. Using the user identifier of A as an argument, the identifiers of user A and user B for the data provider server are acquired from the authentication server IDP via the information distribution module 23. Then, based on the acquired identifiers of the user B and the user A for the data provider server, an information acquisition request is transmitted from the information distribution module 23 to the data provider server DPS1 to be accessed (step S117).

  When the data providing server DPS1 receives the information acquisition request transmitted from the Web cooperation server WFS1 by the information distribution module 12, the information providing module 13 receives the local user ID of the corresponding user A from the local user database 17 in response to the request. Is read. Then, the medical related information database 15 is accessed based on the read local user ID, and corresponding medical related information of the user A is read. Then, the read medical related information is transmitted from the information distribution module 12 to the requesting Web cooperation server WFS1 (step S118).

  When the Web-related server WFS1 receives the medical-related information transmitted from the data provider server DPS1 by the information distribution module 23, the Web-related server WFS1 receives the received medical-related information from the user interface 21 under the control of the information acquisition request module 25. Transfer to user B's user terminal.

(3) Management of TUS revocation list (3-1) TUS revocation processing For example, when the issued TUS is lost or leaked to a third party, the TUS needs to be revoked. This TUS revocation procedure is performed as follows.
Here, a case where user A wants to expire his / her TUS will be described as an example. FIG. 12 is a flowchart showing an outline of the processing procedure and processing contents.

  The TUS revocation management is performed by an operator who is a system administrator in response to a request from the user. User A submits a TUS revocation registration application to the operator (step S121). When the operator receives the TUS revocation registration application in step S122, the operator logs in to the system from the operator terminal (step S123). Upon receiving the login request, the user support center USC first performs user authentication in step S124. When the validity of the login user is confirmed, the result is returned to the operator terminal of the login source.

  When the operator performs a TUS revocation registration request operation based on the contents of the TUS revocation registration application form upon receiving the notification of the authentication result, a request for additional registration of a TUS revocation list is transmitted from the operator terminal to the user support center USC. (Step S125). Upon receiving the above TUS revocation list additional registration request, the user support center USC transfers the TUS revocation list additional registration request to the authentication server IDP in step S126. When the authentication server IDP receives the additional registration request for the TUS revocation list, the authentication server IDP executes a process for additionally registering the TUS to be revoked in the TUS revocation list database 38 according to the content of the received additional registration request (step S127). .

  FIG. 17 is a diagram showing a flow of processing in the user support center USC and the authentication server IDP. In the figure, when the user support center USC receives the above TUS revocation list additional registration request through the user interface 41, the TUS revocation list management request module 43 first checks the input parameters, that is, the TUS and the provider ID of the authentication server. Subsequently, the management processing request module 42 transmits a TUS revocation list addition request message to the authentication server.

On the other hand, upon receiving the TUS revocation list addition request message sent from the user support center USC, the authentication server IDP executes the TUS revocation list addition registration process as follows.
That is, first, it is checked whether or not the IP address of the request source user support center USC is included in the permitted IP address list managed by the management process reception module 34 of the authentication server IDP. Subsequently, the input parameters (TUS list) are checked. If the acceptance condition is satisfied as a result of these checks, the encrypted TUS included in the received TUS revocation list addition request message is decrypted, and the provider ID of the Web linkage server that issued the pseudonym and TUS The expiration date / time and the expiration date / time are extracted.

  Next, the TUS revocation list management module 36 searches the system user database 37 via the information distribution module 33 using the extracted KUS pseudonym and provider ID as search keys, and obtains a system user ID corresponding to the pseudonym. To do. Subsequently, a TUS revocation list record including the acquired system user ID is created. FIG. 18 shows an example of a TUS revocation list record created. As shown in the figure, the record of the TUS revocation list includes a user ID, a TUS, a start date / time and an end date / time of a valid period extracted from the TUS, and a record creation date / time and an update date / time.

  Then, the TUS revocation list management module 36 additionally registers the created TUS revocation list record in the TUS revocation list of the TUS revocation list database 38. When a plurality of TUS lists are described in the input parameter, the above record registration process is repeated for these TUS lists. When registration of all records is completed, the registration process is terminated.

  When the registration process is completed, the management process reception module 34 of the authentication server IDP returns a response indicating the process result to the user support center USC as the request source. The response representing the processing result is transferred to the requesting operator terminal via the user support center USC as shown in FIG.

Upon receiving the response, the operator performs a logout operation at his / her terminal (step S128). Then, the user support center USC performs logout processing in step S129 and notifies the operator terminal of the result. After the logout, the operator creates TUS revocation information in step S130, and transmits this TUS revocation information to the user terminal used by user A (step S131).
Thus, the TUS to be revoked is registered in the TUS revocation list database 38, and the use of this TUS is stopped thereafter.

(3-2) Activation of expired TUS When a temporarily lost TUS is found, it is possible to cancel the expiration of the expired TUS. This invalidated TUS validation process is performed as follows. FIG. 13 is a flowchart showing an outline of the processing procedure and processing contents.

  Similarly to the TUS revocation registration process described above, the revoked TUS validation process is performed by an operator who is a system administrator in response to a request from the user. User A submits a TUS revocation deletion application to the operator (step S141). When the operator receives the TUS revocation deletion application form in step S142, the operator logs in to the system from the operator terminal (step S143). Upon receiving the login request, the user support center USC first performs user authentication in step S144. When the validity of the login user is confirmed, the result is returned to the operator terminal of the login source.

  When the operator performs a request for browsing the TUS revocation list in response to the notification of the authentication result, a TUS revocation management request for searching for the TUS revocation list is transmitted from the operator terminal to the user support center USC (step S145). . Upon receiving the TUS revocation list management request, the user support center USC transfers the TUS revocation list management request for searching the TUS revocation list to the authentication server IDP in step S146. When the authentication server IDP receives the above TUS revocation list management request, the authentication server IDP reads the corresponding TUS revocation list from the TUS revocation list database 38 in response to the received request, and uses the read TUS revocation list to the user support center USC. Then, it is returned to the requesting operator terminal (step S147).

  The operator selects a target TUS whose revocation is to be deleted from the returned TUS revocation list at his / her terminal (step S148). Then, the operator terminal generates a TUS revocation management request for deleting the TUS revocation list by the TUS revocation management request module 43, and transmits this TUS revocation management request to the user support center USC (step S148).

  When the user support center USC receives the TUS revocation management request via the user interface 41, under the control of the TUS revocation management request module 43, the user support center USC issues a TUS revocation management request for requesting revocation deletion of the TUS from the management processing request module 42. Transfer to the authentication server IDP (step S150). When the authentication server IDP receives the TUS revocation list management request, the authentication server IDP deletes the revocation management information of the corresponding revocation TUS from the TUS revocation list database 38 according to the content of the received request (step S151).

When the deletion process is completed, the management process reception module 34 of the authentication server IDP returns a response indicating the process result to the user support center USC as the request source. The response representing the processing result is transferred to the requesting operator terminal via the user support center USC. Upon receiving the response, the operator performs a logout operation at his / her terminal (step S152). Then, the user support center USC performs logout processing in step S153 and notifies the operator terminal of the result. After the logout, the operator creates new TUS revocation information after the deletion process in step S154, and transmits this TUS revocation information to the user terminal used by user A (step S154).
Thus, among the revocation target TUSs stored in the TUS revocation list database 38, the revocation state of the TUS to be validated is released, and thereafter this TUS can be used again.

  As described above in detail, in the above embodiment, when the user B requests registration of his / her user information with respect to the access control rule defined for the personal information of the user A, the user B first issues a TUS. The request is transmitted, and the TUS encrypted by the Web cooperation server WFS1 is issued. Next, a TUS resolution request is transmitted from the terminal of user A, and the authentication server IDP decrypts the TUS included in the TUS resolution request and converts it into information for identifying user B. Information for identification is transmitted to the data provider server DPS1 and set in the access control rule of the user A.

  Therefore, the identification information of the user B set in the access control rule corresponding to the medical related information of the user A is issued as a TU in response to the request of the user B himself / herself. For this reason, the identification information of the user B can be safely passed to the user A without being disclosed or searched. Further, the user A can request the solution of the passed TUS, thereby reliably specifying the user B on the system and setting the identification information in the access control rule of the user A.

  In this embodiment, when the user B obtains the medical related information of the user A from the terminal of the user A using the identification information of the user A, the user A first transmits a TUS issue request from the user A terminal. The Web cooperation server WFS2 issues an encrypted TUS for allowing A to be specified by another person. Next, a TUS resolution request is transmitted from the terminal of the user B, the encrypted TUS included in the resolution request is decrypted by the authentication server IDP and converted into user A identification information, and the converted user A identification is performed. The medical-related information of the user A is acquired from the data provider server DPS1 using the information.

  Therefore, the identification information of the user A necessary for acquiring the medical-related information of the user A is issued as a TUS in response to the request of the user A himself / herself. For this reason, the identification information of the user A can be safely passed from the user A to the user B without being disclosed or searched. In addition, the user B can request the solution of the passed TUS from his / her terminal, thereby reliably specifying the user A on the system and acquiring the medical related information.

  Furthermore, in this embodiment, when issuing the TUS, the pseudonym associated with the user ID of the issue request source is included in the TUS on the system, and when the TUS is resolved, the issued encrypted TU is decrypted. After conversion to the kana, the converted kana is converted to the user ID of the issue request source. Therefore, even if a secret key for decrypting the encrypted TUS is leaked and the TUS is decrypted by a third party, the real ID (user ID or login ID) used on the system is known to the third party. Risk.

  Further, in this embodiment, when issuing the TUS, the TUS includes information indicating the start date and time and end date of the effective period, and when resolving the TUS, the start date and time of the effective period included in the decrypted TUS Based on the information indicating the end date and time, it is determined whether the TUS is valid or invalid. Therefore, the effective period can be arbitrarily set according to the use of TUS. For example, in the case of a doctor or the like, since there are a plurality of recipients who give TUS, issuing a TUS with a long validity period makes it easier for the user to issue a TUS each time. The burden can be reduced.

  Further, in this embodiment, a TUS revocation list database 38 is provided in the authentication server IDP, a TUS revocation registration request is transmitted from the operator terminal, and information indicating the TUS to be revoked is registered in the TUS revocation list database 38 by the authentication server IDP. . Then, when the user requests the TUS resolution, it is determined whether or not the TUS is registered in the TUS revocation list database 38 in response to this request, and if it is registered, this TUS is invalidated. I am doing so. Therefore, when the TUS is lost or misused, the use of the TUS can be stopped.

  Furthermore, when this method is used, it is not necessary to manage the TUS by embedding the encrypted user identification information in the TUS, and there is an advantage that the number of TUS issued is not limited. In addition, the same user can issue a plurality of TUSs.

  Furthermore, in this embodiment, a TUS revocation deletion request is transmitted from the operator terminal, and revocation management information of a TUS that has been revoked is deleted by the authentication server IDP. For this reason, it becomes possible to resume the use of the TUS whose use has been temporarily stopped according to the user's application.

  Furthermore, in this embodiment, when issuing a TUS, in addition to the identification information of the issue requesting user, the TUS includes attribute information of the issue requesting user, for example, information indicating the user's organization and qualification. Yes. In this way, when setting the user ID in the access control rule, it is possible to simultaneously set information representing the organization to which the setting requesting user belongs, qualifications, and the like.

Further, the provider ID of the Web cooperation server that is the issue source may be included in the TUS. In this way, it is possible to accept a TUS resolution request not only by the Web cooperation server of the TUS issuer but by any Web cooperation server that has been authenticated and linked.
Further, by including display information such as a nickname and a question / answer in the TUS, the nickname or the question entered by the issuing user can be displayed to the solution requesting user during the TUS resolution process, and the user can be confirmed. It becomes possible.

  Further, in this embodiment, when issuing the TUS, the TUS is signed using the secret key held by the Web cooperation server, and when the TUS is resolved by the authentication server IDP, the decrypted TUS signature is displayed. Verification is performed using a public key that is paired with a private key. Therefore, it is possible to perform signature verification for the TUS during the TUS resolution process, thereby improving security when the TUS is lost.

The present invention is not limited to the above embodiment. For example, in the above embodiment, TUS revocation management is performed, but in addition to this, TUS issuance management may also be performed.
When only the TUS revocation management is performed, there is an advantage that communication between the Web cooperation servers WFS1 to WFSm and the authentication server IDP does not occur when the TUS is issued, and the number of TUS issues is not limited. In order to expire the TUS, it is necessary to present the TUS, and when the TUS is lost, there is a problem that the TUS revocation process cannot be performed. This can be avoided by enriching the contents of the TUS revocation list, but can be dealt with by managing the issuance of TUS. Hereinafter, a case where the authentication server IDP issues a TUS and manages the issued TUS will be described.

  In the authentication server IDP, in addition to the TUS revocation list, a “TUS issue list” is managed by a database. As described in the above embodiment, the TUS issue list holds information such as an issuer user identifier, affiliation organization information, role information, valid period (start date and end date), and display name embedded in the TUS. It is also possible to hold the type of TUS. As a result, only the information for linking with the TUS issue list need be embedded in the TUS, and there is no need to store various types of information associated with individual users.

  First, the TUS issuance process is performed as follows. That is, the TUS issuing module is arranged in the authentication server IDP instead of the Web cooperation servers WFS1 to WFSm. Instead, the Web cooperation servers WFS1 to WFSm perform processing for transferring the TUS issue request from the user terminal to the authentication server IDP. A TU issuance request module to be executed is arranged. The processing function of the TUS issuing module in the authentication server IDP is the same as that shown in FIG. However, since this TUS issuing process is executed by the authentication server IDP, the issuing provider ID given to the TUS indicates the authentication server IDP. The TUS encryption is performed using the public key of the authentication server IDP as in the above embodiment, but the signature is performed using the secret key of the authentication server IDP.

Next, the TUS solution processing is performed as follows. FIG. 19 shows the processing procedure and processing contents.
That is, the TUS resolution module 35 is provided in the authentication server IDP as in the above embodiment. The TUS resolution module 35 decrypts the TUS with the secret key of the authentication server IDP in step S211 and confirms whether or not the TUS exists in the TUS issue list in step S222. If it exists, the user attribute information associated with the TUS issue list database 39 is acquired, and the user identifier of the target user is generated in step S223. The TUS decryption process is performed by using the secret key of the authentication server IDP, and the signature is performed by using the public key of the authentication server IDP.

  By providing a TUS issue management function in this way, the following effects can be obtained. That is, since the authentication server IDP holds information related to the TUS, there is no need to store various information such as a pseudonym and a validity period in the TUS. For this reason, the character string of TUS can be shortened. Also, information regarding the type of TUS as shown in FIG. 3 can be held on the authentication server IDP side, which can be realized without changing the character string of the TUS itself. Furthermore, the issued TUS can be searched from the user identifier. For this reason, when a TUS is lost, it becomes possible to expire the TUS.

  In the above embodiment, the TUS is valid only within the period specified by the validity period information embedded in the TUS. However, the TUS is controlled to be valid only during the period from login to logout. May be. Further, TUS may be issued by an authentication server, and other data provider servers, Web linkage servers, authentication server configurations and functions, etc. can be implemented with various modifications without departing from the scope of the present invention. is there.

  Furthermore, in the above-described embodiment, the EHR system has been described as an example. However, there are an unspecified number of users, and it is a system that does not allow any personal information to be disclosed to users other than those authorized by the person. Similarly, the present invention can be applied to any system that requires a third party to perform proxy operations or refer to the stored personal information. This type of system includes, for example, the Basic Resident Register Network, which is an existing or expected public service, Resident Registration, Driver's License Management, Car Registration, Long-Term Care Insurance Application, Pension Reference, Tax Payment Status Inquiry, Electronic A system such as a post office box.

  In short, the present invention is not limited to the above-described embodiments as they are, and can be embodied by modifying the components without departing from the scope of the invention in the implementation stage. Moreover, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the above embodiments. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, you may combine suitably the component covering different embodiment.

  DPS1 to DPSn: Data provide server, WFS1 to WFSm ... Web linkage server, IDP ... Authentication server, USC ... User support center 11, 12, 32 ... Authentication linkage module, 12, 23, 33 ... Information distribution module, 13 ... Information Provision module, 14 ... access control rule management module, 15 ... medical related information database, 16 ... access control rule database, 17, 28 ... local user database, 21, 41 ... user interface, 24 ... access control rule management request module, 25 ... Information acquisition request module, 26 ... TUS issue module, 27 ... TUS resolution request module, 31 ... Authentication module, 34 ... Management processing acceptance module, 35 ... TUS resolution module, 36 ... TUS revocation management module, 7 ... system user database, 38 ... TUS revocation list database, 42 ... processing request module for managing, 43 ... TUS revocation management request module.

Claims (9)

An information access control system for accessing personal information of a first user stored in a server device using information for identifying the first user from a terminal of a second user,
In response to an issue request transmitted from the terminal of the first user, in addition to information for identifying the user of the issue request source, attribute information of the issue request source user and the issuer of the temporary user specifier Including at least one of identification information for identifying the server device to be provided and presentation information to be presented to the user of the solution request source, the second user selects the first user for the access. An issuing means for issuing an encrypted temporary user designator used to specify;
In response to a resolution request transmitted from the terminal of the second user, the issued encrypted temporary user specifier included in the resolution request is decrypted and converted into information for identifying the first user And an information access control system. Information for identifying the second user who is permitted to access the personal information from the terminal of the first user with respect to the access control rule defined for the personal information of the first user stored in the server device An information access control system having a function of setting
Used by the first user to designate the second user for setting information for identifying the second user in response to an issue request transmitted from the terminal of the second user. Issuing means for issuing an encrypted temporary user designator;
In response to a resolution request transmitted from the terminal of the first user, the issued encrypted temporary user specifier included in the resolution request is decrypted and converted into information for identifying the second user And an information access control system. The issuing means issues a temporary user designator that encrypts the pseudonym associated with the identifier of the user who issued the request on the system,
The resolution means decrypts the issued encrypted temporary user specifier and converts it into the pseudonym, and then converts the converted pseudonym into an identifier of the user who issued the issue request. 3. The information access control system according to 1 or 2. The issuing means includes information representing a validity period in the temporary user designator,
The solving means further comprises means for determining whether the temporary user designator is valid or invalid based on information representing a validity period included in the decrypted temporary user designator. Item 3. The information access control system according to Item 1 or 2. The solution is as follows:
A revocation list storage means;
Means for storing the temporary user designator designated by the revocation registration request in the revocation list storage means in response to the revocation registration request transmitted from the terminal;
Further comprising: means for determining whether or not the decrypted temporary user specifier is stored in the revocation list storage means, and invalidating the temporary user specifier when stored. The information access control system according to claim 1 or 2.   The resolving means further comprises means for deleting a temporary user designator designated by the revocation deletion request from the revocation list storage means in response to the revocation deletion request transmitted from the terminal. 5. The information access control system according to 5. The issuing means further comprises means for signing a temporary user designator using a secret key owned by the issuing means,
3. The information access according to claim 1, wherein the solution means further comprises means for verifying the signature of the decrypted temporary user designator using a public key paired with the secret key. Control system. A data provider server device that stores personal information of the first user, a cooperation server device that cooperates between the terminal used by the user and the data provider server device, and between the data provider server device and the cooperation server device The first user is identified from the terminal of the second user with respect to the personal information of the first user stored in the data provider server device using a system including an authentication server device that authenticates and cooperates An information access method for accessing using information for
In response to the issuance request transmitted from the terminal of the first user, the cooperation server device, in addition to information for identifying the issuance request source user, attribute information of the issuance request source user, and the temporary A second user for the access including at least one of identification information for specifying a server device that is a user designator issuer and presentation information to be presented to a user of a solution request source Issuing an encrypted temporary user designator that is used to designate the first user;
In response to a resolution request transmitted from the terminal of the second user, the authentication server device decrypts the issued encrypted temporary user specifier included in the resolution request and identifies the first user The information access control method characterized by comprising the process of converting into the information for performing. A data provider server device that stores personal information of the first user, a cooperation server device that cooperates between the terminal used by the user and the data provider server device, and between the data provider server device and the cooperation server device From the first user's terminal to the access control rule defined for the personal information of the first user stored in the data provider server device using a system comprising an authentication server device that authenticates An information access control method having a function of setting information for identifying a second user who is permitted to access the personal information,
In response to an issuance request transmitted from the terminal of the second user, the cooperation server device sets the second user to set information for identifying the second user. Issuing an encrypted temporary user designator that is used to specify,
In response to a resolution request transmitted from the terminal of the first user, the authentication server device decrypts the issued encrypted temporary user specifier included in the resolution request and identifies the second user The information access control method characterized by comprising the process of converting into the information for performing.

Images