本発明は、デジタル放送を受信し表示するデジタル放送受信装置であって、特に放送波により更新ソフトウェアを受信することで制御プログラムを更新するデジタル放送受信装置及びデジタル放送受信装置の制御方法に関する。
現在のデジタル放送は、社団法人電波産業会(ARIB:Association of Radio Industries and Businesses)の定める標準規格及び運用規定に基づいて運用されている。ARIBの定める運用規定においては、放送波を用いてデジタル放送受信装置のソフトウェアを更新する手法が規定されており、受信装置のメーカはこの規定に従って受信装置に更新ソフトウェアを送信することによってソフトウェアを更新できる。
ARIBの運用規定に基づいて更新ソフトウェアを受信装置にダウンロード送出する場合、以下のように行う。
まず、メーカはダウンロード送出させたい更新ソフトウェアを作成し、送出可能な形式に変換する。さらに、対象受信装置や送出日時、連続送出期間等のダウンロード送出についてのスケジュールを決定し、SDTT(Software Download Trigger Table)に記載し
て更新ソフトウェアと共に放送業者に提出する。
現在の運用規定では、実際に放送されるSDTTには2日分のスケジュールを記載することとなっており、受信装置はSDTTによって自身に必要な更新ソフトウェアがいつ送出されるかを認識し、ダウンロードをスケジュールする。
ここで、更新ソフトウェアのダウンロードは、ユーザに実行を意識させたり不便を与えたりせずに行われることが望ましいが、このことは以下に示す二つの問題により難しいのが実情である。
第一の問題は、更新ソフトウェアのダウンロードが行われるタイミングにおいて、使用されていないチューナが無いと更新ソフトウェアが受信できないという問題である。
ダウンロード送出は放送波の所定のチャンネルの周波数を使用して行われる。そのため、ダウンロードがスケジュールされている時間帯に、何らかの理由で受信装置の全てのチューナが更新ソフトウェアのダウンロード送出に使用されるチャンネルと異なるチャンネルの放送波を受信している場合は、ダウンロードを実行することができない。
また、ダウンロードの開始時には不使用の状態であったチューナを用いてダウンロードを開始した後に、ユーザの操作によってそのチューナが使用されることになり、ダウンロードを継続できなくなる場合もある。
第二の問題は、SDTTに記載された2日間のスケジュールでダウンロードを完了しないと、ソフトウェアの更新が出来なくなる可能性があるという問題である。
SDTTには2日分の送出スケジュールが記載されるが、それ以降の送出スケジュールを受信装置が取得する方法はなく、3日後にダウンロード送出があるかどうかは受信装置からは分からない。
上記二点の問題から、受信装置はSDTTを受信した際に、SDTTに記載される2日分の送出スケジュールの中から、自身のチューナ使用状況に応じてダウンロードのタイミングを決定する必要がある。その場合は、ダウンロードを確実なものとするために、ユーザによる受信装置の使用をある程度制限してダウンロードを行う必要があり、ユーザに不都合な状態が発生することがあった。
上記のような問題を解決するための従来技術としては、例えば、ダウンロード専用のチューナを設け、ユーザに意識させずにダウンロード及びプログラムの更新を行う技術が提案されている(特許文献1参照。)。また、2つのチューナを用意し、使用していないチューナを用いてダウンロードを行う技術も公知である(特許文献2参照。)。
特開2002−319871号公報
特開2006−197197号公報
上述した前者の従来技術においては、どの程度の頻度で発生するか分からない更新ソフトウェアのダウンロードのために専用のチューナを用意することとなりコスト上の問題が生じる。また、後者の従来技術では、2つのチューナを用意するが、片方をダウンロード専用とすれば前者の技術と同様の問題が生じ、専用としない場合は2つのチューナの両方をユーザが使用する場合にはダウンロードが実行できなくなる問題が解決できない。
本発明は、上記の従来技術の有する未解決の課題に鑑みてなされたものである。本発明の目的は、放送波により更新ソフトウェアを受信することで制御プログラムを更新するデジタル放送受信装置において、更新ソフトウェアが受信できなくなるタイミングを可及的に少なく抑えることである。また、ダウンロードによってユーザによる受信装置の操作が制限される不都合の発生を抑制することである。
本出願は、上記課題を解決するために以下の手段を採用した。すなわち、本発明に係るデジタル放送受信装置は、所定期間に所定回数に亘り繰り返し送出されるダウンロードデータを放送信号より取得することによって制御プログラムを更新するデジタル放送受信装置であって、
放送信号を受信するチューナと、
前記放送信号に含まれるダウンロード送信スケジュール情報から、ダウンロードデータの各送出が開始される時刻である送出開始時刻及び、一回の送出が完了するのに必要な期間である連続送出期間を取得するダウンロード送信情報取得部と、
前記ダウンロード送信情報取得部で取得した送出開始時刻及び連続送出期間を用いて前記ダウンロードデータを取得する処理を実行する時間を設定すると共に、前記ダウンロードデータを取得する処理と前記チューナを使用して実行される他の処理の実行時間のスケジューリングを行うスケジュール管理部と、
前記スケジュール管理部で決定されたスケジュールに従って、前記ダウンロードデータを取得する処理及び前記チューナを使用して実行される他の処理を実行する制御部と、を具備し、
前記ダウンロード送信情報取得部は、前記放送信号に含まれるダウンロード送信スケジュール情報から、さらに、前記ダウンロードデータがその全送出を終了するまでの期間及び前記ダウンロードデータの単位時間あたりの送出回数を示す送出情報パラメタを取得し、
前記送出情報パラメタの値は、前記ダウンロードデータを取得する処理と前記チューナを使用して実行される他の処理との優先度に対応付けられており、
前記スケジュール管理部は、前記ダウンロードデータを取得する処理と前記チューナを使用して実行される他の処理との実行時間が重複し両処理を同時に実行できない場合に、前記送出情報パラメタの値により定まる優先度に従って、前記ダウンロードデータを取得する処理と前記チューナを使用して実行される他の処理のどちらを優先して実行するかを決定することを特徴とする。
また、本発明に係るデジタル放送受信装置の制御方法は、所定期間に所定回数に亘り繰り返し送出されるダウンロードデータを放送信号より取得することによって制御プログラムを更新するデジタル放送受信装置の制御方法であって、
前記放送信号に含まれるダウンロード送信スケジュール情報から、ダウンロードデータの各送出が開始される時刻である送出開始時刻及び、一回の送出が完了するのに必要な期間である連続送出期間を取得するダウンロード送信情報取得ステップと、
前記ダウンロード送信情報取得ステップで取得した送出開始時刻及び連続送出期間を用いて前記ダウンロードデータを取得する処理を実行する時間を設定すると共に、前記ダウンロードデータを取得する処理とチューナを使用して実行される他の処理の実行時間のスケジューリングを行うスケジュール管理ステップと、
前記スケジュール管理ステップで決定されたスケジュールに従って、前記ダウンロードデータを取得する処理及び前記チューナを使用して実行される他の処理を実行する制御ス
テップと、を有し、
前記ダウンロード送信情報取得ステップでは、前記放送信号に含まれるダウンロード送信スケジュール情報から、さらに、前記ダウンロードデータがその全送出を終了するまでの期間及び前記ダウンロードデータの単位時間あたりの送出回数を示す送出情報パラメタを取得し、
前記送出情報パラメタの値は、前記ダウンロードデータを取得する処理と前記チューナを使用して実行される他の処理との優先度に対応付けられており、
前記スケジュール管理ステップでは、前記ダウンロードデータを取得する処理と前記チューナを使用して実行される他の処理との実行時間が重複し両処理を同時に実行できない場合に、前記送出情報パラメタの値により定まる優先度に従って、前記ダウンロードデータを取得する処理と前記チューナを使用して実行される他の処理のどちらを優先して実行するかを決定することを特徴とする。
本発明によれば、更新ソフトウェアを受信可能な期間中により確実に更新ソフトウェアのダウンロードが完了するように受信装置側でスケジュールすることが可能となる。その結果、更新ソフトウェアが受信できなくなるタイミングを可及的に少なく抑えることができる。また、ダウンロードによってユーザによる受信装置の操作が制限される不都合の発生をより確実に抑制できる。
以下に図面を参照して、この発明を実施するための最良の形態を例示的に詳しく説明する。
図1はデジタル放送受信装置の実施例1を示すブロック図である。図1において、100は、デジタル放送受信装置の全体を制御するシステム制御部、101はデジタル放送を受信するチューナ部、102はチューナ部101が受信した、多重化された放送信号を分離するデマルチプレックス部である。103はデマルチプレックス部102が分解した放送信号のうちのSDTTを処理するSDTT処理部である。なお、SDTTは本実施例においてダウンロード送信スケジュール情報に相当する。104はデマルチプレックス部102が分離した放送信号のうちのEMM(Entitlement Management Message(有料放送契
約情報や暗号を解くためのワーク鍵を含む情報))を処理するEMM処理部である。10
5はデマルチプレックス部102が分離した放送信号のうちのDSM−CC(Digital Storage Media-Command and Control)セクションを処理するDSMCC処理部である。1
06はデマルチプレックス部102が分離した放送信号のうち、映像・音声を処理するAV処理部である。107はデマルチプレックス部102が分離した放送信号のうち、SDTT以外のSI(Service Information)テーブルを処理するSI処理部である。
108は、受信装置で各種予約処理を実行するタイミングを決定するスケジュール管理部である。スケジュール管理部108において予約処理のタイミングを決定する際には、図示しないリモコン等のユーザインタフェースによりユーザから指示された予約情報が用いられる。また、その他にSDTT処理部103が解析したSDTTの情報、EMM処理部104が解析したEMM取得スケジュール情報も用いられる。109はDSMCC処理部105から受け取ったダウンロードデータを蓄積するダウンロードデータ蓄積処理部である。110はダウンロードデータを蓄積しておくダウンロードデータ蓄積部である。111はダウンロードデータ蓄積部110から更新プログラムを読み出し、システムのプログラムを更新するダウンロード更新処理部である。
なお、本実施例においては、送出側システムが以下のような更新ソフトウェアを複数回に亘って送出することを前提としている。
メーカ側は、ダウンロードの対象機種となる受信装置について、所定の手法によって、
市場に存在する、対象の更新ソフトウェアを未だダウンロードしていない(更新ソフトウェアを未取得の)受信装置の個数を把握する。そして、把握されたダウンロード未完の(更新ソフトウェアを未取得の)受信装置の個数に応じて、更新ソフトウェア送出の頻度と、送出を完了するまでの期間を調整する。なお、所定の手法は如何なる方法であってもよい。例えば、受信装置がネットワークに接続されている場合には、メーカ側が用意したサーバに対して、更新ソフトウェアを未取得の受信装置から未取得を示す情報を提供してもらうことで、個数を把握することができる。
ここで、更新ソフトウェアの送出頻度とは、繰り返し送出される更新ソフトウェアが単位時間(例えば、24時間)あたり何回送出されるかという情報である。また、送出期間とは、対象の更新ソフトウェアの送出が開始されてから、送出がすべて終了し、それ以降は受信装置が対象の更新ソフトウェアを受信できなくなるまでの期間のことを言う。なお送出期間は、SDTTに記載される、繰り返し送出のうちの一回の送出が完了する期間ではない。以下、繰り返し送出のうちの一回の送出が完了するのに必要な期間を「連続送出期間」として送出期間とは区別する。
本実施例においては、更新ソフトウェアの送出頻度と送出期間との組み合わせを示す送出情報パラメタをSDTTに付加して送出することとしている。この送出情報パラメタは、SDTTに付加されるダウンロードコンテンツ記述子内text_char領域に記載される。
図2には、本実施例における送出情報パラメタの設定内容を示す。本実施例では、更新ソフトウェアの送出頻度と送出期間との組み合わせを4段階で表現する送出情報パラメタを設定している。ここでは、市場には充分に多くのダウンロード未完装置が残存しており、ソフトウェアが短い送出間隔(高い頻度)で、充分に長い期間送出される場合の送出情報パラメタを4とする。また、市場の受信装置の50%がダウンロードを完了しており、送出頻度は初期の50%とされ、2週間程度で送出が停止される可能性がある場合の送出情報パラメタを3とする。同様に、市場の受信装置の75%がダウンロードを完了しており、送出頻度は初期の25%とされ、1週間程度で送出が停止される可能性がある場合の送出情報パラメタを2とする。同様に、市場のダウンロード未完装置は10%以下となり、送出頻度は初期の20%とされ、現在送出中のSDTT記載のスケジュール以降はソフトウェア送出が停止される可能性がある場合の送出情報パラメタを1とする。なお、これらのパーセンテージは本実施例を説明する上での例であり、必ずしもこれらのパーセンテージである必要は無い。また、送出情報パラメタの種類も4種類に限定するものではない。さらに、送出情報パラメタの値と、更新ソフトウェアの送出頻度と送出期間との組み合わせとの対応関係も、図2に示す関係に限定するものではない。
図2に示した送出情報パラメタの設定内容からも分かるように、本実施例においては、送出情報パラメタの値は、市場におけるダウンロード未完了の受信装置の残存数に応じて定められている。そして、ダウンロード未完了の受信装置がより少ない場合には、ダウンロードデータがその全送出を終了するまでの期間(送出期間)はより短くなり、ダウンロードデータの単位時間あたりの送出回数(送出頻度)はより少なくなるように設定されている。なお、本実施例においてダウンロードデータの送出の開始時期からダウンロードデータがその全送出を終了するまでの期間は所定期間に相当する。また、所定期間中にダウンロードデータが送出された全回数が所定回数に相当する。
次に、この送出情報パラメタを用いた更新ソフトウェア送出の態様を図3を用いて説明する。更新ソフトウェア送出の開始時は、送出情報パラメタは4であり、送出情報パラメタ4に対応する送出頻度、送出期間で更新ソフトウェア送出が行われる。そして、送出期間が終了した際に、市場に残存するダウンロード未完の受信装置の数が取得され、取得さ
れた受信装置の数に応じて新たなパラメタが設定される。例えばその際に、市場の受信装置の50%がダウンロードを完了している場合には、図3に示すように、送出情報パラメタとして3が設定され、送出情報パラメタ3に対応する送出頻度、送出期間で更新ソフトウェア送出が行われる。そして、パラメタ3に対応する送出期間が終了した時点で、再度市場に残存するダウンロード未完の受信装置の数が取得され、新たな送出情報パラメタが設定される。
このように、本実施例において送出側システムは、ダウンロード未完の受信装置の数に応じて送出情報パラメタを設定し、送出情報パラメタの値が小さくなるにつれて送出頻度を少なくするとともに送出期間が短くなるように調整する。ダウンロード未完の受信装置の数が20%未満になったら、送出情報パラメタは1に設定され、その際の送出期間の終了をもって更新ソフトウェアの送出を終了させる。
本実施例では、上記のような前提でSDTT及び更新ソフトウェアが送出される際に、SDTTに付加された送出情報パラメタを解析する。そして、受信装置における更新ソフトウェア受信のタイミングを、ユーザに不都合を生じさせないように、かつダウンロードを失敗させないようにスケジュールする。
ところで、本実施例において、送出情報パラメタを伴わない通常のSDTTを取得した場合の、更新ソフトウェアのダウンロードを実行するまでの受信装置の動作は、一般的な受信装置と同等である。ここでは先ず、この場合の一般的な動作を簡単に説明する。
この場合、図示しないアンテナから受信された放送信号はチューナ部101に入力され、デマルチプレックス部102に送られる。デマルチプレックス部102は、放送信号から、映像信号(Video)、音声信号(Audio)、データセクション(DSMCC:Digital Storage Media-Command and Control)を抽出する。また、ストリーム情報(PSI:Program Specific Information)、番組情報(SI:Service Information)をも抽出する。映
像信号及び音声信号はAV処理部106にて処理され、SIはSI処理部107で処理される。本発明においては、AV処理とSDTTを除くSIの処理は発明の要点でないので説明を省略する。
受信装置が、放送波もしくはユーザによって予め定められた特定の時刻に実行しなければならない処理は数多くある(以下、この放送波もしくはユーザによって予め定められた時刻に行わなければならない処理を「予約処理」という。)。本実施例では簡単のために予約処理を、ユーザの録画または視聴予約や、ダウンロードや、EMM受信のための通電制御に限定して説明する。さらに、それらの優先順位と、ユーザの視聴動作との優先度を図4のように決める(ユーザの視聴、ユーザの予約、ダウンロード、EMM通電制御の順)。なお、図4における優先度の数字は、数字がより小さい場合に優先度がより高いものとする。
デマルチプレックス部102で分離されたSDTTは、SDTT処理部103に出力される。SDTT処理部103は、SDTTを解析し、自身を対象とするソフトウェアのダウンロードがいつ開始され、いつ終了するのかを取得する。取得された情報はスケジュール管理部108に入力される。
デマルチプレックス部102で分離されたEMMは、EMM処理部104に出力される。EMM処理部104は、有料放送契約情報やワーク鍵の取得処理を行い、かつ次回のEMM取得のための通電制御の日時を取得する。有料放送契約情報及びワーク鍵の取得処理に関しては本件と関係が無いため説明を省略する。EMMから取得された次回のEMM取得のための通電制御日時はスケジュール管理部108に入力される。また、図示しないリ
モコン等のユーザインタフェース部に入力されるユーザの予約情報は、システム制御部100を通じてスケジュール管理部108に入力される。
スケジュール管理部108は入力されたダウンロードのスケジュールと、EMM通電制御日時と、ユーザ予約とを、図4に示した処理優先度に従いスケジューリングする。スケジュール管理部108が実行するスケジュール決定の手順を示すフローチャートを図5に示す。
本フローチャートが実行されると、S130において、入力された新規スケジュールの予約処理がユーザ予約か否かが判定される。ここで肯定判定された場合にはS131に進む。一方、否定判定された場合にはS135に進む。
S131においては、入力された新規の予約処理がユーザ予約の場合に、ユーザ予約による新規スケジュールと、更新ソフトウェアのダウンロードの予約時刻との「重複」が判定される。この「重複」とは、新規の予約処理の開始から終了までに必要とする時間帯が、すでに登録済みの他の予約処理が必要とする時間帯と重複し、かつ異なるチャンネルをチューニングする必要がある状態をいう。ここで更新ソフトウェアのダウンロードの予約時刻は、SDTTに記載されている送出開始時刻及び連続送出期間の情報が用いられる。すなわち、送出開始時刻から連続送出期間が経過するまでの時間をもってダウンロードの予約時刻とされる。
ここで、新規の予約処理の開始から終了までに必要とする時間帯が、すでに登録済みの他の予約処理が必要とする時間帯と重複し、かつ同じチャンネルをチューニングする必要がある場合は、同時に処理が可能である。以下、この状態を特に「同時処理可能な重複」と記載する。新規のユーザ予約に係る予約処理が、すでに登録済みのダウンロードの予約処理と重複しない場合には、S132に進む。一方、新規のユーザ予約に係る予約処理が、すでに登録済みのダウンロードの予約処理と重複する場合には、S133に進む。
S133においては、ユーザ予約とダウンロードではユーザ予約の方が処理優先度が高いので、すでに登録済みのダウンロードを再スケジュールする。S133の処理が終了するとフローを終了する。
S132においては、入力された新規の予約処理がユーザ予約の場合に、ユーザ予約による新規スケジュールと、EMM通電制御の予約時刻との重複が判定される。新規のユーザ予約に係る予約処理が、すでに登録済みのEMM通電制御と重複しない場合には、そのままフローを終了する。一方、新規のユーザ予約に係る予約処理が、すでに登録済みのEMM通電制御と重複する場合には、S134に進む。
S134においては、ユーザ予約とEMM通電制御ではユーザ予約の方が処理優先度が高いので、すでに登録済みのEMM通電制御を再スケジュールする。S134の処理が終了するとフローを終了する。
次に、S135においては、入力された新規の予約処理がダウンロードか否かについて判定される。ここで肯定判定された場合にはS136に進む。一方、否定判定された場合、すなわち入力された新規の予約処理がEMM通電処理の場合は、S140に進む。
S136においては、入力された新規の予約処理が更新プログラムのダウンロードの場合に、更新ソフトウェアのダウンロードの予約時刻と、既に登録済みのユーザ予約によるスケジュールの重複が判定される。ダウンロードの予約時刻が、すでに登録済みのユーザ予約に係る予約処理と重複しない場合には、S137に進む。一方、ダウンロードの予約
時刻が、すでに登録済みのユーザ予約に係る予約処理と重複する場合には、S138に進む。
S138においては、ダウンロードとユーザ予約ではユーザ予約の方が処理優先度が高いので、新規の更新ソフトウェアのダウンロードを再スケジュールする。S138の処理が終了するとフローを終了する。
S137においては、入力された新規の予約処理が更新ソフトウェアのダウンロードの場合に、更新ソフトウェアのダウンロードの予約時刻と、EMM通電制御の予約時刻との重複が判定される。新規の更新ソフトウェアのダウンロードの予約処理が、すでに登録済みのEMM通電制御と重複しない場合には、そのままフローを終了する。一方、新規の更新ソフトウェアのダウンロードに係る予約処理が、すでに登録済みのEMM通電制御と重複する場合には、S139に進む。
S139においては、ダウンロードとEMM通電制御ではダウンロードの方が処理優先度が高いので、すでに登録済みのEMM通電制御を再スケジュールする。S139の処理が終了するとフローを終了する。
S140においては、入力された新規の予約処理がEMM通電制御の場合に、EMM通電制御の予約時刻と、既に登録済みのユーザ予約によるスケジュールの重複が判定される。EMM通電制御の予約時刻が、すでに登録済みのユーザ予約に係る予約処理と重複しない場合には、S141に進む。一方、EMM通電制御の予約時刻が、すでに登録済みのユーザ予約に係る予約処理と重複する場合には、S142に進む。
S142においては、EMM通電制御とユーザ予約ではユーザ予約の方が処理優先度が高いので、新規のEMM通電制御を再スケジュールする。S142の処理が終了するとフローを終了する。
S141においては、入力された新規の予約処理がEMM通電制御の場合に、新規のEMM通電制御の予約時刻と、すでに登録済みのEMM通電制御の予約時刻との重複が判定される。新規のEMM通電制御の予約処理が、すでに登録済みのEMM通電制御と重複しない場合には、そのままフローを終了する。一方、新規のEMM通電制御の予約処理が、すでに登録済みのEMM通電制御と重複する場合には、S143に進む。
S143においては、すでに登録済みのEMM通電制御を再スケジュールする。S143の処理が終了するとフローを終了する。
次に、予約された更新ソフトウェアの受信時刻になった際のダウンロードの手順について図6を用いて説明する。本フローはシステム制御部100が主体的に実行するものである。
本フローが実行されると、S150において、ダウンロードの開始時刻か否かが判定される。ここで、ダウンロード開始時刻でないと判定された場合には、本フローはそのまま終了する。一方、ダウンロード開始時刻であると判定された場合には、S151に進む。
S151においては、システム制御部100が、更新ソフトウェアを送出しているチャンネルを受信できるチューナに空きがあるかどうかをチューナ部101に確認して判定する。ここでチューナに空きがないと判定された場合にはS155に進み、更新ソフトウェアのダウンロードを再スケジュールする。一方、チューナに空きがある場合はS152に進む。
S152においては、更新ソフトウェアのダウンロードが開始される。S152の処理が終了するとS153に進む。
S153においては、ユーザの操作により空きチューナがなくなったか否かが判定される。ここで空きチューナがなくなったと判定された場合にはS155に進み、それまでのダウンロードデータを破棄して、更新ソフトウェアのダウンロードを再スケジュールする。一方、空きチューナがなくなっていない場合にはS154に進む。
S154では、更新ソフトウェアのダウンロードが完了したか否かが判定される。ここでダウンロードが完了していないと判定された場合には、S152の処理の後に戻ることで、ダウンロード動作を継続する。一方、ダウンロードが完了したと判定された場合には、フローを終了する。
上記のフローによってダウンロードされた更新ソフトウェアはDSMCC処理部105に入力される。DMSCC処理部105は取得したダウンロードコンテンツをダウンロードデータ蓄積部110に蓄える。受信装置のソフトウェアの更新は受信装置が待機状態のときに行われるのが一般的であり、本実施例でもそのような状態で行なわれる。システム制御部100は、ユーザがテレビに対して待機状態を通知したタイミングで、ダウンロード更新処理部111にダウンロードデータ蓄積部110からデータを読み込みプログラムをアップデートする。なお、DMSCC処理部105の主たる機能はデータ放送の受信だが、データ放送処理は本発明と特に関係が無いため、説明を省略する。
次に、本実施例において図3のような送出情報パラメタが付加されたSDTTを受信した場合の受信装置の動作を説明する。この場合には、送出情報パラメタの値に応じて、処理優先度は図7のように変化する。そして、スケジュール管理部108は、送出開始時刻から連続送出期間が経過するまでの時間と予約処理の実行時間とが重複する場合に、送出情報パラメタの値に応じて、前記ダウンロードデータの取得処理と予約処理のどちらを優先して実行するかを決定する。
本実施例におけるSDTT処理部103とスケジュール管理部108以外の動作は送出情報パラメタが付加されていないSDTTを受信した場合の動作と同じである。従って、ここではSDTT処理部103とスケジュール管理部108以外の動作の説明は省略する。
SDTT処理部103は、SDTTの構造を解析し、SDTTに記載される2日間についての更新ソフトウェア送出開始時刻、連続送出期間情報を読み込む。また、これとともに、SDTTに付加されるダウンロードコンテンツ記述子内text_char領域に記載された数値を読み込み、送出情報パラメタを取得する。受信された送出情報パラメタは、2日間の更新ソフトウェア送出開始時刻、連続送出期間情報と共にスケジュール管理部108に送られる。なお、本実施例においてダウンロード送信情報取得ステップは、このSDTT処理部103における処理を含んで構成される。
EMM処理部104で得られたEMM通電制御時刻及び、図示しないリモコン等のユーザインタフェース部に入力されるユーザの予約情報はSDTTに送出情報パラメタが記載されていない場合と同様に、スケジュール管理部108に送られる。
スケジュール管理部108では、送出情報パラメタの数字によって、受信装置の予約処理の優先度を図7のように変化させる。基本的な考え方は、送出情報パラメタの数字が大きい場合は、まだ充分に送出頻度も高く送出期間も長いため、ユーザの視聴やEMM通電
制御を優先させる。そして、送出情報パラメタの数字が小さくなってくると徐々にダウンロードの優先度を上げ、送出情報パラメタの数字が2よりも小さくなると、ユーザの予約よりもダウンロードを優先させてダウンロードの失敗を防止するようにスケジューリングする。
次に、スケジュール決定の手順を示すフローチャートを図8に示す。なお、本フローにおいて、図5も示したフローと共通の処理については、図5と同じ符号を付するとともに説明は簡略化している。なお、本フローにおける処理はスケジュール管理部108によって実行される。
本フローが実行され、S130において、入力された新規の予約処理がユーザ予約と判定された場合、S131及びS132においてユーザ予約のスケジュールとダウンロード及びEMM通電制御との予約時刻の重複が判断される。S131においてユーザ予約がダウンロードと重複すると判定された場合には、S160に進み、ダウンロードがスケジュールされた際の送出情報パラメタが3未満か否かが判定される。S160において否定判定された場合には、S161に進む。一方S160で肯定判定された場合には、S162に進む。
S161においては、ダウンロードとユーザ予約ではユーザ予約の方が処理優先度が高いので、ユーザ予約を優先してダウンロードを再スケジューリングする。一方、S162においては、ダウンロードとユーザ予約ではダウンロードの方が処理優先度が高いので、ダウンロードを優先してユーザ予約を拒絶する。S132においてユーザ予約とEMM通電制御と重複する場合と判定された場合の動作はSDTTに送出情報パラメタが記載されていない場合と同じであるので説明は省略する。
S135において新規の予約処理がダウンロードと判定された場合、S136においてダウンロードのスケジュールとユーザ予約との重複が判定され、S137においてダウンロードのスケジュールとEMM通電制御との重複が判定される。
S136において肯定判定された場合には、S164に進む。S164においては、ダウンロードの送出情報パラメタが3未満か否かが判定される。ここで否定判定された場合にはS138に進む。S138では、ユーザ予約の方がダウンロードより処理優先度が高いのでダウンロードの再スケジューリングが行なわれる。一方、S164において肯定判定された場合には、S165に進む。S165では、ダウンロードとユーザ予約ではダウンロードの方が処理優先度が高いので、ユーザ予約が拒絶される。S138またはS165の処理が終了するとフローを一旦終了する。
S137において肯定判定された場合には、S163に進む。S163においては、ダウンロードの送出情報パラメタが4か否かが判定される。ここで肯定判定された場合にはS138に進み、EMM通電制御の方がダウンロードより処理優先度が高いのでダウンロードの再スケジューリングが行なわれる。一方、S163において否定判定された場合にはS139に進み、ダウンロードの方がEMM通電制御より処理優先度が高いのでEMM通電制御が再スケジューリングされる。S138またはS139の処理が終了すると本フローを一旦終了する。
S135において新規の予約処理がダウンロードでない、すなわちEMM通電制御であると判定された場合には、S140においてEMM通電制御のスケジュールとユーザ予約との重複が判定される。また、S141においてEMM通電制御のスケジュールとダウンロードとの重複が判定される。
S140において肯定判定された場合にはS142に進み、ユーザ予約の方がEMM通電制御より処理優先度が高いのでEMM通電制御の再スケジューリングが行なわれる。S142の処理が終了すると本フローを一旦終了する。なお、図8に示したフローは、本実施例においてスケジュール管理ステップを構成する。
S141において肯定判定された場合には、S166に進む。S166においては、ダウンロードの送出情報パラメタが4か否かが判定される。ここで肯定判定された場合にはS167に進み、EMM通電制御の方がダウンロードより処理優先度が高いのでダウンロードの再スケジューリングが行なわれる。一方、S166において否定判定された場合にはS142に進み、ダウンロードの方がEMM通電制御より処理優先度が高いのでEMM通電制御が再スケジューリングされる。S167またはS142の処理が終了すると本フローを一旦終了する。
次に、本実施例において図4のように送出情報パラメタが付加されたSDTTを受信する場合において、予約された更新ソフトウェアの受信時刻になった際のダウンロードの手順について、図9を用いて説明する。ここでは、図5で示した、送出情報パラメタを伴わない通常のSDTTを取得した場合におけるダウンロード手順との相違点についてのみ説明する。従って、本フローの処理はシステム制御部100によって実行される。
本フローにおいては、S151において使用されているチューナがないと判定された場合に、S170に進む。S170においては、送出情報パラメタが2以上か否かが判定される。ここで肯定判定された場合、すなわち送出情報パラメタが4から2の場合は、送出情報パラメタが付加されないSDTTを受信した際の動作と同じくS155に進む。一方、S170で否定判定された場合、すなわち送出情報パラメタが1の場合はS171に進む。
この場合には、ユーザの視聴よりもダウンロードが優先されるため、S171においてユーザが視聴もしくは予約されていない録画で使用しているチューナに対して、ダウンロードで使用する旨のメッセージを表示する。そして、強制的に視聴もしくは録画を停止し、空いたチューナを使用してダウンロードを開始する。
また、ダウンロード中にユーザがチューナを使用するような操作を行い、S153において空きチューナがなくなったと判定された場合には、S172に進み、送出情報パラメタが2以上か否かが判定される。S172において肯定判定された場合、すなわち送出情報パラメタが4から2と判定された場合は、送出情報パラメタが付加されないSDTTを受信した際の動作と同じくS155に進む。
一方、S172において否定判定された場合、すなわち送出情報パラメタが1の場合はS173に進む。この場合には、ユーザの視聴よりもダウンロードの処理優先度が高いので、S173において操作の禁止をユーザに提示してダウンロードを続行する。
以上、説明したとおり、本実施例においては、更新ソフトウェアの送出頻度と、送出期間を示す送出情報パラメタを利用することで、ダウンロード処理の優先度を送出側の更新ソフトウェアの送出頻度、送出期間と連動させることとした。これにより、更新ソフトウェアが受信できなくなる前にダウンロードできるように受信装置側でダウンロードをスケジュールすることが可能となる。そうすると、更新ソフトウェアが受信できなくなるタイミングを可及的に少なく抑え、ユーザがダウンロードを意識すること、ユーザにダウンロードによる不都合が発生することを抑制することができる。
また、本実施例においては、スケジュール管理部108は、送出情報パラメタとして図
2に定義するパラメタを用い、また、送出情報パラメタの値に基づいて、ダウンロードと、他の予約処理の処理優先度を図7に示すように定義している。すなわち、本実施例では、送出情報パラメタの値の示す、ダウンロードデータの全送出が終了するまでの期間がより短くなりまたは、ダウンロードデータの単位時間あたりの送出回数がより少なくなる場合に、ダウンロードデータの取得処理の優先度をより高くする。
なお、上記の実施例1において、チューナ部101、マルチプレックス部102及びSDTT処理部103は、ダウンロード送信情報取得部に相当する。
次に、本発明の実施例2について図面を用いて説明する。図10は本実施例に係るデジタル放送受信装置の形態を示すブロック図である。ここで、図1に示した実施例1に係る形態と同一の構成・同一の動作を行う構成要素については、実施例1と同一の符号を付して説明を省略する。
図10において、201はデマルチプレックス部102が分解した放送信号のうち、SDTTを処理するSDTT処理部である。202は、受信装置で各種予約処理を実行するタイミングを決定するスケジュール管理部である。スケジュール管理部202は、リモコン等のユーザインタフェースによるユーザからの予約情報、SDTT処理部201が解析したSDTTの情報、EMM処理部104が解析したEMM取得スケジュール情報により、各種予約処理の実行タイミングを決定する。
なお、本実施例においては、実施例1と同様の送出側システムを前提とし、更新ソフトウェアの送出頻度と、送出期間を示す送出情報パラメタをSDTTに付加して送出する。送出情報パラメタは、SDTTに付加されるダウンロードコンテンツ記述子内text_char領域に記載される。
実施例1との相違点は、送出情報パラメタを図11のように、送出頻度パラメタと送出期間パラメタの2つとする点である。よって、デマルチプレックス部102が分解したSDTTはSDTT処理部201で処理され、受信したSDTTに含まれる2日間のダウンロード開始時刻と連続送出期間とともに、スケジュール情報と共にスケジュール管理部202に送られる。この処理は、本実施例においてこの処理はダウンロード送信情報取得ステップを構成する。
スケジュール管理部202は入力されたダウンロードのスケジュール、EMM通電制御日時、ユーザ予約を、図7の処理優先度に従いスケジューリングする。
ここで、図7の送出情報パラメタは、実施例1ではパラメタそのものをSDTTから取得した。これに対し本実施例においては、送出情報パラメタはSDTTから取得した送出頻度パラメタと送出期間パラメタとを用い、図12のような表を用いて求めるものとする。表の作り方は任意であり、送出頻度と送出期間との優先度を加味して予め受信装置に組み込まれるものとする。本実施例では、送出期間よりも送出頻度を優先するが、送出期間パラメタが1の場合のみ強制的にダウンロードするようにスケジューリングされる。送出頻度パラメタ、送出期間パラメタとそれぞれに対する優先度を用いた計算式を用いて算出するようにしても良い。
送出情報パラメタが決定された後の動作は実施例1におけるものと同一であるので、ここでは説明を省略する。
以上、説明したとおり、本実施例においては、更新ソフトウェアの送出頻度パラメタと
、送出期間パラメタとを利用して送出情報パラメタを求める。このことで、ダウンロード処理の優先度を送出側システムの更新ソフトウェアの送出頻度、送出期間と連動させることとした。これにより、更新ソフトウェアが受信できなくなる前にダウンロードできるように受信装置側でダウンロードをスケジュールすることが可能となる。その結果、更新ソフトウェアが受信できなくなるタイミングを可及的に少なく抑えることができる。また、ユーザがダウンロードを意識すること、ユーザにダウンロードによる不都合が発生することを抑制できる。
次に、本発明の実施例3について説明する。図13は本発明に係るデジタル放送受信装置の実施例3を示すブロック図である。なお、実施例1と同一の構成・同一の動作を行う構成要素については、実施例1と同一の符号を付し説明を省略する。
図13において、300はシステム制御部である。301は図示しないリモコン等のユーザインタフェースによりユーザから指示された予約情報と、SDTT処理部103が解析したSDTTの情報、EMM処理部104が解析した、EMM取得スケジュール情報とを総合するするスケジュール管理部である。このスケジュール管理部では、受信装置で各種予約処理を実行するタイミングを決定する。302は、図示しないリモコン等のユーザインタフェースによりユーザから指示された受信装置のダウンロード受信優先度の設定値を保存する優先度設定蓄積部である。
なお、本実施例においても実施例1と同様の送出側システムを前提とする。SDTTに付加する送出情報パラメタも実施例1において説明したものと同一である。
実施例1との相違点は、更新ソフトウェア受信の予約処理の優先度をユーザが選択できる点である。ユーザが選択できる優先度の例を図14に示す。図14のように、本実施例の受信装置では更新ソフトウェアを受信した際の受信装置の動作を、「ダウンロード優先」「ユーザ視聴・予約優先」「省エネダウンロード」からユーザが任意に選択することが可能とする。
ここで、図14からも分かるように、「ダウンロード優先」設定とは、受信装置においてユーザの予約よりもダウンロードが優先される設定である。また、「ユーザ視聴・予約優先」とは、逆にダウンロードよりもユーザ視聴、ユーザ予約が優先される設定である。さらに「省エネダウンロード」とは、ダウンロードがユーザ予約やEMM通電制御による通電時にまとめて実行されるようにスケジュールする設定である。
ここで、まとめて実行することによる省エネとは、ダウンロードの予約処理を行う際に、他の予約処理と同時に実行できる場合は1回の通電処理で他の予約処理とダウンロードとを同時に行うことをいう。これにより、待機状態の受信装置に通電してダウンロード処理を行うことを可及的に少なくし、省エネルギーを実現する。ここで、ダウンロードの予約処理と他の予約処理との間に「同時処理可能な重複」が存在すれば、同時に処理が可能である。
次に、通常のSDTTを受け取り、ダウンロードを実行するまでの動作を簡単に説明する。
実施例1と動作が異なるのはスケジュール管理部301である。スケジュール管理部301は、図14の処理優先度に従いユーザ視聴、ダウンロード、ユーザ予約、EMM通電制御のスケジュールの決定を行う。その際、SDTT処理部103、EMM処理部104及びシステム制御部300から入力されたダウンロードのスケジュール、EMM通電制御
日時、ユーザ予約と、優先度設定蓄積部302に蓄積されているユーザの優先度設定情報とが用いられる。スケジュール管理部301が実行するスケジュール決定の手順を示すフローチャートを図15に示す。
本フローが実行されると、まず図15(a)に示すS321において、ユーザの優先度設定がダウンロード優先となっているか否かが判定される。ここで肯定判定された場合には、図15(b)に示すフローに進む。否定判定された場合には、S322に進む。S322では、優先度設定がユーザ視聴・予約優先か否かが判定される。ここで肯定判定された場合には、図15(c)に示すフローに進む。否定判定された場合には、図15(d)に示すフローに進む。
図15(b)には、S321において優先度設定が「ダウンロード優先」と判定された場合のフローチャートを示す。
図15(b)に示すフローは、図5に示したフローと大部分が同等であるため、図5に示したフローと同一の処理については、説明は簡略化し、図5に示したフローとの相違点について詳細に説明する。図15(b)に示すフローでは、新規の予約がユーザ予約の場合、まずS131においてダウンロードとの重複が判定される。ここで、ユーザ予約が既に登録済みのダウンロード予約と重複すると判定された場合はS324に進む。そして、S324においては、ダウンロードの方がユーザ予約より処理優先度が高いのでユーザ予約は拒否される。次にS132においてはEMM通電制御とユーザ予約時刻の重複が判定され、肯定判定された場合にはS134に進む。S134においては、ユーザ予約の方がEMM通電制御より処理優先度が高いのでEMM通電制御を再スケジュールする。
新規の予約処理がダウンロードの場合、S136においてすでに登録済みのユーザ予約とダウンロードとが重複すると判定された場合にはS325に進む。S325においては、ダウンロードの方がユーザ予約より処理優先度が高いのでユーザ予約がキャンセルされる。S137においてすでに登録済みのEMM通電制御とダウンロードとが重複すると判定された場合にはS139に進む。S139においては、ダウンロードの方がEMM通電制御より処理優先度が高いのでEMM通電制御を再スケジュールする。また、新規スケジュールがEMM通電制御である場合には、S140及びS326においてEMM通電制御とユーザ予約、ダウンロードとの重複が判定される。S140及びS326で肯定判定された場合には、それぞれS142、S143に進む。S142、S143においては、EMM通電制御の処理優先度が最も低いので、EMM通電制御を再スケジュールする。一連の処理が終了すると図15(a)のS323に戻る。
次に、優先度設定が「ユーザ視聴・予約優先」の場合の処理は、図5に示した、実施例1のSDTTに送出情報パラメタが付加されていない場合の処理と同様である。優先度設定が「ユーザ視聴・予約優先」の場合の処理のフローチャートを図15(c)に示す。
次に、優先度設定が「省エネダウンロード」の場合の処理のフローチャートを図15(d)及び図15(e)に示す。
図15(d)に示すフローでは、まず、S327において新規の予約処理がユーザ予約か否かが判定される。ここで肯定判定された場合にはS328に進み、EMM通電制御とユーザ予約との予約時刻の重複が判定される。ここで肯定判定された場合にはS332に進み、ユーザ予約の方がEMM通電制御より処理優先度が高いので、EMM通電制御が再スケジュールされる。
S327で否定判定された場合にはS335に進み、新規スケジュールがEMM通電制
御か否かが判定される。ここで、肯定判定された場合には、S336に進み、EMM通電制御とユーザ予約との重複が判定される。ここでEMM通電制御とユーザ予約とが重複するようであればS337に進み、ユーザ予約の方がEMM通電制御より処理優先度が高いのでEMM通電制御を再スケジュールする。
その後、S329においてダウンロードのスケジュールが確認される。S329の処理が終了するとS330に進む。
S330においては、決定されたEMM通電制御の予約時刻に対し、登録済みのスケジュールでダウンロードされる更新ソフトウェアと同じ更新ソフトウェアの送出スケジュールが、EMM通電制御のスケジュールと同時処理可能に重複するか否かが判定される。その際、SDTTに記載されている送出開始時刻及び連続送出期間の情報が用いられる。
ここで、同時処理可能な重複がダウンロードの送出スケジュールとEMM通電制御の予約時刻との間に存在すると判定された場合には、S333に進む。S333においては、ダウンロードスケジュールを変更してEMM通電制御と同時にダウンロードが行われるようにスケジュールする。S333の処理が終了すると図15(a)のS323に戻り、スケジュールを決定した後に、本フローを終了する。
一方、S330において否定判定された場合、すなわち、同時処理可能な重複がダウンロードの送出スケジュールとEMM通電制御の予約時刻との間に存在しないと判定された場合には、S331に進む。
S331においては、決定されたユーザ予約の予約時刻に対し、登録済みのスケジュールでダウンロードされる更新ソフトウェアと同じ更新ソフトウェアが送出されるスケジュールが、ユーザ予約のスケジュールと同時処理可能に重複するか否かが判定される。その際、SDTTに記載されている送出開始日時及び連続送出期間情報が用いられる。
ここで、同時処理可能な重複がダウンロードの送出スケジュールとユーザ予約の予約時刻との間に存在すると判定された場合には、S334に進む。S334においては、ダウンロードスケジュールを変更してユーザ予約と同時にダウンロードが行われるようにスケジュールする。S334の処理が終了すると図15(a)のS323に戻り、スケジュールを決定した後に、本フローを終了する。
また、S335において否定判定された場合、すなわち、本フローにおける新規の予約処理がダウンロードの場合は、図15(e)におけるS338に進む。S338においては、すでに登録済みのEMM通電制御の予約時刻と新規のダウンロードのスケジュールとの間に、同時処理可能な重複があるか否かが判定される。
S338で肯定判定された場合は、S342に進み、EMM通電制御の予約時刻と同時処理可能に重複するタイミングでダウンロードされるようにスケジューリングが行なわれる。一方、S338において否定判定された場合には、S339に進み、すでに登録済みのユーザ予約の予約時刻と新規のダウンロードのスケジュールとの間に、同時処理可能な重複があるか否かが判定される。ここで肯定判定された場合、すなわち、すでに登録済みのユーザ予約とダウンロードのスケジュールとの間に同時処理可能な重複があると判定された場合はS343に進む。S343においては、すでに登録済みのユーザ予約と同時処理可能に重複するタイミングでユーザ予約と同時にダウンロードが行われるようにスケジューリングが行なわれる。
S339において否定判定された場合にはS340に進む。S340においては、更新
ソフトウェアのダウンロードの予約時刻と、既に登録済みのユーザ予約によるスケジュールの重複が判定される。ダウンロードの予約時刻が、すでに登録済みのユーザ予約に係る予約処理と重複しない場合には、S341に進む。一方、ダウンロードの予約時刻が、すでに登録済みのユーザ予約に係る予約処理と重複する場合には、S345に進む。
S345においては、ダウンロードとユーザ予約ではユーザ予約の方が処理優先度が高いので、新規の更新プログラムのダウンロードを再スケジュールする。S345の処理が終了すると図15(a)のS323に戻る。
S341においては、更新ソフトウェアのダウンロードの予約時刻と、EMM通電制御の予約時刻との重複が判定される。新規の更新ソフトウェアのダウンロードの予約処理が、すでに登録済みのEMM通電制御と重複しない場合には、図15(a)のS323に戻る。一方、新規の更新ソフトウェアのダウンロードに係る予約処理が、すでに登録済みのEMM通電制御と重複する場合には、S346に進む。
S346においては、ダウンロードとEMM通電制御ではEMM通電制御の方が優先順位が高いので、新規の更新プログラムのダウンロードを再スケジュールする。S346の処理が終了すると図15(a)のS323に戻る。
次に、図3のような送出情報パラメタが付加されたSDTTを受信した場合の受信装置の動作を説明する。この場合、送出情報パラメタの値に応じて、処理優先度は図16のように変化する。
スケジュール管理部301は、図16の処理優先度に従いユーザ視聴、ダウンロード、ユーザ予約、EMM通電制御のスケジュールの決定を行う。その際、SDTT処理部103、EMM処理部104及びシステム制御部300から入力されたダウンロードのスケジュール、EMM通電制御日時、ユーザ予約と、優先度設定蓄積部302に蓄積されているユーザの優先度設定情報とが用いられる。スケジュール決定の手順を示すフローチャートを図17に示す。本フローの処理はスケジュール管理部301によって実行される。
まず、図17(a)に示すフローは、図15(a)に示したフローと同等であるので、説明は省略する。
S321において優先度設定が「ダウンロード優先」と判定された場合の動作は、図15(b)に示した、実施例のSDTTに送出情報パラメタが付加されていない場合のフローと同一であるので、ここでは説明を省略する。このフローチャートを図17(b)に示す。
図17(a)のS322において、優先度設定が「ユーザ視聴・予約優先」であると判定された場合の処理は、図8に示した、実施例1のSDTTに送出情報パラメタが付加された場合の処理と同等になるので説明は省略する。このフローチャートを図17(c)に示す。
図17(a)のS322において、優先度設定が「ユーザ視聴・予約優先」でないと判定された場合、すなわち、優先度設定が「省エネダウンロード」であると判定された場合のフローチャートを図17(d)及び図17(e)に示す。図17(d)に示したフローチャートは、図15(d)において説明したフローと同等であるので、ここでは説明を省略する。
本フローにおいて、新規の予約処理がダウンロードの場合は、図17(e)におけるS
338に進む。S338においては、すでに登録済みのEMM通電制御の予約時刻と新規のダウンロードのスケジュールとの間に、同時処理可能な重複があるか否かが判定される。
S338で肯定判定された場合は、S342に進み、EMM通電制御の予約時刻と同時処理可能に重複するタイミングでダウンロードされるようにスケジューリングが行なわれる。一方、S338において否定判定された場合には、S339に進み、すでに登録済みのユーザ予約の予約時刻と新規のダウンロードのスケジュールとの間に、同時処理可能な重複があるか否かが判定される。
ここで肯定判定された場合、すなわち、すでに登録済みのユーザ予約とダウンロードのスケジュールとの間に同時処理可能な重複があると判定された場合はS343に進む。S343においては、すでに登録済みのユーザ予約と同時処理可能に重複するタイミングでユーザ予約と同時にダウンロードが行われるようにスケジューリングが行なわれる。
S339において否定判定された場合にはS360に進み、すでに登録済みのユーザ予約とダウンロードスケジュールとの間の重複が判定される。ここでユーザ予約とダウンロードスケジュールとが重複していると判定された場合はS364に進む。また、ユーザ予約とダウンロードスケジュールとが重複していないと判定された場合はS361に進む。
S364においては、送出情報パラメタの値が1か否かが判定される。ここで、送出情報パラメタが1と判定された場合にはS366に進み、ダウンロードの方がユーザ予約より処理優先度が高いのでユーザ予約をキャンセルする。一方、送出情報パラメタが1以外と判定された場合にはS365に進み、ユーザ予約の方がダウンロードより処理優先度が高いのでダウンロードを再スケジュールする。S365またはS366の処理が終了すると図17(a)のS323に戻る。
S361においては、ダウンロードとすでに登録済みのEMM通電制御と間の重複が判定される。S361において、ダウンロードがすでに登録済みのEMM通電制御と重複していると判定された場合はS362に進む。一方、S361において、ダウンロードがすでに登録済みのEMM通電制御と重複していないと判定された場合は図17(a)のS323に戻る。
S362においては、送出情報パラメタが4か否かが判定される。S362において送出情報パラメタが4と判定された場合はS365に進み、EMM通電制御の方がダウンロードより処理優先度が高いのでダウンロードを再スケジュールする。一方、S362において送出情報パラメタが4以外と判定された場合にはS363に進み、ダウンロードの方がEMM通電制御より処理優先度が高いのでEMM通電制御を再スケジュールする。S363またはS365の処理が終了すると図17(a)のS323に戻る。なお、図17で示したフローは、本実施例におけるスケジュール管理ステップを構成する。
次に、予約された更新ソフトウェアの受信時刻になった際の、ダウンロードの手順について、図18を用いて説明する。ここでは、実施例1の説明で図6に示した処理と同一の処理については同一の符号で示すとともに、説明は省略する。本実施例における処理と図6に示した処理との相違点についてのみ説明する。なお、ダウンロードの処理については、システム制御部300によって実行される。
本フローにおいては、S151においてダウンロードプログラム取得時刻に、チューナの空きが無いと判定された場合にはS370に進む。S370においては、まず送出情報パラメタの値が2以上か否かが判定される。ここで否定判定された場合、すなわち送出情
報パラメタが1の場合には、S371に進む。S371においては、ダウンロードの方がユーザの視聴よりも処理優先度が高いため、ユーザが視聴もしくは予約されていない録画で使用しているチューナに対して、ダウンロードで使用する旨のメッセージを表示する。そして、強制的に視聴もしくは録画を停止、空いたチューナを使用してダウンロードを開始する。一方、S370において肯定判定された場合、すなわち送出情報パラメタが4から2の場合には、S372に進む。
S372においては、送出情報パラメタが2か否かが判定される。S372において送出情報パラメタが2でない、すなわち3または4と判定された場合には、ユーザ視聴の方がダウンロードよりも処理優先度が高いため、S155に進み、ダウンロードを再スケジュールする。一方、S372において送出情報パラメタが2と判定された場合は、S373に進む。S373においては、さらにユーザの優先度設定が確認される。S373において優先度設定が「ダウンロード優先」となっていると判定された場合はS371に進む。S371においては、ダウンロードの方がユーザの視聴よりも処理優先度が高いため、ユーザが使用しているチューナをダウンロードで使用する旨のメッセージを表示し、強制的に視聴もしくは録画を停止、空いたチューナを使用してダウンロードを開始する。一方、S373において優先度設定が「ダウンロード優先」でない場合は、ユーザ視聴の方がダウンロードよりも処理優先度が高いため、S155に進み、ダウンロードを再スケジュールする。
また、S153において、ダウンロード中にユーザがチューナを使用するような操作を行い、その結果空きチューナがなくなると判定された場合には、S374に進む。S374においては、送出情報パラメタが2以上か否かが確認される。ここで否定判定された、すなわち送出情報パラメタが1の場合は、ダウンロードの方がユーザ視聴より処理優先度が高いのでS375に進み、操作の禁止をユーザに提示してダウンロードを続行する。一方、S374において肯定判定された場合、すなわち送出情報パラメタが4から2の場合にはS376に進む。
S376においては、送出情報パラメタが2か否かが判定される。S376において送出情報パラメタが2でない、すなわち3または4と判定された場合には、ユーザ視聴の方がダウンロードよりも処理優先度が高いため、S155に進む。一方、S376において送出情報パラメタが2と判定された場合はS377に進む。S377においては、さらにユーザのダウンロード優先度設定が確認される。S377において優先度設定が「ダウンロード優先」の場合、ダウンロードの方がユーザ視聴よりも処理優先度が高いため、S375に進み、操作の禁止をユーザに提示してダウンロードを続行する。
一方、S377において優先度設定が「ダウンロード優先」でないと判定された場合は、ユーザ視聴の方がダウンロードよりも処理優先度が高いため、S155に進み、ダウンロードを再スケジュールする。
上記処理の結果、本実施例では、ダウンロード処理の優先度を送出側システムの更新ソフトウェアの送出頻度、送出期間と連動させることで、更新ソフトウェアが受信不能をなる前にダウンロードが完了するように受信装置側でスケジュールすることが可能となる。そして、更新ソフトウェアが受信できなくなるタイミングを可及的に少なく抑え、ユーザがダウンロードを意識すること、ユーザにダウンロードによる不都合が発生することを抑制できる。
本発明における実施例1の概略構成を示すブロック図
実施例1において前提とされるSDTTに付加される送出情報パラメタを説明する説明図
本発明において前提とされる更新ソフトウェアの送出方法を説明する説明図
実施例1のスケジュール管理部の動作における処理優先度を説明する説明図
実施例1のスケジュール管理部の動作を説明するフローチャート
実施例1のシステム制御部の動作を説明するフローチャート
実施例1のスケジュール管理部の動作における送出情報パラメタと処理優先度との関係を説明する説明図
実施例1のスケジュール管理部の動作を説明する説明図
実施例1のシステム制御部の動作を説明するフローチャート
本発明における実施例2の概略構成を示すブロック図
実施例2において前提とされるSDTTに付加される送出情報を説明する説明図
実施例2のスケジュール管理部の動作における送出頻度、送出期間と送出情報パラメタとの関係を説明する説明図
本発明における実施例3の概略構成を示すブロック図
実施例3のスケジュール管理部の動作における処理優先度を説明する説明図
実施例3のスケジュール管理部の動作を説明するフローチャートの一部
実施例3のスケジュール管理部の動作を説明するフローチャートの一部
実施例3のスケジュール管理部の動作を説明するフローチャートの一部
実施例3のスケジュール管理部の動作を説明するフローチャートの一部
実施例3のスケジュール管理部の動作を説明するフローチャートの一部
実施例3のスケジュール管理部の動作における処理優先度を説明する説明図
実施例3のスケジュール管理部の動作を説明するフローチャートの一部
実施例3のスケジュール管理部の動作を説明するフローチャートの一部
実施例3のスケジュール管理部の動作を説明するフローチャートの一部
実施例3のスケジュール管理部の動作を説明するフローチャートの一部
実施例3のスケジュール管理部の動作を説明するフローチャートの一部
実施例3のシステム制御部の動作を説明するフローチャート
符号の説明
100・・・システム制御部
101・・・チューナ部
102・・・デマルチプレックス部
103・・・SDTT処理部
104・・・EMM処理部
105・・・DSMCC処理部
106・・・AV処理部
107・・・SI処理部
108・・・スケジュール管理部
109・・・ダウンロード蓄積処理部
110・・・ダウンロードデータ蓄積部
111・・・ダウンロード更新処理部
201・・・SDTT処理部
202・・・スケジュール管理部
300・・・システム制御部
301・・・スケジュール管理部
302・・・優先度設定蓄積部