JP5201904B2 - 分散型ユーザ確認・プロファイル管理システム及び方法 - Google Patents

Description

本発明は、概してコンピュータ・セキュリティーシステムに関し、具体的にはセキュリティ関連のコンピュータ資源管理および電子ポータル・アクセスシステムに関する。

例えば企業またはその他の組織団体で使用される通常のコンピュータ・ネットワークの多くは、（通常、組織内の従業員または組織と提携しているコンサルタントなどの）様々なユーザが該組織の資源の一部である一つ以上のコンピュータ・ネットワーク化されたアプリケーションにアクセスできるようにするために導入されている。通常、該コンピュータ・アプリケーションには、特化されたセキュリティ機能を伴うかどうかはともかく、ワードプロセッシング、表計算ソフト、プレゼンテーション、Eメール、取引関係管理アプリケーションまたはその他のタイプの汎用アプリケーションなどを含みうる。組織資源の一部として備えられるアプリケーションには、例えば、会計用アプリケーション、企画・マーケティング用アプリケーション、資源管理アプリケーション、トレーニング用アプリケーション、従業員管理・人事管理用アプリケーション、および他のタイプのアプリケーションなど、組織特有の又は組織の必要性に対応可能な様々なアプリケーションが付加的または代替的に含まれることがあり、これらは何らかの理由により組織が機能する上で有用とされる種々様々な作業を行うために組織内に又はその一部として備えられている。多くの場合、これらのアプリケーションにはそれに関連するセキュリティ機能が備えられ、組織に関連したユーザのうちの数人のみがアプリケーションにアクセスできるように、或いは、一部のユーザによるアプリケーションへのアクセスを、該ユーザの組織内における地位、職務、役職、部署、機能などにより限定できるようにされている。

したがって多くの場合、各ユーザが組織内で使用されるアプリケーションのうち限られた数のアプリケーションのみにアクセスできるようになっており、ユーザにアクセスできるアプリケーションのうちのいくつかまたは全てに対して制限付きアクセス権または特権が提供されている場合もある。

小規模または一纏まりの単一組織体で構成される組織の場合は、比較的簡単に組織により提供される各種アプリケーションに対する組織内ユーザのアクセス管理を達成することができる。一方、大規模な組織の場合は通常アプリケーションにアクセスするユーザの数も多くなり、組織内の様々な作業または機能に関連するアプリケーションの数も多くなるので、大規模な組織において様々な組織コンピュータ資産へのユーザ・アクセスを管理することは、非常に困難でかなりの時間と根気を要する作業である。また多くの場合、組織の規模が大きくなると、該組織のパートナーまたは代理として機能しており、よって該組織のコンピュータ・アプリケーションに何らかの形でアクセスすることが必要とされるような、第三者企業または組織体も関わってくる。その上、大規模な組織においては雇用変更の頻度がより多く、また一般的には集権化されていないため、変更の内容が組織の上級管理職レベルには未報告のまま、または未知のままとなることが時折生じる。したがって、従来では、組織のコンピュータ・ネットワーク資産の各々について、組織の様々なユーザに与えるべきアクセス権をトラッキングしアップデートする(すなわち、最新データ状態を維持する）作業は、非常に厄介で多大な時間を要する作業であった。場合によっては、組織関連コンピュータ・ネットワーク上の個々のアプリケーションによって、各アプリケーションへのアクセスを得ることができる一連のユーザを管理し、これらのユーザの各々が利用できるアクセスの量またはレベルの管理が行われる。この機能により高水準のセキュリティが提供される一方、ユーザが離職したり入社したりする度に、また時によっては組織内でユーザの役職または職務が変更される度に、各アプリケーションごとにアプリケーションへのアクセス権を変更しなければならないため、大規模な組織内での管理には非常に使い勝手が悪く管理作業が困難になる。ユーザ数且つ又はアプリケーション数の多い大規模な組織では、従業員の離職・移転が頻繁に生じる傾向にあるため、アプリケーション毎のセキュリティ・アクセス機能の更新が困難または多大な時間を要する作業となる。

この問題を解決するために、諸組織、特に多数のアプリケーション且つ又は多数の従業員を有する大規模な諸組織は、ユーザの自己識別要素（アイデンティティ）およびユーザについての情報（各種アプリケーションを定義する情報、また場合によってはユーザが有している各種アプリケーションへのアクセス権またはセキュリティレベルを定義する情報を含む）を各ユーザに定義する、組織的な幅広いユーザープロファイル・システムを設定している。

これにより、特定のユーザが所定のアプリケーションにログオン又はアクセスしようとすると、該アプリケーションに関連するセキュリティーシステムは、この特定のユーザが、該アプリケーションの全範囲にわたって、もしくは要求されるアクセスレベルで、当該アプリケーションにアクセスしてそれを使用するためのアクセス承認資格またはセキュリティレベルを有するかどうかを判断するために、該ユーザープロファイルを使用する。しかしながら、上記の方法においても、組織を離れたユーザが組織のアプリケーションにアクセスできないようにするため、又は組織内で役職を変更した従業員が新規役職に適したアプリケーションへのアクセス権を確実に取得できるようにするためには、ユーザープロファイルを最新で正確な情報にしておくことが依然として要求される。

当然のことながら、通常は従業員が組織を去る時点でユーザープロファイルへの変更を実施して、即時にあらゆるアプリケーションへのアクセスを打ち切る必要がある。同様に、特定のアプリケーション及びアプリケーション内の特定のコンテンツへのアクセス権は一般的に、一つ以上のユーザ・プロファイルの属性（例えば、従業員の事務所ID、事業部、部署、役職名、機能、技能レベル、または世界地域別所属地など）により判断されるので、組織内の変更（特に従業員の役職変更）が生じた場合にも、変更された時点においてユーザープロファイルを変更する必要がありえる。したがって、ほとんどの場合においては、該当するあらゆるユーザの役職変更が生じた際にも、直ちにその変更をアプリケーションのセキュリティーシステムで使用されるユーザープロファイルに記録または反映し、ユーザの該アプリケーションコンテンツへのアクセスを必要に応じて検討され且つ更新できるようになければならない。

従来は、組織は、アプリケーション・セキュリティーシステムで用いられるユーザープロファイルの更新を主な責務とする人事(HR)部、情報技術(IT)部またはその他何らかの部署またはグループなど、該組織内に通常集権化された特定のグループまたは部署を設けて、従業員の退社または組織内における役職変更などが生じた際に各組織のアプリケーションに関する適切なユーザ・アクセスを管理していた。しかしながら、特に大規模な組織の場合、中央拠点または特定の部署においてユーザープロファイルを手作業で更新する工程は該作業を担当する者にとって多大な時間と根気を要するものである。更に、一つのグループによりプロファイルを変更する仕組みだと、実際にユーザープロファイル変更の対象となっているユーザ本人が関与していないが故に、誤りおよび遅延が多発しえる。また、第三者企業の代表者ユーザに関する変更はなおさらのこと、そのユーザが退社したり、プロファイルの内容に変更が生じたりした時に、実際に変更を実施する側の組織がその変更を即座に知ることができない場合がほとんどである。具体的に言うと、一つ以上のユーザープロファイルの変更が必要かもしれない組織構造内の変更（組織変更の対象となっている特定のユーザのアクセス権を変更する必要がありえる組織的責務の変更、組織の部署内または部署間の人員移動、組織内の様々な部署における上司‐部下関係の変化などのいずれか又は全て）が適切に又は一律に人事部や情報技術部に報告されない場合がほとんどである。さらにまた、大規模な組織または離職率が高い組織や第三者系列会社では、正規の人員削減により生じるユーザープロファイルの作成および変更の頻度（量）が多いため時間と根気を要するものである。またこのような業務は通常、組織内でないがしろにされ易いものであるせいか、スケジュール通りにまたは定期間に十分な注力を費やすことが難しい。このように、これらのシナリオは、組織内のアプリケーションまたはコンピュータ・ネットワーク機構（設備）への適切なアクセスを確保するために変更を必要とする様々なユーザに関する正確な情報を反映するために、ユーザープロファイルを削除、更新、変更する際のバックログ（未処理分）に結びつきえる。

あいにく、ネットワーク化された組織資産への適切なセキュリティまたはアクセス権を適時に割り当てることに失敗すると、場合によっては非常に大きな問題となりえる。特に、ユーザープロファイルを不的確にまたはタイミング悪く更新すると、離職または組織内で職務移転した者の中で不満を持つ或いは悪意ある従業員がこのようなセキュリティ上の過失を悪用する可能性があり、これにより営業秘密、極秘技術、市場取引・販売情報、従業員ファイルに保管されている個人機密情報などが公開される可能性があり、組織に著しい損害をもたらしうる。

本発明は、コンピュータにより実行されるアプリケーションなどの様々な組織資産において、組織内の様々なユーザが有する実際の地位や権限を的確に反映するために、例えば組織のセキュリティ・データベースに保存されるユーザープロファイルを自動的に確認および更新する作業を行うための分散型ユーザ確認（認証）・プロファイル管理システム及び方法を提供することを目的とする。

分散型ユーザ確認（認証）・プロファイル管理システムは、コンピュータにより実行されるアプリケーションなどの様々な組織資産に対して、組織内の様々なユーザが有する実際の地位や権限を的確に反映するために、例えば組織のセキュリティ・データベースに保存されるユーザープロファイルを自動的に確認および更新する作業を行うためのものである。本書に記載されるユーザ確認・プロファイル管理システムには、ユーザープロファイル情報を確認・更新する処理を開始するために、例えばEメールなどの形式で組織内の様々なユーザに定期的に通知を送信するユーザ確認エンジンが含まれる。個人ユーザは、組織内における自分の地位や状態を確認するために、確認用Eメール内に提供される電子リンクにアクセスすることにより、又は該電子リンクを使用して、確認用Eメールに応答することができる。一実施形態においては、ユーザは、現在記録されているユーザープロファイルに示されるものと同じ権限・能力をもって、自分がまだ組織に雇用されているか、または該組織に関連しているかを確認する。ユーザが確認用Eメールへの応答を怠ると、ユーザがアプリケーションにアクセスしようとすると、ユーザ確認・プロファイル管理システムによりそのユーザープロファイルは有効でないと判断され、よって、そのユーザは組織内のネットワーク化されたアプリケーションにアクセス、又はそれを使用できないことになる。

また、他の実施形態においては、特定のユーザが、組織内の一人以上のユーザ（本書において「特定のユーザと密接に関連するユーザ」とされる特定のユーザの上司または直属の部下など）の状態を検証または確認することができ、また場合によっては該検証・確認を行わなければならない。この機能により、任意の特定のユーザ（即ち、そのユーザのユーザープロファイル）の状態が、該特定のユーザおよびに該特定のユーザと密接に関連する組織内の一個人（管理者または特定のユーザの部下など）の両者によりお互いに検証するといった作業を確実に行えるようになる。一人以上の密接に関連するユーザが特定のユーザを検証することを怠ると、特定のユーザのユーザープロファイルが有効でないと見なされることになり、よって、該特定のユーザがネットワーク化された組織資産にアクセス、またはそれを使用できなくなる。

なおまた、特定のユーザのいずれかにユーザ確認・プロファイル管理システムからEメールが大量に送信されるのを防ぐため、或いはそれによってユーザの忍耐を消耗しきることを防ぐために、該確認システムは、確認用Eメールを受信するユーザ・グループを交互に変更することによりユーザが確認期間毎に毎回、自分自身および密接に関連するユーザを検証する必要がないようにする。一実施形態では、ユーザ確認・プロファイル管理システムは、一確認期間おきでのみ特定のユーザのもとに確認用Eメールを送信する。したがって、例えば、第1の確認期間中に、ユーザ確認システムから、組織内のユーザの半数だけにEメールを送信し、確認用Eメールを受信した該半数のユーザにだけ、自分自身および自分以外のその他の半数に属する一人以上の密接に関連するユーザ（すなわち、確認用Eメールが送信されていない残り半数のユーザ）を確認することを要求するようにしてもよい。その後、次の確認期間中に、ユーザ確認システムから、残りの半数のユーザにだけEメールを送信し、該残り半数のユーザの各々に、自分自身および場合によっては第2確認期間に確認用Eメールが送信されない最初の半数に属する一人以上の密接に関連するユーザを確認することを要求するようにしてもよい。

このようにして、該確認システムは、ある特定のユーザが確認用Eメールに応答する2倍の頻度で各ユーザープロファイルを更新または確認（検証）できる。

当然のことながら、本書に記載されるユーザ確認システムは、密接に関連するユーザ同士が一確認期間おきにお互いに確認し合うことにより、ユーザの自己確認に自動チェック機能を提供する。このように、組織から離職する又は組織内において役職を変更する（にもかかわらず、現時点でも依然として組織のネットワークへのアクセスを有する）場合、該変更が有効となった後の最初の確認期間中に特定のユーザは自分自身を確認（承認）できるが、それでも、前記変更が有効となった後に実施される第2の確認期間中に、この特定のユーザに対して定義されている密接に関連するユーザ（例えば、特定のユーザの上司または部下など）が該特定のユーザを確認する要求を受けた際に、該特定のユーザはもはや承認されるべきではないと認知し、確認用Eメールで承認することを拒否するので、該特定のユーザは無効とされるようになっている。

したがって、本書に記載されるユーザ確認・プロファイル管理システムは、ユーザに自分自身とその他組織内の密接に関連するユーザを確認するための自動的方式を提供することにより、自動的・継続的かつ規則的な更新機能を伴うユーザ確認手順を提供し、それによって、ユーザープロファイル変更の開始、監視、および手作業による入力などを行うために人事部などの特定グループを必要とせずに（但し、場合によっては業務管理担当者がユーザープロファイルの変更を監視する必要があるかもしれないが）、ネットワーク化された様々な組織機構への適切なアクセスをより効果的に管理し、且つより優れたセキュリティーシステムを提供する。なおまた、本書に記載される確認システムは、検証（確認）作業を連続した確認期間中に交代で行わせるため、特定のユーザがシステム内で自分自身を更新又は検証する作業を行う回数より多くの頻度で各々のユーザープロファイルを更新・検証できる。したがって、このシステムは、より正確且つより高速な、或いは、少なくとも一般的なユーザープロファイルの検証手段を提供し、ユーザが組織内において変更を行える権限（地位・役職）を持っていないにもかかわらず組織の資産にアクセスし続けてシステムを悪用できないようにする手順を実施する。なおまた、該確認システムは、該確認システムで用いられる様々な確認グループを定義する際に適用される関係に基づいて、組織内の上司/部下関係を示す組織図を定義および更新する際にも簡単に使用でき便利である。

添付の図面において、本発明は実施例として示されており、それにより本発明が限定されるものではなく、類似した表現（言及）は類似する要素・素子を示す。

図1において、企業、非営利事業体、事業法人、政府、政府事業体またはその他の組織的な事業体などの組織に関連したコンピュータ・ネットワークシステム10が、ブロック図の形式で図示されている。図1に示されるように、コンピュータ・ネットワークシステム10は、ネットワーク化された形態で、様々な異なるタイプのコンピュータ・ハードウェア装置を通信可能に接続するローカル・エリア・ネットワーク(LAN)12を含む。特に、コンピュータ・ネットワークシステム10は、組織に関連する様々な異なるユーザがネットワーク化されたコンピュータ機構にLAN12を介してアクセスできるようにするための複数のユーザー・ワークステーションまたはユーザ・インタフェース14を含んだ状態で図示されている。また、例えばサーバ、データベース、アプリケーション・ステーションなどの様々なコンピュータ16は、LAN12と通信可能に接続され、一つ以上のアプリケーション18を格納および実行するために用いられる。なおまた、図1に示されるように、アプリケーション18Aは、ポータルまたはセキュリティサーバ装置24（所望の場合はアプリケーション18A且つ又はアプリケーション18に関してのユーザ確認を調整または実行しうる）を介してLAN12に接続されるコンピュータ16Aに格納されている。

一般的に、ユーザは、ワークステーション14のうちの一つを用いてアプリケーション18および18Aにアクセスまたはそれらを実行することができる。もちろん、アプリケーション18および18Aには、所望のあらゆるタイプ、種類、ブランドなどのアプリケーション（例えば、会計用アプリケーション、財務用アプリケーション、人事管理用アプリケーション、資源管理アプリケーション、トレーニング用アプリケーション、在庫管理用アプリケーション、保全管理アプリケーション、市場取引・営業用アプリケーション、設計用アプリケーション、またはその他組織内で使用されるか又は有用なアプリケーションを含む）を適用することができる。また、様々なワークステーション14のユーザのうちの一人がLAN12を介してアプリケーション18および18Aのいずれにもアクセスできる一方、所望により、アプリケーション18および18Aを所望のあらゆる形態でワークステーション14内ダウンロードし、そこで実行してもよく、またははじめからワークステーション14内に格納するようにしてもよい。

さらにまた、組織内の、組織と関連する、または組織を構成する異なる部署、系列会社または他の組織体に関連するネットワーク資産へのアクセスを提供するために、異なる地理的位置に存在する組織資産へのアクセスを提供できるようにすることを目的として、LAN12をノード（接続点）26、26Aおよび26Bを通して接続することができる。したがって、図1に示されるように、ユーザ・インタフェース・コンピュータ14Aおよび14Bを、LAN12Aおよび12Bに接続してもよく、オフサイト（外部）設備またはワークステーション14が位置する設備から物理的に離れた場所に位置する設備と関連づけてもよい。インタフェースコンピュータ14Aおよび14Bは、広域ネットワーク(WAN)、衛星通信、インターネット、プライベートネットワーク（私設網）などをはじめとするあらゆるタイプの通信ネットワークを用いてノード26、26Aおよび26Bを通してLAN12に接続されることができる。また、図1には図示されていないが、追加のアプリケーション18および18Aを、通信ネットワーク12Aおよび12Bに接続されたコンピュータ機器または設備に格納してもよい。このように、コンピュータ・ネットワークシステム10は、一つの拠点に限らず、公衆網または私設網、LAN、WANなどを含む所望のあらゆるタイプの通信構造を通じて相互に接続された複数拠点を含むことができる。

図1に示されるように、ポータル24は、LAN12に接続され、プロファイル・データベース30に複数のユーザープロファイル28を格納するために用いられる。なお、これは一般的に、組織に関連する様々なユーザの各々に対して（又は少なくともコンピュータ・ネットワークシステム10に関連するアプリケーション18及び／又は18Aのいずれかにアクセスすべき各ユーザに対して）少なくとも一つのユーザープロファイル28が存在する例である。動作中に、ポータル24は、特定のユーザがアプリケーション18または18Aにアクセスまたはそれを実行できる適切な権限を有するかどうかを判断し、アクセス権を有する場合はユーザがアプリケーション18または18Aにアクセスできるアクセスの量またはレベルを判断することにより、特定のユーザに関連するユーザープロファイル28に基づいてアプリケーション18及び／又は18Aへのアクセスを限定するためのセキュリティ・ルーチンまたはセキュリティ・エンジン32を実行する。

ここで重要なことは、例えばユーザがアプリケーション18または18Aのうちの一つへのアクセスを得ようとする時に該ユーザのユーザープロファイルを自動的に確認する作業を行う確認（検証）エンジン34および確認（検証）データベース36を有するユーザ確認・プロファイル管理システムが、ポータル24に含まれているということである。また、本書でより詳細にわたり説明するように、ユーザ確認・プロファイル管理システムは、ユーザが組織内の変更（例えば、新規ユーザの雇用、ユーザの離職または組織内の役職変更、ユーザの新規又は異なる責務への任命、組織内の新規又は異なる機能或いは役職への移動など、ユーザの組織との関係を再定義する結果となりえ、よってユーザがアプリケーション18または18Aにアクセスする際に必要となるアクセスのタイプを再定義する結果となりうるあらゆる変化）に基づき、ユーザープロファイル・データベース30内でユーザープロファイル28を更新できるようにする操作を行うことができる。

これらの機能を果たすために、ユーザ確認・プロファイル管理システムは、確認エンジン34、確認データベース36、ローカルサーバ38(Eメールおよびウェブサーバでありうる)、そして場合によっては公衆サーバ40（インターネットまたはワールド・ワイド・ウェブに接続された電子メールサーバなど）を含む。図1に示されるように、ローカルサーバ38は組織内に提供されているイントラネットを介してEメールを送信するために、LAN12を通して様々なワークステーション14に接続されることができ、またそれに加えて、Eメールを組織外部のアドレスに送信するため、または組織に関連するユーザのもとに公衆通信ネットワークを介して送信されなければならないEメールを送信するために、公衆サーバ40（インターネット・サーバまたは他の公衆網サーバでありうる）に接続されるようにしてもよい。以下詳述されるように、確認エンジン34は、ユーザープロファイル・データベース30内に格納されたユーザープロファイル28の確認および更新過程を開始するために、ローカルサーバ38(及び／又は、場合により公衆サーバ40)を介して様々なユーザに送られるべき確認通知を(好ましくはEメール形式で)生成する。

ポータル24は使用中にユーザ確認・プロファイル管理システムを用いて、一つ以上のユーザ・インタフェース14にログオンしたユーザにアプリケーション18及び／又は18Aへのアクセス権を提供し、さらにまた、定期的な自動ユーザ確認手順を実施する。特に、一実施形態では、ユーザ確認・プロファイル管理システムは、一人以上のユーザによる一つ以上のアプリケーション18Aへのアクセスを提供するポータル24の一部として機能する。この場合、ユーザがポータル24にログオンし、アクセスするべきアプリケーション18Aを選択すると、セキュリティ・エンジン32はまず、確認データベース36内に格納されている確認情報に基づいて、ユーザープロファイル・データベース30に格納されている該ユーザのユーザープロファイル28が有効かどうか判断するためのチェックを行う。該ユーザのユーザープロファイル28が現在有効な場合、ポータル24はアプリケーション18Aへのアクセス権を与える。この工程の一環として、ポータル24内のアプリケーション18Aまたはセキュリティ・エンジン32は、ユーザのユーザープロファイル28の詳細情報、又はアプリケーション18A内に格納されたその他の情報に基づいて、該ユーザに与えられているセキュリティレベルまたはアクセスレベルを判断することができる。

図2は、セキュリティ・エンジン32およびユーザ確認・プロファイル管理システムが、ユーザ確認工程を実施するために一人以上のユーザ14およびアプリケーション18及び又は18Aと論理的に交流（対話）する状態をブロック図の形式で示す。特に、ワークステーション14のユーザの一人がアプリケーション18Aにアクセスしようと試みると、確認エンジン34はまず、そのユーザのユーザープロファイル28が有効かどうかを判断する。図2に示されるように、一実施形態において、各ユーザープロファイル28は、関連する(図1の確認データベース36に格納されている)一組（セット）の確認データ42を含んでおり、確認エンジン34はユーザープロファイル28の有効性を判断するためにこれを使用する。確認データ42の各組には、前回に確認システムで生成された確認用Eメールに関連付けられている日付を格納する二つの確認フィールドが含まれるようにしてもよく、また、確認エンジン32は、前もって定義した確認規則に基づいて、特定のユーザープロファイル28が現在有効かどうか判断するためにこれらのフィールドを使用する。ユーザまたはそれに関連するユーザープロファイル28が有効ならば(すなわち、ユーザープロファイル28に、ユーザがアプリケーション18Aにアクセスしてよいことを示すデータが含まれる場合)、ユーザープロファイルの詳細情報に基づいてアプリケーション18Aへのアクセス権が該ユーザに提供される。

さらに、いかなるアプリケーション18Aは、ユーザープロファイル28を使用して、それ自体のセキュリティまたはアクセス情報を格納することができ、また、アプリケーション18Aからユーザに提供されるべきアクセスのレベルを判断することができる。ユーザープロファイル28が無効と判断された場合、当該のユーザには依頼したアプリケーション18Aへのアクセス権が与えられない。しかしここで注目すべき点は、ユーザープロファイル28は、それに関連するユーザが特定のアプリケーション18Aへのアクセス権を持っている(すなわち、ユーザが前記アクセスが適応する役職名、機能などを持っている)と示しているにもかかわらず、それでもなお確認データベース36に格納された確認データに基づいて無効とされる場合があるということである。この場合、ユーザープロファイルが無効であると判断されたので、ユーザープロファイル内に格納されるデータが何であろうとそれに関係なく、ポータル24内のセキュリティ・エンジン32は、ユーザに所望のアプリケーションへのアクセスを許可しない。

一般的にユーザ確認システム30は、自動ユーザ登録、ユーザープロファイル管理インターフェースおよび、Eメールを介した、及び又はオンライン上の作業よる各ユーザ、各ユーザの上司および一人以上の直属の部下または各ユーザの下で働く者との定期的な通信やプロファイル確認作業の手段を提供することにより、ユーザープロファイル情報の収集・検証および配布を自動化する。具体的には、確認システム30は、ユーザと該ユーザに関連する一人以上のユーザ（例えば、ユーザの上司およびユーザの直属の部下など）の組織内における関係に関しての収集及び格納された情報を用いて組織階層ツリーを作成し、ユーザが自分自身と組織階層ツリー上で自分に直接的つながりを持つ者の確認、移転の標示、あるいは解除を行うことを可能にする。

上述されるように、確認システムへのユーザ・インタフェースには、ポータル・アプリケーションを使用することができ、それによって上記されるセキュリティ機能の実行に加えて、アプリケーション18Aおよび望ましい場合はアプリケーション18（これらアプリケーションにアクセスするユーザは該システムにより確認・維持管理される）にアクセスするためのログイン・センターを提供できる。本説明からも明らかなように、ユーザープロファイルの確認は、組織内のある特定の部署または組織の系列会社（例えば、人事部、情報技術部など）から又はそれらに送信されてくる従業員のステータス（状態）に関する入力に依存することなく、電子メールのメッセージを介して又はウェブ・ページにログインして達成される。

また、一旦確認システムの環境設定が整い正常に機能するようになると、確認システムが確認データベース36内の確認データ42を更新する要求をユーザに対して自動的かつ定期的に行うので、規則的かつ定期的にユーザープロファイルの確認を行うことができる。確認システムやシステムそのもの、又はシステムのコンフィギュレーションを実施するためには、まず「確認グループ」と呼ばれる二つ以上の異なるユーザ・グループ（各ユーザが、一つの（一つに限る）確認グループだけに属することを特徴とする）を定義する。一実施形態において、確認システム30は、二つの異なる確認グループ、いわゆる「V群」だけを使用して、ユーザープロファイル確認を実行するが、別の実施形態では二つ以上のグループを使用できる。確認グループが二つの場合には、ユーザの上司（一人以上）およびあらゆる直属の部下（一人以上）またはユーザの下で働く者（一人以上）を、まず各ユーザごとに定義することにより、確認グループが判断されうる。ここで定義される関係によりユーザ組織図が事実上定義される。その後、各ユーザが、組織図に基づいて二つの異なる確認グループのうちの一つ（一つのみ）に対して定義される又は割り当てられる。

図3は、二つの確認グループまたはV群が、V群1およびV群2として定義されている組織階層ツリー50を示す。図3に示されるように、まず組織内の上司／ユーザ／部下関係に基づいて階層的階層ツリーを構築することにより確認グループを判断することができる。なお、階層的階層ツリー上の関係は、初期段階では登録により、またそれ以降には確認工程そのもの又はユーザによりなされたプロファイルの更新を通してのいずれかにより収集しうる。組織階層ツリー50が判断されると、二つの確認グループV群1およびV群2が、図3に示されるように階層ツリーにおいて交互に配置されるレベルとして定義される。当然のことながら、図3における階層ツリー50の各ボックスは単一のユーザーに関連しており、ユーザの上側に直接に連結されたボックスはユーザの上司を表し、ユーザの下側に直接に連結されたボックスはユーザの下で働くものまたは直属の部下を表す。図3に示されるように、階層ツリー50においてレベルは交互に、それぞれ異なる確認グループV群1およびV群2を形成するか又はそれに関連する。一旦組織に対して確認グループが定義されると、これらのグループは、確認データベース36(図1に図示)または望ましい場合はその他のあらゆるデータベースまたはメモリに格納されうる。

確認グループが定義された後、確認エンジン34が、確認期間ごと（この実施例では2週間ごととして定義される）に、ターゲット・グループと呼ばれる確認グループのうちの一つに含まれるユーザのもとに、好ましくはEメールの形式で一組の確認通知を発送する。確認通知の目的は、ユーザ本人および場合によっては一人以上の自分以外の組織内のユーザが依然として有効なユーザーであることを検証するようにユーザを促すことにある。一実施形態においては、該ターゲット・グループは確認期間ごとに、確認グループ間で変更または交替する。したがって、例えば、第1の確認期間として1月2日に確認用EメールがV群1に送信されるとすると、第2の確認期間として1月16日に確認用EメールがV群2に送信され、その後第3の確認期間として1月30日に確認用Eメールが再びV群1に送信されるといった状態で、それ以降も同様に継続される。もちろん、確認期間は2週間に制限されず、その代りに組織の必要性に最も適した時間間隔で2週間以上またはそれ以下の期間に設定することができる。当然のことながら、ユーザ確認システムは、2週ごとに(またはその他の設定された確認期間ごとに)各ユーザを確認するが、その際、あらゆる特定のユーザは確認用Eメールを4週ごとに(または設定されている確認期間の2倍の長さの期間ごとに)一度だけ受信するような方法で該確認を行う。

一旦確認用Eメールが現在の確認期間のターゲット・グループのもとに送信されると、確認システムは、ターゲット・グループに含まれる各ユーザに対して、自分自身と、組織階層ツリー50において該ユーザの上側に直接に連結している一人以上のユーザ(通常前記ユーザの上司)と、組織階層ツリー50において前記ユーザの下側に直接に連結している一人以上のユーザ(通常前記ユーザの直属の部下または前記ユーザの下で働く者)とを確認するように要求する。このように、ユーザが確認を完了すると、現在の確認期間において自分自身、自分の上司、および自分のあらゆる直属の部下または自分の下で働く者を効率的に確認したことになる。通常は、組織階層ツリー50において直接連結する二人のユーザが同じ確認グループに割り当てられることはないので、これらのユーザが同時にまたは同じ確認期間中に確認用Eメールを受信することはない。すなわち、組織階層ツリー50において直接連結するユーザは、お互いの雇用状態に関して最も正確な情報を持っていると推定され、これらユーザがお互いに確認し合うことにより、より正確でより安全な確認工程を行えることになる。また、組織階層ツリー50の異なるレベルでお互いと直接連結するユーザは、連続する２期の確認期間中に一度だけ（本実施例では、4週間ごとに一度だけ）確認用Eメールを受け取る必要がある。しかしながら、V群1に含まれるユーザが組織階層ツリー50上で各自の上側および下側のV群2に属するユーザを確認し、またその逆の場合も同様に確認が行われるので、実際には各確認期間に（ここでは、2週間ごとに）各ユーザの確認が行われることになる。

以下の説明には、確認データベース36を更新するために確認用Eメールを使用して、組織内のユーザ確認を定期的かつ適時に行えるようにする一態様に関する実施例が述べられているが、ここに記載される詳細は当然のことながら、ここに記載されるユーザ確認・プロファイル管理システムを実行できる様々な方法に変更または改造しえる。

図4は、ユーザが自分自身および場合により一人以上の自分以外の他のユーザを確認する確認工程を開始するためにユーザのもとに送信されうる確認用Eメール52の一実施例を示す画面を表示している。図4に示されるように、確認用Eメール52は、確認システムへのリンク56に加えて、確認工程についての簡単なメッセージ54を含みうる。望ましい場合は、ユーザのプロファイルに格納され且つ組織内のユーザを識別するために使用できるユニークな（ユーザ固有の）値またはID(図示せず)をリンク56に含みうる。ユーザがリンク56をクリックすると、ユーザコンピュータ14は、確認を行なうために使用される確認ページを提供する確認システムに関連付けられている確認サーバ(例えば、図1のローカルサーバ38でありえる)を検索して見つけるためのブラウザを開く。このような確認表示画面またはページ60の一例が図5に示される。リンク56内のユニークIDまたはコードからユーザの自己識別要素（アイデンティティ）を判断することができるので、確認サーバ38は、ユーザによるログインを必要とせずに確認60ページを生成し、確認ページ60を使用してユーザに自分以外の上司と直属の部下を検証するように依頼することができる。図5に示されるように、確認ページ60は、ユーザの上司、Eメール、勤務地およびその他必要とされる情報を識別する、または明確に不明瞭な点が無いように上司を定義するのに役立つ、欄62を含んでいる。同様に、組織階層50(図3)で定義されるように、確認ページ60はユーザの直属の部下またはその下で働く者すべてのアイデンティフィケーション（本人識別情報）を有する欄64を含んでいる。

確認ページ60は、上司および部下を含む各自について、その者が現時点でもなお同じ役職にあること、異なる役職に変更したこと、及び組織から離職したことのうちの少なくとも一つを示す機会をユーザに提供する。図5に示される上司の場合、ユーザは上司に関する更なる検証を行うことなく、そのまま「Done（完了）」のボックス66をクリックしてもよい。しかしながら、上司が組織から離職した場合、ユーザは「Done(完了)」のボックス66をクリックする前にボックス68をクリックする。またユーザは、「Change(変更)」のボックス70を使用して、該ユーザの上司の変更または該ユーザの上司についての情報の変更を指定できるそれ以降のページ(図示せず)を読み出すことができる。但し、上司のEメールは確認用Eメールを該上司に送信する際に使用されるEメールアドレスであるため、セキュリティ目的のためにユーザが上司のEメールを変更できないようにし、上司本人で変更するようにすることが望ましい。

欄64に示される直属の部下の場合、ユーザは、その直属の部下の状態（例えば、現時点でもなおユーザのもとで働いている、あるいは組織内の異なる部署または組織体に移動した、または組織から離職した、など）を、例えば該当するチェックボックスをクリックして指定することができる。その後「Done(完了)」のボックス66をクリックすると、処理のためにこれらの変更または検証内容が検証システムに送信されて処理される。大抵の場合、検証システムは指示された変更の記憶は行うが、検証システムの管理担当者によるOK又は承諾無しではユーザープロファイル28に変更を加えない場合がある。いずれにせよ、検証ページ60においてはボックス62が一つだけユーザの上司について図示されているが、望ましい場合はユーザが一人以上の上司を検証するようにしてもよい。但し、前記されるような特定のユーザの上司の各々が同確認グループに割り当てられ、且つユーザとは異なる確認グループに割り当てられることが好ましい。また、特定のユーザの直属の部下が一人だけである場合も多くある。しかし、自分以外のユーザ(密接に関連するユーザと呼ばれる)が上司であろうと直属の部下であろうと、各ユーザが自分以外のユーザを少なくとも一人を確認するようにすることが一般的に望ましく、また多くの場合そうすることが必要となりうる。図示されていないが、「Done(完了)」のボックス66をクリックすることによりユーザが現時点でもなお有効であることを示すことになる。したがって、図5の確認ページ60にはユーザが自分自身を確認する特定の場所が含まれていないが、ユーザは、自分以外の密接に関連するユーザを確認するか否かの動作でページ60に応答するだけで確認を行うことができる。もちろん、望ましい場合は、確認用Eメールに応答するユーザに対して特別な又は個別の確認欄を用意することができる。

一旦ユーザが確認ページ60を完了すると、確認されたユーザはその確認期間において確認システム内で有効であると見なされるか、又は確認済みとしてマーキングされる。

もちろん、この最終目的は、確認工程をできるだけ単純な構成にすることにより、2期の確認期間ごとに確認工程を完了させなければならないユーザに混乱をもたらしたり多大な時間を要する作業が生じたりすることを防ぐことにある。したがって、確認ページ60は、ユーザにとって便宜で使い易い設計であるものとする。

確認用Eメールに応答するユーザにより提供されるフィードバックに応じて、確認エンジン32は、確認データベース36内の確認データ42を更新し、上記されるようにユーザープロファイルがシステムにおいて有効かどうか判断するためにこのデータベース36を用いる。

ユーザが自分自身と自分以外のユーザを適切に検証することを可能にする一実施形態において、各々のユーザ履歴（記録）は、V組1およびV組2と称される一組の日付フィールドを含んでいる。このようなユーザ履歴80の一実施例が図6に示されている。この場合、一組の日付フィールドV組1およびV組2は「Sent Date（送信日）」の入力欄82と「Received Date（受信日）」の入力欄84のそれぞれを含んでいる。ここで当然のことながら、図6に示されるユーザ履歴80は、第2の確認グループV群2に含まれるユーザのものである。この場合、確認用Eメールが(V群2に属する)ユーザのもとに送信される度に、日付がV組2フィールドの送信日のフィールドに記録される。該ユーザが確認用Eメールに応答すると、その日付はV組2フィールドの受信日のフィールドに記録される。もちろんユーザがV群1に属している場合は、送信日と受信日はV組1フィールドに記録される。

同様に、確認用EメールがV群2に含まれるユーザと密接に関連するユーザ(この場合、密接に関連するユーザはV群1に含まれる)に送信される度に、日付が、該ユーザのV組1フィールドの送信日の欄に記録される。V群1に含まれる密接に関連するユーザがV群2に属するユーザを確認して確認用Eメールに応答すると、その日付が該ユーザのV組1フィールドの受信日のフィールドに記録される。

このように確認用Eメールが確認グループのいずれかに含まれるユーザのもとに送信されると、Eメールが送信されたユーザ履歴および、ユーザの全ての上司と全ての直属の部下(すなわち、確認用Eメールが送信されたユーザに密接に関連するユーザの全ての者)の履歴の送信日が現在の日付(すなわち、確認用Eメールが発送された日付)に設定される。この動作の一例が図7に示されており、特定のユーザ90(V群2に含まれる)と、該特定のユーザの上司92と該特定のユーザの部下94(両者ともV群1に含まれる)を含む三人の密接に関連するユーザを示している。図7に示される場合において、2006年3月1日に行われたユーザ履歴90に対応するユーザ(確認グループV群2に含まれる)への確認用Eメールの送信により、上司の履歴（Manager Record）92と、ユーザ履歴（User Record）90と、直属の部下の履歴（Direct Report Record）94とのそれぞれが2006年3月1日の日付に設定される。ユーザ履歴90に対応するユーザ（V群2に含まれる）が、自分自身およびならびに上司92と直属の部下94の確認工程を完了すると、上司の履歴92とユーザ履歴90と直属の部下の履歴94のそれぞれに対応するV組2フィールド内の受信日フィールドがその時の現在の日付に更新される。この動作は図8に示されており、同図において、V群2に含まれるユーザ履歴90に関連付けられているユーザは、2006年3月1日付けの確認用Eメールに対して2006年3月7日に応答し、それによって上司92および直属の部下94の両者ともを確認している。該ユーザ90が上司92及び直属の部下94の１人または両者を確認しなかった場合、上司の履歴92及び／又は直属の部下の履歴94のV組2の受信日には2006年3月7日の日付が書き込まれない。同様に、ユーザ履歴90に関連付けられているユーザが確認用Eメールに全く応答しない場合は、図8に示されるV組2の履歴の受信日フィールドは一つも設定またはリセットされない。

理解されるように、確認用Eメールが、第1の確認グループV群1に含まれるユーザに送信される時にも同じような操作が実施され、それによって、これらのユーザの履歴および該ユーザに密接に関連するユーザの履歴に関するV組1フィールド内の送信日が、確認用Eメールが送信された日付に設定される。同様に、V群1に含まれるユーザが確認用Eメールに返信することにより、これらのユーザおよび該ユーザが確認することになっている密接に関連するユーザに関するV組1の履歴中の受信日フィールドが、前記応答日に設定される。

その後、ユーザが、例えばインターネットやエクスターネット（Externet）などを介してシステムまたはポータル24にアクセスしたり、又はLAN12（図1）上で組織のイントラネットにログインしたりすると、確認システムは、ユーザ履歴中のV組1およびV組2の両フィールドの送信日と受信日をチェックすることにより、ユーザに関する現在の確認ステータスを簡単に判断できる。一般的に、ユーザが正当なユーザとして判断されるためには、特定のユーザ履歴の両方のV組フィールドが有効となっていなければならない。一実施形態において、確認エンジン34は、特定のユーザのV組データが有効かどうか判断するために三つの規則を適用しうる。具体的に言うと、確認エンジン34は、(1)受信日の値が送信日の値より大きい（受信日が送信日より最近の日付)かどうかを判断する。そうである場合、ユーザを有効なユーザとされる。しかしながら、上記(1)でない場合、確認エンジン34は、(２)「本日」の日付がV組の確認期間(つまり、送信日＋2週間)以内に当て嵌まるかどうかを判断する。そうである場合も、ユーザ(または該ユーザに密接に関連するユーザの１人)が最も最近の確認用Eメールに応答する時間がまだ残っているので、該ユーザは有効なユーザとして見なされる。さらに、確認エンジン34は、(3)特定のV組フィールドに日付が入力されていない場合（これは該ユーザが新規ユーザープロファイルとして最近追加された者であることを意味する）に、該ユーザが有効なユーザであると判断しえる。一般的に、特定のユーザ履歴のV群と一致するV組フィールド(V群2に対するV組2)内のデータが無効の場合は、該ユーザには以降の確認用Eメールが送信されず、ポータル24にホストされるアプリケーションへのアクセス権が与えられないことになる。また、該V群に対する他のV組フィールド(V群2に対するV組1)内のデータが無効の場合、ユーザは、ポータル24によりホストされるアプリケーションへのアクセス権を得ることはできないが、確認Eメールは受信することになる。しかしながら、所望の場合は、ユーザはいつでも確認工程を完了させてもよく、またそれによって直ちに自分自身および場合により一人以上の密接に関連するユーザのアクセス権を回復することができる。

確認期間の長さ(組織により指定される)をV組送信日に加算することによりV組の確認期間を判断することができる。本実施例では確認期間は2週間となっている。したがって、V組の送信日が2006年6月2日である場合、そのV組の確認期間は2006年6月2日〜2006年6月16日である。ユーザまたは密接に関連するユーザが該V組を確認し、該ユーザが新しい確認Eメールを受信し、それによってV組の送信日がリセットされるまで、V組確認期間は変更されない。もちろん、確認期間をその他の方法によっても判断することができ、当然のことながら、このような場合のすべてにおいて、システムは、受信日が送信日に対して特定の期間内にあるかどうか検出することにより有効状態を判断する。（前記特定の期間は、確認依頼がいつ送信されるかにかかわらず確認期間の開始日で定義される。例えば、その月の第一日目などの特定された日付から、又は確認依頼の送信日そのものから計算して定義できる。）

図9〜11には、確認エンジン34が密接に関連するユーザ三人のユーザ履歴90、92および94内の日付フィールドを使用し、このデータに基づいてユーザープロファイルが有効かどうか定義するための方法に関する具体的な例が３件示されている。図9の実施例では、前回の確認期間が2006年2月15日から2006年2月28日までであった。2006年2月15日に、V群1に含まれるユーザ(つまり、上司の履歴92に対応する上司、および直属の部下の履歴94に対応する部下)に確認用Eメールが送信された。V群1に含まれるユーザが確認工程を完了すべき期日は2月28日であった。この実施例において、上司92は2006年2月19日に返信し、また直属の部下は2006年2月23日に返信した。また、ユーザ90(V群2に含まれる)の受信日には、V組1フィールドに対して2006年2月23日に設定された受信日が入力されており、該ユーザの直属の部下94が2月23日に該ユーザを確認したことを示している。しかしながらこの場合、上司92もまた2006年2月19日にユーザ90を確認しているが、しかし、この日付は直属の部下がユーザ90を確認した時に2月23日に上書きされている。

なお、本実施例においては、現在の確認期間が3月1日から3月14日まである。V群2用の確認用Eメールは2O06年3月1日に送信され、また、V群2に含まれるユーザ90が、自分のアカウントおよび場合によっては上司のアカウント92とあらゆる直属の部下のアカウント94が差し止められてしまう前に確認を完了できる期日は3月15日である。ここで図9に示される各ユーザ(つまり、上司92、ユーザ90および直属の部下94)は有効なユーザとして見なされることになる。特に、V組1フィールドに指定されるように、前回の確認期間に上司および直属の部下が該ユーザの確認を行うとともに、次の確認期間が始まる前にユーザ90が確認工程を完了させた場合のみに、該ユーザ90は有効状態を維持できる。なお、V組2フィールドの受信日は設定されていないが、現在の確認期間内にある。すなわち、ユーザ90が、2006年3月1日付けで該ユーザ90に送信された確認用Eメールに応答すべき期日は3月15日である。

図10は、無効なユーザのアカウントに対応する2006年4月3日のデータベースの状態を示す。ここで注目すべき点は、ユーザ90、92および94の各々のV組1フィールドが有効となっていることである。しかし、受信日が送信日よりも前の日付であり、現在の日付がV組2の確認期間内ではない（すなわち、4月3日は3月15日〜3月29日間の日付ではない）ので、V組2フィールドは、ユーザ90、92または94のいずれについても有効ではない。これと対照的に、図11には、一組の有効なユーザアカウントを示す実施例を示す。たとえV組2で受信日が送信日より前の日付であっても、送信日が現在の確認期間以内にある（すなわち、3月1日は3月1日〜3月15日間の日付である）ので、両方のV組は有効である。このため、V群2に含まれるユーザが、アカウントが無効と見なされないようにするには、3月15日までに確認を完了させなければならない。

理解されるように、特定のユーザが、それに関連する複数の密接に関連するユーザを含みえる場合もある。この場合、特定のユーザが確認用Eメールを受信しない確認期間中に、該ユーザに密接に関連するユーザの一人にそのユーザを確認させるようにすれば十分でありえる。したがって、確認用Eメールを受信しない確認休止期間中に確認される必要のあるユーザが有効状態を維持するためには、密接に関連するユーザの一人によってのみ確認さればよいことになりえる。しかしながら、望ましい場合、且つ、より優れたセキュリティ[レベル]を提供する目的で、確認エンジン34を、特定のユーザの有効状態を維持するために該特定のユーザに密接に関連するユーザそれぞれに該特定のユーザを確認することを要求するように設定してもよく、或いは、確認エンジン34が、密接に関連するユーザの応答が特定のユーザの有効状態を維持するのに十分であるかどうかを判断するために、投票方式（例えば、3票中2票、５票中3票などの投票方式）を使用するようにしてもよい。

上司が直属の部下を一人だけ持っており、その部下が離職した場合などに生じうるシナリオとして、ユーザが離職し、その上司が該ユーザの確認を必要とするなどの場合には、ユーザの解雇または移転が検出された際は、離職する該ユーザが確認を担当する確認期間については、システムが自動的に上司を確認するようにしてもよい。通常、任意の密接に関連するユーザにより(例えば、直属の部下のたった一人による)上司が一度「権限解除（解雇）」されたりすると、その上司により「解雇」への変更が承諾されるか拒絶されるまで、その上司は権限停止（停職）状態になる。また、上司が組織から離職した場合は、システムが指定の期間後に該上司の停職状態を「解雇」の状態に変更する。

本書に記載されるシステムには、各ユーザの企業Eメールアドレス、上司および直属の部下の企業Eメールアドレスが使用されているので、一実施形態では公開ドメインにおけるEメールアドレスに依存しない又はそれを使用しない。しかし、システムを「なりすまし」[行為]から守るために好ましくはその他適切なファイアウォール、ログイン手順などの安全予防手段を備えるという条件で、このような公開ドメインEメールアドレスを使用してもよい。

ユーザ確認システムは、上記されるように初期のユーザ確認を行なうことに加えて、ユーザープロファイル内の情報に基づいて一人以上のアプリケーション18および18Aに様々なサブレベル（下位レベル）のアクセスを提供するためにユーザープロファイルを制御し更新するために用いることができる。特に、プロファイル変更に関する一貫した見直し検討や、セキュリティ・アプリケーション内のユーザのセキュリティ設定に必要な更新を怠ると、一般的に適切なレベルのセキュリティも、システム内ユーザープロファイルの初期設定でしか効果をもたらさない。しかしながら、組織の中ではユーザープロファイルを変更しなければならないような出来事が数多く発生し、それによって組織の資源を介して利用可能な特定のアプリケーションへのアクセスに関する変更が必要になる可能性がある。例えば、極秘性の高い販売情報へのアクセスは、直接雇用の従業員すべてに公開しうるが、組織に関連する系列会社の従業員には制限される。しかしながら、ある従業員が系列会社に移転した場合などには、販売情報へのアクセスを妨げた状態でその他のポータル・アプリケーションまたは特定のアプリケーションの機能へのアクセスを維持できるような状態で、従業員のステータスを変更するべきである。別の実施例として、顧客アカウント戦略情報へのアクセスを、顧客アカウントを担当する販売員には許可しえるが、その他の残りの販売員には制限することが挙げられる。この例において、販売員が組織における役割を変更し、もはや特定の顧客アカウントを担当しない場合は、その販売員はアカウント情報にアクセスさせるべきでない。さらに別の例として、製品トレーニングへのアクセスを、特定の部門）だけが利用できるようにし、競合製品のラインアップを取り扱う第三者の代表者が存在する部門に対しては制限することが挙げられる。但し、従業員が部門を変更すれば、この従業員が製品トレーニング用アプリケーションにアクセスできないようにすべきである。

一般的に、従来はこれらすべての変更およびその他数多く考えられる組織内における変更が発生した時点で、好ましくはアプリケーション管理担当者が役職変更の対象となっているユーザのセキュリティ設定を修正変更すべきかどうかを見直し検討し、判断していた。しかしあいにくのところ多くの場合において、このような見直し検討が全くもしくは適時に行われることがなかった。プロファイルの変更が遂行されない主な理由としては、アプリケーション所有者が、ユーザのプロファイル変更を通知する際に、人事部などをはじめとする組織内の一つ以上の部署に依存しなければならないということが挙げられる。結果として、このような通知が行われない、またはあまり迅速に行われないということが多くあり、さもなければ、この業務を担当する部署が、例えば、第三世界各国に所在する系列会社の事務所に設置されている場合もあり、該業務の信頼性が多少低くなりえるといった状態である。したがって多くの場合において、及び様々な理由により、組織内における変更が生じたために、一つ以上の部署を使って手作業でユーザープロファイルを更新したり、アプリケーション所有者に通知したりする場合には信頼性が低下する。

この問題を克服または解消するために、ユーザが確認用Eメール内のリンクを介して、又はポータル24に設置されるプロファイル管理システムにより随時、各自のプロファイルを更新するようにしてもよい。また、ユーザが、密接に関連するユーザの移転を知らせるようにしてもよい。この更新工程には、上司または直属の部下の解雇が含まれるが、必ずしもこれらに限定されない。この結果、解雇されたユーザに対しては直ちに、ポータル24、およびポータル24内又はそのポータルを通じてホストされたアプリケーションへのアクセスが差し止められる。しかしながら、所望の場合、いずれかのフィールドに変更が生じた時に通知を送信する代わりに、あるユーザープロファイルの特定のフィールドが変更された場合だけに警告を出す、及び／又は外部アプリケーションを更新するように確認システムを構成できる。これらの特定のフィールドは、必要に応じて特定のユーザのセキュリティ設定を変更内容に基づいて更新できるアプリケーション管理担当者により変更が検討されるべきものとして選択することができる。

したがって、本書に記載される確認システムはまた、組織内において変更が生じた時にユーザープロファイル情報を更新して、様々なユーザによる各種アプリケーションへの適切なアクセスを可能にする又は許可するために使用することができる。具体的には、上記に図1を参照して説明されているように、ユーザ確認システムは、ユーザープロファイルの一部として各ユーザについての情報（例えば、氏名、会社名、事業部、Eメールアドレス、役職名、上司の氏名など）を維持管理する。そして、図5の確認ページ60によって、各ユーザは自分自身及び場合によっては自分以外の密接に関連するユーザに関する該情報を変更又は更新することを可能にする。但し、場合によっては、ユーザが勝手に許容範囲外のアクセス[権]を自分に与えることが出来ないようにするために、又は不注意により、或いはことによると例えば不満を持つ従業員によって故意にシステムから他のユーザがロックアウトされるような事態を防ぐために、ユーザープロファイルへの変更を実施前に上司または他の者に提出して評価検討を受けるようにしてもよい。

ここではユーザープロファイル情報はポータル24により局所的（ローカル）に格納されると説明されているが、その代わり又はそれに加えて、直通データベース通信、XML、およびURLに基づいた通信などを含む、様々な通信方式を通じてリアルタイムで、ポータル24内でホストされるアプリケーション18Aにこの情報を配信してもよく、その後、外部アプリケーション18Aおよび18が該当する出来事（イベント）に適すると見なされるあらゆる処置を取ることができるようになる。当然のことながら、これらの場合においては、ポータル24は、外部アプリケーション18Aまたは18との通信がユーザに許可されるべきかどうかに関してのみ判断し、ユーザが持つアクセスのレベルや、ユーザが見ることができる内容を判断する工程については、アプリケーション18Aまたは18内に格納されているユーザープロファイルやその他の情報に基づいてアプリケーション18Aまたは18が行うことができる。

なおまた、本書に記載されるユーザ確認・プロファイル管理システムは各ユーザの上司および直属の部下情報をトラッキング（追跡）する。このため、該システムは、ユーザープロファイルおよび定義されているV群に基づいて、いつでも正確な組織階層ツリーを作成（構築）することができる。このような組織階層ツリー100の実施例が図12に示されている。報告関係構造の変更は、確認工程中に行ったり、その他いつでも例えばポータル24専用のホームページ上で「Organization Information（組織情報）」の入力欄を介して行なうことができる。また、不満を持つ又は悪意ある従業員同士が共謀し、自分たちと他のユーザの間に偽のリンクを作成して確認システムを操作・悪用するといった可能性を防止するために、該システムにより組織内の変更を加える前に待機期間を設定するようにしてもよい。例えば、該システムは、組織情報の変更を許可する前に、ユーザおよびユーザの前上司に申請中の組織変更内容に同意することを要求することができる。関与するユーザのいずれもが該変更への同意を拒否することができる。最後に、この実施例においては、ポータル管理担当者が申請内容を検討し、変更に対する最終的な承認または不承認を提供することができる。いかなる場合においても、ユーザがある上司から別の上司[の管理下に移る、または組織内においてその他の変更を行った場合に、システムは自動的に組織階層ツリー100を修正（再計算）することができる。移転に関与する全員が該工程中にユーザまたは上司の解雇を選択できるので、このタイプの出来事（イベント）は確認の必要性を暗黙的に示唆する。したがって、所望の場合、当工程において移転の対象となっているユーザおよびユーザの上司の両者をシステムにより確認することができる。

上述の確認工程では二つの確認グループおよび2組の確認日（各ユーザ確認履歴について「送信日」と「受信日」をそれぞれ含むV組1とV組2）が採用されているが、システムは、二つ以上の確認グループおよび2組以上の日付を含むように設計してもよい。一実施例として、後述されるように確認期間を2週間として、三つの確認グループおよび3組の日付を採用するようにしてもよい。

上述のように、確認システムは、各ユーザを（ユーザが確認用Eメールを受信する際に用いられる）適確な確認グループに適切に割り当てられるか否かに依存する。本実施例において、ユーザは、三つの確認グループV群1、V群2またはV群3のうちの一つに割り当てられる。当初は登録により収集され、その後には確認工程そのもの又はユーザによるプロファイルの変更のどちらかの方法を通じて収集されたユーザ／上司関係のデータに基づいて階層的階層ツリーを構築し、確認グループが判断される。一旦組織階層ツリーが構築されると、次の論理の適用によりV群が判断されうる。

(1) 上司でない（つまり、直属の部下を持たない）ユーザはV群1に割り当てられる。
(2) 上司である（つまり、直属の部下を少なくとも一人持っている)ユーザはV群2に割り当てられる。
(3) V群2の上司が階層ツリーの下位から上位に向かって検討（審査）され、V群2の上司がV群1に含まれる直属の部下を少なくとも一人持っていなければ、該上司はV群3に割り当てられる。

システムが階層ツリーを順次上位方向に移動して次のレベルに来ると、システムは、V群2の上司がV群1またはV群3のいずれかに含まれる直属の部下を少なくとも一人持っていなければ、その上司がV群3に割り当てられるようにV群2の上司のチェックマークを変更する。

図13は、V群1とV群2のユーザの初期設定が確立される上記最初の2段階を実行した後に作成（完成）された組織階層110を示す。図14は同じ組織階層110を示すが、これはV群2の上司の中から特定の者をV群3の上司として再定義するための前記第3の段階を適用した後のものである。上記第3段階を行う理由は、階層ツリー110の異なる確認グループにおいてユーザに直接つながる他のユーザが、必ず各々のユーザに対して少なくとも一人存在することを確実にするためである。実際、階層ツリー110に含まれる上司の全ては、Eメールを受信するタイミングが自分と逆の確認グループに割り当てられている直属の部下を少なくとも一人持っていなければならない。このようにすると、組織階層ツリー110上で関連し且つお互いに確認し合う責任を負う２人のユーザが、確認用Eメールを同時に(即ち、同じ確認期間中に)受信することがなく、またさらに１人のユーザが４週間ごと一回より多く（即ち、確認期間２期ごとに一回より多く）Eメールを受信することもない。例えば、図14に示されるユーザ112と114など、階層ツリー110上で相互直接に関連するユーザが同じ確認グループに含まれている場合、これらのユーザは互いに確認し合う必要がない。これは、ユーザ112および114に直接に関連しており確認作業を遂行できる他のユーザが別の確認グループ(V群1またはV群3)に存在するためである。

前述の二つの確認グループに関して説明される場合とはわずかに異なった方法例として、確認用Eメールを各確認期間に、確認グループV群1およびV群3に含まれるユーザのもとに、或いは確認グループV群2に含まれるユーザのもとに送信して、確認期間ごとに確認用Eメール送信のターゲット群を交替してもよい。ここで、確認用Eメールは、確認グループV群1とV群3のユーザのもとに同時に送信される。したがって、当座の目的に対しては、これらのグループは論理的に見て一つのグループと見なされうる。当機能は階層ツリー上でつながっている二人のユーザが同じ確認期間中に確認用Eメールを受信しないようにするために用いられる。例えば、V群1およびV群3への確認用Eメールが1月2日に送信されるとすると、V群2への確認用Eメールは1月16日に送信され、そして再び1月30日に確認用EメールがV群1およびV群3に送信される、等となる。

ここで、確認システムは、V群1に割り当てられた各ユーザ(直属の部下)に対して、組織階層ツリー110上で自分の上に直接連結するユーザを確認することを要求する。V群2に割り当てられたユーザ(上司)には、組織階層ツリー110上で自分の上下に直接連結するユーザを確認することを要求する。このように、各ユーザは、確認を完了することにより、現在の確認期間において自分および該当する場合は自分の上司と直属の部下を事実上確認したことになる。再度述べるが、二つの確認グループを採用した場合と同様に、特定の一ユーザは確認期間2期ごとに2回以上確認用Eメールを受信しないようになっている。なおまた、一確認グループのユーザが、組織階層ツリー110において直接上位の及び／又は下位の確認グループのユーザを確認するので、各ユーザは、4週間(確認期間2期)ごとに一回だけ確認用Eメールを受信する間、2回確認されることになる。

本実施例の図15に示されるように、すべてのユーザ履歴120はそれぞれV組1とV組2および「個人の日付」と呼ばれる3組の確認日付フィールド122を含む。各一組の確認フィールド122は図15に示されるように「送信日」と「受信日」を含む。当然のことながら、各V組は、組織階層ツリー110に含まれる互いに直接つながるユーザ(つまり、密接に関連するユーザ)間でリンクされる。ある日付が、一ユーザ履歴内の一V組に割り当てられると、同じ日付が関連する１以上のユーザ履歴内でリンクされる日付に割り当てられる。例えば、V群1のメンバーに確認用Eメールが送信される度に、ユーザ履歴およびユーザの上司の履歴の両方におけるV組1の日付フィールドのうち送信日が現在の日付に設定される。「個人の日付」フィールドはV群1のユーザには使用されない。この動作の実施例が、直属の部下(V群1内)の履歴130および上司(V群2内)の履歴132に関して図16に示されている。

また、V群2またはV群3のメンバーに確認用Eメールが送信される度に、ユーザの履歴、ユーザの直属の部下の履歴、およびユーザの上司の履歴内のV組2の日付の組のうち送信日が現在の日付に設定される。この動作の実施例が、図16と同じユーザ履歴130および132に関して図17に示されている。さらにV群2およびV群3の場合、図17に示されるように、ユーザ履歴において上司の履歴132をについて、個人の日付内の日付の対のうち送信日が現在の日付に設定される。ユーザが確認工程を完了すると、リンク先のユーザの対応する受信日が当時の現在の日付に更新される。

簡潔に述べると、本実施例では次の規則によりV組に日付を割り当てる。
(1) V群1とV群3には常に同じ日付に確認用Eメールが送信される。
(2) V群1のユーザが確認用Eメールを受信すると、V組1の送信日に現在の日付が設定される(V組1の送信日は密接に関連するユーザ間でリンクされている)。
(3) V群2またはV群3のいずれかのユーザが確認用Eメールを受信すると、V組2の送信日に現在の日付が設定される。V組2とV組3は「上司」グループと見なすことができ、これらのグループのユーザは常に直属の部下を少なくとも一人持っている(V組2の送信日は密接に関連するユーザ間でリンクされている。)
(4) V群2またはV群3のユーザが確認用Eメールを受信すると、「個人の日付」の送信日に現在の日付が設定される。「個人の日付」の送信日は他のV群の「個人の日付」の送信日にリンクされておらず、確認用Eメールを受信するユーザだけに設定される。
(5) V群1に含まれるユーザに対しては「個人の日付」が設定されない。
(6) V群1のユーザが確認を行った場合、リンク先のV組1受信日がV群1およびV群2に対して設定される。
(7) V群2のユーザが確認を行った場合、V群1、V群2およびV群3においてリンク先のV組2受信日が設定される。
(8) V群３のユーザが確認を行った場合、V群2およびV群3においてリンク先のV組2受信日が設定される。
(9) ユーザが確認を完了しなかった場合、そのユーザは確認を行うまで新しい確認用Eメールを受信しない。
(10) リンク先のV組の日付は常に、無効となっているユーザについても更新される。
(11) V群2またはV群3のユーザが確認を行ったときに「個人の日付」の受信日が設定される。「個人の日付」はV群間ではリンクされていない。

このような設定を使用することにより、確認システムはユーザのログイン時に、ユーザ履歴内のV組1、V組2および個人の日付フィールドの送信日と受信日を確認（検査）することによりユーザの現在の確認状態を簡単に判断できる。ユーザが有効と見なされるには、全日付グループが有効でなければならない。ここで、以下三つの規則のいずれかが該当する（真である）場合、確認エンジン34によりV組フィールドが有効であると判断される。

(1) 受信日の値が送信日の値よりも大きい（受信日が送信日よりも最近の日付の）場合。
(2) 上記の(1)が該当しない（真ではない）場合、本日の日付がV組の確認期間（例えば、送信日＋2週間）以内である場合。
(3) 送信日フィールドおよび受信日フィールドの両方に日付が入力されていない場合。

特定のユーザ履歴のV群に一致するV組(V群2に対するV組2)のフィールド内のデータが無効の場合は、それ以降該ユーザには確認用Eメールが送信されなくなり、ポータル24によりホストされるアプリケーションへのアクセスが許可されない。該V群における別のV組(V群2に対するV組1)のフィールド内のデータが無効の場合、それ以降該ユーザはポータル24によりホストされるアプリケーションへのアクセスを拒否されるが、確認用Eメールは受信し続ける。

一実施例として、上司の履歴(V群3)140、上司の履歴(V群2)142および直属の部下の履歴(V群1)144が第1の確認サイクル中に提示する状態を、図18に示している。確認期間は2006年2月24日に開始する。確認用Eメールはその日にV群1とV群3のもとに送信される。図18の矢印145は、V群1とV群2内のV組1の送信日間のリンク、およびV群2とV群3内のV組2の送信日間のリンクを示す。V群3のユーザの「個人の日付」の送信日も2月24日に設定される。また、図18には、ユーザ144が2006年3月3日に自分自身を確認し、さらに密接に関連するユーザ142を確認したことが示されている。矢印146は、履歴144および142のV組1フィールドについての該確認を示す。

確認期間を2週間とした場合、次回確認用Eメールの組は2006年3月10日にV群2のもとに送信される。確認用Eメールがその日に送信され、V群1のユーザが2006年3月3日に確認を行ったと仮定した時に提示されるユーザ履歴の状態が図19に示されている。V群1およびV群2のV組1のリンクされた受信日(矢印146で示される)は、ユーザ144による上司142の確認を反映している。図18と同様に、V群2の履歴142内のV組2の送信日は、矢印147により示されるように、下側のV群1と上側のV群3内のV組2の送信日にリンクされる。ここで、3月10日〜3月24日の確認期間（つまり、2006年3月24日以前）におけるユーザ140、142および144の確認状態を要約すると次のようになる。

1) 「個人の日付」の受信日が空白で、「個人の日付」の送信日が現在の確認期間内（3月10日〜3月24日）でないため、V群3のユーザ＝無効。
2) 履歴142のV組がすべて確認規則3件に則り有効とされるため、V群2のユーザ＝有効。
3) 履歴144のV組がすべて確認規則3件に則り有効とされるため、V群1のユーザ＝有効。

ここで本実施例においては、次回確認用Eメールの組は、図20に示されるように、2006年3月24日にV群1およびV群3のもとに送信されることになっている。図20の矢印148により示されるとともにユーザ履歴142の「個人の日付」の受信日フィールドに示されるように、2006年3月21日にV群2のユーザ142が、自分自身および上司140と直属の部下144の両者を確認したとする。以上のように、V群1、2、3のV組2フィールドの受信日はすべてリンクされており、2006年3月21日の日付に更新された。また、V群2のユーザ142に対する「個人の日付」の受信日は2006年3月21日に設定された。V群3のユーザ140がこの期間に確認用Eメールを受信しなかったことは注目すべき重要点である。これは、履歴140の「個人の日付」の受信日フィールドが空白となっていることからも分かるように、該ユーザが2006年2月24日〜2006年3月10日の期間中に確認を行わなかったために、該ユーザのアカウントは現在無効となっているからである。したがって、V群3およびV群2のV組2の送信日は2006年3月10日のままとなっている。「個人の日付」の受信日の値が、「個人の日付」の送信日の値を上回っておらず、さらに「本日」（3月26日）が2月24日から3月10日までの確認期間外である。ここで、2006年3月26日におけるユーザの確認状態は次のように要約できる。

(1)「個人の日付」の受信日の値＜「個人の日付」の送信日の値であり、「本日」（3月26日）が「個人の日付」の送信日から開始する確認期間(2月24日〜3月10日)外であるため、V群3のユーザ＝無効。
(2) V組のすべてが確認規則3件に則り有効であるため、V群2のユーザ＝有効。
(3) V組のすべてが確認規則3件に則り有効であるため、V群1のユーザ＝有効。

本実施例によると、図21に示されるように、次回確認用Eメールの組は、4月7日にV群2のユーザ142のもと送信されることになっている。ここで、V群1のユーザが4月4日にユーザ142を確認したことが矢印149により示されている。たとえV群3が有効でなくても、V群3のV組2の送信日は、V群2のV組2の送信日にリンクされているため更新される。個人の日付は2006年2月24日のままである。ここで、2006年4月11日におけるユーザ140、142および144それぞれのユーザ状態は次のように要約される。

(1) 次により、V群3のユーザ＝無効：
V組2： 受信日＞送信日
個人の日付： 「個人の日付」の受信日＜「個人の日付」の送信日、且つ「本日」の日付(4月11日)が「個人の日付」の送信日に開始する確認期間(2月24日〜3月10日)外である。

(2) 次により、V群2のユーザ＝有効：
V組1： 受信日＞送信日
V組2： 受信日＜送信日だが、「本日」の日付(4月11日)がV組の確認期間(4月7日〜4月21日)内である。
個人の日付： 受信日＞送信日

(3) 次により、V群1のユーザ＝有効：
V組1： 受信日＞送信日
V組2： 受信日＜送信日だが、「本日」の日付(4月11日)がV組の確認期間(4月7日〜4月21日)内にある。

もちろん、上記されるように、ユーザが確認工程を次回の確認期間が開始する前に完了させた場合のみに、該ユーザは有効状態を維持できる。それを怠った（行わなかった）場合には、該ユーザのアカウントおよび、場合によっては自分の上司及び／又は直属の部下のアカウントが無効となる。すなわち、ポータル24またはその内のアプリケーション18A、またはポータル24により管理されるアプリケーション18にアクセスできなくなる。無効となったユーザは、確認工程を完了することによって、アクセス権をいつでも自分および上司や直属の部下全員に対して直ちに回復することが可能である。

本発明による数多くの異なる実施形態が上記詳述されているが、当然のことながら、本発明の範囲は、本願の「特許請求の範囲」の記載により定義される。すべてのあらゆる実施形態を説明することは不可能でないとしても現実的ではないため、前記詳細な説明は代表的な例としてのみ解釈されるべきであり、本発明により実施可能な実施形態のすべてを示すものではない。現代の技術または本特許出願後に開発された技術の任意のものを使うことにより、本発明を定義する特許請求の範囲に含まれる実施例をその他数多く実施することが可能である。

したがって、本発明の精神と範囲から逸脱することなく、ここに記載される技法と構成により多種多様の改造および変形が可能である。よって、当然のことながら、本書に記載される方法と装置は単なる実施例であり、本発明の範囲を限定するものではない。

複数のユーザ・アプリケーション、複数のユーザ・インタフェース機器、およびユーザ確認・プロファイル管理システムを含む組織関連コンピュータ・ネットワークのブロック概略図である。 図1のネットワーク内のユーザ確認・プロファイル管理システムの動作を示すブロック図である。 図1および図2のユーザ確認・プロファイル管理システムの複数からなる確認グループを定義するために使用される組織図または組織階層を表す図である。 図1と図2のユーザ確認・プロファイル管理システムで送信することができる確認用Eメールを表示する例示的な表示画面である。 図1と図2のシステム内の一人以上のユーザを確認するために用いられる確認ページに関連する画面表示部を表す図である。 ユーザープロファイルの有効性を判断するための２組の確認フィールドを有するユーザ履歴（記録）の一実施例を示す図である。 密接に関連するユーザに関する３つのユーザ履歴が確認用Eメールに応答して更新される方法を示す図である。 密接に関連するユーザに関する３つのユーザ履歴が確認用Eメールに応答して更新される方法についてさらに別の実施例を示す図である。 第1の実施例に関連する密接に関連するユーザに関する３つのユーザ履歴を示す図であって、これらユーザ履歴と関連するユーザープロファイルの有効性または無効性が判断される。 第2の実施例に関連する密接に関連するユーザに関する３つのユーザ履歴を示す図であって、これらユーザ履歴と関連するユーザープロファイルの有効性または無効性が判断される。 第3の実施例に関係する密接に関連するユーザに対する三つのユーザ履歴を示す図であって、これらユーザ履歴と関連するユーザープロファイルの有効性または無効性が判断される。 ユーザの上司／部下関係を示す、ユーザープロファイルから作成された組織図または組織階層を表す図である。 図1と図2のユーザ確認・プロファイル管理システムにおける三つの確認グループを定義するために初期段階において用いられる組織図または組織階層を表す図である。 図1と図2のユーザ確認・プロファイル管理システムにおける三つの確認グループを定義する組織図または組織階層を表す図である。 関連するユーザープロファイルの有効性を判断するための3組の確認フィールドを有するユーザ履歴（記録）を示す図である。 図15に示すタイプの、密接に関連するユーザについてのユーザ履歴が、確認用Eメールに応答して更新される方法の第1の実施例を示す図である。 図15に示すタイプの、密接に関連するユーザについてのユーザ履歴が、確認用Eメールに応答して更新される方法の第２の実施例を示す図である。 密接に関連するユーザについての、確認フィールド三つを有する、３つのユーザ履歴であって、これらのユーザ履歴に関連するユーザープロファイルの有効性または無効性を初回に判断する実施例に関連する、３つのユーザ履歴を示す図である。 密接に関連するユーザについての、確認フィールド三つを有する、３つのユーザ履歴であって、これらのユーザ履歴に関連したユーザープロファイルの有効性または無効性を第２回目に判断する実施例に関連する、３つのユーザ履歴を示す図である。 密接に関連するユーザについての、確認フィールド三つを有する、３つのユーザ履歴であって、これらのユーザ履歴に関連したユーザープロファイルの有効性または無効性を第３回目に判断する実施例に関連する、３つのユーザ履歴を示す図である。 密接に関連するユーザについての、確認フィールド三つを有する、３つのユーザ履歴であり、これらのユーザ履歴に関連したユーザープロファイルの有効性または無効性を第４回目に判断する実施例に関連する、３つのユーザ履歴を示す図である。

符号の説明

１０ コンピュータ・ネットワークシステム
１２ ＬＡＮ
１４ ユーザー・ワークステーション
１６ コンピュータ
１８ アプリケーション
２４ ポータル
２６ ノード
２８ ユーザープロファイル
３０ データベース
３２ セキュリティ・エンジン
３４ 確認エンジン
３６ 確認データベース
３８ ローカルサーバ
４０ ＷＷＷサーバ

Claims (48)

1. コンピュータ・ネットワーク内でユーザ確認システムが複数ユーザの状態を電子的に判断する方法であって、
   前記ユーザ確認システムが、記憶装置と、確認依頼発生器と、有効性分析装置と、を備え、
   前記方法が、
   前記ユーザ確認システムが、コンピュータ・ネットワークへのアクセスを有する第1のユーザおよび第2のユーザそれぞれの状態指標を前記記憶装置のメモリに記憶すること、
   前記ユーザ確認システムが、第1のユーザの組に第1のユーザを割り当て、第2のユーザの組に第2のユーザを割り当てて前記メモリ内のテーブルに記憶すること、
   前記確認依頼発生器が、第1のユーザの組に含まれる第1のユーザのもとに自動的且つ定期的に第1の電子確認依頼を送信して、第1のユーザに第2のユーザの状態を確認することを依頼する第1の電子確認依頼への応答を要求すること、
   前記有効性分析装置が、第1の電子確認依頼に対する第1のユーザからの応答を受け取ることによって、第2のユーザの状態指標の有効性を判断すること、
   前記確認依頼発生器が、第2のユーザの組に含まれる第2のユーザのもとに自動的且つ定期的に第2の電子確認依頼を送信して、第2のユーザに第1のユーザの状態を確認すること依頼する第2の電子確認依頼への応答を要求すること、
   前記有効性分析装置が、第2の電子確認依頼に対する第2のユーザからの応答を受け取ることによって、第1のユーザの状態指標の有効性の判断すること、
   を含む、方法。
2. 前記確認依頼発生器が、第1および第2の電子確認依頼を異なるタイミングで交互に送信することをさらに含む、請求項1に記載の複数ユーザの状態を電子的に判断する方法。
3. 第1のユーザが第2のユーザの上司または直属の部下のうちの一人であることを特徴とする、請求項1に記載の複数ユーザの状態を電子的に判断する方法。
4. 前記有効性分析装置による、第1の電子確認依頼に対する第1のユーザからの応答を受け取ることにより行われる第2のユーザの状態指標の有効性の判断が、第1の電子確認依頼に対する第1のユーザからの応答が第1の電子確認依頼に関連する所定期間内に送信されたかどうかの判断を含むことを特徴とする、請求項1に記載の複数ユーザの状態を電子的に判断する方法。
5. 前記有効性分析装置による、第2の電子確認依頼に対する第2のユーザからの応答を受け取ることにより行われる第1のユーザの状態指標の有効性の判断が、第２の電子確認依頼に対する第2のユーザからの応答が第2の電子確認依頼に関連する所定期間内に送信されたかどうかの判断を含むことを特徴とする、請求項1に記載の複数ユーザの状態を電子的に判断する方法。
6. 前記確認依頼発生器による第1のユーザに対する第1の電子確認依頼の送信が、第1の電子確認依頼の一部として第2のユーザの状態指標を送信することを含み、
   前記有効性分析装置による、第1の電子確認依頼に対する第1のユーザから応答を受け取ることにより行われる第2のユーザの状態指標の有効性の判断が、第1の電子確認依頼に対する第1のユーザからの応答において、第1のユーザが、第1の電子確認依頼により通知される第2のユーザの状態指標に同意するかどうかの判断を含むことを特徴とする、請求項1に記載の複数ユーザの状態を電子的に判断する方法。
7. 前記確認依頼発生器による第2のユーザに対する第2の電子確認依頼の送信が、第2の電子確認依頼の一部として第1のユーザの状態指標を送信することを含み、
   前記有効性分析装置による、第2の電子確認依頼に対する第2のユーザから応答を受け取ることにより行われる第1のユーザの状態指標の有効性の判断が、第2の電子確認依頼に対する第2のユーザからの応答において、第2のユーザが、第2の電子確認依頼により通知される第1のユーザの状態指標に同意するかどうかの判断を含むことを特徴とする、請求項6に記載の複数ユーザの状態を電子的に判断する方法。
8. 前記ユーザ確認システムが前記メモリに第1および第2ユーザそれぞれについての状態指標を記憶することが、第1および第2ユーザがコンピュータ・ネットワーク内で使用できる権限を定義する、第1および第2ユーザそれぞれのプロファイル情報を前記メモリに記憶することを含むことを特徴とする、請求項1に記載の複数ユーザの状態を電子的に判断する方法。
9. 前記ユーザ確認システムが前記メモリに第1および第2ユーザそれぞれについての状態指標を記憶することが、第1および第2ユーザがコンピュータ・ネットワークを介して利用可能なアプリケーション内で使用できる権限を定義する、第1および第2ユーザそれぞれのプロファイル情報を前記メモリに記憶することを含むことを特徴とする、請求項1に記載の複数ユーザの状態を電子的に判断する方法。
10. 前記有効性分析装置が、第1の電子確認依頼に対する第1のユーザからの応答を受け取ることにより第1のユーザの状態指標の有効性を判断することを更に含む、請求項1に記載の複数ユーザの状態を電子的に判断する方法。
11. 前記有効性分析装置が、第2の電子確認依頼に対する第2のユーザからの応答を受け取ることにより第2のユーザの状態指標の有効性を判断することを更に含む、請求項10に記載の複数ユーザの状態を電子的に判断する方法。
12. 前記確認依頼発生器が、第1および第2電子確認依頼を同じ周期で定期的に送信する一方、第2の電子確認依頼から該周期の期間の約2分の1をオフセット（差し引き計算）したタイミングで第1の電子確認依頼を送信することをさらに含む、請求項1に記載の複数ユーザの状態を電子的に判断する方法。
13. 前記ユーザ確認システムが、第1のユーザ用の第1の記憶フィールドおよび第2のユーザ用の第2の記憶フィールドを前記メモリに作成すること、
    前記ユーザ確認システムが、第1および第2の電子確認依頼に対する応答の指標を第1および第2の記憶フィールドに記憶すること、および
    前記有効性分析装置が、第1の記憶フィールドに記憶された情報に基づき第1のユーザの状態指標の有効性を特定の時点において判断し、且つ第2の記憶フィールドに記憶された情報に基づき第2のユーザの状態指標の有効性を特定の時点において判断すること、
    をさらに含む、請求項1に記載の複数ユーザの状態を電子的に判断する方法。
14. 前記ユーザ確認システムが、第1および第2電子確認依頼に対する応答の指標を第1および第2記憶フィールドに記憶することが、第1の記憶フィールド内の第1の記憶場所に第2のユーザのもとに第2の電子確認依頼がいつ送信されたかの指標を記憶し、第1の記憶フィールド内の第2の記憶場所に第2の電子確認依頼に対する応答がいつ受信されたかの指標を記憶することを含むことを特徴とする、請求項13に記載の複数ユーザの状態を電子的に判断する方法。
15. 前記有効性分析装置が、第1の記憶フィールドに記憶された情報に基づいて第1のユーザの状態指標の有効性を特定の時点において判断することが、第2の電子確認依頼に対する応答が、第2の電子確認依頼が送信された時に対して特定の期間内に受信されたかを判断することを含むことを特徴とする、請求項14に記載の複数ユーザの状態を電子的に判断する方法。
16. 前記記憶装置が、第1の記憶フィールドの第3の記憶場所に第1ユーザのもとに第1の電子確認依頼がいつ送信されたかの指標を記憶し、第1の記憶フィールド内の第4の記憶場所に第1の電子確認依頼に対する応答がいつ受信されたかの指標を記憶することを更に含む、請求項14に記載の複数ユーザの状態を電子的に判断する方法。
17. 前記有効性分析装置が、第1の記憶フィールドに記憶された情報に基づいて第1のユーザの状態指標の有効性を特定の時点において判断することが、第1の電子確認依頼に対する応答が、第1の電子確認依頼が送信された時に対して特定の期間内に受信されたかを判断することを含むことを特徴とする、請求項16に記載の複数ユーザの状態を電子的に判断する方法。
18. 前記有効性分析装置が、第1の記憶フィールドに記憶された情報に基づいて第1のユーザの状態指標の有効性を特定の時点において判断することが、第1の電子確認依頼に対する応答が第1の電子確認依頼が送信された時に対して特定の時間内に受信されたかを判断することと、第2の電子確認依頼に対する応答が第2の電子確認依頼が送信された時に対して特定の期間内に受信されたかを判断することを含むことを特徴とする、請求項16に記載の複数ユーザの状態を電子的に判断する方法。
19. 前記ユーザ確認システムが、第1および第2電子確認依頼に対する応答の指標を第1および第2記憶フィールドに記憶することが、第2の記憶フィールドの第1の記憶場所に第1の電子確認依頼のうちの一つが第1ユーザのもとにいつ送信されたかの指標を記憶することと、第2の記憶フィールドの第2の記憶場所に第1ユーザからの第1の電子確認依頼の一つに対する応答がいつ受信されたかの指標を記憶すること、第2の記憶フィールドの第3の記憶場所に第2のユーザのもとに第2の電子確認依頼がいつ送信されたかの指標とを記憶することと、第2の記憶フィールドの第4の記憶場所に第2ユーザから第2の電子確認依頼に対する応答がいつ受信されたかの指標を記憶することを含むことを特徴とする、請求項14に記載の複数ユーザの状態を電子的に判断する方法。
20. コンピュータ・ネットワーク内でユーザ確認システムが複数ユーザの状態を電子的に判断する方法であって、
    前記ユーザ確認システムが、記憶装置と、確認依頼発生器と、有効性分析装置と、を備え、
    前記方法が、
    前記ユーザ確認システムが、コンピュータ・ネットワークへのアクセスを有する複数のユーザそれぞれに関する状態指標を前記記憶装置のメモリに記憶すること、
    前記ユーザ確認システムが、複数のユーザのそれぞれを第1のユーザの組または第2のユーザの組のいずれかに割り当てて前記メモリ内のテーブルに記憶すること、
    前記確認依頼発生器が、第1のユーザの組に割り当てられた一人以上の第1ユーザのそれぞれに第1の電子確認依頼を自動的且つ定期的に送信して、第2のユーザの組に割り当てられた少なくとも一人の第2ユーザの状態を確認するために第1の電子確認依頼に応答することを、該第1のユーザの組に含まれる一人以上の第1のユーザに要求すること、
    前記有効性分析装置が、第1の電子確認依頼に対する一つ以上の応答を受け取ることによって第2のユーザの組に含まれる第2のユーザの少なくとも一人の状態指標の有効性を判断すること、
    前記確認依頼発生器が、第2のユーザの組に割り当てられた一人以上の第2ユーザのそれぞれに第2の電子確認依頼を自動的且つ定期的に送信して、第1のユーザの組に割り当てられた少なくとも一人の第1ユーザの状態を確認するために第2の電子確認依頼に応答することを、該第2のユーザの組に含まれる一人以上の第2のユーザに要求すること、
    前記有効性分析装置が、第2の電子確認依頼に対する一つ以上の応答を受け取ることによって第1のユーザの組に含まれる第1のユーザの少なくとも一人の状態指標の有効性を判断すること、
    を含む、方法。
21. 前記確認依頼発生器が、第1の電子確認依頼の送信と、第2の電子確認依頼の送信を異なるタイミングで交互に行うことをさらに含む、請求項20に記載の複数ユーザの状態を電子的に判断する方法。
22. 前記有効性分析装置が、第1の電子確認依頼に対する一つ以上の応答を受け取ることによって第2のユーザのうちの一人の状態指標の有効性を判断することが、第1の電子確認依頼に対する一つ以上の応答のうちの一つが所定期間内に送信されたかどうか判断することを含むことを特徴とする、請求項20に記載の複数ユーザの状態を電子的に判断する方法。
23. 前記有効性分析装置が、第2の電子確認依頼に対する一つ以上の応答を受け取ることによって第1のユーザのうちの一人の状態指標の有効性を判断することが、第2の電子確認依頼に対する一つ以上の応答のうちの一つが第2の所定期間内に送信されたかどうか判断することを含むことを特徴とする、請求項22に記載の複数ユーザの状態を電子的に判断する方法。
24. 前記確認依頼発生器が、一人以上の第1のユーザのそれぞれに対して第1の電子確認依頼を送信することが、少なくとも一つの第1の電子確認依頼の一部として第2のユーザの少なくとも一人の状態指標を送信することを含み、
    前記有効性分析装置が、第2のユーザの少なくとも一人の状態指標の有効性を判断することが、前記第1の電子確認依頼の少なくとも一つを受信した第1のユーザが、少なくとも一つの第1の電子確認依頼内に送信された少なくとも一人の第2のユーザの状態指標に同意しているか否かを判断することを含むことを特徴とする、請求項20に記載の複数ユーザの状態を電子的に判断する方法。
25. 前記ユーザ確認システムが前記メモリに複数のユーザそれぞれの状態指標を記憶することが、複数のユーザそれぞれのプロファイル情報を記憶することを含み、ある特定のユーザのプロファイル情報がコンピュータ・ネットワーク内の該特定のユーザのアクセス権を定義することを特徴とする、請求項20に記載の複数ユーザの状態を電子的に判断する方法。
26. 前記有効性分析装置が、第1のユーザのうちの一人のもとに送信された第1の電子確認依頼のうちの一つに対する前記第1のユーザの一人からの応答を受け取ることによって、前記第1のユーザのうちの一人の状態指標の有効性を判断することを更に含む、請求項20に記載の複数ユーザの状態を電子的に判断する方法。
27. 前記確認依頼発生器が、第1の電子確認依頼と第2の電子確認依頼を同じ周期で定期的に送信する一方、第2の電子確認依頼から該周期の期間の約2分の1をオフセット（差し引き計算）したタイミングで第1の電子確認依頼を送信することをさらに含む、請求項20に記載の複数ユーザの状態を電子的に判断する方法。
28. 前記ユーザ確認システムが、第1の電子確認依頼のうちの一つに対する応答に関する第1の応答情報と第2の電子確認依頼のうちの一つに対する応答に関する第2の応答情報を複数のユーザそれぞれについて前記メモリに記憶することと、
    前記有効性分析装置が、特定の時点に特定のユーザについて記憶された第1および第2応答情報によって、複数のユーザの特定のうちの一人の状態指標の有効性を特定の時点において判断することをさらに含む、請求項20に記載の複数ユーザの状態を電子的に判断する方法。
29. 前記ユーザ確認システムが前記メモリに前記特定のユーザの第1の応答情報を記憶することが、第1の電子確認依頼のうちの一つが第1のユーザのうちの一人のもとにいつ送信されたかの指標を記憶することと、第1のユーザの一人からの第1の電子確認依頼のうちの一つに対する応答がいつ受信されたかの指標を記憶することを含むことを特徴とする、請求項28に記載の複数ユーザの状態を電子的に判断する方法。
30. 前記有効性分析装置が、第1および第2応答情報に基づいて複数のユーザの特定の一人の状態指標の有効性を特定の時点において判断することが、第1の電子確認依頼の一つに対する応答が第1の電子確認依頼の一つに関連する特定の期間内に受信されたかどうか判断することを含むことを特徴とする、請求項29に記載の複数ユーザの状態を電子的に判断する方法。
31. 前記ユーザ確認システムが前記メモリに前記特定のユーザの第2の応答情報を記憶することが、第2の電子確認依頼のうちの一つが第2のユーザのうちの一人のもとにいつ送信されたかの指標を記憶することと、第2のユーザの一人からの第2の電子確認依頼の一つに対する応答がいつ受信されたかの指標を記憶することを含むことを特徴とする、請求項29に記載の複数ユーザの状態を電子的に判断する方法。
32. 前記有効性分析装置が、第1および第2応答情報に基づいて複数のユーザの特定の一人の状態指標の有効性を特定の時点において判断することが、第2の電子確認依頼の一つに対する応答が第2の電子確認依頼の一つに関連する特定の期間内に受信されたかどうか判断することを含むことを特徴とする、請求項31に記載の複数ユーザの状態を電子的に判断する方法。
33. コンピュータ・ネットワークで使用されるユーザ確認システムであって、
    メモリと、
    メモリにコンピュータ・ネットワークへのアクセスを有する複数のユーザそれぞれの状態指標を記憶するよう構成される記憶装置と、
    第1のユーザが第1のユーザの組に含まれ、第2ユーザが第2のユーザの組に含まれるように、第1のユーザの組または第2のユーザの組のどちらかに複数のユーザをそれぞれ関連付ける、メモリに記憶されたテーブルと、
    確認依頼発生器であって、
    第1の電子確認依頼のうちの一つに応答することにより第2のユーザの組に含まれる第2のユーザの少なくとも一人の状態の確認することを、第1のユーザの組の一人以上の第1のユーザのそれぞれに要求するために、第1のユーザの組に含まれる一人以上の第1のユーザそれぞれのもとに第1の電子確認依頼を自動的且つ定期的に送信し、
    第2の電子確認依頼のうちの一つに応答することにより第1のユーザの組に含まれる第1のユーザの少なくとも一人の状態の確認することを、第2のユーザの組の一人以上の第2のユーザのそれぞれに要求するために、第2のユーザの組に含まれる一人以上の第2のユーザそれぞれのもとに第2の電子確認依頼を自動的且つ定期的に送信する、確認依頼発生器
    と、
    第1の電子確認依頼と第2の電子確認依頼に対する応答を受信し、第1の電子確認依頼と第2の電子確認依頼に対する応答の受信に関連する情報を示す指標をメモリに記憶するよう構成される応答ユニットと、
    複数のユーザの少なくとも一人に関連する、第1の電子確認依頼および第2の電子確認依頼に対する応答の受信に関連する記憶された情報に基づいて、複数のユーザの少なくとも一人の状態指標の有効性を判断するよう構成される有効性分析装置と
    からなる、コンピュータ・ネットワークで使用されるユーザ確認システム。
34. 記憶装置が複数のユーザそれぞれのユーザープロファイルを記憶するよう構成されることを特徴とする、請求項33に記載のユーザ確認システム。
35. 確認依頼発生器が、複数の連続する確認期間のそれぞれにおいて第1の電子確認依頼を少なくとも一回は生成して送信し、複数の連続する確認期間のそれぞれにおいて第2の電子確認依頼を少なくとも一回は生成して送信し、
    確認依頼発生器が、第2の電子確認依頼から確認期間の約2分の1をオフセット（差し引き計算）したタイミングで第1の電子確認依頼を送信することを特徴とする、請求項33に記載のユーザ確認システム。
36. 確認依頼発生器が第2の電子確認依頼とは異なるタイミングで第1の電子確認依頼を生成し送信することを特徴とする、請求項33に記載のユーザ確認システム。
37. メモリが各ユーザに対する応答情報フィールドを含み、
    応答ユニットが、第2のユーザの一人から受信された、第2の電子確認依頼のうちの一つに対する応答に関する情報を、それぞれの第1のユーザについて記憶するよう構成されることを特徴とする、請求項33に記載のユーザ確認システム。
38. 応答ユニットが、第1のユーザの一人からの、第1の電子確認依頼のうちの一つに対する応答に関する情報を、それぞれの第２のユーザのために記憶するよう構成されることを特徴とする、請求項37に記載のユーザ確認システム。
39. 応答ユニットが、第2の電子確認依頼のうちの一つに対する応答が第2のユーザの一人からいつ受信されたかに関する情報を、第1のユーザのそれぞれに対して記憶するよう構成されることを特徴とする、請求項37に記載のユーザ確認システム。
40. メモリが複数のユーザのそれぞれに対する応答情報フィールドを含み、
    第1のユーザのそれぞれに対する応答情報フィールドが、第2の電子確認依頼のうちの一つが第2のユーザのうちの一人のもとにいつ送信されたかに関する情報と、第2のユーザのうちの一人のもとに送信された第2の電子確認依頼の一つに対する第2のユーザの一人からの応答がいつ受信されたかに関する情報を記憶するよう構成されることを特徴とする、請求項33に記載のユーザ確認システム。
41. 第2のユーザのそれぞれに対する応答情報フィールドが、第1の電子確認依頼のうちの一つが第1のユーザのうちの一人のもとにいつ送信されたかに関する情報と、第1のユーザの一人からの第1の電子確認依頼の一つに対する応答がいつ受信されたかに関する情報とを記憶するよう構成されることを特徴とする、請求項40に記載のユーザ確認システム。
42. 第1のユーザのそれぞれに対する応答情報フィールドがさらに、第1の電子確認依頼のうちの一つが第1のユーザのうちの一人のもとにいつ送信されたかに関する情報と、第1のユーザの一人からの第1の電子確認依頼の一つに対する応答がいつ受信されたかに関する情報とを記憶するよう構成されることを特徴とする、請求項40に記載のユーザ確認システム。
43. 有効性分析装置が、第1のユーザの一人のもとに送信された第1の電子確認依頼の一つに対する第1のユーザの一人からの応答が、第1の電子確認依頼の一つに関連する所定期間内に受信されたかどうかに基づいて、第1のユーザのうちの一人の状態指標の有効性を判断することを特徴とする、請求項42に記載のユーザ確認システム。
44. 有効性分析装置が、第2の電子確認依頼の一つに対する第2のユーザの一人からの応答が、第2の電子確認依頼の一つに関連する所定期間内に受信されたかどうかに基づいて第1のユーザの少なくとも一人の状態指標の有効性を判断し、さらにまた、第1のユーザの一人のもとに送信された第1の電子確認依頼の一つに対する第1のユーザの一人からの応答が、第1の電子確認依頼の一つに関連する所定期間内に受信されたかどうかに基づいて、第1のユーザのうちの一人の状態指標の有効性を判断することを特徴とする、請求項42に記載のユーザ確認システム。
45. 有効性分析装置が、第2の電子確認依頼の一つに対する第2のユーザの一人からの応答が、第2の電子確認依頼の一つに関連する所定期間内に受信されたかどうかに基づいて、第1のユーザの少なくとも一人の状態指標の有効性を判断することを特徴とする、請求項40に記載のユーザ確認システム。
46. 確認依頼発生器が、第2のユーザの少なくとも一人の状態指標を含むよう第1の電子確認依頼のうちの一つを生成し、第1の電子確認依頼の一つを受信する第1のユーザが第1の電子確認依頼の一つに対する応答において、第2のユーザの少なくとも一人の状態指標に同意するか又は同意を拒否できるようにすることを特徴とする、請求項33に記載のユーザ確認システム。
47. 確認依頼発生器が、第2のユーザの少なくとも一人の状態指標を含むよう第1の電子確認依頼のうちの一つを生成し、第1の電子確認依頼の一つを受信する第1のユーザが第1の電子確認依頼に対する応答において、第2のユーザの少なくとも一人の新規状態指標を示すことが可能になるようにすることを特徴とする、請求項33に記載のユーザ確認システム。
48. 複数のユーザのうちのいずれか特定の一人がコンピュータ・ネットワークを介して利用可能な一つ以上のアプリケーションにアクセスすることを、有効性分析装置により判断された該複数のユーザのうちのいずれか特定の一人の状態指標の有効性の判断に基づいて、許可または拒否するよう構成されるアクセス・ポータルを更に含む、請求項33に記載のユーザ確認システム。

Images