Abstract:
In a work environment composed of plural computers, there are provided a method and an apparatus for realizing the coordinative work environment adaptable to various forms of the coordinative work. For this purpose there is disclosed a mechanism for realizing the coordinative work environment for supporting the coordinative work composed of plural computers, the mechanism comprising description means for the coordinative work form and means for effecting the coordinative work management process adapted to arbitrary coordinative work form, based on the description of the coordinative work form described by the description means.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    1. Field of the Invention  
           [0002]    The present invention relates to a system for realizing a coordinative environment enabling plural users to effect a coordinative work, particularly a coordinative work suitable for video conference, through plural computers, and a method and a medium suitable for such system.  
           [0003]    In particular it relates to a coordinative work environment realizing system, capable of providing various coordinative work environments matching various forms of the coordinative work.  
           [0004]    2. Related Background Art  
           [0005]    There are being recently proposed and utilized groupware systems for supporting a coordinative work by plural users, by combining plural personal computers or work stations, thereby enabling data exchange or common utilization of data therebetween.  
           [0006]    In such groupware system, for enabling the computers to execute the coordinative work such as a conference, a presentation or a lecture meeting, that has been executed without relying on the computers, there can be conceived two different approaches, which are:  
           [0007]    1. positively supporting specified coordinative works, such as a conference or a lecture meeting; and  
           [0008]    2. not supporting any specified form the coordinative work but managing only the field of the coordinative work, for example a meeting room.  
           [0009]    The approach 1 is adopted in many commercial television conference systems, while the approach 2 is adopted in many general-purpose coordinative work systems on the computers, such as ShowMe (trade mark) or Communique ! (trade name).  
           [0010]    Thus the systems of the approach 1 are capable of services specified to the particular coordinative works, while those of the approach 2 do not support the specified coordinative works but provide service only to the common portion (namely the management of the information of the attendees and of the application program used), and can therefore be utilized for various purposes by the users.  
           [0011]    Such groupware systems have been discussed, for example, by Earl Craighill et al., “SCOOT: An Object-Oriented Toolkit for Multimedia Collaboration”, Proc. ACM Multimedia 94, pp.41-49(1994), Pavel Curtis et al., “The Jupiter Audio/Video Architecture: Secure Multimedia in Network Places”, Proc. ACM Multimedia 95, pp.79-90(1995), Ralph D. Hill et al., “The Rendezvous Architecture and Language for Constructing Multiuser Applications”, ACM trans. CHI, vol.1, No.2, pp.81-125(1994), and Mark Roseman et al., “Groupkit: A groupware toolkit for building realtime conferencing applications”, Proc. ACM CSCW 92, pp.43-50(1992).  
           [0012]    However the conventional groupware systems have been associated approach 1 or 2.  
           [0013]    The approach 1, being specified to the coordinative word of a certain form, such as a conference, lacks flexibility to wider applications. Also it is deficient in developability of the system, since the expansion of the system, such as addition of new functions, cannot deviate largely from the basic model of the coordinative work. Also certain system in the commercial level cannot be considered to sufficiently realize the coordinative work form such as conference on the computers.  
           [0014]    On the other hand, in the approach 2, sunce the system provides the minimum support only, the means for supporting the actual coordinative work has to be provided by the application program functioning on the system. This fact increases the burden of the application developer and renderes the development of application difficult. Also the simultaneous use of plural applications may cause confusion to the user or trouble in the cooperation between the applications unless such applications assume a unified coordinative work model.  
         SUMMARY OF THE INVENTION  
         [0015]    As object of the present invention is resolve the aforementioned drawbacks individually or entirely.  
           [0016]    Another object of the present invention is to enable a coordinative work operation flexible in application.  
           [0017]    Still another object of the present invention is to enable a coordinative work among plural application softwares which are mutually different in functions.  
           [0018]    The above-mentioned objects can be attained, according to a preferred embodiment of the present invention, by a system for realizing a coordinative work environment supporting a coordinative work, the system comprising:  
           [0019]    description means for describing the form of the coordinative work; and  
           [0020]    realization means for realizing a coordinative work environment capable of adapting to the coordinative works of various forms and an application functioning thereon, by providing means for effecting a coordinative work managing process matching the form of an arbitrary coordinative work based on the form of the coordinative work described by the description means.  
           [0021]    Still another object of the present invention is to provide a system and a software adapted for use in a remote conference system and a medium storing such software.  
           [0022]    Still another object of the present invention is to provide a system and a software adapted for use in a remote monitoring system and a medium storing such software.  
           [0023]    Still other objects of the present invention, and the features thereof, will become fully apparent from the following description of the embodiments, to be taken in conjunction with the attached drawings. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0024]    [0024]FIG. 1 is a view showing the configuration of a conference system constituting a first embodiment of the present invention;  
         [0025]    [0025]FIG. 2 is a view for outlining the system of the first embodiment;  
         [0026]    [0026]FIG. 3 is a view showing CollabField in a C/A object model;  
         [0027]    [0027]FIG. 4 is a view showing Activity in the C/A object model;  
         [0028]    [0028]FIG. 5 is a view showing an example of the C/A object formed by the conference system;  
         [0029]    [0029]FIG. 6 is a view showing the process flow in the foregoing system;  
         [0030]    [0030]FIGS. 7A, 7B and  7 C are flow charts showing the process flow in FIG. 6;  
         [0031]    [0031]FIG. 8 is a view showing the configuration of a remote awareness system constituting a second embodiment of the present invention;  
         [0032]    [0032]FIG. 9 is a view for outlining the system of the second embodiment;  
         [0033]    [0033]FIG. 10 is a view showing an example of the C/A object formed by the awareness system;  
         [0034]    [0034]FIG. 11 is a view showing the process flow in the foregoing system;  
         [0035]    [0035]FIG. 12 is a flow chart showing the process flow in FIG. 11;  
         [0036]    [0036]FIG. 13 is a view showing shift from an awareness application 2000 to a video conference application 3000 in another embodiment of the present invention;  
         [0037]    [0037]FIG. 14 is a view showing coordination of CSCW applications in another embodiment;  
         [0038]    [0038]FIG. 15 is a view showing the configuration of CCF Core in another embodiment;  
         [0039]    [0039]FIG. 16 is a view showing coordination among coordinative process groups in another embodiment;  
         [0040]    [0040]FIG. 17 is a view showing process shift among coordinative process groups in another embodiment;  
         [0041]    [0041]FIG. 18 is a view showing generation/erasure of a communication path in another embodiment; and  
         [0042]    [0042]FIG. 19 is a view showing coordinative support for Work Env layer 3600 shown in FIG. 15. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0043]    Now there will be explained a first embodiment of the present invention, with reference to the attached drawings.  
         [0044]    [0044]FIG. 1 is a view showing the configuration of a conference system constituting the present embodiment. In FIG. 1, a work station  101  is composed of a CPU  102  for process execution in the present embodiment, and a main storage  103  storing a session manager  110 , which is the basic software of the present conference management system, through a computer bus  105 .  
         [0045]    A hard disk  106  for storing permanent data required for the process of the present embodiment, a terminal  104  providing a user interface enabling the user to operate the system, a camera  13  for taking the image of the user, and a microphone  114  for voice input are connected to the work station  101 .  
         [0046]    The hard disk  106  stores two groups of data, namely a C/A object  107  and a coordinative work model description object  108 . These data are managed by a server program called watcher server or watcher  109 . In FIG. 1, the hard disk  106  and the watcher  109  constitute a part of the work station  101 , but they are ordinarily combined with another work station capable of communication through the computer network and are rarely used on the same machine as that of the session manager  110 .  
         [0047]    The C/A object  107  and the coordinative work model description object  108  will be explained later in more details, but are considered as objects described by the C ++  program language. The session manager  110  has copies  111 ,  112  of these data. In handling these data, the session manager  110  does not refer to the hard disk  106  but to the copies  111 ,  112  present in the address space of the session manager.  
         [0048]    Matching of the data  107 ,  111  and  108 ,  112  is assured by the watcher  109 . This is achieved, in case of a change in the values of the data  111 ,  112 , by informing the watcher  109  of the content of such change. According to the notice for a change, the watcher  109  varies the data  107 ,  108  and also informs other session managers, functioning on different work stations of the content of such change.  
         [0049]    The session manager  110  realizes a conference among remote locations by transmitting a moving image and voice, fetched from the camera  113  and the microphone  114 , to other session managers, and displaying, on a display  104 , the moving image and reproducing the voice received from other session managers.  
         [0050]    [0050]FIG. 2 is a view outlining the present embodiment, seen from a user. In FIG. 2, plural users  201 ,  202 ,  203 ,  204  are executing a work on the work stations combined by a computer network  205 . Each of the user displays  206 ,  207 ,  208 ,  209  displays windows such as  210 ,  211 , and the window  210  displays icons  212 ,  213 ,  214 ,  215  representing the attendees of the coordinative work.  
         [0051]    The present embodiment is assumed to support, as the coordinative work, a general “conference”, which may also be called session in the present embodiment.  
         [0052]    A role called “chairman” may be assigned to one of the attendees of the session. The icon  212  in emphasized display indicates that the represented use is the “chairman”. An attendee inviting the session becomes the chairman, so that only one chairman exists in a session. The role of the chairman is to designate the speaker.  
         [0053]    The window  211  displays the moving image and the voice of the current speaker. These data of the speaker are similarly displayed on the displays of all attendees, as on the display  206 . The speaker alone can provide all the attendees of the session with the information of moving image and voice. For the purpose of simplicity, the present embodiment assumes only one speaker at a time. Until the “chairman” males designation, the “chairman” functions also as the speaker. Like the “chairman”, the speaker can also be regarded as a user to whom the role of “speaker” is assigned.  
         [0054]    The present embodiment is at first featured by providing means for defining and describing the properties of the above-mentioned form of the coordinative work.  
         [0055]    The present embodiment provides, as the description means, a C ++  class group, called C/A object model and described by the C ++  program language (This class group is called C/A class, and the instance of the C/A class is called C/A object).  
         [0056]    The present embodiment employs the C/A class and the C/A object by the C ++  program language as the description means of the coordinative work model, but, as the present invention is not limited to the functions provided by the C ++  program language, similar description is also possible by various program languages such as Objective-C, C, CLOS or Lisp.  
         [0057]    Utilizing such C/A object, the programmer of system or application describes the coordinative work form to be processed.  
         [0058]    Followings are defined as the C/A classes:  
         [0059]    Attendee; Cpath; CollabField; and Activity.  
         [0060]    The methods of these classes correspond to the operation primitive of the entity constituting the models of the classes.  
         [0061]    Attendee  
         [0062]    This is a class modeling the attendees of the coordinative work.  
         [0063]    Cpath  
         [0064]    This is a class representing the transmission path of the information, formed from an attendee to another (Cpath being abbreviation of Communication Path). On the C/A object, it represents the transmission path between the attendees. The attendee at the information sending side is called “sender”, and that at the information receiving side is called “receiver”.  
         [0065]    CollabField  
         [0066]    It represents a field or an environment of the coordinative work, formed by the attendees and the Cpath, as shown in FIG. 3 (CollabField being abbreviation of collaboration field). In FIG. 3, 301 to  303  indicate Attendees, which can be considered to correspond to the attendees of the coordinative work.  304  to  308  are Cpaths representing the information transmission paths among the Attendees. These components constitute the CollabField  309 .  
         [0067]    As will be apparent from FIG. 3, the Cpath is a one-directional transmission path from an Attendee to another, but all the Attendees do not necessarily form the Cpaths equally. For example, in FIG. 3, only one Cpath  305  exists between the Attendees  302  and  303 . This indicates that the transmission of information is not possible from the Attendee  303  to  302 . Also any number of Cpaths of a same direction may be formed between given Attendees. In FIG. 3, two Cpaths  304 ,  308  of a same direction are formed, corresponding to a fact that plural transmission means such as image, voice and text are available for the transmission of information between the attendees. However there is no restriction that a Cpath has to correspond to a transmission means, and a Cpath may correspond to plural transmission means.  
         [0068]    Activity  
         [0069]    Even when the CollabField is formed and the Cpaths are formed among the Attendees, the transmission of information is not necessarily conducted thereon. For this reason, it is necessary to distinguish the Cpath actually used for the transmission of information and that not used therefor. The former is called an active Cpath while the latter is called an inactive Cpath, and a group solely consisting of the active Cpaths on the CallabField is called Activity. The CollabField represents the field of coordinative work, while the Activity represents the mode of coordinative work. FIG. 4 shows the Activity  409 , superposed on the CollabField shown in FIG. 3. In FIG. 4, the components  401  to  409  correspond respectively to those  301  to  309  in FIG. 3, but the active Cpaths  406 ,  407  are represented by solid lines while other inactive Cpaths are represented by broken lines. As the Activity  410  in FIG. 4 only contains Cpaths  406 ,  407 , it will be understood that the current coordinative work is executed only between the attendees  401  and  403 .  
         [0070]    The coordinative work form such as the above-mentioned “Conference” can be described by a combination of the C/A objects. Such description may be particularly called “coordinative work model description”, which consists of the following parts:  
         [0071]    correlation between the constituent component of the described coordinative work and the C/A object;  
         [0072]    declaration of the operation executable by the attendee, relative to the described coordinative work; and  
         [0073]    description of the process, corresponding to the above-mentioned operation, by the operation of the C/A object.  
         [0074]    In the present embodiment, the coordinative work model description of the session (“conference”) is executed in the following manner. The constituent components of the session include: Session, User, Chairman, Participant and Speaker. Session is a component corresponding to the session and represents a “conference”. User means the attendee of the session. Chairman, Speaker and Participant are roles respectively corresponding to the “chairman”, the “speaker” and the “other attendee”. Because of the nature of the session, the Session has always to contain an Attendee having the role of the Chairman.  
         [0075]    Thus, following correlations stand between the above-mentioned components and the C/A objects:  
         [0076]    Session←→CollabField  
         [0077]    User←→Attendee  
         [0078]    Chairman, Speaker, Participant←→Partial group of activity having a specified Attendee as sender or receiver.  
         [0079]    These correlations indicate that the behavior of the above-mentioned components can be dealt with as the behavior of the corresponding C/A objects.  
         [0080]    Then there are defined operations executable by the user to the “conference”.  
                                                                       Operation   Meaning                           BeginSession   start of session           TerminateSession   end of session           AddUserToSession   add user to session           RemoveUserFromSession   remove user from session            Following operation can only be executed by the       current “chairman”:                BeSpeaker   designate “speaker”                      
 
         [0081]    Each of the above-mentioned operations can be given the description of an argument and a process as will be explained in the following. (The description is made with the C ++  language, but, for the purpose of clarity, the following explanation is by the ordinary language.)  
         [0082]    BeginSession  
         [0083]    Argument: User list:  
         [0084]    1. Prepare a list of Attendees corresponding to the given list of Users;  
         [0085]    2. Generate two CollabFields, one being for the conference management around the “chairman”, the other being for the information transmission in the conference around the “speaker”. For the purpose of simplicity, the former is called ChairmanField while the latter is called SpeakerField;  
         [0086]    3. Execute BeChairman in order to appoint the user, requesting this process, as the “chairman”;  
         [0087]    4. Execute BeSpeaker in order to appoint the user, requesting this process, as the “speaker”;  
         [0088]    5. Generate Session corresponding to the CollabField and Activity generated in 2 and 3 (These CollabField and Activity are managed in the generated Session.  
         [0089]    In the designing of a coordinative work model, it is also possible not to conceal these CollabFields in the Session but to assign the corresponding components to these CollabFields. In the present embodiment, however, only the Session is defined on a standpoint that the distinction of these two CollabFields is not obvious to the user. It is also possible to model the session by a single CollabField instead of dividing it into the ChairmanField and the SpeakerField, but the operations of the CollabField become more complex.  
         [0090]    [0090]FIG. 5 shows the CollabField and the Activity generated by the BeginSession. In FIG. 5, there exist two CollabFields, namely the SpeakerField  501  and the ChairmanField  502 . In the SpeakerField  501 , there are three Attendees  503 ,  504 ,  505  which respectively correspond to the attendees of the session. Among all the Attendees  503 ,  504 ,  505  of the SpeakerField  501 , there are formed Cpaths  505  to  511  bidirectionally.  
         [0091]    If the Attendee  503  in emphasized display has the role of “speaker”, only the Cpaths  507 ,  510  having the Attendee  503  as the sender and the other attendees  504 ,  505  as the receivers belong to the Activity  512 . Most of the Cpaths remain inactive, but they can also become active when other Attendees assume the role of the “speaker”.  
         [0092]    The ChairmanField  502  contains the same Attendees  503 ,  504 ,  505  as in the SpeakerField  501 , but there are only formed Cpaths  513 ,  514  having the Attendee  504  in the role of the “chairman” as the sender and the other Attendees  503 ,  505  as the receivers and they belong to the Activity  515 . In the present system, since the “chairman” is not transferred to any other Attendee (withdrawal of the chairman being regarded as the end of the conference), it is not necessary to inactive Cpaths as in the SpeakerField.  
         [0093]    In the present embodiment, the Cpath can be unconditionally rendered active or inactive, but a finer control of the data flow is also possible by adding appropriate conditions to the Cpath.  
         [0094]    TerminateSession  
         [0095]    Argument: none  
         [0096]    1. Demolish CollabField and Activity managed in the Session, and erase all the existing Cpaths.  
         [0097]    +AddUserToSession  
         [0098]    Argument: User to be added  
         [0099]    1. Generate Attendee corresponding to the added User;  
         [0100]    2. Add the generated Attendee to the two CollabFields in the Session;  
         [0101]    3. Add Cpaths connecting the added Attendee with other Attendees, to the two CollabFields. In the SpeakerField, bidirectional Cpaths are added in order to enable bidirectional information transmission.  
         [0102]    In the ChairmanField, only one Cpath is added from the Attendee in the role of the “chairman” to the added Attendee;  
         [0103]    4. Render the Cpath added the ChairmanField active and add it to the ChairmanField;  
         [0104]    5. Among the Cpaths added to the SpeakerField, render the Cpath from the Attendee in the role of the “speaker” to the added Attendee active, and add such Cpath to the SpeakerField.  
         [0105]    RemoveUserFromSession  
         [0106]    Argument: User to be removed  
         [0107]    1. Extract Attendee corresponding to the removed User (Correlation between the user and the Attendee is managed in a form that the Attendee is embedded in the data structure of the User);  
         [0108]    2. Delete, in the two CollabFields, all the Cpaths connecting the removed Attendee with other Attendees;  
         [0109]    3. Delete the Attendee from the two CollabFields in the Session.  
         [0110]    BeSpeaker  
         [0111]    Argument: User becoming Speaker  
         [0112]    1. Extract Attendee from the designated User, and render all the Cpaths, having such Attendee as the sender in the SpeakerField, active.  
         [0113]    The components and the operations of the coordinative work form described as explained in the foregoing are realized as the class of C ++  and incorporated in the session manager. More specifically, the components are realized as a C ++  class, and the operations are incorporated as the methods of the C ++  class. In the “conference” of the present embodiment, since all the operations relate to the Session only, the above-mentioned descriptions of operations become the method of the C ++  class corresponding to the Session. The instances of such class are the coordinative work description objects.  
         [0114]    Now reference is made to FIG. 6 for explaining the process flow for controlling the behavior of the system by the incorporated coordinative work model description. FIGS. 7A, 7B and  7 C are flow charts of such process, consisting of three short flow charts  7   a ,  7   b ,  7   c , wherein  7   a  indicates the behavior of the Session manager  605  in FIG. 6, while  7   b  and  7   c  indicate the behaviors respectively of the watcher  612  and the Session manager  606 .  
         [0115]    In FIG. 6, it is assumed that three users  608 ,  609 ,  610  are conducting a conference by the present system, utilizing work stations  601 ,  602 ,  603 ,  604  connected by a network  613 . In the work stations  602 ,  603 ,  604  used by the users there are activated the Session managers  605 ,  606 ,  607 , and, in the work station  601 , there functions the watcher  612  managing the hard disk  611 , which manages therein the C/A object  614  and the coordinative work model description object  615 . Also in the Session manager  605 , there are managed the copy  616  of the C/A object group  614  and the copy  617  of the coordinative work model description object  615 .  
         [0116]    Now, referring to FIG. 6, there is assumed the execution by the user  608  of an operation, such as the start of the session, utilizing the user interface provided by the Session manager  605 .  
         [0117]    Upon detecting the operation of the user  608  (S 7   a   01 ), the Session manager  605  calls the method of the coordinative work system description object  617  and executes the operation of the user on the C/A object  616  (S 7   a   02 ). In the “conference” of the present embodiment, there is executed the method corresponding to the user operation of the C ++  class which corresponds to the Session.  
         [0118]    The operation on the C/A object is monitored by the watcher  612  (In the present embodiment, for the purpose of such monitoring, any operation on the C/A object always contains a final process of informing the watcher  612  of the executed operation). The monitoring can also be realized by a mechanism of informing any change of the data, as provided in certain databases.  
         [0119]    The watcher  612 , upon detecting an operation on the C/A object managed thereby (S 7   b   01 ), informs the manager of the object of such operation and request the execution of a process corresponding to such operation (S 7   b   02 ).  
         [0120]    The manager of the object means a process that has generated such object (also called the object manager). In the present embodiment, as the C/A object is usually generated by the Session manager, it becomes the object manager.  
         [0121]    The Session manager ( 606 ), if being the object manager, receives the process request (S 7   c   01 ), which in the present conference system is an addition/deletion of the Cpath to/from the CollabField, and to/from Activity. (These will be understood from the content of description of the operation in the aforementioned coordinative work model description.).  
         [0122]    In response to such process request, the Session manager  606  executes the following processes (S 7   c   02 ):  
         [0123]    Addition of Cpath to CollabField: to form actual transmission paths for the moving image and the voice, corresponding to Cpath;  
         [0124]    Deletion of Cpath from CollabField: to close actual transmission paths for the moving image and the voice, corresponding to Cpath;  
         [0125]    Addition of Cpath to Activity: to transfer actual data in the actual transmission paths for the moving image and the voice, corresponding to Cpath;  
         [0126]    Deletion of Cpath from Activity: to terminate data transfer in the actual transmission paths for the moving image and the voice, corresponding to Cpath.  
         [0127]    As will be apparent from FIGS. 7A to  7 C, the individual operations of the Session managers  605 ,  606  and of the watcher  612  are very simple. The coordinative work model description may be regarded as the description of a combination of these operations.  
         [0128]    As explained in the foregoing, the present embodiment defines the C/A object as the description means of the coordinative work form and the coordinative work model description for describing the “conference” by the C/A objects, and provides, under such definitions, server programs of the Session manager and the Watcher for controlling the system.  
         [0129]    It realizes a remote conference system by providing the coordinative work model description for the “conference” modeled with the roles of the chairman and the speaker, and also providing the Session manager program as the user interface.  
         [0130]    The present embodiment has explained the description and the realization of the “conference” as the coordinative work form, but the C/A objects and the Watcher server of the present embodiment can be used for describing and realizing various coordinative work forms, in addition to the “conference”. The Session manager excluding the user interface is so realized as to process the operations on the C/A object not dependent on the coordinative work form. Consequently the Session manager can be utilized on the coordinative work systems other than the “conference”.  
         [0131]    The present embodiment of the invention has enabled realization of a remote conference system capable of supporting complex coordinative work forms such as the supporting of the roles, in comparison with the conventional conference systems.  
         [0132]    The present embodiment involves certain restrictions such as the limitation to only one speaker, but such restrictions are not essential on the C/A objects. It is therefore possible to define and realize the coordinative work model description without such restrictions, by means of the C/A objects.  
         [0133]    [Other Embodiments] 
         [0134]    In contrast to the first embodiment constituting a conference management system, a second embodiment of the present invention provides a remote awareness system for controlling cameras in plural locations.  
         [0135]    The remote awareness system allows to call the images of cameras in suitable locations onto the display, thereby recognizing the current status of the remote locations. It is different from the coordinative work in strict sense as in the conference, but can be regarded as a coordinative work of a wider sense, in providing means for the information exchange among the users as a preparatory stage for the coordinative work. Such remote awareness system can also be constructed according to the present invention.  
         [0136]    At first reference is made to FIG. 8 for explaining the principal components of the present embodiment. A personal computer (hereinafter also simply called machine)  801  is composed of a CPU  802  executing the processes of the present embodiment and a main storage  803  storing VideoSender  810  and MultiViewer  811  constituting the softwares of the present embodiment, connected mutually by a computer bus  805 . However the present system is not limited to the personal computers but is applicable also to work stations similar to those in the first embodiment. The VideoSender  810  is a program for fetching the image of a camera  809  and sending it to MultiViewer  811 , while the MultiViewer  811  is a program for displaying the received image on a display  804 .  
         [0137]    Also a database  806  for storing the common data required for the operations of the present system, a display  804  for providing a user interface allowing the user to execute the operations of the system, and a camera  809  for fetching the ambient image of the user are connected to the machine  801 .  
         [0138]    In FIG. 8, the VideoSender  810  and the MultiViewer  811  function on a same machine, but, in the present system, either one may function on a difference machine connected by the computer network. In case the VideoSender  810  functions in another machine, the camera  809  is installed on the machine in which the VideoSender  810  exists.  
         [0139]    The database  806  holds base model information  807  and session model information  808  similar to those in the first embodiment. They have information same as that in the C/A objects and the coordinative work model description objects in the first embodiment, but in a text data format of ASCII character train instead of the C ++  language objects as in the first embodiment.  
         [0140]    The database  806  itself has a mechanism of managing the permanence and continuity of data as in the general relational database or the object oriented database, but the present embodiment adopts, among such databases, one having a mechanism of automatically informing the client of a renewal of the data in the database (variation informing function). If the database lacks such mechanism, the variation informing function has to be provided by a separate server such as the watcher in the first embodiment.  
         [0141]    In the present embodiment, there is assumed a case where the data format in the MultiViewer  811  and the VideoSender  810  is different from that in the database  806 . For this reason, model mapping modules  812 ,  813  for conversion between the data formats are incorporated in the MultiViewer  811  and in the VideoSender  810 . The model mapping modules  812 ,  813  are realized as interpreters of the TCL program language. More specifically, the data base  806  contains base model information  807  and the session model information  808  in the form of TCL scripts and related data. (As to TCL, reference is to be made to “Tcl and the Tk Toolkit”, John K. Ousterhout, Addison-Wesley, 1994.) The model mapping modules  812 ,  813  also provide interfaces for reference, renewal, interpretation and execution of the session model information  1115  and the base model information  1114  for other modules in the program. Therefore, in the sense of the programming model, the model mapping modules  812 ,  813  perform functions similar to those of the objects in the C ++  language.  
         [0142]    In the present embodiment, the information on the database  806  is not copied. Therefore, when necessary, the model mapping modules  812 ,  813  have to refer to the database  806 .  
         [0143]    In the following, the present system will be explained from the standpoint of the user, with reference to FIG. 9, wherein three users  901 ,  902 ,  903  are executing a work on the respective machines which are connected by a network  912  to enable mutual data communication.  
         [0144]    Cameras  907 ,  908  are installed at the users  901 ,  902 , and displays  904 ,  905  display windows  909 ,  910  constituting the user interface of the VideoSender. Utilizing the user interface of the windows  909 ,  910 , the users  901 ,  902  effect control (size, image quality and designation of whether or not to disclose the image to other users) of the images fetched by the cameras  907 ,  908 .  
         [0145]    Also the display  906  of the user  903  displays a window  911  providing the user interface of the MultiViewer. This window provides the user interface for displaying the images from the cameras  907 ,  908  or displaying the image of the camera installed at another machine.  
         [0146]    In FIG. 9, the user  903  can cause the monitor to display the images of other users  901 ,  902 , thereby recognizing the status.  
         [0147]    The description of the base model information in the present embodiment also has the following components:  
         [0148]    Attendee, Cpath, CollabField and Activity as in the first embodiment, with the same meanings as therein. However, in the present embodiment, since the description is made by the TCL language, the above-mentioned components are defined as TCL functions, which have the following basic structure:  
         [0149]    proc Attendee {args}{ 
         [0150]    #head of argument is designation of operation primitive  
         [0151]    eval “[lindex $args 0] $args”;  
         [0152]    } 
         [0153]    The above-mentioned script defines the Attendee as a process for calling a function of a name same as that of the operation primitive designated at the head of the argument. Other components are also defined similarly:  
         [0154]    The remote awareness can be represented, in the coordinative work model description as in the first embodiment, in the following manner. In the present embodiment, the coordinative work described by the base model is called session model information, which can be prepared in the same manner as in the first embodiment. The components of the remote awareness are:  
         [0155]    AwarenessSession, VideoSenderAttendee and MultiViewerAttendee whereby defined are AwarenessSession for abstracting the remote awareness activity, and VideoSenderAttendee and MultiViewerAttendee corresponding to the processes of VideoSender and MultiViewer.  
         [0156]    The VideoSenderAttendee and the MultiViewerAttendee correspond to Attendees. While the users correlate to the Attendees in the “conference” of the first embodiment, the processes are correlated with the Attendees in the “remote awareness” of the present embodiment, so that the users and the Attendees are not correlated on the model, though they are not completely isolated in the sense that the programs are activated by the users.  
         [0157]    The AwarenessSession is correlated with the CollabField but is merely defined as a container therefor, and such concept as the AwarenessSession is not given by the interface provided to the users. In a wider sense, the window  911  in FIG. 9 corresponds to the AwarenessSession.  
         [0158]    Then the operations executable by the user for the services are defined for each of MultiViewerAttendee and VideoSenderAttendee. For the MultiViewerAttendee there can be defined the following operations:  
                                                   Operation   Meaning                           ConnectSender   Connection with VideoSender           DisconnectSender   Disconnection from VideoSender                      
 
         [0159]    and, for the VideoSenderAttendee:  
                                                   Operation   Meaning                           MarkeAvailableFor   Permit image transmission to a               specified Viewer           MakeDisableFor   Inhibit image transmission to               a specified Viewer                      
 
         [0160]    These operations are represented on the base model as the following processes. In the present embodiment, the following processes are described by the TCL language, but the following explanation is made with the ordinary language.  
         [0161]    ConnectSender  
         [0162]    Argument: VideoSenderAttendee to be connected  
         [0163]    1. Generate AwarenessSession if MultiViewerAttendee has not generated AwarenessSession, and add Attendee corresponding to MultiViewerAttendee to CollabField in the generated AwarenessSession;  
         [0164]    2. Extract corresponding Attendee from the given VideoSenderAttendee and add it to CollabField in AwarenessSession;  
         [0165]    3. Add Cpath from the added Attendee to the self Attendee to CollabField in the AwarenessSession.  
         [0166]    DisconnectSender  
         [0167]    Argument: VideoSenderAttendee connected  
         [0168]    1. Extract Attendee from the given VideoSenderAttendee and delete it from CollabField in AwarenessSession.  
         [0169]    Also delete, from CollabField, all the Cpaths having the Attendee as the sender or the receiver.  
         [0170]    MakeAvailableFor  
         [0171]    Argument: MultiViewerAttendee requesting image  
         [0172]    1. Extract corresponding Attendee and AwarenessSession from the given MultiViewerAttendee;  
         [0173]    2. Also extract CollabField from AwarenessSession;  
         [0174]    3. In the extracted CollabField, render active the Cpath having the self Attendee as the sender and the Attendee extracted from MultiViewerAttendee as the receiver;  
         [0175]    4. Start transmission of the moving image and the voice to the actual transmission paths of the moving image and the voice corresponding to the active Cpaths.  
         [0176]    MakeDisableFor  
         [0177]    Argument: MultiViewerAttendee requesting image  
         [0178]    1. Extract corresponding Attendee and AwarenessSession from the given MultiViewerAttendee;  
         [0179]    2. Further extract CollabField from the AwarenessSession;  
         [0180]    3. Render inactive Cpath having the self Attendee within the extracted Collabfield as the sender and the Attendee extracted from MultiViewerAttendee as the receiver;  
         [0181]    4. Terminate transmission of the moving image and the voice to the actual transmission paths of the moving image and the voice corresponding to the deactivated Cpath.  
         [0182]    The components and operations of the coordinative work form, described in the above-explained manner, are described as the TCL processes and managed as the session model information in the database. As an example, the MultiViewerAttendee is defined as follows:  
         [0183]    proc MultiViewerAttendee (args) { 
         [0184]    global mv_attendee_table;  
         [0185]    # head of argument being designation of  
         [0186]    operation primitive eval “[lindex $args 0] 
         [0187]    $args”;  
         [0188]    } 
         [0189]    Thus the description is made as a process, similarly as the components in the base model explained above. Also the correlation between Attendee and MultiViewerAttendee is managed by mv_attendee_table defined as an association arrangement, and the correlation table is also contained in the session model information.  
         [0190]    In the above-explained description, “eval” means evaluation.  
         [0191]    [0191]FIG. 10 shows CollabField and Activity formed by the awareness system in such description.  
         [0192]    More specifically, the CollabField formed by Awareness Session is composed of an Attendee corresponding to a MultiViewerAttendee and Attendees corresponding to plural VideoSenderAttendees and only contains Cpaths directed from the latter to the former. Referring to FIG. 10, each of Attendees  1002 ,  1003 ,  1004  is correlated with a VideoSenderAttendee, and there are formed Cpaths having the Attendee  101 , correlated with the MultiViewerAttendee, as the receiver. These components constitute CollabField  1008 .  
         [0193]    In FIG. 10, Cpaths  1005 ,  1006 , belonging to Activity  1009 , are capable of actually receiving and displaying the data of the moving image and the voice from the VideoSender processes, but Cpath  1007 , not belonging to Activity  1009  and being inactive, is incapable of receiving data from the VideoSender process which manages the Attendee  1004 . However Cpath  1007  may become active under another situation. In case plural Attendees are present corresponding to plural MultiViewers, there exist plural AwarenessSessions having CollabField and Activity as explained above. The Cpath  1007  is inactive in the illustrated situation, but a corresponding Cpath may be rendered active for a different Attendee.  
         [0194]    Now the mode of control of the application behavior by the incorporated coordinative work model description will be explained with reference to FIG. 11, and the function of a model mapping module  1116  in the process to be explained is represented by a flow chart in FIG. 12. The functions of model mapping modules  1117 ,  1118  are identical with that of the model mapping module  1116  as shown in FIG. 12 and will not, therefore, be explained in particular.  
         [0195]    In FIG. 11, it is assumed that three users  1107 ,  1108 ,  1109  are conducting a conference by the present system, utilizing machines  1101 ,  1102 ,  1103  connected by a network  1112 . In the machines  1102 ,  1103  used by the users  1108 ,  1109  there are installed cameras  1110 ,  1111  and there are respectively activated the Videosenders  1104 ,  1105 . In fact the user  1108 ,  1109  can also activate MultiViewers, but, for the purpose of simplicity, it is assumed that MultiViewer  1106  is activated only in the environment of the user  1107 .  
         [0196]    Now, referring to FIG. 11, it is assumed that the user  1107  requests that MultiViewer  1106  receives the moving image from VideoSender  1105  and effects its display. (It is assumed that, at this point, the data transfer connection is not yet formed between MultiViewer  1106  and VideoSender  1105 .) Upon receiving the request from the user, MultiViewer  1106  calls the interface of the model mapping module  1118  and requests the request to be processed. Receiving the user request (S 1201 ), the model mapping module  1118  extracts the session model information  1115  and the base model information  1114  from the database  1113  (S 1202 ) and interprets the TCL scripts therein thereby executing the request from the user (S 1203 ). In the present case, there is executed the MultiViewerAttendee process described in the session model information  1115 . This process is finally executed as an operation on the base model information, and the result is re-written, by the model mapping module  1116 , in the base model information  1114  and the session model information  1115  in the database  1113  (S 1204 ).  
         [0197]    Then the result is informed to the VideoSender  1105  by the variation informing function of the database  1113 .  
         [0198]    VideoSender, upon recognizing an operation on the base model information managed thereby, executes a process corresponding to such operation.  
         [0199]    The process requests, receivable by VideoSender  1105  as a result of process of MultiViewer  1106 , are followings, as in the first embodiment:  
         [0200]    addition of Cpath to CollabField  
         [0201]    deletion of Cpath from CollabField  
         [0202]    addition of Cpath to Activity  
         [0203]    deletion of Cpath from Activity.  
         [0204]    In response to such process requests, VideoSender  1105  executes following processes:  
         [0205]    addition of Cpath to CollabField  
         [0206]    To form the actual transmission path for the moving image and the voice, corresponding to Cpath.  
         [0207]    deletion of Cpath from CollabField  
         [0208]    To close the actual transmission path for the moving image and the voice, corresponding to Cpath.  
         [0209]    addition of Cpath to Activity  
         [0210]    At first the user of VideoSender is given a display that an awareness reference is requested by MultiViewer, and the discretion of the user is requested. The user executes MakeAvailableFor or MakeDisableFor, depending on the situation. Execution of MakeAvailableFor starts data transmission to the actual transmission path for the moving image and the voice corresponding to Cpath. Execution of MakeDisableFor renders Cpath inactive and terminates data transmission to the actual transmission path for the moving image and the voice.  
         [0211]    deletion of Cpath from Activity  
         [0212]    To terminate data transmission in the actual transmission path for the moving image and the voice corresponding to Cpath.  
         [0213]    As explained in the foregoing, the present embodiment defines the base model as the description means of the coordinative work form and the session model description for describing the awareness by the base model, and provides a model mapping module executing such definitions.  
         [0214]    It also provides the session model description for the remote awareness system, and also provides means for executing control matching the coordinative work model of the application, by incorporating the model mapping modules in the two applications, VideoSender and MultiViewer.  
         [0215]    The present embodiment is different in configuration from the first embodiment, but utilizes a base model equivalent to that therein, so that the “conference” system of the first embodiment can also be realized in the present embodiment. In such case, as “conference” and “awareness” can be described by the base model, there can be realized a system uniting these two coordinative work forms and allowing mutual shift, by adding a process of shift from “awareness” to “conference” to the base model.  
         [0216]    The present embodiment of the invention, managing the base model and the session model in the form of scripts of character trains, allows the user to suitably vary the contents thereof utilizing the function of the database. Therefore the variation or expansion of the session model can be achieved easily.  
         [0217]    Also thus realized awareness system itself has flexible expansivity because of the structure based on the base model, and can function without being influenced by the number or configuration of VideoSenders and MultiViewers. As the behaviors of ViewSender and MultiViewer are basically described as processes for the operations on the base model, the variations in ViewSender and MultiViewer can be limited to the user interfaces even when the session model is expanded.  
         [0218]    In the following there will be explained another embodiment of the present invention, representing a cooperation of synchronized applications for CSCW (computer supported coordinative work), designed for supporting the coordinative works executed synchronously in spatially dispersed environments.  
         [0219]    Now there is considered a situation shown in FIG. 13 where, in the combination of a “video conference application” and a “remote awareness application” for referring to the image of a video camera in a distant location, the presence of a user is at first confirmed by the “remote awareness application” and a work is then started with such user by the “video conference application”.  
         [0220]    In such combination, support is desired for a smooth shift from a search/confirmation operation for the user in a “awareness application”  2000  to a coordinative work in a “video conference application”  3000  shown in FIG. 13. For meeting such requirement, it is necessary to realize transactions such as the transfer of information for example on the users between the two CSCW applications and the efficient transfer of the resources such as a camera  2002  used in the awareness application to the video conference application, thereby efficiently resolving the mismatching on the user interface or the competition between the CSCW applications in the resources. Such requirement also occurs when the “awareness application”  2000  and the “video conference application”  3000  function simultaneously (co-existence).  
         [0221]    Therefore, “cooperation of CSCW applications” is defined to indicate various interactions between the CSCW applications in case of:  
         [0222]    shift from a CSCW application to another; and  
         [0223]    co-existence of two or more CSCW applications.  
         [0224]    The CSCW application cooperation can be generally classified into the following two categories, according to the object of coordination:  
         [0225]    1. Cooperation  2010  between the coordinative process groups; and  
         [0226]    2. Cooperation  2020  between the coordinative work models.  
         [0227]    In general, the CSCW application is realized by a group of processes functioning in plural dispersed hosts. Consequently, the shift /co-existence of the CSCW applications have an aspect of the shift /co-existence of process groups constituting the CSCW applications (hereinafter called coordinative process groups).  
         [0228]    “1. Cooperation between the coordinative process groups”  2010  means cooperation required in realizing shift/co-existence of the coordinative process groups. Such cooperation is related to realization of efficient cooperation of the CSCW applications, and, in specific sense, following two kinds of cooperation can be conceived:  
         [0229]    Resolving overlapping of hardware resources and software modules usable in common:  
         [0230]    The CSCW applications to be subjected to shift may utilize resources such as a video camera or a microphone in common or may have a same program or process in common. In such case, efficient shift /co-existence can be realized by re-utilization or common use of such resources or processes. Without such support, there may be encountered a drawback that a same program is activated at every request.  
         [0231]    Access control to hardware resources not usable in common:  
         [0232]    In case of co-existence of the coordinative work forms, there inevitably occurs a situation where the resource itself only permits an exclusive access. In such case a mechanism between the CSCW applications is indispensable for the access control to the resources.  
         [0233]    “2. Cooperation between the coordinative process groups”  2020 , constituting the other type of cooperation, means cooperation of the coordinative work forms such as “conference”, “lecture meeting” and “coordinative writing” provided by the CSCW applications to the users.  
         [0234]    In the cooperation, what is important is the user interface how to uniformly presenting the plural CSCW applications to the users. In this sense there are generated various interactions depending on the coordinative work models to be considered. In the following there are explained representative examples of such cooperation:  
         [0235]    Control of correlation between the components of the coordinative work models:  
         [0236]    Different coordinative works have different components, but certain correlation may occur between such components in case of shift /co-existence.  
         [0237]    As an example, there is considered the aforementioned shift from the “remote awareness application”  2000  to the “conference application”  3000 . In the “remote awareness application”  2000 , the video camera in the remote location is a basic component in the coordinative work form. On the other hand, in the “conference application”  3000 , the user constituting the attendee of the conference is a basic component.  
         [0238]    In the shift between the two CSCW applications, there is conceived a correlation that a person fetched by the video camera before shift becomes the user after the shift. In the present embodiment, by rendering such correlation controllable, there can be avoided a situation where the person fetched in the camera has to be designated as an attendee of the conference after the “conference application”  3000  is activated.  
         [0239]    Such support of the coordination is however hindered by a fact that, in the CSCW applications to be subjected to the shift /co-existence:  
         [0240]    difference in process configuration and in access forms to the resources; and  
         [0241]    difference in components of the coordinative work models and behaviors thereof: are not necessarily made clear. Unless such differences are made clear, it is not possible to determine the correlations of the components and is therefore difficult to realize the description (programming)/control of the cooperation. These difficulties will become severer in realizing “cooperation between coordinative process groups” and “cooperation between coordinative work models”, with the diversification of the CSCW applications.  
         [0242]    In consideration of the foregoing, the present embodiment supports realization of the cooperation of the CSCW applications, in the groupware framework CCF (collaboration control facility), by:  
         [0243]    enabling description of configuration/form/behavior; and  
         [0244]    providing programming and control means for the cooperation based on such description;  
         [0245]    both on the coordinative process groups and the coordinative work models.  
         [0246]    In the following there will at first be outline the CCF, and then explained the realization in the CCF, of each of the cooperations of the coordinative process groups or the coordinative work models.  
         [0247]    The CCF as the groupware framework provides a C ++  CCF Toolkit, which provides a programmer interface for describing the configuration, behavior etc. of the coordinative process groups and the coordinative work models. The CCF Toolkit also provides a programmer interface for describing the coordination to be realized between the CSCW applications.  
         [0248]    The CSCW application, prepared with the incorporated CCF Toolkit, is controlled/managed by a CCF Core System  3501 .  
         [0249]    The CCF Core System  3501  is composed of two programs, which are CCF Core Server and CCF Core Interface. The former is a concentrated server for managing the information on the CSCW application, and the latter is a program for providing the user with a control interface for the CSCW application, such as the start thereof.  
         [0250]    [0250]FIG. 15 shows the concept of the CCF Core System  3501 .  
         [0251]    The interior of the CCF Core System is composed of the following two layers, corresponding to the aforementioned two types of cooperation:  
         [0252]    Node model layer  3500   
         [0253]    It manages what processes constitute the CSCW application and how the processes are correlated as the components. It executes control, such as start and end, of the processes of the CSCW application, based on a Node model thereof to be explained later. In the control of cooperation, it provides a cooperation mechanism between the coordinative process groups.  
         [0254]    WorkEnv layer  3600   
         [0255]    It handles the coordinative work model of the CSCW application, and manages and controls the correspondence between the operations on the coordinative work model provided by the CSCW application and each process in the Node model layer. In the control of coordination, it provides a cooperation mechanism between the coordinative work models.  
         [0256]    In the following there will be explained the support for cooperation in the coordinative process groups and the coordinative work models.  
         [0257]    The cooperation support for the coordinative process groups is executed by the CCF in the following manner, under the management of the Node model layer shown in FIG. 16.  
         [0258]    The Node model layer supports the cooperation by providing:  
         [0259]    a Node model for describing the coordinative process group constituting the CSCW application; and  
         [0260]    a cooperation control mechanism based on the Node model.  
         [0261]    The Node model shown in FIG. 16 is a CSCW application control model in a program/process unit not considered, and is composed of the following components:  
         [0262]    Nodes  4010 ,  4020   
         [0263]    They abstracts the user environment or the host where the program of the CSCW application functions, and function as the management unit for Resource and Module to be explained later.  
         [0264]    Module  4030   
         [0265]    It abstracts the process constituting the CSCW application. The Module managed in the Node can be regarded as a process on the host corresponding to the Node.  
         [0266]    Resource  4050   
         [0267]    It represents a resource exemplified by external input/output devices such as a camera or a microphone. The Resource managed in the Node can be regarded as an external input/output device installed in the host corresponding to the Node or as a management server therefor.  
         [0268]    Channel  4060   
         [0269]    Channel represents a communication path between the Module  4030  and the Resource  4050 . A channel can represent not only a 1:1 communication but also a 1:N communication such as broadcasting. The Channel can be formed not only between the Module and the Resource within a same Node, but also between the Module and the Resource belonging to different Nodes.  
         [0270]    The Node model describes:  
         [0271]    functioning processes;  
         [0272]    resources to be used; and  
         [0273]    access busses to the communication paths between the processes and to the resources; in each host where the coordinative process group of the CSCW application functions.  
         [0274]    The CSCW application is represented, by the Node model, as a group of Nodes correlated with the relevant hosts. The above-mentioned components are respectively given unitary names and are collectively managed by the CCF Core Server, which monitors the actual behavior of the CSCW application, utilizing the Node model, and executes controls when necessary.  
         [0275]    For forming the above-explained Node model, it is necessary to describe, in advance, the Node formed by each groupware application.  
         [0276]    The information constituting the basic design of such Node model is called Node frame information, and the interface required for the preparation thereof is provided by the C ++  class group of the CCF Toolkit.  
         [0277]    The Node frame information is managed also by the CCF Core Server, and is used, when necessary, for the preparation of the Node model.  
         [0278]    As explained in the foregoing, the cooperation of the coordinative process groups can be processed as common-use/access control for the processes and resources required in the shift/co-existence of the CSCW applications.  
         [0279]    Such common-use/access control of the processes and resources can be described and controlled as a replacement process for the Node, Module, Resource and Channel.  
         [0280]    [0280]FIG. 17 shows the algorithm for the cooperation process in this Node model, in case of a shift from a CSCW application A to another B. Now considered is a host where both applications form Nodes, and it is assumed that the shift is made from a Node  4010  in the CSCW application A to a Node  4020  in the CSCW application B (“before shift” in FIG. 17). The shift between these Nodes is realized by reconstructing the Node 2 with the Modules, Resources and Channels of the Node 1.  
         [0281]    This reconstruction is achieved, if the Node  1  before shift and the Node 2 after shift have common Modules (ovals in FIG. 17) and common Resources (rectangles in FIG. 17) by re-utilizing these components (as shown in “in shifting” in FIG. 17), except for a case where the re-utilization is inhibited for such Module or Resource even it has a same name. A Channel is not re-utilized even if the name is same, unless the Modules or the Resources at both ends are re-utilized. In thus re-utilized Modules, Resources and Channels, the corresponding processes are utilized as a part of the CSCW application B.  
         [0282]    Once the components to be re-utilized are determined, there are generated the Modules and Resources lacking for the formation of the Node 2 and at last all the Channels are generated (“after shift” in FIG. 17). New processes are activated by this process, and the communication paths are formed between the re-utilized processes and the new processes.  
         [0283]    The shift from the CSCW application A to B is completed by executing the above-explained process for all the Nodes.  
         [0284]    The process for co-existence of the CSCW applications is executed in a similar manner, but there may occur a situation where either one alone of the application can make access to the Resource. In such case, on the Node model, same Resources are present for both Nodes, but either one alone can form the Channel between such Resource and another Module. The access control between the CSCW applications sharing the resource can be handled on the Node model, by replacing the Channel according to the necessity.  
         [0285]    As explained in the foregoing, the developer of the CSCW application can provide information necessary for the cooperation with another CSCW application in the coordinative process group, by the description of the CSCW application by the Node model and by the description of the re-utilizable Module, Resource and Channel therein.  
         [0286]    With respect to the CSCW application described by the Node model, the Node model layer of the CCF Core System manages the correlations between the components on the Node model and the actual hosts, processes, resources and communication paths.  
         [0287]    There are thus executed processes of reflecting the operations on the Node model to the actual hosts, processes, resources and communication paths, and also reflecting the results onto the Node model by monitoring the behaviors of the actual hosts, processes, resources and communication paths.  
         [0288]    The reflection from the Node model to the actual results is executed when the user requests the operations of the CSCW application for example through the CCF Core Interface.  
         [0289]    The reflection from the actual hosts, processes, resources and communication paths to the Node model is executed, after an independent action of the CSCW application, when such action is informed to the CCF. Also in case the CCF Core Server detects an abnormal process termination for example by an error, there is executed erasure of the relevant Modules, Resources and Channels.  
         [0290]    In the following there are listed possible operations on the Node model and the corresponding CCF processes:  
         [0291]    Generation and Erasure of Node  
         [0292]    Generation and erasure of Modules, Resources and Channels in the Node;  
         [0293]    Generation and Erasure of Module  
         [0294]    Start/end of corresponding program;  
         [0295]    Generation and Erasure of Resource  
         [0296]    Start/end of corresponding resource management server;  
         [0297]    Generation and Erasure of Channel  
         [0298]    Generation/erasure of corresponding communication path.  
         [0299]    In the cooperation of the coordinative process groups, what is important for realizing the access control etc. is realization of the Channel control. The control of the communication path corresponding to Channel is executed by a handler process for the following message, transmitted from the CCF to the program of the groupware application. This message handler is provided by the developer of the CSCW application and forms the actual communication path by socket, rpc etc.:  
         [0300]    CREATE-CHANNEL Generation of Channel  
         [0301]    DESTROY-CHANNEL Erasure of Channel  
         [0302]    Such communication path formation will be explained with reference to FIG. 18.  
         [0303]    In the communication path formation, one of the Modules or the Resources at both ends of the Channel becomes an owner (Node #1 in FIG. 18), which effects generation/erasure of the communication path in response to the above-mentioned message, in the numbered order in FIG. 18. The process corresponding to the non-owner Module or Resource is given a message informing the generation/erasure of the communication path, after the end of the owner process. Since such informing message contains information such as a port number required for establishing the communication path by socket, RPC etc., the process receiving such informing message is rendered capable of establishing the communication path.  
         [0304]    The WorkEnv layer of CCF handles the correlation of information between the coordinative work models in the cooperation thereof.  
         [0305]    In the following there will be explained the cooperation support in such WorkEnv layer, with reference to FIG. 19.  
         [0306]    The mechanism of the cooperation support for the coordinative process groups in the Node mode layer is provided by the CCF Core Server, but the cooperation control mechanism between the coordinative work models is provided from the CSCW application.  
         [0307]    Instead, the CCF provides:  
         [0308]    a C ++  interface for describing the coordinative work model such as “conference” or “lecture meeting” provided by each CSCW application;  
         [0309]    a C ++  interface for describing or controlling the correlation of the components, such as the users, between the two coordinative work models.  
         [0310]    The description of the coordinative work models is achieved by programming:  
         [0311]    correlation between the components of the coordinative work models and those of the Node model; and  
         [0312]    correlation between the operations to the components of the coordinative work models and the operations on the Node model, and adding such program to the CCF Core System. This program is called WorkEnvManager.  
         [0313]    Also the correlation between the coordinative work models is described as a program, called WorkEnvMover, which is activated by the WorkEnv layer of the CCF Core System at the cooperation of the CSCW applications and executes common-use/re-utilization of the information between the coordinative work models.  
         [0314]    The workEnvManager and the WorkEnvMover are provided by the developer of the application as a part of the CSCW application, and the CCF realizes the cooperation of the coordinative work models, utilizing these programs.  
         [0315]    In the present embodiment, the cooperation of the CSCW applications is represented by an interaction between the process groups constituting the CSCW applications and an interaction between the coordinative work models provided to the users by the CSCW applications.  
         [0316]    The support of the cooperation can be realized by:  
         [0317]    enabling description of configuration/form/behavior of the coordinative process group/coordinative work model; and  
         [0318]    providing programming and control means for the cooperation, based on such description.  
         [0319]    The CCF describes or controls the interaction between the coordinative process groups by the Node model. Also for the support between the coordinative work models, it provides a programmer interface for describing and controlling the relation between the components of the model.  
         [0320]    However, in the support basically designed for the coordinative work models, it is also necessary to consider the cooperation other than the correlation between the components.  
         [0321]    The present invention also includes a computer-readable medium which stores the software of the above-explained coordinative works. Such medium can be a ROM, a disk-shaped medium or a tape-shaped medium, as long as the software of the sequences of the foregoing embodiments is stored in a computer-readable form.  
         [0322]    As explained in the foregoing, the embodiments of the present invention provide various advantages, such as:  
         [0323]    modeling various coordinative work forms, thereby facilitating the realization of a coordinative work support system supporting such coordinative works;  
         [0324]    modeling the state changes in various coordinative work forms, thereby facilitating the realization of a corresponding system;  
         [0325]    correlating various coordinative work forms, thereby facilitating the shift from a coordinative work form to another; and  
         [0326]    enabling realization of an application not influenced by the difference in the coordinative work form or the expansion thereof.