JP2012039604A - 放送サービスの送信装置 - Google Patents

Abstract

【課題】コンテンツファイルを受信側で蓄積予約させるのに必要とされる番組スケジュールテーブルを送信する送信装置を提供する。
【解決手段】送信装置１は、サービスＩＤと、イベント識別子と、コンテンツタイプ情報とを含む番組スケジュールテーブルを生成する前記番組スケジュールテーブル生成手段と、前記番組スケジュールテーブルを所定間隔で送信する番組スケジュールテーブル送信手段と、前記番組スケジュールテーブル内で関連付けたイベント識別子を有するコンテンツファイルをデータブロックにてカルーセル方式で送信するコンテンツファイル送信手段とを備える。前記イベント識別子は、前記データブロックとともに放送するヘッダ情報にも記述され、前記コンテンツファイル送信手段は、受信側でコンテンツタイプに応じた蓄積動作を行うよう、前記ヘッダ情報と、前記コンテンツタイプ情報の組み合わせを制御して当該コンテンツファイルを送信する。
【選択図】図４

Description

本発明は、放送局側から放送番組表用のデータを放送波で配信して、受信側で放送局から蓄積（ダウンロード）配信されるファイル形式の任意のファイルを取得可能にする技術に関し、特に、任意ファイルを蓄積配信する放送サービスの送信装置に関する。

従来から、受信装置が放送局から配信される放送コンテンツに関するデータを受信してコンテンツ表を作成し、このコンテンツ表から所望のコンテンツを得るシステムとしてＥＰＧ(Electric Program Guide)を用いたシステムが知られている（特許文献１，２参照）。

通常、ＥＰＧを用いたシステムには、受信装置側でコンテンツ表に基づいて所望のコンテンツを専用のコンテンツサーバから取得して表示するものと、受信装置側でコンテンツ表に基づいて放送日時を管理して放送されるコンテンツを蓄積するものとがある。

コンテンツのソースがデジタル放送である場合、各チャンネルが順次選局されるように、受信周波数、トランスポートストリーム識別（ＴＳＩＤ）が一定周期で切り替えられ、ＴＳデータはパケット単位で伝送され、パケットの先頭部分には、ＰＩＤ（Packet Identification）が付加されている。受信装置は、復調部でトランスポートストリーム（ＴＳ）信号に変換し、映像用データ、音声用データ、データ放送のデータ、及び字幕用データ等の各データを復号し、このＴＳデータ中のＰＡＴ（Program Association Table），ＰＭＴ（Program Map Table）等のＰＳＩ（Program Specific Information）データに基づいて各データのＰＩＤを検出し、このＰＩＤを読み取ることで、映像データ、音声データ、ＥＰＧデータの識別を行う。

ＥＰＧを構成するのに必要なデータは、社団法人電波産業会（通称ＡＲＩＢ）における標準規格「デジタル放送に使用する番組陳列情報」等で規定されるデータ構造で伝送される。主要な構成データとして、編成チャンネルの名称、放送事業者の名称など、編成チャンネルに関する情報を伝送するＳＤＴ（Service Description Table）、放送されるコンテンツの名称、放送開始日時、コンテンツの説明など、コンテンツに関する情報を伝送するＥＩＴ（Event Information Table）、現在の日付、時刻の情報を伝送するＴＯＴ（Time Offset Table）等が挙げられる。尚、ＥＩＴに関しては、「ＡＲＩＢ ＴＲ−Ｂ１４ 第四編 地上デジタルテレビジョン放送 ＰＳＩ／ＳＩ運用規定」に記載されている。

即ち、受信装置側でコンテンツ表に基づいて放送日時を管理して放送されるコンテンツを蓄積するシステムでは、送信側では、放送するコンテンツに関するデータ及びコンテンツを、ＴＳに変換し、生成したＴＳをデジタル放送の放送波で伝送する。受信装置は、この放送波を復調してＴＳを復号し、ＴＳからＥＩＴを抽出し、このＥＩＴを用いて電子プログラムガイド（ＥＰＧ）を作成し、ＥＰＧを画面に表示する。

また、ＥＩＴに関連付けられた複数のコンテンツについて、選局した放送ストリームから抽出したダウンロード関連情報ＤＩＩ（Download Information Indication）／ダウンロード・データブロックＤＤＢ（Download Data Block）情報を用いてコンテンツごとに切り替えて取得することができる（例えば、特許文献３参照）。

従って、従来からの放送サービスを伝送・受信する技術は、受信装置が放送局から配信される放送ＳＩの情報を元に放送コンテンツ表を作成し、所望のコンテンツを視聴、または録画予約を行うＥＰＧを用いたシステムとして構成される。

一方、放送局から蓄積配信により任意のファイルを配信し、受信装置で取得する技法は、ＡＲＩＢ ＳＴＤ‐Ｂ２４に「独自データ放送」として記載があり、また、地上デジタル音声放送の運用規定であるＴＲ‐Ｂ１３のＥプロファイルとして定められている。

尚、現在の技術において、１つの蓄積（ダウンロード）番組（放送枠）で複数のコンテンツを一括蓄積する場合、ＡＲＩＢ ＳＴＤ−Ｂ１０におけるデジタル放送に使用する番組配列情報におけるコンテンツ記述子では、従来のＥＩＴは、１つの放送枠で複数のコンテンツを放送することは想定しておらず、コンテント記述子によるジャンルの指定は放送枠に対してのみであった。

例えば、高度広帯域衛星デジタル放送（以下、高度ＢＳと称する）では、メタデータを用いて、１つの蓄積番組で複数のコンテンツの一括蓄積を提案している。
（コンテンツ蓄積前）この放送枠に対する“蓄積（ダウンロード）情報”に複数のコンテンツに関する情報（コンテンツ識別情報やジャンルなど）を記載して送るので、事前にジャンル情報を取得する。
（コンテンツ蓄積時）事前に取得した情報をもとに、それぞれコンテンツのヘッダ情報を取得し、蓄積を行う。

一方、携帯端末向けマルチメディア放送（Ｖ−ＬＯＷ帯）では、高度ＢＳに比べて放送波帯域が狭い。従って、容量の大きなメタデータを送ることはできない。そこで、ＳＩを用いて、１つの蓄積番組で複数のコンテンツの一括蓄積を実現している。

特開２００７−３６７２６号公報 特開２００１−１３６４９５号公報 特開２００５−１９７９９２号公報

しかしながら、従来のＥＰＧでは、放送ＳＩの情報にコンテンツの種類に応じた蓄積（ダウンロード）ファイルに関する情報が無いため、コンテンツの種類に応じた蓄積ファイルの蓄積用のＥＰＧを実現できていない。

また、地上デジタル音声放送のＥプロファイルでは、受信装置側で実際の蓄積する任意ファイルを含む放送信号全体を受信して復号してメモリへ展開するまで、如何なるファイルが配信されてきたのかを把握することができず、受信装置の処理コスト、及び、受信電力的に非効率であった。

近年では、移動受信端末による移動受信を想定するマルチメディア放送など、携帯受信端末向け放送サービスの需要が増大しており、不安定な受信状況の中でも確実に蓄積（ダウンロード）放送されるコンテンツ（以下、「蓄積コンテンツ」と称する）を受信できるようにする放送システムの構築が要望されている。

特に、放送サービスで交通情報を伝送する場合を想定すると、常に新しい情報を配信する必要があり、受信装置側も限られたメモリ容量を有効利用すること、例えば蓄積放送される同一種類のコンテンツファイルについては上書き更新（常時更新）できるような放送システムを構築することが必要である。

さらに、現行のＥＰＧを用いた番組スケジュールシステムでは、受信装置側における予約蓄積に伴う上書き更新の動作を、単発コンテンツやシリーズコンテンツなどの蓄積コンテンツの種類に応じて、受信装置の利用者がその都度判断して、逐次設定しなければならず極めて不便である。

そこで、本発明の目的は、上述の問題を鑑みて為されたものであり、コンテンツファイルを含む任意ファイルを蓄積（ダウンロード）配信する放送サービスの送信装置を提供することにある。

本発明では、送信装置側で、ＥＰＧを構成する放送ＳＩの情報の中に、具体例としてＥＩＴ内に新規の記述子である「ファイル伝送記述子」（file_delivery_descriptor）を追加して「拡張ＥＩＴ」（後述する）を構成して伝送する態様と、蓄積コンテンツの蓄積予約のためのコンテンツ表の作成を可能とするコンテンツ指向の蓄積予約（映像等の場合、予約録画を含む）に必要な情報を組み入れたコンテンツスケジュールテーブル（ＣＳＴ：後述するContent_Schedule_Sectionから構成されるテーブル）を構成して伝送する態様について想定している。

一方、受信装置側で、拡張ＥＩＴを利用する場合、この「ファイル伝送記述子」に含まれる蓄積放送用の任意のコンテンツファイル（以下、総括して「任意ファイル」とも称する）を識別し、如何なるコンテンツファイルが配信されてきたのかを直ちに把握させ、必要に応じて同一種類のコンテンツファイルについては上書き更新することができる。

また、受信装置側で、ＣＳＴを利用する場合、ＣＳＴは、各蓄積コンテンツの放送時の開始時刻、放送持続時間、及び放送回数を表す「放送時刻識別情報」と、蓄積コンテンツごとに割り当てられた固有の識別子（event_id）と、各蓄積コンテンツの記述内容を表す記述子とを含んでいるため、このＣＳＴを受信して、該ＣＳＴで関連付けられた蓄積コンテンツを蓄積予約するためのコンテンツ表を生成し、前記コンテンツ表で蓄積予約するべく規定された蓄積コンテンツを、当該開始時刻で蓄積予約をカルーセル方式で伝送されるデータブロック単位で実行することができる。

ここで重要なことは、送信装置側で伝送する「拡張ＥＩＴ」及び「ＣＳＴ」には、受信装置側の蓄積予約動作を鑑みた新たな記述子もしくは識別子として、予め蓄積コンテンツの種類を規定した「コンテンツタイプ情報（content_type）が埋め込まれていることである。このコンテンツタイプ情報（content_type）は、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新（常時更新）コンテンツ」、及び「複数項目コンテンツ」が少なくとも定義されている。さらに、受信装置側では、拡張ＥＩＴ又はＣＳＴと、ＤＩＩの情報を組み合わせで、蓄積コンテンツの種類に応じた蓄積予約を可能にする。

「単発コンテンツ」とは、単一の蓄積コンテンツである。

「シリーズコンテンツ」とは、シリーズ番組を構成する蓄積コンテンツである。

「上書き更新（常時更新）コンテンツ」とは、例えば、上書き更新（常時更新）していく蓄積コンテンツである。気象情報や道路交通情報など、中身の情報のみ変わっていくイメージのコンテンツであり、最新の蓄積コンテンツのみ保存する用途向けの蓄積コンテンツである。

「複数項目コンテンツ」とは、例えば、ある放送枠で送られる複数の蓄積コンテンツを云う。例えば、ある番組「全国ニュース１２時」という放送枠で、状況に応じて複数のニュース項目を送る場合、同一のevent_idで３つの蓄積コンテンツを伝送するにあたり、第１カルーセルで「ニュース項目１」を伝送し、第２カルーセルで「ニュース項目２」を伝送し、第３カルーセルで「ニュース項目３」を伝送し、第４カルーセルで「ニュース項目１」を伝送し、第５カルーセルで「ニュース項目２」を伝送することができる。「複数項目コンテンツ」は、例えばＣＳＴに記載された放送時間内で、それぞれ別のカルーセルで伝送される。

「差し替え機能」とは、例えば、放送局が放送後に蓄積コンテンツを修正して再度放送し、蓄積済みの蓄積コンテンツと差し替える機能を云う。

本発明では、移動受信環境でのカルーセル伝送を用いた放送波の蓄積において、以下の機能を実現する。
（１）単発コンテンツとシリーズコンテンツと上書き更新コンテンツと複数項目コンテンツの蓄積の実行
（２）蓄積コンテンツの差し替えの実行
（３）同じ蓄積コンテンツの重複保存の防止
（４）放送枠があるが、新しいニュースがなく、前回と同じ蓄積コンテンツを放送する場合における重複保存の防止
（５）ＣＳＴであれば、蓄積コンテンツ毎に全ての繰り返し放送時刻の保持
（６）放送時間中の蓄積動作は、データカルーセルにより、繰り返し伝送される蓄積放送のデータの取得
（７）移動受信環境での放送波の蓄積では、受信環境が悪いため同じ蓄積コンテンツの繰り返し放送することが求められる。また、携帯端末がターゲットであり消費電力を抑えるために、蓄積に成功した蓄積コンテンツの繰り返し放送は受信しない、蓄積（ダウンロード）チャンネルのストリームを常に監視しないなどが求められる。
（８）移動受信環境下でのカルーセル伝送を用いた放送波の蓄積において、以下の機能を実現する。

本発明によれば、繰り返し放送される蓄積コンテンツを常時監視しなくてもよくなり、従来では、繰り返し放送される蓄積コンテンツに対して上記８つの機能を実現することができなかった。移動受信環境下で、受信装置の消費電力を抑えて、放送波の蓄積が実現できる。

即ち、本発明に係る送信装置は、デジタル放送の放送波でコンテンツファイルを送信する際に、該コンテンツファイルを受信側で蓄積予約させるのに必要とされる番組スケジュールテーブルを送信する送信装置であって、各コンテンツファイルを放送するサービスを一意に指定するサービスＩＤと、開始時刻、放送持続時間、及びコンテンツファイルを一意に表すイベント識別子と、コンテンツタイプを表すコンテンツタイプ情報とを含む、番組スケジュールテーブルを生成する番組スケジュールテーブル生成手段と、前記番組スケジュールテーブルを所定間隔で送信する番組スケジュールテーブル送信手段と、前記番組スケジュールテーブル内で関連付けたイベント識別子を有するコンテンツファイルをデータブロックにてカルーセル方式で送信するコンテンツファイル送信手段とを備え、前記イベント識別子は、前記データブロックとともに放送するヘッダ情報にも記述されており、前記コンテンツファイル送信手段は、受信側でコンテンツタイプに応じた蓄積動作を行うよう、前記ヘッダ情報と、前記コンテンツタイプ情報の組み合わせを制御して当該コンテンツファイルを送信する手段を有することを特徴とする。

また、本発明に係る送信装置において、前記番組スケジュールテーブルは、ＥＩＴにファイル伝送記述子を追加して構成されていることを特徴とする。

また、本発明に係る送信装置において、前記番組スケジュールテーブルは、前記カルーセル方式の繰返し回数ごとに各蓄積コンテンツの放送時刻の情報を含むことを特徴とする。

また、本発明に係る送信装置において、受信側が「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた、蓄積動作を行うよう、前記ヘッダ情報と、前記コンテンツタイプ情報の組み合わせを制御して当該コンテンツファイルを送信する手段を有することを特徴とする。

また、本発明に係る送信装置において、前記番組スケジュールテーブル生成手段は、シリーズ番組のコンテンツ情報を識別するための「シリーズ記述子」を含めて生成する手段を有し、前記イベント識別子は、前記カルーセル方式のヘッダ情報であるＤＩＩにて、ダウンロードＩＤに関連付けて付加されており、前記ダウンロードＩＤは、前記イベント識別子の「枝番」と、「データイベント識別子」とを含み、前記「単発コンテンツ」、前記「シリーズコンテンツ」、前記「上書き更新コンテンツ」、前記「複数項目コンテンツ」のそれぞれのコンテンツタイプにおける蓄積方法を、前記イベント識別子を基準にして、前記番組スケジュールテーブルに定義された前記コンテンツタイプ情報及び前記「シリーズ記述子」と、前記ヘッダ情報であるＤＩＩにて伝送される前記「枝番」及び前記「データイベント識別子」によって定義して、受信側が「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた蓄積動作を行うよう、前記ヘッダ情報と、前記コンテンツタイプ情報の組み合わせを制御して当該コンテンツファイルを送信する手段を有することを特徴とする。

また、本発明に係る送信装置において、前記ヘッダ情報は、複数項目コンテンツのジャンル情報を含み、受信側で前記複数項目コンテンツの蓄積について、ジャンル情報別のコンテンツとして蓄積制御を実行できるようにしたことを特徴とする。

また、本発明に係る送信装置において、前記ヘッダ情報は、複数項目コンテンツを構成するコンテンツ数の情報を含み、受信側で前記複数項目コンテンツの蓄積について、前記コンテンツ数の情報に基づいて蓄積制御を実行できるようにしたことを特徴とする。

また、本発明に係る送信装置において、前記番組スケジュールテーブル生成手段は、再送コンテンツのバージョンが変更される旨を表す更新情報記述子もしくは識別子を含めて生成する手段を有し、受信側で、前記更新情報記述子もしくは識別子で指定される再送コンテンツのバージョン情報を前記ヘッダ情報から取得して、前記再送コンテンツの蓄積を実行できるようにしたことを特徴とする。

また、本発明に係る送信装置において、前記ヘッダ情報に、蓄積コンテンツごとの緯度・経度情報を設定する手段を有し、受信側で蓄積コンテンツごとの蓄積を実行する際に、前記ヘッダ情報から緯度・経度情報を抽出し、該緯度・経度情報に対応する蓄積コンテンツの蓄積を実行できるようにしたことを特徴とする。

また、本発明に係る送信装置において、前記番組スケジュールテーブル生成手段は、蓄積コンテンツごとの放送時刻の情報を含めて生成する手段を有し、受信側で蓄積コンテンツの蓄積を実行する前に、事前に、前記番組スケジュールテーブルにおける現在と次に放送される蓄積コンテンツに関する部分のみをそれぞれ構成したテーブルＣＳＴ［ｐ］とＣＳＴ［ｆ］を取得して、蓄積すべき蓄積コンテンツの変更の有無を判別できるようにしたことを特徴とする。

また、本発明に係る送信装置において、前記番組スケジュールテーブル生成手段は、蓄積コンテンツごとの放送時刻の情報を含めて生成する手段を有し、受信側で蓄積コンテンツの蓄積を実行する前に、事前に、前記番組スケジュールテーブルにおける現在と次に放送されるコンテンツの１回分又は２回分の放送時刻に関する部分のみをそれぞれ構成したテーブルＣＳＴ［ｐ］とＣＳＴ［ｆ］を取得して、蓄積すべき蓄積コンテンツの変更の有無を判別できるようにしたことを特徴とする。

本発明によれば、送信装置は、受信装置側で拡張ＥＩＴ又はＣＳＴにて識別できる任意ファイルの蓄積放送が可能となり、受信装置は、蓄積予約機能の実現や、受信装置が効率的に電力を最小限にして、拡張ＥＩＴ又はＣＳＴにて識別した任意ファイルのみを受信することが可能となり、さらに、コンテンツタイプに応じた蓄積動作を行うことが可能となる。

本発明による一実施例の放送システムの概略構成図である。 本発明に係る拡張ＥＩＴの概略図である。 本発明に係るＣＳＴの概略図である。 本発明による一実施例の放送局側送信装置の概略図である。 本発明に係る一実施例の受信装置の概略図である。 本発明による一実施例の放送システムの動作説明図である。 カルーセル方式による伝送例を示す図である。 本発明による一実施例の放送システムに係るＥＰＧの例を示す図である。 本発明に係る一実施例の受信装置におけるコンテンツ蓄積予約制御部の概略図である。 本発明に係る一実施例の受信装置におけるコンテンツ蓄積予約制御部の動作フロー図である。 （Ａ），（Ｂ），（Ｃ）は、本発明による一実施例の放送システムにおけるＣＳＴ又は拡張ＥＩＴとカルーセル方式のＤＩＩとの関係を示す図である。 本発明に係る一実施例の受信装置における蓄積予約管理表の例を示す図である。 本発明に係る一実施例の受信装置における蓄積コンテンツ管理表の例を示す図である。 受信装置要求と放送局側送信装置要求を説明する対比図である。 本発明による一実施例の放送システムにおける単発コンテンツの送出及び蓄積を例示する図である。 本発明による一実施例の放送システムにおけるシリーズコンテンツの送出及び蓄積を例示する図である。 本発明による一実施例の放送システムにおける複数項目コンテンツの送出及び蓄積を例示する図である。 本発明による一実施例の放送システムにおける上書き更新コンテンツの送出及び蓄積を例示する図である。 （ａ）,（ｂ）は、本発明による一実施例の放送システムにおける単発コンテンツの送出及び蓄積を例示する図である。 （ａ）,（ｂ）は、本発明による一実施例の放送システムにおけるシリーズコンテンツの送出及び蓄積を例示する図である。 （ａ）,（ｂ）は、本発明による一実施例の放送システムにおける複数項目コンテンツの送出及び蓄積を例示する図である。 （ａ）,（ｂ）は、本発明による一実施例の放送システムにおける上書き更新コンテンツの送出及び蓄積を例示する図である。 （ａ）,（ｂ）は、本発明による一実施例の放送システムにおける差し替え機能を例示する図である。 本発明による一実施例の放送システムにおける全ての放送枠でevent_idを同一にする構成を例示する図である。 （ａ）,（ｂ）は、本発明による一実施例の放送システムにおける位置情報の送出及び蓄積を例示する図である。 本発明による一実施例の放送システムにおける位置情報の利用を例示する図である。 本発明による一実施例の放送システムにおけるＣＳＴ［ｐ／ｆ］の第１例を示す図である。 本発明による一実施例の放送システムにおけるＣＳＴ［ｐ／ｆ］の第２例を示す図である。 本発明による一実施例の放送システムにおけるＣＳＴ［ｐ／ｆ］の第３例を示す図である。 本発明に係る拡張ＥＩＴの別例の概略図である。 本発明に係るＣＳＴの別例の概略図である。

以下、本発明に係る任意ファイルを蓄積配信・受信する放送サービスの放送システムの一実施例について説明する。本実施例の放送システムの説明から、本発明に係る送信装置及び受信装置の構成も明らかになる。

［システム構成］
図１は、本発明による一実施例の放送システムの概略構成図である。放送局側送信装置１は、蓄積コンテンツの映像用データ、音声用データ、データ放送のデータ、及び字幕用データ等の各データをデジタル放送で受信装置（図１では、車載・ポータブル受信端末２−１，携帯電話機２−２を例示するが、以下の説明では、包括的に「受信装置２」として説明する）に向けて配信する装置であり、特に、ＥＰＧを構成する放送ＳＩの情報の中に、具体例としてＥＩＴ内に新規の記述子である「ファイル伝送記述子」を追加して「拡張ＥＩＴ」を構成して伝送するか、又は蓄積コンテンツの蓄積予約のためのコンテンツ表の作成を可能とするコンテンツ指向の蓄積予約（映像等の場合、予約録画を含む）に必要な情報を組み入れたコンテンツスケジュールテーブル（ＣＳＴ：後述するContent_Schedule_Sectionから構成されるテーブル）を構成して伝送する装置である。

受信装置２は、この「拡張ＥＩＴ」又は「ＣＳＴ」とＤＩＩの組み合わせによって、如何なる種類のコンテンツファイルが配信され、どのように蓄積予約を行うべきかについて把握し、コンテンツファイルの蓄積予約を管理するための「蓄積予約管理表」及び、コンテンツファイルの蓄積の有無を管理するための「蓄積コンテンツ管理表」を生成して、配信される蓄積コンテンツの蓄積をユーザの指定により、又は自動設定に基づき管理する装置である。

［拡張ＥＩＴ］
「拡張ＥＩＴ」は、図２に例示するように、既存のＥＩＴ内に新規の記述子である「ファイル伝送記述子」を追加して「拡張ＥＩＴ」を構成したものである。以下、ファイル伝送記述子内の各データについて説明する。

「descriptor_tag(8bit)」は、標準化機関が設定する当該ファイル伝送記述子を利用する機関を特定する。

「descriptor_length(8bit)」は、ファイル伝送記述子の既述子長を記述する。

「file_type_value(16bit)」は、伝送するファイルの種別を記述する。

「content_type_value1(8bti)」は、伝送する蓄積コンテンツの種別を記述する。

「content_type_value2(4bit)」は、伝送する蓄積コンテンツの更新の種別を記述する。

「content_type_value3(4bit)」は、伝送する蓄積コンテンツの本編・補足種別を記述する。

「content_volume(16bit)」は、蓄積コンテンツの容量を記述する。なお、蓄積コンテンツの容量が不明な場合には“0xFFFF”を記述する。

「content_bit_rate(16bit)」は、蓄積コンテンツのおよその再生レートを記述する。なお、蓄積コンテンツの再生レートが可変又は不明な場合には“0xFFFF”を記述する。

「transmission_bit_rate(16bit)」は、蓄積コンテンツのおよその伝送レートを記述する。なお、蓄積コンテンツの伝送レートが可変又は不明な場合には“0xFFFF”記述する。

「ex_event_id(12bit)」は、蓄積コンテンツの項目識別値を記述する。なお、蓄積コンテンツの項目識別値を使用しない場合には“0xFFF”を記述する。

「data_event_id(4bit)」は、蓄積コンテンツのバージョン値を記述する。なお、蓄積コンテンツのバージョンを使用しない場合には、“0xF”を記述する。

「reserved_future_use(8bit)」は、上記以外の任意の情報を記述する。

ＥＩＴで使用される記述子は、リアルタイムサービスで使用される短形式イベント記述子、コンテント記述子、デジタルコピー制御記述子、音声コンポーネント記述子、データコンテンツ記述子、スタッフ記述子に加え、前述のファイル伝送記述子、およびシリーズ番組を識別するシリーズ記述子が用いられる。

尚、既存ＥＩＴに新規に追加する「ファイル伝送記述子(file_delivery_descriptor)」は、ＰＭＴにも追加記載することも望ましく、この場合には蓄積コンテンツとの関連付けを再確認できるようになる。尚、「ファイル種別情報（file_type_value）」は、標準化機関に順ずる機関、もしくは、運用するプラットフォーム会社等が管理を行い、放送事業者、メーカー等に開示を行うのが好適である。これにより、受信装置２は実際に任意ファイルを受信する前に、配信されるファイルの内容を把握可能であり、受信の可否の判断が可能となる。

［コンテンツスケジュールテーブル（ＣＳＴ）］
「ＣＳＴ」は、図３に例示するように、ＣＳＴの種別を表す「テーブル識別子」と、ＣＳＴの伝送識別情報を表す「伝送識別情報」と、蓄積コンテンツごとに割り当てられた固有の識別子を表す「イベント識別子（event_id）」と、コンテンツタイプを表す「コンテンツタイプ情報（content_type）」と、各蓄積コンテンツの放送時の開始時刻、放送持続時間、及び放送回数を表す「放送時刻識別情報」と、各蓄積コンテンツの記述内容を表す「各種記述子」からなる。また、コンテンツスケジュールテーブル（ＣＳＴ）は、１つのＣＳＴに含まれる複数の蓄積コンテンツについて、所定回数の「放送時間の情報」とＥＩＴで運用されるものと同一の各種記述子である、蓄積コンテンツのコピーを制限する制御する旨を表す「デジタル制御記述子」、蓄積コンテンツのタイトルを表す「短形イベント記述子」、番組内容を表す「コンテント記述子」、ジャンル及びシリーズ番組である旨を表す「シリーズ記述子」を記述している。尚、コンテンツタイプ情報（content_type）は、図３に示す「コンテンツ情報」内の記述子とすることができる。また、「伝送識別情報」は、各サービス態様で随意決定することができ、その一例を以下に示す。

「table_id(8bit)」は、セクションが属するテーブルの識別のために使用する値であり、カルーセル伝送方式で伝送される蓄積コンテンツのストリーム（自ストリーム又は他ストリーム）、及び、１時間以内，６時間以内，１２時間以内，１日以内，１日以降の放送時間の蓄積コンテンツの組合せで種別化されたテーブル識別子である。尚、for()は、所定数分、繰り返し記述されていることを意味している。

「section_syntax_indicator(1bit)」は、セクション形式は通常形式と拡張形式の２種類があり、その種別を識別するための値である。通常形式は０、拡張形式は１であり、本例では「１」に固定しており、伝送識別情報の１つである。

「reserved_future_use(1bit)」は、符号化ビットストリームを定義する項の中で使用する場合、その値が将来、例えば所定のビット（Ｂ１０）が定義する拡張子として使用可能であることを表す。本例では未定義（全ビット１）とする。即ち、拡張子を表す伝送識別情報の１つである。別途、「reserved」を設けることができ、符号化ビットストリームを定義する中で使用する場合、その値が将来ＩＳＯで定義される拡張子として使用可能であることを表す。本例では未定義（全ビット１）とする。

「section_length(12bit)」は、セクション長フィールドの直後からＣＲＣ（Cyclic Redundancy Check）を含むセクションの最後までのセクションのバイト数を記述する。即ち、ＣＳＴの長さを表す伝送識別情報の１つである。

「service_id(16bit)」は、当該トランスポートストリーム内の他のサービスからこのサービスを識別するための値である。即ち、ＣＳＴにおける蓄積コンテンツのチャンネル（サービスＩＤ）を記述する伝送識別情報の１つである。

「version_number(5bit)」は、サブテーブルのバージョン番号を記述する伝送識別情報の１つである。尚、サブテーブルは、table_idとservice_idとtransport_stream_idとversion_numberが同じセクションであることを表す。

「current_next_indicator(1bit)」は、サブテーブルが現在使用可能である場合は「１」、サブテーブルが現在使用不可であり次に有効となることを示す場合は「０」であり、ＣＳＴ自体の連番を記述する伝送識別情報の１つである。

「section_number(8bit)」は、セクションの番号を表す。サブテーブル中の最初のセクション番号は0x00である。セクション番号は同一のtable_idとservice_idとtransport_stream_id、original_network_idを持つセクションの追加毎に１加算される。即ち、ＣＳＴ内の現セクション番号を記述する伝送識別情報の１つである。

「last_section_number(8bit)」は、そのセクションが属するサブテーブルの最後のセクションの番号を記述する。即ち、ＣＳＴ内の全セクション番号を表す伝送識別情報の１つである。

「transport_stream_id(16bit)」は、ＥＩＴと同様にＣＳＴが示すこのトランスポートストリームをその分配システム内の他の多重から識別するための値である。即ち、ＣＳＴを伝送するＴＳＩＤを記述する伝送識別情報の１つである。

「original_network_id(16bit)」は、元の分配システムのネットワーク識別を記述する伝送識別情報の１つである。

「segment_last_section_number(8bit)」は、サブテーブルをコンテンツ数や放送開始時間などで複数のセグメントに分け、このセクションが属するセグメントの中で最後のセクションの番号を記述することもできる。ＣＳＴを伝送するセグメント最終セクション番号を表す伝送識別情報の１つである。尚、サブテーブルをある単位で区切ったものをセクションとする。例えば２００個の蓄積コンテンツを１０個の蓄積コンテンツ毎に分けた場合、セグメント数は２０となる。尚、「Last_table_id」を設けて、使用されている最終のテーブル識別を示すようにすることもできる。使用されるテーブルが１個のみの場合は、このフィールドにはこのテーブルのテーブル識別が設定される。

「event_id(16bit)」は、蓄積コンテンツごとに割り当てられた固有の識別子を記述する。

file_type_value、content_type_value1、content_type_value2、content_type_value3は、上述したファイル伝送記述子に記述されるデータと同様である。

「broadcast_count(8bit)」は、蓄積コンテンツの放送回数を記述する。

「start_time(40bit)」は、event_idごとの蓄積コンテンツの放送開始時刻を記述する。

「duration(24bit)」は、event_idごとの蓄積コンテンツの持続時間を記述する。

「running_status(3bit)」は、未定義であり、「０」を記述する。

「free_CA_mode(1bit)」は、当該番組が無料番組の場合は「０」を設定し、当該番組が有料番組の場合は「１」を設定する。

「descriptor_loop_length(12bit)」は、続く記述子の長さを記述する。各種記述子は、運用されるＥＩＴの記述子をそのまま採用することができる。

現在のデジタル放送では、番組情報を記述するＥＩＴの中に各番組をユニークに示すイベント識別子（event_id）が記述されている。イベント識別子（event_id）は一定時間、例えば２４時間以内はユニークな値として放送局で運用されている。そして、一定時間が過ぎると、再度ユニークな値として再割当される。本発明においては、蓄積するコンテンツファイルごとにイベント識別子（event_id）を割り当てることとし、一定の時間、例えば２４時間や１週間の間は、同一のファイルを繰り返し配信する場合は、同一のイベント識別子（event_id）を繰り返し使用することとする。同一ファイルを繰り返し配信することで受信装置２は移動中であっても受信できる機会が増加し確実に受信可能となる。また、受信装置２はイベント識別子（event_id）を確認することで、同一ファイルであれば既に受信済みの場合は受信しなくてもよいという判断が可能となる。なお、イベント識別子（event_id）の値をどれくらいの時間でユニークにするかについては、標準化機関等で規定されるものとする。

ＣＳＴで使用される記述子は、ＥＩＴと同様に短形式イベント記述子、コンテント記述子、デジタルコピー制御記述子、音声コンポーネント記述子、データコンテンツ記述子、スタッフ記述子、シリーズ記述子が用いられる。

ＣＳＴにはevent_id、file_type_value、content_type_valueが含まれており、コンテンツの再送出も含めた送出時間が記載される。ＥＩＴでは1つのevent_idに対して1つの送出時間情報（start_time、duration）が記載されるのに対し、ＣＳＴでは1つのevent_idに対して複数の送出時間情報が記載される。これにより再送出を行うコンテンツについては、ＥＩＴに比べて伝送する情報量の削減が可能となり、受信機は再送出を含めたコンテンツ蓄積のためのスケジュール情報の取得が可能となる。尚、ＣＳＴには送出直近に変更される可能性の高いex_event_id値、data_event_id値は記載されない。

拡張ＥＩＴやＣＳＴで伝送される、file_type_value値の例を表１に、content_type_value1値の例を表２に、content_type_value2値の例を表３に、content_type_value3値の例を表４に示す。

図４は、本発明による一実施例の放送局側送信装置１の概略図である。放送局側送信装置１は、コンテンツ編成部１０と、カルーセル処理部１１と、ＰＳＩ／ＳＩ生成符号化部１２と、多重化部１３と、ＯＦＤＭ変調部１４と、送信部１５とを備える。コンテンツ編成部１０は、コンテンツ生成部１０１と、制御データ生成部１０２と、ＥＩＴ生成部１０３とを備える。制御データ生成部１０２は、識別子付番制御部１０２１と、伝送回数・周期管理部１０２２とを備える。ＥＩＴ生成部１０３は、ファイル伝送記述子生成部１０３１を備える。

コンテンツ編成部１０は、放送波で配信するための蓄積コンテンツを生成するとともに、「拡張ＥＩＴ」又は「ＣＳＴ」で関連付けられた蓄積コンテンツを受信側で蓄積予約させるための基礎データとなる番組スケジュールを生成するように構成される。「拡張ＥＩＴ」は、既存のＥＩＴに、「ファイル伝送記述子」を付加したものであり、従来のＥＩＴと比較して伝送容量をほとんど増大させることなしに、蓄積コンテンツに関する情報の受信又は更新の負担を大きく低減させる。一方、「ＣＳＴ」は、コンテンツ指向の番組情報を伝送するため、蓄積コンテンツを受信側で蓄積予約させるための基礎データとなる番組スケジュールを簡単に構成することができる。また、ＣＳＴは、ＥＩＴと比較してテーブルサイズを小さくすることができ、蓄積コンテンツに関する情報の受信又は更新の負担を大きく低減させることができる。

より具体的には、コンテンツ生成部１０１は、蓄積コンテンツを生成し、コンテンツファイルを生成する。例としてＴＳファイルの場合は、蓄積コンテンツを編成する要素である映像、音声、データ、字幕、ＰＳＩを生成して符号化し、多重化（パッケージ化）を施し、ＴＳを生成する。尚、ＰＳＩは、このＴＳを受信側で再生する際に必要なＰＡＴ及びＰＭＴ等の情報である。

制御データ生成部１０２は、コンテンツ生成部１０１を経て伝送する蓄積コンテンツを、カルーセル処理部１１によってカルーセル方式で伝送する際に、ＤＩＩメッセージ内のダウンロードＩＤ（downloadID）と「拡張ＥＩＴ」又は「ＣＳＴ」のイベント識別子（event_id）とを関連付けた紐付けた態様で伝送するよう制御する識別子付番制御部１０２１と、イベント識別子（event_id）で識別されるイベント毎にカルーセル方式で伝送するデータブロック（ＤＤＢ）の伝送回数と、カルーセル方式で伝送する周期を管理する伝送回数・周期管理部１０２２からなる。このカルーセル方式で伝送する蓄積コンテンツをイベント識別子（event_id）で識別されるイベントとして管理するために、識別子付番制御部１０２１は、ＥＩＴ生成部１０３にイベント識別子（event_id）を送出する機能を有する。即ち、コンテンツファイルは、設定される送信周期に従って一定頻度で送信され、この送信周期は、蓄積コンテンツ別に設定可能であり、例えば、５分〜１２０分の間で設定することができる。また、制御データ生成部１０２は、コンテンツタイプを表す「コンテンツタイプ情報（content_type）」と、「イベント識別子（event_id）」と、コンテンツ情報としての「シリーズ記述子(series_id)」とを組み合わせて、コンテンツタイプごとの予約蓄積制御を可能とするべく「拡張ＥＩＴ」又は「ＣＳＴ」を編成するとともに、ＤＩＩに少なくとも「イベント識別子（event_id）」の情報と、その「枝番」及び「データコンポーネント識別子（data_component_id）」を設定する。

ＥＩＴ生成部１０３は、識別子付番制御部１０２１から得られるイベント識別子（event_id）を、放送波で配信するための蓄積コンテンツを受信装置側で蓄積させるのに用いる既存のＥＩＴに組み入れ、且つ「ファイル種別情報（file_type_value）」を含む「ファイル伝送記述子(file_delivery_descriptor)」を生成して追加し、拡張ＥＩＴを構成してＥＩＴ番組情報としてＰＳＩ／ＳＩ生成符号化部１２に送出する。ファイル伝送記述子生成部１０３１は、イベント識別子（event_id）によって識別されるコンテンツファイルの内容の種別を表す「ファイル種別情報（file_type_value）」を含む「ファイル伝送記述子(file_delivery_descriptor)」を生成する機能を有する。尚、ＥＩＴ生成部１０３は、識別子付番制御部１０２１から得られるイベント識別子（event_id）を、放送波で配信するための蓄積コンテンツを受信装置側で蓄積させるのに用いる「ＣＳＴ」に組み入れて構成し、ＥＩＴ番組情報としてＰＳＩ／ＳＩ生成符号化部１２に送出するように構成することができる。「ＣＳＴ」を伝送する場合にも、コンテンツファイルの内容の種別を表す「ファイル種別情報（file_type_value）」を生成して組み入れることができる。

カルーセル処理部１１は、コンテンツ生成部１０１によって符号化した蓄積コンテンツを、制御データ生成部１０２によるカルーセル方式の伝送回数及び送信周期と、ＤＩＩメッセージ内のダウンロードＩＤ（downloadID）とＥＩＴのイベント識別子（event_id）とを関連付けた態様でカルーセル化して、ＤＩＩ及びＤＤＢのモジュールを構築して多重化部１３に送出する。

例えば、図７に示すように、コンテンツ配信のサービスＩＤを表すチャンネル（Ｃｈ）にて、コンテンツデータは、コンポーネントタグ（component_tag：ＥＳｍ〜ＥＳｎ）で識別できるように多重化され、コンテンツデータは、拡張ＥＩＴ又はＣＳＴで関連付けられた複数の蓄積コンテンツについて、選局した放送ストリームから抽出したＤＩＩ／ＤＤＢ情報を用いてイベント識別子（event_id）によって識別される蓄積コンテンツごとにダウンロード・データブロック（ＤＤＢ）を切り替えて取得することができる。尚、蓄積コンテンツは、１つ又は複数のモジュールで構成して伝送することもできる。

ＰＳＩ／ＳＩ生成符号化部１２は、受信装置２で放送波を受信するために必要なＰＳＩ／ＳＩ情報（即ち、ＥＩＴ番組情報）を生成して符号化し、多重化部１３に送出する。このＥＩＴ番組情報は、拡張ＥＩＴと、各蓄積コンテンツの放送時の開始時刻、放送持続時間、及びコンテンツファイルを一意に表す「イベント識別子」とを含むＰＳＩ／ＳＩ情報として構成される。

多重化部１３は、上記カルーセル化したコンテンツデータやＰＳＩ/ＳＩ等を、チャンネルごとに多重化して、ＴＳを形成し、ＯＦＤＭ変調部１４に送出する。

ＯＦＤＭ変調部１４は、多重化部１３を経て得られるＴＳを、デジタル放送のＯＦＤＭ方式に従う変調方式で変調を施して、送信部１５を介して外部に放送波として伝送する。

このように、放送局側送信装置１は、拡張ＥＩＴを一定頻度で送信するとともに、拡張ＥＩＴ又はＣＳＴに基づいて蓄積コンテンツをカルーセル伝送方式で送信する。尚、詳細に後述するが、放送局側送信装置１は、拡張ＥＩＴ又はＣＳＴに従って、各蓄積コンテンツをダウンロードＩＤ（downloadID）と紐付けされたイベント識別子（event_id）で関連付けたデータブロックにて再放送することが可能であり、受信装置２は、再放送の回数や周期を拡張ＥＩＴ又はＣＳＴから知ることができる。

図５は、本発明に係る一実施例の受信装置２の概略図である。受信装置２は、受信用アンテナを有するＯＦＤＭ復調部２０と、ＴＳ復号部２１と、映像復号部２２と、音声復号部２３と、字幕・字幕スーパー復号部２４と、カルーセル復号部２５と、ＢＭＬブラウザ２６と、出力処理Ｉ／Ｆ部２７と、ＳＩ処理部２８と、コンテンツ蓄積予約制御部２９と、記憶部３０と、蓄積コンテンツ一覧表示・再生指示部３１と、蓄積コンテンツ管理表表示・再生指示部３２と、ユーザＩ／Ｆ部３３と、蓄積コンテンツ再生制御部３４とを備える。

ＯＦＤＭ復調部２０は、拡張ＥＩＴ又はＣＳＴのデータを構成するＥＩＴ番組情報を復調して、このＴＳをＴＳ復号部２１に送出する機能と、この拡張ＥＩＴ又はＣＳＴに対応するコンテンツデータを受信し、ＯＦＤＭ復調部２０を介して復調して、このＴＳをＴＳ復号部２１に送出する機能を有する。デジタル放送では、ＴＳデータ中のＰＩＤを検出し、このＰＩＤを読み取ることで、コンテンツデータ、拡張ＥＩＴ又はＣＳＴのデータの識別を行うことができ、ＥＳ番号（component_tag）を検出し、このＥＳ番号を読み取ることで、所望するデータの識別ができる。

ＴＳ復号部２１は、ＯＦＤＭ復調部２０を経て得られるＥＩＴ番組情報を復号して拡張ＥＩＴ又はＣＳＴのデータを復号し、ＳＩ処理部２８に送出する機能と、ＯＦＤＭ復調部２０を経て得られるＥＩＴ番組情報に対応するコンテンツデータを復号し、それぞれ対応する機能部である映像復号部２２、音声復号部２３、字幕・字幕スーパー復号部２４及びカルーセル復号部２５に送出する。映像復号部２２、音声復号部２３、字幕・字幕スーパー復号部２４は、それぞれ蓄積コンテンツを編成する映像、音声、字幕・字幕スーパーを復号して出力処理Ｉ／Ｆ部２７に送出する機能を有し、カルーセル復号部２５は、蓄積コンテンツを編成するデータ放送用のデータを送信側と対応するカルーセル方式に従ってカルーセル処理を施しながら復号してＢＭＬブラウザ２６に送出する機能を有する。復号したデータ放送用のデータは、ＢＭＬブラウザ２６によって規定された描画方式に従って変換され、出力処理Ｉ／Ｆ部２７に送出される。出力処理Ｉ／Ｆ部２７は、外部装置（例えば、表示装置やスピーカ等）に蓄積コンテンツを編成する映像、音声、字幕・字幕スーパー、その他のデータを提示する機能を有する。

ただし、カルーセル復号部２５は、コンテンツ蓄積予約制御部２９からの制御信号によって、当該拡張ＥＩＴ又はＣＳＴに対応するコンテンツデータの取得及び蓄積が制御され、当該拡張ＥＩＴ又はＣＳＴに対応するコンテンツデータを、記憶部３０に蓄積する。記憶部３０内に蓄積されるコンテンツデータは、コンテンツ蓄積予約制御部２９によって管理され、コンテンツ蓄積予約制御部２９は、当該拡張ＥＩＴ又はＣＳＴに従ってデータブロック単位で取得した蓄積コンテンツの上書き更新や差し替えや蓄積予約の制御に用いるコンテンツファイルの蓄積予約を管理するための「蓄積予約管理表」及びコンテンツファイルの蓄積の有無を管理するための「蓄積コンテンツ管理表」を記憶部３０に格納及び更新する機能を有する。

記憶部３０に格納されたコンテンツファイルや「蓄積予約管理表」及び「蓄積コンテンツ管理表」は、ユーザがユーザＩ／Ｆ部３３を介して指定することにより表示又は再生することができるよう蓄積コンテンツ一覧表示・再生指示部３１によって表示又は再生が制御される。

尚、「蓄積予約管理表」は、放送される時間軸に従う蓄積コンテンツ別の放送時間、タイトル、シリーズ、及びジャンルを特定することができるＥＰＧとして利用されるものである（図１２参照）。また、「蓄積コンテンツ管理表」は、蓄積コンテンツ別に蓄積済みであるか否かと、未蓄積ＤＤＢの有無を管理可能な態様で構成される（図１３参照）。

ＳＩ処理部２８は、拡張ＥＩＴ又はＣＳＴのデータを入力してチャンネルごとの放送コンテンツのＥＩＴ情報と、各蓄積コンテンツの放送時の開始時刻、放送持続時間、及びコンテンツファイルを一意に表す「イベント識別子」とを含むＰＳＩ／ＳＩ情報（即ち、ＥＩＴ番組情報）をコンテンツ蓄積予約制御部２９に送出する。

また、コンテンツ蓄積予約制御部２９の詳細は後述するが、ユーザによって「蓄積予約管理表」で指定された蓄積コンテンツの蓄積予約の動作を制御する機能を有する。例えば、コンテンツ蓄積予約制御部２９は、指定された蓄積コンテンツの蓄積予約状態を管理するために、「蓄積予約管理表」を生成し、蓄積コンテンツごとに蓄積予約待ちであるか否かを示すマーキングをして、蓄積コンテンツの蓄積予約の制御を管理することができる。

蓄積予約管理表表示・蓄積予約指示部３１は、ユーザからの蓄積予約管理表の表示指示に応じて、記憶部３０に格納された「蓄積予約管理表」を表示装置（図示せず）に表示する。また、ユーザからの蓄積コンテンツの蓄積予約指示に応じて、予約指示信号をコンテンツ蓄積予約制御部２９に送出する。

蓄積コンテンツ管理表表示・再生指示部３２は、ユーザからの蓄積コンテンツ管理表の表示指示に応じて、記憶部３０に格納された「蓄積コンテンツ管理表」を表示装置（図示せず）に表示する。また、ユーザからの蓄積コンテンツの再生指示、再生終了指示に応じて、再生指示信号、再生終了指示信号を蓄積コンテンツ再生制御部３４に送出する。

蓄積コンテンツ再生制御部３４は、蓄積コンテンツ管理表表示・再生指示部３２から再生指示信号を受け取ると、記憶部３０から、再生指示のあった蓄積コンテンツのコンテンツファイルと、該蓄積コンテンツのコンテンツ種別（content_type_value）とを取得する。そして、蓄積コンテンツ再生制御部３４は、取得したコンテンツ種別に応じて、後述するように、コンテンツファイルの再生動作を制御する。

受信装置２はevent_id等により蓄積の予約を行い、予約した時間にデータカルーセルで送信されるファイルの受信を実行する。蓄積中、パケットを取りこぼすなどの原因により、蓄積が完了しなかった場合は、再度蓄積待機状態に遷移し、蓄積の放送スケジュール情報に記載された次の日時まで予約待機し、放送時刻になると蓄積の状態になり、欠損データの補完を行うことが可能である。また、送信されるコンテンツのバージョンが更新される場合、ファイル伝送記述子内のdata_event_idの値を参照することで、別バージョンとしてコンテンツの蓄積が可能となる。

リアルタイム型放送サービスにおいて番組の識別はevent_idを使用するが、蓄積（ダウンロード）サービスにおいてはevent_idに加え、event_id枝番（ex_event_id）、及びdata_event_idを用いる。すなわち、蓄積（ダウンロード）サービスではevent_id＋ex_event_id＋data_event_idで蓄積コンテンツを一意に特定する。蓄積（ダウンロード）サービスのコンテンツ識別情報とビット数、識別内容を表５に示す。

一般的な蓄積コンテンツを蓄積する場合、event_idを指定することで蓄積コンテンツを一意に特定することができるが、ニュース番組のように蓄積コンテンツの中の項目を一意に特定したい場合、event_idに加えてex_event_idが用いられる。例えば、event_id＝“0x0001”を「全国ニュース」とした場合、ex_event_idを指定することで、「全国ニュース」の項目を一意に特定することができる。この例を以下に示す。

＜event_id＞ ＜ex_event_id＞ 意味
0x0001 0x000 「全国ニュース」項目0
0x0001 0x001 「全国ニュース」項目1
0x0001 0x002 「全国ニュース」項目2

蓄積コンテンツの中の項目の識別が必要な場合、ex_event_idの値が必ず付与され、蓄積コンテンツの中の項目の識別が不要な場合、ex_event_id＝“0xFFF”とするか、ex_event_idが使用されないものとする。なお、ex_event_idの値を１２ｂｉｔとすれば、異なる項目の指定は最大４０９６種類（正確には０ｘＦＦＦを除き４０９５種類）とすることができる。

また、蓄積サービスでは、同じ内容の蓄積コンテンツを複数回送信し、受信装置２側で欠損データの補完として利用することが可能であるが、２回目以降の送信において内容を一部変更するなど、バージョンの異なる蓄積コンテンツが送信されるケースが想定される。この場合、バージョンの変更を受信側に知らされない状態で欠損データの補完を行うと、変更部分の映像や音声などのデータが不連続となり、蓄積コンテンツの視聴に支障をきたすことになる。そこで、バージョンの異なる蓄積コンテンツを送る場合、異なるdata_event_idの値が付与され、受信装置２側でのバージョン管理を可能とする。例えば、event_id＝“0x0001”を「全国ニュース」とした場合、ex_event_idとdata_event_idを指定することで、「全国ニュース」の項目を、バージョンを含めて一意に特定することができる。この例を以下に示す。

＜event_id＞ ＜ex_event_id＞ ＜data_event_id＞ 意味
0x0001 0x000 0x0 「全国ニュース」項目0のVer0
0x0001 0x000 0x1 「全国ニュース」項目0のVer1
0x0001 0x001 0x0 「全国ニュース」項目1のVer0
0x0001 0x002 0x0 「全国ニュース」項目2のVer0

蓄積コンテンツのバージョンの識別が必要な場合、data_event_idの値が必ず付与され、バージョンの識別が不要な場合、data_event_id＝“0xF”とするか、data_event_idが使用されないものとする。なお、data_event_idの値は４bitであり、異なるバージョンの指定は最大１６種類（正確には０ｘＦを除き１５種類）とすることができる。

また、蓄積サービスでは、あらかじめ指定された時間に送信が行われ、蓄積コンテンツが受信装置２に自動的に蓄積されるケースが一般的であるが、交通情報のように常時送信が行われ、最新の情報が受信装置２で常時提示されるサービスも想定される。このような常時更新蓄積コンテンツの場合、event_idは一定値が送られ、ex_event_idは蓄積コンテンツの中の項目、data_event_idは各項目のバージョンを示すものとする。例えば、event_id＝“0x0002”を「交通情報」とした場合、ex_event_idとdata_event_idを指定することで、「交通情報」の各県の項目を、バージョンを含めて一意に特定することができる。この例を以下に示す。

＜event_id＞ ＜ex_event_id＞ ＜data_event_id＞ 意味
0x0002 0x000 0x0 「交通情報」県0のVer0
0x0002 0x000 0x1 「交通情報」県0のVer1
0x0002 0x000 0xE 「交通情報」県0のVer14
0x0002 0x001 0x0 「交通情報」県1のVer0
0x0002 0x002 0x0 「交通情報」県2のVer0

上記の例の場合、県0の情報を提示する受信装置２は、Ver0のデータを受信したらVer0の情報を提示、Ver1のデータを受信したらVer1の情報を提示する。以下同様にVer14のデータを受信したらVer14のデータを提示し、Ver14の次はVer0に戻り、同様の動作を繰り返す。

なお、上書き更新（常時更新）蓄積コンテンツにおいても、蓄積コンテンツの中の項目の識別が必要な場合、ex_event_idの値が必ず付与され、蓄積コンテンツの中の項目の識別が不要な場合、ex_event_id＝“0xFFF”とするか、ex_event_idが使用されないものとする。また、蓄積コンテンツのバージョンの識別が必要な場合、data_event_idの値が必ず付与され、バージョンの識別が不要な場合、data_event_id＝“0xF”とするか、data_event_idが使用されないものとする。

次に、放送局側送信装置１と受信装置２とを含む放送システムの代表的な動作について説明する。

［システム動作］
図６は、本発明による一実施例の放送システムの動作説明図である。

まず、放送局側送信装置１の動作を説明するに、放送局側送信装置１は、一定間隔で拡張ＥＩＴ又はＣＳＴのデータを構成するＥＩＴ番組情報（本例ではＥＩＴに含まれる拡張ＥＩＴ又はＣＳＴのcontent_schedule）を配信する（ステップＳ１〜Ｓ３）。また、拡張ＥＩＴ又はＣＳＴに従って時間編成された放送される番組情報の変更の有無を含む、現在の番組と次の番組の情報（ＣＳＴ［ｐ／ｆ］又は拡張ＥＩＴ［ｐ／ｆ］）を配信する（ステップＳ４）。ここで、一般的なネットワーク通信のような双方向通信によって蓄積コンテンツの再要求及び再送信するものとは異なり、放送コンテンツであるので、受信装置側で受信不良が生じた場合を予め想定して、放送局側送信装置１が備える制御データ生成部１０２は、拡張ＥＩＴ又はＣＳＴに従うイベント識別子（event_id）で管理されたコンテンツデータを、拡張ＥＩＴ又はＣＳＴに従う所定周期及び回数によって、カルーセル方式で送信及び再送信する（ステップＳ５，Ｓ６）。

例えば、図８に示すように、放送局側送信装置１は、１ＴＳ（１セグメント又は３セグメント放送）内で、リアルタイム放送の番組コンテンツを時間編成で送信するメインチャンネル（メインｃｈ１）と、このメインｃｈ１の番組コンテンツに連動する任意ファイル（例えば、動画ファイル、ＰＤＦ、ＴＳファイル、３ＧＰＰ等）を多重して送信する、コンテンツ提供者が独自に利用する独自チャンネル（独自ｃｈ１）と、このメインｃｈ１の番組コンテンツに連動することなく、独立した任意ファイル（例えば、リアルタイムの更新が要求されるような交通情報等）を多重して送信する、コンテンツ提供者が独自に利用する第２の独自チャンネル（独自ｃｈ２）の３チャンネルの蓄積コンテンツを多重送信する。

これらのメインｃｈ１、独自ｃｈ１及び独自ｃｈ２の蓄積コンテンツは、ＥＩＴ番組情報（拡張ＥＩＴ又はＣＳＴ）から、チャンネル種別をそれぞれサービスＩＤ（service_id）で識別することができるだけでなく時間軸方向の編成についてもイベント識別子（event_id）で識別し、且つイベント識別子（event_id）によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送記述子(file_delivery_descriptor)」内の「ファイル種別情報（file_type_value）」で識別することができ、例えば図８に示すように編成したＥＰＧを直ちに構成することができる。

従って、受信装置２は、ＥＩＴ番組情報として機能する本発明に係る拡張ＥＩＴ又はＣＳＴを復号して、チャンネル種別をそれぞれサービスＩＤで、メインｃｈ１、独自ｃｈ１及び独自ｃｈ２のチャンネル別蓄積コンテンツを把握し、各チャンネルにおける時間軸方向の編成についてイベント識別子（event_id）で識別し、且つイベント識別子（event_id）によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送記述子(file_delivery_descriptor)」内の「ファイル種別情報（file_type_value）」で識別し、ＥＰＧのコンテンツ番組一覧を直ちに構成することができる。

以下、受信装置２の動作について説明する。

受信装置２は、ＥＩＴ番組情報を受信して拡張ＥＩＴを復号し、チャンネル種別をそれぞれサービスＩＤで、メインｃｈ１、独自ｃｈ１及び独自ｃｈ２のチャンネル別蓄積コンテンツを把握し、各チャンネルにおける時間軸方向の編成についてイベント識別子（event_id）で識別し、且つイベント識別子（event_id）によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送記述子(file_delivery_descriptor)」内の「ファイル種別情報（file_type_value）」で識別することにより、拡張ＥＩＴ又はＣＳＴにおける蓄積コンテンツがコンテンツファイルとして蓄積可能なファイルであるか否かを判断し、コンテンツタイプ情報（content_type）やＣＳＴ内のupadate_flagで上書き蓄積するファイルであるか否かを判断する（ステップＳ１１〜Ｓ１３）。

続いて、受信装置２は、蓄積可能なファイルについて放送される時間軸に従う蓄積コンテンツ別の放送時間、タイトル、シリーズ、及びジャンルを特定し、ＥＰＧとして利用する「蓄積予約管理表」を生成し、受信装置２のユーザに提示可能にする（ステップＳ１４）。受信装置２は、ユーザによって指定された蓄積コンテンツを蓄積予約として「蓄積予約管理表」に設定して登録し、放送時刻の直前に蓄積予約を起動して、拡張ＥＩＴ又はＣＳＴに従って時間編成された放送番組の変更の有無を含む現在番組と次の番組（ＣＳＴ［ｐ／ｆ］又は拡張ＥＩＴ［ｐ／ｆ］）を受信する（ステップＳ１５）。従って、受信装置２は、予約時間数分前にＣＳＴ又は拡張ＥＩＴを再取得して放送コンテンツの変更がないことを確認し、変更がある場合には蓄積予約管理表の登録内容を自動更新する。

受信装置２は、蓄積予約管理表の登録内容に従って、蓄積コンテンツの蓄積予約の制御を行い、放送時間になると、該当エレメンタリストリーム (ＥＳ)のＤＩＩを取得し、ＤＩＩに記載されたイベント識別子（event_id）に紐づくダウンロードＩＤ（downloadID）で、蓄積するコンテンツファイルをコンテンツタイプとともに特定し、該当するモジュール内のデータブロック（ＤＤＢ）列を受信して蓄積コンテンツの蓄積を実行する（ステップＳ１６）。該当蓄積コンテンツが、モジュールリンクされている場合には、対応する複数のモジュール内のデータブロック（ＤＤＢ）列を受信して蓄積する。尚、受信装置２は、蓄積予約した蓄積コンテンツが放送開始時刻（start_time）に従って放送中であれば、受信して蓄積動作を実行し、放送開始時刻（start_time）外であれば（蓄積予約した蓄積コンテンツが放送中ではなければ）、蓄積予約管理表に登録して放送時間まで待機することになる。受信不良が原因で一度に蓄積コンテンツを構成する全てのデータが受信できない場合にも、蓄積コンテンツは、ＤＤＢ単位で伝送されているために、カルーセル方式で伝送されるカルーセル回数内で再取得可能であれば、受信に失敗したＤＤＢ単位で蓄積を行うことができ、カルーセル回数内で受信に失敗した場合には、再放送時に取得可能である。この再放送日時の情報は、予め拡張ＥＩＴ又はＣＳＴ内に埋め込まれているために、受信装置２は、蓄積予約管理表の登録内容に従って自動的に再取得が可能である。

受信装置２は、蓄積が完了した蓄積コンテンツについては、蓄積予約管理表の登録を削除するとともに、蓄積コンテンツ管理表に登録して蓄積状況を管理する。例えば、蓄積コンテンツの蓄積が完了したら、蓄積コンテンツ管理表に登録し、蓄積予約管理表からマーキングを削除して再放送時の再取得を実行しないように制御する。更に、１サイクル（カルーセルサイクル）内で完全に蓄積できなかった場合は、次のサイクル（カルーセルサイクル）で再度取得する。ただし、蓄積できたデータ（ＤＤＢ単位）は破棄せずに保存（一時保存）しておき、未取得ＤＤＢがある場合には当該コンテンツファイルのＤＤＢの差分蓄積を実行する（ステップＳ１７）。また、拡張ＥＩＴ又はＣＳＴ内の放送の持続時間（duration）の情報を利用して、蓄積未完了のまま当該サイクルの放送時間が終了した際に、再放送がある場合は予約蓄積の中断として判断し、再放送がない場合は予約蓄積の中止として判断する。

また、受信装置２は、ダウンロードＩＤ（downloadID）内のイベント識別子（event_id）と枝番が同一でデータイベント識別子（data_event_id）のみが更新されたコンテンツファイルの蓄積を行うときは、差し替えや上書き更新蓄積を行うことができる（ステップＳ１８）。また、上書き更新コンテンツで同じシリーズに属する蓄積コンテンツが、既に蓄積されている場合には上書き更新を行い、そうでない場合はそのまま蓄積する。

受信装置２は、シリーズやジャンル別に蓄積した蓄積コンテンツの一覧表（蓄積コンテンツ管理表）を作成して、ユーザに提示可能にするのが好適である（ステップＳ１９）。ユーザは、所定の操作で、蓄積コンテンツ管理表から不要な蓄積コンテンツを削除することもできる。シリーズの蓄積コンテンツで、放送間隔の短いものは、古いものから削除するように構成することができる。（シリーズ予約時にユーザに保存数や、上書きするか否かを指定することができる）また、シリーズ単位やカテゴリ単位で複数の蓄積コンテンツを１グループとしたパターンで蓄積することも可能である。

受信装置２は、ユーザの指定された蓄積済みの蓄積コンテンツについて再生可能である（ステップＳ２０）。例えば、受信装置２が携帯電話機で構成される場合には、ユーザインターフェースを介して、画面に表示される蓄積コンテンツのタイトルに含まれる複数の蓄積コンテンツを指定して、情報を得ることができる。当該蓄積コンテンツに映像、音声、データ放送、字幕のデータが関連付けられている場合には、これらのデータを再生することができる。例えば、蓄積コンテンツのデータ放送には、蓄積コンテンツのサムネイル画像を伝送して、受信装置２側で蓄積予約コンテンツ表の表示の際に利用可能することもできる。

このように、受信装置２は、送信される拡張ＥＩＴ又はＣＳＴを受信して、蓄積予約管理表を作成し、この蓄積予約管理表で蓄積予約の制御管理を行い、蓄積コンテンツを受信して自動蓄積する。特に、受信装置２が移動受信装置（例えば、携帯電話機）の場合、１回のカルーセル方式で蓄積コンテンツを完全に受信して蓄積しきれない場合も、放送局側送信装置１からの再放送のタイミングで再度の蓄積動作を自動的に行うことができる。

ここで、コンテンツ蓄積予約制御部２９の構成及び動作について、図９及び図１０を参照して更に詳細に説明する。

コンテンツ蓄積予約制御部２９は、スケジュール情報取得部２９０１と、時刻情報処理部２９０２と、ＣＳＴ／ＥＩＴ情報管理部２９０３と、蓄積予約制御部２９０４と、対応ファイル判定部２９０５と、イベント識別子判定処理部２９０６と、差分ＤＤＢ判定処理部２９０７と、ダウンロードＩＤ判定処理部２９０８と、蓄積予約管理表生成部２９０９と、蓄積コンテンツ管理表生成部２９１０とを備える。

スケジュール情報取得部２９０１は、入力されるＰＳＩ／ＳＩ情報（即ち、ＥＩＴ番組情報）から拡張ＥＩＴ又はＣＳＴのコンテンツスケジュール情報を抽出してＣＳＴ／ＥＩＴ情報管理部２９０３に送出する。

時刻情報処理部２９０２は、入力されるＰＳＩ／ＳＩ情報（即ち、ＥＩＴ番組情報）から各蓄積コンテンツの開始時刻、放送持続時間、及びコンテンツファイルを一意に表す「イベント識別子」を抽出してＣＳＴ／ＥＩＴ情報管理部２９０３に送出する。

ＣＳＴ／ＥＩＴ情報管理部２９０３は、拡張ＥＩＴ又はＣＳＴのコンテンツスケジュール情報を基に、蓄積予約管理表生成部２９０９を機能させて蓄積予約管理表を生成して、コンテンツファイルを格納する記憶部３０に格納する機能と、対応ファイル判定部２９０５を機能させて拡張ＥＩＴ又はＣＳＴのコンテンツスケジュール情報から蓄積予約可能なファイルがあるか否かを判定させる機能と、蓄積予約制御部２９０４からの指示に応じて蓄積予約を行うコンテンツファイルについて蓄積予約管理表をマーキングする機能と、イベント識別子判定処理部２９０６を機能させてＤＩＩ内の情報（イベント識別子、枝番、データイベント識別子）を判定させる機能と、差分ＤＤＢ判定処理部２９０７を機能させて複数ＤＤＢで伝送されるコンテンツファイルについて未蓄積の差分のＤＤＢを判定させ蓄積させる機能と、ＣＳＴ［ｐ／ｆ］又は拡張ＥＩＴ［ｐ／ｆ］を取得し、予約情報の変更の有無を確認し、変更があれば蓄積予約管理表を更新する機能とを有する。

蓄積予約制御部２９０４は、ユーザに提示された蓄積予約管理表について、ユーザによって指定された蓄積コンテンツの蓄積の予約の制御をＣＳＴ／ＥＩＴ情報管理部２９０３に指示する機能を有する。

対応ファイル判定部２９０５は、拡張ＥＩＴ又はＣＳＴのコンテンツスケジュール情報から蓄積予約可能なファイルがあるか否かを判定する機能を有する。

イベント識別子判定処理部２９０６は、ＤＩＩ内のダウンロードＩＤにおけるイベント識別子（event_id）を判定し、且つイベント識別子（event_id）によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送記述子(file_delivery_descriptor)」内の「ファイル種別情報（file_type_value）」で識別する機能、コンテンツタイプを表す「コンテンツタイプ情報（content_type）」と、「イベント識別子（event_id）」と、コンテンツ情報としての「シリーズ記述子(series_id)」とを組み合わせて、コンテンツタイプごとの予約蓄積制御を行う機能を有する。また、イベント識別子判定処理部２９０６は、ダウンロードＩＤ（downloadID）内のイベント識別子（event_id）と枝番が同一でデータイベント識別子（data_event_id）のみが更新されたコンテンツファイル（つまり、ファイルバージョンが更新されたコンテンツファイル）が存在するか否かを判別し、存在する場合に差し替えや上書き蓄積を行う上書き蓄積判定部２９０６ａを有する。また、上書き蓄積判定部２９０６ａではコンテンツタイプ情報（content_type）やＣＳＴのupdate_flagの情報から上書き更新コンテンツであるかどうかを判別し、上書き蓄積コンテンツの場合で同じシリーズに属する蓄積コンテンツが蓄積されている場合には上書き蓄積をする、蓄積されている同じシリーズに属する蓄積コンテンツがない場合はそのまま蓄積する。

差分ＤＤＢ判定処理部２９０７は、蓄積できたデータ（ＤＤＢ単位）は破棄せずに保存（一時保存）しておき、未取得ＤＤＢがある場合には当該コンテンツファイルのＤＤＢの差分蓄積を実行する機能を有する。

ダウンロードＩＤ判定処理部２９０８は、蓄積予約を行うコンテンツファイルについてカルーセル復号部２５から得られるＤＩＩを取得してダウンロードＩＤ（downloadID）を抽出してイベント識別子判定処理部２９０６及び差分ＤＤＢ判定処理部２９０７に送出する機能と、イベント識別子判定処理部２９０６からの指示に従って、当該拡張ＥＩＴやＣＳＴに対応するコンテンツファイルのＤＤＢを取得及び蓄積を制御すべく制御信号をカルーセル復号部２５に送出する機能を有する。また、ダウンロードＩＤ判定処理部２９０８は、差分ＤＤＢ判定処理部２９０７からの指示に応じて複数ＤＤＢで伝送されるコンテンツファイルについて未蓄積の差分のＤＤＢの取得及び蓄積を制御すべく制御信号をカルーセル復号部２５に送出する機能を有する。

蓄積予約管理表生成部２９０９は、ＣＳＴ／ＥＩＴ情報管理部２９０３の制御によって拡張ＥＩＴ又はＣＳＴのコンテンツスケジュール情報を基に蓄積予約管理表を生成する機能を有する。

蓄積コンテンツ管理表生成部２９１０は、ＣＳＴ／ＥＩＴ情報管理部２９０３の制御によって、蓄積予約管理表に従って蓄積した蓄積コンテンツを管理するための蓄積コンテンツ管理表を生成する機能を有する。

図１０は、コンテンツ蓄積予約制御部２９の動作フローを示す図である。コンテンツ蓄積予約制御部２９は、蓄積予約を実行するために、まず、受信して復号した拡張ＥＩＴ又はＣＳＴのコンテンツスケジュール情報をメモリに展開する（ステップＳ３１）。続いて、コンテンツ蓄積予約制御部２９は、対応ファイル判定部２９０５によって、蓄積予約可能なファイルがあるか否かを判定し、蓄積不能の情報は破棄する（ステップＳ３２）。コンテンツ蓄積予約制御部２９は、イベント識別子判定処理部２９０６によって、蓄積予約可能なコンテンツファイルについて、チャンネル種別をそれぞれサービスＩＤで、メインｃｈ１、独自ｃｈ１及び独自ｃｈ２のチャンネル別蓄積コンテンツを把握し、各チャンネルにおける時間軸方向の編成についてイベント識別子（event_id）で識別し、且つイベント識別子（event_id）によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送記述子(file_delivery_descriptor)」内の「ファイル種別情報（file_type_value）」で識別して、蓄積予約管理表生成部２９０９によって、蓄積予約管理表を生成してユーザに提示し、ユーザによる予約の設定、又は蓄積予約管理表の生成と同時に対応ファイルの自動予約の設定を行う（ステップＳ３３，Ｓ３４）。

続いて、コンテンツ蓄積予約制御部２９は、時刻情報処理部２９０２にて取得したイベント識別子に基づいて蓄積予約時刻の数分前にＣＳＴ／ＥＩＴ情報管理部２９０３を起動させ（ステップＳ３５）、ＣＳＴ［ｐ／ｆ］又は拡張ＥＩＴ［ｐ／ｆ］を取得し（ステップＳ３６）、予約情報の変更の有無を確認し（ステップＳ３７）、変更があれば蓄積予約管理表を更新する（ステップＳ３７）。

続いて、コンテンツ蓄積予約制御部２９は、イベント識別子判定処理部２９０６及びダウンロードＩＤ判定処理部２９０８によって、イベント識別子（event_id）に紐づくダウンロードＩＤ（downloadID）のＤＩＩを取得し、上書き蓄積判定部２９０６ａによって、イベント識別子（event_id）と「枝番」が同一でデータイベント識別子（data_event_id）が異なる蓄積済み蓄積コンテンツの有無を判別し（ステップＳ３９）、有りの場合には、こらから受信する蓄積コンテンツを上書き蓄積するまたは差し替えると判断する（ステップＳ４０）。

続いて、コンテンツ蓄積予約制御部２９は、イベント識別子判定処理部２９０６及びダウンロードＩＤ判定処理部２９０８によって、イベント識別子（event_id）に紐づくダウンロードＩＤ（downloadID）のＤＩＩを含むカルーセル方式のＥＳを取得し（ステップＳ４１）、ＤＩＩ内のダウンロードＩＤにおけるイベント識別子（event_id）を判定し、且つイベント識別子（event_id）によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送記述子(file_delivery_descriptor)」内の「ファイル種別情報（file_type_value）」で識別する機能、コンテンツタイプを表す「コンテンツタイプ情報（content_type）」と、「イベント識別子（event_id）」と、シリーズ番組のコンテンツ情報を識別するための「シリーズ記述子(series_id)」とを組み合わせて、コンテンツタイプごとの予約蓄積制御を行ない、差分ＤＤＢ判定処理部２９０７によって、ＤＤＢの蓄積を完了するまで実行し（ステップＳ４２）、未完了である場合には、差分のＤＤＢを取得して蓄積する（ステップＳ４３）。例えば図１１（Ａ）に示すように、ファイル種別情報で判別されるコンテンツファイルの内容の種別が、時間編成のコンテンツファイルのうち同一のコンテンツファイルの蓄積放送が予定されているものである場合、図１１（Ｂ）に示すように、ＣＳＴ又は拡張ＥＩＴのイベント識別子（event_id）を、図１１（Ｃ）に示すように、カルーセル方式のＤＩＩ内のダウンロードＩＤ（downloadID）に関連付けておくことで、ＣＳＴ又は拡張ＥＩＴのイベント識別子（event_id）ごとにＤＤＢを特定し、同一ファイル名に対して上書き蓄積を行うことや、差分のＤＤＢ受信を行うことが可能となる。

コンテンツ蓄積予約制御部２９は、蓄積が完了した場合には（ステップＳ４４）、蓄積予約管理表から対応ファイルの予約制御の旨を削除し、蓄積コンテンツ管理表生成部２９１０によって、蓄積予約管理表に従って蓄積した蓄積コンテンツを管理するための蓄積コンテンツ管理表を生成して、記憶部３０に格納する。蓄積コンテンツ管理表は、ユーザの指示によって提示可能なテーブルである。

従って、コンテンツ蓄積予約制御部２９は、ユーザによって指定された蓄積コンテンツの蓄積予約を実行する際に、カルーセル伝送方式で伝送される「本放送（１回目の放送）」の蓄積コンテンツの取得と、カルーセル伝送方式で伝送される「再放送（２回目以降の放送）」の蓄積コンテンツの取得で、蓄積予約の動作を制御することができるだけでなく、コンテンツタイプを表す「コンテンツタイプ情報（content_type）」と、「イベント識別子（event_id）」と、コンテンツ情報としての「シリーズ記述子(series_id)」とを組み合わせて、コンテンツタイプごとの予約蓄積制御を行なうことができる。

ユーザによって、記憶部３０に記憶した蓄積コンテンツ管理表の読出しの指定が可能であり、記憶部３０に記憶した蓄積コンテンツは、蓄積コンテンツ一覧表示・再生指示部３１によって、再生制御が為され、ユーザに対して提示させることができる。

このように、受信装置２は、蓄積コンテンツの蓄積予約（映像等の場合、予約録画を含む）に必要な情報を拡張ＥＩＴ又はＣＳＴから取得することができる。拡張ＥＩＴ又はＣＳＴには「ファイル伝送記述子(file_delivery_descriptor)」が追加され、さらに「ファイル伝送記述子(file_delivery_descriptor)」内の「ファイル種別情報（file_type_value）」でファイル種別を直ちに識別して、蓄積コンテンツの蓄積予約のための蓄積予約管理表を直ちに作成して、直ちに蓄積コンテンツを取得することもできる。このため、受信装置２の受信処理負担を軽減させ、且つ受信不良のリスクを軽減させると共に、受信不良で未取得のＤＤＢのみを取得してコンテンツファイルを受信完了させることが可能となる。

受信環境が不安定な移動受信においては、ファイルサイズの大きいものを長時間かけて配信するより、ファイルのサイズが小さいものを短時間で配信する方が受信できる可能性が高くなる。そのため、ニュース番組などは、個々のニュース項目ごとに番組を分割して配信する方が効率的である。

つまり、配信されるコンテンツファイルは、イベント識別子（event_id）と、イベント識別子（event_id）を埋め込んだＤＩＩのダウンロードＩＤ（downloadID）を用いてユニークに特定されるため、項目ニュースなどのファイルサイズが小さく配信時間が短いファイルの場合、編成時間軸上の拡張ＥＩＴ又はＣＳＴの情報が多数必要となり、拡張ＥＩＴ又はＣＳＴの情報量が大きくなってしまう。そこで、ダウンロードＩＤ（downloadID）の１６ｂｉｔ〜２７ｂｉｔ目までをイベント識別子（event_id）の「枝番」を設けることで、イベント識別子（event_id）ではニュース番組などの大項目を指定し、枝番を用いて、項目ニュースの個々のニュースを特定することで、拡張ＥＩＴ又はＣＳＴの情報量を増やさずに詳細なファイルを配信可能となる。

さらに、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプを、拡張ＥＩＴ又はＣＳＴに含まれる「コンテンツタイプ情報（content_type）」から識別し、コンテンツ情報としての「シリーズ記述子(series_id)」からシリーズ番組であるか否かを識別し、ＤＩＩに含まれる「イベント識別子（event_id）」と組み合わせて、コンテンツタイプに応じた予約蓄積制御を行なうことができるようになる。

以上のように、本発明によれば、受信装置２は、蓄積予約に使用するために事前に拡張ＥＩＴ又はＣＳＴの情報を取得し、拡張ＥＩＴ又はＣＳＴに記述された、実際に蓄積放送される時間情報や、「ファイル伝送記述子」からファイルの情報及びイベント識別子を識別して、これらの情報を元に蓄積されるファイルが対応しているかどうかを判断した上で、さらに、コンテンツタイプに応じた蓄積予約を行うので、効率的な蓄積放送の予約を行うことが可能となる。

また、データカルーセルの中の全てのＤＤＢは、当該データカルーセルの中ではユニークなブロック番号を持つため、イベント識別子（event_id）毎に、ユニークなＤＤＢを受信装置２で管理することが可能であり、受信状態が不安定な場合でも、繰り返し送出されるデータカルーセルの中で、差分のＤＤＢのみを取得することで効率的にファイルを蓄積可能である。

以下、より具体的な例を示して、従来技術との相違点を説明する。

コンテンツスケジュールの情報を事前に取得して蓄積コンテンツの蓄積予約を行うにあたり、受信装置２側の要求と放送局側送信装置１の要求とはずれがあるため、このずれを緩和する仕組みを提供することになる。

例えば、図１４に示すように、受信装置２側では、番組Ａ（event_id＝１）でファイル要素（１，２，３）のコンテンツファイルを３回の時間編成で受信可能とし、蓄積コンテンツの差し替え更新がある場合に（例えば、ファイル要素３’）、番組Ｂ（event_id＝２）でファイル要素（３’，４，５）のコンテンツファイルを３回の時間編成で受信可能とすることで、蓄積コンテンツの差し替え更新の識別を行いたいとする。この場合、放送局側送信装置１に対して最新ニュースの送出を遅らせることとなり、受信装置２側にとっても差し替えまでの時間がかかることになる。

一方、放送局側送信装置１の要求としては、一刻も早く最新ニュースを送出するために、１つの番組（event_id＝１）でファイル要素を順次更新しながら６回の時間編成とし、蓄積コンテンツの差し替え更新の必要性が生じた（例えば、ファイル要素３’）時点で、更新しながら送出したいとする。この場合、受信装置２側では、蓄積コンテンツの蓄積のために、既蓄積の蓄積コンテンツであるにも関わらず全てのカルーセルを受信して監視しなければならず、蓄積コンテンツの蓄積率の低下や蓄積制御のムラが生じたり、消費電力負荷の増大を招くことになり、他のチャンネルの蓄積スケジュールと競合して取りこぼしを生じる可能性が増大することになる。

このため、本発明では、受信装置２側で、未取得（未蓄積）のＤＤＢのみを取得してコンテンツファイルを受信完了させることが可能とし、ファイルのサイズが小さいものを短時間で配信して受信できる可能性を高めるべく、ＣＳＴ又は拡張ＥＩＴのファイルサイズを可能な限り小さくするとともに、蓄積コンテンツの種類に応じて（例えば、ニュース番組などは、個々のニュース項目ごとに番組を分割して配信する方が効率的である。）、拡張ＥＩＴ又はＣＳＴに含まれる「コンテンツタイプ情報（content_type）」からのコンテンツタイプの値と、コンテンツ情報としての「シリーズ記述子(series_id)」からの値と、ＤＩＩに含まれる「イベント識別子（event_id）」、「枝番」及び「データイベント識別子（data_event_id）」の各値と組み合わせて、コンテンツタイプに応じた予約蓄積制御を行なうことができるように構成している。

以下、個別的に具体例を示す。以下の例では、更新フラグ（update flag）で更新するべき蓄積コンテンツであるか否かを判別する例を説明するが、「コンテンツタイプ情報（content_type）」の情報に、更新フラグ（update flag）を組み入れてもよい。

〔単発コンテンツの送出及び蓄積〕
図１５は、単発コンテンツの送出及び蓄積を例示する図である。カルーセルで放送される単発コンテンツの場合、ＣＳＴ又は拡張ＥＩＴでは、「シリーズ記述子(series_id)」が記載されず、更新フラグ（update flag）が‘０’であり、「コンテンツタイプ情報（content_type）」が‘０’であるから、受信装置２側では、ＤＩＩ内の情報から、蓄積コンテンツの「イベント識別子（event_id）」を参照して、未蓄積の差分ＤＤＢの取得のみを行うよう制御することができる。

例えば、図１５の例では、受信装置２は、ＣＳＴ又は拡張ＥＩＴで、event_id＝１の蓄積コンテンツＡを蓄積予約し、放送時間になるとＤＩＩを取得し、event_id＝１であれば該当するＤＤＢを取得して蓄積し、蓄積完了後、蓄積予約管理表の予約情報を破棄し、２回目以降の繰返し放送は受信しない。続いて、受信装置２は、ＣＳＴ又は拡張ＥＩＴで、event_id＝２の蓄積コンテンツＢを蓄積予約し、放送時間になるとＤＩＩを取得し、event_id＝２であれば該当するＤＤＢを取得して蓄積し、蓄積に失敗した場合には、次の繰返し放送時刻に蓄積に失敗した差分ＤＤＢについて再度取得し、蓄積完了後、蓄積予約管理表の予約情報を破棄し、次回以降の繰返し放送は受信しないでよくなる。

〔シリーズコンテンツの送出及び蓄積〕
図１６は、シリーズコンテンツの送出及び蓄積を例示する図である。カルーセルで放送されるシリーズコンテンツの場合、ＣＳＴ又は拡張ＥＩＴでは、「シリーズ記述子(series_id)」が‘１’であり、更新フラグ（update flag）が‘０’であり、「コンテンツタイプ情報（content_type）」が‘１’であるから、受信装置２側では、ＤＩＩ内の情報から、蓄積コンテンツの「イベント識別子（event_id）」を参照して、未蓄積の差分ＤＤＢの取得のみを行うよう制御することができる。また、ＣＳＴ又は拡張ＥＩＴに関して送信するファイルに変更が生じた場合（蓄積コンテンツＣ→Ｂ）も、更新されたＣＳＴ又は拡張ＥＩＴを取得して、ＤＩＩ内の情報から、単発コンテンツの「イベント識別子（event_id）」を参照して、未蓄積の差分ＤＤＢの取得のみを行うよう制御することができる。

例えば、図１６の例では、受信装置２は、ＣＳＴ又は拡張ＥＩＴで、event_id＝１の蓄積コンテンツＡをシリーズコンテンツとしてseries_id＝１の全ての蓄積コンテンツを自動蓄積予約し、放送時間になるとＤＩＩを取得し、event_id＝１であれば該当するＤＤＢを取得して蓄積し、蓄積完了後、蓄積予約管理表の予約情報を破棄し、２回目以降の繰返し放送は受信しない。続いて、受信装置２は、ＣＳＴ又は拡張ＥＩＴで、event_id＝２の放送時間になるとＤＩＩを取得し、event_id＝２であれば該当するＤＤＢを取得して蓄積し、蓄積に失敗した場合には、次の繰返し放送時刻に蓄積に失敗した差分ＤＤＢについて再度取得し、蓄積完了後、蓄積予約管理表の予約情報を破棄し、次回以降の繰返し放送は受信しないでよくなる。続いて、放送局側送信装置１がevent_id＝３でseries_id＝１の蓄積コンテンツＣを放送する予定であったが、蓄積コンテンツＣの代わりに以前に放送した同じシリーズに属する蓄積コンテンツＢを送ることになった場合、ＣＳＴ又は拡張ＥＩＴで、event_id＝３に関する情報を削除し、event_id＝２の放送時刻にevent_id＝３の放送時刻を追加する（ＣＳＴ又は拡張ＥＩＴに、event_id＝２の情報がない場合には再度追加する）。続いて、受信装置２は、ＣＳＴ又は拡張ＥＩＴで、event_id＝３の放送時間になるとevent_id＝２の蓄積コンテンツＢについて蓄積可能となることを判別でき、再度蓄積する場合には、蓄積を実行する。

〔複数の項目があるシリーズコンテンツの送出及び蓄積〕
図１７は、複数の項目があるシリーズコンテンツの送出及び蓄積を例示する図である。カルーセルで放送される複数の項目があるシリーズコンテンツの場合、ＣＳＴ又は拡張ＥＩＴでは、「シリーズ記述子(series_id)」が‘１’であり、更新フラグ（update flag）が‘０’であり、「コンテンツタイプ情報（content_type）」が‘１’であるから、受信装置２側では、ＤＩＩ内の情報から、蓄積コンテンツの「イベント識別子（event_id）」を参照して、未蓄積の差分ＤＤＢの取得のみを行うよう制御することができ、複数項目コンテンツについては、受信装置２は、ＤＩＩにおける「イベント識別子（event_id）」の「枝番」及び「バージョン（data_event_idの値）」を参照することで項目ごとに未蓄積の差分ＤＤＢの取得のみを行うよう制御することができる。

例えば、図１７の例では、受信装置２は、ＣＳＴ又は拡張ＥＩＴでevent_id＝１の蓄積コンテンツＡの蓄積予約をする。その際、シリーズ予約をする。シリーズ予約を選択すると、series_id＝１の全ての蓄積コンテンツが自動で予約される。受信装置２は、放送時刻になるとＤＩＩを取得し、event_id＝１であれば蓄積し、この時、ＤＩＩ内の枝番で蓄積コンテンツを識別する。受信装置２は、次のＤＩＩが来ると、event_id＝１でまだ蓄積していない蓄積コンテンツ（枝番）であれば蓄積する。受信装置２は、蓄積に失敗した蓄積コンテンツがあると、次回の放送時刻に再度取得に行き、差分受信を行う。全ての蓄積コンテンツを蓄積出来たら、次回以降の放送時刻に、取得に行かない。一方、放送局側送信装置１は、event_id＝２でseries_id＝１の蓄積コンテンツＢを放送する予定であったが、蓄積コンテンツＢの代わりに以前に放送した同じシリーズに属する蓄積コンテンツＡを送ることになった場合、ＣＳＴ又は拡張ＥＩＴでevent_id＝２に関する情報を削除し、event_id＝１の放送時刻にevent_id＝２の放送時刻を追加する（ＣＳＴ又は拡張ＥＩＴにevent_ied＝１の情報がない場合は、再度追加する。）。したがって、受信装置２は、すでに蓄積コンテンツＡを蓄積していれば、取得にいかなくともよくなり、まだ、蓄積していない場合は、放送時刻に取得に行くように構成することができる。また、event_id＝３の蓄積コンテンツＣには、３つの枝番があり、その中には以前放送したものを含んでいる場合、受信装置２は、event_id＝３の放送時刻になるとＤＩＩを取得し、event_id＝３であれば蓄積コンテンツＣを蓄積するが、既に蓄積済みの枝番があれば重複保存しない。また、受信装置２は、蓄積に成功すると次回以降の繰り返し放送時刻には取得に行かなくともよくなる。また、受信装置２は、event_id＝４の蓄積コンテンツＤには、３つの枝番があり、その中には、以前放送したが内容を変更したものがあり、その枝番のバージョン（data_event_idの値）が前回取得した値と異なっていることを判別した場合、event_id＝４の放送時刻になりＤＩＩを取得し、event_id＝４であれば蓄積コンテンツＤを蓄積する際に、既に蓄積済みの枝番でバージョンが異なるものは蓄積し差し替えるように構成することができる。尚、受信装置２は、蓄積に成功すると次回以降の繰り返し放送時刻には取得に行かなくともよくなる。

〔上書き更新コンテンツの送出及び蓄積〕
図１８は、上書き更新コンテンツの送出及び蓄積を例示する図である。カルーセルで放送される上書き更新コンテンツの場合、ＣＳＴ又は拡張ＥＩＴでは、「シリーズ記述子(series_id)」が‘１’であり、更新フラグ（update flag）が‘１’であり、「コンテンツタイプ情報（content_type）」が‘２’（ただし、「上書き更新」の識別を意図するときは、上記‘０’でも‘１’でもよい）であるから、受信装置２側では、ＤＩＩ内の情報から、蓄積コンテンツの「イベント識別子（event_id）」を参照して、未蓄積の差分ＤＤＢの取得のみを行うよう制御することができ、同じseries_idで蓄積済みの蓄積コンテンツと異なるイベント識別（event_id）の蓄積コンテンツを受信した場合は、上書き蓄積する。

以下、他の例として、コンテンツタイプに応じた蓄積予約を実行させるために、「シリーズ記述子(series_id)」と「枝番」の組合せで判別して蓄積を実行する例を説明する。

〔単発コンテンツの送信と受信〕
図１９（ａ）,（ｂ）は、単発コンテンツの送信例を示す図である。図１９（ａ）に示すような時間編成で蓄積コンテンツ（ゲーム［Ａ］、ゲーム［Ｂ］）を放送する場合、受信装置側で受信失敗を考慮して、所定回数放送する。本例では、受信装置２は、「イベント識別子（event_id）」で放送枠（最初の放送と繰返し放送を含む）を識別し、「シリーズ記述子(series_id)」の記載がない、又は‘０’によって、「コンテンツタイプ情報（content_type）」を参照せずとも、「単発コンテンツ」として識別する。「枝番」は、単発コンテンツが「ゲーム［Ａ］、ゲーム［Ｂ］」であることを識別するために用いる。蓄積予約の動作は、図１５の例と同様に、一旦受信に成功した蓄積コンテンツについて再度受信する必要性がなくなる。

〔シリーズコンテンツの送出及び蓄積〕
図２０（ａ）,（ｂ）は、シリーズコンテンツの送信例を示す図である。図２０（ａ）に示すような時間編成で蓄積コンテンツ（シリーズコンテンツ［１］、［２］）を放送する場合、受信装置側で受信失敗を考慮して、所定回数放送する。本例では、受信装置２は、「シリーズ記述子(series_id)」の記述が‘１’である全ての放送枠（event_id=1,2）を同じシリーズの蓄積コンテンツが放送される放送枠として識別し、event_id＝１の放送時刻になるとＤＩＩを取得し、event_id＝１であれば蓄積し、event_id＝２の放送時刻になるとＤＩＩを取得し、図２０に示すように「シリーズ記述子(series_id)」と「枝番」の組合せが異なる場合には、「シリーズコンテンツ」の別の蓄積コンテンツであると判別して蓄積を実行する。

〔複数項目コンテンツの送出及び蓄積〕
図２１（ａ）,（ｂ）は、複数項目コンテンツの送信例を示す図である。図２１（ａ）に示すような時間編成でコンテンツ（複数項目コンテンツ［Ｆ］〜［Ｌ］）を放送する場合、受信装置側で受信失敗を考慮して、所定回数のカルーセルで放送する。本例では、受信装置２は、「シリーズ記述子(series_id)」の記述が‘１’である全ての放送枠（event_id=1,2）を同じシリーズの蓄積コンテンツが放送される放送枠として識別し、event_id＝１の放送時刻になるとＤＩＩを取得し、「枝番」を参照して、「シリーズコンテンツ」のうちの「複数項目コンテンツ」であると認識し、「枝番」毎の蓄積予約の実行を行って、event_id＝１で未蓄積の「枝番」であれば蓄積し、event_id＝２の放送時刻になるとＤＩＩを取得し、図２１に示すように蓄積済みの蓄積コンテンツのものと、「シリーズ記述子(series_id)」と「枝番」の組合せが異なる場合には、「シリーズコンテンツ」の別の蓄積コンテンツであると判別して蓄積を実行する（「シリーズ記述子(series_id)」と「枝番」の組合せが同じである場合には、蓄積しない）。

〔上書き更新コンテンツの送出及び蓄積〕
図２２（ａ）,（ｂ）は、上書き更新コンテンツの送信例を示す図である。図２２（ａ）に示すような時間編成で蓄積コンテンツ（上書き更新コンテンツ）を放送する場合、受信装置側では逐次新しい情報を蓄積するべく、所定回数の放送編成で逐次放送する。本例では、受信装置２は、「イベント識別子（event_id）」の値に関連付けられた「シリーズ記述子(series_id)」の記述が‘１’であり、且つ「コンテンツタイプ情報（content_type）」が「上書き更新コンテンツ」の旨を示す場合には、「イベント識別子（event_id）」の値に関連付けられた「シリーズ記述子(series_id)」の記述が‘１’の全ての放送枠（event_id=1,2,3）を同じシリーズの蓄積コンテンツが放送される放送枠として識別し、event_id＝１の放送時刻になるとＤＩＩを取得し、「枝番」と「データイベント識別子（data_event_id）」を参照して、各event_idの蓄積コンテンツが逐次蓄積すべきコンテンツであると認識し、図２２に示すように蓄積済みの蓄積コンテンツのものと、「シリーズ記述子(series_id)」と「枝番」の組合せが同じで、「データイベント識別子（data_event_id）」が異なる場合には蓄積を実行して前回蓄積した蓄積コンテンツを上書きするために削除する。

〔蓄積コンテンツの差し替え〕
図２３（ａ）,（ｂ）は、差し替えを行う蓄積コンテンツの送信例を示す図である。図２３（ａ）に示すような時間編成で蓄積コンテンツ（差し替えコンテンツ）を放送する場合、放送局側で差し替えを行いたい場合がある。本例では、受信装置２は、「シリーズ記述子(series_id)」の記述が‘１’の全ての放送枠（event_id=1,2,4）を同じシリーズの蓄積コンテンツが放送される放送枠として識別し、event_id＝１の放送時刻になるとＤＩＩを取得し、「枝番」と「データイベント識別子（data_event_id）」を参照して、図２３に示すように蓄積済みの蓄積コンテンツのものと、「シリーズ記述子(series_id)」と「枝番」の組合せが同じで、「データイベント識別子（data_event_id）」が異なる場合には蓄積を実行して前回蓄積した蓄積コンテンツを差し替えるために削除する。つまり、event_id＝４の放送時刻になるとＤＩＩを取得し、event_id＝４で、「シリーズ記述子(series_id)」と「枝番」の組合せが同じで、「データイベント識別子（data_event_id）」が異なる場合に蓄積コンテンツが修正されて再度放送されたとみなし、既に蓄積済みのものと差し替えを行う。

次に、本発明の更なる応用例について説明する。

〔複数項目コンテンツのジャンル情報伝送〕
上記の例では、ある放送枠で複数項目コンテンツを送る場合、処理能力の高くない受信装置では拡張ＥＩＴ［ｐ／ｆ］又はＣＳＴ［ｐ／ｆ］の受信処理を軽くする必要があり、ＣＳＴ又は拡張ＥＩＴには放送枠のコンテンツ情報しか記載しないように構成しているため、複数項目コンテンツ毎にジャンルを割り当てる方法がない。例えば、蓄積コンテンツ放送の「全国ニュース１２時」なる放送枠があり、この放送枠で、政治や経済やスポーツに関する複数のニュースをジャンル内別情報として送りたい場合、ＣＳＴ又は拡張ＥＩＴには「ニュース」というジャンルを記載するのみであり、ＣＳＴ又は拡張ＥＩＴのみでは、受信装置２に、蓄積したニュース毎に政治や経済やスポーツなどのジャンルを伝えることができない。

そこで、ＤＩＩの中に「ジャンル情報」を追加記載することで、放送局側送信装置１は、ＣＳＴ又は拡張ＥＩＴにおけるある放送枠で送られる複数項目コンテンツ毎にジャンルを割り当てて、蓄積コンテンツを送信する。受信装置２は、複数項目コンテンツ毎にジャンルを識別して蓄積でき、蓄積コンテンツの提示や検索に利用できるようにする。

〔複数項目コンテンツのコンテンツ数の伝送〕
上記の例では、ある放送枠で複数項目コンテンツを送る場合、放送時刻の間、それぞれ別々のカルーセルで伝送する。全ての蓄積コンテンツを送り終わると、放送期間中繰り返し放送する。処理能力の高くない受信装置では拡張ＥＩＴ［ｐ／ｆ］又はＣＳＴ［ｐ／ｆ］の受信処理を軽くする必要があり、項目別の蓄積コンテンツ情報を送っていない。この場合、受信装置２は、放送時刻内でＤＩＩを順に取得し、蓄積していないＤＩＩがあれば蓄積する。受信環境が良い場合は、同じ内容のＤＩＩが放送された段階で、すべての蓄積コンテンツを蓄積した判断し、終了することができるが、受信環境が悪く放送波を受信できない期間があった場合は、すべての蓄積コンテンツを蓄積したと判断することができない場合がある。

そこで、ＤＩＩの中にコンテンツ数を追加記載することで、受信環境が悪い状態でも、受信装置２は複数の蓄積コンテンツを全て蓄積できたのか、できなかったのかを判断できるようにする。これは、複数項目コンテンツを別々のカルーセルで伝送する際に、受信装置２がカルーセルの切り替え時にすべての蓄積コンテンツを蓄積したと誤判断して、次のカルーセルを取りこぼすことがないようにするという効果もある。

〔全ての放送枠でevent_idを同一にして送信〕
既存のＥＩＴでは、蓄積コンテンツを一意の「イベント」として識別するためにevent_idを使用するが、複数項目コンテンツ内の各蓄積コンテンツでは、別のevent_idで同じ蓄積コンテンツを送るようにすることが受信装置２側にとって望ましい場合があり、event_idと蓄積コンテンツを１対１に対応させることができない。そこで、この場合、series_idと枝番の組み合わせによって、蓄積コンテンツを一意に識別する例を上述した。ただし、この様に構成すると、全ての蓄積コンテンツを一意に識別する値としてevent_idを統一的に使用したいという要望に対応できないことになる。

そこで、放送局側送信装置１は、ニュースなどの複数項目コンテンツや気象情報や道路交通情報などの自動更新コンテンツのevent_idを、全ての放送で同じ値として用い、受信装置２は、当該event_idの蓄積コンテンツについて全ての放送時刻で受信することにする。図２４は、本発明による一実施例の放送システムにおける全ての放送枠でevent_idを同一にする構成を例示する図である。例えば、data_event_idを取得して更新の有無を確認する代わりに、当該event_idの蓄積コンテンツについてのｐ／ｆを受信し、ｐ／ｆに含まれる後述する更新情報記述子もしくは識別子によって更新すべき蓄積コンテンツの存在の有無を判別するように構成することができる。

〔蓄積コンテンツの変更情報を蓄積実行前に通知〕
上記の例では、携帯端末向けマルチメディア放送で放送波の蓄積を実現するには、受信環境によらず蓄積できるよう送出時刻を変えて繰り返し放送を行うことができ、さらに、例えば携帯端末はバッテリー駆動のため、消費電力を抑制することが重要となることから、一度受信に成功した場合は、再送時は取得に行かない例を説明した。

また、受信装置２を休止状態にすると、途中でニュースコンテンツ等変更や差し替えが生じる場合、変更があったことを知る手段として、再送時刻すべてにおいて受信装置２を起動し、ＤＩＩのdata_event_IDを取得することで、差替を確認することができるようにした。

しかしながら、蓄積コンテンツの送出方法によっては、受信装置２の消費電力が最悪条件で再送回数倍となり、効率が悪くなる。また、変更情報を得るにはＤＩＩを受信する必要があるため、ＤＩＩは蓄積コンテンツ本体を送出している間しか流れていないことから、再送時刻にならないと変更があるかどうか受信装置２では分からないという課題が残る。

そこで、受信装置２に蓄積コンテンツの変更の有無を事前に通知し、不必要な場合に受信動作を行わなくて済む仕組みを提供する。ＥＰＧやＥＣＧといった番組スケジュールを送るＳＩに、蓄積コンテンツ単位に再送時の変更の有無を伝える情報を付与することで、受信装置２では再送時に起動し、ＳＩ情報を取得するだけで、再送コンテンツのバージョンが変更されていないかを把握することが可能となり、変更がある場合は蓄積動作に、変更がない場合はスタンバイ状態に移行することができる。このような場合に対処するために、再送コンテンツのバージョンが変更される旨を表す記述子を更新情報記述子もしくは識別子として新たに設け、拡張ＥＩＴ又はＣＳＴに組み入れるように構成するのが好適である。例えば、拡張ＥＩＴ［ｐ／ｆ］又はＣＳＴ［ｐ／ｆ］のファイル伝送記述子のex_event_idとdata_event_idでコンテンツ（項目単位で可能）に更新があったかどうかを事前に判断することや、後述するＣＳＴ[ｓｃｈｅｄｕｌｅ]とＣＳＴ［ｐ／ｆ］のfile_version_numberで蓄積コンテンツの更新があったかどうかを事前に判断することが可能である。

〔蓄積コンテンツの位置情報を通知〕
携帯端末向けマルチメディア放送の蓄積コンテンツを、受信装置のアプリケーション（地図アプリケーション）と関連付けるためには、受信装置２に蓄積コンテンツ毎の位置情報を提供するのが好ましい。また、その際、蓄積容量や電池容量の少ない受信装置では位置情報をもとに不要な蓄積コンテンツを蓄積しないことも必要となる。しかし、メタデータを使用できない狭帯域の放送波の蓄積では、蓄積前や蓄積後に位置情報を取得する手段がない。

そこで、蓄積コンテンツ毎の位置情報を、ＥＰＧやＥＣＧといった番組スケジュールを送るＳＩやＤＩＩや所定のリソースリストに記載して受信装置２に提供することで、蓄積した蓄積コンテンツを受信装置のアプリケーションと関連づけることができる。例えば、図２５（ａ）に示すように、ＤＩＩに、蓄積コンテンツごとの緯度・経度情報を記述しておくやり方と、図２５（ｂ）に示すように、リソースリストと蓄積コンテンツを一組としたデータを構成し、このリソースリストに、蓄積コンテンツごとの緯度・経度情報を記述しておくやり方が考えられる。

これにより、例えば、逐次更新する交通情報のような蓄積コンテンツを受信する移動受信端末は、緯度・経度情報に関連付けられた蓄積コンテンツを表示できるようになる（図２６参照）。

このように、ＥＰＧやＥＣＧといった番組スケジュールを送るＳＩに位置情報を記載することで、不要な場所の蓄積コンテンツを蓄積しないという制御が可能となり、受信装置の蓄積容量や電池容量に対する負荷を軽減できる。

〔ＣＳＴで現在と次に放送されるコンテンツ情報を送信〕
上記の例では、受信装置２が、蓄積コンテンツの蓄積を実行する直前に、拡張ＥＩＴ［ｐ／ｆ］又はＣＳＴ［ｐ／ｆ］を取得する例について説明した。しかしながら、現在と次以外の放送時刻を含むＣＳＴでは、繰返し放送が多くなると（具体的には、図２７に示すように現在と次に放送される蓄積コンテンツに関する部分のみを、それぞれＣＳＴ［ｐ／ｆ］を構成するＣＳＴ［ｐ］とＣＳＴ［ｆ］としても）、確認用のテーブルサイズも大きくなるという課題を生じる。

そこで、他のやり方として、ＣＳＴであれば、蓄積コンテンツごとの放送時刻の情報を格納していたとしても、現在と次に放送される蓄積コンテンツの１回分の放送時刻に関する部分のみを、それぞれＣＳＴ［ｐ／ｆ］を構成するＣＳＴ［ｐ］とＣＳＴ［ｆ］として構成する（図２８参照）。これにより、蓄積対象以外の蓄積コンテンツに関するｐ／ｆ情報まで受信する必要が無くなるとともに、テーブルサイズを最小化することができる。

他のやり方として、ＣＳＴであれば、蓄積コンテンツごとの放送時刻の情報を格納していたとしても、現在と次に放送される蓄積コンテンツの２回分の放送時刻に関する部分のみを、それぞれＣＳＴ［ｐ／ｆ］を構成するＣＳＴ［ｐ］とＣＳＴ［ｆ］として構成する（図２９参照）。これにより、繰返し放送回数が多くても、当面要求される時刻内の情報のみとなり、テーブルサイズを最小化することができる。また、次の繰返し放送があるのか否かが分かり、蓄積失敗時の動作を受信装置２が判断できる。

〔複数項目コンテンツ情報を拡張ＥＩＴ／ＣＳＴで送信〕
拡張ＥＩＴ／ＣＳＴで複数項目コンテンツの各項目コンテンツの情報を送り、受信機は処理能力に応じて各項目コンテンツの情報を利用できるようにする。受信処理能力の低い受信装置は各項目コンテンツの情報を無視することができる。

各項目コンテンツの情報には、枝番とデータイベント識別子（data_event_id）が含まれ、複数項目コンテンツに含まれる項目コンテンツ数も知ることができる。また、各項目コンテンツのジャンル情報も記載することができる。例えば、ファイル伝送記述子に図３０のように記載することができる。

〔file_type_valueとcontent_typeの統合〕
また、ファイル伝送記述子内のfile_type_valueとcontent_typeは、一つの識別子としてまとめて拡張ＥＩＴ又はＣＳＴに記述することができる。例えば、file_type_valueにまとめる場合、file_type_valueには、ＴＳファイルなどのファイル種別情報、シリーズコンテンツや上書き更新コンテンツなどのコンテンツタイプ情報、映像コンテンツや音声とデータ放送からなる蓄積コンテンツなどコンテンツ構成情報が少なくとも含まれる。
この場合、現在と次のＣＳＴ［ｐ／ｆ］と、それ以外であるＣＳＴ［ｓｃｈｅｄｕｌｅ］のデータ構造は図３１のようになる。file_version_numberは更新情報識別子を示す。ＣＳＴ［ｐ／ｆ］には、複数項目コンテンツの各項目コンテンツの情報を含むファイル伝送記述子を挿入している。コンテンツニブルレベル１（Content_nibble_level1）とコンテンツニブルレベル２（content_nibble_level2）はそれぞれ大分類、中分類のジャンル情報であり、組み合わせて各項目コンテンツのジャンルを指定する。なお、サービス内で一つのデータ列しか使用しない運用においては、component_tagを省略することも可能である。また、ＤＩＩには、複数項目コンテンツの項目数やジャンル情報を含むファイル情報記述子を挿入している。
複数項目コンテンツを蓄積する際、項目コンテンツの数や各項目コンテンツのジャンル情報をＤＩＩ内のファイル情報記述子から取得する。処理能力の高い受信機は、ＣＳＴ［ｐ／ｆ］のファイル伝送記述子から項目コンテンツの数や各項目コンテンツのジャンル情報を取得することができる。
更新や差し替えの発生の有無を受信装置２はＣＳＴ［ｐ／ｆ］のfile_version_numberで判断し、ＤＩＩのデータイベント識別子（data_event_id）の値が変わっていれば上書き更新や差し替えを行う。処理能力の高い受信装置２は、ＣＳＴ［ｐ／ｆ］のファイル伝送記述子のデータイベント識別子（data_event_id）の値を確認し、値が変わっている項目コンテンツの上書き更新や差し替えを行う。

従って、包括的には、放送局側送信装置１において、番組スケジュールテーブル（拡張ＥＩＴ又はＣＳＴ）は、各コンテンツファイルを放送するサービスを一意に指定するサービスＩＤと、開始時刻、放送持続時間、及びコンテンツファイルを一意に表すイベント識別子と、コンテンツタイプを表すコンテンツタイプ情報とを含み、この番組スケジュールテーブルを所定間隔で送信する番組スケジュールテーブル送信手段と、番組スケジュールテーブル内で関連付けたイベント識別子を有するコンテンツファイルをデータブロックにてカルーセル方式で送信するコンテンツファイル送信手段とを備えるように構成され、イベント識別子は、前記データブロックとともに放送するヘッダ情報にも記述されており、コンテンツファイル送信手段は、受信側でコンテンツタイプに応じた蓄積動作を行うよう、当該ヘッダ情報と、コンテンツタイプ情報の組み合わせを制御して当該コンテンツファイルを送信するように構成される。

また、包括的には、受信装置２において、番組スケジュールテーブル（拡張ＥＩＴ又はＣＳＴ）を受信して、該番組スケジュールテーブル（拡張ＥＩＴ又はＣＳＴ）で関連付けられた蓄積コンテンツを蓄積予約可能なコンテンツファイルにおける時間軸方向の編成についてイベント識別子で識別し、イベント識別子によって識別されるコンテンツファイルの蓄積を、データブロックとともに放送されるヘッダ情報とコンテンツタイプ情報の組み合わせによって識別して、蓄積予約するための蓄積予約管理表を生成するとともに、蓄積予約するべく規定された蓄積コンテンツを、所定の開始時刻で蓄積予約の開始を制御し、開始時刻で蓄積予約した蓄積コンテンツの蓄積を、ヘッダ情報とコンテンツタイプ情報の組み合わせに応じてカルーセル方式のデータブロック単位で実行するように構成される。

また、包括的には、受信装置２において、デジタル放送の放送波でコンテンツファイルを受信する際に、該複数の蓄積コンテンツを受信側で蓄積予約させるのに必要とされる番組スケジュールテーブル（拡張ＥＩＴ又はＣＳＴ）を受信する際に、番組スケジュールテーブル（拡張ＥＩＴ又はＣＳＴ）は、各コンテンツファイルを放送するサービスを一意に指定するサービスＩＤと、開始時刻、放送持続時間、及びコンテンツファイルを一意に表すイベント識別子と、コンテンツタイプを表すコンテンツタイプ情報とを含み、イベント識別子は、デジタル放送で放送されるデータブロックのヘッダ情報にも記述されており、前記イベント識別子によって識別されるコンテンツファイルを蓄積予約するための蓄積予約管理表を、コンテンツタイプ情報を付加して生成しておき、蓄積予約管理表で蓄積予約するべく規定された蓄積コンテンツを、当該開始時刻で蓄積予約の開始を制御し、この開始時刻で蓄積予約した蓄積コンテンツの蓄積を、ヘッダ情報とコンテンツタイプ情報の組み合わせに応じて、カルーセル方式のデータブロック単位で実行するように構成される。

また、包括的には、受信装置２において、ヘッダ情報とコンテンツタイプ情報の組み合わせから、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた蓄積制御を実行するように構成することができる。

また、包括的には、受信装置２において、番組スケジュールテーブルは、シリーズ番組のコンテンツ情報を識別するための「シリーズ記述子」を含み、イベント識別子は、前記カルーセル方式のヘッダ情報であるＤＩＩにて、ダウンロードＩＤに関連付けて付加されており、ダウンロードＩＤは、前記イベント識別子の「枝番」と、「データイベント識別子」とを含み、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のそれぞれのコンテンツタイプにおける蓄積方法が、イベント識別子を基準にして、番組スケジュールテーブルに定義されたコンテンツタイプ情報及び「シリーズ記述子」と、ヘッダ情報であるＤＩＩにて伝送される「枝番」及び「データイベント識別子」によって送信側で定義されており、イベント識別子を基準にして、コンテンツタイプ情報及び「シリーズ記述子」と、ヘッダ情報であるＤＩＩにて伝送される「枝番」及び「データイベント識別子」によってコンテンツタイプに応じた蓄積制御を判別して実行するように構成することができる。

また、包括的には、受信装置２において、ヘッダ情報は、複数項目コンテンツのジャンル情報を含み、複数項目コンテンツの蓄積について、ジャンル情報別の蓄積コンテンツとして蓄積制御を実行することや、複数項目コンテンツの蓄積について、コンテンツ数の情報に基づいて蓄積制御を実行するように構成される。

また、包括的には、受信装置２において、番組スケジュールテーブルは、再送コンテンツのバージョンが変更される旨を表す更新情報記述子もしくは識別子を含み、更新情報記述子で指定される再送コンテンツのバージョン情報を前記ヘッダ情報から取得して、再送コンテンツの蓄積を実行するように構成される。

また、包括的には、受信装置２において、ヘッダ情報は、蓄積コンテンツごとの緯度・経度情報を含み、蓄積コンテンツごとの蓄積を実行する際に、ヘッダ情報から緯度・経度情報を抽出し、該緯度・経度情報に対応する蓄積コンテンツの蓄積を実行するように構成される。

また、包括的には、受信装置２において、番組スケジュールテーブルは、蓄積コンテンツごとの放送時刻の情報を含み、蓄積コンテンツの蓄積を実行する前に、事前に、前記番組スケジュールテーブルにおける現在と次に放送される蓄積コンテンツに関する部分のみをそれぞれ構成したテーブルＣＳＴ［ｐ］とＣＳＴ［ｆ］を取得して、蓄積すべき蓄積コンテンツの変更の有無を判別するように構成される。

また、包括的には、受信装置２において、番組スケジュールテーブルは、蓄積コンテンツごとの放送時刻の情報を含み、蓄積コンテンツの蓄積を実行する前に、事前に、前記番組スケジュールテーブルにおける現在と次に放送される蓄積コンテンツの１回分又は２回分の放送時刻に関する部分のみをそれぞれ構成したテーブルＣＳＴ［ｐ］とＣＳＴ［ｆ］を取得して、蓄積すべき蓄積コンテンツの変更の有無を判別するように構成される。

更に、本発明の一態様として、コンテンツ蓄積予約制御部をコンピュータとして構成させることができる。コンピュータに、前述したコンテンツ蓄積予約制御部を実現させるためのプログラムは、コンピュータの内部又は外部に備えられる記憶部（メモリ）に記憶される。そのような記憶部は、外付けハードディスクなどの外部記憶装置、或いはＲＯＭ又はＲＡＭなどの内部記憶装置で実現することができる。コンピュータに備えられる制御部は、中央演算処理装置（ＣＰＵ）などの制御で実現することができる。即ち、ＣＰＵが、各構成要素の機能を実現するための処理内容が記述されたプログラムを、適宜、記憶部から読み込んで、各構成要素の機能をコンピュータ上で実現させることができる。ここで、各構成要素の機能をハードウェアの一部で実現してもよい。

また、この処理内容を記述したプログラムを、例えばＤＶＤ又はＣＤ−ＲＯＭなどの可搬型記録媒体の販売、譲渡、貸与等により流通させることができるほか、そのようなプログラムを、例えばネットワーク上にあるサーバの記憶部に記憶しておき、ネットワークを介してサーバから他のコンピュータにそのプログラムを転送することにより、流通させることができる。

また、そのようなプログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラム又はサーバから転送されたプログラムを、一旦、自己の記憶部に記憶することができる。また、このプログラムの別の実施態様として、コンピュータが可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することとしてもよく、更に、このコンピュータにサーバからプログラムが転送される度に、逐次、受け取ったプログラムに従った処理を実行することとしてもよい。

本発明によれば、受信装置側では受信状況が不安定な環境（例えば、地下鉄乗車時にあるときなど）にある場合においても、再度の蓄積動作を自動的に行う仕組みが提供されるため、安定した蓄積コンテンツの蓄積を実現することができるため、特に、番組表で蓄積予約するデジタル放送の蓄積コンテンツを得る用途に有用である。

１ 放送局側送信装置
２ 受信装置
１０ コンテンツ編成部
１１ カルーセル処理部
１２ ＰＳＩ／ＳＩ生成符号化部
１３ 多重化部
１４ ＯＦＤＭ変調部
１５ 送信部
２０ ＯＦＤＭ復調部
２１ ＴＳ復号部
２２ 映像復号部
２３ 音声復号部
２４ 字幕・字幕スーパー復号部
２５ カルーセル復号部
２６ ＢＭＬブラウザ
２７ 出力処理Ｉ／Ｆ部
２８ ＳＩ処理部
２９ コンテンツ蓄積予約制御部
３０ 記憶部
３１ 蓄積コンテンツ一覧表示・再生指示部
３２ 蓄積コンテンツ管理表表示・再生指示部
３３ ユーザＩ／Ｆ部
３４ 蓄積コンテンツ再生制御部
１０１ コンテンツ生成部
１０２ 制御データ生成部
１０３ ＥＩＴ生成部
１０２１ 識別子付番制御部
１０２２ 伝送回数・周期管理部
１０３１ ファイル伝送記述子生成部
２９０１ スケジュール情報取得部
２９０２ 時刻情報処理部
２９０３ ＣＳＴ／ＥＩＴ情報管理部
２９０４ 蓄積予約制御部
２９０５ 対応ファイル判定部
２９０６ イベント識別子判定処理部
２９０６ａ 上書き蓄積判定部
２９０７ 差分ＤＤＢ判定処理部
２９０８ ダウンロードＩＤ判定処理部
２９０９ 蓄積予約管理表生成部
２９１０ 蓄積コンテンツ管理表生成部

Claims (11)

1. デジタル放送の放送波でコンテンツファイルを送信する際に、該コンテンツファイルを受信側で蓄積予約させるのに必要とされる番組スケジュールテーブルを送信する送信装置であって、
   各コンテンツファイルを放送するサービスを一意に指定するサービスＩＤと、開始時刻、放送持続時間、及びコンテンツファイルを一意に表すイベント識別子と、コンテンツタイプを表すコンテンツタイプ情報とを含む、番組スケジュールテーブルを生成する番組スケジュールテーブル生成手段と、
   前記番組スケジュールテーブルを所定間隔で送信する番組スケジュールテーブル送信手段と、
   前記番組スケジュールテーブル内で関連付けたイベント識別子を有するコンテンツファイルをデータブロックにてカルーセル方式で送信するコンテンツファイル送信手段とを備え、
   前記イベント識別子は、デジタル放送で放送するデータブロックのヘッダ情報にも記述されており、
   前記コンテンツファイル送信手段は、受信側でコンテンツタイプに応じた蓄積動作を行うよう、前記ヘッダ情報と、前記コンテンツタイプ情報の組み合わせを制御して当該コンテンツファイルを送信する手段を有することを特徴とする送信装置。
2. 前記番組スケジュールテーブルは、ＥＩＴにファイル伝送記述子を追加して構成されていることを特徴とする、請求項１に記載の送信装置。
3. 前記番組スケジュールテーブルは、前記カルーセル方式の繰返し回数ごとに各蓄積コンテンツの放送時刻の情報を含むことを特徴とする、請求項１に記載の送信装置。
4. 受信側が「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた差し替えを含む蓄積動作を行うよう、前記ヘッダ情報と、前記コンテンツタイプ情報の組み合わせを制御して当該コンテンツファイルを送信する手段を有することを特徴とする、請求項１〜３のいずれか一項に記載の送信装置。
5. 前記番組スケジュールテーブル生成手段は、シリーズ番組のコンテンツ情報を識別するための「シリーズ記述子」を含めて生成する手段を有し、前記イベント識別子は、前記カルーセル方式のヘッダ情報であるＤＩＩにて、ダウンロードＩＤに関連付けて付加されており、前記ダウンロードＩＤは、前記イベント識別子の「枝番」と、「データイベント識別子」とを含み、前記「単発コンテンツ」、前記「シリーズコンテンツ」、前記「上書き更新コンテンツ」、前記「複数項目コンテンツ」のそれぞれのコンテンツタイプにおける差し替えを含む蓄積方法を、前記イベント識別子を基準にして、前記番組スケジュールテーブルに定義された前記コンテンツタイプ情報及び前記「シリーズ記述子」と、前記ヘッダ情報であるＤＩＩにて伝送される前記「枝番」及び前記「データイベント識別子」によって定義して、受信側が「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた差し替えを含む蓄積動作を行うよう、前記ヘッダ情報と、前記コンテンツタイプ情報の組み合わせを制御して当該コンテンツファイルを送信する手段を有することを特徴とする、請求項４に記載の送信装置。
6. 前記ヘッダ情報は、複数項目コンテンツのジャンル情報を含み、受信側で前記複数項目コンテンツの蓄積について、ジャンル情報別のコンテンツとして蓄積制御を実行できるようにしたことを特徴とする、請求項１〜５のいずれか一項に記載の送信装置。
7. 前記ヘッダ情報は、複数項目コンテンツを構成するコンテンツ数の情報を含み、受信側で前記複数項目コンテンツの蓄積について、前記コンテンツ数の情報に基づいて蓄積制御を実行できるようにしたことを特徴とする、請求項１〜６のいずれか一項に記載の送信装置。
8. 前記番組スケジュールテーブル生成手段は、再送コンテンツのバージョンが変更される旨を表す更新情報記述子を含めて生成する手段を有し、受信側で、前記更新情報記述子で指定される再送コンテンツのバージョン情報を前記ヘッダ情報から取得して、前記再送コンテンツの蓄積を実行できるようにしたことを特徴とする、請求項１〜７のいずれか一項に記載の送信装置。
9. 前記ヘッダ情報に、蓄積コンテンツごとの緯度・経度情報を設定する手段を有し、受信側でコンテンツごとの蓄積を実行する際に、前記ヘッダ情報から緯度・経度情報を抽出し、該緯度・経度情報に対応するコンテンツの蓄積を実行できるようにしたことを特徴とする、請求項１〜８のいずれか一項に記載の送信装置。
10. 前記番組スケジュールテーブル生成手段は、コンテンツごとの放送時刻の情報を含めて生成する手段を有し、受信側でコンテンツの蓄積を実行する前に、事前に、前記番組スケジュールテーブルにおける現在と次に放送されるコンテンツに関する部分のみをそれぞれ構成したテーブルＣＳＴ［ｐ］とＣＳＴ［ｆ］を取得して、蓄積すべきコンテンツの変更の有無を判別できるようにしたことを特徴とする、請求項１〜９のいずれか一項に記載の送信装置。
11. 前記番組スケジュールテーブル生成手段は、コンテンツごとの放送時刻の情報を含めて生成する手段を有し、受信側でコンテンツの蓄積を実行する前に、事前に、前記番組スケジュールテーブルにおける現在と次に放送されるコンテンツの１回分又は２回分の放送時刻に関する部分のみをそれぞれ構成したテーブルＣＳＴ［ｐ］とＣＳＴ［ｆ］を取得して、蓄積すべきコンテンツの変更の有無を判別できるようにしたことを特徴とする、請求項１〜１０のいずれか一項に記載の送信装置。
    

Images