(57)【特許請求の範囲】
【請求項１】
受信装置の側においてダウンロードするディジタル情報の取得先情報を放送する放送装置、
前記取得先情報に基づいて、当該ディジタル情報のダウンロードを行う受信装置、
を備えたディジタル放送システムであって、
前記放送装置は、当該ディジタル情報をダウンロードするための必要条件を必要条件情報として放送し、
前記受信装置は、当該ディジタル情報のダウンロードを開始する際に、前記必要条件情報を満足するか否か判断し、前記必要条件情報を満足する場合には、当該ディジタル情報をダウンロードするディジタル放送システムにおいて、
前記必要条件情報は、ダウンロードするプログラムの容量であり、
前記受信装置は、空き容量が前記プログラムの容量よりも大きい場合には、当該プログラムをダウンロードし、前記空き容量が前記プログラムの容量よりも小さい場合には前記プログラムをダウンロードしないこと、
を特徴とするディジタル放送システム。
【請求項２】
ディジタル放送システムのための放送装置であって、
受信装置の側においてダウンロードするディジタル情報の取得先情報を放送するとともに、
当該ディジタル情報をダウンロードするための必要条件を必要条件情報として放送する放送装置において、
前記必要条件情報は、ダウンロードするプログラムの容量であること、
を特徴とする放送装置。
【請求項３】
受信装置の側においてダウンロードするディジタル情報の取得先情報を放送する放送装置と、前記取得先情報に基づいて当該ディジタル情報のダウンロードを行う受信装置とを含むディジタル放送システムで用いられる受信装置であって、
当該ディジタル情報のダウンロードを開始する際に、当該ディジタル情報をダウンロードするための必要条件として前記放送装置から放送された必要条件情報を満足するか否か判断し、前記必要条件情報を満足する場合には、当該ディジタル情報をダウンロードする受信装置において、
前記必要条件情報は、ダウンロードするプログラムの容量であり、空き容量が前記プログラムの容量よりも大きい場合には、当該プログラムをダウンロードし、前記空き容量が前記プログラムの容量よりも小さい場合には前記プログラムをダウンロードしないこと、
を特徴とする受信装置。
【請求項４】
前記取得先情報は、前記ディジタル情報が記録されているインターネット上のＵＲＬであること、
を特徴とする請求項１記載のディジタル放送システム。
【請求項５】
前記受信装置は、ディジタル情報をダウンロードするために、インターネットへの接続部を備えていること、
を特徴とする請求項４記載のディジタル放送システム。
【請求項６】
受信装置の側においてダウンロードするディジタル情報の取得先情報を放送する放送装置と、前記取得先情報に基づいて当該ディジタル情報のダウンロードを行う受信装置とを含むディジタル放送システムで用いられる受信装置の一部を構成するコンピュータを、
当該ディジタル情報のダウンロードを開始する際に、当該ディジタル情報をダウンロードするための必要条件として前記放送装置から放送された必要条件情報を満足するか否か判断する手段と、
前記判断手段により前記必要条件情報を満足すると判断された場合には、当該ディジタル情報をダウンロードする手段と、
として機能させるための受信プログラムであって、
前記必要条件情報は、ダウンロードするプログラムの容量であり、空き容量が前記プログラムの容量よりも大きい場合には、当該プログラムをダウンロードし、前記空き容量が前記プログラムの容量よりも小さい場合には前記プログラムをダウンロードしないこと、
を特徴とする受信プログラム。
【請求項７】
放送者から受信者に対してコンテンツを放送するディジタル放送方法であって、
放送側は、受信側においてダウンロードするディジタル情報の取得先情報を放送するとともに、
当該ディジタル情報をダウンロードするための必要条件を必要条件情報として放送し、
受信側は、当該ディジタル情報のダウンロードを開始する際に、前記必要条件情報を満足するか否か判断し、前記必要条件情報を満足する場合には、当該ディジタル情報をダウンロードするディジタル放送方法において、
前記必要条件情報は、ダウンロードするプログラムの容量であり、
前記受信装置は、空き容量が前記プログラムの容量よりも大きい場合には、当該プログラムをダウンロードし、前記空き容量が前記プログラムの容量よりも小さい場合には前記プログラムをダウンロードしないこと、
を特徴とするディジタル放送方法。
【請求項８】
前記取得先情報は、前記ディジタル情報が記録されているインターネット上のＵＲＬであること、
を特徴とする請求項２記載の放送装置。
【請求項９】
前記取得先情報は、前記ディジタル情報が記録されているインターネット上のＵＲＬであること、
を特徴とする請求項３記載の受信装置。
【請求項１０】
前記受信装置は、ディジタル情報をダウンロードするために、インターネットへの接続部を備えていること、
を特徴とする請求項９記載の受信装置。
【発明の詳細な説明】
【０００１】
【発明の技術分野】
この発明は放送システムに関し、特に、受信側における不要な処理を排除して、処理の高速化を図るものである。
【０００２】
【従来の技術および課題】
衛星放送、地上波放送などのディジタル放送において、通常の画像・音声番組に付加して、データ放送が行われている。これにより、視聴者に対してインタラクティブなサービスを提供することなどが可能となっている。また、データ放送だけで、独立した番組として提供されている場合もある。
【０００３】
図１に、データ放送の概要を示す。コンテンツ２には、複数のコンテンツ要素ＣＥ１〜ＣＥｎが含まれている。各コンテンツ要素ＣＥ１〜ＣＥｎには、それぞれテーブルＩＤが付されている。１組のコンテンツ要素（つまりコンテンツ２）は、繰り返し同じものが放送される。
【０００４】
なお、各コンテンツ要素は、さらに、複数のパケットに分割されて（パケット化されて）放送される。受信装置側では、分割されたパケットを再構築してコンテンツ要素を得る。
【０００５】
コンテンツ要素ＣＥ１は、たとえば、ＨＴＭＬ言語で記述される。したがって、表示すべき画像のテーブルＩＤや、リンク先のテーブルＩＤが記述される。
【０００６】
受信装置側では、まず、コンテンツ要素ＣＥ１を取り込んで解釈し、参照すべき画像をテーブルＩＤに基づいて取り込む。ただし、取り込みたいテーブルＩＤを持ったコンテンツ要素が、１組のコンテンツ要素の中で、既に送信されたものである場合には、取り込むことができない。しかし、同じコンテンツ２が繰り返し送信されているので、次の組のコンテンツ要素中から、所望のテーブルＩＤを持つコンテンツ要素を取り込むことができる。
【０００７】
受信装置の操作者が、リモコン等によって、リンク先を選択決定した場合にも、上記と同様にして、１組コンテンツ要素中に含まれるリンク先のコンテンツ要素を取り込む。
【０００８】
上記のように、１組のコンテンツ要素を繰り返して放送することにより、受信装置側で、全てのコンテンツ要素を記憶しなくとも、リンクや参照の処理を行うことができる。
【０００９】
なお、受信装置側の記憶容量に余裕があれば、一旦、１組のコンテンツを全て記憶し、リンクや参照の処理を行うようにすることもできる。
【００１０】
データ放送におけるコンテンツの具体的な例を、図２に示すようなＨＴＭＬ文書を用いて説明する。前記ＨＴＭＬ文書を、受信装置のブラウザ・アプリケーション・プログラムにて表示すると図３のようになる。つまり、ブラウザアプリケーションは、図２のようなＨＴＭＬ文書の記述内容を解釈して、図３のような画面を表示する。
【００１１】
図２の２０１は、オブジェクトの位置や大きさを指定している個所で、例えば、２０１ａは、ブラウザ表示される際、左から５０ピクセル、上から３００ピクセルの位置に、幅が３００ピクセル、高さ５００ピクセルの大きさの表示するように指定している。また、図２の２０２は前記２０１において、具体的にどのようなオブジェクトを表示させるかを指定することや、オブジェクトが選択された際の動作などを記述する個所である。例えば、２０２ａは、http://www/dirA/001/s1.png（テーブルＩＤ）にあるイメージファイルを表示するように指定しており、更に、前記イメージファイルの近傍に「このイメージはＰＮＧファイルです」と表示するように記述されている。
【００１２】
上記のようなＨＴＭＬ形式のコンテンツを復元する場合、受信装置としては、放送局側からパケット化して送信されてくるストリーム（トランスポートストリームという）中から、必要なパケットを取得してコンテンツ要素を再構築し、さらに、参照されている画像データ等のコンテンツ要素を復元しなければならない。
【００１３】
しかしながら、画像データ等には多くの規格があり、受信装置によって、全ての形式の画像データを復元できるとは限らない。つまり、受信装置に、当該画像データの形式を復元するための機能（ハードウエア回路やソフトウエア）が備わっていない場合には、当該形式の画像データを復元することはできない。
【００１４】
上記にも拘わらず、受信装置は、パケットを取得し、コンテンツ要素（図２参照）を復元し、さらに、復元したコンテンツ要素の記述（図２の２０２ａ参照）を取得しなければ、当該画像データが復元可能であるか否かを判断することができない。つまり、参照されている画像データ等のファイル名の拡張子を取得して、はじめて復元可能な画像データであるか否かを判断することができる。
【００１５】
また、画像データによっては、バージョンが異なると復元ができないこともあり、このような場合には、拡張子だけでは復元可能かどうかを判断できない。かかる場合には、実際に画像データを取得し、復元を行うアプリケーションに渡してはじめて、復元ができないことを知ることになる。また、場合によっては、誤動作を生じる恐れもあった。
【００１６】
上記いずれの場合においても、復元できない画像データが含まれていることを判断するまでに、多くの処理をしなければならなかった。たとえば、一部に表示できない画像データが含まれていれば、全てまたは一部のコンテンツを表示しないような処理を行う場合には、上記判断に至るまでの処理が無駄となり、また、時間も要するという問題があった。
【００１７】
上記との問題は、一旦、１組のコンテンツ要素を記憶した上で処理を行う方式を採用した場合にも生じる。
【００１８】
さらに、復元可能なデータであっても、当該データのサイズが大きすぎるなどの要因で、データの取得そのものが不可能な場合もある。このような場合も、やはり、結果的に無駄な処理を行うこととなる。
【００１９】
この発明は、上記のような問題点に鑑みて、データ取得の早い段階で、容易に、コンテンツの復元が可能であるか否かを判断できる放送システムを提供することを目的とする。
【００２０】
また、この発明は、データ取得の前に、当該データを取得することが可能であるか否かを判断できる放送システムを提供することを目的とする。
【００２１】
【課題を解決するための手段】
(1)この発明のディジタル放送システムは、放送装置は、受信装置の側においてダウンロードするディジタル情報の取得先情報を放送するとともに、当該ディジタル情報をダウンロードするための必要条件を必要条件情報として放送し、前記受信装置は、当該ディジタル情報のダウンロードを開始する際に、必要条件情報に基づいて、当該ディジタル情報がダウンロード可能であるか否かを判断する。さらに前記必要条件情報は、ダウンロードするプログラムの容量であり、空き容量が前記プログラムの容量よりも大きい場合には、当該プログラムをダウンロードし、前記空き容量が前記プログラムの容量よりも小さい場合には前記プログラムをダウンロードしない。
したがって、前記プログラムをダウンロードする前に、予め、ダウンロード可能であるか否かを判断することができる。
【００３９】
(4)この発明のディジタル放送システムは、取得先情報が、ディジタル情報が記録されているインターネット上のＵＲＬであることを特徴としている。したがって、インターネットを介してディジタル情報を取得する際に、予め、ダウンロードが可能であるか否かを知ることができる。
【００４０】
(6)この発明のディジタル放送システムは、取得先情報が、放送により送られてくるディジタル情報を特定するための情報であることを特徴としている。したがって、放送によってディジタル情報を取得する際に、予め、ダウンロードが可能であるか否かを知ることができる。
【００４１】
この発明において、「復元」とは、暗号化されている等によりそのまま出力して再生できないコンテンツや、ＪＡＶＡ等の対応するプログラムがないと再生できないコンテンツなどを、再生可能な状態にすることをいう。
【００４２】
「ダウンロード」とは、外部からデータを取り込んで、一時的もしくは固定的に記録することをいう。
【００４３】
「受信装置」とは、少なくともコンテンツの復元処理を行う装置をいい、いわゆるセットトップボックスや、セットトップボックスの機能を内蔵したテレビ受像機を含む概念である。
【００４４】
「プログラムを記録した記録媒体」とは、プログラムを記録したＲＯＭ、ＲＡＭ、フレキシブルディスク、ＣＤ−ＲＯＭ、メモリカード、ハードディスク等の記録媒体をいう。また、電話回線、搬送路等の通信媒体も含む概念である。ＣＰＵに接続されて、記録されたプログラムが直接実行されるハードディスクのような記録媒体だけでなく、一旦ハードディスク等にインストールした後に実行されるプログラムを記録したＣＤ−ＲＯＭ等の記録媒体を含む概念である。さらに、ここでいうプログラムには、直接実行可能なプログラムだけでなく、ソース形式のプログラム、圧縮処理がされたプログラム、暗号化されたプログラム等を含む。
【００４５】
【発明の実施の形態】
１．第１の実施形態
1.1  放送装置
図４に、この発明の一実施形態による放送装置１０の構成を示す。この実施形態では、通常の映像音声データにＨＴＭＬなどのディジタルデータが付加されて番組内容が構成されている。なお、ディジタルデータだけで番組を構成するようにしてもよい。
【００４６】
映像音声データ１２は、圧縮処理部１４において圧縮され、多重化処理部２０に与えられる。圧縮処理された映像音声データ１２は、多重化処理部２０に与えられる。ＨＴＭＬデータなどのディジタルデータ１６は、圧縮処理装置１８において圧縮され、多重化処理部２０に与えられる。圧縮処理されたディジタルデータ１６は、多重化処理部２０に与えられる。
【００４７】
多重化処理部２０には、他のサービスのコンテンツも与えられているが、ここでは省略している。多重化処理部２０は、与えられた複数のサービスの映像音声データ、ディジタルデータを、パケット化して多重化する。この際、多重化のための制御データを生成する。
【００４８】
パッケト化されて多重化されたデータは、スクランブル処理部２２においてスクランブル処理される。スクランブルに用いた鍵は、多重化処理部２０に与えられ、制御データの一部に含められる。
【００４９】
スクランブルがかけられたデータは、変調部２４において変調され、トランスポートストリームとして、衛星を介して放送される。
【００５０】
図５に、４つのサービスが多重化されたトランスポートストリームの、パケット多重化の状態を示す。制御データＰＡＴには、それぞれのサービスごとの制御データＰＭＴ１〜ＰＭＴ４を識別するためのパケットＩＤが記述される。たとえば、制御データＰＭＴ２には、当該サービスを構成するコンテンツ（映像音声データ、ＨＴＭＬデータ）を識別するためのパケットＩＤが記述される。さらに、当該コンテンツのスクランブルを解くための鍵データが記述されたＥＣＭデータを識別するためのパケットＩＤも記述される。したがって、制御データＰＭＴ２を取得して解読することにより、当該サービスに含まれる映像音声データおよびＨＴＭＬデータを取得することができる。
【００５１】
また、ＨＴＭＬデータ相互間の参照やリンクは、図６に示すようにして実現している。ＨＴＭＬデータには、上記のように特定のパケットＩＤが与えられる。しかしこれらＨＴＭＬデータ（画像等のデータを含む）には、それぞれのコンテンツとにテーブルＩＤが与えられている。このテーブルＩＤを用いて、参照やリンクを実現している。
【００５２】
この実施形態では、制御データＰＭＴの中に、図７Ａに示すようなコンテンツ種別情報を記述している。コンテンツ種別情報とは、当該ＰＭＴに対応するＨＴＭＬコンテンツ中において参照している画像データの種類を記述した情報である。この実施形態では、コンテンツ種別情報は、ビットフラグの形式で示されている。先頭のビットが「１」であれば、コンテンツにはＰＮＧ形式の画像データが含まれており、受信装置側において、ＰＮＧデコーダが必要であることを示している。先頭のビットが「０」であれば、コンテンツにはＰＮＧ形式の画像データが含まれておらず、受信装置側において、ＰＮＧデコーダが必要でないことを示している。
【００５３】
以下の各ビットは、上記と同様に、ＸＭＬ形式のデータ（ＸＭＬパーザが必要）、ＧＩＦ形式のデータ（ＧＩＦデコーダが必要）、ＪＰＥＧ形式のデータ（ＪＰＥＧデコーダが必要）が含まれていることを示している。
【００５４】
図８に、制御データＰＭＴのデータ構造を示す。制御データＰＭＴには、記述領域としてのdescriptor()５０が用意されている。この実施形態では、descriptor()５０中に、コンテンツ種別情報を記述するようにしている。もちろん、他の領域に記述するようにしても良い。
【００５５】
descriptorには、さらに、複数のdescriptorが記述されている。この例では、図９に示すように、data_component_descriptor()中の、additional_data_component_info中に、コンテンツ種別情報を記述するようにしている。
【００５６】
なお、一般的なdescriptorの記述については、ARIB STD-B10 1.2版を参照のこと。
【００５７】
以上のようにして、コンテンツ種別情報が含まれたディジタルデータが放送される。
【００５８】
1.2  受信装置
図１０に、第１の実施形態による受信装置の全体構成を示す。この実施形態における受信装置７４は、受信部６２と復元部７６を備えている。なお、映像音声出力部７２を含めて、受信装置７４を構成するようにしてもよい。
【００５９】
アンテナ６０によって捕捉された電波は、受信部６２によって１つのトランスポートストリームとして復調される。このトランスポートストリームは、復元部７６に与えられる。復元部７６の選別部６４は、受信制御部６６の制御にしたがって、受け採ったトランスポートストリームから所望のサービスに関するパケットを選択する。選択されたパケットは、出力部７０に与えられて、出力信号（たとえば、ＮＴＳＣのようなコンポジット信号）に復元される。映像・音声出力部７２（たとえばテレビ受像機）は、この出力信号を受けて、映像および音声を出力する。
【００６０】
受信制御部６６は、選別部６４によって、トランスポートストリームから選択したコンテンツ種別情報を取得する。さらに、このコンテンツ種別情報と、復元可能コンテンツ種別情報記録部６８に記録されている復元か能コンテンツ種別情報とを比較する。これにより、復元しようとするコンテンツが、復元可能なものであるか否かを判断し、その判断結果に基づいて、当該コンテンツに対する処理内容を変える。たとえば、当該コンテンツの復元を中止する等の処理を行う。
【００６１】
図１１に、図１０の受信装置をＣＰＵを用いて実現した場合のハードウエア構成を示す。ＣＰＵ６６は、不揮発性メモリ６８（記録媒体）に記録されたプログラムにしたがって各部の制御を行う。操作入力部６１は、操作者の操作を受け付けるものであり、受信装置７４に設けられた入力ボタンもしくはリモコン受信部である。デ・スクランブラ６３は、スクランブルを解除するためのものである。スクランブル解除に用いる鍵は、放送されてくるＥＣＭデータを、ＩＣカード６９において解読して得ることができる。選別部であるトランスポートストリーム・デコーダ（ＴＳデコーダ）６４は、トランスポートストリームから、所望のパケットを分離するものである。
【００６２】
また、不揮発性メモリ６８には、図７Ｂに示すような、復元可能コンテンツ種別情報が記録されている。図７Ｂにおいては、ＰＮＧ、ＸＭＬが復元可能であり（１が記録されている）、ＧＩＦ、ＪＰＥＧが復元不可能であることが示されている（０が記録されている）。つまり、この受信装置は、ＰＮＧデコーダ、ＸＭＬパーザは備えているが、ＧＩＦデコーダ、ＪＰＥＧデコーダは備えていないことを示している。
【００６３】
図１２に、不揮発性メモリ６８に記録された受信処理プログラムのフローチャートを示す。ＣＰＵ６６は、チューナ６２を制御して、所望のトランスポートストリームを受信するように制御する。また、制御データＰＡＴのパケットＩＤ（以下ＰＩＤという）をＴＳデコーダ６４にセットする。なお、ＰＡＴのＰＩＤは、あらかじめ固定的に定められている。
【００６４】
ＴＳデコーダ６４は、これにより制御データＰＡＴを分離し、メモリ６７に出力する（ステップＳ１）。ＣＰＵ６６は、制御データＰＡＴに基づいて、所望のサービスの制御データＰＭＴのＰＩＤを認識する（ステップＳ２、図５参照）。ＴＳデコーダ６４は、これにより制御データＰＭＴを分離し、メモリ６７に出力する（ステップＳ３）。ＣＰＵ６６は、制御データＰＭＴに基づいて、所望のサービスの制御データＥＣＭのＰＩＤを認識する。さらに、このＥＣＭのＰＩＤをＴＳデコーダ６４にセットして、制御データＥＣＭを取得する（ステップＳ４）。
【００６５】
次に、ＣＰＵ６６は、制御データＥＣＭをＩＣカード６９に送信し、ＩＣカード６９から鍵を取得する。さらに、この鍵を、デ・スクランブラ６３にセットする（ステップＳ５）。これにより、所望のサービスの映像音声データやＨＴＭＬデータ等は、スクランブルが解除される。
【００６６】
さらに、ＣＰＵ６６は、ＴＳデコーダ６４に、映像・音声データのＰＩＤをセットする（ステップＳ６）。これにより、ＴＳデコーダ６４は、映像・音声データを、ＡＶデコーダ７０に出力する。したがって、ＴＶセット７２には、映像・音声が出力される。
【００６７】
次に、ＣＰＵ６６は、不揮発性メモリ６８に記録されている復元可能コンテンツフラグ（図７Ｂ参照）を読み出す。そして、制御データＰＭＴに含まれているコンテンツ種別フラグ（図７Ａ参照）と比較する。復元可能コンテンツ種別フラグが「０」であるにもかかわらず、コンテンツ種別フラグが「１」であるビットがあるか否かを判断する（ステップＳ７）。つまり、送信されてきているＨＴＭＬデータに、当該受信装置において復元できない種類のデータが含まれているか否かを判断する。
【００６８】
復元できると判断した場合には、復元に必要なアプリケーションを起動する（ステップＳ９）。たとえば、１番目のビットが「１」である場合には、不揮発性メモリ６８に記録されているＰＮＧデコーダを起動する。続いて、ＣＰＵ６６は、ＴＳデコーダ６４に、ＨＴＭＬデータのＰＩＤをセットする（ステップＳ１０）。これにより、ＴＳデコーダ６４は、ＨＴＭＬデータをメモリ６７に出力する。ＣＰＵ６６は、不揮発性メモリ６８に記録されているブラウザプログラムに基づき、このＨＴＭＬデータを解釈して、ＡＶデコーダ７０に出力する。
【００６９】
さらにＨＴＭＬデータにおいて参照されているＰＮＧデータのテーブルＩＤ（図２の２０２a参照）をＴＳデコーダ６４にセットし、ＰＮＧデータを取得する。このＰＮＧデータは、ＰＮＧデコーダによって復元され、ＡＶデコーダ７０に出力される。
【００７０】
したがって、ＡＶデコーダ７０では、映像・音声データに重ねるように、ＨＴＭＬデータ、ＰＮＧデータが合成されて出力される。
【００７１】
一方、ステップＳ７において、復元できないものが送信されてきていると判断した場合には、当該ＨＴＭＬデータなどの復元処理を行わない（ステップＳ８）。これにより、無駄な、アプリケーションの起動処理などを行わずにすむ。なお、この場合には、図１３に示すように、映像・音声データのみが表示され、ＨＴＭＬデータが表示されるべき部分には、表示できない旨の注意が表示される。
【００７２】
なお、上記ステップＳ７のフラグの比較処理を詳細に示すと、図１４のようになる。このフローチャートからも明らかなように、コンテンツ種別フラグが「１」、」復元可能コンテンツ種別フラグが「０」のビットが、１つでもあれば、エラーメッセージを表示するようにしている。また、復元できないコンテンツ種別があると判明した時点で、以下のビットについての検討を行わないようにしている。これにより、処理の迅速化を図っている。
【００７３】
1.3  他の実施形態
なお、上記実施形態では、いずれかのコンテンツ要素が復元できない場合には、ＨＴＭＬデータすべての復元を行わないようにした。しかし、復元可能なコンテンツ要素のみを復元するようにしてもよい。
【００７４】
たとえば、図７のような場合には、図２に示すようなＨＴＭＬデータに対しては、図１５のような表示が行われる。つまり、ＨＴＭＬのテキストデータ及び復元可能であるＰＮＧデータだけが表示される。
【００７５】
また、上記実施形態では、制御データＰＭＴ中にコンテンツ種別情報を記述しているが、制御データＥＩＴ(Evevt Information Table)中に記述するようにしてもよい。なお、制御データＥＩＴは、番組の名称、放送日時、内容説明など、番組に関する情報を記述するものである。
【００７６】
さらに、上記実施形態では、固定長のコンテンツ種別フラグ（復元可能コンテンツフラグ）を用いた。しかし、図１６に示すように、フラグビット長を記述することにより、可変長のフラグとしてもよい。
【００７７】
また、上記実施形態では、ビットフラグによってコンテンツ種別情報を表した。しかし、図１７に示すように、コンテンツ種別を記述したものをコンテンツ種別情報として用いてもよい。この場合には、復元可能コンテンツ種別情報も、同じように、コンテンツ種別を記述したものを用いる。コンテンツ種別情報に記述されたコンテンツ種別が、復元可能コンテンツ種別情報中になければ、復元ができないと判断することができる。
【００７８】
また、コンテンツ種別として、バージョン情報を含めてもよい。たとえば、同じＧＩＦデータであっても、バージョンによっては、正しい復元ができない場合もあるからである。バージョン情報もコンテンツ種別に含めることにより、かかる場合にも対応することができる。
【００７９】
さらに、図１８に示すように、コンテンツ種別情報に取扱情報を付加してもよい。この取扱情報が「１」であれば、いずれか１つのコンテンツ要素が復元できなければ、すべてのコンテンツを復元しないことを示す（図１３参照）。また、「０」であれば、復元可能なコンテンツ要素のみを復元することを示す（図１５参照）。この取扱情報により、コンテンツ作成者の意図を反映した放送を行うことが可能となる。
【００８０】
また、上記実施形態では、イメージデータ等について説明したが、音声データ等についても適用することができる。
【００８１】
なお、上述の他の実施形態は、以下の第２の実施形態以降においても、同様に適用することができる。
【００８２】
２．第２の実施形態
上記実施形態では、番組を構成するコンテンツ全体について、コンテンツ種別情報を送信するようにしている。しかし、図１９に示すように、複数のコンテンツ５００〜５１０を繰り返し送信する場合に、各コンテンツについて、コンテンツ種別情報を記述して放送するようにしてもよい。つまり、図２０に示すように、各コンテンツごとに、コンテンツ種別情報を記述する。
【００８３】
この場合、コンテンツ種別情報は、制御データＤＩＩ(Download Info Indication)に記述することが好ましい。図２１に、制御データＤＩＩの構造を示す。この実施形態では、moduleInfoByte中の、Control_data_byteに記述するようにしている。
【００８４】
この実施形態では、番組を構成する複数の各コンテンツごとに、表示可能であるか否かを判断することができる。これにより、より詳細に表示の制御を行うことができる。なお、処理の流れは、基本的に、図１２、図１４と同じである。
【００８５】
３．第３の実施形態
3.1  受信装置
図２２に、第３の実施形態の全体図を示す。放送装置３００からは、コンテンツに対し、コンテンツ種別情報およびＵＲＬ（取得先情報）が付されて放送される（図中▲１▼）。受信装置７４では、先の実施形態と同様にして、当該コンテンツの復元に必要なプログラム（またはハードウエア）が、当該受信装置７４に備わっているかを判断する（図中▲２▼）。備わっていなければ、ＵＲＬに基づいて、インターネットを介して、ダウンロードサイト４００にアクセスする。そして、このダウンロードサイトから、復元に必要なプログラムをダウンロードする（図中▲３▼）。受信装置７４は、このプログラムを用いて、コンテンツの復元を行う（図中▲４▼）。なお、受信装置７４は、このプログラムのダウンロードに応じて、復元可能コンテンツ種別情報を更新する。
【００８６】
以上のように、この実施形態では、コンテンツの種別情報とともに、当該種別のコンテンツを復元するためのプログラムの取得先情報を放送するようにしている。したがって、容易にかつ自動的プログラムを取得して、コンテンツの復元を行うことができる。
【００８７】
この実施形態における受信装置７４の全体構成を、図２３に示す。受信制御部６６は、復元できないコンテンツがあることを判断すると、取得先情報を取得する。受信制御部６６は、この取得先情報を、プログラム取得部７１に送る。プログラム取得部７１は、インターネットを介してダウンロードサイトに接続し、プログラムをダウンロードする。受信制御部６６は、このプログラムを用いて、コンテンツの復元を行う。
【００８８】
図２４に、図２３の受信装置７４を、ＣＰＵを用いて実現した場合のハードウエア構成を示す。この実施形態では、インターネットに接続するための通信回路７１が設けられている。
【００８９】
また、この実施形態において、送信装置から放送されてくるコンテンツ種別情報および取得先情報を、図２５に示す。１行目の「１」は、コンテンツにＰＮＧデータが含まれていることを示すコンテンツ種別情報である。また、「http://www.mei.co.jp/PNG」は、ＰＮＧデコーダプログラムのダウンロードサイトのＵＲＬ（取得先情報）である。２行目の「０」は、コンテンツにＸＭＬデータが含まれていないことを示している。この場合、ダウンロードサイトのＵＲＬは記述されていない。なお、このコンテンツ種別情報、取得先情報は、第１の実施形態のように、ＰＭＴやＥＩＴに記述してもよく、第２の実施形態のようにＤＩＩに記述してもよい。
【００９０】
図２６に、不揮発性メモリ６８に記録されている受信処理プログラムのフローチャートを示す。ステップＳ１〜Ｓ６までは、図１２と同じである。ステップＳ５１において、ＣＰＵ６６は、図２５の最初の行の「１」に注目する。そして、不揮発性メモリに記録されている復元可能コンテンツ種別フラグの１番目と、比較する（ステップＳ５２）。その結果、当該コンテンツが復元可能であると判断すると、次の行に注目する（ステップＳ５４）。
【００９１】
当該コンテンツが復元できないと判断すると、当該行に対応づけて記述されたＵＲＬを取得する。ＣＰＵ６６は、このＵＲＬを通信回路７１に渡す。通信回路７１は、インターネットに接続し、このＵＲＬのサイトにアクセスしてプログラムをダウンロードする（ステップＳ５３）。ダウンロードしたプログラムは、不揮発性メモリ６８に記録される。なお、このダウンロードにより、当該種類のコンテンツが復元可能となったので、復元可能コンテンツ種別フラグを更新する。つまり、「０」を「１」に変える。
【００９２】
すべての行について上記の処理を終えれば（ステップＳ５５）、コンテンツの表示出力を行う（ステップＳ５６）。
【００９３】
3.2  その他の実施形態
上記実施形態では、インターネットを介して、プログラムを取得するようにしている。しかしながら、放送によってプログラム取得するようにしてもよい。この場合、取得先情報としては、プログラムを放送しているサービスのＰＭＴなどを記述すればよい。
【００９４】
４．第４の実施形態
この実施形態では、図２７に示すように、必要条件情報を取得先情報に付加するようにしている。この必要条件情報とは、プログラムをダウンロードする際に、受信装置側において必要な条件（必要な記憶空き容量など）をいうものである。図２７においては、ＰＮＧデコーダのプログラムをダウンロードするためには、最低、３００ｋバイトの空き容量が必要であることが示されている。
【００９５】
図２８に、この実施形態における受信処理プログラムのフローチャートを示す。なお、ステップＳ１〜Ｓ６は、図２６と同じである。受信装置のＣＰＵ６６は、ダウンロードを開始する前に、必要条件情報を取得して、ダウンロード可能かどうかを判断する（ステップＳ５７）。ダウンロード可能であれば、図２６と同様にして、ダウンロードを行う。また、ダウンロードが不可能であれば、エラー表示を行う（ステップＳ５８）。
【００９６】
この実施形態によれば、必要条件情報をダウンロードに先駆けて取得することにより、途中までダウンロードが進行した状態で、記憶容量等によりダウンロードを中止せざるを得ないような時間のロスを防止することができる。
【００９７】
なお、上記実施形態では、復元可能でないコンテンツが含まれていた場合に行うプログラムのダウンロードについて説明した。しかし、ダウンロードに必要な条件を、必要条件情報としてあらかじめ送信しておく方法は、ダウンロード一般に適用できるものである。たとえば、１組のコンテンツを、一旦、受信装置に記憶して、操作者の選択によってコンテンツを表示するような場合において、当該１組のコンテンツを記憶（ダウンロード）する際にも適用することができる。
【００９８】
５．その他
上記各実施形態では、衛星放送について説明したが、地上波放送、ケーブルテレビ放送、インターネット放送等にも適用することができる。
【００９９】
また、上記各実施形態では、放送を例として説明したが、送信装置と受信装置が一対一に対応するような、送受信システムにも適用することができる。
【図面の簡単な説明】
【図１】データ放送におけるデータ送信状態を示す図である。
【図２】ＨＴＭＬデータの例を示す図である。
【図３】図２のデータの表示画面を示す図である。
【図４】放送装置１０の構成を示す図である。
【図５】パケット構造を示す図である。
【図６】ＨＴＭＬデータの参照やリンクを実現する方法を示す図である。
【図７】コンテンツ種別情報および復元可能コンテンツ種別情報を示す図である。
【図８】ＰＭＴの構造を示す図である。
【図９】ＰＭＴの構造の詳細を示す図である。
【図１０】受信装置の全体構成を示す図である。
【図１１】受信装置のハードウエア構成を示す図である。
【図１２】受信処理のフローチャートを示す図である。
【図１３】表示画面を示す図である。
【図１４】受信処理の詳細を示す図である。
【図１５】表示画面を示す図である。
【図１６】可変長としたコンテンツ種別情報を示す図である。
【図１７】他の形式によるコンテンツ種別情報を示す図である。
【図１８】取扱情報を付加したコンテンツ種別情報を示す図である。
【図１９】一組のコンテンツを示す図である。
【図２０】図１９の各コンテンツに対するコンテンツ種別情報を示す図である。
【図２１】ＤＩＩの構造を示す図である。
【図２２】第３の実施形態の全体構成を示す図である。
【図２３】受信装置の全体構成を示す図である。
【図２４】受信装置のハードウエア構成を示す図である。
【図２５】コンテンツ種別情報および取得先情報を示す図である。
【図２６】受信処理のフローチャートを示す図である。
【図２７】必要条件情報を示す図である。
【図２８】受信処理のフローチャートを示す図である。
【符号の説明】
６０・・・アンテナ
６２・・・受信部
７４・・・受信装置
７６・・・復元部
【図１】
0004794029.tif 000002
【図２】
0004794029.tif 000003
【図３】
0004794029.tif 000004
【図４】
0004794029.tif 000005
【図５】
0004794029.tif 000006
【図６】
0004794029.tif 000007
【図７】
0004794029.tif 000008
【図８】
0004794029.tif 000009
【図９】
0004794029.tif 000010
【図１０】
0004794029.tif 000011
【図１１】
0004794029.tif 000012
【図１２】
0004794029.tif 000013
【図１３】
0004794029.tif 000014
【図１４】
0004794029.tif 000015
【図１５】
0004794029.tif 000016
【図１６】
0004794029.tif 000017
【図１７】
0004794029.tif 000018
【図１８】
0004794029.tif 000019
【図１９】
0004794029.tif 000020
【図２０】
0004794029.tif 000021
【図２１】
0004794029.tif 000022
【図２２】
0004794029.tif 000023
【図２３】
0004794029.tif 000024
【図２４】
0004794029.tif 000025
【図２５】
0004794029.tif 000026
【図２６】
0004794029.tif 000027
【図２７】
0004794029.tif 000028
【図２８】
0004794029.tif 000029