(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022191286
(43)【公開日】2022-12-27
(54)【発明の名称】情報処理システム、情報処理方法、情報処理プログラム
(51)【国際特許分類】
G06T 19/00 20110101AFI20221220BHJP
A63F 13/52 20140101ALI20221220BHJP
A63F 13/79 20140101ALI20221220BHJP
A63F 13/85 20140101ALI20221220BHJP
【FI】
G06T19/00 300A
A63F13/52
A63F13/79
A63F13/85
【審査請求】有
【請求項の数】16
【出願形態】OL
(21)【出願番号】P 2022154421
(22)【出願日】2022-09-28
(62)【分割の表示】P 2020206435の分割
【原出願日】2020-12-14
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVASCRIPT
(71)【出願人】
【識別番号】504437801
【氏名又は名称】グリー株式会社
(74)【代理人】
【識別番号】110002871
【氏名又は名称】弁理士法人坂本国際特許商標事務所
(72)【発明者】
【氏名】白井 暁彦
(57)【要約】
【課題】仮想現実において仮想空間内でのスタッフユーザによる一般ユーザへの各種補助を可能とする。
【解決手段】仮想空間を描画する空間描画処理部150と、ユーザからの、仮想空間内における所定役割が付与されていない第1属性から仮想空間内における所定役割が付与されている第2属性への属性変化要求に基づいて、ユーザの属性を第1属性から第2属性へ変化させる第1属性変更部1802と、を含み、属性変化要求は、ユーザに関連する情報が所定条件を満たす場合に、実行可能である、情報処理システム10が提供される。
【選択図】
図4
【特許請求の範囲】
【請求項1】
仮想空間を描画する空間描画処理部と、
ユーザからの、前記仮想空間内における所定役割が付与されていない第1属性から前記仮想空間内における所定役割が付与されている第2属性への属性変化要求に基づいて、前記ユーザの属性を前記第1属性から前記第2属性へ変化させる第1属性変更部と、を含み、
前記属性変化要求は、前記ユーザに関連する情報が所定条件を満たす場合に、実行可能である、情報処理システム。
【請求項2】
前記属性変化要求は、前記所定条件として、前記第1属性のユーザに対応付けられた第1移動媒体が前記仮想空間内の特定の位置にいるときに、実行可能である、請求項1に記載の情報処理システム。
【請求項3】
前記属性変化要求は、前記ユーザに係る前記第1属性から前記第2属性への可否情報において変化可能に設定されている場合に、実行可能である、請求項1又は2に記載の情報処理システム。
【請求項4】
前記可否情報は、変化可能に設定されていない場合から変化可能に設定されている場合へ更新可能である、請求項3に記載の情報処理システム。
【請求項5】
前記所定役割を果たしている量に関連するパラメータは、前記第2属性のユーザに対応付けられた前記パラメータの値として更新される、請求項1から4のいずれか1項に記載の情報処理システム。
【請求項6】
前記所定役割を果たしている量は、前記第2属性のユーザに対応付けられた第2移動媒体を介して前記仮想空間内で活動した時間を含む、請求項5に記載の情報処理システム。
【請求項7】
前記第2移動媒体を介して前記仮想空間内で活動した時間は、労働時間を含み、
前記労働時間は、前記ユーザの属性が前記第1属性から前記第2属性へ変化した場合にカウントが開始され、その後、前記ユーザの属性が前記第2属性から前記第1属性へ変化した場合にカウントが終了される、請求項6に記載の情報処理システム。
【請求項8】
前記パラメータの値に基づいて、前記第2属性のユーザにインセンティブが付与される、請求項5から7のいずれか1項に記載の情報処理システム。
【請求項9】
前記第2属性のユーザは、少なくとも前記パラメータの値に基づいて、前記所定役割を果たしているかを評価される、請求項5から8のいずれか1項に記載の情報処理システム。
【請求項10】
前記第2属性のユーザは、前記所定役割に対応する複数種類の権限のうち、少なくとも1つの権限を有する、請求項1から8のいずれか1項に記載の情報処理システム。
【請求項11】
前記複数種類の権限の1つは、通常の前記第2属性のユーザに付与される権限である通常権限であり、前記通常権限は、前記仮想空間内で活動する前記第1属性のユーザを支援するための各種補助を行うことができる権限を含む、請求項9に記載の情報処理システム。
【請求項12】
前記複数種類の権限の1つは、通常の前記第2属性のユーザよりも経験を積んだシニアの前記第2属性のユーザに付与される権限である操作権限であり、前記操作権限は、前記仮想空間内で提供されるコンテンツに関連した各種操作を行うことができる権限を含む、請求項9に記載の情報処理システム。
【請求項13】
前記複数種類の権限の1つは、シニアの前記第2属性のユーザよりも上級であって統括する前記第2属性のユーザに付与される権限である統括権限であり、前記統括権限は、前記仮想空間内での前記第2属性のユーザを取りまとめる権限を含む、請求項9に記載の情報処理システム。
【請求項14】
前記仮想空間内で移動可能な移動媒体であって、前記第1属性のユーザに対応付けられた第1移動媒体と、前記第2属性のユーザに対応付けられた第2移動媒体とを描画する媒体描画処理部を更に備え、
前記媒体描画処理部は、前記ユーザの属性が前記第1属性から前記第2属性へ変化したことを受けて、前記ユーザに対応する移動媒体を前記第2移動媒体として描画する、請求項1に記載の情報処理システム。
【請求項15】
コンピュータにより実行される情報処理方法であって、
仮想空間を描画する空間描画ステップと、
ユーザからの、前記仮想空間内における所定役割が付与されていない第1属性から前記仮想空間内における所定役割が付与されている第2属性への属性変化要求に基づいて、前記ユーザの属性を前記第1属性から前記第2属性へ変化させる第1属性変更ステップと、を含み、
前記属性変化要求は、前記ユーザに関連する情報が所定条件を満たす場合に、実行可能である、情報処理方法。
【請求項16】
仮想空間を描画する空間描画ステップと、
ユーザからの、前記仮想空間内における所定役割が付与されていない第1属性から前記仮想空間内における所定役割が付与されている第2属性への属性変化要求に基づいて、前記ユーザの属性を前記第1属性から前記第2属性へ変化させる第1属性変更ステップと、を含む処理を、コンピュータに実行させ、
前記属性変化要求は、前記ユーザに関連する情報が所定条件を満たす場合に、実行可能である、情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、情報処理システム、情報処理方法、情報処理プログラムに関する。
【背景技術】
【0002】
仮想現実映像によるユーザの体験内容に合わせて、ユーザに現実の体感を与えるために、現実のスタッフがユーザに対して直接又は間接的に働きかける仮想現実装置が知られている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記のような従来技術では、現実におけるスタッフからユーザへの働きかけが必要であり、仮想現実において仮想空間内でのスタッフユーザによる一般ユーザへの各種補助を可能とすることが難しい。
【0005】
そこで、1つの側面では、本発明は、仮想現実において仮想空間内でのスタッフユーザによる一般ユーザへの各種補助を可能とすることを目的とする。
【課題を解決するための手段】
【0006】
1つの側面では、仮想空間を描画する空間描画処理部と、ユーザからの、前記仮想空間内における所定役割が付与されていない第1属性から前記仮想空間内における所定役割が付与されている第2属性への属性変化要求に基づいて、前記ユーザの属性を前記第1属性から前記第2属性へ変化させる第1属性変更部と、を含み、前記属性変化要求は、前記ユーザに関連する情報が所定条件を満たす場合に、実行可能である、情報処理システムが提供される。
【発明の効果】
【0007】
1つの側面では、本発明によれば、仮想現実において仮想空間内でのスタッフユーザによる一般ユーザへの各種補助が可能となる。
【図面の簡単な説明】
【0008】
【
図1】本実施形態に係る仮想現実生成システムのブロック図である。
【
図2A】仮想現実生成システムにより生成可能な仮想現実の一例の説明図である。
【
図2B】仮想現実生成システムにより生成可能な仮想現実の他の一例の説明図である。
【
図2C】仮想現実生成システムにより生成可能な仮想現実の更なる他の一例の説明図である。
【
図2D】仮想現実生成システムにより生成可能な仮想現実の更なる他の一例の説明図である。
【
図3】仮想空間内に位置するユーザアバタの画像の説明図である。
【
図4】ユーザ補助機能に関連したサーバ装置の機能ブロック図の一例である。
【
図5】ユーザ補助機能に関連した端末装置(譲受側の端末装置)の機能ブロック図の一例である。
【
図6】ユーザデータベース内のデータの説明図である。
【
図7】アバタデータベース内のデータの説明図である。
【
図8】コンテンツ情報記憶部内のデータの説明図である。
【
図10】ユーザ補助機能に関連した動作例を示すタイミングチャートである。
【
図11】一場面での端末用画面の一例を示す図である。
【
図12】他の一場面での端末用画面の一例を示す図である。
【
図13】ある時点でのコンテンツ提供用の仮想空間部内の状態を示す図である。
【
図14】更なる他の一場面での端末用画面の一例を示す図である。
【
図15】更なる他の一場面での端末用画面の一例を示す図である。
【
図16】更なる他の一場面での端末用画面の一例を示す図である。
【
図17】更なる他の一場面での端末用画面の一例を示す図である。
【
図18】更なる他の一場面での端末用画面の一例を示す図である。
【
図19】スタッフ管理機能に関連した動作例を示すタイミングチャートである。
【発明を実施するための形態】
【0009】
以下、本発明の実施形態について図面を参照して説明する。
【0010】
(仮想現実生成システムの概要)
図1を参照して、本発明の一実施形態に係る仮想現実生成システム1の概要について説明する。
図1は、本実施形態に係る仮想現実生成システム1のブロック図である。仮想現実生成システム1は、サーバ装置10と、1つ以上の端末装置20と、を備える。
図1では簡便のため、3つの端末装置20を図示しているが、端末装置20の数は2つ以上であればよい。
【0011】
サーバ装置10は、例えば1つ以上の仮想現実を提供する運営者が管理するサーバ等の情報処理システムである。端末装置20は、例えば携帯電話、スマートフォン、タブレット端末、PC(Personal Computer)、ヘッドマウントディスプレイ、又はゲーム装置等の、ユーザによって使用される情報処理システムである。端末装置20は、典型的にはユーザごとに異なる態様で、複数がサーバ装置10にネットワーク3を介して接続されうる。
【0012】
端末装置20は、本実施形態に係る仮想現実アプリケーションを実行可能である。仮想現実アプリケーションは、ネットワーク3を介してサーバ装置10や所定のアプリケーション配信サーバから端末装置20に受信されてもよく、あるいは端末装置20に備えられた記憶装置又は端末装置20が読取可能なメモリカード等の記憶媒体にあらかじめ記憶されていてもよい。サーバ装置10及び端末装置20は、ネットワーク3を介して通信可能に接続される。例えば、サーバ装置10及び端末装置20が協動して、仮想現実に関する多様な処理を実行する。
【0013】
なお、ネットワーク3は、無線通信網や、インターネット、VPN(Virtual Private Network)、WAN(Wide Area Network)、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでよい。
【0014】
ここで、本実施形態に係る仮想現実の概要について説明する。本実施形態に係る仮想現実は、例えば教育、旅行、ロールプレイング、シミュレーション、ゲームやコンサートのようなエンターテインメント等、任意の現実に対する仮想現実等であって、仮想現実の実行に伴い、アバタのような仮想現実媒体が用いられる。例えば、本実施形態に係る仮想現実は、3次元の仮想空間と、当該仮想空間内に登場する各種の仮想現実媒体と、当該仮想空間内で提供される各種のコンテンツとにより実現される。
【0015】
仮想現実媒体は、仮想現実に使用される電子データであり、例えば、カード、アイテム、ポイント、サービス内通貨(又は仮想現実内通貨)、チケット、キャラクタ、アバタ、パラメータ等、任意の媒体を含む。また、仮想現実媒体は、レベル情報、ステータス情報、パラメータ情報(体力値及び攻撃力等)又は能力情報(スキル、アビリティ、呪文、ジョブ等)のような、仮想現実関連情報であってもよい。また、仮想現実媒体は、ユーザによって仮想現実内で取得、所有、使用、管理、交換、合成、強化、売却、廃棄、又は贈与等され得る電子データであるが、仮想現実媒体の利用態様は本明細書で明示されるものに限られない。
【0016】
本実施形態では、ユーザは、後述するユーザアバタm1(第1移動媒体の一例)を介して仮想空間内で活動する一般ユーザ(第1属性のユーザの一例)と、後述するスタッフアバタm2(第2移動媒体の一例)を介して仮想空間内で活動するスタッフユーザ(第2属性のユーザの一例)とを含む。なお、以下では、ユーザアバタm1とスタッフアバタm2とを特に区別しない場合は、単に「アバタ」と称する場合がある。
【0017】
一般ユーザは、仮想現実生成システム1の運営に関与しないユーザであり、スタッフユーザは、仮想現実生成システム1の運営に関与するユーザである。スタッフユーザは、仮想現実内において一般ユーザの各種補助等を行う役割(エージェント機能)を有する。スタッフユーザには、例えば運営側との契約に基づいて、所定の給与が支払われてよい。なお、給与は、通貨や暗号資産等のような、任意の形態であってよい。以下では、特に言及しない限り、ユーザとは、一般ユーザとスタッフユーザの双方を指す。
【0018】
また、ユーザは、更にゲストユーザを含んでもよい。ゲストユーザは、後述するコンテンツ(サーバ装置10が提供するコンテンツ)として機能するゲストアバタを操作するアーティストやインフルエンサー等であってよい。なお、スタッフユーザの一部は、ゲストユーザとなる場合があってもよい。
【0019】
本実施形態では、スタッフユーザは、基本的に、一般ユーザになることができる。換言すると、一般ユーザは、スタッフユーザになることができる一般ユーザと、スタッフユーザになることができない一般ユーザとを含む。なお、スタッフユーザの中には、スタッフユーザにしかなれないユーザが含まれてもよい。
【0020】
サーバ装置10が提供するコンテンツ(仮想現実で提供されるコンテンツ)の種類や数は、任意であるが、本実施形態では、一例として、サーバ装置10が提供するコンテンツは、各種の映像のようなデジタルコンテンツを含んでよい。映像は、リアルタイムの映像であってもよいし、非リアルタイムの映像であってもよい。また、映像は、実画像に基づく映像であってもよいし、CG(Computer Graphics)に基づく映像であってもよい。映像は、情報提供用の映像であってよい。この場合、映像は、特定のジャンルの情報提供サービス(旅や、住まい、食品、ファッション、健康、美容等に関する情報提供サービス)、特定のユーザによる放送サービス(例えばYoutube(登録商標))等に関するものであってよい。
【0021】
また、本実施形態では、一例として、サーバ装置10が提供するコンテンツは、後述するスタッフユーザからの指導やアドバイス等を含んでよい。例えば、ダンスのレッスンに係る仮想現実で提供されるコンテンツとして、ダンスの先生からの指導やアドバイス等を含んでよい。この場合、ダンスの先生がスタッフユーザとなり、生徒が一般ユーザとなり、仮想現実において生徒が先生から個別的に指導を受けることができる。
【0022】
また、他の実施形態では、サーバ装置10が提供するコンテンツは、一人以上のスタッフユーザやゲストユーザによるそれぞれのスタッフアバタm2やゲストアバタを介した各種のパフォーマンスやトークショー、会合、集会等であってもよい。
【0023】
仮想現実におけるコンテンツの提供態様は、任意であり、例えば、コンテンツが映像である場合、仮想空間内の表示装置(仮想現実媒体)のディスプレイ上に、映像を描画することで、当該コンテンツの提供が実現されてもよい。なお、仮想空間内の表示装置は、任意の形態であり、仮想空間内に設置されるスクリーンや、仮想空間内に設置される大画面ディスプレイ、仮想空間内で携帯端末のディスプレイ等であってよい。
【0024】
(サーバ装置の構成)
サーバ装置10の構成について具体的に説明する。サーバ装置10は、サーバコンピュータにより構成される。サーバ装置10は、複数台のサーバコンピュータにより協動して実現されてもよい。例えば、サーバ装置10は、各種のコンテンツを提供するサーバコンピュータや、各種の認証サーバを実現するサーバコンピュータ等により協動して実現されてもよい。また、サーバ装置10は、Webサーバを含んでよい。この場合、後述する端末装置20の機能の一部は、Webサーバから受領したHTML文書やそれに付随する各種プログラム(Javascript)をブラウザが処理することによって実現されてもよい。
【0025】
サーバ装置10は、サーバ通信部11と、サーバ記憶部12と、サーバ制御部13と、を備える。
【0026】
サーバ通信部11は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。サーバ通信部11は、例えば無線LAN(Local Area Network)通信モジュール又は有線LAN通信モジュール等を含んでもよい。サーバ通信部11は、ネットワーク3を介して、端末装置20との間で情報を送受信可能である。
【0027】
サーバ記憶部12は、例えば記憶装置であって、仮想現実に係る各種処理に必要な種々の情報及びプログラムを記憶する。例えばサーバ記憶部12は、仮想現実アプリケーションを記憶する。
【0028】
また、サーバ記憶部12は、仮想空間を描画するためのデータ、例えば建物のような屋内の空間や、屋外の空間の画像等を記憶する。なお、仮想空間を描画するためのデータは、仮想空間ごとに複数種類用意され、使い分けられてもよい。
【0029】
また、サーバ記憶部12は、3次元の仮想空間内に配置された種々のオブジェクトに投影(テクスチャマッピング)するための種々の画像(テクスチャ画像)を記憶する。
【0030】
例えば、サーバ記憶部12は、各ユーザに対応付けられる仮想現実媒体としてのユーザアバタm1の描画情報を記憶する。仮想空間内にユーザアバタm1は、ユーザアバタm1の描画情報に基づいて描画される。
【0031】
また、サーバ記憶部12は、各スタッフユーザに対応付けられる仮想現実媒体としてのスタッフアバタm2の描画情報を記憶する。仮想空間内にスタッフアバタm2は、スタッフアバタm2の描画情報に基づいて描画される。
【0032】
また、サーバ記憶部12は、例えば建物、壁、樹木、又はNPC(Non Player Character)等のような、ユーザアバタm1やスタッフアバタm2とは異なる各種のオブジェクトに係る描画情報を記憶する。仮想空間内に各種のオブジェクトは、かかる描画情報に基づいて描画される。
【0033】
以下、ユーザアバタm1やスタッフアバタm2とは異なる任意の仮想現実媒体(例えば建物、壁、樹木、又はNPC等)に対応するオブジェクトであって、仮想空間内に描画されたオブジェクトを第2オブジェクトm3とも称する。なお、本実施形態では、第2オブジェクトは、仮想空間内で固定されたオブジェクトや、仮想空間内で移動可能なオブジェクト等を含んでもよい。また、第2オブジェクトは、仮想空間内に常に配置されるオブジェクトや、所定の条件が満たされた場合にだけ配置されるオブジェクト等を含んでもよい。
【0034】
サーバ制御部13は、専用のマイクロプロセッサ又は特定のプログラムを読み込むことにより特定の機能を実現するCPU(Central Processing Unit)や、GPU(Graphics Processing Unit)等を含んでよい。例えばサーバ制御部13は、端末装置20と協動して、端末装置20の表示部23に対するユーザ操作に応じて仮想現実アプリケーションを実行する。また、サーバ制御部13は、仮想現実に関する多様な処理を実行する。
【0035】
例えば、サーバ制御部13は、仮想空間(画像)とともにユーザアバタm1やスタッフアバタm2等を描画し、表示部23に表示させる。また、サーバ制御部13は、所定のユーザ操作に応じて、仮想空間内においてユーザアバタm1やスタッフアバタm2を移動させる。サーバ制御部13の具体的な処理の詳細は後述する。
【0036】
(端末装置の構成)
端末装置20の構成について説明する。
図1に示すように、端末装置20は、端末通信部21と、端末記憶部22と、表示部23と、入力部24と、端末制御部25とを備える。
【0037】
端末通信部21は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。端末通信部21は、例えばLTE(Long Term Evolution)(登録商標)や、LTE-A(LTE-Advanced)、第五世代移動通信システム、UMB(Ultra Mobile Broadband)等のモバイル通信規格に対応する無線通信モジュール、無線LAN通信モジュール、又は有線LAN通信モジュール等を含んでもよい。端末通信部21は、ネットワーク3を介して、サーバ装置10との間で情報を送受信可能である。
【0038】
端末記憶部22は、例えば一次記憶装置及び二次記憶装置を含む。例えば端末記憶部22は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。端末記憶部22は、サーバ装置10から受信する、仮想現実の処理に用いられる種々の情報及びプログラムを記憶する。仮想現実の処理に用いられる情報及びプログラムは、端末通信部21を介して外部装置から取得されてもよい。例えば、仮想現実アプリケーションプログラムが、所定のアプリケーション配信サーバから取得されてもよい。以下、アプリケーションプログラムを、単にアプリケーションともいう。また例えば、上述したユーザに関する情報及他のユーザの仮想現実媒体に関する情報等の一部又は全部が、サーバ装置10から取得されてもよい。
【0039】
表示部23は、例えば液晶ディスプレイ又は有機EL(Electro-Luminescence)ディスプレイ等の表示デバイスを含む。表示部23は、多様な画像を表示可能である。表示部23は、例えばタッチパネルで構成され、多様なユーザ操作を検出するインタフェースとして機能する。なお、表示部23は、ヘッドマウントディスプレイの形態であってもよい。
【0040】
入力部24は、例えば表示部23と一体的に設けられたタッチパネルを含む入力インタフェースを含む。入力部24は、端末装置20に対するユーザ入力を受付可能である。また、入力部24は、物理キーを含んでもよいし、マウス等のようなポインティングデバイスをはじめとする任意の入力インタフェースを更に含んでもよい。また、入力部24は、音声入力やジェスチャ入力のような、非接触型のユーザ入力を受付可能であってもよい。なお、ジェスチャ入力には、ユーザの身体の動きを検出するためのセンサ(画像センサや、加速度センサ、距離センサ等)や、センサ技術やカメラを統合した専用モーションキャプチャー、ジョイパッドのようなコントローラ等)が利用されてもよい。
【0041】
端末制御部25は、1つ以上のプロセッサを含む。端末制御部25は、端末装置20全体の動作を制御する。
【0042】
端末制御部25は、端末通信部21を介して情報の送受信を行う。例えば、端末制御部25は、仮想現実に係る各種処理に用いられる種々の情報及びプログラムを、サーバ装置10及び他の外部サーバの少なくとも一方から受信する。端末制御部25は、受信された情報及びプログラムを、端末記憶部22に記憶する。例えば、端末記憶部22には、Webサーバに接続するためのブラウザ(インターネットブラウザ)が格納されてよい。
【0043】
端末制御部25は、ユーザの操作に応じて仮想現実アプリケーションを起動する。端末制御部25は、サーバ装置10と協動して、仮想現実に係る各種処理を実行する。例えば、端末制御部25は、仮想空間の画像を表示部23に表示させる。画面上には、例えばユーザ操作を検出するGUI(Graphic User Interface)が表示されてもよい。端末制御部25は、入力部24を介して、画面に対するユーザ操作を検出可能である。例えば端末制御部25は、ユーザのタップ操作、ロングタップ操作、フリック操作、及びスワイプ操作等を検出可能である。タップ操作は、ユーザが指で表示部23に触れ、その後に指を離す操作である。端末制御部25は、操作情報をサーバ装置10に送信する。
【0044】
(仮想現実の例)
サーバ制御部13は、端末装置20と協動して、表示部23上に仮想空間の画像を表示し、仮想現実の進行やユーザの操作に応じて仮想空間の画像を更新していく。本実施形態では、サーバ制御部13は、端末装置20と協動して、3次元の仮想空間に配置されるオブジェクトを、仮想空間に配置された仮想カメラから視た表現で描画する。
【0045】
なお、以下で説明する描画処理は、サーバ制御部13により実現されるが、他の実施形態では、以下で説明する描画処理の一部又は全部がサーバ制御部13により実現されてもよい。例えば、以下の説明において、端末装置20に表示される仮想空間の画像の少なくとも一部を、サーバ装置10が生成したデータに基づいて端末装置20に表示させるウェブ表示とし、画面の少なくとも一部を、端末装置20にインストールされているネイティブアプリケーションによって表示させるネイティブ表示としてもよい。
【0046】
図2Aから
図2Dは、仮想現実生成システム1により生成可能な仮想現実のいくつかの例の説明図である。
【0047】
図2Aは、旅行に係る仮想現実の説明図であり、仮想空間を平面視で示す概念図である。この場合、仮想空間内には、入場用チュートリアルのコンテンツを視聴する位置SP1と、ゲート付近の位置SP2とが設定される。
図2Aでは、二人の別々のユーザに対応付けられた、ユーザアバタm1が示されている。また、
図2A(
図2B以降も同様)には、スタッフアバタm2も併せて示されている。
【0048】
二人のユーザは、仮想現実で一緒に旅行に行くことを決定し、それぞれのユーザアバタm1を介して、仮想空間内に入る。そして、二人のユーザは、それぞれのユーザアバタm1を介して、位置SP1で入場用チュートリアルのコンテンツを視聴し(矢印R1参照)、位置SP2に至り(矢印R2参照)、その後、ゲートを通り(矢印R3参照)、飛行機(第2オブジェクトm3)に搭乗する。なお、入場用チュートリアルのコンテンツは、入場方法や仮想空間の利用の際の注意事項等を含んでもよい。そして、飛行機が離陸して、所望の目的地に至る(矢印R4参照)。この間、二人のユーザは、それぞれの端末装置20の表示部23を介して、仮想現実を体験できる。例えば、
図3には、所望の目的地に係る仮想空間内に位置するユーザアバタm1の画像G300が示される。このような画像G300は、当該ユーザアバタm1に係るユーザの端末装置20に表示されてよい。この場合、ユーザは、ユーザアバタm1(ユーザ名“fuj”が付与されている)を介して仮想空間内を移動し、観光等を行うことができる。
【0049】
図2Bは、教育に係る仮想現実の説明図であり、仮想空間を平面視で示す概念図である。この場合も、仮想空間内には、入場用チュートリアルのコンテンツを視聴する位置SP1と、ゲート付近の位置SP2とが設定される。
図2Bでは、二人の別々のユーザに対応付けられた、ユーザアバタm1が示されている。
【0050】
二人のユーザは、仮想現実で一緒に特定の教育を受けることを決定し、それぞれのユーザアバタm1を介して、仮想空間内に入る。そして、二人のユーザは、それぞれのユーザアバタm1を介して、位置SP1で入場用チュートリアルのコンテンツを視聴し(矢印R11参照)、位置SP2に至り(矢印R12参照)、その後、ゲートを通り(矢印R13参照)、第1位置SP11に至る。第1位置SP11では、特定の第1コンテンツが提供される。次に、二人のユーザは、それぞれのユーザアバタm1を介して、第2位置SP12に至り(矢印R14参照)、特定の第2コンテンツの提供を受け、ついで、第3位置SP13に至り(矢印R15参照)、特定の第3コンテンツの提供を受け、以下、同様である。特定の第2コンテンツは、特定の第1コンテンツの提供を受けた後に提供されると習得効果が高くなり、特定の第3コンテンツは、特定の第2コンテンツの提供を受けた後に提供されると習得効果が高くなり、以下同様である。
【0051】
例えば、教育が、ある3Dモデリング用のソフトウェアに関する場合、第1コンテンツは、当該ソフトウェアのインストールリンク画像等を含み、第2コンテンツは、アドオンのインストールリンク動画等を含み、第3コンテンツは、初期設定用動画を含み、第4コンテンツは、基本操作用動画を含む、といった具合であってよい。また、複数のユーザが同一ルームに存在する場合、同一の動画コンテンツを同一タイミングで再生してもよい(再生タイムコードを双方のクライアント側に送信する)。また、同期再生せずに、個々のユーザで異なる動画シーク状態にすることもできる。各ユーザは端末に接続されたカメラをつかい、顔画像をリアルタイム送信することができる。また、自分のコンピュータのデスクトップを表示したり、別のアプリケーションの画面を相互に配信することもできる(アプリ学習を隣に並べて手伝ってもらうことができる)。
【0052】
図2Bに示す例では、各ユーザ(例えば生徒)は、第1位置SP11から第8位置SP18まで順にユーザアバタm1を介して移動して、各種のコンテンツの提供を順に受けることで、高い習得効果が得られる態様で特定の教育を受けることができる。あるいは、各種のコンテンツは、クイズ等の課題であってもよく、この場合、
図2Bに示す例では、双六や脱出ゲームのようなゲームを提供できる。
【0053】
図2Cは、レッスンに係る仮想現実の説明図であり、仮想空間を平面視で示す概念図である。この場合も、仮想空間内には、入場用チュートリアルのコンテンツを視聴する位置SP1と、ゲート付近の位置SP2とが設定される。
図2Cでは、二人の別々のユーザに対応付けられた、ユーザアバタm1が示されている。
【0054】
二人のユーザは、仮想現実で一緒に特定のレッスンを受けることを決定し、それぞれのユーザアバタm1を介して、仮想空間内に入る。そして、二人のユーザは、それぞれのユーザアバタm1を介して、位置SP1で入場用チュートリアルのコンテンツを視聴し(矢印R21参照)、位置SP2に至り(矢印R22参照)、その後、ゲートを通り(矢印R23参照)、位置SP20に至る。位置SP20は、例えば円形の周壁W2で囲まれた領域のうちの、各ステージに対応する位置SP21、SP22、SP23等を除くフリースペース内の各位置に対応する。ユーザは、それぞれのユーザアバタm1を介して、第1ステージに対応する第1位置SP21に至ると(矢印R24参照)、第1位置SP21では、レッスン用の第1コンテンツの提供を受ける。また、同様に、ユーザは、それぞれのユーザアバタm1を介して、第2ステージに対応する第2位置SP22に至ると(矢印R25参照)、第2位置SP22では、レッスン用の第2コンテンツの提供を受け、第3ステージに対応する第3位置SP23に至ると(矢印R26参照)、第3位置SP23では、レッスン用の第3コンテンツの提供を受けることができる。
【0055】
例えばレッスンがゴルフのレッスンである場合、レッスン用の第1コンテンツは、ユーザのスイングの改善点を解説するための映像であってよく、レッスン用の第2コンテンツは、プロゴルファーであるスタッフユーザによる見本スイングの実技であり、レッスン用の第3コンテンツは、ユーザのスイングの実技に対するプロゴルファーであるスタッフユーザによるアドバイスである。なお、スタッフユーザによる見本スイングの実技は、スタッフアバタm2により実現され、ユーザのスイングの実技は、ユーザアバタm1により実現される。例えば、スタッフユーザが実際にスイングの動きを行うと、その動きのデータ(例えばジェスチャ入力データ)に基づいて、その動きがスタッフアバタm2の動きにそのまま反映される。スタッフユーザによるアドバイスは、チャット等により実現されてよい。このようにして、各ユーザは、例えば自宅等で、友人とともに、仮想現実で一緒に各種のレッスンを先生(この場合、プロゴルファー)から、十分かつ必要な進度、深度で、受けることができる。
【0056】
このようにして、本実施形態では、
図2Aから
図2Cで例示したように、仮想現実において、ユーザは、ユーザアバタm1を介して、各コンテンツ提供位置に至ると、各コンテンツ提供位置に対応付けられた各コンテンツの提供を、各ユーザの必要なタイミング及び視聴形態で受けることができる。
【0057】
図2Dは、スタッフユーザに関連した仮想現実の説明図であり、スタッフルームに係る仮想空間80を平面視で示す概念図である。
図2Dに示す例では、スタッフユーザ用の仮想空間80は、カンファレンスルームに対応する空間部を形成する位置SP200と、バックヤードに対応する空間部を形成する位置SP201と、ロッカールームに対応する空間部を形成する位置SP202とを含む。なお、各空間部は、壁86に対応する第2オブジェクトm3により仕切られ、ドア85に対応する第2オブジェクトm3を開閉することで、入室や退室が可能であってよい。
【0058】
カンファレンスルームに対応する空間部には、机81(第2オブジェクトm3)や椅子82(第2オブジェクトm3)が配置され、バックヤードに対応する空間部には、商品83(m3)が保管され、ロッカールームに対応する空間部には、ロッカー84(第2オブジェクトm3)が配置されている。ロッカー84には、後述する制服(第2オブジェクトm3)が保管されてよく、スタッフユーザになることができるユーザは、ロッカールームで自身のアバタに制服を着用させることで、スタッフユーザへと変化できる。なお、スタッフユーザ用の仮想空間80の間取り等は多様でありえ、スタッフユーザの数等に応じて適宜設定されてよい。
【0059】
このようなスタッフユーザ用の仮想空間80は、
図2Aから
図2Cに示した仮想空間に隣接して配置されてもよい。この場合、例えば、
図2Aに示した仮想空間内で各種の補助を行うスタッフユーザは、
図2Aに示した仮想空間に隣接して配置される仮想空間80を利用できる。
【0060】
ところで、仮想空間で実現できることが多様化したり、仮想空間内の構造(複数のコンテンツの提供を受ける各位置のレイアウト等)が複雑化したりすると、仮想空間の魅力を高めることができる反面、ルールが複雑化しやすくなる。この場合、ユーザは、かかるルールに慣れるまで苦労したり、あるいは、うまくいかないことがあると、解決できずに嫌になってしまったりする可能性が高くなりやすい。
【0061】
この点、ルール等に関するチュートリアルを仮想空間内に貼り付けることで、ある程度、ユーザによる仮想空間内での円滑な活動が可能となることが期待できるが、仮想空間で実現できること等の多様化に伴い、チュートリアルの数が増加すると、却って利便性を損なうおそれもある。
【0062】
これに対して、本実施形態では、仮想現実生成システム1は、一般ユーザに対して、スタッフアバタm2を介して各種補助を行う補助機能(以下、「ユーザ補助機能」とも称する)を有する。これにより、比較的複雑な仮想空間においても、利便性の高い態様でユーザの円滑な活動を補助できる。このようなユーザ補助機能は、仮想現実において仮想空間内でのスタッフアバタm2(スタッフユーザ)の各種の活動に係る対価を発生させる仕組みがあると、更に有用となる。
【0063】
そこで、本実施形態では、仮想現実生成システム1は、以下で詳説するように、更に、仮想現実において仮想空間内でのスタッフアバタm2(スタッフユーザ)の各種の活動であって、ユーザ補助機能に係る各種の活動を適切に評価できる機能(以下、「スタッフ管理機能」とも称する)を有する。かかるスタッフ管理機能を有することで、仮想現実において仮想空間内でのスタッフアバタm2(スタッフユーザ)の各種の活動に係る対価を適切に発生させることができる。
【0064】
以下では、サーバ装置10が、ユーザ補助機能及びスタッフ管理機能を実現することで、情報処理システムの一例を実現するが、後述するように、特定の一の端末装置20の各要素(
図1の端末通信部21~端末制御部25参照)が、情報処理システムの一例を実現してもよいし、複数の端末装置20が、協動して情報処理システムの一例を実現してもよい。また、サーバ装置10と1つ以上の端末装置20が、協動して情報処理システムの一例を実現してもよい。
【0065】
(ユーザ補助機能及びスタッフ管理機能の詳細)
図4は、ユーザ補助機能に関連したサーバ装置10の機能ブロック図の一例である。
図5は、ユーザ補助機能に関連した端末装置20(譲受側の端末装置20)の機能ブロック図の一例である。
図6は、ユーザデータベース140内のデータの説明図である。
図7は、アバタデータベース142内のデータの説明図である。
図8は、コンテンツ情報記憶部144内のデータの説明図である。
図9は、空間状態記憶部146内のデータの説明図である。なお、
図6から
図9において、“***”は、何らかの情報が格納されている状態を表し、“-”は、情報が格納されていない状態を表し、“・・・”は同様の繰り返しを表す。
【0066】
サーバ装置10は、
図4に示すように、ユーザデータベース140と、アバタデータベース142と、コンテンツ情報記憶部144と、空間状態記憶部146と、空間描画処理部150と、ユーザアバタ処理部152と、スタッフアバタ処理部154と、位置/向き情報特定部156と、補助対象検出部157と、描画処理部158と、コンテンツ処理部159と、対話処理部160と、活動制限部162と、条件処理部164と、抽出処理部166と、役割割当部167と、空間情報生成部168と、パラメータ更新部170と、スタッフ管理部180と、を含む。なお、以下で説明するサーバ装置10の機能の一部又は全部は、適宜、端末装置20により実現されてもよい。また、ユーザデータベース140から空間状態記憶部146の区分けや、空間描画処理部150からパラメータ更新部170の区分けは、説明の都合上であり、一部の機能部が、他の機能部の機能を実現してもよい。例えば、空間描画処理部150、ユーザアバタ処理部152、描画処理部158、位置/向き情報特定部156、コンテンツ処理部159、対話処理部160、及び空間情報生成部168の各機能は、端末装置20により実現されてもよい。また、例えば、ユーザデータベース140内のデータの一部又は全部は、アバタデータベース142内のデータに統合されてもよいし、別のデータベースに格納されてもよい。
【0067】
なお、ユーザデータベース140から空間状態記憶部146は、
図1に示したサーバ記憶部12により実現でき、空間描画処理部150からパラメータ更新部170は、
図1に示したサーバ制御部13により実現できる。また、空間描画処理部150からパラメータ更新部170のうちの一部(端末装置20との通信を行う機能部)は、
図1に示したサーバ制御部13とともにサーバ通信部11により実現できる。
【0068】
ユーザデータベース140には、ユーザ情報が格納される。
図6に示す例では、ユーザ情報は、一般ユーザに係るユーザ情報600と、スタッフユーザに係るスタッフ情報602とを含む。
【0069】
ユーザ情報600は、各ユーザIDに、ユーザ名、認証情報、ユーザアバタID、位置/向き情報、スタッフ可否情報、購買アイテム情報、購買関連情報等が対応付けられる。ユーザ名は、一般ユーザが自身で登録した名前であり、任意である。認証情報は、一般ユーザが正当な一般ユーザであることを示すための情報であり、例えばパスワードや、メールアドレス、生年月日、合言葉、生体情報等を含んでよい。ユーザアバタIDは、ユーザアバタを特定するためのIDである。位置/向き情報は、ユーザアバタm1の位置情報と向き情報とを含む。向き情報は、ユーザアバタm1の顔の向きを表す情報であってよい。なお、位置/向き情報等は、一般ユーザからの操作入力に応じて、動的に変化しうる情報である。位置/向き情報に加えて、ユーザアバタm1の手足等の動きを表す情報や、顔の表情(例えば、口の動き)、顔や頭部の向きや視線方向(例えば、眼球の向き)、レーザーポインターのような空間内の向きや座標を示すオブジェクト等を表す情報を含んでもよい。購買アイテム情報は、仮想空間内で販売される商品やサービスのうちの、一般ユーザが購買した商品やサービスを示す情報であってよい。
【0070】
スタッフ可否情報は、対応する一般ユーザがスタッフユーザになることができるか否かを表す情報である。スタッフ可否情報は、スタッフユーザになることができる一般ユーザに対しては、スタッフユーザであるときのスタッフIDを表してもよい。
【0071】
購買アイテム情報は、仮想空間内で販売される商品やサービスのうちの、一般ユーザが購買した商品やサービスを示す情報(すなわち、商品又はサービスに関する過去の利用又は提供履歴)であってよい。利用又は提供履歴は、利用又は提供された日時や場所を含んでよい。購買関連情報は、仮想空間内で販売される商品やサービスのうちの、その説明や宣伝、勧誘等を受けた商品やサービスを示す情報(すなわち、商品又はサービスに関する過去の案内履歴)であってよい。購買アイテム情報及び/又は購買関連情報は、特定の一の仮想空間に関する情報であってもよいし、複数の仮想空間に関する情報であってもよい。
【0072】
なお、仮想空間内で販売される商品は、仮想空間内で利用又は提供が可能な商品であってよく、仮想空間内で提供されるコンテンツに応じて適合されてもよい。例えば、仮想空間内で提供されるコンテンツがコンサートである場合、仮想空間内で販売される商品は、双眼鏡であってもよい。また、仮想空間内で販売されるサービスは、仮想空間内で利用又は提供が可能なサービスであってよく、仮想空間内でのコンテンツの提供を含んでよい。また、仮想空間内で販売されるサービスは、仮想空間内で提供されるコンテンツに応じて適合されてもよい。例えば、仮想空間内で提供されるコンテンツがコンサートである場合、仮想空間内で販売されるサービスは、アーティストのアバタとの交流(握手や写真撮影等)であってもよい。
【0073】
スタッフ情報602は、各スタッフIDに、スタッフ名、認証情報、スタッフアバタID、位置/向き情報、スタッフポイント等が対応付けられる。スタッフ名は、スタッフユーザが自身で登録した名前であり、任意である。認証情報は、スタッフユーザが正当なスタッフユーザであることを示すための情報であり、例えばパスワードや、メールアドレス、生年月日、合言葉、生体情報等を含んでよい。スタッフアバタIDは、スタッフアバタを特定するためのIDである。位置/向き情報は、スタッフアバタm2の位置情報と向き情報とを含む。向き情報は、スタッフアバタm2の顔の向きを表す情報であってよい。なお、位置/向き情報等は、スタッフユーザからの操作入力に応じて、動的に変化しうる情報である。位置/向き情報に加えて、スタッフアバタm2の手足等の動きを表す情報や、顔の表情(例えば、口の動き)、顔や頭部の向きや視線方向(例えば、眼球の向き)、レーザーポインターのような空間内の向きや座標を示すオブジェクト等を表す情報を含んでもよい。
【0074】
スタッフポイントは、仮想現実におけるスタッフアバタの役割(スタッフとしての仕事)が果たされるごとに増加するパラメータ(所定役割を果たしている量に関連するパラメータの一例)であってよい。すなわち、スタッフポイントは、仮想現実におけるスタッフユーザの働き度合いを表すパラメータであってよい。例えば、一のスタッフユーザに係るスタッフポイントは、当該一のスタッフユーザが、対応するスタッフアバタm2を介して、仮想現実において一般ユーザを補助するごとに増加されてよい。あるいは、一のスタッフユーザに係るスタッフポイントは、当該一のスタッフユーザが、対応するスタッフアバタm2を介して、仮想現実において一般ユーザを補助可能な状態(すなわち稼働状態)となっている時間(労働時間)に応じて増加されてもよい。
【0075】
スタッフ情報602は、好ましくは、スタッフユーザに付与される権限情報を更に含む。権限情報は、仮想空間内で活動するユーザアバタm1を支援(補助)するスタッフアバタm2に付与される役割に関連した権限を表す。権限は、複数種類あってよく、
図6に示す例では、権限は、通常権限と、操作権限、統括権限の3種類である。なお、変形例では、権限は、1種類であってよく、この場合、権限情報は不要であってよい。
【0076】
通常権限は、通常のスタッフユーザに付与される権限であり、例えば、仮想空間内で活動するユーザアバタm1を支援するための各種補助を行うことができる権限であってよい。各種補助は、後述する補助情報の提供により実現されるが、他の形態(例えば実演等)で実現されてもよい。各種補助は、一般ユーザに対する各種の案内、仮想空間内で利用又は提供が可能な商品又はサービスの案内又は販売、一般ユーザからのクレーム対応、及び、一般ユーザに対する各種の注意又は助言のうちの、少なくともいずれか1つを含む。商品又はサービスの案内は、商品又はサービスの説明や宣伝、勧誘等を含んでよい。なお、通常権限は、各種補助のうちの、所定の一部だけが行うことができる権限であってよい。この場合、各種補助のうちの、他の部分は、後述する操作権限や統括権限を有するスタッフユーザが行うことができる。
【0077】
操作権限は、例えば、通常のスタッフユーザよりも経験を積んだシニアスタッフユーザや、特定の教育プログラム(研修プログラム)を受けた専用のスタッフユーザ等に付与される権限であり、例えば、仮想空間内で提供されるコンテンツに関連した各種操作を行うことができる権限であってよい。例えば、仮想空間内で提供されるコンテンツにおいて、スクリプト等を利用して各種演出(例えば適切なタイミングでの所定の第2オブジェクトm3の出現や、音響的な演出等)を実現する場合、操作権限は、当該演出用の各種操作を行うことができる権限であってよい。あるいは、仮想空間内で商品やサービスの販売が実行される場合、操作権限は、商品やサービスの販売に係るレジ(第2オブジェクトm3)の各種操作を行うことができる権限や、商品やサービスの提供数や在庫等を管理する権限を含んでよい。この場合、操作権限は、
図2Dに示した仮想空間80において、バックヤードに対応する空間部(位置SP201)に入ることができる権限を含んでよい。なお、操作権限を有するスタッフユーザは、通常権限も併せて有してよい。
【0078】
統括権限は、例えば、シニアスタッフユーザよりも上級の統括スタッフユーザに付与される権限であり、例えば、上述した通常権限や操作権限が付与されたすべてのスタッフユーザの管理(例えば、権限の変更等)など、仮想空間内でのスタッフユーザを取りまとめる権限であってよい。統括権限を有するスタッフユーザは、例えば、いわゆるゲームマスターと呼ばれるユーザを含んでよい。なお、統括権限は、仮想空間における各種第2オブジェクトm3の配置権限や、提供するコンテンツの選択権限、一般ユーザからのクレーム対応が可能な権限等を含んでもよい。なお、統括権限を有するスタッフユーザは、他の権限(通常権限や操作権限)も併せて有してよい。
【0079】
図6に示す例では、“○”が付されたスタッフユーザには、当該権限が付与されていることを示す。この場合、スタッフID“SU01”に係るスタッフユーザには、通常権限のみが付与されており、スタッフID“SU02”に係るスタッフユーザには、通常権限と操作権限が付与されている。
【0080】
アバタデータベース142には、ユーザアバタm1及びスタッフアバタm2に関するアバタ情報が格納される。
図7に示す例では、アバタ情報は、一般ユーザに係るユーザアバタ情報700と、スタッフユーザに係るスタッフアバタ情報702とを含む。
【0081】
ユーザアバタ情報700は、各ユーザアバタIDに、顔、髪型、服装等が対応付けられる。顔、髪型、服装等の容姿に係る情報は、ユーザアバタを特徴付けるパラメータであり、一般ユーザにより設定される。例えば、アバタに係る顔、髪型、服装等の容姿に係る情報は、種類ごとにIDが付与されてもよい。また、顔については、顔の形、目、口、鼻等の各種類にそれぞれパーツIDが用意され、顔に係る情報は、当該顔を構成する各パーツのIDの組み合わせで管理されてもよい。この場合、顔、髪型、服装等の容姿に係る情報は、アバタ描画用情報として機能できる。すなわち、各ユーザアバタIDに紐付けられた容姿に係る各IDに基づいて、サーバ装置10のみならず端末装置20側においても各ユーザアバタm1を描画することが可能となる。
【0082】
スタッフアバタ情報702は、各スタッフアバタIDに、顔、髪型、服装等が対応付けられる。顔、髪型、服装等の容姿に係る情報は、スタッフアバタを特徴付けるパラメータであり、スタッフユーザにより設定される。顔、髪型等の容姿に係る情報は、ユーザアバタ情報700の場合と同様、各パーツのIDの組み合わせで管理されてよく、アバタ描画用情報として機能できる。
【0083】
このようにして本実施形態では、基本的には、一の一般ユーザに、一のユーザIDが対応付けられ、一のユーザIDに、ユーザアバタIDが対応付けられる。従って、一の一般ユーザに、ある情報が対応付けられる状態と、当該一のユーザIDに、当該情報が対応付けられる状態と、当該一のユーザIDに対応付けられたユーザアバタIDに、当該情報が対応付けられる状態とは、互いに同義である。これは、スタッフユーザに関しても同様である。従って、例えば、
図6で示した例と異なり、ユーザアバタm1の位置/向き情報は、当該ユーザアバタm1に係るユーザアバタIDに対応付けて記憶されてもよいし、同様に、スタッフアバタm2の位置/向き情報は、当該スタッフアバタm2に係るスタッフアバタIDに対応付けて記憶されてもよい。以下では、説明上、一般ユーザと、当該一般ユーザに対応付けられるユーザアバタm1とは、互いに読み替え可能な関係であるとする。
【0084】
コンテンツ情報記憶部144には、仮想空間内で提供可能な特定のコンテンツに関する各種の情報が記憶される。例えば、特定のコンテンツごとに、その提供位置であるコンテンツ提供位置や、内容等が記憶される。
【0085】
図8に示す例では、各コンテンツIDに、コンテンツ提供位置(
図8では、「提供位置」と表記)や、コンテンツ内容(
図8では、「内容」と表記)等が対応付けられている。
【0086】
コンテンツ提供位置は、仮想空間内の位置であって、コンテンツ処理部159を介して一般ユーザがコンテンツ提供を受けることができる位置を含む。すなわち、コンテンツ提供位置は、特定のコンテンツの提供を受けることができる位置を含む。コンテンツ提供位置は、一点の座標値で定義されてもよいが、典型的には、一纏めの領域又は空間部分を形成する複数の座標値で定義されてよい。また、コンテンツ提供位置は、平面上の位置であってもよいし、空間上の位置(すなわち高さ方向を含む3次元の座標系で表される位置)であってもよい。なお、一のコンテンツ提供位置に対応付けられる特定のコンテンツの単位を、1つの特定のコンテンツ(特定のコンテンツの一単位)とする。従って、例えば、ある一のコンテンツ提供位置で、2種類の動画の視聴が可能である場合でも、当該2種類の動画全体が1つの特定のコンテンツである。
【0087】
コンテンツ提供位置は、典型的には、対応する特定のコンテンツの属性に応じて設定されてよい。例えば、
図2Aに示す例では、コンテンツ提供位置は、各ゲートを通って入ることができる仮想空間内の位置である。
図2Bに示す例では、コンテンツ提供位置は、各ゲートを通って入ることができる仮想空間内の第1位置SP11から第8位置SP18のそれぞれである。同様に、
図2Cに示す例では、コンテンツ提供位置は、各ゲートを通って入ることができる仮想空間内の位置SP21、SP22、SP23のそれぞれである。コンテンツ提供位置は、特定のURL(Uniform Resource Locator)で規定されてもよい。この場合、一般ユーザ等は、当該特定のURLにアクセスすることで、ユーザアバタm1等をコンテンツ提供位置に移動させることができる。この場合、一般ユーザは、特定のURLにアクセスして、端末装置20のブラウザ上で特定のコンテンツの提供を受けることができる。
【0088】
コンテンツ内容は、コンテンツ名や、概要、作成者等の情報を含んでよい。
【0089】
コンテンツ情報記憶部144には、更に、各コンテンツ提供位置でそれぞれの特定のコンテンツの提供を受けるために満たされるべき条件(以下、「コンテンツ提供条件」とも称する)を表す情報が記憶されてよい。コンテンツ提供条件は、コンテンツIDごとに設定されてよい。コンテンツ提供条件は、
図2B及び
図2Cに示すように、一連のコンテンツ提供位置を介して、全体として意味を持つ複数の特定のコンテンツの提供が順次受けられるような仮想空間において、設定されるのが好適である。コンテンツ提供条件は、任意であり、提供される特定のコンテンツの特性等に応じて運営側により適宜設定されてよい。また、コンテンツ提供条件は、上述した統括権限を有するスタッフユーザにより設定/変更可能とされてもよい。
【0090】
例えば、ある一のコンテンツ提供位置に係るコンテンツ提供条件は、他の特定の1つ以上のコンテンツ提供位置で特定のコンテンツの提供を受けていることを含んでよい。この場合、一連の特定のコンテンツの提供順序を規制(コントロール)できるので、一連の特定のコンテンツの提供を受けることによる一般ユーザの体験効果(例えば教育の習得効果)を効率的に高めることができる。また、ある一のコンテンツ提供位置に係るコンテンツ提供条件は、他の特定の1つ以上のコンテンツ提供位置で特定のコンテンツの提供を受けており、かつ、当該他の特定の1つ以上のコンテンツ提供位置で設定された課題をクリアしたことであってもよい。この場合、他の特定の1つ以上のコンテンツ提供位置で設定される課題は、当該他の特定の1つ以上のコンテンツ提供位置で提供される特定のコンテンツに関連する課題であってよい。例えば、学習用のコンテンツである場合、効果確認用の課題(例えば簡易なテストやクイズに対する正答率)が設定されてもよい。
【0091】
コンテンツ提供条件は、2種類以上で設定されてもよく、例えば、
図8に示す例では、コンテンツID“CT01”には、通常条件のみが設定されており、コンテンツID“CT02”には、通常条件と緩和条件とが設定されている。この場合、コンテンツID“CT02”に対応する特定のコンテンツに対しては、通常条件と緩和条件のうちのいずれかが選択的に適用される。緩和条件は、通常条件よりも満たされやすい条件である。例えば、通常条件では、課題が所定時間ΔT1以内にクリアされる必要があるのに対して、緩和条件では、課題が所定時間ΔT1よりも有意に長い所定時間ΔT2以内にクリアされればよい、といった具合である。あるいは、緩和条件では、クリアすべき課題の難易度が通常条件のときよりも低い、といった具合である。なお、2種類以上のコンテンツ提供条件が割り当てられるコンテンツIDは、上述した統括権限を有するスタッフユーザにより設定/変更可能とされてもよい。
【0092】
以下、本実施形態では、一例として、一の仮想空間において、Nを3以上の整数としたとき、N個のコンテンツ提供位置(N個の特定のコンテンツ)が設定されているものとする。そして、N個のコンテンツ提供位置で提供可能なN個の特定のコンテンツは、1番目からN番目の順に提供可能なコンテンツであるとする。従って、一般ユーザは、N-1番目の特定のコンテンツについては、N-2番目までの特定のコンテンツの提供をすべて受けてからでないと、提供を受けることができないものとする。
【0093】
空間状態記憶部146には、仮想空間における空間状態情報が格納される。空間状態情報は、仮想空間内のユーザアバタm1のそれぞれの活動に係る状態や、スタッフアバタm2のそれぞれの活動(役割に係る活動)に係る状態等を表す。
【0094】
仮想空間における空間状態情報は、コンテンツ提供位置に係る空間部分内の状態に関する空間状態情報を含み、更に、所定支援位置に係る空間部分内の状態に関する空間状態情報を含んでもよい。
【0095】
コンテンツ提供位置は、上述したとおりである。所定支援位置は、仮想空間におけるコンテンツ提供位置以外の位置であって、スタッフユーザによる一般ユーザの補助が必要となりやすい位置である。例えば、所定支援位置は、コンテンツ提供位置に係る入口付近等を含んでよい。例えば、
図2Aから
図2Cに示す例では、所定支援位置は、位置SP1、SP2や、位置SP20(
図2C参照)等である。
【0096】
以下、特に言及しない限り、空間状態情報とは、コンテンツ提供位置に係る空間部分内の状態に関する空間状態情報を意味する。また、以下では、仮想空間における各コンテンツ提供位置に係る空間部分を、各部屋として定義されており、一般ユーザに向けてURLで記述可能とする。同一ルームにアクセスするユーザを同じルームに紐づけられたセッションとして管理する。ルームに係る空間部分にアバタが入ることを入室と表現する場合がある。一のルームに同時にアクセスできるユーザ数には処理能力の観点から限界があるが、同一の設計を持ったルームを複製し、負荷を分散させる処理があってもよい。なお、各部屋がつながった全体は、ワールドとも称される。
【0097】
図9に示す例では、空間状態情報は、コンテンツ提供位置(部屋)ごとと、仮想空間全体とで管理されている。具体的には、空間状態情報は、一般ユーザに係るユーザ状態情報900と、スタッフユーザに係るスタッフ状態情報902と、仮想空間に係る仮想空間情報904とを含む。ユーザ状態情報900及びスタッフ状態情報902については、ある一のコンテンツ提供位置に係る空間状態情報が示されているが、所定支援位置に係る空間状態情報についても、特に言及しない限り、同様であってよい。
【0098】
ユーザ状態情報900は、コンテンツ提供位置(部屋)ごとに設定され、
図9に示すユーザ状態情報900は、一のコンテンツ提供位置に関する。例えば、
図2Bに示す例では、スタッフ状態情報902は、第1位置SP11から第8位置SP18のそれぞれごとに設定される。同様に、
図2Cに示す例では、位置SP21、SP22、SP23のそれぞれごとに設定される。
【0099】
ユーザ状態情報900は、入室ユーザに、ユーザ名、位置/向き情報、部屋滞在時間、コンテンツ提供条件の緩和の有無、次室移動条件の成否情報等が対応付けられる。入室ユーザは、コンテンツ提供位置に位置しているユーザアバタm1に係る一般ユーザであり、入室ユーザの情報は、当該一般ユーザを特定できる任意の情報(ユーザIDや、ユーザアバタID等)であってよい。ユーザ名は、上述したユーザ情報に基づくユーザ名である。なお、ユーザ名は、入室ユーザに紐付けられる情報であるので、ユーザ状態情報900からは省略されてもよい。位置/向き情報は、ユーザアバタm1の位置/向き情報である。なお、入室ユーザは、コンテンツ提供位置に位置しているユーザアバタm1に係る一般ユーザであることから、ユーザアバタm1の位置情報は、コンテンツ提供位置(複数の座標値で定義される場合、その複数の座標値のうちの1つ)に対応する。換言すると、一のユーザアバタm1の位置情報がコンテンツ提供位置に対応しない場合は、当該一のユーザアバタm1に係る一般ユーザは、入室ユーザから除外される。ユーザアバタm1の位置情報は、特に、一のコンテンツ提供位置が複数の座標値で定義される場合(すなわち比較的広い領域又は空間部分全体がコンテンツ提供位置である場合)に有用となる。この場合、位置情報は、比較的広い空間部分のどこに位置するかを表すことができる。
【0100】
部屋滞在時間は、コンテンツ提供位置に位置している滞在時間に対応する。部屋滞在時間は、次室移動条件の判定等に利用されてもよい。
【0101】
コンテンツ提供条件の緩和の有無は、
図8を参照して上述したコンテンツ情報記憶部144内のコンテンツ提供条件の、通常条件と緩和条件のうちの、いずれが適用されているかを示す情報である。通常条件と緩和条件のうちの、いずれが適用されるかは、所定のルールに従って自動的に設定されてもよいし、後述する条件処理部164により緩和される場合があってもよい。例えば、一の一般ユーザの年齢が比較的低い場合(例えば小学生等である場合)や、一の一般ユーザの部屋滞在時間が比較的長い場合、当該一の一般ユーザに対しては緩和条件が初期的に自動的に設定されてもよい。また、特定の一般ユーザに対しては、緩和条件として、部屋滞在時間に関する条件が外されてもよい。例えば、一般ユーザごとに設定されうるイベントタイマーが、特定の一般ユーザに対しては設定されない又は無視されてもよい。
【0102】
次室移動条件の成否情報は、入室ユーザが、次のコンテンツ提供位置へと移動する際に満たされるべき条件(次室移動条件)を満たしているかどうかを表す。次室移動条件は、上述したコンテンツ提供条件に基づいて任意に設定されてよい。本実施形態では、次室移動条件は、次室に係るコンテンツ提供位置に設定されるコンテンツ提供条件と同じである。従って、一の一般ユーザ(入室ユーザ)については、次室に係るコンテンツ提供位置に設定されるコンテンツ提供条件が満たされると、次室移動条件が満たされることになる。なお、所定支援位置に関する次室移動条件の成否情報についても、次のコンテンツ提供位置(例えば1つ目のコンテンツ提供位置)へと移動する際に満たされるべき条件(次室移動条件)を満たしているか否かを表してよい。
【0103】
なお、次室移動条件は、一般ユーザ(ユーザアバタm1)に対して適用され、スタッフユーザ(スタッフアバタm2)に対しては適用されない。従って、スタッフアバタm2は、原則的に、自由に各部屋を移動できる。
【0104】
スタッフ状態情報902は、仮想空間ごとに設定されてもよいし、一纏まりのコンテンツ提供位置に係る各部屋全体(以下、「コンテンツ提供用の仮想空間部」とも称する)ごとに設定されてもよい。例えば、
図2Bに示す例では、スタッフ状態情報902は、第1位置SP11から第8位置SP18のそれぞれに係る各空間部分全体(コンテンツ提供用の仮想空間部)に関する。同様に、
図2Cに示す例では、スタッフ状態情報902は、位置SP21、SP22、SP23のそれぞれに係る各空間部分全体(コンテンツ提供用の仮想空間部)に関する。
【0105】
スタッフ状態情報902は、稼働スタッフに、スタッフ名や位置/向き情報が対応付けられる。稼働スタッフは、コンテンツ提供位置に位置しているスタッフアバタm2に係るスタッフユーザであり、稼働スタッフの情報は、当該スタッフユーザを特定できる任意の情報(スタッフIDや、スタッフアバタID等)であってよい。
【0106】
仮想空間情報904は、スタッフ状態情報902と同様、仮想空間ごとに設定されてもよいし、コンテンツ提供用の仮想空間部ごとに設定されてもよい。具体的には、複数の独立したコンテンツ提供用の仮想空間部が用意される場合は、仮想空間情報904は、かかる独立したコンテンツ提供用の仮想空間部ごとに設定されてもよい。また、仮想現実生成システム1が
図2Bに示す仮想空間と
図2Cに示す仮想空間を同時に扱う場合、
図2Bに示す仮想空間用の仮想空間情報904と、
図2Cに示す仮想空間用の仮想空間情報904とが、それぞれ設定されてもよい。
【0107】
仮想空間情報904は、空間内ユーザに、ユーザ名、位置情報、空間滞在時間、過去の利用履歴等が対応付けられる。なお、ユーザ名は、上述したとおりであり、省略されてもよい。
【0108】
空間内ユーザは、コンテンツ提供用の仮想空間部内の各コンテンツ提供位置のうちのいずれかに位置しているユーザアバタm1に係る一般ユーザであり、ユーザ状態情報900の入室ユーザの情報に基づいて生成されてよい。
【0109】
位置情報は、コンテンツ提供用の仮想空間部内のどのコンテンツ提供位置(部屋)に位置するかを示す情報であり、ユーザ状態情報900の位置/向き情報よりも粗い情報であってもよい。
【0110】
空間滞在時間は、コンテンツ提供用の仮想空間部内に位置している間に積算される時間であり、ユーザ状態情報900の部屋滞在時間に基づいて生成されてもよい。空間滞在時間は、ユーザ状態情報900の部屋滞在時間と同様、次室移動条件の判定等に利用されてもよい。また、空間滞在時間は、ユーザ状態情報900の部屋滞在時間と同様、仮想空間内での活動結果を表す修了証等の作成に利用されてもよい。
【0111】
過去の利用履歴は、コンテンツ提供用の仮想空間部に関する過去の利用履歴である。過去の利用履歴は、日時や、コンテンツ提供用の仮想空間部内のどのコンテンツ提供位置まで進んだかといった進捗状態を示す情報を含んでよい。過去の利用履歴は、後述するように、一般ユーザに、スタッフユーザに係る役割を付与する際に、利用されてもよい。あるいは、過去の利用履歴は、中断後等に再入場しうる一般ユーザに対して前回の途中からの続きから開始できるようにするために、利用されてもよい。
【0112】
空間描画処理部150は、仮想空間の描画情報に基づいて、仮想空間を描画する。なお、仮想空間の描画情報は、あらかじめ生成されるが、事後的又は動的に更新等されてもよい。仮想空間内の各位置は、空間座標系で規定されてよい。なお、仮想空間の描画方法は、任意であるが、例えばフィールドオブジェクトや背景オブジェクトを、適切な平面や曲面等にマッピングすることにより実現されてもよい。
【0113】
ユーザアバタ処理部152は、ユーザアバタm1に係る各種処理を実行する。ユーザアバタ処理部152は、操作入力取得部1521と、ユーザ動作処理部1522とを含む。
【0114】
操作入力取得部1521は、一般ユーザによる操作入力情報を取得する。なお、一般ユーザによる操作入力情報は、上述した端末装置20の入力部24を介して生成される。
【0115】
ユーザ動作処理部1522は、操作入力取得部1521により取得された操作入力情報に基づいて、仮想空間におけるユーザアバタm1の位置及び向きを決定する。ユーザ動作処理部1522により決定された位置及び向きを表すユーザアバタm1の位置/向き情報は、例えばユーザIDに対応付けて記憶されてよい(
図6のユーザ情報600参照)。また、ユーザ動作処理部1522は、操作入力情報に基づいて、ユーザアバタm1の手や顔などの各種の動きを決定してもよい。この場合、かかる動きの情報も、ユーザアバタm1の位置/向き情報とともに記憶されてよい。
【0116】
本実施形態では、ユーザ動作処理部1522は、仮想空間内においてユーザアバタm1のそれぞれを、後述する活動制限部162による制限下で移動させる。すなわち、ユーザ動作処理部1522は、後述する活動制限部162による制限下で、ユーザアバタm1の位置を決定する。従って、例えば、活動制限部162により一のユーザアバタm1の一のコンテンツ提供位置への移動が制限されている場合、ユーザ動作処理部1522は、当該一のユーザアバタm1の、一のコンテンツ提供位置への移動が実現されない態様で、当該一のユーザアバタm1の位置を決定する。
【0117】
また、ユーザ動作処理部1522は、仮想空間内においてユーザアバタm1のそれぞれを、現実空間における物理法則に対応する所定法則に従って、移動させる。例えば、現実空間における壁に対応する第2オブジェクトm3があるとき、ユーザアバタm1は、壁を通過できなくてもよい。また、ユーザアバタm1は、重力に対応する引力をフィールドオブジェクトから受け、特別な器具(例えば揚力を発生する器具)を装着しない限り、空中に長時間浮遊できなくてもよい。
【0118】
ここで、上述したように、ユーザ動作処理部1522の機能は、サーバ装置10に代えて、端末装置20によって実現することも可能である。例えば、仮想空間内の移動は加速度と衝突等が表現される態様で実現されてもよい。この場合、各ユーザは、位置をポイント(指示)することで、ユーザアバタm1をジャンプさせて移動させることもできるが、壁面や移動に関する制限に関する判定は、端末制御部25(ユーザ動作処理部1522)により実現されてよい。この場合、端末制御部25(ユーザ動作処理部1522)は、事前に提供された制限情報に基づいて判定処理を行う。なお、この場合、位置情報はWebSocket等に基づくリアルタイム通信でサーバ装置10を経由して必要な他ユーザに共有されてよい。
【0119】
スタッフアバタ処理部154は、スタッフアバタm2に係る各種処理を実行する。スタッフアバタ処理部154は、操作入力取得部1541と、スタッフ動作処理部1542と、補助情報提供部1544と、を含む。
【0120】
操作入力取得部1541は、スタッフユーザによる操作入力情報を取得する。なお、スタッフユーザによる操作入力情報は、上述した端末装置20の入力部24を介して生成される。
【0121】
スタッフ動作処理部1542は、操作入力取得部1541により取得された操作入力情報に基づいて、仮想空間におけるスタッフアバタm2の位置及び向きを決定する。スタッフ動作処理部1542により決定された位置及び向きを表すスタッフアバタm2の位置/向き情報は、例えばスタッフIDに対応付けて記憶されてよい(
図6のスタッフ情報602参照)。また、スタッフ動作処理部1542は、操作入力情報に基づいて、スタッフアバタm2の手や顔などの各種の動きを決定してもよい。この場合、かかる動きの情報も、スタッフアバタm2の位置/向き情報とともに記憶されてよい。
【0122】
本実施形態では、スタッフ動作処理部1542は、上述したユーザ動作処理部1522とは異なり、仮想空間内においてスタッフアバタm2のそれぞれを、現実空間における物理法則に対応する所定法則に従うことなく、移動させる。例えば、現実空間における壁に対応する第2オブジェクトm3があるときでも、スタッフアバタm2は、壁を通過できてもよい。また、スタッフアバタm2は、特別な器具(例えば揚力を発生する器具)を装着しなくても、空中に長時間浮遊できてもよい。あるいは、スタッフアバタm2は、いわゆる瞬間移動(ワープ)や、巨大化等が可能であってもよい。
【0123】
また、スタッフアバタm2は、ユーザアバタm1ではできない動き等を実現できてもよい。例えば、スタッフアバタm2は、ユーザアバタm1とは異なり、非常に重たい重量物(例えば銅像や建物)に対応する第2オブジェクトm3を移動できてもよい。あるいは、スタッフアバタm2は、ユーザアバタm1とは異なり、所定のアイテムを譲渡/変換することが可能であってもよい。あるいは、スタッフアバタm2は、ユーザアバタm1とは異なり、打ち合わせ等を行うための仮想空間内の特別な空間部分(例えば、
図2Dの示すような各種のスタッフルームに対応する空間部分)に移動できてもよい。
【0124】
また、スタッフ動作処理部1542は、スタッフユーザに付与される権限情報に基づいて、スタッフアバタm2の移動(動き)の自由度を可変してもよい。例えば、スタッフ動作処理部1542は、統括権限を有するスタッフユーザに係るスタッフアバタm2に対して、最も高い自由度を付与し、操作権限を有するスタッフユーザに係るスタッフアバタm2に対して、次に高い自由度を付与してもよい。
【0125】
補助情報提供部1544は、スタッフユーザによる所定入力に応答して、一般ユーザに所定情報を提供する。所定情報は、一般ユーザにとって有用となりうる任意の情報であってよく、例えば、次室移動条件を満たすためのアドバイス/チップ(Tips)や、一般ユーザの不満や不安等を解消するための情報等を含んでよい。所定情報が多様である場合、スタッフユーザからの所定入力は、提供する所定情報の種類を特定する入力を含んでよい。所定情報は、例えば、一般ユーザの端末装置20を介して任意の態様で出力されてもよい。例えば、所定情報は、端末装置20を介して音声や映像等により出力されてもよい。なお、所定情報の提供が、一般ユーザとスタッフユーザとの間の対話により実現される場合は、所定情報の提供は、後述する第2対話処理部1602により実現される。
【0126】
本実施形態では、所定情報は、一般ユーザに対して各種補助を実現できるような補助情報である。そして、補助情報提供部1544は、一般ユーザのそれぞれに対応付けられたユーザ状態情報900(
図9参照)に基づいて、スタッフアバタm2を介して、一般ユーザのうちの一部又はそれぞれに補助情報を提供する。
【0127】
このように本実施形態では、スタッフユーザは、各種の所定入力を行うことで、補助情報提供部1544によりスタッフアバタm2を介して、一般ユーザに各種の補助情報を提供できる。
【0128】
例えば、スタッフユーザは、次室移動条件を満たしていない一般ユーザに対して、次室移動条件を満たすためのアドバイス/チップを含む補助情報を提供する。例えば、スタッフユーザは、次のコンテンツ提供位置への入口を通れないユーザアバタm1に係る一般ユーザに対して、次室移動条件を説明してもよいし、次室移動条件を満たすようにアドバイスしてもよい。あるいは、課題をクリアしないと次のコンテンツ提供位置への入口を通れない場合は、スタッフユーザは、課題をクリアするためのヒント等を提供してもよい。
【0129】
また、補助情報は、スタッフユーザの動きに基づく実技や見本等であってもよい。例えば、特定のコンテンツに係る課題が、特定の身体の動きを伴う場合、スタッフユーザは、当該特定の身体の動きを実技等で、スタッフアバタm2を介して、一般ユーザに示してもよい。あるいは、
図2Cに示す例のように、所定の順序で特定のコンテンツの提供を受けることが有用な場合は、スタッフユーザは、当該所定の順序で進むようにアドバイスしてもよい。
【0130】
本実施形態では、補助情報提供部1544は、スタッフユーザに付与される権限情報に基づいて、スタッフユーザによる補助情報を提供する能力を可変してもよい。例えば、補助情報提供部1544は、統括権限を有するスタッフユーザに対しては、すべての一般ユーザに対して補助情報を提供できる権限を付与し、操作権限を有するスタッフユーザに対しては、特定の空間部分に位置するユーザアバタm1の一般ユーザに対してだけ補助情報を提供できる権限を付与してもよい。また、補助情報提供部1544は、通常権限を有するスタッフユーザに対して、あらかじめ用意された定型的な補助情報のみを提供できる権限を付与してもよいし、統括権限や操作権限を有するスタッフユーザに係るスタッフアバタm2から補助情報が得られるように、ユーザアバタm1を所定の案内位置等へとナビゲートする補助情報のみを提供できる権限を付与してもよい。
【0131】
位置/向き情報特定部156は、ユーザアバタm1の位置情報とスタッフアバタm2の位置情報とを特定する。なお、位置/向き情報特定部156は、上述したユーザ動作処理部1522及びスタッフ動作処理部1542からの情報に基づいて、ユーザアバタm1及びスタッフアバタm2のそれぞれの位置情報を特定してよい。
【0132】
補助対象検出部157は、仮想空間内で活動しているユーザアバタm1のうちから、補助情報を必要としている可能性が高い一般ユーザに係るユーザアバタm1(以下、「補助対象のユーザアバタm1」とも称する)を検出する。本実施形態では、補助対象検出部157は、空間状態記憶部146内のデータに基づいて、補助対象のユーザアバタm1を検出してもよい。例えば、補助対象検出部157は、部屋滞在時間が比較的長いユーザアバタm1や、動きが少ないユーザアバタm1、迷いを示唆する動きをしているユーザアバタm1等に基づいて、補助対象のユーザアバタm1を検出してもよい。また、補助情報の必要なときに、例えば手をあげるといったユーザアバタm1からの合図があるときは、補助対象検出部157は、かかる合図に基づいて、補助対象のユーザアバタm1を検出してもよい。
【0133】
なお、補助対象のユーザアバタm1は、人工知能を利用して、空間状態記憶部146内のデータを入力して出力(検出)することも可能である。人工知能の場合は、機械学習により得られる畳み込みニューラルネットワークを実装することで実現できる。機械学習では、例えば、空間状態記憶部146内のデータ(実績データ)を用いて、補助対象のユーザアバタm1の検出結果に係る誤差(すなわち、実際には補助情報を必要としていないユーザアバタm1が、補助対象のユーザアバタm1として検出されてしまう誤差)が最小になるような畳み込みニューラルネットワークの重み等が学習される。
【0134】
補助対象検出部157は、補助対象のユーザアバタm1を検出すると、当該補助対象のユーザアバタm1が、所定の描画態様で描画されるように、描画処理部158(後述)に指示を出力してよい。
【0135】
本実施形態では、補助対象検出部157は、補助対象のユーザアバタm1を検出した場合に、補助情報の提供の必要性(緊急性)や、必要とする補助情報の属性等の付加情報を生成してもよい。例えば、付加情報は、後述する第2対話処理部1602による対話を介した補助情報が必要であるか、あるいは、一方通行の補助情報の提供で足りるかを示す情報を含んでもよい。
【0136】
また、補助対象検出部157は、一般ユーザからの直接的な補助要求(後述する補助要求部250からの補助要求)に応じて、補助要求を生成したユーザアバタm1を、補助対象のユーザアバタm1として検出してもよい。
【0137】
描画処理部158(媒体描画処理部の一例)は、仮想空間内で移動可能な各仮想現実媒体(例えばユーザアバタm1やスタッフアバタm2)を描画する。具体的には、描画処理部158は、アバタ描画用情報(
図7参照)と、各ユーザアバタm1の位置/向き情報やスタッフアバタm2の位置/向き情報等とに基づいて、各ユーザに係る端末装置20で表示される画像を生成する。
【0138】
本実施形態では、描画処理部158は、端末画像生成部1581と、ユーザ情報取得部1582とを含む。
【0139】
端末画像生成部1581は、ユーザアバタm1ごとに、一のユーザアバタm1の位置/向き情報に基づいて、当該一のユーザアバタm1に対応付けられた一般ユーザに係る端末装置20で表示される画像(以下、後述のスタッフユーザ用の端末用画像と区別する場合、「一般ユーザ用の端末用画像」とも称する)を生成する。具体的には、端末画像生成部1581は、一のユーザアバタm1の位置/向き情報に基づいて、当該位置/向き情報に対応した位置及び向きの仮想カメラから視た仮想空間の画像(仮想空間の一部を切り取る画像)を端末用画像として生成する。この場合、位置/向き情報に対応した位置及び向きに仮想カメラの位置及び向きを一致させると、仮想カメラの視野は、ユーザアバタm1の視野に実質的に一致する。ただし、この場合、仮想カメラからの視野には、当該ユーザアバタm1は映らない。従って、ユーザアバタm1が映る端末用画像を生成する場合は、仮想カメラの位置は、ユーザアバタm1の背後側に設定されてよい。あるいは、仮想カメラの位置は、対応する一般ユーザにより任意に調整可能であってもよい。なお、かかる端末用画像を生成する際、端末画像生成部1581は、奥行き感等を出すために、各種の処理(例えばフィールドオブジェクトを曲げる処理等)を実行してもよい。また、ユーザアバタm1が映る端末用画像を生成する場合は、描画処理の負荷を低減するために、ユーザアバタm1は、比較的簡易な態様(例えば二次元スプライトの形態)で描画されてもよい。
【0140】
また、同様に、端末画像生成部1581は、スタッフアバタm2ごとに、一のスタッフアバタm2の位置/向き情報に基づいて、当該一のスタッフアバタm2に対応付けられたスタッフユーザに係る端末装置20で表示される画像(以下、上述した一般ユーザ用の端末用画像と区別する場合、「スタッフユーザ用の端末用画像」とも称する)を生成する。
【0141】
端末画像生成部1581は、仮想カメラからの視野内の他のユーザアバタm1やスタッフアバタm2が位置する場合は、当該他のユーザアバタm1やスタッフアバタm2を含む端末用画像を生成する。ただし、この場合、描画処理の負荷を低減するために、他のユーザアバタm1やスタッフアバタm2は、比較的簡易な態様(例えば二次元スプライトの形態)で描画されてもよい。
【0142】
また、端末画像生成部158は、発話者の口の動きを再現したり、発話者の頭部等の大きさを強調表現することで、発話状態をわかりやすくする処理を実現してもよい。このような処理は、後述する対話処理部160と協動して実現されてもよい。
【0143】
ここで、上述したように、端末画像生成部1581の機能は、サーバ装置10に代えて、端末装置20によって実現することも可能である。この場合、例えば、端末画像生成部1581は、サーバ装置10のスタッフアバタ処理部154により生成された位置/向き情報と、描画対象のアバタを特定できる情報(例えばユーザアバタIDやスタッフアバタID)と、当該描画対象のアバタに係るアバタ描画用情報(
図7参照)とをサーバ装置10から受信し、受信した情報に基づいて、各アバタの画像を描画する。この場合、端末装置20は、アバタの各パーツを描画するためのパーツ情報を端末記憶部22内に格納しており、当該パーツ情報と、サーバ装置10から取得する描画対象のアバタ描画用情報(各パーツのID)とに基づいて、各アバタの容姿を描画してもよい。
【0144】
本実施形態では、端末画像生成部1581は、一般ユーザ用の端末用画像(第1属性のユーザ用の表示画像の一例)又はスタッフユーザ用の端末用画像(第2属性のユーザ用の表示画像の一例)におけるスタッフアバタm2を、ユーザアバタm1から識別可能な態様で、描画する。
【0145】
具体的には、端末画像生成部1581は、仮想空間内に配置される複数のスタッフアバタm2に対して共通の可視特徴を対応付けて描画する。これにより、各ユーザは、共通の可視特徴に基づいて、スタッフユーザであるか否かを容易に識別できる。例えば、各ユーザは、一のアバタが共通の可視特徴に対応付けて描画されている場合は、当該一のアバタがスタッフアバタm2であると容易に認識できる。このように、共通の可視特徴は、このような識別機能を有する限り、任意であってもよい。ただし、共通の可視特徴は、好ましくは、高い識別能力を有するように、一目で目に付くような大きさを有する。
【0146】
例えば、共通の可視特徴は、共通の服装(制服)や装着具(例えばスタッフ専用の腕章やバッチ、専用のセキュリティカード等)である。また、共通の可視特徴は、“スタッフ(Staff)”といったテキストであって、スタッフアバタm2の近傍に描画されるテキストであってもよい。本実施形態では、一例として、共通の可視特徴は、制服であるとする。
【0147】
共通の可視特徴は、好ましくは、スタッフユーザのそれぞれによる独自の変更が禁止される。すなわち、共通の可視特徴は、好ましくは、共通性が損なわれることがないように、スタッフユーザのそれぞれによる改変やアレンジが不能とされる。これにより、共通性が損なわれることに起因して共通の可視特徴に係る識別機能が毀損されてしまう可能性を、低減できる。ただし、共通の可視特徴は、特定のスタッフユーザ(例えば統括権限を有するスタッフユーザ)により改変やアレンジは可能であってよい。この場合、改変やアレンジ後の共通の可視特徴は、対応するすべてのスタッフユーザに適用されるので、共通性が損なわれることはない。
【0148】
また、共通の可視特徴は、一のアイテムの一部であってもよい。例えば、共通の可視特徴に係るアイテムがジャケットであり、ジャケットのうちのリボンやボタンがアレンジ可能である場合、共通の可視特徴は、ジャケットのうちの、アレンジが可能なリボンやボタンを除く部分である。また、共通の可視特徴に係るアイテムが帽子付きの髪型であり、帽子付きの髪型のうちの髪型がアレンジ可能である場合(すなわち帽子はアレンジ禁止である場合)、共通の可視特徴は、帽子付きの髪型のうちの、髪型を除く部分(すなわち帽子の部分)である。このような、共通の可視特徴に係るアイテムのうちの、アレンジが可能な部位/禁止の部位は、あらかじめ規定されていてもよい。これにより、共通の可視特徴に係る識別機能を維持しつつ、各スタッフアバタm2の容姿に係る個性(アレンジ部分による個性)の発揮を期待できる。この場合、共通の可視特徴に係るアイテムのうちの、アレンジが禁止されている部分(すなわち共通の可視特徴)をスタッフユーザが編集すると、所定のペナルティが課せられてもよい。例えば、所定のペナルティは、そのアレンジされたアイテムを利用(例えば着用)できなくなる、アレンジしたものを保存できない(サーバ装置10に保存できない)といった具合であってよい。あるいは、所定のペナルティは、後述するスタッフ管理部180の評価部1803の評価結果が著しく低下することを含んでもよい。また、共通の可視特徴に係るアイテムは、別ユーザと交換することや譲渡すること等を禁止されてよい。
【0149】
なお、共通の可視特徴は、スタッフユーザの属性(スタッフ属性)に応じて異なってもよい。換言すると、共通の可視特徴は、スタッフ属性ごとに共通であってよい。スタッフ属性は、例えば、権限情報(通常権限と、操作権限、統括権限の3種類)に応じた属性であってもよいし、より細かい粒度(例えば、より詳細な役割や、位置する部屋等)に応じた属性であってもよい。これにより、各ユーザは、共通の可視特徴の種類に基づいて、スタッフユーザの属性(スタッフ属性)を判断できる。この場合も、同一のスタッフ属性のスタッフユーザに係るスタッフアバタm2は、共通の可視特徴を対応付けて描画される。また、スタッフユーザは、複数種類のオブジェクト(制服等)から任意の種類(例えば所望の種類)を選択可能であってもよい。
【0150】
端末画像生成部1581は、好ましくは、一般ユーザ用の端末用画像と、スタッフユーザ用の端末用画像とを、異なる態様で描画する。この場合、ユーザアバタm1の位置/向き情報と、スタッフアバタm2の位置/向き情報とが完全に一致する場合でも、一般ユーザ用の端末用画像と、スタッフユーザ用の端末用画像とが、異なる態様で描画される。例えば、端末画像生成部1581は、スタッフユーザ用の端末用画像において、後述するユーザ情報取得部1582により取得された所定ユーザ情報を描画してもよい。この場合、所定ユーザ情報の描画方法は任意であるが、例えば、一般ユーザのユーザアバタm1に対応付けて描画されてもよい。例えば、所定ユーザ情報は、ユーザアバタm1に重畳又は近傍に描画されてもよいし、ユーザ名とともに描画されてもよい。また、この場合、所定ユーザ情報は、例えば、スタッフユーザの役割に有用な情報であって、通常は見えない情報(例えば次室移動条件の成否情報)であってよい。また、端末画像生成部1581は、スタッフユーザ用の端末用画像において、次室移動条件の成否情報(
図9参照)に基づいて、次室移動条件を満たしているユーザアバタm1と、そうでないユーザアバタm1とを異なる態様で描画してもよい。この場合、スタッフユーザは、次室に移動可能なユーザアバタm1と、そうでないユーザアバタm1とを容易に見分けることができる。この結果、スタッフユーザは、次室に移動可能でないユーザアバタm1に係る一般ユーザに対して、効率的に補助情報を提供できる。
【0151】
また、端末画像生成部1581は、スタッフユーザ用の端末用画像を生成する際、スタッフユーザに付与される権限情報に基づいて、通常は見えない情報の開示範囲を可変してもよい。例えば、端末画像生成部1581は、統括権限を有するスタッフユーザに係るスタッフアバタm2に対して、最も広い開示範囲を付与し、操作権限を有するスタッフユーザに係るスタッフアバタm2に対して、次に広い開示範囲を付与してもよい。
【0152】
本実施形態では、端末画像生成部1581は、上述したように補助対象検出部157により補助対象のユーザアバタm1が検出された場合に、スタッフユーザ用の端末用画像において、当該補助対象のユーザアバタm1を所定の描画態様で描画する。
【0153】
所定の描画態様は、スタッフユーザが容易に認識できるように強調表示(例えば点滅や赤色等で表示)を含んでよい。この場合、スタッフユーザは、補助対象のユーザアバタm1を容易に見つけることができる。
【0154】
あるいは、所定の描画態様は、重畳表示されるサブ画像(
図15のサブ画像G156参照)の出現を伴ってもよい。この場合、端末画像生成部1581は、特定のスタッフユーザ用の端末用画像において、補助対象のユーザアバタm1を写すサブ画像を重畳表示する。この場合、特定のスタッフユーザは、補助対象のユーザアバタm1に近いスタッフアバタm2に係るスタッフユーザであってもよいし、補助対象のユーザアバタm1に補助情報を提供できる権限を有するスタッフユーザであってもよい。なお、補助対象検出部157により複数の補助対象のユーザアバタm1が検出された場合、サブ画像は、複数生成されてもよい。また、サブ画像は、枠等が点滅する態様で表示されてもよい。
【0155】
また、所定の描画態様は、必要とする補助情報の属性に応じて異なってもよい。例えば、「特定のコンテンツの提供を受け終えていない」ことに起因して補助情報を必要としている補助対象のユーザアバタm1と、「特定のコンテンツの提供を受け終えているが、課題を提出できていない」ことに起因して補助情報を必要としている補助対象のユーザアバタm1とは、異なる所定の描画態様で描画されてもよい。この場合、所定の描画態様と、必要とする補助情報との関係をルール化することで、スタッフユーザは、補助対象のユーザアバタm1の描画態様を見ることで、当該補助対象のユーザアバタm1にとってどのような補助情報が有用であるかを容易に認識できる。
【0156】
また、端末画像生成部1581は、補助対象検出部157により上述した付加情報が生成される場合、当該付加情報に応じて、補助対象のユーザアバタm1に補助情報を提供すべきスタッフユーザ(例えば上述した特定のスタッフユーザ)を決定してもよい。例えば、付加情報が示す属性(必要とする補助情報の属性)が、クレーム対応による対話である場合、端末画像生成部1581は、統括権限を有するスタッフユーザを、補助すべきスタッフユーザとして決定してもよい。この場合、端末画像生成部1581は、統括権限を有するスタッフユーザ用の端末用画像において当該補助対象のユーザアバタm1を写すサブ画像を、重畳表示してもよい。
【0157】
ユーザ情報取得部1582は、上述した所定ユーザ情報を取得する。所定ユーザ情報は、上述したように、スタッフユーザ用の端末用画像において描画される情報であって、一般ユーザ用の端末用画像には、表示されることのない情報である。
【0158】
ユーザ情報取得部1582は、スタッフユーザごとに所定ユーザ情報を取得してもよい。この場合、所定ユーザ情報をスタッフユーザごとに異ならせることができる。これは、スタッフユーザごとに、当該スタッフユーザの役割に有用な情報が異なりうるためである。
【0159】
例えば、ユーザ情報取得部1582は、一のスタッフユーザに係るスタッフユーザ用の端末用画像に関して、当該端末用画像にユーザアバタm1が含まれる場合に、当該ユーザアバタm1に係るユーザ情報(例えば、
図6のユーザ情報600参照)に基づいて、当該ユーザアバタm1に係る一般ユーザに応じた所定ユーザ情報を取得してもよい。この場合、例えば、
図6のユーザ情報600を利用する場合、ユーザ情報取得部1582は、ユーザ情報600における購買アイテム情報及び/又は購買関連情報、又は、それに基づき生成された情報を、所定ユーザ情報として取得してもよい。購買アイテム情報又はそれに基づき生成された情報(例えば購買アイテム情報の一部や、購買アイテム情報から得られるユーザの嗜好情報等)を所定ユーザ情報として取得する場合、スタッフユーザは、補助対象のユーザアバタm1に係る一般ユーザが、どのようなアイテムを既に所持しているかを把握できる。これにより、スタッフユーザは、一般ユーザに対して、所持していないアイテムの購買を薦める等、適切な補助情報の生成が可能となる。また、購買関連情報又はそれに基づき生成された情報(例えばユーザの嗜好情報等)を所定ユーザ情報として取得する場合、スタッフユーザは、補助対象のユーザアバタm1に係る一般ユーザが、どのような嗜好を有しているかを判断しやすくなる。例えば、宣伝したことがあるのに購入に至らなかった事実や、宣伝を重ねたら購入してくれた事実等をスタッフユーザが把握することで、一般ユーザの嗜好や行動傾向を把握しやすくなる。これにより、スタッフユーザは、宣伝が有用となる一般ユーザに対してのみアイテムの宣伝を行う等、適切な補助情報の生成が可能となる。
【0160】
コンテンツ処理部159は、コンテンツ提供位置ごとに一般ユーザに特定のコンテンツを提供する。コンテンツ処理部159は、例えばブラウザを介して端末装置20上で特定のコンテンツを出力してもよい。あるいは、コンテンツ処理部159は、端末装置20に実装される仮想現実アプリケーションを介して、端末装置20上で特定のコンテンツを出力してもよい。
【0161】
なお、本実施形態では、上述したように、基本的には、コンテンツ処理部159により提供される特定のコンテンツは、コンテンツ提供位置ごとに異なる。例えば、一のコンテンツ提供位置で提供される特定のコンテンツは、他の一のコンテンツ提供位置で提供される特定のコンテンツとは異なる。ただし、同じ特定のコンテンツが、複数のコンテンツ提供位置で提供可能とされてもよい。
【0162】
対話処理部160は、第1対話処理部1601と、第2対話処理部1602とを含む。
【0163】
第1対話処理部1601は、複数の一般ユーザからの入力に基づいて、ネットワーク3を介した一般ユーザ間の対話を可能とする。対話は、対応するユーザアバタm1を介して、テキスト及び/又は音声によるチャット形式で実現されてもよい。これにより、一般ユーザ同士で対話が可能となる。なお、テキストは、端末装置20の表示部23に出力される。例えば、テキストは、仮想空間に係る画像とは別に出力されてもよいし、仮想空間に係る画像に重畳して出力されてもよい。端末装置20の表示部23に出力されるテキストによる対話は、不特定多数のユーザに公開される形式で実現されてもよいし、特定の一般ユーザ間のみで公開される形式で実現されてもよい。これは、音声によるチャットも同様である。
【0164】
本実施形態では、第1対話処理部1601は、ユーザアバタm1のそれぞれの位置に基づいて、対話が可能な複数の一般ユーザを決定してもよい。例えば、第1対話処理部1601は、一のユーザアバタm1と他の一のユーザアバタm1との間の距離が所定距離d1以下である場合に、当該一のユーザアバタm1と当該他の一のユーザアバタm1のそれぞれに係る一般ユーザ間の対話を可能としてもよい。所定距離d1は、仮想空間や各部屋の広さ等に応じて適宜設定されてよく、固定であってもよいし、可変とされてもよい。また、端末用画像には、所定距離d1に対応する範囲が色付け等により表現されてもよい。例えば赤エリアには、声が届くが、青エリアには、声が届かないといった態様である。
【0165】
また、本実施形態では、第1対話処理部1601は、所定関係を有さない一般ユーザ間での対話を、所定関係を有する一般ユーザ間での対話よりも、制限してもよい。対話の制限は、対話できる時間や頻度等の制限により実現されてもよい。また、対話の制限は、対話の禁止を含む概念である。
【0166】
所定関係は、任意であるが、グループを形成する関係であってもよいし、親子や近親者である関係、年齢が近い関係等であってもよい。あるいは、所定関係は、所定のアイテム(例えば鍵など)を有している関係であってもよい。また、次の部屋の方向を示す矢印のようなオブジェクトを効果音やサインボードとともに表示してもよい。また、強制的に逆走(例えば、前の部屋に戻る移動)ができないような制限領域を増やしたり、移動不可能なエリアの地面を崩壊させたり、暗転させるといった効果を加えてもよい。
【0167】
本実施形態では、所定関係は、空間状態記憶部146内のデータに基づいて判定されてもよい。この場合、所定関係は、同様のユーザ状態情報を有する関係であってもよい。例えば、第1対話処理部1601は、同じコンテンツ提供位置に係る空間部分(部屋)に位置するユーザアバタm1のそれぞれに係る一般ユーザ間の対話を可能としてもよい。これにより、例えばグループで仮想空間内に訪問した複数の一般ユーザの場合、だれかが次の部屋に移動すると、グループ内での対話が不能になるので、かかる変化を楽しむこともできる。あるいは、次の部屋に移動した友人に追いつこうとする動機づけを与えることができる。また、これにより、自然な誘導でユーザの行動を制御できるため、ユーザの誘導を行うスタッフユーザの数を節減できる効果がある。また、残っているユーザが自分だけであることを示すために、各部屋の存在人数を画面に表示したり「みなさん次の部屋で待ってますよ」といったメッセージを表示してもよい。
【0168】
第2対話処理部1602は、一般ユーザからの入力と、スタッフユーザからの入力に基づいて、ネットワーク3を介した一般ユーザとスタッフユーザとの間の対話を可能とする。対話は、対応するユーザアバタm1とスタッフアバタm2とを介して、テキスト及び/又は音声によるチャット形式で実現されてもよい。
【0169】
また、第2対話処理部1602は、上述したように、スタッフアバタ処理部154の補助情報提供部1544と協動して、又は、補助情報提供部1544に代えて、機能してもよい。これにより、一般ユーザは、スタッフユーザからリアルタイムで補助(アシスタント)を受けることができる。
【0170】
また、第2対話処理部1602は、複数のスタッフユーザからの入力に基づいて、ネットワーク3を介したスタッフユーザ間の対話を可能としてもよい。スタッフユーザ間の対話は、非公開形式であってよく、例えばスタッフユーザ間のみで開示されてもよい。あるいは、第2対話処理部1602は、スタッフユーザに付与される権限情報に基づいて、対話可能なスタッフユーザの範囲を可変してもよい。例えば、第2対話処理部1602は、統括権限を有するスタッフユーザに係るスタッフアバタm2に対して、すべてのスタッフユーザに対して対話できる権限を付与し、操作権限を有するスタッフユーザに係るスタッフアバタm2に対して、一定の場合だけ統括権限を有するスタッフユーザに対して対話できる権限を付与してもよい。
【0171】
本実施形態では、第2対話処理部1602は、ユーザアバタm1のそれぞれの位置と、スタッフアバタm2の位置とに基づいて、複数の一般ユーザのうちの、スタッフユーザと対話が可能な一般ユーザを決定する。例えば、上述した第1対話処理部1601と同様に、一のスタッフアバタm2と一のユーザアバタm1との間の距離が所定距離d2以下である場合に、当該一のスタッフアバタm2に係るスタッフユーザと当該一のユーザアバタm1に係る一般ユーザ間の対話を可能としてもよい。所定距離d2は、仮想空間や各部屋の広さ等に応じて適宜設定されてよく、固定であってもよいし、可変とされてもよい。また、所定距離d2は、上述した所定距離d1よりも長くてもよい。
【0172】
また、第2対話処理部1602は、スタッフユーザに付与される権限情報に基づいて、対話能力を可変してもよい。例えば、第2対話処理部1602は、統括権限を有するスタッフユーザに係るスタッフアバタm2に対して、最も大きい所定距離d2を適用し、操作権限を有するスタッフユーザに係るスタッフアバタm2に対して、次に大きい所定距離d2を適用してもよい。また、第2対話処理部1602は、統括権限を有するスタッフユーザに係るスタッフアバタm2に対して、すべてのユーザと対話できる機能(天の声のような機能)を付与してもよい。あるいは、第2対話処理部1602は、統括権限を有するスタッフユーザに係るスタッフアバタm2に対して、任意の対話を可能とするが、他の権限のスタッフユーザに係るスタッフアバタm2に対しては、それらの役割に関する対話のみを可能としてもよい。
【0173】
また、本実施形態では、第2対話処理部1602は、スタッフユーザからの要求(入力)に基づいて、当該スタッフユーザと対話が可能な一般ユーザを変更してもよい。例えば、第2対話処理部1602は、上述した所定距離d2を一時的に増加することで、スタッフユーザと対話が可能となる一般ユーザの範囲を広げてもよい。これにより、例えばスタッフユーザは、自身のスタッフアバタm2からは比較的離れた位置に補助を必要としそうなユーザアバタm1を自ら見つけたときに、比較的速やかに当該ユーザアバタm1の一般ユーザに話しかけることが可能である。なお、この場合、スタッフ動作処理部1542は、スタッフユーザのスタッフアバタm2を、比較的離れたユーザアバタm1の近傍まで瞬時に移動させてもよい(すなわち、上述した所定法則に反した動きを実現してもよい)。これにより、話しかけられた一般ユーザは、自身の端末装置20に表示される端末用画像を介して、話しかけてきたスタッフアバタm2をすぐに認識できるので、安心感が高まり、スムーズな対話による補助を受けることができる。
【0174】
活動制限部162は、仮想空間内における各ユーザアバタm1の活動であって、コンテンツ処理部159により提供される複数のコンテンツに係る活動を制限する。コンテンツに係る活動とは、コンテンツの提供を受けること自体であってよく、更に、コンテンツの提供を受けるための行動(例えば移動)等を含んでもよい。
【0175】
本実施形態では、活動制限部162は、空間状態記憶部146内のデータに基づいて、活動を制限する。
【0176】
具体的には、活動制限部162は、次室移動条件の成否情報(
図9参照)に基づいて、仮想空間内における各ユーザアバタm1の活動を制限する。例えば、活動制限部162は、ある一のコンテンツ提供条件を満たさない一般ユーザに対しては、当該一のコンテンツ提供位置への移動を禁止する。このような移動の禁止は、任意の態様で実現されてもよい。例えば、活動制限部162は、当該一のコンテンツ提供位置への入口を、当該一のコンテンツ提供条件を満たさない一般ユーザに対してだけ無効化してもよい。このような無効化は、当該入口を不可視又は視認困難な状態にすることや、ユーザアバタm1が通れない当該入口の壁を設定すること等により実現されてもよい。
【0177】
他方、活動制限部162は、ある一のコンテンツ提供条件を満たしている一般ユーザに対しては、当該一のコンテンツ提供位置への移動を許可する。このような移動の許可は、任意の態様で実現されてもよい。例えば、活動制限部162は、当該一のコンテンツ提供位置への入口を、当該一のコンテンツ提供条件を満たす一般ユーザに対してだけ有効化してもよい。このような有効化(無効化された状態からの遷移)は、当該入口を不可視状態から可視状態に変更することや、ユーザアバタm1が通れない当該入口の壁を除去すること等により実現されてもよい。また、このような移動の許可は、スタッフユーザによる入力に基づいて実現されてもよい。この場合、スタッフユーザは、通常は見えない情報(例えば次室移動条件の成否情報)に基づいて、自室移動条件を満たすユーザアバタm1を検出してもよい。また、このような空間的な移動や可視性だけでなく、許可された一般ユーザは、まだ許可されていない一般ユーザと対話(例えば音声会話)をできない状態にする、といった具合に、第1対話処理部1601による分断も実現可能であってよい。これによって、例えば、先行者の一般ユーザによる後続者のユーザへの不要なヒントの流出やネタバレ等を防ぐことができる。また、後続者の一般ユーザは、自ら回答を発見しない限り、次のステップに進むことができないため、このような一般ユーザに主体的な参加(解決)を促すことができる。
【0178】
条件処理部164は、スタッフユーザからの入力に基づいて、複数の一般ユーザのうちの一部の一般ユーザに対して、コンテンツ処理部159により提供可能な複数の特定のコンテンツのうちの、一部又は全部のコンテンツ提供条件を緩和する。あるいは、条件処理部164は、スタッフユーザからの入力に基づいて、複数の一般ユーザのうちの一部の一般ユーザに対して、コンテンツ処理部159により提供可能な複数の特定のコンテンツのうちの、一部又は全部のコンテンツ提供条件を厳しくしてもよい。すなわち、条件処理部164は、スタッフユーザからの入力に基づいて、特定の一の一般ユーザに対して適用されるコンテンツ提供条件を、通常条件と緩和条件(
図8参照)の間で変更してもよい。これにより、スタッフユーザの裁量等によりコンテンツ提供条件の厳しさを変更できるので、一般ユーザのそれぞれの適用度やレベルに応じて、適切なコンテンツ提供条件を設定できる。
【0179】
本実施形態において、条件処理部164は、すべてのスタッフユーザからの入力に基づいて、コンテンツ提供条件を変更してもよいが、一定条件を満たすスタッフユーザからの入力に基づいて、コンテンツ提供条件を変更してもよい。例えば、条件処理部164は、統括権限を有するスタッフユーザからの入力に基づいて、コンテンツ提供条件を変更してもよい。これにより、統括権限を有するスタッフユーザのみが適切なコンテンツ提供条件を設定できるので、一般ユーザ間のバランスの公平化を図ることができる。
【0180】
抽出処理部166は、一般ユーザのそれぞれに対応付けられたユーザ状態情報900(
図9参照)に基づいて、コンテンツ処理部159により提供可能な複数の特定のコンテンツのうちの所定数以上のコンテンツの提供又は特定のコンテンツの提供を受けた第1ユーザを抽出する。所定数は、1以上の任意であるが、N個の特定のコンテンツが提供可能な仮想空間においては、例えばN/2個であってもよいし、N個であってもよい。
【0181】
役割割当部167は、スタッフユーザからの入力に基づいて、又は、スタッフユーザからの入力に基づかずに、抽出処理部166により抽出された一般ユーザに対応付けられたユーザアバタm1に対して、仮想空間内におけるスタッフアバタm2に係る役割の少なくとも一部を付与する。すなわち、当該一般ユーザを、スタッフユーザになることができる一般ユーザに変換し、当該一般ユーザに係るスタッフ可否情報を更新し、スタッフIDを付与する。役割割当部167により一般ユーザに付与される役割は、任意であり、例えば、統括権限を有するスタッフユーザの役割のうちの、重要度の比較的低い一部であってもよい。また、例えば、役割割当部167により一般ユーザに付与される役割は、通常権限が与えられたスタッフユーザと同じ役割であってもよいし、その一部であってよい。あるいは、役割割当部167により一般ユーザに付与される役割は、操作権限が与えられたスタッフユーザと同じ役割であってもよいし、その一部であってよい。
【0182】
この場合、役割割当部167は、統括権限を有するスタッフユーザからの入力に基づいて、仮想空間内におけるスタッフアバタm2に係る役割の少なくとも一部を付与してもよい。これにより、統括権限を有するスタッフユーザの責任で、候補となる一般ユーザを選択できる。従って、統括権限を有するスタッフユーザは、例えば、与えられる予定の役割に対する理解が比較的深い一般ユーザに、スタッフユーザとして効率的に機能してもらい、当該役割を適切に果たしてもらうことができる。
【0183】
また、統括権限を有するスタッフユーザは、抽出処理部166により抽出された一般ユーザ以外からも、自ら、候補となる一般ユーザを探索/勧誘することも可能である。例えば、ある商品(例えばアバタが装着可能な衣服)を販売するスタッフユーザが欠員する状況下では、統括権限を有するスタッフユーザは、当該商品を購買する頻度や数が大きい一般ユーザを探索し(例えばユーザ情報600の購買アイテム情報に基づいて探索し)、当該アイテムを購買するスタッフユーザにならないかどうか勧誘することも可能である。この場合、当該商品を購買する頻度や数が大きい一般ユーザは、当該商品に詳しい可能性が高く、かかる商品を購買しようとしている一般ユーザに対して、スタッフユーザとして適切なアドバイス等を行うことを期待できる。
【0184】
なお、役割割当部167は、一般ユーザからスタッフユーザに変換したユーザに対して、統括権限を有するスタッフユーザからの入力に基づいて、付与する役割を増減させてもよい。これにより、一般ユーザからスタッフユーザに変換したユーザに係る役割の負担を適宜調整できる。このようにしてスタッフユーザに変換された一般ユーザには、スタッフユーザとして、
図6のスタッフ情報602で示すような各種の情報が割り当てられてよい。この場合、一般ユーザからスタッフユーザに変換したユーザに対しては、スタッフ情報602の権限情報に代えて又は加えて、役割に関する情報が対応付けられてもよい。役割に関する情報の粒度は任意であり、役割の粒度に応じて適合されてよい。これは、スタッフユーザの役割(権限情報)についても同様である。
【0185】
このようにして、本実施形態では、ユーザは、一般ユーザからスタッフユーザになることができ、スタッフユーザになりたいユーザに対して、所定数以上のコンテンツの提供を受ける動機づけを与えることができる。所定数以上のコンテンツの提供を受けた一般ユーザは、当該コンテンツから、与えられる役割を果たせるような能力を身に付けている可能性が高く、特定のコンテンツを介したスキルアップを効率的に図ることができる。
【0186】
なお、本実施形態において、スタッフユーザになることができるユーザは、仮想空間内に入る際に、一般ユーザとして入るか、スタッフユーザとして入るかを、選択できてもよい。
【0187】
空間情報生成部168は、上述した空間状態記憶部146内に格納される空間状態情報を生成し、空間状態記憶部146内のデータを更新する。例えば、空間情報生成部168は、定期的に又は不定期的に、入室ユーザのそれぞれに対して、次室移動条件の成否を監視し、次室移動条件の成否情報を更新する。
【0188】
パラメータ更新部170は、上述したスタッフポイントを更新する。例えば、パラメータ更新部170は、
図9に示す空間状態情報に基づいて、各スタッフユーザの稼働状況に応じてスタッフポイントを更新してよい。例えば、パラメータ更新部170は、稼働時間が長くなるほど多くのスタッフポイントを付与する態様で、スタッフポイントを更新してよい。また、パラメータ更新部170は、チャット等による一般ユーザへの補助回数等(発話量や、発話回数、アテンド回数、クレーム対応回数等)に基づいて、スタッフポイントを更新してよい。また、仮想現実において商品やサービスの販売が行われる場合、パラメータ更新部170は、スタッフユーザによる商品やサービスの販売の状況(例えば売り上げ)に基づいて、スタッフポイントを更新してよい。あるいは、パラメータ更新部170は、一般ユーザにより入力されうるスタッフユーザに対する満足度情報(例えばアンケート情報に含まれる評価値等)に基づいて、スタッフポイントを更新してよい。なお、スタッフポイントの更新は、適宜、実行されてもよく、例えば定期的に、ログ情報に基づいて一括的に実行されてもよい。
【0189】
スタッフユーザにより販売される商品やサービスは、現実で利用可能な商品やサービスであってもよいし、仮想現実において利用可能な商品やサービスであってもよい。スタッフユーザにより販売される商品やサービスは、コンテンツ提供位置で提供されるコンテンツに関連してよく、例えば当該コンテンツに係る体験を増大できるようなアイテム等を含んでよい。例えば、コンテンツが、上述した旅行に関連する場合、アイテムは、遠くを見ることができる望遠鏡等であってもよいし、動物等に与えることができる餌等であってもよい。また、コンテンツが、スポーツやコンサートに関連する場合、アイテムは、応援グッズや、選手やアーティストとの記念撮影権や会話権等であってもよい。
【0190】
スタッフ管理部180は、仮想空間におけるスタッフユーザによるスタッフアバタm2を介した活動等に基づいて、スタッフユーザを管理する。
【0191】
本実施形態では、スタッフユーザは、仮想現実を一般ユーザとして体験することも可能である。すなわち、スタッフユーザは、例えば自身の選択に応じて、スタッフユーザとなることも、一般ユーザとなることも可能である。換言すると、スタッフユーザは、スタッフユーザとなることが可能な一般ユーザである。なお、これは、上述した役割割当部167により、スタッフユーザになることができるユーザについても同様である。スタッフユーザとなることが可能な一般ユーザは、スタッフユーザとなることが不能な一般ユーザとは異なり、特別なアイテム(第2オブジェクトm3)として、制服を装着できる。
【0192】
スタッフ管理部180は、第1判定部1801と、第1属性変更部1802と、評価部1803と、第2判定部1804と、第2属性変更部1805と、インセンティブ付与部1806とを含む。
【0193】
第1判定部1801は、一のユーザがスタッフユーザと一般ユーザとの間で変化したか否かを判定する。すなわち、第1判定部1801は、一のユーザの属性が変化したか否かを判定する。第1判定部1801は、後述する第1属性変更部1802や第2属性変更部1805により一のユーザの属性が変更された場合に、当該一のユーザの属性が変化したと判定する。
【0194】
第1判定部1801は、一のユーザがスタッフユーザと一般ユーザとの間で変化したと判定した場合に、端末画像生成部1581に対して当該変化を反映させる。具体的には、端末画像生成部1581は、一のユーザがスタッフユーザと一般ユーザとの間で変化した場合に、当該一のユーザに係るアバタが描画されている端末用画像(一般ユーザ用の端末用画像及び/又はスタッフユーザ用の端末用画像)において、当該変化を当該一のユーザに係るアバタの描画態様に反映させる。例えば、一のユーザがスタッフユーザから一般ユーザへ変化した場合は、端末画像生成部1581は、当該一のユーザに対応するアバタをユーザアバタm1として描画する。他方、一のユーザが一般ユーザからスタッフユーザへ変化した場合は、端末画像生成部1581は、当該一のユーザに対応するアバタをスタッフアバタm2(すなわち制服を着用しているアバタ)として描画する。
【0195】
また、第1判定部1801は、一のユーザがスタッフユーザと一般ユーザとの間で変化したと判定した場合に、パラメータ更新部170に対して当該変化をスタッフポイント(
図6参照)に反映させる。例えば、パラメータ更新部170は、一のユーザがスタッフユーザに変化した場合、当該一のユーザの労働時間のカウントを開始し、その後、当該一のユーザが一般ユーザに変化した場合、当該一のユーザの労働時間のカウントを終了してよい。なお、スタッフポイントの更新は、リアルタイムに実現されてもよいし、事後的に実現されてもよい。
【0196】
第1属性変更部1802は、一のユーザ(スタッフユーザとなることが可能な一般ユーザ)からのユーザ入力である属性変化要求(所定入力の一例)に基づいて、一のユーザをスタッフユーザと一般ユーザとの間で変化させる。すなわち、第1属性変更部1802は、一のユーザからの属性変化要求に基づいて、当該一のユーザの属性を変化させる。
【0197】
属性変化要求は、直接的な要求(例えばスタッフユーザや一般ユーザを指定する入力)であってもよいし、間接的な要求であってよい。間接的な要求の場合、属性変化要求は、例えば、自身のユーザアバタm1に共通の可視特徴が対応付けられるような要求であり、アバタに係る私服から制服への着替え要求、又は、アバタに係る制服から私服への着替え要求を含んでよい。この場合、アバタに係る私服から制服への着替え要求は、一般ユーザからスタッフユーザへの属性変化要求に対応し、アバタに係る制服から私服への着替え要求は、スタッフユーザから一般ユーザへの属性変化要求に対応する。また、複数種類の共通の可視特徴のうちから所望の共通の可視特徴を選択できるスタッフユーザに関しては、当該スタッフユーザに係る属性変化要求は、複数種類の共通の可視特徴のうちから、当該スタッフユーザが選択した共通の可視特徴の種類を表す情報を含んでもよい。
【0198】
なお、ユーザ(スタッフユーザとなることが可能な一般ユーザ)による属性変化要求は、任意のタイミングで入力可能であってもよい。例えば、スタッフユーザとなることが可能な一般ユーザは、例えばそのときの気分や状況等に応じて、仮想空間内に入った後に、一般ユーザからスタッフユーザへと、又は、スタッフユーザから一般ユーザへと、変化できてもよい。あるいは、ユーザによる属性変化要求は、所定条件下で入力可能であってもよい。例えば、スタッフユーザから一般ユーザへの属性変化要求は、仮想空間内に補助対象のユーザアバタm1が存在しない場合や、当該スタッフユーザに係るスタッフアバタm2が補助に係る活動中(例えば補助対象のユーザアバタm1と対話中)でない場合等に、入力可能であってもよい。また、一般ユーザからスタッフユーザへの属性変化要求は、例えば当該一般ユーザに係るユーザアバタm1が所定位置(例えば、
図2Dに示す位置SP202や、
図2Dに示す自身のロッカー84の近傍位置等)に位置する場合に、入力可能であってもよい。
【0199】
評価部1803は、一のユーザがスタッフユーザであるときに、当該一のユーザがスタッフユーザとしての所定役割を適切に果たしているかを評価する。所定役割は、当該一のユーザがスタッフユーザであるときに付与されている役割であり、上述したように、当該スタッフユーザの権限に応じて異なる。この場合、評価部1803は、各スタッフユーザの役割を、スタッフ情報602(
図6参照)の権限情報に基づいて判断してよい。評価部1803は、基本的には、スタッフユーザがさぼって活動していない(ユーザアバタm1の位置や視線等の方向が変化しない、発話がない等)場合、後述する所定基準を満たさないような低い評価結果を付与してよい。
【0200】
例えば、評価部1803は、通常権限を有するスタッフユーザに対しては、一般ユーザへの上述した所定情報の提供状況に基づいて、所定役割を適切に果たしているかを評価してよい。この場合、評価部1803は、通常権限を有するスタッフユーザに対しては、統括権限を有するスタッフユーザからの評価入力(当該通常権限を有するスタッフユーザに対する評価入力)に更に基づいて、所定役割を適切に果たしているかを評価してよい。同様に、評価部1803は、操作権限を有するスタッフユーザに対しては、演出用の各種操作を適切に実行しているか否かに基づいて、所定役割を適切に果たしているかを評価してよい。この場合も、評価部1803は、操作権限を有するスタッフユーザに対しては、統括権限を有するスタッフユーザからの評価入力(当該操作権限を有するスタッフユーザに対する評価入力)に更に基づいて、所定役割を適切に果たしているかを評価してよい。なお、評価部1803は、統括権限を有するスタッフユーザに対しては評価を行わなくてもよい。統括権限を有するスタッフユーザは、他のスタッフユーザを評価する側であるためである。
【0201】
あるいは、評価部1803は、パラメータ更新部170により更新されるスタッフポイント(
図6参照)に基づいて、一のユーザがスタッフユーザとしての所定役割を適切に果たしているかを評価してもよい。この場合、評価部1803は、パラメータ更新部170により更新されるスタッフポイントの値自体やその増加態様に基づいて、各スタッフユーザの評価を実現してもよい。
【0202】
また、評価部1803は、スタッフユーザが一般ユーザを補助している際の、スタッフアバタm2の視線方向(例えば眼球の向き)に基づいて、スタッフユーザの評価を実現してもよい。この場合、スタッフアバタm2がユーザアバタm1の方を向いて対話しているかどうかが、対話内容が適切であるかどうか等の評価項目に加えて、評価されてもよい。また、視線方向に代えて、顔向きや、距離(仮想空間内におけるスタッフアバタm2とユーザアバタm1との間の距離)、位置(例えば、補助対象のユーザアバタm1に対する立ち位置)等が考慮されてもよい。また、指定されたイベントに参加して拍手やコメントをする(いわゆるモブ(群衆)、エキストラ、にぎやかし、応援団等)のような役割が付与されているスタッフアバタm2の場合、拍手やコメントの頻度や内容等が考慮されてもよい。
【0203】
また、評価部1803は、スタッフユーザが一般ユーザを補助した後の、一般ユーザの活動に基づいて、スタッフユーザの評価を実現してもよい。この場合、例えば展示場に係る仮想空間においては、一般ユーザが、スタッフユーザの補助を受けることで、所望の目的位置(店舗等)にスムーズにたどり着けたかどうかが、評価されてもよい。また、就職斡旋に係る仮想空間において、一般ユーザが、スタッフユーザの補助を受けることで、所望の目的位置(所望の会社のブース等)にスムーズにたどり着けたかどうかが、評価されてもよい。
【0204】
また、評価部1803は、スタッフユーザが一般ユーザを補助する際の、立ち振舞方に基づいて、スタッフユーザの評価を実現してもよい。この場合、例えば料亭に係る仮想空間においては、女将さんの役割を果たすスタッフアバタm2が、お客様であるユーザアバタm1に対して、適切な作法でおもてなしができているかどうかが、評価されてもよい。
【0205】
また、評価部1803は、例えば契約等により労働条件(例えば労働時間など)が定められている場合は、労働条件が満たされているか否かに基づいて、スタッフユーザの評価を実現してもよい。
【0206】
また、評価部1803は、例えば、KPI(Key Performance Indicator)といった各種の指標値や売上成績を用いて、各スタッフユーザを評価してもよい。
【0207】
第2判定部1804は、評価部1803による評価結果が所定基準を満たしているか否かを判定する。例えば、評価部1803による評価結果は、“優”、“普通”、“不可”の3段階で出力される場合、評価結果“優”又は“普通”は所定基準を満たしてよい。
【0208】
第2属性変更部1805は、第2判定部1804により所定基準を満たしていないと判定されたスタッフユーザを、一般ユーザへと強制的に(すなわち上述した属性変化要求とは無関係に)変更する。これにより、所定役割を適切に果たしていないスタッフユーザを排除して仮想空間内でのスタッフユーザによるユーザ補助機能の有用性を適切に維持できる。また、スタッフユーザに対して所定役割を適切に果たそうと心がける動機づけを与えることができる。
【0209】
インセンティブ付与部1806は、パラメータ更新部170により更新されるスタッフポイントの値に基づいて、スタッフユーザのそれぞれにインセンティブを付与する。なお、インセンティブ付与部1806による付与対象のスタッフユーザは、すべてのスタッフユーザであってもよいし、統括権限を有するスタッフユーザ以外のすべてのスタッフユーザであってもよい。
【0210】
一のスタッフユーザに与えられるインセンティブは、任意であり、当該一のスタッフユーザのスタッフアバタm2が配置される仮想空間において使用できるアイテム等であってもよいし、当該一のスタッフユーザのスタッフアバタm2が配置される仮想空間とは異なる他の仮想空間において使用できるアイテム等であってもよい。また、インセンティブは、昇格に対応する所定役割の変更や、通常権限から操作権限への変更等であってよい。また、インセンティブは、スタッフユーザへの給与とは別のボーナスであってよい。
【0211】
図5は、一般ユーザに係る端末装置20により実現される機能500と、スタッフユーザに係る端末装置20により実現される機能502とが併せて示されている。なお、
図5は、端末装置20にダウンロード等される仮想現実アプリケーションにより実現される各種機能のうちの、ユーザ補助機能に関連した機能だけを示す。なお、仮想現実アプリケーションは、機能500を実現するユーザ用アプリケーションと、機能502を実現するスタッフ用アプリケーションとが別々に実装可能であってもよいし、一のアプリケーション内で機能500と機能502とはユーザによる操作により切り替え可能とされてもよい。
【0212】
一般ユーザに係る端末装置20は、補助要求部250を含む。補助要求部250は、一般ユーザからの入力に基づいて、補助要求をネットワーク3を介してサーバ装置10に送信する。なお、補助要求は、端末装置20に対応付けられた端末ID又はログインしている仮想現実アプリケーションのユーザIDを含むことで、補助要求に基づいて補助対象のユーザアバタm1がサーバ装置10において特定される。
【0213】
なお、本実施形態では、補助対象のユーザアバタm1は、上述したように、サーバ装置10の補助対象検出部157により検出されるので、補助要求部250は適宜省略されてもよい。
【0214】
スタッフユーザに係る端末装置20は、支援実行部262と、条件変更部263と、役割付与部264とを含む。なお、以下で説明するスタッフユーザに係る端末装置20により実現される機能502の機能の一部又は全部は、サーバ装置10により実現されてもよい。また、
図5に示す支援実行部262、条件変更部263、及び役割付与部264は、一例であり、一部が省略されてもよい。
【0215】
支援実行部262は、スタッフユーザからの所定入力に基づいて、上述した補助情報提供部1544により一般ユーザに補助情報を提供するための補助要求を、ネットワーク3を介してサーバ装置10に送信する。例えば、支援実行部262は、スタッフユーザからの所定入力に応答して、サーバ装置10の補助対象検出部157により検出されたユーザアバタm1を補助情報の伝達対象とした補助要求を、サーバ装置10に送信する。なお、補助情報の伝達対象のユーザアバタm1は、スタッフユーザが自身で決定してもよい。例えば、スタッフユーザは、上述したように、端末用画像において描画されうる、通常は見えない情報(例えば次室移動条件の成否情報)に基づいて、補助対象のユーザアバタm1(補助対象検出部157により検出されないユーザアバタm1)を特定してもよい。また、補助要求は、生成する補助情報の内容を指示する情報等を含んでよい。
【0216】
条件変更部263は、スタッフユーザからの入力に基づいて、上述したような条件処理部164による条件変更を指示する要求(条件変更要求)を、サーバ装置10に送信する。例えば、条件変更部263は、スタッフユーザからの条件変更用の入力に応答して、特定のユーザアバタm1を対象とした条件変更要求を、サーバ装置10に送信する。なお、特定のユーザアバタm1は、サーバ装置10の補助対象検出部157により検出された補助対象のユーザアバタm1であってもよいし、補助情報の伝達対象と同様、スタッフユーザが自身で決定してもよい。
【0217】
役割付与部264は、スタッフユーザからの入力に基づいて、上述したような役割割当部167による役割の付与を指示する要求(役割付与要求)を、サーバ装置10に送信する。例えば、役割付与部264は、スタッフユーザからの役割付与用の入力に応答して、役割付与要求を、サーバ装置10に送信する。なお、役割付与要求は、役割を付与する対象となるユーザアバタm1を特定する情報や、付与する役割の内容を示す情報等を含んでよい。
【0218】
(ユーザ補助機能に関連した動作例)
次に、
図10から
図18を参照して、上述したユーザ補助機能に関連した動作例について説明する。なお、以下の動作例は、具体的な動作例であるが、上述したユーザ補助機能に関連した動作は、上述したように、多様な態様で実現可能である。
【0219】
以下では、一例として、
図2Bに示した仮想空間に関して、上述したユーザ補助機能に関連した動作例について説明する。
【0220】
図10は、上述したユーザ補助機能に関連した動作例を示すタイミングチャートである。
図10では、区別のために、ある一般ユーザに係る端末装置20に対して、符号「20-A」を付与し、他の一般ユーザに係る端末装置20に対して、符号「20-B」を付与し、スタッフユーザに係る端末装置20に対して、符号「20-C」を付与している。以下では、説明上、端末装置20-Aに係る一般ユーザを、ユーザ名「ami」とし、端末装置20-Bに係る一般ユーザを、ユーザ名「fuj」とし、両者は学生(例えば、ユーザ名「ami」が学生Aで、ユーザ名「fuj」が学生B)である。また、以下では、ユーザ名「ami」に係る一般ユーザを、学生ユーザAと称し、ユーザ名「fuj」に係る一般ユーザを、学生ユーザBと称する。また、以下では、複数のスタッフユーザが登場するが、端末装置20-Cは、これらのスタッフユーザに係る各端末装置20を包括した態様で示す。また、
図10において、図面の複雑化防止の都合上、端末装置20-Cから端末装置20-A、20-Bへの補助情報の送信は、直接的な態様で図示されているが、サーバ装置10を介して実現されてよい。
【0221】
【0222】
まず、ステップS10Aにおいて、学生ユーザAは、端末装置20-Aにおいて、仮想現実アプリケーションを起動し、ステップS10Bにおいて、学生ユーザBは、端末装置20-Bにおいて、仮想現実アプリケーションを起動する。なお、仮想現実アプリケーションは、端末装置20-A、20-Bのそれぞれにおいて、時間差をもって起動されてもよいし、起動タイミングは任意である。なお、ここでは、スタッフユーザは、端末装置20-Cにおいて、仮想現実アプリケーションを起動済みであるとするが、この起動タイミングも任意である。
【0223】
ついで、ステップS11Aにおいて、学生ユーザAは、仮想空間内に入り、自身のユーザアバタm1を移動させ、1番目のコンテンツ提供位置に係る入口付近まで至る。同様に、ステップS11Bにおいて、学生ユーザBは、仮想空間内に入り、仮想空間内で自身のユーザアバタm1を移動させ、1番目のコンテンツ提供位置に係る入口付近まで至る。
図11は、学生ユーザBのユーザアバタm1が1番目のコンテンツ提供位置に係る入口付近に位置するときの、学生ユーザB用の端末用画像G110を示す。なお、
図11に示す状態では、学生ユーザAのユーザアバタm1は、学生ユーザBのユーザアバタm1の背後にいるものとする。
図11に示すように、学生ユーザB用の端末用画像G110からは、位置SP1に対応付けて、スタッフ名「cha」が対応付けられたスタッフアバタm2が配置され、1番目のコンテンツ提供位置に係る入口領域に対応する位置SP2に対応付けて、スタッフ名「suk」が対応付けられたスタッフアバタm2が配置されていることがわかる。
【0224】
本実施形態では、
図11に示す端末用画像G110からよくわかるように、スタッフアバタm2は、制服を着用しているので、学生ユーザAや学生ユーザBのような一般ユーザは、他の一般ユーザに係るユーザアバタm1とスタッフアバタm2とを見間違える可能性が低減される。これにより、各ユーザは、なにか困ったことがあった場合等、スタッフユーザからスムーズに支援(補助)を受けることができる。
【0225】
この場合、学生ユーザA及び学生ユーザBは、スタッフ名「cha」のスタッフアバタm2から補助情報の送信(ステップS12)を受けてよい。例えば、学生ユーザA及び学生ユーザBは、入場用チュートリアルのコンテンツの視聴案内を受ける。かかる補助情報は、入場用チュートリアルのコンテンツを視聴するためのURLを含んでよい。
図12は、位置SP1においてスタッフ名「cha」のスタッフアバタm2から補助を受けているときの、学生ユーザB用の端末用画像G120を示す。なお、
図12では、スタッフ名「cha」のスタッフユーザの入力に基づくチャットのテキスト「初めての方は、チュートリアルをどうぞ!」が示されている。なお、この種のチャットは自動的に生成されてもよい。
【0226】
学生ユーザA及び学生ユーザBは、入場用チュートリアルを視聴すると、入口領域に対応する位置SP2へと移動する(ステップS11C、ステップS11D)。この際、学生ユーザA及び学生ユーザBは、位置SP2にて、スタッフ名「suk」のスタッフアバタm2から補助情報の送信(ステップS13)を受けてよい。例えば、学生ユーザA及び学生ユーザBは、次室移動条件に関するアドバイス等の補助を受けてよい。この場合、サーバ装置10は、ステップS13よりも前に、学生ユーザA及び学生ユーザBの次室移動条件が満たされているか否かの入室判定を行う(ステップS14)。ここでは、学生ユーザA及び学生ユーザBは、スタッフユーザからの補助もあり、次室移動条件を満たしているものとする。この場合、サーバ装置10は、1番目のコンテンツ提供位置へと移動するためのURLを、端末装置20-A、20-Bのそれぞれに送信する(ステップS15)。なお、1番目のコンテンツ提供位置へと移動するためのURLは、チケットの形態の第2オブジェクトm3(
図12参照)に描画されてもよい。
【0227】
そして、学生ユーザA及び学生ユーザBは、サーバ装置10から送信されたURLにアクセスすることで、1番目のコンテンツ提供位置(
図13の第1位置SP11参照)に移動する(ステップS16A、S16B)。このようにして、学生ユーザA及び学生ユーザBがそれぞれのユーザアバタm1を1番目のコンテンツ提供位置に移動させると、サーバ装置10は、1番目のコンテンツ提供位置に対応付けられた特定のコンテンツを端末装置20-A、20-Bのそれぞれに送信する(ステップS17)。これにより、学生ユーザA及び学生ユーザBは、1番目のコンテンツ提供位置に対応付けられた特定のコンテンツの提供を受けることができる(ステップS18A、ステップS18B)。
図14は、
図13の第1位置SP11で特定のコンテンツの提供を受けているときの、学生ユーザB用の端末用画像G140を示す。端末用画像G140は、大型スクリーン(第2オブジェクトm3)に対応する画像部G141に、映像コンテンツが出力されている状態に対応する。学生ユーザA及び学生ユーザBは、それぞれの端末用画像G140を介して、大型スクリーン上の映像コンテンツを視聴することで、第1位置SP11で特定のコンテンツの提供を受けることができる。端末用画像G140は、
図14に示すように、学生ユーザBの入力に基づくチャットのテキスト「なるほど、わかりやすいね!」を含んでよい。このようにして、学生ユーザAと学生ユーザBは、一緒に、適宜対話しながら、1番目のコンテンツ提供位置に対応付けられた特定のコンテンツの提供を受けることができる。
【0228】
なお、サーバ装置10は、この間、定期的に又は所定の変化が発生した際に、学生ユーザA及び学生ユーザBのそれぞれのユーザアバタm1の状態に基づいて、適宜、空間状態記憶部146内のデータ(
図9の部屋滞在時間等)を更新する(ステップS19)。
【0229】
学生ユーザA及び学生ユーザBは、1番目のコンテンツ提供位置に対応付けられた特定のコンテンツの提供を受け終えると、当該特定のコンテンツに関連する課題等を提出する(ステップS20A、S20B)。課題等の提出方法は、任意であり、課題提出用のURLが利用されてもよい。サーバ装置10は、学生ユーザA及び学生ユーザBがそれぞれのユーザアバタm1を介した課題の提出結果に基づいて、学生ユーザA及び学生ユーザBの次室移動条件が満たされているか否かの入室判定を行い、空間状態記憶部146内のデータ(
図9の次室移動条件の成否情報参照)を更新する(ステップS21)。
【0230】
学生ユーザA及び学生ユーザBは、課題を提出すると、それぞれのユーザアバタm1を移動させ、2番目のコンテンツ提供位置に係る入口領域まで至る(ステップS22A、S22B)(
図13参照)。サーバ装置10は、学生ユーザA及び学生ユーザBの次室移動条件の可否情報に基づいて、次室移動条件の可否情報に応じた端末用画像を生成する(ステップS23)。ここでは、学生ユーザAは、次室移動条件が満たされているが、学生ユーザBは、次室移動条件が満たされていないものとする。この場合、例えば、サーバ装置10は、学生ユーザAに対して、2番目のコンテンツ提供位置へ移動できる入口を描画した端末用画像を生成し、学生ユーザBに対して、2番目のコンテンツ提供位置へ移動できる入口に壁を描画した端末用画像を生成する。そして、サーバ装置10は、2番目のコンテンツ提供位置へと移動するためのURLを、端末装置20-Aに送信する(ステップS24)。なお、2番目のコンテンツ提供位置へと移動するためのURLは、2番目のコンテンツ提供位置へ移動できる入口を描画した端末用画像に描画されてもよい。この場合、端末装置20-Aは、当該URLを画像認識等により検出し、自動的にアクセスしてもよい。これにより、学生ユーザAは、2番目のコンテンツ提供位置へとユーザアバタm1を進めることができる(ステップS25)。
【0231】
他方、サーバ装置10は、スタッフユーザ用の端末用画像において、学生ユーザBのユーザアバタm1を、補助対象のユーザアバタm1として、他のユーザアバタm1とは異なる態様(上述した所定の描画態様)で描画する(ステップS26)。この場合、補助対象のユーザアバタm1の描画態様は、上述したように、スタッフユーザが見ると、その旨(例えば「特定のコンテンツの提供を受け終えているが、次室移動条件を満たしていないこと」)がわかるような、描画態様であってよい。
【0232】
本実施形態では、サーバ装置10は、補助対象のユーザアバタm1を検出すると、スタッフユーザ用の端末用画像において、補助用のサブ画像をメイン画像上に重畳表示させる。
図15は、補助対象のユーザアバタm1が検出されたときの、スタッフユーザ用の端末用画像G150を示す。スタッフユーザ用の端末用画像G150には、補助対象のユーザアバタm1が検出されたときに、サブ画像G156が出現する。この場合、サブ画像G156には、補助対象のユーザアバタm1(ユーザ名「fuj」)が写されている。スタッフユーザは、例えば、サブ画像G156をタップすることで、スタッフアバタm2をサブ画像G156に係る位置まで瞬間的に移動させることができる。この場合、サブ画像G156が全画面表示となり、
図16に示すような端末用画像G160が、サブ画像G156をタップしたスタッフアバタm2(スタッフ名「zuk」)に係るスタッフユーザの端末装置20-Cに表示される。端末用画像G160においては、補助対象のユーザアバタm1には、対話による補助を必要としている可能性が高いことを示す特徴的な画像部G161が対応付けられている。従って、スタッフユーザは、端末用画像G160に複数のユーザアバタm1が含まれている場合でも、補助対象のユーザアバタm1を容易に特定できる。なお、ここでは、
図13の位置SP14に係る部屋内に位置していたスタッフアバタm2に係るスタッフユーザ(スタッフ名「zuk」)が、サブ画像G156をタップすることで、スタッフアバタm2を第1位置SP11へと瞬時に移動させたものとする。
【0233】
このようにして、スタッフユーザは、補助対象のユーザアバタm1(ユーザ名「fuj」)を見つけると、自身のスタッフアバタm2を補助対象のユーザアバタm1(ユーザ名「fuj」)のそばに移動させ、対話等により補助情報を伝達できる。上述したように、スタッフユーザ用の端末用画像においては、通常は見えない情報(例えば次室移動条件を満たしていない理由等)が描画される。従って、スタッフユーザは、ユーザ名「fuj」のユーザアバタm1が次室移動条件を満たしていない理由を把握できるので、その理由に応じた適切な補助情報を伝達できる。ここでは、
図13の位置SP14に係る部屋内に位置していたスタッフアバタm2に係るスタッフユーザ(スタッフ名「zuk」)は、スタッフアバタm2を第1位置SP11へと瞬時に移動させ、対話により補助情報をユーザ名「fuj」の一般ユーザに伝達する(ステップS27)。
図17は、補助情報が伝達されたときの、学生ユーザB用の端末用画像G170を示す。端末用画像G170は、
図17に示すように、ヒントを示す画像部G171や、スタッフアバタm2(スタッフ名「zuk」)に係るスタッフユーザの入力に基づくチャットのテキスト「これがヒントだよ!」を含んでよい。これにより、学生ユーザBは、次の部屋に進めなかった理由を把握できるとともに、ヒントに基づいて、次室移動条件を満たすような課題等を再提出できる(ステップS28)。
【0234】
このようにして、学生ユーザA及び学生ユーザBは、各部屋(各コンテンツ提供位置)で、対応する特定のコンテンツの提供を受け、かつ、スタッフユーザからの補助を適宜受けながら、対応する課題をクリアすることで、次の部屋へと順に進んでいく。この間、スタッフユーザにより補助を受けることでスムーズに、例えばゴールである第8位置SP18へと、進むことができる。
図18は、ゴールである第8位置SP18まで移動できたときの、学生ユーザB用の端末用画像G180を示す。端末用画像G180は、
図18に示すように、終了証の画像部G181や、スタッフアバタm2(スタッフ名「sta」)に係るスタッフユーザの入力に基づくチャットのテキスト「Congratulations!」を含んでよい。また、修了証は、今回の成績等が記載されていてよい。なお、このような修了証を得た一般ユーザは、対応するコンテンツ提供用の仮想空間部においてスタッフユーザとして機能できる役割が付与される候補として、上述した抽出処理部166により抽出されてもよい。あるいは、このような修了証を得た一般ユーザには、対応するコンテンツ提供用の仮想空間部においてスタッフユーザとして機能できる役割が、上述した役割割当部167により自動的に付与されてもよい。
【0235】
なお、本実施形態では、
図11に示す端末用画像G110に示すように、各スタッフアバタm2には、それぞれに対応するスタッフ名(例えば「cha」)の表示が対応付けられているが、これに代えて、スタッフアバタm2のすべてに「staff」といった表示(共通の可視特徴)が対応付けられてもよい。この場合、「staff」の表示は、例えば「senior staff」といった具合に、権限情報ごとに表示が異なってもよい。この場合、スタッフユーザ用の端末用画像においてだけ、各スタッフアバタm2には、それぞれに対応するスタッフ名(例えば「cha」)の表示が対応付けられてもよい。すなわち、スタッフユーザ用の端末用画像においては、各スタッフアバタm2には、それぞれに対応するスタッフ名(例えば「cha」)の表示が対応付けられ、一般ユーザ用の端末用画像においては、各スタッフアバタm2には、共通の可視特徴「staff」が対応付けられてもよい。これにより、スタッフユーザ間では、各スタッフアバタm2に関する情報(例えばスタッフ名等)を認識できる。
【0236】
また、本実施形態において、共通の可視特徴に酷似する衣服を着用した一般ユーザ(スタッフユーザになりすます一般ユーザ)の出現を防止するための仕組みが付加されてもよい。このような仕組みは、各一般ユーザがユーザアバタm1の衣服を自由にアレンジ(カスタマイズ)できるような仕様である場合に好適である。例えば、サーバ装置10は、定期的に、画像処理により、共通の可視特徴を有する衣服を着用するアバタを検出し、当該アバタに対応付けられているユーザIDの属性が、スタッフユーザであるか否かをチェックしてもよい。これにより、なりすましの一般ユーザの出現に起因してユーザ補助機能が損なわれてしまう可能性を効果的に低減できる。また、スタッフユーザのなりすましを防止する方法として、オフィシャルスタッフ(正規のスタッフユーザ)であるという証明書や腕章のような装身具がスタッフアバタm2に対応付けて描画される方法や、他のユーザがそのスタッフユーザを選択すると(タッチやクリックすると)端末用画像においてスタッフユーザである証明表示が描画される方法、又はこれらの任意の組み合わせが、適宜、採用されてもよい。
【0237】
(スタッフ管理機能に関連した動作例)
次に、
図19を参照して、上述したスタッフ管理機能に関連した動作例について説明する。なお、以下の動作例は、具体的な動作例であるが、上述したスタッフ管理機能に関連した動作は、上述したように、多様な態様で実現可能である。
【0238】
以下では、一例として、
図2B及び
図2Dに示した仮想空間に関して、上述したユーザ補助機能に関連した動作例について説明する。
【0239】
図19は、上述したスタッフ管理機能に関連した動作例を示すタイミングチャートである。
図19では、区別のために、一般ユーザに係る端末装置20に対して、符号「20-A」を付与し、一のスタッフユーザ(スタッフユーザになることができる一般ユーザ)に係る端末装置20に対して、符号「20-D」を付与している。以下では、説明上、端末装置20-Dに係るユーザ(スタッフユーザになることができる一般ユーザ)を、ユーザDとする。また、
図19において、図面の複雑化防止の都合上、端末装置20-Dから端末装置20-Aへの補助情報の送信は、直接的な態様で図示されているが、サーバ装置10を介して実現されてよい。
【0240】
まず、ステップS60において、ユーザDは、端末装置20-Dにおいて、仮想現実アプリケーションを起動し、ついで、ステップS62において、仮想空間内に入り、自身のユーザアバタm1を移動させ、ロッカールームに対応する空間部を形成する位置SP202(
図2D参照)付近に至る。
【0241】
ついで、ステップS64において、ユーザDは、ロッカールームに対応する空間部を形成する位置SP202への移動(ロッカールームへの入室)を要求する。例えば、ユーザDは、アバタが所持するセキュリティカード(第2オブジェクトm3)を所定箇所にかざすことで、位置SP202への移動を要求してもよい。
【0242】
サーバ装置10は、ユーザDに対応するユーザIDと、ユーザデータベース140内のユーザ情報(
図6のスタッフ可否情報参照)に基づいて、ユーザDがスタッフユーザになることができる一般ユーザであるか否かの入室判定を行う(ステップS66)。ここでは、ユーザDは、スタッフユーザになることができる一般ユーザであるので、サーバ装置10は、入室許可を通知する(ステップS68)。例えば、サーバ装置10は、ユーザDに係る端末用画像において、ロッカールームに対応する空間部を形成する位置SP202への移動を制限するドア85(第2オブジェクトm3)が、開状態に描画されるようにすることで、入室許可を通知してもよい。
【0243】
ついで、ステップS70において、ユーザDは、位置SP202へ移動し(ロッカールームへ入室し)(ステップS70)、ロッカールームで自身のユーザアバタm1の衣服を、私服から制服へと着替える(ステップS72)。すなわち、ユーザDは、一般ユーザからスタッフユーザへの属性変化要求を、サーバ装置10に送信する。これに応じて、サーバ装置10は、ユーザDの属性を一般ユーザからスタッフユーザに変更する(ステップS74)。この結果、一般ユーザ用の端末用画像やスタッフユーザ用の端末用画像(当該スタッフユーザに係るスタッフアバタm2が視野内に存在する場合)においては、当該ユーザDのアバタは、制服を着用しているスタッフアバタm2として描画されることになる(ステップS76)。また、サーバ装置10は、属性変更に応じてユーザDの労働時間をカウントするタイマ(労働時間タイマ)を起動する(ステップS78)。なお、労働時間タイマは、ユーザDからのアクションに基づいて起動されてもよい。例えば、ユーザDは、自身のアバタが所持するタイムカード(第2オブジェクトm3)を所定箇所にかざすことで、労働時間タイマの起動を要求してもよい。
【0244】
ユーザDは、スタッフユーザとして、各種の補助情報を一般ユーザに提供する(ステップS80)。これは、例えば、
図10に示した動作例におけるステップS12、ステップS13、ステップS27と同様である。
【0245】
その後、ユーザDは、仮想空間内での労働を終えることとし、ロッカールームで自身のアバタの衣服を、制服から私服へと着替える(ステップS82)。すなわち、ユーザDは、スタッフユーザから一般ユーザへの属性変化要求を、サーバ装置10に送信する。これに応じて、サーバ装置10は、ユーザDの属性をスタッフユーザから一般ユーザに変更する(ステップS84)。この結果、一般ユーザ用の端末用画像やスタッフユーザ用の端末用画像(当該スタッフユーザに係るスタッフアバタm2が視野内に存在する場合)においては、当該ユーザDのアバタは、制服を着用していないユーザアバタm1として描画されることになる(ステップS85)。また、サーバ装置10は、ユーザDの労働時間をカウントするタイマ(労働時間タイマ)を属性変更に応じて停止させ、労働時間を記録する(ステップS86)。なお、労働時間は、上述したように、スタッフポイント(
図7参照)に反映されてよい。また、労働開始時刻と終了時刻が、稼働スタッフ情報902(又はスタッフ情報602)のテーブルに記録されてもよい。
【0246】
なお、ここでは、一例として、ユーザDは、自らの意思(例えば退勤ボタンを押す等の操作)で労働を終えることとしているが、上述したように、第2属性変更部1805により強制的に一般ユーザに属性を変更される場合もありうる。この場合、退職や解雇が実現されてもよい。いずれの場合も、上述したように、一般ユーザに属性が変更された途端に、自動的に制服から私服への着替えと、ロッカーやクローゼット内の私服の削除(制服との入れ替え)とが、同時に実現されてよい。また、退職や解雇の場合、スタッフIDの削除又は無効化とともに、当該スタッフIDに係る各種のアイテムが自動的に削除されてもよい。
【0247】
その後、サーバ装置10は、スタッフユーザとしてのユーザDを評価する(ステップS88)。スタッフユーザの評価については、評価部1803に関連して上述したとおりである。そして、サーバ装置10は、ユーザDにインセンティブを付与する(ステップS90)。この場合、ユーザDは、インセンティブを受け取る(ステップS92)ことで、更にスタッフユーザとしてスキルを高める動機付けを得ることができる。
【0248】
なお、本実施形態において、ユーザDが仮想現実アプリケーションを起動すると、スタッフユーザとして仮想空間に入るか、一般ユーザとして仮想空間に入るかをユーザDが選択できてもよい。スタッフユーザになることができる一般ユーザは、スタッフユーザとして仮想空間に入ることができる。この場合、例えば、ユーザDがスタッフユーザとして仮想空間に入ることを選択すると、ユーザDのアバタがロッカールームに対応する空間部を形成する位置SP202(
図2D参照)付近、又は、位置SP202に配置されてもよい。あるいは、ユーザDがスタッフユーザとして仮想空間に入ることを選択すると、ユーザDのアバタは、制服を着用したスタッフアバタm2として仮想空間内に配置されてもよい。
【0249】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【0250】
例えば、上述した実施形態では、一例として、
図6に示すスタッフ情報602(テーブル)が例示されているが、これに限られない。例えば、「雇用管理者ID」のように、当該スタッフの起用/雇用に関する管理やケアを行うユーザのIDがユーザテーブル(もしくはそのルーム内のユーザセッション管理テーブル)に設定されてもよい。この場合、雇用管理者IDが付与されるスタッフユーザは、何か問題があった時などに通報する上司として機能でき、例えば、以下のようなユーザであってもよい。
・同一ルーム内の別ユーザ、実際にオンラインにいない場合(すなわち稼働中でない場合)はユーザ管理システムを経由して通知等が可能なユーザ。
・他のユーザ(たとえばゲストユーザや顧客ユーザ)から、当該スタッフユーザの問題を指摘された場合に通報先になる(通報システムとともに人間にも伝わる)ユーザ。
・当該スタッフがヘルプを求めるときに他のユーザに知られずにメッセージングや通知が行えるユーザ。
・階層構造:雇用管理者にもその上司として管理を行う「雇用管理者ID」が設定されており、スタッフのケアやサポート、ミッションに対するKPIの評価や教育指導などを担当するユーザ。
・仮想化:中間的な管理職は実在のユーザである必要はなく、オンラインに不在、もしくは実ユーザが割り当てられていない場合は、その管理者が代理で通知を受信するユーザ。
この場合、あるスタッフユーザが通報を行いたい場合に、例えば通報先の上司が制服を既に脱いでおり勤務中(稼働中)でない場合は、その上司に通報を行う必要がありうる。この場合、このような情報を利用することで、その上司へのIDをたどる仕組みとしてユーザ管理システムを実現できる。例えば、組織表のような情報がユーザ管理システム用のユーザテーブルに別途項目として用意されてもよい。このようなオフライン(非稼働中)であったとしても上司にたどれる仕組みとしてのユーザ管理システムは、システムがスケール化したときに非常に有用となる。
【0251】
以下に、本願の原出願の出願時の特許請求の範囲に記載された発明を付記する。
[付記1]
仮想空間を描画する空間描画処理部と、
前記仮想空間内で移動可能な複数の移動媒体であって、複数のユーザに対応付けられる複数の移動媒体を描画する媒体描画処理部とを含み、
前記複数の移動媒体は、第1属性のユーザに対応付けられた第1移動媒体と、前記仮想空間内における所定役割が付与されている第2属性のユーザに対応付けられた第2移動媒体とを含み、
前記媒体描画処理部は、前記第1属性のユーザ用又は前記第2属性のユーザ用の表示画像における前記第2移動媒体を、前記第1移動媒体から識別可能な態様で、描画する、情報処理システム。
[付記2]
前記媒体描画処理部は、前記仮想空間内に配置される複数の前記第2移動媒体に対して共通の可視特徴を対応付けて描画する、[付記1]に記載の情報処理システム。
[付記3]
前記共通の可視特徴の変更であって、前記第2属性のユーザのそれぞれによる独自の変更は、禁止される、[付記2]に記載の情報処理システム。
[付記4]
前記共通の可視特徴は、衣服又は装身具を含む、[付記3]に記載の情報処理システム。
[付記5]
一のユーザの属性は、前記第1属性と前記第2属性との間で変化可能である、[付記1から4]のうちのいずれか1項に記載の情報処理システム。
[付記6]
一のユーザの属性が前記第1属性と前記第2属性との間で変化したか否かを判定する第1判定部を更に含み、
前記第1判定部により前記一のユーザの属性が前記第1属性と前記第2属性との間で変化したと判定された場合、前記媒体描画処理部は、前記第1属性のユーザ用又は前記第2属性のユーザ用の表示画像において、前記一のユーザに対応付けられた移動媒体の描画態様を変化させる、[付記5]に記載の情報処理システム。
[付記7]
一のユーザからの入力に基づいて、前記一のユーザの属性を、前記第1属性と前記第2属性との間で変化させる第1属性変更部を更に含む、[付記5又は6]に記載の情報処理システム。
[付記8]
前記入力は、前記媒体描画処理部に、前記第2移動媒体を、前記第1移動媒体から識別可能な態様で、描画させるための所定要求を含み、
前記第1属性変更部は、前記所定要求に基づいて、前記一のユーザの属性を、前記第1属性から前記第2属性に変化させる、[付記7]に記載の情報処理システム。
[付記9]
前記一のユーザの属性が前記第2属性であるときに、前記一のユーザが前記所定役割を果たしているかを評価する評価部と、
前記評価部による評価結果が所定基準を満たしているか否かを判定する第2判定部と、
前記第2判定部により前記所定基準を満たしていないと判定された前記一のユーザの属性を、前記第2属性から前記第1属性に変更する第2属性変更部とを更に含む、[付記5から8]のうちのいずれか1項に記載の情報処理システム。
[付記10]
前記所定役割は、前記第1属性のユーザに対する各種の補助であって、前記仮想空間内での各種の補助、又は、前記仮想空間内での各種の演出用の操作に関する、[付記1から9]のうちのいずれか1項に記載の情報処理システム。
[付記11]
前記各種の補助は、前記第1属性のユーザに対する各種の案内、前記仮想空間内で利用又は提供が可能な商品又はサービスの案内又は販売、前記第1属性のユーザからのクレーム対応、及び前記第1属性のユーザに対する各種の注意又は助言のうちの、少なくともいずれか1つを含む、[付記10]に記載の情報処理システム。
[付記12]
前記所定役割を果たす際に利用可能な所定ユーザ情報を取得するユーザ情報取得部を更に含み、
前記媒体描画処理部は、前記第2属性のユーザ用の表示画像において、前記第1移動媒体に、前記所定ユーザ情報を対応付けて、描画する、[付記11]に記載の情報処理システム。
[付記13]
前記所定ユーザ情報は、前記仮想空間又は他の仮想空間における商品又はサービスに関する過去の利用又は提供履歴、若しくは案内履歴を含む、[付記12]に記載の情報処理システム。
[付記14]
前記所定役割を果たしている量に関連するパラメータであって、前記第2属性のユーザのそれぞれに対応付けられたパラメータの値を更新するパラメータ更新部を更に含む、[付記1から13]のうちのいずれか1項に記載の情報処理システム。
[付記15]
前記所定役割を果たしている量は、前記第2移動媒体を介して前記仮想空間内で活動した時間を含む、[付記14]に記載の情報処理システム。
[付記16]
前記第2移動媒体を介して前記仮想空間内で活動した時間は、労働時間を含み、
前記パラメータ更新部は、一のユーザの属性が前記第2属性に変化した場合、前記一のユーザの労働時間のカウントを開始し、その後、前記一のユーザの属性が前記第1属性に変化した場合、前記一のユーザの労働時間のカウントを終了する、[付記15]に記載の情報処理システム。
[付記17]
前記パラメータ更新部により更新される前記パラメータの値に基づいて、前記第2属性のユーザのそれぞれにインセンティブを付与するインセンティブ付与部を更に含む、[付記14から16]のうちのいずれか1項に記載の情報処理システム。
[付記18]
コンピュータにより実行される情報処理方法であって、
仮想空間を描画する空間描画ステップと、
前記仮想空間内で移動可能な複数の移動媒体であって、複数のユーザに対応付けられる複数の移動媒体を描画する媒体描画ステップとを含み、
前記複数の移動媒体は、第1属性のユーザに対応付けられた第1移動媒体と、前記仮想空間内における所定役割が付与されている第2属性のユーザに対応付けられた第2移動媒体とを含み、
前記媒体描画ステップにおいて、前記第1属性のユーザ用の表示画像における前記第2移動媒体を、前記第1移動媒体から識別可能な態様で、描画する、情報処理方法。
[付記19]
仮想空間を描画する空間描画ステップと、
前記仮想空間内で移動可能な複数の移動媒体であって、複数のユーザに対応付けられる複数の移動媒体を描画する媒体描画ステップとを含む処理を、コンピュータに実行させ、
前記複数の移動媒体は、第1属性のユーザに対応付けられた第1移動媒体と、前記仮想空間内における所定役割が付与されている第2属性のユーザに対応付けられた第2移動媒体とを含み、
前記媒体描画ステップにおいて、前記第1属性のユーザ用の表示画像における前記第2移動媒体を、前記第1移動媒体から識別可能な態様で、描画する、情報処理プログラム。
【符号の説明】
【0252】
1 仮想現実生成システム
3 ネットワーク
10 サーバ装置
11 サーバ通信部
12 サーバ記憶部
13 サーバ制御部
20 端末装置
21 端末通信部
22 端末記憶部
23 表示部
24 入力部
25 端末制御部
140 ユーザデータベース
142 アバタデータベース
144 コンテンツ情報記憶部
146 空間状態記憶部
150 空間描画処理部
152 ユーザアバタ処理部
1521 操作入力取得部
1522 ユーザ動作処理部
154 スタッフアバタ処理部
1541 操作入力取得部
1542 スタッフ動作処理部
1544 補助情報提供部
156 位置/向き情報特定部
157 補助対象検出部
158 描画処理部
1581 端末画像生成部
1582 ユーザ情報取得部
159 コンテンツ処理部
160 対話処理部
1601 第1対話処理部
1602 第2対話処理部
162 活動制限部
164 条件処理部
166 抽出処理部
167 役割割当部
168 空間情報生成部
170 パラメータ更新部
180 スタッフ管理部
1801 第1判定部
1802 第1属性変更部
1803 評価部
1804 第2判定部
1805 第2属性変更部
1806 インセンティブ付与部
250 補助要求部
262 支援実行部
263 条件変更部
264 役割付与部