(57)【要約】【課題】データ放送で使用される受信機において、記憶領域の有効利用が求められている。【解決手段】圧縮格納判定部は、受信したモジュールが、（１）視聴中のコンポーネントに含まれないと判定された場合（Ｓ１０２のＮ）、（２）ＣｏｍｐｒｅｓｓｉｏｎＴｙｐｅ記述子からは圧縮が確認されなかった場合（Ｓ１０４のＮ）、（３）圧縮符号化のメディア型でないと判定された場合（Ｓ１０６のＮ）、（４）モジュールのデータサイズが所定値を超える場合（Ｓ１０８のＮ）、（５）圧縮率が所定値以下の場合（Ｓ１１２のＹ）、の５条件を満たす場合、モジュールを圧縮して記憶領域に格納する。【選択図】        図３
2004304307.tif 000002
【特許請求の範囲】
【請求項１】
デジタル放送において送出されるデータ放送用データを受信するデジタル放送受信機であって、
複数のデータ放送用データを格納する記憶領域と、
前記データ放送用データを圧縮処理する圧縮処理部と、
前記データ放送用データを前記記憶領域に格納する際、データ放送用データ毎に、前記圧縮処理部で圧縮処理して格納するか、圧縮処理せずに格納するかを判定する圧縮格納判定部と、
を有することを特徴とするデジタル放送受信機。
【請求項２】
前記データ放送用データは、マルチメディアコンテンツを記述する文書を含み、
当該デジタル放送受信機は、更に前記記憶領域に格納したデータ放送用データに含まれる前記文書を解析し表示デバイス上に提示処理を行うデータ解析提示処理部を有することを特徴とする請求項１に記載のデジタル放送受信機。
【請求項３】
前記圧縮格納判定部は、前記データ放送用データが、現在データ解析提示処理部において提示対象となっている文書を伝送するコンポーネントと同一のコンポーネントで伝送されているか否かに応じて、圧縮処理を行うかどうかを判定することを特徴とする請求項２に記載のデジタル放送受信機。
【請求項４】
前記圧縮格納判定部は、前記データ放送用データが、現在データ解析提示処理部から要求中であるかどうかに応じて、圧縮処理を行うかどうかを判定することを特徴とする請求項２または３に記載のデジタル放送受信機。
【請求項５】
前記圧縮格納判定部は、前記データ放送用データが現在選局中のサービスに含まれるか否かに応じて圧縮処理を行うかどうかを判定することを特徴とする請求項１から４のいずれかに記載のデジタル放送受信機。
【請求項６】
前記圧縮格納判定部は、サービスの変更がなされた際に、前記記憶領域に格納済みのデータ放送用データのうち、変更前のサービスに含まれるデータ放送用データの圧縮処理を行うかどうかを判定することを特徴とする請求項１から５のいずれかに記載のデジタル放送受信機。
【請求項７】
前記圧縮格納判定部は、現在データ解析提示処理部において提示対象の文書が遷移する際、遷移前の文書を伝送するコンポーネントと、遷移後の文書を伝送するコンポーネントが異なるか否かに応じて、遷移前の文書を伝送するコンポーネントの圧縮処理を行うか否かを判定することを特徴とする請求項２から６のいずれかに記載のデジタル放送受信機。
【請求項８】
前記圧縮格納判定部は、前記データ放送用データに付加された付加情報に応じて、圧縮処理を行うかどうかを判定することを特徴とする請求項１から７のいずれかに記載のデジタル放送受信機。
【請求項９】
前記圧縮格納判定部は、前記付加情報に含まれる前記データ放送用データの圧縮有無または圧縮形式に応じて圧縮処理を行うかどうかを判定することを特徴とする請求項８に記載のデジタル放送受信機。
【請求項１０】
前記圧縮格納判定部は、前記付加情報に含まれる前記データ放送用データの第１の圧縮形式が前記圧縮処理部における第２の圧縮形式と異なる圧縮形式であった場合は、前記第１の圧縮形式に応じた解凍処理を行った後に、前記第２の圧縮形式に応じた圧縮処理を行うかどうかを判定することを特徴とする請求項８に記載のデジタル放送受信機。
【請求項１１】
前記圧縮格納判定部は、前記付加情報に含まれる前記データ放送用データのメディア型に応じて圧縮処理を行うかどうかを判定することを特徴とする請求項８から１０のいずれかに記載のデジタル放送受信機。
【請求項１２】
前記圧縮格納判定部は、前記付加情報に含まれる前記データ放送用データのサイズによって圧縮処理を行うかどうかを判定する請求項８〜〜１１のいずれかに記載のデジタル放送受信機。
【請求項１３】
前記圧縮処理部は、前記データ放送用データの圧縮処理を試行し、前記圧縮格納判定部はその試行の結果得られた圧縮率に応じてその圧縮処理を有効とするか否かを判定することを特徴とする請求項１〜１２のいずれかに記載のデジタル放送受信機。
【請求項１４】
前記データ解析提示処理部は、前記記憶領域からデータ放送用データを読み出す際、データが圧縮されている場合は、解凍処理を行い、読み出し完了後、前記データ放送用データが直接１つのリソースファイルにマッピングされている場合は、解凍後データを削除した後データを前記記憶領域に格納し、前記データ放送用データがマルチパート形式である場合は、圧縮データを削除した後、解凍後のデータを前記記憶領域に格納することを特徴とする請求項２〜１３のいずれかに記載のデジタル放送受信機。
【請求項１５】
データカルーセル伝送方式によって送出されたデータ放送用データを取得し、取得したデータ放送用データが現在の提示処理に利用されないと判断されるときは、そのデータ放送用データが早期に利用される可能性があるかを判断し、利用される可能性が低いと判断される場合は、そのデータ放送用データを圧縮して保持することを特徴とするデータ処理方法。
【請求項１６】
データカルーセル伝送方式によって送出されたデータ放送用データを取得し、取得したデータ放送用データが現在の提示処理に利用されないと判断されるときは、前記データ放送用データの属性に応じて、そのデータ放送用データを圧縮または圧縮せずに保持するかを判断することを特徴とするデータ処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、デジタル放送技術に関し、特にデータ放送を受信可能なデジタル放送受信機およびデータ放送用データの処理技術に関する。
【０００２】
【従来の技術】
現在、地上波放送では、従来のアナログ方式からデジタル方式へ移行が計画されており、衛星放送では、デジタル放送が開始されている。デジタル放送では、映像の高画質化や、放送の高機能化、高音質化などが実現される。更に、動画、静止画、文字情報、音声などを組み合わせたマルチメディア型のサービスを実現するデータ放送に関しても提供される。
【０００３】
ところで、データ放送には、インターネット等で高度に情報交換できるＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）技術を拡張したＢＭＬ（Ｂｒｏａｄｃａｓｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）と呼ばれる技術が採用されることがあり、この技術により天気やニュース等、視聴者が欲しい情報を何時でも瞬時に見ることができる。データ放送は、従来型の放送と異なり、ユーザの操作に応じて画面に提示される情報が変化する。従って、ユーザの操作に対して、素早く反応することが求められている。そのような要求に応えるために、例えば、受信装置の処理速度を向上させる技術が提案されている（例えば、特許文献１参照）。
【０００４】
【特許文献１】
特開２００１−３２５１４５号公報
【０００５】
【発明が解決しようとする課題】
ところで、データ放送によって提供されるコンテンツは、受信機おいてコンテンツ用の所定の蓄積ディバイスに蓄積され、データ放送ブラウザによって表示画面に表示される。
【０００６】
データ放送ブラウザとして、例えば、ＢＭＬブラウザがあり、これは、蓄積されたデータ放送用のコンテンツを解析、展開し、ＯＳＤ（Ｏｎ  Ｓｃｒｅｅｎ  Ｄｉｓｐｌａｙ）プレーン上に情報画面を描画するとともに、ユーザ操作のためのインタフェイスを提供する。
【０００７】
選局などのユーザ操作から画像提示までのレスポンスが遅いと、ユーザは違和感を覚えることもあり、上述の通り、ユーザの操作に対して、素早く反応することが求められる。特許文献１に記載の技術では、メモリの効率的な利用を行うことで、ユーザの操作に対するレスポンスを向上させている。このような、受信機のレスポンスを向上させる技術は、一つのみではなく複数の技術が受信機に適用されることで、受信機のトータルの性能向上が図られるので、常に様々な技術が求められている。
【０００８】
本発明はそうした状況に鑑みなされたものであって、その目的は、デジタル放送におけるデータ放送の処理速度を向上させる技術を提供することにある。
【０００９】
【課題を解決するための手段】
本発明のある態様は、デジタル放送受信装機に関する。このデジタル放送受信装機は、デジタル放送において送出されるデータ放送用データを受信する装置であって、複数のデータ放送用データを格納する記憶領域と、データ放送用データを圧縮処理する圧縮処理部と、受信した前記データ放送用データを記憶領域に格納する際、データ放送用データ毎に、圧縮処理部で圧縮処理して格納するか、圧縮処理せずに格納するかを判定する圧縮格納判定部と、を有する。
【００１０】
一または複数のネットワークにおいて伝送されるデジタル放送では、ネットワークは複数のトランスポートストリームを含むことができ、更にそれぞれのトランスポートストリームは複数のサービスを含むことができる。同様に、それそれのサービスは複数のコンポーネントを含むことができ、それぞれのコンポーネントは複数のモジュールを含むことができる。
【００１１】
また、ネットワークはオリジナルネットワーク識別（ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ）によって一意に識別される。トランスポートストリームはネットワーク内においてトランスポートストリーム識別（ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ）によって一意に識別される。サービスはトランスポートストリーム内においてサービス識別（ｓｅｒｖｉｃｅ＿ｉｄ）によって一意に識別される。コンポーネントは、サービス内において、コンポーネント識別（ｃｏｍｐｏｎｅｎｔ＿ｔａｇ）によって一意に識別される。また、コンポーネントは前記のトランスポートストリーム内において、エレメンタリーストリーム（以下、単に「ＥＳ」と略す）の形で伝送され、ＥＳはトランスポートストリーム内において、ＰＩＤ（Ｐａｃｋｅｔ  ＩＤ）によって一意に識別される。
【００１２】
モジュールは、コンポーネント内において、モジュール識別（ｍｏｄｕｌｅ＿ｉｄ）によって一意に識別される。コンポーネントは、ＤｏｗｎｌｏａｄＩｎｆｏＩｎｄｉｃａｔｉｏｎ（以下、単に「ＤＩＩ」ともいう）と呼ばれるディレクトリ情報と、データの実体となる複数のモジュールを伝送する。これらのデータは繰り返し伝送され、データカルーセルとも呼ばれる。ここで、データ放送用データは、データの実体であるモジュールを指す。
【００１３】
一般に、データ放送の提示に必要とされるモジュール、つまり伝送されたコンテンツは、上述の通り、受信機おいてコンテンツ用の所定の記憶領域に記憶され、データ放送ブラウザによって、表示画面に表示され、不要となったモジュールは記憶領域から削除される。このとき、データ放送ブラウザにおいてモジュールは、
＜ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ＞／＜ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ＞／＜ｓｅｒｖｉｃｅ＿ｉｄ＞／＜ｃｏｍｐｏｎｅｎｔ＿ｔａｇ＞／＜ｍｏｄｕｌｅ＿ｉｄ＞、
によって一意に識別され、参照される。従って、受信機においては、上記の形でモジュールを記憶領域に格納することになる。
【００１４】
また、１つのモジュールは、直接１つのリソースにマッピングされている場合と、複数のリソースがまとめられているマルチパート形式の場合があり、後者の場合、リソースはデータ放送ブラウザによって、例えば、
＜ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ＞／＜ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ＞／＜ｓｅｒｖｉｃｅ＿ｉｄ＞／＜ｃｏｍｐｏｎｅｎｔ＿ｔａｇ＞／＜ｍｏｄｕｌｅ＿ｉｄ＞／＜ｒｅｓｏｕｒｃｅＮａｍｅ＞
のように識別される。
【００１５】
また、データ放送用データは、マルチメディアコンテンツを記述する文書を含んでもよく、このデジタル放送受信機は、更に記憶領域に格納したデータ放送用データのうちの前記の文書を解析し表示デバイス上に提示処理を行うデータ解析提示処理部を有してもよい。
【００１６】
例えば、データ解析提示処理部として、ＢＭＬブラウザがある。このブラウザから要求されているモジュールについては、すぐ参照される可能性が高いので、圧縮しないようにしてもよい。
【００１７】
また、圧縮格納判定部は、データ放送用データが、現在データ解析提示処理部において提示対象となっている文書を伝送するコンポーネントと同一のコンポーネントによって伝送されているものであるかどうかに応じて、圧縮処理を行うかどうかを判定してもよい。
【００１８】
ユーザが視聴中のコンポーネントは、すぐ参照される可能性が高いので、圧縮しないようにしてもよい。
【００１９】
また、圧縮格納判定部は、データ放送用データが、現在データ解析提示処理部から要求中であるかどうかに応じて、圧縮処理を行うかどうかを判定してもよい。
【００２０】
また、圧縮処理部は、現在選局中のサービス以外のサービスに含まれるデータ放送用データを圧縮し、記憶領域に保持してもよい。一般に、選局中のサービスのモジュールは参照される可能性が高いので、圧縮しないようにしてもよい。
【００２１】
また、圧縮処理部は、選局時に、記憶領域に格納済みのデータ放送用データのうち、選局元のサービスに含まれるデータ放送用データの圧縮処理を行ってもよい。
【００２２】
また、圧縮処理部は、現在データ解析提示処理部において提示対象の文書が遷移する際、遷移前の文書を伝送するコンポーネントと、遷移後の文書を伝送するコンポーネントが異なる場合に、遷移前のコンポーネントに含まれるデータ放送用データの圧縮処理を行ってもよい。
【００２３】
また、圧縮格納判定部は、データ放送用データに付加された付加情報に応じて、圧縮処理を行うかどうかを判定してもよい。付加属性として、例えば、上記のＤＩＩに記述されているモジュール情報がある。
【００２４】
また、圧縮格納判定部は、付加情報に含まれるデータ放送用データの圧縮有無または圧縮形式に応じて圧縮処理を行うかどうかを判定してもよい。データ放送用データの圧縮有無および圧縮形式は、例えばＤＩＩのＣｏｍｐｒｅｓｓｉｏｎＴｙｐｅ記述子の有無および内容によって判別することができる。
【００２５】
また、圧縮格納判定部は、付加情報に含まれるデータ放送用データの第１の圧縮形式が圧縮処理部における第２の圧縮形式と異なる圧縮形式であった場合は、データ放送用データに関する第１の圧縮形式に応じた解凍処理を行った後に、第２の圧縮形式に応じた圧縮処理を行うかどうかを判定してもよい。例えば、データ放送用データが、伝送時においてｚｌｉｂ形式で圧縮されている場合、一旦解凍した後、より圧縮率の高い圧縮形式で再圧縮することにより、データ放送用データのサイズを小さくすることができる。また、圧縮・解凍処理負荷が軽い圧縮形式で再圧縮してもよい。この場合、参照時の処理時間を短くすることができる。
【００２６】
また、圧縮格納判定部は、付加情報に含まれるデータ放送用データのメディア型に応じて圧縮処理を行うかどうかを判定してもよい。
【００２７】
メディア型は、例えば、ＤＩＩのＴｙｐｅ記述子の内容によって判別することができる。メディア型が、例えば、ＪＰＥＧ（Ｊｏｉｎｔ  Ｐｈｏｔｏｇｒａｐｈｉｃ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）形式、ＰＮＧ（Ｐｏｒｔａｂｌｅ  Ｎｅｔｗｏｒｋ  Ｇｒａｐｈｉｃｓ）形式、ＭＮＧ（Ｍｕｌｔｉｐｌｅ−ｉｍａｇｅ  Ｎｅｔｗｏｒｋ  Ｇｒａｐｈｉｃｓ）形式、ＡＩＦＦ（Ａｕｄｉｏ  Ｉｎｔｅｒｃｈａｎｇｅ  Ｆｉｌｅ  Ｆｏｒｍａｔ）形式、ＡＡＣ（Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｃｏｄｉｎｇ）形式の場合は、既に圧縮符号化が行われているので、追加圧縮しても圧縮効果が期待できない。また、マルチパート形式の場合は、リソースに上記圧縮符号化が行われているファイルが含まれている可能性があるので、追加圧縮による圧縮効果は小さい可能性があるし、参照される確率・頻度も高いので非圧縮で保持してもよい。
【００２８】
また、圧縮格納判定部は、付加情報に含まれるデータ放送用データのサイズによって圧縮処理を行うかどうかを判定してもよい。例えば、格納領域は１０２４バイトや４０９６バイト等の固定長ブロックによって構成されることが多い。従って、それらのサイズ以下のモジュールは圧縮処理しても格納領域は小さくならず、利用可能な格納領域が増えるわけではない。そこで、格納領域のブロックサイズを基準として、データ放送用データを圧縮処理するかどうかを判定してもよい。
【００２９】
また、圧縮処理部は、データ放送用データの圧縮処理を試行し、圧縮格納判定部はその試行の結果得られた圧縮率に応じてその圧縮処理を有効とするか否かを判定してもよい。つまり、圧縮率が低ければ、データサイズがあまり変わらず、効果があまり得られないので解凍する際の処理負荷を考慮して圧縮処理を行わない。
【００３０】
また、データ解析提示処理部は、記憶領域からデータ放送用データを読み出す際、データが圧縮されている場合は、解凍処理を行い、読み出し完了後、データ放送用データが直接１つのリソースファイルにマッピングされている場合は、解凍後データを削除し、データ放送用データがマルチパート形式である場合は、圧縮データを削除した後、解凍後のデータを記憶領域に格納してもよい。
【００３１】
本発明によれば、データ放送受信機において、モジュールデータを記憶領域に格納する際、圧縮してデータを保持することにより、使用メモリ量を少なくすることが期待できる。また、視聴中のコンポーネントに含まれるモジュールや、データ放送ブラウザから要求中のモジュールについては、すぐに読み出される可能性が高いので圧縮せずに格納するようにすることによって、ユーザに違和感のない操作性を提供することができる。また、あらかじめ圧縮されているモジュールや、ＪＰＥＧ等のメディアとして圧縮機能が備わったものは重複して圧縮しないようにするとともに、それ以外のものについても圧縮率が一定以下にならない場合は圧縮を行わないようにすることで、適切なデータ管理が期待できる。また、選局時には、選局元のサービスに含まれる解凍状態のモジュールを再圧縮することにより、視聴中サービス以外の優先度の低いサービスは圧縮状態で記憶領域に保持するようにする。
【００３２】
同様に、コンポーネントをまたがる文書遷移時においても、視聴中コンポーネント以外のコンポーネントは圧縮状態で記憶領域に保持するようにする。また、マルチパート形式のモジュールについては、一旦ブラウザから読み出された後も、解凍状態のまま保持することにより再読み出し時の速度低下を防止することができる。
【００３３】
【発明の実施の形態】
図１は、実施の形態に係るデジタル放送受信装置１０の構成を示すブロック図である。デジタル放送受信装置１０において、アンテナ１２より受信されたＲＦ信号は、受信部１４により選局され、復調部１６に与えられる。
【００３４】
復調部１６によって復調された信号は、トランスポートストリームデコーダ（以下、単に「ＴＳデコーダ」と略す）１８に与えられる。ＴＳデコーダ１８は、いわゆるＤｅＭＵＸ処理機能を有し、複数の多重化されたトランスポートストリームから必要とされるストリームを取り出すフィルタリング処理を行う。このフィルタリング処理により取り出せるストリームの数は、一般に、ＴＳデコーダ１８の処理能力によって定まる。
【００３５】
また、このフィルタリング処理によって、番組内容そのものであるＭＰＥＧデータのデータストリームと、データ放送用データに分別される。ＴＳデコーダ１８は、データストリームをＭＰＥＧデコーダ２０に与え、データ放送用データを演算処理部３０に与える。
【００３６】
ＭＰＥＧデコーダ２０は、ＴＳデコーダ１８から与えられたデータストリームを受けて、バッファ用ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）４０をバッファとして用いることで、映像信号や音声信号へと変換する。
【００３７】
デジタル放送受信装置１０は、更に、データバスＤＢを介して、ＴＳデコーダ１８からの信号を受けて、データ放送用データを格納するための蓄積デバイス３４と、データバスＤＢを介して、蓄積デバイス３４に蓄積されたデータに対して、演算処理部３０の演算処理におけるプログラムを記録するためのＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２６と、演算処理部３０の動作のためのメモリ領域を提供するコンテンツ用ＲＡＭ２８と、データバスＤＢと外部との間でデータ入出力を行うための高速デジタルインターフェイス（以下、単に「高速デジタルＩ／Ｆ」と略す）３２とを備える。特に限定されないが、蓄積デバイス３４およびＲＯＭ２６としては、例えば、電気的にデータの書込および読出が可能なＥＥＰＲＯＭ等がある。
【００３８】
演算処理部３０が外部から与えられた指示に従って蓄積デバイス３４中に蓄積されたデータに対してデータ放送用の処理を行った後のデータは、オンスクリーンディスプレイ制御部２４（以下、単に「ＯＳＤ制御部２４」ともいう）から出力制御部２２に与えられる。演算処理部３０が行うデータ放送に関する処理は後述する。
【００３９】
デジタル放送受信装置１０は、更に、音声処理部４２を備える。この音声処理部４２は、蓄積デバイス３４に蓄積されたデータに基づいて、演算処理部３０が処理した結果のデータ等を受けて、表示部５４において出力される映像に対する効果音などを生成して、出力制御部２２に与える。
【００４０】
出力制御部２２は、ＭＰＥＧデコーダ２０からの出力とＯＳＤ制御部２４からの出力とを合成するマルチプレクサ４４と、合成された信号を、モニターなどの外部の表示部５４およびスピーカなどの音声出力部５２に出力する出力回路４６とを有する。
【００４１】
デジタル放送受信装置１０は、必要に応じて、外部との間でデータ授受を行うためのモデムや、ＩＣカードからの情報を受取るためのＩＣカードインターフェイスを備える。また、高速デジタルＩ／Ｆ３２を介して、例えば、ＨＤＤ装置などの外部デバイス５６がデータバスＤＢと接続されている。また、デジタル放送受信装置１０は、映像出力を表示する表示部５４や音声出力信号を出力する音声出力部５２と一体化された構成であってもよい。
【００４２】
図２は、図１に示した構成によって実現される機能の中で、文書データを表示するＢＭＬブラウザ９０の機能を示す概略ブロック図を示している。このＢＭＬブラウザ９０は、演算処理部３０により実行される構文解析プログラムの処理に基づいて、文書データの提示処理を行う。なお、構文解析プログラムの処理は、本実施の形態で示すように、演算処理部３０で実行されるソフトウェア上で実現されても良いし、その他に、専用のハードウェア上で実現されてもよい。構文解析プログラムは、ＲＯＭ２６に保持される。
【００４３】
ＢＭＬブラウザ９０は、ＢＭＬ文書データを解析し、ソフト内部の表現形式であるオブジェクトツリー情報に変換するパーサ部６０と、パーサ部６０で生成されたツリー情報を基に、ＢＭＬ文書データに読み出しまたは書き込み処理を行うインタフェイスを提供するＤＯＭ部６２と、ＢＭＬ文書データ中のＥＣＭＡＳｃｒｉｐｔ記述を処理し内部的な情報処理や表示変更等、コンテンツの動作を制御するスクリプト処理部６４と、規格で規定されている所定のイベントに対応した処理を行うイベント処理部６６と、ＸＭＬ文書をＢＭＬ文書に変形するＸＳＬＴ処理部６８と、上記の各処理を終えたデータを表示できる形式に変換し、表示処理をするレンダリング処理部７０とを備える。以上が、ＢＭＬブラウザ９０の一般的な主要機能であり、本実施の形態では、ＢＭＬブラウザ９０は更に、拡張機能として圧縮解凍処理部７２と、圧縮格納判定部７４を備える。
【００４４】
圧縮解凍処理部７２は、圧縮格納判定部７４の指示に基づき、モジュールを圧縮し、一時的にコンテンツ用ＲＡＭ２８に格納するとともに、必要に応じて、コンテンツ用ＲＡＭ２８に圧縮されて格納されているモジュールを解凍する。圧縮格納判定部７４は、モジュールを圧縮するか否かを所定の条件に基づいて判定し圧縮が必要であれば、圧縮解凍処理部７２にその旨を通知する。なお、圧縮されたモジュールは、コンテンツ用ＲＡＭ２８の替わりに、蓄積デバイス３４に格納されてもよい。
【００４５】
なお、圧縮格納判定部７４の判定条件は以下の通りである。以下の判定条件を１または複数用いてモジュールを圧縮するか否かを判定する。
１）  モジュールが、提示対象となっている文書を伝送するコンポーネントと同一のコンポーネントによって伝送されている場合、すぐ参照される可能性が高いので、圧縮しない。
２）  パーサ部６０から要求されているモジュールについては、すぐ参照される可能性が高いので、圧縮しない。
３）  選局中のサービスのモジュールは参照される可能性が高いので、圧縮しない。
４）  選局時に、コンテンツ用ＲＡＭ２８または蓄積デバイス３４に格納済みのモジュールのうち、選局元のサービスに含まれるモジュールを圧縮する。
５）  ＢＭＬブラウザ９０において提示対象となっている文書を伝送するコンポーネント以外のコンポーネントに含まれるモジュールを圧縮する。
６）  ＢＭＬブラウザ９０において提示対象の文書が遷移する際、遷移前の文書を伝送するコンポーネントと遷移後の文書を伝送するコンポーネントが異なる場合に、遷移前のコンポーネントに含まれるモジュールを圧縮する。
７）  ＤＩＩに記述されているモジュールの圧縮形式が圧縮解凍処理部７２における圧縮形式と異なる圧縮形式であった場合は、そのモジュールの圧縮形式に応じた解凍処理を行った後に、再度圧縮処理を行うかどうかを判定する。例えば、モジュールが、伝送時においてｚｌｉｂ形式で圧縮されている場合、一旦解凍した後、より圧縮率の高い圧縮形式で再圧縮することにより、モジュールのサイズを小さくする。
８）  ＤＩＩに記述されているモジュールの圧縮の有無、またはメディア型に応じて判定する。圧縮の有無またはメディア型は、ＤＩＩのＣｏｍｐｒｅｓｓｉｏｎＴｙｐｅ記述子の有無および内容によって判別することができる。メディア型がＪＰＥＧ形式、ＰＮＧ形式、ＭＮＧ形式、ＡＩＦＦ形式、ＡＡＣ形式の場合は、既に圧縮符号化が行われているので、追加圧縮しても圧縮効果が期待できないので圧縮しない。
９）  モジュールがマルチパート形式の場合は、リソースとして上記のファイルが含まれている可能性があり、その場合、追加圧縮による圧縮効果は小さい可能性があり、更にそのリソースが参照される確率・頻度も高いので圧縮しない。
１０）  ＤＩＩに記述されているモジュールのサイズによって圧縮処理を行うかどうかを判定する。例えば、格納領域は１０２４バイトや４０９６バイト等の固定長ブロックによって構成されることが多く、それらのサイズ以下のモジュールは圧縮処理しても格納領域は小さくならないので、圧縮しない。
１１）  圧縮処理を行った場合の圧縮率が低ければ、データサイズがあまり変わらず、効果があまり得られないので処理速度を考慮して圧縮したモジュールは無効とする。
１２）  コンテンツ用ＲＡＭ２８からモジュールを読み出す際、モジュールが圧縮されている場合は、解凍処理を行い、読み出し完了後、モジュールが直接１つのリソースファイルにマッピングされている場合は、解凍後のモジュールは削除し、モジュールがマルチパート形式である場合は、圧縮されたモジュールを削除した後、解凍後のモジュールを格納する。
なお、圧縮格納判定部７４は、圧縮後のモジュールをコンテンツ用ＲＡＭ２８と蓄積デバイス３４とのいずれに格納するかを判断してもよい。以下の説明では、圧縮後のモジュールはコンテンツ用ＲＡＭ２８に格納されるものとする。
【００４６】
図３は、モジュールを受信した際に行われる圧縮判定及び圧縮処理を示すフローチャートである。まず、圧縮格納判定部７４は、受信したモジュールが、視聴中のコンポーネントに含まれるモジュールか否かを、つまりＢＭＬブラウザ９０による提示処理の対象となっているか否かを判定する（Ｓ１０２）。視聴中のコンポーネントに含まれると判定された場合（Ｓ１０２のＹ）、圧縮せずにコンテンツ用ＲＡＭ２８へ格納する（Ｓ１１６）。視聴中のコンポーネントに含まれないと判定された場合（Ｓ１０２のＮ）、圧縮格納判定部７４は、ＤＩＩのＣｏｍｐｒｅｓｓｉｏｎＴｙｐｅ記述子を参照し、圧縮の有無を確認する（Ｓ１０４）。圧縮が有る場合（Ｓ１０４のＹ）、圧縮格納判定部７４は、モジュールを圧縮せずにコンテンツ用ＲＡＭ２８に格納する（Ｓ１１６）。
【００４７】
ＣｏｍｐｒｅｓｓｉｏｎＴｙｐｅ記述子からは圧縮が確認されなかった場合（Ｓ１０４のＮ）、圧縮格納判定部７４は、ｔｙｐｅ記述子を参照し、圧縮符号化のメディア型であるか否かを判定する（Ｓ１０６）。圧縮符号化のメディア型であると判定された場合（Ｓ１０６のＹ）、圧縮格納判定部７４は、モジュールを圧縮せずにコンテンツ用ＲＡＭ２８に格納する（Ｓ１１６）。圧縮符号化のメディア型でないと判定された場合（Ｓ１０６のＮ）、圧縮格納判定部７４はモジュールのデータサイズを確認し、データサイズが一定値以下であるか否かを判定する（Ｓ１０８）。モジュールのデータサイズが一定値以下である場合（Ｓ１０８のＹ）、圧縮格納判定部７４は、モジュールを圧縮せずにコンテンツ用ＲＡＭ２８に格納する（Ｓ１１６）。モジュールのデータサイズが一定値を超える場合（Ｓ１０８のＮ）、圧縮格納判定部７４はモジュールを圧縮する（Ｓ１１０）。
【００４８】
続いて、圧縮格納判定部７４は、圧縮後のモジュールのサイズを参照し、圧縮率を確認する（Ｓ１１２）。圧縮率が一定値を超える場合（Ｓ１１２のＮ）、圧縮格納判定部７４は、圧縮処理を無効とし、圧縮しないモジュールをコンテンツ用ＲＡＭ２８に格納する（Ｓ１１６）。このとき、圧縮されたモジュールは破棄される。圧縮率が一定値以下の場合（Ｓ１１２のＹ）、圧縮されたモジュールをコンテンツ用ＲＡＭ２８へ格納し（Ｓ１１４）、一連の処理が終了する。なお、この処理において、モジュールの圧縮判定に、５種類の条件を用いたが、これに限らず、これら５種類の条件の一部のみが用いられてもよいし、更に他の条件を加えてもよい。
【００４９】
図４は、サービス選局時に行われる圧縮判定及び圧縮処理を示すフローチャートである。この処理は、選局によってサービスの変更がなされた際に、変更前のサービスを所定の条件に基づいて圧縮する。
【００５０】
サービスの変更がなされると、圧縮格納判定部７４は、変更前、つまり選局前のサービス中に未処理のモジュールがあるかどうかを判定する（Ｓ２０２）。未処理モジュールがあると判定されると（Ｓ２０２のＹ）、圧縮格納判定部７４は、未処理のモジュールを選択し（Ｓ２０４）、そのモジュールに対応するＤＩＩのＣｏｍｐｒｅｓｓｉｏｎＴｙｐｅ記述子を参照し、圧縮の有無を確認する（Ｓ２０６）。ＣｏｍｐｒｅｓｓｉｏｎＴｙｐｅ記述子からは圧縮が確認されなかった場合（Ｓ２０６のＮ）、圧縮格納判定部７４は、ｔｙｐｅ記述子を参照し、圧縮符号化のメディア型であるか否かを判定する（Ｓ２０８）。
【００５１】
圧縮符号化のメディア型でないと判定された場合（Ｓ２０８のＮ）、圧縮格納判定部７４はモジュールのデータサイズを確認し、データサイズが一定値以下であるか否かを判定する（Ｓ２１０）。モジュールのデータサイズが所定値を超える場合（Ｓ２１０のＮ）、圧縮格納判定部７４はモジュールを圧縮する（Ｓ２１２）。
【００５２】
なお、Ｓ２０６の処理において、ＣｏｍｐｒｅｓｓｉｏｎＴｙｐｅ記述子からは圧縮が確認されなかった場合（Ｓ２０６のＹ）、Ｓ２０８の処理において、モジュールが圧縮符号化のメディア型であると判定された場合（Ｓ２０８のＹ）、及びＳ２１０の処理においてモジュールのデータサイズが一定値以下であると判定された場合（Ｓ２１０のＹ）、圧縮処理を行わずＳ２０２の処理に戻る。
【００５３】
Ｓ２１２の処理においてモジュールの圧縮がなされると、圧縮格納判定部７４は圧縮されたモジュールのデータサイズを参照し、圧縮率を確認する（Ｓ２１４）。圧縮率が所定値以下の場合（Ｓ２１４のＹ）、圧縮前のモジュールを削除し、圧縮後のモジュールをコンテンツ用ＲＡＭ２８に格納し（Ｓ２１６）、Ｓ２０２の処理に戻る。また、圧縮率が所定値を超える場合（Ｓ２１４のＮ）、圧縮後のモジュールを破棄し、Ｓ２０２の処理に戻る。以降、変更前のサービスに未処理のモジュールが無くなるまでＳ２０４からＳ２１６に示した一連の処理を継続し、未処理モジュールが無くなると（Ｓ２０２のＮ）、このフローで示す処理は終了する。
【００５４】
図５は、コンポーネントをまたがる文書遷移の際に行われる圧縮判定及び圧縮処理を示すフローチャートである。この処理は、図４に示したフローで示した処理とほぼ同じである。異なる処理は、図４のＳ２０２の処理の替わりに、Ｓ３０２において、遷移前のコンポーネントに未処理モジュールがあるか判定する処理にあり、以降のＳ３０４からＳ３１６の処理は、図４のＳ２０４からＳ２１６の処理と同一である。
【００５５】
以上、本実施の形態によれば、データ放送受信機において、モジュールを所定の記憶領域に格納する際、圧縮してモジュールを保持することにより、使用する記憶領域を少なくすることが期待できる。また、視聴中コンポーネントのモジュールや、データ放送用のブラウザから要求中のモジュールについては、すぐに読み出される可能性が高いので圧縮せずに格納するようにすることによって、ユーザに違和感のない操作性を提供することができる。また、あらかじめ圧縮されているモジュールや、ＪＰＥＧ形式等のメディアとして圧縮機能が備わったものは重複して圧縮しないようにするとともに、それ以外のものについても圧縮率が一定以下にならない場合は圧縮を行わないようにすることで、適切なデータ管理が期待できる。
【００５６】
同様に、コンポーネントをまたがる文書遷移時においても、視聴中コンポーネント以外のコンポーネントは圧縮状態で所定の記憶領域に保持するようにする。また、マルチパート形式のモジュールについては、一旦ブラウザから読み出された後も、解凍状態のまま保持することにより再読み出し時の速度低下を防止することができる。
【００５７】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５８】
【発明の効果】
本発明によれば、デジタル放送におけるデータ放送の処理速度を向上させることが期待できる。
【図面の簡単な説明】
【図１】実施の形態に係るデジタル放送受信装置の構成を示すブロック図である。
【図２】文書データを表示するＢＭＬブラウザの機能を示す概略ブロック図である。
【図３】モジュールを受信した際に行われる圧縮判定及び圧縮処理を示すフローチャートである。
【図４】サービス選局時に行われる圧縮判定及び圧縮処理を示すフローチャートである。
【図５】コンポーネントをまたがる文書遷移の際に行われる圧縮判定及び圧縮処理を示すフローチャートである。
【符号の説明】
１０  デジタル放送受信装置、  １８  ＴＳデコーダ、  ２０  ＭＰＥＧデコーダ、  ２２  出力制御部、  ２４  ＯＳＤ制御部、  ２６  ＲＯＭ、  ２８  コンテンツ用ＲＡＭ、  ３０  演算処理部、  ３４  蓄積デバイス、  ４４  マルチプレクサ、  ６０  パーサ部、  ７２  圧縮解凍処理部、  ７４  圧縮格納判定部、  ９０  ＢＭＬブラウザ。
【図１】
2004304307.tif 000003
【図２】
2004304307.tif 000004
【図３】
2004304307.tif 000005
【図４】
2004304307.tif 000006
【図５】
2004304307.tif 000007