JPH08272744A - 情報処理方法及び装置 - Google Patents

Abstract

(57)【要約】 【目的】異なるアプリケーション間で共有可能で、かつ
個々のアプリケーションのフロア・モデルに対応可能な
柔軟性を有するフロア管理を可能とする。 【構成】１台以上のコンピュータによって構成される作
業環境において動作するアプリケーション群の発言権を
管理する情報処理装置が提供される。発言権制御の対象
であるアプリケーションを表現するFloorUnit２０６、
２０７が各アプリケーション２０４、２０５に対応づけ
て管理される。更に、FloorUnit２０６、２０７が属す
る集合を表現するFloorSpace２０８が管理される。そし
て、アプリケーションより発言権獲得の要求があると、
対応するFloorUnitが属するFloorSpaceにおける当該ア
プリケーションの発言権を該フロアデータに規定された
FloorPolicy２０９によって、所定の手順に従って獲得
される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、１台ないしそれ以上
のコンピュータ上における共同作業を支援する情報処理
方法及び装置に関するものである。

【０００２】

【従来の技術】近年、高速なＬＡＮやＷＡＮが一般に浸
透してくるに従い、ネットワークで結合された複数のコ
ンピュータ上で多様なアプリケーション・プログラムを
連係・動作させることにより、複数のユーザによる共同
作業の場をコンピュータ上に実現するシステム(狭義の
グループウェア)が提案され実際に利用される様になっ
てきた。このようなシステムでは、画像・文書などのデ
ータやアプリケーション・プログラムなどの資源(リソ
ースと呼ぶ)が複数のユーザによって共有されて利用さ
れる。リソースの操作が複数のユーザによって同時にお
こなわれると、データの内容やアプリケーションの内部
状態の一貫性を保ち、システムに正しい動作をおこなわ
せることが困難となる。このため、共有されるリソース
のユーザによる参照・操作の衝突を回避するための機構
が必要となる。

【０００３】このような機構の実現法として、1) アク
セス権管理方式、2) フロア管理方式の２つの方法が提
案されている。

【０００４】1)のアクセス権管理方式は、リソースを画
像・文書などのデータであるとみなし、データの参照・
変更権(アクセス権とよぶ)を各ユーザに対して規定する
ものである。各ユーザはアクセス権を持っているデータ
に対してのみ操作をおこなう事ができる。アクセス・コ
ントロール・リストやケイパビリティ・リストなどに基
づく実現法が一般に使用される(アクセス・コントロー
ル・リスト、ケイパビリティ・リスト等については、"O
perating Systems: Design and Implementation, ANDRA
EW S. TANENBAUM, Prentice-Hall, 1987.等を参照のこ
と）。

【０００５】これに対し、2)のフロア管理方式ではアプ
リケーションをリソースであるとみなし、アプリケーシ
ョンの操作権(発言権あるいはフロアともよぶ)をその時
々の状況にあわせてユーザに付与する。フロアを所有す
るユーザ(或はその代行者としてのアプリケーション)の
みがシステム上で操作をおこなうことができる。

【０００６】アクセス権管理方式は比較的簡単な構造と
ごく限られた操作(あるいは演算)体系を提供するシステ
ムで利用される。ＵＮＩＸオペレーティング・システム
(商標)におけるファイルシステムが代表的な適用例であ
る。

【０００７】これに対し、フロア管理方式は、状況によ
って動的に変化し得る複雑なリソース操作を要求される
システムで利用される。このため、グループウェア・シ
ステムでは主にフロア管理方式に基づくリソース管理方
式が使用される。

【０００８】ただし、上記２つの方式はまったく排他的
な方式というわけではなく、アクセス権管理方式をリソ
ース管理方式におけるフロア決定のメカニズムの１部と
して利用しているシステムも存在する。多くのオペレー
ティング・システムはアクセス権管理方式によるファイ
ル・システムを提供しているので、その上で構築された
フロア管理方式はアクセス権管理システムを利用するこ
とが可能である。

【０００９】従来、グループウェア・システム向きの上
記フロア管理方式の実現は、グループウェア・システム
上で動作する個々のアプリケーションが個別にフロア管
理のメカニズムを実装することにより実現されていた。
多くの場合、フロアを集中管理するプロセスを1つ設置
し、各アプリケーションはこのフロア管理サーバとの通
信によりフロアの獲得・放棄をおこなうという実装が採
用されている。

【００１０】

【発明が解決しようとする課題】しかしながら、従来の
フロア管理方式では、以下のような問題が発生する。即
ち、 １）アプリケーションごとにフロア管理メカニズムを実
装する必要があるので、アプリケーション・プログラム
が複雑化してしまい、アプリケーション開発が難しくな
る． ２）異なるアプリケーション間でのフロア管理の実現が
困難である． ３）フロアを取りあう実体がアプリケーション・プログ
ラムに限定されため、特定の操作や動的に組み込まれる
モジュールなどを制御の対象にすることが困難である． という問題が発生する。

【００１１】本発明は上記の問題に鑑みてなされたもの
であり、異なるアプリケーション間で共有可能で、かつ
個々のアプリケーションのフロア・モデルに対応可能な
柔軟性を有するフロア管理が可能な情報処理方法及び装
置を提供すること目的とする。

【００１２】また、本発明の他の目的は、フロア空間が
複雑な階層構造を構成するようなアプリケーション環境
に対応可能なフロア管理を提供することにある。

【００１３】また、本発明の他の目的は、アプリケーシ
ョンの起動・終了などによる動的なフロア空間の構成の
変化に対応可能な、柔軟なフロア管理を提供することに
ある。

【００１４】更に、本発明の他の目的は、上述した機能
を提供しつつ、アプリケーション開発者に負担を与える
ことなく実現することを可能とすることにある。

【００１５】

【課題を解決するための手段】上記の目的を達成するた
めの本発明の情報処理装置は以下の構成を備えている。
即ち、１台以上のコンピュータによって構成される作業
環境において動作するアプリケーション群の発言権を管
理する情報処理装置であって、発言権制御の対象である
アプリケーションを表現するユニットデータを管理する
第１管理手段と、前記ユニットデータが属する集合を表
現するフロアデータを管理する第２管理手段と、前記ア
プリケーションよりの要求に応じて、対応するユニット
データが属するフロアデータにおける当該アプリケーシ
ョンの発言権を該フロアデータに規定された手順で獲得
する獲得手段とを備える。

【００１６】また、好ましくは、前記ユニットデータの
構成及び前記フロアデータの構造を任意に変更する変更
手段を更に備える。ユニットデータの構成、フロアデー
タの構造を変更可能とすることで、種々の作業環境に柔
軟に対応できるようになる。

【００１７】また、好ましくは、前記第１及び第２管理
手段は、前記ユニットデータの構成及びフロアデータの
構造をデータの階層構造として管理する。フロア空間が
階層構造を有するようなアプリケーション環境に対応す
ることが可能となるからである。

【００１８】また、好ましくは、前記第１及び第２管理
手段は、前記ユニットデータの構成及びフロアデータの
構造を、データの関連をあらわす表を用いて表現する。
リレーショナル・データベースや単なる２次記憶システ
ムを用いてフロアデータ等を管理できるようになるから
である。

【００１９】また、好ましくは、前記獲得手段における
規定された手順は、複数のアプリケーション間で共有可
能である。

【００２０】また、好ましくは、前記獲得手段における
規定された手順は、独立したサーバ・プログラムとして
管理される。

【００２１】また、好ましくは、前記獲得手段における
規定された手順を任意に変更する変更手段を更に備え
る。

【００２２】また、好ましくは、前記アプリケーション
と前記ユニットデータの対応関係を管理する第３管理手
段（実施例ではフロア・トリガ表１００４が相当する）
を更に備える。アプリケーションとユニットデータの対
応をアプリケーション自身で管理する必要がなくなり、
アプリケーションプログラムの負担が軽減される。

【００２３】また、好ましくは、前記対応関係に基づい
て、前記アプリケーションにおける発言権制御処理を自
動的に起動する起動手段を更に備える。

【００２４】

【作用】上記の構成によれば、１台以上のコンピュータ
によって構成される作業環境において動作するアプリケ
ーション群の発言権を管理する情報処理装置が提供され
る。本発明の構成において、第１管理手段は発言権制御
の対象であるアプリケーションを表現するユニットデー
タを管理する。第２管理手段は、前記ユニットデータが
属する集合を表現するフロアデータを管理する。そし
て、獲得手段は、前記アプリケーションよりの要求に応
じて、対応するユニットデータが属するフロアデータに
おける当該アプリケーションの発言権を該フロアデータ
に規定された手順で獲得する。

【００２５】以上のようにして、本発明ではフロア取得
の対象となるユニットデータと、ユニットデータの集ま
りで表現されるフロアデータの構成および構造をモデル
化することが可能となる。さらにフロアデータ内におけ
る規定された手順に従って、モデル化されたフロア構造
(フロア・モデル)をアプリケーションやソフトウェア・
モジュール等の間で共有することを可能ならしめる。

【００２６】以上のような構成により、異なるアプリケ
ーション間で共有可能で、かつ個々のアプリケーション
のフロア・モデルに対応可能な柔軟性を持つフロア管理
方式が提供可能となる。

【００２７】

【実施例】以下に添付の図面を参照して本発明の好適な
一実施例を説明する。

【００２８】＜実施例１＞図１は実施例１の協調型グル
ープウェアシステムにおけるフロア管理機構の構成を表
す図である。

【００２９】本実施例である協調型グループウェアシス
テムは、複数のユーザが各ユーザ環境で複数のアプリケ
ーションを駆使しつつ、そのユーザおよびアプリケーシ
ョン間でさなざまなデータのやり取りをおこなわせるこ
とにより、グループ共同作業環境を提供するものであ
る。本システムではアプリケーション間の動作の一貫性
を保つために図１に示すフロア管理機構を提供する。

【００３０】図１において、ワークステーション１０１
は本実施例の処理を実行するＣＰＵ１０２と、本協調型
グループウェアシステムを構成するアプリケーション群
を保持する主記憶１０３を計算機バス１０５で結合して
構成されている。

【００３１】ワークステーション１０１にはディスプレ
イ１０４も計算機バス１０５によって結合されている。

【００３２】本実施例ではフロア管理のために利用され
るデータとオブジェクト指向データベース１０６を利用
して管理する。オブジェクト指向データベース１０６は
イーサネット等のネットワーク１０７を介してワークス
テーション１０１と結合されている。尚、図１に示され
るようなワークステーション１０１と同様の構成の複数
のワークステーションがネットワーク１０７を介して結
合され得る。

【００３３】データベース１０６で管理されるフロア管
理情報はフロア情報１０８とフロア・ポリシー情報１０
９に大別される。これらの情報の詳細については後述す
る。

【００３４】アプリケーション１１０は本協調型グルー
プウェアシステムを構成するアプリケーションの典型的
な例をあらわすものである。実際には複数のアプリケー
ションが１つないしそれ以上のワークステーション上で
動作する。アプリケーション１１０の内部には、フロア
管理に関する以下の4つのソフトウェア・モジュールお
よびデータ構造が存在する。以下に、これらについて説
明する。

【００３５】［フロア単位表現(FloorUnit)１１１］フ
ロア管理の対象となるアプリケーションやソフトウェア
・モジュールを表現するデータ構造である。フロア管理
機構は、このFloorUnit１１１に対してフロアの付与な
いし剥奪などの制御をおこなう。FloorUnit１１１は1つ
のアプリケーション内にすくなくとも1つ存在し、アプ
リケーションにおけるさまざまなフロアに１つずつ対応
する。

【００３６】［フロア空間表現(FloorSpace)１１２］フ
ロア空間表現(FloorSpace)１１２は、FloorUnit１１１
の集まりであるフロア空間を表現するデータ構造であ
る。FloorUnit１１２は多くの場合１つ以上のFloorSpac
e１１２に属し、そのFloorSpace１１２内において他のF
loorUnitとフロアをとりあう。

【００３７】FloorSpace１１２の実体はフロア情報１０
８としてデータベース１０６上で管理されており、本シ
ステムで動作する他のアプリケーションから参照するこ
とが可能である。フロア情報１０８とFloorSpace１１２
の対応関係はオブジェクト指向データベース１０６の提
供する機構により管理されている。この管理手段をアプ
リケーション１１０側で提供することにより、オブジェ
クト指向データベース１０６をリレーショナル・データ
ベースや単なる２次記憶システムで置き換える事も可能
である。尚、この点については、実施例２において詳述
する。

【００３８】［フロア・ポリシー表現(FloorPolicy)１
１３］FloorPolicy１１３はあるFloorSpaceと必ず関連
づけられ、そのFloorSpaceにおけるフロア制御の方式を
規定する。FloorPolicyの実体はフロア・ポリシー情報
１０９としてデータベース上１０６で管理され、他のア
プリケーションと共有される。

【００３９】［フロア・ポリシー実行モジュール１１
４］FloorUnit１１１、FloorSpace１１２、FloorPolicy
１１３の保持する情報を基に、アプリケーション１１０
におけるフロア制御を実施するソフトウェア・モジュー
ルである。本実施例におけるフロア・ポリシー実行モジ
ュール１１４はFloorPolicy１１３で定義されている関
数(メソッド)を呼びだすものである。

【００４０】また、FloorPolicy１１３上でのポリシー
の記述をTCL (TCLプログラム言語については、"Tcl and
the Tk Toolkit",John K. Ousterhout, Addison-Wesle
y, 1994. 参照のこと)などのスクリプト言語で記述する
ような実装も可能である。この場合、フロア・ポリシー
実行モジュール１１４は、FloorPolicy１１３が提供す
るスクリプトを解釈・実行するインタプリタとして実現
される。

【００４１】FloorUnit, FloorSpaceおよびFloorPolicy
はフロア制御のモデルを構築するために使用される。本
実施例におけるフロア管理は、このフロア制御モデルに
基づき実行される。

【００４２】図２は本実施例におけるフロア制御モデル
の概要を説明するための概念図である。図２において、
２つのワークステーション２０１，２０２がイーサネッ
ト・ケーブル２０３で結合されており、それぞれの上で
アプリケーション２０４，２０５が動作している。

【００４３】アプリケーション２０4上にはFloorUnit２
０６が、またアプリケーション２０５上にはFloorUnit
２０７が存在し、それぞれ各アプリケーションがフロア
取得の候補であることをあらわしている。FloorUnit２
０６，２０７はFloorSpace２０８に属しフロアを奪い合
う関係にある。FloorSpace２０８におけるフロア制御は
FloorPolicy２０９によって規定される。

【００４４】図３は、図２で示したフロア制御モデル
の、本実施例における実現方法を説明する図である。

【００４５】図３において、参照番号３０１から３０７
までの各構成は、図２における参照番号２０１から２０
７までの各構成に対応している。この図ではさらにオブ
ジェクト指向データベース３１５が追加され、図２にお
けるFloorSpace２０８とFloorPolicy２０９を表現する
データであるフロア情報３１１とフロア・ポリシー情報
３１４を管理する。

【００４６】オブジェクト指向データベース３１５によ
って、フロア情報３１１およびフロア・ポリシー情報３
１４は、アプリケーション３０４，３０５のデータ空間
にマップされる。これらは、アプリケーション３０４の
データ空間内ではFloorSpace３０９， FloorPolicy３１
２として参照・操作が可能である。また、同様にアプリ
ケーション３０５においてはFloorSpace３１０とFloorP
olicy３１３として参照・操作が可能である。

【００４７】一方のアプリケーション上のFloorSpace，
FloorPolicy上でおこなった操作の結果は、データベー
ス３１５上のフロア情報３１１，フロア・ポリシー情報
３１４に反映される。さらにその結果はデータベース３
１５によって他方のアプリケーション上のFloorSpace，
FloorPolicyに反映される。

【００４８】次に、FloorUnit, FloorSpaceおよびFloor
Policyのデータ構造について説明する。尚、オブジェク
ト指向データベース３１５内におけるフロア情報３１
１，フロア・ポリシー情報３１４のデータ構造は、オブ
ジェクト指向データベース３１５の実装に依存するた
め、ここでは取りあげない。多くのオブジェクト指向デ
ータベースではアプリケーションのデータ空間内のデー
タ構造をそのまま、データベース内でのデータ構造とし
て使用する。

【００４９】［FloorUnit］FloorUnitはＣ＋＋プログラ
ム言語のデータ構造として、 class FloorUnit { protected: int type; char* floorName; BOOL isFloorHolder; FloorSpace* space; int (*floorCallback)(int callback_type); int (*errorCallback)(int callback_type); public: int requestFloor(); int releaseFloor(); }; の様に定義されている(Ｃ＋＋プログラム言語について
は、"The Annotated Ｃ＋＋ Reference Manual, Margar
et A. Ellis etc., Addison-Wesley, 1990.を参照のこ
と)。

【００５０】上記の定義において、typeはFloorUnitとF
loorSpaceを区別するためのデータ型情報である。この
情報はFloorUnitデータの生成時に自動的に指定され
る。また、isFloorHolderはこのFloorUnitがフロアを確
保しているならTRUEを、そうでないならFALSEを値とし
て取る変数である。また、spaceには、このFloorUnitが
所属しているFloorSpaceへのポインタが登録される。

【００５１】また、floorCallbackはアプリケーション
・プログラム側で指定した関数のポインタが代入され
る。この関数はFloorUnitがフロアを取得したとき、お
よびフロアを失った時に自動的に呼び出される。floorC
allbackの仮引数として指定されているcallback_typeの
値が０ならばフロアの取得をあらわし、１ならばフロア
の喪失を表している。

【００５２】また、errorCallbackにはアプリケーショ
ン・プログラム側で指定した関数のポインタが代入され
る。この関数はFloorUnitにおけるフロア取得等の処理
がエラーになったとき自動的に呼び出される。errorCal
lbackの仮引数として指定されているcallback_typeの値
はfloorCallbackと同様に、０ならばフロアの取得を表
し、１ならばフロアの喪失を表している。

【００５３】また、FloorUnitには２つのメソッドreque
stFloor()とreleaseFloor()が定義されている。request
Floor()はアプリケーション・プログラム本体がフロア
を取得するためのインタフェースとなるメソッドであ
る。releaseFloor()は逆にアプリケーション・プログラ
ム本体がフロアを放棄するためのインタフェースを提供
するメソッドである。いずれも要求が満たされればTRUE
を返し、エラー等により要求が満たされなかった場合は
FALSEを返す。

【００５４】これらのメソッドにより、FloorUnitはア
プリケーション・プログラムとフロア管理機構のインタ
フェースを提供する。アプリケーション・プログラムは
以下の様にして、フロア管理機構を利用する。即ち、 1 FloorUnit* a_floor_unit = new FloorUnit(); 2 FloorSpace* a_floor_space = new FloorSpace("doSomething"); 3 a_floor_space->addFloorUnit(a_floor_unit); 4 ... 5 if (a_floor_unit->requestFloor() != TRUE) { 6 // エラー 7 ... 8 } else { 9 // フロア取得。適当な処理をおこなう． 10 ... 11 } となる。まず１行目で、FloorUnitのインスタンスを生
成する。次にFloorSpaceのインスタンスを生成して、３
行目でFloorUnitを登録している。ここでFloorSpaceイ
ンスタンス生成時に引き数としてあたえられる"doSomet
hing"は、このFloorSpaceを介して操作されるフロアに
付けられた名前(フロア名と呼ぶ)である。

【００５５】このアプリケーションがフロアを必要とす
る操作をおこなう場合、５行目に示す様にrequestFloor
()によってフロア取得を要求し、フロア取得に成功した
時のみ操作をおこなう(９，１０行目)。

【００５６】［FloorSpace］FloorSpaceは以下の様にし
て定義される。FloorSpaceの持つ属性はFloorUnitに若
干の属性を追加したものとなるので、Ｃ＋＋のサブクラ
スの機構を利用し追加される属性のみが記述される。即
ち、 となる。

【００５７】上記の定義において、floorUnitListはFlo
orUnitおよびFloorSpaceのリストであり、このFloorSpa
ceに含まれるフロア制御の対象をあらわしている。この
floorUnitListでは、FloorUnitだけでなくFloorSpaceも
フロア制御の対象として扱う事ができるので、後述する
様にフロア空間による階層構造を形成して複雑なフロア
制御形態をモデル化する事が可能となる。

【００５８】また、policyは、このFloorSpaceにおける
フロア制御を規定するFloorPolicyへのポインタであ
る。floorHolderは、フロアを保持しているFloorUnitな
いしFloorSpaceへのポインタである。このフロア所持者
は必ずfloorUnitListにも属している。また、発言権制
御規定の変更は、上記のFloorPolicy* Policy;の値の
変更によって行われる。この変更の手段は、Ｃ＋＋プロ
グラム言語の提供する、値の変更機構で実現される。

【００５９】さて、FloorSpaceには4つのメソッドFloor
Space(),addFloorUnit(),requestFloor()とreleaseFloo
r()が定義されている。requestFloor()はFloorUnitがフ
ロアを取得するためのインタフェースとなるメソッドで
ある。releaseFloor()は逆にFloorUnitがフロアを放棄
するためのインタフェースを提供するメソッドである。
FloorUnitで定義されているrequestFloor()およびrelea
seFloor()の処理は、FloorSpaceのrequestFloor(),rele
aseFloor()によって実現されている。いずれも要求が満
たされればTRUEを返し、エラー等により要求が満たされ
なかった場合はFALSEを返す。また、addFloorUnit()は
前述した様に引き数で指定されたFloorSpaceおよびFloo
rUnitをfloorUnitListに追加する。FloorSpace()はFloo
rSpaceの生成時に呼び出されるコンストラクタであり、
引き数としてフロア名をとる。

【００６０】［FloorPolicy］最後のFloorPolicyは以下
の様に定義されている。即ち、 class FloorPolicy { protected: char* policyName; public: virtual int requestFloor(FloorUnit* unit, FloorSpace* space); virtual int releaseFloor(FloorUnit* unit, FloorSpace* space); }; と定義されている。

【００６１】上記の定義において、policyNameは、この
FloorPolicyが表現するフロア制御方式につけられた名
前である。FloorPolicyはフロア制御のためのメソッド
を持っている。すなわち、requestFloor()はフロア取得
の要求に対する動作を規定するメソッドであり、releas
eFloor()はフロア放棄の要求に対する動作を規定するメ
ソッドである。FloorUnitおよびFloorSpaceで定義され
ている同名のメソッドは、最終的にFloorPolicyで定義
されているrequestFloor(),releaseFloor()を呼び出
す。

【００６２】フロア制御方式(フロア・ポリシー)には何
種類ものバリエーションが考えられ、それらが必要とす
る情報も多様である。これらのポリシーはFloorPolicy
データ構造に適当な属性を追加し、requestFloor()とre
leaseFloor()をオーバライド(override)することによ
り、本システムに組み込まれる。

【００６３】以上のように定義された、FloorUnit,Floo
rSpace,FloorPolicyは図4に示す様な階層構造を形成す
る。図４では４つのFloorUnit(401, 402, 403, 404)が
存在する。図４は本実施例におけるFloorUnitとFloorSp
aceの階層構造を表す図である。

【００６４】これらのうちFloorUnit４０１，FloorUnit
４０２，FloorUnit４０３はFloorSpace４０５に属して
いる。FloorSpace４０５のフロア制御はFloorPolicy４
０６によってコントロールされている。また、FloorSpa
ce４０５とFloorUnit４０４は、FloorSpace４０７を形
成し、FloorPolicy４０８によって制御されている。

【００６５】図４のような複数のFloorSpaceによって形
成されるフロアの階層構造全体におけるフロア制御は、
フロアの階層構造のルートからFloorUnitにむかって順
にフロア制御をおこなうことにより実行される。これは
下位のFloorSpace（よりFloorUnitに近いFloorSpace）
が上位のFloorSpace（より階層構造のルートに近いFloo
rSpace）で、フロア制御の"フロア"を順に獲得してい
き、最後にFloorUnitでのフロア制御がおこなわれると
いう処理になるためである。

【００６６】次に図５を用いて上記のようなデータ構造
のもとに、どのようにしてフロア制御が実行されるかに
ついて説明する。図５は本実施例によるフロア制御を説
明する図である。ここで述べる処理は図６と図７におい
てフローチャートで表現されている。即ち、図６はFloo
rUnitにおけるフロア制御を表すフローチャートであ
る。また、図７はFloorSpaceにおけるフロア制御を表す
フローチャートである。

【００６７】図５においてアプリケーション５０１は、
FloorUnit５０３，FloorSpace５０４，FloorPolicy５０
５のオブジェクト群からなるフロア管理モジュールと、
フロア管理モジュールのサービスを利用するアプリケー
ション・プログラムの本体５０２の２つのモジュールに
分割することができる。アプリケーション本体５０２に
は必ず１つ以上のFloorUnit５０３が対応づけられてい
る。アプリケーション本体５０２がフロアの取得あるい
は放棄をおこなう時は、まずFloorUnit５０３のメソッ
ド（requestFloor()およびreleaseFloor()）を呼び出し
て要求をおこなう。

【００６８】要求をうけとったFloorUnitは、自分があ
るFloorSpaceに属しているかをチェックする（ステップ
Ｓ６０１）。これはFloorUnitのspace属性の値がNULLか
否かで判断する。値がNULLのときは、どのFloorSpaceに
も属しておらず、他のFloorUnitとフロアを奪い合う必
要がない。このため、フロア取得・放棄ともにステップ
Ｓ６０５以下のFloorUnitにおけるフロア制御処理を直
ちに実行する。

【００６９】また、ステップＳ６０１におけるチェック
でFloorUnit５０３のspace属性の値がNULL以外であった
場合は、FloorSapceにおける同名のメソッドを呼び出す
事により、要求をそのFloorSpace５０４に転送する（ス
テップＳ６０２）。

【００７０】上記要求に基づいてFloorSpace５０４で行
われたフロア制御が終了すると、その結果はFloorUnit
５０３に返される。その結果、要求がエラーとなり許可
されなかった場合、isFloorHolderの値は変更されずerr
orCallbackに登録されている関数が呼び出される（ステ
ップＳ６０３、ステップＳ６０４）。

【００７１】要求が許可された場合、即ち、ステップＳ
６０３においてステップＳ６０２の要求に基づくFloorS
paceの処理がエラーとならなかったか、あるいはステッ
プＳ６０１でFloorSpaceに属していないFloorUnitであ
った場合はステップＳ６０５へ進む。ステップＳ６０５
にてフロアの取得要求が許可されたのであるなら、Floo
rUnitのisFloorHolderの値をTRUEにセットし（ステップ
Ｓ６０６）、そうで無いならばisFloorHolderをFALSEに
セットする（ステップＳ６０７）。それからfloorCallb
ackに登録されている関数を呼び出し（ステップＳ６０
８）、本処理を終了する。

【００７２】次に、上述のステップＳ６０２で呼び出さ
れるFloorSpace５０４におけるフロア制御について図７
を参照して説明する。

【００７３】FloorSpace５０４は要求を受け取ると、自
分が他のFloorSpaceに属しているかをチェックする（ス
テップＳ７０１）。これはFloorUnitと同様にspace属性
の値がNULLか否かで判断する。値がNULLのときは他のFl
oorSpaceには属しておらず、他のFloorUnitやFloorSpac
eとフロアを奪い合う必要がないため、フロア取得・放
棄ともに（ステップＳ７０４）以下のFloorSpaceにおけ
るフロア制御処理を直ちに実行する。

【００７４】また、ステップＳ７０１におけるチェック
でFloorSpace５０４のspace属性の値がNULL以外であっ
た場合は、space属性値である上位のFloorSpaceにおけ
る同名のメソッドを呼び出す事により、上位のFloorSpa
ceにおけるフロア操作権を要求する(ステップＳ７０
２)。尚、この要求に基づいて上位のFloorSpaceが行う
フロア制御処理は、図７のフローチャートで示される処
理とまったく同様に実行される。FloorSpace５０４にお
ける処理との相違点は、関連づけられているFloorPolic
yによって吸収される。

【００７５】FloorSpace５０４は上位のFloorSpaceへの
フロア操作権の要求の結果、上位のFloorSpaceにおける
フロア操作権の取得に失敗した場合、要求の発行元であ
るFloorUnit５０３にエラーを送り返す（ステップＳ７
０３、Ｓ７０６）。前述したように、FloorUnit５０３
はエラー通知を受け取ると、ステップＳ６０３、Ｓ６０
４によるエラー処理をおこなう。

【００７６】一方、ステップＳ７０３において上位のFl
oorSpaceからのフロア操作権の取得に成功した場合、Fl
oorSpace５０４はpolicy属性に登録されているFloorPol
icyにFloorUnitからの要求の実行を依頼する。この処理
は、FloorPolicyのrequestFloor()メソッドあるいはrel
easeFloor()メソッドをよびだすことによって実行され
る（ステップＳ７０４）。

【００７７】ここで、FloorPolicy５０５は、引数でわ
たされたFloorUnit５０３およびFloorSpace５０４、あ
るいはFloorPolicy５０５自身の属性の値を基に要求の
可否を判断して、結果をFloorSpace５０４に返す。

【００７８】FloorSpace５０４がおこなった要求がエラ
ーとなり許可されなかった場合は、FloorSpace５０４は
要求の発行元であるFloorUnit５０３にエラーを送り返
す（ステップＳ７０５、Ｓ７０６）。例えば、すでにフ
ロアを獲得しているFloorUnitがフロア獲得を要求した
り、フロアを獲得していないFloorUnitがフロア放棄を
要求した時などはエラーとなるかもしれない。但し、Fl
oorPolicyが実現しているフロア制御方式によりその動
作は異なる。

【００７９】一方、ステップＳ７０５において要求が許
可された場合、FloorSpace５０４はその結果を受け取る
とそれに基づいてfloorHolder属性の値を変更する。こ
こで、当該要求がフロア取得要求であるならば、floorH
olderに要求を発行したFloorUnit５０３のポインタを代
入する（ステップＳ７０７、Ｓ７０８）。また、要求が
フロア放棄要求ならば、floorHolderの値をNULLにする
（ステップＳ７０７、Ｓ７０９）。

【００８０】以上の様にしてFloorSpace５０４における
フロア制御が終了すると、さらにその結果はFloorUnit
５０３に返される（ステップＳ７１０）。

【００８１】以上説明したように、本実施例１はグルー
プウェア・システムにおけるフロア管理機構を用いて本
発明の一実施例を構成している。即ち、本実施例１で
は、「フロア単位」「フロア空間」および「フロア・ポ
リシー」をオブジェクト指向データベースを利用して、
FloorUnit，FloorSpace，FloorPolicyというＣ＋＋クラ
スを定義する事により導入し、かつFloorUnit，FloorSp
ace，FloorPolicyによって「フロア空間」の構成および
構造をモデル化することを可能にした。

【００８２】本実施例１によれば、グループウェア・シ
ステム上で動作するアプリケーションに組み込み可能な
Ｃ＋＋クラスとしてフロア管理機構を実現し提供するこ
とにより、既存のアプリケーションに一貫したフロア管
理機構を導入することが可能となった。

【００８３】また、「フロア空間」の構成および構造を
Ｃ＋＋オブジェクトのポインタ操作によって変更するこ
とが可能であるため、グループウェア・システムにおけ
る頻繁なユーザの参加・退席、およびそれに伴うアプリ
ケーションの起動・終了などによる動的な作業環境の変
化にも対応することも可能となっている。

【００８４】＜実施例２＞上記の実施例１において、協
調型グループウェアシステムにおける本発明の一実施例
を述べたが、本実施例２では以下に示すような他の構成
による一実施例を説明する。

【００８５】図８は実施例２のグループウェアシステム
におけるフロア管理機構の構成を表す図である。同図に
おいてワークステーション８０１は本実施例の処理を実
行するＣＰＵ８０２と、本協調型グループウェアシステ
ムを構成するアプリケーション群を保持する主記憶８０
３を計算機バス８０５で結合して構成されている。ワー
クステーション８０１にはディスプレイ８０４も計算機
バス８０５によって結合されている。

【００８６】本実施例では、フロア制御のメカニズムを
フロア・サーバ８０８およびフロア・ポリシー・サーバ
群８１０としてアプリケーション８０６から独立させて
実現する。

【００８７】フロア・サーバ８０８は図１におけるフロ
ア単位表現１１１とフロア空間表現１１２に相当し、フ
ロア情報の管理と、後述するフロア・ポリシー・サーバ
群の制御をおこなう。フロア・サーバ８０８は内部に、
実施例１におけるFloorUnitおよびFloorSpaceに相当す
るフロア実体対応表８０９を保持している。フロア実体
対応表８０９についても後述する。

【００８８】また、フロア・ポリシー・サーバ群８１０
は、図１におけるフロア・ポリシー表現１１３とフロア
・ポリシー実行モジュール１１４に相当し、1つのサー
バが１つないし数種類のフロア制御方式を実現してお
り、フロア・サーバ８０８の要求に基づきフロア制御を
実行する。

【００８９】各フロア・ポリシー・サーバ８１０は最低
限以下のリモート・メッセージ(フロア・サーバから送
られて来る)を処理する。リモートメッセージは、 ・requestFloor <フロア実体名1> <フロア実体名2> ・releaseFloor <フロア実体名1> <フロア実体名2> である。これらのリモート・メッセージは、実施例1に
おけるFloorPolicyに定義されていた同名のメソッドと
ほぼ同じ意味をもつ。

【００９０】即ち、requestFloorは指定されたフロア実
体１のフロア実体２におけるフロアの獲得を要求するリ
モート・メッセージである。また、releaseFloorは指定
されたフロア実体１のフロア実体２におけるフロアの放
棄獲得を要求するリモート・メッセージである。

【００９１】フロア・サーバ８０８とフロア・ポリシー
・サーバ群８１０は、ワークステーション８０１上で動
作させることが可能であるが、通常ワークステーション
８０１と同じ構成をもつ他のワークステーション上で動
作させることも可能である。

【００９２】さて、アプリケーション８０６はフロア・
インタフェース・モジュール８０７を介してフロア・サ
ーバ８０８のサービスを利用することによりフロア制御
をおこなう。

【００９３】次に、フロア・サーバ８０８について説明
する。図９はフロア・サーバの内部構造を表す図であ
る。同図において、フロア・サーバ９０１は処理プログ
ラム９０２とフロア実体対応表９０３および、フロア・
ポリシー・サーバ表９０４から構成される。実施例１
で、データの参照関係で表現していた図４のようなフロ
ア単位およびフロア空間の階層を、本実施例ではフロア
実体対応表９０３によって管理する。フロア実体対応表
９０３は以下の５つの属性(アトリビュート)を有する。

【００９４】即ち、フロア実態対応表９０３の有する属
性は、 ・フロア実体名９０５ ・ユニット・リスト９０６ ・フロア所持者名９０７ ・フロア・ポリシー名９０８ ・上位実体名９０９ の５つの属性である。各属性は実施例１におけるFloorU
nitおよびFloorSpaceデータ構造の属性に対応させるこ
とができる。以下各属性について説明する。

【００９５】［フロア実体名９０５］フロア実体とはフ
ロア単位とフロア空間を総称したものである。フロア実
体対応表９０３の各横の列(タプルとよぶ)は1つのフロ
ア実体を表現している。フロア実体名９０５は、各タプ
ルが表現するフロア実体につけられる一意な名前であ
り、タプル生成時に指定される。フロア実体名９０５は
タプル検索における主キーとして使用される。

【００９６】［ユニット・リスト ９０６］ユニット・
リスト９０６はフロア実体に含まれている下位のフロア
実体の名前のリストである。ユニット・リスト９０６が
空値であるフロア実体は実施例１におけるフロア単位に
相当し、その他のフロア実体はフロア空間に相当する。

【００９７】［フロア所持者名９０７］フロア所持者名
９０７はユニット・リスト９０６に含まれるフロア実体
の中で、現在フロアを確保しているフロア実体の名前を
管理する。このフロア所持者名９０７には複数のフロア
実体名を登録できるため、実施例１においてFloorUnit
が提供するフロア・モデルと異なり、１つのフロア空間
内で複数の発言者が存在し得るモデルにも対応する事が
できる。

【００９８】［フロア・ポリシー名９０８］フロア・ポ
リシー名９０８はフロア実体におけるフロア制御を実行
するフロア・ポリシー・サーバの名前である。この名前
はフロア・ポリシー・サーバ表９０４の主キーとして使
用され、フロア・ポリシー・サーバとの通信に必要な情
報の取得に利用される。本実施例ではFloorUnit相当の
フロア実体にもフロア・ポリシー名を指定することによ
り、FloorUnitとFloorSpaceを区別せずに扱うことが可
能になっている。

【００９９】［上位実体名９０９］最後の上位実体名９
０９は、このフロア実体自身をユニット・リストに含む
上位のフロア実体の名前である。この属性により、図４
に示したものと同様なフロア・モデルを形成することが
できる。また、本実施例２では実施例１1におけるフロ
ア・モデルと異なり、複数の上位実体の名前を上位実体
名９０９に登録する事ができるため、複数のフロア空間
に属するフロア実体を表現する事が可能である。

【０１００】さて、フロア・サーバ９０１は以上のフロ
ア実体対応表９０３を参照および変更するためのリモー
トメッセージ・インタフェースを提供している。リモー
トメッセージインターフェースとしては、 ・addFloorEntity <フロア実体名> <ユニット・リスト>
<フロア・ポリシー名> <上位実体名> ・removeFloorEntity <フロア実体名> ・findFloorEntity <フロア実体名> が提供されている。

【０１０１】addFloorEntityはフロア実体を生成し、フ
ロア実体対応表９０３に追加するためのメッセージであ
る。引き数としてフロア所持者名以外の値が指定され
る。フロア実体生成時におけるフロア所持者名は必ず空
値である。また、removeFloorEntityは逆にフロア実体
名を指定し、フロア実体対応表９０３から実体を削除す
る。最後のfindFloorEntityは指定したフロア実体の全
ての値の取得を要求するメッセージである。また、実施
例２において、発言権制御規定の変更は、フロア実体対
応表内のフロアポリシー名の変更によって行われる。こ
の手段は、addFloorEntityとremoveFloorEntityによっ
て提供される。

【０１０２】任意のアプリケーション・プログラムは、
このインタフェースを利用する事により図４に示した様
なフロア階層を動的に変更する事が可能である。さら
に、このフロア階層変更処理に適当なフロア制御を適用
することも可能である。

【０１０３】フロア・ポリシー・サーバ表９０４は前述
したようにフロア・ポリシー名９０８を主キーとして通
信に必要なポートなどの情報を管理するための表であ
る。主にフロア制御処理においてフロア・ポリシー・サ
ーバとのデータ通信が必要となったときに参照される。

【０１０４】フロア・ポリシー・サーバ表９０４におい
ても、フロア実体対応表９０３と同様な参照・変更イン
タフェースをフロア・サーバ９０１は提供している。新
たなフロア制御方式を組み込むためには、そのフロア制
御方式を実装したフロア・ポリシー・サーバを作成し、
フロア・ポリシー・サーバ表９０４に登録してやれば良
い。

【０１０５】次に示す図１０は、アプリケーション内に
おけるフロア・インタフェース・モジュールの概要をあ
らわす図である。図に示す様に、一般的なアプリケーシ
ョン１００１は、フロア制御のインタフェースを提供す
るフロア・インタフェース・モジュール１００２とそれ
以外のアプリケーション・プログラム本体１００３に分
割できる。

【０１０６】本実施例におけるフロア・インタフェース
・モジュール１００２は、Ｃプログラム言語で作成され
た後述する数個の関数とフロア・トリガ表１００４が主
な構成要素である。フロア・インタフェース・モジュー
ル１００２のサービスの利用において、実施例1ではア
プリケーション・プログラムの本体がFloorUnitに明示
的に要求をだすことによりフロアの制御をおこなってい
たが、本実施例では、これとは異なるフロア制御の利用
機構を提供する。

【０１０７】即ち、プログラマはフロア制御が必要な処
理を以下の型をもつ関数として、 typedef int (*operator_t)(); のように定義し、その関数を、フロア・インタフェース
・モジュール１００２が提供する以下の関数でフロア・
インタフェース・モジュール１００２に登録する。その
関数は、 int RegisterOperation(char* floorName, operator_t anOperation); で表される。ここでfloorNameは、登録されるanOperati
onが対象となるフロア制御におけるフロアにつけられた
名前である。RegisterOperation()で登録された、フロ
ア名floorNameと関数ポインタanOperationは、フロア・
トリガ表１００４に追加される。この表の主キーは関数
ポインタanOperationの値(すなわちアドレス)である。

【０１０８】本実施例２では、RegisterOperation()で
登録された関数の呼び出し時に自動的にフロア制御をお
こない、呼び出された関数を実行する事が可能か否かを
決定する。ここでのべるインタフェースはもちろん実施
例１においても同様にして実現することが可能である。

【０１０９】登録された関数の呼び出し時に、フロア制
御を自動的に実行する機構の実現には以下の２通りの実
装方法が可能である。

【０１１０】１）フロア・インタフェース・モジュール
１００２で以下の様な関数呼び出し専用の関数invoke()
を用意し、フロア制御を実行する関数は必ずinvoke()を
介して呼び出すことを義務づける。invoke()は、 void* invoke(operator_t anOperation, char* argDescription, ...); で表される。上記の定義においてanOperationは呼び出
される関数のアドレス、argDescriptionはanOperation
に渡される引数の型情報である。invoke()がanOperatio
nで指定された関数の実行前にフロア制御をおこない、
フロアが獲得できた時のみanOperationを実行する。

【０１１１】さらに、このinvoke()による関数呼び出し
を前処理系(プリプロセッサ)やマクロなどの従来技術を
もちいてプログラマが明示することなく自動生成させる
ことも可能である。

【０１１２】２）オペレーティングシステムあるいは、
オブジェクト指向データベースのクライアントライブラ
リなどが提供する関数呼び出しのトラップ機構を利用す
る。このトラップ機構はswizzlingやexception handlin
gなどの従来技術によって実現され、いくつかの商用シ
ステムでも利用可能である（swizzling, exception han
dlingについては、"Object data management: object-o
riented and extendedrelational database systems",
R.G.G. Cattell, Addison-Wesley, 1991.を参照の
事）。

【０１１３】本実施例２では以下、方式１）に基づいて
説明をおこなうが、この説明は方式２）においてもその
まま適用することができる。

【０１１４】次に図１１をもちいてinvoke()によって開
始されるフロア制御の流れを説明する。図１１は実施例
２のフロア制御を説明する図である。また図１２は図１
１におけるアプリケーション１１０２の動作を表すフロ
ーチャートである。また、図１３は図１１におけるフロ
ア・サーバ１１０１の動作を表すフローチャートであ
る。また、図１４は図１１におけるフロア・ポリシー・
サーバ１１０３の動作を表すフローチャトである。

【０１１５】図１１において、フロア・サーバ１１０１
とアプリケーション１１０２およびフロア・ポリシー・
サーバ１１０３が連係して動作している。アプリケーシ
ョン１１０２内のアプリケーション本体１１０４により
フロア・インタフェース・モジュール１１０５のinvoke
()関数が呼び出されると、フロア・インタフェース・モ
ジュール１１０５はinvoke()の引き数として指定された
関数のアドレスをキーとしてフロア・トリガ表１１０６
から関連づけられてるフロア実体名を取り出す（ステッ
プＳ１２０１）。そして、取り出されたフロア実体名が
示すフロアの取得要求１１０７をフロア・サーバ１１０
１に対して発行する（ステップＳ１２０２）。この後ア
プリケーション１１０２は結果が返されるまで待機する
（ステップＳ１２０３）。

【０１１６】フロア・サーバ１１０１がフロア取得要求
処理を実行した結果が返されると、ステップＳ１２０４
へ進む。フロア・インタフェース・モジュール１１０５
は、フロア獲得要求が許可されたならば、invoke()で指
定された関数anOperationを呼び出し、アプリケーショ
ン本体１１０４が指定した処理を実行する（ステップＳ
１２０５）。また、フロア獲得要求が拒否された場合
は、anOperationを呼び出すことなくinvoke()は処理を
終了する。

【０１１７】anOperation実行の終了後にさらにフロア
放棄要求に関する処理がおこなわれる。即ち、anOperat
ionの返り値がFALSEならばステップＳ１２０６からステ
ップＳ１２０７へ進み、フロア・インタフェース・モジ
ュール１１０５はフロア放棄要求をフロア・サーバ１１
０１に発行する。フロア放棄要求の処理の流れはフロア
獲得要求における処理とほぼ同じである。相違点につい
ては後述する。フロア放棄要求処理がすべて終了する
と、要求の可否にかかわらずinvoke()は処理を終了す
る。また、ステップＳ１２０６においてanOperationの
返り値がTRUEならば、invoke()はフロア放棄要求処理を
おこなわずに即座に処理を終了する。

【０１１８】次にフロア・サーバ１１０１が、アプリケ
ーション１１０２からステップＳ１２０２の処理によっ
て送られてきたフロア取得要求１１０７をどの様にして
処理するかについて図１３のフローチャートに沿って説
明する。

【０１１９】フロア・サーバ１１０１はフロア取得要求
１１０７を受け取ると、フロア実体対応表１１０８から
指定されたフロア実体名をキーとしてタプルを取り出し
（ステップＳ１３０１）、そこからまず上位実体を抜き
出す（ステップＳ１３０２）。上位実体名に適当なフロ
ア実体名が指定されていた場合は、実施例１と同様に、
上位実体上でフロア操作権を獲得するために上位実体に
対してフロア操作権の獲得を要求する（ステップＳ１３
０３、Ｓ１３０４）。尚、フロア操作権の獲得のための
手続きはここで述べる処理（ステップＳ１３０１からＳ
１３１３）を、上位実体名が空値になっているフロア実
体が見つかるまで繰り返す。一方ステップＳ１３０３に
おいて、上位実体名に適当なフロア実体名が指定されて
おらず空値になっている場合はそのままステップ１３０
７へ進み、無条件にフロア操作権を獲得し処理を続行す
ることができる。

【０１２０】しかし上位実体でのフロア操作権の獲得に
失敗した場合はステップＳ１３０５からステップ１３０
６へ進み、結果をアプリケーション１１０２に通知し、
フロア・サーバ１１０１は処理を終了する。

【０１２１】さて、ステップＳ１３０３において上位実
体が指定されていなかったか、ステップＳ１３０５にお
いて上位実体名におけるフロア操作権が得られた場合
は、ステップＳ１３０７へ進み、タプルからフロア・ポ
リシー名を抜きだす。フロア・ポリシー名はさらにフロ
ア・ポリシー・サーバ表１１０９のキーとして使用さ
れ、フロア・ポリシー・サーバ１１０３との通信に必要
なポート番号やソケット等の情報を取り出す（ステップ
Ｓ１３０８）。この情報によりフロア・ポリシー・サー
バ１１０３との通信が可能になると、フロア・サーバ１
１０１はフロア実体名と上位実体名を付加してrequestF
loor要求１１１０をフロア・ポリシー・サーバ１１０３
に対して発行する（ステップＳ１３０９）。この後フロ
ア・サーバ１１０１は結果が返されるまで待機する（ス
テップＳ１３１０）。

【０１２２】フロア・ポリシー・サーバ１１０３がフロ
ア取得要求処理をおこなった結果が返されると処理はス
テップＳ１３１０からステップＳ１３１１へ進む。ステ
ップＳ１３１１において、フロア獲得要求がフロア・ポ
リシー・サーバ１１０３により許可された時は、フロア
実体対応表１１０８における上位実体中のフロア獲得者
名を、要求を発行したフロア実体名に変更する（ステッ
プＳ１３１２）。一方ステップＳ１３１１においてフロ
ア・ポリシー・サーバ１１０３による許可を得られなか
った場合は、フロア実体対応表１１０８の変更は発生し
ない。

【０１２３】以上のフロア・サーバ１１０１内での処理
が終了すると、結果１１１２はさらにアプリケーション
１１０２に転送される（ステップＳ１３１３）。転送さ
れた結果１１１２はフロア・インタフェース・モジュー
ル１１０５によって受け取られ、アプリケーション１１
０２においてステップＳ１２０４以下の処理が行われ
る。

【０１２４】最後にフロア・ポリシー・サーバ１１０３
におけるフロア取得要求処理について図１４に従い説明
する。

【０１２５】フロア・ポリシー・サーバ１１０３は、ス
テップＳ１３０９でフロア・サーバ１１０１が発行した
requestFloor要求１１１０を適当なフロア制御ポリシー
に従い、その要求の可否を判断する（ステップＳ１４０
１）。フロア獲得要求の可否の判断の結果１１１１は、
フロア・サーバ１１０１に返される（ステップＳ１４０
２）。そして、結果１１１１はフロア・サーバ１１０１
に通知され、フロア・サーバ１１０１においてステップ
Ｓ１３１１以下の処理が続行される。

【０１２６】以上述べた様な、フロア・サーバ１１０
１、アプリケーション１１０２、及びフロア・ポリシー
・サーバ１１０３の連係により、フロア獲得要求が処理
される。前述した様にフロア放棄要求処理は、フロア・
サーバ１１０１とフロア・ポリシー・サーバ１１０３に
ついてはフロア獲得要求におけるrequestFloorメッセー
ジのかわりにreleaseFloorメッセージが使用される事を
のぞき、フロア獲得要求における処理とまったく同じで
ある。アプリケーション１１０２においては、図１２に
おけるステップＳ１２０１からＳ１２０４までの処理を
実行することによりフロア放棄要求処理が行われる。

【０１２７】以上説明したように、実施例２はグループ
ウェア・システムにおけるフロア管理機構を実施例１と
は異なる構成で実現したものである。即ち、実施例２に
よれば、フロア実体対応表を管理するフロア・サーバ
と、フロア制御方式を規定するフロア・ポリシー・サー
バを導入し、フロア管理および制御に必要なリモート・
メッセージ・インタフェースを提供し、それをアプリケ
ーション・プログラムから利用可能にするフロア・イン
タフェース・モジュールを提供する。

【０１２８】そして、実施例２によれば、フロア関連情
報を表(テーブル)の形で管理する事により、フロア制御
に必要な情報の操作にリレーショナル代数などの体系を
利用することが可能となり、データの正当性および一貫
性などの管理が容易になるという効果がある。

【０１２９】また、本実施例ではアプリケーション・プ
ログラムからフロア制御機構をinvoke()関数により隠蔽
することができるため、アプリケーション開発者の負担
を軽減し既存のプログラムへのフロア管理機構の組み込
みが容易になるという効果をもつ。

【０１３０】尚、本発明は、複数の機器から構成される
システムに適用しても１つの機器からなる装置に適用し
ても良い。また、本発明はシステム或いは装置に本発明
により規定される処理を実行させるプログラムを供給す
ることによって達成される場合にも適用できることはい
うまでもない。

【０１３１】

【発明の効果】以上説明したように本発明によれば、 （１）異なるアプリケーション間で共有可能で、かつ個
々のアプリケーションのフロア・モデルに対応可能な柔
軟性を持つフロア管理方式を提供することができる． （２）フロア空間が複雑な階層構造を構成するようなア
プリケーション環境に対応可能なフロア管理方式を提供
することができる． （３）アプリケーションの起動・終了などによる動的な
フロア空間の構成の変化にも対応可能な、柔軟なフロア
管理方式を提供することができる． （４）以上の効果をアプリケーション開発者に負担を与
えることなく実現することができる． という効果を得ることができる。

【０１３２】

【図面の簡単な説明】

【図１】実施例１の協調型グループウェアシステムにお
けるフロア管理機構の構成を表す図である。

【図２】本実施例におけるフロア制御モデルの概要を説
明するための概念図である。

【図３】図２で示したフロア制御モデルの、本実施例に
おける実現方法を説明する図である。

【図４】本実施例におけるFloorUnitとFloorSpaceの階
層構造を表す図である。

【図５】本実施例によるフロア制御を説明する図であ
る。

【図６】FloorUnitにおけるフロア制御を表すフローチ
ャートである。

【図７】FloorSpaceにおけるフロア制御を表すフローチ
ャートである。

【図８】実施例２のグループウェアシステムにおけるフ
ロア管理機構の構成を表す図である。

【図９】フロア・サーバの内部構造を表す図である。

【図１０】アプリケーション内におけるフロア・インタ
フェース・モジュールの概要をあらわす図である。

【図１１】実施例２のフロア制御を説明する図である。

【図１２】図１１におけるアプリケーション１１０２の
動作を表すフローチャートである。

【図１３】図１１におけるフロア・サーバ１１０１の動
作を表すフローチャートである。

【図１４】図１１におけるフロア・ポリシー・サーバ１
１０３の動作を表すフローチャトである。

【符号の説明】

１０１、２０１、２０２ ワークステーション １０２ ＣＰＵ １０３ 主記憶 １０４ ディスプレイ １０５ 計算機バス １０６ オブジェクト指向データベース １０７、２０３ イーサネットケーブル １０８ フロア情報 １０９ フロア・ポリシー情報 １１０、２０４、２０５ アプリケーション １１１、２０６、２０７ フロア単位表現（FloorUni
t） １１２、２０８ フロア空間表現（FloorSpace） １１３、２０９ フロア・ポリシー表現（FloorPolic
y） １１４ フロア・ポリシー実行モジュール

Claims (10)

【特許請求の範囲】
1. 【請求項１】 １台以上のコンピュータによって構成さ
   れる作業環境において動作するアプリケーション群の発
   言権を管理する情報処理装置であって、 発言権制御の対象であるアプリケーションを表現するユ
   ニットデータを管理する第１管理手段と、 前記ユニットデータが属する集合を表現するフロアデー
   タを管理する第２管理手段と、 前記アプリケーションよりの要求に応じて、対応するユ
   ニットデータが属するフロアデータにおける当該アプリ
   ケーションの発言権を該フロアデータに規定された手順
   で獲得する獲得手段とを備えることを特徴とする情報処
   理装置。
2. 【請求項２】 前記ユニットデータの構成及び前記フロ
   アデータの構造を任意に変更する変更手段を更に備える
   ことを特徴とする請求項１に記載の情報処理装置。
3. 【請求項３】 前記第１及び第２管理手段は、前記ユニ
   ットデータの構成及びフロアデータの構造をデータの階
   層構造として管理することを特徴とする請求項１に記載
   の情報処理装置。
4. 【請求項４】 前記第１及び第２管理手段は、前記ユニ
   ットデータの構成及びフロアデータの構造を、データの
   関連をあらわす表を用いて表現することを特徴とする請
   求項１に記載の情報処理装置。
5. 【請求項５】 前記獲得手段における規定された手順
   は、複数のアプリケーション間で共有可能であることを
   特徴とする請求項１に記載の情報処理装置。
6. 【請求項６】 前記獲得手段における規定された手順
   は、独立したサーバ・プログラムとして管理されること
   を特徴とする請求項１に記載の情報処理装置。
7. 【請求項７】 前記獲得手段における規定された手順を
   任意に変更する変更手段を更に備えることを特徴とする
   請求項１に記載の情報処理装置。
8. 【請求項８】 前記アプリケーションと前記ユニットデ
   ータの対応関係を管理する第３管理手段を更に備えるこ
   とを特徴とする請求項１に記載の情報処理装置。
9. 【請求項９】 前記対応関係に基づいて、前記アプリケ
   ーションにおける発言権制御処理を自動的に起動する起
   動手段を更に備えることを特徴とする請求項８に記載の
   情報処理装置。
10. 【請求項１０】 １台以上のコンピュータによって構成
    される作業環境において動作するアプリケーション群の
    発言権を管理する情報処理装置であって、 発言権制御の対象であるアプリケーションを表現するユ
    ニットデータを管理する第１管理工程と、 前記ユニットデータが属する集合を表現するフロアデー
    タを管理する第２管理工程と、 前記アプリケーションよりの要求に応じて、対応するユ
    ニットデータが属するフロアデータにおける当該アプリ
    ケーションの発言権を該フロアデータに規定された手順
    で獲得する獲得工程とを備えることを特徴とする情報処
    理方法。