JP2007159148A - データ伝送方法及びデータ伝送装置 - Google Patents

Abstract

【課題】データ受信装置にモノメディアデータを伝送する。
【解決手段】モノメディアデータをＤＳＭ−ＣＣ方式に基づいてモジュールを生成し、生成したモジュールを固定長を有するブロックに分割し、ブロックに分割されたデータから、ＤＤＢメッセージを生成し、モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるＤＩＩメッセージを生成し、ＤＤＢメッセージ及びＤＩＩメッセージを、周期的且つ繰り返し送出するカルーセル方式を使って伝送する。
【選択図】 図３８

Description

本発明は、例えばデジタル衛星放送によるデータサービスなどの、情報の送信／受信／記録（ダウンロード）を行うシステムに関わり、特に情報の受信を行う情報受信装置にデータを伝送するデータ伝送方法及びデータ伝送装置に関するものである。

近年、デジタル衛星放送の普及が進んでいる。デジタル衛星放送は、例えば既存のアナログ放送と比較してノイズやフェージングに強く、高品質の信号を伝送することが可能である。また、周波数利用効率が向上され、多チャンネル化も図ることが可能になる。具体的には、デジタル衛星放送であれば１つの衛星で数百チャンネルを確保することも可能である。このようなデジタル衛星放送では、スポーツ、映画、音楽、ニュースなどの専門チャンネルが多数用意されており、これらの専門チャンネルでは、それぞれの専門のコンテンツに応じたプログラムが放送されている。

そして、上記のようなデジタル衛星放送システムを利用して、ユーザが楽曲等の音声データをダウンロードできるようにしたり、いわゆるテレビショッピングとして、例えばユーザが放送画面を見ながら何らかの商品についての購買契約を結べるようにしたりすることが提案されている。つまりは、デジタル衛星放送システムとして、通常の放送内容と並行したデータサービス放送を行うものである。

一例として、楽曲データのダウンロードであれば、放送側においては、放送番組と並行して、楽曲データを多重化して放送するようにする。また、この楽曲データのダウンロードに際しては、ＧＵＩ(Graphical User Interface)画面（即ちダウンロード用の操作画面である）を表示させることでインタラクティブな操作をユーザに行わせるようにされるが、このＧＵＩ画面出力のためのデータも多重化して放送するようにされる。
そして、受信装置を所有しているユーザ側では、所望のチャンネルを選局している状態で、受信装置に対する所定の操作によって楽曲データをダウンロードするためのＧＵＩ画面を表示出力させるようにする。そして、この表示された操作画面に対してユーザが操作を行うことで、例えば受信装置に接続したデジタルオーディオ機器に対してデータを供給し、これが録音されるようにするものである。

ところで、上記のような楽曲データをダウンロードするためのＧＵＩ画面としては、例えばＧＵＩ画面を形成するパーツ的な画像データ、テキストデータなどの情報に加え、更には所定操作に応じた音声出力のための音声データなどの単位データ（ファイル）をそれぞれオブジェクトとして扱い、このオブジェクトの出力態様を所定方式によるシナリオ記述によって規定することによって、上記操作画面についての所要の表示形態及び音声等の出力態様を実現するように構成することが考えられる。
なお、ここでは、上記ＧＵＩ画面のようにして、記述情報によって規定されることで、或る目的に従った機能を実現する表示画面（ここでは音声等の出力も含む）のことを「シーン」というものとする。また、「オブジェクト」とは、記述情報に基づいてその出力態様が規定される画像、音声、テキスト等の単位情報を示しており、伝送時においては、ここでは記述情報自体のデータファイルも「オブジェクト」の１つとして扱われるものとする。

上記シーン表示及びシーン表示上での音声出力等を実現するためのオブジェクトは、放送局側で放送すべきシーンを形成するデータのディレクトリ構造に対して適当にマッピングが施され、所定の伝送方式に従ってエンコードされて送信される。例えば、或る１番組において複数のシーンが必要な場合には、これら複数のシーンに必要されるオブジェクトのデータが適当にマッピングされたうえで送信されることになる。
受信装置側では伝送方式に従ってデコード処理を施して、例えば表示に必要なシーンに必要とされるオブジェクトごとの纏まりとしてのデータを得て、これをシーンとして出力するようにされる。

ところで受信装置で受信されたデータのダウンロードは、接続されたストレージデバイス側で行われることになるが、例えばそのダウンロード動作に要する時間は、データ量（例えば楽曲の長さ）などに応じて異なるものとなる。
一方ユーザーとしては、ダウンロードが行われている際には、現在そのダウンロード動作がどれほど進捗しているかを知りたいという要望があるが、各楽曲等によりダウンロードに要する時間が異なるため、おおよその進捗状況の判断もしにくい状況である。
またダウンロード動作においては圧縮データ（後述するＡＴＲＡＣデータなど）を直接ストレージデバイスに供給させることで、短時間でダウンロードを完了させることも提案されている。このような高速ダウンロードの場合は、例えば楽曲データのダウンロードは、その楽曲の通常の演奏時間よりも短い時間（例えば１／４程度の時間）で完了できるため、ユーザーにとっては一層進捗状況が把握しにくいものとなる。

本発明は、データ受信装置にモノメディアデータを伝送する伝送方法において、上記モノメディアデータをＤＳＭ−ＣＣ方式に基づいてモジュールを生成し、上記モジュールを固定長を有するブロックに分割し、上記ブロックに分割されたデータから、ＤＤＢメッセージを生成し、上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるＤＩＩメッセージを生成し、上記ＤＤＢメッセージ及びＤＩＩメッセージを、周期的且つ繰り返し送出するカルーセル方式を使って伝送する。

以上説明したように本発明では、ダウンロード動作中に情報受信装置は、逐次ストレージデバイス側に記録データの進行位置情報（例えば曲の先頭をゼロとした時間位置情報）を知らせるように要求し、それに応じて送られてきた進行位置情報から、実際の記録動作の進捗状況を把握し、それに応じて進捗情報データを生成して表示に供するようにする。
これによってユーザーに対してダウンロード記録動作の進捗状況を適切に知らせることができる。

また進行位置情報の要求は所定時間毎に行なうこと、及び進行位置情報が取り込まれる毎に、進捗情報データを更新生成し、表示用データとして出力することで、ダウンロード実行中に適切に進捗状況を更新させながら表示できる。特に所定時間という要求動作間隔を短くすれば、進捗状況の表示がよりスムースに変化するものとなり、ユーザーに対してよりわかりやすい表示を行うことができる。
さらに、進捗情報データは、記録データの総量情報に対する進行位置情報のパーセンテージを示すデータとされ、表示上では進捗状況をパーセンテージで示すことで、ユーザーが一目で進捗状況を把握できるような表示が可能となる。

以降、本発明の実施の形態について説明する。
本発明が適用されるシステムとしては、デジタル衛星放送を利用して番組を放送すると共に、受信装置側ではこの番組に関連した楽曲データ（音声データ）等の情報を受信し、番組及び関連した楽曲データを出力できるとともに、その楽曲データを接続したストレージ機器にダウンロードさせることができるようにしたシステムを例に挙げることとする。
そしてこのようなシステムにおける受信装置（後述するＩＲＤ）が本発明の実施の形態となる。またストレージ機器としてはＭＤ（ミニディスク）レコーダを例にあげる。
説明は次の順序で行う。
１．デジタル衛星放送システム
１−１．全体構成
１−２．ＧＵＩ画面に対する操作
１−３．地上局
１−４．送信フォーマット
１−５．ＡＴＲＡＣデータの送信フォーマット
１−６．ＩＲＤ
１−７．ＭＤレコーダ
１−８．ＭＤのエリア構成
２．ダウンロード
２−１．機器接続構成
２−２．機器接続に関する処理
２−３．ダウンロード動作概要
２−４．ダウンロード設定処理
２−５．ダウンロード実行前のチェック処理
２−６．ダウンロードセットアップ
２−７．ＡＴＲＡＣダウンロード
２−８．管理／付加情報のダウンロード及び終了処理
２−９．エラー発生時の処理

１．デジタル衛星放送システムの構成
１−１．全体構成
図１は、本例としてのデジタル衛星放送システムの全体構成を示すものである。この図に示すように、デジタル衛星放送の地上局１には、テレビ番組素材サーバ６からのテレビ番組放送のための素材と、楽曲素材サーバ７からの楽曲データの素材と、音声付加情報サーバ８からの音声付加情報と、ＧＵＩデータサーバからのＧＵＩデータとが送られる。

テレビ番組素材サーバ６は、通常の放送番組の素材を提供するサーバである。このテレビ番組素材サーバから送られてくる音楽放送の素材は、動画及び音声とされる。例えば、音楽放送番組であれば、上記テレビ番組素材サーバ６の動画及び音声の素材を利用して、例えば新曲のプロモーション用の動画及び音声が放送されたりすることになる。

楽曲素材サーバ７は、オーディオチャンネルを使用して、オーディオ番組を提供するサーバである。このオーディオ番組の素材は音声のみとなる。この楽曲素材サーバ７は、複数のオーディオチャンネルのオーディオ番組の素材を地上局１に伝送する。
各オーディオチャンネルの番組放送ではそれぞれ同一の楽曲が所定の単位時間繰り返して放送される。各オーディオチャンネルは、それぞれ、独立しており、その利用方法としては各種考えられる。例えば、１つのオーディオチャンネルでは最新の日本のポップスの数曲を或る一定時間繰り返し放送し、他のオーディオチャンネルでは最新の外国のポップスの数曲を或る一定時間繰り返し放送するというようにされる。

音声付加情報サーバ８は、楽曲素材サーバ７から出力される楽曲の時間情報等を提供するサーバである。

ＧＵＩデータサーバ９は、ユーザが操作に用いるＧＵＩ画面を形成するための「ＧＵＩデータ」を提供する。例えば後述するような楽曲のダウンロードに関するＧＵＩ画面であれば、配信される楽曲のリストページや各楽曲の情報ページを形成するための画像データ、テキストデータ、アルバムジャケットの静止画を形成するためのデータなどを提供する。更には、受信設備３側にていわゆるＥＰＧ(Electrical Program Guide)といわれる番組表表示を行うのに利用されるＥＰＧデータもここから提供される。
なお、「ＧＵＩデータ」としては、例えばＭＨＥＧ(Multimedia Hypermedia Information Coding Experts Group)方式が採用される。ＭＨＥＧとは、マルチメディア情報、手順、操作などのそれぞれと、その組み合わせをオブジェクトとして捉え、それらのオブジェクトを符号化したうえで、タイトル（例えばＧＵＩ画面）として制作するためのシナリオ記述の国際標準とされる。また、本例ではＭＨＥＧ−５を採用するものとする。

地上局１は上記テレビ番組素材サーバ６、楽曲素材サーバ７、音声付加情報サーバ８、及びＧＵＩデータサーバ９から伝送された情報を多重化して送信する。
本例では、テレビ番組素材サーバ６から伝送されたビデオデータはＭＰＥＧ(Moving Picture Experts Group)２方式により圧縮符号化され、オーディオデータはＭＰＥＧ２オーディオ方式により圧縮符号化される。また、楽曲素材サーバ７から伝送されたオーディオデータは、オーディオチャンネルごとに対応して、例えばＭＰＥＧ２オーディオ方式と、ＡＴＲＡＣ(Adoptive Tranform Acoustic Coding)方式と何れか一方の方式により圧縮符号化される。
また、これらのデータは多重化の際、キー情報サーバ１０からのキー情報を利用して暗号化される。
なお、地上局１の内部構成例については後述する。

地上局１からの信号は衛星２を介して各家庭の受信設備３で受信される。衛星２には複数のトランスポンダが搭載されている。１つのトランスポンダは例えば３０Ｍｂｐｓの伝送能力を有している。各家庭の受信設備３としては、パラボラアンテナ１１とＩＲＤ(Integrated Receiver Decorder)１２と、ストレージデバイス１３と、モニタ装置１４とが用意される。
また、この場合には、ＩＲＤ１２に対して操作を行うためのリモートコントローラ６４が示されている。

パラボラアンテナ１１で衛星２を介して放送されてきた信号が受信される。この受信信号がパラボラアンテナ１１に取り付けられたＬＮＢ(Low Noize Block Down Converter)１５で所定の周波数に変換され、ＩＲＤ１２に供給される。

ＩＲＤ１２における概略的な動作としては、受信信号から所定のチャンネルの信号を選局し、その選局された信号から番組としてのビデオデータ及びオーディオデータの復調を行ってビデオ信号、オーディオ信号として出力する。また、ＩＲＤ１２では、番組としてのデータと共に多重化されて送信されてくる、ＧＵＩデータに基づいてＧＵＩ画面としての出力も行う。このようなＩＲＤ１２の出力は、例えばモニタ装置１４に対して供給される。これにより、モニタ装置１４では、ＩＲＤ１２により受信選局した番組の画像表示及び音声出力が行われ、また、後述するようなユーザの操作に従ってＧＵＩ画面を表示させることが可能となる。

ストレージデバイス１３は、ＩＲＤ１２によりダウンロードされたオーディオデータ（楽曲データ）を保存するためのものである。このストレージデバイス１３の種類としては特に限定されるものではなく、ＭＤ(Mini Disc)レコーダ／プレーヤ（以下ＭＤレコーダ）、ＤＡＴレコーダ／プレーヤ、ＤＶＤレコーダ／プレーヤ等を用いることができる。また、ストレージデバイス１３としてパーソナルコンピュータ装置を用い、ハードディスクのほか、ＣＤ−Ｒ等をはじめとする記録が可能なメディアにオーディオデータを保存するようにすることも可能とされる。
但し本例においては、後述するダウンロード動作に関しては、ＩＲＤ１２はストレージデバイス１３として接続されている機器のうちＭＤレコーダにダウンロードを実行させるものとして説明する。

また、本例の受信設備３としては、図２に示すように、データ伝送規格としてＩＥＥＥ１３９４に対応したデータインターフェイスを備えたＭＤレコーダ１３Ａを、図１に示すストレージデバイス１３として使用することができるようになっている。
この図に示すＩＥＥＥ１３９４対応のＭＤレコーダ１３Ａは、ＩＥＥＥ１３９４バス１６によりＩＲＤ１２と接続される。これによって、本例では、ＩＲＤ１２にて受信された、楽曲としてのオーディオデータ（ダウンロードデータ）を、ＡＴＲＡＣ方式により圧縮処理が施されたままの状態で直接取り込んで記録することができる。また、ＭＤレコーダ１３ＡとＩＲＤ１２とをＩＥＥＥ１３９４バス１６により接続した場合には、上記オーディオデータの他、そのアルバムのジャケットデータ（静止画データ）及び歌詞などのテキストデータを記録することも可能とされている。

ＩＲＤ１２は、例えば電話回線４を介して課金サーバ５と通信可能とされている。ＩＲＤ１２には、後述するようにして各種情報が記憶されるＩＣカードが挿入される。例えば楽曲のオーディオデータのダウンロードが行われたとすると、これに関する履歴情報がＩＣカードに記憶される。このＩＣカードの情報は、電話回線４を介して所定の機会、タイミングで課金サーバ５に送られる。課金サーバ５は、この送られてきた履歴情報に従って金額を設定して課金を行い、ユーザに請求する。

これまでの説明から分かるように、本発明が適用されたシステムでは、地上局１は、テレビ番組素材サーバ６からの音楽番組放送の素材となるビデオデータ及びオーディオデータと、楽曲素材サーバ７からのオーディオチャンネルの素材となるオーディオデータと、音声付加情報サーバ８からの音声データと、ＧＵＩデータサーバ９からのＧＵＩデータとを多重化して送信している。
そして、各家庭の受信設備３でこの放送を受信すると、例えばモニタ装置１４により、選局したチャンネルの番組を視聴することができる。また、番組のデータと共に送信されるＧＵＩデータを利用したＧＵＩ画面として、第１にはＥＰＧ（Electrical Program Guide；電子番組ガイド）画面を表示させ、番組の検索等を行うことができる。また、第２には、例えば通常の番組放送以外の特定のサービス用のＧＵＩ画面を利用して所要の操作を行うことで、本例の場合には、放送システムにおいて提供されている通常番組の視聴以外のサービスを享受することができる。
例えば、オーディオ（楽曲）データのダウンロードサービス用のＧＵＩ画面を表示させて、このＧＵＩ画面を利用して操作を行えば、ユーザが希望した楽曲のオーディオデータをダウンロードしてストレージデバイス１３に記録して保存することが可能になる。

なお、本例では、上記したようなＧＵＩ画面に対する操作を伴う、通常の番組放送以外の特定のサービスを提供するデータサービス放送については、インタラクティブ性を有することもあり、「インタラクティブ放送」ともいうことにする。

１−２．ＧＵＩ画面に対する操作
ここで、上述しているインタラクティブ放送の利用例、つまり、ＧＵＩ画面に対する操作例について、図３及び図４を参照して概略的に説明しておく。ここでは、楽曲データ（オーディオデータ）のダウンロードを行う場合について述べる。

先ず、図３によりＩＲＤ１２に対してユーザが操作を行うためのリモートコントローラ６４の操作キーについて、特に主要なものについて説明しておく。
図３には、リモートコントローラ６４において各種キーが配列された操作パネル面が示されている。ここでは、これら各種キーのうち、電源キー２０１、数字キー２０２、画面表示切換キー２０３、インタラクティブ切換キー２０４、ＥＰＧキーパネル部２０５、チャンネルキー２０６について説明する。

電源キー２０１は、ＩＲＤ１２の電源のオン／オフを行うためのキーである。数字キー２０２は、数字指定によりチャンネル切り換えを行ったり、例えばＧＵＩ画面において数値入力操作が必要な場合に操作するためのキーである。
画面表示切換キー２０３は、例えば通常の放送画面とＥＰＧ画面との切り換えを行うキーである。例えば、画面表示切換キー２０３によりＥＰＧ画面を呼び出した状態の下で、ＥＰＧキーパネル部２０５に配置されたキーを操作すれば、電子番組ガイドの表示画面を利用した番組検索が行えることになる。また、ＥＰＧキーパネル部２０５内の矢印キー２０５ａは、後述するサービス用のＧＵＩ画面におけるカーソル移動などにも使用することができる。
インタラクティブ切換キー２０４は、通常の放送画面と、その放送番組に付随したサービスのためのＧＵＩ画面との切り換えを行うために設けられる。
チャンネルキー２０６は、ＩＲＤ１２における選局チャンネルをそのチャンネル番号の昇順、降順に従って順次切り換えていくために設けられるキーである。

なお、本例のリモートコントローラ６４としては、例えばモニタ装置１４に対する各種操作も可能に構成されているものとされ、これに対応した各種キーも設けられているものであるが、ここでは、モニタ装置１４に対応するキー等の説明は省略する。

次に、図４を参照してＧＵＩ画面に対する操作の具体例について説明する。
受信設備３により放送を受信して所望のチャンネルを選局すると、モニタ装置１４の表示画面には、図４（ａ）に示すように、テレビ番組素材サーバ６から提供された番組素材に基づく動画像が表示される。つまり、通常の番組内容が表示される。ここでは、例えば音楽番組が表示されているものとする。また、この音楽番組には楽曲のオーディオデータのダウンロードサービス（インタラクティブ放送）が付随されているものとする。
そして、この音楽番組が表示されている状態の下で、例えばユーザがリモートコントローラ６４のインタラクティブ切換キー２０４を操作したとすると、表示画面は図４（ｂ）に示すような、オーディオデータのダウンロードのためのＧＵＩ画面に切り替わる。

このＧＵＩ画面においては、先ず、画面の左上部のテレビ番組表示エリア２１Ａに対して、図４（ａ）にて表示されていたテレビ番組素材サーバ６からのビデオデータによる画像が縮小化されて表示される。
また、画面の右上部には、オーディオチャンネルで放送されている各チャンネルの楽曲のリスト２１Ｂが表示される。また、画面の左下にはテキスト表示エリア２１Ｃとジャケット表示エリア２１Ｄが表示される。さらに、画面の右側には歌詞表示ボタン２２、プロフィール表示ボタン２３、情報表示ボタン２４、予約録音ボタン２５、予約済一覧表示ボタン２６、録音履歴表示ボタン２７、およびダウンロードボタン２８が表示される。

ユーザは、このリスト２１Ｂに表示されている楽曲名を見ながら、興味のある楽曲を探していく。そして、興味のある楽曲を見つけたらリモートコントローラ６４の矢印キー２０５ａ（ＥＰＧキーパネル部２０５内）を操作して、その楽曲が表示されている位置にカーソルを合わせた後、エンター操作を行う（例えば矢印キー２０５ａのセンター位置を押圧操作する）。
これによって、カーソルを合わせた楽曲を試聴することができる。すなわち、各オーディオチャンネルでは、所定の単位時間中、同一の楽曲が繰り返し放送されているので、テレビ番組表示エリア２１Ａの画面はそのままで、ＩＲＤ１２により上記操作により選択された楽曲のオーディオチャンネルに切り換えて音声出力することで、その楽曲を聞くことができる。この時、ジャケット表示エリア２１Ｄにはその楽曲のＭＤジャケットの静止画像が表示される

また、例えば上記の状態で歌詞表示ボタン２２にカーソルを合わせ、エンター操作を行う（以下、ボタン表示にカーソルを合わせ、エンター操作を行うことを「ボタンを押す」という）と、テキスト表示エリア２１Ｃに楽曲の歌詞がオーディオデータと同期したタイミングで表示される。同様に、プロフィール表示ボタン２３あるいは情報表示ボタン２４を押すと、楽曲に対応するアーティストのプロフィールあるいはコンサート情報などがテキスト表示エリア２１Ｃに表示される。このように、ユーザは、現在どのような楽曲が配信されているのかを知ることができ、更に各楽曲についての詳細な情報を知ることができる。

ユーザは試聴した楽曲を購入したい場合には、ダウンロードボタン２８を押す。ダウンロードボタン２８が押されると、選択された楽曲のオーディオデータがダウンロードされ、ストレージデバイス１３に記憶される。楽曲のオーディオデータと共に、その歌詞データ、アーティストのプロフィール情報、ジャケットの静止画データ等をダウンロードすることもできる。
そして、このようにして楽曲のオーディオデータがダウンロードされる毎に、その履歴情報がＩＲＤ１２内のＩＣカードに記憶される。ＩＣカードに記憶された情報は、例えば１カ月に一度ずつ課金サーバ５により取り込みが行われ、ユーザに対してデータサービスの使用履歴に応じた課金が行われる。これによって、適切な楽曲データの販売及びダウンロードされる楽曲の著作権を保護することができることにもなる。

また、ユーザは予めダウンロードの予約を行いたい場合には、予約録音ボタン２５を押す。このボタンを押すと、ＧＵＩ画面の表示が切り換わり、予約が可能な楽曲のリストが画面全体に表示される。例えばこのリストは１時間単位、１週間単位、チャンル単位等で検索した楽曲を表示することが可能である。ユーザはこのリストの中からダウンロードの予約を行いたい楽曲を選択すると、その情報がＩＲＤ１２内に登録される。そして、すでにダウンロードの予約を行った楽曲を碓認したい場合には、予約済一覧表示ボタン２６を押すことにより、画面全体に表示させることができる。このようにして予約された楽曲は、予約時刻になるとＩＲＤ１２によりダウンロードされ、ストレージデバイス１３に記憶される。

ユーザはダウンロードを行った楽曲について確認したい場合には、録音履歴ボタン２７を押すことにより、既にダウンロードを行った楽曲のリストを画面全体に表示させることができる。

このように、本発明が適用されたシステムの受信設備３では、モニタ装置１４のＧＵＩ画面上に楽曲のリストが表示される。そして、このＧＵＩ画面上の表示にしたがって楽曲を選択するとその楽曲を試聴することができ、その楽曲の歌詞やアーティストのプロフィール等を知ることができる。さらに、楽曲のダウンロードとその予約、ダウンロードの履歴や予約済楽曲リストの表示等を行うことができる。

詳しいことは後述するが、上記図４（ｂ）に示すようなＧＵＩ画面の表示と、ＧＵＩ画面に対するユーザの操作に応答したＧＵＩ画面上での表示変更、及び音声出力は、前述したＭＨＥＧ方式に基づいたシナリオ記述により、オブジェクトの関係を規定することにより実現される。ここでいうオブジェクトとは、図４（ｂ）に示された各ボタンに対応するパーツとしての画像データや各表示エリアに表示される素材データとなる。
そして、本明細書においては、このＧＵＩ画面のような、シナリオ記述によってオブジェクト間の関係が規定されることで、或る目的に従った情報の出力態様（画像表示や音声出力等）が実現される環境を「シーン」というものとする。また、１シーンを形成するオブジェクトとしては、シナリオ記述のファイル自体も含まれるものとする。

以上のように、本例のデジタル衛星放送システムでは放送番組が配信されると共に、複数のオーディオチャンネルを使用して楽曲のオーディオデータが配信される。そして、配信されている楽曲のリスト等を使用して所望の楽曲を探し、そのオーディオデータをストレージデバイス１３に簡単に保存することができる。
なお、デジタル衛星放送システムにおける番組提供以外のサービスとしては、上記した楽曲データのダウンロードの他にも各種考えられる。例えば、いわゆるテレビショッピングといわれる商品紹介番組を放送した上で、ＧＵＩ画面としては購買契約が結べるようなものを用意することも考えられる。

１−３．地上局
これまで、本例としてのデジタル衛星放送システムの概要について説明したが、以降、このシステムについてより詳しい説明を行っていくこととする。そこで、先ず地上局１の構成について図５を参照して説明する。

なお、以降の説明にあたっては、次のことを前提とする。
本例では、地上局１から衛星２を介しての受信設備３への送信を行うのにあたり、ＤＳＭ−ＣＣ(デジタル蓄積メディア・コマンド・アンド・コントロール；Digital Strage Media-Command and Control)プロトコルを採用する。
ＤＳＭ−ＣＣ（ＭＰＥＧ−ｐａｒｔ６）方式は、既に知られているように、例えば、何らかのネットワークを介して、デジタル蓄積メディア（ＤＳＭ）に蓄積されたＭＰＥＧ符号化ビットストリームを取り出したり(Retrieve)、或いはＤＳＭに対してストリームを蓄積(Store)するためのコマンドや制御方式を規定したものである。そして本例においては、このＤＳＭ−ＣＣ方式がデジタル衛星放送システムにおける伝送規格として採用されているものである。
そして、ＤＳＭ−ＣＣ方式によりデータ放送サービス（例えばＧＵＩ画面など）のコンテンツ（オブジェクトの集合）を伝送するためには、コンテンツの記述形式を定義しておく必要がある。本例では、この記述形式の定義として先に述べたＭＨＥＧが採用されるものである。

図５に示す地上局１の構成において、テレビ番組素材登録システム３１は、テレビ番組素材サーバ６から得られた素材データをＡＶサーバ３５に登録する。この素材データはテレビ番組送出システム３９に送られ、ここでビデオデータは例えばＭＰＥＧ２方式で圧縮され、オーディオデータは、例えばＭＰＥＧ２オーディオ方式によりパケット化される。テレビ番組送出システム３９の出力はマルチプレクサ４５に送られる。

また、楽曲素材登録システム３２では、楽曲素材サーバ７からの素材データ、つまりオーディオデータを、ＭＰＥＧ２オーディオエンコーダ３６Ａ、及びＡＴＲＡＣエンコーダ３６Ｂに供給する。ＭＰＥＧ２オーディオエンコーダ３６Ａ、ＡＴＲＡＣエンコーダ３６Ｂでは、それぞれ供給されたオーディオデータについてエンコード処理（圧縮符号化）を行った後、ＭＰＥＧオーディオサーバ４０Ａ及びＡＴＲＡＣオーディオサーバ４０Ｂに登録させる。
ＭＰＥＧオーディオサーバ４０Ａに登録されたＭＰＥＧオーディオデータは、ＭＰＥＧオーディオ送出システム４３Ａに伝送されてここでパケット化された後、マルチプレクサ４５に伝送される。ＡＴＲＡＣオーディオサーバ４０Ｂに登録されたＡＴＲＡＣデータは、ＡＴＲＡＣオーディオ送出システム４３Ｂに４倍速ＡＴＲＡＣデータとして送られ、ここでパケット化されてマルチプレクサ４５に送出される。

また、音声付加情報登録システム３３では、音声付加情報サーバ８からの素材データである音声付加情報を音声付加情報データベース３７に登録する。この音声付加情報データベース３７に登録された音声付加情報は、音声付加情報送出システム４１に伝送され、同様にして、ここでパケット化されてマルチプレクサ４５に伝送される。

また、ＧＵＩ用素材登録システム３４では、ＧＵＩデータサーバ９からの素材データであるＧＵＩデータを、ＧＵＩ素材データベース３８に登録する。

ＧＵＩ素材データベース３８に登録されたＧＵＩ素材データは、ＧＵＩオーサリングシステム４２に伝送され、ここで、ＧＵＩ画面、即ち図４にて述べた「シーン」としての出力が可能なデータ形式となるように処理が施される。

つまり、ＧＵＩオーサリングシステム４２に伝送されてくるデータとしては、例えば、楽曲のダウンロードのためのＧＵＩ画面であれば、アルバムジャケットの静止画像データ、歌詞などのテキストデータ、更には、操作に応じて出力されるべき音声データなどである。
上記した各データはいわゆるモノメディアといわれるが、ＧＵＩオーサリングシステム４２では、ＭＨＥＧオーサリングツールを用いて、これらのモノメディアデータを符号化して、これをオブジェクトとして扱うようにする。
そして、例えば図４（ｂ）にて説明したようなシーン（ＧＵＩ画面）の表示態様と操作に応じた画像音声の出力態様が得られるように上記オブジェクトの関係を規定したシナリオ記述ファイル（スクリプト）と共にＭＨＥＧ−５のコンテンツを作成する。
また、図４（ｂ）に示したようなＧＵＩ画面では、テレビ番組素材サーバ６の素材データを基とする画像・音声データ（ＭＰＥＧビデオデータ、ＭＰＥＧオーディオデータ）と、楽曲素材サーバ７の楽曲素材データを基とするＭＰＥＧオーディオデータ等も、ＧＵＩ画面に表示され、操作に応じた出力態様が与えられる。
従って、上記シナリオ記述ファイルとしては、上記ＧＵＩオーサリングシステム４２では、上記したテレビ番組素材サーバ６の素材データを基とする画像・音声データ、楽曲素材サーバ７の楽曲素材データを基とするＭＰＥＧオーディオデータ、更には、音声付加情報サーバ８を基とする音声付加情報も必要に応じてオブジェクトとして扱われて、ＭＨＥＧのスクリプトによる規定が行われる。

なお、ＧＵＩオーサリングシステム４２から伝送されるＭＨＥＧコンテンツのデータとしては、スクリプトファイル、及びオブジェクトとしての各種静止画データファイルやテキストデータファイルなどとなるが、静止画データは、例えばＪＰＥＧ(Joint Photograph Experts Group)方式で圧縮された６４０×４８０ピクセルのデータとされ、テキストデータは例えば８００文字以内のファイルとされる。

ＧＵＩオーサリングシステム４２にて得られたＭＨＥＧコンテンツのデータはＤＳＭ−ＣＣエンコーダ４４に伝送される。
ＤＳＭ−ＣＣエンコーダ４４では、ＭＰＥＧ２フォーマットに従ったビデオ、オーディオデータのデータストリームに多重できる形式のトランスポートストリーム（以下ＴＳ(Transport Stream)とも略す）に変換して、パケット化されてマルチプレクサ４５に出力される。

マルチプレクサ４５においては、テレビ番組送出システム３９からのビデオパケットおよびオーディオパケットと、ＭＰＥＧオーディオ送出システム４３Ａからのオーディオパケットと、ＡＴＲＡＣオーディオ送出システム４３Ｂからの４倍速オーディオパケットと、音声付加情報送出システム４１からの音声付加情報パケットと、ＧＵＩオーサリングシステム４２からのＧＵＩデータパケットとが時間軸多重化されると共に、キー情報サーバ１０（図１）から出力されたキー情報に基づいて暗号化される。

マルチプレクサ４５の出力は電波送出システム４６に伝送され、ここで例えば誤り訂正符号の付加、変調、及び周波数変換などの処理を施された後、アンテナから衛星２に向けて送信出力するようにされる。

１−４．送信フォーマット
次に、ＤＳＭ−ＣＣ方式に基づいて規定された本例の送信フォーマットについて説明する。
図６は、地上局１から衛星２に送信出力される際のデータの一例を示している。なお、前述したように、この図に示す各データは実際には時間軸多重化されているものである。また、この図では、図６に示すように、時刻ｔ１から時刻ｔ２の間が１つのイベントとされ、時刻ｔ２から次のイベントとされる。ここでいうイベントとは、例えば音楽番組のチャンネルであれば、複数楽曲のラインナップの組を変更する単位であり、時間的には３０分或いは１時間程度となる。

図６に示すように、時刻ｔ１から時刻ｔ２のイベントでは、通常の動画の番組放送で、所定の内容Ａ１を有する番組が放送されている。また、時刻ｔ２から始めるイベントでは、内容Ａ２としての番組が放送されている。この通常の番組で放送されているのは動画と音声である。

ＭＰＥＧオーディオチャンネル（１）〜（１０）は、例えば、チャンネルＣＨ１からＣＨ１０の１０チャンネル分用意される。このとき、各オーディオチャンネルＣＨ１，ＣＨ２，ＣＨ３・・・・ＣＨ１０では、１つのイベントが放送されている間は同一楽曲が繰り返し送信される。つまり、時刻ｔ１〜ｔ２のイベントの期間においては、オーディオチャンネルＣＨ１では楽曲Ｂ１が繰り返し送信され、オーディオチャンネルＣＨ２では楽曲Ｃ１が繰り返し送信され、以下同様に、オーディオチャンネルＣＨ１０では楽曲Ｋ１が繰り返し送信されることになる。これは、その下に示されている４倍速ＡＴＲＡＣオーディオチャンネル（１）〜（１０）についても共通である。

つまり、図６において、ＭＰＥＧオーディオチャンネルと４倍速ＡＴＲＡＣオーディオチャンネルのチャンネル番号である（ ）内の数字が同じものは同じ楽曲となる。また、音声付加情報のチャンネル番号である（ ）内の数字は、同じチャンネル番号を有するオーディオデータに付加されている音声付加情報である。更に、ＧＵＩデータとして伝送される静止画データやテキストデータも各チャンネルごとに形成されるものである。これらのデータは、図７（ａ）〜（ｄ）に示すようにＭＰＥＧ２のトランスポートパケット内で時分割多重されて送信され、図７（ｅ）〜（ｈ）に示すようにしてＩＲＤ１２内では各データパケットのヘッダ情報を用いて再構築される。

また、上記図６及び図７に示した送信データのうち、少なくとも、データサービス（インタラクティブ放送）に利用されるＧＵＩデータは、ＤＳＭ−ＣＣ方式に則って論理的には次のようにして形成されるものである。ここでは、ＤＳＭ−ＣＣエンコーダ４４から出力されるトランスポートストリームのデータに限定して説明する。

図８（ａ）に示すように、ＤＳＭ−ＣＣ方式によって伝送される本例のデータ放送サービスは、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙという名称のルートディレクトリの中に全て含まれる。Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙに含まれるオブジェクトとしては、ディレクトリ（Ｄｉｒｅｃｔｏｒｙ），ファイル（Ｆｉｌｅ），ストリーム（Ｓｔｒｅａｍ），ストリームイベント（Ｓｔｒｅａｍ Ｅｖｅｎｔ）などの種類が存在する。

これらのうち、ファイルは静止画像、音声、テキスト、更にはＭＨＥＧにより記述されたスクリプトなどの個々のデータファイルとされる。
ストリームは例えば、他のデータサービスやＡＶストリーム（ＴＶ番組素材としてのＭＰＥＧビデオデータ、オーディオデータ、楽曲素材としてのＭＰＥＧオーディオデータ、ＡＴＲＡＣオーディオデータ等）にリンクする情報が含まれる。
また、ストリームイベントは、同じくリンクの情報と時刻情報が含まれる。
ディレクトリは相互に関連するデータをまとめるフォルダである。

そして、ＤＳＭ−ＣＣ方式では、図８（ｂ）に示すようにして、これらの単位情報とＳｅｒｖｉｃｅ Ｇａｔｅｗａｙをそれぞれオブジェクトという単位と捉え、それぞれをＢＩＯＰメッセージという形式に変換する。
なお、本発明に関わる説明では、ファイル，ストリーム，ストリームイベントの３つのオブジェクトの区別は本質的なものではないので、以下の説明ではこれらをファイルとしてのオブジェクトに代表させて説明する。

そして、ＤＳＭ−ＣＣ方式では、図８（ｃ）に示すモジュールといわれるデータ単位を生成する。このモジュールは、図８（ｂ）に示したＢＩＯＰメッセージ化されたオブジェクトを１つ以上含むようにされたうえで、ＢＩＯＰヘッダが付加されて形成される可変長のデータ単位であり、後述する受信側における受信データのバッファリング単位となる。
また、ＤＳＭ−ＣＣ方式としては、１モジュールを複数のオブジェクトにより形成する場合の、オブジェクト間の関係については特に規定、制限はされていない。つまり、極端なことをいえば、全く関係の無いシーン間における２以上のオブジェクトにより１モジュールを形成したとしても、ＤＳＭ−ＣＣ方式のもとでの規定に何ら違反するものではない。

このモジュールは、ＭＰＥＧ２フォーマットにより規定されるセクションといわれる形式で伝送するために、図８（ｄ）に示すように、機械的に「ブロック」といわれる原則固定長のデータ単位に分割される。但し、モジュールにおける最後のブロックについては規定の固定長である必要はないものとされている。このように、ブロック分割を行うのはＭＰＥＧ２フォーマットにおいて、１セクションが４ＫＢを越えてはならないという規定があることに起因する。
また、この場合には上記ブロックとしてのデータ単位と、セクションとは同義なものとなる。

このようにしてモジュールを分割して得たブロックは、図８（ｅ）に示すようにしてヘッダが付加されてＤＤＢ(Download Data Block)というメッセージの形式に変換される。

また、上記ＤＤＢへの変換と並行して、ＤＳＩ(Download Server Initiate)及びＤＩＩ(Download Indication Information)という制御メッセージが生成される。
上記ＤＳＩ及びＤＩＩは、受信側（ＩＲＤ１２）で受信データからモジュールを取得する際に必要となる情報であり、ＤＳＩは主として、次に説明するカルーセル（モジュール）の識別子、カルーセル全体に関連する情報（カルーセルが１回転する時間、カルーセル回転のタイムアウト値）等の情報を有する。また、データサービスのルートディレクトリ（Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ）の所在を知るための情報も有する（オブジェクトカルーセル方式の場合）。

ＤＩＩは、カルーセルに含まれるモジュールごとに対応する情報であり、モジュールごとのサイズ、バージョン、そのモジュールのタイムアウト値などの情報を有する。

そして、図８（ｆ）に示すように、上記ＤＤＢ、ＤＳＩ、ＤＩＩの３種類のメッセージをセクションのデータ単位に対応させて周期的に、かつ、繰り返し送出するようにされる。これにより、受信機側では例えば目的のＧＵＩ画面（シーン）を得るのに必要なオブジェクトが含まれているモジュールをいつでも受信できるようにされる。
本明細書では、このような伝送方式を回転木馬に例えて「カルーセル方式」といい、図８（ｆ）に示すようにして模式的に表されるデータ伝送形態をカルーセルというものとする。
また、「カルーセル方式」としては、「データカルーセル方式」のレベルと「オブジェクトカルーセル方式」のレベルとに分けられる。特にオブジェクトカルーセル方式では、ファイル、ディレクトリ、ストリーム、サービスゲートウェイなどの属性を持つオブジェクトをデータとしてカルーセルを用いて転送する方式で、ディレクトリ構造を扱えることがデータカルーセル方式と大きく異なる。本例のシステムでは、オブジェクトカルーセル方式を採用するものとされる。

また、上記のようにしてカルーセルにより送信されるＧＵＩデータ、つまり、図５のＤＳＭ−ＣＣエンコーダ４４から出力されるデータとしては、トランスポートストリームの形態により出力される。このトランスポートストリームは例えば図９に示す構造を有する。
図９（ａ）には、トランスポートストリームが示されている。このトランスポートストリームとはＭＰＥＧシステムで定義されているビット列であり、図のように１８８バイトの固定長パケット（トランスポートパケット）の連結により形成される。

そして、各トランスポートパケットは、図９（ｂ）に示すようにヘッダと特定の個別パケットに付加情報を含めるためのアダプテーションフィールドとパケットの内容（ビデオ／オーディオデータ等）を表すペイロード（データ領域）とからなる。

ヘッダは、例えば実際には４バイトとされ、図９（ｃ）に示すように、先頭には必ず同期バイトがあるようにされ、これより後ろの所定位置にそのパケットの識別情報であるＰＩＤ（Ｐａｃｋｅｔ＿ＩＤ）、スクランブルの有無を示すスクランブル制御情報、後続するアダプテーションフィールドやペイロードの有無等を示すアダプテーションフィールド制御情報が格納されている。

これらの制御情報に基づいて、受信装置側ではパケット単位でデスクランブルを行い、また、デマルチプレクサによりビデオ／オーディオ／データ等の必要パケットの分離・抽出を行うことができる。また、ビデオ／オーディオの同期再生の基準となる時刻情報を再生することもここで行うことができる。

また、これまでの説明から分かるように、１つのトランスポートストリームには複数チャンネル分の映像／音声／データのパケットが多重されているが、それ以外にＰＳＩ(Program Specific Information)といわれる選局を司るための信号や、限定受信（個人の契約状況により有料チャンネルの受信可不可を決定する受信機能）に必要な情報（ＥＭＭ／ＥＣＭ）、ＥＰＧなどのサービスを実現するためのＳＩ(Service Information)が同時に多重されている。ここでは、ＰＳＩについて説明する。

ＰＳＩは、図１０に示すようにして、４つのテーブルで構成されている。それぞれのテーブルは、セクション形式というＭＰＥＧ Ｓｙｓｔｅｍに準拠した形式で表されている。
図１０（ａ）には、ＮＩＴ(Network Informataion Table)及びＣＡＴ(Conditional Access Table)のテーブルが示されている。
ＮＩＴは、全キャリアに同一内容が多重されている。キャリアごとの伝送諸元（偏波面、キャリア周波数、畳み込みレート等）と、そこに多重されているチャンネルのリストが記述されている。ＮＩＴのＰＩＤとしては、ＰＩＤ＝0x0010とされている。

ＣＡＴもまた、全キャリアに同一内容が多重される。限定受信方式の識別と契約情報等の個別情報であるＥＭＭ(Entitlement Management Message)パケットのＰＩＤが記述されている。ＰＩＤとしては、ＰＩＤ＝0x0001により示される。

図１０（ｂ）には、キャリアごとに固有の内容を有する情報として、ＰＡＴが示される。ＰＡＴには、そのキャリア内のチャンネル情報と、各チャンネルの内容を表すＰＭＴのＰＩＤが記述されている。ＰＩＤとしては、ＰＩＤ＝0x0000により示される。

また、キャリアにおけるチャンネルごとの情報として、図１０（ｃ）に示すＰＭＴ(Program Map Table)のテーブルを有する。
ＰＭＴは、チャンネル別の内容が多重されている。例えば、図１０（ｄ）に示すような、各チャンネルを構成するコンポーネント（ビデオ／オーディオ等）と、デスクランブルに必要なＥＣＭ(Encryption Control Message)パケットのＰＩＤが記述されているＰＭＴのＰＩＤは、ＰＡＴにより指定される。

１−５．ＡＴＲＡＣデータの送信フォーマット
ここでＡＴＲＡＣ（Adaptive Tranform Acoustic Coding ）データの送信フォーマットについて説明する。図６に示したように１イベント内の送信データとしては１０単位の４倍速ＡＴＲＡＣオーディオチャンネル（１）〜（１０）が含まれている。

上記のように、衛星放送で音楽データの配信を行うようした場合、オーディオデータをそのまま伝送したのでは、データ量が膨大となり、転送時間が長くなる。そこで、オーディオデータを圧縮して伝送することが考えられ、その圧縮方式としては、例えば、ＡＴＲＡＣを用いることが考えられている。なおＡＴＲＡＣは、既に、ＭＤ（Mini Disc ）でオーディオデータを圧縮して記録するのに採用されている圧縮方式である。
ＡＴＲＡＣでオーディオデータの圧縮を行えば、配信する音楽データのデータレートを下げられると共に、配信されてきたオーディオデータをＭＤに直接記録することができるという利点がある。

ところで、ＡＴＲＡＣでは、４２４バイトがサウンドグループと称され、１つの記録単位となっている。このため、ＡＴＲＡＣのデータを衛星放送で配信する場合、このサウンドグループが崩れないように、データを伝送することが望まれる。

ＡＴＲＡＣでは、サンプリング周波数が４４．１ｋＨｚ、量子化ビット数１６ビットで、オーディオデータがディジタル化される。そして、このオーディオデータが１１．６１ｍ秒の時間窓で切り出され、変形ＤＣＴ（Discrete Cosine Transform ）により、約１／５のデータ量に圧縮される。

このように、サンプリング周波数が４４．１ｋＨｚ、量子化ビット数が１６ビットでディジタル化されたオーディオデータを１１．６１ｍ秒の時間窓で切り出すと、そのサンプル数は、５１２サンプルとなる。したがって、１１．６１ｍ秒の時間窓でのオーディオデータのデータ量は、５１２×２＝１０２４バイトとなり、左右の２チャンネルで、１０２４×２＝２０４８バイトとなる。

ＡＴＲＡＣでは、変形ＤＣＴデータにより、この２０４８バイトのデータが４２４バイトに圧縮される。この４２４バイトのＡＴＲＡＣデータがサウンドグループと称され、ＡＴＲＡＣ方式で圧縮された音声データを伝送するときの１つの単位となる。２０４８のデータが４２４バイトに圧縮されるので、ＡＴＲＡＣ方式の圧縮率は約１／５となる。

このように、ＡＴＲＡＣでは、１１．６１ｍ秒の期間の音声圧縮データに相当する４２４バイトのサウンドグループが音声圧縮データの１単位となっており、ＡＴＲＡＣのオーディオデータを伝送する場合には、このサウンドグループ単位を保持していくことが望まれる。
なお、サウンドグループを単位とするＭＤシステムのデータ構造は図１８で後述する。

一方、上記したＭＰＥＧ２方式では、ビデオデータ、オーディオデータ、その他のデータが図９に示したトランスポートパケット（ＴＳパケット）と呼ばれる１８８バイトの固定長のパケットに載せられ、同一ストリームで多重化されて伝送されている。したがって、ＡＴＲＡＣで圧縮されたオーディオデータをＭＰＥＧ２のストリームで転送する場合には、ＡＴＲＡＣで圧縮されたオーディオデータを１８８バイトのＴＳパケットに載せなければならない。

ところが、ＡＴＲＡＣのサウンドグループである４２４バイトと、ＴＳパケットのサイズである１８８バイトとの間は、無関係である。このため、ＡＴＲＡＣのデータを単にＴＳパケットに割り当てて伝送すると、サウンドグループが崩れてしまい、ＡＴＲＡＣの復調処理やＡＴＲＡＣでの記録処理が困難になる。
そこで本例では次のようにして、ＡＴＲＡＣデータをＭＰＥＧ２のストリームで伝送する場合に、そのＡＴＲＡＣデータの基本単位を保持しつつ、ＰＥＳ（Packetized Elementary Stream）パケットで効率的に伝送できるようにしている。

ＭＰＥＧ２方式では、ＴＳパケットと呼ばれる伝送単位で、複数のプログラムが多重化されて伝送されるが、このＴＳパケットは、１８８バイトの固定長に定められている。一方、ＡＴＲＡＣで圧縮されたオーディオデータを伝送する場合には、４２４バイトのＡＴＲＡＣの１サウンドグループのデータを保持する必要がある。
そこで、図１１（ａ）に示すように、１つのＴＳパケットＴＳＰ１〜ＴＳＰ８に、夫々、１５９バイトのＡＴＲＡＣの圧縮オーディオデータを配置し、８つのＴＳパケットＴＳＰ１〜ＴＳＰ８でＰＥＳパケットを構成するようにしている。

このように、１つのＴＳパケットで１５９バイトのＡＴＲＡＣのデータを配置し、８つのＴＳパケットでＰＥＳパケットを構成すると、ＰＥＳパケットの大きさは、１５９バイト×８＝１２７２バイトとなる。サウンドグループの大きさは４２４バイトであるから、このＰＥＳパケットで送られる１２７２バイトのデータは、図１１（ｂ）に示すように、３つのサウンドグループＳＧＰ１〜ＳＧＰ３のデータに相当する。
４２４バイト×３＝１２７２バイト

１つのＴＳパケットに１５９バイトのＡＴＲＡＣのデータを配置し、８つのＴＳパケットでＰＥＳパケットを構成すると、ＰＥＳパケットで３サウンドグループのデータが伝送できる。このように、ＰＥＳパケットで整数個のサウンドグループのデータが伝送されるため、ＡＴＲＡＣのデータとＰＥＳパケットとの整合性が良好となる。

このように、ＡＴＲＡＣのデータを伝送する場合には、１８８バイトの固定長のＴＳパケットのうち、１５９バイトがＡＴＲＡＣデータの伝送に使用される。
そしてＴＳパケットの残りの２９バイトは、ＴＳパケットヘッダ、ＰＥＳヘッダ、データヘッダ等が設けられる。データヘッダには、伝送するデータのタイプ、衛星放送や地上波放送等のデータの伝送路のタイプ等が設けられる。更に、ＡＴＲＡＣデータの固有情報を定義するＦＤＦ（Field Dependnet Field ）設けられる。

以上のように本例の伝送方法では、ＡＴＲＡＣのデータを伝送する場合に、１つのＴＳパケットに１５９バイトのＡＴＲＡＣのデータが配置され、更に、データヘッダとＦＤＦが設けられ、８つのＴＳパケットでＰＥＳパケットが構成され、ＰＥＳパケットで３つのサウンドグループのデータが伝送される。
このようにして、ＡＴＲＡＣのデータをＰＥＳパケットで伝送する場合の具体例について以下に説明する。

図１２は、ＰＴＳ（Presentation Time Stamp ）を利用して同期伝送を可能にする方式の場合のＴＳパケットの構成を示すものである。図１２に示すように、ＴＳパケットは１８８バイトの固定長からなる。このＴＳパケットの先頭の１バイト目から４バイト目は、トランスポートパケットヘッダとされ、５バイト目から１８バイト目はＰＥＳパケットヘッダとされ、１９バイト目から２０バイト目はデータヘッダとされ、２１バイト目から１８８バイト目はデータボディとされている。データボディの構成は、図１３に示されている。なお図１２、図１３は図９で説明したＴＳパケットとして、ＡＴＲＡＣデータを伝送するＴＳパケットの場合を詳しく示したものである。

トランスポートパケットヘッダの先頭には、１バイトのシンクバイトが設けられる。このシンクバイトに続いて、このパケット中のエラーの有無を示すトランスポートエラーインディケータと、新たなＰＥＳパケットがこのトランスポートパケットのペイロードから始まることを示すペイロードユニットスタートインディケータと、このパケットの重要度を示すトランスポートプライオリティが、夫々、１ビット設けられる。
トランスポートエラーインディケータは伝送上のエラーが発生した時にＩＲＤ１２側で「１」とされるデータである。そしてトランスポートエラーインディケータ＝「１」とされたＴＳパケットは、データ信頼性が確実でないものとして扱われることになる。

トランスポートパケットヘッダにはさらに、該当パケットの個別ストリームの属性を示す１３ビットのストリーム識別情報（ＰＩＤ）が設けられる。続いてパケットのペイロードのスクランブルの有無や種別を示すトランスポートスクランブリングコントロールと、アダプテーションフィールドの有無を示すアダプテーションフィールドコントロールと、同じＰＩＤを持つパケットが途中で一部破棄されたかどうかを検出するためのコンティニュイティカウンタが設けられる。

５バイト目から１８バイト目のＰＥＳパケットヘッダの先頭には、２４ビットの固定値のパケットスタートコードプリフィックスが設けられ、これに続いて、ストリームを識別する８ビットのストリームＩＤや、ＰＥＳパケットの長さを示すＰＥＳパケットレングスが設けられる。さらに続いて、「１０」の固定パターン、２ビットのＰＥＳスクランブルコントロール、１ビットのＰＥＳプライオリティ、１ビットのデータアライメントインディケータ、１ビットのコピーライト、１ビットのオリジナル／コピーかの識別情報、２ビットのＰＴＳ及びＤＴＳフラグ、１ビットのＥＳＣＲフラグ、１ビットのＥＳレートフラグ、１ビットのＤＭＳトリックモードフラグ、１ビットのアディショナルコピーインフォメーションフラグ、１ビットのＰＥＳのＣＲＣフラグ、１ビットのＰＥＳエクステーションフラグが設けられる。

これらに続いて、８ビットのＰＥＳヘッダデータレングスが設けられる。
さらに「１１０１」の固定パターンの後に、タイムスタンプであるＰＴＳの３２から３０が設けられ、これに続いて１ビットのマーケットビットが設けられる。そして、これに続く１５ビットにタイムスタンプであるＰＴＳの２９から１５が設けられ、これに、１ビットのマーケットビットが付加される。更にこれに続く１５ビットにＰＴＳの１４から０が設けられ、これに、１ビットのマーケットビットが付加される。

１９バイト目から２０バイト目のデータヘッダには、８ビットのデータタイプと、６ビットのデータトランスミッションタイプと、２ビットのタグが設けられる。データタイプには、伝送するデータのタイプが記述される。データトランスミッションタイプには、データの伝送路のタイプ、例えば衛星放送、地上波放送等が記述される。タグには、データヘッダの後に、アディショナルヘッダがあるか否かが記述される。例えば、タグが「００」ならデータヘッダの後にデータが続き、「０１」ならデータヘッダの後にアディショナルヘッタが続くことが示され、「１０」ならアディショナルヘッダがＰＥＳパケットの中で複数回数あることが示される。

２１バイト目から１８８バイト目は、データボディとされ、ここに、ＡＴＲＡＣのデータが配置される。ＡＴＲＡＣデータの配置は、図１３に示すようになっている。

図１３に示すように、データボディの２１バイト目の最初の４ビットには、ＦＤＦフィールドレングスが設けられ、次の４ビットにはオーディオデータタイプ１が設けられる。ＦＤＦフィールドレングスはＦＤＦフィールドの長さを示すものである。オーディオデータタイプ１は、オーディオタイプを定義（例えばＡＴＲＡＣ）するためのものである。これに続いて、オーディオデータタイプ２が設けられる。このオーディオデータタイプ２は、データタイプの中での分類が定義される（例えば、ＡＴＲＡＣ１、ＡＴＲＡＣ２）。次に、１ビットのコピーライト、１ビットのオリジナル／コピー、１ビットのステレオ／モノ、１ビットのエンファシスが設けられる。

これに続いて、１ビットのデータスタートインディケータと、１ビットのデータエンドインディケータと、３ビットのＰＥＳデータカウンタが設けられる。
データスタートインディケータは、伝送中のデータが楽曲データの最初のＰＥＳパケットであることを示している。つまり楽曲の先頭となるＡＴＲＡＣデータが含まれているＰＥＳにおける８個のＴＳパケットにおいては、データスタートインディケータ＝「１」とされる。
データエンドインディケータは、伝送中のデータが楽曲の最後のＰＥＳパケットであることを示している。つまり楽曲の終端となるＡＴＲＡＣデータが含まれているＰＥＳにおける８個のＴＳパケットにおいては、データエンドインディケータ＝「１」とされる。

ＰＥＳデータカウンタは、ＰＥＳを伝送する８つのＴＳパケットの中で何番目かを示している。
これに続く３ビットはリザーブとされているが、次の２４ビットは、プレゼントＰＥＳナンバとされている。このプレゼントＰＥＳナンバには、伝送中のデータが何番目のＰＥＳパケットであるかが示される。
従って、プレゼントＰＥＳナンバと、ＰＥＳデータカウンタにより、ＴＳパケット単位での連続性が判断できる。これはＴＳパケットにのせられるＡＴＲＡＣデータの連続性が判断できることを意味する。

２７バイト目から２８バイト目は、リザーブとされて、その次の２９バイト目にはＡＴＲＡＣデータに対するチェックサム（ＣＲＣエラー検出コード）が設けられる。
そして、３０バイト目から１８８バイト目には、１５９バイト分のＡＴＲＡＣデータが配列される。

２９バイト目のＡＴＲＡＣデータチェックサムとＡＴＲＡＣデータの関係を図１４に示す。ＡＴＲＡＣデータチェックサムによる計算の仕方は次のようになる。
図示するようにＡＴＲＡＣデータチェックサムの各ビットの値をＣＳ［０］〜ＣＳ［７］とし、また１５９バイトのＡＴＲＡＣデータの最初のバイトの値をＡＴ[0][0]、最初のバイトの値をＡＴ[158][7]とすると、
ＣＳ［０］＾ＡＴ[0][0]＾ＡＴ[1][0]＾・・・＾ＡＴ[158][0]＝ＳＵＭ［０］
ＣＳ［１］＾ＡＴ[0][1]＾ＡＴ[1][1]＾・・・＾ＡＴ[158][1]＝ＳＵＭ［１］
・・・・
ＣＳ［７］＾ＡＴ[0][7]＾ＡＴ[1][7]＾・・・＾ＡＴ[158][7]＝ＳＵＭ［７］
としたときに、
ＳＵＭ［０］〜ＳＵＭ［７］＝０ｘ００
となるようにＣＳ［０］〜ＣＳ［７］の値を設定するものである。

このようにＡＴＲＡＣデータに対するチャックサムを設けることで、ＩＲＥ１２側やストレージデバイス１３側においてダウンロードするＡＴＲＡＣデータの信頼性をチェックできる。

以上のようにＴＳパケットには、１５９バイトのＡＴＲＡＣのデータが配置されると共に、固有情報が定義されて、ＦＤＦに挿入される。ＦＤＦの領域は、アディショナルデータヘッダ、ＡＴＲＡＣデータ、ＦＤＦのデータを受信する際に、機器の信号処理をしやすくするために、ＴＳパケットの固定の位置に配置される。

そしてＦＤＦを解析することにより、１つのＴＳパケット中のデータが伝送しようとしている楽曲中のどのデータであるかを解析することがてきる。これにより、伝送中何等かの理由によりエラーが発生し、あるパケットが正しく受信できなかった場合も、どのデータが抜けたかを検出することが可能となる。また、データスタートインディケータ、データエンドインディケータを検出するとで、そのデータが楽曲の最初又は最後であることが検出できる。このデータを利用して、ストレージデバイス１３でダウンロードを行う時に、記録開始位置又は記録終了位置を簡単に検出することができる。

１−６．ＩＲＤ
続いて、受信設備３に備えられるＩＲＤ１２の一構成例について図１５を参照して説明する。

この図に示すＩＲＤ１２において、入力端子Ｔ１には、パラボラアンテナ１１のＬＮＢ１５により所定の周波数に変換された受信信号を入力してチューナ／フロントエンド部５１に供給する。
チューナ／フロントエンド部５１では、ＣＰＵ(Central Processing Unit)８０からの伝送諸元等を設定した設定信号に基づいて、この設定信号により決定されるキャリア（受信周波数）を受信して、例えばビタビ復調処理や誤り訂正処理等を施すことで、トランスポートストリームを得るようにされる。
チューナ／フロントエンド部５１にて得られたトランスポートストリームは、デスクランブラ５２に対して供給される。また、チューナ／フロントエンド部５１では、トランスポートストリームからＰＳＩのパケットを取得し、その選局情報を更新すると共に、トランスポートストリームにおける各チャンネルのコンポーネントＰＩＤを得て、例えばＣＰＵ８０に伝送する。ＣＰＵ８０では、取得したＰＩＤを受信信号処理に利用することになる。

デスクランブラ５２では、ＩＣカード６５に記憶されているデスクランブルキーデータをＣＰＵ８０を介して受け取ると共に、ＣＰＵ８０によりＰＩＤが設定される。そして、このデスクランブルキーデータとＰＩＤとに基づいてデスクランブル処理を実行し、トランスポート部５３に対して伝送する。

トランスポート部５３は、デマルチプレクサ７０と、例えばＤＲＡＭ等により構成されるキュー（Queue）７１とからなる。キュー（Queue）７１は、モジュール単位に対応した複数のメモリ領域が列となるようにして形成されているものとされ、例えば本例では、３２列のメモリ領域が備えられる。つまり、最大で３２モジュールの情報を同時に格納することができる。

デマルチプレクサ７０の概略的動作としては、ＣＰＵ８０のＤｅＭＵＸドライバ８２により設定されたフィルタ条件に従って、デスクランブラ５２から供給されたトランスポートストリームから必要なトランスポートパケットを分離し、必要があればキュー７１を作業領域として利用して、先に図７（ｅ）〜（ｈ）により示したような形式のデータを得て、それぞれ必要な機能回路部に対して供給する。
デマルチプレクサ７０にて分離されたＭＰＥＧビデオデータは、ＭＰＥＧ２ビデオデコーダ５５に対して入力され、ＭＰＥＧオーディオデータは、ＭＰＥＧオーディオデコーダ５４に対して入力される。これらデマルチプレクサ７０により分離されたＭＰＥＧビデオ／オーディオデータの個別パケットは、上述したＰＥＳ(Packetized Elementary Stream)と呼ばれる形式でそれぞれのデコーダに入力される。

また、トランスポートストリームにおけるＭＨＥＧコンテンツのデータについては、デマルチプレクサ７０によりトランスポートストリームからトランスポートパケット単位で分離抽出されながらキュー７１の所要のメモリ領域に書き込まれていくことで、モジュール単位にまとめられるようにして形成される。そして、このモジュール単位にまとめられたＭＨＥＧコンテンツのデータは、ＣＰＵ８０の制御によってデータバスを介して、メインメモリ９０内のＤＳＭ−ＣＣバッファ９１に書き込まれて保持される。

また、トランスポートストリームにおける４倍速ＡＴＲＡＣデータ（圧縮オーディオデータ）も、例えばトランスポートパケット単位で必要なデータがデマルチプレクサ７０により分離抽出されてＩＥＥＥ１３９４インターフェイス６０に対して出力される。また、ＩＥＥＥ１３９４インターフェイス６０を介した場合には、オーディオディオデータの他、ビデオデータ及び各種コマンド信号等を送出することも可能とされる。

なお、図６で説明したように４倍速ＡＴＲＡＣデータとして４倍速ＡＴＲＡＣ（１）〜（１０）というように例えば１０曲分のデータが同時的に受信されるわけであるが、例えばその中の特定の楽曲をストレージデバイス１３においてダウンロードさせる場合には、そのダウンロード対象の曲としてのＡＴＲＡＣデータのみがＩＥＥＥ１３９４インターフェイス６０からストレージデバイス１３に出力されることになる。
即ち或る曲のダウンロードが実行される際には、ＣＰＵ８０はその楽曲のＡＴＲＡＣデータのみを抽出して出力するようにＩＥＥＥ１３９４インターフェイス６０に指示制御を行うことになる。

ＰＥＳとしての形式によるＭＰＥＧビデオデータが入力されたＭＰＥＧ２ビデオデコーダ５５では、メモリ５５Ａを作業領域として利用しながらＭＰＥＧ２フォーマットに従って復号化処理を施す。復号化されたビデオデータは、表示処理部５８に供給される。

表示処理部５８には、上記ＭＰＥＧ２ビデオデコーダ５５から入力されたビデオデータと、後述するようにしてメインメモリ９０のＭＨＥＧバッファ９２にて得られるデータサービス用のＧＵＩ画面等のビデオデータが入力される。表示処理部５８では、このようにして入力されたビデオデータについて所要の信号処理を施して、所定のテレビジョン方式によるアナログオーディオ信号に変換してアナログビデオ出力端子Ｔ２に対して出力する。
これにより、アナログビデオ出力端子Ｔ２とモニタ装置１４のビデオ入力端子とを接続することで、例えば先に図４に示したような表示が行われる。

また、ＰＥＳによるＭＰＥＧオーディオデータが入力されるＭＰＥＧ２オーディオデコーダ５４では、メモリ５４Ａを作業領域として利用しながらＭＰＥＧ２フォーマットに従って復号化処理を施す。復号化されたオーディオデータは、Ｄ／Ａコンバータ５６及び光デジタル出力インターフェイス５９に対して供給される。

Ｄ／Ａコンバータ５６では、入力されたオーディオデータについてアナログ音声信号に変換してスイッチ回路５７に出力する。スイッチ回路５７では、アナログオーディオ出力端子Ｔ３又はＴ４の何れか一方に対してアナログ音声信号を出力するように信号経路の切換を行う。
ここでは、アナログオーディオ出力端子Ｔ３はモニタ装置１４の音声入力端子と接続されるために設けられているものとされる。また、アナログオーディオ出力端子Ｔ４はダウンロードした楽曲をアナログ信号により出力するための端子とされる。
また、光デジタル出力インターフェイス５９では、入力されたデジタルオーディオデータを光デジタル信号に変換して出力する。この場合、光デジタル出力インターフェイス５９は、例えばＩＥＣ９５８に準拠する。

メインメモリ９０は、ＣＰＵ８０が各種制御処理を行う際の作業領域として利用されるものである。そして、本例では、このメインメモリ９０において、前述したＤＳＭ−ＣＣバッファ９１と、ＭＨＥＧバッファ９２としての領域が割り当てられるようになっている。
ＭＨＥＧバッファ９２には、ＭＨＥＧ方式によるスクリプトの記述に従って生成された画像データ（例えばＧＵＩ画面の画像データ）を生成するための作業領域とされ、ここで生成された画像データはバスラインを介して表示処理部５８に供給される。

ＣＰＵ８０は、ＩＲＤ１２における全体制御を実行する。このなかには、デマルチプレクサ７０におけるデータ分離抽出についての制御も含まれる。
また、獲得したＭＨＥＧコンテンツのデータについてデコード処理を施すことで、スクリプトの記述内容に従ってＧＵＩ画面（シーン）を構成して出力するための処理も実行する。

このため、本例のＣＰＵ８０としては、集中的に主たる制御処理を実行する制御処理部８１に加え、例えば少なくとも、ＤｅＭＵＸドライバ８２、ＤＳＭ−ＣＣデコーダブロック８３、及びＭＨＥＧデコーダブロック８４が備えられる。本例では、このうち、少なくともＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４については、ソフトウェアにより構成される。
ＤｅＭＵＸドライバ８２は、入力されたトランスポートストリームのＰＩＤに基づいてデマルチプレクサ７０におけるフィルタ条件を設定する。
ＤＳＭ−ＣＣデコーダブロック８３では、ＤＳＭ−ＣＣバッファ９１に格納されているモジュール単位のデータについて、ＭＨＥＧコンテンツのデータに再構築する。
ＭＨＥＧデコーダブロック８４は、ＤＳＭ−ＣＣデコーダブロック８３により得られたＭＨＥＧコンテンツのデータに基づいてデコード処理を行う。つまり、そのＭＨＥＧコンテンツのスクリプトファイルにより規定されているオブジェクト間の関係を実現していくことで、シーンを形成するものである。この際、シーンとしてＧＵＩ画面を形成するのにあたっては、ＭＨＥＧバッファ９２を利用して、ここで、スクリプトファイルの内容に従ってＧＵＩ画面の画像データを生成するようにされる。

ＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４間のインターフェイスには、Ｕ−Ｕ ＡＰＩが採用される。
Ｕ−Ｕ ＡＰＩは、ＤＳＭ Ｍａｎａｇｅｒオブジェクト（ＤＳＭの機能を実現するサーバオブジェクト）にアクセスするためのインターフェイスであり、これにより、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ，Ｄｉｒｅｃｔｏｒｙ，Ｆｉｌｅ，Ｓｔｒｅａｍ，Ｓｔｒｅａｍ Ｅｖｅｎｔなどのオブジェクトに対する操作を行う。
クライアントオブジェクトは、このＡＰＩを使用することによって、これらのオブジェクトに対して操作を行うことができる。

ここで、ＣＰＵ８０の制御によりトランスポートストリームから１シーンを形成するのに必要な目的のオブジェクトを抽出するための動作例について説明しておく。

ＤＳＭ−ＣＣでは、トランスポートストリーム中のオブジェクトの所在を示すのにＩＯＲ(Interoperable Object Reference)が使用される。ＩＯＲには、オブジェクトを見つけ出すための力ルーセルに対応する識別子、オブジェクトの含まれるモジュールの識別子（以下ｍｏｄｕｌｅ＿ｉｄと表記）、１つのモジュール中でオブジェクトを特定する識別子（以下ｏｂｊｅｃｔ＿ｋｅｙと表記）のほかに、オブジェクトの含まれるモジュールの情報を持つＤＩＩを識別するためのタグ（ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ）情報を含んでいる。
また、モジュール情報を持つＤＩＩには、１つ以上のモジュールそれぞれについてのｍｏｄｕｌｅ＿ｉｄ、モジュールの大きさ、バージョンといった情報と、そのモジュールを識別するためのタグ（ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ）情報を含んでいる。

トランスポートストリームから抜き出されたＩＯＲがＣＰＵ８０において識別された場合に、そのＩＯＲで示されたオブジェクトを受信、分離して得るプロセスは、例えば次のようになる。
（Ｐｒ１） ＣＰＵ８０のＤｅＭＵＸドライバ８２では、ＩＯＲのａｓｓｏｃｉａｔｉｏｎ＿ｔａｇと同じ値を持つエレメンタリーストリーム（以下ＥＳと表記）を、カルーセルにおけるＰＭＴのＥＳループから探し出してＰＩＤを得る。このＰＩＤを持つＥＳにＤＩＩが含まれていることになる。
（Ｐｒ２） このＰＩＤとｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎとをフィルタ条件としてデマルチプレクサ７０に対して設定する。これにより、デマルチプレクサ７０では、ＤＩＩを分離してＣＰＵ８０に対して出力する。
（Ｐｒ３） ＤＩＩの中で、先のＩＯＲに含まれていたｍｏｄｕｌｅ＿ｉｄに相当するモジュールのａｓｓｏｃｉａｔｉｏｎ＿ｔａｇを得る。
（Ｐｒ４） 上記ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇと同じ値を有するＥＳを、ＰＭＴのＥＳループ（カルーセル）から探し出し、ＰＩＤを得る。このＰＩＤを有するＥＳに目的とするモジュールが含まれる。
（Ｐｒ５） 上記ＰＩＤとｍｏｄｕｌｅ＿ｉｄとをフィルタ条件として設定して、デマルチプレクサ７０によるフィルタリングを行う。このフィルタ条件に適合して分離抽出されたトランスポートパケットがキュー７１の所要のメモリ領域（列）に格納されていくことで、最終的には、目的のモジュールが形成される。
（Ｐｒ６） 先のＩＯＲに含まれていたｏｂｊｅｃｔ＿ｋｅｙに相当するオブジェクトをこのモジュールから抜き出す。これが目的とするオブジェクトになる。このモジュールから抜き出されたオブジェクトは、例えば、ＤＳＭ−ＣＣバッファ９１の所定の領域に書き込みが行われる。
例えば、上記動作を繰り返し、目的とするオブジェクトを集めてＤＳＭ−ＣＣバッファ９１に格納していくことで、必要とされるシーンを形成するＭＨＥＧコンテンツが得られることになる。

マンマシンインターフェイス６１では、リモートコントローラ６４から送信されてきたコマンド信号を受信してＣＰＵ８０に対して伝送する。ＣＰＵ８０では、受信したコマンド信号に応じた機器の動作が得られるように、所要の制御処理を実行する。

ＩＣカードスロット６２にはＩＣカード６５が挿入される。そして、この挿入されたＩＣカード６５に対してＣＰＵ８０によって情報の書き込み及び読み出しが行われる。

モデム６３は、電話回線４を介して課金サーバ５と接続されており、ＣＰＵ８０の制御によってＩＲＤ１２と課金サーバ５との通信が行われるように制御される。

またＣＰＵ８０が必要な情報を或る程度長期間保持しておくために、不揮発性メモリ６８が設けられる。この不揮発性メモリ６８には、電源オフにより消失されることが適切でない情報が記憶される。例えば各種制御係数の初期値、設定値などが記憶される。また本例の場合は接続される機器の情報を保持する接続機器ＩＤテーブルが、この不揮発性メモリ６８に保持されることになる。

タイマ６９は、いわゆる時計としての機能であり、現在日時としての年月日時分秒を計数する。例えばダウンロードの予約動作のためなどに用いられる。

また、ストレージデバイス１３に対する接続に関して、制御データやコマンドの授受については上記ＩＥＥＥ１３９４インターフェース６０を介して実行できるが、もちろんそれはストレージデバイス１３側がＩＥＥＥ１３９４に対応している機器である場合である。
もちろんＩＥＥＥ１３９４に対応してないストレージデバイス１３も存在し、そのような機器が接続される場合もあるが、そのような場合には外部バスライン等を構成するコントロールラインインターフェース６７や、赤外線インターフェース６６により、コマンド等の通信を行うことができるようにしている。
コントロールラインインターフェース６７により、ＩＲＤ１２とストレージデバイス１３の間の双方向コマンド通信を可能とできる。また、例えば接続される機器が赤外線リモートコマンダーに対応している場合は、その機器に応じたデータ形態の赤外線コマンドを赤外線インターフェース６６から出力することで、接続機器の制御を行うことができる。この赤外線インターフェイスの場合にも、ストレージデバイス１３側が赤外線出力可能とされることで双方向通信を実行することもできる。

なお、ＩＥＥＥ１３９４に対応してないストレージデバイス１３に対するオーディオデータの出力は、ＡＴＲＡＣ形態ではなく、ベースバンド信号として、光デジタル出力インターフェイス５９もしくはアナログオーディオ出力端子Ｔ４から行われることになる。

ここで、上記構成によるＩＲＤ１２におけるビデオ／オーディオソースの信号の流れを、図４により説明した表示形態に照らし合わせながら補足的に説明する。
図４（ａ）に示すようにして、通常の番組を出力する場合には、入力されたトランスポートストリームから必要な番組のＭＰＥＧビデオデータとＭＰＥＧオーディオデータとが抽出されて、それぞれ復号化処理が施される。そして、このビデオデータとＭＰＥＧオーディオデータが、それぞれアナログビデオ出力端子Ｔ２と、アナログオーディオ出力端子Ｔ３に出力されることで、モニタ装置１４では、放送番組の画像表示と音声出力が行われる。

また、図４（ｂ）に示したＧＵＩ画面を出力する場合には、入力されたトランスポートストリームから、このＧＵＩ画面（シーン）に必要なＭＨＥＧコンテンツのデータをトランスポート部５３により分離抽出してＤＳＭ−ＣＣバッファ９１に取り込む。そして、このデータを利用して、前述したようにＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４が機能することで、ＭＨＥＧバッファ９２にてシーン（ＧＵＩ画面）の画像データが作成される。そして、この画像データが表示処理部５８を介してアナログビデオ出力端子Ｔ２に供給されることで、モニタ装置１４にはＧＵＩ画面の表示が行われる。

また、図４（ｂ）に示したＧＵＩ画面上で楽曲のリスト２１Ｂにより楽曲が選択され、その楽曲のオーディオデータを試聴する場合には、この楽曲のＭＰＥＧオーディオデータがデマルチプレクサ７０により得られる。そして、このＭＰＥＧオーディオデータが、ＭＰＥＧオーディオデコーダ５４、Ｄ／Ａコンバータ、スイッチ回路５７、アナログオーディオ出力端子Ｔ３を介してアナログ音声信号とされてモニタ装置１４に対して出力される。

また、図４（ｂ）に示したＧＵＩ画面上でダウンロードボタン２８が押されてオーディオデータをダウンロードする場合には、ダウンロードすべき楽曲のオーディオデータがデマルチプレクサ７０により抽出されてアナログオーディオ出力端子Ｔ４、光デジタル出力インターフェイス５９、またはＩＥＥＥ１３９４インターフェイス６０に出力される。

ここで、特にＩＥＥＥ１３９４インターフェイス６０に対して、図２に示したＩＥＥＥ１３９４対応のＭＤレコーダ１３Ａが接続されている場合には、デマルチプレクサ７０ではダウンロード楽曲の４倍速ＡＴＲＡＣデータが抽出され、ＩＥＥＥ１３９４インターフェイス６０を介してＭＤレコーダ１３Ａに装填されているディスクに対して記録が行われる。また、この際には、例えばＪＰＥＧ方式で圧縮されたアルバムジャケットの静止画データ、歌詞やアーティストのプロフィールなどのテキストデータもデマルチプレクサ７０においてトランスポートストリームから抽出され、ＩＥＥＥ１３９４インターフェイス６０を介してＭＤレコーダ１３Ａに転送される。ＭＤレコーダ１３Ａでは、装填されているディスクの所定の領域に対して、これら静止画データ、テキストデータを記録することができるようになっている。

ところで、以上のようにＤＳＭ−ＣＣ方式を伝送規格として採用した本例のデジタル衛星放送システムでは、受信装置、つまりＩＲＤ１２のタイプとして、受信バッファの構成の点から２種類に分けることができる。

１つは、ＩＲＤ１２が、データサービス（ＧＵＩ画面表示出力）対応のフラッシュメモリやハードディスクドライバなどの大容量の受信バッファを有する構成のものである。このような構成では、放送されているデータサービス（ＭＨＥＧコンテンツ）全体を一度に受信して、受信バッファに保持させる。これにより、一旦データサービスを受信して取り込んだ後は、ＭＨＥＧによるどのシーン（ＧＵＩ画面）についても、メモリアクセスの待ち時間のみ待機するだけで即座に表示出力させることが可能になる。つまり、ＧＵＩ画面（シーン）の切換のための操作をユーザが行ったような場合にも、次のシーンがほぼ直ぐさま表示されることになる。
このような場合、デマルチプレクサのフィルタ条件の切り換えによる多少のオーバーヘッドは、ＧＵＩ画面の表示に関しては特に問題となるものではない。

もう１つは、ＩＲＤのコストを下げるなどの理由から、上記のような大容量の受信バッファを持たないものである。先に説明した本例のＩＲＤ１２がこれに相当する。この場合、データ放送サービス全体のデータをバッファリングすることができず、データ放送のデータを受信する受信単位であるモジュールのいくつかがバッファリングできるだけの受信バッファしか持たない。図１５に示したＩＲＤ１２では、この受信バッファはキュー７１に相当し、前述のようにモジュールがバッファリングできるメモリ領域が３２列設けられているのみである。
このようなＩＲＤでは、逆に言えば、モジュ−ルの大きさは受信機のバッファメモリーサイズを上回ることはできない。このため、データサービス全体がいくつかのモジュールの集合で構成されることになり、その時々で表示に必要なモジュールだけを受信するなどの手順が必要になってくる。
前述したオブジェクトを抽出するための手順（Ｐｒ１）〜（Ｐｒ６）は、このような大容量の受信バッファを有さないＩＲＤの構成に対応したものである。

ここで、図１６に、ＭＨＥＧ方式に則ったデータサービスとしてのファイル（ＭＨＥＧ ａｐｐｌｉｃａｔｉｏｎ ｆｉｌｅ）のディレクトリ構造例を示す。前述したようにオブジェクトカルーセル方式は、このディレクトリ構造を扱えることに特徴を有する。
通常、Ｓｅｒｖｉｃｅ Ｄｏｍａｉｎの入り口となる（ＭＨＥＧ ａｐｐｌｉｃａｔｉｏｎ ｆｉｌｅ）は、必ず、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙの直下にある、ａｐｐ０／ｓｔａｒｔｕｐというファイルとなる。
基本的には、Ｓｅｒｖｉｃｅ Ｄｏｍａｉｎ（Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ）の下にａｐｐｌｉｃａｔｉｏｎ ｄｉｒｅｃｔｏｒｙ（ａｐｐ０，ａｐｐ１・・・ａｐｐＮ）があり、その下にｓｔａｒｔｕｐといわれるアプリケーション・ファイルと、ａｐｐｌｉｃａｔｉｏｎを構成する各ｓｃｅｎｅのｄｉｒｅｃｔｏｒｙ（ｓｃｅｎｅ０，ｓｃｅｎｅ１・・・）があるようにされる。更にｓｃｅｎｅ ｄｉｒｅｃｔｏｒｙの下には、ＭＨＥＧ ｓｃｅｎｅ ｆｉｌｅとｓｃｅｎｅを構成する各ｃｏｎｔｅｎｔ ｆｉｌｅがおかれることとしている。

上記図１６のディレクトリ構造を前提として、例えば或るデータサービスにおいて、データサービスの最初にアクセスすべきアプリケーションがＳｅｒｖｉｃｅ Ｇａｔｅｗａｙ／ａｐｐ０／ｓｔａｒｔｕｐというファイルで、最初のシーンがｓｃｅｎｅｄｉｒ０に含まれる静止画やテキストのファイルで構成されているとする。
そして、このようなデータサービスについてＩＲＤにより受信を開始したとすれば、次のような手順となる。
（Ｐｒ１１） ＰＭＴを参照して所望のデータサービスのＰＩＤを取得し、そのＰＩＤとｔａｂｌｅ＿ｉｄとｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎをフイルタ条件としてデマルチプレクサでフィルタリングを行い、ＤＳＩを得る。このＤＳＩにはＳｅｒｖｉｃｅ ＧａｔｅｗａｙオブジェクトのＩＯＲが書かれている。
（Ｐｒ１２） このＩＯＲから、先に説明したオブジェクト抽出手順（Ｐｒ１）〜（Ｐｒ６）でＳｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトを得る。

Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトとディレクトリ・オブジェクトの２種類のＢＩＯＰメッセージの中には、そのディレクトリ直下のオブジェクトの名称、所在（ｌＯＲ）、オブジェクトの種類といった情報が、ｂｉｎｄｉｎｇという属性情報として入っている。従ってオブジェクトの名称が与えられると、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙから始まってディレクトリをーつづつ下にたどりながら、その名称のオブジェクトに行き着くことができる（同じ名称のオブジェクトが存在する場合は、違うところまで上位のバス名が必要になる）。そして、さらに次に示す手順に進む。

（Ｐｒ１３） Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトのｂｉｎｄｉｎｇ情報からａｐｐ０オブジェクトのＩＯＲを得て、オブジェクト抽出手順（Ｐｒ１）〜（Ｐｒ６）によりａｐｐ０オブジェクトを得る。
（Ｐｒ１４） ａｐｐ０オブジェクトのｂｉｎｄｉｎｇ情報からｓｔａｒｔｕｐオブジェクトのＩＯＲを得て、オブジェクト抽出手順（Ｐｒ１）〜（Ｐｒ６）でｓｔａｒｔｕｐオブジェクトを得る。以下同様に最初のシーンであるｓｃｅｎｅｄｉｒ０オブジェクトなどを得る。

１−７．ＭＤレコーダ
図１７はストレージデバイス１３となるＭＤレコーダの構成例を示している。
ディスク１０１は、例えば、カートリッジに収納された直径６４ｍｍの光磁気ディスクからなるＭＤである。装填されたディスク１０１はスピントルモータ１０２により所定ＣＬＶ速度の状態で回転される。またディスク１０１に対しては、光学ヘッド１０３と磁気ヘッド１２１が記録面に対してそれぞれ両側から対向した状態に配される。光学ヘッド１０３には、レーザ光を出力するためのレーザダイオード、偏光ビームスプリッタや対物レンズからなる光学系、反射光を検出するためのディテクタなどが搭載されている。対物レンズ１０３ａは、２軸デバイス１０４によりディスクの半径方向及びディスクに接離する方向に変位可能に保持されている。光学ヘッド１０３及び磁気ヘッド１２１全体は、スレッド機構１０５によりディスクの半径方向に移動可能とされている。

光学ヘッド１０３によりディスク１０１から検出された情報は、ＲＦアンプ１０７に供給される。ＲＦアンプ１０７からは、光学ヘッド１０３の各ディテクタの出力を演算処理することにより、再生ＲＦ信号、トラッキングエラー信号、フォーカスエラー信号、ウォブル記録されている絶対位置情報等が抽出される。このうちで、再生ＲＦ信号は、ＥＦＭ（Eight To Fourteen Modulation）及びＡＣＩＣＲ（Advanced Cross Interleave Reed-Solomon Code ）エンコーダ／デコーダ部１０８に供給される。また、ＲＦアンプ１０７からのトラッキングエラー信号、フォーカスエラー信号は、サーボ回路１０９に供給され、絶対位置情報は、アドレスデコーダ１１０に供給されてデコードされ、絶対位置アドレスとして出力される。

サーボ回路１０９は、トラッキングエラー信号、フォーカスエラー信号や、システムコントローラ１１１からのトラックジャンプ指令、アクセス指令、スピンドルモータ１０２の回転速度検出情報等により各種のサーボ駆動信号を発生させ、２軸デバイス１０４及びスレッド機構１０５を制御して、フォーカス及びトラッキング制御を行う。
全体動作は、システムコントローラ１１１により管理されている。システムコントローラ１１１には、操作部１１９から入力が与えられる。

入力端子１２２から入力されるオーディオ信号（アナログオーディオ信号）を記録する場合には、そのアナログオーディオ信号がＡ／Ｄコンバータ１２３に供給される。そしてＡ／Ｄコンバータ１２３で、このオーディオ信号がディジタル化された後、音声圧縮エンコーダ／デコータ１１４に供給される。そして音声圧縮エンコーダ／デコータ１１４で、このオーディオデータがＡＴＲＡＣ方式で圧縮される。
なお、入力端子１２２はいわゆるアナログライン入力用であり、例えば上記ＩＲＤ１２の端子Ｔ４と接続されることで、ＩＲＤ１２からのオーディオ信号を入力できる。

音声圧縮エンコーダ／デコーダ１１４でＡＴＲＡＣ圧縮されたデータは、メモリコントローラ１１２の制御の基に、一旦、ＲＡＭ１３に書き込まれ、そして、ＥＦＭ及びＡＣＩＲＣエンコーダ／デコーダ１０８に供給される。ＥＦＭ及びＡＣＩＲＣエンコーダ／デコーダ１０８で、このオーディオデータにエラー訂正符号が付加され、更に、このデータがＥＦＭ変調される。ＥＦＭ及びＡＣＩＲＣエンコーダ／デコーダ１０８の出力がヘッド駆動回路１２４を介して、磁気ヘッド１２１に供給される。このとき、光学ヘッド１０３からは、ディスクにデータを書き込むために、高レベルのレーザビームが照射される。これにより、ディスク１０１に、ＡＴＲＡＣで圧縮されるたオーディオデータが記録される。

また、このＭＤレコーダでは、ＡＴＲＡＣ方式のデータを直接入力して記録することが可能である。ＡＴＲＡＣのデータは、例えば、ＩＥＥＥ１３９４インターフェース１２５を介して入力される。
即ち上述したＩＲＤ１２のＩＥＥＥ１３９４インターフェース６０と、このＩＥＥＥ１３９４インターフェース１２５が接続されている場合、ダウンロードのために４倍速ＡＴＲＡＣデータが供給されることになる。

ＩＥＥＥ１３９４インターフェース１２５からのＡＴＲＡＣのデータは、ＥＦＭ及びＡＣＩＲＣエンコーダ／デコーダ１０８に供給される。ＥＦＭ及びＡＣＩＲＣエンコーダ／デコーダ１０８で、このオーディオデータにエラー訂正符号の付加、ＥＦＭ変調が施される。そしてＥＦＭ及びＡＣＩＲＣエンコーダ／デコーダ１０８の出力がヘッド駆動回路１２４を介して、磁気ヘッド１２１に供給される。そしてこのとき同様に、光学ヘッド１０３からは、ディスクにデータを書き込むために高レベルのレーザビームが照射され、これにより、ディスク１０１に、ＡＴＲＡＣで圧縮されたオーディオデータが記録される。

また光デジタル入力インターフェース１２８が設けられる。
例えばＩＥＣ９５８による光デジタル入力インターフェース１２８が設けられる場合は、上記ＩＲＤ１２の光デジタル出力インターフェース５９や、他の機器の光デジタル出力インターフェースと接続されることで、デジタルオーディオデータの入力が行われる。
なおその場合は、いわゆるＡＴＲＡＣデータ形態ではないので、入力されたデジタルオーディオデータは音声圧縮エンコーダ／デコーダ１１４でＡＴＲＡＣ形式で圧縮処理された後、ＲＡＭ１１３，ＥＦＭ及びＡＣＩＲＣエンコーダ／デコーダ１０８を介して記録データとされる。

ディスク１０１からの再生時には、光学ヘッド１０３により、ディスク１０１の記録信号が読み出される。この光学ヘッド１０３の出力は、ＲＦアンプ１０７に供給され、ＲＦアンプ１０７からは、再生ＲＦ信号が得られる。この再生ＲＦ信号は、２値化回路１０６を介して、ＥＦＭ及びＡＣＩＲＣデコーダ１０８に供給される。そしてＥＦＭ及びＡＣＩＲＣデコーダ１０８で、再生ＲＦ信号に対して、ＥＦＭ復調処理、ＡＣＩＲＣによるエラー訂正処理が行われる。

ＥＦＭ及びＡＣＩＲＣデコーダ１０８の出力は、メモリコントローラ１１２の制御のもとに、一旦、ＲＡＭ１１３に書き込まれる。なお、光学ヘッド１０３による光磁気ディスク１０１からのデータの読み取り及び光学ヘッド１０３からＲＡＭ１１３までの系における再生データの転送は、１．４１Ｍｂｉｔ／ｓｅｃで、しかも、間欠的に行われる。

ＲＡＭ１１３に書き込まれたデータは、再生データの転送が０．３Ｍｂｉｔ／ｓｅｃとなるタイミングで読み出され、音声圧縮エンコーダ／デコータ１１４に供給される。そしてＡＴＲＡＣ方式の圧縮に対する音声データの伸長処理が行われる。

音声圧縮に対するデコードが行われたデータ、即ち量子化１６ビット、サンプリング周波数４４．１ＫＨｚの形態のデジタルオーディオデータは、Ｄ／Ａコンバータ１１５に供給され、アナログオーディオ信号に変換される。このアナログオーディオ信号が出力端子１１７から外部機器もしくはアンプ・スピーカ等の再生系に出力される。

ここで、ＲＡＭ１１３へのデータの書込み／読出しは、メモリコントローラ１１２によって書込みポインタと読出しポインタの制御によりアドレス指定して行われるが、書込みポインタは１．４１Ｍｂｉｔ／ｓｅｃのタイミングでインクリメントされ、一方、読出しポインタは０．３Ｍｂｉｔ／ｓｅｃのタイミングでインクリメントされていく。この書込みと読出しのビットレートの差により、ＲＡＭ１１３内にある程度データが蓄積された状態となる。ＲＡＭ１１３内にフル容量のデータが蓄積された時点で、書込みポインタのインクリンメトは停止され、光学ヘッド１０３によるディスク１０１からのデータの読出し動作も停止される。但し、読出しポインタのインクリメントは継続して実行されているため、再生音声出力はとぎれることがない。

その後、ＲＡＭ１１３から読出し動作のみが継続されていき、ある時点でＲＡＭ１１３内のデータ蓄積量が所定量以下となったとすると、再び光学ヘッド１１３によるデータ読出し動作及び書込みポインタのインクリメントが再開され、再びＲＡＭ１３のデータ蓄積がなされていく。

このようにＲＡＭ１１３を介して再生オーディオ信号を出力することにより、例えば外乱等でトラッキングが外れた場合などでも、再生音声出力が中断してしまうことがなく、データ蓄積が残っているうちに例えば正しいトラッキング位置までアクセスしてデータ読出しを再開することで、再生出力に影響を与えずに、動作を続行できる。

また記録時には、リアルタイムに入力されるデジタルオーディオ信号又はアナログオーディオ信号は、ＡＴＲＡＣ方式で圧縮された後、ＲＡＭ１１３に一旦蓄積され、その後所定タイミングで記録データとして処理されるべく読み出されていく。たとえば後述するクラスタという単位で読み出され、記録データとして処理される。そして、その処理過程（ＡＣＩＲＣ処理やＥＦＭ処理）では高速レートで処理することは可能である。ところがあくまでも入力は音楽に応じたリアルタイムであるため、例えば楽曲等のディスク１０１への記録にはその楽曲の演奏時間と同じだけの時間がかかることになる。
一方、ＩＲＤ１２から４倍速ＡＴＲＡＣ形式で楽曲データが供給される場合、例えば１つの楽曲としての入力自体が高速で完了することになり、当然その入力レートに応じて処理していけばよいため、ディスク１０１への記録（つまり楽曲等のダウンロード）は非常に短時間に完了できる。例えば演奏時間４分の楽曲であれば１分程度でダウンロードが完了できる。

全体動作を制御するシステムコントローラ１１１に対する操作指示の入力部位としては、操作部１１９、赤外線インターフェース１２７が設けられる。
操作部１１９は各種操作キーやダイヤルとしての操作子が設けられる。操作子としては例えば、再生、録音、一時停止、停止、ＦＦ（早送り）、ＲＥＷ（早戻し）、ＡＭＳ（頭出しサーチ）などの記録再生動作にかかる操作子や、通常再生、プログラム再生、シャッフル再生などのプレイモードにかかるモード操作子、さらには表示部１２９における表示状態を切り換える表示モード操作のための操作子、トラック（プログラム）分割、トラック連結、トラック消去、トラックネーム入力、ディスクネーム入力などの編集操作のための操作子など設けられている。
これらの操作キーやダイヤルによる操作情報はシステムコントローラ１１に供給され、システムコントローラ１１は操作情報に応じた動作制御を実行することになる。

また赤外線インターフェース１２７は、例えば専用の赤外線リモートコマンダーから出力された赤外線コマンド信号を受信／デコードし、システムコントローラ１１１に供給する。リモートコマンダーに操作部１１９と同様の操作キー等が設けられていることで、ユーザーはリモートコマンダーを使用して所要の操作を行うことができる。
また、上記のようにＩＲＤ１２が赤外線インターフェース６６から、当該ＭＤレコーダに対応するコマンド信号形態で赤外線コマンド信号を出力することで、ＩＲＤ１２がＭＤレコーダに対して、各種指示（例えば録音開始／停止、再生など）を行うことができる。

さらに、コントロールラインインターフェース１２６が設けられる場合、ＩＲＤ１２のコントロールラインインターフェース６７と接続されることで、システムコントローラ１１１はＣＰＵ８０との間で各種データ通信を行うことができる。これによってＩＲＤ１２がＭＤレコーダに対して、各種指示（例えば録音開始／停止、再生など）を行うことができる。
なお、上述したようにＩＥＥＥ１３９４インターフェース接続される場合は、ＩＥＥＥ１３９４上でＡＴＲＡＣデータだけでなく各種制御コマンドも送受信できる。従って、コントロールラインインターフェース１２６や赤外線インターフェース１２７を介してＩＲＤ１２がＭＤレコーダを制御するのは、例えばＭＤレコーダがＩＥＥＥ１３９４に対応していない機種の場合に好適なものとなる。

表示部１２９の表示動作はシステムコントローラ１１１によって制御される。
即ちシステムコントローラ１１１は表示動作を実行させる際に表示すべきデータを表示部１２９内の表示ドライバに送信する。表示ドライバは供給されたデータに基づいて液晶パネルなどによるディスプレイの表示動作を駆動し、所要の数字、文字、記号などの表示を実行させる。例えば記録／再生しているディスクの動作モード状態、トラックナンバ、記録時間／再生時間、編集動作状態等が示される。またディスク１０１には主データたるトラック（ＡＴＲＡＣデータとしての楽曲）に付随して管理される文字情報（トラックネーム等）が記録できるが、その文字情報の入力の際の入力文字の表示や、ディスクから読み出した文字情報の表示などが実行される。
また後述するＡＵＸファイルとしてのテキストデータやイメージデータをディスク１０１から読み出した場合は、その表示出力を表示部１２９において実行することができる。

ところで、ディスク１０１に対して記録／再生動作を行なう際には、ディスク１０１に記録されている管理情報、即ちＰ−ＴＯＣ（プリマスタードＴＯＣ）、Ｕ−ＴＯＣ（ユーザーＴＯＣ）を読み出す必要がある。システムコントローラ１１１はこれらの管理情報に応じてディスク１０１上の記録すべきエリアのアドレスや、再生すべきエリアのアドレスを判別することとなる。この管理情報はＲＡＭ１１３に保持される。
そして、システムコントローラ１１１はこれらの管理情報を、ディスク１０１が装填された際に管理情報の記録されたディスクの最内周側の再生動作を実行させることによって読み出し、ＲＡＭ１１３に記憶しておき、以後そのディスク１０１に対する記録／再生／編集動作の際に参照できるようにしている。

また、Ｕ−ＴＯＣはデータの記録や各種編集処理に応じて書き換えられるものであるが、システムコントローラ１１１は記録／編集動作のたびに、Ｕ−ＴＯＣ更新処理をＲＡＭ１１３に記憶されたＵ−ＴＯＣ情報に対して行ない、その書換動作に応じて所定のタイミングでディスク１０１のＵ−ＴＯＣエリアについても書き換えるようにしている。

またディスク１０１にはＡＴＲＡＣデータとしてのトラックとは別にＡＵＸデータファイルを記録することができる。そのＡＵＸデータファイルの管理のためにディスク１０１上にはＡＵＸ−ＴＯＣが形成される。
システムコントローラ１１１はＵ−ＴＯＣの読出の際にＡＵＸ−ＴＯＣの読出も行い、ＲＡＭ１１３に格納して必要時にＡＵＸデータ管理状態を参照できるようにしている。

詳しくは後述するが、ＩＲＤ１２から供給されるＡＴＲＡＣデータをディスク１０１にダウンロードする際には、ＡＴＲＡＣデータに続いて必要なＵ−ＴＯＣデータやその他のテキストデータ、イメージデータなど、ＡＴＲＡＣデータとしての楽曲に付随する情報（付加情報ともいう）も提供される。一連のダウンロード動作としては、ＡＴＲＡＣデータだけでなく、それらの管理／付加情報もＵ−ＴＯＣデータや、ＡＵＸデータファイルとしてディスク１０１に記録されるものである。

１−８．ＭＤのエリア構成
ここで、ＭＤ（ディスク１０１）での記録データの構造及びエリア構成を説明しておく。
ミニディスクシステムでの記録トラックとしては図１８のようにクラスタＣＬが連続して形成されており、１クラスタが記録時の最小単位とされる。１クラスタは２〜３周回トラック分に相当する。

そして１つのクラスタＣＬは、セクターＳFC〜ＳFFとされる４セクターのリンキング領域と、セクターＳ00〜Ｓ1Fとして示す３２セクターのメインデータ領域から形成されている。１セクタは２３５２バイトで形成されるデータ単位である。
４セクターのサブデータ領域のうち、セクターＳFFはサブデータセクタとされ、サブデータとしての情報記録に使用できるが、セクターＳFC〜ＳFEの３セクターはデータ記録には用いられない。
一方、ＴＯＣデータ、オーディオデータ、ＡＵＸデータ等の記録は３２セクター分のメインデータ領域に行なわれる。
なお、アドレスは１セクター毎に記録される。

また、セクターはさらにサウンドグループという単位に細分化され、２セクターが１１サウンドグループに分けられている。
つまり図示するように、セクターＳ00などの偶数セクターと、セクターＳ01などの奇数セクターの連続する２つのセクターに、サウンドグループＳＧ00〜ＳＧ0Aが含まれる状態となっている。１つのサウンドグループは４２４バイトで形成されており、11.61msec の時間に相当する音声データ量となる。
１つのサウンドグループＳＧ内にはデータがＬチャンネルとＲチャンネルに分けられて記録される。例えばサウンドグループＳＧ00はＬチャンネルデータＬ０とＲチャンネルデータＲ０で構成され、またサウンドグループＳＧ01はＬチャンネルデータＬ１とＲチャンネルデータＲ１で構成される。
なお、Ｌチャンネル又はＲチャンネルのデータ領域となる２１２バイトをサウンドフレームとよんでいる。

ディスク１０１のエリア構造を図１９に示す。
図１９（ａ）はディスク最内周側から最外周側までのエリアを示している。
光磁気ディスクとしてのディスク９０は、最内周側はエンボスピットにより再生専用のデータが形成されるピット領域とされており、ここにＰ−ＴＯＣが記録されている。
ピット領域より外周は、光磁気領域とされ、記録トラックの案内溝としてのグルーブが形成された記録再生可能領域となっている。
この光磁気領域の最内周側のクラスタ０〜クラスタ４９までの区間が管理エリアとされ、実際の楽曲等のプログラムが記録されるのは、クラスタ５０〜クラスタ２２５１までのプログラムエリアとなる。プログラムエリアより外周はリードアウトエリアとされている。

管理エリア内を詳しく示したものが図１９（ｂ）である。図１９（ｂ）は横方向にセクター（リンキングセクターは省略）、縦方向にクラスタを示している。
管理エリアにおいてクラスタ０，１はピット領域との緩衝エリアとされている。クラスタ２はパワーキャリブレーションエリアＰＣＡとされ、レーザー光の出力パワー調整等のために用いられる。
クラスタ３，４，５はＵ−ＴＯＣが記録される。Ｕ−ＴＯＣとしては、１つのクラスタ内の各セクターにおいてデータフォーマットが規定され、それぞれ所定の管理情報が記録されるが、このようなＵ−ＴＯＣデータとなるセクターを有するクラスタが、クラスタ３，４，５に３回繰り返し記録される。
１クラスタにはメインセクター領域として３２セクター存在するため、Ｕ−ＴＯＣセクターとしては最高３２種類（Ｕ−ＴＯＣセクター０〜セクター３１）の管理情報記録が設定できる。
実際上、主に用いられているＵ−ＴＯＣセクターは、セクター０，１，２，４であり、Ｕ−ＴＯＣセクター０においては、記録されたトラックの記録位置アドレス、トラックモードなどが管理される。
またＵ−ＴＯＣセクター１，セクター４は、記録されたトラックに対応するトラックネームとなる文字情報の記録に用いられ、さらにＵ−ＴＯＣセクター２は記録されたトラックの録音日時を記録するエリアとされている。

クラスタ６，７，８はＡＵＸ−ＴＯＣが記録される。ＡＵＸ−ＴＯＣとしてのデータにより、ＡＵＸデータファイルの管理が行われる。即ち、テキスト、イメージ等のデータファイルに対するアロケーションテーブルなどのファイル管理情報が記録される。
詳述は避けるが、１つのクラスタ内の各セクターにおいてデータフォーマットが規定され、それぞれ所定のファイル管理情報が記録される。このようなＡＵＸ−ＴＯＣデータとなるセクターを有するクラスタが、クラスタ６，７，８に３回繰り返して記録される。

クラスタ９からクラスタ４６までの領域は、ＡＵＸデータが記録される領域となる。ＡＵＸデータとしてのデータファイルはセクター単位で形成され、後述する静止画ファイルとしてのピクチャーファイルセクタ、文字情報ファイルとしてのテキストファイルセクター、プログラムに同期した文字情報ファイルとしてのカラオケテキストファイルセクター等が形成される。
そしてこのＡＵＸデータとしてのデータファイルや、ＡＵＸデータエリア内でＡＵＸデータファイルを記録可能な領域などは、ＡＵＸ−ＴＯＣによって管理されることになる。

なおＡＵＸデータエリアでのデータファイルの記録容量は、エラー訂正方式モード２として考えた場合に２．８Ｍバイトとなる。
また、例えばプログラムエリアの後半部分やプログラムエリアより外周側の領域（例えばリードアウト部分）に、第２のＡＵＸデータエリアを形成して、データファイルの記録容量を拡大することも考えられる。

クラスタ４７，４８，４９は、プログラムエリアとの緩衝エリアとされる。
クラスタ５０（＝３２ｈ）以降のプログラムエリアには、１又は複数の楽曲等の音声データがＡＴＲＡＣ形式で記録される。
記録される各プログラムや記録可能な領域は、Ｕ−ＴＯＣによって管理される。
なお、プログラム領域における各クラスタにおいて、セクターＦＦｈは、前述したようにサブデータとしての何らかの情報の記録に用いることができる。

２．ダウンロード
２−１．機器接続構成
以上、衛星通信による放送の送信、受信、及びダウンロードを実行するためのシステムについて説明してきたが、以下、ＩＲＤ１２に接続されたストレージデバイス１３に対するダウンロード動作について説明していく。
例えば家庭等で構築される受信設備としては図２で簡単に述べたが、実際にはＩＲＤ１２に対して複数のストレージデバイス１３が接続される場合が考えられる。
複数のストレージデバイス１３が接続される構成例を図２０に示す。

この図２０では、ＩＲＤ１２に対して５つのＩＥＥＥ１３９４対応機器が接続されている例を示している。即ちＭＤレコーダ１３Ａ、１３Ｂ、１３Ｅ、ＶＣＲ１３Ｃ、ＤＶＤプレーヤ１３Ｄである。
これらの機器は。ＩＲＤ１２との間で、ＩＥＥＥ１３９４方式で、各種の制御データやコマンドの通信が可能とされる。
なお、ここではＭＤレコーダ１３Ａ、１３Ｂについては、ＩＥＥＥ１３９４バス１６により送信されてきたＡＴＲＡＣデータの記録にも対応できるものとする。一方、ＭＤレコーダ１３Ｅについては、ＩＥＥＥ１３９４インターフェースにより送信されてきたＡＴＲＡＣデータをそのまま記録できる機能は備えていないものとする。即ちこの場合は、例えばＩＥＥＥ１３９４バス１６、もしくは光デジタルラインなどでデジタルオーディオデータを入力し、ＭＤレコーダ１３Ｅ内部でＡＴＲＡＣ処理を行って記録を行うものとする。

また、ＩＥＥＥ１３９４に対応していない機器として、ＭＤレコーダ１３Ｆ、１３Ｇを示している。
これらは例えば光デジタルラインやアナログラインによりＩＲＤ１２と接続されることで、ＩＲＥ１２からオーディオデータを入力することができる。また、赤外線インターフェースやコントロールライン接続されることで、ＩＲＤ１２による動作制御を受けることも可能となる。

なお、後述するダウンロード動作は、ＭＤレコーダ１３Ａ又は１３Ｂをストレージ機器として用いる例で説明する。即ちＩＲＤ１２はＩＥＥＥ１３９４バス１６によりＡＴＲＡＣデータや各種コマンドをＭＤレコーダ１３Ａ又は１３Ｂに供給し、４倍速ＡＴＲＡＣデータによる高速ダウンロードを実行させるものとする。
但し、高速ではないリアルタイムのダウンロードを行うことを考えれば、後述するダウンロード動作時の処理と同様のダウンロード処理は、他の機器（１３Ｃ〜１３Ｇ）を用いる場合でも可能となる。

２−２．機器接続に関する処理
まずＩＲＤ１２にストレージデバイス１３としての機器が接続された際のＩＲＤ１２の処理を説明していく。
或るストレージデバイスが接続される毎に、ＩＲＤ１２のＣＰＵ８０は、図２４のような接続機器ＩＤテーブルにおいて、その接続機器に関するデータを追加生成していくことになる。なお、この接続機器ＩＤテーブル（以下、ＩＤテーブルという）は不揮発性メモリ６８に保持される。
また接続された機器とＩＲＤ１２との間の通信には、ＩＥＥＥ１３９４で規定されるコマンドが用いられる。

接続の際のＣＰＵ８０の処理を図２１に示す。
ＩＲＤ１２からＩＥＥＥ１３９４バス１６により或るストレージデバイス１３が接続された際には、ＣＰＵ８０の処理は図２１のステップＦ１０１からＦ１０２に進み、ＩＤテーブルへのデータ追加のための処理を開始する。
まずステップＦ１０２では、接続された機器に対してその機器に与えられているＩＤを報せるべくリクエストを行う。ここでいうＩＤとは、いわゆるノードユニークＩＤといわれているもので、機器個体に固有のナンバ（又は文字）として与えられているＩＤコードである。

接続された機器では、ＩＤのリクエストに応じて、その機器固有のＩＤコードをＩＲＤ１２に送信する。
ＣＰＵ８０はＩＤコードの受信をステップＦ１０３で待機しており、ＩＤコードが受信されたらステップＦ１０４に進む。
まずここで受信され取り込まれたＩＤコードと同一のＩＤコードが図２４のようなＩＤテーブル上に存在するか否かを検索する。

新規に或る機器をＩＲＤ１２に接続する場合は、ＩＤテーブルに同一のＩＤコードが登録されていることはない。従って新規接続の場合はステップＦ１０５からＦ１０６に進み、その接続された機器についてＣＰＵ８０がナンバリングを行う。
例えば接続される機器毎に「１」から順にナンバリングを行うとすると、それまで３台の機器が接続されている時点に新たに機器が接続されたら、その機器のナンバは「４」となる。

続いてステップＦ１０７で、接続された機器に対して、機器タイプ、詳細タイプ、ＡＴＲＡＣ入力対応機器であるか否かなど必要な情報を知らせるように順次要求する。
接続された機器では、それらの情報のリクエストに応じて、その機器タイプ、詳細タイプ、ＡＴＲＡＣ入力可否などの情報を送信してくる。
なお、機器タイプとは、「ＶＣＲ機器」と「ディスク機器」を区別するタイプ情報である。例えばアナログＶＣＲ、ＤＶ機器、ＤＶ−ＨＳ機器などがＶＣＲ機器に相当する。一方ＭＤレコーダ、ＣＤプレーヤ、ＤＶＤレコーダ、ハードディスクドライブなどがディスク機器に相当する。
また詳細タイプとは、実際の機器種別の情報となる。例えば「ＭＤレコーダ」「アナログＶＣＲ」「ＤＶＤプレーヤ」などの情報である。

ステップＦ１０８で、これらリクエストした必要な情報が受信されたら、ＣＰＵ８０はステップＦ１０９に進み、その接続された機器に対するニックネームを自動設定する。
後述するが本例では接続機器に対してユーザーが任意のニックネームを設定することができるが、接続時にはまずＣＰＵ８０がデフォルトニックネームを自動設定することになる。例えばＭＤレコーダの場合は「ＭＤ−１」など仮の名称を付与する。

続いてステップＦ１１０では、ＩＤテーブルに、接続機器の情報を追加記憶する。
１つの機器に対応するＩＤテーブル上の情報としては、ステップＦ１０６でナンバリングされた接続機器ナンバ、ステップＦ１０３で受信されたＩＤ、ステップＦ１０８で受信された機器タイプ、詳細タイプ、ＡＴＲＡＣ入力可否、ステップＦ１０９で設定されたデフォルトニックネームとなる。
そしてこれらの情報が図２４のようにＩＤテーブルに書き込まれる。
例えば図２０のうちでＭＤレコーダ１３Ａ、１３Ｂのみが接続されている時点で、新規接続機器としてＶＣＲ１３Ｃが接続されたとすると、図２１の処理により、図２４の３行目として示すデータ、即ち機器ナンバ「３」、ＶＣＲ１３ＣのＩＤ「ｉｄ３」、機器タイプ「ＶＣＲ」、詳細タイプ「アナログＶＣＲ」、デフォルトニックネーム「ＶＣＲ−１」、ＡＴＲＡＣ入力「不可」という各データが記憶される。また、このとき接続状況データが「オン」とされる。

なおこの図２４は、図２０のように５つの機器がＩＥＥＥ１３９４バス１６に接続されており、さらにＭＤレコーダ１３Ａ、１３Ｂ、１３Ｅには既にユーザーがニックネーム登録した後の状態としての例を示している。
このニックネーム登録は、ユーザーが任意に行うものであり、その場合ユーザーはＩＲＤ１２に対して例えばリモートコマンダー６４により、ニックネーム入力モードとしての操作を行う。

いま仮に、５つの機器が接続され、ＩＤテーブルでは全機器がデフォルトニックネームで登録されていたとする。例えば図２０の各機器１３Ａ〜１３Ｅのニックネームが、「ＭＤ−１」「ＭＤ−２」「ＶＣＲ−１」「ＤＶＤ−１」「ＭＤ−３」としてＩＤテーブルに登録されていたとする。
後述するが、ダウンロードを行う時には、ユーザーは予めダウンロードを行う機器を選択する必要がある。この機器選択にはＩＲＤ１２がモニタ装置１４に各接続機器のニックネームを表示してユーザーに選択を促すようにしている。
ここで３台のＭＤレコーダにつきデフォルトニックネームがＩＤテーブルに登録されていると、それぞれ「ＭＤ−１」「ＭＤ−２」「ＭＤ−３」と表示される。この場合、単なる機種名で表示されるよりもユーザーとしては各表示名がどのＭＤレコーダに対応しているか区別がつきやすい。ところが、ユーザーがそのデフォルトニックネームを気に入らなかったり、もしくはより明確に区別できるようにしたいというようなこともある。
そこで、ユーザーが例えば３台のＭＤレコーダ１３Ａ、１３Ｂ、１３Ｅをより区別しやすくするために、各々任意のニックネームをつけるようにし、その場合は、ニックネーム入力モードとする操作を行う。また、過去に登録したニックネームを変更したい場合も同様である。

ニックネーム入力モードとしての操作が行われると、ＣＰＵ８０の処理は図２３のステップＦ１５１からＦ１５２に進み、まずユーザーにニックネーム登録を行う機器の選択要求を行う。例えばモニタ装置１４に、その時点での各機器のニックネーム（デフォルトニックネーム又は過去に登録されたニックネーム）や、必要なき機器種別などを提示して、ユーザーに特定の機器を選択させる。
選択操作が行われたらステップＦ１５３からＦ１５４に進み、モニタ装置１４に、ニックネームの入力要求を行う。
ユーザーはそれに応じてニックネームとなる文字や数字を入力する。そして入力が確定されたら、ステップＦ１５５からＦ１５６に進み、ＩＤテーブルを更新する。即ち選択された機器についてのニックネームデータを、今回入力された文字又は数字に書き換える。例えば図２４のように機器ナンバ「１」のＭＤレコーダ１３Ａに対して、「Ｊｉｍｍｙ」というニックネームが登録される。なお、ユーザーによる文字等の入力は、ＧＵＩ画面とリモートコマンダー６４の操作により実行されるようにすればよい。

このような処理により、図２４に示すように、各機器に対して任意にニックネームを付加することができる。そしてＣＰＵ８０は、何らかの事情でユーザーに対して機器の選択を求める場合には、このＩＤテーブルに登録されたニックネームを表示させて選択させることで、ユーザーにとって機器選択操作をわかりやすいものとすることができる。

ところで、図２４のＩＤテーブルにおける接続状況とは、現在その機器が実際に接続されているか否かを示すデータとなる。
従って一旦接続された機器が、その後接続を外された場合には、接続状況データが更新される。
即ち図２２に示すように、或る機器がＩＥＥＥ１３９４バス１６から外された際には、処理をステップＦ１２１からＦ１２２に進め、その機器に対応するＩＤテーブル上のデータを更新する。具体的には接続状況データを「オフ」に書き換える。
このようにすることで、一旦接続された機器の情報はその後保持できるとともに、実際の接続状況をＩＲＤ１２側から容易に把握できる。

ここで、一旦接続が解かれた機器が、後に再度接続された場合を考える。
機器接続が発生すると、上記図２１の処理が行われるわけであるが、その場合はステップＦ１０４でＩＤテーブルを検索すると、受信ＩＤと同一のＩＤが発見されることになる。その場合は、その接続機器に関してＩＤテーブルに必要な情報は、前回（もしくはそれ以前）の接続時に取り込んでＩＤテーブルに書込済であることになるため、処理をステップＦ１１１に進め、接続状況データを再び「オン」に書き換えるのみでよいことになる。
即ち一旦接続された後、取り外された機器が再度接続された場合には、その機器の機器タイプなどの情報は既に記憶済であるので再度取り込む必要はなく、接続時の処理は簡略化される。
また、ユーザーが過去に、その機器についてニックネーム登録をしていた場合には、その登録されたニックネームも有効データとして扱うことができる（つまり再度の登録操作を必要としない）。
特にこのように接続解除の際もＩＤテーブルのデータ自体は残しておくことで、何度も接続、接続解除が繰り返されるような機器（例えばユーザーが携帯用ＭＤレコーダを用いる場合など）が存在する場合は、非常に有効となる。

以上のようにストレージ機器１３が接続された際（及び接続解除の際）の処理が行われることで、ＩＲＥ１２側では、接続されたストレージ機器１３の機種や状況を的確に判別でき、ダウンロード動作時に適切な処理を行うことができる。
また接続機器に関してユーザーがニックネーム登録を実行できることで、機器選択などの際の操作がわかりやすくなり、またユーザーフレンドリーな楽しみを与えることにもなる。

なお以上の処理はＩＥＥＥ１３９４バス１６に接続される機器について述べたが、図２０のように他のコントロールラインを介してＭＤレコーダ１３Ｇが接続された際などにも適用することができる。

２−３．ダウンロード動作概要
例えば以上のようにＩＲＤ１２に対して各種ストレージデバイス１３が接続されるわけであるが、以下、ＩＲＤ１２が実際にあるストレージデバイス１３に対してダウンロードを実行させる場合の一連の動作概要を図２５、図２６で説明する。なお各手順における詳細な処理については後述する。
またここでダウンロードを実行するストレージデバイス１３としてはＩＥＥＥ１３９４対応でかつＡＴＲＡＣ入力対応のＭＤレコーダ１３Ａ又は１３Ｂとする。

ダウンロードの際にＩＲＤ１２で実行される手順を、図２５、図２６において手順Ｓ１０〜Ｓ１６で示し、またダウンロードの際にストレージデバイス１３（ＭＤレコーダ１３Ａ）で実行される手順を、手順Ｓ２１〜Ｓ２２で示す。
以下、各手順の概略的な内容を説明していく。

［Ｓ１０］
ユーザーがある楽曲のダウンロードを求める場合は、ＩＲＤ１２に対して設定操作を行うことになる。手順Ｓ１０のダウンロード設定処理は、ユーザーの要求するダウンロード動作を設定する処理となり、大まかにいえば、ダウンロードを実行させる機器（ストレージデバイス）の選択、及びダウンロードするコンテンツ（楽曲）の選択を行う。

［Ｓ１１、Ｓ２１］
ＩＲＤ１２が実行する手順Ｓ１１は、ダウンロード実行のためのチェック／指示処理であり、これは手順Ｓ１０で設定されたダウンロード動作を、選択されたストレージデバイス１３側で実行可能な状態にさせる指示、及び実行可能な状態か否かをチェックする処理となる。
このチェック／指示のためにＩＲＤ１２はストレージデバイス１３にコマンドを送り、所定の動作を実行させ、もしくは所要の応答を受ける。
このときストレージデバイス１３側で実行される手順Ｓ２１はチェック／指示に対する設定、応答処理であり、つまりＩＲＤ１２から送られてくるコマンドに応じた設定動作もしくは応答を実行する。

［Ｓ１２、Ｓ２２］
ＩＲＤ１２は上記手順Ｓ１１でダウンロード実行可能を確認したら、手順Ｓ１２としてダウンロードセットアップ指示を行う。ここではまず、ストレージデバイス１３に対して、ダウンロードモードへの移行を要求する。
詳しくは後述するが、ここでダウンロードモードの指示とは、ストレージデバイス１３が動作状態が変化した際にＩＲＤ１２にそれを伝えるべく要求と、実際のセットアップ状態とする指示となる。
このような指示に応じてストレージデバイス１３側では手順Ｓ２２としてダウンロードセットアップ処理を行う。例えばセットアップとして録音待機状態（例えばディスク１０１に対して録音開始する位置での録音ポーズ）とするとともに、その後状態（ステイタス）変化が発生したときにはＩＲＤ１２に報告するモードとする。
さらにこのダウンロードモード下では、ストレージデバイス１３は自分でＡＴＲＡＣデータの開始と終了を判断することになる。

［Ｓ１３、Ｓ２３］
ＩＲＤ１２はダウンロードの際には、ＡＴＲＡＣデータに関しては、単にダウンロードすべく選択された楽曲としてのＡＴＲＡＣデータをＩＥＥＥ１３９４インターフェース６０で選択させて出力させるのみである。つまり図６に示したような受信データの中から該当するチャンネルの４倍速ＡＴＲＡＣデータを出力させる。
これに対して、ＡＴＲＡＣデータが入力されるストレージデバイス１３側では、ＡＴＲＡＣデータの先頭となるＴＳパケットを検出すると、実際の記録動作（ダウンロード）を開始する。
またダウンロード実行中はそのＡＴＲＡＣデータの終端となるＴＳパケットを監視しており、終端となったら記録を終了する。
このようにストレージデバイス１３では手順Ｓ２３として実際のＡＴＲＡＣ記録処理を行う。その開始／終了はＴＳパケットの監視に基づいて行うものとなる。
一方、このときＩＲＤ１２側では、記録動作にステイタス変化したことの報告（ＲＥＣスタート報告）を受けることで、ダウンロードが開始されたことを認識する。
また、停止状態にステイタス変化したことの報告（ＲＥＣエンド報告）を受けることで、ＡＴＲＡＣデータのダウンロードが終了されたことを認識する。
この間、図示していないが、後述するようにダウンロード進捗状況の表示及びそのためのデータ要求などを行うことになる。この間の処理が手順Ｓ１３（ＡＴＲＡＣ記録対応処理）となる。

［Ｓ１４、Ｓ２４］
ＩＲＤ１２は、ＲＥＣエンド報告を受けることで、ＡＴＲＡＣデータのダウンロードが終了されたことを認識したら、手順Ｓ１４の管理／付加情報の記録指示処理を行う。ここでは、ストレージデバイス１３側に管理情報や付加情報の記録を指示するとともに、必要なデータを提供する。ＭＤレコーダ１３Ａの場合は、Ｕ−ＴＯＣデータ、ＡＵＸ−ＴＯＣデータ、ＡＵＸデータの記録指示及び必要なデータを送信することになる。
これに応じてストレージデバイス１３では手順Ｓ２４で、指示に応じた管理情報や付加情報の記録を実行する。

［Ｓ１５、Ｓ２５］
管理情報／付加情報の記録が完了したら、一連のダウンロードは終了される。このためＩＲＤ１２は手順Ｓ１５としてダウンロードの終了を指示し、一方ストレージデバイス１３ではそれを受けてダウンロードモードから抜ける。

［Ｓ１６、Ｓ２６］
以上が通常のダウンロードのための処理手順であるが、ダウンロード実行中、即ちストレージデバイス１３が手順Ｓ２３を実行しているときに、ストレージデバイス１３が記録しているＡＴＲＡＣデータに関するエラーを検出することがある。もちろんストレージデバイス１３に何らかの障害が発生し、記録動作が良好に実行できなくなることもあり得る。
このように何らかのエラーが発生した場合は、そのままエラーを見過ごしてダウンロードを続行することは適切ではない。特にユーザーに有償で楽曲をダウンロードさせる（つまり楽曲の販売）ことを考えれば、エラーが発生した場合は何らかの適切な処置が必要になる。

そこで図２６に示すように、何らかのエラーが発生した場合は、ストレージデバイス１３は手順Ｓ２３においてエラーが発生した旨をＩＲＤ１２に報告する。
そして、これを受けてＩＲＤ１２は手順Ｓ１６のエラー処理を行う。この処理は、リトライが可能かどうかの判別、可能な場合のリトライへの移行、不能の場合のダウンロード中止という処理となる。
一方、ストレージデバイス１３側では手順Ｓ２６としてリトライ準備処理を行っておく。
そしてリトライが可能な場合は、ＩＲＤ１２及びストレージデバイス１３は、それぞれ手順Ｓ１２、手順Ｓ２２に戻り、以降、ダウンロードのリトライを実行する。

以上図２５、図２６のようにダウンロードとしての一連の動作がＩＲＤ１２とストレージデバイス１３の間で所要の通信が行われながら実行されていく。
以下、各手順での詳細な処理例を説明していく。なお、以下説明していく処理における各種通信には、ＩＥＥＥ１３９４方式のＡＶ／Ｃコマンドなどが利用されればよい。但し、本例の通信のために新規設定されるコマンドも含まれる。新規設定されるコマンドとは、例えば後述するダウンロードセットアップコマンド、ダウンロードモードへの移行指示のコマンド、ダウンロード終了指示のコマンドなどである。
また、説明する処理はあくまでも一例であり、具体的な処理方式は多様に考えられることはいうまでもない。

２−４．ダウンロード設定処理
手順Ｓ１０としてのダウンロード設定処理を図２７で説明する。
ユーザーがある楽曲のダウンロードを求める場合は、まずＩＲＤ１２に対して設定操作を行うことになるが、この場合、例えば図４（ｂ）で説明したような画面を表示させた状態で操作を行う。
なお、ダウンロードとしては設定直後にダウンロードを開始する場合と、設定操作として後の時点でのダウンロードを実行させる予約録音操作とがある。いづれの場合も設定処理としては概略同様となる。
設定開始のための何らかの操作をユーザーが行うと、ＣＰＵ８０は図２７のステップＦ２０１からＦ２０２に進み、ダウンロード設定処理を開始する。ここで何らかの操作とは、例えば図４（ｂ）におけるダウンロードボタン２８もしくは予約録音ボタン２５を押す操作としてもよいし、ＧＵＩ画面として設定のための専用ボタンを用意し、それを押すようにしてもよい。

まずステップＦ２０２では、ＣＰＵ８０はＩＥＥＥ１３９４接続機器の中からダウンロード対象となる機器をリストアップする。
本例では、ダウンロード対象機器をＭＤレコーダに限定するものとする。
ここでのリストアップは図２４に示したＩＤテーブルを利用する。即ちＩＤテーブルからダウンロード対象機器となり得る機器をリストアップする。リストアップ条件は各種考えられるが、例えば本例のようにダウンロード対象機器をＭＤレコーダに限定する場合は「ＭＤレコーダ」という条件とする。すると例えば、図２０のＭＤレコーダ１３Ａ（Ｊｉｍｍｙ）、ＭＤレコーダ１３Ｂ（Ｅｒｉｃ）、ＭＤレコーダ１３Ｅ（Ｊｅｆｆ）がリストアップされる。

続いてステップＦ２０３では、もしＩＥＥＥ１３９４バス以外のコントロールラインで接続された機器が存在する場合は、その中で同様にダウンロード対象機器となり得る機器をリストアップする。この場合、コントロールライン接続機器についても、接続時に図２４のようなＩＤテーブルが作成されていれば、それを利用する。ＩＤテーブルが作成されていないものである場合は、接続機器に対して機器種別（詳細タイプ）を尋ねて、該当機器をリストアップする。例えば図２０におけるＭＤレコーダ１３Ｇがリストアップされる。

続くステップＦ２０４では、ＩＲＤ１２が赤外線コマンドにより制御可能な機器出会って、ダウンロード対象機器となり得る機器をリストアップする。この場合はＣＰＵ８０は接続機器を判別できないため、例えばユーザーに入力を求めることとなる。もしくはあらかじめユーザーに赤外線制御可能機器の登録を要求するものとし、その登録データにより判別する。

少なくともステップＦ２０２のリストアップが行われ、また必要に応じてステップＦ２０３，Ｆ２０４のリストアップが行われることで、ダウンロード対象機器としての例えば全ＭＤレコーダがリストアップされる。そこでステップＦ２０５で、リストアップされた機器（ＭＤレコーダ）をモニタ装置１４に表示し、どの機器にダウンロードを実行させるかをユーザーに選択させる。例えば図２８のように機器リスト２１Ｅを表示して選択を促す。
ここで、機器の表示では、上述したニックネームを用いるようにすることで、ユーザーにとって非常に選択操作がわかりやすいものとなる。もちろんニックネームだけでなく、実際の機種名、型番などを同時に表示させてもよい。

なお、ステップＦ２０５までのリストアップ処理及び機器リスト２１Ｅの表示態様は、多様な例が考えられる。
まずリストアップについては、ＭＤレコーダであることを前提とすると、実際にその時点で接続されているＭＤレコーダのみとしてもよい。即ち図２４のＩＤテーブルから、詳細タイプが「ＭＤ」であって接続状況が「オン」の機器を抽出する。
さらに、ＡＴＲＡＣ入力対応機器のみというような条件を付けてもよい。
またＩＥＥＥ１３９４接続機器に限定してステップＦ２０３、Ｆ２０４は実行しなくてもよい。

また、リストアップ条件にもよるが、機器リスト２１Ｅの表示例としては、図２９のように接続中の機器と非接続の機器を分けて表示してもよい。例えばこの図の場合は、ＭＤレコーダ１３Ｅ（Ｊｅｆｆ）、ＭＤレコーダ１３Ｆ（ＭＤ−４）、ＭＤレコーダ１３Ｇ（ＭＤ−５）が、その時点では接続されていなかった場合である。

図３０は、リストアップ条件としてはＡＴＲＡＣ入力対応を問わないが、表示する際にはＡＴＲＡＣ入力対応であるか否かによる動作の違いをユーザーに認識させるようにしている例である。
即ちＡＴＲＡＣ入力対応の場合は、ＩＥＥＥ１３９４インターフェースを介して４倍速ＡＴＲＡＣデータが入力されるため、ダウンロードの所要時間は通常のリアルタイム録音より短時間となる。従ってユーザーにとっては、ＡＴＲＡＣ入力対応であるか否かはダウンロード時間の長短という影響があらわれるため、図示するようにＡＴＲＡＣ入力対応機器の場合は例えば高速でダウンロードが完了できることを示す表示を行う。

図３１は、機器リスト２１Ｅの表示としては、接続された全機器が一応表示されるようにした例である。ただし選択可能なのはリストアップされたＭＤレコーダのみとするため、ＶＣＲ−１、ＤＶＤ−１など他の機種の表示については、選択不能な非アクティブ状態で表示するようにしている。

もちろんさらに多様なリストアップ方式や表示態様が考えられるが、いずれにしてもユーザーの機器選択操作に好適な方式が採用されればよい。

以上のような機器リスト２１Ｅの表示に対して、ユーザーはダウンロードさせたい機器にカーソルを合わせて決定操作を行う。
するとＣＰＵ８０の処理はステップＦ２０６からＦ２０７に進み、選択された機器をダウンロード実行機器として決定する。

続いて、ステップＦ２０８で、ダウンロードするコンテンツをリスト表示し、ユーザーに選択を要求する。例えば図４（ｂ）のようにその時点でダウンロード可能な曲目を表示する。
またユーザーが予約録音としての設定を行っているのであれば、それ以降の時点でダウンロード可能な曲目を、ユーザーの操作に応じて表示していく。

なお、図４の説明において述べたように、ユーザーは或る曲目を選択して試聴した後に、それをダウンロードするべく操作を行うことがある。その場合は既にダウンロードするコンテンツが決定されているため、ステップＦ２０８、Ｆ２０９の処理は不要となる。

ユーザーがコンテンツを選択する操作を行ったら、処理はステップＦ２０９からＦ２１０に進み、選択されたコンテンツをダウンロードするコンテンツとして決定する。
そしてユーザーが実行操作（例えばダウンロードボタン２８もしくは予約録音ボタン２５を押す操作）が行われたら、ステップＦ２１１から手順Ｓ１１に進むことになる。
以上の図２７の処理で、手順Ｓ１０としての設定処理、即ちダウンロードする機器とダウンロードするコンテンツの設定が完了されたことになる。なお以下、ダウンロードする機器としてＭＤレコーダ１３Ａが選択されたとして説明を続ける。

２−５．ダウンロード実行前のチェック処理
ＩＲＤ１２の手順Ｓ１１としてのダウンロード実行のためのチェック／指示処理の例を図３２〜図３５に示す。
ここでＩＲＤ１２は、手順Ｓ１０で選択されたＭＤレコーダ１３Ａが、ダウンロード動作可能な状態であるかのチェックを行うことになる。

まず図３２のステップＦ３０１では選択された機器、即ちＭＤレコーダ１３Ａが電源オフの状態であるか否かを判別する。
そして電源オフであったのならステップＦ３０２に進んで、電源をオンとする指示としてのコマンドをＭＤレコーダ１３Ａに送信する。これに応じてＭＤレコーダ１３Ａのシステムコントローラ１１１は、パワーオン制御を行う。
電源オンであった場合は、ステップＦ３０１からＦ３０３に進む。

続いてステップＦ３０３では、ＭＤレコーダ１３Ａ（システムコントローラ１１１）に対して入力切換を指示するコマンドを発行する。ＭＤレコーダ１３Ａには、図１７からわかるように複数のオーディオ入力系を備えている。そこで、ＡＴＲＡＣデータのダウンロードのために、ＭＤレコーダ１３Ａに対して、ＩＥＥＥ１３９４インターフェース１２５を介して入力されるＡＴＲＡＣデータについての入力処理を行うべく、入力系統の指示を行うものである。

続いてステップＦ３０４以降は、ダウンロード記録を行うメディア自体（ディスク１０１）のチェックを行うことになる。
まずステップＦ３０４では、ＭＤレコーダ１２５に対してディスク１０１が装填されているか否かを尋ねるコマンドを発行する。
これに対してシステムコントローラ１１１は、ディスク装填状況をチェックし、ディスク１０１の有無の情報を送信してくるが、ＣＰＵ８０はその情報の受信があったら、ステップＦ３０５からＦ３０６に進み、応答内容を判別する。そして応答内容が「ディスク装填」であればステップＦ３０６に進むが、「ディスク未装填」であったのなら、1で示すように図３３のステップＦ３２１に進んで、表示処理部５８によりユーザーへのメッセージ及び必要な動作要求をモニタ装置１４に実行させる。

例えばモニタ装置１４に「ＭＤレコーダ「Ｊｉｍｍｙ」にディスクが装填されていません。ディスクを入れてください」などというようなメッセージを表示させる。そしてステップＦ３２２で変数ｎ＝１にセットして、ステップＦ３２３〜Ｆ３２７のループに移る。
ここでは、ステップＦ３２３でＭＤレコーダ１２５に対してディスク１０１が装填されているか否かを尋ねるコマンドを発行し、ステップＦ３２４で受信待機、ステップＦ３２５で受信内容の判別を行っていく。

そしてこのような処理をステップＦ３２７で変数ｎをインクリメントしながら、ステップＦ３２６で変数ｎが或る設定値Ｍ１を越えたと判断されるまで繰り返し実行する。
即ち、ユーザーはステップＦ３２１で表示されるメッセージを読んだら、ディスク１０１をＭＤレコーダ１３Ａに装填することになるが、装填された後の時点では、ステップＦ３２４で受信されるシステムコントローラ１１１からの応答は「ディスク装填」の情報となる。その場合はディスク１０１の装填が確認されたことになり、ステップＦ３２５から2で示すように次のチェック処理である図３２のステップＦ３０７に進む。

ところが、その場にユーザーがいなかったり、もしくはディスク１０１を装填しなかったなど、何の対応もとらなかった場合は、或る時点で図３３のステップＦ３２６で肯定結果が出る。ＣＰＵ８０はこれをタイムオーバとし、ステップＦ３２８でダウンロード禁止処理を行う。つまり上記手順１０で設定されたダウンロード動作の実行の保留又はキャンセルを行う。
そしてステップＦ３２９で、ユーザー宛てのメッセージをモニタ装置１４に表示させ、ディスク未装填によりダウンロード動作が禁止されたことを伝えるようにする。

一方、ディスク装填状態であって図３２のステップＦ３０７に進むと、ＣＰＵ８０は装填されているディスク１０１がライトプロテクト状態でないか否かのチェックを行う。即ちミニディスクカートリッジ上のライトプロテクト用のスライドレバーがプロテクト位置とされていないかどうかのチェックである。

このためステップＦ３０７では、ＭＤレコーダ１２５に対してディスク１０１のプロテクト状況を尋ねるコマンドを発行する。
これに対してシステムコントローラ１１１は、ディスク１０１のプロテクト状況をチェックし、プロテクト状況の情報を送信してくるが、ＣＰＵ８０はその情報の受信があったら、ステップＦ３０８からＦ３０９に進み、応答内容が「非プロテクト（記録可能）」であればチェックＯＫとしてステップＦ３１０に進む。ところが、応答内容が「プロテクト」であったのなら、3で示すように図３４のステップＦ３４１に進んで、表示処理部５８によりユーザーへのメッセージ及び必要な動作要求をモニタ装置１４に実行させる。

例えばモニタ装置１４に「ディスクがライトプロテクトされています。プロテクトを解除してください」などというようなメッセージを表示させる。
そしてステップＦ３４２で変数ｎ＝１にセットして、ステップＦ３４３〜Ｆ３４７のループに移る。

ライトプロテクトを解除するには、ユーザーは一旦ディスク１０１を取り出してカートリッジ上のスライドレバーを移動させ、再度装填するか、もしくは他のディスク１０１を装填することになる。即ちいづれにしてもまずユーザーは現在装填されているディスク１０１をイジェクトする必要がある。
そこで、ユーザーが対応処理を行うか否かの確認のために、ステップＦ３４３でＭＤレコーダ１２５に対してディスク１０１が装填されているか否かを尋ねるコマンドを発行し、ステップＦ３４４で受信待機、ステップＦ３４５で受信内容の判別を行っていく。
この処理をステップＦ３４７で変数ｎをインクリメントしながら、ステップＦ３４６で変数ｎが或る設定値Ｍ２を越えたと判断されるまで繰り返し実行する。

ユーザーはステップＦ３４１で表示されるメッセージを読んだら、まずディスク１０１をＭＤレコーダ１３Ａから取り出すため、その時点でステップＦ３４５でディスクが排出されたことが検出される。
このときは、ディスク１０１が装填されていない状態になるため、上記の図３３のステップＦ３２１に進むことになる。
そしてディスク装填が確認されたら、再度図３２のステップＦ３０７に進んで、ライトプロテクト状態のチェックを行う。

なお、図３４の処理中にユーザーが何の対応もとらなかった場合（ディスクがイジェクトされなかった場合）は、或る時点でステップＦ３４６で肯定結果が出る。ＣＰＵ８０はこれをタイムオーバとし、ステップＦ３４８でダウンロード禁止処理を行う。つまり上記手順１０で設定されたダウンロード動作の実行の保留又はキャンセルを行う。
そしてステップＦ３４９で、ユーザー宛てのメッセージをモニタ装置１４に表示させ、ディスクがライトプロテクトされているためダウンロード動作が禁止されたことを伝えるようにする。
なお、ユーザーが一旦ディスクを取り出したが、その後、或る時間を経過しても再度ディスクを装填しなかった場合は、上記図３３のステップＦ３２８，Ｆ３２９に進み、ダウンロードが中止されることになる。

ディスク１０１のライトプロテクトのチェックがＯＫとなると、続いて図３２のステップＦ３１０から、ディスク１０１の記録容量のチェックが行われる。
これは、ダウンロードするコンテンツに対して十分な記録容量がディスク１０１に残されているか否かのチェックとなる。

このためステップＦ３１０では、ＭＤレコーダ１２５に対してディスク１０１の残容量を尋ねるコマンドを発行する。
これに対してシステムコントローラ１１１は、ディスク１０１のＵ−ＴＯＣデータから記録可能な残り容量をチェックし、その情報を送信してくるが、ＣＰＵ８０はその情報の受信があったら、ステップＦ３１１からＦ３１２に進む。そして、上記手順Ｓ１０で選択されたコンテンツに必要な容量と、受信された残り容量を比較し、コンテンツのダウンロードのために十分な容量が残っているか否かを判断する。
そして残っていればチェックＯＫとして、手順Ｓ１１としての一連のチェック処理を終える。

ところが、十分な容量が残っていないと判断されたのであれば、4で示すように図３５のステップＦ３６１に進んで、表示処理部５８によりユーザーへのメッセージ及び必要な動作要求をモニタ装置１４に実行させる。
例えばモニタ装置１４に「ディスクに十分な容量がありません。ディスクを入れ換えるか、不要なトラックを消去してください」というようなメッセージを表示させる。
そしてステップＦ３６２で変数ｎ＝１にセットして、ステップＦ３６３〜Ｆ３７０のループに移る。

この場合のユーザーの対応としては、ディスクを入れ換えるか、もしくはＭＤレコーダ１３Ａ側の操作での編集処理により、不要なトラックを消去することになる。
そこで、まずユーザーがディスク入れ換えを行う可能性を考えて、ステップＦ３６３でＭＤレコーダ１２５に対してディスク１０１が装填されているか否かを尋ねるコマンドを発行し、ステップＦ３６４で受信待機、ステップＦ３６５で受信内容の判別を行っていく。
もしユーザーがディスク１０１を入れ換える場合は、まずディスク１０１をＭＤレコーダ１３Ａから取り出すため、その時点でステップＦ３６５でディスクが排出されたことが検出される。
このときは、ディスク１０１が装填されていない状態になるため、上記の図３３のステップＦ３２１に進むことになる。
そしてディスク装填が確認されたら、再度図３２のステップＦ３０７に進んで、ライトプロテクト状態のチェックからチェックをやり直す。

一方、ユーザーがトラック消去を行う場合も考えられるため、ステップＦ３６６でＭＤレコーダ１２５に対してディスク１０１の記録可能容量を尋ねるコマンドを発行し、ステップＦ３６７で受信待機、ステップＦ３６８で上記ステップＦ３１２と同様の判別（ダウンロードするコンテンツに十分な容量が確保されたか否かの判別）を行っていく。

ユーザーがＭＤレコーダ１３Ａで編集操作を行ってトラックを消去していくことで、或る時点でステップＦ３６８で十分な容量が確保されてたことが判別される。その場合は容量チェックＯＫとなり、5として示すように図３２に戻り、手順Ｓ１１としての一連のチェック処理を終えることになる。

この図３５のステップＦ３６３〜Ｆ３７０の処理は、ステップＦ３７０で変数ｎをインクリメントしながら、ステップＦ３６９で変数ｎが或る設定値Ｍ３を越えたと判断されるまで繰り返し実行する。
従ってユーザーが何の対応もとらなかった場合（ディスク入換もしくはトラック消去を行わなかった場合）は、或る時点でステップＦ３６９で肯定結果が出る。ＣＰＵ８０はこれをタイムオーバとし、ステップＦ３７１でダウンロード禁止処理を行う。つまり上記手順１０で設定されたダウンロード動作の実行の保留又はキャンセルを行う。
そしてステップＦ３７２で、ユーザー宛てのメッセージをモニタ装置１４に表示させ、ディスクが容量不足のためダウンロード動作が禁止されたことを伝えるようにする。
なお、ユーザーが交換のために一旦ディスクを取り出したが、その後、或る時間を経過しても再度ディスクを装填しなかった場合は、上記図３３のステップＦ３２８，Ｆ３２９に進み、ダウンロードが中止されることになる。

以上の図３２〜図３５の処理により、ダウンロードの実行にあたって、確実にダウンロードが実行できるか否かのチェックが行われる。従ってユーザーのディスクの入れ忘れや、ライトプロテクトの状況、残り容量などが原因となってダウンロードに失敗するという事態は防止される。

また、例えばユーザーがその場にいない場合などであって、対応処置がとれない場合にはダウンロードが実行されないことになる。
特にこれらのチェックは、ダウンロード開始前に絶対にダウンロードが失敗する状況をチェックするという意味になり、失敗となるダウンロードが開始されることを防止するものであるため、ユーザーが対応できない際のダウンロード中止は非常に適切な処理となる。また特にダウンロードに対しては課金が発生するものであるため、失敗がわかっているダウンロードを防止することは非常に重要となる。

ところで、各チェックによりＯＫとならなかった場合の対応処理としては、ユーザーに所要の処置を求めることとしたが、さらに必要な制御を自動的に行うことも考えられる。
例えば、ＭＤレコーダ１３Ａがディスクチェンジャーシステムを装備しているような場合は、ディスクの装填や交換をＩＲＤ１２が指示して自動的に実行させるようにしてもよい。
また、ディスク１０１の記録可能容量が十分でない場合は、ＩＲＤ１２が自動的にトラック消去をＭＤレコーダ１３Ａ側に指示し、消去を実行させるようにしてもよい。但しこの場合は、モニタ装置１４上にメッセージを出し、ユーザーに消去を行ってもよいか否かを尋ねるようにすることが適切である。

また、チェック内容としては、上記の例以外に、例えばＭＤレコーダ１３Ａが他の動作状態であるか否かのチェックなども考えられる。
例えばＭＤレコーダ１３Ａが録音動作や再生動作を行っている場合には、今回実行しようとするダウンロードとどっちを優先させるかを判断しなければならない。
そこでＩＲＤ１２はＭＤレコーダ１３Ａの動作状況をチェックし、録音／再生などの動作中であれば、ユーザーにどちらを優先させるかの判断を求めるようにする。

なお、ＭＤレコーダ１３Ａ側のシステムコントローラ１１１による手順Ｓ２１については詳述を避けるが、上記図３２〜図３５におけるＣＰＵ８０の処理におけるコマンドに対応した制御や通信処理を行うものとなるものであって、上記説明中に述べたとおりである。

２−６．ダウンロードセットアップ
続いて手順Ｓ１２としてのＩＲＤ１２のＣＰＵ８０のダウンロードセットアップ指示処理、及び手順Ｓ２２としてのＭＤレコーダ１３Ａのシステムコントローラ１１１のダウンロードセットアップ処理について、図３６で説明する。

上記手順Ｓ１１までが完了すると、ＣＰＵ８０の処理は図３６のステップＦ４０１に進む。ここで、例えば上記図２７のダウンロード設定処理において、ステップＦ２１１の実行操作が図４のダウンロードボタン２８を押す操作であった場合は、そのまますぐにダウンロードを実行することになる。一方、ステップＦ２１１の実行操作が予約録音ボタン２５を押したものであった場合は、予約されたコンテンツの放送のある時間まで待機してからダウンロードを実行することになる。

従って、予約設定であった場合は、図３６のステップＦ４０１からＦ４０２に進み、タイマ６９による現在日時の監視処理に入る。そして、予約時刻（予約設定されたコンテンツとしての楽曲が放送される日時）となったら、ステップＦ４０３からＦ４０４に進み、ダウンロードセットアップ指示に移る。
一方、予約設定ではない場合はステップＦ４０１からすぐにＦ４０４に進む。

ステップＦ４０４からは実際にダウンロードを実行すべく、ＭＤレコーダ１３Ａに対するセットアップ指示を開始する。
まずステップＦ４０４で、ＣＰＵ８０はＭＤレコーダ１３Ａに対してステイタス変化報告要求を行う。
この要求は、ＭＤレコーダ１３Ａのシステムコントローラ１１１に対して、ダウンロードモードに入っている期間には、ＭＤレコーダ１３Ａにおいて何らかの状態変化（例えば録音ポーズから録音状態への変化など）があった場合には、その都度、そのステイタス変化を報告するように要求するものである。

このようなステイタス変化報告要求があったら、システムコントローラ１１１側では処理をステップＦ４５１からＦ４５２に進め、ダウンロードモード期間中はステイタス変化を報告するように通信モードをセットする。そしてその動作を行ったら、ステップＦ４５３でステイタス変化報告要求を了承した旨の報告をＣＰＵ８０に対して行う。

ＣＰＵ８０は、ステップＦ４０５で了承報告を受けたら、続いてステップＦ４０６でシステムコントローラ１１１に対してダウンロードセットアップ指示を行う。
このセットアップ指示は、システムコントローラ１１１がダウンロードの開始準備として、ダウンロードモードに移行すること、ディスク１０１上での記録を開始する位置にアクセスしてそこで録音ポーズ状態で待機すること、及び、それ以降は、システムコントローラ１１１側で入力されてくるＡＴＲＡＣデータを監視し、その監視結果に応じてダウンロード記録動作の開始、終了を実行すべきこと、を求めるコマンドとなる。
またセットアップ指示を行ったら、ステップＦ４０７で、ＩＥＥＥ１３９４インターフェース６０から、ダウンロードするコンテンツとしてのＡＴＲＡＣデータの出力を開始させる。つまり、例えば受信される１０チャンネルのＡＴＲＡＣデータのうちから選択されたチャンネルのＡＴＲＡＣデータのみを出力させるようにする。

ＣＰＵ８０のステップＦ４０６によるセットアップ指示があると、システムコントローラ１１１では、処理をステップＦ４５４からＦ４５５に進め、まずダウンロードモード状態にセットするとともに、記録開始位置にヘッド（光学ヘッド１０３及び磁気ヘッド１２１）をアクセスさせ、その位置で録音ポーズ状態とする制御を行う。
続いてステップＦ４５６で、ＩＥＥＥ１３９４インターフェース１２５を介して入力されてくるＡＴＲＡＣデータの監視処理を開始する。
ダウンロードモード中にシステムコントローラ１１１が行うＡＴＲＡＣデータの監視処理としては、図１２、図１３に示したＴＳパケット単位での監視処理であり、具体的には、図１３に示したデータスタートインジケータ、データエンドインジケータ、ＰＥＳデータカウンタ、プレゼントＰＥＳナンバの監視、及び図１２のトランスポートパケットヘッダにおけるトランスポートエラーインジケータの監視となる。
また、ＩＥＥＥ１３９４インターフェース１２５においては入力されるＡＴＲＡＣデータに関して、図１３、図１４で説明したチェックサムデータによるエラー検出も行うことになる。

システムコントローラ１１１は以上のセットアップ処理が完了したら、ステップＦ４５７でセットアップ完了報告を行う。そして手順Ｓ２３に進む。
またＩＲＤ１２のＣＰＵ８０は、このセットアップ完了報告を受けたら、ステップＦ４０８から手順Ｓ１３に進むことになる。

以上のように本例のダウンロードセットアップは、ＩＲＤ１２がＭＤレコーダ１３Ａに対してダウンロード実行の指示を行うものであり、しかもそれはＭＤレコーダ１３Ａ側で自主的にダウンロード記録の開始、終了等を制御することを要求するものとなる。
また、ステイタス変化を報告させるようにすることで、以降開始されるダウンロード動作中に、ＩＲＤ１２側でＭＤレコーダ１３Ａの動作状況を把握できるようにするものとなる。

２−７．ＡＴＲＡＣダウンロード
続いて実際のＡＴＲＡＣデータのダウンロードが行われる手順Ｓ１３、手順Ｓ２３を図３７で説明する。
このダウンロード動作は、上記セットアップ処理により、ＭＤレコーダ１３Ａ側で開始／終了等が制御されることになる。そしてＩＲＤ１２側では、単にダウンロードすべきＡＴＲＡＣデータをＩＥＥＥ１３９４インターフェース６０で選択させて出力させるのみとなる。但し、ダウンロードの進捗状況をユーザーに伝えるための所要の処理を行う。

上記図３６のステップＦ４５６で監視処理を開始した後、ＭＤレコーダ１３Ａのシステムコントローラ１１１は、図３７のステップＦ５５１で、入力されるＡＴＲＡＣデータについてダウンロードする楽曲の開始タイミングを待機している。つまりＴＳパケットにおけるデータスタートインジケータ＝「１」が検出されることを待機する。
そしてその開始タイミングを検出したら、ステップＦ５５２に進み、そのＴＳパケットにおけるＡＴＲＡＣデータからディスク１０１への記録を開始する。そしてこれによってステイタス変化が生じたことになるため、ステップＦ５５３で、そのステイタス変化、つまり録音状態への移行をＣＰＵ８０に報告する。

録音が開始された以降は、システムコントローラ１１１は、ステップＦ５５４でのＡＴＲＡＣデータの終了の監視、ステップＦ５５５でのＣＰＵ８０からの時間データ要求、ステップＦ５５６でのエラー発生状況の監視を継続的に実行することになる。

ステップＦ５５３でのステイタス変化、つまり録音状態への移行が報告されたら、ＣＰＵ８０は、ダウンロードが開始されたことをモニタ装置１４に表示させるとともに、処理をステップＦ５０１からＦ５０２に進め、内部タイマをリセットし、タイムカウントをスタートさせる。これはダウンロード進捗状況表示のための時間データ要求を一定時間毎に実行するためのタイムカウント動作である。
その後、ステップＦ５０３でシステムコントローラ１１１から録音を終了したことを示すステイタス変化の報告の有無の監視、ステップＦ５０４でエラー発生報告の監視、ステップＦ５０５でタイムカウントにより所定時間経過したか否かの監視を行う。

ＭＤレコーダ１３Ａ側で適正にダウンロードが継続されている期間は、その進捗状況をＩＲＤ１２側（モニタ装置１４）で表示する処理を行うが、まずこの処理について説明する。
タイムカウントにより所定時間が経過したことを検出したら、ＣＰＵ８０の処理はステップＦ５０５からＦ５０６に進み、システムコントローラ１１１に対して、現在ダウンロード中のＡＴＲＡＣデータに関する時間データ（ＨＭＳ（時分秒）：楽曲の先頭を０分０秒とした時間データ）を要求する。
システムコントローラ１１１はこの要求があったら、ステップＦ５５５からＦ５５９に進み、現在録音しているＡＴＲＡＣデータの時間位置としての時分秒を確認して、その時間データをＣＰＵ８０に伝える。なお、ＡＴＲＡＣデータは実時間の約４倍速のデータであり、その４倍速ＡＴＲＡＣデータをそのまま録音していくものであるため、報告する時間データは、ダウンロード実行中の実時間ではなく、ＡＴＲＡＣデータを実際に再生演奏する際の実時間に相当する値である。
この時間データは、録音しているディスク上のアドレスや、もしくはＡＴＲＡＣデータに含まれているデータアドレスなどから判別できる。

時間データ（ＨＭＳ）が報告されたら、ＣＰＵ８０はステップＦ５０７からＦ５０８に進み、その時間データに基づいて、モニタ装置１４にダウンロード進捗状況の表示を実行させる。この表示は、例えばそのＡＴＲＡＣデータ（楽曲）の総演奏時間を１００％として、現在の記録時間位置を提示するものである。
表示例を図３８に示す。図３８（ａ）は、例えば図４（ａ）のような表示状態に重ねて、パーセンテージとしてのダウンロード進捗状況表示２１Ｆを実行している例である。
また図３８（ｂ）は、図４（ｂ）のような表示状態において、例えばバーグラフ形態でダウンロード進捗状況表示２１Ｆを実行している例である。
もちろん表示態様は、これら以外に多様に考えられ、いづれにしてもユーザーがその楽曲のダウンロードの完了までの経過状態を把握できるような表示を行うものとすればよい。

ステップＦ５０８で表示制御処理を行ったら、ステップＦ５０２に戻ってタイマのリセット／スタートを行う。そして再び所定時間を経過したら、ステップＦ５０５からＦ５０６、Ｆ５０７、Ｆ５０８の処理を行うことになる。
従って例えば所定時間を１分とすると、表示画面上では１分ごとに進捗状況としてのパーセンテージが上がっていくような表示が行われ、ユーザーにとって、あとどれくらいでダウンロードが完了するかが大まかに把握できることになる。
もちろん表示更新のための所定期間を、例えば３０秒毎、１０秒毎、５秒ごとなど、より短い期間としてもよい。短くするほど、パーセンテージ表示の変化がよりスムースなものとなる。

次にダウンロード記録実行中におけるシステムコントローラ１１１によるエラー監視について説明する。
システムコントローラ１１１は、供給されるＡＴＲＡＣデータのＴＳパケット毎について、図１３に示したＰＥＳデータカウンタとプレゼントＰＥＳナンバを確認している。
この２つの値により、ＴＳパケットの連続性が確認できるため、もし何らかの事情で或るＴＳパケットが入力されなかったような場合は、そのＴＳパケットのＡＴＲＡＣデータの欠落を認識できる。
そこで、そのような連続性エラーが確認された場合は、システムコントローラ１１１の処理はステップＦ５５６からＦ５６０に進み、ＣＰＵ８０に対してエラー発生報告を行う。そして、そのようにエラーが発生したままでダウンロードを続行することは適切でないため、後述する手順Ｓ２６に進むことになる。
一方、エラー発生報告を受けたＣＰＵ８０側では、ステップＦ５０４から後述する手順Ｓ１６に進む。

なお、システムコントローラ１１１が監視するエラーとしては、このようなデータ連続性のチェック以外にも同時に行うようにしてもよい。
例えばＴＳパケットヘッダのトランスポートエラーインジケータを監視していれば、そのＴＳパケットのＡＴＲＡＣデータの信頼性を判断できる。従って信頼性のないＡＴＲＡＣデータが入力された際には、エラー発生と判断するようにしてもよい。
また、ＴＳパケットに含まれるチェックサムデータによるエラー検出も行うため、それによるエラー検出があった場合は、エラー発生とする。

さらに、このように入力されるＡＴＲＡＣデータ上のエラーのみならず、当然ながらＭＤレコーダ１３Ａ側の動作エラー（記録データに影響を与える動作エラー）があった場合も、エラー発生として処理を行うことも考えられる。

ＡＴＲＡＣデータのダウンロードがエラーなく継続されると、或る時点でシステムコントローラ１１１は、ＴＳパケット内のデータエンドインジケータ＝「１」という状態を検出することになる。
それは、そのＴＳパケットが楽曲の最後のＰＥＳパケット内のものであることを意味するため、そのＰＥＳパケットの最後のＴＳパケットを受信した時点で、処理をステップＦ５５４からＦ５５７に進め、その最後のＴＳパケットのＡＴＲＡＣデータを最後としてディスク１０１への記録動作を終了させる。
そしてそれはステイタス変化が生じたことになるため、ステップＦ５５８へ、録音状態から停止状態へステイタス変化が起こった旨の報告を行う。そして手順Ｓ２４に進む。

ＣＰＵ８０では、録音が終了したことを示すステイタス変化報告を受けたら、処理をステップＦ５０３から手順Ｓ１４に進めることになる。

以上のように、手順Ｓ１３、手順Ｓ２３としてダウンロード実行中の処理が行われる。
そしてこのようなダウンロード記録は、開始・終了がＭＤレコーダ１３Ａ側で制御されるため、ＩＲＤ１２側の処理負担は小さいものとなる。つまり、ダウンロード動作に関しては、単にダウンロード対象となったＡＴＲＡＣデータを供給するのみで、後は開始／終了の報告を待っていればよい。

また、記録実行中には、ダウンロード進捗状況をモニタ装置１４で表示させることにより、ユーザーに適切に進捗状況を提示でき、ユーザーにとってダウンロード動作をわかりやすいものとすることができる。
なお、進捗状況の表示に関しては、例えばダウンロード実行中の実経過時間（実際のダウンロード動の経過時間）や、ＡＴＲＡＣデータとしての時間位置（楽曲内での経過時間位置）の一方又は両方を同時に表示するようにしてもよい。
またこの例では４倍速ＡＴＲＡＣデータのダウンロードに関して述べたが、ＡＴＲＡＣ入力非対応の機器（例えば図２０のＭＤレコーダ１３Ｅ、１３Ｆ、１３Ｇなど）で、実時間で供給されるオーディオデータをダウンロードしていく場合にも、当然同様の進捗状況表示を行うことができる。もちろんオーディオデータをストレージデバイス１３に対して低速で供給したり、バースト的に供給するような場合でも、進捗状況表示は可能である。

さらに、ＭＤレコーダ１３Ａ側の表示部１２９など、ストレージデバイス１３側に表示機能がある場合は、その表示機能により同様の進捗状況表示を行うようにしてもよい。その場合は、現在記録しているＡＴＲＡＣデータが何％の時間位置であるかをシステムコントローラ１１１が把握できるようにするため、ＣＰＵ８０がシステムコントローラ１１１に、その楽曲の総演奏時間情報を伝えておく必要がある。

また本例では、何らかのエラーが発生して適正にダウンロードが実行できなくなった場合には、システムコントローラ１１１がＣＰＵ８０にエラー報告するとともに、処理を後述する手順Ｓ１６、Ｓ２６に進めるようにすることで、適切な対応がとれる。

２−８．管理／付加情報のダウンロード及び終了処理
手順Ｓ１４、手順Ｓ２４としての処理例を図３９、図４０で説明する。
上記手順Ｓ１３、手順Ｓ２３により、ＡＴＲＡＣデータのディスク１０１への記録が正常に終了された場合は、続いてそのＡＴＲＡＣデータに関する管理情報や、付加情報をディスク１０１に記録する処理に移る。

通常、ＭＤレコーダ１３Ａでは、ＡＴＲＡＣデータの記録に関するＵ−ＴＯＣセクター０の管理情報、即ちトラックナンバに応じた記録位置としてのスタートアドレス、エンドアドレス、トラックモード等は、記録終了時にそのデータを生成して、Ｕ−ＴＯＣセクター０の更新を行うものであるが、このＩＲＤ１２からの指示によるダウンロードモードの場合は、トラックモードのデータをＩＲＤ１２から受け取ることになる。

即ち図３９のステップＦ６０１で、ＩＲＤ１２のＣＰＵ８０は、ダウンロードしたＡＴＲＡＣデータに関するトラックモードデータをシステムコントローラ１１１に送信する。例えば図１３に示したＦＤＦに記述されたコピーライト、オリジナル／コピー、ステレオ／モノ、エンファシスなどに応じて、８ビットのトラックモードデータ（ミニディスクシステムにおけるＵ−ＴＯＣフォーマットに即したトラックモードデータ）を生成し、送信する。またそれを用いてのＵ−ＴＯＣセクター０の更新の指示を行う。

システムコントローラ１１１では、このようなトラックモードデータ及びコマンドが受信されたら、ステップＦ６５１からＦ６５２に進んで、例えばＲＡＭ１１３に保持している、ディスク１０１に関するＵ−ＴＯＣセクター０の更新を行う。つまり供給されたトラックモードとともに、記録動作にかかるスタートアドレス、エンドアドレスを、今回記録したＡＴＲＡＣデータのトラックナンバに対応させて記述する。

なお実際にディスク１０１上でのＵ−ＴＯＣセクターの書換は、例えばディスク１０１がイジェクトされる際や、ＭＤレコーダ１３Ａの電源がオフとされる際などでよいが、この時点で、実際にディスク１０１上でのＵ−ＴＯＣ更新を行うようにしてもよい。以下説明する他のＵ−ＴＯＣセクターデータやＡＵＸ−ＴＯＣ，ＡＵＸデータなども同様である。但し、ＡＵＸデータに関してはＲＡＭ１１３の容量に鑑みて、ＩＲＤ１２から供給された時点でディスク１０１に書き込むことが適切な場合がある。

システムコントローラ１１１はＵ−ＴＯＣセクター０に関する処理を終えたら、ステップＦ６５３でＣＰＵ８０に対して完了報告を行う。
この完了報告を受けたら、ＣＰＵ８０は処理をステップＦ６０２からＦ６０３に進め、続いてＵ−ＴＯＣセクター１又はセクター４に記述すべきトラックネームデータ（つまり曲名）を送信するとともに、これらＵ−ＴＯＣセクター１以降の処理をシステムコントローラ１１１に指示する。

システムコントローラ１１１では、このようなトラックネームデータ及びコマンドが受信されたら、ステップＦ６５４からＦ６５５に進んで、ＲＡＭ１１３に保持している、ディスク１０１に関するＵ−ＴＯＣセクター１，２，４の更新を行う。つまり供給されたトラックネームデータや、システムコントローラ１１１が把握している現在日時データにより、今回記録したＡＴＲＡＣデータのトラックナンバに対応させてトラックネーム、録音日時等を記述する。
そしてシステムコントローラ１１１はＵ−ＴＯＣセクター１以降のＵ−ＴＯＣセクターに関する処理を終えたら、ステップＦ６５６でＣＰＵ８０に対して完了報告を行う。そして8で示すように図４０のステップＦ６５７以降に進む。
ステップＦ６５７以降ではシステムコントローラ１１１は、ステップＦ６５７でテキストデータ及び記録指示コマンドの受信の監視、ステップＦ６６０でのイメージデータ及び記録指示コマンドの監視、ステップＦ６６３でのダウンロード終了指示の監視を行うことになる。

ステップＦ６５６でシステムコントローラ１１１が発する完了報告を受けたら、ＣＰＵ８０は処理を図３９のステップＦ６０４から7で示すように図４０のステップＦ６０５に進める。
まずステップＦ６０５では、今回ダウンロードしたＡＴＲＡＣデータに付随する付加情報として放送されてきたテキストデータが存在するか否かを確認する。例えば楽曲の歌詞データやアーティストのプロフィール、アルバムのライナーノートのようなテキストデータである。これらのデータは図６に示したように音声付加情報として放送されている。
今回ダウンロードしたＡＴＲＡＣデータに付随するテキストデータが存在しなければステップＦ６０８に進むが、存在すれば、ステップＦ６０６に進んで、システムコントローラ１１１に対してそのテキストデータを送信するとともに記録指示コマンドを発行する。

このようにステップＦ６０６によるテキストデータ及びコマンドが発行された場合は、システムコントローラ１１１はステップＦ６５７からＦ６５８に進み、そのテキストデータを、今回のダウンロードデータとしてディスク１０１に記録されたトラックに対応するＡＵＸテキストファイルのデータとしてディスク１０１のＡＵＸエリアに記録する。もちろんこれに応じて、そのファイルの管理情報となるデータを、ＡＵＸ−ＴＯＣに記述する。
そのような処理が完了したら、ステップＦ６５９でＣＰＵ８０に対して完了報告を行う。ＣＰＵ８０は、ステップＦ６０７で、この完了報告を待ってから、処理をステップＦ６０８に進める。

ＣＰＵ８０はステップＦ６０８では、今回ダウンロードしたＡＴＲＡＣデータに付随する付加情報として放送されてきたイメージデータが存在するか否かを確認する。例えば楽曲のアルバムジャケットやアーティストの写真画像のようなイメージデータである。これらのデータも図６に示した音声付加情報として放送されている。
今回ダウンロードしたＡＴＲＡＣデータに付随するテキストデータが存在しなければステップＦ６１１に進むが、存在すれば、ステップＦ６０９に進んで、システムコントローラ１１１に対してそのイメージデータを送信するとともに記録指示コマンドを発行する。

このようにステップＦ６０９によるイメージデータ及びコマンドが発行された場合は、システムコントローラ１１１はステップＦ６６０からＦ６６１に進み、そのイメージデータを、今回のダウンロードデータとしてディスク１０１に記録されたトラックに対応するＡＵＸイメージファイルのデータとして、ディスク１０１のＡＵＸエリアに記録する。もちろんこれに応じて、そのファイルの管理情報となるデータを、ＡＵＸ−ＴＯＣに記述する。
そのような処理が完了したら、ステップＦ６６２でＣＰＵ８０に対して完了報告を行う。ＣＰＵ８０は、ステップＦ６１０でこの完了報告を待って、処理をステップＦ６１１に進める。

ステップＦ６１１に進む時点で、ＣＰＵ８０での手順Ｓ１４としての処理が終了され、続いて手順Ｓ１５としてのダウンロード終了処理に移る。
即ちステップＦ６１１でダウンロード終了指示のコマンドをシステムコントローラ１１１に送る。

このダウンロード終了指示が受信されると、システムコントローラ１１１でも手順Ｓ２４としての処理が終了され、手順Ｓ２５のダウンロード終了処理として、ステップＦ６６３からＦ６６４に進む。そして一連のダウンロード動作が完了されたとして、ダウンロードモードを終了させる処理を行う。さらに終了処理に伴いステップＦ６６５で、ＣＰＵ８０に対して終了報告を行う。以上によりシステムコントローラ１１１側でのダウンロードモード処理が終了される。
一方ＣＰＵ８０では、ステップＦ６１２で終了報告を待機しており、システムコントローラ１１１からの終了報告があったら、一連のダウンロード処理を終了する。このときモニタ装置１４にダウンロード終了の旨を表示する。

以上の処理からわかるように、本例のダウンロード動作としては、ＡＴＲＡＣデータのダウンロードに付随して、トラックモード、トラックネーム、テキストデータ、イメージデータも、ＩＲＤ１２からＭＤレコーダ１３Ａに供給され、ＡＴＲＡＣデータに関連づけられてディスク１０１に記録されることになる。
即ちダウンロードを楽曲の販売として考えたときに、単なる音声データだけでなく付随する文字や画像データも提供されることで、ユーザーに対するサービスを充実したものとすることができる。
また、特にトラックモードとして放送に重畳されたデータ、例えばコピーライト情報など放送局側（コンテンツ提供側）が付与した情報を記録させることで、著作権保護や好適な再生条件の設定などにも好適である。

２−９．エラー発生時の処理
次に上述したように手順Ｓ１３、手順Ｓ２３においてエラー発生が確認され、手順Ｓ１６、手順Ｓ２６に進んだ場合の処理をず４１で説明する。

まずＩＲＤ１２側では、図３７のステップＦ５０４から手順Ｓ１６に進んだ時には、図４１のステップＦ７０１として、エラーメッセージを表示する制御を行う。即ちモニタ装置１４においてユーザーに対して例えば「ダウンロード中にエラーが発生しました。ダウンロードをやり直します」というようなメッセージを表示させる。
そしてステップＦ７０２で、実際にダウンロードのリトライが可能であるか否かを判別する。
例えばＡＴＲＡＣデータの放送は、図６で説明したように１イベントとしての放送期間内に繰り返し放送されてくるため、ダウンロードが失敗しても、そのイベント期間内であれば、また同じＡＴＲＡＣデータが放送されてくる。従って次にくる同一楽曲の先頭位置となるタイミングからダウンロードリトライが可能である。
ところが、その楽曲についてのイベント内の最後のＡＴＲＡＣデータのダウンロード中にエラーが生じた場合は、リトライ不能となる。
また、発生したエラーが単にデータ上のエラーであればリトライ可能であるが、ＭＤレコーダ１３Ａ側の故障などの場合は、リトライ不能となる場合がある。

ＣＰＵ８０はこれらの事情を判別して、リトライ可能であればステップＦ７０３から手順Ｓ１２に進む。即ち再度ダウンロードセットアップからやり直すようにする。

一方、システムコントローラ１１１側では、エラー発生を検出してステップＦ７５１に進んだ場合は、まずＡＴＲＡＣデータのディスク１０１への記録動作を中止させる。
そしてステップＦ７５２で、途中まで記録されていたＡＴＲＡＣデータを消去された状態とする。なお、実際にはＵ−ＴＯＣセクター０が更新されない限りはディスク１０１に記録が行われたとみなされないため、ここでの処理は現在の記録位置として把握しているアドレスをシステムコントローラ１１１が内部的にクリアするのみでよい。
そして特にＣＰＵ８０からダウンロード中止指示がなければ手順Ｓ２２に進み、手順Ｓ１２としてのＣＰＵ８０からの指示に応じて上述したセットアップ動作を再度行う。
即ちこのような場合は、エラー発生の場合に、一旦ダウンロードが中断されるが、その後リトライが実行されることになる。

ところが上記したような何らかの事情でリトライが不可能である場合は、ＣＰＵ８０は処理をステップＦ７０４に進めて、まずユーザーに対してダウンロード不能のメッセージを提示する。即ちモニタ装置１４に例えば「ダウンロードのやり直しができません。ダウンロードを中止します」というようなメッセージ表示を行う。
そしてステップＦ７０５でシステムコントローラ１１１に対してダウンロードの中止の指示を行う。
このような場合システムコントローラ１１１では処理はステップＦ７５３からＦ７５４に進むことになり、ダウンロード動作が中止されたとして、ダウンロードモードを終了させる処理を行う。さらに終了処理に伴いステップＦ７５５で、ＣＰＵ８０に対して終了報告を行う。即ちシステムコントローラ１１１側でのダウンロードモード処理が終了される。
一方ＣＰＵ８０では、ステップＦ７０６で終了報告を待機しており、システムコントローラ１１１からの終了報告があったら、一連のダウンロード処理を中止終了する。

以上の処理からわかるように、たとえダウンロード中にデータエラーが発生しても、多くの場合はダウンロードリトライが行われることになり、ユーザーの要求するダウンロード動作が正確に実現される。また、エラー発生時にそのままダウンロードを続行しないことはダウンロードデータの品質保持につながり、データ販売システムとして好適なものとなる。
さらに、リトライが不可能な場合は、ユーザーにその旨を正しく伝えるとともに、ダウンロードを中止することで、不適切なデータをユーザーに販売してしまうことがないようにできる。

なお、リトライ動作としては、例えばエラー発生時までに録音したＡＴＲＡＣデータをそのまま有効データとして用いる例も考えられる。
即ちステップＦ７５２の処理では、システムコントローラ１１１はエラー発生直前のアドレス（例えばＴＳパケット又はＰＥＳパケットのナンバー）を記憶しておくようにし、またディスク１０１上の記録位置もそのポイントでホールドしておく。そしてリトライ時には、そのアドレス（ＴＳパケット又はＰＥＳパケット）までのＡＴＲＡＣデータの入力が確認されたら、その次のパケットのデータを起点として、ディスク１０１上の次のアドレス位置から記録を再開するようにする方式である。

また、リトライが不能と判断されることを少なくするための処理として次のような動作も考えられる。
例えばＭＤレコーダ１３Ａ側の故障などによりエラーとなった場合は、他の機器（例えばＭＤレコーダ１３Ｂ）に対してリトライ動作としてのダウンロードを実行するようにする。
また、イベント内の最後のＡＴＲＡＣデータの放送でエラーが生じ、リトライ不能となった場合は、そのダウンロード動作を予約登録として、後日同一の楽曲が放送される際に自動的にダウンロードさせるような処理も考えられる。

以上、実施の形態としての構成及び処理例を詳述してきたが、具体的な処理例は上記例に限らず多様に考えられることはいうまでもない。
また機器間の通信方式、通信コマンドも上記例に限定されるものではない。
さらにＩＲＤ１２とストレージデバイス１３が別体である例で説明したが、これらが一体的な機器とされる場合もありうる。

また、放送の送信／受信システムとしてはＤＳＭ−ＣＣ方式を採用した場合に限定されるものではなく、実施の形態において説明した送信フォーマットに準ずる伝送方式であれば本発明の適用が可能とされる。また、本発明が適用されるシステムとしてもデジタル衛星放送システムに限定されるものではなく、例えばケーブルテレビジョンなどの放送や、インターネット等において適用することも可能である。

本発明の実施の形態のデジタル衛星放送受信システムの構成例を示すブロック図である。 実施の形態における受信設備の構築例を示すブロック図である。 実施の形態のＩＲＤのためのリモートコントローラの外観を示す正面図である。 放送画面とＧＵＩ画面との切り換えを示す説明図である。 地上局の構成例を示すブロック図である。 地上局から送信されるデータを示すチャート図である。 送信データの時分割多重化構造を示す説明図である。 ＤＳＭ−ＣＣによる送信フォーマットを示す説明図である。 トランスポートストリームのデータ構造図である。 ＰＳＩのテーブル構造を示す説明図である。 ＰＥＳパケットの説明図である。 ＴＳパケットの説明図である。 ＴＳパケットのデータボディの説明図である。 ＴＳパケットのデータボディのチェックサムデータの説明図である。 実施の形態のＩＲＤの構成を示すブロック図である。 データサービスのディレクトリ構造の一例を示す説明図である。 実施の形態のＩＲＤに接続されるＭＤレコーダのブロック図である。 ミニディスクのクラスタフォーマットの説明図である。 ミニディスクのエリア構造の説明図である。 実施の形態における受信設備の構築例を示すブロック図である。 実施の形態のＩＲＤの機器接続時の処理のフローチャートである。 実施の形態のＩＲＤの機器接続解消時の処理のフローチャートである。 実施の形態のＩＲＤのニックネーム入力モード処理のフローチャートである。 実施の形態のＩＤテーブルの説明図である。 実施の形態のダウンロード処理手順の説明図である。 実施の形態のダウンロード処理手順の説明図である。 実施の形態のダウンロード設定処理のフローチャートである。 実施の形態の機器リスト表示例の説明図である。 実施の形態の機器リスト表示例の説明図である。 実施の形態の機器リスト表示例の説明図である。 実施の形態の機器リスト表示例の説明図である。 実施の形態のダウンロード実行のためのチェック／指示処理のフローチャートである。 実施の形態のディスク装填チェック処理のフローチャートである。 実施の形態のライトプロテクトチェック処理のフローチャートである。 実施の形態のディスク容量チェック処理のフローチャートである。 実施の形態のダウンロードセットアップ時の処理のフローチャートである。 実施の形態のＡＴＲＡＣ記録時の処理のフローチャートである。 実施の形態のダウンロード進捗状況表示例の説明図である。 実施の形態の管理／付加情報記録時の処理のフローチャートである。 実施の形態の管理／付加情報記録時の処理のフローチャートである。 実施の形態のエラー発生時の処理のフローチャートである。

符号の説明

１ 地上局、２ 衛星、３ 受信設備、５ 課金サーバ、６ テレビ番組素材サーバ、７ 楽曲素材サーバ、８ 音声付加情報サーバ、９ ＧＵＩデータサーバ、１０ キー情報サーバ、１１ パラボラアンテナ、１２ ＩＲＤ、１３ ストレージデバイス、１３Ａ，１３Ｂ，１３Ｅ，１３Ｆ，１３Ｇ ＭＤレコーダ、１４ モニタ装置、１６ ＩＥＥＥ１３９４バス、２１Ａ テレビ番組表示エリア、２１Ｂ リスト、２１Ｃ テキスト表示エリア、２１Ｄ ジャケット表示エリア、２２ 歌詞表示ボタン、２３ プロフィール表示ボタン、２４ 情報表示ボタン、２５ 予約録音ボタン、２６ 予約済一覧表示ボタン、２７ 録音履歴ボタン、２８ ダウンロードボタン、３１ テレビ番組素材登録システム、３２ 楽曲素材登録システム、３３ 音声付加情報登録システム、３４ ＧＵＩ用素材登録システム、３５ ＡＶサーバ、３６Ａ ＭＰＥＧオーディオエンコーダ、３６Ｂ ＡＴＲＡＣエンコーダ、３７ 音声付加情報データベース、３８ ＧＵＩ素材データベース、３９ テレビ番組送出システム、４０Ａ ＭＰＥＧオーディオサーバ、４０Ｂ ＭＰＥＧオーディオサーバ、４１ 音声付加情報送出システム、４２ ＧＵＩオーサリングシステム、４３Ａ ＭＰＥＧオーディオ送出システム、４３Ｂ ＡＴＲＡＣオーディオ送出システム、４４ ＤＳＭ−ＣＣエンコーダ、４５ マルチプレクサ、４６ 電波送出システム、５１ チューナ／フロントエンド部、５２ デスクランブラ、５３ トランスポート部、５４ ＭＰＥＧ２オーディオデコーダ、５４Ａ メモリ、５５ ＭＰＥＧ２ビデオデコーダ、５５Ａ メモリ、５６ Ｄ／Ａコンバータ、５７ スイッチ回路、５８ 表示処理部、５９ 光デジタル出力インターフェイス、６０ ＩＥＥＥ１３９４インターフェイス、６１ マンマシンインターフェイス、６２ ＩＣカードスロット、６３ モデム、６４ リモートコントローラ、６５ ＩＣカード、６６ 赤外線インターフェース、６７ コントロールラインインターフェース、６８ 不揮発性メモリ、６９ タイマ、７０ デマルチプレクサ、７１ キュー、８１ 制御処理部、８２ ＤｅＭＵＸドライバ、８３ ＤＳＭ−ＣＣデコーダブロック、８４ ＭＨＥＧデコーダブロック、９０ メインメモリ、９１ ＤＳＭ−ＣＣバッファ、１０１ ディスク、１１１ システムコントローラ、１２５ ＩＥＥＥ１３９４インターフェース、１２６ コントロールラインインターフェース、１２７ 赤外線インターフェース、１２８ 光デジタル入力インターフェース、１２９ 表示部、２０１ 電源キー、２０２ 数字キー、２０３ 画面表示切換キー、２０４ インタラクティブ切換キー、２０５ａ 矢印キー、２０５ ＥＰＧキーパネル部、２０６ チャンネルキー、Ｔ１ 入力端子、Ｔ２ アナログビデオ出力端子、Ｔ３ アナログオーディオ出力端子、Ｔ４ アナログオーディオ出力端子

Claims (2)

1. データ受信装置にモノメディアデータを伝送する伝送方法において、
   上記モノメディアデータをＤＳＭ−ＣＣ方式に基づいてモジュールを生成し、
   上記モジュールを固定長を有するブロックに分割し、
   上記ブロックに分割されたデータから、ＤＤＢメッセージを生成し、
   上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるＤＩＩメッセージを生成し、
   上記ＤＤＢメッセージ及びＤＩＩメッセージを、周期的且つ繰り返し送出するカルーセル方式を使って伝送する
   ことを特徴とするデータ伝送方法。
2. データ受信装置にモノメディアデータを伝送する伝送装置において、
   上記モノメディアデータをＤＳＭ−ＣＣ方式に基づいてモジュールを生成するモジュール生成手段と、
   上記モジュールを固定長を有するブロックに分割する分割手段と、
   上記ブロックに分割されたデータから、ＤＤＢメッセージを生成するＤＤＢメッセージ生成手段と、
   上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるＤＩＩメッセージを生成するＤＩＩメッセージ生成手段と、
   上記ＤＤＢメッセージ及びＤＩＩメッセージを、周期的且つ繰り返し送出するカルーセル方式を使って伝送する伝送手段と
   を備えたことを特徴とするデータ伝送装置。

Images