【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は仮想環境制御装置に関し、特に、舞台を使用する共有マルチユーザー型仮想環境の管理等に用いる仮想環境制御装置に関する。

【０００２】

【従来の技術】仮想環境をコンピュータ上に生成する技術開発分野においては、例えば、米国特許出願第０８／
５２０，０９９号（１９９５年８月２８日出願、発明者：ジョン W. バラス（John W. Barrus）及びリチャード C. ウォータ−ズ（Richard C.Waters））に記載されているように、仮想的な、または、模擬的な環境を、いわゆる「舞台（locales）」を設定し利用することによって、創造することが可能である。 その各舞台は、周辺部及びそれ自身の局部的原点に関して、仮想環境の範囲を定義する。 舞台は、地理的な領域として定義されるものであるが、その領域の境界内における区別して表される２つの位置の間の距離は無視できる程度に小さいものである。 従って、舞台は、境界によって定義されるという特徴を持ち、舞台自体の独立した原点を有するので、
舞台内のグラフィカルオブジェクト（図形オブジェクト）は、特定の原点を基準にして配置される。 これにより、複数のデザイナー（ユーザ）による仮想環境の創造が可能になるので、個々のデザイナー（ユーザ）は自分の責任範囲である舞台を単独に制御できる。 このようにして仮想環境が創造されると、多くのユーザがその環境を制御するときに、その環境の制御を管理するために、
舞台の概念を利用することが可能になる。

【０００３】舞台は、それぞれが、それ自体のモデルを持ち、それ自体の境界を持ち、さらにそれ自体の原点を持つ、仮想環境の一部分を構成している小区分である。
これにより、舞台内のグラフィカルオブジェクトが、この原点に関して正確に配置されることが可能になり、また、それぞれの舞台の原点と舞台の基準点との間の予め定められた所定の距離の仕様だけで、隣接のモデルの管理が可能となる。

【０００４】

【発明が解決しようとする課題】ネットワークが使用される場合、それぞれの舞台からのデータはそのネットワーク上を送信されるので、その背景又は領域だけでなく、舞台内のグラフィカルオブジェクトに関するデータを全てのユーザーが利用できる。 多くの舞台がある場合は、大量のメッセージがネットワークで送られる。 これは、ネットワークの搬送容量を犠牲にするが、そのネットワークの過負荷になる程では無いものの、１つのネットワーク節点にいる任意の一人のユーザがそれらの大量のデータを受け取って処理する能力を越えてしまうという問題点があった。

【０００５】この問題を解決するためには、各舞台に独自の通信アドレスを割り当てることによって、個々の節点が全てのメッセージを受信しなくてもよいようにし、
その節点における処理に関係する舞台に関するメッセージだけを選択して受信するようにする必要がある。 特に、節点の視点が所定の１つの舞台にある場合は、その節点は、他の全ての舞台からのメッセージは無視して、
その１つの舞台とそれのすぐ近くにあるものに関係するメッセージとだけを受け取るように構成する。

【０００６】仮想環境において大多数のデータを、ある節点に無視させることの重要性は、任意の所定の節点で必要な計算を大幅に減らすことにある。 しかし、これが、問題を引き起こすことになる。 情報が無視されるということは、ある所定の節点によってその存在が全く知られていないいくつかのオブジェクトが存在してしまうことになることを意味する。 それらの節点は、自分の知らないオブジェクトがどの舞台に存在しているかを知ることができない。 従って、それらの節点は、これらのオブジェクトを探し出すために受信するべき通信アドレスを知らない。 要するに、ある節点が、ある所定のオブジェクトを知っていない場合は、そのオブジェクトについてのデータを何も見つけ出す手段がない。 このことは、
実際的な事例として、その後、再び、その無視したオブジェクトを見つけ出すための手段が提供されない限り、
ある節点は、いずれの情報も無視できないことを意味する。

【０００７】計算と記憶の観点から、大規模な仮想環境によって引き起こされる問題の大きさは、下記の例で理解される。 ５０室あって、その個々の部屋が異なる舞台に対応している建物を、シミュレーションするとする。
平均して、各部屋、つまり舞台は、５０個のオブジェクトを有しているものとし、画像が３０フレーム／秒で生成されることとする。 また、その内の数個のオブジェクトが移動中で、それらのフレーム毎の位置を表すために、１秒間に大量のメッセージが必要であるとし、一方、それ以外の殆どのオブジェクトは静止していて、それらを表すためには、数秒間に１つのメッセージしか必要でないとする。 最後に、この結果、平均して１個のオブジェクト当たり毎秒１メッセージであるとする。 このことは、１部屋当たり毎秒５０メッセージであり、建物全体では、毎秒２，５００個のメッセージが生成されることを意味する。 このような建物を１００棟持つ都市をモデル化する場合、総計で、毎秒２５０，０００メッセージであることが必要となる。

【０００８】ネットワークの帯域幅、１つの節点での処理能力、及び、ある節点での記憶要件の見地から、上記の例が意味している事柄を考える。 平均して１００バイトが１つのメッセージを表すために必要で、その１つのメッセージを処理するために０．０００１秒の時間が必要で、また、１つのオブジェクトの全ての特徴を表現するために、１０，０００バイトの記憶容量が必要であるとする。 このとき、１つの部屋当たり、５，０００バイト／秒で情報が送信されるが、これは現在の大半のネットワークの能力では容易なことであり、そのメッセージの処理には０．００５秒が必要であるが、これは現在のプロセッサには非常に軽い負荷である。 また、５００，
０００バイトの記憶容量がその節点に必要であるが、これも今日の標準では、軽い負荷であることを意味している。 しかしながら、建物全体としては、２５０，０００
バイト／秒で送信され、これは負担ではあるが、今日の殆どのネットワークの能力の範囲内であるものの、メッセージの処理には、０．２５秒を要し、大量の他の処理をしなければならない節点にとっては、法外な負荷となる。 さらに、オブジェクトに対しては、２５，０００，
０００バイトの記憶容量が必要であるが、これは今日の大多数の装置の能力を超える容量である。 また、１００
棟のこのような建物を有する仮想都市については、２
５，０００，０００バイト／秒で送信されるが、これは多くの種類の高速ネットワークにとっては可能であるが、メッセージの処理には２５秒が必要で、これはリアルタイム性能では不可能である。 また、２，５００，０
００，０００バイトの記憶容量が必要となるが、従来の技術においては、これも同様に非現実的な値である。

【０００９】この発明はかかる問題点を解決するためになされたものであり、複数の舞台を有する仮想環境において、それらの舞台のいずれかに存在するオブジェクトに対してビーコンを与え、そのビーコンを用いることにより、すべての舞台からの情報を受信しなくても、限られた所定の少ない情報量だけで、そのオブジェクトがどの舞台に存在しているかを知らない場合においても、そのオブジェクトを探し出すことができる仮想環境制御装置を得ることを目的としている。

【００１０】なお、上記の従来の問題を避けるための鍵は、ある部屋で仮想会議に出席している１人の参加者が、その部屋と、恐らく少数の隣接する部屋での発生事項以外に知る必要がないことを悟ることである。 その参加者は、他の階の部屋での発生事項を知る必要が無いのは、確かである。 このことは、その仮想建物又は都市がどれ程大きくても、その節点が、関心の無い部屋からのメッセージを無視する、つまり、その参加者の部屋に隣接していない部屋に関係するメッセージを無視すれば、
この参加者によって使用される節点は、多くても、数百のメッセージの処理だけしか必要ではない。 また、通信環境でこれを実行するために、非近隣の舞台に関係するアドレスを持つデータを単に排除するだけでよい。 ここで、非近隣とは、非隣接の意味である。

【００１１】上記した情報の切り捨てによって、節点に対する処理や記憶容量の要件が軽くなる。 しかし、これが問題を発生させる。 管理人を見つけ出そうとしている人がいて、その管理人が地階にいて、サービスをするべき部屋の近くにいない場合、その管理人がいる場所のアドレスが不明なので、その管理人の仮想的な引き渡しができない。 関連する問題は、オブジェクトが、ある舞台から他の舞台へ移動したときに、そのオブジェクトに追随することさえ難しいというものである。 そのオブジェクトがゆっくりと動く場合は、ある舞台から隣の舞台に移動しているオブジェクトを追跡することは、比較的簡単であるが、そのオブジェクトが、ある舞台から非近隣舞台に、素早く飛び移ることはあり得ることである。 この場合、そのオブジェクトの追跡ができなくなる。 両方の状況で、必要なことは、非近隣の舞台にあるオブジェクトを見つけ出すシステムであり、かつ、ネットワーク帯域幅や処理要件だけでなく、記憶容量要件を大幅に増やさずにこれを実施することである。

【００１２】

【課題を解決するための手段】本発明の仮想環境制御装置は、少なくとも１つのオブジェクトが存在する舞台から構成されるとともに所定のネットワークを介して外部の端末と接続されている仮想環境の制御を行うための仮想環境制御装置であって、ネットワークに結合されて、
舞台に関する情報を送信するための通信チャネルと、オブジェクトを識別するためのタグを有するビーコンをオブジェクトに割り当てるビーコン割当手段と、ネットワークに結合されて、ビーコンに関する情報を伝送するためのビーコン専用通信チャネルと、ビーコンをビーコン専用通信チャネルに接続する接続手段と、端末に設けられ、タグに基づいてオブジェクトを識別してオブジェクトに関する情報を受信するためのオブジェクト情報受信手段とを備えている。

【００１３】また、ビーコンが、舞台に接続されている通信チャネルを識別するための通信チャネル識別子をさらに備え、オブジェクト情報受信手段が、通信チャネル識別子に基づいて、舞台に接続された通信チャネルを識別するための通信チャネル識別部を備えている。

【００１４】また、ビーコン通信チャネル及びビーコン専用通信チャネルが複数個設けられて多重ビーコンチャネルを構成しており、所定のビーコンからの情報を受信するためにどのビーコン通信チャネルまたはビーコン専用通信チャネルを使用するかを決めるためのビーコン通信チャネル決定手段をさらに備えている。

【００１５】また、ビーコン通信チャネル決定手段が、
ビーコンのタグからビーコン専用通信チャネルへの多数対単数の写像を計算する計算部を備えている。

【００１６】また、舞台のうち、選択した所定の舞台からの情報だけを受信し、それ以外の舞台からの情報を無視するための情報選択受信手段を備えている。

【００１７】また、少なくとも１つのオブジェクトを有する舞台から構成されるとともに所定のネットワークを介して外部の端末と接続されている仮想環境の制御を行うための仮想環境制御装置であって、オブジェクトを識別するためのタグと舞台に接続されている通信チャネルを識別するための通信チャネル識別子とを有するビーコンを、オブジェクトに割り当てるビーコン割当手段を備えている。

【００１８】

【発明の実施の形態】

実施の形態１． 本発明においては、オブジェクトが存在する舞台の通信アドレスによって、仮想的世界にあるオブジェクトに関する全てのメッセージを送ることで生じた問題に対処するように、システムは設計されている。
その問題というのは、あるオブジェクトに関するものを見つけ出すプロセスは、どのような方法であるか、例えば、そのオブジェクトがどの舞台に存在しているかが既に知られていない場合は、それがどの舞台に存在しているかをどのようにして探し出すかである。 本発明におけるこの問題の解は、オブジェクトが、どの舞台に存在しているかを知らなくてもそれを用いることにより探し出せる、ビーコンと呼ばれる特別な等級のオブジェクトを導入したことである。

【００１９】なぜビーコンが必要で、どのようにそれらが使用されるかを下記の例で考える。 仮想世界である人に会って、彼が観光案内するので彼に付いて来てくれるように言ったとする。 彼に追随するための簡単な方法は、副オブジェクトとして、その仮想世界における彼の表現に対して、貴方が見たことを制御する視点（又はＰ
ＯＶ）を付加することである。 そうすれば、貴方の視点は、彼がどこに行ってもそこに行けるし、彼が何を見てもそれを見ることができる。

【００２０】しかし、彼が別の舞台に移動した場合、どうなるだろうか。 貴方のプロセスが、既にその新しい舞台のアドレスと結びつけられている場合は、何の問題もなく、貴方の視点は、彼の表現である副オブジェクトを捉え続け、その新しい舞台にそのまま移動する。 しかし、彼が、貴方のプロセスが結びつけられていない新しい舞台に移った場合には、彼についての情報を何ら受け取ることが出来なくなる。 特に、彼は、視野から消えて、貴方の視点は、特定の舞台で浮遊状態になったままになる。 貴方は彼を見失い、彼を再度見つけ出す方法も無い。

【００２１】下記のように、本発明においては、その関連するオブジェクトがどこに行っても、ビーコンを見つけ出すことを可能にする機能が備えられている。 誰かが、貴方が、彼に追随できるようにしたい場合には、その仮想世界における彼の表現にビーコンを含ませなければならない。 本発明では、特定のビーコンによって、絶え間ない接触が維持されることを要求するために、アプリケーションが使用できる機能が備えられている。

【００２２】後述する実施の形態では、ビーコンは、図２のビーコンメッセージ４８に示すように、２つのキー・フィールド、つまり、そのビーコンの創作者によって指定された識別子であるタグと、そのビーコンを含んでいる舞台の通信アドレスである通信チャネル識別子とを有する。 ビーコンの主な機能は、ビーコンが存在している舞台に関するアドレスに、ビーコン自体に関するメッセージを発信することだけでなく、特別なビーコン通信アドレスにビーコン自体に関するメッセージを発信することである。 なお、この機構が、非常に大規模な仮想環境に、確実に拡大できるように、無制限のビーコン通信アドレスが用意されている。 どのアドレスが使用されるかは、ビーコンのタグ上のハッシング方法を使用することによって、つまり、ビーコンタグから通信アドレスに、多数対単数の写像を使用することにより決定される。

【００２３】デフォルトにより、本装置は、どのビーコン通信アドレスにも接続していない。 本装置においては、「ビーコンを傾聴する（すなわち、ビーコンを監視し、ビーコンからビーコン通信アドレスに発信されるメッセージを受信する）」機能が備わっており、該システムが、特定のタグに対応するビーコン通信アドレスを傾聴することをアプリケーションによって要求することができる。 一旦、システムがビーコン通信アドレスに連結されると、システムは、そのアドレスにメッセージを送り込んでいる全てのビーコンについての情報を保守する。 アプリケーションが、関心のあるビーコンを見つけると、そのアプリケーションは、システムが「舞台のビーコンを傾聴する」機能により、ビーコンを含む舞台の通信アドレスと結合する事を要求できる。 このアプリケーションは、例えば、コンピュータ上のソフトウエアから構成すればよい。 また、このアプリケーションは、本装置において、いずれの通信チャネルを用いてビーコンからの情報を受信するかを決定するためのビーコン通信チャネル決定手段を構成している。

【００２４】ある人が、他の人々が追随できるようにしたいものを構築した場合、その人は、その構造の中でビーコンを重視しなければならない。 例えば、人々を仮想世界の中を周遊させるために仮想の旅行バスを仕立て、
ビーコンをその中に入れるとする。 逆に言えば、ビーコンを含んでいないものを作った場合、人々は確実にそれに追随することはできない。

【００２５】ビーコンシステムによって解決される別の問題は、先ず第一に、他人が所有していたオブジェクトを見つけ出すことの困難さである。 設計者が、他の人々が見つけ出すことを期待するものを設計した場合、ビーコンをその中に入れなければならない。 一旦、これが行われれば、ビーコンがメッセージを送信しているビーコン通信チャネルを傾聴するために、「ビーコンを傾聴する」操作をすることにより、そのビーコンのタグを知っている人は誰でも、そのオブジェクトを見つけ出すことができる。

【００２６】ビーコンに関係する唯一の複雑な事柄は、
タグが、ユーザと通信する方法に関してである。 あるユーザＵが、タグＴを持つビーコンを作成し、別のユーザＶが、このビーコンを見つけ出したいと思っているとする。 ユーザＶが、そのビーコンを見つけ出すために、ユーザＶは、タグＴを知らなければならない。 これを実現するのには、３つの方法がある。

【００２７】先ず、ユーザＶは、何らかの理由でそのビーコンと以前に出会ったことがあって、タグＴを覚えていた場合である。 これは、これ以前に記述した例の状況に対応している。 第二にユーザＵが、ある方法でユーザＶにタグＴについて連絡する場合である。 例えば、ユーザＵは、ある関心のある位置を記述しているメッセージをユーザＶに送り、ユーザＶに参考のためにタグＴの名前を教える場合である。 ユーザＶは、Ｔという名前のタグを持つビーコンを探すことにより、その位置を見つけ出すことができる。 第三の方法は、何らかの方法で、ユーザＶがタグＴについてユーザＵに連絡する場合である。 例えば、ユーザＶは名前Ｔの下で、ある種のサービスの広告をした場合である。 そのときユーザＶは、サービス要求として動作するタグＴを有するビーコンを、探すことになる。

【００２８】まとめると、大規模な仮想環境が舞台を使って構築され、また、非隣接舞台からのデータが計算や局所記憶容量を最小にするために無視される環境において、そのオブジェクトにビーコンを付加して、専用のビーコン通信チャネルでビーコンを放送することにより、
ユーザが傾聴していないオブジェクトや、それらの関係する舞台を見つけ出すか、またはそれらを追尾するために、システムは、識別タグと、必要とされるオブジェクトが存在する舞台の通信アドレスを含み、特定の舞台からデータをアップロードできるビーコンを備えている。
ビーコンは、処理やデータ記憶要件を最小化するために、見つけたいと思われているオブジェクトや、他の人に見つけさせたいと思われているオブジェクトに対して、極力限定して与えている。 無視された舞台は、ビーコンが存在する舞台のアドレスに、それ自体についての情報を送信することに加えて、特別な通信チャネルでメッセージを発信するビーコンを用いて探し出される。 部分空間チャネル情報は、近隣ではないために通常は無視される非近隣舞台へのアクセスを可能にする。 つまり、
ビーコンシステムは、オブジェクトが存在している舞台に関わらず、また、オブジェクトが存在している舞台がアクセスされているか否かに関わらず、あるビーコンを処理している全てのオブジェクトの追尾を可能にするので、同報通信システムによる舞台の無視に起因して、オブジェクトが、見失われることはない。

【００２９】図１は本願発明の舞台用ビーコンを具体的に説明するための図である。 図１を参照すると、建物１
２内に事務所、会議室、その建物の出入口、及び、ボイラー室が設けられており、それらは、それぞれ、舞台１、舞台２、舞台４３、及び、舞台１０３に相当する。
このように、図１には、建物１２を分割して、舞台１、
舞台２、舞台４３、及び、舞台１０３を割り当てた仮想環境１０が描かれている。 例えば、仮想現実の表現において、所望の舞台に、画像オブジェクトの描画を可能にするために、ある舞台から他の舞台へオブジェクトを移動させることができることは重要なことである。 当然のことながら、所定の舞台の範囲内で、画像オブジェクトの配置や移動を可能にするために、舞台は、仮想現実の場面における道具として提供されるので、仮想建物１２
内の小さな一部分で発生する事柄にのみ関係するアプリケーションは、その建物の他の部分で発生する事柄を無視するようにしたので、計算や局所記憶の要件を大幅に軽減し、通信の効率も向上する。

【００３０】上記のように、各舞台又は舞台群と個別の通信アドレスとを関連づけ、また、所定の端末又はアプリケーションが関係している舞台に関連している通信チャネルと単に連結し、それによって、そのチャネルを傾聴するようにすることで、仮想環境と対話している任意の端末又はアプリケーションが必要とする計算と局所記憶の量を削減することができる。 一般に、各舞台には、
所定の通信チャネルに対応する通信アドレスが割り当てられている。 つまり、舞台とその中のオブジェクトは、
その舞台に関連する通信アドレスを通じて、アクセスされ得る。 上記において、興味のない舞台に関連するデータは無視するという考えで、対応するチャネルと接続しないことによって、大部分の舞台からのデータや他の情報は、濾過されてしまう。 その結果、上記のように、オブジェクトが存在する舞台が知られていない場合、そのオブジェクトを見つけ出すことができないことになる。

【００３１】現在の関心事である舞台から遠い舞台に関する情報を、無視したい場合、どの舞台を傾聴するべきなのかを知るまでは、無視された舞台にある画像オブジェクトが、探し出されないという問題が、当然発生する。 この問題は、舞台１で取り扱われるべき管理人１４
の問題があるとすると、舞台１と２だけを傾聴している人では、例えば、管理人１４がいる場所を知る方法がないことが、図１に図解されている。 その管理人１４を必要とする仮想現実の脚本を提案しようとする場合、舞台１におけるアプリケーションは、その建物１２にある全ての舞台についての情報を有する必要があるが、このことは、これら全ての舞台について放送される情報の全てを聞き、さらに記録する事に関連する計算と記憶要件のために、非現実的である。

【００３２】本発明においては、図２に示されるように、関心のある各オブジェクトは、そのオブジェクトが存在している舞台を指定して、特定のビーコン通信チャネル２０を通して、この情報を放送するビーコン１６を備えている。 本装置は、舞台２２、２４及び２６を有する仮想環境を構成するためのコンピュータ（図示せず）
とそれに接続されたディスプレイ等の表示手段（図示せず）と、それらに接続された外部端末４２、４４及び４
６とから構成されている。

【００３３】図２には、複数の舞台２２、２４及び２６
がそれらに関連するオブジェクト２８、３０、３２、３
４及び３６を有しているシステムが示されている。 図から分かるように、オブジェクト２８は、舞台２２における一人の人物（以下、人物２８とする。）であり、その人物２８はビーコン１６を備えている。 同様に、オブジェクト３０及び３２は、舞台２４における人物である。
人物３０及び３２は、ビーコン１６を備える程の関心は持たれていない。 オブジェクト３４は舞台２６における人物であるが、これもビーコン１６を備える程の関心は持たれていない。 一方、オブジェクト３６は舞台２６における人物であるが、適切なビーコン１６を備えている。 また、図２において、４０は、複数のチャネルＡ〜
Ｅを有するチャネル群である。 各舞台２２、２４及び２
６は、チャネル群４０における個別の通信チャネルと関係している。 つまり、例えば、舞台２２からの全情報は、通信チャネルＡで送信される。 この情報は、ネットワークに結合されている端末４２、４４、又は４６において、この舞台２２上の仮想現実場面を再構築するために必要な全ての情報を含んでいることが理解される。 舞台２２におけるビーコン１６に関する情報、すなわちビーコンメッセージ４８は、通信チャネルＡ及びビーコン通信チャネル２０を介して送信される。 また、端末４２
は、チャネルＡとＢからの情報だけを受信し、端末４４
はチャネルＣとＤ、端末４６はチャネルＤとＥからの情報を受信するというようにしてもよい。 この場合、各端末４２、４４及び４６は、全てのチャネルＡ〜Ｅからの情報を受信せずに、少数の特定のチャネルＡ、Ｂ、Ｃ、
ＤまたはＥを選択し、そこからの情報だけを受信しているので、その端末で必要であった計算と局部記憶容量とを大幅に削減できる。

【００３４】しかし、端末４６が、舞台２２にあるオブジェクト２８に関連する画像を再構築するためには、チャネルＡで伝送されるオブジェクト２８についての情報を判定して、チャネルＡの情報を受信し始めることが必要である。 これは、個々のビーコンメッセージ４８が、
タグと、その関連するオブジェクトについての情報のために、傾聴するべきチャネルを指定するチャネル識別子とを含んでいるビーコンを、使用することで実行される。 例えば、ビーコンメッセージ４８の形式を、＜Jani
tor, 127.144.23.01＞としたとする。 これは、そのビーコンに関連するオブジェクトを識別するタグとチャネル及びその関連するオブジェクトについての情報が存在する舞台を識別するネットワーク内アドレスとに対応している。

【００３５】図３には、本装置が、所定のオブジェクト５１に関する情報を放送するための、単一又は複数のチャネルを決定する過程を示すフローチャートが示されている。 本装置においては、ステップＳ５２に示されるように、そのオブジェクト５１が存在している舞台を決定し、次に、ステップＳ５４に示されるように、その舞台に関連する通信チャネルにメッセージを送信する。 ステップＳ５６で、そのオブジェクト５１が、ビーコンを有しているか否かが検査される。 有していなければ、ステップ５８に示すように、次の行動は取られない。 一方、
そのオブジェクト５１が、ビーコンを有している場合は、本装置は、ステップＳ６０に示すように、専用のビーコンチャネルを通して、ビーコンメッセージを送信する。 このタスクは、ＡＮＳＩ Ｃで書かれた下記のサブルーチンによって達成される。

【００３６】 void sendMessagesFor(spId id) { int locale = localeOf(id); if (locale != NOLOCALE) { sendMessage(id, communicationChannelFor[locale]); } if (subclass(getClass(id), spcBeacon)) { sendMessage(id, beaconChannel); } }

【００３７】図４において、ステップＳ６２に示すように、そのオブジェクト５１が、直接的にその舞台に存在しているか否かを確認して、オブジェクト５１が存在する舞台を判定するために、図４のサブルーチンが使用される。 全てのオブジェクトは直接的にそれを含む親領域を有しており、それらの親領域（または、親）はその中に含まれているオブジェクトを示している。 あるオブジェクトの親領域がある１つの舞台である場合は、そのオブジェクトはその舞台に直接的に存在していると呼ぶこととする。 そのオブジェクトが舞台に直接的に存在している場合には、ステップＳ６６に示すように、そのオブジェクトが存在する舞台が、図４のサブルーチンの処理結果として返される。 そうでない場合は、ステップＳ６
４に示すように、そのプロセスは、その親領域が存在している舞台を判断するために、そのオブジェクトの親領域から再帰的に開始することを繰り返す。 最初のオブジェクト５１の舞台を最終的に判定するために、先祖の長い連鎖を探索する必要がある。 それ自体が親を持たないオブジェクトの先祖に、最終的に出会うことはあり得ることである。 その場合、オブジェクト５１は、どの舞台にも存在していないと考えられ、それに関するメッセージは、何も送信されない。 このプロセスを実施するサブルーチンは、ＡＮＳＩ Ｃで書かれ、以下に記述されている。

【００３８】 spId localeOf(spId id) { spId p; for (p=id; p; p=getParent(p)) { if (subclass(getClass(p), spcLocaleLink)) return p; } return NULL; }

【００３９】図５を参照して、端末とその上で動作しているアプリケーションとの観点から見ると、図５のフローチャートは、特定のタグ６１を有するビーコン関連のオブジェクトに関する情報を探すためのその端末又はアプリケーションのビーコンの使用動作の流れを示したものである。 端末又はアプリケーションは、先ず、ステップＳ７２に示すように、特定のビーコンチャネルと連結して、そこに流れているビーコンからのメッセージを受信し始める。 次に、その端末又はアプリケーションは、
ステップＳ７４に示すように、ビーコンチャネル経由の全ビーコンメッセージを読み取り、タグ６１を有するビーコンがあるか否かをステップＳ７６で判断する。 そうであれば、ステップＳ７８に示すように、その端末又はアプリケーションは、ビーコンチャネルを傾聴することを中止し、さらに、ビーコンメッセージの処理も中止するので、その端末又はアプリケーションが探していた情報が、一旦、判定されると、計算時間が節約される。 次に、端末アプリケーションは、ステップＳ８０に示すように、タグ６１を有するビーコンメッセージの中で指定されるチャネルに連結して、そこに流れているメッセージを受信し始める。 その結果、ステップＳ８２に示すように、その端末又はアプリケーションは、その所望のオブジェクトと、そのオブジェクトが存在する舞台関連の全てについてのメッセージを受け取り始めることができる。 このプロセスを実行するサブルーチンは、ＡＮＳＩ
Ｃで書かれ、下記の通りである。

【００４０】 void getInformationRegardingTag(char * tag) { int channel; struct beaconMsg * msg; channel = OpenBeaconChannel(); for (msg = readFrom(channel); ;msg = readFrom(channel)) { if (strcmp(msg->tag, tag)!=0) break; } closeChannel(channel); AssureChannelIsOpen(msg->channel) /* code in other parts of the subject system read messages from every open channel */ }

【００４１】ビーコンを、オブジェクトに割り当てるか否かを決定するための方法を、以下に記述する。 上述したように、全てのオブジェクトにビーコンを与えると、
ビーコンチャネル上を伝達されるデータが膨大な量となってしまうため、これは推奨できない。 しかしながら、
この問題は、２本以上のビーコンチャネルと、通常、ハッシングと呼ばれる、ビーコンタグとビーコンチャネル間の多数対単数の写像を使用することによって、改善され得る。 このアプローチにより、関心のあるタグ６１だけに基づいて、どのビーコンチャネルが傾聴されるべきかを判断できるので、端末又はアプリケーションは、一時に１つのビーコンチャネルを傾聴することだけが必要である。 また、例えば、ハッシングは、そのタグ６１の中のＡＳＣＩＩ文字のチェック・サムを計算して、さらにそのチェック・サムを使用中のビーコンチャネルの数で割ることによって得られる、剰余を計算することによって完了する。 例えば、図１に示す管理人１４を示しているタグ６１のチェック・サムが２０４で、５本のビーコンチャネルが使用されている場合は、２０４を５で割った余りは４であるので、チャネル４を傾聴することになる。 なお、このハッシングは、ビーコンのタグからビーコン専用通信チャネルへの多数対単数の写像を計算する計算部を構成している。

【００４２】資源の乱用となるので、その点からも、全てのオブジェクトに１個ずつのビーコンを与えることは、やはり推奨できない。 ビーコンは、十分に重要なオブジェクトにのみ割り当てられるべきである。 仮想世界の設計者が使う判断基準の１つは、あるオブジェクト５
１が、１つの舞台から他の舞台に移動できるか否かである。 そのオブジェクト５１が移動できない場合は、オブジェクト５１が存在する場所はおのずと予め知られており、ビーコンを使用してそれを探す必要は無い。 二番目の判断基準は、そのオブジェクト５１が、端末又はアプリケーションに十分な関係があって、端末又はアプリケーションが、ビーコンを使ってそれを探したいか否かである。 三番目の判断基準は、オブジェクト５１が、既にビーコンを有する別のオブジェクト５１Ａと関係があり、従って、オブジェクト５１を探すことに関心がある端末又はアプリケーションは、オブジェクト５１Ａのビーコンを使って、オブジェクト５１Ａの位置を探すことによって、オブジェクト５１を探すことができ、そのために、オブジェクト５１はそれ自体のビーコンを必要としないか否かである。

【００４３】上記のことをまとめると、仮想世界において、舞台に関連する個々のチャネル上の通信を通じて、
オブジェクト５１に関する全てのメッセージを送信することは、非常に有効な計算を可能にする一方、大きな問題をも発生させる。 つまり、端末又はアプリケーションは、あるオブジェクト５１に関するもの、例えば、それが存在する舞台を知らない場合に、そのオブジェクト５
１がどの舞台に存在するかを、どのようにして見つけ出すかという問題である。 本装置では、この問題は、ビーコンがどの舞台にいるかを知らなくても、探し出されるビーコンを導入することによって、対処される。

【００４４】なぜビーコンが必要か、またビーコンはどのように使用されるかについて、下記の例で考える。 仮想世界で、ある人に会い、彼が観光案内をするので、後について来るようにと言われたとする。 彼に追随するための簡単な方法は、副オブジェクトとして、その仮想世界における彼を表現しているものに対して、貴方が見たことを制御する視点（又はＰＯＶ）を、付加することである。 そうすれば、貴方の視点は、彼がどこに行ってもそこに行けるし、彼が何を見てもそれを見ることができる。

【００４５】しかし、彼が別の舞台に移動した場合、どうなるだろうか。 貴方のプロセスが、既にその新しい舞台に関連する通信チャネルと連結されている場合は、何の問題も無い。 貴方の視点は、彼の表現である副オブジェクトを捉え続け、その新しい舞台に疑いもなく移動する。 しかし、彼が、貴方のプロセスが結びつけられていない、新しい舞台に移った場合には、貴方は、彼についての情報を何ら受け取れなくなり、彼は、貴方の視野から消える。 貴方の視点は、特定の舞台で浮遊状態になったままになる。 貴方は彼を見失い、彼を再度見つけ出す方法も無い。

【００４６】本装置は、ビーコンがどこに行っても、ビーコンを見つけ出すことを可能にする機能を備えている。 誰かが、貴方が彼に追随できるようにしたい場合には、その仮想世界における彼を表現しているものに、ビーコンを含ませなければならない。

【００４７】本装置においては、ビーコンは、下記の項目（要素）を有する： タグ − そのビーコンの創作者によって指定された識別子 アドレス − そのビーコンを含んでいる舞台に使用される通信チャネルの通信アドレス

【００４８】ビーコンの主な機能は、ビーコンが存在している舞台にビーコン自体に関するメッセージを流すだけでなく、特定のビーコン通信アドレスに、ビーコン自体に関するメッセージを送信することである。 この機構を、非常に大規模な仮想環境にも確実に拡大できるように無制限のビーコン通信アドレスが用意されている。 例えば、使用されるアドレスを、ビーコンのタグに関するハッシングによって決定するようにしてもよい。

【００４９】デフォルトにより（すなわち、特別に設定しなければ）、本装置は、どのビーコン通信アドレスにも接続していない。 図５に示すようなサブルーチンが備わっているので、本装置が特定のタグに対応するビーコン通信アドレスを傾聴することをアプリケーションから要求することができる。 一旦、本装置が、ビーコン通信アドレスを傾聴すると、本装置は、そのアドレスにメッセージを送っている全てのビーコンに関する、世界モデルにおける情報を保守する。 端末又はアプリケーションが、関心のあるビーコンを見つけると、その端末又はアプリケーションは、本装置が、ビーコンを含む舞台の通信アドレスと結合する事を要求できる。

【００５０】ビーコンに関係する唯一の複雑な事柄は、
タグ６１が、ユーザ間で授受される方法に関してである。 あるユーザＵが、タグ６１を持つビーコンを作成し、別のユーザＶがこのビーコンを見つけ出そうとしているとする。 ユーザＶが、そのビーコンを見つけ出すために、ユーザＶは、タグ６１を知らなければならない。
これを実現するには、以下の３つの方法がある。

【００５１】先ず、ユーザＶは、何らかの他の理由で、
そのビーコンと以前に出会ったことがあり、タグ６１を覚えている場合について説明する。 この場合は、上述した例の図１の管理人１４を見つけ出す問題に対応している。 第二に、ユーザＵが、ある方法でユーザＶにタグ６
１について連絡する場合である。 例えば、ユーザＵは、
ある関心のある位置を記述しているメッセージをユーザＶに送り、ユーザＶに参考のためにタグ６１の名前Ｔを教えた場合である。 ユーザＶは、Ｔという名前のタグ６
１を持つビーコンを探すことにより、その位置を見つけ出すことができる。 第三の方法は、何らかの方法で、ユーザＶが、タグ６１についてユーザＵに連絡する場合である。 例えば、ユーザＶが、タグ６１の名前Ｔの下で、
ある種のサービスの広告をした場合である。 そのときユーザＶは、サービス要求として動作するタグ６１を有するビーコンを、探すはずである。

【００５２】上述した本発明の好ましい実施例のように、変形や変更が、本発明の精神の範囲内で実施できることは、明らかである。 従って、請求項で述べたことのみが、本発明の範囲を規定するものである。

【００５３】

【発明の効果】この発明の仮想環境制御装置によれば、
少なくとも１つのオブジェクトが存在する舞台から構成されるとともに所定のネットワークを介して外部の端末と接続されている仮想環境の制御を行うための仮想環境制御装置であって、ネットワークに結合されて、舞台に関する情報を送信するための通信チャネルと、オブジェクトを識別するためのタグを有するビーコンをオブジェクトに割り当てるビーコン割当手段と、ネットワークに結合されて、ビーコンに関する情報を伝送するためのビーコン専用通信チャネルと、ビーコンをビーコン専用通信チャネルに接続する接続手段と、端末に設けられ、タグに基づいてオブジェクトを識別してオブジェクトに関する情報を受信するためのオブジェクト情報受信手段とを備えているので、すべての舞台からの情報を受信しなくても、ビーコンを用いることにより、少ない所定の情報量で、オブジェクトがどの舞台にいるのかを容易に捜し出すことができるという効果を奏する。

【００５４】また、ビーコンが、舞台に接続されている通信チャネルを識別するための通信チャネル識別子をさらに備え、オブジェクト情報受信手段が、通信チャネル識別子に基づいて、舞台に接続された通信チャネルを識別するための通信チャネル識別部を備えるようにしたので、オブジェクトがどの舞台に存在しているか分からない場合にも、このビーコンにより、容易に探し出すことができる。

【００５５】また、ビーコン通信チャネル及びビーコン専用通信チャネルが複数個設けられて多重ビーコンチャネルを構成しており、所定のビーコンからの情報を受信するためにどのビーコン通信チャネルまたはビーコン専用通信チャネルを使用するかを決めるためのビーコン通信チャネル決定手段をさらに備えているので、ビーコンからの情報が必要なときに、ビーコン通信チャネル決定手段によりいずれの通信チャネルで受信するか決めればよく、不必要な情報をも含むすべての情報を受信するわけではないので、効率的に通信を行うことができる。

【００５６】また、ビーコン通信チャネル決定手段が、
ビーコンのタグからビーコン専用通信チャネルへの多数対単数の写像を計算する計算部を備えているので、ビーコンのタグとビーコンチャネル間が多数対単数であっても、どの通信チャネルを使用すべきかをタグだけを用いて容易に決定することができる。

【００５７】また、舞台のうち、選択した所定の舞台からの情報だけを受信し、それ以外の舞台からの情報を無視するための情報選択受信手段を備えているので、不必要な情報をも含むすべての情報を受信するわけではないので、効率的に必要な情報だけの通信を行うことができる。

【００５８】また、少なくとも１つのオブジェクトを有する舞台から構成されるとともに所定のネットワークを介して外部の端末と接続されている仮想環境の制御を行うための仮想環境制御装置であって、オブジェクトを識別するためのタグと舞台に接続されている通信チャネルを識別するための通信チャネル識別子とを有するビーコンを、オブジェクトに割り当てるビーコン割当手段を備えているので、すべての舞台からの情報を受信しなくても、ビーコンを用いることにより、少ない所定の情報量で、オブジェクトがどの舞台にいるのかを容易に捜し出すことができる。

【図面の簡単な説明】

【図１】 ビーコンを有する管理人がある舞台に存在している仮想環境の一例を示した図である。

【図２】 仮想環境における各舞台と端末とを接続しているチャネル群を示したブロック図である。

【図３】 オブジェクトに関する情報を送信するためのチャネル決定動作を示した流れ図である。

【図４】 オブジェクトの親領域、祖父母領域、曾祖父母領域等の連鎖を検索することにより、そのオブジェクトが存在している舞台を決定する動作を示した流れ図である。

【図５】 アプリケーションが関心のあるオブジェクトを探し出すために、ビーコンを使用する動作を示した流れ図である。

【符号の説明】

１，２，４３，１０３ 舞台、１０ 仮想環境、１２
建物、１４ 管理人、１６ ビーコン。

フロントページの続き (71)出願人 595151497 201 ＢＲＯＡＤＷＡＹ， ＣＡＭＢＲＩ ＤＧＥ， ＭＡＳＳＡＣＨＵＳＥＴＴＳ 02139， Ｕ． Ｓ． Ａ.