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

Abstract

【課題】ユーザ間のチャット形式のコミュニケーションに係る処理負荷を低減する。
【解決手段】送信側から送信される送信内容を取得する取得部と、送信内容に対する受信側からの返信内容に関する複数の選択肢を生成する選択肢生成部とを備え、複数の選択肢は、電子機器を介して視認可能な仮想空間内の移動先に対応付けられた第１選択肢を含み、送信内容及び返信内容は、複数のユーザ間のチャット形式のコミュニケーションに関し、一のチャットにおいて移動先は、送信内容に基づいて決定される、情報処理システムが開示される。
【選択図】図１３

Description

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

携帯端末機の送信側においてキャラクタイメージで表示できる情報を含む文字メッセージを生成伝送し、受信側において受信される文字メッセージを分析した後、キャラクタイメージ表示用情報を含むと、該当するキャラクタイメージと共に文字メッセージを視覚的に表示する技術が知られている。

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

しかしながら、上記のような従来技術では、ユーザ間のチャット形式のコミュニケーションを比較的低い処理負荷で支援することが難しい。

そこで、１つの側面では、本開示は、ユーザ間のチャット形式のコミュニケーションに係る処理負荷を低減することを目的とする。

１つの側面では、複数のユーザ間のチャット形式のコミュニケーションに係る情報処理を行う情報処理システムであって、
送信側から送信される送信内容を取得する取得部と、
前記送信内容に対する受信側からの返信内容に関する複数の選択肢を生成する選択肢生成部とを備え
前記複数の選択肢は、電子機器を介して視認可能な仮想空間内の移動先に対応付けられた第１選択肢を含み、
一のチャットにおいて前記移動先は、前記送信内容に基づいて決定される、情報処理システムが提供される。

１つの側面では、本開示によれば、ユーザ間のチャット形式のコミュニケーションに係る処理負荷を低減することが可能となる。

本実施形態に係るチャット関連支援システムのブロック図である。 本開示に従ったコンピュータベースのオペレーションを実行する処理回路のブロック図である。 ヘッドマウントディスプレイを介して視認可能な端末用画像の説明図である。 スマートフォンを介して視認できる端末用画像の説明図である。 メタバース空間に対する多様なアクセス方法の説明図である。 ある一のユーザに関して、午前０時から２４時までの利用デバイスの時系列の一例を示す図である。 ユーザの状態と利用デバイスの時系列の一例を示す図である。 一のユーザからの送信内容に対する他の各ユーザの返信内容に関する複数の選択肢の提示されている様子を概念的に示す図（その１）である。 一のユーザからの送信内容に対する他の各ユーザの返信内容に関する複数の選択肢の提示されている様子を概念的に示す図（その２）である。 移動関連処理の説明図であって、複数の選択肢に関連した説明図（その１）である。 移動関連処理の説明図であって、複数の選択肢に関連した説明図（その２）である。 選択肢関連機能に関連したサーバ装置の機能ブロック図の一例である。 ユーザ情報記憶部内のデータの説明図である。 アバター情報記憶部内のデータの説明図である。 選択肢関連機能に関連した一の端末装置の機能ブロック図の一例である。

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

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

チャット関連支援システム１は、サーバ装置１０と、１つ以上の端末装置２０と、を備える。図１では簡便のため、３つの端末装置２０を図示しているが、端末装置２０の数は２つ以上であればよい。

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

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

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

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

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

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

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

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

また、本明細書において、用語「対応付け」とは、直接的な対応付けのみならず、間接的な対応付けをも含む。例えば、要素Ａに要素Ｂが対応付けられている状態は、要素Ａに要素Ｂが対応付けられている状態のみならず、要素Ａに要素Ｃが対応付けられかつ要素Ｃに要素Ｂが対応付けられている状態をも含む概念である。

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

図１Ａは、本開示に従ったコンピュータベースのオペレーションを実行する処理回路６００のブロック図である。以下で説明する処理回路６００は、図１に示すサーバ装置１０のサーバ通信部１１からサーバ制御部１３を実現するハードウェア構成として好適である。また、以下で説明する処理回路６００は、図１に示す端末装置２０の端末通信部２１、端末記憶部２２、及び端末制御部２５を実現するハードウェア構成として好適である。

処理回路６００は、任意のコンピュータベースおよびクラウドベースの制御プロセスを制御するために使用され、フローチャートにおける記述またはブロックは、プロセスにおける特定の論理機能またはステップを実装するための１つまたは複数の実行可能命令を含むコードのモジュール、セグメントまたは部分を表すものとして理解することができ、代替実装は、当業者に理解されるように、関連する機能性に応じて実質的に同時または逆順など図示または議論した順序とは異なる順序で機能を実行することができる本先端の例示的実施形態範囲内に含まれる。本明細書に開示された要素の機能は、開示された機能を実行するように構成またはプログラムされた汎用プロセッサ、特殊目的プロセッサ、集積回路、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ）、従来の回路および／またはそれらの組み合わせを含み得る回路または処理回路を使用して実装され得る。プロセッサは、その中にトランジスタ及び他の回路を含むので、処理回路又は回路である。プロセッサは、メモリ６０２に格納されたプログラムを実行するプログラムされたプロセッサであってよい。本開示において、処理回路、ユニット、または手段は、言及された機能を実行する、または実行するようにプログラムされたハードウェアである。ハードウェアは、本明細書に開示された、またはそうでなければ公知の、言及された機能を実行するようにプログラムされるか構成される任意のハードウェアであってよい。

なお、図１Ａでは、処理回路６００は、バス６２８を介して接続されるディスプレイコントローラ６０６、ストレージコントローラ６２４、ネットワークコントローラ７０２、メモリ６０２、Ｉ／Ｏインターフェース６１２等が接続されている。この場合、処理回路６００は、ディスプレイコントローラ６０６を介してディスプレイ６０９に接続され、Ｉ／Ｏインターフェース６１２を介して、キーボードやマウス６１４、タッチスクリーン６１６、周辺装置６１８に接続されている。また、処理回路６００は、ネットワークコントローラ７０２を介してネットワーク３にアクセスする。

図１Ａにおいて、処理回路６００は、本開示で議論される制御プロセスのうちの１つ以上を実行するＣＰＵ６０１を含む。処理データおよび命令は、メモリ６０２に格納されてもよい。また、これらのプロセスおよび命令は、ハードディスクドライブ（ＨＤＤ）または可搬型記憶媒体などの記憶媒体ディスク６０４（図１Ａでは、「ディスク」と表記）に格納されてもよいし、リモートで格納されてもよい。さらに、本開示プロセスの命令が格納されるコンピュータ可読媒体の形態は任意である。例えば、命令は、ＣＤ、ＤＶＤ、処理回路６００が通信する情報処理装置のＦＬＡＳＨメモリ、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ハードディスクまたは他の非一時的コンピュータ可読媒体、例えばサーバまたはコンピュータに格納されてもよい。また、プロセスは、ネットワークベースのストレージ、クラウドベースのストレージ、または他のモバイルアクセス可能なストレージに格納され、処理回路６００によって実行可能であってもよい。

さらに、各種プロセス等は、ＣＰＵ６０１と、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）、Ｓｏｌａｒｉｓ（登録商標）、ＬＩＮＵＸ（登録商標）、Ａｐｐｌｅ（登録商標）、ＭＡＣ－ＯＳ（登録商標）、Ａｐｐｌｅ ｉＯＳ（登録商標）および当業者に知られている他のシステムなどのオペレーティングシステムと連携して実行するユーティリティアプリケーション、バックグラウンドデーモン、またはオペレーティングシステムのコンポーネント、またはその組み合わせとして提供されてもよい。

処理回路６００を実現するためのハードウェア要素は、様々な回路要素によって実現され得る。さらに、上述した実施形態の各機能は、１つまたは複数の処理回路を含む回路によって実現されてもよい。処理回路は、特にプログラムされたプロセッサ、例えば、図１Ａに示すように、プロセッサ（ＣＰＵ）６０１を含む。処理回路はまた、言及された機能を実行するために配置された特定用途向け集積回路（ＡＳＩＣ）および従来の回路構成要素のようなデバイスを含む。

図１Ａにおいて、処理回路６００は、コンピュータまたは特定の特別な目的の機械であってもよい。処理回路６００は、実装される装置（サーバ装置１０や端末装置２０）を制御するための処理を実行するようにプログラムされている。

代替的に、または追加的に、ＣＰＵ６０１は、当業者であれば認識するように、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、ＡＳＩＣ、ＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）上に実装されてもよいし、ディスクリート論理回路を使用して実装されてもよい。さらに、ＣＰＵ６０１は、各種プロセスの命令を実行するために、並行して協調的に動作する複数のプロセッサとして実装されてもよい。

図１Ａの処理回路６００は、また、ネットワーク３とインターフェースするための、イーサネットＰＲＯネットワークインタフェースカードなどのネットワークコントローラ７０２を含む。理解できるように、ネットワーク３は、インターネットなどの公衆ネットワーク、またはローカルエリアネットワーク（ＬＡＮ）もしくはワイドエリアネットワーク（ＷＡＮ）などのプライベートネットワーク、またはそれらの任意の組み合わせとすることができ、公衆交換電話網（ＰＳＴＮ：Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）または統合サービスデジタルネットワーク（ＩＳＤＮ：Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）、サブネットワークも含むことができる。ネットワーク３は、また、イーサネット（Ｅｔｈｅｒｎｅｔ）のような有線ＬＡＮネットワーク、ユニバーサルシリアルバス（ＵＳＢ：Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ケーブルなどの有線とすることができ、またはＥＤＧＥ、３Ｇ、４Ｇ及び５Ｇ無線セルラーシステムを含むセルラーネットワークなどの無線とすることができる。また、無線ネットワークは、Ｗｉ－Ｆｉ（登録商標）、無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、または公知の他の無線通信形態とすることができる。さらに、ネットワークコントローラ７０２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離無線通信（ＮＦＣ）、赤外線などの他の直接通信規格に準拠することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ところで、メタバース空間に対するユーザのアクセス方法は多様であり、例えば、端末装置２０に関しては、図４に概念的に示すように、ヘッドマウントディスプレイ（いわゆるＶＲゴーグルやＶＲグラス等を含む）や、スマートフォン、パーソナルコンピュータ、ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）グラス（いわゆるスマートグラス等を含む）等、多様な種類の端末装置２０（電子機器の一例）によるアクセスが可能である。

また、現実でのユーザのステータスは、仕事中、就寝中、食事中、移動中、メタバース空間の滞在中、といった具合に多様である。なお、ステータスとは、環境を含む概念である。例えば、一のユーザのステータスは、当該一のユーザを取り巻く周辺環境を含んでよい。

各ユーザは、それぞれ異なりうる多様なステータスを有しつつ、多様な端末装置２０を介して交流を図ることができる。

このようにして、各ユーザは、現実でのステータスの変更を伴いながら、かつ、多様な端末装置２０を使い分けながら、複数のユーザ間のチャット形式のコミュニケーションを行うことができる。従って、例えば、各ユーザは、常時接続状態（すなわち、ユーザ間でつながった状態）で、一日以上を過ごすこともできる。例えば、図５に示す例では、ある一のユーザに関して、午前０時から２４時までに利用した端末装置２０（以下、単に「利用デバイス」とも称する）であって、常時接続のために利用した端末装置２０の時系列の一例が示されている。また、各ユーザ（例えば友達同士のユーザ）は、チャット形式のコミュニケーションを介して待ち合わせ場所などの決め事をして、適宜、メタバース空間の所定の場所（例えばいつもの待ち合わせ場所）に移動し、そこで、出会い、遊んだり、話したり、色々できる。
また、図５Ａに示す例では、横軸に時刻（又は時間）を取り、ユーザの状態（Ｕｓｅｒ Ｓｔａｔｕｓ）と、利用デバイスの時系列が示されている。なお、図５Ａは、ある一日のパターンを示すが、当該パターンは、曜日や季節等に応じて異なりうる。図５Ａに示す例では、ユーザの移動中は、ＡＲグラスと連動（連携）してスマートフォンでの同時アクセス（又は連動）が実現されている。この場合、スマートフォンでの操作と、ＡＲグラスでの表示機能が協調されてもよい。また、自宅に帰ると、ユーザは、ＰＣを起動し、スマートフォンからＰＣへの切り替えを実現している。このように、ＰＣとスマートフォンは互いに排他的関係（同時に利用できない関係）であってよい。ユーザは、ＰＣを利用している間は、ヘッドマウントディスプレイとＰＣとを連携させてもよい。ただし、ユーザは、ヘッドマウントディスプレイをスタンドアローンで利用してもよい。

以下では、上述したようなチャット形式のコミュニケーションを効果的に支援できる各種情報処理について説明する。ただし、以下の各種情報処理は、チャット形式のコミュニケーションに好適であるものの、他のアプリケーションにも適用可能である。なお、チャット形式とは、メッセージや文字（絵文字等）、記号、画像（スタンプ等）又はその類のような、通話とは異なる形式を指す。なお、チャット形式とは、音声を除外するものではなく、例えば音声付きのスタンプ等が利用可能な形式を含んでもよい。

以下では、各ユーザは、特に言及しない限り、チャット形式のコミュニケーションのためにつながっている各ユーザであって、一のチャットグループ内の各ユーザを指す。“つながっている”とは、上述したネットワーク３に接続する端末装置２０を介して、互いに通信可能な状態を指す。また、チャットグループとは、あらかじめ登録されたグループであってもよいし、その場で形成されたグループであってもよい。また、一のチャットグループに参加するユーザは、固定であってもよいし、動的に変化してもよい。

本実施形態では、まず、一のユーザから何らかが送信されると、その送信内容に対する受信側からの返信内容に関する複数の選択肢が生成される。この場合、受信側のユーザは、複数の選択肢の中に、所望の選択肢があれば、それを選択するだけで返信が完了するので、利便性が高くなる。

図６及び図７は、一のユーザからの送信内容に対する他の各ユーザの返信内容に関する複数の選択肢の提示されている様子を概念的に示す図である。なお、図６及び図７で示す会話は、チャット形式のコミュニケーションに関する。また、以下の説明において、銀行など場所を表す用語は、特に言及しない限り、メタバース空間内の場所を表す。

図６では、ユーザＡが“問いかけＡ”を他の各ユーザ（３人のユーザＢ、Ｃ、Ｄだけ図示）を受けた場合、各ユーザには、それぞれ、複数の選択肢が提示される。各選択肢は、メッセージや文字（絵文字等）、記号、画像（スタンプ等）又はその類を含んでよい。例えば、ユーザＢには、返答候補Ｂ１、Ｂ２等が提示されている。同様に、ユーザＣには、返答候補Ｃ１、Ｃ２等が提示され、ユーザＤには、返答候補Ｄ１、Ｄ２等が提示されている。この場合、例えば、ユーザＢは、複数の選択肢Ｂ１、Ｂ２等の中に、所望の選択肢があれば、それを選択するだけで返信が完了するので、利便性が高くなる。例えば、図７には、“問いかけＡ”に対して４つの選択肢ＳＴＭ１からＳＴＭ４がユーザＢに提示された状態が示されている。なお、図７では、４つの選択肢ＳＴＭ１からＳＴＭ４が、送信内容（“問いかけＡ”）ともに表示されているが、送信内容とは別に表示（提示）されてもよい。いずれの場合も、ユーザＢは、４つの選択肢ＳＴＭ１からＳＴＭ４のうちに、所望の選択肢があれば、選択するだけで返信が可能となる。

本実施形態では、受信側の各ユーザに提示される複数の選択肢は、送信内容（本例では、“問いかけＡ”）に基づいて生成される。例えば、複数の選択肢は、送信内容に対する応答となる選択肢を含んでよい。本例の場合、複数の選択肢のうちのいくつかの選択肢又はすべては、問いかけＡに対する応答としての意味をなす選択肢であってよい。問いかけＡに対する応答としての意味をなす選択肢とは、例えば、問いかけＡ＝今から場所Ａに行かない？に対して、「今から行くよ」、「今日は無理」、「もうすぐ寝る」、「場所Ｂがいいな」、「お金ない」といったメッセージや、これらの内容を直接的又は間接的に表す絵文字やスタンプを含む各選択肢は、問いかけＡに対する応答としての意味をなす選択肢でありうる。

複数の選択肢は、送信内容に対する応答として意味をなさない選択肢を含んでもよい。送信内容に対する応答として意味をなさない選択肢は、送信内容とは関連性が低い又は関連性が全くないメッセージ等を含む選択肢であってよい。例えば、問いかけＡに対する応答としての意味をなさない選択肢とは、問いかけに対する答えになっていないメッセージ等を含む選択肢であってよい。例えば、問いかけＡ＝今から場所Ａに行かない？に対して、「このおかず美味しいね」、「犬がかわいい」といったメッセージや、謎の絵文字等、これらの内容を直接的又は間接的に表す絵文字やスタンプを含む各選択肢は、問いかけＡに対する応答としての意味をなさない選択肢でありうる。

例えば、一実施例では、ユーザに提示される選択肢は、あることを直接的に表す種類の選択肢（以下、「直接応答型の選択肢」とも称する）、同事項を間接的に表す選択肢（以下、「間接応答型の選択肢」とも称する）、同事項とは無関係な選択肢（以下、「第１の非関連応答型の選択肢」とも称する）、同事項とは違う話題に関する選択肢（以下、「第２の非関連応答型の選択肢」とも称する）の４種類の選択肢があってよい。なお、第１の非関連応答型の選択肢は、例えば、相手側にとって何を意味しているか不明なスタンプを含む選択肢等を含んでよい。また、第２の非関連応答型の選択肢は、上述した例のような、例えば、問いかけＡ＝今から場所Ａに行かない？に対して、「このおかず美味しいね」、「犬がかわいい」といったメッセージを含む選択肢等を含んでよい。

ここで、送信内容に対する応答として意味をなすか否かは、相対的な概念でありうる。例えば、この場合、ある選択肢が、直接応答型の選択肢、間接応答型の選択肢又は第１の非関連応答型の選択肢ともなる場合もありうる。このような点を考慮して、上述した４種類の選択肢のような選択肢の属性を区別するための情報が、各選択肢に付与されてもよい。例えば、各選択肢には、あらかじめ所定フラグ（第２パラメータの一例）が対応付けられてよい。例えば、所定フラグの値“１”（第１の値の一例）が対応付けられた選択肢（第３選択肢の一例）は、送信内容に対する応答として意味をなす選択肢として扱われ、所定フラグの値“０”（第２の値の一例）が対応付けられた選択肢（第４選択肢の一例）は、送信内容に対する応答として意味をなさない選択肢として扱われてよい。

また、所定フラグは、意味をなす／なさない、の区別のためのフラグ機能に代えて又は加えて、意味をなす選択肢に関して、承諾／拒否の区別のためのフラグ機能を有してもよい。例えば、所定フラグの値“１”が対応付けられた選択肢は、送信内容に対する承諾を表す選択肢として扱われ、所定フラグの値“０”が対応付けられた選択肢は、送信内容に対する拒否を表す選択肢として扱われてよい。例えば、なんらかの集まりに誘う送信内容に対する承諾を表す選択肢が一のユーザにより選択された場合、当該ユーザに向けて、当該集まりに係る場所への移動を実現するためのリンクが送信されたり、当該集まりに対する出席予定者として管理されたりしてもよい。また、所定フラグは、承諾／拒否の区別のためのフラグ機能に代えて、承諾／拒否／保留／それ以外、といった具合に、より多くの意味を区別可能とされてもよい。この場合、承諾／拒否／保留／それ以外、の４種類に対応した４種類の選択肢が提示されてよく、ユーザにより選択された選択肢に係る種類に応じて、同ユーザのスケジュール管理が反映（更新）されてもよい。なお、この場合、保留／それ以外は、意味をなす／なさない、の区別のうちの、意味をなさない、に分類されてもよい。

本実施形態では、同じ送信内容（本例では、“問いかけＡ”）であったとしても、異なりうる。例えば、ユーザＣに提示される返答候補Ｃ１、Ｃ２等と、ユーザＤに提示される返答候補Ｄ１、Ｄ２等とは、一部又は全部が異なってもよい。この場合、例えば、複数の選択肢は、各ユーザに対応付けられている任意のパラメータ（第１パラメータの一例）に基づいて生成されてもよい。例えば、一のユーザに提示される複数の選択肢は、当該ユーザが所持する端末装置２０の種類、当該ユーザが所持するメタバース空間内のアイテム、当該ユーザのステータス、及び、当該ユーザと送信側ユーザ（例えば図６ではユーザＡ）との関係のうちの、少なくともいずれか１つを含んでよい。

なお、返答候補が異なるとは、同じ内容であっても表現が異なる態様を含む概念である。例えば、同じ内容であっても、方言や言語が異なる場合があってよい。例えば、大阪出身のユーザに対しては、関西弁のメッセージを含む選択肢が提示されてもよい。また、返答候補が異なるとは、例えばスタンプとして利用されてよいアバターの形態が異なってもよい。例えば、アバターが各ユーザの独自のアバターになることや、アバターの型（男性型／女性型／その他）に応じてポーズが異なる等の相違が実現されてもよい。

このようにして本実施例によれば、ユーザ自体の多様性や、ユーザに関連した多様性、ユーザのステータスの多様性等、各多様性に対応できる選択肢をユーザごとに提示できる。これにより、各ユーザにとって所望の選択肢が提示される可能性が高くなり、利便性が向上するとともに、ユーザによるメッセージ等の打ち直しなどに端末装置２０が対応する場合の処理負荷を低減できる。

本実施形態では、複数の選択肢は、端末装置２０を介して視認可能なメタバース空間内の移動先に対応付けられた選択肢（以下、他の選択肢と区別する場合は、「移動型選択肢」と称する）（第１選択肢の一例）を含んでよい。なお、移動型選択肢は、複数やり取りされる会話における毎回の返信タイミングで提示されてもよいし、一部の返信タイミングだけで提示されてもよい。例えば、送信内容がメタバース空間内での移動を提案する内容である場合、当該送信内容に基づいて生成される複数の選択肢に、移動型選択肢が含められてもよい。あるいは、上述したように、送信内容に対する応答として意味をなさない選択肢として、移動型選択肢が含められてもよい。

移動型選択肢に対応付けられるメタバース空間内の移動先は、メタバース空間内の任意の場所であってよい。例えば、問いかけＡ＝今から場所Ａに行かない？に対して、移動型選択肢に対応付けられるメタバース空間内の移動先は、メタバース空間内の場所Ａであってもよいし、場所Ａの入口であってもよい。後者は、場所Ａが、入口を有する比較的大きい施設である場合に好適である。また、場所Ａが、チケットなどの権限を有するユーザ（アバター）だけが入れる施設等である場合、移動型選択肢に対応付けられるメタバース空間内の移動先は、チケット販売所などの権限取得場所であってもよい。

移動型選択肢についても、提示される各ユーザに対応付けられている任意のパラメータに基づいて、ユーザごとに異なりうる態様で、生成されてもよい。例えば、問いかけＡ＝今から場所Ａに行かない？に対して、場所Ａが有料施設等である場合であって、対応するユーザの所持金が不足している場合、当該ユーザに提示される移動型選択肢に対応付けられるメタバース空間内の移動先は、銀行やＡＴＭ等であってもよい。この場合、銀行やＡＴＭ等で所持金の不足が解消された際に、新たな選択肢が生成されてもよい。この場合、当該ユーザに提示される移動型選択肢に対応付けられるメタバース空間内の移動先は、場所Ａであってもよい。他方、対応するユーザの所持金が不足していない場合、当該ユーザに提示される移動型選択肢に対応付けられるメタバース空間内の移動先は、場所Ａであってもよい。

移動型選択肢は、移動先へのリンクを含んでよい。この場合、当該移動先への移動を望むユーザは、当該リンクを利用して移動先への移動を実現できるので、利便性が向上する。移動先へのリンクは、移動先自体が同じあっても、アクセスに利用する端末装置２０（すなわち利用デバイス）に応じて異なりうる。例えば、利用デバイスがヘッドマウントディスプレイである場合と、利用デバイスがスマートフォンである場合とで、リンクが異なってもよい。また、リンクは、利用するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やプラットフォーム等に応じて異なりうる各種のディープリンクが利用されてもよい。

なお、移動型選択肢は、対応する送信内容に含まれうるリンクに対応付けられてもよい。例えば、対応する送信内容が、「今から場所Ａに行かない？」というメッセージとともに、その場所に係るＵＲＬ表示を含む場合、移動型選択肢は、当該ＵＲＬ表示に係るリンクに対応付けられてよい。

このような移動型選択肢がユーザにより選択される場合、すなわち移動型選択肢に基づく応答（第１応答の一例）がなされた場合）、当該応答がなされた移動型選択肢に対応付けられた移動先への移動関連処理が実行されてよい。

移動関連処理は、移動先へ移動させる処理、及び、移動先への移動を可能とする表示を出力する処理のうちの少なくともいずれか一方を含んでよい。移動先へ移動させる処理は、移動型選択肢がユーザにより選択される場合に、無条件に実行される自動処理であってもよいし、更なる条件下で実行される処理であってもよい。移動先への移動を可能とする表示を出力する処理も同様である。移動先への移動を可能とする表示は、リンク自体であってもよいし、リンクを実行するための所定入力を受け付けるためのユーザインタフェースであってもよい。なお、移動先への移動を可能とする表示（ユーザインタフェース）を出力する処理の場合、ユーザは、当該表示を見て所定入力を行うことで、移動先への移動を実現可能とされてもよい。

図８は、移動関連処理の説明図であって、複数の選択肢に関連した説明図である。

図８には、図７に示したような、“問いかけＡ”に対して４つの選択肢ＳＴＭ１からＳＴＭ４が示されている。ここでは、問いかけＡ＝今から場所Ａに行かない？であるとする。

選択肢ＳＴＭ１は、“いいよ（ＯＫ）”という意味がある“Ｈｉ！”という文字等を含むため、応答の意味をなすメッセージを含む移動型選択肢である。このような選択肢ＳＴＭ１が選択された場合、図８に示すように、場所Ａに対応するリンク（ここでは、「ｈｔｔｐｓ：／／ａａａａ」）が実行される（すなわち、リンクｈｔｔｐｓ：／／ａａａａを踏む）ことで、場所Ａへの移動が、移動関連処理として実現されてよい（ステップＳ８００）。なお、当該リンクは、ユーザの端末装置２０やアプリケーションによって処理が変わる形態のリンクであってもよい。この場合、当該リンクを踏んだユーザの端末装置２０は、選択肢ＳＴＭ１を選択した際にユーザが利用している端末装置２０となる。また、選択肢ＳＴＭ１に対応付けられるリンクは、当該リンクが記載されたチャットに参加しているユーザのみがアクセス可能なものであってもよい。また、選択肢ＳＴＭ１に対応付けられるリンクは、フレンド同士の合言葉のようなパスワードの入力を条件として有効化されてもよい。この場合、意図しない第３者の参加等を防止できる。また、選択肢ＳＴＭ１に対応付けられるリンクは、待ち合わせ時間等に応じた有効期限が設定されてもよい。

選択肢ＳＴＭ２は、“否（ＮＯ）”という意味がある“Ｂｙｅ！”という文字等を含むため、応答の意味をなすメッセージを含む選択肢であるが、“否”であるがゆえに、移動先に対応付けられない選択肢である。この場合、移動関連処理は禁止されてもよい。なお、このような“断り”を表す返信がなされる場合、ユーザＢが伝言等を残すことが可能な場所へのリンクが提示されてもよい。この場合、ユーザＢが伝言や動画（例えば、お断りの伝言や動画）を残した場合、当該リンクがユーザＡ（“問いかけＡ”をしたユーザ）に送信されてもよい。

選択肢ＳＴＭ３は、“いいよ（ＯＫ）”という意味があるグーマーク（ＯＫサイン）を手で出している絵を含むため、応答の意味をなすメッセージを含む移動型選択肢である。また、選択肢ＳＴＭ３は、ヘッドマウントディスプレイの絵を含むため、利用デバイスを示唆する情報を含む。このような選択肢ＳＴＭ３が選択された場合、図８に示すように、利用デバイスに係る条件が満たされた場合（ステップＳ８０１の“ＹＥＳ”）に、図８に示すように、場所Ａに対応するリンク（ここでは、「ｈｔｔｐｓ：／／ａａａａ」）が実行されてもよい。この場合、利用デバイスに係る条件は、対応する利用デバイスが利用された場合に満たされてよい。すなわち、本例の場合、ユーザＢがヘッドマウントディスプレイを装着した場合に、場所Ａに対応するリンク（ここでは、「ｈｔｔｐｓ：／／ａａａａ」）が実行されることで、場所Ａへの移動が、移動関連処理として実現されてよい（ステップＳ８０２）。

選択肢ＳＴＭ４は、“否（ＮＯ）”という意味がある“おやすみなさい”という文字等を含むため、応答の意味をなすメッセージを含む選択肢であるが、“否”であるがゆえに、移動先に対応付けられない選択肢である。この場合、移動関連処理は禁止されてもよい。なお、ユーザＢが就寝中である場合、選択肢ＳＴＭ４が自動的に選択されてもよい。ユーザＢが就寝中であるか否かは、例えばユーザＢに装着されうる生体センサからのセンサ情報等に基づいて判定されてもよい。

図９は、移動関連処理の説明図であって、複数の選択肢に関連した説明図である。

図９には、“問いかけＡ１”に対して４つの選択肢ＳＴＭ１からＳＴＭ４が示されている。ここでは、問いかけＡ１＝「今から場所Ａに行かない？ドレスコードは赤い服」であるとする。選択肢ＳＴＭ２、ＳＴＭ４について、図８を参照して上述した例と同じであってよく、説明を省略する。

選択肢ＳＴＭ１は、“いいよ（ＯＫ）”という意味がある“Ｈｉ！”という文字等を含むため、応答の意味をなすメッセージを含む移動型選択肢である。このような選択肢ＳＴＭ１が選択された場合、図８に示すように、場所Ａに対応するリンクが直ちに実行されてもよいが、“ドレスコードは赤い服”に対応したアイテム調達の要否が判定されてもよい（ステップＳ９００）。すなわち、ユーザＢが、赤い服（対応するアバターに着せる赤い服）を有しているか否かを判定してもよい。判定の結果、アイテム調達が不要であると判定された場合、そのまま、場所Ａに対応するリンクが実行されてもよい（ステップＳ９０２）。ただし、赤い服が複数ある場合、ユーザＢに対して、どの服を着用するかが選択されてもよい。また、ユーザＢが、赤い服を有しているが、新たな赤い服を調達したい場合、ユーザからの指示に応じて、ステップＳ９０１に進むことができてもよい。他方、判定の結果、例えばユーザＢが赤い服を有しておらず、アイテム調達が必要であると判定された場合、赤い服を調達できる別の場所（例えば服屋）に係るリンク（ここでは、「ｈｔｔｐｓ：／／ｂｂｂｂ」）が実行されてもよい（ステップＳ９０１）。なお、赤い服を調達できる別の場所が複数ある場合、ユーザＢにより選択可能とされてもよい。なお、ここでは、赤い服について説明したが、赤い靴や赤い帽子など、他のアイテムが考慮されてもよい。また、赤い服を調達できる別の場所は、お店（例えば服屋）に限られず、任意である。例えば、赤い服を調達できる別の場所への移動は、赤い服を調達できる抽選ゲーム（ガチャ）の実行により実現されてもよい。また、赤い服を調達できる別の場所は、赤い服を調達できるレンタルやアイテム交換が可能な場所であってもよい。アイテム交換が可能な場所への移動は、交換するための掲示板や赤い服を所有しているユーザとのチャット画面への遷移により実現されてもよい。

選択肢ＳＴＭ３は、選択肢ＳＴＭ１と同様、応答の意味をなすメッセージを含む移動型選択肢である。この場合も、図８を参照して上述した例と同様、利用デバイスに係る条件が判定されてよく（ステップＳ９１０）、利用デバイスに係る条件が満たされた場合（ステップＳ９１０の“ＹＥＳ”）に、図９に示すように、アイテム調達の要否が判定されてもよい（ステップＳ９１１）。以下のステップＳ９１２、ステップＳ９１３は、選択肢ＳＴＭ１の場合のステップＳ９０１、ステップＳ９０２とそれぞれ同様である。

このようにして本実施形態では、移動型選択肢に基づき応答がなされた場合に、移動型選択肢に対応付けられた移動先への移動関連処理が実行されるので、ユーザは、移動先へのアクセスのためのリンクを探す手間が省け、利便性が向上する。また、選択された移動型選択肢が、利用デバイスを表すメッセージ等を含む場合は、利用デバイスに係る条件が判定されることで、ユーザの意図しない端末装置２０の利用に基づいて、移動先へのアクセスが実現されてしまうことを防止できる。また、移動型選択肢に対応する送信内容に、アイテムに関する情報が含まれる場合に、アイテム調達の要否が判定されるので、ユーザの意図しないタイミング（例えば準備が整っていないタイミング）で、移動先へのアクセスが実現されてしまうことを防止できる。このようなユーザの望まないアクセスを防止することで、処理負荷を低減できる。

また、本実施形態では、複数の選択肢は、上述した選択肢ＳＴＭ１やＳＴＭ３のような、選択された場合に選択したユーザのステータスが変化する選択肢（第１選択肢の一例）以外にも、上述した選択肢ＳＴＭ２やＳＴＭ４のような、選択された場合でも選択したユーザのステータスが変化しない選択肢（第２選択肢の一例）を含んでよい。これにより、ステータスの変化を伴う選択肢を望まないタイミングや、逆に、ステータスの変化を伴う選択肢を望むタイミングなど、多様なタイミングに適合できる選択肢をユーザに提示できる。

なお、本実施形態において、メタバース空間に一のユーザが位置するときに、当該一のユーザに対して、他のユーザから新たな送信内容が送信された場合も、上述した複数の選択肢が、当該一のユーザに提示されてもよい。

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

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

図１０は、選択肢関連機能に関連したサーバ装置１０の機能ブロック図の一例である。図１１は、ユーザ情報記憶部１４２内のデータの説明図である。図１２は、アバター情報記憶部１４４内のデータの説明図である。

サーバ装置１０は、図１０に示すように、ユーザ情報記憶部１４２及びアバター情報記憶部１４４を含む。なお、ユーザ情報記憶部１４２及びアバター情報記憶部１４４は、図１に示したサーバ記憶部１２により実現できる。

また、サーバ装置１０は、図１０に示すように、ユーザ入力取得部１５０と、アバター処理部１５２と、描画処理部１５６とを含む。ユーザ入力取得部１５０から描画処理部１５６は、図１に示したサーバ制御部１３により実現できる。

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

ユーザ情報記憶部１４２には、各ユーザに関する情報が記憶される。各ユーザに関する情報は、例えばユーザ登録時に生成されてよく、その後、適宜、更新等されてよい。例えば、図１１に示す例では、ユーザ情報記憶部１４２には、ユーザＩＤに対応付けて、ユーザ名、アバターＩＤ、プロフィール情報、所持デバイス情報、ステータス情報等が記憶されている。

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

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

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

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

所持デバイス情報は、ユーザが所持する端末装置２０に関する情報を含む。複数種類の端末装置２０を有しているユーザには、対応する複数種類の端末装置２０を特定可能な情報が、所持デバイス情報として記憶される。

ステータス情報は、ユーザの現在のステータスを表す情報を含む。

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

ユーザ入力取得部１５０は、各ユーザによる各種ユーザ入力を、対応するユーザの端末装置２０との通信を介して取得する。各種入力は、上述したとおりである。なお、各ユーザのステータスや利用デバイスは、ユーザ入力取得部１５０により取得されるユーザ入力（及び当該ユーザ入力とともに送信されうる端末情報等）に基づいて判定されてもよい。ユーザ入力取得部１５０は、その他、ユーザの所持デバイス情報（後述）やステータス情報（後述）等を更新するための情報を取得してもよい。

アバター処理部１５２は、アバターごとに、対応する各ユーザによる各種入力に基づいて、アバターの動作（位置の変化や各部位の動き等）を決定する。また、アバター処理部１５２は、アバター間のチャット（会話）をメタバース空間内で実現してもよい。

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

図１３は、選択肢関連機能に関連した一の端末装置２０の機能ブロック図の一例である。以下では、自ユーザとは、対応する一の端末装置２０を所持するユーザであるとする。なお、一のユーザは、多様な種類の端末装置２０を有しうる。従って、一の端末装置２０に係る自ユーザと、他の一の端末装置２０に係る自ユーザとは、同一となりうる。

なお、以下で説明する端末装置２０の機能の一部又は全部は、適宜、サーバ装置１０により実現されてもよい。例えば、選択肢生成部２６２やアイテム判定部２６４の機能の一部又は全部は、サーバ装置１０により実現されてもよい。また、自ユーザ情報記憶部２７０及び所持アイテム記憶部２７２の区分けや、操作入力取得部２６０から支援処理部２６８の区分けは、説明の都合上であり、一部の機能部が、他の機能部の機能を実現してもよい。

端末装置２０は、操作入力取得部２６０と、送信内容取得部２６１（取得部の一例）と、選択肢生成部２６２と、アイテム判定部２６４（判定部の一例）と、応答処理部２６６と、支援処理部２６８と、自ユーザ情報記憶部２７０と、所持アイテム記憶部２７２とを含む。操作入力取得部２６０から支援処理部２６８は、図１に示した端末制御部２５により実現できる。自ユーザ情報記憶部２７０及び所持アイテム記憶部２７２は、図１に示した端末記憶部２２により実現できる。

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

送信内容取得部２６１は、上述したように他ユーザからの送信内容を受信する。なお、送信内容は、上述したように、自ユーザを含む複数のユーザ間のチャット形式のコミュニケーションに関する。

選択肢生成部２６２は、上述したように他ユーザからの送信内容に基づいて、図６等を参照して上述した複数の選択肢を生成し、自ユーザに提示する。選択肢生成部２６２は、生成した複数の選択肢を表示部２３に表示することで、自ユーザに提示してよい。例えば、選択肢生成部２６２は、チャット画面において、時系列順の最新の位置付近に、複数の選択肢を位置付けて重畳表示させてもよい。

選択肢生成部２６２は、上述したように、送信内容に基づいて移動型選択肢を生成する。例えば、上述した例のように、送信内容が、「今から場所Ａに行かない？」である場合、選択肢生成部２６２は、場所Ａに対応付けられた移動型選択肢を生成する。移動型選択肢は、例えば、場所Ａへの移動が可能なリンクを含んでもよい。この場合、なお、場所Ａへの移動が可能なリンクが、送信内容に含まれている場合は、当該リンクが利用されてもよい。他方、場所Ａへの移動が可能なリンクが、送信内容に含まれていない場合、場所Ａへの移動が可能なリンクは、選択肢生成部２６２により生成されてもよい。この場合、当該リンクは、自ユーザが有する端末装置２０の種類ごとに生成されてもよい。

選択肢生成部２６２は、上述したように、自ユーザに対応付けられている任意のパラメータに基づいて、複数の選択肢を生成してもよい。すなわち、選択肢生成部２６２は、自ユーザが所持する端末装置２０の種類、自ユーザが所持するメタバース空間内のアイテム、自ユーザのステータス、及び、自ユーザと送信側ユーザ（今回の選択肢に係る送信内容を送信した他ユーザ）との関係のうちの、少なくともいずれか１つを含んでよい。

例えば、選択肢生成部２６２は、選択肢に利用予定の端末装置２０を含ませる場合に、自ユーザが所持する端末装置２０の種類に基づいて、利用予定の端末装置２０を決定してもよい。例えば、上述した例のように、送信内容が、「今から場所Ａに行かない？」である場合、複数の選択肢がメッセージ「〇〇で行くね！」を含む場合、メッセージに含まれる○○は、自ユーザの所持する端末装置２０の種類に応じて決定されてもよい。例えば、自ユーザの所持する端末装置２０の種類が、スマートフォン及びヘッドマウントディスプレイである場合、「スマホでいくね！」と「ＨＭＤでいくね！」の２種類が生成されてもよい。この場合、例えば、自ユーザが所持していない種類の端末装置２０に係るメッセージ、例えば「タブレットでいくね！」といったメッセージを含む選択肢が生成されない。これにより、複数の選択肢の精度（自ユーザに選択される可能性）を高めることができる。更に、同様の観点から、自ユーザの過去の利用デバイスの使用時間帯の傾向を分析して、待ち合わせ時間に合わせて利用可能性の高いデバイスを示す選択肢を優先表示させてもよい。
また、選択肢生成部２６２は、更に、スマートフォンと他の端末装置２０とがＢｌｕｅｔｏｏｔｈ（登録商標）等で連携されているかどうかに応じて、利用予定の端末装置２０を決定してもよい。これは、ヘッドマウントディスプレイを所有していても、その時に所持してなければ（例えば家にいなければ）ヘッドマウントディスプレイを利用できないためである。また、外出中等のような、ヘッドマウントディスプレイを即座に装着できない状況下において、例えばユーザがＡＲグラスをすでに装着している状態であるときは、ＡＲグラスを利用予定の端末装置２０として決定してもよい。
また、選択肢生成部２６２は、更に、ユーザの現在地情報に基づいて、ユーザの現在地が自宅、会社、それ以外（移動中）等に応じて、利用予定の端末装置２０を決定してもよい。これは、上述したように、ヘッドマウントディスプレイを所有していても、その時に所持してなければ（例えば自宅にいなければ）ヘッドマウントディスプレイを利用できないためである。例えば、ユーザの現在地が会社であれば、文字のみ又は音声のみでの対応が可能なスマートフォンが利用予定の端末装置２０として決定され、ユーザの現在地が自宅であれば、ヘッドマウントディスプレイが利用予定の端末装置２０として決定され、ユーザの現在地が変化中（すなわち移動中）であれば、ＡＲグラスとスマートフォンの組み合わせが利用予定の端末装置２０として決定されてよい。なお、ＡＲグラスとスマートフォンの組み合わせは、移動中の場合のように、文字のみもしくは音声を聴くことができるが話すことができないといった状況に好適となる。なお、ユーザの現在地情報は、ユーザのステータス情報の一部としてユーザ入力取得部１５０により取得されてもよい。

また、例えば、選択肢生成部２６２は、自ユーザが所持するメタバース空間内のアイテムに応じて、選択肢に含ませてもよいアイテム名を決定してもよい。例えば、上述した例のように、送信内容が、「今から場所Ａに行かない？ドレスコードは赤い服」である場合、複数の選択肢がメッセージ「△△で行くね！」を含む場合、メッセージに含まれる△△は、自ユーザの所持するアイテムに応じて決定されてもよい。例えば、自ユーザの所持するアイテムの種類が、赤のワンピース及び赤のチャイニーズドレスである場合、「ワンピでいくね！」と「ドレスでいくね！」の２種類が生成されてもよい。この場合、例えば、自ユーザが所持していない種類のアイテムに係るメッセージ、例えば「赤スーツでいくね！」といったメッセージを含む選択肢が生成されない。これにより、複数の選択肢の精度（自ユーザに選択される可能性）を高めることができる。なお、自ユーザが赤のアイテムを有していない場合は、それに応じて、「赤い服、買ってからいくね！」といった選択肢が生成されてもよい。

また、例えば、選択肢生成部２６２は、自ユーザのステータスに応じて、当該ステータスを伝達するための選択肢を生成してもよい。例えば、自ユーザが就寝前である場合、選択肢生成部２６２は、“おやすみ”というメッセージを含む選択肢を生成してもよい。また、自ユーザが移動中である場合、選択肢生成部２６２は、“家についたら連絡するね”というメッセージを含む選択肢を生成してもよい。なお、移動中か否かは、端末装置２０に内蔵されうる加速度センサや位置センサ（例えばＧＰＳ受信機に基づく位置センサ）からのセンサ情報に基づいて判定されてよい。

また、例えば、選択肢生成部２６２は、自ユーザと送信側ユーザ（今回の選択肢に係る送信内容を送信した他ユーザ）との関係に応じて、選択肢に含まれるメッセージの表現方法（言葉遣いなど）を変化させてもよい。例えば、送信側ユーザが仕事先のクライアントである場合には、丁寧な言葉遣いのメッセージを含む選択肢が生成され、送信側ユーザが同期である場合には、フランクなメッセージを含む選択肢が生成されてもよい。

その他、選択肢生成部２６２は、進行中のチャットのテーマやチャットのメンバ等に応じて、選択肢自体や、選択肢に含まれるメッセージの表現方法（言葉遣いなど）等を変化させてもよい。

選択肢生成部２６２は、提示した複数の選択肢のうちの、自ユーザにより選択された選択肢情報（実績データ）に基づいて、機械学習を実行してもよい。この際、自ユーザにより選択された選択肢と、選択された際の自ユーザに対応付けられている各パラメータの値との関係が機械学習されてもよい。この場合、自ユーザの好みや選択傾向に適合した選択肢を提示できる。また、時間帯ごとの利用デバイスの傾向等も学習することで、複数の選択肢の精度（自ユーザに選択される可能性）を高めることができる。

また、選択肢生成部２６２は、選択肢に係るスタンプを、自ユーザに係るアバターを利用して生成してもよい。この際、自ユーザに係るアバターの服装に応じて、同じ内容のスタンプであっても、異なる服装のアバターが表現されてもよい。

このようにして本実施例によれば、選択肢生成部２６２により、自ユーザに選択される可能性が高い選択肢を生成できるので、選択肢に対応する応答内容を手動で入力する負荷を低減できることに加えて、端末装置２０を介して所望の選択肢を探し出すユーザ負荷をも低減できる。例えば、自ユーザがスマートフォンを利用している状況下で、選択肢を出すことで、自ユーザは、スマートフォンのような比較的小さな画面内で所望するスタンプを探したりテキストを入力したりする負荷から解放される。その結果、自ユーザは、チャット中に迅速に所望する返答をすることができる。また、例えば自ユーザがヘッドマウントディスプレイを利用している状況下では、自ユーザは、コントローラを使ってバーチャルキーボードでタイピングしたりする負荷から解放される。その結果、自ユーザは、チャット中に迅速に所望する返答をすることができる。なお、本実施例において、選択肢生成部２６２により一度に生成される選択肢の数は、出力される端末装置２０の種類に応じて変化されてもよい。例えば、スマートフォンのような比較的小さな画面を有する端末装置２０を自ユーザが利用している状況下では、選択肢生成部２６２により一度に生成される選択肢の数は、比較的少なくてよい。

アイテム判定部２６４は、移動型選択肢に基づく応答が自ユーザによりなされた場合に、自ユーザが、所定アイテムを所持しているか否かを判定する。所定アイテムは、アバターに装着可能なアイテムのうちの、所定条件を満たすアイテムであってよい。所定条件は、送信内容取得部２６１により取得した送信内容に基づいて設定されてよい。例えば、上述した例のように、送信内容が、「今から場所Ａに行かない？ドレスコードは赤い服」である場合、所定条件を満たすアイテムは、“赤い色の服”等に設定されてよい。また、送信内容が、「今から場所Ａに行かない？今日の色は赤」である場合、所定条件を満たすアイテムは、“赤い色を有する任意のアイテム”等に設定されてよい。

また、アイテム判定部２６４は、移動型選択肢に基づく応答が自ユーザによりなされた場合であって、移動型選択肢が利用デバイスを含む場合に、自ユーザが、当該利用デバイスに対応する端末装置２０を利用開始したか否かを判定する。例えば、応答に係る移動型選択肢が「ＨＭＤでいくね！」を含む場合、アイテム判定部２６４は、自ユーザがヘッドマウントディスプレイを利用しているか否かを判定する。なお、この場合、アイテム判定部２６４は、サーバ装置１０からの情報に基づいて、利用デバイスを判定してもよい。

応答処理部２６６は、自ユーザによる入力に基づいて、上述した複数の選択肢のうちの一の選択肢が選択された場合に、当該一の選択肢に基づく応答を行うとともに、当該一の選択肢に応じて後続処理を実行してよい。当該一の選択肢に応じて後続処理は、当該一の選択肢の属性（例えば上述した直接応答型、間接応答型等）に応じて決定されてもよい。例えば、当該一の選択肢が、上述した所定フラグの値“０”が対応付けられた選択肢である場合と、所定フラグの値“１”が対応付けられた選択肢である場合とで、異なる後続処理が実行されてもよい。所定フラグの値“１”が対応付けられた選択肢（送信内容に対する応答として意味をなす選択肢）の場合、なんらかの後続処理（例えば、自ユーザに係るアバターを遷移する処理や、自ユーザに係るアバターをチャットの参加者のリストに追加する処理など）が実行されてよい。他方、所定フラグの値“０”が対応付けられた選択肢（送信内容に対する応答として意味をなさない選択肢）の場合、なんら後続処理が実行されなくてもよい。

例えば、応答処理部２６６は、自ユーザによる入力に基づいて、上述した移動型選択肢に基づく応答がなされた場合、当該応答に応じた移動関連処理を実行する。移動関連処理は、上述したとおりである。例えば、自ユーザによる応答に係る移動型選択肢が「ＨＭＤでいくね！」を含む場合、応答処理部２６６は、アイテム判定部２６４によりヘッドマウントディスプレイの利用が検出された場合に、移動関連処理を実行してもよい。これにより、ヘッドマウントディスプレイを着用してからの移動先の選択操作などが必要でなくなり、自ユーザはスムーズに所望の移動を実現できる。また、メタバース空間での待ち合わせ場所への移動も選択肢の選択によって自動的に行われることで、ヘッドマウントディスプレイを付けての移動が減り、ユーザのＶＲ酔いなどの負荷を軽減することができる。

また、応答処理部２６６は、常時接続モードにおいて、自動的に送信内容に対する返信内容に関する選択肢を決定し、かつ、当該選択肢に基づく応答（第２応答の一例）を自動的に行ってもよい。常時接続モードとは、上述した常時接続状態が形成されるモードである。なお、動作モードは、常時接続モード以外にも複数のモードが設定可能であってよい。常時接続モードは、自ユーザからの入力に応じて形成されてもよいし、自ユーザのステータスに応じて自動的に形成されてもよい。後者の場合、例えば自ユーザが就寝中や食事中である場合等、あらかじめ規定されたステータスである場合に、常時接続モードが自動的に形成されてもよい。

また、応答処理部２６６は、常時接続モードにおいて、自ユーザのステータスを他のユーザに通知する機能を実現してもよい。例えば、応答処理部２６６は、自ユーザのステータスの変化があった場合に、その旨を表す応答を自動的に行ってもよい。具体的には、自ユーザが、ヘッドマウントディスプレイの装着状態へ変化した場合、その旨を表すメッセージやスタンプ等が、常時接続モードに係るチャットルームに投稿してもよい。かかるステータスの変化の自動的な応答は、移動型選択肢に基づく応答がなされた場合に実行されてもよい。この場合、自ユーザのステータスを気にする他のユーザに、自ユーザの状態（例えばもうすぐ待ち合わせ場所に着くのかどうかに係る各種状態）を自動的に知らせることができる。その結果、各ユーザが待ち合わせ等に係るやり取りのための入力や通信を効率化でき、処理負荷を低減できる。

支援処理部２６８は、移動型選択肢に基づく応答が自ユーザによりなされた場合に、移動型選択肢に関連した所定アイテムの装着又は取得を支援又は実現する。例えば、支援処理部２６８は、アイテム判定部２６４により自ユーザが所定アイテムを所持していると判定された場合に、自ユーザに係るアバターへの所定アイテムの装着を自動的に実現してもよいし、装着可能な複数の所定アイテムを自ユーザが選択可能となるように提示してもよい。また、支援処理部２６８は、アイテム判定部２６４により自ユーザが所定アイテムを所持していないと判定された場合に、所定アイテムを調達（取得）可能な場所への移動が可能なリンクを生成したり、当該場所への自動的に移動を実現したりしてもよい。

自ユーザ情報記憶部２７０は、上述したサーバ装置１０のユーザ情報記憶部１４２において記憶される各ユーザに関する情報のうちの、自ユーザに関する情報が記憶される。なお、端末装置２０には、自ユーザ以外にも、例えばフレンド関係にある他ユーザに関する情報の一部が記憶されてもよい。

所持アイテム記憶部２７２は、自ユーザが所持しているアイテムを表す情報が記憶される。アイテムは、自ユーザに係るアバターに装着可能なアイテム（例えば服、靴等）や同アバターの容姿を変化させることが可能なアイテムを含んでよい。

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

１ チャット関連支援システム
３ ネットワーク
１０ サーバ装置
１１ サーバ通信部
１２ サーバ記憶部
１３ サーバ制御部
２０ 端末装置
２１ 端末通信部
２２ 端末記憶部
２３ 表示部
２４ 入力部
２５ 端末制御部
１４２ ユーザ情報記憶部
１４４ アバター情報記憶部
１５０ ユーザ入力取得部
１５２ アバター処理部
１５６ 描画処理部
２６０ 操作入力取得部
２６１ 送信内容取得部
２６２ 選択肢生成部
２６４ アイテム判定部
２６６ 応答処理部
２６８ 支援処理部
２７０ 自ユーザ情報記憶部
２７２ 所持アイテム記憶部

Claims (16)

1. 複数のユーザ間のチャット形式のコミュニケーションに係る情報処理を行う情報処理システムであって、
   送信側から送信される送信内容を取得する取得部と、
   前記送信内容に対する受信側からの返信内容に関する複数の選択肢を生成する選択肢生成部とを備え
   前記複数の選択肢は、電子機器を介して視認可能な仮想空間内の移動先に対応付けられた第１選択肢を含み、
   一のチャットにおいて前記移動先は、前記送信内容に基づいて決定される、情報処理システム。
2. 一の前記第１選択肢に基づく第１応答がなされた場合に、前記第１応答がなされた前記第１選択肢に対応付けられた前記移動先への移動関連処理を実行する応答処理部を更に備え、
   前記移動関連処理は、前記移動先へ移動させる処理、及び、前記移動先への移動を可能とする表示を出力する処理のうちの少なくともいずれか一方を含む、請求項１に記載の情報処理システム。
3. 前記応答処理部は、前記移動先へのリンクを生成する、請求項２に記載の情報処理システム。
4. 前記応答処理部は、複数種類の前記電子機器のうちの前記受信側のユーザにより利用される前記電子機器の種類に応じた前記リンクを生成する、請求項３に記載の情報処理システム。
5. 前記第１選択肢は、一の前記送信内容に対して複数生成され、
   複数の前記第１選択肢のうちの少なくとも１つは、前記受信側が所持する電子機器、前記受信側が所持する仮想空間内のアイテム、前記受信側のステータス、及び、前記受信側と前記送信側との関係のうちの、少なくともいずれか１つの第１パラメータに基づいて生成される、請求項１に記載の情報処理システム。
6. 前記第１選択肢は、ネットワークに接続可能な一の電子機器を表す又は示唆するメッセージ又は文字、記号若しくは画像を含み、
   前記第１選択肢に基づく前記第１応答がなされた場合に、前記一の電子機器が利用されたか否かを判定する判定部を更に含み、
   前記応答処理部は、前記判定部により前記一の電子機器が利用されたと判定された場合に、前記移動関連処理を実行する、請求項２に記載の情報処理システム。
7. 前記画像は、チャットのスタンプを含む、請求項６に記載の情報処理システム。
8. 前記複数の選択肢は、前記受信側のステータスの変更を伴う前記第１選択肢、又は、前記受信側のステータスの変更を伴わない第２選択肢を含む、請求項１に記載の情報処理システム。
9. 前記複数の選択肢は、応答としての意味があるか否かに関連する第２パラメータの値に関して、第１の値が対応付けられた第３選択肢と、前記第１の値とは異なる第２の値が対応付けられた第４選択肢とを含む、請求項１に記載の情報処理システム。
10. 一の前記第１選択肢に基づく第１応答がなされた場合に、前記第１応答がなされた前記第１選択肢に対応付けられた所定アイテムの装着又は取得を支援又は実現する支援処理部を更に備える、請求項１に記載の情報処理システム。
11. 一の前記第１選択肢に基づく前記第１応答がなされ、かつ、前記所定アイテムの装着又は取得が実現された場合に、前記第１応答がなされた前記第１選択肢に対応付けられた前記移動先への移動関連処理を実行する応答処理部を更に備え、
    前記移動関連処理は、前記移動先へ移動させる処理、及び、前記移動先への移動を可能とする表示を出力する処理のうちの少なくともいずれか一方を含む、請求項１０に記載の情報処理システム。
12. 前記所定アイテムは、前記送信内容に基づいて決定される、請求項１０に記載の情報処理システム。
13. 前記受信側が所持する前記電子機器は、ネットワークに接続した状態を維持する常時接続モードを有し、
    前記応答処理部は、前記常時接続モードにおいて、自動的に前記送信内容に対する前記返信内容に関する選択肢を決定し、かつ、前記選択肢に基づく第２応答を自動的に行う、請求項２、３、４、７、１１のうちのいずれか１項に記載の情報処理システム。
14. 前記応答処理部は、前記常時接続モードにおいて、前記受信側のユーザの状態が所定状態である場合に、自動的に前記第２応答を行う、請求項１３に記載の情報処理システム。
15. 複数のユーザ間のチャット形式のコミュニケーションに係る情報処理用のプログラムであって、
    送信側から送信される送信内容を取得する取得処理と、
    前記送信内容に対する受信側からの返信内容に関する複数の選択肢を生成する選択肢生成処理とを、コンピュータに実行させ、
    前記複数の選択肢は、電子機器を介して視認可能な仮想空間内の移動先に対応付けられた第１選択肢を含み、
    一のチャットにおいて前記移動先は、前記送信内容に基づいて決定される、プログラム。
16. 複数のユーザ間のチャット形式のコミュニケーションに係る情報処理方法であって、
    送信側から送信される送信内容を取得し、
    前記送信内容に対する受信側からの返信内容に関する複数の選択肢を生成することを含み、
    前記複数の選択肢は、電子機器を介して視認可能な仮想空間内の移動先に対応付けられた第１選択肢を含み、
    一のチャットにおいて前記移動先は、前記送信内容に基づいて決定される、情報処理方法。

Images