特許 6526879 データ送信装置、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】6526879

(24)【登録日】2019年5月17日

(45)【発行日】2019年6月5日

(54)【発明の名称】データ送信装置、およびプログラム

(51)【国際特許分類】

   G06F 13/00 20060101AFI20190527BHJP

   G06F 3/16 20060101ALI20190527BHJP

【ＦＩ】

   G06F13/00 510G

   G06F13/00 650R

   G06F3/16 530

【請求項の数】10

【全頁数】21

(21)【出願番号】特願2018-120104(P2018-120104)

(22)【出願日】2018年6月25日

【審査請求日】2018年7月19日

【早期審査対象出願】

(73)【特許権者】

【識別番号】518412081

【氏名又は名称】株式会社バーチャルキャスト

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100153051

【弁理士】

【氏名又は名称】河野 直樹

(74)【代理人】

【識別番号】100179062

【弁理士】

【氏名又は名称】井上 正

(74)【代理人】

【識別番号】100199565

【弁理士】

【氏名又は名称】飯野 茂

(72)【発明者】

【氏名】川上 量生

(72)【発明者】

【氏名】松井 健太郎

(72)【発明者】

【氏名】岩城 進之介

(72)【発明者】

【氏名】小嶋 尚

(72)【発明者】

【氏名】山口 直樹

【審査官】 安藤 一道

(56)【参考文献】

【文献】 特開平１０−０５５２６１（ＪＰ，Ａ）

【文献】 特開２０１６−１８７０６３（ＪＰ，Ａ）

【文献】 特開２０１８−０６７１５７（ＪＰ，Ａ）

【文献】 特開２００３−１０８５０６（ＪＰ，Ａ）

【文献】 特表２０１０−５２０５３９（ＪＰ，Ａ）

【文献】 特開２００３−３０４３５０（ＪＰ，Ａ）

【文献】 国際公開第２０１７／０９８７７２（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｇ０６Ｆ ３／１６

(57)【特許請求の範囲】

【請求項1】

第１のアバターの仮想空間における第１の位置を示す第１の位置データと、前記第１のアバターの音声データとを取得する取得部と、
前記第１の位置に関する既定の条件が満足するか否かを判定する判定部と、
前記既定の条件が満足すると判定された場合に前記音声データを宛先端末へ向けて送信することを決定し、前記既定の条件が満足しないと判定された場合に前記音声データを前記宛先端末へ向けて送信しないことを決定する送信制御部と
を具備し、
前記既定の条件は、前記第１の位置が前記仮想空間における既定のゾーン内にあることであり、
前記判定部は、前記第１のアバターが前記仮想空間における既定のオブジェクトを装着しているか否かを判定し、前記第１のアバターが前記既定のオブジェクトを装着していると判定した場合には前記既定の条件が満足するか否かの判定を省略し、
前記送信制御部は、前記第１のアバターが前記既定のオブジェクトを装着していると判定された場合に、前記音声データを前記宛先端末へ向けて送信することを決定する、
データ送信装置。

【請求項2】

前記送信制御部は、前記既定の条件が満足すると判定された場合にピア・ツー・ピア型のネットワーク経由で前記音声データを前記宛先端末へ向けて送信することを決定する、請求項１に記載のデータ送信装置。

【請求項3】

前記既定のゾーンは、前記仮想空間における既定の地点からの距離に基づいて定められる、請求項１に記載のデータ送信装置。

【請求項4】

前記取得部は、前記第１のアバターの姿勢を決定づける制御データをさらに取得し、
前記送信制御部は、前記既定の条件が満足すると判定された場合に前記音声データと、前記制御データおよび前記第１の位置データの少なくとも一方とを宛先端末へ向けて送信することを決定し、前記既定の条件が満足しないと判定された場合に前記音声データを前記宛先端末へ向けて送信せず前記制御データおよび前記第１の位置データの少なくとも一方を前記宛先端末へ向けて送信することを決定する、
請求項１乃至請求項３のいずれか１項に記載のデータ送信装置。

【請求項5】

コンピュータを、
第１のアバターの仮想空間における第１の位置を示す第１の位置データと、前記第１のアバターの音声データとを取得する手段、
前記第１の位置に関する既定の条件が満足するか否かを判定する手段、
前記既定の条件が満足すると判定された場合に前記音声データを宛先端末へ向けて送信することを決定し、前記既定の条件が満足しないと判定された場合に前記音声データを前記宛先端末へ向けて送信しないことを決定する手段
として機能させるプログラムであって、
前記既定の条件は、前記第１の位置が前記仮想空間における既定のゾーン内にあることであり、
前記判定する手段は、前記第１のアバターが前記仮想空間における既定のオブジェクトを装着しているか否かを判定し、前記第１のアバターが前記既定のオブジェクトを装着していると判定した場合には前記既定の条件が満足するか否かの判定を省略し、
前記決定する手段は、前記第１のアバターが前記既定のオブジェクトを装着していると判定された場合に、前記音声データを前記宛先端末へ向けて送信することを決定する、
プログラム。

【請求項6】

第１のアバターの仮想空間における第１の位置を示す第１の位置データと、前記第１のアバターの音声データとを取得する取得部と、
前記第１の位置に関する既定の条件が満足するか否かを判定する判定部と、
前記既定の条件が満足すると判定された場合に前記音声データを宛先端末へ向けて送信することを決定し、前記既定の条件が満足しないと判定された場合に前記音声データを前記宛先端末へ向けて送信しないことを決定する送信制御部と
を具備し、
前記取得部は、前記仮想空間に存在する前記第１のアバターを含む複数のアバターの前記仮想空間における位置を示す位置データを取得し、
前記既定の条件は、前記複数のアバターの前記仮想空間における位置を前記仮想空間における既定の地点から近い順にソートした場合に前記第１の位置が既定の順位以上となることである、
データ送信装置。

【請求項7】

前記送信制御部は、前記既定の条件が満足すると判定された場合にピア・ツー・ピア型のネットワーク経由で前記音声データを前記宛先端末へ向けて送信することを決定する、請求項６に記載のデータ送信装置。

【請求項8】

前記判定部は、前記第１のアバターが前記仮想空間における既定のオブジェクトを装着しているか否かを判定し、前記第１のアバターが前記既定のオブジェクトを装着していると判定した場合には前記既定の条件が満足するか否かの判定を省略し、
前記送信制御部は、前記第１のアバターが前記既定のオブジェクトを装着していると判定された場合に、前記音声データを前記宛先端末へ向けて送信することを決定する、
請求項６または請求項７に記載のデータ送信装置。

【請求項9】

前記取得部は、前記第１のアバターの姿勢を決定づける制御データをさらに取得し、
前記送信制御部は、前記既定の条件が満足すると判定された場合に前記音声データと、前記制御データおよび前記第１の位置データの少なくとも一方とを宛先端末へ向けて送信することを決定し、前記既定の条件が満足しないと判定された場合に前記音声データを前記宛先端末へ向けて送信せず前記制御データおよび前記第１の位置データの少なくとも一方を前記宛先端末へ向けて送信することを決定する、
請求項６乃至請求項８のいずれか１項に記載のデータ送信装置。

【請求項10】

コンピュータを、
第１のアバターの仮想空間における第１の位置を示す第１の位置データと、前記第１のアバターの音声データとを取得する手段、
前記第１の位置に関する既定の条件が満足するか否かを判定する手段、
前記既定の条件が満足すると判定された場合に前記音声データを宛先端末へ向けて送信することを決定し、前記既定の条件が満足しないと判定された場合に前記音声データを前記宛先端末へ向けて送信しないことを決定する手段
として機能させるプログラムであって、
前記取得する手段は、前記仮想空間に存在する前記第１のアバターを含む複数のアバターの前記仮想空間における位置を示す位置データを取得し、
前記既定の条件は、前記複数のアバターの前記仮想空間における位置を前記仮想空間における既定の地点から近い順にソートした場合に前記第１の位置が既定の順位以上となることである、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）、ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）、またはＭＲ（Ｍｉｘｅｄ Ｒｅａｌｉｔｙ）技術に関する。

【背景技術】

【0002】

従来、ＨＭＤ（Ｈｅａｄ Ｍｏｕｎｔｅｄ Ｄｉｓｐｌａｙ）を装着した複数のユーザ間でネットワークを介して仮想体験、すなわちＶＲ体験を共有することが知られている。具体的には、仮想空間上においてユーザ間（アバター間）の音声チャット（ＶＲチャット）を実現することが知られている（特許文献１の［００８１］）。

【0003】

特許文献１には、「ユーザＡの音声を示す音声データ（ユーザＡの音声データ）をサーバ２に送信する」こと（［００７６］）、「サーバ２の制御部２３は、ユーザ端末１Ａから受信したユーザＡの音声データに関連する音量パラメータＬを設定する（ステップＳ１５）。ここで、音量パラメータＬはユーザ端末１Ｂのヘッドフォン１１６（音声出力部）に出力されるユーザＡの音声の音量（音圧レベル）を規定するパラメータである」こと（［００７８］）、「アバター４Ｂが仮想空間における高伝達領域に位置している場合には、音量パラメータＬを音量パラメータＬ１に設定する」および「アバター４Ｂが仮想空間における高伝達領域に位置していない場合には、音量パラメータＬを音量パラメータＬ２に設定する」こと（要約書）、「ユーザＡの音声データと、音量パラメータＬをユーザ端末１Ｂに送信する」こと（［００７９］）、「ユーザ端末１Ｂの制御部１２１は、ユーザＡの音声データと、音量パラメータＬとに基づいて、ユーザＡの音声をヘッドフォン１１６に出力する」こと（［００８１］）、などが開示されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特許第６２８９７０３号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

仮想空間において複数のユーザ間で例えば音声チャットのような聴覚的な仮想体験の共有を実現するために、各ユーザの端末から他の端末へ向けて音声データを送信することがある。このように端末間で音声データをやり取りすると、仮想体験を共有するユーザ数が増えるほど、音声データのトラフィック量が増大することになる。換言すれば、音声データのトラフィック量が、仮想空間に収容可能なユーザの最大数を制限する一要因となる可能性がある。これは、ＶＲ体験のみならず、ＡＲまたはＭＲといった仮想的な要素を含む体験（以降、仮想的体験と称する）全般において生じ得る。

【0006】

また、仮想的体験を共有するユーザ数が多すぎると、例えばあるユーザのアバターの音声が、同時に発話した他のユーザのアバターの音声に埋もれてしまい、聞き取ることが困難となるおそれもある。これは、例えば仮想空間においてライブなどのイベントを開催する場合により深刻である。すなわち、多くのユーザが注目している、出演者などの主要なアバターのトークや歌声が、観客などの他のアバターの笑い声、歓声、拍手、やじ、などのリアクションに埋もれてしまい、ユーザの仮想的体験を損なうおそれがある。

【0007】

本発明は、複数のユーザ間で仮想的体験を共有する場合に、音声データのトラフィック量を抑制し、またはユーザの仮想的体験の毀損を防止することを目的とする。

【課題を解決するための手段】

【0008】

本発明の一態様に係るデータ送信装置は、取得部と、判定部と、送信制御部とを含む。取得部は、第１のアバターの仮想空間における第１の位置を示す第１の位置データと、第１のアバターの音声データとを取得する。判定部は、第１の位置に関する既定の条件が満足するか否かを判定する。送信制御部は、既定の条件が満足すると判定された場合に音声データを宛先端末へ向けて送信することを決定し、既定の条件が満足しないと判定された場合に音声データを宛先端末へ向けて送信しないことを決定する。

【0009】

本発明の別の態様に係る端末は、取得部と、判定部と、送信制御部とを含む。取得部は、第１のアバターの仮想空間における第１の位置を示す第１の位置データと、第１のアバターの音声データとを取得する。判定部は、第１の位置に関する既定の条件が満足するか否かを判定する。送信制御部は、既定の条件が満足すると判定された場合にピア・ツー・ピア型のネットワーク経由で音声データを宛先端末へ向けて送信することを決定し、既定の条件が満足しないと判定された場合にクライアント／サーバ型のネットワーク経由で音声データを宛先端末へ向けて送信することを決定する。

【発明の効果】

【0010】

本発明によれば、複数のユーザ間で仮想的体験を共有する場合に、音声データのトラフィック量を抑制し、またはユーザの仮想的体験の毀損を防止することができる。

【図面の簡単な説明】

【0011】

【図1】実施形態に係る端末を例示するブロック図。

【図2】図１の端末を含む仮想的体験共有システムを例示するブロック図。

【図3】既定の条件（１）の説明図。

【図4】既定の条件（２）の説明図。

【図5】既定の条件（３）の説明図。

【図6】既定の条件（４）の説明図。

【図7】図１の端末の動作を例示するフローチャート。

【図8】変形例１に係る端末を含む仮想的体験共有システムを例示するブロック図。

【図9】変形例１に係る端末の動作を例示するフローチャート。

【図10】変形例２に係るサーバを例示するブロック図。

【発明を実施するための形態】

【0012】

以下、図面を参照しながら実施形態の説明を述べる。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。例えば、複数の同一または類似の要素が存在する場合に、各要素を区別せずに説明するために共通の符号を用いることがあるし、各要素を区別して説明するために当該共通の符号に加えて枝番号を用いることもある。

【0013】

（実施形態）
実施形態に係る端末は、仮想的体験共有システムを構成することができる。かかるシステムは、図２に例示される。このシステムでは、端末１００は互いに、例えばインターネットなどのネットワーク経由で接続されており、データを送受信できる。

【0014】

なお、図２のシステムでは、端末１００同士がサーバを介してデータを送受信するＣ／Ｓ（Ｃｌｉｅｎｔ ／ Ｓｅｒｖｅｒ）型のネットワークではなく、端末１００同士がデータを直接送受信するＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）型のネットワークが採用されている。しかしながら、Ｐ２Ｐ型のネットワークに代えて、またはＰ２Ｐ型のネットワークに追加して、Ｃ／Ｓ型のネットワークを採用したとしても、本実施形態に係る端末１００およびサーバを用いて仮想的体験共有システムを構築することは可能である。

【0015】

ここで、Ｐ２Ｐ型のネットワークは、Ｃ／Ｓ型のネットワークに比べて種々のメリットがある。具体的には、かかるメリットとして、データ伝送に伴う遅延が低減するのでリアルタイム性の高い仮想的体験の共有に適していること、サーバが存在しないためＣ／Ｓ型のネットワークではサーバに集中していたトラフィックおよび負荷を分散することができること、単一障害点が存在しないこと、などを挙げることができる。

【0016】

反面、Ｐ２Ｐ型のネットワークを採用すると、リンク数はユーザ数ｎに対してｎ×（ｎ−１）／２個となり、非線形に増加することになる。故に、Ｐ２Ｐ型のネットワークでは通常はユーザ数が増えると音声データのトラフィック量は爆発的に増大するため、Ｃ／Ｓ型のネットワークを採用した場合に比べて音声データのトラフィック量の問題がより深刻となり得る。

【0017】

端末１００は、ユーザの頭部に装着可能なＨＭＤ１０（第１のデバイス）に表示されるＶＲ／ＡＲ／ＭＲ画像、およびスピーカ（これは、ＨＭＤ１０に内蔵されていてもよいし、ＨＭＤ１０とは別体であってもよい。）によって出力されるＶＲ／ＡＲ／ＭＲ音声を制御するように構成されたコンピュータであり、当該ＨＭＤ１０とユーザが把持可能なコントローラ２０（第２のデバイス）とにそれぞれ接続されている。なお、コントローラ２０は、ユーザ毎に、２つ（両手用）用意されてもよいし、１つ（片手用）用意されてもよい。また、コントローラ２０は、手以外の部位に装着されてもよい。さらに、図２には示されていないものの、ＨＭＤ１０および／またはコントローラ２０の位置を検出するための位置センサシステムに含まれる要素の１つであるベースステーションがさらに端末１００に接続されてもよい。

【0018】

端末１００は、ＨＭＤ１０、コントローラ２０、および／またはベースステーションと、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ケーブル、ＨＤＭＩ（登録商標）（Ｈｉｇｈ―Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）ケーブル、などの有線通信手段により接続されてもよいし、例えばＢｌｕｅｔｏｏｔｈ（登録商標）、ＷｉｒｅｌｅｓｓＨＤ、ＷＨＤＩ（Ｗｉｒｅｌｅｓｓ Ｈｏｍｅ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ）、などの無線通信手段により接続されてもよい。

【0019】

端末１００は、後述されるように、マイクロホンによって生成された音声データを他の端末１００（宛先端末）へ既定の条件付きで送信する。他の端末１００は、この音声データを再生して出力する。これにより、音声データのトラフィック量を抑制しながらも、ユーザ間の音声チャット、またはライブなどの臨場感のあるイベントをＶＲ／ＡＲ／ＭＲ空間において実現することが可能となる。

【0020】

また、アバターの姿勢を動的に制御するために、端末１００は、後述されるようにＨＭＤ１０の位置およびコントローラ２０の位置に基づく値を持つ制御データを取得し、当該制御データを他の端末１００（宛先端末）へ向けて送信してもよい。制御データは、アバターの姿勢を決定づける。

【0021】

制御データを受信した他の端末１００は、受信した制御データに基づいてユーザのアバター画像を生成する。すなわち、ユーザは、ＨＭＤ１０を装着した頭やコントローラ２０を把持した手を動かすことで自らの分身であるアバターに自由な姿勢を取らせることができる。

【0022】

具体的には、他の端末１００は、受信した制御データの示すＨＭＤ１０の位置に応じてアバター画像の頭部の位置を決定し、当該制御データの示すコントローラ２０の位置に応じてアバター画像の手の位置を決定する。アバターの姿勢の制御には、例えばＩＫ（Ｉｎｖｅｒｓｅ Ｋｉｎｅｍａｔｉｃｓ）技術を利用することができる。

【0023】

ＨＭＤ１０は、アバター画像を含むＶＲ／ＡＲ／ＭＲ画像を表示するための表示装置に加え、種々のセンサ、スピーカ、マイクロホン、などを含み得る。種々のセンサは、動きセンサ、装着センサ、または位置センサシステムに含まれる要素の一部（後述されるマーカーまたはカメラ）を含み得る。ＨＭＤ１０は、端末１００から画像データおよび音声データを受け取って、これらを出力したり、各種センサのセンサデータを端末１００へ向けて送信したりする。

【0024】

表示装置は、透過型ディスプレイであってもよいし、非透過型ディスプレイであってもよい。例えば、ＨＭＤ１０を装着したユーザの視界の少なくとも一部を覆うように表示装置のサイズおよび配置が定められる。表示装置は、左目用表示装置と右目用表示装置とで構成されてもよいし、両者が一体化されていてもよい。

【0025】

動きセンサは、例えば、加速度センサ、ジャイロスコープ、磁気センサ、などであり得る。動きセンサによって検出されたセンサデータは、ユーザの頭部の姿勢（例えば傾き）の推定に利用することができる。具体的には、このセンサデータに基づいて、ユーザの頭部の３次元的な回転角であるＹａｗ角、Ｒｏｌｌ角、およびＰｉｔｃｈ角が推定され、これに応じてユーザの視界を決定する仮想カメラの視軸および／またはアバターの頭部の姿勢が制御され得る。

【0026】

装着センサは、ユーザがＨＭＤ１０を装着／取り外したことを示すセンサデータ（イベントデータ）を発生する。装着センサの仕組みは任意であるが、例えば、ＨＭＤ１０に設けられたバネの弾性力の変化、ＨＭＤ１０の装着時にユーザの鼻などの身体の一部に接触するパッド間を流れる電流の変化、などに応じてイベントデータを発生することが可能である。

【0027】

スピーカは、端末１００から音声データを受け取り、これに基づいて音声を出力する。スピーカは、典型的にはヘッドホン型であるが、これ以外のスピーカシステムとして構成されてもよい。マイクロホンは、音声（主にユーザの発話であるが、周囲の環境音を含み得る）を収集する。マイクロホンは、収集した音声に基づいて音声データを生成し、端末１００へ送る。

【0028】

コントローラ２０は、ユーザ入力を受け付けるボタンに加え、例えば、ＨＭＤ１０と同様の動きセンサ、位置センサシステムに含まれる要素の一部、などを含み得る。さらに、コントローラ２０は、ユーザがコントローラ２０を把持／手放したことを示すセンサデータ（イベントデータ）を発生する把持センサを含んでもよい。把持センサの仕組みは任意であるが、例えば、ユーザの把持力によりコントローラ２０に加わる圧力の変化、コントローラ２０の表面に設けられたセンサ電極と人体との間の静電容量の変化、などに応じてイベントデータを発生することが可能である。コントローラ２０は、ユーザ入力データ、各種センサのセンサデータ、などを端末１００へ向けて送信する。

【0029】

位置センサシステムは、例えばカメラ（ポジション・トラッキング・カメラ）とマーカー（トラッカーとも呼ばれる）との組み合わせにより実現される。マーカーは、赤外光または可視光のエミッタ（例えばＬＥＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ））であってもよいし、カメラの撮影時にエミッタから発せられる赤外光または可視光を反射するための反射材であってもよい。カメラは、マーカーが赤外光を照射または反射する場合には赤外線センサであり得るし、マーカーが可視光を照射または反射する場合には可視光カメラであり得る。

【0030】

典型的には、ＨＭＤ１０／コントローラ２０に複数のマーカーが取り付けられ、カメラがＨＭＤ１０／コントローラ２０から離れた位置に設置された装置（ベースステーション）に取り付けられる。カメラの撮影画像に基づいて、ＨＭＤ１０／コントローラ２０の位置を推定することができる。具体的には、ベースステーションは、撮影画像に基づいて検知点の位置、傾き、発光強度などを検出することができる。ベースステーションは、かかる検知点のデータに基づいてＨＭＤ１０／コントローラ２０の位置（座標）データを計算してもよいし、かかる計算は端末１００に委ねられてもよい。

【0031】

なお、変形例として、カメラをＨＭＤ１０／コントローラ２０側に設け、マーカーをベースステーション側に設けることも可能である。また、ＨＭＤ１０およびコントローラ２０に取り付けられるマーカーに加えて、ユーザの関節、抹消部などにさらなるマーカーが取り付けられてもよい。これにより、ユーザの姿勢をより正確に推定することが可能となる。

【0032】

以下、端末１００のハードウェア構成について説明する。端末１００は、ＨＭＤ１０の制御装置となり得る種々の電子デバイス、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、モバイル端末（例えば、タブレット、ファブレット、スマートフォン、ラップトップ、フィーチャーフォン、ウェアラブルデバイス、ポータブルゲーム機、など）、据え置き型ゲーム機、などであり得るが、これらに限られない。

【0033】

なお、端末１００は、ＨＭＤ１０または他のデバイス（コントローラ２０、ベースステーション、など）と必ずしも別体でなくてもよい。例えば、端末１００がＨＭＤ１０またはベースステーションに内蔵されていてもよいし、端末１００をコントローラ２０として扱うこともあり得る。

【0034】

端末１００は、例えば、入出力制御、通信制御（特に、音声データの送信制御）、画像／音声処理、既定の条件判定、などを行うプロセッサを含む。ここで、プロセッサは、典型的にはＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）および／またはＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であるが、マイコン、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、またはその他の汎用または専用のプロセッサなどであってもよい。

【0035】

また、端末１００は、かかる処理を実現するためにプロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータ、例えば、アバター、背景、などのＶＲ／ＡＲ／ＭＲ体験を演出するための各種オブジェクトの基となる画像データを一時的に格納するメモリを含んでいる。メモリは、かかるプログラム／データが展開されるワークエリアを有するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を含み得る。

【0036】

なお、端末１００は、全てのデータをオンメモリの状態で扱ってもよいし、一部のデータが補助記憶装置に退避されていてもよい。補助記憶装置は、例えば、端末１００に内蔵または外付けされたＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリなどであってもよいし、端末１００からアクセス可能なデータベースサーバであってもよい。

【0037】

端末１００は、さらに、ネットワークに接続するための通信Ｉ／Ｆ（インタフェース）を利用可能である。通信Ｉ／Ｆは、端末１００に内蔵されてもよいし、端末１００に外付けされてもよい。通信Ｉ／Ｆは、他の端末１００、および／または、外部装置、例えば、ＨＭＤ１０、コントローラ２０、ベースステーション、などと通信をするためのモジュールであって、送受信のための信号処理回路、アンテナ、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）端子などを含み得る。通信Ｉ／Ｆは、例えば移動通信などの広域通信用のモジュール、無線／有線ＬＡＮ用のモジュール、Ｂｌｕｅｔｏｏｔｈ用のモジュール、などであり得る。

【0038】

端末１００は、さらに、外部装置、例えば、ＨＭＤ１０、コントローラ２０、ベースステーション、などにケーブル接続するための入出力Ｉ／Ｆを利用可能である。入出力Ｉ／Ｆは、ＵＳＢ端子、ＤＶＩ（Ｄｉｇｉｔａｌ Ｖｉｓｕａｌ Ｉｎｔｅｒｆａｃｅ）端子、ＨＤＭＩ端子、またはその他のデータ転送用ケーブルのための端子、などである。

【0039】

端末１００は、さらに、各要素、例えば、プロセッサ、メモリ、補助記憶装置、通信Ｉ／Ｆ、入出力Ｉ／Ｆなどの間でデータを転送するためのバスを含み得る。

【0040】

図１には、端末１００の機能構成が例示される。端末１００は、入力部１０１と、受信部１０２と、送信部１０３と、出力部１０４と、データ取得部１１１と、距離算出部１１２と、条件判定部１１３と、送信制御部１１４と、画像生成部１１５と、音声生成部１１６とを含む。

【0041】

入力部１０１は、前述の入出力Ｉ／Ｆにより実現され得る。入力部１０１は、外部装置、例えば、ＨＭＤ１０、コントローラ２０、ベースステーション、マイクロホン（ＨＭＤ１０に内蔵されていてもよいし、別体であってもよい）、などから種々のデータを受け付ける。入力部１０１は、受け付けたデータをデータ取得部１１１へ送る。

【0042】

具体的には、入力部１０１は、アバター（端末１００のユーザに関連付けられるアバターであり、以降は第１のアバターと称する）仮想空間における位置を示す位置データ、マイクロホンによって生成された第１のアバターの音声データ、第１のアバターの姿勢を制御するための制御データ（これは、位置データと統合されてもよいし、別個のデータであってもよい）、などを受け付け得る。

【0043】

ここで、位置データは、例えば、ＨＭＤ１０および／またはコントローラ２０の位置を示すデータであってもよいし、これらに基づいて生成されたデータであってもよい。制御データについても同様である。なお、外部装置と端末１００との関係次第で、これらのデータの一部または全部が、入力部１０１ではなく受信部１０２によって受信されることもあり得る。

【0044】

受信部１０２は、前述の通信Ｉ／Ｆにより実現され得る。受信部１０２は、ネットワーク経由で、他の端末１００から、アバター（他の端末１００のユーザに関連付けられるアバターであり、以降は他アバターと称する）の仮想空間における位置を示す位置データ、他アバターの制御データおよび／または音声データを受信し得る。受信部１０２は、受信したデータをデータ取得部１１１へ送る。

【0045】

送信部１０３は、前述の通信Ｉ／Ｆにより実現され得る。送信部１０３は、送信制御部１１４によって制御され、第１のアバターの音声データ、位置データおよび／または制御データを宛先端末へ向けて送信する。

【0046】

出力部１０４は、前述の入出力Ｉ／Ｆにより実現され得る。出力部１０４は、外部装置、例えば、ＨＭＤ１０、スピーカへ出力データ、具体的には、出力部１０４は、ＶＲ／ＡＲ／ＭＲ画像データをＨＭＤ１０へ出力したり、ＶＲ／ＡＲ／ＭＲ音声データをスピーカへ出力したりする。さらに、出力部１０４は、ＨＭＤ１０および／またはコントローラ２０へ、触覚フィードバック用のバイブレータ（図示されない）を振動させるための振動データを出力してもよい。

【0047】

データ取得部１１１は、前述のプロセッサにより実現され得る。データ取得部１１１は、入力部１０１および受信部１０２から種々のデータを取得する。データ取得部１１１は、取得したデータを、距離算出部１１２、条件判定部１１３、画像生成部１１５および／または音声生成部１１６へ送る。

【0048】

具体的には、データ取得部１１１は、第１のアバターの音声データ、位置データ、および制御データ、などに加えて、他アバターの音声データ、位置データ、および制御データ、などを取得し得る。

【0049】

例えば、データ取得部１１１は、第１のアバターの位置データを距離算出部１１２および条件判定部１１３へ送り、第１のアバターの音声データおよび制御データを条件判定部１１３へ送り、他アバターの位置データを距離算出部１１２へ送り、他アバターの制御データを画像生成部１１５へ送り、他アバターの音声データを音声生成部１１６へ送り得る。

【0050】

なお、外部装置、例えば、ＨＭＤ１０、コントローラ２０および／またはベースステーションがＨＭＤ１０／コントローラ２０の位置を推定して第１のアバターの位置データ／制御データを生成する場合には、データ取得部１１１は入力部１０１または受信部１０２から位置データ／制御データを直接取得することができる。他方、端末１００（の図示されない位置／姿勢推定部）が位置センサシステムの出力データ（例えば、検知点の位置、傾き、発光強度などを示すデータ）に基づいてＨＭＤ１０／コントローラ２０の位置を推定して第１のアバターの位置データ／制御データを生成する必要がある場合には、データ取得部１１１はこの位置／姿勢推定部へ位置センサシステムの出力データを送り、位置データ／制御データの生成を依頼してもよい。

【0051】

距離算出部１１２は、前述のプロセッサにより実現され得る。距離算出部１１２は、仮想空間における２地点間の距離を算出する。具体的には、距離算出部１１２は、仮想空間における基準地点から第１のアバターまたは他アバターの居る地点までの距離を算出し得る。基準地点は、第１のアバターまたは他アバターの居る地点に定められてもよいし、いずれのアバターも居ない地点に定められてもよい。距離算出部１１２は、距離データを条件判定部１１３へ送る。なお、後述される既定の条件が、仮想空間における２地点間の距離と無関係のものである場合には、距離算出部１１２は不要となり得る。

【0052】

条件判定部１１３は、前述のプロセッサにより実現され得る。条件判定部１１３は、データ取得部１１１から第１のアバターの音声データと、第１のアバターの制御データおよび／または位置データとを受け取り、さらに、距離算出部１１２から距離データを受け取り得る。条件判定部１１３は、第１のアバターの仮想空間における位置に関する既定の条件が満足するか否かを、第１のアバターの位置データおよび／または距離データに基づいて判定する。条件判定部１１３は、判定結果を示すデータとともに、第１のアバターの音声データ、位置データおよび／または制御データを送信制御部１１４へ送る。既定の条件は、ユーザの仮想的体験の毀損を防止しながら、同時に、共有対象となる音声データを間引くことを目的に定められ得る。

【0053】

具体的には、既定の条件は、（１）第１のアバターの仮想空間における位置（以降、第１の位置と称する）が既定のゾーン内にあること、（２）仮想空間に存在する第１のアバターを含む複数のアバター（仮想空間に存在する全アバターであってもよいし、そうでなくてもよい）の仮想空間における位置を仮想空間における既定の地点から近い順にソートした場合に、第１の位置が既定の順位以上となること、（３）宛先端末としての他の端末１００に関連付けられる他アバターの仮想空間における位置と第１の位置との間の距離が閾値未満で在ること、または（４）仮想空間に存在する第１のアバターを除く複数のアバター（仮想空間に存在する第１のアバターを除く全アバターであってもよいし、そうでなくてもよい）の仮想空間における位置と第１の位置との間の距離を昇順にソートした場合に、宛先端末としての他の端末１００に関連付けられる他アバターの仮想空間における位置と第１の位置との間の距離が既定の順位以上となること、を含み得る。ただし、既定の条件は、これら（１）〜（４）に限定されない。

【0054】

既定の条件（１）について、図３を用いて説明する。既定のゾーンは、仮想空間における既定の地点からの距離に基づいて定められてよい。ただし、既定のゾーンは、これに限らず例えばゾーン内外の境界の座標を指定するなどして任意に定義されてよい。図３および図４乃至図６は、仮想空間を見下ろした俯瞰図であり、丸数字のマークはアバターの（頭部の）位置を表しており、便宜的にその数字をアバターの符号としても用いることとする。また、図３において、既定のゾーンは、×印で表される既定の地点から半径○○メートル以内、と定められている。図３の例では、アバター１の位置は既定のゾーン内になく、アバター２の位置は既定のゾーン内にある。故に、アバター１に関連付けられるユーザの端末１００において、条件判定部１１３は既定の条件が満足しないと判定する。他方、アバター２に関連付けられるユーザの端末１００において、条件判定部１１３は既定の条件が満足すると判定する。なお、既定の条件（１）において、宛先端末の区別はなく、判定結果は全ての宛先端末との関係で適用される。すなわち、アバター１に関連付けられるユーザの端末１００はいずれの他の端末１００にも音声データを送信せず、アバター２に関連付けられるユーザの端末１００は全ての他の端末１００へ音声データを送信する。

【0055】

図３の例は、仮想空間において開催されるライブなどのイベントのように、各ユーザが特定のアバターの挙動に注目する場面に適している。図３の例によれば、既定のゾーンは仮想的なステージとみなすことができる。仮想ステージに登壇していないアバターの音声データは他の端末１００へ送信されないため、仮想ステージに登壇しているアバターの音声が他のアバターの音声に埋もれにくくなる。すなわち、各ユーザは目的のアバターのトークや歌声に集中することができ、同時にシステム全体での音声データのトラフィック量を抑制することができる。また、仮想ステージを視覚的にも表現するために、ＶＲ／ＭＲ／ＡＲ画像データにおいて、既定のゾーンに仮想ステージを表すオブジェクトが配置されてもよい。さらに、既定のゾーン外の場所に仮想観客席を表すオブジェクトが配置されてもよい。なお、既定のゾーンは仮想ステージと一致させる必要はなく、例えば仮想観客席の最前列を含むようにしてもよい。これにより、仮想ステージに加えて仮想観客席に居るアバターの一部によるリアクションの音声データも共有されるので、臨場感を演出することが可能となる。

【0056】

或いは、見方を変えれば、既定の地点は仮想マイクロホンの設置ポイントとみなすこともできる。仮想マイクロホンから遠くに居るアバターの音声データは他の端末１００へ送信されないため、仮想マイクロホンに近くに居るアバターの音声が他のアバターの音声に埋もれにくくなる。すなわち、各ユーザは目的のアバターのトークや歌声に集中することができ、同時にシステム全体での音声データのトラフィック量を抑制することができる。仮想マイクロホンを視覚的にも表現するために、ＶＲ／ＭＲ／ＡＲ画像データにおいて、既定のゾーンの基準位置となる既定の地点に仮想マイクロホンを表すオブジェクトが配置されてもよい。

【0057】

既定の条件（２）について、図４を用いて説明する。図４において、×印は既定の地点を表しており、当該地点とアバター１との距離はｄ_１０、当該地点とアバター２との距離はｄ_２０、当該地点とアバター３との距離はｄ_３０で表される。ｄ_２０＜ｄ_１０＜ｄ_３０であり、既定の順位が２位であったとする。かかる既定の条件の下では、アバター１およびアバター２に関連付けられるユーザの端末１００において、条件判定部１１３は既定の条件が満足すると判定する。他方、アバター３に関連付けられるユーザの端末１００において、条件判定部１１３は既定の条件が満足しないと判定する。なお、既定の条件（２）においても、宛先端末の区別はなく、判定結果は全ての宛先端末との関係で適用される。すなわち、アバター３に関連付けられるユーザの端末１００はいずれの他の端末１００にも音声データを送信せず、アバター１およびアバター２に関連付けられるユーザの端末１００は全ての他の端末１００へ音声データを送信する。

【0058】

図４の例でも、図３の例と同様に既定の地点は仮想マイクロホンの設置ポイントとみなすことができる。ただし、図４の例では、音声データの共有されるアバターの数は限られる。故に、仮想空間に存在するアバターの数の規模の増大に伴って音声データの共有されるアバターの数が増加し、ひいては音声データのトラフィック量が増大する、という事態を防ぐことができる。例えば、仮想空間に存在するアバターの数が５人であろうと５００人であろうと、音声データの共有されるアバターの数は２名に制限することができる。なお、既定の条件（２）は既定の条件（１）と組み合わせられてもよい。例えば、仮想空間に存在する第１のアバターを含む複数のアバターは、既定のゾーン内に居る者に限られてもよい。

【0059】

なお、既定の条件（２）について判定をするためには、第１のアバターの位置データに加えて複数のアバターの位置データを取得する必要がある。故に、位置データを伝送し合うことによるトラフィック量の増加は避けられない。しかしながら、位置データのサイズは一般的に音声データに比べて小さいし、位置データは常時送信する必要がない（例えば、変化が検知されたときに限って送信されてもよい）。故に、端末１００同士が位置データを送信し合うことによるトラフィック量の増分は限定的である。

【0060】

既定の条件（３）について、図５を用いて説明する。図５において、アバター１とアバター２の距離はｄ_２１、アバター１とアバター３との距離はｄ_３１で表される。ｄ_２１＜閾値＜ｄ_３１であったとする。かかる既定の条件の下では、アバター１に関連付けられるユーザの端末１００において、条件判定部１１３は、アバター２に関連付けられるユーザの端末１００との関係では既定の条件が満足すると判定し、アバター３に関連付けられるユーザの端末１００との関係では既定の条件が満足しないと判定する。このように、既定の条件（３）および（４）では、条件判定部１１３は、宛先端末毎に、既定の条件が満足するか否かを判定する。換言すれば、端末１００は、ある端末１００へは音声データを送信するが、別の端末１００へは音声データを送信しない可能性がある。

【0061】

図５の例は、仮想空間においてアバター同士の会話（音声チャット）を楽しむ場面に適している。すなわち、端末１００は、第１のアバターから遠くに居る他のアバターの音声データを受信しないため、第１のアバターに近くに居るアバターの音声が遠くに居るアバターの音声に埋もれにくくなる。すなわち、各ユーザは近くに居るアバターの話し声に集中することができ、同時にシステム全体での音声データのトラフィック量を抑制することができる。音声データの共有が可能なアバターを視覚的にも表現するために、ＶＲ／ＭＲ／ＡＲ画像データにおいて、音声データの共有ができる位置に居るか否かにより他のアバターの視覚的表現を異ならせてもよい。例えば、音声データの共有ができる位置に居ないアバターは通常よりも暗く描かれてもよいし、音声データの共有ができる位置に居るアバターには音声チャットが可能であることを示すアイコンが付加されてもよい。

【0062】

既定の条件（４）について、図６を用いて説明する。図６において、アバター１とアバター２の距離はｄ_２１、アバター１とアバター３との距離はｄ_３１、アバター１とアバター４との距離はｄ_４１で表される。ｄ_２１＜ｄ_３１＜ｄ_４１であり、既定の順位が２位であったとする。かかる既定の条件の下では、アバター１に関連付けられるユーザの端末１００において、条件判定部１１３は、アバター２およびアバター４に関連付けられるユーザの端末１００との関係では既定の条件が満足すると判定し、アバター３に関連付けられるユーザの端末１００との関係では既定の条件が満足しないと判定する。

【0063】

図６の例も、図５の例と同様に仮想空間においてアバター同士の会話（音声チャット）を楽しむ場面に適している。ただし、図６の例では、音声データの共有されるアバターの数は限られる。故に、仮想空間に存在するアバターの数の規模の増大に音声データの共有されるアバターの数が増加し、ひいては音声データのトラフィック量が増大する、という事態を防ぐことができる。例えば、仮想空間に存在するアバターの数が５人であろうと５００人であろうと、音声データの共有されるアバターの数は２名に制限することができる。なお、既定の条件（４）は既定の条件（３）と組み合わせられてもよい。例えば、あるアバターと第１のアバターとの間の距離が既定の順位以上であっても、閾値を超える場合には当該アバターに関連付けられるユーザの端末１００との関係で既定の条件が満足しないと判定されてよい。

【0064】

ところで、条件判定部１１３による判定を免れるためのオブジェクト、例えば仮想ヘッドセット、仮想ピンマイク、などが定義されてもよい。これらのオブジェクトは、ＶＲ／ＭＲ／ＡＲ画像データ上で視覚的に表現され、ユーザは例えばコントローラ２０を操作してアバターにこのオブジェクトを装着させることができる。なお、かかるオブジェクトの視覚的表現は、ヘッドセットまたはピンマイクに似せてもよいし、似せなくてもよい。また、かかるオブジェクトはどのアバターも装着可能としてもよいし、課金に応じるなどの何らかの既定の条件を満足したアバターに限って装着できるようにしてもよい。いずれにせよ、アバターがこのオブジェクトを装着している間は、当該アバターの音声データは当該アバターの位置に関わらず共有され得る。

【0065】

具体的には、条件判定部１１３は、まず第１のアバターが仮想空間における既定のオブジェクト（これは、上記仮想ヘッドセットまたは仮想ピンマイクに相当する）を装着しているか否かを判定する。ここで、第１のアバターによる既定のオブジェクトの装着／取り外しイベントは、例えばコントローラ２０からのユーザ入力データに基づいて検知され得る。条件判定部１１３は、第１のアバターが既定のオブジェクトを装着していると判定した場合には既定の条件が満足するか否かの判定を省略する。

【0066】

そして、後述される送信制御部１１４は、条件判定部１１３によって第１のアバターが既定のオブジェクトを装着していると判定された場合には、全ての宛先端末との関係で既定の条件が満足すると判定された場合と同様に動作する。すなわち、送信制御部１１４は、第１のアバターの音声データを全ての宛先端末へ向けて送信することを決定する。

【0067】

例えば、仮想空間において開催されるイベントの出演者のアバターがかかるオブジェクトを装着しておけば、当該アバターが仮想空間を広範に動き回ったとしても、各ユーザは当該アバターのトークや歌声を途切れることなく聞くことができる。また、前述の既定の条件（３）または（４）と組み合わせれば、例えば目的のアバターの音声が途切れることなく聞こえ、しかも付近のアバターのユーザと音声のやり取りが可能な、臨場感のある仮想的体験をユーザに提供することができる。

【0068】

同様に、条件判定部１１３による判定を免れることのできるアバターが定義されてもよい。すなわち、このアバターの音声データは、当該アバターの位置に関わらず共有されてよい。例えば、仮想空間のホストとなるユーザのアバターの音声データが、当該アバターの位置に関わらず共有されてよい。

【0069】

送信制御部１１４は、前述のプロセッサにより実現され得る。送信制御部１１４は、条件判定部１１３から第１のアバターの音声データと、第１のアバターの制御データおよび／または位置データとを、判定結果を示すデータとともに受け取る。送信制御部１１４は、判定結果に応じて、第１のアバターの少なくとも音声データを宛先端末へ向けて送信するか否かを決定する。送信制御部１１４は、宛先端末を示すデータ（例えば、アドレスデータ）と、当該宛先端末へ送るデータ（例えば、音声データ、位置データおよび／または制御データ）とを送信部１０３へ送る。

【0070】

具体的には、送信制御部１１４は、宛先端末との関係で既定の条件が満足すると判定された場合には、第１のアバターの音声データを当該宛先端末へ向けて送信することを決定する。ここで、前述の種々のメリットを目当てに、送信制御部１１４は、ピア・ツー・ピア型のネットワーク経由で音声データを宛先端末へ向けて送信することを決定してもよい。他方、送信制御部１１４は、宛先端末との関係で既定の条件が満足しないと判定された場合には、第１のアバターの音声データを当該宛先端末へ向けて送信しないことを決定する。

【0071】

なお、制御データおよび位置データのサイズは、一般的に音声データに比べて小さい。さらに、制御データおよび位置データのどちらも宛先端末へ向けて送信しなかったとすると、当該宛先端末に接続されたＨＭＤ１０に表示される第１のアバターは静止したままとなり、当該宛先端末のユーザの仮想的体験を損ねかねない。そこで、制御データおよび／または位置データは判定結果に関わらず全ての宛先端末へ向けて送信されてよい。

【0072】

すなわち、送信制御部１１４は、宛先端末との関係で既定の条件が満足すると判定された場合には、第１のアバターの音声データと、第１のアバターの制御データおよび／または位置データとを当該宛先端末へ向けて送信することを決定する。他方、送信制御部１１４は、宛先端末との関係で既定の条件が満足しないと判定された場合には、第１のアバターの音声データを当該宛先端末へ向けて送信せず第１のアバターの制御データおよび／または位置データを当該宛先端末へ向けて送信することを決定する。

【0073】

画像生成部１１５は、前述のプロセッサにより実現され得る。画像生成部１１５は、例えば端末１００のメモリまたは補助記憶装置に保存されているオブジェクト（アバターを含む）の画像データと、データ取得部１１１からの他アバターの制御データとに基づいて、ＶＲ／ＡＲ／ＭＲ画像データの生成（更新）を行う。ＶＲ／ＡＲ／ＭＲ画像データの生成には、制御データに対応する他アバターの姿勢の制御が含まれ得る。画像生成部１１５は、生成した画像データを出力部１０４経由でＨＭＤ１０へ送る。

【0074】

画像生成部１１５は、前述のように、制御データの示すＨＭＤ１０／コントローラ２０の位置に応じて他アバターの頭部／手の位置を決定し、例えばＩＫ（Ｉｎｖｅｒｓｅ Ｋｉｎｅｍａｔｉｃｓ）技術を利用してアバターの姿勢を制御してもよい。

【0075】

音声生成部１１６は、前述のプロセッサにより実現され得る。音声生成部１１６は、例えばデータ取得部１１１からの他アバターの音声データに基づいて、ＶＲ／ＡＲ／ＭＲ音声データの生成を行う。例えば、音声生成部１１６は、複数の他アバターの音声データを合成することで、音声データを生成してもよい。音声生成部１１６は、生成した音声データを出力部１０４経由でスピーカへ送る。

【0076】

なお、音声生成部１１６は、データ取得部１１１から他アバターの位置データをさらに取得してもよい。そして、音声生成部１１６は、音像定位技術を利用して、他アバターの位置から音声が生じているとユーザに知覚されるように、当該他アバターの音声データを加工してもよい。これにより、視覚的に知覚されるアバターの位置と聴覚的に知覚されるアバターの位置とをマッチさせて、臨場感を演出することが可能となる。

【0077】

以下、図７を用いて、端末１００の動作を説明する。図７の動作は、定期的に行われてもよいし、第１のアバターまたは他アバターの位置データに変化があったことが検知されたタイミングで行われてもよい。

【0078】

まず、データ取得部１１１は、第１のアバターの音声データおよび位置データを取得する（ステップＳ２０１）。次のステップＳ２０２において判定される既定の条件次第で、データ取得部１１１は、他アバターの位置データをさらに取得し得る。さらに、ステップＳ２０２へ進む前に、距離算出部１１２がステップＳ２０１において取得された位置データに基づいて、仮想空間における２地点間の距離を算出してもよい。

【0079】

次に、条件判定部１１３は第１のアバターの位置に関する既定の条件が満足するか否かを判定する（ステップＳ２０２）。少なくとも１つの宛先端末との関係で既定の条件が満足すると判定された場合には、処理はステップＳ２０３へ進む。他方、全ての宛先端末との関係で既定の条件が満足しないと判定された場合には、図７の動作は終了する。なお、ステップＳ２０２の判定結果に関わらず、送信制御部１１４は、第１のアバターの制御データおよび／または位置データを各宛先端末へ向けて送信すると決定してもよい。

【0080】

ステップＳ２０３において、送信制御部１１４は、既定の条件が満足すると判定された宛先端末へ向けて、ステップＳ２０１において取得された音声データを送信することを決定し、図７の動作は終了する。

【0081】

以上説明したように、実施形態に係る端末は、当該端末のユーザに関連付けられる第１のアバターの仮想空間における位置が既定の条件を満足するか否かを判定し、当該既定の条件が満足しないと判定された場合に第１のアバターの音声データを宛先端末へ向けて送信しない。故に、この端末によれば、既定の条件が満足しないと判定された場合には、当該端末から宛先端末への音声データのトラフィックが生じない。他方、この端末は、限られたアバターの音声データに限って受信することになるので、例えば、仮想マイクロホンまたは第１のアバターの近くに居るアバターの音声が他のアバターの音声に埋もれにくくなる。従って、この端末によれば、ユーザは目的のアバターのトークや音声、または近くに居るアバターの話し声に集中することができ、同時にシステム全体での音声データのトラフィック量を抑制することができる。

【0082】

（変形例１）
前述のように、図２のシステムではＰ２Ｐ型のネットワークが採用されているが、これに追加してＣ／Ｓ型のネットワークを採用したとしても、仮想的体験共有システムを構築することは可能である。この変形例１において、各端末１００は、Ｐ２Ｐ型のネットワークおよびＣ／Ｓ型のネットワークのどちらかを選択して、データを宛先端末へ向けて送信する。

【0083】

この変形例１によれば、図８に例示されるように、図２の仮想的体験共有システムにサーバ３００を追加することが可能である。サーバ３００は、送信元となる端末１００からデータを受信し、これを宛先となる端末１００へ送信する。

【0084】

この変形例１において、端末１００における送信制御部１１４は、宛先端末との関係で既定の条件が満足すると判定された場合には、Ｐ２Ｐ型のネットワーク経由で第１のアバターの音声データを当該宛先端末へ向けて送信することを決定する。他方、送信制御部１１４は、宛先端末との関係で既定の条件が満足しないと判定された場合には、Ｃ／Ｓ型のネットワーク経由で第１のアバターの音声データを当該宛先端末へ向けて送信することを決定してもよい。なお、第１のアバターの制御データおよび／または位置データは、第１のアバターの音声データと同じネットワーク経由で送信されてよい。

【0085】

このように送信制御部１１４がＰ２Ｐ型のネットワークまたはＣ／Ｓ型のネットワークを選択して第１のアバターの音声データを送信すれば、当該音声データに関してＰ２Ｐ型のネットワークの種々のメリット（例えば遅延低減）を享受することはできないものの、全てのユーザが全てのアバターの音声データを共有することが可能となる。すなわち、ユーザは、より多くのアバターの音声を同時に聞くことができるので、賑やかさ、盛り上がり、一体感などを感じやすくなる。

【0086】

以下、図９を用いて、変形例１に係る端末１００の動作を説明する。図９の動作は、定期的に行われてもよいし、第１のアバターまたは他アバターの位置データに変化があったことが検知されたタイミングで行われてもよい。

【0087】

まず、データ取得部１１１は、第１のアバターの音声データおよび位置データを取得する（ステップＳ４０１）。次のステップＳ４０２において判定される既定の条件次第で、データ取得部１１１は、他アバターの位置データをさらに取得し得る。さらに、ステップＳ４０２へ進む前に、距離算出部１１２がステップＳ４０１において取得された位置データに基づいて、仮想空間における２地点間の距離を算出してもよい。

【0088】

次に、条件判定部１１３は第１のアバターの位置に関する既定の条件が満足するか否かを判定する（ステップＳ４０２）。既定の条件が満足すると判定された場合には、処理はステップＳ４０３へ進む。他方、既定の条件が満足しないと判定された場合には、処理はステップＳ４０４へ進む。なお、前述の既定の条件（３）または（４）のように、宛先端末間で判定結果が異なり得る場合には、宛先端末毎にステップＳ４０２と、ステップＳ４０３またはステップＳ４０４とを繰り返せばよい。

【0089】

ステップＳ４０３において、送信制御部１１４は、既定の条件が満足すると判定された宛先端末へ向けて、Ｐ２Ｐ型のネットワーク経由で、ステップＳ４０１において取得された音声データを送信することを決定し、図９の動作は終了する。

【0090】

ステップＳ４０４において、送信制御部１１４は、既定の条件が満足しないと判定された宛先端末へ向けて、Ｃ／Ｓ型のネットワーク経由で、ステップＳ４０１において取得された音声データを送信することを決定し、図９の動作は終了する。

【0091】

（変形例２）
前述のように、図２のシステムではＰ２Ｐ型のネットワークが採用されているが、これに代えてＣ／Ｓ型のネットワークを採用したとしても、仮想的体験共有システムを構築することは可能である。さらに、この変形例２に係るサーバ５００は、送信元端末から宛先端末へのデータの中継に留まらず、第１の実施形態において説明した端末１００の機能の一部をも担う。

【0092】

具体的には、この変形例２において、端末は、前述の既定の条件判定および送信制御を行う必要はない。すなわち、端末は、アバターの音声データ、制御データおよび位置データをサーバ５００へ送信する。なお、後述するように、アバターの位置データ／制御データは、端末から受信したデータに基づいてサーバ５００において生成されてもよい。

【0093】

以下、サーバ５００のハードウェア構成について説明する。サーバ５００は、コンピュータであって、例えば、通信制御（特に、音声データの送信制御）、既定の条件判定、などを行うプロセッサを含む。

【0094】

また、サーバ５００は、かかる処理を実現するためにプロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータを一時的に格納するメモリを含んでいる。

【0095】

なお、サーバ５００は、全てのデータをオンメモリの状態で扱ってもよいし、一部のデータが補助記憶装置に退避されていてもよい。補助記憶装置は、例えば、サーバ５００に内蔵または外付けされたＨＤＤ、ＳＳＤ、フラッシュメモリなどであってもよいし、サーバ５００からアクセス可能なデータベースサーバであってもよい。

【0096】

サーバ５００は、さらに、ネットワークに接続するための通信Ｉ／Ｆを利用可能である。通信Ｉ／Ｆは、サーバ５００に内蔵されてもよいし、サーバ５００に外付けされてもよい。通信Ｉ／Ｆは、端末などと通信をするためのモジュールであって、送受信のための信号処理回路、アンテナ、ＬＡＮ端子などを含み得る。

【0097】

サーバ５００は、さらに、各要素、例えば、プロセッサ、メモリ、補助記憶装置、通信Ｉ／Ｆ、などの間でデータを転送するためのバスを含み得る。

【0098】

図１０には、サーバ５００の機能構成が例示される。サーバ５００は、受信部５０１と、送信部５０２と、データ取得部５１１と、距離算出部５１２と、条件判定部５１３と、送信制御部５１４とを含む。ただし、距離算出部５１２、条件判定部５１３および送信制御部５１４は、図１における同名の要素と同一または類似であってよく、それぞれ前述のプロセッサにより実現され得る。

【0099】

受信部５０１は、前述の通信Ｉ／Ｆにより実現され得る。受信部５０１は、ネットワーク経由で、送信元端末から、当該送信元端末のユーザに関連付けられるアバター（これは、第１の実施形態において説明した第１のアバターに相当する）の音声データ、位置データおよび制御データを受信し得る。受信部５０１は、受信したデータをデータ取得部５１１へ送る。

【0100】

送信部５０２は、前述の通信Ｉ／Ｆにより実現され得る。送信部５０２は、送信制御部５１４によって制御され、アバターの音声データ、位置データおよび／または制御データを宛先端末へ向けて送信する。

【0101】

データ取得部５１１は、前述のプロセッサにより実現され得る。データ取得部５１１は、受信部５０１から種々のデータを取得する。データ取得部５１１は、取得したデータを、距離算出部５１２および条件判定部５１３へ送る。

【0102】

具体的には、データ取得部５１１は、アバターの音声データ、位置データおよび制御データを取得し、位置データを距離算出部５１２および条件判定部５１３へ送り、音声データおよび制御データを条件判定部５１３へ送り得る。

【0103】

なお、端末が位置データ／制御データを送信する場合には、データ取得部５１１は受信部５０１から位置データ／制御データを直接取得することができる。他方、サーバ５００（の図示されない位置／姿勢推定部）が位置センサシステムの出力データに基づいてＨＭＤ１０／コントローラ２０の位置を推定して位置データ／制御データを生成する必要がある場合には、データ取得部５１１はこの位置／姿勢推定部へ位置センサシステムの出力データを送り、位置データ／制御データの生成を依頼してもよい。

【0104】

以上説明したように、変形例２に係るサーバは、第１の実施形態に係る端末と同様に、音声データの送信元端末のユーザに関連付けられる第１のアバターの仮想空間における位置が既定の条件を満足するか否かを判定し、当該既定の条件が満足しないと判定された場合に第１のアバターの音声データを宛先端末へ向けて送信しない。故に、このサーバによれば、第１の実施形態に係る端末と同様に、ユーザは目的のアバターのトークや音声、または近くに居るアバターの話し声に集中することができ、同時にシステム全体での音声データのトラフィック量を抑制することができる。なお、本変形例に係るサーバと第１の実施形態および変形例１に係る端末とを、「データ送信装置」と総称することも可能である。

【0105】

上述の実施形態は、本発明の概念の理解を助けるための具体例を示しているに過ぎず、本発明の範囲を限定することを意図されていない。実施形態は、本発明の要旨を逸脱しない範囲で、様々な構成要素の付加、削除または転換をすることができる。

【0106】

上述の実施形態では、いくつかの機能部を説明したが、これらは各機能部の実装の一例に過ぎない。例えば、１つの装置に実装されると説明された複数の機能部が複数の別々の装置に亘って実装されることもあり得るし、逆に複数の別々の装置に亘って実装されると説明された機能部が１つの装置に実装されることもあり得る。

【0107】

上記各実施形態において説明された種々の機能部は、回路を用いることで実現されてもよい。回路は、特定の機能を実現する専用回路であってもよいし、プロセッサのような汎用回路であってもよい。

【0108】

上記各実施形態の処理の少なくとも一部は、例えば汎用のコンピュータに搭載されたプロセッサを基本ハードウェアとして用いることでも実現可能である。上記処理を実現するプログラムは、コンピュータで読み取り可能な記録媒体に格納して提供されてもよい。プログラムは、インストール可能な形式のファイルまたは実行可能な形式のファイルとして記録媒体に記憶される。記録媒体としては、磁気ディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ等）、光磁気ディスク（ＭＯ等）、半導体メモリなどである。記録媒体は、プログラムを記憶でき、かつ、コンピュータが読み取り可能であれば、何れであってもよい。また、上記処理を実現するプログラムを、インターネットなどのネットワークに接続されたコンピュータ（サーバ）上に格納し、ネットワーク経由でコンピュータ（クライアント）にダウンロードさせてもよい。

【符号の説明】

【0109】

１０・・・ＨＭＤ
２０・・・コントローラ
１００・・・端末
１０１・・・入力部
１０２，５０１・・・受信部
１０３，５０２・・・送信部
１０４・・・出力部
１１１，５１１・・・データ取得部
１１２，５１２・・・距離算出部
１１３，５１３・・・条件判定部
１１４，５１４・・・送信制御部
１１５・・・画像生成部
１１６・・・音声生成部
３００，５００・・・サーバ

【要約】      （修正有）

【課題】複数のユーザ間で仮想的体験を共有する場合に、音声データのトラフィック量を抑制し、またはユーザの仮想的体験の毀損を防止する。
【解決手段】データ送信装置１００は、データ取得部と、条件判定部と、送信制御部とを含む。データ取得部は、第１のアバターの仮想空間における第１の位置を示す第１の位置データと、第１のアバターの音声データとを取得する。条件判定部は、第１の位置に関する既定の条件が満足するか否かを判定する。送信制御部は、既定の条件が満足すると判定された場合に音声データを宛先端末へ向けて送信することを決定し、既定の条件が満足しないと判定された場合に音声データを宛先端末へ向けて送信しないことを決定する。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】