本発明は、コンピュータ装置においてアプリケーションを保守する方法に関し、特に、アプリケーションの種類又は実行環境に関わらず、コンピュータ装置上のオペレーティングシステムにより統一された方法で、関連するリソースと共にユーザアプリケーションのライフサイクルを管理する方法に関する。

本明細書で使用されるコンピュータ装置という用語は、任意の形態の電気コンピュータ装置を含むように広範囲に解釈され、データ記録装置と、ハンドヘルドコンピュータ及びパーソナルコンピュータを含む任意の種類又は形態のコンピュータと、通信、画像の記録及び再生の少なくともいずれか、及び計算機能性を単一の装置に組み合わせた通信機、スマートフォン、移動電話及び他の形態の無線／有線情報装置を含む任意の形態の通信装置とを含む。

アプリケーション管理は、多くのコンピュータ装置にとって約２０年前まで問題ではなかった。 アプリケーションがテープ又はディスクからオペレータ又はユーザにより個々にロードされた場合、アプリケーションと媒体との１対１の対応は、オペレータ又はユーザがロードされたアプリケーションを常に正確に知っていたことを意味する。 初期のマルチユーザオペレーティングシステムは、複数のアプリケーションが同時にロードされることを可能にしたが、オペレーティングシステムとそのようなアプリケーションとの間の対話は一般に予測可能であり、アプリケーション間の対話は非常に少なかった。 本質的に、その頃のアプリケーションは、実行中のアプリケーション及び実行中でないアプリケーションの２種類に区分できた。

しかし、安価な大容量ディスク記憶装置が一般に普及したことにより、アプリケーションをロードする時の最低限の労力は略ゼロまで減少した。 安価なメモリが一般に普及したことにより、複数のアプリケーションをロードした結果起こるメモリ競合の問題がなくなった。 また、オペレーティングシステムの継続した開発の結果、プロセス間通信を促進した共通のアプリケーションプログラミングインタフェース（ＡＰＩ）及び豊富な共有ライブラリが生成された。

それと共に、それら３つの進歩は、第３の種類のアプリケーションの概念を助長した。 従って、上記２種類のアプリケーション、すなわち実行中のアプリケーション及び実行中でないアプリケーションに加え、第３の種類である「インストールされた」アプリケーションが存在する。 それらアプリケーションは、実行中のアプリケーションではないが、ローカル記憶装置にロードされ、一般にインストールされた時にオペレーティングシステムに対して変更を行なう。 例えば、システムライブラリの更新又はインストール、あるいはシステムレジストリの変更を行なう。

ある命令及び構成が今日のコンピュータ装置にアプリケーションをインストールする役割を果たすようにされるのが非常に望ましい。 各アプリケーションが中央管理されないために起こる無統制は、オペレーティングシステム全体を容易に不安定にし、コンピュータ装置自体の機能が危険になる。

第４の進歩は、アプリケーションの最適な管理に対する要求に更に拍車をかけた。 この進歩は、安価な公衆インターネットの使用の普及、永続的に接続された固定コンピュータ装置及び移動コンピュータ装置の使用の増加、並びにウェブブラウジング及び電子メール等のネットワーク化アプリケーションの使用の爆発的な増加の結果として得られる接続性の向上である。 それら変更が組み合わされることにより、ユーザは、コンピュータ装置のセキュリティ及び電子攻撃に対するコンピュータ装置の影響の受け易さが学術的な問題ではなく一般的な問題になっていることに気付いた。 電子攻撃の歴史は２０年以上にわたるが（最初のコンピュータウィルスは１９８３年に考案された）、電子攻撃を深刻な脅威にしたのは接続性の向上であり、事実上、コンピュータ装置の全てのユーザが危険にさらされていると感じている。

今日のオープンオペレーティングシステムは、広範囲のアプリケーション管理及びセキュリティ解決策を実装できるが、アプリケーションのライフサイクルの課題に対しては相対的に標準的な方法を有する。 それは、非強制的なアプリケーションマネージャを提供することであり、アプリケーションは、そのアプリケーションマネージャを使用して機構を登録、インストール及び削除してもよい。 尚、それら機構は、アプリケーション専用であってもなくてもよいが、通常、ネイティブ実行ファイル及びそれらのリソースの従来のアプリケーションモデルに結び付けられる。

この方法は、Windows（登録商標）インストーラ及びInstall Shield等の第３者機構により使用されるため、デスクトップコンピュータのMicrosoftオペレーティングシステムのユーザはこの方法に精通している。 それらアプリケーションは、要望に応じてアプリケーションマネージャに登録し、その動作基準に従うことがきでる。 登録を行なうと、Control Panel等の中央サービスは、それらアプリケーションについて知り、アプリケーションの削除のオプションを提供する。 しかし、アプリケーションは、この機構を使用してインストール又は削除をする義務はない。

同一のモデルは、ＲＰＭ（Red Hat Package Manager）及びDebianのＡＰＴ（Advanced Packaging Tool）を中心に多くのLinux配信により使用される。 Linux配信は、アプリケーションのインストール及び削除を考慮するが、機構が回避される可能性に対処しない。

このモデルは、バージョン８までの全てのバージョンにおいて、ＳＩＳ（Symbian Installation System）及び関連するApplnstアーキテクチャを介してLondonのSymbian LimitedのSymbian OS（商標）オペレーティングシステムにより使用された。

今日のオペレーティングシステム（ＯＳ）において使用されるようなアプリケーション管理モデルは、実装及び保守するのに相対的に単純であるが、３つの主な領域にグループ化される複数の考慮点の悪影響を受ける。

１． アプリケーションのライフサイクル段階の間の対話の欠如 それら考慮点は全て、アプリケーションの種々のライフサイクル段階（インストール及び削除に加え、ロード、実行及び終了を含む）の間の対話が基本的に欠如していることに関する。

・アプリケーションマネージャはインストール及び削除を管理するが、それは、アプリケーションが実際に実行している時には存在しない別個のコンポーネントである。 アプリケーションのライフサイクルのこの部分が監視されないということは、オペレーティングシステム及び他の実行プログラムのセキュリティ及び完全性が損なわれる可能性があることを意味する。

・いくつかのシステム（Windows PC等）において、この問題は、別個の常駐セキュリティ監視プロセスにより部分的に管理されてもよい。 しかし、それらプロセスは、インストールプロセスの知識を有さず、アプリケーションが宣言したことに関する暗黙のインストール契約に対して、行なう可能性のあるアクションをチェックできない。

・既存のアプリケーションモデルは、ネットワークセキュリティを実装せず、基本的なファイルシステムセキュリティを有さないが、殆どのオペレーティングシステムは、任意のプログラムが種々の方法で実行されることを可能にする。 許可は、一般に暗黙的であり、実行ファイル毎ではなくユーザ毎に割り当てられる。 この例において、実行ファイルにおける悪意のあるコード又は有害なコード（有害ソフト）に気付かないユーザが自身のファイルだけでなくネットワーク上の他のコンピュータ及びある状況においてはシステムファイルを損なう可能性があるため、それは深刻な問題である。 それらセキュリティの問題については、以下に更に詳細に説明する。

アプリケーションは、実行していない間にリソースを有さず、別のアプリケーションがそのリソースを使用することを防止しない。 これは、必ずしも問題ではないが、特定のリソースが特定の信頼されたアプリケーションのために確保されるか又は特定の状態で保守されることをセキュリティの問題が要求する状況がいくつかある。 いくつかのオペレーティングシステムは制限された機能性（例えばLinuxのinetd）を提供するが、殆どのシステムにおいて、そのようなリソースを保守又は確保するために別個のプロセスが実装される必要がある。

アプリケーションマネージャがある特定のライフサイクル段階に対して制御を行なわない場合、アプリケーションマネージャは、アンインストールが現在実行中のアプリケーションについて要求される状況に対処するようにその能力を制限する。 開発者は、クラッジを使用する必要があり、例えばアプリケーションの削除を完了するためにユーザにシステムのリブートを要求する。 クラッジは、プログラミング又はハードウェア設計、あるいは実装の問題に対する不適切な又は拙劣な（しかし、少なくとも一時的には効果的な）解決策として当業者には周知である。

２． 複数のアプリケーションモデルに対するサポートの欠如 更なる問題は、ＯＳアプリケーション管理システムが種々のファイル（データファイル及び文書を含む）のインストール及び削除を可能にするにも関わらず、単一のアプリケーションモデルを重点的に扱うことである。 通常、そのファイルはネイティブ実行ファイルである。 すなわち、ホストオペレーティングシステムにより直接ロードされ且つホストオペレーティングシステムと直接対話するプログラムである。 しかし、殆どのコンピュータ装置において、サポートされる必要がある追加のアプリケーションモデルが実行ファイルについて存在する。 尚、実行ファイルは、オペレーティングシステムではなくアプリケーションを実行することによりロードされるか又はオペレーティングシステムとの対話が他の実行ファイルにより仲介されるか、あるいはその双方である。 それら追加のアプリケーションモデルの例は以下を含む：
・翻訳された実行ファイル（種々のＢＡＳＩＣにおいて見つけられるように、非特許文献１で説明されるような移動装置に対するVisual Basic Appforgeを含む）
・中間コード実行ファイル（ＰＡＳＣＡＬのｐ−ｃｏｄｅ及びＪａｖａ（登録商標）のバイトコード等）
・埋込みマクロ言語を含むアプリケーション（ＶＢＡ対応の言語を含むMicrosoft Officeアプリケーション等）
・アプリケーションを実行することによりロードされるが、アプリケーション内でネイティブに実行するアプリケーション（ブラウザに対するレンダリングプラグイン等）
・動作環境として他のアプリケーションを使用するアプリケーション（ブラウザで実行するジャバスクリプト等のインターネットスクリプトアプリケーション）
・専用のアプリケーション管理ソフトウェア（ＡＭＳ）により管理される必要があるアプリケーション（ＪａｖａのＭＩＤｌｅｔ又はQualcommのＢＲＥＷ等）
尚、上述は、非ネイティブ実行ファイルの包括的なリストとなることを意図せず、当業者には他の実行ファイルが明らかであろう。

既存のＯＳアプリケーション管理システムは、それらモデルを部分的にのみサポートできる。 それら追加のアプリケーションモデルに対する全体のサポートは、別個のアプリケーション管理システムを介して処理される必要がある。

３． 統一セキュリティ機構の欠如 この問題については、アプリケーション全体のライフサイクル段階の間の対話の欠如から起こる問題を説明した際に言及した。

既存のＯＳ管理システムに対する問題は、それらシステムがインストールの際にある形式の境界セキュリティを実装できる（例えば、無署名のアプリケーションをユーザに通知することを可能にし且つ署名済みアプリケーションに対する証明書のチェックを可能にする）が、ランタイムセキュリティとの境界セキュリティの統一がないことである。 その結果、オープンオペレーティングシステム（ユーザ又は所有者が製造後に追加のプログラムをインストールすることを可能にする）は、任意のプログラムが種々の方法で実行されることを可能にする。 一般に、ランタイムセキュリティの欠如により、リソースは、そのようなプログラムに対して公開されたファイルシステムセキュリティ及びネットワークの双方を介してアクセス可能にされる。 許可が存在する場合、それら許可は、黙示的であり且つ実行ファイル毎ではなくユーザ毎に割り当てられる。 その結果、実行ファイル中の有害ソフトに気付かないユーザは、自身のファイル、ネットワーク上の他のコンピュータ及びある状況においてはシステムファイルを損なう可能性がある。

上述の問題領域は、オペレーティングシステムレベルで実装されるアプリケーション管理システムに当てはまる。 しかし、Sun Microsystemsにより開発されたＪａｖａ技術により、多少異なる方法が使用される。

Ｊａｖａ技術は、「ネットワークの能力に基づいており、同一のソフトウェアが多くの異なる種類のシステムやデバイス上で動作する製品ポートフォリオ」（非特許文献２より）であり、Ｊ２ＭＥ（Java 2 Micro Edition）ＭＩＤＰ（Mobile Information Device Profile）のバージョン２．０は、管理されるアプリケーションの概念を紹介した。

従来のアプリケーションは、ロードされると相対的に自律的になり、主にユーザ入力に依存してライフサイクルを管理する。 しかし、管理されるアプリケーションは、常に基礎となるオペレーティングシステムの制御下にある。 オペレーティングシステムは、アプリケーションの動作を中断又は再開でき、あるいはアプリケーションを完全に強制終了できる。

コンピュータ装置にインストールされるＡＭＳに対する要求は、Ｊ２ＭＥ ＭＩＤＰ ２．０に対する特定の要求である。 Sunは、ＡＭＳを「アプリケーションの各ライフサイクル（インストール、起動、実行及び削除）を管理する装置のソフトウェア」と定義する。 Ｊ２ＭＥにおけるアプリケーション管理の簡単な概要は、４つのアプリケーションモデルを説明する非特許文献３で見つけられる。 それらモデルは、従来の管理されないアプリケーション、ウェブブラウザにより管理されるアプレット、ＭＩＤｌｅｔ及びｘｌｅｔである。 そのうち最後の２つであるＭＩＤｌｅｔ及びｘｌｅｔは、ＡＭＳにより管理される。

Ｊ２ＭＥ ＡＭＳの実装例が実際にそれら要求を実装する方法の一例については、米国のPalmのPalmOS（商標）オペレーティングシステムにおける実装例を説明する非特許文献４を参照。

基礎となるＯＳのＪａｖａ ＡＭＳによる要求は、ＯＳアプリケーション管理システムに関して上述したある特定の問題に対する部分的な解決策を提供すると考えられる。 すなわち：
・寿命が実行中のアプリケーションの寿命を超えるアプリケーション所有のＯＳレベルのリソース（プッシュ接続及び警告等）を管理する。
・アプリケーションのインストール時にＯＳレベルのリソースにより所有されるアプリケーションをインストールする。
・複数のアプリケーション開始方法（ユーザアクティビティ、接続アクティビティ及び警告アクティビティ等）を管理する。

しかし、Ｊａｖａ ＡＭＳは、２つのアプリケーションモデル（ＭＩＤｌｅｔ及びｘｌｅｔ）に対するライフサイクル全体のみを管理できる。 Ｊａｖａ ＡＭＳは、Ｊａｖａアプレット（ウェブブラウザにより管理される必要がある）又は管理されないＪａｖａアプリケーションを処理できない。 最も重要なことは、非Ｊａｖａアプリケーションが全く管理されないことである。 Ｊａｖａプリケーションが提供されたＡＭＳ外にインストールされた場合、Ｊａｖａアプリケーションは完全に監視されない可能性がある。 上述のPalmOS（商標）ＡＭＳが確認するため、Ｊａｖａ ＡＭＳは、「他の手段により装置に転送されたＭＩＤｌｅｔではなく、自身をインストールしたＭＩＤｌｅｔのみ」を認識できる。

従って、Ｊ２ＭＥ ＭＩＤＰの仕様書において説明されるＪａｖａ ＡＭＳシステムが上記問題のいくつかを部分的に軽減するが、システムはＪ２ＭＥに管理されるある特定の種類のアプリケーションのみを監視できるという致命的な欠点による悪影響を受け、また、それらアプリケーションはＪ２ＭＥ自体を介してダウンロード及びインストールされる必要がある。 ＪａｖａがオープンＯＳ上に実装される場合、ネイティブアプリケーションが管理されなくなることを許可するため、この方法は明らかに不十分である。
インターネット〈URL：http://www.appforge.com〉 インターネット〈URL：http://java.sun.com/〉 インターネット〈URL：http://sun.systemnews.com/articles/56/3/ja/7939〉 インターネット〈URL：http://www-106.ibm.com/developerworks/library/wi-amspalm/?ca=dgr-lnxw03AMS〉

従って、本発明の目的は、少なくとも以下の全てを集中管理できる方法を提供することにより、上述の問題に対する改善された解決策を提供することである。
・アプリケーションの完全なライフサイクル（インストール、ロード、全ての種々の実行状態、終了及び削除）。
・アプリケーション能力（例えば、ＭＩＭＥの種類に基づく）。
・長寿命のＯＳレベルのアプリケーション所有のリソース（例えば、特定の実行ファイルと関連付けられるプッシュ接続又はスケジュールイベント及び警告）。
・セキュリティ。

更に、方法は、全ての種類のネイティブアプリケーションだけでなく、他の管理されるサブシステム又は管理されないサブシステムに属するアプリケーションに対しても上記要求を満足できる。 サブシステムに属するアプリケーションには、Ｊａｖａアプリケーション、Ｐｅｒｌ又はＢａｓｉｃスクリプト等の翻訳されたアプリケーション、並びにQualcommのＢＲＥＷ（ワイヤレス対応バイナリランタイム環境）又はＪ２ＭＥ ＡＭＳ等のホスティングされた他のアプリケーション環境に準拠するアプリケーションが含まれるが、それらに限定されない。 それら環境は、当業者には周知であると考えられるため、本出願において更なる説明は行なわない。

本発明の第１の面によると、コンピュータ装置のユーザアプリケーションに対してアプリケーションのライフサイクルを管理する方法が提供される。 方法は、複数のアプリケーションモデル及び複数のアプリケーション環境を管理するアプリケーション管理システム（ＡＭＳ）を提供することを備え、ＡＭＳは、コンピュータ装置に対するオペレーティングシステム内のコンポーネントとして実装され、装置の全てのアプリケーション管理機能性に対する制御をオペレーティングシステムに付与する。

本発明の第２の面によると、第１の面の方法に従って動作するように構成されるコンピュータ装置が提供される。

本発明の第３の面によると、コンピュータ装置を第１の面の方法に従って動作させるためのコンピュータ装置に対するオペレーティングシステムが提供される。

次に、添付の図面を参照して更なる例として本発明の一実施形態を説明する。

以下を保守することによりアプリケーションを管理する一般的なＡＭＳ ＯＳサービスを参照して、本発明の実施形態を以下に説明する：
・インストールされたアプリケーションのレジストリ ・実行中の全てのアプリケーションの状態 ・オペレーティングシステムのリソース更に、以下に説明する方法は拡張可能である。 すなわち、追加のサブシステムがアーキテクチャに追加される。

以下に説明する好適な実装例は、Symbian Software Ltdの移動コンピュータ装置に対する高度なオペレーティングシステムであるSymbian OS（商標）オペレーティングシステムを使用して、コンピュータ装置のネイティブアプリケーション及びＪａｖａアプリケーションのために、そのような一般的なＡＭＳシステムを実装する方法を示す。 しかし、本発明が他のオペレーティングシステム及び他の種類のコンピュータ装置において実装できることは、当業者には容易に理解されるだろう。 更に、本発明において説明されるＪａｖａアプリケーションを管理する方法を開示することにより、当業者は、他の非ネイティブサブシステムに同一の方法を単独で又は組み合わせて適用する方法を認識できる。 従って、本発明の本実施形態におけるSymbian OS（商標）オペレーティングシステム及びＪａｖａの使用は、例示する目的で単独で提供されるが、本発明の応用又は範囲を限定する意図は全くない。

まず、ＡＭＳアーキテクチャの概要を提供する。 本明細書で提供される好適な実装例において、ＡＭＳサービスは、フロントエンドの「シェル」アプリケーションからバックエンドのＲＤＢＭＳ（リレーショナルデータベース管理システム）を使用するアプリケーション情報記憶装置までの機能性のいくつかの層を提供する。 ＡＭＳコンポーネントの全体的なアーキテクチャを図１に提供する。

ネイティブアプリケーション及び非ネイティブサブシステム（Ｊａｖａ仮想マシン、すなわちＪＶＭにおいて実行するＪａｖａアプリケーションにより提供される）がＣ＋＋アプリケーションプログラムインタフェース（ＡＰＩ）を提供され、ＡＰＩがＡＭＳ内のAmsListenerSupport、Installerサーバ及びExecutionサーバ等の共通の機能性へのアクセスを提供することが図１から分かる。 このＡＰＩは、ネイティブアプリケーションにより直接アクセスされることが図２から分かる。 しかし、非ネイティブサブシステムで実行するアプリケーションは、ネイティブオペレーティングシステムのメソッドにアクセスできない場合、それらアプリケーションが通信できる絶縁層（insulation layer）を提供される必要がある。 従って、図１に示す非ネイティブＪａｖａアプリケーションは、Ｊａｖａ ＡＰＩ及びＪａｖａネイティブインタフェース（ＪＮＩ）を提供することによりＡＭＳの機能性を実装する。 同様に、図１には示さないが、他の非ネイティブアプリケーション環境は絶縁層を提供する必要があるだろう。

System AMSサービスと通信するＣ＋＋ＡＰＩを図１に示す。 単一のＡＭＳサービスと通信する必要がある可能な種類のアプリケーションが多く存在するため、クライアント／サーバアーキテクチャが使用されるのが好ましい。 このアーキテクチャには、主に２つのクラスの集合が存在する。 それらは、単一インスタンスインストール／削除イベント及び手順を処理するInstallerクライアント／サーバクラス、並びにアプリケーションのロード、実行及び終了の各インスタンスと関連する複数インスタンスイベント及び手順を処理するExecutionクライアント／サーバクラスである。

イベントを通知するListenerクラスは、Installerクラス及びExecutionクラスと関連付けられる。 これを行なう正確な機構は多種多様である。 例えば、コールバック又はパブリッシュ／サブスクライブは適切な機構である。 当業者には、他の機構も明らかであろう。

ＡＭＳサービスとアプリケーションプロセスとの間のメッセージ交換は、プロセス間通信（ＩＰＣ）を使用して実行される。 ＡＭＳサービスは、以下のいくつかの方法でアプリケーションプロセスと対話する：。

・第１に、ＡＰＩはＡＭＳアプリケーション開発のために提供される。 付与されたセキュリティ許可によって、アプリケーションは、アプリケーションのインストール及び削除、インストールされたアプリケーションのリスト表示、実行中のアプリケーションのリスト表示、アプリケーション情報のクエリ、アプリケーションの実行及びクローズ、並びにアプリケーションのバックグラウンド又はフォアグラウンドへの移動を含む（しかし、これらに限定されない）タスクを実行できる。

・第２に、ＡＭＳは、管理されるアプリケーションプロセスと対話する。 管理されるアプリケーションは、ＡＭＳ ＡＰＩコール又は他のオペレーティングシステムレベルのイベントに応じて、クローズするか又は終了されるように要求されてもよい。 アプリケーションは、プッシュ接続等のオペレーティングシステムレベルのアプリケーション所有のリソースを要求又は解放してもよい。

・第３に、ＡＭＳは通知イベントを提供する。 付与されたセキュリティ許可によって、アプリケーションは、以下を含む（しかし、それらに限定されない）ライフサイクル状態の変更等のＡＭＳイベントの通知を要求できる：
・インストールされた。
・削除された。
・開始された。
・中断された。
・再開された。
・停止された。

実行を終了する（抜ける）能力を有するプログラムを残すことは別にして、ＡＭＳは、アプリケーションのライフサイクル状態の変更をトリガする唯一の手段を与える。 従って、ＡＭＳは、装置上の実行ファイルをインストール、削除及び起動する唯一の利用可能な手段である。

ＡＭＳのこのアプリケーションモデルは、非常に融通性があり且つ拡張可能である。 ＡＭＳ構成は複数の層から成る。 最上位レベルにおいて、ユーザは、インストーラ（ユーザアプリケーションを追加又は削除する）及びデスクトップ（ユーザがアプリケーションを選択し且つ開始することを可能にする）等の馴染みのあるシステムアプリケーションを介してＡＭＳと対話する。 最上位レベルの真下で、ＡＭＳは公開ＡＰＩの集合を提供し、公開ＡＰＩは、割り当てられた許可をクエリしたり、あるいは追加の許可の要求するなど、ライフサイクル状態の変更に影響を与える要求された機能性への制御されたアクセスを提供する。 最下位レベルにおいて、ＡＭＳモデルは、必要なタスクを実装するオペレーティングシステムのカーネルと対話する。 更にＡＭＳは、データ持続性のために不揮発性記憶装置へのアクセスを要求する。 この目的のため、SymbianOS（商標）オペレーティングシステムの実装例はＲＤＢＭＳのバックエンドを使用する。 そのような実装例を図１に示す。

アプリケーションモデルの好適な形態は、種々のアプリケーションモデルをサポートするのに必要なインタフェースの集合を定義する。 ＡＭＳ構成及び関連するアプリケーションプログラミングインタフェースを図２に示す。 図２に示す公開クラスは、以下に説明する実際の例において詳細にリスト表示される。 それと共に、それらクラスは、複数の異なるアプリケーションモデル（この場合、Ｊ２ＭＥ ＭＩＤＰ及びネイティブアプリケーション）を処理する公開インタフェースのオブジェクトモデルを提供する方法を実証する。

上述のように、最上位レベルの抽象は、ExecutableとInstallableとを区別する。 アプリケーション表現オブジェクト（ＡＲＯ）クラスは、既存のAppInfoクラスを拡張し且つExecutableのメソッド及びInstallableのメソッドをインプリメントすることによりコンストラクトされる。 それらは、必要に応じて対で又は単独でインプリメントされてもよい。 例として、MIDletInfoクラスの見出しがExecutableクラスのメソッドのみをインプリメントし、MIDletSuiteInfoクラスの見出しがInstallableのメソッドのみをインプリメントするが、NativeAppInfoクラスの見出しはExecutableクラス及びInstallableクラスのメソッドをインプリメントすることが図２から分かる。

Executableインタフェース及びInstallableインタフェースは、ＡＭＳが実際のインストール又は実行を行なうのに使用される専用のAppExecutorオブジェクト及びAppInstallerオブジェクトを取得することを可能にするメソッドを定義する。 通常、Executable及びInstallableの各インプリメンテーションは、対応するAppExecutor又はAppInstallerのインプリメンテーションを有する。

ListenerクラスがＡＭＳとの対話に対しても使用されることは上述した。 それらListenerクラスは、ExecutorListener及びInstallerListenerを含む。 それらインタフェースをインプリメントするクラスのオブジェクトは、Executor又はInstallerに登録され、対応する通知を取得してもよい。

プロンプト又は進捗ダイアログ等のＡＭＳの対話は、図２においてAmsUIとして示される高レベルのインタフェースに抽象化される。

尚、ＡＭＳ構成の中心の２つのクラスはExecutor及びInstallerである。 それらクラスは、ＡＭＳのタスクを定義し、登録したAppExecutorクラス及びAppInstallerクラスのメソッドに関連するインスタンスをデリゲートすることによりそれらタスクをインプリメントする。

適切なメソッドは、非ネイティブアプリケーション環境に対して定義される必要がある。 図２は、それがJavaInstallerクラス及びJavaExecutorクラスによりＪａｖａに対して行なわれる方法の一例を示す。 尚、非ネイティブアプリケーション環境は、AppInfoから適切なクラスを得る必要があり、図２は、それがＪａｖａ ＭＩＤｌｅｔに対して行なわれる方法を示す。

セキュリティに関しては、単一の中央アプリケーション管理エンティティをインプリメントすることにより、実行ファイル毎の許可の一貫したインストール時間割り当てが容易になる。 そのような方法により、英国特許出願第０３１２１９１．０号の「Secure Mobile Wireless Device」において開示されるプラットフォームセキュリティモデル等の許可（又は能力）に基づく実行モデルの採用が可能になる。

この高度に制御された環境は、従来のＡＭＳモデルとは全く異なることが当業者には理解されるだろう。

通常、許可又は能力は、アプリケーションにより提供される認証（証明書）に基づいてインストール中に割り当てられる。 許可は、ＡＭＳにより継続され、実行（ランタイム）環境に対して利用可能になる。

許可及び実施は、上述の実施形態に適用されると、Ｊ２ＭＥ ＭＩＤＰ２において、Ｊ２ＭＥ ＭＩＤＰ２のセキュリティモデルに直接対応してもよい。 ネイティブアプリケーションの場合、インストールは、アプリケーションにより必要とされる能力の検証を含んでもよい。 いずれの場合も、実行時間の許可／能力チェックは、ランタイムモデル及び関連するＡＰＩに組み込まれた機能である。

次に、本発明によるＡＭＳ構成の実装例を提供する。 以下の実装例において使用される用語は、当業者には容易に理解されるため、本出願において更なる説明は行なわない。

ＡＭＳ構成は、６つのインタフェースを備えることが図２から分かり、それらインタフェースの機能は以下の通りである。

ＡＭＳで用いられるクラスの詳細及び機能は以下の通りである。

AmsEventは、アプリケーション管理ＡＰＩとアプリケーションとの間でメッセージを受け渡すために用いられる。

アプリケーションは、典型的には、アプリケーションがインストールされたこと、或いは起動されたこと等のイベント通知を受け取るために、 Installerクラス又はExecutorクラスとともにリスナーを登録する。

AmsUIインタフェースは、ＡＭＳに要求されたクエリ、情報、警告、及びエラーメッセージの表示をアプリケーションがカスタマイズすることを可能にする。

典型的な実装は、クエリ型を調べ、オプションを追加し、ダイアログを表示することによってクエリメソッドを実装するだろう。

このインタフェースは、インストールの進展等のカスタムダイアログの提示を可能にするように拡張してもよい。

全てのアプリケーションの抽象ベースクラスとして、AppInfoは、それらがインストールされうるか実行可能かについて知ることができない。

異なるアプリケーション型のインストール及び実行は異なる方法でなされるため、そのようなタスクはアプリケーションに特有の実装したもの（implementor）に委譲される。

現在利用可能、及び実行中のアプリケーションの、開始、停止、切り替え、及びキューイングを実行可能なexecutorクラス。

ExecutorListenerインタフェースは、実行中のプロセスの外での変化をＡＭＳアプリケーションが認識できるようにするコールバック・メソッドの集合を定義する。 これの非常に単純な例は、アプリケーションがシェルから開始した後、終了したことの通知である。

最小限の、二つとない、FileSystemアクセス・インタフェースは、現在のドライブ、ディレクトリ・コンテンツ、及びロード中のファイルのリスト表示を可能にする。

installableアプリケーションに共通のインタフェース。

installerは、ＭＩＤｌｅｔ ｓｕｉｔｅとネイティブアプリケーションの両方のインストールに必要なメソッドを提供する。

このインタフェースを実装することによって、アプリケーションは、アプリケーションのインストール、更新、及びアンインストールの通知にサブスクライブすることができる。

典型的なアクションは、インストールされたアプリケーションを表示するユーザインタフェースをリフレッシュすることとなるだろう。

Downloaderインタフェースの単純な実装。

最近使用された（ＭＲＵ：most recently used）オブジェクトのキャッシュ

本発明は、アプリケーションの種類又はモデル、あるいは実行環境に関わらず、任意のアプリケーションに対して以下のことを集中管理できるオペレーティングシステムの単一メソッドを提供する手段を開示することが上記実施形態から分かる。 ：

・アプリケーションのライフサイクル（インストール、実行状態、削除を含む）。

・アプリケーション能力。

・長寿命のＯＳレベルのアプリケーション所有のリソース（例えば、プッシュ接続、警告）。

・セキュリティ。

従って、本発明は、以下を含むアプリケーション管理の周知の方法を介していくつかの利点を提供すると考えられる。 ：
・インストール、実行、終了及び削除の全ての段階を含むアプリケーションのライフサイクル全体は、単一の統一ＡＭＳエンティティから管理される。
・統一ＡＭＳは、寿命がアプリケーションの実行の寿命を超えるアプリケーション所有のＯＳレベルのリソース（プッシュ接続及び警告等）をサポートする。
・統一ＡＭＳは、任意のアプリケーションの種類に対して容易に適応され且つ拡張される。
・統一ＡＭＳは、複数の実行モデル及び複数の実行サブシステムをサポートする。
・統一ＡＭＳは、任意の新しい実行モデル及びサブシステムに対して容易に適応され且つ拡張される。
・単一のアプリケーション管理システムは、（例えば）ネイティブアプリケーション、Ｊａｖａアプリケーション、ＢＲＥＷアプリケーション及びＡｐｐｆｏｒｇｅのＶｉｓｕａｌ Ｂａｓｉｃアプリケーションを処理できる。
・ＡＭＳは、全ての種類の実行ファイルのインストール及び実行を独占するオペレーティングシステムサービスであり、システム全体にわたり共通のセキュリティポリシーを実装できる。

特定の実施形態を参照して本発明を説明したが、添付の請求の範囲により定義される本発明の範囲内である限り、変更が行なわれてもよいことは理解されるだろう。

本発明によるアプリケーション管理システム（ＡＭＳ）の全体のアーキテクチャを示す図である。

図１に示すＡＭＳに対するアプリケーションプログラムインタフェースを示す図である。