(57)【要約】デジタル放送システム中の端末（６０）は、Java（登録商標）バイトコードのような第一のコードフォーマットのアプリケーションを処理するJava（登録商標）仮想マシンのような仮想マシン（１５０）をサポートする。第二のコードフォーマットで受信されたアプリケーションを第一のコードフォーマットに変換するプラグイン（１１０）が提供される。プラグイン（１１０）はアプリケーションを第一のコードフォーマットにコンパイル（１２０）できる。アプリケーションは受信時にコンパイル（１２０）されることもできるし、あるいは保存（６９）されて夜間に、または仮想マシン（１５０）に余剰の処理容量（１１４）があるときのようなのちの時点でコンパイルされてもよい。アプリケーションはモニタリングされた使用統計（１１２）に基づいて変換されることができる。
2007524297.tif 000002
【特許請求の範囲】
【請求項１】
デジタル放送システム中の、第一のコードフォーマットのアプリケーションを処理するよう構成された仮想マシンをサポートしている端末においてアプリケーションを処理する方法であって：
アプリケーションを第二のコードフォーマットで受信し、
前記アプリケーションの少なくとも一部を前記第一のコードフォーマットに変換する、
ステップを有することを特徴とする方法。
【請求項２】
前記アプリケーションを変換する前記ステップが、コンテンツを前記第一のコードフォーマットにコンパイルすることを含むことを特徴とする、請求項１記載の方法。
【請求項３】
コンパイルされたアプリケーションを実行することをさらに含むことを特徴とする、請求項２記載の方法。
【請求項４】
請求項１ないし３のうちいずれか一項記載の方法であって、変換されたコードを保存することをさらに含むことを特徴とする方法。
【請求項５】
請求項１ないし４のうちいずれか一項記載の方法であって、受信したアプリケーションを前記第一のコードフォーマットに変換する前に該アプリケーションを保存することをさらに含むことを特徴とする方法。
【請求項６】
仮想マシンの活動をモニタリングし、前記アプリケーションを前記第一のコードフォーマットに変換すべき時点をモニタリングされた活動に基づいて選択することをさらに含むことを特徴とする、請求項５記載の方法。
【請求項７】
受信したアプリケーションを前記第一のコードフォーマットに解釈してその解釈されたアプリケーションの使用をモニタリングすることをさらに含み、そのモニタリングされた使用に基づいて前記アプリケーションが前記第一のコードフォーマットにコンパイルされることを特徴とする、請求項５記載の方法。
【請求項８】
請求項１ないし７のうちいずれか一項記載の方法であって、前記変換するステップが前記アプリケーションのある部分を解釈し、前記アプリケーションの別の部分をコンパイルして前記第一のコードフォーマットにすることを特徴とする方法。
【請求項９】
前記アプリケーションがスクリプトで書かれた動作とその他のコンテンツとを含んでおり、スクリプトで書かれた動作だけがコンパイルによって前記第一のコードフォーマットにされることを特徴とする、請求項８記載の方法。
【請求項１０】
請求項１ないし９のうちいずれか一項記載の方法であって、前記第二のコードフォーマットで受信されたうち選ばれたアプリケーションのみが前記第一のコードフォーマットに変換されることを特徴とする方法。
【請求項１１】
請求項１ないし１０のうちいずれか一項記載の方法であって、変換されたアプリケーションを別の端末に送ることをさらに含むことを特徴とする方法。
【請求項１２】
請求項１ないし１１のうちいずれか一項記載の方法であって、前記仮想マシンがJava（登録商標）仮想マシンであり、前記第一のコードフォーマットがJava（登録商標）バイトコードであることを特徴とする方法。
【請求項１３】
請求項１ないし１２のうちいずれか一項記載の方法であって、前記端末がマルチメディアホームプラットフォーム（MHP）端末であり、前記コンパイルされたコンテンツがMHP  Xレットであることを特徴とする方法。
【請求項１４】
請求項１ないし１３のうちいずれか一項記載の方法であって、前記第二のコードフォーマットがレガシー伝送コードフォーマットであることを特徴とする方法。
【請求項１５】
前記第二のコードフォーマットがMHEG-5であることを特徴とする、請求項１４記載の方法。
【請求項１６】
請求項１ないし１５のうちいずれか一項記載の方法を実行するよう構成されていることを特徴とする、デジタル放送システム中の端末のための制御装置。
【請求項１７】
請求項１ないし１５のうちいずれか一項記載の方法に従う仕方で端末の動作を制御するためのソフトウェア。
【請求項１８】
請求項１７記載のソフトウェアを具現する、デジタル放送システム中での伝送のための信号。
【請求項１９】
請求項１６記載の制御装置または請求項１７記載のソフトウェアを組み込んでいることを特徴とする端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデジタル放送端末に、特にそのような端末における処理アプリケーションに関する。
【背景技術】
【０００２】
デジタルビデオ放送（DVB:  Digital  Video  Broadcasting）システムは元来オーディオおよびビデオ素材を配送するために開発された。近年では端末によってダウンロードされ、実行されることのできるアプリケーションを配送することに関心が高まっている。デジタルビデオ放送マルチメディアホームプラットフォーム（DVB-MHP:  Digital  Video  Broadcasting  Multimedia  Home  Platform）は、マルチメディアセットトップボックスのための諸規格を調和させようとする努力の結果である。それは双方向デジタルテレビのためのオープンな、公開された規格である。DVB-MHP、あるいは単にMHPは双方向デジタルアプリケーションとそのアプリケーションを実行する端末との間の一般的インターフェースを定義している。ETSI  TS  101812  V1.3.1のようなMHP規格はww.etsi.orgにて閲覧できる。MHP規格のバージョン1.0.3は、「Xレット（Xlet）」と呼ばれる自由にダウンロードできるアプリケーションをサポートする。ETSI  TS  102819で述べられているデジタルビデオ放送大域実行可能MHP（DVB-GEM:  Digital  Video  Broadcasting  Globally  Executable  MHP）もダウンロード可能アプリケーションをサポートしている。しかし、MHPは、MHEG-5のような他のいかなるフォーマットのアプリケーションも直接は処理できない。MHPは規格で定義されているもの以外のアプリケーションフォーマットを扱うための「プラグイン」をサポートしており、端末が該当するデータを受信するとそのプラグインが作動させられる。プラグインの定義された出力は、単にそのアプリケーションの実行である。
【０００３】
双方向テレビのためにMHP以外の規格が使われている市場（たとえばMHEGが使われている英国）では、レガシーシステムをサポートするMHP端末を有することが望ましい。送信チェーンの放送側でレガシーフォーマットからMHPに変換することは可能であるが、これはいくつかの不都合な点がある。特に、コンテンツをレガシーフォーマットと新フォーマットの両方で同時放送することが必要となることがあり、それは通信帯域の無駄である。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
MHP端末のためのプラグインを使ってレガシーアプリケーションフォーマットを解釈する（interpret）ことはできるが、MHEGのような記述的言語（descriptive  language）を解釈するのは遅いことがある。
【０００５】
本発明は、代替的なフォーマットを処理できるデジタル放送端末を提供しようとするものである。
【課題を解決するための手段】
【０００６】
したがって、本発明の第一の側面は、デジタル放送システム中の、第一のコードフォーマットのアプリケーションを処理するよう構成された仮想マシンをサポートしている端末においてアプリケーションを処理する方法を提供する。該方法は：
アプリケーションを第二のコードフォーマットで受信し、
前記アプリケーションの少なくとも一部を前記第一のコードフォーマットに変換する、
ステップを有する。
【０００７】
記述式言語のような第二のコードフォーマットで書かれたアプリケーションを仮想マシンがサポートする第一のコードフォーマットに変換することは、端末の実行速度を改善できる。特にコードが何度か実行される場合はそうである。端末は、その端末のハードウェアおよびソフトウェアに固有の、仮想マシンの基礎にあるネイティブなコードフォーマットも有していることは理解されるであろう。アプリケーションを変換するステップはそのアプリケーションの少なくとも一部を第一のコードフォーマットにコンパイルすることが好ましい。
【０００８】
アプリケーションを第一のコードフォーマットに完全に変換すれば、変換されたアプリケーションがプラグインから独立して使用されることが可能になる。これは、そのアプリケーションを保存したり、他のデバイスに伝搬させたりする場合に有用である。
【０００９】
MHP端末については、仮想マシンはJava（登録商標）仮想マシンであり、第一のコードフォーマットはJava（登録商標）バイトコードである。アプリケーションはMHEG-5のようなレガシーフォーマットで受信されることがある。あるページの情報を単発でレンダリングするためなら、第二のコードフォーマットのコードを第一のコードフォーマットにコンパイルするのにかかる全体としての時間は、そのコードを解釈するよりも長くなる可能性が高い。しかし、ひとたび第一のフォーマットにコンパイルされたら、コードの実行は著しく高速になる。よって、そのページが複数の機会に使用されるのであれば、複数の機会にコードを解釈するのに比べてかなりの時間の節約が可能になる。Java（登録商標）仮想マシンがJIT（Just  in  Time）コンパイラを有していれば、Java（登録商標）バイトコードはさらにJava（登録商標）バイトコードから端末のネイティブコードにコンパイルされ、それにより実行速度をさらに改善することができる。
【００１０】
実行可能MHP  Xレットのような第一のフォーマットにひとたび変換されれば、コンテンツはMHPをサポートするデバイスに保存され、再利用されうる。たとえば、レガシー双方向アプリケーションを含むサービスの記録は、そのアプリケーションをMHPに変換し、次いでそのアプリケーションを記憶装置上に保存することによってなされうる。そのアプリケーションが送られる再生装置はMHPをサポートしてさえいればよく、レガシーアプリケーションタイプをサポートするプラグインを持つ必要はない。
【００１１】
コンテンツをコンパイルするさらなる利点は、クラスサイズおよびランタイムメモリ使用という意味でのコンパイルされたアプリケーションのフットプリントが通例インタープリタよりも少なくなるということである。これは、インタープリタはそのアプリケーションによって使用される部分のみではなく、完全な言語機能を処理できる必要があるからである。本方法はMHEG-5フォーマットのコンテンツの変換に限定されるものではなく、オープンTV（OpenTV）やメディアハイウェイ（MediaHighway）といった他のレガシーアプリケーションフォーマットからのコンテンツを変換するために使用されることもできる。
【００１２】
好ましくは、本方法は当該端末と一緒に供給される、あるいは何らかののちの時点で当該端末に更新としてダウンロードされることのできるソフトウェアプラグインによって実行される。したがって、本発明のもう一つの側面は、本方法を実行するためのソフトウェアを提供する。このソフトウェアは電子メモリデバイス、ハードディスク、光ディスクまたはその他の機械可読記憶媒体上に保存されていてもよい。ソフトウェアは機械可読担体上のコンピュータプログラムプロダクトとして配送されてもよいし、あるいは放送チャンネルまたはネットワーク接続を介して当該端末に直接にダウンロードされてもよい。
【００１３】
本発明のさらなる側面は本方法を実行する端末のための制御装置および該制御装置またはソフトウェアを組み込んだ端末を提供する。端末はセットトップボックス（STB:  set-top  box）の形を取ることが最もありそうであるが、マルチメディアパソコン（PC）またはセットトップボックスの機能を組み込んだテレビのような他の形を取ることもできる。
【００１４】
本発明の実施形態についてこれからあくまでも例として付属の図面を参照しつつ述べる。
【発明を実施するための最良の形態】
【００１５】
図１はアプリケーションを端末に配送するためのデジタルビデオ放送システムを示している。コンテンツは放送者３０によって生成され、放送チャンネル３５を介したユーザー敷地１００への送信のために好適なフォーマットに変換される。そのような敷地１００の一つが図示されている。典型的には、放送チャンネル３５は衛星を介して配送されるが、地上波送信ネットワーク、ケーブル配信ネットワークまたはインターネットのようなデータネットワークによって配送されることもできる。配送の方法は本発明にとって重要ではない。ユーザー敷地にある端末（セットトップボックス、STB）６０は放送ストリームを受信するが、この実施例ではアンテナ１８を介してである。放送チャンネル３５を介して配送される放送ストリームはオーディオおよびビデオコンテンツのほかさまざまなサービスおよびアプリケーションをサポートするためのデータを含む。DVB-MHP仕様では、アプリケーションのためのデータはデジタル記憶媒体‐コマンドおよび制御（DSM-CC:  Digital  Storage  Media‐Command  and  Control）オブジェクトカルーセル（Object  Carousel）の部分として放送される。これは、さまざまなアプリケーションのためのデータファイルを含む、反復的に放送されるファイルシステムである。DSM-CCを含むDVB-MHPシステムのための放送チャンネルのフォーマットはISO/IEC13818-6において述べられており、当技術分野に通じた読者はさらなる情報についてはそちらを参照されたい。
【００１６】
アプリケーションは放送者３０によって、あるいは必要とされるファイルをDSM-CCへの挿入のために放送者３０に提供する独立アプリケーション提供者５０によって生成されることができる。アプリケーションの例としては、電子番組表（EPG:  electronic  programme  guide）、ゲーム、クイズ、操作案内およびホームバンキングのような電子商取引アプリケーションが含まれる。
【００１７】
セットトップボックス６０は、外部パーティーとの間のデータ送受信を可能にする双方向チャンネル８５をサポートするモデムも具備している。双方向チャンネル８５は典型的にはPOTSのような従来の電話ネットワークを使用する。双方向チャンネル８５は：アプリケーション提供者５０へのPOTSを通じた直接のダイヤルアップ接続、インターネットのようなデータネットワークのゲートウェイへの接続（ゲートウェイとアプリケーション提供者５０との間の接続は前記データネットワークを通じて担われている）、ケーブルテレビのバックチャンネルとデータネットワーク（インターネット）を通じたアプリケーション提供者への接続との組み合わせ、ADSLその他のブロードバンドインターネット接続、衛星アップリンクまたはISDN回線の形を取ることができる。
【００１８】
セットトップボックス６０はまた、ユーザー入力２２を受け取るためのリモコン２０またはキーボードと、テレビディスプレイ１２に供給されるビデオ信号１０上に重ねられるメッセージを表示するグラフィカル出力とをもつユーザーインターフェースも含んでいる。
【００１９】
図２は、典型的なMHP端末６０内の機能ブロックを示している。既知のように、端末６０は受け取った放送信号３５を処理するためのフロントエンドを含んでいる。これは必要とされるチャンネルを選択して復調するためのチューナーおよび復調器６１と、信号のスクランブルを解除するための任意的な限定受信ユニット６２とを含んでいる。結果として得られるデジタルデータストリームはオーディオおよびビデオデータを表すデータストリーム（典型的にはMPEG-2フォーマット）と、反復的に放送されるDSM-CCオブジェクトカルーセル６４の形のアプリケーション用データとに多重化解除６３される。オーディオおよびビデオデータは次いでさらに処理６５されてユーザーへの提示に好適な出力信号１０，１４が導出される。放送ストリームからひとたびダウンロードされたら、アプリケーション（単数または複数）は端末のメモリ６９内に存在し、マイクロプロセッサ６８によって実行されることになる。アプリケーションはユーザー入力２２を受け取り、オーディオおよびビデオ出力を生成し、アプリケーションプログラミングインターフェース（API:  Application  Programming  Interface）を介して双方向チャンネル８５にアクセスする。端末を動作させるための制御ソフトウェアも記憶装置６９上に存在する。図２に示されているのが放送配送チャンネルを介して信号を受信することを意図した端末であることを注意しておくべきであろう。非放送配送チャンネルとのインターフェースをもつよう意図された他の実施形態の端末では、チューナー／復調器６１はその配送チャンネルに適したネットワークインターフェースによって置き換えられる。これはインターネットプロトコル（IP:  Internet  Protocol）ベースの配送チャンネルでありうる。
【００２０】
図３は、プロセッサ６８によって実装される処理環境の、本発明にとって重要な主要部分を示している。MHP端末がJava（登録商標）仮想マシン（JVM:  Java（登録商標）  Virtual  Machine）のまわりに構築され、アプリケーションはJava（登録商標）言語で書かれ、その後Java（登録商標）バイトコードにコンパイルされる。Java（登録商標）の使用は、端末上に存在する特定のハードウェアおよびソフトウェアに関わりなく、アプリケーションを共通フォーマットで書けるという利点を有している。端末６０上に存在する、あるいは端末にダウンロードされるMHPアプリケーション１１０は、Java（登録商標）バイトコードでないある種のコンテンツタイプ（たとえばMHEG-5）のためのプラグインとして作用する。これにより端末はコンテンツを表示できる。MHEG-5のページが受信され、コンパイル機能１２０に回送１１５される。コンパイル機能１２０の出力１２５はJVMによって実行できるJava（登録商標）バイトコードである。コンパイルされたJava（登録商標）バイトコードはのちの使用のために端末中の記憶装置６９にも回送１１５されることもできる。
【００２１】
アプリケーション起動時の大きな遅延を回避するため、初期にはアプリケーションは従来の仕方で解釈され、それからのちの時点でJava（登録商標）バイトコードにコンパイルされることができる。コードのコンパイルはJVMがアイドルであるか、あるいは少なくともその機能を実行するための十分な余剰処理容量がある時点にスケジュールされることができる。そのような時点はJVM活動モニタ１１４によって決定される。あるいはまた、コンパイルは夜間など静穏であるとわかっている時点に実行されることもできる。こうして、MHEG-5コンテンツは端末によって受信され、記憶装置６９に保存され、そして後刻記憶装置６９から取り出されてバイトコードにコンパイルされる。
【００２２】
コードをコンパイルするかどうかの決定は、使用頻度あるいは使用モニタ機能１１２によって収集されるその他のヒューリスティクスといった使用統計に基づくことができる。ある特定のコードブロックが頻繁に使用される場合にはそのブロックをJava（登録商標）バイトコードにコンパイルすることに利点があることは理解されるであろう。利用モニタ機能１１２はある閾値を使って候補となるコードブロックをコンパイルに関して識別する。使用モニタ機能および活動モニタ１１４はインターフェース１１５を介してJVMと通信する。あらゆるMHP端末はMHPアプリケーション（MHPで定義されるクラス）のための何らかの種類のアプリケーションデータベースを有している。これはたとえば、異なるMHP（および非MHP）アプリケーションの使用を監視するために拡張されることができる。データは不揮発性メモリ６９に保存されることができる。
【００２３】
プラグイン１１０はハイブリッドモードで動作することもできる。ハイブリッドモードでは、受信したアプリケーションの一部のみがコンパイル１２０され、アプリケーションの残りはインタープリタ式１３０に処理される。たとえば、MHEG-5フォーマットは表示レイアウトの宣言的な記述からなり、ランタイムイベントに対して発生するスクリプト要素が付随している。単純なMHEG-5コンパイラなら、スクリプトで書かれた動作のシーケンスのみを新しいバイトコードにコンパイル１２０することを選んでもよい。これでランタイム速度の改善の大半が得られる。
【００２４】
再び図２を参照すると、端末６０は、ネットワークインターフェース７０を有している。ネットワークインターフェース７０によって端末６０は、敷地１００にある装置のネットワークの一部をなすことができる。家庭ネットワーク７０はここでは無線イーサネット（登録商標）（IEEE802.11）のような無線ネットワークとして示されている。しかし、これは本発明にとって重要ではなく、ネットワークは、イーサネット（登録商標）、電力線ネットワーキング（たとえばHomePlug）、電話線ネットワーキング（たとえばHomePNA）のようなプロトコルをサポートする有線ネットワークであってもよいし、あるいはIEEE802.11a、ブルートゥースまたはZigBeeのような無線ネットワークでもよい。ネットワークインターフェース７０を使用して、端末６０はコンパイルされたアプリケーションをネットワーク内の他の装置９０、９２に送ることができる。該他の装置９０．９２はレガシーフォーマットタイプをサポートするプラグイン１１０を持たない装置であってもよい。
【００２５】
現行のMHP仕様におけるようにプラグインによるClassLoaderの直接生成が妨げられている場合、動的に生成されたJava（登録商標）クラスを、プラグインによって提供されるローカルサーバーにアクセスするorg.dvb.lang.DvbClassLoaderインスタンスを使ってロードすることができる。このことは同時係属出願GB0318198.9において記載されている。プラグインアプリケーション１１０は主要なMHEG-5ページを表すクラスのインスタンスを生成し、そのエントリーメソッドを呼び出す。そのクラスは通常のXレット・インターフェースをインプリメントし、通常のMHPアプリケーションとして振る舞うことができる。生成されたそのクラスは標準的なMHPの規則に従うことができる、すなわち、アプリケーションの主要クラスはjavax.tv.xletインターフェースをインプリメントし、通常のMHPアプリケーションのように振る舞う（ライフサイクルなど）。あるいは独自のJava（登録商標）アプリケーションのように振る舞うこともできる。
【００２６】
ClassLoader生成に対する制限を克服するため、プラグイン１１０は端末６０上に小さなHTTPサーバーを生成する。HTTPサーバーは指定されたポートをもつjava.net.ServerSocketクラスを生成する。典型的には、アドレスはlocalhostすなわち127.0.0.1となる。プラグイン１１０は次いでDVBClassLoaderを生成する。DVBClassLoaderはMHP規格の一部であり、URLから、たとえばHTTPサーバーからしかクラスをロードできない。プラグイン１１０は生成したばかりのHTTPサーバーのURLを渡すDVBClassLoaderに渡す。ひとたびDVBClassLoaderがこのポートに接続すると、ソケット（java.net.Socket）接続が生成される。この接続は双方向通信のために使用されることができる。プラグイン１１０は次いでDVBClassLoader内部の主要アプリケーションをスタートさせることができる。アプリケーションがクラスをロードする必要があるとき、DVBClassLoaderからHTTPサーバーにそのクラスのためのデータの要求が送られる。生成されたクラスファイルは次いでHTTPサーバーに渡され、そこから抽出される。
【００２７】
上記の実施形態では、プラグイン１１０はアプリケーションをJava（登録商標）仮想マシンが実行できるJava（登録商標）バイトコードに変換する。異なるタイプの処理環境が使用されている場合には、プラグイン１１０はアプリケーションをその環境と互換なコードに変換することは理解されるであろう。上記の記述では、プラグイン１１０はそれ自身がJava（登録商標）アプリケーションである相互運用可能なプラグインであった。しかし、相互運用可能でないプラグインを使ってもよい。その場合、プラグインは特定の端末のためにコンパイルされたアプリケーションである。このタイプのプラグインは、すでにコンパイルしたバイトコードを呼び出すためにカスタマイズされた方法を使用できる。たとえば、相互運用可能なアプリケーションには通例与えられない追加的なパーミッションを持つこともでき、それによりローカルなHTTPサーバーおよびDvbClassLoaderを使うことなくクラスをロードすることができる。これはより効率的なアプローチである。
【００２８】
上述した諸実施形態は本発明を限定するのではなく解説するものであり、当業者は付属の請求項の範囲から外れることなく多くの代替的な実施形態を考案することができるであろうことを注意しておくべきである。請求項において、括弧内に参照符号があったとしても請求項を限定するものと解釈してはならない。「有する」および「含む」の語は請求項において挙げられている以外の要素またはステップの存在を排除するものではない。
【図面の簡単な説明】
【００２９】
【図１】デジタル放送システムを示す図である。
【図２】図１の加入者端末を示す図である。
【図３】本発明のある実施形態を実行するための、図２の端末によって使用される処理環境の主要な機能ブロックを示す図である。
【符号の説明】
【００３０】
１０  ビデオ出力
１４  オーディオ出力
２２  ユーザーインターフェース
３０  放送者
３５  放送信号
５０  アプリケーション提供者
６１  チューナー／復調器
６３  デマルチプレクサ
６５  AV処理
６８  プロセッサ
６９  記憶装置
７０  ネットワークインターフェース
７２  モデム
８０  POTS／インターネット
８５  双方向チャンネル
１１２  使用モニタリング
１１４  JVM活動モニタ
１１５  ルーター
１２０  コンパイラ
１３０  インタープリタ
【図１】
2007524297.tif 000003
【図２】
2007524297.tif 000004
【図３】
2007524297.tif 000005
【国際調査報告】
2007524297.tif 000006
2007524297.tif 000007
2007524297.tif 000008
2007524297.tif 000009