JP4184374B2 - 受信機及び受信方法 - Google Patents
受信機及び受信方法 Download PDFInfo
- Publication number
- JP4184374B2 JP4184374B2 JP2005312442A JP2005312442A JP4184374B2 JP 4184374 B2 JP4184374 B2 JP 4184374B2 JP 2005312442 A JP2005312442 A JP 2005312442A JP 2005312442 A JP2005312442 A JP 2005312442A JP 4184374 B2 JP4184374 B2 JP 4184374B2
- Authority
- JP
- Japan
- Prior art keywords
- content
- information
- version
- file
- difference
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Circuits Of Receivers In General (AREA)
Description
この発明はデジタル放送におけるデータ放送に関するもので、コンテンツを構成するモノメディアデータをファイルとして統一的に扱うことにより、オーサリングツールに依存しないモノメディアデータの配信や、受信機に蓄えられたモノメディアデータの自動更新を可能とした受信機及び受信方法に関するものである。
従来のデータ放送分野におけるサービス、伝送プロトコルについて説明する。データ放送は、放送番組以外のコンテンツを放送を使って受信機に配信するものであり、サービス例としてはホームページ配信や電子新聞などが挙げられる。アナログ放送では既にいくつかの放送局でホームページ配信サービスや、専用受信機を使った情報提供サービスが始まっている。また、データ放送で配信されるマルチメディアアプリケーション（以下MMアプリケーションと略記）の制作方法はJava（登録商標）、HTML、MHEGなど選択肢が多いのが現状である。
また、デジタル放送におけるデータ伝送プロトコルの従来の技術としては、ISO13818-6で規定されたDSM-CCデータカルーセル（以下、データカルーセルと略記）がある。データカルーセルはデータをモジュールという論理的な単位でグループ化し、それをブロックという物理的な伝送単位で繰り返し伝送する。受信側ではブロック単位で受信し、これを組み立てモジュールを再構築する。データカルーセルではこのような伝送方式を実現するためにDownloadDataIndication（以下DIIと略記）, DownloadDataBlock（以下DDBと略記）の２つのテーブルを定義しており、DIIではモジュールIDとモジュールの実体を運ぶDDBへのポインタを持つ。伝送されるモジュールは一定サイズ（ブロックサイズ）で分割され、DDBに詰め込まれ伝送される。DDBは何度も繰り返し送出される。図２５にISO13818-6で規定されたDII，DDBのテーブル間の関係を示す。DDBのtable＿id＿extensionとしてモジュールを識別するmoduleIDが使われるので、データカルーセルでは、受信機がmoduleIDでフィルタリングすることにより、モジュール単位でデータを受信することが容易に可能である。（例えば、特許文献１参照）。
特開平１１−２８８２２７号公報
しかしながら、従来のデータ放送方式ではプラットフォームが共通化されていないため、受信機側で、それぞれ専用の受信機を用意しなければならなかった。
また、従来のホームページ配信のような方式ではMMアプリケーションと放送番組をリンク付ける方式がないため、放送番組とリンクしたMMアプリケーションを作成できないという課題があった。
また、データカルーセル方式だけでは受信機に対し、どのモジュールを取ればいいかをセンターから指示することができないので、受信機が配信されるデータの中から必要なデータだけを受信するという効率的なコンテンツの差分配信を行うことが困難であるという課題があった。
また、受信機のフィルタリングの単位がモジュールであるため、受信機が、モジュールの中の特定のデータだけを効率良く取得することができないという課題があった。実際、DIIは１セクションで送られるため、最大１００個くらいのモジュールしか送ることができない。これは将来のデータ放送を考慮すると転送するデータサイズに比べて小さすぎる。しかしながら１モジュールの最大サイズは２５６Ｍバイトであり、これは将来的にもデータ放送では十分な大きさである。従って、モジュールより小さい単位でのフィルタリングが可能となれば伝送プロトコルとしてDII、DDBだけでも十分実用的なデータ放送が実現可能となるはずである。
本発明は、上記従来の課題に鑑みてなされたもので、その目的は、デジタルデータ放送を行なう放送局システムにおいて、コンテンツを構成するモノメディアデータをファイルとして統一的に扱うことにより、オーサリングツールに依存しないコンテンツの配信方式を確立し、放送データとして受信され、受信機に蓄えられたモノメディアデータの自動更新を可能とした受信機及び受信方法を提供することである。
本発明における放送局システムは、オーサリングツールにより作成されたコンテンツを格納するコンテンツDBと、コンテンツを配信するスケジュールを策定する配信スケジュール作成部と、放送番組の放送時間を管理する番組編成管理部とコンテンツ配信サービスに関する番組付加情報（SI情報）を生成するSI生成部とコンテンツ伝送プロトコル生成部と受信機がコンテンツの取得および自動更新を行なう際に利用するコンテンツ配信に関する情報を生成するコンテンツ配信情報生成部と、生成した情報を送出する送出装置から構成されるセンターシステム（放送局）と、放送局より放送されるデータを受信する受信部と放送されているデータのうち、受信機に取り込むものだけを選択して取り込むフィルタリング機能でとコンテンツの自動更新処理を実行するファイル更新管理機能と、指定された時間になったことを知らせるタイマー予約機能と、伝送フォーマットで送られたファイルを伝送フォーマットから元のファイルフォーマットに変換し、これを蓄積装置に蓄積するファイル蓄積管理機能と、ファイル名とファイルの所在の関係を管理し、上位アプリケーションに汎用的なインタフェースを提供するファイル名称管理機能から構成される受信機により、コンテンツを構成するデータをファイル単位で伝送し、受信機側ではファイルとしてモノメディアデータにアクセスするインタフェースを設けることによりオーサリングツールに依存しないコンテンツ配信方式を可能としたものである。
また、コンテンツ配信情報テーブルにより、コンテンツを更新する時刻を受信機に事前に知らせることにより、コンテンツの自動更新を可能としたものであり、この方式は省電力に対応可能である。さらに、放送番組とリンクするために必要な情報をファイルとして定義することにより、受信機上のMMアプリケーションから放送番組を簡単にリンクすることが可能である。さらに、データカルーセルプロトコルをコンテンツの伝送プロトコルとして使う場合、コンテンツ配信情報テーブルでモジュール単位の更新かファイル単位の更新かを事前に受信機に知らせ、モジュール単位の更新の場合は更新するモジュールIDをコンテンツ配信情報テーブルに付加し、ファイル単位の更新の場合はDIIにファイル更新情報を付加することにより、受信機は必要なモジュールだけを受信したり、必要なファイルだけを受信したりすることが可能である。
本発明の請求項１に記載の発明は、バージョンが付与されたコンテンツがどのバージョンとの差分であるかを示す差分情報と、その差分情報が特定のバージョンに限定された差分情報であるか、そのバージョン以降であればどのバージョンでも適用できる差分情報であるかを示す差分付加情報と、当該コンテンツの配信スケジュールと、を含むスケジュール情報を放送局システムから受信する受信部と、前記スケジュール情報を用いて、受信した前記コンテンツの蓄積を制御するファイル更新管理機能とを備え、前記ファイル更新管理機能は、前記差分付加情報に基づいて、前記スケジュール情報の差分情報の示すコンテンツバージョンとすでに蓄積済みのコンテンツのバージョンとが一致するか、あるいは、蓄積済みのコンテンツのバージョンが前記差分情報の示すコンテンツのバージョンを適用できる特定バージョン以降のものであるかを判断し、前記スケジュール情報の差分情報の示すコンテンツのバージョンとすでに蓄積済みのコンテンツのバージョンとが一致する場合は、前記すでに蓄積済みのコンテンツを前記スケジュール情報に従って受信したコンテンツで更新し、蓄積済みのコンテンツのバージョンが前記差分情報の示すコンテンツのバージョンを適用できる特定バージョン以降のものである場合は、前記すでに蓄積済みの特定のバージョン以降のコンテンツを前記スケジュール情報に従って受信したコンテンツで更新する、ことを特徴とする受信機であり、受信した差分情報および差分付加情報を調べることにより、差分情報が特定のバージョンに限定された差分情報であるか、そのバージョン以降のものであればどのバージョンでも適応できる差分情報であるかを判断して受信機側で管理しているコンテンツに適応できるかどうかを判定でき、それぞれに対応して、配信された特定のバージョンに対して更新するか、あるいは特定のバージョン以降のコンテンツを更新するかを制御でき、さらに伝送すべき差分情報を圧縮することが可能になるという作用を有する。
本発明の請求項２に記載の発明は、バージョンが付与されたコンテンツがどのバージョンとの差分であるかを示す差分情報と、その差分情報が特定のバージョンに限定された差分情報であるか、そのバージョン以降であればどのバージョンでも適用できる差分情報であるかを示す差分付加情報と、当該コンテンツの配信スケジュールと、を含むスケジュール情報を放送局システムから受信するステップと、前記スケジュール情報の差分付加情報に基づいて、前記スケジュール情報の差分情報の示すコンテンツのバージョンとすでに蓄積済みのコンテンツのバージョンとが一致するか、あるいは、蓄積済みのコンテンツのバージョンが前記差分情報の示すコンテンツのバージョンを適用できる特定バージョン以降のものであるかを判断するステップと、前記スケジュール情報の差分情報の示すコンテンツのバージョンとすでに蓄積済みのコンテンツのバージョンとが一致する場合は、前記すでに蓄積済みのコンテンツを前記スケジュール情報に従って受信したコンテンツで更新するステップと、蓄積済みのコンテンツのバージョンが前記差分情報の示すコンテンツのバージョンを適用できる特定バージョン以降のものである場合は、前記すでに蓄積済みの特定のバージョン以降のコンテンツを前記スケジュール情報に従って受信したコンテンツで更新するステップと、を有する受信方法であり、受信した差分情報および差分付加情報を調べることにより、差分情報が特定のバージョンに限定された差分情報であるか、そのバージョン以降のものであればどのバージョンでも適応できる差分情報であるかを判断して受信機側で管理しているコンテンツに適応できるかどうかを判定でき、それぞれに対応して、配信された特定のバージョンに対して更新するか、あるいは特定のバージョン以降のコンテンツを更新するかを制御でき、さらに伝送すべき差分情報を圧縮することが可能になる。
本発明は、バージョンが付与されたコンテンツがどのバージョンとの差分であるかを示す差分情報と当該コンテンツの配信スケジュールとを含むスケジュール情報を放送局システムから受信し、このスケジュール情報の差分情報とすでに蓄積済みのコンテンツのバージョンとが一致した場合に、すでに蓄積済みのコンテンツを受信したコンテンツで更新することを特徴とする受信機であり、受信した差分情報を調べることにより、受信機は自己が管理しているコンテンツに対する差分情報であるかどうかを判断することができるので、自動的に新しいバージョンのコンテンツに更新することができるという効果を有する。
以下、本発明の種々の実施の形態について図面を参照して説明する。
（実施の形態１）
本発明のコンテンツ配信システムが扱うコンテンツは特定のオーサリングツールに依存するものではなく広く一般的なコンテンツを対象としている。システムの実施の形態について述べる前に一般的なコンテンツの構造について説明する。
（実施の形態１）
本発明のコンテンツ配信システムが扱うコンテンツは特定のオーサリングツールに依存するものではなく広く一般的なコンテンツを対象としている。システムの実施の形態について述べる前に一般的なコンテンツの構造について説明する。
コンテンツは一般に複数のモノメディアファイルから構成される。モノメディアファイルとは、コンテンツを構成するテキストデータや、静止画データなどのモノメディアを、媒体を使って移動可能なようにファイル化したものであり、オーサリングツールの出力である。コンテンツはマルチメディアプレイヤ（以下MMプレイヤと略記）により再生される。その際、MMプレイヤはファイルを識別するためにファイル名を用いてファイルにアクセスする。放送の場合、MMプレイヤは受信機上に存在する。
ここでは説明の便宜上、配信するコンテンツの例として「いつでも天気」というアプリケーションを配信する場合について述べる。「いつでも天気」は受信機に蓄積されたコンテンツを利用するアプリケーションであり、いつでも最新の天気を知ることができるアプリケーションである。
図２は本実施の形態において、「いつでも天気」のアプリケーションが作動することにより表示される画面イメージを示す。「いつでも天気」は例えば、或る特定の地域（例えば、関東地方）を表す地図と気象情報を表すテキスト、見たい地域を選択するボタンから構成され、視聴者は見たい地域のボタンを押すと最新の気象情報を得ることができるというものである（気象情報は定期的に更新される。ここでは例として３０分おきに書き換わるものとする）。
図３はコンテンツの一般的な構成を示す例である。コンテンツは静止画ファイル、テキストファイル、MMプレイヤがコンテンツを再生するために必要なスクリプトなどのモノメディアファイルから構成される。図３では「いつでも天気」の例として、気象情報を表す地図やボタンなどの画像（ビットマップファイル）、気象情報を表すテキスト（テキストファイル）、視聴者が画面上のボタンを押したときの処理を記述したスクリプトをコンテンツの構成とし、それぞれのファイルは受信機上のMMプレイヤが再生の際、MMプレイヤがアクセスする為に必要なファイル名が付けられている。また、コンテンツにはそのコンテンツを表すタイトル名が付けられる。ファイル名、タイトル名はオーサリングツールを用いて、コンテンツ作成者、またはオーサリングツールが自動的に命名する。
本発明はこのようなタイトル名、ファイル名を持つ複数のファイルから構成される一般的なコンテンツを対象とした配信システムである。
図１はコンテンツ配信センターシステムの一形態を示すブロック図である。図１において、符号１０１はオーサリングツールであり、これは上述のような一般的なコンテンツを作成するものである。１０２はオーサリングツールにより作成されたコンテンツを格納するコンテンツDB（データベース）である。１０３はコンテンツを配信するスケジュールを策定する配信スケジュール作成部である。ここで作成されたスケジュールに従い、コンテンツはセンターから配信される。１０４は番組び編成を管理する番組編成管理部である。コンテンツ配信は番組の一種として番組編成管理部１０４に管理される。番組編成管理部１０４は１０５のSI生成部を使って、コンテンツ配信サービスに関する番組付加情報（SI情報）を生成する。１０６はコンテンツ伝送プロトコル生成部であり、コンテンツを配信できるフォーマットに変換する。１０７はコンテンツ配信情報生成部であり、受信機に放送するコンテンツ配信に関する情報を生成する。この情報は受信機がコンテンツの取得および自動更新を行なう際に利用されるものである。１０８は送出装置であり、SI生成部１０５、コンテンツ伝送プロトコル生成部１０６、コンテンツ配信情報生成部１０７が生成した情報を受信機に対して送出する。
図４はコンテンツDB１０２が管理するコンテンツ管理表の例である。タイトル４１は、オーサリングツール１０１が作成したコンテンツを識別するために付ける名前である。タイトルの例としては「いつでも天気」がある。コンテンツID４２はコンテンツDB１０２がコンテンツに対して一意に割り当てる識別子であり、コンテンツ配信システムではこのコンテンツID４２によりコンテンツを識別する。コンテンツバージョン４３はコンテンツのバージョンであり、コンテンツDB１０２により管理される。このコンテンツバージョン４３はオーサリングツール１０１が同じタイトルのコンテンツを再登録するたびにコンテンツDB１０２により更新される。ファイル名４４はモノメディアファイルの名前であり、オーサリングツール１０１により付けられるファイル名である。この名前はMMプレイヤがコンテンツを再生する際に使われるものである。ファイルバージョン４５はファイルのバージョンであり、これもコンテンツバージョン４３と同様にコンテンツDB１０２により管理される。コンテンツDB１０２はコンテンツID４２、ファイル名４４、ファイルバージョン４５をキーとして、ファイル実体を取得できるように、ファイル実体を格納する。日付４６はファイルが格納または更新された日時である。ファイルサイズ４７は格納するファイルの大きさである。ファイルサイズ４７はファイル実体をコンテンツDB１０２が格納する際、コンテンツDB１０２がサイズを計り登録する。
図４の例ではアプリケーション「いつでも天気」の２つのバージョンが登録されている。コンテンツを構成するファイルが１つでも更新されると（「いつでも天気」の場合、気象情報は３０分ごとに更新される）、コンテンツのバージョンもあがる。
オーサリングツール１０１はコンテンツのタイトル名４１とコンテンツを構成するファイルとそのファイル名４４のリストをパラメータとしてコンテンツDB１０２にコンテンツの登録を行なう。オーサリングツール１０１があるコンテンツを初めて登録する場合は、コンテンツを構成する全てのファイルとファイル名のリストをパラメータとしなければならない。オーサリングツール１０１が既に登録してあるコンテンツを変更する場合は変更したファイルとファイル名のリストをパラメータとする（変更していないファイルはリストには含まない）。例えば、「いつでも天気」の場合、ボタンなどの基本的なビットマップ画像ファイルは変更されないが、最新の気象情報が書かれたテキストファイルは頻繁に更新される。最初に「いつでも天気」を登録するときはビットマップ画像ファイルを含めた全てのファイルを登録するが、オーサリングツール１０１はそれ以降の更新に関しては、気象情報が書かれたテキストファイルの名前と実体だけをコンテンツDB１０２に登録すればよい。コンテンツDB１０２はコンテンツを更新する場合、前に登録したコンテンツの内容と更新内容をマージし、コンテンツバージョン４３と更新したファイルバージョン４５を更新し、新バージョンとして登録する。日付４６はファイルを格納した日付であるので更新したファイルだけが新しい日付となる。図４の例の「いつでも天気」のバージョン２では、気象情報を表すTokyo.txt, Chiba.txtは更新されたため、日付が新しくなっているがButton10.scriptは更新されていないので日付は以前のままになっている。
コンテンツを構成するあるファイルを削除する場合は、登録パラメータに、削除を表すコマンド名と削除するファイル名のリストを付加する。コンテンツDB１０２は削除コマンドを受けるとそのファイル名に対応するファイルを除外し、前に登録したコンテンツの内容と更新内容をマージする。
このようにオーサリングツール１０１とコンテンツDB１０２とのインタフェースは、タイトル名とそのコンテンツを構成するファイルとそのファイル名のリストをパラメータとした汎用的なものであり、オーサリングツールに依存しない。「いつでも天気」が３０分ごとに最新の天気を放送する場合、コンテンツ管理表には図４に示すように３０分おきに新しいコンテンツバージョン４３が生成され、最新の気象情報が書かれたテキストファイルのみが更新される。
番組編成管理部１０４は、放送番組の編成情報と物理的な送出情報を管理する。編成情報とは、放送番組が放送されるスケジュールや放送されるチャンネルに関する情報である。ETS 300 468「Digital Video Broadcasting(DVB); Specification for Service Information(SI) in DVB systems」では放送チャンネルはservice＿idという識別子で識別する。物理的な送出情報とは、MPEG２トランスポートストリームで放送する際に必要なPSIを構成するための情報で、トランスポンダの識別子（TS＿id）、送出ストリームのPIDで構成される。番組編成管理部１０４はコンテンツ配信のための放送時間帯（何時から何時までの時間帯にコンテンツ配信を行うかという情報）、チャンネル、PIDを割当て、これを配信スケジュール作成部１０３に通知する。放送時間帯の中でどのようなスケジュールでコンテンツの配信を実行するかは配信スケジュール作成部１０３が決定する。
図５は配信スケジュール作成部１０３が管理するコンテンツスケジュール表である。５１はコンテンツを識別するコンテンツID、５２はコンテンツバージョン、５３はコンテンツを配信する時間すなわち配信スケジュール、５４はコンテンツを放送を用いて配信するために必要なPSI（Program Specific Information ISO13818-1で規定）生成のための情報、５５はコンテンツを配信する際、コンテンツを構成する全てのファイルを配信するか、更新されたファイルのみを配信するかを指し示す更新フラグ、５６はコンテンツ配信の伝送速度、５７はコンテンツを放送を使って配信するときのservice＿id（SI情報：チャンネル識別子）である。運用者は番組編成管理部１０４より取得した番組編成情報から、配信スケジュール５３、PSI情報５４、伝送速度５６、service＿id５７を決定する。コンテンツスケジュール表は図示されない放送局の操作端末により、配信スケジュール作成部１０３に入力されたデータをもとに作成される。
図５は「いつでも天気」アプリケーションに関するコンテンツスケジュール表である。ここでは例として、１０分おきにコンテンツ配信を１０分間行い、３０分おきに最新の天気に更新するような配信スケジュールとしている。また、配信スケジュールとしては、更新フラグを使うことにより、X回ごとに全部配信し、その間は差分しか配信しない運用も考えられる。たとえば「いつでも天気」を１時間に３回配信し、６回ごとに全部配信するが、後は変更ファイルのみの差分配信とすることも可能である。この場合、受信機は「いつでも天気」アプリケーションを全部取得するのに最悪２時間近く待たなければならないが、そのかわり、いったん取得してしまえば、差分ファイル配信により、受信機に蓄積したファイルを効率的に書き換えることができる。
図６のフローチャートを用いてコンテンツ伝送プロトコル生成部１０６がコンテンツ伝送用データフォーマットを作成するときの処理について説明する。ここではあるコンテンツ（コンテンツID、コンテンツバージョンで識別）を構成するファイル群を伝送フォーマット化するときの処理について述べる。
（ステップ６１） コンテンツID、コンテンツバージョンを使って配信スケジュール作成部１０３のコンテンツスケジュール表から配信スケジュール情報を取得する。
（ステップ６２） コンテンツDB１０２が管理するコンテンツ管理表から、コンテンツID、コンテンツバージョンでコンテンツを構成する配信ファイルリスト（ファイル名、ファイルバージョン、ファイル実体、日付を要素とするリスト）を取得する。
（ステップ６３） コンテンツスケジュール表の 送出の種類が「全部」か「差分」かをチェックする。「全部」の場合はステップ６５へとぶ。
（ステップ６４） 送出の種類が「差分」の場合、ステップ７２で取得した配信ファイルリスト内にあるファイルのバージョンと、前バージョン（コンテンツ伝送プロトコル生成部１０６が最近送ったバージョン）のコンテンツを構成するファイルのバージョンを比較し、バージョンが異なるファイルだけを取り出して新たに配信ファイルリスト（ファイル名、ファイルバージョン、ファイル実体、日付を要素とするリスト）を生成する。コンテンツ伝送プロトコル生成部１０６はそれぞれのコンテンツの送出ログを持っており、最近送ったバージョンは何かということを管理している。
（ステップ６５） 配信ファイルリストを、コンテンツスケジュール表のPSI情報、伝送速度を用いて、伝送フォーマットに変換する。データ伝送用のフォーマットしてはDVB SI-DATで検討が進められており、DSM-CCデータカルーセル（ISO１３８１８ー６）、オブジェクトカルーセル（ISO１３８１８ー６）などがある。
（ステップ６６）伝送フォーマットに変換した配信ファイルリスト（以下、配信ファイルリスト伝送フォーマットとよぶ）と、コンテンツスケジュール表に記述された対応する配信時間、伝送速度を送出装置１０８に渡す。
（ステップ６１） コンテンツID、コンテンツバージョンを使って配信スケジュール作成部１０３のコンテンツスケジュール表から配信スケジュール情報を取得する。
（ステップ６２） コンテンツDB１０２が管理するコンテンツ管理表から、コンテンツID、コンテンツバージョンでコンテンツを構成する配信ファイルリスト（ファイル名、ファイルバージョン、ファイル実体、日付を要素とするリスト）を取得する。
（ステップ６３） コンテンツスケジュール表の 送出の種類が「全部」か「差分」かをチェックする。「全部」の場合はステップ６５へとぶ。
（ステップ６４） 送出の種類が「差分」の場合、ステップ７２で取得した配信ファイルリスト内にあるファイルのバージョンと、前バージョン（コンテンツ伝送プロトコル生成部１０６が最近送ったバージョン）のコンテンツを構成するファイルのバージョンを比較し、バージョンが異なるファイルだけを取り出して新たに配信ファイルリスト（ファイル名、ファイルバージョン、ファイル実体、日付を要素とするリスト）を生成する。コンテンツ伝送プロトコル生成部１０６はそれぞれのコンテンツの送出ログを持っており、最近送ったバージョンは何かということを管理している。
（ステップ６５） 配信ファイルリストを、コンテンツスケジュール表のPSI情報、伝送速度を用いて、伝送フォーマットに変換する。データ伝送用のフォーマットしてはDVB SI-DATで検討が進められており、DSM-CCデータカルーセル（ISO１３８１８ー６）、オブジェクトカルーセル（ISO１３８１８ー６）などがある。
（ステップ６６）伝送フォーマットに変換した配信ファイルリスト（以下、配信ファイルリスト伝送フォーマットとよぶ）と、コンテンツスケジュール表に記述された対応する配信時間、伝送速度を送出装置１０８に渡す。
ステップ６６は送出装置１０８の仕様によっては、コンテンツ伝送プロトコル生成部１０６が配信時間になるまで配信ファイルリスト伝送フォーマットを保持し、配信時間になったら送出装置に配信ファイルリスト伝送フォーマットを送出装置１０８に渡す方式もある。また、配信ファイルリスト伝送フォーマットに対応するPMT（Program Mapping Table）の生成は、ストリームのPID、TS＿id、送出スケジュールがわかれば可能であり、コンテンツ伝送プロトコル生成部で作成することも可能であるし、番組編成管理部104から情報を取得する放送局の他のサブシステムで生成することも可能である。
図７はコンテンツ配信情報生成部１０７が生成するコンテンツ配信情報テーブルを構成するコンテンツ配信情報である。コンテンツ配信情報テーブルはコンテンツ配信情報を要素とするリストである。コンテンツ配信情報テーブルは受信機にコンテンツ配信またはコンテンツ変更を通知するためのテーブルであり、周期的に常時放送されるものである。７０１はコンテンツを識別する識別子である。７０２はコンテンツのバージョンである。７０３はコンテンツが放送される放送チャンネルを表すservice＿idである。７０４はコンテンツを配信する時間（スケジュール）である。７０５はコンテンツ配信がコンテンツを構成する全部のファイルを放送する配信か（「全部」）、変更されたファイルだけを放送する差分配信か（「差分」）を表す更新フラグである。以上の情報は配信スケジュール管理部１０３が管理するコンテンツスケジュール表より渡されるのでコンテンツ配信情報生成部１０７はこれをもとにコンテンツ配信情報テーブルを構成する。
７０６はコンテンツの種類を表す。コンテンツは大きく２つの種類からなる。１つはパッケージ型コンテンツであり、これは一度受信機に蓄積されたら更新されないものである。もう１つは更新型コンテンツであり、これは受信機に蓄積された後も放送局からの更新情報により更新されるものである。以降のコンテンツに関する属性は更新型コンテンツに関するものであるので、パッケージ型コンテンツの場合は以降の内容に関しては省略できる。７０７はコンテンツが次回更新される（コンテンツのバージョンがあがる）予定時間である。７０８はコンテンツの有効期間である。この期間を過ぎると受信機内に蓄積されたコンテンツを構成するすべてのファイルは受信機により削除される。７０９はファイル名であり、７１０はそのファイルの有効期間である。これは受信機に蓄積されるモノメディアデータ（ファイル）が受信機内にいつまで蓄積されていてよいかを表す。受信機はこのファイルの有効期間をみて有効期間の過ぎたファイルを自動的に削除する。これらの情報は運用者が図示されない操作端末より入力する。
SI生成部１０５は番組編成管理部が管理する番組編成情報からSI情報を生成する。このとき、あるサービスまたはイベントがコンテンツ配信である場合、SIテーブルにコンテンツを識別するコンテンツIDを付加する。例えばDVBの場合、SDT（あるいはEIT）テーブルにおいてサービスID（あるいはEIT）で識別されるサービス（あるいはイベント）にコンテンツIDとコンテンツサイズを付加する。コンテンツサイズは配信するファイルの合計サイズであるので、コンテンツDB１０２のコンテンツ管理表と配信スケジュール作成部１０３を参照することにより、配信されるファイルサイズの合計は算出できる。
本実施の形態では、便宜上、「いつでも天気」を番組として定義し、SI情報のうちの番組情報テーブル（DVBのEIT）に「いつでも天気」というコンテンツのタイトル名のほかにコンテンツIDとコンテンツサイズを付加することとする。
以上のような手順で配信する情報を作成することにより図８に示すように、コンテンツ伝送プロトコル生成部１０６、コンテンツ配信情報生成部１０７、SI生成部１０５から送出装置１０８に渡される情報は参照関係を持つ。受信機はこの参照関係を使ってコンテンツを受信する。
図９は配信されるコンテンツを受信する受信機の構成である。９０１は放送局より放送されるテーブルや伝送プロトコルに変換されたコンテンツ（以下、これらを総称してデータという）を受信する受信部である。９０２は放送されているデータのうち、受信機に取り込むものだけを選択して取り込むフィルタリング機能である。９０３はコンテンツの自動更新処理を実行するファイル更新管理機能である。９０４は指定された時間になったことを知らせるタイマー予約機能である。９０５は、伝送フォーマットで送られたファイルを伝送フォーマットから元のファイルフォーマットに変換し、これを蓄積装置に蓄積するファイル蓄積管理機能である。９０６はファイル名とファイルの所在の関係を管理し、上位アプリケーションに汎用的なインタフェースを提供するファイル名称管理機能である。９０７、９０８は上位アプリケーションの１種であるMMプレイヤとEPGである。
図１０のフローチャートを用いて受信機がコンテンツ「いつでも天気」を蓄積するまでの挙動について説明する。ここでは例としてEPGアプリケーションが蓄積を要求しているが、EPGアプリケーション以外のアプリケーションがSI情報を取得して、これを用いて蓄積を要求することも当然可能である。
（ステップ１００１） 図示されていない受信機のSI処理部がSIテーブルを取得し、これをEPGアプリケーション９０７に渡す。
（ステップ１００２） EPGアプリケーション９０７はSI情報の「いつでも天気」を参照し、そこに記述されているタイトル名「いつでも天気」とコンテンツIDとそれを格納する蓄積装置内の場所をパラメータにしてコンテンツ取得をファイル名称管理機能９０６に要求する。蓄積装置のどこにコンテンツを格納するかはアプリケーションが決定する。
（ステップ１００３） ファイル名称管理機能９０６はフィルタリング機能９０２にコンテンツIDを渡し、コンテンツ配信情報テーブルを取得し、その中のコンテンツIDに対応するコンテンツ配信情報だけを返すよう要求する。
（ステップ１００４） フィルタリング機能９０２は受信部９０１が受信したデータの中からコンテンツ配信情報テーブルを選択し、さらにコンテンツIDを用いてコンテンツIDに対応するコンテンツ配信情報を取得し、これをファイル名称管理機能９０６に返す。
（ステップ１００５） ファイル名称管理機能９０６は取得したコンテンツ配信情報から、現在、コンテンツIDに対応するコンテンツが放送されているかどうかをチェックする。配信されている場合はステップ１００８へとぶ。
（ステップ１００６） コンテンツIDに該当するコンテンツが現在、配信されていない場合はコンテンツ配信情報に記述されている配信スケジュールから１つ選択し、その時間になったら知らせるようタイマー予約機能９０４に対しタイマー予約を行う。EPGアプリケーション９０７に予約を行ったことを通知する。EPGアプリケーション９０７のGUIによっては、視聴者にどの時間にコンテンツを受信するかを選択させることも可能である。
（ステップ１００７） 予約時間がくるまで、これに関する処理は行わず待つ。待ち時間の間、受信機の電源がOFFになった場合でもタイマーだけは動いており、タイマー予約時間になると受信機は起動する。
（ステップ１００８） ファイル名称管理機能９０６はファイル蓄積管理機能９０５に対し、ステップ１００１でEPGアプリケーションから渡された格納する蓄積装置内の場所を渡し、コンテンツの格納を指示する。
（ステップ１００９） ファイル名称管理機能９０６はコンテンツ配信情報に記述されたservice＿idを使って、該当する配信ファイルリスト伝送フォーマットを取得するようにフィルタリング機能９０２に要求する。
（ステップ１０１０） フィルタリング機能９０２はservice＿idを用いて受信部９０１から、該当するコンテンツを構成する配信ファイルリスト伝送フォーマットを取得し、これをファイル蓄積管理機能９０５に渡す。
（ステップ１０１１） ファイル蓄積管理機能９０５は取得した配信ファイルリスト伝送フォーマットから元の配信ファイルリストのフォーマットに変換する。配信ファイルリストは、ファイル名、ファイルバージョン、ファイル実体、日付を要素とするリストである。ステップ１００８でファイル名称管理機能９０６に指定された蓄積装置内の格納場所に取得したファイルを全て蓄積する。蓄積後、配信ファイルリストをファイル名称管理機能９０６に渡す。
（ステップ１０１２） ファイル名称管理機能９０６は、ステップ１００５で取得したコンテンツ配信情報を見て、コンテンツの種類が「更新型」コンテンツの場合はファイル更新管理機能９０３に対応するコンテンツIDとコンテンツバージョンを渡し、自動更新管理を行うよう指示する。コンテンツ配信情報に更新予定時間が記述されている場合はそれもファイル更新管理機能９０３に渡す。ステップ１００１で格納場所としてRAMを指定すると、ファイルはメモリ上に蓄積される。リアルタイムアクセスが要求されるようなアプリケーションの場合、格納場所としてメモリを指定することで、アプリケーションはモノメディアデータに速くアクセスすることができる。
（ステップ１００１） 図示されていない受信機のSI処理部がSIテーブルを取得し、これをEPGアプリケーション９０７に渡す。
（ステップ１００２） EPGアプリケーション９０７はSI情報の「いつでも天気」を参照し、そこに記述されているタイトル名「いつでも天気」とコンテンツIDとそれを格納する蓄積装置内の場所をパラメータにしてコンテンツ取得をファイル名称管理機能９０６に要求する。蓄積装置のどこにコンテンツを格納するかはアプリケーションが決定する。
（ステップ１００３） ファイル名称管理機能９０６はフィルタリング機能９０２にコンテンツIDを渡し、コンテンツ配信情報テーブルを取得し、その中のコンテンツIDに対応するコンテンツ配信情報だけを返すよう要求する。
（ステップ１００４） フィルタリング機能９０２は受信部９０１が受信したデータの中からコンテンツ配信情報テーブルを選択し、さらにコンテンツIDを用いてコンテンツIDに対応するコンテンツ配信情報を取得し、これをファイル名称管理機能９０６に返す。
（ステップ１００５） ファイル名称管理機能９０６は取得したコンテンツ配信情報から、現在、コンテンツIDに対応するコンテンツが放送されているかどうかをチェックする。配信されている場合はステップ１００８へとぶ。
（ステップ１００６） コンテンツIDに該当するコンテンツが現在、配信されていない場合はコンテンツ配信情報に記述されている配信スケジュールから１つ選択し、その時間になったら知らせるようタイマー予約機能９０４に対しタイマー予約を行う。EPGアプリケーション９０７に予約を行ったことを通知する。EPGアプリケーション９０７のGUIによっては、視聴者にどの時間にコンテンツを受信するかを選択させることも可能である。
（ステップ１００７） 予約時間がくるまで、これに関する処理は行わず待つ。待ち時間の間、受信機の電源がOFFになった場合でもタイマーだけは動いており、タイマー予約時間になると受信機は起動する。
（ステップ１００８） ファイル名称管理機能９０６はファイル蓄積管理機能９０５に対し、ステップ１００１でEPGアプリケーションから渡された格納する蓄積装置内の場所を渡し、コンテンツの格納を指示する。
（ステップ１００９） ファイル名称管理機能９０６はコンテンツ配信情報に記述されたservice＿idを使って、該当する配信ファイルリスト伝送フォーマットを取得するようにフィルタリング機能９０２に要求する。
（ステップ１０１０） フィルタリング機能９０２はservice＿idを用いて受信部９０１から、該当するコンテンツを構成する配信ファイルリスト伝送フォーマットを取得し、これをファイル蓄積管理機能９０５に渡す。
（ステップ１０１１） ファイル蓄積管理機能９０５は取得した配信ファイルリスト伝送フォーマットから元の配信ファイルリストのフォーマットに変換する。配信ファイルリストは、ファイル名、ファイルバージョン、ファイル実体、日付を要素とするリストである。ステップ１００８でファイル名称管理機能９０６に指定された蓄積装置内の格納場所に取得したファイルを全て蓄積する。蓄積後、配信ファイルリストをファイル名称管理機能９０６に渡す。
（ステップ１０１２） ファイル名称管理機能９０６は、ステップ１００５で取得したコンテンツ配信情報を見て、コンテンツの種類が「更新型」コンテンツの場合はファイル更新管理機能９０３に対応するコンテンツIDとコンテンツバージョンを渡し、自動更新管理を行うよう指示する。コンテンツ配信情報に更新予定時間が記述されている場合はそれもファイル更新管理機能９０３に渡す。ステップ１００１で格納場所としてRAMを指定すると、ファイルはメモリ上に蓄積される。リアルタイムアクセスが要求されるようなアプリケーションの場合、格納場所としてメモリを指定することで、アプリケーションはモノメディアデータに速くアクセスすることができる。
ファイル名称管理機能９０６はステップ１０１０でファイル蓄積管理機能９０５から渡される配信ファイルリストを用いて、タイトル名、ファイル名とその受信機内の格納先の対応関係を保持するファイル所在管理表を管理する。ファイル名称管理機能９０６はコンテンツ配信情報で取得したコンテンツ及びファイルの有効期間の管理も行う。有効期間を過ぎたコンテンツやファイルはファイル名称管理機能９０６により受信機内の蓄積装置から削除される。このようにコンテンツIDを用いることでコンテンツを構成するファイルを取得することができ、アプリケーションからは伝送方式は隠蔽される。図１１のフローを用いてMMプレイヤがコンテンツ「いつでも天気」を再生するときの挙動について説明する。
（ステップ１１０１） MMプレイヤはタイトル名、ファイル名を用いてモノメディアデータ取得をファイル名称管理機能９０６に要求する。
（ステップ１１０２） ファイル名称管理機能９０６はタイトル名、ファイル名からファイル所在管理表を用いてファイル実体の格納場所を検索し、ファイル実体を取得する。
（ステップ１１０３） ファイル名称管理機能９０６は取得したファイル実体をMMプレイヤに返す。
（ステップ１１０４） MMプレイヤは取得したモノメディアデータを再生する。本実施の形態ではコンテンツの取得とコンテンツの再生を分けているが、コンテンツ再生時に図１０で示した手順でコンテンツ取得を行うことも可能である。このようにMMプレイヤはタイトル名とファイル名によりモノメディアデータを取得することが可能である。
（ステップ１１０１） MMプレイヤはタイトル名、ファイル名を用いてモノメディアデータ取得をファイル名称管理機能９０６に要求する。
（ステップ１１０２） ファイル名称管理機能９０６はタイトル名、ファイル名からファイル所在管理表を用いてファイル実体の格納場所を検索し、ファイル実体を取得する。
（ステップ１１０３） ファイル名称管理機能９０６は取得したファイル実体をMMプレイヤに返す。
（ステップ１１０４） MMプレイヤは取得したモノメディアデータを再生する。本実施の形態ではコンテンツの取得とコンテンツの再生を分けているが、コンテンツ再生時に図１０で示した手順でコンテンツ取得を行うことも可能である。このようにMMプレイヤはタイトル名とファイル名によりモノメディアデータを取得することが可能である。
図１２のフローを用いてコンテンツ「いつでも天気」の内容（たとえば気象情報ファイル）が更新されたときの受信機の挙動について説明する。図１０の説明にあるように、更新型のコンテンツに関してはファイル名称管理機能９０６より、ファイル更新管理機能９０３に対し、コンテンツID、コンテンツバージョンが渡される。ファイル更新管理機能９０３はこれらの対応関係を更新型コンテンツ管理表に保持し、管理する。
（ステップ１２０１） フィルタリング機能９０２は定期的にコンテンツ配信情報テーブルを取得し、これをファイル更新管理機能９０３に渡す。
（ステップ１２０２） ファイル更新管理機能９０３はコンテンツ配信情報で送られるコンテンツIDが更新型コンテンツ管理表に登録されていないかをチェックする。登録されていない場合はステップ１２０１へとぶ。
（ステップ１２０３） 次にコンテンツIDのバージョンを比較し、コンテンツ配信情報で送られるバージョンと更新型コンテンツ管理表が保持するバージョンとが同じかどうかをチェックする。同じ場合はステップ１２０１へとぶ。
（ステップ１２０４） コンテンツ配信情報で送られる配信スケジュールを参照し、コンテンツ配信情報に記述されている配信スケジュールから１つ選択し、その時間になったら知らせるようタイマー予約機能に対しタイマー予約を行う。
（ステップ１２０５） 予約時間がくるまで、これに関する処理は行わず待つ。待ち時間の間、受信機の電源がOFFになった場合でもタイマーだけは動いており、タイマー予約時間になると受信機は起動する。
（ステップ１２０６） ファイル更新管理機能９０３はフィルタリング機能９０２より、コンテンツ配信情報を再び取得し、そこに記述されたservice＿idを使って、配信ファイルリスト伝送フォーマットを取得するようにフィルタリング機能９０２に要求する。
（ステップ１２０７） フィルタリング機能９０２はservice＿idを用いて受信部９０１から、該当する配信ファイルリスト伝送フォーマットのストリームを選択し、これをファイル蓄積管理機能９０５に渡す。
（ステップ１２０８） ファイル蓄積管理機能９０５は取得した伝送フォーマットから元のファイル名とファイル実体の配信ファイルリストのフォーマットに変換し、蓄積装置内の格納場所に取得したファイルを全て蓄積する。蓄積後、配信ファイルリストをファイル名称管理機能９０６に渡す。
（ステップ１２０９） ファイル更新管理機能９０３は更新型コンテンツ管理表に書かれたコンテンツのバージョンを１インクリメントする。コンテンツ配信情報に記述されているコンテンツのバージョンと、ファイル更新管理機能９０３が保持しているコンテンツのバージョンが１だけ古い場合、コンテンツ配信情報からダウンロード種別が「差分」になっているダウンロードスケジュールを選択すれば効率良いダウンロードが実現できる。そうでない場合は、ダウンロード種別が「全部」になっているダウンロードスケジュールを選択する。また、ステップ１２０３でコンテンツバージョンがまだ新しくなっていない場合でも、更新予定時間が空になっていない場合は、その時間をタイマー予約機能に予約し、その時間になったら更新処理を再開することも可能である。また、コンテンツ名称管理機能９０６から更新予定時間を取得している場合は、その時間にタイマー予約を行い、タイマー予約時間になったらステップ１２０６から処理を続ける。
（ステップ１２０１） フィルタリング機能９０２は定期的にコンテンツ配信情報テーブルを取得し、これをファイル更新管理機能９０３に渡す。
（ステップ１２０２） ファイル更新管理機能９０３はコンテンツ配信情報で送られるコンテンツIDが更新型コンテンツ管理表に登録されていないかをチェックする。登録されていない場合はステップ１２０１へとぶ。
（ステップ１２０３） 次にコンテンツIDのバージョンを比較し、コンテンツ配信情報で送られるバージョンと更新型コンテンツ管理表が保持するバージョンとが同じかどうかをチェックする。同じ場合はステップ１２０１へとぶ。
（ステップ１２０４） コンテンツ配信情報で送られる配信スケジュールを参照し、コンテンツ配信情報に記述されている配信スケジュールから１つ選択し、その時間になったら知らせるようタイマー予約機能に対しタイマー予約を行う。
（ステップ１２０５） 予約時間がくるまで、これに関する処理は行わず待つ。待ち時間の間、受信機の電源がOFFになった場合でもタイマーだけは動いており、タイマー予約時間になると受信機は起動する。
（ステップ１２０６） ファイル更新管理機能９０３はフィルタリング機能９０２より、コンテンツ配信情報を再び取得し、そこに記述されたservice＿idを使って、配信ファイルリスト伝送フォーマットを取得するようにフィルタリング機能９０２に要求する。
（ステップ１２０７） フィルタリング機能９０２はservice＿idを用いて受信部９０１から、該当する配信ファイルリスト伝送フォーマットのストリームを選択し、これをファイル蓄積管理機能９０５に渡す。
（ステップ１２０８） ファイル蓄積管理機能９０５は取得した伝送フォーマットから元のファイル名とファイル実体の配信ファイルリストのフォーマットに変換し、蓄積装置内の格納場所に取得したファイルを全て蓄積する。蓄積後、配信ファイルリストをファイル名称管理機能９０６に渡す。
（ステップ１２０９） ファイル更新管理機能９０３は更新型コンテンツ管理表に書かれたコンテンツのバージョンを１インクリメントする。コンテンツ配信情報に記述されているコンテンツのバージョンと、ファイル更新管理機能９０３が保持しているコンテンツのバージョンが１だけ古い場合、コンテンツ配信情報からダウンロード種別が「差分」になっているダウンロードスケジュールを選択すれば効率良いダウンロードが実現できる。そうでない場合は、ダウンロード種別が「全部」になっているダウンロードスケジュールを選択する。また、ステップ１２０３でコンテンツバージョンがまだ新しくなっていない場合でも、更新予定時間が空になっていない場合は、その時間をタイマー予約機能に予約し、その時間になったら更新処理を再開することも可能である。また、コンテンツ名称管理機能９０６から更新予定時間を取得している場合は、その時間にタイマー予約を行い、タイマー予約時間になったらステップ１２０６から処理を続ける。
この更新機能を用いて、気象情報ファイルを自動更新することで「いつでも天気」アプリケーションは実現可能である。「いつでも天気」アプリケーションを動かすMMプレイヤは、自動更新に関して何も関与せず、気象情報ファイルを読み込み実行するだけである。コンテンツ配信の上述の更新機能が気象情報ファイルの内容を書き換えることで常に最新の気象情報を取得することができる。本発明のコンテンツ配信がファイルの更新などを行うのでアプリケーション制作者は更新型のアプリケーションを作成する場合でも、通常のパッケージ型アプリケーションのようにアプリケーションを作成すればよい。
（実施の形態２）
図１３はコンテンツＤＢ１０２が管理するコンテンツ管理表を放送番組もファイルとして扱えるように拡張したものである。１３０１は伝送種別である。コンテンツ伝送プロトコル生成部１０６が生成するプロトコルにより伝送されるファイルの伝送種別は「コンテンツ配信」であり、通常の放送番組として送られるストリームは「放送番組」である。図１３では「いつでも天気」のバージョン２から「昼の天気」という放送番組をファイルとして登録している。
（実施の形態２）
図１３はコンテンツＤＢ１０２が管理するコンテンツ管理表を放送番組もファイルとして扱えるように拡張したものである。１３０１は伝送種別である。コンテンツ伝送プロトコル生成部１０６が生成するプロトコルにより伝送されるファイルの伝送種別は「コンテンツ配信」であり、通常の放送番組として送られるストリームは「放送番組」である。図１３では「いつでも天気」のバージョン２から「昼の天気」という放送番組をファイルとして登録している。
図１４はコンテンツDB１０２に放送番組を登録するときの処理フローである。放送番組はSI情報により識別される。ここでは例としてDVBに準拠し、放送番組の識別をサービス（service＿id）、番組（event＿id）、番組開始時間（start＿time）、番組継続時間（duration）で行う場合について説明する。本発明では放送番組はコンテンツを構成するファイルの一種として扱う。
（ステップ１４０１） コンテンツＤＢ１０２に対し、タイトル名、ファイル名、service＿id，event＿id、start＿time、durationを登録する。タイトル名はこの放送番組を構成要素とするコンテンツのタイトル名、ファイル名は受信機上のMMアプリケーションが放送番組を扱うときに用いる名前である。図１３の例ではタイトル名は「いつでも天気」、ファイル名は「昼の天気」である。
（ステップ１４０２） コンテンツＤＢ１０２はservice＿id，event＿id、start＿time、durationを記述したファイルを作成する。このファイルは受信機側で放送番組を自動蓄積（録画）する際利用されるものでストリームリファレンスファイルと呼ぶ。
（ステップ１４０３） コンテンツＤＢ１０２はタイトル名に対応するコンテンツのエンティティに放送番組のファイル名とステップ１４０２で作成したストリームリファレンスファイルを登録する。伝送種別は「放送番組」とする。ストリームリファレンスファイルは通常のファイルと同様にして、コンテンツ伝送プロトコル生成部１０６で伝送フォーマットにされ、放送される。このとき上記実施の形態１で説明したファイルリストの要素として伝送種別を追加する。図１５は放送されたストリームリファレンスファイルを受信した後、ファイル蓄積管理機能９０５が行う処理に関するフローである。
（ステップ１５０１） ファイル蓄積管理機能９０５は伝送種別を参照し、受信したファイルの中に「放送番組」はないかをチェックする。存在する場合は以下の処理を行う。
（ステップ１５０２） ファイル蓄積管理機能１０５はストリームリファレンスファイルの中を読み、この記述をもとに番組録画予約を行う。この際、番組蓄積（録画）装置における番組の格納位置（あるいは番組蓄積装置が蓄積する番組に対して付けるID）を番組蓄積（録画）装置から取得する。
（ステップ１５０３） ファイル蓄積管理機能９０５はファイル名称管理機能９０６に対し、ファイル名、伝送種別、ステップ１５０２で取得した番組格納位置、ストリームリファレンスファイルの内容を渡す。
（ステップ１５０４） ファイル名称管理機能９０５はファイル名と番組格納位置の関係を保持する。ステップ１５０４で述べたようにファイル名称管理機能９０５は放送番組を管理するためにストリームファイル管理表を持つ。
（ステップ１４０１） コンテンツＤＢ１０２に対し、タイトル名、ファイル名、service＿id，event＿id、start＿time、durationを登録する。タイトル名はこの放送番組を構成要素とするコンテンツのタイトル名、ファイル名は受信機上のMMアプリケーションが放送番組を扱うときに用いる名前である。図１３の例ではタイトル名は「いつでも天気」、ファイル名は「昼の天気」である。
（ステップ１４０２） コンテンツＤＢ１０２はservice＿id，event＿id、start＿time、durationを記述したファイルを作成する。このファイルは受信機側で放送番組を自動蓄積（録画）する際利用されるものでストリームリファレンスファイルと呼ぶ。
（ステップ１４０３） コンテンツＤＢ１０２はタイトル名に対応するコンテンツのエンティティに放送番組のファイル名とステップ１４０２で作成したストリームリファレンスファイルを登録する。伝送種別は「放送番組」とする。ストリームリファレンスファイルは通常のファイルと同様にして、コンテンツ伝送プロトコル生成部１０６で伝送フォーマットにされ、放送される。このとき上記実施の形態１で説明したファイルリストの要素として伝送種別を追加する。図１５は放送されたストリームリファレンスファイルを受信した後、ファイル蓄積管理機能９０５が行う処理に関するフローである。
（ステップ１５０１） ファイル蓄積管理機能９０５は伝送種別を参照し、受信したファイルの中に「放送番組」はないかをチェックする。存在する場合は以下の処理を行う。
（ステップ１５０２） ファイル蓄積管理機能１０５はストリームリファレンスファイルの中を読み、この記述をもとに番組録画予約を行う。この際、番組蓄積（録画）装置における番組の格納位置（あるいは番組蓄積装置が蓄積する番組に対して付けるID）を番組蓄積（録画）装置から取得する。
（ステップ１５０３） ファイル蓄積管理機能９０５はファイル名称管理機能９０６に対し、ファイル名、伝送種別、ステップ１５０２で取得した番組格納位置、ストリームリファレンスファイルの内容を渡す。
（ステップ１５０４） ファイル名称管理機能９０５はファイル名と番組格納位置の関係を保持する。ステップ１５０４で述べたようにファイル名称管理機能９０５は放送番組を管理するためにストリームファイル管理表を持つ。
図１６はファイル名称管理機能９０５がストリームリファレンスファイルを管理するためのストリームファイル管理表である。１６０１はコンテンツのタイトル名、１６０２はファイル名、１６０３はSI情報で、service＿id、event＿id、start＿time、durationが格納されている。１６０４は番組格納位置である。MMプレイヤから放送番組へのアクセス要求がタイトル名、ファイル名を用いて、ファイル名称管理機能９０５にきた場合、ファイル名称管理機能９０５は番組蓄積装置内のファイル名に対応する番組格納位置に存在するストリームを再生する。また、放送番組が現在放送されており、蓄積装置に蓄積（録画）中の場合はSI情報を用いてその番組にチャンネルをチューニングし、蓄積されたストリームではなく現在放送されているストリームを再生する。また、その放送番組の放送開始時間（start＿time）前の場合は、再生できないというエラーを返す。これによりMMプレイヤから簡単に放送番組にリンクすることができる。
本発明ではストリームをファイルとして扱うことが可能なので「いつでも天気」アプリケーションが、実際に番組として放送されている「昼の天気予報」とリンクを張ることが可能である。アプリケーション制作者は番組にファイル名を付け、そのSI情報をコンテンツ管理DBに登録するだけで、受信機側でアプリケーションと関連する放送番組を自動的に蓄積し、アプリケーションと放送番組を連動させたサービスを提供することが可能である。
（実施の形態３）
図１７は本発明の第３の実施の形態におけるコンテンツ配信センターシステムの一形態を示すブロック図である。このコンテンツ配信センターシステムは、基本的には上記実施の形態１におけるシステムと同様な構成を有しており、オーサリングツール１０１と、コンテンツDB１０２と、配信スケジュール作成部１０３と、番組編成管理部１０４と、SI生成部１０５と、コンテンツ配信情報生成部１０７と、送出装置１０８とを備えている。また、図１７において、１７０１はデータカルーセル生成装置である。データカルーセルはISO13818-6で規定された一方向ネットワークにおけるデータ伝送プロトコルであり、この装置は入力されたデータをデータカルーセルプロトコルにフォーマットする。１７０２はデータカルーセルプロトコルにフィルタリング情報を付加し、付加した情報の内容をコンテンツ配信情報生成部１０７に渡すフィルタリング情報付加部である。
（実施の形態３）
図１７は本発明の第３の実施の形態におけるコンテンツ配信センターシステムの一形態を示すブロック図である。このコンテンツ配信センターシステムは、基本的には上記実施の形態１におけるシステムと同様な構成を有しており、オーサリングツール１０１と、コンテンツDB１０２と、配信スケジュール作成部１０３と、番組編成管理部１０４と、SI生成部１０５と、コンテンツ配信情報生成部１０７と、送出装置１０８とを備えている。また、図１７において、１７０１はデータカルーセル生成装置である。データカルーセルはISO13818-6で規定された一方向ネットワークにおけるデータ伝送プロトコルであり、この装置は入力されたデータをデータカルーセルプロトコルにフォーマットする。１７０２はデータカルーセルプロトコルにフィルタリング情報を付加し、付加した情報の内容をコンテンツ配信情報生成部１０７に渡すフィルタリング情報付加部である。
図１８はファイルをモジュールに詰め込むときのフォーマットを示した図である。データカルーセルのモジュールには複数のファイルを入れる。１８０１はファイルの切れ目を表すファイルヘッダ、１８０２はファイル本体である。ファイルヘッダはファイル名、ファイルバージョン、ファイルのモジュールにおける相対的な開始位置、ファイルサイズである。このフォーマットのことをデータカルーセル用配信ファイルリストという。実施の形態２のように放送番組もファイルとして扱う場合はファイルヘッダに伝送種別を追加する。
図１９はコンテンツ配信情報テーブルをモジュール単位のフィルタリング、ファイル単位のフィルタリングを可能とするために拡張したものである。１９０１は「モジュール単位の更新」か「ファイル単位の更新」かを示す更新種別である。普通にデータカルーセルを利用してコンテンツを配信する場合は更新種別は「通常」となる。１９０２は更新情報であり、更新種別が「モジュール単位の更新」の場合は更新対象となるモジュールIDのリストが入る。「ファイル単位の更新」の場合、ファイル情報が更新情報として格納される。ファイル情報の内容はファイル名、ファイルバージョン、ファイルサイズ、ファイルの格納位置から構成される。ファイルの格納位置はデータカルーセルのブロックにおけるファイルの先頭位置（ブロック番号とブロック先頭からのオフセット）とブロックにおけるファイル終了位置ブロック番号とブロック先頭からのオフセット）から構成される。
次にデータカルーセルのモジュールを利用したコンテンツ配信における、データカルーセル生成装置１７０１とフィルタリング情報付加部１７０２とコンテンツ配信情報生成部１０７の処理について説明する。ここでは「いつでも天気」アプリケーションを配信する場合を例として挙げ、更新されたファイルとして、地域ごとの最新の気象情報テキストファイルtokyo.txt, ibaraki.txt, saitama.txt, chiba.txtを１モジュールにして送り、他の更新されないファイル（ビットマップファイル、他のテキストファイル、スクリプトファイル）も別のモジュールとして配信する場合について説明する。
（１）フィルタリング情報付加部１７０２は更新された４つのテキストファイルtokyo.txt, ibaraki.txt, saitama.txt, chiba.txtをデータカルーセル用配信ファイルリストにし、これを１つのモジュールとしてデータカルーセルのフォーマットにするよう、データカルーセル生成装置１７０１に要求する。データカルーセル用配信ファイルリスト作成のために必要な情報（ファイル名、ファイルバージョン、ファイルサイズ）は上記実施の形態１と同様に、コンテンツDB１０２のコンテンツ管理表から取得できる。また、どのファイルが更新されたファイルかは実施の形態１と同様にして、フィルタリング情報付加部１２０２は知ることができる。
（２） データカルーセル生成装置１７０１は受け取ったデータをモジュール化し、モジュールIDを返す。
（３） フィルタリング情報付加部１７０２は残りのファイルに関してもデータカルーセル用配信ファイルリスト化し、モジュールとしてデータカルーセルのフォーマットにするよう、データカルーセル生成装置１７０１に要求する。もし、ファイル数やファイルサイズが大きく、モジュールサイズが大きくなる場合は、フィルタリング情報付加部１７０２はファイルを適当にグループ化して、それぞれのグループごとにデータカルーセル用配信ファイルリスト化し、それぞれを別のモジュールに格納するようにする。
（４） データカルーセル生成装置１７０１は受け取った残りのデータもモジュール化する。
（５）フィルタリング情報付加部１７０２は実施の形態１と同様にして、配信スケジュール作成部１０３のコンテンツスケジュール表からデータ伝送に必要なPSI情報と配信スケジュールを取得し、これをデータカルーセル生成装置１７０１に渡す。
（６）データカルーセル生成装置１７０１はDII、DDB伝送フォーマットを作成し、これをスケジュールどおりに放送するように送出装置１０９に渡す。
（７）フィルタリング情報付加部１７０２はステップ２００２で取得したmoduleIDをコンテンツ配信情報生成部１０７に渡す。
（８）コンテンツ配信情報生成部１０７は取得したmoduleIDを用いて図１９に示したコンテンツ配信情報テーブルを生成する。この際、更新の種類は「モジュール単位の更新」となる。生成したンテンツ配信情報テーブルを周期的に常時放送するように送出装置１０８に渡す。
（１）フィルタリング情報付加部１７０２は更新された４つのテキストファイルtokyo.txt, ibaraki.txt, saitama.txt, chiba.txtをデータカルーセル用配信ファイルリストにし、これを１つのモジュールとしてデータカルーセルのフォーマットにするよう、データカルーセル生成装置１７０１に要求する。データカルーセル用配信ファイルリスト作成のために必要な情報（ファイル名、ファイルバージョン、ファイルサイズ）は上記実施の形態１と同様に、コンテンツDB１０２のコンテンツ管理表から取得できる。また、どのファイルが更新されたファイルかは実施の形態１と同様にして、フィルタリング情報付加部１２０２は知ることができる。
（２） データカルーセル生成装置１７０１は受け取ったデータをモジュール化し、モジュールIDを返す。
（３） フィルタリング情報付加部１７０２は残りのファイルに関してもデータカルーセル用配信ファイルリスト化し、モジュールとしてデータカルーセルのフォーマットにするよう、データカルーセル生成装置１７０１に要求する。もし、ファイル数やファイルサイズが大きく、モジュールサイズが大きくなる場合は、フィルタリング情報付加部１７０２はファイルを適当にグループ化して、それぞれのグループごとにデータカルーセル用配信ファイルリスト化し、それぞれを別のモジュールに格納するようにする。
（４） データカルーセル生成装置１７０１は受け取った残りのデータもモジュール化する。
（５）フィルタリング情報付加部１７０２は実施の形態１と同様にして、配信スケジュール作成部１０３のコンテンツスケジュール表からデータ伝送に必要なPSI情報と配信スケジュールを取得し、これをデータカルーセル生成装置１７０１に渡す。
（６）データカルーセル生成装置１７０１はDII、DDB伝送フォーマットを作成し、これをスケジュールどおりに放送するように送出装置１０９に渡す。
（７）フィルタリング情報付加部１７０２はステップ２００２で取得したmoduleIDをコンテンツ配信情報生成部１０７に渡す。
（８）コンテンツ配信情報生成部１０７は取得したmoduleIDを用いて図１９に示したコンテンツ配信情報テーブルを生成する。この際、更新の種類は「モジュール単位の更新」となる。生成したンテンツ配信情報テーブルを周期的に常時放送するように送出装置１０８に渡す。
このようにして、更新ファイルをまとめてモジュール化し、モジュールIDをコンテンツ配信情報に付加することにより、受信機はコンテンツ配信情報に書かれたモジュールIDのモジュールだけを取得するだけで更新ファイルをすべて取得できる。
次にファイル情報を利用したコンテンツ配信における、データカルーセル生成装置１２０１とフィルタリング情報付加部１２０２とコンテンツ配信情報生成部１０７の処理について説明する。ここでは「いつでも天気」アプリケーションを配信する場合を例として挙げ、更新ファイルが関東地方の気象情報テキストファイルtokyo.txtしかない場合について説明する。この場合、上述のモジュールを使う方式も有効であるが（１モジュールにtokyo.txtだけを入れる）、コンテンツを構成する全ファイル数が多いと、モジュールに複数ファイルを詰め込む必要がある場合がある。このような場合にファイル情報を利用したコンテンツ配信が有効になる。この例では上述の例と同様に、他のファイル（ビットマップファイル、他のテキストファイル、スクリプトファイル）も別のモジュールとして配信する。
（１） フィルタリング情報付加部１７０２は「いつでも天気」を構成するファイルをデータカルーセル用配信ファイルリスト化する。もし、ファイル数やファイルサイズが大きく、モジュールサイズが大きくなる場合は、フィルタリング情報付加部１７０２はファイルを適当にグループ化して、それぞれのグループごとにデータカルーセル用配信ファイルリスト化し、それぞれを別のモジュールに格納するようにする。
（２） データカルーセル生成装置１７０１は受け取ったデータをモジュール化する。
（３）フィルタリング情報付加部１７０２は、上記実施の形態１と同様にして、配信スケジュール作成部１０３のコンテンツスケジュール表からデータ伝送に必要なPSI情報と配信スケジュールを取得し、これをデータカルーセル生成装置１７０１に渡す。
（４）データカルーセル生成装置１７０１はDII、DDB伝送フォーマットを作成し、これをスケジュールどおりに放送するように送出装置１０８に渡す。生成したDII、DDBのコピーをデータカルーセル生成装置１７０１内の蓄積装置に格納する。
（５）フィルタリング情報付加部１７０２はデータカルーセル装置１７０１内に格納されたDDBを検索し、ファイル名tokyo.txtがブロックのどこに（何番目のブロックのどこから、何番目のブロックのどこまで）格納されているかを調べ、その結果と、ファイル名（tokyo.txt）、バージョン、ファイルサイズをコンテンツ配信情報生成部１０７に渡す。
（６）コンテンツ配信情報生成部１０７は取得したtokyo.txtのDDBにおける所在情報を用いて図１５に示したコンテンツ配信情報テーブルを生成する。この際、更新の種類は「ファイル単位の更新」となる。生成したンテンツ配信情報テーブルを周期的に常時放送するように送出装置１０８に渡す。
（１） フィルタリング情報付加部１７０２は「いつでも天気」を構成するファイルをデータカルーセル用配信ファイルリスト化する。もし、ファイル数やファイルサイズが大きく、モジュールサイズが大きくなる場合は、フィルタリング情報付加部１７０２はファイルを適当にグループ化して、それぞれのグループごとにデータカルーセル用配信ファイルリスト化し、それぞれを別のモジュールに格納するようにする。
（２） データカルーセル生成装置１７０１は受け取ったデータをモジュール化する。
（３）フィルタリング情報付加部１７０２は、上記実施の形態１と同様にして、配信スケジュール作成部１０３のコンテンツスケジュール表からデータ伝送に必要なPSI情報と配信スケジュールを取得し、これをデータカルーセル生成装置１７０１に渡す。
（４）データカルーセル生成装置１７０１はDII、DDB伝送フォーマットを作成し、これをスケジュールどおりに放送するように送出装置１０８に渡す。生成したDII、DDBのコピーをデータカルーセル生成装置１７０１内の蓄積装置に格納する。
（５）フィルタリング情報付加部１７０２はデータカルーセル装置１７０１内に格納されたDDBを検索し、ファイル名tokyo.txtがブロックのどこに（何番目のブロックのどこから、何番目のブロックのどこまで）格納されているかを調べ、その結果と、ファイル名（tokyo.txt）、バージョン、ファイルサイズをコンテンツ配信情報生成部１０７に渡す。
（６）コンテンツ配信情報生成部１０７は取得したtokyo.txtのDDBにおける所在情報を用いて図１５に示したコンテンツ配信情報テーブルを生成する。この際、更新の種類は「ファイル単位の更新」となる。生成したンテンツ配信情報テーブルを周期的に常時放送するように送出装置１０８に渡す。
なお、この例ではフィルタリング情報付加部１７０２がファイルtokyo.txtのDDBにおける所在を知るために検索したが、データカルーセル生成装置１７０１に、あらかじめtokyo.txtというファイルがフィルタリング対象であることをフィルタリング情報付加部１７０２が知らせておき、データカルーセル生成装置１７０１がDDBを作成するときにファイルtokyo.txtの位置（どのモジュールの、どのブロックのどの位置から始まり、どのブロックのどの位置で終わるか）を記憶し、これをフィルタリング情報付加部１７０２に知らせるという方式も考えられる。また、本実施の形態ではファイル情報はコンテンツ配信情報テーブルに入れて配信するが、DSM-CCカルーセルのDIIのmoduleInfo領域にファイル情報を入れて配信することも可能である。
コンテンツ配信の際、モジュールを利用した配信を行うか、またはファイル情報を利用した配信を行うか、あるいはこれらを利用しないで通常のデータカルーセルで放送するかはフィルタリング情報付加部１７０２を図示しない操作端末で操作する運用者が決定する。どの方式で送るのが効率的かはアプリケーションに依存する。
図２０は受信機がコンテンツ配信情報テーブルを受信してから更新処理を行う処理フロー図である。図１２の説明にあるように、更新型のコンテンツに関してはファイル名称管理機能９０６より、ファイル更新管理機能９０３に対し、コンテンツID、コンテンツバージョンが渡される。ファイル更新管理機能９０３はこれらの対応関係を更新型コンテンツ管理表に保持し、管理する。
（ステップ２００１） フィルタリング機能９０２は定期的にコンテンツ配信情報テーブルを取得し、これをファイル更新管理機能９０３に渡す。
（ステップ２００２） ファイル更新管理機能９０３はコンテンツ配信情報で送られるコンテンツIDが更新型コンテンツ管理表に登録されていないかをチェックする。登録されていない場合はステップ２００１へとぶ。
（ステップ２００３） 次にコンテンツIDのバージョンを比較し、コンテンツ配信情報で送られるバージョンと更新型コンテンツ管理表が保持するバージョンとが同じかどうかをチェックする。同じ場合はステップ２００１へとぶ。
（ステップ２００４） コンテンツ配信情報で送られる配信スケジュールを参照し、コンテンツ配信情報に記述されている配信スケジュールから１つ選択し、その時間になったら知らせるようタイマー予約機能に対しタイマー予約を行う。
（ステップ２００５） 予約時間がくるまで、これに関する処理は行わず待つ。待ち時間の間、受信機の電源がOFFになった場合でもタイマーだけは動いており、タイマー予約時間になると受信機は起動する。
（ステップ２００６） ファイル更新管理機能９０３はコンテンツ配信情報に記述されている更新種別を調べる。更新種別が「モジュール単位の更新」の場合はステップ２０１０へとぶ。更新種別が「ファイル単位の更新」の場合はステップ２０１３へとぶ。
（ステップ２００７） 更新種別が「通常」の場合、ファイル更新管理機能９０３はコンテンツ配信情報に記述されたservice＿idを使って、伝送フォーマット化されたコンテンツを構成するファイルが流れているストリームを取得するようにフィルタリング機能９０２に要求する。
（ステップ２００８） フィルタリング機能９０２はservice＿idを用いて受信部９０１から、該当するコンテンツを構成するファイルが格納された伝送フォーマットのストリームを選択し、これをファイル蓄積管理機能９０５に渡す。
（ステップ２００９） ファイル蓄積管理機能９０５は取得した伝送フォーマットから元の配信用ファイルリストのフォーマットに変換し、蓄積装置内の格納場所に取得したファイルを全て蓄積する。蓄積後、配信ファイルリストをファイル名称管理機能９０６に渡す。
（ステップ２０１０） 更新種別が「モジュール単位」になっている場合、コンテンツ配信情報に記述されているservice＿idと、コンテンツ配信情報の更新情報に記述されているモジュールIDをフィルタリング機能９０２に渡し、モジュール単位でのフィルタリングを要求する。
（ステップ２０１１） フィルタリング機能９０２はservice＿idを使って、DIIを取得した後、モジュールIDを使ったフィルタリングにより該当するモジュールを構成するDDBだけを取得する。フィルタリング機能９０２はDDBを組み立て、モジュールを構成し、これをファイル蓄積管理機能９０５に渡す。
（ステップ２０１２） ファイル蓄積管理機能９０５は取得したモジュールから元のファイル名とファイル実体のリストを取出し、蓄積装置内の格納場所に取得したファイルを全て蓄積する。蓄積後、配信ファイルリストをファイル名称管理機能９０６に渡す。
（ステップ２０１３） 更新種別が「ファイル単位」になっている場合、コンテンツ配信情報に記述されているservice＿idと、コンテンツ配信情報の更新情報に記述されているファイル情報をフィルタリング機能９０２に渡し、モジュール単位でのフィルタリングを要求する。
（ステップ２０１４） フィルタリング機能９０２はservice＿idを使って、DIIを取得した後、ファイル情報のモジュールIDとブロック番号を使ったフィルタリングにより該当するモジュールを構成するDDBのうち、必要なブロック番号のものだけを取得する。フィルタリング機能９０２は取得したDDB群とファイル情報をファイル蓄積管理機能９０５に渡す。
（ステップ２０１５） ファイル蓄積管理機能９０５はファイル情報をもとにDDB群の中からファイルを取出し、蓄積装置内の格納場所に取得したファイルを蓄積する。蓄積後、ファイル情報をファイル名称管理機能９０６に渡す（ファイル情報がファイル配信リストのかわりになる）。
（ステップ２０１６） 更新型コンテンツ管理表のコンテンツのバージョンをインクリメントする。
（ステップ２００１） フィルタリング機能９０２は定期的にコンテンツ配信情報テーブルを取得し、これをファイル更新管理機能９０３に渡す。
（ステップ２００２） ファイル更新管理機能９０３はコンテンツ配信情報で送られるコンテンツIDが更新型コンテンツ管理表に登録されていないかをチェックする。登録されていない場合はステップ２００１へとぶ。
（ステップ２００３） 次にコンテンツIDのバージョンを比較し、コンテンツ配信情報で送られるバージョンと更新型コンテンツ管理表が保持するバージョンとが同じかどうかをチェックする。同じ場合はステップ２００１へとぶ。
（ステップ２００４） コンテンツ配信情報で送られる配信スケジュールを参照し、コンテンツ配信情報に記述されている配信スケジュールから１つ選択し、その時間になったら知らせるようタイマー予約機能に対しタイマー予約を行う。
（ステップ２００５） 予約時間がくるまで、これに関する処理は行わず待つ。待ち時間の間、受信機の電源がOFFになった場合でもタイマーだけは動いており、タイマー予約時間になると受信機は起動する。
（ステップ２００６） ファイル更新管理機能９０３はコンテンツ配信情報に記述されている更新種別を調べる。更新種別が「モジュール単位の更新」の場合はステップ２０１０へとぶ。更新種別が「ファイル単位の更新」の場合はステップ２０１３へとぶ。
（ステップ２００７） 更新種別が「通常」の場合、ファイル更新管理機能９０３はコンテンツ配信情報に記述されたservice＿idを使って、伝送フォーマット化されたコンテンツを構成するファイルが流れているストリームを取得するようにフィルタリング機能９０２に要求する。
（ステップ２００８） フィルタリング機能９０２はservice＿idを用いて受信部９０１から、該当するコンテンツを構成するファイルが格納された伝送フォーマットのストリームを選択し、これをファイル蓄積管理機能９０５に渡す。
（ステップ２００９） ファイル蓄積管理機能９０５は取得した伝送フォーマットから元の配信用ファイルリストのフォーマットに変換し、蓄積装置内の格納場所に取得したファイルを全て蓄積する。蓄積後、配信ファイルリストをファイル名称管理機能９０６に渡す。
（ステップ２０１０） 更新種別が「モジュール単位」になっている場合、コンテンツ配信情報に記述されているservice＿idと、コンテンツ配信情報の更新情報に記述されているモジュールIDをフィルタリング機能９０２に渡し、モジュール単位でのフィルタリングを要求する。
（ステップ２０１１） フィルタリング機能９０２はservice＿idを使って、DIIを取得した後、モジュールIDを使ったフィルタリングにより該当するモジュールを構成するDDBだけを取得する。フィルタリング機能９０２はDDBを組み立て、モジュールを構成し、これをファイル蓄積管理機能９０５に渡す。
（ステップ２０１２） ファイル蓄積管理機能９０５は取得したモジュールから元のファイル名とファイル実体のリストを取出し、蓄積装置内の格納場所に取得したファイルを全て蓄積する。蓄積後、配信ファイルリストをファイル名称管理機能９０６に渡す。
（ステップ２０１３） 更新種別が「ファイル単位」になっている場合、コンテンツ配信情報に記述されているservice＿idと、コンテンツ配信情報の更新情報に記述されているファイル情報をフィルタリング機能９０２に渡し、モジュール単位でのフィルタリングを要求する。
（ステップ２０１４） フィルタリング機能９０２はservice＿idを使って、DIIを取得した後、ファイル情報のモジュールIDとブロック番号を使ったフィルタリングにより該当するモジュールを構成するDDBのうち、必要なブロック番号のものだけを取得する。フィルタリング機能９０２は取得したDDB群とファイル情報をファイル蓄積管理機能９０５に渡す。
（ステップ２０１５） ファイル蓄積管理機能９０５はファイル情報をもとにDDB群の中からファイルを取出し、蓄積装置内の格納場所に取得したファイルを蓄積する。蓄積後、ファイル情報をファイル名称管理機能９０６に渡す（ファイル情報がファイル配信リストのかわりになる）。
（ステップ２０１６） 更新型コンテンツ管理表のコンテンツのバージョンをインクリメントする。
このように、コンテンツ配信情報にフィルタリングのための情報を付加することにより、センター側から差分配信を行わなくても、受信機側で必要な部分だけを切り出すことが可能である。本実施の形態では、セクションにフィルタリングを行うので高速である。
（実施の形態４）
図２１は第１の実施の形態における配信スケジュール作成部１０３が管理するコンテンツスケジュール情報（図５に示されている）において、差分情報５８を追加して拡張させたデータ構造とした本発明の第４の実施の形態を示す図である。図５のスケジュール情報では、更新フラグ５５に対して、「全部」と「差分」しか存在しなかったため、どのコンテンツバージョン５２に対する差分か、端末（すなわち受信機）において知ることは不可能であった。これに対して、差分情報５８を付加することにより、図５の場合では常に受信機の電源が入っていて、コンテンツ情報をすべて受信していなければならなかったのに対し、差分情報５８を調べることにより、受信機は自己機が管理しているコンテンツに対する差分情報であるかどうかを判断することができ、受信機の電源が切られている間に差分情報５８が流れ、端末が受信できなくても、次に差分情報５８が流れてきたときに受信機は、差分情報５８をみることにより、管理しているコンテンツに対して適応できる差分情報かどうかを判断することが可能となる。
（実施の形態４）
図２１は第１の実施の形態における配信スケジュール作成部１０３が管理するコンテンツスケジュール情報（図５に示されている）において、差分情報５８を追加して拡張させたデータ構造とした本発明の第４の実施の形態を示す図である。図５のスケジュール情報では、更新フラグ５５に対して、「全部」と「差分」しか存在しなかったため、どのコンテンツバージョン５２に対する差分か、端末（すなわち受信機）において知ることは不可能であった。これに対して、差分情報５８を付加することにより、図５の場合では常に受信機の電源が入っていて、コンテンツ情報をすべて受信していなければならなかったのに対し、差分情報５８を調べることにより、受信機は自己機が管理しているコンテンツに対する差分情報であるかどうかを判断することができ、受信機の電源が切られている間に差分情報５８が流れ、端末が受信できなくても、次に差分情報５８が流れてきたときに受信機は、差分情報５８をみることにより、管理しているコンテンツに対して適応できる差分情報かどうかを判断することが可能となる。
しかし、差分情報５８だけでは、各コンテンツバージョン５２に対して差分情報５８を送る必要がある。この場合、差分情報５８が大きくなり、伝送路の帯域を広く使用する問題がある。また、差分情報によっては、或るバージョン以降であれば全てに適応できる差分情報も存在する。図２２はこのような状況にも対応できるように、コンテンツスケジュール情報に上記差分情報５８に加えて差分付加情報５９をさらに追加して拡張させたデータ構造としたものである。このようなデータ構造を有するコンテンツスケジュール情報としたため、特定のバージョンに限定された差分情報であるか、そのバージョン以降のものであればどのバージョンでも適応できる差分情報であるかを、放送局から送ることにより、受信機は管理しているコンテンツに適応できるかどうか判断できるだけでなく、伝送すべき差分情報を圧縮することが可能となる。差分情報５８の処理については、上記実施の形態１におけると同様である。
また、コンテンツバージョン５２は無限に増加するものとは限定されない。システムの制約で一定の範囲内でのバージョンしか付与されない場合がある。図２２の差分付加情報で、差分情報５８に対して範囲を指定している特徴を付加したが、コンテンツバージョンが一定の範囲を越えて、繰り返しのバージョン番号が付加されれば、先に付加した差分付加情報を受信機が受信した場合、「以上」の処理を行なうことができなくなる。例えば、コンテンツバージョンが１〜８に限定されていた場合、バージョン８の次にくるバージョンは１となる。このあと、差分情報５８がバージョン８以上できた場合、バージョン１のコンテンツを管理している受信機では差分情報５８を適応できなくなる。そのため、図２３２３に示すように、コンテンツスケジュール情報に上記差分情報５８および差分付加情報５９に加えてバージョン付加情報５１０をさらに追加して拡張させたデータ構造としたものである。このようなデータ構造を有するコンテンツスケジュール情報とし、バージョン付加情報５１０を放送局から受信機に送るときに付加することにより、バージョン番号が８から１になったときに、例えばこのバージョン付加情報５１０に「ＯＮ」を送れば受信機ではこのバージョン番号は「１」で送られてきているが、実際は「９」に等しいことが判断でき、次にくるバージョン８以上への差分情報を適応することが可能となる。
（実施の形態５）
放送局から送られてきたコンテンツには、図７に示すデータ構造を持ったコンテンツ配信情報テーブルが同時に伝送される。このコンテンツを受信機で使用するとき、図７の例では有効期限内であればコンテンツの使用は可能である。しかしコンテンツによっては、蓄積は有効期限まで可能であるが受信機で使用する場合、特定の期間のみに限定して使用が可能なコンテンツも存在する。図２４はこのようなコンテンツの使用期間を明確にするため、コンテンツ配信情報生成部１０７が生成するコンテンツ配信情報テーブルに利用有効期間情報７１１を追加して拡張させたデータ構造を示すものである。このようなデータ構造を有するコンテンツ配信情報テーブルでは、コンテンツのファイル属性についても、ファイル名情報７０９、有効期限情報７１０に加えて利用有効期間情報７１２が追加記述される。上記利用有効期間には、例えば毎週日曜日のみとか、毎日１２：００〜１３：００のみ、或いは毎週月曜日の夕方１７：００〜１８：００と毎月１日のみとかの設定ができる。また、別の形としては、受信機で受信後１日以内とか、受信機で受信後使用時間が１時間以内、或いは特定の番組の放送時間の間などの設定が可能である。
（実施の形態５）
放送局から送られてきたコンテンツには、図７に示すデータ構造を持ったコンテンツ配信情報テーブルが同時に伝送される。このコンテンツを受信機で使用するとき、図７の例では有効期限内であればコンテンツの使用は可能である。しかしコンテンツによっては、蓄積は有効期限まで可能であるが受信機で使用する場合、特定の期間のみに限定して使用が可能なコンテンツも存在する。図２４はこのようなコンテンツの使用期間を明確にするため、コンテンツ配信情報生成部１０７が生成するコンテンツ配信情報テーブルに利用有効期間情報７１１を追加して拡張させたデータ構造を示すものである。このようなデータ構造を有するコンテンツ配信情報テーブルでは、コンテンツのファイル属性についても、ファイル名情報７０９、有効期限情報７１０に加えて利用有効期間情報７１２が追加記述される。上記利用有効期間には、例えば毎週日曜日のみとか、毎日１２：００〜１３：００のみ、或いは毎週月曜日の夕方１７：００〜１８：００と毎月１日のみとかの設定ができる。また、別の形としては、受信機で受信後１日以内とか、受信機で受信後使用時間が１時間以内、或いは特定の番組の放送時間の間などの設定が可能である。
この利用有効期間の判断は図９のファイル蓄積管理機能９０５またはファイル名称管理機能９０６で判断する。この利用有効期間の処理以外の処理は、実施の形態２或いは実施の形態３における処理と同様である。
以上のように、本発明に係る受信機は、バージョン情報によりコンテンツを自動的に更新できるという効果を有し、受信機に蓄えられたモノメディアデータの自動更新を可能とした受信機及び受信方法等として有用である。
１０１ オーサリングツール
１０２ コンテンツDB
１０３ 配信スケジュール作成部
１０４ 番組編成管理部
１０５ SI生成部
１０６ コンテンツ伝送プロトコル生成部
１０７ コンテンツ配信情報生成部
１０８ 送出装置
９０１ 受信部
９０２ フィルタリング機能
９０３ ファイル更新管理機能
９０４ タイマー予約機能
９０５ ファイル蓄積管理機能
９０６ ファイル名称管理機能
９０７ EPG
９０８ MMプレイヤ
１７０１ データカルーセル生成装置
１７０２ フィルタリング情報付加部
１０２ コンテンツDB
１０３ 配信スケジュール作成部
１０４ 番組編成管理部
１０５ SI生成部
１０６ コンテンツ伝送プロトコル生成部
１０７ コンテンツ配信情報生成部
１０８ 送出装置
９０１ 受信部
９０２ フィルタリング機能
９０３ ファイル更新管理機能
９０４ タイマー予約機能
９０５ ファイル蓄積管理機能
９０６ ファイル名称管理機能
９０７ EPG
９０８ MMプレイヤ
１７０１ データカルーセル生成装置
１７０２ フィルタリング情報付加部
Claims (2)
- バージョンが付与されたコンテンツがどのバージョンとの差分であるかを示す差分情報と、その差分情報が特定のバージョンに限定された差分情報であるか、そのバージョン以降であればどのバージョンでも適用できる差分情報であるかを示す差分付加情報と、当該コンテンツの配信スケジュールと、を含むスケジュール情報を放送局システムから受信する受信部と、
前記スケジュール情報を用いて、受信した前記コンテンツの蓄積を制御するファイル更新管理機能とを備え、
前記ファイル更新管理機能は、
前記差分付加情報に基づいて、前記スケジュール情報の差分情報の示すコンテンツバージョンとすでに蓄積済みのコンテンツのバージョンとが一致するか、あるいは、蓄積済みのコンテンツのバージョンが前記差分情報の示すコンテンツのバージョンを適用できる特定バージョン以降のものであるかを判断し、
前記スケジュール情報の差分情報の示すコンテンツのバージョンとすでに蓄積済みのコンテンツのバージョンとが一致する場合は、前記すでに蓄積済みのコンテンツを前記スケジュール情報に従って受信したコンテンツで更新し、
蓄積済みのコンテンツのバージョンが前記差分情報の示すコンテンツのバージョンを適用できる特定バージョン以降のものである場合は、前記すでに蓄積済みの特定のバージョン以降のコンテンツを前記スケジュール情報に従って受信したコンテンツで更新する、
ことを特徴とする受信機。 - バージョンが付与されたコンテンツがどのバージョンとの差分であるかを示す差分情報と、その差分情報が特定のバージョンに限定された差分情報であるか、そのバージョン以降であればどのバージョンでも適用できる差分情報であるかを示す差分付加情報と、当該コンテンツの配信スケジュールと、を含むスケジュール情報を放送局システムから受信するステップと、
前記スケジュール情報の差分付加情報に基づいて、前記スケジュール情報の差分情報の示すコンテンツのバージョンとすでに蓄積済みのコンテンツのバージョンとが一致するか、あるいは、蓄積済みのコンテンツのバージョンが前記差分情報の示すコンテンツのバージョンを適用できる特定バージョン以降のものであるかを判断するステップと、
前記スケジュール情報の差分情報の示すコンテンツのバージョンとすでに蓄積済みのコンテンツのバージョンとが一致する場合は、前記すでに蓄積済みのコンテンツを前記スケジュール情報に従って受信したコンテンツで更新するステップと、
蓄積済みのコンテンツのバージョンが前記差分情報の示すコンテンツのバージョンを適用できる特定バージョン以降のものである場合は、前記すでに蓄積済みの特定のバージョン以降のコンテンツを前記スケジュール情報に従って受信したコンテンツで更新するステップと、
を有する受信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005312442A JP4184374B2 (ja) | 1998-05-07 | 2005-10-27 | 受信機及び受信方法 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP12505298 | 1998-05-07 | ||
| JP2005312442A JP4184374B2 (ja) | 1998-05-07 | 2005-10-27 | 受信機及び受信方法 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001215396A Division JP2002135219A (ja) | 1998-05-07 | 2001-07-16 | 放送局システム、受信機及び放送方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2006109503A JP2006109503A (ja) | 2006-04-20 |
| JP4184374B2 true JP4184374B2 (ja) | 2008-11-19 |
Family
ID=36378573
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005312442A Expired - Lifetime JP4184374B2 (ja) | 1998-05-07 | 2005-10-27 | 受信機及び受信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4184374B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090187593A1 (en) * | 2008-01-17 | 2009-07-23 | Qualcomm Incorporated | Methods and Apparatus for Targeted Media Content Delivery and Acquisition in a Wireless Communication Network |
-
2005
- 2005-10-27 JP JP2005312442A patent/JP4184374B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2006109503A (ja) | 2006-04-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100559006B1 (ko) | 방송국 시스템 및 수신기 | |
| KR100641594B1 (ko) | 데이터 전달 제어 방법, 데이터 전송 방법, 데이터 송신장치, 수신 장치 | |
| US7305696B2 (en) | Three part architecture for digital television data broadcasting | |
| US6160545A (en) | Multi-regional interactive program guide for television | |
| JP4035209B2 (ja) | サイクリックパケットデータ伝送システムの受信機 | |
| US5801753A (en) | Method and apparatus for providing an interactive guide to events available on an information network | |
| RU2518513C2 (ru) | Устройство и способ приема содержания, устройство и способ передачи содержания, программа и носитель записи | |
| KR100910878B1 (ko) | 전송기 및 그로부터 전송되는 신호들을 수신하도록 구성된 적어도 하나의 수신기를 포함하는 전송 시스템 | |
| US20070133610A1 (en) | Storage type broadcast system, transmitter and receiver | |
| KR100582310B1 (ko) | 프로그램 방송 시스템 | |
| JP2004520764A (ja) | 対話型アプリケーションの記録 | |
| US7908633B2 (en) | PMCP extension metadata, data stream generating device, digital data broadcasting emission system and digital data broadcasting emission method thereof | |
| CA2829750A1 (en) | Method for transmitting broadcast service, receiving method therefor, and receiving device therefor | |
| JP4111255B2 (ja) | デジタルテレビジョンシステムにおけるサービス情報を管理するための方法及び受信機 | |
| JP4184374B2 (ja) | 受信機及び受信方法 | |
| US20100257188A1 (en) | Method and apparatus for providing/receiving stereoscopic image data download service in digital broadcasting system | |
| JP4156032B2 (ja) | ディジタルテレビジョン伝送システムにおけるデータの索引付け方法 | |
| JP3704090B2 (ja) | 番組案内情報生成送出システム | |
| JP2002135219A (ja) | 放送局システム、受信機及び放送方法 | |
| JP3611998B2 (ja) | サイマル放送に対応した番組案内情報生成送出システムと装置 | |
| JP3685681B2 (ja) | 番組案内情報生成送出システムとその構成装置 | |
| JP4183528B2 (ja) | 放送受信装置、放送再送信システム | |
| US20050025451A1 (en) | Topic-oriented method of recording digital contents broadcast in accordance with a schedule | |
| KR20070022885A (ko) | 저장형 디지털 방송의 송신 장치 및 송신 방법 | |
| KR20070021329A (ko) | 저장형 디지털 방송 수신 장치 및 수신 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080325 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080526 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080610 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080722 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080812 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080903 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110912 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120912 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130912 Year of fee payment: 5 |
|
| EXPY | Cancellation because of completion of term |