JP2023075441A - 情報処理システム、情報処理方法、情報処理プログラム - Google Patents

Abstract

【課題】情報処理を介して仮想空間におけるユーザ間の交流を促進する。【解決手段】仮想空間に、第１ユーザに対応付けられる第１表示媒体と、第２ユーザに対応付けられる第２表示媒体とを位置付ける位置管理部と、仮想空間における第１表示媒体と第２表示媒体のそれぞれの位置、及び、仮想空間における第１表示媒体と第２表示媒体との第１相対位置関係、の少なくともいずれか一方が、第１所定条件を満たすか否かを判定する第１判定部と、第１判定部により第１所定条件が満たされたと判定された場合に、第１表示媒体と第２表示媒体とを含む複数の表示媒体により連携して実現可能な所定イベントを発生させるイベント発生部とを備える、情報処理システムが開示される。【選択図】図１１

Description

特許法第３０条第２項適用申請有り （１）ウェブサイトの掲載日：令和３年（２０２１年）７月１日 ウェブサイトのアドレス：ｈｔｔｐｓ：／／ｗｗｗ．ｍｏｒｉ．ｃｏ．ｊｐ／ｃｏｍｐａｎｙ／ｐｒｅｓｓ／ｒｅｌｅａｓｅ／２０２１／０７／２０２１０７０１１４００００００４２０２．ｈｔｍｌ

特許法第３０条第２項適用申請有り （２）ウェブサイトの掲載日：令和３年（２０２１年）７月１日 ウェブサイトのアドレス：ｈｔｔｐｓ：／／ｗｗｗ．ｍｏｒｉ．ｃｏ．ｊｐ／ｉｍｇ／ａｒｔｉｃｌｅ／２１０７０１＿２．ｐｄｆ）

特許法第３０条第２項適用申請有り （３）ウェブサイトの掲載日：令和３年（２０２１年）７月１日 ウェブサイトのアドレス：ｈｔｔｐｓ：／／ｅｖｅｎｔｒｅｇｉｓｔ．ｃｏｍ／ｅ／２０７ｎＥ１ｈ７４ＰＥＤ）

特許法第３０条第２項適用申請有り （４）ウェブサイトの掲載日：令和３年（２０２１年）７月１日 ウェブサイトのアドレス ｈｔｔｐｓ：／／ｔｗｉｔｔｅｒ．ｃｏｍ／ＶＲＳｔｕｄｉｏＬａｂ／ｓｔａｔｕｓ／１４１０５５４１５５６８５４０４６８０ ｈｔｔｐｓ：／／ｔｗｉｔｔｅｒ．ｃｏｍ／ＶＲＳｔｕｄｉｏＬａｂ／ｓｔａｔｕｓ／１４１０５４１０２２９７５６９２８０２

特許法第３０条第２項適用申請有り （５）ウェブサイトの掲載日：令和３年（２０２１年）７月１日 ウェブサイトのアドレス：ｈｔｔｐｓ：／／ｖｒ．ｇｒｅｅ．ｎｅｔ／ｌａｂ／ｌｉｖｅ／ｋｗｓ２０２１／

特許法第３０条第２項適用申請有り （６）ウェブサイトの掲載日：令和３年（２０２１年）７月６日 ウェブサイトのアドレス：ｈｔｔｐｓ：／／ｃｏｒｐ．ｇｒｅｅ．ｎｅｔ／ｊｐ／ｊａ／ｎｅｗｓ／ｉｎｆｏ／２０２１／０７０６－０１．ｈｔｍｌ

特許法第３０条第２項適用申請有り （７）ウェブサイトの掲載日：令和３年（２０２１年）７月６日 ウェブサイトのアドレス：ｈｔｔｐｓ：／／ｔｗｉｔｔｅｒ．ｃｏｍ／ＶＲＳｔｕｄｉｏＬａｂ／ｓｔａｔｕｓ／１４１２２１７９４４６２９６６９８９２

特許法第３０条第２項適用申請有り （８）ウェブサイトの掲載日：令和３年（２０２１年）７月２日及び８月２６日 オンライン開催日：令和３年（２０２１年）８月２５日 ウェブサイトのアドレス：（７月２日：８月２５日オンライン開催のインタラクティブセッションによる発明者の講演の紹介） ｈｔｔｐｓ：／／ｃｅｄｅｃ．ｃｅｓａ．ｏｒ．ｊｐ／２０２１／ｓｅｓｓｉｏｎ／ｄｅｔａｉｌ／ｓ６０６４２５ｂ１３３ｃ６３ （８月２６日：上記インタラクティブセッションの動画配信） ｈｔｔｐｓ：／／ｙｏｕｔｕ．ｂｅ／ＰＹｊｑｚＡｗＭｌｔｓ ｈｔｔｐｓ：／／ｙｏｕｔｕ．ｂｅ／ＰＹｊｑｚＡｗＭｌｔｓ？ｔ＝４３１

特許法第３０条第２項適用申請有り （９）ウェブサイトの掲載日：令和３年（２０２１年）９月９日 ウェブサイトのアドレス：ｈｔｔｐｓ：／／ｃｏｒｐ．ｇｒｅｅ．ｎｅｔ／ｊｐ／ｊａ／６ｄｅｇｒｅｅｓ／２０２１／０９／０２．ｈｔｍｌ

特許法第３０条第２項適用申請有り （１０）ウェブサイトの掲載日：令和３年（２０２１年）８月２６日 基調講演開催日：令和３年（２０２１年）９月９日 ウェブサイトのアドレス：（８月２６日：９月９日開催の発明者の基調講演の紹介） ｈｔｔｐｓ：／／ｉｃａｔ－ｅｇｖｅ－２０２１．ｏｒｇ／ｉｎｄｅｘ．ｐｈｐ／ｋｅｙｎｏｔｅｓ／

特許法第３０条第２項適用申請有り （１１）ウェブサイトの掲載日：令和３年（２０２１年）９月２２日 ウェブサイトのアドレス：ｈｔｔｐｓ：／／ｙｏｕｔｕ．ｂｅ／ＵｃｕＨＩＷ３ＨＧＰ４

特許法第３０条第２項適用申請有り （１２）ウェブサイトの掲載日：令和３年（２０２１年）９月２２日 ウェブサイトのアドレス：ｈｔｔｐｓ：／／ｔｗｉｔｔｅｒ．ｃｏｍ／ＶＲＳｔｕｄｉｏＬａｂ／ｓｔａｔｕｓ／１４４０６９１８６４１３５３７２８００？ｓ＝２０

特許法第３０条第２項適用申請有り （１３）ウェブサイトの掲載日：令和３年（２０２１年）１０月６日 ウェブサイトのアドレス：ｈｔｔｐｓ：／／ｎｏｔｅ．ｃｏｍ／ｒｅａｌｉｔｙ＿ｅｎｇ／ｎ／ｎｆｅ６ａａ７０８１０７ａ

特許法第３０条第２項適用申請有り （１４）ウェブサイトの掲載日：令和３年（２０２１年）８月４日 講義開催日：令和３年（２０２１年）１０月６、１３、２０日 ウェブサイトのアドレス：（８月４日：１０月６、１３、２０日開催の発明者の講義の紹介） ｈｔｔｐ：／／ｗｗｗ．ｇｈｒｄ．ｔｉｔｅｃｈ．ａｃ．ｊｐ／２０２１／０８／ｇａｔｉ６／

特許法第３０条第２項適用申請有り （１５）ウェブサイトの掲載日：令和３年（２０２１年）１０月１８日 セッション開催日：令和３年（２０２１年）１１月１１日 ウェブサイトのアドレス：（１０月１８日：１１月１１日開催の発明者のショートセッション８の紹介）ｈｔｔｐｓ：／／ｇｒｅｅ．ｃｏｎｎｐａｓｓ．ｃｏｍ／ｅｖｅｎｔ／２２５９１２／ （１１月１１日：１１月１１日開催の発明者のショートセッション８の動画） ｈｔｔｐｓ：／／ｔｅｃｈｃｏｎ．ｇｒｅｅ．ｊｐ／２０２１／ ｈｔｔｐｓ：／／ｔｅｃｈｃｏｎ．ｇｒｅｅ．ｊｐ／２０２１／ｓｅｓｓｉｏｎ／ＳｈｏｒｔＳｅｓｓｉｏｎ－８

本開示は、情報処理システム、情報処理方法、情報処理プログラムに関する。

動画の共同配信を行う複数のユーザに対応する複数のアバターの各々の３Ｄモデルに基づいて各アバターを描画すると共に、複数のユーザによってそれぞれ入力される入力情報に基づいて当該複数のアバターの各々の動作を制御し、これらの複数のアバターが含まれる仮想空間に対応する動画を生成する技術が知られている。

特開２０１９－２０４２４４号公報

ところで、複数のアバターのような表示媒体を介して仮想空間で活動する場合、情報処理を介して、表示媒体を介したユーザ間の交流が促進されるような仕組みを提供することが有用である。

そこで、１つの側面では、本開示は、情報処理を介して仮想空間におけるユーザ間の交流を促進することを目的とする。

１つの側面では、仮想空間に、第１ユーザに対応付けられる第１表示媒体と、第２ユーザに対応付けられる第２表示媒体とを位置付ける位置管理部と、
各ユーザから各種入力を取得する入力取得部と、
前記第１表示媒体に対応付けられる第１視点から視た前記仮想空間の画像を含む第１表示画像であって、前記第１ユーザにより視認可能な第１表示画像を生成する第１画像条件生成部と、
前記第２表示媒体に対応付けられる第２視点から視た前記仮想空間の画像を含む第２表示画像であって、前記第２ユーザにより視認可能な第２表示画像を生成する第２画像条件生成部と、
前記仮想空間における前記第１表示媒体と前記第２表示媒体のそれぞれの位置、及び、前記仮想空間における前記第１表示媒体と前記第２表示媒体との第１相対位置関係、の少なくともいずれか一方が、第１所定条件を満たすか否かを判定する第１判定部と、
前記第１判定部により前記第１所定条件が満たされたと判定された場合に、前記第１表示媒体と前記第２表示媒体とを含む複数の表示媒体により連携して実現可能な所定イベントを発生させるイベント発生部とを備える、情報処理システムが提供される。

１つの側面では、本開示によれば、情報処理を介して仮想空間におけるユーザ間の交流を促進することが可能となる。

本実施形態に係る仮想現実生成システムのブロック図である。 仮想現実生成システムを利用する２人のユーザの一例の説明図である。 図２に示した２人のユーザがヘッドマウントディスプレイを装着して仮想空間の画像を見ている状態を模式的に示す図である。 端末用画像の一例を示す図である。 本実施形態で好適な端末用画像の一例の説明図である。 ４人のユーザが同じ仮想空間を共有しているときの第１ユーザ用の端末用画像の一例の説明図である。 画像取得イベントの説明図（その１）である。 画像取得イベントの説明図（その２）である。 アイテム取得イベントの説明図（その１）である。 アイテム取得イベントの説明図（その２）である。 画像取得イベント及びアイテム取得イベントに関連したサーバ装置の機能ブロック図である。 画像取得イベント及びアイテム取得イベントに関連した端末装置の機能ブロック図である。 ユーザデータベース内のデータの説明図である。 アバターデータベース内のデータの説明図である。 撮影配置処理の説明図（その１）である。 撮影配置処理の説明図（その２）である。 第１相対位置関係の算出方法の説明図（その１）である。 第１相対位置関係の算出方法の説明図（その２）である。 進行型ミッションモードの説明図である。 画像データ記憶部に記憶されるイベント画像データに係る画像生成条件の説明図である。 分担態様が異なるサーバ装置の一例の機能ブロック図である。 分担態様が異なる端末装置の一例の機能ブロック図である。 分担態様が異なる端末装置の他の一例の機能ブロック図である。 分担態様が異なるサーバ装置の他の一例の機能ブロック図である。 分担態様が異なる端末装置の他の一例の機能ブロック図である。 画像取得イベントの発生に関する仮想現実生成システムの動作例を概略的に示すタイミングチャートである。 アイテム取得イベントの発生に関する仮想現実生成システムの動作例を概略的に示すタイミングチャートである。 変形例によるサーバ装置の機能ブロック図である。 広告情報記憶部内のデータの説明図である。 変形例による端末装置の機能ブロック図である。

以下、実施形態について図面を参照して説明する。

（仮想現実生成システムの概要）
図１は、本実施形態に係る仮想現実生成システム１のブロック図である。仮想現実生成システム１は、サーバ装置１０と、１つ以上の端末装置２０と、を備える。図１では簡便のため、３つの端末装置２０を図示しているが、端末装置２０の数は２つ以上であればよい。

サーバ装置１０は、例えば１つ以上の仮想現実を提供する運営者が管理するサーバ等である。端末装置２０は、例えば携帯電話、スマートフォン、タブレット端末、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、ヘッドマウントディスプレイ、又はゲーム装置等の、ユーザによって使用される装置である。端末装置２０は、典型的にはユーザごとに異なる態様で、複数がサーバ装置１０にネットワーク３を介して接続されうる。

端末装置２０は、本実施形態に係る仮想現実アプリケーションを実行可能である。仮想現実アプリケーションは、ネットワーク３を介してサーバ装置１０や所定のアプリケーション配信サーバから端末装置２０に受信されてもよく、あるいは端末装置２０に備えられた記憶装置又は端末装置２０が読取可能なメモリカード等の記憶媒体にあらかじめ記憶されていてもよい。サーバ装置１０及び端末装置２０は、ネットワーク３を介して通信可能に接続される。例えば、サーバ装置１０及び端末装置２０が協動して、仮想現実に関する多様な処理を実行する。

なお、ネットワーク３は、無線通信網や、インターネット、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでよい。

ここで、本実施形態に係る仮想現実の概要について説明する。本実施形態に係る仮想現実は、例えば教育、旅行、ロールプレイング、シミュレーション、ゲームやコンサートのようなエンターテインメント等、任意の現実に対する仮想現実等であって、仮想現実の実行に伴い、アバターのような仮想現実媒体が用いられる。例えば、本実施形態に係る仮想現実は、３次元の仮想空間と、当該仮想空間内に登場する各種の仮想現実媒体と、当該仮想空間内で提供される各種のコンテンツとにより実現される。

仮想現実媒体は、仮想現実に使用される電子データであり、例えば、カード、アイテム、ポイント、サービス内通貨（又は仮想現実内通貨）、トークン（例えばＮｏｎ－Ｆｕｎｇｉｂｌｅ Ｔｏｋｅｎ（ＮＦＴ））、チケット、キャラクタ、アバター、パラメータ等、任意の媒体を含む。また、仮想現実媒体は、レベル情報、ステータス情報、仮想現実パラメータ情報（体力値及び攻撃力等）又は能力情報（スキル、アビリティ、呪文、ジョブ等）のような、仮想現実関連情報であってもよい。また、仮想現実媒体は、ユーザによって仮想現実内で取得、所有、使用、管理、交換、合成、強化、売却、廃棄、又は贈与等され得る電子データであるが、仮想現実媒体の利用態様は本明細書で明示されるものに限られない。なお、以下では、仮想現実媒体のうちの、仮想空間において描画可能な媒体を、表示媒体と称する場合がある。

（サーバ装置の構成）
サーバ装置１０の構成について具体的に説明する。サーバ装置１０は、サーバコンピュータにより構成される。サーバ装置１０は、複数台のサーバコンピュータにより協動して実現されてもよい。例えば、サーバ装置１０は、各種のコンテンツを提供するサーバコンピュータや、各種の認証サーバを実現するサーバコンピュータ等により協動して実現されてもよい。また、サーバ装置１０は、Ｗｅｂサーバを含んでよい。この場合、後述する端末装置２０の機能の一部は、Ｗｅｂサーバから受領したＨＴＭＬ文書やそれに付随する各種プログラム（ＪａｖａＳｃｒｉｐｔ（登録商標））をブラウザが処理することによって実現されてもよい。

サーバ装置１０は、サーバ通信部１１と、サーバ記憶部１２と、サーバ制御部１３と、を備える。

サーバ通信部１１は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。サーバ通信部１１は、例えば無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）通信モジュール又は有線ＬＡＮ通信モジュール等を含んでもよい。サーバ通信部１１は、ネットワーク３を介して、端末装置２０との間で情報を送受信可能である。

サーバ記憶部１２は、例えば記憶装置であって、仮想現実に係る各種処理に必要な種々の情報及びプログラムを記憶する。例えばサーバ記憶部１２は、仮想現実アプリケーションを記憶する。

例えば、サーバ記憶部１２は、各ユーザに対応付けられる仮想現実媒体としてのユーザアバターＭ１（表示媒体の一例）の描画情報を記憶する。なお、ユーザとは、仮想現実生成システム１のユーザである。ユーザは、一般的なユーザに加えて、仮想現実生成システム１の運営者に関連してアバターを操作する管理ユーザ等を含んでもよい。仮想空間内にユーザアバターＭ１は、ユーザアバターＭ１の描画情報に基づいて描画される。

また、サーバ記憶部１２は、例えば各種アイテム又はＮＰＣ（Ｎｏｎ Ｐｌａｙｅｒ Ｃｈａｒａｃｔｅｒ）等のような、ユーザアバターＭ１とは異なる各種のオブジェクトに係る描画情報を記憶する。仮想空間内に各種のオブジェクトは、かかる描画情報に基づいて描画される。

サーバ制御部１３は、専用のマイクロプロセッサ又は特定のプログラムを読み込むことにより特定の機能を実現するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）や、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等を含んでよい。例えばサーバ制御部１３は、端末装置２０と協動して、端末装置２０の表示部２３に対するユーザ操作に応じて仮想現実アプリケーションを実行する。また、サーバ制御部１３は、仮想現実に関する多様な処理を実行する。サーバ制御部１３の具体的な処理の詳細は後述する。

（端末装置の構成）
端末装置２０の構成について説明する。図１に示すように、端末装置２０は、端末通信部２１と、端末記憶部２２と、表示部２３と、入力部２４と、端末制御部２５とを備える。

端末通信部２１は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。端末通信部２１は、例えばＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）（登録商標）や、ＬＴＥ－Ａ（ＬＴＥ－Ａｄｖａｎｃｅｄ）、第五世代移動通信システム、ＵＭＢ（Ｕｌｔｒａ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）等のモバイル通信規格に対応する無線通信モジュール、無線ＬＡＮ通信モジュール、又は有線ＬＡＮ通信モジュール等を含んでもよい。端末通信部２１は、ネットワーク３を介して、サーバ装置１０との間で情報を送受信可能である。

端末記憶部２２は、例えば一次記憶装置及び二次記憶装置を含む。例えば端末記憶部２２は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。端末記憶部２２は、サーバ装置１０から受信する、仮想現実の処理に用いられる種々の情報及びプログラムを記憶する。仮想現実の処理に用いられる情報及びプログラムは、端末通信部２１を介して外部装置から取得されてもよい。例えば、仮想現実アプリケーションプログラムが、所定のアプリケーション配信サーバから取得されてもよい。以下、アプリケーションプログラムを、単にアプリケーションともいう。また、例えば、上述したユーザに関する情報及び他のユーザの仮想現実媒体に関する情報等の一部又は全部が、サーバ装置１０から取得されてもよい。

表示部２３は、例えば液晶ディスプレイ又は有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等の表示デバイスを含む。表示部２３は、多様な画像を表示可能である。表示部２３は、例えばタッチパネルで構成され、多様なユーザ操作を検出するインタフェースとして機能する。なお、表示部２３は、ヘッドマウントディスプレイの形態であってもよい。

入力部２４は、例えば表示部２３と一体的に設けられたタッチパネルを含む入力インタフェースを含む。入力部２４は、端末装置２０に対するユーザ入力を受付可能である。また、入力部２４は、物理キーを含んでもよいし、マウス等のようなポインティングデバイスをはじめとする任意の入力インタフェースを更に含んでもよい。また、入力部２４は、音声入力やジェスチャ入力のような、非接触型のユーザ入力を受付可能であってもよい。なお、ジェスチャ入力には、ユーザの身体の動きを検出するためのセンサ（画像センサや、加速度センサ、距離センサ等）が利用されてもよい。この場合、入力部２４は、端末装置２０に内蔵される加速度センサやジャイロセンサ等により実現されてもよい。

端末制御部２５は、１つ以上のプロセッサを含む。端末制御部２５は、端末装置２０全体の動作を制御する。

端末制御部２５は、端末通信部２１を介して情報の送受信を行う。例えば、端末制御部２５は、仮想現実に係る各種処理に用いられる種々の情報及びプログラムを、サーバ装置１０及び他の外部サーバの少なくとも一方から受信する。端末制御部２５は、受信された情報及びプログラムを、端末記憶部２２に記憶する。例えば、端末記憶部２２には、Ｗｅｂサーバに接続するためのブラウザ（インターネットブラウザ）が格納されてよい。

端末制御部２５は、ユーザの操作に応じて仮想現実アプリケーションを起動する。端末制御部２５は、サーバ装置１０と協動して、仮想現実に係る各種処理を実行する。例えば、端末制御部２５は、仮想空間の画像を表示部２３に表示させる。画面上には、例えばユーザ操作を検出するＧＵＩ（Ｇｒａｐｈｉｃ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）が表示されてもよい。端末制御部２５は、入力部２４を介して、画面に対するユーザ操作を検出可能である。例えば端末制御部２５は、ユーザのタップ操作、ロングタップ操作、フリック操作、及びスワイプ操作等を検出可能である。タップ操作は、ユーザが指で表示部２３に触れ、その後に指を離す操作である。端末制御部２５は、操作情報をサーバ装置１０に送信する。

（仮想空間の例）
サーバ制御部１３は、端末装置２０と協動して、表示部２３上に仮想空間の画像を表示し、仮想現実の進行やユーザの操作に応じて仮想空間の画像を更新していく。本実施形態では、サーバ制御部１３は、端末装置２０と協動して、３次元の仮想空間に配置されるオブジェクトを、仮想空間に配置された仮想カメラから視た表現で描画する。

なお、以下で説明する描画処理は、サーバ制御部１３により実現されるが、他の実施形態では、以下で説明する描画処理の一部又は全部がサーバ制御部１３により実現されてもよい。なお、以下の説明において、端末装置２０に表示される仮想空間の画像の少なくとも一部を、サーバ装置１０が生成したデータに基づいて端末装置２０に表示させるウェブ表示とし、画像の少なくとも一部を、端末装置２０にインストールされているネイティブアプリケーションによって表示させるネイティブ表示としてもよい。

図２は、仮想現実生成システム１を利用する２人のユーザの一例の説明図である。図３は、図２に示した２人のユーザがヘッドマウントディスプレイ２３Ａを装着して仮想空間の画像を見ている状態を模式的に示す図である。なお、ここでは、２人のユーザが仮想空間を共有する態様を説明するが、３人以上のユーザが仮想空間を共有する態様や、一人だけで仮想空間を専有する態様にも適用可能である。

図２には、実空間において２人のユーザが地球上の離れた位置にいることが模式的に示されている。本実施形態では、このように実空間において離れた位置Ｐ１、Ｐ２にいる２人のユーザが、同じ仮想空間内で交流できる。

本実施形態では、ヘッドマウントディスプレイ２３Ａを装着した２人のユーザは、ユーザアバターＭ１の形態で、仮想空間内で活動することができる。図３には、実空間において離れた位置にいる２人のユーザが、共通の仮想空間３００の画像を見ている状態が模式的に示されている。なお、本実施形態では、ユーザが仮想空間の画像を視るための手段としてヘッドマウントディスプレイ２３Ａを利用するが、他の表示デバイス（例えばＰＣのディスプレイ）が利用されてもよい。

図４は、ヘッドマウントディスプレイ２３Ａ用の画像（以下、「端末用画像」とも称する）の説明図であり、端末用画像の一例を示す図である。図４では、仮想空間の一部がユーザアバターＭ１とともに描画されている。端末用画像の生成方法は後述する。

本実施形態では、例えば、図４に示すように、左右の目でそれぞれ視認される画像Ｇ２００、Ｇ２０１を生成することで、立体視画像を生成してよい。図４には、左右の目でそれぞれ視認される画像Ｇ２００、Ｇ２０１が模式的に示されている。なお、以下では、特に言及しない限り、端末用画像として生成される仮想空間の画像とは、画像Ｇ２００、Ｇ２０１で表現される画像全体を指す。

図５は、本実施形態で好適な端末用画像の一例の説明図である。なお、図５に示す端末用画像は、一のユーザ用の画像（一のユーザがヘッドマウントディスプレイ２３Ａを介して見る端末用画像）であってよい。

本実施形態では、端末用画像は、図５に模式的に示すように、好ましくは、実空間の写真又はＣＧ（コンピュータグラフィック）に基づくリアルな画像を含む。例えば、端末用画像は、実在する場所の画像である。これにより、ユーザは、あたかもその場所にいるかのような錯覚を得ることができる。その結果、各ユーザによる仮想空間での活動範囲が広がる等、活動の活性化を促進できる。

本実施形態では、端末用画像は、実空間の写真又はＣＧをベースとしたリアルな画像（以下、「実空間画像」と称する）をベースとし、実空間画像に、適宜、ＧＵＩとして機能するインタフェース画像やユーザアバターＭ１等を重畳する態様（例えばＪａｖａＳｃｒｉｐｔ（登録商標）上で合成する態様）で形成される。実空間画像は、例えば、Ｇｏｏｇｌｅ社が提供する“Ｇｏｏｇｌｅ Ｓｔｒｅｅｔ Ｖｉｅｗ Ｉｍａｇｅ ＡＰＩ”又はその類のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を利用して取得されてよい。この場合、指定した緯度や経度、Ｐａｎｏ（パノラマ）ＩＤなどから取得したストリートビューの画像を実空間画像として取り込むことができる。

ただし、変形例では、実空間画像に代えて、実空間とは一部又は全体が対応していない空間の画像が利用されてもよい。例えば、ゲームの仮想空間やメタバースの３次元空間の画像が利用されてもよい。また、実空間画像についても、現時点の実空間に対応する画像だけでなく、過去の実空間や未来の予想に基づく実空間に対応する画像であってもよい。

本実施形態では、一のユーザが見る端末用画像の実空間画像が、実在する場所の画像であるとき、一のユーザに対応するユーザアバターＭ１の位置は、実空間画像に対応付けられた位置情報に対応付けられる。例えば、一のユーザが見る端末用画像の実空間画像が、東京タワーの画像であるとき、一のユーザに対応するユーザアバターＭ１は、東京タワーが見える場所に位置することになる。従って、以下の説明において、一のユーザに対応する一のユーザアバターＭ１が、ある場所に移動するとは、当該一のユーザに対応する端末用画像が、当該場所に係る画像となることと実質的に同義である。このようにして、ユーザは、ユーザアバターＭ１を介して、仮想空間における各種場所に行くことができる。

図６は、４人のユーザが同じ仮想空間を共有しているときの、一のユーザ（以下、第１ユーザ）用の端末用画像Ｇ６００の一例の説明図である。

図６に示す端末用画像Ｇ６００は、実空間画像Ｇ６０１上に、第１ユーザに対応するユーザアバターＭ１（以下、「第１ユーザアバターＭ１」とも称する）（第１表示媒体の一例）を示す画像Ｇ６１０と、第１ユーザにより操作可能なＧＵＩであるユーザインタフェースＧ６１１、Ｇ６１２と、方向案内画像Ｇ６１４と、距離案内画像Ｇ６１５と、フレンド案内画像Ｇ６１６とを含む。

画像Ｇ６１０は、第１ユーザに、自身のユーザアバターＭ１を認識させるための画像である。なお、画像Ｇ６１０は、省略されてもよい。

ユーザインタフェースＧ６１１は、第１ユーザにより操作可能な各種操作ボタンＢ６０１からＢ６０３を含む。操作ボタンＢ６０１は、フレンド案内画像Ｇ６１６の表示状態をオン／オフするためのボタンである。操作ボタンＢ６０２は、シャッタボタンであり、後述する記念撮影のような写真撮影（仮想空間内での写真撮影）を行う際に操作される。操作ボタンＢ６０３は、記念撮影で得られた写真又は動画を閲覧等するためのボタンである。以下、写真撮影とは、特に言及しない限り、仮想空間内での写真撮影を意味し、写真とは、撮像の際に記憶される端末用画像に基づく画像データと同義である。

ユーザインタフェースＧ６１２は、瞬間移動用のボタンＢ６０５からＢ６０９を含む。ボタンＢ６０５からＢ６０９のそれぞれには、移動先を示す情報（例えば文字情報）が対応付けられてよい。例えば、ボタンＢ６０５は、第１ユーザアバターＭ１が現に位置する施設等のエントランスに瞬間移動するためのボタンである。

ボタンＢ６０５からＢ６０９の数や行き先は、任意である。ただし、行き先は、好ましくは、実空間においては行くことが非常に困難な場所（例えばエベレストの頂上や高層ビルの屋上など）を含んでよい。この場合、ユーザは、仮想空間でしか行けないような場所にユーザアバターＭ１を介して気軽に行くことができ、貴重な体験等をすることができる。また、瞬間移動用の行き先は、ユーザにより適宜設定可能であってもよい。

方向案内画像Ｇ６１４は、第１ユーザアバターＭ１から視たときの方向（第１ユーザアバターＭ１を基準とした相対方向）を表す又は示唆する情報であり、特定の目的位置の方向や特定アイテムの方向を表す又は示唆する情報である。特定の目的位置は、例えばミッションを伴うゲームが実施される場合、ミッションで指定される位置（例えば東京タワーなど）であってよい。この場合、特定の目的位置は、ある程度の範囲を有する態様で設定されてもよい。特定アイテム（特定の表示媒体の一例）は、任意の仮想現実媒体であってよい。特定アイテムは、例えばミッションを伴うゲームが実施される場合、ミッションで指定される取得目標アイテム（後述）であってよい。これにより、第１ユーザは、方向案内画像Ｇ６１４を見て、特定の目的位置や特定アイテムの方向を容易に把握でき、適宜、特定の目的位置や特定アイテムのそばまで自身の第１ユーザアバターＭ１を移動させることが容易となる。

方向案内画像Ｇ６１４は、特定の目的位置や特定アイテムを示す情報（例えば文字情報）が対応付けられてもよい。これにより、第１ユーザは、特定の目的位置や特定アイテムを、容易に把握することができる。

方向案内画像Ｇ６１４は、例えば、図６に示すように、特定の目的位置の方向や特定アイテムの方向を表すコンパスの形態の画像であってよい。方向案内画像Ｇ６１４は、平面視で描画されてもよい。この場合、尖っている先端の指す方向が、平面視での（鳥瞰図でみたときの）、特定の目的位置の方向や特定アイテムの方向に対応してよい。

なお、方向案内画像Ｇ６１４は、省略されてもよいし、第１ユーザにより表示のオン／オフが可能とされてもよい。

距離案内画像Ｇ６１５は、第１ユーザアバターＭ１からの相対距離を表す又は示唆する情報であり、第１ユーザアバターＭ１から特定の目的位置や特定アイテムまでの距離を表す又は示唆する情報である。距離案内画像Ｇ６１５は、例えば、図６に示すように、対応する距離を表す数字の画像であってよい。これにより、第１ユーザは、距離案内画像Ｇ６１５を見て、特定の目的位置や特定アイテムまでの距離を容易に把握できる。距離案内画像Ｇ６１５は、好ましくは、方向案内画像Ｇ６１４の近傍に、方向案内画像Ｇ６１４とセットで表示される。

フレンド案内画像Ｇ６１６は、他のユーザ（以下、「第２ユーザ」と称する）に対応する各ユーザアバターＭ１（以下、「第２ユーザアバターＭ１」とも称する）（第２表示媒体の一例）の位置情報を示す。従って、第１ユーザは、第２ユーザアバターＭ１との位置関係や第２ユーザアバターＭ１の位置を把握しながら第１ユーザアバターＭ１を移動させることが可能である。これにより、第１ユーザは、フレンド案内画像Ｇ６１６を見て、第２ユーザアバターＭ１のそばまで自身の第１ユーザアバターＭ１を移動させることが容易となる。なお、第２ユーザ側においても、第２ユーザ用の端末画像において同様のフレンド案内画像が表示される。従って、各ユーザは、互いのユーザアバターＭ１の位置関係を把握しながら、交流を図ることができる。

図６に示す例では、フレンド案内画像Ｇ６１６は、各第２ユーザアバターＭ１を示す画像Ｇ６１６ＡからＧ６１６Ｃとともに、第２ユーザアバターＭ１ごとの、案内画像Ｇ６１６－１からＧ６１６－３を含む。この場合、フレンド案内画像Ｇ６１６は、３人の第２ユーザに対応して、案内画像Ｇ６１６－１からＧ６１６－３を含む。

案内画像Ｇ６１６－１からＧ６１６－３のそれぞれは、対応する第２ユーザアバターＭ１を示す画像Ｇ６１６ＡからＧ６１６Ｃに対応付けて配置される。例えば、一の第２ユーザアバターＭ１に係る案内画像Ｇ６１６－１は、当該一の第２ユーザアバターＭ１を示す画像Ｇ６１６Ａに対応付けて配置される（図６では、画像Ｇ６１６Ａの下側に配置されている）。

対応する一の第２ユーザアバターＭ１に係る案内画像Ｇ６１６－１（案内画像Ｇ６１６－２、Ｇ６１６－３も同様）は、方向案内画像Ｇ６１６１と、距離案内画像Ｇ６１６２とを含む。

方向案内画像Ｇ６１６１は、第１ユーザアバターＭ１から視たときの方向（第１ユーザアバターＭ１を基準とした相対方向）を表す又は示唆する情報であり、対応する一の第２ユーザアバターＭ１の方向を表す又は示唆する情報である。これにより、第１ユーザは、方向案内画像Ｇ６１６１を見て、所望の第２ユーザアバターＭ１の方向を把握でき、適宜、所望の第２ユーザアバターＭ１のそばまで自身の第１ユーザアバターＭ１を移動させることが容易となる。

方向案内画像Ｇ６１６１は、例えば、図６に示すように、対応する一の第２ユーザアバターＭ１の方向を表すコンパスの形態の画像であってよい。方向案内画像Ｇ６１６１は、上述した方向案内画像Ｇ６１４と同様、平面視で描画されてもよい。この場合、尖っている先端の指す方向が、平面視での（鳥瞰図でみたときの）、対応する一の第２ユーザアバターＭ１の方向に対応してよい。

距離案内画像Ｇ６１６２は、第１ユーザアバターＭ１からの相対距離を表す又は示唆する情報であり、第１ユーザアバターＭ１から第２ユーザアバターＭ１までの距離を表す又は示唆する情報である。距離案内画像Ｇ６１６２は、上述した距離案内画像Ｇ６１５と同様、例えば、図６に示すように、対応する距離を表す数字の画像であってよい。これにより、第１ユーザは、距離案内画像Ｇ６１６２を見て、第２ユーザアバターＭ１までの距離を容易に把握できる。距離案内画像Ｇ６１６２は、好ましくは、同一の第２ユーザアバターＭ１に係る方向案内画像Ｇ６１６１の近傍に、当該方向案内画像Ｇ６１６１とセットで表示される。

本実施形態では、仮想空間における第１ユーザアバターＭ１と第２ユーザアバターＭ１のそれぞれの位置、及び、仮想空間における第１ユーザアバターＭ１と第２ユーザアバターＭ１との第１相対位置関係、の少なくともいずれか一方が、第１所定条件を満たす場合に、所定イベントを発生させる。

第１所定条件は、任意であるが、第１ユーザアバターＭ１と第２ユーザアバターＭ１との交流の可能性が高い状況下で満たされてよい。本実施形態では、第１所定条件は、第１ユーザアバターＭ１と第２ユーザアバターＭ１とが互いに近接する場合に満たされる。例えば、第１所定条件は、第１ユーザアバターＭ１と第２ユーザアバターＭ１との間の距離（仮想空間内での相対距離）が所定距離内である場合に満たされる。この場合、所定距離は、第１ユーザアバターＭ１と第２ユーザアバターＭ１とが互いに近接する際の距離に対応し、適宜、適合されてよい。あるいは、第１所定条件は、第１ユーザアバターＭ１と第２ユーザアバターＭ１とが、共通の特定位置に対して所定距離内である場合に満たされてもよい。

所定イベントは、任意であるが、好ましくは、第１所定条件を満たした第１ユーザアバターＭ１と第２ユーザアバターＭ１とが連携して実現可能なイベントである。この場合、第１ユーザと第２ユーザとの間の、第１ユーザアバターＭ１と第２ユーザアバターＭ１とを介した交流が促進される。

例えば、第１ユーザアバターＭ１と第２ユーザアバターＭ１とが連携して実現可能なイベントは、例えば、以下のイベントＥ１～Ｅ５等であってもよい。
イベントＥ１：共通のルームや特定の位置に瞬間移動するイベント
イベントＥ２：移動可能な空間が広がる（ゲートに集まったらゲートが開く）イベント
イベントＥ３：みんなでミニゲームができるイベント
イベントＥ４：集まったメンバーだけでチャットができるイベント
イベントＥ５：みんなで協力してクリアするミッションが始まる（宝探しや謎解きゲーム等）イベント。
ここで、共通のルームとは、仮想空間として形成される空間部であり、特定のコンテンツが提供される空間部であってもよい。特定のコンテンツは、視聴可能なエンターテイメント系のコンテンツであってもよい。あるいは、共通のルームは、チャットルームのような、特定のコンテンツが提供されない空間部であってもよい。この場合、イベントＥ１は、イベントＥ４と同様となりうる。なお、チャットは、ボイスチャット及び／又はテキストチャットであってよい。また、“みんな”とは、第１ユーザアバターＭ１と第２ユーザアバターＭ１であるが、第２ユーザアバターＭ１は２体以上であってよい。

また、所定イベントは、運営側で設定するイベントであってもよいし、各ユーザが生成できるＵＧＣ（Ｕｓｅｒ Ｇｅｎｅｒａｔｅｄ Ｃｏｎｔｅｎｔｓ）に基づくイベントであってもよい。この場合、多様なコンテンツに基づく所定イベントを設定することができる。なお、ＵＧＣは、表形式（データベース）でコンテンツ設計者（ユーザ）により制作できる。また、かかるＵＧＣは、コンテンツ市場に流通させることも可能である。また、ユーザアバター（ＵＧＣのコンテンツ設計者やその制作に関わったユーザに係るユーザアバター）は、所定イベントに関連して、ツアーガイドとして「自分が紹介したい旅」を直接案内することとしてもよい。また、各種体験のシナリオに係るＵＧＣをギャラリーに置いておくことで、各ユーザが訪問者としてユーザアバターを介して追体験できる。この場合、ＵＧＣは、表形式（データベース）でコンテンツ設計者が制作することができる。また、座標、視点、イベント、アイテム、メッセージなどは体験のシナリオに容易に変換できる。

本実施形態では、一例として、所定イベントは、記念撮影のような画像取得イベントを含む。この場合、画像取得イベントは、その場所を背景として、第１ユーザアバターＭ１と第２ユーザアバターＭ１とを含む画像が取得されるイベントであってよい。なお、所定イベントが複数種類のイベント（例えば上述したイベントＥ１からイベントＥ５）を含む場合、どのイベントが発生するかは、第１ユーザ等により選択されてもよいし、場所に応じて決まっていてもよい。

この場合、画像取得イベントは、仮想空間内の任意の場所で発生可能であってもよいし、特定の場所（例えば絶景ポイントや名所等）でのみ発生可能であってもよい。後者の場合、第１所定条件は、第１ユーザアバターＭ１と第２ユーザアバターＭ１のそれぞれの位置が、対応する特定の場所に属する場合に満たされてもよい。より具体的には、第１所定条件は、第１ユーザアバターＭ１と第２ユーザアバターＭ１のそれぞれの位置が、対応する特定の場所の基準位置（特定位置）に対して所定距離内にある場合に満たされてもよい。

図７及び図８は、一例による画像取得イベントの説明図である。

この場合、第１所定条件が満たされると、画像取得イベントの準備処理として、シャッタボタンである操作ボタンＢ６０２（図６参照）がアクティブ（操作可能な状態）とされる。第１ユーザが操作ボタンＢ６０２を操作すると、画像取得イベントが発生する。

画像取得イベントが発生すると、まず、図７に模式的に示すように、第１ユーザ用の端末用画像に、第１所定条件を満たした第１ユーザアバターＭ１と第２ユーザアバターＭ１（図７では、第１ユーザアバターＭ１と、１体の第２ユーザアバターＭ１）が描画される。この際、第１ユーザアバターＭ１と第２ユーザアバターＭ１は、それぞれ、複数種類のポーズのうちの一のポーズを取る態様で描画されてもよい。複数種類のポーズのうちの、どのポーズになるかは、ランダムに決定されてもよいし、画像取得イベントの位置に応じて決定されてもよいし、対応するユーザにより選択可能であってもよい。あるいは、適宜、ユーザ（ユーザアバターＭ１）ごとに独自のポーズが用意されてもよい。

そして、カウントダウンが始まり（図７では、３，２，１のうちの、“１”のカウントダウン画像Ｇ７００が示された状態）、最後に、図８に示すように、“はい、チーズ！”といった文字情報Ｇ８００とともにシャッタ音が出力され、写真が撮られる。この場合、写真は、そのときの端末用画像そのものであるが、適宜、不要な部分（例えばユーザインタフェースＧ６１１等）は除去されてもよい。

このような画像取得イベントによれば、第１ユーザは、第１ユーザアバターＭ１及び第２ユーザアバターＭ１を介して、第２ユーザと交流しながら、実空間と同様の態様で、例えば名所や絶景ポイントなどで、記念撮影を行うことができる。

なお、図７及び図８に示す例では、記念撮影で撮られた写真（例えば、ツーショット写真）には、第１ユーザアバターＭ１及び第２ユーザアバターＭ１が映るが、第１ユーザアバターＭ１及び第２ユーザアバターＭ１に代えて、実空間における第１ユーザの画像及び第２ユーザの画像が利用されてもよい。この場合、利用される第１ユーザの画像及び第２ユーザの画像は、あらかじめ用意されてもよいし、実空間においてその場で撮像されてもよい。この場合、第１ユーザ及び第２ユーザは、それぞれのカメラの前に位置し、それぞれのカメラで撮像された画像が、記念撮影で撮られた写真に組み込まれる。また、この場合、実空間における第１ユーザの画像及び第２ユーザの画像は、一部だけ（例えば顔の部分だけ）が利用されてもよい。この場合、他の部分（例えば顔以外の部分）は、所定のキャラクター（例えばご当地キャラ）の画像や、対応するユーザアバターＭ１の一部であってもよい。また、画像取得イベントの際に、第１ユーザアバターＭ１及び／又は第２ユーザアバターＭ１の服装が変化してもよい（例えばその場所に応じた服装に変化してもよい）。

また、画像取得イベントに係る記念撮影の際に、画像取得イベントを発生させるユーザによる選択（要求）に応じて、有名人やインフルエンサーの係るアバターのような特別なアバターが出現してもよい。これにより、画像取得イベントにて特別なアバターを含む画像を得ることができる。この場合、特別なアバターと一緒に写真が撮れる場所や時間帯等は、制限されてもよい。

また、画像取得イベントに係る記念撮影の際に、画像取得イベントを発生させるユーザによる選択（要求）に応じて、過去に同場所に位置した他のユーザアバターＭ１が出現してもよい。これにより、画像取得イベントにて多数のユーザアバターを含む集合写真のような画像を得ることができる。この場合、一緒に写真が撮れる他のユーザアバターＭ１や、場所、時間帯等は、適宜、制限されてもよい。

ところで、このように仮想空間におけるユーザアバターＭ１間の相対位置関係に基づいて所定イベントを発生可能とする構成においては、ユーザアバターＭ１間の相対位置関係が、各ユーザにとってわかりやすくなることが望ましい。

この点、実空間と同様、各ユーザは、互いにチャット等を介して連絡を取り合うことで、ユーザアバターＭ１間の相対位置関係を把握することも可能であるが、見知らぬ場所では、互いに同じ場所で落ち合うことが難しい場合もある。

これに対して、本実施形態によれば、上述したように、フレンド案内画像Ｇ６１６が表示可能であるので、各ユーザは、フレンド案内画像Ｇ６１６から他のユーザアバターＭ１の位置関連の情報を得ながら、第１所定条件が満たされるように、自身のユーザアバターＭ１を移動させることが容易となる。この結果、仮想空間におけるユーザアバターＭ１の移動の効率化が図られることで、処理負荷の低減を図ることも可能となる。

また、このようなフレンド案内画像Ｇ６１６は、比較的画面が小さく視野が限られる端末装置２０（例えばスマートフォン）にも好適である。このような端末装置２０の場合でも、ユーザは、所望の第２ユーザアバターＭ１の位置（相対位置）を容易に認識でき、自身の第１ユーザアバターＭ１を所望の位置へと移動させやすくなる。

また、本実施形態では、仮想空間における第１ユーザアバターＭ１の位置と、仮想空間における特定アイテムの位置とに基づいて、第２所定条件が満たされたと判定された場合に、第１ユーザ又は第１ユーザアバターＭ１に、特定アイテム（所定情報の一例）を取得させるイベント（以下、「アイテム取得イベント」とも称する）を発生させる。なお、特定アイテムを取得させることに代えて又は加えて、特定アイテムに応じた仮想現実媒体（所定情報の他の一例）を第１ユーザ又は第１ユーザアバターＭ１に取得させてもよい。

特定アイテムは、任意であるが、上述したように、例えばミッションを伴うゲームが実施される場合、ミッションで指定される取得目標アイテムであってよい。本実施形態では、取得目標アイテムは、その場所に応じたアイテムであり、適宜設定されてもよい。例えば、フラミンゴのオブジェがある場所の場合、取得目標アイテムは、フラミンゴのたまごを想起させるアイテムであってもよい。

特定アイテムは、実在する物体に対応してもよい。例えば、ある場所に、実在する物体としてカエルの像が設置されている場合、当該場所に対応付けられる特定アイテムは、当該カエルを模した表示媒体であってよい。

特定アイテムに応じた仮想現実媒体は、上述したような任意の仮想現実媒体であってよいが、好ましくは、特定アイテムに直接的又は間接的に関連した仮想現実媒体であってよい。例えば、特定アイテムが、ミッションで指定される取得目標アイテムである場合、特定アイテムに応じた仮想現実媒体は、当該ミッションがクリアされたことを証明する証明書情報であってもよい。

第２所定条件は、任意であるが、上述した第１所定条件と同様、位置関係（距離）に基づいて判定されてもよい。本実施形態では、第２所定条件は、第１ユーザアバターＭ１と特定アイテムとが互いに近接する場合に満たされる。例えば、第２所定条件は、第１ユーザアバターＭ１と特定アイテムとの間の距離（仮想空間内での相対距離）が所定距離内である場合に満たされる。この場合、所定距離は、第１ユーザアバターＭ１と特定アイテムとが互いに近接する際の距離に対応し、適宜、適合されてよい。第２所定条件に係る所定距離は、上述した第１所定条件に係る所定距離と同様であってもよい。

ところで、このように仮想空間におけるユーザアバターＭ１と特定アイテムとの間の相対位置関係に基づいてアイテム取得イベントを発生可能とする構成においては、ユーザアバターＭ１と特定アイテムとの間の相対位置関係が、各ユーザにとってわかりやすくなることが望ましい。

この点、本実施形態によれば、図６を参照して上述したように、方向案内画像Ｇ６１４や距離案内画像Ｇ６１５が表示可能であるので、各ユーザは、方向案内画像Ｇ６１４や距離案内画像Ｇ６１５から情報を得ながら、第２所定条件が満たされるように、自身のユーザアバターＭ１を移動させることが容易となる。この結果、仮想空間におけるユーザアバターＭ１の移動の効率化が図られることで、処理負荷の低減を図ることも可能となる。

また、このような方向案内画像Ｇ６１４や距離案内画像Ｇ６１５は、比較的画面が小さく視野が限られる端末装置２０（例えばスマートフォン）にも好適である。このような端末装置２０の場合でも、ユーザは、所望の特定アイテムの位置（相対位置）を容易に認識でき、自身の第１ユーザアバターＭ１を所望の位置へと移動させやすくなる。

図９及び図１０は、一例によるアイテム取得イベントの説明図である。

図９に示すように、まず、第１ユーザには、アイテム取得イベントに係るミッションが提示されてよい。この場合、ミッションは、取得目標アイテムとしてフラミンゴのたまごのアイテムを取得することである。図９に示すように、端末用画像には、ミッションを表す文字情報Ｇ９００とともに、フラミンゴのたまごの方向及び位置を示す方向案内画像Ｇ６１４及び距離案内画像Ｇ６１５が含まれている。これにより、第１ユーザは、フラミンゴのたまごのアイテムの方向及び位置を容易に把握でき、それに応じて第１ユーザアバターＭ１を移動させることができる。

そして、第１ユーザアバターＭ１がフラミンゴのたまごのアイテムの近くまで移動すると、図１０に示すように、“アイテム獲得！”といった文字情報Ｇ１０００が描画されることで、ミッションがクリアとなったことが通知される。この場合、ユーザには、取得目標アイテムとしてのフラミンゴのたまごのアイテムが対応付けられる。なお、アイテム取得イベントの際、記念として写真が自動的に撮られてもよい。この場合、端末用画像に取得目標アイテムを手にしているポーズで第１ユーザアバターＭ１が含められたうえで、写真が自動的に撮られてもよい。この場合も、上述した画像取得イベントと同様に、写真は、そのときの端末用画像そのものであるが、適宜、不要な部分（例えばユーザインタフェースＧ６１１等）は除去されてもよい。

次に、図１１以降を参照して、上述した仮想現実生成システム１の構成例を順に説明していく。

以下では、サーバ装置１０が、情報処理システムの一例を実現するが、後述するように、一の端末装置２０の各要素（図１の端末通信部２１～端末制御部２５参照）が、情報処理システムの一例を実現してもよいし、複数の端末装置２０が、協動して情報処理システムの一例を実現してもよい。また、サーバ装置１０と１つ以上の端末装置２０が、協動して情報処理システムの一例を実現してもよい。

図１１は、上述した画像取得イベント及びアイテム取得イベントに関連したサーバ装置１０の機能ブロック図の一例である。図１２は、上述した画像取得イベント及びアイテム取得イベントに関連した端末装置２０の機能ブロック図の一例である。図１３は、ユーザデータベース１３０内のデータの説明図である。図１４は、アバターデータベース１３２内のデータの説明図である。なお、図１３及び図１４において、“＊＊＊”は、何らかの情報が格納されている状態を表し、“－”は、情報が格納されていない状態を表し、“・・・”は同様の繰り返しを表す。

ここでは、まず、サーバ装置１０の機能について説明してから、端末装置２０の機能について説明する。

（サーバ装置の機能）
サーバ装置１０は、図１１に示すように、ユーザデータベース１３０と、アバターデータベース１３２と、ユーザ入力取得部１４０（入力取得部の一例）と、位置管理部１４２と、画像条件生成部１４４と、第１判定部１４６と、インタフェース形成部１４８と、準備処理部１５０と、イベント発生部１５２と、第１相対関係出力部１５４と、第２相対関係出力部１５６と、第２判定部１５８と、移動処理部１６２と、画像データ記憶部１７２とを含む。なお、以下で説明するサーバ装置１０の機能の一部又は全部は、適宜、端末装置２０により実現されてもよい（図２１、図２１Ａ及び図２１Ｂを参照して後述）。また、ユーザ入力取得部１４０から移動処理部１６２の区分けは、説明の都合上であり、一部の機能部が、他の機能部の機能を実現してもよい。これは、ユーザデータベース１３０、アバターデータベース１３２、及び画像データ記憶部１７２の区分けについても同様である。例えば、ユーザデータベース１３０内のデータの一部又は全部は、アバターデータベース１３２内のデータに統合されてもよいし、別のデータベースに格納されてもよい。

ユーザ入力取得部１４０から移動処理部１６２は、サーバ装置１０のサーバ制御部１３が、サーバ装置１０のサーバ記憶部１２内の１つ以上のプログラムを実行することで実現できる。また、ユーザデータベース１３０、アバターデータベース１３２、及び画像データ記憶部１７２は、サーバ装置１０のサーバ記憶部１２により実現できる。

ユーザデータベース１３０には、ユーザ情報６００が格納される。図１３に示す例では、ユーザ情報６００は、各ユーザＩＤに、ユーザ名、ユーザアバターＩＤ、位置／向き情報等が対応付けられる。ユーザ名は、ユーザが自身で登録した名前であり、任意である。ユーザアバターＩＤは、ユーザアバターを特定するためのＩＤである。位置／向き情報は、ユーザアバターＭ１の位置情報と向き情報とを含む。ユーザアバターＭ１の位置情報は、実空間画像に対応付けられた座標系で管理されてよい。向き情報は、ユーザアバターＭ１の向きを表す情報であってよい。なお、位置／向き情報等は、ユーザからの操作入力に応じて、動的に変化しうる情報である。位置／向き情報に加えて、ユーザアバターＭ１の手足等の動きを表す情報や、顔の表情等を表す情報を含んでもよい。

アバターデータベース１３２には、ユーザアバターＭ１に関するアバター情報が格納される。図１４に示す例では、ユーザアバター情報７００は、各ユーザアバターＩＤに、顔、髪型、服装等が対応付けられる。顔、髪型、服装等の容姿に係る情報は、ユーザアバターを特徴付けるパラメータであり、あらかじめ設定されてもよいし、各ユーザにより設定されてもよい。例えば、アバターに係る顔、髪型、服装等の容姿に係る情報は、種類ごとＩＤが付与されてもよい。また、顔については、顔の形、目、口、鼻等の各種類にそれぞれパーツＩＤが用意され、顔に係る情報は、当該顔を構成する各パーツのＩＤの組み合わせで管理されてもよい。この場合、顔、髪型、服装等の容姿に係る情報は、アバターの描画情報として機能できる。すなわち、各ユーザアバターＩＤに紐付けられた容姿に係る各ＩＤに基づいて、サーバ装置１０のみならず端末装置２０側においても各ユーザアバターＭ１を描画することが可能となる。

このようにして本実施形態では、基本的には、一のユーザに、一のユーザＩＤが対応付けられ、一のユーザＩＤに、ユーザアバターＩＤが対応付けられる。従って、一のユーザに、ある情報が対応付けられる状態と、当該一のユーザＩＤに、当該情報が対応付けられる状態と、当該一のユーザＩＤに対応付けられたユーザアバターＩＤに、当該情報が対応付けられる状態とは、互いに同義である。なお、一のユーザＩＤには、２つ以上のユーザアバターＩＤが対応付けられてもよい。

ユーザ入力取得部１４０は、端末装置２０の入力部２４を介して入力される各ユーザによる各種入力を取得する。

位置管理部１４２は、所定の配置条件が成立すると、仮想空間に、仮想現実媒体のうちの各種の表示媒体を位置付ける。各種の表示媒体は、第１ユーザに対応付けられる第１ユーザアバターＭ１、第２ユーザに対応付けられる第２ユーザアバターＭ１、及び他の表示媒体（例えば上述した特定アイテム）を含んでよい。

位置管理部１４２は、仮想空間に一の表示媒体を位置付ける場合、上述した実空間画像に対応付けている座標系で、当該一の表示媒体の位置情報を設定してよい。すなわち、位置管理部１４２は、各種の表示媒体の位置情報を、上述した実空間画像に対応付けている座標系で管理してよい。

所定の配置条件は、位置付ける表示媒体ごとに設定されてもよい。例えば、第１ユーザアバターＭ１に係る所定の配置条件は、第１ユーザによる入力であって、仮想空間への入室要求があった場合に満たされてよい。この場合、仮想空間における第１ユーザアバターＭ１の位置情報（初期の位置情報）は、第１ユーザにより指定可能であってもよいし、実空間における第１ユーザの位置情報に基づいて特定されてもよい。同様に、第２ユーザアバターＭ１に係る所定の配置条件は、第２ユーザによる入力であって、仮想空間への入室要求があった場合に満たされてよい。この場合、仮想空間における第２ユーザアバターＭ１の位置情報（初期の位置情報）は、第２ユーザにより指定可能であってもよいし、実空間における第２ユーザの位置情報に基づいて特定されてもよい。なお、位置管理部１４２による配置処理において実空間における各ユーザの位置情報が利用される場合、例えば第１ユーザと第２ユーザが実空間内に実質的に同じ位置にいるときは、仮想空間においても第１ユーザアバターＭ１と第２ユーザアバターＭ１とが実質的に同じ位置に位置付けられる。あるいは、他の実施例では、位置管理部１４２により位置付けられる際の仮想空間におけるユーザアバターＭ１の位置情報（初期の位置情報）は、前回の退出の際の同ユーザアバターＭ１の位置情報に対応してもよい。

また、特定アイテムに係る所定の配置条件は、対応するアイテム取得イベントのミッションが設定された場合に満たされてよい。仮想空間における位置管理部１４２により各種の表示媒体が位置付けられる位置（初期の位置情報）は、あらかじめ規定されてよいし、表示媒体の属性に応じてランダムに決定されてもよい。例えば、実空間内にある物体に対応する特定アイテムの場合、仮想空間における特定アイテムの位置情報（初期の位置情報）は、実空間における同物体の位置情報に対応してもよい。また、配置数が限られている特定アイテムに係る所定の配置条件は、配置数が上限値に満たないことを含んでよい。

位置管理部１４２は、グループごとに、仮想的に別々の仮想空間を形成してもよい。すなわち、位置管理部１４２は、一のグループに属する各ユーザアバターＭ１と、他の一のグループに属する各ユーザアバターＭ１とを、別々の仮想空間に位置付けられてもよい。この場合、別々の仮想空間は、見た目上は、同じであってもよい（すなわち、そこで活動しているユーザアバターＭ１だけが異なる空間であってよい）。

画像条件生成部１４４は、ユーザごとに、上述した端末用画像用の画像生成条件を生成する。画像生成条件は、例えば、日時、撮像した地点に対応付けられたＩＤ（後述する場所ＩＤ）、カメラパラメータ（方位角、迎角、画角等）、描画対象のユーザアバターのＩＤ、描画対象のユーザアバターの位置等を含んでよい。また、画像生成条件は、描画対象のユーザアバター情報７００（図１４参照）や描画対象のユーザアバターの姿勢等を示す情報を含んでよい。また、画像生成条件は、後述するユーザインタフェースを描画するための情報や、方向案内画像Ｇ６１６１及び距離案内画像Ｇ６１６２を描画するための情報等を含んでよい。

画像条件生成部１４４は、第１画像条件生成部１４４１と、第２画像条件生成部１４４２とを含む。

第１画像条件生成部１４４１は、第１ユーザにより視認可能な第１ユーザ用の端末用画像（第１表示画像の一例）用の画像生成条件を生成する。なお、第１ユーザ用の端末用画像は、上述したように、第１ユーザによる端末装置２０の表示部２３を介して視認可能であってよい。

第１画像条件生成部１４４１は、第１ユーザ用の端末用画像用の画像生成条件を、上述したように、第１ユーザ用の端末用画像が実空間画像をベースとして描画されるように生成する。具体的には、第１画像条件生成部１４４１は、第１ユーザアバターＭ１の位置情報（図１３の位置／向き情報参照）に基づいて、第１ユーザ用の端末用画像用の実空間画像を、上述したようにＡＰＩを利用して描画するための画像生成条件を生成する。

この場合、実空間画像を視る第１視点からの向きは、第１ユーザアバターＭ１の向き（図１３の位置／向き情報参照）に応じて決定されてもよい。第１ユーザアバターＭ１の向きは、第１ユーザアバターＭ１の全体としての向きであってもよいし、第１ユーザアバターＭ１の特定の部位の向き（例えば顔の向き、体の向き、目の向き）等であってもよい。

また、第１画像条件生成部１４４１は、第１ユーザ用の端末用画像に第２ユーザアバターＭ１を描画するための画像生成条件を生成する。この場合、第１画像条件生成部１４４１は、第２ユーザアバターＭ１の位置情報（図１３の位置／向き情報参照）に応じて、第１ユーザ用の端末用画像に第２ユーザアバターＭ１を描画するための画像生成条件を生成してもよい。例えば、第２ユーザアバターＭ１の位置情報が、第１ユーザ用の端末用画像で示される空間部に属する場合、第１画像条件生成部１４４１は、第１ユーザ用の端末用画像に第２ユーザアバターＭ１を描画するための画像生成条件を生成してよい。

第１画像条件生成部１４４１は、第２ユーザアバターＭ１を描画するための画像生成条件を生成する際、アバターデータベース１３２内の対応するユーザアバターＩＤに対応付けられたユーザアバター情報７００（図１４参照）を利用してもよい。また、この際、ユーザデータベース１３０内の対応するユーザアバターＩＤの位置／向き情報に基づいて、第２ユーザアバターＭ１の向きを表現するための画像生成条件を生成してもよい。

また、第１画像条件生成部１４４１は、第１ユーザ用の端末用画像に特定アイテムを描画するための画像生成条件を生成する。この場合、第１画像条件生成部１４４１は、特定アイテムの位置情報に応じて、第１ユーザ用の端末用画像に特定アイテムを描画するための画像生成条件を生成してよい。例えば、特定アイテムの位置情報が、第１ユーザ用の端末用画像で示される空間部に属する場合、第１画像条件生成部１４４１は、第１ユーザ用の端末用画像に特定アイテムを描画するための画像生成条件を生成してよい。

また、第１画像条件生成部１４４１は、画像取得イベントに係る第１ユーザ用の端末用画像を描画するための画像生成条件を生成する。この場合、図７を参照して上述したように、第１画像条件生成部１４４１は、第１所定条件が満たされたと判定された場合に、準備処理部１５０と連携して、複数種類のポーズのうちからそれぞれのポーズを選択するとともに、第１ユーザアバターＭ１及び第２ユーザアバターＭ１をそれぞれ選択したポーズで描画するための画像生成条件を生成する。なお、第２ユーザアバターＭ１が複数である場合、ポーズはそれぞれの第２ユーザアバターＭ１に対して別々に選択されてよい。複数種類のポーズは、ピースのような指や手を使うポーズや、ジャンプなど全身を使うポーズ等、任意である。また、複数種類のポーズは、顔の表情の種類を含んでもよい。なお、ポーズの選択方法等については上述したとおりであってよい。

なお、第１画像条件生成部１４４１は、画像取得イベントに係る第１ユーザ用の端末用画像を描画するための画像生成条件を生成する際、第１ユーザアバターＭ１が第１ユーザ用の端末用画像の中央部に来るように第１ユーザアバターＭ１を描画するための画像生成条件を生成してもよいし、第１ユーザアバターＭ１及び第２ユーザアバターＭ１がランダムに決定した配置順になるように第１ユーザアバターＭ１を描画するための画像生成条件を生成してもよいし、第１ユーザアバターＭ１及び第２ユーザアバターＭ１をあらかじめ指定された配置順になるように第１ユーザアバターＭ１を描画するための画像生成条件を生成してもよい。この場合、第１画像条件生成部１４４１は、第１ユーザ用の端末用画像における第２ユーザアバターＭ１の直前の描画位置をずらす等の調整を行ってもよい。このような調整は、後述する撮影配置処理の一部として実行されてもよい。あるいは、第１画像条件生成部１４４１は、第１ユーザ用の端末用画像における第２ユーザアバターＭ１の直前の描画位置が変化（影響）しないように、第１ユーザアバターＭ１を描画するための画像生成条件を生成してもよい。

第２画像条件生成部１４４２は、第２ユーザにより視認可能な第２ユーザ用の端末用画像用の画像生成条件を生成する。なお、第２ユーザ用の端末用画像は、上述したように、第２ユーザによる端末装置２０の表示部２３を介して視認可能であってよい。

第２画像条件生成部１４４２は、第１画像条件生成部１４４１と同様、第２ユーザ用の端末用画像（第２表示画像の一例）用の画像生成条件を、上述したように、第２ユーザ用の端末用画像が実空間画像をベースとして描画されるように生成する。具体的には、第２画像条件生成部１４４２は、第２ユーザアバターＭ１の位置情報（図１３の位置／向き情報参照）に基づいて、第２ユーザ用の端末用画像用の実空間画像を、上述したようにＡＰＩを利用して描画するための画像生成条件を取得してよい。そして、第２画像条件生成部１４４２は、第２ユーザアバターＭ１に対応付けられる第２視点から視た実空間画像に基づいて、第２ユーザ用の端末用画像を描画するための画像生成条件を生成する。この場合、実空間画像を視る第２視点からの向きは、第２ユーザアバターＭ１の向き（図１３の位置／向き情報参照）に応じて決定されてもよい。第２ユーザアバターＭ１の向きは、第２ユーザアバターＭ１の全体としての向きであってもよいし、第２ユーザアバターＭ１の特定の部位の向き（例えば顔の向き、体の向き、目の向き）等であってもよい。

また、一の第２ユーザに係る第２画像条件生成部１４４２は、第２ユーザ用の端末用画像に、第１ユーザアバターＭ１や他の第２ユーザアバターＭ１（当該一の第２ユーザとは異なる他の第２ユーザに対応付けられた第２ユーザアバターＭ１）を描画するための画像生成条件を生成する。この場合、第２画像条件生成部１４４２は、第１ユーザアバターＭ１や他の第２ユーザアバターＭ１の位置情報（図１３の位置／向き情報参照）に応じて、第２ユーザ用の端末用画像に第１ユーザアバターＭ１や他の第２ユーザアバターＭ１を描画するための画像生成条件を生成してもよい。

また、第２画像条件生成部１４４２は、第１画像条件生成部１４４１と同様に、第２ユーザ用の端末用画像に特定アイテムを描画するための画像生成条件を生成する。また、第２画像条件生成部１４４２は、第１画像条件生成部１４４１と同様に、画像取得イベントに係る第２ユーザ用の端末用画像を描画するための画像生成条件を生成する。

第１判定部１４６は、ユーザごとに第１所定条件を満たすか否かを判定する。第１所定条件は、上述したとおりであってよい。この場合、第１判定部１４６は、第１所定条件を満たすか否かを判定する際、ユーザデータベース１３０内の対応するユーザアバターＭ１の位置情報を利用してよい。この場合、第１判定部１４６は、各ユーザアバターＭ１の位置情報に基づいて、各ユーザアバターＭ１間の距離のような、相対位置関係（後述の第１相対関係）を算出できる。

ここで、各ユーザアバターＭ１の位置情報は、上述したように、位置管理部１４２により初期的に決定され、その後、後述する移動処理部１６２により更新される。各ユーザアバターＭ１の位置情報が、位置管理部１４２に関して上述したように又は後出の移動処理部１６２に関して後述するように、実空間における各ユーザの位置に基づいて特定される場合には、第１所定条件は、実空間における各ユーザの位置に基づいて判定されることになる。例えば、第１ユーザアバターＭ１と第２ユーザアバターＭ１との間の距離（仮想空間内での相対距離）が、所定距離内である場合に満たされる第１所定条件は、実空間における同ユーザ間の距離が所定距離内である場合に満たされてよい。また、例えば、第１ユーザアバターＭ１の位置が、対応する特定の場所の基準位置（特定位置）に対して所定距離内にある場合に満たされる第１所定条件は、実空間における同ユーザ位置が、同特定位置に対して所定距離内である場合に満たされてよい。

インタフェース形成部１４８は、端末用画像にユーザインタフェースを形成する。ユーザインタフェースは、図６を参照して上述したユーザインタフェースＧ６１１、Ｇ６１２等を含んでよい。なお、インタフェース形成部１４８は、後述するように、準備処理部１５０と連携して、シャッタボタンである操作ボタンＢ６０２（図６参照）をアクティブ（操作可能な状態）にする処理を行う。

準備処理部１５０は、第１判定部１４６により第１所定条件が満たされたと判定された場合に、所定イベントを発生可能とするための準備処理を行う。準備処理部１５０は、ユーザごとに判定される第１所定条件の成否に応じて、ユーザごとに準備処理を行う。例えば、第１ユーザに関して第１所定条件が満たされたと判定された場合に、第１ユーザに関して所定イベントを発生可能とするための準備処理を行う。

準備処理は、所定イベントごとに異なりえ、所定イベントの属性に依存して省略されてもよい。例えば、所定イベントが、上述したイベントＥ１（共通のルームや特定の位置に瞬間移動するイベント）である場合、準備処理は省略されてもよいし、瞬間移動用のボタンを発生又はアクティブ化する処理であってもよい。

本実施形態では、上述したように所定イベントは、画像取得イベントであり、準備処理は、画像取得イベントを発生させるためのインタフェースとして、シャッタボタンである操作ボタンＢ６０２（図６参照）をアクティブ（操作可能な状態）にする処理を含む。なお、準備処理は、第１所定条件が満たされたと判定されたユーザ用の端末用画像に対して実行される。

具体的には、準備処理部１５０は、第１判定部１４６により第１所定条件が満たされたと判定された場合に、インタフェース形成部１４８を介して、操作ボタンＢ６０２を非アクティブ状態からアクティブ状態へと遷移させる。なお、変形例では、準備処理部１５０は、第１判定部１４６により第１所定条件が満たされたと判定された場合に、インタフェース形成部１４８を介して、操作ボタンＢ６０２を非表示状態から表示状態へと遷移させてもよい。あるいは、他の変形例では、準備処理部１５０は、第１判定部１４６により第１所定条件が満たされたと判定された場合に、インタフェース形成部１４８を介して、操作ボタンＢ６０２の機能を、通常の写真撮影機能から、記念撮影機能に遷移させてもよい。この際、シャッタボタンである操作ボタンＢ６０２（図６参照）は、“いいね”ボタンやシェアボタンように形態が変化してもよい。この場合、通常の写真撮影機能は、後述する第１ユーザアバターＭ１の写り込みのない態様で写真を撮る機能（すなわち第１ユーザ用の端末用画像を記憶する機能）であってもよい。

また、更なる他の変形例として、第１判定部１４６による第１所定条件が満たされているか否かの判定や、準備処理部１５０による操作ボタンＢ６０２に係る準備処理は、省略されるようにしてもよい。この場合、操作ボタンＢ６０２は、基本的に、常時、アクティブ化しておけばよく、操作ボタンＢ６０２を押すと、第１所定条件が満たされていない場合であっても、端末用画像として撮影が可能な範囲にいるユーザアバターＭ１同士の記念撮影（ツーショット写真の撮影）をすることができる。第１判定部１４６による判定や準備処理部１５０による準備処理の省略は、例えば、操作ボタンＢ６０２を常時アクティブ化することに伴って、第１判定部１４６及び準備処理部１５０を経由しないで処理したり、経由する場合でも第１所定条件を解除又は無効としたりすることによって実行され得る。なお、第１判定部１４６による判定や準備処理部１５０による準備処理の省略は、本明細書に開示した他の実施形態においても採用され得る（後記する第２判定部１５８による判定が省略される場合を含む）。

また、本実施形態では、上述したように所定イベントは、画像取得イベントであり、準備処理は、更に、記念撮影となるような描画態様で各ユーザアバターＭ１を描画する処理を含んでよい。

具体的には、準備処理部１５０は、第１ユーザに関して第１判定部１４６により第１所定条件が満たされたと判定された場合に、第１画像条件生成部１４４１を介して、第１ユーザアバターＭ１と第２ユーザアバターＭ１のそれぞれが第１ユーザ用の端末用画像に含まれるように、第１ユーザ用の端末用画像を描画するための画像生成条件を生成する。以下、準備処理部１５０が実行する準備処理のうちの、第１画像条件生成部１４４１と連携して実行する当該描画準備処理を、「撮影配置処理」とも称する。撮影配置処理は、好ましくは、第１ユーザアバターＭ１と第２ユーザアバターＭ１のそれぞれが正面を向いた画像で含まれるように、第１ユーザ用の端末用画像を描画するための画像生成条件を生成する。

なお、第１画像条件生成部１４４１が、画像取得イベントに際して、第１ユーザアバターＭ１及び第２ユーザアバターＭ１をそれぞれ選択したポーズで描画するための画像生成条件を生成する処理は、上述した撮影配置処理の後に実行されてもよいし、撮影配置処理と実質的に同時に実現されてもよい。換言すると、撮影配置処理は、画像取得イベントと連動して同時に実行されてもよいし、シャッタボタンである操作ボタンＢ６０２（図６参照）をアクティブ（操作可能な状態）にする処理と同期して実行されてもよい。

なお、同様に、準備処理部１５０は、第２ユーザに関して第１判定部１４６により第１所定条件が満たされたと判定された場合に、第１画像条件生成部１４４１を介して、第２ユーザアバターＭ１とともに第１所定条件を満たした他のユーザアバターＭ１のそれぞれが第２ユーザ用の端末用画像に含まれるように、第２ユーザ用の端末用画像を描画するための画像生成条件を生成する。

ここで、図１５及び図１６を参照して、撮影配置処理について説明する。ここでは、第１画像条件生成部１４４１について説明するが、第２画像条件生成部１４４２についても同様である。

図１５及び図１６には、仮想空間内の第１ユーザアバターＭ１（第１ユーザに係るユーザアバターＭ１）と仮想カメラ６０とが側面視で模式的に示されている。仮想カメラ６０からの矢印Ｒ１３は、第１ユーザ用の端末用画像に係る第１視点からの視線方向を表す。図１５は、上述した画像取得イベントの前の状態を示し、図１６は、上述した画像取得イベントの際の状態を示す。なお、画像取得イベントの際の状態では、第２ユーザアバターＭ１が第１ユーザアバターＭ１のそばに位置するが、図１６では、第２ユーザアバターＭ１の図示は省略されている。

ここでは、説明用に仮想カメラ６０を利用する。仮想カメラ６０の位置は、第１ユーザ用の端末用画像に係る第１視点に対応し、仮想カメラ６０の視線方向（矢印Ｒ１３の方向）は、第１ユーザ用の端末用画像を生成する際の第１視点からの視線方向（実空間画像を視る方向）を表す。

図１５に示す状態は、画像取得イベントの前の状態であって、撮影配置処理が実行される前の状態である。この場合、第１ユーザアバターＭ１は、仮想カメラ６０の背後に位置付けられ、例えば第１ユーザアバターＭ１の前（例えば目の前）に仮想カメラ６０が位置する。このとき、仮想カメラ６０の視線方向は、第１ユーザアバターＭ１の向きに対応する。この場合、第１ユーザ用の端末用画像は、一人称視点の画像となり、第１ユーザアバターＭ１自身はアバター（画像Ｇ６１０ではない形態）として描画されない。ただし、第１ユーザ用の端末用画像には、第１ユーザアバターＭ１の手など体の一部が描画されるような画像生成条件を生成されてもよい。例えば、第１ユーザが自身の左手を目の前に出した場合、第１ユーザ用の端末用画像には、第１ユーザアバターＭ１の左手が含められてもよい。

図１６に示す状態は、画像取得イベントの際の状態であって、撮影配置処理が実行される後の状態である。この場合、第１ユーザアバターＭ１は、仮想カメラ６０の前側に位置付けられる。このとき、仮想カメラ６０の視線方向は、第１ユーザアバターＭ１に向かう向きに対応する。換言すると、仮想カメラ６０の視野内に第１ユーザアバターＭ１が移動する。

撮影配置処理は、このようにして、第１ユーザ用の端末用画像にユーザアバターＭ１が含まれるように、ユーザアバターＭ１の位置を実質的に変化させることを含む。ただし、実際の処理としては、ユーザアバターＭ１の位置情報自体は変化させずに、第１ユーザ用の端末用画像にユーザアバターＭ１を追加的に描画するような画像生成条件を生成する処理であってよい。

イベント発生部１５２は、画像データ取得部１５２１と、各種イベント発生部１５２２とを含む。

画像データ取得部１５２１は、画像取得イベントを発生させる。本実施形態では、画像データ取得部１５２１は、上述した第１所定条件が満たされ、かつ、第１ユーザによる操作ボタンＢ６０２の操作入力（所定入力の一例）が取得された場合に、画像取得イベントを発生させる。なお、変形例では、画像データ取得部１５２１は、上述した第１所定条件が満たされると、自動的に（第１ユーザによる操作ボタンＢ６０２の操作入力とは無関係に）、画像取得イベントを発生させてもよい。あるいは、画像データ取得部１５２１は、上述した第１所定条件が満たされ、他の任意の条件が成立し、かつ、第１ユーザによる操作ボタンＢ６０２の操作入力が取得された場合に、画像取得イベントを発生させてもよい。また、操作ボタンＢ６０２の操作入力に代えて又は加えて、他の入力（音声入力等を含む）が利用されてもよい。

画像データ取得部１５２１は、第１ユーザに関する画像取得イベントに際して第１画像条件生成部１４４１により生成された第１ユーザ用の端末用画像（第１ユーザアバターＭ１及び第２ユーザアバターＭ１が描画された端末用画像）用の画像生成条件に基づいて、イベント画像データ（特定の画像データの一例）に係る画像生成条件（特定の画像データの画像生成条件の一例）を取得する。なお、イベント画像データは、第１ユーザに関する画像取得イベントの際に第１画像条件生成部１４４１により生成された第１ユーザ用の端末用画像用の画像生成条件自体のデータであってもよいし、それに対して加工がなされた画像データ（例えば圧縮等されたデータや、ユーザインタフェースや一部の表示媒体が除去されたデータ）用の画像生成条件であってもよい。また、イベント画像データに係る画像生成条件は、第１画像条件生成部１４４１により生成された第１ユーザ用の端末用画像用の画像生成条件に対して、ユーザにより選択される付加情報又は所定の付加情報（場所の名前や、撮影時刻、フレームの絵等）が追加されてもよい。

イベント画像データに係る画像生成条件とは、当該イベント画像データに係る画像を生成するための画像生成条件である。イベント画像データに係る画像生成条件は、例えば、撮像した日時、撮像したフェーズ名、撮像した地点に対応付けられたＩＤ（後述する場所ＩＤ）、カメラパラメータ（方位角、迎角、画角等）を含んでよい。なお、フェーズ名は、ウォーターマークの印字に利用されてよい。また、イベント画像データに係る画像生成条件は、描画対象のユーザアバター情報７００（図１４参照）や撮像時のポーズの種類を示す情報を含んでよい。

例えば、画像データ取得部１５２１は、図８を参照して説明した例において、“はい、チーズ！”やシャッタ音の出力と同期して、そのタイミング又はその前後での第１ユーザ用の端末用画像に基づいて、イベント画像データに係る画像生成条件を取得する。なお、変形例では、画像データ取得部１５２１は、イベント画像データ自体を取得してもよい。

なお、画像データ取得部１５２１は、ユーザごとに機能する。すなわち、第２ユーザの場合も同様に、画像データ取得部１５２１は、第２ユーザに関する画像取得イベントに際して第２画像条件生成部１４４２により生成された第２ユーザ用の端末用画像に係る画像生成条件に基づいて、イベント画像データに係る画像生成条件を取得する。

各種イベント発生部１５２２は、仮想空間における各種イベントを発生させる。各種イベントは、上述した所定イベント以外のイベントであってよく、例えば、上述したアイテム取得イベントや、各種イベントに関連したミッション等であってもよい。例えば、各種イベント発生部１５２２は、上述したアイテム取得イベントにおいて、第２所定条件を満たしたユーザに、特定アイテム又はそれに応じた仮想現実媒体を対応付ける。

第１相対関係出力部１５４は、仮想空間における第１ユーザアバターＭ１と第２ユーザアバターＭ１との相対位置関係（以下、「第１相対位置関係」とも称する）に基づいて、第１相対位置関係を表す又は示唆する第１相対関係情報を出力する。第１相対関係情報は、端末用画像を介して出力されてもよい。すなわち、第１相対関係情報は、端末用画像に含まれる画像の形態であってよい。

仮想空間における第１ユーザアバターＭ１と第２ユーザアバターＭ１との相対位置関係は、相対距離や相対方位等を含む概念である。本実施形態では、第１相対関係情報は、図６を参照して上述したような方向案内画像Ｇ６１６１及び距離案内画像Ｇ６１６２を含む。ただし、変形例では、第１相対関係情報は、方向案内画像Ｇ６１６１及び距離案内画像Ｇ６１６２のうちのいずれか一方を含んでもよい。

ここで、図１７及び図１８を参照して、第１相対位置関係の算出方法の一例について説明する。図１７には、第１ユーザアバターＭ１と第２ユーザアバターＭ１とが平面視（鳥瞰図）で模式的に示されている。図１８には、第１ユーザアバターＭ１の向きφの説明図として、顔パーツの向きに係るローカル座標系（ｘ１軸、ｙ１軸、ｚ１軸）が示されている。

本実施形態では、方向案内画像Ｇ６１６１に係る方向αは、例えば、以下のような算出式に基づいて算出されてもよい。
α＝φ＋θ

ここで、（Ｌａｔ_ｐ，Ｌｎｇ_ｐ）は、第１ユーザアバターＭ１の位置情報（緯度、経度）であり、（Ｌａｔ_ｔ，Ｌｎｇ_ｔ）は、実空間画像に対応付けられている座標系での第２ユーザアバターＭ１の位置情報（緯度、経度）である。なお、図１７には、距離案内画像Ｇ６１６２に係る距離ｄが模式的に示されている。距離ｄは、位置情報（Ｌａｔ_ｐ，Ｌｎｇ_ｐ）と位置情報（Ｌａｔ_ｔ，Ｌｎｇ_ｔ）との間のユークリッド距離であってよい。なお、距離ｄは、上述した第１判定部１４６による判定に利用されてよい。

また、第１ユーザアバターＭ１の向きφは、顔パーツの向きとして、ｘ１軸、ｙ１軸及びｚ１軸のそれぞれの軸まわりの回転角度で規定されてよい。なお、ｘ１軸、ｙ１軸及びｚ１軸のそれぞれの軸まわりの回転角度の可変範囲は、特定パーツの属性に応じて設定されてよい。あるいは、上述したように、第１ユーザアバターＭ１の向きφは、他のパーツの方向（例えば目の方向、すなわち視線方向）に基づいて算出されてもよい。

第２相対関係出力部１５６は、仮想空間における第１ユーザアバターＭ１と特定アイテムとの相対位置関係（以下、「第２相対位置関係」とも称する）に基づいて、第２相対位置関係を表す又は示唆する第２相対関係情報を出力する。第２相対関係情報は、端末用画像を介して出力されてもよい。すなわち、第２相対関係情報は、端末用画像に含まれる画像の形態であってよい。

仮想空間における第１ユーザアバターＭ１と特定アイテムとの相対位置関係は、相対距離や相対方位等を含む概念である。本実施形態では、第２相対関係情報は、図６を参照して上述したような方向案内画像Ｇ６１４及び距離案内画像Ｇ６１５を含む。ただし、変形例では、第２相対関係情報は、方向案内画像Ｇ６１４及び距離案内画像Ｇ６１５のうちのいずれか一方を含んでもよい。方向案内画像Ｇ６１４及び距離案内画像Ｇ６１５に係る方向や距離の算出方法は、図１７及び図１８を参照して上述した第１相対位置関係の算出方法と同様であってよい。

第２判定部１５８は、ユーザごとに第２所定条件を満たすか否かを判定する。第２所定条件は、上述したとおりであってよい。この場合、第２判定部１５８は、第２所定条件を満たすか否かを判定する際、ユーザデータベース１３０内の対応するユーザアバターＭ１の位置情報を利用してよい。この場合、第１判定部１４６は、各ユーザアバターＭ１の位置情報と特定アイテムの位置情報（既知）に基づいて、第２相対位置関係を算出できる。

移動処理部１６２は、各ユーザからの各種入力に基づいて、各ユーザアバターＭ１の位置及び向きを変更する。ユーザアバターＭ１の位置及び向きを変更するためのユーザの入力は、多様であってよく、端末装置２０ごとに異なってもよい。一のユーザに係るユーザアバターＭ１の位置情報は、特定キー（例えば“ＷＡＳＤ”キー）のような物理的なスイッチの操作入力により変更されてもよいし、モーションキャプチャ技術に基づく当該一のユーザの動きを示す入力により変更されてもよい。また、一のユーザに係るユーザアバターＭ１の位置情報は、実空間における当該一のユーザの位置に基づいて特定されてもよい。例えば、第１ユーザと第２ユーザが実空間において同じ位置に位置する場合に、第１ユーザアバターＭ１の位置情報と第２ユーザアバターＭ１の位置情報は同じに設定されてもよい。以下では、ユーザアバターＭ１の位置情報を変更するためのユーザ入力を、「移動操作入力」とも称し、ユーザアバターＭ１の向き情報を変更するためのユーザ入力を、「方向操作入力」とも称する。

移動処理部１６２は、第１ユーザアバターＭ１の移動に関する処理を行う第１移動処理部１６２１と、第２ユーザアバターＭ１の移動に関する処理を行う第２移動処理部１６２２とを含む。なお、第１移動処理部１６２１及び第２移動処理部１６２２は、処理対象のユーザアバターＭ１が異なるだけで実質的に同様の機能を有するので、以下では、第１移動処理部１６２１について主に説明する。従って、以下の説明において、第２移動処理部１６２２に関しては、“第１”を“第２”に読み替えれば、実質的に成り立つ。

第１移動処理部１６２１は、ユーザ入力取得部１４０により取得される第１ユーザからの移動操作入力（第１入力の一例）や方向操作入力に基づいて、仮想空間における第１ユーザアバターＭ１の位置情報や向き情報を変化させる。本実施形態では、一例として、仮想空間における第１ユーザアバターＭ１の位置情報及び向き情報は、端末用画像を形成する実空間画像に対応付けられている座標系で管理される。なお、仮想空間における第１ユーザアバターＭ１の位置情報は、基本的に、第１画像条件生成部１４４１により生成される端末用画像用の画像生成条件における第１ユーザアバターＭ１の描画位置と対応するが、常に一致する必要はない。例えば、上述した撮影配置処理の際のように、第１ユーザアバターＭ１の位置情報が変化することなく、端末用画像における第１ユーザアバターＭ１の描画位置が変化するような画像生成条件が生成されてもよい。これは、向き情報についても同様である。

第１移動処理部１６２１は、第１ユーザからの移動操作入力に基づいて、仮想空間において自由に（無制限に）、第１ユーザアバターＭ１の位置情報を変化させてもよいが、好ましくは、所定の制約条件下で、第１ユーザアバターＭ１の位置情報を変化させてよい。所定の制約条件は、任意であるが、例えば実空間における物理現象に明らかに反するような移動（例えば建物の壁を透過するような移動）が禁止されるように設定されてもよい。

また、第１移動処理部１６２１は、仮想空間を管理する管理ユーザにより設定されうるモード等に応じて、所定の制約条件を変化させてもよいし、所定の制約条件をなくしてもよい。例えば、探検モードなるモードが設定された場合は、所定の制約条件が実質的に無くされてもよいし、有意に緩くされてもよい。

本実施形態では、仮想空間を管理する管理ユーザは、各種モードを設定可能であり、各種モードは、各種ミッションモードを含む。各種ミッションモードは、上述した特定アイテムを探してゲットするミッションモードや、特定の場所まで移動するミッションモード等を含んでよい。本実施形態では、各種ミッションモードは、特定の体験や学習用のミッションモードであって、複数の課題（サブミッション）を順にクリアしていくことで体験や学習の深度を高めるミッションモード（以下、「進行型ミッションモード」とも称する）を含む。

図１９は、進行型ミッションモードの説明図である。図１９には、仮想空間内の空間部が概念的に五角形の領域で模式的に示されている。各空間部ＳＰ３０からＳＰ３５のそれぞれでは、対応する課題（サブミッション）が対応付けられる。

この場合、ユーザは、時計回りに周回する態様（矢印Ｒ１９参照）で、空間部ＳＰ３０からＳＰ３５を順に巡る態様で複数の課題（サブミッション）を順にクリアしていくことで、体験や学習の深度を高めることができる。この場合、第１移動処理部１６２１は、空間部ＳＰ３０からＳＰ３４のいずれか１つである一の空間部（第１領域の一例）において、当該空間部に対応付けられた課題（第１移動条件の一例）が第１ユーザによりクリアされた場合に、次の空間部（第２領域の一例）への第１ユーザアバターＭ１の移動を許可してよい。あるいは、次の空間部への移動は、強制的な移動の形態であってもよいし、移動が許可されたユーザからの指示に応答して実現されてもよい。

なお、図１９に示す例では、一例として、概念的に周回する進行型ミッションモードが示されているが、進行型ミッションモードは、周回に限らず、いわゆる“すごろく”のように、多様な態様で実現されてよい。

例えば、フランスへの旅行に係る進行型ミッションモードは、羽田空港に移動するサブミッション、羽田空港で両替を行うサブミッション、チェックインカウンターにて搭乗手続きを行うサブミッション、手荷物検査を行うサブミッション、税関／出国審査を通るサブミッション、飛行機に搭乗するサブミッション、フランスにて入国手続きを行うサブミッション、といった具合に、実際の行動に類するサブミッションを含んでもよい。この場合、事前に準備できるので、初めて海外に旅行に行く子供用の事前体験としても有用となる。また、修学旅行や社内旅行等において事前の待ち合わせ場所の確認等にも利用できる。また、巨大な駅のような複雑な構造の駅における待ち合わせや、単独行動、グループ自由行動等の分散行動のための事前学習としても利用できる。

また、第１移動処理部１６２１は、図６を参照して上述した瞬間移動用のボタンＢ６０５からＢ６０９に係る移動操作入力に基づいて、対応する場所に第１ユーザアバターＭ１を移動させる。また、上述したイベントＥ１（共通のルームや特定の位置に瞬間移動するイベント）を実現する場合は、第１移動処理部１６２１は、同様の瞬間移動を実現してもよい。

ところで、本実施形態のように実空間画像を利用することで仮想空間が実空間に近い空間である場合、各ユーザアバターＭ１の行動範囲（活動範囲）が比較的広くなりえる。従って、ある決まりの下で複数のユーザアバターＭ１が集団で活動（集団行動）をする際には、収拾がつかなくなるおそれがある。特に、探検モードのようなモードが設定されている場合、各ユーザアバターＭ１は自由に色々な場所に移動できるため、統率された行動（例えば集合など）が難しくなる場合がある。

そこで、本実施形態では、移動処理部１６２は、仮想空間を管理する管理ユーザ又はその類の特定ユーザ（所定ユーザの一例）からの集合指示入力（第３入力の一例）に基づいて、各ユーザアバターＭ１を、当該集合指示入力に応じた位置に移動させてもよい。この場合、特定ユーザは、管理ユーザの指示を受けたユーザであってもよい。また、例えば、生徒である複数のユーザに、進行型ミッションモードを設定する場合、特定ユーザは、生徒たちを管理するユーザであってもよい。この場合、特定ユーザは、事前に登録されてもよい。

集合指示入力に応じた位置は、あらかじめ規定された位置であってもよい。この場合、あらかじめ規定された位置は、複数用意されてよく、各ユーザアバターＭ１にとって最も近い位置であってもよい。また、あらかじめ規定された位置は、特定ユーザ等によりあらかじめ指定可能であってもよい。また、集合指示入力は、当該集合指示入力に応じた位置を指定する位置情報を含んでもよい。

移動処理部１６２による移動対象のユーザアバターＭ１は、同一グループ内の各ユーザアバターＭ１であってもよいし、同一グループ内の一部のユーザアバターＭ１に限定されてもよい。

移動処理部１６２は、特定ユーザからの集合指示入力がユーザ入力取得部１４０により取得された場合に、強制的に、各ユーザアバターＭ１を、当該集合指示入力に応じた位置（例えば集合場所）に移動させてもよい。あるいは、移動処理部１６２は、各ユーザからの応答入力（承認の入力）に基づいて、それぞれのユーザアバターＭ１を、当該集合指示入力に応じた位置に移動させてもよい。この場合、ユーザは拒否することも可能であり、自由度の高い構成を実現できる。なお、集合指示入力は、強制的な集合指示入力と、拒否可能な集合指示入力を含む複数種類の入力が用意されてもよい。なお、特定ユーザからの集合指示入力に係る指示内容は、強制的な移動に先立って、音声やメッセージ等の形態で伝達されてもよい。

画像データ記憶部１７２は、上述した画像データ取得部１５２１により取得されたイベント画像データに係る画像生成条件を記憶する。画像データ記憶部１７２は、ユーザごとの記憶領域を備えてよく、この場合、ユーザごとに、ユーザごとの画像データ取得部１５２１により取得されたイベント画像データに係る画像生成条件を記憶する。図２０は、画像データ記憶部１７２に記憶されるイベント画像データに係る画像生成条件の説明図である。図２０は、第１ユーザに係るイベント画像データに係る画像生成条件に関する。図２０に示す例では、イベント画像データに係る画像生成条件は、場所ＩＤが付与され、場所ＩＤごとに、カメラパラメータ、アバター情報、位置情報、及び日時情報を含む。この場合、場所ＩＤごとに、カメラパラメータ、アバター情報、位置情報、及び日時情報が組み込まれたＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）が発行されてもよい。イベント画像データに係る画像生成条件を記憶する場合、イベント画像データを記憶する場合に比べて、記憶容量の効率化を図ることができる。なお、変形例ではイベント画像データに係る画像生成条件を記憶することに代えて、イベント画像データ自体が記憶されてもよい。

場所ＩＤは、画像取得イベントごとに付与される識別子である。カメラパラメータは、画像取得イベントの際の第１視点に関する情報であり、例えば方位角、迎角、画角等を含んでよい。アバター情報は、対応するイベント画像データに描画されるべき描画対象の第２ユーザアバターＭ１に関する情報である。位置情報は、取得されたイベント画像データに係る実空間画像の位置情報である。日時情報は、対応するイベント画像データの取得の日時を表す。

なお、第１ユーザに係る記憶領域内のイベント画像データに係る画像生成条件へのアクセスは、第１ユーザのみ可能であってもよいし、同一グループ内の第２ユーザも可能であってもよいし、他のユーザも可能であってもよい。第１ユーザに係る記憶領域内のイベント画像データに係る画像生成条件へのアクセス権は、第１ユーザにより適宜設定可能であってよい。また、イベント画像データごとにアクセス権が設定可能とされてもよい。

なお、本実施形態では、画像データ記憶部１７２には、画像データ取得部１５２１により取得されたイベント画像データに係る画像生成条件が記憶されているが、これに加えて、他のタイミングで取得された画像データ又はその画像生成条件も記憶されてもよい。

イベント画像データに係る画像生成条件へのアクセスは、イベント画像データに係る画像を描画（再現）するためのアクセスであってよい。この場合、例えば写真再現ページにおいて、ユーザは、アクセスした画像生成条件に基づいて、当該画像生成条件に係るイベント画像データに係る画像を閲覧できる。この場合、写真再現ページでは、後述する画像出力部２１２は、アクセスにより取得された画像生成条件をクエリパラメータとしてパースして変数に格納し、Ｇｏｏｇｌｅ社が提供する“Ｇｏｏｇｌｅ Ｍａｐｓ ＡＰＩ”又はその類のＡＰＩのメソッドに引数として入力、アバター情報の選定などを行うことで、イベント画像データに係る画像の生成（再現）を実現してよい。

（端末装置の機能）
端末装置２０は、図１２に示すように、画像生成条件受信部２１０と、画像出力部２１２と、ユーザ入力生成部２１４と、ユーザ入力送信部２１６とを含む。

画像生成条件受信部２１０は、上述したサーバ装置１０の画像条件生成部１４４により生成される端末用画像用の画像生成条件を受信する。

画像出力部２１２は、画像生成条件受信部２１０により受信された端末用画像用の画像生成条件に基づいて、端末用画像を描画し、描画した端末用画像を、上述した表示部２３上に出力する。例えば、画像出力部２１２は、端末用画像用の画像生成条件をクエリパラメータとしてパースして変数に格納し、Ｇｏｏｇｌｅ社が提供する“Ｇｏｏｇｌｅ Ｍａｐｓ ＡＰＩ”又はその類のＡＰＩのメソッドに引数として入力、アバター情報の選定などを行うことで、端末用画像を描画してよい。なお、画像生成条件を基にサーバ装置１０によって画像データ（ＨＴＭＬ文書＋画像）を生成し、端末装置２０は、画像生成条件そのものから直接画像を描画せず、サーバ装置１０から受信した画像データ（ＨＴＭＬ文書＋画像）を基に撮像画像を含む表示画面を表示部２３上に描画するようにしてもよい。

ユーザ入力生成部２１４は、上述した入力部２４を介して入力される各種入力に応じた信号を生成する。

ユーザ入力送信部２１６は、ユーザ入力生成部２１４により受信された信号をサーバ装置１０に送信する。この場合、サーバ装置１０は、かかる信号を受信することで、対応するユーザによる各種入力を取得する。

ところで、上述したサーバ装置１０及び端末装置２０間の機能の分担は、あくまで一例であり、上述したように、多様に変更が可能である。すなわち、サーバ装置１０の機能の一部又は全部は、適宜、端末装置２０により実現されてもよい。

例えば、図２１及び図２１Ａに示すような分担態様が実現されてもよい。この場合も、サーバ装置１０Ａと各ユーザの端末装置２０Ａとが連携して、上述したサーバ装置１０と端末装置２０とが連携する場合と同様の機能を実現できる。図２１及び図２１Ａに示すような分担態様の場合、第１判定部１４６、画像条件生成部１４４の第１画像条件生成部１４４１、イベント発生部１５２、第１相対関係出力部１５４、移動処理部１６２の第１移動処理部１６２１の各機能は、以下で説明するように、端末装置２０Ａにおいて各ブラウザで行うことが可能である。

図２１Ａに示すような端末装置２０Ａにおいては、例えば、シャッタボタンである操作ボタンＢ６０２（図６参照）が押されたときに、その際の画像生成条件を生成し且つサーバ装置１０に送信することや、既にサーバ装置１０から受信済みのアバター位置情報等のデータを使って写真（例えば記念撮影で得られた写真又は動画）に係る端末画像用画像を描画すること等が可能である。

図２１に示す例では、サーバ装置１０Ａは、ユーザデータベース１３０と、アバターデータベース１３２と、位置情報取得部１６６と、位置情報送信部１６７と、データ更新処理部１６８とを含む。なお、位置情報取得部１６６、位置情報送信部１６７、及びデータ更新処理部１６８は、サーバ装置１０Ａのサーバ制御部（図１のサーバ制御部１３参照）が、サーバ装置１０Ａのサーバ記憶部（図１のサーバ記憶部１２参照）内の１つ以上のプログラムを実行することで実現できる。

位置情報取得部１６６は、各ユーザアバターＭ１の位置／向き情報を各端末装置２０から受信することで取得する。位置情報取得部１６６は、各ユーザアバターＭ１の位置／向き情報を取得すると、ユーザデータベース１３０内の記憶データを更新する。ユーザデータベース１３０内には、図１３に示したように、ユーザアバターＩＤごとの位置／向き情報が記憶されてよい。

位置情報送信部１６７は、ユーザデータベース１３０内のユーザアバターＭ１の位置／向き情報を、送信対象の端末装置２０Ａに送信する。一のユーザアバターＭ１の位置／向き情報の送信対象の端末装置２０Ａは、当該一のユーザアバターＭ１と同一グループに属する他のユーザアバターＭ１に係るユーザの端末装置２０Ａを含む。これにより、同一グループ内の各ユーザに係る端末装置２０Ａは、他のユーザに係る各ユーザアバターＭ１の位置／向き情報を得ることができる。この場合、描画対象でない不要なユーザアバターＭ１については、その位置／向き情報が送信されることがなく、通信負荷の低減を図ることができる。

データ更新処理部１６８は、ユーザデータベース１３０やアバターデータベース１３２内のデータに基づいて、各ユーザの端末装置２０Ａに更新データを送信する。なお、更新データの送信タイミングは、適宜設定されてよく、端末装置２０Ａからの要求に応じたタイミングを含んでよい。

図２１Ａに示す端末装置２０Ａは、仮想現実アプリケーションが、ブラウザ上で利用できるＷｅｂアプリケーションの形態である場合に好適である。端末装置２０Ａは、画像出力部２１２Ａ、ユーザ入力生成部２１４Ａ、及びユーザ入力送信部２１６Ａを含む。画像出力部２１２Ａ、ユーザ入力生成部２１４Ａ、及びユーザ入力送信部２１６Ａは、図１２を参照して、上述した画像出力部２１２、ユーザ入力生成部２１４、及びユーザ入力送信部２１６と実質的に同様であってよい。なお、画像出力部２１２Ａは、後述する第１画像条件生成部２４４１Ａが生成する端末用画像用の画像生成条件に基づいて、端末用画像を描画し、描画した端末用画像を、上述した表示部２３上に出力する。

更に、図２１Ａに示す例では、端末装置２０Ａは、位置情報更新部２４１Ａと、位置管理部２４２Ａと、第１画像条件生成部２４４１Ａと、第１移動処理部２６２１Ａと、第１判定部２４６Ａと、インタフェース形成部２４８Ａと、準備処理部２５０Ａと、イベント発生部２５２Ａと、第１相対関係出力部２５４Ａと、第２相対関係出力部２５６Ａと、第２判定部２５８Ａと、端末記憶部２２Ａとを含む。

以下では、第１ユーザに係る端末装置２０Ａについて説明するが、第２ユーザに係る端末装置２０Ａについても実質的に同様である。

位置情報更新部２４１Ａから第２判定部２５８Ａまでの各部は、端末装置２０Ａの端末制御部（図１の端末制御部２５参照）が、端末装置２０Ａの端末記憶部（図１の端末記憶部２２参照）内のプログラムである本実施形態に係る仮想現実アプリケーションを実行することで実現できる。また、端末装置２０Ａにおいて必要となる各種データの一時的な記憶は、端末記憶部２２ＡのうちＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２２１Ａにより実現できる。ＲＡＭ２２１Ａには、各種データが一時記憶機能として展開されるが、例えば、サーバ装置１０Ａにおいて作成されたＨＴＭＬ文書に基づいて、各種データをダウンロードし、一時的にＲＡＭ２２１Ａにデータが展開されて、ブラウザでの処理（描画等）に使用される。ブラウザを閉じると、ＲＡＭ２２１Ａに展開されたデータは消去される。

ＲＡＭ２２１Ａには、上述したサーバ装置１０のユーザデータベース１３０内のデータ（図１３参照）のうちの、第１ユーザアバターＭ１と同一グループに属する各ユーザアバターＭ１に関するデータだけが記憶されてもよいし、その他のデータが更に記憶されてもよい。ＲＡＭ２２１Ａ内のデータのうち、位置／向き情報のデータは、サーバ装置１０Ａから送信された位置／向き情報に基づいて位置情報更新部２４１Ａにより更新される。なお、ＲＡＭ２２１Ａ内のデータのうち他のデータは、適宜、サーバ装置１０Ａとの通信を介して、上述した更新データに基づいて更新されてもよい（例えば、本実施形態に係る仮想現実アプリケーションの起動時等）。

ＲＡＭ２２１Ａは、上述したサーバ装置１０のアバターデータベース１３２内のデータ（図１４参照）のうちの、第１ユーザアバターＭ１と同一グループに属する各ユーザアバターＭ１に関するデータだけが記憶されてもよいし、その他のデータが更に記憶されてもよい。ＲＡＭ２２１Ａ内のデータは、仮想現実アプリケーション（例えばＷｅｂアプリケーション）の起動時等にサーバ装置１０Ａとの通信を介して、上述した更新データに基づいて更新されてよい。

位置情報更新部２４１Ａは、上述したようにサーバ装置１０Ａからの受信データに基づいて、ＲＡＭ２２１Ａ内のデータのうちの、位置／向き情報のデータを更新する。また、位置情報更新部２４１Ａは、第１ユーザからの移動操作入力や方向操作入力に基づいて、ＲＡＭ２２１Ａ内のデータのうちの、第１ユーザに係る位置／向き情報のデータを更新してもよい。

位置管理部２４２Ａは、上述したサーバ装置１０の位置管理部１４２の同様の機能を実現する。ただし、各ユーザアバターＭ１の配置については、第１ユーザアバターＭ１と同じグループ内のユーザアバターＭ１に関してのみ実行されてもよいし、その他のユーザアバターＭ１に対して実行されてもよい。

第１画像条件生成部２４４１Ａは、上述したサーバ装置１０の第１画像条件生成部１４４１と同様の機能を実現する。第１画像条件生成部２４４１Ａは、生成した画像生成条件をサーバ装置１０Ａに送信してもよい。この場合、画像生成条件は、サーバ装置１０Ａ側でも記憶できる。

第１移動処理部２６２１Ａは、上述したサーバ装置１０の第１移動処理部１６２１と同様の機能を実現する。

第１判定部２４６Ａは、上述したサーバ装置１０の第１判定部１４６と同様の機能を実現する。ただし、第１判定部２４６Ａは、第１ユーザアバターＭ１に関して、第１所定条件を満たすか否かを判定する。

インタフェース形成部２４８Ａは、上述したサーバ装置１０のインタフェース形成部１４８と同様の機能を実現する。ただし、インタフェース形成部１４８は、第１ユーザ用の端末用画像に関する処理を行う。

準備処理部２５０Ａは、上述したサーバ装置１０の準備処理部１５０と同様の機能を実現する。ただし、準備処理部２５０Ａは、第１ユーザアバターＭ１用に（すなわち第１判定部２４６Ａによる判定結果に基づいて）、第１所定条件が満たされた場合の上述した準備処理を実行する。

イベント発生部２５２Ａは、上述したサーバ装置１０のイベント発生部１５２と同様の機能を実現する。ただし、イベント発生部２５２Ａは、第１ユーザアバターＭ１用のイベントを発生させる。イベント発生部２５２Ａは、画像データ取得部２５２１Ａと、各種イベント発生部２５２２Ａとを含む。

第１相対関係出力部２５４Ａは、上述したサーバ装置１０の第１相対関係出力部１５４と同様の機能を実現する。ただし、第１相対関係出力部２５４Ａは、第１ユーザアバターＭ１を基準とした第１相対関係を出力する。

第２相対関係出力部２５６Ａは、上述したサーバ装置１０の第２相対関係出力部１５６と同様の機能を実現する。ただし、第２相対関係出力部２５６Ａは、第１ユーザアバターＭ１を基準とした第２相対関係を出力する。

第２判定部２５８Ａは、上述したサーバ装置１０の第２判定部１５８と同様の機能を実現する。ただし、第２判定部２５８Ａは、第１ユーザアバターＭ１に関して、第２所定条件を満たすか否かを判定する。

ＲＡＭ２２１Ａは、上述したサーバ装置１０の画像データ記憶部１７２と同様の機能を実現する。ただし、ＲＡＭ２２１Ａは、画像データ取得部２５２１Ａにより取得されたイベント画像データに係る画像生成条件を記憶する。この場合も、写真再現ページでは、画像出力部２１２Ａは、アクセスにより取得された画像生成条件をクエリパラメータとしてパースして変数に格納し、Ｇｏｏｇｌｅ社が提供する“Ｇｏｏｇｌｅ Ｍａｐｓ ＡＰＩ”又はその類のＡＰＩのメソッドに引数として入力、アバター情報の選定などを行うことで、イベント画像データに係る画像の生成（再現）を実現してよい。

図２１Ｂは、図２１Ａに示した端末装置２０Ａに代えて実現されてもよい端末装置２０Ｂの機能ブロック図である。図２１Ｂに係る構成は、仮想現実アプリケーションが、ブラウザ上で利用できるＷｅｂアプリケーションとは異なるネイティブアプリケーションの形態である場合に好適である。なお、ネイティブアプリケーションは、事前に端末装置２０Ｂにダウンロードされて利用される。

図２１Ｂに示す例では、端末装置２０Ｂは、画像出力部２１２Ｂ、ユーザ入力生成部２１４Ｂ、及びユーザ入力送信部２１６Ｂを含む。画像出力部２１２Ｂ、ユーザ入力生成部２１４Ｂ、及びユーザ入力送信部２１６Ｂは、図１２を参照して、上述した画像出力部２１２、ユーザ入力生成部２１４、及びユーザ入力送信部２１６と実質的に同様であってよい。なお、画像出力部２１２Ｂは、後述する第１画像条件生成部２４４１Ｂが生成する端末用画像用の画像生成条件に基づいて、端末用画像を描画し、描画した端末用画像を、上述した表示部２３上に出力する。

更に、図２１Ｂに示す例では、端末装置２０Ｂは、ユーザデータベース２３０Ｂと、アバターデータベース２３２Ｂと、位置情報更新部２４１Ｂと、位置管理部２４２Ｂと、第１画像条件生成部２４４１Ｂと、第１移動処理部２６２１Ｂと、第１判定部２４６Ｂと、インタフェース形成部２４８Ｂと、準備処理部２５０Ｂと、イベント発生部２５２Ｂと、第１相対関係出力部２５４Ｂと、第２相対関係出力部２５６Ｂと、第２判定部２５８Ｂと、画像データ記憶部２７２Ｂとを含む。

以下では、第１ユーザに係る端末装置２０Ｂについて説明するが、第２ユーザに係る端末装置２０Ｂについても実質的に同様である。

位置情報更新部２４１Ｂから第２判定部２５８Ｂまでの各部は、端末装置２０Ｂの端末制御部（図１の端末制御部２５参照）が、端末装置２０Ｂの端末記憶部（図１の端末記憶部２２参照）内のプログラムである本実施形態に係る仮想現実アプリケーションを実行することで実現できる。また、ユーザデータベース２３０Ｂ、アバターデータベース２３２Ｂ及び画像データ記憶部２７２Ｂは、端末装置２０Ｂの端末記憶部（図１の端末記憶部２２参照）により実現できる。

ユーザデータベース２３０Ｂには、上述したサーバ装置１０のユーザデータベース１３０内のデータ（図１３参照）のうちの、第１ユーザアバターＭ１と同一グループに属する各ユーザアバターＭ１に関するデータだけが記憶されてもよいし、その他のデータが更に記憶されてもよい。ユーザデータベース２３０Ｂ内のデータのうち、位置／向き情報のデータは、サーバ装置１０Ａから送信された位置／向き情報に基づいて位置情報更新部２４１Ｂにより更新される。なお、ユーザデータベース２３０Ｂ内のデータのうち他のデータは、適宜、サーバ装置１０Ａとの通信を介して、上述した更新データに基づいて更新されてもよい（例えば、本実施形態に係る仮想現実アプリケーションの起動時等）。

アバターデータベース２３２Ｂは、上述したサーバ装置１０のアバターデータベース１３２内のデータ（図１４参照）のうちの、第１ユーザアバターＭ１と同一グループに属する各ユーザアバターＭ１に関するデータだけが記憶されてもよいし、その他のデータが更に記憶されてもよい。アバターデータベース２３２Ｂ内のデータは、グループの生成時やグループを形成するユーザアバターＭ１の構成変更時等にサーバ装置１０Ａとの通信を介して、上述した更新データに基づいて更新されてよい。

位置情報更新部２４１Ｂは、上述したようにサーバ装置１０Ａからの受信データに基づいて、ユーザデータベース２３０Ｂ内のデータのうちの、位置／向き情報のデータを更新する。また、位置情報更新部２４１Ｂは、第１ユーザからの移動操作入力や方向操作入力に基づいて、ユーザデータベース２３０Ｂ内のデータのうちの、第１ユーザに係る位置／向き情報のデータを更新してもよい。

位置管理部２４２Ｂは、上述したサーバ装置１０の位置管理部１４２の同様の機能を実現する。ただし、各ユーザアバターＭ１の配置については、第１ユーザアバターＭ１と同じグループ内のユーザアバターＭ１に関してのみ実行されてもよいし、その他のユーザアバターＭ１に対して実行されてもよい。

第１画像条件生成部２４４１Ｂは、上述したサーバ装置１０の第１画像条件生成部１４４１と同様の機能を実現する。第１画像条件生成部２４４１Ｂは、生成した画像生成条件をサーバ装置１０Ａに送信してもよい。この場合、画像生成条件は、サーバ装置１０Ａ側でも記憶できる。

第１移動処理部２６２１Ｂは、上述したサーバ装置１０の第１移動処理部１６２１と同様の機能を実現する。

第１判定部２４６Ｂは、上述したサーバ装置１０の第１判定部１４６と同様の機能を実現する。ただし、第１判定部２４６Ｂは、第１ユーザアバターＭ１に関して、第１所定条件を満たすか否かを判定する。

インタフェース形成部２４８Ｂは、上述したサーバ装置１０のインタフェース形成部１４８と同様の機能を実現する。ただし、インタフェース形成部１４８は、第１ユーザ用の端末用画像に関する処理を行う。

準備処理部２５０Ｂは、上述したサーバ装置１０の準備処理部１５０と同様の機能を実現する。ただし、準備処理部２５０Ｂは、第１ユーザアバターＭ１用に（すなわち第１判定部２４６Ｂによる判定結果に基づいて）、第１所定条件が満たされた場合の上述した準備処理を実行する。

イベント発生部２５２Ｂは、上述したサーバ装置１０のイベント発生部１５２と同様の機能を実現する。ただし、イベント発生部２５２Ｂは、第１ユーザアバターＭ１用のイベントを発生させる。イベント発生部２５２Ｂは、画像データ取得部２５２１Ｂと、各種イベント発生部２５２２Ｂとを含む。

第１相対関係出力部２５４Ｂは、上述したサーバ装置１０の第１相対関係出力部１５４と同様の機能を実現する。ただし、第１相対関係出力部２５４Ｂは、第１ユーザアバターＭ１を基準とした第１相対関係を出力する。

第２相対関係出力部２５６Ｂは、上述したサーバ装置１０の第２相対関係出力部１５６と同様の機能を実現する。ただし、第２相対関係出力部２５６Ｂは、第１ユーザアバターＭ１を基準とした第２相対関係を出力する。

第２判定部２５８Ｂは、上述したサーバ装置１０の第２判定部１５８と同様の機能を実現する。ただし、第２判定部２５８Ｂは、第１ユーザアバターＭ１に関して、第２所定条件を満たすか否かを判定する。

画像データ記憶部２７２Ｂは、上述したサーバ装置１０の画像データ記憶部１７２と同様の機能を実現する。ただし、画像データ記憶部２７２Ｂは、画像データ取得部２５２１Ｂにより取得されたイベント画像データに係る画像生成条件を記憶する。この場合も、写真再現ページでは、画像出力部２１２Ｂは、アクセスにより取得された画像生成条件をクエリパラメータとしてパースして変数に格納し、Ｇｏｏｇｌｅ社が提供する“Ｇｏｏｇｌｅ Ｍａｐｓ ＢＰＩ”又はその類のＢＰＩのメソッドに引数として入力、アバター情報の選定などを行うことで、イベント画像データに係る画像の生成（再現）を実現してよい。

また、図２２及び図２２Ａに示すような分担態様が実現されてもよい。この場合も、サーバ装置１０Ｃと各ユーザの端末装置２０Ｃとが連携して、上述したサーバ装置１０と端末装置２０とが連携する場合と同様の機能を実現できる。

図２２に示すサーバ装置１０Ｃは、図１１に示したサーバ装置１０に対して、端末画像描画部１６４及び端末画像データ送信部１６５が追加された点が異なる。

端末画像描画部１６４は、画像条件生成部１４４により受信された端末用画像用の画像生成条件に基づいて、端末用画像を描画する。例えば、画像出力部２１２は、端末用画像用の画像生成条件をクエリパラメータとしてパースして変数に格納し、Ｇｏｏｇｌｅ社が提供する“Ｇｏｏｇｌｅ Ｍａｐｓ ＡＰＩ”又はその類のＡＰＩのメソッドに引数として入力、アバター情報の選定などを行うことで、端末用画像を描画してよい。

端末画像データ送信部１６５は、端末画像描画部１６４により描画された端末用画像用の画像データを、対応する各端末装置２０Ｃに送信する。

図２２Ａに示す端末装置２０Ｃは、図１２に示した端末装置２０に対して、画像生成条件受信部２１０及び画像出力部２１２が、それぞれ、画像データ受信部２１１及び画像出力部２１２Ｃに置換された点が異なる。

画像データ受信部２１１は、端末画像データ送信部１６５により送信される端末用画像用の画像データを受信する。

画像出力部２１２Ｃは、画像データ受信部２１１により受信された端末用画像のデータを、上述した表示部２３上に出力する。

次に、図２３及び図２４を参照して、仮想現実生成システム１の動作のうちの一部の動作例について説明する。

図２３は、画像取得イベントの発生に関する仮想現実生成システム１の動作例を概略的に示すタイミングチャートである。

図２３には、動作主体として、３つの端末装置２０として、第１ユーザに係る端末装置２０－１、第２ユーザに係る端末装置２０－２、及びサーバ装置１０が示されている。なお、ここでは、説明上、第２ユーザは、一人であるが、複数人であってよい。この場合、複数の第２ユーザのそれぞれに係る端末装置２０が、同様に動作する。これは、後述する図２４も同様である。

まず、第１ユーザ及び第２ユーザは、本実施形態に係る仮想現実アプリケーション（図２３では、「仮想現実アプリ」と表記）を起動し（ステップＳ２３０）、各種初期入力を行う。なお、仮想現実アプリの起動するタイミングは、例えば同じ時間帯であってよく、事前に連絡等により決められていてもよい。例えば、第１ユーザ及び第２ユーザが、メール等で事前にやり取りをすることで、当該時間帯がスケージュール調整の上で決定されてもよい。初期入力は、グループ名やユーザ名等の入力や、それぞれのユーザアバターＭ１を決定するための入力等を含んでよい。この場合、第１ユーザ及び第２ユーザは、同じグループに属するものとする。

次いで、第１ユーザ及び第２ユーザは、それぞれ、それぞれのユーザアバターＭ１を介して仮想空間内を移動してよい（ステップＳ２３１）。第１ユーザ及び第２ユーザのそれぞれのユーザアバターＭ１が移動する仮想空間において、サーバ装置１０が第１所定条件の成否を監視する（ステップＳ２３２）。なお、ここでは、第１ユーザアバターＭ１と一の第２ユーザアバターＭ１との２体のユーザアバターＭ１だけが対象の仮想空間内に存在する。この場合、サーバ装置１０は、２体に関して共通の第１相対位置関係を算出して第１相対関係情報を出力しつつ、第１所定条件の成否を監視する。ただし、第１ユーザアバターＭ１と複数の第２ユーザアバターＭ１が存在する場合は、サーバ装置１０は、上述したように、ユーザアバターＭ１ごとに、一のユーザアバターＭ１を基準として第１所定条件の成否を監視する。

第１所定条件が成立すると、準備処理として、シャッタボタンである操作ボタンＢ６０２（図６参照）がアクティブ（操作可能な状態）とされる（ステップＳ２３３、ステップＳ２３４）。そして、第１ユーザにより操作ボタンＢ６０２が操作されると（ステップＳ２３５）、サーバ装置１０は、シャッタ音発生指示を第１ユーザアバターＭ１周辺のすべてのユーザアバターＭ１に係る端末装置２０に送信する（ステップＳ２３５Ａ）とともに、第１ユーザに関して画像取得イベントを発生させる（ステップＳ２３６）。また、第２ユーザにより操作ボタンＢ６０２が操作されると（ステップＳ２３７）、サーバ装置１０は、シャッタ音発生指示を第２ユーザアバターＭ１の周辺のすべてのユーザアバターＭ１に係る端末装置２０に送信する（ステップＳ２３７Ａ）とともに、第２ユーザに関して画像取得イベントを発生させる（ステップＳ２３８）。なお、この場合、第１ユーザ側の画像取得イベント（ステップＳ２３６）で取得されるイベント画像データに係る画像生成条件と、第２ユーザ側の画像取得イベント（ステップＳ２３８）で取得されるイベント画像データに係る画像生成条件とは、第１視点と第２視点の相違に起因して異なりうる。また、ポーズ等も異なりうる。この場合、第１ユーザと第２ユーザとの間でイベント画像データの交換等も促進され、ユーザ間の交流の促進を図ることができる。ただし、変形例では、第１ユーザ側の画像取得イベント（ステップＳ２３６）で取得されるイベント画像データに係る画像生成条件と、第２ユーザ側の画像取得イベント（ステップＳ２３８）で取得されるイベント画像データに係る画像生成条件とは、実質的に同じであってもよい。この場合、サーバ装置１０の処理負荷を低減できる。

ここで、ステップＳ２３５Ａ及びステップＳ２３７Ａに関して、シャッタ音発生指示を受信した端末装置２０は、カメラのシャッタ音を模した音声情報を出力（再生）する。この場合、当該端末装置２０のユーザは、他のユーザによる画像取得イベントを知ることができる。これにより、当該場所での画像取得イベントの活性化を図ることができる。

図２４は、アイテム取得イベントの発生に関する仮想現実生成システム１の動作例を概略的に示すタイミングチャートである。図２４には、動作主体として、３つの端末装置２０として、第１ユーザに係る端末装置２０－１、第２ユーザに係る端末装置２０－２、管理ユーザに係る端末装置２０－３、及びサーバ装置１０が示されている。

まず、第１ユーザ及び第２ユーザは、本実施形態に係る仮想現実アプリケーション（図２４では、「仮想現実アプリ」と表記）を起動し、各種初期入力を行う。なお、仮想現実アプリの起動するタイミングは、例えば同じ時間帯であってよく、事前に連絡等により決められていてもよい。例えば、第１ユーザ及び第２ユーザが、管理ユーザの催すイベントに参加する場合、当該時間帯は、管理ユーザにより事前に通知されていてよい。初期入力は、グループ名やユーザ名等の入力を含んでよい。また、第１ユーザ及び第２ユーザが、管理ユーザの催すイベントに参加する場合、初期入力は、当該イベントを特定する情報や参加資格を示す情報の入力を含んでよい。

まず、管理ユーザは、端末装置２０－３を介して、ミッションモードを設定する（ステップＳ２４０）。なお、管理ユーザも、独自のユーザアバターＭ１を介して、仮想空間内で活動することが可能であってもよい。ミッションモードの内容は、あらかじめ管理ユーザにより構成されていてよい。サーバ装置１０は、開始されたミッションモードに応じたミッションを各ユーザに通知し（ステップＳ２４１）、ミッションが開始される（ステップＳ２４２）。ミッションは、例えば、上述したようなフラミンゴのたまごのような特定アイテム（取得目標アイテム）を探して取得するような探索型のミッションであってもよいし、特定のコンテンツを視聴して課題を提出することで特定アイテムに応じた仮想現実媒体（例えば修了情報）を得る学習型のミッションであってもよい。ここでは、特定アイテムを探して取得するような探索型のミッションであるとする。

次いで、第１ユーザ及び第２ユーザは、それぞれのユーザアバターＭ１を介して仮想空間内を移動してよい（ステップＳ２４３）。第１ユーザ及び第２ユーザのそれぞれのユーザアバターＭ１が移動する仮想空間において、サーバ装置１０は、特定アイテムを配置し、第２所定条件の成否を監視する（ステップＳ２４４）。この場合、サーバ装置１０は、ユーザアバターＭ１ごとに、共通の特定アイテムに対する第２相対位置関係を算出して第２相対関係情報を出力しつつ、第２所定条件の成否を監視する。

第２所定条件が成立すると、サーバ装置１０は、第２所定条件を成立させたユーザアバターＭ１に関してアイテム取得イベントを発生させる（ステップＳ２４５）。その後、管理ユーザは、適宜、端末装置２０－３を介して、集合指示入力を生成する（ステップＳ２４６）。この場合、例えば、各ユーザアバターＭ１は、集合指示入力に応じて、対応する所定の集合場所に強制的に移動される（ステップＳ２４７）。なお、上述したように、強制的に移動に代えて、各ユーザからの応答入力（承認の入力）に基づいて、対応する所定の集合場所に強制的に移動されてもよい。そして、サーバ装置１０は、ミッション修了条件が成立すると（ステップＳ２４８）、ミッションを終了させる（ステップＳ２４９）。なお、ミッション修了条件は、任意であり、例えば経過時間等に基づいて設定されてもよい。

次に、図２５以降を参照して、上述した実施形態に対する変形例について説明する。

図２５は、変形例によるサーバ装置１０Ｂの機能ブロック図である。図２６は、広告情報記憶部１７６内のデータの説明図である。

本変形例によるサーバ装置１０Ｂは、図１１を参照して上述したサーバ装置１０に対して、イベント履歴記憶部１７４と、移動履歴記憶部１７５と、広告情報記憶部１７６と、画像評価部１８０と、人気ポイント検出部１８１と、撮影禁止ポイント設定部１８２と、交流促進処理部１８３と、アバター検出部１８４と、アプリ連携処理部１８５と、シャッタ音発生部１８６と、ユーザスコア算出部１８７と、インセンティブ付与部１８８と、広告設定部１８９と、広告評価部１９０と、画像加工部１９２とを含む。

なお、本変形例に対する更なる変形例では、図１１を参照して上述したサーバ装置１０の各機能の一部が省略されてもよいし、イベント履歴記憶部１７４から画像加工部１９２の一部が省略されてもよい。

イベント履歴記憶部１７４には、仮想空間内の各座標で起きた各種イベントの履歴が記憶される。イベント履歴記録用の各座標の粒度は、任意であるが、例えば、施設単位であってもよい。あるいは、イベント履歴記録用の座標の粒度は、場所の属性に応じて設定されてもよい。履歴の記憶対象の各種イベントは、上述した画像取得イベント等であってよい。イベント履歴記憶部１７４内の各種イベントの履歴データは、適宜、特定のユーザ用に出力（表示）されてもよい。イベント履歴記憶部１７４内の各種イベントの履歴データは、ビックデータや集合知として利用されてもよい。

移動履歴記憶部１７５には、各ユーザアバターＭ１の移動履歴データ（仮想空間内の移動に関する履歴データ）が記憶される。各ユーザアバターＭ１の移動履歴データは、移動に関する座標の軌跡、日時、停止時間（滞在時間）等の情報を含んでよい。また、各ユーザアバターＭ１の向き情報の履歴データも、各ユーザアバターＭ１の移動履歴データと関連付けて記憶されてもよい。この場合、各ユーザアバターＭ１が、各座標においてどのような視線方向であったか等の情報を得ることができる。

広告情報記憶部１７６には、仮想空間に仮想現実媒体として配置される広告に関する各種情報（以下、「広告情報」と称する）が記憶される。図２６に示す例では、広告ＩＤごとに、広告主を特定する情報（広告主ＩＤ）、広告内容、広告の位置情報、広告期間、成果情報等のような各種関連情報が対応付けられている。

広告内容は、画像や動画の形態や、仮想空間内で活動する広告用アバターの形態であってよく、ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）看板のようなＡＲアイテムの形態であってよい。また、広告は、仮想空間内のイベントの形態で実現されてもよい。いずれの場合も、広告内容は、広告主により提供される情報に基づいて設定されてもよい。広告の位置情報は、実空間画像に対応付けられている座標系で設定されてもよい。なお、広告内容が広告用アバターの形態である場合、広告の位置情報は、広告用アバターの位置情報として動的に更新されてもよい。広告期間は、契約等に応じてあらかじめ決められる期間である。成果情報は、広告の成果を表す情報である。成果情報は、広告の分野で広く知られている指標値（例えばＣＰＩ：Ｃｏｓｔ Ｐｅｒ Ｉｎｓｔａｌｌ、ＣＰＡ：Ｃｏｓｔ Ｐｅｒ Ａｃｑｕｉｓｉｔｉｏｎ、ＣＴＲ：Ｃｌｉｃｋ Ｔｈｒｏｕｇｈ Ｒａｔｅ）やその類（例えばＣＰＡ：Ｃｏｓｔ Ｐｅｒ Ａｃｔｉｏｎ、ＣＰＣ：Ｃｏｓｔ Ｐｅｒ Ｃｌｉｃｋ、ＣＰＭ：Ｃｏｓｔ Ｐｅｒ Ｍｉｌｌｅ）を含んでよい。

画像評価部１８０は、各ユーザにより取得された画像データ又はその画像生成条件（例えば上述した画像取得イベントにより取得されたイベント画像データに係る画像生成条件）を評価／解析する。この場合、画像評価部１８０は、座標ごとの画像の撮像回数や、座標ごとの画像に含まれるユーザアバターＭ１の数等を数値化してもよい。

また、画像評価部１８０は、同じ場所での画像データであっても、珍しい物体やユーザアバターＭ１（例えば有名人のユーザアバターＭ１）が写っている場合に、かかるレアイベントを検出してもよい。また、画像評価部１８０は、初めて撮像された場所については、撮像したユーザ（以下、「第１撮像ユーザ」とも称する）を特定する情報を生成してもよい。

また、画像評価部１８０は、ユーザによる撮影行為（シャッタボタンである操作ボタンＢ６０２（図６参照）の操作）を仮想空間内の“自動販売機”として置き換える態様で、各種情報を生成してもよい。例えばアバターアイテムのアパレル店に関して、どこのお店でどれぐらい映えるアイテムをどのようにユーザアバター／ユーザが撮影したか又は購入したかを記録してもよい。この場合、かかる情報は、後述する交流促進処理部１８３によりユーザ間でシェアされてもよい。

人気ポイント検出部１８１は、仮想空間における人気ポイント（例えば映えポイント）を検出する。人気ポイントは、例えば各ユーザアバターＭ１による訪問回数が多い場所であり、各ユーザアバターＭ１の移動履歴データに基づいて検出されてもよい。また、人気ポイントは、イベント履歴記憶部１７４内の各種イベントの履歴データに基づいて検出されてもよい。この場合、画像取得イベントの発生回数が多いほど人気が高い場所として評価されてもよい。

また、人気ポイント検出部１８１は、各ユーザアバターＭ１の視線方向を評価することで、人気ポイントにおける人気の視線方向を検出してもよい。各ユーザアバターＭ１の視線方向は、上述した向き情報の履歴データに基づいて評価されてもよい。この場合、各ユーザアバターＭ１の視線が向けられる回数が多い物体や場所ほど人気が高い物体や場所として評価されてもよい。

このようにして、人気ポイント検出部１８１により検出される人気ポイントは、多様な態様で利用できる。例えば、人気ポイントは、人気度合いに応じてランク付けされてよく、各人気ポイントのランクがユーザに多様な態様で伝達されてもよい。例えば、各人気ポイントのランクは、人気度ランキング情報として、上位の所定数が表示されてもよい。また、人気上昇中の人気スポットがピックアップされてもよい。また、おすすめ情報として、ランクが高い人気ポイントが各ユーザに提示されてもよい。この場合、例えば上述した瞬間移動用のボタンＢ６０５からＢ６０９のいずれかが、提示された人気ポイント（場所）の行き先となり、当該人気スポットへの瞬間移動が可能とされてもよい。また、おすすめ情報として各ユーザに提示される人気スポットは、各ユーザの属性や好み等に基づいて、ユーザごとに抽出されてもよい。例えば、一のユーザに提示される人気スポットは、当該一のユーザに似た行動をしている他のユーザが良く訪れる人気スポットを含んでもよい。

撮影禁止ポイント設定部１８２は、画像取得イベントの禁止ポイント、及び／又は、通常の撮影の禁止ポイントを設定する。画像取得イベントの禁止ポイント等では、シャッタボタンである操作ボタンＢ６０２（図６参照）が非アクティブ化されてもよいし、非表示化されてもよい。撮影禁止ポイント設定部１８２は、例えば機密やプライバシー等の観点から禁止ポイントを自動的に設定してもよいし、管理ユーザからの入力に応じて禁止ポイントを設定してもよい。

交流促進処理部１８３は、所定の送信条件が満たされた場合に、一のユーザアバターＭ１のユーザにより操作ボタンＢ６０２（図６参照）の操作を介して取得された画像（図２０内のイベント画像データ又はその画像生成条件等）を、他のユーザ（例えばフレンド情報のユーザ）に送信する。所定の送信条件は、任意であり、各ユーザにより適宜設定されてもよい。この場合、交流促進処理部１８３は、ＱＲコード（登録商標）のような二次元コードを生成することで、対応する画像又はその画像の取得位置（場所）に他のユーザがアクセスできるようにしてもよい。また、この場合、交流促進処理部１８３は、インタフェース形成部１４８を介して、当該画像の取得場所に、他のユーザのユーザアバターＭ１が瞬間移動できるようなユーザインタフェースを形成してもよい。この場合、映えのある撮影ポイントを友人のユーザに紹介したり、友人やそのユーザアバターＭ１と一緒に写真撮ったり、といったユーザ間の各種交流を効果的に促進できる。

アバター検出部１８４は、特定の検出対象場所への一のユーザアバターＭ１の移動を検出した場合に、特定の検出対象場所において一のユーザアバターＭ１を検出した旨の通知（以下、「検出通知」とも称する）を生成する。アバター検出部１８４は、例えば特定の検出対象場所に設置された仮想カメラの画角内に、一のユーザアバターＭ１が入った場合に、検出通知を生成してもよい。検出通知は、検出したユーザアバターＭ１を特定する情報（ユーザアバターＩＤ）を含んでよい。また、アバター検出部１８４は、仮想カメラにより、検出したユーザアバターＭ１を撮影した画像データを検出通知に含めてもよい。検出通知の送信先（通知先）は、特定の検出対象場所ごとに設定されてもよい。特定の検出対象場所は、管理ユーザや特定のユーザにより設定可能であってよい。例えば、管理ユーザは、立入禁止区域等を特定の検出対象場所として設定してもよい。この場合、検出通知の送信先（通知先）は、当該特定の検出対象場所を設定した管理ユーザを含んでよい。

また、アバター検出部１８４は、特定の検出対象物体へ一のユーザアバターＭ１の視線が向けられた場合に、その旨の通知（以下、「特定の検出対象物体へ視線検出通知」とも称する）を生成する。特定の検出対象物体へ一のユーザアバターＭ１の視線が向けられたか否かは、各ユーザアバターＭ１の向き情報と特定の検出対象物体の位置情報とに基づいてリアルタイムに判定されてもよいし、上述した向き情報の履歴データに基づいてオフラインで判定されてもよい。特定の検出対象物体へ視線検出通知の送信先（通知先）は、上述した特定の検出対象場所と同様の態様で設定されてもよい。

シャッタ音発生部１８６は、仮想空間内の一の場所において一のユーザによりシャッタボタンである操作ボタンＢ６０２（図６参照）が操作された場合に、当該一の場所に位置する他のユーザアバターＭ１に係るユーザ（当該一のユーザとは異なる他のユーザ）に、シャッタボタンの操作があったことを知らせる情報（「撮像イベント発生情報」と称する）を出力する。撮像イベント発生情報は、例えば、シャッタ音のような音声情報を介して出力されてもよい。例えば、他のユーザに係る端末装置２０にシャッタ音発生指示（図２３のステップＳ２３５Ａ、２３７Ａ参照）が送信されてシャッタ音が出力（再生）されてもよい。この場合、他のユーザに、「この場所は写真を撮る価値がある場所である」ことを体感的かつ間接的に伝えることができる。このような構成では、人気ポイントではシャッタ音が多く聞こえる可能性が高くなる。これにより、各ユーザは、仮想空間における各人気ポイントを聴覚的に把握することができる。

ユーザスコア算出部１８７は、各ユーザ（又は各ユーザアバターＭ１）に対応付けられる各種スコアを算出する。各種スコアは、仮想空間における活動度合いの指標となるスコアを含んでよい。また、ユーザスコア算出部１８７は、上述した画像評価部１８０による評価結果に基づいて、上述したレアイベントを発生させたユーザ及び／又は上述した第１撮像ユーザに対して特別なスコア（ボーナススコア）を付与してもよい。あるいは、写真撮影会のようなイベントにおいては、各参加ユーザにより取得された写真（操作ボタンＢ６０２を介して取得された画像）に基づいて、各参加ユーザにスコアを付与してもよい。この場合、写真内の物体の配置（構図）等が評価対象とされてもよい。

インセンティブ付与部１８８は、インセンティブ付与条件が満たされた場合に、仮想空間内で活動する各ユーザアバターＭ１（又は各ユーザ）にインセンティブを付与する。インセンティブ付与条件は、ユーザアバターＭ１（又は各ユーザ）ごとに判定されてよい。また、インセンティブ付与条件は、インセンティブごとに又はインセンティブの属性ごとに付与されてもよい。例えば、インセンティブは、有名ポイントに対する命名権であってもよい。この場合、有名ポイントを最初に到来したユーザアバターＭ１や有名ポイントで初めて写真を撮ったユーザ（操作ボタンＢ６０２を操作したユーザ）に、命名権が付与されてもよい。この場合、インセンティブは、新たな有名ポイントが発生するごとに付与されてもよい。

また、インセンティブ付与部１８８は、ユーザスコア算出部１８７と同様に又はユーザスコア算出部１８７に代えて、上述したレアイベントを発生させたユーザ及び／又は上述した第１撮像ユーザに対して、特定のインセンティブ（例えば、最初に撮影したポイントであることの証明情報）を付与してもよい。また、インセンティブ付与部１８８は、ユーザスコア算出部１８７により付与されたスコアが閾値を超えるようなユーザに対して、特定のインセンティブを付与してもよい。

広告設定部１８９は、仮想空間において広告を設定する。広告設定部１８９は、広告を設定する場合に、新たな広告ＩＤを付与し、広告情報記憶部１７６内のデータ（図２６参照）を更新してよい。

このようにして広告設定部１８９により設定される広告に係る広告内容は、広告の期間の間、所定の提示条件が満たされるユーザ（ユーザアバターＭ１）に対して提示される。広告内容の提示は、上述した各ユーザ用の端末用画像に含められる態様で画像条件生成部１４４により画像生成条件が生成されることで、実現されてよい。この場合、画像条件生成部１４４は、実空間画像に態様で広告内容の画像や動画を重畳してよい。例えば、第１画像条件生成部１４４１は、第１ユーザアバターＭ１の位置／向き情報と、一の広告の位置情報との関係に基づいて、第１ユーザアバターＭ１の視界内に当該一の広告の位置情報が位置するか否かを判定する。そして、第１ユーザアバターＭ１の視界内に当該一の広告の位置情報が位置する場合、第１画像条件生成部１４４１は、第１ユーザに係る端末用画像に、対応する広告内容を描画するための画像生成条件を生成してよい。

所定の提示条件は、任意であるが、広告ＩＤごとにターゲット層が設定されてもよい。この場合、一の広告内容は、当該一の広告内容に対応付けられているターゲット層に一致するユーザ（ユーザアバターＭ１）に対してのみ提示可能とされてもよい。また、広告内容がＡＲアイテムの場合、所定の提示条件は、ＡＲアイテムを可視とするツール（例えば仮想現実媒体としてのスマートフォン）を有するユーザアバターＭ１に対してのみ提示可能とされてもよい。

広告設定部１８９は、広告の位置情報に応じて、広告に要するコスト（広告主が負担するコスト）を設定してもよい。この場合、広告設定部１８９は、人気ポイント検出部１８１により検出された人気ポイントにおけるコストが高くなる態様で、広告の位置情報に応じてコストを設定してもよい。例えば、渋谷のハチ公前のような場所はたくさんの人が撮影したくなるので、かかる場所に広告を設定する場合はコストが比較的高くなる。

広告評価部１９０は、広告ＩＤごとに、上述した成果情報を生成する。例えば、広告評価部１９０は、一の広告ＩＤについて、対応する広告内容にユーザアバターＭ１の視線が向けられた回数（すなわち広告内容が描画された端末用画像に係るユーザ数）や、アバターＭ１の視線が向けられた時間の積算値、画像取得イベント等による画像データに写り込んだ回数等を評価材料として利用してもよい。また、広告評価部１９０は、実空間の看板と仮想空間の看板に設定し広告効果を測定してもよい。これは、看板以外の広告についても同様である。

なお、このようにして広告評価部１９０により生成される成果情報は、実空間における広告コストの算出に利用されてもよいし、土地の価格の算出（不動産取引等）に利用されてもよい。これは、上述した人気ポイント検出部１８１による検出結果についても同様である。また、広告評価部１９０により生成される成果情報は、実空間における実広告の設定等に利用されてもよい。例えば、一の広告ＩＤに係る一の場所での成果情報に示す成果が比較的高い場合、実空間において、対応する広告をデジタルサイネージ等に表示することとしてもよい。このようにして、仮想空間内の広告を主として実空間内の広告を従として、仮想空間内の広告の成果情報に応じて実空間内の広告を連動して設定してもよい。

また、このようにして広告評価部１９０により生成される成果情報は、対応する仮想空間における各領域（空間部を含む）の価格に反映されてもよい。これは、仮想空間において土地（領域）の各種取引（販売や賃借等）が行われる場合に好適となる。

画像加工部１９２は、対応するユーザからの要求に応じて、画像データ記憶部１７２内の画像データに係る画像生成条件であって、当該ユーザに対応付けられた画像データに係る画像生成条件の各種加工処理を行う。各種加工処理は、任意であるが、例えば、上述した交流用のＱＲコード（登録商標）のような二次元コードを埋め込む処理を含んでよい。また、各種加工処理は、「六本木ヒルズにてＮ月Ｎ日ＮＮ時撮影」といった具合に、現実空間に基づく情報を画像やＵＲＬに紐付ける処理を含んでよい。また、各種加工処理は、コピーライトのような権利情報を埋め込む処理を含んでよい。また、各種加工処理の一部又は全部は、対応するユーザからの要求とは無関係に、自動的に実現されてもよい。また、各種加工処理の内容の一部又は全部は、事前にユーザにより設定（カスタマイズ）されてもよい。

また、各種加工処理は、不動産取引用の内見写真の自動生成処理を含んでよい。この場合、内見写真の自動生成処理は、ユーザアバターＭ１が訪問したみんなが住みたい場所、買いたい場所の映える写真や動画から、他のユーザアバターだけを除去する処理を含んでよい。

ところで、旧来の実空間に係る不動産写真に求められる機能として、「借り手／買い手などの顧客が興味を持ち、不動産販売業者に問い合わせをする」という、いわゆる美しさとか、実際の物件よりも広くてきれい、という印象を与えることがある。具体的には、広角レンズで撮影することで実際の人間の視界よりも広く見えるような画像を掲示することがある。また窓からの眺めや、カメラの向きについても撮影者の恣意で撮影・生成されることがある。

これに対して、本変形例による画像加工部１９２の自動生成処理を使った不動産写真の場合は、単なる３６０度カメラによる画像と異なり、実際の人間のサイズを比較し（狭い／広い・天井が高い／低いなど）、複数の利用者が同じ空間にいる場合のシミュレーションが可能となる。すなわち、ユーザアバターＭ１が実際の人間のサイズを反映できるから広さの感覚のリアリティさが増す。また、他のユーザの視点（注目した点、評価を高くした／低くした）などの保存が可能となる。これは、他者の注目した画角や方向が保存されない一般的な３６０度画像とは対照的である。また、不動産販売者も「他のユーザがこういうところを気にしました」ということがデータとして記録が可能となる。このようにして、画像データ記憶部１７２内の画像生成条件に係る画像は、名画面において商品性が高いショットとして利用が可能となるが、ここではユーザアバターＭ１を外して表示することで、不動産取引に好適な写真又は動画を得ることができる。なお、端末用画像は、上述したように実空間画像をベースとしており、上述したように例えばＪａｖａＳｃｒｉｐｔ（登録商標）上で合成することで、ユーザアバターの表示／非表示は動的に制御が可能である。

図２７は、変形例による端末装置２０Ｂの機能ブロック図である。本変形例による端末装置２０Ｂは、図１２を参照して上述した端末装置２０に対して、アプリ連携処理部２８５が追加された点が異なる。

アプリ連携処理部２８５は、本実施形態に係る仮想現実アプリケーションを、端末装置２０Ｂ内の他のＧＰＳ利用アプリや通知と連携させる。ＧＰＳ利用アプリとは、端末装置２０Ｂに内蔵されるＧＰＳ機能の位置情報を利用するアプリケーションを指し、その種類は任意である。例えば、第１ユーザに係る端末装置２０Ｂに、実空間内の特定の場所で特定の通知が発生するＧＰＳ利用アプリが実装されている場合、仮想空間内の、対応する特定の場所に第１ユーザアバターＭ１が位置する場合、当該ＧＰＳ利用アプリを介して特定の通知が発生してもよい。

また、アプリ連携処理部２８５は、実空間における第１ユーザの移動履歴（端末装置２０Ｂに内蔵されるＧＰＳ機能の位置情報の履歴）に基づいて、仮想空間内における第１ユーザアバターＭ１の位置情報を連動させてもよい。例えば、Ｍ月Ｍ日のＭ時からＬ時までの実空間における第１ユーザの移動履歴に基づいて、仮想空間内における第１ユーザアバターＭ１の位置情報を変化させてもよい。この場合、第１ユーザは、過去のＭ月Ｍ日のＭ時からＬ時までの実空間における体験を、第１ユーザアバターＭ１を介して仮想空間において振り返ることが可能である。

なお、本変形例によるサーバ装置１０Ｂ及び端末装置２０Ｂについても、上述したサーバ装置１０及び端末装置２０について図２１及び図２１Ａを参照して上述したように、上述したサーバ装置１０Ｂ及び端末装置２０Ｂ間の機能の分担は、多様に変更が可能である。例えば、イベント履歴記憶部１７４から画像加工部１９２の一部が端末装置２０Ｂにより実現されてもよい。

以上、実施形態について図面を参照して詳述してきたが、具体的な構成は上述した各種実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

例えば、上述した実施形態において、上述したイベント発生により取得される画像（例えば記念撮影で得られた写真又は動画）は、ＮＦＴとして流通可能とされてもよい。

１ 仮想現実生成システム
３ ネットワーク
１０、１０Ａ、１０Ｂ サーバ装置
１１ サーバ通信部
１２ サーバ記憶部
１３ サーバ制御部
２０、２０Ａ、２０Ｂ 端末装置
２１ 端末通信部
２２ 端末記憶部
２３ 表示部
２３Ａ ヘッドマウントディスプレイ
２４ 入力部
２５ 端末制御部
６０ 仮想カメラ
１３０ ユーザデータベース
１３２ アバターデータベース
１４０ ユーザ入力取得部
１４２ 位置管理部
１４４ 画像条件生成部
１４４１ 第１画像条件生成部
１４４２ 第２画像条件生成部
１４６ 第１判定部
１４８ インタフェース形成部
１５０ 準備処理部
１５２ イベント発生部
１５２１ 画像データ取得部
１５２２ 各種イベント発生部
１５４ 第１相対関係出力部
１５６ 第２相対関係出力部
１５８ 第２判定部
１６２ 移動処理部
１６２１ 第１移動処理部
１６２２ 第２移動処理部
１７２ 画像データ記憶部
２１０ 画像生成条件受信部
２１２ 画像出力部
２１４ ユーザ入力生成部
２１６ ユーザ入力送信部

Claims (26)

1. 仮想空間に、第１ユーザに対応付けられる第１表示媒体と、第２ユーザに対応付けられる第２表示媒体とを位置付ける位置管理部と、
   各ユーザから各種入力を取得する入力取得部と、
   前記第１表示媒体に対応付けられる第１視点から視た前記仮想空間の画像を含む第１表示画像であって、前記第１ユーザにより視認可能な第１表示画像を生成する第１画像条件生成部と、
   前記第２表示媒体に対応付けられる第２視点から視た前記仮想空間の画像を含む第２表示画像であって、前記第２ユーザにより視認可能な第２表示画像を生成する第２画像条件生成部と、
   前記仮想空間における前記第１表示媒体と前記第２表示媒体のそれぞれの位置、及び、前記仮想空間における前記第１表示媒体と前記第２表示媒体との第１相対位置関係、の少なくともいずれか一方が、第１所定条件を満たすか否かを判定する第１判定部と、
   前記第１判定部により前記第１所定条件が満たされたと判定された場合に、前記第１表示媒体と前記第２表示媒体とを含む複数の表示媒体により連携して実現可能な所定イベントを発生させるイベント発生部とを備える、情報処理システム。
2. 前記所定イベントは、画像取得イベントを含み、
   前記イベント発生部は、前記仮想空間の画像データであって、前記第１ユーザの画像又は前記第１表示媒体と前記第２ユーザの画像又は前記第２表示媒体とを含む特定の画像データ又はその画像生成条件を取得する画像データ取得部を含む、請求項１に記載の情報処理システム。
3. 前記画像データ取得部は、前記特定の画像データを、前記第１表示画像に基づいて決定する、請求項２に記載の情報処理システム。
4. 前記第１表示媒体及び前記第２表示媒体のそれぞれは、アバターの形態であり、
   前記第１画像条件生成部は、前記第１所定条件が満たされたと判定された場合に、複数種類のポーズのうちから２つのポーズを選択するとともに、前記第１表示媒体及び前記第２表示媒体をそれぞれ選択したポーズで描画する、請求項３に記載の情報処理システム。
5. 前記第１ユーザ、前記第２ユーザ又は他のユーザによりアクセス可能な態様で前記特定の画像データ又は前記画像生成条件を記憶する画像データ記憶部を更に備える、請求項２から４のうちのいずれか１項に記載の情報処理システム。
6. 前記第１判定部により前記第１所定条件が満たされたと判定された場合に、前記所定イベントを発生可能とするための準備処理を行う準備処理部を更に備える、請求項１から５のうちのいずれか１項に記載の情報処理システム。
7. 前記第１表示画像にユーザインタフェースを形成するインタフェース形成部を更に備え、
   前記イベント発生部は、更に、前記入力取得部により前記第１ユーザからの所定入力が取得された場合に、前記所定イベントを発生させ、
   前記準備処理部は、前記準備処理として、前記インタフェース形成部を介して、前記所定入力を入力するためのユーザインタフェースを形成する、請求項６に記載の情報処理システム。
8. 前記準備処理部は、前記準備処理として、前記第１画像条件生成部を介して、前記第１表示媒体と前記第２表示媒体のそれぞれが前記第１表示画像に含まれるように、前記第１表示画像を描画する、請求項６又は７に記載の情報処理システム。
9. 前記第１所定条件は、前記仮想空間において、特定位置に対する前記第１表示媒体と前記第２表示媒体のそれぞれの位置が所定距離内である場合に、又は、前記仮想空間において、前記仮想空間における前記第１表示媒体と前記第２表示媒体との相対距離が所定距離内である場合に、満たされる、請求項１から８のうちのいずれか１項に記載の情報処理システム。
10. 前記第１相対位置関係に基づいて、前記第１表示画像及び前記第２表示画像のそれぞれに、前記第１相対位置関係を表す又は示唆する第１相対関係情報を出力する第１相対関係出力部を更に備える、請求項１から９のうちのいずれか１項に記載の情報処理システム。
11. 前記第１相対関係情報は、前記第１相対位置関係に係る方向を表すコンパスの形態の画像、及び、前記第１相対位置関係に係る距離を表す数字の画像のうちの、少なくとも一方を含む、請求項１０に記載の情報処理システム。
12. 前記第１相対関係出力部は、前記仮想空間における前記第１表示媒体の向きと前記仮想空間における前記第１表示媒体と前記第２表示媒体のそれぞれの位置とに基づいて、前記第１表示画像に重畳表示する前記第１相対関係情報に係る前記方向を算出し、前記仮想空間における前記第２表示媒体の向きと前記仮想空間における前記第１表示媒体と前記第２表示媒体のそれぞれの位置とに基づいて、前記第２表示画像に重畳表示する前記第１相対関係情報に係る前記方向を算出する、請求項１１に記載の情報処理システム。
13. 前記位置管理部は、更に、前記仮想空間に特定の表示媒体を位置付け、
    前記仮想空間における前記第１表示媒体の位置と、前記仮想空間における前記特定の表示媒体の位置とに基づいて、第２所定条件を満たすか否かを判定する第２判定部と、
    前記イベント発生部は、更に、前記第２判定部により前記第２所定条件が満たされたと判定された場合に、前記第１ユーザ又は前記第１表示媒体に、前記特定の表示媒体に応じた所定情報を対応付ける、請求項１から１２のうちのいずれか１項に記載の情報処理システム。
14. 前記所定情報は、前記特定の表示媒体を含む、請求項１３に記載の情報処理システム。
15. 前記第２所定条件は、前記仮想空間において、前記仮想空間における前記第１表示媒体と前記特定の表示媒体との相対距離が所定距離内である場合に満たされる、請求項１３又は１４に記載の情報処理システム。
16. 前記仮想空間における前記第１表示媒体と前記特定の表示媒体との第２相対位置関係に基づいて、前記第１表示画像に、前記第２相対位置関係を表す又は示唆する第２相対関係情報を出力する第２相対関係出力部を更に備える、請求項１３から１５のうちのいずれか１項に記載の情報処理システム。
17. 前記第２相対関係情報は、前記第２相対位置関係に係る方向を表すコンパスの形態の画像、及び、前記第２相対位置関係に係る距離を表す数字の画像のうちの、少なくとも一方を含む、請求項１６に記載の情報処理システム。
18. 前記第２相対関係出力部は、前記第１表示媒体の向きと前記仮想空間における前記第１表示媒体と前記特定の表示媒体のそれぞれの位置とに基づいて、前記第１表示画像に重畳表示する前記第２相対関係情報に係る前記方向を算出する、請求項１７に記載の情報処理システム。
19. 前記入力取得部により取得される前記第１ユーザからの第１入力に基づいて、前記仮想空間における前記第１表示媒体の位置を変化させる第１移動処理部と、
    前記入力取得部により取得される前記第２ユーザからの第２入力に基づいて、前記仮想空間における前記第２表示媒体の位置を変化させる第２移動処理部とを更に備え、
    前記第１移動処理部は、第１移動条件が満たされた場合に、前記仮想空間における第１領域から第２領域への前記第１表示媒体の移動を許可し、
    前記第２移動処理部は、第２移動条件が満たされた場合に、前記仮想空間における前記第１領域から前記第２領域への前記第２表示媒体の移動を許可する、請求項１３から１８のうちのいずれか１項に記載の情報処理システム。
20. 前記第１移動条件は、前記第１ユーザ又は前記第１表示媒体に前記所定情報が対応付けられる場合に満たされ、
    前記第２移動条件は、前記第２ユーザ又は前記第２表示媒体に前記所定情報が対応付けられる場合に満たされる、請求項１９に記載の情報処理システム。
21. 前記第１移動処理部及び前記第２移動処理部は、前記入力取得部により取得される所定ユーザからの第３入力に基づいて、前記仮想空間における前記第１表示媒体及び前記第２表示媒体の位置を、前記第３入力に応じた位置に移動させる、請求項１９又は２０に記載の情報処理システム。
22. 前記第１移動処理部及び前記第２移動処理部は、前記第３入力に基づいて、前記仮想空間における前記第１表示媒体及び前記第２表示媒体の位置を、前記第３入力に応じた位置に強制的に移動させる、請求項２１に記載の情報処理システム。
23. 前記仮想空間は、実空間に係る実画像データに基づいて生成される、請求項１から２２のうちのいずれか１項に記載の情報処理システム。
24. 前記第１判定部は、前記仮想空間における前記第１表示媒体又は前記第２表示媒体の位置を、実空間における前記第１ユーザ又は前記第２ユーザの位置情報に基づいて特定する、請求項１から２３のうちのいずれか１項に記載の情報処理システム。
25. 仮想空間に、第１ユーザに対応付けられる第１表示媒体と、第２ユーザに対応付けられる第２表示媒体とを位置付け、
    各ユーザから各種入力を取得し、
    前記第１表示媒体に対応付けられる第１視点から視た前記仮想空間の画像を含む第１表示画像であって、前記第１ユーザにより視認可能な第１表示画像を生成し、
    前記第２表示媒体に対応付けられる第２視点から視た前記仮想空間の画像を含む第２表示画像であって、前記第２ユーザにより視認可能な第２表示画像を生成し、
    前記仮想空間における前記第１表示媒体と前記第２表示媒体のそれぞれの位置、及び、前記仮想空間における前記第１表示媒体と前記第２表示媒体との第１相対位置関係、の少なくともいずれか一方が、第１所定条件を満たすか否かを判定し、
    前記第１所定条件が満たされたと判定した場合に、前記第１表示媒体と前記第２表示媒体とを含む複数の表示媒体により連携して実現可能な所定イベントを発生させることを含む、コンピュータにより実行される情報処理方法。
26. 仮想空間に、第１ユーザに対応付けられる第１表示媒体と、第２ユーザに対応付けられる第２表示媒体とを位置付け、
    各ユーザから各種入力を取得し、
    前記第１表示媒体に対応付けられる第１視点から視た前記仮想空間の画像を含む第１表示画像であって、前記第１ユーザにより視認可能な第１表示画像を生成し、
    前記第２表示媒体に対応付けられる第２視点から視た前記仮想空間の画像を含む第２表示画像であって、前記第２ユーザにより視認可能な第２表示画像を生成し、
    前記仮想空間における前記第１表示媒体と前記第２表示媒体のそれぞれの位置、及び、前記仮想空間における前記第１表示媒体と前記第２表示媒体との第１相対位置関係、の少なくともいずれか一方が、第１所定条件を満たすか否かを判定し、
    前記第１所定条件が満たされたと判定した場合に、前記第１表示媒体と前記第２表示媒体とを含む複数の表示媒体により連携して実現可能な所定イベントを発生させる
    処理をコンピュータに実行させる情報処理プログラム。

Images