JP2000032423A

JP2000032423A - データ伝達制御方法

Info

Publication number: JP2000032423A
Application number: JP10198737A
Authority: JP
Inventors: Kenichi Murata; 賢一村田; Naohisa Kitazato; 直久北里; Junya Saito; 潤也斎藤; Yasushi Katayama; 靖片山
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1998-07-14
Filing date: 1998-07-14
Publication date: 2000-01-28
Anticipated expiration: 2018-07-14
Also published as: JP4378777B2

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)と呼ばれる形式で
それぞれのデコーダに入力される。

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

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

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

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

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

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

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

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

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

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

【００９１】ＤＳＭ−ＣＣデコーダブロック８３及びＭ
ＨＥＧデコーダブロック８４間のインターフェイスに
は、Ｕ−ＵＡＰＩ（ＤＳＭ−ＣＣＵ−ＵＡＰＩ(A
pplivation Portability Interface)）が採用される。
Ｕ−ＵＡＰＩは、例えばクライアント（ＭＨＥＧデコ
ーダブロック８４）側がＤＳＭＭａｎａｇｅｒオブジ
ェクト（ＤＳＭの機能を実現するサーバオブジェクト；
ＤＳＭ−ＣＣデコーダブロック８３）にアクセスするた
めのインターフェイスであり、カルーセルに含まれるＳ
ｅｒｖｉｃｅＧａｔｅｗａｙ，Ｄｉｒｅｃｔｏｒｙ，
Ｆｉｌｅ，Ｓｔｒｅａｍ，ＳｔｒｅａｍＥｖｅｎｔな
どの属性を有するオブジェクトをファイルシステムのよ
うにして構造的にアクセスすることができるようにした
ＡＰＩとされる。

【００９２】このＡＰＩを通じてカルーセルに含まれる
オブジェクトへのアクセスを行うことで、カルーセルを
使用するプログラム（クライアント）がカルーセル受信
動作を関知することなく、バス名を使用してオブジェク
トにアクセスすることが可能になる。

【００９３】また、このＵ−ＵＡＰＩは、下層のデー
タ転送方式に関わらず利用することが出来るように規定
されたインターフェイスの集合であることから、このＡ
ＰＩを利用するプログラムは、Ｕ−ＵＡＰＩを提供す
るどのようなデータ転送方式においても利用できるとい
う利点を有する。

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

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

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

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

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

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

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

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

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

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

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

【０１０５】２．本発明に至った背景例えば、オブジェクトカルーセル方式によるデジタルデ
ータ放送の受信を行っている場合、その放送中において
カルーセルに含まれる或るオブジェクトのバージョンが
更新されたとすると、その時点で、更新前のそのオブジ
ェクトのデータは無効となり、新しいバージョンのオブ
ジェクトにアクセスすることが可能な状態となる。

【０１０６】但し、ＤＳＭ−ＣＣ方式においては、カル
ーセルにおけるオブジェクトのバージョンが更新された
タイミングでこれをクライアント側に通知するインター
フェイスを備えていない。つまり、ＩＲＤ１２の場合で
あれば、ＤＳＭ−ＣＣデコーダブロック８３側の受信デ
ータにおいて、或るオブジェクトのバージョンアップが
あったとしても、これを直ちにＭＨＥＧデコーダブロッ
ク８４側が知ることが出来ない。

【０１０７】ここで、クライアントが、現在シーン表示
に使用しているオブジェクトのバージョンアップを通知
されないまま、次にそのオブジェクトをサーバから読み
出したような場合、以前のオブジェクトとは異なるデー
タが読み出されて、このオブジェクトにより表示が行わ
れてしまうことになる。例えば、オブジェクトのバージ
ョンアップに関わらず以前の表示状態を維持したいよう
な場合には、このようなクライアント側の動作では不都
合を招くことになる。また、逆にオブジェクトのバージ
ョンアップに対応して、現在のシーン表示の一部の内容
を変更する必要が在るような場合には、或る機会でもっ
てその更新されたオブジェクトをサーバから読み出すま
では、シーンの表示が変更されないことになる。つま
り、実際のオブジェクトのバージョンアップのタイミン
グに対して、シーンの表示内容の更新のタイミングが遅
れることになる。このようにして、クライアントがオブ
ジェクトのバージョンアップを通知されないことで、何
らかの不都合が生じることになる。

【０１０８】３．本実施の形態のオブジェクト更新通知
制御３−１．Ｕ−ＵＡＰＩの一般的処理そこで、本実施の形態では、以降説明するようにして、
クライアント（ＭＨＥＧデコーダブロック８４）側にお
いてオブジェクトのバージョンアップを知ることが出来
るようにして、これに対応した適切なＭＨＥＧデコード
処理が得られるようにすることを目的とするものであ
る。更には、バージョンアップされたオブジェクトを特
定できるようにして、サーバ側からのオブジェクトの再
度読み出しが効率的に行われるようにすることを目的と
するものである。また、このようなオブジェクトのバー
ジョンアップの通知のためのインターフェイスとして
は、Ｕ−ＵＡＰＩに準拠させるように構成されるもの
である。

【０１０９】ここで、本実施の形態としてのバージョン
アップ通知のためのインターフェイスを説明するのに先
だって、図１８により、Ｕ−ＵＡＰＩのインターフェ
イスの一般的な一例を説明しておく。ここでは、クライ
アントであるＭＨＥＧデコーダブロック８４が、ストリ
ーム再生を行う場合を例に挙げている。この図において
○内に示す数は、ＭＨＥＧデコーダブロック８４及びＤ
ＳＭ−ＣＣデコーダブロック８３の処理手順を示すもの
である。以下、この処理手順に従って説明を行う。ま
た、以降の説明においては、ＭＨＥＧデコーダブロック
８４をクライアント、ＤＳＭ−ＣＣデコーダブロック８
３についてはサーバということにする。

【０１１０】（処理１）クライアントは、所要のタイ
ミングでＥｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ｓｔｒ
ｅａｍｏｎ″）をサーバに対して伝送する。Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ｓｔｒｅａｍ
ｏｎ″）は、以降において、″ｓｔｒｅａｍｏｎ″イ
ベントを受け取ることをサーバに宣言するインターフェ
イスである。

【０１１１】（処理２）Ｅｖｅｎｔ：：Ｓｕｂｓｃｒ
ｉｂｅ（″ｓｔｒｅａｍｏｎ″）が受信されると、サ
ーバでは、ｓｔｒｅａｍｏｎイベントに対応するイベ
ント番号を返す。ここでは、Ｅｖｅｎｔ＃１０を設定し
てクライアントに対して伝送している。

【０１１２】（処理３）クライアントでは、イベント
番号を獲得したら、Ｅｖｅｎｔ：：ｎｏｔｉｆｙをサー
バへ出力する。Ｅｖｅｎｔ：：ｎｏｔｉｆｙとは、クライアント側から
サーバ側に対して、サーバ側において、何らかのイベン
トの発生があれば、その通知を要求するインターフェイ
スである。

【０１１３】（処理４）上記（処理３）のｎｏｔｉｆ
ｙに対する応答処理として、図１８のようにして或るタ
イミングで受信データにおいて″ｓｔｒｅａｍｏｎ″
イベントが発生したら、サーバは、″ｓｔｒｅａｍｏ
ｎ″イベントに対して設定したイベント番号であるＥｖ
ｅｎｔ＃１０をクライアントに伝送する。（処理５）クライアントでは、受信した上記Ｅｖｅｎ
ｔ＃１０により、″ｓｔｒｅａｍｏｎ″イベントが発
生したことを知ることになる。そして、この場合には例
えばストリーム再生のためのＭＨＥＧデコード処理を実
行する。

【０１１４】３−２．第１例次に、上記図１８に示したＵ−ＵＡＰＩインターフェ
イスに基づく本実施の形態のオブジェクト更新通知制御
について説明する。前述のように、ＤＳＭ−ＣＣではカ
ルーセル内のオブジェクトの更新があったことを、その
タイミングでクライアントに知らせるための情報を有し
てはいない。また、更新されたオブジェクトを直接的に
識別可能な情報も伝送はされない。つまり、現状では、
クライアント側は受信したオブジェクトに更新があった
とされるタイミングでこれを知ることは出来ず、また、
その更新があったオブジェクトを特定することも出来な
いことになる。

【０１１５】但し、ＤＳＭ−ＣＣでは、あるオブジェク
トについて更新（バージョンアップ）が行われた場合、
そのオブジェクトが含まれるモジュールもこれに伴って
バージョンアップされるようになっている。そして、こ
のモジュールのバージョンアップは、図８にて説明した
ＤＩＩの内容に反映される。即ち、ＤＩＩにおけるモジ
ュールのバージョン情報が変更される。本実施の形態で
はこれを利用する。

【０１１６】そして、本実施の形態のオブジェクト更新
通知制御として、その第１例においては、Ｕ−ＵＡＰ
Ｉのインターフェイスとして″ＤＩＩ＿ＣＨＡＮＧＥ
Ｄ″イベントを追加する。この″ＤＩＩ＿ＣＨＡＮＧＥ
Ｄ″イベントは、サーバ側において、その内容が更新さ
れた新規のＤＩＩメッセージを受信したことを意味す
る。そして、図１３の（処理１）〜（処理４）に示すよ
うにしてオブジェクト更新通知制御を実行する。

【０１１７】（処理１）クライアントは、Ｅｖｅｎ
ｔ：：Ｓｕｂｓｃｒｉｂｅ（″ＤＩＩ＿ＣＨＡＮＧＥ
Ｄ″）をサーバに伝達する。（処理２）Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″Ｄ
ＩＩ＿ＣＨＡＮＧＥＤ″）を受信したサーバは、″ＤＩ
Ｉ＿ＣＨＡＮＧＥＤ″イベントに対して設定したイベン
ト番号をクライアントに返す。ここでは、″ＤＩＩ＿Ｃ
ＨＡＮＧＥＤ″イベントに対してＥｖｅｎｔ＃２を設定
して返している。

【０１１８】（処理３）上記イベント番号を獲得した
後、クライアントは、Ｅｖｅｎｔ：：ｎｏｔｉｆｙをサ
ーバに伝送し、″ＤＩＩ＿ＣＨＡＮＧＥＤ″を含む何ら
かのイベントが発生したらこれを通知する要求を行う。（処理４）サーバでは、受信したカルーセルのデータ
に含まれるＤＩＩごとにそのバージョン値を保持してい
るようにされる。そして、上記Ｅｖｅｎｔ：：ｎｏｔｉ
ｆｙを受けて後の或るタイミングで、受信したカルーセ
ルのデータに含まれるＤＩＩのバージョン値が変更され
た、つまりＤＩＩの内容に切り換えがあったとする。こ
れは、そのＤＩＩが示すカルーセルのモジュールにおい
て、特定は出来ないが何らかのオブジェクトについてバ
ージョンアップがあったことを意味する。このようにし
て、ＤＩＩのバージョンアップ（内容切り換え）があっ
た、つまり″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントが発生
すると、サーバでは、（処理３）のＥｖｅｎｔ：：ｎｏ
ｔｉｆｙに対する応答として、″ＤＩＩ＿ＣＨＡＮＧＥ
Ｄ″イベントに対して設定したイベント番号（Ｅｖｅｎ
ｔ＃２）をクライアントに伝送するようにされる。

【０１１９】これにより、クライアントでは、少なくと
も現在放送中のデータサービスにおいてオブジェクトの
変更があったことをほぼリアルタイムで知ることが出来
る。そして、この通知に従って、オブジェクトのバージ
ョンアップに対応した、何らかの適切なＭＨＥＧデコー
ド処理（シーンに関する出力制御等）を実行することが
可能になる。

【０１２０】また、Ｕ−ＵＡＰＩの規定では、インタ
ーフェイスを実行する際に、何らかの情報を付加して伝
達を行ってもよいこととされている。そこで、（処理
４）によりイベント番号（Ｅｖｅｎｔ＃２）をクライア
ントに送信する際、図のようにして、イベント番号と共
にＤＩＩの更新に対応するバージョンアップされたモジ
ュールの識別情報（ｍｏｄｕｌｅＩｄ）を付加すれ
ば、クライアント側ではオブジェクトの内容に変更のあ
ったモジュールを特定することが可能となる。この場
合、クライアント側では、更新されたオブジェクトの特
定まではされないため、現在関心のあるオブジェクト
（例えば、クライアント側でＧＵＩ画面表示などのため
に現在使用しているオブジェクトなどである）がバージ
ョンアップされたモジュールに属しているかどうかまで
は分からない。このため、例えば、クライアント側で
は、現在出力中のシーン（ＧＵＩ画面等）に必要なオブ
ジェクトを全てＤＳＭ−ＣＣバッファ９１から再ロード
するようにされる。このようにすれば、実際に更新され
たオブジェクトは現在出力中のシーンの内容の変更には
関連しない可能性はあるものの、更新されたオブジェク
トは現在出力中のシーンの内容の変更に関わるのであれ
ば、確実にシーン内容の変更を行うことができることに
なる。

【０１２１】ところで、（処理３）として示したＥｖｅ
ｎｔ：：ｎｏｔｉｆｙは、前述のように、何らかのイベ
ントが発生したことの通知をクライアントからサーバに
要求するものであるが、実際には、或るイベントの発生
によってサーバ側でＥｖｅｎｔ：：ｎｏｔｉｆｙに応答
した通知を行うと、この時点で、Ｅｖｅｎｔ：：ｎｏｔ
ｉｆｙは無効となる。このため、上記図１３に示した処
理の実際において、はじめに（処理２）としてＥｖｅｎ
ｔ：：Ｓｕｂｓｃｒｉｂｅ（″ＤＩＩ＿ＣＨＡＮＧＥ
Ｄ″）を発行して以降、サーバ側での″ＤＩＩ＿ＣＨＡ
ＮＧＥＤ″イベントの発生を逃さずに通知させるために
は、一旦発行したＥｖｅｎｔ：：ｎｏｔｉｆｙに応答し
たイベント通知が行われたら、この後、直ちに次のＥｖ
ｅｎｔ：：ｎｏｔｉｆｙを発行するようにしている。つ
まり、サーバ側において、Ｅｖｅｎｔ：：ｎｏｔｉｆｙ
が無効とされている期間ができるだけ生じないようにす
るものである。このようにすれば、データサービス放送
中において、ＤＩＩの切り換えが行われるごとに、これ
を逃すことなくほぼリアルタイムで″ＤＩＩ＿ＣＨＡＮ
ＧＥＤ″イベントの発生のあったことをクライアントに
逐次通知することが可能になる。

【０１２２】また、上記した（処理１）である、Ｅｖｅ
ｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″ＤＩＩ＿ＣＨＡＮＧＥ
Ｄ″）をクライアントからサーバに伝達するインターフ
ェイスは、データサービス放送中におけるＤＩＩの切り
換えを逐一逃さずに通知できるようにすることを考慮し
て、ＭＨＥＧデコーダブロック８４のプログラム（ＭＨ
ＥＧエンジン）が立ち上がって直ぐのタイミングと、カ
ルーセルのデータ内容（放送内容）自体について切り換
えが行われたときに実行するようにされる。なお、ＭＨ
ＥＧデコーダブロック８４のプログラムを立ち上げる場
合とは、例えば、これまでデータサービス放送が付随さ
れていない放送を受信していた状態から、例えばチャン
ネルの切り換えや番組の変更が行われることで、新たに
データサービス放送が付随している番組を受信したとき
などとされる。

【０１２３】３−３．第２例続いて、第２例としてのオブジェクト更新通知制御につ
いて図１４及び図１５を参照して説明する。この第２例
では、クライアント側で変更のあったオブジェクトを特
定することまでが可能となる。

【０１２４】図１４に示す（処理１）〜（処理８）まで
による第２例の処理手順としては次のようになる。（処理１）第２例においても、第１例の場合と同様
に″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントが使用され、先
ずクライアントは、Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ
（″ＤＩＩ＿ＣＨＡＮＧＥＤ″）をサーバに伝達する。（処理２）Ｅｖｅｎｔ：：Ｓｕｂｓｃｒｉｂｅ（″Ｄ
ＩＩ＿ＣＨＡＮＧＥＤ″）を受信したサーバは、″ＤＩ
Ｉ＿ＣＨＡＮＧＥＤ″イベントに対して設定したイベン
ト番号をクライアントに返す。ここでも、″ＤＩＩ＿Ｃ
ＨＡＮＧＥＤ″イベントに対応するイベント番号として
はＥｖｅｎｔ＃２を設定して返している。

【０１２５】（処理３）上記イベント番号を獲得した
後、クライアントはＶｅｒｓｉｏｎ：：ｇｅｔ（ｏｂｊ
ｅｃｔＩｄ）のインターフェイスをサーバに伝送する。Ｖｅｒｓｉｏｎ：：ｇｅｔ（ｏｂｊｅｃｔＩｄ）とは、
クライアント側において関心のあるオブジェクトをサー
バ側に伝えるためのインターフェイスである。このイン
ターフェイスの引数（ｏｂｊｅｃｔＩｄ）には、その関
心のあるオブジェクトについてのｏｂｊｅｃｔＩｄが示
される。なお、ここでいう「関心のあるオブジェクト」
とは、例えばクライアント（ＭＨＥＧデコーダブロック
８４）にて現在シーン出力（ＧＵＩ画面表示等）に使用
しているオブジェクトなどをいうものである。また、実
際のＶｅｒｓｉｏｎ：：ｇｅｔ（）としては、次のよ
うなＡＰＩとなる。ｉｎｔｅｒｆａｃｅＶｅｒｓｉｏｎ｛ｖｏｉｄｇｅｔ（ｉｎＯｂｊＲｅｆｏｂｊ，ｏｕｔｕ＿ｓｈｏｒｔｍｏｄｕｌｅＩｄ）；｝；（処理４）上記Ｖｅｒｓｉｏｎ：：ｇｅｔ（ｏｂｊｅ
ｃｔＩｄ）の受信に応答して、サーバからはそのｏｂｊ
ｅｃｔＩｄにより示されるオブジェクトが属するモジュ
ールの識別情報であるｍｏｄｕｌｅＩｄを返送する。こ
のｍｏｄｕｌｅＩｄの返送を受けて、クライアント側で
は送信したｏｂｊｅｃｔＩｄと、返送されたｍｏｄｕｌ
ｅＩｄとを対応付けして記憶する。

【０１２６】上記（処理３）→（処理４）からなるイン
ターフェイスは、クライアントにおいて現在関心がある
とされるオブジェクトについて全て行われる。ここで、
例えば最後の（処理３）→（処理４）に該当する（処理
５）→（処理６）が完了したとすると、クライアント側
においては、図１５に示すようなテーブル情報が得られ
ている。つまり、［（処理３）→（処理４）］・・・
［（処理５）→（処理６）］が実行されたことで、クラ
イアント側で関心のある全てのオブジェクトごとに、そ
のｏｂｊｅｃｔＩｄとｍｏｄｕｌｅＩｄとが対応付けさ
れたテーブルが得られることになる。そして、この後
（処理７）に移行する。

【０１２７】（処理７）クライアントは、Ｅｖｅｎ
ｔ：：ｎｏｔｉｆｙをサーバに伝送し、何らかのイベン
トが発生したらこれを通知する要求を行う。（処理８）サーバにおいて上記Ｅｖｅｎｔ：：ｎｏｔ
ｉｆｙに対する応答として、ＤＩＩの内容に切り換えが
あって″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントが発生した
とされると、サーバから、″ＤＩＩ＿ＣＨＡＮＧＥＤ″
イベントに対して設定したイベント番号（Ｅｖｅｎｔ＃
２）をクライアントに伝送するのであるが、前述のよう
に、Ｕ−ＵＡＰＩでは、或るイベントの送信に際し
て、何らかの情報を付加してもよいことが規定されてい
る。そこで、この場合には、イベント番号（Ｅｖｅｎｔ
＃２）に対して、バージョンアップしたＤＩＩが対応す
るモジュール（つまりバージョンアップされたオブジェ
クトが属するとされるモジュール）のｍｏｄｕｌｅＩｄ
を付加して伝送するようにされる。これは、次のような
ＡＰＩである。ｍｏｄｕｌｅＤＳＭ｛ｉｎｔｅｒｆａｃｅＥｖｅｎｔ｛ｓｔｒｕｃｔＳｔｒｅａｍＥｖｅｎｔ｛ｕ＿ｓｈｏｒｔｅｖｅｎｔＩｄ；／／ｉｄｆｏｒＤＩＩ＿ＣＨＡＮＧＥＤＡｐｐＮＰＴｒＡｐｐＴｉｍｅ；／／ｎｏｔｕｓｅｄｓｅｑｕｅｎｃｅ＜ｕ＿ｓｈｏｒｔ，６５５３５＞ｍｏｄｕｌｅＩｄＬｉｓｔ；／／（ＮＥＷ）｝｝｝

【０１２８】このようにして、クライアント側でイベン
ト番号（Ｅｖｅｎｔ＃２）とｍｏｄｕｌｅＩｄが得られ
ると、クライアント側では、図１５に示したテーブルつ
いてテーブルサーチを行って、テーブルの中から、（処
理８）により伝送されたｍｏｄｕｌｅＩｄと一致したｍ
ｏｄｕｌｅＩｄを検索する。この検索されたｍｏｄｕｌ
ｅＩｄに対応付けされたｏｂｊｅｃｔＩｄにより示され
るオブジェクトが、更新されたオブジェクトである可能
性を有していることになるので、クライアントは、この
オブジェクトを更新のあったオブジェクトとして特定す
るようにされる。この場合、例えばテーブル中におい
て、（処理８）により伝送されたｍｏｄｕｌｅＩｄと一
致したｍｏｄｕｌｅＩｄと対応づけられたｏｂｊｅｃｔ
Ｉｄが複数存在する可能性もある。この場合、これら複
数のｏｂｊｅｃｔＩｄにより示されるオブジェクトのう
ちの全てが実際に更新されているとは限らないが、ここ
では、これら複数のオブジェクトについて更新があった
ものと見なすようにされる。こうすれば、実際に更新の
あったオブジェクトは確実に含まれるようにされる。

【０１２９】また、第２例においても、ＤＩＩの切り換
えを逃さずに″ＤＩＩ＿ＣＨＡＮＧＥＤ″イベントのイ
ベント番号＋ｍｏｄｕｌｅＩｄの通知がクライアントに
対して行われるようにするには、第１例の場合と同様
に、（処理１）であるＥｖｅｎｔ：：Ｓｕｂｓｃｒｉｂ
ｅ（″ＤＩＩ＿ＣＨＡＮＧＥＤ″）のクライアントから
サーバへの伝達は、ＭＨＥＧデコーダブロック８４のプ
ログラム立ち上げ直後、及びカルーセルの切り換えが有
ったときに行われるようにすることが必要となる。ま
た、実際における（処理７）としてのＥｖｅｎｔ：：ｎ
ｏｔｉｆｙのサーバへの伝達も、これに応答した何らか
のイベントの通知が行われたら、イベント番号＋ｍｏｄ
ｕｌｅＩｄの返送（処理８）が得られたら、直ちに次の
Ｅｖｅｎｔ：：ｎｏｔｉｆｙ（＃２）の伝達を行うよう
にされる。

【０１３０】このようにして、更新されたオブジェクト
を知ることで、クライアントではオブジェクトのバージ
ョンアップに対応した適切なＭＨＥＧデコード処理を実
行することが出来るが、一例として次のような処理を実
行することが可能である。前述したように、ＭＨＥＧデ
コーダブロック８４は、ＭＨＥＧの記述内容に従って、
ＤＳＭ−ＣＣバッファ９１から必要なオブジェクトのデ
ータを読み出して、ＭＨＥＧバッファ９２にてＧＵＩ画
面等のシーンのデータを形成して表示処理部５８に出力
する。ここで、図１４に示す処理によって、１又は複数
の特定のオブジェクトについてバージョンアップしたこ
とが特定されたとする。そして、これらのオブジェクト
は、現在ＧＵＩ画面形成のためのオブジェクトとして使
用されており、この場合には、そのオブジェクトの内容
の変更（バージョンアップ）があれば、出来るだけこれ
を迅速にＧＵＩ画面に反映させる必要があるものとす
る。このような場合、ＭＨＥＧデコーダブロック８４
は、ＤＳＭ−ＣＣバッファ９１に格納されているモジュ
ール単位のデータの中から、バージョンアップが特定さ
れたオブジェクトのデータのみを再ロードするようにさ
れる。そして、ＭＨＥＧバッファ９２にて、そのオブジ
ェクトの内容についてのみ入れ替えるようにして、新規
のシーンのデータを生成して、表示処理部５８に出力さ
せるようにする。

【０１３１】例えば更新されたオブジェクトが特定でき
ないが、シーンについて何らかの変更が有るという可能
性のみが通知されるような場合（例えば第１例）では、
例えばシーン内容の一部変更に対応する場合でさえ、そ
のシーンを形成するための全オブジェクトについて、Ｄ
ＳＭ−ＣＣバッファ９１から再読み出しを行って、ＭＨ
ＥＧバッファ９２上にてシーンの再構築を行う必要が生
じることになる。これに対して、第２例のようにして更
新されたオブジェクトが特定される場合には、上記処理
のようにして、ＭＨＥＧデコーダブロック８４は、シー
ン内容の一部変更に必要とされるオブジェクトのみにつ
いて処理を行えばよいことになる。つまり、同じシーン
内容の一部変更を行うのにも、ＭＨＥＧデコーダブロッ
ク８４の処理負担は軽いものとすることができる。

【０１３２】３−４．第３例続いて、第３例としてのオブジェクト更新通知制御につ
いて図１６及び図１７を参照して説明する。この第３例
によっても、クライアント側で変更のあったオブジェク
トを特定することまでが可能となる。但し、第３例にお
いては、先の第１例及び第２例において使用された″Ｄ
ＩＩ＿ＣＨＡＮＧＥＤ″イベントは使用されない。

【０１３３】図１６に示す第２例の手順としては次のよ
うになる。（処理１）クライアントは、現在関心のあるオブジェ
クトについて、ＵｐｄａｔｅＥｖｅｎｔ：：ｓｕｂｓｃ
ｒｉｂｅ（ｏｂｊｅｃｔＩｄ）をサーバ側に伝達する。ＵｐｄａｔｅＥｖｅｎｔ：：ｓｕｂｓｃｒｉｂｅ（ｏｂ
ｊｅｃｔＩｄ）は、引数に示すｏｂｊｅｃｔＩｄにより
示されるオブジェクトが属するモジュールのバージョン
アップが行われた場合のイベント（ＵｐｄａｔｅＥｖｅ
ｎｔ）を受け取ることを宣言するものであり、次のよう
なＡＰＩを呼ぶことになる。ｉｎｔｅｒｆａｃｅＵｐｄａｔｅＥｖｅｎｔ｛ｖｏｉｄｓｕｂｓｃｒｉｂｅ（ｉｎＯｂｊＲｅｆｏｂｊ，ｏｕｔｕ＿ｓｈｏｒｔｕｐ＿ｅｖｅｎｔＩｄ）；ｖｏｉｄｎｏｔｉｆｙ（ｉｎｕ＿ｓｈｏｒｔｕｐ＿ｅｖｅｎｔＩｄ）；｝；

【０１３４】（処理２）上記ＵｐｄａｔｅＥｖｅｎ
ｔ：：ｓｕｂｓｃｒｉｂｅ（ｏｂｊｅｃｔＩｄ）を受信
したサーバでは、この受信したＵｐｄａｔｅＥｖｅｎ
ｔ：：ｓｕｂｓｃｒｉｂｅ（ｏｂｊｅｃｔＩｄ）に固有
の識別情報である、ＵｐｄａｔｅＥｖｅｎｔＩｄを返送
する。このＵｐｄａｔｅＥｖｅｎｔＩｄは、サーバ側に
てユニークに設定されるＩｄである。

【０１３５】クライアントは、現在関心のある全オブジ
ェクトについて、ＵｐｄａｔｅＥｖｅｎｔ：：ｓｕｂｓ
ｃｒｉｂｅ（ｏｂｊｅｃｔＩｄ）の伝達（処理１）と、
これに応答したＵｐｄａｔｅＥｖｅｎｔＩｄの受信（処
理２）を繰り返すようにされる。ここでは、（処理３）
→（処理４）のプロセスが、最後のオブジェクトについ
ての（処理１）→（処理２）に相当するものとしてい
る。

【０１３６】そして、関心のある全オブジェクトに対応
して（処理１）→（処理２）・・・（処理３）→（処理
４）が完了したとされる段階では、クライアント（ＭＨ
ＥＧデコーダブロック８４）では、図１７（ａ）に示す
テーブル情報が得られている。このテーブル情報は、
（処理１）（又は（処理３））としてサーバに伝送した
ｏｂｊｅｃｔＩｄ、つまり関心のあるオブジェクトにつ
いてのｏｂｊｅｃｔＩｄと、これに応答してサーバから
得られたＵｐｄａｔｅＥｖｅｎｔＩｄとの対応が示され
る。また、サーバ（ＤＳＭ−ＣＣデコーダブロック８
３）側では、図１７（ｂ）に示すテーブル情報が得られ
ている。このテーブル情報は、（処理１）（又は（処理
３））により伝送されたｏｂｊｅｃｔＩｄに対応して設
定したＵｐｄａｔｅＥｖｅｎｔＩｄ、更には、上記ｏｂ
ｊｅｃｔＩｄにより示されるオブジェクトが属するモジ
ュールを特定するｍｏｄｕｌｅＩｄ、及びこのモジュー
ルのバージョンナンバ（ＤＩＩにより示される）とが対
応付けされたものとなる。

【０１３７】（処理５）上記のようにして（処理１）
→（処理２）・・・（処理３）→（処理４）までが完了
されると、クライアントは、ＵｐｄａｔｅＥｖｅｎ
ｔ：：ｎｏｔｉｆｙをサーバに伝送し、ＵｐｄａｔｅＥ
ｖｅｎｔ（モジュールの更新）が発生したらこれを通知
する要求を行う。（処理６）サーバにおいて上記ＵｐｄａｔｅＥｖｅｎ
ｔ：：ｎｏｔｉｆｙを受けて以降は、受信したＤＩＩが
示すモジュールのバージョン値と、図１７（ｂ）に示す
テーブルとを照合している。ここで、テーブルの或るｍ
ｏｄｕｌｅＩｄに対応するバージョンナンバが、上記Ｄ
ＩＩが示すモジュールのバージョン値と異なっていれ
ば、そのモジュールについてバージョンアップが有った
ことが識別される。このようにしてモジュールについて
バージョンアップが有った場合、つまりＵｐｄａｔｅＥ
ｖｅｎｔが発生したら、サーバは、テーブルを参照し
て、そのバージョンアップが有ったとされるモジュール
のｍｏｄｕｌｅＩｄと対応付けされたＵｐｄａｔｅＥｖ
ｅｎｔＩｄを付加して、次のようなＡＰＩを呼び出して
ＵｐｄａｔｅＥｖｅｎｔＩｄを返送する。ｉｎｔｅｒｆａｃｅＵｐｄａｔｅＥｖｅｎｔ｛ｓｔｒｕｃｔＶｅｒｓｉｏｎＵｐＥｖｅｎｔ｛ｕ＿ｓｈｏｒｔｅｖｅｎｔＩｄ；／／ｉｄｆｏｒＤＩＩ＿ＣＨＡＮＧＥＤ｝｝

【０１３８】上記（処理６）によりＵｐｄａｔｅＥｖｅ
ｎｔＩｄを受信して得たクライアント側では、この受信
したＵｐｄａｔｅＥｖｅｎｔＩｄと一致する、テーブル
（図１７（ａ））のＵｐｄａｔｅＥｖｅｎｔＩｄにアク
セスする。そして、テーブル上で、このアクセスされた
ＵｐｄａｔｅＥｖｅｎｔＩｄに対応付けされたｏｂｊｅ
ｃｔＩｄを見ることにより、バージョンアップされたオ
ブジェクトを特定することになる。

【０１３９】このように、第３例によってもバージョン
アップされたオブジェクトが特定されるので、先の第２
例の場合と同様に、ＭＨＥＧデコーダブロック８４側の
処理をより効率的なものとすることが可能になる。そし
て、第３例の場合には次のような利点も有する。図１７
（ａ）に示したように、クライアント（ＭＨＥＧデコー
ダブロック８４）が有するテーブルは、サーバ側でユニ
ークに設定されたＵｐｄａｔｅＥｖｅｎｔＩｄに対して
ｏｂｊｅｃｔＩｄを対応付けしたものである。従って、
クライアント側ではＥｖｅｎｔ：：ｎｏｔｉｆｙに応答
したＵｐｄａｔｅＥｖｅｎｔＩｄを獲得すれば、一義的
にｏｂｊｅｃｔＩｄを特定することが出来る。つまり、
第３例ではクライアント側でバージョンアップされたオ
ブジェクトの特定をするのにテーブルサーチを行う必要
はないものであり、それだけクライアントの処理負担が
軽減されるものである。

【０１４０】また、第３例の場合にも、（処理５）とし
てのＵｐｄａｔｅＥｖｅｎｔ：：ｎｏｔｉｆｙのサーバ
への伝達も、これに応答したＵｐｄａｔｅＥｖｅｎｔＩ
ｄの返送（処理６）が得られたら、直ちに次のＵｐｄａ
ｔｅＥｖｅｎｔ：：ｎｏｔｉｆｙの伝達を行うようにし
て、バージョンアップしたモジュールの通知が逃さず行
われるようにするものである。なお、クライアント側で
バージョンの更新について関心が無くなった場合（例え
ば、ＧＵＩ画面表示が停止された）には、ｉｎｔｅｒｆａｃｅＵｐｄａｔｅＥｖｅｎｔ｛ｖｏｉｄｕｎｓｕｂｓｃｒｉｂｅ（ｕｐ＿ｅｖｅｎｔＩｄ）；｝；のＡＰＩを発行する。これにより、サーバ側ではＵｐｄ
ａｔｅＥｖｅｎｔ通知のための管理情報を消去する。

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

【０１４２】

【発明の効果】以上説明したように本発明は、例えばＤ
ＳＭ−ＣＣ方式のもとでオブジェクトカルーセルにより
データ伝送を行うシステムの受信側におけるデータ伝達
制御方法として、カルーセル（循環データ単位）内にお
けるオブジェクトついて更新が行われたことを、カルー
セルからデータを受信して保持するサーバ側から、この
カルーセルのデータを使用して所要の機能を実現するク
ライアントに対して通知できるようにしたことで、クラ
イアント側では、この通知に従って、オブジェクトの更
新に応答して実行すべき処理を迅速に或いは効率的に実
行することが可能になるものである。

【０１４３】そして本発明では、上記のようなオブジェ
クトの更新を通知するためのオブジェクト更新通知処理
として、例えばＵ−ＵＡＰＩ等の既存のインターフェ
イスのもとで、オブジェクトの更新に応じてその内容が
更新されるモジュールに関する制御情報（ＤＩＩ）の変
更を意味する制御情報変更イベント（ＤＩＩ＿ＣＨＡＮ
ＧＥＤ）を設定し、この制御情報変更イベントを利用し
て、クライアント側からサーバ側に制御情報の変更が有
ったことを通知するように構成される。つまり、敢えて
特化されたインターフェイスの規格を採用することな
く、既存のインターフェイスに準拠した上で、オブジェ
クトの更新を通知を実現することができ、それだけ汎用
性が与えられることになる。ここで、制御情報変更イベ
ントに基づいて、サーバ側から制御情報変更イベントの
発生を通知する際、その制御情報が対応するモジュール
のＩＤを付加すれば、クライアント側では、単にカルー
セル内でオブジェクトの更新が有ったことだけではな
く、更新されたオブジェクトが属するモジュールまで特
定することが出来るため、それだけ、データの再ロード
などを実行する際には、効率的な処理を実行することが
可能になる。

【０１４４】また、本発明の他のオブジェクト更新通知
処理として、上記と同様に、Ｕ−ＵＡＰＩ等の既存のイ
ンターフェイスのもとで、ＤＩＩの変更を意味する制御
情報変更イベント（ＤＩＩ＿ＣＨＡＮＧＥＤ）を設定
し、クライアント側で制御情報変更イベントの受け取り
を宣言（Ｅｖｅｎｔ：：ｓｕｂｓｃｒｉｂｅ）した後、
関心のあるオブジェクトのＩＤをサーバに伝えると共
に、サーバからはこのオブジェクトが属するモジュール
のＩＤをクライアントに送るようにする。そして、この
後のクライアントの制御情報変更イベントの受け取り要
求に応えて、サーバ側では、更新された制御情報のモジ
ュールのＩＤを付加して、制御情報変更イベントが有っ
たことを通知するように構成する。これにより、クライ
アント側では、オブジェクトＩＤとモジュールＩＤとを
対応付けしたテーブルを検索することで、ほぼ更新され
たオブジェクトの特定までも行うことが可能になる。こ
の場合、クライアント側では、例えばオブジェクト単位
でデータを再ロードすればよく、更に処理負担が軽くな
る。

【０１４５】また、更に他のオブジェクト更新通知処理
として、クライアント側では、関心のあるオブジェクト
ＩＤを付加してモジュールの更新イベントの受け取りを
サーバに宣言（ｓｕｂｓｃｒｉｂｅ）し、サーバでは、
このｓｕｂｓｃｒｉｂｅに応答して、固有のモジュール
更新イベントのＩＤを設定してクライアントに返送すと
いうインターフェイスを実行するようにされる。そし
て、この後のクライアントのモジュール更新イベントの
受け取り要求に応えて、サーバ側では、更新された制御
情報のモジュール更新イベントＩＤを付加してモジュー
ル変更イベントを送信するように構成する。この構成に
よっても、クライアント側では、オブジェクトＩＤとモ
ジュール更新イベントＩＤとを対応付けしたテーブルを
検索することで、ほぼ更新されたオブジェクトの特定ま
でも行うことが可能になる。そして、この構成では、ク
ライアント側では獲得したモジュール更新イベントＩＤ
と対応するオブジェクトＩＤが一義的に得られるため、
更新されたオブジェクトを特定するのにテーブルサーチ
を行う必要が無く、更にクライアント側の処理負担は軽
減される。

【０１４６】また、サブスクライブイベント（Ｅｖｅｎ
ｔ：：ｓｕｂｓｃｒｉｂｅ）の伝達は、クライアントの
プログラムの立ち上げ時、又は、カルーセル自体の切り
換えが行われたときに実行する、また、イベント通知要
求（Ｅｖｅｎｔ：：ｎｏｔｉｆｙ）は、サーバからのイ
ベント通知要求に対する応答メッセージが得られた後に
おいて、直ちに実行されるようにすることで、クライア
ントのプログラムの立ち上げ以降においては、オブジェ
クトの更新の通知をほぼ逃さずに得ることが可能にな
り、例えば、放送側でのオブジェクトの更新にほぼ即応
したＧＵＩ画面の内容変更が可能になるなど、信頼性が
向上することになる。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

【図１３】第１例としてのオブジェクト更新通知制御を
示す説明図である。

【図１４】第２例としてのオブジェクト更新通知制御を
示す説明図である。

【図１５】第２例においてクライアント側で用意される
テーブル構造を示す説明図である。

【図１６】第３例としてのオブジェクト更新通知制御を
示す説明図である。

【図１７】第３例においてクライアント側で用意される
テーブル構造を示す説明図である。

【図１８】Ｕ−ＵＡＰＩインターフェイスの一般的な
制御動作例を示す説明図である。

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者斎藤潤也東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者片山靖東京都品川区北品川６丁目７番35号ソニー株式会社内Ｆターム(参考） 5C064 BA01 BB01 BC16 BC17 BC18 BC20 BC22 BC23 BD02 BD04 BD07 BD08

Claims

【特許請求の範囲】

【請求項１】所定方式のシナリオ記述により関連付け
されるオブジェクトを含んでデータ伝送単位を形成し
て、更に、或る一定期間にわたり転送すべき１以上のデ
ータ伝送単位を含んで循環データ単位を形成し、この循
環データ単位を繰り返し転送するデータ転送方式に対応
し、上記循環データ単位に含まれるオブジェクトについて更
新が行われたことを、上記循環データ単位を受信するサ
ーバ側からこの循環データ単位を使用するクライアント
に対して通知できるようにしたオブジェクト更新通知処
理、を実行するように構成されていることを特徴とするデー
タ伝達制御方法。
【請求項２】上記循環データ単位には、上記オブジェ
クトの更新に応じてその内容が更新される上記データ伝
送単位に関する制御情報が含まれるものとされ、上記オブジェクト更新通知処理は、所定のインターフェイスの規格のもとで、上記制御情報
の受取りがあったことを意味する制御情報更新イベント
を設定したうえで、少なくとも、クライアントが、制御情報更新イベントの受取りを宣言
するためのサブスクライブイベントをサーバに伝達する
第１の処理と、クライアントがイベントの発生の通知を要求するイベン
ト通知要求をサーバに伝達する第２の処理と、上記イベント通知要求に対するサーバの応答として、更
新された制御情報を受信したときには、制御情報更新イ
ベントが発生したことをクライアントに通知する第３の
処理と、を実行することにより実現されることを特徴とする請求
項１に記載のデータ伝達制御方法。
【請求項３】上記第３の処理は、更新された制御情報
により示されるデータ伝送単位の識別情報を付加して、
制御情報受取りイベントが発生したことをクライアント
に通知するようにされていることを特徴とする請求項２
に記載のデータ伝達制御方法。
【請求項４】上記第１の処理としてのサブスクライブ
イベントの伝達は、クライアントのプログラムの立ち上
げ時、又は、上記循環データ単位自体の切り換えが行わ
れたときに実行するように構成されていること特徴とす
る請求項２に記載のデータ伝達制御方法。
【請求項５】上記第２の処理としてのイベント通知要
求は、サーバからのイベント通知要求に対する応答メッ
セージが得られた後において、直ちに実行するように構
成されていることを特徴とする請求項２に記載のデータ
伝達制御方法。
【請求項６】上記循環データ単位には、属するオブジ
ェクトの更新に応じてその内容が更新されるデータ伝送
単位に関する制御情報が含まれるものとされ、上記オブジェクト更新通知処理は、少なくとも、クライアントが、制御情報更新イベントの受取りを宣言
するためのサブスクライブイベントをサーバに伝達する
第１の処理と、クライアントにて関心のあるオブジェクトのオブジェク
トＩＤをサーバ側に通知し、サーバ側では通知されたオ
ブジェクトが属するデータ伝送単位のデータ伝送単位Ｉ
Ｄをクライアントに返送する第２の処理と、クライアントにおいて、上記第２の処理にてサーバ側に
通知したオブジェクトＩＤと、上記第２の処理によりサ
ーバ側から獲得したデータ伝送単位ＩＤとの対応を示す
テーブル情報を生成する第３の処理と、クライアントが、イベントの発生の通知を要求するイベ
ント通知要求をサーバに伝達する第４の処理と、サーバにおける上記イベント通知要求に対する応答処理
として、サーバにおいて更新された制御情報を受信した
ときには、この更新された制御情報により示されるデー
タ伝送単位ＩＤを付加して、制御情報更新イベントが発
生したことをクライアントに通知する第５の処理と、クライアントにおいて、上記第５の処理により得られた
データ伝送単位ＩＤと一致したテーブル情報のデータ伝
送単位ＩＤを検索し、この検索されたデータ伝送単位の
ＩＤに対応付けされたオブジェクトＩＤが示すオブジェ
クトついて更新が行われたものと特定する第６の処理
と、を実行するように構成されていることを特徴とする請求
項１に記載のデータ伝達制御方法。
【請求項７】上記第１の処理としてのサブスクライブ
イベントの伝達は、クライアントのプログラムの立ち上
げ時、又は、上記循環データ単位自体の切り換えが行わ
れたときに実行するように構成されていること特徴とす
る請求項６に記載のデータ伝達制御方法。
【請求項８】上記第４の処理としてのイベント通知要
求は、サーバからのイベント通知要求に対する応答メッ
セージが得られた後において、直ちに実行されるように
構成されていることを特徴とする請求項６に記載のデー
タ伝達制御方法。
【請求項９】上記循環データ単位には、属するオブジ
ェクトの更新に応じてその内容が更新されるデータ伝送
単位に関する制御情報が含まれるものとされ、上記オブジェクト更新通知処理は、クライアントが、データ伝送単位更新イベントの受取り
を宣言するためのサブスクライブイベントを関心のある
オブジェクトのオブジェクトＩＤと共にサーバに伝達
し、サーバは、これに応答して固有のデータ伝送単位更
新イベントＩＤを設定してクライアントに伝達する第１
の処理と、クライアントにおいて、上記第１の処理にてサーバ側に
伝達したオブジェクトＩＤと、上記第１の処理によりサ
ーバ側から獲得したデータ伝送単位更新イベントＩＤと
の対応を示すテーブル情報を生成する第２の処理と、クライアントが、データ伝送単位更新イベントの発生の
通知を要求するイベント通知要求をサーバに伝達する第
３の処理と、サーバにおける上記イベント通知要求に対する応答とし
て、更新された制御情報を受信したときには、この更新
された制御情報により示されるデータ伝送単位に含まれ
るオブジェクトのオブジェクトＩＤに対応して設定した
上記データ伝送単位更新イベントＩＤを付加して、デー
タ伝送単位更新イベントが発生したことをクライアント
に通知する第４の処理と、クライアントにおいて、上記第４の処理により得たデー
タ伝送単位更新イベントＩＤと一致する上記テーブル情
報のデータ伝送単位更新イベントＩＤに対応するオブジ
ェクトＩＤを識別し、この識別したオブジェクトＩＤが
示すオブジェクトを更新されたオブジェクトとして特定
する第５の処理と、を実行するように構成されていることを特徴とする請求
項１に記載のデータ伝達制御方法。
【請求項１０】上記第２の処理としてのイベント通知
要求は、サーバからのイベント通知要求に対する応答メ
ッセージが得られた後において、直ちに実行するように
構成されていることを特徴とする請求項９に記載のデー
タ伝達制御方法。