JP2000036946A - 受信装置 - Google Patents

Abstract

(57)【要約】 【課題】 データサービス放送を受信する受信装置にお
いて、シーン出力、シーン切り換えに要する時間の短縮
を図る。 【解決手段】 伝送方式として、１シーン分のシーンデ
ータが原則１モジュールとされたうえで、１以上のモジ
ュールからなる伝送データをカルーセル方式により伝送
する場合に対応する受信装置として、カルーセルから抽
出してキュー７１に蓄積し、更にＤＳＭ−ＣＣバッファ
９１に取り込むべきシーンデータとしてのモジュール
を、シーンの優先順位に従って決定する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、例えばデジタル衛
星放送などのデータサービスにおける受信設備側に設け
られるとされる受信装置に関するものである。

【０００２】

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

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

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

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

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

【０００７】

【発明が解決しようとする課題】ここで、受信装置を所
有するユーザにとってみれば、あるチャンネルを選局し
て最初にシーンを表示するまでの待ち時間や、或るシー
ンから他のシーンに表示を切り換えるような際の待ち時
間はできるだけ短いようにすることが、快適な操作環境
という点で好ましい。

【０００８】例えば、シーン表示の切り換えが迅速に行
われるようにする対策として、受信装置側に比較的大容
量のバッファを備えるようにし、受信データから取り込
んだシーンごとのオブジェクトの集まりとしてのデータ
を、このバッファに格納しておくようにすることが考え
られる。このようにすれば、バッファから読み出したデ
ータに基づいて迅速に次のシーンに切り換えを行うこと
が可能になる。但し、上記のようなバッファを受信装置
に備えるということは、それだけ受信装置の回路規模の
大型化及びコストアップにつながるとう不利な点を抱え
ることになる。

【０００９】

【課題を解決するための手段】そこで本発明は上記した
課題を考慮して、受信装置側においてできるだけ迅速に
必要なシーンのデータが得られるようにし、例えばシー
ン出力の切り換えなども迅速に行われるようにすること
を目的とする。また、これを実現するのにあたり、例え
ば大容量のバッファなどを備えることなく、出来るだけ
小規模な回路で実現できるようにすることを目的とす
る。

【００１０】このため、１シーンを形成するシーンデー
タが１又は複数の情報伝送単位に対応するものとされ、
１以上の情報伝送単位から成る伝送データが循環的に送
信される送信情報を受信する受信装置として、送信情報
を受信して受信データとして取り込む受信手段と、情報
伝送単位でデータを一時蓄積可能なメモリ手段を備え、
受信データから情報伝送単位でデータの抽出を行ってメ
モリ手段に保持させ、このメモリ手段に蓄積されたシー
ンデータとしての情報伝送単位を、シーンデータ格納用
のシーンデータ格納手段に対して伝送して格納させるこ
とのできるシーンデータ取込手段と、シーンデータ格納
手段に格納されているシーンデータのうちから、所要の
シーンデータを利用してシーン出力を行うことのできる
シーン出力手段と、受信手段により受信された送信情報
からシーンの優先順位を示すシーン優先順位情報を獲得
する情報獲得手段と、この情報獲得手段により得られた
シーン優先順位情報に基づいて、受信データから抽出し
てメモリ手段に蓄積させるべきシーンデータとしての情
報伝送単位を選択するように上記シーンデータ取込手段
に対して制御を行う制御手段とを備えて構成することと
した。

【００１１】上記構成によれば、例えば１以上の情報伝
送単位（モジュール）から成る伝送データが循環的に送
信される送信方式（カルーセル方式）に対応して受信を
行う受信装置として、先ず、１シーンを形成するシーン
データが情報伝送単位に対応するものとされたことを前
提として、シーンの優先順位に従って、情報伝送単位
（即ちシーンデータ）を取り込んで、これをシーンデー
タ格納手段に格納するようにされる。つまり、シーンの
優先順位に従って、受信データから抽出して取り込むべ
きモジュールを決定するように規定するものである。こ
れにより、シーンデータ格納手段には、シーンの優先順
位の上位に従ってシーンが格納されていくことになる。

【００１２】

【発明の実施の形態】以降、本発明の実施の形態につい
て説明する。本発明が適用されるシステムとしては、デ
ジタル衛星放送を利用して番組を放送すると共に、受信
装置側ではこの番組に関連した楽曲データ（音声デー
タ）等の情報をダウンロードできるようにしたシステム
を例に挙げることとする。

【００１３】なお、以降の説明は次の順序で行うことと
する。 １．デジタル衛星放送システム １−１．全体構成 １−２．ＧＵＩ画面に対する操作 １−３．地上局 １−４．送信フォーマット １−５．ＩＲＤ ２．本発明に至った背景 ３．地上局側のデータマッピング例 ４．本実施の形態のキューへのモジュール割付

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００５４】１−４．送信フォーマット

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００９１】このため、本実施の形態のＣＰＵ８０とし
ては、主たる制御処理を実行する制御処理部８１に加
え、例えば少なくとも、ＤｅＭＵＸドライバ８２、ＤＳ
Ｍ−ＣＣデコーダブロック８３、及びＭＨＥＧデコーダ
ブロック８４が備えられる。本実施の形態では、このう
ち、少なくともＤＳＭ−ＣＣデコーダブロック８３及び
ＭＨＥＧデコーダブロック８４については、ソフトウェ
アにより構成される。ＤｅＭＵＸドライバ８２は、入力
されたトランスポートストリームのＰＩＤに基づいてデ
マルチプレクサ７０におけるフィルタ条件を設定する。
ＤＳＭ−ＣＣデコーダブロック８３は、ＤＳＭ−Ｍａｎ
ａｇｅｒとしての機能を有するものであり、ＤＳＭ−Ｃ
Ｃバッファ９１に格納されているモジュール単位のデー
タについて、ＭＨＥＧコンテンツのデータに再構築す
る。また、ＭＨＥＧデコーダブロック８４からのアクセ
スに従って所要のＤＳＭ−ＣＣデコード等に関連する処
理を実行する。

【００９２】ＭＨＥＧデコーダブロック８４は、ＤＳＭ
−ＣＣデコーダブロック８３により得られたＭＨＥＧコ
ンテンツのデータ、つまり、ＤＳＭ−ＣＣバッファ９１
にて得られているＭＨＥＧコンテンツのデータにアクセ
スして、シーン出力のためのデコード処理を行う。つま
り、そのＭＨＥＧコンテンツのスクリプトファイルによ
り規定されているオブジェクト間の関係を実現していく
ことで、シーンを形成するものである。この際、シーン
としてＧＵＩ画面を形成するのにあたっては、ＭＨＥＧ
バッファ９２を利用して、ここで、スクリプトファイル
の内容に従ってＧＵＩ画面の画像データを生成するよう
にされる。

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

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

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

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

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

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

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

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

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

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

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

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

【０１０５】２．本発明に至った背景 このようにＤＳＭ−ＣＣ方式を伝送規格として採用した
本実施の形態のデジタル衛星放送システムでは、受信装
置、つまりＩＲＤのタイプとして、受信バッファの構成
の点から２種類に分けることができる。

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

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

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

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

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

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

【０１１２】前述したように、モジュールを形成するオ
ブジェクトの関係はＤＳＭ−ＣＣ方式のもとでは特に限
定されるものではなく任意である。そこで、仮に図１５
に示すような、それぞれのオブジェクト１つがモジュー
ル１つに対応するようなマッピングを取って地上局１か
ら送信を行ったとする。なお、データサービスのディレ
クトリ構造に対するマッピングの処理は、ＤＳＭ−ＣＣ
エンコーダ４４にてモジュールを形成する処理に際し
て、ＭＨＥＧコンテンツのデータに対して行われるもの
である。

【０１１３】この場合、ＩＲＤ側において上記（Ｐｒ１
１）〜（Ｐｒ１４）の手順によってオブジェクトを次々
に得るには、一々新しいモジュールを受信することにな
る。このため、オブジェクトを得るごとにフィルタ条件
を何度もデマルチプレクサ７０に変更設定してフィルタ
リングする手順が必要であり、このようなフィルタリン
グ動作の繰り返しによってシーンの取り込みが遅れ、そ
の表示も遅くなるなどサービス性の低下を招くことにな
る。データサ−ビスの全データの大きさや放送時に割り
当てられる帯域にもよるが、カルーセル１回転の周期は
数秒から、１０秒以上に達することも考えられる。１回
のフィルタリングには最悪で力ルーセル１回転分（平均
１／２回転分）の待ち時間が生じるので、このフィルタ
リングの回数をできるだけ少なくすることがサービス性
の向上に直接結びついてくる。

【０１１４】また、シーンの切り換えについて考えてみ
ると、図１５に示すマッピングでは、表示中のシーンか
ら次のシーンのファイルを呼び込むときには、上位のデ
ィレクトリからたどらなくてはならない場合が生じる。
例えば図１５に示すマッピングの場合であれば、ａｐｐ
０／ｓｃｅｎｅｄｉｒ０からａｐｐ０／ｓｃｅｎｅｄｉ
ｒ１に移る場合は、既にａｐｐ０オブジェクトのＢＩＯ
Ｐメッセージからｓｃｅｎｅｄｉｒ１のｂｉｎｄｉｎｇ
情報が得られているが、ａｐｐ０／ｓｃｅｎｅｄｉｒ０
からａｐｐＮ／ｓｃｅｎｅｄｉｒ０に移る場合は、Ｓｅ
ｒｖｉｃｅ ＧａｔｅｗａｙオブジェクトのＢＩＯＰメ
ッセージにあったａｐｐＮオブジェクトのｂｉｎｄｉｎ
ｇ情報からａｐｐＮ／ｓｃｅｎｅｄｉｒ０を辿ることに
なる。つまり、シーンを変更するために、先ずＳｅｒｖ
ｉｃｅ Ｇａｔｅｗａｙオブジェクトのモジュールを受
信して、このＢＩＯＰメッセージからａｐｐＮのｂｉｎ
ｄｉｎｇ情報を得て、ａｐｐＮ／ｓｃｅｎｅｄｉｒ０の
ディレクトリを識別してから、このａｐｐＮ／ｓｃｅｎ
ｅｄｉｒ０のモジュールを受信せねばならなくなる。
（但し、上記した動作は、１回目のａｐｐＮをアクセス
のときだけである。２回目以降はａｐｐＮのｂｉｎｄｉ
ｎｇ情報を保持していればこの手順は不要となる。）つ
まり、このような場合もモジュールのフィルタリングに
よるシーン切り替えの待ち時間が大きくなる。

【０１１５】３．地上局側のデータマッピング例 そこで、本実施の形態では、先に述べた（Ｐｒ１）〜
（Ｐｒ６）によるオブジェクト抽出手順によっても、最
初のシーン表示や、シーンの切り替えによる待ち時間が
短縮されるように、次のようにオブジェクトのマッピン
グ方法を提案するものである。

【０１１６】図１２は、本実施の形態としてのデータサ
ービスのディレクトリ構造に対するマッピング例を示す
ものである。図１２においては、１つのシーンを構成す
るオブジェクト全てを１つのモジューとして纏め（モジ
ュール２，３・・Ｎ）、それ以外のＳｅｒｖｉｃｅＧａ
ｔｅｗａｙを含む上位ディレクトリを１つのモジュール
（モジュール１）にマッピングしている。ただし最初に
アクセスするアプリケーションファイル「Ｓｔａｒｔｕ
ｐ」は、最初のシーンのモジュールとー緒のモジュール
（モジュール２）にマッピングするようにする。

【０１１７】このようなマッピングとされれば、まずＳ
ｅｒｖｉｃｅ Ｇａｔｅｗａｙのモジュール１を受信す
れば、そのサブディレクトリの構成すべてが同じモジュ
ールに入っているので、ＩＲＤ１２側ではディレクトリ
構成全体をこのモジュール１の受信で得ることができ
る。そして、これに続いてモジュール２を受信すること
になるが、このモジュール２は最初に提示するシーンの
ファイルがマッピングされて形成されたモジュールであ
る。従って、このモジュール２のデータの取り込みが完
了した段階で、最初のシーン出力に必要なオブジェクト
の情報が全て得られることになる。つまり、先に示した
（Ｐｒ５）の手順が完了した段階では、（Ｐｒ６）の手
順もほぼ同時に完了させていることになる。実際には、
キュー７１にてモジュール２が得られたら、このモジュ
ール２を１シーン分のデータとして、ＤＳＭ−ＣＣバッ
ファ９１に伝送するようにされる。なお、このような手
順は、ルートディレクトリを含むモジュール１について
も同様に行われる。従って、この場合には、モジュール
１、モジュール２と続けて、２回のモジュールの受信
（獲得）さえ完了すれば、そのまま最初のシーンをの再
生を始めることができる。また、さらに別のシーンに切
り替わる場合は、最初に取り込んだディレクトリ・オブ
ジェクトのｂｉｎｄｉｎｇ情報を参照すれば、直接所望
のシーン・ディレクトリのモジュールを受信しにいくこ
とができる。

【０１１８】この場合でも、確かにシーン切り替えのオ
ーバーヘッドは大きくないが、データサービスの最初の
シーンの提示までに、モジュールを２回受信する必要が
ある。

【０１１９】なお、図１２に示すマッピングでは、上位
ディレクトリをまとめたモジュール１に、多くのオブジ
ェクトが入ることになるが、Ｓｅｒｖｉｃｅ Ｇａｔｅ
ｗａｙとディレクトリの２種類のオブジェクトは、上記
のようにそのディレクトリにｂｉｎｄされるオブジェク
トの名称やＩＯＲといったデータ量としてはさほど大き
くない情報の組み合わせで出来ているため、オブジェク
トの数が多くても全体のデータ容量は大きくないもので
ある。

【０１２０】また図１３に本実施の形態としての他のマ
ッピング例を示す。ここでは、上位ディレクトリを纏め
たものに、さらに最初にアクセスするアプリケーション
ファイル（ｓｔａｒｔｕｐ）と最初のシーンのオブジェ
クトを１つのモジュール１にマッピングしている。これ
以外の他のモジュール２・・Ｎは、図１２に示したモジ
ュール３・・Ｎ等と同様に、１シーンごとに必要とされ
るオブジェクトを纏めて形成されている。このようなマ
ッピングを施して送信した場合には、ＩＲＤ側ではこの
モジュール１だけを受信して、キュー７１からＤＳＭ−
ＣＣバッファ９１に伝送することで、すぐに最初のシー
ンを表示することができることになる。また、この段階
で、ディレクトリ・オブジェクトのｂｉｎｄｉｎｇ情報
が参照可能となるので、以降のシーンの切り換えに対応
して必要なシーンのオブジェクトから成るモジュールに
直ちにアクセスすることが可能になる。

【０１２１】なお、上記マッピング例としては、１シー
ンを形成するオブジェクトが必ず１モジュールに収まる
ようにしているが、場合によっては、１シーンを形成す
る全てのオブジェクトの容量が大きく、モジュールとし
て規定されている最大サイズを超えるような場合、例え
ば、ｎ番目のモジュールに対して或る１シーンを形成す
るオブジェクトを出来るだけ納めるようにし、ｎ番目の
モジュールに収まりきらなかった同一シーンを形成する
オブジェクトによりｎ＋１番目のモジュールを形成する
ようにする。そして、このｎ番目のモジュールとｎ＋１
番目のモジュールを連続させて、カルーセル方式で送信
する。このようにすれば、ｎ番目のモジュールとｎ＋１
番目のモジュールを２回受信する必要はあるが、比較的
迅速にシーンの再生を行うことが出来る。また、以降の
説明においては、上述のようにして１シーンを形成する
ことのできるオブジェクトが全て格納されることで形成
されたモジュールのことを、「シーンモジュール」とも
いうことにする。

【０１２２】４．本実施の形態のキューへのモジュール
割付 続いて、本発明の実施の形態の特徴となるＩＲＤ１２側
の受信処理として、キュー７１へのモジュール割付につ
いて図１６〜図２０を参照して説明する。本実施の形態
のＩＲＤ１２では、上記した放送側（地上局側）のデー
タマッピングが行われることを前提として、以降説明す
るキュー７１へのモジュール割付を行うことで、更に効
率的に必要なシーンを得ることが可能になるものであ
る。

【０１２３】図１６（ａ）には、トランスポート部５３
におけるデマルチプレクサ７０とキュー７１の構成、及
びＤＳＭ−ＣＣバッファ９１のメモリ領域を概念的に示
している。

【０１２４】この図に示すトランスポート部５３として
は、デマルチプレクサ７０と、キュー７１を形成するメ
モリ領域Ｍｅｍ−１，Ｍｅｍ−２，Ｍｅｍ−３・・・Ｍ
ｅｍ３２が示されている。そして、これら各メモリ領域
がモジュール単位のデータを蓄積可能とされている。前
述したように、デマルチプレクサ７０に与えられたフィ
ルタ条件に適合する種類のデータ（例えばセクション単
位）がトランスポートストリームから分離抽出されるの
であるが、この分離抽出されたセクションは、メモリ領
域Ｍｅｍ−１〜Ｍｅｍ−３２の何れかに対して格納され
る。そして、この動作が繰り返される結果、或るメモリ
領域に対して上記フィルタ条件に適合して集められたセ
クションの集合より成るモジュールが形成されて、ここ
に蓄積されることになる。

【０１２５】ここで、例えば、デマルチプレクサ７０に
より、シーンＡを形成するデータにより形成されるモジ
ュールのデータを分離抽出して、メモリ領域Ｍｅｍ−２
に格納したとする。そして、このシーンＡのモジュール
をＧＵＩ画面表示に使用する場合には、このシーンＡの
モジュールのデータをメモリ領域Ｍｅｍ−２からＤＳＭ
−ＣＣバッファに対して書き込みを行うようにされる。
つまり、受信したシーンのモジュールの一般的な伝送形
態としては、一旦これをキューのメモリ領域にて蓄積し
た後、ＤＳＭ−ＣＣバッファ９１に取り込むようにする
ことになる。そして、前述したようにＤＳＭ−ＣＣバッ
ファ９１に取り込まれたシーンデータを、ＭＨＥＧデコ
ーダブロック８４がアクセスしてロードし、ＭＨＥＧバ
ッファに取り込むことでＧＵＩ画面等のシーン出力が可
能になる。

【０１２６】ところで、ここでもメモリ領域Ｍｅｍ−１
〜Ｍｅｍ３２として示されているように、キュー７１を
形成するメモリ領域は本実施の形態では３２列に限定さ
れている。そして、これらのメモリ領域は、実際にはト
ランスポートストリームを受信する動作を行っている限
りは、各種異なるフィルタ条件に適合して分離された、
例えばＭＰＥＧストリームデータ等をはじめとする多種
のモジュールデータによりほぼ占有されている状態にあ
る。このような状況は、例えば、ＭＨＥＧデコーダブロ
ック８４がアクセスする必要があるとされる多数のシー
ンモジュールをＤＳＭ−ＣＣバッファ９１に取り込もう
としても、このシーンモジュールを一時保持するメモリ
領域数が制限されていることで、例えば必要とされるシ
ーンモジュールの多くを一度にキュー内の複数のメモリ
領域に蓄積して、ＤＳＭ−ＣＣバッファ９１に転送する
ことが事実上困難であることを意味する。また、ＤＳＭ
−ＣＣ方式では、モジュールの受信順（取込順）を特に
規定してはいない。つまり、トランスポート部５３にお
いてどのような順序でシーンモジュールを抽出してメモ
リ領域に格納するのかは任意とされている。

【０１２７】そこで、本実施の形態では、上記したメモ
リ領域数の制限が有ることを踏まえた上で、ＤＳＭ−Ｃ
Ｃバッファ９１に取り込む必要のあるモジュールが出来
るだけ迅速にトランスポート部５３にて得られるよう
に、次のようにしてモジュール割付（受信順）を規定す
る。

【０１２８】先に、説明したようにデータサービスのデ
ィレクトリ構造、及びこのディレクトリ構造に対するモ
ジュールのマッピングは、例えば図１２、図１３に示す
ものとされるが、例えばａｐｐ０のディレクトリに関す
れば、ａｐｐ０／ｓｔａｒｔｕｐと、ａｐｐ０／ｓｃｅ
ｎｅｄｉｒ０／ｓｃｓｎｅ０のオブジェクトを得さえす
れば、ａｐｐ０のアプリケーションを形成するシーンの
優先順位の情報を得ることが出来るようになっている。
これはａｐｐ１〜Ｎまでの他のアプリケーションについ
ても同じことがいえる。ここでいう優先順位とは、例え
ば或るシーンの表示出力から他のシーンの表示出力に移
行する（これを「トランジション」ともいう）場合に
は、上記他のシーンとして複数の候補があるのが通常で
あるが、これら複数のシーンの候補において、例えばユ
ーザの操作によってシーン切り換えの必要があるとされ
たときに、切り換えが行われる可能性の高さに従って付
されているものである。

【０１２９】本実施の形態では、このシーンの優先順位
の情報に基づいてモジュール割付を規定するが、これに
ついて、再度図１６を参照して説明する。ここでは、説
明の便宜上、トランスポート部５３においてシーンモジ
ュールを保持することのできるメモリ領域はＭｅｍ−２
のみとされて、他のメモリ領域は、それ以外の種類のモ
ジュールを格納するために占有されているものとする。
また、ここでは、ａｐｐ０のアプリケーションによりシ
ーン出力する場合に関して説明する。

【０１３０】ここで、トランスポート部５３において
は、既に上記したａｐｐ０／ｓｔａｒｔｕｐと、ａｐｐ
０／ｓｃｅｎｅｄｉｒ０／ｓｃｓｎｅ０のオブジェクト
が属するモジュールを受信しており、例えばＣＰＵ８０
の制御処理部８１では、ａｐｐ０のアプリケーションに
おけるシーンの優先順位情報が得られているものとす
る。そして、ここでは優先順位情報により、ａｐｐ０の
ディレクトリ構造化にある複数シーンについて、シーン
Ａ→シーンＢ→シーンＣ→シーンＤ・・のようにして優
先順位が与えられているものとし、これらのシーンをＤ
ＳＭ−ＣＣバッファ９１に出来るだけ取り込むことが必
要であるとする。

【０１３１】このような場合、制御処理部８１では、先
ず、優先順位が最も高いシーンＡのモジュールがトラン
スポート部５３のメモリ領域Ｍｅｍ−２に格納されるよ
うに制御を実行する。この制御に基づき、デマルチプレ
クサドライバ８２は、シーンＡのモジュールに適合する
フィルタ条件をデマルチプレクサ７０に対して設定す
る。これにより、図１６（ａ）に示すようにして、シー
ンＡのモジュールがメモリ領域Ｍｅｍ−２に格納され、
ＤＳＭ−ＣＣバッファ９１に転送する。

【０１３２】続いては、制御処理部８１は、シーンＡに
続く優先順位のシーンＢを獲得するための処理として、
シーンＢのモジュールに適合するフィルタ条件をデマル
チプレクサ７０に対して設定するようにデマルチプレク
サドライバ８２に指示する。これにより、図１６（ｂ）
に示すようにして、シーンＢのモジュールがメモリ領域
Ｍｅｍ−２に得られ、これをＤＳＭ−ＣＣバッファ９１
に転送することになる。なお、図１６（ｂ）には、図１
６（ａ）に示した回路ブロックのうち、メモリ領域Ｍｅ
ｍ−２とＤＳＭ−ＣＣバッファ９１のみを抜き出して示
している。次に示す図１６（ｃ）も同様である。

【０１３３】更に次は、シーンＢに続く優先順位のシー
ンＣを得るために、シーンＣのモジュールに適合するフ
ィルタ条件をデマルチプレクサ７０に対して設定し、図
１６（ｃ）に示すようにして、シーンＣを得てＤＳＭ−
ＣＣバッファ９１に転送する。

【０１３４】以降、同様にして優先順位に従ったシーン
のフィルタ条件をデマルチプレクサ７０に設定して、そ
のシーンモジュールをメモリ領域Ｍｅｍ−２にて得て、
これをＤＳＭ−ＣＣバッファ９１に転送していくように
される。

【０１３５】このような動作が行われる結果、ＤＳＭ−
ＣＣバッファ９１には、シーン出力のために必要、或い
はシーン切り換え時において、次に必要となる可能性の
高いシーンモジュールのデータがその優先順位に従って
格納されることになる。ＭＨＥＧデコーダブロック８４
は、このようにしてＤＳＭ−ＣＣバッファ９１にて得ら
れたシーンモジュールのデータにアクセスしてＧＵＩ画
面などのシーン出力を行うが、例えばデータ放送中にお
いてユーザの操作により所望のシーンの呼び出しの要求
が有った場合、呼び出し要求のあったシーンのデータが
ＤＳＭ−ＣＣバッファ９１に既に保持されている可能性
は非常に高く、ほぼ確実に呼び出し要求のあったシーン
データにアクセスして、これを即座に出力させることが
可能になる。

【０１３６】ところで、ＤＳＭ−ＣＣバッファ９１の容
量は当然のこととして有限であり、実際にはさほど多く
の容量は割り当てられない。このため、例えばＭＨＥＧ
デコーダブロック８４により使用することが想定される
全てのシーンモジュールを格納することが出来ない場合
がある。このために、例えば次のような不都合が生じる
ことが想定される。

【０１３７】ここで、例えば図１７に示すようにして、
あるアプリケーションのもとでシーンＡ，シーンＢ，シ
ーンＣ，シーンＤ，シーンＥの５つのシーンが用意され
ているとして、この各シーン間のトランジションの形態
が図のように設定されている（このようなトランジジョ
ンの規定はＭＨＥＧにより記述されている）ものとす
る。例えばシーンＡであれば、シーンＢ，Ｃ，Ｅにトラ
ンジションが可能とされ、シーンＢであればシーンＡ，
Ｃにトランジション可能とされている。

【０１３８】そして、ＤＳＭ−ＣＣバッファ９１の容量
として、最大で４つのシーンモジュールを格納すること
が限度であると仮定する。この条件の下で上記図１７に
示すシーンＡ〜Ｅの５つのモジュールが用意されたアプ
リケーションをＭＨＥＧデコーダブロック８４が使用す
るとした場合、上記シーンＡ〜Ｅの５つのモジュールの
うち、１つのシーンモジュールはＤＳＭ−ＣＣバッファ
９１に格納できないことになる。

【０１３９】上記した条件の下、例えば或る段階でシー
ンＡを表示出力しており、このときＤＳＭ−ＣＣバッフ
ァ９１に取り込まれているシーンモジュールはシーン
Ａ，Ｂ，Ｃ，Ｄの４つであるとする。そして、この状態
から、例えばユーザの操作によりシーンＥの呼び出し要
求が有ったとすると、これに応答してシーンＡからシー
ンＥにトランジションすることになる。ところが、この
ときＤＳＭ−ＣＣバッファ９１にはシーンＥのモジュー
ルは無いことから、シーンＥの呼び出し要求に応えるた
めには、シーンＥのモジュールをカルーセルから新規に
取り込む必要がある。この間、ユーザにとってはシーン
ＡからシーンＥの表示に移行するまでの待ち時間が生じ
ることになる。

【０１４０】そこで、このような不都合が出来るだけ解
消されるようにするため、本実施の形態では、更に次の
ようなモジュール割付も行うようにされる。

【０１４１】実際のＭＨＥＧ方式によるデータサービス
では、或るアプリケーションにおける複数シーン間の優
先順位は、現在表示出力中のシーンに依存して変更され
る場合がある。このような出力中のシーンに応じて変更
される優先順位も、前述した優先順位情報に基づいて得
ることが出来る。そこで、本実施の形態では、ＭＨＥＧ
デコーダブロック８４のプログラムとして、現在あるシ
ーンを出力しているときに、その出力中のシーンを基準
として他のシーンの優先順位を管理する、ネクストシー
ンマネージャ（Next Scene Manager）を起動させること
とする。

【０１４２】ここで、ネクストシーンマネージャの管理
例として、図１７に示したシーンのうちで現在シーンＡ
を出力中の場合に、ネクストシーンマネージャにより管
理されている優先順位が図１８に示したものであったと
する。つまり、優先順位として（１）シーンＡ→（２）
シーンＣ→（３）シーンＥ→（４）シーンＢ→（５）シ
ーンＤの順位で管理されているものとする。このような
優先順位は、実際には、図に示すようなプライオリティ
値によって決定される。このプライオリティ値が大きい
ほど優先順位は高いことになり、ここでは、シーンＡに
対する他のシーンのプライオリティ値として、シーンＣ
が‘１０’、シーンＥが‘９’、シーンＢが‘７’、シ
ーンＤが‘１’とされている。そして、このときＤＳＭ
−ＣＣバッファ９１に格納されているシーンモジュール
は、図２０（ａ）に示すように、シーンＡ，Ｅ，Ｃ，Ｂ
であるとする。

【０１４３】この状態の下で、例えばシーンＡからシー
ンＣにトランジジョンするための要求が行われたとする
と、ＭＨＥＧデコーダブロック８４では、図２０（ａ）
に示した格納状態にあるＤＳＭ−ＣＣバッファ９１から
シーンＣのデータにアクセスして、これを出力するため
の処理を実行する。

【０１４４】また、ＭＨＥＧデコーダブロック８４で
は、シーンＣにトランジションしたことに対応して、ネ
クストシーンマネージャによりシーンの優先順位を、例
えば図１９に示すように更新して管理する。この図で
は、現在出力中のシーンＣを筆頭に、（１）シーンＣ→
（２）シーンＢ→（３）シーンＡ→（４）シーンＤ→
（５）シーンＥの順位であるとして管理している。ま
た、この場合のシーンＣに対する他のシーンのプライオ
リティ値は、それぞれシーンＢが‘７’、シーンＡが
‘６’、シーンＤが‘４’、シーンＥが‘２’とされて
おり、上記優先順位はこのプライオリティ値に従って決
定されたものである。このように、現在出力中のシーン
に応じて、シーン間の優先順位は変更される。

【０１４５】そして、本実施の形態では、上記図１９に
示すようにして更新されたシーン間の優先順位に基づい
て、次のようにしてＤＳＭ−ＣＣバッファ９１に格納さ
れるシーンモジュールの内容を更新する。例えば、ＣＰ
Ｕ８０は、上記図１９に示す、現在ネクストシーンマネ
ージャにより管理されているシーン間の優先順位と、図
２０（ａ）のＤＳＭ−ＣＣバッファ９１に格納されてい
るシーンモジュールとの比較を行う。すると、ＤＳＭ−
ＣＣバッファ９１には、図１９に示す優先順位として１
位のシーンＣ、２位のシーンＢ、３位のシーンＡ、及び
５位（最下位）のシーンＥが格納されており、４位のシ
ーンＤが格納されていないことが分かる。

【０１４６】そこで、ＣＰＵ８０においては、ＤＳＭ−
ＣＣバッファ９１に格納されるシーンモジュールが、現
在管理されている優先順位における上位４つのシーンと
なるように制御を実行する。つまり、この場合であれ
ば、図２０（ｂ）に示すようにして、シーンＥの代わり
にシーンＤのモジュールがＤＳＭ−ＣＣバッファ９１に
格納されるようにして、結果的に上位４つのシーンモジ
ュールが格納されるようにするものである。

【０１４７】このためには、先ず、例えばデマルチプレ
クサドライバ８２からデマルチプレクサ７０に対して、
シーンＤのモジュールを得るためのフィルタ条件を出力
させるように、ＣＰＵ８０における制御処理部８０が指
示をするようにされる。これにより、キュー７１におい
てシーンデータのモジュールのために割り当てられたメ
モリ領域にシーンＤのモジュールが格納される。そし
て、このキュー７１のメモリ領域に得られたシーンＤの
モジュールが、シーンＥのモジュールと入れ替わるよう
にして、ＤＳＭ−ＣＣバッファ９１に対する書き込み制
御を実行するものである。この書き込み制御も、例えば
制御処理部８０が実行するようにされればよい。なお、
シーン切り換えに応じて変更されたシーンの優先順位
と、それまでのＤＳＭ−ＣＣバッファ９１に格納されて
いるシーンモジュールデータとの比較で、２以上のシー
ンモジュールを入れ替える必要が有れば、上記した制御
動作に準じてこれらのシーンモジュールについての取り
込みを行うようにされる。

【０１４８】例えば、或るシーンを出力させている状態
の下で、ユーザがシーンの切り換え操作を行う場合、や
はり実際には、その時点でネクストシーンマネージャに
より管理されている優先順位に従って、切り換えのシー
ンが選択される可能性が高い。このため、上記のように
して、現在出力中のシーンに応じて決定されるシーンの
優先順位の上位のシーンから優先的にＤＳＭ−ＣＣバッ
ファ９１に取り込むように、トランスポート部５３にお
けるモジュール割付を規定すれば、例えば、先に述べた
ように、シーンのトランジジョンの要求があったとき
に、このシーンのモジュールがＤＳＭ−ＣＣバッファ９
１に格納されていないといった状況が生じる可能性は極
力回避される。従って、ほとんどの場合、シーンの切り
換え操作に応じて即座にシーンの切り換えが行われるこ
とになるものである。

【０１４９】なお、シーン切り換えに応じて変更された
シーンの優先順位に応じて、例えば上記図２０（ａ）か
ら図２０（ｂ）に示したようにして、ＤＳＭ−ＣＣバッ
ファ９１の格納状態を遷移させるまでには、実際には、
或る程度の時間がかかるのであるが、例えば、シーンＣ
の出力が開始されて後において最初のシーン切り換え操
作が行われるまでには、通常、或る程度の期間が存在す
る。つまり、シーンＣが出力開始されてしばらくはユー
ザは、シーンＣの画像を見ているのが普通である。そし
て、たいていはこの間にＤＳＭ−ＣＣバッファ９１にお
けるシーンデータの入れ替えはほぼ終了しているため、
実用上は問題にはならないものである。

【０１５０】続いて、上記図１８〜図２０により説明し
たモジュール割付を実現するための処理動作について、
図２１のフローチャートを参照して説明する。この図に
示す処理は、ＣＰＵ８０が実行するものとされる。つま
り、制御処理部８１の全体制御に基づいて、デマルチプ
レクサドライバ８２、ＤＳＭ−ＣＣデコーダブロック８
３、及びＭＨＥＧデコーダブロック８４が適宜所要の制
御処理を実行することにより実現されるものである。ま
た、この図においては、例えばユーザによるシーン切り
換え要求のための操作等が行われたことでシーン切り換
えが必要とされた場合における、シーンモジュール割付
に関する対応処理を示している。

【０１５１】この図に示すルーチンにおいては、先ずス
テップＳ１０１において、シーン切り換え前のネクスト
シーンマネージャのシーン優先順位に従って挙げられた
シーン候補と、シーン切り換え後のネクストシーンマネ
ージャのシーン優先順位に従って挙げられたシーン候補
とを比較して、これらのシーン候補間で一致しないもの
をリストアップする。また、上記シーン候補間で共通に
一致したシーンについては、シーン切り換えに応じてシ
ーンネクストマネージャが扱うべき「シーンリスト」に
対して登録が行われる。この処理は、例えばＭＨＥＧデ
コーダブロック８４において、ネクストシーンマネージ
ャを起動させることにより実現される。

【０１５２】続くステップＳ１０２においては、ＭＨＥ
Ｇデコーダブロック８４の処理として、上記ステップＳ
１０１にてリストアップされた一致しないシーン候補の
うちで、シーン切り換え前のシーン候補とされていたも
のについては削除し、シーン切り換え後に候補とされて
いるシーンについてはシーンリストに追加するための処
理が実行される。この処理によって、シーン切り換えに
応じて候補となる複数シーンが、シーンリストとして用
意されることになる。

【０１５３】続くステップＳ１０３においては、ネクス
トシーンマネージャの機能を用い、上記シーンリストと
して登録されたシーンについて、シーン切り換えに応じ
て変更されたシーンの優先順位に従ってソートを実行す
るようにされる。これにより、図１８に示すネクストシ
ーンマネージャの管理状態から、図１９に示すネクスト
シーンマネージャの管理状態に移行することになる。な
お、上記ステップＳ１０１〜Ｓ１０３までに示す処理の
うち、ステップＳ１０１，及びＳ１０２の処理について
は、先の図１８及び図１９に依る説明では特に言及して
いない。これは、図１８、図１９に示した場合において
は、シーンＡからシーンＣへのシーン切り換えによって
は、シーン候補の入れ替えが無いことによる。即ち、図
１８から図１９の遷移に対応するシーン切り換えに際し
ては、ステップＳ１０１において一致しないシーンがリ
ストアップされず、全てのシーンが一致したとして、シ
ーンリストに登録されたことになる。

【０１５４】ステップＳ１０３に続いては、ステップＳ
１０４の処理が実行される。ここでは、上記ステップＳ
１０３においてソートされたシーンリスト上において、
優先順位的に最上位のシーンについての処理を開始す
る。つまり、このシーンを「現シーン」として扱って以
降の処理を実行していくようにされる。また、ステップ
Ｓ１０４においての「優先順位的に最上位のシーン」と
は、現在出力中とされているシーン（図１９であればシ
ーンＣ）を除いて、最も優先順位の高いシーンが選択さ
れる。つまり、図１９の場合で有ればシーンＢが選択さ
れることになる。但し、例えば図１９に示す優先順位の
管理状態が得られたとき、シーンＣがＤＳＭ−ＣＣバッ
ファ９１に格納されていない場合には、例外的にこのシ
ーンＣを現シーンとして扱うようにステップＳ１０４で
の処理が行われるものとする。

【０１５５】続くステップＳ１０５においては、上記ス
テップＳ１０４にて選択された現シーンのデータにより
形成されるモジュール（シーンモジュール）のデータサ
イズをチェックする。これは、例えば現シーンモジュー
ルに対応する制御情報であるＤＩＩ（図８参照）をカル
ーセルのデータから取り込み、例えばＤＳＭ−ＣＣデコ
ーダブロック８３が、この取り込んだＤＩＩにおけるモ
ジュールのデータサイズを示す情報を参照することで識
別が可能とされる。ここで得られた現シーンモジュール
のデータサイズの情報は一時保持されて、後述するステ
ップＳ１０７の判別処理に用いられる。

【０１５６】ステップＳ１０６においては、現シーンモ
ジュールがＤＳＭ−ＣＣバッファ９１に既に取り込まれ
ている状態にあるか否かが判別され、ここで肯定結果が
得られればステップＳ１１０に進んで、シーンリスト上
で、これまでの現シーンに対して次の優先順位が与えら
れているシーンを現シーンとして選択して、この現シー
ンとしての処理を開始させるための処理を実行する。こ
れに対して、ステップＳ１０６において否定結果が得ら
れた場合には、ステップＳ１０７の処理に移行する。

【０１５７】ステップＳ１０７においては、現在のＤＳ
Ｍ−ＣＣバッファ９１の残り容量（データ取込可能容
量）が、ステップＳ１０５にてチェックされた現シーン
モジュールのサイズよりも大きいか否かを判別する。そ
して、肯定結果が得られた場合、つまり、現在のＤＳＭ
−ＣＣバッファ９１の残り容量として、現シーンモジュ
ールを取り込んで格納するだけの余裕があると判別され
た場合には、ステップＳ１１１に進んで現シーンモジュ
ールのデータをカルーセルからキュー７１に蓄積し、こ
れをＤＳＭ−ＣＣバッファ９１に対して取り込んで格納
するための処理が実行される。この処理を実現するため
のＣＰＵ８０の制御動作とこれに伴う各部の信号処理動
作は、例えば図２０の説明において述べたとおりであ
る。そして、上記ステップＳ１１１の処理を実行した後
はステップＳ１１０の処理を経た上で、ステップＳ１０
５の処理に戻るようにされる。

【０１５８】また、ステップＳ１０７において否定結果
が得られ、現在のＤＳＭ−ＣＣバッファ９１の残り容量
が、ステップＳ１０５にてチェックされた現シーンモジ
ュールのサイズよりも小さいと判別された場合には、ス
テップＳ１０８に進む。ステップＳ１０８においては、
現在のネクストシーンマネージャの優先順位管理と、現
在ＤＳＭ−ＣＣバッファ９１に格納されているシーンモ
ジュールとを比較して、現在ＤＳＭ−ＣＣバッファ９１
に格納されているシーンモジュールにおいて、現在最も
優先順位（プライオリティ）が低いものとして管理され
ているシーンモジュールを特定する。そして、次のステ
ップＳ１０９において、この特定されたシーンモジュー
ルのプライオリティが、現シーンよりも低いか否かを判
別するようにされる。

【０１５９】ステップＳ１０９において、ステップＳ１
０８により特定されたシーンモジュールのプライオリテ
ィが現シーンよりも低いとされた場合には、ステップＳ
１１２に進んで、この特定されたシーンモジュールをＤ
ＳＭ−ＣＣバッファから削除してステップＳ１０７に戻
るようにされる。この処理により、現シーンモジュール
が取り込み可能なＤＳＭ−ＣＣバッファ９１の残り容量
が得られるまで、ＤＳＭ−ＣＣバッファ９１から優先順
位（プライオリティ）の最も低いシーンモジュール（但
し現シーンよりもプライオリティが低いもののみが対象
となる）が削除されていくことになる。

【０１６０】そして、ステップＳ１０９において否定結
果が得られた場合、つまり、ステップＳ１０８にて特定
されたシーンモジュールのプライオリティが、現シーン
よりも高いことが判別された場合であるが、この段階で
は、結果的に、ＤＳＭ−ＣＣバッファ９１に格納されて
いるシーンモジュールは、現在のネクストシーンマネー
ジャにより管理されているシーンの優先順位に対応して
いることになる。つまり、先に説明した具体例に従え
ば、図１９に示したネクストシーンマネージャの管理に
対応して、図２０（ｂ）に示すシーンモジュールの格納
状態が得られるものである。この場合には、図のように
して、これまでのモジュール割付のための処理が終了さ
れることになる。

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

【０１６２】

【発明の効果】以上説明したように本発明は、伝送方式
として、１シーン分のシーンデータが原則１モジュール
を形成するものとされたうえで、１以上のモジュールか
らなる伝送データをカルーセル方式により伝送する場合
に対応する受信装置として、カルーセル（伝送情報）か
ら抽出してキュー（メモリ手段）に取り込むべきシーン
データとしてのモジュールを、シーンの優先順位に従っ
て決定するように規定される。例えば、キューに対する
モジュールの取込順を特に規定しない場合、表示出力に
必要なシーンデータを得て、これをシーンデータ格納手
段（ＤＳＭ−ＣＣバッファ）に取り込むまでには相応の
時間を要することになる。また、これを解消しようとし
て、目的のシーンデータとしてのモジュールが出来るだ
け迅速にシーンデータ格納手段にて得られるようにする
ためには、多くのキュー数が必要となってしまう。これ
に対して、本発明では、上記構成によって優先順位に従
ってシーンデータとしてのモジュールを取り込むように
されるため、制限されたキュー数の構成のもとであって
も、表示出力に必要、又は必要とされる可能性の高いシ
ーンデータが比較的迅速に得られることになる。つま
り、本発明では、キュー数が少なくてもシーン出力、及
びシーン切り換えに迅速に対応できることになる。ま
た、逆に言えば、本発明を適用せずに迅速なシーン出
力、シーン切り換えを実現しようとした場合と比較し
て、キュー数を削減することが可能であり、それだけＩ
ＲＤ（受信装置）の回路規模の縮小及び低コスト化を図
ることが可能となる。

【０１６３】また、現在出力されているシーンに応じて
変更される優先順位に応じて、受信データのカルーセル
から取り込むべきシーンデータとしてのモジュールが決
定されるため、常にシーン表示の切り換えに対応して、
シーンデータ格納手段には優先順位的に上位のシーンデ
ータから優先的に格納されている状態が得られることに
なる。この場合、シーン表示の切り換え操作によって選
択されるシーンのシーンデータがシーンデータ格納手段
に格納されている可能性が非常に高く、これにより、例
えばユーザによってシーン表示の切り換え操作が行われ
たとしても、ほとんどの場合において、そのシーンの切
り換えが迅速に行われることになる。この構成は、シー
ンデータ格納手段（ＤＳＭ−ＣＣバッファ）の容量に制
限があって、多数のシーンデータを格納することが出来
ないような条件の下で特に有効となる。

【図面の簡単な説明】

【図１】本発明の実施の形態のデジタル衛星放送受信シ
ステムの構成例を示すブロック図である。

【図２】本実施の形態における受信設備の構築例を示す
ブロック図である。

【図３】ＩＲＤのためのリモートコントローラの外観を
示す正面図である。

【図４】放送画面とＧＵＩ画面との切り換えを示す説明
図である。

【図５】地上局の構成例を示すブロック図である。

【図６】地上局から送信されるデータを示すチャート図
である。

【図７】送信データの時分割多重化構造を示す説明図で
ある。

【図８】ＤＳＭ−ＣＣによる送信フォーマットを示す説
明図である。

【図９】トランスポートストリームのデータ構造図であ
る。

【図１０】ＰＳＩのテーブル構造を示す説明図である。

【図１１】ＩＲＤの構成を示す説明図である。

【図１２】本実施の形態としてのデータサービスのディ
レクトリ構造に対するマッピング例を示す説明図であ
る。

【図１３】本実施の形態としてのデータサービスのディ
レクトリ構造に対する他のマッピング例を示す説明図で
ある。

【図１４】データサービスのディレクトリ構造の一例を
示す説明図である。

【図１５】データサービスのディレクトリ構造に対する
マッピング例を示す説明図である。

【図１６】本実施の形態のシーンデータのモジュールの
取込動作を示す説明図である。

【図１７】シーンのトランジション例を示す説明図であ
る。

【図１８】図１７に示すシーンのトランジション例に従
った、ネクストシーンマネージャにおいて管理されるシ
ーン優先順位例を示す説明図である。

【図１９】図１７に示すシーンのトランジション例に従
った、ネクストシーンマネージャにおいて管理されるシ
ーン優先順位例を示す説明図である。

【図２０】図１８から図１９の遷移として示すシーン優
先順位の変更に応じたシーンデータのモジュールの取込
動作を示す説明図である。

【図２１】本実施の形態のシーン切り換えに応じたモジ
ュール割付けを実現するためのフローチャートである。

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 北里 直久 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 (72)発明者 斎藤 潤也 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 Ｆターム(参考） 5C025 BA27 CA01 CB08 CB09 DA01 DA04 DA05 5C064 BA01 BB01 BB05 BB07 BC06 BC10 BC16 BC18 BC20 BC23 BC25 BD02 BD08 BD13

Claims (2)

【特許請求の範囲】
1. 【請求項１】 １シーンを形成するシーンデータが１又
   は複数の情報伝送単位に対応するものとされ、１以上の
   上記情報伝送単位から成る伝送データが循環的に送信さ
   れる送信情報を受信する受信装置として、 上記送信情報を受信して受信データとして取り込む受信
   手段と、 上記情報伝送単位でデータを一時蓄積可能なメモリ手段
   を備え、上記受信データから情報伝送単位でデータの抽
   出を行って上記メモリ手段に蓄積させ、このメモリ手段
   に保持されたシーンデータとしての情報伝送単位につい
   て、シーンデータ格納用のシーンデータ格納手段に対し
   て伝送して格納させるシーンデータ取込手段と、 上記シーンデータ格納手段に格納されているシーンデー
   タのうちから、所要のシーンデータを利用してシーン出
   力を行うことのできるシーン出力手段と、 上記受信手段により受信された送信情報からシーンの優
   先順位を示すシーン優先順位情報を獲得する情報獲得手
   段と、 上記情報獲得手段により得られたシーン優先順位情報に
   基づいて、受信データから抽出してメモリ手段に蓄積さ
   せるべきシーンデータとしての情報伝送単位を選択する
   ように上記シーンデータ取込手段に対して制御を行う制
   御手段と、 を備えていることを特徴とする受信装置。
2. 【請求項２】 上記制御手段は、 上記シーン出力手段により出力されているシーンに応じ
   て変更されるシーンの優先順位を上記シーン優先順位情
   報に基づいて判別し、 この判別されたシーン優先順位に従って上記シーンデー
   タ格納手段に格納されるシーンデータが得られるように
   して、受信データから抽出してメモリ手段に蓄積させる
   べきシーンデータとしての情報伝送単位が選択されるよ
   うに上記シーンデータ取込手段に対して制御を行うこと
   を特徴とする請求項１に記載の受信装置。