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

Abstract

【課題】移動権限情報を他のユーザに譲渡する仕組みを比較的簡易かつ比較的安全に実現する。【解決手段】仮想空間を描画する空間描画処理部と、仮想空間内で移動可能な各移動媒体であって、各ユーザに対応付けられる各移動媒体を描画する媒体描画処理部と、第１ユーザからの第１入力に基づいて、第１ユーザに対応付けられた第１移動媒体に所定の移動権限情報を対応付ける第１移動権限処理部と、第１ユーザからの第２入力に基づいて、第１移動権限処理部によって第１移動媒体に対応付けられた所定の移動権限情報を、第１ユーザとは異なる第２ユーザに対応付けられた第２移動媒体へと対応付け替える第２移動権限処理部と、一の移動媒体に所定の移動権限情報が対応付けられているか否かに基づいて、仮想空間内の所定位置への一の移動媒体の移動の可否を判断する判断処理部とを含む、情報処理システムが開示される。【選択図】図４

Description

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

ユーザ端末からのチケット購入申込に従ってチケットを特定するチケットＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）とユーザＩＤとを対応付けてデータベースに登録し、サーバからのユーザＩＤ及びコンテンツＩＤを伴う問い合わせに対して、データベースを参照し、コンテンツＩＤに対応するチケットＩＤ及びユーザＩＤが存在することを条件として、サーバに、当該ユーザＩＤへのコンテンツの提供が可能である旨を送信する技術が知られている。

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

上記のような従来技術では、チケットのような特定のコンテンツ提供場所への移動権限情報を他のユーザに譲渡する仕組みを、簡易な構成で安全に実現することが難しい。

そこで、１つの側面では、本発明は、移動権限情報を他のユーザに譲渡する仕組みを比較的簡易かつ比較的安全に実現することを目的とする。

１つの側面では、仮想空間を描画する空間描画処理部と、
前記仮想空間内で移動可能な各移動媒体であって、各ユーザに対応付けられる各移動媒体を描画する媒体描画処理部と、
第１ユーザからの第１入力に基づいて、前記第１ユーザに対応付けられた第１移動媒体に所定の移動権限情報を対応付ける第１移動権限処理部と、
前記第１ユーザからの第２入力に基づいて、前記第１移動権限処理部によって前記第１移動媒体に対応付けられた前記所定の移動権限情報を、前記第１ユーザとは異なる第２ユーザに対応付けられた第２移動媒体へと対応付け替える第２移動権限処理部と、
一の移動媒体に前記所定の移動権限情報が対応付けられているか否かに基づいて、前記仮想空間内の所定位置への前記一の移動媒体の移動の可否を判断する判断処理部とを含む、情報処理システムが提供される。

１つの側面では、本発明によれば、移動権限情報を他のユーザに譲渡する仕組みを比較的簡易かつ比較的安全に実現することが可能となる。

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

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

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

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

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

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

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

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

本実施形態では、ユーザは、一般ユーザと、スタッフユーザ（第３ユーザの一例）とを含む。一般ユーザは、仮想現実生成システム１の運営に関与しないユーザであり、スタッフユーザは、仮想現実生成システム１の運営に関与するユーザである。スタッフユーザは、仮想現実内において一般ユーザのサポート等を行う役割（エージェント機能）を有する。スタッフユーザは、例えば、いわゆるゲームマスターと呼ばれるユーザを含む。以下では、特に言及しない限り、ユーザとは、一般ユーザとスタッフユーザの双方を指す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図２Ａは、旅行に係る仮想現実の説明図であり、仮想空間を平面視で示す概念図である。この場合、仮想空間内には、チケット（この場合、航空券等）を購入又は受け取る位置ＳＰ１と、ゲート付近の位置ＳＰ２とが設定される。図２Ａでは、二人の別々のユーザに対応付けられた、ユーザアバタｍ１が示されている。

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

図２Ｂは、教育に係る仮想現実の説明図であり、仮想空間を平面視で示す概念図である。この場合も、仮想空間内には、チケット（この場合、入場券等）を購入又は受け取る位置ＳＰ１と、ゲート付近の位置ＳＰ２とが設定される。図２Ｂでは、二人の別々のユーザに対応付けられた、ユーザアバタｍ１が示されている。

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

例えば、教育が、ある３Ｄモデリング用のソフトウェアに関する場合、第１コンテンツは、当該ソフトウェアのインストールリンク画像等を含み、第２コンテンツは、アドオンのインストールリンク動画等を含み、第３コンテンツは、初期設定用動画を含み、第４コンテンツは、基本操作用動画を含む、といった具合であってよい。

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

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

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

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

このようにして、本実施形態では、図２Ａから図２Ｃで例示したように、仮想現実において、ユーザは、ユーザアバタｍ１を介して、所定位置で、有用なコンテンツの提供を、各ユーザの必要なタイミング及び視聴形態で受けることができる。
ところで、仮想現実においても、現実の場合と同様、一定の提供条件を満たしたユーザのみがコンテンツの提供を受けることができるようにする仕組みが必要となりうる。例えば、現実では、人は、あるコンテンツの提供（例えば遊園地内のアトラクションの体験）を受けることができる位置に至るために、当該コンテンツの対価を支払うことでチケットを入手する場合がある。この場合、例えば親子連れの場合、親が子供の分のチケットも購入し、親が子供とともに、あるコンテンツの提供を受けることができる位置（例えば施設内等）に入場する。

仮想現実の場合も、現実の場合と同様に、複数のユーザが、一緒に仮想現実でコンテンツの提供を受けようとするときに、一のユーザが、連れのユーザ分の、チケットのような移動権限をも纏めて、入手し、一緒に、当該コンテンツの提供を受けることができる位置（例えば施設内等）に入場できると利便性が高くなる。

しかしながら、仮想現実の場合、現実の場合とは異なり、同伴予定の複数のユーザが、現実においてそばにいない場合がありえ、物理的な接触を行うことができない場合が多い。

そこで、本実施形態では、仮想現実生成システム１は、仮想現実において、このような移動権限を表す移動権限情報を、ユーザ間で、安全かつ低減された操作負荷で、譲渡できるようにする仕組みないし機能（以下、「チケット譲渡機能」と称する）を実現する。以下、このチケット譲渡機能の詳細について説明する。

以下では、チケット譲渡機能に関連したサーバ装置１０が、情報処理システムの一例を実現するが、後述するように、特定の一の端末装置２０の各要素（図１参照）が、情報処理システムの一例を実現してもよいし、複数の端末装置２０が、協動して情報処理システムの一例を実現してもよい。また、サーバ装置１０と１つ以上の端末装置２０が、協動して情報処理システムの一例を実現してもよい。

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

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

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

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

ユーザ情報６００は、各ユーザＩＤに、ユーザ名、認証情報、ユーザアバタＩＤ、位置／向き情報等が対応付けられる。ユーザ名は、一般ユーザが自身で登録した名前であり、任意である。認証情報は、一般ユーザが正当な一般ユーザであることを示すための情報であり、例えばパスワードや、メールアドレス、生年月日、合言葉、生体情報等を含んでよい。ユーザアバタＩＤは、ユーザアバタを特定するためのＩＤである。位置／向き情報は、ユーザアバタｍ１の位置情報と向き情報とを含む。向き情報は、ユーザアバタｍ１の顔の向きを表す情報であってよい。なお、位置／向き情報等は、一般ユーザからの操作入力に応じて、動的に変化しうる情報である。位置／向き情報に加えて、ユーザアバタｍ１の手足等の動きを表す情報や、顔の表情等を表す情報を含んでもよい。

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

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

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

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

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

チケット情報記憶部１４４には、チケットに関するチケット情報が記憶される。チケットとは、ユーザアバタｍ１が仮想空間内の所定位置に移動するための移動権限を表す仮想現実媒体である。本実施形態では、一例として、チケットは、スタッフユーザからのもぎり操作入力に応じて、もぎられることが可能な形態である。なお、変形例では、もぎりに代えて、“利用済”を示す印やマーク等が付与される形態であってもよい。

図８に示す例では、チケット情報は、チケットＩＤに、所定位置と、所有者ＩＤと、購入情報、譲渡用の認証情報、もぎり用の認証情報、譲渡情報、有効フラグ、もぎり者ＩＤ、もぎり情報等が対応付けられている。

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

所定位置は、チケットに係る移動権限に基づいて位置できる仮想空間内の位置を表す。所定位置は、特定のコンテンツの提供を受けることができる位置を含む。所定位置は、一点の座標値で定義されてもよいが、典型的には、一纏めの領域又は空間部分を形成する複数の座標値で定義されてよい。また、所定位置は、平面上の位置であってもよいし、空間上の位置（すなわち高さ方向を含む３次元の座標系で表される位置）であってもよい。所定位置は、典型的には、特定のコンテンツごとに、特定のコンテンツの提供位置や属性に応じて設定されてよい。例えば、図２Ａから図２Ｃに示す例では、所定位置は、各ゲートを通って入ることができる仮想空間内の位置である。所定位置は、特定のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）で規定されてもよい。この場合、一般ユーザ等は、当該特定のＵＲＬにアクセスすることで、ユーザアバタｍ１等を所定位置に移動させることができる。この場合、一般ユーザは、特定のＵＲＬにアクセスして、端末装置２０のブラウザ上で特定のコンテンツの提供を受けることができる。

なお、図８に示すチケット情報は、例えば図２Ａに示すようなゲートより内側の所定位置や、図２Ｂに示すようなゲートより内側の所定位置のような、複数種類の所定位置が用意される場合に好適である。所定位置が１種類だけである場合、チケット情報における所定位置は、省略されてもよい。

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

購入情報は、購入者ＩＤや、購入日時、購入方法、販売者ＩＤ等を表す。なお、購入者ＩＤは、購入入力を行ったユーザに対応付けられたユーザＩＤである。販売者ＩＤは、チケットの販売を行ったスタッフユーザのスタッフＩＤである。なお、チケットの販売が仮想空間内でスタッフユーザによる対面で行われていない場合（例えば事前に購入した場合）、販売者ＩＤは省略されてよい。

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

もぎり用の認証情報は、正当なチケットであることを認証するための認証情報であり、チケットＩＤごとに異なる情報である。もぎり用の認証情報は、任意の形態であってよいが、本実施形態では、一例として、数字及び／又は記号よりなる４桁のコードである。なお、もぎり用の認証情報は、事前に発番された固有の識別子の形態であってもよい。また、もぎり用の認証情報は、チケットを購入したユーザが設定してもよい。

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

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

チケットの有効性は、チケットの属性ごとに設定されてもよい。例えば、ある属性のチケットは、もぎられた時点（あるいは、その直ぐ後の時点であって、所定位置に至った時点）で無効化されてもよい。また、他の属性のチケットは、もぎられた時点から、所定時間が経過した時点で無効化されてもよい。また、他の属性のチケットは、もぎられた後、所定位置から離れた時点で無効化されてもよい。あるいは、同じチケットにより再入場が可能な仕組みを更に実現してもよい。この場合、チケットの有効性は、もぎられた時点から所定時間経過するまで維持されてもよい。あるいは、チケットの有効性は、所定回数以上の所定位置への移動（入場）が検出された場合に、無効化されてもよい。

もぎり者ＩＤは、チケットをもぎったスタッフユーザに対応付けられたスタッフアバタＩＤである。本実施形態では、チケットが、スタッフユーザの直接的な関与がなくもぎられる場合があってもよい。この場合、もぎり者ＩＤとしては、自動的にもぎられた旨を表す情報が格納されてよい。

もぎり情報は、もぎりの有無を表し、更に、もぎり日時等を表してもよい。なお、図８において、“－”は、もぎりがなされていないことを示す。

空間状態記憶部１４６には、仮想空間における所定位置に係る空間部分内の状態に関する空間状態情報が格納される。なお、以下では、仮想空間における所定位置に係る空間部分を、部屋（ルーム）として定義されており、一般ユーザに向けてＵＲＬで記述可能とする。同一ルームにアクセスするユーザを同じルームに紐づけられたセッションとして管理する。ルームに係る空間部分にアバタが入ることを入室と表現する場合がある。一のルームに同時にアクセスできるユーザ数には処理能力の観点から限界があるが、同一の設計を持ったルームを複製し、負荷を分散させる処理があってもよい。また、ルームへの入室はアクセス権などで管理される場合もあり、有効なチケットの保有確認や消費が課される処理があってもよい。

図９に示す例では、空間状態情報は、一般ユーザに係るユーザ状態情報９００と、スタッフユーザに係るスタッフ状態情報９０２とを含む。

ユーザ状態情報９００は、入室ユーザに、チケットＩＤ、提供コンテンツ情報等が対応付けられる。入室ユーザは、所定位置に位置しているユーザアバタｍ１に係る一般ユーザであり、入室ユーザの情報は、当該一般ユーザを特定できる任意の情報（ユーザＩＤや、ユーザアバタＩＤ等）であってよい。なお、入室ユーザは、所定位置に位置しているユーザアバタｍ１に係る一般ユーザであり、当該ユーザアバタｍ１の位置情報は、所定位置（複数の座標値で定義される場合、その複数の座標値のうちの１つ）に対応する。換言すると、一のユーザアバタｍ１の位置情報が所定位置に対応しない場合は、当該一のユーザアバタｍ１に係る一般ユーザは、入室ユーザから除外される。ユーザ状態情報９００のチケットＩＤは、入室ユーザが当該入室の際に利用したチケットに対応付けられたチケットＩＤを表す。提供コンテンツ情報は、特定のコンテンツの提供を受けたか否かの情報や、特定のコンテンツの提供を受けているか否かの情報を含んでよい。また、複数の特定のコンテンツが提供されうる仮想空間に関しては、提供コンテンツ情報は、どの特定のコンテンツの提供を受けたかを示す履歴情報や、どの特定のコンテンツの提供を受けているか否かの情報を含んでよい。ユーザ状態情報９００は、その他、「Ｖａｌｉｄａｔｅｄ＿Ａｔ」（チケットが妥当であることが確認された日付時刻）や、「Ｅｘｐｉｒｅ＿ｏｎ」（チケットの有効期限切れ日時）等の情報を含んでもよい。

スタッフ状態情報９０２は、稼働スタッフの情報を含む。稼働スタッフは、所定位置に位置しているスタッフアバタｍ２に係るスタッフユーザであり、稼働スタッフの情報は、当該スタッフユーザを特定できる任意の情報（スタッフＩＤや、スタッフアバタＩＤ等）であってよい。

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

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

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

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

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

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

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

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

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

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

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

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

ここで、上述したように、端末画像生成部１５８の機能は、サーバ装置１０に代えて、端末装置２０によって実現することも可能である。この場合、例えば、端末画像生成部１５８は、サーバ装置１０のスタッフアバタ処理部１５４により生成された位置／向き情報と、描画対象のアバタを特定できる情報（例えばユーザアバタＩＤやスタッフアバタＩＤ）と、当該描画対象のアバタに係るアバタ描画用情報（図７参照）とをサーバ装置１０から受信し、受信した情報に基づいて、各アバタの画像を描画する。この場合、端末装置２０は、アバタの各パーツを描画するためのパーツ情報を端末記憶部２２内に格納しており、当該パーツ情報と、サーバ装置１０から取得する描画対象のアバタ描画用情報（各パーツのＩＤ）とに基づいて、各アバタの容姿を描画してもよい。
端末画像生成部１５８は、好ましくは、一般ユーザ用の端末用画像と、スタッフユーザ用の端末用画像とを、異なる態様で描画する。この場合、ユーザアバタｍ１の位置／向き情報と、スタッフアバタｍ２の位置／向き情報とが完全に一致する場合でも、一般ユーザ用の端末用画像と、スタッフユーザ用の端末用画像とが、異なる態様で描画される。例えば、端末画像生成部１５８は、スタッフユーザ用の端末用画像に、スタッフユーザに与えられた各種の役割を果たすのに有用な情報であって、通常は見えない情報（例えばチケットの有効フラグの情報）を重畳させてもよい。また、端末画像生成部１５８は、スタッフユーザ用の端末用画像において、チケット情報（図８参照）に基づいて、所有者ＩＤが対応付けられたユーザアバタｍ１と、そうでないユーザアバタｍ１とを異なる態様で描画してもよい。この場合、スタッフユーザは、所有者ＩＤが対応付けられたユーザアバタｍ１と、そうでないユーザアバタｍ１とを容易に見分けることができる。

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

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

また、対話処理部１６０は、一般ユーザからの入力と、スタッフユーザからの入力に基づいて、ネットワーク３を介した一般ユーザとスタッフユーザとの間の対話を可能とする。対話は、対応するユーザアバタｍ１とスタッフアバタｍ２とを介して、テキスト及び／又は音声によるチャット形式で実現されてもよい。これにより、一般ユーザは、スタッフユーザからリアルタイムで補助（アシスタント）を受けることができる。

第１移動権限処理部１６２は、一般ユーザからの購入入力（第１入力の一例）に基づいて、チケット（所定の移動権限情報）を発生させ、一般ユーザに対応付けられたユーザアバタｍ１に当該チケットを対応付ける。

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

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

具体的には、第１移動権限処理部１６２は、購入入力取得部１６２１と、チケットＩＤ生成部１６２２と、認証情報通知部１６２３と、チケット描画部１６２４とを含む。

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

購入入力は、所定位置に係る入口付近にユーザアバタｍ１が位置する場合に、当該ユーザアバタｍ１に対応付けられた一般ユーザにより入力可能とされる。仮想空間内における所定位置に係る入口は、明確に規定されている必要はないが、仮想空間内における入口に対応する位置には、例えば入口やゲートといった文字が描画により対応付けられてよい。例えば、図２Ａから図２Ｃに示す例では、チケット購入領域に対応する位置ＳＰ１、入口領域に対応する位置ＳＰ２、及び、それらの近傍は、入口付近に対応する。

この場合、チケットを購入したい一般ユーザは、自身のユーザアバタｍ１を入口付近に至らせ、位置ＳＰ１に対応付けて配置されるスタッフアバタｍ２との対話を介して、購入入力を行うことができる。

あるいは、購入入力は、事前に（所定位置に係る入口付近にユーザアバタｍ１を位置させる前に）、一般ユーザにより入力可能とされてもよい。この場合、チケットを事前に購入していた一般ユーザは、自身のユーザアバタｍ１を入口付近に至らせ、位置ＳＰ１に対応付けて配置されるスタッフアバタｍ２との対話を介して、事前の購入入力を有効化できる。なお、チケットを事前に購入していた一般ユーザが、自身のユーザアバタｍ１を入口付近に至らせると（ユーザＩＤとそれに紐づけられたチケットＩＤを用いて照会することで）、事前の購入入力が自動的に（すなわち更なる入力を必要とせずに）有効化されてもよい。

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

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

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

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

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

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

譲渡入力は、所定位置に係る入口付近に、譲渡側のユーザアバタｍ１が位置する場合に、当該ユーザアバタｍ１に対応付けられた一般ユーザにより入力可能とされる。所定位置に係る入口付近は、上述の購入入力に関連して上述したとおりである。例えば、図２Ａから図２Ｃに示す例では、位置ＳＰ１は、入口付近に対応する。なお、譲渡入力が入力可能となる、所定位置に係る入口付近と、購入入力が入力可能となる、所定位置に係る入口付近とは、同じであるが、異なってもよい。

あるいは、譲渡入力は、購入入力とともに一般ユーザにより入力可能とされてもよい。これは、例えば親子でチケットを購入する場合、親が、子供への譲渡を予定してチケットを購入する場合が比較的多いためである。

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

第１認証情報描画部１６４２は、上述の譲渡入力に応答して、譲渡用の認証情報に応じた第１認証情報を描画する。具体的には、第１認証情報描画部１６４２は、譲渡対象のチケットに係るチケットＩＤに基づいて、当該チケットＩＤに対応付けられた譲渡用の認証情報（図８参照）を抽出する。そして、第１認証情報描画部１６４２は、抽出した譲渡用の認証情報に応じた第１認証情報を描画する。第１認証情報の描画方法は、譲渡用の認証情報と、描画された第１認証情報とが一対一で対応する限り、任意であるが、好ましくは、第１認証情報は、画像認識が可能な形態で描画される。

本実施形態では、一例として、第１認証情報描画部１６４２は、２次元コードのようなコード情報の形態で、譲渡側のユーザアバタｍ１に対応付けられた位置に、第１認証情報を描画する。例えば、第１認証情報描画部１６４２は、譲渡側のユーザアバタｍ１を含む端末用画像において、当該ユーザアバタｍ１の一部に重畳させる態様で、第１認証情報を描画する。あるいは、第１認証情報描画部１６４２は、譲渡側のユーザアバタｍ１に対応付けて描画される所持物（例えばチケット）に対応付けて第１認証情報を描画してもよい。このようにして描画された第１認証情報は、他の一般ユーザに係る端末装置２０により画像認識されうる。例えば、ある一の端末装置２０に供給される端末用画像に、第１認証情報が含まれる場合、当該一の端末装置２０において、当該第１認証情報が画像認識されうる。この画像認識処理については、図５を参照して後に詳説する。

なお、第１認証情報に係るコード情報は、以下の情報を含む２次元画像コードであってもよい。
・・・（１）認証サーバのＵＲＬ
・・・（２）譲渡側のユーザＩＤ
・・・（３）チケットＩＤ
・・・（４）現在時刻
・・・（５）現在の仮想空間のＵＲＬ
・・・（６）現在の座標
・・・（７）ＰＩＮ（Ｐｅｒｓｏｎａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）
・・・（８）譲受側のユーザＩＤ
この場合、（７）ＰＩＮは、もぎり用の認証情報として利用されてもよい。また、この場合、譲渡側のユーザは、認証サーバのＵＲＬにアクセスし、ＰＩＮコードを入力することで、第２認証判定（後述）を事前に済ますことも可能である。

なお、上述したように、第１認証情報描画部１６４２の機能は、端末装置２０側で実現されてもよい。この場合、例えば、端末装置２０は、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備え、ＧＰＵが第１認証情報に係る画像コードを生成してもよい。

また、第１認証情報に係るコード情報は、ユーザにとって可視である必要はない。従って、例えば、第１認証情報に係るコード情報は、時刻情報を利用して超高速に変動するコードや、解像度が高いコード、色が見えづらいコード、ユーザアバタｍ１が身に着ける服の模様に紛れたコード等を含んでもよい。

第１認証情報受信部１６４３は、端末装置２０からネットワーク３を介して、第１認証情報の画像認識結果を受信する。第１認証情報の画像認識結果は、送信元の端末装置２０に対応付けられたユーザＩＤ等を含んでよい。

チケット情報書換部１６４４は、第１認証情報受信部１６４３が画像認識結果を受信すると、画像認識結果に基づいて、チケット情報の所有者ＩＤを書き換える。具体的には、第１認証情報受信部１６４３が、ある一の一般ユーザに対応付けられた端末装置２０から、画像認識結果を受信すると、チケット情報書換部１６４４は、当該画像認識結果の第１認証情報に基づいて、当該第１認証情報に対応する譲渡用の認証情報を特定する。そして、チケット情報書換部１６４４は、特定した譲渡用の認証情報に係るチケットＩＤに対応付けられた所有者ＩＤとして、画像認識結果に含まれるユーザＩＤを対応付ける。この際、譲渡入力を行ったユーザに係るユーザＩＤは、所有者ＩＤに対応付けられた状態が解消され、当該譲渡の事実が、チケット情報の譲渡情報（図８参照）として追加されてよい。

チケット情報書換部１６４４は、このようにして、画像認識結果に基づいて、一のチケットＩＤに係る所有者ＩＤを変更すると、チケット描画部１６２４に当該変更を反映させる指示を与えてよい。この場合、チケット描画部１６２４は、新たな所有者ＩＤに係るユーザアバタｍ１に対応付けて、チケットを描画する。例えば、一般ユーザは、自身の端末装置２０に表示されるユーザ用の端末用画像において、自身のユーザアバタｍ１にチケットが対応付けて描画されている状態を確認することで、チケットを所持している状態を認識できる。

判断処理部１６６は、チケット情報と、もぎり用の認証情報とに基づいて、ユーザアバタｍ１が所定位置へと移動できるか否かを判定する。

具体的には、判断処理部１６６は、チケット所持判定部１６６１と、第２認証情報受信部１６６２と、第２認証判定部１６６３と、移動可否判定部１６６４とを含む。

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

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

チケット所持判定は、好ましくは、ユーザアバタｍ１の位置情報（図６参照）に基づいて、所定位置に係る入口領域に位置するユーザアバタｍ１に対して実行される。所定位置に係る入口領域は、例えば図２Ａから図２Ｃに示す例では、位置ＳＰ２又はその近傍であってよい。所定位置に係る入口領域は、所定位置への移動を希望するユーザアバタｍ１が位置する領域であり、当該入口領域にユーザアバタｍ１が位置することは、ユーザアバタｍ１の所定位置への移動を希望することの一般ユーザの意思表示であってよい。あるいは、入口領域にユーザアバタｍ１が位置することに加えて、チケットの提示操作等が、ユーザアバタｍ１の所定位置への移動を希望することの一般ユーザの意思表示として扱われてよい。

本実施形態では、チケット所持判定部１６６１は、所定位置に係る入口領域に配置されるスタッフアバタｍ２に係るスタッフユーザからの入力に基づいて、一のユーザアバタｍ１にチケット（当該所定位置に係るチケット）が対応付けられているか否かを判断してもよい。例えば、所定位置に係る入口領域に配置されるスタッフアバタｍ２に係るスタッフユーザは、チケット所持判定の一部を実現し、判定結果をネットワーク３を介してサーバ装置１０に送信してよい。この場合、スタッフユーザからの入力に基づいて、一のユーザアバタｍ１にチケットが対応付けられているか否かを判定できる。

第２認証情報受信部１６６２は、所定位置に係る入口領域に位置するユーザアバタｍ１に対して、もぎり用の認証情報（第２認証情報の一例）の提示（入力）を要求する。なお、もぎり用の認証情報の提示の要求は、ユーザアバタｍ１によるチケットの提示の要求を伴ってもよいし、チケットを提示したユーザアバタｍ１に対してのみ実効されてもよい。例えば、第２認証情報受信部１６６２は、ユーザアバタｍ１の位置情報（図６参照）に基づいて、所定位置に係る入口領域にユーザアバタｍ１を検出した場合、当該ユーザアバタｍ１の一般ユーザに係る端末装置２０に、もぎり用の認証情報の送信を要求する。この場合、ユーザアバタｍ１に係る一般ユーザ用の端末用画像において、スタッフアバタｍ２によりもぎり用の認証情報が要求されるアニメーションを伴ってもよい。かかる要求を受けて、一般ユーザは、もぎり用の認証情報を入力してサーバ装置１０に送信する。このようにして、第２認証情報受信部１６６２は、所定位置に係る入口領域に位置するユーザアバタｍ１から、もぎり用の認証情報を受信（取得）する。

本実施形態では、第２認証情報受信部１６６２は、所定位置に係る入口領域に配置されるスタッフアバタｍ２に係るスタッフユーザからの入力に基づいて、所定位置に係る入口領域に位置するユーザアバタｍ１から、もぎり用の認証情報を受信（取得）してもよい。この場合、スタッフユーザ用の端末用画像には、一般ユーザが入力したもぎり用の認証情報が、入力した一般ユーザに係るユーザアバタｍ１に対応付けて描画されてよい。スタッフユーザは、かかる描画されたもぎり用の認証情報を、対応するユーザアバタｍ１を特定する情報とともに、サーバ装置１０に送信してもよい。

第２認証判定部１６６３は、もぎり用の認証情報に基づく認証が成功したか否かを判定する。このような判定処理を、「第２認証判定」とも称する。このようにして、本実施形態では、判断処理部１６６は、ある一のユーザアバタｍ１が所定位置へと移動できるか否かについて判定する際、チケット所持判定に加えて、第２認証判定を行う。

第２認証判定は、図８に示したチケット情報のもぎり用の認証情報に基づいて実現される。具体的には、第２認証判定は、譲受側の一般ユーザにより入力されるもぎり用の認証情報と、当該一般ユーザのユーザアバタｍ１が所有するチケットに係るもぎり用の認証情報とが一致するか否かを判定することで、実現できる。この場合、これらのもぎり用の認証情報が一致した場合に、もぎり用の認証情報に基づく認証が成功となる。

ここで、もぎり用の認証情報は、上述したように、譲渡側の一般ユーザから譲受側の一般ユーザに、事前に通知される。譲渡側の一般ユーザは、譲受側の一般ユーザにだけわかるような、もぎり用の認証情報を設定したり、譲受側の一般ユーザにだけわかるように、もぎり用の認証情報を通知したりできるので、意図しない他の一般ユーザに、もぎり用の認証情報が知られる可能性は実質的に無い。従って、このようなもぎり用の認証情報を用いることで、第２認証判定の安全性を高めることができる。

本実施形態では、第２認証判定部１６６３は、所定位置に係る入口領域に配置されるスタッフアバタｍ２に係るスタッフユーザからの入力に基づいて、もぎり用の認証情報に基づく認証が成功したか否かを判断してもよい。この場合、例えば、所定位置に係る入口領域に配置されるスタッフアバタｍ２に係るスタッフユーザは、第２認証判定の一部を実現し、判定結果をネットワーク３を介してサーバ装置１０に送信してよい。この際、スタッフユーザは、認証対象のユーザアバタｍ１が所持するチケットに対応付けられているもぎり用の認証情報をサーバ装置１０から取得してよい。この場合、第２認証判定部１６６３は、スタッフユーザからの入力に基づいて、もぎり用の認証情報に基づく認証が成功したか否かを判定できる。

移動可否判定部１６６４は、ある一のユーザアバタｍ１に関して、チケット所持判定部１６６１により、所定位置へと移動できるチケットを所有していると判定され、かつ、第２認証判定部１６６３により、もぎり用の認証情報に基づく認証が成功したと判定された場合、当該一のユーザアバタｍ１が所定位置へと移動を許可する。他方、移動可否判定部１６６４は、ある一のユーザアバタｍ１に関して、チケット所持判定部１６６１により、所定位置へと移動できるチケットを所有していないと判定され、又は、第２認証判定部１６６３により、もぎり用の認証情報に基づく認証が成功していないと判定された場合、当該一のユーザアバタｍ１が所定位置へと移動を禁止する。

移動可否判定部１６６４は、所定位置へと移動を許可したユーザアバタｍ１に対応付けられたチケットをもぎる、もぎり処理を実行する。もぎり処理は、チケットをもぎられるユーザアバタｍ１に係る一般ユーザ用の端末用画像において、スタッフアバタｍ２によりチケットの一部を切り離すアニメーションを伴ってもよい。

本実施形態では、移動可否判定部１６６４は、所定位置に係る入口領域に配置されるスタッフアバタｍ２に係るスタッフユーザからの入力（後述するもぎり入力）に基づいて、もぎり処理を実行してもよい。

移動可否判定部１６６４は、もぎり処理を実行すると、対応するチケットに係るチケットＩＤに対応付けられたもぎり情報（図８参照）を更新するとともに、当該チケットＩＤに対応付けられた有効フラグ（図８参照）を“０”にセットする。なお、有効フラグについては、上述したように、チケットの属性に応じて、異なるタイミングで“０”にセットされてもよい。また、移動可否判定部１６６４は、所定位置に係る入口領域に配置されるスタッフアバタｍ２に係るスタッフユーザからの入力（後述するもぎり入力）に基づいて、もぎり処理を実行した場合、対応するチケットに係るチケットＩＤに対応付けられたもぎり者ＩＤ（図８参照）に、対応するスタッフＩＤ（すなわち、後述するもぎり入力を行ったスタッフユーザに係るスタッフＩＤ）を格納する。

空間情報生成部１６８は、上述した空間状態情報（所定位置に係る空間部分の状態を表す情報）を生成し、空間状態記憶部１４６内のデータを更新する。

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

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

また、所定位置で提供される特定のコンテンツを制作・保守・管理等するスタッフユーザに係るスタッフポイントは、当該特定のコンテンツの提供を受けた一般ユーザの数に応じて増加する態様で更新されてもよい。

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

一般ユーザに係る端末装置２０は、認証画像特定部２５０と、第１認証情報抽出部２５１と、第１認証情報送信部２５２と、入力要求部２５３と、第２認証情報送信部２５４とを含む。

認証画像特定部２５０は、サーバ装置１０から上述のように送信される端末用画像に対して、画像処理を実行し、第１認証情報の画像部（例えば、２次元コードのようなコード情報の形態）を特定する。

なお、認証画像特定部２５０は、端末用画像のフレームごとに、第１認証情報の画像部を特定するための画像処理を実行してもよいし、一般ユーザからの入力に応答する態様で、一定期間内だけ、第１認証情報の画像部を特定するための画像処理を実行してもよい。

第１認証情報抽出部２５１は、第１認証情報の画像部に対して画像認識処理を行うことで、第１認証情報を抽出する。

第１認証情報送信部２５２は、第１認証情報抽出部２５１により抽出された第１認証情報を含む画像認識結果を、ネットワーク３を介してサーバ装置１０に送信する。

入力要求部２５３は、上述したサーバ装置１０の第２認証情報受信部１６６２からの要求、又は、後述するスタッフユーザに係る端末装置２０（第２認証情報要求部２６３）からの要求に応答して、提示するチケットに係るもぎり用の認証情報の入力を要求する。例えば、入力要求部２５３は、表示部２３に、もぎり用の認証情報の入力用画面を出力してもよい。

第２認証情報送信部２５４は、入力要求部２５３による要求に応じて一般ユーザが入力したもぎり用の認証情報を、ネットワーク３を介してサーバ装置１０に送信する。

このようにして、一般ユーザは、端末用画像内の第１認証情報を端末装置２０が画像認識することで、自身のユーザアバタｍ１に、チケットを自動的に対応付けることができる。換言すると、一般ユーザは、譲渡側のユーザアバタｍ１に対応付けて描画される第１認証情報を含む端末用画像を取得することで、自身のユーザアバタｍ１に、チケットを自動的に対応付けることができる。そして、譲受側の一般ユーザは、正当なもぎり用の認証情報を提示することで、自身のユーザアバタｍ１を所定位置へと移動させることができる。

ここで、譲受側の一般ユーザは、自身のユーザアバタｍ１を、譲渡側のユーザアバタｍ１の方に向かせるだけで、譲渡側のユーザアバタｍ１に対応付けて描画される第１認証情報を含む端末用画像を取得できる。このような取得は、譲受側のユーザアバタｍ１と譲渡側のユーザアバタｍ１とが近接した位置で活動していることから、容易に（例えば自然な動きの中で）実現できる。これにより、チケットの譲渡に係る煩雑な作業（入力）が軽減し、利便性を高めることができる。

スタッフユーザに係る端末装置２０は、判定結果取得部２６０と、判定結果送信部２６２と、第２認証情報要求部２６３と、もぎり実行部２６４とを含む。なお、判定結果取得部２６０、第２認証情報要求部２６３及びもぎり実行部２６４は、スタッフユーザが不在時等においては、サーバ装置１０により実現されてよい。

判定結果取得部２６０は、スタッフユーザにより入力されうる各種判定結果を取得する。例えば、所定位置の入口付近に配置されるユーザアバタｍ１に係るスタッフユーザは、入口付近に至る各ユーザアバタｍ１に対して、当該所定位置が対応付けられたチケットを所持しているか否かを判定する。例えば、スタッフユーザは、自身の端末装置２０の表示部２３に表示される端末用画像に基づいて、当該端末用画像内のユーザアバタｍ１の状態等に基づいて、チケットを所持しているか否かを判定してもよい。上述したように、サーバ装置１０の端末画像生成部１５８は、スタッフユーザ用の端末用画像において、チケット情報（図８参照）に基づいて、所有者ＩＤが対応付けられたユーザアバタｍ１と、そうでないユーザアバタｍ１とを異なる態様で描画してもよい。この場合、スタッフユーザは、所有者ＩＤが対応付けられたユーザアバタｍ１と、そうでないユーザアバタｍ１とを見分け、判定結果を入力部２４を介して入力してよい。

判定結果送信部２６２は、判定結果取得部２６０による各種判定結果を、ネットワーク３を介してサーバ装置１０に送信する。

第２認証情報要求部２６３は、スタッフユーザからの要求入力に応答して、スタッフユーザ用の端末用画面に含まれるユーザアバタｍ１に対して、もぎり用の認証情報の入力を要求する。スタッフユーザからの要求入力は、要求対象のユーザアバタｍ１を特定できる情報を含んでよい。例えば、スタッフユーザ用の端末用画面に、複数のユーザアバタｍ１が含まれる場合、スタッフユーザからの要求入力は、複数のユーザアバタｍ１のうちの、要求対象の１つ以上のユーザアバタｍ１を特定できる情報を含んでよい。なお、一般ユーザに対するもぎり用の認証情報の入力の要求は、チケットの提示の要求を伴ってもよい。なお、このような、スタッフユーザに係る端末装置２０と、一般ユーザに係る端末装置２０との間の通信は、サーバ装置１０（例えば上述した第２認証情報受信部１６６２）を介して実現されてもよいし、サーバ装置１０を介さずに実現されてもよい。後者の場合、スタッフユーザは、取得したもぎり用の認証情報を、サーバ装置１０に転送してもよいし、第２認証判定部１６６３の機能を実現した上で判定結果を、サーバ装置１０に送信してもよい。

もぎり実行部２６４は、スタッフユーザにより入力されるもぎり入力を取得し、取得したもぎり入力を、サーバ装置１０に送信する。もぎり入力は、もぎり対象のチケット（又は当該チケットを所持しているユーザアバタｍ１）を特定できる情報を含んでよい。

次に、図１０以降を参照して、上述したチケット譲渡機能に関連した動作例について説明する。なお、以下の動作例は、比較的具体的な動作例であるが、上述したチケット譲渡機能に関連した動作は、上述したように、多様な態様で実現可能である。

図１０は、上述したチケット譲渡機能に関連した動作例を示すタイミングチャートである。図１０では、区別のために、ある一般ユーザに係る端末装置２０に対して、符号「２０－Ａ」を付与し、他の一般ユーザに係る端末装置２０に対して、符号「２０－Ｂ」を付与し、スタッフユーザに係る端末装置２０に対して、符号「２０－Ｃ」を付与している。ここでは、ある一の一般ユーザから、他の一の一般ユーザへのチケットの譲渡について説明するが、一の一般ユーザから、他の複数の一般ユーザへのチケットの譲渡についても同様に適用できる。以下では、説明上、端末装置２０－Ａに係る一般ユーザを、ユーザ名「ａｍｉ」とし、端末装置２０－Ｂに係る一般ユーザを、ユーザ名「ｆｕｊ」とし、両者は親子（例えば、ユーザ名「ａｍｉ」が父で、ユーザ名「ｆｕｊ」が娘）である。また、以下では、ユーザ名「ａｍｉ」に係る一般ユーザを、父ユーザと称し、ユーザ名「ｆｕｊ」に係る一般ユーザを、娘ユーザと称する。

図１１から図１６は、図１０に示す動作例の説明図であり、各場面での端末用画面の一例を示す図である。

ここでは、父ユーザと娘ユーザとが一緒に仮想現実内で特定のコンテンツの提供を受けることを決め、当該特定のコンテンツの提供を受けられる所定位置へとそれぞれのユーザアバタｍ１を移動させるまでの動作を説明する。以下で説明する各ユーザの入力は、自身の端末装置２０の入力部２４を介して実現されるものとする。

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

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

ついで、ステップＳ１４において、父ユーザは、仮想空間内で自身のユーザアバタｍ１をチケット購入領域（位置ＳＰ１）内に移動させ、自身と娘ユーザの二人分のチケットを購入する。すなわち、父ユーザは、自身のユーザアバタｍ１をチケット購入領域内に位置させた状態で、自身と娘ユーザの二人分のチケットを購入するための購入入力を入力又は有効化する。

この場合、ステップＳ１５において、サーバ装置１０は、父ユーザからの購入入力に基づいて、２枚分のチケットＩＤを新たなに発行し、チケット情報記憶部１４４内のデータ（図８参照）を更新する。

ついで、ステップＳ１６において、父ユーザは、購入した２枚のチケットのうちの一枚に対する譲渡入力を行う。

この場合、ステップＳ１７において、サーバ装置１０は、父ユーザからの譲渡入力に基づいて、譲渡するチケットのチケットＩＤに対応付けられた譲渡用の認証情報（図８参照）を抽出する。そして、第１認証情報描画部１６４２は、抽出した譲渡用の認証情報に応じた第１認証情報を、父ユーザのユーザアバタｍ１に対応付けて描画する。図１２は、譲渡入力を行ったときの、娘ユーザ用の端末用画像Ｇ１２０を示す。なお、図１２では、父ユーザの入力に基づくチャットのテキスト「チケット受け取ってね」が示されている。なお、この種のチャットは、譲渡入力に基づいて自動的に生成されてもよい。

図１２に示す例では、父ユーザのユーザアバタｍ１（ユーザ名「ａｍｉ」）には、第１認証情報が描画された画像部Ｇ１２１が対応付けられる。父ユーザは、自身のユーザアバタｍ１を、娘ユーザのユーザアバタｍ１の方に向け、かつ、娘ユーザは、自身のユーザアバタｍ１を、父ユーザのユーザアバタｍ１の方に向けると、図１２に示すような端末用画像Ｇ１２０が生成される。この場合、ステップＳ１８において、娘ユーザの端末装置２０－Ｂは、画像部Ｇ１２１から第１認証情報を画像認識し、第１認証情報の認識結果を、サーバ装置１０に送信する。なお、娘ユーザの端末装置２０－Ｂは、画像部Ｇ１２１から第１認証情報を画像認識した際に、その旨を娘ユーザに通知してもよい。同様に、サーバ装置１０は、娘ユーザの端末装置２０－Ｂから第１認証情報の認識結果を受信すると、譲渡するチケットのチケットＩＤに娘ユーザのユーザアバタｍ１が対応付けられたことを示す情報を、父ユーザの端末装置２０―Ａに送信してもよい。

ついで、ステップＳ１９おいて、父ユーザは、仮想空間内で自身のユーザアバタｍ１を入口領域内に移動させ、ステップＳ２０おいて、娘ユーザは、仮想空間内で自身のユーザアバタｍ１を入口領域内に移動させる。図１３は、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１（ユーザ名「ｆｕｊ」）とが入口領域に位置するときの、スタッフユーザ用の端末用画像Ｇ１３０を示す。端末用画像Ｇ１３０は、入口領域に配置されたスタッフアバタｍ２（スタッフ名「ｓｕｋ」）に係るスタッフユーザの端末装置２０－Ｃに表示される。なお、図１３では、父ユーザの入力に基づくチャットのテキスト「子供と二人でお願いいたします」が示されている。

この場合、ステップＳ２１において、サーバ装置１０は、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１に対して、上述したチケット所持判定を行う。この場合は、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１は、所定位置に移動可能なチケットを所持している。従って、図１３では、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１には、所定位置に移動可能なチケットを所持していることを表す画像部Ｇ１３１、Ｇ１３２が描画されている。このような画像部Ｇ１３１、Ｇ１３２は、スタッフユーザ用の端末用画像にのみ描画される。これにより、スタッフユーザは、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１が、所定位置に移動可能なチケットを所持していることを容易に把握できる。

ついで、ステップＳ２２おいて、スタッフアバタｍ２（スタッフ名「ｓｕｋ」）に係るスタッフユーザは、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１が、所定位置に移動可能なチケットを所持していることを、例えば画像部Ｇ１３１、Ｇ１３２に基づいて、確認した上で、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１に対して、第２認証情報の入力を要求する。図１４は、第２認証情報の入力が要求されたときの、娘ユーザ用の端末用画像Ｇ１４０を示す。なお、第２認証情報の入力が要求されたときの、父ユーザ用の端末用画像は、娘ユーザ用の端末用画像Ｇ１４０と同様であってよい。端末用画像Ｇ１４０は、図１４に示すように、テンキーの画像部Ｇ１４１や、スタッフアバタｍ２（スタッフ名「ｓｕｋ」）に係るスタッフユーザの入力に基づくチャットのテキスト「４桁のコード入力お願いいたします！」を含んでよい。また、テンキーの画像部Ｇ１４１に代えて、認証サーバのＵＲＬが表示されてもよい。

なお、スタッフアバタｍ２へのチケットの提示は、必ずしも必要とされなくてもよい。提示されない場合でも、スタッフ用の端末用画面では、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１とに紐付けられたチケットの有効性に関する情報が表示されることで、スタッフユーザは各チケットの有効性を判断できる。

ついで、ステップＳ２３おいて、父ユーザは、自身のチケットに対応付けた第２認証情報の入力を行い、ステップＳ２４おいて、娘ユーザは、父ユーザから知らされている第２認証情報の入力を行う。

この場合、ステップＳ２５において、サーバ装置１０は、父ユーザ及び娘ユーザのそれぞれからの第２認証情報の入力に基づいて、父ユーザ及び娘ユーザのそれぞれのユーザアバタｍ１に対応付けられるチケットに対して、上述した第２認証判定を行う。この場合は、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１は、それぞれ正当な第２認証情報を入力できるので、上述した第２認証判定の結果は認証成功となる。図１５は、第２認証判定後におけるスタッフアバタｍ２（スタッフ名「ｓｕｋ」）に係るスタッフユーザ用の端末用画像Ｇ１５０を示す。図１５では、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１には、所定位置に移動可能なチケットを所持しておりかつ第２認証判定の結果が認証成功であることを表す画像部Ｇ１５１、Ｇ１５２が描画されている。このような画像部Ｇ１５１、Ｇ１５２は、スタッフユーザ用の端末用画像にのみ描画される。これにより、スタッフユーザは、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１のそれぞれに係る第２認証判定の結果が認証成功であることを容易に把握できる。なお、画像部Ｇ１５１、Ｇ１５２は、所定位置に移動後も、スタッフユーザ用の端末用画像に描画されてもよい。これにより、所定位置に位置するスタッフユーザは、有効なチケットに基づいて入室しているユーザアバタｍ１と、そうでないユーザアバタｍ１とを容易に区別できる。

そして、ステップＳ２６おいて、スタッフアバタｍ２（スタッフ名「ｓｕｋ」）に係るスタッフユーザは、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１のそれぞれが、所定位置に移動可能なチケットを所持しておりかつ第２認証判定の結果が認証成功であることを、例えば画像部Ｇ１５１、Ｇ１５２に基づいて、確認した上で、もぎり入力を行う。

この場合、ステップＳ２７において、サーバ装置１０は、スタッフユーザによるもぎり入力に基づいて、父ユーザのユーザアバタｍ１と娘ユーザのユーザアバタｍ１のそれぞれが所持しているチケットに対して、上述したもぎり処理を実行する。図１６は、上述したもぎり処理の際の、娘ユーザ用の端末用画像Ｇ１６０を示す。なお、もぎり処理の際の、父ユーザ用の端末用画像は、娘ユーザ用の端末用画像Ｇ１６０と同様であってよい。端末用画像Ｇ１６０は、図１６に示すように、スタッフアバタｍ２（スタッフ名「ｓｕｋ」）の手によりチケットの一部を切り離すアニメーションを伴ってもよい。もぎり処理が実行されると、スタッフユーザ用の端末用画像における画像部Ｇ１５１、Ｇ１５２は、消去されてもよいし、別の画像部（例えばチケットがもぎられた状態であることを示す画像部）に置換されてもよい。

ついで、ステップＳ２８おいて、父ユーザは、チケットがもぎられたことを確認した上で、自身のユーザアバタｍ１を仮想空間内の所定位置へと移動させ、ステップＳ２９おいて、娘ユーザは、チケットがもぎられたことを確認した上で、自身のユーザアバタｍ１を仮想空間内の所定位置へと移動させる。なお、所定位置への移動は、端末用画像等に表示される特定のＵＲＬにアクセスすることで実現されてもよい。あるいは、所定位置への移動は、上述したもぎり処理に後続（連動）して自動的に特定のＵＲＬにアクセスさせられることで、実現されてもよい。これにより、父ユーザ及び娘ユーザは、仮想空間内の所定位置で、一緒に特定のコンテンツの提供を受けて楽しむことができる。なお、特定のコンテンツの属性に応じて、仮想空間内の所定位置には、他の一般ユーザも同時に特定のコンテンツの提供を受けることができてもよい。この場合、父ユーザ及び娘ユーザは、他の一般ユーザとも交流しながら、特定のコンテンツを楽しむこともできる。

このようにして、本実施形態によれば、複数のユーザが、所定位置で特定のコンテンツの提供を受けようとするとき、一部のユーザが、所定位置への移動を可能とするチケットを、他のユーザの分まで購入し譲渡できる仕組みを、簡易かつ安全な態様で成立させることができる。

特に、本実施形態によれば、譲渡に際して、譲渡側の一般ユーザも、譲受側の一般ユーザも、ユーザログイン等の特別な作業を要求されないので、利便性が向上する。

ところで、本実施形態では、上述した第１認証情報は、上述したように、端末装置２０により画像認識可能であるため、譲渡側の一般ユーザが意図する一般ユーザ以外の一般ユーザに係る端末装置２０によっても、画像認識される可能性がある。しかしながら、このような意図しない一般ユーザは、第２認証情報を知り得ないので、第２認証判定を突破できない。すなわち、譲渡側の一般ユーザに係るユーザアバタｍ１の周辺の意図しない一般ユーザのユーザアバタｍ１にチケットが利用されてしまう可能性を低減できる。このようにして、本実施形態によれば、簡易な譲渡を実現しつつ、譲渡の安全性を確保できる。

また、本実施形態によれば、チケット購入から譲渡、及び所定位置への移動まで、同じ仮想空間内で実現できるので、一般ユーザは、現実に、より近い形で仮想現実を体験できる。また、上述のような、もぎり処理等を介して、一般ユーザは、現実に、より近い形で仮想現実を体験できる。
また、本実施形態によれば、家族や友人などの実際の関係によって紐づけられるユーザ間の個人情報を仮想現実生成システム１側が取得せずに、チケットの共有や譲渡を行うことができる。また、仮想空間内での２段階認証（第１認証情報による認証と第２認証情報による認証）を実現できる。また、認証に失敗した場合に（旧来のパスワードや暗号鍵と異なり）、ユーザ間の理解がしやすく、スタッフなど人間による対応も含めて、複数の柔軟な解決方法を導きやすいという利点がある。

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

例えば、上述した実施形態では、スタッフアバタｍ２は、スタッフユーザ（人間）により操作されているが、Ｂｏｔ（ボット）プログラムのようなプログラムに基づき動作されてもよい。

１ 仮想現実生成システム
１０ サーバ装置
１１ サーバ通信部
１２ サーバ記憶部
１３ サーバ制御部
２０ 端末装置
１４０ ユーザデータベース
１４２ アバタデータベース
１４４ チケット情報記憶部
１４６ 空間状態記憶部
１５０ 空間描画処理部
１５２ ユーザアバタ処理部
１５２１ 操作入力取得部
１５２２ ユーザ動作処理部
１５４ スタッフアバタ処理部
１５４１ 操作入力取得部
１５４２ スタッフ動作処理部
１５６ 位置／向き情報特定部
１５８ 端末画像生成部
１５９ コンテンツ処理部
１６０ 対話処理部
１６２ 第１移動権限処理部
１６２１ 購入入力取得部
１６２２ チケットＩＤ生成部
１６２３ 認証情報通知部
１６２４ チケット描画部
１６４ 第２移動権限処理部
１６４０ 譲渡入力取得部
１６４１ 認証通知案内部
１６４２ 第１認証情報描画部
１６４３ 第１認証情報受信部
１６４４ チケット情報書換部
１６６ 判断処理部
１６６１ チケット所持判定部
１６６２ 第２認証情報受信部
１６６３ 第２認証判定部
１６６４ 移動可否判定部
１６８ 空間情報生成部
１７０ パラメータ更新部
２５０ 認証画像特定部
２５１ 第１認証情報抽出部
２５２ 第１認証情報送信部
２５３ 入力要求部
２５４ 第２認証情報送信部
２６０ 判定結果取得部
２６２ 判定結果送信部
２６３ 第２認証情報要求部
２６４ もぎり実行部

Claims (19)

1. 仮想空間を描画する空間描画処理部と、
   前記仮想空間内で移動可能な各移動媒体であって、各ユーザに対応付けられる各移動媒体を描画する媒体描画処理部と、
   第１ユーザからの第１入力に基づいて、前記第１ユーザに対応付けられた第１移動媒体に所定の移動権限情報を対応付ける第１移動権限処理部と、
   前記第１ユーザからの第２入力に基づいて、前記第１移動権限処理部によって前記第１移動媒体に対応付けられた前記所定の移動権限情報を、前記第１ユーザとは異なる第２ユーザに対応付けられた第２移動媒体へと対応付け替える第２移動権限処理部と、
   一の移動媒体に前記所定の移動権限情報が対応付けられているか否かに基づいて、前記仮想空間内の所定位置への前記一の移動媒体の移動の可否を判断する判断処理部とを含み、
   前記第２移動権限処理部は、認証情報描画部を備え、
   前記認証情報描画部は、前記第１ユーザからの第２入力に基づいて、画像認識可能な第１認証情報を生成し、生成した前記第１認証情報を前記第１移動媒体に対応付けて前記仮想空間内に描画する、情報処理システム。
2. 仮想空間を描画する空間描画処理部と、
   前記仮想空間内で移動可能な各移動媒体であって、各ユーザに対応付けられる各移動媒体を描画する媒体描画処理部と、
   第１ユーザからの第１入力に基づいて、前記第１ユーザに対応付けられた第１移動媒体に所定の移動権限情報を対応付ける第１移動権限処理部と、
   前記第１ユーザからの第２入力に基づいて、前記第１移動権限処理部によって前記第１移動媒体に対応付けられた前記所定の移動権限情報を、前記第１ユーザとは異なる第２ユーザに対応付けられた第２移動媒体へと対応付け替える第２移動権限処理部と、
   一の移動媒体に前記所定の移動権限情報が対応付けられているか否かに基づいて、前記仮想空間内の所定位置への前記一の移動媒体の移動の可否を判断する判断処理部とを含み、
   前記媒体描画処理部は、更に、前記所定位置への入口に配置される所定媒体を描画し、
   前記判断処理部は、前記所定媒体に対応付けられた第３ユーザからの入力に基づいて、前記一の移動媒体に前記所定の移動権限情報が対応付けられているか否かを判断する、情報処理システム。
3. 前記第２移動権限処理部は、認証情報描画部を備え、
   前記認証情報描画部は、前記第１ユーザからの第２入力に基づいて、画像認識可能な第１認証情報を生成し、生成した前記第１認証情報を前記第１移動媒体に対応付けて前記仮想空間内に描画する、請求項２に記載の情報処理システム。
4. 前記媒体描画処理部は、前記仮想空間内における前記移動媒体のそれぞれの位置に基づいて、前記移動媒体のそれぞれに対応付けられた視野内の前記仮想空間の部分の画像を生成し、生成した画像を、前記移動媒体のそれぞれに対応付けられたユーザ端末に送信し、
   前記第２移動権限処理部は、前記画像を表示する一のユーザ端末から、該画像に対する画像処理により前記第１認証情報を認識したことを表す情報を、受信した場合に、前記一のユーザ端末に対応付けられた移動媒体に、前記所定の移動権限情報を対応付け替える、請求項１又は３に記載の情報処理システム。
5. 前記認証情報描画部は、前記第１認証情報を、前記第１移動媒体に対応付けられた位置に描画する、請求項４に記載の情報処理システム。
6. 前記判断処理部は、一の移動媒体に前記所定の移動権限情報が対応付けられており、かつ、前記第１認証情報とは異なる第２認証情報に基づく認証が成立した場合に、前記所定位置への前記一の移動媒体の移動を許可する、請求項１、３～５のうちのいずれか１項に記載の情報処理システム。
7. 前記第２認証情報は、前記第２ユーザからの入力に含まれる、請求項６に記載の情報処理システム。
8. 前記媒体描画処理部は、更に、前記所定位置への入口に配置される所定媒体を描画し、
   前記判断処理部は、前記所定媒体に対応付けられた第３ユーザからの入力に基づいて、前記一の移動媒体に前記所定の移動権限情報が対応付けられているか否かを判断する、請求項１に記載の情報処理システム。
9. 前記判断処理部は、前記第３ユーザが前記一の移動媒体に前記所定の移動権限情報が対応付けられていると判定したことを表す情報を前記第３ユーザから受信した場合に、前記一の移動媒体に前記所定の移動権限情報が対応付けられていると判定する、請求項８に記載の情報処理システム。
10. 前記媒体描画処理部は、前記一の移動媒体に前記所定の移動権限情報が対応付けられているか否かに応じて、前記一の移動媒体を異なる態様で描画する、請求項８又は９に記載の情報処理システム。
11. 前記第３ユーザからの入力と、前記一の移動媒体に対応付けられたユーザからの入力とに基づいて、通信ネットワークを介した両ユーザ間の対話を可能とする対話処理部を更に備える、請求項８～１０のうちのいずれか１項に記載の情報処理システム。
12. 前記第３ユーザからの前記入力に基づき前記一の移動媒体に提供されるサービス又は商品であって、前記仮想空間内でのサービス又は商品に基づいて、前記第３ユーザに対応付けられたパラメータの値を更新するパラメータ更新部を更に含む、請求項８～１１のうちのいずれか１項に記載の情報処理システム。
13. 前記所定位置に位置する移動媒体に対応付けられたユーザは、所定サービス又は所定商品の提供を受けることができ、
    前記第１入力は、金銭又は金銭的価値を有する媒体の消費を伴う、請求項１～１２のうちのいずれか１項に記載の情報処理システム。
14. 前記第１入力は、前記所定位置に係る入口付近に前記第１移動媒体が位置する場合に、入力可能とされ又は有効化され、
    前記第２入力は、前記所定位置に係る入口付近に前記第１移動媒体が位置する場合に、入力可能とされ又は有効化される、請求項１～１３のうちのいずれか１項に記載の情報処理システム。
15. 前記所定の移動権限情報は、前記所定位置への前記一の移動媒体の移動が実現された場合に、無効化される、請求項１～１４のうちのいずれか１項に記載の情報処理システム。
16. 仮想空間を描画し、
    前記仮想空間内で移動可能な移動媒体であって、ユーザに対応付けられる移動媒体を描画し、
    第１ユーザからの第１入力に基づいて、前記第１ユーザに対応付けられた第１移動媒体に所定の移動権限情報を対応付け、
    前記第１ユーザからの第２入力に基づいて、前記第１移動媒体に対応付けられた前記所定の移動権限情報を、前記第１ユーザとは異なる第２ユーザに対応付けられた第２移動媒体へと対応付け替え、
    一の移動媒体に前記所定の移動権限情報が対応付けられているか否かに基づいて、前記仮想空間内の所定位置への前記一の移動媒体の移動の可否を判断し、
    前記第１ユーザからの第２入力に基づいて、画像認識可能な第１認証情報を生成し、生成した前記第１認証情報を前記第１移動媒体に対応付けて前記仮想空間内に描画することを含む、コンピュータにより実行される情報処理方法。
17. 仮想空間を描画し、
    前記仮想空間内で移動可能な移動媒体であって、ユーザに対応付けられる移動媒体を描画し、
    第１ユーザからの第１入力に基づいて、前記第１ユーザに対応付けられた第１移動媒体に所定の移動権限情報を対応付け、
    前記第１ユーザからの第２入力に基づいて、前記第１移動媒体に対応付けられた前記所定の移動権限情報を、前記第１ユーザとは異なる第２ユーザに対応付けられた第２移動媒体へと対応付け替え、
    一の移動媒体に前記所定の移動権限情報が対応付けられているか否かに基づいて、前記仮想空間内の所定位置への前記一の移動媒体の移動の可否を判断し、
    前記第１ユーザからの第２入力に基づいて、画像認識可能な第１認証情報を生成し、生成した前記第１認証情報を前記第１移動媒体に対応付けて前記仮想空間内に描画する
    処理をコンピュータに実行させる情報処理プログラム。
18. 仮想空間を描画し、
    前記仮想空間内で移動可能な移動媒体であって、ユーザに対応付けられる移動媒体を描画し、
    第１ユーザからの第１入力に基づいて、前記第１ユーザに対応付けられた第１移動媒体に所定の移動権限情報を対応付け、
    前記第１ユーザからの第２入力に基づいて、前記第１移動媒体に対応付けられた前記所定の移動権限情報を、前記第１ユーザとは異なる第２ユーザに対応付けられた第２移動媒体へと対応付け替え、
    一の移動媒体に前記所定の移動権限情報が対応付けられているか否かに基づいて、前記仮想空間内の所定位置への前記一の移動媒体の移動の可否を判断し、
    更に、前記所定位置への入口に配置される所定媒体を描画し、
    前記所定媒体に対応付けられた第３ユーザからの入力に基づいて、前記一の移動媒体に前記所定の移動権限情報が対応付けられているか否かを判断することを含む、コンピュータにより実行される情報処理方法。
19. 仮想空間を描画し、
    前記仮想空間内で移動可能な移動媒体であって、ユーザに対応付けられる移動媒体を描画し、
    第１ユーザからの第１入力に基づいて、前記第１ユーザに対応付けられた第１移動媒体に所定の移動権限情報を対応付け、
    前記第１ユーザからの第２入力に基づいて、前記第１移動媒体に対応付けられた前記所定の移動権限情報を、前記第１ユーザとは異なる第２ユーザに対応付けられた第２移動媒体へと対応付け替え、
    一の移動媒体に前記所定の移動権限情報が対応付けられているか否かに基づいて、前記仮想空間内の所定位置への前記一の移動媒体の移動の可否を判断し、
    更に、前記所定位置への入口に配置される所定媒体を描画し、
    前記所定媒体に対応付けられた第３ユーザからの入力に基づいて、前記一の移動媒体に前記所定の移動権限情報が対応付けられているか否かを判断する
    処理をコンピュータに実行させる情報処理プログラム。

Images