(57)【要約】【課題】複数のプロセスで共有される共有データに対して行われる操作において、先に発行された操作指令が実行された上で後の操作指令が発行されることを保証する。【解決手段】ネットワークを介して接続された複数のプロセスによって共有される共有データを該複数のプロセスの各々が保持して利用するシステムにおいて、各プロセスが保持する共有データの同一性が維持される。共有データに対する操作要求が発生すると、操作要求を表す操作イベントが発行される（Ｔ２５０１）。また、ユーザの所定操作によって消化イベントが発行される（Ｔ２５０３）。発行された操作イベントに応答する操作イベントがサーバから受信されると、この操作イベントに従って共有データへの操作が実行される。このとき、上記消化イベントの発行後、上記発行した消化イベントに対応する消化イベントが受信される（Ｔ２５０６）までの間、操作要求に基づく操作イベントの発行が禁止される。【選択図】図２２
2004265063.tif 000002
【特許請求の範囲】
【請求項１】
情報伝達媒体を介して通信可能な複数のプロセスによって共有される共有データを該複数のプロセスの各々が保持して利用するシステムにおいて、各プロセスが保持する共有データの同一性を維持するための情報処理方法であって、
前記共有データに対する操作要求が発生した場合に、該操作要求を表す操作イベントを前記情報伝達媒体上に発行する第１発行工程と、
所定のユーザ操作に応じて発行禁止イベントを発行する第２発行工程と、
前記第１発行工程によって発行された操作イベントに応答する応答操作イベントを外部より受信し、前記共有データへの操作を実行する操作実行工程と、
前記第２発行工程による発行禁止イベントの発行後、該発行禁止イベントに対応したイベントを受信するまで、前記第１及び第２発行工程によるイベントの発行を禁止する禁止工程とを備えることを特徴とする情報処理方法。
【請求項２】
前記第２発行工程は、操作禁止イベントとして消化イベントを発行し、
前記禁止工程は、前記消化イベントの発行から該消化イベントに応答するイベントを受信するまでの間、前記第１及び第２発行工程によるイベントの発行を禁止することを特徴とする請求項１に記載の情報処理方法。
【請求項３】
前記第２発行工程は、操作禁止イベントとして同期イベントを発行し、
前記禁止工程は、自身の発行した同期イベントと他のクライアントより発行された同期イベントに対応するイベントの受信状態に基づいてイベントの発行禁止を解除することを特徴とする請求項１に記載の情報処理方法。
【請求項４】
前記禁止工程は、受信された同期イベントの数が所定数に達した場合にイベントの発行禁止を解除することを特徴とする請求項３に記載の情報処理方法。
【請求項５】
前記同期イベントの数を設定する設定工程を更に備えることを特徴とする請求項４に記載の情報処理方法。
【請求項６】
前記操作イベントは制限時間を有し、前記操作実行工程は、該操作イベントが未実行のまま前記制限時間を経過した場合には該操作イベントに対応する操作を実行し、前記禁止工程はこれに応じて禁止状態を解除することを特徴とする請求項１乃至５のいずれかに記載の情報処理方法。
【請求項７】
前記禁止工程によって操作イベントの発行が禁止されている間に操作要求が発生した場合、該操作要求をキューに保持する保持工程と、
前記第１及び第２発行工程は、前記禁止工程による禁止が解除された場合に、前記キューに保持されている操作要求に対応した操作イベントもしくは操作禁止イベントを前記情報伝送媒体に発行することを特徴とする請求項１乃至６のいずれかに記載の情報処理方法。
【請求項８】
情報伝達媒体を介して通信可能な複数のプロセスによって共有される共有データを該複数のプロセスの各々が保持して利用するシステムにおいて、各プロセスが保持する共有データの同一性を維持するための情報処理装置であって、
前記共有データに対する操作要求が発生した場合に、該操作要求を表す操作イベントを前記情報伝達媒体上に発行する第１発行手段と、
所定のユーザ操作に応じて発行禁止イベントを発行する第２発行手段と、
前記第１発行手段によって発行された操作イベントに応答する応答操作イベントを外部より受信し、前記共有データへの操作を実行する操作実行手段と、
前記第２発行手段による発行禁止イベントの発行後、該発行禁止イベントに対応したイベントを受信するまで、前記第１及び第２発行手段によるイベントの発行を禁止する禁止手段とを備えることを特徴とする情報処理装置。
【請求項９】
請求項１乃至７のいずれかに記載の情報処理方法をコンピュータに実行させるための制御プログラム。
【請求項１０】
請求項１乃至７のいずれかに記載の情報処理方法をコンピュータに実行させるための制御プログラムを格納した記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数のプロセス間でデータを共有する技術に関する。特に３次元仮想空間を記述するデータを保持するデータベースをネットワークを介して複数のプロセス間で共有させるのに好適な技術に関する。
【０００２】
【従来の技術】
異なるコンピュータ端末間で３次元仮想空間を共有する技術は、遠隔会議システム、ネットワーク型対戦ゲーム、協調型デザインシステムなどを実現するために必須である。
【０００３】
このような３次元仮想空間を共有するシステムでは、仮想空間の動画像をコンピュータグラフィクスにより描画するために、短い時間間隔で多量のデータを参照する。このとき、一つの装置（例えばサーバ）に保持されている仮想空間のデータの全体をネットワークを介して取得することは、現在のネットワークのバンド幅の狭さから現実的ではない。したがって、各々の端末が仮想空間データのコピーを持ち、それを参照することによってＣＧ画像を生成する方式が採用されている。また、あるコンピュータ端末上で仮想空間に対する何らかの操作、例えば仮想物体の移動や回転が行われた場合には、その操作に関する情報が他の端末にネットワーク経由で伝送され、各端末の持つデータベースに反映される。この結果、各コンピュータ端末におけるデータベースの同一性が保たれる。
【０００４】
一般的な仮想空間共有システムにおける上述のデータベースの同一性保持の手順の詳細は次のとおりである。すなわち、あるコンピュータ端末における仮想空間に対する操作が当該端末のローカルのデータベースに直ちに反映されるとともに、当該操作情報が他のコンピュータ端末に送信される。他の端末は、この操作情報を受信し、受信した操作情報に従ってデータを更新する。
【０００５】
このような仮想空間共有システムの実現例として、非特許文献１に記載されたものが挙げられる。
【０００６】
しかし、非特許文献１に代表される仮想空間共有システムでは、操作を行なった端末においてその操作内容が当該端末のデータベースに即座に反映され、他の端末はその操作情報を受信してからデータベースの更新が行なわれる。従って、操作を行った端末とそれ以外の端末とでデータベースを更新するタイミングが異なってしまう。特に、ネットワーク上のトラフィックの影響等で、操作情報の受信までに時間がかかると、端末間のデータベースの更新のタイミングのズレは顕著となる。このため、端末間で仮想空間の描画結果に違いが生ずる可能性があるという課題が指摘されている。また、データベースの操作および更新の手順は上記の如き手順に固定されており、データ更新のタイミングを選択あるいは調整することができないという課題も指摘されていた。
【０００７】
これに対し、複数のプロセスで共有されるデータベースに関して、操作を実行するタイミングをほぼ同一とするシステムが提案されている。このシステムでは、端末とは別に共有データベースの同一性を維持するためのサーバを設け、各端末は共有データベースの変更に関する操作指令を発行し、それに対応するイベントをサーバに対して送信する。一方、サーバは端末から送信されたイベントを受信し、サーバに接続されている複数の端末に対して当該イベントを送信する。各端末はサーバから受信したイベントの操作情報に基づき、当該端末が保持するデータベースを更新する。すなわち、各端末はサーバから送信されるイベントの受信をトリガとして保持しているデータベースを更新するため、操作を実行するタイミングを揃えることができるものである。
【０００８】
【非特許文献１】
Ｄｉｓｔｒｉｂｕｔｅｄ  Ｏｐｅｎ  Ｉｎｖｅｎｔｏｒ（出展：Ｇ．Ｈｅｓｈｉｎａ  ｅｔ．ａｌ．  ：  ”Ｄｉｓｔｒｉｂｕｔｅｄ  Ｏｐｅｎ  Ｉｎｖｅｎｔｏｒ  ：  Ａ  Ｐｒａｃｔｉｃａｌ  Ａｐｐｒｏａｃｈ  ｔｏ  Ｄｉｓｔｒｉｂｕｔｅｄ  ３Ｄ  Ｇｒａｐｈｉｃｓ”，  ｉｎ  Ｐｒｏｃ．  ｏｆ  ｔｈｅ  ＡＣＭ  Ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｖｉｒｔｕａｌ  Ｒｅａｌｉｔｙ  Ｓｏｆｔｗａｒｅ  ａｎｄ  Ｔｅｃｈｎｏｌｏｇｙ  （ＶＲＳＴ’９９），  ｐｐ．７４−８１，  １９９９）
【０００９】
【発明が解決しようとする課題】
しかしながら、上述したシステムでは、操作を実行するタイミングはほぼ同一となるが、端末がデータベースの変更に関する操作指令を発行してから、当該操作指令に対応するイベントが他の各端末に波及し、各端末上で操作が実行されるまでにはタイムラグが発生する。特に、２つ以上の操作が連続している場合、サーバから先の操作（第１の操作）に関するイベントを受信する前の段階で、後の操作（第２の操作）の指令を発行しようとすることが起こり得る。この場合、第１の操作による操作結果はまだデータベースに反映されていないため、第２の操作が予期せぬ結果となる可能性がある。これを回避するためには、第２の操作の指令の発行を遅延させねばならない。
【００１０】
しかし、操作指令発行から操作実行までに要する時間はシステムの動作環境により大きく異なる。このため、第２の操作の指令の発行を遅延させるための遅延時間を定めることは容易ではなく、操作指令を発行するタイミングに制約を受ける場合があった。そのため、第１の操作の指令を発行した後に、第１の操作が確実に実行されたことを保証するための機構が求められていた。
【００１１】
本発明は上記の課題に鑑みてなされたものであり、複数のプロセスで共有される共有データに対して行われる操作について、先に発行された操作指令が実行された上で後の操作指令が発行されることを保証する機構を提供し、操作指令発行のタイミングに関する制約を除去することを目的とする。
また、複数の端末によって操作指令が発行される場合においても、容易に操作実行順序を保証することを目的とする。
【００１２】
【課題を解決するための手段】
上記の目的を達成するための本発明による情報処理方法は、
情報伝達媒体を介して通信可能な複数のプロセスによって共有される共有データを該複数のプロセスの各々が保持して利用するシステムにおいて、各プロセスが保持する共有データの同一性を維持するための情報処理方法であって、
前記共有データに対する操作要求が発生した場合に、該操作要求を表す操作イベントを前記情報伝達媒体上に発行する第１発行工程と、
所定のユーザ操作に応じて発行禁止イベントを発行する第２発行工程と、
前記第１発行工程によって発行された操作イベントに応答する応答操作イベントを外部より受信し、前記共有データへの操作を実行する操作実行工程と、
前記第２発行工程による発行禁止イベントの発行後、該発行禁止イベントに対応したイベントを受信するまで、前記第１及び第２発行工程によるイベントの発行を禁止する禁止工程とを備える。
【００１３】
また、上記の目的を達成するための本発明による情報処理装置は以下の構成を備える。すなわち、
情報伝達媒体を介して通信可能な複数のプロセスによって共有される共有データを該複数のプロセスの各々が保持して利用するシステムにおいて、各プロセスが保持する共有データの同一性を維持するための情報処理装置であって、
前記共有データに対する操作要求が発生した場合に、該操作要求を表す操作イベントを前記情報伝達媒体上に発行する第１発行手段と、
所定のユーザ操作に応じて発行禁止イベントを発行する第２発行手段と、
前記第１発行手段によって発行された操作イベントに応答する応答操作イベントを外部より受信し、前記共有データへの操作を実行する操作実行手段と、
前記第２発行手段による発行禁止イベントの発行後、該発行禁止イベントに対応したイベントを受信するまで、前記第１及び第２発行手段によるイベントの発行を禁止する禁止手段とを備える。
【００１４】
【発明の実施の形態】
以下、添付の図面を参照して本発明の好適な実施形態を説明する。
【００１５】
〔第１実施形態〕
第１実施形態では、本願発明による情報処理方法を、仮想空間の構造と属性を記述するシーンデータベースを複数の端末で共有する仮想空間共有システムに応用した実現形態について説明する。
【００１６】
本実施形態の仮想空間共有システムの全体的な構成を図１に示す。システムには１つのサーバプロセス１０１（以下、「サーバ」と略す）と、複数のクライアントプロセス１０３（以下、「クライアント」と略す）があり、情報伝達媒体としてのネットワーク１０２を介してデータを交換する。それぞれのクライアントは共通の仮想空間の構造と属性を記述するシーンデータベースを保持する。なお、本実施形態では、ネットワーク１０２はイーサネット（登録商標）上に構築したＬＡＮである。なお、情報伝達媒体は無線でも有線でもかまわない。
【００１７】
ここで、以下の説明で用いる「データベース操作」という用語について説明しておく。データベースの「操作」とは、共有データベースを持つ任意のプロセスにおけるデータベースの内容を書き換える処理のことを差す。データベース操作は「操作指令」と「操作実行」の２段階に分かれる。操作指令はデータベースの更新要求であり、実際の書き換えは行われない。データベースに対する実際の書き換えは、操作実行の段階で行われる。以下の説明では特に断らない限り、単に「操作」と記述すれば「データベース操作」のことを指すものとする。操作対象がデータベース以外の場合は、「ユーザによる対話デバイスの操作」などのように操作対象を明示するものとする。
【００１８】
なお、操作指令はユーザが発生させることもあれば、プロセスが動作の過程で発生することもある。前者の例としては、ユーザがマウスなどの対話デバイスを操作して、仮想オブジェクトを移動させた際に操作指令が発生されることが挙げられる。一方、後者の例としては、シューティングゲーム・システムにおいて、ゲームプログラムが敵キャラクタをアルゴリズム的に移動・回転させた際に操作指令が発生されること等が挙げられる。
【００１９】
図２はデータベースを更新するための基本的な情報の流れを示すものである。図２で、Ａ，  Ｂ，  Ｃ，  Ｄ（２０１〜２０４）はクライアント、Ｘ（２０５）はサーバである。いま、クライアントＡ（２０１）がシーンデータベースの操作指令を行ったとする。操作指令の内容はネットワーク経由でサーバに送信される（図２で（１）の矢印の過程）。サーバは、この操作指令を受けてクライアントＡ（２０１）から送信されたデータを、すべてのクライアントに配信する（図２で（２）の矢印の過程）。このような過程を経ることによって、非操作者のクライアントＢ（２０２）、Ｃ（２０３）、Ｄ（２０４）も操作の内容を知ることができる。
【００２０】
次に、クライアントまたはサーバプロセスが動作する端末の構成を図３に示す。図３において、３０１はＣＰＵであり、端末全体の動作を制御する。３０２はメモリであり、ＣＰＵ３０１の動作に用いるプログラムやデータを格納する。３０３はバスであり、各構成モジュール間のデータ転送を司る。３０４はバス３０３と各種装置とのインタフェースである。また、３０５はネットワークと接続するための通信部、３０６はＣＰＵ３０１に読み込むプログラムやデータを格納する外部記憶装置、３０７および３０８はプログラムを起動したり、プログラムの動作を指定するための入力装置を構成するキーボードおよびマウス、３０９はプロセスの動作結果を表示するための表示部である。
【００２１】
本実施形態のシステムは、データベースの更新タイミングに関して下記の３つのモードを持つ。以下、これらのモードを総称して「更新モード」と呼ぶ。
（１）  ウェイトモード（待機モード）
（２）  イミディエートモード（即時モード）
（３）  ディレイモード（遅延モード）
以下、各モードの処理について詳しく説明する。
【００２２】
「ウェイトモード」は、ある操作指令に対する操作実行が、サーバからのイベントの配信を待って行われるモードである。図４は、ウェイトモードにおける時間の進行に沿った処理手順を模式的に示したものである。図４で、「操作者」は操作指令を行ったクライアント、「非操作者」は操作者以外のクライアントを指す。処理の進行は以下の説明の通りである。
【００２３】
まず、手順Ｔ４０１で操作者クライアントがデータベースの操作指令を発する。この時点では、操作者クライアントのデータベースは更新されない。次に手順Ｔ４０２にて、Ｔ４０１の操作内容を示すイベントが生成され、Ｔ４０３でサーバに送信される。サーバは手順Ｔ４０４でイベントを受信し、Ｔ４０５で当該サーバとの接続が確立しているすべてのクライアントに向けてイベントを送信する（接続の確立について図１１のステップＳ１１０２で後述する）。サーバより発行されたイベントを操作者クライアントが手順Ｔ４０６で受信し、その内容を分析して（Ｔ４０７）、データベースを書き換える（Ｔ４０８）。イベントの受信からの手順は、非操作者クライアントでも同様である（手順Ｔ４０９〜Ｔ４１１）。図４に示した通り、ウェイトモードでは、操作指令（Ｔ４０１）から操作実行（Ｔ４０８）までタイムラグがある。しかし、ネットワーク上の情報転送の条件が同様であれば、操作者・非操作者クライアントともほぼ同時刻にデータベースが更新され、仮想空間の画像がクライアント間で同期することが期待できる。
【００２４】
「イミディエートモード」は、操作者の指令が直ちにデータベースに反映され、これに対して非操作者のデータベースは遅れて更新されるものである。図５は、イミディエートモードにおける時間の進行に沿った処理手順を模式的に示したものである。処理の進行は以下の説明の通りである。
【００２５】
まず、手順Ｔ５０１で操作者クライアントがデータベースの操作指令を発する。次に、手順Ｔ５０２で操作指令の内容に従ってデータベースが更新される。この後、操作内容を示すイベントが生成され（Ｔ５０３）、サーバに送信される（Ｔ５０４）。イベント送信後、操作者クライアントでは手順Ｔ５０１の操作指令および実行が行われたことを示す情報を操作キューとして保持しておく（Ｔ５０５、「操作キュー」については後述する）。
【００２６】
サーバは手順Ｔ５０６でイベントを受信し、Ｔ５０７ですべてのクライアントに向けて当該イベントを送信する。操作者クライアントは手順Ｔ５０８でサーバからイベントを受信すると、操作キューを参照する（Ｔ５０９）。ここで、手順Ｔ５０５で記録された情報により、すでに当該操作が実行済みであることが認識されるので、操作実行処理は行わず，手順Ｔ５０５で記録された情報を削除する（Ｔ５１４）。
【００２７】
一方、非操作者クライアントでは手順Ｔ５１０で受信したイベントが未実行であることを操作キューを参照することにより認識し（Ｔ５１１）、イベントの内容に基づいて操作を実行する（Ｔ５１２，  Ｔ５１３）。
【００２８】
上記のような手順でデータベースを更新すると、操作者クライアントにおいては仮想空間に対する操作の結果がＣＧ画像に反映されるまでの時間遅れがウェイトモードに比べて少なくなる。したがって、イミディエートモードは主に、ユーザが対話デバイスを用いて仮想物体を操作する場合に適している。なぜなら、一般的にユーザの対話的操作とその結果の提示の間に時間的ずれが生ずると、操作がより困難になる、ユーザに不快感を与えるなどの不具合が生じるからである。
【００２９】
「ディレイモード」は、ウェイトモードのように操作指令を直ちに実行しないものの、操作実行の期限を設けて、その期限が過ぎた場合にはサーバからのイベント返信を待たずに当該操作を実行するというものである。図６は、ディレイモードにおいて、操作実行期限に到達する前に、サーバからのイベントが到着した場合の時間の進行に沿った処理手順を模式的に示したものである。処理の進行は以下の説明の通りである。
【００３０】
まず、手順Ｔ６０１で操作者クライアントがデータベースの操作指令を発する。この時点では、データベースは更新されない。次に手順Ｔ６０２にて、Ｔ６０１の操作の内容を示すイベントが生成され、Ｔ６０３でサーバに送信される。イベント送信後、操作者クライアントでは手順Ｔ６０１の操作指令が行われたことを示す情報を操作キューに保持し（Ｔ６０４、「操作キュー」については後述する）、さらにタイマー処理を起動する（Ｔ６０５）。タイマー処理はタイムアウトを待って操作実行を行なうものであり、詳細は図１９により後述する。
【００３１】
一方、サーバは手順Ｔ６０６でイベントを受信し、Ｔ６０７ですべてのクライアントに向けてイベントを送信する。操作者クライアントは手順Ｔ６０８でイベントを受信し、操作キューを参照する（Ｔ６０９）。ここで、操作が未実行であることが認識されるので、当該操作キューに操作が実行済みであることを記録し（Ｔ６１０）、イベントの内容を分析し（Ｔ６１１）、データベースを書き換える（Ｔ６１２）。さらに，Ｔ６０４で記録された情報を削除する（Ｔ６１７）。また、非操作者クライアントでは手順Ｔ６１３で受信したイベントが未実行であることを認識し（Ｔ６１４）、イベントの内容に基づいて操作を実行する（Ｔ６１５，  Ｔ６１６）。
【００３２】
一方、図７はディレイモードにおいて、サーバからのイベントが到着する前に操作実行期限（タイムアウト）に至った場合の時間の進行に沿った処理手順を模式的に示したものである。処理の進行は以下の説明の通りである。
【００３３】
まず、手順Ｔ７０１で操作者クライアントがデータベースの操作指令を発する。この時点では、データベースは更新されない。次に手順Ｔ７０２にて、Ｔ７０１の操作の内容を示すイベントが生成され、Ｔ７０３でサーバに送信される。イベント送信後、操作者クライアントでは手順Ｔ７０１の操作指令が行われたことを示す情報を操作キューに保持し（Ｔ７０４、「操作キュー」については後述する）、さらにタイマー処理を起動する（Ｔ７０５）。なお、タイマー処理はタイムアウトを待って操作実行を行なうものであり、詳細は図１９により後述する。一方、サーバは手順Ｔ７０６でイベントを受信し、Ｔ７０９ですべてのクライアントに向けてイベントを送信する。
【００３４】
タイマー処理では、サーバから対応するイベントを受信するまでの間にタイムアウト時刻に至ると、それをタイマー処理が検知し、手順Ｔ７０７で操作を実行して、操作キューに当該操作が実行済みであることを記憶する（Ｔ７０８）。したがって、操作者クライアントは、後に手順Ｔ７１０でイベントを受信するものの、操作キューを参照することにより当該操作が実行済みであることを認識し（Ｔ７１１）、操作実行は行われない。非操作者クライアントでは手順Ｔ７１３で受信したイベントが未実行であることを認識し（Ｔ７１４）、イベントの内容に基づいて操作を実行する（Ｔ７１５，  Ｔ７１６）。
【００３５】
上記のような手順でデータベースを更新すると、イベント配信のタイムラグが大きければ操作実行が極力遅れないように動作し、タイムラグが小さければクライアント間の同期を図るように動作する。このような動作の切り換えは自動的に行われ、タイムアウト時間を適宜設定することにより、どちらの動作を優勢にするか調整することができる。
【００３６】
本実施形態では、上述のウェイトモード及びディレイモードに関して、操作実行と操作指令発行の順番を保証するために、更に消化イベントモード、同期イベントモードに対応した処理を実行する。これらについては、後述する。
【００３７】
図８の（ａ）は、クライアントからサーバに対して、或いはサーバからクライアントに対して発行されるイベントの内容を示したものである。イベントのデータは複数のフィールドから構成される。クライアントＩＤ８０１は、各クライアントを一意に識別するための番号で、クライアントがサーバとネットワーク接続を確立する際にサーバより割り当てられたものである（図１１のステップＳ１１０２により後述する）。操作ＩＤ８０２は操作を一意に識別するための番号で、各クライアントに操作指令を行った時点で割り当てられる。このクライアントＩＤ８０１および操作ＩＤ８０２の組を用いることにより、システム内部で起こったすべての操作指令を一意に特定することが可能である。
【００３８】
更新モードＩＤ８０３は、各更新モードに対して一意に決定された識別番号で、このイベントに対応する操作指令の更新モードにより決定する。更新モードはデータベースの各エントリに設定、登録されている（図２１により後述する）ので、これを参照して更新モードが設定される。なお、更新モードＩＤ８０３には上述したウェイトモード、ディレイモード、イミディエイトモードのいずれかが設定されることになる。
【００３９】
タイムアウト時刻８０４は、上述のディレイモードにおいて使用されるものであり、イベントの発生時刻にディレイ時間を加算した時刻が記述される。エントリＩＤ８０５は、データベースの各エントリを一意に識別するための番号で、データをファイルからロードした際に割り当てられる。操作内容８０６は、操作指令の具体的内容であり、例えばＣＧオブジェクトのＸ座標をある値に設定する操作であれば、Ｘ座標属性を識別する番号とＸ座標の設定値の組で表される。
【００４０】
また、図８の（ｂ）は、同期イベント及び消化イベントのデータ構成を示す。このイベントには、クライアントＩＤ８１１と、イベントの種類（消化か同期か）を表すイベント種別８１２が含まれる。
【００４１】
次に、操作キューについて説明する。操作キューは、イベントの受信または実行処理を待機している操作指令のリストである。ある時点で待機状態にある操作指令がｍ個あるとすると、操作キューは図９のように操作指令に関するｍ個の情報（キューアイテム）を指令の発生順に並べたものとなる。
【００４２】
１つのキューアイテムの内容は図１０（ａ）のように、３つのデータフィールドから構成される。操作ＩＤ１００１は、操作を一意に識別するための番号で、対応するイベントの操作ＩＤフィールドと同じ値である。操作ＩＤ１００１は、クライアントにおいて操作指令を行った時点で割り当てられる。タイムアウト時刻１００２は、ディレイモードにおける操作実行期限であり、クライアントにおいて操作指令を行った時点で、現在時刻に所定のタイムアウト時間を加算して求められる。実行済みフラグ１００３は、イミディエートモードあるいはディレイモードにおいて、この操作ＩＤを持つ操作が実行済みであるかどうかを示す。実行済みフラグは、操作指令を行った時点ではＯＦＦに設定され、操作が実行された時点でＯＮに変更される。
【００４３】
なお、図１０の（ａ）ではフィールド数３の操作キューアイテムを示したが、実行済みフラグとタイムアウト時刻を兼用することも可能である。この場合、タイムアウト時刻が特殊な値（例えばマイナス１）である場合に実行済みであると定義すればよい。この場合の操作キューアイテムのデータ構成は図１０の（ｂ）のようになる。
【００４４】
次に、イベントの消化、イベントの同期について説明する。ユーザは所望のタイミングで端末から消化イベント、同期イベントを発行させることができる。
【００４５】
まず、イベントの消化について説明する。ウェイトモードやディレイモードの場合、操作者クライアントが操作指令を発行してから操作実行までにはタイムラグが生じる。例えば、第１、第２の連続する２つの操作があり、第１の操作結果がある条件を満たしたときのみ第２の操作を行うものとする。第１の操作指令を発行した後、第１の操作が未実行である状態で第２の操作指令が発行されると、その時点では第１の操作結果がデータベースに反映されていないため、第１の操作結果を正しく参照できず、第２の操作が正しく行われない可能性がある。そのため、第１の操作指令が実行された後、第１の操作指令が実行されるまで待機し、その後で第２の操作指令を発行しなければならない。すなわち、第２の操作指令の前に、それ以前に発行されていて未実行であるイベントをすべて実行済みの状態にしておく必要がある。以下、現時点までに発行された全てのイベントを実行済みの状態にすることを「イベントを消化する」と記述する。
【００４６】
以下、ウェイトモードにおける消化イベントの処理について説明する。図２２はイベント消化の手順について示している。図２２では、２つのクライアントが１つのサーバに接続している。まず、手順Ｔ２５０１でクライアント１はデータベースの操作指令を発し、操作内容を示す操作イベントがサーバに送信される。この時点では、クライアント１のデータベースには、手順Ｔ２５０１の操作結果は反映されていない。手順Ｔ２５０２でサーバは操作イベント１を受信し、クライアント１およびクライアント２に対して操作イベント１を送信する。
【００４７】
一方、クライアント１では、操作指令１の操作実行結果に影響を受ける操作指令２の入力に先立って消化イベントの発行をユーザが指示する。この操作は、操作指令１の操作実行後に操作指令２を発行させることを確実にするためのものである。この指示により、手順Ｔ２５０３で「消化イベント」が生成され、サーバに送信されるとともに、操作指令の発行が停止される（操作指令発行停止となる）。
【００４８】
手順Ｔ２５０４でサーバは消化イベントを受信し、クライアント１およびクライアント２に対して消化イベントを送信する。このときサーバは消化イベントを通常の操作イベントと同様に扱う。即ち、受け取った消化イベントを送信元を含む、接続の確立している全てのクライアントに対して送信する。
【００４９】
さて、手順Ｔ２５０５でクライアント１において操作指令２を発行しようとしても、既に手順Ｔ２５０３において操作指令発行を停止しているため、操作指令２はこの時点で発行されない。このとき、図示しない操作指令発行キューに操作指令２を追加する（「操作指令発行キュー」については後述する）。
【００５０】
クライアント１は、サーバより操作イベント１を受信すると直ちに当該操作を実行する。そして、手順Ｔ２５０６でクライアント１はサーバより送信された消化イベントを受信すると、消化イベントのデータ中のクライアントＩＤ８０１（図８）を参照する。その結果、受信した消化イベントがクライアント１によって送信されていた場合には、操作指令発行停止を解除する。操作指令発行停止の解除時には、操作指令発行キューを参照し、操作指令発行キューに登録されている操作指令を順次発行する（手順Ｔ２５０７）。図２２の場合は、Ｔ２５０５で指示された操作指令２が発行され、操作イベント２がサーバに送信される。手順Ｔ２５０８では、クライアント２が消化イベントを受信するが、この消化イベントはクライアント２によって送信されたものではないため、そのまま破棄される。
【００５１】
以上のように、ある操作指令を発行した後、同一クライアントより消化イベントを発行（サーバに送信）すると、消化イベント送信後は、発行した消化イベントをサーバから受信するまでの間、操作指令の発行を停止する。このようにすることで、先の操作指令を確実に実行済みの状態にした上で、次の操作指令を発行することが可能となる。
【００５２】
なお、更新モードがイミディエートモードである場合には、操作指令は発行されてすぐに実行されるため、上記イベント消化手順を行う必要はない。
【００５３】
また、更新モードがディレイモードのときには、手順Ｔ２５０３で操作指令発行を停止した後、サーバから消化イベントを受信する前にタイムアウト時刻に至った場合には、その時点で操作指令発行停止を解除し、操作指令発行キューを参照して登録されているイベントを発行する。なお、この時点で操作実行がされていない場合は、ディレイモードについて上述したように当該操作が即座に実行される。
【００５４】
次に、イベントの同期について説明する。イベントの同期を行なうことによって、接続された全クライアントで操作順序が保証される。操作者クライアントの操作指令の発行から非操作者クライアントの操作実行までにはタイムラグが生じる。例えば、第１、第２の連続する２つの操作があり、第１の操作指令はクライアント１が、第２の操作指令はクライアント２が発行し、第１の操作結果がある条件を満たしたときのみ第２の操作を行うものとする。今、クライアント１が第１の操作指令を発行した後、クライアント２上で第１の操作が未実行である状態で第２の操作指令が発行されたとする。この場合、その時点で第１の操作がクライアント２のデータベースに反映されていないため、クライアント２上で第１の操作結果を正しく参照できず、第２の操作が正しく行われない可能性がある。その結果、クライアント間でデータベースの内容が異なってしまい、整合が取れなくなる可能性が生ずる。
【００５５】
クライアント２上で第２の操作指令が発行された時点で、クライアント１では第１の操作が実行済みで、クライアント２では未実行であったとすると、クライアント１では第２の操作が正しく実行されるが、クライアント２では第２の操作が正しく実行されない。そのため、クライアント２は、すべてのクライアント上で第１の操作実行が行われるまで待機し、その後で第２の操作指令を発行しなければならない。すなわち、第２の操作指令の前に、それ以前に全クライアントで発行されていて未実行であるイベントをすべて消化し、その後に発行されるイベントを全クライアント間で同期させるようにする必要がある。本実施形態では同期イベントの発行及び管理によりこれを実現する。
【００５６】
図２３はイベント同期の手順について示している。図２３では、２つのクライアントが１つのサーバに接続され、クライアント１が操作１を行い、クライアント２は操作１の実行結果に影響を受ける操作２を行う。クライアント２が行う操作２はクライアント１が行う操作１に影響を受ける操作であることに関して、ユーザはあらかじめ知っているものとする。図２３では、クライアント１とクライアント２のイベント発行を同期させる様子が示されている。
【００５７】
まず、手順Ｔ２６０１でクライアント１はデータベースの操作指令を発行し、操作内容を示すイベントがサーバに送信される。この時点では、クライアント１のデータベースには、手順Ｔ２６０１の操作結果は反映されておらず、その後、サーバ１から操作イベント１を受信した時点で操作が実行されることになる。
【００５８】
手順Ｔ２６０２ではサーバは操作イベント１を受信し、クライアント１およびクライアント２に対して操作イベント１を送信する。ここで、操作指令１には、当該操作結果に影響を受ける操作指令２が付随するため、クライアント１のユーザは同期イベントを発行させる操作を行なう。この操作により、手順Ｔ２６０３では、「同期イベント１」が生成されサーバに送信される。そして、クライアント１における操作指令の発行を停止する。この操作指令の発行停止は、クライアント数の同期イベントをサーバから受信したときに解除される。
【００５９】
手順Ｔ２６０４でサーバはクライアント１が送信した同期イベント１を受信し、クライアント１およびクライアント２に対して同期イベント１を送信する。このときサーバは同期イベントを通常の操作イベントと同様に扱う。クライアント２では操作イベントを受信するとこれを実行する。
【００６０】
一方、クライアント２のユーザは、操作指令１の操作実行結果に影響を受ける操作指令２を発行しようとしており、システムの同期を取るために同期イベントを発行する操作を行なう。図２３の手順Ｔ２６０５では、この操作によって同期イベント２が生成され、これがサーバに送信される。同期イベントの発行とともに、クライアント２における操作指令の発行が停止される。これにより、前クライアントで操作指令１が実行済みとなってから操作指令２が発行されることを保証する。
【００６１】
クライアント１においても、サーバより送信された操作イベント１を受信するとこれに対応する操作が実行される。また、手順Ｔ２６０６で同期イベント１を受信するが、この時点でこれまでに受信した同期イベントはクライアント１が送信したもの１つだけであるので、操作指令の発行停止は継続される。
【００６２】
クライアント２においても手順Ｔ２６０７で同期イベント１を受信するが、この時点でこれまでに受信した同期イベントはやはり１つだけであるので、操作指令の発行停止は継続される。したがって、手順Ｔ２６０８で、クライアント２において操作指令２を発行しようとしても、手順Ｔ２６０５で操作指令発行を停止しているため、操作指令２はこの時点で発行されない。このとき、クライアント２において図示しない操作指令発行キューに操作指令２を追加する。
【００６３】
手順Ｔ２６０９でサーバはクライアント２が発行した同期イベント２を受信し、クライアント１およびクライアント２に対して同期イベント２を送信する。手順２６１０でクライアント１はサーバより送信された同期イベント２を受信する。この時点で、これまでにクライアント１およびクライアント２が送信した計２つの同期イベントを受信しており、これはサーバに接続されているクライアント数に等しいので、操作指令の発行停止は解除される。操作指令発行停止の解除時には、操作指令発行キューを参照し、操作指令発行キューに登録されている操作指令があればこれを処理（発行）する。
【００６４】
同様に、手順Ｔ２６１１でクライアント２はサーバより送信された同期イベントを２を受信する。クライアント２において、２つの同期イベントが受信されたので、手順Ｔ２６１０と同様に操作指令の発行停止は解除される。そして、手順Ｔ２６１２において、クライアント２は操作指令発行キューを参照し、キューに登録されている操作指令を発行する。この場合は操作指令２が発行され、操作イベント２がサーバに送信されることになる。
【００６５】
以上のように、同期イベントモードでは、全クライアントが各々同期イベントを発行し、各クライアントは各クライアントが発行した同期イベントを、クライアント数分だけ（サーバを介して）受信する。各クライアントでは、すべての同期イベントの受信が完了するまでの間、操作指令の発行を停止する。このようにすることで、同期イベントの受信が完了した時点では、これまでに全クライアントで発行された全操作指令が確実に消化される。
【００６６】
なお、同期イベントはユーザによる操作指示で発行され、各クライアントはサーバから受信される同期イベントの数を常時カウントする。そしてそのカウント値が所定数（ここではサーバと接続を確立しているクライアント数）となった場合には、操作指令の発行停止を解除するとともに、カウント値をリセットして、再び同期イベントのカウントを開始する。
【００６７】
但し、更新モードがディレイモードのときには、全クライアントからの同期イベントの受信が完了することなくタイムアウト時刻に至った場合には、その時点で操作指令発行停止を解除する。
【００６８】
また、必ずしもサーバに接続している全クライアント間で同期を取る必要はなく、同期させるクライアント群を任意に設定できるようにしてもよい。例えば、同期イベントのデータを構成する際に、操作内容８０６（図８）に同期対象となるクライアント群のクライアント識別番号を設定する。各クライアントが同期イベントを受信する際に、操作内容８０６に設定されているクライアント識別番号と同期イベントのクライアントＩＤ８１１（図８の（ｂ））に記述されている番号とを比較し、操作内容８０６に設定されている全てのクライアント識別番号のクライアントから同期イベントを受信した時点で、操作指令の発行停止を解除する。このようにすることで、任意のクライアント間でイベント発行を同期させることが可能である。
【００６９】
次に、操作指令発行キューについて説明する。操作指令発行キューはイベントの発行を待機している操作指令のリストであり、図９に示した操作キューと同様の構成を有する。すなわち、ある時点で待機状態にある操作指令がｍ個あるとすると、操作指令発行キューは図９のように操作指令に関するｍ個の情報（キューアイテム）を指令の発行順に並べたものとなる。操作キューと操作指令発行キューとは、前者がイベントの受信または実行処理を待機している操作指令のリストであるのに対して、後者はイベントの発行を待機している操作指令のリストであるという差異こそあるが、双方とも操作指令を格納するリストであるため、操作指令発行キューは操作キューと同様の手段および構成で実現することが可能である。
【００７０】
次に、クライアント、サーバのそれぞれについて、上述した処理の流れを詳しく説明する。
【００７１】
図１１は、クライアントの処理の全体的な流れである。クライアントが起動されると、ステップＳ１１０１にて仮想空間を記述するファイルを外部記憶装置３０６（図３）より読み込み、メモリ３０２（図３）上にシーングラフデータベースを構築する。クライアント間でのデータの同一性を維持するため、ここでロードするファイルはクライアント間で同じ内容を持つとする。次に、サーバとのネットワーク接続を確立する（ステップＳ１１０２）。このとき、サーバから各クライアントを識別するためのクライアントＩＤが付与される。なお、クライアントとサーバ間のデータ交換は、ＴＣＰ／ＩＰプロトコルを用いた１対１のソケット通信にて行う。したがって、サーバは少なくともクライアントの数だけのソケット通信路を持つことになる。
【００７２】
続いて、ステップＳ１１０３でプロセスを分岐し、操作指令を処理するための操作処理（ステップＳ１１０４）およびサーバから受信するイベントを処理するための受信イベント処理（ステップＳ１１０６）を起動する。なお、図１１には図示していないが、シーングラフデータベースを参照して、仮想空間のＣＧ画像を生成するプロセスも起動する。この処理は、公知のＣＧ画像生成方法と同様であるのでその詳細な説明は省略する。また、操作処理および受信イベント処理については、後に詳しく説明する。操作処理および受信イベント処理はそれぞれステップＳ１１０５およびステップＳ１１０７でプロセスの終了する指示があったかどうか判定され、終了指示がなければステップＳ１１０４およびステップＳ１１０６に戻って操作指令および受信イベントを継続して処理する。一方、終了指示があればステップＳ１１０８でプロセスを統合し、サーバとのネットワーク接続を切断（ステップＳ１１０９）した上で、データベースの内容を外部記憶装置（図３の３０６）にファイルとしてセーブ（ステップＳ１１１０）して、すべての処理を終了する。
【００７３】
ここで、ステップＳ１１０４の操作処理について図１２Ａ，Ｂを参照して詳しく説明する。初めに、ステップＳ１２０１にて操作指令の内容を入力する。本実施形態では、操作指令の入力はユーザからの操作指示が操作指令発行停止中以外になされた場合には、当該操作指令に対する処理が直ちに実行されるが、操作指令発行停止中に操作指令がなされた場合は、一旦操作指令発行キューに登録され、操作指令発行停止が解除された後にその処理が実行されることになる。
【００７４】
図１２Ｂは図１２Ａの上記ステップＳ１２０１に相当する処理を詳細に説明するフローチャートである。操作指令発行停止中に操作指示がなされた場合は、当該操作が操作指令発行キューに登録される（ステップＳ１２２０、Ｓ１２２１、Ｓ１２２２）。一方、操作指令発行停止中でない間に、操作指示がなされた場合は、当該操作指示が消化イベント或いは同期イベントの発行指示か否かを判定する。消化／同期イベントのいずれでもなければ、ステップＳ１２０２（図１２Ａ）へ進む。操作指示が消化／同期イベントのいずれかであれば、ステップＳ１２２６に進み、対応するイベント（図８（ｂ）に示すような消化イベントもしくは同期イベント）を発行するとともに、操作指令発行停止状態に移行する。
【００７５】
ステップＳ１２２３で操作指示がなされていなかった場合は、ステップＳ１２２４に進み、操作指令発行キューに未処理の操作指示があるか否かを判定する。未処理の操作指示があればステップＳ１２２５へ進み、上記と同様の処理を行なう。ステップＳ１２２４で操作指令発行キューが無ければステップＳ１２２０へ戻り上記処理を繰り返す。
【００７６】
図１２Ａに戻り、ステップＳ１２０２およびステップＳ１２０３で、データベースのエントリを参照して更新モードを判定する。更新モードに応じて、ステップＳ１２０６のウェイトモード操作処理、ステップＳ１２０５のイミディエートモード操作処理、ステップＳ１２０４のディレイモード操作処理、のいずれかのステップを経た後、処理を終了する。
【００７７】
以下、更新モードごとの操作処理（ステップＳ１２０４、Ｓ１２０６）について、図１３〜図１５を参照して詳述する。
【００７８】
図１３に、ウェイトモード操作処理の流れを示す。ウェイトモードの操作処理では、まず、ステップＳ１３０１で当該操作指令に対応した操作イベントを生成し、ステップＳ１３０２でその操作イベントを発行する。
【００７９】
イミディエートモード操作処理の流れは図１４に示す通りである。まず、ステップＳ１４０１にて、ステップＳ１２０１で入力した操作指令を実行する。具体的には、データベースの指定エントリの設定値を変更する。次に、ウェイトモードと同様にイベントを生成し（ステップＳ１４０２）、これをサーバに向けて発信（ステップＳ１４０３）する。最後のステップＳ１４０４で、操作ＩＤをステップＳ１２０１で決定した操作ＩＤ番号に、実行済みフラグをＯＮに、それぞれ設定した操作キューアイテムを操作キューに追加する。このとき、タイムアウト時刻は処理に用いないので、任意に設定してよい（例えば０）。
【００８０】
次に、ディレイモード操作処理について図１５を用いて説明する。まずウェイトモードと同様にイベントを生成し（ステップＳ１５０１）、これをサーバに向けて発信（ステップＳ１５０２）する。次に、操作ＩＤ１００１をステップＳ１２０１で決定した操作ＩＤ番号に、タイムアウト時刻１００２を現在時刻に所定のタイムアウト時間を加えた値に、実行済みフラグをＯＦＦに、それぞれ設定した操作キューアイテム（図９）を操作キューに追加する（ステップＳ１５０３）。最後に、操作ＩＤ、操作内容、タイムアウト時刻のデータを渡してタイマープロセスを起動する（ステップＳ１５０４）。タイマープロセスについては、後に詳述する。
【００８１】
続いて、ステップＳ１１０６（図１１）の受信イベント処理について詳しく説明する。図１６Ａは、受信イベント処理の流れを示した図である。受信イベントは、不図示のイベント通信部がサーバより受信し、受信イベントバッファに入力される。
【００８２】
ステップＳ１６０１では、受信イベントバッファを検索する。続くステップＳ１６０２で、受信イベントバッファにイベントが入力されているかどうか判定し、受信イベントがあればステップＳ１６０３に進む。一方、受信イベントが存在しないと判定されれば、処理を終了する。
【００８３】
受信イベントがある場合、そのイベントデータを解析し、操作指令の内容を抽出する（ステップＳ１６０３）。次にステップＳ１６１１において、当該イベントが消化イベントもしくは同期イベントであるかどうかを判定する。消化イベントもしくは同期イベントであった場合は、ステップＳ１６１２に進み、対応する処理を行なう。一方、消化イベントでも同期イベントでもない場合は、ステップＳ１６０４およびステップＳ１６０５でイベントの更新モードＩＤ８０３を参照して、操作指令の更新モードを判定する。そして、判定した更新モードに応じてステップＳ１６０８（ウェイトモードの場合）、ステップＳ１６０６（イミディエートモードの場合）、ステップＳ１６０７（ディレイモードの場合）のいずれかのステップを経た後、処理を終了する。
【００８４】
次に、ステップＳ１６１２の、消化／同期イベント処理について説明する。図１６Ｂは消化／同期イベント処理を説明するフローチャートである。ステップＳ１６２１において、当該イベントが自分自身の発行した消化イベントであるか否かを判定する。これは、図８（ｂ）に示すクライアントＩＤ８１１とイベント種別８１２を参照することにより判定できる。自分自身の発行した消化イベントであった場合は、ステップＳ１６２２へ進み、操作指令発行停止を解除する。
【００８５】
一方、自分の発行した消化イベントでない場合は、ステップＳ１６２３において、当該イベントが同期イベントであるかを判定する。同期イベントであった場合は、ステップＳ１６２４で同期イベントをカウントし、そのカウント値が所定数に達したか否かを判定する（ステップＳ１６２５）。所定数に達していた場合はステップＳ１６２７へ進み、同期イベントのカウントをクリアし、操作指令発行停止を解除する（ステップＳ１６２８）。同期イベントのカウント値が所定数でない場合はそのまま本処理を終了する。
【００８６】
次に、各更新モードによるイベント処理について説明する。なお、ステップＳ１６０８では、ウェイトモードであるので、当該操作イベントに対応する操作処理が直ちに実行される。
【００８７】
ステップＳ１６０６のイミディエートモードイベント処理について図１７を参照して説明する。
【００８８】
イミディエートモードイベント処理の流れを図１７に示す。まず、ステップＳ１７０１にて操作キューを検索し、ステップＳ１７０２で操作キューに受信イベントに対応する操作キューアイテムが存在するかどうか判定する。具体的には、受信イベントのクライアントＩＤと本処理が動作しているクライアントのＩＤが一致し、かつ受信イベントの操作ＩＤと操作キューアイテムの操作ＩＤが一致すれば、その操作キューアイテムの操作指令と受信イベントの操作指令は対応していると判定する。イミディエートモードでは、対応するキューアイテムが存在する場合、その操作が当該クライアントで生成された時点で実行済みである。したがって、ここでは操作を実行せずに、ステップＳ１７０３で当該操作キューエントリを削除し、処理を終了する。一方、ステップＳ１７０２で対応するキューアイテムがないと判断された場合、その操作は当該クライアント以外のクライアントで生成されたものなので、まだ実行されていない。したがって、ステップＳ１７０４で当該操作を実行し、処理を終了する。
【００８９】
ステップＳ１６０７のディレイモードイベント処理の流れは図１８Ａ，Ｂに示す通りである。
【００９０】
まず、ステップＳ１８０１にて操作キューを検索し、ステップＳ１８０２で受信イベントに対応する操作キューアイテムが操作キューに存在するかどうか判定する。ステップＳ１８０２の処理の詳細は、ステップＳ１７０２と同様である。ここで対応する操作キューアイテムが存在しない場合は、他のクライアントから発行された操作イベントであることがわかる。この場合、その操作は当該クライアント以外のクライアントで生成されたものなのでまだ実行されていない。そこで、ステップＳ１８０４へ進み、当該操作を実行する。なお、ステップＳ１８０４の処理については図１８Ｂにより後述する。
【００９１】
一方、図１８ＡのステップＳ１８０２において操作キューに対応する操作キューアイテムが存在する場合は、自身から発行した操作イベントである。この場合、処理はステップＳ１８０３へ進み、操作キューアイテムの実行済みフラグをチェックする。実行済みフラグがＯＮである場合は、タイムアウト時刻が過ぎているので、タイマープロセス（後述）によって当該操作イベントは実行済みである。したがって、ここでは操作を実行せず、ステップＳ１８０５にて当該操作キューエントリを削除する。
【００９２】
図１８Ｂは他のクライアントから発行された指令モードの操作イベントを実行する差異の処理を説明するフローチャートである。まず、ステップＳ１８２０において、当該操作イベントを実行する。そして、ステップＳ１８２１において、現在自分自身が操作指令発行停止中であるかどうかを判定する。操作指令発行停止中でなければそのまま本処理を終了する。
【００９３】
操作指令発行停止中の場合は、ステップＳ１８２２へ進み、タイムアウトとなったかを判定する。ここで、タイムアウトの判定は、当該操作イベントに含まれるタイムアウト時刻８０４を参照することで行なえる。タイムアウトになっていなければステップＳ１８２１へ戻る。タイムアウトになる前に同期イベントのカウント値が所定数に達した場合にはステップＳ１８２１からそのまま本処理が終了する。一方、同期イベントのカウント値が所定数に達する前にタイムアウトになった場合は、ステップＳ１８２２からステップＳ１８２３へ進み、操作指令発行停止が解除されることになる。
【００９４】
一方、ステップＳ１８０３にて、実行済みフラグがＯＦＦと判定された場合は、未だタイムアウト時刻に到達していないため、操作は実行されていない。そこで、ステップＳ１８０６で当該操作を直ちに実行し、ステップＳ１８０５で操作キューより当該アイテムを削除する。
【００９５】
次に、図１５のステップＳ１５０４で起動したタイマープロセスについて図１９を用いて詳しく説明する。これは、ディレイモードにおいてタイムアウト時刻に到達した場合に対処するための処理である。
【００９６】
まず、ステップＳ１９０１で操作キューを検索し、ステップＳ１９０２でタイマープロセス起動時に指定された操作に対応する操作キューアイテムが存在するかどうか判定する。具体的には、本プロセス起動時の引数である操作ＩＤと操作キューアイテムの操作ＩＤが一致すれば、その操作キューアイテムの操作指令と引数で指定された操作指令は対応していると判定する。対応するキューアイテムが存在する場合、その操作指令に対応する受信イベントが未処理、すなわち実行されていないことを意味する。この場合は、タイムアウト時刻に到達しているかどうか確認する処理に進む。すなわち、ステップＳ１９０３で現在時刻を参照し、タイムアウト時刻との前後関係を判定する（ステップＳ１９０４）。もし、タイムアウト時刻を過ぎていれば、ステップＳ１９０５で操作を実行し、対応する操作キューアイテムの実行済みフラグをＯＮに設定する。また、操作指令発行停止を解除する。
【００９７】
一方、タイムアウト時刻に達していない場合は、ステップＳ１９０１に戻る。また、ステップＳ１９０２にて、対応する操作キューアイテムが存在しないと判定された場合は、その操作指令に対応する受信イベントが処理済み、すなわち当該操作は実行済みであることを意味する。この場合は、操作の実行や操作キューの変更は必要ないため、そのまま処理を終了する。
【００９８】
以上、クライアント側プロセスの流れを説明した。続いて、サーバ側プロセスの流れを図２０を用いて詳しく説明する。
【００９９】
最初にステップＳ２００１で、クライアントからの接続要求を受け付け、通信を確立する。このとき、通信を確立した各クライアントにクライアントＩＤを通知する。次に、受信イベントバッファを検索し（ステップＳ２００２）、受信イベントが存在するかどうか判定する（ステップＳ２００３）。受信イベントがあれば、ステップＳ２００４に進み、なければステップＳ２００５に進む。ステップＳ２００４では、接続している各クライアントに当該イベント（操作イベント、消化イベント、同期イベント）を送信する。ステップＳ２００５では、ユーザからの指令などによりサーバ処理を終了するかどうかを判定し、終了する場合はステップＳ２００６に進み、終了しない場合はステップＳ２００２に戻る。ステップＳ２００６では、接続している各クライアントに処理を終了することを通知し、次にクライアントとの接続を終了して（ステップＳ２００７）から処理を終了する。
【０１００】
次に、本実施形態でクライアントが読み込むデータベース記述ファイルの構成について説明する。
【０１０１】
図２１はエントリ数がＮのデータのファイルフォーマットを模式的に示したものである。各エントリの属性は、スタートデリミタおよびエンドデリミタで囲まれたフィールドに記述される。図２４で、１番目、２番目、Ｎ番目のエントリのスタートデリミタはそれぞれ２４０１、２４０６、２４０９で示されている。一方、それぞれのエンドデリミタは２４０５、２４０８、２４１１である。エントリの属性は、２４０２〜２４０４のように、各属性を識別するための識別子および属性値の組で記述される。更新モード（消化／同期イベントモードを含む）およびタイムアウト時間は、上記のフォーマットのファイルでエントリごとに規定されている。ただし、該当エントリの更新モードがディレイモードでない場合は、タイムアウト時間は記述しなくてもよい。また、いずれの更新モードにおいても両属性を必ずしも記述する必要はなく、もし記述がなければ、メモリ（図３の３０２）上にシーングラフデータベースを構築する時点（ステップＳ１１０１）で、予めシステムによって決められたデフォルト値に設定される。
【０１０２】
なお、上述のデータベース記述ファイルでは、選択する更新モードを記述している。これに対して、選択不可能な更新モードを１つまたは複数設定することもできる。
【０１０３】
また、上記の説明では、サーバ・クライアント間のデータ通信を１対１のＴＣＰ／ＩＰソケットにて行うとしているが、ブロードキャストあるいはマルチキャストによりイベントを交換してもよいし、通信プロトコルはＴＣＰ／ＩＰに限らない。
【０１０４】
また、通信媒体としてはイーサネット（登録商標）を利用しているが、ＵＳＢやＦｉｒｅｗｉｒｅなど他の情報伝達媒体でも構わない。更に、ネットワークの形態もＬＡＮだけでなく、ＷＡＮ経由の接続でもよいし、ＬＡＮとＷＡＮを併用しても構わない。
【０１０５】
また、サーバの数は、１つの共有データベースシステムにつき１つに限定する必要はなく、複数のサーバが存在してもよい。この場合、各サーバに処理を割り当てる形態は任意である。例えば、クライアントごとに異なるサーバを用いてもよいし、あるいはデータベースのエントリごとにサーバを設けてもよい。
【０１０６】
更に、端末に対するプロセスの割当は１端末１プロセスに限定されるものではなく、１つの端末上で複数のプロセスを動作させることができる。その場合、プロセスの種別の組み合わせは任意であり、クライアントのみ、サーバのみ、クライアントおよびサーバの、いずれの組み合わせでもシステムは動作する。なお、同じ端末上のプロセスは、ネットワークに替えて、共有メモリを経由してデータを交換してもよい。
【０１０７】
また、イベントはサーバが仲介して各端末に配信されるが、データ操作を行った端末が直接に他の端末にイベントを送信するようにしてもよい。
【０１０８】
また、上記の説明では、３次元仮想空間データを共有するとしているが、データベースの内容はこれに限らず任意であることはいうまでもない。また、データベース全体を共有する場合のみならず、その一部のみを共有する場合にも上記実施形態で説明した方法が適用可能であることはいうまでもない。
【０１０９】
以上のように本実施形態によれば、情報伝達媒体を介して通信可能に接続された複数のプロセス（クライアントプロセス）によって共有される共有データ（データベース）を該複数のプロセスの各々が保持して利用するシステムにおいて、各プロセスが保持する共有データの同一性を維持するための情報処理方法が開示される。特に、共有データに対する操作要求が発生した場合には、該操作要求を表す要求情報（イベント）が情報伝達媒体上に出力され、この要求情報に対する応答情報（イベント）を情報伝達媒体より受信し、受信した応答情報に従って共有データに対する操作を実行する。このようなウェイトモードによれば、共有データに対する操作が情報伝達媒体を介して受信されるイベントに従って実行されるので、共有データの更新タイミングを高精度に一致させることができる。
【０１１０】
また、ディレイモードでは、タイマー処理により、応答情報を受信する前に操作要求の発生から所定時間が経過した場合には、該応答情報の受信を待たずに当該操作要求に基づく共有データの操作が実行される。このため、操作が発生したプロセスにおける応答性と複数プロセス間の同期タイミングの一致の両立を図ることができる。
【０１１１】
また、本実施形態によれば、操作要求に応じて操作キューにキューアイテムを登録し、操作実行工程によって共有データに対する操作が実行された場合に対応するキューアイテムを処理済とするキュー制御を行い、操作キューにおいて応答情報が表す操作要求に対応するアイテムが処理済となっていない場合に、応答情報に対応する操作を共有データに対して実行する。上述のようなディレイモードにおいて、操作実行が重複することを簡易な構成で防止できる。
【０１１２】
また、本実施形態によれば、受信工程によって応答情報が受信されるのを待って共有データの操作を実行する第１モード（ウェイトモード）と、操作要求の発生からの所定時間の経過と、応答情報の受信の何れかの早い方のタイミングで共有データの操作を実行する第２モード（ディレイモード）を含む複数の変更モードのいずれかで動作することが可能である。
【０１１３】
そして、共有データは複数のアイテムで構成され（図２１）、複数のアイテムの各々は採用すべき変更モードを指定する指定情報を含む。変更モードはこの指定情報に従って選択され、共有データへの操作が実行されることになる。すなわち、複数のアイテム毎に変更モードが切り換えられることになり、この構成によれば、アイテム毎に適切な変更モードを設定できる。
【０１１４】
また、本実施形態によれば、同一クライアントが二つ以上の連続した操作指令を発行する場合において、先の操作指令を発行した後、後に発行する操作指令が先の操作指令の実行結果を参照するような状況下でも、すべての操作を適切に実行し、データベースに反映させることが可能である。
【０１１５】
また、本実施形態によれば、複数のクライアント間で連続した操作指令を発行する場合において、あるクライアント上で先の操作指令を発行した後、先の操作指令を発行したクライアントとは別のクライアント上で、後に発行する操作指令が先の操作指令の実行結果を参照するような状況下でも、すべてのクライアント上ですべての操作を適切に実行し、すべてのクライアントのデータベースに適切に反映させることが可能である。
【０１１６】
また、サーバプロセスにおいては、情報伝達媒体を介して接続された複数のプロセスによって共有される共有データを該複数のプロセスの各々が保持して利用するシステムにおいて、各プロセスが保持する共有データの同一性を維持するために、複数のクライアントプロセスとの接続を確立し、これら複数のクライアントプロセスより共有データの変更に関るイベントを受信する。そして、受信したイベントを、上記複数のクライアントプロセスに対して発行する。
【０１１７】
なお、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【０１１８】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１１９】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０１２０】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２１】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２２】
【発明の効果】
以上説明したように、本発明によれば、複数のプロセスで共有される共有データに対して行われる操作について、先に発行された操作指令が実行された上で後の操作指令が発行されることを保証する機構を提供し、操作指令発行のタイミングに関する制約を除去することが可能となる。
【図面の簡単な説明】
【図１】第１実施形態におけるデータベース共有システム全体の構成を示すブロック図である。
【図２】第１実施形態によるプロセス間の基本的な情報伝達方法を示す図である。
【図３】第１実施形態による端末装置のハードウエア構成を示すブロック図である。
【図４】ウェイトモードにおけるデータベースの更新手順を示す図である。
【図５】イミディエートモードにおけるデータベースの更新手順を示す図である。
【図６】ディレイモード（非タイムアウト時）におけるデータベースの更新手順を示す図である。
【図７】ディレイモード（タイムアウト時）におけるデータベースの更新手順を示す図である。
【図８】イベントデータのデータ構成例を示す図である。
【図９】操作キューのデータ構成例を示す図である。
【図１０】操作キューアイテムのデータ構成例を示す図である。
【図１１】第１実施形態によるクライアントプロセスのフローチャートである。
【図１２Ａ】クライアントプロセスにおける操作処理を示すフローチャートである。
【図１２Ｂ】図１２Ａの操作入力処理を説明するフローチャートである。
【図１３】図１２Ａのウェイトモード操作処理を説明するフローチャートである。
【図１４】図１２Ａのイミディエートモード操作処理を説明するフローチャートである。
【図１５】図１２Ａのディレイモード操作処理を説明するフローチャートである。
【図１６Ａ】図１１のクライアントプロセスにおける受信イベント処理を示すフローチャートである。
【図１６Ｂ】図１６Ａの消化／同期イベント処理を示すフローチャートである。
【図１７】図１６Ａのイミディエートモード受信イベント処理のフローチャートである。
【図１８Ａ】図１６Ａのディレイモード受信イベント処理のフローチャートである。
【図１８Ｂ】図１８ＡのステップＳ１８０４における操作実行処理のフローチャートである。
【図１９】タイマープロセスを説明するフローチャートである。
【図２０】実施形態によるサーバプロセスを説明するフローチャートである。
【図２１】データベースの記述ファイルフォーマットを示す図である。
【図２２】イベントの消化手順を説明する図である。
【図２３】イベントの同期手順を説明する図である。
【図１】
2004265063.tif 000003
【図２】
2004265063.tif 000004
【図３】
2004265063.tif 000005
【図４】
2004265063.tif 000006
【図５】
2004265063.tif 000007
【図６】
2004265063.tif 000008
【図７】
2004265063.tif 000009
【図８】
2004265063.tif 000010
【図９】
2004265063.tif 000011
【図１０】
2004265063.tif 000012
【図１１】
2004265063.tif 000013
【図１２Ａ】
2004265063.tif 000014
【図１２Ｂ】
2004265063.tif 000015
【図１３】
2004265063.tif 000016
【図１４】
2004265063.tif 000017
【図１５】
2004265063.tif 000018
【図１６Ａ】
2004265063.tif 000019
【図１６Ｂ】
2004265063.tif 000020
【図１７】
2004265063.tif 000021
【図１８Ａ】
2004265063.tif 000022
【図１８Ｂ】
2004265063.tif 000023
【図１９】
2004265063.tif 000024
【図２０】
2004265063.tif 000025
【図２１】
2004265063.tif 000026
【図２２】
2004265063.tif 000027
【図２３】
2004265063.tif 000028