JP2022110820A - テレビ受信機およびテレビシステム - Google Patents

Abstract

【課題】サーバへのアクセス集中を回避することができるテレビ受信機およびテレビシステムを提供する。【解決手段】サーバを介して配信されるコンテンツ情報を受信するテレビ受信機において、当該テレビ受信機が有する固有の情報に基づいて、前記サーバにおける負荷の平準化を図る負荷平準化部を備える。【選択図】図７

Description

本発明は、テレビ受信機およびテレビシステムに関する。

近年、ネットワークの進化により、動画配信サービスが多数実施されるようになった。特に、大型、大画面のテレビ受信機は、これまでの様に放送だけを受信するだけでなく、ネットワークに接続され、配信されてくる動画を再生することで、より高画質で臨場感のある映像を楽しむことが出来るようになった。これは、ネットワークの高速化、テレビ受信機の処理性能の向上によって可能となっており、今後は、更にネットワークより提供される様々なコンテンツをテレビ受信機で表示、操作する機会が増加すると考えられる。

動画配信サービスは、高度化しており、単なる動画視聴だけでなく、動画コンテンツからＥＣ（電子商取引）サイトへ誘導して商品を購入し、インターネット上のＷｅｂ情報（例えばニュースやチケット情報等）から動画で詳細を確認する等、いわゆる、動画とＷｅｂ情報を連結したインターラクティブなサービスが展開されている。

以上の様な状況の中、家庭において手軽に使えるテレビ受信機が、ネットワークより提供される動画や、Ｗｅｂサイトの情報、ＥＣサービス等をユーザに提供する手段となることは、今後のネットワーク化が進行する中で、大変重要なテーマとなっている。

特開２００６―２２２６７４号公報 特開２０２０―１０２７２０号公報

ネットワークの進化により、以前に比べ動画配信サービスが容易に実現されるようになってきた。しかし、テレビ受信機におけるネット動画配信サービスを受信するには、様々な課題があり、放送ほどの受信普及には至っていない。さらに、現在では、ＰＣ等の情報端末では、配信される動画とＷｅｂコンテンツの連動により、より高度なネットワークサービスが実施されているが、これまでのテレビ受信機においては、そのような連動サービスの実現が困難であった。

地上波の放送が統一された規格に準じて動画コンテンツが放送されているのに対して、ネットワークによる動画コンテンツは複数の配信方式によって配信されている。そのため、特定の映像を配信するビデオプラットフォームから配信される動画コンテンツを選択し受信するためには、特別な機能を受信機側に装備する必要があった。また、テレビ放送受信機に配信された動画コンテンツを受信するためには、ネットワークに接続する機能と、受信した動画コンテンツを再生する性能がテレビ受信機に求められる。

テレビ受信機側の機能や性能によっては、受信できる配信動画コンテンツと受信できない配信動画コンテンツが存在する。このため、従来の動画配信サービスを実現するビデオプラットフォームと受信端末は、それぞれに、独自の配信技術を搭載することで実現をしていた。ビデオプラットフォームからすると、複数の異なる性能や機能の受信端末に対して個別に対応をする必要があり、受信端末からすると複数の異なる配信方式のビデオプラットフォームに個別に対応をすることが必要であった。また、動画コンテンツの選択を行う際にも様々な方法があり、一貫した番組選択方式が提供できずユーザへの混乱を与えることとなる。このような状況は、ビデオ配信の普及の妨げとなるばかりでなく、ユーザ利便性の観点からも大きな課題となっている。

一方で、動画コンテンツとＷｅｂコンテンツを相互にリンクして、インターラクティブにサービスを行う際に、テレビ受信機は、リモコンによる操作であるため、ＰＣなどの情報端末の持つキーボードやマウスなどの入力機能に比較して極めて操作性が乏しく、ユーザが快適に操作を行い高度なサービスを受けることは難しかった。なお、ビデオプラットフォームとＷｅｂサイトが連携をすることで、このような高度なサービスを実施しているため、異なるビデオプラットフォームと異なる機能や性能のテレビ受信機でこのような連動サービスを共通して提供することは困難である。

そこで、サーバであるテレビゲートウエイを設け、テレビゲートウエイがコンテンツサービスプロバイダからのコンテンツ情報を集約して配信するビデオプラットフォームからのコンテンツ情報を含む情報を受信し、受信したコンテンツ情報をテレビ受信機で受信可能になるよう該情報を変換することが考えられる。

しかしながら、サーバであるテレビゲートウエイを設けるようにした場合において、例えばリニアチャンネルのコンテンツを再生する場合、放送時間が決まっているため、サーバであるテレビゲートウエイに対するテレビ受信機のアクセスが集中することになる。したがって、サーバであるテレビゲートウエイについては、テレビ受信機からのアクセスの集中のピークに合わせて設計する必要があり、コスト高になってしまう。

本発明が解決しようとする課題は、サーバへのアクセス集中を回避することができるテレビ受信機およびテレビシステムを提供することである。

実施の形態のテレビ受信機は、サーバを介して配信されるコンテンツ情報を受信するテレビ受信機において、当該テレビ受信機が有する固有の情報に基づいて、前記サーバにおける負荷の平準化を図る負荷平準化部を備える、ことを特徴とする。

図１は、本発明に基づく第１の実施例の説明図である。 図２は、本発明に基づく第１の実施例のネット番組表の構成図である。 図３は、本発明に基づく第１の実施例のネット番組表の説明図である。 図４は、本発明に基づくテレビ受信機の構成例である。 図５は、本発明に基づくビデオプラットフォームの構成例である。 図６は、本発明に基づくテレビゲートウエイの構成例である。 図７は、ネット番組表取得および表示の流れを示すシーケンス図である。 図８は、ビデオプラットフォームとＴＶクラウドのＩＤの予約例を示す図である。 図９は、その他のＩＤを示す図である。 図１０は、ネット番組表データの構成例を示す図である。 図１１は、ネット番組表データの構成情報例を示す図である。 図１２は、Configuration情報のpeak_shiftキーオブジェクトを示す図である。 図１３は、本発明に基づく第２の実施例の説明図である。 図１４は、本発明に基づく第２の実施例のＩＤ構成とＩＤの結合の説明図である。 図１５は、本発明に基づく第２の実施例のＩＤの結合処理の説明図である。 図１６は、本発明に基づく第２の実施例のＩＤ結合時のネット番組表の構成図である。 図１７は、本発明に基づく第２の実施例のＩＤ結合時の画面表示例である。 図１８は、本発明に基づく第２の実施例のコンテンツ選択に必要な情報である。 図１９は、本発明に基づく第２の実施例の広告の挿入方式である。 図２０は、本発明に基づく第３の実施例の構成図である。 図２１は、本発明に基づく第３の実施例の動作説明図である。

以下、本発明に関わる実施形態に関して、図面を参照して、詳細に説明する。

本発明は、ネットワークを使って実施される、複数の動画配信プラットフォームから送出される動画コンテンツを、性能や機能の異なるテレビ受信機で選択する際に、より簡単な方法で動画コンテンツ選択を可能とし、更に、動画コンテンツとＥＣやニュース、或いは、トラベル情報等のサービスを提供するＷｅｂコンテンツ等を連動して動作することに適した、動画配信とＷｅｂコンテンツの連動システムに関する。

当該システムは異なる機能のビデオプラットフォームと異なる機能や性能のテレビ受信機で構成されるシステムである。本発明はこのようなシステム環境において、良好な動画視聴環境、更には、動画とＷｅｂコンテンツをリンクさせた高度なサービスを実施する。

本発明では、テレビゲートウエイを設置し、モバイル端末とテレビ受信機を連携させることで、これらの課題を解決する。

さらに、本発明では、異なるビデオプラットフォームからのコンテンツを一旦テレビゲートウエイで受信する。更にテレビゲートウエイからの出力を、ほぼ同等の性能及びほぼ同等の機能を有するテレビへ接続されたＴＶクラウドへ入力する。ここで、テレビゲートウエイは、ビデオプラットフォームからの入力を変換し、ＴＶクラウドに共通に提供可能なフォーマットに変換を行い、更に、ＴＶクラウドは、接続先の管理化にあるテレビで選択可能な画面データ構成を生成して、それぞれのテレビ受信機で最適なコンテンツ選択画面であるネット番組表を形成する。

（第１の実施形態）
本発明に関わる第１の実施例を図１に示す。従来の映像配信システムと異なるのは、サーバであるテレビゲートウエイ１２１とＴＶクラウド１３１～１３４が、ビデオプラットフォーム１１１～１１３とテレビ受信機１４１～１５０の間に位置している。

ＣＳＰ１０１～１０８によって提供される動画コンテンツ、及び、コンテンツ選択のための情報は、それぞれビデオプラットフォーム１１１～１１３によって、テレビゲートウエイ１２１に入力される。テレビゲートウエイ１２１は、所定の動画コンテンツ選択のための情報の変換を行った後、ＴＶクラウド１３１～１３４に入力する。

ＴＶクラウド１３１～１３４は、テレビゲートウエイ１２１よりそれぞれのＴＶクラウド１３１～１３４へ入力された情報を、テレビ受信機がコンテンツ選択のための画面を構成するためのデータに変換する。

ＴＶクラウド１３１は、接続先かつ管理下にあるほぼ同等機能のテレビ受信機群１４１～１４３に対してネット番組表データを生成し送信する。同様に、ＴＶクラウド１３２は、テレビ受信機群１４４～１４５、ＴＶクラウド１３３は、テレビ受信機群１４６～１４７、ＴＶクラウド１３４は、テレビ受信機群１４８～１５０へ出力される。これらそれぞれのテレビ受信機群は、ほぼ同等の機能及び性能を有した塊として管理される。

ここで、ＴＶクラウド１３１～１３４は、それぞれの接続先のテレビ機能や性能の情報を有しており、テレビ受信機に対して、受信可能なネット番組表データを生成し、それぞれのテレビ受信機は、そのデータに基づきが最適な画面を構成する。

以上の動作により、異なるビデオプラットフォームから提供される動画コンテンツを、異なる機能を有するテレビ受信機で共通して選択することが可能となる。

以下、本システムの動作の詳細を説明する。

図２に本実施例によって提供されるネット番組表の例を示す。

ビデオプラットフォーム１１１～１１３より、コンテンツ選択のための情報である、タイムテーブル２０１、コンテンツメタデータ２０２、バナーデータ２０３が、テレビゲートウエイ１２１に提供される。これらのデータは、ビデオプラットフォーム１１１～１１３に依存しており、それぞれ異なるフォーマットとなっている。次に、テレビゲートウエイ１２１は、これら、タイムテーブル２０１、コンテンツメタデータ２０２、バナーデータ２０３を、各ＴＶクラウド１３１～１３４に供給するため、共通のコンテンツ選択データ２０４へ変換を行う。ここで、コンテンツ選択データ２０４には、バナーを配置するためのタイムテーブルとチャンネル番号及び、コンテンツの内容を説明するメタデータが含まれている。

テレビゲートウエイ１２１より、コンテンツ選択データ２０４を受信したＴＶクラウド１３１～１３４は、それぞれのテレビ受信機の機能、性能に合わせて、ネット番組表データ２１０を生成する。この際、ビデオプラットフォーム１１１～１１３より提供される動画コンテンツは、単一或いは複数のチャンネルに割り付けられ、ユーザは、ビデオプラットフォームの違いを意識せず動画コンテンツを選択することが出来る。このような画面はネット番組表データ２１０を基に最終的にはテレビ受信機のブラウザにより構成される。ここで、メタデータには、映像音声フォーマット情報が含まれており、当該テレビ受信機の機能や性能の情報と比較することで、再生の可否を判断する。テレビ受信機能や性能の情報は、各ＴＶクラウドが保持しており、再生不可となる番組は、ネット番組表上でグレイアウトされる。

以上の動作の詳細を図３に示す。

ビデオプラットフォーム１１１～１１３により、タイムテーブル、コンテンツメタデータ、バナーデータのデータセット３０１～３０３がテレビゲートウエイ１２１へ提供される。ここで、データセット３０１、３０２、３０３には相互互換性は保証されず、異なるフォーマットで提供される。テレビゲートウエイ１２１により、これらのデータセットは、共通のコンテンツ選択データ２０４に変換される。テレビゲートウエイ１２１より提供されるコンテンツ選択データ２０４を各ＴＶクラウド１３１～１３４が受信し、それぞれのＴＶクラウドで、ネット番組表データ３４１や３４４を生成する。ここでは、例として、ＴＶクラウド１３１とＴＶクラウド１３４を示す。例えば、ＴＶクラウド１３１は、接続先のテレビ受信機１４１～１４３のために、ネット番組表データ３４１を生成し、ＴＶクラウド１３４は、接続先のテレビ受信機１４１～１５０のために、ネット番組表データ３４４を生成する。それぞれのテレビ受信機は、これらのデータを基に画面提示を行う。

図４に本発明に関わるテレビ受信機の構成図を示す。

アンテナ１１０１により、放送を受信し、チューナ１１０２により、デジタルストリームに変換された放送コンテンツは、信号処理部１１０３で音声信号、映像信号に変換される。音声信号は音声処理部１１０４で処理され、スピーカ１１０６により音声が再生される。また、映像信号は映像処理部１１０５により処理され、映像表示部１１０７により映像が再生される。ＣＰＵ１１０９は、メモリ１１０８、不揮発性メモリ１１１０に接続され、制御プログラム（アプリケーション）が実行され、チューナ１１０２の制御、信号処理部１１０３の制御を行う。なお、ユーザの操作は、リモコン１１１３から受信部１１１２に入力され、制御プログラムへ入力される。通信インタフェース１１１１は、ネットワークより配信される動画コンテンツやネット番組表を受信し、ＣＰＵ１１０９の制御プログラムで処理する。

図５に本発明に関わるビデオプラットフォームの構成図を示す。ＣＰＵ１２０２は、メモリ１２０１及びストレージ装置１２０３に接続されており、制御プログラムを実行する。操作部１２０５により操作者が動作を制御する。通信インタフェース１２０４は、ネットワークに接続されており、動画コンテンツの入出力、動画の配信、コンテンツ選択情報の入出力を行う。なお、映像処理部１２０６は入力された動画コンテンツをエンコードし暗号化を行い、動画配信用のストリームを生成する。

図６に本発明に関わるテレビゲートウエイの構成図を示す。

ＣＰＵ１３０２は、メモリ１３０１及びストレージ装置１３０３に接続されており、所定の処理プログラムが動作する。インタフェース１３０４は、ビデオプラットフォームからの入出力及びＴＶクラウドへの入出力を行う。なお、操作者は、操作部１３０５により動作を制御する。

次に、ネット番組表データの受け渡し方法について説明する。

図７は、ネット番組表取得および表示の流れを示すシーケンス図である。図７に示すように、ビデオプラットフォーム１１１～１１３とテレビ受信機１４１～１５０との間のネット番組表データのやりとりは、テレビゲートウエイ１２１を経由して行う。

ビデオプラットフォーム１１１～１１３は、ネット番組表データをテレビゲートウエイ１２１の所定領域（ＥＰＧ Ｓ３）にアップロードする（ステップＳ１）。テレビゲートウエイ１２１は、アップロードされたネット番組表データを、ネット番組表データ用のＣＤＮ（Contents Delivery Network）に配置する。

テレビ受信機１４１～１５０は、ネット番組表データ用のＣＤＮに対して直接アクセスしてネット番組表データを取得する（ステップＳ２）。

なお、テレビゲートウエイ１２１は、各ＴＶクラウド１３１～１３４に対してそれぞれを識別するＴＣ－ＩＤを発行し、各ビデオプラットフォーム１１１～１１３に対してそれぞれを識別するＰＦ－ＩＤを発行し、チャンネル番号を発行する。

ここで、図８はビデオプラットフォーム１１１～１１３とＴＶクラウド１３１～１３４のＩＤの予約例を示す図である。図８に示すように、各ＴＶクラウド１３１～１３４に対応するテレビ受信機のメーカに対し、ＴＣ－ＩＤがそれぞれ予約される。また、図８に示すように、各ビデオプラットフォーム１１１～１１３の配信事業者に対し、ＰＦ－ＩＤがそれぞれ予約される。

また、図９はその他のＩＤを示す図である。図９に示すように、ホームエージェントを識別するＨＡ－ＩＤは、ＴＣ－ＩＤ所有の各テレビ受信機のメーカより発行される。モバイルエージェントを識別するＭＡ－ＩＤは、ＰＦ－ＩＤ所有の各配信事業者により発行される。事業者に属するビデオを提供する動画コンテンツ提供者であるＣＳＰを識別するＣＳ－ＩＤは、配信事業者により発行される。

テレビゲートウエイ１２１は、上記のＰＦ－ＩＤに合わせて、事業者情報のリスト（ｐｆｉｄｓ.ｊｓｏｎ）を作成する。ビデオプラットフォーム１１１～１１３は、アサインされたチャンネルのチャンネル情報のリスト（ｃｈａｎｎｅｌｓ.ｊｓｏｎ）を作成する。こうしてテレビ受信機１４１～１５０は、現在有効なチャンネルの情報を取得することができる。

ここで、図１０はネット番組表データの構成例を示す図、図１１はネット番組表データの構成情報例を示す図である。

図１０に示すように、ビデオプラットフォーム１１１～１１３は、サービスを提供する全チャンネル分の、過去１週間、現在、未来１週間分の１５日間分の番組情報（＜ｙｙｙｙｍｍｄｄ＞.ｊｓｏｎ）を提供する。加えて、ビデオプラットフォーム１１１～１１３は、番組情報リスト（＜ｙｙｙｙｍｍｄｄ＞.ｊｓｏｎ）で参照するビデオ情報（＜ＶＯＤ－ＩＤ＞．ｊｓｏｎ）、シリーズ番組情報（＜ｓｅｒｉｅｓ＿ＩＤ＞.ｊｓｏｎ）、広告情報（＜ＡＤ－ＩＤ＞.ｊｓｏｎ）を作成する。さらに、ビデオプラットフォーム１１１～１１３は、過去番組表に表示するユーザにお勧めしたいおすすめ番組情報であるＶＯＤリスト（ｖｏｄｌｉｓｔ.ｊｓｏｎ）を作成する。

図１１に示すように、ネット番組表データの構成情報は、上述の番組情報リスト、ビデオ情報、シリーズ番組情報、広告情報、おすすめ番組情報に加え、設定情報であるConfiguration情報、ログサーバアクセス情報、事業者情報のリスト、チャンネル情報のリスト、番組情報更新情報を含む。

図１１に示すように、ネット番組表データの構成情報のうち、Configuration情報、ログサーバアクセス情報、事業者情報のリスト、番組情報更新情報の作成者は、テレビゲートウエイ１２１（図１１ではＴＧＷと記載）である。また、ネット番組表データの構成情報のうち、チャンネル情報のリスト、ビデオ情報、シリーズ番組情報、広告情報、番組情報リスト、おすすめ番組情報の作成者は、ビデオプラットフォーム１１１～１１３（図１１ではＶＰＦと記載）である。

Configuration情報（Ｃｏｎｆ.ｊｓｏｎ）には、例えばサーバアクセスのｐｅａｋ＿ｓｉｆｔ情報が記載されている。Configuration情報のファイル単位は、全体で一つである。

ログサーバアクセス情報（ｆｉｒｅｈｏｓｅ＿ｐａｒａｍｓ.ｊｓｏｎ）には、テレビゲートウエイ１２１のログサーバ（ｆｉｒｅｈｏｓｅ ｓｔｒｅａｍ）にデータをアップロードするためのアクセスキー情報が記載されている。ログサーバアクセス情報のファイル単位は、全体で一つである。

事業者情報のリスト（ｐｆｉｄｓ.ｊｓｏｎ）には、番組を配信する事業者の事業者情報と、事業者がサービスをしているＣＳ－ＩＤに関する記述が記載されている。事業者情報のリストのファイル単位は、全体で一つである。

チャンネル情報のリスト（＜ＰＦ＿ＩＤ＞／ｃｈａｎｎｅｌｓ．ｊｓｏｎ）には、配信される番組のチャンネル情報（ｓｅｒｖｉｃｅ＿ｉｄ）の情報が記載されている。チャンネル情報のリストのファイル単位は、ビデオプラットフォーム１１１～１１３（図１１ではＶＰＦと記載）毎である。

ビデオ情報（＜ＶＯＤ－ＩＤ＞．ｊｓｏｎ）には、ネット番組表データで参照するものであって配信されるビデオに関する情報が記載されている。各番組情報はビデオ情報をもとに構成され、再生される動画は必ずビデオ情報をもとにビデオタイプによって契約状況の確認の有無を判断し、再生に用いられる。なお、視聴制限のかかった情報については、視聴者の同意が得られるまでは画面に情報は提示されない。ビデオ情報のファイル単位は、ビデオプラットフォーム１１１～１１３（図１１ではＶＰＦと記載）毎である。

シリーズ番組情報（＜Ｓｅｒｖｉｃｅ＿ｉｄ＞.ｊｓｏｎ）には、連続ドラマや関連番組をまとめるためのリストがＳｅｒｖｉｃｅ＿ｉｄ（シリーズ識別単位）で記述され、エピソード番号順にＶＯＤ－ＩＤが並べられる。シリーズ番組情報のファイル単位は、ビデオプラットフォーム１１１～１１３（図１１ではＶＰＦと記載）毎である。

広告情報（＜ＡＤ－ＩＤ＞.ｊｓｏｎ）には、番組放送中に指定されたタイミングで画面上におすすめ番組への誘導を行う情報が記載されている。なお、広告情報（＜ＡＤ－ＩＤ＞.ｊｓｏｎ）は、ネット番組表には提示しない。広告情報のファイル単位は、ビデオプラットフォーム１１１～１１３（図１１ではＶＰＦと記載）毎である。

番組情報リスト（＜ｙｙｙｙｍｍｄｄ＞.ｊｓｏｎ）には、ネット番組表に表示される１５日間の範囲に含まれる番組情報が、日付ごとにリスト化して記載されている。番組情報リストのファイル単位は、ｓｅｒｖｉｃｅ＿ｉｄ毎であって１日単位である。

なお、前述した視聴年齢制限設定が有効な場合、参照するビデオ情報が制限されている番組はそのまま番組表には提示せず、ユーザの許諾後に提示する。

おすすめ番組情報（ｖｏｄｌｉｓｔ.ｊｓｏｎ）には、事業者がおすすめするＶＯＤのＶＯＤ－ＩＤリストが事業者ごとに記載されている。おすすめ番組情報のファイル単位は、ビデオプラットフォーム１１１～１１３（図１１ではＶＰＦと記載）毎である。

番組情報更新情報（＜ｓｅｒｖｉｃｅ＿ｉｄ＞＿ｌａｓｔｕｐｄａｔｅｄ.ｊｓｏｎ）には、番組情報リスト（＜ｙｙｙｙｍｍｄｄ＞.ｊｓｏｎ）をアップデートした日時情報である番組情報更新情報が記載されている。番組情報更新情報のファイル単位は、ｓｅｒｖｉｃｅ＿ｉｄ毎である。

ところで、テレビゲートウエイ１２１は、ビデオプラットフォーム１１１～１１３に対し、予めクレデンシャルとして、client_ＩＤ（ＰＦ－ＩＤ）とclient_secretを配布する。

ビデオプラットフォーム１１１～１１３は、client_ＩＤ（ＰＦ－ＩＤ）とclient_secretを使って、番組情報リスト（＜ｙｙｙｙｍｍｄｄ＞.ｊｓｏｎ）をテレビゲートウエイ１２１の所定領域（ＥＰＧ Ｓ３）にアップロードする（ステップＳ１）。

テレビゲートウエイ１２１は、ビデオプラットフォーム１１１～１１３がネット番組表データをアップロードしたことを検知すると、番組情報更新情報（＜ｓｅｒｖｉｃｅ＿ｉｄ＞＿ｌａｓｔｕｐｄａｔｅｄ.ｊｓｏｎ）をチャンネル（service_ＩＤ）毎に生成し、ネット番組表データとともにネット番組表データ用のＣＤＮに配置する。

番組情報更新情報（＜ｓｅｒｖｉｃｅ＿ｉｄ＞＿ｌａｓｔｕｐｄａｔｅｄ.ｊｓｏｎ）は、テレビゲートウエイ１２１がチャンネル（Ｓｅｒｖｉｃｅ_ｉｄ）毎に生成し、ネット番組表データ用のＣＤＮに配置する。

番組情報更新情報は、ビデオプラットフォーム１１１～１１３がアップロードする所定領域と、テレビゲートウエイ１２１が配置するＣＤＮと、に蓄積される。日ごとの番組情報更新情報のデータのうち、８日以上過去のものは、テレビゲートウエイ１２１が削除できる。

テレビゲートウエイ１２１は、広告情報（＜ＡＤ－ＩＤ＞.ｊｓｏｎ）や、ビデオ情報（＜ＶＯＤ－ＩＤ＞．ｊｓｏｎ）、シリーズ番組情報（＜Ｓｅｒｖｉｃｅ＿ｉｄ＞.ｊｓｏｎ）については、ビデオプラットフォーム１１１～１１３が所定領域上のデータを削除した場合に、ＣＤＮ上のデータを削除することができる。

番組情報更新情報の内容は、以下の通りである。
｛
<yyyymmdd>: <最終更新日時 （Epoch）>，
<yyyymmdd>: <最終更新日時 （Epoch）>，
<yyyymmdd>: <最終更新日時 （Epoch）>，
<yyyymmdd>: <最終更新日時 （Epoch）>，
<yyyymmdd>: <最終更新日時 （Epoch）>，
（１５日分続く）
｝

なお、当該番組情報更新情報が存在しない場合、最終更新日時の値は０とする。

テレビゲートウエイ１２１は、番組情報更新情報を取得するためのネット番組表データ取得用認証鍵（API_key）を生成する。テレビゲートウエイ１２１は、ネット番組表データをアクセスする権限を持つＩＡＭユーザを作成しておき、１２時間毎にネット番組表データ取得用認証鍵（API_key）を更新・取得する。なお、ネット番組表データ取得用認証鍵（API_key）は、２４時間有効とする。ネット番組表データ取得用認証鍵（API_key）は、作成から２４時間後に破棄されるものとする。ネット番組表データ取得用認証鍵（API_key）は、ビデオプラットフォーム１１１～１１３やチャンネルに依らず共通で定期的に更新される。

ＴＶクラウド１３１～１３４は、ネット番組表データ取得用認証鍵（API_key）をテレビゲートウエイ１２１から１２時間毎に取得し、配下のテレビ受信機１４１～１５０が取得できるようにする。

テレビ受信機１４１～１５０は、httpsでx-api-keyヘッダにネット番組表データ取得用認証鍵（API_key）を付加して、番組情報更新情報を取得する。

ビデオプラットフォーム１１１～１１３は、通常においては１日に１回程度、番組情報更新情報を更新する。なお、ビデオプラットフォーム１１１～１１３は、任意の時間に、番組情報更新情報を更新することもできる。

テレビ受信機１４１～１５０は、定期的に、テレビゲートウエイ１２１のネット番組表データ用のＣＤＮにある<service＿ｉｄ>＿ｌａｓｔｕｐｄａｔｅｄ.ｊｓｏｎをチェックすることで、番組情報更新情報が更新されたことを検知することができる。

テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、詳細は後述するが、テレビ受信機１４１～１５０からテレビゲートウエイ１２１へのアクセス集中を回避するため、デバイス固有のaccess_shift_timeを求める（ステップＳ３）。そして、テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、詳細は後述するが、以降のネット番組表データの取得、ｍｐｄの取得、ログのアップロード時に、access_shift_timeを反映させる。

また、テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、詳細は後述するが、ネット番組表の更新タイミングのチェック時間（epg_update_check_time）も同様に、テレビゲートウエイ１２１へのアクセス集中を回避できるように求める（ステップＳ３）。

テレビ受信機１４１～１５０は、ビデオプラットフォーム１１１～１１３のアプリケーションと連携操作をすることにより、テレビゲートウエイ１２１上でＰＦ－ＩＤとＭＡ－ＩＤとを紐づける。

ＴＶクラウド１３１～１３４は、テレビ受信機１４１～１５０毎に連携している状況を保持し、テレビ受信機１４１～１５０が情報を取得できるようにする。

テレビ受信機１４１～１５０は、ビデオプラットフォーム１１１～１１３との連携状況に応じ、ネット番組表の表示の仕方を変えることができる。

なお、番組情報やビデオ情報には「視聴年齢制限設定」の情報が含まれていてもよい。また、テレビ受信機１４１～１５０上でユーザが視聴年齢制限の設定ができる場合には、テレビ受信機１４１～１５０は、視聴年齢制限の設定に従ってネット番組表の表示や番組再生時に、視聴年齢制限を掛ける。このような視聴年齢制限は、ＰＩＮコード入力などのユーザ操作によって解除できるようになっていることが望ましい。

次に、ネット番組表データの表示方法について説明する。

ネット番組情報は、過去１週間、現在、未来１週間分の１５日間分表示可能とする。番組情報＜ｙｙｙｙｍｍｄｄ＞.ｊｓｏｎには、一日分のデータが含まれる。なお、番組情報＜ｙｙｙｙｍｍｄｄ＞.ｊｓｏｎには、開始時刻が含まれる。

テレビ受信機１４１～１５０は、ネット番組表の表示において、現在番組表を、初回においては一番若いチャンネルから表示できるだけを表示する。テレビ受信機１４１～１５０は、最後に再生したチャンネルを記憶する。また、テレビ受信機１４１～１５０は、２回目以降においては、最後に再生したチャンネルにフォーカスを合わせる。

なお、最後に再生したチャンネルがリニアチャンネルコンテンツ（放送時間が決まっている番組）の場合、テレビ受信機１４１～１５０は、最後に再生したチャンネルのＰＦ－ＩＤとｓｅｒｖｉｃｅ＿ｉｄの現在番組を表示する。

なお、最後に再生したチャンネルがＶＯＤ（Video On Demand）の場合、テレビ受信機１４１～１５０は、最後に再生したチャンネルのＰＦ－ＩＤ，ｓｅｒｖｉｃｅ＿ｉｄ，ｅｖｅｎｔ＿ｉｄを表示する。ｅｖｅｎｔ＿ｉｄが表示範囲の１５日間を超えている場合、テレビ受信機１４１～１５０は、同じチャンネルの一番古いｅｖｅｎｔ＿ｉｄを表示する。

なお、表示の並び順は、テレビ受信機１４１～１５０のメーカの仕様で決められる。

また、ネット番組表上での操作仕様は、テレビ受信機１４１～１５０のメーカで自由に設定できる。

ところで、上述のようにサーバであるテレビゲートウエイ１２１を設け、テレビゲートウエイ１２１がコンテンツサービスプロバイダからのコンテンツ情報を集約して配信するビデオプラットフォーム１１１～１１３からのコンテンツ情報を含む情報を受信し、受信したコンテンツ情報をテレビ受信機１４１～１５０で受信可能になるよう該情報を変換するようにした場合、以下のような課題がある。サーバであるテレビゲートウエイ１２１を設けるようにした場合において、例えばリニアチャンネルのコンテンツを再生する場合、放送時間が決まっているため、サーバであるテレビゲートウエイ１２１に対するテレビ受信機１４１～１５０のアクセスが集中することになる。したがって、サーバであるテレビゲートウエイ１２１については、テレビ受信機１４１～１５０からのアクセスの集中のピークに合わせて設計する必要があり、コスト高になってしまう。

そこで、本実施形態のテレビ受信機１４１～１５０においては、ＣＰＵ１１０９がアプリケーションに従って実行することにより、負荷平準化部１１０９ａとして機能する。負荷平準化部１１０９ａは、テレビゲートウエイ１２１に対するアクセスのアクセス時間を分散させるようにし、サーバであるテレビゲートウエイ１２１へのアクセス集中を回避する。以下において、テレビゲートウエイ１２１へのアクセス集中回避処理について説明する。

リニアチャンネル再生時において、テレビ受信機１４１～１５０は、ビデオプラットフォーム１１１～１１３のｍｐｄや、テレビゲートウエイ１２１のネット番組表データ用のＣＤＮから広告情報を取得する。この際、テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、テレビゲートウエイ１２１へのアクセスの集中を回避するため、各テレビ受信機１４１～１５０固有の情報で、アクセス時刻をシフトさせて動作するようにする。

テレビ受信機１４１～１５０は、アクセスシフト時間（access_shift_time）を計算するための基準値を、ネット番組表データ用のＣＤＮに配置されているConfiguration情報（Ｃｏｎｆ.ｊｓｏｎ）から取得する。テレビ受信機１４１～１５０は、ネット番組表の起動時に、Configuration情報（Ｃｏｎｆ.ｊｓｏｎ）をチェックする。テレビ受信機１４１～１５０は、Configuration情報（Ｃｏｎｆ.ｊｓｏｎ）の基準値が更新されていた場合、再計算を行う。

アクセスシフト時間（access_shift_time）は、リニアチャンネルコンテンツの提示シフトタイムである。すべてのテレビ受信機１４１～１５０が決められた時刻にリニアチャンネルにアクセスして、テレビゲートウエイ１２１へのアクセス集中が発生しないように、アクセスシフト時間は、テレビ受信機１４１～１５０毎に一定時間内で番組提示時刻をシフトする。

図１２は、Configuration情報のpeak_shiftキーオブジェクトを示す図である。テレビ受信機１４１～１５０は、テレビゲートウエイ１２１のネット番組表データ用のＣＤＮに配置されているConfiguration情報（Ｃｏｎｆ.ｊｓｏｎ）を取得する。そして、テレビ受信機１４１～１５０は、図１２に示すように、Configuration情報（Ｃｏｎｆ.ｊｓｏｎ）のpeak_shiftキーオブジェクトにあるｖｉｄｅｏのｍａｘｄｅｌａｙ（秒）の範囲でシフトを実行する。例えば、テレビ受信機１４１～１５０は、シフトを実行するのは１０ｍｓ程度の範囲とし、テレビ受信機１４１～１５０毎に異なる時刻にアクセスするようにする。

アクセスシフト時間（access_shift_time）の演算例を下記に示す。
access_shift_time＝（ｉｎｔ）（乱数％（Ｄ＊１００＋１））；//１０ｍｓ
Ｄ：最大遅延可能時間 peak_shift.Video.maxdelay（second）
Ｕ：テレビ受信機が有する固有の情報（ｅｘ．ＴＶ―ＩＤ（テレビ受信機に個別に付された識別情報））
乱数のシードにＵ（ＴＶ－ＩＤ）を設定

そして、テレビゲートウエイ１２１へのアクセス時刻は、下記式により決定される。
アクセス時刻＝Ｓ＋access_shift_time＊１０ｍｓ
Ｓ：開始時刻

加えて、テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、ネット番組表データの更新チェック時刻についても、テレビゲートウエイ１２１へのアクセス集中が発生しないようにシフトする。

テレビ受信機１４１～１５０は、ビデオプラットフォーム１１１～１１３がネット番組表を更新したかどうかを定期的にチェックするために、テレビゲートウエイ１２１のネット番組表データ用のＣＤＮの番組情報更新情報（＜ｓｅｒｖｉｃｅ＿ｉｄ＞＿ｌａｓｔｕｐｄａｔｅｄ.ｊｓｏｎ）を取得して確認する。このようなテレビゲートウエイ１２１に対する情報取得のアクセスが集中しないように、テレビ受信機１４１～１５０は、テレビ受信機毎に異なる時間にアクセスするように制御する。

テレビ受信機１４１～１５０は、図１２に示すように、Configuration情報（Ｃｏｎｆ.ｊｓｏｎ）のpeak_shiftキーオブジェクトにあるｅｐｇのｍａｘｄｅｌａｙ（秒）の範囲でシフトを実行する。例えば、テレビ受信機１４１～１５０は、シフトを実行するのは１０ｍｓ程度の範囲とし、テレビ受信機１４１～１５０毎に異なる時刻にテレビゲートウエイ１２１にアクセスするようにする。

ネット番組表データ更新チェック時刻（epg_update_checktime）の演算例を下記に示す。
epg_update_check_time＝（ｉｎｔ）（乱数％（Ｐ＊１００＋１））；//１０ｍｓ
Ｐ：チェック間隔 peak_shift.epg.maxdelay （second）
Ｕ：テレビ受信機が有する固有の情報（ｅｘ.ＴＶ－ＩＤ（テレビ受信機に個別に付された識別情報））
乱数のシードにＵ（ＴＶ－ＩＤ）を設定

そして、テレビ受信機１４１～１５０は、毎時、下記の時刻にチェックする。
checktime＝epg.maxdelay＊ｉ＊１０００＋epg_update_check_time＊１０；
checktime（ｍｓ）
ｎ＝（６０／epg.maxdelay）;
ｉ＝０から、ｉ＜ｎの間
epg.maxdelay：一時間以内の６０分を均等に割れる値

加えて、テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、ログの収集時刻についても、テレビゲートウエイ１２１へのアクセス集中が発生しないようにシフトする。

ここで、ログ収集方式について説明する。上述したように、テレビ受信機１４１～１５０は、テレビゲートウエイ１２１のログサーバ（ｆｉｒｅｈｏｓｅ ｓｔｒｅａｍ）にデータ（ログ）をアップロードする（ステップ４）。

まず、測定ログのテレビゲートウエイ１２１への送信インタフェースを規定する。このインタフェースは、テレビ受信機１４１～１５０上のアプリケーション（ネット番組表アプリケーションならびに、動画配信のためのＨＴＭＬ５アプリケーション）によって使用される。

テレビゲートウエイ１２１への送信タイミングは、サービス運用に依存する。しかしながら、アクセスの集中を回避するため、本実施形態においては、テレビゲートウエイ１２１からの時間シフト情報に基づき、各テレビ受信機１４１～１５０において時間をシフトさせ、複数のログをまとめて送信するようにする。

まず、機器認証について説明する。

テレビゲートウエイ１２１は、テレビゲートウエイ１２１のログサーバ（ｆｉｒｅｈｏｓｅ ｓｔｒｅａｍ）にデータをアップロードすることだけができるＩＡＭユーザを作成しておく。テレビゲートウエイ１２１は、ＩＡＭユーザのアクセスキー（access key ＩＤとsecret access keyの組）を１２時間に１度生成し、１日後に削除する。これにより、有効なアクセスキーが常に２つ存在することになる。テレビゲートウエイ１２１は、生成したアクセスキーを含むテレビゲートウエイ１２１のログサーバ（ｆｉｒｅｈｏｓｅ ｓｔｒｅａｍ）にデータをアップロードするための情報を、ＪＳＯＮファイル（ｆｉｒｅｈｏｓｅ＿ｐａｒａｍｓ.ｊｓｏｎ）としてネット番組表データと同じ場所に置く。

ＪＳＯＮファイル（ｆｉｒｅｈｏｓｅ＿ｐａｒａｍｓ.ｊｓｏｎ）の例を以下に示す。なお、アクセスキーは、有効な２つのうち新しいアクセスキーを記述する。
｛
"access_key_ＩＤ": <access key ＩＤ>，
"secret_access_key": <secret access key>，
"region": "ap-northeast-1"，
"stream_name": <firehose stream name>，
"expires_in": 43200，
"scope": "activity_log"
｝

各テレビ受信機１４１～１５０は、ネット番組表データ取得と同様の方法でＪＳＯＮファイル（ｆｉｒｅｈｏｓｅ＿ｐａｒａｍｓ.ｊｓｏｎ）を取得する。各テレビ受信機１４１～１５０は、ＪＳＯＮファイル（ｆｉｒｅｈｏｓｅ＿ｐａｒａｍｓ.ｊｓｏｎ）が取得してから"expires_in"に書かれた秒数（ここでは４３２００秒、１２時間）は有効であることが保証されるので、その間はＪＳＯＮファイル（ｆｉｒｅｈｏｓｅ＿ｐａｒａｍｓ.ｊｓｏｎ）をローカルに保持する。

テレビ受信機１４１～１５０は、ログのアップロードが必要な際に、ＪＳＯＮファイル（ｆｉｒｅｈｏｓｅ＿ｐａｒａｍｓ.ｊｓｏｎ）を使って認証し、テレビゲートウエイ１２１のログサーバ（ｆｉｒｅｈｏｓｅ ｓｔｒｅａｍ）にログデータを送信する。

なお、テレビ受信機１４１～１５０は、ログデータ送信時に有効期限が切れている場合、再度テレビゲートウエイ１２１からＪＳＯＮファイル（ｆｉｒｅｈｏｓｅ＿ｐａｒａｍｓ.ｊｓｏｎ）を取得し、情報を更新する。

次に、アップロードのタイミングについて説明する。

各テレビ受信機１４１～１５０は、ログ情報の生成時に、都度テレビゲートウエイ１２１のログサーバ（ｆｉｒｅｈｏｓｅ ｓｔｒｅａｍ）にアップロードするのではなく、ログサーバの負荷平準化を図るためログ情報を一時的にバッファリングする。

各テレビ受信機１４１～１５０は、テレビゲートウエイ１２１がＣＤＮ上に用意したConfiguration情報（Ｃｏｎｆ.ｊｓｏｎ）のpeak_shift.logエレメントを、起動時に参照する。

以下に、Configuration情報（Ｃｏｎｆ.ｊｓｏｎ）のpeak_shift.logエレメントの例を示す。
｛
peak_shift：｛
video：｛maxdelay：120，lastupdated：<epoch>｝，
log：｛maxdelay：1800，maxsize：4000，lastupdated：<epoch>｝，
...
｝
...
｝

maxdelayは、サーバアクセス分散設定情報であって、ログを保持すべき最大時間（秒）を示す。maxsizeは、データの保持に関する設定情報であって、保持すべきログの最大容量（byte）を示す。これらの値はhard limitではなく、これを超過してもテレビゲートウエイ１２１はアップロードを受け付ける。一方、各テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、ログの保持時間がmaxdelayを、あるいはログの保持容量がmaxsizeを、いずれかが超えそう、あるいは超えた場合に、速やかにアップロードするよう試みる。また、各テレビ受信機１４１～１５０のローカルストレージ容量の制約でmaxsize近くまでログを保持できない場合、各テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、maxsizeに関わらずアップロードしてよいが、テレビゲートウエイ１２１のログサーバ（ｆｉｒｅｈｏｓｅ ｓｔｒｅａｍ）の負荷軽減のため、できるだけそれぞれの最大値まで保持するよう努める。

なお、通信不具合等でログをアップロードができなかった場合、テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、maxdelayやmaxsizeの制限を超過してログを保持する。テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、リトライは指数的バックオフとし、むやみに再送しない。

このように本実施形態によれば、テレビ受信機が有する固有の情報に基づいて、サーバアクセスのアクセス時間を分散させるようにするので、サーバへのアクセス集中を回避することができる。

なお、テレビ受信機１４１～１５０の負荷平準化部１１０９ａは、サービスの状況やアクセスの状況に応じて、データの保持に関する設定情報やサーバアクセス分散設定情報にかかる設定情報（Configuration情報）を変更するようにしてもよい。これにより、サービスの状況やアクセスの状況に応じて、確実にサーバへのアクセス集中を回避することができる。

（第２の実施形態）
図１３に本発明に基づく第２の実施例を示す。

本実施例は、第１の実施例に対して、モバイル端末４０１～４１０、及び、視聴データ保存部４５１、ＩＤ結合情報保存部４５２、コンテンツ推奨情報保存部４５３、推奨広告選択挿入部４５４、広告サーバ４５５が追加されている。

本実施例では、ネット番組表の生成までは、第１の実施例と同様の動作を行うが、テレビ受信機４４１～４５０とモバイル端末４０１～４１０がそれぞれの有するＩＤ（個別識別データ）により連結されている。また、それぞれのテレビ受信機４４１～４５０は、ユーザが何を視聴しているかを視聴データとして計測する機能を有しており、計測した視聴データをＴＶクラウド４３１～４３４を通して、テレビゲートウエイ４２１にアップされる。

テレビゲートウエイ４２１には、視聴データ保存部４５１、ＩＤ結合情報保存部４５２が結合されている。テレビ受信機４４１～４５０より得られた視聴データは、ＴＶクラウド４３１～４３４、テレビゲートウエイ４２１を経由して視聴データ保存部４５１に保存される。また、テレビ受信機４４１～４５０とモバイル端末４０１～４１０のＩＤの結合情報が、ＩＤ結合情報保存部４５２に補完される。

コンテンツ推奨情報保存部４５３は、視聴データ保存部４５１及びＩＤ結合情報保存部４５２の情報により、いずれのテレビ受信機がどのようなコンテンツの視聴傾向にあるかを計算し、ビデオプラットフォーム４１１～４１３に伝える。この計算は、視聴された毎のコンテンツのジャンルの視聴時間を測定する等により実現される。

一方、推奨広告選択挿入部４５４は、視聴データ保存部４５１、及び、ＩＤ結合情報保存部４５２より、いずれのテレビ受信機がどのような広告を挿入するべきかを計算し、広告サーバ４５５より望ましい広告を取得し、ビデオプラットフォーム４１１～４１３の動画コンテンツに広告を挿入する。

本発明におけるＩＤの構成と結合される例を図１４に示す。モバイル端末４０１～４１０は、ＳＰ－ＩＤ（スマートフォンＩＤ）５０１を有している。一方、テレビ受信機４４１～４５０は、ＴＶ－ＩＤ（テレビＩＤ）５１１を有している。ＳＰ－ＩＤは、ビデオプラットフォームのＩＤであるＰＦ－ＩＤとユーザのＩＤであるＵＲ－ＩＤで構成される。ＴＶ－ＩＤは、ＴＶクラウドのＩＤであるＴＣ－ＩＤと、テレビ受信機自身をデバイスとして表すＤＶ－ＩＤで構成される。ＩＤ結合情報保存部４５２には、ＳＰ－ＩＤとＴＶ－ＩＤの結合情報を示す表５２０が構成されており、テレビ受信機とモバイル端末がＩＤによって連結状態を形成している。ここで、表５２０で“〇”でしめすのが結合状態であり、“―”に示すのが非結合状態である。ここで、一つのテレビ受信機には、複数のモバイル端末の結合が行われる可能性がある。

図１５にＩＤの結合方式と、それぞれに保存されるデータを示す。

テレビ受信機１４１とスマートフォンなどのモバイル端末４０１は、テレビ受信機に表示されるＱＲコード（登録商標）等により、認証コード６１１をモバイル端末４０１へ伝える。この認証コードとテレビの対応表は、あらかじめＴＶクラウド４３１のテレビＩＤ保存部６０３に保存されている。

認証コード６１１はテレビ受信機１４１に個別付されたＴＶ―ＩＤに対応した時間時限のある認証コードである。この認証コード６１１はＴＶクラウド４３１からテレビ受信機１４１に送付される。この時ＴＶクラウド４３１は認証コード６１１とともにビデオプラットフォーム４１１へつなげるためのアドレス情報を付加してモバイル端末４０１に送付する。

認証コード６１１は、スマートフォン４０１からモバイル端末の有するＳＰ－ＩＤと共にデータ６１２として、ビデオプラットフォーム４１１へ送出され、ビデオプラットフォーム４１１は、取得した認証コード６１１と、連動するモバイル端末４０１のＳＰ－ＩＤを基に、所有する顧客データ保存部６０１からユーザ属性を取得し、ＳＰ－ＩＤを合わせえてデータ６１３としてテレビゲートウエイ４２１へ送信する。

テレビゲートウエイは、認証コード、ＳＰ－ＩＤ、ユーザ属性をデータ６１３として取得した後、認証コードを基にＴＶクラウド４３１に問い合わせて、対応するＴＶ－ＩＤを取得する。ここで、ＴＶクラウド４３１は、管理下のテレビ受信機のＴＶ－ＩＤを管理しており、ＴＶ－ＩＤと認証コードの対応表をテレビＩＤ保存部６０２に有し、いずれのテレビ受信機が結合の対象となったかを認証コードより取得している。データ６１２並びにデータ６１３の中に配置される認証コードは認証コード６１１と同じものである。

これらの動作により、テレビゲートウエイ４２１は、ＴＶ－ＩＤとＳＰ－ＩＤの結合を行い、ＩＤ結合情報保存部６０２に保存する。更に、ＴＶ－ＩＤとＳＰ－ＩＤの結合情報をパスキー６２１によってビデオプラットフォーム４１１へ通知する。パスキー６２１は、ＩＤ結合情報保存部６０２のデータベースのキーとなっており、パスキー６２１をテレビゲートウエイ６１３へ送付することにより、ＳＰ－ＩＤとＴＶ－ＩＤ及びユーザ属性を取り出すことが出来る。

以上の動作により、ＩＤによってモバイル端末とテレビ受信機が連結される。なお、ＩＤ結合後は、テレビゲートウエイ４２１よりビデオプラットフォーム４１１へ転送されたパスキー６２１により、以後、ビデオプラットフォーム４１１は、ターゲットとなるテレビ受信機へのサービスを展開することが出来る。なお、パスキー６２１は、ＳＰ－ＩＤとの対応が分かるように、顧客データ保存部６０１に保存される。

なお、図１５は、ビデオプラットフォーム４１１の場合に関して説明したが、ビデオプラットフォーム４１２及び４１３においても同様の動作を行う。

ＩＤが結合した場合のネット番組表を図１６に示す。

ＴＶ－ＩＤとＳＰ－ＩＤが結合状態にあると、ＳＰ－ＩＤの構成要素であるＰＦ－ＩＤにより、視聴しているユーザが、いずれのビデオプラフォームの顧客であるかが判別できるため、ネット番組表に、対応するビデオプラットフォームにより構成されるチャンネルをアクセスしやすい位置に提示する。例えば、図１６の場合、ＳＰ－ＩＤ５０１に、ビデオプラットフォーム４１１のＩＤが含まれている場合、ビデオプラットフォーム４１１により提供されるチャンネルを初期画面として提示することで、ユーザに選択を容易にする。また、ＴＶ－ＩＤにより特定されるテレビ受信機の視聴データより、視聴傾向を推察することで、推薦コンテンツ７０１、７０２、７０３を同時に表示する。

このように、ＩＤが結合していることにより、ユーザに対して、対応するビデオプラットフォームのコンテンツを優先して提示することで、ビデオプラットフォームより提供されるサービスを容易に得られる。

図１７には、動画コンテンツとＷｅｂサービスとを連動させた画面の表示例を示す。

ＴＶ－ＩＤ５１１とＳＰ－ＩＤ５０１とが結合状態にある場合、ＴＶ－ＩＤで示されるテレビ受信機に、ＳＰ－ＩＤ５０１で示されるビデオプラットフォームにリンクされたＷｅｂサービス画面を自動的に表示する。これにより、ユーザは、動画視聴だけでなく、関連情報やＥＣサイトの商品説明などのサービスを受けることが出来る。また、モバイル端末上で表示される、モバイルアプリ８１２と動画画面８１１を連動させることができ、通常のリモコンではできない、動画コンテンツ選択方法が可能となる。例えば、モバイルアプリのニュースサイトの興味あるニュースをモバイル端末上でタッチすることで、関連する動画コンテンツをテレビ受信機上で再生することができ、従来にないコンテンツ選択が可能となる。一方で、モバイルアプリでＥＣサイトを表示し、興味ある商品をタップすることで、動画による詳細な商品説明を見る等、これまでにないユーザ体験を得られる。

図１８を用いて以上の動作を詳しく説明する。

ビデオプラットフォーム４１１の動画コンテンツがＷｅｂサイト９０１にリンクしているとき、ビデオプラットフォーム４１１よりＷｅｂリンク情報９０２がテレビゲートウエイ４２１に入力される。また、従来通りのタイムテーブル２０１、コンテンツメタデータ２０２、バナーデータ２０３に加えて、推薦コンテンツデータ９０１がテレビゲートウエイ４２１に入力される。

テレビゲートウエイ４２１は、結合されているＴＶ-ＩＤ５０１とコンテンツ選択データ２０４、更に、推薦コンテンツデータ９０１から作られた推奨メタデータ９１１とＷｅｂリンク情報から得られたリンク先ＵＲＬをＴＶクラウド４３１へ転送する。ＴＶクラウド４３１は、ネット番組表に推奨コンテンツ表示データ９１３を合わせて生成し、テレビ受信機４４１へ送付される。その際、動画コンテンツにリンクできるように、チャンネル、時間情報と合わせてリンク先ＵＲＬをテレビ受信機４４１へセットする。テレビ受信機４４１は、特定のチャンネルと視聴している時間帯を基にユーザがリンクボタン等を押下することで、リンク先ＵＲＬの示すＷｅｂコンテンツをテレビ画面上に表示する。

尚、モバイルアプリと連動する場合は、Ｗｅｂサイト９０１からモバイルアプリをモバイル端末４０１にダウンロードした後、モバイルアプリの操作結果とＳＰ－ＩＤをビデオプラットフォーム４１１へ送信する。その後、ビデオプラットフォーム４１１よりパスキーとモバイル操作をテレビゲートウエイ４２１へ送信することで、テレビの共通操作コード９０３に変換し、ＴＶクラウド４３１で更にテレビの操作コードに変換しテレビ受信機４４１を制御する。パスキーはＳＰ－ＩＤとの対応表である顧客データ保存部６０１より得られる。

以上は、ビデオプラットフォーム４１１に関して説明したが、他のビデオプラットフォームに関しても同様の動作となる。また、ＴＶクラウド４１１以外のＴＶクラウド、テレビ受信機４４１以外のテレビ受信機に関しても同様の動作となる。

図１９に本発明に基づくコンテンツの推薦、広告の挿入の説明を示す。

視聴データ保存部４５１及びＩＤ結合情報保存部４５２の情報が、コンテンツ推薦情報保存部４５３に入力され、テレビの視聴傾向を計算し、推薦コンテンツ、望ましい広告の候補を決定する。コンテンツ推薦情報保存部４５３の情報により、推奨される広告を広告サーバ４５５より取得し、推奨広告選択挿入部４５４の出力により、ビデオプラットフォーム４１１が動画コンテンツへ広告を挿入する。

一方で、受信側広告挿入部では、コンテンツ推薦情報保存部４５３の情報に基づいて、広告サーバ４５５より望ましい広告を転送し、受信側広告挿入部４５６の出力により、テレビ受信機１４１で動作コンテンツに広告を挿入する。

例えば、ビデオプラットフォーム４１１が、マルチキャスト方式により動画配信を行う場合には、テレビ受信機毎に個別の広告を挿入することが出来ない。この場合は、一旦、ビデオプラットフォーム４１１により、広告を挿入し、共通の広告を配信した後、テレビ受信機側で個別に望ましい広告を上書きする。この動作により、個別のテレビ受信機に対してターゲティング広告の様なユーザにあった広告提示を行うことが出来る。

（第３の実施形態）
図２０に本発明に関わる第３の実施例の構成図を示す。

第２の実施例との違いは、ビデオプラットフォーム４１１～４１３とテレビゲートウエイ１４１２の間に変換部１４１１～１４１３が挿入されている。本実施例では、異なるビデオプラットフォーム４１１～４１３から出力される、異なるデータを、あらかじめ変換部１４１１～１４１３により共通データに変換することで、テレビゲートウエイ１４１２へ入力する。この処理により、テレビゲートウエイ１４１２は、共通のデータを処理するため、処理負荷を低減することが出来る。この変換部１４１１～１４１３はテレビゲートウエイ１４１２の入力インタフェースとしてテレビゲートウエイ１４１２の中に設けても良いし、ビデオプラットフォーム４１１～４１３の出力インタフェースとしてビデオプラットフォーム４１１～４１３の中に設けても良い。

第２の実施例が、異なるデータを直接ビデオプラットフォーム４１１～４１３から入力され、内部で共通データに変換していたのに対し、第３の実施例では、共通データへの変換を各ビデオプラットフォーム４１１～４１３に依頼している。これにより、負荷を分散することが出来る。

図２１に本発明に関わる第３の実施例の動作説明図を示す。

図１８に示す、第２の実施例の動作説明と異なるのは、変換部１４１１が挿入されている点である。変換部１４１１により、データ変換が行われ、テレビゲートウエイ４２１に、共通バナーデータ１５０３、共通コンテンツデータ１５０１、共通Ｗｅｂリンク情報１５０２が、テレビゲートウエイ４２１に入力される。

これらの変換データは、いずれの異なるビデオプラットフォーム４１１～４１３も変換部１４１１～１４１３により、共通のフォーマットのデータとなる。

第１の実施例から第３の実施例におけるモバイル端末４０１～４１０の定義はカメラを含みネットワーク接続可能な装置でありスマートフォン、パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等のコンピュータ端末も含む。

第１の実施例から第３の実施例におけるモバイル端末４０１～４１０とテレビ受信機１４１～１５０、４４１～４５０との連携のためＱＲコードをテレビ受信機１４１～１５０、４４１～４５０に表示させているが、ＱＲコード以外でも良い。例えばＰＩＮコードのような数字群や、バーコード等モバイル端末４０１～４１０が光学的検出して認証コード６１１とともにビデオプラットフォーム４１１へつなげるためのアドレス情報を検出できれば良い。さらに上記実施例では光学的検出している例をあげたが、モバイル端末４０１～４１０とテレビ受信機１４１～１５０、４４１～４５０間で連携できる機能を用いれば良い。例えば、無線により接続や有線による接続で認証コード６１１とともにビデオプラットフォーム４１１へつなげるためのアドレス情報を送れれば良い。

異なる性能や機能を有するテレビ受信機、それぞれのビデオプラットフォームが異なる場合でも、単一のフォーマットの入力を介して、すべてのテレビ受信機にコンテンツを提示する用途に適用できる。また、テレビ受信機とモバイル端末の連携により、モバイル端末を介した高度なサービスに適用することができ、さらに、スマートフォンのようなモバイル端末との連携により、既存リモコンでは不可能な高度な連動動作の用途に適用できる。

１０１～１０８ ＣＳＰ
１１１～１１３、４１１～４１３ ビデオプラットフォーム
１２１、４２１ テレビゲートウエイ
１３１、４３１～４３４ ＴＶクラウド
１４１～１５０、４４１～４５０ テレビ受信機
４０１～４１０ モバイル端末
１１０９ａ 負荷平準化部
１４１１～１４１３ 変換部

Claims (9)

1. サーバを介して配信されるコンテンツ情報を受信するテレビ受信機において、
   当該テレビ受信機が有する固有の情報に基づいて、前記サーバにおける負荷の平準化を図る負荷平準化部を備える、
   ことを特徴とするテレビ受信機。
2. 前記負荷平準化部は、前記固有の情報を設定情報とし、前記固有の情報を状況に応じて変更する、
   ことを特徴とする請求項１に記載のテレビ受信機。
3. 前記負荷平準化部は、前記テレビ受信機が有する固有の情報に基づいて、前記サーバに対してアクセスする時刻を他のテレビ受信機とは異なる時刻にシフトさせる、
   ことを特徴とする請求項１または２に記載のテレビ受信機。
4. 前記負荷平準化部は、前記固有の情報として前記テレビ受信機に個別に付された識別情報を用いる、
   ことを特徴とする請求項３に記載のテレビ受信機。
5. 前記負荷平準化部は、前記サーバからコンテンツ情報を取得するために、前記サーバに対してアクセスする時刻を他のテレビ受信機とは異なる時刻にシフトする、
   ことを特徴とする請求項３または４に記載のテレビ受信機。
6. 前記負荷平準化部は、前記サーバに対してコンテンツ情報の更新をチェックするために、前記サーバに対してアクセスする時刻を他のテレビ受信機とは異なる時刻にシフトする、
   ことを特徴とする請求項３ないし５の何れか一項に記載のテレビ受信機。
7. 前記負荷平準化部は、前記サーバに対してデータをアップロードする際に、前記固有の情報として、データの保持に関する設定情報とサーバアクセス分散設定情報との少なくとも何れか一方を用いて、データを一時的にバッファリングする、
   ことを特徴とする請求項１または２に記載のテレビ受信機。
8. 前記負荷平準化部は、前記固有の情報として、データを保持すべき最大時間と、保持すべきデータの最大容量と、の少なくとも何れか一方を用いる、
   ことを特徴とする請求項７に記載のテレビ受信機。
9. ビデオプラットフォームから受信したコンテンツ情報を変換してテレビ受信機に対して配信するサーバと、
   前記サーバを介して配信されるコンテンツ情報を受信する請求項１ないし８のいずれか一項に記載のテレビ受信機と、
   を備えることを特徴とするテレビシステム。

Images