JP2006202290A - オペレーティングシステムのプリミティブとしてのアプリケーションオブジェクト - Google Patents

Abstract

【課題】アプリケーションを分析し、監視する方法を提供する。
【解決手段】アプリケーションオブジェクトを、オペレーティングシステムのプリミティブとして定義する。アプリケーションオブジェクトのＩＤプロパティが、オペレーティングシステムに関連する少なくとも１つのアプリケーションを識別し、アプリケーションオブジェクトのメタデータプロパティが、識別されたアプリケーションの挙動特性を宣言する。識別されたアプリケーションの動的状態を表すアプリケーション状態が、アプリケーションオブジェクトとアプリケーション状態の間の相互作用に関するセマンティクスを定義する。
【選択図】図１

Description

本発明の諸実施形態は、アプリケーション管理の分野に関する。本発明の諸実施形態は、詳細には、アプリケーションオブジェクトをオペレーティングシステムの第一級プリミティブ（ｆｉｒｓｔ ｃｌａｓｓ ｐｒｉｍｉｔｉｖｅ）として定義して、アプリケーションを管理しサービスするためのインフラストラクチャを提供することに関する。

従来のオペレーティングシステムは、ハードウェアを抽象化し、リソースを管理するための１組のサービスを提供する。たとえば、オペレーティングシステムは、基本的なアプリケーションプログラミングインターフェイスの指示に従って、メモリ、ファイル、ネットワーキングなどを露出させる。オペレーティングシステムは、それらのＡＰＩに共通して使用される抽象概念（ａｂｓｔｒａｃｔｉｏｎ）を一般化することによって、他者が興味深いソフトウェア製品を作成することを可能にする。

しかし、オペレーティングシステムは、関連するアプリケーションの「制御」は行わない。言い換えれば、オペレーティングシステムは一般に、ユーザセキュリティおよびシステムポリシーの限界内で、アプリケーションが望むことを何でもできるようにさせ、そのアプリケーションは、それ自体の境界をどんな点についても（たとえば、物理的な点でも挙動の点でも）オペレーティングシステムに示さない。残念なことに、制御されていない欠陥のあるアプリケーションは、オペレーティングシステムを「破壊」し、システムを非常に不安定にすることもある。そのため、ユーザが、安定した使用可能なシステムを回復させるために、オペレーティングシステムを再インストールせざるを得なくなることもある。

アプリケーションがオペレーティングシステムの規則に従わないことも、システムの不安定さを招く。規則は自由に破ることができるので、アプリケーションが、オペレーティングシステムと混在してしまうこともある。同様に、アプリケーションとオペレーティングシステムの間で設定が共用され、相互に依存しているのが一般的である。したがって、それらの設定は、バイナリファイルよりも遥かに入り組んでいることもある。言い換えれば、従来のオペレーティングシステムは、アプリケーションに多くのことをさせすぎ、オペレーティングシステムと、相対的に監視がされず制限も課されていないアプリケーションとの間の定義されていない境界を、アプリケーション単位で効果的に守らせることができない。

残念ながら、システムアプリケーションを分析して、あるバイナリがオペレーティングシステムに属するのか、それとも特定のアプリケーションに属するのかを識別する決定論的な手法はない。同様に、オペレーティングシステムとアプリケーションの状態を分離する決定論的な手法もない。これらの問題は、従来のオペレーティングシステムに意味論的分離が欠落しているために複雑となり、その結果、オペレーティングシステムまたは他のアプリケーションに影響を及ぼすこともあるアプリケーションの変化などを効果的に追跡できないことになる。これらのすべての要因が、オペレーティングシステムを管理する際の極端な複雑さを生み、したがってアップグレード、マイグレーション、バックアップ、およびローミングを妨げ、システムが不安定になる可能性を高める。

さらに、状態を分離しようと試みるソリューションは、非常に複雑で、非決定論的であり、またいくつかの様々なヒューリスティックに基づいている。従来のオペレーティングシステムのコンテキストでは、インストールされたすべてのアプリケーションを正確に識別し、それらに一意の識別子を割り当てるのは、ほぼ不可能である。同様に、オペレーティングシステムの全体を通じてＡＰＩをフックする（ｈｏｏｋ）ことによって、アプリケーションの互換性を確保しようとする試みは、煩雑で非効果的である。これらの問題を解決しようとする事後的な試みの１つとしては、ある種のオペレーティングシステムファイルを重要なファイルと指定し、次いでそれらの「重要な」ファイルが偶然にあるいはその他の原因で修正された場合には、その変更されたバイナリを復元しようと試みることが挙げられる。

上記に照らせば、アップグレード、マイグレーション、ローミングなどに対する消費者の不安を低減させる、システムアプリケーションを決定論的に分析し、監視する上での改善が望まれている。

本発明の諸実施形態は、アプリケーションをオペレーティングシステムに関連する論理オブジェクトとして定義することによって、従来技術における１つまたは複数の欠点を克服する。有利には、アプリケーションオブジェクト設計を第一級プリミティブとして確立することによって、セキュリティ、管理性、所有の総コストなどを改善するシナリオを可能にするインフラストラクチャを提供する。

たとえば、本発明の諸実施形態は、アプリケーションの状態（たとえば、その設定）を維持しながら、コンピュータ間でのアプリケーションのマイグレーションを実施する。本発明の諸態様は、異なるアプリケーションが同様の機能を有する場合に、ライセンスおよびバージョンに依存しないアプリケーションのマイグレーションを可能にし、さらには同じクラスからのアプリケーション間でのマイグレーションをも可能にする。さらに、本発明の諸実施形態は、モバイルコンピューティングおよびローミングを簡略化し、アプリケーション用の適応型セキュリティを提供する。

一実施形態では、オペレーティングシステムに関連する１つまたは複数のアプリケーションを管理する方法は、アプリケーションオブジェクトをオペレーティングシステムのプリミティブとして定義するステップを含む。この方法はまた、アプリケーションオブジェクトのＩＤプロパティを用いて、そのアプリケーションのうちの少なくとも１つを識別するステップと、アプリケーションオブジェクトのメタデータプロパティを用いて、識別されたアプリケーションの挙動特性（ｂｅｈａｖｉｏｒａｌ ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ）を宣言するステップとを含む。

本発明の諸態様を実施するコンピュータ可読媒体は、オペレーティングシステムのプリミティブであるアプリケーションオブジェクトのＩＤプロパティと、そのアプリケーションオブジェクトのメタデータプロパティとを含む。ＩＤプロパティは、オペレーティングシステムに関連する少なくとも１つのアプリケーションを識別し、メタデータプロパティは、識別されたアプリケーションの挙動特性を宣言する。コンピュータ可読媒体はまた、識別されたアプリケーションの動的状態を表す、アプリケーション状態（ａｐｐｌｉｃａｔｉｏｎ ｓｔａｔｅ）を含む。

他の実施形態では、オペレーティングシステムに関連する１つまたは複数のアプリケーションを管理する方法は、アプリケーションオブジェクトをオペレーティングシステムのプリミティブとして定義するステップと、そのアプリケーションオブジェクトのＩＤプロパティを用いて、そのアプリケーションのうちの少なくとも１つを識別するステップとを含む。この方法はまた、識別されたアプリケーションの動的状態を表すアプリケーション状態を定義するステップを含む。この例では、アプリケーション状態は、アプリケーションオブジェクトとアプリケーション状態の間の相互作用に関するセマンティクスを定義する。

アプリケーションを管理する方法を実施するためのコンピュータ実行可能な命令を含むコンピュータ可読媒体が、本発明の他の態様を実施する。

代替として、本発明の諸実施形態は、他の様々な方法および装置を含んでいてもよい。

以下では、他の特徴の一部を指摘し、明らかにする。

添付の図面の全体を通じて、対応する参照符号が、対応する部分を示している。

ここで添付の図面を参照すると、図１には、本発明の諸実施形態による例示的なアプリケーションの抽象概念が示されている。図示したように、アプリケーションオブジェクト１００は、４つのアイテムを、すなわちＩＤプロパティ１０２と、実行可能ファイル（ｅｘｅｃｕｔａｂｌｅ）／データプロパティ１０４と、メタデータプロパティ１０６と、アプリケーション状態１０８とを備える。一実施形態では、アプリケーションオブジェクト１００は、オペレーティングシステムの第一級プリミティブである（図３参照）。言い換えれば、オペレーティングシステムに関連する各アプリケーションは、論理オブジェクトとして扱われる。それによって、セキュリティ、管理性、所有の総コストなどを改善するシナリオを可能にするインフラストラクチャが提供される。

上述の通り、このオペレーティングシステムは、ハードウェアを抽象化し、リソースを管理するための１組のサービスを提供することができる。たとえば、オペレーティングシステムは、基本的なアプリケーションプログラミングインターフェイスの指示に従って、メモリ、ファイル、ネットワーキングなどを露出させる。この点に関して、オペレーティングシステムは、より複雑で厳格に構造化された抽象概念が構築される対象であるツールキットの働きをする。本発明の諸態様では、オペレーティングシステムを、アプリケーションが所在しそこで変換される環境とみなしている。すなわち、オペレーティングシステム設計は、アプリケーションのライフサイクルに焦点を当てたものである。この点から見ると、オペレーティングシステムは、単に制御されていないサービスを提供するのではなく、サービスの管理を行う。本発明の諸態様を利用するオペレーティングシステムは、引き続き一般性を提供するだけでなく、管理性や、互換性、セキュリティなどについて発生した問題を解決するための管理プロトコルも提供する。

本発明の諸実施形態に従ってオペレーティングシステムを再設定（ｒｅ−ｏｒｉｅｎｔ）すると、オペレーティングシステムのベースレベルでの比較的複雑な抽象概念がサポートされる。ここでは、基本的なオペレーティングシステムオブジェクトに関する従来の水平的な表現から、任意の階層構成を有するオペレーティングシステムの抽象概念への偏向を想定している。したがって、従来のオペレーティングシステム設計では、アプリケーションを別々の明確な実体（ｅｓｓｅｎｃｅ）として定義しない。従来のオペレーティングシステム設計では、それ自体の境界を定めることすらしない。また、従来のオペレーティングシステムのコアは、システムに対する多くの制御を有しているが、アプリケーション単位の制御は有していない。本発明は有利には、オペレーティングシステムの複雑さを低減し制御するための自然な方法を提供する。

図１では、ＩＤプロパティ１０２が、たとえばグローバルアプリケーション名前空間においてアプリケーションを一意に識別する。ＩＤプロパティ１０２は、アプリケーションオブジェクト１００に関して、たとえばグローバル一意識別子（ＧＵＩＤ）がＣＯＭオブジェクト空間に関して果たす役割と同じ役割を果たす。アプリケーションのＩＤプロパティ１０２は、比較的基本的な概念かもしれないが、それなしにはアプリケーションおよび状態ベースのシナリオの大部分（たとえばマイグレーション、ローミング、およびバックアップ）が実現可能にならないので、非常に重要である。ＩＤプロパティ１０２は、アプリケーションの抽象概念すなわちアプリケーションオブジェクト１００の様々な部分を接合する接着剤（ｇｌｕｅ）の働きをする。言い換えれば、ＩＤプロパティ１０２は、特定の状態にどのアプリケーションオブジェクト１００が関連しているのかを識別し、それによって新しい技術およびシナリオが可能になる。

この実施形態では、メタデータプロパティ１０６は、識別されたアプリケーションに関連する静的情報を含んでおり、そのアプリケーションの様々な挙動上の側面に関する宣言を提示する。たとえば、メタデータプロパティ１０６は、アプリケーションの意図の宣言、オペレーティングシステムの最小要件および最大要件、オペレーティングシステムの実際のサービスなどに関するマニフェストを提示する。同様に、実行可能ファイル／データプロパティ１０４は、静的情報を含む。この例では、実行可能ファイル／データプロパティ１０４は、識別されたアプリケーションの極めて重要な要素を、すなわちそのアプリケーションのバイナリを表す物理的な静的データを含む。一実施形態では、バイナリのサブセットが、アプリケーション実行のためのエントリポイントである。

引き続き図１について述べると、本発明の諸実施形態では、識別されたアプリケーションの動的状態（または設定）を表すアプリケーション状態１０８を定義する。この例では、アプリケーション状態１０８は、アプリケーションオブジェクト１００とアプリケーション状態１０８の間の相互作用に関するセマンティクスを定義する。もちろんこの状態または設定は、アプリケーションオブジェクト１００の存続期間中に変化することもある。アプリケーション状態１００は、状態分離（ｓｔａｔｅ ｓｅｐａｒａｔｉｏｎ）、状態オブジェクトモデル、状態の一貫性、およびオブジェクトモデル変換の概念を定義し、それによってマイグレーションや、ローミング、バックアップなどの完全なシナリオが可能になる。

さらにアプリケーションオブジェクト１００のメタデータプロパティ１０６について述べると、本発明の諸実施形態では、アプリケーションオブジェクト１００に付随する極めて重要な静的情報を、メタデータプロパティ１０６内で維持する。メタデータプロパティ１０６は、アプリケーションオブジェクト１００の諸要素と、アプリケーションオブジェクト１００の意味論的な意味（ｓｅｍａｎｔｉｃ ｍｅａｎｉｎｇ）に関するキャリアとの間の接続リンクであり、アプリケーションオブジェクト１００のすべての機能的側面およびそれ自体の挙動の管理も行う。一実施形態では、メタデータプロパティ１０６の内容が、初期アプリケーション状態１０８のテンプレートとして、たとえばアプリケーションベースのセキュリティ区域、アプリケーションの挙動宣言区域、アプリケーションプロパティ区域、アプリケーション拡張可能区域として定義される。図１は、様々なデータの中でもとりわけ、ＩＤプロパティ１０２、メタデータプロパティ１０６、アプリケーション状態１０８を含む、本発明の諸態様を実施するコンピュータ可読媒体を表している。

決定論的システムと他のシステムとの違いは、決定論的システムには、厳格な概念および法則があり、このシステムではすべての現象およびそれ自体の諸側面が、システムの能力によって制限され、そのシステムの用語で記述できるという点である。オペレーティングシステムは、決定論的システムであり、したがってそれ自体の概念および規則を有しており、そこではオペレーティングシステム内で発生するあらゆる現象を、オペレーティングシステムの能力によって制限することができ、オペレーティングシステムの用語で記述することができる。本明細書では、オペレーティングシステムの用語で記述することができるアプリケーションの挙動上の諸側面に注目している。これらの用語は、オペレーティングシステムのリソース、オペレーティングシステムのサービス（ファイル、ソケットなど）、あるいはオペレーティングシステムがネイティブでサポートする他の任意の抽象概念である。

アプリケーションは、オペレーティングシステムの法則に従う環境で相互作用する。アプリケーションの挙動上の側面は、当然ながらオペレーティングシステムの法則に従っていなければならないが、これはオペレーティングシステムの能力によって制限され、オペレーティングシステムの用語で記述することができる。オペレーティングシステムの規則および法則の詳細さのレベルは、識別されたアプリケーションにおける現在のニーズに依存する。たとえば、一般用語（ｇｅｎｅｒｉｃ ｔｅｒｍ）に関する１つの可能な定義を、オペレーティングシステムに対する異なるタイプのオブジェクトについての最小要件および最大要件（たとえば、アプリケーションＡが、１０〜５０ＭＢ ＲＡＭディスクの１０〜５０ＭＢ、およびＣＰＵの１０％を必要とする）としてもよい。

オペレーティングシステムの用語の範囲を絞り込むために、広範な側面を最小要件および最大要件によって記述することもでき、それでも識別されたアプリケーションは、何の問題もなく動作することができる。これらの用語は、概略的であるかもしれないが、依然として非常に重要である。最小要件の用語は、アプリケーションを配備しあるいは実行する際の決定を行うのに極めて重要なことがあり得る。上限の用語は、サービス拒否（Ｄｅｎｉａｌ−ｏｆ−Ｓｅｒｖｉｃｅ）の状況を回避するのに重要である。オペレーティングシステムは、これらの用語を定義し遵守させ、それによって用語の定義および実現のための完全なインフラストラクチャが提供される。

反対に、オペレーティングシステムは、オペレーティングシステムのイベントとイベントシーケンスの検証との間の時間依存性など、非常に詳細な用語を定義してもよい。

オペレーティングシステムオブジェクトに関する挙動の用語は、たとえば大容量記憶装置（容量、最小帯域幅、最大帯域幅に関する割当て量）、ネットワーキング（ファイアウォール、ＱｏＳ（サービス品質）、最大帯域幅ＭＢｐｓ）、プロセス（スレッドの数、スレッドの優先順位範囲（ｐｒｉｏｒｉｔｙ ｒａｎｇｅ）、リモートスレッド）、スケジューリング（確保されたプロセッサ使用率のパーセンテージ、優先順位）、メモリ（ワーキングセット、連続ブロックの割付けサイズ）であり得る。

オペレーティングシステムの概略的な用語と詳細な用語は、相互に排他的なものではなく、むしろ互いに相補的なものであり、大部分のアプリケーションニーズを満たすことができる簡略化されたモデルをクライアントに提供する。挙動上の諸側面は、関心のレベルに応じて概略的な用語で、あるいは詳細な用語で定義することができる。

挙動宣言の概念は、独立しており、スケジューリングの最適化、分散型のアプリケーションスケジューリング、要件に関するインストール時の形式的検証（ｉｎｓｔａｌｌ ｔｉｍｅ ｆｏｒｍａｌ ｖｅｒｉｆｉｃａｔｉｏｎ）、挙動宣言のランタイム実行（ｒｕｎｔｉｍｅ ｅｎｆｏｒｃｅｍｅｎｔ）など複数のシナリオで使用することができる。

オペレーティングシステムによって定義され、アプリケーションの挙動宣言に使用される１組の用語が、アプリケーションポリシーの基準を形成する。用語を使用することによって、アプリケーション管理のための非常にフレキシブルな基盤が作り出される。また、アプリケーションのＩＤプロパティ１０２のサポートをアプリケーション管理に加えると、アプリケーション管理は、さらにフレキシブルなものとなる。たとえば、ユーザは、ｄｏｗｎｌｏａｄ．ｃｏｍから取得したアプリケーションＡについて、それがスパイウェアであった場合に備えてそのアプリケーションのネットワーキングを無効化することも含めて、非常に厳格な規則を割り当ててもよい。別の例を挙げれば、Ａ社が、アプリケーションＢに欠陥があることを発見する。Ａ社は、その欠陥の調査中にアプリケーションＢのセキュリティポリシーを無効にし、あるいはそれを強化することもでき、それによってアプリケーションの欠陥が悪用されるのが回避されるはずであるが、その問題が解決でき、そのクライアントが修正版を入手するまでは、機能が制限されることになる。

アプリケーションオブジェクト１０８の宣言挙動によって、オペレーティングシステムが、リソースおよびサービスの衝突をそれが発生する前に予測し、アプリケーション実行における所与のどの時間での衝突も決定論的に解決することが可能になる。それによって、ネットワーキングプロトコルで使用されるサービス品質の概念を、アプリケーションオブジェクト１００の抽象概念のレベルへと一般化することも可能になる。

アプリケーション状態１０８に関して、識別されたアプリケーションおよびオペレーティングシステムの状態は、併存する傾向がある。そこでは重複が生じることもあり、一方のアプリケーションの状態が他方のアプリケーションによって変更されることもある。本発明の諸態様は、アプリケーション状態１０８を、アプリケーションオブジェクト１００およびオペレーティングシステムとは別の独立したものとして確立する。アプリケーション状態１０８は、アプリケーションオブジェクト１００の外部に存在し、その存続期間は、オペレーティングシステムおよび識別されたアプリケーション自体の存続期間とは無関係である。一実施形態では、アプリケーション状態１０８へのアクセスは、それに関連するアプリケーションを介して行われる。

一方のアプリケーションの状態は、恐らくは物理的にも他方のアプリケーションから分離される。アプリケーションは、他のアプリケーションの状態にアクセスできないはずである。オブジェクト指向設計（ｏｂｊｅｃｔ−ｏｒｉｅｎｔｅｄ ｄｅｓｉｇｎ）の場合と同様に、オブジェクトが、他のオブジェクトのメンバに直接アクセスするべきではない。アプリケーション自体は、それ自体の状態について責任を負う。アプリケーションオブジェクト１００が何らかの理由でアプリケーション状態１０８にアクセスしようとする場合、アプリケーション状態１０８は、不可分な（ｎｏｎ−ｄｉｖｉｄｉｎｇ）一体のオブジェクトとして予め定義された１組の責任（ｒｅｓｐｏｎｓｉｂｉｌｉｔｙ）を有する不透明オブジェクトとして現れるはずである。特定の状態１０８を有するアプリケーションオブジェクト１００だけが、状態１０８を変更できるようにすべきである。その理由は、状態の一貫性を維持するためである。

状態の一貫性は、アプリケーションロジックが決定してよい。アプリケーション状態１０８は、アプリケーションオブジェクト１００が使用するが所有はしない分離したエンティティとして存在すべきである。アプリケーション状態１０８の存続期間は、アプリケーションオブジェクト１００の存続期間に依存しないはずであり、したがってアプリケーション状態１０８の一貫性は、アプリケーションオブジェクト１００によってではなく、アプリケーション状態１０８自体によって決まる。すなわち、アプリケーションオブジェクト１００およびアプリケーション状態１０８は、アプリケーションオブジェクトの状態のセマンティクスにおける用語で定義された明確な相互作用コントラクトを有する。かかる技術としては、ＸＳＤにデータスキーマについての一貫性を検証するだけではなく、データ自体の一貫性をも検証する方法を加えた技術を挙げることができる。

状態の意味論的一貫性に関して、オブジェクト指向設計では、開発者は、オブジェクトを実装する場合、所与のどの時間でも確実にオブジェクトの状態が一貫しているようにし、また、かかる制御を行うために、オブジェクトの状態が、オブジェクト自体を除くいかなる物によっても変更されないようにする。オブジェクトの状態のあらゆる変化は、制御可能でなければならず、特定のオブジェクトについて予め定義された一貫性の概念に従っていなければならない。別の例では、多くのビジネスアプリケーションでは、クライアントは、データベースを直接は変更せず、むしろデータベースの整合性を制御し、アプリケーションとデータベースの間の意味論的リンクを体現するストアドプロシージャを作成し使用する。

同様に、アプリケーション状態１０８は、特定のアプリケーションオブジェクト１００についてだけ意味をなし得る個別化された（ｐｅｒｓｏｎａｌｉｚｅｄ）データオブジェクトモデルを露出する。このオブジェクトモデルは、アプリケーションオブジェクト１００とアプリケーション状態１０８の間の相互作用に関するセマンティクスおよびコントラクトを定義する。このオブジェクトモデルは、所与のどの時間でも状態の一貫性を保証する。状態１０８は、単なる記憶域ではなく、オブジェクトモデルの一貫性を保証するロジックを用いるアクティブデータベースである。

アプリケーションオブジェクト１００とアプリケーション状態１０８の間の相互作用と、オペレーティングシステムとアプリケーション状態１０８の間の相互作用は、２つの異なる作用である。オペレーティングシステムは、レジストリの場合のように値のレベルで操作するのではなく、状態１０８を不透明で一体型のデータとして扱う。この実施形態では、オペレーティングシステムおよび他のすべてのアプリケーションが必ずしも特定の状態に関するセマンティクスを理解しているわけではなく、したがって、オペレーティングシステムおよび他のすべてのアプリケーションは、状態を変更する能力がなくても、かかる状態を不透明なものとして扱うはずなので、状態１０８は、不透明である。

状態１０８は、分離されており、予め定義されたアプリケーションを除くどのエンティティからも到達不可能である。予め定義されたアプリケーションオブジェクト１００だけが、状態を変更することができるようにしてもよい。他のエンティティは、状態１０８を不透明で不可分な一体型のデータとして扱う。アプリケーションオブジェクト１００とそのアプリケーション状態１０８の間の相互作用は、状態１０８自体が定義した、意味論的に正しく一貫したデータオブジェクトモデルに基づいて起こる。状態１０８は、それが定義した用語でそれ自体の一貫性を保証する。

アプリケーション状態１０８は、アプリケーションのＩＤプロパティ１０２と、したがって同じＩＤプロパティ１０２を有するアプリケーションオブジェクト１００に関連する。というのも、特定のアプリケーション状態１０８は、他のアプリケーションにとって何ら意味論的な意味をもたないからである。

アプリケーションオブジェクト１００だけがアプリケーション状態１０８のセマンティクスを理解しており、その特定のアプリケーション状態１０８に関連するアプリケーションオブジェクト１００だけがアプリケーション状態１０８を変更することができるので、アプリケーションのＩＤプロパティ１０２とアプリケーション状態１０８との関連は、非常に重要である。他のどんなアプリケーションの状態の変化も、識別されたアプリケーションの状態１０８に影響を及ぼさない。

アプリケーション状態１０８の実装には、次のような問題がある。すなわち、アプリケーション状態スキーマのサポート、内容の一貫性検証ロジックのサポート、データオブジェクトモデルのサポート、および補助記憶装置のサポートについての問題である。

アプリケーション状態１０８を不透明オブジェクトとして扱うと、同じバージョンの同じアプリケーション同士のマイグレーションおよびローミングの実装を可能にする、多くのシナリオが可能となる。しかし、製品には多数の異なるバージョンが存在し、各バージョンには、アプリケーション状態１０８に関するそれ自体の定義がある。アプリケーション状態の点で同様の意味論的な意味をもちながらも、それらのアプリケーション状態のオブジェクトモデルは異なっている可能性が高い、文書処理アプリケーションなど同じタイプの製品に、複数のカテゴリが存在する。両方のアプリケーションが、同様の目的、および同一でないにせよ同様の特徴を有することもある。これは、各アプリケーションのアプリケーション状態１０８が同様の意味論的な意味をもち、重複することがあることを意味する。したがって、どちらのアプリケーション状態１０８でも同じ意味をもつ複数の設定（たとえば、デフォルトのフォント、デフォルトのページレイアウト、デフォルトの言語、デフォルトのカラー）が、存在することもある。しかし、ここでの問題は、それらのアプリケーションが異なるオブジェクトモデルをもち、アプリケーション状態の一貫性について異なる意味をもつ可能性が高いことである。本発明の諸実施形態は、有利には、あるバージョンから別のバージョンへの、さらには異なる製品間でのマイグレーションおよびローミングさえも可能にする。

あらゆるバージョンのアプリケーションオブジェクト１００は、アプリケーション状態１０８の厳格に定義されたオブジェクトモデルを扱い、このオブジェクトモデルは、非常に様々なセマンティクスを有している。同じアプリケーションの異なる２つのバージョンに由来するアプリケーション状態１０８オブジェクトが、あるいは異なる製品に由来するアプリケーション状態１０８オブジェクトでさえ、意味論的に重複してもよい。これによって、２つのアプリケーション状態の間に意味論的な重複がある場合に、あるアプリケーション状態１０８から別のアプリケーション状態１０８への変換を定義することが可能になる。

同様に、本発明の諸態様は特に、モバイルコンピューティングに有益である。たとえば、ユーザが、アプリケーションをモバイルドライブにインストールする。翌日、そのユーザＩが、そのアプリケーションを使用して遠隔地で文書を作成するのを望むとする。アプリケーション状態１０８を用いると、ユーザＩが、ライセンスを有効化し、ショートカットを追加し、カスタマイズ設定を変更することなどが可能になる。ユーザＩのアプリケーションがリモートマシン上に存在した痕跡がない場合でも、カスタマイズ設定は、次回の使用のために記憶されることになる。

さらに、アプリケーション状態１０８があれば、完全にモバイル型の記憶装置が、すなわち文書専用ではなく、アプリケーションがインストールされた全機能搭載型の（ｆｕｌｌ ｆｕｎｃｔｉｏｎａｌ）ドライブが可能になり、さらに良いことには、ホストオペレーティングシステム上で仮想化することができるアプリケーションを備える完全なオペレーティングシステムを含むことさえできる。

アプリケーション状態１０８の変換は、「データオブジェクトモデル」の変換を意味し、したがってここでの問題は、あるオブジェクトモデルから別のオブジェクトモデルへの変換を定義することができるかどうかである。

状態の変換、あるいはデータオブジェクトモデルの変換は、関連する２つのアプリケーション状態１０８のセマンティクスを深く理解することによって達成されるものであり、したがって一般的にオペレーティングシステムレベルで達成できるものではない。さらに、かかる部分的な意味論的マッピングは、アプリケーション状態１０８が、自己完結型であり、オブジェクトモデルにおける一貫性の制御についての定義とは無関係のオブジェクトエンティティである場合に実現可能である。アプリケーション状態１０８は、定義された１組の責任を有する一体のオブジェクトとして、異なるアプリケーション状態１０８の間での変換を記述することができる。アプリケーション状態１０８は、特定のアプリケーション状態１０８からの意味論的に正しく一貫した設定の変換を宣言することができる。変換は、非常に複雑なこともあるが、それでも、たとえばＸＭＬの変換技術および／または制限付きの組込み型．ＮＥＴコードによって、データの変換を行うことができる。

アプリケーション状態１０８の概念およびプロパティを完全に記述すれば、新たに多くの重要なシナリオが可能になる。アプリケーションオブジェクト１００およびオペレーティングシステムから状態を分離することによって、アプリケーション状態１０８の破損が回避される。データオブジェクトモデルおよび一貫性の規則によって、識別されたアプリケーションに状態データを処理する際のバグがある場合にも、状態の一貫性が維持される。状態の変換を、アプリケーションオブジェクト１００の基本的な時効消滅しない責任として追加し、そのための必要なインフラストラクチャを提供することによって、異なるバージョン間での、さらには異なる製品間でのマイグレーションやローミングなど、驚くべきシナリオが可能になる。オペレーティングシステムおよび各種ツールは、不透明オブジェクトの場合と同様にアプリケーション状態１０８を扱うことができる。状態のマイグレーションや状態のローミングなどのシナリオでは、状態を不透明オブジェクトとして扱うことができ、このことは、実装の点から見て非常に単純明快な実装方法（状態の結合と分離について、単純にコピー操作をするだけの非常に決定論的な小ロジック（ｍｉｎｏｒ ｌｏｇｉｃ））であることを意味する。

かかる手法により、それを実現するのに簡単で単純明快な方法を用いて、従来のマイグレーションにおける極端な複雑さ、不完全さ、および非決定論的な方法を克服することが可能になる。アプリケーション状態１０８のマイグレーションは、既存のスクリプトエンジンを使用して作成することが可能である。

アプリケーションベースのセキュリティの概念は、「アプリケーションがなぜ想定される以上のことをできるようにすべきなのか」という疑問から生まれた。アプリケーションベースのセキュリティの目標は、アプリケーションに対するオペレーティングシステムによる個別化されたアクセス制御および使用制御を提供することである。従来のオペレーティングシステムは、アプリケーション用のセキュリティコンテキストを、現在ログオンしている（ｃｕｒｒｅｎｔ ｌｏｇｇｅｄ）ユーザに基づいて構築する。しかし、このセキュリティコンテキストは、細分性が悪いので、しばしばアプリケーションに関する権限が不必要に高くなる。ユーザは直観的に、あるアプリケーションがオペレーティングシステムおよび／または他のアプリケーションを害することはないと信用する。従来技術と比較すると、本発明のこの実施形態は、どのような副次的作用も防止し、あるいは少なくともそれを監視する。

個別化されたセキュリティコンテキストまたはアプリケーションベースのセキュリティコンテキストには、ユーザコンテキスト、アプリケーションセキュリティ宣言、およびアプリケーションポリシーからなる三本柱（ｔｒｉｐｌｅ ａｌｌｉａｎｃｅ）がある。アプリケーションベースのセキュリティには、動的なセキュリティコンテキストのプロパティがあり、これは、単にログオンユーザごとに静的なセキュリティコンテキストではなく、各アプリケーションごとに変わり得る。アプリケーションベースのセキュリティには、セキュリティポリシーを変更することを求める動的な要求を処理し、アプリケーションの細分性に関する状況要件に適応する能力も関連する。デフォルトのアプリケーションポリシーによって、ユーザが「管理者」権限を有する場合でも、アプリケーションが何らかの形でオペレーティングシステムおよびシステム上のそれ以外の何かを害することが防止される。

セキュリティ制御の概念はその後、セキュリティコンテキストの概念およびセキュリティ宣言の概念に拡張される。セキュリティには、アクセス制御に加えて、使用制御も関連する。アクセス制御は、オペレーティングシステムオブジェクトへのアクセスを制御するシステムである。アクセス制御を用いると、オペレーティングシステムオブジェクトへのアクセスを許可し、拒否し、あるいは制限することも可能になる。しかしその一方で、アクセス制御を用いても、アプリケーションがどのようにオブジェクトを使用するのかを制御することが可能になるわけではない。

アクセス制御は、オペレーティングシステムの特定のオブジェクトにアクセスできる能力を識別されたアプリケーションに付与し、あるいは付与しない概念である。しかし、オブジェクトへのアクセスを許可した後、アクセス制御は、どのような形でもオペレーティングシステムオブジェクトの使用制御は行わない。アクセス制御は、３つの基本的なカテゴリに分けて区別することができ、現時点では大抵、ＡＣＬセキュリティの概念をその拠り所とすることができる。ＡＣＬセキュリティの概念には、たとえば、システム（権限、ユーザコンテキスト）、記憶装置へのアクセス（ファイルシステム、レジストリ、状態、ＷｉｎＦＳ）、およびネットワーキング（ソケット）がある。

多くのユーザは、自身が動作させているマシン上の管理者グループの一部であり、使用可能な管理者権限を用いてその作業の大部分を行う。カレントユーザに与えられたのと同じセキュリティ権限をサードパーティのアプリケーションに不必要に割り当てることは、避けるべきである。オペレーティングシステムは、アプリケーションにそれが必要とするよりも多くの自由を与えるべきではない。オペレーティングシステムのアプリケーションポリシーによって、不明なアプリケーションについてのセキュリティを制限することができる。アプリケーションオブジェクト１００および／またはアプリケーションポリシーが、オペレーティングシステムにそれらがネットワーキングを必要としていないことを宣言によって知らせた場合、オペレーティングシステムは、アプリケーションがネットワークアクセスを行うことができないようにすべきである。

たとえば、オペレーティングシステムは、一般的ポリシーとして、アプリケーションオブジェクト１００がそれ自体のバイナリを、あるいは他のどのアプリケーションのバイナリを変更することも許可すべきではない。システムは、ウイルスに感染した場合、アプリケーションのバイナリを変更する可能性が高い。アプリケーションは、ほとんど例外なく、実際にアプリケーションのバイナリへの書込みアクセス（ｗｒｉｔｅ ａｃｃｅｓｓ）を有する必要がある。引き続き上記の例を挙げると、Ａ社は、アプリケーションＢに欠陥があることを発見する。Ａ社は、その欠陥の調査中にアプリケーションＢのセキュリティポリシーを無効にし、あるいはアプリケーションＢのセキュリティコンテキストを強化することもでき、それによってアプリケーションの欠陥が悪用されるのが回避されるはずであるが、クライアントが修正版を入手するまでは、機能が制限されることになる。

使用制御は、オペレーティングシステムのオブジェクトの挙動に関する様々な側面の質的な制御を可能にし、オブジェクトに許可されるアクセスを追跡する概念である。アプリケーションの挙動宣言に関して上述したように、あらゆるアプリケーションは、それ自体の挙動をオペレーティングシステムが定義した用語で記述することができる。使用制御は、用語を、現セキュリティコンテキストに照らして、アプリケーションの挙動宣言に関して定義された通りに制御し検証する責任を負う。

たとえば、アプリケーションＡは、ある大容量のファイルＦに対する読取り専用のアクセス権を有する。ファイルへのアクセスが許可されると、アプリケーションＡは、集中的に途切れなくファイルＦから読取りを行い、ディスクの入出力帯域幅を著しく減少させ、ＣＰＵのパフォーマンスに影響を及ぼす。従来のオペレーティングシステムは、アプリケーションＡが帯域幅の大部分を占有するのを制限することができない。小型のアプリケーションでも、膨大な入出力を伴えば、マシンが暫くの間応答不能になることもある。したがって、オペレーティングシステムの制御を新たな品質レベルへと高めるのに役立つ使用制御の概念を、導入することが望まれている。使用制御は、オペレーティングシステムオブジェクトの様々な挙動上の側面の使用を、そのオブジェクト自体が定義した用語で制御する技術である。従来の入出力オブジェクトについては、これを割当て量概念の一般化と見ることができる。

使用制限の概念は、ファイルオブジェクトの例を用いて明確にすることができる。簡略化のために、ファイルオブジェクトが「最小帯域幅」および「最大帯域幅」の挙動用語をサポートするものと仮定する。アプリケーションの現セキュリティコンテキストは、アプリケーションの挙動宣言、アプリケーションポリシー、およびユーザコンテキストの組合せである。アプリケーションＡの現セキュリティコンテキストは、「最小帯域幅」および「最大帯域幅」の用語のいくつかの具体値ｍｉｎｂおよびｍａｘｂを有する。使用制御は、アプリケーションＡには、ファイルＦにアクセスするための「最小帯域幅」ｍｉｎｂを保証し、オペレーティングシステムには、アプリケーションＡが「最大帯域幅」ｍａｘｂを超えることはないことを保証する。また、使用制御は、オペレーティングシステムが必要とする場合、「最大帯域幅」を「最小帯域幅」まで縮小することもできる。

別の例では、アプリケーションがＣＰＵ使用率の少なくとも１０％を確保する必要がある（これはメタデータを使用してオペレーティングシステムに知らせることができる）場合、オペレーティングシステムは、そのアプリケーションが配備されるときは、それ自体のポリシーに照らしてその検証を行うことができ、そのアプリケーションが実行されるときは、現在のオペレーティングシステムの状態に照らしてその検証を行うことができる。管理者がＣＰＵの９５％をＳＱＬサーバに割振り済みであり（５％はＳＱＬ管理用アプレットなど他のアプリケーションのために確保される）、したがってアプリケーションを配備することさえも無意味である場合、かかる検査は、非常に有益である。

本発明の別の態様は、形式的検証に関するものである。アプリケーションオブジェクト１００には、可能な限り完全なさらなる意図の宣言があることが好ましい。オペレーティングシステムの責任は、特定のアプリケーションのマニフェスト（すなわち、１組の宣言）がそのオペレーティングシステムのアプリケーションポリシーに従っているかどうか形式的に検証することである。たとえば、アプリケーション「ＡＢＣ」がユーザに関するデータを会社に報告する場合、アプリケーション「ＡＢＣ」は、その特定の意図を宣言する必要があり、したがってアプリケーションポリシーに照らしてそれを形式的に検証することができ、そうでない場合はより厳格なデフォルトのポリシーが適用されることになる。

形式的検証は、本質的にオペレーティングシステムのための法則実施エンジン（ｌａｗ ｅｎｆｏｒｃｅｍｅｎｔ ｅｎｇｉｎｅ）であり、アプリケーションポリシーによって定義された法則が、アプリケーションオブジェクト１００のインストール時、および／またはアプリケーションの実行中に、アプリケーションのメタデータプロパティ１０６に基づいて実施される。これによって、問題が実際に起こる前にそれを検出し解決することが可能になる。形式的検証は、アプリケーションオブジェクト１００のインストール中に、またアプリケーションオブジェクト１００の実行前、および実行中に行うことができる。

たとえば、あるアプリケーションがＣＰＵ使用率の少なくとも１０％を確保する必要がある場合、オペレーティングシステムは、アプリケーションが配備されるときは、ポリシーに照らしてその検証を行うことができ、アプリケーションが実行されるときは、現セキュリティコンテキストに照らしてその検証を行うことができる。しかし、一方でＳＱＬサーバがＣＰＵの９５％を割り振られて走っている場合、アプリケーションを実行し、あるいは配備することさえも、あまり意味がない。リソースの割振りの衝突を、実行の前に、さらにはインストールの前でさえ検出することができる。

次に、アプリケーションポリシーおよび管理について述べると、アプリケーションオブジェクト１００のメタデータプロパティ１０６は、アプリケーションの異なる側面をオペレーティングシステムが定義した用語で記述する。かかる用語の１つのタイプを、オペレーティングシステムオブジェクトの特定の側面に対する最小要件および最大要件としてもよい。オペレーティングシステムは、オペレーティングシステムの様々な側面を定義し記述する、かかる複数の変数をもつことができる。オペレーティングシステムの性質を定義する１組の変数、概念、および規則をすべて調節しなければならない。これらの変数の値および範囲は、再計算するのが困難であり、またこれらに定数値（ｃｏｎｓｔ ｖａｌｕｅ）を割り当てるも困難なので、調節しなければならない。したがって、これらの変数を監視し、調整し、これらに関する規則を定義する、オペレーティングシステムの用語および規則の管理概念を有することが望まれている。かかる概念が、「アプリケーションポリシー」である。

たとえば、１つの規則は、アプリケーションＡがポートＢへのアクセスを閉じることでよく、アプリケーションＡ内でのある問題をそれが修正されるまで緩和するために、この規則を、ユーザが作成し、あるいはサービスによって引き渡すこともできる。

これらのポリシーは、オペレーティングシステム上でインストールされ、あるいは実行されるアプリケーションに対する最小要件を記述することができる。これらのポリシーは、アプリケーションをインストールし、あるいは実行する前に、予め定義されたリストを検査することができる。これらのポリシーは、オペレーティングシステムおよび顧客の利益のために、非常に柔軟な規則を定義し実施することができる。アプリケーションポリシーは、オペレーティングシステムが何を追跡し、制御し、監査し、検証すべきかを定義する。

憲法が自然法則は変更せず、単に社会にさらなる恩恵をもたらす理由で、社会の極めて重要な機能に追加の規則を加えるのと同じように、アプリケーションポリシーは、オペレーティングシステムの概念および法則は変更せず、オペレーティングシステムの基本値（ｂａｓｅ ｖａｌｕｅｓ）を定義する。

たとえば、管理者は、アプリケーションを使用するためにポートを１つだけ開こうとする。異なるポートを必要とするどのアプリケーションも、実行が拒否され、あるいはインスールさえも拒否されることになる。さらに、管理者は、オペレーティングシステムに、アプリケーションＡＢＣがポートＸにアクセスする度に、あるいはネットワーク／ディスクの帯域幅消費の閾値に近づく度に、その都度イベントのログをとらせようとする。

３２ビットオペレーティングシステムの１つの大きな進歩は、処理レベルでのメモリの分離である。アプリケーションレベルでのバイナリ、状態、セキュリティ、およびポリシーの分離も、１つの重要な進歩である。オペレーティングシステムに定義および強制力が存在しないことは、従来のオペレーティングシステムにおける複雑で費用のかかる諸問題の直接の結果である。この点に関連して、本発明の諸態様は、オペレーティングシステムがアプリケーションの抽象概念を、すなわちアプリケーションオブジェクト１００をその保護（ｃｏｖｅｒ）の下に置き、アプリケーションオブジェクトの抽象概念の定義およびその進歩の責任を負うことを可能にする。そのため、オペレーティングシステムが、アプリケーションの安全で制御可能な実行の責任を負うことが可能になる。

一般に、本発明の諸実施形態は、アプリケーションオブジェクト１００の抽象概念を、中核概念としてオペレーティングシステムレベルで導入する。かかる抽象概念を導入すると、アプリケーションオブジェクト１００の境界と、アプリケーション状態やセキュリティなどその主要な諸側面の概要が、明らかになる。アプリケーションセキュリティおよび状態は、従来技術における欠陥を克服するのに役立つ２つの主要なポイントである。アプリケーション状態１０８のモデルを用いると、マイグレーション、更新、ローミング、バックアップ、およびモバイルアプリケーションのシナリオのための決定論的で単純明快な方法が可能になる。柔軟なセキュリティモデルを導入すると、非常に柔軟なアプリケーション管理の基礎となる新たな概念、すなわち宣言挙動モデル、アプリケーションベースのセキュリティ、形式的検証、およびアプリケーションポリシー（すべて後述する）に基づく、安全で信用できる実行時環境が可能になる。

一体型のアプリケーションオブジェクト１００の抽象概念を用いると、新しい支援技術（たとえば、ライセンス、サービス、およびエラーレポート）によって比較的簡単に拡張を行うことが可能になる。アプリケーションオブジェクト１００の責任を拡大すると、識別されたアプリケーション自体がそれを認識していない場合でも、抽象概念の特徴が配備されるとすぐにアプリケーションに影響が及ぶ。たとえば、アプリケーションオブジェクト１００の責任の一部として一般的ライセンスがサポートされると、当然すべてのアプリケーションに影響が及ぶことになる。たとえば、ソフトウェアのレンタル企業は、販売員が特定のアプリケーションを貸し出す際にライセンスの延長を手配することによって、アプリケーションの存続期間を制御することができる。

以下で詳細に説明するように、アプリケーションの概念を統一することによって、識別されたアプリケーションのモデルを、いくつかの概念（たとえば、データオブジェクトモデル、状態の一貫性、状態の分離、および状態の変換またはオブジェクトモデルの変換）に基づいて、別々の一体型のエンティティとして定義する、アプリケーション状態１０８を導入することが可能になる。さらに、本発明の諸実施形態による宣言挙動モデルは、識別されたアプリケーションの挙動上の諸側面に関する形式的宣言を提供する。アプリケーションベースのセキュリティは、識別されたアプリケーション用の個別化されたセキュリティコンテキストである。セキュリティ制御の諸側面としては、宣言挙動モデルのための制御エンジンであるアクセス制御および使用制御が挙げられる。形式的検証には、識別されたアプリケーションの様々な挙動上の側面を、インストール前、ならびに実行前および実行中に形式的に検証することが含まれる。一実施形態では、アプリケーションポリシーは、アプリケーションのためのオペレーティングシステム環境を決定する法則を作成し管理するエンジンである。

本発明の諸態様は、アプリケーションオブジェクト１００の抽象概念を構築する次のような基本的な技術に関するものである。
・アプリケーション管理およびポリシー
・マイグレーション、ローミング、バックアップのサポート
・アプリケーションのパッケージ化および引渡し
・アプリケーションの配備

アプリケーションの配備を、オペレーティングシステムだけの特権としてもよい。アプリケーションの物理表現は一般に、実装の詳細であり、たとえばこれを、それ自体のファイル／状態の名前空間を提供し、オペレーティングシステムがアプリケーションのＩＤプロパティ１０２を再解析ポイントとしてあるいはアプリケーションリポジトリ／データベースでの配備として使用してその内部を見ることができる、単一のパッケージとしてもよい。

アプリケーションオブジェクト１００の抽象概念の責任としては、以下のものがある。
・配備／除去
・発見可能性：これによって、配備されたアプリケーションを発見し、それらに関する詳細な情報を検索することが可能になる。
・サービス可能性：あらゆるアプリケーションは当然に、それを配備するには当然のことだが、自然な形でサービス可能でなければならない。
・実行：アプリケーションは、少なくとも１つまたは複数の実行可能なエントリを有していなければならない。
・コピー／移動：アプリケーションは、移動可能でなければならない。つまり、アプリケーションをコピーすることは、その状態も含めて単にアプリケーションの別のインスタンスを配備することにすぎない。
・状態のリセット／関連付け／分離：特定のアプリケーションとの状態の関連付けおよび分離を行う能力が、マイグレーション、ローミング、バックアップ、モバイルアプリケーション、分散型の状態（Ｄｉｓｔｒｉｂｕｔｉｖｅ ｓｔａｔｅ）など次のシナリオのために非常に重要で決定的である。
・分散型の状態：この状態では、実状態の記憶域を、Ｗｅｂサービスとして提示することができ、またオペレーティングシステムが、かかる状態の記憶域をどのアプリケーションにも関連付けることができ、それによってグローバルローミングが可能になる。

あらゆるアプリケーションオブジェクト１００は当然、上記の責任を継承する。これらの責任の実現は、アプリケーションの一部として与えられるメタデータプロパティ１０６によって大抵は管理される。

本発明の１つまたは複数の実施形態では、識別されたアプリケーションは、以下の特徴を有する。
・アプリケーションオブジェクト１００の存続期間は、オペレーティングシステムの存続期間とは無関係である。（オペレーティングシステムのいかなる変更も、何らかの形でアプリケーションに影響を及ぼしてはならない。）
・アプリケーション状態１０８の存続期間は、オペレーティングシステムの存続期間およびアプリケーションオブジェクト１００の存続期間とは無関係である。
・同じ物理マシンおよび同じオペレーティングシステム上で、同じアプリケーションを重複して配備する能力がある。
・あらゆる処理が、トランザクションベースでなければならない。

たとえば、本発明の諸実施形態は、アプリケーションの状態（すなわち、その設定）を維持しながら、コンピュータ間でのアプリケーションのマイグレーションを実施する。たとえば、あるアプリケーションがシングルユーザライセンスを有する場合、ユーザは、そのライセンスをアプリケーションと共に異なるマシンに移したいと思うことがあり、あるいは少なくとも、そのアプリケーションを異なるマシン上で容易にライセンスを取得することが可能な状態にしたいと思うこともある。この例では、本発明により、アプリケーション自体ではなくオペレーティングシステムがライセンスのサポートを維持することが、可能になる。

次に図２を参照すると、オペレーティングシステムに関連するアプリケーションを管理するための例示的な処理が、流れ図によって示されている。１１２から始まり、アプリケーションオブジェクトが、オペレーティングシステムのプリミティブとして定義される。１１４で、アプリケーションオブジェクトのＩＤプロパティが、そのアプリケーションを識別する。１１６で、本発明の図示した実施形態では、アプリケーションオブジェクトのメタデータプロパティを用いて、識別されたアプリケーションの挙動特性（たとえば、大容量記憶装置、ネットワーキング、プロセス、リソースのスケジューリング、メモリ）を宣言する。アプリケーションオブジェクトのメタデータプロパティは、アプリケーションの責任を定義する。このオペレーティングシステムは、有利には、アプリケーションの宣言された挙動特性がオペレーティングシステムの要件に従っているかどうかを検証することができる。１１８で、識別されたアプリケーションの動的状態を表すアプリケーション状態が、他のアプリケーションとは無関係に定義される。この例では、アプリケーション状態は、アプリケーションオブジェクトとアプリケーション状態の間の相互作用に関するセマンティクスを定義するデータオブジェクトモデルである。そのため、本発明の諸実施形態では、１２０で、識別されたアプリケーションへのアクセスを、アプリケーション状態によって表されるその動的状態に基づいて制御することが可能になり、アクセスが許可されたとき、１２２で、識別されたアプリケーションの使用を、その宣言された挙動特性に従って制御することが可能になる。さらに、本発明の諸実施形態により、識別されたアプリケーションのアプリケーション状態に従って、アプリケーションを更新し、それをあるコンピュータから別のコンピュータにローミングし、そのバックアップを取り、それをリモートコンピュータ上で実行することなどが可能になる。１２４で、アプリケーションオブジェクトの実行可能ファイル／プロパティ（ｅｘｅｃｕｔａｂｌｅｓ ｐｒｏｐｅｒｔｙ）を用いて、アプリケーション実行のためのエントリポイントが、定義される。本発明の一実施形態では、実行可能ファイル／プロパティは、識別されたアプリケーションの１つまたは複数のバイナリを表す静的データを含む。

図３には、コンピュータ１３０の形での汎用コンピューティング装置の一例を示してある。本発明の一実施形態では、コンピュータ１３０などのコンピュータは、本明細書において例示し説明したその他の各図で使用するのにも適している。コンピュータ１３０は、１つまたは複数のプロセッサまたは処理ユニット１３２、およびシステムメモリ１３４を有する。例示した実施形態では、システムバス１３６が、システムメモリ１３４を含めて様々なシステムコンポーネントをプロセッサ１３２に結合する。バス１３６は、メモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート、および様々なバスアーキテクチャのいずれかを使用するプロセッサバスまたはローカルバスを含めていくつかのタイプのバス構造のうちの１つまたは複数の任意のバス構造を表す。限定ではなく例を挙げると、かかるアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスがある。

コンピュータ１３０は通常、少なくとも何らかの形のコンピュータ可読媒体を有する。コンピュータ可読媒体には、揮発性および不揮発性の媒体と、取外し可能（ｒｅｍｏｖａｂｌｅ）および固定の（ｎｏｎ−ｒｅｍｏｖａｂｌｅ）媒体の両方があり、これは、コンピュータ１３０がアクセスできる任意の利用可能な媒体でよい。限定ではなく例を挙げると、コンピュータ可読媒体は、コンピュータ記憶媒体、および通信媒体を備える。コンピュータ記憶媒体としては、コンピュータ読取り可能な命令や、データ構造、プログラムモジュール、他のデータなどの情報を記憶するための、任意の方法または技術で実装される、揮発性および不揮発性の、取外し可能および固定の媒体が挙げられる。たとえば、コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ：デジタル多用途ディスク）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは所望の情報を記憶するのに使用でき、コンピュータ１３０がアクセスできる他の任意の媒体がある。通信媒体は通常、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、または他のデータを搬送波や他の移送メカニズムなど変調データ信号の形で実施し、任意の情報送達媒体を含んでいる。当業者は、その特徴の１つまたは複数がその信号内の情報を符号化するようなやり方で設定されまたは変更されるこの変調データ信号を熟知している。通信媒体の例としては、有線ネットワークや直接有線接続（ｄｉｒｅｃｔ−ｗｉｒｅｄ ｃｏｎｎｅｃｔｉｏｎ）などの有線媒体、ならびに音響（ａｃｏｕｓｔｉｃ）、ＲＦ、赤外線、他の無線媒体などの無線媒体がある。上記の任意の組合せも、コンピュータ可読媒体の範囲に含まれる。

システムメモリ１３４は、取外し可能および／または固定の、揮発性および／不揮発性のメモリの形のコンピュータ記憶媒体を含む。例示の実施形態では、システムメモリ１３４は、読出し専用メモリ（ＲＯＭ）１３８、およびランダムアクセスメモリ（ＲＡＭ）１４０を含んでいる。通常、起動時などにコンピュータ１３０内の要素間で情報を転送するのに役立つ基本的なルーチンを含む基本入出力システム（ＢＩＯＳ）１４２が、ＲＯＭ１３８に格納される。ＲＡＭ１４０は通常、処理ユニット１３２が容易にアクセスでき、そして／または現在実行しているデータおよび／またはプログラムモジュールを含む。限定ではなく例示のため、図３には、オペレーティングシステム１４４、アプリケーションプログラム１４６、他のプログラムモジュール１４８、およびプログラムデータ１５０を示してある。

コンピュータ１３０は、他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体も含んでよい。たとえば、図３には、固定の不揮発性磁気媒体への読み書きを行うハードディスクドライブ１５４を示してある。図３には、取外し可能な不揮発性磁気ディスク１５８への読み書きを行う磁気ディスクドライブ１５６、およびＣＤ−ＲＯＭや他の光媒体など取外し可能な不揮発性光ディスク１６２への読み書きを行う光ディスクドライブ１６０も示してある。この例示的な処理環境で使用できる他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体としては、それだけに限らないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが挙げられる。ハードディスクドライブ１５４、磁気ディスクドライブ１５６、および光ディスクドライブ１６０は通常、インターフェイス１６６などの不揮発性メモリインターフェイスによってシステムバス１３６と接続される。

上述の図３に示したドライブまたは他の大容量記憶装置およびそれに関連するコンピュータ記憶媒体は、コンピュータ１３０のコンピュータ読取り可能な命令、データ構造、プログラムモジュール、および他のデータの記憶を行う。たとえば図３では、ハードディスクドライブ１５４が、オペレーティングシステム１７０、アプリケーションプログラム１７２、他のプログラムモジュール１７４、およびプログラムデータ１７６を記憶するドライブとして示されている。これらのコンポーネントは、オペレーティングシステム１４４、アプリケーションプログラム１４６、他のプログラムモジュール１４８、およびプログラムデータ１５０と同じでもあるいは異なっていてもよいことに留意されたい。オペレーティングシステム１７０、アプリケーションプログラム１７２、他のプログラムモジュール１７４、およびプログラムデータ１７６には、本明細書で少なくともそれらが異なるコピーであることを示すために、異なる番号が付されている。

ユーザは、キーボード１８０やポインティング装置１８２（たとえば、マウス、トラックボール、ペン、タッチパッド）などの入力装置またはユーザインターフェイス選択装置を介して、コマンドおよび情報をコンピュータ１３０に入力することができる。他の入力装置（図示せず）としては、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを挙げることができる。これらおよび他の入力装置は、システムバス１３６に結合されているユーザ入力インターフェイス１８４を介して処理ユニット１３２と接続されるが、パラレルポートや、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインターフェイスおよびバス構造によって接続することもできる。モニタ１８８または他のタイプの表示装置も、ビデオインターフェイス１９０などのインターフェイスを介してシステムバス１３６と接続されている。コンピュータ１３０は、しばしばモニタ１８８に加えて、出力周辺インターフェイス（図示せず）を介して接続できるプリンタやスピーカなど他の周辺出力装置（図示せず）も含む。

コンピュータ１３０は、リモートコンピュータ１９４など１つまたは複数のリモートコンピュータへの論理接続を使用するネットワーク環境で動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の共通ネットワークノードでもよく、通常、コンピュータ１３０に関する上述の諸要素の大部分または全部を含む。図３に示した論理接続は、構内ネットワーク（ＬＡＮ）１９６、および広域ネットワーク（ＷＡＮ）１９８を含んでいるが、他のネットワークも含むことができる。ＬＡＮ１３６および／またはＷＡＮ１３８は、有線ネットワークや、無線ネットワーク、それらの組合せなどでよい。かかるネットワーキング環境は、オフィス、企業規模コンピュータネットワーク、イントラネット、およびグローバルコンピュータネットワーク（たとえば、インターネット）においてごく一般的である。

コンピュータ１３０は、構内ネットワーキング環境で使用される場合、ネットワークインターフェイスまたはアダプタ１８６を介してＬＡＮ１９６と接続される。コンピュータ１３０は通常、広域ネットワーキング環境で使用される場合、モデム１７８、またはインターネットなどのＷＡＮ１９８上での通信を確立する他の手段を含む。モデム１７８は、内部モデムでも外部モデムでもよく、ユーザ入力インターフェイス１８４または他の適当なメカニズムを用いてシステムバス１３６と接続される。ネットワーク環境では、コンピュータ１３０に関して示したプログラムモジュールまたはその一部分を、リモートメモリ記憶装置（図示せず）に記憶することができる。限定ではなく例示のため、図３には、リモートアプリケーションプログラム１９２をリモートメモリ装置上に常駐するプログラムとして示してある。図示したネットワーク接続は、例示的な接続であり、コンピュータ間の接続リンクを確立する他の手段を使用することもできる。

一般に、コンピュータ１３０のデータ処理装置は、様々な時間にコンピュータ１３０の様々なコンピュータ読取り可能な記憶媒体に記憶される命令手段によってプログラムされる。プログラムおよびオペレーティングシステムは通常、たとえばフロッピー（登録商標）ディスクやＣＤ−ＲＯＭ上に分散されている。これらのプログラムは、そうした媒体からコンピュータの補助記憶装置にインストールまたはロードされる。実行時は、これらのプログラムが、少なくとも部分的にはコンピュータの電子式の主記憶装置にロードされる。本明細書に記載した本発明の諸実施形態は、マイクロプロセッサまたは他のデータ処理装置に関して後述する諸ステップを実装するための命令またはプログラムを含む場合の、これらおよび他の様々なタイプのコンピュータ読取り可能な記憶媒体を含む。本発明の一実施形態はまた、本明細書に記載した方法および技術に従ってプログラムされた場合の、コンピュータ自体も含む。

本明細書では例示のため、プログラムおよびオペレーティングシステムなど他の実行可能なプログラムコンポーネントを離散的なブロックとして示す。ただし、かかるプログラムおよびコンポーネントは、様々な時間にコンピュータの様々な記憶装置コンポーネント内に所在し、コンピュータの１つ（または複数）のデータ処理装置によって実行されることを理解されたい。

コンピュータ１３０を含む例示的なコンピューティングシステム環境に関して説明してきたが、本発明の一実施形態は、他の多くの汎用または専用のコンピューティングシステム環境または構成でも動作可能である。このコンピューティングシステム環境は、本発明の諸実施形態の使用範囲または機能についての何らかの限定を示唆するものではない。さらに、このコンピューティングシステム環境は、例示的な処理環境に示したコンポーネントのうちの任意の１つまたはそれらの組合せに関して、何らかの依存性または要件を有するものと解釈されるべきではない。本発明の諸実施形態と一緒に使用するのに適し得る、よく知られているコンピューティングシステム、環境、および／または構成の例としては、それだけに限らないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド型またはラップトップ型装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブルな大衆消費電子製品（ｃｏｎｓｕｍｅｒ ｅｌｅｃｔｒｏｎｉｃｓ）、携帯電話、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが挙げられる。

本発明の諸実施形態を、１つまたは複数のコンピュータあるいは他の装置によって実行されるプログラムモジュールなどのコンピュータ実行可能な命令の一般的なコンテキストで説明することもできる。一般に、プログラムモジュールとしては、それだけに限らないが、特定のタスクを実行し、あるいは特定の抽象データ型を実装した、ルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造が挙げられる。本発明の諸実施形態を、通信ネットワークを介してリンクされるリモート処理装置によってタスクが実行される、分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリ記憶装置を含めてローカルとリモートの両方のコンピュータ記憶媒体上に置くことができる。

ソフトウェアアーキテクチャのコンテキストでのインターフェイスには、ソフトウェアモジュール、コンポーネント、コード部分、あるいは他のコンピュータ実行可能な命令シーケンスがある。インターフェイスは、たとえば、第１のモジュールに代わってコンピューティングタスクを実行する第２のモジュールにアクセスする第１のモジュールを含む。一例では、第１および第２のモジュールとして、オペレーティングシステムによって提供されるようなアプリケーションプログラミングインターフェイス（ＡＰＩ）、（たとえば、ピアツーピアのアプリケーション間通信用の）ＣＯＭ（コンポーネントオブジェクトモデル）インターフェイス、および（たとえば、Ｗｅｂサービス間での通信用の）ＸＭＩ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ ｍｅｔａｄａｔａ ｉｎｔｅｒｃｈａｎｇｅ ｆｏｒｍａｔ：ＸＭＬメタデータ交換形式）インターフェイスがある。

インターフェイスは、Ｊａｖａ（登録商標）２ Ｐｌａｔｆｏｒｍ，Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）、ＣＯＭ、分散ＣＯＭ（ＤＣＯＭ）の例におけるような、密結合の同期実装でもよい。その代わりにあるいはそれに加えて、インターフェイスは、（たとえば、簡易オブジェクトアクセスプロトコル（ｓｉｍｐｌｅ ｏｂｊｅｃｔ ａｃｃｅｓｓ ｐｒｏｔｏｃｏｌ）を使用する）Ｗｅｂサービスにおけるような、疎結合の非同期実装でもよい。一般に、インターフェイスは、次の特徴、すなわち密結合、疎結合、同期、および非同期という特徴の任意の組合せを含む。さらに、インターフェイスは、標準プロトコル、独自（ｐｒｏｐｒｉｅｔａｒｙ）プロトコル、あるいは標準および独自プロトコルの任意の組合せに準拠したものでもよい。

本明細書において説明したインターフェイスはすべて、単一のインターフェイスの一部でよく、また別々のインターフェイスあるいはその任意の組合せとして実装されてもよい。その機能を実現するために、インターフェイスをローカルで実行してもリモートで実行してもよい。さらに、インターフェイスは、本明細書において例示または説明した機能よりも多くの機能あるいは少ない機能を含んでもよい。

動作においては、コンピュータ１３０は、本明細書において説明した命令などのコンピュータ実行可能な命令を実行して、アプリケーションオブジェクト１００をオペレーティングシステムのプリミティブとして定義することによって、オペレーティングシステム１４４、１７０に関連するアプリケーションを管理する。アプリケーションオブジェクト１００のＩＤプロパティ１０２は、オペレーティングシステムに関連する少なくとも１つのアプリケーションを識別し、アプリケーションオブジェクト１００のメタデータプロパティ１０６プロパティは、識別されたアプリケーションの挙動特性を宣言する。識別されたアプリケーションの動的状態を表すアプリケーション状態は、アプリケーションオブジェクト１００とアプリケーション状態の間の相互作用に関するセマンティクスを定義する。

本明細書において例示または説明する方法の実行または実施の順序は、別段の指定がない限り、本質的なものではない。すなわち、本願の発明者らは、この方法の諸要素は別段の指定がない限り、任意の順序で実施してもよく、またこの方法は本明細書において開示される要素よりも多くのあるいは少ない要素を含んでもよいことを企図している。たとえば、ある特定の要素を別の要素よりも先に、あるいは同時に、あるいは後に実行しまた実施することが本発明の範囲内であることを企図している。

本発明の諸要素または諸実施形態を導入する場合、「ａ」、「ａｎ」、「ｔｈｅ」、および「ｓａｉｄ」という冠詞は、その要素が１つまたは複数存在することを意味するものとする。「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、および「有する（ｈａｖｉｎｇ）」という用語は、包含的なものであり、列挙した要素以外の追加の要素が存在し得ることを意味するものとする。

上記に鑑みれば、本発明のいくつかの目的が達成され、他の有利な結果が得られることが理解されるであろう。

上記の構成および方法には、本発明の諸実施形態の範囲を逸脱することなく様々な変更を加えることができるので、上記の説明に含まれ、添付の図面に示されるすべての事項は、限定的な意味でなく、例示的なものと解釈されるべきものとする。

本発明の一実施形態による、例示的なアプリケーションの抽象概念を示すブロック図である。 本発明の一実施形態による、オペレーティングシステム用のアプリケーションを管理するための例示的なプロセスの流れを示す流れ図である。 本発明の一実施形態を実装することができる適当なコンピューティングシステム環境の、例示的な一実施形態を示すブロック図である。

符号の説明

１００ アプリケーション
１０２ ＩＤ
１０４ バイナリ／データ
１０６ メタデータ
１０８ 状態
１３２ 処理ユニット
１３４ システムメモリ
１３６ システムバス
１４４ オペレーティングシステム
１４６ アプリケーションプログラム
１４８ 他のプログラムモジュール
１５０ プログラムデータ
１６６ 不揮発性メモリインターフェイス
１７０ オペレーティングシステム
１７２ アプリケーションプログラム
１７４ 他のプログラムモジュール
１７６ プログラムデータ
１８４ ユーザ入力インターフェイス
１８６ ネットワークインターフェイス
１９０ ビデオインターフェイス
１９２ リモートアプリケーションプログラム
１９６ 構内ネットワーク
１９８ 広域ネットワーク

Claims (20)

1. オペレーティングシステムに関連する１つまたは複数のアプリケーションを管理する方法であって、
   アプリケーションオブジェクトを前記オペレーティングシステムのプリミティブとして定義するステップと、
   前記アプリケーションオブジェクトのＩＤプロパティを用いて、前記アプリケーションのうちの少なくとも１つを識別するステップと、
   前記アプリケーションオブジェクトのメタデータプロパティを用いて、識別された前記アプリケーションの挙動特性を宣言するステップと
   を含むことを特徴とする方法。
2. 識別された前記アプリケーションの動的状態を表すアプリケーション状態を定義するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記アプリケーション状態は、前記アプリケーションオブジェクトと前記アプリケーション状態の間の相互作用に関するセマンティクスを定義するデータオブジェクトモデルを備えることを特徴とする請求項２に記載の方法。
4. 識別された前記アプリケーションの前記アプリケーション状態を定義する前記ステップは、識別された前記アプリケーションの前記アプリケーション状態を他のアプリケーションとは無関係に定義するステップを含むことを特徴とする請求項２に記載の方法。
5. 識別された前記アプリケーションへのアクセスを、前記アプリケーション状態によって表されるその前記動的状態に基づいて制御するステップをさらに含むことを特徴とする請求項２に記載の方法。
6. アクセスが許可されたとき、識別された前記アプリケーションの使用を、識別された前記アプリケーションの宣言された前記挙動特性に従って制御するステップをさらに含むことを特徴とする請求項５に記載の方法。
7. 識別された前記アプリケーションの前記アプリケーション状態を、別のアプリケーションのアプリケーション状態へと変換するステップをさらに含むことを特徴とする請求項２に記載の方法。
8. 識別された前記アプリケーションの前記アプリケーション状態に従って、下記のステップ、すなわち前記アプリケーションを更新するステップと、前記アプリケーションをあるコンピュータから別のコンピュータにローミングするステップと、前記アプリケーションのバックアップを取るステップと、前記アプリケーションをリモートコンピュータ上で実行するステップとのうちの１つまたは複数のステップを実施するステップをさらに含むことを特徴とする請求項２に記載の方法。
9. 前記オペレーティングシステムにより、識別された前記アプリケーションの宣言された前記挙動特性がオペレーティングシステムの要件に従っているかどうかを検証するステップをさらに含むことを特徴とする請求項１に記載の方法。
10. 前記アプリケーションオブジェクトの前記メタデータプロパティは、識別された前記アプリケーションを前記オペレーティングシステム上で実行するための要件を定義する１つまたは複数のアプリケーションポリシーを指定することを特徴とする請求項１に記載の方法。
11. 前記アプリケーションオブジェクトの実行可能ファイル／プロパティを用いて、識別された前記アプリケーションの実行のためのエントリポイントを定義するステップをさらに含み、前記実行可能ファイル／プロパティが、識別された前記アプリケーションの１つまたは複数のバイナリを表す静的データを含むことを特徴とする請求項１に記載の方法。
12. 前記アプリケーションオブジェクトの前記メタデータプロパティを用いて、識別された前記アプリケーションの責任を定義するステップをさらに含むことを特徴とする請求項１に記載の方法。
13. 識別された前記アプリケーションの宣言された前記挙動特性は、下記の特徴、すなわち大容量記憶装置、ネットワーキング、プロセス、リソースのスケジューリング、およびメモリのうちの１つまたは複数の特徴を含むことを特徴とする請求項１に記載の方法。
14. １つまたは複数のコンピュータ可読媒体は、請求項１に記載の方法を実施するためのコンピュータ実行可能な命令を含むことを特徴とする請求項１に記載の方法。
15. データ構造がそれに記憶されている１つまたは複数のコンピュータ可読媒体であって、
    アプリケーションオブジェクトのＩＤプロパティであって、前記アプリケーションオブジェクトは、オペレーティングシステムのプリミティブであり、前記ＩＤプロパティは、前記オペレーティングシステムに関連する少なくとも１つのアプリケーションを識別するＩＤプロパティと、
    前記アプリケーションオブジェクトのメタデータプロパティであって、識別された前記アプリケーションの挙動特性を宣言するメタデータプロパティと、
    識別された前記アプリケーションの動的状態を表すアプリケーション状態と
    を備えることを特徴とするコンピュータ可読媒体。
16. 識別された前記アプリケーションの実行のためのエントリポイントを定義する前記アプリケーションオブジェクトの実行可能ファイル／プロパティをさらに備えることを特徴とする請求項１５に記載のコンピュータ可読媒体。
17. 前記実行可能ファイル／プロパティは、識別された前記アプリケーションの１つまたは複数のバイナリを表す静的データを含むことを特徴とする請求項１６に記載のコンピュータ可読媒体。
18. 前記アプリケーションオブジェクトの前記メタデータプロパティは、識別された前記アプリケーションの責任を定義するデータを含むことを特徴とする請求項１５に記載のコンピュータ可読媒体。
19. オペレーティングシステムに関連する１つまたは複数のアプリケーションを管理する方法であって、
    アプリケーションオブジェクトを前記オペレーティングシステムのプリミティブとして定義するステップと、
    前記アプリケーションオブジェクトのＩＤプロパティを用いて、前記アプリケーションのうちの少なくとも１つを識別するステップと、
    識別された前記アプリケーションの動的状態を表すアプリケーション状態を定義するステップとを含み、前記アプリケーション状態が、前記アプリケーションオブジェクトと前記アプリケーション状態の間の相互作用に関するセマンティクスを定義することを特徴とする方法。
20. 前記アプリケーションオブジェクトのメタデータプロパティを用いて、識別された前記アプリケーションの挙動特性を宣言するステップをさらに含むことを特徴とする請求項１９に記載の方法。
    

Images