JP4378780B2 - Receiving apparatus and receiving method - Google Patents
Receiving apparatus and receiving method Download PDFInfo
- Publication number
- JP4378780B2 JP4378780B2 JP20385798A JP20385798A JP4378780B2 JP 4378780 B2 JP4378780 B2 JP 4378780B2 JP 20385798 A JP20385798 A JP 20385798A JP 20385798 A JP20385798 A JP 20385798A JP 4378780 B2 JP4378780 B2 JP 4378780B2
- Authority
- JP
- Japan
- Prior art keywords
- scene
- data
- module
- information
- audio
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【0001】
【発明の属する技術分野】
本発明は、例えばデジタル衛星放送などのデータサービスにおける受信設備側に設けられるとされる受信装置及び受信方法に関するものである。
【0002】
【従来の技術】
近年、デジタル衛星放送の普及が進んでいる。デジタル衛星放送は、例えば既存のアナログ放送と比較してノイズやフェージングに強く、高品質の信号を伝送することが可能である。また、周波数利用効率が向上され、多チャンネル化も図ることが可能になる。具体的には、デジタル衛星放送であれば1つの衛星で数百チャンネルを確保することも可能である。このようなデジタル衛星放送では、スポーツ、映画、音楽、ニュースなどの専門チャンネルが多数用意されており、これらの専門チャンネルでは、それぞれの専門のコンテンツに応じたプログラムが放送されている。
【0003】
そして、上記のようなデジタル衛星放送システムを利用して、ユーザが楽曲等の音声データをダウンロードできるようにしたり、いわゆるテレビショッピングとして、例えばユーザが放送画面を見ながら何らかの商品についての購買契約を結べるようにしたりすることが提案されている。つまりは、デジタル衛星放送システムとして、通常の放送内容と並行したデータサービス放送を行うものである。
【0004】
一例として、楽曲データのダウンロードであれば、放送側においては、放送番組と並行して、楽曲データを多重化して放送するようにする。また、この楽曲データのダウンロードに際しては、GUI(Graphical User Interface)画面(即ちダウンロード用の操作画面である)を表示させることでインタラクティブな操作をユーザに行わせるようにされるが、このGUI画面出力のためのデータも多重化して放送するようにされる。
そして、受信装置を所有しているユーザ側では、所望のチャンネルを選局している状態で、受信装置に対する所定の操作によって楽曲データをダウンロードするためのGUI画面を表示出力させるようにする。そして、この表示された操作画面に対してユーザが操作を行うことで、例えば受信装置に接続したデジタルオーディオ機器に対してデータを供給し、これが録音されるようにするものである。
【0005】
ところで、上記のような楽曲データをダウンロードするためのGUI画面としては、例えばGUI画面を形成するパーツ的な画像データ、テキストデータなどの情報に加え、更には所定操作に応じた音声出力のための音声データなどの単位データ(ファイル)をそれぞれオブジェクトとして扱い、このオブジェクトの出力態様を所定方式によるシナリオ記述によって規定することによって、上記操作画面についての所要の表示形態及び音声等の出力態様を実現するように構成することが考えられる。
なお、ここでは、上記GUI画面のようにして、記述情報によって規定されることで、或る目的に従った機能を実現する表示画面(ここでは音声等の出力も含む)のことを「シーン」というものとする。また、「オブジェクト」とは、記述情報に基づいてその出力態様が規定される画像、音声、テキスト等の単位情報を示しており、伝送時においては、ここでは記述情報自体のデータファイルも「オブジェクト」の1つとして扱われるものとする。
【0006】
上記シーン表示及びシーン表示上での音声出力等を実現するためのオブジェクトは、放送局側で放送すべきシーンを形成するデータのディレクトリ構造に対して適当にマッピングが施され、所定の伝送方式に従ってエンコードされて送信される。例えば、或る1番組において複数のシーンが必要な場合には、これら複数のシーンに必要されるオブジェクトのデータが適当にマッピングされたうえで送信されることになる。
受信装置側では伝送方式に従ってデコード処理を施して、例えば表示に必要なシーンに必要とされるオブジェクトごとの纏まりとしてのデータを得て、これをシーンとして出力するようにされる。
【0007】
【発明が解決しようとする課題】
ここで、受信装置を所有するユーザにとってみれば、あるチャンネルを選局して最初にシーンを表示するまでの待ち時間や、或るシーンから他のシーンに表示を切り換えるような際の待ち時間はできるだけ短いようにすることが、快適な操作環境という点で好ましい。
【0008】
例えば、シーン表示の切り換えが迅速に行われるようにする対策として、受信装置側に比較的大容量のバッファを備えるようにし、受信データから取り込んだシーンごとのオブジェクトの集まりとしてのデータを、このバッファに格納しておくようにすることが考えられる。このようにすれば、バッファから読み出したデータに基づいて迅速に次のシーンに切り換えを行うことが可能になる。
但し、上記のようなバッファを受信装置に備えるということは、それだけ受信装置の回路規模の大型化及びコストアップにつながるという不利な点を抱えることになる。
【0009】
【課題を解決するための手段】
そこで本発明は上記した課題を考慮して、受信装置側においてできるだけ迅速に必要なシーンのデータが得られるようにし、例えばシーン出力の切り換えなども迅速に行われるようにすることを目的とする。また、これを実現するのにあたり、例えば大容量のバッファなどを備えることなく、出来るだけ小規模な回路で実現できるようにすることを目的とする。
【0010】
このため、本発明の受信装置は、オブジェクトカルーセル伝送方式によって繰り返し送信される、提示用コンテンツデータがブロックに分割されて伝送されるシーンデータとされるモジュールを含むDDBメッセージと、該カルーセルの識別子、カルーセル全体に関連する情報及びデータサービスのルートディレクトリの所在を知るための情報を有するDSIメッセージと、該カルーセルに含まれるモジュールごとに対応する情報を含むDIIメッセージとを受信する受信手段と、前記受信手段によって受信されたDDBメッセージに含まれる前記モジュールを、前記カルーセルによって伝送されるシーン切り換えの必要があるとされたときに、切り換えが行われる可能性の高さに従って付されている優先度情報に基づいて蓄積する蓄積手段と、前記DIIメッセージに含まれる情報であって、前記蓄積手段によって蓄積されている前記モジュールの位置を示す前記DSIメッセージが有するルートディレクトリを参照して、前記DDBメッセージ内の前記モジュールのうち、前記優先度情報に基づいてスタートアップファイルを取得する取得手段と、前記取得手段によって取得されたスタートアップファイルを、前記蓄積手段によって蓄積されたDDBメッセージによって伝送される、前記提示用コンテンツデータについて表示制御を行うためのスクリプトに基づいて出力する出力制御手段とを備える。
【0011】
また、本発明の受信方法は、オブジェクトカルーセル伝送方式によって繰り返し送信される、提示用コンテンツデータがブロックに分割されて伝送されるシーンデータとされるモジュールを含むDDBメッセージと、該カルーセルの識別子、カルーセル全体に関連する情報、データサービスのルートディレクトリの所在を知るための情報を有するDSIメッセージと、該カルーセルに含まれるモジュールごとに対応する情報を含むDIIメッセージとを受信する受信手順と、前記受信手順によって受信されたDDBメッセージに含まれる前記モジュールを、前記カルーセルによって伝送されるシーン切り換えの必要があるとされたときに、切り換えが行われる可能性の高さに従って付されている優先度情報に基づいて蓄積する蓄積手順と、前記DIIメッセージに含まれる情報であって、前記蓄積手順によって蓄積されている前記モジュールの位置を示す前記DSIメッセージに含まれるルートディレクトリを参照して、前記DDBメッセージ内の前記モジュールのうち、前記優先度情報に基づいてスタートアップファイルを取得する取得手順と、前記取得手順によって取得されたスタートアップファイルを、前記蓄積手順によって蓄積されたDDBメッセージによって伝送される、前記提示用コンテンツデータについて表示制御を行うためのスクリプトに基づいて出力する出力制御手順とを実行する。
【0012】
【発明の実施の形態】
以降、本発明の実施の形態について説明する。
本発明が適用されるシステムとしては、デジタル衛星放送を利用して番組を放送すると共に、受信装置側ではこの番組に関連した楽曲データ(音声データ)等の情報をダウンロードできるようにしたシステムを例に挙げることとする。
【0013】
なお、以降の説明は次の順序で行うこととする。
1.デジタル衛星放送システム
1−1.全体構成
1−2.GUI画面に対する操作
1−3.地上局
1−4.送信フォーマット
1−5.IRD
2.本発明に至った背景
3.地上局側のデータマッピング例
4.本実施の形態のキューへのモジュール割付
【0014】
1.デジタル衛星放送システムの構成
1−1.全体構成
図1は、本実施の形態としてのデジタル衛星放送システムの全体構成を示すものである。この図に示すように、デジタル衛星放送の地上局1には、テレビ番組素材サーバ6からのテレビ番組放送のための素材と、楽曲素材サーバ7からの楽曲データの素材と、音声付加情報サーバ8からの音声付加情報と、GUIデータサーバからのGUIデータとが送られる。
【0015】
テレビ番組素材サーバ6は、通常の放送番組の素材を提供するサーバである。このテレビ番組素材サーバから送られてくる音楽放送の素材は、動画及び音声とされる。例えば、音楽放送番組であれば、上記テレビ番組素材サーバ6の動画及び音声の素材を利用して、例えば新曲のプロモーション用の動画及び音声が放送されたりすることになる。
【0016】
楽曲素材サーバ7は、オーディオチャンネルを使用して、オーディオ番組を提供するサーバである。このオーディオ番組の素材は音声のみとなる。この楽曲素材サーバ7は、複数のオーディオチャンネルのオーディオ番組の素材を地上局1に伝送する。
各オーディオチャンネルの番組放送ではそれぞれ同一の楽曲が所定の単位時間繰り返して放送される。各オーディオチャンネルは、それぞれ、独立しており、その利用方法としては各種考えられる。例えば、1つのオーディオチャンネルでは最新の日本のポップスの数曲を或る一定時間繰り返し放送し、他のオーディオチャンネルでは最新の外国のポップスの数曲を或る一定時間繰り返し放送するというようにされる。
【0017】
音声付加情報サーバ8は、楽曲素材サーバ7から出力される楽曲の時間情報等を提供するサーバである。
【0018】
GUIデータサーバ9は、ユーザが操作に用いるGUI画面を形成するための「GUIデータ」を提供する。例えば後述するような楽曲のダウンロードに関するGUI画面であれば、配信される楽曲のリストページや各楽曲の情報ページを形成するための画像データ、テキストデータ、アルバムジャケットの静止画を形成するためのデータなどを提供する。更には、受信設備3側にていわゆるEPG(Electrical Program Guide)といわれる番組表表示を行うのに利用されるEPGデータもここから提供される。
なお、「GUIデータ」としては、例えばMHEG(Multimedia Hypermedia Information Coding Experts Group)方式が採用される。MHEGとは、マルチメディア情報、手順、操作などのそれぞれと、その組み合わせをオブジェクトとして捉え、それらのオブジェクトを符号化したうえで、タイトル(例えばGUI画面)として制作するためのシナリオ記述の国際標準とされる。また、本実施の形態ではMHEG−5を採用するものとする。
【0019】
地上局1は上記テレビ番組素材サーバ6、楽曲素材サーバ7、音声付加情報サーバ8、及びGUIデータサーバ9から伝送された情報を多重化して送信する。
本実施の形態では、テレビ番組素材サーバ6から伝送されたビデオデータはMPEG(Moving Picture Experts Group)2方式により圧縮符号化され、オーディオデータはMPEG2オーディオ方式により圧縮符号化される。また、楽曲素材サーバ7から伝送されたオーディオデータは、オーディオチャンネルごとに対応して、例えばMPEG2オーディオ方式と、ATRAC(Adoptive Tranform Acoustic Coding)方式と何れか一方の方式により圧縮符号化される。
また、これらのデータは多重化の際、キー情報サーバ10からのキー情報を利用して暗号化される。
なお、地上局1の内部構成例については後述する。
【0020】
地上局1からの信号は衛星2を介して各家庭の受信設備3で受信される。衛星2には複数のトランスポンダが搭載されている。1つのトランスポンダは例えば30Mbpsの伝送能力を有している。各家庭の受信設備3としては、パラボラアンテナ11とIRD(Integrated Receiver Decorder)12と、ストレージデバイス13と、モニタ装置14とが用意される。
また、この場合には、IRD12に対して操作を行うためのリモートコントローラ64が示されている。
【0021】
パラボラアンテナ11で衛星2を介して放送されてきた信号が受信される。この受信信号がパラボラアンテナ11に取り付けられたLNB(Low Noize Block Down Converter)15で所定の周波数に変換され、IRD12に供給される。
【0022】
IRD12における概略的な動作としては、受信信号から所定のチャンネルの信号を選局し、その選局された信号から番組としてのビデオデータ及びオーディオデータの復調を行ってビデオ信号、オーディオ信号として出力する。また、IRD12では、番組としてのデータと共に多重化されて送信されてくる、GUIデータに基づいてGUI画面としての出力も行う。このようなIRD12の出力は、例えばモニタ装置14に対して供給される。これにより、モニタ装置14では、IRD12により受信選局した番組の画像表示及び音声出力が行われ、また、後述するようなユーザの操作に従ってGUI画面を表示させることが可能となる。
【0023】
ストレージデバイス13は、IRD12によりダウンロードされたオーディオデータ(楽曲データ)を保存するためのものである。このストレージデバイス13の種類としては特に限定されるものではなく、MD(Mini Disc)レコーダ/プレーヤ、DATレコーダ/プレーヤ、DVDレコーダ/プレーヤ等を用いることができる。また、ストレージデバイス13としてパーソナルコンピュータ装置を用い、ハードディスクのほか、CD−R等をはじめとする記録が可能なメディアにオーディオデータを保存するようにすることも可能とされる。
【0024】
また、本実施の形態の受信設備3としては、図2に示すように、データ伝送規格としてIEEE1394に対応したデータインターフェイスを備えたMDレコーダ/プレーヤ13Aを、図1に示すストレージデバイス13として使用することができるようになっている。
この図に示すIEEE1394対応のMDレコーダ/プレーヤ13Aは、IEEE1394バス16によりIRD12と接続される。これによって、本実施の形態では、IRD12にて受信された、楽曲としてのオーディオデータ(ダウンロードデータ)を、ATRAC方式により圧縮処理が施されたままの状態で直接取り込んで記録することができる。また、MDレコーダ/プレーヤ13AとIRD12とをIEEE1394バス16により接続した場合には、上記オーディオデータの他、そのアルバムのジャケットデータ(静止画データ)及び歌詞などのテキストデータを記録することも可能とされている。
【0025】
IRD12は、例えば電話回線4を介して課金サーバ5と通信可能とされている。IRD12には、後述するようにして各種情報が記憶されるICカードが挿入される。例えば楽曲のオーディオデータのダウンロードが行われたとすると、これに関する履歴情報がICカードに記憶される。このICカードの情報は、電話回線4を介して所定の機会、タイミングで課金サーバ5に送られる。課金サーバ5は、この送られてきた履歴情報に従って金額を設定して課金を行い、ユーザに請求する。
【0026】
これまでの説明から分かるように、本発明が適用されたシステムでは、地上局1は、テレビ番組素材サーバ6からの音楽番組放送の素材となるビデオデータ及びオーディオデータと、楽曲素材サーバ7からのオーディオチャンネルの素材となるオーディオデータと、音声付加情報サーバ8からの音声データと、GUIデータサーバ9からのGUIデータとを多重化して送信している。
そして、各家庭の受信設備3でこの放送を受信すると、例えばモニタ装置14により、選局したチャンネルの番組を視聴することができる。また、番組のデータと共に送信されるGUIデータを利用したGUI画面として、第1にはEPG(Electrical Program Guide;電子番組ガイド)画面を表示させ、番組の検索等を行うことができる。また、第2には、例えば通常の番組放送以外の特定のサービス用のGUI画面を利用して所要の操作を行うことで、本実施の形態の場合には、放送システムにおいて提供されている通常番組の視聴以外のサービスを享受することができる。
例えば、オーディオ(楽曲)データのダウンロードサービス用のGUI画面を表示させて、このGUI画面を利用して操作を行えば、ユーザが希望した楽曲のオーディオデータをダウンロードしてストレージデバイス13に記録して保存することが可能になる。
【0027】
なお、本実施の形態では、上記したようなGUI画面に対する操作を伴う、通常の番組放送以外の特定のサービスを提供するデータサービス放送については、インタラクティブ性を有することもあり、「インタラクティブ放送」ともいうことにする。
【0028】
1−2.GUI画面に対する操作
ここで、上述しているインタラクティブ放送の利用例、つまり、GUI画面に対する操作例について、図3及び図4を参照して概略的に説明しておく。ここでは、楽曲データ(オーディオデータ)のダウンロードを行う場合について述べる。
【0029】
先ず、図3によりIRD12に対してユーザが操作を行うためのリモートコントローラ64の操作キーについて、特に主要なものについて説明しておく。
図3には、リモートコントローラ64において各種キーが配列された操作パネル面が示されている。ここでは、これら各種キーのうち、電源キー101、数字キー102、画面表示切換キー103、インタラクティブ切換キー104、EPGキーパネル部105、チャンネルキー106について説明する。
【0030】
電源キー101は、IRD12の電源のオン/オフを行うためのキーである。数字キー102は、数字指定によりチャンネル切り換えを行ったり、例えばGUI画面において数値入力操作が必要な場合に操作するためのキーである。
画面表示切換キー103は、例えば通常の放送画面とEPG画面との切り換えを行うキーである。例えば、画面表示切換キー103によりEPG画面を呼び出した状態の下で、EPGキーパネル部105に配置されたキーを操作すれば、電子番組ガイドの表示画面を利用した番組検索が行えることになる。また、EPGキーパネル部105内の矢印キー105aは、後述するサービス用のGUI画面におけるカーソル移動などにも使用することができる。
インタラクティブ切換キー104は、通常の放送画面と、その放送番組に付随したサービスのためのGUI画面との切り換えを行うために設けられる。
チャンネルキー106は、IRD12における選局チャンネルをそのチャンネル番号の昇順、降順に従って順次切り換えていくために設けられるキーである。
【0031】
なお、本実施の形態のリモートコントローラ64としては、例えばモニタ装置14に対する各種操作も可能に構成されているものとされ、これに対応した各種キーも設けられているものであるが、ここでは、モニタ装置14に対応するキー等の説明は省略する。
【0032】
次に、図4を参照してGUI画面に対する操作の具体例について説明する。
受信設備3により放送を受信して所望のチャンネルを選局すると、モニタ装置14の表示画面には、図4(a)に示すように、テレビ番組素材サーバ6から提供された番組素材に基づく動画像が表示される。つまり、通常の番組内容が表示される。ここでは、例えば音楽番組が表示されているものとする。また、この音楽番組には楽曲のオーディオデータのダウンロードサービス(インタラクティブ放送)が付随されているものとする。
そして、この音楽番組が表示されている状態の下で、例えばユーザがリモートコントローラ64のインタラクティブ切換キー104を操作したとすると、表示画面は図4(b)に示すような、オーディオデータのダウンロードのためのGUI画面に切り替わる。
【0033】
このGUI画面においては、先ず、画面の左上部のテレビ番組表示エリア21Aに対して、図4(a)にて表示されていたテレビ番組素材サーバ6からのビデオデータによる画像が縮小化されて表示される。
また、画面の右上部には、オーディオチャンネルで放送されている各チャンネルの楽曲のリスト21Bが表示される。また、画面の左下にはテキスト表示エリア21Cとジャケット表示エリア21Dが表示される。さらに、画面の右側には歌詞表示ボタン22、プロフィール表示ボタン23、情報表示ボタン24、予約録音ボタン25、予約済一覧表示ボタン26、録音履歴表示ボタン27、およびダウンロードボタン28が表示される。
【0034】
ユーザは、このリスト21Bに表示されている楽曲名を見ながら、興味のある楽曲を探していく。そして、興味のある楽曲を見つけたらリモートコントローラ64の矢印キー105a(EPGキーパネル部105内)を操作して、その楽曲が表示されている位置にカーソルを合わせた後、エンター操作を行う(例えば矢印キー105aのセンター位置を押圧操作する)。
これによって、カーソルを合わせた楽曲を試聴することができる。すなわち、各オーディオチャンネルでは、所定の単位時間中、同一の楽曲が繰り返し放送されているので、テレビ番組表示エリア21Aの画面はそのままで、IRD12により上記操作により選択された楽曲のオーディオチャンネルに切り換えて音声出力することで、その楽曲を聞くことができる。この時、ジャケット表示エリア21Dにはその楽曲のMDジャケットの静止画像が表示される。
【0035】
また、例えば上記の状態で歌詞表示ボタン22にカーソルを合わせ、エンター操作を行う(以下、ボタン表示にカーソルを合わせ、エンター操作を行うことを「ボタンを押す」という)と、テキスト表示エリア21Cに楽曲の歌詞がオーディオデータと同期したタイミングで表示される。同様に、プロフィール表示ボタン23あるいは情報表示ボタン24を押すと、楽曲に対応するアーティストのプロフィールあるいはコンサート情報などがテキスト表示エリア21Cに表示される。このように、ユーザは、現在どのような楽曲が配信されているのかを知ることができ、更に各楽曲についての詳細な情報を知ることができる。
【0036】
ユーザは試聴した楽曲を購入したい場合には、ダウンロードボタン28を押す。ダウンロードボタン28が押されると、選択された楽曲のオーディオデータがダウンロードされ、ストレージデバイス13に記憶される。楽曲のオーディオデータと共に、その歌詞データ、アーティストのプロフィール情報、ジャケットの静止画データ等をダウンロードすることもできる。
そして、このようにして楽曲のオーディオデータがダウンロードされる毎に、その履歴情報がIRD12内のICカードに記憶される。ICカードに記憶された情報は、例えば1カ月に一度ずつ課金サーバ5により取り込みが行われ、ユーザに対してデータサービスの使用履歴に応じた課金が行われる。これによって、ダウンロードされる楽曲の著作権を保護することができることにもなる。
【0037】
また、ユーザは予めダウンロードの予約を行いたい場合には、予約録音ボタン25を押す。このボタンを押すと、GUI画面の表示が切り換わり、予約が可能な楽曲のリストが画面全体に表示される。例えばこのリストは1時間単位、1週間単位、チャンル単位等で検索した楽曲を表示することが可能である。ユーザはこのリストの中からダウンロードの予約を行いたい楽曲を選択すると、その情報がIRD12内に登録される。そして、すでにダウンロードの予約を行った楽曲を碓認したい場合には、予約済一覧表示ボタン26を押すことにより、画面全体に表示させることができる。このようにして予約された楽曲は、予約時刻になるとIRD12によりダウンロードされ、ストレージデバイス13に記憶される。
【0038】
ユーザはダウンロードを行った楽曲について確認したい場合には、録音履歴ボタン27を押すことにより、既にダウンロードを行った楽曲のリストを画面全体に表示させることができる。
【0039】
このように、本発明が適用されたシステムの受信設備3では、モニタ装置14のGUI画面上に楽曲のリストが表示される。そして、このGUI画面上の表示にしたがって楽曲を選択するとその楽曲を試聴することができ、その楽曲の歌詞やアーティストのプロフィール等を知ることができる。さらに、楽曲のダウンロードとその予約、ダウンロードの履歴や予約済楽曲リストの表示等を行うことができる。
【0040】
詳しいことは後述するが、上記図4(b)に示すようなGUI画面の表示と、GUI画面に対するユーザの操作に応答したGUI画面上での表示変更、及び音声出力は、前述したMHEG方式に基づいたシナリオ記述により、オブジェクトの関係を規定することにより実現される。ここでいうオブジェクトとは、図4(b)に示された各ボタンに対応するパーツとしての画像データや各表示エリアに表示される素材データとなる。
そして、本明細書においては、このGUI画面のような、シナリオ記述によってオブジェクト間の関係が規定されることで、或る目的に従った情報の出力態様(画像表示や音声出力等)が実現される環境を「シーン」というものとする。また、1シーンを形成するオブジェクトとしては、シナリオ記述のファイル自体も含まれるものとする。
【0041】
以上、説明したように、本発明が適用されたデジタル衛星放送システムでは放送番組が配信されると共に、複数のオーディオチャンネルを使用して楽曲のオーディオデータが配信される。そして、配信されている楽曲のリスト等を使用して所望の楽曲を探し、そのオーディオデータをストレージデバイス13に簡単に保存することができる。
なお、デジタル衛星放送システムにおける番組提供以外のサービスとしては、上記した楽曲データのダウンロードの他にも各種考えられる。例えば、いわゆるテレビショッピングといわれる商品紹介番組を放送した上で、GUI画面としては購買契約が結べるようなものを用意することも考えられる。
【0042】
1−3.地上局
これまで、本実施の形態としてのデジタル衛星放送システムの概要について説明したが、以降、このシステムについてより詳しい説明を行っていくこととする。そこで、先ず地上局1の構成について図5を参照して説明する。
【0043】
なお、以降の説明にあたっては、次のことを前提とする。
本実施の形態では、地上局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が採用されるものである。
【0044】
図5に示す地上局1の構成において、テレビ番組素材登録システム31は、テレビ番組素材サーバ6から得られた素材データをAVサーバ35に登録する。この素材データはテレビ番組送出システム39に送られ、ここでビデオデータは例えばMPEG2方式で圧縮され、オーディオデータは、例えばMPEG2オーディオ方式によりパケット化される。テレビ番組送出システム39の出力はマルチプレクサ45に送られる。
【0045】
また、楽曲素材登録システム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に送出される。
【0046】
また、音声付加情報登録システム33では、音声付加情報サーバ8からの素材データである音声付加情報を音声付加情報データベース37に登録する。この音声付加情報データベース37に登録された音声付加情報は、音声付加情報送出システム41に伝送され、同様にして、ここでパケット化されてマルチプレクサ45に伝送される。
【0047】
また、GUI用素材登録システム34では、GUIデータサーバ9からの素材データであるGUIデータを、GUI素材データベース38に登録する。
【0048】
GUI素材データベース38に登録されたGUI素材データは、GUIオーサリングシステム42に伝送され、ここで、GUI画面、即ち図4にて述べた「シーン」としての出力が可能なデータ形式となるように処理が施される。
【0049】
つまり、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のスクリプトによる規定が行われる。
【0050】
なお、GUIオーサリングシステム42から伝送されるMHEGコンテンツのデータとしては、スクリプトファイル、及びオブジェクトとしての各種静止画データファイルやテキストデータファイルなどとなるが、静止画データは、例えばJPEG(Joint Photograph Experts Group)方式で圧縮された640×480ピクセルのデータとされ、テキストデータは例えば800文字以内のファイルとされる。
【0051】
GUIオーサリングシステム42にて得られたMHEGコンテンツのデータはDSM−CCエンコーダ44に伝送される。
DSM−CCエンコーダ44では、MPEG2フォーマットに従ったビデオ、オーディオデータのデータストリームに多重できる形式のトランスポートストリーム(以下TS(Transport Stream)とも略す)に変換して、パケット化されてマルチプレクサ45に出力される。
【0052】
マルチプレクサ45においては、テレビ番組送出システム39からのビデオパケットおよびオーディオパケットと、MPEGオーディオ送出システム43Aからのオーディオパケットと、ATRACオーディオ送出システム43Bからの4倍速オーディオパケットと、音声付加情報送出システム41からの音声付加情報パケットと、GUIオーサリングシステム42からのGUIデータパケットとが時間軸多重化されると共に、キー情報サーバ10(図1)から出力されたキー情報に基づいて暗号化される。
【0053】
マルチプレクサ45の出力は電波送出システム46に伝送され、ここで例えば誤り訂正符号の付加、変調、及び周波数変換などの処理を施された後、アンテナから衛星2に向けて送信出力するようにされる。
【0054】
1−4.送信フォーマット
【0055】
次に、DSM−CC方式に基づいて規定された本実施の形態の送信フォーマットについて説明する。
図6は、地上局1から衛星2に送信出力される際のデータの一例を示している。なお、前述したように、この図に示す各データは実際には時間軸多重化されているものである。また、この図では、図6に示すように、時刻t1から時刻t2の間が1つのイベントとされ、時刻t2から次のイベントとされる。ここでいうイベントとは、例えば音楽番組のチャンネルであれば、複数楽曲のラインナップの組を変更する単位であり、時間的には30分或いは1時間程度となる。
【0056】
図6に示すように、時刻t1から時刻t2のイベントでは、通常の動画の番組放送で、所定の内容A1を有する番組が放送されている。また、時刻t2から始めるイベントでは、内容A2としての番組が放送されている。この通常の番組で放送されているのは動画と音声である。
【0057】
MPEGオーディオチャンネル(1)〜(10)は、例えば、チャンネルCH1からCH10の10チャンネル分用意される。このとき、各オーディオチャンネルCH1,CH2,CH3・・・・CH10では、1つのイベントが放送されている間は同一楽曲が繰り返し送信される。つまり、時刻t1〜t2のイベントの期間においては、オーディオチャンネルCH1では楽曲B1が繰り返し送信され、オーディオチャンネルCH2では楽曲C1が繰り返し送信され、以下同様に、オーディオチャンネルCH10では楽曲K1が繰り返し送信されることになる。これは、その下に示されている4倍速ATRACオーディオチャンネル(1)〜(10)についても共通である。
【0058】
つまり、図6において、MPEGオーディオチャンネルと4倍速ATRACオーディオチャンネルのチャンネル番号である( )内の数字が同じものは同じ楽曲となる。また、音声付加情報のチャンネル番号である( )内の数字は、同じチャンネル番号を有するオーディオデータに付加されている音声付加情報である。更に、GUIデータとして伝送される静止画データやテキストデータも各チャンネルごとに形成されるものである。これらのデータは、図7(a)〜(d)に示すようにMPEG2のトランスポートパケット内で時分割多重されて送信され、図7(e)〜(h)に示すようにしてIRD12内では各データパケットのヘッダ情報を用いて再構築される。
【0059】
また、上記図6及び図7に示した送信データのうち、少なくとも、データサービス(インタラクティブ放送)に利用されるGUIデータは、DSM−CC方式に則って論理的には次のようにして形成されるものである。ここでは、DSM−CCエンコーダ44から出力されるトランスポートストリームのデータに限定して説明する。
【0060】
図8(a)に示すように、DSM−CC方式によって伝送される本実施の形態のデータ放送サービスは、Service Gatewayという名称のルートディレクトリの中に全て含まれる。Service Gatewayに含まれるオブジェクトとしては、ディレクトリ(Directory),ファイル(File),ストリーム(Stream),ストリームイベント(Stream Event)などの種類が存在する。
【0061】
これらのうち、ファイルは静止画像、音声、テキスト、更にはMHEGにより記述されたスクリプトなどの個々のデータファイルとされる。
ストリームは例えば、他のデータサービスやAVストリーム(TV番組素材としてのMPEGビデオデータ、オーディオデータ、楽曲素材としてのMPEGオーディオデータ、ATRACオーディオデータ等)にリンクする情報が含まれる。
また、ストリームイベントは、同じくリンクの情報と時刻情報が含まれる。
ディレクトリは相互に関連するデータをまとめるフォルダである。
【0062】
そして、DSM−CC方式では、図8(b)に示すようにして、これらの単位情報とService Gatewayをそれぞれオブジェクトという単位と捉え、それぞれをBIOPメッセージという形式に変換する。
なお、本発明に関わる説明では、ファイル,ストリーム,ストリームイベントの3つのオブジェクトの区別は本質的なものではないので、以下の説明ではこれらをファイルとしてのオブジェクトに代表させて説明する。
【0063】
そして、DSM−CC方式では、図8(c)に示すモジュールといわれるデータ単位を生成する。このモジュールは、図8(b)に示したBIOPメッセージ化されたオブジェクトを1つ以上含むようにされたうえで、BIOPヘッダが付加されて形成される可変長のデータ単位であり、後述する受信側における受信データのバッファリング単位となる。
また、DSM−CC方式としては、1モジュールを複数のオブジェクトにより形成する場合の、オブジェクト間の関係については特に規定、制限はされていない。つまり、極端なことをいえば、全く関係の無いシーン間における2以上のオブジェクトにより1モジュールを形成したとしても、DSM−CC方式のもとでの規定に何ら違反するものではない。
【0064】
このモジュールは、MPEG2フォーマットにより規定されるセクションといわれる形式で伝送するために、図8(d)に示すように、機械的に「ブロック」といわれる原則固定長のデータ単位に分割される。但し、モジュールにおける最後のブロックについては規定の固定長である必要はないものとされている。このように、ブロック分割を行うのはMPEG2フォーマットにおいて、1セクションが4KBを越えてはならないという規定があることに起因する。
また、この場合には上記ブロックとしてのデータ単位と、セクションとは同義なものとなる。
【0065】
このようにしてモジュールを分割して得たブロックは、図8(e)に示すようにしてヘッダが付加されてDDB(Download Data Block)というメッセージの形式に変換される。
【0066】
また、上記DDBへの変換と並行して、DSI(Download Server Initiate)及びDII(Download Info Indication)という制御メッセージが生成される。
上記DSI及びDIIは、受信側(IRD12)で受信データからモジュールを取得する際に必要となる情報であり、DSIは主として、次に説明するカルーセル(モジュール)の識別子、カルーセル全体に関連する情報(カルーセルが1回転する時間、カルーセル回転のタイムアウト値)等の情報を有する。また、データサービスのルートディレクトリ(Service Gateway)の所在を知るための情報も有する(オブジェクトカルーセル方式の場合)。
【0067】
DIIは、カルーセルに含まれるモジュールごとに対応する情報であり、モジュールごとのサイズ、バージョン、そのモジュールのタイムアウト値などの情報を有する。
【0068】
そして、図8(f)に示すように、上記DDB、DSI、DIIの3種類のメッセージをセクションのデータ単位に対応させて周期的に、かつ、繰り返し送出するようにされる。これにより、受信機側では例えば目的のGUI画面(シーン)を得るのに必要なオブジェクトが含まれているモジュールをいつでも受信できるようにされる。
本明細書では、このような伝送方式を回転木馬に例えて「カルーセル方式」といい、図8(f)に示すようにして模式的に表されるデータ伝送形態をカルーセルというものとする。
また、「カルーセル方式」としては、「データカルーセル方式」のレベルと「オブジェクトカルーセル方式」のレベルとに分けられる。特にオブジェクトカルーセル方式では、ファイル、ディレクトリ、ストリーム、サービスゲートウェイなどの属性を持つオブジェクトをデータとしてカルーセルを用いて転送する方式で、ディレクトリ構造を扱えることがデータカルーセル方式と大きく異なる。本実施の形態のシステムでは、オブジェクトカルーセル方式を採用するものとされる。
【0069】
また、上記のようにしてカルーセルにより送信されるGUIデータ、つまり、図5のDSM−CCエンコーダ44から出力されるデータとしては、トランスポートストリームの形態により出力される。このトランスポートストリームは例えば図9に示す構造を有する。
図9(a)には、トランスポートストリームが示されている。このトランスポートストリームとはMPEGシステムで定義されているビット列であり、図のように188バイトの固定長パケット(トランスポートパケット)の連結により形成される。
【0070】
そして、各トランスポートパケットは、図9(b)に示すようにヘッダと特定の個別パケットに付加情報を含めるためのアダプテーションフィールドとパケットの内容(ビデオ/オーディオデータ等)を表すペイロード(データ領域)とからなる。
【0071】
ヘッダは、例えば実際には4バイトとされ、図9(c)に示すように、先頭には必ず同期バイトがあるようにされ、これより後ろの所定位置にそのパケットの識別情報であるPID(Packet_ID)、スクランブルの有無を示すスクランブル制御情報、後続するアダプテーションフィールドやペイロードの有無等を示すアダプテーションフィールド制御情報が格納されている。
【0072】
これらの制御情報に基づいて、受信装置側ではパケット単位でデスクランブルを行い、また、デマルチプレクサによりビデオ/オーディオ/データ等の必要パケットの分離・抽出を行うことができる。また、ビデオ/オーディオの同期再生の基準となる時刻情報を再生することもここで行うことができる。
【0073】
また、これまでの説明から分かるように、1つのトランスポートストリームには複数チャンネル分の映像/音声/データのパケットが多重されているが、それ以外にPSI(Program Specific Information)といわれる選局を司るための信号や、限定受信(個人の契約状況により有料チャンネルの受信可不可を決定する受信機能)に必要な情報(EMM/ECM)、EPGなどのサービスを実現するためのSI(Service Information)が同時に多重されている。ここでは、PSIについて説明する。
【0074】
PSIは、図10に示すようにして、4つのテーブルで構成されている。それぞれのテーブルは、セクション形式というMPEG Systemに準拠した形式で表されている。
図10(a)には、NIT(Network Informataion Table)及びCAT(Conditional Access Table)のテーブルが示されている。
NITは、全キャリアに同一内容が多重されている。キャリアごとの伝送諸元(偏波面、キャリア周波数、畳み込みレート等)と、そこに多重されているチャンネルのリストが記述されている。NITのPIDとしては、PID=0x0010とされている。
【0075】
CATもまた、全キャリアに同一内容が多重される。限定受信方式の識別と契約情報等の個別情報であるEMM(Entitlement Management Message)パケットのPIDが記述されている。PIDとしては、PID=0x0001により示される。
【0076】
図10(b)には、キャリアごとに固有の内容を有する情報として、PATが示される。PATには、そのキャリア内のチャンネル情報と、各チャンネルの内容を表すPMTのPIDが記述されている。PIDとしては、PID=0x0000により示される。
【0077】
また、キャリアにおけるチャンネルごとの情報として、図10(c)に示すPMT(Program Map Table)のテーブルを有する。
PMTは、チャンネル別の内容が多重されている。例えば、図10(d)に示すような、各チャンネルを構成するコンポーネント(ビデオ/オーディオ等)と、デスクランブルに必要なECM(Encryption Control Message)パケットのPIDが記述されているPMTのPIDは、PATにより指定される。
【0078】
1−5.IRD
続いて、受信設備3に備えられるIRD12の一構成例について図11を参照して説明する。
【0079】
この図に示すIRD12において、入力端子T1には、パラボラアンテナ11のLNB15により所定の周波数に変換された受信信号を入力してチューナ/フロントエンド部51に供給する。
チューナ/フロントエンド部51では、CPU(Central Processing Unit)80からの伝送諸元等を設定した設定信号に基づいて、この設定信号により決定されるキャリア(受信周波数)を受信して、例えばビタビ復調処理や誤り訂正処理等を施すことで、トランスポートストリームを得るようにされる。
チューナ/フロントエンド部51にて得られたトランスポートストリームは、デスクランブラ52に対して供給される。また、チューナ/フロントエンド部51では、トランスポートストリームからPSIのパケットを取得し、その選局情報を更新すると共に、トランスポートストリームにおける各チャンネルのコンポーネントPIDを得て、例えばCPU80に伝送する。CPU80では、取得したPIDを受信信号処理に利用することになる。
【0080】
デスクランブラ52では、ICカード65に記憶されているデスクランブルキーデータをCPU80を介して受け取ると共に、CPU80によりPIDが設定される。そして、このデスクランブルキーデータとPIDとに基づいてデスクランブル処理を実行し、トランスポート部53に対して伝送する。
【0081】
トランスポート部53は、デマルチプレクサ70と、例えばDRAM等により構成されるキュー(Queue)71とからなる。キュー(Queue)71は、モジュール単位に対応した複数のメモリ領域が列となるようにして形成されているものとされ、例えば本実施の形態では、32列のメモリ領域が備えられる。つまり、最大で32モジュールの情報を同時に格納することができる。
【0082】
デマルチプレクサ70の概略的動作としては、CPU80のDeMUXドライバ82により設定されたフィルタ条件に従って、デスクランブラ52から供給されたトランスポートストリームから必要なトランスポートパケットを分離し、必要があればキュー71を作業領域として利用して、先に図7(e)〜(h)により示したような形式のデータを得て、それぞれ必要な機能回路部に対して供給する。
デマルチプレクサ70にて分離されたMPEGビデオデータは、MPEG2ビデオデコーダ55に対して入力され、MPEGオーディオデータは、MPEGオーディオデコーダ54に対して入力される。これらデマルチプレクサ70により分離されたMPEGビデオ/オーディオデータの個別パケットは、PES(Packetized Elementary Stream)と呼ばれる形式でそれぞれのデコーダに入力される。
【0083】
また、トランスポートストリームにおけるMHEGコンテンツのデータについては、デマルチプレクサ70によりトランスポートストリームからトランスポートパケット単位で分離抽出されながらキュー71の所要のメモリ領域に書き込まれていくことで、モジュール単位にまとめられるようにして形成される。そして、このモジュール単位にまとめられたMHEGコンテンツのデータは、CPU80の制御によってデータバスを介して、メインメモリ90内のDSM−CCバッファ91に書き込まれて保持される。
【0084】
また、トランスポートストリームにおける4倍速ATRACデータ(圧縮オーディオデータ)も、例えばトランスポートパケット単位で必要なデータがデマルチプレクサ70により分離抽出されてIEEE1394インターフェイス60に対して出力される。また、IEEE1394インターフェイス60を介した場合には、オーディオディオデータの他、ビデオデータ及び各種コマンド信号等を送出することも可能とされる。
【0085】
PESとしての形式によるMPEGビデオデータが入力されたMPEG2ビデオデコーダ55では、メモリ55Aを作業領域として利用しながらMPEG2フォーマットに従って復号化処理を施す。復号化されたビデオデータは、表示処理部58に供給される。
【0086】
表示処理部58には、上記MPEG2ビデオデコーダ55から入力されたビデオデータと、後述するようにしてメインメモリ90のMHEGバッファ92にて得られるデータサービス用のGUI画面等のビデオデータが入力される。表示処理部58では、このようにして入力されたビデオデータについて所要の信号処理を施して、所定のテレビジョン方式によるアナログオーディオ信号に変換してアナログビデオ出力端子T2に対して出力する。
これにより、アナログビデオ出力端子T2とモニタ装置14のビデオ入力端子とを接続することで、例えば先に図4に示したような表示が行われる。
【0087】
また、PESによるMPEGオーディオデータが入力されるMPEG2オーディオデコーダ54では、メモリ54Aを作業領域として利用しながらMPEG2フォーマットに従って復号化処理を施す。復号化されたオーディオデータは、D/Aコンバータ56及び光デジタル出力インターフェイス59に対して供給される。
【0088】
D/Aコンバータ56では、入力されたオーディオデータについてアナログ音声信号に変換してスイッチ回路57に出力する。スイッチ回路57では、アナログオーディオ出力端子T3又はT4の何れか一方に対してアナログ音声信号を出力するように信号経路の切換を行う。
ここでは、アナログオーディオ出力端子T3はモニタ装置14の音声入力端子と接続されるために設けられているものとされる。また、アナログオーディオ出力端子T4はダウンロードした楽曲をアナログ信号により出力するための端子とされる。
また、光デジタル出力インターフェイス59では、入力されたデジタルオーディオデータを光デジタル信号に変換して出力する。この場合、光デジタル出力インターフェイス59は、例えばIEC958に準拠する。
【0089】
メインメモリ90は、CPU80が各種制御処理を行う際の作業領域として利用されるものである。そして、本実施の形態では、このメインメモリ90において、前述したDSM−CCバッファ91と、MHEGバッファ92としての領域が割り当てられるようになっている。
MHEGバッファ92には、MHEG方式によるスクリプトの記述に従って生成された画像データ(例えばGUI画面の画像データ)を生成するための作業領域とされ、ここで生成された画像データはバスラインを介して表示処理部58に供給される。
【0090】
CPU80は、IRD12における全体制御を実行する。このなかには、デマルチプレクサ70におけるデータ分離抽出についての制御も含まれる。
また、獲得したMHEGコンテンツのデータについてデコード処理を施すことで、スクリプトの記述内容に従ってGUI画面(シーン)を構成して出力するための処理も実行する。
【0091】
このため、本実施の形態の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デコード等に関連する処理を実行する。
【0092】
MHEGデコーダブロック84は、DSM−CCデコーダブロック83により得られたMHEGコンテンツのデータ、つまり、DSM−CCバッファ91にて得られているMHEGコンテンツのデータにアクセスして、シーン出力のためのデコード処理を行う。つまり、そのMHEGコンテンツのスクリプトファイルにより規定されているオブジェクト間の関係を実現していくことで、シーンを形成するものである。この際、シーンとしてGUI画面を形成するのにあたっては、MHEGバッファ92を利用して、ここで、スクリプトファイルの内容に従ってGUI画面の画像データを生成するようにされる。
【0093】
DSM−CCデコーダブロック83及びMHEGデコーダブロック84間のインターフェイスには、U−U API(Application Portability Interface)が採用される。
U−U APIは、DSM Managerオブジェクト(DSMの機能を実現するサーバオブジェクト)にアクセスするためのインターフェイスであり、これにより、Service Gateway,Directory,File,Stream,Stream Eventなどのオブジェクトに対する操作を行う。
クライアントオブジェクトは、この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.本発明に至った背景
このようにDSM−CC方式を伝送規格として採用した本実施の形態のデジタル衛星放送システムでは、受信装置、つまりIRDのタイプとして、受信バッファの構成の点から2種類に分けることができる。
【0106】
1つは、IRDが、データサービス(GUI画面表示出力)対応のフラッシュメモリやハードディスクドライバなどの大容量の受信バッファを有する構成のものである。このような構成では、放送されているデータサービス(MHEGコンテンツ)全体を一度に受信して、受信バッファに保持させる。これにより、一旦データサービスを受信して取り込んだ後は、MHEGによるどのシーン(GUI画面)についても、メモリアクセスの待ち時間のみ待機するだけで即座に表示出力させることが可能になる。つまり、GUI画面(シーン)の切換のための操作をユーザが行ったような場合にも、次のシーンがほぼ直ぐさま表示されることになる。
このような場合、デマルチプレクサのフィルタ条件の切り換えによる多少のオーバーヘッドは、GUI画面の表示に関しては特に問題となるものではない。
【0107】
もう1つは、IRDのコストを下げるなどの理由から、上記のような大容量の受信バッファを持たないものである。先に説明した本実施の形態のIRD12がこれに相当する。この場合、データ放送サービス全体のデータをバッファリングすることができず、データ放送のデータを受信する受信単位であるモジュールのいくつかがバッファリングできるだけの受信バッファしか持たない。図11に示したIRD12では、この受信バッファはキュー71に相当し、前述のようにモジュールがバッファリングできるメモリ領域が32列設けられているのみである。
このようなIRDでは、逆に言えば、モジュ−ルの大きさは受信機のバッファメモリーサイズを上回ることはできない。このため、データサービス全体がいくつかのモジュールの集合で構成されることになり、その時々で表示に必要なモジュールだけを受信するなどの手順が必要になってくる。
前述したオブジェクトを抽出するための手順(Pr1)〜(Pr6)は、このような大容量の受信バッファを有さないIRDの構成に対応したものである。
【0108】
ここで、図14に、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がおかれることとしている。
【0109】
上記図14のディレクトリ構造を前提として、例えば或るデータサービスにおいて、データサービスの最初にアクセスすべきアプリケーションがService Gateway/app0/startupというファイルで、最初のシーンがscenedir0に含まれる静止画やテキストのファイルで構成されているとする。
そして、このようなデータサービスについてIRDにより受信を開始したとすれば、次のような手順となる。
(Pr11) PMTを参照して所望のデータサービスのPIDを取得し、そのPIDとtable_idとtable_id_extensionをフイルタ条件としてデマルチプレクサでフィルタリングを行い、DSIを得る。このDSIにはService GatewayオブジェクトのIORが書かれている。
(Pr12) このIORから、先に説明したオブジェクト抽出手順(Pr1)〜(Pr6)でService Gatewayオブジェクトを得る。
【0110】
Service Gatewayオブジェクトとディレクトリ・オブジェクトの2種類のBIOPメッセージの中には、そのディレクトリ直下のオブジェクトの名称、所在(lOR)、オブジェクトの種類といった情報が、bindingという属性情報として入っている。従ってオブジェクトの名称が与えられると、Service Gatewayから始まってディレクトリをーつづつ下にたどりながら、その名称のオブジェクトに行き着くことができる(同じ名称のオブジェクトが存在する場合は、違うところまで上位のバス名が必要になる)。そして、さらに次に示す手順に進む。
【0111】
(Pr13) Service Gatewayオブジェクトのbinding情報からapp0オブジェクトのIORを得て、オブジェクト抽出手順(Pr1)〜(Pr6)によりapp0オブジェクトを得る。
(Pr14) app0オブジェクトのbinding情報からstartupオブジェクトのIORを得て、オブジェクト抽出手順(Pr1)〜(Pr6)でstartupオブジェクトを得る。以下同様に最初のシーンであるscenedir0オブジェクトなどを得る。
【0112】
前述したように、モジュールを形成するオブジェクトの関係はDSM−CC方式のもとでは特に限定されるものではなく任意である。そこで、仮に図15に示すような、それぞれのオブジェクト1つがモジュール1つに対応するようなマッピングを取って地上局1から送信を行ったとする。なお、データサービスのディレクトリ構造に対するマッピングの処理は、DSM−CCエンコーダ44にてモジュールを形成する処理に際して、MHEGコンテンツのデータに対して行われるものである。
【0113】
この場合、IRD側において上記(Pr11)〜(Pr14)の手順によってオブジェクトを次々に得るには、一々新しいモジュールを受信することになる。このため、オブジェクトを得るごとにフィルタ条件を何度もデマルチプレクサ70に変更設定してフィルタリングする手順が必要であり、このようなフィルタリング動作の繰り返しによってシーンの取り込みが遅れ、その表示も遅くなるなどサービス性の低下を招くことになる。
データサ−ビスの全データの大きさや放送時に割り当てられる帯域にもよるが、カルーセル1回転の周期は数秒から、10秒以上に達することも考えられる。1回のフィルタリングには最悪で力ルーセル1回転分(平均1/2回転分)の待ち時間が生じるので、このフィルタリングの回数をできるだけ少なくすることがサービス性の向上に直接結びついてくる。
【0114】
また、シーンの切り換えについて考えてみると、図15に示すマッピングでは、表示中のシーンから次のシーンのファイルを呼び込むときには、上位のディレクトリからたどらなくてはならない場合が生じる。
例えば図15に示すマッピングの場合であれば、app0/scenedir0からapp0/scenedir1に移る場合は、既にapp0オブジェクトのBIOPメッセージからscenedir1のbinding情報が得られているが、app0/scenedir0からappN/scenedir0に移る場合は、Service GatewayオブジェクトのBIOPメッセージにあったappNオブジェクトのbinding情報からappN/scenedir0を辿ることになる。つまり、シーンを変更するために、先ずService Gatewayオブジェクトのモジュールを受信して、このBIOPメッセージからappNのbinding情報を得て、appN/scenedir0のディレクトリを識別してから、このappN/scenedir0のモジュールを受信せねばならなくなる。(但し、上記した動作は、1回目のappNをアクセスのときだけである。2回目以降はappNのbinding情報を保持していればこの手順は不要となる。)
つまり、このような場合もモジュールのフィルタリングによるシーン切り替えの待ち時間が大きくなる。
【0115】
3.地上局側のデータマッピング例
そこで、本実施の形態では、先に述べた(Pr1)〜(Pr6)によるオブジェクト抽出手順によっても、最初のシーン表示や、シーンの切り替えによる待ち時間が短縮されるように、次のようにオブジェクトのマッピング方法を提案するものである。
【0116】
図12は、本実施の形態としてのデータサービスのディレクトリ構造に対するマッピング例を示すものである。
図12においては、1つのシーンを構成するオブジェクト全てを1つのモジューとして纏め(モジュール2,3・・N)、それ以外のServiceGatewayを含む上位ディレクトリを1つのモジュール(モジュール1)にマッピングしている。ただし最初にアクセスするアプリケーションファイル「Startup」は、最初のシーンのモジュールとー緒のモジュール(モジュール2)にマッピングするようにする。
【0117】
このようなマッピングとされれば、まずService Gatewayのモジュール1を受信すれば、そのサブディレクトリの構成すべてが同じモジュールに入っているので、IRD12側ではディレクトリ構成全体をこのモジュール1の受信で得ることができる。
そして、これに続いてモジュール2を受信することになるが、このモジュール2は最初に提示するシーンのファイルがマッピングされて形成されたモジュールである。従って、このモジュール2のデータの取り込みが完了した段階で、最初のシーン出力に必要なオブジェクトの情報が全て得られることになる。つまり、先に示した(Pr5)の手順が完了した段階では、(Pr6)の手順もほぼ同時に完了させていることになる。実際には、キュー71にてモジュール2が得られたら、このモジュール2を1シーン分のデータとして、DSM−CCバッファ91に伝送するようにされる。なお、このような手順は、ルートディレクトリを含むモジュール1についても同様に行われる。
従って、この場合には、モジュール1、モジュール2と続けて、2回のモジュールの受信(獲得)さえ完了すれば、そのまま最初のシーンをの再生を始めることができる。また、さらに別のシーンに切り替わる場合は、最初に取り込んだディレクトリ・オブジェクトのbinding情報を参照すれば、直接所望のシーン・ディレクトリのモジュールを受信しにいくことができる。
【0118】
この場合でも、確かにシーン切り替えのオーバーヘッドは大きくないが、データサービスの最初のシーンの提示までに、モジュールを2回受信する必要がある。
【0119】
なお、図12に示すマッピングでは、上位ディレクトリをまとめたモジュール1に、多くのオブジェクトが入ることになるが、Service Gatewayとディレクトリの2種類のオブジェクトは、上記のようにそのディレクトリにbindされるオブジェクトの名称やIORといったデータ量としてはさほど大きくない情報の組み合わせで出来ているため、オブジェクトの数が多くても全体のデータ容量は大きくないものである。
【0120】
また図13に本実施の形態としての他のマッピング例を示す。ここでは、上位ディレクトリを纏めたものに、さらに最初にアクセスするアプリケーションファイル(startup)と最初のシーンのオブジェクトを1つのモジュール1にマッピングしている。これ以外の他のモジュール2・・Nは、図12に示したモジュール3・・N等と同様に、1シーンごとに必要とされるオブジェクトを纏めて形成されている。
このようなマッピングを施して送信した場合には、IRD側ではこのモジュール1だけを受信して、キュー71からDSM−CCバッファ91に伝送することで、すぐに最初のシーンを表示することができることになる。また、この段階で、ディレクトリ・オブジェクトのbinding情報が参照可能となるので、以降のシーンの切り換えに対応して必要なシーンのオブジェクトから成るモジュールに直ちにアクセスすることが可能になる。
【0121】
なお、上記マッピング例としては、1シーンを形成するオブジェクトが必ず1モジュールに収まるようにしているが、場合によっては、1シーンを形成する全てのオブジェクトの容量が大きく、モジュールとして規定されている最大サイズを超えるような場合、例えば、n番目のモジュールに対して或る1シーンを形成するオブジェクトを出来るだけ納めるようにし、n番目のモジュールに収まりきらなかった同一シーンを形成するオブジェクトによりn+1番目のモジュールを形成するようにする。そして、このn番目のモジュールとn+1番目のモジュールを連続させて、カルーセル方式で送信する。このようにすれば、n番目のモジュールとn+1番目のモジュールを2回受信する必要はあるが、比較的迅速にシーンの再生を行うことが出来る。
また、以降の説明においては、上述のようにして1シーンを形成することのできるオブジェクトが全て格納されることで形成されたモジュールのことを、「シーンモジュール」ともいうことにする。
【0122】
4.本実施の形態のキューへのモジュール割付
続いて、本発明の実施の形態の特徴となるIRD12側の受信処理として、キュー71へのモジュール割付について図16〜図20を参照して説明する。本実施の形態のIRD12では、上記した放送側(地上局側)のデータマッピングが行われることを前提として、以降説明するキュー71へのモジュール割付を行うことで、更に効率的に必要なシーンを得ることが可能になるものである。
【0123】
図16(a)には、トランスポート部53におけるデマルチプレクサ70とキュー71の構成、及びDSM−CCバッファ91のメモリ領域を概念的に示している。
【0124】
この図に示すトランスポート部53としては、デマルチプレクサ70と、キュー71を形成するメモリ領域Mem−1,Mem−2,Mem−3・・・Mem32が示されている。そして、これら各メモリ領域がモジュール単位のデータを蓄積可能とされている。
前述したように、デマルチプレクサ70に与えられたフィルタ条件に適合する種類のデータ(例えばセクション単位)がトランスポートストリームから分離抽出されるのであるが、この分離抽出されたセクションは、メモリ領域Mem−1〜Mem−32の何れかに対して格納される。そして、この動作が繰り返される結果、或るメモリ領域に対して上記フィルタ条件に適合して集められたセクションの集合より成るモジュールが形成されて、ここに蓄積されることになる。
【0125】
ここで、例えば、デマルチプレクサ70により、シーンAを形成するデータにより形成されるモジュールのデータを分離抽出して、メモリ領域Mem−2に格納したとする。そして、このシーンAのモジュールをGUI画面表示に使用する場合には、このシーンAのモジュールのデータをメモリ領域Mem−2からDSM−CCバッファに対して書き込みを行うようにされる。
つまり、受信したシーンのモジュールの一般的な伝送形態としては、一旦これをキューのメモリ領域にて蓄積した後、DSM−CCバッファ91に取り込むようにすることになる。そして、前述したようにDSM−CCバッファ91に取り込まれたシーンデータを、MHEGデコーダブロック84がアクセスしてロードし、MHEGバッファに取り込むことでGUI画面等のシーン出力が可能になる。
【0126】
ところで、ここでもメモリ領域Mem−1〜Mem32として示されているように、キュー71を形成するメモリ領域は本実施の形態では32列に限定されている。そして、これらのメモリ領域は、実際にはトランスポートストリームを受信する動作を行っている限りは、各種異なるフィルタ条件に適合して分離された、例えばMPEGストリームデータ等をはじめとする多種のモジュールデータによりほぼ占有されている状態にある。
このような状況は、例えば、MHEGデコーダブロック84がアクセスする必要があるとされる多数のシーンモジュールをDSM−CCバッファ91に取り込もうとしても、このシーンモジュールを一時保持するメモリ領域数が制限されていることで、例えば必要とされるシーンモジュールの多くを一度にキュー内の複数のメモリ領域に蓄積して、DSM−CCバッファ91に転送することが事実上困難であることを意味する。
また、DSM−CC方式では、モジュールの受信順(取込順)を特に規定してはいない。つまり、トランスポート部53においてどのような順序でシーンモジュールを抽出してメモリ領域に格納するのかは任意とされている。
【0127】
そこで、本実施の形態では、上記したメモリ領域数の制限が有ることを踏まえた上で、DSM−CCバッファ91に取り込む必要のあるモジュールが出来るだけ迅速にトランスポート部53にて得られるように、次のようにしてモジュール割付(受信順)を規定する。
【0128】
先に、説明したようにデータサービスのディレクトリ構造、及びこのディレクトリ構造に対するモジュールのマッピングは、例えば図12、図13に示すものとされるが、例えばapp0のディレクトリに関すれば、app0/startupと、app0/scenedir0/scsne0のオブジェクトを得さえすれば、app0のアプリケーションを形成するシーンの優先順位の情報を得ることが出来るようになっている。これはapp1〜Nまでの他のアプリケーションについても同じことがいえる。
ここでいう優先順位とは、例えば或るシーンの表示出力から他のシーンの表示出力に移行する(これを「トランジション」ともいう)場合には、上記他のシーンとして複数の候補があるのが通常であるが、これら複数のシーンの候補において、例えばユーザの操作によってシーン切り換えの必要があるとされたときに、切り換えが行われる可能性の高さに従って付されているものである。
【0129】
本実施の形態では、このシーンの優先順位の情報に基づいてモジュール割付を規定するが、これについて、再度図16を参照して説明する。
ここでは、説明の便宜上、トランスポート部53においてシーンモジュールを保持することのできるメモリ領域はMem−2のみとされて、他のメモリ領域は、それ以外の種類のモジュールを格納するために占有されているものとする。また、ここでは、app0のアプリケーションによりシーン出力する場合に関して説明する。
【0130】
ここで、トランスポート部53においては、既に上記したapp0/startupと、app0/scenedir0/scsne0のオブジェクトが属するモジュールを受信しており、例えばCPU80の制御処理部81では、app0のアプリケーションにおけるシーンの優先順位情報が得られているものとする。
そして、ここでは優先順位情報により、app0のディレクトリ構造化にある複数シーンについて、シーンA→シーンB→シーンC→シーンD・・のようにして優先順位が与えられているものとし、これらのシーンをDSM−CCバッファ91に出来るだけ取り込むことが必要であるとする。
【0131】
このような場合、制御処理部81では、先ず、優先順位が最も高いシーンAのモジュールがトランスポート部53のメモリ領域Mem−2に格納されるように制御を実行する。この制御に基づき、デマルチプレクサドライバ82は、シーンAのモジュールに適合するフィルタ条件をデマルチプレクサ70に対して設定する。これにより、図16(a)に示すようにして、シーンAのモジュールがメモリ領域Mem−2に格納され、DSM−CCバッファ91に転送する。
【0132】
続いては、制御処理部81は、シーンAに続く優先順位のシーンBを獲得するための処理として、シーンBのモジュールに適合するフィルタ条件をデマルチプレクサ70に対して設定するようにデマルチプレクサドライバ82に指示する。これにより、図16(b)に示すようにして、シーンBのモジュールがメモリ領域Mem−2に得られ、これをDSM−CCバッファ91に転送することになる。なお、図16(b)には、図16(a)に示した回路ブロックのうち、メモリ領域Mem−2とDSM−CCバッファ91のみを抜き出して示している。次に示す図16(c)も同様である。
【0133】
更に次は、シーンBに続く優先順位のシーンCを得るために、シーンCのモジュールに適合するフィルタ条件をデマルチプレクサ70に対して設定し、図16(c)に示すようにして、シーンCを得てDSM−CCバッファ91に転送する。
【0134】
以降、同様にして優先順位に従ったシーンのフィルタ条件をデマルチプレクサ70に設定して、そのシーンモジュールをメモリ領域Mem−2にて得て、これをDSM−CCバッファ91に転送していくようにされる。
【0135】
このような動作が行われる結果、DSM−CCバッファ91には、シーン出力のために必要、或いはシーン切り換え時において、次に必要となる可能性の高いシーンモジュールのデータがその優先順位に従って格納されることになる。
MHEGデコーダブロック84は、このようにしてDSM−CCバッファ91にて得られたシーンモジュールのデータにアクセスしてGUI画面などのシーン出力を行うが、例えばデータ放送中においてユーザの操作により所望のシーンの呼び出しの要求が有った場合、呼び出し要求のあったシーンのデータがDSM−CCバッファ91に既に保持されている可能性は非常に高く、ほぼ確実に呼び出し要求のあったシーンデータにアクセスして、これを即座に出力させることが可能になる。
【0136】
ところで、DSM−CCバッファ91の容量は当然のこととして有限であり、実際にはさほど多くの容量は割り当てられない。このため、例えばMHEGデコーダブロック84により使用することが想定される全てのシーンモジュールを格納することが出来ない場合がある。このために、例えば次のような不都合が生じることが想定される。
【0137】
ここで、例えば図17に示すようにして、あるアプリケーションのもとでシーンA,シーンB,シーンC,シーンD,シーンEの5つのシーンが用意されているとして、この各シーン間のトランジションの形態が図のように設定されている(このようなトランジジョンの規定はMHEGにより記述されている)ものとする。例えばシーンAであれば、シーンB,C,Eにトランジションが可能とされ、シーンBであればシーンA,Cにトランジション可能とされている。
【0138】
そして、DSM−CCバッファ91の容量として、最大で4つのシーンモジュールを格納することが限度であると仮定する。この条件の下で上記図17に示すシーンA〜Eの5つのモジュールが用意されたアプリケーションをMHEGデコーダブロック84が使用するとした場合、上記シーンA〜Eの5つのモジュールのうち、1つのシーンモジュールはDSM−CCバッファ91に格納できないことになる。
【0139】
上記した条件の下、例えば或る段階でシーンAを表示出力しており、このときDSM−CCバッファ91に取り込まれているシーンモジュールはシーンA,B,C,Dの4つであるとする。そして、この状態から、例えばユーザの操作によりシーンEの呼び出し要求が有ったとすると、これに応答してシーンAからシーンEにトランジションすることになる。
ところが、このときDSM−CCバッファ91にはシーンEのモジュールは無いことから、シーンEの呼び出し要求に応えるためには、シーンEのモジュールをカルーセルから新規に取り込む必要がある。この間、ユーザにとってはシーンAからシーンEの表示に移行するまでの待ち時間が生じることになる。
【0140】
そこで、このような不都合が出来るだけ解消されるようにするため、本実施の形態では、更に次のようなモジュール割付も行うようにされる。
【0141】
実際のMHEG方式によるデータサービスでは、或るアプリケーションにおける複数シーン間の優先順位は、現在表示出力中のシーンに依存して変更される場合がある。このような出力中のシーンに応じて変更される優先順位も、前述した優先順位情報に基づいて得ることが出来る。
そこで、本実施の形態では、MHEGデコーダブロック84のプログラムとして、現在あるシーンを出力しているときに、その出力中のシーンを基準として他のシーンの優先順位を管理する、ネクストシーンマネージャ(Next Scene Manager)を起動させることとする。
【0142】
ここで、ネクストシーンマネージャの管理例として、図17に示したシーンのうちで現在シーンAを出力中の場合に、ネクストシーンマネージャにより管理されている優先順位が図18に示したものであったとする。つまり、優先順位として(1)シーンA→(2)シーンC→(3)シーンE→(4)シーンB→(5)シーンDの順位で管理されているものとする。このような優先順位は、実際には、図に示すようなプライオリティ値によって決定される。このプライオリティ値が大きいほど優先順位は高いことになり、ここでは、シーンAに対する他のシーンのプライオリティ値として、シーンCが‘10’、シーンEが‘9’、シーンBが‘7’、シーンDが‘1’とされている。
そして、このときDSM−CCバッファ91に格納されているシーンモジュールは、図20(a)に示すように、シーンA,E,C,Bであるとする。
【0143】
この状態の下で、例えばシーンAからシーンCにトランジジョンするための要求が行われたとすると、MHEGデコーダブロック84では、図20(a)に示した格納状態にあるDSM−CCバッファ91からシーンCのデータにアクセスして、これを出力するための処理を実行する。
【0144】
また、MHEGデコーダブロック84では、シーンCにトランジションしたことに対応して、ネクストシーンマネージャによりシーンの優先順位を、例えば図19に示すように更新して管理する。
この図では、現在出力中のシーンCを筆頭に、(1)シーンC→(2)シーンB→(3)シーンA→(4)シーンD→(5)シーンEの順位であるとして管理している。また、この場合のシーンCに対する他のシーンのプライオリティ値は、それぞれシーンBが‘7’、シーンAが‘6’、シーンDが‘4’、シーンEが‘2’とされており、上記優先順位はこのプライオリティ値に従って決定されたものである。このように、現在出力中のシーンに応じて、シーン間の優先順位は変更される。
【0145】
そして、本実施の形態では、上記図19に示すようにして更新されたシーン間の優先順位に基づいて、次のようにしてDSM−CCバッファ91に格納されるシーンモジュールの内容を更新する。
例えば、CPU80は、上記図19に示す、現在ネクストシーンマネージャにより管理されているシーン間の優先順位と、図20(a)のDSM−CCバッファ91に格納されているシーンモジュールとの比較を行う。
すると、DSM−CCバッファ91には、図19に示す優先順位として1位のシーンC、2位のシーンB、3位のシーンA、及び5位(最下位)のシーンEが格納されており、4位のシーンDが格納されていないことが分かる。
【0146】
そこで、CPU80においては、DSM−CCバッファ91に格納されるシーンモジュールが、現在管理されている優先順位における上位4つのシーンとなるように制御を実行する。つまり、この場合であれば、図20(b)に示すようにして、シーンEの代わりにシーンDのモジュールがDSM−CCバッファ91に格納されるようにして、結果的に上位4つのシーンモジュールが格納されるようにするものである。
【0147】
このためには、先ず、例えばデマルチプレクサドライバ82からデマルチプレクサ70に対して、シーンDのモジュールを得るためのフィルタ条件を出力させるように、CPU80における制御処理部80が指示をするようにされる。これにより、キュー71においてシーンデータのモジュールのために割り当てられたメモリ領域にシーンDのモジュールが格納される。そして、このキュー71のメモリ領域に得られたシーンDのモジュールが、シーンEのモジュールと入れ替わるようにして、DSM−CCバッファ91に対する書き込み制御を実行するものである。この書き込み制御も、例えば制御処理部80が実行するようにされればよい。
なお、シーン切り換えに応じて変更されたシーンの優先順位と、それまでのDSM−CCバッファ91に格納されているシーンモジュールデータとの比較で、2以上のシーンモジュールを入れ替える必要が有れば、上記した制御動作に準じてこれらのシーンモジュールについての取り込みを行うようにされる。
【0148】
例えば、或るシーンを出力させている状態の下で、ユーザがシーンの切り換え操作を行う場合、やはり実際には、その時点でネクストシーンマネージャにより管理されている優先順位に従って、切り換えのシーンが選択される可能性が高い。
このため、上記のようにして、現在出力中のシーンに応じて決定されるシーンの優先順位の上位のシーンから優先的にDSM−CCバッファ91に取り込むように、トランスポート部53におけるモジュール割付を規定すれば、例えば、先に述べたように、シーンのトランジジョンの要求があったときに、このシーンのモジュールがDSM−CCバッファ91に格納されていないといった状況が生じる可能性は極力回避される。従って、ほとんどの場合、シーンの切り換え操作に応じて即座にシーンの切り換えが行われることになるものである。
【0149】
なお、シーン切り換えに応じて変更されたシーンの優先順位に応じて、例えば上記図20(a)から図20(b)に示したようにして、DSM−CCバッファ91の格納状態を遷移させるまでには、実際には、或る程度の時間がかかるのであるが、例えば、シーンCの出力が開始されて後において最初のシーン切り換え操作が行われるまでには、通常、或る程度の期間が存在する。つまり、シーンCが出力開始されてしばらくはユーザは、シーンCの画像を見ているのが普通である。そして、たいていはこの間にDSM−CCバッファ91におけるシーンデータの入れ替えはほぼ終了しているため、実用上は問題にはならないものである。
【0150】
続いて、上記図18〜図20により説明したモジュール割付を実現するための処理動作について、図21のフローチャートを参照して説明する。この図に示す処理は、CPU80が実行するものとされる。つまり、制御処理部81の全体制御に基づいて、デマルチプレクサドライバ82、DSM−CCデコーダブロック83、及びMHEGデコーダブロック84が適宜所要の制御処理を実行することにより実現されるものである。
また、この図においては、例えばユーザによるシーン切り換え要求のための操作等が行われたことでシーン切り換えが必要とされた場合における、シーンモジュール割付に関する対応処理を示している。
【0151】
この図に示すルーチンにおいては、先ずステップS101において、シーン切り換え前のネクストシーンマネージャのシーン優先順位に従って挙げられたシーン候補と、シーン切り換え後のネクストシーンマネージャのシーン優先順位に従って挙げられたシーン候補とを比較して、これらのシーン候補間で一致しないものをリストアップする。また、上記シーン候補間で共通に一致したシーンについては、シーン切り換えに応じてシーンネクストマネージャが扱うべき「シーンリスト」に対して登録が行われる。
この処理は、例えばMHEGデコーダブロック84において、ネクストシーンマネージャを起動させることにより実現される。
【0152】
続くステップS102においては、MHEGデコーダブロック84の処理として、上記ステップS101にてリストアップされた一致しないシーン候補のうちで、シーン切り換え前のシーン候補とされていたものについては削除し、シーン切り換え後に候補とされているシーンについてはシーンリストに追加するための処理が実行される。
この処理によって、シーン切り換えに応じて候補となる複数シーンが、シーンリストとして用意されることになる。
【0153】
続くステップS103においては、ネクストシーンマネージャの機能を用い、上記シーンリストとして登録されたシーンについて、シーン切り換えに応じて変更されたシーンの優先順位に従ってソートを実行するようにされる。
これにより、図18に示すネクストシーンマネージャの管理状態から、図19に示すネクストシーンマネージャの管理状態に移行することになる。
なお、上記ステップS101〜S103までに示す処理のうち、ステップS101,及びS102の処理については、先の図18及び図19に依る説明では特に言及していない。これは、図18、図19に示した場合においては、シーンAからシーンCへのシーン切り換えによっては、シーン候補の入れ替えが無いことによる。即ち、図18から図19の遷移に対応するシーン切り換えに際しては、ステップS101において一致しないシーンがリストアップされず、全てのシーンが一致したとして、シーンリストに登録されたことになる。
【0154】
ステップS103に続いては、ステップS104の処理が実行される。ここでは、上記ステップS103においてソートされたシーンリスト上において、優先順位的に最上位のシーンについての処理を開始する。つまり、このシーンを「現シーン」として扱って以降の処理を実行していくようにされる。
また、ステップS104においての「優先順位的に最上位のシーン」とは、現在出力中とされているシーン(図19であればシーンC)を除いて、最も優先順位の高いシーンが選択される。つまり、図19の場合で有ればシーンBが選択されることになる。但し、例えば図19に示す優先順位の管理状態が得られたとき、シーンCがDSM−CCバッファ91に格納されていない場合には、例外的にこのシーンCを現シーンとして扱うようにステップS104での処理が行われるものとする。
【0155】
続くステップS105においては、上記ステップS104にて選択された現シーンのデータにより形成されるモジュール(シーンモジュール)のデータサイズをチェックする。これは、例えば現シーンモジュールに対応する制御情報であるDII(図8参照)をカルーセルのデータから取り込み、例えばDSM−CCデコーダブロック83が、この取り込んだDIIにおけるモジュールのデータサイズを示す情報を参照することで識別が可能とされる。ここで得られた現シーンモジュールのデータサイズの情報は一時保持されて、後述するステップS107の判別処理に用いられる。
【0156】
ステップS106においては、現シーンモジュールがDSM−CCバッファ91に既に取り込まれている状態にあるか否かが判別され、ここで肯定結果が得られればステップS110に進んで、シーンリスト上で、これまでの現シーンに対して次の優先順位が与えられているシーンを現シーンとして選択して、この現シーンとしての処理を開始させるための処理を実行する。
これに対して、ステップS106において否定結果が得られた場合には、ステップS107の処理に移行する。
【0157】
ステップS107においては、現在のDSM−CCバッファ91の残り容量(データ取込可能容量)が、ステップS105にてチェックされた現シーンモジュールのサイズよりも大きいか否かを判別する。そして、肯定結果が得られた場合、つまり、現在のDSM−CCバッファ91の残り容量として、現シーンモジュールを取り込んで格納するだけの余裕があると判別された場合には、ステップS111に進んで現シーンモジュールのデータをカルーセルからキュー71に蓄積し、これをDSM−CCバッファ91に対して取り込んで格納するための処理が実行される。この処理を実現するためのCPU80の制御動作とこれに伴う各部の信号処理動作は、例えば図20の説明において述べたとおりである。
そして、上記ステップS111の処理を実行した後はステップS110の処理を経た上で、ステップS105の処理に戻るようにされる。
【0158】
また、ステップS107において否定結果が得られ、現在のDSM−CCバッファ91の残り容量が、ステップS105にてチェックされた現シーンモジュールのサイズよりも小さいと判別された場合には、ステップS108に進む。
ステップS108においては、現在のネクストシーンマネージャの優先順位管理と、現在DSM−CCバッファ91に格納されているシーンモジュールとを比較して、現在DSM−CCバッファ91に格納されているシーンモジュールにおいて、現在最も優先順位(プライオリティ)が低いものとして管理されているシーンモジュールを特定する。そして、次のステップS109において、この特定されたシーンモジュールのプライオリティが、現シーンよりも低いか否かを判別するようにされる。
【0159】
ステップS109において、ステップS108により特定されたシーンモジュールのプライオリティが現シーンよりも低いとされた場合には、ステップS112に進んで、この特定されたシーンモジュールをDSM−CCバッファから削除してステップS107に戻るようにされる。この処理により、現シーンモジュールが取り込み可能なDSM−CCバッファ91の残り容量が得られるまで、DSM−CCバッファ91から優先順位(プライオリティ)の最も低いシーンモジュール(但し現シーンよりもプライオリティが低いもののみが対象となる)が削除されていくことになる。
【0160】
そして、ステップS109において否定結果が得られた場合、つまり、ステップS108にて特定されたシーンモジュールのプライオリティが、現シーンよりも高いことが判別された場合であるが、この段階では、結果的に、DSM−CCバッファ91に格納されているシーンモジュールは、現在のネクストシーンマネージャにより管理されているシーンの優先順位に対応していることになる。つまり、先に説明した具体例に従えば、図19に示したネクストシーンマネージャの管理に対応して、図20(b)に示すシーンモジュールの格納状態が得られるものである。この場合には、図のようにして、これまでのモジュール割付のための処理が終了されることになる。
【0161】
なお、本発明としては、DSM−CC方式を採用した場合に限定されるものではなく、実施の形態において説明した送信フォーマットに準ずる伝送方式であれば本発明の適用が可能とされる。また、本発明が適用されるシステムとしてもデジタル衛星放送システムに限定されるものではなく、例えばケーブルテレビジョンなどの放送や、インターネット等において適用することも可能である。
【0162】
【発明の効果】
以上説明したように本発明は、伝送方式として、1シーン分のシーンデータが原則1モジュールを形成するものとされたうえで、1以上のモジュールからなる伝送データをカルーセル方式により伝送する場合に対応する受信装置として、カルーセル(伝送情報)から抽出してキュー(メモリ手段)に取り込むべきシーンデータとしてのモジュールを、シーンの優先順位に従って決定するように規定される。
例えば、キューに対するモジュールの取込順を特に規定しない場合、表示出力に必要なシーンデータを得て、これをシーンデータ格納手段(DSM−CCバッファ)に取り込むまでには相応の時間を要することになる。また、これを解消しようとして、目的のシーンデータとしてのモジュールが出来るだけ迅速にシーンデータ格納手段にて得られるようにするためには、多くのキュー数が必要となってしまう。
これに対して、本発明では、上記構成によって優先順位に従ってシーンデータとしてのモジュールを取り込むようにされるため、制限されたキュー数の構成のもとであっても、表示出力に必要、又は必要とされる可能性の高いシーンデータが比較的迅速に得られることになる。つまり、本発明では、キュー数が少なくてもシーン出力、及びシーン切り換えに迅速に対応できることになる。また、逆に言えば、本発明を適用せずに迅速なシーン出力、シーン切り換えを実現しようとした場合と比較して、キュー数を削減することが可能であり、それだけIRD(受信装置)の回路規模の縮小及び低コスト化を図ることが可能となる。
【0163】
また、現在出力されているシーンに応じて変更される優先順位に応じて、受信データのカルーセルから取り込むべきシーンデータとしてのモジュールが決定されるため、常にシーン表示の切り換えに対応して、シーンデータ格納手段には優先順位的に上位のシーンデータから優先的に格納されている状態が得られることになる。
この場合、シーン表示の切り換え操作によって選択されるシーンのシーンデータがシーンデータ格納手段に格納されている可能性が非常に高く、これにより、例えばユーザによってシーン表示の切り換え操作が行われたとしても、ほとんどの場合において、そのシーンの切り換えが迅速に行われることになる。この構成は、シーンデータ格納手段(DSM−CCバッファ)の容量に制限があって、多数のシーンデータを格納することが出来ないような条件の下で特に有効となる。
【図面の簡単な説明】
【図1】本発明の実施の形態のデジタル衛星放送受信システムの構成例を示すブロック図である。
【図2】本実施の形態における受信設備の構築例を示すブロック図である。
【図3】IRDのためのリモートコントローラの外観を示す正面図である。
【図4】放送画面とGUI画面との切り換えを示す説明図である。
【図5】地上局の構成例を示すブロック図である。
【図6】地上局から送信されるデータを示すチャート図である。
【図7】送信データの時分割多重化構造を示す説明図である。
【図8】DSM−CCによる送信フォーマットを示す説明図である。
【図9】トランスポートストリームのデータ構造図である。
【図10】PSIのテーブル構造を示す説明図である。
【図11】IRDの構成を示す説明図である。
【図12】本実施の形態としてのデータサービスのディレクトリ構造に対するマッピング例を示す説明図である。
【図13】本実施の形態としてのデータサービスのディレクトリ構造に対する他のマッピング例を示す説明図である。
【図14】データサービスのディレクトリ構造の一例を示す説明図である。
【図15】データサービスのディレクトリ構造に対するマッピング例を示す説明図である。
【図16】本実施の形態のシーンデータのモジュールの取込動作を示す説明図である。
【図17】シーンのトランジション例を示す説明図である。
【図18】図17に示すシーンのトランジション例に従った、ネクストシーンマネージャにおいて管理されるシーン優先順位例を示す説明図である。
【図19】図17に示すシーンのトランジション例に従った、ネクストシーンマネージャにおいて管理されるシーン優先順位例を示す説明図である。
【図20】図18から図19の遷移として示すシーン優先順位の変更に応じたシーンデータのモジュールの取込動作を示す説明図である。
【図21】本実施の形態のシーン切り換えに応じたモジュール割付けを実現するためのフローチャートである。
【符号の説明】
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 アナログオーディオ出力端子[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a receiving apparatus provided on the receiving facility side in a data service such as digital satellite broadcasting.And receiving methodIt is about.
[0002]
[Prior art]
In recent years, digital satellite broadcasting has been widely used. Digital satellite broadcasts, for example, are more resistant to noise and fading than existing analog broadcasts, and can transmit high-quality signals. In addition, the frequency utilization efficiency is improved, and the number of channels can be increased. Specifically, in the case of digital satellite broadcasting, it is possible to secure several hundred channels with one satellite. In such digital satellite broadcasting, a large number of specialized channels such as sports, movies, music, and news are prepared, and programs corresponding to each specialized content are broadcast on these specialized channels.
[0003]
Then, by using the digital satellite broadcasting system as described above, the user can download audio data such as music, or as so-called TV shopping, for example, the user can make a purchase contract for some product while watching the broadcast screen. It has been proposed to do so. In other words, as a digital satellite broadcasting system, data service broadcasting is performed in parallel with normal broadcasting contents.
[0004]
As an example, in the case of downloading music data, on the broadcast side, the music data is multiplexed and broadcasted in parallel with the broadcast program. Further, when downloading the music data, a GUI (Graphical User Interface) screen (that is, an operation screen for downloading) is displayed to allow the user to perform an interactive operation. The data for this is also multiplexed and broadcast.
The user who owns the receiving device displays and outputs a GUI screen for downloading music data by a predetermined operation on the receiving device while a desired channel is selected. Then, when the user performs an operation on the displayed operation screen, for example, data is supplied to a digital audio device connected to the receiving device, and this is recorded.
[0005]
By the way, as the GUI screen for downloading the music data as described above, for example, in addition to information such as part image data and text data forming the GUI screen, for further outputting sound according to a predetermined operation. Unit data (file) such as audio data is handled as an object, and the output mode of the object is defined by a scenario description by a predetermined method, thereby realizing the required display mode and the output mode of audio and the like for the operation screen. It is conceivable to configure as follows.
In addition, here, a display screen (including an output of sound or the like) that realizes a function in accordance with a certain purpose by being defined by the description information like the above GUI screen is referred to as a “scene”. Let's say. “Object” indicates unit information such as image, sound, text, etc. whose output mode is defined based on description information. At the time of transmission, the data file of the description information itself is also “object”. ”.
[0006]
The object for realizing the scene display and the sound output on the scene display is appropriately mapped to the directory structure of the data forming the scene to be broadcast on the broadcasting station side, and is according to a predetermined transmission method. Encoded and sent. For example, when a plurality of scenes are required in a certain program, the object data required for the plurality of scenes is appropriately mapped and transmitted.
On the receiving device side, decoding processing is performed according to the transmission method, for example, data as a group for each object required for a scene necessary for display is obtained, and this is output as a scene.
[0007]
[Problems to be solved by the invention]
Here, for the user who owns the receiving device, the waiting time until selecting a channel and displaying a scene for the first time, and the waiting time when switching the display from one scene to another is It is preferable to make it as short as possible in terms of a comfortable operating environment.
[0008]
For example, as a measure for quickly switching the scene display, a relatively large-capacity buffer is provided on the receiving device side, and data as a collection of objects for each scene captured from received data is stored in the buffer. It is conceivable to store it in the. In this way, it is possible to quickly switch to the next scene based on the data read from the buffer.
However, the provision of the buffer as described above in the receiving device will lead to an increase in the circuit scale and cost of the receiving device.SayThere will be disadvantages.
[0009]
[Means for Solving the Problems]
In view of the above-described problems, an object of the present invention is to make it possible to obtain necessary scene data as quickly as possible on the receiving apparatus side, for example, to switch scene output and the like quickly. Another object of the present invention is to realize this with a circuit as small as possible without providing a large-capacity buffer, for example.
[0010]
Therefore, the receiving device of the present invention isobjectContent data for presentation that is repeatedly transmitted by carousel transmission method is divided into blocks and transmittedScene dataA DDB message containing the module;A DSI message having an identifier of the carousel, information relating to the entire carousel and information for knowing the location of the root directory of the data service;DII message including information corresponding to each module included in the carouselWhenAnd the module included in the DDB message received by the receiving means is transmitted by the carousel.It is attached according to the probability of switching when it is necessary to switch scenes.Accumulating means for accumulating based on priority information, and information included in the DII message indicating the position of the module accumulated by the accumulating meansThe DSI message hasReferring to a root directory, among the modules in the DDB message, an acquisition unit that acquires a startup file based on the priority information, and a startup file acquired by the acquisition unit are stored by the storage unit. Output control means for outputting based on a script for performing display control on the presentation content data transmitted by the DDB message.The
[0011]
The receiving method of the present invention isobjectContent data for presentation that is repeatedly transmitted by carousel transmission method is divided into blocks and transmittedScene dataA DDB message containing the module;Carousel identifier, information related to the entire carousel,A DSI message having information for knowing the location of the root directory of the data service;DII message including information corresponding to each module included in the carouselWhenAnd the module included in the DDB message received by the reception procedure is transmitted by the carousel.It is attached according to the probability of switching when it is necessary to switch scenes.An accumulation procedure for accumulation based on priority information, and information included in the DII message, indicating the position of the module accumulated by the accumulation procedureIncluded in the DSI messageReferring to a root directory, among the modules in the DDB message, an acquisition procedure for acquiring a startup file based on the priority information, and a startup file acquired by the acquisition procedure are accumulated by the accumulation procedure. An output control procedure for outputting based on a script for performing display control on the presentation content data transmitted by the DDB message;Execute.
[0012]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described.
An example of a system to which the present invention is applied is a system in which a program is broadcast using digital satellite broadcasting, and information such as music data (audio data) related to the program can be downloaded on the receiving device side. Suppose that
[0013]
The following description will be made in the following order.
1. Digital satellite broadcasting system
1-1. overall structure
1-2. Operations for GUI screen
1-3. Ground station
1-4. Transmission format
1-5. IRD
2. Background to the present invention
3. Example of data mapping on the ground station side
4). Assigning modules to queues in this embodiment
[0014]
1. Configuration of digital satellite broadcasting system
1-1. overall structure
FIG. 1 shows the overall configuration of a digital satellite broadcasting system as the present embodiment. As shown in this figure, the
[0015]
The TV
[0016]
The
In the program broadcast of each audio channel, the same music is repeatedly broadcast for a predetermined unit time. Each audio channel is independent, and there are various possible uses. For example, one audio channel repeatedly broadcasts the latest Japanese pop songs for a certain period of time, and the other audio channel repeatedly broadcasts the latest foreign pop songs for a certain period of time. .
[0017]
The audio
[0018]
The
As the “GUI data”, for example, an MHEG (Multimedia Hypermedia Information Coding Experts Group) system is adopted. MHEG is an international standard for scenario description for producing multimedia information, procedures, operations, etc. and their combinations as objects, encoding those objects, and producing them as titles (for example, GUI screens). Is done. In this embodiment, MHEG-5 is adopted.
[0019]
The
In the present embodiment, video data transmitted from the TV
These data are encrypted using the key information from the
An example of the internal configuration of the
[0020]
A signal from the
In this case, a
[0021]
The
[0022]
As a schematic operation in the
[0023]
The
[0024]
Further, as the receiving
The IEEE 1394-compatible MD recorder /
[0025]
The
[0026]
As can be seen from the above description, in the system to which the present invention is applied, the
When this broadcast is received by the receiving
For example, if a GUI screen for audio (music) data download service is displayed and the operation is performed using this GUI screen, the audio data of the music desired by the user is downloaded and recorded in the
[0027]
In the present embodiment, data service broadcasts that provide specific services other than normal program broadcasts that involve operations on the GUI screen as described above may be interactive and may be referred to as “interactive broadcasts”. I will say.
[0028]
1-2. Operations for GUI screen
Here, an example of using the above-described interactive broadcast, that is, an example of an operation on the GUI screen will be schematically described with reference to FIGS. 3 and 4. Here, a case where music data (audio data) is downloaded will be described.
[0029]
First, the operation key of the
FIG. 3 shows an operation panel surface on which various keys are arranged in the
[0030]
The
The screen
The interactive switch key 104 is provided for switching between a normal broadcast screen and a GUI screen for a service associated with the broadcast program.
The channel key 106 is a key provided for sequentially switching the selected channel in the
[0031]
Note that the
[0032]
Next, a specific example of the operation on the GUI screen will be described with reference to FIG.
When the receiving
If the user operates the interactive switching key 104 of the
[0033]
In this GUI screen, first, an image based on video data from the TV
In the upper right part of the screen, a
[0034]
The user searches for music of interest while looking at the music names displayed in the
As a result, it is possible to audition the music with the cursor. That is, in each audio channel, the same music is repeatedly broadcasted for a predetermined unit time, so that the screen of the TV program display area 21A remains unchanged, and the
[0035]
Further, for example, when the cursor is moved to the
[0036]
The user presses the
Each time the music audio data is downloaded in this way, the history information is stored in the IC card in the
[0037]
In addition, the user presses the reservation recording button 25 to make a reservation for download in advance. When this button is pressed, the display on the GUI screen is switched, and a list of songs that can be reserved is displayed on the entire screen. For example, this list can display music searched in units of one hour, one week, or one unit. When the user selects a music piece for which a download reservation is to be made from this list, the information is registered in the
[0038]
When the user wants to confirm the downloaded music, the user can press the recording history button 27 to display a list of already downloaded music on the entire screen.
[0039]
As described above, in the
[0040]
Although the details will be described later, the display of the GUI screen as shown in FIG. 4B, the display change on the GUI screen in response to the user's operation on the GUI screen, and the audio output are the same as the above-described MHEG method. This is realized by defining the relationship between objects by a scenario description based on the scenario description. The object here is image data as parts corresponding to each button shown in FIG. 4B and material data displayed in each display area.
In this specification, the relationship between objects is defined by scenario description such as this GUI screen, thereby realizing an information output mode (image display, audio output, etc.) according to a certain purpose. This environment is called “scene”. In addition, the scenario forming file itself is included as an object forming one scene.
[0041]
As described above, in the digital satellite broadcasting system to which the present invention is applied, broadcast programs are distributed and audio data of music is distributed using a plurality of audio channels. Then, it is possible to search for a desired music using a list of delivered music and the like and easily store the audio data in the
Various services other than program provision in the digital satellite broadcasting system can be considered in addition to the music data download described above. For example, after broadcasting a product introduction program called so-called TV shopping, it may be possible to prepare a GUI screen that allows a purchase contract to be made.
[0042]
1-3. Ground station
So far, the outline of the digital satellite broadcasting system as the present embodiment has been described, but hereinafter, this system will be described in more detail. First, the configuration of the
[0043]
In the following description, the following is assumed.
In the present embodiment, the DSM-CC (Digital Storage Media Command and Control) protocol is used for transmission from the
As already known, the DSM-CC (MPEG-part6) method can retrieve (retrieve) an MPEG encoded bitstream stored in a digital storage medium (DSM) via some network, for example. It defines commands and control methods for storing streams in the DSM. In this embodiment, this DSM-CC method is adopted as a transmission standard in the digital satellite broadcasting system.
In order to transmit content (a set of objects) of a data broadcasting service (for example, a GUI screen) by the DSM-CC method, it is necessary to define a content description format. In the present embodiment, the MHEG described above is adopted as the definition of the description format.
[0044]
In the configuration of the
[0045]
In the music
The MPEG audio data registered in the
[0046]
Further, in the additional sound
[0047]
In the GUI
[0048]
The GUI material data registered in the
[0049]
In other words, as data transmitted to the
Each of the above-mentioned data is called a so-called mono-media. In the
Then, for example, a scenario description file (script) that defines the relationship between the objects so as to obtain the display mode of the scene (GUI screen) and the output mode of the image and sound according to the operation as described in FIG. At the same time, the contents of MHEG-5 are created.
In the GUI screen as shown in FIG. 4B, image / audio data (MPEG video data, MPEG audio data) based on the material data of the TV
Therefore, as the scenario description file, in the
[0050]
The MHEG content data transmitted from the
[0051]
The data of the MHEG content obtained by the
The DSM-
[0052]
In the
[0053]
The output of the
[0054]
1-4. Transmission format
[0055]
Next, the transmission format of the present embodiment defined based on the DSM-CC scheme will be described.
FIG. 6 shows an example of data at the time of transmission output from the
[0056]
As shown in FIG. 6, in the event from the time t1 to the time t2, a program having a predetermined content A1 is broadcast by a normal moving image program broadcast. In the event starting from time t2, a program as content A2 is broadcast. This normal program is broadcasted with moving images and audio.
[0057]
MPEG audio channels (1) to (10) are prepared, for example, for 10 channels CH1 to CH10. At this time, in each audio channel CH1, CH2, CH3... CH10, the same music is repeatedly transmitted while one event is broadcast. That is, during the event period from time t1 to time t2, the music B1 is repeatedly transmitted on the audio channel CH1, the music C1 is repeatedly transmitted on the audio channel CH2, and similarly, the music K1 is repeatedly transmitted on the audio channel CH10. It will be. This is the same for the quadruple speed ATRAC audio channels (1) to (10) shown below.
[0058]
That is, in FIG. 6, the same music numbers are the same in (), which are the channel numbers of the MPEG audio channel and the quadruple speed ATRAC audio channel. The numbers in parentheses () that are channel numbers of the additional audio information are additional audio information added to audio data having the same channel number. Furthermore, still image data and text data transmitted as GUI data are also formed for each channel. These data are time-division multiplexed in the MPEG2 transport packet as shown in FIGS. 7A to 7D and transmitted in the
[0059]
Of the transmission data shown in FIG. 6 and FIG. 7, at least GUI data used for data service (interactive broadcasting) is logically formed as follows in accordance with the DSM-CC system. Is. Here, the description is limited to the data of the transport stream output from the DSM-
[0060]
As shown in FIG. 8A, all the data broadcasting services of the present embodiment transmitted by the DSM-CC method are included in a root directory named Service Gateway. As objects included in the Service Gateway, there are types such as a directory, a file, a stream, a stream event, and a stream event.
[0061]
Of these, the files are individual data files such as still images, audio, text, and scripts written in MHEG.
The stream includes, for example, information linked to other data services and AV streams (MPEG video data, audio data as TV program material, MPEG audio data as music material, ATRAC audio data, etc.).
The stream event also includes link information and time information.
A directory is a folder for collecting data related to each other.
[0062]
In the DSM-CC system, as shown in FIG. 8B, these unit information and Service Gateway are regarded as units called objects, and each is converted into a format called BIOP message.
In the description related to the present invention, the distinction between the three objects of file, stream, and stream event is not essential, and in the following description, these will be described by representing the object as a file.
[0063]
In the DSM-CC system, a data unit called a module shown in FIG. 8C is generated. This module includes one or more objects that are converted into BIOP messages as shown in FIG.And a BIOP header is addedThis is a variable-length data unit to be formed, and is a buffering unit for received data on the receiving side to be described later.
In the DSM-CC system, the relationship between objects when one module is formed by a plurality of objects is not particularly defined or restricted. That is, in an extreme case, even if one module is formed by two or more objects between scenes that are completely irrelevant, it does not violate the rules under the DSM-CC system.
[0064]
In order to transmit the module in a format referred to as a section defined by the MPEG2 format, as shown in FIG. 8 (d), the module is mechanically divided into data units of a fixed length called a "block" in principle. However, the last block in the module does not need to have a specified fixed length. As described above, the block division is caused by the provision that one section must not exceed 4 KB in the MPEG2 format.
In this case, the data unit as the block and the section are synonymous.
[0065]
The block obtained by dividing the module in this way is converted into a message format of DDB (Download Data Block) with a header added as shown in FIG.
[0066]
In parallel with the conversion to DDB, DSI (Download Server Initiate) and DII (Download Info Indication) Is generated.
The DSI and DII are information necessary for acquiring a module from received data on the receiving side (IRD 12). The DSI mainly includes an identifier of a carousel (module) described below, information related to the entire carousel ( Information such as the time for the carousel to rotate once, the time-out value for carousel rotation). It also has information for knowing the location of the root directory (Service Gateway) of the data service (in the case of the object carousel method).
[0067]
The DII is information corresponding to each module included in the carousel, and includes information such as the size, version, and timeout value of the module for each module.
[0068]
Then, as shown in FIG. 8 (f), the three types of messages DDB, DSI, and DII are periodically and repeatedly sent in correspondence with the data unit of the section. As a result, the receiver side can receive, for example, a module including an object necessary for obtaining a target GUI screen (scene) at any time.
In this specification, such a transmission method is referred to as a “carousel method” compared to a carousel, and a data transmission form schematically represented as shown in FIG. 8F is referred to as a carousel.
The “carousel method” can be divided into a “data carousel method” level and an “object carousel method” level. In particular, the object carousel method is a method for transferring an object having attributes such as a file, a directory, a stream, and a service gateway as data using the carousel, and is different from the data carousel method in that the directory structure can be handled. In the system of the present embodiment, the object carousel method is adopted.
[0069]
Further, the GUI data transmitted by the carousel as described above, that is, the data output from the DSM-
FIG. 9A shows a transport stream. This transport stream is a bit string defined in the MPEG system, and is formed by concatenating 188-byte fixed-length packets (transport packets) as shown in the figure.
[0070]
Each transport packet includes, as shown in FIG. 9B, an adaptation field for including additional information in a header and a specific individual packet, and a payload (data area) indicating packet contents (video / audio data, etc.). It consists of.
[0071]
For example, the header is actually 4 bytes, and as shown in FIG. 9 (c), there is always a synchronization byte at the beginning, and a PID (identification information of the packet) at a predetermined position after this. Packet_ID), scramble control information indicating the presence / absence of scramble, and adaptation field control information indicating the presence / absence of a subsequent adaptation field, payload, and the like.
[0072]
Based on the control information, the receiving device can descramble the packet, and the demultiplexer can separate and extract the necessary packets such as video / audio / data. It is also possible to reproduce time information that is a reference for video / audio synchronous reproduction.
[0073]
As can be seen from the above description, video / audio / data packets for a plurality of channels are multiplexed in one transport stream. In addition, a channel selection called PSI (Program Specific Information) is selected. SI (Service Information) for realizing services such as EMG / ECM, EPG, and other information necessary for control signals, limited reception (reception function that determines whether a paid channel can be received depending on the individual contract status) Are multiplexed simultaneously. Here, PSI will be described.
[0074]
As shown in FIG. 10, the PSI is composed of four tables. Each table is represented in a format conforming to the MPEG System called section format.
FIG. 10A shows a network information table (NIT) and a conditional access table (CAT).
In the NIT, the same content is multiplexed on all carriers. A transmission specification (polarization plane, carrier frequency, convolution rate, etc.) for each carrier and a list of channels multiplexed there are described. The PID of NIT is PID = 0x0010.
[0075]
In the CAT, the same content is multiplexed on all carriers. A PID of an EMM (Entitlement Management Message) packet, which is individual information such as identification of the limited reception method and contract information, is described. The PID is indicated by PID = 0x0001.
[0076]
FIG. 10B shows PAT as information having specific contents for each carrier. PAT describes channel information in the carrier and PMT PID representing the contents of each channel. The PID is indicated by PID = 0x0000.
[0077]
Further, as information for each channel in the carrier, a PMT (Program Map Table) table shown in FIG.
In the PMT, contents for each channel are multiplexed. For example, as shown in FIG. 10D, the PID of the PMT in which the components (video / audio, etc.) constituting each channel and the PID of an ECM (Encryption Control Message) packet necessary for descrambling are described, Specified by PAT.
[0078]
1-5. IRD
Next, a configuration example of the
[0079]
In the
The tuner /
The transport stream obtained by the tuner /
[0080]
The
[0081]
The transport unit 53 includes a
[0082]
As a schematic operation of the
The MPEG video data separated by the
[0083]
Further, the data of the MHEG content in the transport stream is collected in units of modules by being written in a required memory area of the
[0084]
Also, for quad-speed ATRAC data (compressed audio data) in the transport stream, for example, necessary data for each transport packet is separated and extracted by the
[0085]
The
[0086]
The
Thus, by connecting the analog video output terminal T2 and the video input terminal of the
[0087]
In addition, the
[0088]
The D /
Here, the analog audio output terminal T3 is provided to be connected to the audio input terminal of the
The optical
[0089]
The main memory 90 is used as a work area when the
The
[0090]
The
Further, by performing a decoding process on the acquired MHEG content data, a process for configuring and outputting a GUI screen (scene) according to the description content of the script is also executed.
[0091]
For this reason, the
The DeMUX driver 82 sets the filter condition in the
The DSM-
[0092]
The
[0093]
As an interface between the DSM-
The U-U API is an interface for accessing a DSM Manager object (a server object that realizes a DSM function), and performs operations on objects such as Service Gateway, Directory, File, Stream, and Stream Event.
Client objects can perform operations on these objects by using this API.
[0094]
Here, an operation example for extracting a target object necessary to form one scene from the transport stream under the control of the
[0095]
In DSM-CC, IOR (Interoperable Object Reference) is used to indicate the location of an object in a transport stream. The IOR includes an identifier corresponding to a force rucell for finding an object, an identifier of a module in which the object is included (hereinafter referred to as module_id), an identifier for specifying an object in one module (hereinafter referred to as object_key), It includes tag (association_tag) information for identifying DII having information on the module in which the object is included.
The DII having module information includes information such as module_id, module size, and version for each of one or more modules, and tag (association_tag) information for identifying the module.
[0096]
When the IOR extracted from the transport stream is identified by the
(Pr1) The DeMUX driver 82 of the
(Pr2) This PID and table_id_extension are set for the
(Pr3) In DII, association_tag of the module corresponding to module_id included in the previous IOR is obtained.
(Pr4) An ES having the same value as the association_tag is searched from the ES loop (carousel) of the PMT, and the PID is obtained. The target module is included in the ES having this PID.
(Pr5) The PID and module_id are set as filter conditions, and filtering by the
(Pr6) The object corresponding to the object_key included in the previous IOR is extracted from this module. This is the target object. The object extracted from this module is written in a predetermined area of the DSM-
For example, by repeating the above operation and collecting the target objects and storing them in the DSM-
[0097]
The
[0098]
An IC card 65 is inserted into the
[0099]
The modem 63 is connected to the
[0100]
Here, the flow of the signal of the video / audio source in the
As shown in FIG. 4A, when a normal program is output, MPEG video data and MPEG audio data of a necessary program are extracted from the input transport stream, and decoding processing is performed for each. Applied. Then, the video data and the MPEG audio data are output to the analog video output terminal T2 and the analog audio output terminal T3, respectively, so that the
[0101]
When the GUI screen shown in FIG. 4B is output, the transport unit 53 separates and extracts the MHEG content data necessary for the GUI screen (scene) from the input transport stream. The data is taken into the DSM-
[0102]
When a music is selected from the
[0103]
When the
[0104]
Here, particularly when the IEEE 1394-compliant MD recorder /
[0105]
2. Background to the present invention
As described above, in the digital satellite broadcasting system of the present embodiment adopting the DSM-CC system as a transmission standard, the receiving device, that is, the IRD type, can be divided into two types in terms of the configuration of the receiving buffer.
[0106]
One is a configuration in which the IRD has a large-capacity reception buffer such as a flash memory and a hard disk driver compatible with the data service (GUI screen display output). In such a configuration, the entire broadcast data service (MHEG content) is received at once and held in the reception buffer. As a result, once the data service is received and imported, any scene (GUI screen) by MHEG can be immediately displayed and output by simply waiting for the memory access waiting time. That is, even when the user performs an operation for switching the GUI screen (scene), the next scene is displayed almost immediately.
In such a case, the slight overhead due to the switching of the filter conditions of the demultiplexer is not particularly problematic with respect to the display of the GUI screen.
[0107]
The other is one that does not have such a large-capacity reception buffer for reasons such as reducing the cost of IRD. The
Conversely, in such an IRD, the size of the module cannot exceed the buffer memory size of the receiver. For this reason, the entire data service is composed of a set of several modules, and procedures such as receiving only modules necessary for display are sometimes required.
The above-described procedures (Pr1) to (Pr6) for extracting objects correspond to the configuration of the IRD that does not have such a large-capacity reception buffer.
[0108]
Here, FIG. 14 shows a directory structure example of a file (MHEG application file) as a data service conforming to the MHEG method. As described above, the object carousel method is characterized in that it can handle this directory structure.
Normally, the entrance to the Service Domain (MHEG application file) is always a file called app0 / startup that is directly under the Service Gateway.
Basically, application directory (app0, app1... AppN) is located under Service Domain (Service Gateway), and application file called startup and directory0 of each scene that constitutes application (application0). scene1 ...). Further, under the scene directory, each content file constituting the MHEG scene file and the scene is placed.
[0109]
Assuming the directory structure of FIG. 14 above, for example, in a certain data service, the application to be accessed first in the data service is a file called Service Gateway / app0 / startup, and the first scene is a still image or text included in the scene0. Suppose it consists of a file.
If reception of such a data service is started by IRD, the procedure is as follows.
(Pr11) The PID of the desired data service is acquired with reference to the PMT, and filtering is performed by the demultiplexer using the PID, table_id, and table_id_extension as filter conditions, and the DSI is obtained. In this DSI, the IOR of the Service Gateway object is written.
(Pr12) A Service Gateway object is obtained from this IOR by the object extraction procedures (Pr1) to (Pr6) described above.
[0110]
In two types of BIOP messages, a Service Gateway object and a directory object, information such as the name, location (lOR), and object type of the object directly under the directory is included as attribute information called binding. Thus, given the name of an object, you can get to the object with that name, starting from the Service Gateway and going down the directory one after another (if there is an object with the same name, Name is required). Then, the process proceeds to the following procedure.
[0111]
(Pr13) The IOR of the app0 object is obtained from the binding information of the Service Gateway object, and the app0 object is obtained by the object extraction procedures (Pr1) to (Pr6).
(Pr14) The IOR of the startup object is obtained from the binding information of the app0 object, and the startup object is obtained by the object extraction procedures (Pr1) to (Pr6). In the same manner, a sceneir0 object that is the first scene is obtained.
[0112]
As described above, the relationship between the objects forming the module is not particularly limited under the DSM-CC method and is arbitrary. Therefore, it is assumed that transmission is performed from the
[0113]
In this case, on the IRD side, new modules are received one by one in order to obtain objects one after another by the procedures (Pr11) to (Pr14). For this reason, every time an object is obtained, it is necessary to change and set the filter condition in the
Depending on the size of all data in the data service and the bandwidth allocated at the time of broadcasting, the carousel rotation period may reach several seconds to 10 seconds or more. A single filtering operation has a worst case waiting time of one rotation of the power loose cell (an average of 1/2 rotation). Therefore, reducing the number of times of filtering as much as possible directly leads to improvement in serviceability.
[0114]
Considering the switching of scenes, in the mapping shown in FIG. 15, when a file of the next scene is called from the currently displayed scene, it may be necessary to follow the upper directory.
For example, in the case of the mapping shown in FIG. 15, when moving from app0 / scendir0 to app0 / scendir1, the binding information of sendir1 has already been obtained from the BIOP message of the app0 object, but from app0 / scendir0 to appN / scendir0 When moving, appN / scendir0 is traced from the binding information of the appN object in the BIOP message of the Service Gateway object. That is, in order to change the scene, first, the module of the Service Gateway object is received, the binding information of appN is obtained from this BIOP message, the directory of appN / scenedir0 is identified, and then the module of appN / scendir0 is changed. You have to receive it. (However, the above-described operation is only when the first appN is accessed. After the second time, this procedure is unnecessary if the binding information of appN is held.)
That is, in such a case, the waiting time for scene switching due to module filtering increases.
[0115]
3. Example of data mapping on the ground station side
Therefore, in the present embodiment, the object extraction procedure according to (Pr1) to (Pr6) described above is performed as follows so that the waiting time due to the initial scene display and scene switching is reduced. A mapping method is proposed.
[0116]
FIG. 12 shows an example of mapping to the directory structure of the data service as the present embodiment.
In FIG. 12, all objects constituting one scene are grouped as one module (
[0117]
With this mapping, if the
Subsequently, the
Therefore, in this case, if the reception (acquisition) of two modules is completed after the
[0118]
Even in this case, the overhead of scene switching is certainly not large, but it is necessary to receive the module twice before the presentation of the first scene of the data service.
[0119]
In the mapping shown in FIG. 12, many objects are included in the
[0120]
FIG. 13 shows another example of mapping as the present embodiment. Here, an application file (startup) to be accessed first and an object of the first scene are mapped to one
When transmitting with such mapping, the IRD side can receive only this
[0121]
In the above mapping example, an object forming one scene is always contained in one module. However, in some cases, the capacity of all objects forming one scene is large, and the maximum defined as a module is used. When the size is exceeded, for example, an object that forms a certain scene is accommodated as much as possible in the nth module, and the n + 1th object is formed by an object that forms the same scene that does not fit in the nth module. Try to form a module. Then, the nth module and the (n + 1) th module are continuously transmitted and transmitted by the carousel method. In this way, it is necessary to receive the nth module and the (n + 1) th module twice, but the scene can be reproduced relatively quickly.
In the following description, a module formed by storing all objects that can form one scene as described above is also referred to as a “scene module”.
[0122]
4). Assigning modules to queues in this embodiment
Subsequently, module allocation to the
[0123]
FIG. 16A conceptually shows the configuration of the
[0124]
As the transport unit 53 shown in this figure, a
As described above, the type of data (for example, section unit) that matches the filter condition given to the
[0125]
Here, for example, it is assumed that module data formed by the data forming the scene A is separated and extracted by the
That is, as a general transmission mode of the received scene module, it is temporarily stored in the memory area of the queue and then taken into the DSM-
[0126]
By the way, as shown here as the memory areas Mem-1 to Mem32, the memory areas forming the
In such a situation, for example, even if a large number of scene modules that are supposed to be accessed by the
In the DSM-CC system, the module reception order (capture order) is not particularly defined. That is, the order in which scene modules are extracted and stored in the memory area in the transport unit 53 is arbitrary.
[0127]
Therefore, in the present embodiment, in consideration of the limitation on the number of memory areas described above, a module that needs to be loaded into the DSM-
[0128]
As described above, the directory structure of the data service and the mapping of the module to this directory structure are as shown in FIGS. 12 and 13, for example. For the directory of app0, for example, app0 / startup and As long as an object of app0 / scenedir0 / scsne0 is obtained, it is possible to obtain information on the priority of the scene forming the application of app0. The same can be said for other applications from app1 to N.
The priority order here means that, for example, when shifting from the display output of a certain scene to the display output of another scene (this is also referred to as “transition”), there are a plurality of candidates as the other scenes. Usually, in the plurality of scene candidates, for example, when it is determined that the scene needs to be switched by the user's operation, the scenes are assigned according to the possibility of switching.
[0129]
In the present embodiment, the module assignment is defined based on the priority order information of the scene. This will be described again with reference to FIG.
Here, for convenience of explanation, the memory area that can hold the scene module in the transport unit 53 is only Mem-2, and the other memory area is occupied to store other types of modules. It shall be. Here, a case where a scene is output by an application of app0 is described.
[0130]
Here, the transport unit 53 has already received the module to which the above-described app0 / startup and app0 / scenedir0 / scsne0 objects belong. For example, the control processing unit 81 of the
Here, it is assumed that priorities are given in the order of scene A → scene B → scene C → scene D... With respect to a plurality of scenes in the directory structure of app0 based on the priority order information. Is required to be taken into the DSM-
[0131]
In such a case, the control processing unit 81 first executes control so that the module of the scene A having the highest priority is stored in the memory area Mem-2 of the transport unit 53. Based on this control, the demultiplexer driver 82 sets a filter condition suitable for the module of the scene A for the
[0132]
Subsequently, the control processing unit 81 sets a filter condition suitable for the module of the scene B to the
[0133]
Next, in order to obtain the priority scene C following the scene B, a filter condition suitable for the module of the scene C is set for the
[0134]
Thereafter, similarly, the scene filter condition according to the priority order is set in the
[0135]
As a result of such operations, the DSM-
The
[0136]
By the way, the capacity of the DSM-
[0137]
Here, for example, as shown in FIG. 17, assuming that five scenes of scene A, scene B, scene C, scene D, and scene E are prepared under a certain application, transitions between these scenes are prepared. It is assumed that the form is set as shown in the figure (the definition of such a transition is described by MHEG). For example, scene A can be transitioned to scenes B, C, and E, and scene B can be transitioned to scenes A and C.
[0138]
Assume that the maximum capacity of the DSM-
[0139]
Under the above conditions, for example, the scene A is displayed and output at a certain stage, and at this time, the scene modules taken into the DSM-
However, since there is no scene E module in the DSM-
[0140]
Therefore, in order to eliminate such inconvenience as much as possible, in the present embodiment, the following module assignment is also performed.
[0141]
In an actual data service based on the MHEG method, the priority order among a plurality of scenes in a certain application may be changed depending on the scene currently being displayed and output. The priority order changed according to the scene being output can also be obtained based on the priority order information described above.
Therefore, in the present embodiment, as a program of the
[0142]
Here, as an example of management of the next scene manager, when the scene A is currently being output among the scenes shown in FIG. 17, the priorities managed by the next scene manager are those shown in FIG. To do. That is, it is assumed that the priority is managed in the order of (1) scene A → (2) scene C → (3) scene E → (4) scene B → (5) scene D. Such priorities are actually determined by priority values as shown in the figure. The higher the priority value is, the higher the priority is. Here, as the priority values of the other scenes with respect to the scene A, the scene C is “10”, the scene E is “9”, the scene B is “7”, the scene D is set to “1”.
At this time, the scene modules stored in the DSM-
[0143]
Under this state, for example, if a request for transition from scene A to scene C is made, the
[0144]
Further, in the
In this figure, the current output scene C is the top, and (1) scene C → (2) scene B → (3) scene A → (4) scene D → (5) scene E is managed in order. ing. In this case, the priority values of the other scenes with respect to the scene C are “7” for the scene B, “6” for the scene A, “4” for the scene D, and “2” for the scene E, respectively. The priority is determined according to this priority value. In this way, the priority order between scenes is changed according to the currently output scene.
[0145]
In the present embodiment, the contents of the scene module stored in the DSM-
For example, the
Then, the DSM-
[0146]
Therefore, in the
[0147]
For this purpose, first, for example, the
If it is necessary to replace two or more scene modules by comparing the priority order of the scene changed according to the scene switching and the scene module data stored in the DSM-
[0148]
For example, when a user performs a scene switching operation while a certain scene is being output, the switching scene is actually selected according to the priority order managed by the next scene manager at that time. There is a high possibility of being.
Therefore, as described above, the module allocation in the transport unit 53 is performed so as to preferentially capture into the DSM-
[0149]
Note that, depending on the priority order of the scenes changed according to the scene switching, for example, as shown in FIGS. 20A to 20B, until the storage state of the DSM-
[0150]
Next, processing operations for realizing the module assignment described with reference to FIGS. 18 to 20 will be described with reference to the flowchart of FIG. The processing shown in this figure is executed by the
In addition, this figure shows the corresponding processing related to the scene module assignment when the scene switching is required due to, for example, an operation for a scene switching request by the user.
[0151]
In the routine shown in this figure, first, in step S101, the scene candidates listed according to the scene priority of the next scene manager before the scene change, and the scene candidates listed according to the scene priority of the next scene manager after the scene change, Are compared, and those scene candidates that do not match are listed. In addition, the scenes that coincide in common among the scene candidates are registered in the “scene list” to be handled by the scene next manager in accordance with the scene switching.
This process is realized by starting the next scene manager in the
[0152]
In the subsequent step S102, as the processing of the
By this processing, a plurality of candidate scenes according to scene switching are prepared as a scene list.
[0153]
In the subsequent step S103, using the function of the next scene manager, the scenes registered as the scene list are sorted according to the priority order of the scenes changed according to the scene switching.
As a result, the management state of the next scene manager shown in FIG. 18 is shifted to the management state of the next scene manager shown in FIG.
Of the processes shown in steps S101 to S103, the processes in steps S101 and S102 are not particularly mentioned in the description with reference to FIGS. This is because, in the case shown in FIGS. 18 and 19, there is no replacement of the scene candidate when the scene is switched from the scene A to the scene C. That is, when switching scenes corresponding to the transitions of FIGS. 18 to 19, the scenes that do not match are not listed in step S101, and all scenes match and are registered in the scene list.
[0154]
Following step S103, the process of step S104 is executed. Here, processing for the highest-order scene on the scene list sorted in step S103 is started. That is, this scene is treated as the “current scene” and subsequent processing is executed.
In step S104, the “highest priority scene” is selected as the highest priority scene except the scene currently being output (scene C in FIG. 19). . That is, in the case of FIG. 19, the scene B is selected. However, for example, when the priority management state shown in FIG. 19 is obtained, if the scene C is not stored in the DSM-
[0155]
In subsequent step S105, the data size of the module (scene module) formed by the data of the current scene selected in step S104 is checked. For example, DII (see FIG. 8) corresponding to the current scene module is fetched from the carousel data. For example, the DSM-
[0156]
In step S106, it is determined whether or not the current scene module is already in the DSM-
On the other hand, if a negative result is obtained in step S106, the process proceeds to step S107.
[0157]
In step S107, it is determined whether or not the remaining capacity (data capture capacity) of the current DSM-
Then, after executing the process of step S111, the process returns to the process of step S105 after the process of step S110.
[0158]
If a negative result is obtained in step S107 and it is determined that the remaining capacity of the current DSM-
In step S108, the priority management of the current next scene manager is compared with the scene module currently stored in the DSM-
[0159]
If it is determined in step S109 that the priority of the scene module specified in step S108 is lower than that of the current scene, the process proceeds to step S112, and the specified scene module is deleted from the DSM-CC buffer. To return to. By this processing, until the remaining capacity of the DSM-
[0160]
When a negative result is obtained in step S109, that is, when it is determined that the priority of the scene module specified in step S108 is higher than that of the current scene, at this stage, as a result The scene modules stored in the DSM-
[0161]
The present invention is not limited to the case where the DSM-CC system is adopted, and the present invention can be applied to any transmission system that conforms to the transmission format described in the embodiment. Further, the system to which the present invention is applied is not limited to a digital satellite broadcasting system, and can be applied to broadcasting such as cable television, the Internet, and the like.
[0162]
【The invention's effect】
As described above, the present invention is applicable to a case where scene data for one scene forms one module in principle as a transmission method, and transmission data consisting of one or more modules is transmitted by the carousel method. As a receiving device, a module as scene data to be extracted from a carousel (transmission information) and taken into a queue (memory means) is defined to be determined according to the priority of the scene.
For example, if the module loading order for the queue is not specified, it takes a certain amount of time to obtain the scene data required for display output and load it into the scene data storage means (DSM-CC buffer). Become. In order to solve this problem, a large number of queues are required in order to obtain the desired scene data module in the scene data storage means as quickly as possible.
On the other hand, according to the present invention, modules as scene data are fetched according to the priority order according to the above configuration, so that it is necessary or necessary for display output even under a limited queue number configuration. The scene data that is likely to be obtained can be obtained relatively quickly. That is, according to the present invention, even if the number of queues is small, it is possible to quickly cope with scene output and scene switching. In other words, it is possible to reduce the number of queues as compared with a case where quick scene output and scene switching are realized without applying the present invention. It is possible to reduce the circuit scale and reduce the cost.
[0163]
Also, since the module as the scene data to be imported from the carousel of the received data is determined according to the priority order changed according to the currently output scene, the scene data always corresponds to the switching of the scene display. In the storage means, a state in which the data is preferentially stored from the higher-order scene data is obtained.
In this case, the scene data of the scene selected by the scene display switching operation is very likely to be stored in the scene data storage means, and even if the user performs a scene display switching operation, for example, In most cases, the scene will be switched quickly. This configuration is particularly effective under the condition that the capacity of the scene data storage means (DSM-CC buffer) is limited and a large number of scene data cannot be stored.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration example of a digital satellite broadcast receiving system according to an embodiment of the present invention.
FIG. 2 is a block diagram showing a construction example of a reception facility in the present embodiment.
FIG. 3 is a front view showing an external appearance of a remote controller for IRD.
FIG. 4 is an explanatory diagram showing switching between a broadcast screen and a GUI screen.
FIG. 5 is a block diagram illustrating a configuration example of a ground station.
FIG. 6 is a chart showing data transmitted from a ground station.
FIG. 7 is an explanatory diagram showing a time division multiplexing structure of transmission data.
FIG. 8 is an explanatory diagram showing a transmission format by DSM-CC.
FIG. 9 is a data structure diagram of a transport stream.
FIG. 10 is an explanatory diagram showing a PSI table structure;
FIG. 11 is an explanatory diagram showing a configuration of an IRD.
FIG. 12 is an explanatory diagram showing an example of mapping to the directory structure of the data service as the embodiment;
FIG. 13 is an explanatory diagram showing another example of mapping to the directory structure of the data service as the embodiment;
FIG. 14 is an explanatory diagram showing an example of a directory structure of a data service.
FIG. 15 is an explanatory diagram showing an example of mapping to the directory structure of the data service.
FIG. 16 is an explanatory diagram showing a scene data module fetch operation according to the present embodiment;
FIG. 17 is an explanatory diagram illustrating an example of a scene transition;
18 is an explanatory diagram showing an example of scene priority order managed by the next scene manager according to the example of the scene transition shown in FIG. 17;
FIG. 19 is an explanatory diagram showing an example of scene priority order managed by the next scene manager according to the example of the scene transition shown in FIG. 17;
FIG. 20 is an explanatory diagram showing a scene data module loading operation in response to a change in scene priority shown as a transition from FIG. 18 to FIG. 19;
FIG. 21 is a flowchart for realizing module assignment according to scene switching according to the present embodiment;
[Explanation of symbols]
1 ground station, 2 satellites, 3 receiving equipment, 5 billing server, 6 TV program material server, 7 music material server, 8 audio additional information server, 9 GUI data server, 10 key information server, 11 parabolic antenna, 13 storage device, 13A MD recorder / player, 14 monitor device, 16 IEEE1394 bus, 21A TV program display area, 21B list, 21C text display area, 21D jacket display area, 22 lyrics display button, 23 profile display button, 24 information display button, 25 reservation Recording button, 26 Reserved list display button, 27 Recording history button, 28 Download button, 31 TV program material registration system, 32 Music material registration system, 33 Audio additional information registration system, 34 GUI material registration Recording system, 35 AV server, 36A MPEG audio encoder, 36B ATRAC encoder, 37 audio additional information database, 38 GUI material database, 39 TV program transmission system, 40A MPEG audio server, 40B MPEG audio server, 41 audio additional information transmission system, 42 GUI authoring system, 43A MPEG audio transmission system, 43B ATRAC audio transmission system, 44 DSM-CC encoder, 45 multiplexer, 46 radio wave transmission system, 51 tuner / front end unit, 52 descrambler, 53 transport unit, 54 MPEG2 audio Decoder, 54A memory, 55 MPEG2 video decoder, 55A memory, 56 D / A converter 57, switch circuit, 58 display processing unit, 59 optical digital output interface, 60 IEEE1394 interface, 61 man-machine interface, 62 IC card slot, 63 modem, 64 remote controller, 65 IC card, 70 demultiplexer, 71 queue, 81 Control processing unit, 82 DeMUX driver, 83 DSM-CC decoder block, 84 MHEG decoder block, 90 main memory, 91 DSM-CC buffer, 101 power key, 102 numeric keys, 103 screen display switching key, 104 interactive switching key, 105a Arrow keys, 105 EPG key panel, 106 channel keys, T1 input terminal, T2 analog video output terminal, T3 analog audio output terminal T4 analog audio output terminal
Claims (2)
前記受信手段によって受信されたDDBメッセージに含まれる前記モジュールを、前記カルーセルによって伝送されるシーン切り換えの必要があるとされたときに、切り換えが行われる可能性の高さに従って付されている優先度情報に基づいて蓄積する蓄積手段と、
前記DIIメッセージに含まれる情報であって、前記蓄積手段によって蓄積されている前記モジュールの位置を示す前記DSIメッセージが有するルートディレクトリを参照して、前記DDBメッセージ内の前記モジュールのうち、前記優先度情報に基づいてスタートアップファイルを取得する取得手段と、
前記取得手段によって取得されたスタートアップファイルを、前記蓄積手段によって蓄積されたDDBメッセージによって伝送される、前記提示用コンテンツデータについて表示制御を行うためのスクリプトに基づいて出力する出力制御手段と
を備える受信装置。A DDB message including a module that is repeatedly transmitted by the object carousel transmission method and is a scene data in which presentation content data is divided into blocks and transmitted, an identifier of the carousel, information related to the entire carousel, and data service and DSI message with information to know the location of the root directory, a receiving means for receiving a DII message including information corresponding to each module included in the carousel,
Priority given to the modules included in the DDB message received by the receiving means according to the possibility of switching when it is necessary to switch scenes transmitted by the carousel. Storage means for storing based on information;
Referring to a root directory of the DSI message , which is information included in the DII message and indicates the position of the module stored by the storage unit, the priority among the modules in the DDB message An acquisition means for acquiring a startup file based on the information;
Output control means for outputting a startup file acquired by the acquisition means based on a script for performing display control on the presentation content data transmitted by the DDB message stored by the storage means; apparatus.
前記受信手順によって受信されたDDBメッセージに含まれる前記モジュールを、前記カルーセルによって伝送されるシーン切り換えの必要があるとされたときに、切り換えが行われる可能性の高さに従って付されている優先度情報に基づいて蓄積する蓄積手順と、
前記DIIメッセージに含まれる情報であって、前記蓄積手順によって蓄積されている前記モジュールの位置を示す前記DSIメッセージに含まれるルートディレクトリを参照して、前記DDBメッセージ内の前記モジュールのうち、前記優先度情報に基づいてスタートアップファイルを取得する取得手順と、
前記取得手順によって取得されたスタートアップファイルを、前記蓄積手順によって蓄積されたDDBメッセージによって伝送される、前記提示用コンテンツデータについて表示制御を行うためのスクリプトに基づいて出力する出力制御手順と
を実行する受信方法。A DDB message including a module to be transmitted as scene data in which presentation content data is transmitted divided into blocks, which are repeatedly transmitted by the object carousel transmission method, an identifier of the carousel, information related to the entire carousel , a data service and DSI message with information to know the location of the root directory, a receiving step of receiving the DII message including information corresponding to each module included in the carousel,
Priority given to the modules included in the DDB message received by the reception procedure according to the possibility of switching when it is necessary to switch scenes transmitted by the carousel. An accumulation procedure to accumulate based on information;
Reference is made to a root directory included in the DSI message , which is information included in the DII message and indicates the location of the module accumulated by the accumulation procedure, and the priority among the modules in the DDB message. Acquisition procedure to get startup file based on degree information,
An output control procedure for outputting the startup file acquired by the acquisition procedure based on a script for performing display control on the presentation content data transmitted by the DDB message stored by the storage procedure ; Receiving method.
Priority Applications (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP20385798A JP4378780B2 (en) | 1998-07-17 | 1998-07-17 | Receiving apparatus and receiving method |
EP06076318A EP1705918B1 (en) | 1998-07-14 | 1999-07-14 | Data receiving apparatus |
CNB998015814A CN100382498C (en) | 1998-07-14 | 1999-07-14 | Data transmission control method, data transmission method, data transmitter, and receiver |
DE69943228T DE69943228D1 (en) | 1998-07-14 | 1999-07-14 | Data receiving device |
EP99929823A EP1014620B1 (en) | 1998-07-14 | 1999-07-14 | Data transmission control method, data transmission method, data transmitter, and receiver |
PCT/JP1999/003787 WO2000004676A1 (en) | 1998-07-14 | 1999-07-14 | Data transmission control method, data transmission method, data transmitter, and receiver |
KR1020007002686A KR100641594B1 (en) | 1998-07-14 | 1999-07-14 | Data transmission control method, data transmission method, data transmitter, and receiver |
US09/521,098 US6966065B1 (en) | 1998-07-14 | 2000-03-07 | Data transmission control method, data transmitting method, data transmitting apparatus, and receiving apparatus |
US11/217,917 US8209734B2 (en) | 1998-07-14 | 2005-09-01 | Data transmission control method, data transmitting method, data transmitting apparatus, and receiving apparatus |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP20385798A JP4378780B2 (en) | 1998-07-17 | 1998-07-17 | Receiving apparatus and receiving method |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2000036946A JP2000036946A (en) | 2000-02-02 |
JP2000036946A5 JP2000036946A5 (en) | 2005-09-02 |
JP4378780B2 true JP4378780B2 (en) | 2009-12-09 |
Family
ID=16480854
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP20385798A Expired - Fee Related JP4378780B2 (en) | 1998-07-14 | 1998-07-17 | Receiving apparatus and receiving method |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4378780B2 (en) |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3630037B2 (en) | 1999-10-06 | 2005-03-16 | 日本電気株式会社 | DSM-CC carousel receiving apparatus, receiving method used therefor, and recording medium recording the control program thereof |
JP2001243043A (en) | 2000-02-29 | 2001-09-07 | Sony Corp | User interface system and device and method for generating scene description and device and method for converting scene description and recording medium and transmitting medium |
EP1148730A3 (en) * | 2000-03-31 | 2003-10-08 | Matsushita Electric Industrial Co., Ltd. | Data broadcast apparatus for controlling presentation timing of additional data with high precision |
JP2002094472A (en) * | 2000-05-30 | 2002-03-29 | Matsushita Electric Ind Co Ltd | Data acquisition device and method |
JP4240766B2 (en) * | 2000-06-26 | 2009-03-18 | パナソニック株式会社 | DATA STORAGE METHOD, RECEIVING DEVICE AND BROADCASTING SYSTEM IMPLEMENTING THE SAME |
GB0016061D0 (en) * | 2000-06-30 | 2000-08-23 | Koninkl Philips Electronics Nv | Efficient recording of object carousels |
JP2002044553A (en) * | 2000-07-26 | 2002-02-08 | Toshiba Corp | Broadcast reception display device and broadcast reception display method |
JP2002044551A (en) * | 2000-07-26 | 2002-02-08 | Toshiba Corp | Broadcast reception display device and broadcast reception display method |
JP4552290B2 (en) * | 2000-08-21 | 2010-09-29 | ソニー株式会社 | Data transmission apparatus and method, data processing apparatus and method |
JP2002158626A (en) * | 2000-08-25 | 2002-05-31 | Matsushita Electric Ind Co Ltd | Contents editor, contents-editing method and contents- editing program, and computer-readable recording medium |
JP5725235B1 (en) | 2014-04-22 | 2015-05-27 | ソニー株式会社 | Receiving apparatus and receiving method, and transmitting apparatus and transmitting method |
JP5725249B1 (en) * | 2014-11-27 | 2015-05-27 | ソニー株式会社 | Transmitting apparatus, transmitting method, receiving apparatus, and receiving method |
JP5725250B1 (en) * | 2014-11-27 | 2015-05-27 | ソニー株式会社 | Transmitting apparatus, transmitting method, receiving apparatus, and receiving method |
JP6337804B2 (en) * | 2015-03-04 | 2018-06-06 | ソニー株式会社 | Receiving apparatus and receiving method |
-
1998
- 1998-07-17 JP JP20385798A patent/JP4378780B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2000036946A (en) | 2000-02-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100641594B1 (en) | Data transmission control method, data transmission method, data transmitter, and receiver | |
JP5307315B2 (en) | System and method for incorporating previously broadcast content into program recordings | |
US8826111B2 (en) | Receiving apparatus and method for display of separately controllable command objects,to create superimposed final scenes | |
US20160360248A1 (en) | Method and apparatus for decoding segments of an audiovisual stream | |
JP5045535B2 (en) | Receiving apparatus and receiving method | |
JP4378780B2 (en) | Receiving apparatus and receiving method | |
JP2002010182A (en) | Method for storing data, receiver realizing the same as well as broadcasting system | |
JP2001024995A (en) | Broadcasting device, broadcasting method and receiver | |
JP4378777B2 (en) | Broadcast receiving apparatus and broadcast receiving method | |
JP4016160B2 (en) | Data receiving / recording method and data receiving apparatus | |
JP4296631B2 (en) | Broadcasting method and receiving apparatus | |
JP2000333138A (en) | Information processing device and method | |
JP2000295586A (en) | Information processor and information processing method for broadcast | |
JP4378778B2 (en) | Receiving apparatus and receiving method | |
JP4366742B2 (en) | Receiver | |
JP2000333043A (en) | Information processing unit and its method | |
JP3671017B2 (en) | Digital broadcast receiving method and apparatus | |
JP2001024612A (en) | Broadcasting monitoring device | |
JP2000331465A (en) | Information processing device and its method | |
JP2000032415A (en) | Receiver | |
JP2001022625A (en) | Device and method for data recording and device and method for data acquisition | |
JP2000333041A (en) | Device and method for information processing | |
JP2000032362A (en) | Device and method for transmitting information | |
JP2000295638A (en) | Broadcasting equipment monitoring device | |
JP4499205B2 (en) | Data receiving method, data receiving apparatus and program |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050302 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050302 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080415 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080616 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090519 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090716 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090825 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090907 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121002 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121002 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131002 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |