以下の実施形態においては、電子機器をテレビジョン放送受信装置に適用した例について説明する。しかしながら、以下に示す実施形態は、電子機器をテレビジョン受信装置に制限するものではなく、他の電子機器に適用しても良い。
(第1の実施形態)
図1は、第1の実施形態にかかる、ネットワーク環境の構成例を示した図である。図1に示すネットワーク環境では、家庭内(宅内)ネットワーク120内に、テレビジョン放送受信装置100と、ルータ130と、が配置されている。
さらに、図1に示すネットワーク環境では、家庭内ネットワーク120の外部ネットワークに、公衆ネットワーク150を介して、連携サーバ161、181と、コンテンツ配信サーバ171と、が接続されている。
放送局190は、放送波を用いて番組等を提供する。また、放送局190が放送する放送波には、コンテンツ(番組)の他に、当該コンテンツ(番組)と連携するアプリケーションの取得先のURL等が含まれている。なお、本実施形態は、放送波に含まれる情報を、コンテンツ(番組)と連携するアプリケーションの取得先のURLに制限するものではなく、コンテンツと連携するアプリケーションでもよい。このように、放送波に含まれる情報は、コンテンツとの連携を実現する情報であれば良い。
第1の連携サーバ161は、放送波を介してコンテンツ(番組)を提供する放送局190、又は放送局190が認可した事業者が設けたサーバであり、アプリケーション記憶装置162と接続されている。アプリケーション記憶装置162は、コンテンツ(番組)と連携する(HTML)アプリケーション等を記憶する。
従来、コンテンツとHTMLアプリケーションとを連携させるハイブリッドキャスト(登録商標)という放送が提案されている。ハイブリッドキャストにおいては、放送波でコンテンツを受信する際に、放送波に含まれているイベントも受信していた。
一方、テレビジョン放送受信装置100では、コンテンツを表示する際に、当該コンテンツに連携するHTMLアプリケーションを実行させておく。そして、テレビジョン放送受信装置100で実行されているアプリケーションは、コンテンツの放送中に、イベントを受信したタイミングで、受信したイベントに対応する関数を実行する。これにより、コンテンツの放送中に、コンテンツとHTMLアプリケーションの連携を実現していた。
これに対して、ビデオ・オン・デマンド等でコンテンツを利用する場合、ユーザは時間に制限されずに、当該コンテンツを視聴できる。コンテンツを配信するためのフォーマットは、ハイブリッドキャストなどの放送波と規格等が異なるため、イベントの配信が難しい。そこで、本実施形態では、公衆ネットワーク150からのコンテンツ、及び放送波からコンテンツの、どちらであっても、当該コンテンツと連携するアプリケーションを実行可能なテレビジョン放送受信装置100について説明する。
コンテンツ配信サーバ171は、例えばビデオ・オン・デマンドなどを用いて、公衆ネットワーク150を介して接続された電子機器に対してコンテンツ(番組)を配信するサーバであり、コンテンツ記憶装置172と接続されている。コンテンツ記憶装置172は、テレビジョン放送受信装置100等の電子機器に送信するコンテンツ(番組)を記憶する。当該コンテンツは、例えば、すでに放送波で放送されたコンテンツ(番組)等が考えられる。
第2の連携サーバ181は、公衆ネットワーク150を介してコンテンツ(番組)を提供するビデオ・オン・デマンドの事業者が設けたサーバであり、アプリケーション記憶装置182と接続されている。アプリケーション記憶装置182は、コンテンツ(番組)と連携する(HTML)アプリケーション等を記憶する。さらに、アプリケーション記憶装置182は、(HTML)アプリケーションが、コンテンツと連携するためのイベント情報を記憶している。
テレビジョン放送受信装置100は、(図示しない)アンテナが実装されており、アンテナを介して、放送局190から受信した放送波に含まれているコンテンツ(番組)の表示、記憶等を行う。
また、テレビジョン放送受信装置100は、公衆ネットワーク150を介して、コンテンツ配信サーバ171、第1の連携サーバ161又は第2の連携サーバ181等との間でデータを送受信する。これにより、テレビジョン放送受信装置100は、コンテンツ配信サーバ171から送信されたコンテンツを取得できる。さらには、テレビジョン放送受信装置100は、放送波又は受信したデータから抽出されたURLに基づいて、第1の連携サーバ161又は第2の連携サーバ181にアクセスして、コンテンツと連携するアプリケーション(HTMLアプリケーション)を取得できる。
本実施形態は、コンテンツ(番組)と連携するアプリケーションとして、HTMLアプリケーションを適用する例について説明するが、HTMLアプリケーションに制限するものではなく、コンテンツ(番組)と連携して表示可能なソフトウェア、又はコンテンツであれば良い。
本実施形態は、HTMLアプリケーションとして、テレビジョン放送受信装置100側で表示するためのアプリケーションについて説明するが、HTMLアプリケーションの表示先をテレビジョン放送受信装置100に制限するものではなく、家庭内ネットワーク120内に存在するスマートフォンやタブレット端末などの携帯端末であってもよい。
放送波から受信したコンテンツを表示する場合、テレビジョン放送受信装置100は、放送波から抽出されたURLから、第1の連携サーバ161にアクセスして、HTMLアプリケーションを取得する。一方、ビデオ・オン・デマンドで取得したコンテンツを表示する場合、テレビジョン放送受信装置100は、コンテンツと共に受信したデータから抽出されたURLから、第2の連携サーバ181にアクセスして、HTMLアプリケーション、及びイベント情報を取得する。なお、イベント情報については後述する。
図2は、本実施形態にかかるテレビジョン放送受信装置100のブロック構成を例示した図である。図2に示されるように、テレビジョン放送受信装置100は、放送受信部201と、通信部202と、映像コンテンツ取得部203と、映像識別部204と、映像処理部205と、表示部206と、イベント情報記録制御部207と、イベント情報記録部208と、イベント制御部209と、HTMLブラウザ部210と、を備えている。
放送受信部201は、(図示しない)アンテナを介して、デジタルテレビジョン放送信号を受信する。さらに、放送受信部201は、受信したデジタルテレビジョン放送信号を復調してから、映像コンテンツ取得部203に出力する。
通信部202は、公衆ネットワーク150を介して接続された電子機器との間でデータの送受信を行う。例えば、通信部202は、コンテンツ配信サーバ171から、コンテンツを受信する。また、通信部202は、第1の連携サーバ161から、HTMLアプリケーション250を受信し、第2の連携サーバ181から、HTMLアプリケーション250やイベント情報を受信する。
HTMLアプリケーション250は、HTMLで記載されたアプリケーションであって、放送波やビデオ・オン・デマンドなどのコンテンツと連携する(例えば、進行にあわせて内容が変化する)アプリケーションとする。HTMLアプリケーションの具体的な取得手法の例については後述する。イベント情報は、HTMLアプリケーションをコンテンツと連携させるためのイベントが示された情報とする。本実施形態のイベント情報は、コンテンツの再生を開始してからの経過時間と、当該経過時間で処理を実行するためのイベントと、が少なくとも対応付けられている。なお、イベント情報の詳細については後述する。
映像コンテンツ取得部203は、(映像)コンテンツを取得する。映像コンテンツ取得部203は、放送波及び公衆(通信)ネットワーク150のうち、どちらを介してもコンテンツを取得可能とする。
つまり、本実施形態のテレビジョン放送受信装置100は、チャンネル操作に従って、放送波から受信したコンテンツ(番組)を表示するほか、ビデオ・オン・デマンド用のメニュー画面からコンテンツの選択操作を受け付けた場合に、選択されたコンテンツの表示を行う。
さらには、映像コンテンツ取得部203は、コンテンツと連携する連携アプリケーション(HTMLアプリケーション)の取得先となるURLも取得する。放送波からコンテンツを受信する場合、映像コンテンツ取得部203は、連携アプリケーション(HTMLアプリケーション)の取得先となるURLを、当該放送波から取得する。
また、公衆ネットワーク150を介してコンテンツを受信する場合、映像コンテンツ取得部203は、連携アプリケーション(HTMLアプリケーション)の取得先となるURLを、ユーザの入力操作から取得する。また、映像コンテンツ取得部203は、連携アプリケーション(HTMLアプリケーション)の取得先となるURLを、コンテンツと共にコンテンツ配信サーバ171から取得してもよい。
本実施形態では、連携アプリケーション(HTMLアプリケーション)をコンテンツと連携させるために必要なイベント情報の存在の有無を、取得したURLに所定の文字列が含まれているか否かに応じて判断する。
本実施形態における、ビデオ・オン・デマンド(VoD)などの公衆ネットワーク150を介してコンテンツを取得する場合の、連携アプリケーション(HTMLアプリケーション)の取得先となるURLの例を説明する。当該URLとしては、例えば、“http://www.xxxxxxxx.com/hybridcast/app1/index.html?em=em.js”がある。
当該URLのうち、“http://www.xxxxxxxx.com/hybridcast/app1/index.html”がHTMLアプリケーションの取得先となるURLであり、“em=em.js”がイベント情報を示したスクリプトとする。つまり、当該URLにイベント情報を識別させる“em=”が含まれているか否かにより、イベント情報が含まれているか否かを判断する。例えば、映像コンテンツ取得部203は、連携アプリケーションの取得先となるURLとして、“http://www.xxxxxxxx.com/hybridcast/app1/index.html?em=em.js”を取得した場合に、イベント情報“em.js“が含まれていると判断する。
映像コンテンツ取得部203は、アプリケーションの取得先のURLを取得できた場合に、通信部202を介して、取得先のURLから、連携アプリケーション(HTMLアプリケーション)を受信する。
映像コンテンツ取得部203は、アプリケーションの取得先のURLに、イベント情報が含まれていると判断した場合、当該イベント情報を受信する。また、映像コンテンツ取得部203は、イベント情報を、公衆ネットワーク150を介して第2の連携サーバ181から受信する。なお、取得したイベント情報は、イベント情報記録制御部207に出力される。
本実施形態では、映像コンテンツ取得部203が、イベント情報を識別させるためのパラメータが設定されたURLにアクセスした場合に、第2の連携サーバ181から、HTMLアプリケーションと、イベント情報が示されたスクリプト“em.js”と、を取得できる。
なお、本実施形態では、イベント情報を識別させるためのパラメータとして、“em=”という識別子を用いたが、識別子の種類を制限するものではなく、他の文字列でも良い。さらには、パラメータとして設定する手法を制限するものではない。
変形例としては、ユーザの操作等に従って、第2の連携サーバ181に指定されたURLにアクセスした際に、HTMLアプリケーションを取得すると共に、複数のデータを取得する。そして、変形例の映像コンテンツ取得部203が、取得したHTMLアプリケーション内の記載から、複数のデータに含まれているイベント情報を特定しても良い。
図3は、変形例のHTMLアプリケーションの一部を例示した図である。図3に示されるHTMLアプリケーションにおいては、行301の“script”タグにイベント情報のスクリプトが設定されている。さらに、一般のスクリプトタグと区別するためにtypeとして“text/eventmessage”が指定されている。これにより、取得された複数のデータから、イベント情報を特定できる。なお、図3は、typeの文字列を制限するものではなく、その他の文字列でも良い。さらには、スクリプトタグ以外のタグで記述する(metaタグ、linkタグなど)で、スクリプト情報を設定しても良い。変形例においても、取得したイベント情報は、イベント情報記録制御部207に出力される。
映像識別部204は、表示部206に表示するために映像コンテンツ取得部203が取得したコンテンツが、放送波から取得したか、又はビデオ・オン・デマンドなどの公衆ネットワーク150を介して取得したかを識別する。識別手法は、どのような手法でもよく、例えば、映像コンテンツ取得部203が取得したHTMLアプリケーションのタグの記述から判定しても良い。例えばHTMLアプリケーションが、ハイブリッドキャスト(放送波)の場合、objectタグのtypeが“video/x-iptvf-broadcast”か否かで判別する。さらには、映像コンテンツ取得部203に対して、コンテンツの取得元が放送波か否かを問い合わせても良い。なお、判定手法は、objectタグで判断する手法等に制限するものではなく、HTMLアプリケーションにイベント情報が指定されていた場合には、コンテンツが放送波であっても、ビデオ・オン・デマンドと同様の制御を行っても良い。
映像識別部204は、ビデオ・オン・デマンド(VoD)などの公衆ネットワーク150を介してコンテンツを取得した場合、当該コンテンツとHTMLアプリケーションで連携可能か否かを判定する。本実施形態では、HTMLアプリケーションを取得できたか否かを判定すると共に、イベント情報を取得できたか否かを判定する。
映像処理部205は、取得したコンテンツに記述されているビデオ要素の内容に基づいて映像データを取得し、取得した映像データを処理した後、表示部206に再生する。
イベント情報記録制御部207は、通信部202が受信したイベント情報を、イベント情報記録部208に記録する。取得したイベント情報には、経過時間と、当該経過時間で実行するイベント(処理)と、コンテンツを識別するためのIDと、が少なくとも対応付けられている。
イベント情報記録部208は、イベント情報一覧を記録する。図4は、本実施形態のイベント情報記録部208のテーブル構造を例示した図である。図4に示されるように、イベント情報記録部208は、“送出元ID”、“グループID”、“メッセージID”、“Version”、“time”、“メッセージデータ”と、を対応付けて記憶している。“送出元ID”、“グループID”、及び“メッセージID”は、コンテンツを特定するための識別情報とする。
“time”は、コンテンツが再生されてからの経過時間とし、コンテンツの先頭からの経過時間がms単位で記録されている。“メッセージデータ”は、“time”で示された経過時間が経過した後に、実行されるイベント(処理)の内容を表す文字列が示されている。なお、本実施形態は、上述した構成を用いた例について説明するが、コンテンツを特定するための識別情報や、経過時間を示すための情報として、他の態様を用いても良い。例えば、本実施形態では、経過時間を格納する例について説明するが、当該コンテンツが放送波で配信された時に、当該イベントを送信した時刻でも良い。この場合、イベント制御部209は、コンテンツの開始時刻との差分に基づいて、経過時間を算出し、当該イベントを制御する。
HTMLブラウザ部210は、HTMLアプリケーションなどの様々なコンテンツを表示する。例えば、HTMLブラウザ部210は、映像コンテンツ取得部203が取得した情報(URL)に基づいて、表示するコンテンツ(番組)に連携するアプリケーション(HTMLアプリケーション)を表示する。また、HTMLブラウザ部210は、放送中やビデオ・オン・デマンドのコンテンツに重畳してアプリケーションを表示しても良い。
イベント制御部209は、コンテンツの表示中に、HTMLブラウザ部210上で実行されているHTMLアプリケーションを、当該コンテンツと連携したイベント、及びユーザの操作に従って処理が実行されるように制御する。
ところで、イベント制御部209は、例えば、ハイブリッドキャスト(登録商標)ではイベントの受信と、イベントに基づく処理のために以下のAPIが、定義されている。
・addGeneralEventMessageListener(param, listener)
・removeGeneralEventMessageListener(param, listener)
paramには監視するイベントメッセージの条件が指定され、listenerにはイベントが発火した際に呼ばれるリスナが指定されている。
ビデオ・オン・デマンド等のコンテンツ再生時には、これらAPIを、コンテンツの経過時間に合わせて呼び出すことで、当該コンテンツの放送時と同様に、アプリケーションの連携を実現できる。これにより、ビデオ・オン・デマンドでコンテンツ連携を行うために新たなAPIを用意する必要がなくなるため、開発負担を軽減すると共に、放送時に利用したアプリケーションの再利用性を向上させることができる。
例えば、イベント制御部209は、コンテンツを放送波から受信した場合に、当該コンテンツの再生時に、通信部202が第1の連携サーバ161からイベントを受信した際に、当該イベントに基づく処理(関数)が、HTMLブラウザ部210上で実行された連携アプリケーションで実行されるように制御する。
他方では、イベント制御部209は、公衆ネットワーク150を介してコンテンツを受信すると共に、コンテンツと連携するためのアプリケーション及びイベント情報が存在すると判定された場合に、イベント情報記録部208に格納されているイベント情報を読み込み、読み込んだイベント情報に従って、映像処理部205が処理した映像コンテンツが再生されている時に、再生されてからの経過時間に応じて、当該経過時間とイベント情報記録部208で対応付けられた、イベントに基づく処理(関数)がアプリケーションで実行されるよう制御する。これにより、ビデオ・オン・デマンド等の公衆ネットワーク150を介したコンテンツの受信でも、放送波によるコンテンツ連携と同様の処理を実現できる。
表示部206は、コンテンツや、HTMLブラウザ部210で実行されたアプリケーションを表示する。
次に、本実施形態のテレビジョン放送受信装置100がコンテンツを再生するまでに実行する処理について説明する。図5は、本実施形態のテレビジョン放送受信装置100における上述した処理の手順を示すフローチャートである。
まず、映像コンテンツ取得部203が、表示部206に表示するためのコンテンツを取得する(ステップS501)。
次に、映像識別部204が、取得したコンテンツは放送波から取得したか否かを判定する(ステップS502)。取得したコンテンツを放送波から取得した場合(ステップS502:Yes)、映像識別部204からの指示により、HTMLブラウザ部210は、放送向けモード(例えば、ハイブリッドキャストモード)で起動する(ステップS503)。なお、ステップS503以降は、ハイブリッドキャストが行われるものとする。
一方、映像識別部204が、取得したコンテンツは放送波からの取得ではない(公衆ネットワーク150を介して取得した)と判定した場合(ステップS502:No)、HTMLアプリケーション及びイベント情報を取得可能か否か判定する(ステップS504)。本実施形態では、HTMLアプリケーション及びイベント情報の取得が可能か否かを、HTMLアプリケーションのURLに基づいて判定する。なお、判定手法は既に説明したので、省略する。
HTMLアプリケーション及びイベント情報のうちいずれか一つ以上を取得できないと判定した場合(ステップS504:No)、HTMLブラウザ部210を起動させず、表示部206は、取得したコンテンツの、通常のVoD(ビデオ・オン・デマンド)再生制御を行う(ステップS505)。
映像識別部204が、HTMLアプリケーション及びイベント情報を取得可能と判定した場合(ステップS504:Yes)、通信部202が、HTMLアプリケーション及びイベント情報を受信する(ステップS506)。そして、イベント情報記録制御部207が、受信したイベント情報を、イベント情報記録部208に記録する(ステップS507)。
その後、映像識別部204からの指示により、HTMLブラウザ部210は、VoDモードで起動し、終了する(ステップS508)。
VoDモードで起動した場合、イベント情報の取り扱いが、放送向けモードとは異なる。つまり、放送向けモードでは、リアルタイムに受信していたイベントをトリガーとして、当該イベントに対応する処理(関数)を実行していた。これに対して、VoDモードでは、イベント制御部209が、予め取得したイベント情報に格納されている経過時間と、イベントと、の対応一覧を、イベント情報記録部208から呼び出し、コンテンツの再生中に、経過時間と対応するイベントを用いて、上述したAPIを呼び出して、コンテンツとアプリケーションとの連携を実行する。
次に、本実施形態のテレビジョン放送受信装置100がコンテンツの再生時に実行する処理について説明する。図6は、本実施形態のテレビジョン放送受信装置100における上述した処理の手順を示すフローチャートである。
まず、HTMLブラウザ部210は、ユーザの操作に従って、HTMLアプリケーションを起動する(ステップS601)。次に、HTMLブラウザ部210は、図5で起動したモードが、放送向けモードか否かを判定する(ステップS602)。
HTMLブラウザ部210は、放送向けモードの場合(ステップS602:Yes)、HTMLアプリケーション内に記載されたAPI、例えばハイブリッドキャストの場合、addGeneralEventMessageListener()を用いて、イベント受信時に実行される関数を登録する(ステップS603)。
そして、HTMLブラウザ部210で実行されているHTMLアプリケーションは、放送波に含まれているイベントを待ち受ける(ステップS604)。なお、イベントを待ち受けしている間に、受信したコンテンツは、表示部206に表示されているものとする。
そして、HTMLブラウザ部210で実行されているHTMLアプリケーションは、放送受信部201がイベントを受信したか否かを判定する(ステップS605)。受信していない場合(ステップS605:No)、ステップS607に遷移する。
一方、HTMLブラウザ部210で実行されているHTMLアプリケーションは、イベントを受信したと判定した場合(ステップS605:Yes)、当該イベントを受信した際に実行するものとして、登録されている関数を実行する(ステップS606)。このように、放送波からコンテンツを取得する場合、当該コンテンツに連動する処理を実行するためのイベントを、リアルタイムで受信する。そして、イベント制御部209が、受信したイベントに従ってリアルタイムに、当該イベントに対応する関数が実行されるように制御する。関数の実行結果は、表示部206がコンテンツに重畳して表示してもよい。
その後、HTMLブラウザ部210で実行されているHTMLアプリケーションは、コンテンツが終了したか否かを判定する(ステップS607)。終了していないと判定した場合(ステップS607:No)、再びステップS605から処理を開始する。
一方、HTMLブラウザ部210で実行されているHTMLアプリケーションは、コンテンツが終了したと判定した場合(ステップS607:Yes)、処理を終了する。
また、ステップS602において、放送向けモードではないと判定した場合(ステップS602:No)、HTMLブラウザ部210で実行されているHTMLアプリケーションは、イベント情報記録部208に記憶されているイベント情報を読み出す(ステップS608)。さらにHTMLアプリケーション内の記載に従って、実行される関数を登録する(ステップS609)。
その後、HTMLブラウザ部210で実行されているHTMLアプリケーションは、コンテンツが再生されてからの経過時間の監視を開始する(ステップS610)。
その後、HTMLブラウザ部210で実行されているHTMLアプリケーションは、経過時間に対応したイベントがイベント情報内にあるか否かを判定する(ステップS611)。イベント情報内にないと判定した場合(ステップS611:No)、ステップS613に遷移する。
一方、HTMLブラウザ部210で実行されているHTMLアプリケーションは、経過時間に対応したイベントがイベント情報内にあると判定した場合(ステップS611:Yes)、当該イベントに対応するものとして、登録されている関数を実行する(ステップS612)。
その後、HTMLブラウザ部210で実行されているHTMLアプリケーションは、イベント情報に含まれている全てのイベントが終了したか否かを判定する(ステップS613)。終了していないと判定した場合(ステップS613:No)、再びステップS611から処理を開始する。
一方、HTMLブラウザ部210で実行されているHTMLアプリケーションは、イベント情報に含まれている全てのイベントが終了したと判定した場合(ステップS613:Yes)、処理を終了する。
上述した実施形態では、コンテンツの提供者が運用する第2の連携サーバ181が提供するアプリケーション及びイベント情報を利用することを前提としているため、誤動作が生じるのを抑止できる。
(第2の実施形態)
第1の実施形態では、ビデオ・オン・デマンドの提供者側がイベント情報及びHTMLアプリケーションを提供する例について説明した。しかしながら、イベント情報及びHTMLアプリケーションを、ビデオ・オン・デマンドの提供者側で提供する例に制限するものではない。例えば、ハイブリッドキャスト時に送信されたイベントの情報を保存しても良い。そこで、第2の実施形態では、放送波から受信したイベント情報を保存する例とする。
図7は、第2の実施形態にかかるテレビジョン放送受信装置700のブロック構成を例示した図である。図7に示されるように、テレビジョン放送受信装置700は、第1の実施形態のテレビジョン放送受信装置100とは、イベント情報記録制御部207と処理が異なるイベント情報記録制御部701と、イベント情報記録部208と構成が異なるイベント情報記録部702と、イベント制御部209と処理が異なるイベント制御部703と、映像識別部204と処理が異なる映像識別部704と、を備えている点で異なる。なお、同一の構成については、同一の符号を割り当て、説明を省略する。
本実施形態では、通信部202がイベント情報を受信するのではなく、放送受信部201がイベントを受信する。そして、イベント情報記録制御部701が、受信したイベントを、イベント情報として、イベント情報記録部702に記録する。
ところで、近年、複数のチューナを搭載し、ユーザにより指定されたチャンネル及び時間帯の放送番組(コンテンツ)全てを録画する機能を備えたテレビジョン放送受信装置や、HDDレコーダが提供されている。これらの電子機器は、それぞれのチューナで指定時間帯において常時放送波を受信し、受信した放送波のデータを、(図示しない)記憶装置の所定の録画領域に録画し、該録画領域の終端まで達すると、該録画領域の先頭から上書き録画を行っている。
このため、本実施形態のテレビジョン放送受信装置700は、放送コンテンツのみならず、放送波に重畳されているイベントの情報も記録しておく。イベントの情報は、コンテンツ(番組)と比べて、保存に必要な領域が非常に小さい。このため、テレビジョン放送受信装置700は、仮に、時間経過によりコンテンツが自動的に削除(上書き録画)されても、イベントの情報は、例えば他の録画領域に移動させる処理を行って一定期間保存しておく。そして、ユーザが、当該コンテンツをビデオ・オン・デマンドで視聴する際に、保存されているイベント情報を用いて、アプリケーションを連携させる。
イベント情報記録制御部701は、受信したイベントを、イベント情報記録部702に記録する。その際に、イベント情報記録制御部701は、コンテンツの放送開始時刻とイベントを受信した時刻との差分から経過時間を算出し、当該イベントと対応付けて記録する。さらには、イベント情報記録制御部701は、コンテンツを識別するための情報も、イベントと対応付けて記録する。
図8は、本実施形態にかかるイベント情報記録部702のテーブル構造を示した図である。図8に示されるように、イベント情報記録部702は、“チャンネルID”と、“プログラムID”と、“Version”と、“time”と、“メッセージデータ”と、を対応付けて記憶する。“Version”、“time”、及び“メッセージデータ”は第1の実施形態と同様として説明を省略する。“チャンネルID”、及び“プログラムID”は、放送されたコンテンツを識別するための識別情報とする。
さらに、映像識別部704は、公衆ネットワーク150を介して受信したコンテンツに連携するアプリケーションに関する情報に基づいて、イベント情報記録部702に当該コンテンツに対応するイベント情報が存在するか否かを確認する。
本実施形態では、通信部202が、VoDサービスのページ上からダウンロード可能なコンテンツをユーザの選択操作に応じて再生する際に、ユーザがコンテンツを選択したURLに基づいて、コンテンツと連携するアプリケーションを受信する例とする。そして、映像識別部704は、アプリケーションの取得先のURLに基づいて、再生するコンテンツのイベント情報が、イベント情報記録部702に格納されているか否かを判定する。即ち、VoDサービスのウェブサーバ内においては、ダウンロード可能な(ビデオ)コンテンツに該URLが対応付けられており、ユーザによる選択操作に応じてURLが指定される。
次に、ビデオ・オン・デマンド(VoD)などの公衆ネットワーク150を介してコンテンツを取得する場合の、連携アプリケーション(HTMLアプリケーション)の取得先となるURLの例について説明する。当該URLとしては、例えば、“http://www.xxxxxxxx.com/hybridcast/app2/index.html?chid=0x12&prgid=0x12345678”がある。
当該URLのうち、“http://www.xxxxxxxx.com/hybridcast/app2/index.html”がHTMLアプリケーションの取得先となるURLであり、“chid=0x12&prgid=0x12345678”がコンテンツを識別するための情報とする。つまり、映像識別部704は、イベント情報記録制御部701を介して、チャンネルID=”0x12”で、プログラムID=“0x12345678”のレコードがイベント情報記録部702に格納されているか否かを判定する。そして、映像識別部704は、この判定結果により、コンテンツの連携に用いるイベント情報が含まれているか否かを判断する。つまり、チャンネルID=“0x12”で、プログラムID=“0x12345678”のレコードがイベント情報記録部702に存在した場合に、当該コンテンツのイベント情報が存在すると判定する。
なお、本実施形態では、HTMLアプリケーションの取得先となるURLを用いた例について説明した。しかしながら、本実施形態は、URLを用いる場合に制限するものではない。
変形例としては、ユーザの操作等に従って、第2の連携サーバ181に指定されたURLにアクセスした際に、HTMLアプリケーションを取得する。そして、映像識別部704が、取得したHTMLスクリプトを参照して、イベント情報記録部702にイベント情報が格納されているか否かを判断しても良い。
図9は、変形例のHTMLアプリケーションの一部を例示した図である。図9に示されるHTMLアプリケーションにおいては、行801の“meta”タグにチャンネルIDが設定されている。さらに、行802の“meta”タグにプログラムIDが設定されている。そして、映像識別部704は、これらHTMLアプリケーションに設定されているチャンネルID及びプログラムIDのレコードが、イベント情報記録部702に存在するか否かにより、イベント情報の有無を判定する。
なお、本変形例及び第2の実施形態では、チャンネルID及びプログラムIDを用いてコンテンツを識別しているが、識別の手法を制限するものではなく、例えば実際に放送で利用されている“サービスID”、“オリジナルネットワークID”、“イベントID”等で番組を識別してもよい。さらには、放送局独自の識別情報を用いて、コンテンツを識別してもよい。
次に、本実施形態のテレビジョン放送受信装置700がコンテンツの放送時にイベント情報を記録するまでの処理について説明する。図10は、本実施形態のテレビジョン放送受信装置700における上述した処理の手順を示すフローチャートである。
まず、放送受信部201が、放送波を受信する(ステップS1001)。放送波に含まれているコンテンツは、HDDに記録制御されるものとして説明を省略する。
次に、イベント情報記録制御部701が、受信した放送波に含まれているイベント情報を取得する(ステップS1002)。その際に、イベント情報記録制御部701は、放送波のチャンネルIDとプログラムIDとを取得しておく。
そして、イベント情報記録制御部701は、受信したイベントを、コンテンツの放送が開始されてからの経過時間、及びチャンネルID及びプログラムIDと対応付けて、イベント情報記録部702に記憶する(ステップS1003)。
次に、本実施形態のテレビジョン放送受信装置700がコンテンツを再生するまでに実行する処理について説明する。図11は、本実施形態のテレビジョン放送受信装置700における上述した処理の手順を示すフローチャートである。
まず、映像コンテンツ取得部703が、表示部206に表示するためのコンテンツを取得する(ステップS1101)。
次に、映像識別部704が、取得したコンテンツは放送波から取得したか否かを判定する(ステップS1102)。取得したコンテンツを放送波から取得した場合(ステップS1102:Yes)、映像識別部704からの指示により、HTMLブラウザ部210は、放送向けモード(例えば、ハイブリッドキャストモード)で起動する(ステップS1103)。なお、ステップS1103以降は、ハイブリッドキャストが行われるものとする。
一方、映像識別部704が、取得したコンテンツは放送波からの取得ではない(公衆ネットワーク150を介して取得した)と判定した場合(ステップS1102:No)、ユーザの操作によりHTMLアプリケーションを取得した場合について説明する。その後、映像識別部704は、コンテンツに一致する放送番組のイベント情報がイベント情報記録部702に記憶されているか否かを判定する(ステップS1104)。
イベント情報が記録されていないと判定した場合(ステップS1104:No)、HTMLブラウザ部210を起動させず、表示部206は、取得したコンテンツの、通常のVoD再生制御を行う(ステップS1105)。
映像識別部704が、イベント情報が記憶されていると判定した場合(ステップS1104:Yes)、映像識別部204からの指示により、HTMLブラウザ部210は、VoDモードで起動し、終了する(ステップS1106)。
また、本実施形態では、イベント情報記録部702にイベント情報が含まれていない場合に、通常のVoD再生制御を行う例について説明するが、このような手法に制限するものではなく、イベント情報がイベント情報記録部702に格納されていない場合に、イベント情報を第2の連携サーバ181から取得しても良い。
近年、放送を見逃した場合などに、ネットワークを介してコンテンツを視聴する、いわゆるビデオ・オン・デマンドを利用する傾向が高い。しかしながら、放送がハイブリッドキャストである場合、放送の場合と同様のサービスを得ることが難しかった。
これに対して、上述した実施形態のテレビジョン放送受信装置においては、上述した構成を備えて、放送でイベントを受信する構成を装置内でエミュレートすることで、放送の場合と同様のサービスを得ることができる。つまり、コンテンツを視聴するユーザに対して、提供するサービスの種類を向上させることができる。これにより、コンテンツを視聴するユーザの、満足度を向上させるとともに、利便性を向上させることができる。
さらには、放送波で提供されるコンテンツと連携するHTMLアプリケーションと、公衆ネットワーク150を介して提供されるコンテンツと連携するHTMLアプリケーションと、は、イベント情報を除けばそれほど差異はないため、公衆ネットワーク150を介したコンテンツ配信用(例えばVoD用)のHTMLアプリケーションを作成する負担を軽減できる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。