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

Description

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

仮想空間内におけるアバター間の位置関係を制御する技術が知られている。

特開２０２１－０６８２６９号公報

しかしながら、上記のような従来技術では、仮想空間内におけるアバターの移動を適切に支援することが難しい。

そこで、１つの側面では、本開示は、仮想空間内におけるアバターの移動を適切に支援することを目的とする。

１つの側面では、仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成する特定オブジェクト生成部と、
前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は特定の行き先の属性、のうちの少なくともいずれか一方の情報を対応付ける対応付け処理部とを含む、情報処理システムが提供される。

１つの側面では、本開示によれば、仮想空間内におけるアバターの移動を適切に支援することが可能となる。

本実施形態に係る仮想現実生成システムのブロック図である。 ヘッドマウントディスプレイを介して視認可能な端末用画像の説明図である。 ジェスチャによる操作入力の説明図である。 仮想現実生成システムにより生成可能な仮想空間の一例の説明図である。 本実施形態において設定可能なポータルの属性の一例を示す表図である。 ポータルの利用条件の一例を示す説明図である。 ポータルを介して移動中の状態を模式的に示す図である 各アバターに対応付けられている第１エージェントアバターによる案内処理の一例の説明図である。 各アバターに対応付けられている第１エージェントアバターによる案内処理の一例の説明図である。 位置又は領域に紐付けられている第２エージェントアバターの説明図である。 特定のポータルを利用するために待機している複数のアバターの様子を示す説明図である。 ポータル機能に関連したサーバ装置の機能ブロック図の一例である。 ポータル情報記憶部内のデータの説明図である。 ユーザ情報記憶部内のデータの説明図である。 エージェント情報記憶部内のデータの説明図である。 アバター情報記憶部内のデータの説明図である。 利用状況／履歴記憶部内のデータの説明図である。 ポータル関連処理部によるポータルの生成処理に関連した動作例を示す概略フローチャートである。 案内設定部による案内処理に関連した動作例を示す概略フローチャートである。 移動処理部による処理に関連した動作例を示す概略フローチャートである。 移動処理部による思い出録画処理に関連した動作例を示す概略フローチャートである。

以下、添付図面を参照しながら各実施形態について詳細に説明する。なお、添付図面では、見易さのために、複数存在する同一属性の部位には、一部しか参照符号が付されていない場合がある。

図１を参照して、一実施形態に係る仮想現実生成システム１の概要について説明する。図１は、本実施形態に係る仮想現実生成システム１のブロック図である。図２は、ヘッドマウントディスプレイを介して視認可能な端末用画像の説明図である。

仮想現実生成システム１は、サーバ装置１０と、１つ以上の端末装置２０と、を備える。図１では簡便のため、３つの端末装置２０を図示しているが、端末装置２０の数は２つ以上であればよい。

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

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

各端末装置２０は、サーバ装置１０を介して互いに通信可能に接続されている。なお、以下では、「一の端末装置２０が情報を他の端末装置２０に送信する」とは、「一の端末装置２０が情報をサーバ装置１０を介して他の端末装置２０に送信する」ことを意味する。同様に、「一の端末装置２０が情報を他の端末装置２０から受信する」とは、「一の端末装置２０が情報をサーバ装置１０を介して他の端末装置２０から受信する」ことを意味する。ただし、変形例では、各端末装置２０は、サーバ装置１０を介さずに通信可能に接続されてもよい。

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

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

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

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

なお、アバターは、典型的には、正面方向を有するキャラクタの形態であり、人や動物又はその類の形態を有してよい。アバターは、各種アバターアイテムに対応付けられることで、多様な容姿（描画されたときの容姿）を有することができる。また、以下では、アバターの性質上、ユーザとアバターとは同一視して説明する場合がある。従って、例えば、「一のアバターが〇〇する」は、「一のユーザが〇〇する」と同義である場合がある。

ユーザは、頭部又は顔の一部に装着型装置を装着し、当該装着型装置を介して仮想空間を視認してよい。なお、装着型装置は、ヘッドマウントディスプレイやメガネ型装置であってもよい。メガネ型装置は、いわゆるＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）グラスやＭＲ（Ｍｉｘｅｄ Ｒｅａｌｉｔｙ）グラスであってよい。いずれの場合でも、装着型装置は、端末装置２０とは別であってもよいし、端末装置２０の一部又は全部の機能を実現してもよい。端末装置２０は、ヘッドマウントディスプレイにより実現されてよい。

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

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

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

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

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

サーバ制御部１３（以下の端末制御部２５も同様）は、コンピュータプログラム（ソフトウェア）に従って動作する１又は複数のプロセッサ、各種処理のうち少なくとも一部の処理を実行する１又は複数の専用のハードウェア回路、或いはそれらの組み合わせ、を含む回路（ｃｉｒｃｕｉｔｒｙ）として構成し得る。

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

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

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

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

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

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

また、端末記憶部２２は、例えば各種のギフトオブジェクト、建物、壁、又はＮＰＣ（Ｎｏｎ Ｐｌａｙｅｒ Ｃｈａｒａｃｔｅｒ）等のような、アバターとは異なる各種のオブジェクト（仮想現実媒体）に係る描画情報を記憶する。仮想空間内の各種のオブジェクトは、かかる描画情報に基づいて描画される。なお、ギフトオブジェクトとは、一のユーザから他のユーザへのギフト（贈り物）に対応するオブジェクトであり、アイテムの一部である。ギフトオブジェクトは、アバターの身に着けるもの（服やアクセサリー）や装飾するもの（花火やお花等）、背景（壁紙）又はその類や、ガチャ（抽選）を回すことのできるチケット又はその類であってよい。なお、本件出願において用いられる「ギフト」という用語は、「トークン（ｔｏｋｅｎ）」という用語と同様の概念を意味する。したがって、「ギフト」という用語を「トークン（ｔｏｋｅｎ）」という用語に置き換えて、本件出願に記載された技術を理解することも可能である。

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

入力部２４は、物理キーを含んでもよいし、マウス等のようなポインティングデバイスをはじめとする任意の入力インターフェースを更に含んでもよい。また、入力部２４は、音声入力やジェスチャ入力、視線入力のような、非接触型のユーザ入力を受付可能であってもよい。なお、ジェスチャ入力には、ユーザの各種状態を検出するためのセンサ（画像センサや、加速度センサ、距離センサ等）や、センサ技術やカメラを統合した専用モーションキャプチャー、ジョイパッドのようなコントローラ等が利用されてもよい。また、視線検出用のカメラは、ヘッドマウントディスプレイ内に配置されてもよい。なお、上述したように、ユーザの各種状態は、例えばユーザの向きや位置、動き又はその類であり、この場合、ユーザの向きや位置、動きとは、ユーザの顔や手等の身体の一部や全部の向き、位置、動きのみならず、ユーザの視線の向き、位置、動き又はその類を含む概念である。

なお、ジェスチャによる操作入力は、仮想カメラの視点の変更に利用されてもよい。例えば、図３に模式的に示すように、ユーザが、端末装置２０を手で持ちながら、端末装置２０の向きを変化させると、その方向に応じて、仮想カメラの視点が変化されてもよい。この場合、スマートフォンのような比較的小さい画面の端末装置２０を利用する場合でも、ヘッドマウントディスプレイを介して周囲を見渡せるのと同様の態様で視認領域の広さを確保できる。

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

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

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

端末制御部２５は、仮想空間（画像）とともにアバター等を描画し、端末用画像を表示部２３に表示させる。この場合、例えば、図２に示すように、左右の目でそれぞれ視認される画像Ｇ２００、Ｇ２０１を生成することで、ヘッドマウントディスプレイ用の立体視画像を生成してよい。図２には、左右の目でそれぞれ視認される画像Ｇ２００、Ｇ２０１が模式的に示されている。なお、以下では、特に言及しない限り、仮想空間の画像とは、画像Ｇ２００、Ｇ２０１で表現される画像全体を指す。また、端末制御部２５は、例えばユーザによる各種操作に応じて、仮想空間内においてアバターの各種動き等を実現させる。

なお、以下で説明する仮想空間は、ヘッドマウントディスプレイ又はその類を利用して視認可能な没入型の空間であってユーザがアバターを介して自由に（現実と同様に）動き回ることができる連続性のある３次元的な空間のみならず、図３を参照して上述したようなスマートフォン又はその類を利用して視認可能な非没入型の空間をも含む概念である。なお、スマートフォン又はその類を利用して視認可能な非没入型の空間は、アバターを介して自由に動き回ることができる連続性のある３次元的な空間であってもよいし、２次元的な不連続な空間であってもよい。以下、区別するときは、ユーザがアバターを介して自由に動き回ることができる連続性のある３次元的な空間を、「メタバース空間」とも称する。

また、以下の説明において登場する各種モノや施設（例えば映画館等）は、特に言及しない限り、仮想空間におけるオブジェクトであり、実物とは異なる。また、以下の説明における各種イベントは、仮想空間における各種イベント（例えば、映画の上映等）であり、現実でのイベントとは異なる。

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

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

図４に示す例では、仮想空間は、複数の空間部７０と、フリー空間部７１とを備えている。フリー空間部７１では、アバターは、基本的に自由に移動できる。この場合、各空間部７０は、ワールドと称されるローカル区分であってよく、仮想空間全体がグローバルな空間であってよい。複数の空間部７０の一部又は全部は、一のプラットフォーマーにより構築される仮想空間の一部であってよいし、異なる複数のプラットフォーマーにより構築される仮想空間自体であってもよい。

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

空間部７０は、フリー空間部７１に対して少なくとも一部が壁体（後述する所定オブジェクトの例）や移動禁止部（後述する所定オブジェクトの例）により隔てられた空間部であってよい。例えば、空間部７０は、フリー空間部７１に対してアバターが出入りできる出入口（例えば、穴や、ドア等の所定オブジェクト）を有してよい。なお、図４では、空間部７０及びフリー空間部７１を２次元平面として描画しているが、空間部７０及びフリー空間部７１は３次元空間として設定されてもよい。例えば、空間部７０及びフリー空間部７１は、図４に示す平面形状を床として対応する範囲に壁や天井を有する空間でもよい。また、図４に示す例とは別に、ドーム型や球状などの高さを有する空間や、ビルなどの建造物、地球上の特定の場所のほか、アバターが飛び回れる宇宙空間などを模したワールドとしてもよい。

複数の空間部７０は、コンテンツ提供用の空間部を含んでよい。なお、フリー空間部７１においても、適宜、コンテンツ（例えば空間部７０で提供されるような後述する各種コンテンツ）が提供されてもよい。

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

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

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

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

ところで、メタバース空間においては、多くのアバターが自由に動き回ることができるが、比較的遠い場所など、通常の移動方法では移動時間がかかる移動先の場合は、当該移動先へのアバターの移動を適切に支援することが有用である。

そこで、本実施形態では、仮想空間において、特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトとしてポータルが生成される。

本実施形態では、ポータルは、移動先と移動元にそれぞれ設定されてもよい。この場合、２つのポータル間を直接的に行き来する態様でアバターが移動できる。なお、２つのポータルに係る２つの領域間を直接的に行き来する際に要する時間は、当該２つの領域間の距離を移動操作入力に基づきアバターを移動させる場合の時間よりも有意に短くてよい。これにより、ユーザは、ポータルを利用して、効率的な移動を実現できる。なお、変形例では、ポータルは、双方向の移動を可能とするタイプだけでなく、一方向の移動だけを可能とするタイプを含んでもよい。なお、ポータルは、後述するように、複数種類の属性を有する態様で、仮想空間において多様な態様で複数設定されてよい。

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

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

ここで、物理的な同一空間であっても、ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）として重畳したＣＧ（Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ）内のポータル（例えば鏡等の形態のポータル）を仕切り壁として設置し、ポータルに、メタバース内のイベントや空間を接合する役割を持たせてもよい。この場合、アバターが当該ポータルと接触又は通過することで、メタバース内のイベントや空間に入ることが可能とされてよい。

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

図５は、本実施形態において設定可能なポータルの属性の一例を示す表図である。

本実施形態では、ポータルの属性は、特性又は権限の要素を含み、具体的には、図５に示すように、消費型や、可搬性、格納可能性、複製権、譲渡権等を含んでよい。

この場合、各ポータルは、消費型に係る設定状態として、アバターによる利用に伴う消費の可否の設定状態が対応付けられてよい。例えば、消費が“有限”に設定されているポータルは、利用されると消失（消費）されてよい。この場合、消費が“有限”に設定されているポータルには、消費条件が対応付けられてもよい。

また、各ポータルは、可搬性に係る設定状態として、アバターによる持ち運び可否の設定状態とが対応付けられてよい。例えば、アバターによる持ち運びが“可（○）”に設定されているポータルは、対応付けられるアバターによる持ち運び（仮想空間内での移動）が可能とされてよい。なお、可搬性に係る設定状態に代えて又は加えて、仮想空間に固定されているか否かの設定状態が対応付けられてもよい。この場合、例えば、“固定”に設定されているポータルは、特定のアバター（例えば当該ポータルの設置者のアバターや運営者のアバター等）による移動以外の通常的な移動（仮想空間内での移動）が不能とされてよい。

また、各ポータルは、格納可能性に係る設定状態として、アバターの衣装のポケット又はアバターの内部に格納されているか否かの設定状態が対応付けられてよい。例えば、格納可能性が“可能（○）”に設定されているポータルは、対応付けられるアバターのポケット等内への収納（例えば縮小して収納）が可能とされてよい。この場合、比較的大型のポータルであっても、仮想空間内の移動（可搬性による移動）が容易となる。また、格納されている間はポータルの描画が不要となり、処理負荷を低減できる。

また、各ポータルは、複製権に係る設定状態として、複製の可否の設定状態が対応付けられてよい。例えば、複製権が“可（○）”に設定されているポータルは、一定の条件下で複製（コピー）が可能とされてよい。この場合、同様のポータルを仮想空間内に複数設置することが容易となる。

また、各ポータルは、譲渡権に係る設定状態として、譲渡の可否の設定状態が対応付けられてよい。例えば、譲渡権が“可（○）”に設定されているポータルは、一定の条件下で他のアバターへの譲渡が可能とされてよい。この場合、ポータルを取引対象として資産性を持たせることも可能となる。

本実施形態では、ポータルの属性は、形態として型の要素を含み、具体的には、図５に示すように、チケット型、ポスター型、フライヤー型、エレベーター型、トンネル型、ランダム型等を含んでよい。なお、フライヤー型とは、典型的には、チラシの形態である。なお、ここでは、いくつかの型を例示しているが、ポータルは、その存在がアバター（ユーザ）により視認可能であれば、その形態は任意である。

この場合、形態として型と、上述した特性又は権限の要素に係る設定状態との関係は、型の形態に係る現実の特性に応じて、図５に示すように、あらかじめ対応付けられていてもよい。例えば、図５に示す例では、チケット型の場合、現実のチケットと同様に、消費可能であり、可搬性があり、格納が可能であり、複製は不可であり、譲渡が可能である。なお、図５において、“△（有料）”とは、有料を条件として“○（可能）”となることを意味する。

本実施形態では、各ポータルの利用条件は、好ましくは、ポータルごとに異なりうる。この場合、上述したようなポータルの属性の多様化に対応した利用条件の設定が可能となる。

ポータルの利用条件は、ポータルを利用（通過）するために満たされるべき条件である。一のポータルの利用条件は、特定のアバター（例えば当該ポータルの設置者のアバターや運営者のアバター等）により自由に設定可能とされてもよい。これにより、ポータルの更なる多様化とともに、特定のアバターにとっては、ポータルの利用容易性を調整することが容易となり、利便性が向上する。

本実施形態では、同時に複数人のアバターが利用するポータルが設定される。換言すると、１人のアバターだけでは利用できないポータルが設定される。かかる属性のポータルの利用条件は、好ましくは、同時に移動可能なアバターの人数に関する条件を含む。人数に関する上限は、上限人数や下限人数により規定されてもよい。以下では、同時に複数人のアバターでしか利用できない種別のポータルを、「複数アバター通過型のポータル」とも称する。

例えば、ある一のエレベーター型のポータルの場合、当該一のエレベーター型のポータルを利用するための条件は、所定数のアバターが集まることで満たされてよい。所定数は、一定数であってもよいが、動的に可変されてもよい。図６は、ポータルの利用条件の一例を示す説明図である。図６に示す例では、４人のアバターＡ１からＡ４が手をつないでいる。このように、あるポータルの利用条件は、当該ポータルの近傍（すなわち当該ポータルに対応付けられている位置又は領域）で、所定数以上のアバターが手をつなぐことで満たされてよい。

このような複数アバター通過型のポータルの場合のように、ポータルの利用条件として、同時に移動可能なアバターの人数に関する条件を含む場合は、例えば仲間同士で一緒にポータルを介した移動を実現できるので、その移動中の過程も楽しむことが可能である。また、移動先での楽しみの期待感を高めることが可能となる。例えば、図７は、ポータルを介して移動中の状態を模式的に示す図である。図７では、ポータルを介しての移動は、ブラックホールのようなホールに吸い込まれるイメージで実現されているが、乗り物に乗って移動するイメージ等で実現されてもよい。また、ポータルがエレベーター型などのような乗り物に関連する場合、ポータル自体が動く様子（例えば、ポータルが車やバスの形態である場合、車窓からの周りの風景が変化する様子）が描画されてもよい。

また、ポータルを介した移動中、移動しているアバターに、所定動画を出力してもよい。所定動画は、背景や乗り物の表示部等に出力されてもよい。この場合、所定動画は、移動中のアバターに対応付けられているアバター情報又はユーザ情報に基づいて生成されてもよい。例えば、所定動画は、移動中の各アバターのアバター情報又はユーザ情報に基づいて、共通の思い出などを想起させる動画を含んでもよい。

ここで、本明細書において、各種の動画は、当該動画を生成するためのモーションデータ（例えば動画に含まれうるアバター等の移動体の動き）と、当該アバターのアバター情報（図１５参照）とに基づいて生成されてもよい。この場合、モーションデータは、アバターを動かして操演するモーション、表情、音声の再生、及び効果音の再生等に基づいて生成されてもよい。また、ある同じ属性の所定動画であっても、登場するアバターに応じて動画自体が異なってよい。例えば、「このポータルの先にある伝説の剣、いままでどんな怪力の持ち主が抜こうとしても抜けなかったらしいよ」といった移動先情報の出力後に、所定動画として、移動しているアバターが力を込めて剣を抜こうとしているモーションと表情が効果音とともにダイジェスト再生されてもよい。

また、ポータルを介した移動中、移動しているアバターの服装や所持アイテムが、移動先の属性に応じた服装や所持アイテムに変化されてもよい。すなわち、着替えや変身等が実現されてもよい。例えば、移動先がボールパーク（野球場）であり、目的が応援である場合は、贔屓のチームのユニホームへの着替えや応援用のメガホンの供与等が実現されてもよい。

また、ポータルを介した移動中、移動しているアバター同士の会話等が可能とされてもよい。例えば、ポータルを介した移動中、移動している複数のアバターは、上述した所定動画を見ながら、会話を弾ませることも可能である。
ところで、ゲーム等での実装であれば、ポータルでの移動におけるアニメーションは、メモリへのローディングの間の演出（間を持たせるための演出）や時間稼ぎとしての実装や、シーン遷移の間のストーリー説明としてあらかじめ用意された動画等を再生することが行われてきた。他方、メタバース空間においては、プレイヤーキャラクターと周囲のアバターは必ずしも事前準備可能なキャラクタではない。プレイヤーキャラクターはそれぞれ異なる世界観で設計されたアバターでありうるため、移動先の世界観に合わせた服や装備に変更させる必要がある。そこで、ポータルを介した移動中、ユーザに合意が得られる演出が伴うことが好ましい。また、プレイヤーの行動を観測して楽しむ「視聴者」となるユーザも存在する。従って、ポータルを介した移動中の時間で、視聴者や他のプレイヤー間とのコミュニケーションを行える機能は有用となる。

一のポータルの利用条件は、当該一のポータルを介して移動可能な移動先に係る状態（特に動的に変化しうる状態）に基づいて、動的に変化されてもよい。例えば、この場合、一のポータルに係る移動先の混雑度合い（密度等）が所定閾値を超えた場合、当該一のポータルに係る利用条件が通常時よりも厳しく変更されてもよい。この場合、当該一のポータルに係る利用条件は、当該ポータルが実質的に利用不能となるように変更されてもよい。あるいは、当該一のポータルに係る利用条件は、多段階的に変更されてもよい。また、一のポータルの利用条件は、当該一のポータルを介して移動可能な移動先において不審行動や迷惑行為を行うアバターの出現等のトラブルが生じた場合に、当該ポータルが実質的に利用不能となるように変更されてもよい。

ところで、この種のポータルは、利便性が高いものの、アバターにとっては、移動先の情報が良く分からないと、利用を躊躇いがちとなる。

そこで、本実施形態では、エージェントアバターを利用してポータルに対応付けて各種案内処理が実行されてもよい。図８Ａ及び図８Ｂは、各アバターに対応付けられているエージェントアバターによる案内処理の一例の説明図である。

図８Ａは、ポータル１１００の手前にアバターＡが到着した状態の端末用画像Ｇ１１０Ａの一例を示し、図８Ｂは、アバターＡに対応付けられているエージェントアバター（図８Ｂでは、“エージェントＸ１”と表記）が発生した状態の端末用画像Ｇ１１０Ｂの一例を示す。以下、このように、アバターに同伴する態様で生成されるエージェントアバター（第１所定オブジェクト、第１アバターの一例）を、「第１エージェントアバター」とも称する。第１エージェントアバターは、人工知能アルゴリズムやあらかじめ用意されたアルゴリズム等に基づき自動的に動作するアバターであってよい。

また、第１エージェントアバターは、開発者による事前の準備による設置だけでなく、メタバースを設計・設定する一般ユーザ（モデレータ）によっても配置可能とされてもよい。この場合、従来、サービス提供者側のサービスとして目的に沿って設計されてきた人工知能やエージェントといったソフトウェアアルゴリズムによって提案されてきた方法とは異なり、ユーザが創作として利用できる汎用のインターフェースとして設計することが有用となる。この目的のため、変数やスクリプト等で複雑なロジックもシンプルに記述処理できるプログラマブル要素を備えてもよい。また、初心者ユーザや、チュートリアルを必要とするユーザといった理解力が異なるユーザに対してのみ表示するといったユーザの属性からの選択性も有してよい。

第１エージェントアバターは、常時、アバターＡに同伴してもよいし、図８Ａ及び図８Ｂを対比して分かるように、ポータル１１００の近傍にアバターＡが位置する場合だけ発生してもよい。あるいは、アバターＡからの要求（ユーザ入力）に応じて発生してもよい。

いずれの場合でも、第１エージェントアバターは、ポータル１１００を利用した際の移動先に関する情報（以下、「移動先情報」とも称する）を出力してよい。移動先情報は、文字、音声、画像（動画を含む）又はこれらの任意の組み合わせにより出力されてもよい。例えば、移動先情報が動画を含む場合、動画は、移動先でアバターができることなどを概要として表すダイジェスト版の動画（プレビュー動画）を含んでよい。

なお、第１エージェントアバターの形態や声の質等は、対応するアバター（ユーザ）により選択可能とされてもよい。また、第１エージェントアバターの形態は、近傍に位置するポータルの属性等に応じて変化されてもよい。

図９は、位置又は領域に紐付けられているエージェントアバターの説明図である。図９は、２人のエージェントアバター（図９では、“エージェントＹ１”及び“エージェントＹ２”と表記）がポータル１１００の周辺に位置する状態の端末用画像Ｇ１１０Ｃの一例を示す。以下、このように、位置又は領域に紐付けられているエージェントアバター（第２所定オブジェクト、第２アバターの一例）を、上述した第１エージェントアバターとの区別のために、「第２エージェントアバター」とも称する。第２エージェントアバターは、人工知能アルゴリズムやあらかじめ用意されたアルゴリズム等に基づき自動的に動作するアバターであってよいし、特定のユーザ（例えば移動先に係るユーザ）に対応付けられているアバターであってもよい。後者の場合、例えば移動先が特定の施設である場合、第２エージェントアバターは、当該特性の施設から派遣されるスタッフアバターであってもよい。

いずれの場合でも、第２エージェントアバターは、ポータル１１００に紐付けられてもよいし、ポータル１１００を含む領域（位置の集合）に紐付けられてもよい。また、一の第２エージェントアバターは、複数のポータルを含む領域に紐付けられてもよい。この場合、当該一の第２エージェントアバターは、当該複数のポータルにおいて各種案内を実行してもよい。

図９では、一例として、例えば映画館に移動可能なポータル１１００が示されている。この場合、案内場や入口が設定されており、二人のエージェントアバターＹ１、Ｙ２（図９では、“エージェントＹ１”及び“エージェントＹ２”と表記）が案内場及び入口に対応付けられている。案内場のエージェントアバターＹ１は、対応付けられている領域ＳＰ１において、映画館で上映されている映画の情報やチケットの販売場所等を案内してもよい。あるいは、案内場のエージェントアバターＹ１は、チケットの販売を行ってもよい。この場合、チケットの販売（決済）は、スマートコントラクトにより実現されてもよい。なお、スマートコントラクトは、分散型ネットワーク等を介して実現されてもよい。また、入口のエージェントアバターＹ２は、対応付けられている領域ＳＰ２において、チケットのもぎりなど、入場管理の案内を実行してもよい。

また、図９に示す例では、案内場には、デジタルサイネージのような表示装置１２０（第２オブジェクトＭ３）が設置されている。この場合、表示装置１２０には、移動先（映画館）でアバターが見ることができる映画の内容を概要として表すダイジェスト版の動画等が表示されてもよい。また、図９に示す状況下でも、第１エージェントアバターが同伴されてもよい。この場合、第１エージェントアバターは、第２エージェントアバターから得た情報を、対応するアバターに通知してもよい。

ところで、複数アバター通過型のポータルの場合のように、利用条件にアバターの人数に関する条件が含まれる場合、ポータルを通過するための人数を揃えるためのアバターの交流が促進されるような仕組みが設定されてもよい。

例えば、図１０には、特定のポータルを利用するために待機している複数のアバターの様子が概略的に示されている。この場合、特定のポータルの利用条件は、領域Ｒ１内に６人以上のアバターが位置し、全員のアバターが手をつなぐ場合に満たされることとする。従って、図１０に示す状態では、特定のポータルの利用条件は、満たされておらず、５人のアバターＭ１が待機している状態である。このような領域Ｒ１に対しては、待機しているアバターに対して、移動先情報が提供されてよい。例えば、移動先情報は、ポスターのような画像に対して表示されてもよいし、第１エージェントアバターや第２エージェントアバターの発言として音声合成させてもよいし、空間内に吹き出しのように表示されてもよい。図１０に示す例では、壁部（第２オブジェクトＭ３）には、移動先に関連したトークテーマや、待機しているアバター同士の会話に係るトークテーマを示す表示媒体１００２Ｒが対応付けられてよい。この際、表示媒体１００２Ｒは、対応するトークテーマを表す文字情報等を含んでよい。表示媒体１００２Ｒは、他のユーザとして、領域Ｒ１に入ろうとしているアバターＭ７からの視点で見やすい位置に設置されてよい。これにより、外部のアバターの参加（特定のポータルの利用）を促進することが可能となる。また、領域Ｒ１内のアバターＭ１は、外側のアバターＭ７を誘うなどすることができる。なお、領域Ｒ１内には、移動先に対応付けられている第２エージェントアバターが存在してもよい。この場合、アバターＭ７等に対する第２エージェントアバターを介した案内処理が実現されてよい。
また、図１０に示す例では、領域Ｒ１には、各アバターが視聴可能なディスプレイオブジェクトＭ１０（第２オブジェクトＭ３）等が配置されてもよい。このディスプレイオブジェクトＭ１０には、移動情報として上述したプレビュー動画等が表示されてもよい。これにより、領域Ｒ１内で待機しているアバター間の交流や、領域Ｒ１の外部にいるアバターへのアピール等が促進され、アバターによるポータルの利用の促進を図ることができる。

次に、図１１以降を参照して、上述したポータルに関連した機能（以下、「ポータル機能」とも称する）について更に説明する。

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

図１１は、ポータル機能に関連したサーバ装置１０の機能ブロック図の一例である。図１２は、ポータル情報記憶部１４０内のデータの説明図である。図１３は、ユーザ情報記憶部１４２内のデータの説明図である。図１４は、エージェント情報記憶部１４３内のデータの説明図である。図１５は、アバター情報記憶部１４４内のデータの説明図である。図１６は、利用状況／履歴記憶部１４６内のデータの説明図である。なお、図１２から図１６において、“＊＊＊”は、何らかの情報が格納されている状態を表し、“－”は、情報が格納されていない状態を表し、“・・・”は同様の繰り返しを表す。

サーバ装置１０は、図１１に示すように、ポータル情報記憶部１４０、ユーザ情報記憶部１４２、エージェント情報記憶部１４３、アバター情報記憶部１４４、利用状況／履歴記憶部１４６、及び行動記憶部１４８を含む。なお、ポータル情報記憶部１４０から行動記憶部１４８は、図１に示したサーバ記憶部１２により実現でき、操作入力取得部１５０からトークン発行部１６４は、図１に示したサーバ制御部１３により実現できる。

また、サーバ装置１０は、図１１に示すように、操作入力取得部１５０と、アバター処理部１５２と、ポータル関連処理部１５４と、描画処理部１５６と、案内設定部１６０と、移動処理部１６２と、トークン発行部１６４とを含む。

なお、以下で説明するサーバ装置１０の機能の一部又は全部は、適宜、端末装置２０により実現されてもよい。また、ポータル情報記憶部１４０～行動記憶部１４８の区分けや、操作入力取得部１５０～トークン発行部１６４の区分けは、説明の都合上であり、一部の機能部が、他の機能部の機能を実現してもよい。例えば、アバター処理部１５２や描画処理部１５６の機能の一部又は全部は、端末装置２０により実現されてもよい。また、例えば、ユーザ情報記憶部１４２内のデータの一部又は全部は、アバター情報記憶部１４４内のデータに統合されてもよいし、別のデータベースに格納されてもよい。

ポータル情報記憶部１４０には、仮想空間において利用可能な各種ポータルに関するポータル情報が記憶される。ポータル情報記憶部１４０に記憶されるポータル情報は、ポータル関連処理部１５４に関連して後述するように、ユーザにより生成されてもよい。例えば、ポータルは、ＵＧＣ（Ｕｓｅｒ Ｇｅｎｅｒａｔｅｄ Ｃｏｎｔｅｎｔ）として生成されてもよい。この場合、上述したポータル情報記憶部１４０内のデータ（ポータル情報）が、ＵＧＣを構成する。図１２に示す例では、ポータル情報は、ポータルごとに、６つの要素Ｅ１から要素Ｅ６を含む。

要素Ｅ１は、ポータルオブジェクトＩＤであり、ポータルごとに付与される識別子である。ポータルオブジェクトＩＤは、対応するポータルを作成したユーザＩＤを含ませてもよいが、譲渡が可能な属性のポータルに関しては、ユーザＩＤは省略されてもよい。なお、ポータルオブジェクトＩＤは、発行に費用（課金）が必要とされてもよい。

要素Ｅ２は、権限レベルを示す。権限レベルは、ポータル情報の編集等に対する権限を表し、運営側のポータルであるか、ユーザにより生成されたポータルであるかを表す。また、権限レベルは、時限型や、ワールドのみに有効、グローバルに有効等といった具合に、拡張性を有してもよい。

要素Ｅ３は、図５を参照して上述したポータルの属性を表す。なお、ポータルの属性は、ポータルの形態に係る型（例えば図５に示したチケット型やポスター型等）に応じて自動的に決定されてもよい。

要素Ｅ４は、ポータルの３Ｄオブジェクト情報（描画データ）を表し、ユーザにより生成（カスタマイズ）可能とされてよい。

要素Ｅ５は、ポータルの利用条件（通過条件）を表す。ポータルの利用条件は、図６等を参照して上述したとおりである。ポータルの利用条件は、例えばスクリプトで記述可能とされてよい。また、ポータルの利用条件は、利用条件判定用のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に自動的にリダイレクトさせる形式で記述されてもよい。この場合、ユーザは、ポータルの利用条件を作り込む必要がなくなり、利便性が向上する。同様に、ポータルの利用条件に決済が含まれる場合、スマートコントラクト用のＵＲＬが記述されてもよい。

例えば、「フレンドであって、人数が４名で、Ｗａｒｐのエモートを再生する」というポータルの利用条件は、以下のように記述されてもよい。
“Ｆｒｉｅｎｄｓ＝＝ｔｒｕｅ＆ＧｒｏｕｐＮｕｍ＝＝４＆Ｅｍｏｔｅ＝＝Ｗａｒｐ”
なお、Ｅｍｏｔｅ＝＝Ｗａｒｐとは、Ｗａｒｐのエモートを再生する（各アバターがＷａｒｐの動作をする）ことを意味する。かかるポータルの利用条件を、外部連携ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を利用して判定する例では以下のＷｅｂリクエストが生成されてよい。
“ｈｔｔｐｓ：／／ｇａｔｅ．ｒｅｑｕｅｓｔ／？Ｆｒｉｅｎｄ＝ｔｒｕｅ＆ＧｒｏｕｐＮｕｍ＝４＆Ｅｍｏｔｅ＝Ｗａｒｐ＆ｋｅｙ＝１２３４５”
この場合、セキュリティ対策上のキー文字列｛ｋｅｙ＝１２３４５｝が付加されている。外部連携ＡＰＩは、｛Ｆｒｉｅｎｄ，ＧｒｏｕｐＮｕｍ，Ｅｍｏｔｅ｝を指定する。この場合、当該Ｗｅｂリクエストが成功レスポンス（例えば“２００”）を返せば合格、エラーレスポンス（例えば“４００”）を返せば利用できない、などのように判定は、サーバ装置１０側で行う。

要素Ｅ６は、ポータルの利用時の移動先の座標情報を表す。移動先の座標情報は、一点である必要はなく、集合（領域）として表現されてもよい。移動先の座標情報は、任意の形態で記述されてよいが、例えば、ＵＲＬ形式で記述されてもよい。この場合、例えば、移動先の座標情報は、以下のように記述されてもよい。
ｍｅｔａｐｏｒｔａｌ：／／ｖｒｓｎｓ．＊＊＊．ａｐｐ／ｗｏｒｌｄ／？ｗｉｄ：１２３－４５６７＆ｌａｔ＝７２．３＆ｌｏｎ＝１２．５＆ｏｂｊｉｄ＝ｄｏｏｒ１
この場合、ｍｅｔａｐｏｒｔａｌは、プロトコル名であり、ｖｒｓｎｓ．＊＊＊．ａｐｐは、サービスを提供するサーバ（すなわちサーバ装置１０）のＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）である。なお、このＦＱＤＮはＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバ（サーバ装置１０の要素）によって解決できる名称であり、実際には冗長化された複数のサーバが応答する場合がある。Ｗｉｄは、ワールドＩＤであり、例えば図２を参照して上述した個々の空間部７０に付与されたＩＤを含んでよい。この場合、連携する上記のサーバ等に問い合わせることでインスタンスを獲得できる。ｌａｔ，ｌｏｎは、移動先の緯度、経度であり、実際にはｘ，ｙ，ｚといった座標であってもよい。なお、移動先の緯度、経度は、ワールドＩＤとともに、ｋｅｙ－ｖａｌｕｅ型のテーブルで実装されてもよい。また、ｏｂｊｉｄは、ポータルと接続するオブジェクトＩＤである。例えば、往復型のポータルの場合は、ワールド内のオブジェクトのＩＤや、表示したい３ＤオブジェクトのＩＤを指定できる。なお、往復型のポータルの場合、移動先と同座標にポータルが存在すると無限ループになる可能性がある。要素Ｅ６は、かかる無限ループが生じないように設定されてよい。

要素Ｅ６は、移動先の属性を表す情報を含んでもよい。移動先の属性は、移動先で提供されうるコンテンツの属性や、移動先の領域のサイズ、移動先から戻る方法（往復型など）等に関連した任意の属性であってよい。

ユーザ情報記憶部１４２には、各ユーザに関する情報が記憶される。各ユーザに関する情報は、例えばユーザ登録時に生成されてよく、その後、適宜、更新等されてよい。例えば、図１３に示す例では、ユーザ情報記憶部１４２には、ユーザＩＤに対応付けて、ユーザ名、アバターＩＤ、プロフィール情報、ポータル利用情報等が記憶されている。ユーザ情報記憶部１４２内の情報うちの、一のユーザに係る情報の一部は、当該一のユーザに対応付けているアバターに係るポータルの利用条件の成否の判定に利用されてもよい。

ユーザＩＤは、ユーザ登録時に自動的に生成されるＩＤである。

ユーザ名は、各ユーザが自身で登録した名前であり、任意である。

アバターＩＤは、ユーザが利用するアバターを表すＩＤである。アバターＩＤには、対応するアバターを描画するためのアバター描画情報（図１５参照）が対応付けられてよい。なお、一のアバターＩＤに対応付けられるアバター描画情報は、対応するユーザからの入力等に基づいて追加や編集等が可能であってよい。

プロフィール情報は、ユーザプロフィール（又はアバタープロフィール）を表す情報であり、ユーザによる入力情報に基づいて生成される。例えば、プロフィール情報は、ユーザによる入力情報に基づいて生成されてもよい。また、プロフィール情報は、端末装置２０上で生成されるユーザインタフェースを介して選択されて、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）リクエスト等でサーバ装置１０に提供されてもよい。

ポータル利用情報は、対応するアバターによる各ポータルの利用履歴等を表す情報を含む。なお、ポータル利用情報は、図１６を参照して後述する利用アバター情報と整合し、一方が省略されてもよい。

エージェント情報記憶部１４３は、各エージェントアバターに関するエージェント情報が記憶される。エージェント情報は、上述した第１エージェントアバター及び第２エージェントアバターのうちの、第２エージェントアバターに関する情報を含む。なお、エージェント情報は、エージェントアバターＩＤごとに、管轄領域、案内履歴、ポイント数等の情報を含んでよい。管轄領域は、エージェントアバターに紐付けられる位置又は領域を表す。案内履歴は、上述したようにポータルに関連して当該エージェントアバターが行った案内処理の履歴（日時や相手のアバター等）を含んでよい。ポイント数は、エージェントアバターの評価に関するパラメータであり、例えば、案内処理を行う頻度や有効率（案内処理を行ったアバターがポータルを利用した回数や頻度）等に基づいて算出及び更新されてもよい。この場合、ポイント数に応じた報酬又はインセンティブがエージェントアバターに付与されてもよい。

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

利用状況／履歴記憶部１４６には、ポータルごとに、各アバターによるポータルの利用状況又は利用履歴が記憶される。図１６に示す例では、ポータルオブジェクトＩＤごとに、設置時間（期間）や、利用アバター等を表す情報が記憶されている。なお、設置時間は、アバターが利用可能な状態で設置されている時間（利用可能な時間）を表してよい。利用アバター情報は、対応するポータルを利用したアバターを表す情報である。利用アバター情報は、利用アバターの数等を含んでよく、この場合、対応するポータルの価値（人気度等）を表すことができる。従って、資産性を有するポータルの場合（すなわち、図５を参照して上述した譲渡権が“可（○）”に設定されているポータルの場合）、ポータルの価値は、利用アバター情報に基づいて算出又は予測されてもよい。

行動記憶部１４８は、アバターごとに、ポータルに関連して行った行動が記憶される。記憶対象の行動は、任意であるが、思い出となるような行動が好適である。例えば、一のアバターが一のポータルを介して、対応する移動先に移動した場合に、当該移動先への移動中の当該一のアバターの行動（例えば他のアバターとの記念撮影など）が記憶されてよい。また、一のアバターが一のポータルを介して、対応する移動先に移動した場合に、当該移動先における当該一のアバターの行動（例えば他のアバターと行った活動など）が記憶されてよい。行動記憶部１４８に記憶されるデータは、対応するアバターに係る仮想カメラの画像データ（すなわち端末用画像データ）を含んでよい。

操作入力取得部１５０は、端末装置２０の入力部２４を介して入力される各ユーザによる各種ユーザ入力を取得する。各種入力は、上述したとおりである。

アバター処理部１５２は、アバターごとに、対応する各ユーザによる各種入力に基づいて、アバターの動作（位置の変化や各部位の動き等）を決定する。

ポータル関連処理部１５４は、上述したポータル情報記憶部１４０内のデータを記憶及び更新する。ポータル関連処理部１５４は、ポータル生成部１５４１と、対応付け処理部１５４２とを含む。

ポータル生成部１５４１は、仮想空間においてポータルを生成する。ポータルは、上述のとおりである。ポータルの生成は、上述したポータルオブジェクトＩＤの発行を含む。ポータル生成部１５４１は、ポータルを生成しようとするユーザからの生成要求（ユーザ入力）に基づいて、ポータルを生成する。ポータルの生成条件は、任意であるが、ポータルの属性ごとに設定されてもよい。例えば、可搬性のないポータルの場合、ポータルの生成条件は、当該ポータルを配置しようとする土地の所有権や使用権に関する条件を含んでよい。

対応付け処理部１５４２は、ポータルごとに、ポータルの利用条件、ポータルの属性、及び、移動先（特定の行き先）の属性を対応付ける。ポータルの属性、及び、移動先は、ポータル情報記憶部１４０に関連して上述したとおりである。この場合、対応付け処理部１５４２は、ポータル情報記憶部１４０内の、一のポータルに係るデータを追加することで、当該ポータルに関して、ポータルの利用条件、ポータルの属性、及び、移動先（特定の行き先）の属性を対応付けることができる。

対応付け処理部１５４２は、特定のポータルに関して、当該ポータルの利用条件を動的に変化させてもよい。この場合、対応付け処理部１５４２は、特定のポータルに係る移動先の各種状態（動的に変化しうる各種状態）に応じて、当該ポータルの利用条件を動的に変化させてもよい。このような動的な変化態様は、上述したとおりであってよい。

描画処理部１５６は、アバターを含む仮想空間の画像であって、端末装置２０で視聴用の画像（端末用画像）を生成する。描画処理部１５６は、各アバターに対応付けられた仮想カメラに基づいて、各アバター用の画像（端末装置２０用の画像）を生成する。

案内設定部１６０は、上述した第１エージェントアバターを介した所定の案内処理、又は、上述した第２エージェントアバターを介した所定の案内処理を設定する。所定の案内処理は、ポータルに関する案内処理を含み、ポータルに関する案内処理は、図８Ａから図９を参照して上述したとおりであってよい。

移動処理部１６２は、１人以上のアバターに対して一のポータルの利用条件の成否を判定し、当該利用条件が満たされた場合、当該１人以上のアバターに対して当該一のポータルを利用可能とする。ポータルの利用条件の判定は、任意の方法で実現されてよいが、例えば、上述したように、外部連携ＡＰＩを利用して判定されてもよい。

移動処理部１６２は、１人以上のアバターに対して一のポータルの利用条件が満たされた場合、自動的にポータルを介した移動先への移動処理を実行してもよいし、新たな所定のユーザ入力に応答して、ポータルを介した移動先への移動処理を実行してもよい。

また、移動処理部１６２は、ポータルを介した移動先への移動中に、所定動画を出力する。所定動画は上述したとおりである。例えば、移動処理部１６２は、所定動画を、前記アバターに対応付けられているアバター情報又はユーザ情報に基づいて生成してよい。また、移動処理部１６２は、ポータルを介した移動先への移動中に、移動先に関連するゲーム（ミッション）やクイズ等を実施可能としてもよい。この場合、ゲームやクイズの成績に応じて、移動先での特典が付与されてもよい。

また、移動処理部１６２は、更に、移動先に応じたアイテム又はオブジェクトを、アバターに対応付けてもよい。移動先に応じたアイテム又はオブジェクトは、上述したとおりである。例えば、移動先が南国の島である場合、移動先に応じたアイテム又はオブジェクトは、アロハシャツやビーチサンダルのような軽装を含んでもよい。

移動処理部１６２は、１人以上のアバターに対して一のポータルの利用条件が満たされない場合、その旨の通知を第１エージェントアバターや第２エージェントアバターを介して実行してもよい。

トークン発行部１６４は、行動記憶部１４８内のデータに基づいて、非代替性トークン（ＮＦＴ）を発行する。この場合、ユーザは、自身のアバターを介して得た体験に係るデータ（例えば仮想カメラを介して視た風景等の映像データ）を非代替性トークンとして発行できる。この場合、体験に係るデータは、ブロックチェーンを利用して所有権者やその所有権移転を記録したり、有料又は無料の申請によって複製したり破棄することができる。この場合、体験に係るデータは、ブロックチェーンを利用して仮想現実生成システム１に係るシステム内での処理に限らず、所有権者やその所有権移転を記録したり、仮想現実生成システム１に係るシステム外部のマーケットやスマートコントラクト、分散処理モジュールにおいて有料又は無料の申請によって複製したり破棄することができる。

なお、上述したサーバ装置１０及び端末装置２０間の機能の分担は、あくまで一例であり、上述したように、多様に変更が可能である。すなわち、サーバ装置１０の機能の一部又は全部は、適宜、端末装置２０により実現されてもよい。例えば、描画処理部１５６の機能の一部又は全部が端末装置２０により実現されてもよい。このようなクライアントレンダリング型の構成の場合、描画処理部１５６は、端末用画像を描画するための画像生成条件を生成してもよい。この場合、端末装置２０は、仮想ＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）を生成し、サーバ装置１０から送信される画像生成条件に基づいて、差分検知により端末用画像を描画してもよい。

次に、図１７以降を参照して、上述したポータル機能に関連した仮想現実生成システム１の動作例について説明する。

図１７は、上述したポータル関連処理部１５４によるポータルの生成処理に関連した動作例を示す概略フローチャートである。

ステップＳ１７００では、ポータル関連処理部１５４は、ユーザからポータルの生成要求を受信したか否かを判定する。ユーザによるポータルの生成要求は、任意の態様で生成されてよい。判定結果が“ＹＥＳ”の場合、ステップＳ１７０２に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ１７０２では、ポータル関連処理部１５４は、要求元のユーザに係る端末装置２０を介して、ポータル生成用のユーザインタフェースを出力する。ポータル生成用のユーザインタフェースは、端末用画像に重畳される態様で生成されてもよい。ポータル生成用のユーザインタフェースは、上述したようにポータル情報をユーザが生成（記述）するためのユーザインタフェースである。

ステップＳ１７０４では、ポータル関連処理部１５４は、ポータル生成用のユーザインタフェースに対するユーザの入力が完了したか否かを判定する。入力の完了は、ユーザによる確認（確定）操作等を介して生成されてもよい。判定結果が“ＹＥＳ”の場合、ステップＳ１７０６に進み、それ以外の場合は、入力の完了の待機状態となる。なお、一定時間以上、待機状態が継続した場合は終了してよい。

ステップＳ１７０６では、ポータル関連処理部１５４は、ポータル生成用のユーザインタフェースに対するユーザの入力結果を取得する。

ステップＳ１７０８では、ポータル関連処理部１５４は、ユーザの入力結果に基づいて、ポータルの生成条件を満たすか否かを判定する。ポータルの生成条件は、上述したとおりである。判定結果が“ＹＥＳ”の場合、ステップＳ１７１０に進み、それ以外の場合は、ステップＳ１７１２に進む。

ステップＳ１７１０では、ポータル関連処理部１５４は、ユーザの入力結果に基づいて、新たなポータルを生成する。この場合、ポータル関連処理部１５４は、新たなポータルオブジェクトＩＤを発行して、ポータル情報記憶部１４０内のデータを更新してよい。

ステップＳ１７１２では、ポータル関連処理部１５４は、ポータルの生成条件が満たされないことを表すエラー通知を実行する。なお、この場合、エラー通知は、ポータル生成用のユーザインタフェースを介して実現されてもよい。

図１８は、案内設定部１６０による案内処理に関連した動作例を示す概略フローチャートである。図１８は、一の第２エージェントアバターを介した案内処理であり、各第２エージェントアバターを介した案内処理は、同様の態様で並列的に実行されてよい。

ステップＳ１８００では、案内設定部１６０は、対象の第２エージェントアバターの位置情報と、各アバターの位置情報とを取得する。

ステップＳ１８０２では、案内設定部１６０は、ステップＳ１８００で得た各位置情報に基づいて、第２エージェントアバターが案内可能な周辺アバターが存在するか否かを判定する。第２エージェントアバターが案内可能な周辺アバターは、第２エージェントアバターに対して所定距離内に位置するアバターや、第２エージェントアバターに紐付けられている対象のポータルに対して所定距離内に位置するアバター等を含んでよい。判定結果が“ＹＥＳ”の場合、ステップＳ１８０４に進み、それ以外の場合は、そのまま終了する。

ステップＳ１８０４では、案内設定部１６０は、第２エージェントアバターを介して案内処理を実行する。なお、第２エージェントアバターを介した案内処理の内容は、事前に規定されてよい。第２エージェントアバターは、上述したように、移動先の施設等の管理者から委託されたエージェントであってもよい。この場合、委託者は、あらかじめ用意されているＡＰＩを利用すべく、当該エージェントに係るＵＲＬを指定してもよい。これにより、委託者は、細かい条件を作りこむ必要なく、第２エージェントアバターを介した案内処理を実現できる。

ステップＳ１８０６では、案内設定部１６０は、第２エージェントアバターによる案内処理が実行されたことに応答して、第２エージェントアバターによる案内処理の履歴（図１４の「案内履歴」参照）を更新する。この場合、案内処理により当該ポータルが利用されたか否かを表す情報（すなわち案内処理の有効性に関する情報）が併せて記憶されてもよい。

図１９は、移動処理部１６２による処理に関連した動作例を示す概略フローチャートである。図１９は、一のポータル（以下、「本ポータル」とも称する）に係る処理であり、各ポータルに係る処理は、同様の態様で並列的に実行されてよい。

ステップＳ１９００では、移動処理部１６２は、ポータル周辺のアバターのうちから、ポータルを利用することを希望するアバターを抽出する。ポータルを利用することを希望するアバターとは、例えばポータルに紐付けられている領域内に存在するアバターや、ユーザ入力に基づいて利用要求を行うアバター等を含んでよい。

ステップＳ１９０２では、移動処理部１６２は、ステップＳ１９００で抽出した１人以上のアバターに関して、ポータルの利用条件を満たすか否かを判定する。なお、本ポータルが複数アバター通過型のポータルの場合、同行することを希望する複数のアバターを抽出し、抽出した複数のアバターに対して、本ポータルの利用条件を満たすか否かを判定してもよい。判定結果が“ＹＥＳ”の場合、ステップＳ１９０４に進み、それ以外の場合は、今回の処理周期の処理は終了する。

ステップＳ１９０４では、移動処理部１６２は、ポータルの利用条件を満たした１人以上のアバターに対してポータルを介した移動を開始する。

ステップＳ１９０６では、移動処理部１６２は、移動先フラグを“１”にセットする。移動先フラグは、ポータルを利用した移動先への移動中と、移動先での滞在中と、移動先から戻る移動中に、“１”となるフラグである。すなわち、移動先フラグは、ポータルを介した移動開始時から、移動先から元の場所（又は他の新たな移動先）に移動するまでの間、“１”となるフラグである。

ステップＳ１９０８では、移動処理部１６２は、移動中の１人以上のアバターに係るユーザ情報を取得する。

ステップＳ１９１０では、移動処理部１６２は、ステップＳ１９０８で取得したユーザ情報に基づいて、所定動画を生成する。所定動画は、上述したとおりである。移動中の各アバターが仲間同士である場合、所定動画は、共通の思い出などを想起させる動画等であってもよい。あるいは、所定動画は、移動先に係るチュートリアルなどの動画を含んでよい。

ステップＳ１９１２では、移動処理部１６２は、ステップＳ１９１０で生成した所定動画を、対応するアバターに係る端末装置２０を介して出力する。なお、所定動画の生成（描画）は、上述したように、端末装置２０側で実行されてもよい。

ステップＳ１９１４では、移動処理部１６２は、移動中の１人以上のアバターのそれぞれに対して、上述した行動記憶部１４８内のデータの更新処理（以下、「思い出録画処理」とも称する）を開始する。なお、思い出録画機能の設定はアバターによりオン／オフの切り替えが可能とされてもよい。この場合、思い出録画機能の設定がオン状態であるアバターに対して、思い出録画処理が実行されてよい。

ここで、思い出録画機能は基本的にモーションデータの保存によるメタバース世界での行動の記録と再生である。従って、録画されたデータは、効果音や演出、カメラの位置情報など自動再生されるロジックもあわせて再生可能とされてもよい。また、再生時は白黒画像やセピア処理などトーンマッピングなどを施し「思い出である」ことを想起させる演出を伴ってもよい。また、服の変更やアイテムの取得などの状態の変化も含めて再生することも可能である。この際、再生中のアイテムの取得のような所有権の移転、「破壊や死亡」といった不可逆な処理は処理されないようにしてもよい。これは、重複処理を防ぐためである。

思い出データは、サーバ装置１０内又はユーザのデータ領域に圧縮してハンドラーＩＤとともに保管されてよい。例えば、ＮＦＴ上にはそのハンドラーＩＤが記載されており、ＮＦＴの所有権移転時にはそのデータの移転や複製が伴う。ハンドラーには圧縮展開処理が記述されており、他のシステムでの再生や復元が可能な形式となっている（例としてＺＩＰ形式のような暗号化ファイルでの圧縮、ＮＦＴに記述された暗号による展開）。互換性のために、ＭＰＥＧのような標準化された画像や動画に変換されてもよい。

この場合、「互換形式として動画」を維持しつつ、オリジナルの３Ｄアバターアニメーションによる思い出を本プラットフォームで利用できる最大の再生形式として流通させることができる。その結果、ＮＦＴの非可換性と流通性を維持したまま、提供プラットフォームの魅力を高めることができる。

思い出録画処理は、更なる具体例は、以下で図２０を参照して説明する。

図２０は、移動処理部１６２による思い出録画処理に関連した動作例を示す概略フローチャートである。図２０に示す処理は、思い出録画処理の対象のアバターごとに並列的に実行されてよい。

ステップＳ２０００では、移動処理部１６２は、移動先フラグが“１”であるか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２００２に進み、それ以外の場合は、ステップＳ２０１２に進む。

ステップＳ２００２では、移動処理部１６２は、思い出録画中であるか否かを判定する。思い出録画による録画対象の画像は、対応するアバターの視線に対応する仮想カメラから視た風景等の画像であってよい。あるいは、対応するアバターの視線とは別の視線で、アバター等を捕捉する思い出録画用の仮想カメラが設定されてもよい。判定結果が“ＹＥＳ”の場合、ステップＳ２００４に進み、それ以外の場合は、ステップＳ２００８に進む。

ステップＳ２００４では、移動処理部１６２は、録画停止条件が成立したか否かを判定する。録画停止条件は、例えば対応するアバターからの停止指示があった場合に満たされてよい。判定結果が“ＹＥＳ”の場合、ステップＳ２００６に進み、それ以外の場合は、ステップＳ２００７に進む。

ステップＳ２００６では、移動処理部１６２は、思い出録画を停止する。

ステップＳ２００７では、移動処理部１６２は、思い出録画を継続する。この場合、思い出録画に係る画像（動画）が所定の記憶領域に記憶されてよい。

ステップＳ２００８では、移動処理部１６２は、録画再開条件が成立したか否かを判定する。録画再開条件は、例えば対応するアバターからの録画再開指示があった場合に満たされてよい。判定結果が“ＹＥＳ”の場合、ステップＳ２０１０に進み、それ以外の場合は、今回の処理周期は終了する。
ステップＳ２０１０では、移動処理部１６２は、思い出録画を再開する。

ステップＳ２０１２では、移動処理部１６２は、前回の処理周期での移動先フラグが“１”であるか否かを判定する。すなわち、今回の処理周期で移動先フラグが“１”から“０”に遷移したか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２０１４に進み、それ以外の場合は、今回の処理周期は終了する。

ステップＳ２０１４では、移動処理部１６２は、今回の移動先フラグが“１”である期間中に録画された画像データに基づいて、行動記憶部１４８内のデータを更新する。この場合、上述したトークン発行部１６４は、新たな画像データ又はその加工データ（ユーザによる編集されたデータ）に基づいて、非代替性トークンを発行してもよい。より具体的には、モーションデータをハンドラーとともに保存して、格納してもよい。この場合、格納したデータをそのまま仮想現実生成システム１内で流通させてもよいし（例えば、音楽ライブの１曲分）、外部にＮＦＴで流通させる場合はＭＰＥＧ動画としてレンダリングした状態でエクスポートさせてもよい。

なお、図１７以降の説明にあたっては、各ステップの処理がサーバ装置１０によって実行される場合について述べたが、既述のとおり、本実施形態に係る仮想現実生成システム１（情報処理システム）は、サーバ装置１０が単独で実現するようにしてもよいし、サーバ装置１０と１つ以上の端末装置２０が協動して実現するようにしてもよい。後者の場合には、例えば、画像生成条件をサーバ装置１０から端末装置２０に送信し、端末装置２０において、画像生成条件に基づいて、端末用画像を描画するようにしてもよい。端末装置２０側で描画を行う場合、各オブジェクト（例えばポータル）や各オブジェクトとの関係等は、必ずしも各端末装置２０で同じように描画されなくてもよい。

以上、各実施形態について詳述したが、特定の実施形態に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、前述した実施形態の構成要素の全部又は複数を組み合わせることも可能である。

例えば、上述した実施形態では、思い出録画処理は、ポータルを介した移動に関して実行されているが、ポータルを介した移動とは無関係に実行されてもよい。

１ 仮想現実生成システム
３ ネットワーク
１０ サーバ装置
１１ サーバ通信部
１２ サーバ記憶部
１３ サーバ制御部
２０ 端末装置
２１ 端末通信部
２２ 端末記憶部
２３ 表示部
２４ 入力部
２５ 端末制御部
１４０ ポータル情報記憶部
１４２ ユーザ情報記憶部
１４３ エージェント情報記憶部
１４４ アバター情報記憶部
１４６ 利用状況／履歴記憶部
１４８ 行動記憶部
１５０ 操作入力取得部
１５２ アバター処理部
１５４ ポータル関連処理部
１５４１ ポータル生成部（特定オブジェク生成部）
１５４２ 対応付け処理部
１５６ 描画処理部
１５８ 処理部
１６０ 案内設定部
１６２ 移動処理部
１６４ トークン発行部

Claims (24)

1. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成する特定オブジェクト生成部と、
   前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付ける対応付け処理部と、
   前記アバターに同伴する第１所定オブジェクトを介した所定の案内処理、又は、位置又は領域に紐付けられている第２所定オブジェクトを介した所定の案内処理を設定する案内設定部とを含む、情報処理システム。
2. 前記所定の案内処理は、前記特定位置又は特定領域に関する情報を出力する処理を含む、請求項１に記載の情報処理システム。
3. 前記特定位置又は特定領域に関する情報は、前記特定位置又は特定領域に係る動画を含む、請求項２に記載の情報処理システム。
4. 前記特定オブジェクトごとに、複数の前記アバターによる一の前記特定オブジェクトの利用状況又は利用履歴を記憶する利用状況／履歴記憶部を含む、請求項２に記載の情報処理システム。
5. 前記第２所定オブジェクトは、前記特定オブジェクトの位置を含む領域に対応付けられる第１アバター、及び、前記特定位置又は特定領域に対応付けられる第２アバターのうちの、少なくともいずれか一方を含む、請求項１に記載の情報処理システム。
6. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成する特定オブジェクト生成部と、
   前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付ける対応付け処理部とを含み、
   前記特定オブジェクトの属性は、前記アバターによる利用に伴う消費の可否の設定状態と、前記アバターによる持ち運び可否の設定状態と、仮想空間に固定されているか否かの設定状態と、前記アバターの衣装のポケット又は前記アバターの内部に格納されているか否かの設定状態と、複製の可否の設定状態と、譲渡の可否の設定状態、のうちの少なくともいずれか２つを含む、情報処理システム。
7. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成する特定オブジェクト生成部と、
   前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付ける対応付け処理部とを含み、
   前記特定オブジェクトの利用条件は、同時に移動可能な前記アバターの人数に関する条件を含む、情報処理システム。
8. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成する特定オブジェクト生成部と、
   前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付ける対応付け処理部と、
   一の前記アバターが一の前記特定オブジェクトを介して前記特定位置又は特定領域に移動した場合に、前記特定位置又は特定領域への移動中の前記一のアバターの行動、及び、前記特定位置又は特定領域における前記一のアバターの行動のうちの少なくともいずれか一方を記憶する行動記憶部とを含む、情報処理システム。
9. 前記行動記憶部内のデータに基づいて、非代替性トークン（ＮＦＴ）を発行するトークン発行部を更に含む、請求項８に記載の情報処理システム。
10. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成する特定オブジェクト生成部と、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付ける対応付け処理部とを含み、
    前記対応付け処理部は、前記特定位置又は特定領域に対応付けられる特定ユーザからのユーザ入力に基づいて、前記特定オブジェクトの利用条件を生成又は更新する、情報処理システム。
11. 前記対応付け処理部は、前記特定オブジェクトの利用条件を、前記特定位置又は特定領域に係る状態に基づいて、設定又は更新する、請求項１、６から８及び１０のいずれか１項に記載の情報処理システム。
12. 前記特定位置又は特定領域への移動中に、所定動画を出力する移動処理部を更に含む、請求項１、６から８及び１０のいずれか１項に記載の情報処理システム。
13. 前記移動処理部は、前記所定動画を、前記アバターに対応付けられているアバター情報又はユーザ情報に基づいて生成する、請求項１２に記載の情報処理システム。
14. 前記移動処理部は、更に、前記特定位置又は特定領域に応じたアイテム又はオブジェクトを、前記アバターに対応付ける、請求項１２に記載の情報処理システム。
15. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成し、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付け、
    前記アバターに同伴する第１所定オブジェクトを介した所定の案内処理、又は、位置又は領域に紐付けられている第２所定オブジェクトを介した所定の案内処理を設定する、処理をコンピュータにより実行させるプログラム。
16. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成し、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付け、
    前記アバターに同伴する第１所定オブジェクトを介した所定の案内処理、又は、位置又は領域に紐付けられている第２所定オブジェクトを介した所定の案内処理を設定することを含む、コンピュータにより実行される情報処理方法。
17. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成し、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付ける、処理をコンピュータにより実行させ、
    前記特定オブジェクトの属性は、前記アバターによる利用に伴う消費の可否の設定状態と、前記アバターによる持ち運び可否の設定状態と、仮想空間に固定されているか否かの設定状態と、前記アバターの衣装のポケット又は前記アバターの内部に格納されているか否かの設定状態と、複製の可否の設定状態と、譲渡の可否の設定状態、のうちの少なくともいずれか２つを含む、プログラム。
18. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成し、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付けることを含み、
    前記特定オブジェクトの属性は、前記アバターによる利用に伴う消費の可否の設定状態と、前記アバターによる持ち運び可否の設定状態と、仮想空間に固定されているか否かの設定状態と、前記アバターの衣装のポケット又は前記アバターの内部に格納されているか否かの設定状態と、複製の可否の設定状態と、譲渡の可否の設定状態、のうちの少なくともいずれか２つを含む、コンピュータにより実行される情報処理方法。
19. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成し、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付ける、処理をコンピュータにより実行させ、
    前記特定オブジェクトの利用条件は、同時に移動可能な前記アバターの人数に関する条件を含む、プログラム。
20. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成し、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付けることを含み、
    前記特定オブジェクトの利用条件は、同時に移動可能な前記アバターの人数に関する条件を含む、コンピュータにより実行される情報処理方法。
21. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成し、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付け、
    一の前記アバターが一の前記特定オブジェクトを介して前記特定位置又は特定領域に移動した場合に、前記特定位置又は特定領域への移動中の前記一のアバターの行動、及び、前記特定位置又は特定領域における前記一のアバターの行動のうちの少なくともいずれか一方を記憶する、処理をコンピュータにより実行させるプログラム。
22. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成し、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付け、
    一の前記アバターが一の前記特定オブジェクトを介して前記特定位置又は特定領域に移動した場合に、前記特定位置又は特定領域への移動中の前記一のアバターの行動、及び、前記特定位置又は特定領域における前記一のアバターの行動のうちの少なくともいずれか一方を記憶することを含む、コンピュータにより実行される情報処理方法。
23. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成し、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付ける、処理をコンピュータにより実行させ、
    前記特定位置又は特定領域に対応付けられる特定ユーザからのユーザ入力に基づいて、前記特定オブジェクトの利用条件を生成又は更新する、プログラム。
24. 仮想空間において、仮想空間の特定位置又は特定領域へのアバターの移動を可能とする特定オブジェクトを生成し、
    前記特定オブジェクトに対して、前記特定オブジェクトの利用条件、及び、前記特定オブジェクトの属性又は前記特定位置の属性若しくは前記特定領域の属性、のうちの少なくともいずれか一方の情報を対応付けることを含み、
    前記特定位置又は特定領域に対応付けられる特定ユーザからのユーザ入力に基づいて、前記特定オブジェクトの利用条件を生成又は更新する、コンピュータにより実行される情報処理方法。