WO2020213098A1 - 映像表示装置及びその表示制御方法 - Google Patents

Abstract

他の人とアバターを介して空間を共有する際の違和感を低減する映像表示装置及びその表示制御方法を提供することを目的とする。それを達成するために、配信されるコンテンツの映像と、コンピュータ生成画像であるアバターとを重畳して表示画面に表示する映像表示装置であって、ネットワークと接続する通信処理部と、通信処理部を介して受信したアバター情報から他者のアバターを生成するアバター生成処理部と、通信処理部を介して受信したコンテンツの映像に付随する連続する動作の動き情報を検出する動き情報検出処理部と、通信処理部を介して受信したコンテンツを表示する表示部と、制御部を有し、アバター生成処理部は、生成したアバターの動作に動き情報検出処理部で検出した動き情報を加味してアバターを生成し、制御部は、表示部にコンテンツに重畳してアバター生成処理部で生成したアバターを表示する構成とする。

Description

映像表示装置及びその表示制御方法

　本発明は、映像表示装置及びその表示制御方法に関する。

　近年、ＰＣをはじめとする情報端末には種々の製品が世の中に出回っている。中でも、携帯型映像表示装置のヘッドマウントディスプレイ装置（以下「ＨＭＤ」と記載する。）では、眼鏡形式の表示画面上に、配信された映像と、コンピュータによる拡張現実（ＡＲ：Augmented Reality）の生成画像（アバター）とを重畳させて表示することができる。例えば、コンサートやスポーツなどのコンテンツを他のユーザと同時にリアルタイムに鑑賞でき、それと同時に、自分の分身（アバター）や、他のユーザの分身（アバター）を、表示画面に表示することができるヘッドマウントディスプレイ用のアプリケーションが既に提供されている。

　本技術分野における従来技術として特許文献１がある。特許文献１では、アバター表示において、遠隔の意思疎通における遅延の影響を回避する方法が記載されている。

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

　例えば、他のユーザと一緒にコンサート等のライブ映像を楽しむ場合、他のユーザの分身であるアバターの動作が重要になってくる。特に、音楽ライブ等で、聴いている音楽と外れたリズムのまま体を動かし続けるアバターには、非常に違和感を覚える。

　これに対して、特許文献１では、初動の遅延に対する違和感は改善されるが、連続する動作のずれによる違和感に対しては考慮されていなかった。

　本発明の目的は、他の人とアバターを介して空間を共有する際の違和感を低減する映像表示装置及びその表示制御方法を提供することである。

　本発明は、上記課題を解決するために、その一例を挙げるならば、配信されるコンテンツの映像と、コンピュータ生成画像であるアバターとを重畳して表示画面に表示する映像表示装置であって、ネットワークと接続する通信処理部と、通信処理部を介して受信したアバター情報から他者のアバターを生成するアバター生成処理部と、通信処理部を介して受信したコンテンツの映像に付随する連続する動作の動き情報を検出する動き情報検出処理部と、通信処理部を介して受信したコンテンツを表示する表示部と、制御部を有し、アバター生成処理部は、生成したアバターの動作に動き情報検出処理部で検出した動き情報を加味してアバターを生成し、制御部は、表示部にコンテンツに重畳してアバター生成処理部で生成したアバターを表示する構成とする。

　本発明によれば、アバターを介して空間を共有する際の違和感を低減する映像表示装置及びその表示制御方法を提供することができる。

実施例１における映像表示システムの構成模式図である。 実施例１におけるライブコンサート視聴の模式図である。 実施例１におけるＨＭＤのハードウェア構成図である。 実施例１におけるＨＭＤの機能ブロック構成図である。 実施例１におけるＨＭＤの全体の処理フローチャートである。 実施例１におけるＨＭＤの準備処理のフローチャートである。 実施例１におけるＨＭＤのライブコンテンツ処理のフローチャートである。 実施例１におけるＨＭＤのアバター表示処理のフローチャートである。 実施例１におけるＨＭＤのアバターの表示可否を判断するフローチャートである。 実施例２におけるＨＭＤの機能ブロック構成図である。 実施例３におけるアバター表示処理のフローチャートである。 実施例４における管理サーバの処理手順を示すフローチャートである。 実施例５における映像表示システムの構成模式図である。 実施例６におけるスマートフォンの外観図である。 実施例７における自己動作反映処理のフローチャートである。 実施例８におけるライブラリテーブルである。

　以下、本発明の実施例を、図面を用いて説明する。

　図１は、本実施例における映像表示システムの構成模式図である。なお、本発明は、複数のユーザが存在する場合に適用するが、説明を簡単にするため、本実施例では、図１に示すように、二人のユーザ（第１のユーザ１０Ａと、第２のユーザ１０Ｂ）に限定して説明する。

　図１において、映像表示装置であるＨＭＤ１１Ａを装着した第１のユーザ１０Ａと、ＨＭＤ１１Ｂを装着した第２のユーザ１０Ｂは、それぞれ無線ルータ１２Ａと無線ルータ１２Ｂを介して、ネットワーク網１３に接続している。ネットワーク網１３には、配信サーバ１４と、管理サーバ１５が接続されている。

　配信サーバ１４は、ライブコンテンツをライブストリーミング（live streaming）で、ネットワーク網１３上に、ライブ配信する。配信サーバ１４から配信されたライブストリーミングのライブコンテンツは、ネットワーク網１３を介して、無線ルータ１２Ａ経由でＨＭＤ１１Ａと、無線ルータ１２Ｂ経由でＨＭＤ１１Ｂに、それぞれ配信される。配信されたライブコンテンツは、映像はＨＭＤの表示画面に表示し、音声はＨＭＤのスピーカから出力する。

　管理サーバ１５は、ネットワーク網１３を介して取得した、複数の情報を管理する。管理サーバ１５が管理する情報は、例えば、コンテンツの情報や、ユーザに関する情報、無線ルータ１２Ａを介して取得したＨＭＤ１１Ａの動作情報（第１のユーザ１０Ａの動作情報）や音声情報、無線ルータ１２Ｂを介して取得したＨＭＤ１１Ｂの動作情報（第２のユーザ１０Ｂの動作情報）や音声情報、などである。

　コンテンツの情報には、ライブのタイトル情報、演奏者や歌手などのアーティスト情報、ライブコンテンツの開始時刻及び終了時刻などの時間情報、楽曲の拍子やテンポなどの楽譜情報などがある。

　ユーザに関する情報には、氏名を含むニックネームやハンドルネームなどのユーザ情報（ユーザ識別情報）、ユーザ固有のアバター情報、ライブコンテンツを同時に視聴する複数ユーザを管理する管理情報、などがある。

　動作情報は、手を叩く、首や手を振る、手を上下する、立つ、座る、ステップ、ジャンプ、などの動作を、アバターの各関節等を動かすベクトル情報として保持している。

　このようなシステム構成により、ユーザは、ライブコンテンツを視聴しながら、視聴するユーザとは異なる他者の分身でありコンピュータ生成画像であるアバターを、他者の動作情報を付加して、ライブコンテンツに重畳して表示することができ、アバターを介して友人との楽しい状況を共有することができる。

　図２は、第１のユーザ１０Ａが、ライブコンサートを視聴している状態を説明するための模式図である。図２において、配信サーバ１４は、アーティストが演じているライブコンサート全体の映像２１を配信している。

　ライブコンサート全体の映像２１は、例えば、複数台のカメラで撮影した映像を合成することや、３６０度カメラで撮影することなどで実現することができる。

　このライブコンサート全体の映像２１が配信されることにより、第１のユーザ１０Ａが装着するＨＭＤ１１Ａの向いている方向の変化に応じたライブコンサートの映像を、ＨＭＤ１１Ａの表示画面上に表示することができる。例えば、ＨＭＤ１１Ａの向きを、後ろ向きに転じると、観客席の映像が表示される。

　第１のユーザ１０Ａが装着するＨＭＤ１１Ａの表示画面２２には、配信されたライブ会場全体の映像２１から、ＨＭＤ１１Ａの向いている方向に応じて切り出した映像が表示されている。また、その視聴位置は、ライブ会場全体の映像２１の中心の最も良い視聴位置と思われるライブ会場の中央位置２３で視聴している状態を想定している。勿論、第２のユーザ１０Ｂが装着するＨＭＤ１１Ｂの表示画面には、ライブ会場全体の映像２１の中心の最も良い視聴位置と思われるライブ会場の中央位置２３で視聴している状態を想定している。

　本実施例で表示する第２のユーザ１０Ｂの分身であるアバター２４は、管理サーバ１５に格納されている第２のユーザ１０Ｂのユーザ固有のアバター情報を用いている。

　第２のユーザ１０Ｂの分身であるアバター２４の表示位置は、任意で良いが、本実施例では、第１のユーザ１０Ａと第２のユーザ１０Ｂの相対位置を維持している。例えば、第１のユーザ１０Ａの右隣に第２のユーザ１０Ｂが存在し、第２のユーザ１０Ｂの左隣に第１のユーザ１０Ａが存在している状態を、第１のユーザ１０Ａと第２のユーザ１０Ｂが、相互に認識していることを意味している。本実施例における図２の模式図では、第２のユーザ１０Ｂの分身であるアバター２４は、第１のユーザ１０Ａの視聴位置の右側に存在するように設定している。なお、第３のユーザが存在した場合も同様に、３者のユーザの相対位置は維持される。

　また、後ろを含む他の観客席には、一般的な任意のアバターを配置することもできるが、ネットワーク等を介して、外部のサーバから入手した多種のアバターを配置することもできる。

　ＨＭＤ１１Ａは、ライブコンサートで演奏される音楽のリズムを検出し、そのリズムに同期して第２のユーザ１０Ｂの分身であるアバター２４を動かす。さらに、管理サーバ１５から入手した第２のユーザ１０Ｂの動作情報を、第２のユーザ１０Ｂの分身であるアバター２４に反映させている。

　次に、本実施例における頭部装着型映像表示装置であるＨＭＤを、図面を用いて説明する。図３は、本実施例におけるＨＭＤの内部構成の一例を示すハードウェア構成図である。図３において、ＨＭＤ１は、主制御装置２、システムバス３、記憶装置４、センサ装置５、通信処理装置６、映像処理装置７、音声処理装置８、操作入力装置９で構成される。

　主制御装置２は、所定の動作プログラムに従ってＨＭＤ１全体を制御するマイクロプロセッサユニットである。システムバス３は、主制御装置２とＨＭＤ１内の各構成ブロックとの間で各種コマンドやデータなどの送受信を行うためのデータ通信路である。

　記憶装置４は、ＨＭＤ１の動作を制御するためのプログラムなどを記憶するプログラム部４１、動作設定値や後述するセンサ部からの検出値やコンテンツを含むオブジェクトなどの各種データを記憶する各種データ部４２、各種プログラム動作で使用するワークエリアなどの書き替え可能なプログラム機能部４３から構成している。また、記憶装置４は、ネットワーク上からダウンロードした動作プログラムや前記動作プログラムで作成した各種データ等を記憶可能である。また、ネットワーク上からダウンロードした動画や静止画や音声等のコンテンツを記憶可能である。また、カメラ機能を使用して撮影した動画や静止画等のデータを記憶可能である。また、記憶装置４は、ＨＭＤ１に外部から電源が供給されていない状態であっても記憶している情報を保持する必要がある。したがって、例えば、フラッシュＲＯＭやＳＳＤ（Solid State Drive）などの半導体素子メモリ、ＨＤＤ（Hard Disc Drive）などの磁気ディスクドライブ等のデバイスが用いられる。なお、記憶装置４に記憶された前記各動作プログラムは、ネットワーク上の各サーバ装置からのダウンロード処理により更新及び機能拡張することが可能である。

　センサ装置５は、ＨＭＤ１の状態を検出するための各種センサのセンサ群である。センサ装置５は、ＧＰＳ（Global Positioning System）受信部５１、地磁気センサ部５２、距離センサ部５３、加速度センサ部５４、ジャイロセンサ部５５で構成される。これらのセンサ群により、ＨＭＤ１の位置、傾き、方角、動き等を検出することが可能となる。また、ＨＭＤ１が、照度センサ、近接センサ等、他のセンサを更に備えていても良い。更に、手や腕に、それらのセンサと対をなす装置を装着すれば、手や腕の動きを検出することができる。これらのセンサ群を総合的に活用することにより、手を叩く、首や手を振る、手を上下する、立つ、座る、ステップ、ジャンプ、などの動作を検出することができる。

　通信処理装置６は、ＬＡＮ（Local Area Network）通信部６１、電話網通信部６２、で構成される。ＬＡＮ通信部６１は、アクセスポイント等を介してインターネット等のネットワークと接続され、前記ネットワーク上の各サーバ装置とデータの送受信を行う。アクセスポイント等との接続はＷｉ－Ｆｉ（登録商標）等の無線接続で行われて良い。電話網通信部６２は、移動体電話通信網の基地局等との無線通信により、電話通信（通話）及びデータの送受信を行う。基地局等との通信はＷ－ＣＤＭＡ（Wideband Code Division Multiple Access）（登録商標）方式やＧＳＭ（登録商標）（Global System for Mobile communications）方式、ＬＴＥ（Long Term Evolution）方式、或いはその他の通信方式によって行われて良い。ＬＡＮ通信部６１と電話網通信部６２は、それぞれ符号化回路や復号化回路やアンテナ等を備える。また、通信処理装置６が、ＢｌｕｅＴｏｏｔｈ（登録商標）通信部や赤外線通信部等、他の通信部を更に備えていても良い。

　映像処理装置７は、撮像部７１、表示部７２で構成される。撮像部７１は、ＣＣＤ（Charge Coupled Device）やＣＭＯＳ（Complementary Metal Oxide Semiconductor）センサ等の電子デバイスを用いてレンズから入力した光を電気信号に変換することにより、周囲や対象物の画像データを入力するカメラユニットである。表示部７２は、例えば液晶パネル等の表示デバイスであり、画像データをＨＭＤ１のユーザに提供する。表示部７２は図示を省略したビデオＲＡＭを備える。そして、ビデオＲＡＭに入力された画像データに基づいて表示画面上に表示される。

　音声処理装置８は、音声入出力部８１、音声認識部８２、音声復号部８３とで構成される。音声入出力部８１の音声入力はマイクであり、ユーザの声などを音声データに変換して入力する。また、音声入出力部８１の音声出力はスピーカであり、ユーザに必要な音声情報等を出力する。音声認識部８２は、入力された音声情報を解析し、指示コマンド等を抽出する。音声復号部８３は、必要に応じて、符号化音声信号の復号処理（音声合成処理）等を行う機能を有する。

　操作入力装置９は、ＨＭＤ１に対する操作指示の入力を行う指示入力部である。操作入力装置９は、ボタンスイッチ等を並べた操作キー、等で構成される。その他の操作デバイスを更に備えても良い。また、通信処理装置６を利用し、有線通信または無線通信により接続された別体の携帯端末機器を用いてＨＭＤ１の操作を行っても良い。また、音声処理装置８の音声認識部８２を利用して、操作指示の音声コマンドによりＨＭＤ１の操作を行なっても良い。

　なお、図３に示したＨＭＤ１の構成例は、本実施例に必須ではない構成も多数含んでいるが、これらが備えられていない構成であっても本実施例の効果を損なうことはない。また、デジタル放送受信機能や電子マネー決済機能等、図示していない構成が更に加えられていても良い。

　図４は、本実施例におけるＨＭＤ１の機能ブロック構成図である。図４において、制御部３０は、主に、図３における主制御装置２と記憶装置４のプログラム部４１及びプログラム機能部４３で実行される。

　各種センサ情報取得部３１は、センサ装置５の各種センサからの情報を取得する機能であり、自己の動作状態を把握する機能である。

　通信処理部３２は、主に、図３における通信処理装置６のＬＡＮ通信部６１で実行され、ＨＭＤ１の各種情報を、管理サーバ１５へアップロードしたり、管理サーバ１５からの各種情報をダウンロードしたりする機能である。また通信処理部３２は、配信サーバ１４からのライブコンテンツをダウンロードする機能である。

　他者動作情報保存部３３は、管理サーバ１５が取得したＨＭＤ１を視聴するユーザとは異なる他のユーザの動作情報及び音声情報を、通信処理部３２により入手し、記憶装置４の各種データ部４２に保存する機能である。

　アバター情報保存部３４は、管理サーバ１５が管理している他のユーザ固有のアバター情報を、通信処理部３２により入手し、記憶装置４の各種データ部４２に保存する機能である。

　アバター生成処理部３５は、主に、図３における主制御装置２で実行され、アバター情報保存部３４により保存されたアバターに、他者動作情報保存部３３により保存された他者の動作情報を加味して、アバターを生成する機能である。

　アバター表示処理部３６は、図３における映像処理装置７の表示部７２により実行され、アバター生成処理部３５で生成されたアバターを表示する機能である。但し、後ほど説明するが、ＨＭＤ１の位置や方向により、ＨＭＤ１の表示画面上からアバターが逸脱する場合があるので、アバターの表示可否を判断する必要がある。

　リズム検出処理部３７は、主に、図３における主制御装置２と音声処理装置８で実行され、ライブコンテンツにおける楽曲のリズム（拍子）を検出する機能である。管理サーバ１５で管理しているコンテンツ情報（楽譜情報）があれば、通信処理部３２により管理サーバ１５から入手し、リズム（拍子）情報として利用する。番組表などにより、演奏される楽曲が判明している場合は、インターネット等により、その楽曲に関するリズムやテンポなどの楽譜情報を入手することもできる。

　管理サーバ１５、もしくはインターネット等から楽譜情報が入手できなかった場合は、配信サーバ１４からのライブコンテンツを再生しながら、音の強弱の繰り返しパターンにより、リズム（拍子）を検出する。

　次に、制御部３０により実行される本実施例におけるＨＭＤ１での全体の処理フローチャートを図５に示す。図５において、ＨＭＤ１における処理は、起動開始（Ｓ１００）後、準備処理Ｓ２００を行なう。準備処理Ｓ２００は、ライブコンテンツを受信する前に、行なう処理であり、一緒にライブコンテンツを視聴するユーザの設定などを行なう。

　準備処理Ｓ２００が終了した後、ライブコンテンツの開始を待つ。そして、ライブコンテンツの受信動作（ライブコンテンツ処理Ｓ３００）と同時に、アバター表示処理Ｓ４００を行なう。

　ライブコンテンツ処理Ｓ３００では、送られてきたコンテンツを表示するとともに、リズム同期に関する情報をアバター表示処理Ｓ４００に伝達し、リズムに同期したリズム動作情報を生成し、アバターにリズムに合わせた動作をさせる。

　アバター表示処理Ｓ４００では、他者の動作があった場合は、他者動作情報として、アバター表示処理Ｓ４００に入力され、アバター表示に反映させる。

　ライブコンテンツが終了すると、ライブコンテンツ処理Ｓ３００と、アバター表示処理Ｓ４００が終了し、全体の処理を終了する（Ｓ５００）。

　図６は、図５の全体の処理フローチャートにおける準備処理Ｓ２００のフローチャートである。図６において、準備処理Ｓ２００が開始（Ｓ２１０）されると、先ず、ライブコンテンツを検索し設定する（Ｓ２１１）。ライブコンテンツは、管理サーバ１５が既に管理しているライブコンテンツ、もしくは、配信サーバ１４が提供する番組表などから選択し、設定する。

　次にステップＳ２１２で、設定したライブコンテンツの情報を、管理サーバ１５や配信サーバ１４もしくはネットワーク網１３を介して他のサーバなどから入手し、記憶装置４の各種データ部４２に保存する。なお、入手したライブコンテンツの情報は、単独で視聴する場合でも有効に活用できる。そして、ステップＳ２１３で、管理サーバ１５から、管理サーバ１５に登録されているユーザリスト（他者リスト）を入手する。

　そして、ステップＳ２１４で、入手したユーザリスト（他者リスト）の中に、一緒に視聴したいユーザが存在するかどうかを判断する。Ｓ２１４で、一緒に視聴したいユーザが存在した場合は、一緒に視聴したいユーザ（他者）に対して、設定したライブコンテンツを開示して、一緒に視聴するかどうかの承認伺いを行なう（Ｓ２１５）。

　そして、ステップＳ２１６で、一緒に視聴したいユーザ（他者）から承認が得られたかどうかを判断する。Ｓ２１６で、一緒に視聴したいユーザ（他者）から承認が得られなかった場合は、Ｓ２１４の処理に戻り、他の選択すべきユーザを検索する。

　Ｓ２１６の処理で、一緒に視聴したいユーザ（他者）から承認が得られた場合は、管理サーバ１５に、一緒に視聴するユーザとして、一緒に視聴したいユーザ（他者）を登録する（Ｓ２１７）。そして、ステップＳ２１８で、管理サーバ１５から、一緒に視聴したいユーザの固有アバターデータ（友達アバター）を入手し、記憶装置４の各種データ部４２に保存し、Ｓ２１４の処理に戻る。

　Ｓ２１４で、入手したユーザリストの中に、一緒に視聴したいユーザが存在しなかった場合は、準備処理Ｓ２００を終了する（Ｓ２１９）。

　図７は、図５の全体の処理フローチャートにおけるライブコンテンツ処理Ｓ３００のフローチャートである。図７において、ライブコンテンツ処理Ｓ３００が開始（Ｓ３１０）されると、ライブコンテンツの開始を待ち、ライブコンテンツを受信する（Ｓ３１１）。続いて、受信したライブコンテンツを再生する（Ｓ３１２）。

　そして、ステップＳ３１３で、ライブコンテンツを再生しながら、そのライブコンテンツのリズムを検出する。なお、管理サーバ１５のコンテンツ情報に楽譜データがあれば、拍子とテンポ（拍の長さ）が分かるので、特にリズム検出処理は行なわない。

　リズム検出は、通常、１個の強拍と１個以上の弱拍とからなるパターン（リズム区間）を、繰り返すことにより認識する。従って、リズムを認識するには、最低２個のリズム区間を必要とする。リズム検出の具体例としては、例えば、サウンドデータを適切なフレーム長ごとに分割し、フレーム内での音量を計算し、フレーム間の音量増加量を計算する。そして、音量増加量を周波数解析して、ピーク周波数をbpm(Beats Per Minute)に変換することで、リズムを検出する。

　次に、ステップＳ３１４で、ライブコンテンツの楽曲がリズム区間の先頭に到達したかどうかを判断する。そして、ライブコンテンツの楽曲がリズム区間の先頭に到達するまでＳ３１４の処理を繰り返す。

　次に、ステップＳ３１５で、ライブコンテンツの楽曲がリズム区間の先頭に到達したら、リズム区間先頭タイミングをアバター表示処理に通知する。

　次に、ステップＳ３１６で、ライブコンテンツの楽曲がリズム区間の終端に到達したかどうかを判断する。そして、ライブコンテンツの楽曲がリズム区間の終端に到達するまで、Ｓ３１６の処理を繰り返す。

　次に、ステップＳ３１７で、ライブコンテンツの楽曲がリズム区間の終端に到達したら、ライブコンテンツの楽曲が、終了したかどうかを判断する。Ｓ３１７で、ライブコンテンツの楽曲が終了していない場合は、リズム区間の終端は、次のリズム区間の先頭と同一タイミングなので、Ｓ３１５の処理に戻る。

　Ｓ３１７の処理で、ライブコンテンツの楽曲が終了した場合は、ライブコンテンツの楽曲が終了したことを、アバター表示処理に通知し（Ｓ３１８）、ライブコンテンツ処理Ｓ３００を終了する（Ｓ３１９）。

　図８は、図５の全体の処理フローチャートにおけるアバター表示処理Ｓ４００のフローチャートである。図８において、アバター表示処理Ｓ４００が開始（Ｓ４１０）されると、先ず、管理サーバ１５から、一緒にライブコンテンツを視聴する選択したユーザの固有アバターデータ（友達アバター）を入手し、所定の位置に表示する（Ｓ４１１）。

　友達アバターは、選択したユーザの固有のアバターであり、身長や体形などの、その選択したユーザを彷彿させるイメージを有するアバターである。友達アバターは、ユーザ（もしくはユーザ以外の他人）が管理サーバ１５に登録したユーザ固有のアバターである。勿論、選択したユーザの固有のアバターデータを使用せずに、一般的な特徴の無い汎用のアバターを使用することもできることは言うまでも無い。友達アバターは、選択したユーザのＨＭＤの各種センサの情報から、例えば、座った状態や立った状態などの静止状態や、動きの動作情報を入手し、動作情報を生成して動作させる。

　次に、ステップＳ４１２で、リズム区間の先頭タイミングかどうかを判断する。具体的には、ライブコンテンツ処理Ｓ３００におけるＳ３１５の処理からのリズム区間先頭タイミングを待つ。リズム区間の先頭タイミングに到達するまで、Ｓ４１２の処理を繰り返す。

　次に、ステップＳ４１３で、１個前のリズム区間（直前のリズム区間）経過中に、管理サーバ１５から、一緒にライブコンテンツを視聴する選択したユーザの連続した動作情報及び音声情報が有ったかどうかを判断する。そして、連続した動作情報及び音声情報が無かった場合は、後ほど説明するＳ４１８の処理に移行する。また、連続動作情報が有った場合は、ステップＳ４１４でアバターの動作にリズム動作情報を加味する。また、音声情報が有った場合は、音声情報の出力を開始し、その音声情報がなくなるまで音声出力を継続する。

　次に、ステップＳ４１５で、連続した動作情報の有無で動作アバターの表示の終了を判断する。動作アバターの表示が終了するまで、Ｓ４１４の処理を繰り返す。そして、Ｓ４１５の処理で動作アバターの表示が終了した場合は、友達アバターのリズム動作を停止する（Ｓ４１６）。

　次に、リズム区間が終端に到達したかどうかを判断する（Ｓ４１７）。リズム区間が終端に到達していなければ、Ｓ４１５の処理に戻る。Ｓ４１７の処理で、リズム区間が終端に到達した場合は、楽曲が終了したかどうかを判断する（Ｓ４１８）。具体的には、ライブコンテンツ処理Ｓ３００におけるＳ３１８の処理からの楽曲終了通知があるかどうかで判断する。

　Ｓ４１８の処理で、楽曲が終了していない場合は、リズム区間の終端は次のリズム区間の先頭と同一タイミングなので、Ｓ４１３の処理に戻る。Ｓ４１８の処理で、楽曲が終了した場合は、アバターのリズム動作処理を終了する（Ｓ４１９）。

　ここで、図８のアバター表示処理Ｓ４１１の詳細フローチャートを図９に示す。図９は、アバターが表示範囲に入っているか否かを判断してその表示を制御する処理である。

　図９において、処理が開始（Ｓ４２０）されると、表示すべきアバターの位置を確認する（Ｓ４２１）。次に、ＨＭＤ１の位置・方向が、前回と同じかどうかを判断する（Ｓ４２２）。

　Ｓ４２２の処理で、ＨＭＤ１の位置・方向が、変化したと判断した場合は、変化後のＨＭＤ１の位置や方向を検出する（Ｓ４２３）。初期では、前回のＨＭＤ１の位置や方向に関する情報が無いので、ＨＭＤ１の位置や方向が、変化したと判断する。

　次に、変化後のＨＭＤ１の位置や方向におけるＨＭＤ１の表示画面上に、Ｓ４２１の処理で確定したアバターの位置で、アバターが完全に逸脱しているかどうかを判断する（Ｓ４２４）。Ｓ４２４の処理で、アバターが完全に逸脱している場合は、アバターを表示しない（Ｓ４２５）。その後、このアバター表示可否ルーチンを終了する（Ｓ４２９）。

　Ｓ４２４の処理で、アバターが完全に逸脱していない場合、アバターの一部が逸脱したかどうか判断する（Ｓ４２６）。Ｓ４２６で、アバターが少しも逸脱していない場合は、完全なアバターを表示する（Ｓ４２７）。その後、このアバター表示可否ルーチンを終了する（Ｓ４２９）。

　Ｓ４２６の処理で、アバターが一部逸脱している場合は、ＨＭＤ１の表示画面上に逸脱していない残りのアバターを表示する（Ｓ４２８）。その後、このアバター表示可否ルーチンを終了する（Ｓ４２９）。

　このような手順で、アバターの表示可否を判断して実行する。アバターの表示可否は、アバターを表示する度に、実行されることが望ましい。

　以上のように、本実施例は、視聴する音楽のリズムを検出し、表示される他のユーザの分身であるアバターの動作を、その検出したリズムと同期した動作で表示させる。これにより、他のユーザの分身であるアバターの動作がリズムと同期した動作となるので、音楽ライブ等で、臨場感溢れる視聴効果をもたらすことができる。

　なお、本実施例は、楽曲のリズムについて説明したが、これに限定されるものでなく、スポーツ観戦、舞台観戦などに対する反応である、応援、歓声、掛け声等の動作や、映像と一緒に行なう合奏や合唱などの動作を含む、連続する動作でよい。その場合、リズム検出処理部３７は、動き情報検出処理部と置き換えればよい。これにより、本実施例によれば、連続する動作に同期した動作でアバターを表示させることで、空間を共有する際のアバターを介した違和感を低減することが可能となる。

　実施例１では、一緒に視聴している他のユーザのアバターを表示しているが、視聴している自己のアバターを表示していなかった。本実施例では、一緒に視聴している他のユーザのアバターを表示するだけでなく、視聴している自己のアバターも表示する例について説明する。

　図１０は、本実施例におけるＨＭＤ１の機能ブロック図である。図１０において、図４と同様の機能は同じ符号を付し、その説明は省略する。図１０において図４と異なる構成は、自己動作情報保存部３８が追加されている点である。

　図１０において、各種センサ情報取得部３１は、センサ装置５の各種センサからの情報を取得し、自己の動作状態を把握する。

　自己のリズムに関する動作情報は、各種センサ情報取得部３１により入手した自己のリズムに関する動作情報を、自己動作情報保存部３８により記憶装置４の各種データ部４２に保存する。

　自己の分身であるアバター情報は、予め、自己で作成済みで、アバター情報保存部３４により記憶装置４の各種データ部４２に保存している。勿論、この自己アバターの情報は、管理サーバ１５に登録済みであることは、言うまでも無い。

　自己のアバターは、アバター情報保存部３４により保存している自己のアバターに、自己動作情報保存部３８からの自己の動作情報を加味して、アバター生成処理部３５によりアバターを生成し、アバター表示処理部３６により自己のアバターを表示する。

　このようにして、図２のライブコンサート視聴の模式図におけるライブ会場全体の映像２１の中心の最も良い視聴位置と思われるライブ会場の中央位置２３に、自己のアバターを表示することができる。

　実施例１では、１個前のリズム区間（直前のリズム区間）経過中に、管理サーバ１５から、一緒にライブコンテンツを視聴するユーザの連続動作情報が有った場合、アバターをリズム動作させていた。これに対して、本実施例では、リズム動作中に一緒に視聴するユーザの動作情報を入手した時点で、速やかにその動作情報をアバターに反映する場合について説明する。

　図１１は、本実施例におけるアバター表示処理のフローチャートである。図１１において、図８と同様の機能は同じ符号を付し、その説明は省略する。図１１において図８と異なる構成は、図８におけるＳ４１３からＳ４１６の処理を、Ｓ４３１からＳ４３６までの処理とした点である。

　本実施例では、一緒に視聴するユーザが、リズムの感覚を掴めたら、そのリズムに応じた動きを行なうことを想定している。通常は、リズム区間の先頭のタイミング（強拍）で、リズムに関する動作を開始する。各リズム区間の先頭のタイミングで行なうリズムに関する動作は、同じ動作となることが多い。本実施例では、この同じリズム動作のことを動作Ａと定義する。また、リズム区間の先頭のタイミング（強拍）で動作Ａと異なるリズムに関する動作を行なった場合は、動作Ａと異なる動作を意味する動作Ｂと定義している。動作Ｂは、例えば、動作Ａが連続する揺れの動作とすると、動作Ａより大きな動作、大きな移動やジャンプ、手大きく上げる等の動作である。

　図１１において、先ず、１個前のリズム区間（直前のリズム区間）経過中に、管理サーバ１５から、一緒にライブコンテンツを視聴するユーザの動作情報Ａが有ったかどうかを判断する（Ｓ４３１）。この処理は、図８のＳ４１３の処理と等価な処理である。

　Ｓ４３１の処理で、直前のリズム区間経過中に、管理サーバ１５から、一緒にライブコンテンツを視聴するユーザの動作情報が無かった場合は、後ほど説明するＳ４１８の処理に移行する。

　Ｓ４３１の処理で、直前のリズム区間経過中に、管理サーバ１５から、一緒にライブコンテンツを視聴するユーザの動作情報Ａが有った場合は、友達アバターをその動作情報Ａを加味した動き開始する（Ｓ４３２）。

　次に、一緒に視聴するユーザの動作情報Ｂが有るかどうか判断する（Ｓ４３３）。Ｓ４３３の処理で、ユーザの動作情報Ｂがあった場合は、アバターの動作を動作Ａに動作Ｂを重畳した動きとする（Ｓ４３４）。Ｓ４３３の処理で、ユーザの動作情報Ｂが無かった場合は、動作Ａが終了したかどうかを判断する（Ｓ４３５）。

　Ｓ４３５の処理で、動作Ａが終了していない場合は、リズム区間の終端を判定する（Ｓ４１７）。Ｓ４１７の処理で、リズム区間の終端ではない場合は、Ｓ４３３の処理に戻る。Ｓ４３５の処理で、動作Ａが終了した場合は、リズム区間の終端を判定し、終端の場合は、図８と同様に楽曲の終了を判定する（Ｓ４１８）。

　以上説明したように、本実施例によれば、ユーザがリズムをとった動作をしている途中に、他の動作をした場合に、速やかに、かつスムーズにその動作情報をアバター表示に反映させることが可能となる。なお、動作Ａがなく動作Ｂのみの場合に、動作Ｂの動作情報をアバター表示に反映させてもよい。

　実施例１乃至３では、コンサートなどのライブ配信を前提にしていた。これに対して、本実施例では、ライブ配信ではなく、一旦ビデオ化されたビデオ配信に適用した例について説明する。

　ビデオ配信では、コンテンツの再生開始が、任意に行なわれる反面、他のユーザと一緒に視聴して楽しむことに不向きであった。本実施例では、ビデオ配信によるコンテンツでも、他のユーザと一緒に視聴して楽しむことができる方法を提供する。そのため、本実施例では、ビデオ配信されたコンテンツ情報を、管理サーバ１５が一旦受信し、再度、管理サーバ１５から同時にビデオ配信する機能を追加している。管理サーバ１５は、ビデオ配信されたコンテンツを全て受信してから、再度、ビデオ配信することもできるが、本実施例では、配信サーバ１４からビデオ配信されたコンテンツを、管理サーバ１５がタイムシフトして、再度、管理サーバ１５がビデオ配信している。

　図１２は、本実施例における管理サーバ１５の処理手順を示すフローチャートである。図１２において、管理サーバ１５は、ビデオコンテンツ対応処理を開始（Ｓ５１０）すると、ユーザが指定したビデオコンテンツを配信サーバ１４から受信を開始し（Ｓ５１１）、記憶装置４の各種データ部４２に保存する。

　そして、ステップＳ５１２で、保存するビデオコンテンツに対して、タイムシフト処理を開始する。タイムシフト処理とは、受信したデータをテンポラリに保存しながら送信し、送信済みのデータにオーバライトしながら受信する処理である。

　そして、ステップＳ５１３で、管理サーバ１５に登録された、ビデオコンテンツを一緒に視聴するユーザ全てに対して、受信したビデオコンテントの同時配信を開始する。その間、ビデオコンテンツに対するタイムシフトは継続処理（受信しながら配信）を行なう（Ｓ５１４）。

　次に、ステップＳ５１５で、配信サーバ１４からのビデオコンテンツの受信が終了したかどうかを判断する。ビデオコンテンツの受信が終了していない場合は、タイムシフト処理を継続するため、Ｓ５１４の処理に戻る。ビデオコンテンツの受信が終了した場合は、ビデオコンテンツの配信が終了したかどうかを判断する（Ｓ５１６）。

　Ｓ５１６の処理で、ビデオコンテンツの配信が終了していない場合は、タイムシフト終了処理を行なう（Ｓ５１７）。具体的には、ビデオコンテンツの受信が終了しているので、まだ配信されていない残りのビデオコンテンツを配信する。

　Ｓ５１６の処理で、ビデオコンテンツの配信が終了した場合は、管理サーバ１５の、ビデオコンテンツ対応処理を終了する（Ｓ５１８）。

　このタイムシフト処理により、テンポラリで使用する記憶媒体をオーバライトしながら使用するので、使用する記憶容量を少なくすることができる。

　このように、本実施例によれば、ビデオ配信によるコンテンツでも、管理サーバ１５に追加した機能により、ビデオ配信されたコンテンツ情報を、一緒に視聴するユーザに対して、同時にビデオ配信し、実現することが可能となる。

　実施例１乃至３では、ネットワーク等によりライブ配信された映像を、ＨＭＤの表示画面上に、表示することを前提にしていた。これに対して、本実施例では、一般的なＴＶ受信機によるライブ映像の表示に適用した例について説明する。

　図１３は、本実施例における映像表示システムの構成模式図である。図１３において、図１と同様の機能は同じ符号を付し、その説明は省略する。図１３において図１と異なる構成は、ＨＭＤ１１Ａ、１１Ｂは透過型を採用し、配信サーバ１４の代わりに、ＴＶ受信機１６Ａ、１６Ｂが構成要素となっている点である。

　すなわち、第１のユーザ１０Ａが透過型ＨＭＤ１１Ａを介して、ＴＶ受信機１６Ａの表示画面を視聴し、第１のユーザ１０Ａの動作情報を無線ルータ１２Ａ及びネットワーク網１３を介して、管理サーバ１５に伝達する。同様に、第２のユーザ１０Ｂが透過型ＨＭＤ１１Ｂを介して、ＴＶ受信機１６Ｂの表示画面を視聴し、第２のユーザ１０Ｂの動作情報を無線ルータ１２Ｂ及びネットワーク網１３を介して、管理サーバ１５に伝達する。伝達された動作情報は、管理サーバ１５から、ネットワーク網１３及び無線ルータ１２Ａ、１２Ｂを介して、ＨＭＤ１１Ａ、１１Ｂの表示画面上にアバターの動作として反映する。

　このようにして、一般的なＴＶ受信機によるライブ映像においても、管理サーバ１５から、一緒に視聴するユーザの動作情報を入手し、一緒に視聴するユーザのアバターに反映させることで、本発明を適用することができる。

　また、この透過型ＨＭＤは、ＴＶ受信機でなく、ライブ会場にて、直接、生のライブ演奏を視聴する場合においても有効である。すなわち、透過型ＨＭＤで生のライブ映像を視聴しながら、管理サーバ１５から、一緒に視聴するユーザの動作情報を入手し、一緒に視聴するユーザのアバターに反映させることで、本発明を適用することができる。

　勿論、ＨＭＤ１１Ａ、１１Ｂが非透過型の場合でも、映像処理装置７の撮像部７１（カメラ）で、ＴＶ受信機１６の表示画面もしくはライブ会場の映像を撮影し、その撮影した映像情報を、映像処理装置７の表示部７２（表示画面）に表示することができる。従って、管理サーバ１５から、一緒に視聴するユーザの動作情報を入手し、一緒に視聴するユーザのアバターを前記非透過型ＨＭＤ１１Ａ、１１Ｂの表示画面上に重畳して表示することにより実現できることは言うまでも無い。

　実施例１乃至５では、携帯型映像表示装置であるＨＭＤを前提としていた。これに対して、本実施例では、ＨＭＤ以外の映像表示装置に適用した例について説明する。

　本実施例では、スマートフォンや、タブレット端末などの携帯型映像表示装置においても、映像表示装置の方向を把握することができるので、管理サーバ１５から、一緒に視聴するユーザの動作情報を入手し、一緒に視聴するユーザのアバターに反映させることで、本発明を適用することができる。

　図１４は、本実施例におけるスマートフォンの外観図である。図１４において、スマートフォン１１０のスマートフォン正面１１３には、タッチパネルを搭載した表示画面１１１と、自分撮り用のフロントカメラ（インカメラとも言う）１１２、スピーカおよびマイク１１６がある。また、スマートフォン背面１１５には、リアカメラ（アウトカメラもしくは単にカメラとも言う）１１４とマイク１１７がある。

　スマートフォン１１０は、外観からは見えないが、ＨＭＤと同様に各種センサが搭載されており、スマートフォン１１０自体の方向を検知することができる。また、スマートフォン１１０の表示画面１１１には、実施例１にて説明した第１のユーザ１０Ａが装着するＨＭＤ１１Ａの表示画面２２と同等の画面が表示されている。

　一緒に視聴するユーザのアバター２４には、管理サーバ１５から提供される、一緒に視聴するユーザの動作情報及び音声情報が反映され表示されている。但し、スマートフォン１１０は、自己の動作状態を把握するにはやや難があるので、一緒に視聴する他のユーザに対して、動作情報を伝達することは制限される。しかしながら、既存のスマートフォンで他のユーザと一緒にライブコンサートをリズム同期して楽しむことはできるので、臨場感が向上する効果がある。

　また、スマートフォン１１０の自分撮り用のフロントカメラ１１２にて、視聴しているユーザ自体の動画（動き情報及び音声情報）を撮影し、その音声情報を含む映像情報を動作情報として、無線ルータ１２及びネットワーク網１３を介して、管理サーバ１５に伝達することができる。その結果、この音声情報を含む映像情報を、管理サーバ１５から提供することにより、一緒に視聴するユーザのアバターに反映し、表示することができる。

　本実施例では、携帯型映像表示装置としてスマートフォンを例に挙げたが、同等及び近似のハードウェア構成やソフトウェア構成があれば、本発明を実現することができる。例えば、ノートＰＣやタブレットＰＣ等にも適用可能である。

　尚、固定して使用するデスクトップＰＣにおいても、ＨＭＤの向きが変わらない（正面のみ）という前提で、本発明を適用できることは言うまでも無い。

　また、スマートフォンにＴＶチューナが内蔵あるいは接続されている場合には、本実施例は、前述の実施例５にも適用可能である。すなわち、スマートフォン１１０の表示画面１１１にＴＶ画面を表示し、スマートフォン１１０の自分撮り用のフロントカメラ１１２にて、視聴しているユーザ自体の動画（動き情報及び音声情報）を撮影することにより、その音声情報を含む映像情報を動作情報として、無線ルータ１２及びネットワーク網１３を介して、管理サーバ１５に伝達することができる。その結果、この音声情報を含む映像情報を、管理サーバ１５から提供することにより、一緒に視聴するユーザのアバターに反映し、表示することができる。勿論、ＴＶ受信機１６に内蔵もしくは外付けのカメラ機能を設け、ＴＶ受信機１６を視聴しているユーザ自体の動画（動き情報及び音声情報）を撮影することにより、その音声情報を含む映像情報を動作情報として利用してもよい。

　前述の実施例では、他のユーザの動作情報用いて、他のユーザの分身であるアバターに反映して表示することを前提としていた。これに対して、本実施例では、他のユーザの動作情報を用いない例について説明する。

　他のユーザの動作情報を入手する場合、その動作情報を他のユーザの分身であるアバターに反映するには、遅延時間が発生する。一方、一緒に視聴するユーザのアバターが、リズムに完全同期して表示されると、臨場感が高まる。従って、たとえ、一緒に視聴するユーザの動作と異なる動作でも、リズムと完全同期する方が重要である。

　そこで、本実施例では、リズムに完全同期している自己の動作情報そのものを、他のユーザの分身であるアバターに反映して表示する。

　図１５は、本実施例における自己動作反映処理手順を示すフローチャートである。図１５において、自己動作反映処理が開始（Ｓ５２０）されると、管理サーバ１５より、一緒に視聴するユーザの基本アバター（実施例１にて説明済み）を取得する（Ｓ５２１）。

　次に、Ｓ５２２の処理にて、コンテンツが開始されるのを待つ。Ｓ５２２の処理にて、コンテンツの開始があったと判断された場合は、自己動作が有ったかどうかを判断する（Ｓ５２３）。Ｓ５２３の処理で、自己動作が無かった場合は、一緒に視聴するユーザの基本アバターを表示する（Ｓ５２４）。Ｓ５２３の処理で、自己動作が有った場合は、一緒に視聴するユーザの基本アバターに自己動作を反映させて、一緒に視聴するユーザのアバターを表示する（Ｓ５２５）。

　次に、コンテンツが終了したかどうかを判断する（Ｓ５２６）。Ｓ５２６の処理で、コンテンツが終了していない場合は、次の自己動作に備えるため、Ｓ５２３の処理に戻る。Ｓ５２６の処理で、コンテンツが終了した場合は、自己動作反映処理を終了する（Ｓ５２７）。

　このように、自己の動作情報そのものを、一緒に視聴するユーザのアバターに反映して表示しているので、リズムに完全同期して表示することができる。

　また、他のユーザの動作を予め想像し、その想像した他のユーザの動作情報を、他のユーザの分身であるアバターに反映させ、各リズム区間の先頭にてリズムに完全同期して、表示させることもできる。具体的には、実施例１で説明した図８のアバター表示処理のフローチャートにおける、アバターリズム動作（Ｓ４１４）での動作アバターが、予め想像した動作のアバターで表示されることを、意味している。

　これらの手法により、自己ユーザにとって、タイミング的にリズムに完全同期し、他のユーザとの一体感を得ることができる。勿論、前述の実施例と併用できることは言うまでも無い。

　前述の実施例では、アバターの動き情報は、管理サーバ１５等から、その都度、入手することが前提であった。これに対して、本実施例では、アバターの動き情報を、予め取得する例について説明する。

　ライブコンサートでは、そのライブコンサートの楽曲にふさわしい動作が望まれる。本実施例では、その楽曲にふさわしい動作を、ネットワーク網１３を介して、予めライブラリとして提供するライブラリサーバを設けている。

　図１６は、本実施例におけるライブラリサーバに登録されているライブラリのテーブル例である。図１６において、ライブラリテーブル６００は、楽曲名を示す識別情報を有するコンテンツ欄６０１、楽曲からの経過時間を示す経過時間欄６０２、ライブコンサートの楽曲にふさわしい動作の動作情報を示す動作情報欄６０３、から構成されている。

　楽曲に対して、開始時刻か終了時刻までの動き情報を、全てライブラリとして提供することもできるが、本実施例では、動きのある時点（経過時間）のみを登録することにより、ライブラリの保存容量を削減している。

　ユーザは、ライブラリサーバから、予め、この経過時間と動作情報を入手することにより、そのライブコンサートの楽曲にふさわしいアバターの動作を表示させることができ、より臨場感のあるライブコンサートを楽しむことができる。

　ライブコンサートなどのビデオ配信の場合は、ライブコンサートにおける聴衆の動きを、予め把握することができ、その聴衆の動きをパターン化し、動作情報として提供することができる。その結果、より臨場感のあるライブコンサートを楽しむことができる。

　また、ライブラリサーバより、楽曲にふさわしい動きの動作情報を、ライブラリテーブル６００の動作情報欄６０３から任意に抽出し、ユーザの好みに応じて、リズムに同期したアバターを任意に表示することもできる。

　なお、本実施例は、リズムに同期しないコンテンツにも適用可能である。例えば、コメディ（落語や漫才等）などの笑い声や、スポーツなどの応援や、歌舞伎などの掛け声、などにも適用できる。

　勿論、前述の配信サーバ１４もしくは管理サーバ１５に、このライブラリサーバの機能を持たせることができることは言うまでも無い。

　以上、本発明の実施例について説明したが、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成と置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。

１、１１Ａ、１１Ｂ：ＨＭＤ、２：主制御装置、４：記憶装置、５：センサ装置、６：通信処理装置、７：映像処理装置、８：音声処理装置、９：操作入力装置、１０Ａ、１０Ｂ：ユーザ、１３：ネットワーク網、１４：配信サーバ、１５：管理サーバ、２２：表示画面、２４：アバター、３０：制御部、３１：各種センサ情報取得部、３２：通信処理部、３３：他者動作情報保存部、３４：アバター情報保存部、３５：アバター生成処理部、３６：アバター表示処理部、３７：リズム検出処理部、３８：自己動作情報保存部、Ｓ２００：準備処理、Ｓ３００：ライブコンテンツ処理、Ｓ４００：アバター表示処理

Claims (15)

1. 配信されるコンテンツの映像と、コンピュータ生成画像であるアバターとを重畳して表示画面に表示する映像表示装置であって、
   ネットワークと接続する通信処理部と、
   前記通信処理部を介して受信したアバター情報から他者のアバターを生成するアバター生成処理部と、
   前記通信処理部を介して受信した前記コンテンツの映像に付随する連続する動作の動き情報を検出する動き情報検出処理部と、
   前記通信処理部を介して受信した前記コンテンツを表示する表示部と、
   制御部を有し、
   前記アバター生成処理部は、前記生成したアバターの動作に前記動き情報検出処理部で検出した動き情報を加味してアバターを生成し、
   前記制御部は、前記表示部に前記コンテンツに重畳して前記アバター生成処理部で生成したアバターを表示することを特徴とする映像表示装置。
2. 請求項１に記載の映像表示装置であって、
   前記動き情報検出処理部は、前記コンテンツの映像に付随する楽曲のリズムを検出し、
   前記アバター生成処理部は、前記動き情報検出処理部で検出したリズムに同期してアバターを生成し、
   前記制御部は、前記表示部に前記コンテンツに重畳して前記アバター生成処理部で生成したアバターを表示することを特徴とする映像表示装置。
3. 請求項１に記載の映像表示装置であって、
   前記映像表示装置の動きを検出する動き検出処理部を有し、
   前記アバター生成処理部は、さらに、前記動き検出処理部で検出した動きに応じて自己のアバターを生成し、
   前記制御部は、前記表示部に前記コンテンツに重畳して前記アバター生成処理部で生成した前記他者のアバターと前記自己のアバターを表示することを特徴とする映像表示装置。
4. 請求項１に記載の映像表示装置であって、
   前記通信処理部を介して他者の動作情報を受信し、
   前記アバター生成処理部は、前記他者の動作情報を反映してアバターを生成し、
   前記制御部は、前記表示部に前記コンテンツに重畳して前記アバター生成処理部で生成したアバターを表示することを特徴とする映像表示装置。
5. 請求項１に記載の映像表示装置であって、
   視聴するユーザを撮影する撮影部を有し、
   前記撮影部で撮影した映像情報から前記ユーザの動き情報を生成し、
   前記アバター生成処理部は、前記ユーザの動き情報を加味してアバターを生成し、
   前記制御部は、前記表示部に前記コンテンツに重畳して前記アバター生成処理部で生成したアバターを表示することを特徴とする映像表示装置。
6. 請求項２に記載の映像表示装置であって、
   前記通信処理部を介して前記楽曲に対応する動作情報を受信し、
   前記アバター生成処理部は、前記受信した楽曲に対応する動作情報を反映させてアバターを生成し、
   前記制御部は、前記表示部に前記コンテンツに重畳して前記アバター生成処理部で生成したアバターを表示することを特徴とする映像表示装置。
7. 配信されるコンテンツの映像と、コンピュータ生成画像であるアバターとを重畳して表示画面に表示する映像表示装置の表示制御方法であって、
   アバター情報から他者のアバターを生成し、
   前記コンテンツの映像に付随する連続する動作の動き情報を検出し、
   前記生成したアバターの動作に前記動き情報を加味してアバターを生成し、
   前記コンテンツに重畳して前記生成したアバターを表示することを特徴とする表示制御方法。
8. 請求項７に記載の表示制御方法であって、
   前記コンテンツの映像に付随する楽曲のリズムを検出し、
   前記検出したリズムに同期してアバターを生成し、
   前記コンテンツに重畳して前記生成したアバターを表示することを特徴とする表示制御方法。
9. 請求項７に記載の表示制御方法であって、
   前記映像表示装置の動きを検出し、
   前記検出した動きに応じて自己のアバターを生成し、
   前記コンテンツに重畳して前記生成した前記他者のアバターと前記自己のアバターを表示することを特徴とする表示制御方法。
10. 請求項７に記載の表示制御方法であって、
    他者の動作情報を受信し、
    前記他者の動作情報を反映してアバターを生成し、
    前記コンテンツに重畳して前記生成したアバターを表示することを特徴とする表示制御方法。
11. 請求項７に記載の表示制御方法であって、
    前記映像表示装置を視聴するユーザを撮影し、
    前記撮影した映像情報から前記ユーザの動き情報を生成し、
    前記ユーザの動き情報を加味してアバターを生成し、
    前記コンテンツに重畳して前記生成したアバターを表示することを特徴とする表示制御方法。
12. 請求項８に記載の表示制御方法であって、
    前記楽曲に対応する動作情報を受信し、
    前記受信した楽曲に対応する動作情報を反映させてアバターを生成し、
    前記コンテンツに重畳して前記生成したアバターを表示することを特徴とする表示制御方法。
13. 配信されるコンテンツの映像とコンピュータ生成画像であるアバターとを重畳して表示画面に表示する映像表示装置と、前記コンテンツを配信する配信サーバと、前記コンテンツやユーザの情報を管理する管理サーバと、を備えた映像表示システムであって、
    前記映像表示装置は、
    ネットワークと接続する通信処理部と、
    前記通信処理部を介して前記管理サーバから受信した前記映像表示装置を視聴するユーザとは異なる他のユーザのアバター情報から他のユーザのアバターを生成するアバター生成処理部と、
    前記通信処理部を介して前記管理サーバから受信した前記コンテンツの映像に付随する連続する動作の動き情報を検出する動き情報検出処理部と、
    前記通信処理部を介して前記配信サーバから受信した前記コンテンツを表示する表示部と、
    制御部を有し、
    前記アバター生成処理部は、前記生成したアバターの動作に前記動き情報検出処理部で検出した動き情報を加味してアバターを生成し、
    前記制御部は、前記表示部に前記コンテンツに重畳して前記アバター生成処理部で生成したアバターを表示することを特徴とする映像表示システム。
14. 配信されるコンテンツの映像と、コンピュータ生成画像であるアバターとを重畳して表示画面に表示するヘッドマウントディスプレイ装置であって、
    ネットワークと接続する通信処理部と、
    前記通信処理部を介して受信したアバター情報から他者のアバターを生成するアバター生成処理部と、
    前記通信処理部を介して受信した前記コンテンツの映像に付随する連続する動作の動き情報を検出する動き情報検出処理部と、
    前記通信処理部を介して受信した前記コンテンツを表示する表示部と、
    制御部を有し、
    前記アバター生成処理部は、前記生成したアバターの動作に前記動き情報検出処理部で検出した動き情報を加味してアバターを生成し、
    前記制御部は、前記表示部に前記コンテンツに重畳して前記アバター生成処理部で生成したアバターを表示することを特徴とするヘッドマウントディスプレイ装置。
15. 請求項１４に記載のヘッドマウントディスプレイ装置であって、
    前記動き情報検出処理部は、前記コンテンツの映像に付随する楽曲のリズムを検出し、
    前記アバター生成処理部は、前記動き情報検出処理部で検出したリズムに同期してアバターを生成し、
    前記制御部は、前記表示部に前記コンテンツに重畳して前記アバター生成処理部で生成したアバターを表示することを特徴とするヘッドマウントディスプレイ装置。

Images