JP2011529607A - アプリケーション変更に対する状態分離 - Google Patents

Abstract

アプリケーションが使用される種々のコンテキストを定義するポリシーを使用して、アプリケーション状態を格納し、および検索する。アプリケーション状態によって、他のアプリケーションとの接続および相互作用を含む、アプリケーションの構成または用途を定義することができる。仮想化されたアプリケーションは、使用コンテキスト内で定義される状態を有し、および複数の状態または構成を使用コンテキストに基づいて格納し、および呼び出す。ポリシーによって、コンテキストおよび保存されるべきパラメータを定義し、およびアプリケーションが仮想的な方法で動作するときにポリシーを適用する。

Description

本発明はアプリケーション変更に対する状態分離（ｓｔａｔｅ ｓｅｐａｒａｔｉｏｎ）に関する。

アプリケーションは多くの異なる方法で変更することができる。いくつかの場合、レジストリを更新することや、構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）ファイルを変更することや、ダイナミックリンクされたライブラリを更新することや、または他のメカニズムによってアプリケーションを変更することができる。アプリケーションに対する各変更は、オペレーティングシステムのいくつかの部分に影響を及ぼすかもしれず、そのことがオペレーティングシステム環境で実行する他のアプリケーションにも影響を与えるかもしれない。

アプリケーションが使用されている種々のコンテキスト（ｃｏｎｔｅｘｔ）を定義するポリシーを使用して、アプリケーション状態を格納し、および検索することができる。アプリケーション状態によって、他のアプリケーションとの接続および相互作用を含む、アプリケーションの構成または用途を定義することができる。仮想化されたアプリケーションは、使用コンテキスト内と、使用コンテキストに基づいて格納され且つリコールされ得る複数の状態又は構成内で定義される状態を持つことができる。ポリシーは、コンテキストおよび保存されるべきパラメータを定義することができ、およびアプリケーションが仮想的な方法で操作されているときに利用することができる。

この概要は、詳細な説明で以下さらに述べる概念の選択を簡単な形態で導入するために提供される。この概要は請求項のキーとなる特徴すなわち主題の必須な特徴を識別するよう意図されておらず、請求項の主題の範囲を限定するように意図されてもいない。

アプリケーションのコンテキストに基づいて異なる構成を格納するシステムの一実施形態を示す図である。 異なるコンテキスト構成で動作する方法の一実施形態を示すフローチャート図である。

アプリケーションは異なる状態又は構成において動作することができる。そのような１つのメカニズムはアプリケーションの仮想化を通して存在する。アプリケーションが特定のコンテキストに対して構成されるとき、構成情報は保存され、後の使用のために呼び出されるであろう。アプリケーションは、多くの異なる状態において動作するよう構成することができ、一組のポリシーが構成を管理する。

アプリケーションが実行される状態は、オペレーティングシステム構成、種々の他のアプリケーションの存在および動作、ネットワーク又は他の接続を通じてアクセスされるサービスの構成、および多くの他の要素を含むことができる。構成及びアプリケーションの動作は、異なる状態に対して異なっていてもよい。

例えば、いくつかのアプリケーションは、他のアプリケーションと共生関係を持っていてもよい。アプリケーションそれ自体の挙動やパフォーマンスは、他の一体をなすアプリケーションを含めたアプリケーションの挙動やパフォーマンスとは異なるかもしれない。そのような例では、構成は、単独動作の状態でのアプリケーションに対して定義され、第２の共生アプリケーションが存在し、かつ動作する場合に、別個の構成をアプリケーションについて定義することができる。

典型的な実施形態において、アプリケーションは仮想的環境で操作されるかもしれない。仮想的環境は特定のコンテキストに基づいて構成設定の異なるセットを受け入れることができるようにしてもよい。いくつかの場合、仮想環境は仮想マシン環境であってもよい。他の場合では、仮想環境は仮想アプリケーション環境であってもよい。

この明細書および請求項において、アプリケーション構成は、アプリケーションがセットアップ又は構成される方法を指している。アプリケーション構成は変更され、または設定される要素を含んでおり、は他のアプリケーションのパフォーマンス、機能、ルック（ｌｏｏｋ）又オペレーショナル特性に影響を与える要素を含んでいる。

この明細書および請求項において、アプリケーション状態は、アプリケーションが実行されるコンテキストを指す。アプリケーション状態はオペレーティングシステム、およびオペレーションシステムまたはインストールもしくは実行中のアプリケーションの設定または構成を含むことができる。アプリケーション状態は、ハードウェアコンポーネント、ネットワークを通じて利用可能なサービス、他の実行中のアプリケーション、周辺機器およびいかなる他のアイテムを含む、アプリケーションと相互作用するいかなる他の要素の条件および構成を含むことができる。

この明細書および請求項において、アプリケーションコンテキストはアプリケーション状態のひとつのカテゴリであり得る。アプリケーション状態はアプリケーションに影響し得る任意の変数を含むが、コンテキストは、構成を分類及び保存するために使用され得る広範な（ｂｒｏａｄ：大まかな）カテゴリであり得る。例えば、コンテキストを、セッション、仮想アプリケーション環境、仮想マシン環境、ユーザ特定のコンテキスト、マシン特定のコンテキスト、ユーザグループまたはマシングループ特定のコンテキスト、２つまたは３つ以上の相互作用するアプリケーションが相互に動作するコンテキスト、および他のコンテキストに対して定義してもよい。

この明細書全体に亘って、同様の参照番号は図面の記述にわたって同じ要素を示している。

要素が「接続される」又は「結合される」と称される場合、要素は直接的に接続又は結合されることができ、あるいは１つまたは２つ以上の仲介要素もまた存在し得る。これと対比して、要素が「直接的に接続される」又は「直接的に結合される」と称される場合には、仲介要素は存在しない。

主題は、装置、システム、方法、及び／又はコンピュータプログラム製品として具現化できる。従って、いくつかの又は全ての主題は、ハードウェア及び／又はソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコード、状態マシン、ゲートアレイなどを含む）として具現化されるであろう。さらに、主題は、命令実行システムによって使用され、または関連するコンピュータで使用可能なまたはコンピュータで読み取り可能な媒体に具現化されたコンピュータで使用可能なまたはコンピュータで読み取り可能なプログラムコードを有するコンピュータで使用可能なまたはコンピュータで読み取り可能な記憶媒体上のコンピュータプログラム製品の形態としてもよい。この文書の文脈では、コンピュータで利用可能なまたはコンピュータ読み取り可能な媒体は、命令実行システム、装置、又はデバイスによって使用され、またはそれに関連するプログラムを含み、格納し、通信し、伝播し、伝送することができるいかなる媒体であってもよい。

コンピュータで使用可能なまたはコンピュータで読み取り可能な媒体は、例えば、電気的、磁気的、光学的、電磁気的、赤外線の、又は半導体の、システム、装置、デバイス、又は伝播媒体としてよいが、これらに限定されない。限定ではなく、一例として、コンピュータで読み取り可能な媒体はコンピュータ記憶媒体および通信媒体を含み得る。

コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール又は他のデータのような情報を格納するための方法又は技術において実現される、揮発性又は不揮発性、取り外し可能又は取り外し不可能な媒体を含んでいる。コンピュータ記憶媒体は、命令実行システムによってアクセス可能な所望の情報を格納するために使用されることができる、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤまたは他の光学的ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ又は他の磁気ストレージデバイスまたは他の媒体を含む。たとえば、紙または他の媒体を光学的にスキャンすることによってプログラムを電子的に入力し、ついでコンパイルし、解釈し、さもなければ、必要であれば、適当な方法で処理し、ついでコンピュータメモリに格納するようにできるので、コンピュータで使用可能なまたはコンピュータで読み取り可能な媒体は、プログラムが印刷された紙または他の適当な媒体であり得ることに注意されたい。

通信媒体は、典型的には、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、または搬送波もしくは他の移送メカニズムのような変調されたデータ信号における他のデータを具体例として含み、任意の情報伝達媒体を含む。「変調されたデータ信号」との用語は、信号中の情報をエンコードするようにセットされ、または変化する特徴を１つまたは２つ以上有する信号を意味する。限定でなく一例として、通信媒体は、有線のネットワーク、又は直接の有線接続のような有線の媒体及び、音響、ＲＦ、赤外線、及び他の無線媒体などの無線の媒体を含む。上記の何れの組み合わせも、コンピュータ読み取り可能な媒体の範囲に含まれる。

主題がコンピュータで実行可能な命令の一般的なコンテキストで実現される場合、実施形態は、１つまたは２つ以上のシステム、コンピュータ、または他のデバイスによって実行されるプログラムモジュールを含むことができる。一般に、プログラムモジュールは、特定のタスクを実行しまたは特定の抽象データ型を実現する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。典型的には、プログラムモジュールの機能を、種々の実施形態で所望されるように組み合わされ、または分配されるであろう。

図１は、状態分離および管理システムを備えたシステムを示す実施形態１００の図である。実施形態１００は、アプリケーションのコンテキスト又は状態に基づいて、アプリケーションの構成を格納及び管理することができる。

図１は、システムの機能的コンポーネントを図示している。いくつかの場合、コンポーネントはハードウェアコンポーネント、ソフトウエアコンポーネント、又はハードウェア及びソフトウェアの組み合わせであってもよい。コンポーネントのいくつかはアプリケーションレベルのソフトウェアであり、他方で、他のコンポーネントがオペレーティングシステムレベルのコンポーネントであってもよい。いくつかの場合、ある１つのコンポーネントから他のコンポーネントへの接続は、２つまたは３つ以上のコンポーネントが単一のハードウェアプラットフォーム上で動作するような密接した接続とすることができる。他の場合、接続は、長距離に亘るネットワーク接続を介して確立してもよい。各実施形態は、異なるハードウェア、ソフトウェア、および相互接続構造を使用して、記述された機能を実現することができる。

実施形態１００は、アプリケーションのための複数状態実行システムを形成するだろう機能的要素の一例である。アプリケーション１０２の異なる構成１０４は、アプリケーションが実行されるコンテキストに基づく実行システム１０６の形態で実行されるであろう。

種々の実施形態は、アプリケーションのために実行され得る異なるレベルの構成を有することができる。例えば、オペレーティングシステム環境内でインストールされ、実行されるアプリケーションは、構成を定義する一組の構成ファイルを有するものとすることができる。異なるセットの構成を用いて、構成ファイルに関連するコンテキストに基づくアプリケーション１０２を立ち上げてもよい。

他の例では、アプリケーションは仮想環境内で実行でき、そして、先に例示した構成ファイルに加えて、レジストリ設定、ダイナミックにリンクされたライブラリ、および多くの他の構成要素をコンテキスト間で変更してもよい。そのような仮想環境は、仮想マシン環境又は仮想アプリケーション環境とすることができる。仮想環境を用いてアプリケーションを実行する場合、非常に広範で豊富な構成要素のセットをコンテキスト間で変更させてもよい。

アプリケーション１０２は、コンピューティング環境内で実行される、いかなる種類の実行可能プログラムまたはプログラムの組、サービスまたは他のオペレーションとすることができる。多くの場合、アプリケーションは、オペレーティングシステム環境内で直接的に実行され、またはスクリプト、サブルーチン、または他のコンポーネントのようなアプリケーション環境内で実行されることのできる、ファイルのような実行可能要素の集りを有していてもよい。

多くのアプリケーション１０２は、他のアプリケーションまたはサービスと関連して動作することができる。例えば、アプリケーション１０２は、インターネットを介してアクセスされるウェブサービスで動作することができる。このような例では、アプリケーションはいくつかの動作を実行してもよく、ウェブサービスは、ユーザ体験を伝えるために他の動作を実行してもよい。

他の例では、アプリケーション１０２は、それ単独で、又は「プラグイン」されるか若しくは少なくとも部分的に第１のアプリケーションと統合された他のアプリケーションと共に、動作可能とすることができる。一例として、文書出版アプリケーションが動作中であるときに、ツールバー、メニューアイテム又は文書出版アプリケーションへの他のリンクを表示することのできる文書処理プログラムのようなアプリケーションとすることができる。文書出版アプリケーションが利用可能でないときは、文書処理アプリケーションは１つのユーザインタフェースを持ってもよいが、しかし文書出版アプリケーションであるときは、文書処理アプリケーションは第２のユーザインタフェースおよび利用可能な機能の第２のセットを持つことができる。

このような例では、アプリケーション１０２は、単独で動作する場合には、状態又はコンテキストに対して定義される１つの構成１０４を持ち、第２のアプリケーションで動作する場合には、第２の状態又はコンテキストに対して定義される第２の構成１０４を持つことができる。各構成１０４は、一組のポリシー１１０に関連して、変化監視システム１０８を使用して、個別に定義および管理することができる。

変更監視システム１０８は、アプリケーション構成１０４に対する変更を検出し、および格納することができる。変化監視システム１０８は、変化を検出し、変化を分類し、アプリケーション１０２が実行中である、またはこれから実行する１つまたは２つ以上のコンテキストに適用可能であるか否かを決定することができる。どのように変化及びコンテキストを分類するか、および変化をどのように処理するかの定義をポリシー１１０内に定めることができる。

実施形態１００は、別個のアプリケーション１０２および一組の構成１０４を示す。いくつかの実施形態では、構成１０４は、アプリケーション１０２内で定められ得るデフォルト構成の冒頭（ｔｏｐ）で実現され得る一組のファイルまたは設定として格納されることができる。このような実施形態において、構成１０４は、「デルタ（ｄｅｌｔａ：差分）」ファイル、すなわちデフォルトからの変化グループとみることができる。

他の実施形態において、アプリケーションは、構成１０４の一つを含むパッケージとして定義してもよい。異なるアプリケーションパッケージが各構成について作成される。構成内の設定が広く行きわたる場合か、またはアプリケーションが開始したときに構成の変化が使用される場合に、このような実施形態を用いることができる。このような構成の変化の例は、初期スタートアップの間、アプリケーションによって使用されるオプションを定義するレジストリ設定であってよい。

実行システム１０６は、アプリケーション１０２を実行することができる、任意の環境、ワークスペース、またはメカニズムであってよい。いくつかの実施形態において、実行システム１０６は、例えば変化監視システム１０８を含む、多くの他のアプリケーションおよびサービス動作を実行するオペレーティングシステム環境とすることができる。いくつかの実施形態において、実行システム１０６は仮想マシンまたは仮想アプリケーション環境などの仮想環境であってよい。さらに他の例では、実行システム１０６は、アプリケーション１０２を実行する別個のハードウェアプラットフォームとすることができる。

実施形態１００の構成は、いかなる種類のコンピューティング構成であってもよい。いくつかの実施形態において、実施形態１００に図示されるコンポーネントの多くは、パーソナルコンピュータまたはサーバコンピュータのような単独のハードウェアプラットフォーム上で実行することができる。他の実施形態において、いくつかのコンポーネントはあるひとつのハードウェアプラットフォーム上で実行することができる一方、他のコンポーネントは、別個のハードウェアプラットフォーム上で実行することができる。このような実施形態のうちのいくつかは、多くの異なるハードウェアプラットフォームを使用して実施形態１００を実現することができる。そのような実施形態は、クロスマシン（ｃｒｏｓｓ ｍａｃｈｉｎｅ）構成と称することができる。

いくつかのクロスマシン構成において、実施形態１００のコンポーネントのいくつかは、仮想マシンとして実行され、または仮想アプリケーション環境内で操作されることができる。仮想マシンは、ハードウェアプラットフォームのソフトウェアシミュレーションとすることができ、オペレーティングシステムを含み、および仮想マシンが別個の専用ハードウェアプラットフォームであるかのように機能することができる。

アプリケーション仮想化によって、全ての共有されたリソースのアプリケーション固有のコピーを作成することができる。各アプリケーションは、レジストリエントリ、ダイナミックにリンクされたライブラリ、及びアプリケーションとパッケージングされ得る他のオブジェクトのような潜在的に共有されたリソースの別個の構成を有することができる。パッケージはキャッシュで実行され、仮想的アプリケーションを作り出すことができる。仮想的アプリケーションが採用される場合、これら共有されたリソース自体のコピーを用いることができる。

コンテキストマネージャ１１２は、アプリケーションが動作中または将来動作するコンテキストを決定することができる。コンテキストマネージャ１１２は、アプリケーション１０２に利用可能である多くの異なるリソースの存在、構成、および他のパラメータを監視することができる。コンテキストマネージャ１１２は、変化監視システム１０８によって使用され得るアプリケーションに対する状態を決定して、構成を適切に格納することができる。コンテキストマネージャ１１２は、状態又はコンテキストに基づいて種々の構成の間で選択をすることができるアプリケーションランチャ１２６に対する状態を定義することができる。

コンテキストマネージャ１１２は、システムの種々の側面を継続的に監視するアプリケーションまたはサービスとすることができる。いくつかの場合では、このようなコンテキストマネージャ１１２は単一のハードウェアプラットフォームで動作し、種々の条件を監視することができる。ハードウェアプラットフォームは、アプリケーション１０２が実行され得る同じハードウェアプラットフォームであってよい。他の実施形態では、コンテキストマネージャ１１２は、アプリケーションが実行されるハードウェアプラットフォームから遠隔動作するサービスとしてもよい。

コンテキストマネージャ１１２は、アプリケーションが動作中または将来動作する状態についての種々の情報、メタデータ、およびパラメータを収集することができる。コンテキストマネージャ１１２はポリシー１１０内で用いることのできる任意の適切な情報を収集して種々の形態で構成を取り扱うことができる。異なる実施形態によって、異なる組の情報およびメタデータを収集して現在の状態を決定することができる。

コンテキストメタデータの例として、仮想アプリケーション１１４が存在するか又は存在しないこと、種々の仮想マシン１１６の存在、オペレーティングシステム１１８の存在および構成、種々の他のアプリケーション１２０およびネットワークサービス１２２の存在および構成、および他の状態情報１２４を含むことができる。他の状態情報は、アプリケーションが動作するセッション、ユーザまたはデバイスのグループ内の要素であること、または他のパラメータとすることができる。

他の状態情報１２４は、セッションについての情報を含むことができ、それはセッションについてのメタデータを含むことができる。例えば、状態情報１２４は、２つ若しくは３つ以上の特定のデバイス若しくはユーザを接続するセッション、又は２つ若しくは３つ以上の一般的なデバイス若しくはユーザを接続するセッションとすることができる、セッションの型を含むだろう。セッションメタデータは、セッション内で使用されるプロトコル又はセッションを確立するために使用されるアドレス若しくはポートのような種々の接続パラメータを含むこともできる。いくつかの実施形態では、アプリケーションは他のアプリケーションまたはサービスと共にいくつかの異なる種類のセッションを作り、そしてセッションの存在、不存在、または構成をアプリケーションに対するコンテキストの一部として定義することができる。

他の相互作用コンポーネントの存在および構成によって、アプリケーションに対するコンテキストの一部を定義することができる。アプリケーション１０２は、仮想アプリケーション１１４、仮想マシン１１６、アプリケーション１２０、およびネットワークサービス１１２と異なるキャパシティで相互作用することができる。いくつかの場合、アプリケーションの実行または動作は、アプリケーション１０２の外部の種々の相互作用コンポーネントの存在、不存在、または構成に影響されるだろう。

アプリケーションが相互作用するコンポーネントの存在、不存在、及びいくつかの場合では構成によって、アプリケーションに対する新しい状態を定義することができる。例えば、あるアプリケーションは、他のアプリケーションまたはサービスに対するユーザインタフェースコンポーネントを追加又は除去することができる。他のアプリケーションが存在し、構成される場合、最初のアプリケーションは、ユーザインタフェースコンポーネントのあるセットまたは他のアプリケーションにリンクされる機能を提供し、または他のアプリケーションによって提供される機能を使用することができる。他のアプリケーションが存在せず、又は異なって構成される場合、最初のアプリケーションは代替のユーザインタフェース又は機能を提供してもよい。

アプリケーションが相互作用するコンポーネントは、仮想コンポーネントであり得る。いくつかの場合、アプリケーションは、実行システム１０６を使用して仮想的に実行され得るし、他方のアプリケーションが仮想的に実行され得る。双方のアプリケーションが仮想的に実行されるので、各アプリケーションは、デフォルト構成において互いに相互作用なしに動作することができる。しかしながら、双方のアプリケーションが動作する場合、各アプリケーションは、各アプリケーションの間でデータ、コントロールまたは他の信号を通過させるように構成することができる。そのような場合、各アプリケーションは、双方のアプリケーションが仮想的におよび別個に動作する場合であっても、相互作用時点を定義し、および相互作用が発生することができるように指定された構成１０４を有するようにしてもよい。そのような場合、双方のアプリケーションが、同時にまたは順次に開始されて、それらアプリケーションが相互作用するようにすることができる。

アプリケーション１０２と同じオペレーティングシステム内でインストールされ、動作するコンポーネントに比べて、仮想コンポーネントは、異なる構成オプションを示す。一般に、仮想コンポーネントはそれとは知られずに（ａｇｎｏｓｔｉｃａｌｌｙ）他のコンポーネントに作用し、および特定の方法で構成されて、慣例のオペレーションシステム環境や他の仮想環境を含む、別個の環境において他のアプリケーションと相互作用するようにしてもよい。

コンテキストは、オペレーティングシステム１１８の種々のパラメータまたは構成を含むだろう。例えば、コンテキストは、オペレーティングシステムの種類、特定のバージョン、および元々のオペレーティングシステムについての他のパラメータのようなオペレーティングシステムについての一般的な情報を含むことができる。コンテキストは、レジストリセッティング、ダイナミックにリンクされたライブラリのようなファイルの存在および構成、オペレーティングシステムによって用いられて種々のハードウェア周辺デバイスおよびインタフェースにアクセスするための設定、および他の種類のパラメータのような、オペレーティングシステム環境に対する追加または変更をも含むことができる。

いくつかの実施形態では、アプリケーションが開始されるときに構成１０４を適用することができる。いくつかの実施形態によれば、アプリケーション１０２が実行を開始した後に構成１０４がアプリケーション１０２に適用されるようにすることも可能とすることができる。

いくつかの実施形態は、実行開始の後に、いくつかの構成１０４を適用可能とすることができるが、他の構成１０４は、アプリケーションが開始したときにのみ適用されるようにできる。そのような実施形態では、２つまたは３つ以上の構成１０４をアプリケーション１０２の単独のインスタンスに適用してもよい。例えば、全社的な構成は、アプリケーションに対する全社的なデフォルト設定を設定するよう定義してもよい。ユーザの個人的好みに対して全社的な構成をさらに調整する、又は調整しないユーザ固有の設定を含む第２の構成を適用してもよい。

他の例において、アプリケーション１０２は、いくつかの他のアプリケーションまたはネットワークサービスと相互作用するようにしてもよい。各ネットワークサービスまたはアプリケーションを別個の構成１０４内で定義して、アプリケーション１０２が開始したときに、多くの異なる構成１０４が適用され、各構成により別個のアプリケーションまたはサービスがアクセスされるようにしてもよい。

アプリケーション１０２は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）又はインターネットを含む他のネットワークを介して利用可能である種々のネットワークサービス１２２と相互作用するようにしてもよい。多くの場合、ウェブサービスを用いて、クエリ及び他の操作又はサービスに応答してデータを提供するようにしてもよい。構成１０４は、ウェブサービス又は他のネットワークサービス１２２が存在するときに、アプリケーション１０２を実行するために定義してもよい。そのような構成は、ポート、プロトコル、アドレス、および他の通信構成情報、さらにアプリケーション１０２を通じて利用可能な特定の機能を構成することも含めることができる。

構成１０４は、ユーザインタフェースコンポーネント、リンク、又はネットワークサービス１２２が特定のインスタンスにおいてアクセスされ得るようにした他の構成可能なアイテムを含むようにしてもよい。

例えば、文書処理プログラムは、ネットワークサービス１２２として提供されるシソーラスサービスを使用してもよい。シソーラスサービスが利用可能である場合、文書処理プログラムは、シソーラスサービスにアクセスするためのメニュー選択などのユーザインタフェースの形態でシソーラスサービスへのリンクを有するようにしてもよい。シソーラスサービスが選択された場合、クエリはネットワークサービスに送付され、応答が受信される。その応答は、シソーラスサービスが文書処理プログラムの一部であるかのように文書処理プログラム内に表示されることができる。そのような場合、ユーザは、ネットワークサービスが呼び出されたことを認識しない。シソーラスサービスが利用可能でないときに、構成１０４はローカルバージョンを置き換え、シソーラス機能を、非アクティブにし、不可視にし、さもなくばアクセス不可能にすることができる。

コンテキストマネージャ１１２は、アプリケーションが現在動作している又はこれから動作するコンテキストを定義する。コンテキストは、ポリシー１１０と関連して使用されて、アプリケーションランチャ１２６がアプリケーション１０２を開始するときに呼び起こされる特定の構成１０４を作成する。コンテキストマネージャ１１２はアプリケーションランチャ１２６によって使用される現在のコンテキストの検出をして、適切な構成１０４又は構成１０４のグループを選択するようにしてもよい。

アプリケーションが実行するコンテキストは、ポリシー１１０によって定義することができる。コンテキストは状態の分類又は種類とすることができる。多くの場合、状態はいくつかのコンテキストを有する。例えば、アプリケーション１０２は、仮想マシン１１６上で動作する他のアプリケーションと相互作用するのみならず、ネットワークサービス１２２と相互作用してもよい。仮想マシン１１６の存在によって、仮想マシンコンテキストを定義し、およびネットワークサービスの存在によってネットワークを動作可能にするコンテキストを定義することができる。いくつかの場合、２つまたは３つ以上の異なるコンテキストを適用してもよい。

複数の構成１０４がアプリケーション１０２の単一インスタンスに適用される場合、複数の独立したコンテキストを特定のインスタンスに対して定義することができる。上述の例では、仮想マシンコンテキスト及びネットワーク可能化コンテキストを個別的におよび独立して定義することができる。

単一の構成１０４がアプリケーション１０２のインスタンスに適用される場合、いくつかの異なる要素の結合であるコンテキストを定義することができる。上述の例では、仮想マシンおよびネットワーク可能化されたサービスを含む単一のコンテキストを定義することができ、単一の構成１０４を作成することができる。個別の構成を、ネットワーク可能化サービスなしに仮想マシンに対して作成し、および仮想マシンなしにネットワーク可能化サービスに対して作成することができる。

ポリシー１１０によって、コンテキストの種類、およびコンテキストに基づいてアプリケーション構成に対する変化がどのように取り扱われるべきかを定義することができる。例えば、いくつかの変化が放棄される一方で、他の種類の変化が保存されるようにしてもよい。複数の独立した構成が使用される場合、ポリシーによって、ある１つのコンテキスト内に格納されるが、他のコンテキストには格納されない１つの種類の変化を定義することができる。

図２は、コンテキスト依存構成で動作するための方法を示す実施形態２００のフローチャートである。実施形態２００は、アプリケーションランチャ１２６、コンテキストマネージャ１１２、変化監視システム１０８、及び実行システム１０６を含む実施形態１００のコンポーネントによって実行されることのできる種々の動作の一例である。

他の実施形態は、異なるシーケンス、追加的な又は少ないステップ、及び類似の機能を達成するための異なる名称（ｎｏｍｅｎｃｌａｔｕｒｅ）又は用語を使用することができる。いくつかの実施形態では、同期又は非同期のいずれかの形態で、種々の動作又は１組の動作を他の動作と並行して実行することができる。ここで選択されたステップは、動作のいくつかの原理を、単純化された形態で図示するために選ばれたものである。

実施形態２００は、アプリケーションを開始し、アプリケーションの構成に対する変化を検知し、および後の再利用のために構成の格納での変化を格納するための方法を図示する。

アプリケーションをブロック２０２で開始するためにコマンドを受信することができる。多くの場合、アイコンを選択したり、コマンドライン上にコマンドを入力したりするようなユーザ入力によって、コマンドを開始することができる。他の場合、アプリケーションを立ち上げるコマンドは、他のアプリケーション又はネットワークサービスを含むサービスによって開始してもよい。

アプリケーションに対するコンテキストは、ブロック２０４において決定することができる。コンテキストをポリシーにおいて定義し、および特定のコンテキストに対してアプリケーションに対する構成パラメータのセットの形態を作成することができる。コンテキストを任意の方法で決定することができる。いくつかの実施形態では、実施形態１００内のコンテキストマネージャ１１２のようなコンテキストマネージャを用いて、現在のまたは意図されたコンテキストを決定してもよい。

コンテキストは現在のコンテキスト又は意図されたコンテキストとすることができる。現在のコンテキストは、アプリケーションが相互作用する種々のパラメータ、システムおよびサービスの現在の状態を検知することによって決定することができる。意図されたコンテキストは、アプリケーションが実行されているときに存在することのできるコンテキストとすることができる。

互いに相互作用するいくつかのアプリケーションが順次または実質的に同時に立ち上げられる場合に、意図されたコンテキストを使用することができる。立ち上げられたアプリケーションのグループにおける各アプリケーションを、他のアプリケーションと動作するように構成してもよいが、全てのアプリケーションが開始され、互いに接続が形成されているときに、そのようなコンテキストは存在することができる。

ブロック２０６においてコンテキストに対する定義された構成が無い場合、ブロック２０８においてデフォルト構成を選択することができる。ブロック２０６において構成がコンテキストに対して定義されている場合、その構成をブロック２１０においてロードすることができる。

いくつかの実施形態において、２つまたは３つ以上の構成が、コンテキストに基づいてロードされ適用される。そのような実施形態では、種々の構成が順次に適用され、適用された最後の構成が以前の構成の設定を上書きすることが可能である。

いくつかの実施形態が優先順位の手法を適用して、２つ以上の構成がパラメータを設定する場合に、どの構成のどのパラメータが適用されるかを決定するようにしてもよい。順次の優先順位の手法において、最後に適用される構成が優位を占める。しかしながら、他の手法では異なるメトリクス（ｍｅｔｒｉｃｓ）または規則を適用することができる。そのような規則は一組のポリシーの形態で定義することができる。

構成が一旦定義されると、ブロック２１２において、構成を使用して、アプリケーションを実行することができる。

複数の構成が使用される多くの実施形態において、アプリケーションを、専用の仮想マシンのような仮想環境においてまたはアプリケーション仮想化環境内で実行することができる。アプリケーションを仮想化することによって、多くの他のアプリケーションを伴う従来のオペレーティングシステム環境内でアプリケーションが動作する場合よりも簡単な方法で多くの設定を変更しまたは構成することができる。例えば、仮想環境によって、レジストリ設定またはダイナミックにリンクされたライブラリを動作可能にしてもよい。このようにしなければ、これらレジストリ設定またはダイナミックにリンクされたライブラリは、他のアプリケーションと共有化されて仮想アプリケーションに対して変更される。

ブロック２１４において変化が検出された場合、アプリケーションのコンテキストに基づいて構成設定を作成し、または修正するプロセスを開始することができる。

ブロック２１６においてコンテキストを分類することができる。いくつかの実施形態では、特定のインスタンスがいくつかの異なるコンテキストを含み、そのコンテキストの各々は他のコンテキストからは独立している、１つ又は少数のパラメータを有することができる。他の実施形態では、単一のコンテキストを、多くの異なるパラメータ又は記述を含み得る任意のシチュエーションに対して定義することができる。ポリシーのセットによって、コンテキストを定義してもよい。

ブロック２１８において変化を種類によって分類することができる。変化の種類は、変更が適切に処理されるように、ポリシーにおいて定義されるような変化の一般的な分類とすることができる。

ブロック２２０における各コンテキスト分類に対して、後続のブロックにおいて変更を処理することができる。実施形態２００は、２つまたは３つ以上のコンテキストが特定のシチュエーションに対して存在する実施形態の一例である。他の実施形態では、単一のコンテキストを定義し、およびブロック２２０のフォーループ（ｆｏｒ−ｌｏｏｐ）をコンテキストに対して一回実行する。

ブロック２２２において変更の種類がどのように取り扱われるかについてポリシーが規定しない場合、ブロック２２４においてデフォルトのポリシーを適用することができる。そうでなければ、現在のポリシーを適用してもよい。

ブロック２２６において変化が保存されるべきか無視されるべきかを現在のポリシーまたはデフォルトのポリシーにより記述することができる。ブロック２２６において変化が無視されるべき場合、ブロック２３０において変化は保存されない。ブロック２２６で変化が保存されるべきである場合、ブロック２２８において構成はコンテキストに対して更新される。

次のコンテキストが存在する場合、ブロック２２０において、かかる次のコンテキストについてプロセスが継続する。ブロック２２０において、コンテキストの各々が処理された場合、アプリケーションの更なる実行のために、処理はブロック２１２に戻る。

実施形態２００は、コンテキストを決定し、およびコンテキストに基づいてアプリケーションの変化を保存するプロセスの一例である。同一のコンテキストにおいてアプリケーションが再開始される場合、構成は呼び出され、アプリケーションは変化に従って挙動する。

主題の上述した記述は例示及び記述の目的のために提示されたものである。主題を開示されたままの形態に徹底することや制限することを意図しておらず、他の変更および変形は上記教示の観点から可能であろう。実施形態は、本発明の原理とその実際の応用とを、当業者が、熟慮した特定の用途に適合するように種々の実施形態および種々の変更で発明を最もよく利用できることを可能にする。最もよく説明するために選択され、記述され、それにより、添付された請求項は、従来技術によって限定されることを除けば、他の代替的実施形態を含むよう解釈されることを意図している。

Claims (15)

1. 第１のデバイス上で、第１の構成及び第１の状態を有するアプリケーションを実行することと、
   前記アプリケーションに対する変化であって、第２の状態を定義する変化を検出することと、
   前記第２の状態に対して、ユーザコンテキスト又はマシンコンテキストではない第１のコンテキストを決定することと、
   前記第１のコンテキストに対して定義されたポリシーを参照することと、
   前記ポリシー内で定義されたように前記第１のコンテキストに基づいて前記変更を格納することとを具えることを特徴とする方法。
2. 前記コンテキストはセッション特定のコンテキストを具えることを特徴とする請求項１に記載の方法。
3. 前記コンテキストはクロスマシンコンテキストを具えることを特徴とする請求項１に記載の方法。
4. 前記クロスマシンコンテキストは、少なくとも１つの仮想マシンを具えることを特徴とする請求項３に記載の方法。
5. 前記アプリケーションは複数のリソースを具え、前記変化は前記リソースの少なくとも１つに影響を与えることを特徴とする請求項１に記載の方法。
6. 前記複数のリソースのうちの１つは、第２のアプリケーションであることを特徴とする請求項５に記載の方法。
7. 前記アプリケーションは第１のハードウェアプラットフォーム上で実行され、前記リソースのうちの１つは第２のハードウェアプラットフォーム上で実行されることを特徴とする請求項５に記載の方法。
8. 前記アプリケーションは、第１の仮想コンテキストにおいて実行されることを特徴とする請求項５に記載の方法。
9. 前記複数のリソースのうちの少なくとも１つは第２の仮想コンテキスト内にあることを特徴とする請求項８に記載の方法。
10. 前記第１の仮想コンテキストはアプリケーション仮想化コンテキストであることを特徴とする請求項９に記載の方法。
11. 前記第２の仮想コンテキストはアプリケーション仮想化コンテキストであることを特徴とする請求項１０に記載の方法。
12. 前記第２の仮想コンテキストは仮想マシンコンテキストであることを特徴とする請求項１０に記載の方法。
13. 前記第１の仮想コンテキストは第１の仮想マシンコンテキストであることを特徴とする請求項８に記載の方法。
14. 複数のコンテキストのうちの少なくとも１つに基づいて変更の実行を備えるポリシーと、
    前記複数のコンテキストにおいて第１のアプリケーションを実行するよう構成された実行システムと、
    前記第１のアプリケーションに変化がなされたことを決定し、
    前記変化に対して少なくとも１つのコンテキストを決定し、
    前記少なくとも１つのコンテキストが現在のコンテキストであるときに前記変化を格納して前記変化を実行できるように構成された変化監視システムとを備えたことを特徴とするシステム。
15. 前記複数のコンテキストは、
    セッション特定のコンテキストと、
    セッションの種類特定のコンテキストと、
    クロスマシンコンテキストと、
    デュアルアプリケーションコンテキストとからなるグループの少なくとも１つを備えることを特徴とする請求項１４に記載のシステム。

Images