JP4201074B2 - デジタルデータ送受信システムおよびその方法 - Google Patents
デジタルデータ送受信システムおよびその方法 Download PDFInfo
- Publication number
- JP4201074B2 JP4201074B2 JP2002046818A JP2002046818A JP4201074B2 JP 4201074 B2 JP4201074 B2 JP 4201074B2 JP 2002046818 A JP2002046818 A JP 2002046818A JP 2002046818 A JP2002046818 A JP 2002046818A JP 4201074 B2 JP4201074 B2 JP 4201074B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- file
- files
- directory structure
- digital data
- 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 - Fee Related
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、デジタルデータ送受信システムに関し、特に、受信したコンテンツデータのファイル記録方法に関する。
【０００２】
【従来技術】
今日、デジタル放送を蓄積記憶しておき、これを読み出してモニターに表示できるデジタル受信装置が知られている。
【０００３】
かかるコンテンツデータの蓄積方法について説明する。
【０００４】
送信側では以下のようにしてモジュールデータが構成モジュール管理情報であるデータＤＩＩとともに送信される。図３に示すディレクトリ構造のコンテンツデータが記憶されている場合、与えられたモジュール特定情報に基づいて、各コンテンツデータはモジュール化される。ここでは、ディレクトリ/shop1/books/indexに属するファイルindex.bml,index.pngがそれぞれ１のモジュール、ディレクトリ/shop1/books/ebook/indexに属するファイルebook-index.bml,ebook-index.pngがそれぞれ１のモジュール・・・として計６２のモジュールにモジュール化されたとする。
【０００５】
各モジュールデータはモジュール群特定情報に基づいて所定のモジュール群として同じデータＤＩＩにてカルーセル形式で繰り返し送信される。例えば、ディレクトリ/shop1/booksに属するモジュールを１のモジュール群として送信する場合、前記６２個のモジュールでモジュール群が構成されて、そのデータＤＩＩとともに送信される。データＤＩＩには当該モジュール群を構成するモジュールに関する管理データが含まれている。かかる管理データには、受信側で蓄積記憶する場合のディレクトリ構造が書き込まれる。なお、データＤＩＩはモジュールデータの送信に先立って送信される。
【０００６】
受信側ではかかるデータＤＩＩを受信すると、データＤＩＩに格納されているディレクトリ構造を読み出す。データＤＩＩの受信後、モジュールデータを受信するとこれを一旦バッファに書き込み、各モジュールを１のファイルとしてハードディスクに蓄積記憶するためのファイル書き込み準備処理（ファイルオープン処理）を行う。ファイルオープン処理完了すると、ハードディスクへの書き込み処理を行う。ハードディスクへの書き込み処理が終了するとバッファをクリアする。このようにして、受信側で図３のようなディレクトリ構造にてコンテンツデータを蓄積記憶することができる。
【０００７】
【発明が解決しようとする課題】
しかしながら、上記受信装置においては以下のような問題があった。データＤＩＩに基づいてハードディスク上へのファイル書き込み準備処理時間は、各モジュールデータの容量にかかわらずほぼ一定である。モジュールのデータ容量が大きい場合には、モジュールデータを受信している間に、つぎのモジュールデータのファイルオープン処理をすればいいので、かかるファイル管理情報の作成時間はそれほど問題とならない。これに対して、各モジュールのデータ容量が小さくなると、相対的にファイルオープン処理が間に合わず、その結果、バッファメモリへの一時記憶量が増大していき、バッファメモリがオーバフローとなるおそれがある。
【０００８】
かかる問題を防止するために、送信側では、各コンテンツデータをモジュール化して送信するときに、各モジュールのデータ量を所定量よりも多くなるように、マルチパート化して送信することも考えられる。しかし、これでは、各モジュールを構成するデータ量に制約ができる。
【０００９】
この発明は、上記問題を解決し、バッファメモリの容量を増やすことなく、１の構成モジュール管理情報で管理できるモジュールのデータ容量の自由度を高めたデータ送受信システムまたはその方法を提供することを目的とする。
【００１０】
【課題を解決するための手段】
１）本発明にかかるデジタルデータ送受信システムは、送信装置に、コンテンツデータを、ディレクトリ構造で管理された複数のファイルに分けて記憶しておき、前記送信装置から前記ディレクトリ構造の情報および前記複数のファイルをデジタル放送するとともに、受信装置で前記ディレクトリ構造の情報および前記複数のファイルを受信し、前記ディレクトリ構造にて前記複数のファイルを蓄積記憶するデジタルデータ送受信システムにおいて、前記送信装置は、前記ディレクトリ構造の情報をデータＤＩＩのプライベート領域に格納して、当該ＤＩＩの送信を複数回繰り返すことにより、前記複数のファイルをＤＤＢメッセージデータにて送信するまでの所定の猶予時間を確保し、前記受信装置は、前記データＤＩＩを受信すると、前記プライベート領域から前記ディレクトリ構造の情報を読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行する。
したがって、受信装置側でファイルの書き込み準備処理が間に合わないというおそれを少なくし、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。すなわち、データＤＩＩで管理される１モジュールのデータ量を小さくしても、確実な蓄積記憶が可能なデジタルデータ送受信システムを提供することができる。また、従来の送信処理を変更するだけで前記猶予時間を受信装置側に与えることができる。また、データＤＩＩが繰り返し送られてくるので、データＤＩＩの受信タイミングを多くすることができる。
【００１１】
２）本発明にかかるデジタルデータ受信装置は、ディレクトリ構造で管理された複数のファイルに分けて記憶されたコンテンツデータがデジタル放送されると、これを受信して前記ディレクトリ構造で管理された複数のファイルに分けて蓄積記憶するデジタルデータ受信装置において、データＤＩＩを受信すると、当該データＤＩＩの前記プライベート領域から、管理するファイルのディレクトリ構造の情報を読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行し、ＤＤＢメッセージデータにて前記複数のファイルを受信すると、前記書き込み準備ファイルに書き込み処理をする。
したがって、受信装置側でファイルの書き込み準備処理が間に合わないというおそれを少なくし、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００１２】
３）本発明にかかるデジタルデータ送信装置は、コンテンツデータを、ディレクトリ構造で管理された複数のファイルに分けて記憶しておき、前記ディレクトリ構造の情報および前記複数のファイルをデジタル放送するデジタルデータ送信装置において、前記ディレクトリ構造の情報をデータＤＩＩのプライベート領域に格納して、当該ＤＩＩの送信を複数回繰り返すことにより、前記複数のファイルをＤＤＢメッセージデータにて送信するまでに所定の猶予時間を確保する。
したがって、受信装置側でファイルの書き込み準備処理が可能となり、これにより、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００１３】
４）本発明にかかるデジタルデータ送信装置においては、１のデータＤＩＩで管理する総モジュール数は２つであり、前記所定時間は３０秒間である。したがって、受信装置側でファイルの書き込み準備処理が可能となる。
【００１５】
５）本発明にかかるデジタルデータ受信装置においては、前記読み出したディレクトリ構造の情報で管理されるファイルのうち、ファイル書き込み準備処理をまとめて実行した複数のファイルについて、当該複数のファイルの書き込み処理を終了してから、当該複数のファイルについての閉じ処理をする同じデータＤＩＩで特定される全ファイルの書き込み終了してから、前記全ファイルの閉じ処理をする。したがって、書き込み処理が何らかの原因で中断された場合には、書き込みは完了しない。これにより、更新等の場合に、一部のみ更新されるというおそれがない。
【００１６】
６）本発明にかかるデジタルデータ受信装置においては、前記コンテンツデータは、他のコンテンツデータへのリンク情報を含んでいる。したがって、複数のコンテンツデータによって、多彩なコンテンツを提供することができる。
【００１７】
７）本発明にかかるデジタルデータ受信装置においては、１のモジュールを１ファイルに記憶する。したがって、１のデータＤＩＩで管理されるモジュール数が増える場合でも、受信機にてより確実に蓄積記憶させることができる。
【００１９】
８）本発明にかかるデジタルデータ受信装置においては、ディレクトリ構造で管理された複数のファイルに分けて記憶されたコンテンツデータがデジタル放送されると、これを受信して前記ディレクトリ構造で管理された複数のファイルに分けて蓄積記憶するデジタルデータ受信装置において、データＤＩＩのプライベート領域から読み出したディレクトリ構造の情報で管理されるファイルのうち、ファイル書き込み準備処理をまとめて実行した複数のファイルについて、当該複数のファイルの書き込み処理を終了してから、当該複数のファイルについての閉じ処理をする。したがって、一部の書き込みが未完了で終了した場合には、ファイルの閉じ処理を行わず、全体として書き込みが終了しない限り、ファイル閉じ処理がなされない。
【００２０】
９）本発明にかかるデジタルデータ受信装置は、デジタル放送されたコンテンツデータを受信して蓄積記憶するデジタルデータ受信装置において、データＤＩＩを受信すると、当該データＤＩＩの前記プライベート領域から前記ディレクトリ構造の情報を読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行する。したがって、受信装置側でファイルの書き込み準備処理が可能となり、これにより、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００２１】
１０）本発明にかかるデジタルデータ受信装置は、前記データＤＩＩを受信すると、当該データＤＩＩの前記プライベート領域から前記ディレクトリ構造の情報を読み出してファイル開き処理準備の必要なファイルを決定する。したがって、データＤＩＩに開き処理決定に必要な情報を格納させることにより、１のモジュール数のデータ量を小さくしても、確実に各コンテンツデータを記憶させることができる。
【００２２】
１１）本発明にかかるデジタルデータ受信装置においては、前記複数まとめて実行されるファイル書き込み準備処理は、前記モジュールのインデックスデータを含むデータＤＩＩを受信する前に、所定数のファイルについて仮ファイル名で開き処理準備をしておき、データＤＩＩを受信すると、前記ディレクトリ構造で管理されるファイル名を抽出し、前記開き処理準備したファイルのファイル名を前記抽出したファイル名に変更する。したがって、予め多くのファイルについて開き準備処理が可能となる。
【００２３】
１４）本発明にかかるデジタルデータ受信装置は、ディレクトリ構造で管理された複数のファイルに分けて記憶されたコンテンツデータがデジタル放送されると、これを受信して前記ディレクトリ構造で管理された複数のファイルに分けて蓄積記憶するデジタルデータ受信装置において、ファイル管理情報を受信すると、当該ファイル管理情報にて管理するファイルのディレクトリ構造の情報を、当該ファイル管理情報から読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行する。したがって、受信装置側でファイルの書き込み準備処理が間に合わないというおそれを少なくし、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００２４】
１８）本発明にかかるデジタルデータ送受信システムは、コンテンツデータを複数のモジュール化し、各モジュールをモジュール群毎にまとめて、当該モジュール群に属するモジュールに関する構成モジュール管理情報とともにデジタル放送する送信装置、前記構成モジュール管理情報に基づいて、受信したモジュール化コンテンツデータをモジュール毎に１のファイルとして蓄積記憶する受信装置、を備え、前記送信装置は、前記ディレクトリ構造の情報をデータＤＩＩのプライベート領域に格納して、当該ＤＩＩの送信を複数回繰り返すことにより、前記複数のファイルをＤＤＢメッセージデータにて送信するまでに所定の猶予時間を確保し、前記受信装置は、前記構成モジュール管理情報を受信すると、前記モジュール化コンテンツデータをモジュール毎に１のファイルとして蓄積記憶させるためのファイル書き込み準備処理を、複数ファイルについてまとめて実行する。したがって、受信装置側でファイルの書き込み準備処理が間に合わないというおそれを少なくし、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００２５】
１９）本発明にかかるデジタルデータ送信装置は、モジュール化されたコンテンツデータを記憶しておき、各モジュールをモジュール群規則に基づいてモジュール群化して、モジュール群に属するモジュールに関する構成モジュール管理情報とともにデジタル放送するデジタルデータ送信装置において、前記構成モジュール管理情報の送信を複数回繰り返すことにより、前記前記モジュール化されたコンテンツデータを送信するまでの所定の猶予時間を確保する。したがって、受信装置側でファイルの書き込み準備処理が間に合わないというおそれを少なくし、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００２６】
【発明の実施の形態】
１．〔機能ブロックの説明〕
図１に、本発明にかかる発明にかかるデータ送受信システムをデジタル放送システムに適用した場合の機能ブロック図を示す。デジタル放送システム１０００は、送信装置１０１および受信装置１１０を備えている。
【００２７】
送信装置１０１は、コンテンツデータ記憶手段１０３、モジュール化手段１０５、モジュール化データ記憶手段１０６、構成モジュール管理情報生成手段１０７，および送信手段１０９を備えている。コンテンツデータ記憶手段１０３は、伝送対象であるコンテンツデータをファイル形式で記憶する。モジュール化手段１０５は、コンテンツデータ記憶手段１０３に記憶された各コンテンツデータをモジュール化規則に基づいて、モジュール化する。モジュール化データ記憶手段１０６は、モジュール化されたデータを記憶する。構成モジュール管理情報生成手段１０７は、モジュール化手段５から与えられたモジュール群規則に基づいてモジュール群化するときの構成モジュール管理情報を生成する。送信手段１０９は、構成モジュール管理情報生成手段１０７で生成された構成モジュール管理情報を所定回数繰り返し送信する。構成モジュール管理情報の繰り返し送信が終わると、当該モジュール管理情報で管理されるモジュールデータを送信する。
【００２８】
このような送信方法を採用したのは、後述するように、構成モジュール管理情報を受信装置が受信後、所定の猶予時間経過してから前記各モジュールデータを受信できるようにするためである。
【００２９】
受信装置１１０は、受信手段１１１、一時記憶手段１１３、制御手段１１５、および記憶手段１１７を備えている。受信手段１１１は前記送信されたモジュールデータのうち、選別条件に合致する構成モジュール管理情報およびモジュールデータを選別して受信する。一時記憶手段１１３は受信したデータを一時記憶する。制御手段１１５は、一時記憶手段１１３に一時記憶された構成モジュール管理情報に基づいて、記憶手段１１７の必要なファイル構築の前処理を行う。その際、前記モジュール化されたデータをファイルとして蓄積記憶させるためのファイル書き込み準備処理を複数ファイルについて実行する。これにより、複数のファイルについてファイルクリエイトおよびオープン処理が実行される。制御手段１１５は、複数のファイルについてのファイルクリエイトおよびオープン処理が終わると、一時記憶手段１１３に一時記憶されたモジュールデータを読み出して、記憶手段１１７に書き込むとともに、一時記憶手段１１３に一時記憶されたモジュールデータを消去する。その後、前処理が完了している次順位のモジュールデータについて、前記処理を繰り返す。
【００３０】
１のファイルについてファイルクローズ処理がなされると、前記構成モジュール管理情報で特定される次順位ファイルについて、前記前処理を行う。
【００３１】
このように、送信側では、構成モジュール管理情報を送信後、所定の猶予時間経過してから前記各モジュールデータを送信することにより、受信装置では、モジュールデータを受信前に構成モジュール管理情報に基づいて予め複数のファイルについてのクリエイト処理が可能となる。したがって、一時記憶手段１１３につぎつぎとデータが蓄積されてオーバフロー状態となることがない。
【００３２】
以下この発明を地上波デジタル放送に適用した場合について説明する。
【００３３】
２．〔送信装置の概要〕
図２に、上記の送信装置１の詳細ブロック図を示す。送信装置１０１は地上波デジタル放送用の送信装置であり、各コンテンツデータ（ＢＭＬファイル、画像データなど）を１のリソースとして、図８に示すように、複数のリソースをまとめた１のモジュールデータを生成し、これをブロック化したＤＤＢ(Download Data Block)メッセージデータをカルーセル形式で繰り返し送信する。各カルーセルには、当該カルーセルにて送信されているデータの管理データとして、各カルーセルごとにデータＤＩＩ(Download Info Indication)が送信される。
【００３４】
なお、受信側では、後述するように、データＤＩＩを参照して、必要なＤＤＢメッセージデータを受信し、各ＤＤＢメッセージのブロックデータを読み出して連結することにより、各コンテンツデータ（リソース）を再現することができる。
【００３５】
コンテンツデータ記憶部１６１には、図３に示すようなコンテンツデータが各ディレクトリに分類され、ファイルとして記憶されている。制御部１６２はスケジュール記憶部１６４に記憶された配信スケジュールデータに基づき、配信時刻よりも所定時間前になると、コンテンツデータ取得部１６３に取得命令を与える。コンテンツデータ取得部１６３は、コンテンツデータ記憶部１６１からデータを読み出して、記憶しているモジュール化規則に基づいて、モジュール化処理し、記憶する。
【００３６】
本実施形態においては、最下層ディレクトリ（ルートディレクトリから一番遠いディレクトリ）に記憶されているファイルを１のモジュールとしてマルチパート化するようにした。例えば、/shop1/books/index/index.bml,/shop1/books/index/index.pngの各ファイルについては、同じディレクトリ/shop1/books/indexに属しているので、これを１つのモジュールとする。
【００３７】
また、どのモジュールについて同じデータＤＩＩで送るかについても、モジュール化規則に記憶されている。
【００３８】
たとえば、サブディレクトリ"/books"に属する各モジュールを同じデータＤＩＩで送る（１のカルーセルで送信する）場合、以下のようにモジュール化される。
【００３９】
図２に示す制御部１６２はＤＤＢ生成部１６５にＤＤＢメッセージデータの生成命令を与える。ＤＤＢ生成部１６５は、コンテンツデータ取得部１６３に記憶されたモジュール化データを読み出して、図６に示すようなＤＤＢメッセージデータを生成し、記憶する。ＤＤＢメッセージデータのデータ構造は従来のデジタル放送の規格と同様である。本実施形態においては、図３に示すようなディレクトリ構造で各ファイルが管理されており、各ファイルにはコンテンツデータ（以下リソースと呼ぶ）が記憶されている。各モジュールは、図６に示すように、複数のリソースから構成される。各リソース間の関係（リソースのディレクトリ構造を表すリスト）はリソースリストに記述される。
【００４０】
たとえば、図３において、ディレクトリ/shop1/books/indexに属するファイルindex.bml,index.pngで１のモジュール、ディレクトリ/shop1/books/ebook/indexに属するファイルebook-index.bml,ebook-index.pngで１のモジュール、ディレクトリ/shop1/books/ebook/ebook1に属するファイルbook1.bml,ebook1.pngで１のモジュール、・・・と計３１のモジュールにモジュール化され、さらに、これら３１個のモジュールが１のモジュール群として１のデータＤＩＩにて送信される場合には、図１３に示す各モジュールのディレクトリ構造がデータＤＩＩに記述される。また、各モジュールのリソースリストには、当該モジュールにおける各リソースが相対パス形式で記述される。なお、１のモジュールで送信されるコンテンツデータについては、当該モジュールを構成するＤＢＢメッセージデータを全て受信し、これを連結することにより、目的のリソース（コンテンツ）を特定が可能となる。
【００４１】
このように、本実施形態においては、各モジュールが属するディレクトリ情報はデータＤＩＩに、各モジュール内のリソースについてのリソース間の関係はリソースリストに分けて記憶されている。しかし、これに限定されず、データＤＩＩに各リソースについてのディレクトリ構造を記憶させてもよい。
【００４２】
なお、上記実施形態においては、最下層ディレクトリに記憶されているリソースを１のモジュールとしてマルチパート化するようにしたが、モジュール化規則を変更することにより、１のモジュール内にさらにサブディレクトリが存在するように、モジュール化することもできる。この場合には、リソースリストに当該サブディレクトリの構造を記述される。
【００４３】
このようにモジュール内のリソースリストはリソースをまとめたディレクトリからの相対パスで記述することにより、絶対パスで記述した場合と較べて、リソースリストのデータ容量が膨大になることを防ぐことができる。
【００４４】
データＤＩＩについて説明する。データＤＩＩ生成部１６６は、図７に示すようなデータ構造のデータＤＩＩを生成する。データＤＩＩのデータ構造自体は、従来のデジタル放送の規格に則ったものである。データＤＩＩのデータ構造について説明する。データＤＩＩは、DSM-CCメッセージヘッダ、ダウンロード識別子、モジュール数、モジュール管理データ、プライベートデータなどで構成されている。モジュール管理データは、モジュールごとに、モジュール識別子（id)、モジュールサイズ、モジュール情報で構成されている。
【００４５】
プライベートデータ領域には、各ファイルが所属するルートディレクトリがルート記述子（StoreRoot記述子）に、そのサブディレクトリ構造がサブディレクトリ記述子に記憶されている。例えば、図３において、サブディレクトリ「/shop1/books」に属するファイルを１のデータＤＩＩで送信する場合は、ルート記述子にディレクトリ「shop1」が、そのサブディレクトリ記述子に「books」が記憶される。なお、サブディレクトリ「books」以下のディレクトリ構造は、既に説明したように、ＤＤＢメッセージデータのリソースリストに記述される。
【００４６】
データＤＩＩを構成するデータのうち、モジュール数はコンテンツデータ取得部１６３のモジュール化規則に基づいて決定される。
【００４７】
制御部１６２はスケジュール記憶部１６４に記憶された配信スケジュールに基づき、配信時刻になると、データＤＩＩ送出部１７６に対して、データＤＩＩを所定回数繰り返し送るようにデータＤＩＩ送出命令を与える。データＤＩＩ送出部１７６は、これによって、データＤＩＩを多重化コントローラ１８０に送出する。制御部１６２はまた、データＤＩＩ送出命令を与えたあと、ＤＤＢ送出部１７５にＤＤＢ送出命令を与える。多重化コントローラ１８０はこれらを多重化し、変調部１８１に出力する。これにより、トランスポートストリームとしてデータＤＩＩおよび当該データＤＩＩにて管理されるＤＤＢメッセージデータが図８に示すように、送信される。
【００４８】
なお、本実施形態においては、複数のファイルのデータを１のモジュールにまとめたマルチパート形式で送信したが、シングルパート形式（１のモジュールで１のファイルを送る）ようにしてもよい。
【００４９】
３．〔送信装置のハードウェア構成〕
図４を用いて、送信装置１０１のハードウェア構成について説明する。本実施形態においては、送信装置１０１は、多重化処理部および変調部以外は、ＣＰＵを用いてソフトウェアで実現した。
【００５０】
送信装置１０１は、ＣＰＵ１２３、メモリ１２７、ハードディスク１２６、モニタ１３１、入力部１３０、およびバスライン１２９を備えている。ＣＰＵ１２３は、ハードディスク１２６に記憶されたプログラムにしたがいバスライン１２９を介して、各部を制御する。ハードディスク１２６には、モジュール化規則、配信スケジュールデータ、コンテンツデータおよび制御プログラムが記憶される。図５を用いて、かかる制御プログラムによる処理について説明する。
【００５１】
ＣＰＵ１２３は、配信スケジュールデータに基づいて、コンテンツデータをハードディスク１２６から読み出して、モジュール化規則に基づいて、モジュール化してメモリ１２７に記憶する（ステップＳ１）。処理番号kを初期化し（ステップＳ２）、モジュール化規則に基づいて、処理番号k番目のデータＤＩＩで送信するモジュールデータを決定する（ステップＳ３）。データＤＩＩを生成し、メモリ１２７に記憶する（ステップＳ５）。データＤＩＩを構成するデータのうち、モジュール数をモジュール化規則に基づいて決定するとともに、各コンテンツデータがファイルとして管理されていた際の、各ファイルの関係、すなわち、ディレクトリ構造をデータＤＩＩのプライベート領域に書き込む。また、ステップＳ１にてメモリに書き込んだモジュール化データを、所定の固定長のブロック（４０６６バイト）に分割して、ＤＤＢメッセージデータとして、メモリに書き込む（ステップＳ７）。
【００５２】
ＣＰＵ１２３は、データＤＩＩ繰り返し送出回数を決定する（ステップＳ９）。本実施形態においては、データＤＩＩ先出し期間を２０秒とし、２０秒間繰り返されるように、送出回数を決定した。
【００５３】
ＣＰＵ１２３は、配信スケジュールデータに基づいて、データＤＩＩ送出開始時期か否かを判断する（ステップＳ１１）。データＤＩＩ送出開始時期になると、データＤＩＩを多重化コントローラ１８０に送出する（ステップＳ１３）。所定回数データＤＩＩを繰り返し送出したか否か判断し（ステップＳ１５）、所定回数送出するまで、ステップＳ１３の処理を繰り返す。所定回数データＤＩＩを送出すると、当該データＤＩＩを管理データとするＤＤＢメッセージデータを多重化コントローラ１８０に送出する。多重化コントローラ１８０はこれを多重化して、トランスポートストリームとして変調部１８１から送信される。
【００５４】
ＣＰＵ１２３は、全モジュールを送信したか否か判断し（ステップＳ１９）、送信していない場合には、処理番号kをインクリメントし（ステップＳ２０）、ステップＳ３以下の処理を繰り返す。送信済みの場合には処理を終了する。
【００５５】
４．〔受信装置のハードウェア構成〕
図９を用いて、図１に示す受信装置１１０のハードウェア構成について説明する。受信装置１１０は、チューナ１３２、トランスポートストリームデコーダ（ＴＳデコーダ）１３４、ＡＶデコーダ１３６、ＯＳＤ（On Screen Display）１３８、ＲＯＭ１４０、ＲＡＭ１４２、ＣＰＵ１４４、ハードディスク１４６、モデム１４８、信号受信部１５０を備えている。
【００５６】
衛星放送のデータ受信機能としては、従来とほとんど同様である。簡単に説明すると、アンテナ１３０は、送信装置からの電波を捕捉して、チューナー１３２に供給する。チューナー１３２は、ＣＰＵ１４４の指示に従って、１つのトランスポートストリームを選択的に受信する。さらに、チューナー１３２は、復調処理や誤り訂正処理などを行い、トランスポートデコーダ（以下ＴＳデコーダという）１３４に出力する。
【００５７】
ＴＳデコーダ１３４は、トランスポートストリームに多重化されているパケットのうち、ＣＰＵ１４４によってセットされたフィルタリング条件に基づいて、所望のパケットだけを選別する。ＴＳデコーダ１３４は、パケットのヘッダ情報に基づいて、各種の制御データおよびＭＰＥＧ２システムデータをＲＡＭ１４２に記憶する。ＤＤＢメッセージデータを１モジュール分受信すると、ＲＡＭ１４２にモジュールとして一時記憶する。蓄積部であるハードディスク１４６には、後述する蓄積処理によって、受信したコンテンツが蓄積記憶される。なお、信号受信部１５０は、リモコン装置からの信号などを受信するためのものである。
【００５８】
本実施形態においては、１のモジュールに複数のリソース（コンテンツデータ）がマルチパート化されており、ＲＡＭ１４２にはリソース単位ではなく、モジュール単位で記憶される。ＲＡＭ１４２に一時記憶されたデータは、ハードディスク１４６に書き込まれると、削除される。すなわち、ハードディスク１４６には、モジュールの数だけのファイルが記憶される。
【００５９】
なお、このプログラムは、単独で機能するプログラムであってもよいが、オペレーティングシステム（マイクロソフト社のwindows CEなど）を前提として機能するものであってもよい。
【００６０】
５．〔受信制御プログラム〕
かかる処理を行う制御プログラムについて図１０〜図１２を用いて説明する。ＲＯＭ１４０には、制御プログラム（図示せず）が記録されている。なお、ＣＰＵ１４４に対する指令は、リモコン（図示せず）から与えられ、信号受信部１５０がこれを受信して、ＣＰＵ１４７に与えられる。以下では、図３に示すようなディレクトリ構造で各モジュールに格納されたコンテンツデータを、はじめて蓄積記憶する場合について説明する。
【００６１】
ユーザがサービス受信命令を与えると、ＣＰＵ１４４は、データＤＩＩのパケットＩＤ（ＰＩＤ）などのフィルタリング条件を、図９に示すＴＳデコーダ１３４に設定する。これにより、チューナ１３２によって選択されたトランスポートストリーム中から、データＤＩＩが選択され、ＣＰＵ１４４に与えられる
ＣＰＵ１４４は、データＤＩＩを受信したか否か判断しており（ステップＳ２１）、データＤＩＩを受信すると、前処理を行う（ステップＳ２３）。ステップＳ２３の処理の詳細フローチャートを図１１に示す。
【００６２】
ＣＰＵ１４４は、データＤＩＩから、当該モジュールデータを構成するコンテンツデータの所属ディレクトリ名を取得する（ステップＳ５１）。当該ディレクトリが既に存在するか否か判断し（ステップＳ５２）、存在しない場合には、蓄積先ディレクトリを作成する（ステップＳ５３）。例えば、データＤＩＩに図１３に示すようなディレクトリ情報が記述されている場合、ディレクトリ"/shop1/books/index"、"/shop1/books/ebook/index"・・・などが既に存在するか否か判断する。この場合存在しないので、蓄積先ディレクトリを生成する。
【００６３】
蓄積先ディレクトリ生成処理の詳細フローチャートを図１２に示す。ＣＰＵ１４４は、ハードディスク１４６に記憶されたディレクトリインデックスを取得する（ステップＳ６１）。この場合、はじめてなので、ディレクトリインデックスは存在しない。したがって、ディレクトリ情報としてはルートディレクトリが存在することだけが、読み出される。
【００６４】
ＣＰＵ１４４は、各モジュールを格納するファイルのファイルインデックスを作成する（ステップＳ６３）。具体的には、そのファイルのデータを格納する領域へのリンク情報を記憶する。例えば、あるモジュールを構成するデータをそのモジュール識別子で特定されるファイル名で領域xxxxx1〜xxxxx9に格納する場合、当該ファイル名と当該領域とのリンク情報が記憶される。本実施形態においては、当該ファイル名として、モジュールＩＤを用いるようにした。
【００６５】
ＣＰＵ１４４は、生成したファイルインデックスをインデックスリストに追加する（ステップＳ６５）。具体的には、ファイル管理システムが管理するインデックスリストに、作成したファイルインデックスを追加する。この場合、ステップＳ６３で生成されたファイル名と当該領域とのリンク情報が追加記憶される。
【００６６】
ＣＰＵ１４４は、ディレクトリインデックスを更新する（ステップＳ６７）。具体的には、追加したファイルインデックスへリンクを張るためのインデックスをステップＳ６１で取得したディレクトリインデックスに追加する。この場合、所属するディレクトリとして、ルートディレクトリの下に、ディレクトリ/shop1/books/indexが存在することが記憶される。
【００６７】
つぎに、ＣＰＵ１４４は、カルーセル内の全モジュール数を取得する（図１１ステップＳ５５）。カルーセル内の全モジュール数とは、当該データＤＩＩで管理されるモジュール数であり、データＤＩＩのモジュール数領域（図７参照）を参照すればよい。
【００６８】
つぎに、ＣＰＵ１４４は、一括処理ファイル数nを算出する。一括処理ファイル数nとして、本実施形態においては、以下の計算式を満たす一括処理ファイル数nの最大値を求めるようにした。
【００６９】
Td>N*Tcl+Tm*d+n*Tcr・・・・（１）
ここで、Td：データＤＩＩ先出し期間（固定）、Tcr：１ファイルのファイル作成所要時間（固定）、N：１のデータＤＩＩで管理できる最大モジュール数（固定）、Tcl：１ファイルのファイルクローズの所要時間（固定）、Tm：ディレクトリ作成所要時間（固定）、d：ディレクトリ階層最大数（固定）とする。
【００７０】
なお、前記（１）式にて、ファイルクローズの時間をファイル数Ｎ分考慮しているのは、その前のデータＤＩＩにてオープンしたファイルをクローズする必要があるからである。後述するように、ファイルクローズ処理をまとめて行う場合には、考慮する必要はない。
【００７１】
つぎにＣＰＵ１４４は、ステップＳ５７で決定したn個分のファイルについて、オープン処理をまとめて行う（ステップＳ５９）。
【００７２】
かかる前処理が終了すると、ＣＰＵ１４４は、処理番号iを初期化するとともに、次期オープンファイル番号jをj=n+1とする（図１０ステップＳ２５）。ＣＰＵ１４４は、最初のファイルに格納するモジュールデータを受信するか否か判断し（ステップＳ２７）、これを受信すると、ハードディスクに書き込む（ステップＳ２９）。書き込みが完了するまでこれを繰り返し（ステップＳ３１）、書き込みが完了すると、一時記憶していたメモリのバッファ領域から当該モジュールデータを削除する（ステップＳ３２）。
【００７３】
ＣＰＵ１４４は、次期オープンファイル番号jが最大ファイル数Ｎを越えていないか否か判断し（ステップＳ３３）、越えていない場合には、j番目のファイルについて、ファイル作成処理およびファイルオープン処理を行う（ステップＳ３５）。次期オープンファイル番号jおよび処理番号iをインクリメントし（ステップＳ３７、ステップＳ３９）、処理番号iが最大ファイル数を越えていなければステップＳ２７以下を繰り返す。処理番号iが最大ファイル数を越えると、終了と判断して、Ｎ個のファイルについてファイルクローズ処理を行う（ステップＳ４３）。
【００７４】
かかる蓄積データの再生処理については従来と同様である。操作者から与えられた操作指令が蓄積コンテンツの再生である場合には、ハードディスクから該当のリソースを読み出して、モニタ（図示せず）に出力する。これにより、蓄積コンテンツが再生される。なお、この場合１のモジュールデータは、複数のリソースで構成されており、必要なリソースについてはリソースリストを参照することにより、読み出すことができる。
【００７５】
本実施形態においては、所定時間繰り返して送られてくるデータＤＩＩを受信している間に、比較的時間を要するオープン処理を、ＤＤＢメッセージデータ受信前に複数ファイルについてまとめて行う。これにより、１のモジュールのデータ量を少なくして、モジュール数が増えた場合であっても、データＤＩＩ送出後、連続してＤＢＢメッセージデータを送出するような形式であっても、受信装置にてバッファがあふれるおそれを少なくすることができる。
【００７６】
かかる効果について、図１４〜図１６を用いて説明する。図１４は１のモジュールのデータ量が多い場合である。この場合には、結果的にモジュールの数が少なくなるので、各モジュールの前処理および後処理がそれほど頻繁におこらず、バッファ使用量がハードディスクへの書き込み処理が完了すると、つぎつぎと増えていくおそれがほとんど無い。
【００７７】
一方、図１５は１のモジュールのデータ量が少なく、結果的にモジュールの数が多くなる場合である。このような場合には、所要時間が必要な各モジュールの前処理および後処理が頻繁におこる。このため、バッファしておく必要のあるデータが減らず、バッファ使用量がどんどん増えていき、バッファがオーバフローするおそれがある。
【００７８】
このように１のモジュールのデータ量が少なく、結果的にモジュールの数が多くなる場合であっても、本実施形態のように複数ファイルについて、ファイルオープン処理をデータＤＩＩ受信中に行っておくことにより、バッファオーバフローを防止しやすくなる。
【００７９】
また、送信側にて、１のモジュールで送るデータ量が小さくなった場合に、送信側にてデータＤＩＩの繰り返し送信期間を変更し、これを受信側に通知することにより、受信側のバッファオーバフローにならないようコントロールすることもできる。
【００８０】
なお、図１４〜図１６においては、１モジュールを１ファイルに格納する場合について説明したが、蓄積コンテンツについては、各リソースを１のファイルとして展開して記憶するようにしてもよい。
【００８１】
なお、上記実施形態においては、データＤＩＩを繰り返し送ることにより、データＤＩＩ送出後、ＤＤＢメッセージデータ受信開始までの猶予時間を確保するようにしている。かかる繰り返し送信処理は、プログラムを若干修正することができるので、対応が容易である。なお、ＤＤＢメッセージデータ受信開始までの猶予時間を確保できる形式であれば、データＤＩＩを繰り返し送らなくてもよい。
【００８２】
上記実施形態においては、新たに蓄積コンテンツを記憶する場合について説明したが、蓄積コンテンツを更新する場合には以下のような処理をすればよい。なお、更新か否かは、既に同じ名前のファイルが記憶されているかはないかで判断すればよい。更新の場合は、ファイル作成およびオープン処理の際に、空ファイルで、実行する。そして、この空ファイルに一旦データを書き込み、更新元のファイルを削除してから、前記空ファイルのファイル名を削除したファイル名に変更すればよい。このように、更新の際には、更新元ファイルの削除およびファイル名変更の時間がかかることから、図１１ステップＳ５７の一括処理ファイル数nの算出時には、更新元ファイルの削除およびファイル名変更の時間を考慮するようにすればよい。
【００８３】
本実施形態においては、１のモジュールに複数のファイルがマルチパート化されている場合について説明したが、複数のモジュールで１のファイルを構成するようにしてもよい。この場合は、各モジュールを構成する全ＤＤＢメッセージデータを一時記憶し、各モジュールデータを再現し、さらにこれらのモジュールデータから１のファイルを再現するようにすればよい。
【００８４】
上記実施形態においては、後処理をまとめて実行するようにした（図１０ステップＳ４３参照）。これにより、更新の際には、１のカルーセルで送信される全モジュールが、受信された場合に更新されることとなる。
【００８５】
また、データＤＩＩ受信後、モジュールデータを受信する前に、前処理を複数モジュールについてまとめて行っているが、これに限定されない。
【００８６】
上記実施形態においては、受信装置１１０として、いわゆるセット・トップ・ボックスを例として説明したが、モニタを含むテレビ受像機として構成してもよい。
【００８７】
なお、上記実施形態においては、ファイルをＭＰＥＧ−２トランスポートストリーム上のＤＳＭ−ＣＣオブジェクトカルーセルとＤＳＭ−ＣＣデータカルーセルで伝送したが、同様の処理が行える他のプロトコルで伝送してもよい。
【００８８】
上記各実施形態においてはデジタル衛星放送でデジタルデータ伝送を行う場合について説明したが、デジタル地上波放送、さらにケーブルテレビ等の有線放送にも同じように適用することができる。
【００８９】
上記実施形態においては、図１の各ブロックの機能をハードウェアおよびＣＰＵを用いて実現した場合について説明したが、いずれをハードウェアで構成するかについては、特に限定されず、さらに、ソフトウェアで構成した部分を一部または全部をハードウェアロジックによって構成してもよい。
【００９０】
本実施形態においては、ＲＯＭに表示プログラムを記憶するようにしたが、ＩＣカードやＣＤ−ＲＯＭ等の記憶媒体に記憶し、ＩＣカードドライブやＣＤ−ＲＯＭドライブを介して、不揮発性メモリに転送して記憶するようにしてもよい。さらに、通信（放送を含む）でかかるプログラムを転送して、不揮発性メモリに記憶するようにしてもよい。
【００９１】
また、前記プログラムは、信号搬送波と一体化されたコンピュータデータ信号として、伝送することができる。
【００９２】
なお、本実施形態においては、コンテンツデータの記述形式として、ＢＭＬデータを用いたが、文書データを表示する場合の配置位置、文字列の大きさ、参照する図形データに関する情報等の表示指定情報が付加されたデータであればどのような物であってもよく、ＳＧＭＬ，ＨＴＭＬ，ＸＭＬ型データ、ＭＨＥＧ規格のデータ等であってもよい。また、かかるＢＭＬデータにリンクされる画像、音声データ等もコンテンツデータを構成する。
【００９３】
なお、本実施形態においては、コンテンツデータが多層の階層構造で記憶されている場合について説明したが、かかる階層構造については限定されない。
【００９４】
また、上記実施形態においては、本件発明を、１のデータＤＩＩで送信するモジュール数が増えた場合の課題を解決するものとして説明した。しかしながら、１のデータＤＩＩで送信する総モジュール数が少ない場合でも、バッファ領域からハードディスクへの１モジュール単位ではなくそのつど転送し、転送されるとバッファからデータ削除する場合には、本発明を適用することにより、少ないバッファ容量でもバッファオーバフローを防止することができる。
【００９５】
たとえば、１のデータＤＩＩで送信する最大モジュール数が２つである場合、１のカルーセルで送信できる最大サイズは254.125ＭＢ（4066×216バイト）である。したがって、１のカルーセルを構成するモジュールの総サイズは254.125メガバイト（4066×216バイト）以下となる。この場合、第１のモジュールデータについてハードディスクへの書き込みが終了してから、第２のモジュール用のファイルをハードディスクに前処理すると、当該前処理が完了するまで第２のモジュール用のデータをバッファに蓄積しておく必要がある。これに対して、本件発明のように、送信側ではデータＤＩＩを所定時間（例えば３０秒）送信しておき、受信側では、前記２つのモジュールデータ蓄積用のファイルをまとめて前処理しておくことにより、前記２つのモジュールデータの受信が開始されても、バッファ領域に一時記憶したデータのうち、ハードディスクに転送したデータについては、その都度データを削除することができる。このように、第２のモジュール用のファイル前処理に要する時間が不要となり、バッファ容量を少なくすることができる。
【００９６】
６．〔他の実施形態〕
本発明にかかる他の実施形態における受信システムのブロック図を図１７に示す。なお、以下のすべての実施の形態において、同様の機能を有する構成要素には同じ符号を付し、説明を省略する。
【００９７】
図１７の受信システムは、受信装置１０、および記録媒体２０を有する。受信装置１０は、受信部１１、記録部１２および一括処理数保持部１３を有する。受信部１１は、データ群を受信する。データ群の受信は、一般的にはデジタルテレビ放送であるが、アナログテレビ放送でも、ケーブルテレビでも、インターネットなどの通信によるデータ受信でも良い。また、データ群とは、データの集合であり、固定長でも不定長でも良い。また、データ群は、動画であるテレビ番組や静止画、テキストからなるデータ、静止画およびテキストの組み合わせ、音楽データ、コンピュータプログラム、スクリプトなど何でも良い。
【００９８】
記録部１２は、受信部１１で受信したデータを記録媒体２０に記録する。記録媒体２０については、以下に詳述する。
【００９９】
一括処理数保持部１３は、記録部１２が一括処理するデータ群の数を保持する。記録媒体２０は、例えばハードディスクである。しかし、記録媒体２０は、ハードディスクだけにとどまらず、ＣＤ、ＤＶＤ―ＲＡＭなどの光ディスク、半導体メモリなど、データを記録可能な媒体はいずれの媒体でも良い。
【０１００】
次に、図１８のフローチャートに基づいて受信装置１０の動作を説明する。
【０１０１】
（ステップＳ２０１）記録部１２は、受信部１１がヘッダー情報を受信したか否か判断する。ヘッダー情報を受信しておれば、ステップＳ２０２に行く。ヘッダー情報を受信していなければステップＳ２０１に戻る。なお、ヘッダー情報とは、データ群を送信する前に送られる情報であり、例えば、データ群を格納するディレクトリ名や、受信するデータ群の数や一括処理するデータ群数などの情報が記入されている。ただし、上記の三種類の情報だけでなく、ヘッダー情報の内容は、種々考えられ、また上記三種類の情報が必須であるとも限らない。
【０１０２】
（ステップＳ２０２）記録部１２は、受信部１１が受信したヘッダー情報からディレクトリ名を取り出す。記録部１２は、そのディレクトリ名を持つディレクトリを作成する。
【０１０３】
（ステップＳ２０３）記録部１２は、ヘッダー情報から一括処理数（ここでは、ｎとする。）を取り出す。ここで、一括処理数とは、記録部１２が一括処理するデータ群数である。
【０１０４】
（ステップＳ２０４）記録部１２は、ｎ個のデータ群を記録媒体２０に記録するための前処理（以下、前処理という。）を行う。ここで、例えば、１データ群を１ファイルに記録する場合を想定する。この場合、前処理とは、ファイル生成処理およびファイルオープン処理である。
【０１０５】
（ステップＳ２０５）記録部１２は、ステップＳ２０４の処理がエラーか否かを判断する。エラーであればステップＳ２０４に戻り、エラーでなければステップＳ２０６に行く。前処理におけるエラーか否かの判断は、例えばファイルポインタが正常にリターンされない、等で判断可能である。内部の処理では記録媒体における記憶領域が確保できなかった場合などが該当する。
【０１０６】
（ステップＳ２０６）変数ｉに０を代入する。
【０１０７】
（ステップＳ２０７）記録部１２は、受信部１１がｉ番目のデータ群を受信したか否かを判断する。受信していればステップＳ２０８に行き、受信していなければステップＳ２０７に戻る。
【０１０８】
（ステップＳ２０８）記録部１２は、ｉ番目のデータ群を記録媒体２０に記録するため処理（以下、本処理という。）を行う。ここで、本処理とは、データ群の書きこみ処理である。
【０１０９】
（ステップＳ２０９）記録部１２は本処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２０８に戻る。エラーは発生していなければステップＳ２１０に行く。なお、エラーが発生したか否かは、例えばデータＤＩＩ中にあるデータ群のサイズを取り出し、記録したデータ群のデータサイズと比較して、一致していなければエラーが発生したと判断する。その他、記録（ｗｒｉｔｅ）処理が正常終了しなかった場合はエラーとして判断する、など種々、エラー判断の方法は考えられる。
【０１１０】
（ステップＳ２１０）記録部１２は、ｉ番目のデータ群を記録媒体２０に記録した後の処理（以下、後処理という。）を行う。ここで、後処理とはファイルクローズ処理である。
【０１１１】
（ステップＳ２１１）記録部１２は、ステップＳ２１０における後処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２１０に戻り、エラーが発生していなければステップＳ２１２に行く。後処理のエラーとは、ファイルのクローズに失敗した場合がある。
【０１１２】
（ステップＳ２１２）記録部１２は、（ｎ＋ｉ）番目のデータ群の前処理を行う。
【０１１３】
（ステップＳ２１３）記録部１２は、ステップＳ２１２での処理がエラーか否かを判断する。エラーであれば、ステップＳ２１２に戻り、エラーでなければステップＳ２１４に行く。ここで、例えば、ファイルオープン処理（関数ｆｉｌｅｏｐｅｎ（）を実行する）を行った場合を想定する。エラーか否かの判断は、ファイルオープン関数の実行時のリターン値（ファイルポインタがリターンされる）が妥当なファイルポイントであるか否かによる。
【０１１４】
（ステップＳ２１４）ｉにｉ＋１を代入する。ステップＳ２０７に行く。
【０１１５】
次に、上記で説明した受信装置の具体的なデータ群の書き込み処理の例について図１９を用いて説明する。本具体例において、受信装置はデジタルテレビである。また、データ群は、１ＭＢのデータである。また、記録部１２における記録は、データ群をファイルに記録する。また、前処理は、ファイル生成処理（ｃｒｅａｔｅ）、ファイルオープン処理（ｏｐｅｎ）である。本処理は、データ群の書き込み処理（ｗｒｉｔｅ）である。後処理は、ファイルクローズ処理（ｃｌｏｓｅ）である。
【０１１６】
かかる場合に、放送局からデータＤＩＩというヘッダーが送信される。データＤＩＩは、データ群の長さ（本具体例では、１ＭＢ）、データ群の数、データ群の識別子、データ群のバージョン、データ群を記録するディレクトリ名、一括処理するデータ群数（一括処理数）などを含む。なお、データ群とは、図３においては、モジュール（ｍｏｄｕｌｅ）と言う。
【０１１７】
次に、受信部１１はデータＤＩＩを受信する。ここで、受信部１１は、例えば、チューナーおよびデータを記録するメモリなどのハードウェアで実現されている。次に、記録部１２は、データＤＩＩからディレクトリ名を取り出し、ディレクトリを作成する。そして、記録部１２は、データＤＩＩ中の一括処理数（本具体例では、５とする。）を取得する。次に、記録部１２は一括処理数を一括処理数保持部１３に記録する。なお、一括処理数は、データＤＩＩ中に含まれていることが必須ではなく、受信装置に予め格納されていても良いし、インターネットを経由して通信で取得される、またはＤＶＤ等の蓄積媒体から取得されるなど、種々の手段で取得されても良い。
【０１１８】
そして、記録部１２は取得した一括処理数（５）のファイルの生成およびオープンを行う。記録部１２は、以上の前処理により５つのファイルポインタを得る。そして、受信部１１は０番目（０番目から始まる）のモジュールを受信する。次に、記録部１２は、０番目のモジュールを受信部１１から取り出し、モジュールの内容を記録媒体２０に記録（ｗｒｉｔｅ）する。記録の際に、０番目のファイルポインタを記録する関数に引数として渡す。記録が終了すると、０番目のファイルをクローズする。
【０１１９】
次に、５番目のファイルの前処理（ｃｒｅａｔｅ、ｏｐｅｎ）を行う。なお、記録部１２が０番目のモジュールを受信部１１から取り出した後、１番目のモジュールを受信部１１が受信する。この１番目のモジュールを受信している間に、上記の処理、つまり、０番目のデータのｗｒｉｔｅ、ｃｌｏｓｅ、５番目のデータのｃｒｅａｔｅ、ｏｐｅｎを行う。このファイル処理（ｃｒｅａｔｅ、ｏｐｅｎ、ｗｒｉｔｅ、ｃｌｏｓｅ）は、ソフトウェアにより実現される。勿論、図示しないＣＰＵがソフトウェアを解釈実行して、ファイル処理を行う。つまり、記録部１２は、例えばＣＰＵとソフトウェアで実現されている。
【０１２０】
次に、記録部１２は、１番目のモジュールを取り出し、１番目のファイルポインタで識別されるファイルにそのモジュールを記録する。そして、記録部１２は、１番目のファイルをクローズする。
【０１２１】
次に、記録部１２は、６番目のファイルの前処理を行う。
【０１２２】
以下、図１９に示す流れで処理が行われる。
【０１２３】
なお、上記において複数のデータ群に対する前処理は一括して行われた。この「一括して行う」とは、前処理のｃｒｅａｔｅ、ｏｐｅｎが連続して行われた場合だけでなく、２つの処理の間に別の処理があっても良い。また、「一括して行う」の意味として、モジュール０の前処理とモジュール１の前処理は連続して行われることが普通であるが、これに限らず、モジュール０の前処理とモジュール１の前処理の間に別の処理が行われる場合も含まれる。つまり、「一括して行う」とは、前処理をモジュールの書き込み処理中には行わず、前もって行うことを言う。
【０１２４】
以上のように、本実施の形態によれば、複数のデータ群を連続して受信して記録する際に、最初に複数のデータ群の前処理を一括して行うことにより、データ群受信または記録中にエラーが発生した場合にも、エラーとなった処理を再度行う（リトライする）ことにより、すべてのデータ群を安全に記録媒体に記録することができる。
【０１２５】
なお、本実施の形態において、データはファイルに記録されたが、データベースに記録されても良い。かかる場合、前処理は、例えばテーブル生成およびテーブルオープンであり、本処理はテーブルへの書き込みであり、後処理はテーブルクローズである。また、ファイルやデータベース以外の論理構造を持つ対象に記録されても良い。以下、すべての実施の形態において同じである。
【０１２６】
また、本実施の形態において、受信部１１はチューナーを含むハードウェアで実現され、記録部１２はＣＰＵとソフトウェアで実現されていたが、受信部１１も一部ソフトウェアで実現しても良いし、記録部１２もソフトウェアではなく、すべてハードウェア（回路）で実現しても良い。
【０１２７】
また、本実施の形態において、データ群は１ＭＢの固定長のデータブロックであったが、不定長のデータであっても良い。かかる場合、データ群の長さは、データＤＩＩ（ヘッダー）に格納されているのが通常である。以下、すべての実施の形態において、データ群は同様である。
【０１２８】
さらに、上述の記録部１２の記録処理をソフトウェアで実現して、そのソフトウェアをインターネット等のネットワークや放送により流布しても良い。また、そのソフトウェアをＣＤ−ＲやＤＶＤなどのコンピュータ読取可能な記録媒体に記録して流通させても良い。以下、すべての実施の形態において、記録部の各種処理は同様である。
【０１２９】
他の実施形態における受信システムの概要図を図２０に示す。
【０１３０】
図２０の受信システムは、受信装置４０、記録媒体２０を有する。受信装置４０は、受信部１１、記録部４２を有する。記録部４２は、受信部１１で受信したデータを記録媒体２０に記録する。記録の方法が記録部１２とは異なる。
【０１３１】
本実施形態における記録部４２の記録の方法について以下、詳述する。まず、図２１のフローチャートに基づいて受信装置４０の動作を説明する。
【０１３２】
（ステップＳ２０１）記録部４２は、受信部１１がヘッダー情報を受信したか否か判断する。ヘッダー情報を受信しておれば、ステップＳ２０２に行く。ヘッダー情報を受信していなければステップＳ２０１に戻る。
【０１３３】
（ステップＳ２０２）記録部４２は、受信部１１が受信したヘッダー情報からディレクトリ名を取り出す。記録部４２は、そのディレクトリ名を持つディレクトリを作成する。
【０１３４】
（ステップＳ２０３）記録部４２は、ヘッダー情報から一括処理数（ここでは、ｎとする。）を取り出す。
【０１３５】
（ステップＳ２０４）記録部４２は、ｎ個のデータ群の前処理を行う。
【０１３６】
（ステップＳ２０５）記録部４２は、ステップＳ２０４の処理がエラーか否かを判断する。エラーであればステップＳ２０４に戻り、エラーでなければステップＳ２０６に行く。
【０１３７】
（ステップＳ２０６）変数ｉに０を代入する。
【０１３８】
（ステップＳ２０７）記録部４２は、受信部１１がｉ番目のデータ群を受信したか否かを判断する。受信していればステップＳ２０８に行き、受信していなければステップＳ２０７に戻る。
【０１３９】
（ステップＳ２０８）記録部１２は、ｉ番目のデータ群の本処理を行う。
【０１４０】
（ステップＳ２０９）記録部１２は本処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２０８に戻る。エラーは発生していなければステップＳ２１４に行く。
【０１４１】
（ステップＳ２１４）ｉにｉ＋１を代入する。
【０１４２】
（ステップＳ５０１）記録部４２は、ｉをｎで割った余りが０か否かを判断する。０であればステップＳ５０２に行き、０でなければステップＳ２０６に戻る。
【０１４３】
（ステップＳ５０２）ｊに０を代入する。
【０１４４】
（ステップＳ５０３）記録部４２は、（ｉ−ｎ＋ｊ）番目のデータ群の後処理を行う。
【０１４５】
（ステップＳ５０４）記録部４２は、ステップＳ５０３での後処理がエラーでないか否かを判断する。エラーであればステップＳ５０３に戻る。エラーでなければステップＳ５０５に行く。
【０１４６】
（ステップＳ５０５）ｉにｊ＋１を代入する。
【０１４７】
（ステップＳ５０６）ｊがｎ−１と等しいか否かを判断する。等しければステップＳ５０７に行き、等しくなければステップＳ５０３に戻る。
【０１４８】
（ステップＳ５０７）記録部４２は、ｎ個のデータ群の前処理を行う。
【０１４９】
（ステップＳ５０８）記録部４２は、ステップＳ５０７での前処理がエラーでないか否かを判断する。エラーであればステップＳ５０７に戻る。エラーでなければステップＳ２０７に行く。
【０１５０】
次に、上記で説明した受信装置の具体的なデータ群の書き込み処理の例について図２２を用いて説明する。本具体例において、受信装置はデジタルテレビである。また、データ群（モジュール）は、１ＭＢのデータである。また、記録部４２における記録は、モジュールをファイルに記録する。また、前処理は、ファイル生成処理（ｃｒｅａｔｅ）、ファイルオープン処理（ｏｐｅｎ）である。本処理は、データ群の書き込み処理（ｗｒｉｔｅ）である。後処理は、ファイルクローズ処理（ｃｌｏｓｅ）である。
【０１５１】
かかる場合に、放送局からデータＤＩＩが送信される。次に、受信部１１はデータＤＩＩを受信する。次に、記録部４２は、データＤＩＩからディレクトリ名を取り出し、ディレクトリを作成する。そして、記録部４２は、データＤＩＩ中の一括処理数（本具体例では、ｎとする。）を取得する。
【０１５２】
そして、記録部４２は取得した一括処理数（ｎ）のファイルの生成およびオープンを行う。記録部４２は、以上の前処理によりｎ個のファイルポインタを得る。そして、受信部１１は０番目（０番目から始まる）のモジュールを受信する。次に、記録部４２は、０番目のモジュールを受信部１１から取り出し、モジュールの内容を記録媒体２０に記録（ｗｒｉｔｅ）する。記録の際に、０番目のファイルポインタを記録する関数に引数として渡す。なお、本実施の形態においては、後処理を本処理の直後に行わず、後処理も一括して行う。
【０１５３】
次に、１番目のモジュールの本処理を行う。さらに、２番目のモジュールの本処理、ｎ−２番目のモジュールの本処理、ｎ−１番目のモジュールの本処理を次々に行っていく。かかる本処理とは別に受信部１１が０番目からｎ−１番目のモジュールを受信する。受信部１１がｎ−ｍ番目のモジュールの受信（受信部１１が保持する記録手段に記録すること）を完了してからｎ−ｍ＋１番目のモジュールの受信を開始する（ｎ−ｍ＋１番目のモジュールの記録を開始する）までに、記録部４２はｎ−ｍ番目のモジュールを記録媒体２０に記録する。
【０１５４】
次に、一括処理すべきモジュールの本処理が完了した段階で、本処理した分のモジュールの後処理を行う。後処理とは、ファイルクローズである。
【０１５５】
さらに、次のｎ個のモジュールについて前処理を行う。
【０１５６】
なお、上記において複数のデータ群に対する前処理は一括して行われた。この「一括して行う」とは、前処理のｃｒｅａｔｅ、ｏｐｅｎが連続して行われた場合だけでなく、２つの処理の間に別の処理があっても良い。また、「一括して行う」の意味として、モジュール０の前処理とモジュール１の前処理は連続して行われることが普通であるが、これに限らず、モジュール０の前処理とモジュール１の前処理の間別の処理が行われる場合も含まれる。また、後処理もｎ個の後処理が連続して行われているが、他の処理が間に入る場合も、「一括して行う」に含まれる。つまり、「一括して行う」とは、前処理および後処理をモジュールの書き込み処理中には行わず、前もって行って、または後で別途行うことを言う。
【０１５７】
なお、図２２に示すように、本実施形態において、ｎ個のモジュールが連続して送信された後、一括した後処理および一括した前処理のために一定以上の時間的間隔が置かれるものとする。
【０１５８】
以上のように、本実施の形態によれば、複数のデータ群を連続して受信して記録する際に、最初に複数のデータ群の前処理だけではなく、後処理をも一括して行うことにより、データ群受信または記録中にエラーが発生したにも、エラーとなった処理を再度行う（リトライする）ことによりすべてのデータ群をさらに安全に記録媒体に記録することができる。
【０１５９】
なお、本実施の形態において、通常、記録部４２はＣＰＵとソフトウェアで実現されているが、すべてハードウェア（回路）で実現しても良い。
【０１６０】
さらに、本実施の形態において、前処理と後処理の双方を一括して行ったが、後処理のみを一括して行っても良い。かかる場合でも、前処理、本処理、後処理をシーケンシャルに行うより、エラーに強い受信装置が実現できる。
【０１６１】
本発明にかかる他の実施形態の概要図を図２３に示す。
【０１６２】
図２３の受信システムは、受信装置７０、記録媒体２０を有する。受信装置７０は、受信部１１、記録部７２、属性情報保持部７３、一括処理数決定部７４を有する。属性情報保持部７３は、受信装置７０のＣＰＵ能力やメモリサイズなどの受信装置７０の属性に関する情報（以下、属性情報という。）を保持する。
【０１６３】
一括処理数決定部７４は、属性情報保持部７３で保持している属性情報に基づいて一括して処理するデータ群数を決定する。
【０１６４】
次に、図２４のフローチャートに基づいて受信装置７０の動作を説明する。
【０１６５】
（ステップＳ８０１）記録部７２は、予め決められた名称のディレクトリを作成する。
【０１６６】
（ステップＳ８０２）一括処理数決定部７４は、属性情報取得部７３が保持する属性情報を取得する。
【０１６７】
（ステップＳ８０３）一括処理数決定部７４は、取得した属性情報に基づいて一括処理するデータ群数を決定する。詳細は、以下に述べる。
【０１６８】
（ステップＳ２０４）記録部７２は、ｎ個のデータ群を記録媒体２０に記録するための前処理（以下、前処理という。）を行う。ここで、例えば、１データ群を１ファイルに記録する場合を想定する。この場合、前処理とは、ファイル生成処理およびファイルオープン処理である。
【０１６９】
（ステップＳ２０５）記録部７２は、ステップＳ２０４の処理がエラーか否かを判断する。エラーであればステップＳ２０４に戻り、エラーでなければステップＳ２０６に行く。前処理におけるエラーか否かの判断は、例えばファイルポインタが正常にリターンされない、等で判断可能である。内部の処理では記録媒体における記憶領域が確保できなかった場合などが該当する。
【０１７０】
（ステップＳ２０６）変数ｉに０を代入する。
【０１７１】
（ステップＳ２０７）記録部７２は、受信部１１がｉ番目のデータ群を受信したか否かを判断する。受信していればステップＳ２０８に行き、受信していなければステップＳ２０７に戻る。
【０１７２】
（ステップＳ２０８）記録部７２は、ｉ番目のデータ群の本処理を行う。
【０１７３】
（ステップＳ２０９）記録部７２は本処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２０８に戻る。エラーは発生していなければステップＳ２１０に行く。
【０１７４】
（ステップＳ２１０）記録部７２は、ｉ番目のデータ群の後処理を行う。
【０１７５】
（ステップＳ２１１）記録部７２は、ステップＳ２１０における後処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２１０に戻り、エラーが発生していなければステップＳ２１２に行く。
【０１７６】
（ステップＳ２１２）記録部７２は、（ｎ＋ｉ）番目のデータ群の前処理を行う。
【０１７７】
（ステップＳ２１３）記録部７２は、ステップＳ２１２での処理がエラーか否かを判断する。エラーであれば、ステップＳ２１２に戻り、エラーでなければステップＳ２１４に行く。
【０１７８】
（ステップＳ２１４）ｉにｉ＋１を代入する。ステップＳ２０７に行く。
【０１７９】
次に、上記で説明した受信装置の特徴的処理は、ステップＳ８０３である。つまり、属性情報から一括処理するデータ群数を決定する処理である。以下、その処理について詳述する。
【０１８０】
今、属性情報保持部７３に、受信装置７０のＣＰＵ能力とメモリサイズが格納されているとする。そして、一括処理数決定部７４は、ＣＰＵ能力とメモリサイズに基づいて一括処理数を決定する。通常、ＣＰＵ能力が大であればあるほど一括処理数が増加する。また、メモリサイズが大きければ大きいほど一括処理数が増加する。
【０１８１】
具体的には、一括処理数決定部７４は、関数ｚ＝ｆ（ｘ、ｙ）（ｚは一括処理数、ｘはＣＰＵ能力、ｙはメモリサイズ）に基づいて一括処理数を決定する。ただし、一括処理数決定部７４において、上記のような関数により一括処理数を決定しても良いが、ＣＰＵ能力とメモリサイズから一括処理数が決定できる表により一括処理数を決定しても良い。
【０１８２】
さらに、属性情報はＣＰＵ能力とメモリサイズだけではなく、その他受信装置７０の属性情報を用いれば何でもよい。また、一括処理数決定部７４は、受信装置７０の属性情報を用いていれば、当該属性情報に加えて外部からの情報をも用いて一括処理数を決定しても良い。
【０１８３】
次に、図２５のフローチャートに基づいて受信装置７０の別の動作を説明する。先の場合と違うのは、複数のデータ群の後処理も一括して行っている点である。
【０１８４】
（ステップＳ８０１）記録部７２は、予め決められた名称のディレクトリを作成する。
【０１８５】
（ステップＳ８０２）一括処理数決定部７４は、属性情報取得部７３が保持する属性情報を取得する。
【０１８６】
（ステップＳ８０３）一括処理数決定部７４は、取得した属性情報に基づいて一括処理するデータ群数を決定する。詳細は、以下に述べる。
【０１８７】
（ステップＳ２０４）記録部７２は、ｎ個のデータ群の前処理を行う。
【０１８８】
（ステップＳ２０５）記録部７２は、ステップＳ２０４の処理がエラーか否かを判断する。エラーであればステップＳ２０４に戻り、エラーでなければステップＳ２０６に行く。
【０１８９】
（ステップＳ２０６）変数ｉに０を代入する。
【０１９０】
（ステップＳ２０７）記録部７２は、受信部１１がｉ番目のデータ群を受信したか否かを判断する。受信していればステップＳ２０８に行き、受信していなければステップＳ２０７に戻る。
【０１９１】
（ステップＳ２０８）記録部７２は、ｉ番目のデータ群の本処理を行う。
【０１９２】
（ステップＳ２０９）記録部７２は本処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２０８に戻る。エラーは発生していなければステップＳ２１４に行く。
【０１９３】
（ステップＳ２１４）ｉにｉ＋１を代入する。
【０１９４】
（ステップＳ５０１）記録部７２は、ｉをｎで割った余りが０か否かを判断する。０であればステップＳ５０２に行き、０でなければステップＳ２０７に戻る。
【０１９５】
（ステップＳ５０２）ｊに０を代入する。
【０１９６】
（ステップＳ５０３）記録部７２は、（ｉ−ｎ＋ｊ）番目のデータ群の後処理を行う。
【０１９７】
（ステップＳ５０４）記録部７２は、ステップＳ５０３での後処理がエラーでないか否かを判断する。エラーであればステップＳ５０３に戻る。エラーでなければステップＳ５０５に行く。
【０１９８】
（ステップＳ５０５）ｉにｊ＋１を代入する。
【０１９９】
（ステップＳ５０６）ｊがｎ−１と等しいか否かを判断する。等しければステップＳ５０７に行き、等しくなければステップＳ５０３に戻る。
【０２００】
（ステップＳ５０７）記録部７２は、ｎ個のデータ群の前処理を行う。
【０２０１】
（ステップＳ５０８）記録部７２は、ステップＳ５０７での前処理がエラーでないか否かを判断する。エラーであればステップＳ５０７に戻る。エラーでなければステップＳ２０７に行く。
【０２０２】
以上のように、本実施の形態によれば、受信装置の属性情報に基づいて適切な一括処理数が決定されることにより、すべてのデータ群をさらに安全に記録媒体に記録することができる。
【０２０３】
本発明にかかる他の実施形態のブロック図を図２６に示す。
【０２０４】
図２６の受信システムは、受信装置１００、記録媒体２０を有する。受信装置１００は、受信部１１、ｎ個の記録部（９１から９ｎ）を有する。記録部９１等は、受信部１１で受信したデータを記録媒体２０に記録する。記録の方法が記録部１２、記録部４２等とは異なる。以下、本実施の形態における記録部９１等の記録の方法について詳述する。
【０２０５】
次に、図２７のモジュールの記録処理の流れを示す概要図を用いて、記録部９１から記録部９ｎの動作について説明する。
【０２０６】
今、ｎは３である。そして、記録部９１はＣＰＵ１に該当する。記録部９２はＣＰＵ２に、記録部９３はＣＰＵ３に該当する。ＣＰＵ１は、前処理を専門に行う。ＣＰＵ２は本処理を行う。ＣＰＵ３は後処理を行う。そして、各ＣＰＵ間で各処理に必要な情報が渡される。
【０２０７】
そして、受信部１１は、データＤＩＩを受信した後、連続してモジュールを受信する。
【０２０８】
以上の状況で、まずＣＰＵ１がモジュール０の前処理（例えば、ファイル生成、ファイルオープン）を行う。そして、ＣＰＵ１からファイルポインタをＣＰＵ２に渡す。次に、ＣＰＵ２は本処理を行う。つまり、渡されたファイルポインタにより特定されるファイルにモジュールを書き込む。書き込みが終了すると、ＣＰＵ２はファイルポインタをＣＰＵ３に渡す。さらに、ＣＰＵ３は後処理を行う。具体的には、ＣＰＵ３は、渡されたファイルポインタで特定されるファイルをクローズする。
【０２０９】
以上のように、３つのＣＰＵを用いて、パイプライン処理を行い、連続して送信されるモジュールを安全に記録する。
【０２１０】
なお、上記によれば、パイプライン処理により安全にモジュールを記録する処理を行ったが、複数のＣＰＵがある環境であれば、モジュール０の記録処理（前処理、本処理、後処理）をＣＰＵ１で行い、モジュール１の記録処理をＣＰＵ２で行うなど、モジュール処理毎に担当するＣＰＵを分けても良い。この場合、どのＣＰＵがどのモジュールを処理するかは、他のＣＰＵで制御しても良いし、メッセージパッシングによって知らせあっても良い。
【０２１１】
以上説明したように、本発明によれば、複数のデータ群を連続して受信して記録する際に、複数のデータ群の前処理または／および後処理を一括して行うことにより、エラーが発生してもすべてのデータ群を安全に記録媒体に記録することができる。
【０２１２】
本発明は以下のような装置または方法にかかる発明として把握することができる。
【０２１３】
（１）複数のデータ群を受信する受信部と、前記受信部で受信したデータ群を記録媒体に記録する記録部とを具備する受信装置であって、前記記録部は、データ群を記録媒体に記録するための前処理と、データ群を記録媒体に記録する本処理と、データ群を記録媒体に記録するための後処理を行い、複数のデータ群に対する前処理を本処理の前に一括して行うことを特徴とする受信装置。
【０２１４】
（２）複数のデータ群を受信する受信部と、前記受信部で受信したデータ群を記録媒体に記録する記録部とを具備する受信装置であって、前記記録部は、データ群を記録媒体に記録するための前処理と、データ群を記録媒体に記録する本処理と、データ群を記録媒体に記録するための後処理を行い、複数のデータ群に対する後処理を本処理の後に一括して行うことを特徴とする受信装置。
【０２１５】
（３）複数のデータ群を受信する受信部と、前記受信部で受信したデータ群を記録媒体に記録する記録部とを具備する受信装置であって、前記記録部は、データ群を記録媒体に記録するための前処理と、データ群を記録媒体に記録する本処理と、データ群を記録媒体に記録するための後処理を行い、複数のデータ群に対する前処理を本処理の前に一括して行い、かつ複数のデータ群に対する後処理を本処理の後に一括して行うことを特徴とする受信装置。
【０２１６】
（４）一括して前処理を行うデータ群数を保持する一括処理数保持部をさらに具備し、前記記録部は、前記一括処理数保持部で保持しているデータ群数のデータ群の前処理を一括して行うことを特徴とする前記（１）〜（３）いずれかに記載の受信装置。
【０２１７】
（５）受信装置の属性である属性情報を保持する属性情報保持部と、前記属性情報保持部で保持する属性情報に基づいて一括して前処理を行うデータ群数を決定するデータ群数決定部とをさらに具備し、前記記録部は、前記一括処理数保持部で保持しているデータ群数のデータ群の前処理を一括して行うことを特徴とする前記（１）〜（３）いずれかに記載の受信装置。
【０２１８】
（６）複数のデータ群を受信する受信部と、前記受信部で受信したデータ群を記録媒体に記録するために第一の記録部と第二の記録部と第三の記録部とを具備する受信装置であって、前記第一の記録部はデータ群を記録媒体に記録するための前処理を行い、前記第二の記録部はデータ群を記録媒体に記録する本処理を行い、前記第三の記録部はデータ群を記録媒体に記録するための後処理を行い、前記３つの記録部がデータ群に対する前処理、本処理、後処理をリレーして行うことを特徴とする受信装置。
【０２１９】
（７）前記記録部はデータ群をファイルとして記録媒体に記録し、前記前処理はファイル作成およびファイルオープン処理であり、前記本処理はファイル書きこみ処理であり、前記後処理はファイルクローズ処理であることを特徴とする前記（１）〜（６）いずれかに記載の受信装置。
【０２２０】
（８）受信された複数のデータ群を記録媒体に記録するプログラムであって、前記プログラムは、データ群を記録媒体に記録するための前処理ステップと、データ群を記録媒体に記録する本処理ステップと、データ群を記録媒体に記録するための後処理ステップを有し、複数のデータ群に対する複数の前処理ステップを本処理ステップの前に一括して行うことを特徴とするプログラム。
【０２２１】
（９）受信された複数のデータ群を記録媒体に記録するプログラムであって、前記プログラムは、データ群を記録媒体に記録するための前処理ステップと、データ群を記録媒体に記録する本処理ステップと、データ群を記録媒体に記録するための後処理ステップを有し、複数のデータ群に対する複数の後処理ステップを本処理ステップの後に一括して行うことを特徴とするプログラム。
【０２２２】
（１０）受信された複数のデータ群を記録媒体に記録するプログラムであって、前記プログラムは、データ群を記録媒体に記録するための前処理ステップと、データ群を記録媒体に記録する本処理ステップと、データ群を記録媒体に記録するための後処理ステップを有し、複数のデータ群に対する複数の前処理ステップを本処理ステップの前に一括して行い、かつ複数のデータ群に対する複数の後処理ステップを本処理ステップの後に一括して行うことを特徴とするプログラム。
【０２２３】
（１１）記憶されている一括して前処理を行うデータ群数を取得するデータ群数取得ステップをさらに具備し、前記前処理ステップは、前記データ群数のデータ群の前処理を一括して行うことを特徴とする請求項８または請求項１０いずれか記載のプログラム。
【０２２４】
（１２）記録している属性情報に基づいて一括して前処理を行うデータ群数を決定する一括処理数決定ステップとをさらに具備し、前記前処理ステップは、前記一括処理数決定ステップで決定した一括処理数のデータ群の前処理を一括して行うことを特徴とする前記（８）〜（１０）いずれかに記載の受信装置。
【図面の簡単な説明】
【図１】本発明にかかる送受信システムの全体構成を示す図である。
【図２】送信装置１の機能ブロック図である。
【図３】コンテンツデータのディレクトリ構造である。
【図４】送信装置１のハードウェア構成の一例である。
【図５】送信装置１の送信処理フローチャートである。
【図６】モジュールデータのデータ構造を示す図である。
【図７】データＤＩＩのデータ構造を示す図である。
【図８】データＤＩＩが繰り返し送信された後、ＤＢＢメッセージデータが送信された状態を説明するための図である。
【図９】受信装置のハードウェア構成を示す図である。
【図１０】モジュール蓄積恣処理のフローチャートである。
【図１１】前処理の詳細フローチャートである。
【図１２】ディレクトリ作成処理のフローチャートである。
【図１３】ディレクトリ構造を示す図である。
【図１４】バッファ使用量とモジュール書き込み処理との関係を示す図である。
【図１５】バッファ使用量とモジュール書き込み処理との関係を示す図である。
【図１６】バッファ使用量とモジュール書き込み処理との関係を示す図である。
【図１７】他の実施形態における受信システムのブロック図である。
【図１８】図１７の受信装置１０の動作を説明するフローチャートである。
【図１９】受信装置１０の書き込み処理を示す図である。
【図２０】他の実施形態における受信システムのブロック図である。
【図２１】受信装置４０の動作を説明するフローチャートである。
【図２２】受信装置４０の書き込み処理を示す図である。
【図２３】他の実施形態における受信システムのブロック図である。
【図２４】受信装置７０の動作を説明するフローチャートである。
【図２５】受信装置７０における他の動作を説明するフローチャートである。
【図２６】他の実施形態における受信システムのブロック図である。
【図２７】受信装置１００の書き込み処理を示す図である。
【符号の説明】
１０１・・・・・送信装置
１０３・・・・・コンテンツデータ記憶手段
１０５・・・・・モジュール化手段
１０６・・・・・モジュール化データ記憶手段
１０７・・・・・構成モジュール管理情報生成手段
１１０・・・・・受信装置
１１１・・・・・受信手段
１１３・・・・・一時記憶手段
１１５・・・・・制御手段
１１７・・・・・記憶手段
【発明の属する技術分野】
本発明は、デジタルデータ送受信システムに関し、特に、受信したコンテンツデータのファイル記録方法に関する。
【０００２】
【従来技術】
今日、デジタル放送を蓄積記憶しておき、これを読み出してモニターに表示できるデジタル受信装置が知られている。
【０００３】
かかるコンテンツデータの蓄積方法について説明する。
【０００４】
送信側では以下のようにしてモジュールデータが構成モジュール管理情報であるデータＤＩＩとともに送信される。図３に示すディレクトリ構造のコンテンツデータが記憶されている場合、与えられたモジュール特定情報に基づいて、各コンテンツデータはモジュール化される。ここでは、ディレクトリ/shop1/books/indexに属するファイルindex.bml,index.pngがそれぞれ１のモジュール、ディレクトリ/shop1/books/ebook/indexに属するファイルebook-index.bml,ebook-index.pngがそれぞれ１のモジュール・・・として計６２のモジュールにモジュール化されたとする。
【０００５】
各モジュールデータはモジュール群特定情報に基づいて所定のモジュール群として同じデータＤＩＩにてカルーセル形式で繰り返し送信される。例えば、ディレクトリ/shop1/booksに属するモジュールを１のモジュール群として送信する場合、前記６２個のモジュールでモジュール群が構成されて、そのデータＤＩＩとともに送信される。データＤＩＩには当該モジュール群を構成するモジュールに関する管理データが含まれている。かかる管理データには、受信側で蓄積記憶する場合のディレクトリ構造が書き込まれる。なお、データＤＩＩはモジュールデータの送信に先立って送信される。
【０００６】
受信側ではかかるデータＤＩＩを受信すると、データＤＩＩに格納されているディレクトリ構造を読み出す。データＤＩＩの受信後、モジュールデータを受信するとこれを一旦バッファに書き込み、各モジュールを１のファイルとしてハードディスクに蓄積記憶するためのファイル書き込み準備処理（ファイルオープン処理）を行う。ファイルオープン処理完了すると、ハードディスクへの書き込み処理を行う。ハードディスクへの書き込み処理が終了するとバッファをクリアする。このようにして、受信側で図３のようなディレクトリ構造にてコンテンツデータを蓄積記憶することができる。
【０００７】
【発明が解決しようとする課題】
しかしながら、上記受信装置においては以下のような問題があった。データＤＩＩに基づいてハードディスク上へのファイル書き込み準備処理時間は、各モジュールデータの容量にかかわらずほぼ一定である。モジュールのデータ容量が大きい場合には、モジュールデータを受信している間に、つぎのモジュールデータのファイルオープン処理をすればいいので、かかるファイル管理情報の作成時間はそれほど問題とならない。これに対して、各モジュールのデータ容量が小さくなると、相対的にファイルオープン処理が間に合わず、その結果、バッファメモリへの一時記憶量が増大していき、バッファメモリがオーバフローとなるおそれがある。
【０００８】
かかる問題を防止するために、送信側では、各コンテンツデータをモジュール化して送信するときに、各モジュールのデータ量を所定量よりも多くなるように、マルチパート化して送信することも考えられる。しかし、これでは、各モジュールを構成するデータ量に制約ができる。
【０００９】
この発明は、上記問題を解決し、バッファメモリの容量を増やすことなく、１の構成モジュール管理情報で管理できるモジュールのデータ容量の自由度を高めたデータ送受信システムまたはその方法を提供することを目的とする。
【００１０】
【課題を解決するための手段】
１）本発明にかかるデジタルデータ送受信システムは、送信装置に、コンテンツデータを、ディレクトリ構造で管理された複数のファイルに分けて記憶しておき、前記送信装置から前記ディレクトリ構造の情報および前記複数のファイルをデジタル放送するとともに、受信装置で前記ディレクトリ構造の情報および前記複数のファイルを受信し、前記ディレクトリ構造にて前記複数のファイルを蓄積記憶するデジタルデータ送受信システムにおいて、前記送信装置は、前記ディレクトリ構造の情報をデータＤＩＩのプライベート領域に格納して、当該ＤＩＩの送信を複数回繰り返すことにより、前記複数のファイルをＤＤＢメッセージデータにて送信するまでの所定の猶予時間を確保し、前記受信装置は、前記データＤＩＩを受信すると、前記プライベート領域から前記ディレクトリ構造の情報を読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行する。
したがって、受信装置側でファイルの書き込み準備処理が間に合わないというおそれを少なくし、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。すなわち、データＤＩＩで管理される１モジュールのデータ量を小さくしても、確実な蓄積記憶が可能なデジタルデータ送受信システムを提供することができる。また、従来の送信処理を変更するだけで前記猶予時間を受信装置側に与えることができる。また、データＤＩＩが繰り返し送られてくるので、データＤＩＩの受信タイミングを多くすることができる。
【００１１】
２）本発明にかかるデジタルデータ受信装置は、ディレクトリ構造で管理された複数のファイルに分けて記憶されたコンテンツデータがデジタル放送されると、これを受信して前記ディレクトリ構造で管理された複数のファイルに分けて蓄積記憶するデジタルデータ受信装置において、データＤＩＩを受信すると、当該データＤＩＩの前記プライベート領域から、管理するファイルのディレクトリ構造の情報を読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行し、ＤＤＢメッセージデータにて前記複数のファイルを受信すると、前記書き込み準備ファイルに書き込み処理をする。
したがって、受信装置側でファイルの書き込み準備処理が間に合わないというおそれを少なくし、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００１２】
３）本発明にかかるデジタルデータ送信装置は、コンテンツデータを、ディレクトリ構造で管理された複数のファイルに分けて記憶しておき、前記ディレクトリ構造の情報および前記複数のファイルをデジタル放送するデジタルデータ送信装置において、前記ディレクトリ構造の情報をデータＤＩＩのプライベート領域に格納して、当該ＤＩＩの送信を複数回繰り返すことにより、前記複数のファイルをＤＤＢメッセージデータにて送信するまでに所定の猶予時間を確保する。
したがって、受信装置側でファイルの書き込み準備処理が可能となり、これにより、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００１３】
４）本発明にかかるデジタルデータ送信装置においては、１のデータＤＩＩで管理する総モジュール数は２つであり、前記所定時間は３０秒間である。したがって、受信装置側でファイルの書き込み準備処理が可能となる。
【００１５】
５）本発明にかかるデジタルデータ受信装置においては、前記読み出したディレクトリ構造の情報で管理されるファイルのうち、ファイル書き込み準備処理をまとめて実行した複数のファイルについて、当該複数のファイルの書き込み処理を終了してから、当該複数のファイルについての閉じ処理をする同じデータＤＩＩで特定される全ファイルの書き込み終了してから、前記全ファイルの閉じ処理をする。したがって、書き込み処理が何らかの原因で中断された場合には、書き込みは完了しない。これにより、更新等の場合に、一部のみ更新されるというおそれがない。
【００１６】
６）本発明にかかるデジタルデータ受信装置においては、前記コンテンツデータは、他のコンテンツデータへのリンク情報を含んでいる。したがって、複数のコンテンツデータによって、多彩なコンテンツを提供することができる。
【００１７】
７）本発明にかかるデジタルデータ受信装置においては、１のモジュールを１ファイルに記憶する。したがって、１のデータＤＩＩで管理されるモジュール数が増える場合でも、受信機にてより確実に蓄積記憶させることができる。
【００１９】
８）本発明にかかるデジタルデータ受信装置においては、ディレクトリ構造で管理された複数のファイルに分けて記憶されたコンテンツデータがデジタル放送されると、これを受信して前記ディレクトリ構造で管理された複数のファイルに分けて蓄積記憶するデジタルデータ受信装置において、データＤＩＩのプライベート領域から読み出したディレクトリ構造の情報で管理されるファイルのうち、ファイル書き込み準備処理をまとめて実行した複数のファイルについて、当該複数のファイルの書き込み処理を終了してから、当該複数のファイルについての閉じ処理をする。したがって、一部の書き込みが未完了で終了した場合には、ファイルの閉じ処理を行わず、全体として書き込みが終了しない限り、ファイル閉じ処理がなされない。
【００２０】
９）本発明にかかるデジタルデータ受信装置は、デジタル放送されたコンテンツデータを受信して蓄積記憶するデジタルデータ受信装置において、データＤＩＩを受信すると、当該データＤＩＩの前記プライベート領域から前記ディレクトリ構造の情報を読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行する。したがって、受信装置側でファイルの書き込み準備処理が可能となり、これにより、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００２１】
１０）本発明にかかるデジタルデータ受信装置は、前記データＤＩＩを受信すると、当該データＤＩＩの前記プライベート領域から前記ディレクトリ構造の情報を読み出してファイル開き処理準備の必要なファイルを決定する。したがって、データＤＩＩに開き処理決定に必要な情報を格納させることにより、１のモジュール数のデータ量を小さくしても、確実に各コンテンツデータを記憶させることができる。
【００２２】
１１）本発明にかかるデジタルデータ受信装置においては、前記複数まとめて実行されるファイル書き込み準備処理は、前記モジュールのインデックスデータを含むデータＤＩＩを受信する前に、所定数のファイルについて仮ファイル名で開き処理準備をしておき、データＤＩＩを受信すると、前記ディレクトリ構造で管理されるファイル名を抽出し、前記開き処理準備したファイルのファイル名を前記抽出したファイル名に変更する。したがって、予め多くのファイルについて開き準備処理が可能となる。
【００２３】
１４）本発明にかかるデジタルデータ受信装置は、ディレクトリ構造で管理された複数のファイルに分けて記憶されたコンテンツデータがデジタル放送されると、これを受信して前記ディレクトリ構造で管理された複数のファイルに分けて蓄積記憶するデジタルデータ受信装置において、ファイル管理情報を受信すると、当該ファイル管理情報にて管理するファイルのディレクトリ構造の情報を、当該ファイル管理情報から読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行する。したがって、受信装置側でファイルの書き込み準備処理が間に合わないというおそれを少なくし、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００２４】
１８）本発明にかかるデジタルデータ送受信システムは、コンテンツデータを複数のモジュール化し、各モジュールをモジュール群毎にまとめて、当該モジュール群に属するモジュールに関する構成モジュール管理情報とともにデジタル放送する送信装置、前記構成モジュール管理情報に基づいて、受信したモジュール化コンテンツデータをモジュール毎に１のファイルとして蓄積記憶する受信装置、を備え、前記送信装置は、前記ディレクトリ構造の情報をデータＤＩＩのプライベート領域に格納して、当該ＤＩＩの送信を複数回繰り返すことにより、前記複数のファイルをＤＤＢメッセージデータにて送信するまでに所定の猶予時間を確保し、前記受信装置は、前記構成モジュール管理情報を受信すると、前記モジュール化コンテンツデータをモジュール毎に１のファイルとして蓄積記憶させるためのファイル書き込み準備処理を、複数ファイルについてまとめて実行する。したがって、受信装置側でファイルの書き込み準備処理が間に合わないというおそれを少なくし、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００２５】
１９）本発明にかかるデジタルデータ送信装置は、モジュール化されたコンテンツデータを記憶しておき、各モジュールをモジュール群規則に基づいてモジュール群化して、モジュール群に属するモジュールに関する構成モジュール管理情報とともにデジタル放送するデジタルデータ送信装置において、前記構成モジュール管理情報の送信を複数回繰り返すことにより、前記前記モジュール化されたコンテンツデータを送信するまでの所定の猶予時間を確保する。したがって、受信装置側でファイルの書き込み準備処理が間に合わないというおそれを少なくし、受信装置側では一時的に記憶しておくバッファ容量が少なくとも、より確実に蓄積記憶が可能となる。
【００２６】
【発明の実施の形態】
１．〔機能ブロックの説明〕
図１に、本発明にかかる発明にかかるデータ送受信システムをデジタル放送システムに適用した場合の機能ブロック図を示す。デジタル放送システム１０００は、送信装置１０１および受信装置１１０を備えている。
【００２７】
送信装置１０１は、コンテンツデータ記憶手段１０３、モジュール化手段１０５、モジュール化データ記憶手段１０６、構成モジュール管理情報生成手段１０７，および送信手段１０９を備えている。コンテンツデータ記憶手段１０３は、伝送対象であるコンテンツデータをファイル形式で記憶する。モジュール化手段１０５は、コンテンツデータ記憶手段１０３に記憶された各コンテンツデータをモジュール化規則に基づいて、モジュール化する。モジュール化データ記憶手段１０６は、モジュール化されたデータを記憶する。構成モジュール管理情報生成手段１０７は、モジュール化手段５から与えられたモジュール群規則に基づいてモジュール群化するときの構成モジュール管理情報を生成する。送信手段１０９は、構成モジュール管理情報生成手段１０７で生成された構成モジュール管理情報を所定回数繰り返し送信する。構成モジュール管理情報の繰り返し送信が終わると、当該モジュール管理情報で管理されるモジュールデータを送信する。
【００２８】
このような送信方法を採用したのは、後述するように、構成モジュール管理情報を受信装置が受信後、所定の猶予時間経過してから前記各モジュールデータを受信できるようにするためである。
【００２９】
受信装置１１０は、受信手段１１１、一時記憶手段１１３、制御手段１１５、および記憶手段１１７を備えている。受信手段１１１は前記送信されたモジュールデータのうち、選別条件に合致する構成モジュール管理情報およびモジュールデータを選別して受信する。一時記憶手段１１３は受信したデータを一時記憶する。制御手段１１５は、一時記憶手段１１３に一時記憶された構成モジュール管理情報に基づいて、記憶手段１１７の必要なファイル構築の前処理を行う。その際、前記モジュール化されたデータをファイルとして蓄積記憶させるためのファイル書き込み準備処理を複数ファイルについて実行する。これにより、複数のファイルについてファイルクリエイトおよびオープン処理が実行される。制御手段１１５は、複数のファイルについてのファイルクリエイトおよびオープン処理が終わると、一時記憶手段１１３に一時記憶されたモジュールデータを読み出して、記憶手段１１７に書き込むとともに、一時記憶手段１１３に一時記憶されたモジュールデータを消去する。その後、前処理が完了している次順位のモジュールデータについて、前記処理を繰り返す。
【００３０】
１のファイルについてファイルクローズ処理がなされると、前記構成モジュール管理情報で特定される次順位ファイルについて、前記前処理を行う。
【００３１】
このように、送信側では、構成モジュール管理情報を送信後、所定の猶予時間経過してから前記各モジュールデータを送信することにより、受信装置では、モジュールデータを受信前に構成モジュール管理情報に基づいて予め複数のファイルについてのクリエイト処理が可能となる。したがって、一時記憶手段１１３につぎつぎとデータが蓄積されてオーバフロー状態となることがない。
【００３２】
以下この発明を地上波デジタル放送に適用した場合について説明する。
【００３３】
２．〔送信装置の概要〕
図２に、上記の送信装置１の詳細ブロック図を示す。送信装置１０１は地上波デジタル放送用の送信装置であり、各コンテンツデータ（ＢＭＬファイル、画像データなど）を１のリソースとして、図８に示すように、複数のリソースをまとめた１のモジュールデータを生成し、これをブロック化したＤＤＢ(Download Data Block)メッセージデータをカルーセル形式で繰り返し送信する。各カルーセルには、当該カルーセルにて送信されているデータの管理データとして、各カルーセルごとにデータＤＩＩ(Download Info Indication)が送信される。
【００３４】
なお、受信側では、後述するように、データＤＩＩを参照して、必要なＤＤＢメッセージデータを受信し、各ＤＤＢメッセージのブロックデータを読み出して連結することにより、各コンテンツデータ（リソース）を再現することができる。
【００３５】
コンテンツデータ記憶部１６１には、図３に示すようなコンテンツデータが各ディレクトリに分類され、ファイルとして記憶されている。制御部１６２はスケジュール記憶部１６４に記憶された配信スケジュールデータに基づき、配信時刻よりも所定時間前になると、コンテンツデータ取得部１６３に取得命令を与える。コンテンツデータ取得部１６３は、コンテンツデータ記憶部１６１からデータを読み出して、記憶しているモジュール化規則に基づいて、モジュール化処理し、記憶する。
【００３６】
本実施形態においては、最下層ディレクトリ（ルートディレクトリから一番遠いディレクトリ）に記憶されているファイルを１のモジュールとしてマルチパート化するようにした。例えば、/shop1/books/index/index.bml,/shop1/books/index/index.pngの各ファイルについては、同じディレクトリ/shop1/books/indexに属しているので、これを１つのモジュールとする。
【００３７】
また、どのモジュールについて同じデータＤＩＩで送るかについても、モジュール化規則に記憶されている。
【００３８】
たとえば、サブディレクトリ"/books"に属する各モジュールを同じデータＤＩＩで送る（１のカルーセルで送信する）場合、以下のようにモジュール化される。
【００３９】
図２に示す制御部１６２はＤＤＢ生成部１６５にＤＤＢメッセージデータの生成命令を与える。ＤＤＢ生成部１６５は、コンテンツデータ取得部１６３に記憶されたモジュール化データを読み出して、図６に示すようなＤＤＢメッセージデータを生成し、記憶する。ＤＤＢメッセージデータのデータ構造は従来のデジタル放送の規格と同様である。本実施形態においては、図３に示すようなディレクトリ構造で各ファイルが管理されており、各ファイルにはコンテンツデータ（以下リソースと呼ぶ）が記憶されている。各モジュールは、図６に示すように、複数のリソースから構成される。各リソース間の関係（リソースのディレクトリ構造を表すリスト）はリソースリストに記述される。
【００４０】
たとえば、図３において、ディレクトリ/shop1/books/indexに属するファイルindex.bml,index.pngで１のモジュール、ディレクトリ/shop1/books/ebook/indexに属するファイルebook-index.bml,ebook-index.pngで１のモジュール、ディレクトリ/shop1/books/ebook/ebook1に属するファイルbook1.bml,ebook1.pngで１のモジュール、・・・と計３１のモジュールにモジュール化され、さらに、これら３１個のモジュールが１のモジュール群として１のデータＤＩＩにて送信される場合には、図１３に示す各モジュールのディレクトリ構造がデータＤＩＩに記述される。また、各モジュールのリソースリストには、当該モジュールにおける各リソースが相対パス形式で記述される。なお、１のモジュールで送信されるコンテンツデータについては、当該モジュールを構成するＤＢＢメッセージデータを全て受信し、これを連結することにより、目的のリソース（コンテンツ）を特定が可能となる。
【００４１】
このように、本実施形態においては、各モジュールが属するディレクトリ情報はデータＤＩＩに、各モジュール内のリソースについてのリソース間の関係はリソースリストに分けて記憶されている。しかし、これに限定されず、データＤＩＩに各リソースについてのディレクトリ構造を記憶させてもよい。
【００４２】
なお、上記実施形態においては、最下層ディレクトリに記憶されているリソースを１のモジュールとしてマルチパート化するようにしたが、モジュール化規則を変更することにより、１のモジュール内にさらにサブディレクトリが存在するように、モジュール化することもできる。この場合には、リソースリストに当該サブディレクトリの構造を記述される。
【００４３】
このようにモジュール内のリソースリストはリソースをまとめたディレクトリからの相対パスで記述することにより、絶対パスで記述した場合と較べて、リソースリストのデータ容量が膨大になることを防ぐことができる。
【００４４】
データＤＩＩについて説明する。データＤＩＩ生成部１６６は、図７に示すようなデータ構造のデータＤＩＩを生成する。データＤＩＩのデータ構造自体は、従来のデジタル放送の規格に則ったものである。データＤＩＩのデータ構造について説明する。データＤＩＩは、DSM-CCメッセージヘッダ、ダウンロード識別子、モジュール数、モジュール管理データ、プライベートデータなどで構成されている。モジュール管理データは、モジュールごとに、モジュール識別子（id)、モジュールサイズ、モジュール情報で構成されている。
【００４５】
プライベートデータ領域には、各ファイルが所属するルートディレクトリがルート記述子（StoreRoot記述子）に、そのサブディレクトリ構造がサブディレクトリ記述子に記憶されている。例えば、図３において、サブディレクトリ「/shop1/books」に属するファイルを１のデータＤＩＩで送信する場合は、ルート記述子にディレクトリ「shop1」が、そのサブディレクトリ記述子に「books」が記憶される。なお、サブディレクトリ「books」以下のディレクトリ構造は、既に説明したように、ＤＤＢメッセージデータのリソースリストに記述される。
【００４６】
データＤＩＩを構成するデータのうち、モジュール数はコンテンツデータ取得部１６３のモジュール化規則に基づいて決定される。
【００４７】
制御部１６２はスケジュール記憶部１６４に記憶された配信スケジュールに基づき、配信時刻になると、データＤＩＩ送出部１７６に対して、データＤＩＩを所定回数繰り返し送るようにデータＤＩＩ送出命令を与える。データＤＩＩ送出部１７６は、これによって、データＤＩＩを多重化コントローラ１８０に送出する。制御部１６２はまた、データＤＩＩ送出命令を与えたあと、ＤＤＢ送出部１７５にＤＤＢ送出命令を与える。多重化コントローラ１８０はこれらを多重化し、変調部１８１に出力する。これにより、トランスポートストリームとしてデータＤＩＩおよび当該データＤＩＩにて管理されるＤＤＢメッセージデータが図８に示すように、送信される。
【００４８】
なお、本実施形態においては、複数のファイルのデータを１のモジュールにまとめたマルチパート形式で送信したが、シングルパート形式（１のモジュールで１のファイルを送る）ようにしてもよい。
【００４９】
３．〔送信装置のハードウェア構成〕
図４を用いて、送信装置１０１のハードウェア構成について説明する。本実施形態においては、送信装置１０１は、多重化処理部および変調部以外は、ＣＰＵを用いてソフトウェアで実現した。
【００５０】
送信装置１０１は、ＣＰＵ１２３、メモリ１２７、ハードディスク１２６、モニタ１３１、入力部１３０、およびバスライン１２９を備えている。ＣＰＵ１２３は、ハードディスク１２６に記憶されたプログラムにしたがいバスライン１２９を介して、各部を制御する。ハードディスク１２６には、モジュール化規則、配信スケジュールデータ、コンテンツデータおよび制御プログラムが記憶される。図５を用いて、かかる制御プログラムによる処理について説明する。
【００５１】
ＣＰＵ１２３は、配信スケジュールデータに基づいて、コンテンツデータをハードディスク１２６から読み出して、モジュール化規則に基づいて、モジュール化してメモリ１２７に記憶する（ステップＳ１）。処理番号kを初期化し（ステップＳ２）、モジュール化規則に基づいて、処理番号k番目のデータＤＩＩで送信するモジュールデータを決定する（ステップＳ３）。データＤＩＩを生成し、メモリ１２７に記憶する（ステップＳ５）。データＤＩＩを構成するデータのうち、モジュール数をモジュール化規則に基づいて決定するとともに、各コンテンツデータがファイルとして管理されていた際の、各ファイルの関係、すなわち、ディレクトリ構造をデータＤＩＩのプライベート領域に書き込む。また、ステップＳ１にてメモリに書き込んだモジュール化データを、所定の固定長のブロック（４０６６バイト）に分割して、ＤＤＢメッセージデータとして、メモリに書き込む（ステップＳ７）。
【００５２】
ＣＰＵ１２３は、データＤＩＩ繰り返し送出回数を決定する（ステップＳ９）。本実施形態においては、データＤＩＩ先出し期間を２０秒とし、２０秒間繰り返されるように、送出回数を決定した。
【００５３】
ＣＰＵ１２３は、配信スケジュールデータに基づいて、データＤＩＩ送出開始時期か否かを判断する（ステップＳ１１）。データＤＩＩ送出開始時期になると、データＤＩＩを多重化コントローラ１８０に送出する（ステップＳ１３）。所定回数データＤＩＩを繰り返し送出したか否か判断し（ステップＳ１５）、所定回数送出するまで、ステップＳ１３の処理を繰り返す。所定回数データＤＩＩを送出すると、当該データＤＩＩを管理データとするＤＤＢメッセージデータを多重化コントローラ１８０に送出する。多重化コントローラ１８０はこれを多重化して、トランスポートストリームとして変調部１８１から送信される。
【００５４】
ＣＰＵ１２３は、全モジュールを送信したか否か判断し（ステップＳ１９）、送信していない場合には、処理番号kをインクリメントし（ステップＳ２０）、ステップＳ３以下の処理を繰り返す。送信済みの場合には処理を終了する。
【００５５】
４．〔受信装置のハードウェア構成〕
図９を用いて、図１に示す受信装置１１０のハードウェア構成について説明する。受信装置１１０は、チューナ１３２、トランスポートストリームデコーダ（ＴＳデコーダ）１３４、ＡＶデコーダ１３６、ＯＳＤ（On Screen Display）１３８、ＲＯＭ１４０、ＲＡＭ１４２、ＣＰＵ１４４、ハードディスク１４６、モデム１４８、信号受信部１５０を備えている。
【００５６】
衛星放送のデータ受信機能としては、従来とほとんど同様である。簡単に説明すると、アンテナ１３０は、送信装置からの電波を捕捉して、チューナー１３２に供給する。チューナー１３２は、ＣＰＵ１４４の指示に従って、１つのトランスポートストリームを選択的に受信する。さらに、チューナー１３２は、復調処理や誤り訂正処理などを行い、トランスポートデコーダ（以下ＴＳデコーダという）１３４に出力する。
【００５７】
ＴＳデコーダ１３４は、トランスポートストリームに多重化されているパケットのうち、ＣＰＵ１４４によってセットされたフィルタリング条件に基づいて、所望のパケットだけを選別する。ＴＳデコーダ１３４は、パケットのヘッダ情報に基づいて、各種の制御データおよびＭＰＥＧ２システムデータをＲＡＭ１４２に記憶する。ＤＤＢメッセージデータを１モジュール分受信すると、ＲＡＭ１４２にモジュールとして一時記憶する。蓄積部であるハードディスク１４６には、後述する蓄積処理によって、受信したコンテンツが蓄積記憶される。なお、信号受信部１５０は、リモコン装置からの信号などを受信するためのものである。
【００５８】
本実施形態においては、１のモジュールに複数のリソース（コンテンツデータ）がマルチパート化されており、ＲＡＭ１４２にはリソース単位ではなく、モジュール単位で記憶される。ＲＡＭ１４２に一時記憶されたデータは、ハードディスク１４６に書き込まれると、削除される。すなわち、ハードディスク１４６には、モジュールの数だけのファイルが記憶される。
【００５９】
なお、このプログラムは、単独で機能するプログラムであってもよいが、オペレーティングシステム（マイクロソフト社のwindows CEなど）を前提として機能するものであってもよい。
【００６０】
５．〔受信制御プログラム〕
かかる処理を行う制御プログラムについて図１０〜図１２を用いて説明する。ＲＯＭ１４０には、制御プログラム（図示せず）が記録されている。なお、ＣＰＵ１４４に対する指令は、リモコン（図示せず）から与えられ、信号受信部１５０がこれを受信して、ＣＰＵ１４７に与えられる。以下では、図３に示すようなディレクトリ構造で各モジュールに格納されたコンテンツデータを、はじめて蓄積記憶する場合について説明する。
【００６１】
ユーザがサービス受信命令を与えると、ＣＰＵ１４４は、データＤＩＩのパケットＩＤ（ＰＩＤ）などのフィルタリング条件を、図９に示すＴＳデコーダ１３４に設定する。これにより、チューナ１３２によって選択されたトランスポートストリーム中から、データＤＩＩが選択され、ＣＰＵ１４４に与えられる
ＣＰＵ１４４は、データＤＩＩを受信したか否か判断しており（ステップＳ２１）、データＤＩＩを受信すると、前処理を行う（ステップＳ２３）。ステップＳ２３の処理の詳細フローチャートを図１１に示す。
【００６２】
ＣＰＵ１４４は、データＤＩＩから、当該モジュールデータを構成するコンテンツデータの所属ディレクトリ名を取得する（ステップＳ５１）。当該ディレクトリが既に存在するか否か判断し（ステップＳ５２）、存在しない場合には、蓄積先ディレクトリを作成する（ステップＳ５３）。例えば、データＤＩＩに図１３に示すようなディレクトリ情報が記述されている場合、ディレクトリ"/shop1/books/index"、"/shop1/books/ebook/index"・・・などが既に存在するか否か判断する。この場合存在しないので、蓄積先ディレクトリを生成する。
【００６３】
蓄積先ディレクトリ生成処理の詳細フローチャートを図１２に示す。ＣＰＵ１４４は、ハードディスク１４６に記憶されたディレクトリインデックスを取得する（ステップＳ６１）。この場合、はじめてなので、ディレクトリインデックスは存在しない。したがって、ディレクトリ情報としてはルートディレクトリが存在することだけが、読み出される。
【００６４】
ＣＰＵ１４４は、各モジュールを格納するファイルのファイルインデックスを作成する（ステップＳ６３）。具体的には、そのファイルのデータを格納する領域へのリンク情報を記憶する。例えば、あるモジュールを構成するデータをそのモジュール識別子で特定されるファイル名で領域xxxxx1〜xxxxx9に格納する場合、当該ファイル名と当該領域とのリンク情報が記憶される。本実施形態においては、当該ファイル名として、モジュールＩＤを用いるようにした。
【００６５】
ＣＰＵ１４４は、生成したファイルインデックスをインデックスリストに追加する（ステップＳ６５）。具体的には、ファイル管理システムが管理するインデックスリストに、作成したファイルインデックスを追加する。この場合、ステップＳ６３で生成されたファイル名と当該領域とのリンク情報が追加記憶される。
【００６６】
ＣＰＵ１４４は、ディレクトリインデックスを更新する（ステップＳ６７）。具体的には、追加したファイルインデックスへリンクを張るためのインデックスをステップＳ６１で取得したディレクトリインデックスに追加する。この場合、所属するディレクトリとして、ルートディレクトリの下に、ディレクトリ/shop1/books/indexが存在することが記憶される。
【００６７】
つぎに、ＣＰＵ１４４は、カルーセル内の全モジュール数を取得する（図１１ステップＳ５５）。カルーセル内の全モジュール数とは、当該データＤＩＩで管理されるモジュール数であり、データＤＩＩのモジュール数領域（図７参照）を参照すればよい。
【００６８】
つぎに、ＣＰＵ１４４は、一括処理ファイル数nを算出する。一括処理ファイル数nとして、本実施形態においては、以下の計算式を満たす一括処理ファイル数nの最大値を求めるようにした。
【００６９】
Td>N*Tcl+Tm*d+n*Tcr・・・・（１）
ここで、Td：データＤＩＩ先出し期間（固定）、Tcr：１ファイルのファイル作成所要時間（固定）、N：１のデータＤＩＩで管理できる最大モジュール数（固定）、Tcl：１ファイルのファイルクローズの所要時間（固定）、Tm：ディレクトリ作成所要時間（固定）、d：ディレクトリ階層最大数（固定）とする。
【００７０】
なお、前記（１）式にて、ファイルクローズの時間をファイル数Ｎ分考慮しているのは、その前のデータＤＩＩにてオープンしたファイルをクローズする必要があるからである。後述するように、ファイルクローズ処理をまとめて行う場合には、考慮する必要はない。
【００７１】
つぎにＣＰＵ１４４は、ステップＳ５７で決定したn個分のファイルについて、オープン処理をまとめて行う（ステップＳ５９）。
【００７２】
かかる前処理が終了すると、ＣＰＵ１４４は、処理番号iを初期化するとともに、次期オープンファイル番号jをj=n+1とする（図１０ステップＳ２５）。ＣＰＵ１４４は、最初のファイルに格納するモジュールデータを受信するか否か判断し（ステップＳ２７）、これを受信すると、ハードディスクに書き込む（ステップＳ２９）。書き込みが完了するまでこれを繰り返し（ステップＳ３１）、書き込みが完了すると、一時記憶していたメモリのバッファ領域から当該モジュールデータを削除する（ステップＳ３２）。
【００７３】
ＣＰＵ１４４は、次期オープンファイル番号jが最大ファイル数Ｎを越えていないか否か判断し（ステップＳ３３）、越えていない場合には、j番目のファイルについて、ファイル作成処理およびファイルオープン処理を行う（ステップＳ３５）。次期オープンファイル番号jおよび処理番号iをインクリメントし（ステップＳ３７、ステップＳ３９）、処理番号iが最大ファイル数を越えていなければステップＳ２７以下を繰り返す。処理番号iが最大ファイル数を越えると、終了と判断して、Ｎ個のファイルについてファイルクローズ処理を行う（ステップＳ４３）。
【００７４】
かかる蓄積データの再生処理については従来と同様である。操作者から与えられた操作指令が蓄積コンテンツの再生である場合には、ハードディスクから該当のリソースを読み出して、モニタ（図示せず）に出力する。これにより、蓄積コンテンツが再生される。なお、この場合１のモジュールデータは、複数のリソースで構成されており、必要なリソースについてはリソースリストを参照することにより、読み出すことができる。
【００７５】
本実施形態においては、所定時間繰り返して送られてくるデータＤＩＩを受信している間に、比較的時間を要するオープン処理を、ＤＤＢメッセージデータ受信前に複数ファイルについてまとめて行う。これにより、１のモジュールのデータ量を少なくして、モジュール数が増えた場合であっても、データＤＩＩ送出後、連続してＤＢＢメッセージデータを送出するような形式であっても、受信装置にてバッファがあふれるおそれを少なくすることができる。
【００７６】
かかる効果について、図１４〜図１６を用いて説明する。図１４は１のモジュールのデータ量が多い場合である。この場合には、結果的にモジュールの数が少なくなるので、各モジュールの前処理および後処理がそれほど頻繁におこらず、バッファ使用量がハードディスクへの書き込み処理が完了すると、つぎつぎと増えていくおそれがほとんど無い。
【００７７】
一方、図１５は１のモジュールのデータ量が少なく、結果的にモジュールの数が多くなる場合である。このような場合には、所要時間が必要な各モジュールの前処理および後処理が頻繁におこる。このため、バッファしておく必要のあるデータが減らず、バッファ使用量がどんどん増えていき、バッファがオーバフローするおそれがある。
【００７８】
このように１のモジュールのデータ量が少なく、結果的にモジュールの数が多くなる場合であっても、本実施形態のように複数ファイルについて、ファイルオープン処理をデータＤＩＩ受信中に行っておくことにより、バッファオーバフローを防止しやすくなる。
【００７９】
また、送信側にて、１のモジュールで送るデータ量が小さくなった場合に、送信側にてデータＤＩＩの繰り返し送信期間を変更し、これを受信側に通知することにより、受信側のバッファオーバフローにならないようコントロールすることもできる。
【００８０】
なお、図１４〜図１６においては、１モジュールを１ファイルに格納する場合について説明したが、蓄積コンテンツについては、各リソースを１のファイルとして展開して記憶するようにしてもよい。
【００８１】
なお、上記実施形態においては、データＤＩＩを繰り返し送ることにより、データＤＩＩ送出後、ＤＤＢメッセージデータ受信開始までの猶予時間を確保するようにしている。かかる繰り返し送信処理は、プログラムを若干修正することができるので、対応が容易である。なお、ＤＤＢメッセージデータ受信開始までの猶予時間を確保できる形式であれば、データＤＩＩを繰り返し送らなくてもよい。
【００８２】
上記実施形態においては、新たに蓄積コンテンツを記憶する場合について説明したが、蓄積コンテンツを更新する場合には以下のような処理をすればよい。なお、更新か否かは、既に同じ名前のファイルが記憶されているかはないかで判断すればよい。更新の場合は、ファイル作成およびオープン処理の際に、空ファイルで、実行する。そして、この空ファイルに一旦データを書き込み、更新元のファイルを削除してから、前記空ファイルのファイル名を削除したファイル名に変更すればよい。このように、更新の際には、更新元ファイルの削除およびファイル名変更の時間がかかることから、図１１ステップＳ５７の一括処理ファイル数nの算出時には、更新元ファイルの削除およびファイル名変更の時間を考慮するようにすればよい。
【００８３】
本実施形態においては、１のモジュールに複数のファイルがマルチパート化されている場合について説明したが、複数のモジュールで１のファイルを構成するようにしてもよい。この場合は、各モジュールを構成する全ＤＤＢメッセージデータを一時記憶し、各モジュールデータを再現し、さらにこれらのモジュールデータから１のファイルを再現するようにすればよい。
【００８４】
上記実施形態においては、後処理をまとめて実行するようにした（図１０ステップＳ４３参照）。これにより、更新の際には、１のカルーセルで送信される全モジュールが、受信された場合に更新されることとなる。
【００８５】
また、データＤＩＩ受信後、モジュールデータを受信する前に、前処理を複数モジュールについてまとめて行っているが、これに限定されない。
【００８６】
上記実施形態においては、受信装置１１０として、いわゆるセット・トップ・ボックスを例として説明したが、モニタを含むテレビ受像機として構成してもよい。
【００８７】
なお、上記実施形態においては、ファイルをＭＰＥＧ−２トランスポートストリーム上のＤＳＭ−ＣＣオブジェクトカルーセルとＤＳＭ−ＣＣデータカルーセルで伝送したが、同様の処理が行える他のプロトコルで伝送してもよい。
【００８８】
上記各実施形態においてはデジタル衛星放送でデジタルデータ伝送を行う場合について説明したが、デジタル地上波放送、さらにケーブルテレビ等の有線放送にも同じように適用することができる。
【００８９】
上記実施形態においては、図１の各ブロックの機能をハードウェアおよびＣＰＵを用いて実現した場合について説明したが、いずれをハードウェアで構成するかについては、特に限定されず、さらに、ソフトウェアで構成した部分を一部または全部をハードウェアロジックによって構成してもよい。
【００９０】
本実施形態においては、ＲＯＭに表示プログラムを記憶するようにしたが、ＩＣカードやＣＤ−ＲＯＭ等の記憶媒体に記憶し、ＩＣカードドライブやＣＤ−ＲＯＭドライブを介して、不揮発性メモリに転送して記憶するようにしてもよい。さらに、通信（放送を含む）でかかるプログラムを転送して、不揮発性メモリに記憶するようにしてもよい。
【００９１】
また、前記プログラムは、信号搬送波と一体化されたコンピュータデータ信号として、伝送することができる。
【００９２】
なお、本実施形態においては、コンテンツデータの記述形式として、ＢＭＬデータを用いたが、文書データを表示する場合の配置位置、文字列の大きさ、参照する図形データに関する情報等の表示指定情報が付加されたデータであればどのような物であってもよく、ＳＧＭＬ，ＨＴＭＬ，ＸＭＬ型データ、ＭＨＥＧ規格のデータ等であってもよい。また、かかるＢＭＬデータにリンクされる画像、音声データ等もコンテンツデータを構成する。
【００９３】
なお、本実施形態においては、コンテンツデータが多層の階層構造で記憶されている場合について説明したが、かかる階層構造については限定されない。
【００９４】
また、上記実施形態においては、本件発明を、１のデータＤＩＩで送信するモジュール数が増えた場合の課題を解決するものとして説明した。しかしながら、１のデータＤＩＩで送信する総モジュール数が少ない場合でも、バッファ領域からハードディスクへの１モジュール単位ではなくそのつど転送し、転送されるとバッファからデータ削除する場合には、本発明を適用することにより、少ないバッファ容量でもバッファオーバフローを防止することができる。
【００９５】
たとえば、１のデータＤＩＩで送信する最大モジュール数が２つである場合、１のカルーセルで送信できる最大サイズは254.125ＭＢ（4066×216バイト）である。したがって、１のカルーセルを構成するモジュールの総サイズは254.125メガバイト（4066×216バイト）以下となる。この場合、第１のモジュールデータについてハードディスクへの書き込みが終了してから、第２のモジュール用のファイルをハードディスクに前処理すると、当該前処理が完了するまで第２のモジュール用のデータをバッファに蓄積しておく必要がある。これに対して、本件発明のように、送信側ではデータＤＩＩを所定時間（例えば３０秒）送信しておき、受信側では、前記２つのモジュールデータ蓄積用のファイルをまとめて前処理しておくことにより、前記２つのモジュールデータの受信が開始されても、バッファ領域に一時記憶したデータのうち、ハードディスクに転送したデータについては、その都度データを削除することができる。このように、第２のモジュール用のファイル前処理に要する時間が不要となり、バッファ容量を少なくすることができる。
【００９６】
６．〔他の実施形態〕
本発明にかかる他の実施形態における受信システムのブロック図を図１７に示す。なお、以下のすべての実施の形態において、同様の機能を有する構成要素には同じ符号を付し、説明を省略する。
【００９７】
図１７の受信システムは、受信装置１０、および記録媒体２０を有する。受信装置１０は、受信部１１、記録部１２および一括処理数保持部１３を有する。受信部１１は、データ群を受信する。データ群の受信は、一般的にはデジタルテレビ放送であるが、アナログテレビ放送でも、ケーブルテレビでも、インターネットなどの通信によるデータ受信でも良い。また、データ群とは、データの集合であり、固定長でも不定長でも良い。また、データ群は、動画であるテレビ番組や静止画、テキストからなるデータ、静止画およびテキストの組み合わせ、音楽データ、コンピュータプログラム、スクリプトなど何でも良い。
【００９８】
記録部１２は、受信部１１で受信したデータを記録媒体２０に記録する。記録媒体２０については、以下に詳述する。
【００９９】
一括処理数保持部１３は、記録部１２が一括処理するデータ群の数を保持する。記録媒体２０は、例えばハードディスクである。しかし、記録媒体２０は、ハードディスクだけにとどまらず、ＣＤ、ＤＶＤ―ＲＡＭなどの光ディスク、半導体メモリなど、データを記録可能な媒体はいずれの媒体でも良い。
【０１００】
次に、図１８のフローチャートに基づいて受信装置１０の動作を説明する。
【０１０１】
（ステップＳ２０１）記録部１２は、受信部１１がヘッダー情報を受信したか否か判断する。ヘッダー情報を受信しておれば、ステップＳ２０２に行く。ヘッダー情報を受信していなければステップＳ２０１に戻る。なお、ヘッダー情報とは、データ群を送信する前に送られる情報であり、例えば、データ群を格納するディレクトリ名や、受信するデータ群の数や一括処理するデータ群数などの情報が記入されている。ただし、上記の三種類の情報だけでなく、ヘッダー情報の内容は、種々考えられ、また上記三種類の情報が必須であるとも限らない。
【０１０２】
（ステップＳ２０２）記録部１２は、受信部１１が受信したヘッダー情報からディレクトリ名を取り出す。記録部１２は、そのディレクトリ名を持つディレクトリを作成する。
【０１０３】
（ステップＳ２０３）記録部１２は、ヘッダー情報から一括処理数（ここでは、ｎとする。）を取り出す。ここで、一括処理数とは、記録部１２が一括処理するデータ群数である。
【０１０４】
（ステップＳ２０４）記録部１２は、ｎ個のデータ群を記録媒体２０に記録するための前処理（以下、前処理という。）を行う。ここで、例えば、１データ群を１ファイルに記録する場合を想定する。この場合、前処理とは、ファイル生成処理およびファイルオープン処理である。
【０１０５】
（ステップＳ２０５）記録部１２は、ステップＳ２０４の処理がエラーか否かを判断する。エラーであればステップＳ２０４に戻り、エラーでなければステップＳ２０６に行く。前処理におけるエラーか否かの判断は、例えばファイルポインタが正常にリターンされない、等で判断可能である。内部の処理では記録媒体における記憶領域が確保できなかった場合などが該当する。
【０１０６】
（ステップＳ２０６）変数ｉに０を代入する。
【０１０７】
（ステップＳ２０７）記録部１２は、受信部１１がｉ番目のデータ群を受信したか否かを判断する。受信していればステップＳ２０８に行き、受信していなければステップＳ２０７に戻る。
【０１０８】
（ステップＳ２０８）記録部１２は、ｉ番目のデータ群を記録媒体２０に記録するため処理（以下、本処理という。）を行う。ここで、本処理とは、データ群の書きこみ処理である。
【０１０９】
（ステップＳ２０９）記録部１２は本処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２０８に戻る。エラーは発生していなければステップＳ２１０に行く。なお、エラーが発生したか否かは、例えばデータＤＩＩ中にあるデータ群のサイズを取り出し、記録したデータ群のデータサイズと比較して、一致していなければエラーが発生したと判断する。その他、記録（ｗｒｉｔｅ）処理が正常終了しなかった場合はエラーとして判断する、など種々、エラー判断の方法は考えられる。
【０１１０】
（ステップＳ２１０）記録部１２は、ｉ番目のデータ群を記録媒体２０に記録した後の処理（以下、後処理という。）を行う。ここで、後処理とはファイルクローズ処理である。
【０１１１】
（ステップＳ２１１）記録部１２は、ステップＳ２１０における後処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２１０に戻り、エラーが発生していなければステップＳ２１２に行く。後処理のエラーとは、ファイルのクローズに失敗した場合がある。
【０１１２】
（ステップＳ２１２）記録部１２は、（ｎ＋ｉ）番目のデータ群の前処理を行う。
【０１１３】
（ステップＳ２１３）記録部１２は、ステップＳ２１２での処理がエラーか否かを判断する。エラーであれば、ステップＳ２１２に戻り、エラーでなければステップＳ２１４に行く。ここで、例えば、ファイルオープン処理（関数ｆｉｌｅｏｐｅｎ（）を実行する）を行った場合を想定する。エラーか否かの判断は、ファイルオープン関数の実行時のリターン値（ファイルポインタがリターンされる）が妥当なファイルポイントであるか否かによる。
【０１１４】
（ステップＳ２１４）ｉにｉ＋１を代入する。ステップＳ２０７に行く。
【０１１５】
次に、上記で説明した受信装置の具体的なデータ群の書き込み処理の例について図１９を用いて説明する。本具体例において、受信装置はデジタルテレビである。また、データ群は、１ＭＢのデータである。また、記録部１２における記録は、データ群をファイルに記録する。また、前処理は、ファイル生成処理（ｃｒｅａｔｅ）、ファイルオープン処理（ｏｐｅｎ）である。本処理は、データ群の書き込み処理（ｗｒｉｔｅ）である。後処理は、ファイルクローズ処理（ｃｌｏｓｅ）である。
【０１１６】
かかる場合に、放送局からデータＤＩＩというヘッダーが送信される。データＤＩＩは、データ群の長さ（本具体例では、１ＭＢ）、データ群の数、データ群の識別子、データ群のバージョン、データ群を記録するディレクトリ名、一括処理するデータ群数（一括処理数）などを含む。なお、データ群とは、図３においては、モジュール（ｍｏｄｕｌｅ）と言う。
【０１１７】
次に、受信部１１はデータＤＩＩを受信する。ここで、受信部１１は、例えば、チューナーおよびデータを記録するメモリなどのハードウェアで実現されている。次に、記録部１２は、データＤＩＩからディレクトリ名を取り出し、ディレクトリを作成する。そして、記録部１２は、データＤＩＩ中の一括処理数（本具体例では、５とする。）を取得する。次に、記録部１２は一括処理数を一括処理数保持部１３に記録する。なお、一括処理数は、データＤＩＩ中に含まれていることが必須ではなく、受信装置に予め格納されていても良いし、インターネットを経由して通信で取得される、またはＤＶＤ等の蓄積媒体から取得されるなど、種々の手段で取得されても良い。
【０１１８】
そして、記録部１２は取得した一括処理数（５）のファイルの生成およびオープンを行う。記録部１２は、以上の前処理により５つのファイルポインタを得る。そして、受信部１１は０番目（０番目から始まる）のモジュールを受信する。次に、記録部１２は、０番目のモジュールを受信部１１から取り出し、モジュールの内容を記録媒体２０に記録（ｗｒｉｔｅ）する。記録の際に、０番目のファイルポインタを記録する関数に引数として渡す。記録が終了すると、０番目のファイルをクローズする。
【０１１９】
次に、５番目のファイルの前処理（ｃｒｅａｔｅ、ｏｐｅｎ）を行う。なお、記録部１２が０番目のモジュールを受信部１１から取り出した後、１番目のモジュールを受信部１１が受信する。この１番目のモジュールを受信している間に、上記の処理、つまり、０番目のデータのｗｒｉｔｅ、ｃｌｏｓｅ、５番目のデータのｃｒｅａｔｅ、ｏｐｅｎを行う。このファイル処理（ｃｒｅａｔｅ、ｏｐｅｎ、ｗｒｉｔｅ、ｃｌｏｓｅ）は、ソフトウェアにより実現される。勿論、図示しないＣＰＵがソフトウェアを解釈実行して、ファイル処理を行う。つまり、記録部１２は、例えばＣＰＵとソフトウェアで実現されている。
【０１２０】
次に、記録部１２は、１番目のモジュールを取り出し、１番目のファイルポインタで識別されるファイルにそのモジュールを記録する。そして、記録部１２は、１番目のファイルをクローズする。
【０１２１】
次に、記録部１２は、６番目のファイルの前処理を行う。
【０１２２】
以下、図１９に示す流れで処理が行われる。
【０１２３】
なお、上記において複数のデータ群に対する前処理は一括して行われた。この「一括して行う」とは、前処理のｃｒｅａｔｅ、ｏｐｅｎが連続して行われた場合だけでなく、２つの処理の間に別の処理があっても良い。また、「一括して行う」の意味として、モジュール０の前処理とモジュール１の前処理は連続して行われることが普通であるが、これに限らず、モジュール０の前処理とモジュール１の前処理の間に別の処理が行われる場合も含まれる。つまり、「一括して行う」とは、前処理をモジュールの書き込み処理中には行わず、前もって行うことを言う。
【０１２４】
以上のように、本実施の形態によれば、複数のデータ群を連続して受信して記録する際に、最初に複数のデータ群の前処理を一括して行うことにより、データ群受信または記録中にエラーが発生した場合にも、エラーとなった処理を再度行う（リトライする）ことにより、すべてのデータ群を安全に記録媒体に記録することができる。
【０１２５】
なお、本実施の形態において、データはファイルに記録されたが、データベースに記録されても良い。かかる場合、前処理は、例えばテーブル生成およびテーブルオープンであり、本処理はテーブルへの書き込みであり、後処理はテーブルクローズである。また、ファイルやデータベース以外の論理構造を持つ対象に記録されても良い。以下、すべての実施の形態において同じである。
【０１２６】
また、本実施の形態において、受信部１１はチューナーを含むハードウェアで実現され、記録部１２はＣＰＵとソフトウェアで実現されていたが、受信部１１も一部ソフトウェアで実現しても良いし、記録部１２もソフトウェアではなく、すべてハードウェア（回路）で実現しても良い。
【０１２７】
また、本実施の形態において、データ群は１ＭＢの固定長のデータブロックであったが、不定長のデータであっても良い。かかる場合、データ群の長さは、データＤＩＩ（ヘッダー）に格納されているのが通常である。以下、すべての実施の形態において、データ群は同様である。
【０１２８】
さらに、上述の記録部１２の記録処理をソフトウェアで実現して、そのソフトウェアをインターネット等のネットワークや放送により流布しても良い。また、そのソフトウェアをＣＤ−ＲやＤＶＤなどのコンピュータ読取可能な記録媒体に記録して流通させても良い。以下、すべての実施の形態において、記録部の各種処理は同様である。
【０１２９】
他の実施形態における受信システムの概要図を図２０に示す。
【０１３０】
図２０の受信システムは、受信装置４０、記録媒体２０を有する。受信装置４０は、受信部１１、記録部４２を有する。記録部４２は、受信部１１で受信したデータを記録媒体２０に記録する。記録の方法が記録部１２とは異なる。
【０１３１】
本実施形態における記録部４２の記録の方法について以下、詳述する。まず、図２１のフローチャートに基づいて受信装置４０の動作を説明する。
【０１３２】
（ステップＳ２０１）記録部４２は、受信部１１がヘッダー情報を受信したか否か判断する。ヘッダー情報を受信しておれば、ステップＳ２０２に行く。ヘッダー情報を受信していなければステップＳ２０１に戻る。
【０１３３】
（ステップＳ２０２）記録部４２は、受信部１１が受信したヘッダー情報からディレクトリ名を取り出す。記録部４２は、そのディレクトリ名を持つディレクトリを作成する。
【０１３４】
（ステップＳ２０３）記録部４２は、ヘッダー情報から一括処理数（ここでは、ｎとする。）を取り出す。
【０１３５】
（ステップＳ２０４）記録部４２は、ｎ個のデータ群の前処理を行う。
【０１３６】
（ステップＳ２０５）記録部４２は、ステップＳ２０４の処理がエラーか否かを判断する。エラーであればステップＳ２０４に戻り、エラーでなければステップＳ２０６に行く。
【０１３７】
（ステップＳ２０６）変数ｉに０を代入する。
【０１３８】
（ステップＳ２０７）記録部４２は、受信部１１がｉ番目のデータ群を受信したか否かを判断する。受信していればステップＳ２０８に行き、受信していなければステップＳ２０７に戻る。
【０１３９】
（ステップＳ２０８）記録部１２は、ｉ番目のデータ群の本処理を行う。
【０１４０】
（ステップＳ２０９）記録部１２は本処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２０８に戻る。エラーは発生していなければステップＳ２１４に行く。
【０１４１】
（ステップＳ２１４）ｉにｉ＋１を代入する。
【０１４２】
（ステップＳ５０１）記録部４２は、ｉをｎで割った余りが０か否かを判断する。０であればステップＳ５０２に行き、０でなければステップＳ２０６に戻る。
【０１４３】
（ステップＳ５０２）ｊに０を代入する。
【０１４４】
（ステップＳ５０３）記録部４２は、（ｉ−ｎ＋ｊ）番目のデータ群の後処理を行う。
【０１４５】
（ステップＳ５０４）記録部４２は、ステップＳ５０３での後処理がエラーでないか否かを判断する。エラーであればステップＳ５０３に戻る。エラーでなければステップＳ５０５に行く。
【０１４６】
（ステップＳ５０５）ｉにｊ＋１を代入する。
【０１４７】
（ステップＳ５０６）ｊがｎ−１と等しいか否かを判断する。等しければステップＳ５０７に行き、等しくなければステップＳ５０３に戻る。
【０１４８】
（ステップＳ５０７）記録部４２は、ｎ個のデータ群の前処理を行う。
【０１４９】
（ステップＳ５０８）記録部４２は、ステップＳ５０７での前処理がエラーでないか否かを判断する。エラーであればステップＳ５０７に戻る。エラーでなければステップＳ２０７に行く。
【０１５０】
次に、上記で説明した受信装置の具体的なデータ群の書き込み処理の例について図２２を用いて説明する。本具体例において、受信装置はデジタルテレビである。また、データ群（モジュール）は、１ＭＢのデータである。また、記録部４２における記録は、モジュールをファイルに記録する。また、前処理は、ファイル生成処理（ｃｒｅａｔｅ）、ファイルオープン処理（ｏｐｅｎ）である。本処理は、データ群の書き込み処理（ｗｒｉｔｅ）である。後処理は、ファイルクローズ処理（ｃｌｏｓｅ）である。
【０１５１】
かかる場合に、放送局からデータＤＩＩが送信される。次に、受信部１１はデータＤＩＩを受信する。次に、記録部４２は、データＤＩＩからディレクトリ名を取り出し、ディレクトリを作成する。そして、記録部４２は、データＤＩＩ中の一括処理数（本具体例では、ｎとする。）を取得する。
【０１５２】
そして、記録部４２は取得した一括処理数（ｎ）のファイルの生成およびオープンを行う。記録部４２は、以上の前処理によりｎ個のファイルポインタを得る。そして、受信部１１は０番目（０番目から始まる）のモジュールを受信する。次に、記録部４２は、０番目のモジュールを受信部１１から取り出し、モジュールの内容を記録媒体２０に記録（ｗｒｉｔｅ）する。記録の際に、０番目のファイルポインタを記録する関数に引数として渡す。なお、本実施の形態においては、後処理を本処理の直後に行わず、後処理も一括して行う。
【０１５３】
次に、１番目のモジュールの本処理を行う。さらに、２番目のモジュールの本処理、ｎ−２番目のモジュールの本処理、ｎ−１番目のモジュールの本処理を次々に行っていく。かかる本処理とは別に受信部１１が０番目からｎ−１番目のモジュールを受信する。受信部１１がｎ−ｍ番目のモジュールの受信（受信部１１が保持する記録手段に記録すること）を完了してからｎ−ｍ＋１番目のモジュールの受信を開始する（ｎ−ｍ＋１番目のモジュールの記録を開始する）までに、記録部４２はｎ−ｍ番目のモジュールを記録媒体２０に記録する。
【０１５４】
次に、一括処理すべきモジュールの本処理が完了した段階で、本処理した分のモジュールの後処理を行う。後処理とは、ファイルクローズである。
【０１５５】
さらに、次のｎ個のモジュールについて前処理を行う。
【０１５６】
なお、上記において複数のデータ群に対する前処理は一括して行われた。この「一括して行う」とは、前処理のｃｒｅａｔｅ、ｏｐｅｎが連続して行われた場合だけでなく、２つの処理の間に別の処理があっても良い。また、「一括して行う」の意味として、モジュール０の前処理とモジュール１の前処理は連続して行われることが普通であるが、これに限らず、モジュール０の前処理とモジュール１の前処理の間別の処理が行われる場合も含まれる。また、後処理もｎ個の後処理が連続して行われているが、他の処理が間に入る場合も、「一括して行う」に含まれる。つまり、「一括して行う」とは、前処理および後処理をモジュールの書き込み処理中には行わず、前もって行って、または後で別途行うことを言う。
【０１５７】
なお、図２２に示すように、本実施形態において、ｎ個のモジュールが連続して送信された後、一括した後処理および一括した前処理のために一定以上の時間的間隔が置かれるものとする。
【０１５８】
以上のように、本実施の形態によれば、複数のデータ群を連続して受信して記録する際に、最初に複数のデータ群の前処理だけではなく、後処理をも一括して行うことにより、データ群受信または記録中にエラーが発生したにも、エラーとなった処理を再度行う（リトライする）ことによりすべてのデータ群をさらに安全に記録媒体に記録することができる。
【０１５９】
なお、本実施の形態において、通常、記録部４２はＣＰＵとソフトウェアで実現されているが、すべてハードウェア（回路）で実現しても良い。
【０１６０】
さらに、本実施の形態において、前処理と後処理の双方を一括して行ったが、後処理のみを一括して行っても良い。かかる場合でも、前処理、本処理、後処理をシーケンシャルに行うより、エラーに強い受信装置が実現できる。
【０１６１】
本発明にかかる他の実施形態の概要図を図２３に示す。
【０１６２】
図２３の受信システムは、受信装置７０、記録媒体２０を有する。受信装置７０は、受信部１１、記録部７２、属性情報保持部７３、一括処理数決定部７４を有する。属性情報保持部７３は、受信装置７０のＣＰＵ能力やメモリサイズなどの受信装置７０の属性に関する情報（以下、属性情報という。）を保持する。
【０１６３】
一括処理数決定部７４は、属性情報保持部７３で保持している属性情報に基づいて一括して処理するデータ群数を決定する。
【０１６４】
次に、図２４のフローチャートに基づいて受信装置７０の動作を説明する。
【０１６５】
（ステップＳ８０１）記録部７２は、予め決められた名称のディレクトリを作成する。
【０１６６】
（ステップＳ８０２）一括処理数決定部７４は、属性情報取得部７３が保持する属性情報を取得する。
【０１６７】
（ステップＳ８０３）一括処理数決定部７４は、取得した属性情報に基づいて一括処理するデータ群数を決定する。詳細は、以下に述べる。
【０１６８】
（ステップＳ２０４）記録部７２は、ｎ個のデータ群を記録媒体２０に記録するための前処理（以下、前処理という。）を行う。ここで、例えば、１データ群を１ファイルに記録する場合を想定する。この場合、前処理とは、ファイル生成処理およびファイルオープン処理である。
【０１６９】
（ステップＳ２０５）記録部７２は、ステップＳ２０４の処理がエラーか否かを判断する。エラーであればステップＳ２０４に戻り、エラーでなければステップＳ２０６に行く。前処理におけるエラーか否かの判断は、例えばファイルポインタが正常にリターンされない、等で判断可能である。内部の処理では記録媒体における記憶領域が確保できなかった場合などが該当する。
【０１７０】
（ステップＳ２０６）変数ｉに０を代入する。
【０１７１】
（ステップＳ２０７）記録部７２は、受信部１１がｉ番目のデータ群を受信したか否かを判断する。受信していればステップＳ２０８に行き、受信していなければステップＳ２０７に戻る。
【０１７２】
（ステップＳ２０８）記録部７２は、ｉ番目のデータ群の本処理を行う。
【０１７３】
（ステップＳ２０９）記録部７２は本処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２０８に戻る。エラーは発生していなければステップＳ２１０に行く。
【０１７４】
（ステップＳ２１０）記録部７２は、ｉ番目のデータ群の後処理を行う。
【０１７５】
（ステップＳ２１１）記録部７２は、ステップＳ２１０における後処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２１０に戻り、エラーが発生していなければステップＳ２１２に行く。
【０１７６】
（ステップＳ２１２）記録部７２は、（ｎ＋ｉ）番目のデータ群の前処理を行う。
【０１７７】
（ステップＳ２１３）記録部７２は、ステップＳ２１２での処理がエラーか否かを判断する。エラーであれば、ステップＳ２１２に戻り、エラーでなければステップＳ２１４に行く。
【０１７８】
（ステップＳ２１４）ｉにｉ＋１を代入する。ステップＳ２０７に行く。
【０１７９】
次に、上記で説明した受信装置の特徴的処理は、ステップＳ８０３である。つまり、属性情報から一括処理するデータ群数を決定する処理である。以下、その処理について詳述する。
【０１８０】
今、属性情報保持部７３に、受信装置７０のＣＰＵ能力とメモリサイズが格納されているとする。そして、一括処理数決定部７４は、ＣＰＵ能力とメモリサイズに基づいて一括処理数を決定する。通常、ＣＰＵ能力が大であればあるほど一括処理数が増加する。また、メモリサイズが大きければ大きいほど一括処理数が増加する。
【０１８１】
具体的には、一括処理数決定部７４は、関数ｚ＝ｆ（ｘ、ｙ）（ｚは一括処理数、ｘはＣＰＵ能力、ｙはメモリサイズ）に基づいて一括処理数を決定する。ただし、一括処理数決定部７４において、上記のような関数により一括処理数を決定しても良いが、ＣＰＵ能力とメモリサイズから一括処理数が決定できる表により一括処理数を決定しても良い。
【０１８２】
さらに、属性情報はＣＰＵ能力とメモリサイズだけではなく、その他受信装置７０の属性情報を用いれば何でもよい。また、一括処理数決定部７４は、受信装置７０の属性情報を用いていれば、当該属性情報に加えて外部からの情報をも用いて一括処理数を決定しても良い。
【０１８３】
次に、図２５のフローチャートに基づいて受信装置７０の別の動作を説明する。先の場合と違うのは、複数のデータ群の後処理も一括して行っている点である。
【０１８４】
（ステップＳ８０１）記録部７２は、予め決められた名称のディレクトリを作成する。
【０１８５】
（ステップＳ８０２）一括処理数決定部７４は、属性情報取得部７３が保持する属性情報を取得する。
【０１８６】
（ステップＳ８０３）一括処理数決定部７４は、取得した属性情報に基づいて一括処理するデータ群数を決定する。詳細は、以下に述べる。
【０１８７】
（ステップＳ２０４）記録部７２は、ｎ個のデータ群の前処理を行う。
【０１８８】
（ステップＳ２０５）記録部７２は、ステップＳ２０４の処理がエラーか否かを判断する。エラーであればステップＳ２０４に戻り、エラーでなければステップＳ２０６に行く。
【０１８９】
（ステップＳ２０６）変数ｉに０を代入する。
【０１９０】
（ステップＳ２０７）記録部７２は、受信部１１がｉ番目のデータ群を受信したか否かを判断する。受信していればステップＳ２０８に行き、受信していなければステップＳ２０７に戻る。
【０１９１】
（ステップＳ２０８）記録部７２は、ｉ番目のデータ群の本処理を行う。
【０１９２】
（ステップＳ２０９）記録部７２は本処理にエラーが発生したか否かを判断する。エラーが発生していればステップＳ２０８に戻る。エラーは発生していなければステップＳ２１４に行く。
【０１９３】
（ステップＳ２１４）ｉにｉ＋１を代入する。
【０１９４】
（ステップＳ５０１）記録部７２は、ｉをｎで割った余りが０か否かを判断する。０であればステップＳ５０２に行き、０でなければステップＳ２０７に戻る。
【０１９５】
（ステップＳ５０２）ｊに０を代入する。
【０１９６】
（ステップＳ５０３）記録部７２は、（ｉ−ｎ＋ｊ）番目のデータ群の後処理を行う。
【０１９７】
（ステップＳ５０４）記録部７２は、ステップＳ５０３での後処理がエラーでないか否かを判断する。エラーであればステップＳ５０３に戻る。エラーでなければステップＳ５０５に行く。
【０１９８】
（ステップＳ５０５）ｉにｊ＋１を代入する。
【０１９９】
（ステップＳ５０６）ｊがｎ−１と等しいか否かを判断する。等しければステップＳ５０７に行き、等しくなければステップＳ５０３に戻る。
【０２００】
（ステップＳ５０７）記録部７２は、ｎ個のデータ群の前処理を行う。
【０２０１】
（ステップＳ５０８）記録部７２は、ステップＳ５０７での前処理がエラーでないか否かを判断する。エラーであればステップＳ５０７に戻る。エラーでなければステップＳ２０７に行く。
【０２０２】
以上のように、本実施の形態によれば、受信装置の属性情報に基づいて適切な一括処理数が決定されることにより、すべてのデータ群をさらに安全に記録媒体に記録することができる。
【０２０３】
本発明にかかる他の実施形態のブロック図を図２６に示す。
【０２０４】
図２６の受信システムは、受信装置１００、記録媒体２０を有する。受信装置１００は、受信部１１、ｎ個の記録部（９１から９ｎ）を有する。記録部９１等は、受信部１１で受信したデータを記録媒体２０に記録する。記録の方法が記録部１２、記録部４２等とは異なる。以下、本実施の形態における記録部９１等の記録の方法について詳述する。
【０２０５】
次に、図２７のモジュールの記録処理の流れを示す概要図を用いて、記録部９１から記録部９ｎの動作について説明する。
【０２０６】
今、ｎは３である。そして、記録部９１はＣＰＵ１に該当する。記録部９２はＣＰＵ２に、記録部９３はＣＰＵ３に該当する。ＣＰＵ１は、前処理を専門に行う。ＣＰＵ２は本処理を行う。ＣＰＵ３は後処理を行う。そして、各ＣＰＵ間で各処理に必要な情報が渡される。
【０２０７】
そして、受信部１１は、データＤＩＩを受信した後、連続してモジュールを受信する。
【０２０８】
以上の状況で、まずＣＰＵ１がモジュール０の前処理（例えば、ファイル生成、ファイルオープン）を行う。そして、ＣＰＵ１からファイルポインタをＣＰＵ２に渡す。次に、ＣＰＵ２は本処理を行う。つまり、渡されたファイルポインタにより特定されるファイルにモジュールを書き込む。書き込みが終了すると、ＣＰＵ２はファイルポインタをＣＰＵ３に渡す。さらに、ＣＰＵ３は後処理を行う。具体的には、ＣＰＵ３は、渡されたファイルポインタで特定されるファイルをクローズする。
【０２０９】
以上のように、３つのＣＰＵを用いて、パイプライン処理を行い、連続して送信されるモジュールを安全に記録する。
【０２１０】
なお、上記によれば、パイプライン処理により安全にモジュールを記録する処理を行ったが、複数のＣＰＵがある環境であれば、モジュール０の記録処理（前処理、本処理、後処理）をＣＰＵ１で行い、モジュール１の記録処理をＣＰＵ２で行うなど、モジュール処理毎に担当するＣＰＵを分けても良い。この場合、どのＣＰＵがどのモジュールを処理するかは、他のＣＰＵで制御しても良いし、メッセージパッシングによって知らせあっても良い。
【０２１１】
以上説明したように、本発明によれば、複数のデータ群を連続して受信して記録する際に、複数のデータ群の前処理または／および後処理を一括して行うことにより、エラーが発生してもすべてのデータ群を安全に記録媒体に記録することができる。
【０２１２】
本発明は以下のような装置または方法にかかる発明として把握することができる。
【０２１３】
（１）複数のデータ群を受信する受信部と、前記受信部で受信したデータ群を記録媒体に記録する記録部とを具備する受信装置であって、前記記録部は、データ群を記録媒体に記録するための前処理と、データ群を記録媒体に記録する本処理と、データ群を記録媒体に記録するための後処理を行い、複数のデータ群に対する前処理を本処理の前に一括して行うことを特徴とする受信装置。
【０２１４】
（２）複数のデータ群を受信する受信部と、前記受信部で受信したデータ群を記録媒体に記録する記録部とを具備する受信装置であって、前記記録部は、データ群を記録媒体に記録するための前処理と、データ群を記録媒体に記録する本処理と、データ群を記録媒体に記録するための後処理を行い、複数のデータ群に対する後処理を本処理の後に一括して行うことを特徴とする受信装置。
【０２１５】
（３）複数のデータ群を受信する受信部と、前記受信部で受信したデータ群を記録媒体に記録する記録部とを具備する受信装置であって、前記記録部は、データ群を記録媒体に記録するための前処理と、データ群を記録媒体に記録する本処理と、データ群を記録媒体に記録するための後処理を行い、複数のデータ群に対する前処理を本処理の前に一括して行い、かつ複数のデータ群に対する後処理を本処理の後に一括して行うことを特徴とする受信装置。
【０２１６】
（４）一括して前処理を行うデータ群数を保持する一括処理数保持部をさらに具備し、前記記録部は、前記一括処理数保持部で保持しているデータ群数のデータ群の前処理を一括して行うことを特徴とする前記（１）〜（３）いずれかに記載の受信装置。
【０２１７】
（５）受信装置の属性である属性情報を保持する属性情報保持部と、前記属性情報保持部で保持する属性情報に基づいて一括して前処理を行うデータ群数を決定するデータ群数決定部とをさらに具備し、前記記録部は、前記一括処理数保持部で保持しているデータ群数のデータ群の前処理を一括して行うことを特徴とする前記（１）〜（３）いずれかに記載の受信装置。
【０２１８】
（６）複数のデータ群を受信する受信部と、前記受信部で受信したデータ群を記録媒体に記録するために第一の記録部と第二の記録部と第三の記録部とを具備する受信装置であって、前記第一の記録部はデータ群を記録媒体に記録するための前処理を行い、前記第二の記録部はデータ群を記録媒体に記録する本処理を行い、前記第三の記録部はデータ群を記録媒体に記録するための後処理を行い、前記３つの記録部がデータ群に対する前処理、本処理、後処理をリレーして行うことを特徴とする受信装置。
【０２１９】
（７）前記記録部はデータ群をファイルとして記録媒体に記録し、前記前処理はファイル作成およびファイルオープン処理であり、前記本処理はファイル書きこみ処理であり、前記後処理はファイルクローズ処理であることを特徴とする前記（１）〜（６）いずれかに記載の受信装置。
【０２２０】
（８）受信された複数のデータ群を記録媒体に記録するプログラムであって、前記プログラムは、データ群を記録媒体に記録するための前処理ステップと、データ群を記録媒体に記録する本処理ステップと、データ群を記録媒体に記録するための後処理ステップを有し、複数のデータ群に対する複数の前処理ステップを本処理ステップの前に一括して行うことを特徴とするプログラム。
【０２２１】
（９）受信された複数のデータ群を記録媒体に記録するプログラムであって、前記プログラムは、データ群を記録媒体に記録するための前処理ステップと、データ群を記録媒体に記録する本処理ステップと、データ群を記録媒体に記録するための後処理ステップを有し、複数のデータ群に対する複数の後処理ステップを本処理ステップの後に一括して行うことを特徴とするプログラム。
【０２２２】
（１０）受信された複数のデータ群を記録媒体に記録するプログラムであって、前記プログラムは、データ群を記録媒体に記録するための前処理ステップと、データ群を記録媒体に記録する本処理ステップと、データ群を記録媒体に記録するための後処理ステップを有し、複数のデータ群に対する複数の前処理ステップを本処理ステップの前に一括して行い、かつ複数のデータ群に対する複数の後処理ステップを本処理ステップの後に一括して行うことを特徴とするプログラム。
【０２２３】
（１１）記憶されている一括して前処理を行うデータ群数を取得するデータ群数取得ステップをさらに具備し、前記前処理ステップは、前記データ群数のデータ群の前処理を一括して行うことを特徴とする請求項８または請求項１０いずれか記載のプログラム。
【０２２４】
（１２）記録している属性情報に基づいて一括して前処理を行うデータ群数を決定する一括処理数決定ステップとをさらに具備し、前記前処理ステップは、前記一括処理数決定ステップで決定した一括処理数のデータ群の前処理を一括して行うことを特徴とする前記（８）〜（１０）いずれかに記載の受信装置。
【図面の簡単な説明】
【図１】本発明にかかる送受信システムの全体構成を示す図である。
【図２】送信装置１の機能ブロック図である。
【図３】コンテンツデータのディレクトリ構造である。
【図４】送信装置１のハードウェア構成の一例である。
【図５】送信装置１の送信処理フローチャートである。
【図６】モジュールデータのデータ構造を示す図である。
【図７】データＤＩＩのデータ構造を示す図である。
【図８】データＤＩＩが繰り返し送信された後、ＤＢＢメッセージデータが送信された状態を説明するための図である。
【図９】受信装置のハードウェア構成を示す図である。
【図１０】モジュール蓄積恣処理のフローチャートである。
【図１１】前処理の詳細フローチャートである。
【図１２】ディレクトリ作成処理のフローチャートである。
【図１３】ディレクトリ構造を示す図である。
【図１４】バッファ使用量とモジュール書き込み処理との関係を示す図である。
【図１５】バッファ使用量とモジュール書き込み処理との関係を示す図である。
【図１６】バッファ使用量とモジュール書き込み処理との関係を示す図である。
【図１７】他の実施形態における受信システムのブロック図である。
【図１８】図１７の受信装置１０の動作を説明するフローチャートである。
【図１９】受信装置１０の書き込み処理を示す図である。
【図２０】他の実施形態における受信システムのブロック図である。
【図２１】受信装置４０の動作を説明するフローチャートである。
【図２２】受信装置４０の書き込み処理を示す図である。
【図２３】他の実施形態における受信システムのブロック図である。
【図２４】受信装置７０の動作を説明するフローチャートである。
【図２５】受信装置７０における他の動作を説明するフローチャートである。
【図２６】他の実施形態における受信システムのブロック図である。
【図２７】受信装置１００の書き込み処理を示す図である。
【符号の説明】
１０１・・・・・送信装置
１０３・・・・・コンテンツデータ記憶手段
１０５・・・・・モジュール化手段
１０６・・・・・モジュール化データ記憶手段
１０７・・・・・構成モジュール管理情報生成手段
１１０・・・・・受信装置
１１１・・・・・受信手段
１１３・・・・・一時記憶手段
１１５・・・・・制御手段
１１７・・・・・記憶手段
Claims (22)
- 送信装置に、コンテンツデータを、ディレクトリ構造で管理された複数のファイルに分けて記憶しておき、前記送信装置から前記ディレクトリ構造の情報および前記複数のファイルをデジタル放送するとともに、受信装置で前記ディレクトリ構造の情報および前記複数のファイルを受信し、前記ディレクトリ構造にて前記複数のファイルを蓄積記憶するデジタルデータ送受信システムにおいて、
前記送信装置は、前記ディレクトリ構造の情報をデータＤＩＩのプライベート領域に格納して、当該ＤＩＩの送信を複数回繰り返すことにより、前記複数のファイルをＤＤＢメッセージデータにて送信するまでの所定の猶予時間を確保し、
前記受信装置は、前記データＤＩＩを受信すると、前記プライベート領域から前記ディレクトリ構造の情報を読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行すること、
を特徴とするデジタルデータ送受信システム。 - ディレクトリ構造で管理された複数のファイルに分けて記憶されたコンテンツデータがデジタル放送されると、これを受信して前記ディレクトリ構造で管理された複数のファイルに分けて蓄積記憶するデジタルデータ受信装置において、
データＤＩＩを受信すると、当該データＤＩＩの前記プライベート領域から、管理するファイルのディレクトリ構造の情報を読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行し、
ＤＤＢメッセージデータにて前記複数のファイルを受信すると、前記書き込み準備ファイルに書き込み処理をすること、
を特徴とするデジタルデータ受信装置。 - コンテンツデータを、ディレクトリ構造で管理された複数のファイルに分けて記憶しておき、前記ディレクトリ構造の情報および前記複数のファイルをデジタル放送するデジタルデータ送信装置において、
前記ディレクトリ構造の情報をデータＤＩＩのプライベート領域に格納して、当該ＤＩＩの送信を複数回繰り返すことにより、前記複数のファイルをＤＤＢメッセージデータにて送信するまでの所定の猶予時間を確保すること、
を特徴とするデジタルデータ送信装置。 - 請求項３のデジタルデータ送信装置において、
１のデータＤＩＩで管理する総モジュール数は２つであり、
前記所定時間は３０秒間であること、
を特徴とするデジタルデータ送信装置。 - 請求項２のデジタルデータ受信装置において、
前記読み出したディレクトリ構造の情報で管理されるファイルのうち、ファイル書き込み準備処理をまとめて実行した複数のファイルについて、当該複数のファイルの書き込み処理を終了してから、当該複数のファイルについての閉じ処理をする同じデータＤＩＩで特定される全ファイルの書き込み終了してから、前記全ファイルの閉じ処理をすること、
を特徴とするデジタルデータ受信装置。 - 請求項２のデジタルデータ受信装置において、
前記コンテンツデータは、他のコンテンツデータへのリンク情報を含んでいること、
を特徴とするデジタルデータ受信装置。 - 請求項２のデジタルデータ受信装置において、
１のモジュールを１ファイルに記憶すること、
を特徴とするデジタルデータ受信装置。 - ディレクトリ構造で管理された複数のファイルに分けて記憶されたコンテンツデータがデジタル放送されると、これを受信して前記ディレクトリ構造で管理された複数のファイルに分けて蓄積記憶するデジタルデータ受信装置において、
データＤＩＩのプライベート領域から読み出したディレクトリ構造の情報で管理されるファイルのうち、ファイル書き込み準備処理をまとめて実行した複数のファイルについて、当該複数のファイルの書き込み処理を終了してから、当該複数のファイルについての閉じ処理をすること、
を特徴とするデジタルデータ受信装置。 - デジタル放送されたコンテンツデータを受信して蓄積記憶するデジタルデータ受信装置において、
データＤＩＩを受信すると、当該データＤＩＩの前記プライベート領域から前記ディレクトリ構造の情報を読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行すること、
を特徴とするデジタルデータ受信装置。 - 請求項９のデジタルデータ受信装置において、
前記データＤＩＩを受信すると、当該データＤＩＩの前記プライベート領域から前記ディレクトリ構造の情報を読み出してファイル開き処理準備の必要なファイルを決定すること、
を特徴とするデジタルデータ受信装置。 - 請求項９のデジタルデータ受信装置において、
前記複数まとめて実行されるファイル書き込み準備処理は、前記モジュールのインデックスデータを含むデータＤＩＩを受信する前に、所定数のファイルについて仮ファイル名で開き処理準備をしておき、データＤＩＩを受信すると、前記ディレクトリ構造で管理されるファイル名を抽出し、前記開き処理準備したファイルのファイル名を前記抽出したファイル名に変更すること、
を特徴とするデジタルデータ受信装置。 - 請求項２、請求項５〜請求項１１のいずれかのデジタルデータ受信装置を含むデジタル放送用のセットトップボックス。
- 請求項２、請求項５〜請求項１１のいずれかのデジタルデータ受信装置を含むデジタル放送用のテレビ。
- ディレクトリ構造で管理された複数のファイルに分けて記憶されたコンテンツデータがデジタル放送されると、これを受信して前記ディレクトリ構造で管理された複数のファイルに分けて蓄積記憶するデジタルデータ受信装置において、
ファイル管理情報を受信すると、当該ファイル管理情報にて管理するファイルのディレクトリ構造の情報を、当該ファイル管理情報から読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行すること、
を特徴とするデジタルデータ受信装置。 - 送信装置に、コンテンツデータを、ディレクトリ構造で管理された複数のファイルに分けて記憶しておき、前記放送装置から前記ディレクトリ構造の情報および前記複数のファイルをデジタル放送するとともに、受信装置で前記ディレクトリ構造の情報および前記複 数のファイルを受信し、前記ディレクトリ構造にて前記複数のファイルを蓄積記憶するデジタルデータ送受信方法において、
前記送信装置は、前記ディレクトリ構造の情報をデータＤＩＩのプライベート領域に格納して、当該ＤＩＩの送信を複数回繰り返すことにより、前記複数のファイルをＤＤＢメッセージデータにて送信するまでの所定の猶予時間を確保し
前記受信装置は、前記データＤＩＩを受信すると、前記プライベート領域から前記ディレクトリ構造の情報を読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行すること、
を特徴とするデジタルデータ送受信方法。 - コンテンツデータを、ディレクトリ構造で管理された複数のファイルに分けて記憶しておき、前記ディレクトリ構造の情報および前記複数のファイルをデジタル放送するデジタルデータ送信方法において、
前記ディレクトリ構造の情報をデータＤＩＩのプライベート領域に格納して、当該ＤＩＩの送信を複数回繰り返すことにより、前記複数のファイルをＤＤＢメッセージデータにて送信するまでの所定の猶予時間を確保すること、
を特徴とするデジタルデータ送信方法。 - 請求項２２のデジタルデータ送信方法において、
１のデータＤＩＩで管理する総モジュール数は２つであり、前記所定時間は３０秒間であること、
を特徴とするデジタルデータ送信方法。 - コンテンツデータを複数のモジュール化し、各モジュールをモジュール群毎にまとめて、当該モジュール群に属するモジュールに関する構成モジュール管理情報とともにデジタル放送する送信装置、
前記構成モジュール管理情報に基づいて、受信したモジュール化コンテンツデータをモジュール毎に１のファイルとして蓄積記憶する受信装置、
を備えたデジタルデータ送受信システムにおいて、
前記送信装置は、前記構成モジュール管理情報の送信を複数回繰り返すことにより、前記モジュール化されたコンテンツデータを送信するまでの所定の猶予時間を確保し、
前記受信装置は、前記構成モジュール管理情報を受信すると、前記モジュール化コンテンツデータをモジュール毎に１のファイルとして蓄積記憶させるためのファイル書き込み準備処理を、複数ファイルについてまとめて実行すること、
を特徴とするデジタルデータ送受信システム。 - モジュール化されたコンテンツデータを記憶しておき、各モジュールをモジュール群規則に基づいてモジュール群化して、モジュール群に属するモジュールに関する構成モジュール管理情報とともにデジタル放送するデジタルデータ送信装置において、
前記構成モジュール管理情報を所定時間経過するまで繰り返し送信した後、前記モジュール化されたコンテンツデータを送信すること、
を特徴とするデジタルデータ送信装置。 - 送信装置に、コンテンツデータを複数のモジュール化し、各モジュールをモジュール群毎にまとめて、当該モジュール群に属するモジュールに関する構成モジュール管理情報とともにデジタル放送させ、受信装置にて、前記構成モジュール管理情報に基づいて、受信したモジュール化コンテンツデータをモジュール毎に１のファイルとして蓄積記憶させるデジタルデータ送受信方法において、
前記送信装置は、前記構成モジュール管理情報を所定時間経過するまで繰り返し送信した後、前記モジュール化されたコンテンツデータを送信し、
前記受信装置は、前記構成モジュール管理情報を受信すると、前記モジュール化コンテンツデータをモジュール毎に１のファイルとして蓄積記憶させるためのファイル書き込み準備処理を、複数ファイルについてまとめて実行すること、
を特徴とするデジタルデータ送受信方法。 - 1) 設定された選別条件に基づいてモジュールデータを選別受信し各モジュールデータを出力する選別受信部および 2) ＣＰＵを有するデジタルデータ受信装置を、
ディレクトリ構造で管理された複数のファイルに分けて記憶されたコンテンツデータがデジタル放送されると、これを受信して前記ディレクトリ構造で管理された複数のファイルに分けて蓄積記憶するデジタルデータ受信装置であって、ファイル管理情報を受信すると、当該ファイル管理情報にて管理するファイルのディレクトリ構造の情報を、当該ファイル管理情報から読み出して、そのディレクトリ構造で示されるファイルのファイル書き込み準備処理を複数まとめて実行するデジタルデータ受信装置、として機能させるためのコンピュータ読み取り可能なプログラム。 - 請求項２１のプログラムを記録した記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002046818A JP4201074B2 (ja) | 2001-02-23 | 2002-02-22 | デジタルデータ送受信システムおよびその方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001-47856 | 2001-02-23 | ||
| JP2001047856 | 2001-02-23 | ||
| JP2002046818A JP4201074B2 (ja) | 2001-02-23 | 2002-02-22 | デジタルデータ送受信システムおよびその方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002358228A JP2002358228A (ja) | 2002-12-13 |
| JP4201074B2 true JP4201074B2 (ja) | 2008-12-24 |
Family
ID=26609962
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002046818A Expired - Fee Related JP4201074B2 (ja) | 2001-02-23 | 2002-02-22 | デジタルデータ送受信システムおよびその方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4201074B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4715701B2 (ja) * | 2006-09-28 | 2011-07-06 | 船井電機株式会社 | デジタル放送録画装置 |
| JP4884278B2 (ja) * | 2007-03-30 | 2012-02-29 | 日本テレビ放送網株式会社 | データ放送の送出確認システム、変換装置、送出確認装置、及びそのプログラム |
| JP2009049573A (ja) * | 2007-08-15 | 2009-03-05 | Sony Corp | 情報処理装置および方法、並びにプログラム |
| JP2012213138A (ja) * | 2011-03-18 | 2012-11-01 | Nippon Hoso Kyokai <Nhk> | 放送サービスの送信装置及びプログラム |
| KR102181776B1 (ko) * | 2012-06-05 | 2020-11-24 | 삼성전자주식회사 | 범용 디바이스에서의 파일 송/수신 장치 및 방법 |
| JP6543819B2 (ja) * | 2015-04-28 | 2019-07-17 | 日本放送協会 | 処理装置およびプログラム |
-
2002
- 2002-02-22 JP JP2002046818A patent/JP4201074B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002358228A (ja) | 2002-12-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6636953B2 (en) | Receiving apparatus that receives and accumulates broadcast contents and makes contents available according to user requests | |
| US9986198B2 (en) | Receiving device, receiving method, transmitting device, and transmitting method | |
| JP5307315B2 (ja) | 前に放送された内容を番組の録画に組み込むシステムおよび方法 | |
| JP4248183B2 (ja) | クッキー処理プログラムおよび画像データ表示装置 | |
| CN1244223C (zh) | 接收机设备和方法 | |
| JP3959583B2 (ja) | レコーディングシステム | |
| US6622004B1 (en) | Data transceiving system and method | |
| US20030115222A1 (en) | System and method for digital data communication | |
| EP2023514A2 (en) | Apparatus for providing information, information receiver and storage medium | |
| US20030097423A1 (en) | Preview system for data broadcast contents | |
| JPH1098508A (ja) | サイクリックパケットデータ伝送システムの受信機 | |
| US20030009472A1 (en) | Method related to structured metadata | |
| JP2006502611A (ja) | 双方向テレビジョンの受信方法並びに伝送方法及び関連する装置 | |
| US20030084180A1 (en) | Metadata receiving apparatus, receiving method, metadata receiving program, computer-readable recording medium recording therein metadata receiving program, metadata sending apparatus, and transmitting method | |
| WO2006090612A1 (ja) | データ管理システム、データ管理方法、サーバ装置、受信装置、制御プログラムおよびそれを記録したコンピュータ読み取り可能な記録媒体 | |
| US20080077681A1 (en) | Method and apparatus for upgrading software of digital broadcasting receiver | |
| JP4201074B2 (ja) | デジタルデータ送受信システムおよびその方法 | |
| KR100892311B1 (ko) | 디지털 방송 수신기의 소프트웨어 업그레이드 장치 및 방법 | |
| US20070008402A1 (en) | Apparatus and method for backing up broadcast files | |
| JP4243452B2 (ja) | クッキー処理プログラム、クッキー処理装置、クッキー処理方法およびコンテンツ融合方法 | |
| JP4884278B2 (ja) | データ放送の送出確認システム、変換装置、送出確認装置、及びそのプログラム | |
| WO2001095112A1 (fr) | Dispositif de reception/stockage, dispositif d'emission, systeme de diffusion, procede de reception/stockage, procede d'emission, procede de diffusion, programme et support | |
| US20030097435A1 (en) | System and method for statistically processing messages | |
| JP4783215B2 (ja) | 送信装置、受信装置、送信プログラム、及び受信プログラム | |
| US20090125483A1 (en) | File transmission system and file management method thereof |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050209 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080519 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080708 |
|
| 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: 20080908 |
|
| 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: 20080930 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4201074 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111017 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121017 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131017 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |