JPH06119298A - 共同情報処理方法及び処理装置 - Google Patents

Abstract

(57)【要約】 【目的】共同情報処理システムにおいて共同実行アプリ
ケーションプログラム（ＡＰ）とローカルＡＰとのあい
だのデータ交換を容易にする。 【構成】各々ＡＰ４７、ウィンドウサーバ４２、ユーザ
制御部５０、サーバ情報テーブル４８、操作権制御部４
９を備えた複数の端末１０を通信ネットワーク２８を介
して接続し、１つのＡＰを前記各端末上で共通に処理す
る共同情報処理装置であって、ユーザ制御部５０が、対
話入力に基づいて、１つのＡＰ４７に入力可能な端末を
決定し、その結果をサーバ情報テーブル４８に記録し、
操作権制御部４９は、サーバ情報テーブル４８の記録に
基づいて、ＡＰ４７に対する入力を受付け、その結果を
他の各端末に配布するよう前記ウィンドウサーバ４２を
制御する。 【効果】複雑な操作を必要とせず、通常のカットアンド
ペースト操作によってローカルＡＰのデータを共同実行
ＡＰに取り込める。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、通信ネットワークを利
用して遠隔地に分散配置された計算機を利用して複数の
参加者が共同活動を行うことができるようにする共同情
報処理方式に関するものであり、特に共同活動と個人活
動との間で必要なデータを自由に交換できるようにする
共同情報処理方式に関する。

【０００２】

【従来の技術】複数のワークステーションを通信ネット
ワークで接続して共同作業を支援するシステムが開発さ
れている。このような類似システムとして、「 Ahuja,
S. R.Ensor and S. E. Lucco: A Comparison of Aplica
tion Sharing Mechanisms inReal−time Desktop confe
rencing Systems, Proc. of the ACM Conference onOf
fice Information Systems, april 25−27, 1990, Camb
ridge, Massachusetts.」がある。

【０００３】

【発明が解決しようとする課題】共同作業支援システム
ではグループでアプリケーションプログラム（ＡＰ）を
共同実行し、同じ画面を参照しながら作業を行うことが
できる。シングルユーザ用に作成されたＡＰを共同で実
行するためにはいくつかの方式がある。アプリケーショ
ンプログラムを１つのワークステーションに配置し、そ
のリクエストメッセージを複数のウィンドウサーバに同
報し、逆に複数のワークステーションからの入力を該ア
プリケーションに集中する方式もそのひとつである。こ
の方式を集中実行方式という。集中実行方式では、実際
にＡＰが実行されるワークステーション（これを親サイ
トと呼ぶ）と、ＡＰの出力結果である画面表示だけを見
ているワークステーション（これを子サイトと呼ぶ）と
がある。

【０００４】共同作業支援システムでは、共同実行ＡＰ
と同時に、共同作業とは関係なく個人的に利用する個人
ＡＰも利用できる。たとえば、ある資料を共同で編集し
ているときに、参加者の一人が自分だけに必要な資料を
自分のワークステーションでだけ実行することができ
る。このような個人ＡＰをローカルＡＰと呼ぶ。さら
に、このようなローカルＡＰと共同実行ＡＰと間でデー
タのやりとりを行いたい場合がある。

【０００５】ところが、集中実行方式でＡＰを共同実行
している場合、子サイトでのカットアンドペーストがう
まく行かない場合がある。ここで、カットアンドペース
トとは、あるＡＰでデータをとりだして共通領域に格納
し、他のＡＰで該共通領域からデータをとりだす一連の
操作のことを言う。

【０００６】集中実行方式の子サイトで、ローカルＡＰ
でカットしたデータを共同実行ＡＰにペーストしようと
すると、参加者の期待に反した結果が得られる場合があ
る。すなわち、ローカルＡＰでカットされたデータは、
子サイトの共通領域に格納されるが、共通ＡＰのペース
ト操作では、親サイトの共通領域からデータが取り出さ
れるためである。この結果、共同実行ＡＰには親サイト
の共通領域に格納されていたデータがペースとされるこ
とになり、子サイトの利用者は期待に反する結果を得る
ことになる。なお、親サイトではこのような問題は起こ
らない。

【０００７】本発明は、このようなカットアンドペース
トにおける不都合を解決することを目的とする。

【０００８】

【課題を解決する手段】本発明は、各々ウィンドウサー
バと、入力部及び出力部を備えた複数の端末を通信ネッ
トワークを介して接続し、１つのアプリケーションプロ
グラムを各ワークステーション（端末）上で共通に処理
する共同情報処理装置であって、少なくとも１つの端末
が、ユーザ制御部とサーバ情報テーブルと操作権制御部
とを備え、ユーザ制御部が、対話入力に基づいて、１つ
のアプリケーションプログラムに入力可能なワークステ
ーションを決定し、その結果をサーバ情報テーブルに記
録し、操作権制御部は、サーバ情報テーブルの記録に基
づいて、前記１つのアプリケーションプログラムに対す
る入力を受付け、その結果を各ワークステーションに配
布するよう前記ウィンドウサーバを制御することを特徴
とする。

【０００９】

【作用】ＡＰ共同実行中に親サイトを動的に変更するこ
とが可能となる。従って、子サイトで共同実行ＡＰでの
ペーストを実行するときは、まずユーザ制御部を介して
そのワークステーションを親サイトに変更する。集中実
行方式ではリクエストを複数のワークステーションに同
報し、複数ワークステーションからの入力をＡＰに集中
する。また、いくつかのリクエストはワークステーショ
ンへの問い合わせのためのものであり、それらのリクエ
ストが発行されるとリプライと呼ばれるデータが返送さ
れる。このようなリクエストを往復リクエストという。
親サイトからのリプライはＡＰに渡されるが、子サイト
からのリプライは制御プログラムによって破棄される。
これは、ＡＰはもともとシングルユーザ用に作成された
ものなので１つのリクエストに対して複数のリプライを
返されると対処できないからである。逆にいうと、往復
リクエストに対するリプライを受け取るワークステーシ
ョンが親サイトであり、受け取らないワークステーショ
ンが子サイトであるということもできる。このようにし
て、親サイトでのカットアンドペーストは問題なく行わ
れるため、利用者は期待どおりの結果を得ることにな
る。

【００１０】

【実施例】以下、本発明の一実施例である電子対話シス
テムについて説明する。図１は本実施例を適用する電子
対話システムの外観を示す図である。この例では３つの
ワークステーション１０（１０−Ａ，１０−Ｂ，１０−
Ｃ）が通信路２６、ネットワーク２８で接続されてい
る。各ワークステーションには電話機２４が備えられ、
会議における音声による意思疎通を支援する。図１で
は，電話２３もワークステーション１０も同一のネット
ワーク２８に接続されているが、電話２３はワークステ
ーション１０とは別のネットワークに接続されていても
構わない。

【００１１】例えば、複数の機器を同一の回線で接続で
きるＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅ
ｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）では、１つの回
線で電話による音声通話と、ワークステーション間のデ
ィジタルデータ通信を同時に行うことができて便利であ
る。一方企業内などでは、データ通信はＬＡＮ（Ｌｏｃ
ａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）によって行い、電話
による音声通話は専用線を使うようにしてもよい。電話
機２３自体についても、本実施例のような通常電話だけ
でなく、受話器を持たないで離せるハンズフリー電話
や、電話会議用のエコーキャンセラ内蔵の専用電話機を
用いることももちろん可能である。

【００１２】本実施例のように接続されるワークステー
ションは同一機種である必要はなく、ある一定の条件を
満たしていれば異なる機種、あるいは異なるメーカのワ
ークステーションであってもよい。各ワークステーショ
ンには、キーボード２１、マウス２２などの入力機器２
０、ＣＲＴディスプレイ４０などの表示機器が接続され
ている。入力機器としては、タブレット、タッチパネ
ル、タッチペンなど他の機器も使用可能である。これら
ネットワーク２８で接続されたワークステーション１０
上では、同一のアプリケーションプログラムを複数の参
加者で共同実行することができる。

【００１３】図２は、本発明の電子対話システムの構成
例を機能的に表現したものである。ワークステーション
１０−Ａ、１０−Ｂ、は各々ウィンドウサーバ４２、ア
プリケーションプログラム４７、サーバ情報テーブル４
８、操作権制御部４９及びユーザ制御部５０を備えてい
る。また、ワークステーション１０−Ｃはウィンドウサ
ーバ４２とサーバ情報テーブル４８を備えている。ユー
ザ制御部５０は、複数のワークステーション上で共通に
実行されるアプリケーションプログラムの親となる親サ
イト、換言すると操作権を持つワークステーションを会
議参加者の操作によって決定し、動的に切り替えるもの
である。ここで操作権とは、共同作業中の資料を操作す
る権利のことを言う。どの参加者が操作権を有するか
は、サーバ情報テーブル４８に記録され、更新される。
操作権制御部４９は、ユーザ制御部５０で決定されサー
バ情報テーブル４８に記録された操作権に従って共同で
実行されるアプリケーションプログラム（ＡＰ）４７の
処理操作を制御する。

【００１４】図３にディスプレイ４０−Ａ、４０−Ｂの
画面の一例を示す。それぞれのディスプレイ４０−Ａ、
４０−Ｂの画面の上には会議室ウィンドウ８０−Ａ、８
０−Ｂが表示されている。画面上には会議室ウィンドウ
８０しか表示できないわけではなく、会議とは無関係な
さまざまなウィンドウやアイコンを表示できる。例えば
参加者Ａの画面上に電話アイコン１３０が表示されてお
り、そのほか、会議室ウィンドウ８０−Ａ、８０−Ｂ内
にはいくつかのアイコン（１００、１１０、１２０等）
が表示されている。これらのアイコンは資料を示すもの
であるが、それぞれのアイコンには資料を表示したり編
集するためのＡＰを示すデータが付与されているので、
これらのアイコンを操作するだけで必要なＡＰを起動す
ることができるようになっている。このため、以下の説
明ではＡＰのことを資料と言う場合もある。

【００１５】画面上の矢印１４０−Ａ、１４０−Ｂはマ
ウスポインタであり、マウス２２を操作することにより
画面上を動かすことができる。以下、画面上の操作は、
各利用者がマウス２２およびキーボード２１で必要な操
作を行うことによって進められる。図３の例は、２つの
会議室が接続され、アプリケーションプログラムとして
の報告書１００を共同実行しているものであり、参加者
Ａが報告書ウィンドウ２５０−Ａに名前を記入している
状態を示している。参加者Ａの報告書ウィンドウ２５０
−Ａの右上にある操作権表示ウィンドウ２４０−Ａが網
かけになっており、参加者Ａが操作権を持っていること
を示している。参加者Ｂの操作権表示ウィンドウ２４０
−Ｂは白い状態であり、操作権を持っていないことを示
し参加者Ｂは文字入力をすることができない。

【００１６】操作権制御部４９及びユーザ制御部５０
は、汎用タイプのＣＰＵとプログラムの組合せによって
実現することもできるし、あるいは、専用のハードウェ
アによって構成することもできる。ここでは前者の例に
ついて詳細に説明する。

【００１７】図４はワークステーション１０のハードウ
エア構成例を示す。ここでは接続されている３つのワー
クステーションのうちの１つであるワークステーション
１０−Ａについて説明するが、特に断らないかぎり他の
２つのワークステーションも同様の構成をとっている。
メインメモリ４００には、オペレーティングシステム４
１０、ウィンドウサーバプログラム４２０、電子対話制
御プログラム４３０（以下、単に制御プログラムとい
う）が保持されている。

【００１８】オペレーティングシステム４１０は、ワー
クステーション１０のもつすべてのハードウエアを制御
し、ＡＰがハードウエアを効率よく使用できるようにす
るためのプログラムである。オペレーティングシステム
４１０はメインメモリ４００上にデータ４１５を保持し
ている。

【００１９】ウィンドウサーバプログラム４２０は、ウ
ィンドウサーバ４２の機能を実現するものであり、キー
ボード２１やマウス２２などの入力機器２０、およびデ
ィスプレイ４０などの出力機器を制御するプログラムで
ある。ウィンドウサーバプログラム４２０は、他の複数
のプログラムと通信し、他のプログラムからの要求を受
けてディスプレイ４０へ図形・文字を描画したり、入力
機器からの入力を他のプログラムに伝える。ウィンドウ
サーバプログラム４２０はメインメモリ４００上にデー
タ４２５を保持している。

【００２０】制御プログラム４３０は、本発明の電子対
話システムを実現するための中心的役割を果たすプログ
ラムである。制御プログラム４３０はメインメモリ４３
０上にデータ４３５を保持している。この制御プログラ
ム４３０は、オペレーティングシステム４１０、ウィン
ドウサーバプログラム４２０とは異なり、接続されてい
るワークステーションのうちの１つのワークステーショ
ン上にだけあればよい。この例ではワークステーション
１０−Ａに制御プログラムが配置されている。他のワー
クステーション１０−Ｂ，１０−Ｃには制御プログラム
は必要ない。

【００２１】ワークステーション１０は通信インタフェ
ース３９０を介して通信ネットワーク２８に接続されて
いる。通信インタフェース３９０は、他のプログラムか
らの要求によりデータを通信ネットワーク２８を通じて
他のワークステーション１０−Ｂ、１０−Ｃに送信した
り、他のワークステーション１０−Ｂ、１０−Ｃから通
信ネットワーク２８を通じてデータを受取り、プログラ
ムに伝えたりする。

【００２２】ワークステーション１０にはメインメモリ
４００のほかに２次的な記憶装置としてハードディスク
４６０が備えられている。ただし、２次的な記憶装置と
してはこの例のようにハードディスク４６０だけに限定
されるのではなく、光磁気ディスク、半導体ディスク、
フロッピディスクなどの他の媒体を利用することももち
ろん可能である。

【００２３】ハードディスク４６０中にはさまざまなプ
ログラムやデータが格納されている。この中にはオペレ
ーティングシステム４１０やウィンドウサーバプログラ
ム４２０等も含まれる。これらのプログラムやデータ
は，ディスクコントローラ４５０を通じてメインメモリ
４００中にロードされ、ＣＰＵ４４０によって実行され
る。逆に、プログラムはディスクコントローラ４５０を
通じてディスク４６０中にデータを書き込むことができ
る。

【００２４】マウス２２はマウスコントローラ３５０に
よって，キーボード２１はキーボードコントローラ３６
０によって制御される。ディスプレイ４０への出力はフ
レームメモリ３７０に対する書き込みによって行われ
る。ディスプレイコントローラ３８０はフレームメモリ
３７０の内容を定期的に読みだしては、ディスプレイ４
０に表示している。

【００２５】図５は、図４のウィンドウサーバプログラ
ム４２０と制御プログラム４３０とＡＰ４７０との関係
を示している。図４ではＡＰ４７０と制御プログラム４
３０がワークステーション１０−Ａに配置されている。
これはもっとも一般的な配置である。

【００２６】図６では制御プログラム４２０とＡＰ４７
０がそれぞれワークステーション１０−Ａ、ワークステ
ーション１０−Ｂに配置されている。この場合は、ＡＰ
４７０はワークステーションＢで実行され、通信ネット
ワーク２８を通じてワークステーション１０−ＡＡで動
作している制御プログラム４３０との間でメッセージを
送受信する。このようにＡＰ４７０と制御プログラム４
３０の配置にはとくに制限はない。各プログラムの間で
通信ができればよいのである。

【００２７】次に、制御プログラム４３０を詳細に説明
する。図７は制御プログラム４３０の内部構成を示すも
のであり、サーバインタフェース部４８０、操作権制御
部４９０、ＵＩ（ユーザインタフェース）制御部５０
０、サーバ情報テーブル８３０を備えており、さらに、
リクエスト変換部５１０、入力変換部５２０、ＡＰイン
タフェース部５３０を備えている。この図では会議に参
加しているワークステーションが３つで、会議で共同実
行しているＡＰが１つの場合を示している。本実施例の
電子対話システムでは、複数のＡＰを同時に共同実行す
ることができるので、その場合には図７における矢印は
複数のＡＰごとにあることになる。

【００２８】制御プログラム４３０の各部の詳細を説明
する前に、本実施例の電子対話システムで使用するメッ
セージについて説明しておく。図８はリクエストメッセ
ージ５４０である。このリクエストメッセージ５４０
は、ＡＰがウィンドウサーバプログラムに対して発行す
るメッセージであり、その先頭にはリクエストメッセー
ジ種別５４５が格納されている。続いてリクエストの対
象となるウィンドウを表すウィンドウ識別子５５０が格
納されている。残りの部分にはその他リクエストに必要
なデータ５５５が格納される。

【００２９】図９は入力メッセージ５６０である。入力
メッセージ５６０は入力装置からの入力に対応してウィ
ンドウサーバプログラムがＡＰに送信するメッセージで
ある。入力メッセージ５６０の先頭にはメッセージ種別
５６５が格納されている。続いて入力が行われたウィン
ドウを表すウィンドウ識別子５７０が格納されており、
残りの部分にはその他入力メッセージに必要なデータ５
７５が格納される。

【００３０】図１０はリプライメッセージ５８０であ
る。このリプライメッセージ５８０は、リクエストメッ
セージの中でウィンドウサーバからの応答を必要とする
もの、たとえばウィンドウの属性を問い合わせるリクエ
ストメッセージなどに対応してウィンドウサーバプログ
ラムがＡＰに送るメッセージである。従って、リプライ
メッセージは応答を必要とするリクエストメッセージ１
個に対して１個だけＡＰに送られるものである。そこ
で、本システムでは親サイトであるワークステーション
からのリプライメッセージのみをＡＰに伝え、他の子サ
イトからのリプライメッセージは制御プログラムが破棄
する。さらに本システムではこの親サイトをＡＰ共同実
行中に動的に変更することができる。リプライメッセー
ジ５８０の先頭にはメッセージ種別５８５が格納されて
いる。続いてリプライの対象となるウィンドウのウィン
ドウ識別子５９０が格納されている。リプライメッセー
ジの残りの部分には、その他リプライメッセージに必要
なデータ５９５が格納される。

【００３１】次に、図７に示される制御プログラムの各
モジュールについて説明する。まず、サーバインタフェ
ース部４８０は複数のウィンドウサーバプログラム４２
０との通信を行う。この複数のウィンドウサーバプログ
ラム４２０は複数のワークステーション１０上で動作し
ているものである。

【００３２】サーバインタフェース部４８０の処理の流
れは図１１のようになる。サーバインタフェース部４８
０はステップ６０５の繰り返しを行う。まずリクエスト
変換部５１０からのデータがあるかどうかを調べる（ス
テップ６１０）。もしリクエスト変換部５１０からのデ
ータがあった場合にはリクエスト変換部５１０からリク
エストメッセージ５４０を受信し（ステップ６１５）、
ウィンドウサーバ４２０に送信する（ステップ６２
０）。

【００３３】次に、参加者のウィンドウサーバ４２０の
数だけステップ６２５を繰り返す。ウィンドウサーバ４
２０からのデータがあるかどうかを調べる（ステップ６
３０）。もしウィンドウサーバ４２０からのデータがあ
った場合にはウィンドウサーバ４２０から入力メッセー
ジ５６０を受信し（ステップ６３５）、操作権制御部４
９０へ送信する（ステップ６４０）。

【００３４】次に、ＵＩ制御部５００からのデータがあ
るかどうかを調べる（ステップ６４５）。もし、ＵＩ制
御部５００からのデータがあった場合ににはＵＩ制御部
５００からリクエストメッセージ５４０を受信し（ステ
ップ６５０）、ウィンドウサーバ４２０へ送信する（ス
テップ６５５）。

【００３５】次に、ウィンドウサーバ４２０からＵＩ制
御部５００へのデータがあるかどうかを調べる（ステッ
プ６６０）。もし、ウィンドウサーバ４２０からＵＩ制
御部５００へのデータがあった場合にはウィンドウサー
バ４２０から入力メッセージ５６０を受信し（ステップ
６６５）、ＵＩ制御部５００へ送信する（ステップ６７
０）。

【００３６】ＡＰインタフェース部５３０は複数の共同
実行ＡＰ４７０との通信を行う。ＡＰインタフェース部
５３０の処理の流れは図１２のようになる。ＡＰインタ
フェース部５３０はステップ７６０を繰り返す。まず入
力変換部５２０からのデータがあるかどうかを調べる
（ステップ７６５）。もしデータがあった場合には、入
力変換部５２０から入力メッセージ５６０を受信し（ス
テップ７７０）、ＡＰ４７０に送信する（ステップ７７
５）。次にＡＰ４７０からのデータがあるかどうかを調
べる（ステップ７８０）。もし、データがあった場合に
はＡＰ４７０からリクエストメッセージ５４０を受信し
（ステップ７８５）、リクエスト変換部５１０へ送信す
る（ステップ７９０）。

【００３７】次に、操作権制御部４９０は、複数のウィ
ンドウサーバ４２０からの入力メッセージ５６０を受信
し、選択して入力変換部５２０に伝達する。この操作権
制御部４９０は図２の操作権制御部４９の機能を実現す
るものであり、その処理の流れは図１３のようになる。
操作権制御部４９０は、ステップ８０５を繰り返す。ま
ず、サーバインタフェース部４８０から入力メッセージ
５６０を受信する（ステップ８１０）。次に図１４に示
すサーバ情報テーブル８３０を検索する（ステップ８１
５）。そこで検索した結果から、入力メッセージが操作
権を持つ参加者からのものかどうかを調べる（ステップ
８２０）。もし入力メッセージ５６０が操作権を持つ参
加者からのものだった場合にはメッセージを入力変換部
５２０へ送信する（ステップ８２５）。

【００３８】図１４はサーバ情報テーブル８３０の詳細
を示す。サーバ情報テーブル８３０は制御プログラム４
３０が管理している情報であり、制御プログラム４３０
が管理している各ウィンドウサーバ４２０に関する情報
を保持している。管理している情報はウィンドウサーバ
プログラム４２０が動作しているワークステーションの
アドレス８３５、ワークステーションの操作権８４０
（操作権を持つ場合は１、それ以外の場合は０とな
る）、ワークステーションの親サイトフラグ８４５（親
サイトなら１、それ以外なら０となる）、その他サーバ
情報８５０である。制御プログラム４３０は同時に複数
のＡＰを共同実行できるため、サーバ情報テーブル８３
０もＡＰの数だけある。

【００３９】図１４の例では、共同実行しているＡＰが
Ｌ個あり、そのうちテーブル８３０−１で管理されてい
るＡＰの操作権はウィンドウサーバ１が動作しているワ
ークステーションにある。

【００４０】図７に戻って、ＵＩ制御部５００は操作権
の変更操作等を制御する。すなわち、図２のユーザ制御
部５０の機能を実現するものであり、操作権表示ウィン
ドウ２４０を表示したり、操作権表示ウィンドウ２４０
からの入力に応じてサーバ情報テーブル８３０の操作権
情報の記録を変更したりする。

【００４１】ＵＩ制御部５００の処理の流れは図１５の
ようになる。ＵＩ制御部５００はステップ８６５を繰り
返す。まずサーバインタフェース部４８０からのメッセ
ージを受信する（ステップ８７０）。受信したメッセー
ジが操作権表示ウィンドウ２４０への入力かどうかを調
べる（ステップ８７５）。もし受信したメッセージが操
作権表示ウィンドウ２４０への入力だった場合には、操
作権を持つ参加者の操作権表示ウィンドウ２４０の網か
け表示を解除し（ステップ８８０）、入力があった参加
者の操作権表示ウィンドウ２４０を網かけ表示し（ステ
ップ８８５）、入力があった参加者に操作権（親サイ
ト）を移動するようにサーバ情報テーブル８３０を更新
する（ステップ８９０）。なお、操作権表示ウィンドウ
２４０の表示変更等はサーバインタフェース部４８０へ
リクエストメッセージ５４０を発行することによって実
現する。また、サーバ情報テーブル８３０の記録を更新
することにより、操作権制御部４９０を制御する。

【００４２】本実施例では、操作権表示ウィンドウ２４
０に対する明示的な操作によって操作権を移動させてい
るが、共同実行ＡＰへの入力により、自動的に操作権を
移動させることもできる。この場合、ＵＩ制御部５００
の処理においては、共同実行ＡＰへの入力があった場合
に、入力を行った参加者に操作権を与えるようにサーバ
情報テーブル８３０を更新する。

【００４３】入力変換部５２０は入力メッセージ５６０
をＡＰ４７０に伝達する前に入力メッセージ５６０中に
含まれるウィンドウ識別子５７０を変換する。複数のワ
ークステーション１０に表示されるウィンドウはそれぞ
れのワークステーションのウィンドウサーバ４２０によ
って管理されているため、同じ対応するウィンドウどう
しでもワークステーション１０によってウィンドウ識別
子が異なる。したがって、入力メッセージ５６０中のウ
ィンドウ識別子５７０も各ワークステーション１０での
値になっている。これを変換するのが入力変換部５２０
である。

【００４４】入力変換部５２０の処理の流れは図１６の
ようになる。入力変換部５２０はステップ９０５を繰り
返す。まず操作権制御部４９０から入力メッセージ５６
０を受信する（ステップ９１０）。次に入力メッセージ
５６０からウィンドウ識別子５７０を取り出し（ステッ
プ９１５）、図１７に示すウィンドウ識別子テーブル９
４０を検索し（ステップ９２０）、検索結果に基づいて
入力メッセージ５６０中のウィンドウ識別子５７０を変
換し（ステップ９２５）、変換後の入力メッセージ５６
０をＡＰインタフェース部５３０へ送信する（ステップ
９３０）。

【００４５】図１７にウィンドウ識別子テーブル９４０
の詳細を示す。ウィンドウ識別子テーブル９４０は制御
プログラム４３０が管理している情報であり、ウィンド
ウ識別子に関する情報を管理している。ＡＰ４７０は複
数のウィンドウを作成するが、同じウィンドウでもウィ
ンドウサーバプログラム４２０によって異なるウィンド
ウ識別子を持つ。ウィンドウ識別子テーブルはこの対応
関係を保持している。例えばテーブル９４０−１によっ
て管理されている共同実行ＡＰが作成したウィンドウの
ウィンドウサーバごとのウィンドウ識別子は、ウィンド
ウ識別子テーブル９４０の第１行９５０−１を見ればわ
かる。図１７ではこのようにして共同実行ＡＰが作成す
るＭ個のウィンドウに関する情報が格納されている。ウ
ィンドウの個数はＡＰによって異なるので、ウィンドウ
識別子テーブル９４０の大きさもそれに応じて変化す
る。また、制御プログラム４３０は同時に複数のＡＰを
共同実行できるため、ウィンドウ識別子テーブルもＡＰ
の数（図１７ではＬ個）だけある。

【００４６】リクエスト変換部５１０（図７）はＡＰ４
７０が発行したリクエストメッセージ５４０を複数のウ
ィンドウサーバ４２０に送るために分配するとともに、
リクエストメッセージ５４０中のウィンドウ識別子５５
０を変換する。ＡＰ４７０が発行した１つのリクエスト
メッセージ５４０をリクエスト変換部５１０が複数のウ
ィンドウサーバプログラム４２０に分配することによ
り、複数のワークステーション１０での表示が可能にな
る。

【００４７】リクエスト変換部５１０の処理の流れは図
１８のようになる。リクエスト変換部５１０はステップ
１００５を繰り返す。まずＡＰインタフェース部５３０
からリクエストメッセージ５４０を受信する（ステップ
１０１０）。次に参加者のウィンドウサーバ４２０の数
だけステップ１０１５を繰り返す。リクエストメッセー
ジ５４０中のウィンドウ識別子５５０を取り出し（ステ
ップ１０２０）、図１７のウィンドウ識別子テーブル９
４０を検索し（ステップ１０２５）、検索結果に基づい
てリクエストメッセージ５４０中のウィンドウ識別子５
５０を変換し（ステップ１０３０）、変換後のリクエス
トメッセージ５４０をサーバインタフェース部４８０に
送信する（ステップ１０３５）。

【００４８】図１９は２つの会議室を接続して共同作業
を開始する操作を示す。共同作業を開始するためには参
加者の会議室どうしを接続する必要がある。会議室を接
続するには、一方の参加者が「参加希望」を表明し、他
方の参加者が「参加者指定」を行う必要がある。この操
作は、どちらが行ってもよいのである。すなわち、参加
者Ａが参加希望を行ってもよいし、参加者Ｂが参加希望
を行ってもよい。

【００４９】いずれの操作を行う場合にもまず、会議室
ウィンドウ８０内のファイルボタン９０にマウスポイン
タ１４０を移動し、マウスボタンを押すことによりプル
ダウンメニュ−を表示させる。プルダウンメニュ−の中
には会議の開始終了に関係するいくつかのメニュー項目
が表示されている。ここでは、参加者Ａは「参加者指
定」を選択し、参加者Ｂは「参加希望」を選択する。参
加者Ａが参加者指定を選択すると、参加者Ａの画面４０
−Ａに参加者指定ウィンドウが表示される。参加者指定
ウィンドウには、予め登録された参加者リストが表示さ
れている。ここで接続する相手を指定し、接続ボタンの
上でマウスボタンを押すことにより、接続操作が完了す
る。

【００５０】以上の操作によって、参加者Ａと参加者Ｂ
の会議室の接続が完了する。会議室どうしが接続される
と図のように会議室ウィンドウ８０−Ａ、８０−Ｂ上に
接続中を示す文字２２０−Ａ、２２０−Ｂが表示され
る。この時点で参加者Ａと参加者Ｂによる会議が開始さ
れたことになる。

【００５１】会議室が接続されると、会議室ウィンドウ
８０上の資料を会議参加者の間で共同利用できる。次に
ＡＰの共同実行の操作方法を説明する。参加者Ａが自分
の持つ資料である報告書１００を開く場合には、その資
料を示すアイコンの上にマウスポインタ１４０を移動さ
せ、マウスボタンを押す。すると、図２０のようなポッ
プアップメニュ−２３０がマウスポインタの位置に表示
される。これはその資料に対する実行可能な操作を示す
ものである。ここでは、報告書１００を共同実行したい
のであるから、メニュ−２３０−Ａの共同実行２３２−
Ａを選択する。後で述べるように、資料を個人的に利用
する場合には個人利用２３４−Ａを選択する。

【００５２】図２０で共同実行２３２−Ａを選択して報
告書が開かれたところを示すのが図２１である。このよ
うに資料を持つ参加者が操作を行うだけで全会議参加者
の画面に同じ資料が表示される。参加者Ａの会議室ウィ
ンドウ８０−Ａ上では、報告書が使用中であることを示
すために報告書アイコン１００が網かけで表示されてい
る。

【００５３】この例では参加者Ａは資料を操作する権利
を持っている。参加者Ｂは資料を操作する権利を持って
いない。ある資料に対する操作権の有無は資料ウィンド
ウ２５０の右上の操作権表示ウィンドウ２４０によって
示される。この例では、参加者Ａの報告書ウィンドウ２
５０−Ａの右上の操作権表示ウィンドウ２４０−Ａが網
かけになっていることで操作権を持っていることがわか
る。

【００５４】なお、本実施例では操作権を持っている参
加者のワークステーションは、親サイトになっている。
操作権が移動すると親サイトは操作権を持つワークステ
ーションに移動する。会議で共同利用されているＡＰに
入力を行うと、結果は全参加者の画面に反映される。参
加者Ｂは操作権を持たないので文字入力を行うことはで
きない。この文字入力機能はＡＰが本来持っている機能
を共同実行していることになる。

【００５５】参加者Ｂが入力を行うためには、まず操作
権を取得する必要がある。図２２は参加者Ｂが操作権を
取得しようとしているところを示している。操作権を取
得するには、操作権を取得したい資料のウィンドウ２５
０−Ｂの右上に表示されている操作権表示ウィンドウ２
４０−Ｂにマウスポインタ１４０−Ｂを置き、マウスボ
タンを押す。この操作によって参加者Ｂが操作権を取得
すると参加者Ａの操作権表示ウィンドウ２４０−Ａは無
地に戻り、参加者Ｂの操作権表示ウィンドウ２４０−Ｂ
が網かけ表示になる。

【００５６】図２３は操作権を取得した参加者Ｂが入力
を行っているところである。参加者Ｂが操作権を取得し
たので、この時点では参加者Ｂのワークステーションが
自動的に親サイトになっている。参加者Ｂが操作権を持
っているので、参加者Ａは資料に入力することはできな
い。

【００５７】以上の説明のとおり本実施例では、共同実
行ＡＰに対する入力は操作権を持つワークステーション
からのみ可能である。しかし、このような操作権を必ず
設ける必要があるわけではない。すなわち、共同実行Ａ
Ｐには参加者全員が好きな時に入力ができるようにして
もよい。そして、ここまでの説明で用いた操作権表示ウ
ィンドウは、単に親サイトの変更のための手段であると
してもよい。

【００５８】あるいは、操作権は設けるが操作権の移動
を自動化することもできる。その場合には、最初に入力
を行った参加者が操作権を取得するようにする。そし
て、操作権を持つ参加者が入力を続けているかぎり、操
作権を保持し続ける。操作権を持つ参加者がある一定時
間入力を行わないと、次に初めて入力を行った参加者の
もとに自動的に操作権が移動するようにすればよい。い
ずれにしても本実施例では、操作権は参加者が操作権表
示ウィンドウを操作することによって明示的に取得する
方式を取っている。

【００５９】次に、メッセージの流れから見たシステム
の動作を説明する。図２４はリクエストメッセージの流
れを示している。左側が参加者Ａのワークステーション
１０−Ａ、右側が参加者Ｂのワークステーション１０−
Ｂを示している。リクエストメッセージ５４０はＡＰが
ウィンドウサーバに対して発行するウィンドウ生成、描
画などの命令である。ＡＰが発行したリクエストメッセ
ージ５４０は制御プログラム４３０によって複数のウィ
ンドウサーバプログラム４２０−Ａ、４２０−Ｂに送信
される（１０６０、１０７０）。このときリクエストメ
ッセージ５４０は制御プログラム４３０のリクエスト変
換部５１０によって変換されてからウィンドウサーバ４
２０に送られる。

【００６０】図２５は入力メッセージ５６０の流れを示
している。この例は参加者Ａが操作権を持っている場合
である。参加者Ａのワークステーション１０−Ａからの
入力はウィンドウサーバ４２０−Ａによって入力メッセ
ージ５６０として制御プログラム４３０に送られてく
る。参加者Ｂのワークステーション１０−Ｂからの入力
もウィンドウサーバ４２０−Ｂによって入力メッセージ
５６０として制御プログラム４３０に送られてくる。こ
のとき、参加者Ａが操作権を持っているので、参加者Ｂ
からの入力メッセージは破棄され（１０８０）、参加者
Ａからの入力メッセージのみがＡＰ４７０に伝達される
（１０８０）。

【００６１】図２６は図２５と同様イベントメッセージ
の流れを示すが、今度は参加者Ｂが操作権を持っている
場合である。このときは参加者Ｂからの入力メッセージ
５６０のみがＡＰ４７０に伝えられ（１１１０）、参加
者Ａからの入力メッセージ５６０は破棄される（１１０
０）。

【００６２】図２７は参加者Ａが操作権を持つ場合のリ
プライメッセージ５８０の流れを示している。本実施例
の電子対話システムでは操作権を持つワークステーショ
ンが親サイトとなるため、ワークステーション１０−Ａ
が親サイトである。このとき、制御プログラム４３０は
参加者Ａからのリプライメッセージ５８０はＡＰ４７０
に伝達する（１１２０）が、参加者Ｂからのリプライメ
ッセージ８０は破棄する（１１３０）。

【００６３】図２８は参加者Ｂが操作権を持つ場合のリ
プライメッセージ５８０の流れを示している。この場合
は参加者Ｂからのリプライメッセージ５８０だけがＡＰ
４７０に伝達され（１１５０）、参加者Ａからのリプラ
イメッセージ５８０は破棄される（１１４０）。

【００６４】本発明の電子対話システムでは、上記の例
の「報告書」のような共同ＡＰと同時に、参加者が共同
作業とは無関係のＡＰを自分だけのために画面上に同時
に開くことができる。このような共同作業と無関係のＡ
ＰをローカルＡＰと呼ぶ。

【００６５】次に、参加者ＢがローカルＡＰを起動する
操作について説明する。図２９は参加者ＢがローカルＡ
Ｐ「グラフ」１２０を起動したところである。グラフア
イコン１２０の上にマウスカーソル１４０−Ｂを置いて
マウスボタンを押したのでポップアップメニュ−が表示
されている。ここでは、グラフ１２０を個人的に利用し
たいのでメニュー中の個人利用を選択する。その結果、
ローカルＡＰであるグラフ２８０が起動される。前の説
明で、共同利用のために開いた報告書２６０とは異な
り、グラフ２８０のウィンドウは参加者Ｂのディスプレ
イ４０−Ｂにのみ表示されている。つまり、このグラフ
ウィンドウ２８０は共同活動とは無関係なウィンドウで
ある。このようなローカルＡＰを起動する理由の一つは
ローカルＡＰの持つデータを共同活動で利用したいとい
うものである。

【００６６】通常、複数のＡＰでデータを交換する手段
としてカットアンドペーストと呼ばれる手段が用いられ
る。カットアンドペーストではまずデータ提供側のＡＰ
で提供するデータを共通領域に保存する操作を行う。こ
の操作をカット操作という。次に、データ受取側のＡＰ
で共通領域のデータを取り込む操作を行う。この操作を
ペースト操作という。これらの一連のカット操作，ペー
スト操作によりデータ提供側ＡＰからデータ受取側ＡＰ
に必要なデータを渡すことができる。ここで、データ交
換のために共通領域を利用するが、そのような共通領域
のことをカットバッファと呼ぶ。

【００６７】次に、カットアンドペーストを行う際のメ
ッセージの流れを説明する。ここでは、カットアンドペ
ーストの例としてローカルＡＰグラフ２８０から共同実
行ＡＰ報告書２５０にデータを渡す場合の操作を説明す
る。図３０はローカルＡＰグラフ２８０でのカット操作
を示す。参加者Ｂはまずカットしたいデータ３０５−Ｂ
を指定し、次にプルダウンメニュ−３１０でカット３１
２を選択する。図３１は、カット操作を行う時のメッセ
ージの流れを示す。ウィンドウサーバ４２０はデータ交
換用にメインメモリ４００上に共通領域１０４０を確保
している。この共通領域１０４０は各ワークステーショ
ン上で各ウィンドウサーバが管理している。参加者Ｂの
ワークステーションで動作しているローカルＡＰ４７４
が持つ交換データ３０５−Ｂをリクエストメッセージ５
４０によってウィンドウサーバプログラム４２０−Ｂが
管理する共通領域１０４０−Ｂに書き込む。

【００６８】このとき、書き込まれたデータ１１７０
と、ワークステーション１０−Ａの共通領域１０４０−
Ａに格納されているデータ１１６０は異なることに注意
する。これは、ワークステーション１０−Ａの共通領域
１０４０−Ａのデータは、例えばローカルＡＰ４７２か
ら書き込まれたものかも知れないからである。もちろ
ん、共通領域１０４０−Ａが空である場合もあるであろ
う。

【００６９】次に、図３２は共同実行ＡＰ２５０でのペ
ースト操作を示す。参加者Ｂは報告書２５０のプルダウ
ンメニュ−３２０でペースト３２６−Ｂを選択する。す
ると図３３に示されるように共同実行ＡＰである報告書
ウィンドウ２５０に、ローカルＡＰであるグラフ２８０
のデータ３２０−Ｂが表示される。このときペースト操
作をしたのは参加者Ｂであるが、報告書２５０は共同実
行されているため、結果として参加者Ａの報告書ウィン
ドウ２５０−でペーストが実行されデータ３３０−Ａが
表示される。本実施例のシステムでは、本発明の特徴で
ある操作権と親サイトの連動機能によってこのようなカ
ットアンドペーストが参加者の期待どおりに行われる。

【００７０】図３４はペースト操作を行うときのメッセ
ージの流れを示す。この時点では参加者Ｂは共同実行Ａ
Ｐ４７０でのペースト操作を行うために操作権を取得し
ており、その結果参加者Ｂのワークステーション１０−
Ｂが親サイトとなっていることに注意する。参加者Ｂの
ペースト操作により共同実行ＡＰ４７０が発行した共通
領域１０４０のデータを要求するリクエストメッセージ
５４０が制御プログラム４３０によって複数のウィンド
ウサーバプログラム４２０に送られるため、複数のウィ
ンドウサーバ４２０からリプライメッセージ５８０が返
ってくる。このリプライメッセージ５８０は共通領域１
０４０内のデータをＡＰ４７０に送るものである。とこ
ろが、上で述べたようにこのときは参加者Ｂのワークス
テーション１０−Ｂが親サイトとなっているため、参加
者Ａのウィンドウサーバ４２０−Ａからのリプライメッ
セージ５８０は破棄され（１１７０）、参加者Ｂのウィ
ンドウサーバ４２０−Ｂからのリプライメッセージ５８
０のみが共同実行ＡＰ４７０に伝えられる（１１８
０）。この結果、共同実行ＡＰ４７０には、参加者Ｂの
ローカルＡＰ４７４からカットしたデータ１１７０が送
られ、共同実行ＡＰ４７０に正しいデータ３３０がペー
ストされる。

【００７１】次に、本発明のような親サイトの動的な移
動を行わない従来システムにおいてカットアンドペース
トがうまくいかない場合を説明する。参加者Ｂは図３０
と同様にローカルＡＰでのカット操作を実行する。次
に、図３２と同様に共同実行ＡＰでのペースト操作を実
行する。すると、図３５のように共同実行ＡＰである報
告書のウィンドウ２５０には参加者Ｂがカットしたデー
タ３０５−Ｂとは別のデータ３４０が表示される。これ
は参加者Ｂのカットアンドペーストの結果に対する期待
と反する結果である。このような失敗が起こった原因
は、カットアンドペーストの実現メカニズムと関係があ
る。

【００７２】親サイトが動的に変化しない従来システム
では、ペースト操作を実行したときのメッセージの流れ
は図３６のようになる。ここでは、親サイトがワークス
テーション１０−Ａに固定されているため、参加者Ａの
ウィンドウサーバ４２０−Ａからのリプライメッセージ
５８０が共同実行ＡＰ４７０に伝えられ（１１９０）、
参加者Ｂのウィンドウサーバ４２０−Ｂからのリプライ
メッセージ５８０は破棄されてしまう（１２００）。こ
の結果、参加者Ｂがカットしたデータ１１７０ではな
く、参加者Ａのワークステーション１０−Ａの共通領域
に格納されている無関係なデタ１１６０を共同実行ＡＰ
が取り込んでしまう。

【００７３】本発明のようにペースト操作を行うために
操作権を取得すると自動的に親サイトが動的に変化する
ようになつていれば、このような不都合を防ぐことがで
きるのである。なお、会議を終了するには会議参加者の
中の任意の１人が会議室ウィンドウのプルダウンメニュ
−で会議終了を選択する。

【００７４】図３７〜４０は、ＵＩ制御部５００の他の
実施例を示す。操作権制御アイコン１３５−Ｂの入力が
あった場合には（ステップ８７５）、共同実行中のアプ
リケーションのリストを表示し（ステップ８８０）、マ
ウスポインタ１４０−Ｂで指示されたアプリケーション
を選択し（ステップ８８５）、サーバ情報テーブル８３
０の中の指定されたアプリケーションの操作権要求者リ
スト８４７に追加する（ステップ８９０）。

【００７５】図３９では、参加者Ｂのウィンドウに共同
実行中のアプリケーションのリストが表示されている。
参加者Ｂが資料を選択すると、参加者Ａの画面には、参
加者Ｂが操作権を要求していることを示すウィンドウが
表示される。参加者Ａが了解ボタンを押して初めて参加
者Ｂに操作権が移動する。

【００７６】図４０は、サーバ情報テーブル８３０を示
す。要求者リスト８４７の項目が設けられており、参加
者が操作権を要求すると、その順番が設定される。操作
権をもつ参加者が操作権を放棄すると、要求者リスト８
４７に設定された順序で次の参加者に操作権が移動す
る。この方法によれば参加者Ａが処理中不意に操作権を
失うという事態の発生が避けられる。また、他の参加者
も、操作権を獲得できる時期を予め推察できる。

【００７７】ここまでの説明ではただ１つのＡＰを共同
実行する場合について述べてきたが、同時に複数のＡＰ
を共同実行することもできることは言うまでもない。ま
た、以上の実施例では、操作権を持つワークステーショ
ンと親サイトを同一視し、操作権を移動すると親サイト
も操作権と共に移動する。別の実施例として、操作権を
持つワークステーションと親サイトを独立に設定できる
ようにしてもよい。この場合には，操作権を移動しても
親サイトは移動しないままである。

【００７８】さらに別の実施例として、操作権を設けな
いようにすることもできる。すなわち、参加者はいつで
も自由にＡＰに入力を行うことができるようにする。こ
のときも、親サイトはやはり設定し、移動する必要があ
るため、本実施例における操作権表示ウィンドウを親サ
イト表示ウィンドウとして利用すればよい。そして、親
サイト表示ウィンドウを操作することによって親サイト
を任意のワークステーションに割当てられるようにすれ
ば、参加者が自由にカットアンドペーストを行うことが
できる。

【００７９】

【発明の効果】本発明を用いることにより、従来自由に
行うことができなかった共同実行ＡＰとローカルＡＰと
の間でのカットアンドペースト等によるデータ交換が自
由に行えるようになる。

【図面の簡単な説明】

【図１】本発明が適用される電子対話システムの一般的
な構成を示す図。

【図２】本発明の一実施例の電子対話システムの概要を
示す図。

【図３】共同実行ＡＰに参加者Ａが入力を行っている様
子を示す図。

【図４】図２の実施例のハードウエア構成を示す図。

【図５】図４の実施例におけるプログラムの配置例を示
す図。

【図６】図４の実施例におけるプログラムの他の配置例
を示す図。

【図７】図４の実施例のソフトウエア構成を示す図。

【図８】リクエストメッセージを示す図。

【図９】入力メッセージを示す図。

【図１０】リプライメッセージを示す図。

【図１１】サーバインタフェース部の処理の流れを示す
図。

【図１２】ＡＰインタフェース部の処理の流れを示す
図。

【図１３】操作権制御部の処理の流れを示す図。

【図１４】サーバ情報テーブルを示す図。

【図１５】ＵＩ制御部の処理の流れを示す図。

【図１６】入力変換部の処理の流れを示す図。

【図１７】ウィンドウ識別子テーブルを示す図。

【図１８】リクエスト変換部の処理の流れを示す図。

【図１９】会議室ウィンドウが接続されて共同作業が可
能になったときの図。

【図２０】共同実行ＡＰを起動するためのポップアップ
メニューの操作を示す図。

【図２１】共同実行ＡＰが起動したところの図。

【図２２】参加者Ｂが共同実行ＡＰの操作権を得る操作
を示す図。

【図２３】共同実行ＡＰに参加者Ｂが入力を行っている
様子を示す図。

【図２４】リクエストメッセージの流れを示す図。

【図２５】入力メッセージの流れを示す図。

【図２６】入力メッセージの他の流れを示す図。

【図２７】リプライメッセージの流れを示す図。

【図２８】リプライメッセージの他の流れを示す図。

【図２９】共同実行ＡＰとは別にローカルＡＰが起動し
たときの図。

【図３０】参加者ＢがローカルＡＰでカット操作を行っ
ているところを示す図。

【図３１】カット操作時のデータの流れを示す図。

【図３２】参加者Ｂが共同実行ＡＰでペースト操作を行
っているところを示す図。

【図３３】共同実行ＡＰでのペースト操作の結果を示す
図。

【図３４】ペースト操作時のデータの流れを示す図。

【図３５】従来システムでのペースト操作の失敗例を示
す図。

【図３６】従来システムにおいてペースト操作失敗時の
データの流れを示す図。

【図３７】ＵＩ制御部の処理の他の例の流れを示す図。

【図３８】操作権制御アイコンを用いた例を示す図。

【図３９】参加者Ｂが操作権を得る操作を示す図。

【図４０】サーバ情報テーブルの他の例を示す図。

【符号の説明】

１０…ワークステーション、４２０…ウィンドウサーバ
プログラム、４３０…制御プログラム、４７０…ＡＰ、
４８０…サーバインタフェース、４９０…操作権制御
部、５００…ＵＩ制御部、８３０…サーバ情報テーブル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 亀田 正美 神奈川県横浜市戸塚区戸塚町5030番地株式 会社日立製作所ソフトウエア開発本部内 (72)発明者 山光 忠 神奈川県横浜市戸塚区戸塚町5030番地株式 会社日立製作所ソフトウエア開発本部内

Claims (10)

【特許請求の範囲】
1. 【請求項１】複数の計算機が各々入力手段と、ウィンド
   ウサーバと表示装置とを備え、前記計算機の少なくとも
   １つが、アプリケーションプログラムを備え、前記各計
   算機が通信ネットワークを介して接続され、前記アプリ
   ケーションプログラムを共同で実行する共同情報処理方
   法において、 前記計算機の少なくとも１つが、前記アプリケーション
   プログラムの操作権を制御するユーザ制御部と操作権制
   御部を備えており、 前記アプリケーションプログラムの発行するリクエスト
   メッセージを受信し、該受信したリクエストメッセージ
   を複数の他の計算機上で動作するウィンドウサーバに送
   信することによって、１つのアプリケーションプログラ
   ムの画面を前記複数の計算機の表示装置上に共同表示
   し、 かつ、前記複数の計算機上でなされた処理の結果発生す
   るメッセージを受信し混合して前記共同で実行されるア
   プリケーションプログラムに送信するものであって、 前記ユーザ制御部において、前記入力手段からの入力に
   基づいて、前記共同で実行するアプリケーションプログ
   ラムに対し入力することのできる操作権を持つ計算機を
   決定し、 前記操作権制御部において、前記アプリケーションプロ
   グラムが発行する問合せのリクエストメッセージに対す
   る前記複数のウィンドウサーバからの応答のうち前記操
   作権を持つウィンドウサーバからの応答だけを前記アプ
   リケーションプログラムに送信することによって、 前記１つのアプリケーションプログラムを前記複数の計
   算機上で共同操作できるようにしたことを特徴とする共
   同情報処理方法。
2. 【請求項２】前記ユーザ制御部における前記操作権の切
   り替えを、前記表示装置の画面上において表示された共
   同実行中の資料と共に表示されるメニューに従って対話
   入力することによって行うことを特徴とする請求項１記
   載の共同情報処理方法。
3. 【請求項３】前記複数の計算機のうち前記共同で実行さ
   れるアプリケーションプログラムを備えた計算機だけが
   前記アプリケーションプログラムに入力できる操作権を
   持つことが可能であり、参加者が前記アプリケーション
   プログラムに入力を行ったときに、前記ユーザ制御部が
   該入力を行った計算機を自動的に操作権を持つ計算機と
   して切り替えることを特徴とする請求項１記載の共同情
   報処理方法。
4. 【請求項４】前記操作権を持つ計算機から所定時間入力
   がないとき、その後最初に入力のあった他の計算機に前
   記操作権を移すことを特徴とする請求項１記載の共同情
   報処理方法。
5. 【請求項５】前記操作権に対する要求を出した計算機
   を、要求順にサーバ情報テーブルに登録し、該登録順に
   前記計算機の操作権を切り替えることを特徴とする請求
   項１記載の共同情報処理方法。
6. 【請求項６】ウィンドウサーバと、入力部及び出力部を
   備えた複数の端末を通信ネットワークを介して接続し、
   １つのアプリケーションプログラムを前記各端末上で共
   通に処理する共同情報処理装置であって、 前記少なくとも１つの端末が、前記アプリケーションプ
   ログラムと、対話入力に基づいて該１つのアプリケーシ
   ョンプログラムに入力可能な端末を決定し、その結果を
   サーバ情報テーブルに記録するユーザ制御部と、前記サ
   ーバ情報テーブルの記録に基づいて前記１つのアプリケ
   ーションプログラムに対する入力を受付けその結果を前
   記各端末に配布するよう前記ウィンドウサーバを制御す
   る操作権制御部、とを備えたことを特徴とする共同情報
   処理装置。
7. 【請求項７】ウィンドウサーバと、入力部及び出力部と
   を備えた複数の端末を通信ネットワークを介して接続
   し、少なくとも１つの前記端末にある１つのアプリケー
   ションプログラムを前記各端末上で共通に処理する共同
   情報処理装置であって、 前記少なくとも１つの端末が、対話入力に基づいて他の
   端末にある前記１つのアプリケーションプログラムに入
   力可能な端末を決定しその結果をサーバ情報テーブルに
   記録するユーザ制御部と、前記サーバ情報テーブルの記
   録に基づいて前記１つのアプリケーションプログラムに
   対する入力を受付けその結果を前記各端末に配布するよ
   う前記ウィンドウサーバを制御する操作権制御部、とを
   備えたことを特徴とする共同情報処理装置。
8. 【請求項８】複数の計算機が各々入力手段とウィンドウ
   サーバと表示装置とを備え、前記計算機の少なくとも１
   つが、アプリケーションプログラムを備え、前記各計算
   機が通信ネットワークを介して接続され、前記アプリケ
   ーションプログラムを共同で実行する共同情報処理装置
   であって、 前記計算機の少なくとも１つが、 前記アプリケーションプログラムの発行するリクエスト
   メッセージを受信し、該受信したリクエストメッセージ
   を複数の他の計算機上で動作するウィンドウサーバに送
   信することによって、１つのアプリケーションプログラ
   ムの画面を前記複数の計算機の表示装置上に共同表示
   し、 かつ、前記複数の計算機上でなされた処理の結果発生す
   るメッセージを受信し混合して前記共同で実行されるア
   プリケーションプログラムに送信するものにおいて、 前記計算機の少なくとも１つが、 前記入力手段からの入力に基づいて、前記共同で実行す
   るアプリケーションプログラムに対し入力することので
   きる操作権を持つ計算機を決定し、サーバ情報テーブル
   に登録するユーザ制御部と、 前記アプリケーションプログラムが発行する問合せのリ
   クエストメッセージに対する前記複数のウィンドウサー
   バからの応答のうち前記サーバ情報テーブルに登録され
   た操作権を持つウィンドウサーバからの応答だけを前記
   アプリケーションプログラムに送信するよう制御する操
   作権制御部とを備え、 前記１つのアプリケーションプログラムを前記複数の計
   算機上で共同操作できるようにしたことを特徴とする共
   同情報処理装置。
9. 【請求項９】前記ユーザ制御部が、前記表示装置の画面
   上において表示された共同実行中のアプリケーションプ
   ログラムと共に操作権表示ウィンドウを表示し、該ウィ
   ンドウに対する対話入力によって前記操作権の切り替え
   を行うよう構成したことを特徴とする請求項８記載の共
   同情報処理装置。
10. 【請求項１０】前記複数の計算機のうち前記共同で実行
    されるアプリケーションプログラムを備えた計算機だけ
    が前記アプリケーションプログラムに入力できる操作権
    を持つことが可能であり、前記ユーザ制御部が前記アプ
    リケーションプログラムに入力を行った計算機を自動的
    に操作権を持つ計算機として切り替えるよう構成したこ
    とを特徴とする請求項８記載の共同情報処理装置。