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

Description

【０００１】
【発明の属する技術分野】
本発明は、複数のプロセス間でデータを共有する技術に関する。特に３次元仮想空間を記述するデータを保持するデータベースをネットワークを介して複数のプロセス間で同期させるのに好適な技術に関する。
【０００２】
【従来の技術】
異なるコンピュータ端末間で３次元仮想空間を共有する技術は、遠隔会議システム、ネットワーク型対戦ゲーム、協調型デザインシステムなどを実現するために必須である。
【０００３】
このような３次元仮想空間を共有するシステムでは、仮想空間の動画像をコンピュータグラフィクスにより描画するために、短い時間間隔で多量のデータを参照する。このとき、一つの装置（例えばサーバ）に保持されている仮想空間のデータ全体をネットワークを介して取得することは、現在のネットワークのバンド幅の狭さから現実的ではない。したがって、各々の端末が仮想空間データのコピーを持ち、それを参照することによってＣＧ画像を生成する方式が採用されている。また、あるコンピュータ端末上で仮想空間に対して何らかの操作、例えば仮想物体の移動や回転が行われた場合には、その操作に関する情報が他の端末にネットワーク経由で伝送され、各端末の持つデータベースに反映される。この結果、各コンピュータ端末におけるデータベースの同一性が保たれる。
【０００４】
従来の仮想空間共有システムにおける上述のデータベースの同一性保持の手順の詳細は次のとおりである。すなわち、あるコンピュータ端末における仮想空間に対する操作が当該端末のローカルのデータベースに直ちに反映されるとともに、当該操作情報が他のコンピュータ端末に送信される。他の端末は、この操作情報を受信し、受信した操作情報に従ってデータを更新する。
【０００５】
このような仮想空間共有システムの実現例としては、非特許文献１に記載されたものが挙げられる。
【０００６】
【非特許文献１】
Distributed Open Inventor（出展：G.Heshina et.al. : "Distributed Open Inventor : A Practical Approach to Distributed 3D Graphics", in Proc. of the ACM Symposium on Virtual Reality Software and Technology (VRST'99), pp.74-81, 1999）
【０００７】
【発明が解決しようとする課題】
しかしながら、従来の仮想空間共有システムでは、操作を行なった端末においてその操作内容が当該端末のデータベースに即座に反映され、他の端末はその操作情報を受信してからデータベースの更新が行なわれる。従って、操作を行った端末とそれ以外の端末とでデータベースを更新するタイミングが異なってしまう。特に、ネットワーク上のトラフィックの影響等で、操作情報の受信までに時間がかかると、端末間のデータベースの更新のタイミングのズレは顕著となる。このため、端末間で仮想空間の描画結果に違いが生ずる可能性があるという問題点があった。
【０００８】
また、データベースの操作および更新の手順は上記の如き手順に固定されており、データ更新のタイミングを選択あるいは調整することができないという問題もある。
【０００９】
本発明は上記の課題に鑑みてなされたものであり、複数のプロセスで共有される共有データに関して、操作を実行するタイミングをほぼ同一とすることを目的とする。
【００１０】
【課題を解決するための手段】
上記の課題を解決するための本願発明による情報処理方法は、
情報伝達媒体を介して接続された複数のクライアントプロセスによって共有される共有データを該複数のクライアントプロセスの各々が保持して利用するシステムにおいて、各クライアントプロセスが保持する共有データの同一性を維持するための情報処理方法であって、
操作要求を入力する入力工程と、
前記共有データに含まれる複数のアイテムの各々に対するモードを指定する指定情報および前記操作要求の操作内容に応じて、第１のモード、第２のモードおよび第３のモードを含む複数のモードから前記入力工程で入力した操作要求に対応するモードを判定する判定工程と、
前記判定されたモードに基づき、前記操作要求に応じた処理を行う処理工程とを有し、
前記判定工程は、前記操作要求の操作内容が、ユーザの対話的操作に基づくものである場合には、該操作要求に対応するモードが前記第１のモードまたは前記第２のモードであると判定し、
前記処理工程は、
前記共有データに対する操作要求が発生した場合に、該操作要求を表す要求情報をサーバプロセスに送信する送信工程と、
前記送信工程によって送信された前記要求情報に対する応答情報を前記サーバプロセスより受信する受信工程と、
前記操作要求または前記受信工程で受信された応答情報に従って前記共有データを操作する操作実行工程とを有し、
前記判定工程によって前記入力した操作要求に対応するモードが前記第１のモードであると判定された場合は、前記操作実行工程が前記操作要求に応じて前記共有データを操作し、前記送信工程が該操作要求を表す要求情報を前記サーバプロセスに送信し、
前記判定工程によって前記入力した操作要求に対応するモードが前記第２のモードであると判定された場合は、
前記送信工程が、前記操作要求に応じて、該操作要求を表す要求情報を前記サーバプロセスに送信し、
前記操作実行工程は、
操作実行の期限内に、前記サーバプロセスから、前記要求情報に対する応答情報を受信した場合は、該応答情報の受信に応じて該要求情報に対する前記操作要求に応じて前記共有データを操作し、
前記操作実行の期限をすぎても、前記サーバプロセスから前記要求情報に対する応答情報を受信しなかった場合は、該要求情報に対する前記操作要求に応じて前記共有データを操作し、
前記判定工程によって前記入力した操作要求に対応するモードが前記第３のモードであると判定された場合は、
前記送信工程が、前記操作要求に応じて、該操作要求を表す要求情報を前記サーバプロセスに送信し、
前記操作実行工程は前記応答情報の受信に応じて該要求情報に対する前記操作要求に応じて前記共有データを操作する。
更に、上記の目的を達成するための本願発明による情報処理装置は以下の構成を備える。すなわち、
情報伝達媒体を介して接続された複数のクライアントプロセスによって共有される共有データを該複数のクライアントプロセスの各々が保持して利用するシステムにおいて、各クライアントプロセスが保持する共有データの同一性を維持するための情報処理装置であって、
操作要求を入力する入力手段と、
前記共有データに含まれる複数のアイテムの各々に対するモードを指定する指定情報および前記操作要求の操作内容に応じて、第１のモード、第２のモードおよび第３のモードを含む複数のモードから前記入力手段で入力した操作要求に対応するモードを判定する判定手段と、
前記判定されたモードに基づき、前記操作要求に応じた処理を行う処理手段とを有し、
前記判定手段は、前記操作要求の操作内容が、ユーザの対話的操作に基づくものである場合には、該操作要求に対応するモードが前記第１のモードまたは前記第２のモードであると判定し、
前記処理手段は、
前記共有データに対する操作要求が発生した場合に、該操作要求を表す要求情報をサーバプロセスに送信する送信手段と、
前記送信手段によって送信された前記要求情報に対する応答情報を前記サーバプロセスより受信する受信手段と、
前記操作要求または前記受信手段で受信された応答情報に従って前記共有データを操作する操作実行手段とを有し、
前記判定手段によって前記入力した操作要求に対応するモードが前記第１のモードであると判定された場合は、前記操作実行手段が前記操作要求に応じて前記共有データを操作し、前記送信手段が該操作要求を表す要求情報を前記サーバプロセスに送信し、
前記判定手段によって前記入力した操作要求に対応するモードが前記第２のモードであると判定された場合は、
前記送信手段が、前記操作要求に応じて、該操作要求を表す要求情報を前記サーバプロセスに送信し、
前記操作実行手段は、
操作実行の期限内に、前記サーバプロセスから、前記要求情報に対する応答情報を受信した場合は、該応答情報の受信に応じて該要求情報に対する前記操作要求に応じて前記共有データを操作し、
前記操作実行の期限をすぎても、前記サーバプロセスから前記要求情報に対する応答情報を受信しなかった場合は、該要求情報に対する前記操作要求に応じて前記共有データを操作し、
前記判定手段によって前記入力した操作要求に対応するモードが前記第３のモードであると判定された場合は、
前記送信手段が、前記操作要求に応じて、該操作要求を表す要求情報を前記サーバプロセスに送信し、
前記操作実行手段は前記応答情報の受信に応じて該要求情報に対する前記操作要求に応じて前記共有データを操作する。
【００１１】
【発明の実施の形態】
以下、添付の図面を参照して本発明の好適な実施形態を説明する。
【００１２】
〔第１実施形態〕
第１実施形態では、本願発明による情報処理方法を、仮想空間の構造と属性を記述するシーンデータベースを複数の端末で共有する仮想空間共有システムに応用した実現形態について説明する。
【００１３】
本実施形態の仮想空間共有システムの全体的な構成を図１に示す。システムには１つのサーバプロセス１０１（以下、「サーバ」と略す）と、複数のクライアントプロセス１０３（以下、「クライアント」と略す）があり、ネットワーク１０２を介してデータを交換する。それぞれのクライアントは共通の仮想空間の構造と属性を記述するシーンデータベースを保持する。なお、本実施形態では、ネットワーク１０２はイーサネット（登録商標）上に構築したＬＡＮである。
【００１４】
ここで、以下の説明で用いる「データベース操作」という用語について説明しておく。データベースの「操作」とは、共有データベースを持つ任意のプロセスにおけるデータベースの内容を書き換える処理のことを差す。データベース操作は「操作指令」と「操作実行」の２段階に分かれる。操作指令はデータベースの更新要求であり、実際の書き換えは行われない。データベースに対する実際の書き換えは、操作実行の段階で行われる。以下の説明では特に断らない限り、単に「操作」と記述すれば「データベース操作」のことを指すものとする。操作対象がデータベース以外の場合は、「ユーザによる対話デバイスの操作」などのように操作対象を明示するものとする。
【００１５】
なお、操作指令はユーザが発生させることもあれば、プロセスが動作の過程で発生することもある。前者の例としては、ユーザがマウスなどの対話デバイスを操作して、仮想オブジェクトを移動させた際に操作指令が発生されることが挙げられる。一方、後者の例としては、シューティングゲーム・システムにおいて、ゲームプログラムが敵キャラクタをアルゴリズム的に移動・回転させた際に操作指令が発生されること等が挙げられる。
【００１６】
さて、図２はデータベースを更新するための基本的な情報の流れを示すものである。図２で、Ａ， Ｂ， Ｃ， Ｄ（２０１〜２０４）はクライアント、Ｘ（２０５）はサーバである。いま、クライアントＡ（２０１）がシーンデータベースの操作指令を行ったとする。操作指令の内容はネットワーク経由でサーバに送信される（図２で(１)の矢印の過程）。サーバは、この操作指令を受けてクライアントＡ（２０１）から送信されたデータを、すべてのクライアントに配信する（図２で(２)の矢印の過程）。このような過程を経ることによって、非操作者のクライアントＢ（２０２）、Ｃ（２０３）、Ｄ（２０４）も操作の内容を知ることができる。
【００１７】
次に、クライアントまたはサーバプロセスが動作する端末の構成を図３に示す。図３において、３０１はＣＰＵであり、端末全体の動作を制御する。３０２はメモリであり、ＣＰＵ３０１の動作に用いるプログラムやデータを格納する。３０３はバスであり、各構成モジュール間のデータ転送を司る。３０４はバス３０３と各種装置とのインタフェースである。また、３０５はネットワークと接続するための通信部、３０６はＣＰＵ３０１に読み込むプログラムやデータを格納する外部記憶装置、３０７および３０８はプログラムを起動したり、プログラムの動作を指定するための入力装置を構成するキーボードおよびマウス、３０９はプロセスの動作結果を表示するための表示部、３１０は端末外部との入出力部である。例えば、図２７に示すスタイラス装置が接続される。
【００１８】
本実施形態のシステムは、データベースの更新タイミングに関して下記の３つのモードを持つ。以下、これらのモードを総称して「更新モード」と呼ぶ。
(１) ウェイトモード（待機モード）
(２) イミディエートモード（即時モード）
(３) ディレイモード（遅延モード）
以下、各モードの処理について詳しく説明する。
【００１９】
「ウェイトモード」は、ある操作指令に対する操作実行が、サーバからのイベントの配信を待って行われるモードである。図４は、ウェイトモードにおける時間の進行に沿った処理手順を模式的に示したものである。図４で、「操作者」は操作指令を行ったクライアント、「非操作者」は操作者以外のクライアントを指す。処理の進行は以下の説明の通りである。
【００２０】
まず、手順Ｔ４０１で操作者クライアントがデータベースの操作指令を発する。この時点では、操作者クライアントのデータベースは更新されない。次に手順Ｔ４０２にて、Ｔ４０１の操作内容を示すイベントが生成され、Ｔ４０３でサーバに送信される。サーバは手順Ｔ４０４でイベントを受信し、Ｔ４０５で当該サーバとの接続が確立しているすべてのクライアントに向けてイベントを送信する（接続の確立について図１１のステップＳ１１０２で後述する）。サーバより発行されたイベントを操作者クライアントが手順Ｔ４０６で受信し、その内容を分析して（Ｔ４０７）、データベースを書き換える（Ｔ４０８）。イベントの受信からの手順は、非操作者クライアントでも同様である（手順Ｔ４０９〜Ｔ４１１）。図４に示した通り、ウェイトモードでは、操作指令（Ｔ４０１）から操作実行（Ｔ４０８）までタイムラグがある。しかし、ネットワーク上の情報転送の条件が同様であれば、操作者・非操作者クライアントともほぼ同時刻にデータベースが更新され、仮想空間の画像がクライアント間で同期することが期待できる。
【００２１】
「イミディエートモード」は、操作者の指令が直ちにデータベースに反映され、これに対して非操作者のデータベースは遅れて更新されるものである。図５は、イミディエートモードにおける時間の進行に沿った処理手順を模式的に示したものである。処理の進行は以下の説明の通りである。
【００２２】
まず、手順Ｔ５０１で操作者クライアントがデータベースの操作指令を発する。次に、手順Ｔ５０２で操作指令の内容に従ってデータベースが更新される。この後、操作内容を示すイベントが生成され（Ｔ５０３）、サーバに送信される（Ｔ５０４）。イベント送信後、操作者クライアントでは手順Ｔ５０１の操作指令および実行が行われたことを示す情報を操作キューとして保持しておく（Ｔ５０５、「操作キュー」については後述する）。
【００２３】
サーバは手順Ｔ５０６でイベントを受信し、Ｔ５０７ですべてのクライアントに向けて当該イベントを送信する。操作者クライアントは手順Ｔ５０８でサーバからイベントを受信すると、操作キューを参照する（Ｔ５０９）。ここで、手順Ｔ５０５で記録された情報により、すでに当該操作が実行済みであることが認識されるので、操作実行処理は行わず、手順Ｔ５０５で記録された情報を削除する（Ｔ５１４）。
【００２４】
一方、非操作者クライアントでは手順Ｔ５１０で受信したイベントが未実行であることを操作キューを参照することにより認識し（Ｔ５１１）、イベントの内容に基づいて操作を実行する（Ｔ５１２, Ｔ５１３）。
【００２５】
上記のような手順でデータベースを更新すると、操作者クライアントにおいては仮想空間に対する操作の結果がＣＧ画像に反映されるまでの時間遅れがウェイトモードに比べて少なくなる。したがって、イミディエートモードは主に、ユーザが対話デバイスを用いて仮想物体を操作する場合に適している。なぜなら、一般的にユーザの対話的操作とその結果の提示の間に時間的ずれが生ずると、操作がより困難になる、ユーザに不快感を与えるなどの不具合が生じるからである。
【００２６】
「ディレイモード」は、ウェイトモードのように操作指令を直ちに実行しないものの、操作実行の期限を設けて、その期限が過ぎた場合にはサーバからのイベント返信を待たずに当該操作を実行するというものである。図６は、ディレイモードにおいて、操作実行期限に到達する前に、サーバからのイベントが到着した場合の時間の進行に沿った処理手順を模式的に示したものである。処理の進行は以下の説明の通りである。
【００２７】
まず、手順Ｔ６０１で操作者クライアントがデータベースの操作指令を発する。この時点では、データベースは更新されない。次に手順Ｔ６０２にて、Ｔ６０１の操作の内容を示すイベントが生成され、Ｔ６０３でサーバに送信される。イベント送信後、操作者クライアントでは手順Ｔ６０１の操作指令が行われたことを示す情報を操作キューに保持し（Ｔ６０４、「操作キュー」については後述する）、さらにタイマー処理を起動する（Ｔ６０５）。タイマー処理はタイムアウトを待って操作実行を行なうものであり、詳細は図１９により後述する。
【００２８】
一方、サーバは手順Ｔ６０６でイベントを受信し、Ｔ６０７ですべてのクライアントに向けてイベントを送信する。操作者クライアントは手順Ｔ６０８でイベントを受信し、操作キューを参照する（Ｔ６０９）。ここで、操作が未実行であることが認識されるので、当該操作キューに操作が実行済みであることを記録し（Ｔ６１０）、イベントの内容を分析し（Ｔ６１１）、データベースを書き換える（Ｔ６１２）。さらに、Ｔ６０４で記録された情報を削除する（Ｔ６１７）。また、非操作者クライアントでは手順Ｔ６１３で受信したイベントが未実行であることを認識し（Ｔ６１４）、イベントの内容に基づいて操作を実行する（Ｔ６１５, Ｔ６１６）。
【００２９】
一方、図７はディレイモードにおいて、サーバからのイベントが到着する前に操作実行期限（タイムアウト）に至った場合の時間の進行に沿った処理手順を模式的に示したものである。処理の進行は以下の説明の通りである。
【００３０】
まず、手順Ｔ７０１で操作者クライアントがデータベースの操作指令を発する。この時点では、データベースは更新されない。次に手順Ｔ７０２にて、Ｔ７０１の操作の内容を示すイベントが生成され、Ｔ７０３でサーバに送信される。イベント送信後、操作者クライアントでは手順Ｔ７０１の操作指令が行われたことを示す情報を操作キューに保持し（Ｔ７０４、「操作キュー」については後述する）、さらにタイマー処理を起動する（Ｔ７０５）。なお、タイマー処理はタイムアウトを待って操作実行を行なうものであり、詳細は図１９により後述する。一方、サーバは手順Ｔ７０６でイベントを受信し、Ｔ７０９ですべてのクライアントに向けてイベントを送信する。
【００３１】
タイマー処理では、サーバから対応するイベントを受信するまでの間にタイムアウト時刻に至ると、それをタイマー処理が検知し、手順Ｔ７０７で操作を実行して、操作キューに当該操作が実行済みであることを記憶する（Ｔ７０８）。したがって、操作者クライアントは、後に手順Ｔ７１０でイベントを受信するものの、操作キューを参照することにより当該操作が実行済みであることを認識し（Ｔ７１１）、操作履歴を更新する（Ｔ７１２（実行済みかつサーバプロセスから配信済みのイベントに対応する操作キューアイテムを削除））。非操作者クライアントでは手順Ｔ７１３で受信したイベントが未実行であることを認識し（Ｔ７１４）、イベントの内容に基づいて操作を実行する（Ｔ７１５, Ｔ７１６）。
【００３２】
上記のような手順でデータベースを更新すると、イベント配信のタイムラグが大きければ操作実行が極力遅れないように動作し、タイムラグが小さければクライアント間の同期を図るように動作する。このような動作の切り換えは自動的に行われ、タイムアウト時間を適宜設定することにより、どちらの動作を優勢にするか調整することができる。
【００３３】
図８は、クライアントからサーバに対して、或いはサーバからクライアントに対して発行されるイベントの内容を示したものである。イベントのデータは複数のフィールドから構成される。クライアントＩＤ８０１は、各クライアントを一意に識別するための番号で、クライアントがサーバとネットワーク接続を確立する際にサーバより割り当てられたものである（図１１のステップＳ１１０２により後述する）。操作ＩＤ８０２は操作を一意に識別するための番号で、各クライアントに操作指令を行った時点で割り当てられる。このクライアントＩＤおよび操作ＩＤの組を用いることにより、システム内部で起こったすべての操作指令を一意に特定することが可能である。
【００３４】
更新モードＩＤ８０３は、各更新モードに対して一意に決定された識別番号で、このイベントに対応する操作指令の更新モードにより決定する。更新モードはデータベースの各エントリに設定、登録されている（図２４により後述する）ので、これを参照して更新モードが設定される。エントリＩＤ８０４は、データベースの各エントリを一意に識別するための番号で、データをファイルからロードした際に割り当てられる。操作内容８０５は、操作指令の具体的内容であり、例えばＣＧオブジェクトのＸ座標をある値に設定する操作であれば、Ｘ座標属性を識別する番号とＸ座標の設定値の組で表される。
【００３５】
次に、操作キューについて説明する。操作キューは、イベントの受信または実行処理を待機している操作指令のリストである。ある時点で待機状態にある操作指令がｍ個あるとすると、操作キューは図９のように操作指令に関するｍ個の情報（キューアイテム）を指令の発生順に並べたものとなる。
【００３６】
１つのキューアイテムの内容は図１０のように、３つのデータフィールドから構成される。操作ＩＤ１００１は、操作を一意に識別するための番号で、対応するイベントの操作ＩＤフィールドと同じ値である。操作ＩＤ１００１は、クライアントにおいて操作指令を行った時点で割り当てられる。タイムアウト時刻１００２は、ディレイモードにおける操作実行期限であり、クライアントにおいて操作指令を行った時点で、現在時刻に所定のタイムアウト時間を加算して求められる。実行済みフラグ１００３は、イミディエートモードあるいはディレイモードにおいて、この操作ＩＤを持つ操作が実行済みであるかどうかを示す。実行済みフラグは、操作指令を行った時点ではＯＦＦに設定され、操作が実行された時点でＯＮに変更される。
【００３７】
なお、図１０ではフィールド数３の操作キューアイテムを示したが、実行済みフラグをとタイムアウト時刻を兼用することも可能である。この場合、タイムアウト時刻が特殊な値、例えばマイナス１、である場合に実行済みであると定義すればよい。
【００３８】
次に、クライアント、サーバのそれぞれについて、その処理の流れを詳しく説明する。
【００３９】
図１１は、クライアントの処理の全体的な流れである。クライアントが起動されると、ステップＳ１１０１にて仮想空間を記述するファイルを外部記憶装置３０６（図３）より読み込み、メモリ３０２（図３）上にシーングラフデータベースを構築する。クライアント間でのデータの同一性を維持するため、ここでロードするファイルはクライアント間で同じ内容を持つとする。次に、サーバとのネットワーク接続を確立する（ステップＳ１１０２）。このとき、サーバから各クライアントを識別するためのクライアントＩＤが付与される。なお、クライアントとサーバ間のデータ交換は、ＴＣＰ／ＩＰプロトコルを用いた１対１のソケット通信にて行う。したがって、サーバは少なくともクライアントの数だけのソケット通信路を持つことになる。
【００４０】
続いて、ステップＳ１１０３でプロセスを分岐し、操作指令を処理するための操作処理（ステップＳ１１０４）およびサーバから受信するイベントを処理するための受信イベント処理（ステップＳ１１０６）を起動する。なお、図１１には図示していないが、シーングラフデータベースを参照して、仮想空間のＣＧ画像を生成するプロセスも起動する。この処理は、公知のＣＧ画像生成方法と同様であるのでその詳細な説明は省略する。また、操作処理および受信イベント処理については、後に詳しく説明する。操作処理および受信イベント処理はそれぞれステップＳ１１０５およびステップＳ１１０７でプロセスの終了する指示があったかどうか判定され、終了指示がなければステップＳ１１０４およびステップＳ１１０６に戻って操作指令および受信イベントを継続して処理する。一方、終了指示があればステップＳ１１０８でプロセスを統合し、サーバとのネットワーク接続を切断（ステップＳ１１０９）した上で、データベースの内容を外部記憶装置（図３の３０６）にファイルとしてセーブ（ステップＳ１１１０）して、すべての処理を終了する。
【００４１】
ここで、ステップＳ１１０４の操作処理について図１２を参照して詳しく説明する。初めに、ステップＳ１２０１にて操作指令の内容を入力する。このとき、操作指令を一意に特定する操作ＩＤ番号を決定する。次に、ステップＳ１２０２およびステップＳ１２０３で、データベースのエントリを参照して更新モードを判定する。更新モードに応じて、ステップＳ１２０６のウェイトモード操作処理、ステップＳ１２０５のイミディエートモード操作処理、ステップＳ１２０４のディレイモード操作処理、のいずれかのステップを経た後、処理を終了する。以下、更新モードごとの操作処理について、図１３〜図１５を参照して詳述する。
【００４２】
図１３に、ウェイトモード操作処理の流れを示す。ステップＳ１３０１にて、ステップＳ１２０１で入力した操作の内容に基づいて、イベントデータ（図８参照）を生成する。そして、ステップＳ１３０２に進み、生成したイベントデータをサーバに向けて発信する。
【００４３】
イミディエートモード操作処理の流れは図１４に示す通りである。まず、ステップＳ１４０１にて、ステップＳ１２０１で入力した操作指令を実行する。具体的には、データベースの指定エントリの設定値を変更する。次に、ウェイトモードと同様にイベントを生成し（ステップＳ１４０２）、これをサーバに向けて発信（ステップＳ１４０３）する。最後のステップＳ１４０４で、操作ＩＤをステップＳ１２０１で決定した操作ＩＤ番号に、実行済みフラグをＯＮに、それぞれ設定した操作キューアイテムを操作キューに追加する。このとき、タイムアウト時刻は処理に用いないので、任意に設定してよい（例えば０）。
【００４４】
次に、ディレイモード操作処理について図１５を用いて説明する。まずウェイトモードと同様にイベントを生成し（ステップＳ１５０１）、これをサーバに向けて発信（ステップＳ１５０２）する。次に、操作ＩＤをステップＳ１２０１で決定した操作ＩＤ番号に、タイムアウト時刻を現在時刻に所定のタイムアウト時間を加えた値に、実行済みフラグをＯＦＦに、それぞれ設定した操作キューアイテムを操作キューに追加する（ステップＳ１５０３）。最後に、操作ＩＤ、操作内容、タイムアウト時刻のデータを渡してタイマープロセスを起動する（ステップＳ１５０４）。タイマープロセスについては、後に詳述する。
【００４５】
続いて、ステップＳ１１０６（図１１）の受信イベント処理について詳しく説明する。図１６は、受信イベント処理の流れを示した図である。受信イベントは、不図示のイベント通信部がサーバより受信し、受信イベントバッファに入力される。
【００４６】
ステップＳ１６０１では、受信イベントバッファを検索する。続くステップＳ１６０２で、受信イベントバッファにイベントが入力されているかどうか判定し、受信イベントがあればステップＳ１６０３に進む。一方、受信イベントが存在しないと判定されれば、処理を終了する。受信イベントがある場合、そのイベントデータを解析し、操作指令の内容を抽出する（ステップＳ１６０３）。次に、ステップＳ１６０４およびステップＳ１６０５でイベントの更新モードＩＤフィールドを参照して、操作指令の更新モードを判定する。そして、判定した更新モードに応じてステップＳ１６０８（ウェイトモードの場合）、ステップＳ１６０６（イミディエートモードの場合）、ステップＳ１６０７（ディレイモードの場合）のいずれかのステップを経た後、処理を終了する。ステップＳ１６０８では、イベントに記述された操作を実行する。具体的には、指定されたＩＤのエントリに関して、操作内容の通り設定値を変更する。以下、ステップＳ１６０６のイミディエートモードイベント処理、およびステップＳ１６０７のディレイモードイベント処理について、それぞれ図１７、図１８を参照して詳しく説明する。
【００４７】
イミディエートモードイベント処理の流れを図１７に示す。まず、ステップＳ１７０１にて操作キューを検索し、ステップＳ１７０２で操作キューに受信イベントに対応する操作キューアイテムが存在するかどうか判定する。具体的には、受信イベントのクライアントＩＤと本処理が動作しているクライアントのＩＤが一致し、かつ受信イベントの操作ＩＤと操作キューアイテムの操作ＩＤが一致すれば、その操作キューアイテムの操作指令と受信イベントの操作指令は対応していると判定する。イミディエートモードでは、対応するキューアイテムが存在する場合、その操作が当該クライアントで生成された時点で実行済みである。したがって、ここでは操作を実行せずに、ステップＳ１７０３で当該操作キューエントリを削除し、処理を終了する。一方、ステップＳ１７０２で対応するキューアイテムがないと判断された場合、その操作は当該クライアント以外のクライアントで生成されたものなので、まだ実行されていない。したがって、ステップＳ１７０４で当該操作を実行し、処理を終了する。
【００４８】
ディレイモードイベント処理の流れは図１８に示す通りである。まず、ステップＳ１８０１にて操作キューを検索し、ステップＳ１８０２で受信イベントに対応する操作キューアイテムが操作キューに存在するかどうか判定する。ステップＳ１８０２の処理の詳細は、ステップＳ１７０２と同様である。ここで、対応する操作キューアイテムが存在する場合は、ステップＳ１８０３で操作キューアイテムの実行済みフラグをチェックする。実行済みフラグがＯＮである場合は、タイムアウト時刻が過ぎているので、タイマープロセスが操作を実行済みである。したがって、ここでは操作を実行せず、ステップＳ１８０５にて当該操作キューエントリを削除し、処理を終了する。一方、ステップＳ１８０３にて、実行済みフラグがＯＦＦと判定された場合は、未だタイムアウト時刻に到達していないため、操作は実行されていない。そこで、ステップＳ１８０６で当該操作を実行し、操作キューより当該アイテムを削除した（ステップＳ１８０５）後、処理を終了する。また、ステップＳ１８０２にて対応する操作キューアイテムが存在しないと判定された場合、その操作は当該クライアント以外のクライアントで生成されたものなので、まだ実行されていない。そこで、ステップＳ１８０４で当該操作を実行し、処理を終了する。なお、ステップＳ１８０４と、ステップＳ１８０６は、同じ内容の処理である。
【００４９】
次に、図１５のステップＳ１５０４で起動したタイマープロセスについて図１９を用いて詳しく説明する。これは、ディレイモードにおいてタイムアウト時刻に到達した場合に対処するための処理である。
【００５０】
まず、ステップＳ１９０１で操作キューを検索し、ステップＳ１９０２でタイマープロセス起動時に指定された操作に対応する操作キューアイテムが存在するかどうか判定する。具体的には、本プロセス起動時の引数である操作ＩＤと操作キューアイテムの操作ＩＤが一致すれば、その操作キューアイテムの操作指令と引数で指定された操作指令は対応していると判定する。対応するキューアイテムが存在する場合、その操作指令に対応する受信イベントが未処理、すなわち実行されていないことを意味する。この場合は、タイムアウト時刻に到達しているかどうか確認する処理に進む。すなわち、ステップＳ１９０３で現在時刻を参照し、タイムアウト時刻との前後関係を判定する（ステップＳ１９０４）。もし、タイムアウト時刻を過ぎていれば、ステップＳ１９０５で操作を実行し、対応する操作キューアイテムの実行済みフラグをＯＮに設定する。一方、タイムアウト時刻に達していない場合は、ステップＳ１９０１に戻る。また、ステップＳ１９０２にて、対応する操作キューアイテムが存在しないと判定された場合は、その操作指令に対応する受信イベントが処理済み、すなわち当該操作は実行済みであることを意味する。この場合は、操作の実行や操作キューの変更は必要ないため、そのまま処理を終了する。
【００５１】
以上、クライアント側プロセスの流れを説明した。続いて、サーバ側プロセスの流れを図２０を用いて詳しく説明する。
【００５２】
最初にステップＳ２００１で、クライアントからの接続要求を受け付け、通信を確立する。このとき、通信を確立した各クライアントにクライアントＩＤを通知する。次に、受信イベントバッファを検索し（ステップＳ２００２）、受信イベントが存在するかどうか判定する（ステップＳ２００３）。受信イベントがあれば、ステップＳ２００４に進み、なければステップＳ２００５に進む。ステップＳ２００４では、接続している各クライアントに当該イベントを送信する。ステップＳ２００５では、ユーザからの指令（例えば、キーボードのいずれかのキーを終了ボタンとして割り当て、そのキーが押下されたことをもってユーザからの終了指令とする）などによりサーバ処理を終了するかどうかを判定し、終了する場合はステップＳ２００６に進み、終了しない場合はステップＳ２００２に戻る。ステップＳ２００６では、接続している各クライアントに処理を終了することを通知し、次にクライアントとの接続を終了して（ステップＳ２００７）から処理を終了する。
【００５３】
次に、本実施形態でクライアントが読み込むデータベース記述ファイルの構成について説明する。
【００５４】
図２４はエントリ数がＮのデータのファイルフォーマットを模式的に示したものである。各エントリの属性は、スタートデリミタおよびエンドデリミタで囲まれたフィールドに記述される。図２４で、１番目、２番目、Ｎ番目のエントリのスタートデリミタはそれぞれ２４０１、２４０６、２４０９で示されている。一方、それぞれのエンドデリミタは２４０５、２４０８、２４１１である。エントリの属性は、２４０２〜２４０４のように、各属性を識別するための識別子および属性値の組で記述される。更新モードおよびタイムアウト時間は、上記のフォーマットのファイルでエントリごとに規定されている。ただし、該当エントリの更新モードがディレイモードでない場合は、タイムアウト時間は記述しなくてもよい。また、いずれの更新モードにおいても両属性（更新モードおよびタイムアウト時間）を必ずしも記述する必要はなく、もし記述がなければ、メモリ（図３の３０２）上にシーングラフデータベースを構築する時点（ステップＳ１１０１）で、予めシステムによって決められたデフォルト値に設定される。
【００５５】
なお、上述のデータベース記述ファイルでは、選択する更新モードを記述している。これに対して、選択不可能な更新モードを１つまたは複数設定することもできる。このような選択不能な更新モードの設定の活用については、第５実施形態による更新モードの変更操作において詳述する。
【００５６】
また、上記の説明では、サーバ・クライアント間のデータ通信を１対１のＴＣＰ／ＩＰソケットにて行うとしているが、ブロードキャストあるいはマルチキャストによりイベントを交換してもよいし、通信プロトコルはＴＣＰ／ＩＰに限らない。
【００５７】
また、通信媒体としてはイーサネット（登録商標）を利用しているが、ＵＳＢやFirewireなど他の情報伝達媒体でも構わない。更に、ネットワークの形態もＬＡＮだけでなく、ＷＡＮ経由の接続でもよいし、ＬＡＮとＷＡＮを併用しても構わない。
【００５８】
また、サーバの数は、１つの共有データベースシステムにつき１つに限定する必要はなく、複数のサーバが存在してもよい。この場合、各サーバに処理を割り当てる形態は任意である。例えば、クライアントごとに異なるサーバを用いてもよいし、あるいはデータベースのエントリごとにサーバを設けてもよい。
【００５９】
更に、端末に対するプロセスの割当は１端末１プロセスに限定されるものではなく、１つの端末上で複数のプロセスを動作させることができる。その場合、プロセスの種別の組み合わせは任意であり、クライアントのみ、サーバのみ、クライアントおよびサーバの、いずれの組み合わせでもシステムは動作する。なお、同じ端末上のプロセスは、ネットワークに替えて、共有メモリを経由してデータを交換してもよい。
【００６０】
また、イベントはサーバが仲介して各端末に配信されるが、データ操作を行った端末が直接に他の端末にイベントを送信してもよい。なお、サーバを経由しない場合、例えば図４のＴ４０６において、操作クライアントは自分自身からイベントを受け取ることになる。これは、イベントの送信宛て先を自ホストに設定することにより実現できる。なお、自ホストと他ホストを区別せずに通信する機能は主要なＯＳには標準的に備わっているものである。
【００６１】
また、上記の説明では、３次元仮想空間データを共有するとしているが、データベースの内容はこれに限らず任意であることはいうまでもない。また、データベース全体を共有する場合のみならず、その一部のみを共有する場合にも上記実施形態で説明した方法が適用可能であることはいうまでもない。これらの特徴は、以下の実施形態についても同様である。
【００６２】
以上のように第１実施形態によれば、情報伝達媒体を介して接続された複数のプロセス（クライアントプロセス）によって共有される共有データ（データベース）を該複数のプロセスの各々が保持して利用するシステムにおいて、各プロセスが保持する共有データの同一性を維持するための情報処理方法が開示される。特に、共有データに対する操作要求が発生した場合には、該操作要求を表す要求情報（イベント）が情報伝達媒体上に出力され、この要求情報に対する応答情報（イベント）を情報伝達媒体より受信し、受信した応答情報に従って共有データに対する操作を実行する。このようなウェイトモードによれば、共有データに対する操作が情報伝達媒体を介して受信されるイベントに従って実行されるので、共有データの更新タイミングを高精度に一致させることができる。
【００６３】
また、ディレイモードでは、タイマー処理により、応答情報を受信する前に操作要求の発生から所定時間が経過した場合には、該応答情報の受信を待たずに当該操作要求に基づく共有データの操作が実行される。このため、操作が発生したプロセスにおける応答性と複数プロセス間の同期タイミングの一致の両立を図ることができる。
【００６４】
また、本実施形態によれば、操作要求に応じて操作キューにキューアイテムを登録し、操作実行工程によって共有データに対する操作が実行された場合に対応するキューアイテムを処理済とするキュー制御を行い、操作キューにおいて応答情報が表す操作要求に対応するアイテムが処理済となっていない場合に、応答情報に対応する操作を共有データに対して実行する。上述のようなディレイモードにおいて、操作実行が重複することを簡易な構成で防止できる。
【００６５】
また、上記実施形態によれば、受信工程によって応答情報が受信されるのを待って共有データの操作を実行する第１モード（ウェイトモード）と、操作要求の発生からの所定時間の経過と、応答情報の受信の何れかの早い方のタイミングで共有データの操作を実行する第２モード（ディレイモード）を含む複数の変更モードのいずれかで動作することが可能である。
【００６６】
そして、共有データは複数のアイテムで構成され（図２４）、複数のアイテムの各々は採用すべき変更モードを指定する指定情報を含む。変更モードはこの指定情報に従って選択され、共有データへの操作が実行されることになる。すなわち、複数のアイテム毎に変更モードが切り換えられることになり、この構成によれば、アイテム毎に適切な変更モードを設定できる。
【００６７】
また、サーバプロセスにおいては、情報伝達媒体を介して接続された複数のプロセスによって共有される共有データを該複数のプロセスの各々が保持して利用するシステムにおいて、各プロセスが保持する共有データの同一性を維持するために、複数のクライアントプロセスとの接続を確立し、これら複数のクライアントプロセスより共有データの変更に関るイベントを受信する。そして、受信したイベントを、上記複数のクライアントプロセスに対して発行する。
【００６８】
〔第２実施形態〕
第１実施形態では、すべての更新モードにおいて、サーバがすべてのイベントをすべてのクライアントに配信している。しかしながら、イミディエートモードの場合には、操作者クライアントは操作を実行済みであり、サーバからイベントを受信する必要はない。本実施形態では、このような場合にサーバからのイベントの配信を省略するものである。
【００６９】
本実施形態におけるイベント配信処理の流れを図２１に示す。この処理は、図２０のステップＳ２００４に替えて実行されるべきものである。
【００７０】
まず、ステップＳ２１０１にて、更新モードがイミディエートモードかどうか判定する。もし、イミディエートモードであれば、イベントのクライアントＩＤフィールドを参照して、そのＩＤ以外のクライアントに対してイベントを送信する（ステップＳ２１０２）。一方、更新モードがウェイトモードあるいはディレイモードの場合は、第１実施形態と同様にすべてのクライアントに対してイベントを送信する（ステップＳ２１０３）。イベント発行元のクライアントプロセスには、サーバプロセスからイベントが配信されないため、操作キューの参照および更新処理が不要となる。
【００７１】
以上のように第２実施形態によれば、サーバプロセスによって受信されるイベントが共有データの変更手順を示す変更モード情報を含み、サーバはこの変更モード情報に基づいて当該イベントの配信先を制御する。例えば、受信したイベントの変更モード情報に基づいて当該イベントの発行元において共有データの処理が既に完了しているか判定し、完了していると判定された場合には、当該インベントをその発行元のクライアントへは発行しないように制御する。図２１に示すように、変更モードがイミディエートモードの場合は、イベントを受信した時点で発行元のクライアントプロセスにおける操作実行は完了しているので、当該発行元クライアントプロセスへはイベントの配信を行なわない。
【００７２】
上記の処理を行うことにより、サーバからクライアントに送信するイベントの総量が減るので、ネットワーク負荷を軽減することができる。また、イベント発行元のクライアントプロセスは、操作キューの処理が不要となるので、処理負荷を軽減することができる。
【００７３】
〔第３実施形態〕
第１実施形態および第２実施形態では、更新モードがディレイモードの場合に、サーバが受信したイベントはタイムアウト時刻に関係なくクライアントに送信されている。しかしながら、タイムアウト時刻を過ぎると、操作者クライアントはイベントが返信されなくとも操作を実行するので、サーバからイベントを受信する必要はない。第３実施形態は、このような場合にイベントの配信を省略するものである。
【００７４】
第３実施形態の場合には、図８のイベントの内容に替えて、図２２の内容のイベントを用いる。これは、図８のイベントにタイムアウト時刻が追加されたものである。このタイムアウト時刻は、操作指令が生成された時刻にタイムアウト時間を加えたものであり、操作者クライアントにおいてタイマー処理が操作実行を開始する判定基準とする時刻に等しい。
【００７５】
第３実施形態におけるイベント配信処理の流れを図２３に示す。この処理は、図２０のステップＳ２００４に替えて実行されるべきものである。
【００７６】
まず、ステップＳ２３０１にて、更新モードがディレイモードかどうか判定する。もし、ディレイモードであれば、現在時刻を参照し（ステップＳ２３０２）、現在時刻とイベントに記述されたタイムアウト時刻の前後関係を判定する（ステップＳ２３０４）。もし、現在時刻がタイムアウト時刻よりも後ならば、発信者クライアントでは操作の実行を開始していると見なされる。したがって、イベントのクライアントＩＤフィールドを参照して、そのＩＤ以外のクライアントに対してイベントを送信する（ステップＳ２３０５）。一方、更新モードがディレイモード以外の場合や、タイムアウト時刻に到達していない場合は、ステップＳ２３０６に進んで、すべてのクライアントにイベントを送信する。
【００７７】
上記の処理を行うことにより、サーバからクライアントに送信するイベントの総数が減るので、ネットワーク負荷を軽減することができる。
【００７８】
なお、イベントのタイムアウト時刻とサーバの現在時刻を比較して、正確な前後関係を求めるには、クライアントとサーバの現在時刻が一致していなければならない。このための仕組みとしては、例えばＮＴＰ (Network Time Protocol)などが利用できる。
【００７９】
以上のように、第３実施形態は、変更モードがディレイモードであった場合に、イベントの発行元クライアントプロセスで操作実行が完了しているかを判断可能とするしくみを提供する。すなわち、イベントにタイムアウト時刻を含ませ、変更モード情報がタイムアウト時刻の経過によって操作が実行される変更モード（ディレイモード）であることを示し、且つ、現在時刻がタイムアウト時刻を過ぎている場合に、当該イベントの発行元において共有データの処理が既に完了していると判定する。
【００８０】
以上のように、第２および第３実施形態では、端末間で交換されるデータベース更新情報が一部省略されるので、ネットワークへの負荷が軽減される。
【００８１】
〔第４実施形態〕
第２実施形態はイミディエートモード、第３実施形態はディレイモードにおけるイベント配信処理であるが、これらを併用することも可能である。
【００８２】
すなわち、第４実施形態では、第２および第３実施形態におけるネットワーク負荷の軽減方法を併用するものである。
【００８３】
〔第５実施形態〕
上述の各実施形態では、更新モードがデータベース記述ファイルで設定されており、システムの稼働中に更新モードを変更することは考慮されていない。第５実施形態では、データベースの更新モードを変更する手段を有するデータベース更新方法について説明する。
【００８４】
図２５は、本実施形態におけるクライアントの画面表示例を示したものである。第１実施形態と同様に、データベースの内容は３次元仮想空間であり、表示ウィンドウ２５０１中の３次元空間表示部２５０２に、３次元仮想物体２５０３および２５０４のＣＧ画像が表示されている。３次元表示部の下部には、仮想物体の位置、姿勢および更新モードを設定するための、位置設定部２５０６、姿勢設定部２５０７および更新モード設定部２５０８が設けられている。更新モード設定部２５０８には、各更新モードに対応したラジオボタンが表示されている。
【００８５】
更新モードを設定する際には、まずカーソル２５０５をモードを変更したい仮想物体像の上に移動してマウス３０８（図３）の左ボタンをクリックすることにより、その物体を選択する。このとき、その物体に設定されている更新モードに対応したラジオボタンが選択表示される。次に、更新モード設定部にあるラジオボタンのうち、所望のモードに対応するものをマウスの左ボタンでクリックして有効にする。このように、ユーザの対話的操作によって、モードをユーザの希望に応じて設定することができる。なお、位置設定部２５０６および姿勢設定部２５０７には、スライダが表示されており、これを操作することによって選択した仮想物体の位置および姿勢を対話的に変更することができる。
【００８６】
図２６は、別の表示例及びユーザインターフェース例を示したものである。ここでは、ユーザがＨＭＤ（Head Mounted Display）を頭部に装着し、図２６のような仮想空間の３次元表示画面２６０１を観察している。画面中で、２６０２および２６０３は仮想物体、２６０４は物体を選択・操作するためのポインタである。ユーザは図２７に示すようなスタイラス装置２７０１を手に持ち、これを動かすことによりポインタ２６０４の位置や姿勢を制御する。なお、スタイラス装置は、指し棒のような形状を有し、位置姿勢センサとボタンを備えている。例えば、ボタンを押した時点での棒の先端部の位置・姿勢を計測するという目的で使用される。
【００８７】
更新モードを変更する際には、まずポインタ２６０４がモードを変更したい仮想物体像を指すようにスタイラス装置２７０１を動かして、スタイラス装置２７０１上の選択ボタン２７０２を押下することにより、その物体を選択する。このとき、ユーザが観察する画面上には選択した物体の属性を表すアノテーション表示２６０５が現れる。アノテーション表示の中には、現在選択されている更新モードも記されている。次に、スタイラス装置の端部に設けられたダイヤル２７０３を回転させる。回転に従って、アノテーション表示の更新モードが入れ替わるので、所望のモードが表示された時点でダイヤル２７０３の回転を止める。このように、ユーザの対話的操作によって、モードをユーザの希望に応じて設定することができる。なお、ＨＭＤは表示部３０９（図３）に相当するものである。また、スタイラス装置２７０１は入出力部３１０とデータ伝送ケーブル２７０４を介して接続し、ＣＰＵ３０１が選択ボタン２７０２の選択状態・ダイヤル２７０３の回転状態を読み出す。
【００８８】
また、図２５や図２６のように仮想空間を３次元表示するのに替えて、２次元表示を用いてもよい。図２８は２次元表示の例である。この例では、表示ウィンドウ２８０１の中の２次元表示部２８０２に、３次元空間をある方向から観察した様子が平面状に表示されている。２次元表示部の中には、仮想物体２８０３および２８０４がアイコンで表示され、カーソル２８０５をアイコン上に置いてマウス３０８の左ボタンをクリックすることにより、物体を選択できる。更新モードを設定する際には、物体を選択した後、所望の更新モードに対応してシステムで設定されているキーボード３０７の特定キーを押下する。このように、ユーザの対話的操作によって、更新モードをユーザの希望に応じて設定することができる。なお、物体を選択した際に、画面上に選択した物体の属性を表すアノテーション表示２８０６を表示してもよい。アノテーション表示の中に、現在選択されている更新モードも記せば、現在の更新モードを確認しながら更新モードの設定操作を行うことができる。
【００８９】
以上、更新モードの設定方法を３例説明した。ただし、上述のいずれの更新モード設定方法においても、選択不可能な更新モードが指定されていれば、ユーザがそのモードを選択しようとしても、実際に変更されないように構成してもよい。
【００９０】
なお、更新モードは共有データベースのエントリがもつ属性なので、あるクライアントが更新モードを変更した場合、その変更が他のクライアントにも反映されることになる。すなわち、更新モードの変更も操作指令の一つとして扱われ、イベントによって各端末に反映される。
【００９１】
一方、更新モードの設定をクライアント間で共有せず、各クライアントごとに設定できるようにすることも可能である。その場合の操作処理の流れを図２９に示す。これは、図１２の処理に替えて用いるものである。
【００９２】
図２９の処理では、ステップＳ２９０１にて操作指令を入力した後、ステップＳ２９０２において、入力された操作指令がモード設定であるかどうか判定する。モード設定であると判定された場合は、ステップＳ２９０３に進み、指定のエントリに関する更新モードの属性値を操作指令に従って設定する。その他のステップＳ２９０４、Ｓ２９０５、Ｓ２９０６、Ｓ２９０７およびＳ２９０８は、それぞれ図１２のステップＳ１２０２、Ｓ１２０３、Ｓ１２０４、Ｓ１２０５およびＳ１２０６と同様である。
【００９３】
以上のように第５実施形態によれば、共有データ中の所望のアイテム（図２４のエントリ）に対応するオブジェクト表示を選択して所望の変更モードを指定するユーザインターフェースが提供される（図２５等）。このユーザインターフェースにより、アイテム毎に更新モードを所望に設定できる。
【００９４】
また、更新モードの設定操作によるモードの切り換えは、複数のクライアントの共有データに反映されるように構成してもよいし、当該クライアントの共有データのみに反映されるようにしてもよい。更に、更新モードの設定（切り換え結果）を共有する／しないを設定可能としてもよい。
【００９５】
〔第６実施形態〕
第５実施形態では更新モードを変更する手段を説明したが、タイムアウト時間を変更する手段を追加することも可能である。第６実施形態では、タイムアウト時間が変更可能である実施形態を示す。
【００９６】
例えば、図２５の表示画面にタイムアウト時間を調整するスライダを追加したり、図２７のスタイラス装置にタイムアウト時間を設定するダイヤルを装備することで実施できる。あるいは、キーボード３０７の所定のキーを押下すると、タイムアウト時間を加算、減算するように構成してもよい。
【００９７】
いうまでもなく、更新モードの変更手段およびタイムアウト時間の変更手段のうち、どちらか片方を備えてもよいし、両方を備えてもよい。
【００９８】
〔第７実施形態〕
上述の実施形態では、データベースのエントリごとに更新モードおよびタイムアウト時間を設定しているが、クライアントごとに更新モードやタイムアウト時間を設定可能としてもよい。また、データベースのエントリの属性ごとに更新モードやタイムアウト時間を設定できるようにすることも可能である。
【００９９】
〔第８実施形態〕
データベースシステムによっては、データを更新する処理と、データを参照する処理が一定の順序で行われるものがある。このような場合には、ある操作指令から実行までに時間遅れがあるとしても、いずれかのデータ更新過程で実行が完了すれば、その直後の参照には操作の結果が反映される。
【０１００】
一般的に、仮想空間の描画システムも上記のようなシステムの１つであり、シーングラフの更新と、シーンの描画が交互に起こる。図３０は、これを概念的に示したもので、"Update"が更新過程、"Draw"が描画過程を表している。ここで、更新過程と描画過程の組をフレームと呼ぶ。
【０１０１】
ここで、操作指令に対する結果がデータベースに反映されるまでの遅れに関して、要求仕様が２フレーム未満であるとする。いま、Ｓ番目のフレームの時刻ｔ１に１つの操作指令が発生したとする。その操作が時刻ｔ３までに実行されれば、要求仕様を満たしているといえる。これを実現するためには、例えばタイムアウト時刻をｔ２として操作指令をディレイモードで処理すればよい。しかしながら、一般的には時刻ｔ２を推定することは困難である。
【０１０２】
そこで、第８の実施形態では、操作指令を実行するタイミングを自動的に決定することが可能な実施形態を示す。
【０１０３】
上述したタイマー処理（図１９）でタイムアウト時刻を確認するためのステップＳ１９０３およびステップＳ１９０４に替えて、データベース更新過程の到来を検知する処理を加える。その処理で、更新過程の到来を検知したらステップＳ１９０５に進み、更新過程が到来していなければステップＳ１９０１に戻る。なお、更新過程の到来を検知するのではなく、図３０の更新過程を開始した時点で、タイマープロセスに割り込みを掛けて、ステップＳ１９０５に移行させてもよい。
【０１０４】
以上のように第８実施形態によれば、応答情報を受信する前にシステムが定める更新過程の開始時刻に達した場合には、該応答情報の受信を待たずに前記操作要求に基づく前記共有データの操作が実行される。すなわち、タイムアウトのタイミングが自動的に設定され、所望の遅れ時間で操作指令を実行させることが可能になる。
【０１０５】
〔第９実施形態〕
上述の第５実施形態では、更新モードをすべてマニュアルで設定している。これに対し第９の実施形態では、更新モードを自動的に設定する実施形態を示す。本実施形態では、操作指令がユーザの対話的操作に基づくものである場合には、自動的にイミディエートモードあるいはディレイモードに設定する。
【０１０６】
これを実現するためには、対話的操作が行われた場合、操作指令を生成する処理の前に、更新モードをイミディエートモードあるいはディレイモードに設定する指令を加える処理を追加すればよい。このとき、イミディエートモードとディレイモードのどちらを設定するかは、対話的操作の種類ごとに予め決めておく。たとえば、図２５のスライダや図２７のスタイラスにより仮想物体を移動・回転する場合は、イミディエートモードに設定する。一方、マウスクリックや選択ボタン（図２７の２７０２）の押下により物体を選択する場合は、ディレイモードに設定する。
【０１０７】
以上のように、第９実施形態によれば、共有データのアイテムに対応するオブジェクトに対する操作内容に応じて変更モードが設定される。例えば、更新モードが自動的にイミディエートモードあるいはディレイモードに設定されるので、対話的操作の指令から操作実行までの時間遅れをウェイトモードに比べて少なくすることが可能であり、遅れに起因する不快感が軽減される。
【０１０８】
なお、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【０１０９】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１１０】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０１１１】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１２】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１３】
【発明の効果】
以上説明したように、本発明によれば、複数のプロセスで共有される共有データに関して、操作を実行するタイミングを高精度に一致させることが可能となる。
【図面の簡単な説明】
【図１】第１実施形態におけるデータベース共有システム全体の構成を示すブロック図である。
【図２】第１実施形態によるプロセス間の基本的な情報伝達方法を示す図である。
【図３】第１実施形態による端末装置のハードウエア構成を示すブロック図である。
【図４】ウェイトモードにおけるデータベースの更新手順を示す図である。
【図５】イミディエートモードにおけるデータベースの更新手順を示す図である。
【図６】ディレイモード（非タイムアウト時）におけるデータベースの更新手順を示す図である。
【図７】ディレイモード（タイムアウト時）におけるデータベースの更新手順を示す図である。
【図８】イベントデータのデータ構成例を示す図である。
【図９】操作キューのデータ構成例を示す図である。
【図１０】操作キューアイテムのデータ構成例を示す図である。
【図１１】第１実施形態によるクライアントプロセスのフローチャートである。
【図１２】クライアントプロセスにおける操作処理を示すフローチャートである。
【図１３】図１２のウェイトモード操作処理を説明するフローチャートである。
【図１４】図１２のイミディエートモード操作処理を説明するフローチャートである。
【図１５】図１２のディレイモード操作処理を説明するフローチャートである。
【図１６】図１１のクライアントプロセスにおける受信イベント処理を示すフローチャートである。
【図１７】図１６のイミディエートモード受信イベント処理のフローチャートである。
【図１８】図１６のディレイモード受信イベント処理のフローチャートである。
【図１９】タイマープロセスを説明するフローチャートである。
【図２０】第１実施形態によるサーバプロセスを説明するフローチャートである。
【図２１】第２実施形態におけるサーバのイベント配信処理を説明するフローチャートである。
【図２２】第３実施形態におけるイベントデータのデータ構成例を示す図である。
【図２３】第３実施形態におけるサーバのイベント配信処理を説明するフローチャートである。
【図２４】データベースの記述ファイルフォーマットを示す図である。
【図２５】第５実施形態におけるクライアント表示画面の一例を示す図である。
【図２６】第５実施形態におけるクライアント表示画面の一例を示す図である。
【図２７】第５実施形態におけるスタイラス装置の外観と構成を示す図である。
【図２８】第５実施形態におけるクライアント表示画面の一例を示す図である。
【図２９】第５実施形態における操作処理を説明するフローチャートである。
【図３０】第８実施形態におけるタイムアウト時刻の設定方法を示す概念図である。

Claims (6)

1. 情報伝達媒体を介して接続された複数のクライアントプロセスによって共有される共有データを該複数のクライアントプロセスの各々が保持して利用するシステムにおいて、各クライアントプロセスが保持する共有データの同一性を維持するための情報処理方法であって、
   操作要求を入力する入力工程と、
   前記共有データに含まれる複数のアイテムの各々に対するモードを指定する指定情報および前記操作要求の操作内容に応じて、第１のモード、第２のモードおよび第３のモードを含む複数のモードから前記入力工程で入力した操作要求に対応するモードを判定する判定工程と、
   前記判定されたモードに基づき、前記操作要求に応じた処理を行う処理工程とを有し、
   前記判定工程は、前記操作要求の操作内容が、ユーザの対話的操作に基づくものである場合には、該操作要求に対応するモードが前記第１のモードまたは前記第２のモードであると判定し、
   前記処理工程は、
   前記共有データに対する操作要求が発生した場合に、該操作要求を表す要求情報をサーバプロセスに送信する送信工程と、
   前記送信工程によって送信された前記要求情報に対する応答情報を前記サーバプロセスより受信する受信工程と、
   前記操作要求または前記受信工程で受信された応答情報に従って前記共有データを操作する操作実行工程とを有し、
   前記判定工程によって前記入力した操作要求に対応するモードが前記第１のモードであると判定された場合は、前記操作実行工程が前記操作要求に応じて前記共有データを操作し、前記送信工程が該操作要求を表す要求情報を前記サーバプロセスに送信し、
   前記判定工程によって前記入力した操作要求に対応するモードが前記第２のモードであると判定された場合は、
   前記送信工程が、前記操作要求に応じて、該操作要求を表す要求情報を前記サーバプロセスに送信し、
   前記操作実行工程は、
   操作実行の期限内に、前記サーバプロセスから、前記要求情報に対する応答情報を受信した場合は、該応答情報の受信に応じて該要求情報に対する前記操作要求に応じて前記共有データを操作し、
   前記操作実行の期限をすぎても、前記サーバプロセスから前記要求情報に対する応答情報を受信しなかった場合は、該要求情報に対する前記操作要求に応じて前記共有データを操作し、
   前記判定工程によって前記入力した操作要求に対応するモードが前記第３のモードであると判定された場合は、
   前記送信工程が、前記操作要求に応じて、該操作要求を表す要求情報を前記サーバプロセスに送信し、
   前記操作実行工程は前記応答情報の受信に応じて該要求情報に対する前記操作要求に応じて前記共有データを操作することを特徴とする情報処理方法。
2. さらに、所望のアイテムに対応するオブジェクト表示を選択して所望のモードを指定するためのユーザインターフェースを提供することを特徴とする請求項１に記載の情報処理方法。
3. 前記ユーザインターフェースによって選択されたモードが、前記複数のクライアントの共有データに反映されることを特徴とする請求項２に記載の情報処理方法。
4. 前記操作実行の期限を設定する設定工程を更に備えることを特徴とする請求項１に記載の情報処理方法。
5. 情報伝達媒体を介して接続された複数のクライアントプロセスによって共有される共有データを該複数のクライアントプロセスの各々が保持して利用するシステムにおいて、各クライアントプロセスが保持する共有データの同一性を維持するための情報処理装置であって、
   操作要求を入力する入力手段と、
   前記共有データに含まれる複数のアイテムの各々に対するモードを指定する指定情報および前記操作要求の操作内容に応じて、第１のモード、第２のモードおよび第３のモードを含む複数のモードから前記入力手段で入力した操作要求に対応するモードを判定する判定手段と、
   前記判定されたモードに基づき、前記操作要求に応じた処理を行う処理手段とを有し、
   前記判定手段は、前記操作要求の操作内容が、ユーザの対話的操作に基づくものである場合には、該操作要求に対応するモードが前記第１のモードまたは前記第２のモードであると判定し、
   前記処理手段は、
   前記共有データに対する操作要求が発生した場合に、該操作要求を表す要求情報をサーバプロセスに送信する送信手段と、
   前記送信手段によって送信された前記要求情報に対する応答情報を前記サーバプロセスより受信する受信手段と、
   前記操作要求または前記受信手段で受信された応答情報に従って前記共有データを操作する操作実行手段とを有し、
   前記判定手段によって前記入力した操作要求に対応するモードが前記第１のモードであると判定された場合は、前記操作実行手段が前記操作要求に応じて前記共有データを操作し、前記送信手段が該操作要求を表す要求情報を前記サーバプロセスに送信し、
   前記判定手段によって前記入力した操作要求に対応するモードが前記第２のモードであると判定された場合は、
   前記送信手段が、前記操作要求に応じて、該操作要求を表す要求情報を前記サーバプロセスに送信し、
   前記操作実行手段は、
   操作実行の期限内に、前記サーバプロセスから、前記要求情報に対する応答情報を受信した場合は、該応答情報の受信に応じて該要求情報に対する前記操作要求に応じて前記共有データを操作し、
   前記操作実行の期限をすぎても、前記サーバプロセスから前記要求情報に対する応答情報を受信しなかった場合は、該要求情報に対する前記操作要求に応じて前記共有データを操作し、
   前記判定手段によって前記入力した操作要求に対応するモードが前記第３のモードであると判定された場合は、
   前記送信手段が、前記操作要求に応じて、該操作要求を表す要求情報を前記サーバプロセスに送信し、
   前記操作実行手段は前記応答情報の受信に応じて該要求情報に対する前記操作要求に応じて前記共有データを操作することを特徴とする情報処理装置。
6. 請求項１乃至４のいずれか１項に記載の情報処理方法をコンピュータに実行させるための制御プログラム。

Images