(57)【要約】【課題】  確実にソフトウェアを更新することができる受信装置、放送システム、受信方法及びプログラムを提供する。【解決手段】ソフトウェア取得部は受信装置の動作に係るソフトウェアを取得し、受信経路判定部は放送による前記ソフトウェアの受信において障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定する。本発明は、受信装置、放送システム、受信方法方及びプログラムとしても実施することができる。【選択図】図１
2016092504.tif 000002
【特許請求の範囲】
【請求項１】
自装置の動作に係るソフトウェアを取得するソフトウェア取得部と、
放送による前記ソフトウェアの受信において障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定する受信経路判定部と、
を備える受信装置。
【請求項２】
放送波の受信状態を判定する受信状態判定部を備え、
前記障害は前記受信状態が所定の受信状態よりも劣悪である状態である
請求項１に記載の受信装置。
【請求項３】
前記ソフトウェアの配信時間を示す告知情報を解析する告知情報解析部と、
番組の受信を予約する番組予約部と、
前記障害は、前記告知情報が示す受信時間の少なくとも一部が、前記番組予約部が受信を予約した番組の受信時間の少なくとも一部と重複することである
請求項１または請求項２に記載の受信装置。
【請求項４】
前記受信経路判定部は、
放送による前記ソフトウェアの受信が完了する前に前記障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定し、前記ソフトウェアのうち未受信の部分を前記ソフトウェア取得部に受信させる
請求項１から請求項３のいずれか一項に記載の受信装置。
【請求項５】
放送で受信装置の動作に係るソフトウェアを送信する送信装置と、前記ソフトウェアを記憶するサーバー装置と、前記受信装置とを備える放送システムであって、
前記受信装置は、
前記ソフトウェアを取得するソフトウェア取得部と、
放送による前記ソフトウェアの受信において障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定する受信経路判定部と、
を備える放送システム。
【請求項６】
受信装置における受信方法であって、
前記受信装置の動作に係るソフトウェアを取得する取得過程と、
放送による前記ソフトウェアの受信において障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定する受信経路判定過程と、
を有する受信方法。
【請求項７】
受信装置のコンピュータに、
前記受信装置の動作に係るソフトウェアを取得する取得手順、
放送による前記ソフトウェアの受信において障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定する受信経路判定手順
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信装置、放送システム、受信方法及びプログラムに関する。
【背景技術】
【０００２】
従来から、デジタル放送を受信するための受信装置には、例えば、特許文献１に記載されているようにソフトウェアを利用して所定の機能を実現し、放送波により配信されたソフトウェアに更新する仕組みを備えるものがあった。ソフトウェアの更新は、例えば、バグの修正、種々の動作パラメータの変更に応じて行われる。ソフトウェアを更新する際、放送波を送信する放送局は、放送波で伝送する情報の一部を用いてソフトウェアの更新を受信装置に告知し、その後、更新ソフトウェアを示すデータを重畳した放送波を送信する。受信装置は、放送波でソフトウェアを受信し、既存のソフトウェアを受信したソフトウェアに更新する。
一方、近年では放送と通信との融合が進み、多くの受信装置においてネットワークに接続する手段を備え、ネットワークを経由して様々なコンテンツやデータにアクセス可能になっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−１６９６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のソフトウェア更新の仕組みでは、ソフトウェア更新のタイミングで放送波を受信している必要がある。そのタイミングで放送波を受信していないと、ソフトウェアを更新することができないという課題があった。例えば、受信環境において何らかの障害、例えば、降雨による電界強度の低下、チューナーが番組の視聴や録画のために占有されている場合、受信装置はソフトウェアのデータを受信することができない。かかる状態が継続すると、結果としてソフトウェア更新のタイミングを逸することがある。
【課題を解決するための手段】
【０００５】
本発明は、上記の課題を解決するためになされたものであり、本発明の一態様は、自装置の動作に係るソフトウェアを取得するソフトウェア取得部と、放送による前記ソフトウェアの受信において障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定する受信経路判定部と、を備える受信装置である。
【発明の効果】
【０００６】
本発明によれば、受信装置はソフトウェアを確実に更新することができる。
【図面の簡単な説明】
【０００７】
【図１】第１の実施形態に係る放送システムの構成を示すブロック図である。
【図２】第１の実施形態に係る送信装置の構成を示すブロック図である。
【図３】ＤＩＩメッセージの例を示す図である。
【図４】コンパティビリティ記述子の例を示す図である。
【図５】ＤＤＢメッセージの例を示す図である。
【図６】告知情報の例を示す図である。
【図７】ダウンロードコンテンツ記述子の例を示す図である。
【図８】ネットワークダウンロードコンテンツ記述子の例を示す図である。
【図９】第１の実施形態に係るサーバー装置の構成を示すブロック図である。
【図１０】第１の実施形態に係る受信装置の構成を示すブロック図である。
【図１１】第１の実施形態に係る制御部の構成を示すブロック図である。
【図１２】第１の実施形態に係る受信装置の動作を示すフローチャートである。
【図１３】第２の実施形態に係る制御部の構成を示すブロック図である。
【図１４】第２の実施形態に係る受信装置の動作を示すフローチャートである。
【図１５】第３の実施形態に係る制御部の構成を示すブロック図である。
【図１６】第３の実施形態に係る受信装置の動作を示すフローチャートである。
【図１７】第４の実施形態に係る制御部の構成を示すブロック図である。
【図１８】第４の実施形態に係る受信装置の動作を示すフローチャートである。
【発明を実施するための形態】
【０００８】
（第１の実施形態）
本発明の第１の実施形態について、図面を参照しながら説明する。
図１は、本実施形態に係る放送システム１の構成を示すブロック図である。放送システム１は、送信装置１１と、サーバー装置２１と、受信装置３１とを含んで構成される。送信装置１１及びサーバー装置２１は、放送事業者が有する放送設備を構成する。受信装置３１は、送信装置１１から放送される放送番組を受信し、受信した放送番組の映像を表示し、当該放送番組の音声を再生する。受信装置３１は、各家庭や事業所等に設置される。
【０００９】
送信装置１１は、放送伝送路１２を介して放送番組のデータ（番組データ）を逐次に受信装置３１に送信する。また、送信装置１１は、新たなソフトウェアを取得し、取得したソフトウェアを所定の方式、例えば、データカルーセル方式で送信する。データカルーセル方式は、同一のデータを一定期間繰り返し送信する伝送方式である。ここで、ソフトウェアとは、送信装置１１の機能の一部または全部を実現するための動作させるためのプログラムである。新しいソフトウェアの送信は、受信装置３１で用いられている既存のソフトウェアの更新を目的とする新たなソフトウェアとして、例えば、同種類の既存のソフトウェアで発見されたバグを修正したソフトウェア、動作パラメータを変更したソフトウェア、新たな機能が追加もしくは既存の機能の一部が削除されたソフトウェアである。
【００１０】
放送伝送路１２は、送信装置１１が送信する各種のデータを同時に不特定多数の受信装置３１に一方向的に伝送する伝送路である。放送伝送路１２は、例えば、放送衛星１３で中継される所定の周波数帯域の電波（放送波）である。放送伝送路１２の一部には、通信回線、例えば、送信装置１１から電波を送信するための送信設備までの通信回線が含まれてもよい。なお、放送伝送路１２を介して各種のデータを送信（または、受信）することを、「放送で送信（または、受信もしくはダウンロード）する」と呼ぶことがある。
【００１１】
サーバー装置２１は、送信装置１１が送信する新たなソフトウェアを取得し、取得したソフトウェアを蓄積するサーバー装置である。サーバー装置２１の所在は、例えば、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）で放送伝送路１２を介して受信装置３１に通知される。サーバー装置２１は、受信装置３１からソフトウェア要求信号を受信したときに、要求されたソフトウェアを受信装置３１に送信する。
【００１２】
通信伝送路２２は、サーバー装置２１と受信装置３１との間で各種のデータを双方向的に伝送する伝送路である。通信伝送路２２は、例えば、有線の大容量の基幹網を有するインターネット、等の広域通信網を含む。通信伝送路２２は、一部に無線のアクセス網を含む通信網、例えば、公衆無線通信網であってもよい。なお、通信伝送路２２を介して各種のデータを送信することを、「通信で送信（受信もしくはダウンロード）する」と呼ぶことがある。
【００１３】
受信装置３１は、送信装置１１から放送伝送路１２を介して受信したデータを復号するＣＡＳプログラムを起動し、起動したＣＡＳプログラムを実行することにより、受信したデータを復号する。
受信装置３１は、送信装置１１またはサーバー装置２１から自装置の動作に係るソフトウェアを受信する。受信装置３１は、送信装置１１からの放送による受信において障害が検出されたとき、当該ソフトウェアの受信経路を通信伝送路２２と判定し、サーバー装置２１から通信による受信を試みる。受信装置３１は、例えば、テレビジョン受信装置、映像記録装置、等である。
【００１４】
この構成により、放送によるソフトウェアの受信において障害が検出されても、受信装置３１は、通信で当該ソフトウェアを取得することができる。そのため、受信装置は、より確実に既存のソフトウェアを更新することができる。放送によるソフトウェアの受信における障害には、例えば、降雨によって放送波の電界強度が低下した場合、放送波が建造物その他の物体に遮られることによる受信障害、等がある。
【００１５】
（送信装置の構成）
次に、本実施形態に係る送信装置１１の構成について説明する。
図２は、本実施形態に係る送信装置１１の構成を示すブロック図である。送信装置１１は、配信データ生成部１１１、番組データ生成部１１２、告知情報生成部１１３、多重化部１１４、暗号化部１１５及び送信部１１６を含んで構成される。
【００１６】
配信データ生成部１１１には、新たなバージョンのソフトウェアが入力される。配信データ生成部１１１は、入力されたソフトウェアを所定の形式、例えば、セクション形式のデータに変換し、配信用のデータ（配信データ）を生成する。配信データ生成部１１１は、生成した配信データを多重化部１１４に出力する。
具体的には、配信データ生成部１１１は、入力されたソフトウェアを所定の大きさに分割し、分割したデータ（分割データ）をＤＤＢメッセージとして所定の大きさにセクション化し、その構成情報をＤＩＩメッセージとして生成する。配信データは、生成されたＤＩＩメッセージと、ＤＤＢメッセージで形成される。ＤＩＩメッセージには、例えば、当該ソフトウェアのメーカ識別（ｍａｋｅｒ＿ｉｄ）、モデル識別（ｍｏｄｅｌ＿ｉｄ）、バージョン識別（ｖｅｒｓｉｏｎ＿ｉｄ）が含まれる。「識別（ｉｄ：ｉｄｅｎｔｉｆｉｅｒ）」とは、個々の事物を識別するための情報であり、「識別子」と呼ばれることもある。
【００１７】
また、配信データ生成部１１１は、全てのモジュールのＤＤＢメッセージに格納される暗号化した分割データの全体（つまり、ソフトウェア）について、所定のアルゴリズムで演算した誤り検出符号を算出する。所定のアルゴリズムは、例えば、巡回冗長検査（ＣＲＣ：Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）である。巡回冗長検査により、誤り検出符号としてＣＲＣ値が算出される。配信データ生成部１１１は、算出したＣＲＣ値を、例えば、ＤＩＩメッセージのＣＲＣ記述子に記述する。受信装置３１は、格納されたソフトウェアのデータに基づいて演算した誤り検出符号が付加されたＣＲＣ値と一致するか否かにより正しく復号されたか否かを検証することができる。
配信データ生成部１１１は、生成した配信データを多重化部１１４に出力する。
【００１８】
番組データ生成部１１２には、番組データが入力される。番組データは、放送番組を表現する映像データと音声データを含むデータである。番組データ生成部１１２は、入力された番組データについて所定の形式、例えば、ストリーム形式に変換し、変換した番組データを多重化部１１４に出力する。
【００１９】
告知情報生成部１１３には、新たなソフトウェアのダウンロードに関するダウンロード情報が入力される。告知情報生成部１１３は、ダウンロード情報を含み、所定の形式で表された告知情報を生成する。告知情報には、配信されるソフトウェアを特定する情報としてメーカ識別（ｍａｋｅｒ＿ｉｄ）、モデル識別（ｍｏｄｅｌ＿ｉｄ）、バージョン識別（ｖｅｒｓｉｏｎ＿ｉｄ）の組の他、配信時間、別個の配信元であるサーバー装置２１にアドレス、配信元つまり受信（ダウンロード）経路の優先度、等が含まれる。告知情報は、例えば、セクション形式のテーブルであるＳＤＴＴ（Ｓｏｆｔｗａｒｅ  Ｄｏｗｎｌｏａｄ  Ｔｒｉｇｇｅｒ  Ｔａｂｌｅ）で表される。告知情報生成部１１３は、生成した告知情報ＳＤＴＴを多重化部１１４に出力する。
【００２０】
多重化部１１４は、配信データ生成部１１１から入力された配信データ、番組データ生成部１１２から入力された番組データ、及び告知情報生成部１１３から入力された告知情報を多重化して、所定の形式（例えば、トランスポートストリーム）の多重化データを生成する。多重化部１１４は、生成した多重化データを暗号化部１１５に出力する。
暗号化部１１５は、多重化部１１４から入力された多重化データを所定の暗号化方式（例えば、ＭＵＬＴＩ２）を用いて暗号化する。暗号化部１１５は、暗号化した多重化データを送信部１１６に出力する。
送信部１１６は、暗号化部１１５から入力された多重化データを受信装置３１に放送伝送路１２を介して送信する。ここで、送信部１１６は、ベースバンド信号である多重化データで所定の搬送周波数を有する搬送波を変調させて、搬送周波数に対応したチャネル帯域の電波（放送波）を、アンテナを用いて放射する。
【００２１】
（ＤＩＩメッセージのデータ構造）
次に、ソフトウェアを送信する際のＤＩＩメッセージの例について説明する。
図３は、ＤＩＩメッセージの例を示す図である。図３に示す例では、ＤＩＩメッセージは、コンパティビリティ記述子（ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（））を含む。コンパティビリティ記述子（ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（））の例については後述する。また、ＤＩＩメッセージは、モジュール数（ｎｕｍｂｅｒＯｆＭｏｄｕｌｅｓ）、モジュール識別（ｍｏｄｕｌｅ＿ｉｄ）、及びモジュールサイズ（ｍｏｄｕｌｅ＿ｓｉｚｅ）を含む。
【００２２】
（コンパティビリティ記述子のデータ構造）
次に、コンパティビリティ記述子のデータ構造について、説明する。コンパティビリティ記述子（ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（））には、告知情報ＳＤＴＴのテーブル識別（ｔａｂｌｅ＿ｉｄ）やグループ領域（ｇｒｏｕｐ）では表しきれない情報が記述される。
図４は、コンパティビリティ記述子の例を示す図である。図４に示す例では、コンパティビリティ記述子は、モデル領域（ｍｏｄｅｌ）及びバージョン領域（ｖｅｒｓｉｏｎ）を含む。モデル領域（ｍｏｄｅｌ）の上位８ビット、下位８ビットに、それぞれソフトウェアの製作者を示すメーカ識別（ｍａｋｅｒ＿ｉｄ）、対象モデル（機種）を示すモデル識別（ｍｏｄｅｌ＿ｉｄ）が記述される。バージョン領域（ｖｅｒｓｉｏｎ）には、ソフトウェアのバージョンを示すバージョン識別（ｖｅｒｓｉｏｎ＿ｉｄ）が記述される。
【００２３】
（ＤＤＢメッセージのデータ構造）
次に、ソフトウェアを配信する際に用いられるＤＤＢメッセージのデータ構造について説明する。
図５は、ＤＤＢメッセージの例を示す図である。図５に示す例では、ＤＤＢメッセージは、ブロック番号（ＢｌｏｃｋＮｕｍｂｅｒ）、モジュール識別（ｍｏｄｕｌｅＩｄ）及びペイロード領域（ｂｌｏｃｋＤａｔａＢｙｔｅ）を含む。ブロック番号（ＢｌｏｃｋＮｕｍｂｅｒ）は、配信データ生成部１１１によってブロックごとにインクリメントされ、書き込まれる情報である。従って、ブロック番号（ＢｌｏｃｋＮｕｍｂｅｒ）は、分割されたソフトウェアの順序を示す数である。モジュール識別（ｍｏｄｕｌｅＩｄ）は、個々のＤＤＢメッセージを特定する識別情報である。ペイロード領域（ｂｌｏｃｋＤａｔａＢｙｔｅ）は、配信データ生成部１１１によって分割されたソフトウェアが書き込まれる領域である。
【００２４】
（告知情報のデータ構造）
次に、告知情報生成部１１３が生成する告知情報ＳＤＴＴのデータ構造について説明する。図６は、告知情報ＳＤＴＴの例を示す図である。図６に示す例では、告知情報ＳＤＴＴは、テーブル識別拡張（ｔａｂｌｅ＿ｉｄ＿ｅｘｔ）、ターゲットバージョン（ｔａｒｇｅｔ＿ｖｅｒｓｉｏｎ）、新バージョン（ｎｅｗ＿ｖｅｒｓｉｏｎ）、ダウンロードレベル（ｄｏｗｎｌｏａｄ＿ｌｅｖｅｌ）、バージョン指示（ｖｅｒｓｉｏｎ＿ｉｎｄｉｃａｔｏｒ）バージョン番号（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ）、開始時刻（ｓｔａｒｔ＿ｔｉｍｅ）、配信継続時間（ｄｕｒａｔｉｏｎ）及び記述子領域（ｄｅｓｃｒｉｐｔｏｒｓ（））を含む。
【００２５】
テーブル識別拡張（ｔａｂｌｅ＿ｉｄ＿ｅｘｔ）の上位８ビットには、メーカ識別（ｍａｋｅｒ＿ｉｄ）が記述され、下位８ビットには、モデル識別（ｍｏｄｅｌ＿ｉｄ）が記述される。
ターゲットバージョン（ｔａｒｇｅｔ＿ｖｅｒｓｉｏｎ）には、アップデート対象となるソフトウェアのバージョン識別が記述される。新バージョン（ｎｅｗ＿ｖｅｒｓｉｏｎ）には、送信装置１１が送信するソフトウェアのバージョン識別が記述される。
ダウンロードレベル（ｄｏｗｎｌｏａｄ＿ｌｅｖｅｌ）には、ダウンロードの態様を示す値が格納される。例えば、‘０１’は強制ダウンロードを示し、‘００’は、任意ダウンロードを示す。
バージョン指示（ｖｅｒｓｉｏｎ＿ｉｎｄｉｃａｔｏｒ）は、アップデート対象のバージョンの範囲を示す。‘００’は、全バージョンを示し、‘０３’は、指定されたバージョンのみを示す。
【００２６】
開始時刻（ｓｔａｒｔ＿ｔｉｍｅ）は、送信装置１１がソフトウェアの送信を開始する時刻を示す。
配信継続時間（ｄｕｒａｔｉｏｎ）は、送信装置１１がソフトウェアの送信を継続する時間を示す。告知情報ＳＤＴＴでは、開始時刻（ｓｔａｒｔ＿ｔｉｍｅ）及び配信継続時間（ｄｕｒａｔｉｏｎ）が、複数通り設定可能である。
記述子領域（ｄｅｓｃｒｉｐｔｏｒｓ（））には、ダウンロードコンテンツ記述子とネットワークダウンロードコンテンツ記述子が記述される。
【００２７】
（ダウンロードコンテンツ記述子のデータ構造）
次に、ダウンロードコンテンツ記述子のデータ構造について説明する。
図７は、ダウンロードコンテンツ記述子の例を示す図である。ダウンロードコンテンツ記述子は、コンパティビリティフラグ（ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ）、コンパティビリティ記述子（ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（））、モジュール数（ｎｕｍ＿ｏｆ＿ｍｏｄｕｌｅｓ）、モジュール識別（ｍｏｄｕｌｅ＿ｉｄ）、モジュールサイズ（ｍｏｄｕｌｅ＿ｓｉｚｅ）及びプライベートデータ領域（ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ）を含む。
【００２８】
コンパティビリティフラグ（ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ）は、コンパティビリティ記述子（ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（））の有無を示すフラグである。図７に示す例では、コンパティビリティフラグ（ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ）は、コンパティビリティ記述子（ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（））の「有無を示すフラグが設定されている。
コンパティビリティ記述子（ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（））には、上述したコンパティビリティ記述子（図４）と同一の内容が含まれる。ここで、メーカ識別（ｍａｋｅｒ＿ｉｄ）、モデル識別（ｍｏｄｅｌ＿ｉｄ）、及びバージョン識別（ｖｅｒｓｉｏｎ＿ｉｄ）が記述される。
【００２９】
モジュール数（ｎｕｍ＿ｏｆ＿ｍｏｄｕｌｅｓ）、モジュール識別（ｍｏｄｕｌｅ＿ｉｄ）、及びモジュールサイズ（ｍｏｄｕｌｅ＿ｓｉｚｅ）には、ソフトウェアを送信するためのＤＩＩ／ＤＤＢメッセージのモジュール数、モジュール識別、及びモジュールサイズがそれぞれ記述される。
プライベートデータ領域（ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ）の先頭バイトにはダウンロード優先（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）が記述される。ダウンロード優先（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）には、ダウンロード経路として放送と通信のどちらを優先するかを指示する値が格納される。以下の説明では、ダウンロード優先（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）を、「優先フラグ」と呼ぶことがある。
【００３０】
（ネットワークダウンロードコンテンツ記述子のデータ構造）
次に、ネットワークダウンロードコンテンツ記述子のデータ構造について説明する。
図８は、ネットワークダウンロードコンテンツ記述子の例を示す図である。ネットワークダウンロードコンテンツ記述子は、コンパティビリティフラグ（ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ）、コンパティビリティ記述子（ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（））、セッションプロトコル番号（ｓｅｓｓｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｎｕｍｂｅｒ）、再接続回数（ｒｅｔｒｙ）、アドレス種別（ａｄｄｒｅｓｓ＿ｔｙｐｅ）、アドレス種別（ａｄｄｒｅｓ＿ｔｙｐｅ）、及びポート番号（ｐｏｒｔ＿ｎｕｍｂｅｒ）を含む。
【００３１】
図８に示す例においても、コンパティビリティフラグ（ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ）には、図７に示す例と同様に、コンパティビリティ記述子（ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（））があることを示す値（１）が設定されている。コンパティビリティ記述子（ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（））には、上述したコンパティビリティ記述子（図４）と同一の内容が含まれる。ここで、上述したようにメーカ識別（ｍａｋｅｒ＿ｉｄ）、モデル識別（ｍｏｄｅｌ＿ｉｄ）、及びバージョン識別（ｖｅｒｓｉｏｎ＿ｉｄ）が記述される。
【００３２】
セッションプロトコル番号（ｓｅｓｓｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｎｕｍｂｅｒ）は、ネットワークダウンロード、つまり通信伝送路２２を介したダウンロードの際に用いるプロトコル（例えば、ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を示す番号である。アドレス種別（ａｄｄｒｅｓｓ＿ｔｙｐｅ）は、送信元の通信サーバーの所在を示すアドレスの種別を示す番号である。図８に示す例では、アドレスの種別として、ＩＰｖ４、ＩＰｖ６、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）のいずれかが指定可能である。アドレスは、送信元の通信サーバー（例えば、サーバー装置２１）の所在を示し、アドレス種別（ａｄｄｒｅｓｓ＿ｔｙｐｅ）で指定された種別で表されたアドレスである。ポート番号（ｐｏｒｔ＿ｎｕｍｂｅｒ）は、通信サーバーのポート番号を示す。
【００３３】
（サーバー装置の構成）
次に、サーバー装置２１の構成について説明する。
図９は、本実施形態に係るサーバー装置２１の構成を示すブロック図である。サーバー装置２１は、制御部２１０、通信部２１３、及び記憶部２１４を含んで構成される。制御部２１０は、記憶部２１４に記憶されている制御プログラムを実行することにより、配信データ取得部２１１、及び配信データ配信部２１２を実現する。制御部２１０は、例えば、ＣＰＵである。
【００３４】
配信データ取得部２１１は、送信装置１１から配信データ生成部１１１で生成されたソフトウェアの配信データを取得する。配信データ取得部２１１は取得した配信データに含まれるＤＩＩからソフトウェアのメーカ識別（ｍａｋｅｒ＿ｉｄ）、モデル識別（ｍｏｄｅｌ＿ｉｄ）、及びバージョン識別（ｖｅｒｓｉｏｎ＿ｉｄ）を読み取る。配信データ取得部２１１は、読み取ったソフトウェアのメーカ識別（ｍａｋｅｒ＿ｉｄ）、モデル識別（ｍｏｄｅｌ＿ｉｄ）、及びバージョン識別（ｖｅｒｓｉｏｎ＿ｉｄ）と、取得した配信データとを対応付けて記憶部２１４に記憶する。従って、サーバー装置２１には、その時点で送信可能なソフトウェアのうち最新のバージョンのソフトウェアに係る配信データが蓄積される。なお、以下の説明ではメーカ識別（ｍａｋｅｒ＿ｉｄ）、モデル識別（ｍｏｄｅｌ＿ｉｄ）、及びバージョン識別（ｖｅｒｓｉｏｎ＿ｉｄ）の組を「ソフトウェア識別」と呼ぶことがある。
【００３５】
配信データ配信部２１２は、受信装置３１から配信要求信号を受信する。配信要求信号は、指定されたソフトウェア識別で識別されるソフトウェアに係る配信データを要求するための信号である。配信データ配信部２１２は、配信要求信号で指定されたソフトウェア識別に対応する配信データを記憶部２１４から読み取る。配信データ配信部２１２は、読み取った配信データを、通信伝送路２２を介して受信装置３１に送信する。
【００３６】
通信部２１３は、外部機器、例えば、送信装置１１及び受信装置３１との間で各種のデータを送信及び受信する。サーバー装置２１の各構成部による送受信は、通信部２１３を介して行われる。通信部２１３は、例えば、通信インタフェースである。
記憶部２１４は、各種のデータを記憶する。記憶部２１４は、記憶媒体、例えば、ＨＤＤ（Ｈａｒｄ−ｄｉｓｋ  Ｄｒｉｖｅ）、フラッシュメモリ、ＲＯＭ（Ｒｅａｄ−ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）又はそれらの任意の組み合わせを含んで構成される。
【００３７】
（受信装置の構成）
次に、受信装置３１の構成について説明する。図１０は、本実施形態に係る受信装置３１の構成を示すブロック図である。受信装置３１は、チューナー３１１（受信部）、復号部３１２、分離部３１３、音声復号部３１４、再生部３１５、映像復号部３１６、表示部３１７、通信部３２１、制御部３３１、及び記憶部３４１を含んで構成される。
【００３８】
チューナー３１１は、多重化データを送信装置１１から放送伝送路１２を介してアンテナにより受信する。チューナー３１１は、電波で受信したチャネル帯域の受信信号を、その搬送周波数でベースバンド信号である多重化データに復調する。チューナー３１１は、復調した多重化データを復号部３１２に出力する。
復号部３１２は、チューナー３１１から入力された多重化データ（暗号化されている）を、送信装置１１の暗号化部１１５で用いられた方式に対応する復号方式（例えば、ＭＵＬＴＩ２）で復号し、復号した多重化データを生成する。復号部３１２は、生成した多重化データを分離部３１３に出力する。
【００３９】
分離部３１３は、復号部３１２から入力された多重化データから番組データ、配信データ、及び告知情報に分離する。分離部３１３は、配信データ及び告知情報を制御部３３１に出力する。また、分離部３１３は、番組データから音声データと映像データを抽出する。分離部３１３は、抽出した音声データを音声復号部３１４に出力し、映像データを映像復号部３１６に出力する。
【００４０】
音声復号部３１４は、分離部３１３から音声データが入力される。入力された音声データは、所定の音声符号化方式（例えば、ＭＰＥＧ−２  オーディオ）で符号化されたデータである。音声復号部３１４は、符号化に用いられた符号化方式と対応する復号方式で入力された音声データを復号し、復号した音声データを生成する。復号した音声データは、各時刻における音声のレベルを示すデータである。音声復号部３１４は、復号した音声データを再生部３１５に出力する。
再生部３１５は、音声復号部３１４から入力された音声データに基づく音声を再生する。再生部３１５は、例えば、スピーカを含んで構成される。
【００４１】
映像復号部３１６は、分離部３１３から映像データが入力される。入力された映像データは、所定の映像符号化方式（例えば、ＭＰＥＧ−２  ビデオ）で符号化されたデータである。映像復号部３１６は、符号化に用いられた符号化方式と対応する復号方式で入力された映像データを復号し、復号した映像データを生成する。復号した映像データは、各時刻における映像（フレーム画像）を形成する信号値を示すデータである。映像復号部３１６は、復号した映像データを表示部３１７に出力する。
表示部３１７は、映像復号部３１６から入力された映像データに基づく映像を再生する。表示部３１７は、例えば、ディスプレイを含んで構成される。
【００４２】
通信部３２１は、通信伝送路２２を介してサーバー装置２１との間で各種のデータを送信及び受信する。受信装置３１の各構成部による送受信は、通信部３２１を介して行われる。通信部３２１は、例えば、通信インタフェースである。
制御部３３１は、受信装置３１の種々の動作を制御する。例えば、制御部３３１は、告知情報ＳＤＴＴに記述された時間帯において分離部３１３から入力（放送で受信）された配信データから受信装置３１の動作に係るソフトウェアを抽出し、抽出したソフトウェアを記憶部３４１に記憶する。また、制御部３３１は、送信装置１１からの放送によるソフトウェアの受信において障害が検出されたとき、当該ソフトウェアの受信経路を通信と判定する。制御部３３１の機能構成については後述する。
記憶部３４１は、各種のデータを記憶する。記憶部３４１は、記憶媒体、例えば、ＨＤＤ（Ｈａｒｄ−ｄｉｓｋ  Ｄｒｉｖｅ）、フラッシュメモリ、ＲＯＭ（Ｒｅａｄ−ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）又はそれらの組み合わせを含んで構成される。
【００４３】
（制御部の構成）
次に、本実施形態に係る制御部３３１の構成について説明する。図１１は、本実施形態に係る制御部３３１の構成を示すブロック図である。制御部３３１は、告知情報解析部３３２、受信状態判定部３３３、受信経路判定部３３４、及びソフトウェア取得部３３５を含んで構成される。
【００４４】
告知情報解析部３３２は、分離部３１３から入力された告知情報ＳＤＴＴから開始時刻（ｓｔａｒｔ＿ｔｉｍｅ）と配信継続時間（ｄｕｒａｔｉｏｎ）を抽出し、配信時間を特定する。告知情報解析部３３２は、告知情報ＳＤＴＴからメーカ識別（ｍａｋｅｒ＿ｉｄ）、モデル識別（ｍｏｄｅｌ＿ｉｄ）、及びバージョン識別（ｖｅｒｓｉｏｎ＿ｉｄ）を抽出し、受信対象のソフトウェアを特定する。告知情報解析部３３２は、告知情報ＳＤＴＴから優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）の有無を判定し、ダウンロード経路の優先順位の設定の有無を判定する。告知情報解析部３３２は、優先順位の設定があると判断した場合には、その優先順位を特定する。告知情報解析部３３２は、告知情報ＳＤＴＴから通信での送信元の通信サーバー（つまり、サーバー装置２１）のアドレスを抽出して、送信元となるサーバー装置２１を特定する。
【００４５】
受信状態判定部３３３は、分離部３１３から入力された配信データに基づいて、配信データの受信に障害が生じたか否かを判定する。配信データは、上述したようにＤＩＩメッセージと、ソフトウェアを分割したＤＤＢメッセージとを含むデータである。受信状態判定部３３３は、障害が生じたと判定した場合には、放送での障害の発生を示す障害フラグを受信経路判定部３３４に出力する。
受信に障害が生じたとは、本実施形態では、受信に失敗したこと、または受信に失敗する状態であることを意味する。障害が生じていないとは、受信に成功したこと、または受信に成功する状態であることを意味する。受信状態判定部３３３は、例えば、次のいずれかまたは組み合わせに該当する場合に受信に障害が生じたと判定し、いずれも該当しない場合には受信に障害が生じていないと判定する。
【００４６】
（１）分離部３１３から入力されたデータに告知情報解析部３３２で特定した受信対象のソフトウェアに係るＤＩＩメッセージ、及び対応するＤＤＢメッセージが含まれていない場合。
（２）配信データを構成するＤＤＢメッセージの少なくとも一部が欠落している場合。受信状態判定部３３３は、ＤＤＩメッセージに記述されたモジュール数とモジュールＩＤと、ＤＤＢメッセージに記述されたモジュールＩＤとを照合して、ＤＤＢメッセージの欠落の有無を判定することができる。
（３）ＤＩＩメッセージに記述されたＣＲＣ値と、ＤＤＢメッセージに分割して格納された分割データ（ソフトウェア）の全体について巡回冗長検査を行って算出したＣＲＣ値が一致しない場合。
（４）告知情報解析部３３２で特定された配信時間の終了時刻から所定時間内に（例えば、３分）分離部３１３から、受信対象のソフトウェアに係るＤＩＩメッセージ及び対応するＤＤＢメッセージが入力されなかった場合（タイムアウト）。
【００４７】
受信経路判定部３３４は、告知情報解析部３３２で解析された告知情報ＳＤＴＴに基づいて受信経路を判定する。告知情報解析部３３２が、優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）が含まれていると判定するとき、受信経路判定部３３４は、優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）で特定された受信経路でソフトウェアをダウンロードすると判定する。例えば、優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）に設定された値が０ｘ０１または０ｘ０２である場合は、受信経路判定部３３４は、最初に放送でダウンロードすると判定し、ダウンロードに失敗した場合に受信経路を通信と定める。優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）に設定された値が０ｘ０３である場合は、受信経路判定部３３４は、最初に通信でダウンロードすると判定し、ダウンロードに失敗した場合に受信経路を放送と定める。
【００４８】
一方、告知情報解析部３３２において優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）がないと判定するとき、受信経路判定部３３４は、放送でソフトウェアをダウンロードすると判定する。但し、受信状態判定部３３３から障害フラグが入力される場合、つまり、放送でのダウンロードに失敗する場合には、通信でダウンロードすると判定する。受信経路判定部３３４は、通信と放送のどちらを受信経路として用いるかを示す受信経路信号をソフトウェア取得部３３５に出力する。
【００４９】
ソフトウェア取得部３３５は、受信経路判定部３３４で判定された受信経路を介してソフトウェアを取得する。受信経路信号が示す受信経路が放送である場合には、ソフトウェア取得部３３５は、告知情報解析部３３２で特定されたソフトウェアの配信データを受信状態判定部３３３から入力する。受信経路信号が示す受信経路が通信である場合には、ソフトウェア取得部３３５は、告知情報解析部３３２で特定されたソフトウェアを要求するための配信要求信号を生成し、生成した配信要求信号を告知情報解析部３３２で特定されたサーバー装置２１に送信する。これにより、ソフトウェア取得部３３５は、サーバー装置２１から要求されたソフトウェアに係る配信データを受信することができる。
【００５０】
ソフトウェア取得部３３５は、入力または受信した配信データを構成する各ＤＤＢメッセージから分割データを抽出し、抽出した分割データをＤＤＢメッセージに付されたモジュールＩＤの昇順に連結してソフトウェアを取得する。ソフトウェア取得部３３５は、取得したソフトウェアを、当該ソフトウェアを特定するメーカ識別（ｍａｋｅｒ＿ｉｄ）、モデル識別（ｍｏｄｅｌ＿ｉｄ）、及びバージョン識別（ｖｅｒｓｉｏｎ＿ｉｄ）と対応付けて記憶部３４１に記憶する。
なお、告知情報ＳＤＴＴに受信対象のソフトウェアの起動を指示する記述子が含まれている場合には、制御部３３１は、取得したソフトウェアを起動し、その機能を実行してもよい。
【００５１】
（受信装置の動作）
次に、受信装置３１の動作について説明する。図１２は、本実施形態に係る受信装置３１の動作を示すフローチャートである。
（ステップＳ１０１）分離部３１３は、チューナー３１１で受信した放送波から復号部３１２で復号された多重化データから告知情報ＳＤＴＴを検出し、検出した告知情報ＳＤＴＴを分離する。その後、ステップＳ１０２に進む。
（ステップＳ１０２）告知情報解析部３３２は、告知情報ＳＤＴＴにおいて優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）が設定されているか否かを検出する。その後、ステップＳ１０３に進む。
（ステップＳ１０３）受信経路判定部３３４は、優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）により受信経路について優先順位が指定されているか否かを判定する。指定されていると判定された場合には（ステップＳ１０３  ＹＥＳ）、ステップＳ１０５に進む。指定されていないと判定された場合には（ステップＳ１０３  ＮＯ）、ステップＳ１０４に進む。
【００５２】
（ステップＳ１０４）受信経路判定部３３４は、告知情報ＳＤＴＴで指定されたソフトウェアを放送でダウンロードすると判定する。その後、ステップＳ１０６に進む。
（ステップＳ１０５）受信経路判定部３３４は、告知情報ＳＤＴＴで指定されたソフトウェアを指定された優先順位でダウンロードすると判定する。ソフトウェア取得部３３５は、判定した優先順位で指定された受信経路で当該ソフトウェアをダウンロードする。その後、図１２に示す処理を終了する。
（ステップＳ１０６）受信状態判定部３３３は、放送で受信した配信データに基づいて障害が発生せずにダウンロードに成功したか否かを判定する。成功したと判定された場合には（ステップＳ１０６  ＹＥＳ）、ソフトウェア取得部３３５は、放送でダウンロードしたソフトウェアを取得し、図１２に示す処理を終了する。失敗したと判定された場合には（ステップＳ１０６  ＮＯ）、ステップＳ１０７に進む。
（ステップＳ１０７）受信経路判定部３３４は、告知情報ＳＤＴＴで指定されたソフトウェアを通信でダウンロードすると判定する。ソフトウェア取得部３３５は、当該ソフトウェアをサーバー装置２１から通信でダウンロードする。その後、図１２に示す処理を終了する。
【００５３】
以上に説明したように、本実施形態に係る受信装置３１は、自装置の動作に係るソフトウェアを取得するソフトウェア取得部３３５と、放送によるソフトウェアの受信において障害が検出されたとき、ソフトウェアの受信経路を通信（通信伝送路２２）と判定する受信経路判定部３３４とを備える。
この構成により、放送によるソフトウェアの受信において障害が検出されても、通信で当該ソフトウェアが取得されるので、より確実にソフトウェアを更新することができる。また、受信経路の優先順位が定められていないときは受信経路として放送が優先されるので、通信伝送路２２の負荷を軽減することができる。
【００５４】
（第２の実施形態）
本発明の第２の実施形態について、図面を参照しながら説明する。上述した実施形態と同一の構成については、同一の符号を付して説明を援用する。
本実施形態に係る受信装置３１は、制御部３３１に代えて制御部３３１ａを備える。
図１３は、本実施形態に係る制御部３３１ａの構成を示すブロック図である。制御部３３１ａは、告知情報解析部３３２、受信状態判定部３３３ａ、受信経路判定部３３４ａ、及びソフトウェア取得部３３５を含んで構成される。
【００５５】
受信状態判定部３３３ａは、分離部３１３から入力された配信データについて、チューナー３１１から入力された受信状況情報に基づいて受信状態が良好か否かを判定する。受信状況情報は、例えば、チューナー３１１で検出した放送波の電界強度、放送波で伝送された多重化データのエラーレート、ＣＮ値（Ｃａｒｒｉｅｒ−ｔｏ−Ｎｏｉｓｅ  Ｒａｔｉｏ）のいずれか又は組み合わせである。受信状態判定部３３３ａは、受信状態が良好か否かを示す受信状態情報を生成し、生成した受信状態情報を受信経路判定部３３４ａに出力する。受信状態判定部３３３ａは、例えば、次のいずれかに該当する場合には受信状態が劣悪と判定し、いずれも該当しない場合には受信状態が良好と判定する。（ａ）受信電界強度が所定の電界強度の閾値よりも低い、（ｂ）エラーレートが所定のエラーレートの閾値よりも高い、（ｃ）ＣＮ値が所定のＣＮ値の閾値よりも低い。
【００５６】
受信経路判定部３３４ａは、受信経路判定部３３４（図１１）と同様に告知情報ＳＤＴＴに優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）があると判定されたとき、受信に基づいて、どの受信経路を優先するか否かを判定する。例えば、優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）に設定された値が０ｘ０１または０ｘ０２である場合は、受信経路判定部３３４は、放送を優先すると判定する。優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）に設定された値が０ｘ０３である場合は、受信経路判定部３３４は、通信を優先すると判定する。また、優先フラグ（ｄｏｗｎｌｏａｄ＿ｐｒｉｏｒｉｔｙ）がないと判定されたとき、受信経路判定部３３４は、放送を優先すると判定する。
【００５７】
受信経路判定部３３４ａは、放送を優先すると判定した場合、受信状態判定部３３３ａから入力された受信状態情報に基づいて受信経路を判定する。受信経路判定部３３４ａは、受信状態情報が、受信状態が良好であることを示す場合には、受信経路を放送と定め、受信状態情報が、受信状態が劣悪であることを示す場合には、受信経路を通信と定める。受信経路判定部３３４ａは、通信と放送のどちらを受信経路として用いるかを示す受信経路信号をソフトウェア取得部３３５に出力する。
【００５８】
（受信装置の動作）
次に、受信装置３１の動作について説明する。図１４は、本実施形態に係る受信装置３１の動作を示すフローチャートである。図１４に示す処理は、ステップＳ１０１、Ｓ１０２、Ｓ１１３、Ｓ１１４、Ｓ１１５、Ｓ１０４、及びＳ１０７の処理を含む。ステップＳ１０１、Ｓ１０２、Ｓ１０４、及びＳ１０７の処理は、図１２に示す該当ステップの処理と同様であるため、その説明を援用する。
図１４に示す処理において、ステップＳ１０１、Ｓ１０２の処理が終了した後、ステップＳ１１３に進む。
【００５９】
（ステップＳ１１３）受信経路判定部３３４ａは、告知情報ＳＤＴＴに基づいて受信経路として放送を優先するか否かを判定する。放送を優先すると判定された場合（ステップＳ１１３  ＹＥＳ）、ステップＳ１１４に進む。通信を優先すると判定された場合（ステップＳ１１３  ＮＯ）、ステップＳ１０７に進む。
（ステップＳ１１４）受信状態判定部３３３ａには、分離部３１３から入力された配信データについて、チューナー３１１から入力された受信状況情報に基づいて受信状態が良好か否かを判定する。その後、ステップＳ１１５に進む。
（ステップＳ１１５）受信状態判定部３３３ａが判定した受信状態が良好である場合には（ステップＳ１１５  ＹＥＳ）、ステップＳ１０４に進む。受信状態判定部３３３ａが判定した受信状態が劣悪である場合には（ステップＳ１１５  ＮＯ）、ステップＳ１０７に進む。
【００６０】
以上に説明したように、本実施形態に係る受信装置３１は、放送波の受信状態を判定する受信状態判定部３３３ａを備え、受信状態判定部３３３ａは所定の受信状態よりも劣悪である状態をソフトウェアの受信障害と判定する。
この構成により、ソフトウェアの受信前に確認された放送の受信状態が劣悪であるときに、通信でソフトウェアが受信されるため、放送とは異なる受信経路である通信を用いてソフトウェアの取得を確実に行うことができる。
【００６１】
（第３の実施形態）
本発明の第３の実施形態について、図面を参照しながら説明する。上述した実施形態と同一の構成については、同一の符号を付して説明を援用する。
本実施形態に係る受信装置３１は、制御部３３１に代えて制御部３３１ｂを備える。
図１５は、本実施形態に係る制御部３３１ｂの構成を示すブロック図である。制御部３３１ｂは、告知情報解析部３３２、受信状態判定部３３３ｂ、受信経路判定部３３４ｂ、ソフトウェア取得部３３５、及び番組予約部３３６ｂを含んで構成される。
【００６２】
番組予約部３３６ｂには、ユーザーの操作による入力信号が入力され、入力信号により放送予定の番組のうち視聴または録画する番組と、当該視聴または録画する番組の受信時間を特定する。放送予定の番組とその放送時間は、分離部３１３で多重化データから分離されたセクションデータに含まれるＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ）に表される。番組予約部３３６ｂは、特定した番組と受信時間を示す番組予約情報を生成し、生成した番組予約情報を記憶部３４１に記憶する。
【００６３】
受信状態判定部３３３ｂは、記憶部３４１に番組予約情報が記憶されているか否かを判定する。記憶されていると判定したとき、受信状態判定部３３３ｂは、記憶部３４１から番組予約情報を読み取り、告知情報解析部３３２により告知情報ＳＤＴＴに基づいて特定された配信時間の一部または全部が、番組予約情報が示す番組の受信時間の一部または全部と重複するか否かを判定する。受信状態判定部３３３ｂは、重複するか否かを示す受信状態情報を受信経路判定部３３４ｂに出力する。
【００６４】
受信経路判定部３３４ｂは、受信経路判定部３３４ａと同様に、告知情報解析部３３２で解析された告知情報に基づいて、どの受信経路を優先するか否かを判定する。但し、受信経路判定部３３４ｂは、放送を優先すると判定し、かつ受信状態判定部３３３ｂから入力された受信状態情報が重複することを示す場合、告知情報ＳＤＴＴで指定されたソフトウェアを放送でダウンロードすると判定する。当該受信状態情報が重複しないことを示す場合には、受信経路判定部３３４ｂは、通信でダウンロードすると判定する。
【００６５】
（受信装置の動作）
次に、受信装置３１の動作について説明する。図１６は、本実施形態に係る受信装置３１の動作を示すフローチャートである。図１６に示す処理は、ステップＳ１０１、Ｓ１０２、Ｓ１１３、Ｓ１２４、Ｓ１２５、Ｓ１０４、及びＳ１０７の処理を含む。ステップＳ１０１、Ｓ１０２、Ｓ１０４、及びＳ１０７の処理は、それぞれ図１２に示すステップＳ１０１、Ｓ１０２、Ｓ１０４、及びＳ１０７の処理と同様であり、ステップＳ１１３の処理は、図１４に示すステップＳ１１３の処理と同様であるため、それらの説明を援用する。図１６に示す処理において、ステップＳ１０１、Ｓ１０２の処理が終了した後に行われるステップＳ１１３において、受信経路判定部３３４ｂが受信経路として放送を優先すると判定した場合には（ステップＳ１１３  ＹＥＳ）、ステップＳ１２４に進む。
【００６６】
（ステップＳ１２４）受信状態判定部３３３ｂは、番組予約部３３６ｂが生成した番組予約情報が記憶部３４１に記憶されているか否かを判定する。記憶されていると判定した場合、受信状態判定部３３３ｂは、番組予約情報を読み取り、告知情報ＳＤＴＴに表された配信時間の一部または全部が、読み取った番組予約情報が示す番組の受信時間の一部または全部と重複するか否かを判定する（予約の確認）。その後、ステップＳ１２５に進む。
【００６７】
（ステップＳ１２５）受信状態判定部３３３ｂが、告知情報ＳＤＴＴに表された配信時間の一部または全部が、読み取った番組予約情報が示す番組の受信時間の一部または全部と重複する（予約あり）と判定した場合には（ステップＳ１２５  ＹＥＳ）、ステップＳ１０７に進む。受信状態判定部３３３ｂが、告知情報ＳＤＴＴに表された配信時間の一部または全部が、読み取った番組予約情報が示す番組の受信時間の一部または全部と重複しないと判定した場合には（ステップＳ１２５  ＮＯ）、ステップＳ１０４に進む。
【００６８】
以上に説明したように、本実施形態に係る受信装置３１は、ソフトウェアの配信時間を示す告知情報を解析する告知情報解析部３３２と、番組の受信を予約する番組予約部３３６ｂとを備える。また、受信状態判定部３３３ｂは、告知情報が示す受信時間の少なくとも一部が、番組予約部３３６ｂが受信を予約した番組の受信時間の少なくとも一部と重複する状態を、ソフトウェアの受信障害と判定する。
この構成により、受信予約がなされた番組の受信のためにチューナーの占有が予想される場合でも、受信装置３１は、通信によって確実にソフトウェアを受信し、受信予約した番組の受信と両立することができる。
【００６９】
（第４の実施形態）
本発明の第４の実施形態について、図面を参照しながら説明する。上述した実施形態と同一の構成については、同一の符号を付して説明を援用する。
本実施形態に係る受信装置３１は、制御部３３１に代えて制御部３３１ｃを備える。図１７は、本実施形態に係る制御部３３１ｃの構成を示すブロック図である。制御部３３１ｃは、告知情報解析部３３２、受信状態判定部３３３ｃ、受信経路判定部３３４ｃ、及びソフトウェア取得部３３５ｃを含んで構成される。
【００７０】
受信状態判定部３３３ｃは、受信状態判定部３３３と同様な手法を用いて配信データの受信状態を判定する。但し、配信データの分離部３１３からの入力中、つまり、ダウンロード中に、そのダウンロードの障害を検出した場合には、受信状態判定部３３３ｃは、配信データの入力を中断する。また、受信状態判定部３３３ｃは、障害が生じたと判定した場合には、放送での障害の発生を示す障害フラグを受信経路判定部３３４ｃに出力する。
受信状態判定部３３３ｃは、送信装置１１が送信する配信データを構成するＤＤＢメッセージのうち、入力されたＤＩＩメッセージに記述されたモジュール識別を参照して入力が完了していない部分である未受信のＤＤＢメッセージのモジュールを特定する。受信状態判定部３３３ｃは、未受信のＤＤＢメッセージのモジュールを示す未受信情報を生成する。受信状態判定部３３３ｃは、入力されたＤＩＩメッセージ、入力が完了したＤＤＢメッセージ及び未受信情報をソフトウェア取得部３３５ｃに出力する。
【００７１】
受信経路判定部３３４ｃは、受信経路判定部３３４と同様に告知情報ＳＤＴＴに基づいて受信経路を判定する。但し、受信経路判定部３３４ｃは、配信データの放送での受信中に受信状態判定部３３３ｃから障害フラグが入力された場合には、受信経路を通信と判定し、通信を受信経路として用いることを示す受信経路信号をソフトウェア取得部３３５ｃに出力する。
【００７２】
ソフトウェア取得部３３５ｃは、告知情報解析部３３２で特定されたソフトウェアのうち、受信状態判定部３３３ｃから入力された未受信情報が示す未受信のＤＤＢメッセージを要求するための配信要求信号を生成する。ソフトウェア取得部３３５ｃには、受信経路判定部３３４ｃから受信経路として通信を用いることを示す受信経路信号が入力され、配信データの送信元を告知情報解析部３３２で特定されたサーバー装置２１と定める。ソフトウェア取得部３３５ｃは、生成した配信要求信号を告知情報解析部３３２で特定されたサーバー装置２１に送信する。サーバー装置２１は、配信要求信号で指定されたソフトウェアに係る配信データのうち、未受信のＤＤＢメッセージを受信装置３１に送信する。これにより、ソフトウェア取得部３３５ｃは、未受信情報が示すＤＤＢメッセージを受信することができる。ソフトウェア取得部３３５ｃは、入力が完了したＤＤＢメッセージと、新たに受信した未受信情報が示すＤＤＢメッセージのそれぞれから分割データを抽出し、抽出した分割データをモジュール識別（ｍｏｄｕｌｅＩｄ）の昇順に連結してソフトウェアを取得する。ソフトウェア取得部３３５ｃは、ソフトウェア取得部３３５と同様に取得したソフトウェアを記憶部３４１に記憶する。
【００７３】
（受信装置の動作）
次に、受信装置３１の動作について説明する。図１８は、本実施形態に係る受信装置３１の動作を示すフローチャートである。図１８に示す処理は、ステップＳ１０４、Ｓ１３６、及びＳ１３７の処理を含む。
【００７４】
（ステップＳ１０４）受信経路判定部３３４ｃは、告知情報ＳＤＴＴで指定されたソフトウェアを放送でダウンロードすると判定する。その後、ステップＳ１３６に進む。
（ステップＳ１３６）受信状態判定部３３３ｃは、放送でのダウンロード中に、そのダウンロードについて障害が発生していないか否かを検出する。障害を検出した場合には、受信状態判定部３３３ｃは、未受信のＤＤＢメッセージを特定する。その後、ステップＳ１３７に進む。
（ステップＳ１３７）受信経路判定部３３４ｃは、受信経路を通信と判定する。ソフトウェア取得部３３５ｃは、告知情報ＳＤＴＴで指定されたソフトウェアの一部が含まれる未受信のＤＤＢメッセージを、サーバー装置２１から通信でダウンロードする。その後、図１８に示す処理を終了する。
【００７５】
以上に説明したように、本実施形態に係る受信装置３１において、受信経路判定部３３４ｃは、放送によるソフトウェアの受信が完了する前に障害が検出されたとき、ソフトウェアの受信経路を通信（通信伝送路２２）と判定し、ソフトウェアのうち未受信の部分をソフトウェア取得部３３５に通信で受信させる。
この構成により、受信に係るソフトウェアのうち放送で受信が完了した部分を活用し、未受信の部分のみが通信で取得される。通信で受信する部分の情報量及び所要時間を低減することができるので、伝送容量が有限な通信リソースを節減することができる。
【００７６】
なお、本発明は上述した各実施形態に限定されるものではなく、特許請求の範囲に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的構成を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれるものである。
【００７７】
例えば、送信装置１１とサーバー装置２１は、単一の送信装置として構成されてもよい。受信装置３１において、再生部３１５と表示部３１７の両方または一方が省略されてもよい。また、音声復号部３１４と、映像復号部３１６のうちいずれかが省略されてもよい。
また、送信装置１１は、制御部３３１、３３１ａ、３３１ｂ、３３１ｃのいずれか、それらの一部の任意の組、または、それらの全てを備えてもよい。
上述した実施形態では、各種のデータを伝送するための伝送方式として、ＭＰＥＧ−２  Ｓｙｓｔｅｍｓで規定された方式を用いる場合を例にしたが、その他の伝送方式、例えば、ＭＰＥＧ−Ｈで規定されたＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）によるメディアトランスポート方式が用いられていてもよい。また、伝送に係るデータ形式、暗号化方式、符号化方式も、その伝送方式で規定された形式または方式が用いられてもよい。
【００７８】
また、上述した実施形態における送信装置１１の一部、サーバー装置２１の一部、受信装置３１の一部をコンピュータで実現するようにしてもよい。その場合、この制御機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、認識データ伝送装置に内蔵されたコンピュータシステムであって、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
【００７９】
なお、本発明は次の態様でも実施することができる。
（１）自装置の動作に係るソフトウェアを取得するソフトウェア取得部と、放送による前記ソフトウェアの受信において障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定する受信経路判定部と、を備える受信装置。
【００８０】
（２）放送波の受信状態を判定する受信状態判定部を備え、前記障害は前記受信状態が所定の受信状態よりも劣悪である状態である（１）の受信装置。
【００８１】
（３）前記ソフトウェアの配信時間を示す告知情報を解析する告知情報解析部と、番組の受信を予約する番組予約部と、前記障害は、前記告知情報が示す受信時間の少なくとも一部が、前記番組予約部が受信を予約した番組の受信時間の少なくとも一部と重複することである（１）または（２）の受信装置。
【００８２】
（４）前記受信経路判定部は、放送による前記ソフトウェアの受信が完了する前に前記障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定し、前記ソフトウェアのうち未受信の部分を前記ソフトウェア取得部に受信させる（１）から（３）のいずれかの受信装置。
【００８３】
（５）放送で受信装置の動作に係るソフトウェアを送信する送信装置と、前記ソフトウェアを記憶するサーバー装置と、前記受信装置とを備える放送システムであって、前記受信装置は、前記ソフトウェアを取得するソフトウェア取得部と、放送による前記ソフトウェアの受信において障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定する受信経路判定部と、を備える放送システム。
【００８４】
（６）受信装置における受信方法であって、前記受信装置の動作に係るソフトウェアを取得する取得過程と、放送による前記ソフトウェアの受信において障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定する受信経路判定過程と、を有する受信方法。
【００８５】
（７）受信装置のコンピュータに、前記受信装置の動作に係るソフトウェアを取得する取得手順、放送による前記ソフトウェアの受信において障害が検出されたとき、前記ソフトウェアの受信経路を通信と判定する受信経路判定手順を実行させるためのプログラム。
【符号の説明】
【００８６】
１…放送システム、
１１…送信装置、１１１…配信データ生成部、１１２…番組データ生成部、１１３…告知情報生成部、１１４…多重化部、１１５…暗号化部、１１６…送信部、１２…放送伝送路、１３…放送衛星、２１…サーバー装置、
２１０…制御部、２１１…配信データ取得部、２１２…配信データ配信部、２１３…通信部、２１４…記憶部、２２…通信伝送路、３１…受信装置、３１１…チューナー、３１２…復号部、３１３…分離部、３１４…音声復号部、３１５…再生部、３１６…映像復号部、３１７…表示部、３２１…通信部、３３１、３３１ａ、３３１ｂ、３３１ｃ…制御部、３３２…告知情報解析部、３３３、３３３ａ、３３３ｂ、３３３ｃ…受信状態判定部、３３４、３３４ａ、３３４ｂ、３３４ｃ…受信経路判定部、３３５、３３５ｃ…ソフトウェア取得部、３３６ｂ…番組予約部、３４１…記憶部
【図１】
2016092504.tif 000003
【図２】
2016092504.tif 000004
【図３】
2016092504.tif 000005
【図４】
2016092504.tif 000006
【図５】
2016092504.tif 000007
【図６】
2016092504.tif 000008
【図７】
2016092504.tif 000009
【図８】
2016092504.tif 000010
【図９】
2016092504.tif 000011
【図１０】
2016092504.tif 000012
【図１１】
2016092504.tif 000013
【図１２】
2016092504.tif 000014
【図１３】
2016092504.tif 000015
【図１４】
2016092504.tif 000016
【図１５】
2016092504.tif 000017
【図１６】
2016092504.tif 000018
【図１７】
2016092504.tif 000019
【図１８】
2016092504.tif 000020