特開 2023-4507 情報処理システム、情報処理方法、情報処理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023004507

(43)【公開日】2023-01-17

(54)【発明の名称】情報処理システム、情報処理方法、情報処理プログラム

(51)【国際特許分類】

   G06T 19/00 20110101AFI20230110BHJP

   G06F 3/048 20220101ALI20230110BHJP

   A63F 13/53 20140101ALI20230110BHJP

【ＦＩ】

G06T19/00 300A

G06F3/048

A63F13/53

【審査請求】有

【請求項の数】18

【出願形態】ＯＬ

(21)【出願番号】P 2021106217

(22)【出願日】2021-06-28

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】504437801

【氏名又は名称】グリー株式会社

(74)【代理人】

【識別番号】110002871

【氏名又は名称】弁理士法人坂本国際特許商標事務所

(72)【発明者】

【氏名】渡邊 匡志

【テーマコード（参考）】

5B050

5E555

【Ｆターム（参考）】

5B050AA03

5B050BA06

5B050BA08

5B050BA09

5B050BA18

5B050BA20

5B050CA07

5B050CA08

5B050EA12

5B050EA19

5B050EA24

5B050EA26

5B050FA02

5B050FA05

5B050FA10

5B050FA12

5B050FA13

5B050FA14

5B050FA17

5E555AA07

5E555AA12

5E555AA76

5E555BA02

5E555BA03

5E555BA05

5E555BA06

5E555BA20

5E555BA38

5E555BB02

5E555BB03

5E555BB05

5E555BB06

5E555BB20

5E555BB38

5E555BC04

5E555BE17

5E555CA02

5E555CA12

5E555CA17

5E555CA42

5E555CA44

5E555CA47

5E555CB03

5E555CB12

5E555CB20

5E555CB64

5E555CB66

5E555CC01

5E555CC03

5E555DA01

5E555DB18

5E555DB32

5E555DB53

5E555DC19

5E555DD01

5E555DD06

5E555EA08

5E555EA09

5E555EA11

5E555EA14

5E555FA00

(57)【要約】

【課題】仮想空間においてアバターのような表示媒体の移動を適切に補助する。
【解決手段】仮想空間に位置する１つ以上の表示媒体を含む端末用の表示画像を描画する描画部と、ユーザからの入力を取得する取得部と、取得部により取得された一のユーザからの第１入力に基づいて、仮想空間における一のユーザに対応付けられる表示媒体の位置を変化させる位置変更部とを含み、描画部は、一のユーザに対応付けられる第１表示媒体と他のユーザに対応付けられる第２表示媒体との間の位置関係を表す案内情報を、第１表示媒体に対応付けて描画する、情報処理システムが開示される。
【選択図】図１

【特許請求の範囲】

【請求項1】

仮想空間に位置する１つ以上の表示媒体を含む端末用の表示画像を描画する描画部と、
ユーザからの入力を取得する取得部と、
前記取得部により取得された一のユーザからの第１入力に基づいて、仮想空間における前記一のユーザに対応付けられる表示媒体の位置を変化させる位置変更部とを含み、
前記描画部は、前記一のユーザに対応付けられる第１表示媒体と他のユーザに対応付けられる第２表示媒体との間の位置関係を表す案内情報を、前記第１表示媒体に対応付けて描画する、情報処理システム。

【請求項2】

前記案内情報は、線又は曲線を含む、請求項１に記載の情報処理システム。

【請求項3】

前記描画部は、前記第１表示媒体を起点として前記線又は曲線を描画する、請求項２に記載の情報処理システム。

【請求項4】

前記描画部は、複数の前記他のユーザに対応付けられる複数の前記第２表示媒体が仮想空間に位置する場合、前記案内情報を前記第２表示媒体ごとに描画する、請求項３に記載の情報処理システム。

【請求項5】

前記表示媒体が仮想空間における所定領域内まで移動した場合に、前記所定領域から第１所定位置へと前記表示媒体を、前記第１入力に基づく移動より短い時間で、移動させる第１ワープ処理部を更に備え、
前記描画部は、仮想空間における前記第１表示媒体と前記第２表示媒体との位置関係に基づいて、前記所定領域を終点として前記線又は曲線を描画する、請求項３又は４に記載の情報処理システム。

【請求項6】

前記第１表示媒体が仮想空間における特定領域内に位置する場合に、前記第１表示媒体に対応付けられるユーザからの第２入力に応じて、前記特定領域から第２所定位置へと前記第１表示媒体を、前記第１入力に基づく移動より短い時間で、移動させる第２ワープ処理部を更に備える、請求項１～４のうちのいずれか１項に記載の情報処理システム。

【請求項7】

前記第２所定位置は、前記第２表示媒体の位置に応じて設定される、請求項６に記載の情報処理システム。

【請求項8】

前記描画部は、前記第１表示媒体が前記特定領域内に位置する場合に、前記第２入力を入力するための第１操作部を操作可能に描画し、前記第１表示媒体が前記特定領域内に位置しない場合に、前記第１操作部を操作不能に描画する、請求項６又は７に記載の情報処理システム。

【請求項9】

前記描画部は、複数の前記他のユーザに対応付けられる複数の前記第２表示媒体が仮想空間に位置する場合、前記第２表示媒体のそれぞれに対応付けて前記第１操作部を別々に描画し、
前記第２ワープ処理部は、一の前記第２表示媒体に対応付けられた前記第１操作部に対する前記第２入力に応じて、該一の前記第２表示媒体の位置に応じた前記第２所定位置へと前記第１表示媒体を移動させる、請求項８に記載の情報処理システム。

【請求項10】

前記特定領域は、前記第１表示媒体の任意の現在位置を含む、請求項６～８のうちのいずれか１項に記載の情報処理システム。

【請求項11】

表示媒体が仮想空間における特定の空間部に入るために必要な移動権限に関する権限情報を記憶する権限情報記憶部と、
前記権限情報記憶部に記憶されている前記権限情報に基づいて、表示媒体ごとに、前記特定の空間部への表示媒体の移動の可否を判定する第１判定部と、
前記第１判定部によって前記特定の空間部への前記第１表示媒体の移動が不能であると判定された場合に、前記特定の空間部への移動のための前記第２入力を無効化する無効化処理部とを更に備える、請求項６～１０のうちのいずれか１項に記載の情報処理システム。

【請求項12】

前記第１判定部は、一の前記第２表示媒体に、複数の前記移動権限の取得済み情報が対応付けられており、かつ、一の前記第１表示媒体が所定の条件を満たした場合に、前記特定の空間部への該第１表示媒体の移動が可能であると判定する、請求項１１に記載の情報処理システム。

【請求項13】

前記無効化処理部により前記第２入力が無効化されている場合、前記描画部は、前記無効化処理部による無効化を解除するための補助情報を描画する、請求項１１又は１２に記載の情報処理システム。

【請求項14】

前記補助情報は、前記移動権限の取得方法の情報、前記移動権限の取得が可能となる仮想空間内の位置の情報、前記移動権限の取得が可能となる特定画面へのリンク又はアクセス方法の情報、前記移動権限を取得した場合の特典情報、前記移動権限を取得した場合に視聴可能なコンテンツに関する情報、のうちの少なくともいずれか１つを含む、請求項１３に記載の情報処理システム。

【請求項15】

前記描画部は、前記第１表示媒体と前記第２表示媒体との間の距離であって、仮想空間の座標系に基づく距離を算出する距離算出部を備え、
前記案内情報は、前記距離算出部により算出された距離を表す距離情報を含む、請求項１～１４のうちのいずれか１項に記載の情報処理システム。

【請求項16】

前記距離算出部により算出される距離の変化態様に基づいて、前記距離算出部により算出される距離が縮まっているか否かを判定する第２判定部を更に備え、
前記案内情報は、前記第２判定部による判定結果を表す情報を含む、請求項１５に記載の情報処理システム。

【請求項17】

仮想空間に位置する１つ以上の表示媒体を含む端末用の表示画像を描画し、
ユーザからの入力を取得し、
一のユーザからの第１入力に基づいて、仮想空間における前記一のユーザに対応付けられる表示媒体の位置を変化させる、
処理を、コンピュータに実行させ、
前記表示画像を描画することは、前記一のユーザに対応付けられる第１表示媒体と他のユーザに対応付けられる第２表示媒体との間の位置関係を表す案内情報を、前記第１表示媒体に対応付けて描画することを含む、情報処理プログラム。

【請求項18】

仮想空間に位置する１つ以上の表示媒体を含む端末用の表示画像を描画する描画ステップと、
ユーザからの入力を取得する取得ステップと、
前記取得ステップにより取得された一のユーザからの第１入力に基づいて、仮想空間における前記一のユーザに対応付けられる表示媒体の位置を変化させる位置変更ステップとを含み、
前記描画ステップは、前記一のユーザに対応付けられる第１表示媒体と他のユーザに対応付けられる第２表示媒体との間の位置関係を表す案内情報を、前記第１表示媒体に対応付けて描画する、コンピュータにより実行される情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

仮想空間において部屋や氷の国といったような複数種類の空間部を設定し、特定の空間部に入るためのドアをアバターがいる空間部に配置する技術が知られている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１８－１０９８３５号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

仮想空間を現実に模して広がりを有する空間として設計すると、所望の空間部へ到達するための各アバターの移動距離が比較的長くなる傾向となる。このような場合、ユーザが自身のアバターを所望の位置まで移動させる操作を容易に行うことができるように、適切に補助できると有用である。

【0005】

そこで、１つの側面では、本開示は、仮想空間においてアバターのような表示媒体の移動を適切に補助することを目的とする。

【課題を解決するための手段】

【0006】

１つの側面では、仮想空間に位置する１つ以上の表示媒体を含む端末用の表示画像を描画する描画部と、
ユーザからの入力を取得する取得部と、
前記取得部により取得された一のユーザからの第１入力に基づいて、仮想空間における前記一のユーザに対応付けられる表示媒体の位置を変化させる位置変更部とを含み、
前記描画部は、前記一のユーザに対応付けられる第１表示媒体と他のユーザに対応付けられる第２表示媒体との間の位置関係を表す案内情報を、前記第１表示媒体に対応付けて描画する、情報処理システムが提供される。

【発明の効果】

【0007】

１つの側面では、本開示によれば、仮想空間においてアバターのような表示媒体の移動を適切に補助することが可能となる。

【図面の簡単な説明】

【0008】

【図1】本実施形態に係る仮想現実生成システムのブロック図である。

【図2】仮想現実生成システムにより生成可能な仮想空間の一例の説明図である。

【図3】端末用画像の一例を示す図である。

【図3A】図３に示した端末用画像の一部（Ｑ１部）であるグループ情報表示領域の説明図である。

【図4】仮想カメラのカメラパラメータの説明図である。

【図5】アバター移動案内機能に関連したサーバ装置の機能ブロック図の一例である。

【図6】ユーザデータベース内のデータの説明図である。

【図7】アバターデータベース内のデータの説明図である。

【図8】コンテンツ情報記憶部内のデータの説明図である。

【図9】チケット情報記憶部内のデータの説明図である。

【図10】グループ状態記憶部内のデータの説明図である。

【図11A】ワープ領域を含む端末用画像の一例の説明図である。

【図11B】距離情報の一例の説明図である。

【図11C】距離情報の他の一例の説明図である。

【図12】案内情報の説明用の状況の一例を示す図である。

【図13】図１２に示した状況下での案内情報の一例の説明図である。

【図14】案内情報の説明用の状況の他の一例を示す図である。

【図15】図１４に示した状況下での案内情報の一例の説明図である。

【図16】図１２に示した状況下での案内情報の他の一例の説明図である。

【図17】仮想空間内に２人の先行ユーザアバターが位置する状況下での案内情報の一例の説明図である。

【図18】補助情報の一例の説明図である。

【図19】チケット売場までの補助情報の誘導の説明図である。

【図20】仮想現実生成システムの各種動作のうちの、案内情報の描画とワープボタンの描画に関連した動作の一例を示す概略フローチャートである。

【図21】案内情報出力処理（図２０のステップＳ２００９）の一例を示す概略的なフローチャートである。

【図22】ワープ条件判定処理（図２０のステップＳ２０１１）の一例を示す概略的なフローチャートである。

【図23】ユーザアバターに係るユーザからフレンドアバターに係るユーザへのリクエストが送信される場合の概略的なフローチャートである。

【図24】アバター移動案内機能に関連した端末装置の機能ブロック図の一例である。

【図25】図２４に示す端末装置による動作例であって、端末画像生成部に関連した動作例を示す概略的なフローチャートである。

【発明を実施するための形態】

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

図２は、仮想現実生成システム１により生成可能な仮想空間の一例の説明図である。

【0037】

本実施形態では、仮想空間は、複数の空間部を含んでよい。複数の空間部のそれぞれは、ユーザアバターＭ１が入ることができる空間部であり、それぞれにおいて独自のコンテンツが提供可能であってよい。複数の空間部のそれぞれは、現実内の各種空間と同様、仮想空間内において互いに連続する空間を形成する態様で生成されてもよい。あるいは、複数の空間部の一部又はすべては、互いに不連続であってもよい。不連続とは、現実内の物理法則に反する態様で接続される関係であり、例えばワープのような瞬間移動の態様で移動可能な空間部間の関係である。

【0038】

図２に示す例では、仮想空間は、複数のコンテンツ提供用の空間部７０と、フリー空間部７１とを備えている。フリー空間部７１では、ユーザアバターＭ１は、基本的に自由に移動できる。なお、フリー空間部７１においても、適宜、コンテンツ（例えば空間部７０で提供されるような後述する各種コンテンツ）が提供されてもよい。

【0039】

空間部７０は、フリー空間部７１に対して少なくとも一部が壁体（第２オブジェクトＭ３の例）や移動禁止部（第２オブジェクトＭ３の例）により隔てられた空間部であってよい。例えば、空間部７０は、フリー空間部７１に対してユーザアバターＭ１が出入りできる出入口（例えば、穴や、ドア等の第２オブジェクトＭ３）を有してよい。空間部７０では、当該空間部７０に位置するユーザアバターＭ１に対してコンテンツが提供されてよい。

【0040】

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

【0041】

なお、空間部７０で提供されるコンテンツは、仮想空間で利用可能な各種アイテム（第２オブジェクトＭ３の例）であってもよい。この場合、各種アイテムを提供する空間部７０は、販売所の形態であってもよい。あるいは、空間部７０で提供されるコンテンツは、現実で入手可能な物品の取得権限やトークン等であってもよい。なお、複数の空間部７０の一部は、コンテンツを提供しない空間部であってもよい。

【0042】

空間部７０のそれぞれは、現実の実店舗と同様、異なる主体により運営されてもよい。この場合、各空間部７０に係る運営者は、本仮想現実生成システム１の運営者に対して出店料等を支払うことで、対応する空間部７０を利用してもよい。

【0043】

なお、仮想空間は、空間部７０の増加に伴って拡大可能であってもよい。あるいは、仮想空間は、空間部７０で提供されるコンテンツの属性ごとに複数設定されてもよい。この場合、仮想空間同士は、それぞれ“空間部”として互いに不連続であってもよいし、連続する形態であってよい。

【0044】

（仮想空間における描画機能）
サーバ制御部１３は、端末装置２０と協動して、表示部２３上に端末用の表示画像（以下、単に「端末用画像」とも称する）を表示し、端末用画像を更新していく。なお、変形例では、端末用画像は、端末装置２０により描画されてもよい（図２４等参照）。

【0045】

図３は、端末用画像の説明図であり、端末用画像の一例を示す図である。図３では、仮想空間の一部がユーザアバターＭ１（ユーザ名“ユーザＡ”）とともに描画されている。端末用画像は、仮想空間内に配置される仮想カメラ６０からの映像として描画されてもよい。この場合、仮想カメラ６０は、ユーザアバターＭ１ごとに設定されてもよい。また、仮想カメラ６０は、ユーザアバターＭ１ごとのカメラに加えて、定点に設置される形態のカメラを含んでもよい。

【0046】

図４は、仮想カメラ６０のカメラパラメータの説明図である。図４には、グローバル座標系に位置付けられたフィールド面４０が示されている。グローバル座標系は、仮想空間に固定的に対応付けられた座標系である。なお、フィールド面４０とは、特に言及しない限り、フィールド画像が投影された状態のフィールド面４０（フィールドオブジェクトのフィールド面４０）を表す。フィールド面４０は、仮想空間のフィールドを表す。なお、不連続な２つ以上の空間部のそれぞれに対しては、グローバル座標系で互いに不連続なフィールド面４０が設定されてよい。

【0047】

本実施形態では、カメラパラメータは、２つの位置パラメータ（Ｘ、Ｙ）と、距離パラメータＡ２と、向きパラメータθと、迎角パラメータψとを含む。これらのすべてのパラメータの値が決まると、グローバル座標系に対して、仮想カメラ６０を一意に位置付けることができる。なお、迎角パラメータψが約９０度となると、鳥瞰表示が可能となる。

【0048】

位置パラメータＸは、視線方向Ｖのｘｙ平面上の交点のｘ座標であり、位置パラメータＹは、視線方向Ｖのｘｙ平面上の交点のｙ座標であり、距離パラメータＡ２は、視線方向Ｖのｘｙ平面上の交点から仮想カメラ６０までの距離（視線方向Ｖに沿った距離）である。向きパラメータθは、視線方向Ｖのｘｙ平面上の投影ベクトルＶ’と、ｘ軸とのなす角度である。迎角パラメータψは、視線方向Ｖとｘｙ平面とのなす角度である。なお、本実施形態では、迎角パラメータψが利用されるが、迎角パラメータψは省略されてもよい。すなわち、迎角パラメータψは、値が一定値（固定値）であってもよい。

【0049】

このような各種カメラパラメータのうちの一部又は全部の各値は、ユーザアバターＭ１に係るパラメータの値（例えばユーザアバターＭ１の位置や状態）に連動して変化されてもよいし、及び／又は、ユーザからの入力に応じて変化されてもよい。例えば、２つの位置パラメータ（Ｘ、Ｙ）の各値は、ユーザアバターＭ１の位置に対応してもよい。なお、このようなカメラパラメータは、一例であり、実際の処理では、異なるパラメータが等価的に使用されてもよい。例えば、カメラパラメータは、ｘｙ平面に対する高さと、直交する３軸回りの回転パラメータ（すなわち、ヨー、ロール、及びピッチ）とを含んでもよい。また、カメラパラメータは、焦点距離等のような他のパラメータを含んでもよい。

【0050】

（アバター移動案内機能の詳細）
本実施形態において、仮想空間は、ユーザアバターＭ１を介したユーザ間の交流の場として機能することもできる。この場合、例えば、複数のユーザが、事前に約束をして、所定の時間に特定の空間部７０でコンテンツの提供を受けることができる。この場合、複数のユーザは、コンテンツの提供を介して、交流を図ることができる。あるいは、複数のユーザが、事前に約束をして、所定の時間に特定の空間部７０に集まり、会話（チャット等）を楽しむことができる。

【0051】

ところで、仮想現実は、現実の場合とは異なり、仮想空間を比較的自由に設計でき、例えば、仮想空間を現実に模して広がりを有する空間として設計することも可能である。この場合、仮想空間内に比較的多くの空間部を配置でき、例えばモールのような大規模な仮想空間を構築でき、仮想空間への集客力（仮想空間を訪れるユーザアバターＭ１の数や頻度）を高めることができる。

【0052】

しかしながら、仮想空間を現実に模して広がりを有する空間として設計すると、所望の空間部へ到達するための各アバターの移動距離が比較的長くなる傾向となる。このような場合、ユーザアバターＭ１が所望の空間部へ容易に辿り着くことができるように補助できると有用である。

【0053】

そこで、本実施形態では、仮想現実生成システム１は、以下で詳説するように、ユーザアバターＭ１が所望の空間部又は空間部内の所望の位置へ容易に辿り着くことができるように補助ないし案内するアバター移動案内機能を有する。

【0054】

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

【0055】

図５は、アバター移動案内機能に関連したサーバ装置１０の機能ブロック図の一例である。図６は、ユーザデータベース１４０内のデータの説明図である。図７は、アバターデータベース１４２内のデータの説明図である。図８は、コンテンツ情報記憶部１４４内のデータの説明図である。図９は、チケット情報記憶部１４５内のデータの説明図である。図１０は、グループ状態記憶部１４６内のデータの説明図である。なお、図６から図１０において、“＊＊＊”は、何らかの情報が格納されている状態を表し、“－”は、情報が格納されていない状態を表し、“・・・”は同様の繰り返しを表す。

【0056】

サーバ装置１０は、図５に示すように、ユーザデータベース１４０と、アバターデータベース１４２と、コンテンツ情報記憶部１４４と、チケット情報記憶部１４５、グループ状態記憶部１４６と、グループ設定部１５０と、ユーザアバター処理部１５２と、端末画像生成部１５８と、コンテンツ処理部１５９と、対話処理部１６０と、第１移動権限処理部１６２と、第２移動権限処理部１６４と、判断処理部１６６と、パラメータ更新部１７０と、を含む。なお、以下で説明するサーバ装置１０の機能の一部又は全部は、適宜、端末装置２０により実現されてもよい（図２５参照）。また、ユーザデータベース１４０からグループ状態記憶部１４６の区分けや、グループ設定部１５０からパラメータ更新部１７０の区分けは、説明の都合上であり、一部の機能部が、他の機能部の機能を実現してもよい。例えば、グループ設定部１５０、ユーザアバター処理部１５２、端末画像生成部１５８、コンテンツ処理部１５９、及び対話処理部１６０の各機能は、端末装置２０により実現されてもよい。また、例えば、ユーザデータベース１４０内のデータの一部又は全部は、アバターデータベース１４２内のデータに統合されてもよいし、別のデータベースに格納されてもよい。

【0057】

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

【0058】

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

【0059】

ユーザ情報６００は、各ユーザＩＤに、ユーザ名、ユーザ認証情報、ユーザアバターＩＤ、位置／向き情報、フレンド情報等が対応付けられる。ユーザ名は、ユーザが自身で登録した名前であり、任意である。ユーザ認証情報は、ユーザが正当なユーザであることを示すための情報であり、例えばパスワードや、メールアドレス、生年月日、合言葉、生体情報等を含んでよい。フレンド情報は、フレンド関係にあるユーザを特定する情報（例えばユーザＩＤ）を含んでよい。

【0060】

ユーザアバターＩＤは、ユーザアバターを特定するためのＩＤである。本実施形態では、ユーザアバターＩＤは、ユーザＩＤごとに１つずつ対応付けられる。従って、以下の説明において、“ユーザ（又はユーザＩＤ）に対応付けられる”又はその類の表現は、ユーザアバターＩＤに対応付けられる”又はその類の表現と同義である。ただし、他の実施形態では、一のユーザＩＤに複数のユーザアバターＩＤが対応付け可能であってもよい。

【0061】

位置／向き情報は、ユーザアバターＭ１の位置情報と向き情報とを含む。向き情報は、ユーザアバターＭ１の顔の向きを表す情報であってよい。なお、位置／向き情報等は、ユーザからの操作入力に応じて、動的に変化しうる情報である。位置／向き情報に加えて、ユーザアバターＭ１の手足等の動きを表す情報や、顔の表情（例えば、口の動き）、顔や頭部の向きや視線方向（例えば、眼球の向き）、レーザーポインターのような空間内の向きや座標を示すオブジェクト等を表す情報を含んでもよい。

【0062】

アバターデータベース１４２には、ユーザアバターＭ１に関するアバター情報が格納される。

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

コンテンツ情報記憶部１４４には、更に、各コンテンツ提供位置でそれぞれのコンテンツの提供を受けるために満たされるべき条件（以下、「コンテンツ提供条件」とも称する）を表す情報が記憶されてよい。コンテンツ提供条件は、コンテンツＩＤごとに設定されてよい。コンテンツ提供条件は、提供時間、チケットの要否や年齢等に基づいて設定されてもよい。

【0069】

チケット情報記憶部１４５には、チケットに関するチケット情報（権限情報の一例）が記憶される。チケットとは、ユーザアバターＭ１が仮想空間内のコンテンツ提供位置（例えば空間部内の１つ以上の位置）に移動するための移動権限（ひいては、当該コンテンツ提供位置でコンテンツの提供を受けるための権限）を表す仮想現実媒体である。なお、図３を参照して後述するチケット管理ボタン３０３の操作により表示されるチケット管理画面や、図１８を参照して後述するグループ情報表示領域３０００内のチケット状態１８８０は、チケット情報記憶部１４５内のデータに基づいて生成されてよい。

【0070】

図９に示す例では、チケット情報９００は、チケットＩＤに、コンテンツ提供位置と、所有者ＩＤと、購入情報、譲渡用の認証情報、譲渡情報、有効フラグ等が対応付けられている。

【0071】

チケットＩＤは、チケットごとに付与される固有のＩＤである。

【0072】

コンテンツ提供位置は、チケットに係る移動権限に基づいて位置できる仮想空間内の位置を表す。コンテンツ提供位置は、コンテンツの提供を受けることができる位置を含む。コンテンツ提供位置は、一点の座標値で定義されてもよいが、典型的には、一纏めの領域又は空間部を形成する複数の座標値で定義されてよい。また、コンテンツ提供位置は、平面上の位置であってもよいし、空間上の位置（すなわち高さ方向を含む３次元の座標系で表される位置）であってもよい。コンテンツ提供位置は、典型的には、コンテンツごとに、コンテンツの提供位置や属性に応じて設定されてよい。

【0073】

なお、図９に示すチケット情報９００は、例えば図２に示す複数の空間部７０のような、複数種類のコンテンツ提供位置が対応付けられる場合に好適である。コンテンツ提供位置が１種類だけである場合、チケット情報９００におけるコンテンツ提供位置は、省略されてもよい。

【0074】

所有者ＩＤは、現時点で当該チケットを所持しているユーザに係るユーザＩＤに対応する。チケットは、上述したように譲渡可能であるため、所有者ＩＤは、事後的に変化しうる。

【0075】

購入情報は、購入者ＩＤや、購入日時、購入方法等を表す。なお、購入者ＩＤは、購入入力を行ったユーザに対応付けられたユーザＩＤである。

【0076】

譲渡用の認証情報は、譲渡に必要となる認証情報であり、チケットＩＤごとに異なる情報である。

【0077】

譲渡情報は、１回以上の譲渡の有無を表し、更に、譲渡日時等を表してもよい。なお、図９において、“－”は、譲渡がなされていないことを示す。

【0078】

有効フラグは、チケットの有効性を表すフラグ情報である。本実施形態では、一例として、有効フラグが“１”である場合は、チケットが有効である状態を表し、有効フラグが“０”である場合は、チケットが無効である状態を表す。チケットが有効である状態は、当該チケットに対応付けられたコンテンツ提供位置に、当該チケットに対応付けられたユーザアバターＭ１が移動できる状態（及びそれに伴い当該コンテンツ提供位置で特定のコンテンツの提供を受けることができる状態）に対応する。

【0079】

チケットの有効性は、チケットの属性ごとに設定されてもよい。例えば、ある属性のチケットは、対応するユーザアバターＭ１（例えば購入者ＩＤに対応付けられたユーザアバターＭ１）がコンテンツ提供位置に到達した時点（あるいは、その直ぐ後の時点であって、コンテンツ提供位置に至った時点）で無効化されてもよい。また、他の属性のチケットは、対応するユーザアバターＭ１がコンテンツ提供位置に到達した時点から、所定時間が経過した時点で無効化されてもよい。また、他の属性のチケットは、対応するユーザアバターＭ１がコンテンツ提供位置に到達した後、コンテンツ提供位置から離れた時点で無効化されてもよい。あるいは、同じチケットにより再入場が可能な仕組みを更に実現してもよい。この場合、チケットの有効性は、対応するユーザアバターＭ１がコンテンツ提供位置に到達した時点から所定時間経過するまで維持されてもよい。あるいは、チケットの有効性は、所定回数以上のコンテンツ提供位置への移動（入場）が検出された場合に、無効化されてもよい。

【0080】

グループ状態記憶部１４６には、仮想空間において活動するグループの状態に関するグループ状態情報が格納される。グループは、後述するグループ設定部１５０により設定される。図１０に示す例では、グループ状態情報１０００は、グループＩＤごとに、対応するグループ名及びユーザＩＤ（対応するグループに属するユーザに係るユーザＩＤ）が対応付けられている。なお、一のグループＩＤには、複数のユーザＩＤが対応付けられうる。なお、グループは、パーティと呼ばれる場合がある。

【0081】

グループ設定部１５０は、仮想空間において交流する１人以上のユーザからなるグループを設定する。例えば、各ユーザがユーザアバターＭ１を介して仮想空間に入る際、グループ名を入力する。この場合、グループ設定部１５０は、グループ名ごとにグループＩＤを設定し、同じ仮想空間名を入力したユーザ同士を同じグループとして設定してよい。この場合、グループごとに、グループ内の各ユーザが一の仮想空間を共有できるように、仮想空間は、グループごとに生成されてよい。これにより、例えば、仮想空間で交流しようとする複数のユーザは、事前に通知しあった共通の仮想空間名を入力することで、他のユーザ（グループが異なるユーザ）と交流することなく、共通の仮想空間で交流できる。また、グループごとに仮想空間を管理できるので、一の仮想空間を多数のユーザが共有する場合に比べて、一のユーザに対応付けられる端末装置２０に送信する他ユーザの情報量を低減できるので、仮想現実生成システム１全体としての通信負荷を低減できる。なお、変形例では、一の仮想空間は、複数のグループに属するユーザが同時に利用可能であってもよい。以下では、特に言及しない限り、各ユーザアバターＭ１は、同一グループに属するものとする。

【0082】

また、グループ設定部１５０は、一のユーザがユーザアバターＭ１を介して仮想空間に入る際、端末画像生成部１５８と連携して、当該一のユーザに対応付けられる端末装置２０に現在設定中のグループ情報を表示してもよい。この場合、グループ情報は、グループ名やそのメンバを表す情報（ユーザ名等）を含んでよい。また、グループ名の表示は、選択ボタンとして機能してもよい。この場合、所望のグループ名の表示を見つけたユーザは、対応する選択ボタンを操作することで、容易に所望のグループに参加できる。なお、グループへの参加は、グループ内のメンバであるユーザからの許可が必要とされてもよい。

【0083】

また、他の実施形態では、グループ設定部１５０は、ユーザからの入力に基づくことなく、各ユーザを複数のグループのうちの一のグループに割り振ってもよい。この場合、一のグループに属するユーザ数が均等化されるように、割り振りを実現してもよい。これにより、グループごとの処理負荷のバランスを均等化できる。この際、グループ設定部１５０は、入室時刻が近いユーザ同士を同一のグループに割り振ってもよいし、ユーザの属性情報（年齢や、性別、好み等）に応じた割り振りを実現してもよい。

【0084】

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

【0085】

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

【0086】

本実施形態では、操作入力情報は、仮想空間におけるユーザアバターＭ１の位置を変化させる操作入力（第１入力の一例）や、ユーザアバターＭ１の向き等の他のパラメータ（移動以外のパラメータ）の値を変化させる操作入力、ユーザインタフェース描画部１５８２により描画されるユーザインタフェースを介して生成される操作入力、対話処理部１６０で利用される音声又はテキスト入力等を含んでよい。ユーザインタフェースを介して生成される操作入力は、後述するワープボタン１８００を介して生成されるワープ入力（第２入力の一例）を含む。

【0087】

なお、仮想空間におけるユーザアバターＭ１の位置を変化させる操作入力は、ユーザアバターＭ１を移動させる操作入力であり、以下、「移動操作入力」とも称する。また、以下、ユーザアバターＭ１の向き等の他のパラメータ（移動以外のパラメータ）の値を変化させる操作入力を、「アバター関連入力」とも称する。なお、移動操作入力やアバター関連入力は、特定キー（例えば“ＷＡＳＤ”キー）の操作により生成されてもよいし、矢印ボタン等を含むユーザインタフェースを介して生成されてもよいし、音声やジェスチャ等の動きにより生成されてもよい。

【0088】

本実施形態では、ユーザ動作処理部１５２２は、基本動作処理部１５２２１（位置変更部の一例）と、第１ワープ処理部１５２２２と、第２ワープ処理部１５２２３とを含む。

【0089】

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

【0090】

第１ワープ処理部１５２２２は、一のユーザアバターＭ１が仮想空間におけるワープ領域（所定領域の一例）内まで移動した場合に、ワープ領域から所定距離Ｄ１以上離れた第１所定位置へと、又は、ワープ領域が属する空間部とは異なる空間部内の第１所定位置へと、当該一のユーザアバターＭ１を移動させる処理（以下、「第１ワープ処理」と称する）を行う。なお、一のユーザアバターＭ１に対する第１ワープ処理は、当該一のユーザアバターＭ１の位置／向き情報のうちの、少なくとも位置情報を変化させることを伴う。

【0091】

この場合、所定距離Ｄ１は、比較的大きい距離であり、例えば、第１ワープ処理の処理時間に対応する時間あたりで移動操作入力だけによってユーザアバターＭ１が移動できる最大距離よりも有意に大きくてよい。所定距離Ｄ１で判定される距離（ワープ領域から第１所定位置までの距離）は、直線距離であってもよいし、ユーザアバターＭ１の移動経路に沿った距離であってもよい。

【0092】

本実施形態では、第１所定位置は、別のワープ領域として設定される。すなわち、本実施形態では、２つのワープ領域間を直接的に行き来する態様でユーザアバターＭ１が移動できる。なお、２つのワープ領域間を直接的に行き来する際に要する時間は、当該２つのワープ領域間の距離を移動操作入力に基づきユーザアバターＭ１を移動させる場合の時間よりも有意に短い。これにより、ユーザは、ワープ領域を利用して、効率的な移動を実現できる。なお、変形例では、第１所定位置は、ワープ領域ではなく、一方向のワープだけが実現可能であってもよい。なお、ワープ領域は、複数設定されてよく、一部のワープ領域だけが、一方向のワープだけが実現可能であってもよい。

【0093】

図１１Ａには、図２に示した仮想空間におけるワープ領域１１００を含む端末用画像の一例が示されている。ワープ領域１１００は、位置が固定であってもよいし、適宜、位置が変更されてもよい。また、ワープ領域１１００は、所定の出現条件を満たした場合に出現されてもよい。ワープ領域１１００からの行き先は、ワープ領域１１００ごとに設定されてよい。なお、ワープ領域１１００からの行き先は、必ずしも現在位置の属する空間部とは異なる空間部（例えば不連続な空間部）である必要はなく、現在位置の属する空間部と同一の空間部内に設定されてもよい。

【0094】

本実施形態では、上述したように、２つのワープ領域間を直接的に行き来できる態様で、一のワープ領域１１００に対応するワープ領域が、行き先の空間部等において設定される。この場合、ワープ領域を介した双方向の移動が可能である。例えば、図２には、対のワープ領域１１００－１、１１００－２が模式的に示されている。この場合、ワープ領域１１００－１、１１００－２のうちの一方のワープ領域内に移動すると、他方のワープ領域へと瞬間的な移動（以下、「瞬間移動」と称する）を実現できる。２点間の瞬間移動（例えば対のワープ領域１１００－１、１１００－２間の瞬間移動）とは、現実では実現できない移動態様であり、例えば移動操作入力によって２点間をユーザアバターＭ１を移動させた場合に要する最小時間よりも有意に短い時間で移動できる移動態様を指す。

【0095】

なお、図２に示す例では、２つのワープ領域１１００は、フリー空間部７１内に設定されているが、複数のワープ領域の一部又は全部は、空間部７０内に設定されてもよい。また、一のワープ領域から瞬間移動可能な行き先は、２つ以上あり、ユーザにより選択可能であってもよいし、ランダムに選択されてもよい。

【0096】

第２ワープ処理部１５２２３は、一のユーザアバターＭ１が仮想空間における特定領域内に位置する場合に、当該一のユーザアバターＭ１に対応付けられるユーザ（すなわち当該一のユーザアバターＭ１を操作するユーザ）からのワープ入力に応じて、第２所定位置へとユーザアバターＭ１を移動させる処理（以下、「第２ワープ処理」と称する）を行う。この場合、第２所定位置は、特定領域が属する空間部内に設定されてもよいし、特定領域が属する空間部とは異なる空間部内に設定されてもよい。第２所定位置は、固定であってもよいし、可変であってもよい。なお、一のユーザアバターＭ１に対する第２ワープ処理は、当該一のユーザアバターＭ１の位置／向き情報のうちの、少なくとも位置情報を変化させることを伴う。

【0097】

本実施形態では、第２所定位置は、ユーザアバターＭ１ごとに設定される。一のユーザアバターＭ１に対して設定される第２所定位置は、当該一のユーザアバターＭ１に対して所定関係を有する他のユーザアバターＭ１の位置に応じて設定されてよい。所定関係は、任意であるが、本実施形態では、一例として、グループ設定部１５０により設定された同じグループに属する関係を含む。他の実施形態では、同じ観点から、所定関係は、フレンド関係を含んでよい。以下では、一のユーザアバターＭ１に対して所定関係を有する他のユーザアバターＭ１を、「フレンドアバター」とも称する。

【0098】

この場合、一のユーザアバターＭ１に対して設定される第２所定位置は、例えば、フレンドアバターの位置に対して所定距離Ｄ２内に設定されてよい。この場合、所定距離Ｄ２は比較的小さい距離であり、例えば、一のユーザアバターＭ１に係るユーザ用の端末用画像において、第２ワープ処理の直後に、フレンドアバターが描画されるような距離であってよい。この場合、一のユーザアバターＭ１は、フレンドアバターのそばまで瞬間移動が可能となる。なお、この場合、一のユーザアバターＭ１の移動元の位置は、フレンドアバターの位置する空間部内の位置であってもよいし、フレンドアバターの位置する空間部とは異なる空間部内の位置であってもよい。なお、一のユーザアバターＭ１の移動先である第２所定位置は、フレンドアバターの位置に対して所定距離Ｄ２内であれば任意であるが、例えば、フレンドアバターの位置に対して所定距離Ｄ２内、かつ、フレンドアバターの後方又は側方の位置といった具合に、フレンドアバターの位置に対して所定の位置関係を有してもよい。

【0099】

このような第２ワープ処理によれば、ユーザは、移動操作入力によって自身のユーザアバターＭ１をフレンドアバターのそばまで移動させることが難しい場合でも、後述するワープボタン１８００を操作するだけでユーザアバターＭ１をフレンドアバターのそばまで移動させることが可能となるので、利便性が向上する。このような利便性は、特に仮想空間が広く、また、仮想空間内に多数の空間部が配置されている場合等に顕著となる。また、第２ワープ処理によれば、移動操作入力によってユーザアバターＭ１の比較的長い移動過程を描画する描画処理を省略できるので、処理負荷を低減する効果も得られる。また、端末装置２０においても、描画に係る処理負荷及びそれに伴う電力消費（電源の充電状態の減少）を低減できる。

【0100】

第２ワープ処理は、このようにユーザによる移動操作入力の負荷（及びそれに伴う描画処理の負荷）を低減できる反面、仮想空間内をユーザアバターＭ１が移動する際の新たな発見（例えば新しい空間部の出現や、装飾など第２オブジェクトＭ３の変化）の機会や、フリー空間部７１において必要又は有用な各種情報（例えばフリー空間部７１でのチュートリアルや広告等に関するコンテンツや第２オブジェクトＭ３、新設された空間部７０等）を提供する機会を減らしてしまう側面がある。

【0101】

従って、第２ワープ処理は、所定のワープ条件が満たされた場合に実行可能とされてもよい。所定のワープ条件は、任意であるが、例えば、所定のワープ条件は、ユーザによる移動操作入力の負荷が比較的高くなる場合に満たされるように適合されてもよい。例えば、所定のワープ条件は、フレンドアバターに対する距離が所定距離Ｄ３以上離れた場合や、フレンドアバターがユーザアバターＭ１（第２ワープ処理の対象となりうるユーザアバターＭ１）とは異なる空間部に位置する場合等に満たされてもよい。なお、フレンドアバターに対するユーザアバターＭ１の距離は、各ユーザアバターＭ１の位置／向き情報のうちの位置情報に基づいて算出されてよい。

【0102】

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

【0103】

例えば、端末画像生成部１５８は、ユーザアバターＭ１ごとに、一のユーザアバターＭ１の位置／向き情報に基づいて、当該一のユーザアバターＭ１に対応付けられたユーザに係る端末装置２０で表示される画像（端末用画像）を生成する。具体的には、端末画像生成部１５８は、一のユーザアバターＭ１の位置／向き情報に基づいて、当該位置／向き情報に対応した位置及び向きの仮想カメラ６０から視た仮想空間の画像（仮想空間の一部を切り取る画像）を端末用画像として生成する。この場合、各ユーザアバターＭ１に係る位置／向き情報は、互いに異なるので、端末用画像は、各ユーザアバターＭ１に係るユーザごとに異なる。以下では、この点を考慮して、ある一のユーザに係るユーザアバターＭ１の位置／向き情報に基づいて生成される端末用画像を、一のユーザ用の端末用画像と称する場合がある。以下では、特に言及しない限り、一のユーザ（及びそれに対応付けられているユーザアバターＭ１）に係る端末用画像を生成する際の端末画像生成部１５８の機能について説明するが、他のユーザに係る端末用画像を生成する場合も実質的に同様である。

【0104】

端末画像生成部１５８は、一人称視点モードや三人称視点モードのような、複数のモードを有してよい。例えば、一人称視点モードでは、端末画像生成部１５８は、一のユーザアバターＭ１の位置／向き情報に対応した位置及び向きに仮想カメラ６０位置及び向き（カメラパラメータの各値）を合わせる。この場合、仮想カメラ６０の視野は、当該一のユーザアバターＭ１の視野に実質的に一致する。なお、この場合、仮想カメラ６０からの視野には、当該ユーザアバターＭ１は映らない。

【0105】

他方、三人称視点モードでは、端末画像生成部１５８は、一のユーザアバターＭ１の位置から少し離れた位置に仮想カメラ６０の位置を合わせる。このとき、端末画像生成部１５８は、仮想カメラ６０の他のカメラパラメータの各値を、一のユーザアバターＭ１の位置／向き情報の向きや、仮想空間内の状況等に応じて適宜決定してもよい。この際、ユーザアバターＭ１が映る端末用画像を生成するように、仮想カメラ６０の位置は、ユーザアバターＭ１の後方や側方の少し離れた位置に設定されてよい。

【0106】

また、他のモードでは、仮想カメラ６０の各種カメラパラメータの値は、対応するユーザにより任意に調整可能であってもよい。なお、かかる端末用画像を生成する際、端末画像生成部１５８は、奥行き感等を出すために、各種の処理（例えばフィールドオブジェクトを曲げる処理等）を実行してもよい。また、ユーザアバターＭ１が映る端末用画像を生成する場合は、描画処理の負荷を低減するために、ユーザアバターＭ１は、比較的簡易な態様（例えば二次元スプライトの形態）で描画されてもよい。

【0107】

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

【0108】

端末画像生成部１５８は、各ユーザアバターＭ１に対してユーザ名（例えば図３では、“ユーザＡ”）を対応付けて描画してもよい。これにより、各ユーザは、ユーザ名に基づいて所望のユーザに係るユーザアバターＭ１を特定することが可能となる。なお、ユーザ名は、ユーザによる設定に基づいて非表示とされることが可能であってもよい。

【0109】

本実施形態では、端末画像生成部１５８は、ベース画像描画部１５８１と、ユーザインタフェース描画部１５８２と、案内情報描画部１５８３と、補助情報描画部１５８４と、ワープ動作描画部１５８５と、空間部遷移描画部１５８６とを含む。

【0110】

ベース画像描画部１５８１は、上述したような端末用画像の基本部分を描画する。すなわち、ベース画像描画部１５８１は、ユーザインタフェース描画部１５８２、案内情報描画部１５８３、及び補助情報描画部１５８４のそれぞれによる描画が重畳される前の基本部分を描画する。例えば、ベース画像描画部１５８１は、仮想空間の描画情報や、仮想カメラ６０の各カメラパラメータの値、各ユーザアバターＭ１の位置／向き情報、第２オブジェクトＭ３の配置情報等に基づいて、仮想カメラ６０からの視野内の、仮想空間自体（第２オブジェクトＭ３等を除く部分）及び仮想空間内の各種オブジェクト（ユーザアバターＭ１や第２オブジェクトＭ３等）を描画する。なお、仮想空間の描画情報は、あらかじめ用意されてよいが、事後的又は動的に更新等されてもよい。仮想空間内の各位置は、グローバル座標系（図４参照）で規定されてよい。なお、仮想空間の描画方法は、任意であるが、例えばフィールドオブジェクトや背景オブジェクトを、適切な平面や曲面等にマッピングすることにより実現されてもよい。

【0111】

ユーザインタフェース描画部１５８２は、ユーザによる各種操作が可能なユーザインタフェースを描画する。ユーザインタフェースを介して操作可能な項目は、任意である。例えば図３に示す例では、ユーザインタフェース３００は、椅子ボタン３０１と、いいねボタン３０２と、チケット管理ボタン３０３と、友達管理ボタン３０４と、退出ボタン３０５を含む。また、図３に示す例では、端末用画像は、別のユーザインタフェースである対話用インタフェース３０９を含む。

【0112】

椅子ボタン３０１は、ユーザアバターＭ１を仮想空間内で着席させる際に操作される。例えば、各ユーザは、ユーザアバターＭ１を介してじっくりと話したいときなどに、椅子ボタン３０１を利用できる。この場合、ユーザアバターＭ１が着席されると、仮想空間内の音（例えば常時再生している所定の音楽等）が消え、ボイスチャット（音声による対話）のみが可能となってよい。

【0113】

いいねボタン３０２は、ユーザアバターＭ１を介して他のユーザアバターＭ１に良い評価やギフト等を与える際に操作される。

【0114】

チケット管理ボタン３０３は、後述するチケットの各種状態を閲覧可能なチケット管理画面（図示せず）を出力させる際に操作される。チケット管理画面には、後述する譲渡入力や、リクエスト入力、譲渡用の認証情報入力等が可能な更なるユーザインタフェースが設定されてもよい。

【0115】

友達管理ボタン３０４は、フレンド関係となっている他のユーザアバターＭ１に関する友達管理画面（図示せず）を出力させる際に操作される。

【0116】

退出ボタン３０５は、仮想空間からユーザアバターＭ１を退出させる際に操作される。

【0117】

また、本実施形態では、ユーザインタフェース描画部１５８２は、ワープボタン１８００（第１操作部の一例）（図３Ａ参照）を描画する。ワープボタン１８００は、上述した第２ワープ処理部１５２２３の第２ワープ処理による瞬間移動を行う際に操作される。すなわち、ワープボタン１８００は、ワープ入力を発生させる際に操作される。

【0118】

ワープボタン１８００は、端末用画像の任意の位置に描画されてもよいが、好ましくは、対応するフレンドアバターに対応付けて描画される。例えば、一のフレンドアバターのそばまで瞬間移動するためのワープボタン１８００は、当該一のフレンドアバターに対応付けて描画される。これにより、複数のフレンドアバターが存在する場合でも、ユーザは、所望のフレンドアバターのそばまで瞬間移動するためのワープボタン１８００を容易に特定できる。

【0119】

図３Ａには、図３に示した端末用画像の一部（Ｑ１部）であるグループ情報表示領域３０００が示されている。グループ情報表示領域３０００は、例えばユーザによる操作（例えばタップ操作）により全画面表示が可能であってよい。なお、グループ情報表示領域３０００に表示されるグループは、グループ設定部１５０により設定されたグループに対応する。グループ情報表示領域３０００には、同一グループ内の各ユーザアバターＭ１のアバターアイコン３５０、３５１、３５２が含められている。アバターアイコン３５０、３５１、３５２のそれぞれには、対応するユーザ名（例えば“ユーザＡ”、“ユーザＢ”等）が対応付けられている。この場合、ワープボタン１８００は、対応するフレンドアバター（この場合、本人である“ユーザＡ”に対して“ユーザＢ”及び“ユーザＣ”）の各アバターアイコン３５１、３５２に対応付けて描画されている。

【0120】

ユーザインタフェース描画部１５８２は、所定のワープ条件が成立した場合に、ワープボタン１８００を操作可能な表示態様で描画し、所定のワープ条件が成立しない場合に、ワープボタン１８００を操作不能な表示態様で描画してよい。例えば、ワープボタン１８００は、操作不能な表示態様では、操作可能な表示態様に比べて、有意に低い輝度（又は通常とは異なる色）で描画されてもよい（後述する図１８のワープボタン１８００－１参照）。この場合、ユーザは、ワープボタン１８００がアクティブ状態であるか否かを容易に把握できる。ユーザが、操作可能な表示態様で描画されているワープボタン１８００を操作した場合、ワープ入力が正常に発生して操作入力取得部１５２１により取得されることになる。また、ユーザが、操作不能な表示態様で描画されているワープボタン１８００を操作した場合、ワープ入力は発生しない。

【0121】

所定のワープ条件は、上述したように、例えば、ユーザによる移動操作入力の負荷が比較的高くなる場合に満たされるように適合されてもよい。この場合、所定のワープ条件は、複数のフレンドアバターが存在する場合には、フレンドアバターごとに判定されてよい。

【0122】

本実施形態では、一例として、所定のワープ条件は、ユーザアバターＭ１が仮想空間内の特定領域に位置し、仮想空間内にフレンドアバターが存在し、かつ、後述する無効化処理部１６６２からの無効化指示が生成されていない場合に、満たされる。特定領域は、フレンドアバターごとの第２所定位置よりも有意に離れるように、フレンドアバターごとに設定されてもよいが、本実施形態では、特定領域は、仮想空間内の任意の位置である。この場合、ユーザアバターＭ１が仮想空間内に位置する限り、特定領域に位置することになる（すなわち、ユーザアバターＭ１の現在位置が常に特定領域に含まれる）。これにより、ユーザアバターＭ１の位置とは無関係に所定のワープ条件を成立させることができるので、所定のワープ条件の判定のための処理負荷を低減できる。また、ユーザ側からすると、現在位置で第２ワープ処理による瞬間移動を行うことが可能となり、わざわざ現在位置とは異なる位置へとユーザアバターＭ１を移動させないと瞬間移動を行うことができない仕様に比べて、利便性が向上する。

【0123】

案内情報描画部１５８３は、アバター移動案内機能を実現する案内情報を描画する。案内情報は、ユーザアバターＭ１が所望の空間部又は空間部内の所望の位置へ容易に辿り着くことができるように、ユーザアバターＭ１に対応するユーザの移動操作入力を補助ないし案内するための情報である。

【0124】

本実施形態では、案内情報は、ユーザアバターＭ１が他のユーザアバターＭ１のそばまでスムーズに移動するのを補助ないし案内するための情報である。具体的には、案内情報は、ユーザアバターＭ１と他のユーザアバターＭ１との間の位置関係を表す。この場合、案内情報描画部１５８３は、案内情報を、ユーザアバターＭ１のそれぞれに対応付けて描画する。

【0125】

以下では、案内情報に関して、他のユーザアバターＭ１のそばまで案内される側のユーザアバターＭ１を、「案内対象ユーザアバターＭ５」（第１表示媒体の一例）とも称し、他のユーザアバターＭ１を、「先行ユーザアバターＭ６」（第２表示媒体の一例）とも称する。

【0126】

本実施形態では、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６とは、所定関係を有する。所定関係は、上述したフレンドアバターに関連した所定関係と同じであってよい。この場合、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６とは、互いに同一グループに属し、互いにフレンドアバターである。なお、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との区別は、説明上であり、例えば、先行ユーザアバターＭ６が案内対象ユーザアバターＭ５を迎えに行く場合は、案内情報に基づき案内対象ユーザアバターＭ５のそばまで誘導される“案内対象”となりうる。

【0127】

案内情報は、好ましくは、線又は曲線を含む。線又は曲線は、案内対象ユーザアバターＭ５に対応付けて仮想空間内に描画される。例えば、線又は曲線は、仮想空間のフィールド面４０（地面に対応する部分）に描画されてもよいし、仮想空間における空間中に描画されてもよい。

【0128】

案内情報は、案内対象ユーザアバターＭ５が複数存在する場合、案内対象ユーザアバターＭ５ごとに生成及び描画されてよい。ただし、複数の案内対象ユーザアバターＭ５が実質的に同じ位置に存在する場合、当該複数の案内対象ユーザアバターＭ５に係る案内情報の一部又は全部は統合されてもよい。

【0129】

案内情報に係る線又は曲線は、案内対象ユーザアバターＭ５を起点として描画されてもよい。

【0130】

例えば、案内情報に係る線又は曲線は、一端が案内対象ユーザアバターＭ５に対応付けられ、他端が先行ユーザアバターＭ６に対応付けられる。これにより、案内対象ユーザアバターＭ５に係るユーザは、案内対象ユーザアバターＭ５の移動が線又は曲線を辿る態様で実現されるように移動操作入力を行うことで、案内対象ユーザアバターＭ５を先行ユーザアバターＭ６のそばまで容易に移動させることができる。
ただし、案内対象ユーザアバターＭ５に係るユーザ用の端末用画像に、先行ユーザアバターＭ６が描画されない場合、案内情報に係る線又は曲線は、一端が案内対象ユーザアバターＭ５に対応付けられ、他端が先行ユーザアバターＭ６の位置を示唆する位置まで延在してもよい。この場合、他端は、案内対象ユーザアバターＭ５に係るユーザ用の端末用画像の縁部に設定されてもよい。この場合、案内対象ユーザアバターＭ５が移動すると、それに対応して更新される端末用画像の縁部まで、案内情報に係る線又は曲線の他端が伸びる態様が実現されてもよい。

【0131】

また、案内情報に係る線又は曲線は、推奨ルートに沿って描画されてもよい。この場合、推奨ルートは、噴水オブジェクトなどの障害物に係るオブジェクトを通ることのないルート（すなわち、ユーザアバターＭ１がトラブルなく移動できるルート）であってよい。この場合、トラブルの少ない推奨ルートに沿った案内情報を生成できる。この結果、効率的な移動が実現されるので、ユーザアバターＭ１の移動に係る処理負荷を低減できる。

【0132】

また、推奨ルートは、広告等のようなユーザに見せたいコンテンツを提供するコンテンツ提供場所を通るように設定されてもよい。これにより、推奨ルートに沿ったユーザアバターＭ１の移動を支援しつつ、必要又は有用な各種情報（例えばフリー空間部７１でのコンテンツや第２オブジェクトＭ３）をユーザアバターＭ１を介してユーザに伝達することが可能となる。また、このような観点から、推奨ルートは、あえて、噴水オブジェクトなどの障害物に係るオブジェクトを通りうるルート（例えば最短ルート）で算出されてもよい。この場合、案内対象ユーザアバターＭ５に係るユーザが仮想空間内の状況を注視し、自分で考えて操作することにつながり、その結果、必要又は有用な各種情報を当該ユーザに伝達できる可能性を高めることができる。

【0133】

案内情報は、上述した線又は曲線に対応付けて補足案内情報を含んでもよい。補足案内情報は、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の位置関係として、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の距離情報や、当該距離の変化態様を示す距離変化情報であってよい。

【0134】

距離情報は、例えば、数値の形態であるが、メータのような他の形態であってよい。距離変化情報は、線又は曲線の長さや色、太さ等で表現されてもよい。例えば、距離が増加した場合は、線又は曲線の長さが延長され、距離が減少した場合は、線又は曲線の長さが短縮されてもよい。あるいは、距離が増加した場合は、色が特定の色（例えば赤）とされ、距離が減少した場合は、色が他の特定の色（例えば青）とされてもよい。また、距離変化情報は、線又は曲線とは別に、線又は曲線に対応付けて描画されてもよい。例えば、距離変化情報は、文字情報として、“増”や“減”といった具合に、直接的なテキストが線又は曲線に対応付けて描画されてもよい。この場合、距離変化情報は、距離の変化量が所定量を超えた場合のみに描画（更新）されてもよい。これにより、距離変化情報が比較的高頻度で更新される場合の不都合（例えば処理負荷の増加や、増減間の入れ替わりが頻繁に起きることによる表示の煩わしさ等）を低減できる。

【0135】

図１１Ｂは、距離情報の例の説明図であり、図１１Ｃは、距離変化情報の例の説明図であり、いずれも、端末用画像の一部を示す図である。図１１Ｂ及び図１１Ｃには、案内対象ユーザアバターＭ５に対応付けて描画される距離情報又は距離変化情報の例が示されている。

【0136】

具体的には、図１１Ｂには、距離感を“Ｖ”字マークのようなマークで表す距離変化情報の例が示されている。この場合、端末用画像の一部Ｇ１１０２には、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の距離が比較的大きいときの距離情報１１５０Ａが示され、端末用画像の一部Ｇ１１０２には、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の距離が比較的小さいときの距離情報１１５１Ａが示されている。このようにして、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の距離が大きくなるほど、“Ｖ”マークのようなマークの数が増える態様で、距離情報が描画されてもよい。なお、距離情報１１５０Ａ、１１５１Ａに係るマークの全体としての延在方向は、案内対象ユーザアバターＭ５が存在する方向を表してもよい。すなわち、距離情報１１５０Ａ、１１５１Ａは、案内情報に係る線又は曲線として機能してもよい。また、距離情報１１５０Ａ、１１５１Ａに係るマークは、流れを表す態様で順に輝度や色が変化されてもよい。これにより、直感的にわかりやすい案内情報を実現できる。

【0137】

また、図１１Ｃには、相対位置を“Ｖ”字マークのようなマークで表す距離変化情報の例が示されている。この場合、端末用画像の一部Ｇ１１０２には、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の距離が伸びたときの距離変化情報１１５２Ａが示され、端末用画像の一部Ｇ１１０３には、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の距離が縮んだときの距離変化情報１１５３Ａが示されている。すなわち、距離変化情報１１５２Ａは、先行ユーザアバターＭ６が遠ざかったことを表し、距離変化情報１１５３Ａは、先行ユーザアバターＭ６が近づいたことを表す。このようにして、“Ｖ”字マークのようなマークの向きにより距離変化情報が案内対象ユーザアバターＭ５に係るユーザに伝達されてもよい。なお、上述した距離情報１１５０Ａ、１１５１Ａと同様に、距離変化情報１１５２Ａ、１１５３Ａに係るマークの全体としての延在方向は、案内対象ユーザアバターＭ５が存在する方向を表してもよい。すなわち、距離変化情報１１５２Ａ、１１５３Ａは、案内情報に係る線又は曲線として機能してもよい。また、距離変化情報１１５２Ａ、１１５３Ａに係るマークは、流れを表す態様で順に輝度や色が変化されてもよい。

【0138】

本実施形態では、案内情報描画部１５８３は、補足案内情報を生成するために、距離算出部１５８３１と、距離変化判定部（第２判定部の一例）１５８３２とを含む。

【0139】

距離算出部１５８３１は、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の距離（グローバル座標系（図４参照）での距離）を算出する。距離算出部１５８３１は、グループ状態情報１０００に基づいて、グループ内の各ユーザアバターＭ１間の距離を、所定周期ごとに算出してよい。この場合、上述した距離情報は、距離算出部１５８３１による算出結果に基づいて生成できる。算出対象の距離は、直線距離であってもよいし、ユーザアバターＭ１の移動経路に沿った距離であってもよい。なお、距離算出部１５８３１による算出結果は、他の用途（例えば上述した所定のワープ条件の判定等）に利用されてもよい。

【0140】

距離変化判定部１５８３２は、距離算出部１５８３１により算出される距離の変化態様に基づいて、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の距離が縮まっているか否かを判定する。例えば、距離変化判定部１５８３２は、所定の処理周期ごとに、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の距離が縮まっているか否かを判定してよい。なお、判定対象の距離は、案内情報が出力されている各組の案内対象ユーザアバターＭ５と先行ユーザアバターＭ６の間の距離のみであってもよい。この場合、上述した距離変化情報は、距離変化判定部１５８３２による判定結果に基づいて生成できる。また、この場合、判定対象の距離を限定することで、処理負荷の低減を図ることができる。

【0141】

なお、変形例では、補足案内情報は、距離情報に代えて又は加えて、時間情報（例えば、先行ユーザアバターＭ６に到達するのに要する最小時間等）を含んでもよい。

【0142】

ここで、図１２から図１５を参照して、いくつかの案内情報の例を説明する。

【0143】

図１２は、案内情報の説明図であり、図２と同様の仮想空間の平面図である。図２に示した仮想空間において、先行ユーザアバターＭ６と案内対象ユーザアバターＭ５との位置関係の一例が示されている。図１２に示す例では、先行ユーザアバターＭ６は、空間部７０－１２内に位置しており、案内対象ユーザアバターＭ５は、空間部７０－１２とは異なるフリー空間部７１に位置している。例えば、図１２に示す案内対象ユーザアバターＭ５の位置は、仮想空間に入るときの初期位置又はその近傍に対応してよい。この場合、案内情報に係る線又は曲線は、図１２に模式的に示す案内ルート１２００に沿って生成されてよい。

【0144】

図１３は、図１２に示した状況下での案内対象ユーザアバターＭ５に係るユーザ用の端末用画像の一例を示す図である。図１３は、案内情報として矢印の線１３００が案内対象ユーザアバターＭ５に対応付けて描画されている。この場合、案内情報描画部１５８３は、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の位置関係に基づいて、互いのそばに移動するための推奨ルートである案内ルート（図１２に示す例では案内ルート１２００）を算出する。この際、案内情報描画部１５８３は、上述したように、噴水オブジェクトなどの障害物に係るオブジェクトを通ることのない案内ルート（すなわち、ユーザアバターＭ１が移動できる案内ルート）を算出してよい。そして、案内情報描画部１５８３は、算出した案内ルートに基づいて、図１３に示すような矢印の線１３００を描画する。これにより、案内対象ユーザアバターＭ５に係るユーザは、矢印の線１３００に沿って移動すればよいことを容易に理解できる。

【0145】

図１４は、案内情報の説明図であり、図２と同様の仮想空間の平面図であり、図１２とは別の状況を示す。図１４においても、図２に示した仮想空間において、先行ユーザアバターＭ６と案内対象ユーザアバターＭ５との位置関係の他の一例が示されている。図１４
に示す例では、先行ユーザアバターＭ６は、空間部７０－１４内に位置しており、案内対象ユーザアバターＭ５は、空間部７０－１４とは異なるフリー空間部７１に位置している。この場合、案内情報に係る線又は曲線は、図１４に模式的に示す案内ルート１４００であって、図１４に示すようなワープ領域１１００を介した案内ルート１４００に沿って生成されてよい。

【0146】

図１５は、図１４に示した状況下での案内対象ユーザアバターＭ５に係るユーザ用の端末用画像の一例を示す図である。図１５は、案内情報として矢印の線１５００が案内対象ユーザアバターＭ５に対応付けて描画されている。この場合、案内情報描画部１５８３は、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６との間の位置関係に基づいて、互いのそばに移動するための推奨ルートである案内ルート（図１４に示す例では案内ルート１４００）を算出し、算出した案内ルートに基づいて、図１５に示すような矢印の線１５００を描画する。この場合、案内対象ユーザアバターＭ５がワープ領域１１００を介して移動した方が短い時間で先行ユーザアバターＭ６のそばまで移動できる場合、案内ルートはワープ領域１１００を含んでよい。このような場合は、典型的には、案内対象ユーザアバターＭ５と先行ユーザアバターＭ６の間にワープ領域１１００が設定されている場合である。このようにして、案内ルートにワープ領域１１００が含まれる場合、案内情報描画部１５８３は、ワープ領域１１００を終点として線又は曲線を描画してよい。この場合、矢印の線１５００は、ワープ領域１１００に向かうべきことを示唆できる。これにより、案内対象ユーザアバターＭ５に係るユーザは、矢印の線１５００に沿ってワープ領域１１００を介して移動すればよいことを容易に理解できる。

【0147】

図１６は、他の例による案内情報の説明図であり、図１２に示した状況下での、案内対象ユーザアバターＭ５に係るユーザ用の端末用画像の一例を示す図である。案内情報は、上述したように、上述した線又は曲線に加えて、補足案内情報を含んでもよい。補足案内情報は、線又は曲線では表せない情報や、線又は曲線よりも詳しい情報等であってよい。例えば図１６に示す例では、補足案内情報１６００は、文字情報の形態であり、矢印の線１３００に対応付けて描画されている。この場合、案内対象ユーザアバターＭ５に係るユーザは、補足案内情報１６００を見ることで、ユーザ名“ユーザＢ”の先行ユーザアバターＭ６が１００ｍ先にいることを、容易に理解できる。このような補足案内情報は、図１７を参照して後述するような複数の先行ユーザアバターＭ６が存在する状況下において好適である。

【0148】

図１７は、他の例による案内情報の説明図であり、仮想空間内に２人の先行ユーザアバターＭ６が位置する状況下（図１２に示した先行ユーザアバターＭ６と図１４に示した先行ユーザアバターＭ６が同時に存在する状況下）での、案内対象ユーザアバターＭ５に係るユーザ用の端末用画像の一例を示す図である。

【0149】

仮想空間内に複数の先行ユーザアバターＭ６が位置する状況下では、案内情報描画部１５８３は、複数の先行ユーザアバターＭ６ごとに、案内情報を描画してよい。すなわち、案内情報描画部１５８３は、複数の先行ユーザアバターＭ６のそれぞれに対応付けて、案内情報を描画してよい。図１７に示す例では、図１２に示した先行ユーザアバターＭ６に係る矢印の線１３００と、図１４に示した先行ユーザアバターＭ６に係る矢印の線１５００とが同時に描画されている。なお、この場合、図１２に示したユーザ名“ユーザＢ”の先行ユーザアバターＭ６に係る補足案内情報１６００や、図１４に示したユーザ名“ユーザＣ”の先行ユーザアバターＭ６に係る補足案内情報１７００が示されてもよい。

【0150】

なお、上述したように、仮想空間内に複数の先行ユーザアバターＭ６が位置する状況下においても、複数の先行ユーザアバターＭ６の一部又は全員が実質的に同じ位置にいる場合は、実質的に同じ位置にいる１人以上の先行ユーザアバターＭ６に係る案内情報に係る線又は曲線は、統合されてもよい。

【0151】

このように本実施形態によれば、上述のような案内情報を描画することで、仮想空間において案内対象ユーザアバターＭ５の移動（すなわち当該案内対象ユーザアバターＭ５に係るユーザによる移動操作入力）を適切に補助することが可能となる。

【0152】

なお、本実施形態において、案内情報は、所定の出力条件が満たされた場合に出力されてもよい。この場合、所定の出力条件は、上述した所定のワープ条件と同様、先行ユーザアバターＭ６となりうるフレンドアバターごとに判定されてもよい。所定の出力条件は、上述した所定のワープ条件と同様であってもよい。この場合、ワープボタン１８００が対応付けて描画されるフレンドアバターは、先行ユーザアバターＭ６として案内情報も同時に描画される。

【0153】

補助情報描画部１５８４は、後述する無効化処理部１６６２によりワープ入力が無効化されている場合、当該無効化を解除するための補助情報を描画する。後述するように、コンテンツ提供位置へのユーザアバターＭ１の移動は、当該ユーザアバターＭ１に係るチケットの所持状態に応じて制限される場合がある。具体的には、一のユーザが、一のコンテンツ提供位置に係る正当なチケットを所持していない場合、当該一のユーザによるワープ入力（当該一のコンテンツ提供位置に係る空間部への瞬間移動のためのワープ入力）が無効化処理部１６６２により無効化される。補助情報描画部１５８４は、このような場合に、ワープ入力が可能となるような補助情報を提供する。

【0154】

補助情報描画部１５８４により提供される補助情報は、チケットの取得方法の情報、チケットの取得が可能となる仮想空間内の位置の情報、チケットの取得が可能となる特定画面へのリンク又はアクセス方法の情報、チケットを取得した場合の特典情報、チケットを取得した場合に視聴可能なコンテンツに関する情報、のうちの少なくともいずれか１つを含んでよい。

【0155】

本実施形態では、補助情報描画部１５８４は、操作不能な態様で描画されるワープボタン１８００に対応付けて補助情報を描画する。上述したように、ワープボタン１８００は、所定のワープ条件が成立しない場合に、操作不能な態様で描画される。補助情報は、所定のワープ条件を成立させるための情報を含むので、ワープボタン１８００を操作したいユーザは、補助情報にアクセスすることで、所定のワープ条件を成立させるための各種操作の手順や内容等を理解できる。

【0156】

例えば、図１８には、ユーザ名“ユーザＡ”に係るユーザ用の端末用画面におけるグループ情報表示領域３０００が示されている。この例では、ユーザ名“ユーザＣ”にはワープボタン１８００－２が操作可能な態様で描画されているのに対してユーザ名“ユーザＢ”にはワープボタン１８００－１が操作不能な態様で描画されている。この場合、ユーザ名“ユーザＢ”は、チケットＡを必要とする空間部に位置しているが、ユーザ名“ユーザＡ”に係るユーザ（本人）はチケットＡを所持しておらず、所定のワープ条件が成立していない。この場合、ユーザ名“ユーザＡ”に係るユーザは、ワープボタン１８００－１が操作不能である点や補助情報１８４０－１、１８４０－２に基づいて、ユーザ名“ユーザＢ”のユーザアバターＭ１（先行ユーザアバターＭ６）のそばまで自身のユーザアバターＭ１（案内対象ユーザアバターＭ５）を瞬間移動させたい場合、チケットＡを取得する必要があることを理解できる。

【0157】

なお、図１８に示す例では、グループ情報表示領域３０００には、グループ内のチケット状態１８８０が描画されている。グループ内のチケット状態１８８０は、同グループ内の各ユーザアバターＭ１（フレンドアバター）が所持しているチケットに関する情報を含んでよい。この場合、ユーザ名“ユーザＢ”に係るユーザアバターＭ１は、チケットＡを５枚所持している。従って、ユーザ名“ユーザＡ”に係るユーザは、ユーザ名“ユーザＢ”のユーザアバターＭ１（先行ユーザアバターＭ６）のそばまで自身のユーザアバターＭ１（案内対象ユーザアバターＭ５）を瞬間移動させたい場合、例えば補助情報１８４０－１に係るリンク又はボタン（図示せず）を操作することで、ユーザ名“ユーザＢ”のユーザにチケットＡをリクエストすることも可能である。

【0158】

図１９には、仮想空間におけるチケット売場を含む端末用画像Ｇ１１０が示されている。ユーザ名“ユーザＡ”に係るユーザは、例えば補助情報１８４０－２（図１８参照）に係るリンク又はボタン（図示せず）を操作することで、チケット売場へと瞬間移動が可能であってもよい。図１９に示す例では、チケット売場への瞬間移動後の端末用画像であって、ユーザ名“ユーザＡ”に係るユーザ用の端末用画像Ｇ１１０が示されている。なお、チケット売場は、当該チケット売場で販売されているチケットＡに係るコンテンツが提供されている空間部の近傍に配置されてもよい。例えば、図１９に示す例では、ユーザ名“ユーザＡ”に係るユーザは、対応するユーザアバターＭ１をチケット購入位置ＳＰ１に移動させて、例えばチケット売場で働くスタッフに係るユーザアバターＭ１（ユーザ名“ｃｈａ”）を介してチケットＡを購入してよい。そして、ユーザ名“ユーザＡ”に係るユーザは、チケットＡを購入後、対応するユーザアバターＭ１を入口位置ＳＰ２に移動させることで、購入したチケットＡに係るコンテンツを提供する空間部に入ることができる。

【0159】

ワープ動作描画部１５８５は、上述した第１ワープ処理部１５２２２による第１ワープ処理や第２ワープ処理部１５２２３による第２ワープ処理が実行される際に、瞬間移動を示唆する演出（例えばアニメーションによる演出）を行ってよい。瞬間移動を示唆する演出は、例えば、高速の乗り物（高速の列車やヘリコプターなど）や、画面全体の特定色への変化、フラッシュ演出等により実現されてもよい。第１ワープ処理に対する演出と第２ワープ処理に対する演出とは異なる態様で実現されてもよい。また、ワープ処理による移動距離の長さに応じて演出態様が異なってもよい。

【0160】

また、ワープ処理に係る瞬間移動は、先行ユーザアバターＭ６の移動した軌跡に沿ってユーザアバターＭ１（案内対象ユーザアバターＭ５）を高速に自動的に移動させることで実現されてもよい。この場合、ワープ処理中の端末用画像は、周辺の第２オブジェクトＭ２等の描画を部分的に省略して描画されてもよい。これにより、ワープ処理に係る描画処理に係る処理負荷を低減しつつ、先行ユーザアバターＭ６に係るユーザと同じ景色（仮想空間内の景色）を案内対象ユーザアバターＭ５に見せることができる。この結果、例えば、案内対象ユーザアバターＭ５が先行ユーザアバターＭ６のそばに瞬間移動した場合でも、途中にあった第２オブジェクトＭ２などの話題で対話を楽しむ等が可能であり、交流を促進できる。

【0161】

空間部遷移描画部１５８６は、移動操作入力に基づいて一のユーザアバターＭ１が一の空間部から他の空間部に移動した際に、空間部の遷移を示唆する演出を行ってよい。空間部の遷移を示唆する演出は、例えば、移動後の空間部を一時的に拡大すること等により実現されてもよい。

【0162】

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

【0163】

対話処理部１６０は、複数のユーザからの入力に基づいて、ネットワーク３を介したユーザ間の対話に係る対話処理を実行する。ユーザ間の対話は、自身の各ユーザアバターＭ１を介して、テキスト及び／又は音声によるチャット形式で実現されてもよい。例えば、対話用の入力には、図３に示した端末用画像の対話用インタフェース３０９が利用されてもよい。この場合、ユーザは、マイクのアイコン３０９１を操作して発話することで音声入力が可能であり、また、テキスト入力領域３０９２にテキストを入力することでテキスト入力が可能である。これにより、ユーザ同士で対話が可能となる。なお、テキストは、一定数の履歴が残る対話形式で各端末用画像（対話している各ユーザに係る各端末用画像）に描画されてよい。この場合、例えば、テキストは、仮想空間に係る画像とは別に出力されてもよいし、仮想空間に係る画像に重畳して出力されてもよい。

【0164】

対話処理部１６０は、同一グループ内でのみ対話が実現されるように、グループごとに、対話処理を実行してよい。この場合、各ユーザは、発話内容がグループ外のユーザに知られることがないことにより、安心して対話を楽しむことができる。この場合、対話処理部１６０は、グループ内の一ユーザからの音声入力を出力する場合に、グループ情報表示領域３０００（図３Ａ参照）内に表示されてよいマイクアイコン３６０のうちの、当該一ユーザに対応するマイクアイコン３６０を強調（例えば拡大や、点滅、色付け等）してもよい。これにより、他のユーザは、出力されている音声がグループ内のいずれのユーザの発話による音声であるかを容易に把握できる。なお、マイクアイコン３６０に代えて又は加えて、グループ情報表示領域３０００（図３Ａ参照）内のアバターアイコン（アバターアイコン３５０、３５１等）が同様に強調されてもよい。

【0165】

第１移動権限処理部１６２は、ユーザからの購入入力に基づいて、コンテンツ提供位置でコンテンツの提供を受けるためのチケット（移動権限）を発生させ、ユーザに対応付けられたユーザアバターＭ１に当該チケットを対応付ける。

【0166】

購入入力は、チケットの購入のための各種入力を含む。購入入力は、典型的には、金銭又は金銭的価値を有する仮想現実媒体の消費を伴う。金銭的価値を有する仮想現実媒体は、金銭の消費に伴って入手可能な仮想現実媒体等を含んでよい。なお、仮想現実媒体の消費とは、ユーザＩＤと当該仮想現実媒体との対応付けを解消すること、ユーザＩＤに対応付けられた当該仮想現実媒体の量や数等を低減すること等により実現されてよい。

【0167】

第１移動権限処理部１６２は、チケットを発生させる際に、チケットＩＤ（図９参照）を新規に生成し、チケット情報記憶部１４５内のデータを更新する。この場合、新たなチケットＩＤには、コンテンツ提供位置や所有者ＩＤ等が対応付けられる（図９参照）。この場合、所有者ＩＤは、上述した購入入力を行ったユーザに係るユーザＩＤとなる。

【0168】

本実施形態では、一例として、第１移動権限処理部１６２は、購入入力取得部１６２１と、チケットＩＤ生成部１６２２と、認証情報通知部１６２３と、チケット描画部１６２４とを含む。

【0169】

購入入力取得部１６２１は、端末装置２０からネットワーク３を介して、上述したユーザからの購入入力を取得する。

【0170】

購入入力は、コンテンツ提供位置に係る入口付近にユーザアバターＭ１が位置する場合に、当該ユーザアバターＭ１に対応付けられたユーザにより入力可能とされる。仮想空間内におけるコンテンツ提供位置に係る入口は、明確に規定されている必要はないが、仮想空間内における入口に対応する位置には、例えば入口やゲートといった文字が描画により対応付けられてよい。

【0171】

この場合、チケットを購入したいユーザは、自身のユーザアバターＭ１を入口付近に至らせ、チケット購入位置ＳＰ１に対応付けて配置されるスタッフに係るユーザアバターＭ１（図１９のユーザ名“ｃｈａ”のユーザアバターＭ１参照）との対話を介して、購入入力を行うことができる。

【0172】

チケットＩＤ生成部１６２２は、上述のように、購入入力に基づいて、チケットＩＤ（図９参照）を新規に生成し、チケット情報記憶部１４５内のデータを更新する。例えば、チケットを購入したいユーザが、自身のユーザアバターＭ１を入口付近に位置させた状態で購入入力を行うと、チケットＩＤ生成部１６２２は、即座にチケットＩＤを新規に生成する。この場合、チケットＩＤに対応付けられた有効フラグの初期値は“１”にセットされてよい。また、チケットを事前に購入していたユーザが、自身のユーザアバターＭ１を入口付近に位置させた状態で有効化用の入力を行うと、チケットＩＤ生成部１６２２は、すでに生成済のチケットＩＤに対応付けられた有効フラグの値を“０”から“１”に変更してよい。

【0173】

認証情報通知部１６２３は、購入入力に基づいてチケットを購入したユーザに対して、購入したチケットに対応付けられた譲渡用の認証情報（図９参照）を通知する。なお、上述したように、本実施形態では、一例として、譲渡用の認証情報は、数字及び／又は記号よりなる４桁のコードである。例えば、認証情報通知部１６２３は、譲渡用の認証情報を、ネットワーク３を介して、チケットを購入したユーザに係る端末装置２０に送信する。この際、譲渡用の認証情報は、メールや電話による自動音声等により通知されてもよい。あるいは、上述したように、譲渡用の認証情報は、購入入力を行う際、ユーザにより設定されてもよい。この場合、認証情報通知部１６２３は省略されてもよい。

【0174】

チケット描画部１６２４は、購入入力に基づいて、チケットＩＤごとにチケット（仮想現実媒体）を描画してよい。例えば、チケット描画部１６２４は、チケット表示１８５０（図３Ａ参照）に、所有者ＩＤに係るユーザアバターＭ１のアイコン表示が含まれる場合、対応付けてチケットを描画してもよい。あるいは、チケット描画部１６２４は、所有者ＩＤに係るユーザアバターＭ１を含む端末用画像において、所有者ＩＤに係るユーザアバターＭ１の手に対応付けてチケットを描画してもよい。これにより、ユーザアバターＭ１がチケットを所持（所有）している状態を仮想現実において実現できる。なお、複数のチケットＩＤが同一の所有者ＩＤに対応付けられている場合、当該所有者ＩＤに係るユーザアバターＭ１は、複数のチケットを所持している態様で描画されてもよい。

【0175】

第２移動権限処理部１６４は、ユーザからの譲渡入力に基づいて、第１移動権限処理部１６２によって特定のユーザに係るユーザＩＤが対応付けられたチケットを、当該ユーザとは異なるユーザに係るユーザＩＤへと対応付け替える。すなわち、第２移動権限処理部１６４は、当該チケットに対応付けられる所有者ＩＤ（図９参照）を、購入者ＩＤに係るユーザＩＤから、譲渡先の他のユーザに係るユーザＩＤに変更する。このようにして、第２移動権限処理部１６４は、譲渡入力に基づいて、第１移動権限処理部１６２によって特定のユーザ（購入者ＩＤ）に対応付けられたチケットを、当該ユーザとは異なるユーザ（譲渡先のユーザ）へと対応付け替える。この結果、当該チケットは、当該譲渡入力に基づいて、譲渡側のユーザに係るユーザアバターＭ１に対応付けられた状態から、譲受側のユーザに係るユーザアバターＭ１に対応付けられた状態へと変化する。

【0176】

具体的には、第２移動権限処理部１６４は、譲渡入力取得部１６４０と、認証通知案内部１６４１と、チケット情報書換部１６４４とを含む。

【0177】

譲渡入力取得部１６４０は、端末装置２０からネットワーク３を介して、上述した譲渡側のユーザからの譲渡入力を取得する。譲渡入力は、譲渡対象のチケットに係るチケットＩＤを含む。なお、譲渡入力を行うことができるユーザは、チケットを所有しているユーザであり、チケット情報９００（図９参照）において、所有者ＩＤに係るユーザＩＤを持つユーザである。また、譲渡入力は、譲受側のユーザに対応付けられたユーザＩＤを含んでよい。

【0178】

譲渡入力は、例えば、購入入力とともにユーザにより入力可能とされてもよい。これは、例えば親子でチケットを購入する場合、親が、子供への譲渡を予定してチケットを購入する場合が比較的多いためである。あるいは、複数のチケットが対応付けられているユーザ（すなわち複数のチケットを購入したユーザ）は、他のユーザからのリクエストに応じて、譲渡入力を行うこともできる。

【0179】

認証通知案内部１６４１は、上述の譲渡入力に応答して、譲渡側のユーザに対して、譲渡用の認証情報を譲受側のユーザに通知するように、案内する。なお、この案内は、購入入力の際に実現されてもよいし、他のタイミングで実現されてもよい。また、仮想現実生成システム１の利用に際して各ユーザに、この点が事前に周知される場合は、認証通知案内部１６４１は省略されてもよい。譲渡側のユーザは、かかる案内を受けると、譲渡用の認証情報を、チャットやメール、ＳＭＳ（ショートメッセージサービス）等で譲受側のユーザに通知することになる。なお、譲渡側のユーザと、譲受側のユーザとが、親子の関係のように、何度も同じ譲渡用の認証情報を利用している関係である場合、譲渡用の認証情報の通知自体は不要でありうる。また、譲渡側のユーザと、譲受側のユーザとが、現実において近くにいる場合、譲渡用の認証情報の通知は、対面で直接的に実現されてもよい。

【0180】

チケット情報書換部１６４４は、譲渡入力取得部１６４０により取得される譲渡入力と、譲受側のユーザからの譲渡用の認証情報の入力に基づいて、チケット情報９００の所有者ＩＤを書き換える。具体的には、チケット情報書換部１６４４は、譲受側のユーザからの正当な譲渡用の認証情報の入力に基づいて認証が成功した場合、譲渡入力に含まれるチケットＩＤに対応付けられた所有者ＩＤとして、同譲渡入力に含まれるユーザＩＤを対応付ける。この際、譲渡入力を行ったユーザに係るユーザＩＤは、所有者ＩＤに対応付けられた状態が解消され、当該譲渡の事実が、チケット情報書換部１６４４の譲渡情報（図９参照）として追加されてよい。あるいは、チケット情報９００の所有者ＩＤを書き換えることに代えて（例えば、譲渡入力を行ったユーザに係るユーザＩＤが所有者ＩＤに対応付けられた状態が維持されつつ）、当該チケットを利用可能なユーザ又はユーザアバターＭ１として、譲受側のユーザに係るユーザＩＤが登録されてもよい。

【0181】

ここで、譲渡用の認証情報は、上述したように、譲渡側のユーザから譲受側のユーザに、事前に通知される。譲渡側のユーザは、譲受側のユーザにだけわかるような、譲渡用の認証情報を設定したり、譲受側のユーザにだけわかるように、譲渡用の認証情報を通知したりできるので、意図しない他のユーザに、譲渡用の認証情報が知られる可能性は実質的にない。従って、このような譲渡用の認証情報を用いることで、チケット情報書換部１６４４に係る認証の安全性を高めることができる。ただし、簡易な譲渡を可能とする観点から、譲渡の際の譲渡用の認証情報による照合は、省略されてもよい。譲渡用の認証情報の省略の有無は、譲渡入力の際に選択可能であってもよい。

【0182】

チケット情報書換部１６４４は、このようにして、一のチケットＩＤに係る所有者ＩＤを変更すると、チケット描画部１６２４に当該変更を反映させる指示を与えてよい。この場合、チケット描画部１６２４は、新たな所有者ＩＤに係るユーザアバターＭ１に対応付けて、チケットを描画する。例えば、ユーザは、自身の端末装置２０に表示されるユーザ用の端末用画像において、チケット管理画面への遷移や、グループ情報表示領域３０００内に表示されうるチケット表示１８５０（図３Ａ、図１８参照）や、自身のユーザアバターＭ１にチケットが対応付けて描画されている状態を確認することで、チケットを所持しているか否かを認識できる。

【0183】

判断処理部１６６は、チケット情報９００（図９参照）に基づいて、ユーザアバターＭ１がコンテンツ提供位置へと移動できるか否かを判定する。

【0184】

具体的には、判断処理部１６６は、チケット所持判定部１６６１（第１判定部の一例）と、無効化処理部１６６２とを含む。

【0185】

チケット所持判定部１６６１は、ある一のユーザアバターＭ１が一のコンテンツ提供位置へと移動できるか否かについて判定する際、まず、当該一のユーザアバターＭ１が、当該一のコンテンツ提供位置へと移動できるチケットを所持しているか否かを判定する。以下、このような判定処理を、「チケット所持判定」とも称する。

【0186】

チケット所持判定は、図９に示したチケット情報９００に基づいて実現できる。この場合、ユーザＩＤが所有者ＩＤとなっているユーザ（又はそのユーザアバターＭ１）は、当該所有者ＩＤが対応付けられたチケットＩＤのチケットを所持していると判定できる。また、当該チケットのチケットＩＤに有効フラグ“１”が対応付けられている場合に、当該チケットは、コンテンツ提供位置へと移動できるチケットであると判定できる。

【0187】

チケット所持判定は、任意のタイミングで実行されてよく、例えば、上述したワープボタン１８００（図３Ａ参照）が出現している状態で実行されてよい。あるいは、チケット所持判定は、ユーザアバターＭ１の位置情報（図６参照）に基づいて、コンテンツ提供位置に係る入口領域に位置するユーザアバターＭ１に対して実行されてもよい。コンテンツ提供位置に係る入口領域（例えば図１９の入口位置ＳＰ２）は、コンテンツ提供位置への移動を希望するユーザアバターＭ１が位置する領域であり、当該入口領域にユーザアバターＭ１が位置することは、ユーザアバターＭ１のコンテンツ提供位置への移動を希望することのユーザの意思表示であってよい。あるいは、入口領域にユーザアバターＭ１が位置することに加えて、チケットの提示操作等が、ユーザアバターＭ１のコンテンツ提供位置への移動を希望するユーザの意思表示として扱われてよい。

【0188】

ここで、本実施形態では、第２移動権限処理部１６４に関連して上述したようにチケットの譲渡が可能とされている。従って、チケット所持判定部１６６１は、一のコンテンツ提供位置となる空間部に係るチケット所持判定の際、当該一のコンテンツ提供位置に係るチケットを初期的に購入していないユーザに係るユーザアバターＭ１に対しても、当該一のコンテンツ提供位置へと移動できると判定する場合がある。具体的には、チケット所持判定部１６６１は、一のユーザアバターＭ１に、一のコンテンツ提供位置に係る複数のチケットの取得済み情報が対応付けられており、かつ、他の一のユーザアバターＭ１が所定の条件を満たした場合に、当該一のコンテンツ提供位置に係る空間部への当該他の一のユーザアバターＭ１の移動が可能であると判定する。例えば図１８に示す例では、ユーザ名“ユーザＢ”に係るユーザアバターＭ１には、５枚のチケットＡの取得済み情報が対応付けられており、この場合、ユーザ名“ユーザＡ”に係るユーザが、正当にユーザ名“ユーザＢ”に係るユーザからチケットＡを譲り受けた場合（所定の条件の一例）、ユーザ名“ユーザＡ”に係るユーザのユーザアバターＭ１は、チケットＡのコンテンツ提供位置に移動できる。

【0189】

無効化処理部１６６２は、ある一のユーザアバターＭ１に関して、チケット所持判定部１６６１により、コンテンツ提供位置へと移動できるチケットを所有していると判定された場合、当該一のユーザアバターＭ１がコンテンツ提供位置へと移動することを許可する。他方、無効化処理部１６６２は、ある一のユーザアバターＭ１に関して、チケット所持判定部１６６１により、コンテンツ提供位置へと移動できるチケットを所有していないと判定された場合、当該一のユーザアバターＭ１がコンテンツ提供位置へと移動することを禁止する。この場合、本実施形態では、無効化処理部１６６２は、一のユーザアバターＭ１に対応付けられたワープボタン１８００（コンテンツ提供位置への移動のためのワープ入力）を無効化することで、当該一のユーザアバターＭ１がコンテンツ提供位置へと移動することを禁止する。例えば、無効化処理部１６６２は、ワープボタン１８００の無効化指示をユーザインタフェース描画部１５８２に出力する。この場合、ユーザインタフェース描画部１５８２は、一のユーザアバターＭ１に対応付けられたワープボタン１８００を表示しないか、非アクティブ状態で表示することで（図１８のワープボタン１８００－１参照）、無効化を実現する。なお、非アクティブ状態のワープボタン１８００－１は、存在自体は可視であるが、操作しようとしてもワープ入力が発生しない。

【0190】

あるいは、無効化処理部１６６２は、ワープボタン１８００の無効化指示に代えて、ワープボタン１８００に係る第２ワープ処理による行き先である第２所定位置を、コンテンツ提供位置が位置する空間部内の位置から、当該空間部の外の位置（例えば入口付近）に変更してもよい。

【0191】

パラメータ更新部１７０は、仮想カメラ６０の各種パラメータ（図４参照）の各値を更新する。なお、仮想カメラ６０の各種パラメータの各値は、上述したように、端末用画像ごと（ユーザアバターＭ１ごと）に異なりうる。パラメータ更新部１７０は、一のユーザアバターＭ１の位置／向き情報に応じて、当該一のユーザアバターＭ１に係る仮想カメラ６０の各種パラメータの各値を更新してよい。また、パラメータ更新部１７０は、上述した端末画像生成部１５８の一人称視点モード等のモードの変化に応じて、仮想カメラ６０の各種パラメータの各値を更新してよい。

【0192】

次に、図２０から図２３等を参照して、仮想現実生成システム１の動作例について説明する。なお、以降の処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。

【0193】

図２０は、仮想現実生成システム１の各種動作のうちの、案内情報の描画とワープボタン１８００の描画に関連した動作の一例を示す概略フローチャートである。図２０に示す処理は、ある一のユーザに対する処理を示し、一のユーザに係る端末装置２０における仮想現実アプリケーションが起動された場合に起動し、仮想現実アプリケーションがオフされるまで、所定周期ごとに繰り返し実行されてよい。なお、図２０に示す処理は、ユーザごとに並列的に実行されてよい。

【0194】

ステップＳ２０００では、サーバ装置１０は、一のユーザに係るユーザアバターＭ１が仮想空間内に入ったか否かを判定する。すなわち、仮想空間への入室があったか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２００２に進み、それ以外の場合は、ステップＳ２００４に進む。以下では、ユーザとは、特に言及しない限り、ステップＳ２０００で仮想空間内に入ったと判定されたユーザアバターＭ１に係るユーザを指し、ユーザアバターＭ１とは、ステップＳ２０００で仮想空間内に入ったと判定されたユーザアバターＭ１を指す。

【0195】

ステップＳ２００２では、サーバ装置１０は、ユーザアバターＭ１にグループＩＤを割り当てる。なお、ユーザは、仮想空間内に入るとき、グループ名を入力することとしてよい。この場合、グループ名の入力は、現在稼働中のグループ名のリストから所望のグループ名を選択することで実現されてもよい。この場合、サーバ装置１０は、グループ名に対応するグループＩＤにユーザアバターＭ１を対応付けることで、グループ状態記憶部１４６内のグループ状態情報１０００（図１０参照）を更新する。なお、新たなグループ名が入力された場合は、新たなグループＩＤが設定されてよい。

【0196】

ステップＳ２００４では、サーバ装置１０は、ユーザアバターＭ１が仮想空間から退出したか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２００６に進み、それ以外の場合（すなわち、仮想空間内で依然として活動中である場合）は、ステップＳ２００８に進む。

【0197】

ステップＳ２００６では、サーバ装置１０は、ユーザアバターＭ１をグループから外す（除去する）ことでグループ状態記憶部１４６内のグループ状態情報１０００（図１０参照）を更新する。なお、ユーザアバターＭ１の退出は、グループ内の他のユーザアバターＭ１に係るユーザに通知されてもよい。例えば、ユーザアバターＭ１の退出は、グループ情報表示領域３０００内の情報を更新することで、グループ内の他のユーザアバターＭ１に係るユーザに通知されてもよい。

【0198】

ステップＳ２００８では、サーバ装置１０は、グループ状態記憶部１４６内のグループ状態情報１０００に基づいて、同一グループ内の他のユーザアバターＭ１（すなわちフレンドアバター）が存在するか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２００９に進み、それ以外の場合は、ステップＳ２０１７に進む。

【0199】

ステップＳ２００９では、サーバ装置１０は、案内情報出力処理を実行する。案内情報出力処理の一例は、図２１を参照して後述する。

【0200】

ステップＳ２０１０では、サーバ装置１０は、グループ内の１人以上の他のユーザアバターＭ１（フレンドアバター）のユーザＩＤを所定順にソートし、変数ｊを初期値“１”に設定する。

【0201】

ステップＳ２０１１では、サーバ装置１０は、ｊ番目のフレンドアバターに対してワープ条件判定処理を行う。ワープ条件判定処理の一例は、図２２を参照して後述する。

【0202】

ステップＳ２０１２では、サーバ装置１０は、ステップＳ２０１１でのワープ条件判定処理の結果に基づいて、ユーザアバターＭ１がｊ番目のフレンドアバターのそばまで瞬間移動するための所定のワープ条件が成立しているか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２０１３に進み、それ以外の場合は、ステップＳ２０１４に進む。

【0203】

ステップＳ２０１３では、サーバ装置１０は、所定のワープ条件が成立するフレンドアバターに対応付けてワープボタン１８００を操作可能に描画する。

【0204】

ステップＳ２０１４では、サーバ装置１０は、所定のワープ条件が成立しないフレンドアバターに対応付けてワープボタン１８００を操作不能に描画するとともに、上述した補助情報を描画する。これにより、ユーザは、補助情報を頼りに、適宜、チケットを取得することで、所定のワープ条件を成立させることができる。

【0205】

ステップＳ２０１５では、サーバ装置１０は、変数ｊがグループ内のフレンドアバターの数に一致するか否かを判定する。すなわち、すべてのフレンドアバターに対して所定のワープ条件の成否を判定したか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２０１７に進み、それ以外の場合は、ステップＳ２０１６を介して、ステップＳ２０１１に戻る。

【0206】

ステップＳ２０１６では、サーバ装置１０は、変数ｊを“１”だけインクリメントする。このようして、仮想空間内にフレンドアバターが複数存在する場合、フレンドアバターごとにワープ条件判定処理が実行されてよい。

【0207】

ステップＳ２０１７では、サーバ装置１０は、グループ内の各ユーザからの各種操作入力に基づいて、各ユーザアバターＭ１の位置／向き情報や、各仮想カメラ６０の各カメラパラメータの各値等を更新する。

【0208】

ステップＳ２０１８では、サーバ装置１０は、グループ内の各ユーザ用の端末用画像を生成し、各ユーザの端末装置２０に送信する。

【0209】

ステップＳ２０２０では、サーバ装置１０は、グループ内の各ユーザからの音声入力等に基づいて、対話処理を実行する。対話処理は、対話処理部１６０に関連して上述した通りであってよい。

【0210】

図２１は、案内情報出力処理（図２０のステップＳ２００９）の一例を示す概略的なフローチャートである。

【0211】

ステップＳ２１００では、サーバ装置１０は、グループ内の１人以上の他のユーザアバターＭ１（フレンドアバター）を抽出し、抽出したフレンドアバターに係るユーザＩＤ（又はユーザアバターＩＤ）を所定順にソートする。

【0212】

ステップＳ２１０２では、サーバ装置１０は、変数ｋを初期値“１”に設定する。

【0213】

ステップＳ２１０４では、サーバ装置１０は、ｋ番目のフレンドアバターを処理対象として、ユーザアバターＭ１とｋ番目のフレンドアバターとの間の距離（図２１では「アバター間距離」と表記）であって、今回周期の距離ｄ（ｉ）を算出する。なお、ここでは、“ｉ”は、周期数を表す任意の整数とする。距離ｄ（ｉ）は、上述したように、グローバル座標系での距離であってよい。

【0214】

ステップＳ２１０５では、サーバ装置１０は、ｋ番目のフレンドアバターに対して案内情報の所定の出力条件が成立したか否かを判定する。所定の出力条件は、上述したように任意であるが、例えば、ここでは、距離ｄ（ｉ）が所定距離Ｄ４以上である場合に満たされてよい。この場合、所定距離Ｄ４は、上述した所定距離Ｄ２よりも有意に大きく、上述した所定距離Ｄ３と同じであってもよい。判定結果が“ＹＥＳ”の場合、ステップＳ２１０６に進み、それ以外の場合、ステップＳ２１１２に進む。

【0215】

ステップＳ２１０６では、サーバ装置１０は、今回周期の距離ｄ（ｉ）と前回周期の距離ｄ（ｉ－１）とに基づいて、ユーザアバターＭ１とｋ番目のフレンドアバターとの間の距離が前回周期よりも今回周期の方が縮まっているか否かを判定する。なお、変形例では、前回周期の距離ｄ（ｉ－１）に代えて、前回以前の所定数の周期での距離の平均値等が利用されてもよい。判定結果が“ＹＥＳ”の場合、ステップＳ２１０８に進み、それ以外の場合は、ステップＳ２１１０に進む。

【0216】

ステップＳ２１０８では、サーバ装置１０は、ユーザアバターＭ１とｋ番目のフレンドアバターとの間の位置関係を表す案内情報であって、ユーザアバターＭ１とｋ番目のフレンドアバターとの間の距離が縮まっていることを表す距離変化情報（距離短縮を表す案内情報）を含む案内情報を描画する。案内情報の描画方法は、上述した通りであってよい。

【0217】

ステップＳ２１１０では、サーバ装置１０は、ユーザアバターＭ１とｋ番目のフレンドアバターとの間の位置関係を表す案内情報であって、ユーザアバターＭ１とｋ番目のフレンドアバターとの間の距離が増えていることを表す距離変化情報（距離増加を表す案内情報）を含む案内情報を描画する。案内情報の描画方法は、上述した通りであってよい。

【0218】

ステップＳ２１１２では、サーバ装置１０は、変数ｋがグループ内のフレンドアバターの数に一致するか否かを判定する。すなわち、すべてのフレンドアバターに対して案内情報を描画したか否かを判定する。判定結果が“ＹＥＳ”の場合、図２１の処理を終了し、それ以外の場合は、ステップＳ２１１４を介して、ステップＳ２１０４に戻る。

【0219】

ステップＳ２１１４では、サーバ装置１０は、変数ｋを“１”だけインクリメントする。このようして、仮想空間内にフレンドアバターが複数存在する場合、フレンドアバターごとに距離の変化態様が評価されてよい。

【0220】

このようにして図２０及び図２１に示す処理によれば、グループ内のフレンドアバターごとに案内情報やワープボタン１８００を描画でき、仮想空間におけるユーザアバターＭ１の移動を効果的に支援できる。

【0221】

図２２は、ワープ条件判定処理（図２０のステップＳ２０１１）の一例を示す概略的なフローチャートである。

【0222】

ステップＳ２２００では、サーバ装置１０は、ｊ番目のフレンドアバターの位置／向き情報に基づいて、ｊ番目のフレンドアバターが位置する空間部（コンテンツ提供位置）を特定する。

【0223】

ステップＳ２２０２では、サーバ装置１０は、ユーザアバターＭ１の位置／向き情報に基づいて、ユーザアバターＭ１が特定領域内に位置するか否かを判定する。本実施形態では、特定領域は、任意の位置であるので、ステップＳ２２０２は自動的に満たされることとしてよい。ただし、変形例の場合、特定領域は、仮想空間内の一部の領域（例えば、ｊ番目のフレンドアバターから所定距離Ｄ３内の領域）を除く領域であってよい。判定結果が“ＹＥＳ”の場合、ステップＳ２２０４に進み、それ以外の場合は、ステップＳ２２１８に進む。

【0224】

ステップＳ２２０４では、サーバ装置１０は、コンテンツ情報記憶部１４４内のデータに基づいて、ｊ番目のフレンドアバターが位置する空間部（コンテンツ提供位置）に移動するのにチケットが必要であるか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２２０６に進み、それ以外の場合は、ステップＳ２２０８に進む。

【0225】

ステップＳ２２０６では、サーバ装置１０は、ユーザアバターＭ１が、ｊ番目のフレンドアバターが位置する空間部（コンテンツ提供位置）に移動するためのチケットを所持しているか否かを判定する。この判定方法は、チケット所持判定部１６６１に関連して上述した通りであってよい。判定結果が“ＹＥＳ”の場合、ステップＳ２２０８に進み、それ以外の場合は、ステップＳ２２１０に進む。

【0226】

ステップＳ２２０８では、サーバ装置１０は、ｊ番目のフレンドアバターが位置する空間部（コンテンツ提供位置）へとユーザアバターＭ１が移動可能な状態（移動許可状態）を形成する。この場合、所定のワープ条件が満たされることになり、ステップＳ２０１２の判定結果は“ＹＥＳ”となる。

【0227】

ステップＳ２２１０では、サーバ装置１０は、ｊ番目のフレンドアバターが位置する空間部（コンテンツ提供位置）へとユーザアバターＭ１が移動不能な状態（移動禁止状態）を形成する。この場合、所定のワープ条件が満たされないことになり、ステップＳ２０１２の判定結果は“ＮＯ”となる。

【0228】

ステップＳ２２１２では、サーバ装置１０は、チケット情報記憶部１４５内のデータ（図９参照）に基づいて、ｊ番目のフレンドアバターに、当該ｊ番目のフレンドアバターが位置する空間部（コンテンツ提供位置）に移動するためのチケットが複数枚対応付けられているか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２２１４に進み、それ以外の場合は、ステップＳ２２１６に進む。

【0229】

ステップＳ２２１４では、サーバ装置１０は、ユーザアバターＭ１に係るユーザに、ｊ番目のフレンドアバターに係るユーザへのチケット譲渡のリクエストを促す補助情報（図１８の補助情報１８４０－１参照）を出力する。補助情報は、上述したように、ワープボタン１８００に対応付けて描画されてもよい（図１８参照）。補助情報は、ｊ番目のフレンドアバターに係るユーザへリクエストを送信する際に操作されるボタンを含んでもよい。なお、かかる補助情報の出力は、ユーザアバターＭ１の行き先が、ｊ番目のフレンドアバターのそばである可能性が高い場合のみ実行されてもよい。

【0230】

ステップＳ２２１６では、サーバ装置１０は、ユーザアバターＭ１に係るユーザに、ｊ番目のフレンドアバターが位置する空間部（コンテンツ提供位置）へ移動するためのチケットの販売位置を通知する補助情報（図１８の補助情報１８４０－２参照）を出力する。なお、かかる補助情報は、チケットの販売位置（チケット売場）に瞬間移動する際にアクセス又は操作されるリンク又はボタンを含んでもよい。

【0231】

ステップＳ２２１８では、サーバ装置１０は、ｊ番目のフレンドアバターが位置する空間部（コンテンツ提供位置）へとユーザアバターＭ１が移動不能な状態（移動禁止状態）を形成する。この場合、所定のワープ条件が満たされないことになり、ステップＳ２０１２の判定結果は“ＮＯ”となる。

【0232】

なお、図２２に示す処理では、ステップＳ２２１４において、サーバ装置１０は、ユーザアバターＭ１に係るユーザに、ｊ番目のフレンドアバターに係るユーザへのチケット譲渡のリクエストを促す補助情報を出力するが、これに加えて、ステップＳ２２１６で出力する補助情報を出力してもよい。

【0233】

図２３は、図２２の説明図であり、ユーザアバターＭ１に係るユーザからｊ番目のフレンドアバターに係るユーザへのリクエストが送信される場合の概略的なフローチャートである。

【0234】

図２３において、端末装置２０Ａは、ｊ番目のフレンドアバターに対応付けられているユーザに係る端末装置２０を表し、端末装置２０Ｂは、ユーザアバターＭ１に対応付けられているユーザに係る端末装置２０を表す。

【0235】

この場合、ｊ番目のフレンドアバターに対応付けられているユーザは、端末装置２０Ａ上で複数枚のチケットを購入すると（ステップＳ２３００）、当該チケットの購入情報がサーバ装置１０で記憶（更新）される（図９に示したチケット情報記憶部１４５内のチケット情報９００参照）（ステップＳ２３０２）。

【0236】

その後、サーバ装置１０は、端末装置２０Ｂに、ｊ番目のフレンドアバターに係るユーザへのチケット譲渡のリクエストを促す補助情報を出力する（図２２のステップＳ２２１４参照）（ステップＳ２３０４）。この補助情報を受けて、端末装置２０Ｂから端末装置２０Ａにリクエストが送信される（ステップＳ２３０６）。なお、このリクエストは、サーバ装置１０を介して端末装置２０Ｂから端末装置２０Ａに送信されてもよい。

【0237】

ｊ番目のフレンドアバターに対応付けられているユーザは、端末装置２０Ｂからのリクエストに応答して、譲渡入力をサーバ装置１０に送信する（ステップＳ２３０８）とともに、端末装置２０Ｂに係るユーザに、譲渡用の認証情報を通知する（ステップＳ２３１０）。なお、譲渡入力は、上述したように、ｊ番目のフレンドアバターに対応付けられているユーザから事前に（例えばステップＳ２３００の段階で）送信されてもよい。同様に、譲渡用の認証情報は、上述したように、ｊ番目のフレンドアバターに対応付けられているユーザから端末装置２０Ｂのユーザへと事前に通知されていてもよい。

【0238】

端末装置２０Ｂのユーザは、ｊ番目のフレンドアバターに対応付けられているユーザから譲渡用の認証情報の通知を受けると、譲渡用の認証情報をサーバ装置１０に送信する（ステップＳ２３１１）。なお、サーバ装置１０は、リクエストを端末装置２０Ａに送信する際に、譲渡用の認証情報の入力画面を端末装置２０Ｂに出力させてもよい。

【0239】

サーバ装置１０は、端末装置２０Ｂから譲渡用の認証情報を受信すると、照合を行い、照合が成功すると、ｊ番目のフレンドアバターに係るユーザに対応付けられている複数のチケットの１枚を、端末装置２０Ｂに係るユーザに対応付ける（ステップＳ２３１２）。すなわち、このようなチケット情報９００の書き換えは、チケット情報書換部１６４４を参照して上述した通りであってよい。このような書き換えに伴い、サーバ装置１０は、ｊ番目のフレンドアバターに係るワープボタン１８００を操作不能な態様から操作可能な態様に描画し直す（ステップＳ２３１４）。

【0240】

これにより、端末装置２０Ｂのユーザは、ｊ番目のフレンドアバターに係るワープボタン１８００を操作することで、ユーザアバターＭ１をｊ番目のフレンドアバターのそばに瞬間移動させることができる（ステップＳ２３１６）。

【0241】

ところで、図５から図２３を参照して上述した実施形態では、サーバ装置１０が各種機能を網羅的に実現しているが、上述したサーバ装置１０の各種機能の一部又は全部は、サーバ装置１０に代えて、端末装置２０によって実現することも可能である。以下では、一例として、サーバ装置１０の各種機能の一部が端末装置２０によって実現される構成について説明する。

【0242】

図２４は、アバター移動案内機能に関連した端末装置２０の機能ブロック図の一例である。以下では、一の端末装置２０について代表して説明し、ユーザとは、特に言及しない限り、端末装置２０に係るユーザを指す。

【0243】

図２４に示す例では、端末装置２０は、ユーザデータベース２４０と、アバターデータベース２４２と、コンテンツ情報記憶部２４４と、チケット情報記憶部２４５と、グループ状態記憶部２４６と、操作入力生成部２５０と、サーバ情報取得部２５１と、ユーザアバター処理部２５２（取得部の一例及び位置変更部の一例）と、フレンドアバター処理部２５４と、操作入力送信部２５５と、端末画像生成部２５８と、コンテンツ処理部２５９と、対話処理部２６０と、パラメータ更新部２７０とを含む。

【0244】

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

【0245】

ユーザデータベース２４０からグループ状態記憶部２４６のそれぞれに記憶される各データは、上述したサーバ装置１０のユーザデータベース１４０からグループ状態記憶部１４６のそれぞれに記憶される各データと実質的に同じであってよい。ただし、ユーザデータベース２４０に記憶される各データは、上述したサーバ装置１０のユーザデータベース１４０に記憶されるデータのうちの、ユーザ及びそのフレンドユーザ（同一グループ内のフレンドアバターに係るユーザ、以下同様）に係るデータのみであってよい。これは、チケット情報記憶部２４５やグループ状態記憶部２４６も同様である。

【0246】

操作入力生成部２５０は、ユーザからの各種入力（入力部２４を介した各種入力）に基づいて、上述した操作入力情報を生成する。なお、ユーザからの各種入力は、上述したとおりであり、移動操作入力や、対話用の入力、チケットのリクエスト、譲渡用の認証情報等を含んでもよい。

【0247】

サーバ情報取得部２５１は、サーバ装置１０から、ユーザデータベース２４０からグループ状態記憶部２４６のそれぞれに記憶される各種データを取得する。サーバ情報取得部２５１によるデータの取得タイミングは、任意であるが、仮想現実アプリケーションの更新時等であってよい。ただし、グループ状態記憶部２４６に記憶されるデータの取得（更新）タイミングは、グループを構成するユーザの変化時であってよい。このようにして、ユーザデータベース２４０からグループ状態記憶部２４６のそれぞれに記憶される各種データは、適宜、サーバ情報取得部２５１により取得されるデータに基づいて更新されてよい。

【0248】

ユーザアバター処理部２５２は、上述したサーバ装置１０のユーザアバター処理部１５２と実質的に同様の機能を有する。ただし、ユーザアバター処理部２５２の処理対象のユーザアバターＭ１は、端末装置２０に係るユーザに対応付けられているユーザアバターＭ１のみであってよい。

【0249】

フレンドアバター処理部２５４は、上述したサーバ装置１０のユーザアバター処理部１５２と実質的に同様の機能を有する。ただし、フレンドアバター処理部２５４の処理対象のユーザアバターＭ１は、端末装置２０に係るユーザに対応付けられているユーザアバターＭ１に対するフレンドアバターのみであってよい。

【0250】

ユーザアバター処理部２５２及びフレンドアバター処理部２５４は、それぞれ、上述したサーバ装置１０のユーザアバター処理部１５２と同様、処理対象のユーザアバターＭ１に関して、移動操作入力に基づく移動処理や、第１ワープ処理、第２ワープ処理等の各種処理を実現する。ユーザアバター処理部２５２は、ユーザに係る操作入力情報に基づいて各種処理を行い、フレンドアバター処理部２５４は、フレンドユーザに係る操作入力情報に基づいて各種処理を行ってよい。これにより、各ユーザアバターＭ１の位置／向き情報が更新される。

【0251】

操作入力送信部２５５は、操作入力生成部２５０により生成された操作入力情報をサーバ装置１０に送信する。なお、操作入力送信部２５５は、操作入力情報に代えて、ユーザアバター処理部２５２により当該操作入力情報に基づき更新されるユーザアバターＭ１の位置／向き情報を、サーバ装置１０に送信してもよい。また、操作入力送信部２５５は、ユーザに係るユーザアバターＭ１が活動する仮想空間内の他のユーザアバターＭ１（フレンドアバター）が存在する場合のみ、操作入力情報をサーバ装置１０に送信してもよい。

【0252】

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

【0253】

具体的には、端末画像生成部２５８は、ベース画像描画部２５８１と、ユーザインタフェース描画部２５８２と、案内情報描画部２５８３と、補助情報描画部２５８４と、ワープ動作描画部２５８５とを含む。ベース画像描画部２５８１からワープ動作描画部２５８５のそれぞれは、上述したサーバ装置１０のベース画像描画部１５８１からワープ動作描画部１５８５のそれぞれと同様であってよい。ただし、描画対象の端末用画像は、一の端末装置２０用の端末用画像のみである。

【0254】

コンテンツ処理部２５９は、コンテンツ提供位置ごとにユーザにコンテンツを提供する。ユーザに提供するコンテンツは、コンテンツ提供条件が満たされた場合にサーバ装置１０から取得されてよい。

【0255】

対話処理部２６０は、上述したサーバ装置１０の対話処理部１６０と実質的に同様の機能を有する。対話処理部２６０は、ユーザ及びそのフレンドユーザからの対話用の各入力に基づいて、同一グループ内のユーザ間の対話に係る対話処理を実行する。

【0256】

パラメータ更新部２７０は、ユーザアバターＭ１に対応付けられている仮想カメラ６０の各種パラメータ（図４参照）の各値を更新する。

【0257】

図２５は、図２４に示す端末装置２０による動作例であって、端末画像生成部２５８に関連した動作例を示す概略的なフローチャートである。図２５において、端末装置２０Ｃは、ユーザに係る図２４に示す端末装置２０を表し、端末装置２０Ｄは、同一グループ内の一のフレンドアバターに対応付けられているユーザに係る図２４に示す端末装置２０を表す。なお、ここでは、端末装置２０Ｄに係るユーザは、一人であるが、２人以上であっても同様である。すなわち、この場合、端末装置２０Ｃと複数の端末装置２０Ｄのそれぞれが組をなして、図２２に示す動作例が実現されてよい。

【0258】

端末装置２０Ｃ及び端末装置２０Ｄのそれぞれにおいては、対応するユーザによる各種入力に基づいて操作入力情報を生成し（ステップＳ２５００、ステップＳ２５０１）、生成した操作入力情報をサーバ装置１０に送信する（ステップＳ２５０２、ステップＳ２５０８）。サーバ装置１０は、同一グループ内の各ユーザの端末装置２０（ここでは、端末装置２０Ｃ及び端末装置２０Ｄ）から受信された操作入力情報を、転送する（ステップＳ２５０４、ステップＳ２５１０）。なお、この際、サーバ装置１０は、操作入力情報をそのまま転送してもよいし、所定の加工等を施してから送信してもよい。例えば、操作入力情報は、各ユーザアバターＭ１の位置／向き情報に変換されてから送信されてもよい。このようにして操作入力情報（フレンドアバターに係る操作入力情報）は、端末装置２０Ｃ及び端末装置２０Ｄのそれぞれにおいて受信される（ステップＳ２５１２、ステップＳ２５０６）。

【0259】

端末装置２０Ｃにおいては、ステップＳ２５００で生成した操作入力情報や、ステップＳ２５１２で受信した操作入力情報（フレンドアバターに係る操作入力情報）に基づいて、各ユーザアバターＭ１の位置／向き情報を更新するとともに端末用画像を描画する（ステップＳ２５１４）。この際、上述したような案内情報や補助情報等も描画される。同様に、端末装置２０Ｄにおいては、ステップＳ２５０１で生成した操作入力情報や、ステップＳ２５０６で受信した操作入力情報（フレンドアバターに係る操作入力情報）に基づいて、各ユーザアバターＭ１の位置／向き情報を更新するとともに端末用画像を描画する（ステップＳ２５１６）。この際、上述したような案内情報や補助情報等も描画される。

【0260】

このような動作は、端末装置２０Ｃ及び端末装置２０Ｄのそれぞれにおいては、対応するユーザアバターＭ１が仮想空間から退出するまで（ステップＳ２５１８の“ＹＥＳ”、ステップＳ２５２０の“ＹＥＳ”）、繰り返される。

【0261】

なお、図２５では、図示されていないが、上述した対話処理（同一グループ内のユーザアバターＭ１間に係る対話処理）についても、端末装置２０Ｃ及び端末装置２０Ｄのそれぞれにおいて生成される音声入力等が、上述した操作入力情報の場合と同様の態様で端末装置２０Ｃ及び端末装置２０Ｄ間でやり取りされることで、実現されてよい。

【0262】

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

【0263】

例えば、上述した実施形態において、案内情報の描画は、先導者アバター（図示せず）の出現（描画）により実現されてもよい。この場合、先導者アバターは、先行ユーザアバターＭ６まで移動することで、案内対象ユーザアバターＭ５を先行ユーザアバターＭ６まで誘導できる。すなわち、案内対象ユーザアバターＭ５に係るユーザは、先導者アバターの後を案内対象ユーザアバターＭ５が追うように、移動操作入力を行うことで、案内対象ユーザアバターＭ５を先行ユーザアバターＭ６のそばまで容易に移動させることができる。なお、この場合、先導者アバターは、先行ユーザアバターＭ６を示唆する容姿等を有してもよい。また、先導者アバターは、自動的に案内対象ユーザアバターＭ５を先行ユーザアバターＭ６のそばまで移動させるモード（案内対象ユーザアバターＭ５の手を引くモード）を有してもよい。このようなモードは、第２ワープ処理において実現されてもよい。

【0264】

また、上述した実施形態では、第２ワープ処理は、瞬間移動されるユーザアバターＭ１に対応付けられるユーザによるワープ入力により実現されるが、これに限られない。すなわち、第２ワープ処理は、瞬間移動されるユーザアバターＭ１に対応付けられるユーザ以外のユーザによるワープ入力により実現されてもよい。例えば親子関係のような特定のフレンド関係の場合、親ユーザによる特定のワープ入力に基づいて、子供ユーザに対応付けられるユーザアバターＭ１を、親ユーザに対応付けられるユーザアバターＭ１のそばまで瞬間移動させることが可能であってもよい。この場合、特定のワープ入力のためのユーザインタフェースは、例えば、逆ワープボタンや迷子ボタンといった名称で、ワープボタン１８００とは異なるボタンにより実現されてもよい。この場合、例えば親子で仮想現実を楽しむユーザにとってユーザフレンドリな移動支援を実現できる。また、子供ユーザがワープボタンを操作できない場合でも、子供ユーザに係る端末装置２０において、描画に係る処理負荷及びそれに伴う電力消費（電源の充電状態の減少）を低減できる。

【0265】

また、上述した実施形態では、第２ワープ処理は、案内対象ユーザアバターＭ５の近傍に、ワープ領域１１００のようなワープ領域の出現により実現されてもよい。この場合、ワープ領域１１００の出口側は、先行ユーザアバターＭ６の近傍に設定されてもよい。この場合、案内対象ユーザアバターＭ５に係るユーザは、近傍のワープ領域へと案内対象ユーザアバターＭ５を移動させる比較的簡単な移動操作入力を行うだけで、先行ユーザアバターＭ６の近傍まで案内対象ユーザアバターＭ５を瞬間移動させることができる。

【0266】

また、上述した実施形態において、案内情報描画部１５８３（案内情報描画部２５８３についても同様）の機能は、ユーザによる選択によりオン／オフ可能であってもよい。

【0267】

また、上述した実施形態において、チケットを要する空間部に位置する一のフレンドアバターのそばまでユーザアバターＭ１を瞬間移動させる第２ワープ処理に関して、第２所定位置は、ユーザアバターＭ１のチケット所持状況に応じて変化されてもよい。例えば、ユーザアバターＭ１が当該空間部内に移動するためのチケットを所持している場合は、第２所定位置は、当該空間部内に設定されてもよい。他方、ユーザアバターＭ１が当該空間部内に移動するためのチケットを所持していない場合は、第２所定位置は、当該空間部の外（例えば入口）であってよい。このような構成は、当該空間部の外（例えば入口）に、当該空間部に移動するためのチケットを販売するチケット売場がある場合に好適である。

【符号の説明】

【0268】

１ 仮想現実生成システム
３ ネットワーク
１０ サーバ装置
２０ 端末装置
６０ 仮想カメラ
７０ 空間部
７１ フリー空間部
１４０ ユーザデータベース
１４２ アバターデータベース
１４４ コンテンツ情報記憶部
１４５ チケット情報記憶部
１４６ グループ状態記憶部
１５０ グループ設定部
１５２ ユーザアバター処理部
１５２１ 操作入力取得部
１５２２ ユーザ動作処理部
１５２２１ 基本動作処理部
１５２２２ 第１ワープ処理部
１５２２３ 第２ワープ処理部
１５８ 端末画像生成部
１５８１ ベース画像描画部
１５８２ ユーザインタフェース描画部
１５８３ 案内情報描画部
１５８３１ 距離算出部
１５８３２ 距離変化判定部
１５８４ 補助情報描画部
１５８５ ワープ動作描画部
１５８６ 空間部遷移描画部
１５９ コンテンツ処理部
１６０ 対話処理部
１６２ 第１移動権限処理部
１６２１ 購入入力取得部
１６２２ チケットＩＤ生成部
１６２３ 認証情報通知部
１６２４ チケット描画部
１６４ 第２移動権限処理部
１６４０ 譲渡入力取得部
１６４１ 認証通知案内部
１６４４ チケット情報書換部
１６６ 判断処理部
１６６１ チケット所持判定部
１６６２ 無効化処理部
１７０ パラメータ更新部
２４０ ユーザデータベース
２４２ アバターデータベース
２４４ コンテンツ情報記憶部
２４５ チケット情報記憶部
２４６ グループ状態記憶部
２５０ 操作入力生成部
２５１ サーバ情報取得部
２５２ ユーザアバター処理部
２５４ フレンドアバター処理部
２５５ 操作入力送信部
２５８ 端末画像生成部
２５８１ ベース画像描画部
２５８２ ユーザインタフェース描画部
２５８３ 案内情報描画部
２５８４ 補助情報描画部
２５８５ ワープ動作描画部
２５９ コンテンツ処理部
２６０ 対話処理部
２７０ パラメータ更新部
３００ ユーザインタフェース
３０９ 対話用インタフェース
３５０ アバターアイコン
３５１ アバターアイコン
３５２ アバターアイコン
３６０ マイクアイコン
１８００（１８００－１、１８００－２） ワープボタン

【図1】

【図2】

【図3】

【図3A】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11A】

【図11B】

【図11C】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】