Method and apparatus for supporting cooperative activity

Abstract

Provided are a method and apparatus for supporting a cooperative activity in which an activity is performed by cooperation among a plurality of participants, as in a television conference system. When another user attempts to participate in the cooperative activity (session), a guardian is assigned to the session and a guardian is assigned also to the user attempting to participate. Allowance or refusal of participation by the user in the session is decided based upon the access control level of the guardian corresponding to the user, a guardian tree defining the path of the guardian and the mutual relationship between the guardians.

Claims

What is claimed is:

1. A method of supporting a cooperative activity in which an activity is performed by cooperation over a network among a plurality of participants each comprising a terminal connected to the network, said method comprising:

a step of assigning access control information specifying a level of an allowable access operation for a respective one of a plurality of predetermined relationships between a resource and a requesting participant with respect to each of the resources;

a step of entering one of a group of access requests from a requesting participant with a respective access level to one of the resources, the group of access requests including an access request to the shared data, a request for participating in the cooperative activity, or a request for executing a program as an access request for the program; and

a decision step of deciding whether to allow or refuse the request entered in said entering step as the access request for the one resource, wherein said decision step allows the request if the respective access level is not higher than the level specified in the access control information assigned to the relationship between the one resource and the requesting participant.

2. A method of supporting a cooperative activity in which an activity is performed by cooperation among a plurality of participants, said method comprising:

a step of entering an access request with respect to the cooperative activity; and

a decision step of deciding whether to allow or refuse the access request in relation to at least a list of participants in the cooperative activity, shared data, and an executable program,

wherein said decision step includes a step of assigning access control information to each participant in the list of participants in the cooperative activity, each shared data, and each executable program, respectively, and rendering a decision based upon the access control information and the access request, and

wherein the access control information has at least the following three access control levels:

          [Control Level]   :       [Request Allowed]
          _none             :       None
          _readable         :       Reference to object which
                                    receives request
          _updatable        :       Alteration of object which
                                    receives request.

          [Control Level]    :       [Request Allowed]
          _usable            :       Functional utilization of
                                     object which receives
                                     request
          _appendable        :       Alteration by addition to
                                     object which receives
                                     request
          _insertable        :       Alteration by insertion
                                     in object which receives
                                     request
          _deletable         :       Deletion of object which
                                     receives request.

            [Mutual relationship]    :         [Meaning]
            _self                    :         Self
            _ancestor                :         Ancestor
            _progeny                 :         Progeny.

          [Mutual Relationship]  :       [Meaning]
          _sibling               :       Sibling (a node having
                                         the same parent node
          _parent                :       Parent (ancestor in the
                                         first degree)
          _child                 :       Child (progeny in the
                                         first degree)
          _other                 :       No relationship
          _anonymous             :       Relationship not taken
                                         into account.

          [Control Level]   :       [Request Allowed]
          _none             :       None
          _readable         :       Reference to object which
                                    receives request
          _updatable        :       Alteration of object which
                                    receives request.

          [Control Level]    :       [Request Allowed]
          _usable            :       Functional utilization of
                                     object which receives
                                     request
          _appendable        :       Alteration by addition to
                                     object which receives
                                     request
          _insertable        :       Alteration by insertion in
                                     object which receives
                                     request
          _deletable         :       Deletion of object which
                                     receives request.

            [Mutual relationship]    :         [Meaning]
            _self                    :         Self
            _ancestor                :         Ancestor
            _progeny                 :         Progeny.

          [Mutual Relationship]  :       [Meaning]
          _sibling               :       Sibling (a node having
                                         the same parent node
          _parent                :       Parent (ancestor in the
                                         first degree)
          _child                 :       Child (progeny in the
                                         first degree)
          _other                 :       No relationship
          _anonymous             :       Relationship not taken
                                         into account.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to a method and apparatus for supporting a cooperative activity in a system such as a television conference system wherein a plurality of participants cooperate to perform an activity.

2. Description of the Related Art

In a cooperative activity environment such as a conventional television conference system, control for participation in the cooperative activity and for access to shared information used in the activity is not satisfactory. The reason for this is as follows: In a single-function, special-purpose cooperative activity system, whether or not participation in the conference is allowed or denied to a person depends upon whether use of the television conference equipment can be acquired from his terminal, as in the manner of a telephone. In addition, by using a dedicated line for the conference system, leakage of information to a third party is prevented. In a case where someone participates in a certain cooperative activity, therefore, participation is allowed without requiring a special check to determine whether or not the participation should be permitted. Furthermore, when access is made to information shared in the cooperative activity, access to the information is allowed merely by simple access control.

Access control carried out in a conventional television conference system will be described with reference to a specific example. In this example, whether participation of a new participant (namely a new writer or new editor) in a cooperative editing activity in a stand-alone computer is allowed or denied is decided based upon static information using a conventional technique similar to that of access control in a UNIX file system. That is, in the access control described here, whether or not participation is allowed is decided based upon the access attributes of shared data to be edited.

First, in order to simplify the description, a name is given to the object of processing. For example, let the cooperative editing activity be "Cooperative Editing #302" and let a new participant be "Participant #46". Each cooperative editing activity has the attribute of the owner, just as in the case of UNIX file system. Similarly, the activity possesses access control attributes classified into three relationships, namely (1) user, (2) group and (3) other, and each has data representing (a) executable, (b) writable and (c) readable or data which is a combination of these data.

Under these settings, processing executed when "Participant #46" requests participation in "Cooperative Editing #302" is as follows:

First, the owner attributes of "Participant #46" and of "Cooperative Editing #302" are compared and it is determined whether the relationship is (1), (2) or (3) above. Next, the access control attribute relevant to this relationship is extracted and whether or not the participation request is allowed is decided based upon this attribute. For example, if "(a) executable" has been designated for the extracted control attribute, then participation becomes possible. In case of other attributes, however, it is decided that participation is not allowed. This is capable of being decided statically irrespective of the status of execution. Such access control processing is executed as part of system call processing of a UNIX operating system in a case where a UNIX file system is accessed, by way of example. In case of the cooperative editing activity described here, the access control processing is incorporated in cooperative activity software for the purpose of carrying out the cooperative editing activity, or an independent dedicated access control unit is prepared and processing is executed. Further, in case of UNIX or the like, access control for accessing a file in a file system and control of participation in a session such as log-in is managed based upon different frameworks. More specifically, with regard to accessing of a file, a decision is made upon referring to access permission set file by file. With regard to log-in, the decision is rendered upon referring to the content of a file "/etc/password".

Moreover, these decisions are rendered statically based upon file access permission or file content and status at the time of execution is not taken into consideration.

The recent popularization of high-performance computers connected by a high-speed network and the development of distributed computing software have made it possible to use a plurality of computers to perform a cooperative activity by a group comprising a plurality of individuals. Under these conditions, control for allowing or denying participation of each participant in a cooperative activity and for accessing information used therein is an important requirement in terms of carrying out the cooperative activity. In other words, in the prior art, access control is performed with regard to static information. However, in a case where a plurality of participants take part in a cooperative activity, it is necessary to carry out control for access to dynamic information for executing a program in the cooperative activity or participating therein. If the foregoing cannot be controlled properly and put to use in the cooperative activity, the progress of the cooperative activity will be impeded. The actual problems that arise when access control in a cooperative activity is not performed correctly are as follows:

(1) a decline in service caused by acceptance of more participants than the capacity for the processing;

(2) leakage of confidential information; and

(3) failure of the cooperative activity because of improper quantities of information.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a method and apparatus for supporting a cooperative activity in which it is possible to perform flexible control for accessing data used in a cooperative activity.

Another object of the present invention is to provide a method and apparatus for supporting a cooperative activity-in which access control information in a cooperative activity is given in a hierarchical structure and assigned to data used in a cooperative activity so that whether processing is allowed or not can be decided in individual cooperative activities.

A further object of the present invention is to provide a method and apparatus for supporting a cooperative activity in which data in cooperative activity can be accessed dynamically in conformity with the status of execution of the cooperative activity.

Other features and advantages of the present invention will be apparent from the following description taken in conjunction with the accompanying drawings, in which like reference characters designate the same or similar parts throughout the figures thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the invention and, together with the description, serve to explain the principle of the invention.

FIG. 1 is a diagram showing the configuration of a cooperative activity system according to an embodiment of the present invention;

FIG. 2 is a flowchart showing an overview of processing according to a set-up program of a first embodiment of the present invention;

FIG. 3 is a diagram for describing the relationship between shared resources and guardians in the first embodiment;

FIG. 4 is a flowchart showing an overview of processing according to a participation decision program of the first embodiment of the present invention;

FIG. 5 is a diagram for described shared resources in the first embodiment;

FIG. 6 is a diagram for describing a guardian tree (FIG. 6A) and a guardian path (FIG. 6B) according to the first embodiment;

FIG. 7 is a flowchart showing an overview of processing according to an inclusion program according to the first embodiment;

FIG. 8 is a flowchart showing an overview of processing according to an assignment program according to the first embodiment;

FIG. 9,is a flowchart showing an overview of processing according to an evaluation program according to the first embodiment;

FIG. 10 is a flowchart showing an overview of processing according to a refusal program according to the first embodiment;

FIG. 11 is a flowchart showing an overview of processing according to an extended evaluation program according to a second embodiment;

FIG. 12 is a flowchart showing an overview of processing according to a master-tool processing program according to the second embodiment;

FIG. 13 is a flowchart showing an overview of processing according to a decision program of the second embodiment;

FIG. 14 is a diagram for describing the relationship between shared resources and guardians in the second embodiment; and

FIG. 15 is a diagram for describing the constitution of software of a process level according to the first embodiment of the invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. Before the embodiments are described, however, the factors that characterize the embodiments will be set forth.

(1) Access control information referred to as a "guardian" (described later) is assigned to each resource used in a cooperative activity. As a result, whether start-up of applications for accessing shared data, for participation/withdrawal regarding a cooperative activity and for performing a cooperative activity should be allowed or not can be handled collectively by the framework of access control.

(2) In order to implement the above-described function, use is made of an inclusion program, an assignment program and an evaluation program, which will be described later.

(3) A mutual relationship based upon a hierarchical structure is defined between two guardians and access control is performed in accordance with an access control level set for each mutual relationship.

(4) The mutual relationship between guardians is divided into eight relationships, namely six categories based upon a relationship within the hierarchical structure and two categories provided with special meaning. Among these, the three relationships "_self", "_ancestors" and "_progeny" are essential. Some or all of the other relationships may be dispensable.

(5) Access control levels utilized by guardians are divided into seven levels. Among these, three levels "_none", "_readable" and "_updatable" are essential. Some or all of the other relationships may be dispensable.

(6) Positioning within the hierarchical structure of a guardian is maintained as a path to each guardian.

In this embodiment, access control (control for allowing or refusing participation) in a case where a participant is newly added to a cooperative activity in which a plurality of individuals take part will be described. In particular, an example of processing according to a participation decision program (FIG. 4) will be described in which information for access control is provided for each object that participates in a cooperative activity and allowance or refusal of participation is decided using the provided information.

This embodiment is characterized in that a mutual relationship is defined among the items of information provided for the objects and access control is carried out based upon the mutual relationship.

Assume that the processing of an evaluation program (FIG. 9) referred to at step S11 of the participation decision program (FIG. 4) of this embodiment is executed by an access control program (access control program 141) sharing data space with a cooperative editing program (FIG. 1) for performing a cooperative editing activity.

The construction of a terminal device of a cooperative activity system for explaining this embodiment will be described, followed by a description of the operation thereof.

FIG. 1 is a system block diagram for describing an embodiment of the invention.

In FIG. 1, a plurality of terminals 100, 200, 300 are connected to a network 5000. Since the terminals are identically constructed, only the construction of terminal device 100 will be described. The terminal device 100 has an input unit 101 that allows the user of the terminal to enter commands and data. The input unit 101 includes a keyboard and a pointing device such as a mouse pad, and a microphone for entering audio. A CPU 102, which controls the entirety of the terminal device 100 of this embodiment, executes software (stored in a memory 104) for a cooperative editing activity, access control, etc. Though one CPU is used in the arrangement of FIG. 1, the hardware configuration may be such that independent CPUs are utilized. An output unit 103 is constituted by a display such as a CRT or; a projector, or a printer. The output unit 103 allows the user to display and output the content of the cooperative editing activity system as well as the results of processing (allowance or refusal of participation) of the participation decision program. In order to simplify the description, display of a plurality of cooperative editing activities is performed by a single output unit. However, independent display devices or printers may be provided for respective ones of the activities.

A memory 104 has program areas 140, 141 for storing programs which implement functions of the cooperative editing activity and participation decision program described in this embodiment, and a data area 142 for storing data utilized by these programs. A plurality of the memories 104 may be provided, a memory that differs for each item of data to be stored may be provided, or the memory may be one of hierarchical form including a secondary storage device such as a hard disk.

The processing functions (programs) saved as programs in the memory 104 are, specifically, a set-up program, a participation decision program, an inclusion program, an assignment program, an evaluation program, a refusal program, an extended evaluation program, a master-tool processing program and a decision program, etc. In FIG. 1, these programs are indicated by the cooperative editing program 140 and an access control program 141. Further, the memory 104 may be divided into a main storage section for storing data used temporarily and a secondary storage section in which a large amount of data is stored permanently. Further, the memory 104 may include a ROM or the like for storing permanent data regardless of the status of the apparatus.

A communication unit 105 such as an FDDI controller is connected to the network 5000. The elements 101.about.105 mentioned above are joined by a computer bus 106. As mentioned above, the terminals 200, 300 are identical to the terminal device 100 in terms of construction and are for a cooperative editing activity. The terminal devices 100, 200 and 300 allow respective participants to make inputs and outputs and execute processing for cooperative activities. Though a case is described in which the three terminals are connected to a network 5000, there is no limitation upon the number of terminals connected to the network.

The network 5000, which is for implementing a cooperative editing activity, described in this embodiment, by a plurality of computers, includes an Ethernet, FDDI, etc. This embodiment is described with regard to a mode of implementation utilizing general-purpose computers. Consequently, a computer network is used for the purpose of communication. The network may be a wide-area line such as an ISDN.

The constitution of the software executed by the terminal 100 (200, 300) of this embodiment will be described next.

First, the constitution of the software will be described broadly in terms solely of program execution units, e.g., the processes in a UNIX program. When the embodiment is viewed from this standpoint, the cooperative editing program 140 is executed by each of the terminals 100, 200, 300, as shown for example in FIG. 15, and the participants in the cooperative editing activity are placed at respective ones of the separate terminals. Further, in the case of FIG. 15, for example, the access control program 141 of the terminals (e.g., terminal 100) is executed to carry out access control (FIG. 15), described later.

Further, in order to simplify the description, the cooperative editing program 140 and access control program 141 of each terminal share data space, and the data to be processed placed in this shared data space can be referred to or manipulated from any of these terminals in the same manner. In order to realize this, an object-oriented database system or distributed shared-memory technology can be used.

Next, the data used in each of these programs is named.

FIG. 5 is a diagram showing the object of processing (hereinafter referred to as the "object") utilized in the description of this embodiment.

In this embodiment, the object of a cooperative activity such as a cooperative editing operation is referred to as a "session" 500, as depicted in FIG. 5. An application object such as drawing software or an editor utilized in the session is referred to as a "tool" 501. An object which is a participant in such a cooperative activity is referred to as a "user" 502. FIG. 5 represents the following state: "Another user `user #14` is attempting to participate in a `session` of cooperative activity #205, in which `users` indicated by user #12 and user #03 are utilizing "tools" referred to as tool #108 and tool #115". The processing of this embodiment becomes necessary under such conditions.

Further, in the description of this embodiment, the object of the side which receives a request for participation and which performs the relevant control is referred to a "control object", as in the manner of the session of a cooperative editing activity. On the other hand, the object of the side which issues the participation request such as the "user #14" 502 is referred to as a "requesting object". This distinction is for the sake of simplicity in a case where attention is focused upon the participation request; no distinction is made between the information represented and the type thereof. For example, a tool which provides a service can be the "control object" or the "requesting object", depending upon the type of operation. An object assigned for each resource and retaining access control information shall be referred to as a "guardian".

The operation of a set-up program, indicated by the flowchart of FIG. 2, necessary for access control is described in line with the situation illustrated in FIG. 3. The set-up program performs the three preparatory operations described below with regard to the data of the shared data space of the cooperative editing operation and the processing of the program for the cooperative editing activity. It is required that these preparations be performed prior to the start of processing of the participation decision program (FIG. 4), described later. Further, the preparations (1).about.(3) described below need not be carried out in the order of the flowchart shown in FIG. 2.

1. Preparatory operation (1)

At step S2, it is determined whether an operation requiring access control exists. If the answer is "YES", the program proceeds to step S3. Here processing for inquiring of a guardian is included, by the inclusion program of FIG. 7, in the operation requiring access control from the operation of the control object, such as session information. This can be implemented using a technique for functional extension similar to that of a hook function in an Emacs editor, by way of example. In this embodiment, the step S3 corresponds to the inclusion of a participation decision program (FIG. 4) in an operation for adding a new participant (user #14) in the session cooperative activity #205 of FIGS. 3 and 5.

2. Preparatory operation (2)

Next, when processing for generating a control object is detected at step S4, the program proceeds to step S5, at which a guardian capable of being specified from the control object is assigned by an assignment program (FIG. 8). This may be a newly created guardian or an existing guardian.

In the case of this embodiment, a guardian (guardian #01) is assigned to a session (cooperative activity #205), as shown in FIG. 3.

3. Preparatory operation (3)

When processing for generating a requesting object is detected at step S6, the program proceeds to step S7, at which a guardian capable of being specified from the requesting object is assigned by the assignment program (FIG. 8). Here also the guardian may be one created anew or one already existing.

In the case of this embodiment, a guardian (guardian #24) is assigned to a participant (user #14), as shown in FIG. 3. Furthermore, in this embodiment, it has been described that the same assignment program (FIG. 8) is utilized at steps S5 and S7 in FIG. 2. However, this does not impose a limitation upon the invention and it is permissible to utilize other assignment programs having different assignment policies.

[Overview of operating procedure]

The general features of the operating procedure of processing in this embodiment will now be described. This will then be followed by a description of the details of operation.

FIG. 4 is a flowchart showing a processing operation according to a participation decision program in a cooperative editing operation performed in the system of this embodiment. When the cooperative editing program executed by each of the terminals 100, 200, 300 attempts to perform an operation requiring access control at execution of the cooperative editing operation, the operation is executed by sending the access control program 141 an evaluation request for the purpose of access control. More specifically, when the participant "user #14" attempts to participate in session cooperative activity #205, the above is executed by start-up of the participation decision program incorporated by the preparatory operation (1). Further, the evaluation request sent to the access control program 141 can be implemented by an RPC (Remote Procedure Call), by way of example.

First, at step S11, whether a participation request is allowed or not is decided by the evaluation program (FIG. 9) of the access control program 141 based upon the relationship between the guardian (guardian #01) assigned to the session information and the guardian (guardian #24) assigned to the participating user (user #14) information. If participation is allowed at step S12, the program proceeds to step S13, at which operation for adding on a participant is continued.

If participation is not allowed, the program proceeds to step S14, at which a refusal program (FIG. 10) is executed to suspend the operation which adds on the participant. Though access control relating to participation in a session has been described, an operation such as tool execution and group generation or access to information within a session can also be performed by a similar access control program 141.

After the general features of a guardian are described, the details of the operation of each program referred to in the foregoing operation procedure will be described in regular order while referring to the flowchart as necessary.

(a) Guardian access control level

A guardian decides whether or not to allow a request using access control levels set forth below. The correspondence between access control levels and requests allowed by these access control levels are indicated below. The access control levels are listed in order of decreasing restrictions. In other words, the higher the obtained access control level is in the list, the more restrictive the level of access.

          [Control Level]            [Request Allowed]
          _none              :       None (all requests are
                                     refused)
          _readable          :       Reference to control
                                     object
          _usable            :       Functional utilization of
                                     control object
          _appendable        :       Alteration by addition to
                                     control object
          _insertable        :       Alteration by insertion
                                     in control object
          _updatable         :       Alteration of control
                                     object
          _deletable         :       Deletion of control
                                     object

          [Mutual Relationship]  :       [Meaning]
          _self                  :       One`s own self
          _sibling               :       Sibling (a guardian
                                         having the same parent
                                         guardian)
          _ancestor              :       Ancestor
          _progeny               :       Progeny
          _parent                :       Parent (ancestor in the
                                         first degree)
          _child                 :       Child (progeny in the
                                         first degree)
          _other                 :       No relationship
          _anonymous             :       Relationship not taken
                                         into account

          [Control Level]           [Request Allowed]
          _none             :       None *(all requests are
                                    refused)
          _readable                 Reference to control
                                    object
          _usable           :       Functional utilization of
                                    control object
          _appendable       :       Alteration by addition to
                                    control object.
          _insertable       :       Alteration by insertion
                                    in control object
          _updatable        :       Alteration of control
                                    object
          _deletable        :       Deletion of control
                                    object
          _consult          :       Decision based upon
                                    result of inquiry to
                                    master tool

• Inventors
  Kurosawa, Takahiro;
• Assignee
  Canon Kabushiki Kaisha (Tokyo, JP)
• Published
  Oct-2-2001
• Current US Classes:
  707/9
  709/223
  711/100
• Application #
  564634
• International Classes
  G06F 017/30
• Field of Search
  395/684 395/677 395/670 395/614 395/187.01 395/674 707/2 707/8 707/9 707/10 707/103 707/11 380/25 711/163 711/100 709/223 709/300 709/104
• Examiner
  Black; Thomas G.
• Agent
  Fitzpatrick, Cella, Harper, & Scinto
• US Patent References:
  4104718
  5113442
  5136712
  5173939
  5315657
  5481715
  5504895
  5627987
  5630125
  5675782
  5701458
  5708812
  5768516
  5794006
  5890189
  5894573
  6038543
  6047288