JP7454166B2 - 情報処理システム、情報処理方法、及び記憶媒体 - Google Patents

Description

本開示は、情報処理システム、情報処理方法、及び記憶媒体に関する。

会話開始トリガ等の第１トリガが検知されるまでは、複数の仮想キャラクタの配置を、仮想キャラクタ配置取得部によって取得された配置に従った配置とする表示制御データを生成し、第１トリガが検知されたことに応答して、第１トリガに関連付けられた第１仮想キャラクタの仮想空間における配置が変更された表示制御データを生成する技術が知られている。

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

しかしながら、上記のような従来技術では、アバター間の交流を効果的に促進することが難しい。

そこで、１つの側面では、本開示は、アバター間の交流を効果的に促進することを目的とする。

１つの側面では、仮想空間において各アバターの動きを処理するアバター処理部と、
各アバターに、対応するユーザにより指定される文字情報又はアバター自身と関連付けられる文字情報を対応付ける対応付け処理部と、
第１アバターに対応付けられている前記文字情報と、第２アバターに対応付けられている前記文字情報との関係を判定する第１判定部とを備え、
前記アバター処理部は、仮想空間において第１所定位置関係に前記第１アバターと前記第２アバターとが存在する場合に、前記第１判定部による判定結果に基づいて、前記第２アバターに、又は、前記第１アバターと前記第２アバターの双方に、所定動作を自動的に行わせる、情報処理システムが提供される。

１つの側面では、本開示によれば、アバター間の交流を効果的に促進することが可能となる。

本実施形態に係る仮想現実生成システムのブロック図である。 ヘッドマウントディスプレイを介して視認可能な端末用画像の説明図である。 スマートフォンを介して視認可能な端末用画像の説明図である。 仮想空間における自動リアクションの発動シーン（その１）の一例を示す説明図である。 仮想空間における自動リアクションの発動シーン（その２）の一例を示す説明図である。 仮想空間における自動リアクションの発動シーン（その１）の他の一例を示す説明図である。 仮想空間における自動リアクションの発動シーン（その２）の他の一例を示す説明図である。 タグ情報に基づく文字間距離の説明図である。 制限フラグの説明図である。 自動リアクションに関連したサーバ装置の機能を示す概略的なブロック図である。 自動リアクション関連データ記憶部内のデータの一例を示す説明図である。 ユーザ情報記憶部内のデータの一例を示す説明図である。 プロフィール情報の説明図である。 アバター情報記憶部内のデータの一例を示す説明図である。 アバターの自動リアクションに関連してサーバ装置により実行される処理の一例を示す概略的なフローチャートである。 アバターの自動リアクションに関連してサーバ装置により実行される処理の他の一例を示す概略的なフローチャートである。

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

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

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

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

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

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

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

図１に示す例では、仮想現実生成システム１は、スタジオユニット３０Ａ、３０Ｂを含む。スタジオユニット３０Ａ、３０Ｂは、主催側の端末装置２０Ａと同様、主催側の装置である。スタジオユニット３０Ａ、３０Ｂは、コンテンツ制作用のスタジオ、部屋、ホール等に配置され得る。スタジオユニット３０Ａ、３０Ｂには、モーションキャプチャ用の各種機材が設置されてもよい。

各スタジオユニット３０は、主催側の端末装置２０Ａ、及び／又は、サーバ装置１０と同様の機能を有することができる。以下、主催側と参加側を区別する場合、説明を簡単にするために、主催側の端末装置２０Ａがサーバ装置１０を介して各参加側の端末装置２０Ｂに対して各種のコンテンツを配信する態様を主に説明する。しかしながら、これに代えて又はこれに加えて、主催側ユーザに対向するスタジオユニット３０Ａ、３０Ｂが、主催側の端末装置２０Ａと同様の機能を有することにより、サーバ装置１０を介して各参加側の端末装置２０Ｂに対して各種のコンテンツを配信してもよい。なお、変形例では、仮想現実生成システム１は、スタジオユニット３０Ａ、３０Ｂを備えていなくてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここで、このような多様な仮想空間においては、多種多様なユーザが存在しうる。例えば、配信ユーザは、映像および／または音声に関する情報を送信する側のユーザを意味するものとする。例えば、配信ユーザは、単独での動画配信、複数人が参加可能なコラボ配信、複数人が参加および／または視聴可能なビデオチャットまたはボイスチャット、複数人が参加および／または視聴可能な仮想空間上でのイベント（パーティなど）を主催または開催するユーザ、すなわち、これらをメインで実行するユーザであればよい。そのため、本開示における配信ユーザは、ホストユーザ、主催ユーザまたは開催ユーザなどと言い換えることもできる。

一方で、視聴ユーザは、映像および／または音声に関する情報を受信する側のユーザを意味するものとする。ただし、視聴ユーザは上記情報を受信するのみならず、リアクションすることも可能なユーザとすることができる。例えば、視聴ユーザは、動画配信、コラボ配信を視聴するユーザ、または、ビデオチャット、ボイスチャットやイベントに参加および／またはこれらを視聴するユーザであればよい。そのため、本開示における視聴ユーザは、ゲストユーザ、参加ユーザ、リスナー、観覧ユーザ、応援ユーザなどと言い換えることもできる。

また、本開示の実施形態における情報処理システムは、多くの人が同時に参加してキャラクタオブジェクト（アバター）を通じた交流や仕事、遊びなど、実社会に近いレベルの自由な活動ができるデジタル世界であって、現実と仮想の隔たりを超えて社会活動ができる、次のインターネット空間（メタバース）を提供するために用いられることができる。

このようなメタバース空間において、ユーザのアバターはワールド内を自由に歩き回り、互いにコミュニケーションをとることが可能である。

そして、かかるメタバース空間にいる複数のアバターの中の一のアバター（キャラクタオブジェクト）が、配信ユーザのキャラクタオブジェクトとして動画を配信できる構成としてもよい。すなわち、多対多のメタバース空間において一対多の動画配信を行うことができるものとしてもよい。

このようなメタバース空間において、配信ユーザと視聴ユーザとは特に区別されないものとすることができる。

次に、図４から図９を参照して、仮想空間内におけるアバターの動作に関する特徴的な構成を説明する。

図４及び図５は、仮想空間における自動リアクションの発動シーンの一例を示す説明図である。図６及び図７は、仮想空間における自動リアクションの発動シーンの他の一例を示す説明図である。図８は、タグ情報に基づく文字間距離の説明図である。図９は、制御フラグの説明図である。

なお、以下の説明において登場する各種モノ（例えばサッカーボールやピアノ等）は、特に言及しない限り、仮想空間におけるオブジェクトであり、実物とは異なる。また、以下の説明における各種イベントは、仮想空間における各種イベント（例えば、演奏会等）であり、現実でのイベントとは異なる。また、以下の説明において、アバターが、あるモノを取得する（手に入れる）とは、当該アバターに、当該モノが対応付けられていない状態から、当該モノが対応付けられている状態への遷移を表す。また、上述したように、一のアバターと、当該一のアバターに対応付けられているユーザとは、同一視できる関係であるので、これらを区別せずに説明する場合もある。なお、一のユーザが、複数のアバターに対応付けられる仕様も可能であるが、この場合も、当該一のユーザは、一のアバターを選択して仮想空間内で活動する。従って、この場合も、各時点では、一のアバターと、当該一のアバターに対応付けられているユーザとは、同一視できる関係である。

本実施形態では、仮想空間内におけるアバターの動作は、ユーザからのユーザ入力に応じた通常の動作に加えて、文字情報に基づく所定動作（以下、「自動リアクション」とも称する）を含む。以下では、自動リアクションを行うか否かを判定されるアバター又は自動リアクションを行うアバター（第２アバターの一例）を、「リアクション主体のアバター」とも称する。この場合、自動リアクションは、リアクション主体のアバターに対応付けられている文字情報に基づく自動的な動作である。文字情報は、リアクション主体のアバター又はリアクション主体のアバターに対応付けられているユーザ（以下、「対象ユーザ」とも称する）の嗜好を表す情報であってよい。例えば、文字情報は、好きな人、好きなこと、苦手な人、苦手なこと、好きな属性、苦手な属性等を表してよい。また、文字情報は、性格（“陽キャ”や“陰キャ”等）を表してもよい。また、文字情報は、リアクション主体のアバターに対応付けられているプロフィール情報等を含んでよい。また、文字情報は、仮想空間内におけるアバターの各種活動（会話／発語情報や行動履歴等）に応じて自動的に生成されてもよい。文字情報の更なる具体例は、後述する。

自動リアクションは、他のオブジェクトや他のアバター等に対して、自動的に行われる反応的な動作である。自動リアクションは、自動的に行われるため、ユーザからの特別なユーザ入力を必要としない。ただし、各アバターは、自動リアクションの実行可否に関する設定が可能とされてもよい。この場合、自動リアクションの実行が可能と設定されている各アバターに対してのみ、自動リアクションが自動的に行われてよい。

自動リアクションは事前に用意されているアニメーションデータに基づいて描画されてもよい。これは、本開示では、アバター間の交流を効果的に促進することを課題としているが、他のアバターによるすべての特定行動に対して処理対象アドバイザーの自動リアクションをトラッキングしていると処理負荷が高くなりすぎる可能性があること、また、リアクションが遅れたり、通信状況によってモーションデータを送るのに時間を要したりすると、大事な場面（例えば初対面のとき）におけるタイムリーなリアクションが取れなくなってしまう可能性があることなどから、自動リアクションの種類を限定しているものである。この場合、自動リアクションは、ユーザからのユーザ入力とは無関係に、実行可能であるので、すべての時間にわたってユーザのユーザ入力（例えばモーションキャプチャによるトラッキング情報）を取得する必要がなくなる。この結果、通信負荷を効率的に低減できる。また、アバター（ユーザ）側からしても、自動リアクションが自動的に実行されるので、ユーザがその都度リアクションをとったりエモートを選択したりする労力（手間）を省くことができ、利便性が向上する。

自動リアクションの描画については、サーバ装置１０から端末装置２０にアバターをどのように動作させるかというモーションデータを送信し、端末装置２０でそのモーションデータからアバターを動作させるようにしてもよい。例えば、サーバ装置１０で事前生成したアニメーションにモーションデータをブレンドして、端末装置２０でトラッキングして操作するようにしてもよい。具体的には、端末装置２０の画面でジョイスティック（画面でのコントロール）をもってアバターを移動させながら、興味のあるアバターには首や視線が自動的に向くようにしてもよい。そのほかにも、サーバ装置１０から端末装置２０に対し、スマイリングフェースマークというエモートや記号としてハートマークのパーティクルを自動的に発火させる（出現させる）ようにしてもよい。さらに、スタンプ、ＧＩＦアニメーションの再生を頭の上や吹き出しで表示させるようにしてもよい。なお、本開示では、後述するように、自動リアクションを実行するか否かの判定は、サーバ装置１０で行うように説明しているが、判定は、サーバ装置１０だけでなく、端末装置２０で、又は端末装置２０でも、行うようにしてもよい。なお、自動リアクションの描画がなされる実際のＣＧ空間においては、そのディスプレイ解像度や表示される他のオブジェクトの状況により、細かなアバターの機微や動作の表示が必ずしも適さない場合がある。このような状況への対応としては、指や視線、表情といった細かなボーン情報や演出画像をやり取りする必要がある３次元的距離との関係において、十分に離れることで表示ピクセル上では判別できない状態になる距離ＬｏＤ（Ｌｅｖｅｌ ｏｆ Ｄｅｔａｉｌ）に基づく処理がある。ＬｏＤは、ゲームエンジン内で開発者が自動もしくは明示的に管理するが、本開示においては、実際にアバターを表示すべき３次元位置の関係に加えて、自動リアクションの動作の閾値となるアバター間の興味の距離ＬｏＩ（Ｌｅｖｅｌ ｏｆ Ｉｎｔｅｒｅｓｔ）を利用することにより、効率良く情報のカリングや通信量の圧縮、描画コストの節減、キャッシュヒット率の向上を図るようにしてもよい。

アニメーションデータに基づく描画は、アバターの各部位の一部である所定部位だけに適用されてもよい。所定部位は、自動リアクションに関連した部位であり、例えば、自動リアクションが、手を上げて挨拶する動作である場合、所定部位は、アバターの手の部分であってよい。この場合、他の部位は、インバースキネマティクス（Ｉｎｖｅｒｓｅ Ｋｉｎｅｍａｔｉｃｓ）を利用して描画されてよい。このような構成によれば、所定部位以外の他の部位のうち、所定部位の動きに無関係な部位については、ユーザ操作に基づく描画も可能であり、この場合、各アバターの個性の表現が可能となる。なお、所定部位の一部は、一つの部位であってもよいし、一つの部位に限らずに複数の部位を含んでもよく、アニメーションは、複数の部位が連動して行われてもよい。例えば、挨拶をする際の動作として、手を振りながら頭を傾げるなど、手のほかに、頭を含めてもよい。

なお、アバターの顔の表情（例えば目や口等の動き）やそれに付随する部分（髪や髪飾りなど）を描画可能である仕様の場合、自動リアクション中のアバターの顔の表情やそれに付随する部分の動きは、同様にアニメーションによる描画であってもよいし、ユーザ操作に基づく描画であってもよい。また、アバターの顔の表情（例えば目や口等の動き）を描画可能である仕様の場合、自動リアクション中のアバターの顔の表情は、ユーザの顔画像情報やモーションキャプチャ（例えばフェイスキャプチャ）で取得されたトラッキング情報に基づいて描画されてもよい。

自動リアクションは、所定の発動条件が満たされた場合に、その後のユーザからのユーザ入力とは無関係に（すなわち自動的に）実行されてもよい。所定の発動条件は、リアクション主体のアバター又は対象ユーザに対応付けられている文字情報（以下、「リアクション主体のアバターに対応付けられている文字情報」で代表する）に基づく条件であってよい。すなわち、所定の発動条件の成否は、リアクション主体のアバターに対応付けられている文字情報に基づいて判定されてよい。

自動リアクションは、仮想空間におけるアバター間の交流を促進するための任意の動作であってよい。例えば、自動リアクションは、拍手のような称賛動作、笑顔を向ける動作、挨拶する動作、好意的なポーズ（グーサインなど）やアクションを行う動作、声をかける動作、ギフトや手紙を贈る、その他の好意的なエモート動作、又は、これらの類の各種動作を含む。また、自動リアクションは、これらの各種動作の任意の組み合わせを含んでもよい。

例えば、リアクション主体のアバターが他のアバターに、自動リアクションとして、笑顔を向ける動作を行う場合、他のアバターとリアクション主体のアバターとが初対面であったとしても、両者の交流が促進される可能性がある。例えば、他のアバターは、笑顔を向けているリアクション主体のアバターの存在に気が付き、声をかけることで、対話が開始される可能性がある。

このようにして自動リアクションは、特定の相手のアバター（以下、「相手アバター」とも称する）（第１アバターの一例）に向けた動作であってよい。従って、所定の発動条件は、仮想空間において所定位置関係（以下、「第１所定位置関係」とも称する）にリアクション主体のアバターと相手アバターとなりうる他のアバターとが存在する場合に、判定されてよい。これにより、自動リアクションを適切なタイミングで実行可能としつつ、処理負荷の低減を図ることができる。

この場合、第１所定位置関係は、任意であるが、互いに対して所定距離（例えば仮想空間における３次元の空間距離又は２次元の距離）内であることや、相手アバターとなりうる他のアバターからリアクション主体のアバターが見える位置関係（すなわち他のアバターからリアクション主体のアバターが見える位置関係）を含んでよい。あるいは、第１所定位置関係は、相手アバターとなりうる他のアバターの現在の視点からはリアクション主体のアバターが見えないが、その場で当該他のアバターの視点を変えると（例えば顔の向きや体の向きを変えると）、当該他のアバターからリアクション主体のアバターが見える位置関係を含んでよい。

図４及び図５には、自動リアクションが実行されうる一シーンが示されている。この場合、学校の廊下で、リアクション主体のアバターであるアバターＡ１が立っており、向こうから他のアバターＡ２がこちら側に歩いてきている。なお、この状況では、アバターＡ１とアバターＡ２は、初対面であるか、又は未だ打ち解けた関係でないものとする。また、この状況では、アバターＡ１とアバターＡ２は、それぞれに対応付けられている文字情報に基づいて、同じこと（例えば音楽、バンドなど）に興味があるものとする。図５では、所定の発動条件が満たされることで、リアクション主体のアバターであるアバターＡ１は、自動リアクションとして、手を上げて挨拶する動作を行っている。

図４及び図５に示すような場面では、所定の発動条件は、アバターＡ１に対応付けられている文字情報と、アバターＡ２に対応付けられている文字情報との関係が所定関係である場合に満たされてよい。この場合、所定関係は、両者に対応付けられている文字情報が共通点を有する関係を含んでよい。以下では、このようにして文字情報同士の関係に基づいて成否が判定される所定の発動条件を、「所定の第１発動条件」とも称する。

このようにして自動リアクションがアバターＡ１により行われると、リアクション主体のアバターＡ１が視野に入るように、アバターＡ２に係る仮想カメラの視野が変更されてもよい。すなわち、リアクション主体のアバターＡ１がよく見えるようなアバターＡ２の視点変更が実現されてもよい。あるいは、自動リアクションが開始されると、リアクション主体のアバターＡ１の位置を知らせる案内情報が、アバターＡ２に対して生成されてもよい。かかる仮想カメラの視野の変更や案内情報は、メタバース空間において有効となる。すなわち、視点の変更の自由度を高くすることによって、表示される情報量の多いメタバース空間では、視野の変更や案内情報が有効となる。

このようしてリアクション主体のアバターＡ１に、アバターＡ２が気付くことで、アバターＡ１とアバターＡ２と間の交流が促進される。この際、アバターＡ１とアバターＡ２は、それぞれに対応付けられている文字情報に基づいて、同じこと（例えば音楽、バンドなど）に興味があるので、話をすれば友達になれる可能性が高く、交流を効率的に促進できる。また、共通する文字情報（ひいては共通の嗜好）をもつアバター（ユーザ）が見つけやすくなることで、各ユーザの仮想空間の利用頻度や利用の継続率を、効果的に高めることができる。

また、図４及び図５に示すような場面では、リアクション主体のアバターＡ１に対して、アバターＡ２が自動リアクションを返すこととしてもよい。この場合、自動リアクションが一方通行とならず、交流を効率的に促進できる。

本実施形態において、自動リアクションがアバターＡ１により行われる際に、アバターＡ１の頭上等に対応付けてタグ情報（図５では、＃ｂａｎｄ、＃ｍｕｓｉｃ、＃ｄｒｕｍ）が表示されてもよい。タグ情報は、アバターＡ２にだけ認識可能となる態様で表示されてよいし、他の周辺アバターにも認識可能となる態様で表示されてもよい。タグ情報は、文字情報の一部又は全部であってもよいし、文字情報の一部又は全部に基づいて変換や加工等を介して生成されてもよい。共通するタグ情報に加えて共通していないタグ情報が表示されている場合には、共通するタグ情報が際立つように表示されてもよい。また、表示されるタグ情報は、アバターＡ２と共通のタグ情報だけであってもよい。いずれの場合も、アバターＡ２は、アバターＡ１と初対面であっても、アバターＡ１と自分との共通点等をすぐに認識できるので、その後の会話等の促進を図ることができる。なお、かかるタグ情報の表示は、自動リアクション自体として又は自動リアクションの一環として実行されてもよい。あるいは、かかるタグ情報は、自動リアクションがアバターＡ１により行われる前（図３参照）から表示されてもよい。

また、自動リアクションがアバターＡ１により行われる際に、アバターＡ１の頭上等に対応付けてメッセージ情報（図５では、“Ｂｅ ａ ｆｒｉｅｎｄ”）が表示されてもよい。この場合、かかるメッセージ情報の内容は、自動的に決定されてもよいし、事前にアバターＡ１により設定されてもよい。いずれの場合も、これにより、アバターＡ２は、アバターＡ１の意図（すなわちアバターＡ１が行った自動リアクションの意図）を容易に把握できるので、その後の会話等の促進を図ることができる。なお、かかるメッセージ情報の表示は、自動リアクション自体として又は自動リアクションの一環として実行されてもよい。

なお、図４及び図５に示す例では、自動リアクションは、手を上げて挨拶する動作であるが、実行される自動リアクションの種類は、これに限られない。自動リアクションは、相手アバターに対して好意的な反応を含む複数種類の動作のうちから所定ルールに基づいて選択（決定）されてもよい。例えば、自動リアクションの種類は、アバターＡ１とアバターＡ２に対応付けられている文字情報に応じて決定されてもよい。例えば、自動リアクションの種類は、アバターＡ１又はアバターＡ２に対応付けられているすべての文字情報のうちの、上述した所定関係を有する文字情報に応じて決定されてもよい。この場合、アバターの個性に応じた自動リアクションが可能となり、自動リアクションの多様性とともに自動リアクションへのアバターの個性の反映を図ることができる。

また、自動リアクションは、互いの文字情報の共通性の強さに応じて変化されてもよい。例えば、図４及び図５に示す例において、アバターＡ１に対応付けられている文字情報と、アバターＡ２に対応付けられている文字情報との関係が、第１の所定関係である場合と、第２の所定関係である場合とで、自動リアクションが異なってもよい。例えば、第２の所定関係である場合、第１の所定関係である場合よりも、自動リアクションが、目立つ態様に強調されてもよい。例えば、第１の所定関係である場合は、自動リアクションは、手を上げて挨拶する動作であるのに対して、第２の所定関係である場合は、自動リアクションは、手を上げて手を振りながら挨拶する動作であってもよい。あるいは、同じ手を振る動作であっても、第２の所定関係である場合は、第１の所定関係である場合よりも、大きく手を振る動作であってよい。いずれの場合、第２の所定関係は、第１の所定関係よりも、文字情報に共通点が多い関係（例えば、後述する文字間距離が近い関係）であってよい。

図６及び図７には、自動リアクションが実行されうる他の一シーンが示されている。この場合、学校の体育館のようなところで、舞台の上でアバターＢ５が特定行動（この場合、サッカーボールのリフティング）を行っており、そのそばに４人のアバターＢ１からＢ４が立っている。なお、この状況では、アバターＢ５とアバターＢ１からＢ４は、初対面であるか、又は未だ打ち解けた関係でないものとする。また、この状況では、アバターＢ１からＢ４のうちの、アバターＢ２とアバターＢ３は、それぞれに対応付けられている文字情報に基づいて、アバターＢ５の特定行動（例えばサッカー又はスポーツ全般）に興味があるものとする。図７では、アバターＢ２とアバターＢ３に関してのみ所定の発動条件が満たされることで、リアクション主体のアバターであるアバターＢ２とアバターＢ３は、相手アバターであるアバターＢ５に対して、自動リアクションとして、拍手する動作を行っている。

図６及び図７に示すような場面では、所定の発動条件は、アバターＢ５の特定行動の属性と、アバターＢ２又はアバターＢ３に対応付けられている文字情報との関係が所定関係である場合に満たされてよい。この場合、所定関係は、特定行動の属性と文字情報とが共通点を有する関係を含んでよい。以下では、このようにして特定行動の属性と文字情報の関係に基づいて成否が判定される所定の発動条件を、上述した所定の第１発動条件と区別するために、「所定の第２発動条件」とも称する。また、図示はしていないが、次のような発動条件を「所定の第３発動条件」としてもよい。すなわち、第１発動条件が文字情報同士の関係が所定関係である場合、第２発動条件が特定行動と文字情報の関係が所定関係である場合を発動条件とするのに対し、第３発動条件は、特定行動と特定行動の関係が所定関係である場合を発動条件とするものである。例えば、第３発動条件による自動リアクションは、図６及び図７の例を取れば、アバターＢ３がアバターＢ５と共に特定行動（この場合、サッカーボールのリフティング）を行って特定行動が終了した後に、お互いを見て挨拶をしたり、会話が終了して無音になった瞬間（例えば会話の切れ目）に頷きをしたり、お互いに他方に対して拍手をしたりという動作である。このほかにも、アニメーション制御に使用するステートマシンの変更や、特定のステートになったときに検出してタイミングよく同じステートを出したり、対象となるアバターＢ３とアバターＢ５の特定行動終了後に、周囲のアバターＢ２が拍手をしたりするようにしてもよい。

このようにして自動リアクションがアバターＢ２とアバターＢ３により行われると、アバターＢ２とアバターＢ３が視野に入るように、アバターＢ５に係る仮想カメラの視野が変更されてもよい。すなわち、リアクション主体のアバターＢ２とアバターＢ３がよく見えるようなアバターＢ５の視点変更が実現されてもよい。あるいは、自動リアクションが開始されると、リアクション主体のアバターＢ２とアバターＢ３の位置（又は拍手しているアバターＢ２、Ｂ３の存在）を知らせる案内情報が、アバターＢ５に対して生成されてもよい。かかる仮想カメラの視野の変更や案内情報は、メタバース空間において有効となる。すなわち、前述したように、視点の変更の自由度を高くすることによって、表示される情報量の多いメタバース空間では、視野の変更や案内情報が有効となる。

このようしてリアクション主体のアバターＢ２とアバターＢ３に、アバターＢ５が気付くことで、アバターＢ２及びアバターＢ３とアバターＢ５と間の交流が促進される。この際、アバターＢ２及びアバターＢ３とアバターＢ５は、それぞれに対応付けられている文字情報に基づいて、同じこと（例えばサッカー又はスポーツ全般）に興味があるので、話をすれば友達になれる可能性が高く、交流を効率的に促進できる。

また、図６及び図７に示すような場面では、自動リアクションがアバターＢ２により行われると、アバターＢ２が視野に入るように、アバターＢ３に係る仮想カメラの視野が変更されてもよい。あるいは、拍手している他のアバターＢ２の存在を知らせる案内情報が、アバターＢ３に対して生成されてもよい。これは、逆も同様である。すなわち、自動リアクションがアバターＢ３により行われると、アバターＢ３が視野に入るように、アバターＢ２に係る仮想カメラの視野が変更されてもよい。あるいは、拍手している他のアバターＢ３の存在を知らせる案内情報が、アバターＢ２に対して生成されてもよい。これにより、アバターＢ２とアバターＢ３との間の交流の促進を図ることができる。すなわち、アバターＢ２とアバターＢ３は、それぞれに対応付けられている文字情報に基づいて、同じこと（例えばサッカー又はスポーツ全般）に興味があるので、話をすれば友達になれる可能性が高く、交流を効率的に促進できる。また、共通する嗜好をもつアバター（ユーザ）が見つけやすくなることで、各ユーザの仮想空間の利用頻度や利用の継続率を、効果的に高めることができる。

なお、図６及び図７に示す例では、自動リアクションは、拍手する動作であるが、自動リアクションの種類は、これに限られない。特定行動に対する自動リアクションは、相手アバターに対して好意的な反応を含む複数種類の動作のうちから所定ルールに基づいて選択（決定）されてもよい。例えば、自動リアクションの種類は、特定行動の属性に応じて決定されてもよい。例えば、この場合、特定行動がサッカーボールのリフティングであるので、自動リアクションは、サッカー系やスポーツ系の自動リアクションであってもよい。あるいは、自動リアクションの種類は、アバターＢ２又はアバターＢ３に対応付けられているすべての文字情報のうちの、アバターＢ５の特定行動の属性と所定関係を有する文字情報に応じて決定されてもよい。この場合、アバターの個性に応じた自動リアクションが可能となり、自動リアクションの多様性とともに自動リアクションへのアバターの個性の反映を図ることができる。

ここで、一のアバターの特定行動は、当該一のアバターに対応するユーザに係るトラッキング情報（例えばモーションキャプチャによる各部位のトラッキング情報）に基づいて実行（描画）されてもよいが、好ましくは、アニメーションデータを利用して描画される。この場合、ユーザのすべての動きをトラッキングする必要がないため処理負荷を低減することができ、効率的に各アバターの特定行動を表現（描画）できる。

ところで、本実施形態では、上述したような自動リアクションは、上述したように、所定の発動条件が満たされた場合に実行される。自動リアクションは、上述したように、アバター間の交流を図るために有効な反面、処理負荷を増加させる背反がありうる。従って、所定の発動条件の成否は、効率的に判定されることが望ましい。

このため、所定の発動条件の成否は、好ましくは、文字情報に基づく文字間距離を利用して判定される。例えば、リアクション主体のアバターに係る所定の発動条件が、リアクション主体のアバターに対応付けられている文字情報と、相手アバターとなりうる他のアバターに対応付けられている文字情報との関係が所定関係である場合に満たされる構成においては、所定関係の有無は、文字情報に基づく文字間距離を利用して判定されてもよい。この場合、例えばＷｏｒｄ２ｖｅｃのような自然言語処理における単語の埋め込みが利用されてもよい。Ｗｏｒｄ２ｖｅｃの場合、文字情報に含まれる各文字（単語）のうちの、ベクトル空間内で近くに配置される単語ベクトル同士は、所定関係を有すると判定されてもよい。このような自然言語処理を利用することで、所定関係の有無（及びそれに伴い所定の発動条件の成否）を効率的に判定できる。また、各種多様な種類の言語に対しても、所定の発動条件の成否を効率的に判定できる。

例えば、図４及び図５に示すような場面では、所定関係は、上述したように、アバターＡ１に対応付けられている文字情報と、アバターＡ２に対応付けられている文字情報との間の文字間距離（関係）が、所定距離内である関係を含んでよい。Ｗｏｒｄ２ｖｅｃの場合、それぞれの文字情報に含まれる各文字（単語）のうちの、ベクトル空間内で近くに配置される単語ベクトルが１組又は複数組存在する場合、所定の第１発動条件が成立してよい。

また、図６及び図７に示すような場面では、所定の第２発動条件は、上述したように、アバターＡ５の特定行動に関連する文字と、アバターＢ１からＢ４のそれぞれに対応付けられている文字情報との間の文字間距離（関係）が、所定関係として所定距離内であるか否かが判定されてよい。Ｗｏｒｄ２ｖｅｃの場合、アバターＢ１からＢ４のそれぞれごとに、アバターＡ５の特定行動に関連する文字に対して、それぞれの文字情報に含まれる各文字（単語）のうちの、ベクトル空間内で近くに配置される単語ベクトルが１組又は複数組存在するかが判定されてもよい。

文字間距離の算出に利用される文字情報は、タグ情報を含んでよい。図８には、複数のアバターに対応付けられているタグ情報の一例が示されている。図８において、ｔａｇ［アバターＣ１］は、アバターＣ１に対応付けられているタグ情報を表す。また、図８において、［＊＊＊、１００］といった情報は、“＊＊＊”は、文字であり、例えば図８に示すような絵文字であってもよい。絵文字の場合、世界共通となりえ、利便性が向上する。また、“１００”といった数値は、当該文字に対応付けられている重みを表し、重みが大きいほど、当該アバターの嗜好を強く表すことを意味する。従って、重みが大きい文字同士の“距離”が近いほど共通性が高くなる態様で、重みが利用されてよい。この場合、アバターＣ１とアバターＣ２とは、タグ情報に基づく文字間距離（関係）が近く、所定の発動条件が成立しやすい。

このようにして、タグ情報に基づく所定の発動条件は、タグ情報同士が所定関係を有する場合に満たされてよい。この場合、所定関係は、多段階で可変されてもよい。例えば、所定関係は、最も厳しい関係として、タグ情報に係る文言の完全一致を表してもよいし、より緩やかな関係として、タグの意味も考慮してよい。例えば、＃ｍｕｓｉｃと＃ｓｉｎｇｅｒは所定関係を有すると判定されてもよい。また、タグ情報に基づく所定の発動条件は、多言語で横断的に照合されてもよい。この場合、例えば＃野球と＃ｂａｓｅｂａｌｌは所定関係を有すると判定されてもよい。

ここで、「名寄せと対象となる人数」について補足する。同じ意味を持つワード、例えば、＃ｂａｓｅｂａｌｌ，＃ベースボール，＃プロ野球，＃野球，＃◎（ボールマーク）は、それぞれ異なる言語や文化によって分離されたほうが良い場合もあるが、名寄せされ、より近い興味を持つものが積極的に視野に入り、円滑に出会うように設計されたほうが良い場合もある。この条件は言語や文化圏といった分類でデータベースを構築する方法もあるが、出会わせたい対象となるユーザの数によって調整する方法も合理的である。例えば、日本語ネイティブ話者とそれ以外が５人ずつ、合計１０名がログインしているワールドで野球関連の趣味をもつユーザを効率的にグルーピング（名寄せ）したい場合、５名対５名という形で、そのグループを意味空間で２分する直線を想定することができ、その直線によって分離される言語／ワードで分けることができる。例示した１０名のユーザについていえば、そのうち日本語話者である５名が｛ベースボール，プロ野球，野球｝、それ以外の５名が｛＃ｂａｓｅｂａｌｌ，＃◎（ボールマーク），＃ＭＬＢ｝などのタグになり、前者を積極的にグルーピング（名寄せ）することが合理的となる。なお、この分離は、機械学習では、ＳＶＭ：Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ等の一般的アルゴリズムで行うことができる。

なお、このようなタグ情報は、文字間距離の算出に利用される以外にも、図５を参照して上述したように、アバターの頭上等に対応付けて表示されることで、アバター間の交流の促進に利用できる。例えば、一のアバターに対応付けられているタグ情報は、以下の条件要素Ｃ１からＣ４等のいずれか１つ又は２つ以上の任意の組み合わせで成立したときのみ、他の一のアバターに向けて表示されてもよい。
条件要素Ｃ１：一のアバターと他の一のアバターに、共通するタグ情報が対応付けられていること。
条件要素Ｃ２：一のアバターと他の一のアバターとが所定位置関係であること。
条件要素Ｃ３：一のアバターと他の一のアバターとが、特定の親密関係であること。
条件要素Ｃ４：他の一のアバターが一のアバターを指定して、タグ情報の表示を要求したこと。
ここで、条件要素Ｃ２において、所定位置関係は、上述した第１所定位置関係と同様に、所定距離内であることや、相手アバターとなりうる他のアバターから一のアバターが見える位置関係（すなわち他の一のアバターから一のアバターが見える位置関係）等を含んでよい。また、条件要素Ｃ３において、特定の親密関係は、一方が他方のフレンド情報としてユーザ情報（後述）に登録されている関係や、双方が互いにフレンド情報としてユーザ情報（後述）に登録されている関係、フォロワーとフォロイーとしてユーザ情報（後述）に登録されている関係、又はこれらの任意の組み合わせ等を含んでよい。

なお、初心者モードが存在する仕様である場合、初心者モードが設定されているアバターに対しては、タグ情報が頭上等に対応付けて表示されてもよい。この場合、タグ情報は、初心者マークを含んでよい。あるいは、初心者マークは、アバターの衣装等に付与されてもよい。なお、初心者モードを熟練したユーザが選ぶこともできるがその時は自分のアバターと名前も表示されてよい。ここで、初心者モードのほかに、中級者モードや上級者モードなど、複数のモードが設定される場合には、各モードは、ユーザが手動で選択できるよういしてもよいし、サービスに登録してからの日数やログイン回数に応じて自動的に設定されるようにしてもよい。

条件要素Ｃ４を含む条件の成立に伴って、一のアバターに対応付けられているタグ情報が、他のアバターに対して表示された場合、当該一のアバターに対して、その旨を表す情報がフィードバックされてもよい。この場合、フィードバックは、タグ情報が見られている旨の表示及び／又は振動（例えば入力部２４の振動）等を介して実現されてもよい。これは、タグ情報に限らず、プロフィール情報等についても同様であってよい。

ところで、上述した自動リアクションは、上述したように低減された処理負荷で、仮想空間内でのアバター間の交流を促進できるものの、仮想空間内のアバター密度が高くなると、その分だけ自動リアクションの頻度が高くなりやすく、それに応じて処理負荷が高くなるおそれがある。

そこで、本実施形態においては、アバター間での交流は、自動的に及び／又はユーザ設定に基づいて、制限可能とされてもよい。

アバター間での交流の制限方法は、ブロックフラグやミュートフラグといった制限フラグを利用して実現されてもよい。ブロックフラグやミュートフラグのような制限フラグは、アバターごとに、他のアバターに対応付けて管理されてよい。図９は、制限フラグの説明図であり、図９には、アバターＤ１に関して、他のアバターＤ２、Ｄ３、Ｄ４に対応付けられている制限フラグの状態の一例が示されている。図９に示す制限フラグは、図９の下側に模式的に示すように、アバターＤ１により設定された状態である。この場合、アバターＤ１は、他のアバターＤ２、Ｄ３、Ｄ４等との交流の制限フラグを任意に設定可能である。図９の状態では、アバターＤ１は、アバターＤ２に対しては、ミュートフラグをオンしており、アバターＤ３に対しては、ブロックフラグ及びミュートフラグのいずれもオンしておらず、アバターＤ４に対しては、ブロックフラグをオンしている。

この場合、ミュートフラグ＝オンのアバターＤ２は、アバターＤ１にとっては実質的に存在しないアバターであり、見ることも話しかけることもできないし、その声も聞こえない。すなわち、アバターＤ２は、アバターＤ１が活動する仮想空間内のリスト（閲覧可能なユーザ台帳）には載っていないアバターである。従って、アバターＤ１及びアバターＤ２間での交流の促進は不要であり、自動リアクションが互いに対して実行されることない。これにより、アバターＤ１及びアバターＤ２間に関して、自動リアクションを実行するための各種処理（例えば第１所定位置関係の判定や所定の発動条件の成否の判定等）が不要となり、処理負荷を効率的に低減できる。また、アバターＤ１にとっても、交流したくないアバターを設定に基づいて“存在しないアバター”にすることができ、利便性が向上する。

ここで、ミュートとブロックについて、補足する。アバターＤ１はミュートやブロックを利用するアバター、アバターＤ２ミュートやブロックされるアバターであるが、アバターＤ１の自動リアクションは、アバターＤ２に対しては発動しない。まず、ミュートについていえば、アバターＤ１からアバターＤ２のアバターは見えなくなる一方、アバターＤ２からアバターＤ１は見える。換言すると、アバターＤ２は、アバターＤ１が自動リアクションを行うか否かの判定の対象とならない。音声会話についても、アバターＤ１の発話はアバターＤ２聞こえる一方、アバターＤ２からの発話はアバターＤ１には聞こえない。文字チャットについても、アバターＤ１からアバターＤ２の発言テキストは表示されないし、メンションや通知も処理されない。アバターＤ２はアバターＤ１を視聴するのみであり、インタラクションの一切は許可されないが、アバターＢ２は自分がミュートされている事を認知する必要はない。アバターＤ１は、ミュート対象リストからアバターＤ２のミュートを、任意のタイミングで解除してよい。次に、ブロックについていえば、アバターＤ１は、アバターＤ２を明示的に拒絶する。アバターＤ１がアバターＤ２をブロック対象リストから削除するまで、アバターＤ２はアバターＤ１を検索できない、すなわち、アバターＤ２にとってアバターＤ１は存在しないアバターとなる。両アバターが同じワールドにいても、アバターＤ２の端末装置２０には、アバターＤ１は表示されないし、発話やテキストも表示されないこととなる。なお、ミュートとブロックは、各アバター（ユーザ）の嗜好や経験に応じて設定されてもよいし、デフォルト設定として広く設定されてもよい。また、ミュートとブロックは、仮想現実を提供する運営者により、通信制御、フェスティバルなどのイベント、初心者ユーザ向けのチュートリアル（個別指導）などの目的に応じて設定されてもよいし、さらには、自動リアクションを描画するＣＧ空間を考慮して、前述したアバター間の興味の距離ＬｏＩに応じて動的に制御されてもよい。

他方、ブロックフラグ＝オンのアバターＤ４は、アバターＤ２とは異なり、アバターＤ１にとっては存在するアバターであるが、アバターＤ４は、アバターＤ１に対して話しかけたり、近づいたりする等の交流を行うことができない。また、アバターＤ４は、アバターＤ１のプロフィール情報やタグ情報を閲覧することができない。例えば、アバターＤ４は、アバターＤ１のタグ情報に関して、上述した条件要素Ｃ４が満たされることはない。また、アバターＤ１及びアバターＤ４間での交流の促進は実質的に不要であり、自動リアクションが互いに対して実行されることない。これにより、アバターＤ１及びアバターＤ４間に関して、自動リアクションを実行するための各種処理が不要となり、処理負荷を効率的に低減できる。なお、アバターＤ４は、アバターＤ１が自身に対してブロックフラグをオンしていることを認識可能であってよい。

このようにして制限フラグを利用する場合、自動リアクションは、交流促進効果が高いアバター間だけで実行されやすくなる。これにより、自動リアクションの実行機会を不要に制限することなく、処理負荷を効率的に低減できる。

本実施形態において、制限フラグのオン／オフ状態は、対応するユーザによるユーザ入力に応じて変更可能であってもよいし、及び／又は、文字情報に基づいて自動的に変更されてもよい。例えば、この場合、例えば、一のアバターに対応付けられている文字情報が、嫌いなこととして“自慢話”を含む場合、自慢話が多いアバターによる当該一のアバターへの交流が制限されてもよい。なお、一のアバターについて自慢話が多いか否かは、当該一のアバターに係る会話／発語情報に基づいて判定されてもよい。

また、本実施形態において、自動リアクションは、仮想空間内のアバター密度のような、処理負荷に応じて制限されてもよい。例えば、仮想空間内のアバター密度が高い領域（例えばコンサートイベント会場等）においては、上述した自動リアクションが制限されてもよい。この場合、自動リアクションの機能がオフされてもよいし、所定の発動条件が成立し難くなる方向に所定の発動条件が自動的に変更されてもよい。例えば、仮想空間内のアバター密度が高い領域において、一のアバターに対応付けられている文字情報と、所定数を超えるアバターに対応付けられている文字情報との関係が、第１の所定関係である場合、処理負荷が有意に高くなるとする。この場合、所定数を超えるアバターのうちの、第２の所定関係となる文字情報が対応付けられているアバターに対してのみ、自動リアクションが実行されてもよい。なお、この場合、第２の所定関係は、第１の所定関係よりも、文字情報に共通点が多い関係であってよい。あるいは、仮想空間内のアバター密度が高い領域において、一のアバターに対応付けられている文字情報と、所定数を超えるアバターに対応付けられている文字情報との関係が所定関係である場合は、所定数を超えるアバターのうちの、ランダムに又は所定ルールに従って選択されたアバターに対してのみ、自動リアクションが実行されてもよい。以上のほか、自動リアクションは、仮想空間内の領域の性質に応じて制限されてもよい。例えば、バーチャルシネマのような会場において、観客の会話が許容されるロビーでは自動リアクションの機能がオン、観客がシネマに集中するシアタールームでは、たとえ客席に空席が目立っても、自動リアクションの機能がオフとされてもよい。

次に、図１０以降を参照して、上述したアバターの自動リアクションに関連したサーバ装置１０及び端末装置２０のそれぞれの機能的な構成例について説明する。

図１０は、上述した自動リアクションに関連したサーバ装置１０の機能を示す概略的なブロック図である。図１１は、自動リアクション関連データ記憶部１４２内のデータの一例を示す説明図である。図１２は、ユーザ情報記憶部１４４内のデータの一例を示す説明図である。図１３は、プロフィール情報の説明図である。図１４は、アバター情報記憶部１４６内のデータの一例を示す説明図である。なお、図１１（以下の同様の図１２等も同様）において、「＊＊＊」は、なんらかの情報が格納されている状態を示し、「・・・」は、同様の情報の格納の繰り返し状態を示す。

サーバ装置１０は、図１０に示すように、自動リアクション関連データ記憶部１４２、ユーザ情報記憶部１４４、アバター情報記憶部１４６、ユーザ入力取得部１５０、アバター処理部１５２、対応付け処理部１５３、交流制限処理部１５４、発動条件判定部１５５、リアクション種別決定部１５６、パラメータ算出部１５８、視野処理部１６０、及びユーザ情報開示制御部１６２を含む。

なお、図１０において、自動リアクション関連データ記憶部１４２、ユーザ情報記憶部１４４、及びアバター情報記憶部１４６は、図１に示したサーバ装置１０のサーバ記憶部１２により実現できる。また、ユーザ入力取得部１５０からユーザ情報開示制御部１６２の各部の機能は、図１に示したサーバ装置１０のサーバ制御部１３やサーバ通信部１１により実現できる。

自動リアクション関連データ記憶部１４２には、上述した各自動リアクションに関連した自動リアクション関連データが記憶される。自動リアクション関連データは、例えば図１１に示すように、自動リアクションＩＤごとに、自動リアクション属性、発動条件情報、アニメーションデータ、及び再生用情報を含んでよい。

自動リアクションＩＤは、各自動リアクションの生成時に自動的に生成されるＩＤである。自動リアクション属性は、自動リアクションの属性を表し、自動リアクションの属性は、挨拶や称賛等のような自動リアクションの意図に関する情報を含んでよい。

発動条件情報は、上述した所定の発動条件を表す情報を含んでよい。なお、発動条件情報は、自動リアクションＩＤごとに異なってもよいが、好ましくは、複数の自動リアクションＩＤに対して同じ（共通）である。この場合、ある一の所定の発動条件が成立した場合、複数の自動リアクションＩＤのうちのいずれか１つ以上に係る自動リアクションＩＤに係る自動リアクションが実行可能となり、自動リアクションの多様化を図ることができる。

アニメーションデータは、上述した自動リアクションの描画用のアニメーションデータを含む。アニメーションデータは、上述したように、リアクション主体のアバターの所定部位の動きだけに関するデータであってよい。この場合、アニメーションデータは、複数のアバター間で共用できるように生成でき、データの効率化を図ることができる。なお、アニメーションデータは、実際の人（ユーザ）が自動リアクションに係る実際の動作を行った際に得られるトラッキング情報に基づいて生成されてよい。また、アニメーションデータは、アバターの型（Ｆ型＜女性型＞、Ｍ型＜男性型＞など）や属性（性格別、年齢別（世代別）など）に応じて選択されてもよい。

再生用情報は、アニメーションデータの再生の開始タイミングや再生の終了タイミングを表す基本情報を含む。なお、アニメーションデータの再生の開始タイミングは、リアクション主体のアバターと相手アバターとの間の距離で規定されてもよい。あるいは、アニメーションデータの再生の開始タイミングは、所定の発動条件が満たされたと判定されるタイミングと同期してよく、例えば、当該判定のタイミングと実質的に同じであってもよい。

ユーザ情報記憶部１４４には、各ユーザに関する情報が記憶される。各ユーザに関する情報は、例えばユーザ登録時に生成されてよく、その後、適宜、更新等されてよい。例えば、図１２に示す例では、ユーザ情報記憶部１４４には、ユーザＩＤごとに、ユーザ名、アバターＩＤ、プロフィール情報、会話／発語情報、活動情報、文字情報（タグ情報）、フレンド情報、好み情報、制限フラグ情報、アイテム情報、及び自動リアクション可否情報が対応付けられている。

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

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

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

なお、上述したように一のユーザに対して、複数のアバターＩＤが対応付け可能であってもよい。この場合、アバターＩＤごとに、プロフィール情報、会話／発語情報、活動情報、文字情報、フレンド情報、好み情報、制限フラグ情報、アイテム情報、及び自動リアクション可否情報が対応付けられてもよい。

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

なお、本実施形態では、プロフィール情報は、その更新態様（更新頻度や更新量等）を表す情報を含んでよい。なお、プロフィール情報の更新態様は、アバターごとに異なりうり、比較的高い頻度で更新するアバターも存在すれば、一度きりで全く更新しないアバターも存在しうる。

会話／発語情報は、対応するアバターが仮想空間内において発話した際の発話内容に関する情報を表す。会話／発語情報は、アバター間の会話に係る会話情報と、会話以外の発語（例えば独り言や配信での発語）に係る発語情報とを含んでよい。この場合、会話／発語情報は、会話情報と発語情報とが別々に管理されてもよいし、同様に管理されてもよい。会話／発語情報は、テキスト化されたデータであってよい。また、会話／発語情報は、どの言語を話すかを表す情報（例えばロケールＩＤ）を含んでもよい。また、会話／発語情報は、一人称の呼び方、言葉遣い、方言等に関する情報を含んでもよい。また、会話／発語情報は、加工前の生データ（すなわち生発話ログ）であってもよいが、テキスト化（文字に変換された）データを含んでもよい。後者の場合、記憶領域の効率化を図ることができる。

また、会話／発語情報は、キーワード情報を含んでよい。この場合、キーワード情報は、例えば、対応するユーザが入室したトークルームで行われていた会話におけるキーワードを表す情報であってよい。キーワード情報は、Text-to-Speech(TTS)等を利用して生成されてもよい。キーワード情報は、ユーザの好み等を精度良く表す可能性があり、後述する対応付け処理部１５３での処理等で利用されてもよい。

活動情報は、仮想空間における各種活動履歴や行動履歴を表す情報を含む。各種活動は、イベント参加及びイベント主催等のような特別な活動のみならず、仮想空間へのアクセスや仮想空間内の滞在時間等のような、通常的な活動（行動）をも表す情報を含んでよい。また、各種活動は、仮想空間におけるオブジェクトの制作活動等を含んでもよい。

文字情報は、上述したとおりであり、アバターの嗜好等を表してよい。文字情報は、ユーザからの入力等に応じて更新されてよい。また、文字情報は、会話／発語情報や行動履歴等に基づいて自動的に抽出されてもよい。また、一のアバターに対応付けられている文字情報の一部又は全部は、図４及び図５等を参照して上述したように、当該一のアバターに対応付けて、タグ情報の形式で表示可能とされてよい。あるいは、逆に、タグ情報が文字情報として機能してもよい。また、文字情報は、メタデータの形態であってもよい。

フレンド情報は、フレンド関係にあるユーザを特定可能な情報（例えばユーザＩＤ）であってよい。フレンド情報は、上述したようにフォロワー等の情報を含んでよい。フレンド情報は、過去の会話の相手の情報や、過去の自動リアクションを行った相手アバターの情報、ユーザ間の交流や交友の有無や度合いを表す情報等を含んでよい。

好み情報は、対応するユーザの好みであって、好み全般や、会話（例えばトークテーマ）に関連する好みを表してよい。好み情報は、任意であるが、ユーザの好む言語設定や、好むキーワードを含んでよい。また、ユーザがあらかじめ自分の好きな人や好きなこと、嫌いな人や嫌いなこと等、を設定することが可能であってよく、この場合、好み情報は、かかる設定内容を含んでよい。なお、好み情報は、ユーザプロフィール情報と同様の情報を含みうるので、ユーザプロフィール情報と統合されてもよい。

制限フラグ情報は、図９を参照して上述した制限フラグの設定状態を表す。なお、上述したように制限フラグの設定状態は、ユーザにより変更が可能とされてよい。

アイテム情報は、対応するユーザに対応付けられている所定アイテムを表す。所定アイテムは、上述した仮想現実媒体の一要素であり、ユーザの好みを表す仮想現実媒体であってよい。例えば、所定アイテムは、アバターアイテムや、各種楽器やボールなど任意のオブジェクト等を含んでもよい。

自動リアクション可否情報は、上述した自動リアクションの実行可否に関するユーザによる設定情報である。自動リアクション可否情報は、上述した自動リアクションの実行を望まないユーザと、望むユーザとを判別するために利用可能である。なお、ユーザは、場面や、状況、位置、日時ごとに、自動リアクションの実行可否を設定可能とされてもよい。

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

ユーザ入力取得部１５０は、端末装置２０の入力部２４を介して入力される各ユーザによる各種ユーザ入力を取得する。各種入力は、上述したとおりであり、モーションキャプチャで取得されたトラッキング情報を含んでよい。

アバター処理部１５２は、所定の発動条件が満たされた場合に、アバターに自動リアクションを行わせる。自動リアクションは、上述したとおりである。

アバター処理部１５２は、アバター動作処理部１５２１と、描画処理部１５２２を含む。

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

描画処理部１５２２は、アバターを含む仮想空間の画像であって、端末装置２０で視聴用の画像（端末用画像）を生成する。描画処理部１５２２は、各アバターに対応付けられる仮想カメラの撮像パラメータの各値（位置、視線方向、画角等）に基づいて、各アバター用の画像（端末装置２０用の画像）を生成する。なお、一のアバターに対応付けられる仮想カメラの撮像パラメータの各値は、基本的には（後述する視野処理部１６０による介入時を除いて）、当該一のアバターの視野関連の各種パラメータの各値（例えば目の位置、視線方向、視力等）に対応してよい。本実施形態では、描画処理部１５２２は、自動リアクションを行う際のアバターを描画する。この場合、描画処理部１５２２は、図１１に示した自動リアクション関連データ記憶部１４２内の自動リアクション関連データに基づいて、低減された処理負荷で、自動リアクションを行うアバターを描画できる。

対応付け処理部１５３は、各アバターに、対応するユーザ又はアバター自身の嗜好や性格（以下、「嗜好」で代表する）に関連した文字情報を対応付ける。本実施形態では、対応付け処理部１５３は、ユーザ情報記憶部１４４内のユーザ情報を生成及び更新することで、各アバターに、対応するユーザ又はアバター自身の嗜好に関連した文字情報を対応付ける。

対応付け処理部１５３は、例えば、対応するユーザにより指定される文字情報を、各アバターに対応付けてもよい。あるいは、対応付け処理部１５３は、対応するユーザ又はアバター自身の嗜好に関連した各種情報に基づいて、当該各種情報に応じた文字情報を、各アバターに対応付けてもよい。図１２に示す例では、対応するユーザ又はアバター自身の嗜好に関連した各種情報は、プロフィール情報、フレンド情報、及び好み情報を含む。また、会話／発語情報、活動情報、及びアイテム情報は、対応するアバターの嗜好を表しうる。従って、対応するユーザ又はアバター自身の嗜好に関連した各種情報は、会話／発語情報、活動情報、及びアイテム情報のうちの、少なくともいずれか１つを含んでもよい。

なお、このようにして対応付け処理部１５３により対応付けられる文字情報は、対応するユーザにより手動で編集等の修正が可能とされてもよい。

交流制限処理部１５４は、アバターごとに、対応する一のアバターに対応付けられている文字情報等に基づいて、当該一のアバターと交流可能な他のアバター（相手アバターとなりうる他のアバター）を決定する。例えば、交流制限処理部１５４は、一のアバターに対応付けられているプロフィール情報、一のアバターによる会話／発語情報、一のアバターに対応付けられているアイテム情報、及び、一のアバターによる仮想空間における行動履歴のうちの少なくともいずれか１つに基づいて、一のアバターと交流可能な他のアバターを決定してよい。

例えば、行動履歴に基づく場合、特定のネガティブなエモートやネガティブなギフトを贈る傾向が強いアバターや、他のアバターに迷惑をかける傾向にあるアバター、また、当該他のアバターや第三のアバターから、特定行動に対するリアクションがルールやマナーに違反しているとして、注意、警告や通報されたことが所定回数以上なされたことがあるアバターは、他のアバターと交流が不能なアバターとされてもよい。また、行動履歴に基づく場合、サービス内通貨の消費（課金状況）等に基づいて、課金が多いユーザに対しては、交流可能な他のアバターの範囲が拡大されてもよい。

この場合、交流制限処理部１５４は、対応する一のアバターに対応付けられている文字情報に基づいて、当該文字情報に対して、上述した自動リアクションに係る所定の発動条件を満たすような文字情報が対応付けられているアバターを、交流可能な他のアバターとして決定してもよい。

また、交流制限処理部１５４は、フレンド情報に基づいて、一のアバターのフォロワーが上述したミュートフラグやブロックフラグを設定しているアバターに対して、交流不能なアバターとして決定してもよい。すなわち、このようにして、一のアバターに係るフラグ制限情報は、当該一のアバターのフォロワーに対応付けられている同フラグ制限情報を承継してもよい。

このようにして交流制限処理部１５４は、一のアバターと交流可能な他のアバターを決定すると、ユーザ情報記憶部１４４内のユーザ情報のうちの、当該一のアバターに係る制限フラグ情報を生成又は更新する。なお、当該一のアバターに対応付けられている制限フラグ情報は、当該一のアバターに対応付けられているユーザによるユーザ入力に基づいて適宜変更可能とされてよい。

発動条件判定部１５５は、アバター間ごとに、上述した所定の発動条件の成否を判定する。

本実施形態では、発動条件判定部１５５は、判定対象決定部１５５０と、第１判定部１５５１と、第２判定部１５５２と、第３判定部１５５３とを含む。

判定対象決定部１５５０は、上述した所定の発動条件の判定対象となるアバターを決定する。

判定対象決定部１５５０は、第１判定対象決定部１５５０１と、第２判定対象決定部１５５０２とを含む。

第１判定対象決定部１５５０１は、アバターごとに、一のアバターをリアクション主体のアバターとしたときの、相手アバターとなりうる他のアバター（以下、「第１判定対象アバター」とも称する）を決定する。なお、リアクション主体のアバターは、上述したユーザ情報記憶部１４４内のユーザ情報の自動リアクション可否情報に基づいて、自動リアクションの実行を望むアバターのみに限定されてもよい。この場合、発動条件判定部１５５に係る処理負荷を効率的に低減できる。

第１判定対象決定部１５５０１は、一のリアクション主体のアバターに関して、第１判定対象アバターを、当該一のリアクション主体のアバターに対する位置関係に基づいて、限定してもよい。例えば、第１判定対象決定部１５５０１は、一のリアクション主体のアバターに対する位置関係が、上述した第１所定位置関係である他のアバターだけを、第１判定対象アバターとして限定してもよい。この場合、発動条件判定部１５５に係る処理負荷を効率的に低減できる。

また、第１判定対象決定部１５５０１は、一のリアクション主体のアバターに関して、第１判定対象アバターを、当該一のリアクション主体のアバターに係る制限フラグ情報に基づいて、限定してもよい。具体的には、第１判定対象決定部１５５０１は、当該一のリアクション主体のアバターに係る制限フラグ情報に基づいて、上述したミュートフラグやブロックフラグがオンとされていない他のアバターのみが第１判定対象アバターに含まれるように、第１判定対象アバターを限定してもよい。この場合、発動条件判定部１５５に係る処理負荷を効率的に低減できる。

第２判定対象決定部１５５０２は、一のアバターが上述した特定行動を行う場合に、リアクション主体のアバターとなりうるアバター（以下、「第２判定対象アバター」とも称する）を決定する。なお、この場合も、リアクション主体のアバターは、上述したユーザ情報記憶部１４４内のユーザ情報の自動リアクション可否情報に基づいて、自動リアクションの実行を望むアバターのみに限定されてもよい。この場合、発動条件判定部１５５に係る処理負荷を効率的に低減できる。

第２判定対象決定部１５５０２は、特定行動を行う一のアバターに関して、第２判定対象アバターを、当該特定行動を行うアバターに対する位置関係に基づいて、限定してもよい。例えば、第２判定対象決定部１５５０２は、特定行動を行うアバターに対する位置関係が、上述した第１所定位置関係である他のアバターだけを、第２判定対象アバターとして限定してもよい。この場合、発動条件判定部１５５に係る処理負荷を効率的に低減できる。

また、第２判定対象決定部１５５０２は、特定行動を行う一のアバターに関して、第２判定対象アバターを、当該特定行動を行うアバターに係る制限フラグ情報に基づいて、限定してもよい。具体的には、第２判定対象決定部１５５０２は、当該特定行動を行うアバターに係る制限フラグ情報に基づいて、上述したミュートフラグやブロックフラグがオンとされていない他のアバターのみが第２判定対象アバターに含まれるように、第２判定対象アバターを限定してもよい。この場合、発動条件判定部１５５に係る処理負荷を効率的に低減できる。

第１判定部１５５１は、一のアバターをリアクション主体のアバターとしたとき、第１判定対象決定部１５５０１により決定された第１判定対象アバターごとに、上述した所定の第１発動条件を判定する。所定の第１発動条件は、図４及び図５等を参照して上述したとおりである。

第２判定部１５５２は、一のアバターが上述した特定行動を行った場合に、第２判定対象決定部１５５０２により決定された第２判定対象アバターごとに、上述した所定の第２発動条件を判定する。所定の第２発動条件は、図６及び図７等を参照して上述したとおりである。

第３判定部１５５３は、リアクション主体のアバターと相手アバターに関するアバター間の位置関係が第１所定位置関係であるか否かを判定する。第１所定位置関係は、上述したとおりである。第３判定部１５５３は、例えば、リアクション主体のアバターと相手アバターに関するアバター間の距離、同アバター間の障害物（他のオブジェクト）の有無、相手アバターの視野内におけるリアクション主体のアバターの有無、及び、相手アバターの視野外にリアクション主体のアバターが位置する状態からリアクション主体のアバターの視野内に相手アバターが位置する状態への遷移が可能であるか否か、のうちの少なくともいずれか１つのパラメータに基づいて、判定を行ってよい。なお、障害物を考慮する場合は、当該障害物に起因して、相手アバターの視野内にリアクション主体のアバターが入るか否かが判定されてもよい。また、相手アバターの視野外にリアクション主体のアバターが位置する状態からリアクション主体のアバターの視野内に相手アバターが位置する状態への遷移は、後述する視野処理部１６０により処理により可能とされる遷移を含んでよい。

リアクション種別決定部１５６は、一のリアクション主体のアバターが上述した自動リアクションを行う場合に、その自動リアクションの種類を、選択可能な複数種類のうちから、選択する。本実施形態では、自動リアクションは、複数種類用意されているものとする。すなわち、図１１を参照して上述したように、複数の自動リアクションＩＤに対して同じ発動条件情報が対応付けられている。

リアクション種別決定部１５６による選択ルールは、任意であり、例えばランダムな選択ルールであってもよい。ただし、リアクション種別決定部１５６は、所定の第１発動条件を成立させた文字情報に基づいて、当該文字情報に応じた種類の自動リアクションを選択してよい。例えば、所定の第１発動条件を成立させた文字情報が、“バンド”を含む場合、音楽やバンドを示唆するような種類の自動リアクションが選択されてもよい。同様に、リアクション種別決定部１５６は、好ましくは、所定の第２発動条件を成立させた文字情報、又は、その際の特定行動の属性に基づいて、当該文字情報及び／又は当該特定行動に応じた種類の自動リアクションを選択してよい。

パラメータ算出部１５８は、所定の発動条件の成否の判定に利用可能な各種パラメータの値を算出する。各種パラメータは、文字情報に関連するパラメータを含んでよい。

本実施形態では、パラメータ算出部１５８は、第１算出部１５８１と、第２算出部１５８２とを含む。

第１算出部１５８１は、リアクション主体のアバターに対応付けられている文字情報と、第１判定対象アバターに対応付けられている文字情報との間の文字間距離を算出する。文字間距離の算出方法は、上述したとおりであってよい。この場合、文字情報は、本来的に短い単語で構成される傾向があるので、文字間距離の算出処理負荷を効率的に低減できる。

第２算出部１５８２は、特定行動に関連する文字と、第２判定対象アバターに対応付けられている文字情報との間の文字間距離を算出する。文字間距離の算出方法は、上述したとおりであってよい。この場合も、文字情報は、本来的に短い単語で構成される傾向があるので、文字間距離の算出処理負荷を効率的に低減できる。

また、特定行動に関連する文字は、あらかじめ特定行動の属性に応じて文字化されていてもよい。この場合、特定行動ＩＤごとに、特定行動に関連する文字が記憶されてもよい。かかる構成によれば、特定行動に関連する文字を導出する処理が不要となり、処理負荷を低減できる。

視野処理部１６０は、ユーザからのユーザ入力とは直接的に無関係に、特定のアバターに対応付けられている仮想カメラの撮像パラメータの各値（位置、視線方向、画角等）を一時的に変化させる処理を実行する。

本実施形態では、視野処理部１６０は、第１視野変化処理部１６０１と、第２視野変化処理部１６０２とを含む。

第１視野変化処理部１６０１は、リアクション主体のアバターが相手アバターに対して自動リアクションを行う場合に、相手アバターに対応付けられている仮想カメラの撮像パラメータの各値を、相手アバターの視野内にリアクション主体のアバターが入るように変化させる。これにより、上述したように、リアクション主体のアバターに相手アバターが気付きやすくなり、両者の交流を効率的に促進できる。

第２視野変化処理部１６０２は、一のアバターと他の一のアバターとの位置関係が第２所定位置関係へと遷移した場合に、当該一のアバター及び当該他の一のアバターのうちの一方のアバターの視野内に他方のアバターが入るように、当該一のアバター及び当該他の一のアバターのうちの他方のアバターの視野を一時的に変化させる。第２所定位置関係は、上述した第１所定位置関係と同じであってもよいし、上述した第１所定位置関係よりも離れた位置関係を含んでもよい。例えば、あるトークルームに、新たなアバターが入ってきた場合、当該トークルーム内のすべて又は一部のアバターの視野を一時的に変化させることで、当該トークルーム内にいるアバターの視野内に、新たなアバターが入りやすくなる。これにより、両者の交流を効率的に促進できる。なお、本実施形態では、アバターの視野を一時的に変化させることで、注目等すべきアバターを目立たせることとしているが、これに代えて又は加えて、注目等すべきアバターを強調したり、注目等すべきアバターの位置（視野外にいるアバターの位置）を案内する案内表示等を出力したりしてもよい。なお、この案内は、案内表示に加えて、又は、代えて、ユーザが手にしているジョイパッドのようなコントローラを振動させることによって、さらには、音声によって、実行されてもよい。

ユーザ情報開示制御部１６２は、ユーザ情報記憶部１４４内のユーザ情報のうちの、一部（以下、「閲覧用ユーザ情報」とも称する）を他のアバター（ユーザ）が閲覧可能とする。閲覧用ユーザ情報は、プロフィール情報や文字情報等を含んでよい。例えば、プロフィール情報は、所定のユーザ入力（以下、「閲覧要求」とも称する）に応じて閲覧可能とされてもよい。この場合、ユーザ情報開示制御部１６２は、ミュートフラグがオンされているアバターに係る閲覧用ユーザ情報は、当該アバターに対してミュートフラグをオンしているユーザには、閲覧不能としてもよい。また、ユーザ情報開示制御部１６２は、ブロックフラグがオンされているアバターに対しては、当該アバターに対してブロックフラグをオンしているユーザに係る閲覧用ユーザ情報は、閲覧不能とされてもよい。

閲覧要求は、任意の態様で生成されてもよい。例えば、スマートフォンのような端末装置２０を利用する場合、一のアバターに係る閲覧用ユーザ情報の閲覧要求（他のアバターによる閲覧要求）は、当該一のアバターを画面上でタップすることで生成されてもよい。あるいは、閲覧要求は、当該一のアバターに虫眼鏡をかざすことで生成されてもよい。また、メタバース空間において、一のアバターに係る閲覧用ユーザ情報の閲覧要求（他のアバターによる閲覧要求）は、当該一のアバターに向けて視線を所定時間以上向けることで生成されてもよい。あるいは、当該一のアバターとの間で視線が一致する（すなわち目が合う）ことで生成されてもよい。

なお、上述したサーバ装置１０及び端末装置２０間の機能の分担は、あくまで一例であり、上述したように、多様に変更が可能である。すなわち、サーバ装置１０の機能の一部又は全部は、適宜、端末装置２０により実現されてもよい。

次に、図１５以降を参照して、上述したアバターの自動リアクションに関連した仮想現実生成システム１の動作例について説明する。

図１５は、上述したアバターの自動リアクションに関連してサーバ装置１０により実行される処理の一例を示す概略的なフローチャートである。図１５に示す処理は、特定の一のアバター（以下、「処理対象アバター」とも称する）に関する処理であり、所定周期ごとに繰り返し実行されてよい。図１５に示す処理は、仮想空間内のアバターごとに並列的に実行されてよい。

ステップＳ２７００では、サーバ装置１０は、処理対象アバターに対応するユーザからの今回周期のユーザ入力を取得する。

ステップＳ２７０１では、サーバ装置１０は、ステップＳ２７００で取得したユーザ入力に基づいて、処理対象アバターの位置や視野（仮想カメラ）を更新する。

ステップＳ２７０２では、自動リアクション可否情報に基づいて、自動リアクションが可能な設定状態であるか否かを判定する。なお、自動リアクション可否情報は、ユーザ情報記憶部１４４内のユーザ情報に関連して上述したとおりである。判定結果が“ＹＥＳ”の場合、ステップＳ２７０３に進み、それ以外の場合は、ステップＳ２７１４に進む。

ステップＳ２７０３では、サーバ装置１０は、処理対象アバターの視野内に位置する１人以上の他のアバターを抽出する。なお、図示しないが、他のアバターが一人もいない場合は、今回周期の処理はそのまま終了してもよい。

ステップＳ２７０４では、サーバ装置１０は、処理対象アバターに対応付けられている制限フラグ情報（図１２参照）に基づいて、ステップＳ２７０３で抽出した１人以上の他のアバターにおいて、ミュートフラグがオンに設定されているアバターが存在するか否かを判定する。なお、変形例では、ミュートフラグがオンに設定されているアバターは、初期的に処理対象から除外されてもよい。判定結果が“ＹＥＳ”の場合、ステップＳ２７０５に進み、それ以外の場合は、ステップＳ２７０６に進む。

ステップＳ２７０５では、サーバ装置１０は、ミュートフラグがオンに設定されているアバターを、以下のステップＳ２７０６以降の処理対象から除外するとともに、アバターミュート処理を実行する。アバターミュート処理は、上述したように、処理対象アバターにとって、当該アバターの存在を実質的に無くす処理である。

ステップＳ２７０６では、サーバ装置１０は、処理対象アバターに対応付けられている制限フラグ情報（図１２参照）に基づいて、ステップＳ２７０３で抽出した１人以上の他のアバターにおいて、ブロックフラグがオンに設定されているアバターが存在するか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２７０７に進み、それ以外の場合は、ステップＳ２７０８に進む。

ステップＳ２７０７では、サーバ装置１０は、ブロックフラグがオンに設定されているアバターを、以下のステップＳ２７０８以降の処理対象から除外するとともに、交流対象から除外するアバターブロック処理を実行する。アバターブロック処理は、上述したように、処理対象アバターに、当該アバターに近づいたり話しかけたりできなくする処理である。

ステップＳ２７０８では、サーバ装置１０は、処理対象アバターに対して第１所定位置関係に他のアバターが存在するか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ２７０９に進み、それ以外の場合は、ステップＳ２７１４に進む。

ステップＳ２７０９では、サーバ装置１０は、処理対象アバターに対して第１所定位置関係に位置する他のアバターに対応付けられている文字情報を抽出する。なお、処理対象アバターに対して第１所定位置関係に位置する他のアバターが複数存在する場合は、他のアバターごとにステップＳ２７０９からステップＳ２７１３の処理が順次実行されてもよい。

ステップＳ２７１０では、サーバ装置１０は、処理対象アバターに対応付けられている文字情報と、ステップＳ２７０９で抽出した文字情報とに基づいて、文字間距離を算出する。文字間距離の算出方法は、上述したとおりである。

ステップＳ２７１１では、サーバ装置１０は、文字間距離が所定距離Ｌ_０以下であるか否かを判定する。所定距離Ｌ_０は、一定値であってもよいし、可変値であってよい。例えば、所定距離Ｌ_０は、ユーザにより設定可能とされてもよい。判定結果が“ＹＥＳ”の場合、所定の第１発動条件が満たされたと判断し、ステップＳ２７１２に進み、それ以外の場合は、ステップＳ２７１４に進む。

ステップＳ２７１２では、サーバ装置１０は、自動リアクションの種類を決定する。この場合、サーバ装置１０は、ステップＳ２７１１で文字間距離が所定距離Ｌ_０以下であると判定された文字情報に基づいて、自動リアクションの種類を決定してよい。例えば、文字間距離が所定距離Ｌ_０以下であると判定された文字情報が、“お酒”で共通している場合、自動リアクションの種類は、“飲むジェスチャ”に係る動作であってよい。また、文字間距離が所定距離Ｌ_０以下であると判定された文字情報が、“バスケ（スポーツ）”で共通している場合、自動リアクションの種類は、“シュートするジェスチャ”に係る動作であってよい。また、変形例では、文字間距離に応じて、自動リアクションに係る動作の強弱を変更してもよい。例えば、自動リアクションの種類が手を振る動作である場合、文字間距離が小さいほど大きく手を振る動作が選択される態様で、自動リアクションの種類が決定されてもよい。

ステップＳ２７１３では、サーバ装置１０は、処理対象アバターに、ステップＳ２７１２で決定した種類の自動リアクションを実行させる。これは、前述したとおり、本開示では、アバター間の交流を効果的に促進することを課題としているが、他のアバターによるすべての特定行動に対して処理対象アドバイザーの自動リアクションをトラッキングしていると処理負荷が高くなりすぎる可能性があること、また、リアクションが遅れたり、通信状況によってモーションデータを送るのに時間を要したりすると、大事な場面（例えば初対面のとき）におけるタイムリーなリアクションが取れなくなってしまう可能性があることなどから、自動リアクションの種類を限定しているものである。

ステップＳ２７１４では、サーバ装置１０は、処理対象アバターに、ユーザ入力に応じた動作を実行させる。

図１６は、上述したアバターの自動リアクションに関連してサーバ装置１０により実行される処理の他の一例を示す概略的なフローチャートである。図１６に示す処理は、図１５に示した処理と同様、特定の一のアバター（以下、「処理対象アバター」とも称する）に関する処理であり、所定周期ごとに繰り返し実行されてよい。図１６に示す処理は、仮想空間内のアバターごとに並列的に実行されてよい。また、図１６に示す処理は、上述した図１５に示した処理と並列的に実行されてもよい。

ステップＳ２９００からステップＳ２９０７までの処理は、図１５に示したステップＳ２７００からステップＳ２７０７と同じであってよく、説明を省略する。

ステップＳ２９０８では、サーバ装置１０は、処理対象アバターの視野内の他のアバターが特定行動を行う（又は行っているか）か否かを判定する。特定行動は、上述したとおりである。判定結果が“ＹＥＳ”の場合、ステップＳ２９０９に進み、それ以外の場合は、ステップＳ２９１４に進む。なお、判定にあたっては、ある時点における処理対象アバターの視野外の他のアバターの特定行動であっても、処理対象アバターの視点を変更することによって視野に入れることが可能な範囲における特定行動については、自動リアクションをとる対象としてもよい。

ステップＳ２９０９では、サーバ装置１０は、特定行動の属性を判定し、当該属性に応じた文字を決定（又は導出）する。例えば、特定行動が“サッカーボールのリフティング”である場合、特定行動の属性に応じた文字は、“サッカー”及び／又は“リフティング”であってよい。また、サッカーボールの絵柄などに特徴がある場合は、その絵柄に応じた文字を決定してもよい。なお、処理対象アバターの視野内に特定行動を行う他のアバターが複数存在する場合は、他のアバターごとにステップＳ２９０９からステップＳ２９１３の処理が順次実行されてもよい。

ステップＳ２９１０では、サーバ装置１０は、処理対象アバターに対応付けられている文字情報と、ステップＳ２９０９で抽出した文字情報とに基づいて、文字間距離を算出する。文字間距離の算出方法は、上述したとおりである。

ステップＳ２９１１では、サーバ装置１０は、文字間距離が所定距離Ｌ_０以下であるか否かを判定する。所定距離Ｌ_０は、一定値であってもよいし、可変値であってよい。例えば、所定距離Ｌ_０は、ユーザにより設定可能とされてもよい。判定結果が“ＹＥＳ”の場合、所定の第１発動条件が満たされたと判断し、ステップＳ２９１２に進み、それ以外の場合は、ステップＳ２９１４に進む。

ステップＳ２９１２では、サーバ装置１０は、自動リアクションの種類（属性）を決定する。この場合、サーバ装置１０は、ステップＳ２９１１で文字間距離が所定距離Ｌ_０以下であると判定された文字情報（特定行動の属性に応じた文字）に基づいて、自動リアクションの種類を決定してよい。これは、図１５を参照して上述したステップＳ２７１２と同様である。

ステップＳ２９１３では、サーバ装置１０は、処理対象アバターに、ステップＳ２９１２で決定した種類の自動リアクションを実行させる。

ステップＳ２９１４では、サーバ装置１０は、処理対象アバターに、ユーザ入力に応じた動作を実行させる。

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

１ 仮想現実生成システム
３ ネットワーク
１０ サーバ装置
１１ サーバ通信部
１２ サーバ記憶部
１３ サーバ制御部
２０、２０Ａ、２０Ｂ 端末装置
２１ 端末通信部
２２ 端末記憶部
２３ 表示部
２４ 入力部
２５ 端末制御部
１４２ 自動リアクション関連データ記憶部
１４４ ユーザ情報記憶部
１４６ アバター情報記憶部
１５０ ユーザ入力取得部
１５２ アバター処理部
１５２１ アバター動作処理部
１５２２ 描画処理部
１５３ 対応付け処理部
１５４ 交流制限処理部
１５５ 発動条件判定部
１５５０ 判定対象決定部
１５５０１ 第１判定対象決定部
１５５０２ 第２判定対象決定部
１５５１ 第１判定部
１５５２ 第２判定部
１５５３ 第３判定部
１５６ リアクション種別決定部（第１、２所定動作決定部）
１５８ パラメータ算出部
１５８１ 第１算出部
１５８２ 第２算出部
１６０ 視野処理部
１６０１ 第１視野変化処理部
１６０２ 第２視野変化処理部
１６２ ユーザ情報開示制御部

Claims (22)

1. 仮想空間において各アバターの動きを処理するアバター処理部と、
   各アバターに、対応するユーザにより指定される文字情報又はアバター自身と関連付けられる文字情報を対応付ける対応付け処理部と、
   第１アバターに対応付けられている前記文字情報と、第２アバターに対応付けられている前記文字情報との関係を判定する第１判定部とを備え、
   前記アバター処理部は、仮想空間において第１所定位置関係に前記第１アバターと前記第２アバターとが存在する場合に、前記第１判定部による判定結果に基づいて、前記第２アバターに、又は、前記第１アバターと前記第２アバターの双方に、所定動作を自動的に行わせる、情報処理システム。
2. 前記アバター処理部は、前記第１アバターに対応付けられている前記文字情報と、前記第２アバターに対応付けられている前記文字情報との関係が所定関係であると前記第１判定部により判定された場合に、前記第２アバターに、又は、前記第１アバターと前記第２アバターの双方に、前記所定動作を自動的に行わせる、請求項１に記載の情報処理システム。
3. 前記アバター処理部は、更に、前記第１所定位置関係に前記第１アバターと前記第２アバターとが存在し、かつ、前記第１アバターが特定行動を行う場合に、前記特定行動の属性と、前記第２アバターに対応付けられている前記文字情報とに基づいて、前記第２アバターに、前記所定動作を自動的に行わせる、請求項１に記載の情報処理システム。
4. 前記特定行動の属性と、前記第２アバターに対応付けられている前記文字情報との関係を判定する第２判定部を更に備え、
   前記アバター処理部は、前記第２判定部による判定結果に基づいて、前記第２アバターに、前記所定動作を自動的に行わせる、請求項３に記載の情報処理システム。
5. 前記アバター処理部は、前記特定行動の属性と、前記第２アバターに対応付けられている前記文字情報との関係が所定関係であると前記第２判定部により判定された場合に、前記第２アバターに前記所定動作を自動的に行わせる、請求項４に記載の情報処理システム。
6. 前記第１アバターに対応付けられている前記文字情報、及び、前記第２アバターに対応付けられている前記文字情報のうちの少なくともいずれか一方に基づいて、複数種類のうちから、自動的に行わせる前記所定動作の種類を決定する第１所定動作決定部を更に備える、請求項５に記載の情報処理システム。
7. 前記所定関係は、共通点を有する関係を含み、
   前記所定動作は、前記第１アバターと前記第２アバターとの間の相互に対する動作を含む、請求項２又は５に記載の情報処理システム。
8. 前記第１アバターに対応付けられている前記文字情報と、前記第２アバターに対応付けられている前記文字情報との間の文字間距離を算出する第１算出部を更に備え、
   前記第１判定部は、前記文字間距離に基づいて、前記所定関係の有無を判定する、請求項２に記載の情報処理システム。
9. 前記所定関係は、共通点を有する関係を含み、
   前記所定動作は、前記特定行動に対する前記第２アバターの好意的な反応を含む、請求項５に記載の情報処理システム。
10. 前記特定行動に関連する文字と、前記第２アバターに対応付けられている前記文字情報との間の文字間距離を算出する第２算出部を更に備え、
    前記第２判定部は、前記文字間距離に基づいて、前記所定関係の有無を判定する、請求項５に記載の情報処理システム。
11. 前記特定行動の属性、及び、前記特定行動の属性に対して前記所定関係を有する前記文字情報のうちの少なくともいずれか一方に基づいて、複数種類のうちから、自動的に行わせる前記所定動作の種類を決定する第２所定動作決定部を更に備える、請求項５に記載の情報処理システム。
12. 前記対応付け処理部は、各アバターに対応付けられているプロフィール情報、及び、前記プロフィール情報の更新態様の少なくともいずれか一方に基づいて、各アバターに対応付ける前記文字情報を生成及び更新する、請求項１に記載の情報処理システム。
13. 前記対応付け処理部は、各アバターによる会話情報又は発語情報に基づいて、各アバターに対応付ける前記文字情報を生成及び更新する、請求項１に記載の情報処理システム。
14. 前記対応付け処理部は、各アバターによる仮想空間における行動履歴に基づいて、各アバターに対応付ける前記文字情報を生成及び更新する、請求項１に記載の情報処理システム。
15. 一のアバターに対応付けられているプロフィール情報、前記一のアバターによる会話情報、前記一のアバターに対応付けられているアイテム情報、及び、前記一のアバターによる仮想空間における行動履歴のうちの少なくともいずれか１つに基づいて、前記一のアバターと交流可能なアバターを決定する交流制限処理部を更に備える、請求項１に記載の情報処理システム。
16. 前記対応付け処理部は、複数のアバターが一のユーザに対応付けられている場合、アバターごとに前記文字情報を対応付ける、請求項１に記載の情報処理システム。
17. 前記第２アバターが前記第１アバターに対して前記所定動作を自動的に行う場合に、前記第１アバターの視野内に前記第２アバターが入るように、前記第１アバターの視野を変化させる第１視野変化処理部を更に備える、請求項１に記載の情報処理システム。
18. 仮想空間において前記第１アバターと前記第２アバターとの位置関係が第２所定位置関係へと遷移した場合に、前記第１アバター及び前記第２アバターのうちの一方のアバターの視野内に他方のアバターが入るように、前記第１アバター及び前記第２アバターのうちの他方のアバターの視野を変化させる第２視野変化処理部を更に備える、請求項１に記載の情報処理システム。
19. 仮想空間における前記第１アバターと前記第２アバターとの位置関係が前記第１所定位置関係であるか否かを判定する第３判定部を更に備え、
    前記第３判定部は、前記第１アバターと前記第２アバターとの間の距離、前記第１アバターと前記第２アバターとの間の障害物の有無、前記第１アバターの視野内における前記第２アバターの有無、及び、前記第１アバターの視野外に前記第２アバターが位置する状態から前記第１アバターの視野内に前記第２アバターが位置する状態への遷移が可能であるか否か、のうちの少なくともいずれか１つのパラメータに基づいて、前記位置関係が前記第１所定位置関係であるか否かを判定する、請求項１に記載の情報処理システム。
20. 前記文字情報は、対応するアバターに対応付けられた位置に、タグ情報の形式で表示可能である、請求項１に記載の情報処理システム。
21. 非一時的なコンピュータ読み取り可能な記憶媒体であって、
    仮想空間において各アバターの動きを処理するアバター処理と、
    各アバターに、対応するユーザにより指定される文字情報又はアバター自身と関連付けられる文字情報を対応付ける対応付け処理と、
    第１アバターに対応付けられている前記文字情報と、第２アバターに対応付けられている前記文字情報との関係を判定する判定処理とを、
    コンピュータに実行させるプログラムが記憶され、
    前記アバター処理は、仮想空間において所定位置関係に前記第１アバターと前記第２アバターとが存在する場合に、前記判定処理による判定結果に基づいて、前記第２アバターに、又は、前記第１アバターと前記第２アバターの双方に、所定動作を自動的に行わせることを含む、記憶媒体。
22. 仮想空間において各アバターの動きを処理するアバター処理を実行し、
    各アバターに、対応するユーザにより指定される文字情報又はアバター自身と関連付けられる文字情報を対応付ける対応付け処理を実行し、
    第１アバターに対応付けられている前記文字情報と、第２アバターに対応付けられている前記文字情報との関係を判定する判定処理を実行することを含み、
    前記アバター処理は、仮想空間において所定位置関係に前記第１アバターと前記第２アバターとが存在する場合に、前記判定処理による判定結果に基づいて、前記第２アバターに、又は、前記第１アバターと前記第２アバターの双方に、所定動作を自動的に行わせることを含む、コンピュータにより実行される情報処理方法。