JP4378780B2 - 受信装置及び受信方法 - Google Patents
受信装置及び受信方法 Download PDFInfo
- Publication number
- JP4378780B2 JP4378780B2 JP20385798A JP20385798A JP4378780B2 JP 4378780 B2 JP4378780 B2 JP 4378780B2 JP 20385798 A JP20385798 A JP 20385798A JP 20385798 A JP20385798 A JP 20385798A JP 4378780 B2 JP4378780 B2 JP 4378780B2
- Authority
- JP
- Japan
- Prior art keywords
- scene
- data
- module
- information
- audio
- 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
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
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 Info Indication)という制御メッセージが生成される。
上記ＤＳＩ及びＤＩＩは、受信側（ＩＲＤ１２）で受信データからモジュールを取得する際に必要となる情報であり、ＤＳＩは主として、次に説明するカルーセル（モジュール）の識別子、カルーセル全体に関連する情報（カルーセルが１回転する時間、カルーセル回転のタイムアウト値）等の情報を有する。また、データサービスのルートディレクトリ（Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ）の所在を知るための情報も有する（オブジェクトカルーセル方式の場合）。
【００６７】
ＤＩＩは、カルーセルに含まれるモジュールごとに対応する情報であり、モジュールごとのサイズ、バージョン、そのモジュールのタイムアウト値などの情報を有する。
【００６８】
そして、図８（ｆ）に示すように、上記ＤＤＢ、ＤＳＩ、ＤＩＩの３種類のメッセージをセクションのデータ単位に対応させて周期的に、かつ、繰り返し送出するようにされる。これにより、受信機側では例えば目的のＧＵＩ画面（シーン）を得るのに必要なオブジェクトが含まれているモジュールをいつでも受信できるようにされる。
本明細書では、このような伝送方式を回転木馬に例えて「カルーセル方式」といい、図８（ｆ）に示すようにして模式的に表されるデータ伝送形態をカルーセルというものとする。
また、「カルーセル方式」としては、「データカルーセル方式」のレベルと「オブジェクトカルーセル方式」のレベルとに分けられる。特にオブジェクトカルーセル方式では、ファイル、ディレクトリ、ストリーム、サービスゲートウェイなどの属性を持つオブジェクトをデータとしてカルーセルを用いて転送する方式で、ディレクトリ構造を扱えることがデータカルーセル方式と大きく異なる。本実施の形態のシステムでは、オブジェクトカルーセル方式を採用するものとされる。
【００６９】
また、上記のようにしてカルーセルにより送信されるＧＵＩデータ、つまり、図５のＤＳＭ−ＣＣエンコーダ４４から出力されるデータとしては、トランスポートストリームの形態により出力される。このトランスポートストリームは例えば図９に示す構造を有する。
図９（ａ）には、トランスポートストリームが示されている。このトランスポートストリームとはＭＰＥＧシステムで定義されているビット列であり、図のように１８８バイトの固定長パケット（トランスポートパケット）の連結により形成される。
【００７０】
そして、各トランスポートパケットは、図９（ｂ）に示すようにヘッダと特定の個別パケットに付加情報を含めるためのアダプテーションフィールドとパケットの内容（ビデオ／オーディオデータ等）を表すペイロード（データ領域）とからなる。
【００７１】
ヘッダは、例えば実際には４バイトとされ、図９（ｃ）に示すように、先頭には必ず同期バイトがあるようにされ、これより後ろの所定位置にそのパケットの識別情報であるＰＩＤ（Ｐａｃｋｅｔ＿ＩＤ）、スクランブルの有無を示すスクランブル制御情報、後続するアダプテーションフィールドやペイロードの有無等を示すアダプテーションフィールド制御情報が格納されている。
【００７２】
これらの制御情報に基づいて、受信装置側ではパケット単位でデスクランブルを行い、また、デマルチプレクサによりビデオ／オーディオ／データ等の必要パケットの分離・抽出を行うことができる。また、ビデオ／オーディオの同期再生の基準となる時刻情報を再生することもここで行うことができる。
【００７３】
また、これまでの説明から分かるように、１つのトランスポートストリームには複数チャンネル分の映像／音声／データのパケットが多重されているが、それ以外にＰＳＩ(Program Specific Information)といわれる選局を司るための信号や、限定受信（個人の契約状況により有料チャンネルの受信可不可を決定する受信機能）に必要な情報（ＥＭＭ／ＥＣＭ）、ＥＰＧなどのサービスを実現するためのＳＩ(Service Information)が同時に多重されている。ここでは、ＰＳＩについて説明する。
【００７４】
ＰＳＩは、図１０に示すようにして、４つのテーブルで構成されている。それぞれのテーブルは、セクション形式というＭＰＥＧ Ｓｙｓｔｅｍに準拠した形式で表されている。
図１０（ａ）には、ＮＩＴ(Network Informataion Table)及びＣＡＴ(Conditional Access Table)のテーブルが示されている。
ＮＩＴは、全キャリアに同一内容が多重されている。キャリアごとの伝送諸元（偏波面、キャリア周波数、畳み込みレート等）と、そこに多重されているチャンネルのリストが記述されている。ＮＩＴのＰＩＤとしては、ＰＩＤ＝0x0010とされている。
【００７５】
ＣＡＴもまた、全キャリアに同一内容が多重される。限定受信方式の識別と契約情報等の個別情報であるＥＭＭ(Entitlement Management Message)パケットのＰＩＤが記述されている。ＰＩＤとしては、ＰＩＤ＝0x0001により示される。
【００７６】
図１０（ｂ）には、キャリアごとに固有の内容を有する情報として、ＰＡＴが示される。ＰＡＴには、そのキャリア内のチャンネル情報と、各チャンネルの内容を表すＰＭＴのＰＩＤが記述されている。ＰＩＤとしては、ＰＩＤ＝0x0000により示される。
【００７７】
また、キャリアにおけるチャンネルごとの情報として、図１０（ｃ）に示すＰＭＴ(Program Map Table)のテーブルを有する。
ＰＭＴは、チャンネル別の内容が多重されている。例えば、図１０（ｄ）に示すような、各チャンネルを構成するコンポーネント（ビデオ／オーディオ等）と、デスクランブルに必要なＥＣＭ(Encryption Control Message)パケットのＰＩＤが記述されているＰＭＴのＰＩＤは、ＰＡＴにより指定される。
【００７８】
１−５．ＩＲＤ
続いて、受信設備３に備えられるＩＲＤ１２の一構成例について図１１を参照して説明する。
【００７９】
この図に示すＩＲＤ１２において、入力端子Ｔ１には、パラボラアンテナ１１のＬＮＢ１５により所定の周波数に変換された受信信号を入力してチューナ／フロントエンド部５１に供給する。
チューナ／フロントエンド部５１では、ＣＰＵ(Central Processing Unit)８０からの伝送諸元等を設定した設定信号に基づいて、この設定信号により決定されるキャリア（受信周波数）を受信して、例えばビタビ復調処理や誤り訂正処理等を施すことで、トランスポートストリームを得るようにされる。
チューナ／フロントエンド部５１にて得られたトランスポートストリームは、デスクランブラ５２に対して供給される。また、チューナ／フロントエンド部５１では、トランスポートストリームからＰＳＩのパケットを取得し、その選局情報を更新すると共に、トランスポートストリームにおける各チャンネルのコンポーネントＰＩＤを得て、例えばＣＰＵ８０に伝送する。ＣＰＵ８０では、取得したＰＩＤを受信信号処理に利用することになる。
【００８０】
デスクランブラ５２では、ＩＣカード６５に記憶されているデスクランブルキーデータをＣＰＵ８０を介して受け取ると共に、ＣＰＵ８０によりＰＩＤが設定される。そして、このデスクランブルキーデータとＰＩＤとに基づいてデスクランブル処理を実行し、トランスポート部５３に対して伝送する。
【００８１】
トランスポート部５３は、デマルチプレクサ７０と、例えばＤＲＡＭ等により構成されるキュー（Queue）７１とからなる。キュー（Queue）７１は、モジュール単位に対応した複数のメモリ領域が列となるようにして形成されているものとされ、例えば本実施の形態では、３２列のメモリ領域が備えられる。つまり、最大で３２モジュールの情報を同時に格納することができる。
【００８２】
デマルチプレクサ７０の概略的動作としては、ＣＰＵ８０のＤｅＭＵＸドライバ８２により設定されたフィルタ条件に従って、デスクランブラ５２から供給されたトランスポートストリームから必要なトランスポートパケットを分離し、必要があればキュー７１を作業領域として利用して、先に図７（ｅ）〜（ｈ）により示したような形式のデータを得て、それぞれ必要な機能回路部に対して供給する。
デマルチプレクサ７０にて分離されたＭＰＥＧビデオデータは、ＭＰＥＧ２ビデオデコーダ５５に対して入力され、ＭＰＥＧオーディオデータは、ＭＰＥＧオーディオデコーダ５４に対して入力される。これらデマルチプレクサ７０により分離されたＭＰＥＧビデオ／オーディオデータの個別パケットは、ＰＥＳ(Packetized Elementary Stream)と呼ばれる形式でそれぞれのデコーダに入力される。
【００８３】
また、トランスポートストリームにおけるＭＨＥＧコンテンツのデータについては、デマルチプレクサ７０によりトランスポートストリームからトランスポートパケット単位で分離抽出されながらキュー７１の所要のメモリ領域に書き込まれていくことで、モジュール単位にまとめられるようにして形成される。そして、このモジュール単位にまとめられたＭＨＥＧコンテンツのデータは、ＣＰＵ８０の制御によってデータバスを介して、メインメモリ９０内のＤＳＭ−ＣＣバッファ９１に書き込まれて保持される。
【００８４】
また、トランスポートストリームにおける４倍速ＡＴＲＡＣデータ（圧縮オーディオデータ）も、例えばトランスポートパケット単位で必要なデータがデマルチプレクサ７０により分離抽出されてＩＥＥＥ１３９４インターフェイス６０に対して出力される。また、ＩＥＥＥ１３９４インターフェイス６０を介した場合には、オーディオディオデータの他、ビデオデータ及び各種コマンド信号等を送出することも可能とされる。
【００８５】
ＰＥＳとしての形式によるＭＰＥＧビデオデータが入力されたＭＰＥＧ２ビデオデコーダ５５では、メモリ５５Ａを作業領域として利用しながらＭＰＥＧ２フォーマットに従って復号化処理を施す。復号化されたビデオデータは、表示処理部５８に供給される。
【００８６】
表示処理部５８には、上記ＭＰＥＧ２ビデオデコーダ５５から入力されたビデオデータと、後述するようにしてメインメモリ９０のＭＨＥＧバッファ９２にて得られるデータサービス用のＧＵＩ画面等のビデオデータが入力される。表示処理部５８では、このようにして入力されたビデオデータについて所要の信号処理を施して、所定のテレビジョン方式によるアナログオーディオ信号に変換してアナログビデオ出力端子Ｔ２に対して出力する。
これにより、アナログビデオ出力端子Ｔ２とモニタ装置１４のビデオ入力端子とを接続することで、例えば先に図４に示したような表示が行われる。
【００８７】
また、ＰＥＳによるＭＰＥＧオーディオデータが入力されるＭＰＥＧ２オーディオデコーダ５４では、メモリ５４Ａを作業領域として利用しながらＭＰＥＧ２フォーマットに従って復号化処理を施す。復号化されたオーディオデータは、Ｄ／Ａコンバータ５６及び光デジタル出力インターフェイス５９に対して供給される。
【００８８】
Ｄ／Ａコンバータ５６では、入力されたオーディオデータについてアナログ音声信号に変換してスイッチ回路５７に出力する。スイッチ回路５７では、アナログオーディオ出力端子Ｔ３又はＴ４の何れか一方に対してアナログ音声信号を出力するように信号経路の切換を行う。
ここでは、アナログオーディオ出力端子Ｔ３はモニタ装置１４の音声入力端子と接続されるために設けられているものとされる。また、アナログオーディオ出力端子Ｔ４はダウンロードした楽曲をアナログ信号により出力するための端子とされる。
また、光デジタル出力インターフェイス５９では、入力されたデジタルオーディオデータを光デジタル信号に変換して出力する。この場合、光デジタル出力インターフェイス５９は、例えばＩＥＣ９５８に準拠する。
【００８９】
メインメモリ９０は、ＣＰＵ８０が各種制御処理を行う際の作業領域として利用されるものである。そして、本実施の形態では、このメインメモリ９０において、前述したＤＳＭ−ＣＣバッファ９１と、ＭＨＥＧバッファ９２としての領域が割り当てられるようになっている。
ＭＨＥＧバッファ９２には、ＭＨＥＧ方式によるスクリプトの記述に従って生成された画像データ（例えばＧＵＩ画面の画像データ）を生成するための作業領域とされ、ここで生成された画像データはバスラインを介して表示処理部５８に供給される。
【００９０】
ＣＰＵ８０は、ＩＲＤ１２における全体制御を実行する。このなかには、デマルチプレクサ７０におけるデータ分離抽出についての制御も含まれる。
また、獲得したＭＨＥＧコンテンツのデータについてデコード処理を施すことで、スクリプトの記述内容に従ってＧＵＩ画面（シーン）を構成して出力するための処理も実行する。
【００９１】
このため、本実施の形態のＣＰＵ８０としては、主たる制御処理を実行する制御処理部８１に加え、例えば少なくとも、ＤｅＭＵＸドライバ８２、ＤＳＭ−ＣＣデコーダブロック８３、及びＭＨＥＧデコーダブロック８４が備えられる。本実施の形態では、このうち、少なくともＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４については、ソフトウェアにより構成される。
ＤｅＭＵＸドライバ８２は、入力されたトランスポートストリームのＰＩＤに基づいてデマルチプレクサ７０におけるフィルタ条件を設定する。
ＤＳＭ−ＣＣデコーダブロック８３は、ＤＳＭ−Ｍａｎａｇｅｒとしての機能を有するものであり、ＤＳＭ−ＣＣバッファ９１に格納されているモジュール単位のデータについて、ＭＨＥＧコンテンツのデータに再構築する。また、ＭＨＥＧデコーダブロック８４からのアクセスに従って所要のＤＳＭ−ＣＣデコード等に関連する処理を実行する。
【００９２】
ＭＨＥＧデコーダブロック８４は、ＤＳＭ−ＣＣデコーダブロック８３により得られたＭＨＥＧコンテンツのデータ、つまり、ＤＳＭ−ＣＣバッファ９１にて得られているＭＨＥＧコンテンツのデータにアクセスして、シーン出力のためのデコード処理を行う。つまり、そのＭＨＥＧコンテンツのスクリプトファイルにより規定されているオブジェクト間の関係を実現していくことで、シーンを形成するものである。この際、シーンとしてＧＵＩ画面を形成するのにあたっては、ＭＨＥＧバッファ９２を利用して、ここで、スクリプトファイルの内容に従ってＧＵＩ画面の画像データを生成するようにされる。
【００９３】
ＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４間のインターフェイスには、Ｕ−Ｕ ＡＰＩ(Application Portability Interface)が採用される。
Ｕ−Ｕ ＡＰＩは、ＤＳＭ Ｍａｎａｇｅｒオブジェクト（ＤＳＭの機能を実現するサーバオブジェクト）にアクセスするためのインターフェイスであり、これにより、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ，Ｄｉｒｅｃｔｏｒｙ，Ｆｉｌｅ，Ｓｔｒｅａｍ，Ｓｔｒｅａｍ Ｅｖｅｎｔなどのオブジェクトに対する操作を行う。
クライアントオブジェクトは、このＡＰＩを使用することによって、これらのオブジェクトに対して操作を行うことができる。
【００９４】
ここで、ＣＰＵ８０の制御によりトランスポートストリームから１シーンを形成するのに必要な目的のオブジェクトを抽出するための動作例について説明しておく。
【００９５】
ＤＳＭ−ＣＣでは、トランスポートストリーム中のオブジェクトの所在を示すのにＩＯＲ(Interoperable Object Reference)が使用される。ＩＯＲには、オブジェクトを見つけ出すための力ルーセルに対応する識別子、オブジェクトの含まれるモジュールの識別子（以下ｍｏｄｕｌｅ＿ｉｄと表記）、１つのモジュール中でオブジェクトを特定する識別子（以下ｏｂｊｅｃｔ＿ｋｅｙと表記）のほかに、オブジェクトの含まれるモジュールの情報を持つＤＩＩを識別するためのタグ（ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ）情報を含んでいる。
また、モジュール情報を持つＤＩＩには、１つ以上のモジュールそれぞれについてのｍｏｄｕｌｅ＿ｉｄ、モジュールの大きさ、バージョンといった情報と、そのモジュールを識別するためのタグ（ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ）情報を含んでいる。
【００９６】
トランスポートストリームから抜き出されたＩＯＲがＣＰＵ８０において識別された場合に、そのＩＯＲで示されたオブジェクトを受信、分離して得るプロセスは、例えば次のようになる。
（Ｐｒ１） ＣＰＵ８０のＤｅＭＵＸドライバ８２では、ＩＯＲのａｓｓｏｃｉａｔｉｏｎ＿ｔａｇと同じ値を持つエレメンタリーストリーム（以下ＥＳと表記）を、カルーセルにおけるＰＭＴのＥＳループから探し出してＰＩＤを得る。このＰＩＤを持つＥＳにＤＩＩが含まれていることになる。
（Ｐｒ２） このＰＩＤとｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎとをフィルタ条件としてデマルチプレクサ７０に対して設定する。これにより、デマルチプレクサ７０では、ＤＩＩを分離してＣＰＵ８０に対して出力する。
（Ｐｒ３） ＤＩＩの中で、先のＩＯＲに含まれていたｍｏｄｕｌｅ＿ｉｄに相当するモジュールのａｓｓｏｃｉａｔｉｏｎ＿ｔａｇを得る。
（Ｐｒ４） 上記ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇと同じ値を有するＥＳを、ＰＭＴのＥＳループ（カルーセル）から探し出し、ＰＩＤを得る。このＰＩＤを有するＥＳに目的とするモジュールが含まれる。
（Ｐｒ５） 上記ＰＩＤとｍｏｄｕｌｅ＿ｉｄとをフィルタ条件として設定して、デマルチプレクサ７０によるフィルタリングを行う。このフィルタ条件に適合して分離抽出されたトランスポートパケットがキュー７１の所要のメモリ領域（列）に格納されていくことで、最終的には、目的のモジュールが形成される。
（Ｐｒ６） 先のＩＯＲに含まれていたｏｂｊｅｃｔ＿ｋｅｙに相当するオブジェクトをこのモジュールから抜き出す。これが目的とするオブジェクトになる。このモジュールから抜き出されたオブジェクトは、例えば、ＤＳＭ−ＣＣバッファ９１の所定の領域に書き込みが行われる。
例えば、上記動作を繰り返し、目的とするオブジェクトを集めてＤＳＭ−ＣＣバッファ９１に格納していくことで、必要とされるシーンを形成するＭＨＥＧコンテンツが得られることになる。
【００９７】
マンマシンインターフェイス６１では、リモートコントローラ６４から送信されてきたコマンド信号を受信してＣＰＵ８０に対して伝送する。ＣＰＵ８０では、受信したコマンド信号に応じた機器の動作が得られるように、所要の制御処理を実行する。
【００９８】
ＩＣカードスロット６２にはＩＣカード６５が挿入される。そして、この挿入されたＩＣカード６５に対してＣＰＵ８０によって情報の書き込み及び読み出しが行われる。
【００９９】
モデム６３は、電話回線４を介して課金サーバ５と接続されており、ＣＰＵ８０の制御によってＩＲＤ１２と課金サーバ５との通信が行われるように制御される。
【０１００】
ここで、上記構成によるＩＲＤ１２におけるビデオ／オーディオソースの信号の流れを、図４により説明した表示形態に照らし合わせながら補足的に説明する。
図４（ａ）に示すようにして、通常の番組を出力する場合には、入力されたトランスポートストリームから必要な番組のＭＰＥＧビデオデータとＭＰＥＧオーディオデータとが抽出されて、それぞれ復号化処理が施される。そして、このビデオデータとＭＰＥＧオーディオデータが、それぞれアナログビデオ出力端子Ｔ２と、アナログオーディオ出力端子Ｔ３に出力されることで、モニタ装置１４では、放送番組の画像表示と音声出力が行われる。
【０１０１】
また、図４（ｂ）に示したＧＵＩ画面を出力する場合には、入力されたトランスポートストリームから、このＧＵＩ画面（シーン）に必要なＭＨＥＧコンテンツのデータをトランスポート部５３により分離抽出してＤＳＭ−ＣＣバッファ９１に取り込む。そして、このデータを利用して、前述したようにＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４が機能することで、ＭＨＥＧバッファ９２にてシーン（ＧＵＩ画面）の画像データが作成される。そして、この画像データが表示処理部５８を介してアナログビデオ出力端子Ｔ２に供給されることで、モニタ装置１４にはＧＵＩ画面の表示が行われる。
【０１０２】
また、図４（ｂ）に示したＧＵＩ画面上で楽曲のリスト２１Ｂにより楽曲が選択され、その楽曲のオーディオデータを試聴する場合には、この楽曲のＭＰＥＧオーディオデータがデマルチプレクサ７０により得られる。そして、このＭＰＥＧオーディオデータが、ＭＰＥＧオーディオデコーダ５４、Ｄ／Ａコンバータ、スイッチ回路５７、アナログオーディオ出力端子Ｔ３を介してアナログ音声信号とされてモニタ装置１４に対して出力される。
【０１０３】
また、図４（ｂ）に示したＧＵＩ画面上でダウンロードボタン２８が押されてオーディオデータをダウンロードする場合には、ダウンロードすべき楽曲のオーディオデータがデマルチプレクサ７０により抽出されてアナログオーディオ出力端子Ｔ４、光デジタル出力インターフェイス５９、またはＩＥＥＥ１３９４インターフェイス６０に出力される。
【０１０４】
ここで、特にＩＥＥＥ１３９４インターフェイス６０に対して、図２に示したＩＥＥＥ１３９４対応のＭＤレコーダ／プレーヤ１３Ａが接続されている場合には、デマルチプレクサ７０ではダウンロード楽曲の４倍速ＡＴＲＡＣデータが抽出され、ＩＥＥＥ１３９４インターフェイス６０を介してＭＤレコーダ／プレーヤ１３Ａに装填されているディスクに対して記録が行われる。また、この際には、例えばＪＰＥＧ方式で圧縮されたアルバムジャケットの静止画データ、歌詞やアーティストのプロフィールなどのテキストデータもデマルチプレクサ７０においてトランスポートストリームから抽出され、ＩＥＥＥ１３９４インターフェイス６０を介してＭＤレコーダ／プレーヤ１３Ａに転送される。ＭＤレコーダ／プレーヤ１３Ａでは、装填されているディスクの所定の領域に対して、これら静止画データ、テキストデータを記録することができるようになっている。
【０１０５】
２．本発明に至った背景
このようにＤＳＭ−ＣＣ方式を伝送規格として採用した本実施の形態のデジタル衛星放送システムでは、受信装置、つまりＩＲＤのタイプとして、受信バッファの構成の点から２種類に分けることができる。
【０１０６】
１つは、ＩＲＤが、データサービス（ＧＵＩ画面表示出力）対応のフラッシュメモリやハードディスクドライバなどの大容量の受信バッファを有する構成のものである。このような構成では、放送されているデータサービス（ＭＨＥＧコンテンツ）全体を一度に受信して、受信バッファに保持させる。これにより、一旦データサービスを受信して取り込んだ後は、ＭＨＥＧによるどのシーン（ＧＵＩ画面）についても、メモリアクセスの待ち時間のみ待機するだけで即座に表示出力させることが可能になる。つまり、ＧＵＩ画面（シーン）の切換のための操作をユーザが行ったような場合にも、次のシーンがほぼ直ぐさま表示されることになる。
このような場合、デマルチプレクサのフィルタ条件の切り換えによる多少のオーバーヘッドは、ＧＵＩ画面の表示に関しては特に問題となるものではない。
【０１０７】
もう１つは、ＩＲＤのコストを下げるなどの理由から、上記のような大容量の受信バッファを持たないものである。先に説明した本実施の形態のＩＲＤ１２がこれに相当する。この場合、データ放送サービス全体のデータをバッファリングすることができず、データ放送のデータを受信する受信単位であるモジュールのいくつかがバッファリングできるだけの受信バッファしか持たない。図１１に示したＩＲＤ１２では、この受信バッファはキュー７１に相当し、前述のようにモジュールがバッファリングできるメモリ領域が３２列設けられているのみである。
このようなＩＲＤでは、逆に言えば、モジュ−ルの大きさは受信機のバッファメモリーサイズを上回ることはできない。このため、データサービス全体がいくつかのモジュールの集合で構成されることになり、その時々で表示に必要なモジュールだけを受信するなどの手順が必要になってくる。
前述したオブジェクトを抽出するための手順（Ｐｒ１）〜（Ｐｒ６）は、このような大容量の受信バッファを有さないＩＲＤの構成に対応したものである。
【０１０８】
ここで、図１４に、ＭＨＥＧ方式に則ったデータサービスとしてのファイル（ＭＨＥＧ ａｐｐｌｉｃａｔｉｏｎ ｆｉｌｅ）のディレクトリ構造例を示す。前述したようにオブジェクトカルーセル方式は、このディレクトリ構造を扱えることに特徴を有する。
通常、Ｓｅｒｖｉｃｅ Ｄｏｍａｉｎの入り口となる（ＭＨＥＧ ａｐｐｌｉｃａｔｉｏｎ ｆｉｌｅ）は、必ず、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙの直下にある、ａｐｐ０／ｓｔａｒｔｕｐというファイルとなる。
基本的には、Ｓｅｒｖｉｃｅ Ｄｏｍａｉｎ（Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ）の下にａｐｐｌｉｃａｔｉｏｎ ｄｉｒｅｃｔｏｒｙ（ａｐｐ０，ａｐｐ１・・・ａｐｐＮ）があり、その下にｓｔａｒｔｕｐといわれるアプリケーション・ファイルと、ａｐｐｌｉｃａｔｉｏｎを構成する各ｓｃｅｎｅのｄｉｒｅｃｔｏｒｙ（ｓｃｅｎｅ０，ｓｃｅｎｅ１・・・）があるようにされる。更にｓｃｅｎｅ ｄｉｒｅｃｔｏｒｙの下には、ＭＨＥＧ ｓｃｅｎｅ ｆｉｌｅとｓｃｅｎｅを構成する各ｃｏｎｔｅｎｔ ｆｉｌｅがおかれることとしている。
【０１０９】
上記図１４のディレクトリ構造を前提として、例えば或るデータサービスにおいて、データサービスの最初にアクセスすべきアプリケーションがＳｅｒｖｉｃｅ Ｇａｔｅｗａｙ／ａｐｐ０／ｓｔａｒｔｕｐというファイルで、最初のシーンがｓｃｅｎｅｄｉｒ０に含まれる静止画やテキストのファイルで構成されているとする。
そして、このようなデータサービスについてＩＲＤにより受信を開始したとすれば、次のような手順となる。
（Ｐｒ１１） ＰＭＴを参照して所望のデータサービスのＰＩＤを取得し、そのＰＩＤとｔａｂｌｅ＿ｉｄとｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎをフイルタ条件としてデマルチプレクサでフィルタリングを行い、ＤＳＩを得る。このＤＳＩにはＳｅｒｖｉｃｅ ＧａｔｅｗａｙオブジェクトのＩＯＲが書かれている。
（Ｐｒ１２） このＩＯＲから、先に説明したオブジェクト抽出手順（Ｐｒ１）〜（Ｐｒ６）でＳｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトを得る。
【０１１０】
Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトとディレクトリ・オブジェクトの２種類のＢＩＯＰメッセージの中には、そのディレクトリ直下のオブジェクトの名称、所在（ｌＯＲ）、オブジェクトの種類といった情報が、ｂｉｎｄｉｎｇという属性情報として入っている。従ってオブジェクトの名称が与えられると、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙから始まってディレクトリをーつづつ下にたどりながら、その名称のオブジェクトに行き着くことができる（同じ名称のオブジェクトが存在する場合は、違うところまで上位のバス名が必要になる）。そして、さらに次に示す手順に進む。
【０１１１】
（Ｐｒ１３） Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトのｂｉｎｄｉｎｇ情報からａｐｐ０オブジェクトのＩＯＲを得て、オブジェクト抽出手順（Ｐｒ１）〜（Ｐｒ６）によりａｐｐ０オブジェクトを得る。
（Ｐｒ１４） ａｐｐ０オブジェクトのｂｉｎｄｉｎｇ情報からｓｔａｒｔｕｐオブジェクトのＩＯＲを得て、オブジェクト抽出手順（Ｐｒ１）〜（Ｐｒ６）でｓｔａｒｔｕｐオブジェクトを得る。以下同様に最初のシーンであるｓｃｅｎｅｄｉｒ０オブジェクトなどを得る。
【０１１２】
前述したように、モジュールを形成するオブジェクトの関係はＤＳＭ−ＣＣ方式のもとでは特に限定されるものではなく任意である。そこで、仮に図１５に示すような、それぞれのオブジェクト１つがモジュール１つに対応するようなマッピングを取って地上局１から送信を行ったとする。なお、データサービスのディレクトリ構造に対するマッピングの処理は、ＤＳＭ−ＣＣエンコーダ４４にてモジュールを形成する処理に際して、ＭＨＥＧコンテンツのデータに対して行われるものである。
【０１１３】
この場合、ＩＲＤ側において上記（Ｐｒ１１）〜（Ｐｒ１４）の手順によってオブジェクトを次々に得るには、一々新しいモジュールを受信することになる。このため、オブジェクトを得るごとにフィルタ条件を何度もデマルチプレクサ７０に変更設定してフィルタリングする手順が必要であり、このようなフィルタリング動作の繰り返しによってシーンの取り込みが遅れ、その表示も遅くなるなどサービス性の低下を招くことになる。
データサ−ビスの全データの大きさや放送時に割り当てられる帯域にもよるが、カルーセル１回転の周期は数秒から、１０秒以上に達することも考えられる。１回のフィルタリングには最悪で力ルーセル１回転分（平均１／２回転分）の待ち時間が生じるので、このフィルタリングの回数をできるだけ少なくすることがサービス性の向上に直接結びついてくる。
【０１１４】
また、シーンの切り換えについて考えてみると、図１５に示すマッピングでは、表示中のシーンから次のシーンのファイルを呼び込むときには、上位のディレクトリからたどらなくてはならない場合が生じる。
例えば図１５に示すマッピングの場合であれば、ａｐｐ０／ｓｃｅｎｅｄｉｒ０からａｐｐ０／ｓｃｅｎｅｄｉｒ１に移る場合は、既にａｐｐ０オブジェクトのＢＩＯＰメッセージからｓｃｅｎｅｄｉｒ１のｂｉｎｄｉｎｇ情報が得られているが、ａｐｐ０／ｓｃｅｎｅｄｉｒ０からａｐｐＮ／ｓｃｅｎｅｄｉｒ０に移る場合は、Ｓｅｒｖｉｃｅ ＧａｔｅｗａｙオブジェクトのＢＩＯＰメッセージにあったａｐｐＮオブジェクトのｂｉｎｄｉｎｇ情報からａｐｐＮ／ｓｃｅｎｅｄｉｒ０を辿ることになる。つまり、シーンを変更するために、先ずＳｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトのモジュールを受信して、このＢＩＯＰメッセージからａｐｐＮのｂｉｎｄｉｎｇ情報を得て、ａｐｐＮ／ｓｃｅｎｅｄｉｒ０のディレクトリを識別してから、このａｐｐＮ／ｓｃｅｎｅｄｉｒ０のモジュールを受信せねばならなくなる。（但し、上記した動作は、１回目のａｐｐＮをアクセスのときだけである。２回目以降はａｐｐＮのｂｉｎｄｉｎｇ情報を保持していればこの手順は不要となる。）
つまり、このような場合もモジュールのフィルタリングによるシーン切り替えの待ち時間が大きくなる。
【０１１５】
３．地上局側のデータマッピング例
そこで、本実施の形態では、先に述べた（Ｐｒ１）〜（Ｐｒ６）によるオブジェクト抽出手順によっても、最初のシーン表示や、シーンの切り替えによる待ち時間が短縮されるように、次のようにオブジェクトのマッピング方法を提案するものである。
【０１１６】
図１２は、本実施の形態としてのデータサービスのディレクトリ構造に対するマッピング例を示すものである。
図１２においては、１つのシーンを構成するオブジェクト全てを１つのモジューとして纏め（モジュール２，３・・Ｎ）、それ以外のＳｅｒｖｉｃｅＧａｔｅｗａｙを含む上位ディレクトリを１つのモジュール（モジュール１）にマッピングしている。ただし最初にアクセスするアプリケーションファイル「Ｓｔａｒｔｕｐ」は、最初のシーンのモジュールとー緒のモジュール（モジュール２）にマッピングするようにする。
【０１１７】
このようなマッピングとされれば、まずＳｅｒｖｉｃｅ Ｇａｔｅｗａｙのモジュール１を受信すれば、そのサブディレクトリの構成すべてが同じモジュールに入っているので、ＩＲＤ１２側ではディレクトリ構成全体をこのモジュール１の受信で得ることができる。
そして、これに続いてモジュール２を受信することになるが、このモジュール２は最初に提示するシーンのファイルがマッピングされて形成されたモジュールである。従って、このモジュール２のデータの取り込みが完了した段階で、最初のシーン出力に必要なオブジェクトの情報が全て得られることになる。つまり、先に示した（Ｐｒ５）の手順が完了した段階では、（Ｐｒ６）の手順もほぼ同時に完了させていることになる。実際には、キュー７１にてモジュール２が得られたら、このモジュール２を１シーン分のデータとして、ＤＳＭ−ＣＣバッファ９１に伝送するようにされる。なお、このような手順は、ルートディレクトリを含むモジュール１についても同様に行われる。
従って、この場合には、モジュール１、モジュール２と続けて、２回のモジュールの受信（獲得）さえ完了すれば、そのまま最初のシーンをの再生を始めることができる。また、さらに別のシーンに切り替わる場合は、最初に取り込んだディレクトリ・オブジェクトのｂｉｎｄｉｎｇ情報を参照すれば、直接所望のシーン・ディレクトリのモジュールを受信しにいくことができる。
【０１１８】
この場合でも、確かにシーン切り替えのオーバーヘッドは大きくないが、データサービスの最初のシーンの提示までに、モジュールを２回受信する必要がある。
【０１１９】
なお、図１２に示すマッピングでは、上位ディレクトリをまとめたモジュール１に、多くのオブジェクトが入ることになるが、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙとディレクトリの２種類のオブジェクトは、上記のようにそのディレクトリにｂｉｎｄされるオブジェクトの名称やＩＯＲといったデータ量としてはさほど大きくない情報の組み合わせで出来ているため、オブジェクトの数が多くても全体のデータ容量は大きくないものである。
【０１２０】
また図１３に本実施の形態としての他のマッピング例を示す。ここでは、上位ディレクトリを纏めたものに、さらに最初にアクセスするアプリケーションファイル（ｓｔａｒｔｕｐ）と最初のシーンのオブジェクトを１つのモジュール１にマッピングしている。これ以外の他のモジュール２・・Ｎは、図１２に示したモジュール３・・Ｎ等と同様に、１シーンごとに必要とされるオブジェクトを纏めて形成されている。
このようなマッピングを施して送信した場合には、ＩＲＤ側ではこのモジュール１だけを受信して、キュー７１からＤＳＭ−ＣＣバッファ９１に伝送することで、すぐに最初のシーンを表示することができることになる。また、この段階で、ディレクトリ・オブジェクトのｂｉｎｄｉｎｇ情報が参照可能となるので、以降のシーンの切り換えに対応して必要なシーンのオブジェクトから成るモジュールに直ちにアクセスすることが可能になる。
【０１２１】
なお、上記マッピング例としては、１シーンを形成するオブジェクトが必ず１モジュールに収まるようにしているが、場合によっては、１シーンを形成する全てのオブジェクトの容量が大きく、モジュールとして規定されている最大サイズを超えるような場合、例えば、ｎ番目のモジュールに対して或る１シーンを形成するオブジェクトを出来るだけ納めるようにし、ｎ番目のモジュールに収まりきらなかった同一シーンを形成するオブジェクトによりｎ＋１番目のモジュールを形成するようにする。そして、このｎ番目のモジュールとｎ＋１番目のモジュールを連続させて、カルーセル方式で送信する。このようにすれば、ｎ番目のモジュールとｎ＋１番目のモジュールを２回受信する必要はあるが、比較的迅速にシーンの再生を行うことが出来る。
また、以降の説明においては、上述のようにして１シーンを形成することのできるオブジェクトが全て格納されることで形成されたモジュールのことを、「シーンモジュール」ともいうことにする。
【０１２２】
４．本実施の形態のキューへのモジュール割付
続いて、本発明の実施の形態の特徴となるＩＲＤ１２側の受信処理として、キュー７１へのモジュール割付について図１６〜図２０を参照して説明する。本実施の形態のＩＲＤ１２では、上記した放送側（地上局側）のデータマッピングが行われることを前提として、以降説明するキュー７１へのモジュール割付を行うことで、更に効率的に必要なシーンを得ることが可能になるものである。
【０１２３】
図１６（ａ）には、トランスポート部５３におけるデマルチプレクサ７０とキュー７１の構成、及びＤＳＭ−ＣＣバッファ９１のメモリ領域を概念的に示している。
【０１２４】
この図に示すトランスポート部５３としては、デマルチプレクサ７０と、キュー７１を形成するメモリ領域Ｍｅｍ−１，Ｍｅｍ−２，Ｍｅｍ−３・・・Ｍｅｍ３２が示されている。そして、これら各メモリ領域がモジュール単位のデータを蓄積可能とされている。
前述したように、デマルチプレクサ７０に与えられたフィルタ条件に適合する種類のデータ（例えばセクション単位）がトランスポートストリームから分離抽出されるのであるが、この分離抽出されたセクションは、メモリ領域Ｍｅｍ−１〜Ｍｅｍ−３２の何れかに対して格納される。そして、この動作が繰り返される結果、或るメモリ領域に対して上記フィルタ条件に適合して集められたセクションの集合より成るモジュールが形成されて、ここに蓄積されることになる。
【０１２５】
ここで、例えば、デマルチプレクサ７０により、シーンＡを形成するデータにより形成されるモジュールのデータを分離抽出して、メモリ領域Ｍｅｍ−２に格納したとする。そして、このシーンＡのモジュールをＧＵＩ画面表示に使用する場合には、このシーンＡのモジュールのデータをメモリ領域Ｍｅｍ−２からＤＳＭ−ＣＣバッファに対して書き込みを行うようにされる。
つまり、受信したシーンのモジュールの一般的な伝送形態としては、一旦これをキューのメモリ領域にて蓄積した後、ＤＳＭ−ＣＣバッファ９１に取り込むようにすることになる。そして、前述したようにＤＳＭ−ＣＣバッファ９１に取り込まれたシーンデータを、ＭＨＥＧデコーダブロック８４がアクセスしてロードし、ＭＨＥＧバッファに取り込むことでＧＵＩ画面等のシーン出力が可能になる。
【０１２６】
ところで、ここでもメモリ領域Ｍｅｍ−１〜Ｍｅｍ３２として示されているように、キュー７１を形成するメモリ領域は本実施の形態では３２列に限定されている。そして、これらのメモリ領域は、実際にはトランスポートストリームを受信する動作を行っている限りは、各種異なるフィルタ条件に適合して分離された、例えばＭＰＥＧストリームデータ等をはじめとする多種のモジュールデータによりほぼ占有されている状態にある。
このような状況は、例えば、ＭＨＥＧデコーダブロック８４がアクセスする必要があるとされる多数のシーンモジュールをＤＳＭ−ＣＣバッファ９１に取り込もうとしても、このシーンモジュールを一時保持するメモリ領域数が制限されていることで、例えば必要とされるシーンモジュールの多くを一度にキュー内の複数のメモリ領域に蓄積して、ＤＳＭ−ＣＣバッファ９１に転送することが事実上困難であることを意味する。
また、ＤＳＭ−ＣＣ方式では、モジュールの受信順（取込順）を特に規定してはいない。つまり、トランスポート部５３においてどのような順序でシーンモジュールを抽出してメモリ領域に格納するのかは任意とされている。
【０１２７】
そこで、本実施の形態では、上記したメモリ領域数の制限が有ることを踏まえた上で、ＤＳＭ−ＣＣバッファ９１に取り込む必要のあるモジュールが出来るだけ迅速にトランスポート部５３にて得られるように、次のようにしてモジュール割付（受信順）を規定する。
【０１２８】
先に、説明したようにデータサービスのディレクトリ構造、及びこのディレクトリ構造に対するモジュールのマッピングは、例えば図１２、図１３に示すものとされるが、例えばａｐｐ０のディレクトリに関すれば、ａｐｐ０／ｓｔａｒｔｕｐと、ａｐｐ０／ｓｃｅｎｅｄｉｒ０／ｓｃｓｎｅ０のオブジェクトを得さえすれば、ａｐｐ０のアプリケーションを形成するシーンの優先順位の情報を得ることが出来るようになっている。これはａｐｐ１〜Ｎまでの他のアプリケーションについても同じことがいえる。
ここでいう優先順位とは、例えば或るシーンの表示出力から他のシーンの表示出力に移行する（これを「トランジション」ともいう）場合には、上記他のシーンとして複数の候補があるのが通常であるが、これら複数のシーンの候補において、例えばユーザの操作によってシーン切り換えの必要があるとされたときに、切り換えが行われる可能性の高さに従って付されているものである。
【０１２９】
本実施の形態では、このシーンの優先順位の情報に基づいてモジュール割付を規定するが、これについて、再度図１６を参照して説明する。
ここでは、説明の便宜上、トランスポート部５３においてシーンモジュールを保持することのできるメモリ領域はＭｅｍ−２のみとされて、他のメモリ領域は、それ以外の種類のモジュールを格納するために占有されているものとする。また、ここでは、ａｐｐ０のアプリケーションによりシーン出力する場合に関して説明する。
【０１３０】
ここで、トランスポート部５３においては、既に上記したａｐｐ０／ｓｔａｒｔｕｐと、ａｐｐ０／ｓｃｅｎｅｄｉｒ０／ｓｃｓｎｅ０のオブジェクトが属するモジュールを受信しており、例えばＣＰＵ８０の制御処理部８１では、ａｐｐ０のアプリケーションにおけるシーンの優先順位情報が得られているものとする。
そして、ここでは優先順位情報により、ａｐｐ０のディレクトリ構造化にある複数シーンについて、シーンＡ→シーンＢ→シーンＣ→シーンＤ・・のようにして優先順位が与えられているものとし、これらのシーンをＤＳＭ−ＣＣバッファ９１に出来るだけ取り込むことが必要であるとする。
【０１３１】
このような場合、制御処理部８１では、先ず、優先順位が最も高いシーンＡのモジュールがトランスポート部５３のメモリ領域Ｍｅｍ−２に格納されるように制御を実行する。この制御に基づき、デマルチプレクサドライバ８２は、シーンＡのモジュールに適合するフィルタ条件をデマルチプレクサ７０に対して設定する。これにより、図１６（ａ）に示すようにして、シーンＡのモジュールがメモリ領域Ｍｅｍ−２に格納され、ＤＳＭ−ＣＣバッファ９１に転送する。
【０１３２】
続いては、制御処理部８１は、シーンＡに続く優先順位のシーンＢを獲得するための処理として、シーンＢのモジュールに適合するフィルタ条件をデマルチプレクサ７０に対して設定するようにデマルチプレクサドライバ８２に指示する。これにより、図１６（ｂ）に示すようにして、シーンＢのモジュールがメモリ領域Ｍｅｍ−２に得られ、これをＤＳＭ−ＣＣバッファ９１に転送することになる。なお、図１６（ｂ）には、図１６（ａ）に示した回路ブロックのうち、メモリ領域Ｍｅｍ−２とＤＳＭ−ＣＣバッファ９１のみを抜き出して示している。次に示す図１６（ｃ）も同様である。
【０１３３】
更に次は、シーンＢに続く優先順位のシーンＣを得るために、シーンＣのモジュールに適合するフィルタ条件をデマルチプレクサ７０に対して設定し、図１６（ｃ）に示すようにして、シーンＣを得てＤＳＭ−ＣＣバッファ９１に転送する。
【０１３４】
以降、同様にして優先順位に従ったシーンのフィルタ条件をデマルチプレクサ７０に設定して、そのシーンモジュールをメモリ領域Ｍｅｍ−２にて得て、これをＤＳＭ−ＣＣバッファ９１に転送していくようにされる。
【０１３５】
このような動作が行われる結果、ＤＳＭ−ＣＣバッファ９１には、シーン出力のために必要、或いはシーン切り換え時において、次に必要となる可能性の高いシーンモジュールのデータがその優先順位に従って格納されることになる。
ＭＨＥＧデコーダブロック８４は、このようにしてＤＳＭ−ＣＣバッファ９１にて得られたシーンモジュールのデータにアクセスしてＧＵＩ画面などのシーン出力を行うが、例えばデータ放送中においてユーザの操作により所望のシーンの呼び出しの要求が有った場合、呼び出し要求のあったシーンのデータがＤＳＭ−ＣＣバッファ９１に既に保持されている可能性は非常に高く、ほぼ確実に呼び出し要求のあったシーンデータにアクセスして、これを即座に出力させることが可能になる。
【０１３６】
ところで、ＤＳＭ−ＣＣバッファ９１の容量は当然のこととして有限であり、実際にはさほど多くの容量は割り当てられない。このため、例えばＭＨＥＧデコーダブロック８４により使用することが想定される全てのシーンモジュールを格納することが出来ない場合がある。このために、例えば次のような不都合が生じることが想定される。
【０１３７】
ここで、例えば図１７に示すようにして、あるアプリケーションのもとでシーンＡ，シーンＢ，シーンＣ，シーンＤ，シーンＥの５つのシーンが用意されているとして、この各シーン間のトランジションの形態が図のように設定されている（このようなトランジジョンの規定はＭＨＥＧにより記述されている）ものとする。例えばシーンＡであれば、シーンＢ，Ｃ，Ｅにトランジションが可能とされ、シーンＢであればシーンＡ，Ｃにトランジション可能とされている。
【０１３８】
そして、ＤＳＭ−ＣＣバッファ９１の容量として、最大で４つのシーンモジュールを格納することが限度であると仮定する。この条件の下で上記図１７に示すシーンＡ〜Ｅの５つのモジュールが用意されたアプリケーションをＭＨＥＧデコーダブロック８４が使用するとした場合、上記シーンＡ〜Ｅの５つのモジュールのうち、１つのシーンモジュールはＤＳＭ−ＣＣバッファ９１に格納できないことになる。
【０１３９】
上記した条件の下、例えば或る段階でシーンＡを表示出力しており、このときＤＳＭ−ＣＣバッファ９１に取り込まれているシーンモジュールはシーンＡ，Ｂ，Ｃ，Ｄの４つであるとする。そして、この状態から、例えばユーザの操作によりシーンＥの呼び出し要求が有ったとすると、これに応答してシーンＡからシーンＥにトランジションすることになる。
ところが、このときＤＳＭ−ＣＣバッファ９１にはシーンＥのモジュールは無いことから、シーンＥの呼び出し要求に応えるためには、シーンＥのモジュールをカルーセルから新規に取り込む必要がある。この間、ユーザにとってはシーンＡからシーンＥの表示に移行するまでの待ち時間が生じることになる。
【０１４０】
そこで、このような不都合が出来るだけ解消されるようにするため、本実施の形態では、更に次のようなモジュール割付も行うようにされる。
【０１４１】
実際のＭＨＥＧ方式によるデータサービスでは、或るアプリケーションにおける複数シーン間の優先順位は、現在表示出力中のシーンに依存して変更される場合がある。このような出力中のシーンに応じて変更される優先順位も、前述した優先順位情報に基づいて得ることが出来る。
そこで、本実施の形態では、ＭＨＥＧデコーダブロック８４のプログラムとして、現在あるシーンを出力しているときに、その出力中のシーンを基準として他のシーンの優先順位を管理する、ネクストシーンマネージャ（Next Scene Manager）を起動させることとする。
【０１４２】
ここで、ネクストシーンマネージャの管理例として、図１７に示したシーンのうちで現在シーンＡを出力中の場合に、ネクストシーンマネージャにより管理されている優先順位が図１８に示したものであったとする。つまり、優先順位として（１）シーンＡ→（２）シーンＣ→（３）シーンＥ→（４）シーンＢ→（５）シーンＤの順位で管理されているものとする。このような優先順位は、実際には、図に示すようなプライオリティ値によって決定される。このプライオリティ値が大きいほど優先順位は高いことになり、ここでは、シーンＡに対する他のシーンのプライオリティ値として、シーンＣが‘１０’、シーンＥが‘９’、シーンＢが‘７’、シーンＤが‘１’とされている。
そして、このときＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールは、図２０（ａ）に示すように、シーンＡ，Ｅ，Ｃ，Ｂであるとする。
【０１４３】
この状態の下で、例えばシーンＡからシーンＣにトランジジョンするための要求が行われたとすると、ＭＨＥＧデコーダブロック８４では、図２０（ａ）に示した格納状態にあるＤＳＭ−ＣＣバッファ９１からシーンＣのデータにアクセスして、これを出力するための処理を実行する。
【０１４４】
また、ＭＨＥＧデコーダブロック８４では、シーンＣにトランジションしたことに対応して、ネクストシーンマネージャによりシーンの優先順位を、例えば図１９に示すように更新して管理する。
この図では、現在出力中のシーンＣを筆頭に、（１）シーンＣ→（２）シーンＢ→（３）シーンＡ→（４）シーンＤ→（５）シーンＥの順位であるとして管理している。また、この場合のシーンＣに対する他のシーンのプライオリティ値は、それぞれシーンＢが‘７’、シーンＡが‘６’、シーンＤが‘４’、シーンＥが‘２’とされており、上記優先順位はこのプライオリティ値に従って決定されたものである。このように、現在出力中のシーンに応じて、シーン間の優先順位は変更される。
【０１４５】
そして、本実施の形態では、上記図１９に示すようにして更新されたシーン間の優先順位に基づいて、次のようにしてＤＳＭ−ＣＣバッファ９１に格納されるシーンモジュールの内容を更新する。
例えば、ＣＰＵ８０は、上記図１９に示す、現在ネクストシーンマネージャにより管理されているシーン間の優先順位と、図２０（ａ）のＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールとの比較を行う。
すると、ＤＳＭ−ＣＣバッファ９１には、図１９に示す優先順位として１位のシーンＣ、２位のシーンＢ、３位のシーンＡ、及び５位（最下位）のシーンＥが格納されており、４位のシーンＤが格納されていないことが分かる。
【０１４６】
そこで、ＣＰＵ８０においては、ＤＳＭ−ＣＣバッファ９１に格納されるシーンモジュールが、現在管理されている優先順位における上位４つのシーンとなるように制御を実行する。つまり、この場合であれば、図２０（ｂ）に示すようにして、シーンＥの代わりにシーンＤのモジュールがＤＳＭ−ＣＣバッファ９１に格納されるようにして、結果的に上位４つのシーンモジュールが格納されるようにするものである。
【０１４７】
このためには、先ず、例えばデマルチプレクサドライバ８２からデマルチプレクサ７０に対して、シーンＤのモジュールを得るためのフィルタ条件を出力させるように、ＣＰＵ８０における制御処理部８０が指示をするようにされる。これにより、キュー７１においてシーンデータのモジュールのために割り当てられたメモリ領域にシーンＤのモジュールが格納される。そして、このキュー７１のメモリ領域に得られたシーンＤのモジュールが、シーンＥのモジュールと入れ替わるようにして、ＤＳＭ−ＣＣバッファ９１に対する書き込み制御を実行するものである。この書き込み制御も、例えば制御処理部８０が実行するようにされればよい。
なお、シーン切り換えに応じて変更されたシーンの優先順位と、それまでのＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールデータとの比較で、２以上のシーンモジュールを入れ替える必要が有れば、上記した制御動作に準じてこれらのシーンモジュールについての取り込みを行うようにされる。
【０１４８】
例えば、或るシーンを出力させている状態の下で、ユーザがシーンの切り換え操作を行う場合、やはり実際には、その時点でネクストシーンマネージャにより管理されている優先順位に従って、切り換えのシーンが選択される可能性が高い。
このため、上記のようにして、現在出力中のシーンに応じて決定されるシーンの優先順位の上位のシーンから優先的にＤＳＭ−ＣＣバッファ９１に取り込むように、トランスポート部５３におけるモジュール割付を規定すれば、例えば、先に述べたように、シーンのトランジジョンの要求があったときに、このシーンのモジュールがＤＳＭ−ＣＣバッファ９１に格納されていないといった状況が生じる可能性は極力回避される。従って、ほとんどの場合、シーンの切り換え操作に応じて即座にシーンの切り換えが行われることになるものである。
【０１４９】
なお、シーン切り換えに応じて変更されたシーンの優先順位に応じて、例えば上記図２０（ａ）から図２０（ｂ）に示したようにして、ＤＳＭ−ＣＣバッファ９１の格納状態を遷移させるまでには、実際には、或る程度の時間がかかるのであるが、例えば、シーンＣの出力が開始されて後において最初のシーン切り換え操作が行われるまでには、通常、或る程度の期間が存在する。つまり、シーンＣが出力開始されてしばらくはユーザは、シーンＣの画像を見ているのが普通である。そして、たいていはこの間にＤＳＭ−ＣＣバッファ９１におけるシーンデータの入れ替えはほぼ終了しているため、実用上は問題にはならないものである。
【０１５０】
続いて、上記図１８〜図２０により説明したモジュール割付を実現するための処理動作について、図２１のフローチャートを参照して説明する。この図に示す処理は、ＣＰＵ８０が実行するものとされる。つまり、制御処理部８１の全体制御に基づいて、デマルチプレクサドライバ８２、ＤＳＭ−ＣＣデコーダブロック８３、及びＭＨＥＧデコーダブロック８４が適宜所要の制御処理を実行することにより実現されるものである。
また、この図においては、例えばユーザによるシーン切り換え要求のための操作等が行われたことでシーン切り換えが必要とされた場合における、シーンモジュール割付に関する対応処理を示している。
【０１５１】
この図に示すルーチンにおいては、先ずステップＳ１０１において、シーン切り換え前のネクストシーンマネージャのシーン優先順位に従って挙げられたシーン候補と、シーン切り換え後のネクストシーンマネージャのシーン優先順位に従って挙げられたシーン候補とを比較して、これらのシーン候補間で一致しないものをリストアップする。また、上記シーン候補間で共通に一致したシーンについては、シーン切り換えに応じてシーンネクストマネージャが扱うべき「シーンリスト」に対して登録が行われる。
この処理は、例えばＭＨＥＧデコーダブロック８４において、ネクストシーンマネージャを起動させることにより実現される。
【０１５２】
続くステップＳ１０２においては、ＭＨＥＧデコーダブロック８４の処理として、上記ステップＳ１０１にてリストアップされた一致しないシーン候補のうちで、シーン切り換え前のシーン候補とされていたものについては削除し、シーン切り換え後に候補とされているシーンについてはシーンリストに追加するための処理が実行される。
この処理によって、シーン切り換えに応じて候補となる複数シーンが、シーンリストとして用意されることになる。
【０１５３】
続くステップＳ１０３においては、ネクストシーンマネージャの機能を用い、上記シーンリストとして登録されたシーンについて、シーン切り換えに応じて変更されたシーンの優先順位に従ってソートを実行するようにされる。
これにより、図１８に示すネクストシーンマネージャの管理状態から、図１９に示すネクストシーンマネージャの管理状態に移行することになる。
なお、上記ステップＳ１０１〜Ｓ１０３までに示す処理のうち、ステップＳ１０１，及びＳ１０２の処理については、先の図１８及び図１９に依る説明では特に言及していない。これは、図１８、図１９に示した場合においては、シーンＡからシーンＣへのシーン切り換えによっては、シーン候補の入れ替えが無いことによる。即ち、図１８から図１９の遷移に対応するシーン切り換えに際しては、ステップＳ１０１において一致しないシーンがリストアップされず、全てのシーンが一致したとして、シーンリストに登録されたことになる。
【０１５４】
ステップＳ１０３に続いては、ステップＳ１０４の処理が実行される。ここでは、上記ステップＳ１０３においてソートされたシーンリスト上において、優先順位的に最上位のシーンについての処理を開始する。つまり、このシーンを「現シーン」として扱って以降の処理を実行していくようにされる。
また、ステップＳ１０４においての「優先順位的に最上位のシーン」とは、現在出力中とされているシーン（図１９であればシーンＣ）を除いて、最も優先順位の高いシーンが選択される。つまり、図１９の場合で有ればシーンＢが選択されることになる。但し、例えば図１９に示す優先順位の管理状態が得られたとき、シーンＣがＤＳＭ−ＣＣバッファ９１に格納されていない場合には、例外的にこのシーンＣを現シーンとして扱うようにステップＳ１０４での処理が行われるものとする。
【０１５５】
続くステップＳ１０５においては、上記ステップＳ１０４にて選択された現シーンのデータにより形成されるモジュール（シーンモジュール）のデータサイズをチェックする。これは、例えば現シーンモジュールに対応する制御情報であるＤＩＩ（図８参照）をカルーセルのデータから取り込み、例えばＤＳＭ−ＣＣデコーダブロック８３が、この取り込んだＤＩＩにおけるモジュールのデータサイズを示す情報を参照することで識別が可能とされる。ここで得られた現シーンモジュールのデータサイズの情報は一時保持されて、後述するステップＳ１０７の判別処理に用いられる。
【０１５６】
ステップＳ１０６においては、現シーンモジュールがＤＳＭ−ＣＣバッファ９１に既に取り込まれている状態にあるか否かが判別され、ここで肯定結果が得られればステップＳ１１０に進んで、シーンリスト上で、これまでの現シーンに対して次の優先順位が与えられているシーンを現シーンとして選択して、この現シーンとしての処理を開始させるための処理を実行する。
これに対して、ステップＳ１０６において否定結果が得られた場合には、ステップＳ１０７の処理に移行する。
【０１５７】
ステップＳ１０７においては、現在のＤＳＭ−ＣＣバッファ９１の残り容量（データ取込可能容量）が、ステップＳ１０５にてチェックされた現シーンモジュールのサイズよりも大きいか否かを判別する。そして、肯定結果が得られた場合、つまり、現在のＤＳＭ−ＣＣバッファ９１の残り容量として、現シーンモジュールを取り込んで格納するだけの余裕があると判別された場合には、ステップＳ１１１に進んで現シーンモジュールのデータをカルーセルからキュー７１に蓄積し、これをＤＳＭ−ＣＣバッファ９１に対して取り込んで格納するための処理が実行される。この処理を実現するためのＣＰＵ８０の制御動作とこれに伴う各部の信号処理動作は、例えば図２０の説明において述べたとおりである。
そして、上記ステップＳ１１１の処理を実行した後はステップＳ１１０の処理を経た上で、ステップＳ１０５の処理に戻るようにされる。
【０１５８】
また、ステップＳ１０７において否定結果が得られ、現在のＤＳＭ−ＣＣバッファ９１の残り容量が、ステップＳ１０５にてチェックされた現シーンモジュールのサイズよりも小さいと判別された場合には、ステップＳ１０８に進む。
ステップＳ１０８においては、現在のネクストシーンマネージャの優先順位管理と、現在ＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールとを比較して、現在ＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールにおいて、現在最も優先順位（プライオリティ）が低いものとして管理されているシーンモジュールを特定する。そして、次のステップＳ１０９において、この特定されたシーンモジュールのプライオリティが、現シーンよりも低いか否かを判別するようにされる。
【０１５９】
ステップＳ１０９において、ステップＳ１０８により特定されたシーンモジュールのプライオリティが現シーンよりも低いとされた場合には、ステップＳ１１２に進んで、この特定されたシーンモジュールをＤＳＭ−ＣＣバッファから削除してステップＳ１０７に戻るようにされる。この処理により、現シーンモジュールが取り込み可能なＤＳＭ−ＣＣバッファ９１の残り容量が得られるまで、ＤＳＭ−ＣＣバッファ９１から優先順位（プライオリティ）の最も低いシーンモジュール（但し現シーンよりもプライオリティが低いもののみが対象となる）が削除されていくことになる。
【０１６０】
そして、ステップＳ１０９において否定結果が得られた場合、つまり、ステップＳ１０８にて特定されたシーンモジュールのプライオリティが、現シーンよりも高いことが判別された場合であるが、この段階では、結果的に、ＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールは、現在のネクストシーンマネージャにより管理されているシーンの優先順位に対応していることになる。つまり、先に説明した具体例に従えば、図１９に示したネクストシーンマネージャの管理に対応して、図２０（ｂ）に示すシーンモジュールの格納状態が得られるものである。この場合には、図のようにして、これまでのモジュール割付のための処理が終了されることになる。
【０１６１】
なお、本発明としては、ＤＳＭ−ＣＣ方式を採用した場合に限定されるものではなく、実施の形態において説明した送信フォーマットに準ずる伝送方式であれば本発明の適用が可能とされる。また、本発明が適用されるシステムとしてもデジタル衛星放送システムに限定されるものではなく、例えばケーブルテレビジョンなどの放送や、インターネット等において適用することも可能である。
【０１６２】
【発明の効果】
以上説明したように本発明は、伝送方式として、１シーン分のシーンデータが原則１モジュールを形成するものとされたうえで、１以上のモジュールからなる伝送データをカルーセル方式により伝送する場合に対応する受信装置として、カルーセル（伝送情報）から抽出してキュー（メモリ手段）に取り込むべきシーンデータとしてのモジュールを、シーンの優先順位に従って決定するように規定される。
例えば、キューに対するモジュールの取込順を特に規定しない場合、表示出力に必要なシーンデータを得て、これをシーンデータ格納手段（ＤＳＭ−ＣＣバッファ）に取り込むまでには相応の時間を要することになる。また、これを解消しようとして、目的のシーンデータとしてのモジュールが出来るだけ迅速にシーンデータ格納手段にて得られるようにするためには、多くのキュー数が必要となってしまう。
これに対して、本発明では、上記構成によって優先順位に従ってシーンデータとしてのモジュールを取り込むようにされるため、制限されたキュー数の構成のもとであっても、表示出力に必要、又は必要とされる可能性の高いシーンデータが比較的迅速に得られることになる。つまり、本発明では、キュー数が少なくてもシーン出力、及びシーン切り換えに迅速に対応できることになる。また、逆に言えば、本発明を適用せずに迅速なシーン出力、シーン切り換えを実現しようとした場合と比較して、キュー数を削減することが可能であり、それだけＩＲＤ（受信装置）の回路規模の縮小及び低コスト化を図ることが可能となる。
【０１６３】
また、現在出力されているシーンに応じて変更される優先順位に応じて、受信データのカルーセルから取り込むべきシーンデータとしてのモジュールが決定されるため、常にシーン表示の切り換えに対応して、シーンデータ格納手段には優先順位的に上位のシーンデータから優先的に格納されている状態が得られることになる。
この場合、シーン表示の切り換え操作によって選択されるシーンのシーンデータがシーンデータ格納手段に格納されている可能性が非常に高く、これにより、例えばユーザによってシーン表示の切り換え操作が行われたとしても、ほとんどの場合において、そのシーンの切り換えが迅速に行われることになる。この構成は、シーンデータ格納手段（ＤＳＭ−ＣＣバッファ）の容量に制限があって、多数のシーンデータを格納することが出来ないような条件の下で特に有効となる。
【図面の簡単な説明】
【図１】本発明の実施の形態のデジタル衛星放送受信システムの構成例を示すブロック図である。
【図２】本実施の形態における受信設備の構築例を示すブロック図である。
【図３】ＩＲＤのためのリモートコントローラの外観を示す正面図である。
【図４】放送画面とＧＵＩ画面との切り換えを示す説明図である。
【図５】地上局の構成例を示すブロック図である。
【図６】地上局から送信されるデータを示すチャート図である。
【図７】送信データの時分割多重化構造を示す説明図である。
【図８】ＤＳＭ−ＣＣによる送信フォーマットを示す説明図である。
【図９】トランスポートストリームのデータ構造図である。
【図１０】ＰＳＩのテーブル構造を示す説明図である。
【図１１】ＩＲＤの構成を示す説明図である。
【図１２】本実施の形態としてのデータサービスのディレクトリ構造に対するマッピング例を示す説明図である。
【図１３】本実施の形態としてのデータサービスのディレクトリ構造に対する他のマッピング例を示す説明図である。
【図１４】データサービスのディレクトリ構造の一例を示す説明図である。
【図１５】データサービスのディレクトリ構造に対するマッピング例を示す説明図である。
【図１６】本実施の形態のシーンデータのモジュールの取込動作を示す説明図である。
【図１７】シーンのトランジション例を示す説明図である。
【図１８】図１７に示すシーンのトランジション例に従った、ネクストシーンマネージャにおいて管理されるシーン優先順位例を示す説明図である。
【図１９】図１７に示すシーンのトランジション例に従った、ネクストシーンマネージャにおいて管理されるシーン優先順位例を示す説明図である。
【図２０】図１８から図１９の遷移として示すシーン優先順位の変更に応じたシーンデータのモジュールの取込動作を示す説明図である。
【図２１】本実施の形態のシーン切り換えに応じたモジュール割付けを実現するためのフローチャートである。
【符号の説明】
１ 地上局、２ 衛星、３ 受信設備、５ 課金サーバ、６ テレビ番組素材サーバ、７ 楽曲素材サーバ、８ 音声付加情報サーバ、９ ＧＵＩデータサーバ、１０ キー情報サーバ、１１ パラボラアンテナ、１３ ストレージデバイス、１３Ａ ＭＤレコーダ／プレーヤ、１４ モニタ装置、１６ ＩＥＥＥ１３９４バス、２１Ａ テレビ番組表示エリア、２１Ｂ リスト、２１Ｃ テキスト表示エリア、２１Ｄ ジャケット表示エリア、２２ 歌詞表示ボタン、２３ プロフィール表示ボタン、２４ 情報表示ボタン、２５ 予約録音ボタン、２６ 予約済一覧表示ボタン、２７ 録音履歴ボタン、２８ ダウンロードボタン、３１ テレビ番組素材登録システム、３２ 楽曲素材登録システム、３３ 音声付加情報登録システム、３４ ＧＵＩ用素材登録システム、３５ ＡＶサーバ、３６Ａ ＭＰＥＧオーディオエンコーダ、３６Ｂ ＡＴＲＡＣエンコーダ、３７ 音声付加情報データベース、３８ ＧＵＩ素材データベース、３９ テレビ番組送出システム、４０Ａ ＭＰＥＧオーディオサーバ、４０Ｂ ＭＰＥＧオーディオサーバ、４１ 音声付加情報送出システム、４２ ＧＵＩオーサリングシステム、４３Ａ ＭＰＥＧオーディオ送出システム、４３Ｂ ＡＴＲＡＣオーディオ送出システム、４４ ＤＳＭ−ＣＣエンコーダ、４５ マルチプレクサ、４６ 電波送出システム、５１ チューナ／フロントエンド部、５２ デスクランブラ、５３ トランスポート部、５４ ＭＰＥＧ２オーディオデコーダ、５４Ａ メモリ、５５ ＭＰＥＧ２ビデオデコーダ、５５Ａ メモリ、５６ Ｄ／Ａコンバータ、５７ スイッチ回路、５８ 表示処理部、５９ 光デジタル出力インターフェイス、６０ ＩＥＥＥ１３９４インターフェイス、６１ マンマシンインターフェイス、６２ ＩＣカードスロット、６３ モデム、６４ リモートコントローラ、６５ ＩＣカード、７０ デマルチプレクサ、７１ キュー、８１ 制御処理部、８２ ＤｅＭＵＸドライバ、８３ ＤＳＭ−ＣＣデコーダブロック、８４ ＭＨＥＧデコーダブロック、９０ メインメモリ、９１ ＤＳＭ−ＣＣバッファ、１０１ 電源キー、１０２ 数字キー、１０３ 画面表示切換キー、１０４ インタラクティブ切換キー、１０５ａ 矢印キー、１０５ ＥＰＧキーパネル部、１０６ チャンネルキー、Ｔ１ 入力端子、Ｔ２ アナログビデオ出力端子、Ｔ３ アナログオーディオ出力端子、Ｔ４ アナログオーディオ出力端子
【発明の属する技術分野】
本発明は、例えばデジタル衛星放送などのデータサービスにおける受信設備側に設けられるとされる受信装置及び受信方法に関するものである。
【０００２】
【従来の技術】
近年、デジタル衛星放送の普及が進んでいる。デジタル衛星放送は、例えば既存のアナログ放送と比較してノイズやフェージングに強く、高品質の信号を伝送することが可能である。また、周波数利用効率が向上され、多チャンネル化も図ることが可能になる。具体的には、デジタル衛星放送であれば１つの衛星で数百チャンネルを確保することも可能である。このようなデジタル衛星放送では、スポーツ、映画、音楽、ニュースなどの専門チャンネルが多数用意されており、これらの専門チャンネルでは、それぞれの専門のコンテンツに応じたプログラムが放送されている。
【０００３】
そして、上記のようなデジタル衛星放送システムを利用して、ユーザが楽曲等の音声データをダウンロードできるようにしたり、いわゆるテレビショッピングとして、例えばユーザが放送画面を見ながら何らかの商品についての購買契約を結べるようにしたりすることが提案されている。つまりは、デジタル衛星放送システムとして、通常の放送内容と並行したデータサービス放送を行うものである。
【０００４】
一例として、楽曲データのダウンロードであれば、放送側においては、放送番組と並行して、楽曲データを多重化して放送するようにする。また、この楽曲データのダウンロードに際しては、ＧＵＩ(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 Info Indication)という制御メッセージが生成される。
上記ＤＳＩ及びＤＩＩは、受信側（ＩＲＤ１２）で受信データからモジュールを取得する際に必要となる情報であり、ＤＳＩは主として、次に説明するカルーセル（モジュール）の識別子、カルーセル全体に関連する情報（カルーセルが１回転する時間、カルーセル回転のタイムアウト値）等の情報を有する。また、データサービスのルートディレクトリ（Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ）の所在を知るための情報も有する（オブジェクトカルーセル方式の場合）。
【００６７】
ＤＩＩは、カルーセルに含まれるモジュールごとに対応する情報であり、モジュールごとのサイズ、バージョン、そのモジュールのタイムアウト値などの情報を有する。
【００６８】
そして、図８（ｆ）に示すように、上記ＤＤＢ、ＤＳＩ、ＤＩＩの３種類のメッセージをセクションのデータ単位に対応させて周期的に、かつ、繰り返し送出するようにされる。これにより、受信機側では例えば目的のＧＵＩ画面（シーン）を得るのに必要なオブジェクトが含まれているモジュールをいつでも受信できるようにされる。
本明細書では、このような伝送方式を回転木馬に例えて「カルーセル方式」といい、図８（ｆ）に示すようにして模式的に表されるデータ伝送形態をカルーセルというものとする。
また、「カルーセル方式」としては、「データカルーセル方式」のレベルと「オブジェクトカルーセル方式」のレベルとに分けられる。特にオブジェクトカルーセル方式では、ファイル、ディレクトリ、ストリーム、サービスゲートウェイなどの属性を持つオブジェクトをデータとしてカルーセルを用いて転送する方式で、ディレクトリ構造を扱えることがデータカルーセル方式と大きく異なる。本実施の形態のシステムでは、オブジェクトカルーセル方式を採用するものとされる。
【００６９】
また、上記のようにしてカルーセルにより送信されるＧＵＩデータ、つまり、図５のＤＳＭ−ＣＣエンコーダ４４から出力されるデータとしては、トランスポートストリームの形態により出力される。このトランスポートストリームは例えば図９に示す構造を有する。
図９（ａ）には、トランスポートストリームが示されている。このトランスポートストリームとはＭＰＥＧシステムで定義されているビット列であり、図のように１８８バイトの固定長パケット（トランスポートパケット）の連結により形成される。
【００７０】
そして、各トランスポートパケットは、図９（ｂ）に示すようにヘッダと特定の個別パケットに付加情報を含めるためのアダプテーションフィールドとパケットの内容（ビデオ／オーディオデータ等）を表すペイロード（データ領域）とからなる。
【００７１】
ヘッダは、例えば実際には４バイトとされ、図９（ｃ）に示すように、先頭には必ず同期バイトがあるようにされ、これより後ろの所定位置にそのパケットの識別情報であるＰＩＤ（Ｐａｃｋｅｔ＿ＩＤ）、スクランブルの有無を示すスクランブル制御情報、後続するアダプテーションフィールドやペイロードの有無等を示すアダプテーションフィールド制御情報が格納されている。
【００７２】
これらの制御情報に基づいて、受信装置側ではパケット単位でデスクランブルを行い、また、デマルチプレクサによりビデオ／オーディオ／データ等の必要パケットの分離・抽出を行うことができる。また、ビデオ／オーディオの同期再生の基準となる時刻情報を再生することもここで行うことができる。
【００７３】
また、これまでの説明から分かるように、１つのトランスポートストリームには複数チャンネル分の映像／音声／データのパケットが多重されているが、それ以外にＰＳＩ(Program Specific Information)といわれる選局を司るための信号や、限定受信（個人の契約状況により有料チャンネルの受信可不可を決定する受信機能）に必要な情報（ＥＭＭ／ＥＣＭ）、ＥＰＧなどのサービスを実現するためのＳＩ(Service Information)が同時に多重されている。ここでは、ＰＳＩについて説明する。
【００７４】
ＰＳＩは、図１０に示すようにして、４つのテーブルで構成されている。それぞれのテーブルは、セクション形式というＭＰＥＧ Ｓｙｓｔｅｍに準拠した形式で表されている。
図１０（ａ）には、ＮＩＴ(Network Informataion Table)及びＣＡＴ(Conditional Access Table)のテーブルが示されている。
ＮＩＴは、全キャリアに同一内容が多重されている。キャリアごとの伝送諸元（偏波面、キャリア周波数、畳み込みレート等）と、そこに多重されているチャンネルのリストが記述されている。ＮＩＴのＰＩＤとしては、ＰＩＤ＝0x0010とされている。
【００７５】
ＣＡＴもまた、全キャリアに同一内容が多重される。限定受信方式の識別と契約情報等の個別情報であるＥＭＭ(Entitlement Management Message)パケットのＰＩＤが記述されている。ＰＩＤとしては、ＰＩＤ＝0x0001により示される。
【００７６】
図１０（ｂ）には、キャリアごとに固有の内容を有する情報として、ＰＡＴが示される。ＰＡＴには、そのキャリア内のチャンネル情報と、各チャンネルの内容を表すＰＭＴのＰＩＤが記述されている。ＰＩＤとしては、ＰＩＤ＝0x0000により示される。
【００７７】
また、キャリアにおけるチャンネルごとの情報として、図１０（ｃ）に示すＰＭＴ(Program Map Table)のテーブルを有する。
ＰＭＴは、チャンネル別の内容が多重されている。例えば、図１０（ｄ）に示すような、各チャンネルを構成するコンポーネント（ビデオ／オーディオ等）と、デスクランブルに必要なＥＣＭ(Encryption Control Message)パケットのＰＩＤが記述されているＰＭＴのＰＩＤは、ＰＡＴにより指定される。
【００７８】
１−５．ＩＲＤ
続いて、受信設備３に備えられるＩＲＤ１２の一構成例について図１１を参照して説明する。
【００７９】
この図に示すＩＲＤ１２において、入力端子Ｔ１には、パラボラアンテナ１１のＬＮＢ１５により所定の周波数に変換された受信信号を入力してチューナ／フロントエンド部５１に供給する。
チューナ／フロントエンド部５１では、ＣＰＵ(Central Processing Unit)８０からの伝送諸元等を設定した設定信号に基づいて、この設定信号により決定されるキャリア（受信周波数）を受信して、例えばビタビ復調処理や誤り訂正処理等を施すことで、トランスポートストリームを得るようにされる。
チューナ／フロントエンド部５１にて得られたトランスポートストリームは、デスクランブラ５２に対して供給される。また、チューナ／フロントエンド部５１では、トランスポートストリームからＰＳＩのパケットを取得し、その選局情報を更新すると共に、トランスポートストリームにおける各チャンネルのコンポーネントＰＩＤを得て、例えばＣＰＵ８０に伝送する。ＣＰＵ８０では、取得したＰＩＤを受信信号処理に利用することになる。
【００８０】
デスクランブラ５２では、ＩＣカード６５に記憶されているデスクランブルキーデータをＣＰＵ８０を介して受け取ると共に、ＣＰＵ８０によりＰＩＤが設定される。そして、このデスクランブルキーデータとＰＩＤとに基づいてデスクランブル処理を実行し、トランスポート部５３に対して伝送する。
【００８１】
トランスポート部５３は、デマルチプレクサ７０と、例えばＤＲＡＭ等により構成されるキュー（Queue）７１とからなる。キュー（Queue）７１は、モジュール単位に対応した複数のメモリ領域が列となるようにして形成されているものとされ、例えば本実施の形態では、３２列のメモリ領域が備えられる。つまり、最大で３２モジュールの情報を同時に格納することができる。
【００８２】
デマルチプレクサ７０の概略的動作としては、ＣＰＵ８０のＤｅＭＵＸドライバ８２により設定されたフィルタ条件に従って、デスクランブラ５２から供給されたトランスポートストリームから必要なトランスポートパケットを分離し、必要があればキュー７１を作業領域として利用して、先に図７（ｅ）〜（ｈ）により示したような形式のデータを得て、それぞれ必要な機能回路部に対して供給する。
デマルチプレクサ７０にて分離されたＭＰＥＧビデオデータは、ＭＰＥＧ２ビデオデコーダ５５に対して入力され、ＭＰＥＧオーディオデータは、ＭＰＥＧオーディオデコーダ５４に対して入力される。これらデマルチプレクサ７０により分離されたＭＰＥＧビデオ／オーディオデータの個別パケットは、ＰＥＳ(Packetized Elementary Stream)と呼ばれる形式でそれぞれのデコーダに入力される。
【００８３】
また、トランスポートストリームにおけるＭＨＥＧコンテンツのデータについては、デマルチプレクサ７０によりトランスポートストリームからトランスポートパケット単位で分離抽出されながらキュー７１の所要のメモリ領域に書き込まれていくことで、モジュール単位にまとめられるようにして形成される。そして、このモジュール単位にまとめられたＭＨＥＧコンテンツのデータは、ＣＰＵ８０の制御によってデータバスを介して、メインメモリ９０内のＤＳＭ−ＣＣバッファ９１に書き込まれて保持される。
【００８４】
また、トランスポートストリームにおける４倍速ＡＴＲＡＣデータ（圧縮オーディオデータ）も、例えばトランスポートパケット単位で必要なデータがデマルチプレクサ７０により分離抽出されてＩＥＥＥ１３９４インターフェイス６０に対して出力される。また、ＩＥＥＥ１３９４インターフェイス６０を介した場合には、オーディオディオデータの他、ビデオデータ及び各種コマンド信号等を送出することも可能とされる。
【００８５】
ＰＥＳとしての形式によるＭＰＥＧビデオデータが入力されたＭＰＥＧ２ビデオデコーダ５５では、メモリ５５Ａを作業領域として利用しながらＭＰＥＧ２フォーマットに従って復号化処理を施す。復号化されたビデオデータは、表示処理部５８に供給される。
【００８６】
表示処理部５８には、上記ＭＰＥＧ２ビデオデコーダ５５から入力されたビデオデータと、後述するようにしてメインメモリ９０のＭＨＥＧバッファ９２にて得られるデータサービス用のＧＵＩ画面等のビデオデータが入力される。表示処理部５８では、このようにして入力されたビデオデータについて所要の信号処理を施して、所定のテレビジョン方式によるアナログオーディオ信号に変換してアナログビデオ出力端子Ｔ２に対して出力する。
これにより、アナログビデオ出力端子Ｔ２とモニタ装置１４のビデオ入力端子とを接続することで、例えば先に図４に示したような表示が行われる。
【００８７】
また、ＰＥＳによるＭＰＥＧオーディオデータが入力されるＭＰＥＧ２オーディオデコーダ５４では、メモリ５４Ａを作業領域として利用しながらＭＰＥＧ２フォーマットに従って復号化処理を施す。復号化されたオーディオデータは、Ｄ／Ａコンバータ５６及び光デジタル出力インターフェイス５９に対して供給される。
【００８８】
Ｄ／Ａコンバータ５６では、入力されたオーディオデータについてアナログ音声信号に変換してスイッチ回路５７に出力する。スイッチ回路５７では、アナログオーディオ出力端子Ｔ３又はＴ４の何れか一方に対してアナログ音声信号を出力するように信号経路の切換を行う。
ここでは、アナログオーディオ出力端子Ｔ３はモニタ装置１４の音声入力端子と接続されるために設けられているものとされる。また、アナログオーディオ出力端子Ｔ４はダウンロードした楽曲をアナログ信号により出力するための端子とされる。
また、光デジタル出力インターフェイス５９では、入力されたデジタルオーディオデータを光デジタル信号に変換して出力する。この場合、光デジタル出力インターフェイス５９は、例えばＩＥＣ９５８に準拠する。
【００８９】
メインメモリ９０は、ＣＰＵ８０が各種制御処理を行う際の作業領域として利用されるものである。そして、本実施の形態では、このメインメモリ９０において、前述したＤＳＭ−ＣＣバッファ９１と、ＭＨＥＧバッファ９２としての領域が割り当てられるようになっている。
ＭＨＥＧバッファ９２には、ＭＨＥＧ方式によるスクリプトの記述に従って生成された画像データ（例えばＧＵＩ画面の画像データ）を生成するための作業領域とされ、ここで生成された画像データはバスラインを介して表示処理部５８に供給される。
【００９０】
ＣＰＵ８０は、ＩＲＤ１２における全体制御を実行する。このなかには、デマルチプレクサ７０におけるデータ分離抽出についての制御も含まれる。
また、獲得したＭＨＥＧコンテンツのデータについてデコード処理を施すことで、スクリプトの記述内容に従ってＧＵＩ画面（シーン）を構成して出力するための処理も実行する。
【００９１】
このため、本実施の形態のＣＰＵ８０としては、主たる制御処理を実行する制御処理部８１に加え、例えば少なくとも、ＤｅＭＵＸドライバ８２、ＤＳＭ−ＣＣデコーダブロック８３、及びＭＨＥＧデコーダブロック８４が備えられる。本実施の形態では、このうち、少なくともＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４については、ソフトウェアにより構成される。
ＤｅＭＵＸドライバ８２は、入力されたトランスポートストリームのＰＩＤに基づいてデマルチプレクサ７０におけるフィルタ条件を設定する。
ＤＳＭ−ＣＣデコーダブロック８３は、ＤＳＭ−Ｍａｎａｇｅｒとしての機能を有するものであり、ＤＳＭ−ＣＣバッファ９１に格納されているモジュール単位のデータについて、ＭＨＥＧコンテンツのデータに再構築する。また、ＭＨＥＧデコーダブロック８４からのアクセスに従って所要のＤＳＭ−ＣＣデコード等に関連する処理を実行する。
【００９２】
ＭＨＥＧデコーダブロック８４は、ＤＳＭ−ＣＣデコーダブロック８３により得られたＭＨＥＧコンテンツのデータ、つまり、ＤＳＭ−ＣＣバッファ９１にて得られているＭＨＥＧコンテンツのデータにアクセスして、シーン出力のためのデコード処理を行う。つまり、そのＭＨＥＧコンテンツのスクリプトファイルにより規定されているオブジェクト間の関係を実現していくことで、シーンを形成するものである。この際、シーンとしてＧＵＩ画面を形成するのにあたっては、ＭＨＥＧバッファ９２を利用して、ここで、スクリプトファイルの内容に従ってＧＵＩ画面の画像データを生成するようにされる。
【００９３】
ＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４間のインターフェイスには、Ｕ−Ｕ ＡＰＩ(Application Portability Interface)が採用される。
Ｕ−Ｕ ＡＰＩは、ＤＳＭ Ｍａｎａｇｅｒオブジェクト（ＤＳＭの機能を実現するサーバオブジェクト）にアクセスするためのインターフェイスであり、これにより、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ，Ｄｉｒｅｃｔｏｒｙ，Ｆｉｌｅ，Ｓｔｒｅａｍ，Ｓｔｒｅａｍ Ｅｖｅｎｔなどのオブジェクトに対する操作を行う。
クライアントオブジェクトは、このＡＰＩを使用することによって、これらのオブジェクトに対して操作を行うことができる。
【００９４】
ここで、ＣＰＵ８０の制御によりトランスポートストリームから１シーンを形成するのに必要な目的のオブジェクトを抽出するための動作例について説明しておく。
【００９５】
ＤＳＭ−ＣＣでは、トランスポートストリーム中のオブジェクトの所在を示すのにＩＯＲ(Interoperable Object Reference)が使用される。ＩＯＲには、オブジェクトを見つけ出すための力ルーセルに対応する識別子、オブジェクトの含まれるモジュールの識別子（以下ｍｏｄｕｌｅ＿ｉｄと表記）、１つのモジュール中でオブジェクトを特定する識別子（以下ｏｂｊｅｃｔ＿ｋｅｙと表記）のほかに、オブジェクトの含まれるモジュールの情報を持つＤＩＩを識別するためのタグ（ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ）情報を含んでいる。
また、モジュール情報を持つＤＩＩには、１つ以上のモジュールそれぞれについてのｍｏｄｕｌｅ＿ｉｄ、モジュールの大きさ、バージョンといった情報と、そのモジュールを識別するためのタグ（ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ）情報を含んでいる。
【００９６】
トランスポートストリームから抜き出されたＩＯＲがＣＰＵ８０において識別された場合に、そのＩＯＲで示されたオブジェクトを受信、分離して得るプロセスは、例えば次のようになる。
（Ｐｒ１） ＣＰＵ８０のＤｅＭＵＸドライバ８２では、ＩＯＲのａｓｓｏｃｉａｔｉｏｎ＿ｔａｇと同じ値を持つエレメンタリーストリーム（以下ＥＳと表記）を、カルーセルにおけるＰＭＴのＥＳループから探し出してＰＩＤを得る。このＰＩＤを持つＥＳにＤＩＩが含まれていることになる。
（Ｐｒ２） このＰＩＤとｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎとをフィルタ条件としてデマルチプレクサ７０に対して設定する。これにより、デマルチプレクサ７０では、ＤＩＩを分離してＣＰＵ８０に対して出力する。
（Ｐｒ３） ＤＩＩの中で、先のＩＯＲに含まれていたｍｏｄｕｌｅ＿ｉｄに相当するモジュールのａｓｓｏｃｉａｔｉｏｎ＿ｔａｇを得る。
（Ｐｒ４） 上記ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇと同じ値を有するＥＳを、ＰＭＴのＥＳループ（カルーセル）から探し出し、ＰＩＤを得る。このＰＩＤを有するＥＳに目的とするモジュールが含まれる。
（Ｐｒ５） 上記ＰＩＤとｍｏｄｕｌｅ＿ｉｄとをフィルタ条件として設定して、デマルチプレクサ７０によるフィルタリングを行う。このフィルタ条件に適合して分離抽出されたトランスポートパケットがキュー７１の所要のメモリ領域（列）に格納されていくことで、最終的には、目的のモジュールが形成される。
（Ｐｒ６） 先のＩＯＲに含まれていたｏｂｊｅｃｔ＿ｋｅｙに相当するオブジェクトをこのモジュールから抜き出す。これが目的とするオブジェクトになる。このモジュールから抜き出されたオブジェクトは、例えば、ＤＳＭ−ＣＣバッファ９１の所定の領域に書き込みが行われる。
例えば、上記動作を繰り返し、目的とするオブジェクトを集めてＤＳＭ−ＣＣバッファ９１に格納していくことで、必要とされるシーンを形成するＭＨＥＧコンテンツが得られることになる。
【００９７】
マンマシンインターフェイス６１では、リモートコントローラ６４から送信されてきたコマンド信号を受信してＣＰＵ８０に対して伝送する。ＣＰＵ８０では、受信したコマンド信号に応じた機器の動作が得られるように、所要の制御処理を実行する。
【００９８】
ＩＣカードスロット６２にはＩＣカード６５が挿入される。そして、この挿入されたＩＣカード６５に対してＣＰＵ８０によって情報の書き込み及び読み出しが行われる。
【００９９】
モデム６３は、電話回線４を介して課金サーバ５と接続されており、ＣＰＵ８０の制御によってＩＲＤ１２と課金サーバ５との通信が行われるように制御される。
【０１００】
ここで、上記構成によるＩＲＤ１２におけるビデオ／オーディオソースの信号の流れを、図４により説明した表示形態に照らし合わせながら補足的に説明する。
図４（ａ）に示すようにして、通常の番組を出力する場合には、入力されたトランスポートストリームから必要な番組のＭＰＥＧビデオデータとＭＰＥＧオーディオデータとが抽出されて、それぞれ復号化処理が施される。そして、このビデオデータとＭＰＥＧオーディオデータが、それぞれアナログビデオ出力端子Ｔ２と、アナログオーディオ出力端子Ｔ３に出力されることで、モニタ装置１４では、放送番組の画像表示と音声出力が行われる。
【０１０１】
また、図４（ｂ）に示したＧＵＩ画面を出力する場合には、入力されたトランスポートストリームから、このＧＵＩ画面（シーン）に必要なＭＨＥＧコンテンツのデータをトランスポート部５３により分離抽出してＤＳＭ−ＣＣバッファ９１に取り込む。そして、このデータを利用して、前述したようにＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４が機能することで、ＭＨＥＧバッファ９２にてシーン（ＧＵＩ画面）の画像データが作成される。そして、この画像データが表示処理部５８を介してアナログビデオ出力端子Ｔ２に供給されることで、モニタ装置１４にはＧＵＩ画面の表示が行われる。
【０１０２】
また、図４（ｂ）に示したＧＵＩ画面上で楽曲のリスト２１Ｂにより楽曲が選択され、その楽曲のオーディオデータを試聴する場合には、この楽曲のＭＰＥＧオーディオデータがデマルチプレクサ７０により得られる。そして、このＭＰＥＧオーディオデータが、ＭＰＥＧオーディオデコーダ５４、Ｄ／Ａコンバータ、スイッチ回路５７、アナログオーディオ出力端子Ｔ３を介してアナログ音声信号とされてモニタ装置１４に対して出力される。
【０１０３】
また、図４（ｂ）に示したＧＵＩ画面上でダウンロードボタン２８が押されてオーディオデータをダウンロードする場合には、ダウンロードすべき楽曲のオーディオデータがデマルチプレクサ７０により抽出されてアナログオーディオ出力端子Ｔ４、光デジタル出力インターフェイス５９、またはＩＥＥＥ１３９４インターフェイス６０に出力される。
【０１０４】
ここで、特にＩＥＥＥ１３９４インターフェイス６０に対して、図２に示したＩＥＥＥ１３９４対応のＭＤレコーダ／プレーヤ１３Ａが接続されている場合には、デマルチプレクサ７０ではダウンロード楽曲の４倍速ＡＴＲＡＣデータが抽出され、ＩＥＥＥ１３９４インターフェイス６０を介してＭＤレコーダ／プレーヤ１３Ａに装填されているディスクに対して記録が行われる。また、この際には、例えばＪＰＥＧ方式で圧縮されたアルバムジャケットの静止画データ、歌詞やアーティストのプロフィールなどのテキストデータもデマルチプレクサ７０においてトランスポートストリームから抽出され、ＩＥＥＥ１３９４インターフェイス６０を介してＭＤレコーダ／プレーヤ１３Ａに転送される。ＭＤレコーダ／プレーヤ１３Ａでは、装填されているディスクの所定の領域に対して、これら静止画データ、テキストデータを記録することができるようになっている。
【０１０５】
２．本発明に至った背景
このようにＤＳＭ−ＣＣ方式を伝送規格として採用した本実施の形態のデジタル衛星放送システムでは、受信装置、つまりＩＲＤのタイプとして、受信バッファの構成の点から２種類に分けることができる。
【０１０６】
１つは、ＩＲＤが、データサービス（ＧＵＩ画面表示出力）対応のフラッシュメモリやハードディスクドライバなどの大容量の受信バッファを有する構成のものである。このような構成では、放送されているデータサービス（ＭＨＥＧコンテンツ）全体を一度に受信して、受信バッファに保持させる。これにより、一旦データサービスを受信して取り込んだ後は、ＭＨＥＧによるどのシーン（ＧＵＩ画面）についても、メモリアクセスの待ち時間のみ待機するだけで即座に表示出力させることが可能になる。つまり、ＧＵＩ画面（シーン）の切換のための操作をユーザが行ったような場合にも、次のシーンがほぼ直ぐさま表示されることになる。
このような場合、デマルチプレクサのフィルタ条件の切り換えによる多少のオーバーヘッドは、ＧＵＩ画面の表示に関しては特に問題となるものではない。
【０１０７】
もう１つは、ＩＲＤのコストを下げるなどの理由から、上記のような大容量の受信バッファを持たないものである。先に説明した本実施の形態のＩＲＤ１２がこれに相当する。この場合、データ放送サービス全体のデータをバッファリングすることができず、データ放送のデータを受信する受信単位であるモジュールのいくつかがバッファリングできるだけの受信バッファしか持たない。図１１に示したＩＲＤ１２では、この受信バッファはキュー７１に相当し、前述のようにモジュールがバッファリングできるメモリ領域が３２列設けられているのみである。
このようなＩＲＤでは、逆に言えば、モジュ−ルの大きさは受信機のバッファメモリーサイズを上回ることはできない。このため、データサービス全体がいくつかのモジュールの集合で構成されることになり、その時々で表示に必要なモジュールだけを受信するなどの手順が必要になってくる。
前述したオブジェクトを抽出するための手順（Ｐｒ１）〜（Ｐｒ６）は、このような大容量の受信バッファを有さないＩＲＤの構成に対応したものである。
【０１０８】
ここで、図１４に、ＭＨＥＧ方式に則ったデータサービスとしてのファイル（ＭＨＥＧ ａｐｐｌｉｃａｔｉｏｎ ｆｉｌｅ）のディレクトリ構造例を示す。前述したようにオブジェクトカルーセル方式は、このディレクトリ構造を扱えることに特徴を有する。
通常、Ｓｅｒｖｉｃｅ Ｄｏｍａｉｎの入り口となる（ＭＨＥＧ ａｐｐｌｉｃａｔｉｏｎ ｆｉｌｅ）は、必ず、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙの直下にある、ａｐｐ０／ｓｔａｒｔｕｐというファイルとなる。
基本的には、Ｓｅｒｖｉｃｅ Ｄｏｍａｉｎ（Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ）の下にａｐｐｌｉｃａｔｉｏｎ ｄｉｒｅｃｔｏｒｙ（ａｐｐ０，ａｐｐ１・・・ａｐｐＮ）があり、その下にｓｔａｒｔｕｐといわれるアプリケーション・ファイルと、ａｐｐｌｉｃａｔｉｏｎを構成する各ｓｃｅｎｅのｄｉｒｅｃｔｏｒｙ（ｓｃｅｎｅ０，ｓｃｅｎｅ１・・・）があるようにされる。更にｓｃｅｎｅ ｄｉｒｅｃｔｏｒｙの下には、ＭＨＥＧ ｓｃｅｎｅ ｆｉｌｅとｓｃｅｎｅを構成する各ｃｏｎｔｅｎｔ ｆｉｌｅがおかれることとしている。
【０１０９】
上記図１４のディレクトリ構造を前提として、例えば或るデータサービスにおいて、データサービスの最初にアクセスすべきアプリケーションがＳｅｒｖｉｃｅ Ｇａｔｅｗａｙ／ａｐｐ０／ｓｔａｒｔｕｐというファイルで、最初のシーンがｓｃｅｎｅｄｉｒ０に含まれる静止画やテキストのファイルで構成されているとする。
そして、このようなデータサービスについてＩＲＤにより受信を開始したとすれば、次のような手順となる。
（Ｐｒ１１） ＰＭＴを参照して所望のデータサービスのＰＩＤを取得し、そのＰＩＤとｔａｂｌｅ＿ｉｄとｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎをフイルタ条件としてデマルチプレクサでフィルタリングを行い、ＤＳＩを得る。このＤＳＩにはＳｅｒｖｉｃｅ ＧａｔｅｗａｙオブジェクトのＩＯＲが書かれている。
（Ｐｒ１２） このＩＯＲから、先に説明したオブジェクト抽出手順（Ｐｒ１）〜（Ｐｒ６）でＳｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトを得る。
【０１１０】
Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトとディレクトリ・オブジェクトの２種類のＢＩＯＰメッセージの中には、そのディレクトリ直下のオブジェクトの名称、所在（ｌＯＲ）、オブジェクトの種類といった情報が、ｂｉｎｄｉｎｇという属性情報として入っている。従ってオブジェクトの名称が与えられると、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙから始まってディレクトリをーつづつ下にたどりながら、その名称のオブジェクトに行き着くことができる（同じ名称のオブジェクトが存在する場合は、違うところまで上位のバス名が必要になる）。そして、さらに次に示す手順に進む。
【０１１１】
（Ｐｒ１３） Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトのｂｉｎｄｉｎｇ情報からａｐｐ０オブジェクトのＩＯＲを得て、オブジェクト抽出手順（Ｐｒ１）〜（Ｐｒ６）によりａｐｐ０オブジェクトを得る。
（Ｐｒ１４） ａｐｐ０オブジェクトのｂｉｎｄｉｎｇ情報からｓｔａｒｔｕｐオブジェクトのＩＯＲを得て、オブジェクト抽出手順（Ｐｒ１）〜（Ｐｒ６）でｓｔａｒｔｕｐオブジェクトを得る。以下同様に最初のシーンであるｓｃｅｎｅｄｉｒ０オブジェクトなどを得る。
【０１１２】
前述したように、モジュールを形成するオブジェクトの関係はＤＳＭ−ＣＣ方式のもとでは特に限定されるものではなく任意である。そこで、仮に図１５に示すような、それぞれのオブジェクト１つがモジュール１つに対応するようなマッピングを取って地上局１から送信を行ったとする。なお、データサービスのディレクトリ構造に対するマッピングの処理は、ＤＳＭ−ＣＣエンコーダ４４にてモジュールを形成する処理に際して、ＭＨＥＧコンテンツのデータに対して行われるものである。
【０１１３】
この場合、ＩＲＤ側において上記（Ｐｒ１１）〜（Ｐｒ１４）の手順によってオブジェクトを次々に得るには、一々新しいモジュールを受信することになる。このため、オブジェクトを得るごとにフィルタ条件を何度もデマルチプレクサ７０に変更設定してフィルタリングする手順が必要であり、このようなフィルタリング動作の繰り返しによってシーンの取り込みが遅れ、その表示も遅くなるなどサービス性の低下を招くことになる。
データサ−ビスの全データの大きさや放送時に割り当てられる帯域にもよるが、カルーセル１回転の周期は数秒から、１０秒以上に達することも考えられる。１回のフィルタリングには最悪で力ルーセル１回転分（平均１／２回転分）の待ち時間が生じるので、このフィルタリングの回数をできるだけ少なくすることがサービス性の向上に直接結びついてくる。
【０１１４】
また、シーンの切り換えについて考えてみると、図１５に示すマッピングでは、表示中のシーンから次のシーンのファイルを呼び込むときには、上位のディレクトリからたどらなくてはならない場合が生じる。
例えば図１５に示すマッピングの場合であれば、ａｐｐ０／ｓｃｅｎｅｄｉｒ０からａｐｐ０／ｓｃｅｎｅｄｉｒ１に移る場合は、既にａｐｐ０オブジェクトのＢＩＯＰメッセージからｓｃｅｎｅｄｉｒ１のｂｉｎｄｉｎｇ情報が得られているが、ａｐｐ０／ｓｃｅｎｅｄｉｒ０からａｐｐＮ／ｓｃｅｎｅｄｉｒ０に移る場合は、Ｓｅｒｖｉｃｅ ＧａｔｅｗａｙオブジェクトのＢＩＯＰメッセージにあったａｐｐＮオブジェクトのｂｉｎｄｉｎｇ情報からａｐｐＮ／ｓｃｅｎｅｄｉｒ０を辿ることになる。つまり、シーンを変更するために、先ずＳｅｒｖｉｃｅ Ｇａｔｅｗａｙオブジェクトのモジュールを受信して、このＢＩＯＰメッセージからａｐｐＮのｂｉｎｄｉｎｇ情報を得て、ａｐｐＮ／ｓｃｅｎｅｄｉｒ０のディレクトリを識別してから、このａｐｐＮ／ｓｃｅｎｅｄｉｒ０のモジュールを受信せねばならなくなる。（但し、上記した動作は、１回目のａｐｐＮをアクセスのときだけである。２回目以降はａｐｐＮのｂｉｎｄｉｎｇ情報を保持していればこの手順は不要となる。）
つまり、このような場合もモジュールのフィルタリングによるシーン切り替えの待ち時間が大きくなる。
【０１１５】
３．地上局側のデータマッピング例
そこで、本実施の形態では、先に述べた（Ｐｒ１）〜（Ｐｒ６）によるオブジェクト抽出手順によっても、最初のシーン表示や、シーンの切り替えによる待ち時間が短縮されるように、次のようにオブジェクトのマッピング方法を提案するものである。
【０１１６】
図１２は、本実施の形態としてのデータサービスのディレクトリ構造に対するマッピング例を示すものである。
図１２においては、１つのシーンを構成するオブジェクト全てを１つのモジューとして纏め（モジュール２，３・・Ｎ）、それ以外のＳｅｒｖｉｃｅＧａｔｅｗａｙを含む上位ディレクトリを１つのモジュール（モジュール１）にマッピングしている。ただし最初にアクセスするアプリケーションファイル「Ｓｔａｒｔｕｐ」は、最初のシーンのモジュールとー緒のモジュール（モジュール２）にマッピングするようにする。
【０１１７】
このようなマッピングとされれば、まずＳｅｒｖｉｃｅ Ｇａｔｅｗａｙのモジュール１を受信すれば、そのサブディレクトリの構成すべてが同じモジュールに入っているので、ＩＲＤ１２側ではディレクトリ構成全体をこのモジュール１の受信で得ることができる。
そして、これに続いてモジュール２を受信することになるが、このモジュール２は最初に提示するシーンのファイルがマッピングされて形成されたモジュールである。従って、このモジュール２のデータの取り込みが完了した段階で、最初のシーン出力に必要なオブジェクトの情報が全て得られることになる。つまり、先に示した（Ｐｒ５）の手順が完了した段階では、（Ｐｒ６）の手順もほぼ同時に完了させていることになる。実際には、キュー７１にてモジュール２が得られたら、このモジュール２を１シーン分のデータとして、ＤＳＭ−ＣＣバッファ９１に伝送するようにされる。なお、このような手順は、ルートディレクトリを含むモジュール１についても同様に行われる。
従って、この場合には、モジュール１、モジュール２と続けて、２回のモジュールの受信（獲得）さえ完了すれば、そのまま最初のシーンをの再生を始めることができる。また、さらに別のシーンに切り替わる場合は、最初に取り込んだディレクトリ・オブジェクトのｂｉｎｄｉｎｇ情報を参照すれば、直接所望のシーン・ディレクトリのモジュールを受信しにいくことができる。
【０１１８】
この場合でも、確かにシーン切り替えのオーバーヘッドは大きくないが、データサービスの最初のシーンの提示までに、モジュールを２回受信する必要がある。
【０１１９】
なお、図１２に示すマッピングでは、上位ディレクトリをまとめたモジュール１に、多くのオブジェクトが入ることになるが、Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙとディレクトリの２種類のオブジェクトは、上記のようにそのディレクトリにｂｉｎｄされるオブジェクトの名称やＩＯＲといったデータ量としてはさほど大きくない情報の組み合わせで出来ているため、オブジェクトの数が多くても全体のデータ容量は大きくないものである。
【０１２０】
また図１３に本実施の形態としての他のマッピング例を示す。ここでは、上位ディレクトリを纏めたものに、さらに最初にアクセスするアプリケーションファイル（ｓｔａｒｔｕｐ）と最初のシーンのオブジェクトを１つのモジュール１にマッピングしている。これ以外の他のモジュール２・・Ｎは、図１２に示したモジュール３・・Ｎ等と同様に、１シーンごとに必要とされるオブジェクトを纏めて形成されている。
このようなマッピングを施して送信した場合には、ＩＲＤ側ではこのモジュール１だけを受信して、キュー７１からＤＳＭ−ＣＣバッファ９１に伝送することで、すぐに最初のシーンを表示することができることになる。また、この段階で、ディレクトリ・オブジェクトのｂｉｎｄｉｎｇ情報が参照可能となるので、以降のシーンの切り換えに対応して必要なシーンのオブジェクトから成るモジュールに直ちにアクセスすることが可能になる。
【０１２１】
なお、上記マッピング例としては、１シーンを形成するオブジェクトが必ず１モジュールに収まるようにしているが、場合によっては、１シーンを形成する全てのオブジェクトの容量が大きく、モジュールとして規定されている最大サイズを超えるような場合、例えば、ｎ番目のモジュールに対して或る１シーンを形成するオブジェクトを出来るだけ納めるようにし、ｎ番目のモジュールに収まりきらなかった同一シーンを形成するオブジェクトによりｎ＋１番目のモジュールを形成するようにする。そして、このｎ番目のモジュールとｎ＋１番目のモジュールを連続させて、カルーセル方式で送信する。このようにすれば、ｎ番目のモジュールとｎ＋１番目のモジュールを２回受信する必要はあるが、比較的迅速にシーンの再生を行うことが出来る。
また、以降の説明においては、上述のようにして１シーンを形成することのできるオブジェクトが全て格納されることで形成されたモジュールのことを、「シーンモジュール」ともいうことにする。
【０１２２】
４．本実施の形態のキューへのモジュール割付
続いて、本発明の実施の形態の特徴となるＩＲＤ１２側の受信処理として、キュー７１へのモジュール割付について図１６〜図２０を参照して説明する。本実施の形態のＩＲＤ１２では、上記した放送側（地上局側）のデータマッピングが行われることを前提として、以降説明するキュー７１へのモジュール割付を行うことで、更に効率的に必要なシーンを得ることが可能になるものである。
【０１２３】
図１６（ａ）には、トランスポート部５３におけるデマルチプレクサ７０とキュー７１の構成、及びＤＳＭ−ＣＣバッファ９１のメモリ領域を概念的に示している。
【０１２４】
この図に示すトランスポート部５３としては、デマルチプレクサ７０と、キュー７１を形成するメモリ領域Ｍｅｍ−１，Ｍｅｍ−２，Ｍｅｍ−３・・・Ｍｅｍ３２が示されている。そして、これら各メモリ領域がモジュール単位のデータを蓄積可能とされている。
前述したように、デマルチプレクサ７０に与えられたフィルタ条件に適合する種類のデータ（例えばセクション単位）がトランスポートストリームから分離抽出されるのであるが、この分離抽出されたセクションは、メモリ領域Ｍｅｍ−１〜Ｍｅｍ−３２の何れかに対して格納される。そして、この動作が繰り返される結果、或るメモリ領域に対して上記フィルタ条件に適合して集められたセクションの集合より成るモジュールが形成されて、ここに蓄積されることになる。
【０１２５】
ここで、例えば、デマルチプレクサ７０により、シーンＡを形成するデータにより形成されるモジュールのデータを分離抽出して、メモリ領域Ｍｅｍ−２に格納したとする。そして、このシーンＡのモジュールをＧＵＩ画面表示に使用する場合には、このシーンＡのモジュールのデータをメモリ領域Ｍｅｍ−２からＤＳＭ−ＣＣバッファに対して書き込みを行うようにされる。
つまり、受信したシーンのモジュールの一般的な伝送形態としては、一旦これをキューのメモリ領域にて蓄積した後、ＤＳＭ−ＣＣバッファ９１に取り込むようにすることになる。そして、前述したようにＤＳＭ−ＣＣバッファ９１に取り込まれたシーンデータを、ＭＨＥＧデコーダブロック８４がアクセスしてロードし、ＭＨＥＧバッファに取り込むことでＧＵＩ画面等のシーン出力が可能になる。
【０１２６】
ところで、ここでもメモリ領域Ｍｅｍ−１〜Ｍｅｍ３２として示されているように、キュー７１を形成するメモリ領域は本実施の形態では３２列に限定されている。そして、これらのメモリ領域は、実際にはトランスポートストリームを受信する動作を行っている限りは、各種異なるフィルタ条件に適合して分離された、例えばＭＰＥＧストリームデータ等をはじめとする多種のモジュールデータによりほぼ占有されている状態にある。
このような状況は、例えば、ＭＨＥＧデコーダブロック８４がアクセスする必要があるとされる多数のシーンモジュールをＤＳＭ−ＣＣバッファ９１に取り込もうとしても、このシーンモジュールを一時保持するメモリ領域数が制限されていることで、例えば必要とされるシーンモジュールの多くを一度にキュー内の複数のメモリ領域に蓄積して、ＤＳＭ−ＣＣバッファ９１に転送することが事実上困難であることを意味する。
また、ＤＳＭ−ＣＣ方式では、モジュールの受信順（取込順）を特に規定してはいない。つまり、トランスポート部５３においてどのような順序でシーンモジュールを抽出してメモリ領域に格納するのかは任意とされている。
【０１２７】
そこで、本実施の形態では、上記したメモリ領域数の制限が有ることを踏まえた上で、ＤＳＭ−ＣＣバッファ９１に取り込む必要のあるモジュールが出来るだけ迅速にトランスポート部５３にて得られるように、次のようにしてモジュール割付（受信順）を規定する。
【０１２８】
先に、説明したようにデータサービスのディレクトリ構造、及びこのディレクトリ構造に対するモジュールのマッピングは、例えば図１２、図１３に示すものとされるが、例えばａｐｐ０のディレクトリに関すれば、ａｐｐ０／ｓｔａｒｔｕｐと、ａｐｐ０／ｓｃｅｎｅｄｉｒ０／ｓｃｓｎｅ０のオブジェクトを得さえすれば、ａｐｐ０のアプリケーションを形成するシーンの優先順位の情報を得ることが出来るようになっている。これはａｐｐ１〜Ｎまでの他のアプリケーションについても同じことがいえる。
ここでいう優先順位とは、例えば或るシーンの表示出力から他のシーンの表示出力に移行する（これを「トランジション」ともいう）場合には、上記他のシーンとして複数の候補があるのが通常であるが、これら複数のシーンの候補において、例えばユーザの操作によってシーン切り換えの必要があるとされたときに、切り換えが行われる可能性の高さに従って付されているものである。
【０１２９】
本実施の形態では、このシーンの優先順位の情報に基づいてモジュール割付を規定するが、これについて、再度図１６を参照して説明する。
ここでは、説明の便宜上、トランスポート部５３においてシーンモジュールを保持することのできるメモリ領域はＭｅｍ−２のみとされて、他のメモリ領域は、それ以外の種類のモジュールを格納するために占有されているものとする。また、ここでは、ａｐｐ０のアプリケーションによりシーン出力する場合に関して説明する。
【０１３０】
ここで、トランスポート部５３においては、既に上記したａｐｐ０／ｓｔａｒｔｕｐと、ａｐｐ０／ｓｃｅｎｅｄｉｒ０／ｓｃｓｎｅ０のオブジェクトが属するモジュールを受信しており、例えばＣＰＵ８０の制御処理部８１では、ａｐｐ０のアプリケーションにおけるシーンの優先順位情報が得られているものとする。
そして、ここでは優先順位情報により、ａｐｐ０のディレクトリ構造化にある複数シーンについて、シーンＡ→シーンＢ→シーンＣ→シーンＤ・・のようにして優先順位が与えられているものとし、これらのシーンをＤＳＭ−ＣＣバッファ９１に出来るだけ取り込むことが必要であるとする。
【０１３１】
このような場合、制御処理部８１では、先ず、優先順位が最も高いシーンＡのモジュールがトランスポート部５３のメモリ領域Ｍｅｍ−２に格納されるように制御を実行する。この制御に基づき、デマルチプレクサドライバ８２は、シーンＡのモジュールに適合するフィルタ条件をデマルチプレクサ７０に対して設定する。これにより、図１６（ａ）に示すようにして、シーンＡのモジュールがメモリ領域Ｍｅｍ−２に格納され、ＤＳＭ−ＣＣバッファ９１に転送する。
【０１３２】
続いては、制御処理部８１は、シーンＡに続く優先順位のシーンＢを獲得するための処理として、シーンＢのモジュールに適合するフィルタ条件をデマルチプレクサ７０に対して設定するようにデマルチプレクサドライバ８２に指示する。これにより、図１６（ｂ）に示すようにして、シーンＢのモジュールがメモリ領域Ｍｅｍ−２に得られ、これをＤＳＭ−ＣＣバッファ９１に転送することになる。なお、図１６（ｂ）には、図１６（ａ）に示した回路ブロックのうち、メモリ領域Ｍｅｍ−２とＤＳＭ−ＣＣバッファ９１のみを抜き出して示している。次に示す図１６（ｃ）も同様である。
【０１３３】
更に次は、シーンＢに続く優先順位のシーンＣを得るために、シーンＣのモジュールに適合するフィルタ条件をデマルチプレクサ７０に対して設定し、図１６（ｃ）に示すようにして、シーンＣを得てＤＳＭ−ＣＣバッファ９１に転送する。
【０１３４】
以降、同様にして優先順位に従ったシーンのフィルタ条件をデマルチプレクサ７０に設定して、そのシーンモジュールをメモリ領域Ｍｅｍ−２にて得て、これをＤＳＭ−ＣＣバッファ９１に転送していくようにされる。
【０１３５】
このような動作が行われる結果、ＤＳＭ−ＣＣバッファ９１には、シーン出力のために必要、或いはシーン切り換え時において、次に必要となる可能性の高いシーンモジュールのデータがその優先順位に従って格納されることになる。
ＭＨＥＧデコーダブロック８４は、このようにしてＤＳＭ−ＣＣバッファ９１にて得られたシーンモジュールのデータにアクセスしてＧＵＩ画面などのシーン出力を行うが、例えばデータ放送中においてユーザの操作により所望のシーンの呼び出しの要求が有った場合、呼び出し要求のあったシーンのデータがＤＳＭ−ＣＣバッファ９１に既に保持されている可能性は非常に高く、ほぼ確実に呼び出し要求のあったシーンデータにアクセスして、これを即座に出力させることが可能になる。
【０１３６】
ところで、ＤＳＭ−ＣＣバッファ９１の容量は当然のこととして有限であり、実際にはさほど多くの容量は割り当てられない。このため、例えばＭＨＥＧデコーダブロック８４により使用することが想定される全てのシーンモジュールを格納することが出来ない場合がある。このために、例えば次のような不都合が生じることが想定される。
【０１３７】
ここで、例えば図１７に示すようにして、あるアプリケーションのもとでシーンＡ，シーンＢ，シーンＣ，シーンＤ，シーンＥの５つのシーンが用意されているとして、この各シーン間のトランジションの形態が図のように設定されている（このようなトランジジョンの規定はＭＨＥＧにより記述されている）ものとする。例えばシーンＡであれば、シーンＢ，Ｃ，Ｅにトランジションが可能とされ、シーンＢであればシーンＡ，Ｃにトランジション可能とされている。
【０１３８】
そして、ＤＳＭ−ＣＣバッファ９１の容量として、最大で４つのシーンモジュールを格納することが限度であると仮定する。この条件の下で上記図１７に示すシーンＡ〜Ｅの５つのモジュールが用意されたアプリケーションをＭＨＥＧデコーダブロック８４が使用するとした場合、上記シーンＡ〜Ｅの５つのモジュールのうち、１つのシーンモジュールはＤＳＭ−ＣＣバッファ９１に格納できないことになる。
【０１３９】
上記した条件の下、例えば或る段階でシーンＡを表示出力しており、このときＤＳＭ−ＣＣバッファ９１に取り込まれているシーンモジュールはシーンＡ，Ｂ，Ｃ，Ｄの４つであるとする。そして、この状態から、例えばユーザの操作によりシーンＥの呼び出し要求が有ったとすると、これに応答してシーンＡからシーンＥにトランジションすることになる。
ところが、このときＤＳＭ−ＣＣバッファ９１にはシーンＥのモジュールは無いことから、シーンＥの呼び出し要求に応えるためには、シーンＥのモジュールをカルーセルから新規に取り込む必要がある。この間、ユーザにとってはシーンＡからシーンＥの表示に移行するまでの待ち時間が生じることになる。
【０１４０】
そこで、このような不都合が出来るだけ解消されるようにするため、本実施の形態では、更に次のようなモジュール割付も行うようにされる。
【０１４１】
実際のＭＨＥＧ方式によるデータサービスでは、或るアプリケーションにおける複数シーン間の優先順位は、現在表示出力中のシーンに依存して変更される場合がある。このような出力中のシーンに応じて変更される優先順位も、前述した優先順位情報に基づいて得ることが出来る。
そこで、本実施の形態では、ＭＨＥＧデコーダブロック８４のプログラムとして、現在あるシーンを出力しているときに、その出力中のシーンを基準として他のシーンの優先順位を管理する、ネクストシーンマネージャ（Next Scene Manager）を起動させることとする。
【０１４２】
ここで、ネクストシーンマネージャの管理例として、図１７に示したシーンのうちで現在シーンＡを出力中の場合に、ネクストシーンマネージャにより管理されている優先順位が図１８に示したものであったとする。つまり、優先順位として（１）シーンＡ→（２）シーンＣ→（３）シーンＥ→（４）シーンＢ→（５）シーンＤの順位で管理されているものとする。このような優先順位は、実際には、図に示すようなプライオリティ値によって決定される。このプライオリティ値が大きいほど優先順位は高いことになり、ここでは、シーンＡに対する他のシーンのプライオリティ値として、シーンＣが‘１０’、シーンＥが‘９’、シーンＢが‘７’、シーンＤが‘１’とされている。
そして、このときＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールは、図２０（ａ）に示すように、シーンＡ，Ｅ，Ｃ，Ｂであるとする。
【０１４３】
この状態の下で、例えばシーンＡからシーンＣにトランジジョンするための要求が行われたとすると、ＭＨＥＧデコーダブロック８４では、図２０（ａ）に示した格納状態にあるＤＳＭ−ＣＣバッファ９１からシーンＣのデータにアクセスして、これを出力するための処理を実行する。
【０１４４】
また、ＭＨＥＧデコーダブロック８４では、シーンＣにトランジションしたことに対応して、ネクストシーンマネージャによりシーンの優先順位を、例えば図１９に示すように更新して管理する。
この図では、現在出力中のシーンＣを筆頭に、（１）シーンＣ→（２）シーンＢ→（３）シーンＡ→（４）シーンＤ→（５）シーンＥの順位であるとして管理している。また、この場合のシーンＣに対する他のシーンのプライオリティ値は、それぞれシーンＢが‘７’、シーンＡが‘６’、シーンＤが‘４’、シーンＥが‘２’とされており、上記優先順位はこのプライオリティ値に従って決定されたものである。このように、現在出力中のシーンに応じて、シーン間の優先順位は変更される。
【０１４５】
そして、本実施の形態では、上記図１９に示すようにして更新されたシーン間の優先順位に基づいて、次のようにしてＤＳＭ−ＣＣバッファ９１に格納されるシーンモジュールの内容を更新する。
例えば、ＣＰＵ８０は、上記図１９に示す、現在ネクストシーンマネージャにより管理されているシーン間の優先順位と、図２０（ａ）のＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールとの比較を行う。
すると、ＤＳＭ−ＣＣバッファ９１には、図１９に示す優先順位として１位のシーンＣ、２位のシーンＢ、３位のシーンＡ、及び５位（最下位）のシーンＥが格納されており、４位のシーンＤが格納されていないことが分かる。
【０１４６】
そこで、ＣＰＵ８０においては、ＤＳＭ−ＣＣバッファ９１に格納されるシーンモジュールが、現在管理されている優先順位における上位４つのシーンとなるように制御を実行する。つまり、この場合であれば、図２０（ｂ）に示すようにして、シーンＥの代わりにシーンＤのモジュールがＤＳＭ−ＣＣバッファ９１に格納されるようにして、結果的に上位４つのシーンモジュールが格納されるようにするものである。
【０１４７】
このためには、先ず、例えばデマルチプレクサドライバ８２からデマルチプレクサ７０に対して、シーンＤのモジュールを得るためのフィルタ条件を出力させるように、ＣＰＵ８０における制御処理部８０が指示をするようにされる。これにより、キュー７１においてシーンデータのモジュールのために割り当てられたメモリ領域にシーンＤのモジュールが格納される。そして、このキュー７１のメモリ領域に得られたシーンＤのモジュールが、シーンＥのモジュールと入れ替わるようにして、ＤＳＭ−ＣＣバッファ９１に対する書き込み制御を実行するものである。この書き込み制御も、例えば制御処理部８０が実行するようにされればよい。
なお、シーン切り換えに応じて変更されたシーンの優先順位と、それまでのＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールデータとの比較で、２以上のシーンモジュールを入れ替える必要が有れば、上記した制御動作に準じてこれらのシーンモジュールについての取り込みを行うようにされる。
【０１４８】
例えば、或るシーンを出力させている状態の下で、ユーザがシーンの切り換え操作を行う場合、やはり実際には、その時点でネクストシーンマネージャにより管理されている優先順位に従って、切り換えのシーンが選択される可能性が高い。
このため、上記のようにして、現在出力中のシーンに応じて決定されるシーンの優先順位の上位のシーンから優先的にＤＳＭ−ＣＣバッファ９１に取り込むように、トランスポート部５３におけるモジュール割付を規定すれば、例えば、先に述べたように、シーンのトランジジョンの要求があったときに、このシーンのモジュールがＤＳＭ−ＣＣバッファ９１に格納されていないといった状況が生じる可能性は極力回避される。従って、ほとんどの場合、シーンの切り換え操作に応じて即座にシーンの切り換えが行われることになるものである。
【０１４９】
なお、シーン切り換えに応じて変更されたシーンの優先順位に応じて、例えば上記図２０（ａ）から図２０（ｂ）に示したようにして、ＤＳＭ−ＣＣバッファ９１の格納状態を遷移させるまでには、実際には、或る程度の時間がかかるのであるが、例えば、シーンＣの出力が開始されて後において最初のシーン切り換え操作が行われるまでには、通常、或る程度の期間が存在する。つまり、シーンＣが出力開始されてしばらくはユーザは、シーンＣの画像を見ているのが普通である。そして、たいていはこの間にＤＳＭ−ＣＣバッファ９１におけるシーンデータの入れ替えはほぼ終了しているため、実用上は問題にはならないものである。
【０１５０】
続いて、上記図１８〜図２０により説明したモジュール割付を実現するための処理動作について、図２１のフローチャートを参照して説明する。この図に示す処理は、ＣＰＵ８０が実行するものとされる。つまり、制御処理部８１の全体制御に基づいて、デマルチプレクサドライバ８２、ＤＳＭ−ＣＣデコーダブロック８３、及びＭＨＥＧデコーダブロック８４が適宜所要の制御処理を実行することにより実現されるものである。
また、この図においては、例えばユーザによるシーン切り換え要求のための操作等が行われたことでシーン切り換えが必要とされた場合における、シーンモジュール割付に関する対応処理を示している。
【０１５１】
この図に示すルーチンにおいては、先ずステップＳ１０１において、シーン切り換え前のネクストシーンマネージャのシーン優先順位に従って挙げられたシーン候補と、シーン切り換え後のネクストシーンマネージャのシーン優先順位に従って挙げられたシーン候補とを比較して、これらのシーン候補間で一致しないものをリストアップする。また、上記シーン候補間で共通に一致したシーンについては、シーン切り換えに応じてシーンネクストマネージャが扱うべき「シーンリスト」に対して登録が行われる。
この処理は、例えばＭＨＥＧデコーダブロック８４において、ネクストシーンマネージャを起動させることにより実現される。
【０１５２】
続くステップＳ１０２においては、ＭＨＥＧデコーダブロック８４の処理として、上記ステップＳ１０１にてリストアップされた一致しないシーン候補のうちで、シーン切り換え前のシーン候補とされていたものについては削除し、シーン切り換え後に候補とされているシーンについてはシーンリストに追加するための処理が実行される。
この処理によって、シーン切り換えに応じて候補となる複数シーンが、シーンリストとして用意されることになる。
【０１５３】
続くステップＳ１０３においては、ネクストシーンマネージャの機能を用い、上記シーンリストとして登録されたシーンについて、シーン切り換えに応じて変更されたシーンの優先順位に従ってソートを実行するようにされる。
これにより、図１８に示すネクストシーンマネージャの管理状態から、図１９に示すネクストシーンマネージャの管理状態に移行することになる。
なお、上記ステップＳ１０１〜Ｓ１０３までに示す処理のうち、ステップＳ１０１，及びＳ１０２の処理については、先の図１８及び図１９に依る説明では特に言及していない。これは、図１８、図１９に示した場合においては、シーンＡからシーンＣへのシーン切り換えによっては、シーン候補の入れ替えが無いことによる。即ち、図１８から図１９の遷移に対応するシーン切り換えに際しては、ステップＳ１０１において一致しないシーンがリストアップされず、全てのシーンが一致したとして、シーンリストに登録されたことになる。
【０１５４】
ステップＳ１０３に続いては、ステップＳ１０４の処理が実行される。ここでは、上記ステップＳ１０３においてソートされたシーンリスト上において、優先順位的に最上位のシーンについての処理を開始する。つまり、このシーンを「現シーン」として扱って以降の処理を実行していくようにされる。
また、ステップＳ１０４においての「優先順位的に最上位のシーン」とは、現在出力中とされているシーン（図１９であればシーンＣ）を除いて、最も優先順位の高いシーンが選択される。つまり、図１９の場合で有ればシーンＢが選択されることになる。但し、例えば図１９に示す優先順位の管理状態が得られたとき、シーンＣがＤＳＭ−ＣＣバッファ９１に格納されていない場合には、例外的にこのシーンＣを現シーンとして扱うようにステップＳ１０４での処理が行われるものとする。
【０１５５】
続くステップＳ１０５においては、上記ステップＳ１０４にて選択された現シーンのデータにより形成されるモジュール（シーンモジュール）のデータサイズをチェックする。これは、例えば現シーンモジュールに対応する制御情報であるＤＩＩ（図８参照）をカルーセルのデータから取り込み、例えばＤＳＭ−ＣＣデコーダブロック８３が、この取り込んだＤＩＩにおけるモジュールのデータサイズを示す情報を参照することで識別が可能とされる。ここで得られた現シーンモジュールのデータサイズの情報は一時保持されて、後述するステップＳ１０７の判別処理に用いられる。
【０１５６】
ステップＳ１０６においては、現シーンモジュールがＤＳＭ−ＣＣバッファ９１に既に取り込まれている状態にあるか否かが判別され、ここで肯定結果が得られればステップＳ１１０に進んで、シーンリスト上で、これまでの現シーンに対して次の優先順位が与えられているシーンを現シーンとして選択して、この現シーンとしての処理を開始させるための処理を実行する。
これに対して、ステップＳ１０６において否定結果が得られた場合には、ステップＳ１０７の処理に移行する。
【０１５７】
ステップＳ１０７においては、現在のＤＳＭ−ＣＣバッファ９１の残り容量（データ取込可能容量）が、ステップＳ１０５にてチェックされた現シーンモジュールのサイズよりも大きいか否かを判別する。そして、肯定結果が得られた場合、つまり、現在のＤＳＭ−ＣＣバッファ９１の残り容量として、現シーンモジュールを取り込んで格納するだけの余裕があると判別された場合には、ステップＳ１１１に進んで現シーンモジュールのデータをカルーセルからキュー７１に蓄積し、これをＤＳＭ−ＣＣバッファ９１に対して取り込んで格納するための処理が実行される。この処理を実現するためのＣＰＵ８０の制御動作とこれに伴う各部の信号処理動作は、例えば図２０の説明において述べたとおりである。
そして、上記ステップＳ１１１の処理を実行した後はステップＳ１１０の処理を経た上で、ステップＳ１０５の処理に戻るようにされる。
【０１５８】
また、ステップＳ１０７において否定結果が得られ、現在のＤＳＭ−ＣＣバッファ９１の残り容量が、ステップＳ１０５にてチェックされた現シーンモジュールのサイズよりも小さいと判別された場合には、ステップＳ１０８に進む。
ステップＳ１０８においては、現在のネクストシーンマネージャの優先順位管理と、現在ＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールとを比較して、現在ＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールにおいて、現在最も優先順位（プライオリティ）が低いものとして管理されているシーンモジュールを特定する。そして、次のステップＳ１０９において、この特定されたシーンモジュールのプライオリティが、現シーンよりも低いか否かを判別するようにされる。
【０１５９】
ステップＳ１０９において、ステップＳ１０８により特定されたシーンモジュールのプライオリティが現シーンよりも低いとされた場合には、ステップＳ１１２に進んで、この特定されたシーンモジュールをＤＳＭ−ＣＣバッファから削除してステップＳ１０７に戻るようにされる。この処理により、現シーンモジュールが取り込み可能なＤＳＭ−ＣＣバッファ９１の残り容量が得られるまで、ＤＳＭ−ＣＣバッファ９１から優先順位（プライオリティ）の最も低いシーンモジュール（但し現シーンよりもプライオリティが低いもののみが対象となる）が削除されていくことになる。
【０１６０】
そして、ステップＳ１０９において否定結果が得られた場合、つまり、ステップＳ１０８にて特定されたシーンモジュールのプライオリティが、現シーンよりも高いことが判別された場合であるが、この段階では、結果的に、ＤＳＭ−ＣＣバッファ９１に格納されているシーンモジュールは、現在のネクストシーンマネージャにより管理されているシーンの優先順位に対応していることになる。つまり、先に説明した具体例に従えば、図１９に示したネクストシーンマネージャの管理に対応して、図２０（ｂ）に示すシーンモジュールの格納状態が得られるものである。この場合には、図のようにして、これまでのモジュール割付のための処理が終了されることになる。
【０１６１】
なお、本発明としては、ＤＳＭ−ＣＣ方式を採用した場合に限定されるものではなく、実施の形態において説明した送信フォーマットに準ずる伝送方式であれば本発明の適用が可能とされる。また、本発明が適用されるシステムとしてもデジタル衛星放送システムに限定されるものではなく、例えばケーブルテレビジョンなどの放送や、インターネット等において適用することも可能である。
【０１６２】
【発明の効果】
以上説明したように本発明は、伝送方式として、１シーン分のシーンデータが原則１モジュールを形成するものとされたうえで、１以上のモジュールからなる伝送データをカルーセル方式により伝送する場合に対応する受信装置として、カルーセル（伝送情報）から抽出してキュー（メモリ手段）に取り込むべきシーンデータとしてのモジュールを、シーンの優先順位に従って決定するように規定される。
例えば、キューに対するモジュールの取込順を特に規定しない場合、表示出力に必要なシーンデータを得て、これをシーンデータ格納手段（ＤＳＭ−ＣＣバッファ）に取り込むまでには相応の時間を要することになる。また、これを解消しようとして、目的のシーンデータとしてのモジュールが出来るだけ迅速にシーンデータ格納手段にて得られるようにするためには、多くのキュー数が必要となってしまう。
これに対して、本発明では、上記構成によって優先順位に従ってシーンデータとしてのモジュールを取り込むようにされるため、制限されたキュー数の構成のもとであっても、表示出力に必要、又は必要とされる可能性の高いシーンデータが比較的迅速に得られることになる。つまり、本発明では、キュー数が少なくてもシーン出力、及びシーン切り換えに迅速に対応できることになる。また、逆に言えば、本発明を適用せずに迅速なシーン出力、シーン切り換えを実現しようとした場合と比較して、キュー数を削減することが可能であり、それだけＩＲＤ（受信装置）の回路規模の縮小及び低コスト化を図ることが可能となる。
【０１６３】
また、現在出力されているシーンに応じて変更される優先順位に応じて、受信データのカルーセルから取り込むべきシーンデータとしてのモジュールが決定されるため、常にシーン表示の切り換えに対応して、シーンデータ格納手段には優先順位的に上位のシーンデータから優先的に格納されている状態が得られることになる。
この場合、シーン表示の切り換え操作によって選択されるシーンのシーンデータがシーンデータ格納手段に格納されている可能性が非常に高く、これにより、例えばユーザによってシーン表示の切り換え操作が行われたとしても、ほとんどの場合において、そのシーンの切り換えが迅速に行われることになる。この構成は、シーンデータ格納手段（ＤＳＭ−ＣＣバッファ）の容量に制限があって、多数のシーンデータを格納することが出来ないような条件の下で特に有効となる。
【図面の簡単な説明】
【図１】本発明の実施の形態のデジタル衛星放送受信システムの構成例を示すブロック図である。
【図２】本実施の形態における受信設備の構築例を示すブロック図である。
【図３】ＩＲＤのためのリモートコントローラの外観を示す正面図である。
【図４】放送画面とＧＵＩ画面との切り換えを示す説明図である。
【図５】地上局の構成例を示すブロック図である。
【図６】地上局から送信されるデータを示すチャート図である。
【図７】送信データの時分割多重化構造を示す説明図である。
【図８】ＤＳＭ−ＣＣによる送信フォーマットを示す説明図である。
【図９】トランスポートストリームのデータ構造図である。
【図１０】ＰＳＩのテーブル構造を示す説明図である。
【図１１】ＩＲＤの構成を示す説明図である。
【図１２】本実施の形態としてのデータサービスのディレクトリ構造に対するマッピング例を示す説明図である。
【図１３】本実施の形態としてのデータサービスのディレクトリ構造に対する他のマッピング例を示す説明図である。
【図１４】データサービスのディレクトリ構造の一例を示す説明図である。
【図１５】データサービスのディレクトリ構造に対するマッピング例を示す説明図である。
【図１６】本実施の形態のシーンデータのモジュールの取込動作を示す説明図である。
【図１７】シーンのトランジション例を示す説明図である。
【図１８】図１７に示すシーンのトランジション例に従った、ネクストシーンマネージャにおいて管理されるシーン優先順位例を示す説明図である。
【図１９】図１７に示すシーンのトランジション例に従った、ネクストシーンマネージャにおいて管理されるシーン優先順位例を示す説明図である。
【図２０】図１８から図１９の遷移として示すシーン優先順位の変更に応じたシーンデータのモジュールの取込動作を示す説明図である。
【図２１】本実施の形態のシーン切り換えに応じたモジュール割付けを実現するためのフローチャートである。
【符号の説明】
１ 地上局、２ 衛星、３ 受信設備、５ 課金サーバ、６ テレビ番組素材サーバ、７ 楽曲素材サーバ、８ 音声付加情報サーバ、９ ＧＵＩデータサーバ、１０ キー情報サーバ、１１ パラボラアンテナ、１３ ストレージデバイス、１３Ａ ＭＤレコーダ／プレーヤ、１４ モニタ装置、１６ ＩＥＥＥ１３９４バス、２１Ａ テレビ番組表示エリア、２１Ｂ リスト、２１Ｃ テキスト表示エリア、２１Ｄ ジャケット表示エリア、２２ 歌詞表示ボタン、２３ プロフィール表示ボタン、２４ 情報表示ボタン、２５ 予約録音ボタン、２６ 予約済一覧表示ボタン、２７ 録音履歴ボタン、２８ ダウンロードボタン、３１ テレビ番組素材登録システム、３２ 楽曲素材登録システム、３３ 音声付加情報登録システム、３４ ＧＵＩ用素材登録システム、３５ ＡＶサーバ、３６Ａ ＭＰＥＧオーディオエンコーダ、３６Ｂ ＡＴＲＡＣエンコーダ、３７ 音声付加情報データベース、３８ ＧＵＩ素材データベース、３９ テレビ番組送出システム、４０Ａ ＭＰＥＧオーディオサーバ、４０Ｂ ＭＰＥＧオーディオサーバ、４１ 音声付加情報送出システム、４２ ＧＵＩオーサリングシステム、４３Ａ ＭＰＥＧオーディオ送出システム、４３Ｂ ＡＴＲＡＣオーディオ送出システム、４４ ＤＳＭ−ＣＣエンコーダ、４５ マルチプレクサ、４６ 電波送出システム、５１ チューナ／フロントエンド部、５２ デスクランブラ、５３ トランスポート部、５４ ＭＰＥＧ２オーディオデコーダ、５４Ａ メモリ、５５ ＭＰＥＧ２ビデオデコーダ、５５Ａ メモリ、５６ Ｄ／Ａコンバータ、５７ スイッチ回路、５８ 表示処理部、５９ 光デジタル出力インターフェイス、６０ ＩＥＥＥ１３９４インターフェイス、６１ マンマシンインターフェイス、６２ ＩＣカードスロット、６３ モデム、６４ リモートコントローラ、６５ ＩＣカード、７０ デマルチプレクサ、７１ キュー、８１ 制御処理部、８２ ＤｅＭＵＸドライバ、８３ ＤＳＭ−ＣＣデコーダブロック、８４ ＭＨＥＧデコーダブロック、９０ メインメモリ、９１ ＤＳＭ−ＣＣバッファ、１０１ 電源キー、１０２ 数字キー、１０３ 画面表示切換キー、１０４ インタラクティブ切換キー、１０５ａ 矢印キー、１０５ ＥＰＧキーパネル部、１０６ チャンネルキー、Ｔ１ 入力端子、Ｔ２ アナログビデオ出力端子、Ｔ３ アナログオーディオ出力端子、Ｔ４ アナログオーディオ出力端子
Claims (2)
- オブジェクトカルーセル伝送方式によって繰り返し送信される、提示用コンテンツデータがブロックに分割されて伝送されるシーンデータとされるモジュールを含むＤＤＢメッセージと、該カルーセルの識別子、カルーセル全体に関連する情報及びデータサービスのルートディレクトリの所在を知るための情報を有するＤＳＩメッセージと、該カルーセルに含まれるモジュールごとに対応する情報を含むＤＩＩメッセージとを受信する受信手段と、
前記受信手段によって受信されたＤＤＢメッセージに含まれる前記モジュールを、前記カルーセルによって伝送されるシーン切り換えの必要があるとされたときに、切り換えが行われる可能性の高さに従って付されている優先度情報に基づいて蓄積する蓄積手段と、
前記ＤＩＩメッセージに含まれる情報であって、前記蓄積手段によって蓄積されている前記モジュールの位置を示す前記ＤＳＩメッセージが有するルートディレクトリを参照して、前記ＤＤＢメッセージ内の前記モジュールのうち、前記優先度情報に基づいてスタートアップファイルを取得する取得手段と、
前記取得手段によって取得されたスタートアップファイルを、前記蓄積手段によって蓄積されたＤＤＢメッセージによって伝送される、前記提示用コンテンツデータについて表示制御を行うためのスクリプトに基づいて出力する出力制御手段と
を備える受信装置。 - オブジェクトカルーセル伝送方式によって繰り返し送信される、提示用コンテンツデータがブロックに分割されて伝送されるシーンデータとされるモジュールを含むＤＤＢメッセージと、該カルーセルの識別子、カルーセル全体に関連する情報、データサービスのルートディレクトリの所在を知るための情報を有するＤＳＩメッセージと、該カルーセルに含まれるモジュールごとに対応する情報を含むＤＩＩメッセージとを受信する受信手順と、
前記受信手順によって受信されたＤＤＢメッセージに含まれる前記モジュールを、前記カルーセルによって伝送されるシーン切り換えの必要があるとされたときに、切り換えが行われる可能性の高さに従って付されている優先度情報に基づいて蓄積する蓄積手順と、
前記ＤＩＩメッセージに含まれる情報であって、前記蓄積手順によって蓄積されている前記モジュールの位置を示す前記ＤＳＩメッセージに含まれるルートディレクトリを参照して、前記ＤＤＢメッセージ内の前記モジュールのうち、前記優先度情報に基づいてスタートアップファイルを取得する取得手順と、
前記取得手順によって取得されたスタートアップファイルを、前記蓄積手順によって蓄積されたＤＤＢメッセージによって伝送される、前記提示用コンテンツデータについて表示制御を行うためのスクリプトに基づいて出力する出力制御手順と
を実行する受信方法。
Priority Applications (9)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20385798A JP4378780B2 (ja) | 1998-07-17 | 1998-07-17 | 受信装置及び受信方法 |
| EP06076318A EP1705918B1 (en) | 1998-07-14 | 1999-07-14 | Data receiving apparatus |
| KR1020007002686A KR100641594B1 (ko) | 1998-07-14 | 1999-07-14 | 데이터 전달 제어 방법, 데이터 전송 방법, 데이터 송신장치, 수신 장치 |
| EP99929823A EP1014620B1 (en) | 1998-07-14 | 1999-07-14 | Data transmission control method, data transmission method, data transmitter, and receiver |
| PCT/JP1999/003787 WO2000004676A1 (fr) | 1998-07-14 | 1999-07-14 | Procede de gestion de la transmission de donnees, procede de transmission de donnees, et emetteur et recepteur de donnees |
| DE69943228T DE69943228D1 (de) | 1998-07-14 | 1999-07-14 | Datenempfangsvorrichtung |
| CNB998015814A CN100382498C (zh) | 1998-07-14 | 1999-07-14 | 数据发送控制方法、数据发送方法和设备以及接收设备 |
| US09/521,098 US6966065B1 (en) | 1998-07-14 | 2000-03-07 | Data transmission control method, data transmitting method, data transmitting apparatus, and receiving apparatus |
| US11/217,917 US8209734B2 (en) | 1998-07-14 | 2005-09-01 | Data transmission control method, data transmitting method, data transmitting apparatus, and receiving apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20385798A JP4378780B2 (ja) | 1998-07-17 | 1998-07-17 | 受信装置及び受信方法 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2000036946A JP2000036946A (ja) | 2000-02-02 |
| JP2000036946A5 JP2000036946A5 (ja) | 2005-09-02 |
| JP4378780B2 true JP4378780B2 (ja) | 2009-12-09 |
Family
ID=16480854
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP20385798A Expired - Fee Related JP4378780B2 (ja) | 1998-07-14 | 1998-07-17 | 受信装置及び受信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4378780B2 (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3630037B2 (ja) | 1999-10-06 | 2005-03-16 | 日本電気株式会社 | Ｄｓｍ−ｃｃカルーセル受信装置及びそれに用いる受信方法並びにその制御プログラムを記録した記録媒体 |
| JP2001243043A (ja) | 2000-02-29 | 2001-09-07 | Sony Corp | ユーザインタフェースシステム、シーン記述生成装置及び方法、シーン記述変換装置及び方法、記録媒体並びに伝送媒体 |
| EP1148730A3 (en) | 2000-03-31 | 2003-10-08 | Matsushita Electric Industrial Co., Ltd. | Data broadcast apparatus for controlling presentation timing of additional data with high precision |
| JP2002094472A (ja) * | 2000-05-30 | 2002-03-29 | Matsushita Electric Ind Co Ltd | データ取得装置及びその方法 |
| JP4240766B2 (ja) * | 2000-06-26 | 2009-03-18 | パナソニック株式会社 | データ蓄積方法およびそれを実現した受信装置および放送システム |
| GB0016061D0 (en) * | 2000-06-30 | 2000-08-23 | Koninkl Philips Electronics Nv | Efficient recording of object carousels |
| JP2002044553A (ja) * | 2000-07-26 | 2002-02-08 | Toshiba Corp | 放送受信表示装置及び放送受信表示方法 |
| JP2002044551A (ja) * | 2000-07-26 | 2002-02-08 | Toshiba Corp | 放送受信表示装置及び放送受信表示方法 |
| JP4552290B2 (ja) * | 2000-08-21 | 2010-09-29 | ソニー株式会社 | データ伝送装置及び方法、データ処理装置及び方法 |
| JP2002158626A (ja) * | 2000-08-25 | 2002-05-31 | Matsushita Electric Ind Co Ltd | コンテンツ編集装置、コンテンツ編集方法及びコンテンツ編集プログラム並びにコンピューター読み取り可能な記録媒体 |
| JP5725235B1 (ja) | 2014-04-22 | 2015-05-27 | ソニー株式会社 | 受信装置及び受信方法、並びに、送信装置及び送信方法 |
| JP5725250B1 (ja) * | 2014-11-27 | 2015-05-27 | ソニー株式会社 | 送信装置及び送信方法、並びに受信装置及び受信方法 |
| JP5725249B1 (ja) * | 2014-11-27 | 2015-05-27 | ソニー株式会社 | 送信装置及び送信方法、並びに受信装置及び受信方法 |
| JP6337804B2 (ja) * | 2015-03-04 | 2018-06-06 | ソニー株式会社 | 受信装置及び受信方法 |
-
1998
- 1998-07-17 JP JP20385798A patent/JP4378780B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000036946A (ja) | 2000-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100641594B1 (ko) | 데이터 전달 제어 방법, 데이터 전송 방법, 데이터 송신장치, 수신 장치 | |
| JP5307315B2 (ja) | 前に放送された内容を番組の録画に組み込むシステムおよび方法 | |
| US8826111B2 (en) | Receiving apparatus and method for display of separately controllable command objects,to create superimposed final scenes | |
| US20160360248A1 (en) | Method and apparatus for decoding segments of an audiovisual stream | |
| JP5045535B2 (ja) | 受信装置及び受信方法 | |
| JP4378780B2 (ja) | 受信装置及び受信方法 | |
| JP2002010182A (ja) | データ蓄積方法およびそれを実現した受信装置および放送システム | |
| JP2001024995A (ja) | 放送装置、放送方法、及び受信装置 | |
| JP4378777B2 (ja) | 放送受信装置、放送受信方法 | |
| JP4016160B2 (ja) | データ受信・記録方法及びデータ受信装置 | |
| JP4296631B2 (ja) | 放送方法、及び受信装置 | |
| JP2000333138A (ja) | 情報処理装置及び情報処理方法 | |
| JP2000295586A (ja) | 放送用情報処理装置及び放送用情報処理方法 | |
| JP4378778B2 (ja) | 受信装置および受信方法 | |
| JP4366742B2 (ja) | 受信装置 | |
| JP2000333043A (ja) | 情報処理装置およびその方法 | |
| JP3671017B2 (ja) | デジタル放送受信方法および装置 | |
| JP2001024612A (ja) | 放送監視装置 | |
| JP2000331465A (ja) | 情報処理装置およびその方法 | |
| JP2000032415A (ja) | 受信装置 | |
| JP2001022625A (ja) | データ記録装置、データ記録方法、データ取得装置、データ取得方法 | |
| JP2000333041A (ja) | 情報処理装置及び情報処理方法 | |
| JP2000032362A (ja) | 情報伝送装置、及び情報伝送方法 | |
| JP2000295638A (ja) | 放送設備監視装置 | |
| JP4499205B2 (ja) | データ受信方法、データ受信装置及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050302 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050302 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080415 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080616 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090519 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090716 |
|
| 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: 20090825 |
|
| 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: 20090907 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121002 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121002 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131002 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |