JP2001306522A - ネットワーク環境へのアクセスを検証する方法およびシステム - Google Patents

Abstract

(57)【要約】 【課題】 ネットワーク内の複数の異なるタイプのエン
ティティについて、エンティティへのアクセス権を管理
し、検証するのに使用される、分散ネットワーク環境で
の管理機能を自動化する方法を提供すること。 【解決手段】 この方法には、ユーザＩＤのリストをコ
ンパイルするステップが含まれ、ユーザＩＤは、少なく
とも１つのシステムと関連する。住所録を取り出し、リ
スト内のデータを、住所録に含まれるデータと比較す
る。リスト内の無効なデータにフラグを立てる。その
後、リスト内のデータと住所録に含まれるデータの比較
の結果に基づいて、ユーザ定義のレポートを生成する。
この方法を実施するシステムおよび記憶媒体も開示され
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク環境
へのアクセスを検証する方法およびシステムに関する。

【０００２】

【従来の技術】多くの組織が現在、ユーザが分散リソー
スにアクセスし、アプリケーションを処理する分散コン
ピューティング環境（ＤＣＥ）に相互接続された複数の
コンピュータを使用している。さまざまなアプリケーシ
ョンを使用して、データ共用、印刷サービス、および分
散ファイル・システムを介するデータベース・アクセス
などの分散サービスを提供することができる。

【０００３】分散ファイル・システムは、データおよび
リソースのより高い可用性、超大規模システム全体にわ
たって情報を共用する能力、およびセキュリティ機構の
使用を介する情報の保護など、独立型ファイル・サーバ
に対する多数の長所をもたらす。また、分散ファイル・
システムは、さまざまなファイル・システムに格納され
たファイルのすべてを、グローバル・ネームスペースに
まとめる。複数のサーバが、そのファイル・システムを
このネームスペースにエクスポートすることができる。
その間に、分散ファイル・システム・ユーザのすべて
が、このネームスペースを共用し、分散ファイル・シス
テム・ファイルのすべてが、すべての分散ファイル・シ
ステム計算機から簡単に使用可能にされる。

【０００４】ＤＣＥが、単にピアツーピアに結合された
２台のコンピュータであるか、数千のユーザを有する広
域ネットワークであるかに無関係に、セキュリティ・シ
ステムが、通常は、ネットワーク上のエンティティ（プ
リンタ、モデム、他のネットワーク、ディレクトリ、フ
ァイル、データなど）へのアクセス権を制限し、ネット
ワークに接続することができる各ユーザを識別するため
に含められる。

【０００５】コンピュータ・ネットワーク上のエンティ
ティへのアクセスの制御は、非常に重要である。本来個
人的なデータもしくは独占的情報または機密情報を含む
データを、ネットワークに接続されたユーザのすべてに
よって自由にアクセス可能または使用可能にしてはなら
ない。たとえば、電子メール・メッセージは、所期の受
取人によってのみアクセス可能にしなければならない。
会社の各従業員に関する詳細を含む個人データ・ファイ
ルは、限られたグループ、たとえば、その会社の人事部
の人間によってのみアクセス可能にしなければならな
い。ファイルの内容の変更、ファイルの読取、またはフ
ァイルの実行を行う権利は、しばしば、ネットワークの
保全性を保守するため、またはプログラムを実行できる
ユーザ数を制限するライセンス交付要件を満足するため
に、指定されたユーザに制限されなければならない。

【０００６】ネットワーク管理者またはシステム管理者
は、通常は、ユーザの定義されたグループを確立し、保
守し、誰がネットワークに接続する権利を有するかを決
定し、ネットワーク上のエンティティに関する各グルー
プおよび個々のユーザの権利を最初に決定する責任を割
り当てられる。グループには、通常は、当初にそれに関
するアクセス権が許可されるエンティティに対する共通
の関係を有する１つまたは複数のユーザが含まれる。た
とえば、ある会社の会計部門の事務員が、いくつかの会
計プログラムおよびいくつかの会計データ・ファイルに
対するすべての権利とそれ以外に対する制限された権利
を有する「Accounting Group（会計グループ）」を構成
することができる。会計部門の長は、通常は、「Accoun
ting Group」のメンバであり、より多くの機密会計デー
タ・ファイルへの完全な権利と極秘会計データ・ファイ
ルへの制限された権利を有する「Accounting Superviso
rGroup（会計管理者グループ）」のメンバでもあること
ができる。

【０００７】グループまたは個々のユーザに与えられる
権利によって、そのグループのメンバまたはそのユーザ
が、システム上の他のエンティティへのアクセスを制御
できるかどうかが決定される。したがって、あるディレ
クトリですべての権利を有するユーザは、ネットワーク
上の他のユーザよる、そのディレクトリへのアクセスお
よびそのディレクトリのサブディレクトリまたはそのユ
ーザがそのディレクトリ内で作成したファイルへのアク
セスを制御することができる。

【０００８】エンティティへのアクセス制御の一形態で
は、アクセス制御項目（ＡＣＥ）の組からなるアクセス
制御リスト（ＡＣＬ）が使用される。ＡＣＬは、ネット
ワーク上のエンティティと関連付けることができる。Ａ
ＣＥには、通常は、ユーザまたはグループの識別子（プ
ラットホーム固有またはオペレーティング・システム固
有）と、そのオブジェクトに関してそのユーザまたはグ
ループに許可される権利または拒否される権利を指定す
るエンコードまたは表現が含まれる。あるエンティティ
上のオブジェクトへのアクセスを求める個々のユーザま
たはグループを、「要求者」と称する。アクセス・マス
クは、エンティティまたはそれが使用される環境もしく
はその両方に関する動作のエンコードを表す。したがっ
て、ＡＣＬによって、誰がそのエンティティへのアクセ
ス権を有するかと、そのアクセスの性質が指定される。

【０００９】より大きいネットワークでは、アクセス管
理は、時間がかかり、大量の人間の介入を必要とする。
通常のシステム管理システムまたはアクセス管理システ
ムは、１つの位置に集中化され、１人の人間または１つ
の部署によって管理される。通常のシステム管理者また
はアクセス管理者は、ＤＣＥ内での使用に関するアクセ
スのシステムを開発し、実施し、継続的に更新する責任
を負う。たとえば、新しいパスワードＩＤに関する要求
は、必要に応じて、個別に評価され、承認（または拒
否）されることが必要である。この処理には、その変更
をシステムに入力する前にさまざまな個人または部署に
よる複数レベルの承認または検討が含まれる可能性があ
り、これが、要求ごとのより長い処理時間になる可能性
がある。さらに、システム管理者またはアクセス管理者
は、組織の必要に応じて、アクセス権を与えるためのシ
ステム判断基準を継続的に更新する必要がある。このデ
ータの手動操作の量が多いほど、エラーが生じる危険性
が高くなる。ＤＣＥ環境でのこのアクセス管理のシステ
ムを容易にし、自動化することが望ましい。

【００１０】

【発明が解決しようとする課題】ネットワーク内の複数
の異なるタイプのエンティティについて、エンティティ
へのアクセス権を管理し、検証するのに使用される、分
散ネットワーク環境での管理機能を自動化する方法であ
る。

【００１１】

【課題を解決するための手段】本発明の例示的実施形態
は、ネットワーク内の複数の異なるタイプのエンティテ
ィに関するエンティティへのアクセス権を管理し、検証
するのに使用される、分散ネットワーク環境での管理機
能を自動化する方法である。この方法には、ユーザＩＤ
のリストをコンパイルするステップが含まれ、ユーザＩ
Ｄは、少なくとも１つのシステムに関連する。住所録を
取り出し、リスト内のデータを、住所録に含まれるデー
タと比較する。リスト内の無効なデータにフラグを立て
る。その後、住所録に含まれるデータとのリスト内のデ
ータの比較の結果に基づいて、ユーザ定義レポートを生
成する。この方法を実施するシステムおよび記憶媒体も
開示される。

【００１２】

【発明の実施の形態】ユーザ識別管理システムは、通常
は、分散コンピューティング環境（ＤＣＥ）内で相互接
続された１つまたは複数のサーバおよび１つまたは複数
のエンティティを含むシステムを介して実施される。本
発明を使用することができる例示的なシステム１０の一
部を、図１に示す。本発明の長所を実現するために必要
ではないが、システム１０は、大きく異なる位置にある
数百台のワークステーションを相互接続する、高速デー
タ回線または無線リンクのいずれかによって異なる地理
的位置が相互接続される広域ネットワークの一部とする
ことができる。図１の簡略化された図では、３つのサー
バ１２、１４、および１６だけが示されており、これら
は、ネットワーク１８によって、２つのワークステーシ
ョン２０および２２と、プリンタ３８に結合される。本
発明が、トークン・リング構成またはスター構成などの
複数のタイプのネットワーク構成上でも使用可能である
ことを、当業者は理解するであろう。ネットワーク・シ
ステムで典型的であるとおり、サーバ１２、１４、およ
び１６のそれぞれには、ワークステーション２０および
２２によってアクセスすることができるデータおよびア
プリケーションを含む複数のファイルが格納される少な
くとも１つのハード・ディスク２４が含まれる。さら
に、各サーバには、モニタ２６が与えられる。特に図示
されてはいないが、各サーバを、サーバの動作の構成お
よび制御に使用されるコマンドおよびデータの入力用の
キーボードに結合することもできる。

【００１３】ワークステーション２０および２２のそれ
ぞれは、ワークステーション内のマザーボード上に配置
される中央処理装置（ＣＰＵ）（共に図示せず）によっ
て実行することができるプログラムを格納するためのハ
ード・ディスク３０を含む汎用コンピュータとすること
ができる。表示画面３２が、ワークステーションのそれ
ぞれに設けられる。ユーザは、キーボード３４またはマ
ウス３６（または他の適当な入力デバイス）を介して、
ワークステーションを制御し、コマンドおよびデータの
入力を供給することができる。ワークステーション２０
および２２のそれぞれは、ネットワーク１８を介してサ
ーバ１２、１４、および１６のいずれにもアクセスする
ことができる。

【００１４】上で説明したように、コンピュータ・ネッ
トワーク上のエンティティへのアクセスの制御が、重要
である。ネットワーク管理者またはシステム管理者は、
ネットワーク内のこれらのエンティティへの他のユーザ
によるアクセスを確立し、保守する責任を負う。ユーザ
識別管理システムは、要求、要求に関する承認、および
これらの要求の実施を、フロント・エンドとしてネット
ワーク・インターフェースを使用する簡単でユーザ・フ
レンドリなツールに構造化するように設計される。

【００１５】ユーザ識別管理システムが確立された後
に、レベル１管理者と称するすべてのアクセス権を有す
る管理者が、ネットワーク許可構造のセット・アップを
開始することができる。下でさらに説明するように、ユ
ーザ識別管理システムは、単一カスタマ・ベースまた
は、各カスタマが複数のグループ／プロジェクトを有す
ることができ、各プロジェクトが複数のシステム識別子
（ＳＩＤ）を有することができ、各ＳＩＤが複数のクラ
イアントを有することができる複数カスタマ・ベースを
サポートすることができる。

【００１６】複数のレベル１管理者を、所与のネットワ
ーク内で指定することができる。さらに、すべてのレベ
ル１管理者が、レベル１ＩＤまたはレベル２ＩＤを作成
または削除するためのアクセス権を有し、他のレベル１
ＩＤまたはレベル２ＩＤのアドレスまたはパスワードを
変更することができる。当初は、レベル１管理者が、ユ
ーザ識別管理システムにログ・オンし、複数レベルにま
たがる許可構造をセット・アップまたは定義する。「カ
スタマ」は、包括的な用語であり、個々の組織の必要と
矛盾しない形でレベル１管理者によって定義することが
でき、その代わりに完全に省略することもできる。たと
えば、複数のカスタマが所望される、より大きいネット
ワークでは、カスタマを、組織内の多数の部署の１つと
して定義することができる。より小さいネットワークで
は、カスタマ・データベースが必要でない場合があり、
完全に省略することができる。任意の数のカスタマを指
定することができる。

【００１７】図２に、管理者が、選択されている特定の
ディレクトリまたはファイルに関するアクセス許可をセ
ットすることができる、ユーザ識別管理システムの「管
理」画面５０を示す。ツール・バー５２によって、そこ
から本発明にアクセス可能であるアプリケーションが識
別される。図２からわかるように、「Admin（管理）」
というラベルを付けられたオプション５４が、ツール・
バー５２から選択されており、複数の追加メニュー・オ
プションが、ドロップ・ダウン・リスト・ボックス（ま
たはプル・ダウン・メニュー）５６に表示され、その４
番目が、「CHANGE CUSTOMERS（カスタマ変更）」と記さ
れたオプション５８である。オプション５８を選択する
ことによって、レベル１管理者は、必要に応じてカスタ
マを追加、変更、または削除することができる。図２に
は、カスタマ・ウィンドウ６０の例が示されており、こ
のウィンドウでは、８つのカスタマ６２が、すでに作成
され、定義されており、８つの事前定義のカスタマ・コ
ード６４が、それぞれ各カスタマに割り当てられてい
る。例示的実施形態では、レベル１管理者だけが、カス
タマの追加または削除を行うアクセス許可を有する。し
かし、レベル１管理者は、レベル２管理者が既存のカス
タマに関する情報を変更するための許可を与えることが
できる。カスタマを追加するには、レベル１管理者が、
図２のカスタマ画面の「ＡＤＤ（追加）」機能６６を選
択する。

【００１８】ウィンドウが表示され（図示せず）、ユー
ザに、カスタマ・コードおよびカスタマ名（共に図示せ
ず）を入力するように問い合わせる。その後、ユーザ
は、「commit（コミット）」ボタン（図示せず）を選択
して、処理を完了する（または、その代わりに、「canc
el（キャンセル）」ボタンを選択してアクションを放棄
する）。カスタマ・コードおよびカスタマ名は、レベル
１管理者によって入力される時に、メイン・ネットワー
ク・ページ（図示せず）に即座に反映される。ここで、
ＳＩＤをこのカスタマに割り当てることができる。

【００１９】ＳＩＤとは、ユーザが図１のネットワーク
１８を介してアクセスすることができるシステム、ＳＩ
Ｄのタイプ、およびそのＳＩＤへのアクセス権を所有す
るか制御する管理者を識別する一意の識別子である。図
３に、レベル１管理者がカスタマに新しいＳＩＤを追加
することができる、ユーザ識別管理システムの「保守」
ウィンドウ６８を示す。レベル１管理者だけが、ＳＩＤ
の追加または削除を行うことができる。しかし、レベル
１管理者は、レベル２管理者に、そのレベル２管理者に
よって制御される既存のＳＩＤに関する情報を変更する
アクセス許可を与えることができる。ＳＩＤを追加する
には、レベル１管理者が、図２のツール・バー５２のＳ
ＩＤオプション７０を選択し、プル・ダウン・メニュー
（図示せず）の「new（新規）」をクリックする。図３
で参照される保守ウィンドウ６８が表示される。レベル
１管理者は、ＳＩＤボックス７２でＳＩＤを識別する一
意の識別子を割り当て、その後、図４の符号９４に示さ
れているように、メイン・ネットワーク・ページに表示
されることが望まれるので、DESCRIPTION（説明）ボッ
クス７４にシステムの説明を入力する。その後、レベル
１管理者は、プル・ダウン・メニュー７６から、このシ
ステムを所有するADMIN ID（管理者ＩＤ）を選択する。
図３に示されているように、ＳＩＤに関する他の情報を
入力することができる。

【００２０】レベル１管理者は、ＴＹＰＥ（タイプ）プ
ル・ダウン・メニュー７８から、システムの３つのタイ
プの１つを選択する。システムのタイプを指定すること
によって、レベル１管理者は、システムにアクセスする
ためのパスワードを分配する方法を制御する。第１のタ
イプのシステムは、新しいＩＤおよびパスワードのリセ
ットを含めて、このシステムにアクセスするためのパス
ワードが所有者のマネージャに行くだけである「実働」
システムである。第２のタイプのシステムは、パスワー
ドを所有者のマネージャおよび所有者の両方に送らなけ
ればならない実働システムを指定する、「ユーザへのパ
スワードを有する実働」システムである。第３のタイプ
のシステムは、システムが実働システムでないことを指
定する非実働システムである。非実働システムでは、パ
スワードは、マネージャと所有者の両方に送られる。そ
の後、レベル１管理者は、CUSTOMER CODE（カスタマ・
コード）プル・ダウン・メニュー８０からの選択によっ
て、ＳＩＤボックス７２で指定された所望のＳＩＤをカ
スタマに割り当てる。

【００２１】システムへの要求は、本明細書で説明する
ように、１つまたは複数の承認者によって承認される。
図３には、義務不履行（delinquent）の承認者に覚え書
きが送られる前に要求が処置なしのままでいられる日数
を指定する第１時間制限８２が示されている。ステージ
１承認者が義務不履行の場合には、そのステージ１承認
者だけが注を受け取る。ステージ１承認者の一部がすで
に承認している場合には、それらのステージ１承認者は
通知を受け取らない。ステージ２承認者が義務不履行者
である場合には、その承認者だけが、通知を受け取り、
ステージ１承認者は通知を受け取らない。この通知機能
が所望されない場合には、第１時間制限８２に０をセッ
トして、この通知を非活動化しなければならない。

【００２２】第２時間制限８４は、完全に承認されずに
要求がキュー内にいられる時間を示す。カウントは、元
の要求日付から開始されるので、このオプションは、第
１時間制限８２より短い日数にすることができない。第
２時間制限８４に達した後に、要求は、キューから削除
される。要求が削除されたことを述べ、まだ必要な場合
には再サブミットするように示す注が、すべての承認者
および要求者に送られる。この機能が所望されない場合
には、第２時間制限８４に０をセットして、この機能を
非活動化しなければならない。

【００２３】レベル１管理者は、任意選択として、「グ
ループ指定機能」８６を選択し、メイン・ネットワーク
・ページに表示されなければならないグループ名を入力
することによって、カスタマ内のグループまたはプロジ
ェクトを定義することができる。図４に複製されたネッ
トワーク・ページでは、ユーザが見るカスタマ・プロフ
ァイル９０の特定の例に、それぞれが１つまたは複数の
ＳＩＤ９４を含む３つのユーザ定義のグループまたはプ
ロジェクト９２が示されている。

【００２４】ＳＩＤを作成する際に、管理者は、所与の
システムについて使用可能であるアクセス・プロファイ
ルも定義する。アクセス・プロファイルによって、ユー
ザまたはシステム内で共通のジョブ要件を共用するユー
ザのグループに許可されるアクセスのレベルが定義され
る。定義することができるアクセス・プロファイルに
は、「メイン（main）」および「アド・オン（add o
n）」の２タイプがある。このアクセス・プロファイル
のタイプの相違は、そのプログラムされた定義にある。
メイン・アクセス・プロファイルは、ユーザＩＤについ
て１つのメイン・アクセス・プロファイルを必要とし、
１つのメイン・アクセス・プロファイルを選択すること
だけが許容される。アド・オン・アクセス・プロファイ
ルでは、ユーザＩＤについて０個、１個、または複数の
アド・オン・アクセス・プロファイルを選択することが
許容される。１つのユーザＩＤについて１つのアクセス
・プロファイルだけを望むＳＩＤ（業務の分離のために
実働環境でしばしば使用される）では、メイン・アクセ
ス・プロファイルだけが定義され、したがって、ユーザ
ＩＤが複数のアクセス・プロファイルを得ることができ
ない。ジョブ要件のほとんどを含むがいくつかのアクセ
ス・プロファイルの追加を許容するアクセス・プロファ
イルを有するＳＩＤでは、ジョブ・レベル・プロファイ
ルに「メイン」、追加の権限プロファイルに「アド・オ
ン」を使用することができる。ＳＩＤが、アクセス・プ
ロファイルの組合せを必要とする場合には、管理者は、
「アド・オン」を使用することができ、したがって、ア
クセス・プロファイルのすべての組合せの選択が可能に
なる。「カテゴリ」アクセス・プロファイルを使用する
場合には、下で説明するように、承認者を、「承認者の
定義」と称する機能を介してカテゴリによって定義する
ことができる。

【００２５】図５に、これによって管理者が新しいアク
セス・プロファイルをカスタマ・ネットワーク・ページ
に追加できる、管理画面５０内のメイン・アクセス・プ
ロファイル・ウィンドウ１００を示す。新しいメイン・
アクセス・プロファイルを追加するには、管理者が、ま
ず、管理画面５０の左側に配置されたＳＩＤメニュー１
０２に表示された所望のＳＩＤを強調表示し、その後、
ツール・バーのＳＩＤオプション７０を選択し、その
後、プル・ダウン（図示せず）の「profiles（プロファ
イル）」を選択し、最後のプル・ダウン・メニュー（図
示せず）の「main（メイン）」（図示せず）を選択す
る。図５のメイン・アクセス・プロファイル・ウィンド
ウ１００が、管理者に提示される。その後、管理者は、
「ADD（追加）」ボタン１０８を選択し、図６の「ADD A
NEW PROFILE（新規プロファイルの追加）」ウィンドウ
１１０が表示される。管理者は、カスタマ・ネットワー
ク・ページでのアクセス・プロファイルの提示をソート
するのに使用されるソート・キー１１２を入力する。ア
クセス・プロファイルは、数によってソートすることが
できる。ＳＩＤについてカテゴリが使用される場合に
は、アクセス・プロファイルが、各カテゴリ１１４内で
数によってソートされる。「カテゴリ」とは、包括的な
用語であり、組織の必要に従って管理者が定義すること
ができる。その後、管理者は、「PROFILE NAME（プロフ
ァイル名）」ボックス１１６にテクニカル・アクセス・
プロファイル名、「DESCRIPTION」ボックス１１８にア
クセス・プロファイルの説明を入力する。アクセス・プ
ロファイルのテクニカル名は、そのＩＤを作成したシス
テムによって認識される名前である。アクセス・プロフ
ァイルの説明は、管理者が説明と共にテクニカル名を表
示することを望まない場合にカスタマ・ページに反映さ
れるものであり、管理者が説明と共にテクニカル名を表
示することを望む場合には、管理者は、図３で説明した
保守ウィンドウ６８を介してそれを行うことができる。

【００２６】その代わりに、管理者は、「main」（図示
せず）を選択するのではなく、図５で説明したプル・ダ
ウンから「add on（アド・オン）」を選択することによ
って、「メイン」アクセス・プロファイルの代わりに
「アド・オン」アクセス・プロファイル（図示せず）を
追加することができる。アクセス・プロファイル提示機
能のもう１つの特徴が、カスタマ・ネットワーク・ペー
ジに提示されるテキストの、色、テキスト・スタイル、
およびサイズをカストマイズする能力ならびにヘッダま
たはカラムを含める能力である。これらの効果を達成す
るために、図５で説明したメインまたはアド・オンのア
クセス・プロファイル・メニューの通常テキスト区域で
テキスト・タグを使用することができる。

【００２７】ＤＣＥ組織が、ＳＩＤ内の複数クライアン
ト構造の使用を望む場合、図７に、そのようなクライア
ントの構成のための管理画面５０を示す。「クライアン
ト」とは、包括的な用語であり、組織の必要に従って管
理者が定義することができる。管理者は、まず、管理画
面５０の左側に配置されたＳＩＤメニュー１０２から所
望のＳＩＤを強調表示し、その後、ツール・バー５２の
ＳＩＤオプション７０を選択し、その後、プル・ダウン
・メニュー１２８の「CLIENTS（クライアント）」１２
６を選択する。ポップアップ・ウィンドウ１３０が表示
され、管理者に、クライアント・コード１３２およびク
ライアント名１３４を入力するように問い合わせる。ク
ライアント名１３４は、即座にコンパイルされ、メイン
・ネットワーク・ページのメイン・クライアント・リス
ト見出し（図示せず）の下に反映される。クライアント
・リストに対する更新は、クライアント名１３４のフィ
ールド「CLIENT NAME」を選択し、所望の情報を直接に
入力することによって完了することができる。同様に、
クライアント名１３４のフィールド「CLIENT NAME」を
選択し、「DELETE（削除）」１３６を選択することによ
って、クライアント名を削除することができる。確認ウ
ィンドウが表示され、管理者は、「ＯＫ」を選択してク
ライアントの除去を確認する（図示せず）。

【００２８】ユーザ識別管理システムのもう１つの特徴
が、承認者のさまざまなステージおよびタイプを介する
承認セットアップのために提供される変数オプションで
ある。用語「承認者」および「オーソライザ」は、交換
可能に使用される。承認者の２つのステージは、ネット
ワーク情報に対する２ステップ複数レベル許可を提供す
るために存在する。ＳＩＤは、１ステージ承認または２
ステージ承認のいずれかを含むように構成することがで
きる。さらに、ステージ１承認者は、指定されたステー
ジ２承認者の前に、許可に関する要求を受け取る。ステ
ージ１承認者が要求を拒否する場合には、ステージ２承
認者は、要求を受け取らない。さらに、承認の各ステー
ジ内に、複数のタイプの承認者すなわち、General（一
般）、Category（カテゴリ）、Client（クライアン
ト）、Delete（削除）、およびChange（変更）が存在す
る。削除承認者および変更承認者は、１ステージ承認だ
けを使用することができ、他のタイプの承認者は、２ス
テージ承認方法を使用することができる。一般承認者
は、要求が何であっても、承認リスト上にある。カテゴ
リ承認者は、図５および図６に示されているように、ジ
ョブ・プロファイルがカスタマ内のカテゴリにグループ
化される場合に使用される。カテゴリ承認者は、その承
認者が指定されているジョブ・プロファイルが要求者に
よって選択された場合に、承認リスト上にある。システ
ムが、複数クライアント構造である場合には、クライア
ント承認者を、クライアントごとに指定することができ
る。クライアント承認者は、要求者が要求に関してその
クライアントを選択した場合に限って、承認リスト上に
ある。削除承認者は、システムについて指定された唯一
の承認者がカテゴリ承認者である場合を除いて、任意選
択である。削除要求は、カテゴリの選択を必要としない
ので、削除承認者を定義しなければならない。一般承認
者またはクライアント承認者がすでに存在する場合、削
除承認者は、これらの承認者に追加される。変更承認者
は、変更承認のみについて指定される。上の承認タイプ
のそれぞれが、単一の承認者、それぞれが承認しなけれ
ばならない複数の承認者、または承認者のどれかが承認
すると同時に承認が完了することを示す「どれか１つ
（any one of）」条件（たとえばブールＯＲ）を用いて
リンクされた複数の承認者を有することができる。「an
d」条件（承認者のメールＩＤの間の「＆」を使用して
入力される）が選択される場合、各承認者が、それ自体
の一意のパスコードを受け取る。「or」条件（承認者の
メールＩＤの間の「｜」を使用して入力される）が選択
される場合、「or」されるすべての承認者が、同一のパ
スコードを受け取る。上のすべてを、任意の組合せで使
用することができる。

【００２９】図８に、さまざまな承認者を指定する際に
使用される管理画面５０を示す。承認者を追加するため
に、管理者は、まず管理画面５０の左側に配置されたＳ
ＩＤメニュー１０２に表示された所望のＳＩＤを強調表
示し、次にツール・バー５２のＳＩＤオプション７０を
選択し、次にプル・ダウン・メニュー１５０の「AUTHOR
IZERS（オーソライザ）」１４８を選択し、最後のプル
・ダウン・メニュー１５２でオーソライザのタイプを選
択する。一般（GENERAL）承認者１５４を選択すると、
承認の適当なステージに関する承認者ボックス１６６で
の承認者の直接入力を可能にするウィンドウ１６０が表
示される。この承認者を更新するには、管理者が、承認
者ボックス１６６を選択し、正しい情報をその中に入力
し、「COMMIT」ボタン１６８を選択して、行った変更を
確認する。その後、管理者は、適当な承認者ステージ・
ボックスに承認者の完全な電子メール・アドレスを入力
し、ステージ１の承認者ボックス１６６またはステージ
２の承認者ボックス１４６のいずれかを選択する。複数
の承認者が所望される（たとえばブールＡＮＤ条件）場
合には、管理者は、承認者ボックス１６６または１４６
に「電子メール＆電子メール」を入力する。一方の承認
者が承認する（たとえばブールＯＲ条件）場合には、承
認者ボックス１６６または１４６に「電子メール｜電子
メール」を入力する。文字列は、任意の組合せで連結す
ることができ、たとえば、「電子メール１｜電子メール
２＆電子メール３＆電子メール４」などとすることがで
きる。他のタイプの承認者は、同様に構成することがで
き、これ以上説明しない。

【００３０】ユーザ識別管理システムは、すべての承認
が完了した後に要求を自動的に完了するのに使用される
ように設計されている。しかし、承認された要求を自動
的に処理せず、手動完了を要求するように構成すること
もできる。自動的に処理されるすべての要求が、介入を
一切必要とせずに、キューに入れられ、キューから除去
される。しかし、キューに入れられた要求を管理しなけ
ればならない理由が多数存在する。キューには２つのタ
イプがある。第１のキューには、許可を保留されている
すべての要求が含まれる。このキューの操作は、失われ
た承認コード、故意でなしに繰り返して入力された要求
などに起因するものとすることができる。第２のキュー
には、承認処理を完了し、完全に承認され、要求の実行
を待っている要求が含まれる。システムが、自動実行用
にセット・アップされ、要求がエラーなしに完了する場
合には、そのレコードは、このキューで数分の１秒だけ
を過ごす。しかし、要求がエラーを有する（作成中にプ
ロファイルが見つからないなど）場合、またはシステム
が自動実行用にセット・アップされない場合には、要求
は、このキューから手動で操作されなければならない。
許可保留中キューの管理を助けるもう１つの機能が、そ
の設定および使用を図３の「ＳＩＤの追加」部分の警告
フィールドである第１時間制限８２および第２時間制限
８４で示したキュー警告設定である。この機能を用いる
と、許可の要求が指定された時間の間に作用されない場
合の、覚え書きの通知または保留中要求の除去をセット
・アップできるようになる。

【００３１】要求キューの管理は、図９に示されたキュ
ー管理機能を介して使用可能である。第１のキューにア
クセスするには、管理者が、まず、管理画面５０の左側
に表示されたＳＩＤ１５６を強調表示し、次にツール・
バー５２のＳＩＤオプション７０を選択し、プル・ダウ
ン・メニュー１２８の「USER QUEUE（ユーザ・キュ
ー）」１９０を選択し、許可を保留されている要求の
「MAINTAIN（保守）」１２９を選択する。「MAINTAIN U
SER REQUESTS（ユーザ要求の保守）」ウィンドウ１５８
が表示され、このキューにあるすべての要求の要約が表
示される。要約の最初のフィールド１６２には、主パス
コードが含まれる（承認者に送られるパスコードは、承
認に必要な追加の４文字を有する）。次のフィールド１
６４には、ＳＩＤが含まれ、その次のフィールド１７０
には、要求のタイプ（ADD（追加）、CHANGE（変更）、R
ESET（リセット）など）が含まれる。次のフィールド１
７２には、ユーザ情報が含まれ、その次のフィールド１
７８には、ユーザのメール・アドレスが含まれ、最後の
フィールド１８０は、状況（PENDING（保留中）また
は、第２ステージの場合のPENDING 2のいずれか）であ
る。項目を削除するには、管理者が、項目を強調表示
し、「DELETE」１７４をクリックする。確認ウィンドウ
が表示され、管理者は、「confirm（確認）」を選択す
る（どちらも図示せず）。完全なレコードを見るには、
管理者が、「SHOW DETAILS（詳細を表示）」１７６をク
リックするか、項目をダブル・クリックする。その後、
レコード全体１８２が、図１０に示されているように表
示される。使用されていないフィールドには、空白が表
示される。要求がサブミットされた日付１８４ならびに
割り当てられた承認者およびそのパスコードのすべて１
８６を、ここで得ることができる。承認者を見る時に
は、メールＩＤのとなりに完全なパスコードを有する承
認者だけが、承認していない承認者である。たとえば、
図１０からわかるように、符号１８６の「STAGE 2 APPR
OVERS」にリストされた第２の承認者が、まだレコード
全体１８２で示される要求を承認していない。

【００３２】図１１からわかるように、管理者は、管理
画面５０の左側に表示されたＳＩＤ１８８を強調表示
し、その後、ツール・バー５２のＳＩＤオプション７０
を選択し、その後、プル・ダウン・メニュー１２８の
「USER QUEUE」１９０をクリックすることによって、キ
ュー管理機能の第２のキューにアクセスする。その後、
管理者は、完了を保留されている要求に関する「COMPLE
TE-REJECT（完了／拒否）」１９２機能を選択する。管
理者は、「REFRESH（最新表示）」１９６キーを選択す
ることによって、このキューの現在の要求に画面を更新
することができる。要求を再処理するには、管理者が、
キューの要求１９４を強調表示し、「REPROCESS（再処
理）」１９８を押し下げる。これによって、まだ作成さ
れていない要求がシステムに送り返される。「COMPLETE
（完了）」２５８は、ある項目についてすべての項目が
手動で完了された後に使用される。これによって、未解
決の注のすべてが送られ、要求がキューから除去され、
状況に手動完了がセットされる。「REJECT（拒否）」２
６０機能を用いると、管理者が、すべての承認者が承認
した要求を拒否できるようになる。これは、コメント・
フィールドに、処理することができない特殊な指示があ
る場合に必要になる可能性がある。最後に、「SHOW DET
AILS」２６２を用いて、レコード全体を表示することが
できる。

【００３３】図１２に、新規ユーザＩＤまたは更新され
たユーザＩＤの処理および承認の処理を示す。ユーザ
が、３０２で要求をサブミットする。ユーザ識別管理シ
ステムは、３０４で、住所録から入手可能な情報のすべ
てを事前に書き込む。要求者情報を突きとめることがで
きない場合には、既存ユーザが、要求者を保証しなけれ
ばならない（図示せず）。ステージ１の承認通知を送る
３０４。承認者は、３０６で、そのアカウントの承認ペ
ージを入力し、この要求に関する１回限り使用の承認コ
ードを入力する。承認者は、要求を再検討し、その要求
の承認または拒否のいずれかを行う。要求が拒否される
場合には、流れはステップ３１２に進み、承認者が、拒
否の理由または他のコメントを入力することができる。
承認者のどれかが要求を拒否する場合、要求が拒否され
たことの通知が３１２で生成され、承認者によって入力
された理由と共に、他のすべての承認者（そのステージ
の承認者のみ）および要求者に送られる。この要求に関
する未解決の承認コードのすべてが、３１４で無効化さ
れる。

【００３４】ステップ３０８で、ステージ１承認者のす
べてが応答したかどうかを判定する。そうでない場合に
は、流れはステップ３０６に進み、そこで処理を継続す
る。ステージ１承認のすべてが完了した後に、ステップ
３０９で、ステージ２承認者の存在を判定する。ステー
ジ２承認者がない場合には、流れは、本明細書で説明す
るステップ３２０に進む。ステージ２承認者が存在する
場合には、流れはステップ３１６に進み、そこで、ステ
ージ２承認者に通知を送る。ステージ２承認処理は、ス
テップ３１７および３１８で、ステップ３０６および３
０８に類似する形で実行される。

【００３５】ステップ３１８で承認が完了した後に、ユ
ーザ識別管理システムは、ステップ３２０で、システム
上のＩＤを作成または更新する。３２１で、ＩＤが成功
裡に完了したかどうかを判定する。そうである場合に
は、流れはステップ３２４に進み、そこで、通知がシス
テム上で分配される。たとえば、新規ユーザがＳＩＤへ
のアクセスを許可されたことの通知を送ることができ
る。３２６で、要求にコメントがあるかどうかを判定す
る。ない場合には、流れはステップ３２８に進み、そこ
で、処理が終了し、要求が完了としてマークされる。３
２１でＩＤが成功裡に完了しなかった場合、または３２
６で要求にコメントがある場合、流れはステップ３２５
に進み、そこで、管理者に通知を送る。管理者は、問題
を解決し、コメントに対処することができる。ステップ
３２７が完了した後に、流れはステップ３２８に進み、
要求が「完了」とマークされる。

【００３６】上で説明した、承認者を確立し、承認を実
行する処理は、図１に示されたものなどのシステムで実
施することができる。そのようなシステムでは、たとえ
ばワークステーション２０によって実施される要求者
が、アプリケーション、データなどを含むことができる
サーバ１２などのネットワーク上のエンティティへのア
クセスを望む。要求者システムであるワークステーショ
ン２０が、アクセスの要求をサブミットし、この要求
は、サーバ１４などの管理サーバに向けることができ
る。管理サーバであるサーバ１４は、この要求を適当な
承認者に転送し、この承認者は、たとえばワークステー
ション２２によって実施することができる。管理サーバ
であるサーバ１４は、システム識別子のデータベースに
アクセスして、どの承認者が、要求者がアクセスを求め
ているエンティティに関連するかを判定する。このデー
タベースは、管理サーバであるサーバ１４の一部または
ワークステーション２０または２２の一部もしくはその
両方とすることができる。その代わりに、これらのデー
タベースを、外部に格納し、リモート機能呼出しによっ
てアクセスすることができる。承認者システムであるワ
ークステーション２２は、上で説明したように、管理サ
ーバであるサーバ１４に応答を供給することによって、
エンティティへのアクセスを許可する。

【００３７】管理者は、サーバから直接に、または、サ
ーバに結合されたワークステーションを介して、システ
ムを構成することができる。管理者が、ＳＩＤに対する
変更を開始する時に、ユーザ識別管理システムが、実行
され、管理者にパスコードを問い合わせる。その後、ユ
ーザ識別管理システムは、承認された管理者および対応
するパスコードのリストをアプリケーション・サーバに
問い合わせ、このリストを検査して、その管理者のアク
セス許可を検証する。管理者が、適当なアクセスのレベ
ルを有する場合に、その管理者は、その管理者に割り当
てられたＳＩＤに対する複数の変更を開始することがで
きる。ＳＩＤに対するさまざまな承認者を定義し、選択
された承認者のそれぞれに電子メール・アドレスを関連
付けることによって、管理者は、アクセスに関する要求
の実行のシステムを自動化することができる。たとえ
ば、ユーザが、システムへのアクセスを要求する時に、
ユーザ識別管理システムは、そのシステムについて定義
されたアクセス許可および識別子を含むデータベースな
らびにこれらのアクセス許可に割り当てられた承認者を
取り出し、そのユーザに割り当てられたアクセス権を検
証する。ユーザ識別管理システムは、その後、許可のた
めに指定された承認者にこの要求を送るか、キューに要
求情報を格納し、要求はそこで次のアテンションを待
つ。このキューは、ネットワーク内の１つまたは複数の
サーバに格納することができる。

【００３８】上の機能のほかに、ユーザ管理識別システ
ムは、システム・ユーザに関する最新情報を管理し、保
持する組織の能力の援助を提供する。このオプション
は、再検証ツールを介して使用可能になる。再検証ツー
ルは、ユーザ・アクセスがまだ必要であることを周期的
に確認する自動化された方法を提供する。再検証ツール
を用いると、管理者が、定義されたシステムまたは保管
されたファイルから直接にユーザ情報をロードできるよ
うになる。会社の住所録と共にその情報を使用すること
によって、ユーザ識別管理システムの再検証ツールは、
情報レポートを作成し、通知を作成し、通知のメールを
送り、応答状況を追跡し、覚え書き通知を送り、応答し
ていないグループをロックする。使用可能なオプション
には、１つのシステムまたはクライアントに対する実行
または多数に対する実行を可能にすること、ある形式の
アドレス（識別）が欠けているレコードのレポートの生
成、システムまたはクライアントでリストされているが
住所録内で見つからないユーザＩＤのレポートの生成、
「報告先（reports to）」によってグループ化されたユ
ーザ情報のレポートの生成、指定された個人またはアド
レスに送られるリリース・ノートの生成が含まれる。

【００３９】再検証ツールにアクセスするには、管理者
が、図１３の管理画面のツール・バー５２の「Tools
（ツール）」を選択し、その後、プル・ダウン・メニュ
ーの「REVERIFICATION（再検証）」２０２を選択する。
再検証ウィンドウ２０４が表示される。再検証ツールの
機能を使用するには、管理者が、まず、再検証が所望さ
れるユーザのグループを定義しなければならない。ユー
ザのグループは、システムまたはクライアントによって
編成することができる。ユーザのグループを定義するに
は、管理者が、再検証ウィンドウ２０４のツール・バー
２０６から「USERS（ユーザ）」２０５を選択し、その
後、プル・ダウン・メニュー（図示せず）の「From sys
tem（元のシステム）」を選択する。図１４のログオン
・ウィンドウ２０８が表示される。その後、管理者は、
収集されるシステムまたはクライアントに関する情報を
入力する。管理者は、ユーザ情報にアクセスするために
ＩＤ２１０およびパスワード２１２を入力しなければな
らない。すべての情報を入力した時に、管理者は「SUBM
IT（サブミット）」２１４をクリックする。ユーザ識別
管理システムは、システムから情報を取り出し、図１５
に示されている、システムから引き出した情報の未加工
テーブル２１３を作成する。完了の後に、図１３および
図１４に示された処理を繰り返すことによって、追加の
クライアント情報またはシステム情報を、追加するか、
現在のリストと共にグループ化することができる。

【００４０】図１６を参照すると、現行リストをクリア
する処理が示されている。管理者は、ツール・バー２０
６の「USERS」２０５をクリックし、その後、プル・ダ
ウン・メニューの「CLEAR（クリア）」２１６をクリッ
クする。操作されるすべての情報がコンパイルされた時
に、管理者は、「VERIFY（検証）」オプション２１８を
実行し、これによって、各ユーザＩＤ所有者を住所録に
対して検査して、彼らがまだ雇用されているかどうかを
検証する。この機能が実行される際に、「USERNAME（ユ
ーザ名）」２２０フィールドおよび「MANAGER NAME（マ
ネージャ名）」２２２フィールドが、再検証ウィンドウ
２０４に取り込まれる。欠けているデータまたは無効な
データがあるユーザＩＤは、赤で強調表示される（図示
せず）。訂正を完了することができ、継続する前に上の
ステップが繰り返される。検証機能が完了し、システム
情報が望み通りになった時に、図１７に示された再検証
レポート機能を使用することができる。

【００４１】例示的レポートの１つが、マネージャに、
そのマネージャによって所有されるユーザＩＤのリスト
と各ユーザのアクセス情報とを含む再検証ノートが送ら
れる、メール・レポートである。図１７に、再検証ノー
トの生成のための管理者画面を示す。図１８に、受取側
のマネージャが見る再検証ノートを示す。マネージャ
は、ユーザ情報の正確さおよび最新性を検証し、必要な
変更のすべてをサブミットすることを求められる。マネ
ージャには、彼らがその間に応答しなければならない指
定された時間制限を与えることもできる。マネージャへ
のノートに、パスコードが含まれる。従業員リストを検
証するために、マネージャは、再検証通知に含まれるネ
ットワーク・ページへのリンクを活動化し、これによっ
て、彼らのパスコードが自動的に登録される（いずれも
図示せず）。このネットワーク・ページで確認２７０を
入力することによって、再検証完了が登録され、日付が
記録される。１つまたは複数のマネージャが、所定の時
間以内に再検証ノートに応答しない場合には、管理者
は、図１７に示されているように、再検証ウィンドウ２
７４の「REPORT（レポート）」２７２を選択し、その
後、プル・ダウン・メニューの「MAIL（メール）」２７
６を選択し、その後、「POSITIVE（肯定）」２７８およ
び「2ND NOTICE（第２通知）」２８０を選択することに
よって、第２通知を実行することができる。これによっ
て、まだ検証してないマネージャだけに第２通知が送ら
れ、これには、元の情報のすべてが含まれる。第２通知
では、管理者によって変更可能な、もう１つの制限付き
応答期間が与えられる。第２期間の後に、管理者は、第
２通知処理を繰り返すか、ロックダウン（すなわち、ア
クセス権の否認）を実行するかを選択できる。ロックダ
ウンを実行するには、管理者が、USERS、lockを選択
し、検証の実行コードを入力する（図示せず）。その代
わりに、第２時間期間が満了した後に、自動ロックダウ
ンを実行するようにシステムを構成することができる。
ロックダウンによって、まだ検証されていないすべての
ＩＤのターゲットＳＩＤに対するロックが作成される。
未解決のマネージャからの後続の検証によって、彼らの
従業員ＩＤが自動的にロック解除される。図１９に、ど
のマネージャが所定の期日までに応答したかと未解決の
ノートを検証するために管理者がコンパイルすることが
できる再検証状況レポートの例を示す。この情報には、
マネージャがノートに応答した実際の日付が含まれ、管
理者は、図１９に示されたネットワーク状況ページから
この情報を入手可能である。マネージャが、所定の時間
以内にこの要求に応答しない場合には、このマネージャ
によって所有されるすべてのユーザＩＤが、システムか
ら除去される。その場合には、アクセスに関する新しい
要求を開始しなければならない。

【００４２】上で説明した再検証処理は、図１に示され
たものなどのシステムで実施することができる。そのよ
うなシステムでは、通知を送る装置を、ワークステーシ
ョン２０などの通知を受け取る装置に通知を発行するサ
ーバ１４によって実施することができる。上で説明した
ように、通知によって、ユーザがシステム上のエンティ
ティ（たとえばサーバ１２）へのアクセスを許可される
ことの再検証が要求される。管理サーバであるサーバ１
４は、システムに関連するユーザＩＤを含むデータベー
スおよび会社の住所録にアクセスする。データベース
は、管理サーバであるサーバ１４の一部またはワークス
テーション２０または２２の一部もしくはその両方とす
ることができる。その代わりに、これらのデータベース
を、外部に格納し、リモート機能呼出しによってアクセ
スすることができる。管理サーバであるサーバ１４は、
ユーザＩＤを住所録と比較して、個人が会社を去ったか
どうかなどを判定する。管理サーバであるサーバ１４
は、通知を送る装置として働き、ワークステーション２
０（すなわち、通知を受け取る装置）に通知を送る。上
で説明したように、通知を受け取るものは、通知にリス
トされたユーザのアクセス権を確認しなければならな
い。これは、通知を受け取る装置（すなわちワークステ
ーション２０）が、通知を送る装置（すなわち管理サー
バであるサーバ１４）に応答を送ることによって達成さ
れる。

【００４３】再検証ツールのほかに、ユーザ識別管理シ
ステムは、管理者が、情報検索のためにデータベースに
アクセスでき、測定データを収集できるようにする、ロ
グ・ビューア・ツールを備える。図２０に、どのように
して管理者がログ・ビューア・ツールを使用してデータ
ベースを検索できるかを示す。管理者は、まず、管理画
面５０のツール・バー５２の「TOOL（ツール）」機能２
００を選択し、その後、プル・ダウン・メニューの「LO
G VIEWER（ログ・ビューア）」２２６を選択する。ログ
・ビューア・ウィンドウ２２７が表示される。検索の有
効範囲または収集される測定値は、可変である。これ
は、１つのＳＩＤ上の１つのクライアントに制限するこ
とも、使用可能なすべてのＳＩＤ上のすべてのクライア
ントにすることもできる。ログ・オンしているadmin ID
からアクセス可能なすべてのＳＩＤが、「ＳＩＤ」とい
うラベルを付けられた、ログ・ビューア・ウィンドウ２
２７内に配置されたスクロール可能なサブウィンドウ２
２８にリストされる。単一のＳＩＤ、複数のＳＩＤ、ま
たはＳＩＤのブロックを選択することができる。１つの
ＳＩＤを選択するには、管理者が、所望のＳＩＤをクリ
ックする（図示せず）。そのＳＩＤが強調表示される。
複数のＳＩＤを選択するには、管理者が、所望のＳＩＤ
を選択している間にキーボードの「Ctrl」キーを押し下
げる（図示せず）。選択されたＳＩＤのそれぞれが、強
調表示される。管理者は、範囲の上端の所望のＳＩＤを
クリックし、キーボードの「Shift」キーを押し下げ、
そのままに保ち、範囲の下端のＳＩＤを選択することに
よって（図示せず）、ＳＩＤの範囲を選択することもで
きる。２つのＳＩＤの間のすべてのＳＩＤが強調表示さ
れる。

【００４４】１つのＳＩＤだけが選択される場合には、
検索を、特定のクライアントにさらに制限することがで
きる。これを行うために、管理者は、まず、上で示した
ようにサブウィンドウ２２８にリストされる所望のＳＩ
Ｄを選択し、その後、「ALLCLIENTS（全クライアン
ト）」とマークされたボックス２３０のチェックを除去
し、その後、「REFRESH CLIENTS（クライアント最新表
示）」ボタン２３２をクリックする。そのＳＩＤについ
てユーザ識別管理システム内で定義されているすべての
クライアントが、「CLIENTS」ボックス２３４に表示さ
れる。管理者は、ＳＩＤの選択について上で説明したも
のと同一の方法を使用して、検索に含まれるクライアン
トを選択する。

【００４５】ＳＩＤまたはクライアントを選択した後
に、管理者は、「SEARCH（検索）」ボタン２３６をクリ
ックする。図２１のポップアップ・ウィンドウが表示さ
れる。行うことができる検索には、５つの主なタイプが
ある。「USERID」フィールド２３８を用いて、検索を特
定のユーザＩＤに制限することができる。管理者は、こ
のＵＳＥＲＩＤフィールド２３８に検索用のユーザＩＤ
を入力する。ユーザＩＤが定義されない場合には、この
ＵＳＥＲＩＤフィールド２３８は、すべてのユーザＩＤ
が選択されることを示す「％」ワイルドカード記号を除
いて、空白にすることができる。次に、要求のタイプを
選択する。このリミッタは、所与の期間内に要求された
パスワード・リセットの回数など、情報に関する統計の
収集に有用である。検索に要求タイプを含めるには、
「TYPES OF REQUESTS TO SHOW（表示する要求のタイ
プ）」セクション２４０の５つのボックスの１つをチェ
ックしなければならない。第３のセクションである「ST
ATUS OF REQUESTS TO SHOW（表示する要求の状況）」２
４２は、選択されたＳＩＤまたはクライアント内のすべ
ての要求の現在の状況を判定するのに使用される。この
セクションの１つまたは複数のボックスを選択すること
ができる。「DATE RANGE（日付範囲）」セクション２４
４を用いて、管理者が、指定された日付範囲内の状況に
選択を制限することができる。たとえば、特定の月の情
報を集めるには、管理者が、所望の月の最初の日を、指
定されたフォーマットで、「FROM」行２４８に入力し、
所望の月の最後の日を、「TO」行２５０に入力する。TO
行２５０を空白にすると、現在の日付が選択される。検
索機能の最後のオプションが、「GROUP BY USERID（ユ
ーザＩＤによるグループ化）」ボックス２５２である。
管理者は、検索の結果を、デフォルトの「発生順」ソー
トではなくユーザＩＤによってアルファベット順に提示
しなければならない場合に、このオプションを選択す
る。

【００４６】検索に関する選択を行った後に、管理者
は、「SEARCH」ボタン２５４を選択して実行する。ユー
ザ識別管理システムは、判断条件に一致するすべての項
目の要約を作成し、結果を画面上にリストする。各要求
が検索によって定義される特定の状況に達した時刻、要
求が承認されるまでの全時間、要求を完了するまでの全
時間、および検索によって定義される要求の現在の状況
（図示せず）などの、さまざまな情報が表示される。管
理者は、要約リスティングの項目をダブルクリックし
て、その項目の完全な詳細を表示することができる。管
理者は、検索で見つかった要求の総数、検索内の全要求
の承認の平均時間、要求完了の平均時間、および他の同
様のタイプの情報（図示せず）など、検索結果にリスト
された全レコードの要約状況を得ることもできる。新し
い検索を実行するには、管理者が、図２０のログ・ビュ
ーア・ウィンドウ２２７の「Clear（クリア）」ボタン
２５６をクリックし、その後、上で説明したように「SE
ARCH」ボタン２３６を選択する。管理者は、上で説明し
た図２１のものと同一のステップを繰り返して、検索を
定義する。

【００４７】ユーザ識別管理システムのもう１つの有用
な特徴が、第三者承認を用いずにユーザが即座にパスワ
ードをリセットできるようにするパスワード・リセット
機能である。あるシステムは、不正なパスワードが複数
回入力された場合（たとえば、誤ったパスワードによる
３回のログインの試行）に、ＩＤおよびパスワードを使
用不可にする。これは、システムへの許可されないアク
セスを防ぐセキュリティ機能である。パスワード・リセ
ット機能を用いると、管理者が定義した情況でのパスワ
ード・リセットの自動承認が可能になる。図２２に、パ
スワードをリセットする処理を示す。ユーザは、４００
で要求をサブミットする。４０２で、ユーザ識別管理シ
ステムが、システムを検査して、現在のユーザＩＤが存
在することを検証する。ＩＤが存在しない場合には、流
れはステップ４０４に進み、ここで、ＩＤが存在しない
ことを示す通知をユーザに即座に送り、４０６で要求処
理を終了する。ＩＤが存在する場合には、ユーザ識別管
理システムが、データベース（図示せず）からユーザ情
報を取り出し、４０８でその情報をユーザに表示する。
４１０で、ユーザが、パスワード・リセットの要求をサ
ブミットする。システムは、４１２で、要求を受け取
り、ＩＤの所有者に承認通知を送る。ＩＤの所有者は、
システム構成に応じて、実際のユーザとするか、その代
わりにユーザのマネージャとすることができる。４１４
で、要求が承認されたかどうかを判定する。ＩＤの所有
者が要求を承認しない場合には、４１６で要求処理を終
了する。要求が承認される場合には、流れはステップ４
１８に進み、ここで、システムが、そのシステム上でパ
スワード・リセットを実行し、必要であれば、ＩＤをロ
ック解除する。ステップ４２０で、リセットが成功裡に
完了したかどうかを判定する。そうである場合には、流
れはステップ４２２に進み、ここで、システムを介して
通知を配布する。たとえば、ユーザのパスワードがリセ
ットされたことの通知を、ユーザのマネージャまたは管
理者に送ることができる。４２４で、要求にコメントが
存在するかどうかを判定する。そうでない場合には、流
れはステップ４２６に進み、ここで、処理が終了し、要
求が「完了」としてマークされる。４２０でリセットが
成功裡に完了しなかった場合、または、４２４で要求に
コメントが存在する場合には、流れはステップ４２８に
進み、ここで、管理者に通知を送る。管理者は、問題を
解決し、コメントに対処することができる。ステップ４
３０が完了した後に、流れはステップ４２６に進み、要
求が「完了」としてマークされる。

【００４８】上で説明したパスワード・リセット処理
は、図１に示されたものなどのシステムで実施すること
ができる。そのようなシステムでは、要求元装置を、サ
ーバ１４などの承認する装置にパスワード・リセットの
要求を発行するワークステーション２０によって実施す
ることができる。上で説明したように、パスワード・リ
セットの要求をサブミットすると、ユーザのパスワード
がロック解除される。承認する装置（すなわちサーバ１
４）は、ユーザＩＤを含むデータベースにアクセスし
て、そのユーザＩＤの存在を確認する。このデータベー
スは、サーバ１４の一部またはワークステーション２０
または２２の一部もしくはその両方とすることができ
る。その代わりに、これらのデータベースを、外部に格
納し、リモート機能呼出しによってアクセスすることが
できる。このデータベースには、ユーザＩＤの所有者の
身元も含まれる。承認する装置は、ユーザＩＤの所有者
に承認通知を送って、ユーザＩＤおよびパスワードをロ
ック解除するための承認を要求する。「所有者」のアド
レスは、ワークステーション２０および２２の一方の電
子メール・アドレスとすることができる。好ましい実施
形態では、要求元の装置と所有者が同一であり、その結
果、ユーザが、自分自身のパスワードをリセットできる
ようになっている。承認する装置（すなわちサーバ１
４）は、所有者（たとえばワークステーション２０）か
ら承認を受け取った場合にパスワードをリセットし、承
認を受け取らない場合にはパスワード・リセットの要求
を終了する。

【００４９】上で説明したように、本発明は、コンピュ
ータ実施される処理およびこれらの処理を実施する装置
の形で実施することができる。本発明は、フロッピ・デ
ィスケット、ＣＤ−ＲＯＭ、ハード・ディスク、または
他のコンピュータ可読記憶媒体などの有形の媒体内で実
施される命令を含むコンピュータ・プログラム・コード
であって、このコンピュータ・プログラム・コードが、
コンピュータにロードされ、コンピュータによって実行
される時に、そのコンピュータが本発明を実施する装置
になる、コンピュータ・プログラム・コードの形で実施
することもできる。本発明は、たとえば、記憶媒体に格
納されるか、コンピュータにロードまたはコンピュータ
によって実行またはその両方を行われるか、電線または
ケーブリングなどの伝送媒体、光ファイバ、または電磁
放射を介するなどの伝送媒体を介して伝送されるかいず
れかである、コンピュータ・プログラム・コードであっ
て、そのコンピュータ・プログラム・コードがコンピュ
ータにロードされ、コンピュータによって実行される時
に、そのコンピュータが本発明を実施する装置になるコ
ンピュータ・プログラム・コードの形で実施することも
できる。汎用マイクロプロセッサ上で実施される時に
は、コンピュータ・プログラム・コード・セグメントに
よってマイクロプロセッサが構成されて、特定の論理回
路が作成される。

【００５０】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００５１】（１）ネットワーク内の複数の異なるタイ
プのエンティティについて、エンティティへのアクセス
権を管理し、検証するのに使用される、分散ネットワー
ク環境での管理機能を自動化する方法であって、ユーザ
ＩＤのリストであって、前記ユーザＩＤが、少なくとも
１つのシステムに関連する、ユーザＩＤのリストをコン
パイルするステップと、住所録を取り出すステップと、
前記リスト内のデータを前記住所録に含まれるデータと
比較するステップであって、前記リスト内の無効なデー
タにフラグが立てられる、比較するステップと、前記デ
ータの前記比較の結果に基づいて、ユーザ定義レポート
を生成するステップとを含む方法。 （２）リモート機能呼出しを介して前記ユーザＩＤのリ
ストにアクセスするステップをさらに含む、上記（１）
に記載の方法。 （３）前記データの前記比較の前記結果に含まれるデー
タを変更するステップをさらに含む、上記（１）に記載
の方法。 （４）通知送信者によって通知受信者に通知を送るステ
ップであって、前記通知が、継続されるアクセス権の検
証に関する確認要求と、現在アクセス権を有する前記ユ
ーザＩＤのそれぞれに関するユーザＩＤデータと、前記
通知への応答に関するユーザ定義の時間制限とを含む、
通知を送るステップと、前記通知受信者による前記通知
に対する応答に基づいて、前記継続されるアクセス権を
検証するステップとをさらに含む、上記（１）に記載の
方法。 （５）前記通知が、第１通知および第２通知を含み、前
記第２通知が、前記時間制限までに前記第１通知に応答
しなかった前記通知受信者に送られ、前記第２通知が、
応答に関する第２のユーザ定義の時間制限を含む上記
（４）に記載の方法。 （６）前記通知のそれぞれが、一意のパスコードを含
み、前記パスコードが、通知受信者を識別する、上記
（４）に記載の方法。 （７）前記通知のそれぞれが、ネットワーク・ページへ
のリンクを含み、前記リンクの活動化が、前記パスコー
ドの自動的な登録を引き起こす、上記（６）に記載の方
法。 （８）前記継続されるアクセス権の前記検証が、前記通
知受信者による前記検証の完了を確認するステップを含
み、前記完了が、検証結果および前記検証の日付の登録
を引き起こす、上記（４）に記載の方法。 （９）前記検証に関する要求に対する応答が、前記通知
で規定される前記時間制限内に前記通知送信者によって
受け取られない前記ユーザＩＤについて、前記エンティ
ティへのアクセス権を拒否するステップをさらに含む、
上記（４）に記載の方法。 （１０）前記アクセス権の拒否が、前記通知送信者によ
って手動で実行される、上記（９）に記載の方法。 （１１）前記アクセス権の拒否が、前記第２通知で規定
される前記時間制限の満了時に自動的に実行される、上
記（９）に記載の方法。 （１２）前記アクセス権の拒否が、前記通知送信者によ
る前記検証の要求に対する前記応答の後続の受取時に、
自動的に逆転される、上記（９）に記載の方法。 （１３）前記アクセス権の拒否が、前記通知送信者によ
る前記検証の要求に対する前記応答の後続の受取時に、
手動で逆転される、上記（９）に記載の方法。 （１４）前記検証の要求に対する応答が、前記通知送信
者によって受け取られない前記ユーザＩＤを削除するス
テップをさらに含む、上記（４）に記載の方法。 （１５）ネットワーク内の複数の異なるタイプのエンテ
ィティについて、エンティティへのアクセス権を管理
し、検証するのに使用される、分散ネットワーク環境で
の管理機能を自動化するシステムであって、少なくとも
１つのエンティティと、前記少なくとも１つのネットワ
ーク・エンティティと通信する少なくとも１つの通知を
送る装置と、前記通知を送る装置と通信する少なくとも
１つの通知を受け取る装置とを含むコンピュータ・ネッ
トワークと、ユーザＩＤのデータベースであって、前記
ユーザＩＤが、少なくとも１つのシステムと関連する、
ユーザＩＤのデータベースと、ユーザ情報を含む住所録
とを含み、前記通知を送る装置が、前記ユーザＩＤおよ
び前記住所録に応答してアクセス権を検証するシステ
ム。 （１６）前記通知を送る装置が、ユーザＩＤのリストを
コンパイルし、住所録を取り出し、前記リスト内のデー
タを前記住所録に含まれるデータと比較し、前記リスト
内の無効なデータにフラグを立て、前記比較の結果に基
づいて、ユーザ定義レポートを生成する上記（１５）に
記載のシステム。 （１７）前記ユーザＩＤのリストが、リモート機能呼出
しによってアクセスされることをさらに含む、上記（１
６）に記載のシステム。 （１８）前記比較の前記結果に含まれるデータが、前記
通知を送る装置によって変更される、上記（１６）に記
載のシステム。 （１９）前記通知を送る装置が、前記通知を受け取る装
置に通知を送り、前記通知が、継続されるアクセス権の
検証に関する確認要求と、現在アクセス権を有する前記
ユーザＩＤのそれぞれに関するユーザＩＤデータと、応
答に関するユーザ定義の時間制限とを含み、前記通知を
受け取る装置が、前記通知に対する応答に基づいて、前
記継続されるアクセス権を検証することをさらに含む、
上記（１６）に記載のシステム。 （２０）前記通知が、第１通知および第２通知を含み、
前記第２通知が、前記時間制限までに前記第１通知に応
答しなかった前記通知を受け取る装置に送られ、さら
に、前記第２通知が、応答に関する第２のユーザ定義の
時間制限を含む上記（１９）に記載のシステム。 （２１）前記通知が、一意のパスコードを含み、前記パ
スコードが、通知を受け取る装置を識別する、上記（１
９）に記載のシステム。 （２２）前記通知が、ネットワーク・ページへのリンク
を含み、前記リンクの活動化が、前記パスコードの自動
的な登録を引き起こす上記（２１）に記載のシステム。 （２３）前記継続されるアクセス権の前記検証が、前記
通知を受け取る装置による前記検証の完了の確認を含
み、前記完了が、検証結果および前記検証の日付の登録
を引き起こす、上記（１９）に記載のシステム。 （２４）前記検証に関する要求に対する応答が前記時間
制限内に前記通知を送る装置によって受け取られかった
前記ユーザＩＤが、その後、前記エンティティへのアク
セス権を拒否される上記（１９）に記載のシステム。 （２５）前記ユーザＩＤが、前記通知を送る装置によっ
て手動でアクセス権を拒否される、上記（２４）に記載
のシステム。 （２６）前記ユーザＩＤが、前記通知で規定される前記
時間制限の満了時に自動的にアクセス権を拒否される、
上記（２４）に記載のシステム。 （２７）アクセス権を拒否された前記ユーザＩＤが、前
記通知を送る装置による前記検証の要求に対する応答の
後続の受取時に、自動的に復権される、上記（２４）に
記載のシステム。 （２８）アクセス権を拒否された前記ユーザＩＤが、前
記通知を送る装置による前記検証の要求に対する応答の
後続の受取時に、手動で復権される、上記（２４）に記
載のシステム。 （２９）前記検証の要求に対する応答が、前記通知を送
る装置によって前記時間制限内に受け取られなかった前
記ユーザＩＤが、前記通知を送る装置によって削除され
る上記（１９）に記載のシステム。 （３０）製造品であって、ネットワーク内の複数の異な
るタイプのエンティティについて、アクセス権を管理
し、検証するのに使用される、分散ネットワーク環境で
の管理機能を自動化するコンピュータ可読プログラム・
コードをその中で実施されたコンピュータ使用可能媒体
を含み、前記製造品内の上記コンピュータ可読プログラ
ム・コードが、ユーザＩＤのリストであって、前記ユー
ザＩＤが、少なくとも１つのシステムに関連する、ユー
ザＩＤのリストを、コンピュータにコンパイルさせるコ
ンピュータ可読プログラム・コードと、コンピュータに
住所録を取り出させるコンピュータ可読プログラム・コ
ードと、コンピュータに前記リスト内のデータを前記会
社の住所録に含まれるデータと比較させるコンピュータ
可読プログラム・コードであって、前記リスト内の無効
なデータにフラグが立てられる、比較させるコンピュー
タ可読プログラム・コードと、コンピュータに、前記デ
ータの前記比較の結果に基づいて、ユーザ定義レポート
を生成させるコンピュータ可読プログラム・コードとを
含む、製造品。 （３１）コンピュータに、リモート機能呼出しを介して
前記ユーザＩＤのリストにアクセスさせるコンピュータ
可読プログラム・コードをさらに含む、上記（３０）に
記載の製造品。 （３２）コンピュータに、前記データの前記比較の前記
結果に含まれるデータを変更させるコンピュータ可読プ
ログラム・コードをさらに含む、上記（３０）に記載の
製造品。 （３３）コンピュータに、通知を受け取る装置に通知を
送らせるコンピュータ可読プログラム・コードであっ
て、前記通知が、継続されるアクセス権の検証に関する
確認要求と、現在アクセス権を有する前記ユーザＩＤの
それぞれに関するユーザＩＤデータと、前記要求への応
答に関するユーザ定義の時間制限とを含む、通知を送ら
せるコンピュータ可読プログラム・コードと、コンピュ
ータに、前記通知を受け取る装置からの応答に基づい
て、前記継続されるアクセス権を検証させるコンピュー
タ可読プログラム・コードとをさらに含む、上記（３
０）に記載の製造品。 （３４）前記通知が、第１通知および第２通知を含み、
前記第２通知が、前記時間制限までに前記第１通知に応
答しなかった前記通知を受け取る装置に送られ、さら
に、前記第２通知が、応答に関する第２のユーザ定義の
時間制限を含む上記（３３）に記載の製造品。 （３５）前記通知が、一意のパスコードを含み、前記パ
スコードが、通知を受け取る装置を識別する、上記（３
３）に記載の製造品。 （３６）コンピュータに、前記通知にネットワーク・ペ
ージへのリンクを提供させるコンピュータ可読プログラ
ム・コードをさらに含み、前記リンクの活動化が、前記
パスコードの自動的な登録を引き起こす上記（３５）に
記載の製造品。 （３７）前記継続されるアクセス権の前記検証が、前記
通知を受け取る装置による前記検証の完了の確認を含
み、前記完了が、検証結果および前記検証の日付の登録
を引き起こす、上記（３３）に記載の製造品。 （３８）コンピュータに、前記検証に関する要求に対す
る応答が受け取られない前記ユーザＩＤへのアクセス権
を拒否させるコンピュータ可読プログラム・コードをさ
らに含む、上記（３３）に記載の製造品。 （３９）前記アクセス権の拒否が、手動で実行される、
上記（３８）に記載の製造品。 （４０）前記アクセス権の拒否が、前記通知で規定され
る前記時間制限の満了時に自動的に実行される、上記
（３８）に記載の製造品。 （４１）前記アクセス権の拒否が、前記検証の要求に対
する前記応答の後続の受取時に、自動的に逆転される、
上記（３８）に記載の製造品。 （４２）前記アクセス権の拒否が、前記検証の要求に対
する前記応答の後続の受取時に、手動で逆転される、上
記（３８）に記載の製造品。 （４３）コンピュータに、前記検証の要求に対する応答
が受け取られない前記ユーザＩＤを削除させるコンピュ
ータ可読プログラム・コードをさらに含む、上記（３
３）に記載の製造品。

【図面の簡単な説明】

【図１】その上でアクセスが制御される、複数のワーク
ステーションおよびサーバを含むシステムの一部のブロ
ック図である。

【図２】管理者がカスタマ・データ・ベースの構成また
は変更を選択的に行えるようにする、プル・ダウン・メ
ニューおよびカスタマ・ウィンドウを含む例示的管理画
面を示す図である。

【図３】管理者がカスタマ内のシステム識別子（ＳＩ
Ｄ）ならびに他の所望の判断基準を選択的に構成する方
法を示す、例示的保守ウィンドウを示す図である。

【図４】所与のカスタマについて定義されたプロジェク
トまたはグループならびに各プロジェクトまたは各グル
ープに割り当てられたＳＩＤを示す、ユーザが見る例示
的ウェブ画面を示す図である。

【図５】管理者が所与のＳＩＤについてメイン・アクセ
ス・プロファイルの作成、変更、または削除を行う方法
を示す、例示的管理画面およびメイン・アクセス・プロ
ファイル・ウィンドウを示す図である。

【図６】管理者がＳＩＤ内の新しいアクセス・プロファ
イルを作成する方法を示す、例示的アクセス・プロファ
イル・ウィンドウを示す図である。

【図７】管理者がＳＩＤ内のクライアントを選択的に構
成できるようにするプル・ダウン・メニューおよびクラ
イアント・ウィンドウを含む、例示的管理画面を示す図
である。

【図８】管理者がＳＩＤのシステム・オーソライザまた
は承認者を選択的に構成できるようにするプル・ダウン
・メニューおよび承認者ウィンドウを含む、例示的管理
画面を示す図である。

【図９】管理者がキュー内の許可を保留されている要求
の状況を再検討できるようにするプル・ダウン・メニュ
ーおよび保守ウィンドウを含む、例示的管理画面を示す
図である。

【図１０】管理者がキュー内の個々の要求に関する特定
の詳細を再検討できるようにする、保守ウィンドウおよ
びユーザ・データ・ウィンドウを含む、例示的管理画面
を示す図である。

【図１１】管理者が、手動で処理されなければならない
承認された要求を実行できるようにする、プル・ダウン
・メニューおよび「Complete/Reject User Requests」
ウィンドウを含む、例示的管理画面を示す図である。

【図１２】ネットワーク上のエンティティへのアクセス
を選択し、制御するために実施される論理ステップを示
す、例示的流れ図である。

【図１３】どのユーザが、アクセスを許可されたシステ
ムへのアクセスを要求し続けているかを管理者が周期的
に評価できるようにする、プル・ダウン・メニューおよ
び再検証ウィンドウを含む例示的管理画面を示す図であ
る。

【図１４】管理者が、評価されるアクセス要件について
グループのユーザを選択でき、定義できるようにする、
例示的再検証ウィンドウを示す図である。

【図１５】アクセス要件の評価のために管理者によって
選択されたシステムまたはクライアント内のユーザのグ
ループを含む情報のテーブルを表示する再検証ウィンド
ウを含む、例示的管理画面を示す図である。

【図１６】管理者が、テーブル内で識別されたユーザが
まだ雇用されているかどうかを検証し、ユーザ・データ
に対する訂正または更新を行えるようにする再検証ウィ
ンドウおよびプル・ダウン・メニューを含む、例示的管
理画面を示す図である。

【図１７】管理者が、ユーザ・データに関するさまざま
なレポートを生成できるようにする、再検証ウィンドウ
およびプル・ダウン・メニューを含む例示的管理画面を
示す図である。

【図１８】マネージャがそれに関するユーザ・アクセス
要件の検証を要求したユーザ・データのリスティングを
表示する、受信側マネージャによって見られる、例示的
メール・レポート画面を示す図である。

【図１９】管理者が再検証メール・レポート処理を管理
できるようにする、例示的再検証状況レポート画面を示
す図である。

【図２０】管理者がユーザ識別管理システムに含まれる
さまざまなデータを検索できるようにする、１つまたは
複数の異なる選択された判断基準によって編成すること
ができる、ログ・ビューア・ウィンドウを含む例示的管
理画面を示す図である。

【図２１】管理者が、指定されたＳＩＤまたはクライア
ントに関する検索をさらに定義できるようにする、ログ
・ビューア・ツールの例示的検索機能ウィンドウを示す
図である。

【図２２】自動パスワード・リセットのために実施され
る論理ステップを示す例示的流れ図である。

【符号の説明】

３０２ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３０３ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３０４ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３０５ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３０６ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３０７ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３０８ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３０９ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３１０ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３１１ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３１２ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３１３ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３１４ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３１５ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３１６ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３１７ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３１８ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３１９ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３２０ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３２１ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３２２ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３２３ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３２４ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３２５ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３２６ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３２７ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ３２８ ネットワーク上のエンティティへのアクセスを
選択し、制御するためのステップ ４００ 自動パスワード・リセットのためのステップ ４０１ 自動パスワード・リセットのためのステップ ４０２ 自動パスワード・リセットのためのステップ ４０３ 自動パスワード・リセットのためのステップ ４０４ 自動パスワード・リセットのためのステップ ４０５ 自動パスワード・リセットのためのステップ ４０６ 自動パスワード・リセットのためのステップ ４０７ 自動パスワード・リセットのためのステップ ４０８ 自動パスワード・リセットのためのステップ ４０９ 自動パスワード・リセットのためのステップ ４１０ 自動パスワード・リセットのためのステップ ４１１ 自動パスワード・リセットのためのステップ ４１２ 自動パスワード・リセットのためのステップ ４１３ 自動パスワード・リセットのためのステップ ４１４ 自動パスワード・リセットのためのステップ ４１５ 自動パスワード・リセットのためのステップ ４１６ 自動パスワード・リセットのためのステップ ４１７ 自動パスワード・リセットのためのステップ ４１８ 自動パスワード・リセットのためのステップ ４１９ 自動パスワード・リセットのためのステップ ４２０ 自動パスワード・リセットのためのステップ ４２１ 自動パスワード・リセットのためのステップ ４２２ 自動パスワード・リセットのためのステップ ４２３ 自動パスワード・リセットのためのステップ ４２４ 自動パスワード・リセットのためのステップ ４２５ 自動パスワード・リセットのためのステップ ４２６ 自動パスワード・リセットのためのステップ ４２７ 自動パスワード・リセットのためのステップ ４２８ 自動パスワード・リセットのためのステップ ４２９ 自動パスワード・リセットのためのステップ ４３０ 自動パスワード・リセットのためのステップ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 マイケル・エス・マッケイ アメリカ合衆国12570 ニューヨーク州ポ ーカーグ グリーン・ストリート 20

Claims (43)

【特許請求の範囲】
1. 【請求項１】ネットワーク内の複数の異なるタイプのエ
   ンティティについて、エンティティへのアクセス権を管
   理し、検証するのに使用される、分散ネットワーク環境
   での管理機能を自動化する方法であって、 ユーザＩＤのリストであって、前記ユーザＩＤが、少な
   くとも１つのシステムに関連する、ユーザＩＤのリスト
   をコンパイルするステップと、 住所録を取り出すステップと、 前記リスト内のデータを前記住所録に含まれるデータと
   比較するステップであって、前記リスト内の無効なデー
   タにフラグが立てられる、比較するステップと、 前記データの前記比較の結果に基づいて、ユーザ定義レ
   ポートを生成するステップとを含む方法。
2. 【請求項２】リモート機能呼出しを介して前記ユーザＩ
   Ｄのリストにアクセスするステップをさらに含む、請求
   項１に記載の方法。
3. 【請求項３】前記データの前記比較の前記結果に含まれ
   るデータを変更するステップをさらに含む、請求項１に
   記載の方法。
4. 【請求項４】通知送信者によって通知受信者に通知を送
   るステップであって、前記通知が、 継続されるアクセス権の検証に関する確認要求と、 現在アクセス権を有する前記ユーザＩＤのそれぞれに関
   するユーザＩＤデータと、 前記通知への応答に関するユーザ定義の時間制限とを含
   む、通知を送るステップと、 前記通知受信者による前記通知に対する応答に基づい
   て、前記継続されるアクセス権を検証するステップとを
   さらに含む、請求項１に記載の方法。
5. 【請求項５】前記通知が、第１通知および第２通知を含
   み、 前記第２通知が、前記時間制限までに前記第１通知に応
   答しなかった前記通知受信者に送られ、 前記第２通知が、応答に関する第２のユーザ定義の時間
   制限を含む請求項４に記載の方法。
6. 【請求項６】前記通知のそれぞれが、一意のパスコード
   を含み、前記パスコードが、通知受信者を識別する、請
   求項４に記載の方法。
7. 【請求項７】前記通知のそれぞれが、ネットワーク・ペ
   ージへのリンクを含み、前記リンクの活動化が、前記パ
   スコードの自動的な登録を引き起こす、請求項６に記載
   の方法。
8. 【請求項８】前記継続されるアクセス権の前記検証が、
   前記通知受信者による前記検証の完了を確認するステッ
   プを含み、前記完了が、検証結果および前記検証の日付
   の登録を引き起こす、請求項４に記載の方法。
9. 【請求項９】前記検証に関する要求に対する応答が、前
   記通知で規定される前記時間制限内に前記通知送信者に
   よって受け取られない前記ユーザＩＤについて、前記エ
   ンティティへのアクセス権を拒否するステップをさらに
   含む、請求項４に記載の方法。
10. 【請求項１０】前記アクセス権の拒否が、前記通知送信
    者によって手動で実行される、請求項９に記載の方法。
11. 【請求項１１】前記アクセス権の拒否が、前記第２通知
    で規定される前記時間制限の満了時に自動的に実行され
    る、請求項９に記載の方法。
12. 【請求項１２】前記アクセス権の拒否が、前記通知送信
    者による前記検証の要求に対する前記応答の後続の受取
    時に、自動的に逆転される、請求項９に記載の方法。
13. 【請求項１３】前記アクセス権の拒否が、前記通知送信
    者による前記検証の要求に対する前記応答の後続の受取
    時に、手動で逆転される、請求項９に記載の方法。
14. 【請求項１４】前記検証の要求に対する応答が、前記通
    知送信者によって受け取られない前記ユーザＩＤを削除
    するステップをさらに含む、請求項４に記載の方法。
15. 【請求項１５】ネットワーク内の複数の異なるタイプの
    エンティティについて、エンティティへのアクセス権を
    管理し、検証するのに使用される、分散ネットワーク環
    境での管理機能を自動化するシステムであって、 少なくとも１つのエンティティと、 前記少なくとも１つのネットワーク・エンティティと通
    信する少なくとも１つの通知を送る装置と、 前記通知を送る装置と通信する少なくとも１つの通知を
    受け取る装置とを含むコンピュータ・ネットワークと、 ユーザＩＤのデータベースであって、前記ユーザＩＤ
    が、少なくとも１つのシステムと関連する、ユーザＩＤ
    のデータベースと、 ユーザ情報を含む住所録とを含み、前記通知を送る装置
    が、前記ユーザＩＤおよび前記住所録に応答してアクセ
    ス権を検証するシステム。
16. 【請求項１６】前記通知を送る装置が、 ユーザＩＤのリストをコンパイルし、 住所録を取り出し、 前記リスト内のデータを前記住所録に含まれるデータと
    比較し、前記リスト内の無効なデータにフラグを立て、 前記比較の結果に基づいて、ユーザ定義レポートを生成
    する請求項１５に記載のシステム。
17. 【請求項１７】前記ユーザＩＤのリストが、リモート機
    能呼出しによってアクセスされることをさらに含む、請
    求項１６に記載のシステム。
18. 【請求項１８】前記比較の前記結果に含まれるデータ
    が、前記通知を送る装置によって変更される、請求項１
    ６に記載のシステム。
19. 【請求項１９】前記通知を送る装置が、前記通知を受け
    取る装置に通知を送り、前記通知が、 継続されるアクセス権の検証に関する確認要求と、 現在アクセス権を有する前記ユーザＩＤのそれぞれに関
    するユーザＩＤデータと、 応答に関するユーザ定義の時間制限とを含み、 前記通知を受け取る装置が、前記通知に対する応答に基
    づいて、前記継続されるアクセス権を検証することをさ
    らに含む、請求項１６に記載のシステム。
20. 【請求項２０】前記通知が、第１通知および第２通知を
    含み、 前記第２通知が、前記時間制限までに前記第１通知に応
    答しなかった前記通知を受け取る装置に送られ、 さらに、前記第２通知が、応答に関する第２のユーザ定
    義の時間制限を含む請求項１９に記載のシステム。
21. 【請求項２１】前記通知が、一意のパスコードを含み、
    前記パスコードが、通知を受け取る装置を識別する、請
    求項１９に記載のシステム。
22. 【請求項２２】前記通知が、ネットワーク・ページへの
    リンクを含み、前記リンクの活動化が、前記パスコード
    の自動的な登録を引き起こす請求項２１に記載のシステ
    ム。
23. 【請求項２３】前記継続されるアクセス権の前記検証
    が、前記通知を受け取る装置による前記検証の完了の確
    認を含み、前記完了が、検証結果および前記検証の日付
    の登録を引き起こす、請求項１９に記載のシステム。
24. 【請求項２４】前記検証に関する要求に対する応答が前
    記時間制限内に前記通知を送る装置によって受け取られ
    かった前記ユーザＩＤが、その後、前記エンティティへ
    のアクセス権を拒否される請求項１９に記載のシステ
    ム。
25. 【請求項２５】前記ユーザＩＤが、前記通知を送る装置
    によって手動でアクセス権を拒否される、請求項２４に
    記載のシステム。
26. 【請求項２６】前記ユーザＩＤが、前記通知で規定され
    る前記時間制限の満了時に自動的にアクセス権を拒否さ
    れる、請求項２４に記載のシステム。
27. 【請求項２７】アクセス権を拒否された前記ユーザＩＤ
    が、前記通知を送る装置による前記検証の要求に対する
    応答の後続の受取時に、自動的に復権される、請求項２
    ４に記載のシステム。
28. 【請求項２８】アクセス権を拒否された前記ユーザＩＤ
    が、前記通知を送る装置による前記検証の要求に対する
    応答の後続の受取時に、手動で復権される、請求項２４
    に記載のシステム。
29. 【請求項２９】前記検証の要求に対する応答が、前記通
    知を送る装置によって前記時間制限内に受け取られなか
    った前記ユーザＩＤが、前記通知を送る装置によって削
    除される請求項１９に記載のシステム。
30. 【請求項３０】製造品であって、 ネットワーク内の複数の異なるタイプのエンティティに
    ついて、アクセス権を管理し、検証するのに使用され
    る、分散ネットワーク環境での管理機能を自動化するコ
    ンピュータ可読プログラム・コードをその中で実施され
    たコンピュータ使用可能媒体を含み、前記製造品内の上
    記コンピュータ可読プログラム・コードが、 ユーザＩＤのリストであって、前記ユーザＩＤが、少な
    くとも１つのシステムに関連する、ユーザＩＤのリスト
    を、コンピュータにコンパイルさせるコンピュータ可読
    プログラム・コードと、 コンピュータに住所録を取り出させるコンピュータ可読
    プログラム・コードと、 コンピュータに前記リスト内のデータを前記会社の住所
    録に含まれるデータと比較させるコンピュータ可読プロ
    グラム・コードであって、前記リスト内の無効なデータ
    にフラグが立てられる、比較させるコンピュータ可読プ
    ログラム・コードと、 コンピュータに、前記データの前記比較の結果に基づい
    て、ユーザ定義レポートを生成させるコンピュータ可読
    プログラム・コードとを含む、製造品。
31. 【請求項３１】コンピュータに、リモート機能呼出しを
    介して前記ユーザＩＤのリストにアクセスさせるコンピ
    ュータ可読プログラム・コードをさらに含む、請求項３
    ０に記載の製造品。
32. 【請求項３２】コンピュータに、前記データの前記比較
    の前記結果に含まれるデータを変更させるコンピュータ
    可読プログラム・コードをさらに含む、請求項３０に記
    載の製造品。
33. 【請求項３３】コンピュータに、通知を受け取る装置に
    通知を送らせるコンピュータ可読プログラム・コードで
    あって、前記通知が、 継続されるアクセス権の検証に関する確認要求と、 現在アクセス権を有する前記ユーザＩＤのそれぞれに関
    するユーザＩＤデータと、 前記要求への応答に関するユーザ定義の時間制限とを含
    む、通知を送らせるコンピュータ可読プログラム・コー
    ドと、 コンピュータに、前記通知を受け取る装置からの応答に
    基づいて、前記継続されるアクセス権を検証させるコン
    ピュータ可読プログラム・コードとをさらに含む、請求
    項３０に記載の製造品。
34. 【請求項３４】前記通知が、第１通知および第２通知を
    含み、 前記第２通知が、前記時間制限までに前記第１通知に応
    答しなかった前記通知を受け取る装置に送られ、 さらに、前記第２通知が、応答に関する第２のユーザ定
    義の時間制限を含む請求項３３に記載の製造品。
35. 【請求項３５】前記通知が、一意のパスコードを含み、
    前記パスコードが、通知を受け取る装置を識別する、請
    求項３３に記載の製造品。
36. 【請求項３６】コンピュータに、前記通知にネットワー
    ク・ページへのリンクを提供させるコンピュータ可読プ
    ログラム・コードをさらに含み、前記リンクの活動化
    が、前記パスコードの自動的な登録を引き起こす請求項
    ３５に記載の製造品。
37. 【請求項３７】前記継続されるアクセス権の前記検証
    が、前記通知を受け取る装置による前記検証の完了の確
    認を含み、前記完了が、検証結果および前記検証の日付
    の登録を引き起こす、請求項３３に記載の製造品。
38. 【請求項３８】コンピュータに、前記検証に関する要求
    に対する応答が受け取られない前記ユーザＩＤへのアク
    セス権を拒否させるコンピュータ可読プログラム・コー
    ドをさらに含む、請求項３３に記載の製造品。
39. 【請求項３９】前記アクセス権の拒否が、手動で実行さ
    れる、請求項３８に記載の製造品。
40. 【請求項４０】前記アクセス権の拒否が、前記通知で規
    定される前記時間制限の満了時に自動的に実行される、
    請求項３８に記載の製造品。
41. 【請求項４１】前記アクセス権の拒否が、前記検証の要
    求に対する前記応答の後続の受取時に、自動的に逆転さ
    れる、請求項３８に記載の製造品。
42. 【請求項４２】前記アクセス権の拒否が、前記検証の要
    求に対する前記応答の後続の受取時に、手動で逆転され
    る、請求項３８に記載の製造品。
43. 【請求項４３】コンピュータに、前記検証の要求に対す
    る応答が受け取られない前記ユーザＩＤを削除させるコ
    ンピュータ可読プログラム・コードをさらに含む、請求
    項３３に記載の製造品。