JP2000137435A - Managing device, storing device, and processing system for team data list, and recording medium therefor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a team data list processing system capable of sharing information and function while hierarchizing a team composed of plural members. SOLUTION: An authority data 33 is the data representing a relation between a team and a sub-team subordinate thereto, and an authority list 34 is the list in which a manager of each team is registered, and each team is hierarchized according to these team data lists. A list storing function 36 transfers the team data list with storage device 32. An authority confirming function 35 judges acceptance of a request or refusal thereof based on the contents of the team data list when the team data list is required to be referred to, changed, or deleted. A list validity confirming function 37 traces back the hierarchy of the team data list to the route team and confirms the signature of the team master. An AUD-AUL modifying function 38 creates, deletes, and changes the team data list. An electronic signature function 39 acquires a secret key corresponding to the public key, and adds the signature to the changed team data list.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention creates, manages, and stores a team data list for hierarchizing teams such as departments and sections of a company composed of a plurality of users (members). The present invention relates to a team data list processing system for safely sharing various information and various functions provided between users. More specifically, a team data list storage device that performs processing related to storage of the team data list and a team data list management device that performs various managements on the team data list obtained from the team data list storage device are provided. It is about the system.

[0002]

2. Description of the Related Art In order to share various resources such as various functions and information provided to a user among a plurality of users, a user requesting access to these resources has a right to truly access the resource. It is necessary to prepare a function to verify whether or not it has. In order to perform such verification, conventionally, a list called an access control list (hereinafter, abbreviated as “ACL”) in which users who have been granted valid access rights to resources have been used. The ACL mentioned here is an example of a list including only information for controlling access to a shared resource among various information included in the team data list described above.

FIG. 15 shows an outline of a conventional system for sharing information among a plurality of users using an ACL. In the system shown in FIG.
The server 5 is connected to the server 5 via the Internet 4, and sharing members 6 outside the intranet as well as those inside the intranet 1 share information with each other via the Internet 2. As is well known, the intranet 1 is a closed network such as a network provided in a company,
On the other hand, the Internet 2 is a public network that spans the world.

The firewalls 3 and 4 are computers for preventing a malicious intruder or the like from illegally accessing the intranet 1. Server 5
Is a terminal (computer) in which various resources are stored, and a database 7 in which shared information is stored, and an ACL 8 which holds a group list of members who can access specific information or functions and members belonging thereto. It has. The server 5 has a data storage function for managing shared information stored in the database 7, a user authentication function for verifying whether or not a communication partner corresponding to a client is a previously permitted person, and an ACL 8. An access control function for verifying whether or not access to the shared information is possible, and a group management function for enabling only members belonging to a specific group to access the specific shared information based on the ACL 8 are provided.

[0005] In the system shown in FIG. 15, when there is an access request to the database 7 from a shared member 6 or a user inside the intranet 1, the server 5 sends the ACL 8 each time.
, The user is authenticated. If the user is defined as a member in the ACL 8, access is permitted. If the user is not defined as a member, access is denied. If the user is permitted to access, the server 5 refers to the ACL 8 to check whether the member is included in a specific group, and determines whether the member has access to the shared information requested to be accessed. To see if they are allowed.

[0006]

When resources are shared among a plurality of users, it may not be preferable to include an administrator on the server side as a shared member. For example,
It is considered necessary for a system administrator belonging to the information system department of a certain company to be unable to access the personnel information of the company that should be shared only within the personnel department. However, in the system as shown in FIG. 15 described above, the administrator of the server 5 is authorized to set and manage the ACL 8. Therefore, there is a disadvantage that the server administrator 5 can make unauthorized access to the ACL 8 and cannot intentionally falsify the setting contents of the ACL 8. In addition to this, there is also a possibility that the ACL 8 may be tampered with by a person (so-called cracker) who intrudes into the server SV in addition to the server administrator.

[0007] In addition, in consideration of application to a usage form in which information is shared inside a company, it is desirable to construct a system that is well suited to such a form.
In other words, companies of a certain size or more have a hierarchical relationship in which the organization is formed in a pyramid shape.For example, it is quite common that there are one HR section and two HR sections under the HR department. It can be said that Also, in the development department, for example, the development manager is given the authority to create new sections, integrate several sections, or abolish certain sections in accordance with the product development process, etc. May be considered. Also, each section may be divided into several groups depending on the task.

In such an organization, it is very burdensome for the director of development to manage each section and members of all groups belonging to each section. Therefore, in order to disperse such a management burden, it has been practiced to allocate some persons to assist the development manager and to have these persons perform part or all of the management work. Furthermore, the director of the development department is given only the authority to perform tasks such as section creation and consolidation, and the internal management and information sharing itself of the section is left to the section manager and group leaders under the section. I have. However, the conventional system described above has a problem in that flexible management and information sharing suitable for the organizational form of the company as described above are not considered at all.

SUMMARY OF THE INVENTION The present invention has been made in view of the above points, and has as its object to include a person outside a team corresponding to an organizational unit of a company, including a privileged person such as a server administrator.
It is an object of the present invention to provide a team data list processing system for preventing a cracker or the like from cheating on a team data list, and for realizing a team hierarchy and various information and functions. More specifically, only those who are specifically selected from the members belonging to each team can create sub-teams under the team, assign sub-team creation rights to specific people, create sub-teams, etc. It is an object of the present invention to provide a team data list processing system that allows a specific person selected by an authorized person to manage a sub-team.

[0010]

Means for Solving the Problems To solve the above problems, the invention according to claim 1 is a team data list management device for managing a team data list for hierarchizing teams, wherein An operation request for the team data list is made to a request destination, and in response to the operation request, for each team from the team to be operated to the root team, an identifier indicating the parent team of the own team and the electronic information of the manager of the parent team It has authority data including a signature, administrator information on the management authority of the sub-team under the control of the own team, and an authority list including the electronic signature of the team master who is the manager of the own team or the manager of the parent team. Obtain a team data list from the request destination, and trace each team using the identifier to the root team while tracing the team to the root team. System, confirm that the electronic signature of the team data list has not been tampered with and that it has been signed by an authorized person using the administrator information, and confirm the user's approval of the team master of the root team. Validity checking means, a team data list changing means for making a change in accordance with the operation request to the team data list verified by the validity checking means, and an instructor who has made the operation request Signature means for creating the electronic signature of the above, attaching the electronic signature to the changed team data list, and sending the electronic signature to the request destination.

According to a second aspect of the present invention, in the first aspect of the present invention, the manager information is a person designated by a member of the own team by the team master and has a management authority of the sub-team. And information on one or more sub-authorities having the sub-authority and the team master having the authority to manage the sub-authority in addition to the authority of the sub-authority. According to a third aspect of the present invention, in the first or the second aspect of the present invention, there is provided a registration means for acquiring and registering identification information for performing identity identification of the team master of the root team from a predetermined location, And a team master confirming means for confirming that an electronic signature of the authority data of the root team sent from the request destination is an electronic signature of the team master using the registered identification information. It is characterized by.

According to a fourth aspect of the present invention, there is provided a team data list storage device for storing a team data list for hierarchizing teams, comprising: an identifier representing a parent team of the own team; and a manager of the parent team. Authority data storage means for storing the authority data including the electronic signature of each team, manager information relating to the management authority of the sub-team under the control of the own team, and the team master or the master who is the manager of the own team. An authority list storing means for storing, for each team, an authority list including an electronic signature of an administrator of the parent team, and an operation request from a predetermined request source for the authority data and the team data list including at least the authority list The administrator information that the instructor of the operation request has request authority. In addition to using and confirming, the team data list requested for the reference request or the deletion request is returned or deleted to the request source, and for the update request, the electronic signature of the team data list sent from the request source is used. Authority confirmation means for confirming that the signature is a signature by an authorized person using the manager information, and updating the stored contents of the authority data storage means and the authority list storage means with the transmitted team data list. It is characterized by having. According to a fifth aspect of the present invention, in the fourth aspect of the present invention, the manager information is a person designated by a member in the own team by the team master and who has management authority for the sub-team. It is characterized in that it is information relating to the above-mentioned sub-authorities and the team master having the authority to manage the sub-authorities in addition to the authority of the sub-authorities. The invention according to claim 6 is
A team data list management device according to any one of claims 1 to 3 that is a request source and a team data list storage device according to claim 4 or 5 that is a request destination.

According to a seventh aspect of the present invention, there is provided a recording medium recording a team data list management program for managing a team data list for hierarchizing teams, wherein a predetermined request destination includes the team data list management program. A process for performing an operation request, and an authority including an identifier representing a parent team of the own team and an electronic signature of a manager of the parent team for each team from the team to be operated to the root team in response to the operation request. Team data having data, administrator information on the management authority of the sub-team under the control of the own team, and the authority list including the electronic signature of the team master who is the manager of the own team or the manager of the parent team. A process of obtaining a list from the request destination, and tracing each team obtained using the identifier to the root team Meanwhile, for each team, after confirming that the electronic signature of the team data list has not been tampered with and that the signature is signed by an authorized person using the manager information, the user approves the team master of the root team. And a change process for making a change in accordance with the operation request to the team data list whose validity has been confirmed by the validity check process; and a change process of the instructor who has performed the operation request. A computer that executes a process of creating an electronic signature, attaching the electronic signature to the team data list changed by the change process, and sending the list to the request destination.

According to a further aspect of the present invention, there is provided a recording medium storing a team data list storage program for storing a team data list for hierarchizing teams, wherein the identifier indicates a parent team of the own team and the identifier. The process of storing in advance the authority data including the electronic signature of the parent team's manager for each team, the management information on the sub team's management authority under the control of the own team, and the management of the own team. A process of storing in advance for each team an authority list including an electronic signature of a certain team master or an administrator of the parent team, and a team data including at least the authority data and the authority list from a predetermined request source When there is an operation request for the list, the administrator information indicates that the instructor of the operation request has request authority. When the operation request is a reference request or a deletion request, the requested team data list is returned or deleted to the request source, and when the operation request is an update request, the request is deleted. After confirming that the electronic signature of the team data list sent from the original is a signature by an authorized person using the manager information, the authority data stored in the sent team data list and the stored And a computer that executes the authority confirmation process for updating the authority list.

[0015]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described with reference to the drawings. First, a team data list in the present invention will be described. The team data list according to the present invention is a generic name of a list that defines information about a team, and defines a “set of members” that is applied to an application requiring highly confidential management such as the ACL described above. belongs to. As described above, in the conventional system, the terminal manager who is not a member of the team,
A network administrator, a server administrator, and the like can change information about the team. On the other hand, in the team data list according to the present invention, information on the team is divided into a plurality of lists (authority list, authority data and member list, team master list, application list, which will be described later) and managed, so that the team hierarchy can be obtained. Team management, such as licensing and changing the team master itself, can be performed only by members of the team.

In the embodiment which will be described in detail below, first, a mechanism for sharing information by simulating a hierarchical relationship in a company organization or the like is realized by enabling a sub-team to be created under a team. I have. Secondly, a mechanism has been realized that allows the authority to create sub-teams to be granted to a plurality of selected persons, thereby distributing the management burden so that the load is not concentrated on one administrator. Is being planned. Thirdly, a mechanism has been realized in which the sub-team creation authority is assigned to a specific person selected from within the sub-team for management within the sub-team. By doing so, the team manager does not need to be involved in managing and sharing information within the sub-team.

[First Embodiment] In the present embodiment, persons who can access the team data list are classified into three types of members, sub-authorities, and team masters according to the contents of the authority according to the hierarchized teams. In this order, the authority granted to that person expands. The team master is a manager of a certain team and has a management authority such as creation of a sub-team as an organization under the team. On the other hand, a sub-authority is a person designated by the team master and has administrative authority such as creation of a sub-team like the team master, but it is not allowed to appoint another person as a sub-authority . There may be multiple sub-authorities or no sub-authorities. On the other hand, general members other than the sub-authority and the team master are those who share information and functions, and are not given any privileges such as the right to create sub-teams. Although the sub authority and the team master are given special authority, they are still members of the team, and in that sense, the sub authority and the team master are sometimes referred to as members. In the following description and drawings, the team master may be abbreviated as “TM” and the sub authority may be abbreviated as “subAU”.

Hereinafter, the present embodiment will be described with respect to a system including two devices, a team data list management device and a team data list storage device. FIG. 1 is a block diagram showing the configuration of the entire system of the present embodiment including a team data list management device and a team data list storage device. In the figure, a team data list management device 30 and a team data list storage device 31 are provided with a team data list management function and a team data list storage function, respectively, which will be described in detail below. are doing. Each of the team data list management device 30 and the team data list storage device 31 can be realized by a general computer such as a workstation. Programs (team data list management program, team data list storage program) for realizing the list storage function are stored.

These programs are stored on a floppy disk, IC (integrated circuit) card, magneto-optical disk, CD-
A part or the whole is stored in a computer-readable storage medium such as a portable storage medium such as a ROM (compact disk-read only memory) or a large-capacity storage medium such as a hard disk built in a computer. . That is, the program may be for realizing a part of the functions described in detail below,
Further, these functions may be realized in combination with a program already recorded in a computer. Then, when operating the team data list management device and the team data list storage device, these programs are transferred from the storage medium to the main storage in advance under the instruction of the CPU (Central Processing Unit) on the computer. Thereafter, the CPU executes the program transferred to the main memory, thereby controlling each unit of the apparatus, and realizes various processes described in detail below.

The "computer" referred to here is O
It includes hardware such as S (operating system) and peripheral devices. In addition, the computer-readable storage medium is not limited to the one that statically stores the program as described above, and dynamically stores the program for a short time through a communication line such as a dedicated line or a telephone line. Main memory and cache memory built into computer equipment such as servers, routers, and gateways that hold, transfer, and relay programs and data over networks such as the Internet, and volatile memory inside computers that function as servers and clients. And all that can hold the program for a certain period of time.

A storage device 32 such as a hard disk which can construct a database is connected to the team data list storage device 31 shown in FIG. This storage device 32
Stores a set of a team data list including an authority data 33 and an authority list 34 for each team composed of a plurality of members. In the figure, the authority data 33 and the authority list 34 are shown for convenience of explanation.
Although only one set is shown, there are actually these sets as many as the number of teams. Here, FIG.
(B) shows a detailed structure of the authority data 33 and the authority list 34. 3C and 3D show notations for simplifying the storage contents of the authority data 33 and the authority list 34 in the following drawings. In the following description and drawings, the authority data may be abbreviated as “AUD” and the authority list may be abbreviated as “AUL”.

The authority data 33 is data representing the relationship between a certain team and the sub-teams under the team, and the team higher in the relationship with the sub-team is called the parent team. As shown in FIG. 2A, the symbol "AUD" indicates that the data is authority data, and the authority data 33 is assigned to a team ID 33a, which is an identifier assigned to its own team, and to a parent team of this team. The parent team ID 33b, which is the team ID, the team creator 33c indicating who created the parent team, the team master 33d indicating who has given the team master authority to the members belonging to this team, the team The signature 33e includes a digital signature (also referred to as an electronic signature) of the creator 33c. Further, in FIG. 2C, it can be seen that the authority data is related to the team 102 which is a sub-team of the team 101. In addition, the digital signature indicates that the team creator of the authority data is member B, and that the team master is member X.

On the other hand, the authority list 34 is a list in which a plurality of managers in each team are registered, and includes data on the team master and sub-authorities of the team. As shown in FIG.
L "means an authority list, and the authority list 34 is a team ID 34 for this team.
a, a team master 34b, a sub-authority 34c (two persons in the case of FIG. 3), and a signature 34d, which is a digital signature of the team master 34b. According to FIG. 2D, it can be seen that the team master is the member X, the signature of which is made, and the sub-authorities are the members C and D. Note that, in FIG.
The notation itself of D is omitted. As described above, the team data list according to the present embodiment has a structure in which the AUD is a list indicating the relationship between the parent team and the sub-team, and the AUL is a list related to the management of the sub-team.

The authority data 33 and the authority list 34 include, in addition to the data shown in FIG.
3e and the signature algorithm used to create the signature 34d, the expiration date of the authority data 33 and the authority list 34 itself, and data on the identification number of the authority data 33 and the authority list 34 itself. In addition, various types of IDs (identifiers) for identifying each of the members, sub-authorities, and team masters, such as names, e-mail addresses, organizational names, individual serial numbers, and digital certificates, may be used. Is possible.

Next, FIG. 3 shows an example of a conceptual diagram of a hierarchical team. As shown in the figure, the team hierarchy has a tree structure like a computer file system, and the ellipses in the figure represent teams, and the parent team and its sub-teams are connected to each other by straight lines. ing. A plurality of sub-teams can be registered in each team. For example, sub-teams such as a first HR section and a second HR section can be registered under the team of the HR department. Also, the team 101 existing at the top
Since this corresponds to the root of the tree structure, it is referred to as a “root” or a root team in the present embodiment, like a root directory on a file system.
Further, both the team 102 and the team 103 are sub-teams of the team 101 and belong to the same hierarchy on the tree. On the other hand, team 104
Is a sub-team.

On the other hand, FIG. 4 is a diagram in which specific values are entered for the authority list and authority data of each team in correspondence with the team hierarchy shown in FIG. FIG. 3 shows an example in which each team includes a member list (“ML” in the figure) showing a list of shared members sharing information and functions with each other, in addition to the authority list and the authority data. is there. That is, in this figure, the team data list is composed of three types of lists: authority list, authority data, and member list. Each of the member lists 101m to 104m shows the signature of the creator of the member list and a list of members, but also includes management information of various teams that match the purpose of use of the team. That is, identification information of each member, a public key (that is, a bit string of a predetermined length) assigned to each member in a public key system, an identifier of a holder corresponding to this public key (hereinafter, referred to as “public key ID”),
The information includes a team ID, a time stamp indicating a creation time of a member list, information on a function (for example, an application) that can be used by members in the team, and the like. In addition, each member list also includes information such as an e-mail (e-mail) address and the member's own address as information on each member, and by using these, management of information resources regarding each member is simultaneously performed. It can be carried out.

According to the configuration shown in the figure, by following the parent team ID described in the authority data, it is possible to reach the root team 101 from any sub-team. In addition, in each team, a plurality of managers can create sub-teams. For example, in the team 101, the team master A and the sub-authorities B and C have the authority to create a sub-team, and the authority data 10
As can be seen from the signatures 2d and 103d, the sub-teams 102 and 103 are created by the sub-authorities B and C of the team 101, respectively.

The authority data of a certain sub-team is to be created by a manager registered in the parent team of the sub-team. Also, anyone in the sub-team can become the team master of this sub-team according to the instruction of the manager of the parent team. For example, in team 104,
The digital signature of the authority data 104d is Member V
Therefore, the sub-authority V, one of the administrators of the parent team 103, has created the authority data 104d, and has designated the member L as the team master of the team 104.

On the other hand, the authority list is created and signed by the team master of each team. For example, the authority list 103u of the team 103 is created by the member X as the team master, and has a digital signature of the member X. for that reason,
Only the member X can manage the data related to the sub-authorities in the authority list 103u, and there is no interference from the manager of the team 101 as the parent team (that is, the team master A and the sub-authorities B and C). In other words, if the signer of the authority list is the creator of the team (that is, the team master or sub-authority of the parent team), for example, the HR manager cannot assign the HR manager to manage the section. You have to manage it yourself. Similarly, since the team master of each team also signs the member list, the management of the shared members in each team does not need to be interfered by the parent team. For example, the member list 103m of the team 103 is signed by the team master X and cannot be managed by the parent team manager. However, if the initial state when the sub-team is first created, or if the sub-team's team master is changed by the parent team's team master or sub-authority, the signature of the authority list will be the parent team that created the sub-team. Of the team master or sub authority.

To summarize the above points, in the present embodiment, the authority data and the authority list are separated, and the parent team can refer to the authority data AUD of the sub team, while the administrator of the parent team can read the authority data AUD. By preventing the list and member list from being tampered with, the parent team is not involved in the management inside the sub-team. As a result, the team master of each team can select the sub-authority by itself, and can also manage information sharing members within the team.

Next, in the team data list storage device 31 shown in FIG. 1, the authority confirmation function 35 transmits the authority data 33 and the authority list 34 from the client CL side.
When there is a request for reference, change, or deletion of the request, the requester is identified, and whether these requests are permitted or rejected is determined. In making this determination, the requestor is given the authority of the team members, the team master, the sub-authority of the team being requested, the relationship between the team and the parent team or sub-team, and the requester himself. Are compared with the authority they have. That is, since the details of the determination procedure differ depending on the request content, the details will be described later in the operation description. Next, list storage function 3
Reference numeral 6 denotes a process in which when the authority confirmation function 35 uses the authority data 33 and the authority list 34, these lists are acquired from the storage device 32, deleted from the storage device 32, or stored in the storage device 32. . In the following description, it is assumed that the list storage function 36 always intervenes when the authority confirmation function 35 accesses the authority data 33 and the authority list 34.

Next, in the team data list management device 30, the list validity confirmation function 37 sequentially traces the authority list and the authority data of the parent team up to the root team, and finally the team master A of the team 101 The signature is checked to verify the validity of the authority list and the authority data. Note that the validity here means that the management of the team hierarchy is performed through a valid procedure without any tampering or overright act. Next, the AUD / AUL change function 38 changes the authority data 33 and the authority list 34 acquired by the list validity check function 37 such as addition, deletion, and replacement of members and managers, and creates a sub team. At times, the authority data 33 and the authority list 34 may be newly created. Next, the electronic signature function 39 uses the hash function together with the encryption using the secret key or signature key known only to the changer, for the authority data 33 and the authority list 34 processed by the AUD / AUL change function 38. Then, a digital signature of the creator or modifier of these lists (ie, the team master or sub authority) is added.

Next, the public key management function 40 accesses the public key database 41 connected to the team data list management device 30, and acquires the public key and the public key ID corresponding to the public key. By the way, in the actual form,
The public key database 41 is not limited to a local form directly connected to the team data list management device 30,
A form in which a server (for example, a certificate authority) installed on a network such as the Internet exists can be considered. According to such an embodiment, the public key management function 40 accesses the public key database 41 via a homepage registered on the certificate authority, and obtains the above-mentioned public key and public key ID therefrom in a file format. It becomes possible.

Next, the operation of the system having the team data list management device 30 and the team data list storage device 31 having the above configuration will be described for each request made by the client CL to the server SV.

[Creation of Sub-Team] FIG. 5 shows a processing procedure for creating a sub-team. Here, member C which is a sub authority of team 101 shown in FIG.
However, it is assumed that a sub-team 103 having the team master as a member X is created under the team 101. This corresponds to a case where a deputy manager of the HR department performs a task of establishing a new section under the HR department on behalf of the HR department manager. Here, in the team data list storage device 31, a team data list for the team 101 created according to a valid procedure is stored in the storage device 32 in advance, and the root team 101
The sub-team is created by the management system of the team master A. As shown in FIG. 4, since the parent team does not exist in the team 101, the authority data 101
A fixed value “Root” is set in the parent team ID of “d”, and the authority data 101d and the authority list 101u are both digitally signed by the member A because the team master is the member A. Of course, it can be considered that the root team virtually has a parent team called "Root", and that the parent team has designated member A as the team master.

First, in accordance with the sub-team creation instruction from the member C, the team data list management device 30 sends a sub-team creation request to the team data list storage device 31 (step S11). Team data list storage device 3
1 acquires the authority data 101d and the authority list 101u from the storage device 32 and sends them to the team data list management device 30. At this time, the team data list storage device 31 sends the team data list relating to the sub-teams (that is, the team 102 shown in FIG. 4) to the team data list management device 30 together with the sub-teams (that is, the team 102 shown in FIG. S1
2). In the team data list management device 30, AUD /
The AUL change function 38, based on the instruction from the member C,
Parent team ID is team 101, team ID is team 10
3. Create the authority data 103d with the team master as the member X and create the team master as the member X
Is created. Next, the AUD / AUL change function 38 transfers the created authority list 103ua to the electronic signature function 39 together with the authority data 103d.

The electronic signature function 39 obtains a secret key related to the member C from a secret key file or an IC card in which the secret key is recorded, and based on this, the AUD / AUL change function 38
The digital signature of the requesting member C is performed on the authority data 103d and the authority list 103ua sent from the company. Authority list 1 at this time
The signature of 03ua is not the signature of the team master X, but the signature of the creator of the sub-team (step S1).
3). Next, the electronic signature function 39 stores the authority data 103 d and the authority list 103 ua created for the team 103 in the team data list storage device 3.
1 to request these storages (step S1).
4).

In the team data list storage device 31, the authority confirmation function 35 confirms the authority shown in the flowchart of FIG. First, the authority confirmation function 35 identifies that the requester who made the storage request is the member C (step S3).
1) Authority data 10 on team 101
1d and the member list C based on the authority list 101u.
It is determined whether or not is the team master or sub authority of the team 101 (step S32). In this case, since member C is a sub-authority of team 101,
It is determined to be a request to save data created by a person with valid authority (the determination result in the step is “YES”).
Incidentally, if the result of the determination in the step is "NO", there is tampering or fraudulent activity, and the authority confirmation function 35 stops the processing without performing the required saving operation.

Next, the authority confirmation function 35 confirms that the signatures of the created authority data 103d and authority list 103ua of the sub-team 103 are both those of the requesting member C (step S33).
In this case, as described above, the result of the determination in this step is "YES" because the member C has signed all the members, and the authority confirmation function 35 finally determines that the sub-team has been created with normal authority. Then, the created sub-team authority data 103d and the authority list 103u
a is stored in the storage device 32 (step S34). By the way, if the result of the determination in step S33 is "NO", there is tampering or fraudulent activity, so that the authority confirmation function 35 stops the processing without performing the required saving operation (the above-mentioned processing is stopped). The processing corresponds to step S15 in FIG. 5). With the above procedure, the creation of the sub team is completed.

Thereafter, it is assumed that there is a management request from the member X, which is the team master of the team 103, to the team 103, such as information sharing members and sub team creation authority. Here, as an example, the team 103
A case where members W and V are newly registered as sub-authorities will be described. As shown in FIG.
First, the team data list management device 30 stores the team data list relating to the parent team 103 based on the management request instructed by the member X.
1 (step S16). Then, the team data list storage device 31 stores the team data lists of all the parent teams (in this case, only the root team 101) up to the root team in addition to the sub team 103 based on the request contents. The data is transferred to the list management device 30 (step S17). In the team data list management device 30, the list validity check function 37 checks the validity of the transferred list according to the processing procedure shown in the flowchart of FIG. 7 (step S18).

First, the list validity confirmation function 37 performs the authority data 103d of the team 103 to be managed.
The digital signature of the authority list 103ua is referred to to confirm whether or not they have been tampered with (Step S41). Is "NO"). On the other hand, the determination result of the step is “YE
S ”and if there is no tampering, list validity check function 3
7 can confirm from the authority data 103d that the member X is the team master of the team 103. Here, normally, the list validity confirmation function 37 confirms from the authority list 103ua that the signer is the member X who is the team master. However, as described above, this point is a transition period in the process of creating the sub team, and the signer of the authority list 103ua is the member C who is the sub team creator.
It is confirmed whether or not has the right to create a sub-team by checking whether or not the member C is registered as a team master or a sub-authority of the parent team 101 in a process described later (step S45) (step S42). ).

Next, the list validity confirmation function 37 knows that the parent team is the team 101 from the parent team ID of the authority data 103d (step S43), and the digital signature of the parent team's authority data 101d and the authority list 101u is entered. It is checked whether it has been falsified (step S44). If any one of these has been tampered with, the list validity checking function 37 stops the process (the determination result in the step is “NO”), but the determination result in the step is “YES”. "
If there is no tampering, it is confirmed whether or not the creator of the team 103 is the team master or sub authority of the parent team (step S45). In this case, the signer of the authority data 103d of the team 103 is the member C, and it is understood from the authority list 101u of the parent team 101 that the member C is registered as a sub-authority of the parent team. It can be confirmed that the file has been created by a person who has valid creation authority (the determination result of the step is “Y
ES ”). If the determination result in the step is“ NO ”, the list validity confirmation function 37 determines that there has been an illegal act and stops the processing.

Next, the list validity check function 37 checks whether or not the parent team 101 is the root. In this case, since the parent team ID of the authority data 101d of the team 101 is "Root", the root team (The determination result of step S46 is “Y
ES "). Then, the list validity checking function 37 checks the authority data 101d of the team 101 to find out that the team master is the member A. Then, the authority data 101d is determined by the member A.
Since the authority list and the authority list 101u are signed, it can be confirmed that the team hierarchy is properly managed under the team master A (step S47). Lastly, the member X itself operates the team data list management device 30 to use the team data list for information sharing and the like for the hierarchical team under the team hierarchy managed by the team master A of the root team 101. It approves that it has been used, and notifies the list validity confirmation function 37 of this fact.

According to the procedure described above, the list validity check function 37 determines that the sub-authority C designated by the team master A of the team 101 has created the authority data and the authority list relating to the team 103. It can be confirmed that these team data lists are obtained in a normal state. Therefore, the list validity confirmation function 37 converts the team data list transferred from the team data list storage device 31 into an AUD.
• Pass to the AUL change function 38. Note that step S in FIG.
If the parent team is not determined to be the root team in 46, for example, the team 10 which is a sub-team of the team 103
When the management request is made to the fourth team, the list validity confirmation function 37 changes the target team to the parent team and goes up the team hierarchy toward the root team by one (step S).
49), the loop including steps S42 to S46 and step S49 is repeatedly executed until the parent team becomes the team 101 as the root team (the determination result in step S46 is “YES”).

Next, the AUD / AUL change function 38 creates an authority list 103u in which the members W and V are added as sub-authorities to the authority list 103ua of the team 103, and uses this together with the authority data 103d as an electronic signature function. Pass to 39. The electronic signature function 39 acquires the secret key related to the team master X from the above-described secret key file and the like, signs the passed authority list 103u with the team master X (above, step S19), and transmits the signature to the authority. Team data list storage device 3 with data 103d
1 to make a save request for these team data lists (step S20).

In the team data list storage device 31, the authority confirmation function 35 is provided by the team data list management device 3.
In response to the save request from the client device 0, based on the team data list related to the team 101 stored in the storage device 32 and the team data list related to the team 103 transferred from the client side, the authority shown in the flowchart of FIG. Make a confirmation. That is, first, the authority confirmation function 35
Identifies that the requester who instructed the storage request is the member X (step S51), and based on the transferred authority data 103d and authority list 103u, the requester determines the team master of the team 103,
It is checked whether any one of the team master and the sub-authority of the parent team 101 matches. In this case, since the requester member X is registered as the team master of the team 103 (the determination result in step S52 is “YES”), the authority confirmation function 35 has the requester having the right authority for the storage request. Judge. By the way, if the result of the determination in this step is "NO", the authority confirmation function 35 assumes that the requester has not been given valid authority and stops the processing.

Next, the authority confirmation function 35 confirms whether or not the signer of the authority data 103d matches either the team master of the parent team or the sub authority.
In this case, since the signer of the authority data 103d is the member C and the sub-authority of the parent team 101 (the determination result in step S53 is "YES"), the authority confirming function 35 determines that the requester has the right authority for the storage request. Judge to have. By the way, if the result of the determination in this step is “NO”, the authority confirmation function 35 stops the processing as if there has been tampering or illegal action. Next, the authority confirmation function 35 confirms whether or not the signer of the authority list 103u matches the team master registered in the authority data 103d. In this case, the signer of the authority list 103u is the authority data 1
03d is the team master X (the determination result in step S54 is "YES"), the authority confirmation function 35 makes a final determination that the team 103 has been created by a person having normal authority, and The team data list transferred from the data list management device 30 is stored in the storage device 32.
And updates the contents of the team data list for the team 103 (step S55). If the result of the determination in step S54 is "NO", the authority confirmation function 35 cancels the processing on the assumption that there has been tampering or fraudulent activity, and does not execute the above-described storage processing in step S55.

As described above, based on the team data list stored in the server SV, the member X is definitely appointed as the team master of the team 103 in the management system by the team master A of the root team. This can be verified (step S21 in FIG. 5).

<Change of Sub-Team Team Master> Next, a processing procedure for changing the sub-team team master will be described with reference to FIG. Here, a case will be described as an example in which member B registered as a sub-authority in the root team 101 changes the team master of the sub-team 103 from member X to member Z. This corresponds to a case where a section manager of HR has been changed and the deputy manager changes the section manager instead of the HR manager. First, the team data list management device 3
0 sends a request to change the team data list relating to the sub team 103 to the team data list storage device 31 (step S61). Thus, the team data list storage device 31 stores the team 1 in the same manner as in step S12 of FIG.
Then, the team data list relating to the sub-team 01 and its sub-teams is transferred to the team data list management device 30 (step S62).

In the team data list management device 30, the list validity check function 37 verifies the validity of the transferred team data list according to the processing procedure described in FIG. 7 (step S63), and the validity is verified. AUD / AU is used to transfer the transferred team data list when it is completed.
Deliver to the L change function 38. AUD / AUL change function 3
8 is the authority data 103d of the delivered team data list according to the instruction content from the member B.
The team master is changed from member X to member Z, and the changed authority data and the passed authority list are sent to the electronic signature function 39. The electronic signature function 39 obtains the secret key of the member B from the above-mentioned secret key file or the like and applies a digital signature to the team data list, thereby performing the authority data 103db and the authority list 1
After creating the 03ub (step S64), these team data lists are transferred to the team data list storage device 31 and a storage request is made (step S65).

In the team data list storage device 31, the authority confirmation function 35 performs authority confirmation in accordance with the procedure shown in FIG. 8 based on the transferred team data list, and when its validity is confirmed. Then, the transferred team data list is stored in the storage device 32. Here, the difference from the sub-team creation (step S21 in FIG. 5) is that the authority list 10 is used in the team master change processing.
Member B who is a 3ub signer and authority data 1
That is, the team master member Z designated at 03db is different (a case where the determination result of step S54 is "NO"). Therefore, in this case, the authority confirmation function 35 determines that the authorized authority is valid if the signer of the authority list 103ub matches any of the team masters A, sub-authorities B, and sub-authorities C, which are managers registered in the parent team. It is determined that the signature is by the holder. As described above, on the server SV side, two sets of authority lists and authority data having different creation times, ie, each team data list before and after the change of the team master, are stored as team data lists relating to the team 103. After that, the team data list storage device 3
1 transfers the authority data 103db and the authority list 103ub to the team data list management device 30 in order to add the signature of the member Z who is the new team master of the team 103 to the authority list 103ub (step S66).

In the team data list management device 30, the list validity confirmation function 37 verifies the validity of the transferred team data list according to the processing procedure of FIG. 7, and then verifies the validity via the AUD / AUL change function 38. To the electronic signature function 39. The electronic signature function 39 obtains a secret key related to the member Z from the above-described secret key file or the like, and performs a digital signature of the member Z on the authority list 103ub based on the acquired secret key, thereby obtaining the authority list 103u.
c is created (step S67). Next, the electronic signature function 39 transfers the created authority list 103uc to the team data list storage device 31 together with the authority data 103db (step S68). In the team data list storage device 31, the authority confirmation function 35 confirms the authority based on the transferred team data list according to the processing procedure of FIG. 8, and when the validity is confirmed, the transferred team data list Is stored in the storage device 32, and the team data list relating to the team 103 is updated. Thus, the team master has been changed following the normal procedure.

<Change of Sub-Authority> Next, a processing procedure for changing the sub-authority will be described with reference to FIG. Here, the team 10 which is the route
A case will be described as an example in which one team master A denies the creation authority of the member B registered as a sub authority in the team 101. This corresponds to, for example, a case where the deputy manager is transferred and the human resources manager removes this deputy manager from the human resources department. Note that FIG. 9 is based on the premise that the team 103 is the creator of the sub authority B due to the change of the team master shown in FIG. Also, in the figure, the case where the team 103 is deleted along with the deletion of the authority to create the sub-authority B,
Two cases where the team 103 is continued are shown together. Therefore, when the member A instructs the request to the team data list management device 30, the member A also instructs whether to keep the team 103 or not.

First, the team data list management device 30 sends a change request (deletion request) for the sub-authority B registered in the team 101 to the team data list storage device 31 (step S71). Thus, the team data list storage device 31 refers to the authority data of the sub-teams under the team 101, searches the sub-teams for the team 103 whose sub-team B is the creator, and then searches the team 103 101
And the team data list relating to the team 103 are transferred to the team data list management device 30 (step S7).
2). In the team data list management device 30, the list validity confirmation function 37 performs the processing according to the processing procedure described in FIG.
The validity of the transferred team data list is verified, and if the validity can be verified, the transferred team data list is delivered to the AUD / AUL change function 38.

The AUD / AUL change function 38, based on the contents of the instruction from the member A, the authority list 101ub in which the member B is deleted from the sub-authorities described in the authority list 101u in the delivered team data list. (Step S7)
3). In addition to this, the AUD / AUL change function 38 provides the member B assigned to the authority data 103db.
Is deleted and the authority data 103dc is created (step S74). Thereafter, the AUD / AUL change function 38 sends the authority data 103dc and the authority list 103uc to the electronic signature function 39.

The electronic signature function 39 performs one of the following two processes in accordance with the instruction content from the member A. First
If there is a request to continue the team 103, the electronic signature function 39 determines that the team 103 exists
, And obtains the secret key for member A from the above-described secret key file and the like, and based on this, attaches the signature of member A to authority data 103dc to create authority data 103dd (step S7).
5). Next, the electronic signature function 39 executes the authority data 101d and 103dd and the authority list 101u.
b and 103 uc are transferred to the team data list storage device 31 to make a request to save these team data lists (step S76). In the team data list storage device 31, the authority confirmation function 35 performs authority confirmation in accordance with the procedure shown in FIG. 8 based on the transferred team data list. The content of the storage device 32 is updated with the team data list (step S77).

Second, if a request to delete the team 103 has been received, the electronic signature function 39
In step S78, the team data list relating to No. 1, that is, the authority data 101d and the authority list 101ub are transferred to the team data list storage device 31, and an instruction to invalidate the team 103 is sent to the team data list storage device 31. In the team data list storage device 31, the authority confirmation function 35 stores the authority list 101u stored in the storage device 32.
By comparing the authority list 101ub sent to the sub authority B, the deletion of the sub authority B can be recognized. In addition to this, the authority confirmation function 35 knows from the contents of the authority data 101d and the authority list 101ub that the team master is the member A and all of these team data lists are digitally signed by this member A. Accordingly, the authority confirmation function 35 determines that the team master A has deleted the sub-authority B with the proper authority, and based on the authority data 101d and the contents of the authority list 101ub, the team data list of the team 101 in the storage device 32. To update. Next, the authority confirmation function 35
2 delete the authority data and the authority list relating to the team 103 from above (step S7).
9). As described above, the authority to create the sub authority B is deleted from the team data list on the server SV.

<Deletion of Sub Team> Next, a processing procedure for deleting a sub team will be described with reference to FIG. Here, a case where the member C registered as a sub-authority in the team 101 as the root deletes the team 103 created by the above-described processing procedure of FIG. 5 will be described as an example. This is equivalent to the case where the HR section under the HR department has been abolished, and the deputy director of HR conducts work related to the abolition of the section. Here, member C
Is a sub-team with the authority of the sub-authority of the team 101 corresponding to the parent of the team 103.
In order to delete 3, it is necessary to prove to the team data list storage device 31 that he / she is definitely the member C himself. Therefore, the team data list management device 30 notifies the team data list storage device 31 of the electronic signature of the member C as described later.

When the member C first instructs the team data list management device 30 to delete the team 103, the team data list management device 30 sets the electronic signature function 3
9, a command to delete the team 103 with the authority of the member C, and a command to delete the team 103
Team data list storage device 31 with the electronic signature of
(Step S81). As a method other than attaching a digital signature, "Shake Hand" or "Challenge Response" to certify at the time of transfer of a deletion instruction
Although it is conceivable to employ a method called (hereinafter described in detail), here, the description will be made along a method using an electronic signature, and the shake hand will be described last.

When the team data list storage device 31 receives an instruction to delete the team 103 from the team data list management device 30, the authority confirmation function 35 refers to the team data lists relating to the teams 101 and 103 and is registered in the team 101. Know that the sub authority C is the creator of the team 103. Further, the authority confirmation function 35 checks the signature of the member C described in the authority data 103d and the signature of the member C attached to the deletion instruction, and confirms that they match, thereby deleting the member C. Can be confirmed that the person who instructed is definitely the member C himself. Thus, the authority confirmation function 35 determines that the instruction is a delete instruction issued with valid authority, and deletes the authority data 103d and the authority list 103u relating to the team 103 from the storage device 32 (step S82). This completes the process of deleting the team 103 by the sub authority C.

Since the member A is the team master of the team 101, the member A has the right to delete the team 103 as a sub-team instead of the sub-authority C. In this case, when the member A instructs the team data list management device 30 to delete the team 103, the team data list management device 30
9 to create a digital signature for member A,
Then, an instruction to delete 3 with the authority of the team master A and the electronic signature of the member A are transferred to the team data list storage device 31 (step S83). In the team data list storage device 31, the authority confirmation function 35 refers to the team data list relating to the teams 101 and 103, and the sub authority C registered in the team 101 is referred to.
Is the creator of the team 103, and the sub authority C is designated as the sub authority by the team master A of the parent team 101. In addition, the authority confirmation function 35 is provided for the authority data 10.
By checking the signature of the member A described in 1d with the signature of the member A attached to the deletion instruction, it is confirmed that the person who instructed the deletion is the member A himself. Thus, the authority confirmation function 35 determines that the instruction is a delete instruction issued with valid authority, and deletes the authority data 103d and the authority list 103u relating to the team 103 from the storage device 32 (above, step S84).

As described above, the process of deleting the team 103 by the team master A is completed. In addition to the members described above, for example, it is also possible to delete the team 103 in which the member B registered as a sub authority in the team 101 is a sub team.

Lastly, the details of the above-described shake hand or challenge response processing procedure will be described with reference to FIG. First, the client CL is the server SV
When the user is accessed, the user name and user public key of the user (member C or member A in the case of FIG. 11) are sent to the server SV (step S101). Server S
V generates a random number, stores it internally, encrypts the random number with the user public key (step S102), and transmits the encrypted data to the client CL as “challenge data” (step S103). The client CL decrypts the challenge data sent from the server SV with a secret key corresponding to the user public key (step S10).
4) Then, the obtained decrypted data is returned to the server SV as a “challenge response” (step S10).
5). The server SV compares the challenge response sent from the client CL with the random number generated in step S102 to confirm the communication partner. That is, if they match, it can be confirmed (successful authentication) that the person who knows the secret key corresponding to the user public key sent in step S101 is the communication partner. On the other hand, if the two do not match, it can be understood that the communication partner may not be a person with valid authority (authentication failed) (step S106). Thereafter, the server SV proceeds to step S10
The client CL is notified of the confirmation result (authentication success or authentication failure) obtained in step 6 (step S107). By doing so, the server SV can confirm that the members C and A are the same as in the case where the digital signature is attached.
You can check on the side.

Incidentally, instead of sending the user public key from the client CL to the server SV, a "user public key number" may be sent. The user public key number referred to here is information for identifying and authenticating the user himself / herself, and is a serial number assigned to each user public key in advance. More specifically, the user public key number is information corresponding to each user public key for uniquely identifying the user public key. For example, the user public key number included in the certificate issued from the above-described certificate authority is This is the certificate serial number. Further, as information for identifying and authenticating the user himself / herself, various information such as an ID and a name for actually identifying the key creator himself / herself can be used in addition to the user public key number just described.

[Second Embodiment] FIG. 13 shows a hierarchical structure of a team according to the present embodiment, in which an application which can be used by members of the team is different for each team. FIG. 3 shows only the teams corresponding to the teams 101 to 103 among the teams shown in FIG. The authority list and authority data are the same as those shown in FIG.
In addition, each team has an application list 101 including the contents of the member list instead of the member list.
a, 102a and 103a are provided. That is,
In these application lists, a list of members belonging to each team is described, in addition to available systems of members belonging to each team. For applications, for example, a personnel management system, an accounting system, a schedule, and a file sharing system are registered in the application list 101a of the team 101. The member list is the same as that described in the member list of FIG.

In the second embodiment, similar to the first embodiment, the generation of a team is interfered by the parent team. However, since the application list is signed by the team master of each team, management within the team is controlled by the parent. It can be done without interference from the team. In other words, the team master can determine independently which members can use the applications available in the team independently of the manager of the parent team. For example, in the team 102 which is a sub-team of the team 101, the signature of the application list 102a is signed by the member Y which is the team master of the team 102, and the team master A and the sub-authorities B and C which are the managers of the team 101.
You do not have to interfere.

[Third Embodiment] In this embodiment, in addition to the above-mentioned authority sharing of members, sub-authorities, and team masters from the viewpoint of managing sub-teams,
Persons belonging to each team are classified into three types: members, submasters, and team masters, as a division of management authority within the team for sharing information. Of these, the submaster is a manager in the team designated by the teammaster, and is not allowed to change the teammaster or submaster, but can add, delete, or change general members. It is. On the other hand, a team master is a person who can change a submaster or a member, and can even change its own team master. On the other hand,
General members other than the submaster and the team master are those who share information and functions provided to the members, and have no authority to change the contents of the team data list. Although the submaster and the team master are also given special authority, they are still members of the team, and in that sense, the submaster or the team master may be called a member.

FIG. 14 shows the hierarchization of teams in this embodiment. In the figure, a team master list is further added to each team of the first embodiment shown in FIG. In this way, information sharing is managed for each team, and a plurality of managers can manage information sharing members in each team. FIG.
, The team master lists 101t to 104t include a list of team masters and submasters registered for each team, and a signature of the team master. However, in addition to this, the team master list includes identification information of the team master or the submaster, a public key, a public key ID, a team ID, a time stamp indicating a creation time of the team master list, and the like. In addition, the team master list 34 includes information on the team, such as the number of team members, the time when the team was created, and various functions that can be used by each member in the team (for example,
The above-mentioned application list is also included, and by using these, information resources for each team can be managed at the same time.

The signature of the team master list is signed by the team master of each team when the team is created, and has been the signature of the team master ever since. On the other hand, regarding the member list, in addition to the team master in each team, since the submaster has been given the authority to manage the member list, the submaster may be signed in addition to the team master. For example, regarding member list 101ma, member B registered as a submaster of team 101
Has been signed. On the other hand, like team 102,
If no submaster is registered in the team master list 102t, the member list 102ma is signed by the member B as the team master.

In FIG. 14, the management authority of the sub-team and the management authority of the members are divided into the authority list / authority data and the team master list, respectively. it can. For example, team 103
, Members W and V are sub-authorities,
Since members Y and Z are sub-masters, different persons can be in charge of sub-team management and member management to achieve load distribution. However, actually, the sub authority and the sub master may be the same member. In that case, the authority list and the member list can be integrated into one list.

[Fourth Embodiment] In each of the above-described embodiments, each time the team data list is used, the user needs to confirm on the client CL side whether or not the team master is definitely his / her own team master. For example, on the display of the computer constituting the team data list management device 30, "This list is normally managed by the following members as an administrator. Name: Member A. Organization: Mitsubishi Materials Corporation. If you want to continue, click the OK button with the mouse. " As described above, since the user needs to visually confirm the message, it cannot be said that there is no possibility of giving a troublesome impression to the user. In order to improve such points, the following functions are added as new functions that cooperate with the list validity confirmation function 37, or are incorporated as one function of the list validity confirmation function 37.

That is, the public key of the team master in the root team 101 is previously determined for each team by the client CL.
For example, the public key database 41 is registered in the public key database 41 (see FIG. 1), and the public key management function 40
A public key related to the team master of the team 101 is obtained from 1 and the public key is notified to the list validity confirmation function 37. Alternatively, a serial number or the like for identifying a public key is registered in the public key database 41 as information on the public key, and after the public key management function 40 acquires this serial number from the public key database 41, A public key registered outside of the team data list management device 30 (for example, on the Internet) may be separately obtained and passed to the list validity confirmation function 37.

On the other hand, the list validity confirmation function 37 outputs the above-mentioned message on the display of the computer, and, based on the public key of the team master of the team 101 notified from the public key management function 40, The digital signature of the team master included in the authority data 101d transferred from the data list storage device 31 is confirmed, and it is determined whether or not the signature belongs to the registered team master. This allows the user to verify the validity of the team master of the root team 101 without visually confirming the display on the display. Of course, various information other than the public key can be used as the information for confirming the team master.

As described above, in the recording medium on which the team data list management program for managing the team data list for hierarchizing the teams is recorded, the team data list management program (1) transmits the team data list to a predetermined request destination. Processing for requesting a list operation; and (2) for each team from the operation target team to the root team in response to the operation request, an identifier representing the parent team of the own team and an electronic signature of the manager of the parent team. Authority data that includes the authority data that includes the information of the administrator of the sub-team under the control of the own team, and the electronic signature of the team master who is the administrator of the own team or the administrator of the parent team A process of obtaining a team data list having a list from the request destination; and (3) obtaining the team data list using the identifier. After tracing each team to the root team for each team, after confirming that the electronic signature of the team data list has not been tampered with and that it is a signature by an authorized person using the manager information, (4) a change in accordance with the operation request is made to the team data list, which has been verified by the validity check process, to confirm the user's approval of the team master of the root team. And (5) processing of creating an electronic signature of the instructor who has made the operation request, attaching the electronic signature to the team data list changed by the change processing, and sending the list to the request destination. Let the computer run.

In the above-mentioned team data list management program, the validity confirmation processing is performed by one or more sub-teams designated by the team master from members of the own team and having the authority to manage the sub-team. Information on the authority and the team master having the authority to manage the sub authority in addition to the authority of the sub authority may be used as the administrator information. Further, the above-described team data list management program obtains identification information for performing personal identification of the team master of the root team from a predetermined location and pre-registers the identification information. Every time authority data is sent,
Using the identification information registered in advance, the computer may further execute a process of confirming that the electronic signature of the authority data is the electronic signature of the team master.

On the other hand, in a recording medium recording a team data list storage program for storing a team data list for hierarchizing teams, the team data list storage program includes: (1) an identifier representing the parent team of the own team; A process of storing in advance for each team authority data including an electronic signature of a parent team manager;
(2) For each team, an authority list including the management information on the management authority of the sub-team under the management of the own team and the team master who is the manager of the own team or the electronic signature of the manager of the parent team is provided. (3) when an operation request is made to a team data list including at least the authority data and the authority list from a predetermined request source, the instructor of the operation request sets the request authority. Is confirmed using the manager information, and if the operation request is a reference request or a deletion request, the requested team data list is returned or deleted to the request source, and the operation request is updated. If it is a request, the administrator information indicates that the electronic signature of the team data list sent from the requester is a signature by an authorized person. After confirming with, to perform the permission check process of updating the authority list the being authority data and stored stored in the sent team data list to the computer.
Further, in the above-mentioned team data list storage program, the authority confirmation processing includes one or more sub-authorities designated by the team master from members of the own team and having management authority for the sub-team,
Information on the team master having the authority to manage the sub authority in addition to the authority of the sub authority may be used as the administrator information.

[0077]

As described above, according to the present invention, sub-teams can be created under each team by using the authority list and the team data list including the authority data. Can be built. Also, the user can confirm the validity of the team data list for each team from the operation target team to the root team only by checking the signature of the team master of the root team. Further, anyone can become a team master who manages the inside of the sub team according to the instruction of the manager of the parent team. In the present invention,
The team data list is divided into the authority data under the control of the parent team and the authority list related to the management of the own team, and the team master of each team manages the information sharing members without interference from the parent team Management within the sub-team, while the manager of the parent team does not need to be involved in the management within the sub-team. Further, in the present invention, since an electronic signature by a person having valid authority is included in the team data list, it is possible to detect an illegal act such as falsification.
Further, according to the present invention, when an operation request for the team data list is made, the authority confirmation of whether or not the instructor of the request has the authority is performed.
It is possible to prevent improper activities by a general member of the team, a cracker, or other unauthorized person. Further, in the present invention, sub-team management authority is given to the selected team master and one or more sub-authorities, and the team master itself can appoint a sub-authority, and a plurality of managers can assign the sub-team. The management burden is distributed because it can be managed. Further, in the present invention, identification information such as a public key for identifying and authenticating the team master of the root team is registered in advance, and the team master of the root team is confirmed based on the identification information. This eliminates the need for a troublesome operation such as a visual check by the user himself / herself each time the team data list is operated, and the team master of the root team can be automatically approved.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration of a system having a team data list management device and a team data list storage device according to a first embodiment of the present invention.

FIG. 2 is an explanatory diagram showing a structure of a team data list stored in a server provided with a team data list storage device in the embodiment; FIG. 2 (a) is a structure of authority data; Is the structure of the authority list, (c) is a simplified notation of the authority data, (d)
Is a simplified notation for the authority list.

FIG. 3 is an explanatory diagram showing an example of a team hierarchy in the embodiment.

FIG. 4 is an explanatory diagram in which specific values of a team data list are entered for each team in the team hierarchy shown in FIG.

FIG. 5 is an explanatory diagram showing a processing procedure for creating a sub team in the embodiment.

FIG. 6 is an explanatory diagram showing a processing procedure of a server-side authority confirmation function performed at the time of a sub-team creation request in the process of FIG. 5;

FIG. 7 is an explanatory diagram showing a processing procedure related to a client-side list validity verification performed in the process of FIG. 5;

8 is an explanatory diagram showing a processing procedure when the server side confirms the authority of a team data list newly created on the client side in the process of FIG.

FIG. 9 is an explanatory diagram showing a processing procedure for changing a team master of a sub team in the embodiment.

FIG. 10 is an explanatory diagram showing a processing procedure for changing (deleting) the authority to create a sub authority in the embodiment.

FIG. 11 is an explanatory diagram showing a processing procedure for deleting a sub team in the embodiment.

FIG. 12 is an explanatory diagram showing a procedure of a method called a shake hand or a challenge response used by a server when confirming the authority of a user at a client side.

FIG. 13 is an explanatory diagram showing an example of a team hierarchy according to the second embodiment of the present invention.

FIG. 14 is an explanatory diagram showing an example of a team hierarchy according to the third embodiment of the present invention.

FIG. 15 is a block diagram showing the configuration of a conventional system for sharing information using an access control list.

[Explanation of symbols]

Reference Signs List 30: Team data list management device, 31: Team data list storage device, 32: Storage device, 33: Authority data, 34: Authority list, 35: Authority confirmation function, 36: List storage function, 37: List validity confirmation function 38, AUD / AUL change function, 39, electronic signature function, 40, public key management function, 41, public key database, CL, client, SV, server

Claims (8)

[Claims] 1. A team data list management device that manages a team data list for hierarchizing teams, requests a predetermined request destination to operate the team data list, and performs an operation in response to the operation request. For each team from the target team to the root team, the authority data including the identifier indicating the parent team of the own team and the electronic signature of the manager of the parent team, and the management authority of the sub team managed by the own team A team data list having an authority list including manager information or an electronic signature of the manager of the parent team or the manager of the parent team, which is the manager of the own team, is obtained from the request destination, and the team obtained using the identifier is obtained. The electronic signature of the team data list is not falsified for each team while tracing to the root team And validity checking means for confirming that the signature is signed by an authorized person using the administrator information, and confirming the user's approval of the team master of the root team. A team data list changing means for making a change in accordance with the operation request to the confirmed team data list, and creating an electronic signature of an instructor who has made the operation request, to the changed team data list. Signature means for attaching the electronic signature and sending the electronic signature to the request destination. 2. The manager information includes one or more sub-authorities designated by the team master from members of the own team and having management authority for the sub-team, and the authority of the sub-authority. 2. The information according to claim 1, wherein the information is related to the team master having management authority for the sub authority.
Listed team data list management device. 3. A registration unit for acquiring and registering identification information for identifying the team master of the root team from a predetermined location, and using the identification information registered in advance to transmit a request from the request destination. 3. The team data list management according to claim 1, further comprising: a team master confirming means for confirming that an electronic signature of the authority data of the root team sent is an electronic signature of the team master. apparatus. 4. A team data list storage device for storing a team data list for hierarchizing teams, wherein the authority includes an identifier indicating a parent team of the own team and an electronic signature of an administrator of the parent team. Authority data storage means for storing data for each team, manager information on the management authority of the sub team under the control of the own team, and electronic signature of the team master who is the manager of the own team or the manager of the parent team Authority list storage means for storing, for each team, an authority list including the authority data, and an instructor of the operation request with respect to an operation request from a predetermined request source for the authority data and the team data list including at least the authority list. Confirms that the user has the required authority using the administrator information, The team data list requested in response to the reference request or the deletion request is returned or deleted to the request source, and in the case of an update request, the electronic signature of the team data list sent from the request source is determined by an authorized person. The authority data storage means and the authority confirmation means for updating the stored contents of the authority list storage means with the sent team data list. A team data list storage device. 5. The manager information includes at least one sub-authority designated by a member of the team by the team master and having authority to manage the sub-team, and an authority of the sub-authority. 5. The information related to the team master having the management authority for the sub authority.
Listed team data list storage device. 6. A team data list management device according to claim 1, which is a request source, and a team data list storage device according to claim 4 or 5, which is a request destination. And team data list processing system. 7. A recording medium on which a team data list management program for managing a team data list for hierarchizing teams is recorded, wherein a process for requesting a predetermined request destination to operate the team data list; In response to an operation request, for each team from the operation target team to the root team, authority data including an identifier representing the parent team of the own team and an electronic signature of the manager of the parent team, and And a team data list having an authority list including an electronic signature of a team master who is an administrator of the own team and an administrator of the parent team, which is an administrator of the own team. Processing, for each team while tracing each team obtained using the identifier to the root team, After confirming that the electronic signature of the team data list has not been tampered with and that it has been signed by an authorized person using the administrator information, the validity of confirming the user's approval of the team master of the root team by the user Confirmation processing; change processing for making a change in accordance with the operation request to the team data list whose validity has been confirmed by the validity confirmation processing; and creating an electronic signature of the instructor who has made the operation request. And a process of attaching the electronic signature to the team data list changed by the change process and sending the electronic signature to the request destination. 8. A recording medium storing a team data list storage program for storing a team data list for hierarchizing teams, comprising: an identifier indicating a parent team of the own team; and an electronic signature of an administrator of the parent team. Is stored in advance for each team, including the authority data containing the authority information of the sub-team under the control of the own team, and the manager information of the team master or the parent team, which is the manager of the own team. A process of storing an authority list including an electronic signature of an administrator in advance for each team; and a case where an operation request is made from a predetermined request source to the authority data and a team data list including at least the authority list. In addition, while using the administrator information to confirm that the instructor of the operation request has request authority, If the operation request is a reference request or a deletion request, the requested team data list is returned or deleted to the request source, and if the operation request is an update request, the team data transmitted from the request source is deleted. After confirming that the electronic signature of the list is a signature by an authorized person by using the manager information, the authority data stored in the transmitted team data list and the stored authority list are read. A recording medium storing a team data list storage program for causing a computer to execute an authority confirmation process to be updated.