JP2010093734A - 映像視聴装置、映像視聴装置の制御方法 - Google Patents

Abstract

【課題】ソーシャルグラフ（以下ＳＧ）に基づき、複数のユーザが１つの番組をあたかも一緒にいるかのように観賞できる映像視聴装置とその制御方法を提供する。
【解決手段】本発明の一面では、第１の受信部で受信した放送番組信号を処理し、第１表示領域に出力する放送番組信号処理部と、第２の受信部で受信したグループ化映像信号を処理し、第２表示領域にマルチ画面で出力するグループ化映像信号処理部と、撮像信号を処理して外部へ送信する送信部とを有したことを特徴とする。
【選択図】 図１

Description

この発明は、映像視聴装置、映像視聴装置の制御方法及び情報サービス方法に関し、ソーシャルグラフを発展させた技術であり複数の視聴者のコミュニケーション体系を活性化できるものである。

地理的に離れた場所にいる複数のユーザが、あたかも、同じ場所に集まってコミュニケーションをしながら映像を視聴しているような一体感が得られる映像再生制御方法が提案されている（たとえば特許文献１）。

この技術では、複数のユーザがそれぞれ嗜好情報をサーバーに送信している。サーバーでは嗜好が類似しているユーザをグループ化している。ユーザは、コミュニティー入退会手続きを行うことにより、自身と類似する嗜好性をもつユーザグループに所属する。サーバーは、類似する嗜好性をもつユーザグループの各ユーザに対して、同一の映像シーンが見られるように再生制御コマンドを送信する。

上記したように、複数のユーザが同一の映像を視聴することで、ユーザ間のコミュニケーションに寄与することができる。コミュニケーションに寄与するシステムとして、ＴＶ会議システムもある。この技術では、サービスプロバイダに予め参加者を登録して、相互に映像のやり取りを行うことしかできなかった。そのため、人間関係は閉鎖的であり、適宜、新しい参加者（友人の友人など）を交えて、映像を楽しむことはできなかった。また、従来の技術では、特定のサービスプロバイダに参加者全員を登録する作業が煩雑であり、一度登録したプロバイダを変更することも簡単にはできなかった。

上記のような「複数のユーザが同一の映像を視聴する」という環境をさらにリアル的に実現でき、しかも取り扱いを容易にしたいという要望が高まっている。
特開２００３−１６３８９３号公報

この発明の目的は、ソーシャルグラフ（以下ＳＧ）の人間関係に基づき、複数のユーザが１つの番組を、あたかも一緒にいるかのように観賞できる映像視聴装置とその制御方法を提供することにある。

上記課題を解決するために本発明の一面では、第１の受信部で受信した放送番組信号を処理し、第１表示領域に出力する放送番組信号処理部と、第２の受信部で受信したグループ化映像信号を処理し、第２表示領域にマルチ画面で出力するグループ化映像信号処理部と、撮像信号を処理して外部へ送信する送信部とを有したことを基本とする。

上記の手段によると、ソーシャルグラフ（ＳＧ）のコミュニティーに参加する旨の操作を行うだけで、ソーシャルグラフ（以下ＳＧ）の人間関係に基づき複数のユーザが１つの番組を、あたかも一緒にいるかのように観賞できる。

以下図面を参照して、この発明の実施の形態を説明する。図１に、本発明の一実施の形態の基本構成を示す。

この装置はたとえば、クライアントテレビジョン受信装置（以下クライアントＴＶ）１００として構成されている。アンテナ１からの放送信号は、受信部１１０に導入され、受信部１１０で受信された放送番組信号が放送番組信号処理部１１１でデコードされる。デコードされた音声信号はスピーカ８に供給され、映像信号はメインディスプレイ６に供給される。

インターネット２０上の信号は、受信部２１で受信される。受信信号のうちグループ化信号（後述する）はグループ化信号処理部１１２に入力される。グループ化信号としてはグループ化映像信号、グループ化音声信号があり、それぞれはグループ化映像信号処理部１１３、グループ化音声信号処理部１１４で処理される。処理された映像信号は、マルチ画面としてサブディスプレイ２６で表示される。また処理されたグループ化音声信号は、スピーカ８ａ，８ｂに供給される。このグループ化音声信号は、スピーカ８に入力されてもよい。

また例えばサブディスプレイ２６の近く、あるいは視聴者が座る椅子の近くには、視聴者を撮影するカメラ１４が設置され、また音声をピックアップするマイク１６も設置されている。カメラ１４で撮像された撮像信号、マイク１６でピックアップされた音声信号は、送信部１９を介してインターネット２０上に送出され、所定のサーバーへ送信される。

制御部９は各ブロックを総合的に統括して制御している。また制御部９は操作部１０からの操作信号を受けており、クライアントＴＶ１００の動作モードを制御している。

なおディスプレイ６と２６は別体で示しているが、１つのディスプレイが画面分割されて利用されていてもよい。またディスプレイ２６としてはパーソナルコンピュータのディスプレイが利用されてもよい。またディスプレイ２６はマルチ画面用として複数が用意されていてもよい。

上記の装置は、受信部１１０で受信した放送番組信号を放送番組信号処理部１１１で処理し、ディスプレイ６に出力している。また受信部２１で受信したグループ化映像信号をグループ化映像信号処理部１１３処理し、ディスプレイ２６にマルチ画面で出力している。さらに送信部１９は撮像信号を処理して外部へ送信している。また送信部１９は、制御部９から情報及び制御情報を取得し、視聴しているチャンネル情報及び前記グループ化映像信号を生成するための参照情報となるユーザデータをさらに外部へ送信している。

上記の基本構成により、ソーシャルグラフ（以下ＳＧ）の人間関係に基づき、複数のユーザが１つの番組を、あたかも一緒にいるかのように観賞できる。つまりユーザがスコープ（ＳＧの探索範囲）を入力することで、その範囲に接続するノード（以下友人ノード）をソーシャルグラフ（ＳＧ）から抽出し、友人ノードに対応する友人の映像及び音声（ストリームと呼ぶ）を自身の映像視聴装置に表示することを可能とするものである。またユーザ自身のストリームを友人の映像視聴装置に配信することも可能とする。

次に図２を参照して、具体的実施の形態として、クライアントテレビジョン受信装置（以下クライアントＴＶ）とサービスサーバー（サーバーと略す）の組み合わせを代表し説明する。

まずクライアントＴＶ側の構成例を説明する。アンテナ１は、チューナ部２に接続されており地上デジタル放送を受信する。チューナー部２は、テレビ放送を受信・選局する部分である。本実施例では、デジタル放送を受信して、受信チャンネルの信号を一旦IF（中間周波数）信号に変換する装置として設定している。デジタル復調部３は、IF信号からデジタル信号（TS：トランスポートストリーム）を取り出し、ＭＰＥＧ処理部４へ送る。ＭＰＥＧ処理部４は、デジタル復調部３から送られたトランスポートストリームを処理し、映像/音声のデコードを行う。デコードされた映像データは液晶デバイス制御部（以下ＬＣＤ制御部）５へ渡される。また、音声データは音声出力部７で再生される。

ＬＣＤ制御部５は、映像データをメインディスプレイ６へ送り、画像を表示する。メインディスプレイ６は、ＬＣＤ制御部５に接続されており、ＭＰＥＧ処理部４がデコードした映像データを表示する。すなわち、地上デジタル放送の番組を表示するディスプレイである。

音声出力部７はスピーカ８に接続され、ＭＰＥＧ処理部４が出力した音声データをスピーカ８に出力する。なお、音声出力部７は、音声伸張部２３が出力する音声データの出力も同時に行う。スピーカ８は音声出力部７に接続されており、音声を出力する。

制御部９は、クライアントＴＶの各処理部の動作を統括的に制御するための処理部である。制御部９は、図として明示していないが、制御プログラムを格納するROMと、例えば後述の処理で必要となるカレントユーザ番号他の作業データを格納するRAMを備えている。

操作部１０はリモコン１１からの制御コマンドを受信し、制御部９に送る。リモコン１１は、本発明に関わる操作を行うための装置であり、操作部１０に対して赤外線を利用した無線通信で制御コマンドを与える。リモコン１１には、数字を入力するためのテンキーが設けられており、チャンネル番号の入力を可能としている。また、リモコン１１には、十字キーが設けられており、パスワードなどの文字入力に使用するソフトウェアキーボードを含むＧＵＩ（Graphical User Interface）の操作を可能としている。

図３（Ａ）にリモコン１１（図３（Ｂ））を用いて操作を行うためのＧＵＩの例を示す。メインディスプレイ６上にソフトウェアキーボード６−１とカーソル６−２を表示し、リモコン１１の十字キー１１−１でカーソル６−２をキーボード６−１上に移動して、決定ボタン１１−２で文字を選択する。なお、リモコン１１には、ユーザ設定ＧＵＩを起動する「ユーザ設定ボタン１１−３」、サーバー接続を始める「接続ボタン１１−４」、サーバの接続を終了する「切断ボタン１１−５」がある。

図２に戻り説明する。ユーザデータテーブル作成部１２は、ＴＶを視聴しているユーザがサーバーにログインするためのＩＤ及びパスワード、ソーシャルグラフ（ＳＧ）のノード探索範囲であるスコープ（自身からの距離）を格納するユーザデータテーブル１３を作成する。

メモリに設定されるユーザデータテーブル１３は、ユーザデータテーブル作成部１２が作成したサーバーのログインＩＤなどの個人データを格納しているとともに、制御部９が書き込む現在視聴中のチャンネル情報を格納する。

図４にユーザデータテーブル１３の例を示す。ユーザ番号は、制御部９が発行するユーザの管理番号である。実施例では、クライアントＴＶを視聴するユーザは１人なので、番号は０のみ割り当てられている。ＩＤはサーバーにログインするためのＩＤであり、実施例では簡単のため「０」としている。パスワードは前記ＩＤで認証を行うときのパスワードであり、実施例では「サッカー」としている。スコープはソーシャルグラフにおける友人の探索範囲を示し、実施例ではたとえば「２」とする。チャンネルは制御部９が、ユーザが現在視聴しているチャンネルに応じて、そのチャンネル番号をセットするフィールドである。本実施例ではユーザデータテーブルの１行分のデータセット（ＩＤ、パスワード、スコープ、チャンネル）をユーザデータと呼ぶ。

図２に戻り説明する。カメラ１４は、クライアントＴＶの前のユーザの様子を撮影する。画像圧縮部１５は、カメラ１４が撮影した映像をエンコードする。マイク１６は、クライアントＴＶの前のユーザが発する音声を入力する手段である。音声圧縮部１７は、マイク１６に入力された音声をエンコードする。多重化部１８は、映像圧縮部１５と音声圧縮部１７からの２つの出力を１つの伝送路で送信するため、時間的に配列する処理を行う。

送信部１９は、本実施例のサーバーに対して、前述のユーザデータと多重化部１８の出力である映像音声データ（ストリームと呼ぶ）をインターネット２０を通じて送信する。例えば、Ｈ３２３プロトコルとして広く公知なマルチメディア・リアルタイム通信に関する標準を用いる。

インターネット２０は、通信プロトコルTCP/IPにより全世界のネットワークを相互に接続したコンピュータネットワークである。受信部２１は、サーバーから送信されたストリームをインターネット２０から受信する。

分離部２２は、まず、多重化されたストリームを個々のストリームに分離し、さらに各ストリームの音声と映像を分離して、それぞれを音声伸張部２３と映像伸張部２４に送る。

音声伸張部２３は、分離部２２から音声データを受け取り、伸張して、音声出力部７へ送る。この音声データは、必ずしも音声出力部７に供給される必要はない。別途設けられた音声出力部に供給されてもよい。

映像伸張部２４は、分離部２２から映像データを受け取り、伸張して、ＬＣＤ制御部２５へ送る。ＬＣＤ制御部２５は、映像伸張部２４から送られる複数の映像データを受け取り、ストリーム毎にマルチウインドウ形式で、サブディスプレイ２６に表示する。

サブディスプレイ２６は、ＬＣＤ制御部２５に接続されており、映像伸張部２４がデコードした複数の映像データを表示する。

図５に８つの映像データ（８台のカメラ画像）の表示例を示す。別のクライアントＴＶからの映像データがさらに多くなった場合、マルチ画面の数を多くしてもよい。あるいは、図５に示すような８つの画面が一定の速度で画面がスクロールし、他の画面を視聴できるようにしてもよい。

つぎに、図２に戻りサービスサーバーの構成例を説明する。受信部２７は、インターネット２０経由でクライアントＴＶにつながり、ユーザデータとストリームを受信する。受信部２７は、通常、複数のクライアントＴＶとインターネット２０を介して接続される。

認証部２８は、受信部２７が受信したユーザデータのＩＤ及びパスワードと認証データ２８を用いて、クライアントＴＶのサーバーへの接続の許可/不許可を判定する。

メモリに格納される認証データ２９は、認証部２８が参照するユーザのＩＤとパスワードの組を記憶する。実施例では、簡単のため、サーバー内部に認証部２８と認証データを持つ構成としたが、例えば、サイトを越えて使用できる「認証システム」と「そのシステムで利用できるID」を提供する認証プロトコル「ＯｐｅｎＩＤ」を利用しても良い。

メモリに格納されているソーシャルグラフデータ３０は、あるユーザと、その友人との繋がりを表わすグラフであり、関係を定義する属性を得たものである。すなわち、同グラフは、人と人との関係をノードとエッジで表現する。実施例では、人（又はクライアントＴＶ）をノードで表し、その関係をエッジで表している。例えば、“mixi”（登録商標）、“Facebook”（登録商標）、“MySpace”（登録商標）といった、ソーシャルネットワークサービス(ＳＮＳ)は、このソーシャルグラフデータを基本としており広く公知の技術である。

図６に実施例の説明のためにソーシャルグラフの例を示す。各ノード（四角で示している）にはユニークなＩＤが割り当てられており、ここでは、簡単のためその番号はサーバーのログインＩＤと同一とする。ＩＤ＝０のノードに接続するノードを見れば、ＩＤ＝１から６までのノードが直接の友人であり、ＩＤ＝７，８のノードは友人の友人であることが分かる。また、各ノードは、本実施例で利用するチャンネル及びスコープ（後述）を格納する領域を持ち、ＩＤ＝１〜８のノードには図６で示しているチャンネル及びスコープの値が既に格納されているものとする。

なお、実施例では、簡単のため、サーバー内部にソーシャルグラフデータを持つ構成としたが、ＳＮＳのデータ共有化を目指す技術である「DataPortability」（登録商標）を利用しても構わない。

図２に戻り説明する。ユーザデータ設定部３１は、受信部２７が受信したユーザデータのうち、ＩＤ、スコープ、現在クライアントＴＶで選択しているチャンネルの情報を使用して、ソーシャルグラフデータ３０のＩＤに対応するノードに、スコープとチャンネルをセットする。

図７にソーシャルグラフのノードにスコープとチャンネルをセットした例を示す。ソーシャルグラフでは、各ユーザのノード間の距離が親密度を示し、本実施例では、この距離をスコープと呼ぶ。例えば、スコープが１のノードであれば、自身に接続するノード、すなわち、直接の友人を示し、スコープが２のノードであれば、友人の友人であることを示す。

図２に戻り説明する。セレクターテーブル作成部３２は、受信部２７が受信したユーザのＩＤと、ユーザデータ設定部３０が設定したソーシャルグラフデータを用いて、あるクライアントＴＶに対して、どのクライアントＴＶのストリームを配信すべきかを定義するセレクタテーブル３３を作成する。

メモリに構築されるセレクタテーブル３３は、クライアントＴＶのユーザＩＤ（デスティネーションと呼ぶ）と、同クライアントＴＶに対してストリームを配信するユーザのＩＤのリスト（ソースと呼ぶ）を記したテーブルであり、セレクタテーブル作成部３２が作成する。

図８にセレクタテーブル３３の例を示す。図２に戻り説明する。ストリームセレクタ部３４は、セレクタテーブル３３に基き、ストリームを送信すべき各クライアントＴＶを認識し、また受信部２７が受信した他のクライアントＴＶからの収集ストリームを選択する機能を有する。

ストリーム多重化部３５は、ストリームセレクタ部３４が選択したストリームを多重化して、送信部３６へ送る機能を有する。

送信部３６は、本実施例の各クライアントＴＶに対して、ストリーム多重化部３５で多重化された他のクライアントＴＶの映像音声データ（多重化ストリームと呼ぶ）をインターネット２０を通じて送信する。受信部２１は、この多重化されたストリームを受信して、サブディスプレイ２６に表示する。

制御部３７は、サービスサーバーの各処理部の動作を統括的に制御するための処理部である。サーバは、クライアントＴＶの認証からセレクタテーブルの作成、多重化ストリームの配信までを適切な順序で行う必要がある。シーケンス制御などを制御部３７が行っている。

制御部３７は、図として明示していないが、制御プログラムを格納するROMと、クライアントＴＶに多重化ストリームを配信するために必要なサーバーに接続するクライアントＴＶのＩＰアドレス他のデータを格納するRAMを備えている。

本実施例では、ユーザが「第９チャンネル」を視聴していることを前提に、説明する。まず、（１）ユーザデータの設定、次に（２）クライアントＴＶとサーバーの接続、最後に（３）クライアントＴＶ（ＩＤ＝０）のサブディスプレイに友人（ＩＤ＝１〜８）がＴＶを視聴する様子（ストリーム）が表示されるまでを説明する。

（１）ユーザデータの設定
図９にユーザデータ設定フローを示す。設定は、図３（Ａ）で示すような、広く公知のＧＵＩを使い、リモコン１１を操作することで行う。ステップＳ８０１でリモコン１１のユーザデータ設定ボタンを押下げると、例えば、図３（Ａ）のような、ユーザデータの新規作成あるいは既存データの編集を選択する画面（選択画面）及び、ソフトウェアキーボードの画面がオープンする。実施例の説明では、「選択画面６−３」で「ＹＥＳボタン」（新規作成）を押すことにする。

新規作成が押されたので、ステップＳ８０５で新規ユーザとしてユーザ番号「０」を発行し、ステップＳ８０６で「ユーザデータ設定画面６−４」をオープンする。なお、選択画面で「ＮＯボタン」（既存データの編集）を選択した場合は、ステップＳ８０４の判定がＮＯとなり、ステップＳ８１１において、「ユーザ番号入力画面６−５」がオープンする。ここでユーザ番号として「０」を入力した場合、ステップＳ８０６では、ステップＳ８１１で入力されたユーザ番号「０」で、ユーザデータテーブル（図４）を検索（ステップＳ８１２）し、既設定のデータが、ユーザデータ設定画面にデフォルト値としてセット（ステップＳ８１４）される。

ステップＳ８０７では、サーバーにログインするためのＩＤである「０」とパスワードであるたとえば「サッカー」及びスコープ（ソーシャルグラフ上のノード探索範囲）として「２」をソフトウェアキーボードを使って入力し、ＯＫボタンを押す。サーバにログインするためのＩＤは本来であれば、ある長さの文字列となるが、実施例では簡単のため数字の「０」としている。

ステップＳ８０７でＯＫボタンが押されたので、ＧＵＩに入力されたＩＤ＝０、パスワード＝サッカー、スコープ＝２をユーザデータテーブル１３に書き込み（ステップＳ８０９）、ＴＶ画面上に表示された「ユーザデータ設定画面」他のＧＵＩ画面をクローズ（ステップＳ８１０）する。その結果、ユーザデータテーブルは図１０のようにセットされる。なお、ユーザデータテーブル１３のフィールドのうち、チャンネルはユーザの選択により刻々と変わるもので、サービスサーバー接続（後述）実行時に、制御部９が書き込むフィールドである。（ユーザのプロファイルデータではない）
また、通常、サーバーにアクセスするためのパスワードは、テーブル書き込み時に暗号化されるが、実施例では簡単のため、平文で書き込んでいる。

以上のフローで、ユーザデータテーブル１３の作成が完了する。次にクライアントＴＶとサービスサーバーの接続を行う。なお、ユーザデータテーブルの設定は、変更がない限り、１度行えばよい。

（２）クライアントＴＶとサービスサーバーの接続
クライアントＴＶとサービスサーバーの接続は、ユーザデータを設定した後に、リモコン１１の「接続ボタン」を押すことで行う。接続ボタンを押すと、制御部９は、まず、図２の「ソフトウェアキーボード」と「ユーザ番号入力画面」を表示するので、実施例では、「０」を入力する。まず、制御部９は図として明示していないRAM領域のカレントユーザ番号に「０」を設定する。

次に、制御部９は、同カレントユーザ番号で、図１０のユーザデータテーブルを検索して、ユーザデータを確定する。最後に、現在視聴しているチャンネルの情報（例ではチャンネル＝９）を、前記ユーザデータのチャンネルフィールドに書き込む。その結果、ユーザデータテーブルは図１１に示すようになる。次に、このテーブルを用いて、クライアントＴＶとサーバーの接続を行う。

図１２にクライアントＴＶとサーバーの接続フローを示す。まず、クライアント側からサーバー側にカレントユーザのＩＤ（ＩＤ＝０）、パスワード（パスワード＝サッカー）を送信する（ステップＳ１１０１〜Ｓ１１０２）。サーバー側はクライアントから接続要求と共に送信されたＩＤとパスワードで、クライアントＴＶの接続認証を行う（ステップＳ１１０５〜Ｓ１１０６）。

認証に失敗した場合は接続を拒否して、クライアントＴＶとサーバー共に処理を終了する（ステップＳ１１０７、Ｓ１１１４、Ｓ１１０３）。

接続の確立後（ステップＳ１１０４Ａ）、クライアントＴＶはサーバーにスコープ（スコープ＝２）、チャンネル（チャンネル＝９）を送信し、サーバは同データを受信する（ステップＳ１１０４Ｂ、Ｓ１１０９）。

ステップＳ１１１０からステップＳ１１１３はクライアントＴＶから送信されたスコープとチャンネルをソーシャルグラフ中のノードに設定する処理である。

これにより、図１３に示すように、ソーシャルグラフのＩＤ＝０のノードには、チャンネル＝９、スコープ＝２がセットされる。

次に、クライアントＴＶはユーザのストリーム（映像音声データ）をサーバーへ送信開始する。図１４にクライアントからサーバーへのストリームの送信フローを示す。

ステップＳ１３０１〜Ｓ１３０２でカメラ１４で撮影を行いマイク１６で音声データを取得して、ステップＳ１３０３〜Ｓ１３０４でデータを圧縮後、多重化処理を行い、ステップＳ１３０５でサーバーに対し送信する。

ステップＳ１３０６でリモコン１１の切断ボタンの状態をチェックして、押された場合は送信を終了し、サーバへ切断信号を送信する（ステップＳ１３０７）。サーバーはクライアントＴＶからの切断信号をチェックしており、受信した場合は、切断信号を送信したクライアントＴＶへの多重化ストリームの配信を終了し、ソーシャルグラフのノードのチャンネルとスコープを初期化し、セレクタテーブル（後述）の再作成を行う。

サーバーは、まず、ストリームの配信時に参照するセレクタテーブルを作成する。セレクタテーブル作成はクライアントＴＶの接続確立毎に行う処理であり、接続する全ての配信先であるクライアントＴＶ（デスティネーションと呼ぶ）について作成する必要がある。（そうでなければ全てのクライアントＴＶ間で双方向の配信ができない）ただし、実施例では、簡単のため、１つのクライアントＴＶ（デスティネーション：ＩＤ＝０）について、ソーシャルグラフを用いて、どのように受信元（ソースと呼ぶ）を決定するか、すなわちセレクタテーブルを作成するかについて示す。

実施例では、セレクタテーブルを作成するため、事前に任意のノード間の最短距離を求め、グラフの各ノードに格納しておく。この処理はソーシャルグラフの構造が変化（グラフの作成、ノードの追加／削除、リンクの追加／削除）するタイミングで行うものである。逆にグラフ構造に変化がなければ、１回処理を行えばよい。

各ノードにセットするノード間の最短距離のデータを、実施例では距離リストと呼ぶ。距離リストはそのノードに接続する相手ノードのＩＤ及びそのノードから相手ノードまでの距離の２つの組のリストである。なお処理の都合上、距離リストには、自分自身のＩＤも距離０で登録する。距離リストは以下のように示すことができる。

距離リスト＝（（相手ノードのＩＤ，自身との距離）、（相手ノードのＩＤ，自身との距離）、・・・・・）。

ソーシャルグラフでは、すべてのノードに対して接続があるために、グラフ上に存在するノードの数に応じて、距離リストは膨大になる。しかし、距離リストは友人を見つけるために使うため、高々２乃至３の距離（友人の友人から友人の友人のまで）に接続するノードが登録されていれば十分である。特に実施例では簡単のために、距離２までの範囲（友人の友人）に存在するノードのＩＤを距離リストに登録しているものとする。この範囲をＭＡＸ＿ＤＩＳＴと呼び、あるノードに接続する他のノードを探索する際の深さとなる。実施例では、ＭＡＸ＿ＤＩＳＴ＝２とする。即ち、友人の友人までをグラフ上で探索するものとする。

図１５は、ソーシャルグラフの各ノードに対する距離リストを作成するフローチャートである。図１６は図１５のフローチャートの一部であり、距離リスト設定関数のフローチャートである。以下、図１７に示すソーシャルグラフを例に、各ノードに対する距離リストが設定される様子を説明する。ソーシャルグラフノードの全てには、識別のためユニークなＩＤ（番号）が割り当てられており、そのＩＤの最大値はＩＤ＿ＭＡＸと言う変数で管理される。図１７のソーシャルグラフでは、ノードのＩＤは０〜１５、ＩＤ＿ＭＡＸ＝１６である。

まずステップＳ１８０１からＳ１８０２で変数を初期化する。ステップＳ１８０３ではＩＤ＝０のノードの距離リストに（０，０）を登録する。これはＩＤ＝０のノードとＩＤ＝０のノード（即ち自分自身）の距離は０であることを示す（図１８）。

ステップＳ１８０４で距離リスト設定関数ＳｅｔＤｉｓｔ（処理中ノードＩＤ，始点ノードＩＤ、距離）を呼び出し、ＩＤ＝０のノードから、距離がＭＡＸ＿ＤＩＳＴ以内のノードを距離リストに登録する。ステップＳ１８０３〜Ｓ１８０６を繰り返すことで、ソーシャルグラフの全てのノード（ＩＤ＝０からＩＤ＝１５までのノード）の距離リストが完成する。

ステップＳ１８０４の処理（関数ＳｅｔＤｉｓｔ（））の詳細が図１６に示す処理フローであり、これは幅優先検索で、起点となるノードから接続する他のノードを探索する処理である。

処理中ノードＩＤ＝０、始点ノードＩＤ＝０，距離＝０で、関数ＳｅｔＤｉｓｔ（）を呼び出すと、距離はインクリメントされ１となり、Ｎ ｄｉｓｔにセットされる（ステップＳ１９０１）。処理中ノード＝０につながるノードのひとつとして、まずＩＤ＝１が求まる。（ＣＩＤ＝１）距離リストは、未登録なので、ＩＤ＝１のノードの距離リストには、始点ノードのＩＤ＝０とＮｄｉｓｔ＝１が、２つ組みで追加される。ＩＤ＝０のノードには、ＩＤ＝１からＩＤ＝６のノードがつながっているので、順次各ノードに対する処理を行うと各ノードの距離リストには（０，１）が登録される。これはＩＤ＝０のノードからみて、ＩＤ＝１〜６のノードは距離＝１であること示している（図１９）。

Ｎｄｉｓｔ＝１に対してＭＡＸ＿ＤＩＳＴ＝２のため、さらに深さ方向にノード探索を行う（Ｓ１９０８）。ＩＤ＝０のノードには、ＩＤ＝１からＩＤ＝６のノードがつながっているため、その各々について、再帰的に距離リスト設定関数ＳｅｔＤｉｓｔ（）を呼び出すと、次々とＩＤ＝０〜ＩＤ＝８の各ノードに距離リストが設定される（図２０−図２７）。

図２０はノードＩＤ＝１に対して距離リストを作成する例であり、図２１はノードＩＤ＝２に対して距離リストを作成する例であり、図２２はノードＩＤ＝３に対して距離リストを作成する例であり、図２３はノードＩＤ＝４に対して距離リストを作成する例である。

またＩＤ＝０のノードから距離＝２の探索を行うと、ＩＤ＝１のノードに接続するノードとしてＩＤ＝０，ＩＤ＝６の２つのノードが求まる。ＩＤ＝０のノードは、起点となったノードＩＤ＝６、ＩＤ＝２のノードはＩＤ＝０に直接接続されるノードであり、すでに各ノードの距離には（０，１）が登録されている。したがって、このときは、ＩＤ＝１のノードには、ＩＤ＝０からみて距離＝２のノードは接続されていないと判断できる。

起点となったノード、既に距離リストに登録されているノードの情報が上書きされないように図１６のフローチャートではステップＳ１９０４−Ｓ１９０５でノードの新規登録前に、既登録ノードの判定を行う。この判定を行うために、本実施例では起点となるノードに自身の距離を０として登録し、幅優先でノードを探索し、起点ノードに近いノードから順次距離リストの登録を行っている。

図２７に示すようにソーシャルグラフの各ノードの距離リストがセットされていることを前提として、図２８に１つのクライアントＴＶ（デスティネーション）のセレクタテーブルの作成フローを示す。

図２８において、まず、クライアントＴＶに対応するユーザノード（ＩＤ＝０）からスコープ１である「２」とチャンネル９を取り出す。（ステップＳ１４０１〜Ｓ１４０２）
次に、ソーシャルグラフ上で、ユーザノードに接続するノードであるノード（これを友人ノードと呼ぶ）を探すと、ＩＤ＝１の友人ノードが見つかるので、そのスコープ（スコープ２）である２を取り出す。（ステップＳ１４０３〜Ｓ１４０４）
「スコープ１＜＝スコープ２」、かつ、「友人ノード（ＩＤ＝１）」のチャンネルは「９」であり、ユーザと同じチャンネルを視聴しているので、友人ノード（ＩＤ＝１）をセレクタテーブルに登録する。（ステップＳ１４０５〜Ｓ１４０８）「スコープ１＜＝スコープ２」の判定は、「先方も自分を友人と見なしているか否か」の判定である。ステップＳ１４０３〜Ｓ１４０９の処理を繰り返すと、ユーザノード（ＩＤ＝０）にはスコープ２の範囲に、ＩＤ＝２〜８までの友人ノードが接続し、そのすべてがセレクタテーブルの登録条件を満たすので、最終的にセレクタテーブルは図２９のようになる。

この処理から分かるように、セレクタテーブルの作成は、同じチャンネルを視聴している友人をソーシャルグラフ上で探す処理である。

（３）サブディスプレイにストリーム表示
本発明の実施例は、クライアントＴＶとサービスサーバーが、同期しながら並行して処理を行う。以降の処理は、クライアントＴＶ側のストリームの送信が全て始まり、サーバー側のセレクタテーブルの作成が終了した後の処理である。

セレクタテーブルの作成と同様に、クライアントＴＶの多重化ストリーム配信も、接続する全ての送信先であるクライアントＴＶについて行う必要があるが、実施例では簡単のため、１つのクライアントＴＶに他のクライアントＴＶのストリームを配信する場合を示す。

図３０には、あるクライアントＴＶ（デスティネーション）に対するサーバーのストリーム配信処理フローを示す。

サーバーは、ステップＳ１６０１でセレクタテーブルのデスティネーションＩＤ＝０を選択し、ステップＳ１６０２からＳ１６０３で、セレクタテーブルを参照し、受信しているストリームからソースＩＤ＝１〜８のストリームを選択する。ステップＳ１６０４ではソースＩＤ＝１〜８の計８本のストリームを多重化して、ＩＤ＝０のクライアントＴＶに送信する。クライアントＴＶから切断のシグナルが送られるまで、配信処理を続ける。（ステップＳ１６０６、Ｓ１６０５）
クライアントＴＶは、サーバーから送信された多重化ストリームを受信し、各クライアントＴＶの個々のストリーム８本に分離したのち、映像と音声をデコードする。（ステップＳ１６０７〜Ｓ１６０９）
映像はサブディスプレイ（２６）に表示し、音声は各ストリームの音声とＴＶ放送の音声をミキシングした上でスピーカに出力する。（ステップＳ１６１０〜Ｓ１６１１）この処理を、サーバーからの送信が途絶えるまで続ける。（ステップＳ１６１２、ステップＳ１６０７〜Ｓ１６１１）
上記の処理で、クライアントＴＶのサブディスプレイには、例えば図３１のように、友人たちが現在観賞している番組を楽しむ様子が表示される。同様に、接続する全てのクライアントＴＶについてもセレクタテーブルを作成すれば、ユーザ自身のストリームも友人たちのクライアントＴＶのサブディスプレイの１ウインドウに表示されることは言うまでもない。

このように、広く普及したソーシャルグラフで定義された人間関係も基き、気の合う友人達と、リアルタイムでお互いの様子を見ながら、番組を観賞することができる。本発明では、既に存在するソーシャルグラフを用いることで、友人の登録などの手続きが不要で、しかも、人間関係の定義は、ソーシャルグラフの変化に追従するため、友人達がスポーツパブに集まりサッカーの試合を観賞するような現実に近い形で、ＴＶを観賞できる。本発明は、特にサッカー中継などスポーツ観戦において効果を発揮するものである。

さらに図３２に示すように特定の相手と特別に会話をしたい場合のためにコール信号送受信機能が設けられていてもよい。例えばカーソルを移動させて、特定の小画面を選択し、コール信号を送信するようにしても良い。例えば制御部９には、コール信号送受信処理部９ａ，コール信号受信処理部９ｂが設けられている。いまクライアントＴＶ１００Ａの視聴者が、クライアントＴＶ１００Ｂの視聴者と特別に会話をしたい場合、例えばカーソルを移動させて、クライアントＴＶ１００Ｂからの小画面を選択する。すると、この情報はユーザデータに付加されて、サーバー２００に送信される。サーバー２００は、コール信号を受信した場合、コール信号関連付け部３７ａが動作し、クライアントＴＶ１００Ｂに送信するデータの中に、コール信号（クライアントＴＶ１００ＡのＩＤが付いている）を付加して送信する。するとクライアントＴＶ１００Ｂでは、クライアントＴＶ１００Ａからの送られてきている小画面（特定画面）に例えばフラッシュするマークを表示する。これにより、クライアントＴＶ１００Ｂ側の視聴者は、クライアントＴＶ１００Ａ側の視聴者が呼びかけていることを知ることができる。上記のような状況のときは、特定画面の一部又は枠をフラッシュさせるようにしてもよい。

上記の呼びかけに対して、クライアントＴＶ１００Ｂ側の視聴者は、別途電話をかける、あるいは、音声信号選択処理部９ｃにより、クライアントＴＶ１００Ａ側の音声のみが出力されるように選択処理を行うことができる。これにより互いに選択したクライアント同士の会話も可能となる。

さらに特別画面映像送出部３７ｂがサーバー２００に設けられていてもよい。この場合は、クライアントＴＶ側にも特別画面選択部９ｄが設けられる。この特別画面映像信号は、例えば探索範囲とは独立しており、例えば有料により受信できるようになっている。特別画面映像信号を受信して表示した場合、たとえば、画面Ｓのごとく表示される。この場合もこの画面Ｓのみの音声信号を選択することができる。

このような機能を設けることにより、例えば現在視聴中の番組に関連した出演者又は解説者又は司会者の映像信号を送信することが可能となる。つまり現在視聴中の番組に関して、例えば監督、あるいは俳優から解説などを視聴することができる。

なお、本発明は上記した実施の形態そのままに限定されるものではなく、実施段階ではその趣旨を逸脱しない範囲で構成要素を種々変形して具体化することが可能である。

実施例では、クライアントＴＶはメインディスプレイとサブディスプレイの２台構成としたが、メインディスプレイ上にサブウインドウを作成して、サブディスプレイを代用することも、もちろん可能である。

実施例では、簡単のため、友人登録の条件を「自身と友人のスコープ」と両者の「視聴チャンネル」としたが、ソーシャルグラフに登録された、「性別、年齢、趣味、居住地などの他のファクタ」を含めて条件を設定することも考えられる。同様に、あるファクタを持つメンバーを友人から除外することも考えられる。

実施例では、クライアントＴＶを観賞する人数を１名として、そのＩＤをカレントユーザＩＤとして処理を行ったが、カレントユーザＩＤをリスト化し、複数のカレントユーザＩＤの設定を可能とすることで、例えば家族全員の友人（両親の友人＋子供の友人）と共に番組を観賞することも考えられる。

実施例では、地上デジタル放送を想定したが、ケーブルＴＶや衛星放送で実施することもできることは言うまでもない。

実施例では、各クライアントＴＶは映像と音声の双方を送受信したが、どちらか１方だけでもよい。例えば、映像の送信は止めて、音声のみで参加することも考えられる。例えば、その場合、サブディスプレイには例えばアイコンなどの静止画を表示するなど考えられる。

実施例では、音声を１つのスピーカにミキシングして出力したが、マイクをヘッドセットに変えて、音声を入力すると同時に、個別に音声を配信しても構わない。これにより、ユーザ毎に聞きたいと考える音声を選択可能となる。

実施例では、各クライアントＴＶのストリームをそのまま送信したが、映像を解析して、ジェスチャーを検出し、そのジェスチャーに対応する文字（ガッツポーズ→「ヤッター」という文字列）やアイコン（ガッツポーズ→Ｖサインのアイコン）などの効果を撮影した映像にブレンドして送信しても構わない。

実施例では、各クライアントＴＶのストリームをそのまま送信したが、音声を解析して、歓声を検出し、それに対応する文字（歓声→「ヤッター」という文字列）やアイコン（歓声→Ｖサインのアイコン）など効果を撮影した映像にブレンドして配信しても構わない。

実施例では、各クライアントＴＶが送信するのはストリームデータとしたが、ストリームデータに加えてテキストデータや画像データを同時に送信しても良い。例えば、クライアントＴＶにキーボードを接続して、文字を打ち込み送信、あるいは、手持ちのカメラ画像を友人に送信するなど考えられる。

ＴＶ会議システムといった従来技術では、サービスプロバイダに予め参加するメンバーを登録する必要があり、そのメンバーのみしか相互のストリームをやり取りできないという問題点があった。そのため、人間関係は閉鎖的であり、ビジネス指向であればよいが、適宜、新しい参加者（友人の友人など）を交えて、映像を楽しむといったエンターテインメント指向の用途としては利用できないという問題があった。本発明はこの課題を解決するものである。また、従来の技術では、特定のサービスプロバイダに参加者メンバー全員を登録する作業は煩雑であり、一度登録したプロバイダを変更することも簡単ではなかった。本発明は、ソーシャルグラフの友人関係を多人数の映像視聴に応用することで、この課題も解決するものである。ソーシャルグラフを利用すれば、本発明のために友人を登録する作業が不要で、しかも友人関係を適宜メンテナンスする必要もない。また、刻々とネットワークが変化するソーシャルグラフ上で探索範囲（スコープ）を変えることにより、「友人の友人の友人」といった予想外のメンバーとの偶然の出会いも期待でき、スポーツパブでサッカーの試合を見るような、より現実世界に近い形で映像視聴が可能となる。本発明は、特に、スポーツ観戦においてはきわめて有効な効果を発揮する。

なお、この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

この発明の一実施の形態に関わる基本構成を示す図である。 この発明の一実施の形態におけるクライアントＴＶとサーバーをより具体的に示す図である。 この発明の装置において利用されるグラフィックユーザインターフェースの例とリモートコントローラの例を示す図である。 この発明の一実施の形態で使用されるユーザデータテーブルの例を示す図である。 クライアントＴＶにおけるサブディスプレイにマルチ画像が表示された例を示す図である。 実施例の説明のためにソーシャルグラフの例を示す図である。 ソーシャルグラフのノードにスコープとチャンネルをセットした例を示す説明図である。 この発明の一実施の形態で使用されるセレクタテーブルの例を示す図である。 この発明の一実施の形態で使用されるユーザデータの設定フローの例を示す図である。 図９に示すフローで処理されたユーザデータテーブルの例を示す図である。 図１０のユーザデータテーブルにチャンネル情報が記述された様子を示す図である。 クライアントＴＶとサーバーの接続手順の例を示す図である。 この発明の一実施例においてソーシャルグラフのＩＤ＝０のノードにチャンネル＝９、スコープ＝２がセットされた様子を示す図である。 クライアントからサーバーへのストリームの送信手順の例を示す図である。 ソーシャルグラフの各ノードに対する距離リストを作成するフローチャートである。 図１５のフローチャートの一部であり、距離リスト設定関数のフローチャートである。 ソーシャルグラフの一例を示す図である。 ソーシャルグラフのノードの距離が設定された例を示す図である。 ソーシャルグラフのノードの距離が設定された例を示す図である。 ソーシャルグラフのノードの距離が設定された例を示す図である。 ソーシャルグラフのノードの距離が設定された例を示す図である。 ソーシャルグラフのノードの距離が設定された例を示す図である。 ソーシャルグラフのノードの距離が設定された例を示す図である。 ソーシャルグラフのノードの距離が設定された例を示す図である。 ソーシャルグラフのノードの距離が設定された例を示す図である。 ソーシャルグラフのノードの距離が設定された例を示す図である。 ソーシャルグラフのノードの距離が設定された例を示す図である。 １つのクライアントＴＶ（デスティネーション）のセレクタテーブルの作成手順を示す図である。 図２８に示した処理手順により作成されたセレクタテーブルの例を示す図である。 あるクライアントＴＶ（デスティネーション）に対するサーバーのストリーム配信処理手順を示す図である。 クライアントＴＶのサブディスプレイにて、友人たちが現在観賞している番組を楽しむ様子を示す説明図である。 この発明の別の実施の形態におけるサブディスプレイの様子を示す説明図である。

符号の説明

１・・・アンテナ、２・・・チューナー部、３・・・デジタル副兆部、４・・・ＭＰＥＧ処理部、５・・・ＬＣＤ制御部、６・・・メインディスプレイ、７・・・音声出力部、８・・・スピーカ、９・・・制御部、１０・・・操作部、１１・・・リモコン、１２・・・ユーザデータテーブル作成部、１３・・・ユーザデータテーブル、１４・・・カメラ、１５・・・画像圧縮部、１６・・・マイク、１７・・・音声圧縮部、１８・・・多重化部、１９・・・送信部、２０・・・インターネット、２１・・・受信部、２２・・・分離部、２３・・・音声伸張部、２４・・・映像伸張部、２５・・・ＬＣＤ制御部、２６・・・サブディスプレイ、２７・・・受信部、２８・・・認証部、２９・・・認証データ、３０・・・ソーシャルグラフデータ、３１・・・ユーザデータ設定部、３２・・・セレクタテーブル作成部、３３・・・セレクタテーブル、３４・・・ストリームセレクタ部、３５・・・ストリーム多重化部、３６・・・送信部、３７・・・制御部、１１０・・・受信部、１１１・・・放送番組信号処理部、１１２・・・グループ化信号処理部、１１３・・・グループ化映像信号処理部、１１４・・・グループ化音声信号処理部。

Claims (14)

1. 第１の受信部で受信した放送番組信号を処理し、第１表示領域に出力する放送番組信号処理部と、
   第２の受信部で受信したグループ化映像信号を処理し、第２表示領域にマルチ画面で出力するグループ化映像信号処理部と、
   撮像信号を処理して外部へ送信する送信部と
   を有したことを特徴とする映像視聴装置。
2. 前記送信部は、視聴しているチャンネル情報及び前記グループ化映像信号の取得に寄与する探索情報を含むユーザデータを外部へ送信することを特徴とする請求項１記載の映像視聴装置。
3. 前記ユーザデータに含まれる前記探索情報を入力するためのユーザインターフェースとして動作する操作部を有することを特徴とする請求項２記載の映像視聴装置。
4. 前記第２の受信部は前記グループ化映像信号に対応したグループ化音声信号も受信し、
   前記グループ化音声信号は、グループ化音声信号処理部で処理されることを特徴とする請求項１記載の映像視聴装置。
5. グループ化音声信号処理部は、操作入力に応答してグループ内の任意の単一又は複数の音声信号を選択して出力可能であることを特徴とする請求項４記載の映像視聴装置。
6. 前記第１の表示領域と前記第２の表示領域とはそれぞれ第１、第２の表示器に位置することを特徴とする請求項１記載の映像視聴装置。
7. 前記第２の表示領域は複数の表示器で形成されていることを特徴とする請求項１記載の映像視聴装置。
8. 前記第２の表示領域はパーソナルコンピュータの表示器であることを特徴とする請求項１記載の映像視聴装置。
9. 前記マルチ画面の中から任意の小画面をカーソルで指定したコール信号を送信するコール信号送信処理部を有することを特徴とする請求項１記載の映像視聴装置。
10. 前記受信部で前記マルチ画面の中の任意の小画面を指定したコール信号が受信されたとき、前記指定されている小画面の一部又は枠をフラッシュさせるコール信号受信処理部を有することを特徴とする請求項１記載の映像視聴装置。
11. 前記グループ化映像信号処理部は、前記マルチ画面の中の小画面に前記放送番組信号に関連した出演者又は解説者又は司会者の映像信号を選択して出力することを特徴とする請求項１記載の映像視聴装置。
12. 第１の受信部で受信した放送番組信号を処理し第１表示領域に出力し、
    第２の受信部で受信したグループ化映像信号を処理し第２表示領域にマルチ画面で出力し、
    撮像信号を処理してネットワークへ送信し、
    さらに視聴しているチャンネル情報及び前記グループ化映像信号の取得に寄与する探索情報を含むユーザデータをネットワークへ送信することを特徴とする映像視聴装置の制御方法。
13. 送受信部、制御部及びデータ格納及び処理部を有するサービス方法において、
    複数のクライアントに対応した各ノードを設定し、
    各ノードには対応するクライアントから送信されてくる少なくともクライアント番号、中心ノードと他ノード間の間隔に相当する探索範囲、及び中心ノードに対応したクライアントがする視聴チャンネル番号のユーザデータを格納し、
    特定クライアントからの要求に応じて、前記ユーザデータを参照して前記特定クライアントを中心にした複数の関連ノードであり、かつ各ノードには同じ視聴チャンネルの情報が設定されている関連ノードを示す設定ソーシャルグラフを設定し、
    前記設定ソーシャルグラフに属する各クライアントから送られてくる撮像信号を、グループ化映像信号として前記特定クライアントに送信するようにした
    ことを特徴とする情報サービス方法。
14. 前記さらにグループ化音声信号を前記特定クライアントに送信することを特徴とする請求項１３記載の情報サービス方法。

Images