JP5118638B2 - ユーザアカウント内のアプリケーション特有データの隔離 - Google Patents

Description

従来、オペレーティングシステムは、ユーザアカウントの粒度でアプリケーション特有のデータを隔離する。すなわち、異なるユーザアカウントで動作するアプリケーションは、相互に隔離される。その結果、あるユーザアカウントで動作するアプリケーションは、別のユーザアカウントで動作する同一のアプリケーション用のデータにアクセスできない。しかし、同一のユーザアカウントで実行するアプリケーション用のデータは、相互に隔離されない。その結果、あるユーザアカウントで実行するアプリケーションが、同一のユーザアカウントで実行する別のアプリケーション用のデータにアクセスし、変更することさえ可能である。これによって潜在的な安定性、セキュリティ及び管理に問題をもたらし得る。したがって、同一のユーザアカウントを共有するアプリケーションの間でアプリケーション特有のデータを隔離するためのメカニズムを提供するのが望まれる。

詳細説明において、さらに後述する概念を抽出したものを簡易化された形式で紹介するためにこの概要を提供する。この概要は、請求項に記載された対象に関する重要な特徴を特定することを意図せず、また請求項に記載された対象の範囲を決定する際の支援として使用されることも意図しない。

複数のアプリケーションが同一のユーザアカウントに関連付けられた環境において、本発明によって、アプリケーション特有のデータが別のアプリケーションから隔離できる。例えば、本発明はデータにアクセスするために、ハンドルを基本とするアプローチを使用する。アプリケーションが、データに対するハンドルを所有している場合、そのアプリケーションは、データにアクセスできる。データがアプリケーション特有である場合、そのデータ用にただ１つのハンドルを生成できる。ハンドルは、データを特定しているアプリケーションに渡される。ハンドルを所有するアプリケーションだけがそのデータにアクセスできる。同一のユーザアカウントをアプリケーションと共有する別のアプリケーションからのアクセスリクエストは拒否される。

本発明の一特徴によると、アプリケーションがデータにアクセスする必要があって、データがロードされていないとき、データがまずロードされる。望ましくは、固有識別子がデータ用に生成される。固有識別子はその後、データ用のアクセス経路を形成するために使用される。アクセス経路は、データがロードされ得る場所を示す。データは、その場所にロードされる。ハンドルは、ロードされたデータ用に生成され、アプリケーションに渡される。アプリケーションは、ハンドルを介しデータにアクセスできる。アプリケーションただ１つがデータにアクセスできる場合、そのデータはそのアプリケーション特有と見なされる。同一のユーザアカウントをそのアプリケーションと共有する他のいかなるアプリケーションもロードされたデータに対するハンドルを生成できず、ハンドルを介してデータにアクセスもできない。他方、データがアプリケーション特有でない場合、別のアプリケーションは、データに対するハンドルを生成し、そのハンドルを介しデータにアクセスできる。

本発明のもう１つの特徴によると、データがロードされるとき、カウンタがそのデータ用に生成される。ハンドルがそのデータ用に生成される度にカウンタの値を増やし、そのデータ用のハンドルが終了される度に減らす。カウンタの値が０に達すると、データは自動的にアンロードされる。

本発明のさらなる特徴によると、アプリケーション特有のデータアクセスのためにアプリケーションプログラミングインターフェースが提供される。複数のアプリケーションが同一のユーザアカウントを共有する環境において、アプリケーションプログラミングインターフェースは、計算プロセスすなわちアプリケーションからアクセスリクエストを受信したときにデータオブジェクトへのアクセスを提供する機能を含む。アクセスをリクエストする計算プロセスのみによって、データオブジェクトがアクセスされ得るだけであるように本機能を構成できる。すなわち、別の計算プロセスはそのデータオブジェクトにアクセスできない。望ましくは、本機能を現在呼んでいる計算プロセスだけがデータオブジェクトにアクセスできるように構成され得るパラメタを本機能は含む。また、データオブジェクトにアクセスするための本機能を呼ぶ任意の計算プロセスがデータオブジェクトにアクセスできるようにもパラメタを構成できる。

さらに具体的にいうと、データオブジェクトへのアクセスをリクエストする計算プロセスによって呼ばれたとき、本機能はそのデータオブジェクト用の固有識別子を生成する。固有識別子はその後、データオブジェクトをロードするための場所を示す経路を生成するために使用され得る。それにしたがって本機能がその後、データオブジェクトをロードする。本機能はその後、ロードされたデータオブジェクトへのハンドルを計算プロセスに返す。計算プロセスがアクセスリクエストを完了する度に、対応するハンドルを終了する。データオブジェクトに関連付けられるハンドルがなくなると、本機能はそのデータオブジェクトをアンロードする。

要約すれば、本発明によって、アプリケーション特有のデータが同一のユーザアカウントを前記アプリケーションと共有する別のアプリケーションによってアクセスされるのを防ぐことができる。本発明によって、アプリケーション特有のデータは、そのアプリケーションだけによってアクセス可能になる。こうして同一のユーザアカウントをアプリケーションと共有する別のアプリケーションは、アプリケーション特有のデータの整合性を干渉し得ない。

添付図面と併用するときに以下の詳細説明を参照することにより、同等のことがさらに理解されるようになるので、上記の特徴及び本発明の添付の利点の多くが、さらに容易に正しく評価されるようになるだろう。

一般的に説明すると、本発明の実施形態は、同一のユーザアカウントに関連付けられたアプリケーション間においてアプリケーション特有のデータを隔離する。さらに具体的にいうと、本発明の実施形態は、複数のアプリケーションが同一のユーザアカウントに関連付けられている環境において、データにアクセスするためのハンドルを基本とするアプローチを採用する。アプリケーションが、アプリケーション特有のデータにアクセスする必要があるとき、そのデータはロードされ、ハンドルがデータ用に生成され、アプリケーションに渡される。アプリケーションは、ハンドルを介しデータにアクセスする。別のアプリケーションは、そのデータ用のハンドルを生成できず、したがってそのデータへのアクセスは拒否される。本発明の実施形態においては、データは、同一のユーザアカウントを共有するアプリケーションによって使用され得る任意のデータを含み得る。

図１はユーザ（１０１）のために複数のアプリケーションをホスティングする計算機システム（１００）を例示する。複数のアプリケーションは、アプリケーションＡ（１０２Ａ）及びアプリケーションＢ（１０２Ｂ）を含む。例示されたこの例においては、アプリケーションデータＡ（１０４Ａ）は、アプリケーションＡ（１０２Ａ）特有であり、一方、アプリケーションデータＢ（１０４Ｂ）は、アプリケーションＢ（１０２Ｂ）特有である。本発明の実施形態においては、アプリケーション特有のデータオブジェクトに対してアプリケーションからアクセスリクエストを受信したとき、固有識別子（”ＵＩＤ”）が動的に生成される。ＵＩＤは、データオブジェクト用のアクセス経路を生成するために使用される。例えばアプリケーションＡ（１０２Ａ）が一旦、アプリケーションデータＡ（１０４Ａ）をリクエストすると、ＵＩＤ Ａ（１０６Ａ）が動的に生成される。ＵＩＤ Ａ(１０６Ａ)はその後、／ｒｏｏｔ／ａｐｐ／ＵＩＤ Ａ／Ａｐｐｌｉｃａｔｉｏｎ Ｄａｔａ Ａのようなアクセス経路を生成するのに使用され、そのアクセス経路によって指定される場所にアプリケーションデータＡ（１０４Ａ）をロードするために使用され得る。同様に、アプリケーションＢ（１０２Ｂ）がアプリケーションデータＢ（１０４Ｂ）にアクセスすることを望むときは、計算機システム（１００）は、ＵＩＤ Ｂ（１０６Ｂ）を動的に生成し、ＵＩＤ Ｂは、アプリケーションデータＢ（１０４Ｂ）用のアクセス経路を形成するのに使用される。そのようなアクセス経路は、例えば、／ｒｏｏｔ／ａｐｐ／ＵＩＤ Ｂ／Ａｐｐｌｉｃａｔｉｏｎ Ｄａｔａ Ｂであり得る。アプリケーションデータＢ（１０４Ｂ）は、アクセス経路によって指定される場所にロードされ得る。

本発明の実施形態においては、ＵＩＤ及びアプリケーション特有のデータオブジェクト用アクセスに対応する経路の生成後、計算機システム（１００）は、アクセス経路によって指定される場所にデータオブジェクトをロードする。計算機システム（１００）はその後、ロードされたデータオブジェクトへのハンドルを生成し、データオブジェクトをリクエストしているアプリケーションにそのハンドルを渡す。例えば図１に示されるように、アプリケーションＡ（１０２Ａ）は、アプリケーションデータＡ（１０４Ａ）へのハンドルＡ（１１０Ａ）を受け取る。アプリケーションＢ（１０２Ｂ）は、アプリケーションデータＢ（１０４Ｂ）へのハンドルＢ（１１０Ｂ）を受け取る。本発明の実施形態においては、データオブジェクトへのハンドルを所有するアプリケーションだけが、データオブジェクトにアクセスでき、データオブジェクトを明確に特定するアプリケーションだけが、そのデータオブジェクトへのハンドルを所有できる。したがって、図１に例示された例において、アプリケーションＡ（１０２Ａ）だけが、アプリケーションデータＡ（１０４Ａ）にアクセスでき、アプリケーションＢ（１０２Ｂ）だけが、アプリケーションデータＢ（１０４Ｂ）にアクセスできる。

理論的には別のアプリケーションがそのアクセス経路を介し、データオブジェクトにアクセスできる。本発明の実施形態においては、あるアプリケーションがそのアクセス経路を介しデータオブジェクトにアクセスするのを試みる場合、そのアクセスは拒否される。例えば、前述のようにアプリケーションデータＡ（１０４Ａ）用のアクセス経路は、／ｒｏｏｔ／ａｐｐ／ＵＩＤ Ａ／Ａｐｐｌｉｃａｔｉｏｎ Ｄａｔａ Ａである。理論的には、アプリケーションＢ（１０２Ｂ）は、このアクセス経路を介し、アプリケーションデータＡ（１０４Ａ）にアクセスできる。本発明の実施形態においては、そのようなアクセスを拒否し、ハンドルＡ（１１０Ａ）を介しアプリケーションデータＡ（１０４Ａ）に対してのみアクセスを許可する。このように、アプリケーションＡ（１０２Ａ）だけがアプリケーションデータＡ（Ａ１０４）にアクセスできる。

本発明の実施形態はまた、ロードされたデータオブジェクト用のカウンタも提供する。ロードされたデータオブジェクト用にハンドルが生成される度に、カウンタの値を増やす。ロードされたデータオブジェクトへのハンドルが終了される度に、カウンタの値を減らす。本発明の実施形態においては、カウンタの値が０に達すると、対応するデータオブジェクトはアンロードされる。例えば、図１に示されるように、ロードされたアプリケーションデータＡ（１０４Ａ）はカウンタ（１１２Ａ）に関連付けられ、ロードされたアプリケーションデータＢ（１０４Ｂ）はカウンタ（１１２Ｂ）に関連付けられる。本発明の実施形態においては、あるデータオブジェクトがロードされると、別のアプリケーションは、そのロードされたデータオブジェクトと別のデータオブジェクトとを置換できない。

本発明の例示的な実施形態においては、計算機システム（１００）は、マイクロソフト（登録商標）ウィンドウズ（登録商標）オペレーティングシステムを使用する。当業者によって知られているように、マイクロソフト（登録商標）ウィンドウズ（登録商標）オペレーティングシステムは、システム及びユーザ関連のデータ用のセントラルリポジトリとして、ウィンドウズ（登録商標）レジストリを使用する。ディスク上では、ウィンドウズ（登録商標）レジストリは、個別ファイル、データオブジェクトのセットとして組織化されていてハイブ（ｈｉｖｅ）と呼ばれる。ハイブそれぞれは、データの階層構造を含む。ハイブが計算機システムのファイルシステムにロードされると、ハイブへのアクセス経路がＨＫＥＹ ＬＯＣＡＬ ＭＡＣＨＩＮＥ／ＳＹＳＴＥＭ／ＣｕｒｒｅｎｔＣｏｎｔｒｏｌＳｅｔ／Ｃｏｎｔｒｏｌ／ｈｉｖｅｌｉｓｔ下に記録される。ハイブがアンロードされると、アクセス経路は削除される。

今、マイクロソフト（登録商標）ウィンドウズ（登録商標）オペレーティングシステムが始動すると、ウィンドウズ（登録商標）レジストリは、デフォルトによりいくつかのハイブをロードする。従来、ＲｅｇＬｏａｄＫｅｙ ＡＰＩは、ユーザが特定のハイブをオンデマンドでロード可能にすることに使用されてきた。ＲｅｇＬｏａｄＫｅｙ ＡＰＩを使用し、ハイブがロードされると、ハイブはシステム全体から見えるようになる。その結果、十分なアクセス権を有する人であればハイブのデータにアクセスできる。しかし、ＲｅｇＬｏａｄＫｅｙ ＡＰＩにより、普通のユーザは特権を必要としないでハイブをロードできない。ＲｅｇＬｏａｄＫｅｙ ＡＰＩはまた、同一のユーザアカウントで動作する別のアプリケーションが、ハイブのデータを操作することを防げない。

ＲｅｇＬｏａｄＫｅｙ ＡＰＩによってもたらされる制限の解決のために、本発明の例示的な実施形態は、例えば、ＲｅｇＬｏａｄＡｐｐＫｅｙと呼ばれる新規のハイブロードＡＰＩを提供する。ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩによってユーザは、特権を必要とせずにハイブをロードできる。ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩはまた、このＡＰＩを使用しロードされたハイブのアプリケーションレベルの隔離も可能にする。システムワイドの可視性を有するハイブをロードする既存のＲｅｇＬｏａｄＫｅｙ ＡＰＩと異なり、ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩは、プロセスワイドの可視性だけを有するハイブをロードする。すなわち、ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩを呼ぶプロセスだけが、ハイブへのハンドルを取得する。ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩは、ハイブを首尾よくロードする最初のプロセスだけに対してハイブを公開する。このようにＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩを使用し、アプリケーションは、そのアプリケーションだけに関連する設定を含むハイブをロード可能であって、同一又は異なるユーザアカウントの下で実行するいかなる他のアプリケーションもこのハイブにアクセスできないことを保証できる。アプリケーションの終了時又はハイブに関連付けられるハンドルへの最後のリファレンスがクローズされると、ハイブは自動的にアンロードされる。

図２は、ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩ（２００）の例示的な使用法を例示する。アプリケーション（２０２）が特定のハイブをロードするためにＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩ（２００）を呼ぶと、アプリケーション（２０２）は、ロードされるべきハイブのファイル名をＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩ（２００）に提供する。提供されたファイル名にしたがって、ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩ（２００）は、指定されるハイブをロードし、逆にアプリケーション（２０２）へハイブ用ハンドル（２０４）を提供する。アプリケーション（２０２）はその後、ハンドル（２０４）を介しロードされたハイブを操作できる。

ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩ（２００）の例示的な実装においては、ロードされるハイブのファイル名を受信したとき、ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩ（２００）は、ＵＩＤ（２０６）を生成する。ハイブが既にロードされている場合は、ＵＩＤ（２０６）は無視される。そうでない場合、ＵＩＤ（２０６）は、「ロードする場所への経路」（２０８）を形成するために使用され、ハイブをロード可能な場所を示す。例えば、ハイブを／ｒｅｇｉｓｔｒｙ／ａｐｐ／ＵＩＤにロードできる。

本発明の例示的な実施形態においては、ＲｅｇＬｏａｄＡｐｐＫｅｙ（２００）はその後、ハイブをロードするために、ＮｔＬｏａｄＫｅｙＥｘ ＡＰＩ（２１０）を呼ぶことができる。ＮｔＬｏａｄＫｅｙＥｘ ＡＰＩ（２１０）は、「ロードする場所への経路」（２０８）によって指定される場所にハイブをロードし、ハイブ用のハンドル（２０４）を返す。望ましくは、アプリケーション（２０２）がハイブにアクセスするために、ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩ（２００）を呼ぶ度に、ハイブ（２０４）用のハンドルが生成される。アプリケーション（２０２）がアクセスを手放すと、対応するハンドルがクローズされる。ハイブ用のハンドルすべてがクローズされると、ハイブは自動的にアンロードされる。

操作上、ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩ（２００）は、ハイブへのアクセスが呼び出したアプリケーション（２０２）に限定される指定をするためのパラメタを含むことができる。パラメタが指定されると、その後、別のアプリケーションによる同一のハイブをロードする試みは失敗し、このようにそれをロードしたアプリケーション（２０２）だけに対してハイブをアクセス可能にする。パラメタが指定されない場合、複数のアプリケーション、すなわちプロセスが、同一のハイブをロードできる。さらに、あるアクセスリクエストが、ハイブ用のハンドル（２０４）からの代わりに「ロードする場所への経路」（２０８）を介してハイブへのアクセスを試みる場合、ＲｅｇＬｏａｄＡｐｐＫｅｙ ＡＰＩ（２００）は、そのアクセスリクエストを拒否する。

図３Ａ及び３Ｂは、同一のユーザアカウントをそのアプリケーションと共有する別のアプリケーションからそのアプリケーション特有のデータを隔離するための例示的なプロセス（３００）を示す。本質的にデータがアンロードされた場合、プロセス（３００）は、リクエストされたデータをロードし、ロードされたデータへのハンドルを生成し、そのデータをリクエストしているアプリケーションにハンドルを渡す。プロセス（３００）はまた、データに関連付けられたハンドル数を追跡するために、カウンタを使用する。ハンドルがデータ用に生成される度にカウンタの値を増やし、アプリケーションがデータに関連付けられたハンドルを終了する度に減らす。カウンタの値が０に達すると、データは自動的にアンロードされる。特にアプリケーションは、他のいかなるアプリケーションもデータにアクセスできない仕様のもとデータをロードできる。このような場合、別のアプリケーションからのアクセスリクエストは拒否される。

具体的にいうと図３Ａに示されるように、アプリケーションＡがあるデータへのアクセスをリクエストすると、プロセス（３００）が開始される。判断ブロック（３０１）を参照されたい。本発明の例示的な実施形態においては、そのようなリクエストを受信したとき、プロセス（３００）がデータ用の固有識別子を生成する。ブロック（３０２）を参照されたい。プロセス（３００）はその後、固有識別子を使用し、データ用アクセス経路を生成する。ブロック（３０４）を参照されたい。前述のように、例えばＵＩＤ Ａ（１０６Ａ）を有するプリケーションデータＡ（１０４Ａ）用のアクセス経路は、／Ｒｏｏｔ／Ａｐｐ／ＵＩＤ Ａ／ＡｐｐｌｉｃａｔｉｏｎＤａｔａＡである。

プロセス（３００）はその後、別のアプリケーションによって既にデータをロードされたか否かを決定するために次に進む。判断ブロック（３０５）を参照されたい。判断ブロック（３０５）に対する回答が肯定である場合、プロセス（３００）は、ロードされたデータがアプリケーション特有か、すなわちデータをロードしたアプリケーションだけがデータにアクセスできるか否かの決定するために次に進む。判断ブロック（３０６）を参照されたい。判断ブロック（３０６）に対する回答が肯定の場合、データはアプリケーション特有であって、かつ、別のアプリケーションによってロードされたことを意味し、プロセス（３００）は終了する。アプリケーションＡからのアクセスリクエストは拒否される。

判断ブロック（３０６）に対する回答が否定の場合、そのデータは複数のアプリケーションからアクセスされ得ることを意味し、プロセス（３００）は、ロードされたデータへのハンドルを生成する。ブロック（３０９）を参照されたい。

一方、判断ブロック（３０５）に対する回答が否定である場合、データはいかなるアプリケーションによってもロードされていないことを意味し、プロセス（３００）は、生成されたアクセス経路によって特定される場所にデータをロードする。ブロック（３０７）を参照されたい。プロセス（３００）はその後、ロードされたデータに関連付けられるカウンタを生成する。ブロック（３０８）を参照されたい。カウンタの初期値は、０に設定される。プロセス（３００）はその後、データへのハンドルを生成する。ブロック（３０９）を参照されたい。プロセス（３００）は、ハンドルをアプリケーションに渡す。ブロック（３１０）を参照されたい。プロセス（３００）は、ブロック（３１０）から継続端子Ａに続く。

本発明の実施形態においては、データがアプリケーション特有である場合、たった１つのハンドルがデータ用に生成され、そのハンドルを所有しているアプリケーションだけがそのデータにアクセスできる。別のアプリケーションは、データに対するハンドルを有しないために、そのデータにアクセスできない。前述のように、理論的には別のアプリケーションは、生成されたアクセス経路を介しデータにアクセスできる。しかし、本発明の実施形態は、そのアクセス経路を介したデータへのアクセスを拒否する。したがって、データに対するハンドルを所有しているアプリケーションだけが、そのデータにアクセスできる。

本発明の実施形態においては、ロードされたデータに関連付けられたハンドル数を追跡するために、カウンタが使用される。ハンドルがロードされたデータ用に生成される度にカウンタの値を増やし、データへのハンドルが終了される度に減らす。カウンタの値が０に達すると、データは自動的にアンロードされる。その結果、継続端子Ａからの図３Ｂに例示されるように、ハンドルがデータ用に生成されると、カウンタを増やす。ブロック（３１４）を参照されたい。さらに、データへのハンドルを終了されると、カウンタの値を減らす。ブロック（３１６）を参照されたい。本発明の実施形態においては、プロセス（３００）は、カウンタの値が０に達したか否かを決定するために、その値を定期的にチェックする。判断ブロック（３１８）を参照されたい。カウンタの値が０に達すると、そのデータに関連付けられたハンドルがないことを意味し、プロセス（３００）は、データをアンロードする。ブロック（３２０）を参照されたい。判断ブロック（３１８）に対する回答が否定の場合、カウンタの値は０でないことを意味し、プロセス（３００）は、ループしてカウンタの値の任意の調整を待つためにブロック（３１４）へ戻る。一旦、データがアンロードされると、プロセス（３００）は終了する。

結果として本発明の実施形態は、同一のユーザアカウントのもとで実行するアプリケーション特有のデータを隔離する。本発明の実施形態はまた、データオブジェクトへの最後のリファレンスが一旦、クローズされると、データオブジェクトを自動的にアンロードする。

本発明の例示的な実施形態を示し説明してきたが、本発明の趣旨と範囲から逸脱せずに本明細への様々な変更を行うことができるのがよく理解されよう。

本発明の特徴を実施するための例示的な計算機システムを示すブロック図であって、同一のユーザアカウントを有する複数のアプリケーションに対し、アプリケーション特有のデータが隔離される。 本発明の特徴を実施するための例示的なウィンドウズ（登録商標）のＡＰＩを示すブロック図である。 あるユーザアカウント内でアプリケーション特有のデータを隔離するための例示的なプロセスを示すフロー図である。 あるユーザアカウント内でアプリケーション特有のデータを隔離するための例示的なプロセスを示すフロー図である。

Claims (13)

1. 同一のユーザアカウントに複数のアプリケーションを関連付ける計算機システムにおいて、メモリーに記憶された第１のアプリケーション特有のデータを第２のアプリケーションのアクセスから隔離するための方法であって、第１のアプリケーション及び第２のアプリケーションが、アプリケーション設定のセントラルリポジトリへの共有アクセスを提供する前記同一のユーザアカウントを共有していて、
   前記データに対するアクセスリクエストを前記第１のアプリケーションから受信したとき、前記データを前記セントラルリポジトリからメモリー内のアクセス経路によって特定される記憶位置にロードするステップと、
   前記アクセス経路によって特定された記憶位置のデータへのハンドルを生成するステップと、
   前記ハンドルを前記第１のアプリケーションに渡すステップと、
   前記第１のアプリケーションから受信した前記アクセスリクエストと共に受け取った情報に基づいて、前記データが、他のアプリケーションがアクセスできない、第１のアプリケーション特有と指定されたデータであるか否かを決定するステップと、
   前記データが第１のアプリケーション特有と指定されたデータであると決定されたとき、前記第1のアプリケーションに渡されたハンドルのほかに当該データへの追加のハンドルの生成を防止して唯一のハンドルのみが当該データにアクセス可能であるようにし、前記第２のアプリケーションが前記唯一のハンドルを有しないために前記第２のアプリケーションからの当該データに対するアクセスリクエストを拒否するステップと、
   前記データが第１のアプリケーション特有と指定されていないデータであると決定されたとき、他のハンドルの生成を可能にして、当該他のハンドルを用いる前記第２のアプリケーションからの前記データに対する１つ以上のアクセスリクエストを許可するステップと、を含む方法。
2. 前記データをメモリーにロードするステップが、
   前記データ用の固有識別子を生成するステップと、
   前記固有識別子を使用し、前記データ用のアクセス経路を生成するステップと、
   前記アクセス経路によって指定される前記メモリー内の記憶位置に前記データをロードするステップと、を含む請求項１記載の方法。
3. さらに、前記データをロードしたあと前記データ用のカウンタをメモリー内に生成するステップであって、前記カウンタの値が０に初期化されるものと、
   前記ハンドルが前記データ用に生成されるとき前記カウンタの値を増やすステップと、
   前記ハンドルが終了されるとき前記カウンタの値を減らすステップと、を含む請求項１記載の方法。
4. さらに、前記カウンタの値が０に達したとき、前記データを前記メモリーからアンロードするステップを含む請求項３記載の方法。
5. 前記計算機システムがマイクロソフトのウィンドウズ（登録商標）レジストリを含み、前記データが、ウィンドウズ（登録商標）レジストリの１つ以上のハイブであることを特徴とする請求項１記載の方法。
6. 複数のアプリケーションが同一のユーザアカウントを共有するコンピューター環境において、コンピューターによって実行された時に、当該コンピューターにアプリケーション特有のデータアクセスを提供させる方法であって、
   第１のアプリケーションから、メモリーに記憶されたデータに対するアクセスリクエストを受け取るステップであって、当該データが、前記同一のユーザアカウントを共有する複数のアプリケーションに対するアプリケーション設定のセントラルリポジトリのデータであるものと、
   前記アプリケーション設定のセントラルリポジトリのデータへのハンドルを前記第１のアプリケーションに返すステップと、
   少なくとも前記アクセスリクエストと共に受け取った情報に基づいて、前記データへのアクセスが前記第１のアプリケーションに限定されているか否かを決定するステップであって、前記第１のアプリケーションが、他のアプリケーションがアクセスできないアプリケーション特有データとしての前記データへの排他的アクセスを有するか否かを少なくとも決定するステップを含むものと、
   そのアクセスが限定されていると決定されたとき、他のハンドルの生成を防止して、前記第１のアプリケーションと同一のユーザアカウントを共有する他のアプリケーションからの前記データへのアクセスを拒否して、前記同一のユーザアカウントを共有する複数のアプリケーションに対するアプリケーション設定のセントラルリポジトリのデータが前記第１のアプリケーションによってのみアクセス可能であるようにするステップと、
   そのアクセスが限定されていないと決定されたとき、他のハンドルの生成を可能にして、前記アプリケーション設定のセントラルリポジトリのデータに対する複数のアプリケーションの共有アクセスを許可するステップと、を含む方法を実行させる、１つ以上の計算機可読記憶媒体に記憶されるプログラム。
7. 前記アクセスリクエストと共に受け取った情報が、前記データへのアクセスが、前記機能を呼ぶ前記第１のアプリケーションに限定されるか否かを示すように構成可能な機能パラメタ、を含むことを特徴とする請求項６記載のプログラム。
8. 前記方法が、更に、
   前記アプリケーション設定のセントラルリポジトリのデータ用の固有識別子を生成するステップと、
   前記固有識別子を使用しアクセス経路を生成するステップと、
   前記アクセス経路で示される位置に前記アプリケーション設定のセントラルリポジトリのデータをロードするステップと、を含む事を特徴とする請求項６記載のプログラム。
9. 前記方法が、更に、
   前記第１のアプリケーションが前記ハンドル使用を終了するとき、前記ハンドルをクローズするステップと、
   いかなるハンドルも前記アプリケーション設定のセントラルリポジトリのデータと関連付けられていないとき、前記アプリケーション設定のセントラルリポジトリのデータをアンロードするステップと、を含む事を特徴とする請求項６記載のプログラム。
10. 第１のアプリケーションと同一のユーザアカウントを共有する別のアプリケーションのアクセスから、メモリーに記憶された前記第１のアプリケーション特有のデータを隔離するための計算機に実装された方法であって、当該データが、前記同一のユーザアカウントを共有する複数のアプリケーションに対するアプリケーション設定のセントラルリポジトリのデータであり、
    前記データに対して前記第１のアプリケーションからアクセスリクエストを受信したとき、前記同一のユーザアカウントを共有する複数のアプリケーションに対するアプリケーション設定のセントラルリポジトリからのアプリケーション設定のセントラルリポジトリの前記データをメモリー内の記憶位置にロードするステップと、
    アクセス経路によって特定される記憶位置における前記データへのハンドルを生成するステップと、
    前記ハンドルを前記第１のアプリケーションに渡すステップと、
    少なくとも前記アクセスリクエストと共に受け取った情報に基づいて、アプリケーション設定のセントラルリポジトリの前記データが前記第１のアプリケーション以外のアプリケーションがアクセスできないものとして指定されているか否かを決定するステップと、
    アプリケーション設定のセントラルリポジトリの前記データが前記第１のアプリケーション以外のアプリケーションがアクセスできないものとして指定されていると決定されたとき、他のハンドルの生成を防止して、前記第１のアプリケーションと同一のユーザアカウントを共有する他のアプリケーションから、同一のユーザアカウントを共有する複数のアプリケーションに対するアプリケーション設定のセントラルリポジトリの前記データへのいかなるアクセスリクエストも拒否するステップと、
    アプリケーション設定のセントラルリポジトリの前記データが前記第１のアプリケーション以外のアプリケーションがアクセスできないものとして指定されていないと決定されたとき、他のハンドルの生成を可能にして、アプリケーション設定のセントラルリポジトリの前記データへの前記他のアプリケーションからのアクセスを許可するステップと、
    を含む方法。
11. 前記データをメモリー内の記憶位置にロードするステップが、
    前記データ用の固有識別子を生成するステップと、
    前記固有識別子を使用して前記データ用のアクセス経路を生成するステップと、
    前記アクセス経路によって指定される前記メモリー内の記憶位置に前記データをロードするステップと、を含む請求項１０記載の計算機実装方法。
12. さらに、前記データをロードするとき前記データ用のカウンタをメモリー内に生成し、前記カウンタの値が０に初期化するステップと、
    前記データのためにハンドルが作成される度に前記カウンタの値を増やすステップと、
    前記ハンドルが終了される度に前記カウンタの値を減らすステップを含む請求項１０記載の計算機実装方法。
13. さらに、前記カウンタの値が０に達するとき、前記データを前記メモリーからアンロードするステップを含む請求項１２記載の計算機実装方法。

Images