(57)【特許請求の範囲】
【請求項１】
放送としてＤＳＭ−ＣＣ方式のもとでカルーセル方式によりＭＨＥＧ方式により記述されて送信されてくるもので、１以上のモジュールを形成するデータ部分を含むＤＤＢメッセージと、モジュールごとに対応するＤＩＩメッセージを有するカルーセルのデータを受信する受信手段と、
上記受信手段により受信したＤＤＢメッセージから取得したモジュールを形成するデータを再構築してＭＨＥＧ方式のデータとして保持する受信データ保持手段と、
上記受信データ保持手段により保持されているＭＨＥＧ方式のデータを利用してデコード処理を実行するもので、モジュールについてのバージョンの切り換わりの通知に応じて、上記受信データ保持手段により保持されているデータのうちから、変更されたデータを取得するデータデコード手段と、
上記受信手段により受信した上記ＤＩＩメッセージにおけるバージョン情報に基づいて、このＤＩＩメッセージが対応するモジュールについてのバージョンの切り換わりを検出したことに応じて、上記受信データ保持手段から上記データデコード手段に対して、上記モジュールについてのバージョンの切り換わりを通知するための処理を、上記データデコード手段が上記受信データ保持手段にて保持されている上記データにアクセスするためのＵ−Ｕ  ＡＰＩ規格のインターフェイス規格のもとで実行する通知制御手段と、
を備え、
上記通知制御手段は、
ＤＩＩメッセージ変更イベントの受け取りを宣言するサブスクライブイベントを、上記データデコード手段から上記受信データ保持手段に対して伝達するサブスクライブイベント伝達処理と、
上記サブスクライブイベントの伝達後において、上記サブスクライブイベントに設定したイベント番号を上記受信データ保持手段から上記データデコード手段に伝達するイベント番号伝達処理と、
上記イベント番号の伝達後において、上記データデコード手段が関心のあるデータを示すデータＩＤを、上記データデコード手段から上記受信データ保持手段に伝達させ、次に、この伝達させたデータＩＤが示すデータが属するモジュールを示すモジュールＩＤを、上記受信データ保持手段から上記データデコード手段に伝達する、データＩＤ／モジュールＩＤ伝達処理と、
上記データＩＤ／モジュールＩＤ伝達処理による、データＩＤとモジュールＩＤの伝達後において、イベントの発生の通知を要求するイベント発生通知要求を、上記データデコード手段から上記受信データ保持手段に対して伝達するイベント発生通知要求伝達処理と、
上記イベント発生通知要求に対する応答として、上記受信手段により受信したデータにおける上記ＤＩＩメッセージが格納するもので、対応するモジュールにおけるデータの更新が反映されるモジュールのバージョン情報について変更が生じた場合に、上記イベント番号伝達処理により伝達させたのと同じ上記イベント番号による上記ＤＩＩメッセージ変更イベントを、上記受信データ保持手段から上記データデコード手段に対して伝達する、ＤＩＩメッセージ変更イベント伝達処理とを実行するようにされている、
放送受信装置。
【請求項２】
放送としてＤＳＭ−ＣＣ方式のもとでカルーセル方式によりＭＨＥＧ方式により記述されて送信されてくるもので、１以上のモジュールを形成するデータ部分を含むＤＤＢメッセージと、モジュールごとに対応するＤＩＩメッセージを有するカルーセルのデータを受信する受信手段と、
上記受信手段により受信したＤＤＢメッセージから取得したモジュールを形成するデータを再構築してＭＨＥＧ方式のデータとして保持する受信データ保持手段と、
上記受信データ保持手段により保持されているＭＨＥＧ方式のデータを利用してデコード処理を実行するもので、モジュールについてのバージョンの切り換わりの通知に応じて、上記受信データ保持手段により保持されているデータのうちから、変更されたデータを取得するデータデコード手段と、
上記受信手段により受信した上記ＤＩＩメッセージにおけるバージョン情報に基づいて、このＤＩＩメッセージが対応するモジュールについてのバージョンの切り換わりを検出したことに応じて、上記受信データ保持手段から上記データデコード手段に対して、上記モジュールについてのバージョンの切り換わりを通知するための処理を、上記データデコード手段が上記受信データ保持手段にて保持されている上記データにアクセスするためのＵ−Ｕ  ＡＰＩ規格のインターフェイス規格のもとで実行する通知制御手段と、
を備え、
上記通知制御手段は、
関心のあるデータのデータＩＤとともに、このデータＩＤが示すデータを格納するモジュールについてのモジュール更新イベントの受け取りを宣言するためのサブスクライブイベントを、データデコード手段から受信データ保持手段に対して伝達する、サブスクライブイベント伝達処理と、
上記受信データ保持手段での上記サブスクライブイベントの受け取りに応じて、この受け取ったサブスクライブイベントに対応するモジュール更新イベントＩＤを設定するモジュール更新イベントＩＤ設定処理と、
上記インターフェイス規格のもとで、上記モジュール更新イベントＩＤ設定手段が設定したモジュール更新イベントＩＤを、上記受信データ保持手段から上記データデコード手段に対して伝達するモジュール更新イベントＩＤ伝達処理と、
上記データデコード手段での上記モジュール更新イベントＩＤの受け取りに応じて、この受け取ったモジュール更新イベントＩＤと、上記サブスクライブイベント伝達処理により上記データデコード手段から伝達したデータＩＤとを対応付けたテーブル情報を生成するテーブル情報生成処理と、
上記インターフェイス規格のもとで、モジュール更新イベントの発生通知を要求するイベント発生通知要求を、上記データデコード手段から上記受信データ保持手段に対して伝達するイベント発生通知要求伝達処理と、
上記イベント発生通知要求に対する応答として、上記受信手段により受信したデータにおける上記ＤＩＩメッセージが格納するもので、対応するモジュールにおけるデータの更新が反映されるバージョン情報について変更が生じた場合に、このバージョン情報について変更が生じたとされるモジュールに対応して設定されているモジュール更新イベントＩＤを付加した上記モジュール更新イベントの発生通知を、上記受信データ保持手段から上記データデコード手段に対して伝達するイベント発生通知伝達処理と、
上記データデコード手段での上記モジュール更新イベントの発生通知の受け取りに応じて、上記テーブル情報から、この受け取ったモジュール更新イベントに対応付けられたデータＩＤを識別し、この識別したデータＩＤが示すデータを、更新されたデータとして特定する更新データ特定処理とを実行する、
放送受信装置。
【請求項３】
上記通知制御手段は、
上記データＩＤ／モジュールＩＤ伝達処理により伝達されたデータＩＤとモジュールＩＤとを対応付けたテーブル情報を生成するテーブル情報生成処理をさらに実行し、
上記ＤＩＩメッセージ変更イベント伝達処理は、上記ＤＩＩメッセージ変更イベントに、上記バージョン情報について変更が生じていたモジュールを示すモジュールＩＤを付加して伝達するとともに、
上記データデコード手段にて受け取ったＤＩＩメッセージ変更イベントに付加されていたモジュールＩＤに対応付けられたデータＩＤを、上記テーブル情報から検索する検索処理とを実行する、
請求項１に記載の放送受信装置。
【請求項４】
上記サブスクライブイベント伝達処理による上記サブスクライブイベントの伝達は、上記データデコード手段としての機能を実現するために放送受信装置が実行するプログラムの立ち上げに応じて実行される、
請求項１又は請求項２に記載の放送受信装置。
【請求項５】
上記サブスクライブイベント伝達処理による上記サブスクライブイベントの伝達は、地上局側でデータ内容自体が変更された上記カルーセルのデータが上記受信手段により受信されたことに応じて実行される、
請求項１又は請求項２に記載の放送受信装置。
【請求項６】
上記イベント発生通知要求伝達処理は、
一旦、上記イベント発生通知要求を伝達した後において、このイベント発生通知要求に応答したイベント発生通知が行われた場合には、直ちに次のイベント発生通知要求を伝達する、
請求項１又は請求項２に記載の放送受信装置。
【請求項７】
放送としてＤＳＭ−ＣＣ方式のもとでカルーセル方式によりＭＨＥＧ方式により記述されて送信されてくるもので、１以上のモジュールを形成するデータ部分を含むＤＤＢメッセージと、モジュールごとに対応するＤＩＩメッセージを有するカルーセルのデータを受信する受信手順と、
上記受信手順により受信したＤＤＢメッセージから取得したモジュールを形成するデータを再構築してＭＨＥＧ方式のデータとして保持する受信データ保持手順と、
上記受信データ保持手順により保持されているＭＨＥＧ方式のデータを利用してデコード処理を実行するもので、モジュールについてのバージョンの切り換わりの通知に応じて、上記受信データ保持手順により保持されているデータのうちから、変更されたデータを取得するデータデコード手順と、
上記受信手順により受信した上記ＤＩＩメッセージにおけるバージョン情報に基づいて、このＤＩＩメッセージが対応するモジュールについてのバージョンの切り換わりを検出したことに応じて、上記受信データ保持手順から上記データデコード手順に対して、上記モジュールについてのバージョンの切り換わりを通知するための処理を、上記データデコード手順が上記受信データ保持手順にて保持されている上記データにアクセスするためのＵ−Ｕ  ＡＰＩ規格のインターフェイス規格のもとで実行する通知制御手順と、
を実行し、
上記通知制御手順は、
ＤＩＩメッセージ変更イベントの受け取りを宣言するサブスクライブイベントを、上記データデコード手順から上記受信データ保持手順に対して伝達するサブスクライブイベント伝達処理と、
上記サブスクライブイベントの伝達後において、上記サブスクライブイベントに設定したイベント番号を上記受信データ保持手順から上記データデコード手順に伝達するイベント番号伝達処理と、
上記イベント番号の伝達後において、上記データデコード手順が関心のあるデータを示すデータＩＤを、上記データデコード手順から上記受信データ保持手順に伝達させ、次に、この伝達させたデータＩＤが示すデータが属するモジュールを示すモジュールＩＤを、上記受信データ保持手順から上記データデコード手順に伝達する、データＩＤ／モジュールＩＤ伝達処理と、
上記データＩＤ／モジュールＩＤ伝達処理による、データＩＤとモジュールＩＤの伝達後において、イベントの発生の通知を要求するイベント発生通知要求を、上記データデコード手順から上記受信データ保持手順に対して伝達するイベント発生通知要求伝達処理と、
上記イベント発生通知要求に対する応答として、上記受信手順により受信したデータにおける上記ＤＩＩメッセージが格納するもので、対応するモジュールにおけるデータの更新が反映されるモジュールのバージョン情報について変更が生じた場合に、上記イベント番号伝達処理により伝達させたのと同じ上記イベント番号による上記ＤＩＩメッセージ変更イベントを、上記受信データ保持手順から上記データデコード手順に対して伝達する、ＤＩＩメッセージ変更イベント伝達処理とを実行するようにされている、
放送受信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばデジタル衛星放送などにおいてデータサービスを受信するシステムに適用して好適なデータ伝達制御方法に関するものである。
【０００２】
【従来の技術】
近年、デジタル衛星放送の普及が進んでいる。デジタル衛星放送は、例えば既存のアナログ放送と比較してノイズやフェージングに強く、高品質の信号を伝送することが可能である。また、周波数利用効率が向上され、多チャンネル化も図ることが可能になる。具体的には、デジタル衛星放送であれば１つの衛星で数百チャンネルを確保することも可能である。このようなデジタル衛星放送では、スポーツ、映画、音楽、ニュースなどの専門チャンネルが多数用意されており、これらの専門チャンネルでは、それぞれの専門のコンテンツに応じたプログラムが放送されている。
【０００３】
そして、上記のようなデジタル衛星放送システムを利用して、ユーザが楽曲等の音声データをダウンロードできるようにしたり、いわゆるテレビショッピングとして、例えばユーザが放送画面を見ながら何らかの商品についての購買契約を結べるようにしたりすることが提案されている。つまりは、デジタル衛星放送システムとして、通常の放送内容と並行したデータサービス放送を行うものである。
【０００４】
一例として、楽曲データのダウンロードであれば、放送側においては、放送番組と並行して、楽曲データを多重化して放送するようにする。また、この楽曲データのダウンロードに際しては、ＧＵＩ(Graphical User Interface)画面（即ちダウンロード用の操作画面である）を表示させることでインタラクティブな操作をユーザに行わせるようにされるが、このＧＵＩ画面出力のためのデータも多重化して放送するようにされる。
そして、受信装置を所有しているユーザ側では、所望のチャンネルを選局している状態で、受信装置に対する所定の操作によって楽曲データをダウンロードするためのＧＵＩ画面を表示出力させるようにする。そして、この表示された操作画面に対してユーザが操作を行うことで、例えば受信装置に接続したデジタルオーディオ機器に対してデータを供給し、これが録音されるようにするものである。
【０００５】
ところで、上記のような楽曲データをダウンロードするためのＧＵＩ画面としては、例えばＧＵＩ画面を形成するパーツ的な画像データ、テキストデータなどの情報に加え、更には所定操作に応じた音声出力のための音声データなどの単位データ（ファイル）をそれぞれオブジェクトとして扱い、このオブジェクトの出力態様を所定方式によるシナリオ記述によって規定することによって、上記操作画面についての所要の表示形態及び音声等の出力態様を実現するように構成することが考えられる。
なお、ここでは、上記ＧＵＩ画面のようにして、記述情報によって規定されることで、或る目的に従った機能を実現する表示画面（ここでは音声等の出力も含む）のことを「シーン」というものとする。また、「オブジェクト」とは、記述情報に基づいてその出力態様が規定される画像、音声、テキスト等の単位情報を示しており、伝送時においては、ここでは記述情報自体のデータファイルも「オブジェクト」の１つとして扱われるものとする。
【０００６】
上記シーン表示及びシーン表示上での音声出力等を実現するためのオブジェクトは、例えば所定の伝送方式に従ってエンコードされて送信される。
受信装置側では上記伝送方式に従ってデータを受信すると共に、この受信データについてデコード処理を施して、例えば表示に必要なシーンに必要とされるオブジェクトごとの纏まりとしてのデータを得て、これをシーンとして出力するようにされる。
【０００７】
【発明が解決しようとする課題】
ここで、受信装置を所有するユーザの使用環境を考慮すれば、上記所定の伝送方式に則った上で、受信装置にて受信したデータサービス用のデータの処理については出来るだけ効率的な処理が行われるようにして、例えば表示出力されるべきシーン内容の更新なども、できるだけ軽い処理で迅速に対応できるようにすることが好ましい。
【０００８】
【課題を解決するための処理】
そこで、本発明は上記した課題を考慮して、放送受信装置として、次のように構成することとした。
つまり、放送としてＤＳＭ−ＣＣ方式のもとでカルーセル方式によりＭＨＥＧ方式により記述されて送信されてくるもので、１以上のモジュールを形成するデータ部分を含むＤＤＢメッセージと、モジュールごとに対応するＤＩＩメッセージを有するカルーセルのデータを受信する受信手段と、上記受信手段により受信したＤＤＢメッセージから取得したモジュールを形成するデータを再構築してＭＨＥＧ方式のデータとして保持する受信データ保持手段と、上記受信データ保持手段により保持されているＭＨＥＧ方式のデータを利用してデコード処理を実行するもので、モジュールについてのバージョンの切り換わりの通知に応じて、上記受信データ保持手段により保持されているデータのうちから、変更されたデータを取得するデータデコード手段と、上記受信手段により受信した上記ＤＩＩメッセージにおけるバージョン情報に基づいて、このＤＩＩメッセージが対応するモジュールについてのバージョンの切り換わりを検出したことに応じて、上記受信データ保持手段から上記データデコード手段に対して、上記モジュールについてのバージョンの切り換わりを通知するための処理を、上記データデコード手段が上記受信データ保持手段にて保持されている上記データにアクセスするためのＵ−Ｕ  ＡＰＩ規格のインターフェイス規格のもとで実行する通知制御手段と、を備え、上記通知制御手段は、ＤＩＩメッセージ変更イベントの受け取りを宣言するサブスクライブイベントを、上記データデコード手段から上記受信データ保持手段に対して伝達するサブスクライブイベント伝達処理と、上記サブスクライブイベントの伝達後において、上記サブスクライブイベントに設定したイベント番号を上記受信データ保持手段から上記データデコード手段に伝達するイベント番号伝達処理と、上記イベント番号の伝達後において、上記データデコード手段が関心のあるデータを示すデータＩＤを、上記データデコード手段から上記受信データ保持手段に伝達させ、次に、この伝達させたデータＩＤが示すデータが属するモジュールを示すモジュールＩＤを、上記受信データ保持手段から上記データデコード手段に伝達する、データＩＤ／モジュールＩＤ伝達処理と、上記データＩＤ／モジュールＩＤ伝達処理による、データＩＤとモジュールＩＤの伝達後において、イベントの発生の通知を要求するイベント発生通知要求を、上記データデコード手段から上記受信データ保持手段に対して伝達するイベント発生通知要求伝達処理と、上記イベント発生通知要求に対する応答として、上記受信手段により受信したデータにおける上記ＤＩＩメッセージが格納するもので、対応するモジュールにおけるデータの更新が反映されるモジュールのバージョン情報について変更が生じた場合に、上記イベント番号伝達処理により伝達させたのと同じ上記イベント番号による上記ＤＩＩメッセージ変更イベントを、上記受信データ保持手段から上記データデコード手段に対して伝達する、ＤＩＩメッセージ変更イベント伝達処理とを実行するようにされていることとした。
【０００９】
上記構成によれば、少なくとも、カルーセルを形成するデータについて、何らかのデータ、若しくは特定のデータの更新されたことをデータデコード手段が知ることが可能となり、データデコード手段では、これに基づいた所要の対応処理を実行することが可能になる。
【００１０】
【発明の実施の形態】
以降、本発明の実施の形態について説明する。
本発明が適用されるシステムとしては、デジタル衛星放送を利用して番組を放送すると共に、受信装置側ではこの番組に関連した楽曲データ（音声データ）等の情報をダウンロードできるようにしたシステムを例に挙げることとする。
【００１１】
なお、以降の説明は次の順序で行うこととする。
１．デジタル衛星放送システム
１−１．全体構成
１−２．ＧＵＩ画面に対する操作
１−３．地上局
１−４．送信フォーマット
１−５．ＩＲＤ
２．本発明に至った背景
３．本実施の形態のオブジェクト更新通知制御
３−１．Ｕ−Ｕ  ＡＰＩの一般的処理
３−２．第１例
３−３．第２例
３−４．第３例
【００１２】
１．デジタル衛星放送システムの構成
１−１．全体構成
図１は、本実施の形態としてのデジタル衛星放送システムの全体構成を示すものである。この図に示すように、デジタル衛星放送の地上局１には、テレビ番組素材サーバ６からのテレビ番組放送のための素材と、楽曲素材サーバ７からの楽曲データの素材と、音声付加情報サーバ８からの音声付加情報と、ＧＵＩデータサーバからのＧＵＩデータとが送られる。
【００１３】
テレビ番組素材サーバ６は、通常の放送番組の素材を提供するサーバである。このテレビ番組素材サーバから送られてくる音楽放送の素材は、動画及び音声とされる。例えば、音楽放送番組であれば、上記テレビ番組素材サーバ６の動画及び音声の素材を利用して、例えば新曲のプロモーション用の動画及び音声が放送されたりすることになる。
【００１４】
楽曲素材サーバ７は、オーディオチャンネルを使用して、オーディオ番組を提供するサーバである。このオーディオ番組の素材は音声のみとなる。この楽曲素材サーバ７は、複数のオーディオチャンネルのオーディオ番組の素材を地上局１に伝送する。
各オーディオチャンネルの番組放送ではそれぞれ同一の楽曲が所定の単位時間繰り返して放送される。各オーディオチャンネルは、それぞれ独立しており、その利用方法としては各種考えられる。例えば、１つのオーディオチャンネルでは最新の日本のポップスの数曲を或る一定時間繰り返し放送し、他のオーディオチャンネルでは最新の外国のポップスの数曲を或る一定時間繰り返し放送するというようにされる。
【００１５】
音声付加情報サーバ８は、楽曲素材サーバ７から出力される楽曲の時間情報等を提供するサーバである。
【００１６】
ＧＵＩデータサーバ９は、ユーザが操作に用いるＧＵＩ画面を形成するための「ＧＵＩデータ」を提供する。例えば後述するような楽曲のダウンロードに関するＧＵＩ画面であれば、配信される楽曲のリストページや各楽曲の情報ページを形成するための画像データ、テキストデータ、アルバムジャケットの静止画を形成するためのデータなどを提供する。更には、受信設備３側にていわゆるＥＰＧ(Electrical Program Guide)といわれる番組表表示を行うのに利用されるＥＰＧデータもここから提供される。
なお、「ＧＵＩデータ」としては、例えばＭＨＥＧ(Multimedia Hypermedia Information Coding Experts Group)方式が採用される。ＭＨＥＧとは、マルチメディア情報、手順、操作などのそれぞれと、その組み合わせをオブジェクトとして捉え、それらのオブジェクトを符号化したうえで、タイトル（例えばＧＵＩ画面）として制作するためのシナリオ記述の国際標準とされる。また、本実施の形態ではＭＨＥＧ−５を採用するものとする。
【００１７】
地上局１は上記テレビ番組素材サーバ６、楽曲素材サーバ７、音声付加情報サーバ８、及びＧＵＩデータサーバ９から伝送された情報を多重化して送信する。
本実施の形態では、テレビ番組素材サーバ６から伝送されたビデオデータはＭＰＥＧ(Moving Picture Experts Group)２方式により圧縮符号化され、オーディオデータはＭＰＥＧ２オーディオ方式により圧縮符号化される。また、楽曲素材サーバ７から伝送されたオーディオデータは、オーディオチャンネルごとに対応して、例えばＭＰＥＧ２オーディオ方式と、ＡＴＲＡＣ(Adoptive Tranform Acoustic Coding)方式と何れか一方の方式により圧縮符号化される。
また、これらのデータは多重化の際、キー情報サーバ１０からのキー情報を利用して暗号化される。
なお、地上局１の内部構成例については後述する。
【００１８】
地上局１からの信号は衛星２を介して各家庭の受信設備３で受信される。衛星２には複数のトランスポンダが搭載されている。１つのトランスポンダは例えば３０Ｍｂｐｓの伝送能力を有している。各家庭の受信設備３としては、パラボラアンテナ１１とＩＲＤ(Integrated Receiver Decorder)１２と、ストレージデバイス１３と、モニタ装置１４とが用意される。
また、この場合には、ＩＲＤ１２に対して操作を行うためのリモートコントローラ６４が示されている。
【００１９】
パラボラアンテナ１１で衛星２を介して放送されてきた信号が受信される。この受信信号がパラボラアンテナ１１に取り付けられたＬＮＢ(Low Noize Block Down Converter)１５で所定の周波数に変換され、ＩＲＤ１２に供給される。
【００２０】
ＩＲＤ１２における概略的な動作としては、受信信号から所定のチャンネルの信号を選局し、その選局された信号から番組としてのビデオデータ及びオーディオデータの復調を行ってビデオ信号、オーディオ信号として出力する。また、ＩＲＤ１２では、番組としてのデータと共に多重化されて送信されてくる、ＧＵＩデータに基づいてＧＵＩ画面としての出力も行う。このようなＩＲＤ１２の出力は、例えばモニタ装置１４に対して供給される。これにより、モニタ装置１４では、ＩＲＤ１２により受信選局した番組の画像表示及び音声出力が行われ、また、後述するようなユーザの操作に従ってＧＵＩ画面を表示させることが可能となる。
【００２１】
ストレージデバイス１３は、ＩＲＤ１２によりダウンロードされたオーディオデータ（楽曲データ）を保存するためのものである。このストレージデバイス１３の種類としては特に限定されるものではなく、ＭＤ(Mini Disc)レコーダ／プレーヤ、ＤＡＴレコーダ／プレーヤ、ＤＶＤレコーダ／プレーヤ等を用いることができる。また、ストレージデバイス１３としてパーソナルコンピュータ装置を用い、ハードディスクのほか、ＣＤ−Ｒ等をはじめとする記録が可能なメディアにオーディオデータを保存するようにすることも可能とされる。
【００２２】
また、本実施の形態の受信設備３としては、図２に示すように、データ伝送規格としてＩＥＥＥ１３９４に対応したデータインターフェイスを備えたＭＤレコーダ／プレーヤ１３Ａを、図１に示すストレージデバイス１３として使用することができるようになっている。
この図に示すＩＥＥＥ１３９４対応のＭＤレコーダ／プレーヤ１３Ａは、ＩＥＥＥ１３９４バス１６によりＩＲＤ１２と接続される。これによって、本実施の形態では、ＩＲＤ１２にて受信された、楽曲としてのオーディオデータ（ダウンロードデータ）を、ＡＴＲＡＣ方式により圧縮処理が施されたままの状態で直接取り込んで記録することができる。また、ＭＤレコーダ／プレーヤ１３ＡとＩＲＤ１２とをＩＥＥＥ１３９４バス１６により接続した場合には、上記オーディオデータの他、そのアルバムのジャケットデータ（静止画データ）及び歌詞などのテキストデータを記録することも可能とされている。
【００２３】
ＩＲＤ１２は、例えば電話回線４を介して課金サーバ５と通信可能とされている。ＩＲＤ１２には、後述するようにして各種情報が記憶されるＩＣカードが挿入される。例えば楽曲のオーディオデータのダウンロードが行われたとすると、これに関する履歴情報がＩＣカードに記憶される。このＩＣカードの情報は、電話回線４を介して所定の機会、タイミングで課金サーバ５に送られる。課金サーバ５は、この送られてきた履歴情報に従って金額を設定して課金を行い、ユーザに請求する。
【００２４】
これまでの説明から分かるように、本発明が適用されたシステムでは、地上局１は、テレビ番組素材サーバ６からの音楽番組放送の素材となるビデオデータ及びオーディオデータと、楽曲素材サーバ７からのオーディオチャンネルの素材となるオーディオデータと、音声付加情報サーバ８からの音声データと、ＧＵＩデータサーバ９からのＧＵＩデータとを多重化して送信している。
そして、各家庭の受信設備３でこの放送を受信すると、例えばモニタ装置１４により、選局したチャンネルの番組を視聴することができる。また、番組のデータと共に送信されるＧＵＩデータを利用したＧＵＩ画面として、第１にはＥＰＧ（Electrical Program Guide；電子番組ガイド）画面を表示させ、番組の検索等を行うことができる。また、第２には、例えば通常の番組放送以外の特定のサービス用のＧＵＩ画面を利用して所要の操作を行うことで、本実施の形態の場合には、放送システムにおいて提供されている通常番組の視聴以外のサービスを享受することができる。
例えば、オーディオ（楽曲）データのダウンロードサービス用のＧＵＩ画面を表示させて、このＧＵＩ画面を利用して操作を行えば、ユーザが希望した楽曲のオーディオデータをダウンロードしてストレージデバイス１３に記録して保存することが可能になる。
【００２５】
なお、本実施の形態では、上記したようなＧＵＩ画面に対する操作を伴う、通常の番組放送以外の特定のサービスを提供するデータサービス放送については、インタラクティブ性を有することもあり、「インタラクティブ放送」ともいうことにする。
【００２６】
１−２．ＧＵＩ画面に対する操作
ここで、上述しているインタラクティブ放送の利用例、つまり、ＧＵＩ画面に対する操作例について、図３及び図４を参照して概略的に説明しておく。ここでは、楽曲データ（オーディオデータ）のダウンロードを行う場合について述べる。
【００２７】
先ず、図３によりＩＲＤ１２に対してユーザが操作を行うためのリモートコントローラ６４の操作キーについて、特に主要なものについて説明しておく。
図３には、リモートコントローラ６４において各種キーが配列された操作パネル面が示されている。ここでは、これら各種キーのうち、電源キー１０１、数字キー１０２、画面表示切換キー１０３、インタラクティブ切換キー１０４、ＥＰＧキーパネル部１０５、チャンネルキー１０６について説明する。
【００２８】
電源キー１０１は、ＩＲＤ１２の電源のオン／オフを行うためのキーである。数字キー１０２は、数字指定によりチャンネル切り換えを行ったり、例えばＧＵＩ画面において数値入力操作が必要な場合に操作するためのキーである。
画面表示切換キー１０３は、例えば通常の放送画面とＥＰＧ画面との切り換えを行うキーである。例えば、画面表示切換キー１０３によりＥＰＧ画面を呼び出した状態の下で、ＥＰＧキーパネル部１０５に配置されたキーを操作すれば、電子番組ガイドの表示画面を利用した番組検索が行えることになる。また、ＥＰＧキーパネル部１０５内の矢印キー１０５ａは、後述するサービス用のＧＵＩ画面におけるカーソル移動などにも使用することができる。
インタラクティブ切換キー１０４は、通常の放送画面と、その放送番組に付随したサービスのためのＧＵＩ画面との切り換えを行うために設けられる。
チャンネルキー１０６は、ＩＲＤ１２における選局チャンネルをそのチャンネル番号の昇順、降順に従って順次切り換えていくために設けられるキーである。
【００２９】
なお、本実施の形態のリモートコントローラ６４としては、例えばモニタ装置１４に対する各種操作も可能に構成されているものとされ、これに対応した各種キーも設けられているものであるが、ここでは、モニタ装置１４に対応するキー等の説明は省略する。
【００３０】
次に、図４を参照してＧＵＩ画面に対する操作の具体例について説明する。
受信設備３により放送を受信して所望のチャンネルを選局すると、モニタ装置１４の表示画面には、図４（ａ）に示すように、テレビ番組素材サーバ６から提供された番組素材に基づく動画像が表示される。つまり、通常の番組内容が表示される。ここでは、例えば音楽番組が表示されているものとする。また、この音楽番組には楽曲のオーディオデータのダウンロードサービス（インタラクティブ放送）が付随されているものとする。
そして、この音楽番組が表示されている状態の下で、例えばユーザがリモートコントローラ６４のインタラクティブ切換キー１０４を操作したとすると、表示画面は図４（ｂ）に示すような、オーディオデータのダウンロードのためのＧＵＩ画面に切り替わる。
【００３１】
このＧＵＩ画面においては、先ず、画面の左上部のテレビ番組表示エリア２１Ａに対して、図４（ａ）にて表示されていたテレビ番組素材サーバ６からのビデオデータによる画像が縮小化されて表示される。
また、画面の右上部には、オーディオチャンネルで放送されている各チャンネルの楽曲のリスト２１Ｂが表示される。また、画面の左下にはテキスト表示エリア２１Ｃとジャケット表示エリア２１Ｄが表示される。さらに、画面の右側には歌詞表示ボタン２２、プロフィール表示ボタン２３、情報表示ボタン２４、予約録音ボタン２５、予約済一覧表示ボタン２６、録音履歴表示ボタン２７、およびダウンロードボタン２８が表示される。
【００３２】
ユーザは、このリスト２１Ｂに表示されている楽曲名を見ながら、興味のある楽曲を探していく。そして、興味のある楽曲を見つけたらリモートコントローラ６４の矢印キー１０５ａ（ＥＰＧキーパネル部１０５内）を操作して、その楽曲が表示されている位置にカーソルを合わせた後、エンター操作を行う（例えば矢印キー１０５ａのセンター位置を押圧操作する）。
これによって、カーソルを合わせた楽曲を試聴することができる。すなわち、各オーディオチャンネルでは、所定の単位時間中、同一の楽曲が繰り返し放送されているので、テレビ番組表示エリア２１Ａの画面はそのままで、ＩＲＤ１２により上記操作により選択された楽曲のオーディオチャンネルに切り換えて音声出力することで、その楽曲を聞くことができる。この時、ジャケット表示エリア２１Ｄにはその楽曲のＭＤジャケットの静止画像が表示される
【００３３】
また、例えば上記の状態で歌詞表示ボタン２２にカーソルを合わせ、エンター操作を行う（以下、ボタン表示にカーソルを合わせ、エンター操作を行うことを「ボタンを押す」という）と、テキスト表示エリア２１Ｃに楽曲の歌詞がオーディオデータと同期したタイミングで表示される。同様に、プロフィール表示ボタン２３あるいは情報表示ボタン２４を押すと、楽曲に対応するアーティストのプロフィールあるいはコンサート情報などがテキスト表示エリア２１Ｃに表示される。このように、ユーザは、現在どのような楽曲が配信されているのかを知ることができ、更に各楽曲についての詳細な情報を知ることができる。
【００３４】
ユーザは試聴した楽曲を購入したい場合には、ダウンロードボタン２８を押す。ダウンロードボタン２８が押されると、選択された楽曲のオーディオデータがダウンロードされ、ストレージデバイス１３に記憶される。楽曲のオーディオデータと共に、その歌詞データ、アーティストのプロフィール情報、ジャケットの静止画データ等をダウンロードすることもできる。
そして、このようにして楽曲のオーディオデータがダウンロードされる毎に、その履歴情報がＩＲＤ１２内のＩＣカードに記憶される。ＩＣカードに記憶された情報は、例えば１カ月に一度ずつ課金サーバ５により取り込みが行われ、ユーザに対してデータサービスの使用履歴に応じた課金が行われる。これによって、ダウンロードされる楽曲の著作権を保護することができることにもなる。
【００３５】
また、ユーザは予めダウンロードの予約を行いたい場合には、予約録音ボタン２５を押す。このボタンを押すと、ＧＵＩ画面の表示が切り換わり、予約が可能な楽曲のリストが画面全体に表示される。例えばこのリストは１時間単位、１週間単位、チャンル単位等で検索した楽曲を表示することが可能である。ユーザはこのリストの中からダウンロードの予約を行いたい楽曲を選択すると、その情報がＩＲＤ１２内に登録される。そして、すでにダウンロードの予約を行った楽曲を碓認したい場合には、予約済一覧表示ボタン２６を押すことにより、画面全体に表示させることができる。このようにして予約された楽曲は、予約時刻になるとＩＲＤ１２によりダウンロードされ、ストレージデバイス１３に記憶される。
【００３６】
ユーザはダウンロードを行った楽曲について確認したい場合には、録音履歴ボタン２７を押すことにより、既にダウンロードを行った楽曲のリストを画面全体に表示させることができる。
【００３７】
このように、本発明が適用されたシステムの受信設備３では、モニタ装置１４のＧＵＩ画面上に楽曲のリストが表示される。そして、このＧＵＩ画面上の表示にしたがって楽曲を選択するとその楽曲を試聴することができ、その楽曲の歌詞やアーティストのプロフィール等を知ることができる。さらに、楽曲のダウンロードとその予約、ダウンロードの履歴や予約済楽曲リストの表示等を行うことができる。
【００３８】
詳しいことは後述するが、上記図４（ｂ）に示すようなＧＵＩ画面の表示と、ＧＵＩ画面に対するユーザの操作に応答したＧＵＩ画面上での表示変更、及び音声出力は、前述したＭＨＥＧ方式に基づいたシナリオ記述により、オブジェクトの関係を規定することにより実現される。ここでいうオブジェクトとは、図４（ｂ）に示された各ボタンに対応するパーツとしての画像データや各表示エリアに表示される素材データとなる。
そして、本明細書においては、このＧＵＩ画面のような、シナリオ記述によってオブジェクト間の関係が規定されることで、或る目的に従った情報の出力態様（画像表示や音声出力等）が実現される環境を「シーン」というものとする。また、１シーンを形成するオブジェクトとしては、シナリオ記述のファイル自体も含まれるものとする。
【００３９】
以上、説明したように、本発明が適用されたデジタル衛星放送システムでは放送番組が配信されると共に、複数のオーディオチャンネルを使用して楽曲のオーディオデータが配信される。そして、配信されている楽曲のリスト等を使用して所望の楽曲を探し、そのオーディオデータをストレージデバイス１３に簡単に保存することができる。
なお、デジタル衛星放送システムにおける番組提供以外のサービスとしては、上記した楽曲データのダウンロードの他にも各種考えられる。例えば、いわゆるテレビショッピングといわれる商品紹介番組を放送した上で、ＧＵＩ画面としては購買契約が結べるようなものを用意することも考えられる。
【００４０】
１−３．地上局
これまで、本実施の形態としてのデジタル衛星放送システムの概要について説明したが、以降、このシステムについてより詳しい説明を行っていくこととする。そこで、先ず地上局１の構成について図５を参照して説明する。
【００４１】
なお、以降の説明にあたっては、次のことを前提とする。
本実施の形態では、地上局１から衛星２を介しての受信設備３への送信を行うのにあたり、ＤＳＭ−ＣＣ(デジタル蓄積メディア・コマンド・アンド・コントロール；Digital Strage Media-Command and Control)プロトコルを採用する。
ＤＳＭ−ＣＣ（ＭＰＥＧ−ｐａｒｔ６）方式は、既に知られているように、例えば、何らかのネットワークを介して、デジタル蓄積メディア（ＤＳＭ）に蓄積されたＭＰＥＧ符号化ビットストリームを取り出し(Retrieve)たり、或いはＤＳＭに対してストリームを蓄積(Store)するためのコマンドや制御方式を規定したものである。そして本実施の形態においては、このＤＳＭ−ＣＣ方式がデジタル衛星放送システムにおける伝送規格として採用されているものである。
そして、ＤＳＭ−ＣＣ方式によりデータ放送サービス（例えばＧＵＩ画面など）のコンテンツ（オブジェクトの集合）を伝送するためには、コンテンツの記述形式を定義しておく必要がある。本実施の形態では、この記述形式の定義として先に述べたＭＨＥＧが採用されるものである。
【００４２】
図５に示す地上局１の構成において、テレビ番組素材登録システム３１は、テレビ番組素材サーバ６から得られた素材データをＡＶサーバ３５に登録する。この素材データはテレビ番組送出システム３９に送られ、ここでビデオデータは例えばＭＰＥＧ２方式で圧縮され、オーディオデータは、例えばＭＰＥＧ２オーディオ方式によりパケット化される。テレビ番組送出システム３９の出力はマルチプレクサ４５に送られる。
【００４３】
また、楽曲素材登録システム３２では、楽曲素材サーバ７からの素材データ、つまりオーディオデータを、ＭＰＥＧ２オーディオエンコーダ３６Ａ、及びＡＴＲＡＣエンコーダ３６Ｂに供給する。ＭＰＥＧ２オーディオエンコーダ３６Ａ、ＡＴＲＡＣエンコーダ３６Ｂでは、それぞれ供給されたオーディオデータについてエンコード処理（圧縮符号化）を行った後、ＭＰＥＧオーディオサーバ４０Ａ及びＡＴＲＡＣオーディオサーバ４０Ｂに登録させる。
ＭＰＥＧオーディオサーバ４０Ａに登録されたＭＰＥＧオーディオデータは、ＭＰＥＧオーディオ送出システム４３Ａに伝送されてここでパケット化された後、マルチプレクサ４５に伝送される。ＡＴＲＡＣオーディオサーバ４０Ｂに登録されたＡＴＲＡＣデータは、ＡＴＲＡＣオーディオ送出システム４３Ｂに４倍速ＡＴＲＡＣデータとして送られ、ここでパケット化されてマルチプレクサ４５に送出される。
【００４４】
また、音声付加情報登録システム３３では、音声付加情報サーバ８からの素材データである音声付加情報を音声付加情報データベース３７に登録する。この音声付加情報データベース３７に登録された音声付加情報は、音声付加情報送出システム４１に伝送され、同様にして、ここでパケット化されてマルチプレクサ４５に伝送される。
【００４５】
また、ＧＵＩ用素材登録システム３４では、ＧＵＩデータサーバ９からの素材データであるＧＵＩデータを、ＧＵＩ素材データベース３８に登録する。
【００４６】
ＧＵＩ素材データベース３８に登録されたＧＵＩ素材データは、ＧＵＩオーサリングシステム４２に伝送され、ここで、ＧＵＩ画面、即ち図４にて述べた「シーン」としての出力が可能なデータ形式となるように処理が施される。
【００４７】
つまり、ＧＵＩオーサリングシステム４２に伝送されてくるデータとしては、例えば、楽曲のダウンロードのためのＧＵＩ画面であれば、アルバムジャケットの静止画像データ、歌詞などのテキストデータ、更には、操作に応じて出力されるべき音声データなどである。
上記した各データはいわゆるモノメディアといわれるが、ＧＵＩオーサリングシステム４２では、ＭＨＥＧオーサリングツールを用いて、これらのモノメディアデータを符号化して、これをオブジェクトとして扱うようにする。
そして、例えば図４（ｂ）にて説明したようなシーン（ＧＵＩ画面）の表示態様と操作に応じた画像音声の出力態様が得られるように上記オブジェクトの関係を規定したシナリオ記述ファイル（スクリプト）と共にＭＨＥＧ−５のコンテンツを作成する。
また、図４（ｂ）に示したようなＧＵＩ画面では、テレビ番組素材サーバ６の素材データを基とする画像・音声データ（ＭＰＥＧビデオデータ、ＭＰＥＧオーディオデータ）と、楽曲素材サーバ７の楽曲素材データを基とするＭＰＥＧオーディオデータ等も、ＧＵＩ画面に表示され、操作に応じた出力態様が与えられる。
従って、上記シナリオ記述ファイルとしては、上記ＧＵＩオーサリングシステム４２では、上記したテレビ番組素材サーバ６の素材データを基とする画像・音声データ、楽曲素材サーバ７の楽曲素材データを基とするＭＰＥＧオーディオデータ、更には、音声付加情報サーバ８を基とする音声付加情報も必要に応じてオブジェクトとして扱われて、ＭＨＥＧのスクリプトによる規定が行われる。
【００４８】
なお、ＧＵＩオーサリングシステム４２から伝送されるＭＨＥＧコンテンツのデータとしては、スクリプトファイル、及びオブジェクトとしての各種静止画データファイルやテキストデータファイルなどとなるが、静止画データは、例えばＪＰＥＧ(Joint Photograph Experts Group)方式で圧縮された６４０×４８０ピクセルのデータとされ、テキストデータは例えば８００文字以内のファイルとされる。
【００４９】
ＧＵＩオーサリングシステム４２にて得られたＭＨＥＧコンテンツのデータはＤＳＭ−ＣＣエンコーダ４４に伝送される。
ＤＳＭ−ＣＣエンコーダ４４では、ＭＰＥＧ２フォーマットに従ったビデオ、オーディオデータのデータストリームに多重できる形式のトランスポートストリーム（以下ＴＳ(Transport Stream)とも略す）に変換して、パケット化されてマルチプレクサ４５に出力される。
【００５０】
マルチプレクサ４５においては、テレビ番組送出システム３９からのビデオパケットおよびオーディオパケットと、ＭＰＥＧオーディオ送出システム４３Ａからのオーディオパケットと、ＡＴＲＡＣオーディオ送出システム４３Ｂからの４倍速オーディオパケットと、音声付加情報送出システム４１からの音声付加情報パケットと、ＧＵＩオーサリングシステム４２からのＧＵＩデータパケットとが時間軸多重化されると共に、キー情報サーバ１０（図１）から出力されたキー情報に基づいて暗号化される。
【００５１】
マルチプレクサ４５の出力は電波送出システム４６に伝送され、ここで例えば誤り訂正符号の付加、変調、及び周波数変換などの処理を施された後、アンテナから衛星２に向けて送信出力するようにされる。
【００５２】
１−４．送信フォーマット
次に、ＤＳＭ−ＣＣ方式に基づいて規定された本実施の形態の送信フォーマットについて説明する。
図６は、地上局１から衛星２に送信出力される際のデータの一例を示している。なお、前述したように、この図に示す各データは実際には時間軸多重化されているものである。また、この図では、図６に示すように、時刻ｔ１から時刻ｔ２の間が１つのイベントとされ、時刻ｔ２から次のイベントとされる。ここでいうイベントとは、例えば音楽番組のチャンネルであれば、複数楽曲のラインナップの組を変更する単位であり、時間的には３０分或いは１時間程度となる。
【００５３】
図６に示すように、時刻ｔ１から時刻ｔ２のイベントでは、通常の動画の番組放送で、所定の内容Ａ１を有する番組が放送されている。また、時刻ｔ２から始めるイベントでは、内容Ａ２としての番組が放送されている。この通常の番組で放送されているのは動画と音声である。
【００５４】
ＭＰＥＧオーディオチャンネル（１）〜（１０）は、例えば、チャンネルＣＨ１からＣＨ１０の１０チャンネル分用意される。このとき、各オーディオチャンネルＣＨ１，ＣＨ２，ＣＨ３・・・・ＣＨ１０では、１つのイベントが放送されている間は同一楽曲が繰り返し送信される。つまり、時刻ｔ１〜ｔ２のイベントの期間においては、オーディオチャンネルＣＨ１では楽曲Ｂ１が繰り返し送信され、オーディオチャンネルＣＨ２では楽曲Ｃ１が繰り返し送信され、以下同様に、オーディオチャンネルＣＨ１０では楽曲Ｋ１が繰り返し送信されることになる。これは、その下に示されている４倍速ＡＴＲＡＣオーディオチャンネル（１）〜（１０）についても共通である。
【００５５】
つまり、図６において、ＭＰＥＧオーディオチャンネルと４倍速ＡＴＲＡＣオーディオチャンネルのチャンネル番号である（  ）内の数字が同じものは同じ楽曲となる。また、音声付加情報のチャンネル番号である（  ）内の数字は、同じチャンネル番号を有するオーディオデータに付加されている音声付加情報である。更に、ＧＵＩデータとして伝送される静止画データやテキストデータも各チャンネルごとに形成されるものである。これらのデータは、図７（ａ）〜（ｄ）に示すようにＭＰＥＧ２のトランスポートパケット内で時分割多重されて送信され、図７（ｅ）〜（ｈ）に示すようにしてＩＲＤ１２内では各データパケットのヘッダ情報を用いて再構築される。
【００５６】
また、上記図６及び図７に示した送信データのうち、少なくとも、データサービス（インタラクティブ放送）に利用されるＧＵＩデータは、ＤＳＭ−ＣＣ方式に則って論理的には次のようにして形成されるものである。ここでは、ＤＳＭ−ＣＣエンコーダ４４から出力されるトランスポートストリームのデータに限定して説明する。
【００５７】
図８（ａ）に示すように、ＤＳＭ−ＣＣ方式によって伝送される本実施の形態のデータ放送サービスは、Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙという名称のルートディレクトリの中に全て含まれる。Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙに含まれるオブジェクトとしては、ディレクトリ（Ｄｉｒｅｃｔｏｒｙ），ファイル（Ｆｉｌｅ），ストリーム（Ｓｔｒｅａｍ），ストリームイベント（Ｓｔｒｅａｍ  Ｅｖｅｎｔ）などの種類が存在する。
【００５８】
これらのうち、ファイルは静止画像、音声、テキスト、更にはＭＨＥＧにより記述されたスクリプトなどの個々のデータファイルとされる。
ストリームは例えば、他のデータサービスやＡＶストリーム（ＴＶ番組素材としてのＭＰＥＧビデオデータ、オーディオデータ、楽曲素材としてのＭＰＥＧオーディオデータ、ＡＴＲＡＣオーディオデータ等）にリンクする情報が含まれる。
また、ストリームイベントは、同じくリンクの情報と時刻情報が含まれる。
ディレクトリは相互に関連するデータをまとめるフォルダである。
【００５９】
そして、ＤＳＭ−ＣＣ方式では、図８（ｂ）に示すようにして、これらの単位情報とＳｅｒｖｉｃｅ  Ｇａｔｅｗａｙをそれぞれオブジェクトという単位と捉え、それぞれをＢＩＯＰメッセージという形式に変換する。
なお、本発明に関わる説明では、ファイル，ストリーム，ストリームイベントの３つのオブジェクトの区別は本質的なものではないので、以下の説明ではこれらをファイルとしてのオブジェクトに代表させて説明する。
【００６０】
そして、ＤＳＭ−ＣＣ方式では、図８（ｃ）に示すモジュールといわれるデータ単位を生成する。このモジュールは、図８（ｂ）に示したＢＩＯＰメッセージ化されたオブジェクトを１つ以上含むようにされたうえで、ＢＩＯＰヘッダが付加されて形成される可変長のデータ単位であり、後述する受信側における受信データのバッファリング単位となる。
また、ＤＳＭ−ＣＣ方式としては、１モジュールを複数のオブジェクトにより形成する場合の、オブジェクト間の関係については特に規定、制限はされていない。つまり、極端なことをいえば、全く関係の無いシーン間における２以上のオブジェクトにより１モジュールを形成したとしても、ＤＳＭ−ＣＣ方式のもとでの規定に何ら違反するものではない。
【００６１】
このモジュールは、ＭＰＥＧ２フォーマットにより規定されるセクションといわれる形式で伝送するために、図８（ｄ）に示すように、機械的に「ブロック」といわれる原則固定長のデータ単位に分割される。但し、モジュールにおける最後のブロックについては規定の固定長である必要はないものとされている。このように、ブロック分割を行うのはＭＰＥＧ２フォーマットにおいて、１セクションが４ＫＢを越えてはならないという規定があることに起因する。
また、この場合には上記ブロックとしてのデータ単位と、セクションとは同義なものとなる。
【００６２】
このようにしてモジュールを分割して得たブロックは、図８（ｅ）に示すようにしてヘッダが付加されてＤＤＢ(Download Data Block)というメッセージの形式に変換される。
【００６３】
また、上記ＤＤＢへの変換と並行して、ＤＳＩ(Download Server Initiate)及びＤＩＩ(Download Indication Information)という制御メッセージが生成される。
上記ＤＳＩ及びＤＩＩは、受信側（ＩＲＤ１２）で受信データからモジュールを取得する際に必要となる情報であり、ＤＳＩは主として、次に説明するカルーセル（モジュール）の識別子、カルーセル全体に関連する情報（カルーセルが１回転する時間、カルーセル回転のタイムアウト値）等の情報を有する。また、データサービスのルートディレクトリ（Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ）の所在を知るための情報も有する（オブジェクトカルーセル方式の場合）。
【００６４】
ＤＩＩは、カルーセルに含まれるモジュールごとに対応する情報であり、モジュールごとのサイズ、バージョン、そのモジュールのタイムアウト値などの情報を有する。
【００６５】
そして、図８（ｆ）に示すように、上記ＤＤＢ、ＤＳＩ、ＤＩＩの３種類のメッセージをセクションのデータ単位に対応させて周期的に、かつ、繰り返し送出するようにされる。これにより、受信機側では例えば目的のＧＵＩ画面（シーン）を得るのに必要なオブジェクトが含まれているモジュールをいつでも受信できるようにされる。
本明細書では、このような伝送方式を回転木馬に例えて「カルーセル方式」といい、図８（ｆ）に示すようにして模式的に表されるデータ伝送形態をカルーセルというものとする。
ここで、１カルーセルに含まれるモジュールとしては複数とされて構わない。例えば、１カルーセルにより１つのデータサービスに必要な複数のモジュールを伝送するようにしてもよいものである。
また、「カルーセル方式」としては、「データカルーセル方式」のレベルと「オブジェクトカルーセル方式」のレベルとに分けられる。特にオブジェクトカルーセル方式では、ファイル、ディレクトリ、ストリーム、サービスゲートウェイなどの属性を持つオブジェクトをデータとしてカルーセルを用いて転送する方式で、ディレクトリ構造を扱えることがデータカルーセル方式と大きく異なる。本実施の形態のシステムでは、オブジェクトカルーセル方式を採用するものとされる。
【００６６】
また、図９に、ＭＨＥＧ方式に則ったデータサービスとしてのファイル（ＭＨＥＧ ａｐｐｌｉｃａｔｉｏｎ ｆｉｌｅ）のディレクトリ構造例を示す。上述のようにオブジェクトカルーセル方式は、このディレクトリ構造を扱えることに特徴を有する。
通常、Ｓｅｒｖｉｃｅ  Ｄｏｍａｉｎの入り口となる（ＭＨＥＧ ａｐｐｌｉｃａｔｉｏｎ ｆｉｌｅ）は、必ず、Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙの直下にある、ａｐｐ０／ｓｔａｒｔｕｐというファイルとなる。
基本的には、Ｓｅｒｖｉｃｅ  Ｄｏｍａｉｎ（Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ）の下にａｐｐｌｉｃａｔｉｏｎ  ｄｉｒｅｃｔｏｒｙ（ａｐｐ０，ａｐｐ１・・・ａｐｐＮ）があり、その下にｓｔａｒｔｕｐといわれるアプリケーション・ファイルと、ａｐｐｌｉｃａｔｉｏｎを構成する各ｓｃｅｎｅのｄｉｒｅｃｔｏｒｙ（ｓｃｅｎｅ０，ｓｃｅｎｅ１・・・）があるようにされる。更にｓｃｅｎｅ  ｄｉｒｅｃｔｏｒｙの下には、ＭＨＥＧ  ｓｃｅｎｅ  ｆｉｌｅとｓｃｅｎｅを構成する各ｃｏｎｔｅｎｔ  ｆｉｌｅがおかれることとしている。
【００６７】
また、上記のようにしてカルーセルにより送信されるＧＵＩデータ、つまり、図５のＤＳＭ−ＣＣエンコーダ４４から出力されるデータとしては、トランスポートストリームの形態により出力される。このトランスポートストリームは例えば図１０に示す構造を有する。
図１０（ａ）には、トランスポートストリームが示されている。このトランスポートストリームとはＭＰＥＧシステムで定義されているビット列であり、図のように１８８バイトの固定長パケット（トランスポートパケット）の連結により形成される。
【００６８】
そして、各トランスポートパケットは、図１０（ｂ）に示すようにヘッダと特定の個別パケットに付加情報を含めるためのアダプテーションフィールドとパケットの内容（ビデオ／オーディオデータ等）を表すペイロード（データ領域）とからなる。
【００６９】
ヘッダは、例えば実際には４バイトとされ、図１０（ｃ）に示すように、先頭には必ず同期バイトがあるようにされ、これより後ろの所定位置にそのパケットの識別情報であるＰＩＤ（Ｐａｃｋｅｔ＿ＩＤ）、スクランブルの有無を示すスクランブル制御情報、後続するアダプテーションフィールドやペイロードの有無等を示すアダプテーションフィールド制御情報が格納されている。
【００７０】
これらの制御情報に基づいて、受信装置側ではパケット単位でデスクランブルを行い、また、デマルチプレクサによりビデオ／オーディオ／データ等の必要パケットの分離・抽出を行うことができる。また、ビデオ／オーディオの同期再生の基準となる時刻情報を再生することもここで行うことができる。
【００７１】
また、これまでの説明から分かるように、１つのトランスポートストリームには複数チャンネル分の映像／音声／データのパケットが多重されているが、それ以外にＰＳＩ(Program Specific Information)といわれる選局を司るための信号や、限定受信（個人の契約状況により有料チャンネルの受信可不可を決定する受信機能）に必要な情報（ＥＭＭ／ＥＣＭ）、ＥＰＧなどのサービスを実現するためのＳＩ(Service Information)が同時に多重されている。ここでは、ＰＳＩについて説明する。
【００７２】
ＰＳＩは、図１１に示すようにして、４つのテーブルで構成されている。それぞれのテーブルは、セクション形式というＭＰＥＧ  Ｓｙｓｔｅｍに準拠した形式で表されている。
図１１（ａ）には、ＮＩＴ(Network Informataion Table)及びＣＡＴ(Conditional Access Table)のテーブルが示されている。
ＮＩＴは、全キャリアに同一内容が多重されている。キャリアごとの伝送諸元（偏波面、キャリア周波数、畳み込みレート等）と、そこに多重されているチャンネルのリストが記述されている。ＮＩＴのＰＩＤとしては、ＰＩＤ＝0x0010とされている。
【００７３】
ＣＡＴもまた、全キャリアに同一内容が多重される。限定受信方式の識別と契約情報等の個別情報であるＥＭＭ(Entitlement Management Message)パケットのＰＩＤが記述されている。ＰＩＤとしては、ＰＩＤ＝0x0001により示される。
【００７４】
図１１（ｂ）には、キャリアごとに固有の内容を有する情報として、ＰＡＴが示される。ＰＡＴには、そのキャリア内のチャンネル情報と、各チャンネルの内容を表すＰＭＴのＰＩＤが記述されている。ＰＩＤとしては、ＰＩＤ＝0x0000により示される。
【００７５】
また、キャリアにおけるチャンネルごとの情報として、図１１（ｃ）に示すＰＭＴ(Program Map Table)のテーブルを有する。
ＰＭＴは、チャンネル別の内容が多重されている。例えば、図１１（ｄ）に示すような、各チャンネルを構成するコンポーネント（ビデオ／オーディオ等）と、デスクランブルに必要なＥＣＭ(Encryption Control Message)パケットのＰＩＤが記述されているＰＭＴのＰＩＤは、ＰＡＴにより指定される。
【００７６】
１−５．ＩＲＤ
続いて、受信設備３に備えられるＩＲＤ１２の一構成例について図１２を参照して説明する。
【００７７】
この図に示すＩＲＤ１２において、入力端子Ｔ１には、パラボラアンテナ１１のＬＮＢ１５により所定の周波数に変換された受信信号を入力してチューナ／フロントエンド部５１に供給する。
チューナ／フロントエンド部５１では、ＣＰＵ(Central Processing Unit)８０からの伝送諸元等を設定した設定信号に基づいて、この設定信号により決定されるキャリア（受信周波数）を受信して、例えばビタビ復調処理や誤り訂正処理等を施すことで、トランスポートストリームを得るようにされる。
チューナ／フロントエンド部５１にて得られたトランスポートストリームは、デスクランブラ５２に対して供給される。また、チューナ／フロントエンド部５１では、トランスポートストリームからＰＳＩのパケットを取得し、その選局情報を更新すると共に、トランスポートストリームにおける各チャンネルのコンポーネントＰＩＤを得て、例えばＣＰＵ８０に伝送する。ＣＰＵ８０では、取得したＰＩＤを受信信号処理に利用することになる。
【００７８】
デスクランブラ５２では、ＩＣカード６５に記憶されているデスクランブルキーデータをＣＰＵ８０を介して受け取ると共に、ＣＰＵ８０によりＰＩＤが設定される。そして、このデスクランブルキーデータとＰＩＤとに基づいてデスクランブル処理を実行し、トランスポート部５３に対して伝送する。
【００７９】
トランスポート部５３は、デマルチプレクサ７０と、例えばＤＲＡＭ等により構成されるキュー（Queue）７１とからなる。キュー（Queue）７１は、モジュール単位に対応した複数のメモリ領域が列となるようにして形成されているものとされ、例えば本実施の形態では、３２列のメモリ領域が備えられる。つまり、最大で３２モジュールの情報を同時に格納することができる。
【００８０】
デマルチプレクサ７０の概略的動作としては、ＣＰＵ８０のＤｅＭＵＸドライバ８２により設定されたフィルタ条件に従って、デスクランブラ５２から供給されたトランスポートストリームから必要なトランスポートパケットを分離し、必要があればキュー７１を作業領域として利用して、先に図７（ｅ）〜（ｈ）により示したような形式のデータを得て、それぞれ必要な機能回路部に対して供給する。
デマルチプレクサ７０にて分離されたＭＰＥＧビデオデータは、ＭＰＥＧ２ビデオデコーダ５５に対して入力され、ＭＰＥＧオーディオデータは、ＭＰＥＧオーディオデコーダ５４に対して入力される。これらデマルチプレクサ７０により分離されたＭＰＥＧビデオ／オーディオデータの個別パケットは、ＰＥＳ(Packetized Elementary Stream)と呼ばれる形式でそれぞれのデコーダに入力される。
【００８１】
また、トランスポートストリームにおけるＭＨＥＧコンテンツのデータについては、デマルチプレクサ７０によりトランスポートストリームからトランスポートパケット単位で分離抽出されながらキュー７１の所要のメモリ領域に書き込まれていくことで、モジュール単位にまとめられるようにして形成される。そして、このモジュール単位にまとめられたＭＨＥＧコンテンツのデータは、ＣＰＵ８０の制御によってデータバスを介して、メインメモリ９０内のＤＳＭ−ＣＣバッファ９１に書き込まれて保持される。
【００８２】
また、トランスポートストリームにおける４倍速ＡＴＲＡＣデータ（圧縮オーディオデータ）も、例えばトランスポートパケット単位で必要なデータがデマルチプレクサ７０により分離抽出されてＩＥＥＥ１３９４インターフェイス６０に対して出力される。また、ＩＥＥＥ１３９４インターフェイス６０を介した場合には、オーディオディオデータの他、ビデオデータ及び各種コマンド信号等を送出することも可能とされる。
【００８３】
ＰＥＳとしての形式によるＭＰＥＧビデオデータが入力されたＭＰＥＧ２ビデオデコーダ５５では、メモリ５５Ａを作業領域として利用しながらＭＰＥＧ２フォーマットに従って復号化処理を施す。復号化されたビデオデータは、表示処理部５８に供給される。
【００８４】
表示処理部５８には、上記ＭＰＥＧ２ビデオデコーダ５５から入力されたビデオデータと、後述するようにしてメインメモリ９０のＭＨＥＧバッファ９２にて得られるデータサービス用のＧＵＩ画面等のビデオデータが入力される。表示処理部５８では、このようにして入力されたビデオデータについて所要の信号処理を施して、所定のテレビジョン方式によるアナログオーディオ信号に変換してアナログビデオ出力端子Ｔ２に対して出力する。
これにより、アナログビデオ出力端子Ｔ２とモニタ装置１４のビデオ入力端子とを接続することで、例えば先に図４に示したような表示が行われる。
【００８５】
また、ＰＥＳによるＭＰＥＧオーディオデータが入力されるＭＰＥＧ２オーディオデコーダ５４では、メモリ５４Ａを作業領域として利用しながらＭＰＥＧ２フォーマットに従って復号化処理を施す。復号化されたオーディオデータは、Ｄ／Ａコンバータ５６及び光デジタル出力インターフェイス５９に対して供給される。
【００８６】
Ｄ／Ａコンバータ５６では、入力されたオーディオデータについてアナログ音声信号に変換してスイッチ回路５７に出力する。スイッチ回路５７では、アナログオーディオ出力端子Ｔ３又はＴ４の何れか一方に対してアナログ音声信号を出力するように信号経路の切換を行う。
ここでは、アナログオーディオ出力端子Ｔ３はモニタ装置１４の音声入力端子と接続されるために設けられているものとされる。また、アナログオーディオ出力端子Ｔ４はダウンロードした楽曲をアナログ信号により出力するための端子とされる。
また、光デジタル出力インターフェイス５９では、入力されたデジタルオーディオデータを光デジタル信号に変換して出力する。この場合、光デジタル出力インターフェイス５９は、例えばＩＥＣ９５８に準拠する。
【００８７】
メインメモリ９０は、ＣＰＵ８０が各種制御処理を行う際の作業領域として利用されるものである。そして、本実施の形態では、このメインメモリ９０において、前述したＤＳＭ−ＣＣバッファ９１と、ＭＨＥＧバッファ９２としての領域が割り当てられるようになっている。
ＭＨＥＧバッファ９２には、ＭＨＥＧ方式によるスクリプトの記述に従って生成された画像データ（例えばＧＵＩ画面の画像データ）を生成するための作業領域とされ、ここで生成された画像データはバスラインを介して表示処理部５８に供給される。
【００８８】
ＣＰＵ８０は、ＩＲＤ１２における全体制御を実行する。このなかには、デマルチプレクサ７０におけるデータ分離抽出についての制御も含まれる。
また、獲得したＭＨＥＧコンテンツのデータについてデコード処理を施すことで、スクリプトの記述内容に従ってＧＵＩ画面（シーン）を構成して出力するための処理も実行する。
【００８９】
このため、本実施の形態のＣＰＵ８０としては、主たる制御処理を実行する制御処理部８１に加え、例えば少なくとも、ＤｅＭＵＸドライバ８２、ＤＳＭ−ＣＣデコーダブロック８３、及びＭＨＥＧデコーダブロック８４が備えられる。本実施の形態では、このうち、少なくともＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４については、ソフトウェアにより構成される。
ＤｅＭＵＸドライバ８２は、入力されたトランスポートストリームのＰＩＤに基づいてデマルチプレクサ７０におけるフィルタ条件を設定する。
ＤＳＭ−ＣＣデコーダブロック８３は、ＤＳＭ−Ｍａｎａｇｅｒとしての機能を有するものであり、ＤＳＭ−ＣＣバッファ９１に格納されているモジュール単位のデータについて、ＭＨＥＧコンテンツのデータに再構築する。また、ＭＨＥＧデコーダブロック８４からのアクセスに従って所要のＤＳＭ−ＣＣデコード等に関連する処理を実行する。
【００９０】
ＭＨＥＧデコーダブロック８４は、ＤＳＭ−ＣＣデコーダブロック８３により得られたＭＨＥＧコンテンツのデータ、つまり、ＤＳＭ−ＣＣバッファ９１にて得られているＭＨＥＧコンテンツのデータにアクセスして、シーン出力のためのデコード処理を行う。つまり、そのＭＨＥＧコンテンツのスクリプトファイルにより規定されているオブジェクト間の関係を実現していくことで、シーンを形成するものである。この際、シーンとしてＧＵＩ画面を形成するのにあたっては、ＭＨＥＧバッファ９２を利用して、ここで、スクリプトファイルの内容に従ってＧＵＩ画面の画像データを生成するようにされる。
【００９１】
ＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４間のインターフェイスには、Ｕ−Ｕ  ＡＰＩ（ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＡＰＩ(Applivation Portability Interface)）が採用される。
Ｕ−Ｕ  ＡＰＩは、例えばクライアント（ＭＨＥＧデコーダブロック８４）側がＤＳＭ  Ｍａｎａｇｅｒオブジェクト（ＤＳＭの機能を実現するサーバオブジェクト；ＤＳＭ−ＣＣデコーダブロック８３）にアクセスするためのインターフェイスであり、カルーセルに含まれるＳｅｒｖｉｃｅ Ｇａｔｅｗａｙ，Ｄｉｒｅｃｔｏｒｙ，Ｆｉｌｅ，Ｓｔｒｅａｍ，Ｓｔｒｅａｍ  Ｅｖｅｎｔなどの属性を有するオブジェクトをファイルシステムのようにして構造的にアクセスすることができるようにしたＡＰＩとされる。
【００９２】
このＡＰＩを通じてカルーセルに含まれるオブジェクトへのアクセスを行うことで、カルーセルを使用するプログラム（クライアント）がカルーセル受信動作を関知することなく、バス名を使用してオブジェクトにアクセスすることが可能になる。
【００９３】
また、このＵ−Ｕ  ＡＰＩは、下層のデータ転送方式に関わらず利用することが出来るように規定されたインターフェイスの集合であることから、このＡＰＩを利用するプログラムは、Ｕ−Ｕ  ＡＰＩを提供するどのようなデータ転送方式においても利用できるという利点を有する。
【００９４】
ここで、ＣＰＵ８０の制御によりトランスポートストリームから１シーンを形成するのに必要な目的のオブジェクトを抽出するための動作例について説明しておく。
【００９５】
ＤＳＭ−ＣＣでは、トランスポートストリーム中のオブジェクトの所在を示すのにＩＯＲ(Interoperable Object Reference)が使用される。ＩＯＲには、オブジェクトを見つけ出すための力ルーセルに対応する識別子、オブジェクトの含まれるモジュールの識別子（以下ｍｏｄｕｌｅ＿ｉｄと表記）、１つのモジュール中でオブジェクトを特定する識別子（以下ｏｂｊｅｃｔ＿ｋｅｙと表記）のほかに、オブジェクトの含まれるモジュールの情報を持つＤＩＩを識別するためのタグ（ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ）情報を含んでいる。
また、モジュール情報を持つＤＩＩには、１つ以上のモジュールそれぞれについてのｍｏｄｕｌｅ＿ｉｄ、モジュールの大きさ、バージョンといった情報と、そのモジュールを識別するためのタグ（ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ）情報を含んでいる。
【００９６】
トランスポートストリームから抜き出されたＩＯＲがＣＰＵ８０において識別された場合に、そのＩＯＲで示されたオブジェクトを受信、分離して得るプロセスは、例えば次のようになる。
（Ｐｒ１）  ＣＰＵ８０のＤｅＭＵＸドライバ８２では、ＩＯＲのａｓｓｏｃｉａｔｉｏｎ＿ｔａｇと同じ値を持つエレメンタリーストリーム（以下ＥＳと表記）を、カルーセルにおけるＰＭＴのＥＳループから探し出してＰＩＤを得る。このＰＩＤを持つＥＳにＤＩＩが含まれていることになる。
（Ｐｒ２）  このＰＩＤとｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎとをフィルタ条件としてデマルチプレクサ７０に対して設定する。これにより、デマルチプレクサ７０では、ＤＩＩを分離してＣＰＵ８０に対して出力する。
（Ｐｒ３）  ＤＩＩの中で、先のＩＯＲに含まれていたｍｏｄｕｌｅ＿ｉｄに相当するモジュールのａｓｓｏｃｉａｔｉｏｎ＿ｔａｇを得る。
（Ｐｒ４）  上記ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇと同じ値を有するＥＳを、ＰＭＴのＥＳループ（カルーセル）から探し出し、ＰＩＤを得る。このＰＩＤを有するＥＳに目的とするモジュールが含まれる。
（Ｐｒ５）  上記ＰＩＤとｍｏｄｕｌｅ＿ｉｄとをフィルタ条件として設定して、デマルチプレクサ７０によるフィルタリングを行う。このフィルタ条件に適合して分離抽出されたトランスポートパケットがキュー７１の所要のメモリ領域（列）に格納されていくことで、最終的には、目的のモジュールが形成される。
（Ｐｒ６）  先のＩＯＲに含まれていたｏｂｊｅｃｔ＿ｋｅｙに相当するオブジェクトをこのモジュールから抜き出す。これが目的とするオブジェクトになる。このモジュールから抜き出されたオブジェクトは、例えば、ＤＳＭ−ＣＣバッファ９１の所定の領域に書き込みが行われる。
例えば、上記動作を繰り返し、目的とするオブジェクトを集めてＤＳＭ−ＣＣバッファ９１に格納していくことで、必要とされるシーンを形成するＭＨＥＧコンテンツが得られることになる。
【００９７】
マンマシンインターフェイス６１では、リモートコントローラ６４から送信されてきたコマンド信号を受信してＣＰＵ８０に対して伝送する。ＣＰＵ８０では、受信したコマンド信号に応じた機器の動作が得られるように、所要の制御処理を実行する。
【００９８】
ＩＣカードスロット６２にはＩＣカード６５が挿入される。そして、この挿入されたＩＣカード６５に対してＣＰＵ８０によって情報の書き込み及び読み出しが行われる。
【００９９】
モデム６３は、電話回線４を介して課金サーバ５と接続されており、ＣＰＵ８０の制御によってＩＲＤ１２と課金サーバ５との通信が行われるように制御される。
【０１００】
ここで、上記構成によるＩＲＤ１２におけるビデオ／オーディオソースの信号の流れを、図４により説明した表示形態に照らし合わせながら補足的に説明する。
図４（ａ）に示すようにして、通常の番組を出力する場合には、入力されたトランスポートストリームから必要な番組のＭＰＥＧビデオデータとＭＰＥＧオーディオデータとが抽出されて、それぞれ復号化処理が施される。そして、このビデオデータとＭＰＥＧオーディオデータが、それぞれアナログビデオ出力端子Ｔ２と、アナログオーディオ出力端子Ｔ３に出力されることで、モニタ装置１４では、放送番組の画像表示と音声出力が行われる。
【０１０１】
また、図４（ｂ）に示したＧＵＩ画面を出力する場合には、入力されたトランスポートストリームから、このＧＵＩ画面（シーン）に必要なＭＨＥＧコンテンツのデータをトランスポート部５３により分離抽出してＤＳＭ−ＣＣバッファ９１に取り込む。そして、このデータを利用して、前述したようにＤＳＭ−ＣＣデコーダブロック８３及びＭＨＥＧデコーダブロック８４が機能することで、ＭＨＥＧバッファ９２にてシーン（ＧＵＩ画面）の画像データが作成される。そして、この画像データが表示処理部５８を介してアナログビデオ出力端子Ｔ２に供給されることで、モニタ装置１４にはＧＵＩ画面の表示が行われる。
【０１０２】
また、図４（ｂ）に示したＧＵＩ画面上で楽曲のリスト２１Ｂにより楽曲が選択され、その楽曲のオーディオデータを試聴する場合には、この楽曲のＭＰＥＧオーディオデータがデマルチプレクサ７０により得られる。そして、このＭＰＥＧオーディオデータが、ＭＰＥＧオーディオデコーダ５４、Ｄ／Ａコンバータ、スイッチ回路５７、アナログオーディオ出力端子Ｔ３を介してアナログ音声信号とされてモニタ装置１４に対して出力される。
【０１０３】
また、図４（ｂ）に示したＧＵＩ画面上でダウンロードボタン２８が押されてオーディオデータをダウンロードする場合には、ダウンロードすべき楽曲のオーディオデータがデマルチプレクサ７０により抽出されてアナログオーディオ出力端子Ｔ４、光デジタル出力インターフェイス５９、またはＩＥＥＥ１３９４インターフェイス６０に出力される。
【０１０４】
ここで、特にＩＥＥＥ１３９４インターフェイス６０に対して、図２に示したＩＥＥＥ１３９４対応のＭＤレコーダ／プレーヤ１３Ａが接続されている場合には、デマルチプレクサ７０ではダウンロード楽曲の４倍速ＡＴＲＡＣデータが抽出され、ＩＥＥＥ１３９４インターフェイス６０を介してＭＤレコーダ／プレーヤ１３Ａに装填されているディスクに対して記録が行われる。また、この際には、例えばＪＰＥＧ方式で圧縮されたアルバムジャケットの静止画データ、歌詞やアーティストのプロフィールなどのテキストデータもデマルチプレクサ７０においてトランスポートストリームから抽出され、ＩＥＥＥ１３９４インターフェイス６０を介してＭＤレコーダ／プレーヤ１３Ａに転送される。ＭＤレコーダ／プレーヤ１３Ａでは、装填されているディスクの所定の領域に対して、これら静止画データ、テキストデータを記録することができるようになっている。
【０１０５】
２．本発明に至った背景
例えば、オブジェクトカルーセル方式によるデジタルデータ放送の受信を行っている場合、その放送中においてカルーセルに含まれる或るオブジェクトのバージョンが更新されたとすると、その時点で、更新前のそのオブジェクトのデータは無効となり、新しいバージョンのオブジェクトにアクセスすることが可能な状態となる。
【０１０６】
但し、ＤＳＭ−ＣＣ方式においては、カルーセルにおけるオブジェクトのバージョンが更新されたタイミングでこれをクライアント側に通知するインターフェイスを備えていない。つまり、ＩＲＤ１２の場合であれば、ＤＳＭ−ＣＣデコーダブロック８３側の受信データにおいて、或るオブジェクトのバージョンアップがあったとしても、これを直ちにＭＨＥＧデコーダブロック８４側が知ることが出来ない。
【０１０７】
ここで、クライアントが、現在シーン表示に使用しているオブジェクトのバージョンアップを通知されないまま、次にそのオブジェクトをサーバから読み出したような場合、以前のオブジェクトとは異なるデータが読み出されて、このオブジェクトにより表示が行われてしまうことになる。例えば、オブジェクトのバージョンアップに関わらず以前の表示状態を維持したいような場合には、このようなクライアント側の動作では不都合を招くことになる。
また、逆にオブジェクトのバージョンアップに対応して、現在のシーン表示の一部の内容を変更する必要が在るような場合には、或る機会でもってその更新されたオブジェクトをサーバから読み出すまでは、シーンの表示が変更されないことになる。つまり、実際のオブジェクトのバージョンアップのタイミングに対して、シーンの表示内容の更新のタイミングが遅れることになる。
このようにして、クライアントがオブジェクトのバージョンアップを通知されないことで、何らかの不都合が生じることになる。
【０１０８】
３．本実施の形態のオブジェクト更新通知制御
３−１．Ｕ−Ｕ  ＡＰＩの一般的処理
そこで、本実施の形態では、以降説明するようにして、クライアント（ＭＨＥＧデコーダブロック８４）側においてオブジェクトのバージョンアップを知ることが出来るようにして、これに対応した適切なＭＨＥＧデコード処理が得られるようにすることを目的とするものである。更には、バージョンアップされたオブジェクトを特定できるようにして、サーバ側からのオブジェクトの再度読み出しが効率的に行われるようにすることを目的とするものである。また、このようなオブジェクトのバージョンアップの通知のためのインターフェイスとしては、Ｕ−Ｕ  ＡＰＩに準拠させるように構成されるものである。
【０１０９】
ここで、本実施の形態としてのバージョンアップ通知のためのインターフェイスを説明するのに先だって、図１８により、Ｕ−Ｕ  ＡＰＩのインターフェイスの一般的な一例を説明しておく。
ここでは、クライアントであるＭＨＥＧデコーダブロック８４が、ストリーム再生を行う場合を例に挙げている。この図において○内に示す数は、ＭＨＥＧデコーダブロック８４及びＤＳＭ−ＣＣデコーダブロック８３の処理手順を示すものである。以下、この処理手順に従って説明を行う。また、以降の説明においては、ＭＨＥＧデコーダブロック８４をクライアント、ＤＳＭ−ＣＣデコーダブロック８３についてはサーバということにする。
【０１１０】
（処理１）  クライアントは、所要のタイミングでＥｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ｓｔｒｅａｍ  ｏｎ″）をサーバに対して伝送する。
Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ｓｔｒｅａｍ  ｏｎ″）は、以降において、″ｓｔｒｅａｍ  ｏｎ″イベントを受け取ることをサーバに宣言するインターフェイスである。
【０１１１】
（処理２）  Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ｓｔｒｅａｍ  ｏｎ″）が受信されると、サーバでは、ｓｔｒｅａｍ  ｏｎイベントに対応するイベント番号を返す。ここでは、Ｅｖｅｎｔ＃１０を設定してクライアントに対して伝送している。
【０１１２】
（処理３）  クライアントでは、イベント番号を獲得したら、Ｅｖｅｎｔ：：ｎｏｔｉｆｙをサーバへ出力する。
Ｅｖｅｎｔ：：ｎｏｔｉｆｙとは、クライアント側からサーバ側に対して、サーバ側において、何らかのイベントの発生があれば、その通知を要求するインターフェイスである。
【０１１３】
（処理４）  上記（処理３）のｎｏｔｉｆｙに対する応答処理として、図１８のようにして或るタイミングで受信データにおいて″ｓｔｒｅａｍ  ｏｎ″イベントが発生したら、サーバは、″ｓｔｒｅａｍ  ｏｎ″イベントに対して設定したイベント番号であるＥｖｅｎｔ＃１０をクライアントに伝送する。
（処理５）  クライアントでは、受信した上記Ｅｖｅｎｔ＃１０により、″ｓｔｒｅａｍ  ｏｎ″イベントが発生したことを知ることになる。そして、この場合には例えばストリーム再生のためのＭＨＥＧデコード処理を実行する。
【０１１４】
３−２．第１例
次に、上記図１８に示したＵ−Ｕ  ＡＰＩインターフェイスに基づく本実施の形態のオブジェクト更新通知制御について説明する。
前述のように、ＤＳＭ−ＣＣではカルーセル内のオブジェクトの更新があったことを、そのタイミングでクライアントに知らせるための情報を有してはいない。また、更新されたオブジェクトを直接的に識別可能な情報も伝送はされない。つまり、現状では、クライアント側は受信したオブジェクトに更新があったとされるタイミングでこれを知ることは出来ず、また、その更新があったオブジェクトを特定することも出来ないことになる。
【０１１５】
但し、ＤＳＭ−ＣＣでは、あるオブジェクトについて更新（バージョンアップ）が行われた場合、そのオブジェクトが含まれるモジュールもこれに伴ってバージョンアップされるようになっている。そして、このモジュールのバージョンアップは、図８にて説明したＤＩＩの内容に反映される。即ち、ＤＩＩにおけるモジュールのバージョン情報が変更される。本実施の形態ではこれを利用する。
【０１１６】
そして、本実施の形態のオブジェクト更新通知制御として、その第１例においては、Ｕ−Ｕ  ＡＰＩのインターフェイスとして″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントを追加する。この″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントは、サーバ側において、その内容が更新された新規のＤＩＩメッセージを受信したことを意味する。そして、図１３の（処理１）〜（処理４）に示すようにしてオブジェクト更新通知制御を実行する。
【０１１７】
（処理１）  クライアントは、Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ＤＩＩ＿ＣＨＡＮＧＥＤ″）をサーバに伝達する。
（処理２）  Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ＤＩＩ＿ＣＨＡＮＧＥＤ″）を受信したサーバは、″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントに対して設定したイベント番号をクライアントに返す。ここでは、″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントに対してＥｖｅｎｔ＃２を設定して返している。
【０１１８】
（処理３）  上記イベント番号を獲得した後、クライアントは、Ｅｖｅｎｔ：：ｎｏｔｉｆｙをサーバに伝送し、″ＤＩＩ＿ＣＨＡＮＧＥＤ″を含む何らかのイベントが発生したらこれを通知する要求を行う。
（処理４）  サーバでは、受信したカルーセルのデータに含まれるＤＩＩごとにそのバージョン値を保持しているようにされる。そして、上記Ｅｖｅｎｔ：：ｎｏｔｉｆｙを受けて後の或るタイミングで、受信したカルーセルのデータに含まれるＤＩＩのバージョン値が変更された、つまりＤＩＩの内容に切り換えがあったとする。これは、そのＤＩＩが示すカルーセルのモジュールにおいて、特定は出来ないが何らかのオブジェクトについてバージョンアップがあったことを意味する。
このようにして、ＤＩＩのバージョンアップ（内容切り換え）があった、つまり″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントが発生すると、サーバでは、（処理３）のＥｖｅｎｔ：：ｎｏｔｉｆｙに対する応答として、″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントに対して設定したイベント番号（Ｅｖｅｎｔ＃２）をクライアントに伝送するようにされる。
【０１１９】
これにより、クライアントでは、少なくとも現在放送中のデータサービスにおいてオブジェクトの変更があったことをほぼリアルタイムで知ることが出来る。
そして、この通知に従って、オブジェクトのバージョンアップに対応した、何らかの適切なＭＨＥＧデコード処理（シーンに関する出力制御等）を実行することが可能になる。
【０１２０】
また、Ｕ−Ｕ  ＡＰＩの規定では、インターフェイスを実行する際に、何らかの情報を付加して伝達を行ってもよいこととされている。
そこで、（処理４）によりイベント番号（Ｅｖｅｎｔ＃２）をクライアントに送信する際、図のようにして、イベント番号と共にＤＩＩの更新に対応するバージョンアップされたモジュールの識別情報（ｍｏｄｕｌｅＩｄ） を付加すれば、クライアント側ではオブジェクトの内容に変更のあったモジュールを特定することが可能となる。
この場合、クライアント側では、更新されたオブジェクトの特定まではされないため、現在関心のあるオブジェクト（例えば、クライアント側でＧＵＩ画面表示などのために現在使用しているオブジェクトなどである）がバージョンアップされたモジュールに属しているかどうかまでは分からない。このため、例えば、クライアント側では、現在出力中のシーン（ＧＵＩ画面等）に必要なオブジェクトを全てＤＳＭ−ＣＣバッファ９１から再ロードするようにされる。このようにすれば、実際に更新されたオブジェクトは現在出力中のシーンの内容の変更には関連しない可能性はあるものの、更新されたオブジェクトは現在出力中のシーンの内容の変更に関わるのであれば、確実にシーン内容の変更を行うことができることになる。
【０１２１】
ところで、（処理３）として示したＥｖｅｎｔ：：ｎｏｔｉｆｙは、前述のように、何らかのイベントが発生したことの通知をクライアントからサーバに要求するものであるが、実際には、或るイベントの発生によってサーバ側でＥｖｅｎｔ：：ｎｏｔｉｆｙに応答した通知を行うと、この時点で、Ｅｖｅｎｔ：：ｎｏｔｉｆｙは無効となる。
このため、上記図１３に示した処理の実際において、はじめに（処理２）としてＥｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ＤＩＩ＿ＣＨＡＮＧＥＤ″）を発行して以降、サーバ側での″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントの発生を逃さずに通知させるためには、一旦発行したＥｖｅｎｔ：：ｎｏｔｉｆｙに応答したイベント通知が行われたら、この後、直ちに次のＥｖｅｎｔ：：ｎｏｔｉｆｙを発行するようにしている。つまり、サーバ側において、Ｅｖｅｎｔ：：ｎｏｔｉｆｙが無効とされている期間ができるだけ生じないようにするものである。
このようにすれば、データサービス放送中において、ＤＩＩの切り換えが行われるごとに、これを逃すことなくほぼリアルタイムで″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントの発生のあったことをクライアントに逐次通知することが可能になる。
【０１２２】
また、上記した（処理１）である、Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ＤＩＩ＿ＣＨＡＮＧＥＤ″）をクライアントからサーバに伝達するインターフェイスは、データサービス放送中におけるＤＩＩの切り換えを逐一逃さずに通知できるようにすることを考慮して、ＭＨＥＧデコーダブロック８４のプログラム（ＭＨＥＧエンジン）が立ち上がって直ぐのタイミングと、カルーセルのデータ内容（放送内容）自体について切り換えが行われたときに実行するようにされる。
なお、ＭＨＥＧデコーダブロック８４のプログラムを立ち上げる場合とは、例えば、これまでデータサービス放送が付随されていない放送を受信していた状態から、例えばチャンネルの切り換えや番組の変更が行われることで、新たにデータサービス放送が付随している番組を受信したときなどとされる。
【０１２３】
３−３．第２例
続いて、第２例としてのオブジェクト更新通知制御について図１４及び図１５を参照して説明する。この第２例では、クライアント側で変更のあったオブジェクトを特定することまでが可能となる。
【０１２４】
図１４に示す（処理１）〜（処理８）までによる第２例の処理手順としては次のようになる。
（処理１）  第２例においても、第１例の場合と同様に″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントが使用され、先ずクライアントは、Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ＤＩＩ＿ＣＨＡＮＧＥＤ″）をサーバに伝達する。
（処理２）  Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ＤＩＩ＿ＣＨＡＮＧＥＤ″）を受信したサーバは、″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントに対して設定したイベント番号をクライアントに返す。ここでも、″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントに対応するイベント番号としてはＥｖｅｎｔ＃２を設定して返している。
【０１２５】
（処理３）  上記イベント番号を獲得した後、クライアントはＶｅｒｓｉｏｎ：：ｇｅｔ（ｏｂｊｅｃｔＩｄ）のインターフェイスをサーバに伝送する。
Ｖｅｒｓｉｏｎ：：ｇｅｔ（ｏｂｊｅｃｔＩｄ）とは、クライアント側において関心のあるオブジェクトをサーバ側に伝えるためのインターフェイスである。このインターフェイスの引数（ｏｂｊｅｃｔＩｄ）には、その関心のあるオブジェクトについてのｏｂｊｅｃｔＩｄが示される。なお、ここでいう「関心のあるオブジェクト」とは、例えばクライアント（ＭＨＥＧデコーダブロック８４）にて現在シーン出力（ＧＵＩ画面表示等）に使用しているオブジェクトなどをいうものである。
また、実際のＶｅｒｓｉｏｎ：：ｇｅｔ（  ）としては、次のようなＡＰＩとなる。
0004378777.tif 000002
（処理４）  上記Ｖｅｒｓｉｏｎ：：ｇｅｔ（ｏｂｊｅｃｔＩｄ）の受信に応答して、サーバからはそのｏｂｊｅｃｔＩｄにより示されるオブジェクトが属するモジュールの識別情報であるｍｏｄｕｌｅＩｄを返送する。
このｍｏｄｕｌｅＩｄの返送を受けて、クライアント側では送信したｏｂｊｅｃｔＩｄと、返送されたｍｏｄｕｌｅＩｄとを対応付けして記憶する。
【０１２６】
上記（処理３）→（処理４）からなるインターフェイスは、クライアントにおいて現在関心があるとされるオブジェクトについて全て行われる。ここで、例えば最後の（処理３）→（処理４）に該当する（処理５）→（処理６）が完了したとすると、クライアント側においては、図１５に示すようなテーブル情報が得られている。つまり、［（処理３）→（処理４）］・・・［（処理５）→（処理６）］が実行されたことで、クライアント側で関心のある全てのオブジェクトごとに、そのｏｂｊｅｃｔＩｄとｍｏｄｕｌｅＩｄとが対応付けされたテーブルが得られることになる。
そして、この後（処理７）に移行する。
【０１２７】
（処理７）  クライアントは、Ｅｖｅｎｔ：：ｎｏｔｉｆｙをサーバに伝送し、何らかのイベントが発生したらこれを通知する要求を行う。
（処理８）  サーバにおいて上記Ｅｖｅｎｔ：：ｎｏｔｉｆｙに対する応答として、ＤＩＩの内容に切り換えがあって″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントが発生したとされると、サーバから、″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントに対して設定したイベント番号（Ｅｖｅｎｔ＃２）をクライアントに伝送するのであるが、前述のように、Ｕ−Ｕ  ＡＰＩでは、或るイベントの送信に際して、何らかの情報を付加してもよいことが規定されている。そこで、この場合には、イベント番号（Ｅｖｅｎｔ＃２）に対して、バージョンアップしたＤＩＩが対応するモジュール（つまりバージョンアップされたオブジェクトが属するとされるモジュール）のｍｏｄｕｌｅＩｄを付加して伝送するようにされる。
これは、次のようなＡＰＩである。
0004378777.tif 000003
【０１２８】
このようにして、クライアント側でイベント番号（Ｅｖｅｎｔ＃２）とｍｏｄｕｌｅＩｄが得られると、クライアント側では、図１５に示したテーブルついてテーブルサーチを行って、テーブルの中から、（処理８）により伝送されたｍｏｄｕｌｅＩｄと一致したｍｏｄｕｌｅＩｄを検索する。この検索されたｍｏｄｕｌｅＩｄに対応付けされたｏｂｊｅｃｔＩｄにより示されるオブジェクトが、更新されたオブジェクトである可能性を有していることになるので、クライアントは、このオブジェクトを更新のあったオブジェクトとして特定するようにされる。
この場合、例えばテーブル中において、（処理８）により伝送されたｍｏｄｕｌｅＩｄと一致したｍｏｄｕｌｅＩｄと対応づけられたｏｂｊｅｃｔＩｄが複数存在する可能性もある。この場合、これら複数のｏｂｊｅｃｔＩｄにより示されるオブジェクトのうちの全てが実際に更新されているとは限らないが、ここでは、これら複数のオブジェクトについて更新があったものと見なすようにされる。こうすれば、実際に更新のあったオブジェクトは確実に含まれるようにされる。
【０１２９】
また、第２例においても、ＤＩＩの切り換えを逃さずに″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントのイベント番号＋ｍｏｄｕｌｅＩｄの通知がクライアントに対して行われるようにするには、第１例の場合と同様に、（処理１）であるＥｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ＤＩＩ＿ＣＨＡＮＧＥＤ″）のクライアントからサーバへの伝達は、ＭＨＥＧデコーダブロック８４のプログラム立ち上げ直後、及びカルーセルの切り換えが有ったときに行われるようにすることが必要となる。
また、実際における（処理７）としてのＥｖｅｎｔ：：ｎｏｔｉｆｙのサーバへの伝達も、これに応答した何らかのイベントの通知が行われたら、イベント番号＋ｍｏｄｕｌｅＩｄの返送（処理８）が得られたら、直ちに次のＥｖｅｎｔ：：ｎｏｔｉｆｙ（＃２）の伝達を行うようにされる。
【０１３０】
このようにして、更新されたオブジェクトを知ることで、クライアントではオブジェクトのバージョンアップに対応した適切なＭＨＥＧデコード処理を実行することが出来るが、一例として次のような処理を実行することが可能である。
前述したように、ＭＨＥＧデコーダブロック８４は、ＭＨＥＧの記述内容に従って、ＤＳＭ−ＣＣバッファ９１から必要なオブジェクトのデータを読み出して、ＭＨＥＧバッファ９２にてＧＵＩ画面等のシーンのデータを形成して表示処理部５８に出力する。
ここで、図１４に示す処理によって、１又は複数の特定のオブジェクトについてバージョンアップしたことが特定されたとする。そして、これらのオブジェクトは、現在ＧＵＩ画面形成のためのオブジェクトとして使用されており、この場合には、そのオブジェクトの内容の変更（バージョンアップ）があれば、出来るだけこれを迅速にＧＵＩ画面に反映させる必要があるものとする。
このような場合、ＭＨＥＧデコーダブロック８４は、ＤＳＭ−ＣＣバッファ９１に格納されているモジュール単位のデータの中から、バージョンアップが特定されたオブジェクトのデータのみを再ロードするようにされる。そして、ＭＨＥＧバッファ９２にて、そのオブジェクトの内容についてのみ入れ替えるようにして、新規のシーンのデータを生成して、表示処理部５８に出力させるようにする。
【０１３１】
例えば更新されたオブジェクトが特定できないが、シーンについて何らかの変更が有るという可能性のみが通知されるような場合（例えば第１例）では、例えばシーン内容の一部変更に対応する場合でさえ、そのシーンを形成するための全オブジェクトについて、ＤＳＭ−ＣＣバッファ９１から再読み出しを行って、ＭＨＥＧバッファ９２上にてシーンの再構築を行う必要が生じることになる。
これに対して、第２例のようにして更新されたオブジェクトが特定される場合には、上記処理のようにして、ＭＨＥＧデコーダブロック８４は、シーン内容の一部変更に必要とされるオブジェクトのみについて処理を行えばよいことになる。つまり、同じシーン内容の一部変更を行うのにも、ＭＨＥＧデコーダブロック８４の処理負担は軽いものとすることができる。
【０１３２】
３−４．第３例
続いて、第３例としてのオブジェクト更新通知制御について図１６及び図１７を参照して説明する。
この第３例によっても、クライアント側で変更のあったオブジェクトを特定することまでが可能となる。但し、第３例においては、先の第１例及び第２例において使用された″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントは使用されない。
【０１３３】
図１６に示す第２例の手順としては次のようになる。
（処理１）  クライアントは、現在関心のあるオブジェクトについて、ＵｐｄａｔｅＥｖｅｎｔ：：ｓｕｂｓｃｒｉｂｅ（ｏｂｊｅｃｔＩｄ）をサーバ側に伝達する。
ＵｐｄａｔｅＥｖｅｎｔ：：ｓｕｂｓｃｒｉｂｅ（ｏｂｊｅｃｔＩｄ）は、引数に示すｏｂｊｅｃｔＩｄにより示されるオブジェクトが属するモジュールのバージョンアップが行われた場合のイベント（ＵｐｄａｔｅＥｖｅｎｔ）を受け取ることを宣言するものであり、次のようなＡＰＩを呼ぶことになる。
0004378777.tif 000004
【０１３４】
（処理２）  上記ＵｐｄａｔｅＥｖｅｎｔ：：ｓｕｂｓｃｒｉｂｅ（ｏｂｊｅｃｔＩｄ）を受信したサーバでは、この受信したＵｐｄａｔｅＥｖｅｎｔ：：ｓｕｂｓｃｒｉｂｅ（ｏｂｊｅｃｔＩｄ）に固有の識別情報である、ＵｐｄａｔｅＥｖｅｎｔＩｄを返送する。このＵｐｄａｔｅＥｖｅｎｔＩｄは、サーバ側にてユニークに設定されるＩｄである。
【０１３５】
クライアントは、現在関心のある全オブジェクトについて、ＵｐｄａｔｅＥｖｅｎｔ：：ｓｕｂｓｃｒｉｂｅ（ｏｂｊｅｃｔＩｄ）の伝達（処理１）と、これに応答したＵｐｄａｔｅＥｖｅｎｔＩｄの受信（処理２）を繰り返すようにされる。ここでは、（処理３）→（処理４）のプロセスが、最後のオブジェクトについての（処理１）→（処理２）に相当するものとしている。
【０１３６】
そして、関心のある全オブジェクトに対応して（処理１）→（処理２）・・・（処理３）→（処理４）が完了したとされる段階では、クライアント（ＭＨＥＧデコーダブロック８４）では、図１７（ａ）に示すテーブル情報が得られている。このテーブル情報は、（処理１）（又は（処理３））としてサーバに伝送したｏｂｊｅｃｔＩｄ、つまり関心のあるオブジェクトについてのｏｂｊｅｃｔＩｄと、これに応答してサーバから得られたＵｐｄａｔｅＥｖｅｎｔＩｄとの対応が示される。
また、サーバ（ＤＳＭ−ＣＣデコーダブロック８３）側では、図１７（ｂ）に示すテーブル情報が得られている。このテーブル情報は、（処理１）（又は（処理３））により伝送されたｏｂｊｅｃｔＩｄに対応して設定したＵｐｄａｔｅＥｖｅｎｔＩｄ、更には、上記ｏｂｊｅｃｔＩｄにより示されるオブジェクトが属するモジュールを特定するｍｏｄｕｌｅＩｄ、及びこのモジュールのバージョンナンバ（ＤＩＩにより示される）とが対応付けされたものとなる。
【０１３７】
（処理５）  上記のようにして（処理１）→（処理２）・・・（処理３）→（処理４）までが完了されると、クライアントは、ＵｐｄａｔｅＥｖｅｎｔ：：ｎｏｔｉｆｙをサーバに伝送し、ＵｐｄａｔｅＥｖｅｎｔ（モジュールの更新）が発生したらこれを通知する要求を行う。
（処理６）  サーバにおいて上記ＵｐｄａｔｅＥｖｅｎｔ：：ｎｏｔｉｆｙを受けて以降は、受信したＤＩＩが示すモジュールのバージョン値と、図１７（ｂ）に示すテーブルとを照合している。ここで、テーブルの或るｍｏｄｕｌｅＩｄに対応するバージョンナンバが、上記ＤＩＩが示すモジュールのバージョン値と異なっていれば、そのモジュールについてバージョンアップが有ったことが識別される。
このようにしてモジュールについてバージョンアップが有った場合、つまりＵｐｄａｔｅＥｖｅｎｔが発生したら、サーバは、テーブルを参照して、そのバージョンアップが有ったとされるモジュールのｍｏｄｕｌｅＩｄと対応付けされたＵｐｄａｔｅＥｖｅｎｔＩｄを付加して、次のようなＡＰＩを呼び出してＵｐｄａｔｅＥｖｅｎｔＩｄを返送する。
0004378777.tif 000005
【０１３８】
上記（処理６）によりＵｐｄａｔｅＥｖｅｎｔＩｄを受信して得たクライアント側では、この受信したＵｐｄａｔｅＥｖｅｎｔＩｄと一致する、テーブル（図１７（ａ））のＵｐｄａｔｅＥｖｅｎｔＩｄにアクセスする。そして、テーブル上で、このアクセスされたＵｐｄａｔｅＥｖｅｎｔＩｄに対応付けされたｏｂｊｅｃｔＩｄを見ることにより、バージョンアップされたオブジェクトを特定することになる。
【０１３９】
このように、第３例によってもバージョンアップされたオブジェクトが特定されるので、先の第２例の場合と同様に、ＭＨＥＧデコーダブロック８４側の処理をより効率的なものとすることが可能になる。
そして、第３例の場合には次のような利点も有する。図１７（ａ）に示したように、クライアント（ＭＨＥＧデコーダブロック８４）が有するテーブルは、サーバ側でユニークに設定されたＵｐｄａｔｅＥｖｅｎｔＩｄに対してｏｂｊｅｃｔＩｄを対応付けしたものである。従って、クライアント側ではＥｖｅｎｔ：：ｎｏｔｉｆｙに応答したＵｐｄａｔｅＥｖｅｎｔＩｄを獲得すれば、一義的にｏｂｊｅｃｔＩｄを特定することが出来る。つまり、第３例ではクライアント側でバージョンアップされたオブジェクトの特定をするのにテーブルサーチを行う必要はないものであり、それだけクライアントの処理負担が軽減されるものである。
【０１４０】
また、第３例の場合にも、（処理５）としてのＵｐｄａｔｅＥｖｅｎｔ：：ｎｏｔｉｆｙのサーバへの伝達も、これに応答したＵｐｄａｔｅＥｖｅｎｔＩｄの返送（処理６）が得られたら、直ちに次のＵｐｄａｔｅＥｖｅｎｔ：：ｎｏｔｉｆｙの伝達を行うようにして、バージョンアップしたモジュールの通知が逃さず行われるようにするものである。
なお、クライアント側でバージョンの更新について関心が無くなった場合（例えば、ＧＵＩ画面表示が停止された）には、
0004378777.tif 000006
のＡＰＩを発行する。これにより、サーバ側ではＵｐｄａｔｅＥｖｅｎｔ通知のための管理情報を消去する。
【０１４１】
また、本発明としては、データ伝送方式としてＤＳＭ−ＣＣ方式を採用し、ＭＨＥＧのクライアント−サーバ間のインターフェイスとしてＵ−Ｕ  ＡＰＩを採用した場合について説明しているが、これに限定されるものではなく、上記実施の形態において説明した送信フォーマットに準ずる伝送方式、及びインターフェイスであれば本発明の適用が可能とされる。また、本発明が適用されるシステムとしてもデジタル衛星放送システムに限定されるものではなく、例えばケーブルテレビジョンなどの放送や、インターネット等において適用することも可能である。
【０１４２】
【発明の効果】
以上説明したように本発明は、例えばＤＳＭ−ＣＣ方式のもとでデータカルーセルによりデータ伝送を行うシステムの受信側において、カルーセル（循環データ単位）内におけるデータついて更新が行われたことを、カルーセルからデータを受信して保持するサーバ（受信データ保持手段）側から、このカルーセルのデータを使用して所要の機能を実現するクライアント（データデコード手段）に対して通知できるようにしたことで、クライアント側では、この通知に従って、データの更新に応答して実行すべき処理を迅速に或いは効率的に実行することが可能になるものである。
【０１４３】
そして本発明では、上記のようなオブジェクトの更新を通知するためのオブジェクト更新通知処理として、例えばＵ−Ｕ  ＡＰＩ等の既存のインターフェイスのもとで、オブジェクトの更新に応じてその内容が更新されるモジュールに関する制御情報（ＤＩＩ）の変更を意味する制御情報変更イベント（ＤＩＩ＿ＣＨＡＮＧＥＤ）を設定し、この制御情報変更イベントを利用して、クライアント側からサーバ側に制御情報の変更が有ったことを通知するように構成される。つまり、敢えて特化されたインターフェイスの規格を採用することなく、既存のインターフェイスに準拠した上で、オブジェクトの更新を通知を実現することができ、それだけ汎用性が与えられることになる。
ここで、制御情報変更イベントに基づいて、サーバ側から制御情報変更イベントの発生を通知する際、その制御情報が対応するモジュールのＩＤを付加すれば、クライアント側では、単にカルーセル内でオブジェクトの更新が有ったことだけではなく、更新されたオブジェクトが属するモジュールまで特定することが出来るため、それだけ、データの再ロードなどを実行する際には、効率的な処理を実行することが可能になる。
【０１４４】
また、本発明の他のオブジェクト更新通知処理として、上記と同様に、Ｕ−ＵＡＰＩ等の既存のインターフェイスのもとで、ＤＩＩの変更を意味する制御情報変更イベント（ＤＩＩ＿ＣＨＡＮＧＥＤ）を設定し、クライアント側で制御情報変更イベントの受け取りを宣言（Ｅｖｅｎｔ：：ｓｕｂｓｃｒｉｂｅ）した後、関心のあるオブジェクトのＩＤをサーバに伝えると共に、サーバからはこのオブジェクトが属するモジュールのＩＤをクライアントに送るようにする。そして、この後のクライアントの制御情報変更イベントの受け取り要求に応えて、サーバ側では、更新された制御情報のモジュールのＩＤを付加して、制御情報変更イベントが有ったことを通知するように構成する。
これにより、クライアント側では、オブジェクトＩＤとモジュールＩＤとを対応付けしたテーブルを検索することで、ほぼ更新されたオブジェクトの特定までも行うことが可能になる。この場合、クライアント側では、例えばオブジェクト単位でデータを再ロードすればよく、更に処理負担が軽くなる。
【０１４５】
また、更に他のオブジェクト更新通知処理として、クライアント側では、関心のあるオブジェクトＩＤを付加してモジュールの更新イベントの受け取りをサーバに宣言（ｓｕｂｓｃｒｉｂｅ）し、サーバでは、このｓｕｂｓｃｒｉｂｅに応答して、固有のモジュール更新イベントのＩＤを設定してクライアントに返送すというインターフェイスを実行するようにされる。
そして、この後のクライアントのモジュール更新イベントの受け取り要求に応えて、サーバ側では、更新された制御情報のモジュール更新イベントＩＤを付加してモジュール変更イベントを送信するように構成する。
この構成によっても、クライアント側では、オブジェクトＩＤとモジュール更新イベントＩＤとを対応付けしたテーブルを検索することで、ほぼ更新されたオブジェクトの特定までも行うことが可能になる。そして、この構成では、クライアント側では獲得したモジュール更新イベントＩＤと対応するオブジェクトＩＤが一義的に得られるため、更新されたオブジェクトを特定するのにテーブルサーチを行う必要が無く、更にクライアント側の処理負担は軽減される。
【０１４６】
また、サブスクライブイベント（Ｅｖｅｎｔ：：ｓｕｂｓｃｒｉｂｅ）の伝達は、クライアントのプログラムの立ち上げ時、又は、カルーセル自体の切り換えが行われたときに実行する、また、イベント通知要求（Ｅｖｅｎｔ：：ｎｏｔｉｆｙ）は、サーバからのイベント通知要求に対する応答メッセージが得られた後において、直ちに実行されるようにすることで、クライアントのプログラムの立ち上げ以降においては、オブジェクトの更新の通知をほぼ逃さずに得ることが可能になり、例えば、放送側でのオブジェクトの更新にほぼ即応したＧＵＩ画面の内容変更が可能になるなど、信頼性が向上することになる。
【図面の簡単な説明】
【図１】本発明の実施の形態のデジタル衛星放送受信システムの構成例を示すブロック図である。
【図２】本実施の形態における受信設備の構築例を示すブロック図である。
【図３】ＩＲＤのためのリモートコントローラの外観を示す正面図である。
【図４】放送画面とＧＵＩ画面との切り換えを示す説明図である。
【図５】地上局の構成例を示すブロック図である。
【図６】地上局から送信されるデータを示すチャート図である。
【図７】送信データの時分割多重化構造を示す説明図である。
【図８】ＤＳＭ−ＣＣによる送信フォーマットを示す説明図である。
【図９】データサービスのディレクトリ構造の一例を示す説明図である。
【図１０】トランスポートストリームのデータ構造図である。
【図１１】ＰＳＩのテーブル構造を示す説明図である。
【図１２】ＩＲＤの構成を示す説明図である。
【図１３】第１例としてのオブジェクト更新通知制御を示す説明図である。
【図１４】第２例としてのオブジェクト更新通知制御を示す説明図である。
【図１５】第２例においてクライアント側で用意されるテーブル構造を示す説明図である。
【図１６】第３例としてのオブジェクト更新通知制御を示す説明図である。
【図１７】第３例においてクライアント側で用意されるテーブル構造を示す説明図である。
【図１８】Ｕ−Ｕ  ＡＰＩインターフェイスの一般的な制御動作例を示す説明図である。
【符号の説明】
１  地上局、２  衛星、３  受信設備、５  課金サーバ、６  テレビ番組素材サーバ、７  楽曲素材サーバ、８  音声付加情報サーバ、９  ＧＵＩデータサーバ、１０  キー情報サーバ、１１  パラボラアンテナ、１３  ストレージデバイス、１３Ａ  ＭＤレコーダ／プレーヤ、１４  モニタ装置、１６  ＩＥＥＥ１３９４バス、２１Ａ  テレビ番組表示エリア、２１Ｂ  リスト、２１Ｃ  テキスト表示エリア、２１Ｄ  ジャケット表示エリア、２２  歌詞表示ボタン、２３  プロフィール表示ボタン、２４  情報表示ボタン、２５  予約録音ボタン、２６  予約済一覧表示ボタン、２７  録音履歴ボタン、２８  ダウンロードボタン、３１  テレビ番組素材登録システム、３２  楽曲素材登録システム、３３  音声付加情報登録システム、３４  ＧＵＩ用素材登録システム、３５  ＡＶサーバ、３６Ａ  ＭＰＥＧオーディオエンコーダ、３６Ｂ  ＡＴＲＡＣエンコーダ、３７  音声付加情報データベース、３８  ＧＵＩ素材データベース、３９  テレビ番組送出システム、４０Ａ  ＭＰＥＧオーディオサーバ、４０Ｂ  ＭＰＥＧオーディオサーバ、４１  音声付加情報送出システム、４２  ＧＵＩオーサリングシステム、４３Ａ  ＭＰＥＧオーディオ送出システム、４３Ｂ  ＡＴＲＡＣオーディオ送出システム、４４  ＤＳＭ−ＣＣエンコーダ、４５  マルチプレクサ、４６  電波送出システム、５１  チューナ／フロントエンド部、５２  デスクランブラ、５３  トランスポート部、５４  ＭＰＥＧ２オーディオデコーダ、５４Ａ  メモリ、５５  ＭＰＥＧ２ビデオデコーダ、５５Ａ  メモリ、５６  Ｄ／Ａコンバータ、５７  スイッチ回路、５８  表示処理部、５９  光デジタル出力インターフェイス、６０  ＩＥＥＥ１３９４インターフェイス、６１  マンマシンインターフェイス、６２  ＩＣカードスロット、６３  モデム、６４  リモートコントローラ、６５  ＩＣカード、７０  デマルチプレクサ、７１  キュー、８１  制御処理部、８２  ＤｅＭＵＸドライバ、８３  ＤＳＭ−ＣＣデコーダブロック、８４  ＭＨＥＧデコーダブロック、９０  メインメモリ、９１  ＤＳＭ−ＣＣバッファ、１０１  電源キー、１０２  数字キー、１０３  画面表示切換キー、１０４  インタラクティブ切換キー、１０５ａ  矢印キー、１０５  ＥＰＧキーパネル部、１０６  チャンネルキー、Ｔ１  入力端子、Ｔ２  アナログビデオ出力端子、Ｔ３  アナログオーディオ出力端子、Ｔ４  アナログオーディオ出力端子
【図１】
0004378777.tif 000007
【図２】
0004378777.tif 000008
【図３】
0004378777.tif 000009
【図４】
0004378777.tif 000010
【図５】
0004378777.tif 000011
【図６】
0004378777.tif 000012
【図７】
0004378777.tif 000013
【図８】
0004378777.tif 000014
【図９】
0004378777.tif 000015
【図１０】
0004378777.tif 000016
【図１１】
0004378777.tif 000017
【図１２】
0004378777.tif 000018
【図１３】
0004378777.tif 000019
【図１４】
0004378777.tif 000020
【図１５】
0004378777.tif 000021
【図１６】
0004378777.tif 000022
【図１７】
0004378777.tif 000023
【図１８】
0004378777.tif 000024