特許法第30条第2項適用 (1)ウェブサイトの掲載日:令和3年(2021年)12月21日 ・ウェブサイトのアドレス: https://youtu.be/0eKx-mlRNd4 (2)ウェブサイトの掲載日:令和4年(2022年)1月20日 ・ウェブサイトのアドレス: https://note.com/reality_eng/n/nc63e1665affa?magazine_key=m394ac85738b5
以下、実施形態について図面を参照して説明する。
図1を参照して、本発明の一実施形態に係る仮想現実生成システム1の概要について説明する。図1は、本実施形態に係る仮想現実生成システム1のブロック図である。図2は、ヘッドマウントディスプレイを介して視認可能な端末用画像の説明図である。
仮想現実生成システム1は、サーバ装置10と、1つ以上の端末装置20と、を備える。図1では簡便のため、3つの端末装置20を図示しているが、端末装置20の数は2つ以上であればよい。
サーバ装置10は、例えば1つ以上の仮想現実を提供する運営者が管理するサーバ等の情報処理システムである。端末装置20は、例えば携帯電話、スマートフォン、タブレット端末、PC(Personal Computer)、ヘッドマウントディスプレイ、又はゲーム装置等の、ユーザによって使用される装置である。端末装置20は、典型的にはユーザごとに異なる態様で、複数がサーバ装置10にネットワーク3を介して接続されうる。
端末装置20は、本実施形態に係る仮想現実アプリケーションを実行可能である。仮想現実アプリケーションは、ネットワーク3を介してサーバ装置10や所定のアプリケーション配信サーバから端末装置20に受信されてもよく、あるいは端末装置20に備えられた記憶装置又は端末装置20が読取可能なメモリカード等の記憶媒体にあらかじめ記憶されていてもよい。サーバ装置10及び端末装置20は、ネットワーク3を介して通信可能に接続される。例えば、サーバ装置10及び端末装置20が協動して、仮想現実に関する多様な処理を実行する。
仮想現実生成システム1では、利用するユーザを主催側(コンテンツ配信側)と参加側(コンテンツ視聴側)に区別してもよいし、両者を区別せずに各ユーザが対等の立場で利用するようにしてもよい。ユーザが主催側と参加側に区別される場合には、端末装置20は、主催側(コンテンツ配信側)の端末装置20Aと、参加側(コンテンツ視聴側)の端末装置20Bとを含む。ユーザが主催側と参加側に区別されない場合には、端末装置20は、主催側の端末装置20Aと、参加側の端末装置20Bとに区別されない。なお、以下では、説明上、主催側の端末装置20Aと、参加側の端末装置20Bとは、別々の端末装置として説明するが、主催側の端末装置20Aが、参加側の端末装置20Bとなる場合や、その逆の場合もありうる。なお、以下では、端末装置20A及び端末装置20Bとを特に区別しない場合は、単に「端末装置20」と称する場合がある。
各端末装置20は、サーバ装置10を介して互いに通信可能に接続されている。なお、以下では、「一の端末装置20が情報を他の端末装置20に送信する」とは、「一の端末装置20が情報をサーバ装置10を介して他の端末装置20に送信する」ことを意味する。同様に、「一の端末装置20が情報を他の端末装置20から受信する」とは、「一の端末装置20が情報をサーバ装置10を介して他の端末装置20から受信する」ことを意味する。ただし、変形例では、各端末装置20は、サーバ装置10を介さずに通信可能に接続されてもよい。
なお、ネットワーク3は、無線通信網や、インターネット、VPN(Virtual Private Network)、WAN(Wide Area Network)、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでよい。
図1に示す例では、仮想現実生成システム1は、スタジオユニット30A、30Bを含む。スタジオユニット30A、30Bは、主催側の端末装置20Aと同様、主催側の装置である。スタジオユニット30A、30Bは、コンテンツ制作用のスタジオ、部屋、ホール等に配置され得る。
各スタジオユニット30は、主催側の端末装置20A、及び/又は、サーバ装置10と同様の機能を有することができる。以下、主催側と参加側を区別する場合、説明を簡単にするために、主催側の端末装置20Aがサーバ装置10を介して各参加側の端末装置20Bに対して各種のコンテンツを配信する態様を主に説明する。しかしながら、これに代えて又はこれに加えて、主催側ユーザに対向するスタジオユニット30A、30Bが、主催側の端末装置20Aと同様の機能を有することにより、サーバ装置10を介して各参加側の端末装置20Bに対して各種のコンテンツを配信してもよい。なお、変形例では、仮想現実生成システム1は、スタジオユニット30A、30Bを備えていなくてもよい。
以下では、仮想現実生成システム1が、情報処理システムの一例を実現するが、特定の一の端末装置20の各要素(図1の端末通信部21~端末制御部25参照)が、情報処理システムの一例を実現してもよいし、複数の端末装置20が、協動して情報処理システムの一例を実現してもよい。また、サーバ装置10が単独で、情報処理システムの一例を実現してもよいし、サーバ装置10と1つ以上の端末装置20が、協動して情報処理システムの一例を実現してもよい。
ここで、本実施形態に係る仮想現実の概要について説明する。本実施形態に係る仮想現実は、例えば教育、旅行、ロールプレイング、シミュレーション、ゲームやコンサートのようなエンターテイメント等、任意の現実に対する仮想現実等であって、仮想現実の実行に伴い、アバターのような仮想現実媒体が用いられる。例えば、本実施形態に係る仮想現実は、3次元の仮想空間と、当該仮想空間内に登場する各種の仮想現実媒体と、当該仮想空間内で提供される各種のコンテンツとにより実現される。
仮想現実媒体は、仮想現実に使用される電子データであり、例えば、カード、アイテム、ポイント、サービス内通貨(又は仮想現実内通貨)、トークン(例えばNon-Fungible Token(NFT))、チケット、キャラクタ、アバター、パラメータ等、任意の媒体を含む。また、仮想現実媒体は、レベル情報、ステータス情報、パラメータ情報(体力値及び攻撃力等)又は能力情報(スキル、アビリティ、呪文、ジョブ等)のような、仮想現実関連情報であってもよい。また、仮想現実媒体は、ユーザによって仮想現実内で取得、所有、使用、管理、交換、合成、強化、売却、廃棄、又は贈与等され得る電子データであるが、仮想現実媒体の利用態様は本明細書で明示されるものに限られない。
本実施形態では、ユーザが主催側と参加側に区別される場合、ユーザは、各種コンテンツを視聴する参加側ユーザと、後述するモデレータアバターM2を介して後述する特定トークコンテンツ(所定デジタルコンテンツの一例)を配信する主催側ユーザとを含む。ユーザが主催側と参加側に区別されない場合には、対等のユーザが複数含まれる。
なお、主催側ユーザは、参加側ユーザとして、他の主催側ユーザによる特定トークコンテンツを視聴することも可能であるし、逆に、参加側ユーザも、主催側ユーザとして、特定トークコンテンツを配信することも可能でありうる。ただし、以下では、説明の複雑化を防止する都合上、参加側ユーザとは、その時の参加側ユーザであるとし、主催側ユーザは、その時の主催側ユーザであるとする。なお、以下では、主催側ユーザと参加側ユーザとを特に区別しない場合は、単に「ユーザ」と称する場合がある。また、参加側ユーザに係る参加アバターM1とモデレータアバターM2とを特に区別しない場合は、単に「アバター」と称する場合がある。また、以下では、アバターの性質上、ユーザとアバターとは同一視して説明する場合がある。従って、例えば、「一のアバターが〇〇する」は、「一のユーザが〇〇する」と同義である場合がある。
なお、アバターは、典型的には、正面方向を有するキャラクタの形態であり、人や動物又はその類の形態を有してよい。アバターは、各種アバターアイテムに対応付けられることで、多様な容姿(描画されたときの容姿)を有することができる。
参加側ユーザ及び主催側ユーザは、頭部又は顔の一部に装着型装置を装着し、当該装着型装置を介して仮想空間を視認してよい。なお、装着型装置は、ヘッドマウントディスプレイやメガネ型装置であってもよい。メガネ型装置は、いわゆるAR(Augmented Reality)グラスやMR(Mixed Reality)グラスであってよい。いずれの場合でも、装着型装置は、端末装置20とは別であってもよいし、端末装置20の一部又は全部の機能を実現してもよい。端末装置20は、ヘッドマウントディスプレイにより実現されてよい。
あるいは、参加側ユーザ及び主催側ユーザは、スマートフォンやパーソナルコンピュータのような画面を有するデバイスを用いて、表示画面を介して仮想空間を視認してよい。この場合、仮想空間は、実質的に2次元表示で表現されてよい。
以下では、サーバ装置10が配信する各種コンテンツのうちの、ユーザ間(アバター間)の会話が可能な特定トークコンテンツを主に説明する。また、以下の説明では、ヘッドマウントディスプレイやスマートフォン等を介して視聴されることが好適なコンテンツについて説明する。
主催側ユーザによる特定トークコンテンツとは、主催側ユーザ以外のユーザの参加が可能なユーザ参加型のトークコンテンツであり、複数のユーザによる各アバターを介した会話を伴う動画コンテンツである。主催側ユーザによる特定トークコンテンツは、主催側ユーザが決めたテーマに沿って会話を行うタイプのコンテンツであってもよい。また、主催側ユーザによる特定トークコンテンツでは、主催側ユーザに係るモデレータアバターM2であって、主催側ユーザの向きや位置、動き等に応じて向きや位置、動き等を変化させるモデレータアバターM2が仮想空間内に登場してよい。なお、主催側ユーザの向きや位置、動きとは、主催側ユーザの顔や手等の身体の一部や全部の向き、位置、動きのみならず、主催側ユーザの視線の向き、位置、動き又はその類を含む概念である。
主催側ユーザによる特定トークコンテンツは、典型的には、モデレータアバターM2を介して任意の態様で、会話を伴うものである。例えば、主催側ユーザによる特定トークコンテンツは、チャット、会合、集会、会議、又はその類に関連してもてよい。
また、主催側ユーザによる特定トークコンテンツは、2人以上の主催側ユーザによるコラボレーション(以下、「コラボ」と省略)の形態を含んでよい。これにより、多様な態様での配信が可能となり、主催側ユーザ間での交流が促進される。
なお、サーバ装置10は、主催側ユーザによる特定トークコンテンツ以外のコンテンツを配信することも可能である。サーバ装置10が提供するコンテンツ(仮想現実で提供されるコンテンツ)の種類や数は、任意であるが、本実施形態では、一例として、サーバ装置10が提供するコンテンツは、各種の映像のようなデジタルコンテンツを含んでよい。映像は、リアルタイムの映像であってもよいし、非リアルタイムの映像であってもよい。また、映像は、実画像に基づく映像であってもよいし、CG(Computer Graphics)に基づく映像であってもよい。映像は、情報提供用の映像であってよい。この場合、映像は、特定のジャンルの情報提供サービス(旅や、住まい、食品、ファッション、健康、美容等に関する情報提供サービス)、特定のユーザによる放送サービス(例えばYoutube(登録商標))等に関するものであってよい。
仮想現実におけるコンテンツの提供態様は、多様であり、ヘッドマウントディスプレイの表示機能を利用して提供される態様以外であってもよい。例えば、コンテンツが映像である場合、仮想空間内の表示装置(仮想現実媒体)のディスプレイ上に、映像を描画することで、当該コンテンツの提供が実現されてもよい。なお、仮想空間内の表示装置は、任意の形態であり、仮想空間内に設置されるスクリーンや、仮想空間内に設置される大画面ディスプレイ、仮想空間内の携帯端末のディスプレイ等であってよい。
また、仮想現実におけるコンテンツは、上述したように、ヘッドマウントディスプレイを介する以外の方法によっても視聴可能であってもよい。例えば、仮想現実におけるコンテンツは、スマートフォンやタブレット等を介して直接的に(ヘッドマウントディスプレイを介することなく)視聴されてもよい。
(サーバ装置の構成)
サーバ装置10の構成について具体的に説明する。サーバ装置10は、サーバコンピュータにより構成される。サーバ装置10は、複数台のサーバコンピュータにより協動して実現されてもよい。例えば、サーバ装置10は、各種のコンテンツを提供するサーバコンピュータや、各種の認証サーバを実現するサーバコンピュータ等により協動して実現されてもよい。また、サーバ装置10は、Webサーバを含んでよい。この場合、後述する端末装置20の機能の一部は、Webサーバから受領したHTML文書やそれに付随する各種プログラム(Javascript)をブラウザが処理することによって実現されてもよい。
サーバ装置10は、図1に示すように、サーバ通信部11と、サーバ記憶部12と、サーバ制御部13と、を備える。
サーバ通信部11は、外部装置と無線又は有線によって通信し、情報の送受信を行うインターフェースを含む。サーバ通信部11は、例えば無線LAN(Local Area Network)通信モジュール又は有線LAN通信モジュール等を含んでもよい。サーバ通信部11は、ネットワーク3を介して、端末装置20との間で情報を送受信可能である。
サーバ記憶部12は、例えば記憶装置であって、仮想現実に係る各種処理に必要な種々の情報及びプログラムを記憶する。
サーバ制御部13は、専用のマイクロプロセッサ又は特定のプログラムを読み込むことにより特定の機能を実現するCPU(Central Processing Unit)や、GPU(Graphics Processing Unit)等を含んでよい。例えばサーバ制御部13は、端末装置20と協動して、端末装置20の表示部23に対するユーザ操作に応じて仮想現実アプリケーションを実行する。
(端末装置の構成)
端末装置20の構成について説明する。図1に示すように、端末装置20は、端末通信部21と、端末記憶部22と、表示部23と、入力部24と、端末制御部25とを備える。
端末通信部21は、外部装置と無線又は有線によって通信し、情報の送受信を行うインターフェースを含む。端末通信部21は、例えばLTE(Long Term Evolution)(登録商標)や、LTE-A(LTE-Advanced)、第五世代移動通信システム、UMB(Ultra Mobile Broadband)等のモバイル通信規格に対応する無線通信モジュール、無線LAN通信モジュール、又は有線LAN通信モジュール等を含んでもよい。端末通信部21は、ネットワーク3を介して、サーバ装置10との間で情報を送受信可能である。
端末記憶部22は、例えば一次記憶装置及び二次記憶装置を含む。例えば端末記憶部22は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。端末記憶部22は、サーバ装置10から受信する、仮想現実の処理に用いられる種々の情報及びプログラムを記憶する。仮想現実の処理に用いられる情報及びプログラムは、端末通信部21を介して外部装置から取得されてもよい。例えば、仮想現実アプリケーションプログラムが、所定のアプリケーション配信サーバから取得されてもよい。以下、アプリケーションプログラムを、単にアプリケーションともいう。
また、端末記憶部22は、仮想空間を描画するためのデータ、例えば建物のような屋内の空間や、屋外の空間の画像等を記憶する。なお、仮想空間を描画するためのデータは、仮想空間ごとに複数種類用意され、使い分けられてもよい。
また、端末記憶部22は、3次元の仮想空間内に配置された種々のオブジェクトに投影(テクスチャマッピング)するための種々の画像(テクスチャ画像)を記憶する。
例えば、端末記憶部22は、各ユーザに対応付けられる仮想現実媒体としての参加アバターM1に係るアバター描画情報を記憶する。仮想空間内に参加アバターM1は、参加アバターM1に係るアバター描画情報に基づいて描画される。
また、端末記憶部22は、各主催側ユーザに対応付けられる仮想現実媒体としてのモデレータアバターM2に係るアバター描画情報を記憶する。仮想空間内にモデレータアバターM2は、モデレータアバターM2に係るアバター描画情報に基づいて描画される。
また、端末記憶部22は、例えば各種のギフトオブジェクト、建物、壁、又はNPC(Non Player Character)等のような、参加アバターM1やモデレータアバターM2とは異なる各種のオブジェクトに係る描画情報を記憶する。仮想空間内に各種のオブジェクトは、かかる描画情報に基づいて描画される。なお、ギフトオブジェクトとは、一のユーザから他のユーザへのギフト(贈り物)に対応するオブジェクトであり、アイテムの一部である。ギフトオブジェクトは、アバターの身に着けるもの(服やアクセサリー)やトークルーム画像(又は、仮想空間における対応する空間部)を装飾するもの(花火やお花等)、背景(壁紙)又はその類や、ガチャ(抽選)を回すことのできるチケット又はその類であってよい。なお、本件出願において用いられる「ギフト」という用語は、「トークン(token)」という用語と同様の概念を意味する。したがって、「ギフト」という用語を「トークン(token)」という用語に置き換えて、本件出願に記載された技術を理解することも可能である。
表示部23は、例えば液晶ディスプレイ又は有機EL(Electro-Luminescence)ディスプレイ等の表示デバイスを含む。表示部23は、多様な画像を表示可能である。表示部23は、例えばタッチパネルで構成され、多様なユーザ操作を検出するインターフェースとして機能する。なお、表示部23は、上述したように、ヘッドマウントディスプレイに内蔵される形態であってよい。
入力部24は、物理キーを含んでもよいし、マウス等のようなポインティングデバイスをはじめとする任意の入力インターフェースを更に含んでもよい。また、入力部24は、音声入力やジェスチャ入力、視線入力のような、非接触型のユーザ入力を受付可能であってもよい。なお、ジェスチャ入力には、ユーザの各種状態を検出するためのセンサ(画像センサや、加速度センサ、距離センサ等)や、センサ技術やカメラを統合した専用モーションキャプチャー、ジョイパッドのようなコントローラ等が利用されてもよい。また、視線検出用のカメラは、ヘッドマウントディスプレイ内に配置されてもよい。なお、上述したように、ユーザの各種状態は、例えばユーザの向きや位置、動き又はその類であり、この場合、ユーザの向きや位置、動きとは、ユーザの顔や手等の身体の一部や全部の向き、位置、動きのみならず、ユーザの視線の向き、位置、動き又はその類を含む概念である。
端末制御部25は、1つ以上のプロセッサを含む。端末制御部25は、端末装置20全体の動作を制御する。
端末制御部25は、端末通信部21を介して情報の送受信を行う。例えば、端末制御部25は、仮想現実に係る各種処理に用いられる種々の情報及びプログラムを、サーバ装置10及び他の外部サーバの少なくとも一方から受信する。端末制御部25は、受信した情報及びプログラムを、端末記憶部22に記憶する。例えば、端末記憶部22には、Webサーバに接続するためのブラウザ(インターネットブラウザ)が格納されてよい。
端末制御部25は、ユーザの操作に応じて仮想現実アプリケーションを起動する。端末制御部25は、サーバ装置10と協動して、仮想現実に係る各種処理を実行する。例えば、端末制御部25は、仮想空間の画像を表示部23に表示させる。画面上には、例えばユーザ操作を検出するGUI(Graphic User Interface)が表示されてもよい。端末制御部25は、入力部24を介して、ユーザ操作を検出可能である。例えば端末制御部25は、ユーザのジェスチャによる各種操作(タップ操作、ロングタップ操作、フリック操作、及びスワイプ操作等に対応する操作)を検出可能である。端末制御部25は、操作情報をサーバ装置10に送信する。
端末制御部25は、仮想空間(画像)とともにモデレータアバターM2や参加アバターM1を描画し、端末用画像を表示部23に表示させる。この場合、例えば、図2に示すように、左右の目でそれぞれ視認される画像G200、G201を生成することで、立体視画像を生成してよい。図2には、左右の目でそれぞれ視認される画像G200、G201が模式的に示されている。なお、以下では、特に言及しない限り、仮想空間の画像とは、画像G200、G201で表現される画像全体を指す。また、端末制御部25は、例えば主催側ユーザによる各種操作に応じて、仮想空間内においてモデレータアバターM2の各種動きを実現させる。端末制御部25の具体的な描画処理は後述する。
ところで、主催側ユーザによる特定トークコンテンツのような、ユーザ参加型のトークコンテンツの場合、初心者ユーザを含め多くのユーザの参加が可能である場合、会話の盛り上がりや活性度が高くなり、トークコンテンツの魅力が増す。また、ユーザ間の交流が促進され、仮想空間の魅力を高める効果もある。
しかしながら、ユーザ参加型のトークコンテンツが多数配信される場合、各ユーザが参加しやすいトークコンテンツを見つけ出すことが容易でない場合がある。例えば、サムネイルだけではトークコンテンツのテーマ等が理解できない場合、当該トークコンテンツの視聴や参加に対するハードルが高くなりやすい。また、使用する言語の違いもありえ、興味のある会話をする人々が集まるトークコンテンツに辿り着けないという課題もある。また、会話や発話をしない限り、相手がどのような言語や興味かわからないという課題もある。
なお、このような課題は、ユーザが主催側と参加側に区別される場合における主催側ユーザによる特定トークコンテンツだけでなく、ユーザが主催側と参加側に区別されない場合として、参加自由型(入室自由型)のトークルーム等においても同様に生じうる。例えば、アバターが自由に動き回ることができる仮想空間(ワールド形態の仮想空間)においては、仮想空間内に各種トークルームが設置される場合や、複数のアバターが集まりトークルームが自然に発生する場合がありうる。なお、ワールド形態の仮想空間においても、仮想空間内に配置される仮想カメラの視点からの端末用画像に基づいて、特定トークコンテンツが生成されることになる。かかる場合も、トークルームで行われている会話のテーマが外部からわからない場合、当該トークルームに入ることに対するハードルが高くなりやすい。
そこで、本実施形態では、以下で詳説するように、主催側ユーザによる特定トークコンテンツや参加自由型(入室自由型)のトークルーム等での会話に関して、トークテーマ(会話のテーマ)を特定及び出力することで、特定トークコンテンツやトークルーム等での会話に対する各ユーザの視聴や参加に対するハードルを下げることを可能とする。すなわち、特定トークコンテンツやトークルーム等での会話に対する各ユーザの視聴や参加を促進することを可能とする。ひいては、視聴や参加が活性化することにより、新たなユーザが会話に参加、すなわち、新たな会話の開始を効果的に促進することを可能とする。また、本実施形態では、データ量や処理負荷の低減とコミュニケーションの活発化を同時に達成することが可能となる。例えば、会話に入る前からその詳細が全部出力されるような仕様の情報処理システムとすると、通信データ量が増えるとともに、ユーザにとっても情報量が多すぎて認識しきれない事態となる。これに対し、本実施形態では、詳しくは以下で説明するように、会話に入る前はトークテーマ表示だけが実行され、会話に参加してはじめて詳細を視聴可能とすることで、サーバや端末の処理負荷の低減と、ユーザが参加したい会話を効率的に選ぶことによるコミュニケーションの活発化とを同時に達成することが可能となる。さらに、本実施形態では、ユーザの操作数を減らしてユーザビリティの向上と処理負荷の低減を達成することが可能となる。すなわち、本実施形態では、詳しくは以下で説明するように、トークテーマで会話を検索したり、トークテーマを会話参加前に表示したり、お好みのトークテーマの会話に誘導したりすることにより、ユーザが所望の会話に到達するまでの操作数を減少させることができ、ユーザビリティの向上と処理負荷の低減を達成することが可能となる。
ここで、図3から図15を参照して、トークテーマに関する構成について説明する。
図3は、仮想空間における一のトークルームの概念図である。図3に示す例では、会議形式のトークルーム300Rであり、トークルーム300Rには、そのトークテーマを示す表示媒体302R(所定表示媒体の一例)が対応付けられている。表示媒体302Rは、対応するトークテーマを表す文字情報のほか、画像、動画、3Dオブジェクトなどを含んでよい。後述するように、トークテーマは、トークルームで行われていた会話におけるキーワードを抽出して特定してよいが、抽出したキーワードやトークテーマの文字情報と画像、動画、3Dオブジェクトなどとの関連付テーブルを用意しておき、トークテーマに相当する画像、動画、3Dオブジェクトなどによって特定してもよい。以下の説明において、文字情報等というときには、このようにして得られた画像、動画、3Dオブジェクトなどを含む概念として用いている。このような表示媒体302Rを有することで、トークルーム300Rでの会話に対する各ユーザの視聴や参加を促進することが可能となる。なお、図3では、表示媒体302Rは、立て看板(第2オブジェクトM3)の形態であるが、他の形態であってもよい。
図4は、仮想空間における他の一のトークルームの概念図である。図4に示す例では、発表形式又はパネルディスカッション形式のトークルーム400Rであり、トークルーム400Rには、そのトークテーマを示す表示媒体402Rが対応付けられている。表示媒体402Rは、対応するトークテーマを表す文字情報等を含んでよい。このような表示媒体402Rを有することで、トークルーム400Rでの会話に対する各ユーザの視聴や参加を促進することが可能となる。すなわち、既に開始している会話に参加する前に、ユーザが会話の内容を把握できるようにすることで、会話への参加を促進し、ユーザ同士のコミュニケーションを活発にすることができる。
図5は、仮想現実生成システム1により生成可能な仮想空間の一例の説明図である。
本実施形態では、仮想空間は、複数の空間部を含んでよい。複数の空間部のそれぞれは、参加アバターM1が入ることができる空間部であり、それぞれにおいて独自のコンテンツが提供可能であってよい。複数の空間部のそれぞれは、現実内の各種空間と同様、仮想空間内において互いに連続する空間を形成する態様で生成されてもよい。あるいは、複数の空間部の一部又はすべては、壁部やドア(第2オブジェクトM3)を介して仕切られていてもよいし、互いに不連続であってもよい。不連続とは、現実内の物理法則に反する態様で接続される関係であり、例えばワープのような瞬間移動の態様で移動可能な空間部間の関係である。
図5に示す例では、仮想空間は、複数のトークルーム用の空間部70と、フリー空間部71とを備えている。フリー空間部71では、参加アバターM1は、基本的に自由に移動できる。なお、フリー空間部71においても、適宜、特定トークコンテンツ(例えば空間部70で提供されるような後述する特定トークコンテンツ)に係る会話が行われうる。
空間部70は、フリー空間部71に対して少なくとも一部が壁体(第2オブジェクトM3の例)や移動禁止部(第2オブジェクトM3の例)により隔てられた空間部であってよい。例えば、空間部70は、フリー空間部71に対して参加アバターM1が出入りできる出入口(例えば、穴や、ドア等の第2オブジェクトM3)を有してよい。空間部70は、当該空間部70に位置する参加アバターM1が参加可能なトークルームとして機能してよい(すなわち特定トークコンテンツに係る端末用画像用の仮想カメラが配置される空間部70として機能してよい)。なお、図5では、空間部70及びフリー空間部71を2次元平面として描画しているが、空間部70及びフリー空間部71は3次元空間として設定されてもよい。例えば、空間部70及びフリー空間部71は、図5に示す平面形状を床として対応する範囲に壁や天井を有する空間でもよく、また、図5に示す例とは別に、ドーム型や球状などの高さを有する空間や、ビルなどの建造物、地球上の特定の場所のほか、アバターが飛び回れる宇宙空間などを模したワールドとしてもよい。
図6は、仮想空間におけるモデレータアバターM2まわりの属性の異なる領域の説明図である。後述するように、仮想空間には第1属性の領域R1と第2属性の領域R2が設けられる。領域R1は、ユーザが仮想空間内での会話の詳細(会話音声やチャット文字など)を視聴可能であるとともに自らの会話が可能な領域である一方、領域R2は、ユーザが仮想空間内での会話の詳細を視聴可能であるが自らの会話はできない領域である。領域R2の外側では、ユーザは、トークテーマが視聴でき、領域R2に入った後は会話の詳細が視聴可能となる。この際、トークテーマの表示は消えてもよい。
本実施形態では、仮想空間におけるモデレータアバターM2まわりには、第1属性の領域R1と、第1属性とは異なる第2属性の領域R2が形成されてよい。なお、第1属性の領域R1及び第2属性の領域R2は、それぞれ、複数の位置の集合からなる。第1属性の領域R1及び第2属性の領域R2は、トークルームに含まれる態様で定義されてよい。換言すると、トークルームは、第1属性の領域R1及び第2属性の領域R2により規定されてもよい。ただし、トークルームは、第2属性の領域R2よりも外側の領域を含んでもよい。また、変形例では、例えば、モデレータアバターM2とのコラボが可能な第3属性の領域や、モデレータアバターM2しか位置することができない第4属性の領域といった具合に、他の属性の領域が定義されてもよい。なお、図6では、領域R1及び領域R2を2次元平面として円状に描画しているが、図5と同様に、領域R1及び領域R2は3次元空間の球状に設定されてもよい。
第1属性の領域R1は、モデレータアバターM2と参加アバターM1との会話、及び/又は、複数の参加アバターM1同士の会話が可能な領域であり、第2属性の領域R2よりもモデレータアバターM2の近くに設定されてよい。図6に示す例では、第1属性の領域R1は、モデレータアバターM2まわりの半径r1の円領域に対応するが、形態やサイズは任意である。例えば、第1属性の領域R1のサイズ(例えば半径r1の大きさ)は、一定(固定)であってもよいし、第1属性の領域R1内の参加アバターM1の数が増加するにつれて大きくなる態様で可変とされてもよい。
第2属性の領域R2は、モデレータアバターM2と第1属性の領域R1内の参加アバターM1との間の会話を視聴のみ可能な領域である。すなわち、第2属性の領域R2は、第1属性の領域R1とは異なり、モデレータアバターM2と会話が不能であるが、モデレータアバターM2と第1属性の領域R1内の参加アバターM1との間の会話を視聴できる領域である。このような属性に起因して、第2属性の領域R2は、第1属性の領域R1よりもモデレータアバターM2から遠くに設定されてよい。例えば、第2属性の領域R2は、第1属性の領域R1に隣接して設定されてよい。図6に示す例では、第2属性の領域R2は、第1属性の領域R1を囲繞する態様の、内径r1及び外径r2の円環領域に対応するが、形態やサイズは任意である。例えば、第2属性の領域R2のサイズ(例えば半径r2の大きさ)は、一定(固定)であってもよいし、第2属性の領域R2内の参加アバターM1の数(又は後述する活性度パラメータのような特定パラメータの値)が増加するにつれて大きくなる態様で可変とされてもよい。
ところで、仮想空間においては、トークルームとともにモデレータアバターM2が事前に決定されてもよい。例えば、モデレータアバターM2に係るユーザは、事前にトークルームに係る領域(例えば空間部70)を予約等し、トークイベント等を開催してもよい。あるいは、トークルームは、モデレータアバターM2に係るユーザからの作成指示に応答して新規に生成されてもよい。あるいは、トークルームは、例えばフリー空間部71において自然に(例えば場当たり的に)発生してもよい。例えば、図7に示すように、あらかじめトークテーマに係る張り紙(第2オブジェクトM3)が壁体(第2オブジェクトM3)に貼られており、他のユーザと会話をしたいユーザに係るアバターM9が、対応する所望のトークテーマに係る張り紙を手にすることで、トークルームを形成すること(及びそれに伴い当該トークルームに係るモデレータアバターM2となること)が可能であってもよい。なお、トークテーマに係る張り紙に代えて、図8に示すように、チラシラックないし書棚(第2オブジェクトM3)に配置されるパンフレットや冊子(第2オブジェクトM3)にトークテーマが記載されてもよい。このように、張り紙やパンフレットなどからユーザがトークテーマを選んでトークルームを形成できるようにすることで、会話を開始する心理的なハードルを下げることができ、仮想空間におけるユーザ間のコミュニケーションを活発化することに資するという効果を得ることができる。なお、これらのトークテーマは、特定のユーザや運営者側が編集したり、新規作成したりしてもよい。この場合、モデレータアバターM2となりたいユーザのアバターM9が、対応する所望のトークテーマに係るパンフレットを手にすることで、モデレータアバターM2となることが可能であってもよい。このようにしてモデレータアバターM2が発生すると、図9に示すように、当該モデレータアバターM2まわりに、上述した第1属性の領域R1及び第2属性の領域R2が設定されてもよいし、ユーザが張り紙やパンフレットなどを手に取ることにより、図3から5、図10及び図11などに示されているような態様のトークルームが発生するようにしてもよい。この場合、モデレータアバターM2は、手にしたパンフレット(トークテーマを表す表示媒体902R)が、多方面から視認可能なビルボードとして機能してもよい。これにより、モデレータアバターM2まわりの任意の方向に位置するアバターからも、容易にトークテーマを視認できる。なお、仮想空間においてモデレータアバターM2が移動する場合、それに伴い第1属性の領域R1及び第2属性の領域R2も移動されてよい。
図10及び図11は、トークルームの多様な形態の説明図である。トークルームは、例えば、図10に示すように、カフェの形態の空間部70内に設定されてもよいし、図11に示すように、比較的大きいイベント会場の形態の空間部70内において複数個設定されてもよい。
例えば、図10に示す例では、カフェに係る空間部70内の壁部(第2オブジェクトM3)には、トークテーマを示す表示媒体1002Rが対応付けられている。表示媒体1002Rは、対応するトークテーマを表す文字情報等を含んでよい。表示媒体1002Rは、他のユーザとして、領域R2の外側から領域R2に入ろうとしているアバターM7からの視点で見やすい位置に設置されてよい。これにより、当該トークルームでの会話に対する各ユーザの視聴や参加を促進することが可能となる。
また、図10に示す例では、空間部70は、第1属性の領域R1内に入るためには所定料金(例えば30分あたり500円)の支払いが必要な有料カフェの形態であってよい。この場合、カフェに係る空間部70内の壁部(第2オブジェクトM3)には、料金体系を示す表示媒体(第2オブジェクトM3)(図示せず)が配置されてよい。この場合、ユーザは、例えば30分ごとに延長料金を支払うことで、第1属性の領域R1内に居続けることができる。延長料金の支払いが行われていないユーザは、自動的にログアウト(フェードアウト)されてもよいし、トークルームから退出させられるようにしてもよい。この場合、例えば、延長料金の支払いが行われていないユーザ又は当該ユーザに係る参加アバターM1に対して、参加アバターM1の描画(他のユーザにとっての可視性)が薄くなったり、トークルーム内のモデレータアバターM2等からの声(他のユーザにとっての声の可聴性)が小さくなったり、トークルーム内のモデレータアバターM2等からの発話が文字情報等に変換されなかったりするような、制限が発生してもよい。なお、仮想空間内での料金の支払いは、所定媒体の消費(例えば購入可能なポイントの消費や、特定の仮想通貨の消費)等により実現されてもよい。
また、図11に示す例では、イベント会場には、複数のモデレータアバターM2のトークルームを設定してもよい。この場合、複数(図11では2体)のモデレータアバターM2のそれぞれには、対応するトークテーマを示す表示媒体1102Rが対応付けられている。各表示媒体1102Rは、対応するトークテーマを表す文字情報等を含んでよい。なお、対応するトークテーマを示す表示媒体1102Rに代えて又は加えて、モデレータアバターM2が、トークテーマを明示又は示唆(連想を含む)するキャラクタの形態であってもよい。この場合、モデレータアバターM2自体が、対応するキャラクタがトークテーマであることを示す表示媒体として機能できる。このような構成は、トークテーマが変動しない場合に好適である。このようにして、イベント会場に、各キャラクタに関連するトークルームを複数設定することで、各キャラクタに関連したトークテーマの会話を活性化できる。
また、図11に示す例では、各参加アバターM1は、モデレータアバターM2との記念撮影が可能とされてもよい。この場合、各モデレータアバターM2に対応付けてカメラオブジェクトM13(第2オブジェクトM3)が配置されてもよい。カメラオブジェクトM13で撮像された画像は、対応する参加アバターM1に係るユーザが閲覧可能な態様で当該ユーザに提供されてもよい。また、カメラオブジェクトM13は、仮想カメラとして機能してもよく、この場合、仮想カメラからの動画は、スマートフォン等での視聴用の端末用画像(図14のトークルーム画像H21参照)を生成するために利用されてもよい。
また、図11に示す例では、空間部70内の壁部(第2オブジェクトM3)には、対応するイベントに係るパンフレット(第2オブジェクトM3)や原画(第2オブジェクトM3)、インタビューの動画を視聴可能なディスプレイオブジェクトM10(第2オブジェクトM3)等が配置されてもよい。この場合、かかる第2オブジェクトM3に起因したトークルームが自然に発生してもよい。また、空間部70内には、アバターが着席可能な椅子や机(第2オブジェクトM3)が配置されてよく、対応するイベントに係る音源の音楽が再生されてもよい。このような椅子や机は、トークルームが発生した場合に出現されてもよい。なお、図11に示されているそれぞれの領域R1内にいるモデレータアバターM2及び参加アバターM1は、それぞれの領域R1内で、モデレータアバターM2と参加アバターM1との間で、及び/又は、参加アバターM1同士の間で、会話が可能である。
図12は、トークテーマの詳しさ(階層)に応じた各トークルームの配置例の説明図である。図12には、映画館のようなイベント会場の形態の空間部70(図12では、符号70(1))に隣接するロビーの形態の空間部70(図12では、符号70(2))における各種トークルームが示されている。図12では、各種トークルームに、それぞれのトークテーマA~Fが対応付けられている。各トークテーマA~Fは、イベント会場におけるイベントに関連し、イベント会場への入口(イベント会場からロビーへの出口)から、ロビーの出口に向けて、徐々に内容が詳しくなる態様で設定されてもよい。例えば、図12に示す例において、トークテーマE、Fは、トークテーマA、Cよりも初心者向けであってよい。この場合、イベント会場でイベントを体験したユーザは、イベント会場からロビーに出てから、ロビーの出口に向かうまで、順番にトークルームに立ち寄ることで、当該イベントに関する知識を徐々に深めていくことができる。なお、図12では、映画館のようなイベント会場の形態の空間部70に、ロビーの形態の空間部70が隣接する態様でされているが、これに限れない。例えば、空間部70から出てくるアバターを、関連するトークテーマで会話が行われているトークルーム(映画館のようなイベント会場の形態の空間部70とは隣接してない空間部70)へと案内する構成であってよい。
図13は、スマートフォン等(端末装置20の一例)での視聴用のトークルーム選択画面の一例を示す説明図である。
図13に示す例では、視聴用のトークルーム選択画面G1300は、各種トークルームに対応する選択項目(配信中又は配信予定の特定トークコンテンツの配信種目)を含むリスト情報を表示する。
各種トークルームに対応する選択項目G1301は、好ましくは、サムネイルとともに、対応するトークテーマを示すテーマ表示G1302(テーマ情報)を含む。テーマ表示G1302は、トークテーマを表す文字情報等を含んでよい。これにより、当該トークルームでの会話に対する各ユーザの視聴や参加を促進することが可能となる。なお、一画面に含まれる選択項目G1301の数は、画面サイズに応じて適宜設定されてよく、トークルーム選択画面G1300は、表示される選択項目G1301を変更するためのスクロール操作等が可能であってよい。
図14は、参加側ユーザが図13に示すトークルーム選択画面を介して一のトークルームに入室したときの、当該参加側ユーザ用のトークルーム画像H2(端末用画像)の一例を示す図である。トークルーム画像H2は、仮想空間内の仮想カメラに基づいて生成されてもよいし、スタジオユニット30A、30Bにより生成されてもよいし、端末装置20のカメラの撮像画像に基づいて生成されてもよい。図14A及び図14Bは、参加側ユーザ用のトークルーム画像H2の他の例を示す図である。
なお、トークルーム画像H2は、ヘッドマウントディスプレイを介さずに視認可能なトークルーム画像H21(以下、「スマートフォン用のトークルーム画像H21」又は単に「トークルーム画像H21」とも称する)(図14参照)の他、主催側ユーザ用のトークルーム画像や、参加側ユーザ用のトークルーム画像であって、ヘッドマウントディスプレイを介して視認可能なトークルーム画像を含んでよい。
参加側ユーザは、トークルーム選択画面G1300を介して一のトークルームに入室する場合、会話が可能な態様での入室(例えば上述した第1属性の領域R1への入室)と、視聴のみが可能な態様での入室(例えば上述した第2属性の領域R2への入室)のうちの、いずれか一方を選択可能であってよい。あるいは、トークルーム選択画面G1300を介した入室は、会話が可能な態様での入室(例えば上述した第1属性の領域R1への入室)と、視聴のみが可能な態様での入室(例えば上述した第2属性の領域R2への入室)のうちの、いずれか一方としてあらかじめ設定されていてもよい。
トークルーム画像H21には、図14、図14A及び図14Bに示すように、対応するトークテーマを示すテーマ表示G11(テーマ情報)を含む。テーマ表示G11は、トークテーマを表す文字情報等を含んでよい。これにより、参加側ユーザは、入室後も、トークテーマを確認できる。なお、このようなテーマ表示G11は、一のトークルームに係るトークテーマが動的に変化しうる場合に好適である。
なお、図14に示す例では、トークテーマを示すテーマ表示G11に加えて、モデレータアバターM2とともに、ハート型のギフトオブジェクトG12、プレゼント型のギフトオブジェクトG12A、「初見です・・・」といった各種コメントG13、コラボ配信の要請を他の主催側ユーザに送信するための操作部G109等が描画されている。
ところで、スマートフォンのような比較的小さい画面の端末装置20では、参加アバターM1は、図14Aに示すように、パネル形式で表現されてもよい。具体的には、参加アバターM1は、画像領域G35にアバターアイコンで描画されてよい。この場合、アバターアイコン350、351、352のそれぞれは、対応するアバターが属する仮想空間を表す。この場合、アバターアイコン350、351、352のそれぞれには、対応するユーザ名(例えば“ユーザA”、“ユーザB”等)が対応付けられてよい。また、アバターアイコン350、351、352のそれぞれには、マイクアイコン360、361、362が対応付けられてよい。この場合、マイクアイコン360、361、362のうちの、発話状態のユーザアバターM1に対応するマイクアイコンが、同様の態様で強調(例えばサイズの拡大や、点滅、色付け等)されてよい。この場合、マイクアイコンは、声の大きさ(ボリューム)によって大きさが変化されてもよい。
あるいは、参加アバターM1は、図14Bに示すように、モデレータアバターM2とともに、アバターパネルG371~G376の形態で描画されてよい。この場合も、アバターパネルG371~G376のそれぞれは、対応するアバターが属する仮想空間を表す。この場合、仮想空間は、実質的に2次元表示で表現されてよい。この場合、アバターパネルG371~G376のうちの、発話状態のアバターに対応するアバターパネルが、同様の態様で強調(例えばサイズの拡大や、点滅、色付け等)されてよい。
図15は、ヘッドマウントディスプレイでの視聴用のトークルーム選択画面の一例を説明する説明図である。
図15には、ユーザの視点からの視界範囲(正面を視ている場合)R500が上面視で模式的に示されるとともに、ヘッドマウントディスプレイ(端末装置20の一例)を介して可視となる複数の平面状の操作部G300が示されている。なお、この場合、ユーザがヘッドマウントディスプレイを介して視認できる画面が、ヘッドマウントディスプレイを利用した場合の視聴用のトークルーム選択画面となる。
複数の平面状の操作部G300は、各種トークルームに対応する選択項目(配信中又は配信予定の特定トークコンテンツの配信種目)として機能する。従って、ユーザは、ヘッドマウントディスプレイを介して、複数の選択項目(操作部G300)を含むリスト情報を視認できる。そして、ユーザは、ジェスチャ入力(例えば所望の選択項目に手を伸ばす動き)等により、複数の選択項目(操作部G300)のうちの、所望の選択項目を選択できる。
複数の平面状の操作部G300は、好ましくは、サムネイル(例えばモデレータアバターM2の画像を含むサムネイル)とともに、対応するトークテーマを示すテーマ表示G1502(テーマ情報)を含む。テーマ表示G1502は、トークテーマを表す文字情報等を含んでよい。これにより、当該トークルームでの会話に対する各ユーザの視聴や参加を促進することが可能となる。
複数の平面状の操作部G300は、好ましくは、前後に複数層をなす態様で配置される。例えば、複数の平面状の操作部G300は、所定基準軸まわりの第1曲面501に沿って複数の列で配置される第1グループと、同所定基準軸まわりの第2曲面502に沿って複数の列で配置される第2グループとを含んでよい。この場合、第2曲面502は、図15に示すように、第1曲面501に対して背後にオフセットされてよい。この場合、ユーザの視点から視たとき、第1曲面501に沿って配置された第1グループの複数の操作部G300(以下、第2グループと区別するために、「操作部G300-1」とも称する)の背後に、第2曲面502に沿って配置された第2グループの複数の操作部G300(以下、第1グループと区別するために、「操作部G300-2」とも称する)がオーバーラップする関係となる。このとき、ユーザの視点から視たとき、第2グループの操作部G300-2は、第1グループの操作部G300-1の背後から一部が可視であってもよい。この場合、ユーザに背後側の操作部の存在を知ってもらうことが可能となるとともに、ユーザの目に留まりうる操作部の数を効率的に増加させることが可能となる。なお、第2曲面に対して、更に背後側にオフセットした第3曲面を設定し、更なる平面状の操作部G300を配置してもよい。このように、ユーザの視点から視て2つ以上の任意の数で平面状の操作部G300をオーバーラップする態様で配置してもよい。
また、このような前後にオーバーラップした複数の平面状の操作部G300の場合、多数の操作部G300を、ユーザにより操作可能に配置しつつ、描画に関する処理負荷を効率的に低減できる。例えば、操作部G300-1に関してのみサムネイル画像やリアルタイムの映像の完全な描画を行いつつ、操作部G300-2に関しては不完全な描画(例えばテクスチャを変化させるなどの加工)を行うことによって、全体としての描画に関する処理負荷を低減することも可能である。また、同様の観点から、操作部G300-1のうちの、ユーザの視点から視て正面の領域R500内の操作部G300-1に関してのみサムネイル画像やリアルタイムの映像の完全な描画を行いつつ、正面の領域R500外の操作部G300-1に関しては不完全な描画(例えばテクスチャを変化させるなどの加工)を行うことによって、全体としての描画に関する処理負荷を低減することも可能である。例えば、正面の領域R500内の操作部G300-1となる可能性が高いデータをユーザの端末装置20においてプリキャッシュやプリロードすることによって、レイテンシを低減しつつ、ネットワーク3を介して提出されるリクエストの数、及びそれに伴いネットワーク3に課されるリクエストの量、並びにリクエストに応答するために使用される計算リソースを、効率的に低減することが可能となる。この場合、正面の領域R500内の操作部G300-1となる可能性が高いデータは、ユーザごとの傾向に基づき予測されてよいし、人工知能に基づく機械学習等により決定されてもよい。
ユーザの視点から視たとき、第1曲面501に沿って配置された第1グループの複数の操作部G300-1の背後に、第2曲面502に沿って配置された第2グループの複数の操作部G300-2がオーバーラップする場合、ユーザは、手を所定の態様で動かす所定入力により、第1グループと第2グループとを入れ替えることができてよい。これにより、多数の操作部G300を効率的に配置しつつ、直感的な操作による操作性を高めることができる。なお、このような複数の平面状の操作部G300が配置される構成では、ユーザは、特定の操作により、複数の平面状の操作部G300の配置を変更可能であってよい。これにより、ユーザの好みや嗜好に応じた操作部G300の配置が可能となる。
次に、図16以降を参照して、上述したトークテーマに関連したサーバ装置10及び端末装置20のそれぞれの機能的な構成例について説明する。
まず、図16から図22を参照して、主にサーバ装置10の機能について説明する。
図16は、上述したトークテーマに関連したサーバ装置10の機能を示す概略的なブロック図である。図17は、トーク履歴記憶部140内のデータの一例を示す説明図である。図18は、トーク状況記憶部142内のデータの一例を示す説明図である。図19は、ユーザ情報記憶部144内のデータの一例を示す説明図である。図20は、各種テーブルの説明図である。図21は、アバター情報記憶部146内のデータの一例を示す説明図である。図22は、トークテーマの階層構造の説明図である。なお、図17(以下の同様の図18等も同様)において、「***」は、なんらかの情報が格納されている状態を示し、「・・・」は、同様の情報の格納の繰り返し状態を示す。
サーバ装置10は、図16に示すように、トーク履歴記憶部140と、トーク状況記憶部142と、ユーザ情報記憶部144と、アバター情報記憶部146と、トークデータ取得部150と、テーマ特定部152と、キーワード抽出部154と、トーク管理部156と、アバター決定部158と、配信処理部160と、設定処理部162と、ユーザ抽出部164と、誘導処理部166と、テーマ管理部168と、パラメータ算出部170と、端末用データ取得部172と、端末用データ送信部174と、会話支援処理部176とを含む。
なお、図16において、トーク履歴記憶部140、トーク状況記憶部142、ユーザ情報記憶部144、及びアバター情報記憶部146は、図1に示したサーバ装置10のサーバ記憶部12により実現できる。また、トークデータ取得部150から会話支援処理部176の各部の機能は、図1に示したサーバ装置10のサーバ制御部13やサーバ通信部11により実現できる。
トーク履歴記憶部140には、仮想現実生成システム1において形成された各トークルームの履歴情報が記憶される。図17に示す例では、トーク履歴記憶部140には、トークIDごとに、テーマ情報、場所情報、アバター情報、時間情報、及び言語情報の各項目が対応付けられている。
トークIDは、トークルームごとに付与されてよい。トークIDが付与されるトークルームの形態は任意であり、トークIDが付与されるトークルームは、上述した空間部70において形成されるトークルームに加えて、上述したフリー空間部71において形成されるトークルームを含んでよい。また、トークIDが付与されるトークルームは、空間部70等に形成されるトークルームに加えて、スマートフォン等での視聴用のトークルーム(図14参照)を含んでもよい。
テーマ情報は、対応するトークルームにおける会話に係るトークテーマに対応し、後述するテーマ特定部152により特定されるトークテーマを表す。なお、一のトークルームにおいて、トークテーマが変化する場合、一のトークIDに対して複数のテーマ情報が対応付けられてもよい。あるいは、変形例では、トークテーマが変化するたびに新たなトークIDが発行されてもよい。
場所情報は、対応するトークルームの位置(仮想空間内の位置)を表す。例えば、トークルームが空間部70において形成される場合、当該トークルームの場所情報は、空間部70の位置情報(座標値)であってもよいし、対応する一の空間部70を特定する情報であってもよい。また、トークルームが移動可能である場合(例えば、モデレータアバターM2の位置に応じて変化する場合)、場所情報は、移動履歴を含んでもよい。
また、上述したように第1属性の領域R1及び第2属性の領域R2を有するトークルームについては、場所情報は、第1属性の領域R1及び第2属性の領域R2のそれぞれの範囲を示す情報を含んでよい。
アバター情報は、対応するトークルームにおけるモデレータアバターM2や、対応するトークルームに入室した各参加アバターM1を表す情報(例えば対応するユーザIDやアバターID)である。一のアバターに対応するアバター情報は、当該アバターの入室時間のような、詳細情報を含んでもよい。また、アバター情報は、参加アバターM1の総数や延べ数、会話の頻度や発話の回数等を含んでよい。また、アバター情報は、各参加アバターM1の参加属性(第1属性の領域R1に位置するか、第2属性の領域R2に位置するかの属性)を含んでよい。また、アバター情報は、各アバターの属性を表す属性情報を含んでもよい。例えば、属性情報は、アカウントやプロフィールに登録している情報(性別や好きなもの等)や、音声分析から一人称の呼び方や言葉遣い、方言の有無、行動履歴(仮想空間内での行動履歴)、購入アイテム(仮想空間内での購入アイテム)等に基づいて生成されてもよい。
時間情報は、対応するトークルームの開始時刻と終了時刻とを表す。なお、常時形成されているトークルームに対しては、時間情報が省略されてもよい。
言語情報は、対応するトークルームで行われていた会話の言語を表す。なお、2つ以上の言語で会話が行われていた場合は、言語情報は、2つ以上の言語を含んでよい。なお、言語情報には、ロケールIDが利用されてよい。
トーク状況記憶部142には、現在形成されているトークルームにおける状況(現況)を表す情報が記憶される。図18に示す例では、トーク状況記憶部142には、トークIDごとに、トークデータ、テーマ情報、場所情報、アバター情報、持続時間情報、言語情報、活性度情報、及び参加可否情報の各項目が対応付けられている。
トークデータは、対応するトークルームにおいて現に行われている会話の全内容に関するデータである。トークデータは、加工前の生データ(すなわち生発話ログ)であってもよいが、テキスト化(文字に変換された)データであってよい。
テーマ情報は、対応するトークルームにおける会話に係るトークテーマを表す。ただし、トーク状況記憶部142内のテーマ情報は、現時点でのトークテーマを表す。
場所情報は、対応するトークルームの場所を表す。ただし、トーク状況記憶部142内の場所情報は、現時点での場所を表す。なお、トークルームの位置が変化しない仕様の場合、トーク状況記憶部142内の場所情報は省略されてもよい。また、上述したように第1属性の領域R1及び第2属性の領域R2を有するトークルームについては、場所情報は、第1属性の領域R1及び第2属性の領域R2のそれぞれの範囲(現時点での範囲)を示す情報を含んでよい。
アバター情報は、対応するトークルームにおけるモデレータアバターM2や、対応するトークルームに入室した各参加アバターM1を表す情報(例えば対応するユーザIDやアバターID)である。ただし、トーク状況記憶部142内のアバター情報は、現時点でのトークルーム内に位置する各アバターを表す。
持続時間情報は、対応するトークルームの持続時間(開始時刻からの経過時間)を表す。なお、トークテーマが変化したトークルームについては、持続時間は、トークテーマごとに算出されてもよい。
言語情報は、対応するトークルームで行われている会話の言語を表す。なお、2つ以上の言語で会話が行われている場合は、言語情報は、2つ以上の言語を含んでよい。
活性度情報は、対応するトークルームで行われている会話の活性度を表す。活性度は、後述するパラメータ算出部170により算出される活性度パラメータの現在値であってよい。
参加可否情報は、対応するトークルームへの任意のユーザの参加可否(入室可否)を示す情報である。なお、参加可否情報は、参加可否に加えて、参加可能な条件(例えば友達の同伴の場合はOK等の条件や、人数制限に係る条件)等の情報を含んでよい。また、参加可否情報は、入室料金等の情報を含んでもよい。
ユーザ情報記憶部144には、各ユーザに関する情報が記憶される。各ユーザに関する情報は、例えばユーザ登録時に生成されてよく、その後、適宜、更新等されてよい。例えば、図19に示す例では、ユーザ情報記憶部144には、ユーザIDごとに、ユーザ名、アバターID、トーク参加履歴、会話情報、キーワード情報、除外ワード(禁止ワード)情報、フレンド情報、及び好み情報の各項目が対応付けられている。
ユーザIDは、ユーザ登録時に自動的に生成されるIDである。
ユーザ名は、各ユーザが自身で登録した名前であり、任意である。
アバターIDは、ユーザが利用するアバターを表すIDである。アバターIDには、対応するアバターを描画するためのアバター描画情報(図21参照)が対応付けられてよい。なお、一のアバターIDに対応付けられるアバター描画情報は、対応するユーザからの入力等に基づいて追加や編集等が可能であってよい。
トーク参加履歴は、対応するユーザが入室したトークルームに関する情報(例えばトークテーマ等)を表し、図17に示したトーク履歴記憶部140内のデータに基づいて生成されてよい。なお、トークテーマを会話タグとして利用してもよい。この場合、トーク参加履歴は、対応するユーザが過去に参加した会話の会話タグが、対応するユーザのプロフィールに表示されてもよい。過去に参加した会話については、そのうち、そのユーザの参加数が多い上位の所定数の会話タグをプロフィールに表示してもよい。これにより、端末装置20の表示部23のスペースの都合で全部は表示しきれない場合や、表示部23の小さい端末装置20(スマートフォン等のモバイル端末など)でも、ユーザのプロフィールやユーザに必要な情報を効果的に表示して認識させることが可能となる。過去に参加した会話は、会話タグをキーとして、過去のトークルームでの会話が検索等されてもよい。会話タグでユーザを検索することで、趣味の合うユーザを見つけることができる。そして、会話タグで仲良くなりたいユーザを見つけて、そのユーザに直接チャットなどの連絡ができてもよいし、そのユーザがいる仮想空間上の位置(例えば、「BBカフェテリアにいる」など)を教えてもらったり、その位置にワープしたりすることもできる。
会話情報は、対応するユーザが入室したトークルームで発話した際の発話内容に関する情報を表す。会話情報は、テキスト化されたデータであってよい。また、会話情報は、どの言語を話すかを表す情報(例えばロケールID)や、総配信時間の情報を含んでもよい。また、会話情報は、一人称の呼び方、言葉遣い、方言等に関する情報を含んでもよい。
キーワード情報は、対応するユーザが入室したトークルームで行われていた会話におけるキーワードを表す情報である。キーワード情報は、ユーザの好み等を精度良く表す可能性があり、後述する誘導処理部166での処理等で利用されてもよい。
除外ワード(禁止ワード)情報は、各ユーザが除外ワード(禁止ワード)を発した回数に関する。除外ワード(禁止ワード)は、運営者側で決められてもよいし、対応するトークルームのモデレータアバターM2により追加されてもよい。なお、除外ワード(禁止ワード)を発したことがないユーザには、その旨の情報が対応付けられてよい。
フレンド情報は、フレンド関係にあるユーザを特定可能な情報(例えばユーザID)であってよい。フレンド情報は、ユーザ間の交流や交友の有無や度合いを表す情報を含んでよい。
好み情報は、対応するユーザの好みであって、トークテーマに関連する好みを表す。好み情報は、任意であるが、ユーザの好む言語設定や、好むキーワードを含んでよい。また、ユーザがあらかじめ自分の好きなトークテーマや嫌いなトークテーマ(参加したくないトークテーマ)を設定することが可能であってよく、この場合、好み情報は、かかる設定内容を含んでよい。また、好み情報は、ユーザプロフィール情報を含んでよい。好み情報は、端末装置20上で生成されるユーザインタフェースを介して選択されて、JSON(JavaScript Object Notation)リクエスト等でサーバ装置10に提供されてもよい。
また、好み情報は、会話情報や行動履歴等に基づいて自動的に抽出されてもよい。例えばユーザが入室する頻度が高いトークルームの特徴を表してもよい。例えば、ユーザによっては、トークテーマが同じであっても、参加人数の比較的多い大規模なトークルームを好む傾向があったり、逆に、参加人数の比較的少ない小規模なトークルームを好む傾向があったりといった具合に、トークルームの規模に関して好みが分かれる場合がある。また、ユーザによっては、トークテーマが同じであっても、活性度が高いトークルーム(例えば各ユーザの発言数や発言頻度が多く活発に会話が進むトークルーム<例えば略して「活発トークルーム」>)を好む傾向があったり、逆に、活性度が低いトークルーム(例えば各ユーザの発言数や発言頻度が少なく静かでまったりと会話が進むトークルーム<例えば略して「まったりトークルーム」>)を好む傾向があったりといった具合に、トークルームの規模に関して好みが分かれる場合がある。従って、好み情報は、このような好みの傾向を表す情報を含んでもよい。
アバター情報記憶部146には、各ユーザのアバターを描画するためのアバター描画情報が記憶される。図21に示す例では、アバター描画情報は、各アバターIDに、顔パーツID、髪型パーツID、服装パーツID等が対応付けられる。顔パーツID、髪型パーツID、服装パーツID等の容姿に係るパーツ情報は、アバターを特徴付けるパラメータであり、各ユーザにより選択されてよい。例えば、アバターに係る顔パーツID、髪型パーツID、服装パーツID等の容姿に係る情報は、複数種類用意される。また、顔パーツIDについては、顔の形、目、口、鼻等の各種類にそれぞれパーツIDが用意され、顔パーツIDに係る情報は、当該顔を構成する各パーツのIDの組み合わせで管理されてもよい。この場合、各アバターIDに紐付けられた容姿に係る各IDに基づいて、サーバ装置10のみならず端末装置20側においても各アバターを描画することが可能となる。
トークデータ取得部150は、現在形成されているトークルームごとに、対応するトークルームにおいて発生するトーク(会話に係る発話)のログ(発話ログ)に基づいて、上述したトーク状況記憶部142内のトークデータを更新する。すなわち、トークデータ取得部150は、一のトークルームに関して、会話に係る会話関連入力をユーザから取得すると、当該会話関連入力の情報を、上述したトーク状況記憶部142内のトークデータに含める。なお、トークデータ取得部150によるトークデータの更新周期は、任意であるが、トークテーマが変化しやすいトークルーム(トークテーマが規定されていないトークルームや、上述したように自然に発生したトークルーム等)に対しては、比較的短い周期に設定されてもよい。これにより、データの更新処理に係る負荷を低減しつつ、トークルームの変化を比較的速やかに検出できる。
テーマ特定部152は、現在形成されているトークルームごとに、対応するトークルームにおけるトークテーマを特定する。すなわち、テーマ特定部152は、現在形成されているトークルームごとに、対応するトークルーム内で成立している会話に関して、そのテーマをトークテーマとして特定する。トークテーマの表示態様は、特に限定されないが、例として、複数のトークテーマを表示するようにしてもよい。例えば、メインテーマはあらかじめ運営者側または特定のユーザが設定し、その他のサブテーマは会話の内容によりテーマ特定部152が特定して表示するようにしてもよい。
テーマ特定部152は、あらかじめトークテーマが決まっているトークルームに対しては、当該トークテーマに沿った会話が継続されているか否かを監視してもよい。あるいは、テーマ特定部152は、当該トークテーマに対して、より詳細なトークテーマ(下位のトークテーマ)を特定してもよい。例えば、あらかじめ決まっているトークテーマが「アニメA」である場合、より詳細なトークテーマは、「アニメAのキャラクタB」であってもよい。このように、テーマ特定部152は、トークテーマを階層的な粒度で特定してもよい。
また、テーマ特定部152は、あらかじめトークテーマが決まっていないトークルームに対しては、トークテーマを初期的に特定してよい。そして、その後、テーマ特定部152は、あらかじめトークテーマが決まっているトークルームに対してと同様、当該初期的に特定したトークテーマに沿った会話が継続されているか否か(トークテーマの変化があったか否かを含む)を監視してもよい。また、テーマ特定部152は、あらかじめトークテーマが決まっていないトークルームに対しても、トークテーマを階層的な粒度で特定してもよい。
このようしてテーマ特定部152は、同じトークルームであってもトークテーマの変化や詳細化にも対応できる。すなわち、事前にトークテーマを設定していたとしても、会話の広がりによって内容が変わることがあるが、テーマ特定部152は、進行中の会話からトークテーマを特定するので、正確なトークテーマをリアルタイムでユーザに提示することが可能となる。
トークテーマの特定方法は多様であり、任意の方法が利用されてもよい。例えば、テーマ特定部152は、後述するキーワード抽出部154により抽出されたキーワードを利用して、トークテーマを特定してもよい。この場合、テーマ特定部152は、キーワード自体をトークテーマとして特定してもよいし、2つ以上のキーワードの組み合わせやその融合をトークテーマとして特定してもよいし、1つ以上のキーワードからトークテーマを導出してもよい。
あるいは、テーマ特定部152は、人工知能を利用して、トークデータ又は後述するキーワードを入力してトークテーマを出力(生成)することも可能である。人工知能の場合は、機械学習により得られる畳み込みニューラルネットワークを実装することで実現できる。機械学習では、例えば、トークデータに係る実績データ又は後述するキーワードに係る実績データを用いて、トークテーマの特定結果の精度が最大化するような畳み込みニューラルネットワークの重み等が学習されてよい。
なお、テーマ特定部152により特定されるトークテーマは、常に特定の単語である必要はなく、会話内容を要約したものや、会話の一部抜粋であってもよい。また、テーマ特定部152は、1つのトークルームに対して2つ以上のトークテーマ(例えばメイントークテーマとサブトークテーマの2種類)を特定してもよい。例えば、2つ以上のトークテーマは、上述した階層構造の関係を有してもよい。
キーワード抽出部154は、現在形成されているトークルームごとに、対応するトークルームにおけるトークデータ(各ユーザからの会話関連入力)に基づいて、キーワードを特定(抽出)する。キーワードの抽出方法は、任意であるが、例えば形態解析エンジン(例えば、“MeCab”)が利用されてもよい。キーワード抽出部154は、形態解析エンジンによりトークデータに係る文字列を単語に分割して単語リスト(又は分かち書きデータ)を生成してよい。そして、キーワード抽出部154は、名詞翻訳Tblや固有名詞翻訳Tblを参照して、単語リスト中の選択単語が抽出条件に適合するか否かを判定し、適合する場合、当該選択単語を抽出してキーワードとして出力(抽出)してもよい。また、キーワード抽出部154は、出現頻度の高いテキストを抽出し、重み付けによりキーワードを抽出してもよい。
この場合、キーワード抽出部154は、図20に示すような各種テーブル(図20では「Tbl」と表記)を利用して、キーワードを特定してもよい。この場合、名詞翻訳Tblには、各種名詞が登録される。この場合、各名詞には、概念、日本語読み、揺れ表記、絵文字等が対応付けられてよい。例えば、名詞“猫”については、概念として、「Cat」が対応付けられて、日本語読みとして「ねこ」が対応付けられて、揺れ表記や絵文字として、ねこ、猫、ネコ、neko、chat、ぬこ、(=^x^=)等が対応付けられてよい。また、固有名詞翻訳Tblには、各種固有名詞が登録される。この場合、各種固有名詞には、概念、日本語読み、揺れ表記、他言語表記等が対応付けられてよい。なお、名詞翻訳Tblや固有名詞翻訳Tblは、ロケールIDごとに参照されてよい。また、名詞翻訳Tblや固有名詞翻訳Tblは、新語や固有表現に対応できるように、補強されてもよい。また、あらかじめ優先度の高いトレンドワードTblを用意しておくことも可能である。この場合、トレンドワードとしてあらかじめ登録しているワードに対応するテキストをキーワードとして抽出してもよいし、当該テキストに対して高い重み付けを付与してもよい。なお、トレンドワードTblには、全ユーザの24時間以内の人気ワードや、年間のトップランキングのワードが収録されてよい。なお、上記では各種テーブルとして名詞翻訳Tblや固有名詞翻訳Tblを挙げたが、これらに限られず、動詞、句(フレーズ)、節、文などのテーブルもあってよい。このように、テーブルを使ってキーワードを特定することにより、ユーザごとに表現方法に揺れがあっても1つに集約したキーワードを特定できることとなる。また、多言語表記のテーブルを使う場合は、日本語で行われている会話であっても、対応する外国語キーワードを特定して外国語ユーザには外国語でトークテーマを提示するといったことも可能となる。
除外ワードTblは、上述したユーザ情報記憶部144内の除外ワード(禁止ワード)情報に対応してよい。除外ワードは、禁止ワードに加えて、キーワードとして抽出されるべきでないワード(例えばあいさつ)を含んでよい。除外ワードTblは、運営者側で作成されてよく、この場合、特定のユーザにより編集可能であってもよいし、トークルームの属性等に応じて異なってもよい。また、個人UserTblは、上述したユーザ情報記憶部144内のユーザID、会話情報(ロケールID、総配信時間)に対応してよい。TalkSessionTblは、トーク状況記憶部142内のデータに対応してよい。生発話ログは、トーク状況記憶部142内のトークデータに対応してよい。例えば、生発話ログは、時刻、トークID、ユーザID、及び、発話内容をテキスト化した文字情報の各項目の情報を含んでよい。文字チャットログは、トーク状況記憶部142内のトークデータに対応してよい。例えば、文字チャットログは、時刻、トークID、ユーザID、及びテキストの各項目の情報を含んでよい。
キーワード抽出部154は、抽出したキーワードを、TalkThemeTblに書き込み、TalkThemeTblを更新する。なお、TalkThemeTblには、トークIDごとに、ユーザID、キーワード(名詞、動詞、句(フレーズ)、節、文などを含む)、発話回数、出現頻度が記憶されてよい。なお、キーワード抽出部154が抽出するキーワードの数が比較的多い場合、名詞翻訳Tblを介して概念に変換した上で、同じ概念の頻度や回数に応じて、上位所定数(例えば3つ)の概念に絞られてもよい。この場合、テーマ特定部152は、上位所定数の概念に基づいて、トークテーマを特定できる。なお、この場合、テーマ特定部152は、上位所定数の概念自体をトークテーマとして特定してもよいし、上位所定数の概念を組み合わせたトークテーマを作出してもよい。キーワード抽出部154は、除外ワードTblを利用して、抽出したキーワードが除外ワードに該当するかしないかの検閲を行う。
キーワード抽出部154によるキーワード抽出処理の処理周期(TalkThemeTblやTalkSessionTblの更新周期等)は、任意であるが、トークデータの更新周期と同様、トークテーマが変化しやすいトークルームに対しては、比較的短い周期に設定されてもよい。すなわち、キーワード抽出部154によるキーワード抽出処理は、トークデータの更新ごとに実行されてよい。これにより、データの更新処理に係る負荷を低減しつつ、トークルームの変化を比較的速やかに検出できる。この場合、キーワード抽出部154によりキーワード抽出に用いるトークデータは、一定時間(例えば10分程度)ごとにリフレッシュ(すなわち一旦削除)されてもよいし、FIFO(First in First out)形式で直近の一定時間(例えば10分程度)が常時に維持されてもよい。
トーク管理部156は、各トークルームの状態を管理する。例えば、トーク管理部156は、空間部70のような規定されたトークルーム以外について、自然に発生しうる会話であって、トークルームを形成すべき会話を検出するための会話成立条件を判定してもよい。会話成立条件は、例えば、任意であり、例えば、事前に開始時刻が指定されている特定トークコンテンツについては、当該開始時刻が到来した場合に、当該トークコンテンツに係る会話成立条件が満たされてよい。また、事前に開始時刻が指定されていない特定トークコンテンツについては、例えば以下の条件要素が満たされた場合に、会話成立条件が満たされてもよい。
(条件要素1)2体以上のアバターが所定位置関係(又は第1属性の位置に位置する)であること。
(条件要素2)2体以上のアバターのユーザから会話関連入力がある。
(条件要素3)2体以上のアバターの発言の間隔、文脈、2体以上のアバター間の距離(仮想空間内の距離)、2体以上のアバター間での視線関係等に基づいて、会話状態と判断できる条件が満たされること。
また、トーク管理部156は、一のユーザ(アバター)と他のユーザ(アバター)とが会話をし始めて、例えば3ターンぐらい会話が続いたら会話成立条件が成立したと判断してもよい。このほかにも、会話成立条件としては、ターン数に限られず、一のユーザによる会話開始指示入力を契機としたり(例えばトークルーム開設のユーザインタフェースのボタンを選択すると、トークルーム形成)、一のユーザが所定位置に行くことを契機としたり(例えば図11に示すような立て看板や、図24に示すようなテーブルに行くと、トークルーム形成)してもよい。
トーク管理部156は、会話成立条件が満たされた場合に、上述した第1属性の領域R1及び第2属性の領域R2を設定してもよい。
また、トーク管理部156は、トークルームの消滅条件を判定してもよい。トークルームの消滅条件は、あらかじめ規定された終了時刻が到来した場合や、あらかじめ規定された経過時間が経過した場合、トークルーム内のアバターの数が所定数(例えば1)以下になった場合、トークルーム内での会話の頻度が所定基準以下となった場合等に満たされてもよい。
アバター決定部158は、各トークルームにおけるモデレータアバターM2(所定のアバター)を決定する。すなわち、アバター決定部158は、一のトークルームにおいて、会話を成立させている各ユーザに対応付けられたアバターのうちから、モデレータアバターM2を決定する。
アバター決定部158によるモデレータアバターM2の決定方法は任意である。例えば図7及び図8に示した例では、アバター決定部158は、張り紙やチラシ等を手にしたアバターを、モデレータアバターM2として特定してもよい。また、事前に開催が予約されていたトークルームについては、モデレータアバターM2として申請されたアバターをモデレータアバターM2として特定してもよい。
また、アバター決定部158は、自然に発生したトークルームや、事前に開催が予約されていたトークルームであってモデレータアバターM2が指定されていないトークルームについては、会話状況に応じてモデレータアバターM2を決定してもよい。例えば、アバター決定部158は、最も発話頻度が高いユーザに係るアバターを、モデレータアバターM2として決定してもよい。
また、アバター決定部158は、1つのトークルームが複数に分離された場合、分離後の各トークルームに対しては、自然に発生したトークルームの場合と同様の態様で、新たなモデレータアバターM2を決定してもよい。
また、アバター決定部158は、2つ以上のトークルームが併合された場合、併合後のトークルームに対しては、併合前のトークルームのそれぞれのモデレータアバターM2のうちの、1体以上のモデレータアバターM2を、新たなモデレータアバターM2として決定してもよい。例えば、アバター決定部158は、2つ以上のトークルームが併合された場合、併合前のトークルームの規模(例えば第1属性の領域R1に居る参加アバターM1の数)が大きい方のモデレータアバターM2を、新たなモデレータアバターM2として決定してもよい。
また、アバター決定部158は、テーマ特定部152と連携してモデレータアバターM2を決定してもよい。例えば、テーマ特定部152により特定されたトークテーマに係るキーワードの発話頻度が高いアバターを、モデレータアバターM2として決定してもよい。この場合、テーマ特定部152により特定されたトークテーマに係るキーワードの発話頻度が高いアバターが、モデレータアバターM2となるので、一のトークルームに対応付けられているモデレータアバターM2は、動的に変わりうる。また、上述したように、張り紙やチラシ等を手にしたアバターを、モデレータアバターM2として特定する場合においても、発生したトークテーマに興味を持つアバターが集まった場合、張り紙やチラシ等を手にしたアバターとトークテーマの対応付けが解除されてもよい(すなわち、張り紙やチラシ等を手にしたアバターがモデレータアバターM2でなくなってもよい)。
なお、モデレータアバターM2を決定する必要がない場合は、アバター決定部158は省略されてもよい。また、モデレータアバターM2を決定する必要がないトークルームに対しては、アバター決定部158が機能しなくてもよい。
配信処理部160は、1つ以上の特定トークコンテンツを配信する。また、配信処理部160は、図13や図15を参照して上述したように、配信中又は配信予定の特定トークコンテンツの配信種目を含むリスト情報を出力する。
設定処理部162は、仮想空間内に各トークルーム(所定の位置又は領域の一例)を位置付ける。仮想空間におけるトークルームの位置付けは、例えばトークルームの範囲や中心位置の座標値(場所)を設定することで実現されてもよい。例えば、設定処理部162は、図5を参照して上述したように、複数のトークルーム用の空間部70を設定することで、仮想空間にトークルームを位置付けてよい。空間部70の形態やサイズ(すなわちトークルームの形態やサイズ)は、任意であり、形態は、トークの形態に応じて決定されてもよいし、サイズは、参加アバターM1の人数のような規模に応じて決定されてもよい。
なお、スマートフォン等での視聴用のトークルーム画像H21(図14参照)に係るトークルームについては、空間部70(ワールド形態の仮想空間内の空間部)とは無関係に位置付けられてもよい。
設定処理部162は、トーク状況記憶部142内のトークIDごとに(すなわち現在進行中の会話のトークテーマごとに)トークルームが形成される態様で、仮想空間にトークルームを位置付けてよい。
また、設定処理部162は、共通の仮想空間内で複数のトークルームが形成されている場合、これらに対して特定されているトークテーマ同士の関連性又は従属性に基づいて、各トークルーム同士の距離を変化させてもよい。この際、2つのトークルームに関して、それらのトークテーマ同士の関連性が高いほど、これらのトークルーム同士の距離が短くされてもよい。また、2つのトークルームに関して、それらのトークテーマ同士に従属関係がある場合(例えば階層的に特定されているトークテーマの上位と下位の関係がある場合)、これらのトークルーム同士の距離が短くされてもよい。これにより、トークルームの併合のような、トークルームの変化を起こすことができ、トークルームの変化によるユーザ間の交流の広がりを促進できる。2つ以上のトークルームで似たようなトークテーマの会話がなされている場合、併合したほうが盛り上がる場合があり、かかる効果を期待できる。あるいは、上位のトークテーマに係るトークルーム内に、下位のテーマに係るトークルームを入れ子式に設定してもよい。
また、設定処理部162は、トークテーマの変化に基づいて、トークルームの位置を変化させてよい。すなわち、設定処理部162は、一のトークルームに係るトークテーマが変化した場合、当該一のトークルームの位置を変化させてもよい。これにより、例えば2つのトークルームに関して、それらのトークテーマ同士の関連性が高くなると、互いの離間距離が短くなり、逆に関連性が低くなると、互いの離間距離が長くなる。
また、設定処理部162は、トークルームの併合条件が満たされた場合に、2つ以上のトークルームを併合してもよいし、トークルームの分離条件が満たされた場合に、1つのトークルームを2つ以上のトークルームに分離してもよい。併合条件及び分離条件は、任意であるが、トークテーマが同じ又は類似するトークルームを併合したり、所定距離内のトークルーム同士を併合したり、一のトークルームにおいて複数のトークテーマが特定された場合(すなわちグループに分かれて別のテーマの会話が個々に発生した場合)に、当該一のトークルームを分離したりしてもよい。併合条件や分離条件が満たされた場合、トークルームの併合や分離は、トークルームの併合や分離を提案する通知がモデレータアバターM2に提示され、その提案を受け入れる指示入力がされたときに実現されてもよいし、参加アバターM1全員にもその提案通知が提示され、多数決で賛同が得られたときに実現されてもよい。
なお、設定処理部162は、トークテーマが類似するトークルームが2つ以上ある場合等に、併合を促進する通知処理(例えばコラボの案内等)を行ってもよい。これは、特定トークコンテンツの配信の場合も同様である。特定トークコンテンツの配信の場合、他の主催側ユーザが同じようなテーマで配信を開始していることに気がつかない場合がある。かかる通知処理によれば、他の人が「同じ話題で盛り上がりたい」ということに気がつくため、主催側ユーザ同士の衝突回避や、視聴者(参加側ユーザ)の取り合いを解消できる。
ユーザ抽出部164は、誘導対象のユーザを抽出する。誘導対象のユーザ(誘導対象のユーザに係るアバターと同義)は、特定のトークルームへの誘導が好ましいユーザや、特定のトークルームへの誘導が望まれるユーザ等であってよい。ユーザ抽出部164は、ユーザからの誘導リクエスト入力に基づいて、誘導対象のユーザを抽出してもよいし、仮想空間内におけるアバターの動きに基づいて、誘導対象のアバターを自動的に抽出してもよい。例えば、ユーザ抽出部164は、所望のトークルームを見つけられずにウロウロしていると推定されるアバターを検出した場合、当該アバターを誘導対象のアバターとして抽出してもよい。
誘導処理部166は、ユーザ抽出部164により誘導対象のユーザが抽出されると、当該誘導対象のユーザに対して、現在形成されている複数のトークルーム(誘導対象のユーザが参加可能なトークルーム)のうちから、案内対象のトークテーマで会話が行われているトークルームを決定(抽出)する。すなわち、誘導処理部166は、共通の仮想空間内で複数のトークルームが形成されている場合、複数のトークテーマのうちから、誘導対象のユーザに対する案内対象のトークテーマを決定する。
案内対象のトークテーマは、ユーザに関する情報(ユーザ情報記憶部144内のデータ)に基づいて決定されてよい。例えば、誘導処理部166は、誘導対象のユーザに対応付けられる会話情報に基づいて、案内対象のトークテーマを決定してもよい。例えば、誘導処理部166は、誘導対象のユーザに係る会話情報に比較的高い頻度で含まれるキーワードを含むトークテーマを、案内対象のトークテーマとして決定してもよい。また、誘導処理部166は、誘導対象のユーザに係る会話情報に含まれているキーワードに基づいて、当該キーワードに関連性の高いキーワード(例えば当該キーワードに対して下位概念となるキーワード)を含むトークテーマを、案内対象のトークテーマとして決定してもよい。
また、誘導処理部166は、誘導対象のユーザに対応付けられる好み情報に基づいて、案内対象のトークテーマを決定してもよい。例えば、誘導処理部166は、誘導対象のユーザに係る好み情報に合致するキーワードを含むトークテーマを、案内対象のトークテーマとして決定してもよい。また、誘導処理部166は、映画館のようなイベント会場の形態の空間部70から出てくるアバターに係る誘導対象のユーザに対しては、当該イベントに関連するトークテーマを、案内対象のトークテーマとして決定してもよい。
なお、誘導処理部166は、誘導対象の一のユーザに対して案内対象のトークテーマを複数決定してもよい。この場合、誘導処理部166は、複数の案内対象のトークテーマに対して優先順位付けしてもよい。例えば、誘導処理部166は、誘導対象の一のユーザに対して複数の案内対象のトークテーマを決定した場合は、フレンド情報に基づいて、複数の案内対象のトークテーマに対して優先順位付けしてもよい。この場合、誘導対象の一のユーザに対してフレンド関係のユーザが多くいるトークルームに係るトークテーマに対して優先順位が高くなる態様で、優先順位付けを実現してもよい。
また、後述するようにトークテーマが階層構造(例えばツリー構造)で管理されている場合、誘導処理部166は、階層構造の上位側から下位側へと順に辿れる態様で、階層構造の上位側のトークテーマを初期の案内対象のトークテーマとして決定してもよい。例えば、図22に示す例は、トークテーマAが例えば「アニメ」であり、トークテーマBが例えば「〇〇の刃」、トークテーマCが例えば「〇〇の拳」、トークテーマDが例えば「〇〇の刃に登場するキャラクタX」、トークテーマGが例えば「〇〇の刃に登場するキャラクタXのボスYとの戦いについて」、といった具合に、4段階の階層構造(上位カテゴリとしての最上位、上位、中位、及び下位)を有する。この場合、誘導処理部166は、ユーザに関する情報に基づいて誘導対象の一のユーザがアニメに興味があると判断した場合に、トークテーマA「アニメ」を初期の案内対象のトークテーマとして決定してもよい。
誘導処理部166は、誘導対象の一のユーザに対して案内対象のトークテーマを決定すると、当該案内対象のトークテーマに対応付けられたトークルーム(以下、「案内対象のトークルーム」とも称する)へと、誘導対象の一のユーザに対応付けられたアバター(以下、「案内対象アバターM5」とも称する)が到達しやすくする案内処理を実行してよい。案内処理は、後述するように、誘導対象の一のユーザの端末装置20と連携して実現されてよい。例えば、案内処理は、案内対象のトークテーマ又は当該トークテーマに係るトークルームを“おすすめ”のカテゴリ(図15参照)に紐付けることで、誘導対象のユーザに視認されやすくしてもよい。あるいは、案内対象のトークテーマを示す表示媒体(図3の表示媒体302R等)やテーマ表示(図13のテーマ表示G1302等)を、他よりも強調させてもよい。強調の仕様としては、例えば、色を変える、文字を大きくする、絵を大きくする、おすすめマークを付けるなどとしてよい。案内対象のトークテーマに係る案内処理の他の例については、図25を参照して後述する。
また、誘導処理部166は、誘導対象の一のユーザに対して複数の案内対象のトークテーマを決定した場合は、優先順位に合致した順に、案内対象のトークルームへと案内対象アバターM5が到達しやすくなるように、案内処理を実行してよい。また、後述するようにトークテーマが階層構造(例えばツリー構造)で管理されている場合、誘導処理部166は、階層構造の上位側から下位側へと順に辿れる態様で、案内対象のトークルームへと案内対象アバターM5が到達しやすくなるように、案内処理を実行してよい。
また、誘導処理部166は、他の因子に基づいて、案内対象のトークテーマを決定してもよい。例えば、主催側ユーザからの対価の支払いに応じて、当該主催側ユーザにより主催される特定トークコンテンツへの誘導を促進してもよい。この場合、例えば、当該特定トークコンテンツに対応付けられているトークテーマを表す表示媒体を他よりも目立たせることとしてもよい。なお、競合する類似のトークテーマが存在する場合、誘導処理部166は、このような因子に基づいて、案内対象のトークテーマを決定してもよい。
また、誘導処理部166は、後述する端末装置20のテーマ情報出力処理部256と連携して、トークテーマを表す表示媒体(例えば図3の表示媒体302R参照)やトークテーマを示すテーマ表示(例えば図13のテーマ表示G1302参照)の表示態様を変化させることで、補助的な案内処理を実行してよい。例えば、テーマ情報出力処理部256は、誘導対象の一のユーザの好み情報等に基づいて、トークテーマを表す表示媒体等の視認しやすさを変化させてもよい。この場合、テーマ情報出力処理部256は、好みに合うトークテーマが目立つように、トークテーマを表す表示媒体等の視認しやすさを変化させてもよい。
テーマ管理部168は、仮想空間において異なるトークテーマの複数の会話が成立している場合に、図22を参照して上述したように、複数のトークテーマを階層状に分岐させた階層構造で管理する。これにより、階層構造に沿って上述した誘導処理部166による案内処理を実現できる。
パラメータ算出部170は、トークルームにおける会話の活性度(すなわちトークルームの活性度)を表す活性度パラメータ(所定パラメータの一例)の値を算出する。パラメータ算出部170は、一のトークルームに対する活性度パラメータについて、当該一のトークルームに係る参加アバターM1の数(総数や延べ数)、各参加アバターの発話頻度等に基づいて、算出してもよい。この場合、参加アバターM1の数が大きいほど又は発話頻度が高いほど活性度が高くなる態様で、活性度パラメータの値を算出してもよい。また、パラメータ算出部170は、単位時間あたりの参加アバターM1の数(総数や延べ数)等に基づいて、活性度パラメータを算出してもよい。
また、ギフトを贈ることが可能なトークルームについては、パラメータ算出部170は、更に、ギフトオブジェクト(例えば図14のハート型のギフトオブジェクトG12参照)の数や頻度に基づいて、活性度パラメータの値を算出(又は補正)してもよい。これは、ギフトと同様の性質を有するコメント(参加側ユーザからのコメント等)についても同様である。また、各ユーザの発話の音量情報(ボリューム情報)が取得可能である場合、パラメータ算出部170は、音量が大きいほど活性度が高くなる態様で、活性度パラメータの値を算出してもよい。また、パラメータ算出部170は、拍手音や笑い声、歓声等に基づいて、活性度パラメータの値を算出(又は補正)してもよい。
また、パラメータ算出部170は、会話の中に居るアバターのモーション等の非言語情報に基づいて、活性度パラメータの値を算出(又は補正)してもよい。例えば、パラメータ算出部170は、ユーザの頷きの動きの頻度等に基づいて、頷きの頻度が高いほど活性度が高くなる態様で、活性度パラメータの値を算出してもよい。
また、パラメータ算出部170は、特定のアバター(例えばインフルエンサーや有名人等に係るアバター)の有無に応じて、一のトークルームに対する活性度パラメータの値を補正してもよい。
パラメータ算出部170は、一のトークルームに対する活性度パラメータの値を算出すると、算出値に基づいてトーク状況記憶部142内のデータを更新する。なお、トーク状況記憶部142内の活性度パラメータに係るデータは、時系列データとして保存されてもよい。この場合、活性度の変化やトレンド(上昇傾向か下降傾向等)を考慮することも可能となる。なお、一のトークルームに対するパラメータ算出部170による活性度パラメータの算出タイミングは、任意であるが、所定周期ごとに実行されてもよいし、参加アバターM1の数が変動した場合等に実行されてもよい。
端末用データ取得部172は、各端末装置20が以下で図23から図27を参照して説明する各種機能を実現できるように、各端末装置20用の各種データを取得する。各種データは、トーク状況記憶部142内のデータや、各種アバターの状態(位置や動き)を表すデータ、各種会話に係る文字情報又は音声情報に係るデータ等を含んでよい。なお、各種アバターの状態(位置や動き)を表すデータは、各アバターのモーション情報や位置情報(仮想空間における座標)を含んでよい。
端末用データ送信部174は、端末用データ取得部172により取得された各種データを各端末装置20に送信する。各端末装置20に送信する送信データの一部又は全部は、端末装置20ごとに異なってもよいし、共通であってもよい。例えば、一のユーザに係る端末装置20には、トーク状況記憶部142内のデータや各種アバターの状態を表すデータ等のうちの、当該一のユーザに係るアバターが存在するトークルームに関するデータのみが、送信されてもよい。送信データの更なる詳細については、以下の図23から図27を参照した説明に関連して説明する。
会話支援処理部176は、トークルームにおける各種会話を支援するための支援処理を行う。支援処理は、任意であるが、例えば、会話の中のキーワードやトークルームのトークテーマに合致したデジタルコンテンツを特定し、トークルーム内のディスプレイ(例えば図10の壁掛けのディスプレイオブジェクトM10参照)上に再生してもよい。例えば、特定の動画について話している場合は、当該特定の動画を再生する。このようなデジタルコンテンツ(会話の中のキーワードやトークルームのトークテーマに合致したデジタルコンテンツ)の特定は、端末装置20側で実現されてもよい。
次に、図23から図27を参照して、主に端末装置20の機能について説明する。
図23は、上述したトークテーマに関連した端末装置20の機能を示す概略的なブロック図である。
以下では、主に一の端末装置20について説明するが、他の端末装置20についても実質的に同様であってよい。また、以下では、説明対象の一の端末装置20を利用するユーザ及びそのアバターを、自ユーザ又は自アバターとも称し、それ以外のユーザ又はそのアバターを、他ユーザ又は他アバターとも称する。
端末装置20は、図23に示すように、アバター情報記憶部240と、端末用データ記憶部242と、端末用データ取得部250と、画像生成部252と、情報出力部254と、テーマ情報出力処理部256と、配信出力部258と、活性度出力部260と、ユーザ入力取得部262と、ユーザ入力送信部264と、案内情報出力部266と、補助情報出力部268とを含む。
なお、図23において、アバター情報記憶部240及び端末用データ記憶部242は、図1に示した端末装置20の端末記憶部22により実現できる。また、端末用データ取得部250から補助情報出力部268の各部の機能は、図1に示した端末装置20の端末制御部25や端末通信部21により実現できる。
アバター情報記憶部240には、後述する端末用データ取得部250により取得されるアバター情報が記憶される。アバター情報は、図21に示したサーバ装置10のアバター情報記憶部146内のデータの一部又は全部に対応してよい。
端末用データ記憶部242には、後述する端末用データ取得部250により取得される端末用データが記憶される。端末用データは、後述する画像生成部252、情報出力部254、テーマ情報出力処理部256、配信出力部258、及び活性度出力部260の各部の処理に必要なデータであってよい。
端末用データ取得部250は、上述したサーバ装置10の端末用データ送信部174により送信される送信データに基づいて、端末用データを取得する。端末用データ取得部250は、取得した端末用データに基づいて、端末用データ記憶部242内のデータを更新する。なお、端末用データの取得タイミングは、任意であり、端末用データのうちの、動的に変化しうるデータは、所定周期ごとであってもよいし、プッシュ型又はプル型で実現されてもよい。例えば、端末用データのうちの、アバターの状態(位置や動き)を表すデータや会話に係る文字情報又は音声情報に係るデータは、所定周期ごとに取得されてもよい。他方、端末用データのうちの、第2オブジェクトM3等のような仮想空間の基本データは、比較的長い周期で更新されてもよい。
画像生成部252は、自アバターが位置する仮想空間を表現する端末用画像(端末出力用画像の一例)を生成する。画像生成部252は、例えば、端末用データ記憶部242内のデータに基づいて、仮想空間のうちの、アバターを除く部分を描画してよい。この場合、自ユーザ(自アバター)に係る仮想カメラの視点は、入力部24を介した自ユーザからのユーザ入力に基づいて設定及び変更してよい。そして、画像生成部252は、仮想カメラの視野内に1つ以上の他アバター(描画対象の他アバター)が位置する場合、アバター情報記憶部146内のデータであって、対応する1つ以上の他アバターに係るアバター描画情報に基づいて、対応する1つ以上の他アバターを描画する。なお、自ユーザ(自アバター)に係る仮想カメラの視点は、デフォルトとして、自アバターの目の視点、すなわち1人称視点(図25参照)とされてもよい。ただし、仮想カメラの視点は、自アバターの移動中は3人称視点とされ、会話中は1人称視点(図25参照)とされるといった具合に、自アバターの状態に応じて自動的に変化されてもよい。
なお、画像生成部252は、例えばモデレータアバターM2が着替え等を行った場合(すなわち髪型や服装に係るIDを変化させた場合)は、それに応じてモデレータアバターM2の容姿を更新してよい。
画像生成部252は、端末用データ取得部250により取得された端末用データのうちの、描画対象の1つ以上の他アバターの状態(位置や動き)を表す情報に基づいて、1つ以上の他アバターの位置の変化や動きを表現してよい。なお、画像生成部252は、発話する際の他アバターの口や顔の動きを表現する場合、当該他アバターに係る音声情報と同期する態様で、当該表現を実現してもよい。
具体的には、例えば、自ユーザに係る仮想カメラの視野内の他アバターが正面方向を有するキャラクタの形態である場合、画像生成部252は、他ユーザが右を向くと、対応する他アバターが右(又は左)を向き、他ユーザが下を向くと、対応する他アバターが下を向くといった態様で、他アバターの向きを他ユーザの向きに連動させてもよい。なお、この場合、向きは、顔だけであってもよいし、身体だけであってもよいし、これらの組み合わせであってもよい。これにより、他アバターと他ユーザとの間の向きの整合性(連動性)が高くなり、他アバターの向きによる表現の多様化が可能となる。
また、他アバターが視線方向を有するキャラクタの形態である場合、画像生成部252は、他ユーザの視線が右を向くと、他アバターの視線が右(又は左)を向き、他ユーザの視線が下を向くと、他アバターの視線が下を向くといった態様で、他アバターの視線の向きを他ユーザの視線の向きに連動させてもよい。また、瞬きなど、目の各種動きを連動させてもよい。また、鼻や口などの動きを連動させてもよい。これにより、他アバターと他ユーザとの間のパーツごとの整合性(連動性)が高くなり、他アバターによる表情の多様化が可能となる。
また、他アバターが手を有するキャラクタの形態である場合、画像生成部252は、他ユーザが右手を上げると、他アバターが右手(又は左手)を上げ、他ユーザが両手を上げると、他アバターが両手を上げるといった態様で、他アバターの手の動きを他ユーザの手の動きに連動させてもよい。また、指など手の各部の動きについても連動させてもよい。また、足等の他のパーツについても同様に連動させてもよい。これにより、他アバターと他ユーザとの間の整合性(連動性)が高くなり、他アバターのパーツの動き等による表現の多様化が可能となる。
なお、本実施形態では、端末用画像の描画処理は、端末装置20の画像生成部252により実行されるが、他の実施形態では、端末用画像の描画処理の一部又は全部は、サーバ装置10により実行されてもよい。例えば、サーバ装置10を形成するWebサーバから受領したHTML文書やそれに付随する各種プログラム(Javascript)をブラウザが処理することによって実現されてもよい。すなわち、サーバ装置10によって画像生成用データを生成し、端末装置20は、サーバ装置10から受信した画像生成用データに基づいて、端末用画像を描画してもよい。このような構成では、画像生成用データは、端末用データ取得部250によりサーバ装置10から、都度、取得されてよい。すなわち、端末装置20において必要となる各種データの一時的な記憶は、端末装置20の端末記憶部22を形成するRAM(Random Access Memory)により実現できる。RAMには、各種データが一時記憶機能として展開されるが、この場合、例えば、サーバ装置10において作成されたHTML文書に基づいて、各種データをダウンロードし、一時的にRAMにデータが展開されて、ブラウザでの処理(描画等)に使用される。ブラウザを閉じると、RAMに展開されたデータは消去される。また、更なる変形例では、サーバ装置10によって生成された画像データに基づいてストリーミング形式で端末用画像が出力されてもよい。
情報出力部254は、仮想空間内の各アバターに対応付けられた各ユーザからの会話関連入力に基づいて、自ユーザが視聴可能な文字情報又は音声情報を、画像生成部252により生成された端末用画像とともに出力する。この場合、情報出力部254は、仮想空間内における各トークルームと、自アバターの位置との位置関係に基づいて、会話に係る文字情報又は音声情報の出力先ユーザを決定する。この場合、一のトークルーム内の会話に係る文字情報又は音声情報の出力先ユーザは、当該一のトークルーム内の各アバターに係るユーザを含んでよい。このようにして、自ユーザ(及びその端末装置20)に係る情報出力部254は、仮想空間内の各トークルームのうちの、自アバターが存在するトークルームに関してのみ、自ユーザが視聴可能な文字情報又は音声情報を端末用画像とともに出力してよい。
また、情報出力部254は、第1属性の領域R1及び第2属性の領域R2が対応付けられているトークルームに自アバターが位置する場合、第1属性の領域R1及び第2属性の領域R2に対する自アバターの位置関係に基づいて、会話に係る文字情報又は音声情報の出力態様を変更してもよい。具体的には、情報出力部254は、自アバターが、一のトークルームの第1属性の領域R1及び第2属性の領域R2に位置する場合のみ、当該一のトークルーム内の会話に係る文字情報又は音声情報を、自ユーザの端末装置20に出力してもよい。また、情報出力部254は、一のトークルーム内の第2属性の領域R2よりも外側に自アバターが位置する場合、当該一のトークルーム内の会話に係る音声情報を、比較的低いボリュームで自ユーザの端末装置20に出力してもよい。
また、情報出力部254は、フリー空間部71に自アバターが位置する場合等には、周辺のトークルーム内の会話に係る音声情報を、所定のボリュームで自ユーザの端末装置20に出力してもよい。所定のボリュームは、対応するトークルームの活性度が高いほど大きくなる態様で、対応するトークルームの活性度パラメータの現在値等に応じて変化されてもよい。
また、情報出力部254は、例えば図13や図15を参照して上述したような選択画面において、一のユーザの入力指示に応じて一の特定トークコンテンツが選択された場合、配信出力部258と連携して、当該一のユーザに係る端末装置20に、選択された一の特定トークコンテンツに係る会話の文字情報や音声情報等を、端末用画像とともに出力する。例えば、図13に示す例では、情報出力部254は、図14を参照して上述したトークルーム画像H21とともに、特定トークコンテンツに係る会話の文字情報や音声情報等を出力する。
テーマ情報出力処理部256は、サーバ装置10のテーマ特定部152により特定されたトークテーマを表すテーマ情報を端末用画像に含ませるテーマ情報出力処理を行う。テーマ情報の出力態様は、任意であり、例えば、図9、図10、図11、図13、図14等を参照して上述したとおりである。例えば、図10に示す例では、第2属性の領域R2に入ろうとしているアバターM7を自アバターとすると、テーマ情報出力処理部256は、自アバターに係る仮想カメラからの視野内に、“トークテーマA”の文字情報等を含む表示媒体1002Rが入る場合、端末用画像(自アバターに係るユーザ用の端末用画像)に、表示媒体1002Rを描画する。
なお、テーマ情報出力処理部256は、トークテーマを示す表示媒体(図3の表示媒体302R等)やテーマ表示(図13のテーマ表示G1302等)を出力する場合、端末用画像における位置や向きは、仮想空間内の位置や向きと必ずしも一致しなくてもよい。例えば、トークテーマを示す表示媒体は、上述したようにビルボードの形態(常に正面方向を向く態様)で出力されてもよい。
また、テーマ情報出力処理部256は、自ユーザの好み情報や属性情報等に基づいて、トークテーマを表す表示媒体(例えば図3の表示媒体302R参照)やトークテーマを示すテーマ表示(例えば図13のテーマ表示G1302参照)の表示態様を変化させてもよい。例えば、テーマ情報出力処理部256は、自ユーザの好み情報等に基づいて、自ユーザの好きなトークテーマを示す表示媒体等については強調表示し、反対に嫌いなトークテーマを示す表示媒体等については小さく表示又は非表示としてもよい。
配信出力部258は、サーバ装置10の配信処理部160により配信される各特定トークコンテンツのうちの、自ユーザにより選択された特定トークコンテンツを出力する。なお、配信出力部258による特定トークコンテンツの出力の際の描画は、上述した画像生成部252と同様の態様で実現されてよい。
活性度出力部260は、端末用データ取得部250により取得された端末用データのうちの、活性度情報(図18参照)に基づいて、活性度情報(会話の活性度を表す情報)を端末用画像に含ませる。活性度情報の出力態様は、任意であるが、例えば活性度パラメータの現在値がメータ(ゲージ)表現で出力されてもよい。
あるいは、活性度出力部260は、活性度パラメータの現在値を間接的に表す出力を実現してもよい。例えば、活性度出力部260は、活性度パラメータの現在値に応じた各種エフェクトを発生させてもよい。例えば、発話内容を表す文字情報に、“魔法陣エフェクト”として、トークルーム内の所定オブジェクトに対する特定の色による着色や、立ち昇るパーティクルの発生等を実現させてもよい。パーティクルは、図24に模式的に示すように、仮想空間内で立ち昇る態様で表現されてもよい。この場合、活性度が高いほど立ち昇るパーティクルオブジェクトM24(第2オブジェクトM3)が多くなる態様で、エフェクトを発生させてもよい。また、パーティクルオブジェクトM24は、活性度パラメータの値の特定の変化(例えば急増等)をトリガとして発生されてもよい。
また、活性度出力部260は、上述した第1属性の領域R1及び/又は第2属性の領域R2を仕切る線(サークル)の表示態様(例えば点滅の有無や太さ等)を、活性度パラメータの現在値に応じて変化させてもよい。なお、第1属性の領域R1及び/又は第2属性の領域R2を仕切る線(サークル)の色は、モデレータアバターM2に係るユーザにより選択されてもよいし、トークテーマごと又はトークテーマの上位カテゴリごとに自動設定されてもよいし、言語(ロケールID)ごとに設定されてもよい。なお、図24には、トークテーマを表す表示媒体2402Rが図示されている。この場合、表示媒体2402Rは、会話をしているアバターの頭上に浮遊する文字列の形態であってよい。例えば、図24に示す状況では、バーのような空間部に配置されるカウンターM34で立ち話をしている2体のアバターM26は、パーティクルオブジェクトM24が立ち昇る会話に係る表示媒体2402Rを見て、当該会話に参加するかどうか相談することもできる。
また、活性度出力部260は、活性度が高いトークルームに対しては「活発トーク中」のタグを対応付けてもよいし、逆に、静かなトークルームには「まったりトーク中」のタグを対応付けてもよい。
ユーザ入力取得部262は、端末装置20の入力部24を介して自ユーザからの各種入力を取得する。入力部24は、例えば、自ユーザ用の端末用画像に形成されるユーザインタフェースにより実現されてもよい。
図25は、アバターが自由に動き回ることができるワールド形態の仮想空間に好適なユーザインタフェースの一例を示す図である。図25には、自アバターの一人称視点から、他アバター(この場合、ユーザB及びユーザCに係る各アバター)と会話している状態の端末用画像G1700が示されている。
図25に示す例では、ユーザインタフェースは、メインインタフェース300を含み、メインインタフェース300は、椅子ボタン301と、いいねボタン302と、チケット管理ボタン303と、友達管理ボタン304と、退出ボタン305を含む。また、図25に示す例では、端末用画像は、別のユーザインタフェースである会話用インターフェース309を含む。
椅子ボタン301は、参加アバターM1の状態を、着座状態と非着座状態との間で切り替える際に操作される。例えば、各ユーザは、参加アバターM1を介してじっくりと話したいときなどに、椅子ボタン301を操作することで、椅子M4に着座するための着座指示を生成できる。なお、図25では、ユーザB及びユーザCに係るアバターM1は、椅子M4に着座した状態である。
例えば、椅子ボタン301は、参加アバターM1の状態が着座状態であるときに操作されると、解除指示が生成される。この場合、椅子ボタン301は、参加アバターM1の状態が着座状態であるときと、移動可能状態(例えば非着座状態)であるときとで、異なる指示(着座指示又は解除指示)を生成する。なお、参加アバターM1の状態が着座状態であるとき、参加アバターM1が第1属性の領域R1に位置するのと同様の効果が実現されてもよい。
椅子ボタン301の形態は、任意であるが、図25に示す例では、椅子の形態である。この場合、直感的にわかりやすいユーザインタフェースを実現できる。なお、椅子ボタン301は、フリー空間部71のような特定の空間に自アバターが位置する場合だけ操作可能とされてもよい。
なお、一の参加アバターM1に係る椅子ボタン301は、当該一の参加アバターM1の状態が着座状態であるときと、当該一の参加アバターM1の状態が移動可能状態であるときとで、異なる態様で描画されてもよい。例えば、一の参加アバターM1の状態が着座状態であるときと、当該一の参加アバターM1の状態が移動可能状態であるときとで、椅子ボタン301の色や形態等が異なってもよい。あるいは、変形例では、着座指示用のボタンと、解除指示用のボタンとが別々に描画されてもよい。この場合、着座指示用のボタンは、参加アバターM1が移動可能状態であるときに操作可能に描画され、参加アバターM1が着座状態であるときに操作不能に描画されてもよい。また、解除指示用のボタンは、参加アバターM1が移動可能状態であるときに操作不能に描画され、参加アバターM1が着座状態であるときに操作可能に描画されてもよい。
いいねボタン302は、参加アバターM1を介して他の参加アバターM1に良い評価やギフト等を与える際に操作される。
チケット管理ボタン303は、チケットの各種状態を閲覧可能なチケット管理画面(図示せず)を出力させる際に操作される。チケットは、特定の空間部70(例えば有料の特定トークコンテンツに係るトークルーム)への入室の際に提示が必要な仮想現実媒体であってよい。
友達管理ボタン304は、フレンド関係となっている他の参加アバターM1に関する友達管理画面(図示せず)を出力させる際に操作される。
退出ボタン305は、仮想空間又はトークルームから参加アバターM1を退出させる際に操作される。
会話用インターフェース309は、テキスト及び/又は音声によるチャット形式で実現される会話関連入力用の入力インターフェースである。この場合、ユーザは、マイクのアイコン3091を操作して発話することで音声入力(マイクロフォンの形態の入力部24からの音声入力)が可能であり、また、テキスト入力領域3092にテキストを入力することでテキスト入力が可能である。これにより、ユーザ同士で会話が可能となる。なお、テキストは、一定数の履歴が残る対話形式で各端末用画像(対話している各ユーザに係る各端末用画像)に描画されてよい。この場合、例えば、テキストは、仮想空間に係る画像とは別に出力されてもよいし、仮想空間に係る画像に重畳して出力されてもよい。
なお、上述したように第1属性の領域R1及び第2属性の領域R2を有するトークルームに自アバターが位置する場合、会話用インターフェース309は、自アバターが第1属性の領域R1に位置する場合のみ、アクティブ化(又は表示)されてもよい。また、アイコン3091は、自ユーザからの操作に応じてミュート化可能であってもよい。なお、この場合でも、自ユーザは、テキスト入力を介した他ユーザとの会話が可能である。
図26は、ジェスチャによるパーツ向き操作入力の説明図である。図26には、自ユーザが、端末装置20を手で持ちながら、顔の向きを変化させることで、パーツ向き操作入力を行う様子が示されている。この場合、端末装置20は、端末カメラ24Aを介して入力される自ユーザの顔画像に基づいて、自ユーザの顔を特定し、特定した顔の向きに応じたパーツ向き操作入力を含む操作入力情報を生成する。あるいは、自ユーザが、端末装置20を手で持ちながら、端末装置20の向きを変化させることとしてもよい。この場合、端末装置20は、端末装置20に内蔵される加速度センサ24Bに基づいて、端末装置20の向きに応じたパーツ向き操作入力を含む操作入力情報を生成してもよい。
ジェスチャによる操作入力は、仮想カメラの視点の変更に利用されてもよい。例えば、自ユーザが、端末装置20を手で持ちながら、端末装置20の向きを変化させると、その方向に応じて、仮想カメラの視点が変化されてもよい。この場合、スマートフォンのような比較的小さい画面の端末装置20を利用する場合でも、ヘッドマウントディスプレイを介して周囲を見渡せるのと同様の態様で視認領域の広さを確保できる。
ユーザ入力送信部264は、ユーザ入力取得部262により取得される上述した各種ユーザ入力をサーバ装置10に送信する。このようにしてサーバ装置10に送信される自ユーザからの各種ユーザ入力の一部又は全部に基づくデータは、他ユーザの端末装置20に係る端末用データとして、サーバ装置10を介して、他ユーザの端末装置20の端末用データ取得部250に取得されうる。なお、変形例では、自ユーザの端末装置20と他ユーザの端末装置20の間のP2Pによるデータのやり取りが実現されてもよい。
案内情報出力部266は、自ユーザが誘導対象のユーザとして抽出された場合に機能する。すなわち、案内情報出力部266は、自アバターが案内対象アバターM5となる場合に機能する。案内情報出力部266は、上述したサーバ装置10の誘導処理部166と連携して、案内対象のトークルームへと、自アバター(案内対象アバターM5)が到達しやすくする案内処理を実行する。
図27は、案内処理の一例を説明するためのユーザ用の端末用画像の一例を示す図である。なお、図27に示す案内処理は、アバターが自由に動き回ることができるワールド形態の仮想空間に好適な処理である。
図27は、案内情報として矢印の線1300、1500が自アバター(案内対象アバターM5)に対応付けて描画されている。この場合、案内情報出力部266は、案内対象アバターM5と案内対象のトークルームとの間の位置関係に基づいて、案内対象のトークルームへと移動するための推奨ルートである案内ルートを算出する。この際、案内情報出力部266は、通過できないオブジェクトなどの障害物に係るオブジェクトを通ることのない案内ルート(すなわち、案内対象アバターM5が移動できる案内ルート)を算出してよい。そして、案内情報出力部266は、算出した案内ルートに基づいて、案内ルートに沿った図27に示すような矢印の線1300、1500とともに、トークテーマ案内情報1600、1700(テーマ情報)を描画する。これにより、案内対象アバターM5に係るユーザは、トークテーマBに係るトークルームへは矢印の線1300に沿って移動すればよいことを容易に理解できるとともに、距離が100mであることを理解できる。また、案内対象アバターM5に係るユーザは、トークテーマCに係るトークルームへは矢印の線1500に沿って移動すればよいことを容易に理解できるとともに、距離が50mであることを理解できる。なお、図27においては、ワープ領域1100が設定されており、トークテーマCに係るトークルームへは、ワープ領域1100を介して効率的に移動できる。なお、かかるワープ領域1100は、トークテーマが階層構造で管理されている場合に出現されてもよい。この場合、分岐ごとにワープ領域1100が設定されてよく、ワープ領域1100ごとに分岐先をユーザが決定可能であってもよい。なお、トークテーマが階層構造で管理されている場合の案内態様は、これに限られず、概念的な分岐地図を提示してもよいし、ワープ領域1100に代えてドア(第2オブジェクトM3)が設定されてもよい。なお、概念的な分岐地図は、双六や電車の路線図のような形態であってもよい。
なお、図27に示す例では、案内対象のトークルームへの距離情報が補足的に出力されているが、これに加えて又は代えて、案内対象のトークルーム内におけるフレンドユーザの数や、活性度情報が出力されてもよい。この場合、ユーザは、トークテーマのみならず、距離やフレンドの有無等をも考慮して、複数の案内対象のトークルームのうちから所望のトークルームを選択できる。また、案内情報出力部266は、フレンドユーザ以外にも、過去に参加したトークルームに係るキーワードが多く一致するユーザとの交流を案内してもよい。例えば、案内情報出力部266は、過去に参加したトークルームに係るキーワードが多く一致するユーザとお友達になるよう勧めたり、ワープボタン(図示せず)等により仮想空間内で、過去に参加したトークルームに係るキーワードが多く一致するユーザの近くに移動できるようにしたりしてもよい。「お友達になることのお勧め」の通知は、ユーザの端末装置20の表示部23に通知されてもよい。また、まったく会話に参加したことない初心者ユーザの便宜に備えて、ユーザが話したいトークテーマを1または複数選択すると、そのトークテーマの会話に過去に参加したユーザを抽出して「お友達になることのお勧め」、「近くに移動」を通知してもよいし、またはそのトークルームを提示するようにしてもよい。これにより、最初に友達がいないユーザであっても、見ず知らずのユーザと最初に話すきっかけを効果的に作ることができる。
補助情報出力部268は、ユーザにとって利便性の高い各種補助情報を出力する。例えば、補助情報出力部268は、各トークルームに参加可否情報(図18のトーク状況記憶部142のデータ参照)を対応付けてもよい。例えば、トークルームの扉(第2オブジェクトM3)や会話参加前の画面に、参加可能または参加不能なのかを提示してもよい。例えば、「入室可!」、「誰でも凸可能!」や「はいらないでね!」などのメッセージ板(第2オブジェクトM3)が対応付けられてもよい。あるいは、補助情報出力部268は、参加不能のトークルームを、鍵がかかっていて入れない状態にしてもよいし、視認不能にしてもよい。その場合、補助情報出力部268は、参加可能なトークルームについてユーザの視界(仮想カメラの視野内)に入りやすくしてもよい。
また、補助情報出力部268は、トークルームで行われている会話の言語が自ユーザの言語と異なる場合に、会話に係る文字情報又は音声情報の出力と同期して、当該文字情報又は音声情報に対する翻訳(例えば字幕の形態)を出力してもよい。
また、補助情報出力部268は、特定のトークテーマによる会話の終了時に二次会のトークテーマを提示してもよい。この場合、残ったユーザ(参加者)で次のテーマを決めることとしてもよい。あるいは、補助情報出力部268は、これまでの会話情報に基づいて、自動で次のトークテーマ候補を提案してもよい。あるいは、補助情報出力部268は、既存の別の会話情報から近しいトークテーマを提示してもよい。
次に、図28以降を参照して、図1に示した仮想現実生成システム1における各種動作例について更に説明する。
図28は、一のトークルームの生成から配信終了までの動作の流れの説明図である。図28には、横軸を時間として、一のトークルームの生成から配信終了までの動作の流れが概略的に示されている。
まず、ステップS180では、トークルームが生成(形成)される。トークルームは、上述したように、特定トークコンテンツの配信の場合は主催側ユーザによるリクエスト(予約等)に応じて形成されてもよいし、ワールド形態の仮想空間の場合はアバター同士の会話の流れで自然に形成されてもよいし、形成条件は任意である。なお、トークルームが生成(形成)されると、当該トークルームに対してトークIDが付与され、また、適宜、上述した第1属性の領域R1及び第2属性の領域R2が定義されてよい。
トークルームが生成(形成)されると、トークルーム内での会話/配信の状態が形成される(S182)。このような状態において、トークテーマの特定のための各種処理が実行される。具体的には、発話内容がテキスト化され(図では、「発話内容STT」と表記)(S1821)、形態素解析(S1822)及び検閲(S1823)を経て、トークテーマが特定(及び表示)(S1824)される。そして、トークルームの消滅条件が満たされると(例えば配信終了時刻になると)、配信終了となる(S184)。なお、ワールド形態の仮想空間の場合は、配信終了に代えて、トークルームが消滅してもよいし、他の利用に開放されてもよい。なお、会話がチャットなどによる文字入力による場合は、上記したステップのうち発話内容がテキスト化されるステップ(図では、「発話内容STT」)(S1821)は、省略されてよい。
ここで、発話内容のテキスト化(S1821)や形態素解析(S1822)は、サーバ装置10で実行されるが、端末装置20で実行されてもよい。これにより、トークテーマの特定のための各種処理に係る処理コストを分散させ、サーバ装置10の負荷を低減できる。なお、検閲(S1823)は、名詞翻訳Tbl等の各種辞書の管理上、サーバ装置10により実行されるのが好適であるが、一部の処理が端末装置20により実行されてもよい。また、トークテーマの特定及び表示(S1824)のうちの、トークテーマの特定はサーバ装置10により実行されるのが好適であるが、一部の処理が端末装置20により実行されてもよい。また、トークテーマの特定及び表示(S1824)のうちの、トークテーマの表示(描画)は、端末装置20により実行されるのが好適であるが、サーバ装置10により実行されてもよい。
図29は、図1に示した仮想現実生成システム1において行われる主催側(コンテンツ配信側)の端末装置20A、参加側(コンテンツ視聴側)の端末装置20B、及びサーバ装置10の動作であって、主催側ユーザによる特定トークコンテンツの配信中(すなわち参加側ユーザによる特定トークコンテンツの視聴中)の動作の一例を示すフロー図である。
なお、図29において、左側には、一の主催側の端末装置20Aにより行われる動作が示され、中央には、サーバ装置10(ここでは1つのサーバ装置10)により行われる動作が示され、右側には、一の参加側の端末装置20Bにより行われる動作が示されている。
ステップS210において、主催側ユーザは、トークテーマに応じた配信を開始し、モデレータアバターM2の各種動作を実現すべく各種動作(会話に係る発話動作を含む)を行う。これにより、主催側の端末装置20Aは、モデレータアバターM2の各種動作に応じた主催側ユーザ情報を生成する。主催側の端末装置20Aは、このような主催側ユーザ情報を、端末装置20Bに係る端末用データとして、サーバ装置10に送信する。なお、主催側ユーザ情報は、伝送される(伝送された)情報と基準時間に基づくタイムスタンプとの対応関係が主催側の端末装置20A及び参加側の端末装置20Bの両方において明らかであるという条件が満たされる限りにおいて、任意の多重方式により相互に多重されサーバ装置10に送信されてもよい。このような条件が満たされていれば、参加側の端末装置20Bは、主催側ユーザ情報を受信したときに、主催側ユーザ情報に対応するタイムスタンプに従って適切に処理することができる。多重方式については、主催側ユーザ情報は、それぞれ、別々のチャネルを介して送信されてもよいし、主催側ユーザ情報のうちの一部が同一のチャネルを介して送信されてもよい。チャネルは、タイムスロット、周波数帯域、及び/又は、拡散符号等を含み得る。なお、基準時間を利用した動画(特定トークコンテンツ)の配信方法は、ここでの参照により本願明細書に組み込まれる特許第6803485号公報に開示される態様で実現されてもよい。
次に、ステップS210における動作と並行して、主催側の端末装置20Aは、ステップS212において、参加側ユーザ用のトークルーム画像H21を描画するための主催側ユーザ情報を継続的に参加側の端末装置20Bにサーバ装置10を介して送信するとともに、主催側の端末装置20Aに主催側ユーザ用のトークルーム画像(図示せず)を出力する。
主催側の端末装置20Aは、ステップS210及びステップS212における動作を、以下に説明するステップS214~ステップ222における動作と並行して行うことができる。
次に、ステップS214において、サーバ装置10は、主催側の端末装置20Aから継続的に送信されてくる主催側ユーザ情報を、参加側の端末装置20Bに送信(転送)する。
ステップS216において、参加側の端末装置20Bは、サーバ装置10から主催側ユーザ情報を受信して端末記憶部22に記憶させる。一実施形態では、音声情報が他の情報に比べて大きな容量を有する可能性及び/又は通信回線に障害が発生する可能性を考慮して、参加側の端末装置20Bは、サーバ装置10から受信した主催側ユーザ情報を一時的に端末記憶部22(図1参照)に記憶(バッファリング)することができる。
このような主催側ユーザ情報を受信及び記憶することに並行して、ステップS218において、参加側の端末装置20Bは、主催側の端末装置20Aからサーバ装置10を介して受信及び記憶した主催側ユーザ情報を用いて、参加側ユーザ用のトークルーム画像H21を生成して特定トークコンテンツを再生する。
上述したステップS216及びステップS218における動作と並行して、ステップS220において、参加側の端末装置20Bは、参加側ユーザ情報を生成し、参加側ユーザ情報を、端末装置20Aに係る端末用データとして、サーバ装置10を介して主催側の端末装置20Aに送信する。参加側ユーザ情報は、例えば、参加側ユーザが会話関連入力を入力した場合や、ギフトを贈る操作を行った場合等にだけ、生成されてもよい。
ステップS222において、サーバ装置10は、参加側の端末装置20Bから受信した参加側ユーザ情報を、主催側の端末装置20Aに送信(転送)する。
ステップS224において、主催側の端末装置20Aは、参加側ユーザ情報をサーバ装置10を介して受信することができる。
ステップS226において、主催側の端末装置20Aは、基本的にステップS210におけるものと同様の動作を行うことができる。例えば、主催側の端末装置20Aは、ステップS224において受信した参加側ユーザ情報に基づいて、参加側アバターM1の描画指示及び/又はギフト描画指示を生成し、トークルーム画像に、対応する参加側アバターM1及び/又はギフトオブジェクトを描画する。なお、描画指示に加えて音声出力指示が生成された場合には、描画及び音声出力がなされる。
このようにして、図29に示す処理は、主催側ユーザによる特定トークコンテンツの配信が終了するまで又は当該特定トークコンテンツの参加側ユーザがいなくなるまで継続的に実行されてよい。
なお、図29に示す例において、各処理の実行主体は、上述のように多様な態様で変更可能である。例えば、ステップS212の処理のうち、主催側ユーザ用のトークルーム画像(図示せず)を生成する処理は、端末装置20Aに代えて、サーバ装置10で実現されてもよい。また、ステップS218の処理のうち、参加側ユーザ用のトークルーム画像H21を生成する処理は、端末装置20Aやサーバ装置10で実現されてもよい。この場合、ステップS216では、主催側ユーザ情報に代えて、参加側ユーザ用のトークルーム画像H21のデータが受信されてよい。また、ステップS226の処理のうち、参加側ユーザ情報に基づいて主催側ユーザ用のトークルーム画像(図示せず)にギフトオブジェクトを描画する処理は、端末装置20Aに代えて、サーバ装置10で実現されてもよい。
また、図29に示す例は、主催側(コンテンツ配信側)と参加側(コンテンツ視聴側)の役割が区別されているが、これらの役割の区別はなくてもよい。例えば、各アバターが自由に動き回ることができるワールド形態の仮想空間においては、上述したように、参加アバターM1やモデレータアバターM2の役割の区別は説明の都合上であり、アバターとしては実質的な差異はなくてよい。すなわち、各アバターが自由に動き回ることができる仮想空間においては、各端末用画像は、それぞれの仮想カメラの視点からの仮想空間内の様子を示す画像であるので、役割の区別は不要である。
以上、実施形態について図面を参照して詳述してきたが、具体的な構成は上述した各種実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
例えば、上述した実施形態においては、トークルームは、各ユーザの自由な参加が可能であるが、ユーザの属性等に応じて参加可能なトークルームが異なってもよいし、プライベートトークルームのような特別なトークルームが設定されてもよい。プライベートトークルームのような特別なトークルームに対しては、トークテーマは特定されてなくてもよいし、特定されたとしても、対応するトークテーマを示すテーマ表示等(テーマ情報)の出力が禁止されてもよい。従って、各ユーザの自由な参加が可能なトークルームに対してだけ、トークテーマを表す表示媒体等が出力されてもよい。
また、上述した実施形態において、公式イベントなどの主催側のリクエストに応じて、トークルームにおける言語を固定することが可能とされてもよい。この場合、異なる言語の発話が検出された場合に、言語に関する注意に係る通知等が実施されてもよい。
また、上述した実施形態では、一のトークルームに対応付けられているトークテーマは、テーマ特定部152による特定結果に応じて変化しうるが、例えば主催側ユーザからのリクエストや設定に基づいて、かかる変化が禁止可能とされてもよい。この場合、主催側ユーザが会話の途中でテーマを意図的に脱線させたときでも、当該脱線に起因してトークテーマが変化してしまう可能性を防止できる。
また、上述した実施形態において、例えば以下のような変形を加えてもよい。
・トークテーマを表示する表示媒体302R(立て看板など)が他のユーザの視界に入ったかどうかを判定して、イベントフック又はログを作り、広告効果測定とする。
・課金ユーザなどのインセンティブに対して、トークテーマを表示する表示媒体302R(立て看板など)を大きく、見やすくするため、アニメーションや電飾などで強調表示する。付言すると、表示媒体302Rを立て看板として構成した場合には、立て看板は固定の位置に通常配置されるが、この場合、仮想空間の中での他の要素との相対的関係により立て看板が目立ち難いときがあり得る。そのような場合、実空間における立て看板と同じように目立たせ、立て看板そのものの可視性を向上させるため、トークテーマに関して「装飾」という機能を立て看板に付与してもよい。具体的な装飾機能の例としては、前述のとおり、立て看板について、設置のサイズ(面積)を大きくする、情報面をアニメーションにする(YouTubeや動画ファイルなど任意のURLを与えて立て看板内に表示させる)、電飾のようなエフェクト(効果)を情報の周囲に加えることとしてよく、さらには、仮想空間内ではなく検索機能(例えば、“虫眼鏡絵文字”)で検索する際に検索時に特定のキーワードでトークテーマを含めてこのイベントの情報と画像を表示する(「リスティング広告(検索連動広告)」に類似の機能)といった点を追加してもよい。そして、このような装飾機能を加える場合には、追加課金を設定するようにしてもよい。
・トークテーマを表示する表示媒体302R(立て看板など)が他のユーザの視界に入ったこと、サークルに近づいた他のユーザがいることを、当該トークテーマへの参加者に通知する。
・上記通知によって、当該他のユーザの方向に参加済みのアバターの向きを自動で変えて、エモートを自動再生する。エモートはアバターに感情表現ごとに決まったポーズ(仕草)を取らせる機能であるが、ここでは、例えば、参加済みのアバターが近づいていてくる当該他のユーザの方向に向かって、一斉に又はアバター別に、「パチパチ」と拍手をしたり、「ピース」のサインを送ったりするようにしてもよい。このほかにも、例えば、「握手」を求めたり、「手招き」や「ハグ」などのポーズをしたりするようにもできる。一方、他のユーザがサークルを離れていく際には、「バイバイ」と手を振ったり、「ごめんね」と手を合わせたり、「またね」と手を挙げたりするようにしてもよい。なお、同じポーズでも国によってその受け取め方が異なることもあるため(例えば、ある国では他意のないポーズでも、別の国によっては侮辱的なポーズと受け取められることがある)、ポーズは、当該他のユーザの国籍ごとに、そのときの感情表現に適切に対応するものに使い分けられるよう考慮されてよい。
・上記自動エモートは、当該他のユーザの属性を「初心者」、「話し相手募集」、「話したくない」といったタグ、話題、言語属性などによって分類してもよい。
・上記自動エモートは、トークルームの会話の現在の活性度に応じてもよい。
以上の実施形態に関して、更に、以下の付記を開示する。
(付記1)
各ユーザに対応付けられたアバターを含む仮想空間を表現する端末出力用画像を生成する画像生成部と、
仮想空間内のアバターに対応付けられた各ユーザからの会話関連入力に基づいて、各ユーザが視聴可能な文字情報又は音声情報を前記端末出力用画像とともに出力する情報出力部と、
前記情報出力部により出力される前記文字情報又は前記音声情報に基づいてユーザ間で成立している会話に関して、前記会話関連入力に基づいて前記会話のテーマを特定するテーマ特定部と、
前記テーマ特定部により特定された前記会話のテーマを表すテーマ情報を前記端末出力用画像に含ませるテーマ情報出力処理を行うテーマ情報出力処理部と、を備える、情報処理システム。
(付記2)
前記テーマ情報出力処理部は、一のユーザに係るユーザ情報に基づいて、前記一のユーザに対する前記テーマ情報の出力方法を決定する、付記1に記載の情報処理システム。
(付記3)
前記情報出力部は、一のユーザの入力指示に応じて前記テーマ情報が出力された前記会話が選択された場合、前記一のユーザに、選択された前記テーマ情報に係る前記会話の前記文字情報又は前記音声情報を出力する、付記1又は2に記載の情報処理システム。
(付記4)
1つ以上の所定デジタルコンテンツを配信するとともに、配信中又は配信予定の前記所定デジタルコンテンツの配信種目を含むリスト情報を出力する配信処理部を更に備え、
前記テーマ情報出力処理は、前記リスト情報に、前記所定デジタルコンテンツに係る前記会話のテーマを表す前記テーマ情報を対応付けることを含む、付記1又は2に記載の情報処理システム。
(付記5)
前記配信処理部は、前記所定デジタルコンテンツの配信種目を、対応するサムネイルを含む態様で出力する、付記4に記載の情報処理システム。
(付記6)
前記情報出力部は、一のユーザの入力指示に応じて一の前記所定デジタルコンテンツが選択された場合、前記一のユーザに、選択された一の前記所定デジタルコンテンツに係る前記会話の前記文字情報又は前記音声情報を出力する、付記4又は5に記載の情報処理システム。
(付記7)
前記情報出力部は、仮想空間内における前記会話のテーマに対応付けられた所定の位置又は領域と、各アバターの位置との位置関係に基づいて、前記会話に係る前記文字情報又は前記音声情報の出力先ユーザを決定する、付記1から3のうちのいずれか1項に記載の情報処理システム。
(付記8)
前記テーマ情報出力処理は、前記所定の位置又は領域に、前記テーマ情報に係る所定表示媒体を対応付けることを含む、付記7に記載の情報処理システム。
(付記9)
前記会話を成立させている各ユーザに対応付けられたアバターのうちから、所定のアバターを決定するアバター決定部を更に備え、
前記テーマ情報出力処理は、前記所定のアバターに、前記テーマ情報に係る所定表示媒体を対応付けることを含む、付記7又は8に記載の情報処理システム。
(付記10)
前記会話のテーマに対応付けられた前記所定の位置又は領域は、第1属性の位置又は領域と、前記第1属性とは異なる第2属性の位置又は領域とを含み、
前記情報出力部は、前記所定の位置又は領域に位置する1人以上のアバターに対応付けられた各ユーザのうちの、前記第1属性の位置又は領域に位置する1人以上のアバターに対応付けられたユーザのみからの前記会話関連入力に基づいて、前記所定の位置又は領域に位置する1人以上のアバターに対応付けられた各ユーザに対して、前記文字情報又は前記音声情報を出力する、付記7から9のうちのいずれか1項に記載の情報処理システム。
(付記11)
前記第2属性の位置又は領域は、前記第1属性の位置又は領域に隣接して設定される、付記10に記載の情報処理システム。
(付記12)
仮想空間において異なるテーマの複数の前記会話を特定した場合に、前記会話のテーマごとに、前記所定の位置又は領域を対応付ける設定処理部を更に備える、付記7から11のうちのいずれか1項に記載の情報処理システム。
(付記13)
前記設定処理部は、前記会話のテーマ同士の関連性又は従属性に基づいて、各テーマに対応付ける前記所定の位置又は領域同士の距離を変化させる、付記12に記載の情報処理システム。
(付記14)
前記テーマ特定部は、前記会話のテーマの変化の有無を監視する、付記12又は13に記載の情報処理システム。
(付記15)
前記設定処理部は、前記会話のテーマの変化に基づいて、前記所定の位置又は領域を変化させる、付記14に記載の情報処理システム。
(付記16)
各ユーザに対応付けて、各ユーザが参加した前記会話に関する会話情報を記憶するユーザ情報記憶部と、
誘導対象のユーザを抽出するユーザ抽出部と、
仮想空間において異なるテーマの複数の前記会話が成立している場合に、誘導対象の一のユーザに対応付けられる前記会話情報に基づいて、複数の前記会話のテーマのうちから、前記誘導対象の一のユーザに対する案内対象のテーマを決定する誘導処理部と、を更に備える、付記7から15うちのいずれか1項に記載の情報処理システム。
(付記17)
一のユーザに対応付けられる前記会話情報は、前記一のユーザからの前記会話関連入力に基づいて抽出される、付記16に記載の情報処理システム。
(付記18)
前記誘導処理部は、前記案内対象のテーマに対応付けられた前記所定の位置又は領域へと、前記誘導対象の一のユーザに対応付けられたアバターが到達しやすくする、付記16又は17に記載の情報処理システム。
(付記19)
仮想空間において異なるテーマの複数の前記会話が成立している場合に、複数の前記会話のテーマを階層状に分岐させた階層構造で管理するテーマ管理部を更に備え、
前記誘導処理部は、前記誘導対象の一のユーザが前記階層構造の上位側から下位側へと順に辿れる態様で、前記階層構造の上位側のテーマを前記案内対象の初期のテーマとして決定する、付記16から18のうちのいずれか1項に記載の情報処理システム。
(付記20)
前記テーマ特定部は、各ユーザからの前記会話関連入力に基づいて、キーワードを抽出するキーワード抽出部を含む、付記1から19のうちのいずれか1項に記載の情報処理システム。
(付記21)
前記会話の活性度を表す所定パラメータの値を算出するパラメータ算出部と、
前記所定パラメータの算出値に基づいて、前記会話の活性度を表す情報を前記端末出力用画像に含ませる活性度出力部と、を更に備える、付記1から20のうちのいずれか1項に記載の情報処理システム。
(付記22)
各ユーザに対応付けられたアバターを含む仮想空間を表現する端末出力用画像を生成し、
仮想空間内のアバターに対応付けられた各ユーザからの会話関連入力に基づいて、各ユーザが視聴可能な文字情報又は音声情報を前記端末出力用画像とともに出力し、
出力される前記文字情報又は前記音声情報に基づきユーザ間で成立している会話に関して、前記会話のテーマを特定し、
特定した前記会話のテーマを表すテーマ情報を前記端末出力用画像に含ませることを含む、コンピュータにより実行される情報処理方法。
(付記23)
各ユーザに対応付けられたアバターを含む仮想空間を表現する端末出力用画像を生成し、
仮想空間内のアバターに対応付けられた各ユーザからの会話関連入力に基づいて、各ユーザが視聴可能な文字情報又は音声情報を前記端末出力用画像とともに出力し、
出力される前記文字情報又は前記音声情報に基づきユーザ間で成立している会話に関して、前記会話のテーマを特定し、
特定した前記会話のテーマを表すテーマ情報を前記端末出力用画像に含ませる、
処理をコンピュータに実行させる、プログラム。