JP2013258600A

JP2013258600A - 映像表示端末

Info

Publication number: JP2013258600A
Application number: JP2012133896A
Authority: JP
Inventors: Yukinori Endo; 幸典遠藤; Shinji Maeda; 慎司前田; Yutaka Honda; 裕本田; Shin Miura; 紳三浦
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2012-06-13
Filing date: 2012-06-13
Publication date: 2013-12-26
Anticipated expiration: 2032-06-13
Also published as: JP5921348B2

Abstract

【課題】映像表示端末としての動作品質を向上させることのできる映像表示端末を得る。
【解決手段】リソース情報変換部１３２は、自端末の映像表示処理を携帯端末２００に分担させる場合、携帯端末２００で処理を行うために必要となるリソースを求める。リソース予約部１３３は、リソース情報変換部１３２で求めたリソースで携帯端末２００に対してリソース予約とリソース予約解除を行う。
【選択図】図２

Description

本発明は、他の端末と通信を行い映像表示や映像蓄積を行う映像表示端末に関する。

従来の番組録画再生システム、携帯端末およびビデオ録画装置は、放送受信可能な携帯端末とビデオ録画装置間において、携帯端末からビデオ録画装置へ放送のチャンネル情報を送信し、ビデオ録画装置で電子番組表機能を使って番組録画を行う。また、ビデオ録画装置で再生した録画番組を携帯端末へ送信（配信）して、携帯端末側で視聴可能にしていた（例えば、特許文献１）。

また、従来の２画面表示型の複数連携型表示システムは、テレビと携帯表示端末間において、親機（＝テレビ）と子機（＝携帯表示端末）がリアルタイムに連動することによって、テレビ側で放送番組を表示しながら、携帯表示端末側で字幕・スーパ等の文字情報を拡大表示する、またはデータ放送やネット情報番組関連情報を表示する、またはＰｉｃｔｕｒｅＩｎＰｉｃｔｕｒｅ機能の子画面を表示する、またはマルチカメラアングル放送映像（マルチ編成番組）を表示する、といった表示機器間で機能連携するシステムも提案されていた（例えば、特許文献２）。

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

しかしながら、上記の従来技術では、映像表示端末（ビデオ録画装置やテレビ等）と携帯端末（携帯電話やタブレット等）の間で機能連携する際に、双方の（特に処理分担させる端末側の）処理能力（ＣＰＵ性能やメモリ容量や通信性能等）や表示能力（映像フォーマットや解像度等）に基づく使用リソースの差異を考慮していないため、常に快適で安定した連携動作ができるとは限らないという問題点があった。

この発明は上記のような問題点を解決するためになされたもので、映像表示端末としての動作品質を向上させることを目的とする。

この発明に係る映像表示端末は、自端末と相互に通信可能な端末の処理能力を含むリソースの情報を取得する端末情報管理部と、端末情報管理部で取得した端末のリソースに基づき、自端末の映像表示処理を分担させる場合、処理を行うために端末で必要となるリソースを求めるリソース情報変換部と、端末に対して、リソース情報変換部で求めたリソースでリソース予約とリソース予約解除を行うリソース予約部と、リソース予約部が、端末とリソース予約／解除処理を行う場合、端末とのリソース予約プロトコル通信を行うプロトコル通信部とを備えたものである。

この発明の映像表示端末は、自端末の処理を行うために端末で必要となるリソースを求め、このリソースで端末に対してリソース予約するようにしたので、映像表示端末としての動作品質を向上させることができる。

この発明の端末間機能連携の例を示す概念図である。この発明の実施の形態１による映像表示端末と携帯端末とを示す構成図である。この発明の実施の形態１による映像表示端末の動作を示すシーケンス図である。この発明の実施の形態２による映像表示端末の動作を示すシーケンス図である。この発明の実施の形態３による映像表示端末の動作を示すシーケンス図である。この発明の実施の形態４による映像表示端末と携帯端末とを示す構成図である。この発明の実施の形態４による映像表示端末の動作を示すシーケンス図である。

実施の形態１．
図１は本発明の端末間機能連携の例を示す概念図である。
図１において、映像表示端末１００は例えば放送受信可能な液晶テレビや車載テレビといった映像を表示する端末であり、携帯端末２００は例えば携帯電話やタブレットである。これら映像表示端末１００と携帯端末２００とは宅内ネットワークやクラウド・ネットワーク環境等で接続可能とする。図中の映像表示端末１００と携帯端末２００内の円グラフは、それぞれにおけるリソース使用状況を示す。ここで、リソースとは、ＣＰＵ、メモリ、ディスク、ネットワーク等の計算機資源を指し、使用リソース量はＣＰＵ使用率、メモリ使用量、ディスク入出力帯域、ネットワーク通信帯域等で表す。

映像表示端末１００において、電子番組表（ＥＰＧ：ＥｌｅｃｔｒｏｎｉｃＰｒｏｇｒａｍＧｕｉｄｅ）機能を用いて番組表一覧を表示させて番組の録画予約を行うシーンを考える。ＥＰＧ機能は、ラテ欄と呼ぶ電子番組表一覧の中に、放送波やＩＰネットワーク等から取得した番組情報を表示する機能であり、大きくは番組情報取得処理とＥＰＧ描画処理から構成される。端末間で機能連携する前の映像表示端末１００内では、両方の処理を単独で実行した時のリソース使用状況（本図では例としてＣＰＵ使用率）を示している。これに対して、端末間で機能連携する場合、ここでは映像表示端末１００は自身で実行していた処理のうち、番組情報取得処理を携帯端末２００に処理分担させるものとする。

このために、映像表示端末１００は始めに携帯端末２００との間で「リソース予約プロトコル」処理を行う。具体的には、映像表示端末１００は、携帯端末２００に分担させたい処理を自身で実行した場合に使用するリソース量を通知し、携帯端末２００側でそのリソースを予約させる。そして、リソース予約プロトコルを実行した結果、携帯端末２００側で番組情報取得処理が起動され、取得した番組情報は、例えば映像表示端末１００側での表示の移動方向（時間帯やチャンネル）に合わせて、映像表示端末１００側へ逐次データ送信される。映像表示端末１００側は、受信した番組情報をＥＰＧ描画する。このように端末間で使用リソース配分を調整した上で機能連携することにより、映像表示端末１００側のリソース使用量、及び処理負荷を減らし、動作品質を向上させることができる。

図２は、実施の形態１の映像表示端末１００と携帯端末２００とを示す構成図である。
図２において、映像表示端末１００は、ＣＰＵやメモリ等の計算機資源を管理・制御するＯＳ（オペレーティングシステム）１１０をベースとして、リソース管理機構１２０を搭載する。リソース管理機構１２０は、少なくともリソースグループ管理部１２０ａ、リソース設定部１２０ｂ、リソース監視制御部１２０ｃから構成され、ＯＳ１１０上の一つ以上のタスクをいくつかにグループ分けして、グループ毎に各種計算機資源の使用リソース量の上限値を設定することにより、それらの上限値を超過しないように監視・制御するものである。ここで、リソースグループ管理部１２０ａは、グループ分けした各グループを管理する機能部であり、リソース設定部１２０ｂは、それぞれのグループのリソースを設定する機能部、リソース監視制御部１２０ｃは、各グループのリソースの上限を超過しないように監視・制御する機能部である。リソース管理機構１２０の実装例として、Ｗｉｎｄｏｗｓ（登録商標）サーバ上のシステムリソースマネージャやＬｉｎｕｘ（登録商標）上のＣｇｒｏｕｐｓ（Ｃｏｎｔｒｏｌｇｒｏｕｐｓ）がある。

次に、その上位層にリソース予約マネージャ１３０と、一つ以上のアプリ（Ａ）１４０ａ，アプリ（Ｂ）１４０ｂ、アプリ（Ｃ）１４０ｃ，・・・を搭載する。リソース予約マネージャ１３０は、少なくとも、端末情報管理部１３１、リソース情報変換部１３２、リソース予約部１３３、プロトコル通信部１３４を備えている。端末情報管理部１３１は、機能連携（処理分担）対象の端末（＝携帯端末２００）が有する処理能力や表示能力等の情報を相互に通信し、取得した内容を判断する処理部である。リソース情報変換部１３２は、端末間の処理能力等の差異に基づき予約リソース情報を補正計算（正規化）する処理部である。リソース予約部１３３は、リソース管理機構１２０のリソース設定部１２０ｂに対してリソース予約を行う処理部である。プロトコル通信部１３４は、携帯端末２００との間でリソース予約プロトコル通信を行うための通信処理部である。

また、携帯端末２００側も同様の構成であり、少なくとも、ＯＳ２１０、リソース管理機構２２０、リソース予約マネージャ２３０、及び一つ以上のアプリ（Ａ）２４０ａ，アプリ（Ｂ）２４０ｂ，アプリ（Ｃ）２４０ｃ，・・・を搭載するものとする。ＯＳ２１０は、携帯端末２００側のオペレーティングシステムである。リソース管理機構２２０は、携帯端末２００側のリソース管理を行う機能部であり、基本的な構成は映像表示端末１００側のリソース管理機構１２０と同様である。即ち、リソースグループ管理部２２０ａ，リソース設定部２２０ｂ，リソース監視制御部２２０ｃを備えている。

また、リソース予約マネージャ２３０は、映像表示端末１００側のリソース予約マネージャ１３０と対になる機能を有し、端末情報管理部２３１、リソース情報変換部２３２、リソース予約部２３３、プロトコル通信部２３４を備えている。端末情報管理部２３１は、携帯端末２００側の端末情報の管理部である。また、リソース情報変換部２３２は、映像表示端末１００側のリソース情報変換部１３２と同様の処理を行う演算部であるが、携帯端末２００が映像表示端末１００としての動作を行わない場合は、特に設けなくてもよい。リソース予約部２３３は、リソース予約部１３３からの予約要求を受けてリソース予約を行い、その応答をリソース予約部１３３に対して行う処理部である。また、プロトコル通信部２３４は、プロトコル通信部１３４と共に、映像表示端末１００と携帯端末２００間のリソース予約プロトコル処理の通信を制御する通信制御部である。また、アプリ（Ａ）２４０ａ，アプリ（Ｂ）２４０ｂ，アプリ（Ｃ）２４０ｃは、番組情報取得処理を行うといったプログラムである。

次に、実施の形態１の映像表示端末１００の動作について説明する。
図３は、本発明の映像表示端末１００の処理を示すシーケンス図である。
図３において、ステップＳＴ１００で映像表示端末１００のユーザがＥＰＧ表示操作を行ったとする。なお、このＥＰＧ表示操作はユーザによるリモコン（図示せず）の操作といった動作で行われるものとする。

まず、ステップＳＴ１０１で映像表示端末１００は携帯端末２００側へ番組情報取得処理アプリの起動要求を発行する。なお、この番組情報取得処理アプリは、アプリ（Ａ）〜（Ｃ）２４０ａ〜２４０ｃのいずれかのアプリである。ステップＳＴ１０２で携帯端末２００側では、対応するアプリ（処理プログラム）を起動する。次に、ＥＰＧ機能は、予め映像表示端末１００との間の機能連携対象機能に指定しているとすると、リソース予約プロトコルの処理を開始する。まず、ステップＳＴ１０３でリソース予約マネージャ１３０内の端末情報管理部１３１は、プロトコル通信部１３４を介して、携帯端末２００側の端末情報管理部２３１に対して、端末情報の取得要求を発行する。ここで、端末情報とは、ＣＰＵクロック周波数、メモリ搭載サイズ、ネットワーク通信速度等であり、取得要求の項目種別は一つ以上の任意の組み合わせであってよい。

ステップＳＴ１０４で携帯端末２００側の端末情報管理部２３１は要求された端末情報を取得し、ステップＳＴ１０５で映像表示端末１００へ返信する。次に、ステップＳＴ１０６でリソース予約マネージャ１３０内のリソース情報変換部１３２は、携帯端末２００から取得した端末情報に基づき、自身（映像表示端末１００）と携帯端末２００間の処理能力の差異を計算する。そして、携帯端末２００に分担させたい番組情報取得処理を自身で実行した場合に使用するリソース量に、端末間の処理能力の差異を掛け合わせて、携帯端末２００上での予約リソース量を求める。例えば、映像表示端末１００のＣＰＵクロック周波数が５００ＭＨｚ、携帯端末２００のＣＰＵクロック周波数が１ＧＨｚであり、かつ映像表示端末１００上で番組情報取得処理を実行する場合のＣＰＵ使用率が最大１０％だった場合、番組情報取得処理を携帯端末２００上で処理分担させる際の予約リソース量は、ＣＰＵ使用率５％となる。この時、映像表示端末１００上で番組情報取得処理を実行する場合のＣＰＵ使用率といった情報は、予め固定情報として保持しておいてもよいし、リソース管理機構１２０内のリソース監視制御部１２０ｃで過去の動作時に取得した情報を保持しておき、使用するようにしてもよい。

続いて、ステップＳＴ１０７でリソース予約マネージャ１３０内のリソース予約部１３３は、リソース情報変換部１３２で求めた予約リソース量と共に、携帯端末２００側のリソース予約部２３３に対して、使用リソースの予約要求を発行する。ステップＳＴ１０８で携帯端末２００側のリソース予約部２３３はリソース管理機構２２０に対して、番組情報取得処理を行う起動済みアプリを対象として、要求された予約リソース量でリソース予約を行う。正常にリソース予約が行われたら、ステップＳＴ１０９で映像表示端末１００へ予約完了を応答する。ここまでが、端末間の機能連携の開始前に実行するリソース予約プロトコル処理である。なお、このリソース予約プロトコル処理は、プロトコル通信部１３４とプロトコル通信部２３４間の通信によって行われる。

次に、ステップＳＴ１１０で、映像表示端末１００側のＥＰＧ機能アプリから携帯端末２００側へ番組情報の取得要求を発行する。なお、ここでＥＰＧ機能アプリとは、アプリ（Ａ）〜（Ｃ）１４０ａ〜１４０ｃのいずれかのアプリである。ステップＳＴ１１１で、携帯端末２００側の番組情報取得処理アプリは、放送波ではなくＩＰネットワークから番組情報を取得するようにしてもよいし、また、映像表示端末１００側からの番組情報取得要求の有り無しにかかわらず、非同期に番組情報を先読み取得して、一時保存やデータベース化を行うようにしてもよい。

ステップＳＴ１１２で携帯端末２００側の番組情報取得処理アプリは、映像表示端末１００側へ番組情報を送信する。ステップＳＴ１１３で映像表示端末１００側のＥＰＧ機能アプリは、受信した番組情報をＥＰＧ描画する。以後、映像表示端末１００のユーザによるリモコン操作に基づき、ＥＰＧの表示範囲が変わった場合、適宜番組情報の取得要求を発行する。または、先読み効果を出すため、携帯端末２００側から隣接の番組情報を送信し続けるようにしてもよい。

一方、ステップＳＴ１１４でユーザがＥＰＧ終了操作を行ったとする。この場合、ステップＳＴ１１５でリソース予約マネージャ１３０内のリソース予約部１３３は、プロトコル通信部１３４を介して、携帯端末２００側のリソース予約部２３３に対して、使用リソースの予約解除要求を発行する。ステップＳＴ１１６で携帯端末２００側のリソース予約部２３３はリソース管理機構２２０に対して、番組情報取得処理を行うアプリに対するリソース予約を解除する。正常にリソース予約解除が行われたら、ステップＳＴ１１７で映像表示端末１００へ予約解除完了を応答する。ここまでが、端末間の機能連携の終了時に実行するリソース予約プロトコル処理である。なお、このリソース予約プロトコル処理も、プロトコル通信部１３４とプロトコル通信部２３４間の通信によって行われる。

最後に、ステップＳＴ１１８で映像表示端末１００は携帯端末２００側へ番組情報取得処理アプリの終了要求を発行する。ステップＳＴ１１９で携帯端末２００側では、対応するアプリ（処理プログラム）を終了する。

なお、上記の実施の形態では、端末間の処理能力等の差異に基づき予約リソース量を補正計算した上でリソース予約要求を発行するようにしたものであるが、端末間のリソース配分を決める規則や条件といったポリシーとしては、他に例えば表示処理のために使用する描画メモリをできるだけ確保するようにリソース予約要求するようにしてもよい。また、他に映像ストリームのビットレート等の固定的な要因に基づきネットワーク帯域とＣＰＵ使用率をリソース予約要求するようにしてもよい。また、全てのリソースに対して１００％の予約要求するようにしてもよい（その端末の使用を一時的にブロックする）。また、他にトランスコーダ等の特定ハードウェア（リソース）の使用（占有）を予約要求するようにしてもよい。また、始めに最小のリソース予約要求をしておき、その後現在の特定リソースの使用量を定期的に受信し、それらの値に基づいてリソース予約要求を動的に変更するようにしてもよい。

また、上記の一連のリソース予約プロトコル処理において、セキュリティを強化する目的から、リソース予約マネージャ１３０内のプロトコル通信部１３４で暗号化・復号化を施した上で通信するようにしてもよい。すなわち、映像表示端末１００におけるプロトコル通信部１３４と携帯端末２００におけるプロトコル通信部２３４間の通信を暗号化し、それぞれのプロトコル通信部１３４およびプロトコル通信部２３４で暗号化した信号を復号するようにしてもよい。また、同様にセキュリティを強化する目的から、機能連携対象の端末認証やユーザ認証の処理を追加で実行するようにしてもよい。すなわち、プロトコル通信部１３４が携帯端末２００と通信を行う場合、機能連携対象として予め登録されている携帯端末２００であるかを認証する。また、映像表示端末１００を操作するユーザに対してパスワード入力といったユーザ認証を行うようにしてもよい。

また、映像表示端末１００と携帯端末２００間の機能連携の他のアプリケーション適用例として、例えば、ＰｉｃｔｕｒｅＩｎＰｉｃｔｕｒｅ機能の親画面を映像表示端末１００側に表示すると共に、子画面を携帯端末２００側に表示しようとする場合や、マルチカメラアングル放送映像（マルチ編成番組）の第一のチャンネル画面を映像表示端末１００側に表示すると共に、第二のチャンネル画面を携帯端末２００側に表示しようとする場合に、端末情報管理部１３１または新たに端末連携条件判定部（図示せず）を設けて、連携対象の携帯端末２００側に出画可能か、あるいは出画してもよいかといった表示に関わる機能連携の可否条件を判定するようにしてもよい。具体的には、ステップＳＴ１０７でリソース予約マネージャ１０３内のリソース予約部１０７が、使用リソースの予約要求を発行した時、携帯端末２００側で映像配信サービスの契約内容や著作権等に基づき、出画可否の判定を行い、もし出画不可と判断した場合はステップＳＴ１０９で予約エラーの応答をするようにする。携帯端末２００から予約エラーの応答があった場合、端末情報管理部１３１または新たに設けた端末連携条件判定部は、この端末を機能連携対象からは外すようにする。

このように実施の形態１では、端末間で使用リソース配分を調整した上で機能連携するようにしているので、映像表示端末１００側のリソース使用量や処理負荷を減らし、動作品質を向上させ、安定的にきびきびした動きや表示を実現することができる。また、端末間で使用リソース配分を調整する際に、端末間の処理能力等の差異に基づき予約リソース量を補正計算（正規化）するようにしているので、機能連携（処理分担）先の端末における予約リソース量を、実際の使用量に合った無駄のない設定値にすることができる。また、端末間で使用リソースの予約と予約解除のリソース予約プロトコル処理を暗号化して通信する、及び端末／ユーザ認証するようにしているので、セキュリティ上の安全性を確保できる。また、映像表示端末１００と携帯端末２００間で連携してそれぞれに映像等を出画しようとする場合に、機能連携の可否条件を判定するようにしているので、映像配信サービスの契約内容や著作権の侵害を回避しながらマルチデバイス型の表示、利用形態で楽しむことができる。

以上説明したように、実施の形態１の映像表示端末によれば、自端末と相互に通信可能な端末の処理能力を含むリソースの情報を取得する端末情報管理部と、端末情報管理部で取得した端末のリソースに基づき、自端末の映像表示処理を分担させる場合、処理を行うために端末で必要となるリソースを求めるリソース情報変換部と、端末に対して、リソース情報変換部で求めたリソースでリソース予約とリソース予約解除を行うリソース予約部と、リソース予約部が、端末とリソース予約／解除処理を行う場合、端末とのリソース予約プロトコル通信を行うプロトコル通信部とを備えたので、映像表示端末の動作品質を向上させることができる。

また、実施の形態１の映像表示端末によれば、自端末と相互に通信可能な端末との間の通信を暗号化する処理と、端末が機能連携対象として予め登録されているかを判定する端末認証処理と、自端末を操作するユーザの認証処理のうち、少なくともいずれかの処理を行うようにしたので、リソース予約プロトコル処理を実行する際のセキュリティ強化を図ることができる。

また、実施の形態１の映像表示端末によれば、自端末から端末への出画を行う場合、予め決められた出画条件に基づき端末への出画が認められている場合にのみ出画を行うようにしたので、端末の表示に関する機能連携の可否を考慮した動作を実現することができる。

実施の形態２．
上記実施の形態１では、予め、映像表示端末１００と携帯端末２００との端末アドレス（例えばＩＰアドレス）を認識し、コネクションが確立している２台の端末間で、使用リソース配分を調整した上で機能連携するようにしたものであるが、ネットワークに接続された複数の映像表示端末（携帯端末を含む）が存在するような場合に、複数端末の中からそれらの応答遅延や処理能力等に基づいて機能連携（処理分担）する端末を選択し、選択した端末との間で使用リソース配分を調整する例を実施の形態２として説明する。

図４は、実施の形態２における映像表示端末の処理を示すシーケンス図である。
図４において、映像表示端末１００と、この映像表示端末１００に対して機能連携の対象となりうる映像表示端末（携帯端末を含む）が、端末（Ａ）２００ａ、端末（Ｂ）２００ｂ、端末（Ｃ）２００ｃのように複数存在するものとする。ここで、映像表示端末１００の図面上の構成は図２に示した映像表示端末１００と同様である。また、端末（Ａ）２００ａ、端末（Ｂ）２００ｂ、端末（Ｃ）２００ｃは、それぞれ、図２における携帯端末２００と同様に、ＯＳ２１０、リソース管理機構２２０、リソース予約マネージャ２３０、アプリ（Ａ）２４０ａ，アプリ（Ｂ）２４０ｂ，アプリ（Ｃ）２４０ｃ，・・・を備えているものとする。

すなわち、実施の形態２における端末情報管理部１３１は、複数の端末（Ａ）２００ａ、端末（Ｂ）２００ｂ、端末（Ｃ）２００ｃのリソースの情報として、通信帯域情報および処理能力情報のうち少なくとも一方の情報を取得し、この情報に基づいて、応答遅延を最小とする端末または処理能力の余裕度が大きい端末のうち、少なくともいずれかを満たす端末を選択するよう構成されている。その他の構成は実施の形態１と同様である。

実施の形態２においても、ステップＳＴ１００で映像表示端末１００のユーザがＥＰＧ表示操作を行ったとする。
ステップＳＴ１２０で映像表示端末１００内の端末情報管理部１３１は、端末（Ａ）２００ａ、端末（Ｂ）２００ｂ、端末（Ｃ）２００ｃに対して、通信帯域情報の取得要求を発行する。ここで、取得要求する情報の種別は、通信帯域情報の他に、例えば現在のＣＰＵ負荷情報のように現時点で機能連携可能であるかどうかの判断に使用できる端末処理能力に関連する各種情報であってもよい。また、取得要求の項目種別は一つ以上の任意個の組であってよい。

次に、ステップＳＴ１２１で各端末２００ａ〜２００ｃは映像表示端末１００へ通信帯域情報を返信する。ステップＳＴ１２２で映像表示端末１００内の端末情報管理部１３１は、各端末２００ａ〜２００ｃから返信された通信帯域情報を参照し、最も遅延の小さいと判断した端末（ここでは端末（Ａ）２００ａとする）を選択する。ステップＳＴ１２３で映像表示端末１００内の端末情報管理部１３１は、決定した端末（Ａ）２００ａへ決定通知を送信する。この最後のステップは省略してもよい。ここまでが、機能連携対象の端末を選択決定するための付加的なリソース予約プロトコルである。

次に、ステップＳＴ１０１で映像表示端末１００は上記のステップＳＴ１２０〜ＳＴ１２３で決定した端末（Ａ）２００ａ側へ番組情報取得処理アプリの起動要求を発行し、ステップＳＴ１０２で端末（Ａ）２００ａ側では、対応するアプリ（処理プログラム）を起動する。以降は、実施の形態１で説明したリソース予約プロトコルのステップと同じであるためここでの説明は省略する。

なお、ステップＳＴ１２２で端末２００ａ〜２００ｃにおける複数の端末から返信があった場合、端末情報管理部１３１は、予め優先度付けした端末選択ポリシーに基づいて、機能連携（処理分担）する端末を選択するようにしてもよいし、また複数のポリシーを切り替えられる（ユーザが変更できる）ようにしてもよい。具体的には、過去に機能連携が成立した端末を優先させる、機能連携した際に最も省電力化が図ることが可能な端末を優先させる等の様々な端末選択ポリシーが考えられる。

このように実施の形態２では、ネットワークに接続された複数の映像表示端末（携帯端末を含む）との間でそれらの応答遅延や処理能力等の情報を送受信して機能連携（処理分担）する端末を選択するようにしているので、機能連携する上でのデータ送受信の遅延を最小化する等のより適切な端末を選択することができる。また、複数の端末から返信があった場合の端末選択ポリシーを設定、切り替えるようにしているので、映像表示端末１００の特性や利用シーンに合わせて最適な端末を選択することができる。

以上説明したように、実施の形態２の映像表示端末によれば、自端末と相互に通信可能な端末として複数の端末が存在する場合、端末情報管理部は、複数の端末のリソースの情報として、通信帯域情報および処理能力情報のうち少なくとも一方の情報を取得し、この情報に基づいて、応答遅延を最小とする端末または処理能力の余裕度が大きい端末のうち、少なくともいずれかを満たす端末を選択するようにしたので、複数の端末の中から所望する機能連携に適した端末を選択することができる。

また、実施の形態２の映像表示端末によれば、自端末と相互に通信可能な端末として複数の端末が存在する場合、端末情報管理部は、複数の端末のリソースの情報として、通信帯域情報および処理能力情報のうち少なくとも一方の情報を取得し、この情報と予め定められた端末選択ポリシーとに基づいて、端末選択ポリシーに最も適合する端末を選択するようにしたので、所望する端末選択ポリシーに適した端末を選択することができる。

実施の形態３．
上記実施の形態２では、ネットワークに接続された複数の映像表示端末（携帯端末を含む）が存在するような場合に、複数端末の中からそれらの応答遅延や処理能力等に基づいて機能連携（処理分担）する端末を選択し、選択した端末との間で使用リソース配分を調整するようにしたものであるが、次に、ネットワーク接続された任意の端末の中から予約したい空き使用リソース量の有無（予約可否）に基づいて機能連携（処理分担）する端末を選択し、選択した端末との間で使用リソース配分を調整する例を実施の形態３として説明する。

図５は、実施の形態３における映像表示端末の処理を示すシーケンス図である。
図５において、映像表示端末１００と、この映像表示端末１００に対して機能連携の対象となりうる映像表示端末（携帯端末を含む）が、端末（Ａ）２００ａ、端末（Ｂ）２００ｂ、端末（Ｃ）２００ｃのように複数存在するものとする。ここで、映像表示端末１００の図面上の構成は図２に示した映像表示端末１００と同様である。また、端末（Ａ）２００ａ、端末（Ｂ）２００ｂ、端末（Ｃ）２００ｃは、それぞれ、図２における携帯端末２００と同様に、ＯＳ２１０、リソース管理機構２２０、リソース予約マネージャ２３０、アプリ（Ａ）２４０ａ，アプリ（Ｂ）２４０ｂ，アプリ（Ｃ）２４０ｃ，・・・を備えているものとする。

すなわち、実施の形態３における端末情報管理部１３１は、複数の端末のうち、任意の端末に対して空き使用リソース量の問い合わせを行い、問い合わせに対する応答に基づいて複数の端末のうち少なくとも１つの端末を選択するよう構成されている。その他の構成は実施の形態１と同様である。

実施の形態３においても、ステップＳＴ１００で映像表示端末１００のユーザがＥＰＧ表示操作を行ったとする。
ステップＳＴ１２４で、映像表示端末１００内の端末情報管理部１３１は、プロトコル通信部１３４を介して、任意の端末（ここでは、端末（Ａ）２００ａ、端末（Ｂ）２００ｂ、端末（Ｃ）２００ｃとする）に対して、機能連携（処理分担）する上で必要な使用リソースの予約可否要求を一斉同報（ブロードキャスト）で発行する。具体的には、例えば予約したい空き使用リソース量としてＣＰＵ使用率５％以下でかつメモリ空き容量１００ＭＢ以上といった内容で通知する。

ステップＳＴ１２５で各端末２００ａ〜２００ｃから予約可否を応答する。この応答時は、単純に予約可否だけを返信するようにしてもよいし、応答端末における項目別の空き使用リソース量の情報を付与して返信するようにしてもよい。
ステップＳＴ１２６で映像表示端末１００内の端末情報管理部１３１は、最初に予約可能を返信してきた端末を選択するか、または複数の端末から予約可能を返信してきた場合、予約したい空き使用リソース量に最も適合すると判断した端末を選択する。ここでは、端末（Ａ）２００ａが選択されたとする。ここまでが、機能連携対象の端末を選択決定するための付加的なリソース予約プロトコルである。

次に、ステップＳＴ１０１で映像表示端末１００は上記のステップＳＴ１２４〜ＳＴ１２６で決定した端末（Ａ）２００ａ側へ番組情報取得処理アプリの起動要求を発行し、ステップＳＴ１０２で端末（Ａ）２００ａ側では、対応するアプリ（処理プログラム）を起動する。以降は、既に説明したリソース予約プロトコルのステップと同じであるため省略する。

なお、上記例のシナリオでは、機能連携する端末を一つに決定するような記載をしているが、複数の端末を選択することがあってもよい。具体的には、ステップＳＴ１２６で映像表示端末１００内の端末情報管理部１３１は、各端末２００ａ〜２００ｃから返信してきた項目別の空き使用リソース量を比較検討した結果、機能連携（処理分担）した時の全体負荷が最も低くなる、あるいは全体消費電力が最も低く抑えられるような２台以上の複数端末を選択する。そして、後段のリソース予約プロトコルにおいて、選択した各端末に対して、使用リソースを最適に分割した使用リソースの予約要求を発行するようにする。

一方、ステップＳＴ１２４で映像表示端末１００内の端末情報管理部１３１は任意の端末に対して、機能連携（処理分担）する上で必要な使用リソースの予約可否要求を一斉同報（ブロードキャスト）で発行する際に、リソース予約時刻の情報を追加してもよい。例えば、毎週何曜日の何時から何時間といったリソース予約指定を可能にすることで、夜中の間に録画映像のトランスコード処理を行い、翌朝すぐに携帯端末に持出しができるようにするといった利用方法が考えられる。

このように実施の形態３では、ネットワーク接続された任意の映像表示端末（携帯端末を含む）に対して予約したい空き使用リソース量の有無（予約可否）を問い合わせるようにしているので、最適な機能連携（処理分担）候補の端末を選択することができる。また、複数の端末から予約可能（連携可能）の返信を受けた時に、各端末の空き使用リソース量を勘案し、同時に３台以上の複数端末と機能連携することにして各端末に予約リソースを適切に振り分けるようにしているので、機能連携のスケーラビリティを確保することができる。また、空き使用リソース量に加えて、リソース予約時刻の情報を問い合わせるようにしているので、端末間で使用リソースを効率的に融通することができる。

以上説明したように、実施の形態３の映像表示端末によれば、自端末と相互に通信可能な端末として複数の端末が存在する場合、端末情報管理部は、複数の端末のうち、任意の端末に対して空き使用リソース量の問い合わせを行い、問い合わせに対する応答に基づいて複数の端末のうち少なくとも１つの端末を選択するようにしたので、複数の端末の中から所望する機能連携に適した端末を選択することができる。

また、実施の形態３の映像表示端末によれば、端末情報管理部は、空き使用リソース量に加えてリソース予約可能な時刻の問い合わせを行い、問い合わせに対する応答に基づいて複数の端末のうち少なくとも１つの端末を選択するようにしたので、機能連携させる時間を含め、複数の端末の中から所望する機能連携に適した端末を選択することができる。

実施の形態４．
上記実施の形態３では、ネットワーク接続された任意の端末の中から予約したい空き使用リソース量の有無（予約可否）に基づいて機能連携（処理分担）する端末を選択し、選択した端末との間で使用リソース配分を調整するようにしたものであるが、次に、過去の機能連携した端末やリソース予約情報（リソース連携が成立した情報）を記憶しておき、連携端末の選択や使用リソースの予約要求等のリソース予約プロトコル処理を効率化する例を実施の形態４として説明する。

図６は、実施の形態４の映像表示端末を示すシステム構成図である。
図６において、映像表示端末１００ａは、図２に示した実施の形態１の映像表示端末１００と同様に、ＯＳ１１０、リソース管理機構１２０、リソース予約マネージャ１３０ａ、アプリ（Ａ）１４０ａ，アプリ（Ｂ）１４０ｂ，アプリ（Ｃ）１４０ｃを備えている。ここで、ＯＳ１１０、リソース管理機構１２０、アプリ（Ａ）１４０ａ，アプリ（Ｂ）１４０ｂ，アプリ（Ｃ）１４０ｃの構成は実施の形態１と同様であるため、ここでの説明は省略する。

実施の形態４のリソース予約マネージャ１３０ａは、端末情報管理部１３１、リソース情報変換部１３２、リソース予約部１３３ａ、プロトコル通信部１３４、リソース予約履歴テーブル１３５、リソース予約履歴管理部１３６を備えている。リソース予約履歴テーブル１３５は、過去の機能連携した端末やリソース予約情報（リソース連携が成立した情報）を記憶するテーブルであり、リソース予約履歴管理部１３６は、リソース予約履歴テーブル１３５の保存・更新処理と検索処理を行う処理部である。また、リソース予約部１３３ａは、リソース予約を行う端末のリソース予約情報がリソース予約履歴テーブル１３５に記憶されていた場合は、リソース情報変換部１３２で求めたリソースに代えて、リソース予約履歴テーブル１３５のリソース予約情報に基づいてリソース予約を行うよう構成されている。これ以外のリソース予約マネージャ１３０ａ内の構成は実施の形態１と同様である。

また、実施の形態４の携帯端末２００の構成は図２に示した実施の形態１の構成と同様であるため、対応する部分に同一符号を付してその説明を省略する。

図７は、このような場合の映像表示端末の処理を示すシーケンス図である。
図７において、ステップＳＴ１１４でユーザがＥＰＧ終了操作を行ったとする。ステップＳＴ１１５でリソース予約マネージャ１３０内のリソース予約部１３３ａは、プロトコル通信部１３４を介して、携帯端末２００側のリソース予約部２３３に対して、使用リソースの予約解除要求を発行する。
ステップＳＴ１１６で携帯端末２００側のリソース予約部２３３はリソース管理機構２２０に対して、番組情報取得処理を行うアプリに対するリソース予約を解除する。正常にリソース予約解除が行われたら、ステップＳＴ１１７で映像表示端末１００ａへ予約解除完了を応答する。
最後に、ステップＳＴ１２７でリソース予約マネージャ１３０内のリソース予約履歴管理部１３６は、今回機能連携した端末の識別情報（例えばＩＰアドレス）がリソース予約履歴テーブル１３５に保持されていない、及び今回の機能連携（処理分担）におけるリソース予約情報がリソース予約履歴テーブル１３５にないことを確認した場合、これらの情報を保存する。ここまでが、端末間の機能連携の終了時に実行するリソース予約プロトコルである。

ステップＳＴ１１８で映像表示端末１００ａは携帯端末２００側へ番組情報取得処理アプリの終了要求を発行する。ステップＳＴ１１９で携帯端末２００側では、対応するアプリ（処理プログラム）を終了する。

一方、ステップＳＴ１００で、次回、映像表示端末１００ａのユーザがＥＰＧ表示操作を行ったとする。ステップＳＴ１０１で映像表示端末１００ａは携帯端末２００側へ番組情報取得処理アプリの起動要求を発行する。ステップＳＴ１０２で携帯端末２００側では、対応するアプリ（処理プログラム）を起動する。次に、リソース予約プロトコルを開始し、ステップＳＴ１２８でリソース予約マネージャ１３０内のリソース予約履歴管理部１３６は、リソース予約履歴テーブル１３５内を検索して、今回機能連携する端末との間における過去のリソース予約情報を取得する。ステップＳＴ１０７でリソース予約マネージャ１３０内のリソース予約部１３３ａは、リソース予約履歴管理部１３６から渡された予約リソース量と共に、携帯端末２００側のリソース予約部２３３に対して、使用リソースの予約要求を発行する。なお、その携帯端末２００と初めて機能連携を行う場合等、ステップＳＴ１２８のリソース予約検索処理で該当する端末の情報が記憶されていなかった場合、リソース予約部１３３ａは、実施の形態１と同様に、リソース情報変換部１３２で求めた予約リソース量でリソースの予約要求を行う。

ステップＳＴ１０８で携帯端末２００側のリソース予約部２３３はリソース管理機構２２０に対して、番組情報取得処理を行う起動済みアプリを対象として、要求された予約リソース量でリソース予約を行う。正常にリソース予約が行われたら、ステップＳＴ１０９で映像表示端末１００ａへ予約完了を応答する。ここまでが、端末間の機能連携の開始前に実行するリソース予約プロトコルである。以降は、既に説明した動作ステップと同じであるため省略する。

また、以上の説明は携帯端末２００が予め決定されている実施の形態１に対して適用したものであるが、端末が複数の場合である実施の形態２や実施の形態３に対しても適用可能である。例えば、実施の形態２に適用した場合、リソース予約履歴テーブル１３５は、過去に処理分担した端末の通信帯域情報または処理能力のうち少なくとも一方の値を記憶し、端末情報管理部１３１が、端末の選択を行う場合、リソース予約履歴テーブル１３５に登録されている端末の情報を含めて複数の端末の中から選択を行うよう構成される。また、実施の形態３に適用した場合、リソース予約履歴テーブル１３５は、過去に処理分担した端末の空き使用リソース量の値を記憶し、端末情報管理部１３１は、リソース予約履歴テーブル１３５に登録されている端末の情報を含めて複数の端末の中から選択を行うよう構成される。

このように実施の形態４では、過去の機能連携した端末やリソース予約情報（リソース連携が成立した情報）を記憶しておき、次回この内容を参照してリソース予約するようにしているので、連携端末の選択や使用リソースの予約要求等のリソース予約プロトコル処理を効率化できる。

以上説明したように実施の形態４の映像表示端末によれば、過去に処理分担した端末のリソース予約情報を記憶するリソース予約履歴テーブルを備え、リソース予約部は、リソース予約を行う端末のリソース予約情報がリソース予約履歴テーブルに記憶されていた場合は、リソース情報変換部で求めたリソースに代えて、リソース予約履歴テーブルのリソース予約情報に基づいてリソース予約を行うようにしたので、使用リソースの予約要求等のリソース予約プロトコル処理を効率化することができる。

また、実施の形態４の映像表示端末によれば、過去に処理分担した端末の通信帯域情報または処理能力のうち少なくとも一方の値を記憶するリソース予約履歴テーブルを備え、端末情報管理部は、リソース予約履歴テーブルに登録されている端末の情報を含めて複数の端末の中から選択を行うようにしたので、連携端末の選択を効率化することができる。

また、実施の形態４の映像表示端末によれば、過去に処理分担した端末の空き使用リソース量の値を記憶するリソース予約履歴テーブルを備え、端末情報管理部は、リソース予約履歴テーブルに登録されている端末の情報を含めて複数の端末の中から選択を行うようにしたので、連携端末の選択を効率化することができる。

なお、本願発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。

１００，１００ａ映像表示端末、１１０，２１０ＯＳ、１２０，２２０リソース管理機構、１２０ａ，２２０ａリソースグループ管理部、１２０ｂ，２２０ｂリソース設定部、１２０ｃ，２２０ｃリソース監視制御部、１３０，１３０ａリソース予約マネージャ、１３１，２３１端末情報管理部、１３２，２３２リソース情報変換部、１３３，１３３ａ，２３３リソース予約部、１３４，２３４プロトコル通信部、１３５リソース予約履歴テーブル、１３６リソース予約履歴管理部、１４０ａ，２４０ａアプリＡ、１４０ｂ，２４０ｂアプリＢ、１４０ｃ，２４０ｃアプリＣ、２００携帯端末。

Claims

自端末と相互に通信可能な端末の処理能力を含むリソースの情報を取得する端末情報管理部と、
前記端末情報管理部で取得した前記端末のリソースに基づき、自端末の映像表示処理を分担させる場合、当該処理を行うために前記端末で必要となるリソースを求めるリソース情報変換部と、
前記端末に対して、前記リソース情報変換部で求めたリソースでリソース予約とリソース予約解除を行うリソース予約部と、
前記リソース予約部が、前記端末とリソース予約／解除処理を行う場合、当該端末とのリソース予約プロトコル通信を行うプロトコル通信部とを備えた映像表示端末。
自端末と相互に通信可能な端末との間の通信を暗号化する処理と、前記端末が機能連携対象として予め登録されているかを判定する端末認証処理と、自端末を操作するユーザの認証処理のうち、少なくともいずれかの処理を行うことを特徴とする請求項１記載の映像表示端末。
自端末から端末への出画を行う場合、予め決められた出画条件に基づき前記端末への出画が認められている場合にのみ出画を行うことを特徴とする請求項１または請求項２記載の映像表示端末。
自端末と相互に通信可能な端末として複数の端末が存在する場合、
端末情報管理部は、前記複数の端末のリソースの情報として、通信帯域情報および処理能力情報のうち少なくとも一方の情報を取得し、当該情報に基づいて、応答遅延を最小とする端末または処理能力の余裕度が大きい端末のうち、少なくともいずれかを満たす端末を選択することを特徴とする請求項１から請求項３のうちのいずれか１項記載の映像表示端末。
自端末と相互に通信可能な端末として複数の端末が存在する場合、
端末情報管理部は、前記複数の端末のリソースの情報として、通信帯域情報および処理能力情報のうち少なくとも一方の情報を取得し、当該情報と予め定められた端末選択ポリシーとに基づいて、当該端末選択ポリシーに最も適合する端末を選択することを特徴とする請求項１から請求項３のうちのいずれか１項記載の映像表示端末。
自端末と相互に通信可能な端末として複数の端末が存在する場合、
端末情報管理部は、前記複数の端末のうち、任意の端末に対して空き使用リソース量の問い合わせを行い、当該問い合わせに対する応答に基づいて前記複数の端末のうち少なくとも１つの端末を選択することを特徴とする請求項１から請求項３のうちのいずれか１項記載の映像表示端末。
端末情報管理部は、空き使用リソース量に加えてリソース予約可能な時刻の問い合わせを行い、当該問い合わせに対する応答に基づいて複数の端末のうち少なくとも１つの端末を選択することを特徴とする請求項６記載の映像表示端末。
過去に処理分担した端末のリソース予約情報を記憶するリソース予約履歴テーブルを備え、
リソース予約部は、リソース予約を行う端末のリソース予約情報が前記リソース予約履歴テーブルに記憶されていた場合は、リソース情報変換部で求めたリソースに代えて、前記リソース予約履歴テーブルのリソース予約情報に基づいてリソース予約を行うことを特徴とする請求項１から請求項３のうちのいずれか１項記載の映像表示端末。
過去に処理分担した端末の通信帯域情報または処理能力のうち少なくとも一方の値を記憶するリソース予約履歴テーブルを備え、
端末情報管理部は、前記リソース予約履歴テーブルに登録されている端末の情報を含めて複数の端末の中から選択を行うことを特徴とする請求項４または請求項５記載の映像表示端末。
過去に処理分担した端末の空き使用リソース量の値を記憶するリソース予約履歴テーブルを備え、
端末情報管理部は、前記リソース予約履歴テーブルに登録されている端末の情報を含めて複数の端末の中から選択を行うことを特徴とする請求項６または請求項７記載の映像表示端末。