まず、本発明の理解を助けるために、本発明に係る任意ファイルをダウンロード配信・受信する放送サービスの放送システムの一実施例について説明する。本実施例の放送システムの説明から、本発明に係る送信装置及び受信装置の構成も明らかになる。
[システム構成]
図1は、本発明による一実施例の放送システムの概略構成図である。放送局側送信装置1は、コンテンツの映像用データ、音声用データ、データ放送のデータ、及び字幕用データ等の各データをデジタル放送で受信装置(図1では、車載・ポータブル受信端末2−1,携帯電話機2−2を例示するが、以下の説明では、包括的に「受信装置2」として説明する)に向けて配信する装置であり、特に、EPGを構成する放送SIの情報の中に、具体例としてEIT内に新規の記述子である「ファイル伝送識別子」とコンテンツタイプを表す「コンテンツタイプ情報(content_type)」を追加して「拡張EIT」を構成して伝送するか、又はコンテンツの蓄積予約のためのコンテンツ表の作成を可能とするコンテンツ指向の蓄積予約(映像等の場合、予約録画を含む)に必要な情報を組み入れたコンテンツスケジュールテーブル(CST:後述するContent_Schedule_Sectionから構成されるテーブル)を構成して伝送する装置である。「拡張EIT」及び「CST」の詳細については後述する。
受信装置2は、この「拡張EIT」又は「CST」とDIIの組み合わせによって、如何なる種類のコンテンツファイルが配信され、どのように蓄積予約を行うべきかについて把握し、コンテンツファイルの蓄積予約を管理するための「蓄積予約管理表」及び、コンテンツファイルの蓄積の有無を管理するための「蓄積コンテンツ管理表」を生成して、配信されるコンテンツの蓄積をユーザの指定により、又は自動設定に基づき管理する装置である。
まず、従来の技術では、コンテンツタイプに分けることなくダウンロードコンテンツを配信していたために、送信側及び受信側での処理負担が大きかった。特に、同一のサービスIDでも複数の項目からなるコンテンツについては、各項目コンテンツを別々のカルーセルで伝送していた。この場合、カルーセルの切り替え時に、受信装置2側では受信処理の切り替えを行うことになり、この切り替え時の取りこぼしを考慮して、送信装置1側では、伝送するカルーセルを1周以上冗長して伝送する必要が生じていた。そこで、本発明では、詳細に後述するように、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプに応じた蓄積制御を可能とする伝送システムを構成し、「複数項目コンテンツ」のコンテンツタイプについては、より効率的なダウンロード配信を実現する。
本発明の理解を助けるために、従来技術と、その課題、及び本発明に係る動作の概念図を図2に示す。図2(a)は、番組スケジュールを構成するEPGやECGで、例えば番組「いつでもニュース」、「気象情報」及び「いつでもニュース」を順次配信する態様を例示している。「いつでもニュース」は、複数項目コンテンツを構成しており、「ニュースA」、「ニュースB」、「ニュースC」及び「ニュースD」の項目のコンテンツファイルを含んでいる。この場合、図2(b)に示すように、従来技術では、送信装置側では、伝送するカルーセルを1周以上冗長して(例えば、1.5カルーセル)、伝送する必要が生じていた。これは、放送コンテンツであるがゆえに、受信装置側で番組コンテンツの取りこぼしを予想しているためであり、結果として放送時間が長くなり非効率的であった。
そこで、本発明の方式では、「ニュースA」、「ニュースB」、「ニュースC」及び「ニュースD」の項目のコンテンツファイルをマルチパート化して一つの「複数項目コンテンツ」として伝送する。この場合、受信装置2側の取りこぼし対策として、送信装置1は、コンテンツタイプ情報として複数項目コンテンツのコンテンツファイルを送信する際に、コンテンツタイプ情報に関連付けられたイベント識別子をヘッダ情報(DII)に記述し、該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を所定の蓄積型リソースリストに記述して、該蓄積型リソースリストの情報と各項目のコンテンツをマルチパート化したデータブロックで送信するように構成する。これにより、受信装置2は、コンテンツタイプ情報として複数項目コンテンツのコンテンツファイルを蓄積制御する際に、ヘッダ情報に記述されたコンテンツタイプ情報に関連付けられたイベント識別子を取得し、当該イベント識別子に関連付けられたデータブロックを全て取得して一時蓄積し、取得したデータブロックから1つのモジュールを構築し、構築したモジュールに含まれる所定の蓄積型リソースリストから、当該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を抽出し、抽出した枝番とバージョンを示す情報に基づいて保存すべき各項目のコンテンツの蓄積を実行する。
以下、本発明に係る任意ファイルをダウンロード配信・受信する放送サービスの放送システムの一実施例について説明する。
[拡張EIT]
「拡張EIT」は、図3に示すように、既存のEIT内に新規の記述子である「ファイル伝送識別子」とコンテンツタイプを表す「コンテンツタイプ情報(content_type)」を追加して「拡張EIT」を構成したものである。
詳細は後述するが、「ファイル伝送識別子(file_delivery_descriptor)」は、受信装置2側でコンテンツファイルの内容を識別させるための「ファイル種別情報(file_type_value)」を含み、必要に応じて、標準化機関が設定する当該ファイル伝送識別子を利用する機関を特定するための「記述子タグ情報(descriptor_tag)」と、当該ファイル伝送識別子の長さを表す「識別子長(descriptor_length)」と、コンテンツファイルに対して予め規定した暗号化が施されているか否かを識別するための「暗号化フラグ(encryption_flag)」と、上記以外の任意の情報を記述するための「リザーブ(reserved_future_use)」と、標準化機関が設定する当該ファイル伝送識別子で関連付けるコンテンツファイルのデータ構成(データコンポーネント)を識別するための「データコンポーネント識別子(data_component_id)」とを含む。尚、既存EITに新規に追加する「ファイル伝送識別子(file_delivery_descriptor)」は、PMTにも追加記載することも望ましく、この場合にはコンテンツとの関連付けを再確認できるようになる。尚、「ファイル種別情報(file_type_value)」は、標準化機関に順ずる機関、もしくは、運用するプラットフォーム会社等が管理を行い、放送事業者、メーカー等に開示を行うのが好適である。これにより、受信装置2は実際に任意ファイルを受信する前に、配信されるファイルの内容を把握可能であり、受信の可否の判断が可能となる。
[コンテンツスケジュールテーブル(CST)]
「CST」は、図4(a)に示すように、CSTの種別を表す「テーブル識別子」と、CSTの伝送識別情報(セクション情報)を表す「伝送識別情報」と、コンテンツごとに割り当てられた固有の識別子を表す「イベント識別子(event_id)」と、コンテンツファイルの内容を識別させるための「ファイル種別情報(file_type_value)」と、コンテンツタイプを表す「コンテンツタイプ情報(content_type_value1, content_type_value2, content_type_value3)」と、放送するコンテンツファイルの変更の有無を確認可能にする「ファイルバージョン番号(file_version_number)」(これは、ファイル伝送識別子(file_delivery_descriptor)を伝送する場合、省略することもできる)と、放送回数を示
す「broadcast_count(8bits)」と、各コンテンツの放送の開始時刻、放送持続時間、及び放送回数を表す「放送時刻識別情報」と、各コンテンツの記述内容を表す「各種記述子」からなる。また、コンテンツスケジュールテーブル(CST)は、1つのCSTに含まれる複数のコンテンツについて、所定回数の「放送時間の情報」とEITで運用されるものと同一の各種記述子である、コンテンツのコピーを制限する制御する旨を表す「デジタル制御記述子」、コンテンツのタイトルを表す「短形イベント記述子」、番組内容を表す「コンテント記述子」、ジャンル及びシリーズ番組である旨を表す「シリーズ記述子」を記述している。尚、コンテンツタイプ情報(content_type)は、図4(a)に示す「コンテンツ情報」内の記述子とすることができる。また、「伝送識別情報」は、各サービス態様で随意決定することができ、その一例を以下に示す。
「CST[p/f]」は、図4(b)に示すように、EIT[p/f]の代わりに用いるものであり、CSTの記述内容に対して現在及び次に放送されるコンテンツの1回分の放送の開始時刻及び放送持続時間を伝送するように構成される。ただし、コンテンツファイルの内容を識別させるためのファイル伝送識別子(file_delivery_descriptor)を各種記述子の記述欄に追加して伝送することができ、この場合、「ファイルバージョン番号(file_version_number)」の記述を省略することができる。
つまり、「CST[p/f]」は、図4(c)に示すように、受信装置2側では、コンテンツファイルの更新や差し替えの発生の有無を、「CST[p/f]」内の「ファイルバージョン番号(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として3種類とし、拡張EITやCSTで伝送するように構成する。
例えば、ファイル種別(file_type_value)、コンテンツ種別(content_type_value1),
コンテンツ種別(content_type_value2)、及び、コンテンツの本編・補足種別(content_type_value3)のビット割当と識別項目、及び識別内容の例を表1〜表5に示す。表1は、file_typ_value及びcontent_type_valueと対応する識別項目の関係を示しており、表2は、file_type_valueとファイル種別の対応関係を示しており、表3は、content_type_value1とコンテンツ種別の対応関係を示しており、表4は、content_type_value2とコンテンツ更新種別の対応関係を示しており、表5は、content_type_value3と本編・補足種別との対応関係を示している。また、表6には、記述子と対応する受信処理の関係を示す。
尚、「ファイルバージョン番号(file_version_number)」は、同じevent_idのコンテンツで内容の変更の有無を通知する。拡張EIT[p/f]やCST[p/f]の受信処理を軽くしたい場合に、ファイル伝送識別子(file_delivery_descriptor)を記述せずとも、この「ファイルバージョン番号(file_version_number)」の値を参照するのみで、カルーセル受信の有無を判断することができ、拡張EITやCSTに記載することで、一般番組で変更があったことを知ることも可能となる。尚、上書き更新コンテンツについても、「ファイルバージョン番号(file_version_number)」が前回と異なっている場合は、カルーセルを受信し、上書き更新するのに有利な情報となる。
一方、ファイル伝送識別子(file_delivery_descriptor)は、複数項目コンテンツにおける各項目のコンテンツファイルの識別のために、拡張EIT[p/f]やCST[p/f]に挿入することができ、p/f情報の取得の時点で、複数項目コンテンツにおける各項目のコンテンツの更新差替情報、項目数を把握することができるようになる。ファイル伝送識別子(file_delivery_descriptor)には、複数項目コンテンツにおける各項目のコンテンツについて項目毎のジャンル情報を記述しておくことで、受信装置2は、所望のジャンル情報のみについて蓄積制御すればよくなる。
受信装置2側では、CST[p/f]によって、コンテンツファイルの更新や差し替えの発生の有無を確認した場合、カルーセルのDIIに記述されるファイル情報記述子(file_info_descriptor)から、ファイル情報記述子である旨を示す「記述子タグ(descriptor_tag)」及び「記述子長(descriptor_length)」を参照して確認し、ブランチカウント情報(branch_count)で複数項目コンテンツに含まれる項目コンテンツファイルの数を確認し、各項目コンテンツファイルのジャンル情報(例えば、content_nibble_level1, content_nibble_level2)を把握することができる。
「CST[p/f]」内に、ファイル伝送識別子(file_delivery_descriptor)が記述される場合、当該イベント識別子(event_id)のコンテンツファイルの枝番(ex_event_id)とデータイベント識別子(data_event_id)から、複数項目コンテンツの各項目のコンテンツファイルとそのバージョン情報を基に、コンテンツファイルの更新や差し替えの発生の有無を把握することができる。
「table_id (8bits)」は、セクションが属するテーブルの識別のために使用する値であり、カルーセル伝送方式で伝送されるコンテンツのストリーム(自ストリーム又は他ストリーム)、及び、1時間以内,6時間以内,12時間以内,1日以内,1日以降の放送時間のコンテンツの組合せで種別化されたテーブル識別子である。尚、for()は、所定数分、繰り返し記述されていることを意味している。
「section_syntex_indicator (1bit)」は、セクション形式は通常形式と拡張形式の2種類があり、その種別を識別するための値である。通常形式は0、拡張形式は1であり、本例では「1」に固定しており、伝送識別情報の1つである。
「reserved_future_use (1bit)」は、符号化ビットストリームを定義する項の中で使用する場合、その値が将来、例えば所定のビット(B10)が定義する拡張子として使用可能であることを表す。本例では未定義(全ビット1)とする。即ち、拡張子を表す伝送識別情報の1つである。別途、「reserved」を設けることができ、符号化ビットストリームを定義する中で使用する場合、その値が将来ISOで定義される拡張子として使用可能であることを表す。本例では未定義(全ビット1)とする。
「section_length(12bits)」は、セクション長フィールドの直後からCRC(Cyclic Redundancy Check)を含むセクションの最後までのセクションのバイト数を規定する。即ち、CSTの長さを表す伝送識別情報の1つである。
「service_id(16bits)」は、当該トランスポートストリーム内の他のサービスからこのサービスを識別するための値である。即ち、CSTにおけるコンテンツのチャンネル(サービスID)を表す伝送識別情報の1つである。
「version_number(5bits)」は、サブテーブルのバージョン番号を表す伝送識別情報の1つである。尚、サブテーブルは、table_idとservice_idとtransport_stream_idとversion_numberが同じセクションであることを表す。
「current_next_indicator(1bit)」は、サブテーブルが現在使用可能である場合は「1」。サブテーブルが現在使用不可であり次に有効となることを示す場合は「0」であり、CST自体の連番を表す伝送識別情報の1つである。
「section_number(8bits)」は、セクションの番号を表す。サブテーブル中の最初のセクション番号は0x00である。セクション番号は同一のtable_idとservice_idとtransport_stream_id、original_network_idを持つセクションの追加毎に1加算される。即ち、CST内の現セクション番号を表す伝送識別情報の1つである。
「last_section_number(8bits)」は、そのセクションが属するサブテーブルの最後のセクションの番号である。即ち、CST内の全セクション番号を表す伝送識別情報の1つである。
「transport_stream_id(16bits)」は、EITと同様にCSTが示すこのトランスポートストリームをその分配システム内の他の多重から識別するための値である。即ち、CSTを伝送するTSIDを表す伝送識別情報の1つである。
「original_network_id(16bits)」は、元の分配システムのネットワーク識別を表す伝送識別情報の1つである。
「segment_last_section_number(8bits)」は、サブテーブルをコンテンツ数や放送開始時間などで複数のセグメントに分け、このセクションが属するセグメントの中で最後のセクションの番号を記載することもできる。CSTを伝送するセグメント最終セクション番号を表す伝送識別情報の1つである。尚、サブテーブルをある単位で区切ったものをセクションとする。例えば200個のコンテンツを10個のコンテンツ毎に分けた場合、セグメント数は20となる。尚、「Last_table_id」を設けて、使用されている最終のテーブル識別を示すようにすることもできる。使用されるテーブルが1個のみの場合は、このフィールドにはこのテーブルのテーブル識別が設定される。
「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)」は、続く記述子の長さを表す。各種記述子は、運用されるEITの記述子をそのまま採用することができる。
[CSTと拡張EITの併用]
図5は、CSTと拡張EITを併用した例を示す。本例は、番組スケジュールにCSTを用い、コンテンツの蓄積直前に取得するテーブルには、拡張EIT[p/f]を用いる例である。図5(a)に示すCSTは、図4(a)に示すものと同様である。図5(b)に示す拡張EIT[p/f]は、既存のEITに、図5(b)に示すように「ファイル伝送識別子(file_delivery_descriptor)」が追加されたものである。図4に示すように構成しても、「CST[p/f]」内に、ファイル伝送識別子(file_delivery_descriptor)が記述される場合、当該イベント識別子(event_id)のコンテンツファイルの枝番(ex_event_id)とデータイベント識別子(data_event_id)から、複数項目コンテンツの各項目のコンテンツファイルとそのバージョン情報を基に、コンテンツファイルの更新や差し替えの発生の有無を把握することができる。
現在のデジタル放送では、番組情報を記述するEITの中に各番組をユニークに示すイベント識別子(event_id)が記述されている。イベント識別子(event_id)は一定時間、例えば24時間以内はユニークな値として放送局で運用されている。そして、一定時間が過ぎると、再度ユニークな値として再割当される。本発明においては、ダウンロードするコンテンツファイルごとにイベント識別子(event_id)を割り当てることとし、一定の時間、例えば24時間や1週間の間は、同一のファイルを繰り返し配信する場合は、同一のイベント識別子(event_id)を繰り返し使用することとする。同一ファイルを繰り返し配信することで受信装置2は移動中であっても受信できる機会が増加し確実に受信可能となる。また、受信装置2はイベント識別子(event_id)を確認することで、同一ファイルであれば既に受信済みの場合は受信しなくてもよいという判断が可能となる。なお、イベント識別子(event_id)の値をどれくらいの時間でユニークにするかについては、標準化機関等で規定されるものとする。
ここで、リアルタイムサービスのコンテンツについて詳述する。本発明では、リアルタイムサービスにおいて番組の識別はevent_idを使用し、ダウンロードサービスにおいてはevent_idに加え、event_idの枝番(ex_event_id)、およびdata_event_idを用いるようにしている。すなわち、ダウンロードサービスではevent_id + ex_event_id + data_event_idでコンテンツが一意に特定される。ダウンロードサービスのコンテンツ識別情報とビット数、識別内容を表7に示す。
一般的なコンテンツをダウンロードする場合、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の値を例えば12bitとし、異なる項目の指定は最大4096種類(正確には0xFFFを除き4095種類)とすることができる。
また、ダウンロードサービスでは、同じ内容のコンテンツが複数回送信され、受信装置2側で欠損データの補完として利用することが可能であるが、2回目以降の送信において内容を一部変更するなど、バージョンの異なるコンテンツが送信されるケースが想定される。この場合、バージョンの変更を受信側に知らされない状態で欠損データの補完を行うと、変更部分の映像や音声などのデータが不連続となり、コンテンツの視聴に支障をきたすことになる。そこで、バージョンの異なるコンテンツを送る場合、異なるdata_event_idの値が付与され、受信装置2側でのバージョン管理を可能とする。
例えば、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の情報を提示する受信装置2は、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が使用されないものとすることができる。
受信装置2は、event_id等によりダウンロードの予約を行い、予約した時間にデータカルーセルで送信されるファイルの受信を実行する。ダウンロード中、パケットを取りこぼすなどの原因により、ダウンロードが完了しなかった場合は、再度ダウンロード待機状態に遷移し、ダウンロードの放送スケジュール情報に記載された次の日時まで予約待機し、放送時刻になるとダウンロードの状態になり、欠損データの補完を行うことが可能である。また、送信されるコンテンツのバージョンが更新される場合、ファイル伝送記述子内のdata_event_idの値を参照することで、別バージョンとしてコンテンツの蓄積が可能となる。
ダウンロードサービスにおいて拡張EITで使用される記述子は、リアルタイムサービスで使用される短形式イベント記述子、コンテント記述子、デジタルコピー制御記述子、音声コンポーネント記述子、データコンテンツ記述子、スタッフ記述子に加え、前述のファイル伝送記述子、およびシリーズ番組を識別するシリーズ記述子を用いるのが好適である。
上述したように、CSTにはevent_id、file_type_value、content_type_valueが含まれており、コンテンツの再送出も含めた送出時間が記載される。拡張EITでは1つのevent_idに対して1つの送出時間情報(start_time、duration)が記載されるのに対し、CSTでは1つのevent_idに対して複数の送出時間情報が記載される。これにより再送出を行うコンテンツについては、拡張EITに比べて伝送する情報量の削減が可能となり、受信装置は再送出を含めたコンテンツ蓄積のためのスケジュール情報の取得が可能となる。なお、CSTには送出直近に変更される可能性の高いex_event_id値、data_event_id値は記載しないようにすることもできる。
図6は、本発明による一実施例の放送局側送信装置1の概略図である。放送局側送信装置1は、コンテンツ編成部10と、カルーセル処理部11と、PSI/SI生成符号化部12と、多重化部13と、OFDM変調部14と、送信部15とを備える。コンテンツ編成部10は、コンテンツ符号化部101と、制御データ生成部102と、EIT生成部103とを備える。制御データ生成部102は、識別子付番制御部1021と、伝送回数・周期管理部1022とを備える。EIT生成部103は、ファイル伝送記述子生成部1031を備える。
コンテンツ編成部10は、放送波で配信するためのコンテンツを生成するとともに、「拡張EIT」又は「CST」で関連付けられたコンテンツを受信側で蓄積予約させるための基礎データとなる番組スケジュールを生成するように構成される。「拡張EIT」は、既存のEITに、「ファイル伝送識別子」を付加したものであり、従来のEITと比較して伝送容量をほとんど増大させることなしに、コンテンツに関する情報の受信又は更新の負担を大きく低減させる。一方、「CST」は、コンテンツ指向の番組情報を伝送するため、コンテンツを受信側で蓄積予約させるための基礎データとなる番組スケジュールを簡単に構成することができる。また、CSTは、EITと比較してテーブルサイズを小さくすることができ、コンテンツに関する情報の受信又は更新の負担を大きく低減させることができる。また、リアルタイム型放送に連動したダウンロードを実行する際には、コンテンツ編成部10は、ダウンロード放送で送信するコンテンツファイルと、リアルタイム放送で送信するコンテンツとを、それぞれ異なるサービスIDで同一のTS内で送出するとともに、リアルタイム型放送をプライマリ(Primary)、ダウンロード型放送をセカンダリ(Secondary)としてグルーピングする所定のサービスグループ識別子(service_group_descriptor)をNITにて伝送する機能を有する(詳細は後述する)。
より具体的には、コンテンツ符号化部101は、放送波で配信するための任意ファイルのコンテンツを符号化する。例としてTSファイルの場合は、コンテンツを編成する要素である映像、音声、データ、字幕、PSIを生成して符号化し、多重化(パッケージ化)を施し、TSを生成する。尚、PSIは、このTSを受信側で再生する際に必要なPAT及びPMT等の情報である。
制御データ生成部102は、コンテンツ符号化部101を経て伝送するコンテンツを、カルーセル処理部11によってカルーセル方式で伝送する際に、DIIメッセージ内のダウンロードID(downloadID)と「拡張EIT」又は「CST」のイベント識別子(event_id)とを関連付けた紐付けた態様で伝送するよう制御する識別子付番制御部1021と、イベント識別子(event_id)で識別されるイベント毎にカルーセル方式で伝送するデータブロック(DDB)の伝送回数と、カルーセル方式で伝送する周期を管理する伝送回数・周期管理部1022からなる。このカルーセル方式で伝送するコンテンツをイベント識別子(event_id)で識別されるイベントとして管理するために、識別子付番制御部1021は、EIT生成部103にイベント識別子(event_id)を送出する機能を有する。即ち、コンテンツファイルは、設定される送信周期に従って一定頻度で送信され、この送信周期は、コンテンツ別に設定可能であり、例えば、5分〜120分の間で設定することができる。また、制御データ生成部102は、コンテンツタイプを表す「コンテンツタイプ情報(content_type)」と、「イベント識別子(event_id)」と、コンテンツ情報としての「シリーズ記述子(series_id)」とを組み合わせて、コンテンツタイプごとの予約蓄積制御を可能とするべく「拡張EIT」又は「CST」を編成するとともに、DIIに少なくとも「イベント識別子(event_id)」の情報と、その「枝番」及び「データコンポーネント識別子(data_component_id)」を設定する。
EIT生成部103は、識別子付番制御部1021から得られるイベント識別子(event_id)を、放送波で配信するためのコンテンツを受信装置側で蓄積させるのに用いる既存のEITに組み入れ、且つ「ファイル種別情報(file_type_value)」を含む「ファイル伝送識別子(file_delivery_descriptor)」を生成して追加し、拡張EITを構成してEIT番組情報としてPSI/SI生成符号化部12に送出する。ファイル伝送記述子生成部1031は、イベント識別子(event_id)によって識別されるコンテンツファイルの内容の種別を表す「ファイル種別情報(file_type_value)」を含む「ファイル伝送識別子(file_delivery_descriptor)」を生成する機能を有する。尚、EIT生成部103は、識別子付番制御部1021から得られるイベント識別子(event_id)を、放送波で配信するためのコンテンツを受信装置側で蓄積させるのに用いる「CST」に組み入れて構成し、EIT番組情報としてPSI/SI生成符号化部12に送出するように構成することができる。「CST」を伝送する場合にも、コンテンツファイルの内容の種別を表す「ファイル
種別情報(file_type_value)」を生成して組み入れることができる。
カルーセル処理部11は、コンテンツ符号化部101によって符号化したコンテンツを、制御データ生成部102によるカルーセル方式の伝送回数及び送信周期と、DIIメッセージ内のダウンロードID(downloadID)とEITのイベント識別子(event_id)とを関連付けた態様でカルーセル化して、DII及びDDBのモジュールを構築して多重化部13に送出する。
例えば、コンテンツ配信のサービスIDを表すチャンネル(Ch)にて、コンテンツデータは、コンポーネントタグ(component_tag:ESm〜ESn)で識別できるように多重化され、コンテンツデータは、拡張EIT又はCSTで関連付けられた複数のコンテンツについて、選局した放送ストリームから抽出したDII/DDB情報を用いてイベント識別子(event_id)によって識別されるコンテンツごとにダウンロード・データブロック(DDB)を切り替えて取得することができる。尚、コンテンツは、1つ又は複数のモジュールで構成して伝送することもできる。
PSI/SI生成符号化部12は、受信装置2で放送波を受信するために必要なPSI/SI情報(即ち、EIT番組情報)を生成して符号化し、多重化部13に送出する。このEIT番組情報は、拡張EITと、各コンテンツの放送時のデータパケット、開始時刻、放送持続時間、及びコンテンツファイルを一意に表す「イベント識別子」とを含むPSI/SI情報として構成される。
多重化部13は、上記カルーセル化したコンテンツデータやPSI/SI等を、チャンネルごとに多重化して、TSを形成し、OFDM変調部14に送出する。
OFDM変調部14は、多重化部13を経て得られるTSを、デジタル放送のOFDM方式に従う変調方式で変調を施して、送信部15を介して外部に放送波として伝送する。
このように、放送局側送信装置1は、拡張EITを一定頻度で送信するとともに、拡張EIT又はCSTに基づいてコンテンツをカルーセル伝送方式で送信する。尚、詳細に後述するが、放送局側送信装置1は、拡張EIT又はCSTに従って、各コンテンツをダウンロードID(downloadID)と紐付けされたイベント識別子(event_id)で関連付けたデータブロックにて再放送することが可能であり、受信装置2は、再放送の回数や周期を拡張EIT又はCSTから知ることができる。
図7は、本発明に係る一実施例の受信装置2の概略図である。受信装置2は、受信用アンテナを有するOFDM復調部20と、TS復号部21と、音声・復号部22と、映像・復号部23と、字幕・復号部24と、カルーセル処理部25と、BMLブラウザ26と、提示処理部27と、SI処理部28と、コンテンツ蓄積予約制御部29と、コンテンツ蓄積部30と、蓄積コンテンツ一覧表示・再生指示部31と、ユーザI/F部32とを備える。
OFDM復調部20は、拡張EIT又はCSTのデータを構成するEIT番組情報を復調して、このTSをTS復号部21に送出する機能と、この拡張EIT又はCSTに対応するコンテンツデータを受信し、OFDM復調部20を介して復調して、このTSをTS復号部21に送出する機能を有する。デジタル放送では、TSデータ中のPIDを検出し、このPIDを読み取ることで、コンテンツデータ、拡張EIT又はCSTのデータの識別を行うことができ、ES番号(component_tag)を検出し、このES番号を読み取ることで、所望するデータの識別ができる。
TS復号部21は、OFDM復調部20を経て得られるEIT番組情報を復号して拡張EIT又はCSTのデータを復号し、SI処理部28に送出する機能と、OFDM復調部20を経て得られるEIT番組情報に対応するコンテンツデータを復号し、それぞれ対応する機能部である音声・復号部22、映像・復号部23、字幕・復号部24及びカルーセル処理部25に送出する。音声・復号部22、映像・復号部23、字幕・復号部24は、それぞれコンテンツを編成する音声、映像、字幕を復号して提示処理部27に送出する機能を有し、カルーセル処理部25は、コンテンツを編成するデータ放送用のデータを送信側と対応するカルーセル方式に従ってカルーセル処理を施しながら復号してBMLブラウザ26に送出する機能を有する。復号したデータ放送用のデータは、BMLブラウザ26によって規定された描画方式に従って変換され、提示処理部27に送出される。提示処理部27は、外部装置(例えば、表示装置やスピーカ等)にコンテンツを編成する音声、映像、字幕、その他のデータを提示する機能を有する。
ただし、カルーセル処理部25は、コンテンツ蓄積予約制御部29からの制御信号によって、当該拡張EIT又はCSTに対応するコンテンツデータの取得及び蓄積が制御され、当該拡張EIT又はCSTに対応するコンテンツデータを、コンテンツ蓄積部30に蓄積する。コンテンツ蓄積部30内に蓄積されるコンテンツデータは、コンテンツ蓄積予約制御部29によって管理され、コンテンツ蓄積予約制御部29は、当該拡張EIT又はCSTに従ってデータブロック単位で取得したコンテンツの上書き更新や差し替えや蓄積予約の制御に用いるコンテンツファイルの蓄積予約を管理するための「蓄積予約管理表」及びコンテンツファイルの蓄積の有無を管理するための「蓄積コンテンツ管理表」をコンテンツ蓄積部30に格納及び更新する機能を有する。
コンテンツ蓄積部30に格納されたコンテンツファイルや「蓄積予約管理表」及び「蓄積コンテンツ管理表」は、ユーザがユーザI/F部32を介して指定することにより表示又は再生することができるよう蓄積コンテンツ一覧表示・再生指示部31によって表示又は再生が制御される。
尚、「蓄積予約管理表」は、放送される時間軸に従うコンテンツ別の放送時間、タイトル、シリーズ、及びジャンルを特定することができるEPGとして利用されるものである(図13参照)。また、「蓄積コンテンツ管理表」は、コンテンツ別に蓄積済みであるか否かと、未蓄積DDBの有無を管理可能な態様で構成される(図14参照)。
SI処理部28は、拡張EIT又はCSTのデータを入力してチャンネルごとの放送コンテンツのEIT情報と、各コンテンツの放送時のデータパケット、開始時刻、放送持続時間、及びコンテンツファイルを一意に表す「イベント識別子」とを含むPSI/SI情報(即ち、EIT番組情報)をコンテンツ蓄積予約制御部29に送出する。
また、コンテンツ蓄積予約制御部29の詳細は後述するが、ユーザによって「蓄積予約管理表」で指定されたコンテンツの蓄積予約の動作を制御する機能を有する。例えば、コンテンツ蓄積予約制御部29は、指定されたコンテンツの蓄積予約状態を管理するために、「蓄積予約管理表」を生成し、コンテンツごとに蓄積予約待ちであるか否かを示すマーキングをして、コンテンツの蓄積予約の制御を管理することができる。また、コンテンツ蓄積予約制御部29は、リアルタイム放送で送信されるコンテンツの受信時に、リアルタイム型放送をプライマリ、ダウンロード型放送をセカンダリとしてグルーピングする所定のサービスグループ識別子を受信して、前記リアルタイム放送で送信されたコンテンツに連動する、ダウンロード放送で送信されるコンテンツファイルの有無を判別し、コンテンツファイルの有を判別した際に、当該受信装置2に設定される自動ダウンロード実行の指示にしたがって、リアルタイム放送で送信するコンテンツとは異なるサービスIDのダウンロード放送で送信されるコンテンツファイルの自動蓄積を制御するコンテンツ蓄積実行手段として機能する。
次に、放送局側送信装置1と受信装置2とを含む放送システムの代表的な動作について説明する。
[システム動作]
図8は、本発明による一実施例の放送システムの動作説明図である。
まず、放送局側送信装置1の動作を説明するに、放送局側送信装置1は、一定間隔で拡張EIT又はCSTのデータを構成するEIT番組情報(本例では拡張EITに含まれるEITschedule又はCSTのcontent_schedule)を配信する(ステップS1〜S3)。また、拡張EIT又はCSTに従って時間編成された放送される番組情報の変更の有無を含む、現在の番組と次の番組の情報(CST/拡張EIT‐p/f)を配信する(ステップS4)。ここで、一般的なネットワーク通信のような双方向通信によってコンテンツの再要求及び再送信するものとは異なり、放送コンテンツであるので、受信装置側で受信不良が生じた場合を予め想定して、放送局側送信装置1が備える制御データ生成部102は、拡張EIT又はCSTに従うイベント識別子(event_id)で管理されたコンテンツデータを、拡張EIT又はCSTに従う所定周期及び回数によって、カルーセル方式(図9参照)で送信及び再送信する(ステップS5,S6)。
例えば、放送局側送信装置1は、1TS(1セグメント又は3セグメント放送)内で、リアルタイム放送の番組コンテンツを時間編成で送信するメインチャンネル(メインch1)と、このメインch1の番組コンテンツに連動する任意ファイル(例えば、動画ファイル、PDF、TSファイル、3GPP等)を多重して送信する、コンテンツ提供者が独自に利用する独自チャンネル(独自ch1)と、このメインch1の番組コンテンツに連動することなく、独立した任意ファイル(例えば、リアルタイムの更新が要求されるような交通情報等)を多重して送信する、コンテンツ提供者が独自に利用する第2の独自チャンネル(独自ch2)の3チャンネルのコンテンツを多重送信することが可能である。
これらのメインch1、独自ch1及び独自ch2のコンテンツは、EIT番組情報(拡張EIT又はCST)から、チャンネル種別をそれぞれサービスID(serviceID)で識別することができるだけでなく時間軸方向の編成についてもイベント識別子(event_id)で識別し、且つイベント識別子(event_id)によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送識別子(file_delivery_descriptor)」内の「ファイル種別情報(file_type_value)」で識別することができ、EPGを直ちに構成することができる。
従って、受信装置2は、EIT番組情報として機能する本発明に係る拡張EIT又はCSTを復号して、チャンネル種別をそれぞれサービスIDで、メインch1、独自ch1及び独自ch2のチャンネル別コンテンツを把握し、各チャンネルにおける時間軸方向の編成についてイベント識別子(event_id)で識別し、且つイベント識別子(event_id)によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送識別子(file_delivery_descriptor)」内の「ファイル種別情報(file_type_value)」で識別し、EPGのコンテンツ番組一覧を直ちに構成することができる。
以下、受信装置2の動作について説明する。
受信装置2は、EIT番組情報を受信して拡張EITを復号し、チャンネル種別をそれぞれサービスIDで、メインch1、独自ch1及び独自ch2のチャンネル別コンテンツを把握し、各チャンネルにおける時間軸方向の編成についてイベント識別子(event_id)で識別し、且つイベント識別子(event_id)によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送識別子(file_delivery_descriptor)」内の「ファイル種別情報(file_type_value)」で識別することにより、拡張EIT又はCSTにおけるコンテンツがコンテンツファイルとして蓄積可能なファイルであるか否かを判断し、コンテンツタイプ情報(content_type)で上書き蓄積するファイルであるか否かを判断する(ステップS11〜S13)。
続いて、受信装置2は、蓄積可能なファイルについて放送される時間軸に従うコンテンツ別の放送時間、タイトル、シリーズ、及びジャンルを特定し、EPGとして利用する「蓄積予約管理表」を生成し、受信装置2のユーザに提示可能にする(ステップS14)。受信装置2は、ユーザによって指定されたコンテンツを蓄積予約として「蓄積予約管理表」に設定して登録し、放送時刻の直前に蓄積予約を起動して、拡張EIT又はCSTに従って時間編成された放送番組の変更の有無を含む現在番組と次の番組(CST/拡張EIT‐p/f)を受信する(ステップS15)。従って、受信装置2は、予約時間数分前にCST又は拡張EITを再取得して放送コンテンツの変更がないことを確認し、変更がある場合には蓄積予約管理表の登録内容を自動更新する。
受信装置2は、蓄積予約管理表の登録内容に従って、コンテンツの蓄積予約の制御を行い、放送時間になると、該当エレメンタリストリーム (ES)のDIIを取得し、DIIに記載されたイベント識別子(event_id)に紐づくダウンロードID(downloadID)で、ダウンロードするコンテンツファイルをコンテンツタイプとともに特定し、該当するモジュール内のデータブロック(DDB)列を受信してコンテンツの蓄積を実行する(ステップS16)。該当コンテンツが、モジュールリンクされている場合には、対応する複数のモジュール内のデータブロック(DDB)列を受信して蓄積する。尚、受信装置2は、蓄積予約したコンテンツが放送開始時刻(start_time)に従って放送中であれば、受信して蓄積動作を実行し、放送開始時刻(start_time)外であれば(蓄積予約したコンテンツが放送中ではなければ)、蓄積予約管理表に登録して放送時間まで待機することになる。受信不良が原因で一度にコンテンツを構成する全てのデータが受信できない場合にも、コンテンツは、DDB単位で伝送されているために、カルーセル方式で伝送されるカルーセル回数内で再取得可能であれば、受信に失敗したDDB単位で蓄積を行うことができ、カルーセル回数内で受信に失敗した場合には、再放送時に取得可能である。この再放送日時の情報は、予め拡張EIT又はCST内に埋め込まれているために、受信装置2は、蓄積予約管理表の登録内容に従って自動的に再取得が可能である。
受信装置2は、蓄積が完了したコンテンツについては、蓄積予約管理表の登録を削除するとともに、蓄積コンテンツ管理表に登録して蓄積状況を管理する。例えば、コンテンツの蓄積が完了したら、蓄積コンテンツ管理表に登録し、蓄積予約管理表からマーキングを削除して再放送時の再取得を実行しないように制御する。更に、1サイクル(カルーセルサイクル)内で完全に蓄積できなかった場合は、次のサイクル(カルーセルサイクル)で再度取得する。ただし、蓄積できたデータ(DDB単位)は破棄せずに保存(一時保存)しておき、未取得DDBがある場合には当該コンテンツファイルのDDBの差分蓄積を実行する(ステップS17)。また、拡張EIT又はCST内の放送の持続時間(duration)の情報を利用して、蓄積未完了のまま当該サイクルの放送時間が終了した際に、再放送がある場合は予約蓄積の中断として判断し、再放送がない場合は予約蓄積の中止として判断する。
また、受信装置2は、ダウンロードID(downloadID)内のイベント識別子(event_id)と枝番が同一でデータイベント識別子(data_event_id)のみが更新されたコンテンツファイルの蓄積を行うときは、差し替えや上書き更新蓄積を行うことができる(ステップS18)。また、上書き更新コンテンツで同じシリーズに属するコンテンツが、既に蓄積されている場合には上書き更新を行い、そうでない場合はそのまま蓄積する。
受信装置2は、シリーズやジャンル別に蓄積したコンテンツの一覧表(蓄積コンテンツ管理表)を作成して、ユーザに提示可能にするのが好適である(ステップS19)。ユーザは、所定の操作で、蓄積コンテンツ管理表から不要なコンテンツを削除することもできる。シリーズのコンテンツで、放送間隔の短いものは、古いものから削除するように構成することができる。(シリーズ予約時にユーザに保存数や、上書きするか否かを指定することができる)また、シリーズ単位やカテゴリ単位で複数のコンテンツを1グループとしたパターンで蓄積することも可能である。
受信装置2は、ユーザの指定された蓄積済みのコンテンツについて再生可能である(ステップS20)。例えば、受信装置2が携帯電話機で構成される場合には、ユーザインターフェースを介して、画面に表示されるコンテンツのタイトルに含まれる複数のコンテンツを指定して、情報を得ることができる。当該コンテンツに映像、音声、データ放送、字幕のデータが関連付けられている場合には、これらのデータを再生することができる。例えば、コンテンツのデータ放送には、コンテンツのサムネイル画像を伝送して、受信装置2側で蓄積予約コンテンツ表の表示の際に利用可能することもできる。
このように、受信装置2は、送信される拡張EIT又はCSTを受信して、蓄積予約管理表を作成し、この蓄積予約管理表で蓄積予約の制御管理を行い、コンテンツを受信して自動蓄積する。特に、受信装置2が移動受信装置(例えば、携帯電話機)の場合、1回のカルーセル方式でコンテンツを完全に受信して蓄積しきれない場合も、放送局側送信装置1からの再放送のタイミングで再度の蓄積動作を自動的に行うことができる。
例えば、図10(a)は、番組スケジュールを構成するEPGやECGで、例えば番組「いつでもニュース」、「気象情報」及び「いつでもニュース」を順次配信する態様を例示している。拡張EIT又はCSTでは、「いつでもニュース」のコンテンツ情報である複数項目コンテンツを伝送する旨を示す番組スケジュールを伝送するため、受信装置2は、EPGやECGを構築することができる。本発明に係る送信装置1は、番組スケジュールテーブル(拡張EIT又はCST)を送信するとともに、拡張EIT又はCST[p/f]を送信することができる。また、本発明に係る送信装置1は、複数項目コンテンツの配信の場合には、図10(b)に示すように、ヘッダ部を構成するヘッダ情報(DII)内のダウンロードIDに記述したイベント識別子の枝番(ex_event_id)とバージョン情報(data_event_id)とを、「蓄積型リソースリスト」にも記述して、蓄積型リソースリストの情報と複数項目コンテンツの各項目のコンテンツをマルチパート化したデータブロックで送信する。蓄積型リソースリストの情報と、マルチパート化された各項目のコンテンツ(「ニュースA」、「ニュースB」、「ニュースC」及び「ニュースD」)を一つのモジュールとして伝送する。つまり、1つのモジュールを複数のパートに分割して伝送するため、受信装置2側では、複数項目コンテンツの各項目のコンテンツを受信して蓄積する際に、まず、DIIからイベント識別子を把握し、当該イベント識別子に関連付けられたデータブロックを全て取得し、取得したデータブロックから1つのモジュールを構築し、構築したモジュールに含まれる所定の蓄積型リソースリストから、当該複数項目コンテンツの各項目のコンテンツを識別するための枝番とバージョンを示す情報を抽出し、抽出した枝番とバージョンを示す情報に基づいて前記各項目のコンテンツ(「ニュースA」、「ニュースB」、「ニュースC」及び「ニュースD」)の蓄積を実行する。尚、各リソースごとにリソースヘッダが設けられ、「蓄積型リソースリスト」内の記述子タグ情報(descriptor_tag)と対応付けた番号を記載する。受信装置2は、ジャンル情報、又は階層的なジャンル情報としてのコンテンツニブルレベル1(Content_nibble_level1)とコンテンツニブルレベル2(content_nibble_level2)を含む場合には、各項目コンテンツのジャンルを把握することができる。
ここで、コンテンツ蓄積予約制御部29の構成及び動作について、図11及び図12を参照して更に詳細に説明する。
コンテンツ蓄積予約制御部29は、スケジュール情報取得部2901と、時刻情報処理部2902と、CST/EIT情報管理部2903と、蓄積予約制御部2904と、対応ファイル判定部2905と、イベント識別子判定処理部2906と、差分DDB判定処理部2907と、ダウンロードID判定処理部2908と、蓄積予約管理表生成部2909と、蓄積コンテンツ管理表生成部2910とを備える。
スケジュール情報取得部2901は、入力されるPSI/SI情報(即ち、EIT番組情報)から拡張EIT又はCSTのコンテンツスケジュール情報を抽出してCST/EIT情報管理部2903に送出する。
時刻情報処理部2902は、入力されるPSI/SI情報(即ち、EIT番組情報)から各コンテンツの開始時刻、放送持続時間、及びコンテンツファイルを一意に表す「イベント識別子」を抽出してCST/EIT情報管理部2903に送出する。
CST/EIT情報管理部2903は、拡張EIT又はCSTのコンテンツスケジュール情報を基に、蓄積予約管理表生成部2909を機能させて蓄積予約管理表を生成して、コンテンツファイルを格納するコンテンツ蓄積部30に格納する機能と、対応ファイル判定部2905を機能させて拡張EIT又はCSTのコンテンツスケジュール情報から蓄積予約可能なファイルがあるか否かを判定させる機能と、蓄積予約制御部2904からの指示に応じて蓄積予約を行うコンテンツファイルについて蓄積予約管理表をマーキングする機能と、イベント識別子判定処理部2906を機能させてDII内の情報(イベント識別子、枝番、データイベント識別子)を判定させる機能と、差分DDB判定処理部2907を機能させて複数DDBで伝送されるコンテンツファイルについて未蓄積の差分のDDBを判定させ蓄積させる機能と、CST/拡張EIT−p/fを取得し、予約情報の変更の有無を確認し、変更があれば蓄積予約管理表を更新する機能とを有する。
蓄積予約制御部2904は、ユーザに提示された蓄積予約管理表について、ユーザによって指定されたコンテンツの蓄積の予約の制御をCST/EIT情報管理部2903に指示する機能を有する。
対応ファイル判定部2905は、拡張EIT又はCSTのコンテンツスケジュール情報から蓄積予約可能なファイルがあるか否かを判定する機能を有する。
イベント識別子判定処理部2906は、DII内のダウンロードIDにおけるイベント識別子(event_id)を判定し、且つイベント識別子(event_id)によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送識別子(file_delivery_descriptor)」内の「ファイル種別情報(file_type_value)」で識別する機能、コンテンツタイプを表す「コンテンツタイプ情報(content_type)」と、「イベント識別子(event_id)」と、コンテンツ情報としての「シリーズ記述子(series_id)」とを組み合わせて、コンテンツタイプごとの予約蓄積制御を行う機能を有する。また、イベント識別子判定処理部2906は、ダウンロードID(downloadID)内のイベント識別子(event_id)と枝番が同一でデータイベント識別子(data_event_id)のみが更新されたコンテンツファイル(つまり、ファイルバージョンが更新されたコンテンツファイル)が存在するか否かを判別し、存在する場合に差し替えや上書き蓄積を行う上書き蓄積判定部2906aを有する。また、上書き蓄積判定部2906aではコンテンツタイプ情報(content_type)から上書き更新コンテンツであるかどうかを判別し、上書き蓄積コンテンツの場合で同じシリーズに属するコンテンツが蓄積されている場合には上書き蓄積をする、蓄積されている同じシリーズに属するコンテンツがない場合はそのまま蓄積する。
差分DDB判定処理部2907は、蓄積できたデータ(DDB単位)は破棄せずに保存(一時保存)しておき、未取得DDBがある場合には当該コンテンツファイルのDDBの差分蓄積を実行する機能を有する。
ダウンロードID判定処理部2908は、蓄積予約を行うコンテンツファイルについてカルーセル処理部25から得られるDIIを取得してダウンロードID(downloadID)を抽出してイベント識別子判定処理部2906及び差分DDB判定処理部2907に送出する機能と、イベント識別子判定処理部2906からの指示に従って、当該拡張EITやCSTに対応するコンテンツファイルのDDBを取得及び蓄積を制御すべく制御信号をカルーセル処理部25に送出する機能を有する。また、ダウンロードID判定処理部2908は、差分DDB判定処理部2907からの指示に応じて複数DDBで伝送されるコンテンツファイルについて未蓄積の差分のDDBの取得及び蓄積を制御すべく制御信号をカルーセル処理部25に送出する機能を有する。
蓄積予約管理表生成部2909は、CST/EIT情報管理部2903の制御によって拡張EIT又はCSTのコンテンツスケジュール情報を基に蓄積予約管理表を生成する機能を有する。
蓄積コンテンツ管理表生成部2910は、CST/EIT情報管理部2903の制御によって、蓄積予約管理表に従って蓄積したコンテンツを管理するための蓄積コンテンツ管理表を生成する機能を有する。
図12は、コンテンツ蓄積予約制御部29の動作フローを示す図である。コンテンツ蓄積予約制御部29は、蓄積予約を実行するために、まず、受信して復号した拡張EIT又はCSTのコンテンツスケジュール情報をメモリに展開する(ステップS31)。続いて、コンテンツ蓄積予約制御部29は、対応ファイル判定部2905によって、蓄積予約可能なファイルがあるか否かを判定し、蓄積不能の情報は破棄する(ステップS32)。コンテンツ蓄積予約制御部29は、イベント識別子判定処理部2906によって、蓄積予約可能なコンテンツファイルについて、チャンネル種別をそれぞれサービスIDで、メインch1、独自ch1及び独自ch2のチャンネル別コンテンツを把握し、各チャンネルにおける時間軸方向の編成についてイベント識別子(event_id)で識別し、且つイベント識別子(event_id)によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送識別子(file_delivery_descriptor)」内の「ファイル種別情報(file_type_value)」で識別して、蓄積予約管理表生成部2909によって、蓄積予約管理表を生成してユーザに提示し、ユーザによる予約の設定、又は蓄積予約管理表の生成と同時に対応ファイルの自動予約の設定を行う(ステップS33,S34)。
続いて、コンテンツ蓄積予約制御部29は、時刻情報処理部2902にて取得したイベント識別子に基づいて蓄積予約時刻の数分前にCST/EIT情報管理部2903を起動させ(ステップS35)、CST/拡張EIT−p/fを取得し(ステップS36)、予約情報の変更の有無を確認し(ステップS37)、変更があれば蓄積予約管理表を更新する(ステップS37)。
続いて、コンテンツ蓄積予約制御部29は、イベント識別子判定処理部2906及びダウンロードID判定処理部2908によって、イベント識別子(event_id)に紐づくダウンロードID(downloadID)のDIIを取得し、上書き蓄積判定部2906aによって、イベント識別子(event_id)と「枝番」が同一でデータイベント識別子(data_event_id)が異なる蓄積済みコンテンツの有無を判別し(ステップS39)、有りの場合には、こらから受信するコンテンツを上書き蓄積するまたは差し替えると判断する(ステップS40)。
続いて、コンテンツ蓄積予約制御部29は、イベント識別子判定処理部2906及びダウンロードID判定処理部2908によって、イベント識別子(event_id)に紐づくダウンロードID(downloadID)のDIIを含むカルーセル方式のESを取得し(ステップS41)、DII内のダウンロードIDにおけるイベント識別子(event_id)を判定し、且つイベント識別子(event_id)によって識別されるコンテンツファイルの内容の種別を、「ファイル伝送識別子(file_delivery_descriptor)」内の「ファイル種別情報(file_type_value)」で識別する機能、コンテンツタイプを表す「コンテンツタイプ情報(content_type)」と、「イベント識別子(event_id)」と、シリーズ番組のコンテンツ情報を識別するための「シリーズ記述子(series_id)」とを組み合わせて、コンテンツタイプごとの予約蓄積制御を行ない、差分DDB判定処理部2907によって、DDBの蓄積を完了するまで実行し(ステップS42)、未完了である場合には、差分のDDBを取得して蓄積する(ステップS43)。ファイル種別情報で判別されるコンテンツファイルの内容の種別が、時間編成のコンテンツファイルのうち同一のコンテンツファイルのダウンロード放送が予定されているものである場合、CST又は拡張EITのイベント識別子(event_id)を、カルーセル方式のDII内のダウンロードID(downloadID)に関連付けておくことで、CST又は拡張EITのイベント識別子(event_id)ごとにDDBを特定し、同一ファイル名に対して上書き蓄積を行うことや、差分のDDB受信を行うことが可能となる。
コンテンツ蓄積予約制御部29は、蓄積が完了した場合には(ステップS44)、蓄積予約管理表から対応ファイルの予約制御の旨を削除し、蓄積コンテンツ管理表生成部2910によって、蓄積予約管理表に従って蓄積したコンテンツを管理するための蓄積コンテンツ管理表を生成して、コンテンツ蓄積部30に格納する。蓄積コンテンツ管理表は、ユーザの指示によって提示可能なテーブルである。
従って、コンテンツ蓄積予約制御部29は、ユーザによって指定されたコンテンツの蓄積予約を実行する際に、カルーセル伝送方式で伝送される「本放送(1回目の放送)」のコンテンツの取得と、カルーセル伝送方式で伝送される「再放送(2回目以降の放送)」のコンテンツの取得で、蓄積予約の動作を制御することができるだけでなく、コンテンツタイプを表す「コンテンツタイプ情報(content_type)」と、「イベント識別子(event_id)」と、コンテンツ情報としての「シリーズ記述子(series_id)」とを組み合わせて、コンテンツタイプごとの予約蓄積制御を行なうことができる。
ユーザによって、コンテンツ蓄積部30に記憶した蓄積コンテンツ管理表の読出しの指定が可能であり、コンテンツ蓄積部30に記憶したコンテンツは、蓄積コンテンツ一覧表示・再生指示部31によって、再生制御が為され、ユーザに対して提示させることができる。
このように、受信装置2は、コンテンツの蓄積予約(映像等の場合、予約録画を含む)に必要な情報を拡張EIT又はCSTから取得することができる。拡張EIT又はCSTには「ファイル伝送識別子(file_delivery_descriptor)」が追加され、さらに「ファイル伝送識別子(file_delivery_descriptor)」内の「ファイル種別情報(file_type_value)」でファイル種別を直ちに識別して、コンテンツの蓄積予約のための蓄積予約管理表を直ちに作成して、直ちにコンテンツ取得することもでき。このため、受信装置2の受信処理負担を軽減させ、且つ受信不良のリスクを軽減させると共に、受信不良で未取得のDDBのみを取得してコンテンツファイルを受信完了させることが可能となる。
さらに、「単発コンテンツ」、「シリーズコンテンツ」、「上書き更新コンテンツ」、「複数項目コンテンツ」のコンテンツタイプを、拡張EIT又はCSTに含まれる「コンテンツタイプ情報(content_type)」から識別し、コンテンツ情報としての「シリーズ記述子(series_id)」からシリーズ番組であるか否かを識別し、DIIに含まれる「イベント識別子(event_id)」と組み合わせて、コンテンツタイプに応じた予約蓄積制御を行なうことができるようになる。
以上のように、受信装置2は、蓄積予約に使用するために事前に拡張EIT又はCSTの情報を取得し、拡張EIT又はCSTに記述された、実際にダウンロード放送される時間情報や、「ファイル伝送識別子」からファイルの情報及びイベント識別子を識別して、これらの情報を元にダウンロードされるファイルが対応しているかどうかを判断した上で、さらに、コンテンツタイプに応じた蓄積予約を行うので、効率的なダウンロード放送の予約を行うことが可能となる。
また、データカルーセルの中の全てのDDBは、当該データカルーセルの中ではユニークなブロック番号を持つため、イベント識別子(event_id)毎に、ユニークなDDBを受信装置2で管理することが可能であり、受信状態が不安定な場合でも、繰り返し送出されるデータカルーセルの中で、差分のDDBのみを取得することで効率的にファイルをダウンロード可能である。
以下、リアルタイム型放送に連動したダウンロードに関する、より具体的な例を示して、従来技術との相違点を説明する。受信装置側のダウンロード処理のやり方には、幾つかの態様が考えられる。
(EPGからのダウンロード予約による態様)
従来技術のように、ユーザによるボタン操作等により受信装置2にてEPGを起動すると、放送波で伝送されるSIにより、コンテンツのダウンロードの予約が可能なEPGが生成される。予約可能なコンテンツの一覧が表示され、ユーザがコンテンツを選択すると、EPGはダウンロードの制御のための情報をダウンローダに渡す。ダウンローダはダウンロードの制御情報を解析し、記載された放送スケジュールが到来するまで待機する。
(BMLブラウサからのダウンロード予約による態様)
従来から知られるように、ユーザによるボタン操作等により受信装置2にてBMLブラウザを起動すると、データカルーセルから取得したBML コンテンツを提示し、BMLコンテンツにより、コンテンツ検索の機能が提供される。ユーザによる検索の結果、選択したコンテンツに対しダウンロード実行を指示すると、ダウンロードの制御のための情報がダウンローダに渡される。ダウンローダはダウンロードの制御情報を解析し、記載された放送スケジュールが到来するまで待機する。
(通信ブラウザからのダウンロード予約による態様)
従来から知られるように、ユーザによるボタン操作等により受信装置2(ネットワーク通信機能を搭載する受信装置)にて通信ブラウザを起動すると、通信で伝送される情報により、コンテンツのダウンロードの予約が可能な画面が生成される。予約可能なコンテンツの一覧が表示され、ユーザがコンテンツを選択すると、ダウンロードの制御のための情報がダウンローダに渡される。ダウンローダはダウンロードの制御情報を解析し、記載された放送スケジュールが到来するまで待機する。
(ダウンロードのための情報取得による態様)
本発明に係る受信装置2のように、コンテンツをダウンロードするための情報を放送波からSI処理により取得する。取得する情報は現行のイベント情報テーブルEIT(Event Information Table)をベースとする拡張EITを用いる方式、及びコンテンツスケジュールテーブルCST(Contents Schedule Table)による方式とすることができる。
(リアルタイム型放送に連動したダウンロード)
本発明に係る受信装置2のように、ユーザによるボタン操作等により受信装置2にてリアルタイム型放送に連動したコンテンツのダウンロードを選択すると、ユーザのリアルタイム型放送視聴時に、バックグラウンドでコンテンツのダウンロードが自動的に行われる。
より具体的には、ダウンロードの予約について、拡張EITやCSTにより生成されるEPGによる予約、BMLコンテンツによる予約、通信で取得する情報により生成される画面による予約などがあるが、マルチメディア放送ではこれらの事前予約に加え、リアルタイム型放送に連動したダウンロードも可能とする。
リアルタイム型放送に連動したコンテンツのダウンロードでは、ユーザのリアルタイム放送視聴時に、バックグラウンドでコンテンツのダウンロードが自動的に行われる。リアルタイム型放送コンテンツと連動するダウンロード型放送コンテンツの関係の例を図15に示す。
図15に示すように、リアルタイム放送のコンテンツと連動ダウンロードのコンテンツは同一のTS内で送出されるとともに、異なるサービスIDで送出される。お互いのサービスはサービスグループ識別子(service_group_descriptor)でグルーピングされ、リアルタイム型がプライマリ(Primary)、ダウンロード型がセカンダリ(Secondary)とする。
サービスグループ識別子(service_group_descriptor)を図16に示す。サービスグループ識別子内のサービスグループ種別(service_group_type)にはマルチメディア放送における連動を示す値(例えば、「0x2」)が用いられ、primary_service_idにはリアルタイム型放送のサービスID、secondary_service_idには連動するダウンロード型放送のサービスIDを用いる。このサービスグループ識別子はNIT(Network Information Table、例えば、第2ループ)で送出することができる。
1つのプライマリサービスに対して、グルーピングが行われるセカンダリサービスは1つであり、1つのリアルタイム型コンテンツに対して、連動ダウンロード型コンテンツは、同一時刻に2つ以上送出されないものとする。例えば図15に示す例の場合、リアルタイム型コンテンツ(1)に対して、連動コンテンツ(連動−1)と(連動−1)が各々2回、別々の時刻に送出される。また、リアルタイム型コンテンツ(3)のように、連動するダウンロード型コンテンツが送出されない場合もあることになる。
リアルタイム型コンテンツのevent_id値と、連動するダウンロード型コンテンツのevent_id値は独立しており、event間の紐付け情報は存在しない。そのため、受信装置2はリアルタイム型放送のサービスIDに連動するサービスIDが存在するか否かをNITで確認した後、連動サービスIDがある場合は、セカンダリの拡張EIT[p/f](又はCST)を参照して、連動コンテンツの有無を確認し、連動コンテンツが存在する場合にダウンロードを行うものとする。
この受信装置2の動作例を図17に示す。なお、図17はあくまで動作例であり、受信装置の動作を拘束するものではない。図17において、受信装置2は、OFDM復調部20によって、リアルタイムチャンネルの選局処理を実行後、一定時間(1分程度を想定)の待機処理を行ない、視聴者の頻繁なチャンネル切り替え(ザッピング等)に対応する(ステップS101〜S103)。受信装置2は、SI処理部28によって、セカンダリサービスの有無を、リアルタイム型放送のサービスIDに連動するサービスIDが存在するか否かの判定により行い(ステップS105)、セカンダリが有り(連動するダウンロード放送が有り)と判断した場合に、コンテンツ蓄積予約制御部29により、対応する拡張EIT[p/f]を取得して確認し(ステップS106)、連動コンテンツの有無を確認し(ステップS107)、ユーザが設定する自動ダウンロード実行のON/OFFにしたがって、連動コンテンツが存在する場合にダウンロードを行う(ステップS108,S109,S110,S112)。また、自動ダウンロード実行のON/OFFは、ユーザがリアルタイムチャンネル毎に設定することが想定されるが、その実装方法については適宜定めるものとする。ダウンロード中に、OFDM復調部20によってチャンネル切り替えを検出した場合には(ステップS111)、ダウンロードの継続の有無を確認して、ダウンロード中の蓄積制御を実行するように構成することもできる(ステップS111,S113〜S115)。
バックグラウンドでの自動ダウンロードの実行中に、リアルタイムチャンネルの変更が行われた場合、チャンネルを切り替える前に、ダウンロードを中断するか否かの確認を行うことが望ましい。
なお、連動ダウンロードコンテンツのevent_id、ex_event_id、data_event_idの扱いは非連動に同じであり、file_type_value、content_type_valueの扱いも非連動に同じであるが、常時更新コンテンツ(contetn_type_value2 = ’0x2’)については、非連動のみで送出されるものとする。また、連動ダウンロードコンテンツも非連動ダウンロードコンテンツの場合と同様に、拡張EIT、CSTが送出され、EPG等から事前にダウンロードの予約も可能である。
尚、content_type_value3に新たな種別を用意し、放送局側で連動ダウンロードコンテンツをEPG等からダウンロードすることができないようにすることもできる。具体的には、content_type_value3=0x2として拡張EITやCSTを送出し、受信装置はこのコンテンツをEPGなどには表示せず、受信装置でのコンテンツ検索結果に含めないことで、ユーザの操作によりコンテンツのダウンロードができないようにする。
また、先に述べた補足情報について、リアルタイム型放送に連動したダウンロードコンテンツとして、リアルタイムのコンテンツを補足する情報として送信する態様も考えられる。この場合、補足情報はリアルタイム型放送とサービスグループを組んだセカンダリのサービスIDで伝送する。送られる情報は同一時刻に送出されているリアルタイム型コンテンツに関するものに限定され、同じ内容がカルーセル伝送により、繰り返し送出されるものとする。
上述したように、リアルタイム放送の場合、download_idは28bit〜31bitにdata_event_idの値を埋め込んでいるが、それ以外のbitは全て“1”で使用していない。ダウンロード放送の場合、data_event_idに加え、0bit〜15bit目までにevent_id、16bit〜27bit目までにex_event_idが埋め込まれる。各DDBメッセージのヘッダ部分にはDIIと同じ値のdownload_idが記載されているため、event_idやex_event_idごとに、DDBブロックをユニークに特定できるようになり、差分受信が可能となる。また、data_event_idの4bitを更新情報とすることで、ダウンロードコンテンツのバージョン管理が可能となる。
例えば、交通情報など、常に最新情報を受信するような受信装置2においては、ダウンロードされるファイルの更新情報を常に監視し、情報が更新された場合は蓄積受信を行い、情報の上書き更新を行う必要がある。ダウンロードサービスにおいて、DIIやDDBのdownload_idの中に埋め込まれるdata_event_idの4bitを更新情報として用いることで、受信装置2はファイルの上書き更新が可能となる。なお、補足情報についてはdownload_idが固定値であり、差分受信は行わないものとする。
一方、ダウンロードサービスにおいては、受信側で欠損データの補完を可能とするために、同じ内容のコンテンツが連続、または一定時間経過後に複数回送信される運用が想定され、同一のevent_idが異なる時間に送出されるケースが出てくる。また、ニュースのように、同一のevent_idを用いて項目が更新される(ex_event_idが更新される)コンテンツや、交通情報のように常時更新されるコンテンツをダウンロードするケースも想定される。また、event_idの値は、ダウンロード予約に必要となるCSTに、最初の送出開始時刻の所定日前(例えば、8日前)以降に記載されることから、一定期間の間はコンテンツを一意に識別可能とするために、再送信、項目更新、常時更新、及び補足情報の送信の場合を除きevent_idの値はユニークに保たれる必要がある。
そこで、表8に示すように、一般的なコンテンツで同一のevent_idが使用されるケースは、同一コンテンツの再送信(data_event_id値が異なるコンテンツの再送信も含まれる)の場合に限定される。
本発明のリアルタイム型放送に連動したダウンロードにおける具体的な効果として従来技術と対比すると、例えば、図18に示す従来の態様では、送信側では、リアルタイム型放送について、映像音声に連動して字幕をPESで送出し、受信側では、映像音声に連動して字幕を表示するものであった。この場合、字幕のみの情報を効率的に受信することができない字幕のみの情報を知りたい場合や、当該リアルタイム放送のコンテンツを蓄積したい場合、コンテンツファイル全体を取得するには、EPGの蓄積予約に基づく蓄積が必要であった。
一方、図19に示すように、本発明に係るリアルタイム型放送に連動したダウンロードでは、リアルタイム型放送に連動するコンテンツとして例えば字幕をテキスト情報に変換して補足情報として送出することで、補足情報の情報量は少ないので、番組の時間内で、同内容の補足情報を何度も再送可能であることや、受信不良時の取りこぼしを防止することができ、従来の問題を解決することができる。さらに、リアルタイム型放送のコンテンツに連動したダウンロード放送のコンテンツを、リアルタイム型放送のコンテンツ自体の動画ファイルやPDFファイル或いは商業的情報ファイルとして自動蓄積することで、リアルタイム型放送のコンテンツの視聴に伴い、あわててダウンロード蓄積を行なうユーザ操作を不要にすることができるため、様々な用途に利用できるようになる。
更に、本発明の一態様として、コンテンツ蓄積予約制御部をコンピュータとして構成させることができる。コンピュータに、前述したコンテンツ蓄積予約制御部を実現させるためのプログラムは、コンピュータの内部又は外部に備えられる記憶部(メモリ)に記憶される。そのような記憶部は、外付けハードディスクなどの外部記憶装置、或いはROM又はRAMなどの内部記憶装置で実現することができる。コンピュータに備えられる制御部は、中央演算処理装置(CPU)などの制御で実現することができる。即ち、CPUが、各構成要素の機能を実現するための処理内容が記述されたプログラムを、適宜、記憶部から読み込んで、各構成要素の機能をコンピュータ上で実現させることができる。ここで、各構成要素の機能をハードウェアの一部で実現してもよい。
また、この処理内容を記述したプログラムを、例えばDVD又はCD−ROMなどの可搬型記録媒体の販売、譲渡、貸与等により流通させることができるほか、そのようなプログラムを、例えばネットワーク上にあるサーバの記憶部に記憶しておき、ネットワークを介してサーバから他のコンピュータにそのプログラムを転送することにより、流通させることができる。
また、そのようなプログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラム又はサーバから転送されたプログラムを、一旦、自己の記憶部に記憶することができる。また、このプログラムの別の実施態様として、コンピュータが可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することとしてもよく、更に、このコンピュータにサーバからプログラムが転送される度に、逐次、受け取ったプログラムに従った処理を実行することとしてもよい。