JP2008515322A - Ｍｈｐアプリケーションの起動時間を減少させるシステム及び方法 - Google Patents

Abstract

ＭＨＰ１.０.ｘの持続性記憶域能力及びカスタム・クラスローダを利用することによりＭＨＰ１.０.ｘ規格に基づくＭＨＰアプリケーションの起動時間を減少させるシステム及び方法が提供される。ＭＨＰ１.０.ｘアプリケーションが、前記アプリケーション自体を持続性記憶域に複製し、前記持続性記憶域から前記アプリケーションを実行することを可能にする汎用ラッパクラスが作成され、これにより起動時間を減少させる。前記汎用ラッパクラスは、ＭＨＰプロトコル内の２つの事前に存在するＡＰＩ，即ちＤＶＢクラスローダＡＰＩ及び持続性記憶域ＡＰＩを使用する。

Description

本発明は、ＭＨＰ１.０.ｘ標準規格に基づくＭＨＰアプリケーションの起動時間を減少させるシステム及び方法に関する。

テレビ放送消費者の多くの高機能の市場主導型の要求を満たすために、サブスクライバ・セットトップボックスにコンテンツデータを通信するようなミドルウェア・プラットフォーム・プロバイダは、複数の異種放送及びウェブ対応ネットワークを越えて展開されるコンテンツ（即ち、アプリケーション／データ）にアクセスする必要がある。これらのネットワークは、一般に、例えば、（ＤＶＢ−Ｃ（ケーブル）、ＤＶＢ−Ｔ（地上波）及びＤＶＢ−Ｓ（衛星）を含む）デジタルビデオ放送（ＤＶＢ）、オープンケーブル・アプリケーション・プラットフォーム（ＯＣＡＰ）、アドバンストテレビシステム委員会（ＡＴＳＣ）、国家テレビ標準委員会（ＮＴＳＣ）、ＧＩモトローラネットワーク、及びマルチメディアホームプラットフォーム（ＭＨＰ）標準規格等を含む米国又は欧州の産業デジタル放送標準規格に基づく。ＭＨＰ規格は、衛星、ケーブル、地上波、及びマイクロウェーブを含む全ての伝送ネットワークにおける放送及びインタラクティブサービスに対して既存のＤＶＢ規格を拡張する。ＤＶＢ／ＭＨＰ規格は、インタラクティブデジタルアプリケーションと前記アプリケーションが実行する端末との間の汎用（generic）、即ちハードウェアに独立なインターフェースを規定する。これは、デジタルコンテンツプロバイダが、ローエンドからハイエンドのセットトップボックス、統合デジタルテレビセット及びマルチメディアＰＣまでの範囲の全てのタイプの端末にアドレスすることを可能にする。

ＤＶＢ／ＭＨＰ規格によると、ＭＨＰアプリケーションは、ＤＳＭ−ＣＣとして既知のプロトコルにより周期的な形式で放送される。アプリケーションを開始するために、受信器は、少なくとも前記アプリケーションを開始するのに必要とされる部分が来るまで待機しなければならない。多くの場合、この時間は、完全なアプリケーションのサイクル時間に等しく、これは不十分であり、時間がかかる。更に、帯域幅制限及び増大するアプリケーションサイズは、前記アプリケーション起動時間を更に大幅に制限する。前記ＭＨＰアプリケーションを統合受信器デバイスの常駐型ファイルシステム（resident file system）に記憶することは、ＡＰＩが、必要に応じて前記記憶されたＭＨＰアプリケーションの取り出しを容易化するように構成される点で、ＭＨＰ１.１.ｘ規格によって動作するシステムに対して完全な解決を提供する。しかしながら、多くのユーザは、依然としてＭＨＰ１.０.ｘからＭＨＰ１.１.ｘに移る必要があり、記憶されたＭＨＰアプリケーションを取り出すような機能は、ＭＨＰ１.０.ｘには存在しない。

したがって、ＭＨＰ１.０.ｘ標準規格に基づくＭＨＰアプリケーションの起動時間を減少させる装置及び方法を提供することが望ましい。

本発明によると、ＭＨＰ１.０.ｘ標準規格に基づくＭＨＰアプリケーションの起動時間を減少させるシステム及び方法が提供される。広くは、本発明のシステム及び方法は、説明されるようにＭＨＰ１.０.ｘのカスタム・クラスローダ（Classloader）及び持続性記憶域（persistent storage）性能を利用することにより、ＭＨＰ１.０.ｘアプリケーションが起動時間を減少させることを可能にする。

一実施例において、汎用ラッパ（ＧＷ、generic wrapper）クラスがＭＨＰ１.０.ｘアプリケーションに対して作成され、これは、ＭＨＰ１.０.ｘアプリケーションが、ＭＨＰ１.０.ｘアプリケーションの起動時間を減少させるために従来のような放送ファイルシステムの代わりに、持続性ファイルシステム（persistent file system）に前記アプリケーション自体を複製し、前記持続性ファイルシステムから前記アプリケーション自体を実行することを可能にし、前記持続性ファイルシステムは、例えば、インタラクティブデジタルテレビ（ＩＤＴ）システム又はセットトップボックス（ＳＴＢ）に関連付けられることができる。前記放送ファイルシステムは、放送ストリームによりＤＳＭ−ＣＣプロトコルによって搬送されるファイルシステムである。

起動時間は、ＭＨＰプロトコル内の２つの以前から存在するＡＰＩ、即ちＤＶＢクラスローダ（DVBClassloader）ＡＰＩ及び持続性記憶域ＡＰＩを使用することにより前記汎用ラッパ（ＧＷ）クラスにより減少される。前記ＤＶＢクラスローダＡＰＩは、常駐型ファイルシステム内のディレクトリからクラス及びリソースをロードすることができるＤＶＢクラスローダオブジェクトをインスタンシエートする（instantiate）ために前記汎用ラッパ（ＧＷ）クラスにより呼び出される。前記ＤＶＢクラスローダオブジェクトは、前記持続性ファイルシステム内のクラスファイルの場所と、前記放送ファイルシステム内のクラスファイルの場所とを含むＵＲＬのリストを受信する。前記ＤＶＢクラスローダオブジェクトは、前記リスト内の第１のＵＲＬを使用して前記持続性ファイルシステム内のＭＨＰ１.０.ｘアプリケーションのクラスファイル及びリソースを検索する。前記持続性ファイルシステム内で見つからなかったクラス及びリソースに対して、前記ＤＶＢクラスローダオブジェクトは、前記リスト内の第２のＵＲＬを使用して前記放送ファイルシステムにおいて前記持続性ファイルシステム内で見つからなかったクラス及びリソースを検索する。

他の態様によると、前記汎用ラッパ（ＧＷ）クラスが呼び出されるたびに、コピースレッドプロセス（copythread process）（Ｊａｖａ（登録商標）タスク）が作成され、前記コピースレッドプロセスは、前記放送システムから前記持続性ファイルシステムにファイルを複製し始める。より具体的には、持続性記憶域ＡＰＩは、前記汎用ラッパ（ＧＷ）クラスにより呼び出される。前記コピースレッドプロセスは、前記汎用ラッパ（ＧＷ）クラスが呼び出されるたびに、持続性記憶域ＡＰＩを使用してＭＨＰアプリケーションの多くのクラスファイルを前記放送ストリームから前記持続性ファイルシステムに複製する。前記汎用ラッパ（ＧＷ）クラスが呼び出されるたびに、前記コピースレッドプロセスは、クラスを前記持続性記憶域に複製しつづけることにより以前の呼び出しにおいて中止した点で続行する。このように、前記コピースレッドプロセスは、むしろバックグラウンドプロセスに近い。このようなものとして、前記汎用ラッパ（ＧＷ）クラスに対する各呼び出しは、以前の呼び出しの各々において持続性記憶域に追加のクラスファイルを記憶したおかげで前記ＭＨＰアプリケーションの起動時間を増加的に向上させる働きをする。一実施例において、このプロセスは、上述のように前記ＤＶＢクラスローダＡＰＩと並列に実行されるように、低い優先順位で実行されてもよい。

一態様によると、前記アプリケーションに関連付けられた持続性ファイルシステムディレクトリがセキュリティ制限無しでアクセスすることができる唯一のディレクトリであることを認識することにより、前記ＭＨＰアプリケーションがＸｌｅｔコンテキストを常駐システムから受信する前に前記ＭＨＰアプリケーションの組織ＩＤ及びアプリケーションＩＤを得ることが可能である。

本発明の前述のフィーチャは、添付の図面と一緒に本発明の例示的な実施例の以下の詳細な説明を参照することにより、より容易に明らかになり、理解されることができる。

本発明は、ＤＶＢ／ＭＨＰ環境に適用されるＤＳＭ−ＣＣ放送プロトコルによる使用に対する実施例を参照して説明される。

背景技術に記載されたように、従来技術によると、図１のＩＲＤ受信器１２のようなＤＳＭ−ＣＣを使用するデジタルテレビプラットフォームは、典型的には、テレテキストのようなシステムと遭遇したモジュールにアクセスする際に、要求されるモジュールが放送される順番まで待機しなければならないことにより生じる長い遅延を避けるために、少なくとも幾らかのＤＳＭ−ＣＣモジュールをキャッシュする。しかしながらキャッシングは、限られたメモリ及び非持続性のため、不完全な解決法である。このようなものとして、記憶は好ましいオプションである。後の呼び出しのためにＭＨＰアプリケーションを持続性ファイルシステムに記憶することは、"記憶されたアプリケーション"と称されるＭＨＰ１.１の内在する機構であるが、しかしながら、ＭＨＰ１.０.ｘは、このような記憶及び前記持続性ファイルシステムからの再呼び出しに対して明示的なサポートを提供しない。

本発明のシステム及び方法は、ＭＨＰ１.０.ｘ規格により動作する既存のＭＨＰアプリケーションが、前記ＭＨＰアプリケーション自体を持続性ファイルシステムに複製し、次に前記ＭＨＰアプリケーションが開始される場合に前記ＭＨＰアプリケーション自体を前記持続性ファイルシステムからロードすることを可能にする汎用ラッパクラスを提供することによりこれらの欠点を克服する。この複製プロセスが初めの又は後の呼び出しにおいて全体としては実行されることができず、この場合、次に前記アプリケーションが開始される場合、前記アプリケーションが、前記持続性ファイルシステムから部分的にしかロードされないことに注意すべきである。

マルチメディアアプリケーションに対する通信システムのバックボーンは、ここで図１を参照して論じられる。前記バックボーンは、複数の通信パスを有する。伝送媒体は、オーディオ（Ａ）、ビデオ（Ｖ）及びデータ（Ｄ）のようなデジタル情報の高速伝送をサポートする。複数のユーザが前記バックボーンに接続され、このうち第１のユーザ１０が図１に示されている。このユーザ１０は、図１において４０で示される複数のサービスプロバイダにより提供されるテレビ番組のサブスクライバのようなマルチメディア情報の受信器として機能する。各ユーザは、入ってくる情報を処理し、ときどき情報の送信機としても機能するように構成されたセットトップボックス（図示されない）又は統合型受信器／デコーダ（ＩＲＤ）１２であることができる受信又は常駐プラットフォーム（resident platform）を持つ。

この模範的実施例において、前記常駐プラットフォームは、統合型受信器／デコーダ（ＩＲＤ）１２として実施され、ＤＶＢ／ＭＨＰ準拠であると仮定される。マルチメディアホームプラットフォーム（ＭＨＰ）仕様は、デジタルテレビに対する改良された及びインタラクティブなアプリケーションの送信のためにＤＶＢ規格により規定される。この仕様の最大のフィーチャは、Ｊａｖａ（登録商標）ミドルウェアを使用することである。Ｊａｖａ（登録商標）は、プラットフォーム間の互換性を向上させる１つの方法としてSun Microsystemsにより推進されるミドルウェアである。全てのＪａｖａ（登録商標）アプリケーションは、Ｊａｖａ（登録商標）を備えたコンピュータ又はデバイス上で実行し、Ｊａｖａ（登録商標）アプリケーションの最大のフィーチャは、前記アプリケーションが特定のプラットフォームに制限されず、幅広い動作環境において使用されることができることである。このようなものとして、マルチメディアホームプラットフォーム（ＭＨＰ）は、インタラクティブデジタルアプリケーションと、これらのアプリケーションを実行する端末との間の汎用インターフェースを規定する。このインターフェースは、異なるＭＨＰ端末実装の特定のハードウェア及びソフトウェアの詳細から異なるプロバイダのアプリケーションを分離する。これは、デジタルコンテンツプロバイダが、ローエンドからハイエンドのセットトップボックス、統合型デジタルテレビセット及びマルチメディアＰＣまでの範囲にある全てのタイプの端末にアドレスすることを可能にする。ここで使用されるように、"アプリケーション"は、放送受信装置において様々な目的を達成するために実行されるプログラムとして規定される。

ＭＨＰアプリケーションは、適切に備えられたＩＲＤ受信器１２に対してデジタルテレビ番組を持つ放送ストリームにおいて放送される。背景技術に記載されたように、前記ＭＨＰアプリケーションは、前記ＭＨＰアプリケーションが周期的に放送されるＩＳＯ／ＩＥＣ１３８１−６の下で規定されるＤＳＭ−ＣＣプロトコルのようなプロトコルによってカルーセル形式（carousel format）で放送される。適切に備えられたＩＲＤ受信器１２は、これらのＭＨＰアプリケーションを受信し、ローカルで実行することができる。アプリケーション例は、電子番組ガイド、プレイアロング（play-along）ゲーム、テレバンキング、メニューナビゲーションオプション、テレショッピング、電子新聞及び同様な情報サービスである。

上述のように、本発明は、持続性複製ラッパ（PersistentCopyWrapper）Ｘｌｅｔとも称される汎用ラッパ（ＧＷ）クラスを使用し、前記汎用ラッパ（ＧＷ）クラスは、ＭＨＰ１.０.ｘアプリケーションが、前記アプリケーション自体を持続性ファイルシステムに複製し、前記持続性ファイルシステムから前記アプリケーション自体を実行することを可能にする。したがって、この点で簡潔にＸｌｅｔを概説することは有益である。

Sun Microsystemsは、Ｘｌｅｔとも称されるＪａｖａ（登録商標）ＴＶＴＭ ＡＰＩをリリースした。Ｊａｖａ（登録商標）テレビアプリケーションは、プログラミング情報及びアナウンスのようなフィーチャ、ゲームショーに沿ってプレイする能力のような選択可能なアプリケーション、画面を横断する株式ティッカーバナーのような放送データ、又はインタラクティブ番組関連調査のような媒体制御を提供することにより放送及び視聴体験を向上させる。アプレットのようなＸｌｅｔは、前記Ｘｌｅｔを実行するソフトウェアにより制御される。アプレットの場合、基礎を成すソフトウェアは、ブラウザ又はアプレットビューワツールである。Ｘｌｅｔの場合、基礎を成すソフトウェアは、Ｊａｖａ（登録商標）テレビプラットフォームをサポートするセットトップボックス又はデジタルテレビ受信器である（例えば図１のＩＲＤ１２）。Ｘｌｅｔは、"主要な"メソッドを持たず、Ｘｌｅｔは常にインターフェースＸｌｅｔを実装する。アプレットのように、Ｘｌｅｔはライフサイクルを持ち、ライフサイクルメソッドシグネチャは、前記インターフェースＸｌｅｔにより規定される。前記インターフェースＸｌｅｔは、作成、初期化、開始、停止及び破壊のようなＸｌｅｔ状態変化を信号通知するためにライフサイクルメソッドを提供する。しかしながら、前記インターフェースＸｌｅｔは、ライフサイクルメソッドに対する実装を提供しない。

全てのＪａｖａ（登録商標）テレビ実装は、インターフェースＸｌｅｔを介して様々なアプリケーション状態を通して１つ以上のＸｌｅｔを移動するように前記ライフサイクルメソッドを呼び出すアプリケーションマネージャを持つ。上述のように、前記インターフェースＸｌｅｔは、ライフサイクルメソッドに対する実装を提供しない。開発者は、Ｘｌｅｔライフサイクル内の各点において何が起こるかを規定することによりこれらのメソッドに対するアプリケーション固有の実装を提供する。例えば、ゲームＸｌｅｔに対するｉｎｉｔＸｌｅｔメソッドは、ユーザインターフェースコンポーネントを作成することができる。Ｘｌｅｔが一部の状態変化をこれ自体で開始し、ＸｌｅｔＣｏｎｔｅｘｔインターフェースにおけるメソッドを起動することによりこれらの状態変化を前記アプリケーションマネージャに通知することができることに注意すべきである。

前記インターフェースＸｌｅｔは、Ｊａｖａ（登録商標）ＴＶＴＭ ＡＰＩにおいて規定されるパッケージの１つであるｊａｖａｘ.ｔｖ.ｘｌｅｔパッケージにより規定される。Ｊａｖａ（登録商標）ＴＶＴＭ ＡＰＩは、パッケージにグループ化されたクラス及びインターフェースからなる。これらのパッケージは、テレビネットワークにより送信される放送ストリームによりデジタル受信器に送信されるビデオ、オーディオ及びデータを処理するクラス及びインターフェースを含む。

前記ｊａｖａｘ.ｔｖ.ｘｌｅｔにおいて規定される前記インターフェースＸｌｅｔは、アプリケーションマネージャがＸｌｅｔを作成、初期化、開始、停止及び破壊することを可能にする。前記アプリケーションマネージャは、前記Ｘｌｅｔの状態を維持し、様々なライフサイクルメソッドを介して前記Ｘｌｅｔ上のメソッドを起動する。前記Ｘｌｅｔは、これらのメソッドを実装して、前記アプリケーションマネージャにより命令されたように内部活動及びリソース使用を更新する。

ｊａｖａｘ.ｔｖ.ｘｌｅｔにより規定される前記インターフェースＸｌｅｔのメソッドサマリ（method summary）は以下のとおりである。ｄｅｓｔｒｏｙｘｌｅｔは、終了し、破壊された状態に入るように前記Ｘｌｅｔに信号通知する。ｉｎｉｔＸｌｅｔは、前記Ｘｌｅｔ自体を初期化し、停止された状態に入るように前記Ｘｌｅｔに信号通知する。ｐａｕｓｅＸｌｅｔは、サービスの提供を停止し、停止された状態に入るように前記Ｘｌｅｔに信号通知する。ｓｔａｒｔＸｌｅｔは、サービスの提供を開始し、アクティブ状態に入るように前記Ｘｌｅｔに信号通知する。これらのメソッドが、以下に記載されるように、本発明の汎用ラッパクラスに組み込まれると確信される。

周知のように、ＭＨＰ１.０.ｘは、基礎を成すベンダ固有のハードウェア及びソフトウェアと独立なデジタルインタラクティブテレビに対する拡張アプリケーション実行環境を定めている。この実行環境は、Ｊａｖａ（登録商標）仮想マシンの使用と、前記インタラクティブデジタルテレビ端末の典型的なリソース及び機能に対するアクセスを提供する汎用ＡＰＩの定義とに基づく。これらの汎用ＡＰＩを使用するＪａｖａ（登録商標）アプリケーションは、ＤＶＢ−Ｊアプリケーションと称される。これに反して、ＭＨＰ１.１は、新しいオプションのアプリケーションタイプ、ＤＶＢ−ＨＴＭＬを規定することを含む複数の方法で前記ＭＨＰ１.０.ｘプラットフォームに追加の機能を提供する。ＭＨＰ１.０.ｘに対して、ＤＶＢ−Ｊのみがサポートされる必要がある。したがって、ＭＨＰ１.０.ｘの下で実行するＤＶＢ−Ｊアプリケーションに対して、"ｊａｖａｘ.ｔｖ.ｘｌｅｔ.Ｘｌｅｔ"は、定義済みのインターフェースであり、ＭＨＰ１.０.ｘの下で実行されることができる唯一の認識可能なエンティティである。

本発明は、ＭＨＰ１.０.ｘアプリケーションが、持続性ファイルシステムにＭＨＰアプリケーションのコード（クラスファイル）を記憶し、前記記憶されたクラスファイルを使用して次に実行する場合に前記持続性ファイルシステムから完全なＭＨＰアプリケーションをロードすることを可能にするＭＨＰアプリケーションに対する汎用Ｘｌｅｔラッパクラスを作成する。このように、通常は記憶されていないＭＨＰアプリケーションが、改良された起動時間を実現する。

本発明は、好ましくは、ＭＨＰ１.０.ｘアプリケーションが、前記持続性ファイルシステムに前記アプリケーション自体を複製し、前記持続性ファイルシステムから前記アプリケーション自体を実行することを可能にする、ＭＨＰアプリケーションに対する、ここで"ＰｅｒｓｉｓｔｅｎｔＸｌｅｔＣｏｐｙＷｒａｐｐｅｒＸｌｅｔ"とも称される、記載されるべき汎用ラッパ（ＧＷ）クラスを作成することにより一般的な方法で実施される。

前記汎用ラッパ（ＧＷ）クラスは、前記ＧＷラッパクラスにおいて呼び出される各メソッド、コンストラクタ（constructor）、スタティック初期化子（static initializer）が、元のＭＨＰ１.０.ｘアプリケーション内の対応するメソッド、コンストラクタ、スタティック初期化子に伝播されるように設計される。事実、前記インターフェースは、これが含むＭＨＰ１.０.ｘアプリケーションインターフェースと全く同じである。

前記元のＭＨＰ１.０.ｘアプリケーションの機能をミラーリングすることに加えて、前記汎用ラッパクラスは、２つのＡＰＩを含む。一方のＡＰＩは、Ｊａｖａ（登録商標）クラスローダの拡張であるＤＶＢクラスローダＡＰＩであり、ＭＨＰ ＡＰＩの一部である。これは、ＭＨＰアプリケーションによる使用に対して利用可能な唯一のクラスローダである点で特別な拡張である。前記ＤＶＢクラスローダＡＰＩは、Ｊａｖａ（登録）クラスが記憶されることができる場所を参照するＵＲＬの検索パスからクラス及びリソースをロードするのに使用される。本発明で使用されるように、前記ＤＶＢクラスローダＡＰＩは、前記持続性ファイルシステム内の場所のリストに対応するＵＲＬの検索パスと、前記ＭＨＰアプリケーションのクラスを探すことができる前記放送ファイルシステム内の場所のリストに対応するＵＲＬの検索パスとを備える。

第２のＡＰＩは、前記"ＰｅｒｓｉｓｔｅｎｔＸｌｅｔＣｏｐｙＷｒａｐｐｅｒＸｌｅｔ"クラスが呼び出される場合にはいつも前記ＤＶＢクラスローダＡＰＩと実質的に並列に動作することができる持続性記憶域ＡＰＩである。コピースレッドプロセスは、前記ＭＨＰ１.０.ｘアプリケーションのクラスファイルを前記放送ストリームから前記持続性ファイルシステムに複製する。前記"ＰｅｒｓｉｓｔｅｎｔＸｌｅｔＣｏｐｙＷｒａｐｐｅｒＸｌｅｔ"クラスが呼びされるたびに、前記コピースレッドプロセスは、前記持続性ファイルシステムにクラスを複製しつづけることにより以前の呼び出しにおいて中断した点で続行する。このように、前記コピースレッドプロセスは、むしろバックグラウンドプロセスに近い。このようなものとして、前記"ＰｅｒｓｉｓｔｅｎｔＸｌｅｔＣｏｐｙＷｒａｐｐｅｒＸｌｅｔ"クラスに対する各呼び出しは、前記以前の呼び出しの各々において前記持続性ファイルシステムに追加のクラスファイルを記憶したおかげで前記ＭＨＰ１.０.ｘアプリケーションの起動時間を向上させる働きをするだけである。

図２ａ及び図２ｂは、従来技術によるＭＨＰアプリケーションに対する呼び出し（図２ａ）及び本発明の"ＰｅｒｓｉｓｔｅｎｔＸｌｅｔＣｏｐｙＷｒａｐｐｅｒＸｌｅｔ"クラスに対する呼び出し（図２ｂ）の機構を説明するシーケンス図を示す。時間的に、前記シーケンス図は、ユーザがチャネルをザッピングする点から開始し、前記ＭＨＰシステムは、（１）当該チャネルに関連付けられたＭＨＰアプリケーションが存在しうること、（２）いずれのＸｌｅｔクラスファイルが各ＭＨＰアプリケーションに属するか、（３）前記ストリーム及び前記クラスの場所を応答的に決定する。この全てがＭＨＰプロトコルにカプセル化される（encapsulated）。ある時点で、前記システムは前記クラスファイルをロードし始め、これは、図２ａ及び２ｂが開始する点である。

図２ａは、従来技術のシーケンス図である。これは、ＭＨＰアプリケーションが開始される場合に前記ＭＨＰシステムが、以下のステップ、即ち（１）ラベル５１で示される前記Ｘｌｅｔクラス（即ち前記Ｘｌｅｔインターフェース、ＡｎＸｌｅｔを実装するＪａｖａ（登録商標）クラス）をロードするステップと、（２）ラベル５３で示される前記Ｘｌｅｔクラスのスタティック初期化子を実行するステップと、（３）ラベル５５で示される前記Ｘｌｅｔクラスのインスタンスを作成し、デフォルトのコンストラクタを実行するステップと、（４）ラベル５７で示されるｉｎｉｔＸｌｅｔを呼び出すステップと、（５）ラベル５９で示されるｓｔａｒｔＸｌｅｔを呼び出すステップとを実行することが示される。これらのステップは、前記ＭＨＰアプリケーションのライフサイクルを制御する。ＭＨＰアプリケーションが開始されるたびに同じステップが実行されることに注意する。大きいアプリケーションは、必然的に小さいアプリケーションよりロードするのに長い時間がかかる。ある時点において、示された前記クラスは、独自のコンストラクタ及び初期化子を持つ他のクラスを再帰的にロードし、追加の時間を要する。

図２ｂは、以後、ＧＷクラス９０と称される、前記汎用ラッパクラス、"ＰｅｒｓｉｓｔｅｎｔＸｌｅｔＣｏｐｙＷｒａｐｐｅｒＸｌｅｔ"により実行されるステップを説明する本発明の一実施例によるシーケンス図である。ＧＷクラス９０は、ＭＨＰアプリケーションを開始する（図２に示されるような）従来技術の動作を実行するのに加えて、２つのＡＰＩ、即ちＤＶＢクラスローダＡＰＩ及び持続性ファイルシステムＡＰＩを呼び出す。

ＭＨＰシステム７０は、黙示的にクラスローダ７５をインスタンシエートし、前記Ｘｌｅｔクラスをロードする。（このクラスローダはシステム固有であり、したがって前記アプリケーションにより使用されることができない。）

ＭＨＰシステム７０は、次いで、"ｌｏａｄＣｌａｓｓ"２０１を呼び出し、ＧＷクラス９０をロードする。

ＭＨＰシステム７０は、次いで、ＧＷクラス９０の"スタティック初期化子"３０１を呼び出す。この呼び出しは、ＤＶＢクラスローダオブジェクト８０をインスタンシエートする。上述のように、前記ＤＶＢクラスローダは、ＭＨＰアプリケーションが、前記持続性ファイル記憶システムからＭＨＰアプリケーションをロードするためにＭＨＰ１.０.ｘアプリケーションにおいて使用することができる、唯一の種類のクラスローダである。前記ＤＶＢクラスローダは、システムリソースであり、ＵＲＬパラメータのリスト（図示されない）を受信する。好適な実施例において、ＤＶＢクラスローダオブジェクト８０は、前記持続性ファイルシステム及び前記放送ファイルシステム内のクラスファイル及びリソースの場所を規定又は指定する２つのＵＲＬを受信する。

ＤＶＢクラスローダオブジェクト８０は、前記持続性ファイルシステム内でＭＨＰアプリケーションのクラスファイル及びリソースを検索するのに第１の提供されたＵＲＬを使用する。全てのクラス及びリソースが前記持続性ファイルシステム内で見つけられることができるわけではない。前記持続性ファイルシステム内で見つからなかったクラス及びリソースに対して、ＤＶＢクラスローダオブジェクト８０は、前記放送ファイルシステム内でクラス及びリソースを検索するために第２の提供されたＵＲＬを使用する。クラスファイルが、前記持続性ファイルシステムに存在する（即ち、以前の呼び出しから既に複製されていると仮定する）場合には常に前記持続性ファイルシステムからロードされるべきであり、前記持続性ファイルシステム内で見つからなかった代わりにのみ前記放送システムからロードされるので、この順序が非常に重要であり、本発明の鍵となるフィーチャを表していると理解されるべきである。

上で述べられた正確な順序で前記クラスファイルを取り出す（即ち、前記持続性ファイルシステムを検索した後に前記放送システムを検索する）ことは、ＭＨＰアプリケーションに対する連続した呼び出しに対して前記ＭＨＰアプリケーションの起動時間の増加的な向上を可能にする。これは、各呼び出しにおいて、バックグラウンドのコピースレッドプロセスが、追加のクラス及びリソースを前記放送ファイルシステムから前記持続性ファイルシステムに複製するので起こる。これは、前記クラスの全てが複製される最初の呼び出しにおいて複製動作を実行し、次いで前記持続性ファイルシステムからロードするのと対照的である。

典型的には、ＤＶＢクラスローダ８０は、以下のように前記ＤＶＢクラスローダにより作成される。
ライン１ String root=System.getProperty("dvb.persistentroot");
ライン２ persistentUrl = new URL("file:/"+root+"/"+orgid+"/"+appid);
ライン３ broadcastUrl = new URL("file://";
ライン４ URL[] urls = new URL[] { persistentUrl, broadcastUrl };
ライン５ DVBClassloader l = DVBClassloader.newInstance(urls);

ライン４において、上述されたＵＲＬを検索する好適な順序が規定されていることに注意する。即ち、第１の又は最初の検索は、前記持続性ファイルシステム、即ちpersistentUrlで行われ、ついで、必要に応じて、第２の検索は、前記最初の検索の間に前記持続性ファイル記憶システムで見つからなかったクラスファイル及びリソースに対して、前記放送ファイルシステム、broadcastUrlで行われる。

ＧＷクラス９０は、次にＤＶＢクラスローダオブジェクト８０のｌｏａｄＣｌａｓｓを呼び出して元のＸｌｅｔクラスをロードする。この点で、前記好適な検索順序が呼び出され、特に持続性ファイルシステムの後に放送ファイルシステムが続き、前記Ｘｌｅｔクラス及びリソースをいずれか一方の場所から取り出す。

ＤＶＢクラスローダオブジェクト８０に対する呼び出しは、実行されるＭＨＰアプリケーションからのＸｌｅｔクラスである、ＡｎＸｌｅｔ４０２と称されるクラスを返す。

ＧＷクラス９０は、次に前記元のＸｌｅｔクラスのスタティック初期化子４０３を呼び出す。

前記Ｘｌｅｔクラスのスタティック初期化子は完全であり、ＭＨＰシステム７０は、汎用ラッパ（ＧＷ）クラス９０をインスタンシエートし３０２、汎用ラッパクラス９０は、前記ＭＨＰアプリケーションをインスタンシエートする４０４。

ＧＷクラス９０は、次いで、複製プロセスを実行するスレッド４０５を作成する。

ＧＷクラス９０は、次いで、ファイル及びディレクトリを前記放送ストリームから前記持続性ファイルシステムに再帰的に複製するスレッド４０６を開始する。

ＭＨＰシステム７０は、次いで、ＧＷクラス９０のｉｎｉｔＸｌｅｔ３０３を呼び出し、ｉｎｉｔＸｌｅｔ８０１は、ＭＨＰ１.０.ｘアプリケーションのｉｎｉｔＸｌｅｔ４０７を呼び出す。

ＭＨＰシステム７０は、次いで、ＧＷクラス９０のｓｔａｒｔＸｌｅｔ３０４を呼び出し、ｓｔａｒｔＸｌｅｔ３０４は、前記ＭＨＰ１.０.ｘアプリケーションのｓｔａｒｔＸｌｅｔ４０８を呼び出す。

他の態様によると、ＭＨＰアプリケーションが前記システムから前記Ｘｌｅｔコンテキストを受信する前に、即ち、ｉｎｉｔＸｌｅｔを呼び出す前の時点で（図２ｂの３０３参照）、前記ＭＨＰアプリケーションの組織ＩＤ及びアプリケーションＩＤを得ることが可能である。下でより詳細に記載されるように、前記組織ＩＤ及びアプリケーションＩＤの取得は、前記アプリケーションに関連付けられた持続性ファイルシステムディレクトリが、セキュリティ制限無しでアクセスすることができる唯一のディレクトリであると認識することにより達成される。放送される各ＭＨＰアプリケーションは、アプリケーション情報テーブル（ＡＩＴ）と称される追加のサービス情報（ＳＩ）テーブルにも記憶される一意的な識別子を与えられる。前記ＡＩＴは、ＭＨＰアプリケーションを含むサービス毎に放送され、当該サービスに対して有効であるＭＨＰアプリケーション毎にエントリを含む。したがって、サービスが、前記サービスに関連付けられた２つのアプリケーションを持つ場合、このテーブルは、２つのエントリを含む。各ＭＨＰアプリケーションに与えられた一意的な識別子は、名称又は他の特性が一意的でないかもしれないので、前記システムの他の部分が一意的にアプリケーションを参照することができるようにすることを可能にする。各識別子は、２つの部分、即ち、ＭＨＰアプリケーションを生成する組織毎に一意的である３２ビット組織ＩＤと、１６ビットアプリケーションＩＤとからなる。このアプリケーションＩＤは、一意的である必要はないが、同じＡＩＴに信号通知される２つのアプリケーションは、同じ組織ＩＤ及びアプリケーションＩＤを持つことができない。

ＭＨＰアプリケーションが前記システムから前記Ｘｌｅｔコンテキストを受信する前に前記ＭＨＰアプリケーションの組織ＩＤ及びアプリケーションＩＤを得ることができるようにする鍵は、Ｘｌｅｔが独自のアプリケーションディレクトリにのみアクセスを持つことを知ることである。この情報は、以下のように使用される。

アプリケーションライフサイクルＡＰＩを用いて、前記汎用ラッパ（ＧＷ）クラス（即ち、"ＰｅｒｓｉｓｔｅｎｔＸｌｅｔＣｏｐｙＷｒａｐｐｅｒＸｌｅｔ"）は、現在既知である全てのアプリケーションを含むリストを受信する。一度このリストが得られると、前記ＧＷクラスは、前記リスト上で各アプリケーションに関連付けられたアプリケーションディレクトリにアクセスしようと試みる。１つを除いて全ての場合に、"セキュリティエクセプション（Security Exception）"が生じる。上述のようにＸｌｅｔは独自のアプリケーションディレクトリのみにアクセスを持つので、前記アプリケーションの独自のディレクトリのみが"セキュリティエクセプション"を起こさない。前記アプリケーションライフサイクルＡＰＩが全ての既知のアプリケーションの組織ＩＤ及びアプリケーションＩＤを公開するので、対応するものが得られることができる。

つまり、本発明のシステム及び方法は、ＭＨＰ１.０.ｘにおいて持続的に記憶されたアプリケーションに対する明確なサポートの欠如を克服する。持続性記憶域は、ＭＨＰ実装に持続的に記憶され、前記放送ストリームから再びダウンロードすることなく後の実行に対して利用可能であるように、放送されることができるアプリケーションとして規定される。より具体的には、本発明のシステム及び方法は、有利には、ＭＨＰ１.０.ｘアプリケーションが前記アプリケーション自体を持続性記憶域に複製し、前記持続性記憶域から前記アプリケーションを実行することを可能にする汎用ラッパクラスを作成することにより、ＭＨＰ１.０.ｘアプリケーションが、前記アプリケーション自体を持続性記憶域に複製し、前記持続性記憶域から前記アプリケーション自体を実行することを可能にする。

加えて、本発明のシステム及び方法は、ＭＨＰアプリケーションが前記システムからＸｌｅｔコンテキストを受信する前に前記ＭＨＰアプリケーションの組織ＩＤ及びアプリケーションＩＤを得る方法をも提供する。

本発明は、特定の実施例を参照して記載されているが、多くの変更が、添付の請求項に記載された本発明の範囲及び精神から逸脱することなく行われることができると理解されるべきである。明細書及び図面は、これに応じて、説明用と見なされ、添付の請求項の範囲を限定することは意図されない。

マルチメディアアプリケーションに対する通信システムのバックボーンを図示する。 従来技術によるＸｌｅｔクラスローディングを図示するタイムライン図を示す。 本発明によるＸｌｅｔクラスローディングを図示するシーケンス図を示す。

Claims (19)

1. ＭＨＰ１.０.ｘアプリケーションの起動時間を減少させる方法において、
   汎用ラッパ（ＧＷ）クラスを作成する動作と、
   前記ＧＷクラスの各呼び出しに応答して、
   （ａ）前記ＭＨＰ１.０.ｘアプリケーションのクラス及びリソースの一部を、該クラス及びリソースの一部が記憶されている持続性ファイルシステムからロードする動作、及び
   （ｂ）放送ファイルシステムから前記ＭＨＰ１.０.ｘアプリケーションの前記クラス及びリソースの残りの部分をロードする動作、
   を実行する動作と、
   を有する方法。
2. 前記ＭＨＰ１.０.ｘアプリケーションの前記クラス及びリソースの前記残りの部分の少なくとも一部を前記放送ファイルシステムから前記持続性ファイルシステムに複製する動作を更に有する、請求項１に記載の方法。
3. 前記複製する動作が、コピースレッドプロセスの制御下で実行される、請求項２に記載の方法。
4. 前記コピースレッドプロセスが、ＭＨＰプロトコル内で規定される持続性記憶域ＡＰＩを使用する、請求項３に記載の方法。
5. ステップ（ａ）及び（ｂ）における前記ローディングする動作が、ＭＨＰプロトコル内で規定されるＤＶＢクラスローダＡＰＩを使用する、請求項１に記載の方法。
6. 前記ＤＶＢクラスローダＡＰＩが、少なくとも第１のＵＲＬパラメータ及び第２のＵＲＬパラメータを含み、前記第１のＵＲＬパラメータが、前記ＭＨＰ１.０.ｘアプリケーションの前記クラス及びリソースの一部が記憶される前記持続性記憶域内の場所に対するクラスパスを規定し、前記第２のＵＲＬパラメータが、前記ＭＨＰ１.０.ｘアプリケーションの前記クラス及びリソースの前記残りの部分が記憶される前記放送ファイルシステム内の場所に対するクラスパスを規定する、請求項５に記載の方法。
7. ＭＨＰ１.０.ｘ規格に基づくＭＨＰアプリケーションの起動時間を減少させる方法において、
   （ａ）前記ＭＨＰアプリケーションに対する汎用ラッパ（ＧＷ）クラスを作成する動作と、
   （ｂ）前記汎用ラッパ（ＧＷ）クラスから、前記ＭＨＰアプリケーションのクラス及びリソースが記憶される受信器デバイスの持続性ファイルシステム内の場所に対応する第１のＵＲＬ検索パスを識別する第１のパラメータを持つ第１のＡＰＩを呼び出す動作であって、前記第１のＡＰＩが、前記ＭＨＰアプリケーションのクラス及びリソースが記憶される放送ファイルシステム内の場所に対応する第２のＵＲＬ検索パスを識別する第２のパラメータを更に持つ、当該呼び出す動作と、
   （ｃ）前記第１のＡＰＩの制御下で、前記持続性ファイルシステムに現在記憶されている前記ＭＨＰアプリケーションに関連付けられたクラス及びリソースをロードする動作と、
   （ｄ）前記第１のＡＰＩの制御下で、前記第２のパラメータを使用して、前記放送ファイルシステムから前記持続性ファイルシステムに現在記憶されていない前記ＭＨＰアプリケーションに関連付けられた残りのクラス及びリソースをロードする動作と、
   を有する方法。
8. 前記第１のＡＰＩがＤＶＢクラスローダＡＰＩである、請求項７に記載の方法。
9. （ａ）前記汎用ラッパ（ＧＷ）クラスから第２のＡＰＩを呼び出す動作と、
   （ｂ）前記呼び出された第２のＡＰＩから、前記ＭＨＰアプリケーションに関連付けられたファイル及びディレクトリを放送ストリームから前記持続性ファイルシステムに再帰的に複製するスレッドを開始する動作と、
   を更に有する、請求項７に記載の方法。
10. 前記第１のＡＰＩ及び前記第２のＡＰＩが、実質的に並列に動作する、請求項３に記載の方法。
11. 前記第２のＡＰＩが、持続性記憶域ＡＰＩである、請求項４に記載の方法。
12. ＭＨＰ１.０.ｘ規格によって動作する統合型受信器デバイスにおいて、
    ＭＨＰアプリケーションに対する汎用ラッパクラスを作成する手段と、
    持続性ファイルシステムに現在存在する前記ＭＨＰ１.０.ｘアプリケーションの一部をロードする手段と、
    前記持続性ファイルシステムに現在存在しない前記アプリケーション１.０.ｘアプリケーションの少なくとも一部を複製する手段と、
    を有するデバイス。
13. 前記複製する手段が、前記ＭＨＰ１.０.ｘアプリケーションのクラスファイル及びリソースを前記ＭＨＰ１.０.ｘアプリケーションを放送する放送ストリームから前記持続性ファイルシステムに複製することを更に含む、請求項１２に記載の方法。
14. 前記複製する手段が、コピースレッドプロセスの制御下で実行される、請求項１２に記載の方法。
15. 前記コピースレッドプロセスが、ＭＨＰプロトコルにおいて規定される持続性記憶域ＡＰＩを使用する、請求項１４に記載の方法。
16. 前記ロードする手段が、ＭＨＰプロトコルにおいて規定されるＤＶＢクラスローダＡＰＩを使用する、請求項１２に記載の方法。
17. 前記ＤＶＢクラスローダＡＰＩが、前記ＭＨＰアプリケーションのクラスファイルが記憶される前記持続性ファイルシステム内の場所に対するクラスパスを規定する少なくとも第１のＵＲＬパラメータ及び第２のＵＲＬパラメータを含み、前記第１のＵＲＬパラメータが、前記ＭＨＰ１.０.ｘアプリケーションを放送する放送ストリームの放送ファイルシステムのファイルシステム内の場所に対するクラスパスを規定する、請求項１６に記載の方法。
18. ＭＨＰアプリケーションがＭＨＰシステムからＸｌｅｔコンテキストを受信する前に前記ＭＨＰアプリケーションの組織ＩＤ及びアプリケーションＩＤを得る仕方を提供する方法において、
    汎用ラッパ（ＧＷ）クラスにより、前記ＭＨＰシステムから現在既知の全てのアプリケーションのリストを受信する動作であって、前記リスト上の各アプリケーションが、関連付けられた組織ＩＤ及びアプリケーションＩＤを含む、当該受信する動作と、
    前記組織ＩＤ及び前記アプリケーションＩＤを使用して、前記リスト上の各アプリケーションを、持続性ファイルシステムにおいて前記アプリケーションを識別するディレクトリリストに変換する動作と、
    前記ＧＷクラスにより、前記ディレクトリリストの各々にアクセスしようと試みる動作と、
    前記リストの中のいずれのアプリケーションがセキュリティエクセプションを返さないかを決定する動作と、
    前記セキュリティエクセプションを返さないアプリケーションとして、前記決定するステップから組織ＩＤ及びアプリケーションＩＤを得る動作と、
    を有する方法。
19. 前記変換する動作が、persistent root/organization ID/application IDの形式で前記組織ＩＤ及び前記アプリケーションＩＤを使用して前記ディレクトリリストを構成することを更に含む、請求項１８に記載の方法。

Images