JPH0934842A - 処理システム及び処理装置 - Google Patents

Abstract

(57)【要約】 【課題】 複数の処理装置における共同作業単位におい
て、使い勝手の悪かった各種操作を行うためのアプリケ
ーションの使い勝手を向上する。 【解決手段】 1 台以上の処理装置によって構成される
作業環境において共同作業を行なう処理システムであっ
て、共同作業の単位を指定する手段と上記共同作業単位
の操作手段を有し、上記操作を上記共同作業単位の構成
要素に対する操作として記述する手段と、上記操作記述
手段によって記述された操作の実行手段を有することを
特徴とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は複数のユーザが複数
の処理装置上で共同作業を行なうことを可能にする処理
システム及び処理システムにおける処理装置に関するも
のである。

【０００２】

【従来の技術】近年、複数のパーソナル・コンピュータ
あるいはワークステーションなどのコンピュータを組み
合わせ、データの交換あるいは共有を可能にすることに
より、多人数での共同作業をサポートする、いわゆるグ
ループウェア・システムが提案され、実際に利用される
されるようになってきている。このようなグループウェ
ア・システムにおいて、その上で行なわれる共同作業を
概念化することにより、共同作業をアプリケーション・
プログラムなどと同様な単位として操作することを可能
にしているシステムが存在する。

【０００３】

【発明が解決しようとしている課題】しかしながら、こ
の共同作業単位( 仮にセッションとよぶ) と、実際にセ
ッション上で使用されるアプリケーションとの対応関係
は状況に応じてさまざまに変化する。

【０００４】このため従来のシステムでは、セッション
を単なる共同作業の場程度のものに限定し、そこで使用
されるアプリケーション・プログラムとは無関係に管理
せざるをえなかった。

【０００５】上述の問題をかんがみて、本発明はさまざ
まな共同作業単位を容易に提供でき、さらに共同作業単
位に応じて種々のアプリケーションプログラムを使い良
好に共同作業を行うことができる処理システム及び処理
システムにおける処理装置を提供することを目的とす
る。

【０００６】

【課題を解決するための手段】この発明では上記の問題
を解決するために、共同作業をサポートする共同作業支
援システムにおいて、 ・共同作業の単位( セッション) を指定する手段と ・上記指定されたセッションにおいて、ユーザがセッシ
ョン単位での操作を可能ならしめる手段を提供する。

【０００７】さらに、上記操作をセッションの構成要素
に対する操作として記述する手段を提供し、その記述手
段によって記述されたセッション操作の解釈および実行
手段を提供する。

【０００８】

【発明の実施の形態】

（第１の実施例）ここでは本発明の第1 の実施例につい
て図を用いながら説明する。

【０００９】図1 は、本実施例である会議管理システム
の構成図である。この会議管理システムでは、共同作業
として一般的な会議をサポートしており、この「会議」
に相当する管理単位のことを本実施例ではセッションと
呼ぶ。図1 において、ワークステーション(101) は本実
施例における処理の実行を行うCPU(102)と、本会議管理
システムの基本ソフトウェア群(109, 111, 113, 116, 1
17) を保持する主記憶(103) を計算機バス(105) で結合
することにより構成されている。また、本実施例におけ
る処理に必要な永続データを保持するためのハードディ
スク(106) と、ユーザがシステムの操作をおこなうため
のユーザインタフェースを提供するため端末(104) がワ
ークステーション(101) に結合されている。なお、後述
のユーザによる種々の操作は不図示のキーボードやポイ
ンティングデバイスにより入力されるものである。本シ
ステムでは基本ソフトウェアとして以下の5 種類のプロ
グラムが提供されている。

【００１０】・vc_sm 〔 会議情報管理プログラム(10
9)〕 会議情報管理プログラム(109) はvc_sm という名前のプ
ログラムとして提供されており、会議等に関するユーザ
情報(118) やセッション情報(119) など複数のプログラ
ムで共有される情報を管理する。

【００１１】これらの共有情報はハードディスク(106)
上に蓄積され、適宜、会議情報管理プログラム(109) に
よって読み出される。図1 において、ハードディスク(1
06) 上に蓄積されているサービス情報(107) とサービス
・スクリプト情報(108) も共有情報として会議情報管理
プログラム(109) によって管理されている。また、会議
情報管理プログラム(109) の中心部分は共有情報管理モ
ジュール(110) とよばれる。

【００１２】共有情報管理モジュール(110) は、管理下
にある共有情報に、同じ種類のデータ内で一意となるid
番号( これはデータの種類を表す名前と組み合わせて、
ユーザid, セッションidなどと呼ばれる。) を自動的に
割り当てる。

【００１３】会議情報管理プログラム(109) のクライア
ント( すなわち他の基本ソフトウェア111, 113, 116, 1
17) は、基本的にはこのid番号を用いて、共有情報を指
定する。

【００１４】本実施例における共有情報管理モジュール
(110) は、整数をインデックスとする単純な配列の集ま
りとして実装されているがハッシュテーブルその他のデ
ータ管理方式による実現も可能である。vc_sm(109)は、
システム全体で1 つだけ起動される。

【００１５】・vc_am 〔 会議操作インタフェース・プ
ログラム(111)〕 会議操作インタフェース・プログラム(111) はvc_am と
いう名前のプログラムとして提供されており、本システ
ムが提供しているセッション( すなわち会議）の開始・
終了などの操作のためのユーザ・インタフェースを提供
する。ｖｃ＿ａｍ（１１１）の主な処理はセッション操
作マネージャ(112) によって制御される。このセッショ
ン操作マネージャ(112) は、vc\_sm(109) のクライアン
トとして、ユーザからのセッション操作要求に応じて、
vc\_sm(109) で管理しているセッション情報等の参照、
変更等を行なう。vc_am(111)は本システムの利用者のユ
ーザ環境で1 つずつ起動される。

【００１６】・vc_tm 〔 サービス操作インタフェース
・プログラム(113)〕 サービス操作インタフェース・プログラム(113) はvc_t
m という名前のプログラムとして提供されており、セッ
ション上でのアプリケーション・プログラムの起動・終
了などの操作をおこなうためのユーザインタフェースを
提供する。本システムでは上記のようなアプリケーショ
ンをサービスと呼ぶ。

【００１７】たとえば、共有エディタやビデオ会議アプ
リケーション等がサービスとして利用される。

【００１８】vc_tm は、ユーザが参加しているセッショ
ンの数だけ各ユーザ環境上で起動され、各vc_tm はユー
ザの各セッションにおいて使用されるアプリケーション
を管理する。

【００１９】さて、vc_tm(113)内には2 つの重要なモジ
ュールが存在する。

【００２０】- サービス・マネージャ(114) サービス・マネージャ(114) は、サービスの起動・終了
などに必要な情報を管理するモジュールである。サービ
スに関連する情報のうち複数のユーザ間で共有可能な情
報はvc_sm(109)で管理されるが、個々のユーザに特有な
情報はサービス・マネジャ(14)内で管理される。

【００２１】- 代理実行モジュール(115) vc_am(111)やvc_tm(113)などが、他のユーザ環境で何ら
かの処理を行なう場合、その環境を管理しているvc_tm
に処理の代理実行を依頼する。代理実行モジュール(11
5) はそのためのインタフェースを提供するモジュール
である。

【００２２】・スクリプト・ハンドラ 〔サービス・ス
クリプト( 後述) 実行プログラム(116) ユーザが共同作業に使用できるサービスにはさまざまな
ものがあり、個々のサービスを制御するにはそれぞれに
対応した制御をおこなわなければならない。このような
vc_tm から利用可能なサービスの制御方法を記述したも
のをサービス・スクリプトと呼ぶ。サービス・スクリプ
トはサービススクリプト情報(108) としてvc_sm(109)に
よって管理されている。このサービス・スクリプトを解
釈・実行するのがービス・スクリプト実行プログラム(1
16) である。サービス・スクリプト実行プログラム(11
6) はスクリプト・ハンドラとも呼ばれ、必要に応じて
適宜vc_tm(113)によって起動されるコマンドである。

【００２３】・Notifier 〔会議情報変更通知プログラ
ム(117)〕 vc_am(111) 等でユーザが行なったセッションに関する
操作の結果は、 vc_sm(109)で管理されるセッション情
報等に反映されるが、その結果を各ユーザに分かるよう
提示するためには、各ユーザにインタフェースを提供し
ているvc_am およびvc_tm に、共有情報になんらかの変
更があった旨を通知してやる必要がある。 会議情報変
更通知プログラム(117) はNotifierともよばれ、この通
知の必要があった時にvc_am(111)やvc_tm(113)から起動
され、他のvc_am やvc_tm へ変更通知を発行する。この
変更通知はsocketやRPC によるプロセス間通信機構によ
って実現される。

【００２４】本実施例では、以上のような本発明の主要
な構成要素が、複数のプログラム中に分散して実装され
ているが、各構成要素の異なる組み合わせからなるシス
テムの実現もここでのべる実施例と同様にして可能であ
る。

【００２５】ここで、図2 を用いて本実施例が提供する
セッションおよびサービス操作のユーザ・インタフェー
スについて説明する。

【００２６】本実施例ではユーザはまず、自分の環境(
多くの場合自分専用のワークステーションである。) 上
でvc_am を起動することにより、会議管理システムの利
用を開始する。図2 におけるウィンドウ(201) がこのvc
_am 起動時に表示されるvc_am 初期(Initial) ウィンド
ウである。

【００２７】vc_am 初期ウィンドウ(201) は、vc_am を
起動したユーザをあらわすユーザ・アイコンが表示され
るユーザアイコン・フィールド(202) と、そのユーザの
現在の状況を表示するStatus情報フィールド(203) から
構成される。ユーザ・アイコンはユーザの顔写真などか
ら生成されるビットマップ・イメージである。

【００２８】また、Status情報フィールドには、 acceptable ( いつでも共同作業に参加できること
を示す) busy ( 重要な共同作業のみ参加できること
を示す) unavaiable ( 緊急時のみ共同作業に参加できるこ
とを表す) 等が表示される。さらに、Status情報フィールドをクリ
ックすることにより、より詳しいユーザの状況に関する
情報を登録することも可能である。

【００２９】またパネル(204) は、セッション操作パネ
ルとよばれ、vc\_am(111) がサポートするセッション操
作のためのインタフェースを提供するパネルである。セ
ッション操作パネル(204) は、ユーザがユーザアイコン
・フィールド(202) をクリックすると表示されるポップ
アップメニューの" セッション操作パネル" 項目を選択
することにより表示される。

【００３０】セッション操作ウィンドウ(204) 内には、
現在稼働中のセッションの名前を表示するセッション・
リスト(205) と、セッション・リストで選択されたセッ
ションの現時点での参加者のユーザアイコンのリストが
表示されるセッション・ユーザリスト(206) 、およびセ
ッション・リストからセッションを削除する( これは後
述する" セッションの終了操作" に相当する) 時とセッ
ション・ユーザリストからユーザを削除する( これは後
述する" セッションからの退席操作" に相当する) 時に
使用されるごみ箱フィールド(207)、 セッションの起動
操作を行うためのセッション起動ボタン(208) が存在す
る。

【００３１】図2 においては、セッション・リスト(20
5) 中には現在稼働中のセッション"Session\#1"と"Sess
ion\#2"が表示されている。また、セッションリストの
先頭の"〔新規セッション〕"は新たにセッションを起動
する時に選択され、この場合、起動時の初期ユーザの指
定にセッション・ユーザリストを使用することができ
る。図2 ではSession\#1がユーザによって選択されてお
り、セッション・ユーザリストには現時点でのSesseion
\#1 の参加者のユーザ・アイコン(209, 210, 211)が表
示されている。ユーザはセッション操作パネル(204) を
操作することにより、セッションに対して以下の操作を
行うことが可能である: - セッションの起動 - セッションの終了 - セッションへの参加 - セッションからの退席 これらの操作は、それぞれ会議の開始, 終了,(途中) 参
加,(途中) 退席に相当する行為をセッション上でモデル
化したものである。これらの操作が本システムでどのよ
うに処理されるかの詳細については後述する。次に、パ
ネル(212, 213, 214) はvc\_tmのユーザインタフェース
を提供するサービス操作パネルである。各サービス操作
パネル(212, 213, 214) はおのおの1 つずつのvc\_tmに
対応しており、まったく同じ構造をしている。そこで、
ここでは212 を用いて説明する。サービス操作パネル(2
12) の主要な構成要素はサービス・リスト(215) であ
る。このサービス・リスト(215) には、セッション内で
利用可能なビデオ会議アプリケーション等のサービスを
あらわすアイコン(216, 217, 218) が表示されている。

【００３２】本実施例では、起動されたサービスにはツ
ール番号が付加されて管理される。このツール番号と
は、サービスが起動される時に割り当てられる番号であ
り、その番号は、起動されたセッション内における同一
サービスにおいて一意となっている。

【００３３】サービスリスト(215) 中のサービス・アイ
コンの下に存在するフィールド(219,220,221) は、ツー
ル番号が付加されたサービス名のリストを表示する、ツ
ール・リストである。( このサービス名とツール番号を
つなげることにより生成される名前をツール名と呼
ぶ。) のこりの構成要素214 は、パネル(212) を表示し
ているvc\_tmが属しているセッションの名前を表示する
セッション名フィールドである。また、ごみ箱フィール
ド(215) は、セッション操作パネル内のゴミ箱フィール
ドと同様に、稼働中のサービスを終了させるために使用
される。

【００３４】すなわち、サービスアイコンあるいは、ツ
ールリスト中のツール名をごみ箱フィールド(215) 内の
drag\&dropすることにより、サービスの終了処理が実行
される。

【００３５】つぎに、図2 のようなユーザインタフェー
スを用いて行なわれるセッションおよびサービスの操作
がどのようにして処理されるかについて説明する。

【００３６】（vc_am 起動）ユーザの会議管理システム
の利用は、まずvc_am を起動することから始まる。(図3
参照) 例えば、ユーザ(301) が使用している端末(302)
上で、 ｖｃ＿ａｍ ＜ＲＥＴＵＲＮ＞ とタイプすると、ユーザ（３０１） が利用しているワ
ークステーション(303) 上でvc_am(304)が起動される。
vc_am(304)は起動されると、ユーザ(301) が本システム
の利用を開始したことを、別のワークステーション(30
5) 上で常時稼働しているvc_sm(306)に通知する。この
通知をユーザ・エントリの登録通知(307) と呼ぶ。ユー
ザ・エントリ登録通知(307) には、ユーザ(301) の名前
( ユーザ名) と、ユーザ(301) が利用しているホスト(3
02) の名前( ホスト名) が付加される。本システムにお
けるユーザはユーザ名とホスト名を指定することにより
一意に識別(identify)される。vc_sm(306)はユーザ・エ
ントリ登録通知(307) を受けとると、付加されているユ
ーザ名をキーとして、ハードディスク(308) からユーザ
(301) のユーザ情報(309) を取り出す。

【００３７】( ユーザ情報の参照、 311)ここで、ユーザ
(301) とユーザ情報(309) の対応づけは、ユーザ情報(3
09) をユーザ(301) のユーザ名をファイル名としたファ
イルとしてディスク(306) 上に置くことにより実現され
ている。

【００３８】したがって、ユーザ情報(309) の取得はユ
ーザ(301) のユーザ名をファイル名として持っているフ
ァイルをとり出すことによって行なわれる。vc_sm(306)
は、ユーザ情報(309) を取り出すとそのメモリイメージ
を共有情報管理モジュール(310) の管理下に置き以降の
ユーザ情報参照要求に備えてキャッシュする。

【００３９】これは他のクライアントがユーザ情報(30
9) を要求した場合に、ハードディスク(308) にアクセ
スする必要をなくすためである。

【００４０】（セッションの起動）ここではセッション
の起動処理について図4 と図9 を用いて説明する。

【００４１】図4 は、3 人のユーザ(401, 402, 403)
が、それぞれ端末(404, 405, 406) からワークステーシ
ョン(407, 408, 409) 上でvc_am(410, 411, 412)を起動
した状態における、ユーザ(401) によるユーザ(401, 40
2, 403) 間でのセッション( 会議) の起動の様子をあら
わす図である。

【００４２】また、図9 は図4 で説明する処理の流れを
フローチャートであらわしたものであり、そのうち図9a
はvc_am(411), 図9bはvc_sm(413), 図9cはNotifier(42
0) のフローチャートである。図2 で説明したように、
ユーザ(401) が端末(404) 上に表示されるセッション操
作ウィンド上でセッション開始要求(410) を行うと、こ
の要求はvc_am(411)内のセッション操作マネージャ(41
2) で処理される。

【００４３】すなわち、セッション操作マネージャ(41
2) は、まずvc\_sm(413) に、新しいセッションの生成
要求(414) を発行する(S9a01) 。この生成要求(414) に
は、セッションの初期ユーザであるユーザ(401, 402, 4
03) のユーザidが付加される。ここで上記のような要求
はsocketないしRPC 等によるプロセス間通信機構により
実装される。以降述べる同様な要求処理もプロセス間通
信機構により実現されている。

【００４４】vc_sm(413)は生成要求(414) を受け取る
と、セッションidとセッション名を生成し、新しいセッ
ションに割り当てる(S9b01, S9b02)。ここでセッション
idは共有情報管理モジュール(415) によって0 から順番
に生成順にふられる0 以上の整数である。

【００４５】また、セッション名は"Session\#" という
文字列とセッションidを連結した文字列として生成され
る。セッション名は共有情報管理モジュール(415) によ
ってvc_sm(413)上で管理されるとともに、生成要求(41
4) に対するリプライ・メッセージ(416) に付加され
て、vc_am(411)に送り返され(S9b03) 、セッション操作
マネージャ(412) によって保持される。次に、セッショ
ン操作マネージャ(412) はセッション上でのサービスの
利用を可能にするために、サービス操作ウィンドウを表
示するvc_tm(417)を起動する(S9a02) 。最後に、セッシ
ョン操作マネージャ(412) は、セッション内の他の初期
ユーザのvc_am(418, 419) に、セッションが開始された
旨を通知するために、Notifier(420) を起動する(S9a0
3) 。

【００４６】起動されたNotifier(420) は、起動時の引
数としてvc_am(411)から与えられる変更通知の送り先(4
02, 403)のユーザidから、vc_am(418, 419) との通信ポ
ートをオープンするために必要な情報をvc_sm の管理下
にあるユーザ情報から取り出す(S9c01) 。

【００４７】その情報をもとにvc_am(418, 419) との通
信ポートをオープンすると(S9c02)、Notifier(420) は
セッション起動通知(421, 422)を送信する(S0c03) 。vc
\_am(418, 419)内のセッション操作マネージャ(423, 42
4)が通知(421, 422)を受け取ると、それぞれvc\_tm(42
5, 426)を起動する。以上で、セッションの起動が完了
する。

【００４８】（セッション終了）つぎにセッションの終
了処理について図5 と図10を用いて説明する。

【００４９】図5 は終了処理の流れを概念的に表す図で
あり、図10は図5 におけるvc_am(511)の処理をフローチ
ャートで表したものである。

【００５０】図5 において、501 から509 までの構成要
素は、図4 における401 から409 までの構成要素に対応
している。

【００５１】セッション終了処理においては、ユーザ(5
01) が端末(504) 上のセッション操作ウィンドウ上での
セッション終了操作( すなわち、セッション・リストか
らのセッション名のゴミ箱フィールドへのdrag&drop)を
おこなうと、セッション終了要求(510) がvc_am(511)内
のセッション操作マネージャ(512) に発行され処理され
る。

【００５２】セッション操作マネージャ(512) は要求を
受けとると、vc_am(511)が管理しているユーザ環境にお
いて終了処理の対象となるセッションに対応するvc_tm
(513)に、現在セッション中で使用されているサービス
の終了要求(514) を発行する(S1001) 。終了要求を受け
とったvc_tm(513)はセッション内で稼働中のサービス(5
15) の終了スクリプト・ハンドラ(516) を起動する。終
了スクリプト・ハンドラ(516) はセッション内の全ユー
ザ環境における対象サービスの終了処理を、終了スクリ
プトの記述にしたがって実行する。( スクリプトの解
釈, 実行の詳細については後述する。）

【００５３】終了スクリプト・ハンドラ(516) は、ユー
ザ(501) のユーザ環境上のサービス(515) だけでなく、
セッションに属している全ユーザ(502, 503)のユーザ環
境上のサービス(517, 518)の終了処理も実行する。

【００５４】これは、終了処理を全vc\_tm(513, 522, 5
23) 内の代理実行モジュールに実行させることによつて
行なわれる。このようにしてセッション内の全ユーザに
おける全サービスの終了が完了すると、終了スクリプト
・ハンドラ(516) も処理を終了する。

【００５５】終了スクリプト・ハンドラ(516) の終了を
waitシステムコールで検知した(S1002) vc\_am(511) は
Notifier(517) を起動することによりセッション終了通
知(518, 519)をvc_am(520, 521) に送信したのち(S100
3) ，vc_tm(513)を終了させる(S1004) 。セッション終
了通知(518, 519)を受けとったvc_am(520, 521) も同様
にしてvc_tm(522, 523) を終了させる。最後にvc_am(51
0)はvc_sm(524)に終了処理がおこなわれたセッションの
削除要求(525) を発行する(S1005) 。この削除要求(52
5) には削除されるセッションのセッションidが付加さ
れる。vc_sm(524)は削除要求を受けとると、指定された
セッションに関する情報を削除する。この時点で、セッ
ションが完全に終了されることになる。

【００５６】（セッションへの途中参加）つぎにセッシ
ョンの途中参加処理について図6 と図11を用いて説明す
る。図6 は途中参加処理の流れを概念的に表す図であ
り、図11は図6 におけるvc_am(611)の処理をフローチャ
ートで表したものである。図6 において、ユーザ(601)
が途中参加処理を要求したユーザであり、ユーザ(602)
は参加処理の対象となるユーザであるとする。またユー
ザ(603) は処理対象となるセッションにすでに参加して
いるユーザである。ここで、 ユーザ(601) は処理対象
となるセッションに参加していてもいなくても、ここで
の処理には影響しないが、ここでは参加しているものと
して説明する。まず、ユーザ(601) が端末(604) に表示
されているセッション操作ウィンドウでセッション名を
選択し、セッション・ユーザリストにユーザ(602) のユ
ーザ・アイコンをdrag\&dropで追加することによって、
セッション参加要求(610) がvc_am(611)に発行される。

【００５７】vc_am(611)がユーザ参加要求(610) を受け
とると、セッション操作マネージャ(612) はセッション
情報へのユーザの追加要求(613) をvc\_sm(614) に発行
する(S1101) 。この追加要求(613) には、処理の対象と
なるセッションのidとユーザ(602) のidが付加される。

【００５８】vc_sm(614)は追加要求(613) をうけとる
と、指定されたセッションのセッション情報内の参加者
情報に指定されたユーザidを追加する。この時点でデー
タ上は、ユーザ(602) がセッションに追加されたことに
なる。vc_am はvc_sm からユーザ情報追加処理の終了の
旨をつたえるリプライ(615) を受けとると(S1102) 、次
に、ユーザ(602) を含むセッション内の全ユーザのvc_a
m(611, 616, 617)に、ユーザ参加通知を発行すべく、No
tifier(618) を起動する(S1103) 。起動されたNotifier
(618) は、途中参加通知(619, 620, 621) を発行する。

【００５９】途中参加通知(619, 620, 621) をうけとっ
たvc\_amのうち、参加対象ユーザ(602) のユーザ環境を
管理するvc_am(616)は参加したセッション上で利用され
るサービスを管理するために、vc_tm(622)を起動する。

【００６０】また、その他のvc_am(612, 617) では、新
たなユーザのユーザ・アイコンをセッションのユーザ・
リストに表示する。このようにして、会議管理機構にお
ける参加は完了するが、ユーザ(602) が実際の共同作業
に参加するためには、セッション内で使用されているサ
ービスをユーザ(602) からも利用できるようにしなけれ
ばならない。

【００６１】この要求をみたすために、vc_am(611)は使
用中の全サービスの参加処理スクリプト・ハンドラ(62
2) を起動する(S1104) 。参加処理スクリプト・ハンド
ラ(622) はユーザ(602) のユーザ環境におけるサービス
の途中参加処理を、vc_am(616)代理実行モジュールを利
用することにより、途中参加スクリプトに従って実行す
る。ただし、ここでユーザ(602) がセッションに参加し
ている唯一のユーザであった場合、参加処理スクリプト
・ハンドラ(622) は退席処理スクリプトではなく、サー
ビス開始処理スクリプトを解釈・実行する。これはこの
時点でだれも、サービスを起動していないためである。
以上のようにして、セッションへの途中参加処理が実行
される。

【００６２】（セッションからの途中退席）つぎにセッ
ションの途中参加処理について図7 と図12を用いて説明
する。図7 は途中退席処理の流れを概念的に表す図であ
り、図12は図7 におけるvc_am(711)の処理をフローチャ
ートで表したものである。

【００６３】図7 において、ユーザ(701) が途中退席処
理要求ユーザであり、ユーザ(702)がここで退席処理の
対象となるユーザである。最後のユーザ(703) はセッシ
ョンに参加しているが直接退席処理とは関係しないユー
ザである。ここで、 ユーザ(701) は処理対象となるセ
ッションに参加していてもいなくても、ここでの処理に
は影響しないが、ここでは参加しているものとして説明
する。

【００６４】まず、ユーザ(701) が端末(704) 上のセッ
ション操作ウィンドウでセッション名を選択し、表示さ
れるセッションユーザリストからユーザ(702) のユーザ
・アイコンをゴミ箱フィールドにdrag\&dropすることに
よって、セッション退席要求(710) がvc_am(711)に発行
される。

【００６５】vc_am(711)がユーザ退席要求(710) を受け
とると、セッション操作マネージャ(712) はセッション
情報からのユーザの削除要求(713) をvc\_sm(714) に発
行する(S1201) 。この削除要求(713) には、処理の対象
となるセッションのidとユーザ(702) のidが付加され
る。

【００６６】vc_sm(714)は削除要求(713) をうけとる
と、指定されたセッションの参加者情報から指定された
ユーザidを削除する。この時点でデータ上は、ユーザ(7
02) がセッションから削除されたことになる。すると、
セッションから削除されたユーザ(702) にとっては、セ
ッション内で利用していたサービス(717) は不要とな
る。そこで、vc_am(711)はvc_sm からユーザ情報削除処
理の終了の旨をつたえるリプライ(716) を受けとると(S
1202) 、次に利用中の全サービスの退席処理スクリプト
・ハンドラ(718) を起動する(S1203) 。

【００６７】退席処理スクリプト・ハンドラ(718) は、
ユーザ(702) のユーザ環境における、サービスの途中退
席処理を途中退席スクリプトの記述にしたがって実行す
る。ただし、ここでユーザ(702) がセッションに参加し
ていた唯一のユーザであった場合、退席処理スクリプト
・ハンドラ(718) は退席処理スクリプトではなく、サー
ビス終了処理スクリプトを解釈・実行する。

【００６８】これはこの時点でだれも、サービスを利用
する必要がなくなるためである。最後にvc_am(711)は、
ユーザ(702) を含むセッション内の全ユーザのvc_am(71
1,719, 720)に、ユーザ退席通知を発行すべく、Notifie
r(721) を起動する(S1204) 。

【００６９】起動されたNotifier(721) は、途中退席通
知(722, 723, 724) を発行する。途中退席通知(722, 72
3, 724) をうけとったvc_am のうち、退席対象ユーザ(7
02) のユーザ環境を管理するvc_am(719)はサービスを管
理するために起動されていたvc_tm(725)を終了する。ま
た、その他のvc_am(711, 720) では、退席したユーザの
ユーザ・アイコンをセッションのユーザ・リストから取
り除き、セッションからの退席処理が完了する。概要に
ついて説明したが、次にサービス・スクリプトによるサ
ービスの制御について説明する。まず、サービス・スク
リプトそのものについて説明する。

【００７０】本実施例では、サービスの起動/ 終了およ
びユーザの途中参加/ 途中退席に対応するスクリプト
は、 それぞれ <<サービス名>>.start <<サービス名>>.terminate <<サービス名>>.join <<サービス名>>.disjoin 例.TvPhone.start, TvPhone.terminate, TvPhone.join,
TvPhone.disjoin というファイルに記述される。また各ファイルに記述で
きるスクリプトの基本構文は以下のようになっている：
<<Waitフラグ>> << 実行ユーザ>> << プログラム>> <<
引数>> ... "Waitフラグ" は" プログラム" で指定されたプログラ
ムが終了するまで呼びだし側( すなわちスクリプト・ハ
ンドラ) を待機(wait)させるか否かをあらわすフラグで
ある。Waitフラグは以下の3 種類の値の1 つをとる: %%nowait # waitしない %%wait # waitする %%waitstatus # waitして、 <<プログラム>>の終了
時に指定されるexit値をチェックする。 その値が0 以
外の場合は、 スクリプトの実行をその場で中止する。

【００７１】”実行ユーザ" は" プログラム" で指定さ
れたプログラムをどのユーザの環境で実行するかを指定
する。 実行ユーザは以下の値の1 つをとる: %requser # 操作を要求したユーザ %startrequser # 会議を開始したユーザ %targetuser # 操作の対象となるユーザ(.start, .
terminate スクリプト内では使用できない。) %operateuser # 操作を実際に処理するユーザ( ツー
ルの起動, 終了では%requser, その他の場合では%targe
tuser を指定したのとおなじことになる。) %alluser # セッション内の全ユーザ username@hostname # ユーザ名とホスト名によるユーザ
の直接記述 "プログラム" および" 引数 ..." は起動されるべきプ
ログラムとその引数である。 アプリケーションそのも
のや、 前処理プログラム等をここで指定する。 また、
引数に対して以下ような値の指定が可能である： %sessionname # セッション名 %sessionid # セッション番号 %servicename # サービス名 %serviceid # サービス番号 %toolname # ツール名 %toolid # ツール番号 %username # ユーザ名(%operateuser と同じユー
ザとなる) %userid # ユーザ番号(%operateuser と同じユ
ーザとなる) %hostname # ホスト名(%operateuser が使用して
いるホスト) %userhost # %username と%hostname を'@' で連
結した文字列。(%operateuser と同じユーザとなる) では、上記の構文で記述されたサービス・スクリプトの
実行の様子を、図8 と図13を用いて説明する。

【００７２】図8 においてはvc_tm におけるサービス起
動の様子が示されている。ここでは、サービス起動の場
合について説明するが、サービスの終了, 途中参加, 途
中退席などの場合も同様にして実行される。また図13は
図8 におけるスクリプト・ハンドラ(818) の処理をフロ
ーチャートであらわしたものである。

【００７３】図8 において、図4 と同様に3 人のユーザ
(801, 802, 803) が、それぞれ端末(804, 805, 806) か
らワークステーション(807, 808, 809) 上でvc_am(810,
811, 812)を起動して、同一セッションに参加している
ものとする。セッションに参加しているので、各ユーザ
環境ではセッション内のサービスを管理・操作するvc_t
m(813, 814, 815)が起動されている。サービスの起動
は、図2 で説明したように、ユーザ(801) が端末(804)
上に表示されるサービス操作ウィンドウ上でサービス・
アイコンをクリックすることにより、サービス起動要求
(816) がvc_tm(813)に発行される。

【００７４】vc_tm(813)がサービス起動要求(816) を受
けとると、内部のサービス・マネージャ(817) が、起動
スクリプト・ハンドラ(818) を起動する。起動スクリプ
ト・ハンドラ(818) は、まずvc_sm(819)に起動スクリプ
ト取得要求(820) を発行する(S1301) 。この起動スクリ
プト取得要求(820) には、起動されるセッション, ユー
ザ, サービスのidが付加される。vc_sm(819)は起動スク
リプト取得要求(820)を受けとると、付加されているセ
ッション, ユーザ, サービスidで、サービス・スクリプ
ト中の%requser等の'%' で始まる特殊なwordをおきかえ
る。この置き換えは、単純な文字列の置き換えとして実
装されている。

【００７５】wordの置き換えが完了すると、サービス・
スクリプトは起動スクリプト取得要求(820) のリプライ
・メッセージ(821) に付加されて、スクリプト・ハンド
ラ(818) に送られる。スクリプト・ハンドラ(818) は起
動スクリプトをうけとると(S1302) 、まず起動スクリプ
トから先頭の行をとりだし(S1303) 、さらにとりだした
行から"Wait フラグ" と" 実行ユーザ" を抜き出す(S13
04) 。

【００７６】次に" 実行ユーザ"(ここでは仮に802 とす
る) で指定されたユーザの環境で動作しているvc_tm(こ
こでは814)の代理実行モジュール(822) に対してプログ
ラム起動要求(823) を発行して、"Wait フラグ" と" 実
行ユーザ" を抜き出したあとに残った" プログラム" を
起動させる。

【００７７】ここで、" 実行ユーザ" で指定されるユー
ザidからvc_tm の通信ポート番号は以下の式に従って導
き出すことができる。

【００７８】 vc_tm の通信ポート番号 = (0x100000 + ユーザid) 通常、この" プログラム" にはサービスの本体であるア
プリケーション自身か、あるいはアプリケーションを起
動させるためのコマンドが指定されるので、この時点
で、サービスは起動はほぼ完了する。ここで、"Wait フ
ラグ”が\%nowait以外なら、vc_tm(814)から" プログラ
ム" の終了が通知されるまで、ウエイトする(S1307) 。
さらに、"Wait フラグ" が%waitstatus なら、終了通知
に付加される終了ステータス値をしらべ(S1309) 、0 以
外(S1310) ならスクリプトの処理を中止する。以上の処
理を、起動スクリプトの全行について繰り返す(S1308)
。最後に、vc_tm(813)はNotifier(824) を起動し、セ
ッション中の全vc\_tm(814, 815)に、サービスに関する
変更があったことを通知して、サービスの起動処理は終
了する。以上の様にして本実施例では、セッションをユ
ーザの集まりとして定義する手段としてのvc\_amと、セ
ッションをサービスの集まりとして動作させる手段とし
てのvc\_tmを提供し、また、サービスの操作を指定する
手段をサービス・スクリプト情報という形で記述するこ
とを可能とし、セッションの操作をサービスの操作とし
て処理するスクリプト・ハンドラを提供した。さらに、
スクリプト・ハンドラの処理における、セッションやユ
ーザに関する情報を取得する手段としてのvc_sm と、ユ
ーザによるセッションの操作をシステム全体に伝播させ
る手段としてのNotifierを提供した。

【００７９】本実施例では本発明を適用することによ
り、セッション上の操作に対して、使用される個々のア
プリケーションにとって最も都合の良い処理を行わせる
ことが可能となる。また、サービスの操作指定を通常の
テキストファイルとして管理しているので、修正や変更
に特別な機構が不要である。

【００８０】（その他の実施例）第1 の実施例におい
て、会議管理システムにおける本発明の実施例について
のべたが、本発明の第2 の実施例として、非同期な共同
作業をサポートする共同作業支援システムについて説明
する。

【００８１】ここで非同期な共同作業とは、共同作業を
おこなう人物が、同時に作業をおこなうのではなく、各
ユーザが異なる時間帯に作業を行なうことを一定期間継
続し、最終的に1 つの共同作業としてまとめ挙げること
を可能にするシステムである。すなわち、実施例1 の
「共同作業」が、数人が同時に同じ場所に集まることに
よって成立する会議をサポートしているのに対し、実施
例2 の「共同作業」は郵便等を介した長期に渡る断続的
な、やりとりをサポートしたものである。

【００８２】また、モデル的には、共同作業そのものよ
り。共同作業の対象となるデータを「セッション」とし
てモデル化する。従って、実施例1 の「セッション」
が、サービスとよばれるアプリケーションの集まりとし
て実現されていたのに対して、本実施例における「セッ
ション」は、共同作業の対象となるデータ( 文書，画像
など）の集まりを扱うための単位として実現される。図
14は、本実施例の主要な構成を示す図である。図におい
て、パーソナル・コンピュータ( 以降単にマシンともよ
ぶ)(1401) は本実施例における処理の実行を行うCPU(14
02) と、本システムの基本ソフトウェアであるSessionM
anager(1410)とDesktopManager(1411)を保持する主記憶
(1403)を計算機バス(1405)で結合することにより構成さ
れている。

【００８３】また、本システムが動作するために必要な
共有データを保持するためのデータベース(1406)と、共
有されないが後述する処理に使用される永続データを保
持するためのハードディスク(1407)、およびユーザがシ
ステムの操作をおこなうためのユーザインタフェースを
提供する端末(1404)がマシン(1401)に結合されている。
ここで、データベース(1406)には、一般的なリレーショ
ナル・データベースやオブジェクト指向データベースな
ど、データの永続化と一貫性管理の機構をもっているも
のならどのようなものでも利用可能であり、実施例1 に
おけるvc\_smを流用して本実施例を実現することも可能
である。

【００８４】主記憶(1403)上で動作しているSessionMan
ager(1408)は、データベース(1406)を利用して、以下の
情報を管理する。

【００８５】セッション情報(1409) プロダクト情報(1410) セッション情報(1409)は、共同作業の対象となる文書等
のデータ( これをプロダクトとよぶ) のリストとその関
連情報( 変更履歴など) で構成される共有情報である。
セッション情報(1409)には、名前( セッション名) とid
番号( セッションid) が割り当てられる。このうち、セ
ッション名はセッションの生成時にユーザによって指定
される文字列であり、セッションidはセッションの生成
時にSessionManager(1408)によって割り当てられる0 以
上の整数である。セッションidとセッション名の対応関
係もセッション情報(1409)の一部として管理されてい
る。プロダクト情報(1410)はセッションを構成するプロ
ダクトに関する情報である。おもに、プロダクトの実体
の置かれている場所, 所有者や変更履歴, データの種類
等が管理されている。

【００８６】プロダクト情報(1410)もセッション情報(1
409)と同様な、プロダクト名とプロダクトidで管理され
ている。SessionManager(1408)は、実施例1 におけるvc
\_smとは異なり、ユーザごとに1 つずつ起動される。本
実施例での共有データの一貫性管理はデータベース(140
6)によって実現されており、そのかわりにSessionManag
er(1408)は変更通知モジュール(1416)を内部にもってい
る。

【００８７】これは本実施例においても．SessionManag
er(1408)上での共有情報の更新などの変化は関連する全
DesktopManagerに通知する必要があるためである。

【００８８】SessionManager(1408)と同様に主記憶(140
3)上で動作しているDesktopManager(1411)は、 ユーザ
からの要求に応じてセッションの操作をおこなう。Desk
topManager(1411)は内部的に以下のモジュールに分割さ
れている：

【００８９】- ユーザイベント・ハンドラ(1412) ユーザイベント・ハンドラ(1412)はユーザの行なった操
作を解釈し、他のモジュール操作のためのコマンドを発
行するモジュールである。本実施例におけるユーザイン
タフェースは、TCL スクリプト言語(TCLについては"Tcl
and the Tk Toolkit",John K. Ousterhout, Addison-W
esley, 1994. 参照のこと) によるコマンドインタプリ
タとして実現されており、ユーザイベント・ハンドラお
よび他のモジュールもTCL インタプリタを拡張すること
によって実装されている。このため、ユーザイベント・
ハンドラ(1412)が発行するコマンドもTCL で記述されて
いる。

【００９０】- スクリプト・エンジン(1413) ハードディスク(1407)内で管理されているハンドラ情報
(1417)には、ある適当なセッション中のプロダクト1 つ
1 つについて、それをどのように扱うべきかが記述され
ている。この記述を本実施例においてもスクリプトとよ
ぶ。スクリプトはTCL に若干のコマンドを追加したもの
を用いて記述する。スクリプト・エンジン(1413)は、こ
のハンドラ情報(1417)内のスクリプトを解釈、 実行する
インタプリタとして実現されている。本実施例でのスク
リプトは、TCL に以下の名前のオペレータの記述をハン
ドラ情報に追加することにより使用可能となる。

【００９１】checkin-service-<<プロダクト名>> checkout-service-<< プロダクト名>> 以下の例はプロダクト名"FigureOnSomething.ps"に対す
るスクリプトである。

【００９２】 checkin-service-FigureOnSomething.ps {} { global temp-dir; checkin-file-as "$temp-dir/FigureOnSomething.ps" \ FigureOnSomething.ps; } checkout-service-FigureOnSomething.ps {} { global temp-dir; checkout-file-as FigureOnSomething.ps \ "$temp-dir/FigureOnSomething.ps"; exec idraw "$temp-dir/FigureOnSomething.ps"; } 例にあるように、pre-defined コマンドとして checkout-file-as << プロダクト名>> << コピー場所>> checkin-file-as <<コピー場所>> << プロダクト名>> が用意されている。

【００９３】Checkout-file-asは、" プロダクト名" で
指定されるプロダクトをファイルとみなし" コピー場
所" にコピーする。checkout-file-asが実行されると、
次にcheckin-file-as が行なわれるまで、指定されたプ
ロダクトをチェック・アウトしたり変更することはでき
なくなる。checkin-file-as は逆に" コピー場所" にあ
るコピーを最新のプロダクトとして" プロダクト名" で
プロダクト情報に登録する。以降、" コピー場所" にあ
るデータがオリジナルのプロダクトとみなされる。chec
kout-file-as, checkin-file-as は例えばftp やNFS 等
のファイル転送ないしファイル共有機構を利用して実現
される。

【００９４】- プロダクト・ハンドラ(1415) プロダクト上でユーザが作業を行なう場合、ユーザは一
時的にプロダクトを占有してからなんらかの変更をおこ
なう。この占有をチェック・アウトとよぶ。また、逆に
1 度占有したプロダクトを解放することに対応する処理
をチェック・インとよぶ。チェック・イン, チェック・
アウトは個々のプロダクトごとに行なうことができる
が、プロダクトの集まりであるセッション単位でのチェ
ック・イン,チェック・アウトも可能である。プロダク
ト・ハンドラ(1415)は、チェック・アウト後からチェッ
ク・イン直前までの間、プロダクトの管理をおこなうモ
ジュールである。

【００９５】すなわち、チェック・アウトに伴うプロダ
クトのコピーとオリジナルの対応関係の管理をおこな
う。また、ハンドラ情報(1417)の管理もプロダクト・ハ
ンドラ(1415)によって行なわれている。図14においては
SessionManager(1410)とDesktopManager(1411)が同一マ
シン上に存在しているが、本システムにおいて、実施例
1 におけるvc_sm と同様に、SessionManager(1410)を他
のネットワーク結合された他のマシン上で動作させるこ
とも可能である。さて、本実施例における「セッショ
ン」では - セッションの生成 - セッションの削除 - セッションのチェック・イン - セッションのチェック・アウト - セッションへのプロダクトの追加 - セッションからのプロダクトの削除 という操作が可能である。以下、これらの操作の典型例
である - セッションの生成 - セッションのチェック・イン について説明する。

【００９６】（セッションの生成）ここでは本実施例に
おけるセッションの生成処理を図15と図17を用いて説明
する。図15はセッションの生成処理の流れを概念的に表
す図である。また、図17において、図17a はSessionMan
ager(1514)の処理をフローチャートで表したものであ
り、図17b はSessionManager(1515, 1516)の処理をフロ
ーチャートで表したものである。図15において、3 人の
ユーザ(1501, 1502, 1503)が、それぞれ端末(1504, 150
5,1506)からマシン(1507, 1508, 1509)上で作業をして
いる。このうち、現時点では2 人のユーザ(1501, 1502)
はDesktopManager(1510, 1511)を起動し、本システムを
利用できる状態になっているが、ユーザ(1503)はDeskto
pManager(1512)を起動していないものとする。ただし、
SessionManager(1514, 1515, 1516)は必ず各ユーザ環境
で動作しているものとする。

【００９７】ここで、ユーザ(1501)がセッションの生成
を要求したと仮定する。ここでユーザ(1501)が要求をだ
すためのユーザインタフェースは、実施例1 と同様なウ
ィンドウベースのGUI によっても実現可能であるが、こ
こでは文字端末ベースのテキスト・インタフェースにも
とづいており、ユーザ(1501)が、"CreateSession" とい
うコマンドをタイプすることによって、セッションの生
成要求(1513)がDesktopManager(1510)に発行される。

【００９８】このときセッション生成要求(1513)には、
CreateSession コマンドの引数として指定される、ユー
ザ名のリストが付加される。ここでは、図中の3 人のユ
ーザ(1501, 1502, 1503)が指定されているものとする。
セッション生成要求(1513)は、ユーザイベント・ハンド
ラ(1520)によって解釈され、以下の処理を実行させる。

【００９９】すなわち、まず、SessionManager(1514)に
セッション生成要求(1517)を発行する。セッション生成
要求(1517)には、新しく生成されるセッションのセッシ
ョン名とセッションを操作可能なユーザ( ここでは150
1, 1502, 1503) のユーザ名が付加される。SessionMana
ger(1514)は新しく生成されるセッションのセッションi
dを生成したのち(S17a01)、セッション情報をデータベ
ース(1518)上に生成する(S17a02)。ここで、新しいセッ
ションidはすでに生成されているセッション情報の最新
のものの( セッションid +1)で生成される。

【０１００】次にSessionManager(1514)内の変更通知モ
ジュール(1519)は、セッション生成がなされたことを、
ユーザ(1502, 1503)のユーザ環境で動作しているSessio
nManager(1515, 1516)に通知(1520, 1521)する(S17a0
3)。

【０１０１】各SessionManagerはユーザ環境でDesktopM
anagerが起動されているなら(S17b01)、セッション生成
通知をそのDesktopManagerに通知する(S17b02)。図15で
は、SessionManager(1515)とDesktopManager(1511)間で
このようなやりとりがおこなわれる。

【０１０２】また、SessionManager(1516)では、Deskto
pManager(1512)がまだ起動されていないので、通知(152
1)を記録しておきDesktopManager(1512)の起動後に通知
する(S17b03)。

【０１０３】（セッションのチェック・アウト）図16は
セッションのチェック・アウト処理について説明する図
である。また、図16におけるDesktopManagerの動作をフ
ローチャートで表したものが図18である。本実施例にお
けるスクリプトは、チェック・アウトおよびチェック・
インに対してのみ定義可能である。

【０１０４】図16において図15と同様に、3 人のユーザ
(1601, 1602, 1603)が、それぞれ端末(1604, 1605, 160
6)からマシン(1607, 1608, 1609)上で作業をしている。
このうち、2 人のユーザ(1601, 1602)はDesktopManager
(1610, 1611)を起動し、本システムを利用できる状態に
なっているが、ユーザ(1603)はDesktopManager(1612)を
起動していない。ただし、SessionManager(1614, 1615,
1616)は必ず各ユーザ環境で動作しているものとする。

【０１０５】ここで、ユーザ(1601)が"CheckoutSession
<< セッション名>>" というコマンドをタイプして、セ
ッションのチェック・アウト要求(1613)をDesktopManag
er(1610)に発行したとする。このとき、セッションのチ
ェック・アウト要求(1613)には、CheckoutSession コマ
ンドの引数として指定される、セッション名が付加され
る。要求(1613)は、ユーザイベント・ハンドラ(1632)に
よって解釈され、以下の処理をおこなわせる。すなわ
ち、まず、SessionManager(1614)にセッション・プロダ
クト取得要求(1619)を発行する(S1801) 。SessionManag
er(1614)はデータベース(1620)に、セッション名をキー
としてセッション情報(1621)の取得要求(1622)を送る。
次にデータベース(1620)のリプライ(1623)に付加されて
いるセッション情報をうけとると、それからプロダクト
名のリストをとりだし、セッション・プロダクト取得要
求(1619)のリプライ(1624)に付加して、DesktopManager
(1610)に送り返す。

【０１０６】DesktopManager(1610)はリプライを受けと
ると(S1802) 、リプライから付加されているプロダクト
名のリストをとりだす(S1803) 。次に、DesktopManager
(1610)内部のプロダクト・ハンドラ(1625)はうけとった
リスト中の先頭のプロダクト名を抜きだし(S1804) 、さ
らに、ハードディスク(1626)から対応するハンドラ情報
(1627)をとりだして(S1805) 、ハンドラ情報(1627)内の
スクリプト記述部分から以下のチェック・アウト処理記
述： checkout-service-<<プロダクト名>> をとりだし(S1086) 、スクリプト・エンジン(1628)に解
釈・実行させる(S1807)。プロダクト名リスト内のすべ
てのプロダクトについてS1804 からS1808 までの処理を
繰り返す(S1808) 。

【０１０７】上記の処理が全プロダクトについて完了す
ると、DesktopManager(1610)はSessionManager(1615)に
セッションの起動と同様な通知を依頼する(S1809) 。こ
の通知に対するSessionManagerの処理は図17b で示した
フローチャートにおけるセッション生成通知をチェック
・アウト通知で置換したものとなる。すなわち、Sessio
nManager(1615)内の変更通知モジュール(1629)は、セッ
ションのチェック・アウトがなされたことを、ユーザ(1
602, 1603)のユーザ環境で動作しているSessionManager
(1615, 1616)に通知(1630, 1631)する。そしてSessionM
anager(1615)とDesktopManager(1611)間は通知(1630)の
転送が行なわれ、また、SessionManager(1616)では、De
sktopManager(1612)がまだ起動されていないので、通知
(1631)を記録しておき、DesktopManager(1612)の起動後
に通知する。

【０１０８】以上の様に本実施例では、セッションをプ
ロダクトの集まりとして定義し、\noindent セッション
をプロダクトの処理プログラムの集まりとして動作させ
る手段としてのプロダクトハンドラと、セッションの操
作をプロダクトの操作として処理する手段としてのスク
リプト・エンジンを提供し、プロダクトの操作方式を指
定する手段をハンドラ情報という形で記述することを可
能とした。さらに、スクリプト・エンジンの処理におけ
る、セッションやユーザに関する情報を取得する手段と
してのSessionManagerと、ユーザによるセッションの操
作をシステム全体に伝播させる手段としての変更通知モ
ジュールを提供した。本実施例では本発明を適用するこ
とにより、ハンドラ情報がユーザごとに定義されるた
め、セッション上の操作に対して、参照される個々のプ
ロダクトをユーザにとって最も都合の良いアプリケーシ
ョンを用いて扱うことが可能となる。また、データを中
心にセッションを形成するのでセッションに参加するユ
ーザを意識することなく共同作業環境を提供することが
可能となる。

【０１０９】

【発明の効果】以上の様にして、共同作業をサポートす
るグループウェア・システムにおいて、・共同作業の単
位( セッション) を指定するの手段と ・上記指定されたセッションにおいて、ユーザがセッシ
ョン単位での操作を可能ならしめる手段を提供する。さ
らに、上記操作をセッションの構成要素に対する操作と
して記述する手段を提供し、その記述手段によって記述
されたセッション操作の解釈および実行手段を提供する
ことにより、 ・共同作業をコンピュータ上でサポートし、かつ共同作
業の運用形態の細部をユーザが意識することなく利用す
ることが可能となる。 ・共同作業上の処理を、その構成要素にとってもっとも
適した処理によって実現することができる。 ・共同作業の構成要素の動的な変更に柔軟に対応するこ
とが可能となる。

【図面の簡単な説明】

【図１】本発明の第１の実施例である会議管理システム
の構成図である。

【図２】第１の実施例におけるユーザインタフェースを
説明するための図である。

【図３】サービス操作インタフェース・プログラムの起
動時の処理を説明するための図である。

【図４】第１の実施例におけるセッション起動処理の流
れを説明するための図である。

【図５】第１の実施例におけるセッション終了処理の流
れを説明するための図である。

【図６】第１の実施例におけるセッション参加処理の流
れを説明するための図である。

【図７】第１の実施例におけるセッション退席処理の流
れを説明するための図である。

【図８】第１の実施例におけるサービス起動処理の流れ
を説明するための図である。

【図９】図４におけるセッション起動処理のフローチャ
ートである。

【図１０】図５におけるセッション終了処理のフローチ
ャートである。

【図１１】図６におけるセッション参加処理のフローチ
ャートである。

【図１２】図７におけるセッション退席処理のフローチ
ャートである。

【図１３】図８におけるサービス起動処理のフローチャ
ートである。

【図１４】本発明の第２の実施例である非同期型共同作
業支援システムの構成図である。

【図１５】第２の実施例におけるセッション生成処理の
流れを説明するための図である。

【図１６】第２の実施例におけるセッションのチェック
・アウト処理の流れを説明するための図である。

【図１７】図１５におけるＳｅｓｓｉｏｎＭａｎａｇｅ
ｒの処理をフローチャートで表した図である。

【図１８】図１６におけるＤｅｓｋｔｏｐＭａｎａｇｅ
ｒの処理をフローチャートで表した図であるである。

Claims (17)

【特許請求の範囲】
1. 【請求項１】 １台以上の処理装置によって構成される
   作業環境において共同作業を行なう処理システムであっ
   て、 共同作業の単位を指定する手段と上記共同作業単位の操
   作手段を有し、 上記操作を上記共同作業単位の構成要素に対する操作と
   して記述する手段と、 上記操作記述手段によって記述された操作の実行手段を
   有することを特徴とする処理システム。
2. 【請求項２】 前記実行手段は、 共同作業単位およびその利用者に関する情報を取得する
   手段と、 1 人のユーザの操作の結果をシステム全体に伝播させる
   ための通知手段を有することを特徴とする請求項１記載
   の処理システム。
3. 【請求項３】 任意の処理を他のユーザ環境で実行可能
   にする処理代行手段を有することを特徴とする請求項２
   項記載の処理システム。
4. 【請求項４】 上記共同作業の単位を、システムのユー
   ザと利用可能なアプリケーション・プログラムの集まり
   として指定することを特徴とする請求項１項記載の処理
   システム。
5. 【請求項５】 上記共同作業の単位を、共有される文書
   等のデータの集まりとして指定することを特徴とする請
   求項５項記載の処理システム。
6. 【請求項６】 共同作業単位の操作として、共同作業単
   位の起動, 終了, ユーザの追加, ユーザの削除, アプリ
   ケーション・プログラムの起動, アプリケーション・プ
   ログラムの終了のいずれかを含むことを特徴とする請求
   項４項記載の処理システム。
7. 【請求項７】 上記共同作業単位の操作を、グラフィカ
   ル・ユーザ・インタフェース上でのアイコンのドラッグ
   ・アンド・ドロップによってユーザが指定することを特
   徴とする請求項６項記載の処理システム。
8. 【請求項８】 共同作業単位の操作として、共同作業単
   位の生成, 削除, データの追加, データの削除, 共同作
   業単位の占有( チェック・アウト),共同作業単位の公開
   ( チェック・イン) を有することを特徴とする請求項５
   項記載の処理システム。
9. 【請求項９】 上記操作記述手段として、起動可能なコ
   マンド列を指定することを特徴とする請求項１項記載の
   処理システム。
10. 【請求項１０】 上記記述手段として、スクリプト言語
    を用いて記述することを特徴とする請求項１記載の処理
    システム。
11. 【請求項１１】 上記コマンド列に、コマンドを実行す
    べきユーザ環境を指定する情報を付加することを特徴と
    する請求項９項記載の処理システム。
12. 【請求項１２】 上記コマンド列に、コマンド終了前に
    次のコマンド実行を行うか否かを指定する情報を付加す
    ることを特徴とする請求項９項記載の処理システム。
13. 【請求項１３】 上記コマンド列に、コマンド終了後に
    そのコマンドの終了状態に基づき、次のコマンド実行を
    行うか否かを指定する情報を付加することを特徴とする
    請求項９項記載の処理システム。
14. 【請求項１４】 上記共同作業単位の操作に加え、上記
    共同作業単位の構成要素の状態に関する情報の追加、 新
    および参照手段を提供することを特徴とする請求項６項
    記載の処理システム。
15. 【請求項１５】 上記ユーザ環境指定に、抽象的なユー
    ザ名を指定することを特徴とする請求項１１項記載の処
    理システム。
16. 【請求項１６】 上記コマンド列の引数に、抽象的なユ
    ーザ名, セッション名, アプリケーション名を指定する
    ことを特徴とする請求項９項記載の処理システム。
17. 【請求項１７】 1 台以上の処理装置によって構成され
    る作業環境において共同作業を行なう処理システムにお
    ける処理装置であって、 共同作業の単位を指定する手段と上記共同作業単位の操
    作手段を有し、 上記操作を上記共同作業単位の構成要素に対する操作と
    して記述する手段と、 上記操作記述手段によって記述された操作の実行手段を
    有することを特徴とする処理装置。