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

Description

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

仮想現実映像によるユーザの体験内容に合わせて、ユーザに現実の体感を与えるために、現実のスタッフがユーザに対して直接又は間接的に働きかける仮想現実装置が知られている。

特開２０１９－１５０５７９号公報

上記のような従来技術では、現実におけるスタッフからユーザへの働きかけが必要であり、仮想現実において仮想空間内でのスタッフユーザによる一般ユーザへの各種補助を可能とすることが難しい。

そこで、１つの側面では、本発明は、仮想現実において仮想空間内でのスタッフユーザによる一般ユーザへの各種補助を可能とすることを目的とする。

１つの側面では、仮想空間を描画する空間描画処理部と、ユーザからの、前記仮想空間内における所定役割が付与されていない第１属性から前記仮想空間内における所定役割が付与されている第２属性への属性変化要求に基づいて、前記ユーザの属性を前記第１属性から前記第２属性へ変化させる第１属性変更部と、を含み、前記属性変化要求は、前記ユーザに関連する情報が所定条件を満たす場合に、実行可能である、情報処理システムが提供される。

１つの側面では、本発明によれば、仮想現実において仮想空間内でのスタッフユーザによる一般ユーザへの各種補助が可能となる。

本実施形態に係る仮想現実生成システムのブロック図である。 仮想現実生成システムにより生成可能な仮想現実の一例の説明図である。 仮想現実生成システムにより生成可能な仮想現実の他の一例の説明図である。 仮想現実生成システムにより生成可能な仮想現実の更なる他の一例の説明図である。 仮想現実生成システムにより生成可能な仮想現実の更なる他の一例の説明図である。 仮想空間内に位置するユーザアバタの画像の説明図である。 ユーザ補助機能に関連したサーバ装置の機能ブロック図の一例である。 ユーザ補助機能に関連した端末装置（譲受側の端末装置）の機能ブロック図の一例である。 ユーザデータベース内のデータの説明図である。 アバタデータベース内のデータの説明図である。 コンテンツ情報記憶部内のデータの説明図である。 空間状態記憶部内のデータの説明図である。 ユーザ補助機能に関連した動作例を示すタイミングチャートである。 一場面での端末用画面の一例を示す図である。 他の一場面での端末用画面の一例を示す図である。 ある時点でのコンテンツ提供用の仮想空間部内の状態を示す図である。 更なる他の一場面での端末用画面の一例を示す図である。 更なる他の一場面での端末用画面の一例を示す図である。 更なる他の一場面での端末用画面の一例を示す図である。 更なる他の一場面での端末用画面の一例を示す図である。 更なる他の一場面での端末用画面の一例を示す図である。 スタッフ管理機能に関連した動作例を示すタイミングチャートである。

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

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

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

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

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

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

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

本実施形態では、ユーザは、後述するユーザアバタｍ１（第１移動媒体の一例）を介して仮想空間内で活動する一般ユーザ（第１属性のユーザの一例）と、後述するスタッフアバタｍ２（第２移動媒体の一例）を介して仮想空間内で活動するスタッフユーザ（第２属性のユーザの一例）とを含む。なお、以下では、ユーザアバタｍ１とスタッフアバタｍ２とを特に区別しない場合は、単に「アバタ」と称する場合がある。

一般ユーザは、仮想現実生成システム１の運営に関与しないユーザであり、スタッフユーザは、仮想現実生成システム１の運営に関与するユーザである。スタッフユーザは、仮想現実内において一般ユーザの各種補助等を行う役割（エージェント機能）を有する。スタッフユーザには、例えば運営側との契約に基づいて、所定の給与が支払われてよい。なお、給与は、通貨や暗号資産等のような、任意の形態であってよい。以下では、特に言及しない限り、ユーザとは、一般ユーザとスタッフユーザの双方を指す。

また、ユーザは、更にゲストユーザを含んでもよい。ゲストユーザは、後述するコンテンツ（サーバ装置１０が提供するコンテンツ）として機能するゲストアバタを操作するアーティストやインフルエンサー等であってよい。なお、スタッフユーザの一部は、ゲストユーザとなる場合があってもよい。

本実施形態では、スタッフユーザは、基本的に、一般ユーザになることができる。換言すると、一般ユーザは、スタッフユーザになることができる一般ユーザと、スタッフユーザになることができない一般ユーザとを含む。なお、スタッフユーザの中には、スタッフユーザにしかなれないユーザが含まれてもよい。

サーバ装置１０が提供するコンテンツ（仮想現実で提供されるコンテンツ）の種類や数は、任意であるが、本実施形態では、一例として、サーバ装置１０が提供するコンテンツは、各種の映像のようなデジタルコンテンツを含んでよい。映像は、リアルタイムの映像であってもよいし、非リアルタイムの映像であってもよい。また、映像は、実画像に基づく映像であってもよいし、ＣＧ（Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ）に基づく映像であってもよい。映像は、情報提供用の映像であってよい。この場合、映像は、特定のジャンルの情報提供サービス（旅や、住まい、食品、ファッション、健康、美容等に関する情報提供サービス）、特定のユーザによる放送サービス（例えばＹｏｕｔｕｂｅ（登録商標））等に関するものであってよい。

また、本実施形態では、一例として、サーバ装置１０が提供するコンテンツは、後述するスタッフユーザからの指導やアドバイス等を含んでよい。例えば、ダンスのレッスンに係る仮想現実で提供されるコンテンツとして、ダンスの先生からの指導やアドバイス等を含んでよい。この場合、ダンスの先生がスタッフユーザとなり、生徒が一般ユーザとなり、仮想現実において生徒が先生から個別的に指導を受けることができる。

また、他の実施形態では、サーバ装置１０が提供するコンテンツは、一人以上のスタッフユーザやゲストユーザによるそれぞれのスタッフアバタｍ２やゲストアバタを介した各種のパフォーマンスやトークショー、会合、集会等であってもよい。

仮想現実におけるコンテンツの提供態様は、任意であり、例えば、コンテンツが映像である場合、仮想空間内の表示装置（仮想現実媒体）のディスプレイ上に、映像を描画することで、当該コンテンツの提供が実現されてもよい。なお、仮想空間内の表示装置は、任意の形態であり、仮想空間内に設置されるスクリーンや、仮想空間内に設置される大画面ディスプレイ、仮想空間内で携帯端末のディスプレイ等であってよい。

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

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

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

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

また、サーバ記憶部１２は、仮想空間を描画するためのデータ、例えば建物のような屋内の空間や、屋外の空間の画像等を記憶する。なお、仮想空間を描画するためのデータは、仮想空間ごとに複数種類用意され、使い分けられてもよい。

また、サーバ記憶部１２は、３次元の仮想空間内に配置された種々のオブジェクトに投影（テクスチャマッピング）するための種々の画像（テクスチャ画像）を記憶する。

例えば、サーバ記憶部１２は、各ユーザに対応付けられる仮想現実媒体としてのユーザアバタｍ１の描画情報を記憶する。仮想空間内にユーザアバタｍ１は、ユーザアバタｍ１の描画情報に基づいて描画される。

また、サーバ記憶部１２は、各スタッフユーザに対応付けられる仮想現実媒体としてのスタッフアバタｍ２の描画情報を記憶する。仮想空間内にスタッフアバタｍ２は、スタッフアバタｍ２の描画情報に基づいて描画される。

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

以下、ユーザアバタｍ１やスタッフアバタｍ２とは異なる任意の仮想現実媒体（例えば建物、壁、樹木、又はＮＰＣ等）に対応するオブジェクトであって、仮想空間内に描画されたオブジェクトを第２オブジェクトｍ３とも称する。なお、本実施形態では、第２オブジェクトは、仮想空間内で固定されたオブジェクトや、仮想空間内で移動可能なオブジェクト等を含んでもよい。また、第２オブジェクトは、仮想空間内に常に配置されるオブジェクトや、所定の条件が満たされた場合にだけ配置されるオブジェクト等を含んでもよい。

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

例えば、サーバ制御部１３は、仮想空間（画像）とともにユーザアバタｍ１やスタッフアバタｍ２等を描画し、表示部２３に表示させる。また、サーバ制御部１３は、所定のユーザ操作に応じて、仮想空間内においてユーザアバタｍ１やスタッフアバタｍ２を移動させる。サーバ制御部１３の具体的な処理の詳細は後述する。

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

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

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

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

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

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

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

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

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

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

図２Ａから図２Ｄは、仮想現実生成システム１により生成可能な仮想現実のいくつかの例の説明図である。

図２Ａは、旅行に係る仮想現実の説明図であり、仮想空間を平面視で示す概念図である。この場合、仮想空間内には、入場用チュートリアルのコンテンツを視聴する位置ＳＰ１と、ゲート付近の位置ＳＰ２とが設定される。図２Ａでは、二人の別々のユーザに対応付けられた、ユーザアバタｍ１が示されている。また、図２Ａ（図２Ｂ以降も同様）には、スタッフアバタｍ２も併せて示されている。

二人のユーザは、仮想現実で一緒に旅行に行くことを決定し、それぞれのユーザアバタｍ１を介して、仮想空間内に入る。そして、二人のユーザは、それぞれのユーザアバタｍ１を介して、位置ＳＰ１で入場用チュートリアルのコンテンツを視聴し（矢印Ｒ１参照）、位置ＳＰ２に至り（矢印Ｒ２参照）、その後、ゲートを通り（矢印Ｒ３参照）、飛行機（第２オブジェクトｍ３）に搭乗する。なお、入場用チュートリアルのコンテンツは、入場方法や仮想空間の利用の際の注意事項等を含んでもよい。そして、飛行機が離陸して、所望の目的地に至る（矢印Ｒ４参照）。この間、二人のユーザは、それぞれの端末装置２０の表示部２３を介して、仮想現実を体験できる。例えば、図３には、所望の目的地に係る仮想空間内に位置するユーザアバタｍ１の画像Ｇ３００が示される。このような画像Ｇ３００は、当該ユーザアバタｍ１に係るユーザの端末装置２０に表示されてよい。この場合、ユーザは、ユーザアバタｍ１（ユーザ名“ｆｕｊ”が付与されている）を介して仮想空間内を移動し、観光等を行うことができる。

図２Ｂは、教育に係る仮想現実の説明図であり、仮想空間を平面視で示す概念図である。この場合も、仮想空間内には、入場用チュートリアルのコンテンツを視聴する位置ＳＰ１と、ゲート付近の位置ＳＰ２とが設定される。図２Ｂでは、二人の別々のユーザに対応付けられた、ユーザアバタｍ１が示されている。

二人のユーザは、仮想現実で一緒に特定の教育を受けることを決定し、それぞれのユーザアバタｍ１を介して、仮想空間内に入る。そして、二人のユーザは、それぞれのユーザアバタｍ１を介して、位置ＳＰ１で入場用チュートリアルのコンテンツを視聴し（矢印Ｒ１１参照）、位置ＳＰ２に至り（矢印Ｒ１２参照）、その後、ゲートを通り（矢印Ｒ１３参照）、第１位置ＳＰ１１に至る。第１位置ＳＰ１１では、特定の第１コンテンツが提供される。次に、二人のユーザは、それぞれのユーザアバタｍ１を介して、第２位置ＳＰ１２に至り（矢印Ｒ１４参照）、特定の第２コンテンツの提供を受け、ついで、第３位置ＳＰ１３に至り（矢印Ｒ１５参照）、特定の第３コンテンツの提供を受け、以下、同様である。特定の第２コンテンツは、特定の第１コンテンツの提供を受けた後に提供されると習得効果が高くなり、特定の第３コンテンツは、特定の第２コンテンツの提供を受けた後に提供されると習得効果が高くなり、以下同様である。

例えば、教育が、ある３Ｄモデリング用のソフトウェアに関する場合、第１コンテンツは、当該ソフトウェアのインストールリンク画像等を含み、第２コンテンツは、アドオンのインストールリンク動画等を含み、第３コンテンツは、初期設定用動画を含み、第４コンテンツは、基本操作用動画を含む、といった具合であってよい。また、複数のユーザが同一ルームに存在する場合、同一の動画コンテンツを同一タイミングで再生してもよい（再生タイムコードを双方のクライアント側に送信する）。また、同期再生せずに、個々のユーザで異なる動画シーク状態にすることもできる。各ユーザは端末に接続されたカメラをつかい、顔画像をリアルタイム送信することができる。また、自分のコンピュータのデスクトップを表示したり、別のアプリケーションの画面を相互に配信することもできる（アプリ学習を隣に並べて手伝ってもらうことができる）。

図２Ｂに示す例では、各ユーザ（例えば生徒）は、第１位置ＳＰ１１から第８位置ＳＰ１８まで順にユーザアバタｍ１を介して移動して、各種のコンテンツの提供を順に受けることで、高い習得効果が得られる態様で特定の教育を受けることができる。あるいは、各種のコンテンツは、クイズ等の課題であってもよく、この場合、図２Ｂに示す例では、双六や脱出ゲームのようなゲームを提供できる。

図２Ｃは、レッスンに係る仮想現実の説明図であり、仮想空間を平面視で示す概念図である。この場合も、仮想空間内には、入場用チュートリアルのコンテンツを視聴する位置ＳＰ１と、ゲート付近の位置ＳＰ２とが設定される。図２Ｃでは、二人の別々のユーザに対応付けられた、ユーザアバタｍ１が示されている。

二人のユーザは、仮想現実で一緒に特定のレッスンを受けることを決定し、それぞれのユーザアバタｍ１を介して、仮想空間内に入る。そして、二人のユーザは、それぞれのユーザアバタｍ１を介して、位置ＳＰ１で入場用チュートリアルのコンテンツを視聴し（矢印Ｒ２１参照）、位置ＳＰ２に至り（矢印Ｒ２２参照）、その後、ゲートを通り（矢印Ｒ２３参照）、位置ＳＰ２０に至る。位置ＳＰ２０は、例えば円形の周壁Ｗ２で囲まれた領域のうちの、各ステージに対応する位置ＳＰ２１、ＳＰ２２、ＳＰ２３等を除くフリースペース内の各位置に対応する。ユーザは、それぞれのユーザアバタｍ１を介して、第１ステージに対応する第１位置ＳＰ２１に至ると（矢印Ｒ２４参照）、第１位置ＳＰ２１では、レッスン用の第１コンテンツの提供を受ける。また、同様に、ユーザは、それぞれのユーザアバタｍ１を介して、第２ステージに対応する第２位置ＳＰ２２に至ると（矢印Ｒ２５参照）、第２位置ＳＰ２２では、レッスン用の第２コンテンツの提供を受け、第３ステージに対応する第３位置ＳＰ２３に至ると（矢印Ｒ２６参照）、第３位置ＳＰ２３では、レッスン用の第３コンテンツの提供を受けることができる。

例えばレッスンがゴルフのレッスンである場合、レッスン用の第１コンテンツは、ユーザのスイングの改善点を解説するための映像であってよく、レッスン用の第２コンテンツは、プロゴルファーであるスタッフユーザによる見本スイングの実技であり、レッスン用の第３コンテンツは、ユーザのスイングの実技に対するプロゴルファーであるスタッフユーザによるアドバイスである。なお、スタッフユーザによる見本スイングの実技は、スタッフアバタｍ２により実現され、ユーザのスイングの実技は、ユーザアバタｍ１により実現される。例えば、スタッフユーザが実際にスイングの動きを行うと、その動きのデータ（例えばジェスチャ入力データ）に基づいて、その動きがスタッフアバタｍ２の動きにそのまま反映される。スタッフユーザによるアドバイスは、チャット等により実現されてよい。このようにして、各ユーザは、例えば自宅等で、友人とともに、仮想現実で一緒に各種のレッスンを先生（この場合、プロゴルファー）から、十分かつ必要な進度、深度で、受けることができる。

このようにして、本実施形態では、図２Ａから図２Ｃで例示したように、仮想現実において、ユーザは、ユーザアバタｍ１を介して、各コンテンツ提供位置に至ると、各コンテンツ提供位置に対応付けられた各コンテンツの提供を、各ユーザの必要なタイミング及び視聴形態で受けることができる。

図２Ｄは、スタッフユーザに関連した仮想現実の説明図であり、スタッフルームに係る仮想空間８０を平面視で示す概念図である。図２Ｄに示す例では、スタッフユーザ用の仮想空間８０は、カンファレンスルームに対応する空間部を形成する位置ＳＰ２００と、バックヤードに対応する空間部を形成する位置ＳＰ２０１と、ロッカールームに対応する空間部を形成する位置ＳＰ２０２とを含む。なお、各空間部は、壁８６に対応する第２オブジェクトｍ３により仕切られ、ドア８５に対応する第２オブジェクトｍ３を開閉することで、入室や退室が可能であってよい。

カンファレンスルームに対応する空間部には、机８１（第２オブジェクトｍ３）や椅子８２（第２オブジェクトｍ３）が配置され、バックヤードに対応する空間部には、商品８３（ｍ３）が保管され、ロッカールームに対応する空間部には、ロッカー８４（第２オブジェクトｍ３）が配置されている。ロッカー８４には、後述する制服（第２オブジェクトｍ３）が保管されてよく、スタッフユーザになることができるユーザは、ロッカールームで自身のアバタに制服を着用させることで、スタッフユーザへと変化できる。なお、スタッフユーザ用の仮想空間８０の間取り等は多様でありえ、スタッフユーザの数等に応じて適宜設定されてよい。

このようなスタッフユーザ用の仮想空間８０は、図２Ａから図２Ｃに示した仮想空間に隣接して配置されてもよい。この場合、例えば、図２Ａに示した仮想空間内で各種の補助を行うスタッフユーザは、図２Ａに示した仮想空間に隣接して配置される仮想空間８０を利用できる。

ところで、仮想空間で実現できることが多様化したり、仮想空間内の構造（複数のコンテンツの提供を受ける各位置のレイアウト等）が複雑化したりすると、仮想空間の魅力を高めることができる反面、ルールが複雑化しやすくなる。この場合、ユーザは、かかるルールに慣れるまで苦労したり、あるいは、うまくいかないことがあると、解決できずに嫌になってしまったりする可能性が高くなりやすい。

この点、ルール等に関するチュートリアルを仮想空間内に貼り付けることで、ある程度、ユーザによる仮想空間内での円滑な活動が可能となることが期待できるが、仮想空間で実現できること等の多様化に伴い、チュートリアルの数が増加すると、却って利便性を損なうおそれもある。

これに対して、本実施形態では、仮想現実生成システム１は、一般ユーザに対して、スタッフアバタｍ２を介して各種補助を行う補助機能（以下、「ユーザ補助機能」とも称する）を有する。これにより、比較的複雑な仮想空間においても、利便性の高い態様でユーザの円滑な活動を補助できる。このようなユーザ補助機能は、仮想現実において仮想空間内でのスタッフアバタｍ２（スタッフユーザ）の各種の活動に係る対価を発生させる仕組みがあると、更に有用となる。

そこで、本実施形態では、仮想現実生成システム１は、以下で詳説するように、更に、仮想現実において仮想空間内でのスタッフアバタｍ２（スタッフユーザ）の各種の活動であって、ユーザ補助機能に係る各種の活動を適切に評価できる機能（以下、「スタッフ管理機能」とも称する）を有する。かかるスタッフ管理機能を有することで、仮想現実において仮想空間内でのスタッフアバタｍ２（スタッフユーザ）の各種の活動に係る対価を適切に発生させることができる。

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

（ユーザ補助機能及びスタッフ管理機能の詳細）
図４は、ユーザ補助機能に関連したサーバ装置１０の機能ブロック図の一例である。図５は、ユーザ補助機能に関連した端末装置２０（譲受側の端末装置２０）の機能ブロック図の一例である。図６は、ユーザデータベース１４０内のデータの説明図である。図７は、アバタデータベース１４２内のデータの説明図である。図８は、コンテンツ情報記憶部１４４内のデータの説明図である。図９は、空間状態記憶部１４６内のデータの説明図である。なお、図６から図９において、“＊＊＊”は、何らかの情報が格納されている状態を表し、“－”は、情報が格納されていない状態を表し、“・・・”は同様の繰り返しを表す。

サーバ装置１０は、図４に示すように、ユーザデータベース１４０と、アバタデータベース１４２と、コンテンツ情報記憶部１４４と、空間状態記憶部１４６と、空間描画処理部１５０と、ユーザアバタ処理部１５２と、スタッフアバタ処理部１５４と、位置／向き情報特定部１５６と、補助対象検出部１５７と、描画処理部１５８と、コンテンツ処理部１５９と、対話処理部１６０と、活動制限部１６２と、条件処理部１６４と、抽出処理部１６６と、役割割当部１６７と、空間情報生成部１６８と、パラメータ更新部１７０と、スタッフ管理部１８０と、を含む。なお、以下で説明するサーバ装置１０の機能の一部又は全部は、適宜、端末装置２０により実現されてもよい。また、ユーザデータベース１４０から空間状態記憶部１４６の区分けや、空間描画処理部１５０からパラメータ更新部１７０の区分けは、説明の都合上であり、一部の機能部が、他の機能部の機能を実現してもよい。例えば、空間描画処理部１５０、ユーザアバタ処理部１５２、描画処理部１５８、位置／向き情報特定部１５６、コンテンツ処理部１５９、対話処理部１６０、及び空間情報生成部１６８の各機能は、端末装置２０により実現されてもよい。また、例えば、ユーザデータベース１４０内のデータの一部又は全部は、アバタデータベース１４２内のデータに統合されてもよいし、別のデータベースに格納されてもよい。

なお、ユーザデータベース１４０から空間状態記憶部１４６は、図１に示したサーバ記憶部１２により実現でき、空間描画処理部１５０からパラメータ更新部１７０は、図１に示したサーバ制御部１３により実現できる。また、空間描画処理部１５０からパラメータ更新部１７０のうちの一部（端末装置２０との通信を行う機能部）は、図１に示したサーバ制御部１３とともにサーバ通信部１１により実現できる。

ユーザデータベース１４０には、ユーザ情報が格納される。図６に示す例では、ユーザ情報は、一般ユーザに係るユーザ情報６００と、スタッフユーザに係るスタッフ情報６０２とを含む。

ユーザ情報６００は、各ユーザＩＤに、ユーザ名、認証情報、ユーザアバタＩＤ、位置／向き情報、スタッフ可否情報、購買アイテム情報、購買関連情報等が対応付けられる。ユーザ名は、一般ユーザが自身で登録した名前であり、任意である。認証情報は、一般ユーザが正当な一般ユーザであることを示すための情報であり、例えばパスワードや、メールアドレス、生年月日、合言葉、生体情報等を含んでよい。ユーザアバタＩＤは、ユーザアバタを特定するためのＩＤである。位置／向き情報は、ユーザアバタｍ１の位置情報と向き情報とを含む。向き情報は、ユーザアバタｍ１の顔の向きを表す情報であってよい。なお、位置／向き情報等は、一般ユーザからの操作入力に応じて、動的に変化しうる情報である。位置／向き情報に加えて、ユーザアバタｍ１の手足等の動きを表す情報や、顔の表情（例えば、口の動き）、顔や頭部の向きや視線方向（例えば、眼球の向き）、レーザーポインターのような空間内の向きや座標を示すオブジェクト等を表す情報を含んでもよい。購買アイテム情報は、仮想空間内で販売される商品やサービスのうちの、一般ユーザが購買した商品やサービスを示す情報であってよい。

スタッフ可否情報は、対応する一般ユーザがスタッフユーザになることができるか否かを表す情報である。スタッフ可否情報は、スタッフユーザになることができる一般ユーザに対しては、スタッフユーザであるときのスタッフＩＤを表してもよい。

購買アイテム情報は、仮想空間内で販売される商品やサービスのうちの、一般ユーザが購買した商品やサービスを示す情報（すなわち、商品又はサービスに関する過去の利用又は提供履歴）であってよい。利用又は提供履歴は、利用又は提供された日時や場所を含んでよい。購買関連情報は、仮想空間内で販売される商品やサービスのうちの、その説明や宣伝、勧誘等を受けた商品やサービスを示す情報（すなわち、商品又はサービスに関する過去の案内履歴）であってよい。購買アイテム情報及び／又は購買関連情報は、特定の一の仮想空間に関する情報であってもよいし、複数の仮想空間に関する情報であってもよい。

なお、仮想空間内で販売される商品は、仮想空間内で利用又は提供が可能な商品であってよく、仮想空間内で提供されるコンテンツに応じて適合されてもよい。例えば、仮想空間内で提供されるコンテンツがコンサートである場合、仮想空間内で販売される商品は、双眼鏡であってもよい。また、仮想空間内で販売されるサービスは、仮想空間内で利用又は提供が可能なサービスであってよく、仮想空間内でのコンテンツの提供を含んでよい。また、仮想空間内で販売されるサービスは、仮想空間内で提供されるコンテンツに応じて適合されてもよい。例えば、仮想空間内で提供されるコンテンツがコンサートである場合、仮想空間内で販売されるサービスは、アーティストのアバタとの交流（握手や写真撮影等）であってもよい。

スタッフ情報６０２は、各スタッフＩＤに、スタッフ名、認証情報、スタッフアバタＩＤ、位置／向き情報、スタッフポイント等が対応付けられる。スタッフ名は、スタッフユーザが自身で登録した名前であり、任意である。認証情報は、スタッフユーザが正当なスタッフユーザであることを示すための情報であり、例えばパスワードや、メールアドレス、生年月日、合言葉、生体情報等を含んでよい。スタッフアバタＩＤは、スタッフアバタを特定するためのＩＤである。位置／向き情報は、スタッフアバタｍ２の位置情報と向き情報とを含む。向き情報は、スタッフアバタｍ２の顔の向きを表す情報であってよい。なお、位置／向き情報等は、スタッフユーザからの操作入力に応じて、動的に変化しうる情報である。位置／向き情報に加えて、スタッフアバタｍ２の手足等の動きを表す情報や、顔の表情（例えば、口の動き）、顔や頭部の向きや視線方向（例えば、眼球の向き）、レーザーポインターのような空間内の向きや座標を示すオブジェクト等を表す情報を含んでもよい。

スタッフポイントは、仮想現実におけるスタッフアバタの役割（スタッフとしての仕事）が果たされるごとに増加するパラメータ（所定役割を果たしている量に関連するパラメータの一例）であってよい。すなわち、スタッフポイントは、仮想現実におけるスタッフユーザの働き度合いを表すパラメータであってよい。例えば、一のスタッフユーザに係るスタッフポイントは、当該一のスタッフユーザが、対応するスタッフアバタｍ２を介して、仮想現実において一般ユーザを補助するごとに増加されてよい。あるいは、一のスタッフユーザに係るスタッフポイントは、当該一のスタッフユーザが、対応するスタッフアバタｍ２を介して、仮想現実において一般ユーザを補助可能な状態（すなわち稼働状態）となっている時間（労働時間）に応じて増加されてもよい。

スタッフ情報６０２は、好ましくは、スタッフユーザに付与される権限情報を更に含む。権限情報は、仮想空間内で活動するユーザアバタｍ１を支援（補助）するスタッフアバタｍ２に付与される役割に関連した権限を表す。権限は、複数種類あってよく、図６に示す例では、権限は、通常権限と、操作権限、統括権限の３種類である。なお、変形例では、権限は、１種類であってよく、この場合、権限情報は不要であってよい。

通常権限は、通常のスタッフユーザに付与される権限であり、例えば、仮想空間内で活動するユーザアバタｍ１を支援するための各種補助を行うことができる権限であってよい。各種補助は、後述する補助情報の提供により実現されるが、他の形態（例えば実演等）で実現されてもよい。各種補助は、一般ユーザに対する各種の案内、仮想空間内で利用又は提供が可能な商品又はサービスの案内又は販売、一般ユーザからのクレーム対応、及び、一般ユーザに対する各種の注意又は助言のうちの、少なくともいずれか１つを含む。商品又はサービスの案内は、商品又はサービスの説明や宣伝、勧誘等を含んでよい。なお、通常権限は、各種補助のうちの、所定の一部だけが行うことができる権限であってよい。この場合、各種補助のうちの、他の部分は、後述する操作権限や統括権限を有するスタッフユーザが行うことができる。

操作権限は、例えば、通常のスタッフユーザよりも経験を積んだシニアスタッフユーザや、特定の教育プログラム（研修プログラム）を受けた専用のスタッフユーザ等に付与される権限であり、例えば、仮想空間内で提供されるコンテンツに関連した各種操作を行うことができる権限であってよい。例えば、仮想空間内で提供されるコンテンツにおいて、スクリプト等を利用して各種演出（例えば適切なタイミングでの所定の第２オブジェクトｍ３の出現や、音響的な演出等）を実現する場合、操作権限は、当該演出用の各種操作を行うことができる権限であってよい。あるいは、仮想空間内で商品やサービスの販売が実行される場合、操作権限は、商品やサービスの販売に係るレジ（第２オブジェクトｍ３）の各種操作を行うことができる権限や、商品やサービスの提供数や在庫等を管理する権限を含んでよい。この場合、操作権限は、図２Ｄに示した仮想空間８０において、バックヤードに対応する空間部（位置ＳＰ２０１）に入ることができる権限を含んでよい。なお、操作権限を有するスタッフユーザは、通常権限も併せて有してよい。

統括権限は、例えば、シニアスタッフユーザよりも上級の統括スタッフユーザに付与される権限であり、例えば、上述した通常権限や操作権限が付与されたすべてのスタッフユーザの管理（例えば、権限の変更等）など、仮想空間内でのスタッフユーザを取りまとめる権限であってよい。統括権限を有するスタッフユーザは、例えば、いわゆるゲームマスターと呼ばれるユーザを含んでよい。なお、統括権限は、仮想空間における各種第２オブジェクトｍ３の配置権限や、提供するコンテンツの選択権限、一般ユーザからのクレーム対応が可能な権限等を含んでもよい。なお、統括権限を有するスタッフユーザは、他の権限（通常権限や操作権限）も併せて有してよい。

図６に示す例では、“○”が付されたスタッフユーザには、当該権限が付与されていることを示す。この場合、スタッフＩＤ“ＳＵ０１”に係るスタッフユーザには、通常権限のみが付与されており、スタッフＩＤ“ＳＵ０２”に係るスタッフユーザには、通常権限と操作権限が付与されている。

アバタデータベース１４２には、ユーザアバタｍ１及びスタッフアバタｍ２に関するアバタ情報が格納される。図７に示す例では、アバタ情報は、一般ユーザに係るユーザアバタ情報７００と、スタッフユーザに係るスタッフアバタ情報７０２とを含む。

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

スタッフアバタ情報７０２は、各スタッフアバタＩＤに、顔、髪型、服装等が対応付けられる。顔、髪型、服装等の容姿に係る情報は、スタッフアバタを特徴付けるパラメータであり、スタッフユーザにより設定される。顔、髪型等の容姿に係る情報は、ユーザアバタ情報７００の場合と同様、各パーツのＩＤの組み合わせで管理されてよく、アバタ描画用情報として機能できる。

このようにして本実施形態では、基本的には、一の一般ユーザに、一のユーザＩＤが対応付けられ、一のユーザＩＤに、ユーザアバタＩＤが対応付けられる。従って、一の一般ユーザに、ある情報が対応付けられる状態と、当該一のユーザＩＤに、当該情報が対応付けられる状態と、当該一のユーザＩＤに対応付けられたユーザアバタＩＤに、当該情報が対応付けられる状態とは、互いに同義である。これは、スタッフユーザに関しても同様である。従って、例えば、図６で示した例と異なり、ユーザアバタｍ１の位置／向き情報は、当該ユーザアバタｍ１に係るユーザアバタＩＤに対応付けて記憶されてもよいし、同様に、スタッフアバタｍ２の位置／向き情報は、当該スタッフアバタｍ２に係るスタッフアバタＩＤに対応付けて記憶されてもよい。以下では、説明上、一般ユーザと、当該一般ユーザに対応付けられるユーザアバタｍ１とは、互いに読み替え可能な関係であるとする。

コンテンツ情報記憶部１４４には、仮想空間内で提供可能な特定のコンテンツに関する各種の情報が記憶される。例えば、特定のコンテンツごとに、その提供位置であるコンテンツ提供位置や、内容等が記憶される。

図８に示す例では、各コンテンツＩＤに、コンテンツ提供位置（図８では、「提供位置」と表記）や、コンテンツ内容（図８では、「内容」と表記）等が対応付けられている。

コンテンツ提供位置は、仮想空間内の位置であって、コンテンツ処理部１５９を介して一般ユーザがコンテンツ提供を受けることができる位置を含む。すなわち、コンテンツ提供位置は、特定のコンテンツの提供を受けることができる位置を含む。コンテンツ提供位置は、一点の座標値で定義されてもよいが、典型的には、一纏めの領域又は空間部分を形成する複数の座標値で定義されてよい。また、コンテンツ提供位置は、平面上の位置であってもよいし、空間上の位置（すなわち高さ方向を含む３次元の座標系で表される位置）であってもよい。なお、一のコンテンツ提供位置に対応付けられる特定のコンテンツの単位を、１つの特定のコンテンツ（特定のコンテンツの一単位）とする。従って、例えば、ある一のコンテンツ提供位置で、２種類の動画の視聴が可能である場合でも、当該２種類の動画全体が１つの特定のコンテンツである。

コンテンツ提供位置は、典型的には、対応する特定のコンテンツの属性に応じて設定されてよい。例えば、図２Ａに示す例では、コンテンツ提供位置は、各ゲートを通って入ることができる仮想空間内の位置である。図２Ｂに示す例では、コンテンツ提供位置は、各ゲートを通って入ることができる仮想空間内の第１位置ＳＰ１１から第８位置ＳＰ１８のそれぞれである。同様に、図２Ｃに示す例では、コンテンツ提供位置は、各ゲートを通って入ることができる仮想空間内の位置ＳＰ２１、ＳＰ２２、ＳＰ２３のそれぞれである。コンテンツ提供位置は、特定のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）で規定されてもよい。この場合、一般ユーザ等は、当該特定のＵＲＬにアクセスすることで、ユーザアバタｍ１等をコンテンツ提供位置に移動させることができる。この場合、一般ユーザは、特定のＵＲＬにアクセスして、端末装置２０のブラウザ上で特定のコンテンツの提供を受けることができる。

コンテンツ内容は、コンテンツ名や、概要、作成者等の情報を含んでよい。

コンテンツ情報記憶部１４４には、更に、各コンテンツ提供位置でそれぞれの特定のコンテンツの提供を受けるために満たされるべき条件（以下、「コンテンツ提供条件」とも称する）を表す情報が記憶されてよい。コンテンツ提供条件は、コンテンツＩＤごとに設定されてよい。コンテンツ提供条件は、図２Ｂ及び図２Ｃに示すように、一連のコンテンツ提供位置を介して、全体として意味を持つ複数の特定のコンテンツの提供が順次受けられるような仮想空間において、設定されるのが好適である。コンテンツ提供条件は、任意であり、提供される特定のコンテンツの特性等に応じて運営側により適宜設定されてよい。また、コンテンツ提供条件は、上述した統括権限を有するスタッフユーザにより設定／変更可能とされてもよい。

例えば、ある一のコンテンツ提供位置に係るコンテンツ提供条件は、他の特定の１つ以上のコンテンツ提供位置で特定のコンテンツの提供を受けていることを含んでよい。この場合、一連の特定のコンテンツの提供順序を規制（コントロール）できるので、一連の特定のコンテンツの提供を受けることによる一般ユーザの体験効果（例えば教育の習得効果）を効率的に高めることができる。また、ある一のコンテンツ提供位置に係るコンテンツ提供条件は、他の特定の１つ以上のコンテンツ提供位置で特定のコンテンツの提供を受けており、かつ、当該他の特定の１つ以上のコンテンツ提供位置で設定された課題をクリアしたことであってもよい。この場合、他の特定の１つ以上のコンテンツ提供位置で設定される課題は、当該他の特定の１つ以上のコンテンツ提供位置で提供される特定のコンテンツに関連する課題であってよい。例えば、学習用のコンテンツである場合、効果確認用の課題（例えば簡易なテストやクイズに対する正答率）が設定されてもよい。

コンテンツ提供条件は、２種類以上で設定されてもよく、例えば、図８に示す例では、コンテンツＩＤ“ＣＴ０１”には、通常条件のみが設定されており、コンテンツＩＤ“ＣＴ０２”には、通常条件と緩和条件とが設定されている。この場合、コンテンツＩＤ“ＣＴ０２”に対応する特定のコンテンツに対しては、通常条件と緩和条件のうちのいずれかが選択的に適用される。緩和条件は、通常条件よりも満たされやすい条件である。例えば、通常条件では、課題が所定時間ΔＴ１以内にクリアされる必要があるのに対して、緩和条件では、課題が所定時間ΔＴ１よりも有意に長い所定時間ΔＴ２以内にクリアされればよい、といった具合である。あるいは、緩和条件では、クリアすべき課題の難易度が通常条件のときよりも低い、といった具合である。なお、２種類以上のコンテンツ提供条件が割り当てられるコンテンツＩＤは、上述した統括権限を有するスタッフユーザにより設定／変更可能とされてもよい。

以下、本実施形態では、一例として、一の仮想空間において、Ｎを３以上の整数としたとき、Ｎ個のコンテンツ提供位置（Ｎ個の特定のコンテンツ）が設定されているものとする。そして、Ｎ個のコンテンツ提供位置で提供可能なＮ個の特定のコンテンツは、１番目からＮ番目の順に提供可能なコンテンツであるとする。従って、一般ユーザは、Ｎ－１番目の特定のコンテンツについては、Ｎ－２番目までの特定のコンテンツの提供をすべて受けてからでないと、提供を受けることができないものとする。

空間状態記憶部１４６には、仮想空間における空間状態情報が格納される。空間状態情報は、仮想空間内のユーザアバタｍ１のそれぞれの活動に係る状態や、スタッフアバタｍ２のそれぞれの活動（役割に係る活動）に係る状態等を表す。

仮想空間における空間状態情報は、コンテンツ提供位置に係る空間部分内の状態に関する空間状態情報を含み、更に、所定支援位置に係る空間部分内の状態に関する空間状態情報を含んでもよい。

コンテンツ提供位置は、上述したとおりである。所定支援位置は、仮想空間におけるコンテンツ提供位置以外の位置であって、スタッフユーザによる一般ユーザの補助が必要となりやすい位置である。例えば、所定支援位置は、コンテンツ提供位置に係る入口付近等を含んでよい。例えば、図２Ａから図２Ｃに示す例では、所定支援位置は、位置ＳＰ１、ＳＰ２や、位置ＳＰ２０（図２Ｃ参照）等である。

以下、特に言及しない限り、空間状態情報とは、コンテンツ提供位置に係る空間部分内の状態に関する空間状態情報を意味する。また、以下では、仮想空間における各コンテンツ提供位置に係る空間部分を、各部屋として定義されており、一般ユーザに向けてＵＲＬで記述可能とする。同一ルームにアクセスするユーザを同じルームに紐づけられたセッションとして管理する。ルームに係る空間部分にアバタが入ることを入室と表現する場合がある。一のルームに同時にアクセスできるユーザ数には処理能力の観点から限界があるが、同一の設計を持ったルームを複製し、負荷を分散させる処理があってもよい。なお、各部屋がつながった全体は、ワールドとも称される。

図９に示す例では、空間状態情報は、コンテンツ提供位置（部屋）ごとと、仮想空間全体とで管理されている。具体的には、空間状態情報は、一般ユーザに係るユーザ状態情報９００と、スタッフユーザに係るスタッフ状態情報９０２と、仮想空間に係る仮想空間情報９０４とを含む。ユーザ状態情報９００及びスタッフ状態情報９０２については、ある一のコンテンツ提供位置に係る空間状態情報が示されているが、所定支援位置に係る空間状態情報についても、特に言及しない限り、同様であってよい。

ユーザ状態情報９００は、コンテンツ提供位置（部屋）ごとに設定され、図９に示すユーザ状態情報９００は、一のコンテンツ提供位置に関する。例えば、図２Ｂに示す例では、スタッフ状態情報９０２は、第１位置ＳＰ１１から第８位置ＳＰ１８のそれぞれごとに設定される。同様に、図２Ｃに示す例では、位置ＳＰ２１、ＳＰ２２、ＳＰ２３のそれぞれごとに設定される。

ユーザ状態情報９００は、入室ユーザに、ユーザ名、位置／向き情報、部屋滞在時間、コンテンツ提供条件の緩和の有無、次室移動条件の成否情報等が対応付けられる。入室ユーザは、コンテンツ提供位置に位置しているユーザアバタｍ１に係る一般ユーザであり、入室ユーザの情報は、当該一般ユーザを特定できる任意の情報（ユーザＩＤや、ユーザアバタＩＤ等）であってよい。ユーザ名は、上述したユーザ情報に基づくユーザ名である。なお、ユーザ名は、入室ユーザに紐付けられる情報であるので、ユーザ状態情報９００からは省略されてもよい。位置／向き情報は、ユーザアバタｍ１の位置／向き情報である。なお、入室ユーザは、コンテンツ提供位置に位置しているユーザアバタｍ１に係る一般ユーザであることから、ユーザアバタｍ１の位置情報は、コンテンツ提供位置（複数の座標値で定義される場合、その複数の座標値のうちの１つ）に対応する。換言すると、一のユーザアバタｍ１の位置情報がコンテンツ提供位置に対応しない場合は、当該一のユーザアバタｍ１に係る一般ユーザは、入室ユーザから除外される。ユーザアバタｍ１の位置情報は、特に、一のコンテンツ提供位置が複数の座標値で定義される場合（すなわち比較的広い領域又は空間部分全体がコンテンツ提供位置である場合）に有用となる。この場合、位置情報は、比較的広い空間部分のどこに位置するかを表すことができる。

部屋滞在時間は、コンテンツ提供位置に位置している滞在時間に対応する。部屋滞在時間は、次室移動条件の判定等に利用されてもよい。

コンテンツ提供条件の緩和の有無は、図８を参照して上述したコンテンツ情報記憶部１４４内のコンテンツ提供条件の、通常条件と緩和条件のうちの、いずれが適用されているかを示す情報である。通常条件と緩和条件のうちの、いずれが適用されるかは、所定のルールに従って自動的に設定されてもよいし、後述する条件処理部１６４により緩和される場合があってもよい。例えば、一の一般ユーザの年齢が比較的低い場合（例えば小学生等である場合）や、一の一般ユーザの部屋滞在時間が比較的長い場合、当該一の一般ユーザに対しては緩和条件が初期的に自動的に設定されてもよい。また、特定の一般ユーザに対しては、緩和条件として、部屋滞在時間に関する条件が外されてもよい。例えば、一般ユーザごとに設定されうるイベントタイマーが、特定の一般ユーザに対しては設定されない又は無視されてもよい。

次室移動条件の成否情報は、入室ユーザが、次のコンテンツ提供位置へと移動する際に満たされるべき条件（次室移動条件）を満たしているかどうかを表す。次室移動条件は、上述したコンテンツ提供条件に基づいて任意に設定されてよい。本実施形態では、次室移動条件は、次室に係るコンテンツ提供位置に設定されるコンテンツ提供条件と同じである。従って、一の一般ユーザ（入室ユーザ）については、次室に係るコンテンツ提供位置に設定されるコンテンツ提供条件が満たされると、次室移動条件が満たされることになる。なお、所定支援位置に関する次室移動条件の成否情報についても、次のコンテンツ提供位置（例えば１つ目のコンテンツ提供位置）へと移動する際に満たされるべき条件（次室移動条件）を満たしているか否かを表してよい。

なお、次室移動条件は、一般ユーザ（ユーザアバタｍ１）に対して適用され、スタッフユーザ（スタッフアバタｍ２）に対しては適用されない。従って、スタッフアバタｍ２は、原則的に、自由に各部屋を移動できる。

スタッフ状態情報９０２は、仮想空間ごとに設定されてもよいし、一纏まりのコンテンツ提供位置に係る各部屋全体（以下、「コンテンツ提供用の仮想空間部」とも称する）ごとに設定されてもよい。例えば、図２Ｂに示す例では、スタッフ状態情報９０２は、第１位置ＳＰ１１から第８位置ＳＰ１８のそれぞれに係る各空間部分全体（コンテンツ提供用の仮想空間部）に関する。同様に、図２Ｃに示す例では、スタッフ状態情報９０２は、位置ＳＰ２１、ＳＰ２２、ＳＰ２３のそれぞれに係る各空間部分全体（コンテンツ提供用の仮想空間部）に関する。

スタッフ状態情報９０２は、稼働スタッフに、スタッフ名や位置／向き情報が対応付けられる。稼働スタッフは、コンテンツ提供位置に位置しているスタッフアバタｍ２に係るスタッフユーザであり、稼働スタッフの情報は、当該スタッフユーザを特定できる任意の情報（スタッフＩＤや、スタッフアバタＩＤ等）であってよい。

仮想空間情報９０４は、スタッフ状態情報９０２と同様、仮想空間ごとに設定されてもよいし、コンテンツ提供用の仮想空間部ごとに設定されてもよい。具体的には、複数の独立したコンテンツ提供用の仮想空間部が用意される場合は、仮想空間情報９０４は、かかる独立したコンテンツ提供用の仮想空間部ごとに設定されてもよい。また、仮想現実生成システム１が図２Ｂに示す仮想空間と図２Ｃに示す仮想空間を同時に扱う場合、図２Ｂに示す仮想空間用の仮想空間情報９０４と、図２Ｃに示す仮想空間用の仮想空間情報９０４とが、それぞれ設定されてもよい。

仮想空間情報９０４は、空間内ユーザに、ユーザ名、位置情報、空間滞在時間、過去の利用履歴等が対応付けられる。なお、ユーザ名は、上述したとおりであり、省略されてもよい。

空間内ユーザは、コンテンツ提供用の仮想空間部内の各コンテンツ提供位置のうちのいずれかに位置しているユーザアバタｍ１に係る一般ユーザであり、ユーザ状態情報９００の入室ユーザの情報に基づいて生成されてよい。

位置情報は、コンテンツ提供用の仮想空間部内のどのコンテンツ提供位置（部屋）に位置するかを示す情報であり、ユーザ状態情報９００の位置／向き情報よりも粗い情報であってもよい。

空間滞在時間は、コンテンツ提供用の仮想空間部内に位置している間に積算される時間であり、ユーザ状態情報９００の部屋滞在時間に基づいて生成されてもよい。空間滞在時間は、ユーザ状態情報９００の部屋滞在時間と同様、次室移動条件の判定等に利用されてもよい。また、空間滞在時間は、ユーザ状態情報９００の部屋滞在時間と同様、仮想空間内での活動結果を表す修了証等の作成に利用されてもよい。

過去の利用履歴は、コンテンツ提供用の仮想空間部に関する過去の利用履歴である。過去の利用履歴は、日時や、コンテンツ提供用の仮想空間部内のどのコンテンツ提供位置まで進んだかといった進捗状態を示す情報を含んでよい。過去の利用履歴は、後述するように、一般ユーザに、スタッフユーザに係る役割を付与する際に、利用されてもよい。あるいは、過去の利用履歴は、中断後等に再入場しうる一般ユーザに対して前回の途中からの続きから開始できるようにするために、利用されてもよい。

空間描画処理部１５０は、仮想空間の描画情報に基づいて、仮想空間を描画する。なお、仮想空間の描画情報は、あらかじめ生成されるが、事後的又は動的に更新等されてもよい。仮想空間内の各位置は、空間座標系で規定されてよい。なお、仮想空間の描画方法は、任意であるが、例えばフィールドオブジェクトや背景オブジェクトを、適切な平面や曲面等にマッピングすることにより実現されてもよい。

ユーザアバタ処理部１５２は、ユーザアバタｍ１に係る各種処理を実行する。ユーザアバタ処理部１５２は、操作入力取得部１５２１と、ユーザ動作処理部１５２２とを含む。

操作入力取得部１５２１は、一般ユーザによる操作入力情報を取得する。なお、一般ユーザによる操作入力情報は、上述した端末装置２０の入力部２４を介して生成される。

ユーザ動作処理部１５２２は、操作入力取得部１５２１により取得された操作入力情報に基づいて、仮想空間におけるユーザアバタｍ１の位置及び向きを決定する。ユーザ動作処理部１５２２により決定された位置及び向きを表すユーザアバタｍ１の位置／向き情報は、例えばユーザＩＤに対応付けて記憶されてよい（図６のユーザ情報６００参照）。また、ユーザ動作処理部１５２２は、操作入力情報に基づいて、ユーザアバタｍ１の手や顔などの各種の動きを決定してもよい。この場合、かかる動きの情報も、ユーザアバタｍ１の位置／向き情報とともに記憶されてよい。

本実施形態では、ユーザ動作処理部１５２２は、仮想空間内においてユーザアバタｍ１のそれぞれを、後述する活動制限部１６２による制限下で移動させる。すなわち、ユーザ動作処理部１５２２は、後述する活動制限部１６２による制限下で、ユーザアバタｍ１の位置を決定する。従って、例えば、活動制限部１６２により一のユーザアバタｍ１の一のコンテンツ提供位置への移動が制限されている場合、ユーザ動作処理部１５２２は、当該一のユーザアバタｍ１の、一のコンテンツ提供位置への移動が実現されない態様で、当該一のユーザアバタｍ１の位置を決定する。

また、ユーザ動作処理部１５２２は、仮想空間内においてユーザアバタｍ１のそれぞれを、現実空間における物理法則に対応する所定法則に従って、移動させる。例えば、現実空間における壁に対応する第２オブジェクトｍ３があるとき、ユーザアバタｍ１は、壁を通過できなくてもよい。また、ユーザアバタｍ１は、重力に対応する引力をフィールドオブジェクトから受け、特別な器具（例えば揚力を発生する器具）を装着しない限り、空中に長時間浮遊できなくてもよい。

ここで、上述したように、ユーザ動作処理部１５２２の機能は、サーバ装置１０に代えて、端末装置２０によって実現することも可能である。例えば、仮想空間内の移動は加速度と衝突等が表現される態様で実現されてもよい。この場合、各ユーザは、位置をポイント（指示）することで、ユーザアバタｍ１をジャンプさせて移動させることもできるが、壁面や移動に関する制限に関する判定は、端末制御部２５（ユーザ動作処理部１５２２）により実現されてよい。この場合、端末制御部２５（ユーザ動作処理部１５２２）は、事前に提供された制限情報に基づいて判定処理を行う。なお、この場合、位置情報はＷｅｂＳｏｃｋｅｔ等に基づくリアルタイム通信でサーバ装置１０を経由して必要な他ユーザに共有されてよい。

スタッフアバタ処理部１５４は、スタッフアバタｍ２に係る各種処理を実行する。スタッフアバタ処理部１５４は、操作入力取得部１５４１と、スタッフ動作処理部１５４２と、補助情報提供部１５４４と、を含む。

操作入力取得部１５４１は、スタッフユーザによる操作入力情報を取得する。なお、スタッフユーザによる操作入力情報は、上述した端末装置２０の入力部２４を介して生成される。

スタッフ動作処理部１５４２は、操作入力取得部１５４１により取得された操作入力情報に基づいて、仮想空間におけるスタッフアバタｍ２の位置及び向きを決定する。スタッフ動作処理部１５４２により決定された位置及び向きを表すスタッフアバタｍ２の位置／向き情報は、例えばスタッフＩＤに対応付けて記憶されてよい（図６のスタッフ情報６０２参照）。また、スタッフ動作処理部１５４２は、操作入力情報に基づいて、スタッフアバタｍ２の手や顔などの各種の動きを決定してもよい。この場合、かかる動きの情報も、スタッフアバタｍ２の位置／向き情報とともに記憶されてよい。

本実施形態では、スタッフ動作処理部１５４２は、上述したユーザ動作処理部１５２２とは異なり、仮想空間内においてスタッフアバタｍ２のそれぞれを、現実空間における物理法則に対応する所定法則に従うことなく、移動させる。例えば、現実空間における壁に対応する第２オブジェクトｍ３があるときでも、スタッフアバタｍ２は、壁を通過できてもよい。また、スタッフアバタｍ２は、特別な器具（例えば揚力を発生する器具）を装着しなくても、空中に長時間浮遊できてもよい。あるいは、スタッフアバタｍ２は、いわゆる瞬間移動（ワープ）や、巨大化等が可能であってもよい。

また、スタッフアバタｍ２は、ユーザアバタｍ１ではできない動き等を実現できてもよい。例えば、スタッフアバタｍ２は、ユーザアバタｍ１とは異なり、非常に重たい重量物（例えば銅像や建物）に対応する第２オブジェクトｍ３を移動できてもよい。あるいは、スタッフアバタｍ２は、ユーザアバタｍ１とは異なり、所定のアイテムを譲渡／変換することが可能であってもよい。あるいは、スタッフアバタｍ２は、ユーザアバタｍ１とは異なり、打ち合わせ等を行うための仮想空間内の特別な空間部分（例えば、図２Ｄの示すような各種のスタッフルームに対応する空間部分）に移動できてもよい。

また、スタッフ動作処理部１５４２は、スタッフユーザに付与される権限情報に基づいて、スタッフアバタｍ２の移動（動き）の自由度を可変してもよい。例えば、スタッフ動作処理部１５４２は、統括権限を有するスタッフユーザに係るスタッフアバタｍ２に対して、最も高い自由度を付与し、操作権限を有するスタッフユーザに係るスタッフアバタｍ２に対して、次に高い自由度を付与してもよい。

補助情報提供部１５４４は、スタッフユーザによる所定入力に応答して、一般ユーザに所定情報を提供する。所定情報は、一般ユーザにとって有用となりうる任意の情報であってよく、例えば、次室移動条件を満たすためのアドバイス／チップ（Ｔｉｐｓ）や、一般ユーザの不満や不安等を解消するための情報等を含んでよい。所定情報が多様である場合、スタッフユーザからの所定入力は、提供する所定情報の種類を特定する入力を含んでよい。所定情報は、例えば、一般ユーザの端末装置２０を介して任意の態様で出力されてもよい。例えば、所定情報は、端末装置２０を介して音声や映像等により出力されてもよい。なお、所定情報の提供が、一般ユーザとスタッフユーザとの間の対話により実現される場合は、所定情報の提供は、後述する第２対話処理部１６０２により実現される。

本実施形態では、所定情報は、一般ユーザに対して各種補助を実現できるような補助情報である。そして、補助情報提供部１５４４は、一般ユーザのそれぞれに対応付けられたユーザ状態情報９００（図９参照）に基づいて、スタッフアバタｍ２を介して、一般ユーザのうちの一部又はそれぞれに補助情報を提供する。

このように本実施形態では、スタッフユーザは、各種の所定入力を行うことで、補助情報提供部１５４４によりスタッフアバタｍ２を介して、一般ユーザに各種の補助情報を提供できる。

例えば、スタッフユーザは、次室移動条件を満たしていない一般ユーザに対して、次室移動条件を満たすためのアドバイス／チップを含む補助情報を提供する。例えば、スタッフユーザは、次のコンテンツ提供位置への入口を通れないユーザアバタｍ１に係る一般ユーザに対して、次室移動条件を説明してもよいし、次室移動条件を満たすようにアドバイスしてもよい。あるいは、課題をクリアしないと次のコンテンツ提供位置への入口を通れない場合は、スタッフユーザは、課題をクリアするためのヒント等を提供してもよい。

また、補助情報は、スタッフユーザの動きに基づく実技や見本等であってもよい。例えば、特定のコンテンツに係る課題が、特定の身体の動きを伴う場合、スタッフユーザは、当該特定の身体の動きを実技等で、スタッフアバタｍ２を介して、一般ユーザに示してもよい。あるいは、図２Ｃに示す例のように、所定の順序で特定のコンテンツの提供を受けることが有用な場合は、スタッフユーザは、当該所定の順序で進むようにアドバイスしてもよい。

本実施形態では、補助情報提供部１５４４は、スタッフユーザに付与される権限情報に基づいて、スタッフユーザによる補助情報を提供する能力を可変してもよい。例えば、補助情報提供部１５４４は、統括権限を有するスタッフユーザに対しては、すべての一般ユーザに対して補助情報を提供できる権限を付与し、操作権限を有するスタッフユーザに対しては、特定の空間部分に位置するユーザアバタｍ１の一般ユーザに対してだけ補助情報を提供できる権限を付与してもよい。また、補助情報提供部１５４４は、通常権限を有するスタッフユーザに対して、あらかじめ用意された定型的な補助情報のみを提供できる権限を付与してもよいし、統括権限や操作権限を有するスタッフユーザに係るスタッフアバタｍ２から補助情報が得られるように、ユーザアバタｍ１を所定の案内位置等へとナビゲートする補助情報のみを提供できる権限を付与してもよい。

位置／向き情報特定部１５６は、ユーザアバタｍ１の位置情報とスタッフアバタｍ２の位置情報とを特定する。なお、位置／向き情報特定部１５６は、上述したユーザ動作処理部１５２２及びスタッフ動作処理部１５４２からの情報に基づいて、ユーザアバタｍ１及びスタッフアバタｍ２のそれぞれの位置情報を特定してよい。

補助対象検出部１５７は、仮想空間内で活動しているユーザアバタｍ１のうちから、補助情報を必要としている可能性が高い一般ユーザに係るユーザアバタｍ１（以下、「補助対象のユーザアバタｍ１」とも称する）を検出する。本実施形態では、補助対象検出部１５７は、空間状態記憶部１４６内のデータに基づいて、補助対象のユーザアバタｍ１を検出してもよい。例えば、補助対象検出部１５７は、部屋滞在時間が比較的長いユーザアバタｍ１や、動きが少ないユーザアバタｍ１、迷いを示唆する動きをしているユーザアバタｍ１等に基づいて、補助対象のユーザアバタｍ１を検出してもよい。また、補助情報の必要なときに、例えば手をあげるといったユーザアバタｍ１からの合図があるときは、補助対象検出部１５７は、かかる合図に基づいて、補助対象のユーザアバタｍ１を検出してもよい。

なお、補助対象のユーザアバタｍ１は、人工知能を利用して、空間状態記憶部１４６内のデータを入力して出力（検出）することも可能である。人工知能の場合は、機械学習により得られる畳み込みニューラルネットワークを実装することで実現できる。機械学習では、例えば、空間状態記憶部１４６内のデータ（実績データ）を用いて、補助対象のユーザアバタｍ１の検出結果に係る誤差（すなわち、実際には補助情報を必要としていないユーザアバタｍ１が、補助対象のユーザアバタｍ１として検出されてしまう誤差）が最小になるような畳み込みニューラルネットワークの重み等が学習される。

補助対象検出部１５７は、補助対象のユーザアバタｍ１を検出すると、当該補助対象のユーザアバタｍ１が、所定の描画態様で描画されるように、描画処理部１５８（後述）に指示を出力してよい。

本実施形態では、補助対象検出部１５７は、補助対象のユーザアバタｍ１を検出した場合に、補助情報の提供の必要性（緊急性）や、必要とする補助情報の属性等の付加情報を生成してもよい。例えば、付加情報は、後述する第２対話処理部１６０２による対話を介した補助情報が必要であるか、あるいは、一方通行の補助情報の提供で足りるかを示す情報を含んでもよい。

また、補助対象検出部１５７は、一般ユーザからの直接的な補助要求（後述する補助要求部２５０からの補助要求）に応じて、補助要求を生成したユーザアバタｍ１を、補助対象のユーザアバタｍ１として検出してもよい。

描画処理部１５８（媒体描画処理部の一例）は、仮想空間内で移動可能な各仮想現実媒体（例えばユーザアバタｍ１やスタッフアバタｍ２）を描画する。具体的には、描画処理部１５８は、アバタ描画用情報（図７参照）と、各ユーザアバタｍ１の位置／向き情報やスタッフアバタｍ２の位置／向き情報等とに基づいて、各ユーザに係る端末装置２０で表示される画像を生成する。

本実施形態では、描画処理部１５８は、端末画像生成部１５８１と、ユーザ情報取得部１５８２とを含む。

端末画像生成部１５８１は、ユーザアバタｍ１ごとに、一のユーザアバタｍ１の位置／向き情報に基づいて、当該一のユーザアバタｍ１に対応付けられた一般ユーザに係る端末装置２０で表示される画像（以下、後述のスタッフユーザ用の端末用画像と区別する場合、「一般ユーザ用の端末用画像」とも称する）を生成する。具体的には、端末画像生成部１５８１は、一のユーザアバタｍ１の位置／向き情報に基づいて、当該位置／向き情報に対応した位置及び向きの仮想カメラから視た仮想空間の画像（仮想空間の一部を切り取る画像）を端末用画像として生成する。この場合、位置／向き情報に対応した位置及び向きに仮想カメラの位置及び向きを一致させると、仮想カメラの視野は、ユーザアバタｍ１の視野に実質的に一致する。ただし、この場合、仮想カメラからの視野には、当該ユーザアバタｍ１は映らない。従って、ユーザアバタｍ１が映る端末用画像を生成する場合は、仮想カメラの位置は、ユーザアバタｍ１の背後側に設定されてよい。あるいは、仮想カメラの位置は、対応する一般ユーザにより任意に調整可能であってもよい。なお、かかる端末用画像を生成する際、端末画像生成部１５８１は、奥行き感等を出すために、各種の処理（例えばフィールドオブジェクトを曲げる処理等）を実行してもよい。また、ユーザアバタｍ１が映る端末用画像を生成する場合は、描画処理の負荷を低減するために、ユーザアバタｍ１は、比較的簡易な態様（例えば二次元スプライトの形態）で描画されてもよい。

また、同様に、端末画像生成部１５８１は、スタッフアバタｍ２ごとに、一のスタッフアバタｍ２の位置／向き情報に基づいて、当該一のスタッフアバタｍ２に対応付けられたスタッフユーザに係る端末装置２０で表示される画像（以下、上述した一般ユーザ用の端末用画像と区別する場合、「スタッフユーザ用の端末用画像」とも称する）を生成する。

端末画像生成部１５８１は、仮想カメラからの視野内の他のユーザアバタｍ１やスタッフアバタｍ２が位置する場合は、当該他のユーザアバタｍ１やスタッフアバタｍ２を含む端末用画像を生成する。ただし、この場合、描画処理の負荷を低減するために、他のユーザアバタｍ１やスタッフアバタｍ２は、比較的簡易な態様（例えば二次元スプライトの形態）で描画されてもよい。

また、端末画像生成部１５８は、発話者の口の動きを再現したり、発話者の頭部等の大きさを強調表現することで、発話状態をわかりやすくする処理を実現してもよい。このような処理は、後述する対話処理部１６０と協動して実現されてもよい。

ここで、上述したように、端末画像生成部１５８１の機能は、サーバ装置１０に代えて、端末装置２０によって実現することも可能である。この場合、例えば、端末画像生成部１５８１は、サーバ装置１０のスタッフアバタ処理部１５４により生成された位置／向き情報と、描画対象のアバタを特定できる情報（例えばユーザアバタＩＤやスタッフアバタＩＤ）と、当該描画対象のアバタに係るアバタ描画用情報（図７参照）とをサーバ装置１０から受信し、受信した情報に基づいて、各アバタの画像を描画する。この場合、端末装置２０は、アバタの各パーツを描画するためのパーツ情報を端末記憶部２２内に格納しており、当該パーツ情報と、サーバ装置１０から取得する描画対象のアバタ描画用情報（各パーツのＩＤ）とに基づいて、各アバタの容姿を描画してもよい。

本実施形態では、端末画像生成部１５８１は、一般ユーザ用の端末用画像（第１属性のユーザ用の表示画像の一例）又はスタッフユーザ用の端末用画像（第２属性のユーザ用の表示画像の一例）におけるスタッフアバタｍ２を、ユーザアバタｍ１から識別可能な態様で、描画する。

具体的には、端末画像生成部１５８１は、仮想空間内に配置される複数のスタッフアバタｍ２に対して共通の可視特徴を対応付けて描画する。これにより、各ユーザは、共通の可視特徴に基づいて、スタッフユーザであるか否かを容易に識別できる。例えば、各ユーザは、一のアバタが共通の可視特徴に対応付けて描画されている場合は、当該一のアバタがスタッフアバタｍ２であると容易に認識できる。このように、共通の可視特徴は、このような識別機能を有する限り、任意であってもよい。ただし、共通の可視特徴は、好ましくは、高い識別能力を有するように、一目で目に付くような大きさを有する。

例えば、共通の可視特徴は、共通の服装（制服）や装着具（例えばスタッフ専用の腕章やバッチ、専用のセキュリティカード等）である。また、共通の可視特徴は、“スタッフ（Ｓｔａｆｆ）”といったテキストであって、スタッフアバタｍ２の近傍に描画されるテキストであってもよい。本実施形態では、一例として、共通の可視特徴は、制服であるとする。

共通の可視特徴は、好ましくは、スタッフユーザのそれぞれによる独自の変更が禁止される。すなわち、共通の可視特徴は、好ましくは、共通性が損なわれることがないように、スタッフユーザのそれぞれによる改変やアレンジが不能とされる。これにより、共通性が損なわれることに起因して共通の可視特徴に係る識別機能が毀損されてしまう可能性を、低減できる。ただし、共通の可視特徴は、特定のスタッフユーザ（例えば統括権限を有するスタッフユーザ）により改変やアレンジは可能であってよい。この場合、改変やアレンジ後の共通の可視特徴は、対応するすべてのスタッフユーザに適用されるので、共通性が損なわれることはない。

また、共通の可視特徴は、一のアイテムの一部であってもよい。例えば、共通の可視特徴に係るアイテムがジャケットであり、ジャケットのうちのリボンやボタンがアレンジ可能である場合、共通の可視特徴は、ジャケットのうちの、アレンジが可能なリボンやボタンを除く部分である。また、共通の可視特徴に係るアイテムが帽子付きの髪型であり、帽子付きの髪型のうちの髪型がアレンジ可能である場合（すなわち帽子はアレンジ禁止である場合）、共通の可視特徴は、帽子付きの髪型のうちの、髪型を除く部分（すなわち帽子の部分）である。このような、共通の可視特徴に係るアイテムのうちの、アレンジが可能な部位／禁止の部位は、あらかじめ規定されていてもよい。これにより、共通の可視特徴に係る識別機能を維持しつつ、各スタッフアバタｍ２の容姿に係る個性（アレンジ部分による個性）の発揮を期待できる。この場合、共通の可視特徴に係るアイテムのうちの、アレンジが禁止されている部分（すなわち共通の可視特徴）をスタッフユーザが編集すると、所定のペナルティが課せられてもよい。例えば、所定のペナルティは、そのアレンジされたアイテムを利用（例えば着用）できなくなる、アレンジしたものを保存できない（サーバ装置１０に保存できない）といった具合であってよい。あるいは、所定のペナルティは、後述するスタッフ管理部１８０の評価部１８０３の評価結果が著しく低下することを含んでもよい。また、共通の可視特徴に係るアイテムは、別ユーザと交換することや譲渡すること等を禁止されてよい。

なお、共通の可視特徴は、スタッフユーザの属性（スタッフ属性）に応じて異なってもよい。換言すると、共通の可視特徴は、スタッフ属性ごとに共通であってよい。スタッフ属性は、例えば、権限情報（通常権限と、操作権限、統括権限の３種類）に応じた属性であってもよいし、より細かい粒度（例えば、より詳細な役割や、位置する部屋等）に応じた属性であってもよい。これにより、各ユーザは、共通の可視特徴の種類に基づいて、スタッフユーザの属性（スタッフ属性）を判断できる。この場合も、同一のスタッフ属性のスタッフユーザに係るスタッフアバタｍ２は、共通の可視特徴を対応付けて描画される。また、スタッフユーザは、複数種類のオブジェクト（制服等）から任意の種類（例えば所望の種類）を選択可能であってもよい。

端末画像生成部１５８１は、好ましくは、一般ユーザ用の端末用画像と、スタッフユーザ用の端末用画像とを、異なる態様で描画する。この場合、ユーザアバタｍ１の位置／向き情報と、スタッフアバタｍ２の位置／向き情報とが完全に一致する場合でも、一般ユーザ用の端末用画像と、スタッフユーザ用の端末用画像とが、異なる態様で描画される。例えば、端末画像生成部１５８１は、スタッフユーザ用の端末用画像において、後述するユーザ情報取得部１５８２により取得された所定ユーザ情報を描画してもよい。この場合、所定ユーザ情報の描画方法は任意であるが、例えば、一般ユーザのユーザアバタｍ１に対応付けて描画されてもよい。例えば、所定ユーザ情報は、ユーザアバタｍ１に重畳又は近傍に描画されてもよいし、ユーザ名とともに描画されてもよい。また、この場合、所定ユーザ情報は、例えば、スタッフユーザの役割に有用な情報であって、通常は見えない情報（例えば次室移動条件の成否情報）であってよい。また、端末画像生成部１５８１は、スタッフユーザ用の端末用画像において、次室移動条件の成否情報（図９参照）に基づいて、次室移動条件を満たしているユーザアバタｍ１と、そうでないユーザアバタｍ１とを異なる態様で描画してもよい。この場合、スタッフユーザは、次室に移動可能なユーザアバタｍ１と、そうでないユーザアバタｍ１とを容易に見分けることができる。この結果、スタッフユーザは、次室に移動可能でないユーザアバタｍ１に係る一般ユーザに対して、効率的に補助情報を提供できる。

また、端末画像生成部１５８１は、スタッフユーザ用の端末用画像を生成する際、スタッフユーザに付与される権限情報に基づいて、通常は見えない情報の開示範囲を可変してもよい。例えば、端末画像生成部１５８１は、統括権限を有するスタッフユーザに係るスタッフアバタｍ２に対して、最も広い開示範囲を付与し、操作権限を有するスタッフユーザに係るスタッフアバタｍ２に対して、次に広い開示範囲を付与してもよい。

本実施形態では、端末画像生成部１５８１は、上述したように補助対象検出部１５７により補助対象のユーザアバタｍ１が検出された場合に、スタッフユーザ用の端末用画像において、当該補助対象のユーザアバタｍ１を所定の描画態様で描画する。

所定の描画態様は、スタッフユーザが容易に認識できるように強調表示（例えば点滅や赤色等で表示）を含んでよい。この場合、スタッフユーザは、補助対象のユーザアバタｍ１を容易に見つけることができる。

あるいは、所定の描画態様は、重畳表示されるサブ画像（図１５のサブ画像Ｇ１５６参照）の出現を伴ってもよい。この場合、端末画像生成部１５８１は、特定のスタッフユーザ用の端末用画像において、補助対象のユーザアバタｍ１を写すサブ画像を重畳表示する。この場合、特定のスタッフユーザは、補助対象のユーザアバタｍ１に近いスタッフアバタｍ２に係るスタッフユーザであってもよいし、補助対象のユーザアバタｍ１に補助情報を提供できる権限を有するスタッフユーザであってもよい。なお、補助対象検出部１５７により複数の補助対象のユーザアバタｍ１が検出された場合、サブ画像は、複数生成されてもよい。また、サブ画像は、枠等が点滅する態様で表示されてもよい。

また、所定の描画態様は、必要とする補助情報の属性に応じて異なってもよい。例えば、「特定のコンテンツの提供を受け終えていない」ことに起因して補助情報を必要としている補助対象のユーザアバタｍ１と、「特定のコンテンツの提供を受け終えているが、課題を提出できていない」ことに起因して補助情報を必要としている補助対象のユーザアバタｍ１とは、異なる所定の描画態様で描画されてもよい。この場合、所定の描画態様と、必要とする補助情報との関係をルール化することで、スタッフユーザは、補助対象のユーザアバタｍ１の描画態様を見ることで、当該補助対象のユーザアバタｍ１にとってどのような補助情報が有用であるかを容易に認識できる。

また、端末画像生成部１５８１は、補助対象検出部１５７により上述した付加情報が生成される場合、当該付加情報に応じて、補助対象のユーザアバタｍ１に補助情報を提供すべきスタッフユーザ（例えば上述した特定のスタッフユーザ）を決定してもよい。例えば、付加情報が示す属性（必要とする補助情報の属性）が、クレーム対応による対話である場合、端末画像生成部１５８１は、統括権限を有するスタッフユーザを、補助すべきスタッフユーザとして決定してもよい。この場合、端末画像生成部１５８１は、統括権限を有するスタッフユーザ用の端末用画像において当該補助対象のユーザアバタｍ１を写すサブ画像を、重畳表示してもよい。

ユーザ情報取得部１５８２は、上述した所定ユーザ情報を取得する。所定ユーザ情報は、上述したように、スタッフユーザ用の端末用画像において描画される情報であって、一般ユーザ用の端末用画像には、表示されることのない情報である。

ユーザ情報取得部１５８２は、スタッフユーザごとに所定ユーザ情報を取得してもよい。この場合、所定ユーザ情報をスタッフユーザごとに異ならせることができる。これは、スタッフユーザごとに、当該スタッフユーザの役割に有用な情報が異なりうるためである。

例えば、ユーザ情報取得部１５８２は、一のスタッフユーザに係るスタッフユーザ用の端末用画像に関して、当該端末用画像にユーザアバタｍ１が含まれる場合に、当該ユーザアバタｍ１に係るユーザ情報（例えば、図６のユーザ情報６００参照）に基づいて、当該ユーザアバタｍ１に係る一般ユーザに応じた所定ユーザ情報を取得してもよい。この場合、例えば、図６のユーザ情報６００を利用する場合、ユーザ情報取得部１５８２は、ユーザ情報６００における購買アイテム情報及び／又は購買関連情報、又は、それに基づき生成された情報を、所定ユーザ情報として取得してもよい。購買アイテム情報又はそれに基づき生成された情報（例えば購買アイテム情報の一部や、購買アイテム情報から得られるユーザの嗜好情報等）を所定ユーザ情報として取得する場合、スタッフユーザは、補助対象のユーザアバタｍ１に係る一般ユーザが、どのようなアイテムを既に所持しているかを把握できる。これにより、スタッフユーザは、一般ユーザに対して、所持していないアイテムの購買を薦める等、適切な補助情報の生成が可能となる。また、購買関連情報又はそれに基づき生成された情報（例えばユーザの嗜好情報等）を所定ユーザ情報として取得する場合、スタッフユーザは、補助対象のユーザアバタｍ１に係る一般ユーザが、どのような嗜好を有しているかを判断しやすくなる。例えば、宣伝したことがあるのに購入に至らなかった事実や、宣伝を重ねたら購入してくれた事実等をスタッフユーザが把握することで、一般ユーザの嗜好や行動傾向を把握しやすくなる。これにより、スタッフユーザは、宣伝が有用となる一般ユーザに対してのみアイテムの宣伝を行う等、適切な補助情報の生成が可能となる。

コンテンツ処理部１５９は、コンテンツ提供位置ごとに一般ユーザに特定のコンテンツを提供する。コンテンツ処理部１５９は、例えばブラウザを介して端末装置２０上で特定のコンテンツを出力してもよい。あるいは、コンテンツ処理部１５９は、端末装置２０に実装される仮想現実アプリケーションを介して、端末装置２０上で特定のコンテンツを出力してもよい。

なお、本実施形態では、上述したように、基本的には、コンテンツ処理部１５９により提供される特定のコンテンツは、コンテンツ提供位置ごとに異なる。例えば、一のコンテンツ提供位置で提供される特定のコンテンツは、他の一のコンテンツ提供位置で提供される特定のコンテンツとは異なる。ただし、同じ特定のコンテンツが、複数のコンテンツ提供位置で提供可能とされてもよい。

対話処理部１６０は、第１対話処理部１６０１と、第２対話処理部１６０２とを含む。

第１対話処理部１６０１は、複数の一般ユーザからの入力に基づいて、ネットワーク３を介した一般ユーザ間の対話を可能とする。対話は、対応するユーザアバタｍ１を介して、テキスト及び／又は音声によるチャット形式で実現されてもよい。これにより、一般ユーザ同士で対話が可能となる。なお、テキストは、端末装置２０の表示部２３に出力される。例えば、テキストは、仮想空間に係る画像とは別に出力されてもよいし、仮想空間に係る画像に重畳して出力されてもよい。端末装置２０の表示部２３に出力されるテキストによる対話は、不特定多数のユーザに公開される形式で実現されてもよいし、特定の一般ユーザ間のみで公開される形式で実現されてもよい。これは、音声によるチャットも同様である。

本実施形態では、第１対話処理部１６０１は、ユーザアバタｍ１のそれぞれの位置に基づいて、対話が可能な複数の一般ユーザを決定してもよい。例えば、第１対話処理部１６０１は、一のユーザアバタｍ１と他の一のユーザアバタｍ１との間の距離が所定距離ｄ１以下である場合に、当該一のユーザアバタｍ１と当該他の一のユーザアバタｍ１のそれぞれに係る一般ユーザ間の対話を可能としてもよい。所定距離ｄ１は、仮想空間や各部屋の広さ等に応じて適宜設定されてよく、固定であってもよいし、可変とされてもよい。また、端末用画像には、所定距離ｄ１に対応する範囲が色付け等により表現されてもよい。例えば赤エリアには、声が届くが、青エリアには、声が届かないといった態様である。

また、本実施形態では、第１対話処理部１６０１は、所定関係を有さない一般ユーザ間での対話を、所定関係を有する一般ユーザ間での対話よりも、制限してもよい。対話の制限は、対話できる時間や頻度等の制限により実現されてもよい。また、対話の制限は、対話の禁止を含む概念である。

所定関係は、任意であるが、グループを形成する関係であってもよいし、親子や近親者である関係、年齢が近い関係等であってもよい。あるいは、所定関係は、所定のアイテム（例えば鍵など）を有している関係であってもよい。また、次の部屋の方向を示す矢印のようなオブジェクトを効果音やサインボードとともに表示してもよい。また、強制的に逆走（例えば、前の部屋に戻る移動）ができないような制限領域を増やしたり、移動不可能なエリアの地面を崩壊させたり、暗転させるといった効果を加えてもよい。

本実施形態では、所定関係は、空間状態記憶部１４６内のデータに基づいて判定されてもよい。この場合、所定関係は、同様のユーザ状態情報を有する関係であってもよい。例えば、第１対話処理部１６０１は、同じコンテンツ提供位置に係る空間部分（部屋）に位置するユーザアバタｍ１のそれぞれに係る一般ユーザ間の対話を可能としてもよい。これにより、例えばグループで仮想空間内に訪問した複数の一般ユーザの場合、だれかが次の部屋に移動すると、グループ内での対話が不能になるので、かかる変化を楽しむこともできる。あるいは、次の部屋に移動した友人に追いつこうとする動機づけを与えることができる。また、これにより、自然な誘導でユーザの行動を制御できるため、ユーザの誘導を行うスタッフユーザの数を節減できる効果がある。また、残っているユーザが自分だけであることを示すために、各部屋の存在人数を画面に表示したり「みなさん次の部屋で待ってますよ」といったメッセージを表示してもよい。

第２対話処理部１６０２は、一般ユーザからの入力と、スタッフユーザからの入力に基づいて、ネットワーク３を介した一般ユーザとスタッフユーザとの間の対話を可能とする。対話は、対応するユーザアバタｍ１とスタッフアバタｍ２とを介して、テキスト及び／又は音声によるチャット形式で実現されてもよい。

また、第２対話処理部１６０２は、上述したように、スタッフアバタ処理部１５４の補助情報提供部１５４４と協動して、又は、補助情報提供部１５４４に代えて、機能してもよい。これにより、一般ユーザは、スタッフユーザからリアルタイムで補助（アシスタント）を受けることができる。

また、第２対話処理部１６０２は、複数のスタッフユーザからの入力に基づいて、ネットワーク３を介したスタッフユーザ間の対話を可能としてもよい。スタッフユーザ間の対話は、非公開形式であってよく、例えばスタッフユーザ間のみで開示されてもよい。あるいは、第２対話処理部１６０２は、スタッフユーザに付与される権限情報に基づいて、対話可能なスタッフユーザの範囲を可変してもよい。例えば、第２対話処理部１６０２は、統括権限を有するスタッフユーザに係るスタッフアバタｍ２に対して、すべてのスタッフユーザに対して対話できる権限を付与し、操作権限を有するスタッフユーザに係るスタッフアバタｍ２に対して、一定の場合だけ統括権限を有するスタッフユーザに対して対話できる権限を付与してもよい。

本実施形態では、第２対話処理部１６０２は、ユーザアバタｍ１のそれぞれの位置と、スタッフアバタｍ２の位置とに基づいて、複数の一般ユーザのうちの、スタッフユーザと対話が可能な一般ユーザを決定する。例えば、上述した第１対話処理部１６０１と同様に、一のスタッフアバタｍ２と一のユーザアバタｍ１との間の距離が所定距離ｄ２以下である場合に、当該一のスタッフアバタｍ２に係るスタッフユーザと当該一のユーザアバタｍ１に係る一般ユーザ間の対話を可能としてもよい。所定距離ｄ２は、仮想空間や各部屋の広さ等に応じて適宜設定されてよく、固定であってもよいし、可変とされてもよい。また、所定距離ｄ２は、上述した所定距離ｄ１よりも長くてもよい。

また、第２対話処理部１６０２は、スタッフユーザに付与される権限情報に基づいて、対話能力を可変してもよい。例えば、第２対話処理部１６０２は、統括権限を有するスタッフユーザに係るスタッフアバタｍ２に対して、最も大きい所定距離ｄ２を適用し、操作権限を有するスタッフユーザに係るスタッフアバタｍ２に対して、次に大きい所定距離ｄ２を適用してもよい。また、第２対話処理部１６０２は、統括権限を有するスタッフユーザに係るスタッフアバタｍ２に対して、すべてのユーザと対話できる機能（天の声のような機能）を付与してもよい。あるいは、第２対話処理部１６０２は、統括権限を有するスタッフユーザに係るスタッフアバタｍ２に対して、任意の対話を可能とするが、他の権限のスタッフユーザに係るスタッフアバタｍ２に対しては、それらの役割に関する対話のみを可能としてもよい。

また、本実施形態では、第２対話処理部１６０２は、スタッフユーザからの要求（入力）に基づいて、当該スタッフユーザと対話が可能な一般ユーザを変更してもよい。例えば、第２対話処理部１６０２は、上述した所定距離ｄ２を一時的に増加することで、スタッフユーザと対話が可能となる一般ユーザの範囲を広げてもよい。これにより、例えばスタッフユーザは、自身のスタッフアバタｍ２からは比較的離れた位置に補助を必要としそうなユーザアバタｍ１を自ら見つけたときに、比較的速やかに当該ユーザアバタｍ１の一般ユーザに話しかけることが可能である。なお、この場合、スタッフ動作処理部１５４２は、スタッフユーザのスタッフアバタｍ２を、比較的離れたユーザアバタｍ１の近傍まで瞬時に移動させてもよい（すなわち、上述した所定法則に反した動きを実現してもよい）。これにより、話しかけられた一般ユーザは、自身の端末装置２０に表示される端末用画像を介して、話しかけてきたスタッフアバタｍ２をすぐに認識できるので、安心感が高まり、スムーズな対話による補助を受けることができる。

活動制限部１６２は、仮想空間内における各ユーザアバタｍ１の活動であって、コンテンツ処理部１５９により提供される複数のコンテンツに係る活動を制限する。コンテンツに係る活動とは、コンテンツの提供を受けること自体であってよく、更に、コンテンツの提供を受けるための行動（例えば移動）等を含んでもよい。

本実施形態では、活動制限部１６２は、空間状態記憶部１４６内のデータに基づいて、活動を制限する。

具体的には、活動制限部１６２は、次室移動条件の成否情報（図９参照）に基づいて、仮想空間内における各ユーザアバタｍ１の活動を制限する。例えば、活動制限部１６２は、ある一のコンテンツ提供条件を満たさない一般ユーザに対しては、当該一のコンテンツ提供位置への移動を禁止する。このような移動の禁止は、任意の態様で実現されてもよい。例えば、活動制限部１６２は、当該一のコンテンツ提供位置への入口を、当該一のコンテンツ提供条件を満たさない一般ユーザに対してだけ無効化してもよい。このような無効化は、当該入口を不可視又は視認困難な状態にすることや、ユーザアバタｍ１が通れない当該入口の壁を設定すること等により実現されてもよい。

他方、活動制限部１６２は、ある一のコンテンツ提供条件を満たしている一般ユーザに対しては、当該一のコンテンツ提供位置への移動を許可する。このような移動の許可は、任意の態様で実現されてもよい。例えば、活動制限部１６２は、当該一のコンテンツ提供位置への入口を、当該一のコンテンツ提供条件を満たす一般ユーザに対してだけ有効化してもよい。このような有効化（無効化された状態からの遷移）は、当該入口を不可視状態から可視状態に変更することや、ユーザアバタｍ１が通れない当該入口の壁を除去すること等により実現されてもよい。また、このような移動の許可は、スタッフユーザによる入力に基づいて実現されてもよい。この場合、スタッフユーザは、通常は見えない情報（例えば次室移動条件の成否情報）に基づいて、自室移動条件を満たすユーザアバタｍ１を検出してもよい。また、このような空間的な移動や可視性だけでなく、許可された一般ユーザは、まだ許可されていない一般ユーザと対話（例えば音声会話）をできない状態にする、といった具合に、第１対話処理部１６０１による分断も実現可能であってよい。これによって、例えば、先行者の一般ユーザによる後続者のユーザへの不要なヒントの流出やネタバレ等を防ぐことができる。また、後続者の一般ユーザは、自ら回答を発見しない限り、次のステップに進むことができないため、このような一般ユーザに主体的な参加（解決）を促すことができる。

条件処理部１６４は、スタッフユーザからの入力に基づいて、複数の一般ユーザのうちの一部の一般ユーザに対して、コンテンツ処理部１５９により提供可能な複数の特定のコンテンツのうちの、一部又は全部のコンテンツ提供条件を緩和する。あるいは、条件処理部１６４は、スタッフユーザからの入力に基づいて、複数の一般ユーザのうちの一部の一般ユーザに対して、コンテンツ処理部１５９により提供可能な複数の特定のコンテンツのうちの、一部又は全部のコンテンツ提供条件を厳しくしてもよい。すなわち、条件処理部１６４は、スタッフユーザからの入力に基づいて、特定の一の一般ユーザに対して適用されるコンテンツ提供条件を、通常条件と緩和条件（図８参照）の間で変更してもよい。これにより、スタッフユーザの裁量等によりコンテンツ提供条件の厳しさを変更できるので、一般ユーザのそれぞれの適用度やレベルに応じて、適切なコンテンツ提供条件を設定できる。

本実施形態において、条件処理部１６４は、すべてのスタッフユーザからの入力に基づいて、コンテンツ提供条件を変更してもよいが、一定条件を満たすスタッフユーザからの入力に基づいて、コンテンツ提供条件を変更してもよい。例えば、条件処理部１６４は、統括権限を有するスタッフユーザからの入力に基づいて、コンテンツ提供条件を変更してもよい。これにより、統括権限を有するスタッフユーザのみが適切なコンテンツ提供条件を設定できるので、一般ユーザ間のバランスの公平化を図ることができる。

抽出処理部１６６は、一般ユーザのそれぞれに対応付けられたユーザ状態情報９００（図９参照）に基づいて、コンテンツ処理部１５９により提供可能な複数の特定のコンテンツのうちの所定数以上のコンテンツの提供又は特定のコンテンツの提供を受けた第１ユーザを抽出する。所定数は、１以上の任意であるが、Ｎ個の特定のコンテンツが提供可能な仮想空間においては、例えばＮ／２個であってもよいし、Ｎ個であってもよい。

役割割当部１６７は、スタッフユーザからの入力に基づいて、又は、スタッフユーザからの入力に基づかずに、抽出処理部１６６により抽出された一般ユーザに対応付けられたユーザアバタｍ１に対して、仮想空間内におけるスタッフアバタｍ２に係る役割の少なくとも一部を付与する。すなわち、当該一般ユーザを、スタッフユーザになることができる一般ユーザに変換し、当該一般ユーザに係るスタッフ可否情報を更新し、スタッフＩＤを付与する。役割割当部１６７により一般ユーザに付与される役割は、任意であり、例えば、統括権限を有するスタッフユーザの役割のうちの、重要度の比較的低い一部であってもよい。また、例えば、役割割当部１６７により一般ユーザに付与される役割は、通常権限が与えられたスタッフユーザと同じ役割であってもよいし、その一部であってよい。あるいは、役割割当部１６７により一般ユーザに付与される役割は、操作権限が与えられたスタッフユーザと同じ役割であってもよいし、その一部であってよい。

この場合、役割割当部１６７は、統括権限を有するスタッフユーザからの入力に基づいて、仮想空間内におけるスタッフアバタｍ２に係る役割の少なくとも一部を付与してもよい。これにより、統括権限を有するスタッフユーザの責任で、候補となる一般ユーザを選択できる。従って、統括権限を有するスタッフユーザは、例えば、与えられる予定の役割に対する理解が比較的深い一般ユーザに、スタッフユーザとして効率的に機能してもらい、当該役割を適切に果たしてもらうことができる。

また、統括権限を有するスタッフユーザは、抽出処理部１６６により抽出された一般ユーザ以外からも、自ら、候補となる一般ユーザを探索／勧誘することも可能である。例えば、ある商品（例えばアバタが装着可能な衣服）を販売するスタッフユーザが欠員する状況下では、統括権限を有するスタッフユーザは、当該商品を購買する頻度や数が大きい一般ユーザを探索し（例えばユーザ情報６００の購買アイテム情報に基づいて探索し）、当該アイテムを購買するスタッフユーザにならないかどうか勧誘することも可能である。この場合、当該商品を購買する頻度や数が大きい一般ユーザは、当該商品に詳しい可能性が高く、かかる商品を購買しようとしている一般ユーザに対して、スタッフユーザとして適切なアドバイス等を行うことを期待できる。

なお、役割割当部１６７は、一般ユーザからスタッフユーザに変換したユーザに対して、統括権限を有するスタッフユーザからの入力に基づいて、付与する役割を増減させてもよい。これにより、一般ユーザからスタッフユーザに変換したユーザに係る役割の負担を適宜調整できる。このようにしてスタッフユーザに変換された一般ユーザには、スタッフユーザとして、図６のスタッフ情報６０２で示すような各種の情報が割り当てられてよい。この場合、一般ユーザからスタッフユーザに変換したユーザに対しては、スタッフ情報６０２の権限情報に代えて又は加えて、役割に関する情報が対応付けられてもよい。役割に関する情報の粒度は任意であり、役割の粒度に応じて適合されてよい。これは、スタッフユーザの役割（権限情報）についても同様である。

このようにして、本実施形態では、ユーザは、一般ユーザからスタッフユーザになることができ、スタッフユーザになりたいユーザに対して、所定数以上のコンテンツの提供を受ける動機づけを与えることができる。所定数以上のコンテンツの提供を受けた一般ユーザは、当該コンテンツから、与えられる役割を果たせるような能力を身に付けている可能性が高く、特定のコンテンツを介したスキルアップを効率的に図ることができる。

なお、本実施形態において、スタッフユーザになることができるユーザは、仮想空間内に入る際に、一般ユーザとして入るか、スタッフユーザとして入るかを、選択できてもよい。

空間情報生成部１６８は、上述した空間状態記憶部１４６内に格納される空間状態情報を生成し、空間状態記憶部１４６内のデータを更新する。例えば、空間情報生成部１６８は、定期的に又は不定期的に、入室ユーザのそれぞれに対して、次室移動条件の成否を監視し、次室移動条件の成否情報を更新する。

パラメータ更新部１７０は、上述したスタッフポイントを更新する。例えば、パラメータ更新部１７０は、図９に示す空間状態情報に基づいて、各スタッフユーザの稼働状況に応じてスタッフポイントを更新してよい。例えば、パラメータ更新部１７０は、稼働時間が長くなるほど多くのスタッフポイントを付与する態様で、スタッフポイントを更新してよい。また、パラメータ更新部１７０は、チャット等による一般ユーザへの補助回数等（発話量や、発話回数、アテンド回数、クレーム対応回数等）に基づいて、スタッフポイントを更新してよい。また、仮想現実において商品やサービスの販売が行われる場合、パラメータ更新部１７０は、スタッフユーザによる商品やサービスの販売の状況（例えば売り上げ）に基づいて、スタッフポイントを更新してよい。あるいは、パラメータ更新部１７０は、一般ユーザにより入力されうるスタッフユーザに対する満足度情報（例えばアンケート情報に含まれる評価値等）に基づいて、スタッフポイントを更新してよい。なお、スタッフポイントの更新は、適宜、実行されてもよく、例えば定期的に、ログ情報に基づいて一括的に実行されてもよい。

スタッフユーザにより販売される商品やサービスは、現実で利用可能な商品やサービスであってもよいし、仮想現実において利用可能な商品やサービスであってもよい。スタッフユーザにより販売される商品やサービスは、コンテンツ提供位置で提供されるコンテンツに関連してよく、例えば当該コンテンツに係る体験を増大できるようなアイテム等を含んでよい。例えば、コンテンツが、上述した旅行に関連する場合、アイテムは、遠くを見ることができる望遠鏡等であってもよいし、動物等に与えることができる餌等であってもよい。また、コンテンツが、スポーツやコンサートに関連する場合、アイテムは、応援グッズや、選手やアーティストとの記念撮影権や会話権等であってもよい。

スタッフ管理部１８０は、仮想空間におけるスタッフユーザによるスタッフアバタｍ２を介した活動等に基づいて、スタッフユーザを管理する。

本実施形態では、スタッフユーザは、仮想現実を一般ユーザとして体験することも可能である。すなわち、スタッフユーザは、例えば自身の選択に応じて、スタッフユーザとなることも、一般ユーザとなることも可能である。換言すると、スタッフユーザは、スタッフユーザとなることが可能な一般ユーザである。なお、これは、上述した役割割当部１６７により、スタッフユーザになることができるユーザについても同様である。スタッフユーザとなることが可能な一般ユーザは、スタッフユーザとなることが不能な一般ユーザとは異なり、特別なアイテム（第２オブジェクトｍ３）として、制服を装着できる。

スタッフ管理部１８０は、第１判定部１８０１と、第１属性変更部１８０２と、評価部１８０３と、第２判定部１８０４と、第２属性変更部１８０５と、インセンティブ付与部１８０６とを含む。

第１判定部１８０１は、一のユーザがスタッフユーザと一般ユーザとの間で変化したか否かを判定する。すなわち、第１判定部１８０１は、一のユーザの属性が変化したか否かを判定する。第１判定部１８０１は、後述する第１属性変更部１８０２や第２属性変更部１８０５により一のユーザの属性が変更された場合に、当該一のユーザの属性が変化したと判定する。

第１判定部１８０１は、一のユーザがスタッフユーザと一般ユーザとの間で変化したと判定した場合に、端末画像生成部１５８１に対して当該変化を反映させる。具体的には、端末画像生成部１５８１は、一のユーザがスタッフユーザと一般ユーザとの間で変化した場合に、当該一のユーザに係るアバタが描画されている端末用画像（一般ユーザ用の端末用画像及び／又はスタッフユーザ用の端末用画像）において、当該変化を当該一のユーザに係るアバタの描画態様に反映させる。例えば、一のユーザがスタッフユーザから一般ユーザへ変化した場合は、端末画像生成部１５８１は、当該一のユーザに対応するアバタをユーザアバタｍ１として描画する。他方、一のユーザが一般ユーザからスタッフユーザへ変化した場合は、端末画像生成部１５８１は、当該一のユーザに対応するアバタをスタッフアバタｍ２（すなわち制服を着用しているアバタ）として描画する。

また、第１判定部１８０１は、一のユーザがスタッフユーザと一般ユーザとの間で変化したと判定した場合に、パラメータ更新部１７０に対して当該変化をスタッフポイント（図６参照）に反映させる。例えば、パラメータ更新部１７０は、一のユーザがスタッフユーザに変化した場合、当該一のユーザの労働時間のカウントを開始し、その後、当該一のユーザが一般ユーザに変化した場合、当該一のユーザの労働時間のカウントを終了してよい。なお、スタッフポイントの更新は、リアルタイムに実現されてもよいし、事後的に実現されてもよい。

第１属性変更部１８０２は、一のユーザ（スタッフユーザとなることが可能な一般ユーザ）からのユーザ入力である属性変化要求（所定入力の一例）に基づいて、一のユーザをスタッフユーザと一般ユーザとの間で変化させる。すなわち、第１属性変更部１８０２は、一のユーザからの属性変化要求に基づいて、当該一のユーザの属性を変化させる。

属性変化要求は、直接的な要求（例えばスタッフユーザや一般ユーザを指定する入力）であってもよいし、間接的な要求であってよい。間接的な要求の場合、属性変化要求は、例えば、自身のユーザアバタｍ１に共通の可視特徴が対応付けられるような要求であり、アバタに係る私服から制服への着替え要求、又は、アバタに係る制服から私服への着替え要求を含んでよい。この場合、アバタに係る私服から制服への着替え要求は、一般ユーザからスタッフユーザへの属性変化要求に対応し、アバタに係る制服から私服への着替え要求は、スタッフユーザから一般ユーザへの属性変化要求に対応する。また、複数種類の共通の可視特徴のうちから所望の共通の可視特徴を選択できるスタッフユーザに関しては、当該スタッフユーザに係る属性変化要求は、複数種類の共通の可視特徴のうちから、当該スタッフユーザが選択した共通の可視特徴の種類を表す情報を含んでもよい。

なお、ユーザ（スタッフユーザとなることが可能な一般ユーザ）による属性変化要求は、任意のタイミングで入力可能であってもよい。例えば、スタッフユーザとなることが可能な一般ユーザは、例えばそのときの気分や状況等に応じて、仮想空間内に入った後に、一般ユーザからスタッフユーザへと、又は、スタッフユーザから一般ユーザへと、変化できてもよい。あるいは、ユーザによる属性変化要求は、所定条件下で入力可能であってもよい。例えば、スタッフユーザから一般ユーザへの属性変化要求は、仮想空間内に補助対象のユーザアバタｍ１が存在しない場合や、当該スタッフユーザに係るスタッフアバタｍ２が補助に係る活動中（例えば補助対象のユーザアバタｍ１と対話中）でない場合等に、入力可能であってもよい。また、一般ユーザからスタッフユーザへの属性変化要求は、例えば当該一般ユーザに係るユーザアバタｍ１が所定位置（例えば、図２Ｄに示す位置ＳＰ２０２や、図２Ｄに示す自身のロッカー８４の近傍位置等）に位置する場合に、入力可能であってもよい。

評価部１８０３は、一のユーザがスタッフユーザであるときに、当該一のユーザがスタッフユーザとしての所定役割を適切に果たしているかを評価する。所定役割は、当該一のユーザがスタッフユーザであるときに付与されている役割であり、上述したように、当該スタッフユーザの権限に応じて異なる。この場合、評価部１８０３は、各スタッフユーザの役割を、スタッフ情報６０２（図６参照）の権限情報に基づいて判断してよい。評価部１８０３は、基本的には、スタッフユーザがさぼって活動していない（ユーザアバタｍ１の位置や視線等の方向が変化しない、発話がない等）場合、後述する所定基準を満たさないような低い評価結果を付与してよい。

例えば、評価部１８０３は、通常権限を有するスタッフユーザに対しては、一般ユーザへの上述した所定情報の提供状況に基づいて、所定役割を適切に果たしているかを評価してよい。この場合、評価部１８０３は、通常権限を有するスタッフユーザに対しては、統括権限を有するスタッフユーザからの評価入力（当該通常権限を有するスタッフユーザに対する評価入力）に更に基づいて、所定役割を適切に果たしているかを評価してよい。同様に、評価部１８０３は、操作権限を有するスタッフユーザに対しては、演出用の各種操作を適切に実行しているか否かに基づいて、所定役割を適切に果たしているかを評価してよい。この場合も、評価部１８０３は、操作権限を有するスタッフユーザに対しては、統括権限を有するスタッフユーザからの評価入力（当該操作権限を有するスタッフユーザに対する評価入力）に更に基づいて、所定役割を適切に果たしているかを評価してよい。なお、評価部１８０３は、統括権限を有するスタッフユーザに対しては評価を行わなくてもよい。統括権限を有するスタッフユーザは、他のスタッフユーザを評価する側であるためである。

あるいは、評価部１８０３は、パラメータ更新部１７０により更新されるスタッフポイント（図６参照）に基づいて、一のユーザがスタッフユーザとしての所定役割を適切に果たしているかを評価してもよい。この場合、評価部１８０３は、パラメータ更新部１７０により更新されるスタッフポイントの値自体やその増加態様に基づいて、各スタッフユーザの評価を実現してもよい。

また、評価部１８０３は、スタッフユーザが一般ユーザを補助している際の、スタッフアバタｍ２の視線方向（例えば眼球の向き）に基づいて、スタッフユーザの評価を実現してもよい。この場合、スタッフアバタｍ２がユーザアバタｍ１の方を向いて対話しているかどうかが、対話内容が適切であるかどうか等の評価項目に加えて、評価されてもよい。また、視線方向に代えて、顔向きや、距離（仮想空間内におけるスタッフアバタｍ２とユーザアバタｍ１との間の距離）、位置（例えば、補助対象のユーザアバタｍ１に対する立ち位置）等が考慮されてもよい。また、指定されたイベントに参加して拍手やコメントをする（いわゆるモブ（群衆）、エキストラ、にぎやかし、応援団等）のような役割が付与されているスタッフアバタｍ２の場合、拍手やコメントの頻度や内容等が考慮されてもよい。

また、評価部１８０３は、スタッフユーザが一般ユーザを補助した後の、一般ユーザの活動に基づいて、スタッフユーザの評価を実現してもよい。この場合、例えば展示場に係る仮想空間においては、一般ユーザが、スタッフユーザの補助を受けることで、所望の目的位置（店舗等）にスムーズにたどり着けたかどうかが、評価されてもよい。また、就職斡旋に係る仮想空間において、一般ユーザが、スタッフユーザの補助を受けることで、所望の目的位置（所望の会社のブース等）にスムーズにたどり着けたかどうかが、評価されてもよい。

また、評価部１８０３は、スタッフユーザが一般ユーザを補助する際の、立ち振舞方に基づいて、スタッフユーザの評価を実現してもよい。この場合、例えば料亭に係る仮想空間においては、女将さんの役割を果たすスタッフアバタｍ２が、お客様であるユーザアバタｍ１に対して、適切な作法でおもてなしができているかどうかが、評価されてもよい。

また、評価部１８０３は、例えば契約等により労働条件（例えば労働時間など）が定められている場合は、労働条件が満たされているか否かに基づいて、スタッフユーザの評価を実現してもよい。

また、評価部１８０３は、例えば、ＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ）といった各種の指標値や売上成績を用いて、各スタッフユーザを評価してもよい。

第２判定部１８０４は、評価部１８０３による評価結果が所定基準を満たしているか否かを判定する。例えば、評価部１８０３による評価結果は、“優”、“普通”、“不可”の３段階で出力される場合、評価結果“優”又は“普通”は所定基準を満たしてよい。

第２属性変更部１８０５は、第２判定部１８０４により所定基準を満たしていないと判定されたスタッフユーザを、一般ユーザへと強制的に（すなわち上述した属性変化要求とは無関係に）変更する。これにより、所定役割を適切に果たしていないスタッフユーザを排除して仮想空間内でのスタッフユーザによるユーザ補助機能の有用性を適切に維持できる。また、スタッフユーザに対して所定役割を適切に果たそうと心がける動機づけを与えることができる。

インセンティブ付与部１８０６は、パラメータ更新部１７０により更新されるスタッフポイントの値に基づいて、スタッフユーザのそれぞれにインセンティブを付与する。なお、インセンティブ付与部１８０６による付与対象のスタッフユーザは、すべてのスタッフユーザであってもよいし、統括権限を有するスタッフユーザ以外のすべてのスタッフユーザであってもよい。

一のスタッフユーザに与えられるインセンティブは、任意であり、当該一のスタッフユーザのスタッフアバタｍ２が配置される仮想空間において使用できるアイテム等であってもよいし、当該一のスタッフユーザのスタッフアバタｍ２が配置される仮想空間とは異なる他の仮想空間において使用できるアイテム等であってもよい。また、インセンティブは、昇格に対応する所定役割の変更や、通常権限から操作権限への変更等であってよい。また、インセンティブは、スタッフユーザへの給与とは別のボーナスであってよい。

図５は、一般ユーザに係る端末装置２０により実現される機能５００と、スタッフユーザに係る端末装置２０により実現される機能５０２とが併せて示されている。なお、図５は、端末装置２０にダウンロード等される仮想現実アプリケーションにより実現される各種機能のうちの、ユーザ補助機能に関連した機能だけを示す。なお、仮想現実アプリケーションは、機能５００を実現するユーザ用アプリケーションと、機能５０２を実現するスタッフ用アプリケーションとが別々に実装可能であってもよいし、一のアプリケーション内で機能５００と機能５０２とはユーザによる操作により切り替え可能とされてもよい。

一般ユーザに係る端末装置２０は、補助要求部２５０を含む。補助要求部２５０は、一般ユーザからの入力に基づいて、補助要求をネットワーク３を介してサーバ装置１０に送信する。なお、補助要求は、端末装置２０に対応付けられた端末ＩＤ又はログインしている仮想現実アプリケーションのユーザＩＤを含むことで、補助要求に基づいて補助対象のユーザアバタｍ１がサーバ装置１０において特定される。

なお、本実施形態では、補助対象のユーザアバタｍ１は、上述したように、サーバ装置１０の補助対象検出部１５７により検出されるので、補助要求部２５０は適宜省略されてもよい。

スタッフユーザに係る端末装置２０は、支援実行部２６２と、条件変更部２６３と、役割付与部２６４とを含む。なお、以下で説明するスタッフユーザに係る端末装置２０により実現される機能５０２の機能の一部又は全部は、サーバ装置１０により実現されてもよい。また、図５に示す支援実行部２６２、条件変更部２６３、及び役割付与部２６４は、一例であり、一部が省略されてもよい。

支援実行部２６２は、スタッフユーザからの所定入力に基づいて、上述した補助情報提供部１５４４により一般ユーザに補助情報を提供するための補助要求を、ネットワーク３を介してサーバ装置１０に送信する。例えば、支援実行部２６２は、スタッフユーザからの所定入力に応答して、サーバ装置１０の補助対象検出部１５７により検出されたユーザアバタｍ１を補助情報の伝達対象とした補助要求を、サーバ装置１０に送信する。なお、補助情報の伝達対象のユーザアバタｍ１は、スタッフユーザが自身で決定してもよい。例えば、スタッフユーザは、上述したように、端末用画像において描画されうる、通常は見えない情報（例えば次室移動条件の成否情報）に基づいて、補助対象のユーザアバタｍ１（補助対象検出部１５７により検出されないユーザアバタｍ１）を特定してもよい。また、補助要求は、生成する補助情報の内容を指示する情報等を含んでよい。

条件変更部２６３は、スタッフユーザからの入力に基づいて、上述したような条件処理部１６４による条件変更を指示する要求（条件変更要求）を、サーバ装置１０に送信する。例えば、条件変更部２６３は、スタッフユーザからの条件変更用の入力に応答して、特定のユーザアバタｍ１を対象とした条件変更要求を、サーバ装置１０に送信する。なお、特定のユーザアバタｍ１は、サーバ装置１０の補助対象検出部１５７により検出された補助対象のユーザアバタｍ１であってもよいし、補助情報の伝達対象と同様、スタッフユーザが自身で決定してもよい。

役割付与部２６４は、スタッフユーザからの入力に基づいて、上述したような役割割当部１６７による役割の付与を指示する要求（役割付与要求）を、サーバ装置１０に送信する。例えば、役割付与部２６４は、スタッフユーザからの役割付与用の入力に応答して、役割付与要求を、サーバ装置１０に送信する。なお、役割付与要求は、役割を付与する対象となるユーザアバタｍ１を特定する情報や、付与する役割の内容を示す情報等を含んでよい。

（ユーザ補助機能に関連した動作例）
次に、図１０から図１８を参照して、上述したユーザ補助機能に関連した動作例について説明する。なお、以下の動作例は、具体的な動作例であるが、上述したユーザ補助機能に関連した動作は、上述したように、多様な態様で実現可能である。

以下では、一例として、図２Ｂに示した仮想空間に関して、上述したユーザ補助機能に関連した動作例について説明する。

図１０は、上述したユーザ補助機能に関連した動作例を示すタイミングチャートである。図１０では、区別のために、ある一般ユーザに係る端末装置２０に対して、符号「２０－Ａ」を付与し、他の一般ユーザに係る端末装置２０に対して、符号「２０－Ｂ」を付与し、スタッフユーザに係る端末装置２０に対して、符号「２０－Ｃ」を付与している。以下では、説明上、端末装置２０－Ａに係る一般ユーザを、ユーザ名「ａｍｉ」とし、端末装置２０－Ｂに係る一般ユーザを、ユーザ名「ｆｕｊ」とし、両者は学生（例えば、ユーザ名「ａｍｉ」が学生Ａで、ユーザ名「ｆｕｊ」が学生Ｂ）である。また、以下では、ユーザ名「ａｍｉ」に係る一般ユーザを、学生ユーザＡと称し、ユーザ名「ｆｕｊ」に係る一般ユーザを、学生ユーザＢと称する。また、以下では、複数のスタッフユーザが登場するが、端末装置２０－Ｃは、これらのスタッフユーザに係る各端末装置２０を包括した態様で示す。また、図１０において、図面の複雑化防止の都合上、端末装置２０－Ｃから端末装置２０－Ａ、２０－Ｂへの補助情報の送信は、直接的な態様で図示されているが、サーバ装置１０を介して実現されてよい。

図１１、図１２、及び図１４から図１８は、図１０に示す動作例の説明図であり、各場面での端末用画面の一例を示す図である。図１３は、ある時点での、図２Ｂに示した仮想空間における状態を模式的に示す図である。

まず、ステップＳ１０Ａにおいて、学生ユーザＡは、端末装置２０－Ａにおいて、仮想現実アプリケーションを起動し、ステップＳ１０Ｂにおいて、学生ユーザＢは、端末装置２０－Ｂにおいて、仮想現実アプリケーションを起動する。なお、仮想現実アプリケーションは、端末装置２０－Ａ、２０－Ｂのそれぞれにおいて、時間差をもって起動されてもよいし、起動タイミングは任意である。なお、ここでは、スタッフユーザは、端末装置２０－Ｃにおいて、仮想現実アプリケーションを起動済みであるとするが、この起動タイミングも任意である。

ついで、ステップＳ１１Ａにおいて、学生ユーザＡは、仮想空間内に入り、自身のユーザアバタｍ１を移動させ、１番目のコンテンツ提供位置に係る入口付近まで至る。同様に、ステップＳ１１Ｂにおいて、学生ユーザＢは、仮想空間内に入り、仮想空間内で自身のユーザアバタｍ１を移動させ、１番目のコンテンツ提供位置に係る入口付近まで至る。図１１は、学生ユーザＢのユーザアバタｍ１が１番目のコンテンツ提供位置に係る入口付近に位置するときの、学生ユーザＢ用の端末用画像Ｇ１１０を示す。なお、図１１に示す状態では、学生ユーザＡのユーザアバタｍ１は、学生ユーザＢのユーザアバタｍ１の背後にいるものとする。図１１に示すように、学生ユーザＢ用の端末用画像Ｇ１１０からは、位置ＳＰ１に対応付けて、スタッフ名「ｃｈａ」が対応付けられたスタッフアバタｍ２が配置され、１番目のコンテンツ提供位置に係る入口領域に対応する位置ＳＰ２に対応付けて、スタッフ名「ｓｕｋ」が対応付けられたスタッフアバタｍ２が配置されていることがわかる。

本実施形態では、図１１に示す端末用画像Ｇ１１０からよくわかるように、スタッフアバタｍ２は、制服を着用しているので、学生ユーザＡや学生ユーザＢのような一般ユーザは、他の一般ユーザに係るユーザアバタｍ１とスタッフアバタｍ２とを見間違える可能性が低減される。これにより、各ユーザは、なにか困ったことがあった場合等、スタッフユーザからスムーズに支援（補助）を受けることができる。

この場合、学生ユーザＡ及び学生ユーザＢは、スタッフ名「ｃｈａ」のスタッフアバタｍ２から補助情報の送信（ステップＳ１２）を受けてよい。例えば、学生ユーザＡ及び学生ユーザＢは、入場用チュートリアルのコンテンツの視聴案内を受ける。かかる補助情報は、入場用チュートリアルのコンテンツを視聴するためのＵＲＬを含んでよい。図１２は、位置ＳＰ１においてスタッフ名「ｃｈａ」のスタッフアバタｍ２から補助を受けているときの、学生ユーザＢ用の端末用画像Ｇ１２０を示す。なお、図１２では、スタッフ名「ｃｈａ」のスタッフユーザの入力に基づくチャットのテキスト「初めての方は、チュートリアルをどうぞ！」が示されている。なお、この種のチャットは自動的に生成されてもよい。

学生ユーザＡ及び学生ユーザＢは、入場用チュートリアルを視聴すると、入口領域に対応する位置ＳＰ２へと移動する（ステップＳ１１Ｃ、ステップＳ１１Ｄ）。この際、学生ユーザＡ及び学生ユーザＢは、位置ＳＰ２にて、スタッフ名「ｓｕｋ」のスタッフアバタｍ２から補助情報の送信（ステップＳ１３）を受けてよい。例えば、学生ユーザＡ及び学生ユーザＢは、次室移動条件に関するアドバイス等の補助を受けてよい。この場合、サーバ装置１０は、ステップＳ１３よりも前に、学生ユーザＡ及び学生ユーザＢの次室移動条件が満たされているか否かの入室判定を行う（ステップＳ１４）。ここでは、学生ユーザＡ及び学生ユーザＢは、スタッフユーザからの補助もあり、次室移動条件を満たしているものとする。この場合、サーバ装置１０は、１番目のコンテンツ提供位置へと移動するためのＵＲＬを、端末装置２０－Ａ、２０－Ｂのそれぞれに送信する（ステップＳ１５）。なお、１番目のコンテンツ提供位置へと移動するためのＵＲＬは、チケットの形態の第２オブジェクトｍ３（図１２参照）に描画されてもよい。

そして、学生ユーザＡ及び学生ユーザＢは、サーバ装置１０から送信されたＵＲＬにアクセスすることで、１番目のコンテンツ提供位置（図１３の第１位置ＳＰ１１参照）に移動する（ステップＳ１６Ａ、Ｓ１６Ｂ）。このようにして、学生ユーザＡ及び学生ユーザＢがそれぞれのユーザアバタｍ１を１番目のコンテンツ提供位置に移動させると、サーバ装置１０は、１番目のコンテンツ提供位置に対応付けられた特定のコンテンツを端末装置２０－Ａ、２０－Ｂのそれぞれに送信する（ステップＳ１７）。これにより、学生ユーザＡ及び学生ユーザＢは、１番目のコンテンツ提供位置に対応付けられた特定のコンテンツの提供を受けることができる（ステップＳ１８Ａ、ステップＳ１８Ｂ）。図１４は、図１３の第１位置ＳＰ１１で特定のコンテンツの提供を受けているときの、学生ユーザＢ用の端末用画像Ｇ１４０を示す。端末用画像Ｇ１４０は、大型スクリーン（第２オブジェクトｍ３）に対応する画像部Ｇ１４１に、映像コンテンツが出力されている状態に対応する。学生ユーザＡ及び学生ユーザＢは、それぞれの端末用画像Ｇ１４０を介して、大型スクリーン上の映像コンテンツを視聴することで、第１位置ＳＰ１１で特定のコンテンツの提供を受けることができる。端末用画像Ｇ１４０は、図１４に示すように、学生ユーザＢの入力に基づくチャットのテキスト「なるほど、わかりやすいね！」を含んでよい。このようにして、学生ユーザＡと学生ユーザＢは、一緒に、適宜対話しながら、１番目のコンテンツ提供位置に対応付けられた特定のコンテンツの提供を受けることができる。

なお、サーバ装置１０は、この間、定期的に又は所定の変化が発生した際に、学生ユーザＡ及び学生ユーザＢのそれぞれのユーザアバタｍ１の状態に基づいて、適宜、空間状態記憶部１４６内のデータ（図９の部屋滞在時間等）を更新する（ステップＳ１９）。

学生ユーザＡ及び学生ユーザＢは、１番目のコンテンツ提供位置に対応付けられた特定のコンテンツの提供を受け終えると、当該特定のコンテンツに関連する課題等を提出する（ステップＳ２０Ａ、Ｓ２０Ｂ）。課題等の提出方法は、任意であり、課題提出用のＵＲＬが利用されてもよい。サーバ装置１０は、学生ユーザＡ及び学生ユーザＢがそれぞれのユーザアバタｍ１を介した課題の提出結果に基づいて、学生ユーザＡ及び学生ユーザＢの次室移動条件が満たされているか否かの入室判定を行い、空間状態記憶部１４６内のデータ（図９の次室移動条件の成否情報参照）を更新する（ステップＳ２１）。

学生ユーザＡ及び学生ユーザＢは、課題を提出すると、それぞれのユーザアバタｍ１を移動させ、２番目のコンテンツ提供位置に係る入口領域まで至る（ステップＳ２２Ａ、Ｓ２２Ｂ）（図１３参照）。サーバ装置１０は、学生ユーザＡ及び学生ユーザＢの次室移動条件の可否情報に基づいて、次室移動条件の可否情報に応じた端末用画像を生成する（ステップＳ２３）。ここでは、学生ユーザＡは、次室移動条件が満たされているが、学生ユーザＢは、次室移動条件が満たされていないものとする。この場合、例えば、サーバ装置１０は、学生ユーザＡに対して、２番目のコンテンツ提供位置へ移動できる入口を描画した端末用画像を生成し、学生ユーザＢに対して、２番目のコンテンツ提供位置へ移動できる入口に壁を描画した端末用画像を生成する。そして、サーバ装置１０は、２番目のコンテンツ提供位置へと移動するためのＵＲＬを、端末装置２０－Ａに送信する（ステップＳ２４）。なお、２番目のコンテンツ提供位置へと移動するためのＵＲＬは、２番目のコンテンツ提供位置へ移動できる入口を描画した端末用画像に描画されてもよい。この場合、端末装置２０－Ａは、当該ＵＲＬを画像認識等により検出し、自動的にアクセスしてもよい。これにより、学生ユーザＡは、２番目のコンテンツ提供位置へとユーザアバタｍ１を進めることができる（ステップＳ２５）。

他方、サーバ装置１０は、スタッフユーザ用の端末用画像において、学生ユーザＢのユーザアバタｍ１を、補助対象のユーザアバタｍ１として、他のユーザアバタｍ１とは異なる態様（上述した所定の描画態様）で描画する（ステップＳ２６）。この場合、補助対象のユーザアバタｍ１の描画態様は、上述したように、スタッフユーザが見ると、その旨（例えば「特定のコンテンツの提供を受け終えているが、次室移動条件を満たしていないこと」）がわかるような、描画態様であってよい。

本実施形態では、サーバ装置１０は、補助対象のユーザアバタｍ１を検出すると、スタッフユーザ用の端末用画像において、補助用のサブ画像をメイン画像上に重畳表示させる。図１５は、補助対象のユーザアバタｍ１が検出されたときの、スタッフユーザ用の端末用画像Ｇ１５０を示す。スタッフユーザ用の端末用画像Ｇ１５０には、補助対象のユーザアバタｍ１が検出されたときに、サブ画像Ｇ１５６が出現する。この場合、サブ画像Ｇ１５６には、補助対象のユーザアバタｍ１（ユーザ名「ｆｕｊ」）が写されている。スタッフユーザは、例えば、サブ画像Ｇ１５６をタップすることで、スタッフアバタｍ２をサブ画像Ｇ１５６に係る位置まで瞬間的に移動させることができる。この場合、サブ画像Ｇ１５６が全画面表示となり、図１６に示すような端末用画像Ｇ１６０が、サブ画像Ｇ１５６をタップしたスタッフアバタｍ２（スタッフ名「ｚｕｋ」）に係るスタッフユーザの端末装置２０－Ｃに表示される。端末用画像Ｇ１６０においては、補助対象のユーザアバタｍ１には、対話による補助を必要としている可能性が高いことを示す特徴的な画像部Ｇ１６１が対応付けられている。従って、スタッフユーザは、端末用画像Ｇ１６０に複数のユーザアバタｍ１が含まれている場合でも、補助対象のユーザアバタｍ１を容易に特定できる。なお、ここでは、図１３の位置ＳＰ１４に係る部屋内に位置していたスタッフアバタｍ２に係るスタッフユーザ（スタッフ名「ｚｕｋ」）が、サブ画像Ｇ１５６をタップすることで、スタッフアバタｍ２を第１位置ＳＰ１１へと瞬時に移動させたものとする。

このようにして、スタッフユーザは、補助対象のユーザアバタｍ１（ユーザ名「ｆｕｊ」）を見つけると、自身のスタッフアバタｍ２を補助対象のユーザアバタｍ１（ユーザ名「ｆｕｊ」）のそばに移動させ、対話等により補助情報を伝達できる。上述したように、スタッフユーザ用の端末用画像においては、通常は見えない情報（例えば次室移動条件を満たしていない理由等）が描画される。従って、スタッフユーザは、ユーザ名「ｆｕｊ」のユーザアバタｍ１が次室移動条件を満たしていない理由を把握できるので、その理由に応じた適切な補助情報を伝達できる。ここでは、図１３の位置ＳＰ１４に係る部屋内に位置していたスタッフアバタｍ２に係るスタッフユーザ（スタッフ名「ｚｕｋ」）は、スタッフアバタｍ２を第１位置ＳＰ１１へと瞬時に移動させ、対話により補助情報をユーザ名「ｆｕｊ」の一般ユーザに伝達する（ステップＳ２７）。図１７は、補助情報が伝達されたときの、学生ユーザＢ用の端末用画像Ｇ１７０を示す。端末用画像Ｇ１７０は、図１７に示すように、ヒントを示す画像部Ｇ１７１や、スタッフアバタｍ２（スタッフ名「ｚｕｋ」）に係るスタッフユーザの入力に基づくチャットのテキスト「これがヒントだよ！」を含んでよい。これにより、学生ユーザＢは、次の部屋に進めなかった理由を把握できるとともに、ヒントに基づいて、次室移動条件を満たすような課題等を再提出できる（ステップＳ２８）。

このようにして、学生ユーザＡ及び学生ユーザＢは、各部屋（各コンテンツ提供位置）で、対応する特定のコンテンツの提供を受け、かつ、スタッフユーザからの補助を適宜受けながら、対応する課題をクリアすることで、次の部屋へと順に進んでいく。この間、スタッフユーザにより補助を受けることでスムーズに、例えばゴールである第８位置ＳＰ１８へと、進むことができる。図１８は、ゴールである第８位置ＳＰ１８まで移動できたときの、学生ユーザＢ用の端末用画像Ｇ１８０を示す。端末用画像Ｇ１８０は、図１８に示すように、終了証の画像部Ｇ１８１や、スタッフアバタｍ２（スタッフ名「ｓｔａ」）に係るスタッフユーザの入力に基づくチャットのテキスト「Ｃｏｎｇｒａｔｕｌａｔｉｏｎｓ！」を含んでよい。また、修了証は、今回の成績等が記載されていてよい。なお、このような修了証を得た一般ユーザは、対応するコンテンツ提供用の仮想空間部においてスタッフユーザとして機能できる役割が付与される候補として、上述した抽出処理部１６６により抽出されてもよい。あるいは、このような修了証を得た一般ユーザには、対応するコンテンツ提供用の仮想空間部においてスタッフユーザとして機能できる役割が、上述した役割割当部１６７により自動的に付与されてもよい。

なお、本実施形態では、図１１に示す端末用画像Ｇ１１０に示すように、各スタッフアバタｍ２には、それぞれに対応するスタッフ名（例えば「ｃｈａ」）の表示が対応付けられているが、これに代えて、スタッフアバタｍ２のすべてに「ｓｔａｆｆ」といった表示（共通の可視特徴）が対応付けられてもよい。この場合、「ｓｔａｆｆ」の表示は、例えば「ｓｅｎｉｏｒ ｓｔａｆｆ」といった具合に、権限情報ごとに表示が異なってもよい。この場合、スタッフユーザ用の端末用画像においてだけ、各スタッフアバタｍ２には、それぞれに対応するスタッフ名（例えば「ｃｈａ」）の表示が対応付けられてもよい。すなわち、スタッフユーザ用の端末用画像においては、各スタッフアバタｍ２には、それぞれに対応するスタッフ名（例えば「ｃｈａ」）の表示が対応付けられ、一般ユーザ用の端末用画像においては、各スタッフアバタｍ２には、共通の可視特徴「ｓｔａｆｆ」が対応付けられてもよい。これにより、スタッフユーザ間では、各スタッフアバタｍ２に関する情報（例えばスタッフ名等）を認識できる。

また、本実施形態において、共通の可視特徴に酷似する衣服を着用した一般ユーザ（スタッフユーザになりすます一般ユーザ）の出現を防止するための仕組みが付加されてもよい。このような仕組みは、各一般ユーザがユーザアバタｍ１の衣服を自由にアレンジ（カスタマイズ）できるような仕様である場合に好適である。例えば、サーバ装置１０は、定期的に、画像処理により、共通の可視特徴を有する衣服を着用するアバタを検出し、当該アバタに対応付けられているユーザＩＤの属性が、スタッフユーザであるか否かをチェックしてもよい。これにより、なりすましの一般ユーザの出現に起因してユーザ補助機能が損なわれてしまう可能性を効果的に低減できる。また、スタッフユーザのなりすましを防止する方法として、オフィシャルスタッフ（正規のスタッフユーザ）であるという証明書や腕章のような装身具がスタッフアバタｍ２に対応付けて描画される方法や、他のユーザがそのスタッフユーザを選択すると（タッチやクリックすると）端末用画像においてスタッフユーザである証明表示が描画される方法、又はこれらの任意の組み合わせが、適宜、採用されてもよい。

（スタッフ管理機能に関連した動作例）
次に、図１９を参照して、上述したスタッフ管理機能に関連した動作例について説明する。なお、以下の動作例は、具体的な動作例であるが、上述したスタッフ管理機能に関連した動作は、上述したように、多様な態様で実現可能である。

以下では、一例として、図２Ｂ及び図２Ｄに示した仮想空間に関して、上述したユーザ補助機能に関連した動作例について説明する。

図１９は、上述したスタッフ管理機能に関連した動作例を示すタイミングチャートである。図１９では、区別のために、一般ユーザに係る端末装置２０に対して、符号「２０－Ａ」を付与し、一のスタッフユーザ（スタッフユーザになることができる一般ユーザ）に係る端末装置２０に対して、符号「２０－Ｄ」を付与している。以下では、説明上、端末装置２０－Ｄに係るユーザ（スタッフユーザになることができる一般ユーザ）を、ユーザＤとする。また、図１９において、図面の複雑化防止の都合上、端末装置２０－Ｄから端末装置２０－Ａへの補助情報の送信は、直接的な態様で図示されているが、サーバ装置１０を介して実現されてよい。

まず、ステップＳ６０において、ユーザＤは、端末装置２０－Ｄにおいて、仮想現実アプリケーションを起動し、ついで、ステップＳ６２において、仮想空間内に入り、自身のユーザアバタｍ１を移動させ、ロッカールームに対応する空間部を形成する位置ＳＰ２０２（図２Ｄ参照）付近に至る。

ついで、ステップＳ６４において、ユーザＤは、ロッカールームに対応する空間部を形成する位置ＳＰ２０２への移動（ロッカールームへの入室）を要求する。例えば、ユーザＤは、アバタが所持するセキュリティカード（第２オブジェクトｍ３）を所定箇所にかざすことで、位置ＳＰ２０２への移動を要求してもよい。

サーバ装置１０は、ユーザＤに対応するユーザＩＤと、ユーザデータベース１４０内のユーザ情報（図６のスタッフ可否情報参照）に基づいて、ユーザＤがスタッフユーザになることができる一般ユーザであるか否かの入室判定を行う（ステップＳ６６）。ここでは、ユーザＤは、スタッフユーザになることができる一般ユーザであるので、サーバ装置１０は、入室許可を通知する（ステップＳ６８）。例えば、サーバ装置１０は、ユーザＤに係る端末用画像において、ロッカールームに対応する空間部を形成する位置ＳＰ２０２への移動を制限するドア８５（第２オブジェクトｍ３）が、開状態に描画されるようにすることで、入室許可を通知してもよい。

ついで、ステップＳ７０において、ユーザＤは、位置ＳＰ２０２へ移動し（ロッカールームへ入室し）（ステップＳ７０）、ロッカールームで自身のユーザアバタｍ１の衣服を、私服から制服へと着替える（ステップＳ７２）。すなわち、ユーザＤは、一般ユーザからスタッフユーザへの属性変化要求を、サーバ装置１０に送信する。これに応じて、サーバ装置１０は、ユーザＤの属性を一般ユーザからスタッフユーザに変更する（ステップＳ７４）。この結果、一般ユーザ用の端末用画像やスタッフユーザ用の端末用画像（当該スタッフユーザに係るスタッフアバタｍ２が視野内に存在する場合）においては、当該ユーザＤのアバタは、制服を着用しているスタッフアバタｍ２として描画されることになる（ステップＳ７６）。また、サーバ装置１０は、属性変更に応じてユーザＤの労働時間をカウントするタイマ（労働時間タイマ）を起動する（ステップＳ７８）。なお、労働時間タイマは、ユーザＤからのアクションに基づいて起動されてもよい。例えば、ユーザＤは、自身のアバタが所持するタイムカード（第２オブジェクトｍ３）を所定箇所にかざすことで、労働時間タイマの起動を要求してもよい。

ユーザＤは、スタッフユーザとして、各種の補助情報を一般ユーザに提供する（ステップＳ８０）。これは、例えば、図１０に示した動作例におけるステップＳ１２、ステップＳ１３、ステップＳ２７と同様である。

その後、ユーザＤは、仮想空間内での労働を終えることとし、ロッカールームで自身のアバタの衣服を、制服から私服へと着替える（ステップＳ８２）。すなわち、ユーザＤは、スタッフユーザから一般ユーザへの属性変化要求を、サーバ装置１０に送信する。これに応じて、サーバ装置１０は、ユーザＤの属性をスタッフユーザから一般ユーザに変更する（ステップＳ８４）。この結果、一般ユーザ用の端末用画像やスタッフユーザ用の端末用画像（当該スタッフユーザに係るスタッフアバタｍ２が視野内に存在する場合）においては、当該ユーザＤのアバタは、制服を着用していないユーザアバタｍ１として描画されることになる（ステップＳ８５）。また、サーバ装置１０は、ユーザＤの労働時間をカウントするタイマ（労働時間タイマ）を属性変更に応じて停止させ、労働時間を記録する（ステップＳ８６）。なお、労働時間は、上述したように、スタッフポイント（図７参照）に反映されてよい。また、労働開始時刻と終了時刻が、稼働スタッフ情報９０２（又はスタッフ情報６０２）のテーブルに記録されてもよい。

なお、ここでは、一例として、ユーザＤは、自らの意思（例えば退勤ボタンを押す等の操作）で労働を終えることとしているが、上述したように、第２属性変更部１８０５により強制的に一般ユーザに属性を変更される場合もありうる。この場合、退職や解雇が実現されてもよい。いずれの場合も、上述したように、一般ユーザに属性が変更された途端に、自動的に制服から私服への着替えと、ロッカーやクローゼット内の私服の削除（制服との入れ替え）とが、同時に実現されてよい。また、退職や解雇の場合、スタッフＩＤの削除又は無効化とともに、当該スタッフＩＤに係る各種のアイテムが自動的に削除されてもよい。

その後、サーバ装置１０は、スタッフユーザとしてのユーザＤを評価する（ステップＳ８８）。スタッフユーザの評価については、評価部１８０３に関連して上述したとおりである。そして、サーバ装置１０は、ユーザＤにインセンティブを付与する（ステップＳ９０）。この場合、ユーザＤは、インセンティブを受け取る（ステップＳ９２）ことで、更にスタッフユーザとしてスキルを高める動機付けを得ることができる。

なお、本実施形態において、ユーザＤが仮想現実アプリケーションを起動すると、スタッフユーザとして仮想空間に入るか、一般ユーザとして仮想空間に入るかをユーザＤが選択できてもよい。スタッフユーザになることができる一般ユーザは、スタッフユーザとして仮想空間に入ることができる。この場合、例えば、ユーザＤがスタッフユーザとして仮想空間に入ることを選択すると、ユーザＤのアバタがロッカールームに対応する空間部を形成する位置ＳＰ２０２（図２Ｄ参照）付近、又は、位置ＳＰ２０２に配置されてもよい。あるいは、ユーザＤがスタッフユーザとして仮想空間に入ることを選択すると、ユーザＤのアバタは、制服を着用したスタッフアバタｍ２として仮想空間内に配置されてもよい。

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

例えば、上述した実施形態では、一例として、図６に示すスタッフ情報６０２（テーブル）が例示されているが、これに限られない。例えば、「雇用管理者ＩＤ」のように、当該スタッフの起用／雇用に関する管理やケアを行うユーザのＩＤがユーザテーブル（もしくはそのルーム内のユーザセッション管理テーブル）に設定されてもよい。この場合、雇用管理者ＩＤが付与されるスタッフユーザは、何か問題があった時などに通報する上司として機能でき、例えば、以下のようなユーザであってもよい。
・同一ルーム内の別ユーザ、実際にオンラインにいない場合（すなわち稼働中でない場合）はユーザ管理システムを経由して通知等が可能なユーザ。
・他のユーザ（たとえばゲストユーザや顧客ユーザ）から、当該スタッフユーザの問題を指摘された場合に通報先になる（通報システムとともに人間にも伝わる）ユーザ。
・当該スタッフがヘルプを求めるときに他のユーザに知られずにメッセージングや通知が行えるユーザ。
・階層構造：雇用管理者にもその上司として管理を行う「雇用管理者ＩＤ」が設定されており、スタッフのケアやサポート、ミッションに対するＫＰＩの評価や教育指導などを担当するユーザ。
・仮想化：中間的な管理職は実在のユーザである必要はなく、オンラインに不在、もしくは実ユーザが割り当てられていない場合は、その管理者が代理で通知を受信するユーザ。
この場合、あるスタッフユーザが通報を行いたい場合に、例えば通報先の上司が制服を既に脱いでおり勤務中（稼働中）でない場合は、その上司に通報を行う必要がありうる。この場合、このような情報を利用することで、その上司へのＩＤをたどる仕組みとしてユーザ管理システムを実現できる。例えば、組織表のような情報がユーザ管理システム用のユーザテーブルに別途項目として用意されてもよい。このようなオフライン（非稼働中）であったとしても上司にたどれる仕組みとしてのユーザ管理システムは、システムがスケール化したときに非常に有用となる。

以下に、本願の原出願の出願時の特許請求の範囲に記載された発明を付記する。
［付記１］
仮想空間を描画する空間描画処理部と、
前記仮想空間内で移動可能な複数の移動媒体であって、複数のユーザに対応付けられる複数の移動媒体を描画する媒体描画処理部とを含み、
前記複数の移動媒体は、第１属性のユーザに対応付けられた第１移動媒体と、前記仮想空間内における所定役割が付与されている第２属性のユーザに対応付けられた第２移動媒体とを含み、
前記媒体描画処理部は、前記第１属性のユーザ用又は前記第２属性のユーザ用の表示画像における前記第２移動媒体を、前記第１移動媒体から識別可能な態様で、描画する、情報処理システム。
［付記２］
前記媒体描画処理部は、前記仮想空間内に配置される複数の前記第２移動媒体に対して共通の可視特徴を対応付けて描画する、［付記１］に記載の情報処理システム。
［付記３］
前記共通の可視特徴の変更であって、前記第２属性のユーザのそれぞれによる独自の変更は、禁止される、［付記２］に記載の情報処理システム。
［付記４］
前記共通の可視特徴は、衣服又は装身具を含む、［付記３］に記載の情報処理システム。
［付記５］
一のユーザの属性は、前記第１属性と前記第２属性との間で変化可能である、［付記１から４］のうちのいずれか１項に記載の情報処理システム。
［付記６］
一のユーザの属性が前記第１属性と前記第２属性との間で変化したか否かを判定する第１判定部を更に含み、
前記第１判定部により前記一のユーザの属性が前記第１属性と前記第２属性との間で変化したと判定された場合、前記媒体描画処理部は、前記第１属性のユーザ用又は前記第２属性のユーザ用の表示画像において、前記一のユーザに対応付けられた移動媒体の描画態様を変化させる、［付記５］に記載の情報処理システム。
［付記７］
一のユーザからの入力に基づいて、前記一のユーザの属性を、前記第１属性と前記第２属性との間で変化させる第１属性変更部を更に含む、［付記５又は６］に記載の情報処理システム。
［付記８］
前記入力は、前記媒体描画処理部に、前記第２移動媒体を、前記第１移動媒体から識別可能な態様で、描画させるための所定要求を含み、
前記第１属性変更部は、前記所定要求に基づいて、前記一のユーザの属性を、前記第１属性から前記第２属性に変化させる、［付記７］に記載の情報処理システム。
［付記９］
前記一のユーザの属性が前記第２属性であるときに、前記一のユーザが前記所定役割を果たしているかを評価する評価部と、
前記評価部による評価結果が所定基準を満たしているか否かを判定する第２判定部と、
前記第２判定部により前記所定基準を満たしていないと判定された前記一のユーザの属性を、前記第２属性から前記第１属性に変更する第２属性変更部とを更に含む、［付記５から８］のうちのいずれか１項に記載の情報処理システム。
［付記１０］
前記所定役割は、前記第１属性のユーザに対する各種の補助であって、前記仮想空間内での各種の補助、又は、前記仮想空間内での各種の演出用の操作に関する、［付記１から９］のうちのいずれか１項に記載の情報処理システム。
［付記１１］
前記各種の補助は、前記第１属性のユーザに対する各種の案内、前記仮想空間内で利用又は提供が可能な商品又はサービスの案内又は販売、前記第１属性のユーザからのクレーム対応、及び前記第１属性のユーザに対する各種の注意又は助言のうちの、少なくともいずれか１つを含む、［付記１０］に記載の情報処理システム。
［付記１２］
前記所定役割を果たす際に利用可能な所定ユーザ情報を取得するユーザ情報取得部を更に含み、
前記媒体描画処理部は、前記第２属性のユーザ用の表示画像において、前記第１移動媒体に、前記所定ユーザ情報を対応付けて、描画する、［付記１１］に記載の情報処理システム。
［付記１３］
前記所定ユーザ情報は、前記仮想空間又は他の仮想空間における商品又はサービスに関する過去の利用又は提供履歴、若しくは案内履歴を含む、［付記１２］に記載の情報処理システム。
［付記１４］
前記所定役割を果たしている量に関連するパラメータであって、前記第２属性のユーザのそれぞれに対応付けられたパラメータの値を更新するパラメータ更新部を更に含む、［付記１から１３］のうちのいずれか１項に記載の情報処理システム。
［付記１５］
前記所定役割を果たしている量は、前記第２移動媒体を介して前記仮想空間内で活動した時間を含む、［付記１４］に記載の情報処理システム。
［付記１６］
前記第２移動媒体を介して前記仮想空間内で活動した時間は、労働時間を含み、
前記パラメータ更新部は、一のユーザの属性が前記第２属性に変化した場合、前記一のユーザの労働時間のカウントを開始し、その後、前記一のユーザの属性が前記第１属性に変化した場合、前記一のユーザの労働時間のカウントを終了する、［付記１５］に記載の情報処理システム。
［付記１７］
前記パラメータ更新部により更新される前記パラメータの値に基づいて、前記第２属性のユーザのそれぞれにインセンティブを付与するインセンティブ付与部を更に含む、［付記１４から１６］のうちのいずれか１項に記載の情報処理システム。
［付記１８］
コンピュータにより実行される情報処理方法であって、
仮想空間を描画する空間描画ステップと、
前記仮想空間内で移動可能な複数の移動媒体であって、複数のユーザに対応付けられる複数の移動媒体を描画する媒体描画ステップとを含み、
前記複数の移動媒体は、第１属性のユーザに対応付けられた第１移動媒体と、前記仮想空間内における所定役割が付与されている第２属性のユーザに対応付けられた第２移動媒体とを含み、
前記媒体描画ステップにおいて、前記第１属性のユーザ用の表示画像における前記第２移動媒体を、前記第１移動媒体から識別可能な態様で、描画する、情報処理方法。
［付記１９］
仮想空間を描画する空間描画ステップと、
前記仮想空間内で移動可能な複数の移動媒体であって、複数のユーザに対応付けられる複数の移動媒体を描画する媒体描画ステップとを含む処理を、コンピュータに実行させ、
前記複数の移動媒体は、第１属性のユーザに対応付けられた第１移動媒体と、前記仮想空間内における所定役割が付与されている第２属性のユーザに対応付けられた第２移動媒体とを含み、
前記媒体描画ステップにおいて、前記第１属性のユーザ用の表示画像における前記第２移動媒体を、前記第１移動媒体から識別可能な態様で、描画する、情報処理プログラム。

１ 仮想現実生成システム
３ ネットワーク
１０ サーバ装置
１１ サーバ通信部
１２ サーバ記憶部
１３ サーバ制御部
２０ 端末装置
２１ 端末通信部
２２ 端末記憶部
２３ 表示部
２４ 入力部
２５ 端末制御部
１４０ ユーザデータベース
１４２ アバタデータベース
１４４ コンテンツ情報記憶部
１４６ 空間状態記憶部
１５０ 空間描画処理部
１５２ ユーザアバタ処理部
１５２１ 操作入力取得部
１５２２ ユーザ動作処理部
１５４ スタッフアバタ処理部
１５４１ 操作入力取得部
１５４２ スタッフ動作処理部
１５４４ 補助情報提供部
１５６ 位置／向き情報特定部
１５７ 補助対象検出部
１５８ 描画処理部
１５８１ 端末画像生成部
１５８２ ユーザ情報取得部
１５９ コンテンツ処理部
１６０ 対話処理部
１６０１ 第１対話処理部
１６０２ 第２対話処理部
１６２ 活動制限部
１６４ 条件処理部
１６６ 抽出処理部
１６７ 役割割当部
１６８ 空間情報生成部
１７０ パラメータ更新部
１８０ スタッフ管理部
１８０１ 第１判定部
１８０２ 第１属性変更部
１８０３ 評価部
１８０４ 第２判定部
１８０５ 第２属性変更部
１８０６ インセンティブ付与部
２５０ 補助要求部
２６２ 支援実行部
２６３ 条件変更部
２６４ 役割付与部

Claims (16)

1. 仮想空間を描画する空間描画処理部と、
   ユーザからの、前記仮想空間内における仮想現実の運営に関与する所定役割が付与されていない第１属性から前記仮想空間内における前記所定役割が付与されている第２属性への属性変化要求に基づいて、前記ユーザの属性を前記第１属性から前記第２属性へ変化させる第１属性変更部と、を含み、
   前記属性変化要求は、前記ユーザに関連する情報が所定条件を満たす場合に、実行可能であり、
   前記第２属性のユーザは、前記所定役割に対応する複数種類の権限のうち、少なくとも１つの権限を有する、情報処理システム。
2. 前記属性変化要求は、前記所定条件として、前記第１属性のユーザに対応付けられた第１移動媒体が前記仮想空間内の特定の位置にいるときに、実行可能である、請求項１に記載の情報処理システム。
3. 前記属性変化要求は、前記ユーザに係る前記第１属性から前記第２属性への可否情報において変化可能に設定されている場合に、実行可能である、請求項１又は２に記載の情報処理システム。
4. 前記可否情報は、変化可能に設定されていない場合から変化可能に設定されている場合へ更新可能である、請求項３に記載の情報処理システム。
5. 前記所定役割を果たしている量に関連するパラメータは、前記第２属性のユーザに対応付けられた前記パラメータの値として更新される、請求項１から４のいずれか１項に記載の情報処理システム。
6. 前記所定役割を果たしている量は、前記第２属性のユーザに対応付けられた第２移動媒体を介して前記仮想空間内で活動した時間を含む、請求項５に記載の情報処理システム。
7. 前記第２移動媒体を介して前記仮想空間内で活動した時間は、労働時間を含み、
   前記労働時間は、前記ユーザの属性が前記第１属性から前記第２属性へ変化した場合にカウントが開始され、その後、前記ユーザの属性が前記第２属性から前記第１属性へ変化した場合にカウントが終了される、請求項６に記載の情報処理システム。
8. 前記パラメータの値に基づいて、前記第２属性のユーザにインセンティブが付与される、請求項５から７のいずれか１項に記載の情報処理システム。
9. 前記第２属性のユーザは、少なくとも前記パラメータの値に基づいて、前記所定役割を果たしているかを評価される、請求項５から８のいずれか１項に記載の情報処理システム。
10. 前記複数種類の権限は、権限の種類に応じて、前記第２属性のユーザが行うことができる行為を含む、請求項１に記載の情報処理システム。
11. 前記複数種類の権限の１つは、通常の前記第２属性のユーザに付与される権限である通常権限であり、前記通常権限は、前記仮想空間内で活動する前記第１属性のユーザを支援するための各種補助を行うことができる権限を含む、請求項１又は１０に記載の情報処理システム。
12. 前記複数種類の権限の１つは、通常の前記第２属性のユーザよりも経験を積んだシニアの前記第２属性のユーザに付与される権限である操作権限であり、前記操作権限は、前記仮想空間内で提供されるコンテンツに関連した各種操作を行うことができる権限を含む、請求項１又は１０に記載の情報処理システム。
13. 前記複数種類の権限の１つは、シニアの前記第２属性のユーザよりも上級であって統括する前記第２属性のユーザに付与される権限である統括権限であり、前記統括権限は、前記仮想空間内での前記第２属性のユーザを取りまとめる権限を含む、請求項１又は１０に記載の情報処理システム。
14. 前記仮想空間内で移動可能な移動媒体であって、前記第１属性のユーザに対応付けられた第１移動媒体と、前記第２属性のユーザに対応付けられた第２移動媒体とを描画する媒体描画処理部を更に備え、
    前記媒体描画処理部は、前記ユーザの属性が前記第１属性から前記第２属性へ変化したことを受けて、前記ユーザに対応する移動媒体を前記第２移動媒体として描画する、請求項１に記載の情報処理システム。
15. コンピュータにより実行される情報処理方法であって、
    仮想空間を描画する空間描画ステップと、
    ユーザからの、前記仮想空間内における仮想現実の運営に関与する所定役割が付与されていない第１属性から前記仮想空間内における前記所定役割が付与されている第２属性への属性変化要求に基づいて、前記ユーザの属性を前記第１属性から前記第２属性へ変化させる第１属性変更ステップと、を含み、
    前記属性変化要求は、前記ユーザに関連する情報が所定条件を満たす場合に、実行可能であり、
    前記第２属性のユーザは、前記所定役割に対応する複数種類の権限のうち、少なくとも１つの権限を有する、情報処理方法。
16. 仮想空間を描画する空間描画ステップと、
    ユーザからの、前記仮想空間内における仮想現実の運営に関与する所定役割が付与されていない第１属性から前記仮想空間内における前記所定役割が付与されている第２属性への属性変化要求に基づいて、前記ユーザの属性を前記第１属性から前記第２属性へ変化させる第１属性変更ステップと、を含む処理を、コンピュータに実行させ、
    前記属性変化要求は、前記ユーザに関連する情報が所定条件を満たす場合に、実行可能であり、
    前記第２属性のユーザは、前記所定役割に対応する複数種類の権限のうち、少なくとも１つの権限を有する、情報処理プログラム。