JP2004536364A

JP2004536364A - 情報オブジェクトを管理するためのシステムおよび方法

Info

Publication number: JP2004536364A
Application number: JP2002548541A
Authority: JP
Inventors: ゲイリーコール，
Original assignee: ウェーブセットテクノロジーズインコーポレイテッド
Priority date: 2000-12-06
Filing date: 2001-11-06
Publication date: 2004-12-02
Also published as: US20020095395A1; AU2002246595A1; WO2002046873A2; EP1370938A2; WO2002059794A2; IL156287A0; AU2002230616A1; WO2002059794A3; EP1356363A2; US7574413B2; US20020093857A1; IL156288A0; JP2004534987A; WO2002046873A9; WO2002059794A9; CA2436594A1; CA2436636A1; WO2002046873A3; US7941785B2

Abstract

アイデンティティインデックス２５０を用いてネットワーク上の情報を管理するためのシステムおよび方法を提供し得る。本発明の一実施形態は、ユーザを定義する情報オブジェクト３５０に１つ以上のユーザを関連付けるように動作するコンピュータ読み出し可能媒体上に格納されたソフトウエアプログラム２４０を含み得る。ソフトウエアプログラム２４０は、各ユーザのための「仮想アイデンティティ」３１２、３１４、３１６を保守し得、「仮想アイデンティティ」３１２、３１４、３１６は、ユーザに関連付けられた情報オブジェクト識別３５０（例えばアカウント）および情報オブジェクト３５０が見出され得るリソースのアイデンティティのリストを含む。本発明の一実施形態では、情報オブジェクト３５０のリストは情報オブジェクトを含み得る。

Description

【０００１】
（発明の技術分野）
本発明は、一般的にシステム管理のシステムおよび方法に関する。より詳細には、本発明は、配信された情報オブジェクトを管理するためのシステムおよび方法に関する。さらにより詳細には、本発明の実施形態は、配信された情報オブジェクトへの参照を含むインデックスを用いて配信された情報データを管理するためのシステムおよび方法に関する。
【０００２】
（発明の背景）
電子データの処理および格納は、現在では、大抵の組織の日常的な動作に対して重要である。ネットワーキング技術の進展と共に、電子データ処理を利用する組織は、処理およびストレージが多くの異機種で相互接続されたコンピュータを介して配信される「企業」コンピュータネットワークにますます依存するようになっている。多くの企業システムでは、組織の人員は、システムを介して複数のリソースへのアクセスを有する。例えば、会社の従業員は、電子メールアカウント、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴアカウント、Ｕｎｉｘ（Ｒ）アカウントを使用し得、企業システム上に格納されたデータをアクセスおよび処理する。さらに組織は、しばしば外部ユーザ（例えば、配信者、ビジネスパートナー、および供給者等）に企業システムに格納されたデータへの制限されたアクセスを付与するアカウントを提供することを望む。内部および外部アカウントを管理することが必要とされた管理オーバーヘッドは、しばしば組織に対して実際に関心のあるデータよりも管理することがより困難になる。これは、システム効率の低下および支援コストの増加を生じ得る。
【０００３】
その結果、組織は、効率的なシステム管理が、利益の中でも、低減された情報技術（「ＩＴ」）コスト、ならびに企業データを設定および管理する場合の増加された効率性を提供し得るため、効率的なシステム管理にますます興味を持つことになる。しかし、現在では、特にレガシーデータを含む企業コンピュータネットワークに効率的なシステム管理を提供することは、非現実的なタスクである。これは、部分的には、多くの組織が、何年も、無数の異なるデータタイプを格納する種々の異なるコンピュータシステムを含むネットワークを開発してきたためである。さらに、企業ネットワークを管理する複雑さに加えて、組織は、しばしばネットワークを介して非一貫性データを格納する。データ非一貫性データのもう一つの例として、会社は、会社人的資源（「ＨＲ」）メインフレームにおける従業員のための１つの家の電話番号を格納しつつ、部門メインフレームに異なる家の電話番号を格納し得る。２つのメインフレームは、異種（例えば異なるハードウエア、オペレーティングシステム、プロトコル、ツール、および／またはアプリケーションを採用する）であり得るため、非一貫性を取り除くために２つのリソース間で同期化することは、困難性を提供し得る。
【０００４】
ほとんどの従来のシステム管理技術は、データを中央化することによってこれらの困難性にアドレスする。プロファイルベースの管理システム、ディレクトリベースの管理システム、およびメタディレクトリは、データストレージを中央化するための種々のアプローチを提供する。図１は、データの中央化に依存する従来技術のシステムの制限を示す。図１は、管理システム１１０を含むコンピュータシステム１００の図である。コンピュータシステム１００は、中央化されたデータベース１１２と、電子メールサーバ１２０（Ｍｉｃｒｏｓｏｆｔｅｘｃｈａｎｇｅサーバ等）、Ｕｎｉｘ（Ｒ）システム１２５、Ｗｉｎｄｏｗ（Ｒ）ＮＴシステム１３０およびメインフレーム１３５を含むリソースとを含む。このリソースは互いに相互接続され、ネットワーク１４５を介して管理システム１１０に接続される。各リソースは、エンティティまたは個人を表すデータアイテムの収集を含み得る。例えば、電子メールサーバ１２０は、電子メールアカウント１５０の収集を含み得、Ｕｎｉｘ（Ｒ）システム１２５は、Ｕｎｉｘ（Ｒ）アカウント１５５の収集を含み得、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴシステム１３０は、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴアカウント１６０の収集を含み得、そしてメインフレーム１３５は、データレコード１６５の収集を含み得る。
【０００５】
データのこれらの収集は、個人またはエンティティの各リソースの「ビュー（ｖｉｅｗ）」を表す。例えば、従業員ＪａｎｅＤｏｅの場合に、電子メールサーバ１２０は、彼女をｊａｎｅｄ（すなわち、彼女の電子メールユーザ名）として参照し得、Ｕｎｉｘ（Ｒ）システム１２５は彼女をＪａｎｅＤ（すなわち、彼女のＵｎｉｘ（Ｒ）アカウントユーザ名）としてまたは彼女のＵｎｉｘ（Ｒ）識別（「ＵＩＤ」）によって参照し得、そして、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴシステム１３０は、ＪａｎｅＤｏｅをＪＡＮＥＤ（すなわち、彼女の、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴアカウントユーザ名）として参照し得る。ＪａｎｅＤｏｅがコンピュータシステム１００上でデータにアクセスすることを可能にするアカウント情報に加えて、ＪａｎｅＤｏｅの部門コード等の情報、タイムキーパ番号、給料のレート、および従業員識別がメインフレーム１３５で格納され得る。これは、ＪａｎｅＤｏｅによって個人的に使用されない情報であり得が、彼女の管理者または他の職員によって、代わりに使用される。従って、メインフレーム１３５は、さらに、彼女の従業員記録に基づいたＪａｎｅＤｏｅのためのアイデンティティを保守し得る。例えば、アイデンティティはＪＡＮＥ＿Ｄの下に格納され得る。
【０００６】
データの中央化に依存する従来技術のシステムの欠点を図示するために、従業員ＪａｎｅＤｏｅが結婚し、姓をＳｍｉｔｈに変更したと仮定する。システム１００上でＪａｎｅＤｏｅの名前を更新する一つの方法は、各システムの更新された情報を別個に入力することである。多数のユーザおよび／または高度に分配されたコンピュータシステム１００を有する組織に対して、これは非実用的である。各リソースにおける別個の情報入力の非効率を改善するために、１つの従来技術のシステムは、中央化されたデータベース１１２（複製されたデータ１７５によって表される）の個人またはエンティティを識別する情報の全てを複製する。従って、電子メールアカウント１５０の収集、Ｕｎｉｘ（Ｒ）アカウント１５５の収集、ＷｉｎｄｏｗＮＴアカウント１６０の収集、およびデータレコード１６５の収集は、典型的には、中央化されたデータベース１１２において複製される。変更がデータに対してなされると、変更は複製されたデータ１７５に入力され得、次いで、リソースのそれぞれにプッシュされ得る。次いで、ＪａｎｅＤｏｅの場合、複製されたデータ１７５は、彼女の名前の変更の説明のために修正され、次いで、複製されたデータは、１つ以上のリソースにプッシュアウトされ得る。ＪａｎｅＤｏｅ等の個人の場合、従って、複製されたデータは彼女のデータの「マスターコピー」を含む。
【０００７】
中央化されたデータベースを有するシステムが管理システム１１０を介して入力されたデータに対するデータの一貫性を保証することを支援し、各リソースにプッシュアウトする一方で、このシステムはいくつかの欠点を有する。１つのこのような制限は、各リソースにおいて変化されたデータ間の非一貫性の分解能を含む。結婚したＪａｎｅＤｏｅの例を続けると、ＪａｎｅＤｏｅが彼女の姓をＳｍｉｔｈに変える場合、彼女の名前はメインフレーム１３５において不注意にもＳｍｙｔｈに変更され得るが、彼女の名前は電子メールサーバ１２０においてＳｍｉｔｈに変更される。リソースからのデータが中央化されたデータベース１１２にコピーされる場合、コンピュータシステム１００上の同一の従業員に対して３つの名前があり得る。すなわち、ＪａｎｅＤｏｅ、ＪａｎｅＳｍｙｔｈ、およびＪａｎｅＳｍｉｔｈである。管理システム１１０は、名前の変更が実際に適切であり、変更の内のどれが適切であるかどうかを決定しなければならない。一旦特定の変更が選択されると、この変更がリソースに配信され、各リソースにおいてなされたローカルな変化（または変化の欠如）を上書きする。従って、例えば、ＪａｎｅＳｍｙｔｈが正しい変更として任意に選択された場合、ＪａｎｅＳｍｙｔｈは、リソースのそれぞれに配信され、正しい名前ＪａｎｅＳｍｉｔｈを上書きする。
【０００８】
さらに、異なるリソースが組織内の異なるグループによって制御される場合、別のリソースよりもあるリソースを好むような決定が、組織内の政策的な緊張（ｐｏｌｉｔｉｃａｌｔｅｎｓｉｏｎ）を生じ得る。この従来技術のシステムのさらなる制限としては、十分大きなコンピュータシステム１００において、リソースのいくつかのサブセットは、接続性の問題または他の技術的問題のため、任意の所与の時間において利用できない。従っていくつかのリソースのみが更新され、ＪａｎｅＤｏｎｅのデータのさらなる非一貫性を生じる。
【０００９】
中央化されたデータベースアプローチをインプリメントするためには、典型的には、従来技術のシステムは、組織のメンバーによって使用されたリソースを識別するように、全体のシステムアドミニストレータまたはマネージャに依存する。しかし、どの組織のリソースメンバが必要とされるかについてのアドミニストレータの観点が典型的には制限され、一般的にアドミニストレータは、どのリソースが部門ごとに基づいて用いられるかについての見解または個人レベルで用いられるリソースについての見解をほとんど有しない。さらに、典型的には、従来技術のシステムは複数の異種のソースからの情報を検索し、マッピングし、関連付け、そしてマージするプロセスを自動化しない。このため、アドミニストレータは、典型的には情報を抽出し、マッピングし、関係付け、マージし、中央化されたデータベース１１２にアップロードするように特別なクエリおよびスクリプトを書き込むことにより、長時間の中央化されたデータベースのインプリメンテーションを行わなければならない。
【００１０】
典型的にはデータの中央化は、管理されたデータの少なくともいくつかのサブセットを複製することを要求する。このタイプのシステムは、中央化されたデータベース１１２に格納されなければならない大量のデータのために、ほとんど調整されず、このシステムは、中央化されたデータベース１１２とリソースとを同期化させる問題をさらに導入する。さらに、これらのシステムは、リソースから中央化されたデータベース１１２に前後して繰り返してコピーされるデータを必要とするために、有意な帯域幅要求はネットワークに応じて課される。さらに別の欠点として、手動での位置付けおよび複数のリソースからの組織データは、典型的には、時間および金額の著しい投資を必要とする。従って、従来技術のシステムは一般的には高価であり効率的ではない。
【００１１】
（発明の要旨）
本発明の実施形態は、以前のシステム管理方法およびシステムに関連付けられた欠点および問題を実質的に低減または除去するネットワーク上の情報を管理するためのシステムおよび方法を含む。より詳細には、本発明の実施形態は、アイデンティティインデックスを用いて、ネットワーク上の配信された情報を管理するためのシステムおよび方法を提供する。
【００１２】
本発明の実施形態は、アイデンティティインデックスを用いて、方法の情報（ｍｅｔｈｏｄｉｎｆｏｒｍａｔｉｏｎ）のためのシステムおよび方法を提供し得る。本発明の一実施形態は、ユーザを定義する情報オブジェクトに１つ以上のユーザを関連付けるように動作可能であるコンピュータ読み出し可能媒体上に格納されたソフトウエアプログラムを含み得る。ソフトウエアプログラムは、各ユーザに対して「仮想アイデンティティ」を保守し得、この仮想アイデンティティは、ユーザおよび情報オブジェクトが見出され得るリソースのアイデンティティに関連付けられた情報オブジェクトのリストを含む。本発明の一実施形態では、情報オブジェクトのリストは、各情報オブジェクトのための情報オブジェクト識別子（すなわち、リソースに対して意味のあるネイティブキーまたは任意の識別子）を含み得る。ソフトウエアプログラムはまた、各識別されたリソースのためのリソース定義を保守し得る。このリソース定義は、ソフトウエアプログラムが対応するリソースに接続するように使用し得る接続パラメータのセットを含み得る。リソース定義および情報オブジェクト識別子に基づいて、本発明の実施形態は、各リソースに接続し得、これらのリソース上の情報オブジェクトを位置付け得る。
【００１３】
本発明の一実施形態では、各リソース定義は、スキーママップによって定義された仮想属性にリソース上に格納された属性（例えば「リソース属性」）を関連付けるスキーママップをさらに含み得る。ソフトウエアプログラムは、スキーママップによって定義された仮想属性に基づいたユーザの複合ビューを作成し得、カスタマイズ可能なグラフィカルユーザインターフェースで複合ビューを表示し得る。
【００１４】
本発明の一実施形態では、情報オブジェクトはユーザアカウントを含み得る。従って、本発明の実施形態は、複数のリソース上に格納されたユーザアカウントをユーザに関連付け得る。ユーザアカウントを定義する属性は、リソーススキーママップに基づいた仮想属性として複合ビューに表され得る。仮想属性が修正される場合、この変更はスキーママップに基づいてリソース属性にプッシュされ得る。従って、リソース属性は、中央化されたデータベースにおいて関連付けられた情報オブジェクトを複製する必要なしで修正され得る。
【００１５】
本発明の実施形態は、データを管理するために必要とされたストレージの量を実質的に低減することによって従来技術のシステムおよび方法を超える利点を提供する。
【００１６】
さらに、本発明の実施形態は管理データに必要とされた帯域幅の量を低減することによる従来のシステムおよび方法を超える利点を提供する。
【００１７】
さらに、本発明の実施形態は、中央化されたデータベースにおける情報オブジェクトを複製しないが、データオブジェクトが常駐するインデックスを作成する。本発明の実施形態は、従来技術のシステムよりもより高度な拡張性を提供し得る。
【００１８】
（発明の詳細な説明）
本発明の好適な実施形態が図面に示され、同様な参照符号は同様かつ対応する部分を示すために使用される。
【００１９】
本発明の実施形態は、アイデンティティインデックスを用いて情報を管理するためのシステムおよび方法を提供し得る。本発明の一実施形態は、ユーザを定義する情報オブジェクトに１つ以上のユーザを関連付けるように動作可能なコンピュータ読み出し可能媒体上に格納されたソフトウエアプログラムを含み得る。ソフトウエアプログラムは、各ユーザのための「仮想アイデンティティ」を保守し得る。仮想アイデンティティは、ユーザおよび情報オブジェクトが見出され得るリソースのアイデンティティに関連付けられた情報オブジェクトのリストを含む。本発明の一実施形態では、情報オブジェクトのリストは、各情報オブジェクトのための情報オブジェクト識別子（すなわち、リソースに対して意味のあるネイティブキーまたは任意の識別子）を含み得る。ソフトウエアプログラムはまた、各識別されたリソースのためのリソース定義を保守し得る。このリソース定義は、ソフトウエアプログラムが対応するリソースに接続するように使用し得る接続パラメータのセットを含み得る。リソース定義および情報オブジェクト識別子に基づいて、本発明の実施形態は、各リソースに接続し得、これらのリソース上の情報オブジェクトを位置付け得る。
【００２０】
本発明の一実施形態では、各リソース定義は、スキーママップによって定義された仮想属性にリソース上に格納された属性（例えば「リソース属性」）を関連付けるスキーママップをさらに含み得る。ソフトウエアプログラムは、スキーママップによって定義された仮想属性に基づいたユーザの複合ビューを作成し得、カスタマイズ可能なグラフィカルユーザインターフェースで複合ビューを表示し得る。
【００２１】
本発明の一実施形態では、情報オブジェクトはユーザアカウントを含み得る。従って、本発明の実施形態は、複数のリソース上に格納されたユーザアカウントをユーザに関連付け得る。ユーザアカウントを定義する属性は、リソーススキーママップに基づいた仮想属性として複合ビューに表され得る。仮想属性が修正される場合、この変更はスキーママップに基づいてリソース属性にプッシュバックされ得る。
【００２２】
この出願の目的のため、用語「リソース」は、その管理または動作に関連付けられた情報オブジェクトを定義するネットワークを介してアクセス可能なシステムまたはアプリケーションを意味し得る。例えば、Ｕｎｉｘ（Ｒ）システムは、典型的には／ｅｔｃ／ｐａｓｓｗｄｆｉｌｅにおけるアカウント（すなわち、情報オブジェクト）を定義するリソースであり得、Ｗｉｎｄｏｗｓ（Ｒ）システムは、ユーザマネージャアプリケーションにおけるユーザアカウントを定義するリソースであり得、そしてＤＢＭＳシステムは、特定の１つ以上のテーブルにおいてユーザアカウントを定義するリソースであり得る。リソースは、特定のコンピュータシステム（配信されるまたは配信されない）、コンピュータシステム上のアプリケーション、あるいは、ネットワーク情報システム（「ＮＩＳ」）等のいくつかのコンピュータシステムを介して配信されたアプリケーションを含み得ることに留意されるべきである。「ユーザ」は、人間、プログラム、またはリソースを使用するコンピュータシステムであり得る。「情報オブジェクト」は単一のエンティティまたはアイデンティティを表し得る１つ以上のデータ部分の集合であり得る。言い換えると、情報オブジェクトは、エンティティ（ユーザ等）のリソースの「ビュー」を表し得る。属性は、情報オブジェクトの少なくとも一部を構成する情報（例えば、名前を有する属性、データタイプ、および０、１以上の値）の単一の部分であり得る。「スキーマ」は、リソース上の情報オブジェクト（データアイテム（属性）のセットを含む）のクラスの構造およびそのクラス間の関係であり得る。このリソースは、各情報オブジェクトを説明するために定義される。「仮想アイデンティティ」は、１つ以上のリソースに格納された１つ以上の情報オブジェクトに基づいたユーザの複合アイデンティティであり得る。
【００２３】
図２は、本発明の一実施形態がインプリメントされ得るシステム２００を示す。システム２００は、複数のリソース（ここで、リソース２１０、リソース２１２、およびリソース２１４で示される）を含み得る。各リソースはコンピュータシステム（分離または配信されたシステムのいずれか）および／またはコンピュータシステム上のアプリケーションを含み得る。システム２００が複数のリソースを含む一方で、本発明は、１つのみのリソースを有するシステムでインプリメントされ得ることが理解されるべきである。システム２００はまた、ネットワーク２２５を介してリソースにアクセスするのに動作可能な管理システム２２０を含み得る。ネットワーク２２５は、ＬＡＮ、ＷＡＮ、グローバルエリアネットワーク（例えば、インターネット、ワイヤレスネットワーク）、または当該分野で公知の任意の他の電子通信ネットワークであり得る。管理システム２２０は、コンピュータプロセッサ２３０、コンピュータ読み出し可能メモリ２３５（例えば、公知のＲＡＭ、ＲＯＭ、コンピュータ読み出し可能な磁気格納デバイスおよび／または他のコンピュータ読み出し可能メモリ）、ならびにコンピュータ読み出し可能メモリ２３５に格納された管理システム２３９を含み得る。管理システム２３９は、システム２００のユーザを情報オブジェクトおよびリソースに関連付けるアイデンティティインデックス２５０を維持するために動作可能なソフトウエアプログラム２４０を含み得る。管理システム２２０が離散システムとして示されるが、管理システム２２０は、１つ以上のリソースとして１つ以上の同じ物理ユニットに配信および／または実現され得ることが理解されるべきである。
【００２４】
各リソースは、関連付けられたリソースの管理または構成に関連した情報オブジェクトを定義し得る。例として、リソース２１０は、情報オブジェクトとして従業員レコード２４２を含むＯｒａｃｌｅデータベースシステムを含み得、リソース２１２は、Ｕｎｉｘ（Ｒ）ユーザアカウント２４４のセットを含むＵｎｉｘ（Ｒ）システムを含み得、そしてリソース２１４は、ＮＴユーザアカウント２４６のセットを含むＷｉｎｄｏｗｓ（Ｒ）ＮＴシステムを含み得る。リソースアカウント（すなわち情報オブジェクト）は、特定のユーザの各リソースの「ビュー」を表す。言い換えると、各リソースアカウント（およびこのアカウントを構成する属性）は、リソースの範囲内のユーザを表し得る。
【００２５】
全てのユーザがシステム２００における全てのリソースへのアクセスを有するとは限らないことに留意するべきである。従って、いくつかのリソースは、いくつかのユーザを定義する（他のものではなく）情報オブジェクトを含み得る。アイデンティティインデックス２５０は、特定のユーザを説明する情報オブジェクトをそのユーザにマッピングする情報を格納し得る。情報オブジェクトからの実際のデータの全てを格納するのではなく、アイデンティティインデックス２５０は、リソースへの接続方法、各情報オブジェクトの検索方法、および情報オブジェクトの標準的な表示へのマッピング方法に関する情報を格納し得る。アイデンティティインデックス２５０に基づいて、ソフトウエアプログラム２４０は、各リソースからのデータアイテムを検索して、中央化されたデータベースにおいてデータアイテムを複製することなく（例えば不揮発性メモリにおけるデータアイテムのための値を格納することなく）基本フォーマット（ｃａｎｏｎｉｃａｌｆｏｒｍａｔ）でデータアイテムを示し得る。本発明は、人間のユーザによってアクセスされた種々のフォーマットのコンピュータアカウントを管理する点において主に説明されるが、本発明の教示は、任意のタイプの情報オブジェクトをユーザに関連付けるように等しく利用可能である。従って、例えば、本発明の実施形態は、特定のネットワークエレメント等に種々のサーバ上のルーティングテーブルを関連付けるように構成される。
【００２６】
図３は、本発明の一実施形態による情報オブジェクトを管理するための管理システム２３９の概略図である。管理システム２３９は、ユーザおよびリソースアカウントを管理するためのソフトウエアプログラム２４０と、ユーザをリソースアカウントに関連付けるアイデンティティンデックス２５０と、リソース属性を仮想属性に関連付けるためのスキーママップ（例えば以下に説明するようにスキーママップ３７０、スキーママップ３７２、およびスキーママップ３７４）と、１つ以上のリソースに従ってユーザの「ビュー」を提示するための複合ビュー３１９とを含み得る。
【００２７】
ソフトウエアプログラム２４０は、Ｏｒａｃｌｅデータベースシステム２１０、Ｕｎｉｘ（Ｒ）システム２１２、およびＮＴシステム２１４と通信するようにリソースアダプタモジュール３２５を呼び出し得る。この説明されたリソースアダプタモジュールは、例示のみによって提供されることに留意すべきである。典型的には、１つのリソースアダプタモジュール３２５は、特定のリソースタイプ（例えば、１つのリソースアダプタ３２５は、全てのＵｎｉｘ（Ｒ）システムと通信するように呼び出され得る）と通信するように動作可能であるが、図３に示されるように、別のリソースアダプタモジュール３２５はまた、各リソースのために使用され得る。当業者に理解されるように、リソースアダプタモジュール３２５はまた、任意のリソースタイプと通信するようにカスタムプログラムされ得る。
【００２８】
図３に示された実施形態では、アイデンティティンデックス２５０は、複数の仮想アイデンティティ（例えば、仮想アイデンティティ３１２、３１４、および３１６）を含み得る。各仮想アイデンティティ３１２、３１４、および３１６は、仮想ユーザ名３４５および仮想アイデンティティに関連付けられた情報オブジェクト３５０のリストを含み得る。本発明の一実施形態では、仮想ユーザ名３４５は、関連付けられた仮想アイデンティティを位置付け、アイデンティティインデックス２５０から取り出すためのネイティブキーとして使用され得る。関連付けられた情報オブジェクト３５０のリストは、１つ以上のエントリ（エントリ３５１等）を含み、情報オブジェクトをリソースに関連付ける。各エントリは、関連付けられた情報オブジェクトが位置付けられたリソースのための情報オブジェクトネイティブキー（例えばネイティブキー３５２）およびリソース名（例えばリソース名３５３）を含み得る。リソース名は、特定のリソースを参照するために使用された任意の識別子であり得ることが留意されるべきである。さらに、ネイティブキーを格納するのではなく、アイデンティティインデックス２５０は、ソフトウエアプログラム２４０が、情報オブジェクトが位置付けられるリソースに対して意味のあるネイティブキーまたは識別子に変換またはマッピングし得る任意の情報オブジェクト識別子を格納し得る。各仮想アイデンティティはまた、組織が仮想アイデンティティに格納されることを望む任意のさらなる属性を含み得る（例えば、組織がユーザ名によって仮想アイデンティティを検索する能力を望む場合、組織は、「名」、「姓」、または「氏名」等の属性を格納することを望み得る）。
【００２９】
さらに、アイデンティティインデックス２５０は、リソース定義３６０、リソース定義３６２、およびリソース定義３６４等のリソース定義を含み得る。各リソース定義は、リソース名３６６および接続情報３６８のセットを含み得る。接続情報３６８の各セットは、対応するリソースに接続するようにソフトウエアプログラム２４０によって使用された接続パラメータを含み得る（例えばホスト名、ドメイン、リソースユーザ名、リソースパスワード、ポート等）。例えば、リソース定義３６０は、Ｏｒａｃｌｅシステム２１０に接続するようにソフトウエアプログラム２４０のための十分な情報を含み得、リソース定義３６２は、Ｕｎｉｘ（Ｒ）システム２１２に接続するようにソフトウエアプログラム２４０のための十分な情報を含み得、そしてリソース定義３６４は、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴシステム２１４に接続するようにソフトウエアプログラム２４０のための十分な情報を含み得る。従って、リソース定義３６０は、以下の情報を含み得る。
【００３０】
【数１】

同様に、リソース定義３６２は、以下の情報を含み得る。
【００３１】
【数２】

リソース定義３６４は以下を含み得る。
【００３２】
【数３】

上記で提供されたリソース定義は例示的のみであり、リソースに接続するために使用された任意の情報が使用され得ることが理解されるべきである。例えば、Ｕｎｉｘ（Ｒ）システム２１２に対して、ソフトウエアプログラム２４０は、ｔｅｌｎｅｔ（例えばＳＳＨ）ではなく異なるプロトコルを用いて接続し得、「ｒｏｏｔ」ではなく異なるユーザとして接続し得る。アイデンティティインデックス２５０に含まれた接続情報は、システム２００上で利用可能なリソースに依存して変更し得、ソフトウエアプログラム２４０が有効にされるリソースへのアクセスの量が有効にされる。例えば、管理システム２３９が組織制御システム２００以外のエントリによってインプリメントされる場合、組織はシステム２００のリソースへのアクセスを制限するように望み得る。ユーザ名およびリソース定義において提供されたパスワードが個々のアカウントに接続するように使用されたユーザ名およびパスワードを含まないかもしれないことに留意すべきである。
【００３３】
アイデンティティインデックス２５０の一実施形態の例として、ユーザ「ＪａｎｅＤｏｅ」が、Ｏｒａｃｌｅデータベースシステム２１０上のＯｒａｃｌｅデータベースアカウント３４２、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴシステム２１４上のＷｉｎｄｏｗｓ（Ｒ）ＮＴアカウント３４６、およびＵｎｉｘ（Ｒ）システム２１２上のＵｎｉｘ（Ｒ）アカウント３４４を有すると想定する。さらに、Ｏｒａｃｌｅデータベースアカウント３４２は、アカウント名「ＪＡＮＥ＿Ｄ」を有し、Ｕｎｉｘ（Ｒ）アカウント３４４は、アカウント名「ｊａｎｅｄ」を有し、そしてＷｉｎｄｏｗｓ（Ｒ）ＮＴアカウント３４６は、アカウント名「ｊａｎｅＤ」を有すると想定する。このような場合、図３に示されるような仮想ユーザ名３４５は、「ｊａｎｅＤ」または任意の他の識別子であり得る。さらに、情報オブジェクトリスト３５０は、ＪａｎｅＤｏｅのユーザアカウントのためのネイティブキーおよび各アカウントが見出され得るリソースのための関連付けられたリソース名のリストを含み得る。従って、例えばエントリ３５１は、ネイティブキー３５２として「ｊａｎｅｄ」およびリソース名３５３として「Ｒｅｓｏ０２」の値を含み得る。リソース名３５３は、リソース定義３６２のリソース名３６６に対応するため、ソフトウエアプログラム２４０は、ＪａｎｅＤｏｅのＵｎｉｘ（Ｒ）アカウント３４４を位置付けるためにリソース定義３６２に基づいたＵｎｉｘ（Ｒ）システム２１２に接続させ得る。さらに、エントリ３５１は、ネイティブキー「ｊａｎｅｄ」を含むため、ソフトウエアプログラム２４０は、Ｕｎｉｘ（Ｒ）システム２１２上のＪａｎｅＤｏｅのＵｎｉｘ（Ｒ）アカウント３４４を位置付けることができる。従って、当業者に理解されるように、アイデンティティインデックス２５０は、情報オブジェクト（例えばユーザアカウント）をユーザおよびリソースに関連付け得、その結果、情報オブジェクトは、中央化されたデータベースにおける情報オブジェクトを複製することなく位置付けられ得る。図３は、ネイティブキー３５２および連続して格納されたリソース名３５３を表すが、実際にはエントリ３５１は配信され得ることに留意されるべきである。例えば、ネイティブキー３５２は、リレーショナルデータベースのテーブルの１つのロウに格納され得る一方で、同じエントリ３５０のリソース名３５３は、異なるロウおよび／または異なるテーブルに格納され得る。
【００３４】
さらに、各リソース定義はスキーママップを含み得る。例えば、リソース定義３６０はスキーママップ３７０を含み得（図４に示された実施形態）、リソース定義３６２はスキーママップ３７２を含み得、そしてリソース定義３６４はスキーママップ３７４を含み得る。スキーママップは、リソース専用情報オブジェクト（例えばアカウント）属性をスキーママップにおいて定義された仮想属性に関連付け得る。この態様では、スキーママップは、ソフトウエアプログラム２４０が共通のフォーマットで異なるリソースからの属性値（すなわちデータアイテム）を表示することを可能にする。スキーママップは、リソース属性の値を操作するように使用されて、対応する仮想属性のための値を誘導し得ることに留意されるべきである。
【００３５】
例えば、異なるリソースからの属性は、同じ仮想属性にマッピングされ得る。従って、例えば、Ｏｒａｃｌｅデータベースシステム２１０が「ｐｈｏｎｅ」と命名された属性を含み、Ｕｎｉｘ（Ｒ）システム２１２が「ｐｈ＿ｎｕｍ」と命名された属性を含んだ場合、スキーママップ３７０および３７２は、それぞれ「ＰｈｏｎｅＮｕｍｂｅｒ」と命名された仮想属性にこれらの属性をマッピングし得る。本発明の一実施形態では、仮想属性「ＰｈｏｎｅＮｕｍｂｅｒ」のための値は、アイデンティティインデックス２５０に格納される必要がない。その代わり、仮想アイデンティティがアクセスされる場合、以下により詳細に説明されるように、ソフトウエアプログラム２４０は、属性「ｐｈ＿ｎｕｍ」および「ｐｈｏｎｅ」にアクセスし得、値をＲＡＭに格納し、そして複合ビュー３１９における「ＰｈｏｎｅＮｕｍｂｅｒ」の下に値を表示し得る。
【００３６】
複合ビュー３１９は、スキーママップによって定義されたようなユーザのアカウントの「ビュー」を含み得る。１つ以上のスキーママップに基づいて、複合ビュー３１９は、ユーザのためのリソース専用属性から誘導された仮想属性値を含み、グラフィカルユーザインターフェースを介してアドミニストレータおよびユーザに提示され得る。仮想アイデンティティがアクセスされる場合、ソフトウエアプログラム２４０は、適切なリソースアダプタモジュール３２５を呼び出し、仮想アイデンティティに関連付けられたリソースと通信し、そして各情報オブジェクトのために提供されたネイティブキーに基づいた情報オブジェクト（例えばアカウント）を配置させ得る。ソフトウエアプログラム２４０は、リソース属性のセットを取り出し得、リソース属性を仮想属性のセットにマッピングし得る（すなわち、「仮想情報オブジェクト」を作成し、複合ビュー３１９で仮想属性を表示する）。本発明の一実施形態では、仮想属性が揮発性メモリ（例えばＲＡＭ）に格納される。言い換えると、ソフトウエアプログラム２４０は、ユーザの仮想アイデンティティを介してユーザに関連付けられた情報オブジェクトに基づいてユーザの「インメモリ」表示（「仮想情報オブジェクト」）を提示し得る。本発明の一実施形態では、ソフトウエアプログラム２４０は、グラフィカルユーザインターフェースに複合ビュー３１９を表示し得る。実際のディスプレイは、カスタム可能な形態によって支配され得る。
【００３７】
上記のように、スキーママップは、１より多くのリソースからのリソース属性を同じ仮想属性に関連付け得る。本発明の一実施形態では、２つ以上のリソース属性が、値が異なる同じ仮想属性にマッピングされた場合、全ての値が複合ビュー３１９の一部として表示され得、１つの値がディスプレイのために選択され得、またはリソース属性が共通の値に強制され得る。仮想アイデンティティへの変更がなされた場合（例えば、グラフィカルユーザインターフェースにおける仮想属性値の操作によって）、この変更は、１つ以上のスキーママップによって仮想属性にマッピングされた各リソース属性にプッシュアウトされ得る。従って、リソースを横切るデータは中央化されたデータベースにおいて属性を持続的に複製することなく（すなわち中央化されたデータベースにおけるリソース属性値のコピーを格納することなく）同期化され得る。
【００３８】
上記議論において開示され説明されたように、アイデンティティインデックス２５０は、情報オブジェクトおよびその情報オブジェクトが位置付けられるリソースにユーザを関連付け得る。本発明の一実施形態では、アイデンティティインデックス２５０は、システム２００上に格納された情報オブジェクトに関する「メタ情報」を格納し得る（例えばシステム２００上の情報オブジェクトを位置付ける方法に関する情報を格納し得る）。従って、アイデンティティインデックス２５０は、いくつかの状態情報（例えばシステム２００上の情報オブジェクトの位置）を保守し得るが、アイデンティティインデックスが情報オブジェクトの実際のデータを持続的に格納することを避け得る点において「無状態（ｓｔａｔｅｌｅｓｓ）」のままである。従って、本発明の実施形態は、システム２００において配信された情報オブジェクトの「準無状態（ｑｕａｓｉ−ｓｔａｔｅｌｅｓｓ）」管理を提供し得る。情報オブジェクトがアイデンティティインデックス２５０のいくつかの実施形態において複製されないために、本発明の実施形態は、高度に拡張可能であり、本発明をインプリメントするための格納要求は、各情報オブジェクトに関連付けられたデータ量によって大幅に影響されない。さらに、仮想アイデンティティへの変化が、情報オブジェクトごとのベース（従来技術のシステムに関して）ではなく、属性ごとのベースに関してリソースにプッシュアウトされ得るため、本発明の実施形態は、ネットワーク２２５のための帯域幅要求を低減させる。アイデンティティインデックス２５０は、例えば、グラフィカルユーザインターフェースを介してアイデンティティインデックス２５０に含まれた情報を入力するシステムアドミニストレータによって手動で構築され得るか、またはアイデンティティインデックス２５０が、ソフトウエアがインプリメントされた発見プロセスを介して構築され得ることに留意されるべきである。アイデンティティインデックス２５０を構築するために使用され得る情報を発見するためのシステムおよび方法の一実施形態は、２００１年１２月６日に出願された、「ＳｙｓｔｅｍａｎｄＭｅｔｈｏｄｏｆＤｉｓｃｏｖｅｒｉｎｇＩｎｆｏｒｍａｔｉｏｎ」と題された米国特許出願第＿＿号に開示され、説明される。
【００３９】
公知の任意のデータ格納方式がアイデンティティインデックス２５０を保守するために使用され得ることに留意されるべきである。例によって、限定されないが、本発明の実施形態によって利用され得るデータ格納方式は、シーケンシャルファイル、インデックス付けされたファイル、ＬＤＡＰディレクトリ、およびリレーショナルデータベースを含む。シーケンシャルファイルは、一般的にインプリメントするのに安価であり、種々のシステムと共に使用され得る。しかし、アイデンティティインデックス２５０のサイズが増加すると共に、シーケンシャルファイルのためのアクセス時間が急速に増大する。なぜなら、このようなファイルは所望のデータの部分を見つけるために、通常スキャンまたは構文解析されなければならないためである。インデックス付けされたファイルはまた、比較的安価であり、容易に拡張可能である。しかし、インデックス付けされたファイルは、典型的には、単一のキーを介するアクセスを可能にする。ＬＤＡＰディレクトリサービスは比較的安価であり、ますます利用可能になりつつある。ＬＤＡＰプロトコルは、書き込みよりも読み出しを最適化する。それにより、データを頻繁に読み出すことに役立つが、更新頻度が低い。ＬＤＡＰディレクトリは、大量のデータを処理するように拡張し得るが、アクセス時間はほとんど拡張されない。当業者に理解されるようにリレーショナルデータベース管理システムは、高度に拡張可能であり、アクセス、トランザクション、バックアップ、および復元を最適化するための洗練された技術を使用する。
【００４０】
図４は、スキーママップ（例えば図３のスキーママップ３７０）の一実施形態を示す。特定のリソースのためのスキーママップ（スキーママップ３７０等）は、仮想属性４１０、リソース属性４２０、および属性タイプ４３０を含み得る。図４の例では、１つの仮想属性４１０は、「ＰｈｏｎｅＮｕｍｂｅｒ」であるが対応するリソース属性４２０は「ｐｈｏｎｅ」である。ソフトウエアプログラム２４０が、ユーザのリソースアカウントに関連付けられたリソース専用属性「ｐｈｏｎｅ」を読み出す場合、ソフトウエアプログラム２４０は、「ｐｈｏｎｅ」のための値を仮想属性「ＰｈｏｎｅＮｕｍｂｅｒ」の値にマッピングし得る。従って、「ｐｈｏｎｅ」の値が、「ＰｈｏｎｅＮｕｍｂｅｒ」のための値として複合ビュー３１９に含まれ得る。「ＰｈｏｎｅＮｕｍｂｅｒ」のための値が不揮発性メモリに保存されるのではなく（例えばアイデンティティインデックス２５０と共に）、仮想アイデンティティが操作されつつ（例えば観察される）、その代わりにＲＡＭに保存されるのみであり得ることに留意されるべきである。
【００４１】
スキーママップ３７０では、当業者に理解されるように、属性タイプ４３０は、「ストリング」および「ブーリアン」、あるいは他の可能な属性タイプを含み得る。属性タイプ４３０のフィールドが使用されて、属性の異なるタイプ同士を互いにマッピングし得る。本発明のいくつかの実施形態では、全ての属性が仮想属性にマッピングされるとは限らないことに留意されるべきである。これらのマッピングされない属性は、典型的には複合ビュー３１９、アイデンティティインデックス２５０、またはスキーママップ３７０において現れない。例えば、本発明の実施形態をインプリメントする組織が、特定の属性が発見可能であることを望まない場合（例えば従業員の社会保障番号等）、これが発生し得る。
【００４２】
リソースタイプの全ての例が同じである場合、スキーママップがリソースごとのベースではなくリソースタイプに対して規定され得ることにさらに留意されるべきである。例えば、このようにＮＴシステムのための１つのスキーママップ、Ｕｎｉｘ（Ｒ）のための１つのスキーママップ、ＬＤＡＰのための１つのスキーママップ等である。例えば、組織が異なるシステム上のＮＴシステム「記述」フィールドにおける異なるタイプのデータを格納し得る。従って、各リソースは固有のスキーママップを必要とし得る。
【００４３】
本発明の実施形態は、以前の情報を管理するシステムおよび方法に関連付けられた欠点または問題を実質的に低減または除去するネットワーク上の情報を管理するためのシステムおよび方法を含む。より詳細には、本発明の実施形態は、アイデンティティンデックスを用いて、情報をトラッキングするためのシステムおよび方法を提供し得る。本発明の一実施形態は、ユーザを定義する情報オブジェクトに１つ以上のユーザを関連付けるように動作可能であるコンピュータ読み出し可能媒体上に格納されたソフトウエアプログラムを含み得る。ソフトウエアプログラムは、各ユーザに対して「仮想アイデンティティ」を保守し得、この仮想アイデンティティは、ユーザに関連付けられた情報オブジェクト（例えばアカウント）のリストを含む。さらに各情報オブジェクトは、情報オブジェクトが位置付けられるリソースに関連付けられ得る。本発明の一実施形態では、情報オブジェクトのリストは、各情報オブジェクトのための情報オブジェクト識別子（すなわち、情報オブジェクトが位置付けられるリソースに対して意味のあるネイティブキーまたは任意の識別子）を含み得る。ソフトウエアプログラムはまた、各識別されたリソースのためのリソース定義を保守し得る。このリソース定義は、ソフトウエアプログラムが対応するリソースに接続するように使用され得る接続パラメータのセットを含み得る。リソース定義および情報オブジェクト識別子（例えば情報オブジェクトのためのネイティブキー）に基づいて、本発明の実施形態は、各リソースに接続し得、これらのリソース上の情報オブジェクトを位置付け得る。
【００４４】
本発明の一実施形態では、各リソース定義は、スキーママップによって定義された仮想属性にリソース上に格納された属性（例えば「リソース属性」）を相関させるスキーママップをさらに含み得る。ソフトウエアプログラムは、スキーママップによって定義された仮想属性に基づいたユーザの複合ビューを作成し得、カスタマイズ可能なグラフィカルユーザインターフェースで複合ビューを表示させ得る。
【００４５】
本発明の一実施形態では、情報オブジェクトはユーザアカウントを含み得る。従って、本発明の実施形態は、複数のリソース上に格納されたユーザアカウントをユーザに関連付け得る。ユーザアカウントを定義する属性は、リソーススキーママップに基づいた仮想属性として複合ビューに表され得る。仮想属性が修正される場合、この変更はスキーママップに基づいてリソース属性にプッシュバックされ得る。
【００４６】
本発明は、例示の実施形態を参照しながら本明細書中で詳細に説明されてきたが、その説明は例示のみによっておよび限定的な意味で構成されないことが理解されるべきである。従って、本発明の実施形態および本発明のさらなる実施形態の詳細の多くの変更がこの説明を参照する当業者に明らかになり、当業者によって作成され得ることがさらに理解されるべきである。全てのこのような変更およびさらなる実施形態が上掲の特許請求の範囲として本発明の範囲内にあることが企図される。
【図面の簡単な説明】
【図１】
図１は、データが中央化されたデータベースにおいて複製されるシステム管理の従来技術のシステムを示す。
【図２】
図２は、本発明の教示がインプリメントされ得るコンピュータシステムの一実施形態を示す。
【図３】
図３は、本発明の一実施形態によるアカウント管理のシステムを示す。
【図４】
図４は、本発明の一実施形態によるスキーママップを示す。

Claims

情報を管理するためのシステムであって、
アイデンティティインデックスを保守するために動作可能なコンピュータ読み出し可能媒体上に格納されたソフトウェアプログラムであって、該アイデンティティインデックスは、
仮想アイデンティティであって、
情報オブジェクトに対応する情報オブジェクト識別子と、
該情報オブジェクトが位置付けられるリソースを識別するリソース名であって、該情報オブジェクト識別子に関連付けられる、リソース名と、
を含む、仮想アイデンティティと、
該命名されたリソースに対応するリソース定義であって、接続情報のセットをさらに含む、リソース定義と
を含む、ソフトウェアプログラムを含む、システム。
前記リソース定義は、スキーママップをさらに含む、請求項１に記載のシステム。
前記スキーママップは、前記リソースからのリソース属性を該スキーママップによって定義された仮想属性にマッピングする、請求項２に記載のシステム。
前記仮想属性のための仮想属性値がＲＡＭに格納される、請求項３に記載のシステム。
前記仮想属性のための仮想属性値が前記アイデンティティインデックスに格納される、請求項３に記載のシステム。
前記接続情報のセットは、ホスト名、ポート、リソースユーザ名、リソースパスワード、またはリソースタイプの内の１つから選択された接続パラメータを含む、請求項１に記載のシステム。
前記仮想アイデンティティはユーザに対応する、請求項１に記載のシステム。
前記情報オブジェクトはユーザアカウントを含む、請求項１に記載のシステム。
前記情報オブジェクト識別子はアカウント名を含む、請求項８に記載のシステム。
前記リソース定義は、スキーママップをさらに含む、請求項８に記載のシステム。
前記スキーママップは、前記リソースからのリソース属性を該スキーママップによって定義された仮想属性にマッピングする、請求項１０に記載のシステム。
前記仮想属性のための仮想属性値がＲＡＭに保守される、請求項１１に記載のシステム。
前記仮想属性のための仮想属性値がアイデンティティインデックスに保守される、請求項１１に記載のシステム。
前記接続情報のセットは、ホスト名、ポート、リソースユーザ名、リソースパスワード、またはリソースタイプの内の１つから選択された接続パラメータを含む、請求項８に記載のシステム。
前記リソースは、Ｕｎｉｘ（Ｒ）システム、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴシステム、Ｏｒａｃｌｅデータベースシステム、または電子メールサーバの内の１つである、請求項８に記載のシステム。
前記ソフトウエアプログラムは、前記リソース定義に基づいて前記リソースに接続されるように動作可能である、請求項１に記載のシステム。
前記リソース定義はスキーママップをさらに含み、前記ソフトウエアプログラムは、該スキーママップに基づいて該仮想アイデンティティの複合ビューを作成するように動作可能である、請求項１に記載のシステム。
前記ソフトウエアプログラムは、グラフィカルユーザインターフェースに前記複合ビューの表示を提示するように動作可能である、請求項１７に記載のシステム。
前記グラフィカルユーザインターフェースは、カスタマイズ可能である、請求項１８に記載のシステム。
情報を管理するためのシステムであって、
アイデンティティインデックスを保守するように動作可能なコンピュータ読み出し可能な媒体上に格納されたソフトウェアプログラムであって、該アイデンティティインデックスは、
仮想識別子のセットであって、各仮想識別子はユーザに対応し、各仮想識別子は、さらに、
情報オブジェクト識別子のセットであって、各識別オブジェクト識別子は、情報オブジェクトに対応する、情報オブジェクト識別子のセットと、
リソース名のセットであって、各リソース名は、情報オブジェクト識別子と関連付けられ、各リソース名は、関連付けられた情報オブジェクト識別子に対応する該情報オブジェクトが位置付けられたリソースに対応する、リソース名のセットと
を含む、仮想識別子のセットと、
各命名されたリソースのためのリソース定義を含むリソース定義のセットであって、各リソース定義は、該対応する命名されたリソースのための接続情報を含む、リソース定義のセットと
を含む、ソフトウェアプログラムを含む、システム。
前記各リソース定義は、スキーママップをさらに含む、請求項２０に記載のシステム。
前記各情報オブジェクトは、ユーザアカウントを含む、請求項２０に記載のシステム。
前記各情報オブジェクト識別子はアカウント名を含む、請求項２２に記載のシステム。
前記各リソース定義は、スキーママップをさらに含む、請求項２３に記載のシステム。
前記各スキーママップは、リソース属性を仮想属性にマッピングする、請求項２４に記載のシステム。
情報を管理する方法であって、
ユーザを定義する情報オブジェクトのセットに対応する情報オブジェクト識別子のセットを格納するステップと、
各情報オブジェクト識別子に少なくとも１つのリソース定義のセットを関連付けるステップであって、各リソース定義は、該関連付けられた情報オブジェクト識別子に対応する該情報オブジェクトが位置付けられるリソースの少なくとも１つのセットに対応し、各リソース定義は、該対応するリソースのための接続情報のセットを含む、情報を管理する方法。
前記情報オブジェクト識別子のセットからの各情報オブジェクト識別子は、該対応する情報オブジェクトのためのネイティブキーを含む、請求項２６に記載の方法。
前記ネイティブキーは、アカウント名を含む、請求項２７に記載の方法。
リソース定義のセットの内の少なくとも１つを各情報オブジェクト識別子に関連付けるステップは、少なくとも１つのリソース名を各情報オブジェクト識別子に関連付けるステップをさらに含む、請求項２６に記載の方法。
前記各情報オブジェクトは、ユーザアカウントを含む、請求項２６に記載の方法。
前記各リソース定義は、スキーママップをさらに含む、請求項２６に記載の方法。
前記各スキーママップは、リソース属性を仮想属性にマッピングする、請求項３１に記載の方法。
各リソース定義からの前記スキーママップに基づいてユーザの複合ビューを生成するステップをさらに含む、請求項３１に記載の方法。