JP5622475B2 - 放送サービスの送信装置、受信装置及びそのプログラム - Google Patents

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で３つのコンテンツを伝送するにあたり、第１カルーセルで「ニュース項目１」を伝送し、第２カルーセルで「ニュース項目２」を伝送し、第３カルーセルで「ニュース項目３」を伝送し、第４カルーセルで「ニュース項目１」を伝送し、第５カルーセルで「ニュース項目２」を伝送することができる。「複数項目コンテンツ」は、例えばＣＳＴに記載された放送時間内で、それぞれ別のカルーセルで伝送される。

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

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

本発明によれば、繰り返し放送されるコンテンツを常時監視しなくてもよくなり、特に、従来の技術では、同一のサービスＩＤでも複数の項目からなる複数項目コンテンツについては各項目コンテンツを別々のカルーセルで伝送していたため、送信装置側では、伝送するカルーセルを１周以上冗長して伝送する必要性もなくなり、受信装置側でも受信処理の切り替えの必要性をなくすことで、移動受信環境下で、受信装置の消費電力を抑えて、放送波のダウンロードが実現できる。

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

これにより、送信装置側では、複数項目コンテンツのコンテンツファイルについては、伝送するカルーセルを１周以上冗長して伝送する必要性がなくなる。

また、本発明に係る送信装置において、前記コンテンツファイル送信手段は、前記コンテンツタイプ情報として複数項目コンテンツのコンテンツファイルを送信する際に、前記蓄積型リソースリストに対して、前記複数項目コンテンツのジャンル情報を記述して送信する手段をさらに有することを特徴とする。

これにより、受信装置側では、複数項目コンテンツのコンテンツファイルのジャンルを把握できるようになる。

本発明に係る受信装置は、デジタル放送の放送波でコンテンツファイルを受信する際に、該複数のコンテンツを受信側で蓄積予約させるのに必要とされる番組スケジュールテーブルを受信する受信装置であって、前記番組スケジュールテーブルは、各コンテンツファイルを放送するサービスを一意に指定するサービスＩＤと、開始時刻、放送持続時間、及びコンテンツファイルを一意に表すイベント識別子と、コンテンツタイプを表すコンテンツタイプ情報とを含み、前記イベント識別子は、デジタル放送で放送されるデータブロックのヘッダ情報に記述されており、前記番組スケジュールテーブルを受信して、前記イベント識別子によって識別されるコンテンツファイルを蓄積予約するための蓄積予約管理表を、コンテンツタイプ情報を付加して生成する蓄積予約管理表生成手段と、前記蓄積予約管理表で蓄積予約するべく規定されたコンテンツを、前記開始時刻で蓄積予約の開始を制御するコンテンツ蓄積予約制御手段と、前記開始時刻で蓄積予約したコンテンツの蓄積を、前記ヘッダ情報と前記コンテンツタイプ情報の組み合わせに応じて、カルーセル方式のデータブロック単位で実行するコンテンツ蓄積実行手段とを備え、前記コンテンツ蓄積実行手段は、前記ヘッダ情報と前記コンテンツタイプ情報の組み合わせから、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた蓄積制御を実行する手段を有し、さらに、前記コンテンツタイプ情報として複数項目コンテンツのコンテンツファイルを蓄積制御する際に、前記ヘッダ情報に記述された前記コンテンツタイプ情報に関連付けられたイベント識別子を取得し、当該イベント識別子に関連付けられたデータブロックを全て取得し、取得したデータブロックから１つのモジュールを構築し、構築したモジュールに含まれる所定の蓄積型リソースリストから、当該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を抽出し、抽出した枝番とバージョンを示す情報に基づいて前記各項目のコンテンツの蓄積を実行する手段を有することを特徴とする。

これにより、受信装置側では、複数項目コンテンツのコンテンツファイルの蓄積において、受信処理の切り替えの必要性がなくなり、さらに、放送時間内でのカルーセル数も意識する必要がなくなり、そのうえで、枝番とバージョン情報から、重複保存の回避や複数項目コンテンツにおける各項目のコンテンツの上書き・更新を制御することができる。

また、本発明に係る受信装置において、前記コンテンツ蓄積実行手段は、前記蓄積型リソースリストから、前記複数項目コンテンツのジャンル情報を抽出してコンテンツファイルのジャンルを決定する手段をさらに有することを特徴とする。

これにより、受信装置側では、ジャンル別に、複数項目コンテンツのコンテンツファイルの蓄積が可能となる。

また、本発明に係るプログラムは、デジタル放送の放送波でコンテンツファイルを受信する際に、該複数のコンテンツを受信側で蓄積予約させるのに必要とされる番組スケジュールテーブルを受信する受信装置にて、前記番組スケジュールテーブルは、各コンテンツファイルを放送するサービスを一意に指定するサービスＩＤと、開始時刻、放送持続時間、及びコンテンツファイルを一意に表すイベント識別子と、コンテンツタイプを表すコンテンツタイプ情報とを含み、前記イベント識別子は、デジタル放送で放送されるデータブロックのヘッダ情報に記述されており、前記受信装置における蓄積制御部を構成するコンピュータに前記番組スケジュールテーブルを受信して、前記イベント識別子によって識別されるコンテンツファイルを蓄積予約するための蓄積予約管理表を、コンテンツタイプ情報を付加して生成するステップと、前記蓄積予約管理表で蓄積予約するべく規定されたコンテンツを、前記開始時刻で蓄積予約の開始を制御するステップと、前記開始時刻で蓄積予約したコンテンツの蓄積を、前記ヘッダ情報と前記コンテンツタイプ情報の組み合わせに応じて、カルーセル方式のデータブロック単位で実行するステップと、を実行させるためのプログラムであり、前記コンテンツの蓄積を行うステップは、前記ヘッダ情報と前記コンテンツタイプ情報の組み合わせから、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた蓄積制御を実行するステップを含み、さらに、前記コンテンツタイプ情報として複数項目コンテンツのコンテンツファイルを蓄積制御する際に、前記ヘッダ情報に記述された前記コンテンツタイプ情報に関連付けられたイベント識別子を取得し、当該イベント識別子に関連付けられたデータブロックを全て取得し、取得したデータブロックから１つのモジュールを構築し、構築したモジュールに含まれる所定の蓄積型リソースリストから、当該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を抽出し、抽出した枝番とバージョンを示す情報に基づいて前記各項目のコンテンツの蓄積を実行するステップを含むことを特徴とする。

本発明によれば、送信装置は、受信装置側で拡張ＥＩＴ又はＣＳＴにて識別できる任意ファイルのダウンロード放送が可能となり、受信装置は、ダウンロード予約機能の実現や、受信装置が効率的に電力を最小限にして、拡張ＥＩＴ又はＣＳＴにて識別した任意ファイルのみを受信することが可能となり、さらに、コンテンツタイプに応じた蓄積動作を行うことが可能となり、特に、送信装置側では、伝送するカルーセルを１周以上冗長して伝送する必要性もなくなり、受信装置側でも受信処理の切り替えの必要性をなくすことができるようになる。

本発明による一実施例の放送システムの概略構成図である。 （ａ），（ｂ）は、従来技術と、その課題、及び本発明に係る動作の概念図である。 本発明に係る拡張ＥＩＴの概略図である。 本発明に係るＣＳＴの概略図である。 本発明に係るＣＳＴと拡張ＥＩＴを併用する例を示す図である。 （ａ），（ｂ）は、ＡＲＩＢ ＳＴＤ−Ｂ２４第二編で定義されている「蓄積型リソースリスト」（storedFileInfo()）に新たに追加されるマルチパート化ファイル情報（multipart_file_info）の例示する図である。 本発明による一実施例の放送局側送信装置の概略図である。 本発明に係る一実施例の受信装置の概略図である。 本発明による一実施例の放送システムの動作説明図である。 カルーセル方式による伝送例を示す図である。 （ａ），（ｂ）は、発明による一実施例の放送システムにて、複数項目コンテンツを順次配信する態様を例示する図である。 本発明に係る一実施例の受信装置におけるコンテンツ蓄積予約制御部の概略図である。 本発明に係る一実施例の受信装置におけるコンテンツ蓄積予約制御部の動作フロー図である。 本発明に係る一実施例の受信装置における蓄積予約管理表の例を示す図である。 本発明に係る一実施例の受信装置における蓄積コンテンツ管理表の例を示す図である。 本発明に係る一実施例の受信装置における複数項目コンテンツの蓄積動作例を示す図である。

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

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

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

まず、従来の技術では、コンテンツタイプに分けることなくダウンロードコンテンツを配信していたために、送信側及び受信側での処理負担が大きかった。特に、同一のサービスＩＤでも複数の項目からなるコンテンツについては、各項目コンテンツを別々のカルーセルで伝送していた。この場合、カルーセルの切り替え時に、受信装置２側では受信処理の切り替えを行うことになり、この切り替え時の取りこぼしを考慮して、送信装置１側では、伝送するカルーセルを１周以上冗長して伝送する必要が生じていた。そこで、本発明では、詳細に後述するように、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた蓄積制御を可能とする伝送システムを構成し、「複数項目コンテンツ」のコンテンツタイプについては、より効率的なダウンロード配信を実現する。

本発明の理解を助けるために、従来技術と、その課題、及び本発明に係る動作の概念図を図２に示す。図２（ａ）は、番組スケジュールを構成するＥＰＧやＥＣＧで、例えば番組「いつでもニュース」、「気象情報」及び「いつでもニュース」を順次配信する態様を例示している。「いつでもニュース」は、複数項目コンテンツを構成しており、「ニュースＡ」、「ニュースＢ」、「ニュースＣ」及び「ニュースＤ」の項目のコンテンツファイルを含んでいる。この場合、図２（ｂ）に示すように、従来技術では、送信装置側では、伝送するカルーセルを１周以上冗長して（例えば、１．５カルーセル）、伝送する必要が生じていた。これは、放送コンテンツであるがゆえに、受信装置側で番組コンテンツの取りこぼしを予想しているためであり、結果として放送時間が長くなり非効率的であった。

そこで、本発明の方式では、「ニュースＡ」、「ニュースＢ」、「ニュースＣ」及び「ニュースＤ」の項目のコンテンツファイルをマルチパート化して一つの「複数項目コンテンツ」として伝送する。この場合、受信装置２側の取りこぼし対策として、送信装置１は、コンテンツタイプ情報として複数項目コンテンツのコンテンツファイルを送信する際に、コンテンツタイプ情報に関連付けられたイベント識別子をヘッダ情報（ＤＩＩ）に記述し、該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を所定の蓄積型リソースリストに記述して、該蓄積型リソースリストの情報と各項目のコンテンツをマルチパート化したデータブロックで送信するように構成する。これにより、受信装置２は、コンテンツタイプ情報として複数項目コンテンツのコンテンツファイルを蓄積制御する際に、ヘッダ情報に記述されたコンテンツタイプ情報に関連付けられたイベント識別子を取得し、当該イベント識別子に関連付けられたデータブロックを全て取得して一時蓄積し、取得したデータブロックから１つのモジュールを構築し、構築したモジュールに含まれる所定の蓄積型リソースリストから、当該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を抽出し、抽出した枝番とバージョンを示す情報に基づいて保存すべき各項目のコンテンツの蓄積を実行する。

以下、本発明に係る任意ファイルをダウンロード配信・受信する放送サービスの放送システムの一実施例について説明する。

［拡張ＥＩＴ］
「拡張ＥＩＴ」は、図３に示すように、既存のＥＩＴ内に新規の記述子である「ファイル伝送識別子」とコンテンツタイプを表す「コンテンツタイプ情報（content_type）」を追加して「拡張ＥＩＴ」を構成したものである。
詳細は後述するが、「ファイル伝送識別子(file_delivery_descriptor)」は、受信装置２側でコンテンツファイルの内容を識別させるための「ファイル種別情報（file_type_value）」を含み、必要に応じて、標準化機関が設定する当該ファイル伝送識別子を利用する機関を特定するための「記述子タグ情報（descriptor_tag）」と、当該ファイル伝送識別子の長さを表す「識別子長（descriptor_length）」と、コンテンツファイルに対して予め規定した暗号化が施されているか否かを識別するための「暗号化フラグ(encryption_flag)」と、上記以外の任意の情報を記述するための「リザーブ（reserved_future_use）」と、標準化機関が設定する当該ファイル伝送識別子で関連付けるコンテンツファイルのデータ構成（データコンポーネント）を識別するための「データコンポーネント識別子（data_component_id）」とを含む。尚、既存ＥＩＴに新規に追加する「ファイル伝送識別子(file_delivery_descriptor)」は、ＰＭＴにも追加記載することも望ましく、この場合にはコンテンツとの関連付けを再確認できるようになる。尚、「ファイル種別情報（file_type_value）」は、標準化機関に順ずる機関、もしくは、運用するプラットフォーム会社等が管理を行い、放送事業者、メーカー等に開示を行うのが好適である。これにより、受信装置２は実際に任意ファイルを受信する前に、配信されるファイルの内容を把握可能であり、受信の可否の判断が可能となる。

［コンテンツスケジュールテーブル（ＣＳＴ）］
「ＣＳＴ」は、図４（ａ）に示すように、ＣＳＴの種別を表す「テーブル識別子」と、ＣＳＴの伝送識別情報（セクション情報）を表す「伝送識別情報」と、コンテンツごとに割り当てられた固有の識別子を表す「イベント識別子（event_id）」と、コンテンツファイルの内容を識別させるための「ファイル種別情報（file_type_value）」と、コンテンツタイプを表す「コンテンツタイプ情報（content_type_value1, content_type_value2, content_type_value3）」と、放送するコンテンツファイルの変更の有無を確認可能にする「ファイルバージョン番号（file_version_number）」（これは、ファイル伝送識別子(file_delivery_descriptor)を伝送する場合、省略することもできる）と、放送回数を示す「broadcast_count(8bits)」と、各コンテンツの放送の開始時刻、放送持続時間、及び放送回数を表す「放送時刻識別情報」と、各コンテンツの記述内容を表す「各種記述子」からなる。また、コンテンツスケジュールテーブル（ＣＳＴ）は、１つのＣＳＴに含まれる複数のコンテンツについて、所定回数の「放送時間の情報」とＥＩＴで運用されるものと同一の各種記述子である、コンテンツのコピーを制限する制御する旨を表す「デジタル制御記述子」、コンテンツのタイトルを表す「短形イベント記述子」、番組内容を表す「コンテント記述子」、ジャンル及びシリーズ番組である旨を表す「シリーズ記述子」を記述している。尚、コンテンツタイプ情報（content_type）は、図４（ａ）に示す「コンテンツ情報」内の記述子とすることができる。また、「伝送識別情報」は、各サービス態様で随意決定することができ、その一例を以下に示す。

「ＣＳＴ［ｐ／ｆ］」は、図４（ｂ）に示すように、ＥＩＴ［ｐ／ｆ］の代わりに用いるものであり、ＣＳＴの記述内容に対して現在及び次に放送されるコンテンツの１回分の放送の開始時刻及び放送持続時間を伝送するように構成される。ただし、コンテンツファイルの内容を識別させるためのファイル伝送識別子(file_delivery_descriptor)を各種記述子の記述欄に追加して伝送することができ、この場合、「ファイルバージョン番号（file_version_number）」の記述を省略することができる。

つまり、「ＣＳＴ［ｐ／ｆ］」は、図４（ｃ）に示すように、受信装置２側では、コンテンツファイルの更新や差し替えの発生の有無を、「ＣＳＴ［ｐ／ｆ］」内の「ファイルバージョン番号（file_version_number）」で確認するか、又は、ファイル伝送識別子(file_delivery_descriptor)の内容から確認することができる。

「ファイル種別情報（file_type_value）」や、「コンテンツタイプ情報（content_type_value1, content_type_value2, content_type_value3）」は、コンテンツの種別等を表す値として用いられ、例えば、以下のように利用することができる。

（ファイル、コンテンツの種別とfile_type_value、content_type_value）
ダウンロードサービスで使用するコンテンツは、一般的なコンテンツ以外に、項目が更新されるコンテンツ（ニュースなど）や、常時更新のコンテンツ（交通情報など）があり、また、これらのコンテンツの内容を補足する情報も存在させるのが好適である。これらのファイルやコンテンツの種類を識別する値がfile_type_value、content_type_valueである。file_type_valueは16bitの値で、例えば公的機関で管理され放送事業者やメーカー等に開示されるものとすることができ、本例では、content_type_valueとして３種類とし、拡張ＥＩＴやＣＳＴで伝送するように構成する。

例えば、ファイル種別（file_type_value）、コンテンツ種別（content_type_value1）,
コンテンツ種別(content_type_value2)、及び、コンテンツの本編・補足種別（content_type_value3）のビット割当と識別項目、及び識別内容の例を表１〜表５に示す。

尚、「ファイルバージョン番号（file_version_number）」は、同じevent_idのコンテンツで内容の変更の有無を通知する。拡張ＥＩＴ［ｐ／ｆ］やＣＳＴ［ｐ／ｆ］の受信処理を軽くしたい場合に、ファイル伝送識別子(file_delivery_descriptor)を記述せずとも、この「ファイルバージョン番号（file_version_number）」の値を参照するのみで、カルーセル受信の有無を判断することができ、拡張ＥＩＴやＣＳＴに記載することで、一般番組で変更があったことを知ることも可能となる。尚、上書き更新コンテンツについても、「ファイルバージョン番号（file_version_number）」が前回と異なっている場合は、カルーセルを受信し、上書き更新するのに有利な情報となる。

一方、ファイル伝送識別子(file_delivery_descriptor)は、複数項目コンテンツにおける各項目のコンテンツファイルの識別のために、拡張ＥＩＴ［ｐ／ｆ］やＣＳＴ［ｐ／ｆ］に挿入することができ、ｐ／ｆ情報の取得の時点で、複数項目コンテンツにおける各項目のコンテンツの更新差替情報、項目数を把握することができるようになる。ファイル伝送識別子(file_delivery_descriptor)には、複数項目コンテンツにおける各項目のコンテンツについて項目毎のジャンル情報を記述しておくことで、受信装置２は、所望のジャンル情報のみについて蓄積制御すればよくなる。

受信装置２側では、ＣＳＴ［ｐ／ｆ］によって、コンテンツファイルの更新や差し替えの発生の有無を確認した場合、カルーセルのＤＩＩに記述されるファイル情報記述子（file_info_descriptor）から、ファイル情報記述子である旨を示す「記述子タグ(descriptor_tag)」及び「記述子長（descriptor_length）」を参照して確認し、ブランチカウント情報（branch_count）で複数項目コンテンツに含まれる項目コンテンツファイルの数を確認し、各項目コンテンツファイルのジャンル情報（例えば、content_nibble_level1, content_nibble_level2）を把握することができる。

「ＣＳＴ［ｐ／ｆ］」内に、ファイル伝送識別子(file_delivery_descriptor)が記述される場合、当該イベント識別子（event_id）のコンテンツファイルの枝番（ex_event_id）とデータイベント識別子（data_event_id）から、複数項目コンテンツの各項目のコンテンツファイルとそのバージョン情報を基に、コンテンツファイルの更新や差し替えの発生の有無を把握することができる。

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

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

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

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

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

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

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

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

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

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

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

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

「event_id_length(8 bits)」は、コンテンツごとに割り当てられた固有の識別子（event_id）の長さを表す。

「event_id (16bits)」は、コンテンツごとに割り当てられた固有の識別子を表す。

「broadcast_count(8bits)」は、コンテンツの放送回数を表す。

「component_tag(8bits)」は、event_idごとの多重伝送するデータ列を表すタグ情報である。サービス内で一つのデータ列しか使用しない運用においては、component_tagを省略することも可能である。

「start_time(40bits)」は、event_idごとのコンテンツの放送開始時刻を表す。

「duration(24bits)」は、event_idごとのコンテンツの持続時間を表す。

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

［ＣＳＴと拡張ＥＩＴの併用］
図５は、ＣＳＴと拡張ＥＩＴを併用した例を示す。本例は、番組スケジュールにＣＳＴを用い、コンテンツの蓄積直前に取得するテーブルには、拡張ＥＩＴ［ｐ／ｆ］を用いる例である。図５（ａ）に示すＣＳＴは、図４（ａ）に示すものと同様である。図５（ｂ）に示す拡張ＥＩＴ［ｐ／ｆ］は、既存のＥＩＴに、図５（ｂ）に示すように「ファイル伝送識別子(file_delivery_descriptor)」が追加されたものである。図５に示すように構成しても、「ＣＳＴ［ｐ／ｆ］」内に、ファイル伝送識別子(file_delivery_descriptor)が記述される場合、当該イベント識別子（event_id）のコンテンツファイルの枝番（ex_event_id）とデータイベント識別子（data_event_id）から、複数項目コンテンツの各項目のコンテンツファイルとそのバージョン情報を基に、コンテンツファイルの更新や差し替えの発生の有無を把握することができる。

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

図６（ａ），（ｂ）は、ＡＲＩＢ ＳＴＤ−Ｂ２４第二編で定義されている「蓄積型リソースリスト」（storedFileInfo()）に新たに追加されるマルチパート化ファイル情報（multipart_file_info）の例である。図６（ａ）は、マルチパート化ファイル情報（multipart_file_info）として、当該マルチパート化ファイル情報の記述子タグ情報（descriptor_tag）と、マルチパート化ファイル情報の長さを表す記述子長情報（descriptor_length）と、ＤＩＩに記述されるevent_idの枝番を示すイベント識別子（ex_event_id）と、複数項目コンテンツにおける各項目のコンテンツファイルのバージョンを示すバージョン情報（data_event_id）と、必要に応じて記述される複数項目コンテンツのジャンル情報（genru_id）を含む。図６（ｂ）は、マルチパート化ファイル情報（multipart_file_info）として、当該マルチパート化ファイル情報のタグ情報（descriptor_tag）と、マルチパート化ファイル情報の長さを表す記述子長情報（descriptor_length）と、ＤＩＩに記述されるevent_idの枝番を示す識別子（ex_event_id）と、複数項目コンテンツにおける各項目のコンテンツファイルのバージョンを示すバージョン情報（data_event_id）と、必要に応じてコンテンツニブルレベル１（Content_nibble_level1）とコンテンツニブルレベル２（content_nibble_level2）を含む。コンテンツニブルレベル１（Content_nibble_level1）とコンテンツニブルレベル２（content_nibble_level2）はそれぞれ大分類、中分類のジャンル情報であり、組み合わせて各項目コンテンツのジャンルを指定する。

ここで、リアルタイムサービスのコンテンツについて詳述する。本発明では、リアルタイムサービスにおいて番組の識別は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の値を例えば１２ｂｉｔとし、異なる項目の指定は最大4096種類（正確には0xFFFを除き4095種類）とすることができる。

また、ダウンロードサービスでは、同じ内容のコンテンツが複数回送信され、受信装置２側で欠損データの補完として利用することが可能であるが、２回目以降の送信において内容を一部変更するなど、バージョンの異なるコンテンツが送信されるケースが想定される。この場合、バージョンの変更を受信側に知らされない状態で欠損データの補完を行うと、変更部分の映像や音声などのデータが不連続となり、コンテンツの視聴に支障をきたすことになる。そこで、バージョンの異なるコンテンツを送る場合、異なる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を使用しないでもよい。

ダウンロードサービスでは、あらかじめ指定された時間に送信が行われ、コンテンツが受信機に自動的に蓄積されるケースが一般的であるが、交通情報のように常時送信が行われ、最新の情報が受信機で常時提示されるサービスも想定される。このような常時更新コンテンツの場合、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が使用されないものとすることができる。

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

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

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

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

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

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

制御データ生成部１０２は、コンテンツ符号化部１０１を経て伝送するコンテンツを、カルーセル処理部１１によってカルーセル方式で伝送する際に、ＤＩＩメッセージ内のダウンロードＩＤ（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）を検出し、このＥＳ番号を読み取ることで、所望するデータの識別ができる。

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

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

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

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

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

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

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

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

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

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

これらのメインｃｈ１、独自ｃｈ１及び独自ｃｈ２のコンテンツは、ＥＩＴ番組情報（拡張ＥＩＴ又はＣＳＴ）から、チャンネル種別をそれぞれサービスＩＤ（serviceID）で識別することができるだけでなく時間軸方向の編成についてもイベント識別子（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）のみが更新されたコンテンツファイルの蓄積を行うときは、差し替えや上書き更新蓄積を行うことができる（ステップＳ１８）。また、上書き更新コンテンツで同じシリーズに属するコンテンツが、既に蓄積されている場合には上書き更新を行い、そうでない場合はそのまま蓄積する。

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

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

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

例えば、図１１（ａ）は、番組スケジュールを構成するＥＰＧやＥＣＧで、例えば番組「いつでもニュース」、「気象情報」及び「いつでもニュース」を順次配信する態様を例示している。拡張ＥＩＴ又はＣＳＴでは、「いつでもニュース」のコンテンツ情報である複数項目コンテンツを伝送する旨を示す番組スケジュールを伝送するため、受信装置２は、ＥＰＧやＥＣＧを構築することができる。本発明に係る送信装置１は、番組スケジュールテーブル（拡張ＥＩＴ又はＣＳＴ）を送信するとともに、拡張ＥＩＴ又はＣＳＴ[ｐ／ｆ]を送信することができる。また、本発明に係る送信装置１は、複数項目コンテンツの配信の場合には、図１１（ｂ）に示すように、ヘッダ部を構成するヘッダ情報（ＤＩＩ）内のダウンロードＩＤに記述したイベント識別子の枝番（ex_event_id）とバージョン情報（data_event_id）とを、「蓄積型リソースリスト」にも記述して、蓄積型リソースリストの情報と複数項目コンテンツの各項目のコンテンツをマルチパート化したデータブロックで送信する。蓄積型リソースリストの情報と、マルチパート化された各項目のコンテンツ（「ニュースＡ」、「ニュースＢ」、「ニュースＣ」及び「ニュースＤ」）を一つのモジュールとして伝送する。つまり、１つのモジュールを複数のパートに分割して伝送するため、受信装置２側では、複数項目コンテンツの各項目のコンテンツを受信して蓄積する際に、まず、ＤＩＩからイベント識別子を把握し、当該イベント識別子に関連付けられたデータブロックを全て取得し、取得したデータブロックから１つのモジュールを構築し、構築したモジュールに含まれる所定の蓄積型リソースリストから、当該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を抽出し、抽出した枝番とバージョンを示す情報に基づいて前記各項目のコンテンツ（「ニュースＡ」、「ニュースＢ」、「ニュースＣ」及び「ニュースＤ」）の蓄積を実行する。尚、各リソースごとにリソースヘッダが設けられ、「蓄積型リソースリスト」内の記述子タグ情報（descriptor_tag）と対応付けた番号を記載する。受信装置２は、ジャンル情報、又は階層的なジャンル情報としてのコンテンツニブルレベル１（Content_nibble_level1）とコンテンツニブルレベル２（content_nibble_level2）を含む場合には、各項目コンテンツのジャンルを把握することができる。

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

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

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

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

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

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

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

イベント識別子判定処理部２９０６は、ＤＩＩ内のダウンロードＩＤにおけるイベント識別子（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）」でファイル種別を直ちに識別して、コンテンツの蓄積予約のための蓄積予約管理表を直ちに作成して、直ちにコンテンツ取得することもでき。このため、受信装置２の受信処理負担を軽減させ、且つ受信不良のリスクを軽減させると共に、受信不良で未取得のＤＤＢのみを取得してコンテンツファイルを受信完了させることが可能となる。

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

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

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

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

〔複数の項目があるシリーズコンテンツの送出及び蓄積〕
ＣＳＴ［ｐ／ｆ］の受信処理を単純化するために、ｆile_version_numberを用いる場合には、受信装置２は、以下の手順で蓄積動作が可能である。
（１）ＣＳＴ［ｐ／ｆ］のｆile_version_numberが前回と異なっている場合は、カルーセルを受信する。
（２）ＤＩＩを取得し、download_idから新規蓄積、差し替えを判断し、file_info_descriptorから、項目数を取得し、file_info_descriptorから項目コンテンツのジャンルを取得する。
（３）新規蓄積や差し替えがある場合は、DDBを受信し、すべて取得したらファイルとして保存する。
（４）項目数分、上記の（２），（３）を繰り返す。

ＣＳＴ［ｐ／ｆ］にて、ｆile_version_numberを用いずに、ファイル伝送識別子を用いる場合には、受信装置２は、以下の手順で蓄積動作が可能である。
（１）file_delivery_descriptorで、項目数と、各項目の枝番とdata_event_idを取得する。
（２）いずれかのコンテンツで新規蓄積や差し替えが発生する場合はカルーセルを受信し、ＤＩＩを取得し、downnload_idで蓄積や差し替え対象の項目コンテンツかどうかを判断し、file_info_descriptorから項目コンテンツのジャンルを取得する。
（３）対象の場合はＤＤＢを受信し、すべて取得したらファイルとして保存する。
（４）項目数分、上記の（２），（３）を繰り返す。

例えば、図１６の例では、受信装置２は、ＣＳＴ又は拡張ＥＩＴで「コンテンツタイプ情報（content_type）」が‘１’であり、event_id＝１のコンテンツＡ〜Ｈの蓄積予約をする。その際、シリーズ予約をする。シリーズ予約を選択すると、series_id＝１の全てのコンテンツが自動で予約される。受信装置２は、放送時刻の直前に、拡張ＥＩＴ又はＣＳＴ[ｐ／ｆ]を取得してevent_idを確認し、放送時刻になるとＤＩＩを取得し、event_id＝１であれば蓄積し、この時、event_id＝１の全てのＤＤＢを取得し、１モジュールを構築する。この１モジュールの構築で、「蓄積型リソースリスト」、各項目のコンテンツファイルである「コンテンツＡ」、「コンテンツＢ」、及び「コンテンツＣ」からなるＤＤＢを把握することができる（図１１参照）。

拡張ＥＩＴ又はＣＳＴ[ｐ／ｆ]の取得の結果、例えば送信装置側からの「コンテンツＣ」の差し替え要求を更新フラグで把握すると、放送時刻になるとＤＩＩを取得し、event_id＝１であれば全てのＤＤＢを一時蓄積し、この時、event_id＝１の全てのＤＤＢを取得し、１モジュールを構築する。「蓄積型リソースリスト」から、各項目の枝番とdata_event_idを取得することで、例えば、ダウンロードＩＤを識別して「コンテンツＣ’」の部分に対応するＤＤＢのみを蓄積する。続いて、「コンテンツＤ」、「コンテンツＥ」の取得に失敗していたとしても、所定回数は１モジュール単位で繰返し放送され、再度の蓄積を試みることができる。１モジュール単位で繰返し放送される全ての項目のコンテンツファイルの蓄積に終了すれば、放送時刻の直前における拡張ＥＩＴ又はＣＳＴ[ｐ／ｆ]の取得は不要である。また、拡張ＥＩＴ又はＣＳＴ[ｐ／ｆ]の変更がないときは、カルーセルの取得も不要である。ＣＳＴ又は拡張ＥＩＴの情報に従ってさらに別の「コンテンツＦ」、「コンテンツＧ」、「コンテンツＨ」の蓄積予約に伴い、放送時刻の直前に、拡張ＥＩＴ又はＣＳＴ[ｐ／ｆ]を取得して確認する場合も「コンテンツＡ」、「コンテンツＢ」、「コンテンツＣ」の蓄積と同様に動作させることができる。

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

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

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

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

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

Claims (5)

1. デジタル放送の放送波でコンテンツファイルを送信する際に、該コンテンツファイルを受信側で蓄積予約させるのに必要とされる番組スケジュールテーブルを送信する送信装置であって、
   各コンテンツファイルを放送するサービスを一意に指定するサービスＩＤと、開始時刻、放送持続時間、及びコンテンツファイルを一意に表すイベント識別子と、コンテンツタイプを表すコンテンツタイプ情報とを含む、番組スケジュールテーブルを生成する番組スケジュールテーブル生成手段と、
   前記番組スケジュールテーブルを所定間隔で送信する番組スケジュールテーブル送信手段と、
   前記番組スケジュールテーブル内で関連付けたイベント識別子を有するコンテンツファイルを、受信側でコンテンツタイプに応じた蓄積動作を行うよう、前記イベント識別子を有するヘッダ情報と、前記コンテンツタイプ情報の組み合わせを制御して、データブロックにてカルーセル方式で送信するコンテンツファイル送信手段とを備え、
   前記コンテンツファイル送信手段は、前記コンテンツタイプ情報に基づいて複数項目コンテンツのコンテンツファイルを送信する際には、該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を所定の蓄積型リソースリストに記述して、該蓄積型リソースリストの情報と前記各項目のコンテンツをマルチパート化したデータブロックで送信することを特徴とする送信装置。
2. 前記コンテンツファイル送信手段は、前記コンテンツタイプ情報として複数項目コンテンツのコンテンツファイルを送信する際に、前記蓄積型リソースリストに対して、前記複数項目コンテンツのジャンル情報を記述して送信する手段をさらに有することを特徴とする、請求項１に記載の送信装置。
3. デジタル放送の放送波でコンテンツファイルを受信する際に、該複数のコンテンツを受信側で蓄積予約させるのに必要とされる番組スケジュールテーブルを受信する受信装置であって、
   前記番組スケジュールテーブルは、各コンテンツファイルを放送するサービスを一意に指定するサービスＩＤと、開始時刻、放送持続時間、及びコンテンツファイルを一意に表すイベント識別子と、コンテンツタイプを表すコンテンツタイプ情報とを含み、前記イベント識別子は、デジタル放送で放送されるデータブロックのヘッダ情報に記述されており、
   前記番組スケジュールテーブルを受信して、前記イベント識別子によって識別されるコンテンツファイルを蓄積予約するための蓄積予約管理表を、コンテンツタイプ情報を付加して生成する蓄積予約管理表生成手段と、
   前記蓄積予約管理表で蓄積予約するべく規定されたコンテンツを、前記開始時刻で蓄積予約の開始を制御するコンテンツ蓄積予約制御手段と、
   前記開始時刻で蓄積予約したコンテンツの蓄積を、前記ヘッダ情報と前記コンテンツタイプ情報の組み合わせに応じて、カルーセル方式のデータブロック単位で実行するコンテンツ蓄積実行手段とを備え、
   前記コンテンツ蓄積実行手段は、前記ヘッダ情報と前記コンテンツタイプ情報の組み合わせから、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた蓄積制御を実行する手段を有し、さらに、前記コンテンツタイプ情報として複数項目コンテンツのコンテンツファイルを蓄積制御する際に、前記ヘッダ情報に記述された前記コンテンツタイプ情報に関連付けられたイベント識別子を取得し、当該イベント識別子に関連付けられたデータブロックを全て取得し、取得したデータブロックから１つのモジュールを構築し、構築したモジュールに含まれる所定の蓄積型リソースリストから、当該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を抽出し、抽出した枝番とバージョンを示す情報に基づいて前記各項目のコンテンツの蓄積を実行する手段を有することを特徴とする受信装置。
4. 前記コンテンツ蓄積実行手段は、前記蓄積型リソースリストから、前記複数項目コンテンツのジャンル情報を抽出してコンテンツファイルのジャンルを決定する手段をさらに有することを特徴とする、請求項３に記載の受信装置。
5. デジタル放送の放送波でコンテンツファイルを受信する際に、該複数のコンテンツを受信側で蓄積予約させるのに必要とされる番組スケジュールテーブルを受信する受信装置にて、前記番組スケジュールテーブルは、各コンテンツファイルを放送するサービスを一意に指定するサービスＩＤと、開始時刻、放送持続時間、及びコンテンツファイルを一意に表すイベント識別子と、コンテンツタイプを表すコンテンツタイプ情報とを含み、前記イベント識別子は、デジタル放送で放送されるデータブロックのヘッダ情報に記述されており、前記受信装置における蓄積制御部を構成するコンピュータに、
   前記番組スケジュールテーブルを受信して、前記イベント識別子によって識別されるコンテンツファイルを蓄積予約するための蓄積予約管理表を、コンテンツタイプ情報を付加して生成するステップと、
   前記蓄積予約管理表で蓄積予約するべく規定されたコンテンツを、前記開始時刻で蓄積予約の開始を制御するステップと、
   前記開始時刻で蓄積予約したコンテンツの蓄積を、前記ヘッダ情報と前記コンテンツタイプ情報の組み合わせに応じて、カルーセル方式のデータブロック単位で実行するステップと、を実行させるためのプログラムであり、
   前記コンテンツの蓄積を行うステップは、前記ヘッダ情報と前記コンテンツタイプ情報の組み合わせから、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた蓄積制御を実行するステップを含み、さらに、前記コンテンツタイプ情報として複数項目コンテンツのコンテンツファイルを蓄積制御する際に、前記ヘッダ情報に記述された前記コンテンツタイプ情報に関連付けられたイベント識別子を取得し、当該イベント識別子に関連付けられたデータブロックを全て取得し、取得したデータブロックから１つのモジュールを構築し、構築したモジュールに含まれる所定の蓄積型リソースリストから、当該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を抽出し、抽出した枝番とバージョンを示す情報に基づいて前記各項目のコンテンツの蓄積を実行するステップを含む、プログラム。

Images