JP4378778B2 - 受信装置および受信方法 - Google Patents
受信装置および受信方法 Download PDFInfo
- Publication number
- JP4378778B2 JP4378778B2 JP20172998A JP20172998A JP4378778B2 JP 4378778 B2 JP4378778 B2 JP 4378778B2 JP 20172998 A JP20172998 A JP 20172998A JP 20172998 A JP20172998 A JP 20172998A JP 4378778 B2 JP4378778 B2 JP 4378778B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- mheg
- dsm
- dsi
- decoder
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【発明の属する技術分野】
本発明は、例えばデジタル衛星放送などにおいてデータサービスを受信するシステムに適用して好適なデータ伝達制御方法に関するものである。
【0002】
【従来の技術】
近年、デジタル衛星放送の普及が進んでいる。デジタル衛星放送は、例えば既存のアナログ放送と比較してノイズやフェージングに強く、高品質の信号を伝送することが可能である。また、周波数利用効率が向上され、多チャンネル化も図ることが可能になる。具体的には、デジタル衛星放送であれば1つの衛星で数百チャンネルを確保することも可能である。このようなデジタル衛星放送では、スポーツ、映画、音楽、ニュースなどの専門チャンネルが多数用意されており、これらの専門チャンネルでは、それぞれの専門のコンテンツに応じたプログラムが放送されている。
【0003】
そして、上記のようなデジタル衛星放送システムを利用して、ユーザが楽曲等の音声データをダウンロードできるようにしたり、いわゆるテレビショッピングとして、例えばユーザが放送画面を見ながら何らかの商品についての購買契約を結べるようにしたりすることが提案されている。つまりは、デジタル衛星放送システムとして、通常の放送内容と並行したデータサービス放送を行うものである。
【0004】
一例として、楽曲データのダウンロードであれば、放送側においては、放送番組と並行して、楽曲データを多重化して放送するようにする。また、この楽曲データのダウンロードに際しては、GUI(Graphical User Interface)画面(即ちダウンロード用の操作画面である)を表示させることでインタラクティブな操作をユーザに行わせるようにされるが、このGUI画面出力のためのデータも多重化して放送するようにされる。
そして、受信装置を所有しているユーザ側では、所望のチャンネルを選局している状態で、受信装置に対する所定の操作によって楽曲データをダウンロードするためのGUI画面を表示出力させるようにする。そして、この表示された操作画面に対してユーザが操作を行うことで、例えば受信装置に接続したデジタルオーディオ機器に対してデータを供給し、これが録音されるようにするものである。
【0005】
ところで、上記のような楽曲データをダウンロードするためのGUI画面としては、例えばGUI画面を形成するパーツ的な画像データ、テキストデータなどの情報に加え、更には所定操作に応じた音声出力のための音声データなどの単位データ(ファイル)をそれぞれオブジェクトとして扱い、このオブジェクトの出力態様を所定方式によるシナリオ記述によって規定することによって、上記操作画面についての所要の表示形態及び音声等の出力態様を実現するように構成することが考えられる。
なお、ここでは、上記GUI画面のようにして、記述情報によって規定されることで、或る目的に従った機能を実現する表示画面(ここでは音声等の出力も含む)のことを「シーン」というものとする。また、「オブジェクト」とは、記述情報に基づいてその出力態様が規定される画像、音声、テキスト等の単位情報を示しており、伝送時においては、ここでは記述情報自体のデータファイルも「オブジェクト」の1つとして扱われるものとする。
【0006】
上記シーン表示及びシーン表示上での音声出力等を実現するためのオブジェクトは、例えば所定の伝送方式に従ってエンコードされて送信される。
受信装置側では上記伝送方式に従ってデータを受信すると共に、この受信データについてデコード処理を施して、例えば表示に必要なシーンに必要とされるオブジェクトごとの纏まりとしてのデータを得て、これをシーンとして出力するようにされる。
【0007】
【発明が解決しようとする課題】
ここで、受信装置を所有するユーザの使用環境を考慮すれば、上記所定の伝送方式に則った上で、受信装置にて受信したデータサービス用のデータの処理については出来るだけ効率的な処理が行われるようにして、例えば表示出力されるべきシーン内容の更新なども、できるだけ軽い処理で迅速に対応できるようにすることが好ましい。
【0008】
【課題を解決するための手段】
そこで、本発明は上記した課題を考慮して、転送すべき所要のデータにより循環データ単位を形成し、この循環データ単位を所要の期間にわたり繰り返し転送するデータ転送方式に対応し、上記循環データ単位の内容が切り換ったことを、上記循環データ単位を受信するサーバ側からこの循環データ単位を使用するクライアントに対して通知できるようにした循環データ単位切り換え処理を実行するようにデータ伝達制御を行う。
【0009】
上記構成によれば、少なくとも、循環データ単位の内容が切り換わったことををクライアントが知ることが可能となり、クライアントでは、これに基づいた所要の対応処理を実行することが可能になる。
【0010】
【発明の実施の形態】
以降、本発明の実施の形態について説明する。
本発明が適用されるシステムとしては、デジタル衛星放送を利用して番組を放送すると共に、受信装置側ではこの番組に関連した楽曲データ(音声データ)等の情報をダウンロードできるようにしたシステムを例に挙げることとする。
【0011】
なお、以降の説明は次の順序で行うこととする。
1.デジタル衛星放送システム
1−1.全体構成
1−2.GUI画面に対する操作
1−3.地上局
1−4.送信フォーマット
1−5.IRD
2.本発明に至った背景
3.本実施の形態のカルーセル切り換え通知制御
3−1.U−U APIの一般的処理
3−2.第1例
3−3.第2例
【0012】
1.デジタル衛星放送システムの構成
1−1.全体構成
図1は、本実施の形態としてのデジタル衛星放送システムの全体構成を示すものである。この図に示すように、デジタル衛星放送の地上局1には、テレビ番組素材サーバ6からのテレビ番組放送のための素材と、楽曲素材サーバ7からの楽曲データの素材と、音声付加情報サーバ8からの音声付加情報と、GUIデータサーバからのGUIデータとが送られる。
【0013】
テレビ番組素材サーバ6は、通常の放送番組の素材を提供するサーバである。このテレビ番組素材サーバから送られてくる音楽放送の素材は、動画及び音声とされる。例えば、音楽放送番組であれば、上記テレビ番組素材サーバ6の動画及び音声の素材を利用して、例えば新曲のプロモーション用の動画及び音声が放送されたりすることになる。
【0014】
楽曲素材サーバ7は、オーディオチャンネルを使用して、オーディオ番組を提供するサーバである。このオーディオ番組の素材は音声のみとなる。この楽曲素材サーバ7は、複数のオーディオチャンネルのオーディオ番組の素材を地上局1に伝送する。
各オーディオチャンネルの番組放送ではそれぞれ同一の楽曲が所定の単位時間繰り返して放送される。各オーディオチャンネルは、それぞれ独立しており、その利用方法としては各種考えられる。例えば、1つのオーディオチャンネルでは最新の日本のポップスの数曲を或る一定時間繰り返し放送し、他のオーディオチャンネルでは最新の外国のポップスの数曲を或る一定時間繰り返し放送するというようにされる。
【0015】
音声付加情報サーバ8は、楽曲素材サーバ7から出力される楽曲の時間情報等を提供するサーバである。
【0016】
GUIデータサーバ9は、ユーザが操作に用いるGUI画面を形成するための「GUIデータ」を提供する。例えば後述するような楽曲のダウンロードに関するGUI画面であれば、配信される楽曲のリストページや各楽曲の情報ページを形成するための画像データ、テキストデータ、アルバムジャケットの静止画を形成するためのデータなどを提供する。更には、受信設備3側にていわゆるEPG(Electrical Program Guide)といわれる番組表表示を行うのに利用されるEPGデータもここから提供される。
なお、「GUIデータ」としては、例えばMHEG(Multimedia Hypermedia Information Coding Experts Group)方式が採用される。MHEGとは、マルチメディア情報、手順、操作などのそれぞれと、その組み合わせをオブジェクトとして捉え、それらのオブジェクトを符号化したうえで、タイトル(例えばGUI画面)として制作するためのシナリオ記述の国際標準とされる。また、本実施の形態ではMHEG−5を採用するものとする。
【0017】
地上局1は上記テレビ番組素材サーバ6、楽曲素材サーバ7、音声付加情報サーバ8、及びGUIデータサーバ9から伝送された情報を多重化して送信する。本実施の形態では、テレビ番組素材サーバ6から伝送されたビデオデータはMPEG(Moving Picture Experts Group)2方式により圧縮符号化され、オーディオデータはMPEG2オーディオ方式により圧縮符号化される。また、楽曲素材サーバ7から伝送されたオーディオデータは、オーディオチャンネルごとに対応して、例えばMPEG2オーディオ方式と、ATRAC(Adoptive Tranform Acoustic Coding)方式と何れか一方の方式により圧縮符号化される。また、これらのデータは多重化の際、キー情報サーバ10からのキー情報を利用して暗号化される。
なお、地上局1の内部構成例については後述する。
【0018】
地上局1からの信号は衛星2を介して各家庭の受信設備3で受信される。衛星2には複数のトランスポンダが搭載されている。1つのトランスポンダは例えば30Mbpsの伝送能力を有している。各家庭の受信設備3としては、パラボラアンテナ11とIRD(Integrated Receiver Decorder)12と、ストレージデバイス13と、モニタ装置14とが用意される。
また、この場合には、IRD12に対して操作を行うためのリモートコントローラ64が示されている。
【0019】
パラボラアンテナ11で衛星2を介して放送されてきた信号が受信される。この受信信号がパラボラアンテナ11に取り付けられたLNB(Low Noize Block Down Converter)15で所定の周波数に変換され、IRD12に供給される。
【0020】
IRD12における概略的な動作としては、受信信号から所定のチャンネルの信号を選局し、その選局された信号から番組としてのビデオデータ及びオーディオデータの復調を行ってビデオ信号、オーディオ信号として出力する。また、IRD12では、番組としてのデータと共に多重化されて送信されてくる、GUIデータに基づいてGUI画面としての出力も行う。このようなIRD12の出力は、例えばモニタ装置14に対して供給される。これにより、モニタ装置14では、IRD12により受信選局した番組の画像表示及び音声出力が行われ、また、後述するようなユーザの操作に従ってGUI画面を表示させることが可能となる。
【0021】
ストレージデバイス13は、IRD12によりダウンロードされたオーディオデータ(楽曲データ)を保存するためのものである。このストレージデバイス13の種類としては特に限定されるものではなく、MD(Mini Disc)レコーダ/プレーヤ、DATレコーダ/プレーヤ、DVDレコーダ/プレーヤ等を用いることができる。また、ストレージデバイス13としてパーソナルコンピュータ装置を用い、ハードディスクのほか、CD−R等をはじめとする記録が可能なメディアにオーディオデータを保存するようにすることも可能とされる。
【0022】
また、本実施の形態の受信設備3としては、図2に示すように、データ伝送規格としてIEEE1394に対応したデータインターフェイスを備えたMDレコーダ/プレーヤ13Aを、図1に示すストレージデバイス13として使用することができるようになっている。
この図に示すIEEE1394対応のMDレコーダ/プレーヤ13Aは、IEEE1394バス16によりIRD12と接続される。これによって、本実施の形態では、IRD12にて受信された、楽曲としてのオーディオデータ(ダウンロードデータ)を、ATRAC方式により圧縮処理が施されたままの状態で直接取り込んで記録することができる。また、MDレコーダ/プレーヤ13AとIRD12とをIEEE1394バス16により接続した場合には、上記オーディオデータの他、そのアルバムのジャケットデータ(静止画データ)及び歌詞などのテキストデータを記録することも可能とされている。
【0023】
IRD12は、例えば電話回線4を介して課金サーバ5と通信可能とされている。IRD12には、後述するようにして各種情報が記憶されるICカードが挿入される。例えば楽曲のオーディオデータのダウンロードが行われたとすると、これに関する履歴情報がICカードに記憶される。このICカードの情報は、電話回線4を介して所定の機会、タイミングで課金サーバ5に送られる。課金サーバ5は、この送られてきた履歴情報に従って金額を設定して課金を行い、ユーザに請求する。
【0024】
これまでの説明から分かるように、本発明が適用されたシステムでは、地上局1は、テレビ番組素材サーバ6からの音楽番組放送の素材となるビデオデータ及びオーディオデータと、楽曲素材サーバ7からのオーディオチャンネルの素材となるオーディオデータと、音声付加情報サーバ8からの音声データと、GUIデータサーバ9からのGUIデータとを多重化して送信している。
そして、各家庭の受信設備3でこの放送を受信すると、例えばモニタ装置14により、選局したチャンネルの番組を視聴することができる。また、番組のデータと共に送信されるGUIデータを利用したGUI画面として、第1にはEPG(Electrical Program Guide;電子番組ガイド)画面を表示させ、番組の検索等を行うことができる。また、第2には、例えば通常の番組放送以外の特定のサービス用のGUI画面を利用して所要の操作を行うことで、本実施の形態の場合には、放送システムにおいて提供されている通常番組の視聴以外のサービスを享受することができる。
例えば、オーディオ(楽曲)データのダウンロードサービス用のGUI画面を表示させて、このGUI画面を利用して操作を行えば、ユーザが希望した楽曲のオーディオデータをダウンロードしてストレージデバイス13に記録して保存することが可能になる。
【0025】
なお、本実施の形態では、上記したようなGUI画面に対する操作を伴う、通常の番組放送以外の特定のサービスを提供するデータサービス放送については、インタラクティブ性を有することもあり、「インタラクティブ放送」ともいうことにする。
【0026】
1−2.GUI画面に対する操作
ここで、上述しているインタラクティブ放送の利用例、つまり、GUI画面に対する操作例について、図3及び図4を参照して概略的に説明しておく。ここでは、楽曲データ(オーディオデータ)のダウンロードを行う場合について述べる。
【0027】
先ず、図3によりIRD12に対してユーザが操作を行うためのリモートコントローラ64の操作キーについて、特に主要なものについて説明しておく。
図3には、リモートコントローラ64において各種キーが配列された操作パネル面が示されている。ここでは、これら各種キーのうち、電源キー101、数字キー102、画面表示切換キー103、インタラクティブ切換キー104、EPGキーパネル部105、チャンネルキー106について説明する。
【0028】
電源キー101は、IRD12の電源のオン/オフを行うためのキーである。数字キー102は、数字指定によりチャンネル切り換えを行ったり、例えばGUI画面において数値入力操作が必要な場合に操作するためのキーである。
画面表示切換キー103は、例えば通常の放送画面とEPG画面との切り換えを行うキーである。例えば、画面表示切換キー103によりEPG画面を呼び出した状態の下で、EPGキーパネル部105に配置されたキーを操作すれば、電子番組ガイドの表示画面を利用した番組検索が行えることになる。また、EPGキーパネル部105内の矢印キー105aは、後述するサービス用のGUI画面におけるカーソル移動などにも使用することができる。
インタラクティブ切換キー104は、通常の放送画面と、その放送番組に付随したサービスのためのGUI画面との切り換えを行うために設けられる。
チャンネルキー106は、IRD12における選局チャンネルをそのチャンネル番号の昇順、降順に従って順次切り換えていくために設けられるキーである。
【0029】
なお、本実施の形態のリモートコントローラ64としては、例えばモニタ装置14に対する各種操作も可能に構成されているものとされ、これに対応した各種キーも設けられているものであるが、ここでは、モニタ装置14に対応するキー等の説明は省略する。
【0030】
次に、図4を参照してGUI画面に対する操作の具体例について説明する。
受信設備3により放送を受信して所望のチャンネルを選局すると、モニタ装置14の表示画面には、図4(a)に示すように、テレビ番組素材サーバ6から提供された番組素材に基づく動画像が表示される。つまり、通常の番組内容が表示される。ここでは、例えば音楽番組が表示されているものとする。また、この音楽番組には楽曲のオーディオデータのダウンロードサービス(インタラクティブ放送)が付随されているものとする。
そして、この音楽番組が表示されている状態の下で、例えばユーザがリモートコントローラ64のインタラクティブ切換キー104を操作したとすると、表示画面は図4(b)に示すような、オーディオデータのダウンロードのためのGUI画面に切り替わる。
【0031】
このGUI画面においては、先ず、画面の左上部のテレビ番組表示エリア21Aに対して、図4(a)にて表示されていたテレビ番組素材サーバ6からのビデオデータによる画像が縮小化されて表示される。
また、画面の右上部には、オーディオチャンネルで放送されている各チャンネルの楽曲のリスト21Bが表示される。また、画面の左下にはテキスト表示エリア21Cとジャケット表示エリア21Dが表示される。さらに、画面の右側には歌詞表示ボタン22、プロフィール表示ボタン23、情報表示ボタン24、予約録音ボタン25、予約済一覧表示ボタン26、録音履歴表示ボタン27、およびダウンロードボタン28が表示される。
【0032】
ユーザは、このリスト21Bに表示されている楽曲名を見ながら、興味のある楽曲を探していく。そして、興味のある楽曲を見つけたらリモートコントローラ64の矢印キー105a(EPGキーパネル部105内)を操作して、その楽曲が表示されている位置にカーソルを合わせた後、エンター操作を行う(例えば矢印キー105aのセンター位置を押圧操作する)。
これによって、カーソルを合わせた楽曲を試聴することができる。すなわち、各オーディオチャンネルでは、所定の単位時間中、同一の楽曲が繰り返し放送されているので、テレビ番組表示エリア21Aの画面はそのままで、IRD12により上記操作により選択された楽曲のオーディオチャンネルに切り換えて音声出力することで、その楽曲を聞くことができる。この時、ジャケット表示エリア21Dにはその楽曲のMDジャケットの静止画像が表示される
【0033】
また、例えば上記の状態で歌詞表示ボタン22にカーソルを合わせ、エンター操作を行う(以下、ボタン表示にカーソルを合わせ、エンター操作を行うことを「ボタンを押す」という)と、テキスト表示エリア21Cに楽曲の歌詞がオーディオデータと同期したタイミングで表示される。同様に、プロフィール表示ボタン23あるいは情報表示ボタン24を押すと、楽曲に対応するアーティストのプロフィールあるいはコンサート情報などがテキスト表示エリア21Cに表示される。このように、ユーザは、現在どのような楽曲が配信されているのかを知ることができ、更に各楽曲についての詳細な情報を知ることができる。
【0034】
ユーザは試聴した楽曲を購入したい場合には、ダウンロードボタン28を押す。ダウンロードボタン28が押されると、選択された楽曲のオーディオデータがダウンロードされ、ストレージデバイス13に記憶される。楽曲のオーディオデータと共に、その歌詞データ、アーティストのプロフィール情報、ジャケットの静止画データ等をダウンロードすることもできる。
そして、このようにして楽曲のオーディオデータがダウンロードされる毎に、その履歴情報がIRD12内のICカードに記憶される。ICカードに記憶された情報は、例えば1カ月に一度ずつ課金サーバ5により取り込みが行われ、ユーザに対してデータサービスの使用履歴に応じた課金が行われる。これによって、ダウンロードされる楽曲の著作権を保護することができることにもなる。
【0035】
また、ユーザは予めダウンロードの予約を行いたい場合には、予約録音ボタン25を押す。このボタンを押すと、GUI画面の表示が切り換わり、予約が可能な楽曲のリストが画面全体に表示される。例えばこのリストは1時間単位、1週間単位、チャンル単位等で検索した楽曲を表示することが可能である。ユーザはこのリストの中からダウンロードの予約を行いたい楽曲を選択すると、その情報がIRD12内に登録される。そして、すでにダウンロードの予約を行った楽曲を碓認したい場合には、予約済一覧表示ボタン26を押すことにより、画面全体に表示させることができる。このようにして予約された楽曲は、予約時刻になるとIRD12によりダウンロードされ、ストレージデバイス13に記憶される。
【0036】
ユーザはダウンロードを行った楽曲について確認したい場合には、録音履歴ボタン27を押すことにより、既にダウンロードを行った楽曲のリストを画面全体に表示させることができる。
【0037】
このように、本発明が適用されたシステムの受信設備3では、モニタ装置14のGUI画面上に楽曲のリストが表示される。そして、このGUI画面上の表示にしたがって楽曲を選択するとその楽曲を試聴することができ、その楽曲の歌詞やアーティストのプロフィール等を知ることができる。さらに、楽曲のダウンロードとその予約、ダウンロードの履歴や予約済楽曲リストの表示等を行うことができる。
【0038】
詳しいことは後述するが、上記図4(b)に示すようなGUI画面の表示と、GUI画面に対するユーザの操作に応答したGUI画面上での表示変更、及び音声出力は、前述したMHEG方式に基づいたシナリオ記述により、オブジェクトの関係を規定することにより実現される。ここでいうオブジェクトとは、図4(b)に示された各ボタンに対応するパーツとしての画像データや各表示エリアに表示される素材データとなる。
そして、本明細書においては、このGUI画面のような、シナリオ記述によってオブジェクト間の関係が規定されることで、或る目的に従った情報の出力態様(画像表示や音声出力等)が実現される環境を「シーン」というものとする。また、1シーンを形成するオブジェクトとしては、シナリオ記述のファイル自体も含まれるものとする。
【0039】
以上、説明したように、本発明が適用されたデジタル衛星放送システムでは放送番組が配信されると共に、複数のオーディオチャンネルを使用して楽曲のオーディオデータが配信される。そして、配信されている楽曲のリスト等を使用して所望の楽曲を探し、そのオーディオデータをストレージデバイス13に簡単に保存することができる。
なお、デジタル衛星放送システムにおける番組提供以外のサービスとしては、上記した楽曲データのダウンロードの他にも各種考えられる。例えば、いわゆるテレビショッピングといわれる商品紹介番組を放送した上で、GUI画面としては購買契約が結べるようなものを用意することも考えられる。
【0040】
1−3.地上局
これまで、本実施の形態としてのデジタル衛星放送システムの概要について説明したが、以降、このシステムについてより詳しい説明を行っていくこととする。そこで、先ず地上局1の構成について図5を参照して説明する。
【0041】
なお、以降の説明にあたっては、次のことを前提とする。
本実施の形態では、地上局1から衛星2を介しての受信設備3への送信を行うのにあたり、DSM−CC(デジタル蓄積メディア・コマンド・アンド・コントロール;Digital Strage Media-Command and Control)プロトコルを採用する。
DSM−CC(MPEG−part6)方式は、既に知られているように、例えば、何らかのネットワークを介して、デジタル蓄積メディア(DSM)に蓄積されたMPEG符号化ビットストリームを取り出し(Retrieve)たり、或いはDSMに対してストリームを蓄積(Store)するためのコマンドや制御方式を規定したものである。そして本実施の形態においては、このDSM−CC方式がデジタル衛星放送システムにおける伝送規格として採用されているものである。
そして、DSM−CC方式によりデータ放送サービス(例えばGUI画面など)のコンテンツ(オブジェクトの集合)を伝送するためには、コンテンツの記述形式を定義しておく必要がある。本実施の形態では、この記述形式の定義として先に述べたMHEGが採用されるものである。
【0042】
図5に示す地上局1の構成において、テレビ番組素材登録システム31は、テレビ番組素材サーバ6から得られた素材データをAVサーバ35に登録する。この素材データはテレビ番組送出システム39に送られ、ここでビデオデータは例えばMPEG2方式で圧縮され、オーディオデータは、例えばMPEG2オーディオ方式によりパケット化される。テレビ番組送出システム39の出力はマルチプレクサ45に送られる。
【0043】
また、楽曲素材登録システム32では、楽曲素材サーバ7からの素材データ、つまりオーディオデータを、MPEG2オーディオエンコーダ36A、及びATRACエンコーダ36Bに供給する。MPEG2オーディオエンコーダ36A、ATRACエンコーダ36Bでは、それぞれ供給されたオーディオデータについてエンコード処理(圧縮符号化)を行った後、MPEGオーディオサーバ40A及びATRACオーディオサーバ40Bに登録させる。
MPEGオーディオサーバ40Aに登録されたMPEGオーディオデータは、MPEGオーディオ送出システム43Aに伝送されてここでパケット化された後、マルチプレクサ45に伝送される。ATRACオーディオサーバ40Bに登録されたATRACデータは、ATRACオーディオ送出システム43Bに4倍速ATRACデータとして送られ、ここでパケット化されてマルチプレクサ45に送出される。
【0044】
また、音声付加情報登録システム33では、音声付加情報サーバ8からの素材データである音声付加情報を音声付加情報データベース37に登録する。この音声付加情報データベース37に登録された音声付加情報は、音声付加情報送出システム41に伝送され、同様にして、ここでパケット化されてマルチプレクサ45に伝送される。
【0045】
また、GUI用素材登録システム34では、GUIデータサーバ9からの素材データであるGUIデータを、GUI素材データベース38に登録する。
【0046】
GUI素材データベース38に登録されたGUI素材データは、GUIオーサリングシステム42に伝送され、ここで、GUI画面、即ち図4にて述べた「シーン」としての出力が可能なデータ形式となるように処理が施される。
【0047】
つまり、GUIオーサリングシステム42に伝送されてくるデータとしては、例えば、楽曲のダウンロードのためのGUI画面であれば、アルバムジャケットの静止画像データ、歌詞などのテキストデータ、更には、操作に応じて出力されるべき音声データなどである。
上記した各データはいわゆるモノメディアといわれるが、GUIオーサリングシステム42では、MHEGオーサリングツールを用いて、これらのモノメディアデータを符号化して、これをオブジェクトとして扱うようにする。
そして、例えば図4(b)にて説明したようなシーン(GUI画面)の表示態様と操作に応じた画像音声の出力態様が得られるように上記オブジェクトの関係を規定したシナリオ記述ファイル(スクリプト)と共にMHEG−5のコンテンツを作成する。
また、図4(b)に示したようなGUI画面では、テレビ番組素材サーバ6の素材データを基とする画像・音声データ(MPEGビデオデータ、MPEGオーディオデータ)と、楽曲素材サーバ7の楽曲素材データを基とするMPEGオーディオデータ等も、GUI画面に表示され、操作に応じた出力態様が与えられる。
従って、上記シナリオ記述ファイルとしては、上記GUIオーサリングシステム42では、上記したテレビ番組素材サーバ6の素材データを基とする画像・音声データ、楽曲素材サーバ7の楽曲素材データを基とするMPEGオーディオデータ、更には、音声付加情報サーバ8を基とする音声付加情報も必要に応じてオブジェクトとして扱われて、MHEGのスクリプトによる規定が行われる。
【0048】
なお、GUIオーサリングシステム42から伝送されるMHEGコンテンツのデータとしては、スクリプトファイル、及びオブジェクトとしての各種静止画データファイルやテキストデータファイルなどとなるが、静止画データは、例えばJPEG(Joint Photograph Experts Group)方式で圧縮された640×480ピクセルのデータとされ、テキストデータは例えば800文字以内のファイルとされる。
【0049】
GUIオーサリングシステム42にて得られたMHEGコンテンツのデータはDSM−CCエンコーダ44に伝送される。
DSM−CCエンコーダ44では、MPEG2フォーマットに従ったビデオ、オーディオデータのデータストリームに多重できる形式のトランスポートストリーム(以下TS(Transport Stream)とも略す)に変換して、パケット化されてマルチプレクサ45に出力される。
【0050】
マルチプレクサ45においては、テレビ番組送出システム39からのビデオパケットおよびオーディオパケットと、MPEGオーディオ送出システム43Aからのオーディオパケットと、ATRACオーディオ送出システム43Bからの4倍速オーディオパケットと、音声付加情報送出システム41からの音声付加情報パケットと、GUIオーサリングシステム42からのGUIデータパケットとが時間軸多重化されると共に、キー情報サーバ10(図1)から出力されたキー情報に基づいて暗号化される。
【0051】
マルチプレクサ45の出力は電波送出システム46に伝送され、ここで例えば誤り訂正符号の付加、変調、及び周波数変換などの処理を施された後、アンテナから衛星2に向けて送信出力するようにされる。
【0052】
1−4.送信フォーマット
次に、DSM−CC方式に基づいて規定された本実施の形態の送信フォーマットについて説明する。
図6は、地上局1から衛星2に送信出力される際のデータの一例を示している。なお、前述したように、この図に示す各データは実際には時間軸多重化されているものである。また、この図では、図6に示すように、時刻t1から時刻t2の間が1つのイベントとされ、時刻t2から次のイベントとされる。ここでいうイベントとは、例えば音楽番組のチャンネルであれば、複数楽曲のラインナップの組を変更する単位であり、時間的には30分或いは1時間程度となる。
【0053】
図6に示すように、時刻t1から時刻t2のイベントでは、通常の動画の番組放送で、所定の内容A1を有する番組が放送されている。また、時刻t2から始めるイベントでは、内容A2としての番組が放送されている。この通常の番組で放送されているのは動画と音声である。
【0054】
MPEGオーディオチャンネル(1)〜(10)は、例えば、チャンネルCH1からCH10の10チャンネル分用意される。このとき、各オーディオチャンネルCH1,CH2,CH3・・・・CH10では、1つのイベントが放送されている間は同一楽曲が繰り返し送信される。つまり、時刻t1〜t2のイベントの期間においては、オーディオチャンネルCH1では楽曲B1が繰り返し送信され、オーディオチャンネルCH2では楽曲C1が繰り返し送信され、以下同様に、オーディオチャンネルCH10では楽曲K1が繰り返し送信されることになる。これは、その下に示されている4倍速ATRACオーディオチャンネル(1)〜(10)についても共通である。
【0055】
つまり、図6において、MPEGオーディオチャンネルと4倍速ATRACオーディオチャンネルのチャンネル番号である( )内の数字が同じものは同じ楽曲となる。また、音声付加情報のチャンネル番号である( )内の数字は、同じチャンネル番号を有するオーディオデータに付加されている音声付加情報である。更に、GUIデータとして伝送される静止画データやテキストデータも各チャンネルごとに形成されるものである。これらのデータは、図7(a)〜(d)に示すようにMPEG2のトランスポートパケット内で時分割多重されて送信され、図7(e)〜(h)に示すようにしてIRD12内では各データパケットのヘッダ情報を用いて再構築される。
【0056】
また、上記図6及び図7に示した送信データのうち、少なくとも、データサービス(インタラクティブ放送)に利用されるGUIデータは、DSM−CC方式に則って論理的には次のようにして形成されるものである。ここでは、DSM−CCエンコーダ44から出力されるトランスポートストリームのデータに限定して説明する。
【0057】
図8(a)に示すように、DSM−CC方式によって伝送される本実施の形態のデータ放送サービスは、Service Gatewayという名称のルートディレクトリの中に全て含まれる。Service Gatewayに含まれるオブジェクトとしては、ディレクトリ(Directory),ファイル(File),ストリーム(Stream),ストリームイベント(Stream Event)などの種類が存在する。
【0058】
これらのうち、ファイルは静止画像、音声、テキスト、更にはMHEGにより記述されたスクリプトなどの個々のデータファイルとされる。
ストリームは例えば、他のデータサービスやAVストリーム(TV番組素材としてのMPEGビデオデータ、オーディオデータ、楽曲素材としてのMPEGオーディオデータ、ATRACオーディオデータ等)にリンクする情報が含まれる。
また、ストリームイベントは、同じくリンクの情報と時刻情報が含まれる。
ディレクトリは相互に関連するデータをまとめるフォルダである。
【0059】
そして、DSM−CC方式では、図8(b)に示すようにして、これらの単位情報とService Gatewayをそれぞれオブジェクトという単位と捉え、それぞれをBIOPメッセージという形式に変換する。
なお、本発明に関わる説明では、ファイル,ストリーム,ストリームイベントの3つのオブジェクトの区別は本質的なものではないので、以下の説明ではこれらをファイルとしてのオブジェクトに代表させて説明する。
【0060】
そして、DSM−CC方式では、図8(c)に示すモジュールといわれるデータ単位を生成する。このモジュールは、図8(b)に示したBIOPメッセージ化されたオブジェクトを1つ以上含むようにされたうえで、BIOPヘッダが付加されて形成される可変長のデータ単位であり、後述する受信側における受信データのバッファリング単位となる。
また、DSM−CC方式としては、1モジュールを複数のオブジェクトにより形成する場合の、オブジェクト間の関係については特に規定、制限はされていない。つまり、極端なことをいえば、全く関係の無いシーン間における2以上のオブジェクトにより1モジュールを形成したとしても、DSM−CC方式のもとでの規定に何ら違反するものではない。
【0061】
このモジュールは、MPEG2フォーマットにより規定されるセクションといわれる形式で伝送するために、図8(d)に示すように、機械的に「ブロック」といわれる原則固定長のデータ単位に分割される。但し、モジュールにおける最後のブロックについては規定の固定長である必要はないものとされている。このように、ブロック分割を行うのはMPEG2フォーマットにおいて、1セクションが4KBを越えてはならないという規定があることに起因する。
また、この場合には上記ブロックとしてのデータ単位と、セクションとは同義なものとなる。
【0062】
このようにしてモジュールを分割して得たブロックは、図8(e)に示すようにしてヘッダが付加されてDDB(Download Data Block)というメッセージの形式に変換される。
【0063】
また、上記DDBへの変換と並行して、DSI(Download Server Initiate)及びDII(Download Indication Information)という制御メッセージが生成される。
上記DSI及びDIIは、受信側(IRD12)で受信データからモジュールを取得する際に必要となる情報であり、DSIは主として、次に説明するカルーセル(モジュール)の識別子、カルーセル全体に関連する情報(カルーセルが1回転する時間、カルーセル回転のタイムアウト値)等の情報を有する。また、データサービスのルートディレクトリ(Service Gateway)の所在を知るための情報も有する(オブジェクトカルーセル方式の場合)。
【0064】
DIIは、カルーセルに含まれるモジュールごとに対応する情報であり、モジュールごとのサイズ、バージョン、そのモジュールのタイムアウト値などの情報を有する。
【0065】
そして、図8(f)に示すように、上記DDB、DSI、DIIの3種類のメッセージをセクションのデータ単位に対応させて周期的に、かつ、繰り返し送出するようにされる。これにより、受信機側では例えば目的のGUI画面(シーン)を得るのに必要なオブジェクトが含まれているモジュールをいつでも受信できるようにされる。
本明細書では、このような伝送方式を回転木馬に例えて「カルーセル方式」といい、図8(f)に示すようにして模式的に表されるデータ伝送形態をカルーセルというものとする。
ここで、1カルーセルに含まれるモジュールとしては複数とされて構わない。例えば、1カルーセルにより1つのデータサービスに必要な複数のモジュールを伝送するようにしてもよいものである。
また、「カルーセル方式」としては、「データカルーセル方式」のレベルと「オブジェクトカルーセル方式」のレベルとに分けられる。特にオブジェクトカルーセル方式では、ファイル、ディレクトリ、ストリーム、サービスゲートウェイなどの属性を持つオブジェクトをデータとしてカルーセルを用いて転送する方式で、ディレクトリ構造を扱えることがデータカルーセル方式と大きく異なる。本実施の形態のシステムでは、オブジェクトカルーセル方式を採用するものとされる。
【0066】
また、図9に、MHEG方式に則ったデータサービスとしてのファイル(MHEG application file)のディレクトリ構造例を示す。上述のようにオブジェクトカルーセル方式は、このディレクトリ構造を扱えることに特徴を有する。
通常、Service Domainの入り口となる(MHEG application file)は、必ず、Service Gatewayの直下にある、app0/startupというファイルとなる。
基本的には、Service Domain(Service Gateway)の下にapplication directory(app0,app1・・・appN)があり、その下にstartupといわれるアプリケーション・ファイルと、applicationを構成する各sceneのdirectory(scene0,scene1・・・)があるようにされる。更にscene directoryの下には、MHEG scene fileとsceneを構成する各content fileがおかれることとしている。
【0067】
また、上記のようにしてカルーセルにより送信されるGUIデータ、つまり、図5のDSM−CCエンコーダ44から出力されるデータとしては、トランスポートストリームの形態により出力される。このトランスポートストリームは例えば図10に示す構造を有する。
図10(a)には、トランスポートストリームが示されている。このトランスポートストリームとはMPEGシステムで定義されているビット列であり、図のように188バイトの固定長パケット(トランスポートパケット)の連結により形成される。
【0068】
そして、各トランスポートパケットは、図10(b)に示すようにヘッダと特定の個別パケットに付加情報を含めるためのアダプテーションフィールドとパケットの内容(ビデオ/オーディオデータ等)を表すペイロード(データ領域)とからなる。
【0069】
ヘッダは、例えば実際には4バイトとされ、図10(c)に示すように、先頭には必ず同期バイトがあるようにされ、これより後ろの所定位置にそのパケットの識別情報であるPID(Packet_ID)、スクランブルの有無を示すスクランブル制御情報、後続するアダプテーションフィールドやペイロードの有無等を示すアダプテーションフィールド制御情報が格納されている。
【0070】
これらの制御情報に基づいて、受信装置側ではパケット単位でデスクランブルを行い、また、デマルチプレクサによりビデオ/オーディオ/データ等の必要パケットの分離・抽出を行うことができる。また、ビデオ/オーディオの同期再生の基準となる時刻情報を再生することもここで行うことができる。
【0071】
また、これまでの説明から分かるように、1つのトランスポートストリームには複数チャンネル分の映像/音声/データのパケットが多重されているが、それ以外にPSI(Program Specific Information)といわれる選局を司るための信号や、限定受信(個人の契約状況により有料チャンネルの受信可不可を決定する受信機能)に必要な情報(EMM/ECM)、EPGなどのサービスを実現するためのSI(Service Information)が同時に多重されている。ここでは、PSIについて説明する。
【0072】
PSIは、図11に示すようにして、4つのテーブルで構成されている。それぞれのテーブルは、セクション形式というMPEG Systemに準拠した形式で表されている。
図11(a)には、NIT(Network Informataion Table)及びCAT(Conditional Access Table)のテーブルが示されている。
NITは、全キャリアに同一内容が多重されている。キャリアごとの伝送諸元(偏波面、キャリア周波数、畳み込みレート等)と、そこに多重されているチャンネルのリストが記述されている。NITのPIDとしては、PID=0x0010とされている。
【0073】
CATもまた、全キャリアに同一内容が多重される。限定受信方式の識別と契約情報等の個別情報であるEMM(Entitlement Management Message)パケットのPIDが記述されている。PIDとしては、PID=0x0001により示される。
【0074】
図11(b)には、キャリアごとに固有の内容を有する情報として、PATが示される。PATには、そのキャリア内のチャンネル情報と、各チャンネルの内容を表すPMTのPIDが記述されている。PIDとしては、PID=0x0000により示される。
【0075】
また、キャリアにおけるチャンネルごとの情報として、図11(c)に示すPMT(Program Map Table)のテーブルを有する。
PMTは、チャンネル別の内容が多重されている。例えば、図11(d)に示すような、各チャンネルを構成するコンポーネント(ビデオ/オーディオ等)と、デスクランブルに必要なECM(Encryption Control Message)パケットのPIDが記述されているPMTのPIDは、PATにより指定される。
【0076】
1−5.IRD
続いて、受信設備3に備えられるIRD12の一構成例について図12を参照して説明する。
【0077】
この図に示すIRD12において、入力端子T1には、パラボラアンテナ11のLNB15により所定の周波数に変換された受信信号を入力してチューナ/フロントエンド部51に供給する。
チューナ/フロントエンド部51では、CPU(Central Processing Unit)80からの伝送諸元等を設定した設定信号に基づいて、この設定信号により決定されるキャリア(受信周波数)を受信して、例えばビタビ復調処理や誤り訂正処理等を施すことで、トランスポートストリームを得るようにされる。
チューナ/フロントエンド部51にて得られたトランスポートストリームは、デスクランブラ52に対して供給される。また、チューナ/フロントエンド部51では、トランスポートストリームからPSIのパケットを取得し、その選局情報を更新すると共に、トランスポートストリームにおける各チャンネルのコンポーネントPIDを得て、例えばCPU80に伝送する。CPU80では、取得したPIDを受信信号処理に利用することになる。
【0078】
デスクランブラ52では、ICカード65に記憶されているデスクランブルキーデータをCPU80を介して受け取ると共に、CPU80によりPIDが設定される。そして、このデスクランブルキーデータとPIDとに基づいてデスクランブル処理を実行し、トランスポート部53に対して伝送する。
【0079】
トランスポート部53は、デマルチプレクサ70と、例えばDRAM等により構成されるキュー(Queue)71とからなる。キュー(Queue)71は、モジュール単位に対応した複数のメモリ領域が列となるようにして形成されているものとされ、例えば本実施の形態では、32列のメモリ領域が備えられる。つまり、最大で32モジュールの情報を同時に格納することができる。
【0080】
デマルチプレクサ70の概略的動作としては、CPU80のDeMUXドライバ82により設定されたフィルタ条件に従って、デスクランブラ52から供給されたトランスポートストリームから必要なトランスポートパケットを分離し、必要があればキュー71を作業領域として利用して、先に図7(e)〜(h)により示したような形式のデータを得て、それぞれ必要な機能回路部に対して供給する。
デマルチプレクサ70にて分離されたMPEGビデオデータは、MPEG2ビデオデコーダ55に対して入力され、MPEGオーディオデータは、MPEGオーディオデコーダ54に対して入力される。これらデマルチプレクサ70により分離されたMPEGビデオ/オーディオデータの個別パケットは、PES(Packetized Elementary Stream)と呼ばれる形式でそれぞれのデコーダに入力される。
【0081】
また、トランスポートストリームにおけるMHEGコンテンツのデータについては、デマルチプレクサ70によりトランスポートストリームからトランスポートパケット単位で分離抽出されながらキュー71の所要のメモリ領域に書き込まれていくことで、モジュール単位にまとめられるようにして形成される。そして、このモジュール単位にまとめられたMHEGコンテンツのデータは、CPU80の制御によってデータバスを介して、メインメモリ90内のDSM−CCバッファ91に書き込まれて保持される。
【0082】
また、トランスポートストリームにおける4倍速ATRACデータ(圧縮オーディオデータ)も、例えばトランスポートパケット単位で必要なデータがデマルチプレクサ70により分離抽出されてIEEE1394インターフェイス60に対して出力される。また、IEEE1394インターフェイス60を介した場合には、オーディオディオデータの他、ビデオデータ及び各種コマンド信号等を送出することも可能とされる。
【0083】
PESとしての形式によるMPEGビデオデータが入力されたMPEG2ビデオデコーダ55では、メモリ55Aを作業領域として利用しながらMPEG2フォーマットに従って復号化処理を施す。復号化されたビデオデータは、表示処理部58に供給される。
【0084】
表示処理部58には、上記MPEG2ビデオデコーダ55から入力されたビデオデータと、後述するようにしてメインメモリ90のMHEGバッファ92にて得られるデータサービス用のGUI画面等のビデオデータが入力される。表示処理部58では、このようにして入力されたビデオデータについて所要の信号処理を施して、所定のテレビジョン方式によるアナログオーディオ信号に変換してアナログビデオ出力端子T2に対して出力する。
これにより、アナログビデオ出力端子T2とモニタ装置14のビデオ入力端子とを接続することで、例えば先に図4に示したような表示が行われる。
【0085】
また、PESによるMPEGオーディオデータが入力されるMPEG2オーディオデコーダ54では、メモリ54Aを作業領域として利用しながらMPEG2フォーマットに従って復号化処理を施す。復号化されたオーディオデータは、D/Aコンバータ56及び光デジタル出力インターフェイス59に対して供給される。
【0086】
D/Aコンバータ56では、入力されたオーディオデータについてアナログ音声信号に変換してスイッチ回路57に出力する。スイッチ回路57では、アナログオーディオ出力端子T3又はT4の何れか一方に対してアナログ音声信号を出力するように信号経路の切換を行う。
ここでは、アナログオーディオ出力端子T3はモニタ装置14の音声入力端子と接続されるために設けられているものとされる。また、アナログオーディオ出力端子T4はダウンロードした楽曲をアナログ信号により出力するための端子とされる。
また、光デジタル出力インターフェイス59では、入力されたデジタルオーディオデータを光デジタル信号に変換して出力する。この場合、光デジタル出力インターフェイス59は、例えばIEC958に準拠する。
【0087】
メインメモリ90は、CPU80が各種制御処理を行う際の作業領域として利用されるものである。そして、本実施の形態では、このメインメモリ90において、前述したDSM−CCバッファ91と、MHEGバッファ92としての領域が割り当てられるようになっている。
MHEGバッファ92には、MHEG方式によるスクリプトの記述に従って生成された画像データ(例えばGUI画面の画像データ)を生成するための作業領域とされ、ここで生成された画像データはバスラインを介して表示処理部58に供給される。
【0088】
CPU80は、IRD12における全体制御を実行する。このなかには、デマルチプレクサ70におけるデータ分離抽出についての制御も含まれる。
また、獲得したMHEGコンテンツのデータについてデコード処理を施すことで、スクリプトの記述内容に従ってGUI画面(シーン)を構成して出力するための処理も実行する。
【0089】
このため、本実施の形態のCPU80としては、主たる制御処理を実行する制御処理部81に加え、例えば少なくとも、DeMUXドライバ82、DSM−CCデコーダブロック83、及びMHEGデコーダブロック84が備えられる。本実施の形態では、このうち、少なくともDSM−CCデコーダブロック83及びMHEGデコーダブロック84については、ソフトウェアにより構成される。
DeMUXドライバ82は、入力されたトランスポートストリームのPIDに基づいてデマルチプレクサ70におけるフィルタ条件を設定する。
DSM−CCデコーダブロック83は、DSM−Managerとしての機能を有するものであり、DSM−CCバッファ91に格納されているモジュール単位のデータについて、MHEGコンテンツのデータに再構築する。また、MHEGデコーダブロック84からのアクセスに従って所要のDSM−CCデコード等に関連する処理を実行する。
【0090】
MHEGデコーダブロック84は、DSM−CCデコーダブロック83により得られたMHEGコンテンツのデータ、つまり、DSM−CCバッファ91にて得られているMHEGコンテンツのデータにアクセスして、シーン出力のためのデコード処理を行う。つまり、そのMHEGコンテンツのスクリプトファイルにより規定されているオブジェクト間の関係を実現していくことで、シーンを形成するものである。この際、シーンとしてGUI画面を形成するのにあたっては、MHEGバッファ92を利用して、ここで、スクリプトファイルの内容に従ってGUI画面の画像データを生成するようにされる。
【0091】
DSM−CCデコーダブロック83及びMHEGデコーダブロック84間のインターフェイスには、U−U API(DSM−CC U−U API(Applivation Portability Interface))が採用される。
U−U APIは、例えばクライアント(MHEGデコーダブロック84)側がDSM Managerオブジェクト(DSMの機能を実現するサーバオブジェクト;DSM−CCデコーダブロック83)にアクセスするためのインターフェイスであり、カルーセルに含まれるService Gateway,Directory,File,Stream,Stream Eventなどの属性を有するオブジェクトをファイルシステムのようにして構造的にアクセスすることができるようにしたAPIとされる。
【0092】
このAPIを通じてカルーセルに含まれるオブジェクトへのアクセスを行うことで、カルーセルを使用するプログラム(クライアント)がカルーセル受信動作を関知することなく、バス名を使用してオブジェクトにアクセスすることが可能になる。
【0093】
また、このU−U APIは、下層のデータ転送方式に関わらず利用することが出来るように規定されたインターフェイスの集合であることから、このAPIを利用するプログラムは、U−U APIを提供するどのようなデータ転送方式においても利用できるという利点を有する。
【0094】
ここで、CPU80の制御によりトランスポートストリームから1シーンを形成するのに必要な目的のオブジェクトを抽出するための動作例について説明しておく。
【0095】
DSM−CCでは、トランスポートストリーム中のオブジェクトの所在を示すのにIOR(Interoperable Object Reference)が使用される。IORには、オブジェクトを見つけ出すための力ルーセルに対応する識別子、オブジェクトの含まれるモジュールの識別子(以下module_idと表記)、1つのモジュール中でオブジェクトを特定する識別子(以下object_keyと表記)のほかに、オブジェクトの含まれるモジュールの情報を持つDIIを識別するためのタグ(association_tag)情報を含んでいる。
また、モジュール情報を持つDIIには、1つ以上のモジュールそれぞれについてのmodule_id、モジュールの大きさ、バージョンといった情報と、そのモジュールを識別するためのタグ(association_tag)情報を含んでいる。
【0096】
トランスポートストリームから抜き出されたIORがCPU80において識別された場合に、そのIORで示されたオブジェクトを受信、分離して得るプロセスは、例えば次のようになる。
(Pr1) CPU80のDeMUXドライバ82では、IORのassociation_tagと同じ値を持つエレメンタリーストリーム(以下ESと表記)を、カルーセルにおけるPMTのESループから探し出してPIDを得る。このPIDを持つESにDIIが含まれていることになる。
(Pr2) このPIDとtable_id_extensionとをフィルタ条件としてデマルチプレクサ70に対して設定する。これにより、デマルチプレクサ70では、DIIを分離してCPU80に対して出力する。
(Pr3) DIIの中で、先のIORに含まれていたmodule_idに相当するモジュールのassociation_tagを得る。
(Pr4) 上記association_tagと同じ値を有するESを、PMTのESループ(カルーセル)から探し出し、PIDを得る。このPIDを有するESに目的とするモジュールが含まれる。
(Pr5) 上記PIDとmodule_idとをフィルタ条件として設定して、デマルチプレクサ70によるフィルタリングを行う。このフィルタ条件に適合して分離抽出されたトランスポートパケットがキュー71の所要のメモリ領域(列)に格納されていくことで、最終的には、目的のモジュールが形成される。
(Pr6) 先のIORに含まれていたobject_keyに相当するオブジェクトをこのモジュールから抜き出す。これが目的とするオブジェクトになる。このモジュールから抜き出されたオブジェクトは、例えば、DSM−CCバッファ91の所定の領域に書き込みが行われる。
例えば、上記動作を繰り返し、目的とするオブジェクトを集めてDSM−CCバッファ91に格納していくことで、必要とされるシーンを形成するMHEGコンテンツが得られることになる。
【0097】
マンマシンインターフェイス61では、リモートコントローラ64から送信されてきたコマンド信号を受信してCPU80に対して伝送する。CPU80では、受信したコマンド信号に応じた機器の動作が得られるように、所要の制御処理を実行する。
【0098】
ICカードスロット62にはICカード65が挿入される。そして、この挿入されたICカード65に対してCPU80によって情報の書き込み及び読み出しが行われる。
【0099】
モデム63は、電話回線4を介して課金サーバ5と接続されており、CPU80の制御によってIRD12と課金サーバ5との通信が行われるように制御される。
【0100】
ここで、上記構成によるIRD12におけるビデオ/オーディオソースの信号の流れを、図4により説明した表示形態に照らし合わせながら補足的に説明する。
図4(a)に示すようにして、通常の番組を出力する場合には、入力されたトランスポートストリームから必要な番組のMPEGビデオデータとMPEGオーディオデータとが抽出されて、それぞれ復号化処理が施される。そして、このビデオデータとMPEGオーディオデータが、それぞれアナログビデオ出力端子T2と、アナログオーディオ出力端子T3に出力されることで、モニタ装置14では、放送番組の画像表示と音声出力が行われる。
【0101】
また、図4(b)に示したGUI画面を出力する場合には、入力されたトランスポートストリームから、このGUI画面(シーン)に必要なMHEGコンテンツのデータをトランスポート部53により分離抽出してDSM−CCバッファ91に取り込む。そして、このデータを利用して、前述したようにDSM−CCデコーダブロック83及びMHEGデコーダブロック84が機能することで、MHEGバッファ92にてシーン(GUI画面)の画像データが作成される。そして、この画像データが表示処理部58を介してアナログビデオ出力端子T2に供給されることで、モニタ装置14にはGUI画面の表示が行われる。
【0102】
また、図4(b)に示したGUI画面上で楽曲のリスト21Bにより楽曲が選択され、その楽曲のオーディオデータを試聴する場合には、この楽曲のMPEGオーディオデータがデマルチプレクサ70により得られる。そして、このMPEGオーディオデータが、MPEGオーディオデコーダ54、D/Aコンバータ、スイッチ回路57、アナログオーディオ出力端子T3を介してアナログ音声信号とされてモニタ装置14に対して出力される。
【0103】
また、図4(b)に示したGUI画面上でダウンロードボタン28が押されてオーディオデータをダウンロードする場合には、ダウンロードすべき楽曲のオーディオデータがデマルチプレクサ70により抽出されてアナログオーディオ出力端子T4、光デジタル出力インターフェイス59、またはIEEE1394インターフェイス60に出力される。
【0104】
ここで、特にIEEE1394インターフェイス60に対して、図2に示したIEEE1394対応のMDレコーダ/プレーヤ13Aが接続されている場合には、デマルチプレクサ70ではダウンロード楽曲の4倍速ATRACデータが抽出され、IEEE1394インターフェイス60を介してMDレコーダ/プレーヤ13Aに装填されているディスクに対して記録が行われる。また、この際には、例えばJPEG方式で圧縮されたアルバムジャケットの静止画データ、歌詞やアーティストのプロフィールなどのテキストデータもデマルチプレクサ70においてトランスポートストリームから抽出され、IEEE1394インターフェイス60を介してMDレコーダ/プレーヤ13Aに転送される。MDレコーダ/プレーヤ13Aでは、装填されているディスクの所定の領域に対して、これら静止画データ、テキストデータを記録することができるようになっている。
【0105】
2.本発明に至った背景
例えば、オブジェクトカルーセル方式によるデジタルデータ放送の受信を行っている場合、その放送中においてカルーセルの内容(放送内容)が切り換えられたとすると、その時点で、切り換え前のそのカルーセルのデータは無効となり、新しい内容のカルーセルにアクセスすることが可能な状態となる。なお、カルーセルを形成するデータ単位としては、例えば図6に示した1イベントに相当するデータとされている。
【0106】
但し、DSM−CC方式においては、カルーセルの内容が切り換わったタイミングでこれをクライアント側に通知するインターフェイスを備えていない。つまり、IRD12の場合であれば、DSM−CCデコーダブロック83側の受信データにおいて、カルーセルの内容切り換えがあったとしても、これを直ちにMHEGデコーダブロック84側が知ることが出来ない。
【0107】
ここで、クライアントが、現在シーン表示に使用しているカルーセルの内容切り換えを通知されないまま、次にそのカルーセルをサーバから読み出したような場合、以前のカルーセルとは異なるデータが読み出されて、このカルーセルにより表示が行われてしまうことになる。例えば、カルーセルの内容切り換えに関わらず以前の表示状態を維持したいような場合には、このようなクライアント側の動作では不都合を招くことになる。これは、例えばユーザが楽曲などの購買を行うことが可能とされる放送を視聴している状態で、購買に関わる入力操作等を行っているときに、カルーセルの内容が切り換わってしまった場合などが挙げられる。すなわち、カルーセルの内容が切り換わった時点でそれまで行っていた購買操作が無効になり、購買が不成立となってしまう。
また、逆にカルーセルの内容切り換えに対応して、現在のシーン表示の一部の内容を変更する必要が在るような場合には、或る機会でもってその切り換わったカルーセルをサーバから読み出すまでは、シーンの表示が変更されないことになる。つまり、実際のカルーセルの内容切り換えのタイミングに対して、シーンの表示内容を切り換えるタイミングが遅れることになる。
このようにして、クライアントがカルーセルの内容切り換えを通知されないことで、何らかの不都合が生じることになる。
【0108】
3.本実施の形態のカルーセル切り換え新通知制御
3−1.U−U APIの一般的処理
そこで、本実施の形態では、以降説明するようにして、クライアント(MHEGデコーダブロック84)側においてカルーセルの内容切り換えを知ることが出来るようにして、これに対応した適切なMHEGデコード処理が得られるようにすることを目的とするものである。また、このようなカルーセルの内容切り換えの通知のためのインターフェイスとしては、U−U APIに準拠させるように構成されるものである。
【0109】
ここで、本実施の形態としての内容切り換え通知のためのインターフェイスを説明するのに先だって、図15により、U−U APIのインターフェイスの一般的な一例を説明しておく。
ここでは、クライアントであるMHEGデコーダブロック84が、ストリーム再生を行う場合を例に挙げている。この図において○内に示す数は、MHEGデコーダブロック84及びDSM−CCデコーダブロック83の処理手順を示すものである。以下、この処理手順に従って説明を行う。また、以降の説明においては、MHEGデコーダブロック84をクライアント、DSM−CCデコーダブロック83についてはサーバということにする。
【0110】
(処理1) クライアントは、所要のタイミングでEvent::Subscribe(″stream on″)をサーバに対して伝送する。
Event::Subscribe(″stream on″)は、以降において、″stream on″イベントを受け取ることをサーバに宣言するインターフェイスである。
【0111】
(処理2) Event::Subscribe(″stream on″)が受信されると、サーバでは、stream onイベントに対応するイベント番号を返す。ここでは、Event#10を設定してクライアントに対して伝送している。
【0112】
(処理3) クライアントでは、イベント番号を獲得したら、Event::notifyをサーバへ出力する。
Event::notifyとは、クライアント側からサーバ側に対して、サーバ側において、何らかのイベントの発生があれば、その通知を要求するインターフェイスである。
【0113】
(処理4) 上記(処理3)のnotifyに対する応答処理として、図15のようにして或るタイミングで受信データにおいて″stream on″イベントが発生したら、サーバは、″stream on″イベントに対して設定したイベント番号であるEvent#10をクライアントに伝送する。
(処理5) クライアントでは、受信した上記Event#10により、″stream on″イベントが発生したことを知ることになる。そして、この場合には例えばストリーム再生のためのMHEGデコード処理を実行する。
【0114】
3−2.第1例
次に、上記図15に示したU−U APIインターフェイスに基づく本実施の形態のカルーセル切り換え通知制御について説明する。
前述のように、DSM−CCではカルーセルの内容切り換えがあったことを、そのタイミングでクライアントに知らせるための情報を有してはいない。また、切り換えられたカルーセルを直接的に識別可能な情報も伝送はされない。つまり、現状では、クライアント側は受信したカルーセルの内容が切り換わったタイミングを知ることは出来ない。
【0115】
但し、DSM−CCでは、カルーセルの内容切り換えが行われた場合、これが図8にて説明したDSIの内容に反映される。即ち、DSIにおけるカルーセルの内容に関する情報が変更される。本実施の形態ではこれを利用する。
【0116】
そして、本実施の形態のカルーセル切り換え通知制御として、その第1例においては、U−U APIのインターフェイスとして″DSI_CHANGED″イベントを追加する。この″DSI_CHANGED″イベントは、サーバ側において、その内容が変更された新規のDSIメッセージを受信したことを意味する。そして、図13の(処理1)〜(処理4)に示すようにしてカルーセルの切り換え通知制御を実行する。
【0117】
(処理1) クライアントは、Event::Subscribe(″DSI_CHANGED″)をサーバに伝達する。
(処理2) Event::Subscribe(″DSI_CHANGED″)を受信したサーバは、″DSI_CHANGED″イベントに対して設定したイベント番号をクライアントに返す。ここでは、″DSI_CHANGED″イベントに対してEvent#1を設定して返している。
【0118】
(処理3) 上記イベント番号を獲得した後、クライアントは、Event::notifyをサーバに伝送し、″DSI_CHANGED″を含む何らかのイベントが発生したらこれを通知する要求を行う。
(処理4) サーバでは、受信したカルーセルのデータに含まれるDSIを保持しているようにされる。そして、上記Event::notifyを受けた後の或るタイミングで、受信したカルーセルのデータに含まれるDSIが変更されたとする。これは、そのDSIが示すカルーセルの内容切り換えがあったことを意味する。
このようにして、DSIの変更があった、つまり″DSI_CHANGED″イベントが発生すると、サーバでは、(処理3)のEvent::notifyに対する応答として、″DSI_CHANGED″イベントに対して設定したイベント番号(Event#1)をクライアントに伝送するようにされる。
【0119】
これにより、クライアントでは、少なくとも現在放送中のデータサービスにおいてカルーセルの切り換えがあったことをほぼリアルタイムで知ることが出来る。 そして、この通知に従って、(処理5)としてカルーセルの内容切り換えに対応した、何らかの適切なMHEGデコード処理(シーンに関する出力制御等)を実行することが可能になる。図13に示す例では、クライアントとしてはDSIが変更した時点でカルーセル2のデータを利用した処理を開始することができるようになる。
具体的には、受信したカルーセルは受信されて所要の処理を経た後に、順次図12に示したDSM−CCバッファ91に読み込まれることになるが、従来ではカルーセル1からカルーセル2に切り換わり、カルーセル2のデータが読み込みが開始された時点において、クライアントはカルーセル1のデータを要求していた。つまり、この時点ではMHEGバッファ92ではカルーセル1のデータ(GUI画面のデータ)が処理に用いられていた。
しかし、本発明では、クライアントは(処理5)によってカルーセルの切り換わったタイミングを検出することができ、このタイミングに基づいてDSM−CCバッファ91に読み込まれているカルーセル2のデータを要求してMHEGバッファ92に格納していくことができるようになる。これにより、カルーセル2に切り換わったタイミングとほぼ同じ時点で、カルーセル2のデータによるGUI画面を構成して出力することができるようになる。
【0120】
ところで、図13の(処理3)として示したEvent::notifyは、前述のように、何らかのイベントが発生したことの通知をクライアントからサーバに要求するものであるが、実際には、或るイベントの発生によってサーバ側でEvent::notifyに応答した通知を行うと、この時点で、Event::notifyは無効となる。
このため、図13に示した処理の実際において、はじめに(処理2)としてEvent::Subscribe(″DSI_CHANGED″)を発行して以降、サーバ側での″DSI_CHANGED″イベントの発生を逃さずに通知させるために、一旦発行したEvent::notifyに応答したイベント通知が行われたら、この後、直ちに次のEvent::notifyを発行するようにしている。つまり、サーバ側において、Event::notifyが無効とされている期間ができるだけ生じないようにするものである。
このようにすれば、データサービス放送中において、DSIの切り換えが行われるごとに、これを逃すことなくほぼリアルタイムで″DSI_CHANGED″イベントの発生のあったことをクライアントに逐次通知することが可能になる。
【0121】
また、上記した(処理1)である、Event::Subscribe(″DSI_CHANGED″)をクライアントからサーバに伝達するインターフェイスは、データサービス放送中におけるDSIの切り換えを逐一逃さずに通知できるようにすることを考慮して、MHEGデコーダブロック84のプログラム(MHEGエンジン)が立ち上がって直ぐのタイミングと、カルーセルのデータ内容の切り換えが行われたときに実行するようにされる。
なお、MHEGデコーダブロック84のプログラムを立ち上げる場合とは、例えば、これまでサービスデータ放送が付随されていない放送を受信していた状態から、例えばチャンネルの切り換えや番組の変更が行なわれることで、新たにデータサービス放送が付随している番組を受信した時などとされる。
【0122】
3−3.第2例
続いて、第2例としてのカルーセル切り換え通知制御について図14を参照して説明する。この第2例では、クライアントに対してイベント番号(Event#1)が伝送(処理4)された後、クライアントは所定の期間、DSIが変更した直前のカルーセルを継続して利用することが可能になる。なお、(処理1)から(処理4)に至る行程は第1例と同様であり説明は省略する。
【0123】
本例では、クライアントにおけるイベント番号(Event#1)が伝送(処理4)された場合、IRD12としてはカルーセル1に続くカルーセル2を受信しているが、対応処理(処理6)としては、DSIが変更する前のカルーセル1に対応した処理可能データ1を継続して利用する。
この場合、サーバとしてはクライアントに対して新たに受信しているカルーセル2に対応したデータの開示を行なわないようにし、処理可能データ1としてDSM−CCバッファ91に取り込まれているカルーセルのデータ(例えば斜線を付して示されている部分)を開示して、これらにクライアントがアクセスするように設定する。すなわち、DSIの変更に対して、切り換わったカルーセルのデータの読み出しを遅らせるような制御が行なわれる。
【0124】
そして、その後クライアントは所定のタイミングで、Session::detachを伝送(処理7)する。このSession::detachは、クライアントが(処理6)によってサーバが開示していないカルーセル2に対応した処理可能データ2の解放を要求する解放要求イベントとされ、所定のタイミングでサーバに対して伝送する。
これによりサーバは、クライアントに対してカルーセル2に対応した処理可能データ2をアクセス可能とする。したがって、クライアントではSession::detachの伝送を行なった後は、サーバによって新たに開示されたカルーセル2の処理可能データ2に基づいて所要の処理を行なうことが可能になる。
【0125】
Session::detachが伝送されるタイミングとしては、例えば(処理5)が開始されてからの時間を予め設定しておいても良いし、現在処理を行なっているデータ、すなわち本例では処理可能データ1が必要なくなったと判断した場合としても良い。処理可能データ1が必要なくなったことを判断する要因としては、例えばユーザによる所要の操作が検出された場合などとされる。
【0126】
このように、第2例によれば、カルーセルが切り換わった後でも、切り換わる直前のデータを継続して用いて処理を行なうことができる。したがって、カルーセルの切り換わりに伴って、現在行なわれている処理が中断されないようにすることができる。
【0127】
なお、本発明としては、データ伝送方式としてDSM−CC方式を採用し、MHEGのクライアント−サーバ間のインターフェイスとしてU−U APIを採用した場合について説明しているが、これに限定されるものではなく、上記実施の形態において説明した送信フォーマットに準ずる伝送方式、及びインターフェイスであれば本発明の適用が可能とされる。また、本発明が適用されるシステムとしてもデジタル衛星放送システムに限定されるものではなく、例えばケーブルテレビジョンなどの放送や、インターネット等において適用することも可能である。
【0128】
【発明の効果】
以上説明したように本発明は、例えばDSM−CC方式のもとでオブジェクトカルーセルによりデータ伝送を行うシステムの受信側におけるデータ伝達制御方法として、カルーセルの内容が切り換わったことを、カルーセルからデータを受信して保持するサーバ側から、このカルーセルのデータを使用して所要の機能を実現するクライアントに対して通知できるようにしたことで、クライアント側では、この通知に従って、カルーセルの内容切り換えに応答して実行すべき処理を迅速に或いは効率的に実行することが可能になるものである。
【0129】
そして本発明では、上記のようなカルーセルの内容切り換えを通知するためのカルーセル内容切り換え通知処理として、例えばU−U API等の既存のインターフェイスのもとで、カルーセルの内容切り換えに関する制御情報(DSI)の変更を意味する制御情報変更イベント(DSI_CHANGED)を設定し、この制御情報変更イベントを利用して、クライアント側からサーバ側に制御情報の変更が有ったことを通知するように構成される。つまり、敢えて特化されたインターフェイスの規格を採用することなく、既存のインターフェイスに準拠した上で、カルーセルの内容切り換えの通知を実現することができ、それだけ汎用性が与えられることになる。
【0130】
また、サブスクライブイベント(Event::subscribe)の伝達は、クライアントのプログラムの立ち上げ時、又は、カルーセル自体の切り換えが行われたときに実行する、また、イベント通知要求(Event::notify)は、サーバからのイベント通知要求に対する応答メッセージが得られた後において、直ちに実行されるようにすることで、クライアントのプログラムの立ち上げ以降においては、カルーセルの内容切換え通知をほぼ逃さずに得ることが可能になり、例えば、放送側でのカルーセルの内容切り換えにほぼ即応したGUI画面の内容変更が可能になるなど、信頼性が向上することになる。
【0131】
さらに、前記サーバが前記制御情報変更イベントの発生を前記クライアントに通知した後、前記クライアントが前記サーバに対してセッションデタッチ(Session::detach・・・解放要求)を伝達するまでの所定の期間内において、前記制御情報変更イベントが発生する前のカルーセルの内容を継続して使用するようにしている。したがって、カルーセルの内容が切り換わった場合でも、直前のカルーセルの内容に基づいて行なわれている処理を中断させないようにすることができる。
【図面の簡単な説明】
【図1】本発明の実施の形態のデジタル衛星放送受信システムの構成例を示すブロック図である。
【図2】本実施の形態における受信設備の構築例を示すブロック図である。
【図3】IRDのためのリモートコントローラの外観を示す正面図である。
【図4】放送画面とGUI画面との切り換えを示す説明図である。
【図5】地上局の構成例を示すブロック図である。
【図6】地上局から送信されるデータを示すチャート図である。
【図7】送信データの時分割多重化構造を示す説明図である。
【図8】DSM−CCによる送信フォーマットを示す説明図である。
【図9】データサービスのディレクトリ構造の一例を示す説明図である。
【図10】トランスポートストリームのデータ構造図である。
【図11】PSIのテーブル構造を示す説明図である。
【図12】IRDの構成を示す説明図である。
【図13】第1例としてのカルーセル切り換え通知制御を示す説明図である。
【図14】第2例としてのカルーセル切り換え通知制御を示す説明図である。
【図15】U−U APIインターフェイスの一般的な制御動作例を示す説明図である。
【符号の説明】
1 地上局、2 衛星、3 受信設備、5 課金サーバ、6 テレビ番組素材サーバ、7 楽曲素材サーバ、8 音声付加情報サーバ、9 GUIデータサーバ、10 キー情報サーバ、11 パラボラアンテナ、13 ストレージデバイス、13A MDレコーダ/プレーヤ、14 モニタ装置、16 IEEE1394バス、21A テレビ番組表示エリア、21B リスト、21C テキスト表示エリア、21D ジャケット表示エリア、22 歌詞表示ボタン、23 プロフィール表示ボタン、24 情報表示ボタン、25 予約録音ボタン、26 予約済一覧表示ボタン、27 録音履歴ボタン、28 ダウンロードボタン、31 テレビ番組素材登録システム、32 楽曲素材登録システム、33 音声付加情報登録システム、34 GUI用素材登録システム、35 AVサーバ、36A MPEGオーディオエンコーダ、36B ATRACエンコーダ、37 音声付加情報データベース、38 GUI素材データベース、39 テレビ番組送出システム、40A MPEGオーディオサーバ、40B MPEGオーディオサーバ、41 音声付加情報送出システム、42 GUIオーサリングシステム、43A MPEGオーディオ送出システム、43B ATRACオーディオ送出システム、44 DSM−CCエンコーダ、45 マルチプレクサ、46 電波送出システム、51 チューナ/フロントエンド部、52 デスクランブラ、53 トランスポート部、54 MPEG2オーディオデコーダ、54A メモリ、55 MPEG2ビデオデコーダ、55A メモリ、56 D/Aコンバータ、57 スイッチ回路、58 表示処理部、59 光デジタル出力インターフェイス、60 IEEE1394インターフェイス、61 マンマシンインターフェイス、62 ICカードスロット、63 モデム、64 リモートコントローラ、65 ICカード、70 デマルチプレクサ、71 キュー、81 制御処理部、82 DeMUXドライバ、83 DSM−CCデコーダブロック、84 MHEGデコーダブロック、90 メインメモリ、91 DSM−CCバッファ、101 電源キー、102 数字キー、103 画面表示切換キー、104 インタラクティブ切換キー、105a 矢印キー、105 EPGキーパネル部、106 チャンネルキー、T1 入力端子、T2 アナログビデオ出力端子、T3 アナログオーディオ出力端子、T4 アナログオーディオ出力端子
Claims (3)
- データカルーセル方式によって繰り返し送信される複数のモジュールを含むカルーセルの切り換えに応じてその内容が切り換わる、MHEGコンテンツデータと前記カルーセルの識別子であるDSIメッセージとを受信する受信手段と、
前記受信された前記MHEGコンテンツデータを蓄積するDSM−CCバッファと、
前記DSMCバッファに格納されている前記MHEGコンテンツデータを再構築するDSM−CCデコーダブロックと、
前記DSM−CCデコーダブロックにより得られたMHEGコンテンツデータにアクセスしてシーン出力のデコード処理をおこなうMHEGデコーダブロックと、を備え、
前記DSM−CCデコーダブロックと前記MHEGデコーダとの間のインターフェイスとしては、該MHEGデコーダにおいて、内容が変更された前記DSIメッセージを受信した場合にはDSIチェンジドイベントを発生する、U−U APIインターフェイスを採用し、
前記MHEGデコーダは、前記DSIチェンジドイベントを前記DSM−CCデコーダブロックに伝達し、
前記DSM−CCデコーダブロックは、前記DSIチェンジドイベントを受信して、該DSIチェンジドイベント対して設定したイベント番号を前記MHEGデコーダに返し、
前記MHEGデコーダは、前記イベント番号を獲得して、ノーティファイを前記DSM−CCデコーダブロックに出力して前記DSIチェンジドイベントが発生した場合に知らせる要求を行い、
前記DSM−CCデコーダブロックは、DSIチェンジドイベントが発生した場合には、前記イベント番号を前記MHEGデコーダに伝送する、受信装置。 - 前記DSIチェンジドイベントが発生した場合に、前記イベント番号を受信した前記MHEGデコーダは、前記DSIチェンジドイベントが発生する前のカルーセルに対応した処理データを継続して利用する請求項1に記載の受信装置。
- 受信手段が、データカルーセル方式によって繰り返し送信される複数のモジュールを含むカルーセルの切り換えに応じてその内容が切り換わる、MHEGコンテンツデータと前記カルーセルの識別子であるDSIメッセージと、を受信し、
DSM−CCバッファが、前記受信された前記MHEGコンテンツデータを蓄積し、
DSM−CCデコーダブロックが、前記DSMCバッファに格納されている前記MHEGコンテンツデータを再構築し、
MHEGデコーダブロックが、前記DSM−CCデコーダブロックにより得られたMHEGコンテンツデータにアクセスしてシーン出力のデコード処理をおこない、
前記DSM−CCデコーダブロックと前記MHEGデコーダとの間のインターフェイスとしては、該MHEGデコーダにおいて、内容が変更された前記DSIメッセージを受信した場合にはDSIチェンジドイベントを発生する、U−U APIインターフェイスを採用し、
前記MHEGデコーダは、前記DSIチェンジドイベントを前記DSM−CCデコーダブロックに伝達し、
前記DSM−CCデコーダブロックは、前記DSIチェンジドイベントを受信して、該DSIチェンジドイベント対して設定したイベント番号を前記MHEGデコーダに返し、
前記MHEGデコーダは、前記イベント番号を獲得して、ノーティファイを前記DSM−CCデコーダブロックに出力して前記DSIチェンジドイベントが発生した場合に知らせる要求を行い、
前記DSM−CCデコーダブロックは、DSIチェンジドイベントが発生した場合には、前記イベント番号を前記MHEGデコーダに伝送する、受信方法。
Priority Applications (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP20172998A JP4378778B2 (ja) | 1998-07-16 | 1998-07-16 | 受信装置および受信方法 |
EP06076318A EP1705918B1 (en) | 1998-07-14 | 1999-07-14 | Data receiving apparatus |
KR1020007002686A KR100641594B1 (ko) | 1998-07-14 | 1999-07-14 | 데이터 전달 제어 방법, 데이터 전송 방법, 데이터 송신장치, 수신 장치 |
EP99929823A EP1014620B1 (en) | 1998-07-14 | 1999-07-14 | Data transmission control method, data transmission method, data transmitter, and receiver |
PCT/JP1999/003787 WO2000004676A1 (fr) | 1998-07-14 | 1999-07-14 | Procede de gestion de la transmission de donnees, procede de transmission de donnees, et emetteur et recepteur de donnees |
DE69943228T DE69943228D1 (de) | 1998-07-14 | 1999-07-14 | Datenempfangsvorrichtung |
CNB998015814A CN100382498C (zh) | 1998-07-14 | 1999-07-14 | 数据发送控制方法、数据发送方法和设备以及接收设备 |
US09/521,098 US6966065B1 (en) | 1998-07-14 | 2000-03-07 | Data transmission control method, data transmitting method, data transmitting apparatus, and receiving apparatus |
US11/217,917 US8209734B2 (en) | 1998-07-14 | 2005-09-01 | Data transmission control method, data transmitting method, data transmitting apparatus, and receiving apparatus |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP20172998A JP4378778B2 (ja) | 1998-07-16 | 1998-07-16 | 受信装置および受信方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2000032425A JP2000032425A (ja) | 2000-01-28 |
JP4378778B2 true JP4378778B2 (ja) | 2009-12-09 |
Family
ID=16445975
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP20172998A Expired - Fee Related JP4378778B2 (ja) | 1998-07-14 | 1998-07-16 | 受信装置および受信方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4378778B2 (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002158626A (ja) * | 2000-08-25 | 2002-05-31 | Matsushita Electric Ind Co Ltd | コンテンツ編集装置、コンテンツ編集方法及びコンテンツ編集プログラム並びにコンピューター読み取り可能な記録媒体 |
-
1998
- 1998-07-16 JP JP20172998A patent/JP4378778B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2000032425A (ja) | 2000-01-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100641594B1 (ko) | 데이터 전달 제어 방법, 데이터 전송 방법, 데이터 송신장치, 수신 장치 | |
US8588678B2 (en) | Control method, control apparatus, data receiving and recording method, data receiver and receiving method | |
US8826111B2 (en) | Receiving apparatus and method for display of separately controllable command objects,to create superimposed final scenes | |
JP5045535B2 (ja) | 受信装置及び受信方法 | |
JP4378780B2 (ja) | 受信装置及び受信方法 | |
JP2001024995A (ja) | 放送装置、放送方法、及び受信装置 | |
JP4378777B2 (ja) | 放送受信装置、放送受信方法 | |
JP4016160B2 (ja) | データ受信・記録方法及びデータ受信装置 | |
JP4296631B2 (ja) | 放送方法、及び受信装置 | |
JP2000333138A (ja) | 情報処理装置及び情報処理方法 | |
JP4378778B2 (ja) | 受信装置および受信方法 | |
JP2000295586A (ja) | 放送用情報処理装置及び放送用情報処理方法 | |
JP4366742B2 (ja) | 受信装置 | |
JP2000333043A (ja) | 情報処理装置およびその方法 | |
JP2001024612A (ja) | 放送監視装置 | |
JP2000032415A (ja) | 受信装置 | |
JP2000331465A (ja) | 情報処理装置およびその方法 | |
JP2001022625A (ja) | データ記録装置、データ記録方法、データ取得装置、データ取得方法 | |
JP2000295638A (ja) | 放送設備監視装置 | |
JP4499205B2 (ja) | データ受信方法、データ受信装置及びプログラム | |
JP2000032362A (ja) | 情報伝送装置、及び情報伝送方法 | |
JP2000333041A (ja) | 情報処理装置及び情報処理方法 | |
JP2001024606A (ja) | 情報送信システム | |
JP2000286809A (ja) | 情報処理装置及び情報処理方法 | |
JP2000286733A (ja) | 情報処理装置及び情報処理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050224 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080325 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080526 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090519 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090721 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090825 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090907 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121002 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121002 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131002 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |