(57)【要約】【課題】　異種のデータ・ソースからのエントリを管理する双方向メタディレクトリ・エージェントを提供する。【解決手段】本発明のメタディレクトリ・エージェントは、データ・ソース・コンバータ層と、　許容されない変更をブロックするためのフィルタ及びルール層と、　属性名のローカル・セットからメタディレクトリ属性名のセットに及びその逆に変更コマンドにおける属性を変換し、エージェント内部共通フォーマット及びディレクトリ変更プロトコルの間で変更コマンドを変換するためのマッピング層と、　カスタム・メタディレクトリ・エージェント機能をインプリメントするための拡張可能ユーザ・カスタマイズ層と、　前記変更コマンドを前記ディレクトリ変更プロトコルで送信及び受信するためのメタディレクトリ・インターフェースと、　を含む。【選択図】　図５
2004127273.tif 000002
【特許請求の範囲】
【請求項１】
　データ・ソース特有のプロトコル及びエージェント内部共通フォーマットの間で変更コマンドを変換するためのデータ・ソース・コンバータ層と、
　前記データ・ソースからメタディレクトリにエクスポートされることを許容されない変更及び外部エンティティから前記データ・ソースにインプリメントされることを許容されない変更をブロックするためのフィルタ及びルール層と、
　属性名のローカル・セットからメタディレクトリ属性名のセットに及びその逆に変更コマンドにおける属性を変換し、前記エージェント内部共通フォーマット及びディレクトリ変更プロトコルの間で変更コマンドを変換するためのマッピング層と、
　カスタム・メタディレクトリ・エージェント機能をインプリメントするためのユーザ・カスタマイズ層と、
　前記変更コマンドを前記ディレクトリ変更プロトコルで送信及び受信するためのメタディレクトリ・インターフェースと、
　を含む、双方向メタディレクトリ・エージェント。
【請求項２】
　前記マッピング層が、変更コマンドを前記エージェント内部共通フォーマット及びライトウェート・ディレクトリ・アクセス・プロトコルの間で変換するように構成される、請求項１に記載の双方向メタディレクトリ・エージェント。
【請求項３】
　前記メタディレクトリ・インターフェースがセキュア・ソケット層通信インターフェースを含む、請求項１に記載の双方向メタディレクトリ・エージェント。
【請求項４】
　前記ユーザ・カスタマイズ層が１つ又は複数のプラグイン機能を含む、請求項１に記載の双方向メタディレクトリ・エージェント。
【請求項５】
　前記ユーザ・カスタマイズ層がポータル・サーバ通信機能を含む、請求項１に記載の双方向メタディレクトリ・エージェント。
【請求項６】
　前記ポータル・サーバ通信機能がプラグイン機能を含む、請求項５に記載の双方向メタディレクトリ・エージェント。
【請求項７】
　前記データ・コンバータ層が、クライアント・システムとメタディレクトリ・ジョイナ、メタディレクトリ・データ・ソース、及びポータル・サーバのグループから選択されたシステムとの間で通信を行うためのクライアント・インターフェースを含む、請求項１に記載の双方向メタディレクトリ・エージェント。
【請求項８】
　前記クライアント・インターフェースがアプリケーション・プログラム・バックエンドを含む、請求項７に記載の双方向メタディレクトリ・エージェント。
【請求項９】
　前記ユーザ・カスタマイズ層が、ポータル・サーバから、クライアント・デバイス、他のポータル・サーバ、メタディレクトリ・ジョイナ、及びメタディレクトリ・データ・ソースのグループから選択されたシステムに変更コマンドをプッシュする変更通知プッシュ機能を含む、請求項１に記載の双方向メタディレクトリ・エージェント。
【請求項１０】
　前記ユーザ・カスタマイズ層が、ユーザの希望に従って変更コマンド・ブロッキングを更に制限するためのパーソナライゼーション・ルール・エンジンを含む、請求項１に記載の双方向メタディレクトリ・エージェント。
【請求項１１】
　前記ユーザ・カスタマイズ層が前にクライアント・デバイスに送られた変更及び更新を後で処理するための後処理機能を含む、請求項１に記載の双方向メタディレクトリ・エージェント。
【請求項１２】
　前記ユーザ・カスタマイズ層がセキュリティ機能を含む、請求項１に記載の双方向メタディレクトリ・エージェント。
【請求項１３】
　前記セキュリティ機能がユーザ・アクセス認可検証プロセスを含む、請求項１２に記載の双方向メタディレクトリ・エージェント。
【請求項１４】
　前記セキュリティ機能が変更リクエスタ認可プロセスを含む、請求項１２に記載の双方向メタディレクトリ・エージェント。
【請求項１５】
　前記変更リクエスタ認可プロセスがディジタル署名ベリファイヤを含む、請求項１４に記載の双方向メタディレクトリ・エージェント。
【請求項１６】
　前記セキュリティ機能がデータ保全性保証機能を含む、請求項１２に記載の双方向メタディレクトリ・エージェント。
【請求項１７】
　前記セキュリティ機能がピア・ツー・ピア通信インターフェースを含む、請求項１２に記載の双方向メタディレクトリ・エージェント。
【請求項１８】
　双方向メタディレクトリ・エージェントによって実行される方法であって、
データ・ソース特有のプロトコル及びエージェント内部共通フォーマットの間で変更コマンドを変換するステップと、
　前記メタディレクトリ・エージェントによって、変更コマンドがローカル・データ・ソースから送られること及び変更コマンドが前記ローカル・データ・ソースにおいてインプリメントされることを許容及びブロックする条件を定義する第１セットのルールに従って変更コマンドをフィルタ及びブロックするステップと、
　前記変更コマンドにおける属性を属性名のローカル・セットのからメタディレクトリ属性名のセットに及びその逆にマッピングするステップと、
　変更コマンドを前記エージェント内部共通フォーマットからディレクトリ変更プロトコルに及びその逆に変換するステップと、
　１つ以上のカスタム・メタディレクトリ・エージェント機能を実行するステップと、
　前記変更コマンドを前記メタディレクトリ・エージェントに及び前記メタディレクトリ・エージェントから前記ディレクトリ変更プロトコルで送信及び受信するステップと、
　を含む方法。
【請求項１９】
　前記マッピングするステップが、変更コマンドを前記エージェント内部共通フォーマットからライトウェート・ディレクトリ・アクセス・プロトコルに変換することを含む、請求項１８に記載の方法。
【請求項２０】
　前記変更コマンドを送信及び受信するステップが、セキュア・ソケット層プロトコルを使用してコミュニケーションを行うことを含む、請求項１８に記載の方法。
【請求項２１】
　前記カスタム・メタディレクトリ・エージェント機能を実行するステップが１つ以上のプラグイン機能を実行することを含む、請求項１８に記載の方法。
【請求項２２】
前記カスタム・メタディレクトリ・エージェント機能を実行するステップがポータル・サーバとのコミュニケーションを行うことを含む、請求項１８に記載の方法。
【請求項２３】
　前記ポータル・サーバとのコミュニケーションがプラグイン機能を実行すること含む、請求項２２に記載の方法。
【請求項２４】
　前記変更コマンドを前記エージェント内部共通フォーマットからディレクトリ変更プロトコルに及びその逆に変換するステップが、クライアント・デバイスとメタディレクトリ・ジョイナ、メタディレクトリ・データ・ソース、及びポータル・サーバのグループから選択されたシステムとの間でコミュニケーションを行うためのクライアント・インターフェースを提供することを含む、請求項１８に記載の方法。
【請求項２５】
　前記クライアント・インターフェースがアプリケーション・プログラム・バックエンドを提供する、請求項２４に記載の方法。
【請求項２６】
　前記カスタム・メタディレクトリ・エージェント機能の実行が、ポータル・サーバから、クライアント・デバイス、他のポータル・サーバ、メタディレクトリ・ジョイナ、及びメタディレクトリ・データ・ソースのグループから選択されたシステムに変更コマンドをプッシュすることを含む、請求項１８に記載の方法。
【請求項２７】
　前記カスタム・メタディレクトリ・エージェント機能を実行するステップが、ユーザの希望に従って変更コマンド・ブロッキングを更に制限するためのパーソナライゼーション・ルール・エンジンを提供することを含む、請求項１８に記載の方法。
【請求項２８】
　前記カスタム・メタディレクトリ・エージェント機能を実行するステップが、前にクライアント・デバイスに送られた変更及び更新を後処理することを含む、請求項１８に記載の方法。
【請求項２９】
　前記カスタム・メタディレクトリ・エージェント機能を実行するステップがセキュリティ機能を実行することを含む、請求項１８に記載の方法。
【請求項３０】
　前記セキュリティ機能がユーザ・アクセス認可検証プロセスを実行する、請求項２９に記載の方法。
【請求項３１】
前記セキュリティ機能が変更リクエスタ認可プロセスを実行する、請求項２９に記載の方法。
【請求項３２】
　前記変更リクエスタ認可プロセスがディジタル署名を検証する、請求項３１に記載の方法。
【請求項３３】
　前記セキュリティ機能がデータ保全性保証を実行する、請求項２９に記載の方法。
【請求項３４】
　前記セキュリティ機能がピア・ツー・ピア通信を実行する、請求項２９に記載の方法。
【請求項３５】
　双方向メタディレクトリ・エージェントのためのソフトウェアでもってエンコードされたコンピュータ可読媒体であって、前記ソフトウェアは、
データ・ソース特有のプロトコル及びエージェント内部共通フォーマットの間で変更コマンドを変換し、
　前記メタディレクトリ・エージェントによって、変更コマンドがローカル・データ・ソースから送られること及び変更コマンドが前記ローカル・データ・ソースにおいてインプリメントされることを許容及びブロックする条件を定義する第１セットのルールに従って変更コマンドをフィルタ及びブロックし、
　前記変更コマンドにおける属性を属性名のローカル・セットのからメタディレクトリ属性名のセットに及びその逆にマッピングし、
　変更コマンドを前記エージェント内部共通フォーマットからディレクトリ変更プロトコルに及びその逆に変換し、
　１つ以上のカスタム・メタディレクトリ・エージェント機能を実行し、
　前記変更コマンドを前記メタディレクトリ・エージェントに及び前記メタディレクトリ・エージェントから前記ディレクトリ変更プロトコルで送信及び受信する、
　プロセスを含む、コンピュータ可読媒体。
【請求項３６】
　前記マッピングするプロセスが、変更コマンドを前記エージェント内部共通フォーマットからライトウェート・ディレクトリ・アクセス・プロトコルに変換するためのプロセスを含む、請求項３５に記載のコンピュータ可読媒体。
【請求項３７】
　前記変更コマンドを送信及び受信するプロセスが、セキュア・ソケット層プロトコルを使用してコミュニケーションを行うためのプロセスを含む、請求項３５に記載のコンピュータ可読媒体。
【請求項３８】
　前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスが１つ以上のプラグイン機能を実行するためのプロセスを含む、請求項３５に記載のコンピュータ可読媒体。
【請求項３９】
前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスがポータル・サーバとのコミュニケーションを行うためのプロセスを含む、請求項３５に記載のコンピュータ可読媒体。
【請求項４０】
　前記ポータル・サーバとのコミュニケーションを行うためのプロセスがプラグイン機能を実行するためのプロセスを含む、請求項３９に記載のコンピュータ可読媒体。
【請求項４１】
　前記変更コマンドを前記エージェント内部共通フォーマットからディレクトリ変更プロトコルに及びその逆に変換するプロセスが、クライアント・デバイスとメタディレクトリ・ジョイナ、メタディレクトリ・データ・ソース、及びポータル・サーバのグループから選択されたシステムとの間で通信を行うためにクライアントにインターフェースするためのプロセスを含む、請求項３５に記載のコンピュータ可読媒体。
【請求項４２】
　前記クライアント・インターフェースにインターフェースするプロセスがアプリケーション・プログラム・バックエンドを提供するためのプロセスを含む、請求項４１に記載のコンピュータ可読媒体。
【請求項４３】
　前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスが、ポータル・サーバから、クライアント・デバイス、他のポータル・サーバ、メタディレクトリ・ジョイナ、及びメタディレクトリ・データ・ソースのグループから選択されたシステムに変更コマンドをプッシュするためのプロセスを含む、請求項３５に記載のコンピュータ可読媒体。
【請求項４４】
　前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスが、ユーザの希望に従って変更コマンド・ブロッキングを更に制限するためのパーソナライゼーション・ルール・エンジンのためのプロセスを含む、請求項３５に記載のコンピュータ可読媒体。
【請求項４５】
　前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスが、前にクライアント・デバイスに送られた変更及び更新を後処理するためのプロセスを含む、請求項３５に記載のコンピュータ可読媒体。
【請求項４６】
　前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスがセキュリティ機能を実行するためのプロセスを含む、請求項３５に記載のコンピュータ可読媒体。
【請求項４７】
　前記セキュリティ機能を実行するためのプロセスがユーザ・アクセス認可検証プロセスを実行するためのプロセスを含む、請求項４６に記載のコンピュータ可読媒体。
【請求項４８】
前記セキュリティ機能を実行するためのプロセスが変更リクエスタ認可プロセスを実行するためのプロセスを含む、請求項４６に記載のコンピュータ可読媒体。
【請求項４９】
　前記変更リクエスタ認可プロセスがディジタル署名を検証するためのプロセスを含む、請求項４８に記載のコンピュータ可読媒体。
【請求項５０】
　前記セキュリティ機能を実行するためのプロセスがデータ保全性保証を実行するためのプロセスを含む、請求項４６に記載のコンピュータ可読媒体。
【請求項５１】
　前記セキュリティ機能を実行するためのプロセスがピア・ツー・ピア通信を実行するためのプロセスを含む、請求項４６に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ポータル・サーバを介してメタディレクトリをインプリメントし、インターフェースするためのテクノロジに関するものであるが、それに限定されない。
【背景技術】
【０００２】
　コンピューティング企業は、それが大規模のものであろうと又は小規模のものであろうと、多数のディレクトリ、ネットワーク・オペレーティング・システム、及びデータベースを保有し、そのデータベースには、会社のデータ、クライアント情報、及び従業員のデータが記憶される。
【０００３】
　或るシナリオでは、管理されるべきデータが均一の環境内にある。例えば、データのフォーム及びフォーマットは同じであるか又は互換性のあるものである。そのような場合、周期的な「同期化」プロセスが実行される。そのプロセスは、分散したデータ・オブジェクトのコンテンツを比較し、適切なデータを含むようにすべてのデータ・ソースを選択的にコピー又は更新する。
【０００４】
　例えば、電子メール・サーバのメッセージ記憶フォーマットは、通常、電子メールのクライアント・マシンにおける記憶フォーマットと同じである。従って、クライアント・マシンが電子メール・サーバ内にログするとき、そのサーバは、何らかの「新しい」メッセージ（例えば、クライアントの記憶装置にコピーされないで、サーバの記憶装置にあるメッセージ）が存在するかどうかを素早く決定し、それらのメッセージをクライアント・マシンに伝送することができる。大規模な同種のデータベースの同期化は、ＩＢＭ社のLotus Notes（商標）製品のような多くの分散型データベース製品によって実現可能にされる。
【０００５】
　しかし、関連した又は部分的に関連したものを含む多くのデータ・ソースは相互に同種のものではなく、むしろ、異種のものである。例えば、従業員「John Smith」に関する情報は、社内のイントラネットにおける多くの異なるデータ記憶装置に含まれることがある。従業員のレコード（入社日、給与額、住所、扶養者名等）は人的資源サーバにおけるオラクル（Oracle）データベースに含まれ得るし、一方、その従業員の職務情報が（LotusNotes)システムにおける部門又は部局サーバ（部門長の名前、電子メール・アドレス等）に記憶され得る。
【０００６】
　異種のデータ・ソースにおけるデータ・オブジェクトを管理するための１つの使用可能なテクノロジは、ライトウェート・ディレクトリ・アクセス・プロトコル（Lightweight Directory Access Protocol − ＬＤＡＰ）であり、ＬＤＡＰイネーブルド・プロトコルにおいてデータ・オブジェクトを遠隔的に照会及び修正するためのオープン・インダストリ・スタンダードである。このプロトコルは、照会及び変更オペレーションを、ディレクトリにおけるデータ・オブジェクトに対して変更を行うためにＬＤＡＰイネーブルド・サーバによって解釈され得る一律のＬＤＡＰオペレーションに減少させる。
【０００７】
　ＬＤＡＰは、ユーザが組織、個人を見つけること、及び公衆のインターネット又は企業のイントラネットであろうとネットワークにおけるファイル及びデバイスのような他のリソースを見つけることを可能にする。ＬＤＡＰは、ネットワークにおけるディレクトリ・サービスに対するＸ.５００標準の一部であるディレクトリ・アクセス・プロトコル（ＤＡＰ）の最小バージョンである。
【０００８】
　ＬＤＡＰディレクトリのようなある種のディレクトリは、そのディレクトリに対して行われた変更を記録する変更ログに対するサポートを有する。変更ログをサポートしないディレクトリに関して、ユーザ又は管理者は、ディレクトリにおける変更を検出するためのそれら自身のメカニズムを開発することが多い。これらの技術は、通常、ディレクトリをポーリングすること、最後のポーリング・オペレーション以後に行われた如何なる変更も識別すること、及び変更の検出の際、通常はその変更されたエントリに対するすべての属性をリストしてエントリが修正されたことをレポートすることを含む。
【０００９】
　以下の例では、ＸＹＺ社の人的資源データベースにおける個人「John Smith」に対するエントリにおける電話番号が「８３８−１１８０」に等しくなるように更新されるべきであり、彼の部門が部門「６」に変更されるべきものとする。表１に示されるように、５つのフィールドを持ったオリジナル・エントリが表示可能である。
【００１０】
　（表１）
full_name=”JohnSmith”
PhoneNumber=”838-1178”
UserID=”jsmith”
Division=92
Department=5
Email=”jsmith@xyzcorp.com
　なお、フォーマットのエントリは次のようになる：
　full_name,PhoneNumber,UserID,Division,Department,email
【００１１】
　ユーザ作成のスクリプトは、変更されたエントリを含むディレクトリをポーリングし得る。なお、そのディレクトリは、変更ログにおいてレコードを生成する。変更ログにおけるレコードは、表２に示される一連のＬＤＡＰ修正オペレーションとして、エントリに対する変更を反映する。
【００１２】
　（表２）
DN:cn=JohnSmith, ou=Austin, o=xyz
Changetype:modify
replace:PhoneNumber
　 PhoneNumber:838-1180
-
changetype:modify
replace:UserId
　 UserID:jsmith
-
changetype:modify
replace:Division
　 Division:92
-
changetype:modify
replace:Department
　 Department:6
-
changetype:modify
replace:email
　 email:jsmith@xyzcorp.com
【００１３】
　代表的なユーザ作成のスクリプトは、更新又は修正されたデータの実際のフィールドを識別しようとするものではないので、メタディレクトリにおける他のディレクトリに対するその結果の更新は、実際には修正されなかったフィールドを含むすべてのデータ・オブジェクトに対して全体的に簡単に行われる。
【００１４】
　ポーリング・オペレーションが比較的速く一連の単一フィールド修正オペレーションに比較される場合、ユーザ開発の解決方法は、個々の各変更を検出し、メタディレクトリを通して各エントリを（同じにすべてのフィールドを）何回も更新するであろう。
【００１５】
　これは、実際のデータにおけるわずかな増分的変更を行うためにメタディレクトリを通して多くの冗長なエントリ更新を生じさせることが多い。各々が数千のエントリを有する数百個のデータ・ソースを含み得る実際のデータ・ソースの編成が考察されるとき、これらの冗長な更新に関するシステム・パフォーマンスのインパクトは容易に明らかであろう。
【００１６】
　コンピューティング・リソースの効率的でない使用に加えて、これらの更新がコンピュータ・ネットワークを通して伝播し、従って、通信帯域幅及び中間的な記憶メモリを不必要に消費するので、これはシステム・オペレーション全体にかなりの問題を引き起こすことがあり得る。
【００１７】
　ＬＤＡＰ方法のもう１つの欠点は、レガシ・ディレクトリがいつまでも存在し得ること及びすべてのレガシ・ディレクトリがＬＤＡＰ互換性のものにアップグレードされるとは限らないことである。更に、ＬＤＡＰは、実際には、共通アクセス・プロトコル（例えば、ディレクトリをアクセスするリモート方法）を提供するだけであるが、実際の異種データ・ソース管理機能を自身で提供するものではない。
【００１８】
　いくつかのＬＤＡＰレプリケーション・スタンダードが開発中であって未だに完成していないけれども、多くの既存の専有的な方法は異なっており、互換性がない。いずれの場合も、レプリケーション及び同期化は、専有的であろうと或いはスタンダード・ベースであろうと、企業全体の異種データ・ソース・ディレクトリ管理の要求に適合するには不十分である。
【００１９】
　用語「メタディレクトリ」は、異種のデータ・ソースを含む２つ又はそれ以上のディレクトリを管理及び同期化するための手段を提供するエンタープライズ・ディレクトリ管理ツールの１つのクラスを指す。代表的なメタディレクトリ製品は、まったく異なる異種のデータ・ソースを管理するためにそれらのデータを共通のフォーマットにエクスポートし、しかる後、ファイル転送、電子メール、又は他のデータ転送プロトコルを使ってそのデータをメタディレクトリと交換すべく個別のデータ・ソース（例えば、ディレクトリ、ファイル、データベース等）を必要とする。メタディレクトリがデータ・ソースからファイルを受け取った後、管理者はそのメタディレクトリからのデータを追加又は修正することが可能である。そのような製品は、マイクロソフト社によって買収されたズーミット(Zoomit)社により最初に提供されたＶＩＡ製品である。
【００２０】
　メタディレクトリは、それらが既存の解決方法を単純化し且つ新たなウェブ・ベースのアプリケーションを作成するための統合ポイントとして使用可能であるので、システム管理及びセキュリティ管理にとって極めて有用である。例えば、いずれのアプリケーションも、それがユーザ情報、セキュリティ情報、コンフィギュレーション設定等であっても、そのアプリケーションと関連した情報を記憶するという自己専有の方法又はスキームを有する。
【００２１】
　メタディレクトリの使用を通して、これらの種々のデータ・ストアが一旦記憶され、（メタディレクトリのルール及び制約に従って）単一のエンティティとして管理及び監督されるように統合され、それによって、この情報を処理するセキュリティ及び信頼性を高めると共にこの情報を維持するコスト全体を減少させる。
【発明の開示】
【発明が解決しようとする課題】
【００２２】
　しかし、現在のメタディレクトリ製品は、種々のデータ・ソースがそれらのデータをこれらの「共通」フォーマットにエクスポートできることを必要とするので、そのようなエクスポート・オペレーションをサポートしないデータ・ソースは、メタディレクトリに組み込むことを排除されることがある。
【００２３】
　現在のプロセスに従って複数の異種データ・ソースからのエントリを管理する場合におけるもう１つの問題点は、これらのデータ・ソースに情報を一貫して入力し得ないこと、例えば、完全な文字ストリングの一致がないエントリ内に論理的同義語が存在することがあることである。例えば、各々が「Robert Smith」に関する情報を含む３つのデータ・ソースが単一のメタディレクトリにおいて管理される場合、名前「RobertSmith」は、
　データ・ソース１では、Robert Smith、
データ・ソース２では、Bob Smith、
データ・ソース３では、Rob Smith、
として入力されてしまうことがあり得る。
【００２４】
　一般的なメタディレクトリ製品は、これらの別名又は関連のエントリを自動的に解析又は検出することに関して非常にわずかな備えしかなく、管理者がこれらのデータ・オブジェクトを管理するためには手操作で介入する必要があることが多い。同義語を含むそのようなレコードに変更を伝播するための伝統的な方法は、各レコードの変形体に対する変更を伝播することであろう。この例では、メタディレクトリを通して「Robert Smith」に対するメール・アドレスを効果的に更新するために、管理者は、先ず、３つの使用可能な同義語に気がつかなければならないであろうし、更に、メタディレクトリを通して伝播される３つの個別の変更を手操作で実行しなければならないであろう。
【００２５】
　本願の関連出願、即ち、２００２年１月１０日出願の米国特許出願番号１０／０４４９９８号の未決出願において開示されたシステム及び方法は、メタディレクトリにおけるエントリに更新を伝播させるというシステム・パフォーマンスのインパクトを最小にする。更に、このシステムは、ユーザ及び管理者に構成可能性（configurability）及び制御を提供するとともに、既存のメタディレクトリ・ツール及びテクノロジの機能と協同してその機能を拡張する。
【００２６】
　メタディレクトリは、種々のタイプのデータを一様に管理及びアクセスする機会を与えるので、更なる有用性をユーザに提供するためにポータルを介してメタディレクトリにおけるデータをアクセスできるということは非常に有用であろう。
【００２７】
　更に、伝統的なメタディレクトリに対する変更は、結合されたデータ・ソースに変更を適正に提示することによって行われ得るので、不正な又は許されない変更がインプリメントされることを防ぐためにセキュリティ、認証、及びデータ保全性の保証を提供する必要がある。このように、相互通信、セキュリティ、フィルタリング、及びパーソナライゼーション（personalization）フィーチャをポータル・サーバに提供するメタディレクトリは有用であろう。
【課題を解決するための手段】
【００２８】
　ポータル・サーバとの統合を可能にするメタディレクトリ及びポータル・サーバ配置のための整合したアーキテクチャが提供される。そのアーキテクチャは、ポータルを介して未構造化データ及び構造化データへのアクセスを可能にする。ディレクトリ、データベース、ユーザ・レジストリ等のような或る種のデータ・ソースは「構造化データ」（即ち、データベース・レコード）を含み、一方、その他は「未構造化」（即ち、電子メール及びドキュメント）を含む。
【００２９】
　両方の種類のデータとも、本願において開示されるメタディレクトリによってサポートされる。構造化及び未構造化データは、ＬＤＡＰフォーマットのような標準ベースのフォーマットにマップされる。これは、例えば、メタディレクトリがオラクル（Oracle）データベース、ファイル・システム、及びドミノ・ディスカッション（Domino discussion）データベースからのデータを処理することを可能にする。なお、それらのデータベース及びファイル・システムはすべて、かなり異なるフォーマット及び構造のデータがそれらに含まれる。セキュリティ・フィルタリング及びパーソナライゼーションを含むポータル・サーバの機能も提供される。そのポータル・サーバの機能を通して、任意の数のシステムがそのポータル・サーバによるサービスを受けることにより、メタディレクトリ・コンテンツがアクセス及び(又は)修正され得る。
【発明を実施するための最良の形態】
【００３０】
　１つの実施例では、システムは、周知のTivoli SecureWay（商標）エンタープライズ・コンピューティング製品に対する拡張として実現可能である。しかし、インライン・コード変更、或いは他のメタディレクトリ管理ソフトウェア及び製品に機能を加えるために一般に使用される他の技法のような他の適当な実現方法が当業者は容易に明らかであろう。そのような代替のメタディレクトリ管理ソフトウェア製品は、マイクロソフト社からのＶＩＡ製品を含むが、それに限定されない。
【００３１】
　本願において開示されるシステム及び方法は、管理者が或るディレクトリから別のディレクトリにオブジェクトをマッチングするための基準に関するルール、属性及びオブジェクト所有権に関するルール、及びフィルタリング属性に関するルールを指定することを可能にする。例えば、従業員の給与情報が複製されること又は他のディレクトリ、ファイル、若しくはデータベースに複写されることを禁止するために、その情報を含んだメタディレクトリ内のコンポーネントに関するルールが確立され得る。
【００３２】
　メタディレクトリは、次のような機能のいくつか又はすべてを持ち得る：
（ａ）それが、１つ又は複数の接続された異種のデータ・ソース及びメタディレクトリの間で情報を同期化する；
（ｂ）それは、どのデータ・ソースが同期化されるべきかに関して構成可能である；
（ｃ）それは、ＬＤＡＰユニバーサル・リソース・ロケータ（ＵＲＬ）のような、メタディレクトリがそのメタディレクトリのユーザのために解決しなければならない情報に対するポインタを流すことができる；及び
（ｄ）管理者定義のコンフィギュレーション及びルールに従って複数の異種データ・ソースからのデータを複製するための方法を提供する。
【００３３】
　従って、本システム及び方法によって提供されるメタディレクトリは、１つの可能な実施例では、すべての接続ディレクトリからの情報に対するクライアント・アクセスを統合した共通情報モデル（例えば、スキーマ）及び複数の異なるディレクトリを或る統一した方法で管理するための手段を提供するために、複数の異なる名前スペースを論理的な単一の名前スペースに統合するエンタープライズ管理ツールである。しかし、メタディレクトリは、情報を単一のマスタ「メガディレクトリ（mega-directory）」に物理的に統合することを意味するものではなく、ディレクトリ同期化及び複製ツールを意味するものでもない。
【００３４】
　更に、本願のメタディレクトリは、データを、異種のデータ・ソースからインポートすること、異種のデータ・ソースにエクスポートすること、及び変更することを通して相互接続する。なお、それら異種のデータ・ソースは、データベース(即ち、DB2、オラクル等)、Lotus Notes、Novell Directory Services、Netscape、OS/2directories、Windows NT（登録商標）データ・ソース等を含むが、それらに限定されない。
【００３５】
　図１を参照すると、本メタディレクトリ・アーキテクチャ１の一実施例が示される。ジョイナ（Joiner）１０は、情報が統合され且つ同期化されるセントラル・ハブであり、それは、Java（登録商標） Beans１００の使用を通して拡張可能である。
【００３６】
　ジョイナ１０は、データベース１１、１６のような接続されたデータ・ソース（ＤＳ）と、直接に又はメタディレクトリ・エージェント１２、１５、１７を通してコミュニケーションを行う。それは、テキスト・ファイル１８、データベース１６、１１におけるレコード、ネットワーク・データ・ストレージ・アイテム（ＮＤＳ）１３、又は他の遠隔的にアクセス可能なデータ記憶装置、例えば、ＬＤＡＰディレクトリ１４，１９のような種々のデータ・ソースからの同じオブジェクト・タイプのエントリをマージする。ジョイナ１０は、リレーショナル・データベース、望ましくは、ＤＢ２データベースにおける各データ・ソースからの結合されたデータのコピーを保持する。各データ記憶装置に対する各オブジェクト・タイプは、ローカル・テーブル（ＬＴ）１００に含まれる。
【００３７】
　データ記憶装置に対する各オブジェクト結合のエントリは、対応するＬＴにおける行エントリとして反映される。すべてのデータ記憶装置に対してオブジェクトの同じインスタンスを識別するために使用される独特のキー、即ち、「マッチ・キー（Match key）」を含む列が加えられる。
【００３８】
　メタディレクトリ・エージェント１７は、そのメタディレクトリ内のディレクトリ又はデータ・ソースにおける結合されたオブジェクトに対して行われる如何なる変更もジョイナ１０に伝送する。これらの変更は、ジョイナに伝送される変更ログに記憶される。そこで、ジョイナは、これらの変更が有効であるかどうかを評価し、しかる後、そのメタディレクトリにおける他のディレクトリにそれらを伝播する。
【００３９】
　このようにして、ジョイナは次のような機能を提供する：
（ａ）単一のエンティティ又は共通のサブジェクトに関する異なる情報ソースが、複数のデータにおける情報を１つの集合体にリンクすることによってメタディレクトリにおける単一のエントリにグループ化される。
（ｂ）１つの機構におけるすべてのリソースが結合（Join）によって表される。
（ｃ）種々のデータ・ソース相互間の「ファジー」マッチングを可能にするために、ルールは管理者が定義可能である。
【００４０】
　図２は、更に、１つの例を使用して結合オペレーションを図解する。人的資源データベースは、従業員「Clark Kent」に対する第１エントリ２２を含む。その第１エントリは、その従業員の従業員番号、名字、ファースト・ネーム、肩書、職場電話番号、部門、入社日、給与、住所、自宅電話番号、及び健康状態を含む。ノーツの名前及びアドレス帳（NotesName and Address Book - ＮＡＢ）には、Mr. Kentに対するエントリ２３が存在する。そのエントリは、彼のユーザ名、ユーザの短縮名、メール・サーバ及びメール・ファイルの場所、及びインターネットに対して入出力する外部電子メールのための電子メール・アドレスを含む。ＮＴドメイン・ディレクトリには、ユーザＩＤ、パスワード、サーバＩＤ、及びユーザが属するグループのリストを含むMr.Kentに対するエントリ２４が存在する。更に、Novellware（NW3.x）バインダリには、ユーザ・オブジェクト、及びMr. Kentへの及びMr.Kentからのメッセージを経路指定する方法を定義する１つ又は複数のルーティング・テーブル２５が存在し得る。
【００４１】
　メタディレクトリ２０によって行われる基本的な結合オペレーションが、これらのデータ・ソースの各々からの選択されたデータ・アイテムをマージして、Mr. Kentのためのローカル・テーブルにおけるエントリ２１を作成する。マージ又は結合されないデータ・ソースからのオブジェクトはフィルタされる。これは、メタディレクトリに関する統一された見解から一般に必要とされないデータ・アイテムでもってメタディレクトリをクラッタすることを防止する。例えば、ＨＲデータベースからの名字、ファースト・ネーム、肩書、職場電話番号、及び部門がメタディレクトリにエクスポートされ、他の属性（従業員番号、入社日等）は取り除かれる。更に、Novellwareバインダリからのユーザ・オブジェクトがメタディレクトリにエクスポートされ得るが、Mr.Kentに対するルーティング・テーブルは取り除かれる。
【００４２】
　この融通性のある管理制御は、特定の機構情報の所有権及びセキュリティ要件次第で、中央制御対地方自治の論争を平衡させる。それは、「トップダウン」又は「ボトムアップ」が「ジオポリティカル（geo-political）」シナリオの範囲を調整することを可能にする。更に、メタディレクトリ（ＭＤ）は、どのエンティティがデータ・オブジェクトを作成、修正、及び削除するかを決定する、その管理されたデータ・ソースに対するマスタ、スレーブ、又はピアとなり得る。融通性のある属性内容制御（例えば、フィルタリング・コンフィギュレーション）を通して、オブジェクト作成、修正、及び削除の定義とは別に、双方向のフローが定義される。
【００４３】
　説明のためのこの例を続けると、人的資源（ＨＲ）部門は、メタディレクトリがＨＲデータベースにおける他の属性を作成又は削除することを可能にすると同時に、ＨＲデータベースにおける或る属性の作成及び削除を制御し得る。このようにして、図３の例では、ＨＲスタッフが各従業員に対する名前、肩書、及び部門の属性３１を修正し得るし、一方、メタディレクトリが、他の部門のデータ・ソース、例えば、ノーツ名前及びアドレス帳から伝播される（３３）電話及び住所属性３２に対する変更を行い得る。
【００４４】
　図４を参照すると、ジョイナ１０のアーキテクチャの可能な一実施例の詳細図が示される。ジョイナ１０は、データ・ソース（ＤＳ）４３と関連したメタディレクトリ・エージェント４２からデータ・オブジェクト変更を、望ましくは、ＬＤＡＰ変更オペレーション・フォーマットで受け取る。ジョイナ１０が、データ・ソース４３に変更を送ることも可能である。各ＭＤエージェント４２は、ＬＤＡＰインターフェース４１のような適切なインターフェースを具備している。
【００４５】
　ジョイナ１０には、各データ・ソース４３と関連したローカル・テーブル（ＬＴ）１００が共通フォーマットで、恐らく、ＤＢ２フォーマットで維持されるが、それとは別に、他の任意のフォーマットでも維持され得る。そこで、これらの複数のローカル・テーブルが、結合した異種データの同種のビューを提供するテーブル結合機能４５によって結合テーブル（ＪＴ）を作成するために連結される。ＪＴデータは、望ましくは、ユーザがＪＴデータを見てアクセスし得るようにＬＤＡＰサーバ上に記憶される。
【００４６】
　データ・ソース又は管理者から受け取った変更に応答して変更されなければならないデータ・アイテムを適正に識別するためには、解決されるべき２つの問題点が存在する。各データ・アイテムは、属性名及び属性値を含む。例えば、ＨＲデータベースには、各レコードにおける属性（例えば、列）「名字」が存在する。本実施例のClark KentのためのＨＲデータベースにおけるレコード（例えば、行）に関して、属性「名字」の値は「Kent」となるであろう。
【００４７】
　正確なマッチングによる第１の問題点は、単一のデータ・ソースにおける及びデータ・ソース相互間における属性値の値の別名又は同義語を解決することを含む。例えば、「Bob」、「Robert」、又は「Rob」は、ＨＲデータベースにおける属性「First_Name」で見つかったとき、すべて相互の同義語になり得る。「Rob＊」（但し、「＊」は「ワイルド・カード」文字又はストリングである）のような標準のマッチング・ルールは、「Bob」に対してマッチングをもたらさないであろう。「＊ob＊」のような修正されたマッチング・ルールは、別名「Bob」を見つけるであろうが、間違って「Job」も見つけるであろう。
【００４８】
　正確なマッチングによる第２の問題点は、異なるデータ・ソース相互間で属性名（値ではない）を解決することを含む。例えば、従業員のファースト・ネームは、ＨＲデータベースにおける属性「First_Name」に記憶され、再び、名前及びアドレス帳における属性「name_1」に記憶される。もちろん、これら２つの問題点の連結は、次のようにして生じ得る：
　 First_Name = “Robert”
and
name_1 = “Bob”
【００４９】
　前述のように、多くの既存のメタディレクトリ製品は、これらの同義語及びマッチング問題を自動的に解決しようとするものではないが、マッチングを手操作で行うための管理者ツールを提供する。しかし、本願のメタディレクトリは、マッチング・プラグイン４４の使用を通して、望ましくは、Java Beans 及び拡張可能マークアップ言語（ＸＭＬ）の形式で、マッチング及び結合（joining）ロジック、ルール、及び関係の付加を可能にする。これらのマッチング定義及びロジックを使用して、個々のデータ・ソースにとってはローカルな属性ネーミング協定が維持され、マスタ、スレーブ及びピアの役割がカスタマイズされ得る。
【００５０】
　図５を参照すると、ディレクトリ寛容性（directory-agnostic）のメタディレクトリ・エージェント４２の更なる詳細が示される。それは、PEAL、Java、VisualBasic、又は Python のような任意の適切なオブジェクト指向プログラミング・テクノロジを使用して構成し得る。それは、共通サービス５８の機能に対するデータ・ソース特有のインターフェース５９によるサービスの双方向スタックである。データ・ソースからメタディレクトリにレポートされる変更５００は、先ず、ＤＳインターフェース５９によりデータ・ソース特有のプロトコルからインターナル共通フォーマットに変換され、共通サービス５８によって処理され、そして変更マネージャ５１によって受け取られる。
【００５１】
　変更マネージャは、変更を追跡し、それらを変更ログにログする。フィルタ及びルール５２は、メタディレクトリにエクスポートされるべきもの及びエクスポートを阻止されるべきものを定義することを可能にする。そこで、変更は、属性名のローカル・セットからメタディレクトリ属性名にマップされ、望ましくはＸＭＬベースのスキーマ・マッピングを使用してＬＤＡＰプロトコル・フォーマットに変換される。
【００５２】
　拡張機能又はプラグイン機能を通したユーザ・カスタマイズ５４のためのもう１つの処理ステージが、変更をＬＤＡＰデーモン（ＳＬＡＰＤ）４１に提示する前に提供される。一方、ＳＬＡＰＤは、望ましくはセキュア・ソケット・プロトコル（ＳＳＬ）を使用して、その変更をメタディレクトリに伝送する。
【００５３】
　メタディレクトリから（例えば、ジョイナから）データ・ソースに伝播される変更は、ＳＬＡＰＤ４１からメタディレクトリ・エージェント４２によって受け取られる。メタディレクトリによって変更されることを許されたアイテムだけがインプリメントされることを保証するために、フィルタ及びルール５５が利用される。そこで、変更オペレーションがＬＤＡＰプロトコルから共通のサービス・フォーマットにマップされる。その後は、任意のカスタマイズ・プラグインが実行可能になる。そこで、変更オペレーションが共通サービス５８によって処理され、データ・ソース特有のインターフェース５９に送られる。そこで、ＤＳインターフェース５９が、それを、共通のサービス・フォーマットから、特定のデータ・ソースと直接に互換性のあるコマンドに又はコマンドのセットに変換する。
【００５４】
　一実施例では、変更マネージャが、データ・ソースにおける変更に関する適切なリアルタイム応答に対して「アプリケーション支援」され、しかも、それは関連のトリガに対してプラグイン・アーキテクチャを使用する。変更ロギングは周期的であるか又はポーリングされ得るものであり、或いは、イベント又は変更によって駆動され得る。それの最も簡単な形式では、変更ログはテキスト・ベースのファイルである。
【００５５】
　図６には、ＤＢ２テーブル１００、マッチング・プラグイン及びエキスパート・ジョイナ４４、テーブル結合機能４５、並びに同種結合テーブル４６の間の機能的配列が示される。ＭＤエージェントからの（データ・ソースからの）変更はマッチング・プラグイン４４によって処理され、その変更が生じたデータ・ソースと関連するテーブル１００に記憶される。しかる後、複数のテーブル１００が結合ロジック４５によって結合され、前述のように、ＪＴ同種ビュー４６を生じる。管理者から同種ビューを介して（例えば、Ｊａｖａベースのユーザ・インターフェース・ツールを介して）生じた変更は、データ・ソース・テーブル１００にインプリメントされ、しかる後、前述のように、ＭＤエージェントに伝播される。
【００５６】
　次にマッチング・ロジックに話題を変えると、前述のように、異種のデータ・ソースにおけるエントリを効果的にマッチングして変更するためには、解決すべき２つの問題点が存在する。即ち、それは、属性名同義語及び属性値同義語である。次のようなコンポーネント及び論理プロセスは、前述のジョイナのようなメタディレクトリ・ジョイナ機能、又は可能な一実施例では別のジョイナ機能に対するJava Beans拡張として実現される。本発明の精神及び技術的範囲から逸脱することなく、インライン・コード変更又は独立のアプリケーション・プログラム・インプリメンテーションのような代替の実現方法が利用可能であることは当業者には容易に明らかであろう。
【００５７】
　成功したマッチング・システムにより解決されるべき問題に関する本実施例及び説明をレビューすると、同義語は、ファースト・ネーム（例えば、所与の名前）、自宅電話番号、職場電話番号、並びにマッチ・テーブルにおける各データ・ソースに対する肩書に関して定義可能である。
【００５８】
　マッチング・プラグインの一実施例は、結合されたオブジェクト・クラスすべてに対して単一のマッチ・テーブルを使用する。マッチ・テーブル名は、複数のマッチ・テーブルを潜在的にインプリメントするために、すべての結合されたオブジェクト・クラスによって指定される。従って、この実施例では、すべてのオブジェクト・クラスに対するすべてのマッチ・テーブル名が同じ名前として指定される。マッチ・テーブルの一例が表３に示される。表３では、名前及びアドレス帳（ＮＡＢ）及び人的資源データベースに対する同義語が、属性名及び属性値の両方において定義される。
【００５９】
（表３）
　ルール　　　属性名同義語　　　　属性値同義語
　　1　　　　HR:First_name　　　　Rob＊, Bob;
　　　　　　　NAB:name1　　　　　Daniel, Danny, Dan;
　　　　　　　　　　　　　　　　　Liz, Elizabeth;
　　2　　　　HR:Home_tel　　　　　512-111-4321, 111-4321
　　　　　　　NAB:tele1　　　　　512-xxx-yyyy, xxx-yyyy;
　　3　　　　HR:Work_tel　　　　512-999-8888, X8888, ext.8888;
　　　　　　　NAB:tele2　　　　　512-xxx-yyyy, Xyyyy, ext.yyyy;
　　4　　　　HR:Title　　　　　　supervisor,“group supervisor”
　　　　　　　NAB:position
【００６０】
　図８は、メタディレクトリにおけるデータ・ソースに対する変更を生成及び伝播するための高レベル論理的プロセス８０の実施例を示す。前述のように、ジョイナは、正規には、メタディレクトリによって管理されているディレクトリからのエントリのローカル・コピーを記憶する。ジョイナがディレクトリにおけるエントリに対する更新オペレーションを受け取るとき（ステップ８１）、それは、メタディレクトリ・ローカル・テーブルにおける選択されたエントリに関して「適用（apply）」オペレーションを遂行し（ステップ８２）、更新の結果を含む一時的修正エントリを作成する。
【００６１】
　しかし、この一時的修正エントリは、二次記憶装置には書き込まれない（例えば、他の結合されたディレクトリに伝播される）。その修正エントリは、オリジナル（未修正の）エントリと比較され、オリジナル・エントリとその更新されたエントリとの間の相違点を識別する（ステップ８３）。
【００６２】
　オリジナル・エントリと更新されたエントリとの間に相違点がない場合（ステップ８４）、更新はメタディレクトリにおける他のディレクトリに伝播されず、一時的ローカル・エントリは削除される。
【００６３】
　相違点がある場合（ステップ８４）、エントリにおける更新されたフィールドのみを含む差動更新オペレーションが生じ、フィールドに対する最終的な変更を生じないオペレーションは省略される。そこで、この差動更新がメタディレクトリにおける他のディレクトリに伝播され、エントリのオリジナル（未修正）のローカル・コピーがエントリの一時的（更新済み）コピーによって置換される。メタディレクトリにおける結合したオブジェクト及びディレクトの各コンテンツ・フォーマットは種々のフォーマット（例えば、ＮＡＢ、ＤＢ２等のフォーマット）であるので、影響を受けたアイテムに対して差動変更をインプリメントするためには、種々のフォーマット・オブジェクト及びディレクトリ対して、種々の更新オペレーションが実行されなければならない。差動更新は共通フォーマット、望ましくは、ＬＤＡＰで伝播され、メタディレクトリによって各結合オブジェクト及びディレクトリの必要なフォーマットに変換される。
【００６４】
　この実施例では、著名な名前及びそのエントリを形成するすべての属性を記憶するために、エントリ・クラスがインプリメントされる。これらの属性は、属性名によってアルファベット順にソートされる。その結果、ディレクトリからジョイナに送られた更新を適用する「適用」オペレーションは極めて効率的である。
【００６５】
従って、その「差動」オペレーションは、オリジナル・エントリを新たなエントリに変換するために適用される必要がある最小セットの更新又は変更オペレーションを含む。それは、メタディレクトリにおける時間応答性及び帯域幅消費効率を高める。
【００６６】
　更に、この実施例では、アプリケーション・プログラミング・インターフェース（ＡＰＩ）がＬＤＡＰ　ＡＰＩにマップされる。従って、ディレクトリにおいて行われた変更をジョイナに伝播する責任があるメタディレクトリ・エージェントは、その変更をＬＤＡＰ「追加」、「削除」、又は「修正」のようなＬＤＡＰオペレーションとして記録する。
【００６７】
　以下の例は、ＸＹＺ社の人的資源データベースにおける個人「John Smith」に関するエントリにおける電話番号が838-1180に更新され、彼の部門が部門６に変更されるべき場合のメタディレクトリのオペレーションを示す。５つのフィールドを有するオリジナル・エントリが、前掲の表１に示されるように現れる。エントリに対する変更をＬＤＡＰ修正オペレーションとして反映する、メタディレクトリ・エージェントによって作成された変更ログにおけるレコードが表２に示された。
【００６８】
　変更がメタディレクトリ・エージェントによってジョイナに送られるとき、ジョイナは、新たな（一時的な）エントリを作成するためにそれがローカル的に記憶したオリジナル・エントリにその変更を適用する。旧エントリと新エントリとの間の相違を決定した後、ジョイナは、表４に示されるような差動更新ＬＤＡＰオペレーションを生じる。
【００６９】
　（表４）
　　　DN:cn=JohnSmith, ou=Austin, o=xyz
　　　changetype:modify
　　　replace:PhoneNumber
　　　　　PhoneNumber:838-1180
　　　-
　　　changetype:modify
　　　replace:Department
　　　　　Department:6
【００７０】
　そこで、この差動更新オペレーションは、メタディレクトリ内の他のディレクトリにジョイナによって伝播される。伝播帯域幅が減少すること及び更新処理要件がこの差動更新技法によって減少することは、この簡単な例から容易に明らかである。実際に、ほとんどのエントリが５つ以上のフィールドを有し、更新は所与の期間内に多くのエントリに対して生じ得る。これは、本発明の利点を倍増する。
【００７１】
　比較を目的として更新オペレーションを適用すべきローカル・テーブル・エントリを選択するステップは、この実施例では、先ず、マッチ・テーブルを含むユーザ構成可能な同義語ディクショナリを使用してキー又はフィールドにおける同義語を含むレコードに対する複数オペレーションの減少を可能にし、複数のマッチング・エントリから１つの最良のマッチング・エントリを選択する場合の援助をする。
【００７２】
　同義語ディクショナリ又は「マッチ・テーブル」を調べるこのマッチング・ロジックは、データ・ソースが変更を最小セットの変更に減少させるために変更ロジックにおける変更を調べる前に実行される。
【００７３】
　説明の便宜上、図７は、２つのデータ・ソースＤ１及びＤ２におけるいくつかの例示的エントリを示す。更に、この例のために、データ・ソースＤ１は、マッチされるべきエントリのメタディレクトリ・コピーであり、第２のデータ・ソースＤ２は、マッチング・エントリに関してサーチされるべきデータ・ソースであるものとする。更に、データ・ソースＤ１には、いくつかの属性a１乃至aｎがあり、それらは、データ・ソースＤ２において属性a１’乃至aｍ’にマップされるものとする。恐らく、a１は、データ・ソースＤ１における「ファースト・ネーム（First_name）」であり、データ・ソースＤ２における「name1」すなわちa１’にマップされる。更に、この説明に関して、エントリe０はＤ２においてマッチされるべきエントリ又はレコード（例えば、属性値のセット）であり、Ｄ２のレコードe１及びe２は共に、下記のようにエントリe０における属性a１にマッチするものとする。
　e０(a１)=“Kris”;
e１(a１’)=“Chris”; 及び
e２(a１’)=“Krishna”;
これらはすべて属性値同義語として定義される。
【００７４】
　ほとんどの場合、データ・ソースＤ２が実際に同じ個人「Kris」に対して２つのレコードを含むことはありそうもなく、従って、このマッチングは、マッチングの一般的な基本ルールに基づいて完全には解決されない。ほとんどのメタディレクトリ製品は、このマッチングの矛盾を簡単に記録し、管理者が手操作で解決するようにそれを管理者にレポートしている。
【００７５】
　しかし、本発明のマッチング・プロセスは、複数の属性をマッチングして最もマッチしそうなものを決定するというウェート付けマッチング方法を提供することによって、一般的なマッチングで解決できない多くの点を排除する。例えば、更に、データ・ソースＤ１の属性a５が「肩書（Title）」であり、データ・ソースＤ２の属性a５’が「地位（Position）」であると仮定する。従って、それら２つの属性は相互にマップされ得るし、ウェートはそれら属性の間のマッチングに割り当てられ得る。「ファースト・ネーム（First_name）」に対して０.９のウェート及び「肩書」に対して０.６のウェートを仮定し、次のような例のレコードを仮定する：
　e０(a１,…,a５)=(“Kris”,…,“Manager”)
e１(a１’,…,a５’)=(“Chris”,…,“Contractor”)
e２(a１’,…,a５’)=(“Krishna”,…,“Supervisor”);
しかも、「Manager」及び「Supervisor」は同義語として定義され、結合された「スコア」又はウェートは、e０及びe１の間で０.９（ファースト・ネームのみのマッチ）を割り当てられ、e０及びe２の間で１.５（ファースト・ネーム及び肩書の両方のマッチ）を割り当てられる。このプロセスは、望ましい場合には、マップされ且つ比較された属性の数でスコアを除することによって（この例では、２で除するというようにして）正規化され、閾値がセットされ得る。なお、その除算の結果が閾値を超えた場合にマッチが表される。このプロセスは、特定のウェート割り当てを有する各属性との比較では任意の数の属性を含むように拡張可能である。
【００７６】
　図９を参照すると、ウェート付けされたスコアを複数マッチのエントリに適用するための１つの可能な実施例による論理的プロセス８２が更に詳細に示される．プロセスが開始すると（ステップ９１）、同義語による減少及びマッチングが可能であるかどうかを知るためのチェックが行われ（ステップ９２）、それが肯定される場合、１つの最良のマッチング・エントリだけが選択されるように、マップされた属性の値にマッチするすべてのエントリに対して管理者構成可能な同義語ディクショナリを使用して（ステップ９４）、前述のように、ウェート付けされたスコアリングが行われる（ステップ９３）。
【００７７】
　今や、単一の最良のマッチ・エントリが選択され、選択されたエントリの一時的コピーに対して、変更又は更新が施される（ステップ９５）。
【００７８】
　処理は、図８に示されるように、更新されたエントリをオリジナルの（未修正の）選択されたエントリと比較する（ステップ８３）ことによって進行する。しかる後、更新のためにエントリに対する最終的な変更がある場合（例えば、一時的コピーがオリジナル・コピーに等しくない場合）、差動更新オペレーションを生じるように（ステップ８６）及びメタディレクトリにおける他のディレクトリにそのオペレーションを伝播するように（ステップ８７）、処理が継続する。
【００７９】
　任意選択的には、1つのディレクトリ内にあって同じエンティティを参照する複数のエントリがフラッグ又はマークされ得る。それは、これらのエントリにおけるフィールド又はキーが同義であるためである。これは、管理者がそのマークされたエンティティをレビューし、その同義語のエンティティを最もよく表す単一のエントリを選択し、そのディレクトリにおける他のエンティティを削除することを可能にする。これは、1つのディレクトリにおいて管理される必要があるエントリの数及び生成される変更ログ・エントリの数を減少させる。
【００８０】
　本発明のメタディレクトリ・エージェントに関する第1の局面では、メタディレクトリ・オペレーションのための機能、並びに、前述のように且つ図5に示されたように、セキュリティ・フィーチャ及びパーソナライゼーションのための機能を提供するために使用可能である層状のスタックが定義される。これは、メタディレクトリのために使用される同じ構成可能なビルディング・ブロックが、ポータルをインプリメントするために使用されることを可能にする。これは、メタディレクトリ及びポータルが種々のソースからの情報を集約し、この情報の統一され且つパーソナル化されたビューをユーザに提供することを可能にする．
【００８１】
　メタディレクトリ・エージェントのための本発明のアーキテクチャは、エージェントがクライアント・デバイス及びサーバ・デバイスの両方において有用であることをも可能にする。同じメタディレクトリ・エージェントの汎用の層は、ディレクトリ・サーバ上でクライアントにより実行され得るか又はアプリケーション・プログラムと統合され得る。メタディレクトリの機能は、それを他のバックエンド・プロセスとして扱うことによってアプリケーションと統合され得る。或るポータル・サーバは、企業の既存のワークフロー及びビジネス・プロセス・アプリケーションとの相互協調処理を必要とするので、アプリケーションとの統合化が有用であろう。
【００８２】
　ＰＤＡ、ＷＡＰデバイスのような種々のデバイスに対する変更の通知を強制するための本発明のメタディレクトリの機能は更に有用である。実際に、或るサーバは、デバイスへの通知を「強要する」。本発明のメタディレクトリは、ポータル・サーバからデバイスに、及び或るポータル・サーバから別のポータル・サーバに作業する機能を与える。それは、ルール・エンジンをスタックに挿入するというようなパーソナライゼーションに備える。ポータル・サーバは、デバイスに送られた変更又は更新の後処理を可能にすることによって、本発明のメタディレクトリを使用して機能強化され得る。更に、本発明のメタディレクトリは、種々のディレクトリ及びデバイスへの変更の通知を強制する機能を有する。
【００８３】
　セキュリティ・フィーチャは、ユーザ認証及びアクセス・チェックを可能にする「プラグイン」を通して本発明のメタディレクトリを具備し得る。これらは、メタディレクトリ及びポータル・サーバの両方にとって有用である。本発明は、エージェント・スタックにおけるセキュリティ・プラグインを介して2つの問題を解決する。第1の問題は、情報に対するユーザ・アクセスを許容する前に、認証し、アクセス・チェックを行うというものである。第2の問題は、ピア・ツー・ピアのポータル・サーバ交換において、認証及びデータ保全性のために改ざんを防ぐようコンテンツがディジタル的にサインされることを保証するというものである。
【００８４】
　本発明のメタディレクトリ・アーキテクチャ及びエージェントに関するこれらの能力がこれらの機能に適応する方法を理解するために、メタディレクトリ・エージェントの詳細を検討することにする。図5に示されたように編成された本発明のメタディレクトリ・エージェントのプロセスを更に詳細に注意すると共に、図１０のローカル・データ・ソース１６３における変更が検出される（ステップ１５１）という論理的プロセスの実施例を参照する。その変更は、ローカル・データ・ソース独特のプロトコルから、メタディレクトリ・エージェント内で使用される内部フォーマットに変換される（ステップ１５２）。そこで、その変更は、変更ログ１５４内にログされ（ステップ１５３）、メタディレクトリを通して変更を伝播するための任意のフィルタ及び（又は）ルール１５５が適用される（ステップ１５６）。
【００８５】
　変更がルール及びフィルタに従って伝播されるべき場合（ステップ１５７）、変更がローカル属性名からメタディレクトリ属性名にマップされ（ステップ１５８）、そして再フォーマットされる。しかる後、ユーザ・プラグイン機能が処理される（ステップ１５９）。その処理中、他のネットワーク・サーバ又はプロセスが関与可能である（例えば、他のサーバ及びプロセスとのコミュニケーションがプラグインによって遂行され得る）。最終的に、変更がジョイナに伝送される（ステップ１６０）。
【００８６】
　図１１は、メタディレクトリから、本発明のメタディレクトリ・エージェントによって提供されるローカル・データ・ソースに伝播された変更を受け取るための論理的プロセスの実施例を示す。ジョイナから又はメタディレクトリの他の部分から変更を受け取ると（ステップ１７１）、その変更がインプリメントされるべきか（又は、拒否されるべきか）どうかを決定するためにフィルタ及びルール１５５が適用される（ステップ１７２）。変更がインプリメントされるべき場合（ステップ１７３）、その変更はローカル・データ・ソースの属性名にマップされ（ステップ１７４）、そのローカル・データ・ソースのプロトコルに再フォーマットされる。
【００８７】
　しかる後、プラグイン機能が実行される（ステップ１７５）。その実行中、他のネットワーク・サーバ１６２又はプロセスがそれらのサーバ又はプロセスとのコミュニケーションを介してその処理に関与することが可能である。最終的に、変更がローカル・データ・ソース１６３においてインプリメントされ（ステップ１７６）、変更ログ１５４に記録される（ステップ１７７）。
【００８８】
　今や、上述のメタディレクトリ・エージェント・アーキテクチャの効力を通して、２つの機能が提供される。第１に、ポータル・サーバを介してメタディレクトリにポータルが提供される。第２に、受け取った変更が実際に信頼性のあるソースからのものであって、改変されてないことをメタディレクトリ・エージェントが確認することを可能にするピア・ツー・ピア・セキュリティが提供される。
【００８９】
　ポータル機能の説明がピア・ツー・ピア・セキュリティ機能の理解を更に助けるので、先ず、そのポータル機能を説明する。、図１４は、ポータルをメタディレクトリに提供するシステムの１つの可能な実施例を図解したものを示す。情報テクノロジ及びｅ−ビジネスの語法において現在使用されている用語の一般的な意味におけるポータルは、ユーザが種々のデータ又はサービスをオンラインでアクセスするときに用いるシステム又はサーバである。例えば、旅行計画のウェブ・サイトは、航空券予約システム、レンタカー・システム、旅行者情報データベースのような個別のシステムに対するポータルと見なすことができる。
【００９０】
　図１４の例では、無線でネットワーク接続されたパーソナル・ディジタル・アシスタント（ＰＤＡ）のような無線クライアント２０６は、種々のデータをアクセスするために使用されるべきものである。この例に関して、この種々のデータは、取引レコード、報道記事、会社概要、及びリアルタイムのチッカー情報のような投資及びビジネス関連のデータであるものとする。
【００９１】
　その場合、このタイプの異種情報は、前述のように、メタディレクトリに入れておくには適している。更に、メタディレクトリのジョイナ１０は、第１ポータル・サーバ２０２とコミュニケーションを行うメタディレクトリ・エージェント２０１を備えている。そのメタディレクトリ・エージェントは、ポータル・サーバの通信機能と互換性のあるプラグインを使用してポータル・サーバとコミュニケーションを行うように適応している。例えば、ポータル・サーバは、ＴＣＰ／ＩＰプロトコルを使用してコミュニケーションを行うことが可能である。もう１つのポータル・サーバは、トランザクション指向のもの（例えば、株式売買システム）であってもよく、電子データ交換（ＥＤＩ）を使用してコミュニケーションを行ってもよい。本質的には、任意の通信プロトコル或いはスキーム（即ち、ＨＴＴＰ、ＳＳＬ、ＥＤＩ、電子メール、ＴＣＰ／ＩＰ等）が、前述のように、プラグインの使用を通してメタディレクトリ・エージェントのアーキテクチャに統合され得る。そこで、これは、メタディレクトリが種々のタイプ及びフォーマットのデータ・ソースを統合することを可能にするのみならず、種々のタイプの通信機能を統合することも可能にする。
【００９２】
　更に、ポータル・サーバは、クライアント・システム２０６におけるメタディレクトリ・エージェント２０５とコミュニケーションを行うためにメタディレクトリ・エージェント２０４を具備することが可能である。これは、メタディレクトリとクライアントとの間の通信パスを完成する。このようにして、クライアントは、メタディレクトリ内のいずれのデータ・ソースからも情報を受け取ることが可能であり、変更又はトランザクションを、データ・ソースを通して伝播するために、メタディレクトリにサブミットすることも可能である。
【００９３】
　例えば、クライアントは、投資者に対して住所変更をサブミットし得るし、その結果、メタディレクトリに含まれているクライアントの銀行口座、オンライン投資口座、旅行概要等におけるそのクライアントの住所に関する対応するすべてのレコード及びインスタンスの自動更新を生じさせる。同様に、クライアントは、チッカー・レポーティング・サーバからの株価、銀行及び投資会社からの口座残高、及び通信社からのニュース・リリースのような情報を、それがメタディレクトリ内で変更するときに受け取り得る。
【００９４】
　本発明のメタディレクトリのポータル機能に関連した第２の新たなフィーチャでは、ピア・ツー・ピア・セキュリティがメタディレクトリ・エージェントにおけるプラグインの使用を通して実現される。金融情報及び取引のためにポータルを使用する無線クライアントに関する上記の例では、メタディレクトリ変更のソースを認証する必要が示されている。例えば、クライアントはメタディレクトリに含まれた１つの口座から別の口座への資金の移動を許可し得るけれども、未許可のソースからのそのような変更を行おうとする試みを阻止又は拒否することが望ましい。
【００９５】
　このようにして、図１２及び図１３における例のような論理的プロセス有するピア・ツー・ピア（Ｐ２Ｐ）セキュリティ・プラグインが提供される。図１２を参照すると、メタディレクトリ・エージェントが変更を受け取るとき、ローカル・データ・ソースにおけるインプリメンテーションの前に、プラグインは、ＩＢＭ社のWebSphere認証製品のような認証サービス又はサーバとコミュニケーションを行うことによって変更のソースを認証する（ステップ１８１）。ソースが認証されたものである場合、そのソースは、リクエストされた変更を行うための認可の適性をチェックされる。これも、ＩＢＭ社のWebSphere認証製品のような認証サーバ製品とコミュニケーションを行うことによって遂行され得る。簡単な名前及びパスワード方式、公開鍵インフラストラクチャ（ＰＫＩ）、ディジタル署名、証明書交換等のような他の形式の認証及び（又は）認可が利用可能である。ソースが認証されないか又はその変更を行うことを認可されない場合、変更インプリメンテーションはブロックされる（ステップ１７８）。
【００９６】
　図１３は、プラグインを介したエージェントのようなメタディレクトリ・エージェントにおいて具体化されたそのような安全な変更を生成及び伝播するための論理的プロセスを示す。ディジタル署名（又は、名前、又は、証明等）のような識別子が、変更をリクエストする（例えば、伝播する）データ・ソースにおけるメタディレクトリ・エージェントによって変更コマンド又はメッセージに適用される（ステップ１９１）。暗号化、巡回冗長コード生成（ＣＲＣ）等のような他の形式のデータ・プライバシ及び保全性保証も適用され得る（ステップ１９２）。しかる後、この機能強化された変更コマンドがメタディレクトリを介して伝播される。それを受信した際、受信側のメタディレクトリ・エージェントの対応するセキュリティ・プラグインが変更コマンドの認証及び認可を確認するであろう。
【００９７】
　特許請求の範囲によって定義されたような本発明の技術的範囲から逸脱することなく、上記の実施例に対して種々の修正及び変更を行い得ることは上記の説明から明らかであろう。
　本発明は、ハードウェア、ソフトウェア、またはハードウェア及びソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアの組み合わせによる実行において、所定のプログラムを有するコンピュータ・システムにおける実行が典型的な例として挙げられる。かかる場合、該所定のプログラムが該コンピュータ・システムにロードされ実行されることにより、該プログラムは、コンピュータ・システムを制御し、本発明にかかる処理を実行させる。このプログラムは、任意の言語・コード・表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接、または１．他の言語・コード・表記への変換、２．他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行することを可能にするものである。もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記録した媒体もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハード・ディスク装置、ＲＯＭ、ＭＲＡＭ、ＲＡＭ等の任意のコンピュータ読み取り可能な記録媒体に格納することができる。かかるプログラムは、記録媒体への格納のために、通信回線で接続する他のコンピュータ・システムからダウンロードしたり、他の記録媒体から複製したりすることができる。また、かかるプログラムは、圧縮し、または複数に分割して、単一または複数の記録媒体に格納することもできる。
【００９８】
　まとめとして、本発明の構成に関して以下の事項を開示する。
【００９９】
（１）データ・ソース特有のプロトコル及びエージェント内部共通フォーマットの間で変更コマンドを変換するためのデータ・ソース・コンバータ層と、
　前記データ・ソースからメタディレクトリにエクスポートされることを許容されない変更及び外部エンティティから前記データ・ソースにインプリメントされることを許容されない変更をブロックするためのフィルタ及びルール層と、
　属性名のローカル・セットからメタディレクトリ属性名のセットに及びその逆に変更コマンドにおける属性を変換し、前記エージェント内部共通フォーマット及びディレクトリ変更プロトコルの間で変更コマンドを変換するためのマッピング層と、
　カスタム・メタディレクトリ・エージェント機能をインプリメントするためのユーザ・カスタマイズ層と、
　前記変更コマンドを前記ディレクトリ変更プロトコルで送信及び受信するためのメタディレクトリ・インターフェースと、
　を含む、双方向メタディレクトリ・エージェント。
（２）前記マッピング層が、変更コマンドを前記エージェント内部共通フォーマット及びライトウェート・ディレクトリ・アクセス・プロトコルの間で変換するように構成される、上記（１）に記載の双方向メタディレクトリ・エージェント。
（３）前記メタディレクトリ・インターフェースがセキュア・ソケット層通信インターフェースを含む、上記（１）に記載の双方向メタディレクトリ・エージェント。
（４）前記ユーザ・カスタマイズ層が１つ又は複数のプラグイン機能を含む、上記（１）に記載の双方向メタディレクトリ・エージェント。
（５）前記ユーザ・カスタマイズ層がポータル・サーバ通信機能を含む、上記（１）に記載の双方向メタディレクトリ・エージェント。
（６）前記ポータル・サーバ通信機能がプラグイン機能を含む、上記（５）に記載の双方向メタディレクトリ・エージェント。
（７）前記データ・コンバータ層が、クライアント・システムとメタディレクトリ・ジョイナ、メタディレクトリ・データ・ソース、及びポータル・サーバのグループから選択されたシステムとの間で通信を行うためのクライアント・インターフェースを含む、上記（１）に記載の双方向メタディレクトリ・エージェント。
（８）前記クライアント・インターフェースがアプリケーション・プログラム・バックエンドを含む、上記（７）に記載の双方向メタディレクトリ・エージェント。
（９）前記ユーザ・カスタマイズ層が、ポータル・サーバから、クライアント・デバイス、他のポータル・サーバ、メタディレクトリ・ジョイナ、及びメタディレクトリ・データ・ソースのグループから選択されたシステムに変更コマンドをプッシュする変更通知プッシュ機能を含む、上記（１）に記載の双方向メタディレクトリ・エージェント。
（１０）前記ユーザ・カスタマイズ層が、ユーザの希望に従って変更コマンド・ブロッキングを更に制限するためのパーソナライゼーション・ルール・エンジンを含む、上記（１）に記載の双方向メタディレクトリ・エージェント。
（１１）前記ユーザ・カスタマイズ層が前にクライアント・デバイスに送られた変更及び更新を後で処理するための後処理機能を含む、上記（１）に記載の双方向メタディレクトリ・エージェント。
（１２）前記ユーザ・カスタマイズ層がセキュリティ機能を含む、上記（１）に記載の双方向メタディレクトリ・エージェント。
（１３）前記セキュリティ機能がユーザ・アクセス認可検証プロセスを含む、上記（１２）に記載の双方向メタディレクトリ・エージェント。
（１４）前記セキュリティ機能が変更リクエスタ認可プロセスを含む、上記（１２）に記載の双方向メタディレクトリ・エージェント。
（１５）前記変更リクエスタ認可プロセスがディジタル署名ベリファイヤを含む、上記（１４）に記載の双方向メタディレクトリ・エージェント。
（１６）前記セキュリティ機能がデータ保全性保証機能を含む、上記（１２）に記載の双方向メタディレクトリ・エージェント。
（１７）前記セキュリティ機能がピア・ツー・ピア通信インターフェースを含む、上記（１２）に記載の双方向メタディレクトリ・エージェント。
（１８）双方向メタディレクトリ・エージェントによって実行される方法であって、
データ・ソース特有のプロトコル及びエージェント内部共通フォーマットの間で変更コマンドを変換するステップと、
　前記メタディレクトリ・エージェントによって、変更コマンドがローカル・データ・ソースから送られること及び変更コマンドが前記ローカル・データ・ソースにおいてインプリメントされることを許容及びブロックする条件を定義する第１セットのルールに従って変更コマンドをフィルタ及びブロックするステップと、
　前記変更コマンドにおける属性を属性名のローカル・セットのからメタディレクトリ属性名のセットに及びその逆にマッピングするステップと、
　変更コマンドを前記エージェント内部共通フォーマットからディレクトリ変更プロトコルに及びその逆に変換するステップと、
　１つ以上のカスタム・メタディレクトリ・エージェント機能を実行するステップと、
　前記変更コマンドを前記メタディレクトリ・エージェントに及び前記メタディレクトリ・エージェントから前記ディレクトリ変更プロトコルで送信及び受信するステップと、
　を含む方法。
（１９）前記マッピングするステップが、変更コマンドを前記エージェント内部共通フォーマットからライトウェート・ディレクトリ・アクセス・プロトコルに変換することを含む、上記（１８）に記載の方法。
（２０）前記変更コマンドを送信及び受信するステップが、セキュア・ソケット層プロトコルを使用してコミュニケーションを行うことを含む、上記（１８）に記載の方法。
（２１）前記カスタム・メタディレクトリ・エージェント機能を実行するステップが１つ以上のプラグイン機能を実行することを含む、上記（１８）に記載の方法。
（２２）前記カスタム・メタディレクトリ・エージェント機能を実行するステップがポータル・サーバとのコミュニケーションを行うことを含む、上記（１８）に記載の方法。
（２３）前記ポータル・サーバとのコミュニケーションがプラグイン機能を実行すること含む、上記（２２）に記載の方法。
（２４）前記変更コマンドを前記エージェント内部共通フォーマットからディレクトリ変更プロトコルに及びその逆に変換するステップが、クライアント・デバイスとメタディレクトリ・ジョイナ、メタディレクトリ・データ・ソース、及びポータル・サーバのグループから選択されたシステムとの間でコミュニケーションを行うためのクライアント・インターフェースを提供することを含む、上記（１８）に記載の方法。
（２５）前記クライアント・インターフェースがアプリケーション・プログラム・バックエンドを提供する、上記（２４）に記載の方法。
（２６）前記カスタム・メタディレクトリ・エージェント機能の実行が、ポータル・サーバから、クライアント・デバイス、他のポータル・サーバ、メタディレクトリ・ジョイナ、及びメタディレクトリ・データ・ソースのグループから選択されたシステムに変更コマンドをプッシュすることを含む、上記（１８）に記載の方法。
（２７）前記カスタム・メタディレクトリ・エージェント機能を実行するステップが、ユーザの希望に従って変更コマンド・ブロッキングを更に制限するためのパーソナライゼーション・ルール・エンジンを提供することを含む、上記（１８）に記載の方法。
（２８）前記カスタム・メタディレクトリ・エージェント機能を実行するステップが、前にクライアント・デバイスに送られた変更及び更新を後処理することを含む、上記（１８）に記載の方法。
（２９）前記カスタム・メタディレクトリ・エージェント機能を実行するステップがセキュリティ機能を実行することを含む、上記（１８）に記載の方法。
（３０）前記セキュリティ機能がユーザ・アクセス認可検証プロセスを実行する、上記（２９）に記載の方法。
（３１）前記セキュリティ機能が変更リクエスタ認可プロセスを実行する、上記（２９）に記載の方法。
（３２）前記変更リクエスタ認可プロセスがディジタル署名を検証する、上記（３１）に記載の方法。
（３３）前記セキュリティ機能がデータ保全性保証を実行する、上記（２９）に記載の方法。
（３４）前記セキュリティ機能がピア・ツー・ピア通信を実行する、上記（２９）に記載の方法。
（３５）双方向メタディレクトリ・エージェントのためのソフトウェアでもってエンコードされたコンピュータ可読媒体であって、前記ソフトウェアは、
データ・ソース特有のプロトコル及びエージェント内部共通フォーマットの間で変更コマンドを変換し、
　前記メタディレクトリ・エージェントによって、変更コマンドがローカル・データ・ソースから送られること及び変更コマンドが前記ローカル・データ・ソースにおいてインプリメントされることを許容及びブロックする条件を定義する第１セットのルールに従って変更コマンドをフィルタ及びブロックし、
　前記変更コマンドにおける属性を属性名のローカル・セットのからメタディレクトリ属性名のセットに及びその逆にマッピングし、
　変更コマンドを前記エージェント内部共通フォーマットからディレクトリ変更プロトコルに及びその逆に変換し、
　１つ以上のカスタム・メタディレクトリ・エージェント機能を実行し、
　前記変更コマンドを前記メタディレクトリ・エージェントに及び前記メタディレクトリ・エージェントから前記ディレクトリ変更プロトコルで送信及び受信する、
　プロセスを含む、コンピュータ可読媒体。
（３６）前記マッピングするプロセスが、変更コマンドを前記エージェント内部共通フォーマットからライトウェート・ディレクトリ・アクセス・プロトコルに変換するためのプロセスを含む、上記（３５）に記載のコンピュータ可読媒体。
（３７）前記変更コマンドを送信及び受信するプロセスが、セキュア・ソケット層プロトコルを使用してコミュニケーションを行うためのプロセスを含む、上記（３５）に記載のコンピュータ可読媒体。
（３８）前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスが１つ以上のプラグイン機能を実行するためのプロセスを含む、上記（３５）に記載のコンピュータ可読媒体。
（３９）前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスがポータル・サーバとのコミュニケーションを行うためのプロセスを含む、上記（３５）に記載のコンピュータ可読媒体。
（４０）前記ポータル・サーバとのコミュニケーションを行うためのプロセスがプラグイン機能を実行するためのプロセスを含む、上記（３９）に記載のコンピュータ可読媒体。
（４１）前記変更コマンドを前記エージェント内部共通フォーマットからディレクトリ変更プロトコルに及びその逆に変換するプロセスが、クライアント・デバイスとメタディレクトリ・ジョイナ、メタディレクトリ・データ・ソース、及びポータル・サーバのグループから選択されたシステムとの間で通信を行うためにクライアントにインターフェースするためのプロセスを含む、上記（３５）に記載のコンピュータ可読媒体。
（４２）前記クライアント・インターフェースにインターフェースするプロセスがアプリケーション・プログラム・バックエンドを提供するためのプロセスを含む、上記（４１）に記載のコンピュータ可読媒体。
（４３）前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスが、ポータル・サーバから、クライアント・デバイス、他のポータル・サーバ、メタディレクトリ・ジョイナ、及びメタディレクトリ・データ・ソースのグループから選択されたシステムに変更コマンドをプッシュするためのプロセスを含む、上記（３５）に記載のコンピュータ可読媒体。
（４４）前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスが、ユーザの希望に従って変更コマンド・ブロッキングを更に制限するためのパーソナライゼーション・ルール・エンジンのためのプロセスを含む、上記（３５）に記載のコンピュータ可読媒体。
（４５）前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスが、前にクライアント・デバイスに送られた変更及び更新を後処理するためのプロセスを含む、上記（３５）に記載のコンピュータ可読媒体。
（４６）前記カスタム・メタディレクトリ・エージェント機能を実行するプロセスがセキュリティ機能を実行するためのプロセスを含む、上記（３５）に記載のコンピュータ可読媒体。
（４７）前記セキュリティ機能を実行するためのプロセスがユーザ・アクセス認可検証プロセスを実行するためのプロセスを含む、上記（４６）に記載のコンピュータ可読媒体。
（４８）前記セキュリティ機能を実行するためのプロセスが変更リクエスタ認可プロセスを実行するためのプロセスを含む、上記（４６）に記載のコンピュータ可読媒体。
（４９）前記変更リクエスタ認可プロセスがディジタル署名を検証するためのプロセスを含む、上記（４８）に記載のコンピュータ可読媒体。
（５０）前記セキュリティ機能を実行するためのプロセスがデータ保全性保証を実行するためのプロセスを含む、上記（４６）に記載のコンピュータ可読媒体。
（５１）前記セキュリティ機能を実行するためのプロセスがピア・ツー・ピア通信を実行するためのプロセスを含む、上記（４６）に記載のコンピュータ可読媒体。
【図面の簡単な説明】
【０１００】
【図１】メタディレクトリのコンポーネントの配列を示す図である。
【図２】説明目的のための例示的なメタディレクトリを示す図である。
【図３】メタディレクトリによってマージされた属性名及び属性値の可能なセットの詳細な例を示す図である。
【図４】メタディレクトリの構造の詳細を示す図である。
【図５】メタディレクトリ・エージェントのコンポーネントの詳細を示す図である。
【図６】メタディレクトリ・エージェントの一実施例の論理的プロセスを示す図である。
【図７】説明目的のための複数エントリ・マッチングの例を示す図である。
【図８】メタディレクトリ変更生成の高レベル論理的プロセスを示す図である。
【図９】複数エントリ・マッチングにおけるウェート付けされたスコアを生成し遂行する論理的プロセスの詳細を示す図である。
【図１０】変更を伝播するときにメタディレクトリ・エージェントによって遂行される論理的プロセスを示す図である。
【図１１】変更を受信するときにメタディレクトリ・エージェントによって遂行される論理的プロセスを示す図である。
【図１２】メタディレクトリ・エージェント・プラグインのようなメタディレクトリ・エージェントによって遂行されるソース認証のための論理的プロセスを示す図である。
【図１３】メタディレクトリ・エージェント・プラグインのようなメタディレクトリ・エージェントによって遂行されるソース識別のための論理的プロセスを示す図である。
【図１４】メタディレクトリにポータル・サーバ機能を与えるためのシステム及びコンポーネントの配列を示す図である。
【図１】
2004127273.tif 000003
【図２】
2004127273.tif 000004
【図３】
2004127273.tif 000005
【図４】
2004127273.tif 000006
【図５】
2004127273.tif 000007
【図６】
2004127273.tif 000008
【図７】
2004127273.tif 000009
【図８】
2004127273.tif 000010
【図９】
2004127273.tif 000011
【図１０】
2004127273.tif 000012
【図１１】
2004127273.tif 000013
【図１２】
2004127273.tif 000014
【図１３】
2004127273.tif 000015
【図１４】
2004127273.tif 000016