(57)【要約】オペレーティングシステムによって提供されるリソースにアクセスする方法において、リソースの要求は、環境内で実行するアプリケーションプログラムによって受信される。リソースに関連する第１の識別子が取得される。リソースに関連する第１の識別子とリソースに関連する第２の識別子との間の関連付け、ならびに環境に関連する関連付けに応答して、レジストリが調べられる。レジストリを調べたことに応答して、リソースと、上記リソースを起動する環境とが、調べられる。第２の識別子は、リソースと、環境と、リソースを起動する環境とに関連付けられる。リソースに対するレジストリキーが、レジストリに保存され、上記レジストリキーは、第２の識別子を含む。第２の識別子に応答して、リソースの要求は、リソースの識別されたインスタンスにリダイレクトされる。
2008521071.tif 000002
【特許請求の範囲】
【請求項１】
オペレーティングシステムによって提供されるリソースにアクセスするための方法であって、
（ａ）第１の環境内で実行するアプリケーションプログラムによって該リソースの要求を受信するステップと、
（ｂ）該リソースに関連する第１の識別子を取得するステップと、
（ｃ）要求された該リソースおよび該リソースを起動するための起動環境を参照する第２の識別子を判定するステップと、
（ｄ）該第２の識別子に応答して、該リソースの識別されたインスタンスへ該リソースの要求をリダイレクトするステップと、
（ｅ）該リソースが存在する環境内に位置する該リソースのインスタンスを使用して、該リソースの要求に応答するステップと
を含む、方法。
【請求項２】
ステップ（ａ）は、前記アプリケーションプログラムによって、ＣＯＭライブラリを使用することをさらに含む、請求項１に記載の方法。
【請求項３】
ステップ（ａ）は、環境内で実行する前記アプリケーションプログラムによって、前記リソースの要求をすることを含む、請求項１に記載の方法。
【請求項４】
ステップ（ｅ）は、プロセス外ＣＯＭサーバのインスタンスを作成することをさらに含む、請求項１に記載の方法。
【請求項５】
ステップ（ｂ）は、前記リソースに関連する第１の識別子をインターセプトすることをさらに含む、請求項１に記載の方法。
【請求項６】
ステップ（ｂ）は、フックされるＣＯＭ  ＡＰＩに応答する第１の識別子を取得することをさらに含む、請求項１に記載の方法。
【請求項７】
ステップ（ｂ）は、ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ  ＣＯＭ  ＡＰＩをフックすることをさらに含む、請求項１に記載の方法。
【請求項８】
ステップ（ｂ）は、ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅＥｘ  ＣＯＭ  ＡＰＩをフックすることをさらに含む、請求項１に記載の方法。
【請求項９】
ステップ（ｂ）は、ＣｏＧｅｔＣｌａｓｓＯｂｊｅｃｔ  ＣＯＭ  ＡＰＩをフックすることをさらに含む、請求項１に記載の方法。
【請求項１０】
ステップ（ｂ）は、ＣｏＧｅｔＩｎｓｔａｎｃｅＦｒｏｍＦｉｌｅ  ＣＯＭ  ＡＰＩをフックすることをさらに含む、請求項１に記載の方法。
【請求項１１】
ステップ（ｂ）は、ＣｏＧｅｔＩｎｓｔａｎｃｅＦｒｏｍｌＳｔｏｒａｇｅ  ＣＯＭ  ＡＰＩをフックすることをさらに含む、請求項１に記載の方法。
【請求項１２】
ＣｏＲｅｇｉｓｔｅｒＣｌａｓｓＯｂｊｅｃｔ  ＣＯＭ  ＡＰＩをフックするステップをさらに含む、請求項１に記載の方法。
【請求項１３】
ステップ（ｃ）は、決定性のマッピングアルゴリズムを実行することをさらに含む、請求項１に記載の方法。
【請求項１４】
ステップ（ｃ）は、マップを調べることをさらに含む、請求項１に記載の方法。
【請求項１５】
ステップ（ｃ）は、前記環境に関連するマップを調べることをさらに含む、請求項１に記載の方法。
【請求項１６】
ステップ（ｃ）は、アプリケーション分離環境に関連するマップを調べることをさらに含む、請求項１に記載の方法。
【請求項１７】
ステップ（ｃ）は、前記第２の識別子の静的コピーをマップに格納することをさらに含む、請求項１に記載の方法。
【請求項１８】
ステップ（ｃ）は、前記第２の識別子を受信することをさらに含み、該第２の識別子は、前記起動環境に関連する、請求項１に記載の方法。
【請求項１９】
ステップ（ｃ）は、マップから第２の識別子を受信することをさらに含み、該第２の識別子は、前記リソースが存在する前記環境において要求された前記リソースのインスタンスを識別する、請求項１に記載の方法。
【請求項２０】
前記リソースが存在する第２の環境を識別するステップをさらに含む、請求項１に記載の方法。
【請求項２１】
ステップ（ｅ）は、前記リソースを実行することをさらに含む、請求項１に記載の方法。
【請求項２２】
ステップ（ｅ）は、前記リソースのインスタンスによって、前記アプリケーションプログラムに関連する表示領域に変更を加えることをさらに含む、請求項１に記載の方法。
【請求項２３】
オペレーティングシステムによって提供される分離リソースにアクセスするためのシステムであって、
リソースと、
環境内で実行し、該リソースの要求を受信するアプリケーションプログラムと、
該リソースに関連する第１の識別子と該リソースに関連する第２の識別子との間の関連付けと、
該第１の識別子に応答して、該関連付けから、該第２の識別子を受信する第１のプロセスと、
該リソースのインスタンスおよび該リソースを起動するための環境を識別する、第２のプロセスと、
該第２の識別子に応答して、該リソースの要求を該リソースのインスタンスへリダイレクトする第３のプロセスと
を含む、システム。
【請求項２４】
前記第１のプロセスは、前記環境内で実行する、請求項２３に記載のシステム。
【請求項２５】
前記第１のプロセスは、前記環境外で実行する、請求項２３に記載のシステム。
【請求項２６】
前記第１のプロセスは、前記第１の識別子をインターセプトする、請求項２３に記載のシステム。
【請求項２７】
前記第１のプロセスは、前記関連付けから、静的に生成される前記第２の識別子を受信することをさらに含む、請求項２３に記載のシステム。
【請求項２８】
前記第１のプロセスは、前記関連付けから、動的に生成される前記第２の識別子を受信することをさらに含む、請求項２３に記載のシステム。
【請求項２９】
前記第１のプロセスは、前記第２の識別子を前記第２のプロセスへ送信することをさらに含む、請求項２３に記載のシステム。
【請求項３０】
前記第１のプロセスは、前記第２の識別子を前記第３のプロセスへ送信することをさらに含む、請求項２３に記載のシステム。
【請求項３１】
前記第２のプロセスは、前記環境内で実行する、請求項２３に記載のシステム。
【請求項３２】
前記第２のプロセスは、前記環境外で実行する、請求項２３に記載のシステム。
【請求項３３】
前記第３のプロセスは、前記環境内で実行する、請求項２３に記載のシステム。
【請求項３４】
前記第３のプロセスは、前記環境外で実行する、請求項２３に記載のシステム。
【請求項３５】
前記リソースは、プロセス外ＣＯＭサーバをさらに含む、請求項２３に記載のシステム。
【請求項３６】
前記リソースは、前記環境に存在する第２のリソースとは異なるバージョンのＣＯＭサーバをさらに含む、請求項２３に記載のシステム。
【請求項３７】
前記第１の識別子は、第１のリソースおよび前記第２のリソースと関連している、請求項３６に記載のシステム。
【請求項３８】
前記リソースは、前記環境内に存在する、請求項２３に記載のシステム。
【請求項３９】
前記リソースは、第２の環境内に存在する、請求項２３に記載のシステム。
【請求項４０】
前記リソースは、アプリケーション分離環境内に存在する、請求項２３に記載のシステム。
【請求項４１】
前記リソースは、該リソースが存在する環境において少なくとも１つのレジストリエントリをさらに含む、請求項２３に記載のシステム。
【請求項４２】
前記アプリケーションプログラムは、アプリケーション分離環境内で実行する、請求項２３に記載のシステム。
【請求項４３】
前記アプリケーションプログラムは、アプリケーション分離環境に関連する環境内で実行する、請求項２３に記載のシステム。
【請求項４４】
前記環境内で実行する前記アプリケーションプログラムは、リソースの要求をすることを含む、請求項２３に記載のシステム。
【請求項４５】
前記アプリケーションプログラムは、リソースの要求をすることを含む、請求項２３に記載のシステム。
【請求項４６】
前記関連付けは、少なくとも１つのＣＯＭサーバおよび前記アプリケーションプログラムに関連するアプリケーション分離環境を識別するクラス識別子から、動的に生成されたクラス識別子へとマッピングすることをさらに含む、請求項２３に記載のシステム。
【請求項４７】
前記第１の識別子は、少なくとも１つのＣＯＭサーバを識別することをさらに含む、請求項２３に記載のシステム。
【請求項４８】
プロセスは、前記アプリケーションプログラム内で実行する追加的なコードをさらに含む、請求項２３に記載のシステム。
【請求項４９】
前記第１のプロセスおよび前記第２のプロセスは、同じプロセスを含む、請求項２３に記載のシステム。
【請求項５０】
前記第１のプロセスおよび前記第３のプロセスは、同じプロセスを含む、請求項２３に記載のシステム。
【請求項５１】
前記第１のプロセスおよび前記第２のプロセスおよび前記第３のプロセスは、同じプロセスを含む、請求項２３に記載のシステム。
【請求項５２】
前記第２のプロセスおよび前記第３のプロセスは、同じプロセスを含む、請求項２３に記載のシステム。
【請求項５３】
オペレーティングシステムによって提供されるリソースにアクセスするための方法であって、
（ａ）環境内で実行するアプリケーションプログラムによってリソースの要求を受信するステップと、
（ｂ）該リソースに関連する第１の識別子を取得するステップと、
（ｃ）該リソースと関連する第１の識別子と、該リソースと関連する第２の識別子との間の関連付けに応答して、レジストリを調べるステップであって、該関連付けは該環境と関連する、ステップと、
（ｄ）該レジストリを調べることに応答して、該リソースおよび該リソースを起動するための環境を識別するステップと、
（ｅ）該第２の識別子を、該リソースと、該環境と、該リソースを起動する環境とに関連付けるステップと、
（ｆ）該リソースのための、レジストリキーを該レジストリに格納するステップであって、該レジストリキーは、該第２の識別子を含む、ステップと、
（ｇ）該第２の識別子に応答して、該リソースの要求を識別された該リソースのインスタンスへリダイレクトするステップと、
（ｈ）該リソースが存在する該環境に位置する該リソースのインスタンスを使用して、該リソースの要求に応答するステップと
（ｉ）該第２の識別子に応答して、識別された該環境において、要求された該リソースを起動するステップと
を含む、方法。
【請求項５４】
ステップ（ａ）は、前記環境において実行する前記アプリケーションプログラムによって、リソースの要求をすることを含む、請求項５３に記載の方法。
【請求項５５】
ステップ（ｂ）は、フックされたＣＯＭ  ＡＰＩに応答して、該第１の識別子を取得することをさらに含む、請求項５３に記載の方法。
【請求項５６】
ステップ（ｂ）は、ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅＥｘ  ＣＯＭ  ＡＰＩをフックすることをさらに含む、請求項５３に記載の方法。
【請求項５７】
ステップ（ｂ）は、ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ  ＣＯＭ  ＡＰＩをフックすることをさらに含む、請求項５３に記載の方法。
【請求項５８】
ステップ（ｂ）は、ＣｏＧｅｔＣｌａｓｓＯｂｊｅｃｔ  ＣＯＭ  ＡＰＩをフックすることをさらに含む、請求項５３に記載の方法。
【請求項５９】
ステップ（ｂ）は、ＣｏＧｅｔＩｎｓｔａｎｃｅＦｒｏｍＦｉｌｅ  ＣＯＭ  ＡＰＩをフックすることをさらに含む、請求項５３に記載の方法。
【請求項６０】
ステップ（ｂ）は、ＣｏＧｅｔＩｎｓｔａｎｃｅＦｒｏｍｌＳｔｏｒａｇｅ  ＣＯＭ  ＡＰＩをフックすることをさらに含む、請求項５３に記載の方法。
【請求項６１】
ＣｏＲｅｇｉｓｔｅｒＣｌａｓｓＯｂｊｅｃｔ  ＣＯＭ  ＡＰＩをフックするステップをさらに含む、請求項５３に記載の方法。
【請求項６２】
ステップ（ｃ）は、前記アプリケーションプログラムが存在する前記環境において前記レジストリを調べることをさらに含む、請求項５３に記載の方法。
【請求項６３】
ステップ（ｃ）は、第２の環境において第２のレジストリを調べることをさらに含む、請求項５３に記載の方法。
【請求項６４】
ステップ（ｃ）は、前記関連付けから前記第２の識別子を受信することができなかったことに応答して、前記レジストリを調べることをさらに含む、請求項５３に記載の方法。
【請求項６５】
ステップ（ｄ）は、前記リソースが存在する第２の環境を識別することをさらに含む、請求項５３に記載の方法。
【請求項６６】
ステップ（ｅ）は、前記関連付けにおいて、前記第２の識別子を、前記リソースと、前記環境と、該リソースを起動するための環境と、該リソースを起動して環境の中に入れるための方法の記述とに関連させることをさらに含む、請求項５３に記載の方法。
【請求項６７】
ステップ（ｇ）は、前記第２の識別子を、第２プロセスへ送信することをさらに含む、請求項５３に記載の方法。
【請求項６８】
ステップ（ｇ）は、前記第２のプロセスによって、前記リソースを実行することをさらに含む、請求項６７に記載の方法。
【請求項６９】
ステップ（ｇ）は、前記アプリケーションプログラムによって、前記リソースと通信することをさらに含む、請求項５３に記載の方法。
【請求項７０】
ステップ（ｇ）は、前記リソースによって、前記アプリケーションプログラムに関連する表示領域に変更を加えることをさらに含む、請求項５３に記載の方法。
【請求項７１】
オペレーティングシステムによって提供されるリソースにアクセスするためのシステムであって、
リソースと、
環境内で実行し、該リソースの要求を受信するアプリケーションプログラムと、
該リソースと関連する第１の識別子と、該リソースと関連する第２の識別子との間の関連付けであって、該関連付けは該環境と関連する、関連付けと、
フックプロセスであって、
該リソースと関連する該第１の識別子を取得することと、
該リソースおよび該リソースを実行するための該環境を識別することと、
該関連付けの中に、該第２の識別子を格納することと、
該リソースのためのレジストリキーを格納することと
を含む、フックプロセスと、
該第２の識別子に応答して、該リソースへ、該リソースの要求をリダイレクトする第２のプロセスと
を含む、システム。
【請求項７２】
前記リソースは、ＣＯＭサーバをさらに含む、請求項７１に記載のシステム。
【請求項７３】
前記リソースは、該リソースが存在する環境において、少なくとも１つのレジストリエントリをさらに含む、請求項７１に記載のシステム。
【請求項７４】
前記リソースは、第２の環境に存在する、請求項７１に記載のシステム。
【請求項７５】
前記アプリケーションプログラムは、アプリケーション分離環境内で実行することをさらに含む、請求項７１に記載のシステム。
【請求項７６】
前記アプリケーションプログラムは、アプリケーション分離環境に関連する環境内で実行することをさらに含む、請求項７１に記載のシステム。
【請求項７７】
前記環境内で実行する前記アプリケーションプログラムは、リソースを要求することを含む、請求項７１に記載のシステム。
【請求項７８】
前記関連付けは、少なくとも１つのＣＯＭサーバおよびＣＯＭクライアントが存在する環境を識別するクラス識別子から、前記第２クラス識別子へとマッピングすることをさらに含む、請求項７１に記載のシステム。
【請求項７９】
前記フックプロセスは、前記第１の識別子に応答して、前記関連付けを調べることをさらに含む、請求項７１に記載のシステム。
【請求項８０】
前記フックプロセスは、前記関連付けを調べることに応答して、環境内のレジストリを調べることを判定することをさらに含む、請求項７１に記載のシステム。
【請求項８１】
前記フックプロセスは、前記関連付けを調べることに応答して、アプリケーション分離環境内のレジストリを調べることを判定することをさらに含む、請求項７１に記載のシステム。
【請求項８２】
前記フックプロセスは、前記関連付けを調べることに応答して、第２の環境内のレジストリを調べることを判定することをさらに含む、請求項７１に記載のシステム。
【請求項８３】
前記フックプロセスは、前記レジストリを調べることに応答して、該リソースおよび該リソースが存在する環境を識別することをさらに含む、請求項７１に記載のシステム。
【請求項８４】
前記フックプロセスおよび前記第２のプロセスは、同じプロセスである、請求項７１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の技術分野）
本発明は、コンピュータによるソフトウェアアプリケーションの実行の管理に関し、特に、異なるアプリケーションプログラム間の、および、同じコンピュータシステムによって実行される同じアプリケーションの個人ユーザ間の、互換性および社交性の問題を低減するための方法および装置に関する。
【背景技術】
【０００２】
（発明の背景）
コンピュータソフトウェアアプリケーションプログラムは、実行中およびインストール中、コンピュータのオペレーティングシステムによって提供される様々なネイティブリソースを活用する。従来のシングルユーザコンピュータを図１Ａに描写している。図１Ａに示すように、オペレーティングシステム１００によって提供されるネイティブリソースは、ファイルシステム１０２、レジストリデータベース１０４、およびオブジェクト１０６を含んでよい。ファイルシステム１０２は、アプリケーションプログラムがデータファイル１５０、１５２を開く、作成する、読み込む、コピーする、修正する、および削除するためのメカニズムを提供する。データファイル１５０、１５２は、ディレクトリ１６０、１６２の論理階層内において共にグループ化されてよい。レジストリデータベース１０４は、コンピュータに物理的に取り付けられたハードウェア、いずれのシステムオプションが選択されたか、コンピュータメモリがどのようにセットアップされているか、アプリケーション固有データの様々な項目、および、オペレーティングシステム１００が開始される際にはどのアプリケーションプログラムが存在しているべきか、に関する情報を保存する。図１Ａに示すように、レジストリデータベース１０４は一般に、レジストリ値用のコンテナである「キー」１７０、１７２の論理階層に組織化される。オペレーティングシステム１００は、セマフォ、セクション、ミューテックス、タイマ、ミュータント、およびパイプを含む、多数の通信オブジェクトおよび同期オブジェクト１０６を提供してもよい。同時に、ファイルシステム１０２、レジストリデータベース１０４、オブジェクト１０６、および、オペレーティングシステム１００によって利用されるその他任意のネイティブリソースを、本書全体を通じて「システムレイヤ」１０８と称することにする。システムレイヤ１０８によって提供されるリソースは、任意のアプリケーションまたはシステムプログラム１１２、１１４で利用可能である。
【０００３】
しかしながら、互換性のない２つのアプリケーションプログラム１１２、１１４の実行またはインストールを試みる場合に問題が生じる。図１Ａに示すように、２つのアプリケーションプログラムＡＰＰ１  １１２およびＡＰＰ２  １１４は、オペレーティングシステム１００の「優位に立って」実行する、すなわち、アプリケーションプログラムは、オペレーティングシステムによって提供された機能を活用してネイティブリソースにアクセスする。アプリケーションプログラムは、実行中またはインストールプロセス中にネイティブリソース１０２、１０４、１０６を相互排他的な方式で活用する際、互いに互換性がないといわれている。ＡＰＰ１  １１２は、パス名ｃ：＼ｗｉｎｄｏｗｓ＼ｓｙｓｔｅｍ３２＼ｍｓｖｃｒｔ．ｄｌｌによって位置付けられるファイルを必要とする、またはそれをインストールしようと試みる場合があり、ＡＰＰ２  １１４は、同じパス名によって位置付けられる第２の異なるファイルを必要とする、またはそれをインストールしようと試みる場合がある。この場合、ＡＰＰ１  １１２およびＡＰＰ２  １１４は同じコンピュータで実行されることができず、互いに互換性がないといわれている。その他のネイティブリソースも同様の問題に直面し得る。すなわち、同じオペレーティングシステム１００環境においてＡＰＰ１  １１２およびＡＰＰ２  １１４の両方を共にインストールまたは実行することを必要とするコンピュータのユーザにとって不便であるという程度のものである。
【０００４】
図１Ｂは、数人のユーザに代わってアプリケーションプログラム１１２、１１４、１１２’、１１４’の同時実行をサポートするマルチユーザコンピュータシステムを描写している。図１Ｂに示すように、ＡＰＰ１  １１２の第１のインスタンスおよびＡＰＰ２  １１４の第１のインスタンスは第１のユーザセッション１１０のコンテキスト内で実行され、ＡＰＰ１  １１２’の第２のインスタンスは第２のユーザセッション１２０のコンテキスト内で実行され、ＡＰＰ２  １１４’の第２のインスタンスは第３のユーザセッション１３０のコンテキスト内で実行される。こうした環境においては、ＡＰＰ１  １１２、１１２’の両方のインスタンスおよびＡＰＰ２  １１４、１１４’の両方のインスタンスが、アプリケーションを実行するのは単一のユーザであるかのようにネイティブリソース１０２、１０４、１０６を活用すると、問題が生じる。例えば、ＡＰＰ１  １１２はアプリケーション固有データをレジストリキー１７０に保存することができる。第１のユーザコンテキスト１１０内で実行するＡＰＰ１  １１２の第１のインスタンスおよび第２のユーザコンテキスト１２０内で実行するＡＰＰ１  １１２’の第２のインスタンスがいずれも構成データを同じレジストリキー１７０に保存しようと試みる場合、ユーザの１人について誤った構成データが保存される。その他のネイティブリソースにも同様の問題が発生し得る。
【０００５】
本発明は、これらのアプリケーションプログラム互換性および社交性の問題に対処するものである。
【発明の開示】
【課題を解決するための手段】
【０００６】
（発明の概要）
本発明は、互いに互換性のないアプリケーションプログラム、および、同じアプリケーションプログラムの互換性のないバージョン同士の、単一のコンピュータにおけるインストールおよび実行を可能にする。また、本発明は、シングルユーザコンピュータ用に作成された、または、マルチユーザコンピュータにおいて実行した際に生じる課題を考慮せずに作成されたプログラムの、マルチユーザコンピュータにおけるインストールおよび実行を可能にする。記載する方法および装置は、多くのユーザが単一のコンピュータを同時に使用するマルチユーザコンピューティング環境に加えて、多くのユーザが単一のコンピュータを交互に使用することができる環境を含むシングルユーザコンピューティング環境に適用可能である。本発明は、アプリケーションプログラムまたは基本オペレーティングシステムを修正することなく、ファイルシステム、レジストリデータベース、システムオブジェクト、ウィンドウクラス、およびウィンドウ名等のネイティブリソースへのユーザアクセスおよびアプリケーションアクセスを仮想化する。また、仮想化されたネイティブリソースは、標準ツールおよび技術を使用して、仮想化されたリソースの閲覧および管理の実現を可能にするネイティブ形式で保存することができる（すなわち、仮想化ファイルがファイルシステムに保存される、仮想化されたレジストリエントリがレジストリデータベースに保存される等）。
【０００７】
一つの側面において、本発明は、オペレーティングシステムによって提供されたリソースにアクセスする方法に関する。リソースの要求は、第１の実施形態の内部で実行するアプリケーションプログラムによって受信される。上記リソースに関連する第１の識別子が取得される。第２の識別子は、要求されたリソースと、起動するリソースが決定される起動環境とを参照する。第２の識別子に応答して、リソースの要求は、リソースの識別されたインスタンスにリダイレクトされる。リソースの要求は、リソースが存在する環境内に位置するリソースのインスタンスを用いることにより、応答される。第２の識別子に応答して、要求されたリソースは、識別された環境内で起動される。
【０００８】
一実施形態において、第２の識別子を決定することは、アプリケーション分離環境に関連するマップを調べることを包含する。別の実施形態において、第２の識別子を決定することは、マップから、第２の識別子を受信することを包含し、第２の識別子は、リソースが存在する環境内の要求されたリソースのインスタンスを識別する。
【０００９】
別の側面において、本発明は、オペレーティングシステムによって提供されたリソースにアクセスするためのシステムに関し、上記システムは、リソース、アプリケーションプログラム、関連付け（ａｓｓｏｃｉａｔｉｏｎ）、第１のプロセス、第２のプロセス、および第３のプロセスを含む。環境内で実行するアプリケーションプログラムは、リソースの要求を受信する。関連付けは、リソースに関連する第１の識別子とリソースに関連する第２の識別子とを関連付ける。第１の識別子に応答して、第１のプロセスは、アプリケーションから、第２の識別子を受信する。第２のプロセスは、リソースのインスタンスと、上記リソースが起動される環境とを識別する。第２の識別子に応答して、第３のプロセスは、リソースの要求を、リソースのインスタンスにリダイレクトする。
【００１０】
一実施形態において、第１のプロセスは、関連付けから、動的に生成された第２の識別子を受信する。別の実施形態において、関連付けは、クラス識別子から動的に生成されたクラス識別子へのマッピングを含み、上記マッピングは、少なくとも１つのＣＯＭサーバと、アプリケーションプログラムに関連するアプリケーション分離環境とを識別する。さらなる別の実施形態において、リソースは、プロセス外ＣＯＭサーバを備える。
【００１１】
別の側面において、本発明は、オペレーティングシステムによって提供されたリソースにアクセスする方法に関する。リソースの要求は、環境内で実行するアプリケーションプログラムによって受信される。リソースに関連する第１の識別子が取得される。リソースに関連する第１の識別子とリソースに関連する第２の識別子との間の関連付け、ならびに環境に関連する関連付けに応答して、レジストリが調べられる。レジストリを調べることに応答して、リソースとリソースが起動される環境とが識別される。第２の識別子は、リソースと、環境と、リソースを起動する環境とに関連付けられる。リソースに対するレジストリキーが、レジストリ内に保存され、上記レジストリキーは、第２の識別子を含む。リソースの要求は、第２の識別子に応答して、リソースの識別されたインスタンスにリダイレクトされる。リソースの要求は、リソースが存在する環境内に位置するリソースのインスタンスを用いることにより、応答される。要求されたリソースは、第２の識別子に応答して、識別された環境内で起動される。
【００１２】
一実施形態において、関連付けから第２の識別子を受信することに失敗したことに応答して、レジストリが調べられる。別の実施形態において、第２の識別子は、リソースと、環境と、リソースを起動する環境とに関連付けられる。
【００１３】
別の側面において、本発明は、オペレーティングシステムによって提供されたリソースにアクセスするシステムに関し、上記システムは、リソースと、アプリケーションプログラムと、関連付けと、フックプロセスと、第２のプロセスとを含む。環境内で実行するアプリケーションプログラムは、リソースの要求を受信する。リソースに関連する第１の識別子とリソースに関連する第２の識別子との間の関連付けは、環境と関連付けられる。フックプロセスは、リソースに関連する第１の識別子を取得し、リソースとリソースを起動する環境とを識別し、第２の識別子を関連付けに保存し、リソースに対するレジストリキーを保存する。第２の識別子に応答して、第２のプロセスは、リソースの要求をリソースにリダイレクトする。
【００１４】
一実施形態において、アプリケーションプログラムは、アプリケーション分離環境内でアプリケーションプログラムを実行する。別の実施形態において、リソースは、第２の環境に存在する。さらに別の実施形態において、関連付けは、少なくとも１つのＣＯＭサーバとＣＯＭクライアントが存在する環境とを識別するクラス識別子から第２の識別子への
マッピングを含む。さらに別の実施形態において、フックプロセスは、関連付けを調べることに応答して、レジストリを調べること決定する。
【発明を実施するための最良の形態】
【００１５】
（索引）
この索引は、読者が発明の議論を理解する助けとなることを意図するものである。
【００１６】
１．０  分離環境観念的概念
１．１  アプリケーション分離
１．２  ユーザ分離
１．３  ネイティブリソースの集約ビュー
１．４  プロセスと分離スコープとの関連付け
１．４．１  スコープ外プロセスと分離スコープとの関連付け
２．０  仮想化機構概念
３．０  分離環境へのインストール
４．０  仮想化の詳細例
４．１  ファイルシステム仮想化
４．１．１  ファイルシステムオープン動作
４．１．２  ファイルシステム削除動作
４．１．３  ファイルシステム列挙動作
４．１．４  ファイルシステム作成動作
４．１．５  短いファイル名管理
４．２  レジストリ仮想化
４．２．１  レジストリキーオープン動作
４．２．２  レジストリキー削除動作
４．２．３  レジストリキー列挙動作
４．２．４  レジストリ作成動作
４．３  名前付きオブジェクト仮想化動作
４．４  ウィンドウ名仮想化
４．５  プロセス外ＣＯＭサーバ仮想化
４．６  仮想化されたファイルタイプ関連付け
４．７  分離環境間におけるプロセスの動的移動
（発明の詳細な説明）
（１．０  分離環境観念的概念）
（１．１  アプリケーション分離）
図２Ａを参照すると、アプリケーション互換性および社交性（ｓｏｃｉａｂｉｌｉｔｙ）の問題を低減したオペレーティングシステム１００の制御下で作動するコンピュータの一実施形態が示されている。オペレーティングシステム１００は、そのシステムレイヤ１０８を介して、様々なネイティブリソースをアプリケーションプログラム１１２、１１４で利用可能なようにする。システムレイヤ１０８によって具現化されるリソースのビューを、「システムスコープ」と呼ぶことにする。アプリケーションプログラム１１２、１１４によるネイティブリソース１０２、１０４、１０６、１０７へのアクセスと衝突するのを回避するために、分離環境２００が提供される。図２Ａに示すように、分離環境２００は、アプリケーション分離レイヤ２２０およびユーザ分離レイヤ２４０を含む。概念的には、分離環境２００は、アプリケーション分離レイヤ２２０を介して、ファイルシステム１０２、レジストリ１０４、オブジェクト１０６、およびウィンドウ名１０７等、ネイティブリソースの唯一のビューをアプリケーションプログラム１１２、１１４に提供する。各分離レイヤは、アプリケーションに提供されたネイティブリソースのビューを修正する。レイヤによって提供される、修正されたネイティブリソースのビューを、「分離スコープ」と称することにする。図２Ａに示すように、アプリケーション分離レイヤは、２つのアプリケーション分離スコープ２２２、２２４を含む。スコープ２２２はアプリケーション１１２に提供されたネイティブリソースのビューを表し、スコープ２２４はアプリケーション１１４に提供されたネイティブリソースのビューを表す。したがって、図２Ａに示す実施形態においては、ＡＰＰ１  １１２にはファイルシステム１０２’の特定のビューが提供され、一方ＡＰＰ２  １１４にはファイルシステム１０２’’の別のビューが提供される。いくつかの実施形態において、アプリケーション分離レイヤ２２０は、オペレーティングシステム１００の優位に立って実行する各個別のアプリケーションプログラムに、ネイティブリソース１０２、１０４、１０６、１０７の特定のビューを提供する。その他の実施形態において、アプリケーションプログラム１１２、１１４はセットにグループ化される場合があり、これらの実施形態において、アプリケーション分離レイヤ２２０はアプリケーションプログラムのセットごとにネイティブリソースの特定のビューを提供する。アプリケーションプログラムと衝突することによって別個のグループとなり、アプリケーションの互換性および社交性を高めることができる。またさらなる実施形態において、セットに属するアプリケーションを管理者が構成してもよい。いくつかの実施形態において、「パススルー」分離スコープは、システムスコープに厳密に対応するものであると定義できる。換言すると、パススルー分離スコープ内で実行するアプリケーションは、システムスコープにおいて直接動作する。
【００１７】
いくつかの実施形態において、アプリケーション分離スコープは、さらにレイヤ型サブスコープに分割される。主なサブスコープはベースアプリケーション分離スコープを含有し、付加的なサブスコープは、アプリケーションの多くの実行中のインスタンスに可視であり得るこのスコープへの様々な修正を含有する。例えば、サブスコープは、アプリケーションのパッチレベルの変更、または付加的な特徴のインストールもしくは除去を具現化するこのスコープへの修正を含有する場合がある。いくつかの実施形態において、実行中のアプリケーションのインスタンスに可視とされる付加的なサブスコープのセットを構成可能である。いくつかの実施形態において、どのユーザに代わってアプリケーションが実行しているかにかかわらず、当該可視であるサブスコープのセットは実行中のアプリケーションのインスタンスすべてについて同じである。その他において、可視であるサブスコープのセットは、アプリケーションを実行中の異なるユーザごとに変わる。また他の実施形態において、サブスコープの様々なセットが定義される場合があり、ユーザはどのセットを使用するかについて選択権を有することができる。いくつかの実施形態において、サブスコープは、必要なくなれば破棄してよい。いくつかの実施形態において、サブスコープのセットに含有される修正をマージして、単一のサブスコープを形成してもよい。
【００１８】
（１．２  ユーザ分離）
図２Ｂを参照すると、アプリケーション互換性およびアプリケーション社交性の問題を低減したマルチユーザコンピュータが描写されている。マルチユーザコンピュータは、つい先ほど論じた分離環境２００に加えて、システムレイヤ１０８にネイティブリソース１０２、１０４、１０６、１０７を含む。アプリケーション分離レイヤ２２０は、上述のように機能し、アプリケーションまたはアプリケーションのグループに、ネイティブリソースの修正されたビューを提供する。ユーザ分離レイヤ２４０は、概念的には、アプリケーションプログラム１１２、１１４に、アプリケーションがその代わりに実行されているユーザのユーザＩＤに基づいてさらに変更されたネイティブリソースのビューを提供する。図２Ｂに示すように、ユーザ分離レイヤ２４０は、多数のユーザ分離スコープ２４２’、２４２’’、２４２’’’、２４２’’’’、２４２’’’’’、２４２’’’’’’（概して２４２）を備えると考えることができる。ユーザ分離スコープ２４２は、ネイティブリソースのアプリケーション固有ビューのユーザ固有ビューを提供する。例えば、ユーザ「ａ」に代わってユーザセッション１１０において実行するＡＰＰ１  １１２には、ユーザ分離スコープ２４２’およびアプリケーション分離スコープ２２２の両方によって変更または修正されたファイルシステムビュー１０２’（ａ）が提供される。
【００１９】
言い換えれば、ユーザ分離レイヤ２４０は、アプリケーション分離スコープ２２２によって提供されたアプリケーション固有ビューの修正の「優位に立って」、ユーザ分離スコープ２４２’によって提供されたユーザ固有ビューの修正を「レイヤ化する」ことにより、各個人ユーザごとにネイティブリソースのビューを変更し、これが順に、システムレイヤによって提供されたネイティブリソースのシステム全体のビューの「上にレイヤ化」される。例えば、ＡＰＰ１  １１２の第１のインスタンスがレジストリデータベース１０４内のエントリにアクセスする場合、第１のユーザセッションおよびアプリケーション１０４’（ａ）に固有のレジストリデータベースのビューが調べられる。レジストリ１０４’（ａ）のユーザ固有のビューにおいて、要求されたレジストリキーが見つかれば、当該レジストリキーがＡＰＰ１  １１２に返される。見つからなければ、アプリケーション１０４’に固有のレジストリデータベースのビューが調べられる。レジストリ１０４’のアプリケーション固有のビューにおいて、要求されたレジストリキーが見つかれば、当該レジストリキーがＡＰＰ１  １１２に返される。見つからなければ、システムレイヤ１０８内のレジストリデータベース１０４に保存されたレジストリキー（すなわち、ネイティブレジストリキー）がＡＰＰ１  １１２に返される。
【００２０】
いくつかの実施形態において、ユーザ分離レイヤ２４０は、各個人ユーザごとに分離スコープを提供する。その他の実施形態において、ユーザ分離レイヤ２４０は、ユーザのグループごとに分離スコープを提供し、当該分離スコープは、組織内の役割によって定義されてもよいし、管理者によって予め定められてもよい。また他の実施形態において、ユーザ分離レイヤ２４０は提供されない。これらの実施形態において、アプリケーションプログラムによって見られるネイティブリソースのビューは、アプリケーション分離レイヤ２２０によって提供されるものである。分離環境２００は、様々なユーザによるアプリケーションプログラムの同時実行をサポートするマルチユーザコンピュータとの関連で説明されているが、異なるユーザによる同じコンピュータシステムでのアプリケーションプログラムの順次実行の結果生じるアプリケーション互換性および社交性の問題、ならびに、同じユーザによる互換性のないプログラムのインストールおよび実行の結果生じる問題に対処するために、シングルユーザコンピュータにおいて使用してもよい。
【００２１】
いくつかの実施形態において、ユーザ分離スコープは、さらにサブスコープに分割される。ユーザ分離スコープによる、当該スコープ内で実行中のアプリケーションに提示されたビューへの修正は、スコープ内の各サブスコープに含有される修正の集約である。サブスコープは互いの上にレイヤ化され、集約ビューにおいては、上位サブスコープ内のリソースへの修正が、下位レイヤ内の同じリソースへの修正の上に重なる。
【００２２】
これらの実施形態のいくつかにおいて、これらのサブスコープのうち１つ以上が、ユーザに固有であるビューへの修正を含有する場合がある。これらの実施形態のいくつかにおいて、１つ以上のサブスコープが、ユーザのセットに固有であるビューへの修正を含有する場合があり、当該修正は、システム管理者によって定義されてもよいし、オペレーティングシステムにおいてユーザのグループとして定義されてもよい。これらの実施形態のいくつかにおいて、これらのサブスコープの１つが、特定のログインセッションに固有であるビューへの修正を含有する場合があり、したがってセッション終了時に破棄される。これらの実施形態のいくつかにおいて、ユーザ分離スコープに関連するアプリケーションインスタンスによるネイティブリソースへの変更は、常にこれらのサブスコープのうち１つに影響を及ぼし、その他の実施形態において、それらの変更は、変更を加えられた特定のリソースに応じて異なるサブスコープに影響を及ぼし得る。
【００２３】
（１．３  ネイティブリソースの集約ビュー）
上述した概念アーキテクチャは、ユーザに代わって実行するアプリケーションに、集約または統一された、アプリケーションとユーザの組み合わせに固有であるネイティブリソースの仮想化されたビューを提示することを可能にする。この集約されたビューは、「仮想スコープ」と称される場合がある。ユーザに代わって実行するアプリケーションインスタンスには、動作しているすべての、ネイティブリソースの仮想化されたインスタンスを反映するネイティブリソースの単一のビューが提示される。概念的には、この集約されたビューはまず、システムスコープ内のオペレーティングシステムによって提供されたネイティブリソースのセットからなり、実行中のアプリケーションに適用可能なアプリケーション分離スコープにおいて具現化される修正によってオーバーレイされ、ユーザに代わって実行するアプリケーションに適用可能なユーザ分離スコープにおいて具現化される修正によってさらにオーバーレイされる。システムスコープ内のネイティブリソースは、オペレーティングシステムの許可が特定のユーザまたはアプリケーションへのアクセスを拒否する場所を除き、システム上の全てのユーザおよびアプリケーションに共通であることを特徴とする。アプリケーション分離スコープにおいて具現化されるリソースビューへの修正は、当該アプリケーション分離スコープに関連するアプリケーションのすべてのインスタンスに共通であるとして特徴付けられる。ユーザ分離スコープにおいて具現化されるリソースビューへの修正は、ユーザ分離スコープに関連するユーザに代わって実行する適用可能なアプリケーション分離スコープに関連するすべてのアプリケーションに共通であるとして特徴付けられる。
【００２４】
この概念はサブスコープにまで拡大することができ、ユーザサブスコープにおいて具現化されるリソースビューへの修正は、ユーザ分離サブスコープに関連するユーザまたはユーザのグループに代わって実行する適用可能な分離サブスコープに関連するすべてのアプリケーションに共通である。本明細書全体を通して、一般に「スコープ」に言及する際はいつでも、サブスコープが存在する場合には、それらにも言及していることを意図していることを理解すべきである。
【００２５】
アプリケーションが、ファイルシステムの一部またはレジストリデータベース等のネイティブリソースの列挙を要求すると、ネイティブリソースの「システムスコープ付き」インスタンス、すなわち、もしあれば、システムレイヤにおいて見つかったインスタンスをまず列挙することによって、仮想化された列挙が構築される。次に、要求されたリソースの「アプリケーションスコープ付き」インスタンス、すなわち、もしあれば、適切なアプリケーション分離スコープにおいて見つかったインスタンスが列挙される。アプリケーション分離スコープにおいて発見されたあらゆる列挙されたリソースが、ビューに追加される。列挙されたリソースが既にビュー内に存在する場合（システムスコープにも存在していたため）、アプリケーション分離スコープにおいて発見されたリソースのインスタンスで置換される。同様に、要求されたリソースの「ユーザスコープ付き」インスタンス、すなわち、もしあれば、適切なユーザ分離スコープにおいて見つかったインスタンスが列挙される。ここでも、ユーザ分離スコープにおいて発見されたあらゆる列挙されたリソースが、ビューに追加される。ネイティブリソースが既にビュー内に存在する場合（システムスコープまたは適切なアプリケーション分離スコープに存在していたため）、ユーザ分離スコープにおいて発見されたリソースのインスタンスで置換される。このようにして、ネイティブリソースのあらゆる列挙は、列挙されたネイティブリソースの仮想化を正確に反映することになる。概念的には、多くのサブスコープを備える分離スコープの列挙にも同じアプローチが当てはまる。個別のサブスコープは、下位サブスコープからの一致するインスタンスを置換する上位サブスコープからのリソースと共に集約ビュー内に列挙される。
【００２６】
その他の実施形態において、その逆よりもむしろ、ユーザ分離スコープからシステムレイヤへの列挙が行われる。これらの実施形態において、ユーザ分離スコープが列挙される。続いてアプリケーション分離スコープが列挙され、ユーザ分離スコープにおいて列挙されなかったアプリケーション分離スコープにおいて現われるあらゆるリソースインスタンスが、構築中の集約ビューに追加される。システムスコープにおいてのみ現われるリソースについて、同様のプロセスを繰り返してもよい。
【００２７】
また他の実施形態において、すべての分離スコープが一斉に列挙され、それぞれの列挙が組み合わされる場合がある。
【００２８】
アプリケーションが、ネイティブリソースを修正する意図なく当該リソースの既存インスタンスを開こうと試みる場合、アプリケーションに返される特定のインスタンスは、仮想スコープにおいて見つかったものであるか、または同等に、要求されたリソースの親の仮想化された列挙において現われ得るインスタンスである。分離環境の観点から、アプリケーションは「仮想リソース」を開くことを要求しているといわれており、当該要求を満たすために使用されるネイティブリソースの特定のインスタンスは、要求されたリソースに対応する「文字リソース」であるといわれている。
【００２９】
ユーザに代わって実行するアプリケーションがリソースを開こうと試み、当該リソースを修正する意図を持ってそうしていることを示す場合、当該アプリケーションインスタンスには通常、修正するために、その他のユーザに代わって実行するアプリケーションに共通であるアプリケーション分離スコープおよびシステムスコープ内のリソースとして、当該リソースのプライベートコピーが与えられる。一般的には、ユーザスコープ付きインスタンスが既に存在するのでない限り、リソースのユーザスコープ付きコピーが作られる。仮想スコープによって提供される集約ビューの定義は、アプリケーションスコープ付きまたはシステムスコープ付きリソースをユーザ分離スコープにコピーする行為が、問題のユーザおよびアプリケーション用、その他任意のユーザ用、またその他任意のアプリケーションインスタンス用の、仮想スコープによって提供される集約ビューに変更を加えないことを意味する。ユーザに代わって実行するアプリケーションインスタンスによるコピーされたリソースへの後の修正は、同じユーザ分離スコープを共有しない、その他任意のアプリケーションインスタンスの集約ビューに影響を及ぼさない。換言すると、それらの修正は、その他のユーザ用、または同じアプリケーション分離スコープに関連しないアプリケーションインスタンス用のネイティブリソースの集約ビューに変更を加えない。
【００３０】
（１．４  プロセスと分離スコープとの関連付け）
アプリケーションは、特定の分離スコープにインストールすることができる（以下でさらに詳細に説明する）。分離スコープにインストールされるアプリケーションは、常に当該スコープに関連付けられている。あるいは、アプリケーションは、特定の分離スコープ内、または多数の分離スコープ内に起動してよい。実際に、アプリケーションは、１つ以上の分離スコープに起動され、関連付けられる。関連付けられた分離スコープは、プロセスにネイティブリソースの特定のビューを提供する。アプリケーションは、システムスコープ内に起動してもよい、すなわち、分離スコープと関連付けなくてもよい。これにより、分離環境内において、第三者アプリケーションに加え、インターネットエクスプローラ等のオペレーティングシステムアプリケーションの選択的実行が可能になる。
【００３１】
アプリケーションがどこにインストールされているかにかかわらず分離スコープ内でアプリケーションを起動するこの能力は、分離スコープ内のアプリケーションを別個にインストールすることを必要とせずに、アプリケーション互換性および社交性の課題を緩和する。異なる分離スコープにおいて、インストールされたアプリケーションを選択的に起動する能力は、ヘルパーアプリケーション（Ｗｏｒｄ、Ｎｏｔｅｐａｄ等）を必要とするアプリケーションに、それらのヘルパーアプリケーションを同じルールセットによって起動させる能力を提供する。
【００３２】
さらに、多くの分離環境内でアプリケーションを起動する能力により、分離されたアプリケーションおよび共通アプリケーション間でのより良い統合が可能になる。
【００３３】
図２Ｃおよび概要を参照すると、プロセスを分離スコープと関連付けるための方法は、待機状態でプロセスを起動するステップ（ステップ２８２）を含む。望ましい分離スコープに関連するルールが検索され（ステップ２８４）、プロセスの識別子および検索されたルールはメモリ素子に保存され（ステップ２８６）、待機プロセスがレジュームされる（ステップ２８８）。プロセスによって行われるネイティブリソースにアクセスするための次のコールは傍受またはフックされ（ステップ２９０）、プロセス識別子に関連するルールは、もしあれば、要求されたリソースへのアクセスを仮想化するために使用される（ステップ２９２）。
【００３４】
図２Ｃをさらに詳細に参照すると、プロセスは待機状態で起動される（ステップ２８２）。いくつかの実施形態において、このタスクを実現するために、カスタムランチャプログラムが使用される。これらの実施形態のいくつかにおいて、ランチャは、選択された分離スコープ内にプロセスを起動するよう特別に設計される。その他の実施形態において、ランチャは、例えばコマンドラインオプションによって、望ましい分離スコープの仕様を入力として受け入れる。
【００３５】
望ましい分離スコープに関連するルールが検索される（ステップ２８４）。いくつかの実施形態において、ルールは、ハードディスクドライブまたはその他の固体メモリ素子等の永続的記憶素子から検索される。ルールは、リレーショナルデータベース、フラットファイルデータベース、木構造データベース、二分木構造、またはその他の永続的データ構造として保存される場合がある。その他の実施形態において、ルールは、それらを保存するよう特別に構成されたデータ構造に保存される場合がある。
【００３６】
プロセスＩＤ（ＰＩＤ）等のプロセスの識別子および検索されたルールは、メモリ素子に保存される（ステップ２８６）。いくつかの実施形態において、新規プロセス作成についてのオペレーティングシステムメッセージを受信するカーネルモードドライバが提供される。これらの実施形態において、ＰＩＤおよび検索されたルールは、ドライバのコンテキストに保存される場合がある。その他の実施形態において、ネイティブリソースの要求を傍受するファイルシステムフィルタドライバまたはミニフィルタが提供される。これらの実施形態において、ＰＩＤおよび検索されたルールは、フィルタに保存される場合がある。その他の実施形態において、すべての傍受はやはりユーザモードフッキングによって行われ、ＰＩＤは全く保存されない。ルールは、プロセス初期化中にユーザモードフッキング装置によってロードされ、ルールの関連付けは完全にプロセス中に行われるため、その他のコンポーネントがＰＩＤに当てはまるルールを知っている必要はない。
【００３７】
待機プロセスがレジュームされ（ステップ２８８）、プロセスによって行われるネイティブリソースにアクセスするための次のコールは傍受またはフックされ（ステップ２９０）、プロセス識別子に関連するルールは、もしあれば、要求されたリソースへのアクセスを仮想化するために使用される（ステップ２９２）。いくつかの実施形態において、ファイルシステムフィルタドライバまたはミニフィルタは、ネイティブリソースへのアクセスの要求を傍受し、傍受された要求に関連するプロセス識別子がルールのセットに関連付けられたか否かを判断する。関連付けられていれば、保存されたプロセス識別子に関連するルールはネイティブリソースへのアクセスの要求を仮想化するために使用される。関連付けられていなければ、ネイティブリソースへのアクセスの要求は無修正で通過する。その他の実施形態において、新規作成されたプロセスに動的リンクライブラリがロードされ、そのライブラリは分離ルールをロードする。また他の実施形態において、カーネルモード技術（フッキング、フィルタドライバ、ミニフィルタ）およびユーザモード技術のいずれも、ネイティブリソースにアクセスするためのコールを傍受するために使用される。ファイルシステムフィルタドライバがルールを保存している実施形態では、ライブラリがファイルシステムフィルタドライバからルールをロードすることができる。
【００３８】
分離スコープに関連するプロセスの「子」であるプロセスは、それらの「親」プロセスの分離スコープに関連する。いくつかの実施形態において、これは、子プロセスが作成された際にカーネルモードドライバがファイルシステムフィルタドライバに通知することによって実現される。これらの実施形態において、ファイルシステムドライバは、親プロセスのプロセス識別子が分離スコープに関連付けられているか否かを判定する。関連付けられていれば、ファイルシステムフィルタドライバは、新規作成された子プロセスのプロセス識別子と親プロセスの分離スコープとの間の関連付けを保存する。その他の実施形態において、ファイルシステムフィルタドライバは、カーネルモードドライバを使用することなく、システムから直接的にコールされることができる。その他の実施形態において、分離スコープに関連するプロセス中に、新規プロセスを作成するオペレーティングシステム機能がフックまたは傍受される。そのようなプロセスから新規プロセス作成の要求が受信されると、新規の子プロセスと親の分離スコープとの間の関連付けが保存される。
【００３９】
いくつかの実施形態において、スコープまたはサブスコープは、プロセス全体の代わりに個別のスレッドと関連する場合があり、これによりスレッドごとを基準に分離を行うことが可能になる。いくつかの実施形態において、スレッドごとの分離は、サービスおよびＣＯＭ＋サーバに使用される場合がある。
【００４０】
（１．４．１  スコープ外プロセスと分離スコープとの関連付け）
本発明の別の側面は、アプリケーションが、当該アプリケーション分離スコープ、別のアプリケーション分離スコープ、またはアプリケーション分離スコープ以外のいずれにインストールされたにかかわらず、任意のアプリケーションインスタンスを任意のアプリケーション分離スコープと関連付ける能力である。それでもやはり、特定のアプリケーションスコープにインストールされなかったアプリケーションは、それらのネイティブリソースが、ユーザ分離スコープ、アプリケーション分離スコープ、およびシステムスコープによって形成された集約仮想スコープを介して利用可能であるため、アプリケーション分離スコープおよび対応するユーザ分離スコープのコンテキストにおいて、ユーザに代わって実行されることができる。アプリケーションを分離スコープにおいて作動させることが望ましい場合、これは、システムスコープに直接的にインストールされたアプリケーションに、分離スコープ内でアプリケーションを別個にインストールすることを必要とせずに、分離スコープ内において作動する能力を提供する。これは、システムスコープに直接的にインストールされたアプリケーションに、任意の分離スコープのコンテキストにおいてヘルパーアプリケーションとして使用される能力も提供する。
【００４１】
実行中のアプリケーションを構成するすべてのプロセスを含む各アプリケーションインスタンスは、０または１つのアプリケーション分離スコープいずれか、拡大解釈すれば、厳密に０または１の対応するユーザ分離スコープと関連付けられる。この関連付けは、もしあれば、どのルールがリソース要求に当てはまるかを判定する際に、ルールエンジンによって使用される。この関連付けは、もしある場合、アプリケーションがインストールされたアプリケーション分離スコープのためのものである必要はない。分離スコープにインストールされた多くのアプリケーションは、必要なネイティブリソースを見つけることができないため、異なる分離スコープまたは分離スコープ以外で作動する際に正しく機能しない。しかしながら、分離スコープはシステムスコープを含むリソースビューの集約であるため、システムスコープにインストールされたアプリケーションは、概してアプリケーション分離スコープ内で正しく機能する。これは、プロセス外ＣＯＭサーバに加えて、ヘルパープログラムを、特定の分離スコープにおいてユーザに代わって実行するアプリケーションによって呼び出し、実行することができることを意味する。
【００４２】
いくつかの実施形態において、システムスコープにインストールされたアプリケーションは、この実行の結果として、コンピュータのファイルおよび構成設定にどのような変更が加えられたかを識別する目的で、分離スコープ内で実行される。ユーザ分離スコープにおいて分離される、すべての影響を受けたファイルおよび構成設定として、これらのファイルおよび構成設定は容易に識別可能である。これらの実施形態のいくつかにおいて、これは、アプリケーションによってファイルおよび構成設定に加えられた変更について報告するために使用される。いくつかの実施形態において、ファイルおよび構成設定はアプリケーション実行の終わりに削除され、これにより、アプリケーション実行の結果としてコンピュータのファイルおよび構成設定に加えられた変更が保存されていないことを効果的に確認する。また他の実施形態において、ファイルおよび構成設定はアプリケーション実行の終わりに選択的に削除されるか、または削除されず、これにより、アプリケーション実行の結果としてコンピュータのファイルおよび構成設定に加えられた変更がわずかに保存されていることを効果的に確認する。
【００４３】
（２．０  仮想化機構概念）
図３Ａを参照すると、以下のインストールモードとは区別される実行モードでネイティブリソースへのアクセスを仮想化するために取られるステップの一実施形態が示されている。概要において、ネイティブリソースへのアクセスの要求は、傍受または受信される（ステップ３０２）。要求は、アクセスが求められているネイティブリソースを識別する。受信したアクセス要求をどのように扱うかに関する適用可能なルールが判定される（ステップ３０４）。要求を無視すべきであることをルールが示す場合、アクセス要求は修正なくシステムレイヤに渡され（ステップ３０６）、結果が要求元に返される（ステップ３１０）。アクセス要求をリダイレクトまたは分離すべきであることをルールが示す場合、要求を満たすリソースの文字インスタンスが識別され（ステップ３０８）、修正された、または文字リソースの置換要求がシステムレイヤに渡され（ステップ３０６）、結果が要求元に返される（ステップ３１０）。
【００４４】
図３をさらに詳細に参照すると、ネイティブリソースを識別する要求は傍受または受信される（ステップ３０２）。いくつかの実施形態において、ネイティブリソースの要求は、オペレーティングシステムによってアプリケーションに提供される「フッキング」機能によって傍受され、ネイティブリソース要求を行う。特定の実施形態において、これは、オペレーティングシステムによって作成されたあらゆる新規プロセスのアドレス空間にロードされる動的リンクライブラリとして実装され、初期化ルーチン中にこれがフッキングを行う。あらゆるプロセスにＤＬＬをロードすることは、オペレーティングシステムによって提供される設備を介して、あるいは、プロセス用の実行可能なイメージがディスクからロードされる際に、ディスクファイルまたはメモリのいずれかにおいて、インポートするＤＤＬの実行可能なイメージのリストを修正することによって、達成できる。その他の実施形態において、フッキングする機能は、サービス、ドライバ、またはデーモンによって行われる。その他の実施形態において、オペレーティングシステムによって提供された、共有ライブラリおよび実行可能なファイルを含む実行可能なイメージは、フックする機能を提供するため、または本発明の論理を直接的に具現化するために、修正される、またはパッチを適用される場合がある。オペレーティングシステムがＭｉｃｒｏｓｏｆｔ  ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムファミリーのメンバーである特定の実施形態では、カーネルモードドライバがシステムサービスディスパッチテーブルをフックすることによって傍受が行われる。また他の実施形態において、オペレーティングシステムは、ネイティブリソースへのアクセスを要求する機能を第三者がフックすることを可能にする設備を提供することができる。これらの実施形態のいくつかにおいて、オペレーティングシステムは、アプリケーションプログラミングインターフェース（ＡＰＩ）またはデバッグ設備を介してこの設備を提供することができる。
【００４５】
その他の実施形態において、ネイティブリソース要求は、ネイティブリソースに関連するドライバスタックまたはハンドラスタック内のフィルタによって傍受される。例えば、Ｍｉｃｒｏｓｏｆｔ  ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムファミリーのいくつかのメンバーは、第三者フィルタドライバまたはミニフィルタをファイルシステムドライバスタックに接続する性能を提供し、ファイルシステムフィルタドライバまたはミニフィルタを使用して、以下で説明する分離機能を提供することができる。また他の実施形態において、本発明は、本発明の論理を直接的に組み込んだファイルシステム実装を含む。あるいは、オペレーティングシステムは、以下で説明する機能を直接的に提供するために書き換えられる場合がある。いくつかの実施形態において、上記に記載したリソースの要求を傍受または受信するための方法の一部またはすべての組み合わせは、一斉に用いることができる。
【００４６】
多くの実施形態において、実行中のネイティブリソースを開く、または新規のネイティブリソースを作成するための要求のみが、フックまたは傍受される。これらの実施形態において、ネイティブリソースへの初期アクセスは、リソースを仮想化させるアクセスである。初期アクセスの後、要求中のアプリケーションプログラムは、ハンドラもしくはポインタ、または、文字リソースを直接的に識別するオペレーティングシステムによって提供されたその他の識別子を使用して、仮想化されたリソースについてオペレーティングシステムと通信することができる。その他の実施形態において、仮想化されたネイティブリソースにおいて動作するための他の種類の要求も、フックまたは傍受される。これらの実施形態のいくつかにおいて、アプリケーションによる、仮想リソースを開くまたは作成する要求は、文字リソースを直接的に識別しない仮想ハンドルを返し、分離環境は、仮想ハンドルに対する次の要求を対応する文字リソースに翻訳する責任を負っている。それらの実施形態のいくつかにおいて、必要であると証明されるまで、付加的な仮想化動作を延期することができる。例えば、リソースの修正可能なプライベートコピーを分離スコープに提供する動作は、次の修正が可能なモードでリソースが開かれているときではなく、リソースを変更する要求が行われるまで延期することができる。
【００４７】
ネイティブリソース要求が傍受または受信されると、特定の要求をどのように扱うか判定する適用可能なルールが判定される（ステップ３０４）。ほとんどの適用可能なルールは、リストまたは木構造等の適切なデータ構造を使用して組織化されたルールを含有する、ルールエンジン、ルールのデータベース、またはフラットファイルを参照することにより、判定されることができる。いくつかの実施形態において、ルールは、２つ以上のルールが当てはまる場合に、どのルールが最も適用可能であると見なされるかを判定する優先権を与えられる。これらの実施形態のいくつかにおいて、ルール優先度は、ルール自体に含まれるか、あるいは、ルール優先度は、ルールを保存するために使用されるデータ構造に埋め込まれてよく、例えば、ルール優先度は、木構造におけるルールの位置によって示すことができる。判定されたルールは、例えば要求をリダイレクトするための文字リソース等、仮想化されたリソース要求をどのように処理するかに関する付加的な情報を含む場合がある。特定の実施形態において、ルールは、フィルタフィールド、アクションフィールド、およびデータフィールドを含む３つである。この実施形態において、フィルタフィールドは、受信したネイティブリソース要求を、要求されたリソース名にルールが有効であるか否か判定するよう適合させるために使用されるフィルタを含む。アクションフィールドは、「無視する」「リダイレクトする」または「分離する」であってよい。データフィールドは、ルールが有効である場合に使用される機能を含む、ルールが有効である場合に取られるアクションについての任意の付加的な情報であってよい。
【００４８】
ルールアクションの「無視する」は、システムスコープにおいて、要求されたネイティブリソースに要求が直接動作することを意味する。すなわち、要求は無変更でシステムレイヤ１０８へ渡され（ステップ３０６）、要求は分離環境２００が存在しないかのように遂行される。この場合、分離環境は「ホール」を有するといわれており、また、要求は「パススルー」要求と称される場合がある。
【００４９】
ネイティブリソース要求をリダイレクトまたは分離すべきであることをルールアクションが示すと、要求を満たす文字リソースが識別される（ステップ３０８）。
【００５０】
ルールアクションの「リダイレクトする」は、要求において特定されたものとは異なるリソースであるが、システムスコープ付きネイティブリソースに要求が直接動作することを意味する。文字リソースは、判定されたルールのデータフィールドにおいて特定された、またはそれによって暗示されたマッピング機能を、要求されたネイティブリソースの名前に適用することによって識別される。最も一般的な場合において、文字ネイティブリソースは、システムスコープ内のどこに位置してもよい。簡単な例として、ルール｛ｐｒｅｆｉｘ＿ｍａｔｃｈ（“ｃ：＼ｔｅｍｐ＼”，ｒｅｓｏｕｒｃｅ  ｎａｍｅ），ＲＥＤＩＲＥＣＴ，ｒｅｐｌａｃｅ＿ｐｒｅｆｉｘ（“ｃ：＼ｔｅｍｐ＼”，“ｄ：＼ｗｕｔｅｍｐ＼”，ｒｅｓｏｕｒｃｅ  ｎａｍｅ）｝は、要求されたファイルｃ：＼ｔｅｍｐ＼ｅｘａｍｐｌｅｓ＼ｄ１．ｔｘｔへのアクセスを、文字ファイルｄ：＼ｗｕｔｅｍｐ＼ｅｘａｍｐｌｅｓ＼ｄ１．ｔｘｔにリダイレクトする。ルールのデータフィールドに含まれるマッピング機能、およびマッチング機能は、例えば正規表現を使用して、複雑挙動をサポートするようにさらに一般化されることができる。いくつかの実施形態は、ユーザに代わって実行するアプリケーションに適用可能なユーザ分離スコープもしくはサブスコープ、またはアプリケーションに適用可能なアプリケーション分離スコープもしくはサブスコープ内に文字リソースを位置付けるマッピング機能を特定する能力を提供することができる。さらなる実施形態は、分離されたアプリケーション間の制御形態の対話を提供するために、異なるアプリケーションに適用可能なアプリケーション分離スコープ内に文字リソースを位置付けるマッピング機能を特定する能力を提供することができる。いくつかの特定の実施形態において、「リダイレクトする」アクションは、「無視する」ルールアクションに相当する挙動を提供するよう構成されてよい。これらの実施形態において、文字リソースは、厳密には要求されたネイティブリソースである。この状況が構成されている場合、分離環境は「ホール」を有するといわれており、また要求は「パススルー」要求と称される場合がある。
【００５１】
ルールアクションの「分離する」は、適切なユーザ分離スコープおよびアプリケーション分離スコープを使用して識別された文字リソースに要求が動作することを意味する。すなわち、文字リソースの識別子は、ユーザ分離スコープ、アプリケーション分離スコープ、両方のスコープを使用して、またはいずれのスコープも使用しないで、要求されたネイティブリソースの識別子を修正することにより、判定される。識別される特定の文字リソースは、要求されたアクセスの種類および要求されたネイティブリソースのいずれのインスタンスが適用可能なユーザ分離スコープ、適用可能なアプリケーション分離スコープ、およびシステムスコープ内に既に存在するかによって異なる。
【００５２】
図３Ｂは、リソースがそれを修正することを意図して開かれることを示す、ネイティブリソースを開くための要求が受信された際に、文字リソースを識別するために取られるステップ（図３Ａのステップ３０６）の実施形態を描写している。簡潔に言うと、要求されたネイティブリソースの、ユーザスコープ付きインスタンス、すなわち適用可能なユーザスコープまたはユーザサブスコープ内に存在するインスタンスが、存在するか否かの判定が行われる（ステップ３５４）。存在する場合、ユーザスコープ付きインスタンスは、要求用の文字リソースとして識別され（ステップ３７２）、当該インスタンスは開かれ、要求元に返される。ユーザスコープ付きインスタンスが存在しない場合、要求されたネイティブリソースのアプリケーションスコープ付きインスタンスが存在するか否かの判定が行われる（ステップ３５６）。アプリケーションスコープ付きインスタンスが存在する場合、「候補」リソースインスタンスとして識別され（ステップ３５９）、候補インスタンスの修正が許容されているか否かを判定するために、当該インスタンスに関連する許可データがチェックされる（ステップ３６２）。アプリケーションスコープ付きインスタンスが存在しない場合、要求されたネイティブリソースのシステムスコープ付きインスタンスが存在するか否かの判定が行われる（ステップ３５８）。存在しない場合、要求された仮想化リソースが仮想スコープに存在しないことを示すエラー状態が要求元に返される（ステップ３６０）。しかしながら、システムスコープ付きリソースが存在する場合、候補リソースインスタンスとして識別され（ステップ３６１）、候補インスタンスの修正が許容されているか否かを判定するために、当該インスタンスに関連する許可データがチェックされる（ステップ３６２）。許容されていない場合、仮想化リソースの修正が許容されていないことを示すエラー状態が要求元に返される（ステップ３６４）。候補リソースを修正してよいことを許可データが示す場合、ネイティブリソースの候補インスタンスのユーザスコープ付きコピーが作られ（ステップ３７０）、ユーザスコープ付きインスタンスは、要求用の文字リソースとして識別され（ステップ３７２）、開かれ、要求元に返される。
【００５３】
図３Ｂをさらに詳細に参照すると、ユーザスコープ付きリソースが存在するか否か、つまり換言すると、要求されたリソースが適用可能なユーザスコープまたはサブスコープに存在するか否かの判定が行われる（ステップ３５４）。適用可能なユーザスコープまたはサブスコープは、要求を行うアプリケーションに関連するアプリケーション分離スコープ上にレイヤ化されるユーザに関連するスコープである。ユーザ分離スコープまたはサブスコープは、ファイルシステムの場合、ユーザ分離スコープ内に存在するすべてのファイルが保存されるディレクトリであってよい。これらの実施形態のいくつかにおいて、ユーザ分離ディレクトリの下のディレクトリ木構造は、要求されたリソースのパスを反映している。例えば、要求されたファイルがｃ：＼ｔｅｍｐ＼ｔｅｓｔ．ｔｘｔであり、ユーザ分離スコープディレクトリがｄ：＼ｕｓｅｒ１＼ａｐｐ１＼である場合、ユーザスコープ付き文字ファイルへのパスは、ｄ：＼ｕｓｅｒ１＼ａｐｐ１＼ｃ＼ｔｅｍｐ＼ｔｅｓｔ．ｔｘｔであってよい。その他の実施形態において、ユーザスコープ付き文字ファイルへのパスは、ネイティブ命名規則において定義されてよい。例えば、ユーザスコープ付き文字ファイルへのパスは、ｄ：＼ｕｓｅｒ１＼ａｐｐ１＼ｄｅｖｉｃｅ＼ｈａｒｄｄｉｓｋ１＼ｔｅｍｐ＼ｔｅｓｔ．ｔｘｔであってよい。また他の実施形態において、ユーザスコープ付きファイルは唯一であるように選ばれた名前を持つ単一のディレクトリにすべて保存されてよく、データベースは、要求されたファイル名とディレクトリに保存されている対応する文字ファイルの名前との間のマッピングを保存するために使用されてよい。また他の実施形態において、文字ファイルの内容はデータベースに保存されてよい。また他の実施形態において、ネイティブファイルシステムは、個別に名付けられた多くの「ストリーム」を含有するための設備を単一のファイルに提供し、ユーザスコープ付きファイルの内容は関連ファイルの追加ストリームとしてシステムスコープに保存される。あるいは、文字ファイルは、ディスクの使用状況またはその他の関心の基準を最適化するように設計されることができるカスタムファイルシステムに保存されてよい。
【００５４】
ユーザスコープ付きリソースインスタンスが存在しない場合、アプリケーションスコープ付きリソースが存在するか否か、つまり換言すると、要求されたリソースがアプリケーションスコープに存在するか否かの判定が行われる（ステップ３５６）。上述の方法は、この判定を行うために使用される。例えば、要求されたファイルがｃ：＼ｔｅｍｐ＼ｔｅｓｔ．ｔｘｔであり、アプリケーション分離スコープディレクトリがｅ：＼ａｐｐ１＼，である場合、アプリケーションスコープ付きフィルへのパスは、ｅ：＼ａｐｐ１＼ｃ＼ｔｅｍｐ＼ｔｅｓｔ．ｔｘｔであってよい。上述のように、アプリケーションスコープ付きファイルへのパスは、ネイティブ命名規則に保存されてよい。上述の実施形態は、アプリケーション分離スコープにも当てはまる場合がある。
【００５５】
アプリケーションスコープ付きリソースが存在しない場合、システムスコープ付きリソースが存在するか否か、つまり換言すると、要求されたリソースがシステムスコープに存在するか否かの判定が行われる（ステップ３５８）。例えば、要求されたファイルがｃ：＼ｔｅｍｐ＼ｔｅｓｔ．ｔｘｔである場合、システムスコープ付きファイルへのパスはｃ：＼ｔｅｍｐ＼ｔｅｓｔ．ｔｘｔである。要求されたリソースがシステムスコープに存在しない場合、要求されたリソースは仮想スコープに存在しないという指示が要求元に返される（ステップ３６０）。
【００５６】
要求されたリソースの候補リソースインスタンスがアプリケーション分離スコープに位置していても、システムスコープに位置していても、候補リソースインスタンスの修正が許容されているか否かの判定は行われる（ステップ３６２）。例えば、候補ネイティブリソースインスタンスは、当該ユーザによる候補インスタンスの修正は許容されていないことを示す関連のネイティブ許可データを有してよい。さらに、ルールエンジンは、リソースの仮想化されたコピーのネイティブ許可データに従うか、またはそれを無効にするよう分離環境に命令する構成設定を含んでよい。いくつかの実施形態において、ルールは、例えばシステムスコープまたはアプリケーション分離スコープもしくはサブスコープ等、いくつかの仮想リソースに対し、修正が発生するスコープを特定してよい。いくつかの実施形態において、ルールエンジンは、アクセスされるリソースの階層または種類に基づいて、仮想化されたネイティブリソースのサブセットに当てはまる構成設定を特定することができる。これらの実施形態のいくつかにおいて、構成設定は、各アトミックネイティブリソースに固有である場合がある。別の例において、ルールエンジンは、実行可能なコードまたはオペレーティングシステムによって定義されるようなＭＩＭＥタイプもしくはファイルタイプ等、あるクラスのファイルの修正を禁止または許容する構成データを含んでよい。
【００５７】
ステップ３６２の判定が、候補リソースインスタンスの修正は許容されていないというものである場合、仮想リソースへの書き込みアクセスが許容されていないことを示すエラー状態が要求元に返される（ステップ３６４）。ステップ３６２の判定が、候補リソースインスタンスの修正は許容されているというものである場合、候補インスタンスは適切なユーザ分離スコープまたはサブスコープにコピーされる（ステップ３７０）。要求されたネイティブリソースの論理階層構造が分離スコープにおいて維持されている実施形態では、ユーザ分離スコープにリソースの候補インスタンスをコピーするには、階層プレースホルダのユーザ分離スコープにおける基準が必要である。階層プレースホルダは、コピーされたリソースを分離スコープ内において正しく位置付けるために階層に置かれたノードである。階層プレースホルダは、データを保存せず、プレースホルダノードとして識別され、要求元に返される文字リソースではあり得ないという意味で「存在しない」。いくつかの実施形態において、プレースホルダノードとしてのノードの識別は、ノード、もしくはノードの親、またはシステムレイヤ内のその他何らかの関連するエンティティに添付されたメタデータにその事実を記録することによって行われる。その他の実施形態において、プレースホルダノード名の別個のリポジトリが維持される。
【００５８】
いくつかの実施形態において、ルールは、特定のリソースへの修正を、アプリケーション分離スコープ等の特定のスコープにおいて行ってよいと特定することができる。それらの場合、ステップ３７０のコピー動作は、候補リソースインスタンスへの修正が、それが見つかったスコープまたはサブスコープにおいて許容されているか否かを判定するまで拡張される。許容されていない場合、候補リソースインスタンスは修正が許容されているスコープまたはサブスコープにコピーされるが、当該スコープは常にユーザ分離スコープでなくてもよく、新規のコピーは文字リソースインスタンスとして識別される（ステップ３７２）。許容されている場合、候補リソースインスタンスは文字インスタンスとして識別され（ステップ３７２）、開かれ、結果が要求元に返される（ステップ３０６）。
【００５９】
再度図３Ａを参照すると、文字リソースインスタンスは、ステップ３５４で位置していたかステップ３７０で作成されたかにかかわらず、開かれ（ステップ３０６）、要求元に返される（ステップ３１０）。いくつかの実施形態において、これは、オペレーティングシステムに対して「開く」コマンドを発行し、その「開く」コマンドに対するオペレーティングシステムからの応答を要求元に返すことによって実現される。
【００６０】
ユーザに代わって実行するアプリケーションがネイティブリソースを削除する場合、仮想スコープとして当該アプリケーションに提示されているネイティブリソースの集約ビューはその削除を反映しなくてはならない。リソースを削除する要求は、その存在を完全に除去することによってリソースを修正するものであるが、特別な種類の修正の要求である。概念的には、リソースを削除する要求は、図３Ｂで概説したような文字リソースの判定を含み、図３Ａにおいて概説したものと同様の方式で進む。しかしながら、ステップ３０６は、分離されたリソースに対しておよびリダイレクトまたは無視されたリソースに対して異なる動作をする。リダイレクトおよび無視の場合、文字リソースはシステムスコープから削除される。分離の場合、文字リソースは「事実上」削除される、つまり換言すると、それが削除されたという事実がユーザ分離スコープに記録される。削除されたノードはデータを含有せず、削除されたものとして識別され、当該ノードおよびその子孫は「存在しない」。換言すると、他にリソース要求を満たすのがリソースまたはリソースの祖先（ａｎｃｅｓｔｏｒ）である場合、「リソースが見つかりません」エラーが要求元に返される。さらなる詳細は、第４節において概説する。いくつかの実施形態において、削除されたノードとしてのノードの識別は、ノード、もしくはノードの親、またはシステムレイヤ内のその他何らかの関連するエンティティに添付されたメタデータにその事実を記録することによって行われる。その他の実施形態において、削除されたノード名の別個のリポジトリが、例えば別個のサブスコープ内において、維持される。
【００６１】
（３．０  分離環境へのインストール）
上述したアプリケーション分離スコープは、関連するアプリケーションインスタンスが、いかなるユーザとも無関係に、または同等に、すべての考えられるユーザに代わって、それらのアプリケーションインスタンスが作成するリソースを含むリソースを共有するスコープとして考えることができる。該当するリソースの主要なクラスは、アプリケーションがオペレーティングシステムにインストールされる際に作成されたセットである。図１Ａに示すように、互換性のない２つのアプリケーションを両方同じシステムスコープにインストールすることはできないが、それらのアプリケーションのうち少なくとも１つを分離環境にインストールすることにより、この問題は解決できる。
【００６２】
分離スコープ、または分離スコープに関連するアプリケーションインスタンスは、アプリケーションのインストールをサポートするために「インストールモード」で動作できる。これは、図４〜１６に関連して以下で説明する「実行モード」と対照的である。インストールモードにおいて、アプリケーションインストールプログラムはアプリケーション分離スコープに関連付けられ、すべてのユーザに代わって実行していると推測される。アプリケーション分離スコープは、当該アプリケーションインスタンスに対して「すべてのユーザ」のユーザ分離スコープであるかのように作用し、ユーザ分離スコープは当該アプリケーションインスタンスに対してアクティブではない。
【００６３】
図３Ｃは、リソースがそれを修正することを意図して開かれることを示す、ネイティブリソースを開くための要求が受信された際に、文字リソースを識別するためにインストールモードで取られるステップの一実施形態を描写している。簡潔に言うと、アクティブなユーザ分離スコープがない場合、要求されたネイティブリソースのアプリケーションスコープ付きインスタンスが存在するか否かの判定がまず行われる（ステップ３７４）。アプリケーションスコープ付きインスタンスが存在する場合、当該インスタンスは文字リソースインスタンスとして識別される（ステップ３８４）。アプリケーションスコープ付きインスタンスが存在しない場合、要求されたリソースのシステムスコープ付きインスタンスが存在するか否かの判定が行われる。（ステップ３７６）。存在しない場合、要求された仮想化リソースが仮想スコープに存在しないことを示すエラー状態が要求元に返される（ステップ３７７）。しかしながら、システムスコープ付きリソースが存在する場合、候補リソースインスタンスとして識別され（ステップ３７８）、候補インスタンスの修正が許容されているか否かを判定するために、当該インスタンスに関連する許可データがチェックされる（ステップ３８０）。許容されていない場合、仮想化リソースの修正が許容されていないことを示すエラー状態が要求元に返される（ステップ３８１）。候補リソースを修正してよいことを許可データが示す場合、アクティブであるユーザ分離スコープがないので、ネイティブリソースの候補インスタンスのアプリケーションスコープ付きコピーが作られ（ステップ３８２）、アプリケーションスコープ付きインスタンスは要求用の文字インスタンスとして識別される（ステップ３８４）。いくつかの実施形態において、候補ファイルはルールエンジンによって定義された位置にコピーされる。例えば、ルールは、ファイルがアプリケーション分離スコープにコピーされると特定することができる。その他の実施形態において、ルールは、ファイルをコピーすべき特定のアプリケーション分離サブスコープまたはユーザ分離サブスコープを特定することができる。ファイルがコピーされる分離スコープに現われない要求されたファイルのあらゆる祖先は、コピーされたインスタンスを階層に正しく位置付けるために、分離スコープにおいてプレースホルダとして作成される。
【００６４】
図３Ｄは、ネイティブリソースを作成するための要求が受信された際に、文字リソースを識別するためにインストールモードで取られるステップの一実施形態を示す。簡潔に言うと、アクティブなユーザ分離スコープがない場合、要求されたネイティブリソースのアプリケーションスコープ付きインスタンスが存在するか否かの判定がまず行われる（ステップ３９０）。アプリケーションスコープ付きインスタンスが存在する場合、リソースは既に存在するため作成できないことを示すエラー状態が要求元に返され得る（ステップ３９２）。アプリケーションスコープ付きインスタンスが存在しない場合、要求されたネイティブリソースのシステムスコープ付きインスタンスが存在するか否かの判定が行われる（ステップ３９４）。システムスコープ付きインスタンスが存在する場合、リソースは既に存在するため作成できないことを示すエラー状態が要求元に返され得る（ステップ３９２）。いくつかの実施形態において、リソースを開くために使用される要求は、リソースの現存する任意のシステムスコープ付きインスタンスは上書きされ得ることを特定する場合がある。システムスコープ付きリソースインスタンスが存在しない場合、アプリケーションスコープ付きリソースインスタンスは、要求を遂行するために作成される文字インスタンスとして識別され得る（ステップ３９６）。
【００６５】
図３Ｂを図３Ｃおよび３Ｄと比較すると、インストールモードは実行モードと同様に動作し、アプリケーション分離スコープがユーザ分離スコープに取って代わるものであることがわかる。換言すると、新規リソースの作成を含む永久的リソースへの変更は、適切なユーザ分離スコープの代わりに適切なアプリケーション分離スコープにおいて行われる。さらに、分離された既存リソースへのアクセスの仮想化は、適切なユーザ分離スコープを無視し、アプリケーション分離スコープにおいて候補文字リソースを探索し始める。
【００６６】
既存リソースへの修正および新規リソースの作成を含有するためにアプリケーション分離スコープがこの方式で動作する他の２つの場合がある。第一に、ユーザ分離レイヤなしに動作するよう構成された分離環境、またはユーザ分離スコープなしに動作するよう構成された仮想スコープがあってよい。この場合、アプリケーション分離スコープは、修正されたリソースと新規作成されたリソースを分離できる唯一の分離スコープである。第二に、仮想リソースの特定のセットを規定するルールは、それらが適切なユーザ分離スコープではなく適切なアプリケーション分離スコープへ分離されることを特定する場合がある。この場合も、これは、当該ルールに支配されるリソースへの修正およびリソースの作成が、それらのアプリケーションインスタンスを実行しているユーザにのみ可視であるユーザ分離スコープではなく、アプリケーション分離スコープを共有するすべてのアプリケーションインスタンスに可視である適切な当該スコープへ分離されることを意味する。
【００６７】
また他の実施形態において、分離環境は、あるリソースをシステムスコープにおいて共有できるように構成されてよい、すなわち、分離環境は、１つ以上のシステムリソースに対して、ユーザ分離スコープもアプリケーション分離スコープも存在しないかのように作用し得る。システムスコープにおいて共有されるシステムリソースは、すべてのアプリケーションおよびすべてのユーザによって共有される、すなわち、グローバルオブジェクトであるため、修正する目的でアクセスされる際には決してコピーされない。
【００６８】
（４．０  仮想化の詳細例）
上述の方法および装置は、多種多様なネイティブリソース１０８を仮想化するために使用され得る。これらのうち多数を以下で詳細に説明する。
【００６９】
（４．１  ファイルシステム仮想化）
上述の方法および装置は、ファイルシステムへのアクセスを仮想化するために使用され得る。上述のように、ファイルシステムは通常、それ自体がファイルであり、その他のディレクトリおよびデータファイルを含有し得る、ディレクトリの論理階層に組織化されている。
【００７０】
（４．１．１  ファイルシステムオープン動作）
概要において、図４は、上述の仮想化環境においてファイルを開くために取られるステップの一実施形態を描写している。ファイルを開くための要求が受信または傍受される（ステップ４０２）。要求は、分離環境によって仮想ファイル名として扱われるファイル名を含有する。ファイルシステムオープン要求のターゲットに適用可能な処理ルールが判定される（ステップ４０４）。ルールアクションが「リダイレクトする」である場合（ステップ４０６）、要求中に提供された仮想ファイル名は、適用可能なルールに従って文字ファイル名にマップされる（ステップ４０８）。文字ファイル名を使用して文字ファイルを開くための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ４１０）。そうではなく、ルールアクションが「無視する」である場合（ステップ４０６）、文字ファイル名は厳密には仮想ファイル名であると判定され（ステップ４１２）、文字ファイルを開くための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ４１０）。ステップ４０６において、ルールアクションが「分離する」である場合、ユーザ分離スコープ内の仮想ファイル名に対応するファイル名が候補ファイル名として識別される（ステップ４１４）。換言すると、候補ファイル名は、適用可能なユーザ分離スコープに固有の対応するネイティブファイル名に仮想ファイル名をマップすることによって形成される。候補ファイルが存在するカテゴリは、ユーザ分離スコープおよび候補ファイルに関連する任意のメタデータを調査することによって判定される（ステップ４１６）。候補ファイルが「否定的存在」を有すると判定された場合、当該候補ファイルまたはユーザ分離スコープ内にあるその祖先ディレクトリの１つのいずれかが削除されたものとしてマークされているため、これは要求された仮想ファイルが存在しないと分かっていることを意味する。この場合、要求されたファイルが見つからないことを示すエラー状態が要求元に返される（ステップ４２２）。そうではなく、ステップ４１６において候補ファイルが「肯定的存在」を有すると判定された場合、候補ファイルはユーザ分離スコープに存在しており、プレースホルダノードとしてマークされていないため、要求された仮想ファイルは存在すると分かっている。候補ファイルは、要求に対する文字ファイルとして識別され（ステップ４１８）、文字ファイルを開くために要求が発行され、結果が要求元に返される（ステップ４２０）。しかしながら、ステップ４１６において、候補ファイルが「中立的存在」を有する場合、候補ファイルは存在しないため、または候補ファイルは存在するがプレースホルダノードとしてマークされているため、仮想ファイルが存在するか否かはまだ分かっていない。この場合、仮想ファイル名に対応するアプリケーションスコープ付きファイル名は、候補ファイル名として識別される（ステップ４２４）。換言すると、候補ファイル名は、適用可能なアプリケーション分離スコープに固有の対応するネイティブファイル名に仮想ファイル名をマップすることによって形成される。候補ファイルが存在するカテゴリは、アプリケーション分離スコープおよび候補ファイルに関連する任意のメタデータを調査することによって判定される（ステップ４２６）。候補ファイルが「否定的存在」を有すると判定された場合、当該候補ファイルまたはアプリケーション分離スコープ内にあるその祖先ディレクトリの１つのいずれかが削除されたものとしてマークされているため、これは要求された仮想ファイルが存在しないと分かっていることを意味する。この場合、要求されたファイルが見つからないことを示すエラー状態が要求元に返される（ステップ４２２）。そうではなく、ステップ４２６において候補ファイルが「肯定的存在」を有すると判定された場合、候補ファイルはアプリケーション分離スコープに存在しており、プレースホルダノードとしてマークされていないため、要求された仮想ファイルは存在すると分かっている。オープン要求がファイルを修正する意図を示しているか否かを判定するために、要求はチェックされる（ステップ４２８）。示していない場合、候補ファイルは要求に対する文字ファイルとして識別され（ステップ４１８）、文字ファイルを開くために要求が発行され、結果が要求元に返される（ステップ４２０）。しかしながら、ステップ４２８において、オープン要求がファイルを修正する意図を示していると判定された場合、ファイルの修正が許容されているか否かを判定するために、ファイルに関連する許可データがチェックされる（ステップ４３６）。許容されていない場合、ファイルの修正が許容されていないことを示すエラー状態が要求元に返される（ステップ４３８）。ファイルを修正してよいことを許可データが示す場合、候補ファイルはユーザ分離スコープにコピーされる（ステップ４４０）。いくつかの実施形態において、候補ファイルはルールエンジンによって定義された位置にコピーされる。例えば、ルールは、ファイルがアプリケーション分離スコープにコピーされると特定することができる。その他の実施形態において、ルールは、ファイルをコピーすべき特定のアプリケーション分離サブスコープまたはユーザ分離サブスコープを特定することができる。ファイルがコピーされる分離スコープに現われない要求されたファイルのあらゆる祖先は、コピーされたインスタンスを階層に正しく位置付けるために、分離スコープにおいてプレースホルダとして作成される。スコープ付きインスタンスは文字ファイルとして識別され（ステップ４４２）、文字ファイルを開くために要求が発行され、結果が要求元に返される（ステップ４２０）。ステップ４２６に戻って、候補ファイルが中立的存在を有する場合、候補ファイルは存在しないため、または候補ファイルは見つかったがプレースホルダノードとしてマークされているため、仮想ファイルが存在するか否かはまだ分かっていない。この場合、仮想ファイル名に対応するシステムスコープ付きファイル名は、候補ファイル名として識別される（ステップ４３０）。換言すると、候補ファイル名は厳密には仮想ファイル名である。候補ファイルが存在しない場合（ステップ４３２）、仮想ファイルが見つからなかったことを示すエラー状態が要求元に返される（ステップ４３４）。一方、候補ファイルが存在する場合（ステップ４３２）、オープン要求がファイルを修正する意図を示しているか否かを判定するために、要求はチェックされる（ステップ４２８）。示していない場合、候補ファイルは要求に対する文字ファイルとして識別され（ステップ４１８）、文字ファイルを開くために要求が発行され、結果が要求元に返される（ステップ４２０）。しかしながら、ステップ４２８において、オープン要求がファイルを修正する意図を示していると判定された場合、ファイルの修正が許容されているか否かを判定するために、ファイルに関連する許可データがチェックされる（ステップ４３６）。許容されていない場合、ファイルの修正が許容されていないことを示すエラー状態が要求元に返される（ステップ４３８）。ファイルを修正してよいことを許可データが示す場合、候補ファイルはユーザ分離スコープにコピーされる（ステップ４４０）。いくつかの実施形態において、候補ファイルはルールエンジンによって定義された位置にコピーされる。例えば、ルールは、ファイルがアプリケーション分離スコープにコピーされると特定することができる。その他の実施形態において、ルールは、ファイルをコピーすべき特定のアプリケーション分離サブスコープまたはユーザ分離サブスコープを特定することができる。分離スコープに現われない要求されたファイルのあらゆる祖先は、コピーされたインスタンスを階層に正しく位置付けるために、分離スコープにおいてプレースホルダとして作成される。スコープ付きインスタンスは、文字ファイルとして識別され（ステップ４４２）、文字ファイルを開くために要求が発行され、結果が要求元に返される（ステップ４２０）。
【００７１】
この実施形態は、ファイルを開くのではなく、ファイルの存在のチェックを行うように、修正をしてよいことが自明である。ステップ４２０の文字ファイルを開く試みは、当該文字ファイルの存在および要求元に返される状態のチェックに置換される。
【００７２】
ここで図４をさらに詳細に参照すると、仮想ファイルを開くための要求が受信または傍受される（ステップ４０２）。対応する文字ファイルは、ユーザ分離スコープ、アプリケーション分離スコープ、またはシステムスコープのものであってよく、または、アプリケーション分離サブスコープまたはユーザ分離サブスコープに範囲付けてもよい。いくつかの実施形態において、要求は、ファイルを開くためのオペレーティングシステム機能を置換する機能によってフックされる。別の実施形態において、要求を傍受するためにフッキング動的リンクライブラリが使用される。フッキング機能は、ユーザモードまたはカーネルモードで実行することができる。フッキング機能がユーザモードで実行する実施形態では、フッキング機能は、プロセスが作成される際に当該プロセスのアドレス空間にロードされてよい。フッキング機能がカーネルモードで実行する実施形態では、フッキング機能は、ネイティブファイルの要求をディスパッチするのに使用されるオペレーティングシステムリソースと関連付けられてよい。ファイル動作の種類ごとに別個のオペレーティングシステム機能が提供される実施形態では、各機能は別個にフックされてよい。あるいは、数種類のファイル動作の作成コールまたはオープンコールを傍受する単一のフッキング機能を提供してよい。
【００７３】
要求は、分離環境によって仮想ファイル名として扱われるファイル名を含有する。ルールエンジンを調べることによって、ファイルシステムオープン要求に適用可能な処理ルールが判定される（ステップ４０４）。いくつかの実施形態において、オープン要求に適用可能な処理ルールは、そのオープン要求に含まれる仮想名を使用して判定される。いくつかの実施形態において、ルールエンジンは、リレーショナルデータベースとして提供される場合がある。その他の実施形態において、ルールエンジンは、木構造データベース、ハッシュテーブル、またはフラットファイルデータベースであってよい。いくつかの実施形態において、要求されたファイルに提供された仮想ファイル名は、要求に当てはまる１つ以上のルールをルールエンジン内に位置付けるための索引として使用される。これらの実施形態のうち特定のものにおいて、特定のファイルのルールエンジンに多くのルールが存在する場合があり、これらの実施形態において、仮想ファイル名と一致する最も長い接頭辞を有するルールは、要求に適用されるルールである。その他の実施形態において、プロセス識別子は、存在する場合、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。要求に関連するルールは、要求を無視すること、要求をリダイレクトすること、または要求を分離することであってよい。図４では単一のデータベーストランザクションまたは単一のファイル内検索として示されているが、ルール検索は一連のルール検索として行われてもよい。
【００７４】
ルールアクションが「リダイレクトする」である場合（ステップ４０６）、要求中に提供された仮想ファイル名は、適用可能なルールに従って文字ファイル名にマップされる（ステップ４０８）。文字ファイル名によって識別された文字ファイルを開くための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ４１０）。例えば、「ｆｉｌｅ＿１」と名付けられたファイルを開くための要求により、「Ｄｉｆｆｅｒｅｎｔ＿ｆｉｌｅ＿１」と名付けられた文字ファイルを開くことができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。ファイルシステムフィルタドライバを使用する実施形態では、仮想名を使用してファイルを開くための第１の要求により、ファイルシステムフィルタドライバから、判定された文字名を示すＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答を返すことになる。次に、Ｉ／Ｏマネージャは、ＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答に含む判定された文字名を持つファイルオープン要求を再発行する。
【００７５】
そうではなく、ルールアクションが「無視する」である場合（ステップ４０６）、文字ファイル名は厳密には仮想ファイル名であると判定され（ステップ４１２）、文字ファイルを開くための要求がオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ４１０）。例えば、「ｆｉｌｅ＿１」と名付けられたファイルを開くための要求により、「ｆｉｌｅ＿１」と名付けられた実際のファイルを開くことになる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。
【００７６】
ステップ４０６において、ルールアクションが「分離する」である場合、仮想ファイル名に対応するユーザスコープ付きファイル名が候補ファイル名として識別される（ステップ４１４）。換言すると、候補ファイル名は、適用可能なユーザ分離スコープに固有の対応するネイティブファイル名に仮想ファイル名をマップすることによって形成される。例えば、「ｆｉｌｅ＿１」と名付けられたファイルを開くための要求により、「Ｉｓｏｌａｔｅｄ＿ｆｌｌｅ＿１」と名付けられた実際のファイルを開くことができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。ファイルシステムフィルタドライバを使用する実施形態では、仮想名を使用してファイルを開くための第１の要求により、ファイルシステムフィルタドライバから、判定された文字名を示すＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答を返すことになる。次に、Ｉ／Ｏマネージャは、ＲＥＰＡＲＳＥ応答に含む判定された文字名を持つファイルオープン要求を再発行する。
【００７７】
いくつかの実施形態において、要求されたシステムファイルを分離するために形成された文字名は、受信した仮想ファイル名およびスコープ固有の識別子に基づくものであってよい。スコープ固有の識別子は、アプリケーション分離スコープ、ユーザ分離スコープ、セッション分離スコープ、アプリケーション分離サブスコープ、ユーザ分離サブスコープ、または上記のいくつかの組み合わせに関連する識別子であってよい。スコープ固有の識別子は、要求中に受信した仮想名を「マングルする」ために使用される。
【００７８】
その他の実施形態において、ユーザ分離スコープまたはサブスコープは、ユーザ分離スコープ内に存在するすべてのファイルが保存されるディレクトリであってよい。これらの実施形態のいくつかにおいて、ユーザ分離ディレクトリの下のディレクトリ木構造は、要求されたリソースのパスを反映している。換言すると、文字ファイルパスは、仮想ファイルパスをユーザ分離スコープにマップすることによって形成される。例えば、要求されたファイルがｃ：＼ｔｅｍｐ＼ｔｅｓｔ．ｔｘｔであり、ユーザ分離スコープディレクトリがｄ：＼ｕｓｅｒ１＼ａｐｐ１＼である場合、ユーザスコープ付き文字ファイルへのパスは、ｄ：＼ｕｓｅｒ１＼ａｐｐ１＼ｃ＼ｔｅｍｐ＼ｔｅｓｔ．ｔｘｔであってよい。その他の実施形態において、ユーザスコープ付き文字へのパスは、ネイティブ命名規則において定義されてよい。例えば、ユーザスコープ付き文字ファイルへのパスは、ｄ：＼ｕｓｅｒｌ＼ａｐｐ１＼ｄｅｖｉｃｅ＼ｈａｒｄｄｉｓｋ１＼ｔｅｍｐ＼ｔｅｓｔ．ｔｘｔであってよい。また他の実施形態において、ユーザスコープ付きファイルは、唯一であるように選ばれた名前を持つ単一のディレクトリにすべて保存されてよく、データベースは、要求されたファイル名とディレクトリに保存されている対応する文字ファイルの名前との間のマッピングを保存するために使用されてよい。また他の実施形態において、文字ファイルの内容はデータベースに保存されてよい。また他の実施形態において、ネイティブファイルシステムは、個別に名付けられた多くの「ストリーム」を含有するための設備を単一のファイルに提供し、ユーザスコープ付きファイルの内容は関連ファイルの追加ストリームとしてシステムスコープに保存される。あるいは、文字ファイルは、ディスクの使用状況またはその他の関心の基準を最適化するように設計されることができるカスタムファイルシステムに保存されてよい。
【００７９】
候補ファイルが存在するカテゴリは、ユーザ分離スコープおよび候補ファイルに関連する任意のメタデータを調査することによって判定される（ステップ４１６）。候補ファイルが「否定的存在」を有すると判定された場合、当該候補ファイルまたはユーザ分離スコープ内にあるその祖先ディレクトリの１つのいずれかが削除されたものとしてマークされているため、これは要求された仮想ファイルが存在しないと分かっていることを意味する。この場合、要求されたファイルが見つからないことを示すエラー状態が要求元に返される（ステップ４２２）。
【００８０】
いくつかの実施形態において、ファイルについての少量のメタデータが、仮想名にメタデータ識別子で接尾辞を付ける等によって文字ファイル名に直接的に保存されてよく、ここでメタデータ識別子は特定のメタデータ状態に一意に関連する文字列である。メタデータ識別子は、１または数ビットのメタデータを示す、または符号化することができる。メタデータ識別子の存在による文字ファイル名の考えられる変形に関する仮想ファイル名チェックによってファイルにアクセスするための要求、およびファイル名自体を検索するための要求は、文字名で応答するためにフックまたは傍受される。その他の実施形態において、ファイルの１つ以上の代替名が仮想ファイル名およびメタデータ識別子から形成されてよく、ファイルシステムによって提供されたハードリンクまたはソフトリンク設備を使用して作成されてよい。これらのリンクの存在は、リンクの名前を使用してアクセスのための要求が与えられる場合、分離環境によってファイルが見つからないことを示すことにより、アプリケーションから隠される。特定のリンクの有無は各メタデータ識別子につき１ビットのメタデータを示してよく、または、数ビットのメタデータを示すために多くの状態を呈することができるメタデータ識別子とのリンクがあってよい。また他の実施形態において、ファイルシステムが代替ファイルストリームをサポートする場合、メタデータを具現化するために代替ファイルストリームが作成されてよく、そのストリームのサイズは数ビットのメタデータを示す。また他の実施形態において、ファイルシステムは、ファイルシステム内の各ファイルに、いくつかの第三者メタデータを保存する能力を直接的に提供する。
【００８１】
これらの実施形態のうち特異のものにおいて、削除されたファイルまたはファイルシステム要素のリストは、この削除されたファイルに関するチェックを最適化するために維持され調べられてよい。これらの実施形態において、削除されたファイルが再作成されると、ファイル名は削除されたファイルのリストから除去されてよい。これらの実施形態のうちのその他において、リストが一定サイズを超えた場合、ファイル名はリストから除去されてよい。
【００８２】
そうではなく、ステップ４１６において候補ファイルが「肯定的存在」を有すると判定された場合、候補ファイルはユーザ分離スコープに存在しており、プレースホルダノードとしてマークされていないため、要求された仮想ファイルは存在すると分かっている。候補ファイルは要求に対する文字ファイルとして識別され（ステップ４１８）、文字ファイルを開くために要求が発行され、結果が要求元に返される（ステップ４２０）。
【００８３】
しかしながら、ステップ４１６において、候補ファイルが「中立的存在」を有する場合、候補ファイルは存在しないため、または候補ファイルは存在するがプレースホルダノードとしてマークされているため、仮想ファイルが存在するか否かはまだ分かっていない。この場合、仮想ファイル名に対応するアプリケーションスコープ付きファイル名は、候補ファイル名として識別される（ステップ４２４）。換言すると、候補ファイル名は、適用可能なアプリケーション分離スコープに固有の対応するネイティブファイル名に仮想ファイル名をマップすることによって形成される。候補ファイルが存在するカテゴリは、アプリケーション分離スコープおよび候補ファイルに関連する任意のメタデータを調査することによって判定される（ステップ４２６）。
【００８４】
アプリケーションスコープ付き候補ファイルが「否定的存在」を有すると判定された場合、当該候補ファイルまたはアプリケーション分離スコープ内にあるその祖先ディレクトリの１つのいずれかが削除されたものとしてマークされているため、これは要求された仮想ファイルが存在しないと分かっていることを意味する。この場合、要求されたファイルが見つからないことを示すエラー状態が要求元に返される（ステップ４２２）。
【００８５】
ステップ４２６において候補ファイルが「肯定的存在」を有すると判定された場合、候補ファイルはアプリケーション分離スコープに存在しており、プレースホルダノードとしてマークされていないため、要求された仮想ファイルは存在すると分かっている。オープン要求がファイルを修正する意図を示しているか否かを判定するために、要求はチェックされる（ステップ４２８）。示していない場合、候補ファイルは要求に対する文字ファイルとして識別され（ステップ４１８）、文字ファイルを開くために要求が発行され、結果が要求元に返される（ステップ４２０）。
【００８６】
しかしながら、ステップ４２８において、オープン要求がファイルを修正する意図を示していると判定された場合、ファイルの修正が許容されているか否かを判定するために、ファイルに関連する許可データがチェックされる（ステップ４３６）。いくつかの実施形態において、許可データはアプリケーションスコープ付き候補ファイルと関連付けられる。これらの実施形態のいくつかにおいて、許可データは、ルールエンジンに、または、候補ファイルに関連するメタデータに保存される。その他の実施形態において、候補ファイルに関連する許可データがオペレーティングシステムによって提供される。さらに、ルールエンジンは、リソースの仮想化されたコピーのネイティブ許可データに従うか、またはそれを無効にするよう分離環境に命令する構成設定を含んでよい。いくつかの実施形態において、ルールは、例えばシステムスコープまたはアプリケーション分離スコープもしくはサブスコープ、またはユーザ分離スコープもしくはサブスコープ等、いくつかの仮想リソースに対し、修正が発生するスコープを特定してよい。いくつかの実施形態において、ルールエンジンはアクセスされるリソースの階層または種類に基づいて、仮想化されたネイティブリソースのサブセットに当てはまる構成設定を特定することができる。これらの実施形態のいくつかにおいて、構成設定は、各アトミックネイティブリソースに固有である場合がある。別の例において、ルールエンジンは、実行可能なコード、またはオペレーティングシステムによって定義されるようなＭＩＭＥタイプもしくはファイルタイプ等、あるクラスのファイルの修正を禁止または許容する構成データを含んでよい。
【００８７】
候補ファイルに関連する許可データが、修正してはいけないことを示す場合、ファイルの修正が許容されていないことを示すエラー状態が要求元に返される（ステップ４３８）。ファイルを修正してよいことを許可データが示す場合、候補ファイルはユーザ分離スコープにコピーされる（ステップ４４０）。いくつかの実施形態において、候補ファイルはルールエンジンによって定義された位置にコピーされる。例えば、ルールは、ファイルが別のアプリケーション分離スコープにコピーされると特定することができる。その他の実施形態において、ルールは、ファイルをコピーすべき特定のアプリケーション分離サブスコープまたはユーザ分離サブスコープを特定することができる。ファイルがコピーされる分離スコープに現われない要求されたファイルのあらゆる祖先は、コピーされたインスタンスを階層に正しく位置付けるために、分離スコープにおいてプレースホルダとして作成される。
【００８８】
いくつかの実施形態において、ファイルがコピーされた日時を示すメタデータが、分離スコープにコピーされたファイルに関連付けられる。この情報は、ファイルのコピーされたインスタンスに関連するタイムスタンプを、ファイルの元のインスタンスの、または下位分離スコープに位置するファイルの別のインスタンスの、前回の修正のタイムスタンプと比較するために使用される場合がある。これらの実施形態において、ファイルの元のインスタンス、または下位分離スコープに位置するファイルのインスタンスが、コピーされたファイルのタイムスタンプよりも後のタイムスタンプに関連付けられている場合、当該ファイルを分離スコープにコピーして候補ファイルを更新してよい。その他の実施形態において、分離スコープ内のファイルのコピーは、コピーされた元のファイルを含有するスコープを識別するメタデータと関連付けられてよい。
【００８９】
さらなる実施形態において、分離スコープにコピーされたファイルは、それらを修正する意図を持って開かれたものであるため、現実に修正されるか否かを判定するために監視される場合がある。一実施形態において、コピーされたファイルは、ファイルが実際に修正された際に設定されるフラグと関連付けられてよい。これらの実施形態において、コピーされたファイルが実際に修正されない場合、コピーされたファイルに関連するあらゆるプレースホルダノードに加えて、当該ファイルも、閉じられた後に、コピーされたスコープから除去されてよい。
【００９０】
スコープ付きインスタンスは文字ファイルとして識別され（ステップ４４２）、文字ファイルを開くために要求が発行され、結果が要求元に返される（ステップ４２０）。
【００９１】
ステップ４２６に戻って、候補ファイルは存在しないため候補ファイルが中立的存在を有する場合、または候補ファイルは見つかったがプレースホルダノードとしてマークされている場合、仮想ファイルが存在するか否かはまだ分かっていない。この場合、仮想ファイル名に対応するシステムスコープ付きファイル名は、候補ファイル名として識別される（ステップ４３０）。換言すると、候補ファイル名は厳密には仮想ファイル名である。
【００９２】
候補ファイルが存在しない場合（ステップ４３２）、仮想ファイルが見つからなかったことを示すエラー状態が要求元に返される（ステップ４３４）。一方、候補ファイルが存在する場合（ステップ４３２）、オープン要求がファイルを修正する意図を示しているか否かを判定するために、要求はチェックされる（ステップ４２８）。
【００９３】
上述のように、候補ファイルがそれを修正することを意図せず開かれている場合、システムスコープ付き候補ファイルは要求に対する文字ファイルとして識別され（ステップ４１８）、文字ファイルを開くために要求が発行され、結果が要求元に返される（ステップ４２０）。しかしながら、ステップ４２８において、オープン要求がファイルを修正する意図を示していると判定された場合、ファイルの修正が許容されているか否かを判定するために、ファイルに関連する許可データがチェックされる（ステップ４３６）。いくつかの実施形態において、許可データはシステムスコープ付き候補ファイルと関連付けられる。これらの実施形態のいくつかにおいて、許可データは、ルールエンジンに、または、候補ファイルに関連するメタデータに保存される。その他の実施形態において、候補ファイルに関連する許可データがオペレーティングシステムによって提供される。
【００９４】
システムスコープ付き候補ファイルに関連する許可データが、当該ファイルを修正してはいけないことを示す場合、ファイルの修正が許容されていないことを示すエラー状態が要求元に返される（ステップ４３８）。しかしながら、ファイルを修正してよいことを許可データが示す場合、候補ファイルはユーザ分離スコープにコピーされる（ステップ４４０）。いくつかの実施形態において、候補ファイルはルールエンジンによって定義された位置にコピーされる。例えば、ルールは、ファイルがアプリケーション分離スコープにコピーされる、またはシステムスコープに残されてよいと特定することができる。その他の実施形態において、ルールは、ファイルをコピーすべき特定のアプリケーション分離サブスコープまたはユーザ分離サブスコープを特定することができる。分離スコープに現われない要求されたファイルのあらゆる祖先は、コピーされたインスタンスを階層に正しく位置付けるために、分離スコープにおいてプレースホルダとして作成される。
【００９５】
いくつかの実施形態において、ファイルがコピーされた日時を示すメタデータが、分離スコープにコピーされたファイルに関連付けられる。この情報は、ファイルのコピーされたインスタンスに関連するタイムスタンプを、ファイルの元のインスタンスの前回の修正のタイムスタンプと比較するために使用される場合がある。これらの実施形態において、ファイルの元のインスタンスが、コピーされたファイルのタイムスタンプよりも後のタイムスタンプに関連付けられている場合、元のファイルを分離スコープにコピーして候補ファイルを更新してよい。その他の実施形態において、分離スコープにコピーされた候補ファイルは、元のファイルのコピー元であるスコープを示すメタデータと関連付けられてよい。
【００９６】
さらなる実施形態において、分離スコープにコピーされたファイルは、それらを修正する意図を持って開かれたものであるため、現実に修正されるか否かを判定するために監視される場合がある。一実施形態において、コピーされたファイルは、ファイルが実際に修正された際に設定されるフラグと関連付けられてよい。これらの実施形態において、コピーされたファイルが実際に修正されない場合、コピーされたファイルに関連するあらゆるプレースホルダノードに加えて、当該ファイルも、閉じられた際に、コピーされたスコープから除去されてよい。またさらなる実施形態において、ファイルは、実際に修正される際に適切な分離スコープにコピーされるのみである。
【００９７】
スコープ付きインスタンスは、文字ファイルとして識別され（ステップ４４２）、文字ファイルを開くために要求が発行され、結果が要求元に返される（ステップ４２０）。
【００９８】
（４．１．２  ファイルシステム削除動作）
図５および概要を参照すると、ファイルを削除するために取られるステップの一実施形態が描写されている。ファイルを削除するための要求が受信または傍受される（ステップ５０２）。要求は、分離環境によって仮想ファイル名として扱われるファイル名を含有する。ルールは、ファイル動作がどのように処理されるかを判定する（ステップ５０４）。ルールアクションが「リダイレクトする」である場合（ステップ５０６）、仮想ファイル名はルールに従って文字ファイル名に直接的にマップされる（ステップ５０８）。文字ファイルを削除するための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ５１０）。ルールアクションが「無視する」である場合（ステップ５０６）、文字ファイル名は厳密には仮想ファイル名として識別され（ステップ５１３）、文字ファイルを削除するための要求がオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ５１０）。ルールアクションが「分離する」である場合（ステップ５０６）、仮想ファイルの存在が判定される（ステップ５１４）。仮想ファイルが存在しない場合、仮想ファイルが存在しないことを示すエラー状態が要求元に返される（ステップ５１６）。仮想ファイルが存在する場合、および、仮想化ファイルが通常ファイルではなくディレクトリを特定する場合、仮想ファイルまたは仮想サブディレクトリを含有するか否かを判定するために、仮想ディレクトリが調べられる（ステップ５１８）。要求された仮想化ファイルが任意の仮想ファイルまたは仮想サブディレクトリを含有する仮想ディレクトリである場合、仮想ディレクトリを削除することができず、エラーメッセージが返される（ステップ５２０）。要求された仮想化ファイルが通常ファイルである場合、または仮想ファイルも仮想サブディレクトリも含有しない仮想ディレクトリである場合、仮想ファイルに対応する文字ファイルが識別される（ステップ５２２）。削除が許容されているか否かを判定するために、当該ファイルに関連する許可データがチェックされる（ステップ５２４）。許容されていない場合、許可エラーメッセージが返される（ステップ５２６）。しかしながら、ファイルの削除が許容されている場合、および、文字ファイルが適切なユーザ分離スコープにある場合（ステップ５２８）、当該文字ファイルは削除され（ステップ５３４）、削除された仮想ファイルを表す「削除」ノードが適切なユーザ分離スコープ内に作成される（ステップ５３６）。しかしながら、ステップ５２８において、文字ファイルはユーザ分離スコープにないが、適切なアプリケーション分離スコープまたはシステムスコープにあると判定された場合、既に存在しない要求されたファイルのユーザスコープ付きインスタンスのユーザスコープ付き祖先すべてのインスタンスが作成され、プレースホルダとしてマークされる（ステップ５３２）。これは、ユーザ分離スコープにおいてディレクトリ構造の論理階層を維持するためになされる。その後、適切なユーザ分離スコープにおいて、削除された仮想ファイルを表すユーザスコープ付き「削除」ノードが作成される（ステップ５３６）。
【００９９】
図５をさらに詳細に参照すると、ファイルを削除するための要求が受信または傍受される（ステップ５０２）。当該ファイルは、ユーザ分離スコープ、アプリケーション分離スコープ、システムスコープ、または何らかの適用可能な分離サブスコープのものであってよい。いくつかの実施形態において、要求は、ファイルを削除するためのオペレーティングシステム機能を置換する機能によってフックされる。別の実施形態において、要求を傍受するためにフッキング動的リンクライブラリが使用される。フッキング機能は、ユーザモードまたはカーネルモードで実行することができる。フッキング機能がユーザモードで実行する実施形態では、フッキング機能は、プロセスが作成される際に当該プロセスのアドレス空間にロードされてよい。フッキング機能がカーネルモードで実行する実施形態では、フッキング機能は、ネイティブファイルの要求をディスパッチするのに使用されるオペレーティングシステムリソースと関連付けられてよい。ファイルの種類ごとに別個のオペレーティングシステム機能が提供される実施形態では、各機能は別個にフックされてよい。あるいは、数種類のファイルの作成コールまたはオープンコールを傍受する単一のフッキング機能を提供してよい。
【０１００】
要求は、分離環境によって仮想ファイル名として扱われるファイル名を含有する。ルールエンジンを調べることによって、削除動作に適用可能な処理ルールが判定される（ステップ５０４）。いくつかの実施形態において、要求されたファイルに提供された仮想ファイル名は、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。これらの実施形態のうち特定のものにおいて、特定のファイルのルールエンジンに多くのルールが存在する場合があり、これらの実施形態において、仮想ファイル名と一致する最も長い接頭辞を有するルールは、要求に適用されるルールである。いくつかの実施形態において、ルールエンジンは、リレーショナルデータベースとして提供される場合がある。その他の実施形態において、ルールエンジンは、木構造データベース、ハッシュテーブル、またはフラットファイルデータベースであってよい。いくつかの実施形態において、要求中に提供された仮想ファイル名は、要求に当てはまる１つ以上のルールをルールエンジン内に位置付けるための索引として使用される。その他の実施形態において、プロセス識別子は、存在する場合、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。要求に関連するルールは、要求を無視すること、要求をリダイレクトすること、または要求を分離することであってよい。図５では一連の決定として示されているが、ルール検索は単一のデータベーストランザクションとして発生する場合がある。
【０１０１】
ルールアクションが「リダイレクトする」である場合（ステップ５０６）、仮想ファイル名は適用可能なルールに従って文字ファイル名に直接的にマップされる（ステップ５０８）。文字ファイルを削除するための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ５１０）。例えば、「ｆｉｌｅ＿１」と名付けられたファイルを削除するための要求により、「Ｄｉｆｆｅｒｅｎｔ＿ｆｉｌｅ＿１」と名付けられた実際のファイルを削除することができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。ファイルシステムフィルタドライバを使用する実施形態では、仮想名を使用してファイルを削除するために第１の要求により、ファイルシステムフィルタドライバから、判定された文字名を示すＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答を返すことになる。次に、Ｉ／Ｏマネージャは、ＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答に含む判定された文字名を持つファイル削除要求を再発行する。
【０１０２】
いくつかの実施形態において、文字ファイル「Ｄｉｆｆｅｒｅｎｔ＿ｆｉｌｅ＿１」と関連するオペレーティングシステム許可は、文字ファイルの削除を防止することができる。これらの実施形態において、ファイルを削除することができなかったというエラーメッセージが返される。
【０１０３】
ルールアクションが「無視する」である場合（ステップ５０６）、文字ファイル名は厳密には仮想ファイル名として識別され（ステップ５１３）、文字ファイルを削除するための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ５１０）。例えば、「ｆｉｌｅ＿１」と名付けられたファイルを削除するための要求により、「ｆｉｌｅ＿１」と名付けられた実際のファイルを削除することになる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。ファイルシステムフィルタドライバを使用する実施形態では、仮想名を使用してファイルを削除するための第１の要求により、ファイルシステムフィルタドライバから、当該文字名を示すＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答を返す。次に、Ｉ／Ｏマネージャは、ＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答に含む判定された文字名を持つファイル削除要求を再発行する。
【０１０４】
いくつかの実施形態において、文字ファイル「ｆｉｌｅ＿１」と関連するオペレーティングシステム許可は、文字ファイルの削除を防止することができる。これらの実施形態において、ファイルを削除することができなかったというエラーメッセージが返される。
【０１０５】
ルールアクションが「分離する」である場合（ステップ５０６）、仮想ファイルの存在が判定される（ステップ５１４）。ファイルが存在しない場合、ファイルが見つからないことを示すエラーが返される（ステップ５１６）。
【０１０６】
しかしながら、ステップ５１８において、ファイルは存在するが通常ファイルではなく、かつ空の仮想ディレクトリではない、すなわち仮想ファイルまたは仮想サブディレクトリを含有すると判定された場合、ファイルを削除できないことを示すエラーメッセージが返される（ステップ５２０）。
【０１０７】
しかしながら、ファイルが存在すると判定され、要求された仮想化ファイルが通常ファイルであるか、または空の仮想ディレクトリである、すなわち仮想ファイルおよび仮想サブディレクトリを含有しない場合（ステップ５１８）、仮想ファイルに対応する文字ファイルが識別される（ステップ５２２）。文字ファイル名は、分離ルールにより特定されるように仮想ファイル名から判定される。例えば、「ｆｉｌｅ＿１」と名付けられたファイルを削除するための要求により、「Ｉｓｏｌａｔｅｄ＿ｆｉｌｅ＿１」と名付けられた実際のファイルを削除することができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。ファイルシステムフィルタドライバを使用する実施形態では、仮想名を使用してファイルを削除するために第１の要求により、ファイルシステムフィルタドライバから、当該文字名を示すＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答を返す。次に、Ｉ／Ｏマネージャは、ＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答に含む判定された文字名を持つファイル削除要求を再発行する。
【０１０８】
仮想ファイルに対応する文字ファイルが識別されると、当該文字ファイルを削除できるか否か判定される（ステップ５２４）。ファイルを削除できない場合、ファイルを削除することができなかったというエラーが返される（ステップ５２４）。いくつかの実施形態において、許可データはシステムスコープ付き候補ファイルと関連付けられる。これらの実施形態のいくつかにおいて、許可データは、ルールエンジンに、または候補ファイルに関連するメタデータに保存される。その他の実施形態において、候補ファイルに関連する許可データがオペレーティングシステムによって提供される。
【０１０９】
しかしながら、ファイルの削除が許容されている場合、および、文字ファイルが適切なユーザ分離スコープにある場合（ステップ５２８）、当該文字ファイルは削除され（ステップ５３４）、削除された仮想ファイルを表す「削除」ノードが適切なユーザ分離スコープ内に作成される（ステップ５３６）。
【０１１０】
しかしながら、ステップ５２８において、文字ファイルはユーザ分離スコープにないが、適切なアプリケーション分離スコープまたはシステムスコープにあると判定された場合、既に存在しない要求されたファイルのユーザスコープ付きインスタンスのユーザスコープ付き祖先すべてのインスタンスが作成され、プレースホルダとしてマークされる（ステップ５３２）。これは、ユーザ分離スコープにおいてディレクトリ構造の論理階層を維持するためになされる。その後、適切なユーザ分離スコープにおいて、削除された仮想ファイルを表すユーザスコープ付き「削除」ノードが作成される（ステップ５３６）。いくつかの実施形態において、削除されたファイルのＩＤは、削除されたファイルに関するチェックを最適化するために、ファイルまたはその他のキャッシュメモリに保存される。
【０１１１】
いくつかの実施形態において、位置付けられた仮想化ファイルは、当該仮想化ファイルが既に削除されたことを示すメタデータと関連付けられてよい。その他いくつかの実施形態において、仮想化ファイルの祖先（例えば、ファイルを含有する上位ディレクトリ）は、それが削除されたことを示すメタデータと関連付けられる。これらの実施形態において、仮想化ファイルは存在しないことを示すエラーメッセージが返される場合がある。これらの実施形態のうち特異のものにおいて、削除されたファイルまたはファイルシステム要素のリストは、この削除されたファイルに関するチェックを最適化するために維持され調べられてよい。
【０１１２】
（４．１．３  ファイルシステム列挙動作）
図６および概要を参照すると、上述の仮想化環境において、ディレクトリを列挙するために取られるステップの一実施形態が示されている。列挙するための要求が受信または傍受される（ステップ６０２）。要求は、分離環境によって仮想ディレクトリ名として扱われるディレクトリ名を含有する。概念的には、仮想ディレクトリの存在は第４．１．１節で記載したように判定される（ステップ６０３）。仮想ディレクトリが存在しない場合、仮想ディレクトリが見つからないことを示す結果が要求元に返される（ステップ６２０）。そうではなく、仮想ディレクトリが存在する場合、列挙要求において特定されたディレクトリのルールを判定するために、ルールエンジンが調べられる（ステップ６０４）。ルールが「リダイレクトする」のアクションを特定する場合（ステップ６０６）、仮想ディレクトリ名に対応する文字ディレクトリ名がルールによって特定されるように判定され（ステップ６０８）、文字名によって識別された文字ディレクトリが列挙され、列挙結果が作業データストアに保存され（ステップ６１２）、以下で説明するようにステップ６３０に続く。特定されたルールアクションが「リダイレクトする」ではなく「無視する」である場合（ステップ６１０）、文字ディレクトリ名は厳密には仮想ディレクトリ名であり（ステップ６１３）、文字ディレクトリは列挙され、列挙結果が作業データストアに保存され（ステップ６１２）、以下で説明するようにステップ６３０に続く。しかしながら、ルールアクションが「分離する」を特定した場合、まずシステムスコープが列挙される、すなわち、候補ディレクトリ名は厳密には仮想ディレクトリ名であり、候補ディレクトリが存在する場合、それが列挙される。列挙結果は作業データストアに保存される。候補ディレクトリが存在しない場合、作業データストアはこの段階では空のままである（ステップ６１４）。次に、候補ディレクトリは仮想ディレクトリのアプリケーションスコープ付きインスタンスとして識別され、候補ディレクトリが存在するカテゴリが判定される（ステップ６１５）。候補ディレクトリが「否定的存在」を有する場合、すなわち、当該候補ディレクトリまたはスコープ内にあるその祖先の１つが削除されたものとしてマークされている場合、このスコープ内では削除されることが分かっており、これは作業データストアを一括消去することによって示される（ステップ６４２）。そうではなく、候補ディレクトリが否定的存在を有さない場合、当該候補ディレクトリは列挙され、得られたあらゆる列挙結果が作業データストアにマージされる。特に、列挙内の各ファイルシステム要素について、その存在のカテゴリが判定される。否定的存在を持つ要素は作業データストアから除去され、肯定的存在を持つ要素、すなわち、存在しているがプレースホルダとしてマークされておらず、かつ削除されたものとしてマークされていない要素は、作業データストアに追加され、作業データストアに既に存在しているものがある場合には、対応する要素と置換する（ステップ６１６）。
【０１１３】
いずれの場合も、候補ディレクトリは仮想ディレクトリのユーザスコープ付きインスタンスとして識別され、候補ディレクトリが存在するカテゴリが判定される（ステップ６１７）。候補ディレクトリが「否定的存在」を有する場合、すなわち、当該候補ディレクトリまたはスコープ内にあるその祖先の１つが削除されたものとしてマークされている場合、このスコープ内では削除されることが分かっており、これは作業データストアを一括消去することによって示される（ステップ６４４）。そうではなく、候補ディレクトリが否定的存在を有さない場合、当該候補ディレクトリは列挙され、得られたあらゆる列挙結果が作業データストアにマージされる。特に、列挙内の各ファイルシステム要素について、その存在のカテゴリが判定される。否定的存在を持つ要素は作業データストアから除去され、肯定的存在を持つ要素、すなわち、存在しているがプレースホルダとしてマークされておらず、かつ削除されたものとしてマークされていない要素は、作業データストアに追加され、作業データストアに既に存在しているものがある場合には、対応する要素と置換し（ステップ６１８）、以下で説明するようにステップ６３０に続く。
【０１１４】
次いで、３種類すべてのルールについて、ステップ６３０が実行される。ルールエンジンは、そのフィルタが要求されたティレクトリの直接の子には一致するが要求されたディレクトリ自体には一致しないルールのセットを見つけるためにクエリされる（ステップ６３０）。セット内の各ルールについて、その名前がルール内の名前に一致する仮想子の存在が、第４．１．１節で概説した論理を使用してクエリされる。子が肯定的存在を有する場合、作業データストアに追加され、既にそこにある同じ名前の任意の子と置換する。子が否定的存在を有する場合、子に対応する作業データストア内のエントリは、もしあれば、除去される（ステップ６３２）。そして最後に、構築された列挙は、作業データストアから要求元に返される（ステップ６２０）。
【０１１５】
図６をさらに詳細に参照すると、ディレクトリを列挙するための要求は受信または傍受される（ステップ６０２）。いくつかの実施形態において、要求は、ディレクトリを列挙するためのオペレーティングシステム機能を置換する機能によってフックされる。別の実施形態において、要求を傍受するためにフッキング動的リンクライブラリが使用される。フッキング機能は、ユーザモードまたはカーネルモードで実行することができる。フッキング機能がユーザモードで実行する実施形態では、フッキング機能は、プロセスが作成される際に当該プロセスのアドレス空間にロードされてよい。フッキング機能がカーネルモードで実行する実施形態では、フッキング機能は、ファイル動作の要求をディスパッチするのに使用されるオペレーティングシステムリソースと関連付けられてよい。ファイル動作の種類ごとに別個のオペレーティングシステム機能が提供される実施形態では、各機能は別個にフックされてよい。あるいは、数種類のファイル動作の作成コールまたはオープンコールを傍受する単一のフッキング機能を提供してよい。
【０１１６】
仮想ディレクトリの存在が判定される（ステップ６０３）。これは、第４．１．１節に記載したように達成される。仮想ディレクトリが存在しない場合、列挙することはできず、仮想ディレクトリが存在しないことを示す結果が要求元に返される（ステップ６２０）。
【０１１７】
要求は、分離環境によって仮想ディレクトリ名として扱われるディレクトリ名を含有する。仮想ディレクトリが存在する場合、ルールエンジンを調べることによって、列挙動作をどのように処理するかを判定するルールが位置付けられる（ステップ６０４）。いくつかの実施形態において、ルールエンジンは、リレーショナルデータベースとして提供される場合がある。その他の実施形態において、ルールエンジンは、木構造データベース、ハッシュテーブル、またはフラットファイルデータベースであってよい。いくつかの実施形態において、要求されたディレクトリに提供された仮想ディレクトリ名は、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。これらの実施形態のうち特定のものにおいて、特定のディレクトリのルールエンジンに多くのルールが存在する場合があり、これらの実施形態において、仮想ディレクトリ名と一致する最も長い接頭辞を有するルールは、要求に適用されるルールである。その他の実施形態において、プロセス識別子は、存在する場合、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。要求に関連するルールは、要求を無視すること、要求をリダイレクトすること、または要求を分離することであってよい。図６では単一のデータベーストランザクションまたは単一のファイル内検索として示されているが、ルール検索は一連のルール検索として行われてもよい。
【０１１８】
ルールアクションが「リダイレクトする」である場合（ステップ６０６）、仮想ディレクトリ名はルールに従って文字ディレクトリ名に直接的にマップされる（ステップ６０８）。文字ディレクトリを列挙するための要求がオペレーティングシステムに渡され（ステップ６１２）、以下で説明するようにステップ６３０が実行される。例えば、「ｄｉｒｅｃｔｏｒｙ＿１」と名付けられたディレクトリを列挙するための要求により、「Ｄｉｆｆｅｒｅｎｔ＿ｄｉｒｅｃｔｏｒｙ＿１」と名付けられた文字ディレクトリを列挙することができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。ファイルシステムフィルタドライバを使用する実施形態では、仮想名を使用して列挙するディレクトリを開くための第１の要求により、判定された文字名を示すＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ要求応答がもたらされる。次に、Ｉ／Ｏマネージャは、ＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答に含む判定された文字名を持つ、列挙のためのディレクトリオープン要求を再発行する。
【０１１９】
ルールアクションが「リダイレクトする」でなく（ステップ６０６）、「無視する」である場合（ステップ６１０）、文字ディレクトリ名は厳密には仮想ディレクトリ名として識別され（ステップ６１３）、文字ディレクトリを列挙するための要求はオペレーティングシステムに渡され（ステップ６１２）、以下で説明するようにステップ６３０が実行される。例えば、「ｄｉｒｅｃｔｏｒｙ＿１」と名付けられたディレクトリを列挙するための要求により、「ｄｉｒｅｃｔｏｒｙ＿１」と名付けられた実際のディレクトリを列挙することになる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。ファイルシステムフィルタドライバを使用する実施形態では、仮想名を使用してディレクトリを列挙するための第１の要求は、フィルタドライバを無修正で通過する。
【０１２０】
ステップ６１０において判定されたルールアクションが「無視する」ではなく「分離する」である場合、システムスコープが列挙される、すなわち、要求中に提供された仮想名を使用して、列挙されたディレクトリを識別する（ステップ６１４）。列挙結果は作業データストアに保存される。いくつかの実施形態において、作業データストアはメモリ素子からなる。その他の実施形態において、作業データストアは、データベースまたはファイルまたは固体メモリ素子または永続的データストアを備える。
【０１２１】
次に、候補ディレクトリは仮想ディレクトリのアプリケーションスコープ付きインスタンスとして識別され、候補ディレクトリが存在するカテゴリが判定される（ステップ６１５）。候補ディレクトリが「否定的存在」を有する場合、すなわち、当該候補ディレクトリまたはスコープ内にあるその祖先の１つが削除されたものとしてマークされている場合、このスコープ内では削除されることが分かっており、これは作業データストアを一括消去することによって示される（ステップ６４２）。
【０１２２】
いくつかの実施形態において、ファイルについての少量のメタデータが、仮想名にメタデータ識別子で接尾辞を付ける等によって文字ファイル名に直接的に保存されてよく、ここでメタデータ識別子は特定のメタデータ状態に一意に関連する文字列である。メタデータ識別子は、１または数ビットのメタデータを示す、または符号化することができる。メタデータ識別子の存在による文字ファイル名の考えられる変形に関する仮想ファイル名チェックによってファイルにアクセスするための要求、およびファイル名自体を検索するための要求は、文字名で応答するためにフックまたは傍受される。その他の実施形態において、ファイルの１つ以上の代替名が仮想ファイル名およびメタデータ識別子から形成されてよく、ファイルシステムによって提供されたハードリンクまたはソフトリンク設備を使用して作成されてよい。これらのリンクの存在は、リンクの名前を使用してアクセスのための要求が与えられる場合、分離環境によってファイルが見つからないことを示すことにより、アプリケーションから隠される場合がある。特定のリンクの有無は各メタデータ識別子につき１ビットのメタデータを示してよく、または、数ビットのメタデータを示すために多くの状態を呈することができるメタデータ識別子とのリンクがあってよい。また他の実施形態において、ファイルシステムが代替ファイルストリームをサポートする場合、メタデータを具現化するために代替ファイルストリームが作成されてよく、そのストリームのサイズは数ビットのメタデータを示す。また他の実施形態において、ファイルシステムは、ファイルシステム内の各ファイルに、いくつかの第三者メタデータを保存する能力を直接的に提供することができる。さらに他の実施形態において、別個のサブスコープは削除されたファイルを記録するために使用することができ、当該サブスコープ内の（プレースホルダとしてマークされていない）ファイルの存在は、ファイルが削除されたことを意味すると解釈される。
【０１２３】
そうではなく、候補ディレクトリが否定的存在を有さない場合、当該候補ディレクトリは列挙され、得られたあらゆる列挙結果が作業データストアにマージされる。特に、列挙内の各ファイルシステム要素について、その存在のカテゴリが判定される。否定的存在を持つ要素は作業データストアから除去され、肯定的存在を持つ要素、すなわち、存在しているがプレースホルダとしてマークされておらず、かつ削除されたものとしてマークされていない要素は、作業データストアに追加され、作業データストアに既に存在しているものがある場合には、対応する要素と置換する（ステップ６１６）。
【０１２４】
いずれの場合も、候補ディレクトリは仮想ディレクトリのユーザスコープ付きインスタンスとして識別され、候補ディレクトリが存在するカテゴリが判定される（ステップ６１７）。候補ディレクトリが「否定的存在」を有する場合、すなわち、当該候補ディレクトリまたはスコープ内にあるその祖先の１つが削除されたものとしてマークされている場合、このスコープ内では削除されることが分かっており、これは作業データストアを一括消去することによって示される（ステップ６４４）。そうではなく、候補ディレクトリが否定的存在を有さない場合、当該候補ディレクトリは列挙され、得られたあらゆる列挙結果が作業データストアにマージされる。特に、列挙内の各ファイルシステム要素について、その存在のカテゴリが判定される。否定的存在を持つ要素は作業データストアから除去され、肯定的存在を持つ要素、すなわち、存在しているがプレースホルダとしてマークされておらず、かつ削除されたものとしてマークされていない要素は、作業データストアに追加され、作業データストアに既に存在しているものがある場合には、対応する要素と置換し（ステップ６１８）、以下で説明するようにステップ６３０に続く。
【０１２５】
次いで、３種類すべてのルールについて、ステップ６３０が実行される。ルールエンジンは、そのフィルタが要求されたティレクトリの直接の子には一致するが要求されたディレクトリ自体には一致しないルールのセットを見つけるためにクエリされる（ステップ６３０）。セット内の各ルールについて、その名前がルール内の名前に一致する仮想子の存在が、第４．１．１節で概説した論理を使用してクエリされる。子が肯定的存在を有する場合、作業データストアに追加され、既にそこにある同じ名前の任意の子と置換する。子が否定的存在を有する場合、子に対応する作業データストア内のエントリは、もしあれば、除去される（ステップ６３２）。そして最後に、構築された列挙は、作業データストアから要求元に返される（ステップ６２０）。
【０１２６】
当業者であれば、上述のレイヤ化された列挙プロセスは、微修正して、複数の分離サブスコープを備える単一の分離スコープを列挙する動作に適用できることを認識するであろう。作業データストアが作成され、連続的なサブスコープが列挙され、分離スコープの集約列挙を形成するために、結果が作業データストアにマージされる。
【０１２７】
（４．１．４  ファイルシステム作成動作）
図７および概要を参照すると、分離環境においてファイルを作成するために取られるステップの一実施形態が示されている。ファイルを作成するための要求が受信または傍受される（ステップ７０２）。要求は、分離環境によって仮想ファイル名として扱われるファイル名を含有する。第４．１．１節で記載したように、適用可能なルールを使用した、すなわち、適切なユーザおよびアプリケーション分離スコープを使用した完全仮想化を使用して、要求されたファイルを開く試みが行われる（ステップ７０４）。アクセスが拒否された場合（ステップ７０６）、アクセス拒否エラーが要求元に返される（ステップ７０９）。アクセスが許可され（ステップ７０６）、要求されたファイルがうまく開かれた場合（ステップ７１０）、要求されたファイルが要求元に返される（ステップ７１２）。しかしながら、アクセスが許可されたが（ステップ７０６）、要求されたファイルがうまく開かれず（ステップ７１０）、要求されたファイルの親も存在しない場合（ステップ７１４）、要求動作に適したエラーが要求元に対して発行される（ステップ７１６）。一方、適切なユーザおよびアプリケーションスコープを使用して、完全に仮想化されたビューにおいて要求されたファイルの親が見つかった場合（ステップ７１４）、ルールはファイル動作をどのように処理するかを判定する（ステップ７１８）。ルールアクションが「リダイレクトする」または「無視する」である場合（ステップ７２０）、仮想ファイル名はルールに従って文字ファイル名に直接的にマップされる。具体的には、ルールアクションが「無視する」である場合、文字ファイル名は厳密には仮想ファイル名として識別される。そうではなく、ルールアクションが「リダイレクトする」である場合、文字ファイル名はルールによって特定されるように仮想ファイル名から判定される。次いで文字ファイルを作成するための要求がオペレーティングシステムに渡され、結果が要求元に返される（ステップ７２４）。一方、ステップ７２０において判定されたルールアクションが「分離する」である場合、文字ファイル名はユーザ分離スコープにおける仮想ファイル名のインスタンスとして識別される。文字ファイルが既に存在するが、プレースホルダであること、または削除されたことを示すメタデータと関連付けられている場合、それらの表示を除去するよう関連のメタデータを修正し、ファイルが空であることが確認される。いずれの場合も、文字ファルを開くための要求がオペレーティングシステムに渡される（ステップ７２６）。文字ファイルがうまく開かれた場合（ステップ７２８）、当該文字ファイルが要求元に返される（ステップ７３０）。一方、ステップ７２８において、要求されたファイルが開けない場合、現在ユーザ分離スコープに存在しない文字ファイルの各祖先についてプレースホルダ（ステップ７３２）、文字ファイル名を使用して文字ファイルを作成するための要求がオペレーティングシステムに渡され、結果が要求元に返される（ステップ７３４）。
【０１２８】
図７をさらに詳細に参照すると、ファイルを作成するための要求が受信または傍受される（ステップ７０２）。いくつかの実施形態において、要求は、ファイルを作成するためのオペレーティングシステム機能を置換する機能によってフックされる。別の実施形態において、要求を傍受するためにフッキング動的リンクライブラリが使用される。フッキング機能は、ユーザモードまたはカーネルモードで実行することができる。フッキング機能がユーザモードで実行する実施形態では、フッキング機能は、プロセスが作成される際に当該プロセスのアドレス空間にロードされてよい。フッキング機能がカーネルモードで実行する実施形態では、フッキング機能は、ファイルの要求をディスパッチするのに使用されるオペレーティングシステムリソースと関連付けられてよい。ファイル動作の種類ごとに別個のオペレーティングシステム機能が提供される実施形態では、各機能は別個にフックされてよい。あるいは、数種類のファイル動作の作成コールまたはオープンコールを傍受する単一のフッキング機能を提供してよい。
【０１２９】
要求は、分離環境によって仮想ファイル名として扱われるファイル名を含有する。要求元は、第４．１．１節で記載したように、適用可能なルールを使用した、すなわち、適切なユーザおよびアプリケーション分離スコープを使用した完全仮想化を使用して、要求されたファイルを開くよう試みる（ステップ７０４）。完全に仮想化されたオープン動作中にアクセスが拒否された場合（ステップ７０６）、アクセス拒否エラーが要求元に返される（ステップ７０９）。アクセスが許可され（ステップ７０６）、要求された仮想ファイルがうまく開かれた場合（ステップ７１０）、対応する文字ファイルが要求元に返される（ステップ７１２）。しかしながら、アクセスが許可されたが（ステップ７０６）、要求されたファイルがうまく開かれない場合（ステップ７１０）、仮想ファイルは存在しないと判定されたということである。第４．１．１節の手順によって判定された際に、要求された仮想ファイルの仮想親も存在しない場合（ステップ７１４）、要求動作に適したエラーが要求元に対して発行される（ステップ７１６）。一方、適切なユーザおよびアプリケーションスコープを使用して、完全に仮想化されたビューにおいて要求された仮想ファイルの仮想親が見つかった場合（ステップ７１４）、ルールエンジンを調べることにより、作成動作をどのように処理するかを判定するルールが位置付けられる（ステップ７１８）。いくつかの実施形態において、ルールエンジンは、リレーショナルデータベースとして提供される場合がある。その他の実施形態において、ルールエンジンは、木構造データベース、ハッシュテーブル、またはフラットファイルデータベースであってよい。いくつかの実施形態において、要求されたファイルに提供された仮想ファイル名は、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。これらの実施形態のうち特定のものにおいて、特定のファイルのルールエンジンに多くのルールが存在する場合があり、これらの実施形態のいくつかにおいて、仮想ファイル名と一致する最も長い接頭辞を有するルールは、要求に適用されるルールである。いくつかの実施形態において、プロセス識別子は、存在する場合、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。要求に関連するルールは、要求を無視すること、要求をリダイレクトすること、または要求を分離することであってよい。図７では単一のデータベーストランザクションまたは単一のファイル内検索として示されているが、ルール検索は一連のルール検索として行われてもよい。
【０１３０】
ルールアクションが「リダイレクトする」または「無視する」である場合（ステップ７２０）、仮想ファイル名はルールに従って文字ファイル名に直接的にマップされる（ステップ７２４）。ルールアクションが「リダイレクトする」である場合（ステップ７２０）、文字ファイル名はルールによって特定されるように仮想ファイル名から判定される（ステップ７２４）。ルールアクションが「無視する」である場合（ステップ７２０）、文字ファイル名は厳密には仮想ファイル名であると判定される（ステップ７２４）。ルールアクションが「無視する」である、またはルールアクションが「リダイレクトする」である場合、判定された文字ファイル名を使用して文字ファイルを作成するための要求がオペレーティングシステムに渡され、オペレーティングシステムから結果が要求元に返される（ステップ７２４）。例えば、「ｆｉｌｅ＿１」と名付けられた仮想ファイルを作成するための要求により、「Ｄｉｆｆｅｒｅｎｔ＿ｆｉｌｅ＿１」と名付けられた文字ファイルを作成することができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される（ステップ７２４）。ファイルシステムフィルタドライバを使用する実施形態では、仮想名を使用してファイルを開くための第１の要求により、判定された文字名を示す「ＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ」要求応答がもたらされる。次に、Ｉ／Ｏマネージャは、ＳＴＡＴＵＳ＿ＲＥＰＡＲＳＥ応答に含む判定された文字名を持つファイルオープン要求を再発行する。
【０１３１】
ステップ７２０において判定されたルールアクションが「無視する」または「リダイレクトする」ではなく「分離する」である場合、文字ファイル名はユーザ分離スコープにおける仮想ファイル名のインスタンスとして識別される。文字ファイルが既に存在するが、プレースホルダであること、または削除されたことを示すメタデータと関連付けられている場合、それらの表示を除去するよう関連のメタデータを修正し、ファイルが空であることが確認される。
【０１３２】
いくつかの実施形態において、ファイルについての少量のメタデータが、仮想名にメタデータ識別子で接尾辞を付ける等によって文字ファイル名に直接的に保存されてよく、ここでメタデータ識別子は特定のメタデータ状態に一意に関連する文字列である。メタデータ識別子は、１または数ビットのメタデータを示す、または符号化することができる。メタデータ識別子の存在による文字ファイル名の考えられる変形に関する仮想ファイル名チェックによってファイルにアクセスするための要求、およびファイル名自体を検索するための要求は、文字名で応答するためにフックまたは傍受される。その他の実施形態において、ファイルの１つ以上の代替名が仮想ファイル名およびメタデータ識別子から形成されてよく、ファイルシステムによって提供されたハードリンクまたはソフトリンク設備を使用して作成されてよい。これらのリンクの存在は、リンクの名前を使用してファイルにアクセスするための要求が与えられる場合、分離環境によってファイルが見つからないことを示すことにより、アプリケーションから隠される。特定のリンクの有無は各メタデータ識別子につき１ビットのメタデータを示してよく、または、数ビットのメタデータを示すために多くの状態を呈することができるメタデータ識別子とのリンクがあってよい。また他の実施形態において、ファイルシステムが代替ファイルストリームをサポートする場合、メタデータを具現化するために代替ファイルストリームが作成されてよく、そのストリームのサイズは数ビットのメタデータを示す。また他の実施形態において、ファイルシステムは、ファイルシステム内の各ファイルに、いくつかの第三者メタデータを保存する能力を直接的に提供することができる。
【０１３３】
これらの実施形態のうち特異のものにおいて、削除されたファイルまたはファイルシステム要素のリストは、この削除されたファイルに関するチェックを最適化するために維持され調べられてよい。これらの実施形態において、削除されたファイルが再作成されると、ファイル名は削除されたファイルのリストから除去されてよい。これらの実施形態のうちのその他において、リストが一定サイズを超えた場合、ファイル名はリストから除去されてよい。
【０１３４】
いずれの場合も、ユーザスコープ付き文字ファイルを開くための要求がオペレーティングシステムに渡される（ステップ７２６）。いくつかの実施形態において、ルールは、アプリケーション分離スコープ、システムスコープ、ユーザ分離サブスコープ、またはアプリケーション分離サブスコープ等、ユーザ分離スコープ以外のスコープにおいて、仮想ファイルに対応する文字ファイルが作成されるべきであると特定することができる。
【０１３５】
文字ファイルがうまく開かれた場合（ステップ７２８）、当該文字ファイルが要求元に返される（ステップ７３０）。一方、ステップ７２８において、要求されたファイルが開けない場合、現在ユーザ分離スコープに存在しない文字ファイルの各祖先についてプレースホルダが作成され（ステップ７３２）、文字ファイル名を使用して文字ファイルを作成するための要求がオペレーティングシステムに渡され、結果が要求元に返される（ステップ７３４）。
【０１３６】
この実施形態は、コール／呼び出しごとに１レベルの作成のみをサポートするＡＰＩまたは設備を持つオペレーティングシステムを表すものである。コール／呼び出しごとにマルチレベルへ拡大解釈できることは、当業者には明白なはずである。
【０１３７】
（４．１．５  短いファイル名管理）
いくつかのファイルシステムにおいて、各ファイルに短いファイル名と長いファイル名の両方を与えることができる。いずれの名前も、上述したファイル動作のいずれかにおいてファイルにアクセスするために使用することができる。短いファイル名と長いファイル名の両方を所有する各ファイルについて、これは、当該ファイルに割り当てられた短いファイル名と長いファイル名との間に暗黙に関連付けを作成するものである。これらのファイルシステムのいくつかにおいて、短い名前は、長いファイル名を使用して作成されたファイルに、ファイルシステムによって自動的に割り当てられる。短いファイル名と長いファイル名との間の関連付けが分離環境によって維持されていない場合、同じディレクトリ内であるが異なるスコープレベル内の異なる長い名前を持つファイルは、同じ短いファイル名を有することがあり、短い名前を使用して仮想ファイルにアクセスすれば、曖昧さにつながる。あるいは、短いファイル名には、ファイルがユーザ分離スコープにコピーされる際に修正のための変更が加えられる場合があり、もはや元の短い名前を使用して仮想ファイルにアクセスすることはできないことを意味する。
【０１３８】
これらの問題を防止するため、第一に、「上位」スコープに修正する意図を持って開かれたファイルインスタンスをコピーするファイルシステム動作は、コピーされたインスタンスに関連する短いファイル名と長いファイル名との間の関連付けを保護する。第二に、オペレーティングシステムによって割り当てられたファイル名の代わりに、新規作成された分離ファイルのための短い唯一の名前が作成される。生成された短いファイル名は、その生成されたファイル名が同じ分離スコープ内の同じディレクトリ、または「下位」分離スコープ内の同じディレクトリにおける、既存のいかなる短いファイル名とも一致しないという条件を満たさなくてはならない。例えば、ユーザ分離スコープに位置するファイルのインスタンス用に生成された短いファイル名は、ディレクトリのアプリケーションスコープ付きインスタンス内の、または、ディレクトリのシステムスコープ付きインスタンス内の、既存の短いファイル名と一致してはならない。
【０１３９】
図７Ａを参照すると、新規ファイルを作成した後、唯一の短いファイル名を割り当てるために取られるステップの一実施形態が示されている。概要では、短いファイル名を生成するべきか否かを判定するためにチェックが行われる（ステップ７５２）。生成するべきでない場合、短いファイル名は生成されないことを示す状態が返される（ステップ７５４）。そうでなければ、既にファイルシステムに従った正当な短いファイル名であるか否かを判定するために、ファイル名がチェックされる（ステップ７５６）。既に正当な短いファイル名である場合、短いファイル名は生成されないことを示す状態が返される（ステップ７５４）。そうでなければ、適合する短いファイル名が構築される（ステップ７５８）。
【０１４０】
図７Ａをより詳細に参照すると、短いファイル名を生成するべきか否かを判定するためにチェックが行われる（ステップ７５２）。いくつかの実施形態において、この決定は、そのファイル名が参照するファイルを保存するデバイスに基づいて行われる。その他の実施形態において、短いファイル名の生成は、一定のスコープもしくはサブスコープに、または分離環境全体に使用可能な場合がある。これらの実施形態のいくつかにおいて、レジストリ設定は、特定のファイル名について短いファイル名が生成されるか否かを特定することができる。短いファイル名を生成するべきでない場合、短いファイル名は生成されないという状態が返される（ステップ７５４）。
【０１４１】
そうでなければ、既に正当な短いファイル名であるか否かを判定するために、ファイル名がチェックされる（ステップ７５６）。いくつかの実施形態において、正当な短いファイル名は、ファイル名に最大８文字、任意の拡張子に最大３文字を含有する。いくつかの実施形態において、正当な短い名前は、Ａ−Ｚ、ａ−ｚ、０−９、’、〜、！、＠、＃、＄、％、＾、＆、＊、（、）、−、＿、‘、｛、および｝等の正当な文字のみを含有する。いくつかの実施形態において、先頭の空白もしくは「．」、または１つを超えて埋め込まれた「．」は不正である。提供されたファイル名が既に正当な短いファイル名である場合、短いファイル名は生成されないという状態が返される（ステップ７５４）。
【０１４２】
そうではなく、ステップ７５６において、ファイル名は不正なファイル名であると判定された場合、適合する短いファイル名が構築される（ステップ７５８）。いくつかの実施形態において、これは、短いファイル名において使用するのに正当な長いファイル名の部分のいくつかを、短い候補ファイル名を形成するために、符号化反復回数と組み合わせて使用することによって達成される。反復回数は、関連する短い候補ファイル名が適合する、すなわち、同じスコープの同じディレクトリ内、または下位スコープの同じディレクトリ内の、その他いかなるファイルによっても使用されない、正当な短いファイル名となるまで増加される。その他の実施形態において、長いファイル名は、マングルまたはハッシュおよび符号化され、短い候補ファイル名を形成するために、符号化反復回数と組み合わせられる。反復回数は、関連する短い候補ファイル名が適合する、すなわち、同じスコープの同じディレクトリ内、または下位スコープの同じディレクトリ内の、その他いかなるファイルによっても使用されない、正当な短いファイル名となるまで増加される。これらの実施形態のすべてにおいて、適合する短い候補ファイル名が低反復回数で見つかる可能性を高めるために、スコープ固有の文字列を短い候補ファイル名に組み込んでよい。
【０１４３】
（４．２  レジストリ仮想化）
上述の方法および装置は、レジストリデータベースへのアクセスを仮想化するために使用され得る。上述のように、レジストリデータベースは、コンピュータに物理的に取り付けられたハードウェア、いずれのシステムオプションが選択されたか、コンピュータメモリがどのようにセットアップされているか、アプリケーション固有データの様々な項目、および、オペレーティングシステムが開始される際にはどのアプリケーションプログラムが存在しているべきか、に関する情報を保存する。レジストリデータベースは通常、レジストリ値用のコンテナである「キー」１７０、１７２の論理階層に組織化されている。
【０１４４】
（４．２．１  レジストリキーオープン動作）
概要において、図８は、上述の分離環境において、レジストリキーを開くために取られるステップの一実施形態を描写している。レジストリキーを開くための要求であって、分離環境によって仮想キー名として扱われるレジストリキー名を含有する要求が、受信または傍受される（ステップ８０２）。要求中の仮想名に適用可能な処理ルールは、レジストリキー動作がどのように処理されるかを判定する（ステップ８０４）。ルールアクションが「リダイレクトする」である場合（ステップ８０６）、要求中に提供された仮想キー名は、適用可能なルールによって特定されるように文字キー名にマップされる（ステップ８０８）。文字キー名を使用して文字レジストリキーを開くための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ８１０）。ルールアクションが「リダイレクトする」ではなく「無視する」である場合（ステップ８０６）、仮想キー名は文字キー名として識別され（ステップ８１２）、文字レジストリキーを開くための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ８１０）。ステップ８０６において判定されたルールアクションが「リダイレクトする」でも「無視する」でもなく「分離する」である場合、要求中に提供された仮想キー名は、ユーザスコープ付き候補キー名、すなわち、適用可能なユーザ分離スコープに固有である仮想キー名に対応するキー名にマップされる（ステップ８１４）。ユーザスコープ付き候補キーが存在するカテゴリは、ユーザ分離スコープおよび候補キーに関連する任意のメタデータを調査することによって判定される（ステップ８１６）。候補キーが「否定的存在」を有すると判定された場合、当該候補キーまたはユーザ分離スコープ内のその祖先キーの１つのいずれかが削除されたものとしてマークされているため、これは要求された仮想キーが存在しないと分かっていることを意味する。この場合、要求されたファイルが見つからないことを示すエラー状態が要求元に返される（ステップ８２２）。そうではなく、ステップ８１６において候補キーが「肯定的存在」を有すると判定された場合、候補キーはユーザ分離スコープに存在しており、プレースホルダノードとしてマークされていないため、要求された仮想キーは存在すると分かっている。候補キーは、要求に対する文字キーとして識別され（ステップ８１８）、文字キーを開くために要求が発行され、結果が要求元に返される（ステップ８２０）。しかしながら、ステップ８１６において、候補キーが「中立的存在」を有する場合、候補キーは存在しないため、または候補キーは存在するがプレースホルダノードとしてマークされているため、仮想キーが存在するか否かはまだ分かっていない。この場合、仮想キー名に対応するアプリケーションスコープ付きキー名は、候補キー名として識別される（ステップ８２４）。換言すると、候補キー名は、適用可能なアプリケーション分離スコープに固有の対応するネイティブキー名に仮想キー名をマップすることによって形成される。候補キーが存在するカテゴリは、アプリケーション分離スコープおよび候補キーに関連する任意のメタデータを調査することによって判定される（ステップ８２６）。候補キーが「否定的存在」を有すると判定された場合、当該候補キーまたはアプリケーション分離スコープ内のその祖先キーの１つのいずれかが削除されたものとしてマークされているため、これは要求された仮想キーが存在しないと分かっていることを意味する。この場合、要求されたキーが見つからないことを示すエラー状態が要求元に返される（ステップ８２２）。そうではなく、ステップ８２６において候補キーが「肯定的存在」を有すると判定された場合、候補キーはアプリケーション分離スコープに存在しており、プレースホルダノードとしてマークされていないため、要求された仮想キーは存在すると分かっている。オープン要求がキーを修正する意図を示しているか否かを判定するために、要求はチェックされる（ステップ８２８）。示していない場合、候補キーは要求に対する文字キーとして識別され（ステップ８１８）、文字キーを開くために要求が発行され、結果が要求元に返される（ステップ８２０）。しかしながら、ステップ８２８において、オープン要求がキーを修正する意図を示していると判定された場合、キーの修正が許容されているか否かを判定するために、キーに関連する許可データがチェックされる（ステップ８３６）。許容されていない場合、キーの修正が許容されていないことを示すエラー状態が要求元に返される（ステップ８３８）。キーを修正してよいことを許可データが示す場合、候補キーはユーザ分離スコープにコピーされる（ステップ８４０）。いくつかの実施形態において、候補キーはルールエンジンによって定義された位置にコピーされる。例えば、ルールは、キーがアプリケーション分離スコープにコピーされると特定することができる。その他の実施形態において、ルールは、キーをコピーすべき特定のアプリケーション分離サブスコープまたはユーザ分離サブスコープを特定することができる。キーがコピーされる分離スコープに現われない要求されたキーのあらゆる祖先は、コピーされたインスタンスを階層に正しく位置付けるために、分離スコープにおいてプレースホルダとして作成される。新規にコピーされたスコープ付きインスタンスは文字キーとして識別され（ステップ８４２）、文字キーを開くための要求が発行され、結果が要求元に返される（ステップ８２０）。ステップ８２６に戻って、候補キーが中立的存在を有する場合、候補キーは存在しないため、または候補キーは見つかったがプレースホルダノードとしてマークされているため、仮想キーが存在するか否かはまだ分かっていない。この場合、仮想キー名に対応するシステムスコープ付きキー名は、候補キー名として識別される（ステップ８３０）。換言すると、候補キー名は厳密には仮想キー名である。候補キーが存在しない場合（ステップ８３２）、仮想キーが見つからなかったことを示すエラー状態が要求元に返される（ステップ８３４）。一方、候補キーが存在する場合（ステップ８３２）、オープン要求がキーを修正する意図を示しているか否かを判定するために、要求はチェックされる（ステップ８２８）。示していない場合、候補キーは要求に対する文字キーとして識別され（ステップ８１８）、文字キーを開くために要求が発行され、結果が要求元に返される（ステップ８２０）。しかしながら、ステップ８２８において、オープン要求がキーを修正する意図を示していると判定された場合、キーの修正が許容されているか否かを判定するために、キーに関連する許可データがチェックされる（ステップ８３６）。許容されていない場合、キーの修正が許容されていないことを示すエラー状態が要求元に返される（ステップ８３８）。キーを修正してよいことを許可データが示す場合、候補キーはユーザ分離スコープにコピーされる（ステップ８４０）。いくつかの実施形態において、候補キーはルールエンジンによって定義された位置にコピーされる。例えば、ルールは、キーがアプリケーション分離スコープにコピーされると特定することができる。その他の実施形態において、ルールは、キーをコピーすべき特定のアプリケーション分離サブスコープまたはユーザ分離サブスコープを特定することができる。分離スコープに現われない要求されたキーのあらゆる祖先は、コピーされたインスタンスを階層に正しく位置付けるために、分離スコープにおいてプレースホルダとして作成される。新規にコピーされたスコープ付きインスタンスは文字キーとして識別され（ステップ８４２）、文字キーを開くための要求が発行され、結果が要求元に返される（ステップ８２０）。
【０１４５】
図８をさらに詳細に参照すると、仮想レジストリキーを開くための要求が受信または傍受される（ステップ８０２）。対応する文字レジストリキーは、ユーザ分離スコープ、アプリケーション分離スコープまたはシステムスコープのものであってよく、アプリケーション分離サブスコープまたはユーザ分離サブスコープに範囲付けてもよい。いくつかの実施形態において、要求は、レジストリキーを開くためのオペレーティングシステム機能を置換する機能によってフックされる。別の実施形態において、要求を傍受するためにフッキング動的リンクライブラリが使用される。フッキング機能は、ユーザモードまたはカーネルモードで実行することができる。フッキング機能がユーザモードで実行する実施形態では、フッキング機能は、プロセスが作成される際に当該プロセスのアドレス空間にロードされてよい。フッキング機能がカーネルモードで実行する実施形態では、フッキング機能は、ネイティブレジストリキーの要求をディスパッチするのに使用されるオペレーティングシステムリソースと関連付けられてよい。レジストリキー動作の種類ごとに別個のオペレーティングシステム機能が提供される実施形態では、各機能は別個にフックされてよい。あるいは、数種類のレジストリキー動作の作成コールまたはオープンコールを傍受する単一のフッキング機能を提供してよい。
【０１４６】
要求は、分離環境によって仮想レジストリキー名として扱われるレジストリキー名を含有する。ルールエンジンを調べることにより、レジストリキーオープン要求に適用可能な処理ルールが判定される（ステップ８０４）。いくつかの実施形態において、ルールエンジンは、リレーショナルデータベースとして提供される場合がある。その他の実施形態において、ルールエンジンは、木構造データベース、ハッシュテーブル、またはフラットファイルデータベースであってよい。いくつかの実施形態において、要求されたレジストリキーに提供された仮想レジストリキー名は、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。これらの実施形態のうち特定のものにおいて、特定のレジストリキーのルールエンジンに多くのルールが存在する場合があり、これらの実施形態において、仮想レジストリキー名と一致する最も長い接頭辞を有するルールは、要求に適用されるルールである。その他の実施形態において、プロセス識別子は、存在する場合、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。要求に関連するルールは、要求を無視すること、要求をリダイレクトすること、または要求を分離することであってよい。図８では単一のデータベーストランザクションまたは単一のファイル内検索として示されているが、ルール検索は一連のルール検索として行われてもよい。
【０１４７】
ルールアクションが「リダイレクトする」である場合（ステップ８０６）、要求中に提供された仮想レジストリキー名は、適用可能なルールに従って文字レジストリキー名にマップされる（ステップ８０８）。文字レジストリキー名を使用して文字レジストリキーを開くための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ８１０）。例えば、「ｒｅｇｉｓｔｒｙ＿ｋｅｙ＿１」と名付けられたレジストリキーを開くための要求により、「Ｄｉｆｆｅｒｅｎｔ＿ｒｅｇｉｓｔｒｙ＿ｋｅｙ＿１」と名付けられた文字レジストリキーを開くことができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。その他の実施形態において、ファイルシステムフィルタドライバ設備と概念的に同様のレジストリフィルタドライバ設備が、オペレーティングシステムによって提供される場合がある。これらの実施形態において、文字レジストリキーを開くことは、判定された文字キー名を使用して要求を再構文解析するようレジストリフィルタマネージャに信号を送り、仮想キーを開くための元の要求に応答することによって達成できる。そうではなく、ルールアクションが「無視する」である場合（ステップ８０６）、文字レジストリキー名は厳密には仮想レジストリキー名であると判定され（ステップ８１２）、文字レジストリキーを開くための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ８１０）。例えば、「ｒｅｇｉｓｔｒｙ＿ｋｅｙ＿１」と名付けられたレジストリキーを開くための要求により、「ｒｅｇｉｓｔｒｙ＿ｋｅｙ＿１」と名付けられた文字レジストリキーを開くことになる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。別の実施形態において、これは、元の無修正の要求に対する処理を標準のやり方で継続するようレジストリフィルタマネージャに信号を送ることによって実現される。
【０１４８】
ステップ８０６において、ルールアクションが「分離する」である場合、仮想レジストリキー名に対応するユーザスコープ付きレジストリキー名が候補レジストリキー名として識別される（ステップ８１４）。換言すると、候補レジストリキー名は、適用可能なユーザ分離スコープに固有の対応するネイティブレジストリキー名に仮想レジストリキー名をマップすることによって形成される。例えば、「ｒｅｇｉｓｔｒｙ＿ｋｅｙ＿１」と名付けられたレジストリキーを開くための要求により、「Ｉｓｏｌａｔｅｄ＿ＵｓｅｒＳｃｏｐｅ＿ＵｓｅｒＡ＿ｒｅｇｉｓｔｒｙ＿ｋｅｙ＿１」と名付けられた文字レジストリキーを開くことができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。その他の実施形態において、文字レジストリキーを開くことは、判定された文字キー名を使用して要求を再構文解析するようレジストリフィルタマネージャに信号を送り、仮想キーを開くための元の要求に応答することによって達成できる。
【０１４９】
いくつかの実施形態において、要求された仮想レジストリキーを分離するために形成された文字名は、受信した仮想レジストリキー名およびスコープ固有の識別子に基づくものであってよい。スコープ固有の識別子は、アプリケーション分離スコープ、ユーザ分離スコープ、セッション分離スコープ、アプリケーション分離サブスコープ、ユーザ分離サブスコープ、または上記のいくつかの組み合わせに関連する識別子であってよい。スコープ固有の識別子は、要求中に受信した仮想名を「マングルする」ために使用される。
【０１５０】
その他の実施形態において、ユーザ分離スコープまたはサブスコープは、ユーザ分離スコープ内に存在するすべてのキーが保存されるレジストリキーであってよい。これらの実施形態のいくつかにおいて、ユーザ分離キーの下のキー階層は、要求されたリソースのパスを反映している。換言すると、文字キーパスは、仮想キーパスをユーザ分離スコープにマップすることによって形成される。例えば、要求されたキーがＨＫＬＭ＼Ｓｏｆｔｗａｒｅ＼Ｃｉｔｒｉｘ＼ＭｙＫｅｙであり、ユーザ分離スコープキーがＨＫＣＵ＼Ｓｏｆｔｗａｒｅ＼ＵｓｅｒＳｃｏｐｅ＼である場合、ユーザスコープ付き文字キーへのパスはＨＫＣＵ＼Ｓｏｆｔｗａｒｅ＼ＵｓｅｒＳｃｏｐｅ＼ＨＫＬＭ＼Ｓｏｆｔｗａｒｅ＼Ｃｉｔｒｉｘ＼ＭｙＫｅｙであってよい。その他の実施形態において、ユーザスコープ付き文字へのパスは、ネイティブ命名規則において定義されてよい。例えば、ユーザスコープ付き文字キーへのパスは、ＨＫＣＵ＼Ｓｏｆｔｗａｒｅ＼ＵｓｅｒＳｃｏｐｅ＼Ｒｅｇｉｓｔｒｙ＼Ｍａｃｈｉｎｅ＼Ｓｏｆｔｗａｒｅ＼Ｃｉｔｒｉｘ＼ＭｙＫｅｙであってよい。また他の実施形態において、ユーザスコープ付きキーは、唯一であるように選ばれた名前を持つ単一のキーの下にすべて保存されてよく、データベースは、要求されたキー名とユーザ分離キーに保存されている対応する文字キーの名前との間のマッピングを保存するために使用されてよい。また他の実施形態において、文字キーの内容はデータベースまたはファイルストアに保存されてよい。
【０１５１】
候補キーが存在するカテゴリは、ユーザ分離スコープおよび候補キーに関連する任意のメタデータを調査することによって判定される（ステップ８１６）。候補キーが「否定的存在」を有すると判定された場合、当該候補キーまたはユーザ分離スコープ内のその祖先キーの１つのいずれかが削除されたものとしてマークされているため、これは要求された仮想キーが存在しないと分かっていることを意味する。この場合、要求されたキーが見つからないことを示すエラー状態が要求元に返される（ステップ８２２）。
【０１５２】
いくつかの実施形態において、文字レジストリキーは、仮想化されたレジストリキーが既に削除されたことを示すメタデータに関連付けられる場合がある。いくつかの実施形態において、レジストリキーについてのメタデータは、当該キーが保持する識別値に保存されてよく、当該値の存在は、通常のアプリケーションで使用のレジストリＡＰＩから隠される。いくつかの実施形態において、レジストリキーについての少量のメタデータが、仮想名にメタデータ識別子で接尾辞を付ける等によって文字キー名に直接的に保存されてよく、ここでメタデータ識別子は特定のメタデータ状態に一意に関連する文字列である。メタデータ識別子は、１または数ビットのメタデータを示す、または符号化することができる。メタデータ識別子の存在による文字キー名の考えられる変形に関する仮想名チェックによってキーにアクセスするための要求、およびキー名自体を検索するための要求は、文字名で応答するためにフックまたは傍受される。その他の実施形態において、メタデータ識別子は、キー名自体の代わりにサブキー名またはレジストリ値名において符号化されてよい。また他の実施形態において、レジストリキーシステムは、各キーに、いくつかの第三者メタデータを保存する能力を直接的に提供することができる。いくつかの実施形態において、メタデータは、データベース、またはレジストリデータベースから離れたその他のリポジトリに保存される。いくつかの実施形態において、別個のサブスコープは、削除されたものとしてマークされているキーを保存するために使用されてよい。サブスコープ内のキーの存在は、当該キーが削除されたものとしてマークされていることを示す。
【０１５３】
これらの実施形態のうち特異のものにおいて、削除されたキーまたはキーシステム要素のリストは、この削除されたキーに関するチェックを最適化するために維持され調べられてよい。これらの実施形態において、削除されたキーが再作成されると、キー名は削除されたキーのリストから除去されてよい。これらの実施形態のうちのその他において、リストが一定サイズを超えた場合、キー名はリストから除去されてよい。
【０１５４】
そうではなく、ステップ８１６において候補キーが「肯定的存在」を有すると判定された場合、候補キーはユーザ分離スコープに存在しており、プレースホルダノードとしてマークされていないため、要求された仮想キーは存在すると分かっている。候補キーは、要求に対する文字キーとして識別され（ステップ８１８）、文字キーを開くために要求が発行され、結果が要求元に要求元に返される（ステップ８２０）。
【０１５５】
しかしながら、ステップ８１６において、候補キーが「中立的存在」を有する場合、候補キーは存在しないため、または候補キーは存在するがプレースホルダノードとしてマークされているため、仮想キーが存在するか否かはまだ分かっていない。この場合、仮想キー名に対応するアプリケーションスコープ付きキー名は、候補キー名として識別される（ステップ８２４）。換言すると、候補キー名は、適用可能なアプリケーション分離スコープに固有の対応するネイティブキー名に仮想キー名をマップすることによって形成される。候補キーが存在するカテゴリは、アプリケーション分離スコープおよび候補キーに関連する任意のメタデータを調査することによって判定される（ステップ８２６）。
【０１５６】
アプリケーションスコープ付き候補キーが「否定的存在」を有すると判定された場合、当該候補キーまたはアプリケーション分離スコープ内のその祖先キーの１つのいずれかが削除されたものとしてマークされているため、これは要求された仮想キーが存在しないと分かっていることを意味する。この場合、要求されたキーが見つからないことを示すエラー状態が要求元に返される（ステップ８２２）。
【０１５７】
しかしながら、ステップ８２６において候補キーが「肯定的存在」を有すると判定された場合、候補キーはアプリケーション分離スコープに存在しており、プレースホルダノードとしてマークされていないため、要求された仮想キーは存在すると分かっている。オープン要求がキーを修正する意図を示しているか否かを判定するために、要求はチェックされる（ステップ８２８）。示していない場合、候補キーは要求に対する文字キーとして識別され（ステップ８１８）、文字キーを開くために要求が発行され、結果が要求元に返される（ステップ８２０）。
【０１５８】
しかしながら、ステップ８２８において、オープン要求がキーを修正する意図を示していると判定された場合、キーの修正が許容されているか否かを判定するために、キーに関連する許可データがチェックされる（ステップ８３６）。いくつかの実施形態において、許可データはアプリケーションスコープ付き候補キーと関連付けられる。これらの実施形態のいくつかにおいて、許可データは、ルールエンジンに、または、候補キーに関連するメタデータに保存される。その他の実施形態において、候補キーに関連する許可データがオペレーティングシステムによって提供される。さらに、ルールエンジンは、リソースの仮想化されたコピーのネイティブ許可データに従うか、またはそれを無効にするよう分離環境に命令する構成設定を含んでよい。いくつかの実施形態において、ルールは、例えばシステムスコープまたはアプリケーション分離スコープもしくはサブスコープ、またはユーザ分離スコープもしくはサブスコープ等、いくつかの仮想リソースに対し、修正が発生するスコープを特定してよい。いくつかの実施形態において、ルールエンジンは、階層に基づいて、仮想化されたネイティブリソースのサブセットに当てはまる構成設定を特定することができる。これらの実施形態のいくつかにおいて、構成設定は、各アトミックネイティブリソースに固有である場合がある。
【０１５９】
候補キーに関連する許可データが、修正してはいけないことを示す場合、キーの修正が許容されていないことを示すエラー状態が要求元に返される（ステップ８３８）。キーを修正してよいことを許可データが示す場合、候補キーはユーザ分離スコープにコピーされる（ステップ８４０）。いくつかの実施形態において、候補キーはルールエンジンによって定義された位置にコピーされる。例えば、ルールは、キーが別のアプリケーション分離スコープにコピーされると特定することができる。その他の実施形態において、ルールは、キーをコピーすべき特定のアプリケーション分離サブスコープまたはユーザ分離サブスコープを特定することができる。キーがコピーされる分離スコープに現われない要求されたキーのあらゆる祖先は、コピーされたインスタンスを階層に正しく位置付けるために、分離スコープにおいてプレースホルダとして作成される。
【０１６０】
いくつかの実施形態において、キーがコピーされた日時を示すメタデータが、分離スコープにコピーされたキーに関連付けられる。この情報は、キーのコピーされたインスタンスに関連するタイムスタンプを、キーの元のインスタンスの、または下位分離スコープに位置するキーの別のインスタンスの、前回の修正のタイムスタンプと比較するために使用される場合がある。これらの実施形態において、キーの元のインスタンス、または下位分離スコープに位置するキーのインスタンスが、コピーされたキーのタイムスタンプよりも後のタイムスタンプに関連付けられている場合、当該キーを分離スコープにコピーして候補キーを更新してよい。その他の実施形態において、分離スコープ内のキーのコピーは、コピーされた元のキーを含有するスコープを識別するメタデータと関連付けられてよい。
【０１６１】
さらなる実施形態において、分離スコープにコピーされたキーは、それらを修正する意図を持って開かれたものであるため、現実に修正されるか否かを判定するために監視される場合がある。一実施形態において、コピーされたキーは、キーが実際に修正された際に設定されるフラグと関連付けられてよい。これらの実施形態において、コピーされたキーが実際に修正されない場合、コピーされたキーに関連するあらゆるプレースホルダノードに加えて、当該キーも、閉じられた後に、コピーされたスコープから除去されてよい。
【０１６２】
スコープ付きインスタンスは文字キーとして識別され（ステップ８４２）、文字キーを開くために要求が発行され、結果が要求元に返される（ステップ８２０）。
【０１６３】
ステップ８２６に戻って、候補キーは存在しないため候補キーが中立的存在を有する場合、または候補キーは見つかったがプレースホルダノードとしてマークされている場合、仮想キーが存在するか否かはまだ分かっていない。この場合、仮想キー名に対応するシステムスコープ付きキー名は、候補キー名として識別される（ステップ８３０）。換言すると、候補キー名は厳密には仮想キー名である。
【０１６４】
候補キーが存在しない場合（ステップ８３２）、仮想キーが見つからなかったことを示すエラー状態が要求元に返される（ステップ８３４）。一方、候補キーが存在する場合（ステップ８３２）、オープン要求がキーを修正する意図を示しているか否かを判定するために、要求はチェックされる（ステップ８２８）。
【０１６５】
上述のように、候補キーがそれを修正することを意図せずに開かれている場合、システムスコープ付き候補キーは要求に対する文字キーとして識別され（ステップ８１８）、文字キーを開くために要求が発行され、結果が要求元に返される（ステップ８２０）。しかしながら、ステップ８２８において、オープン要求がキーを修正する意図を示していると判定された場合、キーの修正が許容されているか否かを判定するために、キーに関連する許可データがチェックされる（ステップ８３６）。いくつかの実施形態において、許可データはアプリケーションスコープ付き候補キーと関連付けられる。これらの実施形態のいくつかにおいて、許可データは、ルールエンジンに、または、候補キーに関連するメタデータに保存される。その他の実施形態において、候補キーに関連する許可データがオペレーティングシステムによって提供される。さらに、ルールエンジンは、リソースの仮想化されたコピーのネイティブ許可データに従うか、またはそれを無効にするよう分離環境に命令する構成設定を含んでよい。いくつかの実施形態において、ルールは、例えばシステムスコープまたはアプリケーション分離スコープもしくはサブスコープ、またはユーザ分離スコープもしくはサブスコープ等、いくつかの仮想リソースに対し、修正が発生するスコープを特定してよい。いくつかの実施形態において、ルールエンジンは、階層に基づいて、仮想化されたネイティブリソースのサブセットに当てはまる構成設定を特定することができる。これらの実施形態のいくつかにおいて、構成設定は、各アトミックネイティブリソースに固有である場合がある。
【０１６６】
システムスコープ付き候補キーに関連する許可データが、当該キーを修正してはいけないことを示す場合、キーの修正が許容されていないことを示すエラー状態が要求元に返される（ステップ８３８）。しかしながら、キーを修正してよいことを許可データが示す場合、候補キーはユーザ分離スコープにコピーされる（ステップ８４０）。いくつかの実施形態において、候補キーはルールエンジンによって定義された位置にコピーされる。例えば、ルールは、キーがアプリケーション分離スコープにコピーされる、またはシステムスコープに残されてよいと特定することができる。その他の実施形態において、ルールは、キーをコピーすべき特定のアプリケーション分離サブスコープまたはユーザ分離サブスコープを特定することができる。分離スコープに現われない要求されたキーのあらゆる祖先は、コピーされたインスタンスを階層に正しく位置付けるために、分離スコープにおいてプレースホルダとして作成される。
【０１６７】
いくつかの実施形態において、キーがコピーされた日時を示すメタデータが、分離スコープにコピーされたキーに関連付けられる。この情報は、キーのコピーされたインスタンスに関連するタイムスタンプを、キーの元のインスタンスの前回の修正のタイムスタンプと比較するために使用される場合がある。これらの実施形態において、キーの元のインスタンスが、コピーされたキーのタイムスタンプよりも後のタイプスタンプに関連付けられている場合、元のキーを分離スコープにコピーして候補キーを更新してよい。その他の実施形態において、分離スコープにコピーされた候補キーは、元のファイルのコピー元であるスコープを示すメタデータと関連付けられてよい。
【０１６８】
さらなる実施形態において、分離スコープにコピーされたキーは、それらを修正する意図を持って開かれたものであるため、現実に修正されるか否かを判定するために監視される場合がある。一実施形態において、コピーされたキーは、キーが実際に修正された際に設定されるフラグと関連付けられてよい。これらの実施形態において、コピーされたキーが実際に修正されない場合、コピーされたキーに関連するあらゆるプレースホルダノードに加えて、当該キーも、閉じられた際に、コピーされたスコープから除去されてよい。またさらなる実施形態において、キーは、実際に修正される際に適切な分離スコープにコピーされるのみである。
【０１６９】
スコープ付きインスタンスは、文字キーとして識別され（ステップ８４２）、文字キーを開くために要求が発行され、結果が要求元に返される（ステップ８２０）。
【０１７０】
４．２．２  レジストリキー削除動作
図９および概要を参照すると、レジストリキーを削除するために取られるステップの一実施形態が描写されている。キーを削除できる前に、まず当該キーが削除アクセスによってうまく開かれなくてはならない（ステップ９０１）。キーがうまく開かれない場合、エラーが返される（ステップ９１６）。仮想キーがうまく開かれた場合、仮想化されたレジストリキーを削除するための要求であって、仮想キーに対応する文字キーのハンドルを含む要求が、受信または傍受される（ステップ９０２）。ルールは、レジストリキー動作がどのように処理されるかを判定する（ステップ９０４）。削除されるキーに適用可能なルールに加えて、直接のサブキーに適用可能なその他任意のルールが調査される（ステップ９０５）。見つかった直接のサブキーに適用可能な各ルールについて、仮想サブキーを開く試みが行われ、当該仮想サブキーの名前は、ステップ９０５で見つかったルールにおいて与えられた名前により特定される。ステップ９０５で見つかったルールの１つに対応する名前を持つサブキーがうまく開かれた場合（ステップ９０６）、仮想キーはサブキーを有すると考えられ、これは削除できないことを意味し、エラーが返される（ステップ９０７）。
【０１７１】
ステップ９０５において抽出されたすべての仮想キー名を開くよう試みた後（ステップ９０６）、仮想キーが存在しないことが判明した場合、さらなる調査が必要である。ルールアクションが「分離する」ではなく「リダイレクトする」または「無視する」である場合（ステップ９０８）、文字レジストリキーを削除するための要求はオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ９１１）。しかしながら、ステップ９０８において判定されたルールアクションが「分離する」である場合、仮想サブキーを含有するか否かを判定するために、集約された仮想化レジストリキーが調べられる（ステップ９１４）。仮想化されたキーが仮想サブキーを有する場合、削除は継続できず、キーは削除されなかったことを示すエラーが返される（ステップ９２０）。仮想化されたキーが仮想サブキーを有さない場合、別のスコープレベルにおいて同じ仮想名を持つスコープ付きキーをマスクするか否かを判定するために、仮想キーに対応する文字キーが調査される（ステップ９２２）。仮想キーに対応する文字キーが、同じ仮想名を持つ、異なるスコープ付きキーをマスクしない場合、仮想キーに対応する文字キーは削除され、結果が返される（ステップ９２６）。仮想キーに対応する文字キーが、同じ仮想名を持つ、異なるスコープ付きキーをマスクする場合、仮想キーに対応する文字キーは、削除されたことを示す値でマークされ、成功結果がコール元に返される（ステップ９２４）。
【０１７２】
図９をさらに参照すると、キーを削除するためには、まず削除アクセスによって開かれなくてはならない（ステップ９０１）。削除アクセスによってキーを開くための要求は、分離環境によって仮想名として扱われるキーの名前を含む。第４．２．１節で記載したように、完全仮想化されたキーオープンが行われる。仮想化オープン動作が失敗した場合、エラーが要求元に返される（ステップ９１６）。仮想化オープン動作が成功した場合、仮想キーに対応する文字キーのハンドルが要求元に返される。その後、ステップ９０１において開かれたレジストリキーを削除するための要求が受信または傍受される（ステップ９０２）。開かれた文字レジストリキーは、ユーザ分離スコープ、アプリケーション分離スコープ、システムスコープ、または何らかの適用可能な分離サブスコープのものであってよい。いくつかの実施形態において、削除要求は、レジストリキーを削除するためのオペレーティングシステム機能を置換する機能によってフックされる。別の実施形態において、削除要求を傍受するために、フッキング動的リンクライブラリが使用される。フッキング機能は、ユーザモードまたはカーネルモードで実行することができる。フッキング機能がユーザモードで実行する実施形態では、フッキング機能は、プロセスが作成される際に当該プロセスのアドレス空間にロードされてよい。フッキング機能がカーネルモードで実行する実施形態では、フッキング機能は、ネイティブレジストリキーの要求をディスパッチするのに使用されるオペレーティングシステムリソースと関連付けられてよい。その他の実施形態において、ファイルシステムフィルタドライバ設備と概念的に同様のレジストリフィルタドライバ設備が、オペレーティングシステムによって提供される場合がある。当業者であれば、オペレーティングシステムがレジストリ動作を行うための要求を渡すレジストリフィルタドライバを作成し、それにより、レジストリ動作要求を傍受するためのメカニズムを提供することができる。レジストリキー機能の種類ごとに別個のオペレーティングシステムが提供される実施形態では、各機能は別個にフックされてよい。あるいは、数種類のレジストリキー機能の作成コールまたはオープンコールを傍受する単一のフッキング機能を提供してよい。
【０１７３】
削除要求は、文字キーハンドルを含有する。ハンドルに関連する仮想キー名は、オペレーティングシステムに対して、ハンドルに関連する文字名をクエリすることによって判定される。もしあれば、文字名に関連する仮想名を判定するために、ルールエンジンが調べられる。ルールエンジンを調べることによって、レジストリキー動作をどのように処理するかを判定するルールが得られる（ステップ９０４）。いくつかの実施形態において、削除される仮想レジストリキーの仮想キー名は、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。これらの実施形態のうち特定のものにおいて、特定の仮想レジストリキーのルールエンジンに多くのルールが存在する場合があり、これらの実施形態のいくつかにおいて、仮想キー名と一致する最も長い接頭辞を有するルールは、要求に適用されるルールである。いくつかの実施形態において、ルールエンジンは、リレーショナルデータベースとして提供される場合がある。その他の実施形態において、ルールエンジンは、木構造データベース、ハッシュテーブル、またはフラットレジストリキーデータベースであってよい。いくつかの実施形態において、要求中の仮想キーハンドルに対応する仮想キー名は、要求に当てはまる１つ以上のルールをルールエンジン内に位置付けるための索引として使用される。いくつかの実施形態において、プロセス識別子は、存在する場合、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。要求に関連するルールは、要求を無視すること、要求をリダイレクトすること、または要求を分離することであってよい。ルール検索は一連の決定として発生してもよいし、ルール検索は単一のデータベーストランザクションとして発生してもよい。
【０１７４】
削除されるキーの仮想名は、削除される仮想キーに適用可能なものではなく、削除する仮想キーの任意の直接の子キーに適用可能なルールのセットを位置付けるため、ルールエンジンを調べるのに使用される。このルールのセットは、それらの子キーが存在するか否かにかかわらず、位置付けられる（ステップ９０５）。この直接の子キーに適用可能なルールのセットが空でない場合、これらのルールのそれぞれの仮想名が抽出される。抽出された仮想子キー名のそれぞれの完全仮想化オープンをする試みが順に行われる（ステップ９０６）。これらの仮想名のいずれかに対応する仮想キーのいずれかをうまく開くことができた場合、これは仮想サブキーが存在することを意味する。これは、存在する仮想子を有するために仮想キーを削除できないことを意味し、エラーが返される（ステップ９０７）。仮想キーの直接の子に適用可能なルールのセットをすべて調査した後（ステップ９０５）、仮想サブキーが存在しないことが判明した場合、削除を継続することができる。例えば、仮想名「ｋｅｙ＿１」を持つキーは、「ｋｅｙ１＼ｓｕｂｋｅｙ＿１」および「ｋｅｙ１＼ｓｕｂｋｅｙ＿２」に適用可能な子ルールを有することができる。このステップにおいて、「ｋｅｙ１＼ｓｕｂｋｅｙ＿１」および「ｋｅｙ１＼ｓｕｂｋｅｙ＿２」の仮想化オープンをする試みが行われる。これらのサブキーのうちいずれかをうまく開くことができた場合、削除は失敗し、エラーが返される（ステップ９０７）。これらの仮想サブキーがいずれも存在しない場合のみ、削除を継続することができる。
【０１７５】
ルールアクションが「分離する」ではなく「リダイレクトする」である、または「無視する」である場合（ステップ９０８）、文字キーハンドルを使用して文字レジストリキーを削除するための要求がオペレーティングシステムに渡され、オペレーティングシステムからの結果が要求元に返される（ステップ９１１）。文字キーが文字サブキーを含有する場合、この要求は失敗することになる。一実施形態において、文字レジストリキーを削除するための要求は、フックされた機能のオリジナルバージョンをコールし、文字キーハンドルを引数としてその機能に渡すことによって実現される。レジストリフィルタドライバを活用する実施形態において、これは、要求に対し通常処理を行うようオペレーティングシステムに信号を送る完了状態で要求に応答することによって実現される。いくつかの実施形態において、文字レジストリキーに関連するオペレーティングシステム許可は、その削除を防止することができる。これらの実施形態において、仮想レジストリキーを削除できなかったというエラーメッセージが返される。
【０１７６】
ステップ９０８において判定されたルールアクションが「分離する」である場合、集約された仮想レジストリキーは、仮想サブキーを含有するか否かを判定するために調べられる（ステップ９１４）。要求された仮想レジストリキーが仮想サブキーを含有する場合、仮想キーは削除できず、エラーがコール元に返される（ステップ９２０）。
【０１７７】
要求された仮想レジストリキーが仮想サブキーを含有しない場合、仮想キーは削除されることができる。次に取られるアクションは、削除される文字キーを含有するスコープによって異なる。例えば、仮想レジストリキーを削除するための要求により、アプリケーションスコープ付き文字キーを削除することができる。文字キーを含有するスコープは、文字キーへのフルパスでルールエンジンを調べることによって判定できる。
【０１７８】
削除される文字キーが特定のスコープ内で見つかり、当該文字キーが別のスコープ内の同じ仮想名の別のキーをマスクする場合、削除される文字キーは削除されたものとしてマークされ、結果が要求元に返される（ステップ９２４）。例えば、同じ仮想名を持つ対応するアプリケーションスコープ付きキーまたは同じ仮想名を持つ対応するシステムスコープ付きキーが「肯定的存在」を有する場合、すなわち、スコープ内に存在し、プレースホルダとしてマークされておらず、削除されないと考えられる場合、ユーザスコープ付き文字キーに対応する仮想キーは、異なるスコープ付きキーをマスクすると考えられる。同様に、同じ仮想名に対応するシステムスコープ付きキーが存在し、削除されないと考えられる場合、アプリケーションスコープ付きキーは、当該システムスコープ付きキーをマスクすると考えられる。
【０１７９】
削除される文字キーが別のスコープ内の同じ仮想名の別のキーをマスクしないことが判明した場合、削除される文字キーは実際に削除され、結果が返される（ステップ９２６）。
【０１８０】
いくつかの実施形態において、文字レジストリキーと関連するオペレーティングシステム許可は、文字レジストリキーの削除を防止することができる。これらの実施形態において、仮想レジストリキーを削除することができなかったというエラーメッセージが返される。
【０１８１】
いくつかの実施形態において、文字レジストリキーは、仮想化レジストリキーが既に削除されたことを示すメタデータと関連付けられてよい。いくつかの実施形態において、レジストリキーについてのメタデータは、当該キーが保持する識別値に保存されてよく、当該値の存在は、通常のアプリケーションで使用のレジストリＡＰＩから隠される。いくつかの実施形態において、レジストリキーについての少量のメタデータが、仮想名にメタデータ識別子で接尾辞を付ける等によって文字キー名に直接的に保存されてよく、ここでメタデータ識別子は特定のメタデータ状態に一意に関連する文字列である。メタデータ識別子は、１または数ビットのメタデータを示す、または符号化することができる。メタデータ識別子の存在による文字キー名の考えられる変形に関する仮想名チェックによってキーにアクセスするための要求、およびキー名自体を検索するための要求は、文字名で応答するためにフックまたは傍受される。その他の実施形態において、メタデータ識別子は、キー名自体の代わりにサブキー名またはレジストリ値名において符号化されてよい。また他の実施形態において、レジストリキーシステムは、各キーに、いくつかの第三者メタデータを保存する能力を直接的に提供することができる。いくつかの実施形態において、メタデータは、データベース、またはレジストリデータベースから離れたその他のリポジトリに保存され得る。いくつかの実施形態において、別個のサブスコープは、削除されたものとしてマークされているキーを保存するために使用されてよい。サブスコープ内のキーの存在は、当該キーが削除されたものとしてマークされていることを示す。
【０１８２】
これらの実施形態のうち特異のものにおいて、削除されたキーまたはキーシステム要素のリストは、この削除されたキーに関するチェックを最適化するために維持され調べられてよい。これらの実施形態において、削除されたキーが再作成されると、キー名は削除されたキーのリストから除去されてよい。これらの実施形態のうちのその他において、リストが一定サイズを超えた場合、キー名はリストから除去されてよい。
【０１８３】
いくつかの実施形態において、同じスコープ内の文字レジストリキーの祖先は、それが削除されることを示すメタデータと関連付けられるか、または削除されることが示される。これらの実施形態において、仮想化されたレジストリキーが存在しないことを示すエラーメッセージが返される場合がある。これらの実施形態のうち特異のものにおいて、削除されたレジストリキーまたはレジストリキーシステム要素のリストは、この削除されたレジストリキーに関するチェックを最適化するために維持され調べられてよい。
【０１８４】
４．２．３  レジストリキー列挙動作
図１０および概要を参照すると、上述の仮想化環境において、キーを列挙するために取られるステップの一実施形態が示されている。キーが列挙される前に、まず当該キーが列挙アクセスによってうまく開かれなくてはならない（ステップ１００１）。キーがうまく開かれない場合、エラーが返される（ステップ１０４０）。仮想キーがうまく開かれた場合、列挙するための要求であって、仮想キーに対応する文字キーのハンドルを含む要求が、受信または傍受される（ステップ１００２）。
【０１８５】
ハンドルに対応する仮想キー名が判定され、列挙要求中に特定されたキーのルールを判定するためにルールエンジンが調べられる（ステップ１００４）。ルールが「分離する」のアクションを特定せず、「無視する」を特定するか、「リダイレクトする」を特定する場合（ステップ１００６）、文字キーハンドルによって識別された文字キーが列挙され、列挙結果が作業データストアに保存され（ステップ１０１２）、以下で説明するようにステップ１０３０に続く。
【０１８６】
しかしながら、ルールアクションが「分離する」を特定する場合、まずシステムスコープが列挙される、すなわち、候補キー名は厳密には仮想キー名であり、候補キーが存在する場合にはそれが列挙される。列挙結果は作業データストアに保存される。候補キーが存在しない場合、作業データストアはこの段階では空のままである（ステップ１０１４）。次に、候補キーは仮想キーのアプリケーションスコープ付きインスタンスとして識別され、候補キーが存在するカテゴリが判定される（ステップ１０１５）。候補キーが「否定的存在」を有する場合、すなわち、当該キーまたはスコープ内にあるその祖先の１つが削除されたものとしてマークされている場合、このスコープ内では削除されることが分かっており、これは作業データストアを一括消去することによって示される（ステップ１０４２）。そうではなく、候補キーが否定的存在を有さない場合、当該候補キーは列挙され、得られたあらゆる列挙結果が作業データストアにマージされる。特に、列挙内の各サブキーについて、その存在のカテゴリが判定される。否定的存在を持つサブキーは作業データストアから除去され、肯定的存在を持つサブキー、すなわち、存在しているがプレースホルダとしてマークされておらず、かつ削除されたものとしてマークされていないサブキーは、作業データストアに追加され、作業データストアに既に存在しているものがある場合には、対応するサブキーと置換する（ステップ１０１６）。
【０１８７】
いずれの場合も、候補キーは仮想キーのユーザスコープ付きインスタンスとして識別され、候補キーが存在するカテゴリが判定される（ステップ１０１７）。候補キーが「否定的存在」を有する場合、すなわち、当該キーまたはスコープ内にあるその祖先の１つが削除されたものとしてマークされている場合、このスコープ内では削除されることが分かっており、これは作業データストアを一括消去することによって示される（ステップ１０４４）。そうではなく、候補キーが否定的存在を有さない場合、当該候補キーは列挙され、得られたあらゆる列挙結果が作業データストアにマージされる。特に、列挙内の各サブキーについて、その存在のカテゴリが判定される。否定的存在を持つサブキーは作業データストアから除去され、肯定的存在を持つサブキー、すなわち、存在しているがプレースホルダとしてマークされておらず、かつ削除されたものとしてマークされていないサブキーは、作業データストアに追加され、作業データストアに既に存在しているものがある場合には、対応するサブキーと置換し（ステップ１０１８）、以下で説明するようにステップ１０３０に続く。
【０１８８】
次いで、３種類すべてのルールについて、ステップ１０３０が実行される。ルールエンジンは、そのフィルタが要求された仮想キー名の直接の子には一致するが要求された仮想キー名自体には一致しないルールのセットを見つけるためにクエリされる（ステップ１０３０）。セット内の各ルールについて、その名前がルール内の名前に一致する仮想子の存在が判定される。子が肯定的存在を有する場合、作業データストアに追加され、既にそこにある同じ名前の任意の子と置換する。子が否定的存在を有する場合、子に対応する作業データストア内のエントリは、もしあれば、除去される（ステップ１０３２）。そして最後に、構築された列挙は、作業データストアから要求元に返される（ステップ１０２０）。
【０１８９】
図１０をさらに詳細に参照すると、キーを列挙するためには、まず当該キーが列挙アクセスによって開かれなくてはならない（ステップ１００１）。列挙アクセスによってキーを開くための要求は、分離環境によって仮想名として扱われるキーの名前を含む。第４．２．１節で記載したように、完全仮想化されたキーオープンが行われる。仮想化オープン動作が失敗した場合、エラーが要求元に返される（ステップ１０４０）。仮想化オープン動作が成功した場合、仮想キーに対応する文字キーのハンドルが要求元に返される。その後、ステップ１００１において開かれたレジストリキーを列挙するための要求が受信または傍受される（ステップ１００２）。開かれた文字レジストリキーは、ユーザ分離スコープ、アプリケーション分離スコープ、システム分離スコープ、または何らかの適用可能な分離サブスコープのものであってよい。いくつかの実施形態において、列挙要求は、レジストリキーを列挙するためのオペレーティングシステム機能を置換する機能によってフックされる。別の実施形態において、列挙要求を傍受するために、フッキング動的リンクライブラリが使用される。フッキング機能は、ユーザモードまたはカーネルモードで実行することができる。フッキング機能がユーザモードで実行する実施形態では、フッキング機能は、プロセスが作成される際に当該プロセスのアドレス空間にロードされてよい。フッキング機能がカーネルモードで実行する実施形態では、フッキング機能は、ネイティブレジストリキーの要求をディスパッチするのに使用されるオペレーティングシステムリソースと関連付けられてよい。その他の実施形態において、ファイルシステムフィルタドライバ設備と概念的に同様のレジストリフィルタドライバ設備が、オペレーティングシステムによって提供される場合がある。当業者であれば、オペレーティングシステムがレジストリ動作を行うための要求を渡すレジストリフィルタドライバを作成し、それにより、レジストリ動作要求を傍受するためのメカニズムを提供することができる。レジストリキー機能の種類ごとに別個のオペレーティングシステムが提供される実施形態では、各機能は別個にフックされてよい。あるいは、数種類のレジストリキー機能の作成コールまたはオープンコールを傍受する単一のフッキング機能を提供してよい。
【０１９０】
列挙要求は、文字キーハンドルを含有する。ハンドルに関連する仮想キー名は、オペレーティングシステムに対して、ハンドルに関連する文字名をクエリすることによって判定される。もしあれば、文字名に関連する仮想名を判定するために、ルールエンジンが調べられる。
【０１９１】
ルールエンジンを調べることによって、レジストリキー動作をどのように処理するかを判定するルールが得られる（ステップ１００４）。いくつかの実施形態において、列挙される仮想レジストリキーの仮想キー名は、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。これらの実施形態のうち特定のものにおいて、特定の仮想レジストリキーのルールエンジンに多くのルールが存在する場合があり、これらの実施形態のいくつかにおいて、仮想キー名と一致する最も長い接頭辞を有するルールは、要求に適用されるルールである。いくつかの実施形態において、ルールエンジンは、リレーショナルデータベースとして提供される場合がある。その他の実施形態において、ルールエンジンは、木構造データベース、ハッシュテーブル、またはフラットレジストリキーデータベースであってよい。いくつかの実施形態において、要求中の仮想キーハンドルに対応する仮想キー名は、要求に当てはまる１つ以上のルールをルールエンジン内に位置付けるための索引として使用される。いくつかの実施形態において、プロセス識別子は、存在する場合、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。要求に関連するルールは、要求を無視すること、要求をリダイレクトすること、または要求を分離することであってよい。ルール検索は一連の決定として発生してもよいし、ルール検索は単一のデータベーストランザクションとして発生してもよい。
【０１９２】
ルールアクションが「分離する」ではなく（ステップ１００６）、「無視する」である、または「リダイレクトする」である場合、文字キーを列挙するための要求は文字キーハンドルを使用してオペレーティングシステムに渡され、列挙結果は、もしあれば、作業データストアに保存され（ステップ１０１２）、以下で説明するように、ステップ１０３０が実行される。
【０１９３】
一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。その他の実施形態において、ファイルシステムフィルタドライバ設備と概念的に同様のレジストリフィルタドライバ設備が、オペレーティングシステムによって提供される場合がある。これらの実施形態において、文字レジストリキーを列挙することは、無修正の要求を標準のやり方で処理するようレジストリフィルタマネージャに信号を送り、キーを列挙するための元の要求に応答することによって達成できる。
【０１９４】
ステップ１０１０において判定されたルールアクションが「分離する」である場合、システムスコープは列挙される。これを達成するために、候補キーは、列挙される仮想キーに対応するシステムスコープ付きキーとして識別される。候補キーが列挙され、列挙の結果が作業データストアに保存される（ステップ１０１４）。いくつかの実施形態において、作業データストアはメモリ素子からなる。その他の実施形態において、作業データストアは、データベースまたはキーまたは固体メモリ素子または永続的データストアを備える。
【０１９５】
次に、候補キーは仮想キーのアプリケーションスコープ付きインスタンスとして識別され、候補キーが存在するカテゴリが判定される（ステップ１０１５）。候補キーが「否定的存在」を有する場合、すなわち、当該候補キーまたはスコープ内にあるその祖先の１つが削除されたものとしてマークされている場合、このスコープ内では削除されることが分かっており、これは作業データストアを一括消去することによって示される（ステップ１０４２）。
【０１９６】
いくつかの実施形態において、候補レジストリキーは、候補レジストリキーが削除されたことを示すメタデータと関連付けられる場合がある。いくつかの実施形態において、レジストリキーについてのメタデータは、当該キーが保持する識別値に保存されてよく、当該値の存在は、通常のアプリケーションで使用のレジストリＡＰＩから隠される。いくつかの実施形態において、レジストリキーについての少量のメタデータが、仮想名にメタデータ識別子で接尾辞を付ける等によって文字キー名に直接的に保存されてよく、ここでメタデータ識別子は特定のメタデータ状態に一意に関連する文字列である。メタデータ識別子は、１または数ビットのメタデータを示す、または符号化することができる。メタデータ識別子の存在による文字キー名の考えられる変形に関する仮想名チェックによってキーにアクセスするための要求、およびキー名自体を検索するための要求は、文字名で応答するためにフックまたは傍受される。その他の実施形態において、メタデータ識別子は、キー名自体の代わりにサブキー名またはレジストリ値名において符号化されてよい。また他の実施形態において、レジストリキーシステムは、各キーに、いくつかの第三者メタデータを保存する能力を直接的に提供することができる。いくつかの実施形態において、メタデータは、データベース、またはレジストリデータベースから離れたその他のリポジトリに保存される。いくつかの実施形態において、別個のサブスコープは、削除されたものとしてマークされているキーを保存するために使用されてよい。サブスコープ内のキーの存在は、当該キーが削除されたものとしてマークされていることを示す。
【０１９７】
そうではなく、ステップ１０１５において、候補キーが否定的存在を有さない場合、当該候補キーは列挙され、得られたあらゆる列挙結果が作業データストアにマージされる。特に、列挙内の各サブキーについて、その存在のカテゴリが判定される。否定的存在を持つサブキーは作業データストアから除去され、肯定的存在を持つサブキー、すなわち、存在しているがプレースホルダとしてマークされておらず、かつ削除されたものとしてマークされていないサブキーは、作業データストアに追加され、作業データストアに既に存在しているものがある場合には、対応するサブキーと置換する（ステップ１０１６）。
【０１９８】
いずれの場合も、候補キーは仮想キーのユーザスコープ付きインスタンスとして識別され、候補キーが存在するカテゴリが判定される（ステップ１０１７）。候補キーが「否定的存在」を有する場合、すなわち、当該候補キーまたはスコープ内にあるその祖先の１つが削除されたものとしてマークされている場合、このスコープ内では削除されることが分かっており、これは作業データストアを一括消去することによって示される（ステップ１０４４）。そうではなく、候補キーが否定的存在を有さない場合、当該候補キーは列挙され、得られたあらゆる列挙結果が作業データストアにマージされる。特に、列挙内の各サブキーについて、その存在のカテゴリが判定される。否定的存在を持つサブキーは作業データストアから除去され、肯定的存在を持つサブキー、すなわち、存在しているがプレースホルダとしてマークされておらず、かつ削除されたものとしてマークされていないサブキーは、作業データストアに追加され、作業データストアに既に存在しているものがある場合には、対応するサブキーと置換し（ステップ１０１８）、以下で説明するようにステップ１０３０に続く。
【０１９９】
次いで、３種類すべてのルールについて、ステップ１０３０が実行される。ルールエンジンは、そのフィルタが要求されたキーの直接の子には一致するが要求されたキー自体には一致しないルールのセットを見つけるためにクエリされる（ステップ１０３０）。セット内の各ルールについて、その名前がルール内の名前に一致する仮想子の存在が、判定される。いくつかの実施形態において、これは、適切な分離スコープおよび仮想子に関連するメタデータを調査することによって判定される。その他の実施形態において、これは、キーを開くよう試みることによって判定される。オープン要求が成功した場合、仮想子は肯定的存在を有する。オープン要求が失敗し、仮想子は存在しないことを示す場合、仮想子は否定的存在を有する。
【０２００】
子が肯定的存在を有する場合、作業データストアに追加され、既にそこにある同じ名前の任意の子と置換する。子が否定的存在を有する場合、仮想子に対応する作業データストア内の子は、もしあれば、除去される（ステップ１０３２）。そして最後に、構築された列挙は、作業データストアから要求元に返される（ステップ１０２０）。
【０２０１】
当業者であれば、上述のレイヤ化された列挙プロセスは、微修正して、複数の分離サブスコープを備える単一の分離スコープを列挙する動作に適用できることを認識するであろう。作業データストアが作成され、連続的なサブスコープが列挙され、分離スコープの集約列挙を形成するために、結果が作業データストアにマージされる。
【０２０２】
４．２．４．  レジストリ作成動作
図１１および概要を参照すると、分離環境においてキーを作成するために取られるステップの一実施形態が示されている。キーを作成するための要求が受信または傍受される（ステップ１１０２）。要求は、分離環境によって仮想キー名として扱われるキー名を含有する。第４．２．１節で記載したように、適用可能なルールを使用した、すなわち、適切なユーザおよびアプリケーション分離スコープを使用した完全仮想化を使用して、要求されたキーを開く試みが行われる（ステップ１１０４）。アクセスが拒否された場合（ステップ１１０６）、アクセス拒否エラーが要求元に返される（ステップ１１０９）。アクセスが許可され（ステップ１１０６）、要求されたキーがうまく開かれた場合（ステップ１１１０）、要求されたキーが要求元に返される（ステップ１１１２）。しかしながら、アクセスが許可されたが（ステップ１１０６）、要求されたキーがうまく開かれず（ステップ１１１０）、要求されたキーの親も存在しない場合（ステップ１１１４）、要求動作に適したエラーが要求元に対して発行される（ステップ１１１６）。一方、適切なユーザおよびアプリケーションスコープを使用して、完全に仮想化されたビューにおいて要求されたキーの親が見つかった場合（ステップ１１１４）、ルールはキー動作をどのように処理するかを判定する（ステップ１１１８）。ルールアクションが「リダイレクトする」または「無視する」である場合（ステップ１１２０）、仮想キー名はルールに従って文字キー名に直接的にマップされる。具体的には、ルールアクションが「無視する」である場合、文字キー名は厳密には仮想キー名として識別される。そうではなく、ルールアクションが「リダイレクトする」である場合、文字キー名はルールによって特定されるように仮想キー名から判定される。次いで文字キーを作成するための要求がオペレーティングシステムに渡され、結果が要求元に返される（ステップ１１２４）。一方、ステップ１１２０において判定されたルールアクションが「分離する」である場合、文字キー名はユーザ分離スコープにおける仮想キー名のインスタンスとして識別される。文字キーが既に存在するが、プレースホルダであること、または削除されたことを示すメタデータと関連付けられている場合、それらの表示を除去するよう関連のメタデータを修正し、キーが空であることが確認される。いずれの場合も、文字キーを開くための要求がオペレーティングシステムに渡される（ステップ１１２６）。文字キーがうまく開かれた場合（ステップ１１２８）、当該文字キーが要求元に返される（ステップ１１３０）。一方、ステップ１１２８において、要求されたキーが開けない場合、現在ユーザ分離スコープに存在しない文字キーの各祖先についてプレースホルダが（ステップ１１３２）、文字名を使用して文字キーを作成するための要求がオペレーティングシステムに渡され、結果が要求元に返される（ステップ１１３４）。
【０２０３】
図１１をさらに詳細に参照すると、キーを作成するための要求が受信または傍受される（ステップ１１０２）。いくつかの実施形態において、要求は、キーを作成するためのオペレーティングシステム機能を置換する機能によってフックされる。別の実施形態において、要求を傍受するためにフッキング動的リンクライブラリが使用される。フッキング機能は、ユーザモードまたはカーネルモードで実行することができる。フッキング機能がユーザモードで実行する実施形態では、フッキング機能は、プロセスが作成される際に当該プロセスのアドレス空間にロードされてよい。フッキング機能がカーネルモードで実行する実施形態では、フッキング機能は、キー動作の要求をディスパッチするのに使用されるオペレーティングシステムリソースと関連付けられてよい。キー動作の種類ごとに別個のオペレーティングシステム機能が提供される実施形態では、各機能は別個にフックされてよい。あるいは、数種類のキー動作の作成コールまたはオープンコールを傍受する単一のフッキング機能を提供してよい。
【０２０４】
要求は、分離環境によって仮想キー名として扱われるキー名を含有する。いくつかの実施形態において、仮想キー名は、親キーのハンドルと、子孫キーの相対パス名との組み合わせとして表現される場合がある。親キーハンドルは、それ自体が仮想キー名と関連付けられた文字キー名と関連付けられている。要求元は、第４．２．１節で記載したように、適用可能なルールを使用した、すなわち、適切なユーザおよびアプリケーション分離スコープを使用した完全仮想化を使用して、仮想キーを開くよう試みる（ステップ１１０４）。完全に仮想化されたオープン動作中にアクセスが拒否された場合（ステップ１１０６）、アクセス拒否エラーが要求元に返される（ステップ１１０９）。アクセスが許可され（ステップ１１０６）、要求された仮想キーがうまく開かれた場合（ステップ１１１０）、対応する文字キーが要求元に返される（ステップ１１１２）。しかしながら、アクセスが許可されたが（ステップ１１０６）、仮想キーがうまく開かれない場合（ステップ１１１０）、仮想キーは存在しないと判定されたということである。第４．２．１節の手順によって判定された際に、要求された仮想キーの仮想親も存在しない場合（ステップ１１１４）、要求動作に適したエラーが要求元に対して発行される（ステップ１１１６）。一方、適切なユーザおよびアプリケーションスコープを使用して、完全に仮想化されたビューにおいて要求された仮想キーの仮想親が見つかった場合（ステップ１１１４）、ルールエンジンを調べることにより、作成動作をどのように処理するかを判定するルールが位置付けられる（ステップ１１１８）。いくつかの実施形態において、ルールエンジンは、リレーショナルデータベースとして提供される場合がある。その他の実施形態において、ルールエンジンは、木構造データベース、ハッシュテーブル、またはフラットキーデータベースであってよい。いくつかの実施形態において、要求されたキーに提供された仮想キー名は、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。これらの実施形態のうち特定のものにおいて、特定のキーのルールエンジンに多くのルールが存在する場合があり、これらの実施形態のいくつかにおいて、仮想キー名と一致する最も長い接頭辞を有するルールは、要求に適用されるルールである。いくつかの実施形態において、プロセス識別子は、存在する場合、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。要求に関連するルールは、要求を無視すること、要求をリダイレクトすること、または要求を分離することであってよい。図１１では単一のデータベーストランザクションまたは単一のキー検索として示されているが、ルール検索は一連のルール検索として行われてもよい。
【０２０５】
ルールアクションが「リダイレクトする」または「無視する」である場合（ステップ１１２０）、仮想キー名はルールに従って文字キー名に直接的にマップされる（ステップ１１２４）。ルールアクションが「リダイレクトする」である場合（ステップ１１２０）、文字キー名はルールによって特定されるように仮想キー名から判定される（ステップ１１２４）。ルールアクションが「無視する」である場合（ステップ１１２０）、文字キー名は厳密には仮想キー名であると判定される（ステップ１１２４）。ルールアクションが「無視する」である、またはルールアクションが「リダイレクトする」である場合、判定された文字キー名を使用して文字キーを作成するための要求がオペレーティングシステムに渡され、オペレーティングシステムから結果が要求元に返される（ステップ１１２４）。例えば、「ｋｅｙ＿１」と名付けられた仮想キーを作成するための要求により、「Ｄｉｆｆｅｒｅｎｔ＿ｋｅｙ＿１」と名付けられた文字キーを作成することができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される（ステップ１１２４）。その他の実施形態において、ファイルシステムフィルタドライバ設備と概念的に同様のレジストリフィルタドライバ設備が、オペレーティングシステムによって提供される場合がある。これらの実施形態において、文字レジストリキーを作成することは、判定された文字キー名を使用して要求を再構文解析するようレジストリフィルタマネージャに信号を送り、仮想キーを作成するための元の要求に応答することによって達成できる。
【０２０６】
ステップ１１２０において判定されたルールアクションが「無視する」または「リダイレクトする」ではなく「分離する」である場合、文字キー名はユーザ分離スコープにおける仮想キー名のインスタンスとして識別される。仮想キーが既に存在するが、プレースホルダであること、または削除されたことを示すメタデータと関連付けられている場合、それらの表示を除去するよう関連のメタデータを修正し、キーが空であることが確認される。
【０２０７】
いくつかの実施形態において、レジストリキーについてのメタデータは、当該キーが保持する識別値に保存されてよく、当該値の存在は、通常のアプリケーションで使用のレジストリＡＰＩから隠される。いくつかの実施形態において、レジストリキーについての少量のメタデータが、仮想名にメタデータ識別子で接尾辞を付ける等によって文字キー名に直接的に保存されてよく、ここでメタデータ識別子は特定のメタデータ状態に一意に関連する文字列である。メタデータ識別子は、１または数ビットのメタデータを示す、または符号化することができる。メタデータ識別子の存在による文字キー名の考えられる変形に関する仮想名チェックによってキーにアクセスするための要求、およびキー名自体を検索するための要求は、文字名で応答するためにフックまたは傍受される。その他の実施形態において、メタデータ識別子は、キー名自体の代わりにサブキー名またはレジストリ値名において符号化されてよい。また他の実施形態において、レジストリキーシステムは、各キーに、いくつかの第三者メタデータを保存する能力を直接的に提供することができる。いくつかの実施形態において、メタデータは、データベース、またはレジストリデータベースから離れたその他のリポジトリに保存され得る。いくつかの実施形態において、別個のサブスコープは、削除されたものとしてマークされているキーを保存するために使用されてよい。サブスコープ内のキーの存在は、当該キーが削除されたものとしてマークされていることを示す。
【０２０８】
これらの実施形態のうち特異のものにおいて、削除されたキーまたはキーシステム要素のリストは、この削除されたキーに関するチェックを最適化するために維持され調べられてよい。これらの実施形態において、削除されたキーが再作成されると、キー名は削除されたキーのリストから除去されてよい。これらの実施形態のうちのその他において、リストが一定サイズを超えた場合、キー名はリストから除去されてよい。
【０２０９】
いずれの場合も、ユーザスコープ付き文字キーを開くための要求がオペレーティングシステムに渡される（ステップ１１２６）。いくつかの実施形態において、ルールは、アプリケーション分離スコープ、システムスコープ、ユーザ分離サブスコープ、またはアプリケーション分離サブスコープ等、ユーザ分離スコープ以外のスコープにおいて、仮想キーに対応する文字キーが作成されるべきであると特定することができる。
【０２１０】
文字キーがうまく開かれた場合（ステップ１１２８）、当該文字キーが要求元に返される（ステップ１１３０）。一方、ステップ１１２８において、要求されたキーが開けない場合、現在ユーザ分離スコープに存在しない文字キーの各祖先についてプレースホルダが作成され（ステップ１１３２）、文字名を使用して文字キーを作成するための要求がオペレーティングシステムに渡され、結果が要求元に返される（ステップ１１３４）。
【０２１１】
この実施形態は、コール／呼び出しごとに１レベルの作成のみをサポートするＡＰＩまたは設備を持つオペレーティングシステムを表すものである。コール／呼び出しごとにマルチレベルへ拡大解釈できることは、当業者には明白なはずである。
【０２１２】
（４．３  名前付きオブジェクト仮想化動作）
上述の技術を使用して仮想化することが可能な別のクラスのシステムスコープ付きリソースは、セマフォ、ミューテックス、ミュータント、待機可能タイマ、イベント、ジョブオブジェクト、セクション、名前付きパイプ、およびメールスロットを含む、名前付きオブジェクトである。これらのオブジェクトは、一般にそれらを作成するプロセスの持続時間にのみ存在することを特徴とする。これらのオブジェクトの名前空間は、コンピュータ全体にわたって（スコープ内でグローバル）、または、個人ユーザセッションにおいてのみ（セッションスコープ付き）、有効であってよい。
【０２１３】
図１２および概要を参照すると、名前付きオブジェクトを作成する、または開くための要求が受信または傍受される（ステップ１２０２）。当該要求は、分離環境によって仮想名として扱われるオブジェクト名を含有する。要求をどのように扱うかを判定するルールが判定される（ステップ１２０４）。要求を無視すべきであることをルールが示す場合（ステップ１２０６）、文字オブジェクト名は仮想名であると判定され（ステップ１２０７）、文字オブジェクトを作成する、または開くための要求がオペレーティングシステムに対して発行される（ステップ１２１４）。判定されたルールが要求を無視することでなく、要求をリダイレクトすべきであることを示す場合（ステップ１２０８）、文字オブジェクト名は、リダイレクトルールによって特定されるように仮想名から判定され（ステップ１２１０）、文字オブジェクトの作成またはオープン要求がオペレーティングシステムに対して発行される（ステップ１２１４）。要求をリダイレクトすべきであることをルールが示さず（ステップ１２０８）、代わりに要求を分離すべきであることを示す場合、文字オブジェクト名は、分離ルールによって特定されるように仮想名から判定され（ステップ１２１２）、文字オブジェクトの作成またはオープンコマンドがオペレーティングシステムに対して発行される（ステップ１２１４）。発行された作成またはオープンコマンドを受けてオペレーティングシステムによって返される文字オブジェクトのハンドルが、仮想オブジェクトの作成またはオープンを要求するプログラムに返される（ステップ１２１６）。
【０２１４】
図１２をさらに詳細に参照すると、名前付きオブジェクトを作成する、または開くためのプロセスからの要求が傍受される（ステップ１２０２）。名前付きオブジェクトは、セッションスコープのものであってもよいし、グローバルスコープのものであってもよい。いくつかの実施形態において、要求は、名前付きオブジェクトを作成する、または開くためのオペレーティングシステム機能を置換する機能によってフックされる。別の実施形態において、要求を傍受するためにフッキング動的リンクライブラリが使用される。フッキング機能は、ユーザモードまたはカーネルモードで実行することができる。フッキング機能がユーザモードで実行する実施形態では、フッキング機能は、プロセスが作成される際に当該プロセスのアドレス空間にロードされてよい。フッキング機能がカーネルモードで実行する実施形態では、フッキング機能は、システムオブジェクトの要求をディスパッチするのに使用されるオペレーティングシステムリソースと関連付けられてよい。名前付きオブジェクトを作成する、または開くための要求は、プロセス間通信および同期に使用され、セマフォ、ミューテックス、ミュータント、待機可能タイマ、ファイルマッピングオブジェクト、イベント、ジョブオブジェクト、セクション、名前付きパイプ、およびメールスロットを含む一意識別子によって識別される、多種多様なシステムスコープ付きリソースのいずれか１つに言及する場合がある。オブジェクトの種類ごとに別個のオペレーティングシステム機能が提供される実施形態では、各機能は別個にフックされてよい。あるいは、数種類のオブジェクトの作成コールまたはオープンコールを傍受する単一のフッキング機能を提供してよい。
【０２１５】
傍受された要求は、分離環境によって仮想名として扱われるオブジェクト名を含有する。ルールエンジンを調べることによって、オブジェクトの要求をどのように扱うかを判定するルールが判定される（ステップ１２０４）。いくつかの実施形態において、ルールエンジンは、リレーショナルデータベースとして提供される場合がある。その他の実施形態において、ルールエンジンは、木構造データベース、ハッシュテーブル、またはフラットファイルデータベースであってよい。いくつかの実施形態において、要求されたオブジェクトに提供された仮想名は、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。これらの実施形態のうち特定のものにおいて、特定のオブジェクトのルールエンジンに多くのルールが存在する場合があり、これらの実施形態において、仮想名と一致する最も長い接頭辞を有するルールは、要求に適用されるルールである。いくつかの実施形態において、プロセス識別子は、存在する場合、要求に当てはまるルールをルールエンジン内において位置付けるために使用される。要求に関連するルールは、要求を無視すること、要求をリダイレクトすること、または要求を分離することであってよい。図１２では一連の決定として示されているが、ルール検索は単一のデータベーストランザクションとして発生する場合がある。
【０２１６】
要求を無視すべきであることをルールが示す場合（ステップ１２０６）、文字オブジェクト名は仮想名であると判定され、文字オブジェクトを作成する、または開くための要求がオペレーティングシステムに対して発行される（ステップ１２１４）。例えば、「Ｏｂｊｅｃｔ＿１」と名付けられた名前付きオブジェクトを作成する、または開くための要求により、「Ｏｂｊｅｃｔ＿１」と名付けられた実際のオブジェクトを作成することになる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。
【０２１７】
ルールエンジンにアクセスすることによって判定されたルールが要求を無視することでなく、代わりに要求をリダイレクトすべきであることを示す場合（ステップ１２０８）、文字オブジェクト名はリダイレクトルールによって特定されるように仮想名から判定され（ステップ１２１０）、文字オブジェクトの作成またはオープン要求がオペレーティングシステムに対して発行される（ステップ１２１４）。例えば、「Ｏｂｊｅｃｔ＿１」と名付けられた名前付きオブジェクトを作成する、または開くための要求により、「Ｄｉｆｆｅｒｅｎｔ＿Ｏｂｊｅｃｔ＿１」と名付けられた実際のオブジェクトを作成することができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。
【０２１８】
ルールが要求をリダイレクトすべきであることを示さず（ステップ１２０８）、代わりに要求を分離すべきであることを示す場合、文字オブジェクト名は、分離ルールによって特定されるように仮想名から判定され（ステップ１２１２）、文字オブジェクトの作成またはオープンコマンドがオペレーティングシステムに対して発行される（ステップ１２１４）。例えば、「Ｏｂｊｅｃｔ＿１」と名付けられた名前付きオブジェクトを作成する、または開くための要求により、「Ｉｓｏｌａｔｅｄ＿Ｏｂｊｅｃｔ＿１」と名付けられた実際のオブジェクトを作成することができる。一実施形態において、これは、フックされた機能のオリジナルバージョンをコールし、形成された文字名を引数としてその機能に渡すことによって実現される。
【０２１９】
要求されたシステムオブジェクトを分離するために形成された文字名は、受信した仮想名およびスコープ固有の識別子に基づくものであってよい。スコープ固有の識別子は、アプリケーション分離スコープ、ユーザ分離スコープ、セッション分離スコープ、またはその３つのいくつかの組み合わせに関連する識別子であってよい。スコープ固有の識別子は、要求中に受信した仮想名を「マングルする」ために使用される。例えば、名前付きオブジェクト「Ｏｂｊｅｃｔ＿１」の要求が、その関連する識別子が「ＳＡ１」であるアプリケーション分離スコープに分離された場合、文字名は「Ｉｓｏｌａｔｅｄ＿ＡｐｐＳｃｏｐｅ＿ＳＡ１＿Ｏｂｊｅｃｔ＿１」であってよい。以下の表は、セッション分離スコープ、またはユーザ分離スコープ、およびアプリケーション分離スコープを持つオブジェクトの名前をマングルすることの効果を識別するものである。スコープを組み合わせてマングルする場合は、表に記載された制限事項を組み合わせる。
【０２２０】
【表１】
2008521071.tif 000003
オペレーティングシステムがＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムファミリーの１つである実施形態では、オブジェクトに関連するグローバル／ローカル名接頭辞を切り替えることによりオブジェクトスコープを修正することができ、これは、分離されたアプリケーションについて、セッション固有の識別子を持つオブジェクト名をマングルすることと同じ効果を有するものである。しかしながら、グローバル／ローカル名接頭辞を切り替えることにより、分離されていないアプリケーションのオブジェクトスコープにも影響を及ぼす。
【０２２１】
ステップ１２１４において発行された、名前付きオブジェクトを作成する、または開くためのコマンドを受けてオペレーティングシステムによって返される文字オブジェクトのハンドルが、仮想オブジェクトの作成またはオープンを要求するプログラムに返される（ステップ１２１６）。
【０２２２】
（４．４  ウィンドウ名仮想化）
上述の技術を使用して仮想化することが可能なその他のクラスのシステムスコープ付きリソースは、ウィンドウ名およびウィンドウクラス名である。グラフィックソフトウェアアプリケーションは、アプリケーションプログラムが既に作動しているか否かを識別する手法として、およびその他の形態の同期化のために、ウィンドウまたはそのウィンドウクラスの名前を使用する。図１３および概要を参照すると、ウィンドウ名またはウィンドウクラスについての要求が受信または傍受される（ステップ１３０２）。要求は、Ｗｉｎ３２  ＡＰＩコールの形態、またはウィンドウメッセージの形態であってよい。両方の種類の要求がハンドルされる。それらの要求は、分離環境によって仮想名として扱われるウィンドウ名および／またはウィンドウクラス名を含有する、またはそれらの検索を要求する。要求が、ハンドルによって識別されたウィンドウのウィンドウ名またはウィンドウクラスを検索することである場合（ステップ１３０４）、ハンドルとウィンドウに関する要求された情報とが分かっているか否かを判定するためにウィンドウマッピングテーブルが調べられる（ステップ１３０６）。分かっている場合、ウィンドウマッピングテーブルから要求された情報が要求元に返される（ステップ１３０８）。分かっていない場合、要求はオペレーティングシステムに渡され（ステップ１３１０）、結果が要求元に返される（ステップ１３１４）。ステップ１３０４において、要求がウィンドウ名またはウィンドウクラスを提供する場合、オペレーティングシステムによって定義されたウィンドウのクラスの１つを特定するか否かを判定するために、要求がチェックされる（ステップ１３２０）。特定する場合、オペレーティングシステムに対して要求が発行され、オペレーティングシステムから返された結果が要求元に返される（ステップ１３２２）。要求がオペレーティングシステムによって定義されたウィンドウのクラスの１つを特定しない場合、仮想クラス名およびルールに基づいて文字クラス名が判定され（ステップ１３２４）、仮想ウィンドウ名およびルールに基づいて文字ウィンドウ名が判定される（ステップ１３２６）。要求は次いで文字ウィンドウおよび文字クラス名を使用してオペレーティングシステムに渡される（ステップ１３２８）。ステップ１３２４および１３２６で判定された文字ウィンドウ名または文字ウィンドウクラス名のいずれかが、対応する仮想名と異なる場合、ウィンドウハンドルへのウィンドウマッピングテーブルエントリは、要求中に提供された仮想ウィンドウ名または仮想クラス名を記録するために更新される（ステップ１３３０）。オペレーティングシステムからの応答がネイティブウィンドウ名またはクラスのネイティブ識別を含む場合、それらは要求中に提供された仮想ウィンドウ名または仮想クラス名で置換され（ステップ１３１２）、結果が要求元に返される（ステップ１３１４）。
【０２２３】
図１３をさらに詳細に参照すると、ウィンドウ名またはウィンドウラスについての要求が受信または傍受される（ステップ１３０２）。それらの要求は、分離環境によって仮想名として扱われるウィンドウ名および／またはウィンドウクラス名を含有する、またはそれらの検索を要求する。
【０２２４】
要求が、ハンドルによって識別されたウィンドウのウィンドウ名またはウィンドウクラスを検索することである場合（ステップ１３０４）、ハンドルとウィンドウに関する要求された情報とが分かっているか否かを判定するためにウィンドウマッピングテーブルが調べられる（ステップ１３０６）。いくつかの実施形態において、オペレーティングシステムによって提供された設備を使用して、マッピングテーブルの代わりに、ウィンドウおよびウィンドウクラスごとに追加データが保存される。
【０２２５】
分かっている場合、要求された情報がウィンドウマッピングテーブルから要求元に返される（ステップ１３０８）。分かっていない場合、要求はオペレーティングシステムに渡され（ステップ１３１０）、結果が要求元に返される（ステップ１３１４）。
【０２２６】
ステップ１３０４において、要求がウィンドウ名またはウィンドウクラスを提供する場合、オペレーティングシステムによって定義されたウィンドウのクラスの１つを特定するか否かを判定するために、要求がチェックされる（ステップ１３２０）。特定する場合、要求はオペレーティングシステムに渡され、オペレーティングシステムから返された結果が要求元に返される（ステップ１３２２）。
【０２２７】
要求がオペレーティングシステムによって定義されたウィンドウのクラスの１つを特定しない場合、仮想クラス名およびルールに基づいて文字クラス名が判定され（ステップ１３２４）、仮想ウィンドウ名およびルールに基づいて文字ウィンドウ名が判定される（ステップ１３２６）。要求は次いで文字ウィンドウおよび文字クラス名を使用してオペレーティングシステムに渡される（ステップ１３２８）。いくつかの実施形態において、ウィンドウ名およびウィンドウクラス名は、単純文字列リテラルではなくアトムであってよい。一般に、アプリケーションはアトムテーブルに文字列を置き、文字列にアクセスするために使用できる、アトムと呼ばれる１６ビット整数を受信する。
【０２２８】
ステップ１３２４および１３２６で判定された文字ウィンドウ名または文字ウィンドウクラス名のいずれかが、対応する仮想名と異なる場合、ウィンドウハンドルへのウィンドウマッピングテーブルエントリは、要求中に提供された仮想ウィンドウ名または仮想クラス名を記録するために更新される（ステップ１３３０）。
【０２２９】
オペレーティングシステムからの応答がネイティブウィンドウ名またはクラスのネイティブ識別を含む場合、それらは要求中に提供された仮想ウィンドウ名または仮想クラス名で置換され（ステップ１３１２）、結果が要求元に返される（ステップ１３１４）。
【０２３０】
図１３Ａを参照すると、そこに示されているように、文字ウィンドウ名またはウィンドウクラス名が判定される。要求に当てはまるルールを判定するために、ルールエンジンが調べられる（ステップ１３５２）。ルールアクションが「無視する」である場合（ステップ１３５４）、文字名は仮想名と等しい（ステップ１３５６）。しかしながら、ルールアクションが「無視する」ではなく「リダイレクトする」である場合（ステップ１３５８）、文字名はリダイレクトルールによって特定されるように仮想名から判定される（ステップ１３６０）。しかしながら、ルールアクションが「リダイレクトする」ではなく「分離する」である場合、文字名はスコープ固有の識別子を使用して仮想名から判定される（ステップ１３６２）。
【０２３１】
いくつかの実施形態において、特定のスコープ固有の識別子がルール内で特定される。その他の実施形態において、使用されるスコープ固有の識別子は、要求中のプロセスが関連付けられているアプリケーション分離スコープと関連付けられたものである。これにより、ウィンドウまたはウィンドウクラスを、同じアプリケーション分離スコープに関連付けられたその他任意のアプリケーションによって使用することが可能になる。ウィンドウ名およびクラスがセッション内で既に分離されている、Ｍｉｃｒｏｓｏｆｔ  ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムファミリーの多くのようなオペレーティングシステムにおいて、これは、同じアプリケーション分離スコープと関連付けられた同じセッション内で実行するアプリケーションのみがウィンドウ名またはクラスを使用できることを意味する。
【０２３２】
Ｍｉｃｒｏｓｏｆｔ  ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムファミリーのいくつかにおいて、ウィンドウ名は、タイトルバー内のウィンドウのタイトルとして使用される。非クライアントエリアペイントウィンドウメッセージをハンドルし、ウィンドウタイトルバーに表示されたウィンドウタイトルが特定のウィンドウの文字名ではなく仮想名を反映していることを確認することが望ましい。非クライアントエリアペイントメッセージが傍受されると、もしあれば、ウィンドウに関連する仮想名がマッピングテーブルから検索される。仮想名が検索された場合、非クライアントエリアは仮想名を使用してウィンドウタイトルとしてペイントされ、要求メッセージがハンドルされたことが示される。仮想名が検索されない場合、要求はハンドルされなかったものとして示され、これにより要求は、ウィンドウの文字名を使用してタイトルバーをペイントする元の機能に渡される。
【０２３３】
（４．５  プロセス外ＣＯＭサーバ仮想化）
ＣＯＭ、ＣＯＲＢＡ、．ＮＥＴおよびその他のソフトウェアコンポーネント技術により、ソフトウェアコンポーネントを開発、配置、登録、発見、起動またはインスタンス作成し、個々のユニットとして利用することが可能になる。いくつかのコンポーネントはこれらの場合のサブセットをサポートするのみであるが、ほとんどのコンポーネントモデルにおいて、コンポーネントは、同じコンピュータまたは全く別個のコンピュータで、コール元のプロセスまたは別個のプロセスのいずれかにおいて実行することができる。
【０２３４】
１つ以上の一意識別子がこれらのコンポーネントを識別する。一般に、コンポーネント基盤は、ブローカ起動が要求するサービスまたはデーモンを提供する。コンポーネントの使用を開始することを望むソフトウェアプロセスは、コンポーネント識別子によって特定されたコンポーネントを起動するための要求をブローカに渡す。ブローカは要求されたコンポーネントを起動し、可能であれば、起動されたインスタンスへの参照を返す。これらのコンポーネント基盤のいくつかにおいて、コンポーネント識別子はバージョンが異なっても同じままであるため、同じコンポーネントの多くのバージョンは共存することができない。
【０２３５】
ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムファミリーのメンバーのいくつかは、ＣＯＭと呼ばれるコンポーネント基盤を提供する。ＣＯＭコンポーネント（「ＣＯＭサーバ」）はクラス識別子（ＣＬＳＩＤ）と呼ばれるＧＵＩＤによって識別され、各コンポーネントは、それぞれが独自の唯一のインターフェース識別子（ＵＩＩＤ）を有する１つ以上のインターフェースを提供する。ＣＯＭサービスコントロールマネージャ（ＣＳＣＭ）はプロセス外起動要求のためのブローカであり、ＣＬＳＩＤを介してコール元がＣＯＭサーバの起動を要求することを可能にするインターフェースを提供する。以下の説明ではＣＯＭサーバおよびＣＯＭクライアントという用語で言い表されるが、当業者であれば、ＣＯＲＢＡ、．ＮＥＴ、およびソフトウェアコンポーネントの動的起動を提供するその他のソフトウェアアーキテクチャに当てはまることを理解するであろう。
【０２３６】
ＣＯＭコンポーネントは、コンピュータにインストールされる際、ＣＳＣＭがＣＯＭサーバの新規インスタンスを起動するのに必要な情報とともに、そのＣＬＳＩＤをレジストリデータベースの既知の部分に登録する。プロセス外ＣＯＭサーバについて、これは、作動する実行可能ファイルへのパスおよびコマンドラインパラメータを含んでよい。同じＣＯＭサーバの多くのバージョンが同じＣＬＳＩＤを共有しており、そのため、一度にコンピュータにインストールできるのは１つのバージョンのみである。
【０２３７】
ある実施形態において、（ＣＯＭクライアントとして作用する）アプリケーションは、ＣＯＭ  ＡＰＩ（例えば、ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）またはＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅＥｘ（））をコールすることによってＣＯＭサーバのインスタンス作成をする。このコールへのパラメータは、プロセス中、同じコンピュータのプロセス外、リモートコンピュータのプロセス外の望ましい起動コンテキストを特定する、または、ＣＯＭサブシステムがこれら３つの場合からどれを使用するか判定することを可能にする。プロセス外起動が必要であると判定された場合、ＣＬＳＩＤを含む要求がＣＳＣＭに渡される。ＣＳＣＭは、レジストリデータベースを使用して、ＣＯＭサーバをホストする実行可能ファイルを起動するために必要なパスおよびパラメータを位置付ける。当該実行可能ファイルは、起動されると、ＣＯＭ  ＡＰＩ  ＣｏＲｅｇｉｓｔｅｒＣｌａｓｓＯｂｊｅｃｔ（）を使用してＣＳＣＭでサポートするすべてのＣＯＭサーバのすべてのＣＬＳＩＤを登録する。要求されたＣＬＳＩＤが登録されると、ＣＳＣＭは当該ＣＯＭサーバへの参照をコール元に返す。ＣＯＭクライアントとＣＯＭサーバとの間の後の対話はすべてＣＳＣＭと無関係に行われる。
【０２３８】
前述の分離環境２００は、同じＣＬＳＩＤを持つＣＯＭサーバの多くのインスタンスを、それぞれ異なる分離スコープ（システムスコープであり得るうちの１つのみ）にあるコンピュータにインストールすることを可能にする。しかしながら、これだけでそれらのＣＯＭサーバがＣＯＭクライアントに利用可能となるわけではない。
【０２３９】
図１４は、ＣＯＭサーバへのアクセスを仮想化するために取られるステップの一実施形態を描写している。概要において、分離スコープ内に起動されるプロセス外ＣＯＭサーバごとに、以後分離ＣＬＳＩＤ（ＩＣＬＳＩＤ）と呼ぶ新規ＣＬＳＩＤが作成される（ステップ１４０２）。定義によれば、これはＣＬＳＩＤであり、したがって他のＣＬＳＩＤすべての中で唯一でなくてはならない、換言すると、ＧＵＩＤの特性を有さなくてはならない。ペア（ＣＬＳＩＤ、アプリケーション分離スコープ）をＩＣＬＳＩＤにマップするマッピングテーブルが作成される。適切なアプリケーション分離スコープにおいて実行可能なＣＯＭサーバを開始する起動パラメータによって、ＣＯＭサーバをどのように起動するかを説明するＩＣＬＳＩＤのＣＯＭサーバレジストリエントリが作成される（ステップ１４０４）。ＣＯＭクライアントによる、ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）およびＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅＥｘ（）等のＣＯＭ  ＡＰＩへのコールがフックまたは傍受される（ステップ１４０６）。（ａ）プロセス内ＣＯＭサーバによって要求を満たすことができる、または（ｂ）ＣＯＭクライアントおよびＣＯＭサーバの両方が、いかなる分離スコープとも関連付けられていない、と判定された場合、要求は無修正で元のＣＯＭ  ＡＰＩに渡され、結果がコール元に返される（ステップ１４０８）。使用するＣＯＭサーバの適切なインスタンスが識別される（ステップ１４１０）。選択されたＣＯＭサーバインスタンスがアプリケーション分離環境にある場合、上記で概説したデータ構造を使用して、そのＩＣＬＳＩＤが判定される。そうでない場合、要求中のＣＬＳＩＤが使用される（ステップ１４１２）。ステップ１４１２において識別されていれば、ＩＣＬＳＩＤによって元のＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）またはＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅＥｘ（）機能がコールされる。これが要求をＣＳＣＭに渡す（ステップ１４１４）。ＣＳＣＭは、起動パラメータを判定するために要求されたＣＬＳＩＤをレジストリ内で検索することにより、標準のやり方で実行可能なＣＯＭサーバを見つけ、起動する。ＩＣＬＳＩＤが要求されると、ステップ１４０４において説明したようなＩＣＬＳＩＤシステムスコープレジストリエントリが見つけられ、適切なアプリケーション分離スコープにおいてＣＯＭサーバが起動される（ステップ１４１６）。起動されたＣＯＭ実行可能ファイルは、それがサポートするＣＯＭサーバのＣＬＳＩＤによって、フックされたＣｏＲｅｇｉｓｔｅｒＣｌａｓｓＯｂｊｅｃｔ（）ＡＰＩをコールし、これらは元のＣｏＲｅｇｉｓｔｅｒＣｌａｓｓＯｂｊｅｃｔ（）ＡＰＩに渡される適切なＩＣＬＳＩＤに翻訳される（ステップ１４１８）。ＣＳＣＭは、予期されたＩＣＬＳＩＤを持つＣｏＲｅｇｉｓｔｅｒＣｌａｓｓＯｂｊｅｃｔ（）コールからの応答を受信すると、当該ＣＯＭサーバインスタンスへの参照をコール元に返す（ステップ１４２０）。
【０２４０】
図１４をさらに詳細に参照すると、分離スコープ内に起動されるプロセス外ＣＯＭサーバごとに、ＩＣＬＳＩＤが作成される（ステップ１４０２）。いくつかの実施形態において、ＩＣＬＳＩＤはＣＯＭサーバのインストール中に作成される。その他の実施形態において、ＩＣＬＳＩＤはインストール直後に作成される。また他の実施形態において、ＩＣＬＳＩＤは、ＣＯＭサーバが分離スコープ内に起動される前に作成される。これらの実施形態のすべてにおいて、ＩＣＬＳＩＤは、レジストリデータベースにおいてＣＬＳＩＤエントリを作成またはクエリするシステムコールをフックまたは傍受することによって作成されることができる。あるいは、ＩＣＬＳＩＤは、ＣＯＭサーバインスタンスを作成するＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）およびＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅＥｘ（）等のＣＯＭ  ＡＰＩコールをフックまたは傍受することによって作成されることができる。あるいは、レジストリデータベースのＣＬＳＩＤ固有の部分への変更は、インストールが行われた後に観測され得る。
【０２４１】
適切なアプリケーション分離スコープにおいて実行可能なＣＯＭサーバを開始する起動パラメータによって、ＣＯＭサーバをどのように起動するかを説明する当該ＩＣＬＳＩＤを持つＣＯＭサーバ用の適切なレジストリエントリとともに、ペア（ＣＬＳＩＤ、アプリケーション分離スコープ）をＩＣＬＳＩＤにマップするマッピングテーブルが作成される（ステップ１４０４）。多くの実施形態において、このテーブルは、ハードディスクドライブまたは固体メモリ素子等の永続的メモリ素子に保存される。その他の実施形態において、テーブルは、レジストリ、フラットファイル、データベース、または揮発性メモリ素子に保存されてよい。また他の実施形態において、テーブルは、例えばこの目的に固有の新規サブキーを、ＣＬＳＩＤによって識別された適切な各ＣＯＭサーバエントリに追加することによって、レジストリデータベースのＣＯＭ固有の部分全体に分配されてよい。このテーブル内のエントリは、レジストリデータベースにおいてＣＬＳＩＤを作成するコールをフックまたは傍受することによって、または、インストールが行われた後にレジストリデータベースのＣＬＳＩＤ固有の部分への変更を観測することによって、または、ＣＯＭサーバインスタンスを作成するＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）およびＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅＥｘ（）等のＣＯＭ  ＡＰＩコールをフックまたは傍受することによって、インストール中またはインストール直後に作成されることができる。特定の分離スコープへのＣＯＭサーバのインストールは、永続的に記録されることができる。あるいは、ＩＣＬＳＩＤへの特定のＣＯＭサーバおよび分離スコープのマッピングは、動的に作成され、非永続データベースまたはレジストリデータベースにエントリとして保存されることができる。
【０２４２】
ＣＯＭクライアントによる、ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）およびＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅＥｘ（）等のＣＯＭ  ＡＰＩへのコールがフックまたは傍受される（ステップ１４０６）。（ａ）プロセス内ＣＯＭサーバによって要求を満たすことができる、または（ｂ）ＣＯＭクライアントおよびＣＯＭサーバの両方が、システムスコープにあると判定された場合（ステップ１４０７）、要求は無修正で元のＣＯＭ  ＡＰＩに渡され、結果がコール元に返される（ステップ１４０８）。
【０２４３】
プロセス内ＣＯＭサーバによって要求を満たすことができず、ＣＯＭクライアントまたはＣＯＭサーバのいずれかがシステムスコープにない場合（ステップ１４０７）、使用するＣＯＭサーバの適切なインスタンスが識別される（ステップ１４１０）。ＣＯＭクライアントが特定の分離スコープにおいて実行する実施形態では、同じアプリケーション分離スコープにインストールされたＣＯＭサーバ、続いてシステムスコープにインストールされた（場合によってはクライアントのアプリケーション分離スコープにおいて実行する）ＣＯＭサーバ、次に、その他のアプリケーション分離スコープにインストールされたＣＯＭサーバにプリファレンスが与えられる。これらの実施形態のいくつかにおいて、システムスコープにインストールされたＣＯＭサーバは、ＣＯＭクライアントと同じアプリケーション分離スコープにおいて実行することができる。これは、ＣＯＭサーバがこのモードで正しく実行できるようにルールエンジンおよび管理設定によって制御され、ＣＯＭサーバが実行できなくなるのを防止することができる。ＣＯＭクライアントがシステムスコープにおいて実行する実施形態では、システムスコープＣＯＭサーバ、続いて分離スコープ内のＣＯＭサーバにプリファレンスが与えられ得る。ＣＯＭクライアントは、ＣＯＭサーバのインスタンスを作成するコールにおいて使用するＣＯＭサーバを特定することができる。あるいは、構成ストアは、インスタンス作成されるＣＯＭサーバを示す情報を保存することができる。いくつかの実施形態において、特定されたＣＯＭサーバは別のコンピュータによってホストされ、当該コンピュータは別個の物理マシンまたは仮想マシンであってよい。ステップ１４０４に関連して上述したマッピングテーブルは、適用可能なＣＯＭサーバのセットを見つけ、（必要に応じて）ルールに基づきプリファレンスを計算するために使用されてよい。
【０２４４】
適用可能なＣＯＭサーバが別のコンピュータに存在する実施形態では、リモートコンピュータにおいて実行するサービスまたはデーモンは、使用するＩＣＬＳＩＤをクエリされることができる。ＣＯＭクライアントフックは、リモートＣＯＭサーバが必要であると判定した場合、使用するＣＬＳＩＤ／ＩＣＬＳＩＤを判定するためにまずサービスまたはデーモンにクエリする。サービスまたはデーモンは、要求中に与えられたＣＬＳＩＤに対応するＩＣＬＳＩＤを判定する。いくつかの実施形態において、サービスまたはデーモンによって返されたＩＣＬＳＩＤは、管理者定義の構成データ、ルールエンジンに含有されたルール、またはビルトインのハードコードされた論理に基づいて選択または作成され得る。その他の実施形態において、要求は、使用するサーバにおける分離スコープを特定することができる。また他の実施形態において、要求されたＣＯＭサーバはサーバのシステムスコープと関連付けられてよく、この場合、ＣＯＭサーバと関連するＣＬＳＩＤが返される。また他の実施形態において、要求されたＣＯＭサーバはサーバの分離スコープの１つと関連付けられてよく、この場合、ＣＯＭサーバおよび分離スコープのインスタンスと関連するＩＣＬＳＩＤを返す。いくつかの実施形態において、上述のようなサービスまたはデーモンは、プロセス外ＣＯＭサーバをローカルに起動するのをサポートするために使用されてもよい。
【０２４５】
選択されたＣＯＭサーバインスタンスがローカルコンピュータのアプリケーション分離環境にある場合、ステップ１４０４に関連して説明したデータ構造を使用して、ＩＣＬＳＩＤが判定される。そうではなく、選択されたＣＯＭサーバインスタンスがローカルコンピュータのシステムスコープにある場合、要求中のＣＬＳＩＤが使用される（ステップ１４１２）。これらの実施形態のいくつかにおいて、ＩＣＬＳＩＤを使用してＣＯＭサーバへのエントリが動的に作成される場合がある。
【０２４６】
ＩＣＬＳＩＤが返されると、元のＣＬＳＩＤの代わりに元のＣＯＭ  ＡＰＩに渡される。例えば、判定されたＩＣＬＳＩＤは元のＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）またはＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅＥｘ（）機能に渡されてよく、これが要求をＣＳＣＭに渡す（ステップ１４１４）。ＣＯＭサーバが別のコンピュータによってホストされる実施形態では、ＣＳＣＭはＣＯＭサーバをホストしているコンピュータにＩＣＬＳＩＤを渡し、ここで当該コンピュータのＣＳＣＭはＣＯＭサーバ起動をハンドルする。
【０２４７】
ＣＳＣＭは、起動パラメータを判定するために要求されたＣＬＳＩＤまたはＩＣＬＳＩＤをレジストリ内で検索することにより、標準のやり方で実行可能なＣＯＭサーバを見つけ、起動する。ＩＣＬＳＩＤが要求されると、ステップ１４０４において説明したようなＩＣＬＳＩＤシステムスコープレジストリエントリが見つけられ、適切なアプリケーション分離スコープにおいてＣＯＭサーバが起動される（ステップ１４１６）。
【０２４８】
起動されたＣＯＭサーバインスタンスがアプリケーション分離スコープにおいて実行する場合（当該スコープにインストールされるかシステムスコープにインストールされるかにかかわらず）、ＣＯＭサーバインスタンスのＣＯＭ  ＡＰＩ機能ＣｏＲｅｇｉｓｔｅｒＣｌａｓｓＯｂｊｅｃｔ（）がフックまたは傍受される。ＣｏＲｅｇｉｓｔｅｒＣｌａｓｓＯｂｊｅｃｔ（）に渡された各ＣＬＳＩＤは、ステップ１４０４で定義したようなマッピングテーブルを使用して、対応するＩＣＬＳＩＤにマップされる。元のＣｏＲｅｇｉｓｔｅｒＣｌａｓｓＯｂｊｅｃｔ（）ＡＰＩはＩＣＬＳＩＤでコールされる（ステップ１４１８）。
【０２４９】
ＣＳＣＭは、予期されたＩＣＬＳＩＤを持つＣｏＲｅｇｉｓｔｅｒＣｌａｓｓＯｂｊｅｃｔ（）コールからの応答を受信すると、当該ＣＯＭサーバインスタンスへの参照をコール元に返す（ステップ１４２０）。
【０２５０】
この技術は、ＣＯＭクライアントおよびＣＯＭサーバが、（異なるスコープを含む）アプリケーション分離スコープとシステムスコープとの任意の組み合わせにおいて実行する場合、ＣＯＭサーバ実行をサポートする。ＩＣＬＳＩＤは、（ＣＬＳＩＤによって識別された）サーバと望ましい適切な分離スコープとの組み合わせに固有である。クライアントは、正しいＩＣＬＳＩＤ（または、サーバがシステムスコープにインストールされ、そこで実行している場合には元のＣＬＳＩＤ）を判定すればよい。
【０２５１】
（４．６  仮想化されたファイルタイプ関連付け（Ｆｉｌｅ−Ｔｙｐｅ  Ａｓｓｏｃｉａｔｉｏｎ；ＦＴＡ））
ファイルタイプ関連付けは、アプリケーションプログラムの実行を呼び出すための、既知のグラフィカルユーザインターフェース技術である。ユーザには、データファイルを表すグラフィックアイコンが提示される。ユーザは、自身がファイルを開きたいことを示すために、キーボードコマンドを使用して、またはマウス等のポインティングデバイスを使用してデータファイルを選択し、アイコン上でクリックまたはダブルクリックする。あるいは、いくつかのコンピューティング環境において、ユーザはコマンドの代わりにコマンドラインプロンプトでファイルへのパスを入力する。ファイルは一般に、ファイルを開く際に使用するアプリケーションプログラムを判定するために使用される、関連付けられたファイルタイプ表示を有する。これは、通常、ファイルタイプ表示を特定のアプリケーションにマップするテーブルを使用してなされる。Ｍｉｃｒｏｓｏｆｔ  ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムファミリーの多くのメンバーにおいて、マッピングは一般に、実行されるアプリケーションを示すファイルタイプインジケータおよびフルパス名を含むタプル内のレジストリデータベースに保存され、任意の特定のファイルタイプに関連付けることができるのは、１つのアプリケーションプログラムのみである。
【０２５２】
上述の分離環境において、アプリケーションの多くのバージョンが単一のコンピュータにインストールされ、そこで実行される場合がある。したがって、これらの環境において、ファイルタイプと、関連付けられたアプリケーションプログラムとの間の関係は、もはや一対一の関係ではなく、一対多の関係である。ＭＩＭＥ添付タイプにも同様の問題が存在する。これらの環境においては、あるファイルタイプが選択された際に起動されるアプリケーションプログラムを示すパス名を置換することによって、この問題は解決される。パス名は、起動するアプリケーションプログラムの選択肢をユーザに与えるチューザツールのパス名で置換される。
【０２５３】
図１５および概要を参照すると、ファイルタイプ関連付けデータを構成ストアに書き込むための要求が傍受される（ステップ１５０２）。構成ストア内のファイルタイプ関連付け情報を要求が更新しているか否かの判定が行われる（ステップ１５０４）。更新していない場合、すなわち、エントリが既に存在する場合、更新は発生しない（ステップ１５０６）。そうでなければ、第４．１．４節または第４．２．４節で上述した仮想化技術を使用して新規エントリが作成されるか、または既存エントリが更新される（ステップ１５０８）。新規または更新されたエントリは、適切な分離スコープに仮想化され、ファイル閲覧時または編集時に使用するために、ユーザが多くのアプリケーションプログラムのうちいずれかを選択するのを可能にするチューザツールに、ファイルタイプをマップする。
【０２５４】
図１５をさらに詳細に参照すると、ファイルタイプ関連付けデータを構成ストアに書き込むための要求が傍受される（ステップ１５０２）。いくつかの実施形態において、構成ストアはＷＩＮＤＯＷＳ（登録商標）レジストリデータベースである。データを構成ストアに書き込むための要求は、ユーザモードフッキング機能、カーネルモードフッキング機能、ファイルシステムフィルタドライバ、またはミニドライバによって傍受される場合がある。
【０２５５】
構成ストア内のファイルタイプ関連付け情報を要求が更新しようとしているか否かの判定が行われる（ステップ１５０４）。一実施形態において、これは、傍受された要求が、構成ストアの修正を意図していることを示すか否かを検出することによって実現される。別の実施形態において、要求のターゲットは、要求が構成ストアを修正するよう試みているか否かを判定するために、要求に含まれる情報と比較される。構成ストアがレジストリデータベースである実施形態では、第４．２節で上述したように、レジストリを修正するための要求が傍受される。
【０２５６】
要求が構成ストアの更新を試みていないと判定された場合、更新は発生しない（ステップ１５０６）。いくつかの実施形態においては、傍受された要求が読み込み要求であるため、構成ストアを更新する試みが行われていないと判定される。その他の実施形態において、この判定は、構成ストア内のターゲットエントリと傍受された要求に含まれる情報とが同一である、または実質的に同一である場合に行われ得る。
【０２５７】
しかしながら、ステップ１５０４において、要求が構成ストアを更新することを意図していると判定された場合、構成ストアにおいて新規エントリが作成されるか、または既存エントリが更新される（ステップ１５０８）。いくつかの実施形態において、ルールは、どの分離スコープにおいてエントリを作成または更新するかを判定する。いくつかの実施形態において、システムスコープまたはアプリケーション分離スコープ内で、新規エントリが作成されるか、または既存エントリが更新される。多くの実施形態において、適切なユーザ分離スコープ内で、新規エントリが作成されるか、または既存エントリが更新される。新規エントリが作成された場合、当該エントリは、傍受された要求中で識別されたアプリケーションを示すよりも、特定のタイプのファイルにアクセスする際に使用されるアプリケーションとしてチューザアプリケーションを記載する。いくつかの実施形態において、チューザツールは、アプリケーションの新規バージョンがインストールされた際、または同じファイルタイプをハンドルする別のアプリケーションがインストールされた際、または、当該特定のタイプのファイルをハンドルするためにアプリケーションが自身を登録もしくは登録解除する際に、自動的に更新される。いくつかの実施形態において、チューザツールは、チューツールがユーザスコープで実行している場合はシステムスコープおよびアプリケーションスコープ等、その他のスコープで維持されている構成ストアの部分において、同じファイルタイプをハンドルするために登録された任意のアプリケーションを、その適合するアプリケーションのリストに組み込むことができる。既存エントリが更新され、既存エントリが当該特定のファイルタイプのファイルが使用される際に使用するアプリケーションとしてチューザアプリケーションを既に記載している場合、チューザによって当該ファイルタイプに提示されたアプリケーションのリストは、更新アプリケーションを含むように更新されることができる。既存エントリが更新されたが、チューザアプリケーションを記載していない場合、当該特定のファイルタイプが使用される際に使用するアプリケーションとしてチューザアプリケーションを記載するために、更新されたエントリが作られる。これらの実施形態において、関連するアプリケーションに関する情報は、関連する構成ファイルに、または、いくつかの実施形態において、エントリとしてレジストリデータベースに保存されることができる。
【０２５８】
チューザアプリケーションは、選択されたファイルタイプに関連するアプリケーションのリストをユーザに提示することができる。当該アプリケーションは、ユーザがファイルを処理するために使用したいアプリケーションプログラムを選ぶことも可能にする。次いでチューザは、適切なスコープ、つまりシステムスコープ、アプリケーション分離スコープ、またはユーザ分離スコープにおいて、アプリケーションプログラムを起動する。いくつかの実施形態において、チューザツールは、ファイルタイプに関連するデフォルトアプリケーションプログラムのＩＤを維持する。これらの実施形態において、デフォルトアプリケーションは、デスクトップへのアクセスを持たない、または、ユーザに選択肢を提示することなくデフォルトハンドラを使用するように構成された、プロセスによって使用することができる。
【０２５９】
（４．７  分離環境間におけるプロセスの動的移動）
本発明の付加的側面は、異なる仮想スコープ間で作動中のプロセスを移動するための設備である。換言すると、分離環境２００によってアプリケーションインスタンスに提示されたネイティブリソースの集約ビューは、アプリケーションの実行中に異なる集約ビューに変更される場合がある。これにより、特定の分離スコープ内で分離されたプロセスを、プロセス作動中に別の分離スコープへ「移動する」ことが可能になる。これは、ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステム内のＭＳＩサービス等、一度に実行できるのが１つのインスタンスのみであるシステムサービスまたはプロセスに特に有用である。本発明のこの側面は、ユーザが連続的に数個の分離スコープで作業できるようにするために使用することもできる。
【０２６０】
図１６および概要を参照すると、１つの分離スコープと第２の分離スコープとの間、またはシステムスコープと分離スコープとの間で、プロセスを移動するためのプロセスの一実施形態が示されている。本明細書において使用する場合、「ターゲット分離スコープ」という用語は、システムスコープを含む、プロセス移動先の分離スコープに言及するために使用され、「ソース分離スコープ」という用語は、システムスコープを含む、プロセス移動元の分離スコープに言及するために使用される。図１６および概要に示すように、プロセスをターゲット分離スコープへ移動するための方法は、プロセスが安全な状態であることを確認するステップ（ステップ１６０２）と、プロセスの関連付けを、そのソース分離スコープからルールエンジン内のターゲット分離スコープに変更するステップ（ステップ１６０４）と、プロセスの関連付けを、ソース分離スコープから任意のフィルタドライバまたはフック用のターゲット分離スコープに変更するステップ（ステップ１６０６）と、プロセスが実行をレジュームするのを可能にするステップ（ステップ１６０８）とを含む。
【０２６１】
図１６をさらに詳細に参照すると、異なる分離スコープへ移動される間、プロセスは「安全な」状態でなくてはならない（ステップ１６０２）。いくつかの実施形態において、プロセスは、要求を処理していない時を判定するために監視される。これらの実施形態において、プロセスは、プロセスによって処理されている要求がない時に移動するために、「安全な」状態であると考えられる。これらの実施形態のいくつかにおいて、プロセスが「安全な」状態であると見なされると、プロセスへの新規要求はプロセスが移動されるまで遅延される。診断アプリケーションに関連するようなその他の実施形態において、分離スコープ内での変更をトリガするためにユーザインターフェースが提供される場合がある。これらの実施形態において、ユーザインターフェースは、プロセスを「安全な」状態に移動させるコードを実行することができる。また他の実施形態において、管理プログラムは、プロセスへの着信要求をすべて遅延させ、プロセスが任意のアクティブな要求の実行を完了するのを待つことによって、プロセスを強制的に「安全な」状態にすることができる。
【０２６２】
ターゲット分離スコープに関連するルールは、既にルールエンジンに存在しているのでなければ、ルールエンジンへロードされる（ステップ１６０３）。
【０２６３】
プロセスのソース分離スコープとの関連付けは、ルールエンジンにおいて変更される（ステップ１６０４）。上述したように、プロセスはいかなる分離スコープと関係付けられてもよい。当該関連付けは、仮想ネイティブリソースが要求に当てはまるルールを判定するためのすべての要求において、ルールエンジンによって使用される。アプリケーションインスタンスは、ルールエンジン内の適切なデータ構造に変更を加えることによって、ターゲット分離スコープと関連付けられることができる。いくつかの実施形態において、プロセスを新規分離スコープと関連付ける新規データベースエントリが書き込まれる。その他の実施形態において、プロセスが関連付けられている分離スコープの識別子を保存するツリーノードは、新規分離スコープを識別するために上書きされる。また他の実施形態において、オペレーティングシステムは、ターゲット分離スコープに関連するルール、または、いくつかの実施形態においては、ルールの識別子を保存するために、プロセス用の追加記憶装置を割り当てるようにできる。
【０２６４】
ソース分離スコープとのプロセスの関連付けは、関連付けまたはルールが、フィルタドライバ、カーネルモードフック、またはユーザモードフック等、ルールエンジン外のどこに保存されていても、変更される（ステップ１６０６）。プロセスと分離スコープルールとの間の関連付けがＰＩＤに基づいて維持される実施形態では、プロセスＰＩＤとルールセットとの間の関連付けが変更される。プロセスと分離ルールの適用可能なセットとの間の関連付けを維持するためにＰＩＤが使用されない実施形態では、ユーザモードフッキング機能は、ターゲット分離スコープに関連するルールセットにアクセスするよう変更される場合がある。分離スコープのルールセットとのプロセス関連付けがルールエンジンにおいて維持される実施形態では、上記のステップ１６０４においてルールエンジン内に保存された関連付けを変更すれば十分である。
【０２６５】
プロセスは、新規分離スコープにおいて実行をレジュームすることが可能である（ステップ１６１０）。新規要求が遅延された、または行われるのを禁止された実施形態では、それらの要求がプロセスに対して発行され、新規要求が許容される。
【０２６６】
特に有用な一側面において、上述の方法は、Ｍｉｃｒｏｓｏｆｔ製であり、Ｍｉｃｒｏｓｏｆｔ  ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムファミリーのいくつかにおいて利用可能なＭＳＩ、インストールパッケージおよびインストール技術を仮想化するために使用することができる。このインストールの技術によってパッケージされたアプリケーションは、ＭＳＩパッケージと呼ばれる。この技術をサポートするオペレーティングシステムは、ＭＳＩパッケージのインストールを支援する、ＭＳＩサービスと呼ばれるＷＩＮＤＯＷＳ（登録商標）サービスを有する。システムには、このサービスの単一のインスタンスがある。ＭＳＩパッケージをインストールすることを望むプロセスは、ＭＳＩサービスへのＣＯＭコールを作るそれらのセッションにおいて、ＭＳＩプロセスを作動させる。
【０２６７】
ＭＳＩパッケージをアプリケーション分離環境にインストールするために、ＭＳＩインストールを仮想化することができる。概念的には、これは、ＭＳＩサービスへのインストールセッションにおいて、ＭＳＩ  ＡＰＩに対して行われたコールをフックまたは傍受することによって達成できる。ミューテックスを使用して、一度に１つのインストールのみが行われることを確認することができる。新規インストールの開始を要求するＭＳＩ  ＡＰＩへのコールが受信または傍受され、コール元プロセスが特定のアプリケーション分離スコープと関連付けられると、コールを進めることが許容される前に、当該分離スコープのコンテキスト内にＭＳＩサービスが置かれる。ＭＳＩサービスによるネイティブリソース要求は、適用可能な分離スコープに従って仮想化されるが、インストールは、ＭＳＩサービスが通常のインストールアクションを行うのに伴って進められる。インストールプロセスの終了が検出されると、ＭＳＩサービスと分離スコープとの間の関連付けは除去される。上記ではＭＳＩに関して説明したが、上述の技術はその他のインストール技術にも適用可能である。
【０２６８】
（均等物）
本発明は、１つ以上の製品において具現化される１つ以上のコンピュータ可読プログラムとして提供され得る。製品は、フロッピー（登録商標）ディスク、ハードディスク、ＣＤ−ＲＯＭ、フラッシュメモリカード、ＰＲＯＭ、ＲＡＭ、ＲＯＭ、または磁気テープであってよい。概して、コンピュータ可読プログラムは、ＬＩＳＰ、ＰＥＲＬ、Ｃ、Ｃ＋＋、ＰＲＯＬＯＧ等の任意のプログラミング言語、またはＪＡＶＡ（登録商標）等の任意のバイトコード言語で実装されることができる。ソフトウェアプログラムは、オブジェクトコードとして１つ以上の製品に保存されることができる。
【０２６９】
本発明の一定の実施形態について説明したが、当業者には、本発明の概念を組み込んだその他の実施形態を使用できることが明らかになるであろう。したがって、本発明は一定の実施形態に限定すべきでなく、以下の特許請求の範囲の精神および範囲によってのみ限定されるべきである。
【図面の簡単な説明】
【０２７０】
添付の特許請求の範囲において、本発明を詳細に説明する。上述した本発明の利点は、本発明のさらなる利点と同様に、付随する図面と併せてなされる以下の説明を参照することにより、より良く理解できる。
【図１Ａ】図１Ａは、ユーザに代わって２つのアプリケーションプログラムの実行をサポートする先行技術のオペレーティングシステム環境のブロック図である。
【図１Ｂ】図１Ｂは、数人のユーザに代わって多くのアプリケーションの同時実行をサポートする先行技術のオペレーティングシステム環境のブロック図である。
【図２Ａ】図２Ａは、アプリケーションプログラム互換性および社交性の問題を低減したコンピュータシステムの実施形態のブロック図である。
【図２Ｂ】図２Ｂは、アプリケーションプログラム互換性および社交性の問題を低減したコンピュータシステムの実施形態の図である。
【図２Ｃ】図２Ｃは、プロセスを分離スコープと関連付けるために取られるステップの一実施形態を示すフローチャートである。
【図３Ａ】図３Ａは、コンピュータシステムにおいてネイティブリソースへのアクセスを仮想化するために取られるステップの一実施形態を示すフローチャートである。
【図３Ｂ】図３Ｂは、実行モードで置換インスタンスを識別するために取られるステップの実施形態を示すフローチャートである。
【図３Ｃ】図３Ｃは、リソースがそれを修正することを意図して開かれることを示す、ネイティブリソースを開くための要求が受信された際に、文字リソースを識別するためにインストールモードで取られるステップの一実施形態を描写したフローチャートである。
【図３Ｄ】図３Ｄは、仮想リソースを作成するための要求が受信された際に、文字リソースを識別するためにインストールモードで取られるステップの一実施形態を描写したフローチャートである。
【図４】図４は、上述の仮想化環境において、ファイルシステム内のエントリを開くために取られるステップの一実施形態を描写したフローチャートである。
【図５】図５は、上述の仮想化環境において、ファイルシステムからエントリを削除するために取られるステップの一実施形態を描写したフローチャートである。
【図６】図６は、上述の仮想化環境において、ファイルシステム内のエントリを列挙するために取られるステップの一実施形態を描写したフローチャートである。
【図７】図７は、上述の仮想化環境において、ファイルシステム内でエントリを作成するために取られるステップの一実施形態を描写したフローチャートである。
【図７Ａ】図７Ａは、一実施形態を描写したフローチャートである。
【図８】図８は、上述の仮想化環境において、レジストリキーを開くために取られるステップの一実施形態を描写したフローチャートである。
【図９】図９は、上述の仮想化環境において、レジストリキーを削除するために取られるステップの一実施形態を描写したフローチャートである。
【図１０】図１０は、上述の仮想化環境において、レジストリデータベース内のキーのサブキーを列挙するために取られるステップの一実施形態を描写したフローチャートである。
【図１１】図１１は、上述の仮想化環境において、レジストリキーを作成するために取られるステップの一実施形態を描写したフローチャートである。
【図１２】図１２は、名前付きオブジェクトへのアクセスを仮想化するために取られるステップの一実施形態を描写したフローチャートである。
【図１３】図１３は、上述の環境において、ウィンドウ名およびウィンドウクラスを仮想化するために取られるステップの一実施形態を描写したフローチャートである。
【図１３Ａ】図１３Ａは、文字ウィンドウ名およびウィンドウクラス名を判定するために取られるステップの一実施形態を描写したフローチャートである。
【図１４】図１４は、上述の仮想化環境において、プロセス外ＣＯＭサーバを呼び出すために取られるステップの一実施形態を描写したフローチャートである。
【図１５】図１５は、ファイルタイプ関連付けを使用してアプリケーション呼び出しを仮想化するために取られるステップの一実施形態を描写したフローチャートである。
【図１６】図１６は、ソース分離スコープからターゲット分離スコープへプロセスを移動するために取られるステップの一実施形態を描写したフローチャートである。
【図１Ａ】
2008521071.tif 000004
【図１Ｂ】
2008521071.tif 000005
【図２Ａ】
2008521071.tif 000006
【図２Ｂ】
2008521071.tif 000007
【図２Ｃ】
2008521071.tif 000008
【図３Ａ】
2008521071.tif 000009
【図３Ｂ】
2008521071.tif 000010
【図３Ｃ】
2008521071.tif 000011
【図３Ｄ】
2008521071.tif 000012
【図４】
2008521071.tif 000013
【図５】
2008521071.tif 000014
【図６】
2008521071.tif 000015
【図７】
2008521071.tif 000016
【図７Ａ】
2008521071.tif 000017
【図８】
2008521071.tif 000018
【図９】
2008521071.tif 000019
【図１０】
2008521071.tif 000020
【図１１】
2008521071.tif 000021
【図１２】
2008521071.tif 000022
【図１３】
2008521071.tif 000023
【図１３Ａ】
2008521071.tif 000024
【図１４】
2008521071.tif 000025
【図１５】
2008521071.tif 000026
【図１６】
2008521071.tif 000027
【国際調査報告】
2008521071.tif 000028
2008521071.tif 000029
2008521071.tif 000030