JP2017079423A - 放送受信装置 - Google Patents

Abstract

【課題】必要性の低いデータのダウンロードを回避し、処理負荷を軽減する放送受信装置を提供する。
【解決手段】放送受信装置は、第１の番組と、第１の番組に続いて同じチャンネルで放送される第２の番組に対応付けられたデータをダウンロードするための制御情報とを受信する受信部と、視聴履歴を記録する視聴履歴記録部と、制御情報を受信した場合にＳ１００；ＹＥＳ、視聴履歴に基づいてデータをダウンロードするか否かを判定し、データをダウンロードすると判定した場合にＳ１２０；ＹＥＳ、制御情報に基づいてデータをダウンロードするＳ１５０ダウンロード処理部とを備える。
【選択図】図２

Description

本発明は、放送受信装置に関する。

電波（放送信号）による放送とインターネットなどのネットワークを利用する通信との融合によるサービスの開発が進んでいる。このようなサービス体系の一つとしては、例えばHybridcast（登録商標）が挙げられる。これによれば、デジタル放送される番組に対応付けられたアプリケーションをインターネット経由で放送受信装置へダウンロードして画面上に当該アプリケーションによるサービス画像を合成することにより、例えば、ＳＮＳ（Social Networking Service）などのインターネット上のサービス等を連携させた形態での放送が実現できる。

なお、アプリケーションをダウンロードするための情報と各アプリケーションの開始時刻および終了時刻とを含む複数のアプリケーション情報を受信し、ダウンロード実行手段は、現時刻では放送されていない番組の放送前に、当該放送前の番組に対応するアプリケーションに係る前記アプリケーション情報に含まれる開始時刻に従って、サーバから前記放送前の番組に対応するアプリケーションのダウンロードを実行する放送受信装置が知られている（特許文献１参照）。

特開２０１４‐６４２１０号公報

上述したような放送受信装置によるアプリケーションのダウンロードは、当該アプリケーションをダウンロード可能である旨等を知らせるアプリケーション情報を放送信号から受信したタイミングや、ユーザが視聴するチャンネルを切り替えたタイミング等で自動的に実行されていた。しかしながら、アプリケーションの配信元となるサーバやネットワークや放送受信装置の処理負荷を考慮すると、ユーザにとって必要性の低いアプリケーションのダウンロードは可能な限り避けるべきであると言える。

本発明は上述の課題に鑑みてなされたものであり、ユーザにとって必要性の高いデータをダウンロードすることにより、前記負担を軽減させる放送受信装置を提供する。

本発明の態様の一つは、放送受信装置は、第１の番組と、前記第１の番組に続いて同じチャンネルで放送される第２の番組に対応付けられたデータをダウンロードするため制御情報とを受信する受信部と、視聴履歴を記録する視聴履歴記録部と、前記制御情報を受信した場合に、前記視聴履歴に基づいて前記データをダウンロードするか否かを判定し、前記データをダウンロードすると判定した場合に、前記制御情報に基づいて前記データをダウンロードするダウンロード処理部と、を備える。

本態様によれば、番組の視聴履歴に基づいてデータのダウンロードの要否を判定するため、ユーザにとって必要性の低いデータのダウンロードを回避し、前記負担を軽減することができる。

本発明の実施形態として、前記ダウンロード処理部は、前記視聴履歴に基づいて前記第２の番組を視聴する傾向がある場合に、前記データをダウンロードするとしてもよい。
当該構成によれば、第２の番組を視聴する傾向があると推測される場合に前記データをダウンロードすることができる。
また、本発明の実施形態として、前記ダウンロード処理部は、前記視聴履歴の前記第２の番組の視聴回数が、前記第２の番組と同じ時間帯に各チャンネルで放送される番組毎の視聴回数の中で最も多い場合に、前記第２の番組を視聴する傾向がある、としてもよい。
また、前記ダウンロード処理部は、前記視聴履歴の前記第２の番組の視聴回数が所定の基準回数を超えている場合に、前記第２の番組を視聴する傾向がある、としてもよい。
これら構成によれば、第２の番組を視聴する傾向が所定以上にある場合に前記データをダウンロードすることができる。

また、本発明の実施形態として、前記ダウンロード処理部は、前記視聴履歴に基づいて前記第１の番組と同じチャンネルと異なる他のチャンネルで前記第２の番組と同じ時間帯に放送される第３の番組を視聴する傾向がある場合、前記第２の番組の放送開始時刻の所定時間前になっても前記第１の番組と同じチャンネルから前記他のチャンネルへの切り替えが実行されなければ、前記データをダウンロードするとしてもよい。
当該構成によれば、ほぼ確実に第２の番組を視聴すると言える状態になってから前記データをダウンロードすることができる。

また、本発明の実施形態として、放送受信装置は、視聴予約の情報を記録する視聴予約情報記録部を備え、前記ダウンロード処理部は、前記視聴予約の情報に基づいて前記第１の番組と同じチャンネルと異なる他のチャンネルで前記第２の番組と同じ時間帯に放送される第４の番組の視聴予約がされている場合には、前記視聴履歴にかかわらず前記データをダウンロードしないと判定するとしてもよい。
当該構成によれば、前記データの無駄なダウンロードを回避できる。

また、本発明の実施形態として、前記ダウンロード処理部は、所定時間内でのチャンネルの切り替えを繰り返している期間は、前記データをダウンロードしないと判定するとしてもよい。
当該構成によれば、第２の番組を視聴するか否か判らない状況で前記データをダウンロードすることを回避できる。

本発明の技術的思想は、放送受信装置以外の態様によっても実現される。つまり、放送受信装置が実行する各工程を含む方法（データ取得方法）や、このような方法をハードウェア（放送受信装置）に実行させるためのプログラムや、当該プログラムを記憶したコンピュータ読取可能な記憶媒体を、それぞれ発明として捉えることができる。

放送受信装置の概略を例示するブロック図。 第１実施形態にかかるフローチャート。 各チャンネルの時間帯毎の番組の放送スケジュールの一部を例示する図。 第２実施形態にかかるフローチャート。 第３実施形態にかかるフローチャート。

以下、図面を参照しながら本発明の実施形態を更に説明する。
図１は、実施形態にかかる放送受信装置１１の概略を例示するブロック図である。放送受信装置１１を、デジタルテレビジョンと称してもよい。図１に示すように、放送受信装置１１は、アンテナ１２で受信したデジタルテレビジョン放送信号を、入力端子１３を介してチューナ部１４に供給することにより、所望のチャンネルの放送信号（番組を放送するための放送信号）を選局して受信する。

放送受信装置１１は、チューナ部１４で選局された放送信号を、復調部１５に供給して復調し、デスクランブラ部１６で必要に応じて暗号を復号した後、分離（Ｄｅｍｕｘ）部１７に出力する。分離（Ｄｅｍｕｘ）部１７は、デスクランブラ部１６から出力された放送信号を種別ごとに分離し、分離された映像信号及び音声信号を映像／音声デコーダ１８に出力する。映像／音声デコーダ１８は、分離された映像信号及び音声信号（番組を構成する映像および音声）を復号し、映像信号を合成処理部１９に出力し、音声信号を音声処理部２０に出力する。合成処理部１９は、映像／音声デコーダ１８から供給される映像信号に、後述するブラウザ２１を介して入力される映像データまたは画像データを重畳して出力している。

放送受信装置１１は、合成処理部１９から出力した映像信号を、映像処理部２２に供給する。映像処理部２２は、入力された映像信号を、例えば液晶パネル等を有する映像表示部２３で表示可能なフォーマットのアナログ映像信号に変換している。放送受信装置１１は、映像処理部２２から出力されたアナログ映像信号を、映像表示部２３に供給して映像表示に供する。音声処理部２０は、入力された音声信号を、スピーカ２４で再生可能なフォーマットのアナログ音声信号に変換している。そして、この音声処理部２０から出力されたアナログ音声信号が、スピーカ２４に供給されることにより音声再生に供される。これにより、ユーザは所望の番組を放送受信装置１１を用いて視聴することができる。

また、映像信号及び音声信号の他に、放送信号にはメディア情報や番組情報など番組関連情報（ＳＩ／ＰＳＩ）が含まれている。この番組関連情報（ＳＩ／ＰＳＩ）は、分離（Ｄｅｍｕｘ）部１７より分離され、ＳＩ／ＰＳＩ取得部２５により解釈され、ＲＡＭ（Random Access Memory）２６に格納される。さらに、放送信号には放送受信装置１１で実行されるアプリケーションに関するアプリケーション情報（番組に対応付けられたアプリケーションをダウンロードするためのアプリケーション情報）が重畳されている。このアプリケーション情報は、分離（Ｄｅｍｕｘ）部１７により分離され、アプリダウンローダ２７に出力される。すなわち、チューナ部１４、復調部１５、分離（Ｄｅｍｕｘ）部１７等が「受信部」として機能することになる。本実施形態で言うアプリケーションは、特許請求の範囲における「番組に対応付けられたデータ」の一種である。また、アプリケーション情報は、特許請求の範囲における「データをダウンロードするための制御情報」の一種である。

アプリダウンローダ２７は「ダウンロード処理部」としても機能する。アプリダウンローダ２７は、分離（Ｄｅｍｕｘ）部１７で分離されて取得したアプリケーション情報に従って、ネットワークインターフェース２８を介してネットワーク２９上のサーバ３０からアプリケーションをダウンロードし、ＲＡＭ２６もしくはFlashMemory３１等の記憶媒体へ記録する。

アプリケーションは、例えばＨＴＭＬによって記述されている。アプリケーションとしては、例えば、選挙や自然災害（台風、地震、水害など）発生の際などに、放送画面に字幕情報を表示するアプリケーションが挙げられる。また、アプリケーションとしては、放送局が作成する情報だけではなく、例えば、番組内容に関連してＳＮＳなどに一般視聴者が投稿した情報を一覧表示するアプリケーションが挙げられる。本実施形態が想定するアプリケーションには、これら具体例に限らず、ユーザが視聴する番組と何らかの関連付けや対応付けがされたアプリケーションの全てが含まれる。

ダウンロードされたアプリケーションは、ユーザの指示もしくはアプリケーション情報に記載された起動条件に従ってブラウザ２１上で実行されて映像データまたは画像データとして映像／音声デコーダ１８から供給される映像信号に重畳される。

放送受信装置１１は、上記した受信動作を含むその全ての動作を統括的に制御するＣＰＵ（Central Processing Unit）３２を備える。ＣＰＵ３２は、上述したＲＡＭ２６やＣＰＵ３２が実行する制御プログラムを格納したFlashMemory３１とともに制御部３３を構成する。むろん、制御部３３は、ユーザが操作する不図示のリモートコントローラ（以下、リモコン）からの制御信号に応じた処理を実行可能である。

制御部３３には、ネットワークインターフェース２８が接続されている。ネットワークインターフェース２８は、入出力端子を介して外部のネットワーク２９に接続されている。そして、ネットワーク２９には、当該ネットワーク２９を介した通信機能を利用して各種のアプリケーションを提供するためのサーバ３０が接続されている。このため、制御部３３は、ネットワークインターフェース２８及びネットワーク２９を介して、サーバ３０にアクセスして情報通信を行なうことにより、サーバ３０が提供しているアプリケーションを利用することができる。

次に、放送信号によるアプリケーション情報の伝送方式について説明する。アプリケーション情報には、例えば、アプリケーション名（番組に対応付けられたアプリケーションを識別するための名称）、アプリケーションを表すアイコンのイメージ、アプリケーションの取得先（例：インターネット等）、アプリケーション位置（ＵＲＩ（Uniform Resource Identifier）で取得するファイルの位置）が含まれている。なお、アプリケーション情報に含まれる情報は、これらに限られない。

アプリケーション情報の放送信号による伝送方式としては、トランスポートストリーム中のＡＩＴテーブルを用いる方式、ＸＭＬ形式を用いてＡＩＴ情報を表現（ＸＭＬ−ＡＩＴ）し、放送中のカルーセル（ＤＳＭ−ＣＣ：Digital Storage Media-Command and Control：サーバ−端末間制御プロトコル）を用いてＸＭＬ−ＡＩＴファイルを伝送する方式、ネットワーク２９上のサーバ３０からＸＭＬ−ＡＩＴファイルを取得する方法がある。ＡＩＴテーブルで表現する際には、上記の情報を記述子の形で表現する。

次に、アプリダウンローダ２７によるアプリケーションのダウンロードの実行について説明する。基本的には、アプリダウンローダ２７は、分離（Ｄｅｍｕｘ）部１７により分離されたアプリケーション情報を受信した場合に、ネットワークインターフェース２８を介してネットワーク２９上のサーバ３０からアプリケーションのダウンロードを試みる。

第１実施形態：
図２は、第１実施形態にかかるフローチャートを示している。当該フローチャートは、制御部３３やアプリダウンローダ２７が協働して実現する処理の一部分（データ取得方法）を示している。当該フローチャートが実行される前提として、ユーザは、放送受信装置１１により選局中の或るチャンネル（例えば、図３に示すチャンネル１）で現在受信されている番組（例えば、番組Ａ）を視聴中であるとする（後述の図４，５のフローチャートに関しても同様）。番組Ａは、第１の番組の一例である。図３は各チャンネルの時間帯毎の番組の放送スケジュールの一部を例示しており、知られているように放送受信装置１１は、このような情報を放送信号から得られるＥＰＧ情報等に基づいて認識可能である。

番組Ａの視聴中、アプリダウンローダ２７は、現在選局されているチャンネル１により番組Ａの次に放送される番組（番組Ｃ、図３参照。）に対応するアプリケーション情報を取得できたか否か判定する（ステップＳ１００）。番組Ｃは、チャンネル１で第１の番組に続いて放送される第２の番組の一例である。図２（および図４，５）では、番組Ｃを次番組と表記している。アプリダウンローダ２７は、番組Ｃに対応するアプリケーション情報、つまり番組Ｃに対応付けられたアプリケーションをダウンロードするためのアプリケーション情報を取得済みか否かを、例えば、取得済みのアプリケーション情報のアプリケーション名やＥＰＧ情報等に基づいて判定する。アプリダウンローダ２７は、番組Ｃに対応するアプリケーション情報を取得済みと判定するまでステップＳ１００の判定を繰り返し、そのようなアプリケーション情報を取得済みと判定した場合は、ステップＳ１１０へ進む。

アプリダウンローダ２７は、ステップＳ１１０において過去の番組の視聴履歴を参照し、ステップＳ１２０では、当該視聴履歴に基づいて、番組Ｃに対応付けられたアプリケーションをダウンロードするか否かを判定する。そして、当該判定の結果に基づいて、ステップＳ１５０へ進む。つまりステップＳ１２０からは、アプリケーションをダウンロードすると判定した場合にステップＳ１５０へ進み、一方、アプリケーションをダウンロードしないと判定した場合にステップＳ１３０へ進む。

制御部３３は、過去（例えば、過去数か月間）における番組の視聴履歴を所定の記憶媒体（例えば、FlashMemory３１や不図示のハードディスク等）へ、随時更新しながら記録している。例えば、視聴履歴としては、ユーザが放送受信装置１１で視聴した番組のタイトルや放送日時を始めとした情報が記録されている。この意味で、当該所定の記憶媒体は、視聴履歴を記録する「視聴履歴記録部」に該当する。

ステップＳ１２０における視聴履歴に基づく具体的な判定方法として、アプリダウンローダ２７は、視聴履歴に基づいて、番組Ｃを視聴する傾向（番組Ｃの視聴傾向）がある（所定以上の視聴傾向がある）と判定した場合に、番組Ｃに対応付けられたアプリケーションをダウンロードすると判定する。番組Ｃの視聴傾向があるとは、例えば、視聴履歴の番組Ｃの放送時間帯における他チャンネルの番組の視聴回数との比較で、番組Ｃの視聴回数が最も多い場合が挙げられる。つまり、番組Ｃと同じ時間帯に各チャンネルで放送される番組毎の視聴履歴に記録されている視聴回数の中で、番組Ｃの視聴回数が最も多い場合に、番組Ｃの視聴傾向があると言える。あるいは、視聴履歴の番組Ｃの視聴回数が所定の基準回数を超えている場合に、番組Ｃの視聴傾向があると判定してもよい。

ステップ１５０では、アプリダウンローダ２７は、番組Ｃに対応するアプリケーション情報に基づいて、番組Ｃに対応付けられたアプリケーションをダウンロードする。つまり、取得済みの番組Ｃに対応するアプリケーション情報にはアプリケーション位置等の情報が含まれているため、当該アプリケーション位置等に基づいて番組Ｃに対応付けられたアプリケーションの配信元（サーバ３０）へアクセスし、サーバ３０から、当該番組Ｃに対応付けられたアプリケーションをダウンロードする。

一方、ステップ１２０からステップＳ１３０へ進んだということは、アプリダウンローダ２７は、視聴履歴に基づいて、ユーザによる視聴傾向が高い別の番組（番組Ｃではない別の番組）の存在を認知したと言える。ステップＳ１２０，Ｓ１３０，Ｓ１４０の流れを説明する場面においては、番組Ｂを現在放送中のチャンネル２で番組Ｃと同じ時間帯に放送される番組Ｄ（図３参照）が、アプリダウンローダ２７が視聴履歴に基づいて視聴傾向が番組Ｃよりも高い（視聴傾向が所定の基準よりも高い）と判定した番組であると仮定する。番組Ｄは、チャンネル１と異なる他のチャンネル（チャンネル２）で第２の番組と同じ時間帯に放送される第３の番組の一例である。

ステップＳ１３０では、アプリダウンローダ２７は、ユーザによるリモコンの操作等により、チューナ部１４が選局するチャンネルがチャンネル１からチャンネル２へ切り替えられたか否か判定する。チャンネル２への切り替えが実行されていない場合には、アプリダウンローダ２７は、ステップＳ１４０において、番組Ｃの放送開始時刻（例えば、２０時）の所定時間前（例えば、３分前）に達したか否か判定し、番組Ｃの放送開始時刻の所定時間前に達するまでステップＳ１３０，Ｓ１４０の判定を繰り返す。ステップＳ１４０において“Ｙｅｓ”と判定した場合、つまり番組Ｃの放送開始時刻の所定時間前になってもチャンネル２への切り替えが実行されなければ、アプリダウンローダ２７は、番組Ｃに対応付けられたアプリケーションをダウンロードすると判定し、ステップＳ１５０へ進む。

このように第１実施形態によれば、放送受信装置１１は、過去の番組の視聴履歴に応じて、現在よりも後に放送される番組に対応付けられたアプリケーションをダウンロードするか否かを分岐することができる。特に、視聴履歴に基づいて視聴傾向が所定の基準よりも高いと判定される番組に対応付けられたアプリケーションをダウンロードするようにしたため、ユーザにとって必要性の低いアプリケーションのダウンロードを回避できる。これにより、サーバ３０やネットワーク２９や放送受信装置１１の処理負荷を軽減することができる。

また、ステップＳ１２０，Ｓ１３０，Ｓ１４０の流れによれば、視聴履歴から現在視聴中の番組Ａと同じチャンネル１で次に放送される番組Ｃの視聴傾向は高いとは言えないが、チャンネルの切り替えが実行されないために、そのまま番組Ｃが視聴される可能性が高いと推測される場合にも、番組Ｃに対応付けられたアプリケーションがダウンロードされる。そのため、ユーザの利便性が向上する。

ただし、第１実施形態において、ステップＳ１３０，Ｓ１４０は必須ではなく、ステップＳ１２０で“Ｎｏ”と判定した場合は、そのまま、番組Ｃに対応付けられたアプリケーションをダウンロードせずに当該フローチャートを終えてもよい。仮にその後、過去の視聴傾向に反してユーザが番組Ｃを視聴した場合、番組Ｃに対応付けられたアプリケーションはダウンロードされていないため放送受信装置１１上で当該アプリケーションを実行できないが、番組Ｃの視聴に際して当該アプリケーションは絶対に必要なものではないため、ユーザの大きな損失とはならない。むろん、当該フローチャートとは別に、放送受信装置１１は、ユーザの任意の操作に応じて、番組Ｃに対応付けられたアプリケーションをダウンロードすることは可能である。また、当該フローチャートでは、番組Ｄの視聴傾向が高いと判定した状況でチャンネル２への切り替えがされた（ステップＳ１３０において“Ｙｅｓ”の判定をした）場合の処理は特に記載していないが、むろんこの場合、放送受信装置１１は、番組Ｄに対応付けられたアプリケーションをダウンロードすることが可能である。

本発明は上述の実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば後述するような実施形態も採用可能である。以下の実施形態の説明においては、第１実施形態と共通する事項は説明を省略する。複数の実施形態を適宜組み合わせた構成も本発明の開示範囲に入る。

第２実施形態：
図４は、第２実施形態にかかるフローチャートを示している。当該フローチャートは、制御部３３やアプリダウンローダ２７が協働して実現する処理の一部分（データ取得方法）を示している。ステップＳ２００，Ｓ２１０は、図２のステップＳ１００，Ｓ１１０と同じである。

ステップＳ２２０では、アプリダウンローダ２７は、番組のいわゆる視聴予約の情報を参照して、今後放送される番組であって視聴予約されている番組を特定する。視聴予約は、ユーザにより任意に設定された予約であり、制御部３３は、視聴予約の情報を所定の記憶媒体（例えば、FlashMemory３１や不図示のハードディスク等）に記録している。この意味で、当該所定の記憶媒体は、視聴予約の情報を記録する「視聴予約情報記録部」にも該当する。

ステップＳ２３０では、アプリダウンローダ２７は、視聴履歴および視聴予約に基づいて、番組Ｃに対応付けられたアプリケーションをダウンロードするか否か判定する。ステップＳ２３０からは、アプリケーションをダウンロードすると判定した場合にステップＳ２４０へ進み、一方、アプリケーションをダウンロードしないと判定した場合に当該フローチャートを終える。ステップＳ２４０は、図２のステップＳ１５０と同じである。

ステップＳ２３０における具体的な判定方法として、アプリダウンローダ２７は、視聴履歴に基づいて番組Ｃの視聴傾向が所定の基準よりも高いと判定した場合であっても、ステップＳ２２０で特定した番組（視聴予約されている番組）に番組Ｃと同じ時間帯に放送される番組（例えば、番組Ｄ）が含まれている場合には、番組Ｃに対応付けられたアプリケーションをダウンロードしないと判定する。なお、視聴履歴に基づいて番組Ｃの視聴傾向が所定の基準よりも高いと判定した場合であって、ステップＳ２２０で特定した番組（視聴予約されている番組）に番組Ｃと同じ時間帯に放送される番組が含まれていなければ、番組Ｃに対応付けられたアプリケーションをダウンロードすると判定する。つまり、アプリダウンローダ２７は、番組の視聴予約の情報に基づいて、現在視聴中のチャンネル１と異なる他のチャンネルで第２の番組（番組Ｃ）と同じ時間帯に放送される第４の番組（第２実施形態の説明の便宜上、例えば、チャンネル２で放送される番組Ｄ）の視聴予約がされていると判定した場合には、視聴履歴（番組Ｃの視聴傾向）にかかわらず、番組Ｃに対応付けられたアプリケーションをダウンロードしないと判定する。

このように第２実施形態によれば、放送受信装置１１は、視聴履歴から見て視聴傾向が高い番組であっても、視聴予約の状況からその番組を視聴しないと判断できる番組については、対応付けられたアプリケーションをダウンロードしないため、ユーザにとって必要性の低いアプリケーションのダウンロードを回避できる。

第２実施形態ではフローチャートに表現していないが、アプリダウンローダ２７は、ステップＳ２３０において“Ｎｏ”の判定をした後、視聴予約されている番組（前記の例では番組Ｄ）について、その放送前のタイミングでその番組に対応付けられたアプリケーションをダウンロードすることが可能である。また、ステップＳ２３０において、視聴履歴に基づいて番組Ｃの視聴傾向が所定の基準よりも高いと判定しなかった場合は、番組Ｃに対応付けられたアプリケーションをダウンロードしない判定となるが（ステップＳ２３０において“Ｎｏ”）、ステップＳ２２０で特定した番組（視聴予約されている番組）に番組Ｃと同じ時間帯に放送される番組が含まれておらず、かつ、図２のステップＳ１３０，Ｓ１４０の判定を経た上であれば、ステップＳ２４０へ進むとしてもよい。つまり、現在視聴中のチャンネル１で後に放送される番組Ｃの視聴傾向が低く、番組Ｃと同じ放送時間帯に他チャンネルで放送される番組に視聴予約がされておらず、かつ、視聴傾向が高い番組を放送する他チャンネルへの切り替え（チャンネル１からチャンネル２への切り替え等）が番組Ｃの放送開始時刻の所定時間前になっても実行されなければ、番組Ｃに対応付けられたアプリケーションをダウンロードするとしてもよい（第１実施形態と第２実施形態との組み合わせ）。

第３実施形態：
図５は、第３実施形態にかかるフローチャートを示している。当該フローチャートは、制御部３３やアプリダウンローダ２７が協働して実現する処理の一部分（データ取得方法）を示している。ステップＳ３００，Ｓ３１０，Ｓ３２０，Ｓ３３０，Ｓ３４０は、図２のステップＳ１００，Ｓ１１０，Ｓ１２０，Ｓ１３０，Ｓ１４０と同じである。

ステップＳ３２０における“Ｙｅｓ”の判定に従ってステップＳ３２５へ進んだアプリダウンローダ２７は、現在、所定時間内でのチャンネルの切り替えを繰り返している期間（ザッピング期間）であるか否か判定する。アプリダウンローダ２７は、ユーザによるリモコンの操作等によりチューナ部１４が選局するチャンネルが所定時間内（例えば、３０秒以内）に切り替わる状態が継続している間はザッピング期間であると判定し、ザッピング期間ではないと判定したときに、ステップＳ３２５からステップＳ３５０へ進む。ステップＳ３５０は、図２のステップＳ１５０と同じである。

このように第３実施形態によれば、放送受信装置１１は、視聴履歴に基づいて視聴傾向が所定の基準よりも高いと判定される番組（番組Ｃ）に対応付けられたアプリケーションをダウンロードする場合であっても、視聴する番組が定まらないザッピング期間中は、当該アプリケーションをダウンロードしないと判定する。つまり、当該視聴傾向が高い番組Ｃを視聴する状況が整うまで（ザッピング期間が終わるまで）は番組Ｃに対応付けられたアプリケーションのダウンロードを保留するため、結果的に、真に必要なアプリケーションのみダウンロードすることができる。なお第３実施形態ではフローチャートに表現していないが、アプリダウンローダ２７は、ステップＳ３２５において“Ｎｏ”の判定をしたときに選局されているチャンネルが、ステップＳ３２０で視聴傾向が高いと判定した番組Ｃの放送チャンネル（チャンネル１）と異なる場合は、その後に番組Ｃが視聴されるとは言えないため、ステップＳ３５０へは進まない。この場合、ステップＳ１３０（図２）で“Ｙｅｓ”の判定をした後と同様に、放送受信装置１１は、現在選局されているチャンネル（例えば、チャンネル２）で放送される番組に対応付けられたアプリケーションをダウンロードすることが可能である。

また、このような第３実施形態に第２実施形態を組み合わせることも可能である。つまり、アプリダウンローダ２７は、図５のフローチャートの中でも視聴予約の情報を参照し、現在視聴しているチャンネル１で後に放送される番組（番組Ｃ）が、視聴履歴から見て視聴傾向が高い番組であっても、視聴予約の状況から番組Ｃを視聴しないと判断できる場合には、この番組Ｃに対応付けられたアプリケーションをダウンロードしないようにする。また、放送受信装置１１は、ニュースや天気予報等の放送時間が比較的短い（例えば、放送時間が５分以内である）番組については、番組に対応付けられたアプリケーションをダウンロードする対象から除外するとしてもよい。このように放送時間が短い番組については、そもそも関連するアプリケーションの実行が望まれない傾向があるからである。

なお、放送受信装置１１はデジタルテレビジョンに限定されない。放送受信装置１１は、放送信号を受信し、またネットワークを介して外部からデータ（例えば、アプリケーション）をダウンロード可能な機能を有する装置によって具現化される。放送受信装置１１は、例えば、ＨＤＤレコーダ、チューナ、セットトップボックス等であってもよい。本発明における、番組に対応付けられたデータには、これまで説明したようなアプリケーションには該当しないデータ、例えば、単に放送画面に重畳されて表示されるデータ等も含まれる。

また、放送受信装置１１が番組に対応付けらたデータ（例えば、アプリケーション）をダウンロードするという概念には、ネットワークを介した通信によりサーバからデータを取得する処理以外に、放送局から放送される放送信号を受信し、当該放送信号に重畳されているデータを抽出する処理も含むものとする。この場合、放送局がデータの配信元となる。

１１…放送受信装置、１４…チューナ部、２７…アプリダウンローダ、２９…ネットワーク、３０…サーバ

Claims (7)

1. 第１の番組と、前記第１の番組に続いて同じチャンネルで放送される第２の番組に対応付けられたデータをダウンロードするため制御情報とを受信する受信部と、
   視聴履歴を記録する視聴履歴記録部と、
   前記制御情報を受信した場合に、前記視聴履歴に基づいて前記データをダウンロードするか否かを判定し、前記データをダウンロードすると判定した場合に、前記制御情報に基づいて前記データをダウンロードするダウンロード処理部と、
   を備えることを特徴とする放送受信装置。
2. 前記ダウンロード処理部は、前記視聴履歴に基づいて前記第２の番組を視聴する傾向がある場合に、前記データをダウンロードする、ことを特徴とする請求項１に記載の放送受信装置。
3. 前記ダウンロード処理部は、前記視聴履歴の前記第２の番組の視聴回数が、前記第２の番組と同じ時間帯に各チャンネルで放送される番組毎の視聴回数の中で最も多い場合に、前記第２の番組を視聴する傾向があるとする、ことを特徴とする請求項２に記載の放送受信装置。
4. 前記ダウンロード処理部は、前記視聴履歴の前記第２の番組の視聴回数が所定の基準回数を超えている場合に、前記第２の番組を視聴する傾向があるとする、ことを特徴とする請求項２に記載の放送受信装置。
5. 前記ダウンロード処理部は、前記視聴履歴に基づいて前記第１の番組と同じチャンネルと異なる他のチャンネルで前記第２の番組と同じ時間帯に放送される第３の番組を視聴する傾向がある場合、前記第２の番組の放送開始時刻の所定時間前になっても前記第１の番組と同じチャンネルから前記他のチャンネルへの切り替えが実行されなければ、前記データをダウンロードする、ことを特徴とする請求項１〜請求項４のいずれかに記載の放送受信装置。
6. 視聴予約の情報を記録する視聴予約情報記録部を備え、
   前記ダウンロード処理部は、前記視聴予約の情報に基づいて前記第１の番組と同じチャンネルと異なる他のチャンネルで前記第２の番組と同じ時間帯に放送される第４の番組の視聴予約がされている場合には、前記視聴履歴にかかわらず前記データをダウンロードしないと判定する、ことを特徴とする請求項１〜請求項５のいずれかに記載の放送受信装置。
7. 前記ダウンロード処理部は、所定時間内でのチャンネルの切り替えを繰り返している期間は、前記データをダウンロードしないと判定する、ことを特徴とする請求項１〜請求項６のいずれかに記載の放送受信装置。

Images