JP2009211728A - データ及びリソースに対するアクセス制御を有するウェブベースセキュリティ - Google Patents

Abstract

【課題】スポンサー組織のデータ及び他のリソースへのアクセス制御を提供するウェブベースのセキュリティアプリケーションを提供する。
【解決手段】（１）セキュリティで保護された情報へのアクセスの制御、（２）スポンサー組織と間接的及び直接的関係を有するユーザへのアクセスを可能にすること、（３）中央情報技術リソースからセキュリティシステムのユーザへのセキュリティ管理の分配、（４）異なる環境内への組込みに対するサポート、及び（５）システム統括者に対するサポートという５つの主要な一面を有し、「ウェブ」ベース及び「ＩＶＲ」ベースのセルフサービス機能に使用可能である、スポンサー組織のセキュリティ保護情報及びセルフサービス機能へのアクセスを制御する独立型セキュリティシステム。
【選択図】図１

Description

関連出願
本出願は、本明細書においてその全内容が引用により組み込まれる２００１年８月１４日出願の米国特許仮出願一連番号第６０／３１１，８２１号に対する優先権を請求するものである。
著作権に関する通知
本特許文書の開示の一部は、著作権保護を受ける内容を含んでいる。著作権「所有者」は、特許文書又は特許開示内容が米国特許庁の特許ファイル又は記録にある場合、何人によるその複製にも異存はないが、他の場合は著作権のいかなる権利もその全てを保有するものである。
本発明は、スポンサー組織のデータ及び他のリソースへのアクセス制御を提供するウェブベースのセキュリティアプリケーションに関する。

医療関連会社のようなスポンサー組織は、彼らのデータ及び他のリソースに「ワールド・ワイド・ウェブ」のような分散型情報検索システムを通じてアクセスするクライアントを有する。このようなスポンサー組織には、スポンサー組織のためのセキュリティで保護された情報及びセルフサービス機能へのアクセスを制御する独立型セキュリティシステムが必要である。このようなセキュリティシステムの基本的要件は、以下の通りである。
１．ユーザＩＤは、特定の個人及びその個人のみに付随するものとする。
２．システムは、登録前にスポンサー組織に既知ではなく、スポンサー組織とその従業員を通じて間接的な関係を有する人々の登録を処理すべきである。この要件により登録処理が必要になる。
３．システムを使用するために、各ユーザは、システムを使用するコンテキストを定義すべきである。一般に、そのコンテキストは、ユーザが勤務する組織である。一般的に、これらの組織は、スポンサー組織とは異なるものである。コンテキストを有することは、どのような種類のビジネス機能及びデータがユーザに利用可能であるかを決定することになる。セキュリティで保護されたログオンアプリケーション内では、コンテキストをエンティティと呼ばれる。これらのエンティティの各々も登録すべきである。
４．ユーザは、複数のコンテキスト内で勤務し、尚かつ同じユーザＩＤを使用することができる。
５．ユーザが異なれば、勤務するエンティティ内で果たす役割も異なるべきである。この要件は、役割をユーザに割り当てる方法があるべきであることを意味する。
６．システムにログオンした時、各ユーザには、自分の役割が許されているビジネス機能のみを含むメニューが呈示されるべきである。
７．エンティティ内のセキュリティ活動の毎日の管理をこれらのエンティティに分配すべきである。
８．アクセス識別子は、バックエンドシステム内のデータへのキーを与えるために、エンティティと関連付ける必要がある。
９．セキュリティシステムは、１つのスポンサー組織内であっても複数の環境内に組み込む必要がある。
１０．１つの組織がそのアクセス権を別の組織に委任し、従ってその第２の組織が第１の組織に代わって作業することができることが可能であるべきである。
１１．複数のアクセス識別子を有する大きなエンティティの場合、アクセス識別子のグループ分けに基づいて組織の部分（セグメント）を形成し、組織全体に基づく代わりに各部分に基づいて許可を割り当てることが可能であるべきである。

米国特許仮出願一連番号第６０／３１１，８２１号

「医療保険移植性及び義務法」（ＨＩＰＡＡ）、１９９６年

これらの要件の一部を満足する様々な従来技術のセキュリティシステムの存在は公知であるが、要件全体はいうに及ばず、その大部分を満足するセキュリティシステムも存在しないことが知られている。

本発明は、以下においてセキュリティ保護ログオンアプリケーションと呼ぶ、スポンサー組織のためのセキュリティで保護された情報及びセルフサービス機能へのアクセスを制御する独立型セキュリティシステムである。それは、「ウェブ」ベース及び「音声自動応答システム（Interactive Voice Response:ＩＶＲ）」ベースのセルフサービス機能に使用することができる。スポンサー組織は、ユーザインタフェース（「ウェブ」サイト又は「ＩＶＲ」）及びバックエンドシステムをホスティングする組織とすることができ、又は、単にユーザインタフェースをホスティングして、バックエンド処理のためにトランザクションを他の組織に転送する組織とすることができる。これは、医療関連会社で開発されたものであるが、医療に特定のものではなく、スポンサー組織のセキュリティ保護情報及びセルフサービス機能へのアクセスを必要とするクライアントを有する任意のスポンサー組織により使用することができる。

本明細書で使用される定義及び略称は以下の通りである。
・「アクセス管理者」（ＡＡ）−エンティティに対する何らかのセキュリティ管理権を有するが「主アクセス管理者」ではない、エンティティにおけるユーザ。
・「アクセス制御」−必要な場合にアクセス権及びこの情報の通信の記録を維持すること。一般に、アクセス制御は、ユーザがどのデータを使用してどのビジネス機能を実行することができるかを制御し、そのユーザがこれらのビジネス機能を実行する間はアクティブユーザであることを保証することから成る。
・「アクセス識別子」−スポンサー組織のバックエンドシステムにエンティティに関するデータを有するエンティティについては、アクセス識別子は、そのデータに対するキーである。識別子は、主識別子とすることができ、すなわち、それらは、登録処理中又はシステムアプリケーション所有者により準備され、又は、派生識別子とすることができ、すなわち、それらは、主識別子に基づいてバックエンドシステムのデータから導出される。プロバイダグループに対するアクセス識別子の一例は、グループの「ＴＩＮ」（納税ＩＤ番号）である。セキュリティ保護ログオンアプリケーションにアクセスするエンティティは、サイズが異なることが可能である。大半のエンティティは、「アクセス識別子」を１つだけ有することになる。何十、何百、又は何千ものアクセス識別子を持ち得る大きな病院のような他のエンティティがある。

・「アクセス識別子タイプ」−「アクセス識別子タイプ」は、エンティティを識別するために設定されるアクセス識別子の分類である。
・「アクセス管理」（「役割割当て」とも呼ばれる）−組織データへの管理者（又はユーザ）のアクセスを許可、修正、又は除去する処理。
・「Ａｄｍｉｎエンティティ」−ユーザが作業している対象の「エンティティ」。
・「ＡＫＡ名」−公開ユーザＩＤ又はユーザの別名。ユーザＩＤのような「ＡＫＡ名」は、ユーザ固有のものである。これは、ログオンに使用することができるいかなる情報も公表することなくユーザを言及する代替方法である。
・「代替制御権限」−「代替制御権限」（ＡＣＡ）は、エンティティを法的に拘束することができ、「主制御権限」が利用不能の場合に「主制御権限」のバックアップとして働く個人である。
・「役割割合て」−「アクセス管理」を参照。

・「認証」−当該の個人が依然としてアクセスを有することを許可されていることの進行中の確認。
・「承認」−個人の信用認定書及びアクセスが必要とされるコンテキストに基づき、特定のビジネス機能及びデータへのアクセスに関して、セキュリティで保護されたウェブセルフサービス機能を使用する権利及び必要性を有する個人を承認すること。
・「ＢｅｈａｌｆＯＦエンティティ」−ユーザが代行して作業を行っているエンティティ。委任を伴う状況においては、これは、ユーザが作業している対象のエンティティと異なるエンティティであることになる。

・「ビジネス機能」−ビジネス機能とは、ユーザが実行することができ、セキュリティ保護ログオンアプリケーション内で適正に登録されたシステムアプリケーションによりセキュリティ保護ログオンアプリケーションを通じてユーザに利用可能にされた何らかの機能又は活動である。一例は、「クレームを閲覧する」である。
・「ビジネス機能発生キー」／「ビジネス機能ＩＤ」−「ビジネス機能発生キー」は、「ビジネス機能ＩＤ」とも呼ばれるが、「ビジネス機能」に割り当てられる固有の値である。それは、「ビジネス機能」がセキュリティ保護ログオンアプリケーションで登録された時に割り当てられる。
・「ビジネス機能セット」−「ビジネス機能セット」は、「ビジネス機能」の論理グループ分けである。

・「委任」−「委任」とは、１つのエンティティにより別のエンティティが第１のエンティティに代わって第１のエンティティの作業を行うことを可能にされる処理である。
・「派生識別子」−派生識別子は、主識別子の値に基づいて、バックエンドシステム内のデータから導出された識別子である。
・「動的メニュー」−セキュリティ保護ログオンアプリケーション内でユーザに認められた権利に基づいてユーザが行うことができる機能のリスト。ユーザが特定機能へのアクセスを持たない場合、その機能は、ユーザにメニュー品目として呈示されないことになる。

・「エンティティ」−プロバイダグループ、ブローカー代理店、雇用主のようなような組織。エンティティは、スポンサー組織が取引関係を有する組織又は個人である。また、エンティティは、スポンサー組織と関係を有するエンティティと取引きする第三者組織である。各エンティティは、いくつかの責任に関して特定された特定の人々、すなわち、組織を法的に拘束することができる個人（「主制御権限」−ＰＣＡ）及びセキュリティ管理に責任のある個人（「主アクセス管理者」−ＰＡＡ）を持つべきである。
・「エンティティタイプ」−複数の種類のエンティティをサポートすることができる。各エンティティタイプは、それに付随する特定のビジネス機能及びそれに付随するいくつかの識別子タイプを有することができる。医療関連会社の場合、エンティティタイプには、プロバイダ組織、内科医、雇用主、会員、代理店、又はブローカーが含まれるであろう。

「エンティティユーザ」−エンティティユーザは、特定ユーザが特定エンティティに代わって作業を行うことができることを示す。「ユーザコンテキスト」も参照。
・「識別子」−「アクセス識別子」を参照。
・「メニュー」−ユーザがログオンした時、少なくともユーザの役割が許すビジネス機能又は時にはそれ以上のもののリストから成るビジネス機能のメニューがユーザに呈示される。
・「原点ポート」（ＰＯ）−セキュリティ保護ログオンアプリケーションを通じてスポンサー組織のセキュリティ保護ビジネス機能及びリソースにアクセスするための開始点又は入力点。医療関連会社のためのスポンサー組織の場合、医療プロバイダ及び雇用主のための原点ポートがある場合がある。
「原点ポートキー」−「ＰＯ」が最初に登録された時にセキュリティ保護ログオンアプリケーションの管理者により「ＰＯ」に割り当てられるキー。

・「主アクセス管理者」（ＰＡＡ）−「主アクセス管理者」は、エンティティにおけるセキュリティ管理に責任のある個人である。
・「主制御権限」（ＰＣＡ）−「主制御権限」（ＰＣＡ）は、エンティティを法的に拘束することができる個人である。
・「主識別子」−「主識別子」は、登録処理中に設けられるか又はシステムアプリケーション所有者により維持される識別子である。
・「プロバイダ組織」−「スポンサー組織」の保険に入っている人々に医療を提供し、スポンサー組織によりそれ自体が保険に入ることができる組織。
・「実際のエンティティユーザ」−実際のエンティティユーザの状況では、ユーザは、ユーザが代わりに作業を行っているエンティティに勤務している。

・「登録処理」−エンティティ、「主制御権限」、及び「主アクセス管理者」に関するデータがオンライン処理を通じて捕捉されて承認される処理。この承認は、「ＩＴ」セキュリティ担当員によるか、又は自動承認処理とすることができる。
「セグメント化」−「セグメント化」は、アクセス識別子のグループ分けに基づく組織の部分（セグメント）の定義であり、組織全体ではなく部分に基づいて許可を割り当てる。
・「単一サインオン」−単一サインオンの概念は、複数のコンテキストに対してログオンするために、ユーザが単一の「ユーザＩＤ」を使用することを意味する。
・「スポンサー組織」−「スポンサー組織」とは、そのセキュリティ保護情報、及び「ウェブ」サイト能力に対するセルフサービス機能へのアクセスを制御するために、セキュリティ保護ログオンアプリケーションをインストールする組織である。スポンサー組織は、ユーザインタフェース（「ウェブ」サイト）及びバックエンドシステムをホスティングする組織とすることができ、又は、ユーザインタフェースのみをホスティングしてバックエンド処理のためにトランザクションを他の組織に転送する組織とすることができる。

・「システムアプリケーション」−ビジネス機能又は「ビジネス機能セット」を実施するコード。
・「システムアプリケーションＩＤ」−「システムアプリケーションＩＤ」は、「システムアプリケーション」に割り当てられる固有の値である。それは、「システムアプリケーション」がセキュリティ保護ログオンアプリケーションで登録された時に割り当てられる。
・「システムアプリケーション所有者」−「システムアプリケーション」の「所有者」は、「システムアプリケーション」のスポンサーになるか又は制御するビジネス人又は組織であると考えられる。
・「システム設定」−セキュリティ保護ログオンアプリケーションは、複数のインストール単位の設定オプションをサポートする。各オプションは、セキュリティ保護ログオンアプリケーションが所定のインストールで機能するような方法でいくつかの相違に対して準備する。設定は、相違の全体パッケージから成り、すなわち、個々の相違を個別に選択及び指定することはできない。

・「ユーザ」−エンティティに付随し、かつ、セキュリティ保護ログオンアプリケーションにより保護されたセキュリティ保護ビジネス機能へのアクセスを有する個人。
・「ユーザコンテキスト」−システムを使用するために、各ユーザは、ユーザがシステムを使用するコンテキストを定義すべきである。一般的に、コンテキストは、ユーザが勤務する組織である。通常、これらの組織は、スポンサー組織とは異なる。コンテキストを有することは、どのような種類のビジネス機能及びデータがユーザに利用可能であるかを決定することになる。コンテキストは、エンティティと呼ばれる。

・「ユーザＩＤ」−「ユーザＩＤ」は、ユーザが「原点ポート」にログオンしてセキュリティ保護情報及びセルフサービス機能にアクセスするために使用するＩＤである。それは、特定の個人及びその個人のみに付随する。
・「ユーザ役割」−ユーザ役割は、ユーザがアクセスを認められたビジネス機能により定義される。役割は、動的に変更することができる。作成することができる役割数は、利用可能なビジネス機能の組合せ数によってのみ限定される。
・「仮想エンティティユーザ」−仮想エンティティユーザの状況では、ユーザは、ユーザが代わりに作業を行っているエンティティに勤務していない。

セキュリティ保護ログオンアプリケーションには、５つの主要な面がある。
１．「アクセス制御」：スポンサー組織のためのセキュリティ保護情報及びセルフサービス機能へのアクセスの制御。
２．「未知のユーザのためのサポート」：スポンサー組織と間接的関係を有するユーザ、及び、スポンサー組織と直接的関係を有するユーザへのアクセスを可能にする。
３．「セキュリティ管理の分配」：中央情報技術リソースからセキュリティ保護ログオンアプリケーションの様々なユーザまでのセキュリティ管理の分配。
４．「複数の環境に対するサポート」：異なる種類の環境内への組込みに対するサポート。
５．「システム統括者に対するサポート」：ビジネス機能を実行するためにセキュリティ保護ログオンアプリケーションに接続し、その情報を使用する必要があるシステム統括者に対するサポート。

本発明によるセキュリティ保護ログオンアプリケーションは、上述の５つの所要な面の１つ又は他にそれぞれ適合する以下の特性を有する。
１．「スポンサー組織」：セキュリティ保護ログオンアプリケーションは、異なる「スポンサー組織」にインストールすることができる。
２．「システム設定」：セキュリティ保護ログオンアプリケーションは、スポンサー組織に依存して設定にいくつかの相違を有することができる。
３．「ウェブサイト内への原点ポートとの統合」：セキュリティ保護ログオンアプリケーションは、「原点ポート」のセキュリティ未保護区域と「原点ポート」のセキュリティ保護区域との間で「原点ポート」に統合されて調和させることができる。統合には、「原点ポート」の体裁及び感じへの適応、いくつかの内容の調節、及び、メニュー構造を通じてそれが提供する機能までのナビゲーションパスの形成が含まれる。
４．「システムアプリケーション及びシステムアプリケーション所有者」：セキュリティ保護ログオンアプリケーションは、「システムアプリケーション」により実行されるビジネス機能に基づいて、セキュリティ管理権の一部を「システムアプリケーション所有者」に分配する。
５．「ビジネス機能」：セキュリティ保護ログオンアプリケーションは、「スポンサー組織」を制御するのではなく、別の組織に対して存在するビジネス機能へのアクセスをサポートする。
６．「エンティティ」：セキュリティ保護ログオンアプリケーションは、エンティティに基づいて形成されたアクセスを有する。アクセスは、エンティティに対して承認され、これらのエンティティ内の人々に認められる。
７．「エンティティタイプ」：セキュリティ保護ログオンアプリケーションは、アクセスを制御する、及び、どのビジネス機能がそのエンティティに適当かを判断するという様々な目的のために、エンティティを「エンティティタイプ」に分類する。
８．「ユーザ」：セキュリティ保護ログオンアプリケーションは、エンティティに付随する人々であるユーザをサポートする。
９．「既知及び未知の人々」：セキュリティ保護ログオンアプリケーションは、ユーザがいかなるスポンサー組織にも以前から既知ではないが、その雇用主を通じてスポンサー組織に間接的関係を有する人々であることを可能にする。
１０．「単一サインオン」：セキュリティ保護ログオンアプリケーションは、「ＩＶＲ」を含む複数のコンテキストにおける任意のユーザに対して単一「ユーザＩＤ」の使用をサポートする。
１１．「公開名を通じたユーザの識別」：セキュリティ保護ログオンアプリケーションは、ユーザに対する「ＡＫＡ名」をサポートする。
１２．「ユーザ役割」：セキュリティ保護ログオンアプリケーションは、利用可能なビジネス機能の組合せ数によってのみ限定される異なるユーザに対する異なる役割の作成をサポートする。
１３．「役割を判断する複数の方法」：セキュリティ保護ログオンアプリケーションは、役割を構成するビジネス機能の直接的な割当てから黙示的な判断まで、ユーザに関する事実に基づいてユーザの役割を判断する複数の方法をサポートする。
１４．「メニュー」：ユーザがログオンした時、セキュリティ保護ログオンアプリケーションは、ユーザの役割が許すビジネス機能のみを含むビジネス機能のメニューのユーザへの呈示をサポートする。
１５．「セキュリティ管理の分配」：セキュリティ保護ログオンアプリケーションは、毎日のアカウント管理を行うために「ウェブ」サイトを使用するエンティティに対して、及び、「ウェブ」サイト上で利用可能なビジネス機能を制御してそれらのビジネス機能とそのビジネス機能が必要とするアクセス識別子とを認めるために「システムアプリケーション所有者」に対して「セキュリティ管理」の分配をサポートする。
１６．「第三者への委任」：セキュリティ保護ログオンアプリケーションは、エンティティが関係を有する第三者へのエンティティによる委任をサポートする。
１７．「バックエンドデータ（アクセス識別子）への接続」：エンティティに関するデータをスポンサー組織のバックエンドシステム内に有するエンティティの場合、セキュリティ保護ログオンアプリケーションは、そのデータへの接続又はキーをもたらすアクセス識別子を捕捉する。それはまた、最初のアクセス識別子の派生物である他の識別子の捕捉及び格納をサポートする。
１８．「アクセス制御」：セキュリティ保護ログオンアプリケーションは、ユーザに割り当てられたエンティティのアクセス識別子、及び、ユーザに割り当てられたビジネス機能（役割）に基づいて、サイト上の情報及び機能性に対するアクセス制御をサポートする。
１９．「アクセス識別子管理（セグメント化）」：セキュリティ保護ログオンアプリケーションは、複数のアクセス識別子を有する大きな組織が、組織全体に対して部分集合へのアクセスを制御する目的でそれ自身の部分集合を形成することを可能にする。
２０．「サイトの条件付き使用」：セキュリティ保護ログオンアプリケーションは、サイトのユーザがサイト使用の前にサイトの使用条件に同意したか又は認めたという事実の記録を管理及び保管する。
２１．「セッション管理」：セキュリティ保護ログオンアプリケーションは、ユーザがサイトにログオンした状態で、「ウェブ」サイトでのセッション管理を準備する。
２２．「複数の登録代替方法」：セキュリティ保護ログオンアプリケーションは、複数の登録代替方法をサポートする。これらには、エンティティを通じてスポンサー組織に間接的に接続されたユーザに対するオンライン登録、信用あるソースからの供給に基づくユーザ及びエンティティの自動作成、バックエンドシステム内のデータに基づき「既知」である個人エンティティに対するワンステップ登録、及び、仮「ユーザＩＤ」及びパスワードを通じた仮登録が含まれる。
２３．「バックエンドシステムからの通知」：セキュリティ保護ログオンアプリケーションは、エンティティ及びユーザのセキュリティプロフィールを変更するためのバックエンドシステムからの情報の受領をサポートする。
２４．「バックエンドシステムへの通知」：セキュリティ保護ログオンアプリケーションは、エンティティ及びユーザのセキュリティプロフィールに対する追加及び変更のバックエンドシステムへの通知をサポートする。
２５．「状態管理」：セキュリティ保護ログオンアプリケーションは、「アクティブ」であるユーザのみが機能を実行することができるように管理者がユーザの状態を管理することを可能にする。
２６．「他のセキュリティソフトウエアとの統合」：追加レベルのディレクトリアクセス保護をもたらすために、「マイクロソフト」の「パーソナライゼーション及びメンバーシップ（Ｐ＆Ｍ）」製品をセキュリティ保護ログオンアプリケーションと共に利用することができる。

「アクセス制御」の一面には、「ビジネス機能」、「エンティティ」、「エンティティタイプ」、「ユーザ」、「単一サインオン」、「公開名を通じたユーザの識別」、「ユーザ役割」、「役割を判断するための複数の方法」、「メニュー」、「第三者への委任」、「バックエンドデータへの接続」、「アクセス制御」、「アクセス識別子管理」、「サイトの条件つき使用」、「セッション管理」、及び「状態管理」の特性が含まれる。「未知のユーザに対するサポート」の一面には、「既知及び未知の人々」及び「複数の登録代替方法」の特性が含まれる。「セキュリティ管理の分配」の一面には、「システムアプリケーション及びシステムアプリケーション所有者」及び「セキュリティ管理の分配」の特性が含まれる。「複数の環境に対するサポート」の一面には、「スポンサー組織」、「システム設定」、「ウェブサイト内への原点ポートとの統合」、及び「他のセキュリティソフトウエアとの統合」の特性が含まれる。「システム統括者に対するサポート」の一面には、「バックエンドシステムからの通知」及び「バックエンドシステムへの通知」の特性が含まれる。
本発明は、同じ参照番号が一貫して同じ要素を示す添付図面を参照しながら「好ましい実施形態」の以下の「詳細説明」を読むことにより更に良く理解される。

エンティティ、ユーザ、ユーザが何を行うことができるか（ビジネス機能）、及び、ユーザがその機能をどのデータに行うことができるか（アクセス識別子）の間の関係を示す図である。 セキュリティ保護ログオンアプリケーションのユーザが、登録された原点ポートからセキュリティ保護ログオンアプリケーション内のビジネス機能設定にアクセスした時に従うことになる流れを示す流れ図である。 例示的なヘルプテキスト画面を示す図である。 セキュリティ保護ログオンアプリケーションの「ユーザＩＤ」及び「ＡＫＡ」名矛盾管理処理を示す流れ図である。 図５Ａ〜図５Ｄの配置を示す図である。 セキュリティ保護ログオンアプリケーションにおいてエンティティ及びユーザを「自動作成」する能力を原点ポートに与えるために使用されるフォームポストの一例を示す図である。 セキュリティ保護ログオンアプリケーションにおいてエンティティ及びユーザを「自動作成」する能力を原点ポートに与えるために使用されるフォームポストの一例を示す図である。 セキュリティ保護ログオンアプリケーションにおいてエンティティ及びユーザを「自動作成」する能力を原点ポートに与えるために使用されるフォームポストの一例を示す図である。 セキュリティ保護ログオンアプリケーションにおいてエンティティ及びユーザを「自動作成」する能力を原点ポートに与えるために使用されるフォームポストの一例を示す図である。 例示的な「役割割当て」画面を示す図である。 ユーザのアクセスをプログラム的に更新するための例示的な「ＸＭＬ」トランザクションを示す図である。 ビジネス機能及びそれと共に使用するデータを割り当てるための例示的画面を示す図である。 ビジネス機能及びそれと共に使用するデータを割り当てるための例示的画面を示す図である。 例示的「プロバイダ」の組織を示す概略図である。 個人の組織及びその組織の主要連絡先に関する情報を取得するためのウェブベースの登録アプリケーションで使用される例示的画面を示す図である。 個人の組織及びその組織の主要連絡先に関する情報を取得するためのウェブベースの登録アプリケーションで使用される例示的画面を示す図である。 個人の組織及びその組織の主要連絡先に関する情報を取得するためのウェブベースの登録アプリケーションで使用される例示的画面を示す図である。 ウェブページを通じて呈示された守秘義務同意を示す図である。 派生識別子が割り当てられる処理を示す流れ図である。 一時的にユーザを保留するための例示的画面を示す図である。 一時的にユーザを保留するための例示的画面を示す図である。 同じソースのエンティティから異なるパスを通る目標エンティティへの複数の委任チェーンがある時、及び、目標エンティティが委任したいと欲する時に、次のレベルへの複数の委任チェーンの拡張を示す図である。 ３組のデータによる委任チェーンの追跡を示す図である。 「主アクセス管理者」に対してその組織に対するセグメントを作成するために表示された可能な選択の例を示す図表である。 「アクセス管理者」に対して組織のそのセグメント内にセグメントを作成するために表示された可能な選択の例を示す図表である。 セグメントの作成及び内容を管理するのに使用される例示的画面を示す図である。 セグメントの作成及び内容を管理するのに使用される例示的画面を示す図である。 セグメントの作成及び内容を管理するのに使用される例示的画面を示す図である。 委任と、典型的な「作業の委任」及び「委任された作業の割当て」作業流れとを管理する機能性を示す図である。 委任と、典型的な「作業の委任」及び「委任された作業の割当て」作業流れとを管理する機能性を示す図である。 委任と、典型的な「作業の委任」及び「委任された作業の割当て」作業流れとを管理する機能性を示す図である。 委任と、典型的な「作業の委任」及び「委任された作業の割当て」作業流れとを管理する機能性を示す図である。 委任と、典型的な「作業の委任」及び「委任された作業の割当て」作業流れとを管理する機能性を示す図である。 委任と、典型的な「作業の委任」及び「委任された作業の割当て」作業流れとを管理する機能性を示す図である。 委任と、典型的な「作業の委任」及び「委任された作業の割当て」作業流れとを管理する機能性を示す図である。 セキュリティ保護ログオンアプリケーションの重要な構成要素間の概念的関係を示す図である。

セキュリティ保護ログオンアプリケーションは、セキュリティ保護情報及びセルフサービス機能のようなスポンサー組織のリソースへの制御されたアクセスを準備する安全な外部管理式動的メニュープログラムを通じて、スポンサー組織のためのセキュリティ保護情報及びセルフサービス機能へのアクセスを制御する独立型セキュリティシステムである。それは、従来の市販コンピュータ機器及びプログラミング言語を使用して実行し、「ウェブ」ベース及び「ＩＶＲ」ベースのセルフサービス機能に使用することができる。スポンサー組織は、ユーザインタフェース（「ウェブ」サイト又は「ＩＶＲ」）及びバックエンドシステムをホスティングする組織とすることができ、又は、ユーザインタフェースのみをホスティングし、バックエンド処理のためにトランザクションを他の組織に転送する組織とすることができる。セキュリティ保護ログオンアプリケーションの主な用途は医療業界に関連しているが、医療に特定ではない。

セキュリティ保護ログオンアプリケーションの特徴は、スポンサー組織により設定の相違を有することができる、サイトセキュリティ未保護区域とサイトのセキュリティ保護区域との間で統合して「ウェブ」サイトに調和させることができる、エンティティに基づいて定義されたアクセスを有する、既知の人々、及び登録前はスポンサー組織に既知ではないが雇用主を通じてスポンサー組織と間接的関係を有する人々とに対するセキュリティをサポートする、利用可能なビジネス機能の組合せ数（役割ベースの割当て）によってのみ限定される異なるユーザに対する異なる役割の作成をサポートする、複数のタイプのエンティティをサポートして各エンティティタイプが特定ビジネス機能及び特定ビジネス機能に付随するいくつかの「アクセス識別子タイプ」を有することを可能にする、（医療補助プロバイダの場合は）プロバイダ組織、内科医、雇用主、代理店、ブローカー、会員、及び同僚を含む、ウェブセルフサービス機能の全ての予想されるユーザに対して機能する、１９９６年の「医療保険移植性及び義務法」（ＨＩＰＡＡ）をサポートする、「ＩＶＲ」を含む複数のコンテキストにおける任意のユーザの単一ユーザＩＤの使用をサポートする、及び、承認された内在的データへの「フック」をもたらすことである。

セキュリティ管理は、「承認組織」に分配される。各「承認組織」は、少なくとも１つの「制御権限」及び１つの「アクセス管理者」を指名すべきである。１つの「承認組織」は、別の「承認組織」に委任することができる。しかし、委任は、特定の非常に重大なセキュリティ活動については許容されない。例示的な医院の組織を概略的に図９に示す。
様々な組織構造をサポートするために、セキュリティ保護ログオンアプリケーションは、個人が「承認組織」で果たす役割に基づく機能の割当てを可能にする。以下で更に詳細に説明するように、「役割割当て」機能は、図６に示すような「役割割当て」画面から開始される。

「ＨＩＰＡＡ」をサポートするために、「ユーザＩＤ」により示されるような各ユーザアカウントは、特定の個人及びその個人のみに関連付けられる。更に、単一「ユーザＩＤ」は、複数のコンテキストについて使用されるので、個人は、複数のコンテキストから機能することができ、例えば、ブローカーには、雇用主の「スタッフ」の一部として及びブローカーの役割としての役割を認めることができ、内科医は、内科医ばかりでなく医療計画に携わる会員と成り得る。「ＡＫＡ名」は、ログオンするために使用することができる任意の情報を公表することなくユーザを言及する代替方法となる。それは、任意のユーザアカウントに関して他の個人と通信するために使用され、その結果、顧客サービスのサポートが可能になる。また、「ＡＫＡ名」により、ユーザは、「ユーザＩＤ」が確立された場所とは異なるコンテキストで「ユーザＩＤ」を流用することができる。

セキュリティ保護ログオンアプリケーションは、高度な識別情報を収集することにより内在的データのフックとなる。プロバイダ組織の場合は、医療業界においては、高度な識別情報は、「納税ＩＤ」とすることができ、内科医の場合は、州の免許取得番号又は類似の識別情報とすることができる。また、セキュリティ保護ログオンアプリケーションは、アクセス識別子のグループ分けに基づいて組織の部分への「セグメント化」を可能にするために、かつ、組織全体に基づくのではなく部分に基づいて許可を割り当てるために様々なインタフェースをサポートする。

アクセス制御概念は、セキュリティ保護ログオンアプリケーションが、ユーザ情報及びアクセス権を維持し、必要な場合はスポンサー組織内でアクセス権情報を通信するための単一の権威あるシステムを提供することを意味する。一般に、アクセス制御は、ユーザがどのデータを使用してどのビジネス機能を実行することができるかを制御すること、及び、そのビジネス機能を実行する間はそのユーザがアクティブユーザであることを保証することから成る。

セキュリティ保護ログオンアプリケーションは、スポンサー組織との関係を有する組織の個人が、セキュリティ保護ログオンアプリケーション内の有効なエンティティとしてその組織を登録し、その組織のセキュリティ保護ログオンアプリケーションの継続使用のために「主アクセス管理者」（セキュリティ管理者）を確立することができる登録処理をサポートする。
セキュリティ保護ログオンアプリケーションはまた、ウェブを使用する「承認組織」によるセキュリティ管理を可能にし、高レベルアクセス識別子よりも低いレベルでバックエンドシステムからアクセス識別子を捕捉するためのインタフェースをサポートする。派生識別子が割り当てられる処理を示す流れ図を図１４に示す。アクセス権は、ビジネス機能及びアクセス識別子により付与及び取消しが行われる。また、アクセス権は、他の「承認組織」に委任することができる。

複数の環境をサポートするために、セキュリティ保護ログオンアプリケーションは、ポータルによりカスタム化可能である。カスタム化することができる画面機能には、ページ上部に表示されるヘッダ／ロゴ、左下のナビゲーションバー、スタイルシートを通じてセキュリティ保護ログオンアプリケーションにより表示されるメニュー項目の体裁及び感じ、セキュリティ保護ログオンアプリケーションによってもたらされたビジネス機能を完了した時にユーザが戻る位置（これは、セキュリティ保護ログオンアプリケーション内の「原点ポート」戻り「ＵＲＬ」を設定することにより行われる）、ナビゲーションに使用されるグラフィック、所要のフィールド及び行方不明データを指定するために使用されるグラフィック、セキュリティ保護ログオンアプリケーションにより提供される各外部画面上に呈示されるヘルプテキスト、アクセスが認められた時にユーザに呈示されるメニュー項目、及びセキュリティ保護ログオンアプリケーション利用中にユーザに呈示されるエラーメッセージの大半のテキストが含まれる。
セキュリティ保護ログオンアプリケーションは、全ての「承認組織」との法的合意事項の取得、全てのユーザとの法的合意事項の取得、監査処理及び能力の組込み、及び、全てのセキュリティトランザクションの記録のようなリスク軽減機能を含むことができる。

図１は、エンティティ、ユーザ、ユーザが何を行うことができるか（ビジネス機能）、及び、ユーザがこの機能をどのデータ上に行うことができるか（アクセス識別子）の間の関係を示す。
本発明の好ましい実施形態において、セキュリティ保護ログオンアプリケーションを実行するために使用されるプログラミング言語は、「ビジュアル・ベーシック（ＶＢ６）」（「ＣＯＭ」オブジェクト用）、「ＳＱＬ」（記憶手順用）、「ＡＳＰ」（ウェブ呈示用）、「ＨＴＭＬ」（ウェブ呈示用）、「ＪＡＶＡ（登録商標）」（「ＣＯＭ」オブジェクト用）、及び「ジャバスクリプト」である。データベースは、「ＳＱＬサーバ」データベースであることが好ましい。

Ｉ．セキュリティ保護ログオンアプリケーションの主要な一面
セキュリティ保護ログオンアプリケーションには、５つの主要な面がある。
１．「アクセス制御」：スポンサー組織のためのセキュリティ保護情報及びセルフサービス機能へのアクセスの制御。
２．「未知のユーザのためのサポート」：スポンサー組織と間接的関係を有するユーザ、及び、スポンサー組織と直接的関係を有するユーザへのアクセスを可能にする。
３．「セキュリティ管理の分配」：中央情報技術リソースからセキュリティ保護ログオンアプリケーションの様々なユーザまでのセキュリティ管理の分配。
４．「複数の環境に対するサポート」：異なる種類の環境内への組込みに対するサポート。
５．「システム統括者に対するサポート」：ビジネス機能を実行するためにセキュリティ保護ログオンアプリケーションに接続し、その情報を使用する必要があるシステム統括者に対するサポート。
これらの各々について、以下に更に詳細に説明する。

ＩＩ．アクセス制御
非常に高いレベルでは、アクセス制御は、ユーザがどのデータを使用してどのビジネス機能を実行することができるかを制御すること、及び、そのビジネス機能を実行する間はそのユーザがアクティブユーザであることを保証することから成る。動的メニューに含まれる項目はまた、「アクセス制御」の一部と考えることができる。
Ａ．ユーザがどのデータを使用してどのビジネス機能を実行することができるかの制御 ユーザがどのデータを使用してどのビジネス機能を実行することができるかの制御には、それに対して多くの相互関係を有する一面がある。これは、セキュリティ保護ログオンアプリケーション内での「委任」及び「セグメント化」のサポートのために、一般的に予想されるであろうものよりも複雑である。「委任」は、１つの組織から別の組織への許可の付与である。「セグメント化」は、組織の部分（セグメント）を定義し、組織全体ではなく部分を対象とする許可を割り当てるためのサポートである。様々な一面及びそれらが互いにどのように機能するかについての説明として、まず、この制御で使用される基礎的要素について説明し、引き続き、基礎的要素を関連付ける様々な概念及び構造を説明し、最後に、事柄の構築の方法を支配する規則について説明する。

Ｂ．ユーザがどのデータを使用してどのビジネス機能を実行することができるかの制御で使用される基礎的要素
ユーザがどのデータを使用してどのビジネス機能を実行することができるかの制御で使用される基本的な基礎的要素を以下に列挙する。
エンティティ−エンティティは、スポンサー組織が取引関係を有する組織又は個人である。エンティティはまた、スポンサー組織と関係を有するエンティティと取引きする第三者組織である。スポンサー組織としての医療関連会社において適用可能な例は、以下のものである。
組織エンティティ−プロバイダグループ、保険代理店、雇用主、
個人エンティティ−会員（医療関連会社の保険に入っている個人）、ブローカー、内科医、及び
第三者エンティティ−課金組織、料金回収組織。
ビジネス機能−ビジネス機能は、ユーザが実行することができる何らかの機能又は活動である。
アクセス識別子−スポンサー組織のバックエンドシステムにエンティティに関するデータを有するエンティティの場合、「アクセス識別子」は、そのデータのキーである。プロバイダグループに対するアクセス識別子の例は、そのグループの「ＴＩＮ」（納税ＩＤ番号）である。
「アクセス識別子タイプ」−これは、エンティティを識別するために設定されるアクセス識別子の分類である。
ユーザ−セキュリティ保護ログオンアプリケーションによりセキュリティ保護されているビジネス機能及び情報へのアクセスを得ることをエンティティにより承認された個人。
エンティティにおける重要な位置−各エンティティは、いくつかの地位、すなわち、その組織を法的に拘束することができる個人（「主制御権限」−ＰＣＡ）及びセキュリティ管理に責任のある個人（「主アクセス管理者」−ＰＡＡ）について特定された特別な人々を有するべきである。個人エンティティの場合、「ＰＣＡ」及び「ＰＡＡ」は、一般的に本人である。非個人エンティティの場合、「ＰＣＡ」及び「ＰＡＡ」は、一般的に人々であり、同一人物とすることができる。他にオプションであるエンティティにおける２つの地位がある。「アクセス管理者」（ＡＡ）は、セキュリティ管理に関する責任がある別の個人とすることができる。「事務局管理者」（ＯＡ）は、セキュリティ管理に関する責任のない別の個人とすることができる。
セキュリティアカウント管理機能：いくつかのビジネス機能が、アカウント管理活動を行うために「ＰＡＡ」及び「ＡＡ」に用意されている。非「所有者」エンティティ用のこれらの機能のセット及び「所有者」エンティティ用のセットがある。アクセス制御を目的とした非「所有者」エンティティ用ビジネス機能のうちで主なものは、「ウェブアクセス権を割り当てる」、「ユーザステータスを管理する」、「貴組織をセグメント化する」、「作業を別の組織に委任する」、「別の組織に委任された作業を変更する」、「別の組織への委任を停止する」、及び「委任された作業をスタッフに割り当てる」である。「所有者」エンティティ用ビジネス機能は、「組織へのアクセスを認める」及び「新しい機能を確立する」である。

Ｃ．ユーザがどのデータを使用してどのビジネス機能を実行することができるかの制御において使用される基礎的要素を関連付ける概念及び構造（データベース表）
基本的な基礎的要素を互いに関連付けるいくつかの重要な概念及び表がある。それらを以下で説明する。
１．概念：「エンティティ−ユーザ」−ユーザは、エンティティのコンテキストにおいてのみ操作する。
システムを使用するために、各ユーザは、ユーザが定義されたシステムを使用するコンテキストを有するべきである。一般に、コンテキストとは、ビジネス機能及び情報へのアクセスをユーザに承認したエンティティである。コンテキストを有することは、どのような種類のビジネス機能及びデータがユーザに利用可能であるかを決定することになる。

２．構造：ＥＮＴＩＴＹ＿ＵＳＥＲ表
「Ｅｎｔｉｔｙ＿Ｕｓｅｒ」表は、ユーザをエンティティと関連付け、従って、ユーザが操作することができるコンテキストを提供する。
３．概念：「主アクセス識別子」及び「派生アクセス識別子」
セキュリティ保護ログオンアプリケーションは、「アクセス識別子」を２つの広義の範疇、すなわち、「主」と「派生」に分ける。この区別は、セキュリティ保護ログオンアプリケーションの様々な処理には重要であるが、「管理者」（「主アクセス管理者」−ＰＡＡ、及び、「アクセス管理者」−ＡＡ）には曖昧なものであり、又は曖昧なものとなる可能性がある。「主アクセス識別子」は、明示的に定義される。初期設定は、スポンサー組織の「ＩＴ」セキュリティ担当者により行われ、この情報は、エンティティ側の登録情報から集められる。付加的な「主」アクセス識別子を後で追加することができる。「主」アクセス識別子は、最も高く最も一般的なレベルであることが最も多く、「納税識別」番号、「社会保証番号」、医師州免許取得番号、又は保険会社発行の雇用主グループ番号であることが多い。「派生」アクセス識別子は、主アクセス識別子から導出される。「第１レベル」の「派生」アクセス識別子は、主アクセス識別子を「親」としてを有することになり、「第２レベル」の「派生」アクセス識別子は、「派生」アクセスを「親」としてを有することになる、などである。「派生」アクセス識別子は、主アクセス識別子に同等か、又は、主アクセス識別子が表す内容の「再分割」を表す。再分割は、部門、部署、サイト、位置、又は雇用主下位グループとすることができるであろう。例えば、主アクセス識別子が「納税識別」番号である病院は、会計、入院、又はスケジュール立案のような病院内の部署を表す「派生」識別子を有することができる。最下位レベルの「派生」アクセス識別子は、特定のバックエンドシステムに記憶された詳細レベルにより、個人か、又は、位置、ユニット、又は部署を表すことができる。

報告書作成及び制御上の要件により、エンティティに対する主アクセス識別子及び「派生」アクセス識別子間で階層を作ることができることが必要である。これを達成するために、セキュリティ保護ログオンアプリケーションは、各「派生」アクセス識別子をその親のアイデンティティでタグ付けし、その結果、ツリー構造を表すバックリンクフィールドをもたらす。全ての派生アクセス識別子は、別の派生アクセス識別子又は主アクセス識別子にバックリンクされる。この表設計により、ツリーは、任意のレベル数の深さにすることができる。それらは、全て「主」アクセス識別子においてパス指定される。任意のノードの下には複数のノードが存在することができる（複数の枝）。

４．構造：ＡＣＣＥＳＳ＿ＩＤＥＮＴＩＦＩＥＲ表
セキュリティ保護ログオンアプリケーションは、主アクセス識別子及び「派生」アクセス識別子を「アクセス識別子」表に記憶することになる。この表には、アクセス識別子値及び「アクセス識別子タイプ」、アクセス識別子が関係するエンティティ、アクセス識別子が主又は「派生」アクセス識別子であるか否かに関する指示、「派生」アクセス識別子の親のアイデンティティ、及び長短の説明が含まれている。
５．概念：アクセス識別子のグループ分けに基づくエンティティのセグメント化
セキュリティ保護ログオンアプリケーションにアクセスするエンティティは、サイズが異なることが可能である。大半のエンティティは、「アクセス識別子」を１つだけ有する。他のエンティティ、例えば大きな病院のような一般的に大きなエンティティは、何十、何百、又は何千ものアクセス識別子を有する可能性がある。複数のアクセス識別子を有するエンティティの場合、セグメント化は、アクセス識別子のグループ分けと組織全体ではなく部分を対象とした許可の割当てとに基づく組織の部分（セグメント）の定義である。このようにして、組織内の異なるグループの人々は、自分が勤務する組織の部分に特定の情報を用いて作業することができる。

６．構造：ＡＣＣＥＳＳ＿ＧＲＯＵＰ及びＡＣＣＥＳＳ＿ＧＲＯＵＰ＿ＩＤ＿ＡＳＳＯＣ表
セグメントの定義は、「ＡＣＣＥＳＳ＿ＧＲＯＵＰ」表に記憶され、アクセス識別子がセグメントを構成する結び付きは、「ＡＣＣＥＳＳ＿ＧＲＯＵＰ＿ＩＤ＿ＡＳＳＯＣ」表に記憶される。
７．概念：多くのビジネス機能はデータを使用する
ビジネス機能の大部分は、いくつかのタイプのアクセス識別子と協働してその「アクセス識別子タイプ」により入力されたデータを得る。例えば、「会員のクレームを閲覧する」には、適切なクレームを表示するためにアクセス識別子の「会員ＩＤ」タイプが必要であり、「雇用主請求書を調べる」には、適切な請求書を表示するためにアクセス識別子の「雇用主グループ番号」タイプが必要である。一部のビジネス機能には、特定のデータセット、例えば参照情報用のビジネス機能及びセキュリティ機能との関連は必要ではない。どのビジネス機能がどの「アクセス識別子タイプ」と機能するか、及び、機能する上でいかなるアクセス識別子も必要ないのはどのビジネス機能かに関する記録が保持される。

８．構造：ＢＵＳ＿ＦＵＮＣ＿ＩＤ＿ＴＹＰＥ＿ＡＳＳＯＣ（ＢＦＩＴＡ）表
この表は、ビジネス機能に付随されるべき「アクセス識別子」タイプを定義するものである。任意のビジネス機能は、１つよりも多い「アクセス識別子タイプ」に関連付けることができる。この表にビジネス機能に関するエントリがない場合、ビジネス機能には、いかなるデータも必要ではない。
９．概念：委任
組織のために仕事を行うスペシャリストを求める多くの組織が存在する。それは、金銭の節約、優れたサービスの提供、又は営業時間の拡張に対処するため、又は、組織が特定の仕事を行うための人材を雇い、訓練し、維持することが難し過ぎるために為されることが多い。
セキュリティ保護ログオンアプリケーションは、１つのエンティティ（ＢｅｈａｌｆＯＦエンティティ）がそれに代わって別のエンティティ（Ａｄｍｉｎエンティティ）に作業させることを可能にする。これを委任と呼ぶ。委任は、一般的により小さな組織により行われる。
一例は、政府機関と共に保険金請求を処理するために第三者管理者（ＴＰＡ）と契約する小規模の医院であり、それはまた、別の会社と契約することができ、他の保険会社と取引きするために別の「ＴＰＡ」として作用する。

１０．概念：委任チェーン
セキュリティ保護ログオンアプリケーションは、委任先のエンティティ（Ａｄｍｉｎエンティティ）が更に別のエンティティに最初のエンティティ（ＢｅｈａｌｆＯＦエンティティ）に代わって作業させることを可能にする。これは、最初の「ＢｅｈａｌｆＯＦ」エンティティに代わって作業を行うことができるエンティティのストリングがあるまで継続することができ、ストリング内の各エンティティは、ストリング内の直前のエンティティから委任された許可を受領する。これを委任チェーンと呼ぶ。

１１．構造：ＤＥＬＥＧＡＴＩＯＮ表
「ＤＥＬＥＧＡＴＩＯＮ」表には、１つのエンティティにより別のエンティティに委任されたビジネス機能及びデータ、及び、委任チェーンの定義に関する情報が説明されている。
図１７を参照すると、委任チェーンは、３組のデータ、チェーン識別子、レベル、及び親により追跡される。チェーンにより、特定のエンティティ／ビジネス機能／データセットに関する委任がグループ分けされる。例えば、「ＸＹＺ」が「クレームを申請する」を「ＤＥＦ」に委任した時、「Ｃ１３５７」のチェーンＩＤが割り当てられる。「ＤＥＦ」が「ＡＢＣ」に委任することにより委任を進めた時、その委任は、「Ｃ１３５７」という同じＩＤを有する。「ＸＹＺ」から「ＤＥＦ」の第１の委任はレベル１であり、「ＤＥＦ」から「ＡＢＣ」への第２の委任はレベル２である。親の値は、委任が生じた行を示す。「ＸＹＺ」から「ＤＥＦ」への委任には、親がないので「ＮＵＬＬ」である。「ＤＥＦ」から「ＡＢＣ」への委任は、「ＸＹＺ」から「ＤＥＦ」の行の親を有する。
「ＤＥＦ」はまた、同じ作業を「ＭＮＯ」に委任することが可能である。「ＤＥＦ」による「ＭＮＯ」へのこの委任は、「ＤＥＦ」による「ＡＢＣ」への委任と同じチェーンＩＤ、同じレベル、及び同じ親値を有することになる。

このデザインは、以下の種類の委任及び作用を取り扱うものであり、「⇒」は、委任を表す。すなわち、１つのノードから別のノードへの２つのパス：Ａ⇒Ｂ⇒Ｄ及びＡ⇒Ｃ⇒Ｄ（Ｄノードは、２つのパスを通じてＡに接続され、各パスは、個別に追跡される）、多数対１のマッピング：Ａ、Ｂ、Ｃ、Ｄ、Ｅ、．．．⇒Ｚ、任意のレベルのサブツリー、Ｆ⇒Ｇのみの単純なツリー、パスをウォーキングバックアップする、及び、ツリー全体の再構築である。

１２．概念：実際のエンティティユーザ及び仮想エンティティユーザ−エンティティユーザ概念への拡張
セキュリティ保護ログオンアプリケーションが委任を行うために、セキュリティ保護ログオンアプリケーションは、２種類のエンティティユーザ、すなわち、実際のエンティティユーザ及び仮想エンティティユーザを有するべきである。実際のエンティティユーザは、ユーザが作業を行っているエンティティに勤務している場合のユーザである。仮想エンティティユーザは、１つの会社（Ａｄｍｉｎエンティティ）により雇用され、「Ａｄｍｉｎ」エンティティに作業を委任した異なる会社（ＢｅｈａｌｆＯＦエンティティ）に代わって作業を行っているユーザである。

１３．構造：ＥＮＴＩＴＹ＿ＵＳＥＲ表
これは、先に参照したものと同じ「Ｅｎｔｉｔｙ＿Ｕｓｅｒ」表である。先の参照では、１つのエンティティフィールドのみについて説明した。実際は、委任をサポートするために必要なエンティティフィールドは、３つ、すなわち、「ＧｒａｎｅｄＢｙ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」、「Ａｄｍｉｎ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」、及び「ＢｅｈａｌｆＯｆ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」である。「ＧｒａｎｅｄＢｙ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」は、そのユーザによりエンティティユーザ行が作成されるエンティティの識別を含む。「Ａｄｍｉｎ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」は、ユーザが実際に勤務しているエンティティの識別を含む。「ＢｅｈａｌｆＯｆ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」は、ユーザが代わりに作業を行っているエンティティの識別を含む。実際のエンティティユーザ及び仮想エンティティユーザは、「ＧｒａｎｅｄＢｙ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」により、及び、「Ａｄｍｉｎ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」と「ＢｅｈａｌｆＯｆ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」との間の関係により区別される。実際のエンティティユーザの場合、このフィールドは賑わうことになる。仮想エンティティユーザの場合、「ＧｒａｎｅｄＢｙ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」は、「ＮＵＬＬ」となる。また、仮想エンティティユーザの場合、「Ａｄｍｉｎ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」（ユーザの勤務先であるエンティティ）及び「ＢｅｈａｌｆＯｆ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」（ユーザが代わりに作業を行っているエンティティ）は異なるものになる。

１４．概念：１つの表は、ユーザが使用することができるビジネス機能／データの組合せを制御し、ユーザの役割は、割り当てられたビジネス機能及びデータにより判断される。
セキュリティ保護ログオンアプリケーションは、「ＰＡＡ」、「ＡＡ」、又は「ＯＡ」がアクセスすることができるデータを制限する。データを必要とするビジネス機能については、セキュリティ保護ログオンアプリケーションは、特定のデータをそのユーザの特定ビジネス機能と関連付ける。ビジネス機能は、個々に割り当てられ、また、「ＥＵＡ」表においてビジネス機能が操作することができるデータと共に記録されることから、各ユーザは、ユーザの組織内のそのユーザの役割に特定して割り当てられるビジネス機能／データを有することができる。

１５．構造：ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＡＣＣＥＳＳ（ＥＵＡ）表
「ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＡＣＣＥＳＳ（ＥＵＡ）表」は、ユーザが作業することができる「ビジネス機能」／「データ」対に関して、ユーザが「外部エンティティ」に対して有するアクセス権を定義する。
１６．概念：任意の「ＥＵＡ」エントリは、複数の委任から生じる可能性がある。
１つのエンティティから委任されている別のエンティティまで複数のパスを有することが可能である。例えば、「⇒」が委任を表すとすると、Ａ⇒Ｂ⇒Ｄ及びＡ⇒Ｃ⇒Ｄの場合は、ＡからＤまで２つのパスがある。この考えを更に拡張すると、Ｄ⇒Ｅの場合、Ｄに対するＡの委任チェーンの両方は、エンティティＥに拡張されることになる。Ａに代わってＤにおいて作業を行っているユーザ及びＡに代わってＥにおいて作業を行っているユーザについて「ＥＵＡ」エントリがあると考えられる。

１７．構造：ＥＵＡ＿ＤＥＬＥＧＡＴＩＯＮ＿ＡＳＳＯＣ表
「ＥＵＡ＿ＤＥＬＥＧＡＴＩＯＮ＿ＡＳＳＯＣ」表は、仮想ユーザがなぜ「ビジネス機能／データ対」にアクセスすることができるかを文書化するものである。「Ｅｎｔｉｔｙ＿Ｕｓｅｒ＿Ａｃｃｅｓｓ」内の「ＥＵＡ」エントリと共に、委任から生じる各「ＥＵＡ」エントリを正当化するために「ＥＵＡ＿ＤＥＬＥＧＡＴＩＯＮ＿ＡＳＳＯＣ」表にエントリが作られることになる。
１８．概念：ビジネス機能は、セグメント上で操作することができるか又はできない。
一部のビジネス機能については、そのビジネス機能が組織の個別のセグメント又はその一部で作動することは道理にかなうことである。その一例は、大きな病院における「クレームを閲覧する」であり、この場合、各部署について個別に「クレームを閲覧する」ことができれば好都合である。他のビジネス機能については、そのビジネス機能が組織の個別のセグメント又は一部で作動することは理にかなうことではない。その一例は、「参考資料」であろう。

１９．概念：ビジネス機能は、委任可能であるか又はできない。
一部のビジネス機能については、そのビジネス機能が１つの組織から別の組織に委任されることは理にかなうことである。第三者に会計サービスを委任するプロバイダ組織の場合の一例は、「クレームを提出する」ことである。他のビジネス機能については、そのビジネス機能が１つの組織から別の組織に委任されることは理にかなうことではない。その一例は、セキュリティアカウント管理機能のいずれかであろう。
２０．構造：ＢＵＳＩＮＥＳＳ＿ＦＵＮＣＴＩＯＮ表
「Ｂｕｓｉｎｅｓｓ＿Ｆｕｎｃｔｉｏｎ」表は、セキュリティ保護ログオンアプリケーションにより制御される各「ビジネス機能」を定義し、かつ、各ビジネス機能がセグメント上で作動することができるか否か、及び、各ビジネス機能を委任することができるか否かを記録するものである。

２１．概念：許可付与の階層
セキュリティ保護ログオンアプリケーションは、階層を用いて、人々がビジネス機能及び情報（データ）にアクセスすることを可能にする。全てのビジネス機能及びデータアクセスに対する主制御は、スポンサー組織の「ＩＴセキュリティ」グループである。それらは、プロバイダ、保険会社、支払人、第三者管理者、会員、代理店、ブローカーなどを表すエンティティを作成する。設定の一部は、エンティティの主アクセス管理者（ＰＡＡ）の作成である。「ＰＡＡ」は、エンティティが有することを許可されるビジネス機能及び情報の完全なセットが与えられる個人である。これは、割当て階層の第１層である。

「ＰＡＡ」が「ＰＡＡ」と同じエンティティに勤務する人々にビジネス機能及び情報へのアクセスを割り当てることを欲する時、その処理を「割当て」と呼び、「ＰＡＡ」は、「アクセスを割り当てる」作業流れに従う。「ＰＡＡ」は、その組織の他の人々に「アクセスを割り当てる」作業流れを使用する権限を与えることができ、その結果、「アクセス管理者」（ＡＡ）が作成される。これは、第２レベルの階層である。「ＡＡ」は、「ＰＡＡ」と同じセットのビジネス機能及び情報へのアクセスを有さなくてもよいが、セキュリティ保護ログオンアプリケーションは、「ＡＡ」が同僚であることを許容する。尚、「ＡＡ」が同じセットのビジネス機能及び情報へのアクセスを有していたとしても、「ＡＡ」は、依然として「ＰＡＡ」ではない。「ＰＡＡ」は、セキュリティ保護ログオンアプリケーションの作業流れの多くにおいて特別な意味を有し、スポンサー組織の「ＩＴセキュリティ」グループからの介入を通じて初めて別の個人に作成及び変更することができる。

組織の「ＰＡＡ」又は「ＡＡ」がビジネス機能及び情報へのアクセスを異なるエンティティに勤務する人々に委任することを欲する時、この処理を「委任」と呼び、「ＰＡＡ」／「ＡＡ」は、「作業を委任する」作業流れに従う。「委任」が発生した場合、受け取り側組織の「ＰＡＡ」は、委任されたビジネス機能及び情報アクセスの様々な権利を受け取り、その組織のスタッフにそれらを割り当てることができる。これは、別のレベルの階層である。
委任された権利を受け取った組織の「ＰＡＡ」がそれらの権利をその組織に勤務する人々に割り当てた時、この処理を「委任された作業を割り当てる」と呼び、「ＰＡＡ」は、「委任された作業を割り当てる」作業流れに従う。「ＰＡＡ」は、その組織内の他の人々に「委任された作業を割り当てる」作業流れを使用する権限を与えることができる。これは、別のレベルの階層である。
階層の別のパスは、スポンサー組織の「ＩＴセキュリティ」グループから「システムアプリケーション所有者」に至る。これらの「システムアプリケーション所有者」は、自らが制御する機能の「ＰＡＡ」への割り当てを制御する。その後の流れは、「ＰＡＡ」から外に向って以上概説した通りである。

分散式セキュリティ管理の要点は、全ての権限がスポンサー組織の「ＩＴ」セキュリティ担当者から始まって外に向って流れるということである。すなわち、
「ＩＴ」セキュリティ担当者から、
エンティティ「ＰＡＡ」に、
そのエンティティの「ＡＡ」に、
そのエンティティの従業員に、
そのエンティティの従業員に、
別のエンティティの「ＰＡＡ」に、
他のエンティティの「ＡＡ」に、
他のエンティティの従業員に、
他のエンティティの従業員に、
「システムアプリケーション所有者」に、
エンティティ「ＰＡＡ」に、
そのエンティティの「ＡＡ」に、
そのエンティティの従業員に、
そのエンティティの従業員に、
別のエンティティの「ＰＡＡ」に、
他のエンティティの「ＡＡ」に、
他のエンティティの従業員に、
他のエンティティの従業員に。

Ｄ．ユーザがどのデータを使用してどのビジネス機能を実行することができるかの制御で使用される規則
重要な地位に認められた許可に関する規則が８つあり、それらは以下の通りである。
１．セキュリティ保護ログオンアプリケーションは、エンティティについては１つのアクティブ「ＰＡＡ」のみを許可する。
２．セキュリティ保護ログオンアプリケーションは、「ＰＡＡ」の許可を保護する。スポンサー組織の「ＩＴセキュリティ」担当者又は「システムアプリケーション所有者」のみが、「ＰＡＡ」のベースアクセスを変更することができる。「ＰＡＡ」に委任されたアクセスは、その委任者により変更される。同一エンティティ内の「ＡＡ」は、「ＰＡＡ」のアクセスを変更することができない。
３．「ＰＡＡ」の許可は、３通りの方法、すなわち、「ＰＡＡ」を交代させる、「ＰＡＡ」に機能を追加する、及び「ＰＡＡ」から機能を除去するうちの１つで変更することができる。
ａ．「ＰＡＡ」を交代させる場合、新任の「ＰＡＡ」を指名する。新任の「ＰＡＡ」は、前任の「ＰＡＡ」が有していた全ての許可を受け取る。前任の「ＰＡＡ」は、もはや「ＰＡＡ」ではないこと以外は、いかなる許可も自動的に除去されるものではない。
ｂ．「ＰＡＡ」は、スポンサー組織の「ＩＴ」セキュリティ担当者又は「システムアプリケーション所有者」によってのみ追加されたか又は除去されたビジネス機能を有することができる。
４．ビジネス機能が「ＰＡＡ」に追加された場合、「ＰＡＡ」は、他の者がそれらのビジネス機能を実行するためにそれらを他の者に割り当てるか又は委任すべきである。
５．ビジネス機能がエンティティの「ＰＡＡ」から除去された場合、それらは、それらが以前に割り当てられていたエンティティ内の誰からも自動的に除去され、かつ、それらが委任されていた他の全てのエンティティ内のいかなるユーザからも自動的に除去される。
６．「ＡＡ」は、任意の他の「ＡＡ」又は「ＯＡ」の権利を変更することができるが、「ＡＡ」の権利の範囲に限られる。本実施例においては、「Ｄ」は、データ割り当てを示し、「ＢＦ」は、対応するビジネス機能の割り当てを示す。例えば、ハリーの「ＰＡＡ」が「ＯＡ」にハリーの権利「Ｄ１−ＢＦ１」、「Ｄ１−ＢＦ２」、「Ｄ２−ＢＦ１４４」、及び「Ｄ２−ＢＦ１４５」を与え、また、２つの「ＡＡ」であるジョアンナ及びベラがあると仮定する。ジョアンは、ハリーの権利を有し、更に、権利「Ｄ３−ＢＦ１」及び「Ｄ３−ＢＦ２」を有する。ジョアンは、ハリーから権利を除去するか、又はハリーに「Ｄ３」アクセス対の１つ又はそれ以上を与えることができる。「ＡＡ」ベラは、「Ｄ１−ｘｘ」へのアクセスを有するのみであり、従って、ハリーに対して「Ｄ１−ｘｘ」を追加又は除去することしかできない。つまり、ベラは、ハリーの「Ｄ２−ｘｘ」権利をいかなる点においても変更することができない。ジョアンはまた、ベラに対してアクセスを与えるか又は除去することができる。ベラは、「Ｄ１−ｘｘ」データ対のビジネス機能についてジョアンからアクセスを除去することしかできない。
７．「ＡＡ」を解任したり、又は、「ＡＡ」の許可が取り消された場合、解任又は取消しがあっても、「ＡＡ」がアクセスを割り当てたり、委任したり、又は「委任されたアクセスを割り当てる」を行ったいかなる個人に対してもいかなる影響も及ばないことになる。
８．権利は、それらが認められた状態では、明示的か、又は委任の取消しのためのカスケード削除を通じてのみ除去することができる。

明示的なビジネス機能割当てに関する規則が３つあり、それは以下の通りである。
１．ユーザがどのデータを使用してどのビジネス機能を実行することができるかに関する判断は、ユーザへのビジネス機能の割当てから始まる。これが発生する可能性がある複数の状態がある。
ａ．「ＩＴ」セキュリティ担当者から「ＰＡＡ」に対して、アプリケーションが承認された時、「ＰＡＡの役割を管理する」の処理中、又は「大量の割当て」の処理中に。これは、エンティティタイプコンテキストにおいて行われることになる。
ｂ．「ＩＴ」セキュリティ担当者から「ＡＡ」又は「ＯＡ」に対して、「管理者を追加する」の処理又は「ＡＡの役割を管理する」の処理中に。これは、エンティティコンテキストにおいて行われることになる。
ｃ．「ＰＡＡ」又は「ＡＡ」から「ＡＡ」又は「ＯＡ」に対して、「新規ユーザを登録する」の処理又は「アクセス権を割り当てる」の処理中に。これは、「原点ポート」内から及びエンティティタイプコンテキストにおいて行われることになる。
ｄ．「システムアプリケーション所有者」から「ＰＡＡ」に対して、「組織へのアクセスを認める」の処理又は「新規機能を確立する」の処理中に。これは、「原点ポート」内から及びエンティティタイプコンテキストにおいて行われることになる。
ｅ．１つの組織の「ＰＡＡ」又は「ＡＡ」から別の組織の「ＰＡＡ」に対して、「委任を開始する」の処理、「委任を変更する」の処理、又は「委任を停止する」の処理中に。これは、「原点ポート」内から及びエンティティコンテキストにおいて行われることになる。
ｆ．委任された権利については、委任先の組織の「ＰＡＡ」又は「ＡＡ」からその同じ組織の「ＡＡ」又は「ＯＡ」に対して、「委任された権利を割り当てる」の処理中に。これは、「原点ポート」内から及び選択された「ＢｅｈａｌｆＯＦ」エンティティについて行われることになる。
ｇ．「ＰＡＡ機能データアクセス」トランザクション（アクセス識別子を追加し、その後、以前に割り当てられたビジネス機能を通じて対応する権利をそのアクセス識別子に追加する）及び「ユーザアクセストランザクション」（ビジネス機能／データ対をエンティティのユーザに追加する）を通じた「トランザクション受領者」。これらは、エンティティコンテキストにおいて行われることになる。

２．トランザクション受領者を除く全ての場合において、割当てに利用可能なビジネス機能を示す画面が表示される。例示的な画面を図６に示す。最初に、「ビジネス機能セット」のみを示す画面が現れる。「ビジネス機能セット」の左のプラス記号のあるボックスをクリックすれば、そのセットは、その中のビジネス機能を示すように拡張される。ビジネス機能が既に割り当てられており、また、その処理が「大量の割り当て」処理ではない場合、画面は、ボックス内のチェックマークを示すことにより。現在割り当てられているビジネス機能又は「ビジネス機能セット」を表示する。

３．上述の状況の各々において、どのビジネス機能が割当てに利用可能であるかに関する判断は異なる。すなわち、
ａ．「ＩＴ」セキュリティ担当者から「ＰＡＡ」に。
ｉ．「ＰＡＡ」エンティティのエンティティタイプ又は「大量の割当て」に使用されているエンティティタイプを判断する。
ｉｉ．そのエンティティタイプに付与することができる「ビジネス機能セット」を判断する。
ｉｉｉ．「ビジネス機能セット」の一部であるビジネス機能を調べる。
ｂ．「ＩＴ」セキュリティ担当者から「ＡＡ」又は「ＯＡ」に。
ｉ．選択されたエンティティの「ＰＡＡ」が有するビジネス機能を調べる。
ｃ．「ＰＡＡ」又は「ＯＡ」から「ＡＡ」又は「ＯＡ」に。
ｉ．処理が行われている「原点ポート」に有効な選択されたエンティティに対して管理者が有するビジネス機能を調べる。
ｄ．「システムアプリケーション所有者」から「ＰＡＡ」に。
ｉ．選択されたエンティティタイプ及び処理が行われている「原点ポート」に有効なシステムアプリケーション所有者に登録されているビジネス機能を調べる。
ｅ．１つの組織の「ＰＡＡ」又は「ＡＡ」から別の組織の「ＰＡＡ」に。
ｉ．選択されたエンティティについて管理者が有し、処理が行われている「原点ポート」に有効で、「委任可能」であるビジネス機能を調べる。
ｆ．委任された権利については、委任先の組織の「ＰＡＡ」又は「ＡＡ」からその同一組織の「ＡＡ」又は「ＯＡ」に。
ｉ．最初の組織（ＢｅｈａｌｆＯＦエンティティ）について管理者が有し、処理が行われている「原点ポート」に有効なビジネス機能を調べる。
ｇ．「トランザクション受領者」から非「ＰＡＡ」ユーザに。
ｉ．割り当てられている機能が選択されたエンティティの「ＰＡＡ」に既に割り当てられたことを確認する。

黙示的なビジネス機能割当てに関する規則が１つあり、それは以下の通りである。
１．セキュリティ保護ログオンアプリケーションは、一部の状況においてビジネス機能の黙示的割当てをサポートする。黙示的ビジネス機能割当てをサポートするためには、２つの機能が存在すべきである。１番目は、どのようなビジネス機能がどのような条件下で割り当てられるべきかに関するデータベース表でコード化された規則のセットである。２番目は、ユーザがログインする条件を判断し、それによって、適切なセットのビジネス機能を判断するためにそれらの条件に関する規則にそれらの条件を適合させることができるようにする手段である。

ビジネス機能を用いるデータの割当てに関する１４個の規則があり、それらは以下の通りである。
１．ユーザがどのデータを使用してどのビジネス機能を実行することができるかに関する判断における第２の段階は、割り当てられたビジネス機能への特定のデータの割当てである。
２．割当てが「ＰＡＡ」に対するものであり、かつ、ビジネス機能にデータが必要である時は常に、ビジネス機能に適切であるエンティティの全ての既存のアクセス識別子は、ビジネス機能と自動的に関連付けられる。
３．割当てが「ＰＡＡ」に対するものではなく、ビジネス機能にはデータが必要であり、かつ、ビジネス機能が「セグメント化可能」ではない時、ビジネス機能に適切であるエンティティの全ての既存のアクセス識別子は、ビジネス機能と自動的に関連付けられる。
４．割当てが「ＰＡＡ」に対するものではなく、ビジネス機能にはデータが必要であり、ビジネス機能が「セグメント化可能」であり、ビジネス機能に適切であるエンティティの既存のアクセス識別子が１つしかなく、かつ、それを含むセグメントがない時、その１つのアクセス識別子は、ビジネス機能と自動的に関連付けられる。
５．割当てが「ＰＡＡ」に対するものではなく、ビジネス機能にはデータが必要であり、ビジネス機能が「セグメント化可能」であり、かつ、ビジネス機能に適切であるエンティティのアクセス識別子及び／又はセグメントが複数ある時、そのビジネス機能にデータを割り当てるための「データを割り当てる」画面が表示される。図８Ａ及び図８Ｂは、ビジネス機能及びビジネス機能に付随するデータを割り当てるシーケンスを示す。

６．ビジネス機能にデータが必要ではない場合、それは、「ＥＵＡ」表及び恐らくは「委任」表にもデータ指定なしで割り当てられる。
７．ビジネス機能にデータが必要である場合、割当てを完了するためには、適切なタイプの少なくとも１つのアクセス識別子が存在すべきである。それが存在しない場合、ビジネス機能は割り当てられない。
８．ビジネス機能が「セグメント化可能」である場合、それは、「ＢＦＩＴＡ」表内の少なくとも１つのアクセス識別子のタイプと関連付けなければならない。そうでない場合は、組織のセグメント又は部分をビジネス機能に割り当てることは不可能である。
９．セグメント化可能なビジネス機能は、主アクセス識別子及び／又はセグメントと関連付けることができる。「管理者」は、１つ又はそれ以上の主アクセス識別子、１つ又はそれ以上の「セグメント」、又は、「セグメント」及び主アクセス識別子の任意の組合せに付随するビジネス機能を個人に割り当てることができる。
１０．同じビジネス機能に対する主アクセス識別子及びそのアクセス識別子を含むセグメントの割り当ては、互いに独立したものである。これが起こり、かつ、後で主アクセス識別子がセグメントから除去された場合、主アクセス識別子及びビジネス機能の直接的な割り当てが残る。例えば、個人に「納税ＩＤ」２２２３３４４４４の「主」アクセス識別子が割り当てられ、同一アクセス識別子が「セグメント」に含まれている場合、その後に「主」アクセス識別子が「セグメント」から除去されてそれ以外の内容は変更されていない時に、その個人は、依然として「納税ＩＤ」にアクセスすることができることになる。

１１．ビジネス機能が「アクセスを割り当てる」の作業流れ又は「作業を委任する」の作業流れ中に実行されるべきデータを割り当てた時、「ＡＡ」は、それ自身にアクセスすることができる範囲内でのみ別の「ＡＡ」又は「ＯＡ」へのアクセスを割り当てることができる。選択することができるデータは、（ａ）ビジネス機能が使用するタイプの少なくとも１つのアクセス識別子をセグメントが含んでいる限り、このセグメントの機能及び適切な部分集合に対して管理者に既に割り当てられている「セグメント」により、及び（ｂ）ビジネス機能について管理者が権利を有する「主」アクセス識別子により表される（設計により、これらの主アクセス識別子は、ビジネス機能に適切なタイプでなければならない）。
１２．「アクセスを割り当てる」作業流れ又は「作業を委任する」作業流れ中のアクセス識別子の割当てにおいては、「ＰＡＡ」は、全ての「セグメント」へのアクセスを有することになると仮定される。これは、「ＰＡＡ」が全ての「主」アクセス識別子にアクセスすることができるので、「ＡＡ」が「派生」アクセス識別子を「セグメント」に割り当て、かつ、「ＰＡＡ」が直接に新規「派生」アクセス識別子と共に作業しなかった時でさえも当てはまる。全ての「派生」アクセス識別子は、「主」アクセス識別子の１つから引き出されることから、「ＰＡＡ」は、「派生」アクセス識別子の全ての「親」にアクセスすることができる。セキュリティ保護ログオンアプリケーションは、誰かが「親」アクセス識別子にアクセスすることができる場合、彼らが全ての「派生」アクセス識別子にもアクセスを有することを保証する。

１３．ビジネス機能は、ビジネス機能には通常の使用においてアクセスＩＤが必要でない場合、かつその場合に限り、それに付随するいかなるデータがなくても委任することができる。
１４．ビジネス機能実施時に、セキュリティ保護ログオンアプリケーションは、以下のステップに従ってビジネス機能を構成する個々のアクセス識別子内に「セグメント」を拡張することになる。
ａ．個々のアクセス識別子を捜すために各「セグメント」を調べる。
ｂ．「セグメント」の個々のアクセス識別子と割り当てられた個々のアクセス識別子との和集合が見出され、個々のアクセス識別子の完全な集合をもたらすことになる。
ｃ．ビジネス機能を処理することが許可されているアクセス識別子のタイプに基づいて、個々のアクセス識別子の完全な集合を濾過することになる。得られる濾過されたグループは、個人がビジネス機能と共に使用することができるアクセス識別子の集合である。得られる集合は、「ＮＵＬＬ」であることが可能である。

セグメントに関する１５個の規則があり、それらは以下の通りである。
１．「セグメント」は、１つのエンティティ「に属する」１つ又はそれ以上のアクセス識別子の集まりである。「セグメント」は、「主」アクセス識別子及び「派生」アクセス識別子の任意の組合せを含むことができる。
２．アクセス識別子がセグメントに追加された時、セグメントが参照される全ての場所で直ちに利用可能になる。同様に、アクセス識別子がセグメントから除去された時、セグメントが参照される全ての場所で直ちに除去される。
３．アクセス識別子は、ゼロ、１つ、又はそれ以上の「セグメント」の要素とすることができ、唯一の制限は、「セグメント」がアクセス識別子が関連付けられた同じエンティティのためのものであるべきであるということである。
４．「セグメント」内では、アクセス識別子は、１回だけ存在することができる。
５．「セグメント」は、別のセグメント含むことができない。
６．「セグメント」は、その中に会員がなくても存在することができる。

７．「セグメント管理」機能により、管理者は、「セグメント」の作成及び内容を管理することができる。図２０から図２２は、セグメント定義を作成し、その後にその内容を判断する処理を示す。
ａ．「派生」アクセス識別子が可能である場合、「セグメント」内容定義で使用するのに以前に選択されていない任意の「派生識別子」をユーザが選択することができるように「セグメント管理」機能にリンクが設けられる。
８．「ＰＡＡ」は、「セグメント管理」機能の割り当てを通じてセグメントと共に作業する許可を管理者に対して割り当てるか、又は差しとめる。「ＡＡ」が「セグメント管理」ビジネス機能を有していない場合、「ＡＡ」は、「セグメント」により定義されたデータを使用してビジネス機能を実行するというコンテキストにおいて「セグメント」を割り当てられたという程度以外に「セグメント」には気が付かないであろう。

９．「セグメント管理」機能は、「ＢＦＩＴＡ」内のアクセスＩＤタイプと関連付けられる。
ａ．派生リンクが起動され、派生リンクが「親」アクセス識別子に対してどのデータと共に作業すべきであるかを知りたい時に派生リンクが適切なデータを得るように、「セグメント管理」機能を「ＢＦＩＴＡ」内のアクセスＩＤタイプと関連付けることが必要である。一例として、代理店及びブローカーの場合、その機能は、親としての納税ＩＤというアクセスＩＤタイプ、及び、親としての「代理店所在地」ＩＤというアクセスＩＤタイプに基づくものとなる。これらのアクセスＩＤタイプは、実際に派生をもたらすことができる唯一のものである。
ｂ．「ＢＦＩＴＡ」内のアクセスＩＤタイプとの「セグメント管理」機能の関連付けはまた、管理者を組織の特定セグメントについて「セグメント管理」に割り当てることができるように行われる。
ｉ．「セグメント管理」処理を通じて管理者が管理するための組織のセグメントを割り当てる結果は、より広いか又は異なるセグメントが他の機能に割り当てられた場合に、管理者が、異なる機能のためにより多くのデータにアクセスすることができるということである。
１０．「ＰＡＡ」は、「セグメント」の内容を定義した時、全ての「アクセス」識別子と共に作業することができる。

１１．セグメントの内容を定義した時に「ＡＡ」が共に作業することができる識別子は、以下のように判断される。
ａ．「ＡＡ」に「セグメント管理」ビジネス機能が割り当てられた時、それを割り当てた個人は、「セグメント維持」のために「ＡＡ」がどのデータと共に作業することができるかを示す。割り当てたデータは、「セグメント」又は「主」アクセス識別子の形式である。
ｂ．「セグメント」内の全ての「主」アクセス識別子、「セグメント」内の全ての派生アクセス識別子、直接割り当てられた全ての「主」アクセス識別子、及び「主」アクセス識別子から引き出された全てのアクセス識別子を判断する。これは、「ＡＡ」が共に作業することができる全てのアクセス識別子を成す。
１２．「ＰＡＡ」は、「セグメント管理」機能を使用する時、その組織のための全ての「セグメント」と共に作業することができる。

１３．「セグメント管理」機能を使用する時に「ＡＡ」が共に作業することができる「セグメント」は、以下のように判断される（セグメントリストがもたらされ、その各々は、「セグメント管理」において使用するために「ＡＡ」に直接的又は間接的に割り当てられるアクセス識別子から成る）。
ａ．上述のようにセグメントの内容を定義した時に「ＡＡ」が共に作業することができる識別子を判断する。
ｂ．完全に上述のリスト内のアクセス識別子から成るセグメントを判断する。
１４．セグメントが１つの組織から別の組織に委任された場合、受け取り側組織の「ＰＡＡ」及び「ＡＡ」は、セグメント内の個々の項目を見ることはできず、また、最初のセグメント内の項目又は個々に委任された主アクセスＩＤの独自のセグメントを定義することはできない。
１５．セグメントは、ユーザインタフェースベースの処理（セグメント管理）及び「トランザクション受領者」トランザクションの両方により作成及び維持することができる。
セグメント化を使用する２つの例は、以下の通りである。

「ジェファーソン病院システム」は、大きな大都市病院であった「ジェファーソン総合病院」として創業した。買収により大きくなり、その結果、現在では、かつては別個の１３個の組織であった施設を所有している。これらの施設の各々は、最初の納税ＩＤを保持している。
ミーガンは、「ジェファーソン」の「事業部」の副社長であり、「ジェファーソン病院システム」の全ての管理を行っている。彼女には、町東部の施設を監督するチャールズ、商業地区の施設を監督するリンダ、及び郊外の施設を監督するピーターという「事業部」の３名の取締役がいる。

２種類の業務活動、すなわち、保険金請求処理及び紹介処理がオンラインで行われている。ミーガンは、チャールズに組織全体の紹介処理を担当するように依頼した。保険金請求処理は、個々の事業部により担当されている。
これらのパラメータについて、組織は、以下のように構成されている。
チャールズの担当：
・東部家族クリニック−納税ＩＤ＝ＴＩＮＡ
・東部ＭＲＩセンター−納税ＩＤ＝ＴＩＮＢ
・東部外来患者手術センター−納税ＩＤ＝ＴＩＮＣ
・東部リハビリ−納税ＩＤ＝ＴＩＮＤ
・東部病院−納税ＩＤ＝ＴＩＮＥ
リンダ担当：
・シスター慈悲病院−納税ＩＤ＝ＴＩＮＬ
・ジェファーソン総合病院−納税ＩＤ＝ＴＩＮＭ
チャールズ担当：
・ミドルタウン病院−納税ＩＤ＝ＴＩＮＦ
・チェスター病院−納税ＩＤ＝ＴＩＮＧ
・ジェファーソン市立病院−納税ＩＤ＝ＴＩＮＨ
・キングストン病院−納税ＩＤ＝ＴＩＮＩ
・コールドスプリング病院−納税ＩＤ＝ＴＩＮＪ
・ブリストル病院−納税ＩＤ＝ＴＩＮＫ

チャールズには、部下の管理者が４名いる。キャシーは、「東部家族クリニック」を担当し、シャーロットは、特別施設（「東部ＭＲＩ」及び「東部リハビリ」）を担当し、コナーは、「東部外来患者手術センター」及び「東部病院」を担当し、クリスは、組織全体の「紹介処理」を担当している。
ミーガンが「ジェファーソン病院システム」をセキュリティ保護ログオンアプリケーションで登録する時、彼女は、１３個の「納税ＩＤ」の全てを登録上の「アクセス識別子」として列挙する。
セキュリティ保護ログオンアプリケーションの背景には、以下の情報が「ＢＦＩＴＡ」表にある。

以下の情報が「ビジネス機能」表にある。

ミーガンは、最初にオンした時、セグメントを設定する。ミーガンは全てのデータにアクセスすることができ、また、「貴組織をセグメント化する」は、「納税ＩＤ」の「アクセスＩＤタイプ」でデータを使用するので、セグメントを作成するための選択事項は、図１８に示すものである。
ミーガンは、以下のセグメントを設定する。

ミーガンは、チャールズ、ピーター、リンダを登録し、彼等に以下のように権利を割り当てる。

ミーガンは、担当者に権利を割り当てる時、最初に彼女が付与することができるビジネス機能を表示する画面を見ることになる。この画面では、「貴組織をセグメント化する」、「保険金請求処理」、及び「紹介処理」が表示される。ビジネス機能を選択した後、選択された機能の各々で割り当てることができる全てのデータを見ることになる。

ミーガンがチャールズ担当のビジネス機能に対してデータを割り当てる時にチャールズに関して見る画面には、以下の選択事項の表示を含まれる。
＋「貴組織をセグメント化する」
− ＴＩＮＡ［東部家族クリニック］
− ＴＩＮＢ［東部ＭＲＩセンター］
− ＴＩＮＣ［東部外来患者手術センター］
− ＴＩＮＤ［東部リハビリ］
− ＴＩＮＥ［東部病院］
− ＴＩＮＦ［ミドルタウン病院］
− ＴＩＮＧ［チェスター病院］
− ＴＩＮＨ［ジェファーソン市立病院］
− ＴＩＮＩ［キングストン病院］
− ＴＩＮＪ［コールドスプリング病院］
− ＴＩＮＫ［ブリストル病院］
− ＴＩＮＬ［シスター慈悲病院］
− ＴＩＮＭ［ジェファーソン総合病院］
− 東部
− ミドルタウン
− 郊外
− 全て
＋保険金請求処理
− ＴＩＮＡ［東部家族クリニック］
− ＴＩＮＢ［東部ＭＲＩセンター］
− ＴＩＮＣ［東部外来患者手術センター］
− ＴＩＮＤ［東部リハビリ］
− ＴＩＮＥ［東部病院］
− ＴＩＮＦ［ミドルタウン病院］
− ＴＩＮＧ［チェスター病院］
− ＴＩＮＨ［ジェファーソン市立病院］
− ＴＩＮＩ［キングストン病院］
− ＴＩＮＪ［コールドスプリング病院］
− ＴＩＮＫ［ブリストル病院］
− ＴＩＮＬ［シスター慈悲病院］
− ＴＩＮＭ［ジェファーソン総合病院］
− 東部
− ミドルタウン
− 郊外
− 全て
＋紹介処理
− ＴＩＮＡ［東部家族クリニック］
− ＴＩＮＢ［東部ＭＲＩセンター］
− ＴＩＮＣ［東部外来患者手術センター］
− ＴＩＮＤ［東部リハビリ］
− ＴＩＮＥ［東部病院］
− ＴＩＮＦ［ミドルタウン病院］
− ＴＩＮＧ［チェスター病院］
− ＴＩＮＨ［ジェファーソン市立病院］
− ＴＩＮＩ［キングストン病院］
− ＴＩＮＪ［コールドスプリング病院］
− ＴＩＮＫ［ブリストル病院］
− ＴＩＮＬ［シスター慈悲病院］
− ＴＩＮＭ［ジェファーソン総合病院］
− 東部
− ミドルタウン
− 郊外
− 全て

チャールズが担当機能を持った状態で、彼は、自分に適するセグメントの設定に取り掛かる。彼には「貴組織をセグメント化する」機能について東部セグメントが既に割り当てられていることから、セグメント作成の選択事項は、図１９に示すものとなる。
チャールズは、以下のセグメントを設定する。

チャールズは、東部家族クリニックに対する個別セグメントは設定しない。
チャールズは、キャシー、シャーロット、及びコナーを登録し、それぞれの作業に関して「保険金請求処理」を設定する。彼はクリスを設定し、組織全体の「紹介処理」をクリスに設定する。
キャシー、シャーロット、及びコナーのために保険金請求処理のデータを割り当てる時、チャールズは、データを割り当てるための以下のオプションを有することになり、データを以下の要領で割り当てる。

チャールズは、クリスに対する「紹介処理」のデータを割り当てる時、データを割り当てるための以下のオプションを有することになり、自分が適切と思ういくつかの異なる方法でデータを割り当てることができる。

尚、「保険金請求処理」及び「紹介処理」のための割り当てに関してチャールズが見るデータ選択肢は互いに異なっている。その差異は、チャールズに本来割り当てられた権利に基づいている。「保険金請求処理」については、チャールズには東部セグメントが割り当てられた。従って、「保険金請求処理」に関するデータを割り当てる時、彼は、東部セグメントに関連した「アクセス識別子」を見て、東部セグメントの適切な部分集合である他のセグメントを見る。
「紹介処理」については、彼には「全て」のセグメントが割り当てられた。従って、「紹介処理」に関するデータを割り当てる時、彼は、「全て」のセグメントに関連した「アクセス識別子」を見て、「全て」のセグメントの適切な部分集合である他のセグメントを見る。

「支払人フロントエンド」（ＰＦＥ）は、プロバイダからトランザクションを捕捉し、プロバイダと契約している支払人組織に処理のためにトランザクションを送るスポンサー組織である。「ＰＦＥ」は、３つの支払人、「ＡＢＣ」、「ＤＥＦ」、及び「ＧＨＩ」を有する。
「ＰＦＥ」では、各種のトランザクションについて「支払人」特定の機能がある。これは、「保険金請求問い合わせ」トランザクションの場合、「ＡＢＣ保険金請求問い合わせ」、「ＤＥＦ保険金請求問い合わせ」、及び「ＧＨＩ保険金請求問い合わせ」があることを意味する。「紹介問い合わせ」トランザクションの場合、「ＡＢＣ紹介問い合わせ」、「ＤＥＦ紹介問い合わせ」、及び「ＧＨＩ紹介問い合わせ」がある。

一般に、「ＡＢＣ」機能及び「ＧＨＩ」機能は、その機能を処理する時の識別子として、「納税ＩＤ」（「アクセス識別子タイプ」＝ＴＩ）を使用し、「ＤＥＦ」機能は、その機能を処理する時の識別子として、「サイト定義」ｉｄと呼ばれる専用識別子（「アクセス識別子タイプ」＝ＳＤ）を使用する。
「貴組織をセグメント化する」というビジネス機能は、「納税ＩＤ」及び「ＤＥＦサイト定義」ｉｄに関連付けられるが、その理由は、セグメントがそのいずれか又は両方の種類の識別子から作成することができるからである。
その結果、これらの機能の「ＢＦＩＴＡ」エントリは、以下のようになるであろう。
「ＢＦＩＴＡ」エントリ
ＡＢＣ保険金請求問い合わせ：ＴＩ
ＡＢＣ紹介問い合わせ：ＴＩ
ＤＥＦ保険金請求問い合わせ：ＳＤ
ＤＥＦ紹介問い合わせ：ＳＤ
ＧＨＩ保険金請求問い合わせ：ＴＩ
ＧＨＩ紹介問い合わせ：ＴＩ
貴組織をセグメント化する：ＴＩ
貴組織をセグメント化する：ＳＤ

大きな「プロバイダ組織」の場合、複数のＳＤが定義されることが多く、一般的にその「プロバイダ組織」の所在地の各々について１つである。時には、複数の「納税ＩＤ」もある。
「大フロリダ病院」を例に取る。その所在地は３種類、すなわち、マイアミ東、マイアミ中央、及びタンパである。「大フロリダ病院」は、タンパで創業し、「マイアミ地域病院」システムを取得した。従って、それは、最初のタンパ所在の病院に１つ、及び「マイアミ地域病院」に１つの２つの「納税ＩＤ」を有する。３つの所在地の識別子は、以下の通りである。
大フロリダ病院識別子
マイアミ東：ＴＩ＝２２２３３３４４４、ＳＤ＝Ｈ６７８
マイアミ中央：ＴＩ＝２２２３３３４４４、ＳＤ＝Ｈ７８９
タンパ：ＴＩ＝６６６７７７６６６、ＳＤ＝Ｉ３４５

「大フロリダ病院」が設定された時、それは、アプリケーション内に「納税ＩＤ」のみを有する。ＳＤアクセスｉｄは、後で追加されることになる。従って、「セキュリティ」が「ＰＡＡ」（ミーガン）へのアクセスを割り当てた時、ミーガンは、以下の「ＥＵＡ」エントリを有することになる。
ＰＡＡ（ミーガン）初期ＥＵＡエントリ
貴組織をセグメント化する：ＴＩ＝２２２３３３４４４
貴組織をセグメント化する：ＴＩ＝６６６７７７６６６
ＡＢＣ保険金請求問い合わせ：ＴＩ＝２２２３３３４４４
ＡＢＣ保険金請求問い合わせ：ＴＩ＝６６６７７７６６６
ＡＢＣ紹介問い合わせ：ＴＩ＝２２２３３３４４４
ＡＢＣ紹介問い合わせ：ＴＩ＝６６６７７７６６６
ＧＨＩ保険金請求問い合わせ：ＴＩ＝２２２３３３４４４
ＧＨＩ保険金請求問い合わせ：ＴＩ＝６６６７７７６６６
ＧＨＩ紹介問い合わせ：ＴＩ＝２２２３３３４４４
ＧＨＩ紹介問い合わせ：ＴＩ＝６６６７７７６６６

「ＤＥＦ」は、登録完了から数日以内に「サイト定義」ｉｄを割り当てるために「システムアプリケーション所有者」機能処理を用いる。それらは登録処理中に追加するために「プロバイダ組織」には知られていないので、登録処理中には捕捉されない。また、「ＤＥＦ」は、「サイト定義」ｉｄを追加した後に「ＤＥＦ」機能を「プロバイダ組織」に割り当てる。実際に、「セキュリティ」が「サイト定義」ｉｄが存在する前に「ＤＥＦ」機能を割り当てようとした場合、これを防止して適切なタイプのＩＤが不在であるという警告を発するための検査がある。
「ＤＥＦ」が「サイト定義」ｉｄ及び「ＤＥＦ」ビジネス機能の割り当てを完了した状態で、以下のような追加「ＥＵＡ」エントリが存在することになる。
ＰＡＡ（ミーガン）追加ＥＵＡエントリ
ＤＥＦ保険金請求問い合わせ：ＳＤ＝Ｈ６７８
ＤＥＦ保険金請求問い合わせ：ＳＤ＝Ｈ７８９
ＤＥＦ保険金請求問い合わせ：ＳＤ＝Ｉ３４５
ＤＥＦ紹介問い合わせ：ＳＤ＝Ｈ６７８
ＤＥＦ紹介問い合わせ：ＳＤ＝Ｈ７８９
ＤＥＦ紹介問い合わせ：ＳＤ＝Ｉ３４５

また、「貴組織をセグメント化する」のいくつかの追加の「ＥＵＡ」エントリが、「サイト定義」ｉｄが追加された時に存在するようになる。これは、アクセス識別子がエントリに追加された時、そのタイプのアクセス識別子を使用することができる現在割り当てられている任意のビジネス機能と共に、そのアクセス識別子の「ＰＡＡ」への自動的な割当てがあることによるものである。
ＰＡＡ（ミーガン）追加ＥＵＡエントリ
貴組織をセグメント化する：ＳＤ＝Ｈ６７８
貴組織をセグメント化する：ＳＤ＝Ｈ７８９
貴組織をセグメント化する：ＳＤ＝Ｉ３４５

ミーガンは、ここで入り、セグメントを以下のように作成する。
セグメント名：内容
マイアミ東：ＴＩ＝２２２３３３４４４、ＳＤ＝Ｈ６７８
マイアミ中央：ＴＩ＝２２２３３３４４４、ＳＤ＝Ｈ７８９
マイアミ：ＴＩ＝２２２３３３４４４、ＳＤ＝Ｈ６７８、ＳＤ＝Ｈ７８９
タンパ：ＴＩ＝６６６７７７６６６、ＳＤ＝Ｉ３４５
組織全体：ＴＩ＝２２２３３３４４４、ＴＩ＝６６６７７７６６６、ＳＤ＝Ｈ６７８、ＳＤ＝Ｈ７８９、ＳＤ＝Ｉ３４５

尚、ミーガンは、「ＤＥＦ」が「サイト定義」ｉｄ及びビジネス機能を追加する前に直ちにセグメントを作成することができたであろう。仮にそうしたとすれば、セグメントは、「サイト定義」ｉｄが利用可能ではないので「納税ＩＤ」のみを含むであろう。その後、「サイト定義」ｉｄが利用可能になった時、彼女は、「サイト定義」ｉｄを適切なセグメントに追加することができたであろう。早期に設定作業を行った場合、全てのビジネス機能又は「サイト定義」ｉｄにアクセスすることができなくなることから、全てのビジネス機能を割り当てることはできなくなる。
ミーガンには、所在地の各々に対して確立された「ＡＡ」、すなわち、マイアミ東にはチャールズ、マイアミ中央にはスーザン、タンパにはジョージがいる。
ビジネス機能を割り当てる時、ミーガンには以下の情報が表示され、チャールズ、スーザン、及びジョージについて行った選択は「Ｘ」で表示される。

尚、上述の割当てに基づいて、チャールズはマイアミについての全ての紹介を担当するが、スーザンは何も担当しない。
チャールズには、数人のスタッフがいる。スタッフにアクセスを割り当てる時、彼は、表示された以下のリストを見る。

マイアミに関してチャールズに紹介処理を割り当てることができた複数の方法がある。
３つのオプションは以下の通りである。

オプション１は、チャールズに紹介処理が割り当てられた方法である。
割当てのためにどのような「アクセス識別子」及びセグメントがチャールズに利用可能であるかに関連した規則があれば、実際に行われたチャールズに対する割当て方法は問題にならないであろう。上記に示すように、全てのオプションは、「紹介処理」用データの割当てに対する選択肢をもたらす。

「派生」アクセス識別子に関する４つの規則があり、それらは以下の通りである。
１．セキュリティ保護ログオンアプリケーションは、バックエンドシステムを詳細に調べる処理を通じて「派生」アクセス識別子を見出す。その処理は、「親」アクセス識別子を使用して「親」アクセス識別子に関係するバックエンドシステムの識別子を検索し、管理者（「ＰＡＡ」又は「ＡＡ」）に呈示するものである。次に、管理者は、目標とする「派生」アクセス識別子を選択する。この処理の一般的な流れを図１４に示す。「原点ポート」（ＰＯ）開発担当者は、バックエンドアクセス識別子を検索するためのルーチンを実行し、バックエンドアクセス識別子を「ユーザインタフェース」を通じて「管理者」に呈示し、その後、セキュリティ保護ログオンアプリケーション供給の「ＡＰＩ」ルーチンを通じて、選択された「派生」アクセス識別子リストをセキュリティ保護ログオンアプリケーションに送ることになっている。更に、セキュリティ保護ログオンアプリケーションは、登録アプリケーション（プログラム）が、セキュリティ保護ログオンアプリケーション受領者を通じて派生アクセス識別子を追加することを可能にすることになる。

２．「セグメント管理」機能は、ユーザが「派生識別子」を選択することを可能にする処理へのリンクを含む。このビジネス機能及びデータにアクセスすることができる個人だけが、「ＰＯ」の機能を使用してセキュリティ保護ログオンアプリケーションに追加するための派生アクセス識別子を見つけることができる。
３．追加されたアクセス識別子は、個別に使用することができないので、「セグメント」内に置くべきである。
４．「派生」アクセス識別子は、セグメント内でのみ使用することができるので、ビジネス機能がセグメント化可能でないことを表示する結果は、「派生」識別子がそれに対して準備されていないということである。

もはやアクティブではないアクセス識別子に関する１つの規則があり、それは以下の通りである。
セキュリティ保護ログオンアプリケーションは、任意のアクセス識別子（主又は派生）が依然としてバックエンドシステム内でアクティブであることを保証するための同期化の方法を設けていない。ビジネス機能が業務規則に従ってアクセス識別子を適切に使用することを保証することは、全てのビジネス機能の責任であり、すなわち、それ以外のアクティブではないアクセス識別子は、報告のために必要とされるかもしれないが、新しい作業には使用すべきではない。その例として、ブローカーは、もはや代理店のために業務を行っていないが、そのブローカーアクセス識別子は、現在の会計年度の手数料報告書を発行するためにはまだ必要とされる。ビジネス機能は、他の状況では、無効又は非アクティブアクセス識別子を遠まわしに避けるか、又はユーザにどうしたらよいかを教えることができるべきである。ビジネス機能は、適切な方法でアクセスＩＤを取り扱うべきである。例えば、ビジネス機能は、アクセス識別子を拒否するか、又は新しい作業にではなく報告に使用することができる。

アクセス識別子及びセグメントの削除に関する３つの規則があり、それらは以下の通りである。
１．アクセス識別子を削除する時は常に、アクセス識別子及びその子への参照を削除すべきである。
ａ．「Ａｃｃｅｓｓ＿Ｉｄｅｎｔｉｆｉｅｒ」表内のそのアクセス識別子以下のサブツリー全体を削除すべきであり、すなわち、全ての子を削除すべきである。
ｂ．更に、削除されたアクセス識別子及びその子を参照する「ＥＵＡ」表内の全ての行を削除すべきである。
ｃ．「Ａｃｃｅｓｓ＿Ｇｒｏｕｐ＿ＩＤ＿Ａｓｓｏｃ」表内の結び付きを除去することにより、セグメント内の削除されたアクセス識別子とその子に対する全ての参照を削除すべきである。
ｄ．「委任」表内の削除されたアクセス識別子及びその子に対する全ての参照を非アクティブと標記すべきであり、また、それらの「委任」行に付随する全ての「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」行を非アクティブと標記すべきである。
２．「ＥＵＡ」行又は「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」行の削除は、アクセス識別子を削除した時に空になるセグメントを指す行については行わない。
３．セグメントを削除する時は常に、セグメントへの参照を削除すべきである。
ａ．削除されたセグメントを参照する「ＥＵＡ」表内の全ての行を削除すべきである。
ｂ．「委任」表内の削除されたセグメントへの全ての参照を非アクティブと標記すべきであり、また、それらの「委任」行に付随する全ての「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」行を非アクティブと標記すべきである。

アクセス識別子の追加に関する２つの規則がある。
１．アクセス識別子をエンティティに追加した時、そのタイプのアクセス識別子を使用することができる現在割り当てられている任意のビジネス機能と共に、そのアクセス識別子が「ＰＡＡ」に自動的に割り当てられることになる。
２．「ＰＡＡ」に現在割り当てられていないいかなるビジネス機能に対しても、このような自動割当てを行うべきではない。

ロギング及び監査記録に関する２つの規則があり、それらは以下の通りである。
１．ログ記録は、アクセス識別子及びセグメントのあらゆる追加、変更、及び削除に関して保管される。
２．セキュリティ保護ログオンアプリケーションは、任意の個人又はエンティティがどのようにして他の個人に代わって機能を実行する権限を受け取ったかに関する監査記録を有する。

委任に関する２３個の規則があり、それらは以下の通りである。
１．エンティティが別のエンティティに作業の一部又は全てを代行して欲しいと思った時は常に、「ＰＡＡ」は、「アクセスを委任する」作業流れに従うことになる。「ＰＡＡ」は、「委任可能な」ビジネス機能の任意の一部又は全て、及び情報へのアクセスを他のエンティティに委任することができる。
２．委任は、特定の個人のエンティティ内で他の人々に「アクセスを割り当てる」ための代替方法ではない。割当ては、個人のエンティティ内の他の人々に作業を行う能力を与える処理であり、委任は、別のエンティティへアクセスを付与することである。
３．セキュリティ保護ログオンアプリケーションは、どのエンティティタイプを別のエンティティタイプに委任することができるかを予め判断することになり、例えば、プロバイダは、第三者管理者に委任することができるが、会員エンティティにはできない。
４．「ＰＡＡ」は、「ＢｅｈａｌｆＯｆ」エンティティが「ＰＡＡ」の勤務するエンティティ（Ａｄｍｉｎエンティティ）に作業を委任した時、「ＢｅｈａｌｆＯｆ」エンティティの仮想エンティティユーザになる。「ＰＡＡ」と、その後に許可が与えられた場合は「Ａｄｍｉｎ」エンティティの「ＡＡ」とは、「ＰＡＡ」／「ＡＡ」が委任された作業をユーザに割り当てた時に、他の仮想エンティティユーザを作成する。スポンサー組織の「ＩＴ」セキュリティ担当者も、委任された作業をユーザに割り当てた時に仮想エンティティユーザを作成することができる。これらの仮想エンティティユーザの各々は、エンティティユーザ表内に行を有することになる。

５．個人に別のエンティティへの委任を通じてアクセスが与えられた時、その別のエンティティというコンテキストにおいて、その個人は「ＯＡ」であるに過ぎず、そのエンティティの「ＡＡ」又は「ＰＡＡ」にはなれない。
６．自身のエンティティというコンテキストにおいて個人が「ＰＡＡ」又は「ＡＡ」である場合、その個人は、そのエンティティに「雇われた」人々に他のエンティティへのアクセスを割り当てることができる。
７．図１７を参照すると、委任チェーンは、チェーン識別子、レベル、及び親である３組のデータにより追跡される。このチェーンは、特定のエンティティ／ビジネス機能／データのセットに関する委任をグループ分けする。例えば、「ＸＹＺ」が「請求を申請する」を「ＤＥＦ」に委任した時、「Ｃ１３５７」というチェーンＩＤが割り当てられる。「ＤＥＦ」が「ＡＢＣ」に委任することにより委任を進めた時、その委任は、同じチェーンＩＤ「Ｃ１３５７」を有する。「ＸＹＺ」から「ＤＥＦ」の第１の委任は、レベル１であり、「ＤＥＦ」から「ＡＢＣ」への委任は、レベル２である。親の値は、委任を与えた行を指示する。「ＸＹＺ」から「ＤＥＦ」の委任には親がないので、「ＮＵＬＬ」である。「ＤＥＦ」から「ＡＢＣ」への委任には、「ＸＹＺ」から「ＤＥＦ」の行の親がある。また、「ＤＥＦ」は、同じ作業を「ＭＮＯ」に委任することが可能である。「ＤＥＦ」による「ＭＮＯ」へのこの委任は、「ＤＥＦ」による「ＡＢＣ」への委任と同じチェーンＩＤ、同じレベル、及び同じ親値を有することになる。

８．各「委任チェーン」は、各「ビジネス機能／データアクセス対」に関して別々に検討される。多くの異なる「委任チェーン」が存在する可能性がある。実際に、各「ビジネス機能／データアクセス対」又は「ビジネス機能のみ」は別々に委任されるので、２つのエンティティ間で何百もの異なる「委任チェーン」が存在することができる。
９．第１の委任については、「ＥＵＡ」内の委任された行と「ＥＵＡ＿ＤＥＬＥＧＡＴＩＯＮ＿ＡＳＳＯＣ」表との間には一対一の対応がある。
１０．委任された作業が「Ａｄｍｉｎ」エンティティ内のスタッフに割り当てられた時、「ＰＡＡ」への委任に使用された「委任」定義は、スタッフにも使用される。これは、「Ａｄｍｉｎ」エンティティ内の「ＰＡＡ」又は「ＡＡ」が、「Ａｄｍｉｎ」エンティティ内の別のスタッフに「委任されたアクセスを割り当てる」を行った時、他のスタッフに「ＥＵＡ」エントリが作成され、「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」表は、新しい「ＥＵＡ」行を「ＰＡＡ」に対する最初の「委任」と関連付けるエントリを含むことを意味する。

１１．異なる経路を通じた同じ「ＢｅｈａｌｆＯｆ」エンティティから「Ａｄｍｉｎ」エンティティへの複数の委任チェーンがあり、かつ「Ａｄｍｉｎ」エンティティが委任を欲する時、チェーンの全ては、次のレベルまで拡張されることになる。これは、次のレベルへのこの委任の結果として作成された任意の「ＥＵＡ」エントリに関して、「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」表内に複数のエントリが存在することになることを意味する。一例として図１６を参照し、エンティティＡの作業が、Ａ⇒Ｂ⇒Ｄ及びＡ⇒Ｃ⇒Ｄのように委任されていると仮定する。この場合、エンティティＤは、２つの異なるパスを通じてＡの代行として作業を行うことができる。Ａの代行としてＤ⇒Ｅの時、Ｄに対するＡの委任チェーンの両方は、エンティティＥまで拡張されることになる。これは、Ａの代行として作業を行うためにＥにおけるユーザのために使用される任意の「ＥＵＡ」エントリは、「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」表内で２つのエントリを有することになり、１つは、Ａ⇒Ｂ⇒Ｄ⇒Ｅの委任パスを表し、１つは、Ａ⇒Ｃ⇒Ｄ⇒Ｅの委任パスを表すことを意味する。

１２．２つの異なるパスを通じて同一「Ａｄｍｉｎ」エンティティまで拡張された複数の委任パスの上述のような場合においては、委任は、パスの１つが取り消されたとしても継続することになる。上述の例において、ＡがＣに対する委任を取り消した場合、Ａ⇒Ｂ⇒Ｄ⇒Ｅのパスは残り、Ｅは、依然としてＡの代行として作業を行うことができる。この場合、Ａ⇒Ｃ⇒Ｄ⇒Ｅを表す「委任」は、非アクティブにされ、その「委任」を参照する「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」行も同様に非アクティブにされるであろう。
１３．セキュリティ保護ログオンアプリケーションは、委任チェーン内において「ループ」を有することを許可しない。すなわち、「ＰＡＡ」又は「ＡＡ」は、同じ委任チェーン上で最初のエンティティの代行として既に委任されたいかなる組織にも委任して戻すことはできない。例えば、ＡがＢに委任し、ＢがＡの作業をＣに委任した場合、Ｃは、Ａの作業をＡ又はＢに委任することはできず、Ｂは、Ａの作業をＡに委任して戻すことはできない。

１４．「Ｄｅｌｅｇａｔｉｏｎ＿Ａｕｔｈｏｒｉｚａｔｉｏｎ」表は、２つのエンティティ間の委任が最初に正しいエンティティに到達することを保証するものである。受け取り側エンティティは、この表において「委任受理コード」エントリを設定し、この公開情報を委任を実行することになる「ＰＡＡ」に伝える。この表のエントリは、他のエンティティがこのエンティティに委任するための「扉を開く」ものである。受け取り側エンティティの「ＰＡＡ」は、全ての委任を受け取るために使用する１つのエントリを有することを選択することができるか、又は、各委任について別々の行を作成することができる。それは、受け取り側「ＰＡＡ」の裁量によるものである。この表における行は、受け取り側「ＰＡＡ」又はスポンサー組織の「ＩＴ」セキュリティ担当者により非アクティブにされる。
１５．委任の結果、「Ａｄｍｉｎ」エンティティの「ＰＡＡ」は、ビジネス機能及びデータを受け取る。セキュリティ保護ログオンアプリケーションは誰が委任を受け取るかに関してある程度の制御を行うべきであるから、エンティティは、他のエンティティの「ＰＡＡ」以外の誰にも委任することはできない。「ＰＡＡ」は、その後、委任された権利の「委任されたアクセスを割り当てる」をその組織内の他人に対して行い、最初の委任側エンティティの代行として作業を行うことができる委任先の会社の人々をもたらす。委任処理には、委任側エンティティの「ＰＡＡ」又は「ＡＡ」が「委任先」エンティティの「ＰＡＡ」からの委任受理コード値を知っている必要がある。

１６．「ＰＡＡ」又は「ＡＡ」は、所属エンティティからチェーン内の次のエンティティへの直接的な委任のみを取り消すことができる。
１７．特定のビジネス機能／データ対に対する権利の除去か又は全ての権利が「別の組織への委任の停止」を通じて除去されるために委任が終了された時、委任終了側エンティティ内の全ての対応する委任及び全てのその後のもの（下位レベルの認証）は、自動的に終了される（取り消される）。これをカスケード削除と呼ぶ。どの項目を取り消すかの判断は、委任チェーンを詳しく検討して「委任」表の対応する「委任」及び「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」表からの結び付きを非アクティブにすることにより行われる。「ＥＵＡ」行は、「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」表内に「ＥＵＡ」行に関する残りのエントリがない場合は除去される。
１８．Ａが既に「ビジネス機能／データ対」についてＢに委任しており、しばらくしてＡが同じビジネス機能について更に別のアクセスＩＤをＢに委任したいと思った場合、セキュリティ保護ログオンアプリケーション内には、これを達成する２通りの方法がある。すなわち、（１）その委任が「セグメント」を使用して最初に行われた場合、Ａの管理者は、新規アクセスＩＤを適切な「セグメント」に追加するだけで済むか、又は、（２）Ａは、「委任を変更する」処理を実行して「ビジネス機能／新規アクセスＩＤ対」をＢに委任する。いずれの場合においても、Ａの「ＰＡＡ」は、Ｂの「ＰＡＡ」に新規アクセスＩＤが委任されたことを告げるべきである。

１９．セグメントが１つの組織から別の組織に委任された場合、受け取り側組織の「ＰＡＡ」及び「ＡＡ」は、セグメント内の個々の項目を見ることはできなくなり、最初のセグメント内の項目又は個別に委任された主アクセスＩＤのそれ自身のセグメントを定義することができない。
２０．「委任された作業を割り当てる」作業流れ中のアクセス識別子の割当てにおいて、「ＰＡＡ」又は「ＡＡ」は、自分に直接割り当てられたセグメント又は主アクセスＩＤを割り当てることができる。
２１．受け取り側「ＰＡＡ」は、自分に委任されたセグメントを定義／再定義することは許可されていないので、委任された機能及び任意の更に別の委任の割当ては、最初に割り当てられたもので行われることになる。
２２．「ＰＡＡ」が更に別の委任を制御する明示的な方法はない。セキュリティ保護ログオンアプリケーションの将来の目的は、４つの方向、すなわち、更に別の委任は許されない、許可付きで許される委任、通知付きで許される委任、及び制約なしで許される委任に沿ってアクセスを制御することである。現時点での制御は、「委任を実行する」機能を「委任を受け取る」機能を有する組織に委任しないことから成る。

２３．委任情報の簡単な要約及び委任情報が記憶された表
ａ．「委任ビジネス機能」及び「アクセス識別子」対は、委任チェーンの定義と共に「Ｄｅｌｅｇａｔｉｏｎ＿Ｔａｂｌｅ」に記憶される。委任チェーンにより、ビジネス機能／アクセス識別子対の存在の「理由」がもたらされる。３つのデータ、すなわち、チェーン識別子、レベル、及び親により、委任チェーンが定義される。「Ｄｅｌｅｇａｔｉｏｎ＿Ｔａｂｌｅ」には、エンティティ単位の情報がある。
ｂ．仮想「エンティティユーザ」は、「Ｅｎｔｉｔｙ＿Ｕｓｅｒ」表に記憶され、「ＢｅｈａｌｆＯｆ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」＜＞「Ａｄｍｉｎ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」であり、「ＧｒａｎｅｄＢｙ＿Ｅｎｔｉｔｙ＿Ｇｅｎ＿Ｋｅｙ」は、「ｎｕｌｌ」である（エンティティによる付与は、「Ｄｅｌｅｇａｔｉｏｎ＿Ｔａｂｌｅ」を見て委任チェーン情報を検討することにより判断することができる）。
ｃ．「ＢｅｈａｌｆＯｆ」エンティティの代行としてユーザに割り当てられた各「ビジネス機能／アクセス識別子」対について、「Ｅｎｔｉｔｙ＿Ｕｓｅｒ＿Ａｃｃｅｓｓ」（ＥＵＡ）エントリがある。
ｄ．「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」表は、「ＥＵＡ」エントリをその存在の理由、すなわち、ユーザが「ＥＵＡ」エントリで作業を行う許可を受け取った委任チェーンを文書化する「Ｄｅｌｅｇａｔｉｏｎ＿Ｔａｂｌｅ」内のエントリ又はエンティティと関連付けるものである。
ｅ．誰かが「委任された作業を割り当てられた」時、彼のために「ＥＵＡ」記録が作成され、「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」表は、新規「ＥＵＡ」行と「ＰＡＡ」が同じ許可を受け取った理由を文書化する同じ「委任」とを関連付けるエントリを含む。
ｆ．既存のチェーンから更に別の委任が行われた時、「委任」表内の新規エントリに関する３組のデータは、同じチェーンＩＤを含み、発生元の委任から１だけ増分したレベルを有し、発生元の委任を指示する親を有するように現れる委任を定義する３組のデータと関連付けられる。
ｇ．ユーザが複数のパスから委任された同じ機能性を有する時、同一「ＥＵＡ」行が使用され、別の行（理由）が「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」表に追加され、１つの「ＥＵＡ」行を異なる「委任」エントリと関連付ける。
ｈ．複数のパスから機能性を受け取ったユーザから機能が除去された時、除去されたパスに付随する「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」行を非アクティブにし、その「ＥＵＡ」行に関して他の「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」行がない場合に限り、「ＥＵＡ」行を除去する。
図２３から図２９は、委任を管理するための機能性、及び、典型的な「作業を委任する」作業流れ及び「委任された作業を割り当てる」作業流れを示す。
図３０は、重要な構成要素間の概念上の関係を示す。以下の３つの実施例は、図３０が説明する基本的概念を示す。

例１：図３０における概念の説明
以下は、図３０に示す基本概念を説明するものであり、健康保険会社がスポンサー組織である。
セキュリティ保護ログオンアプリケーションが確立された時、以下の項目、すなわち、２つの原点ポート、２つの「アクセス識別子タイプ」、３つのシステムアプリケーション、３つの「所有者」、５つの「ビジネス機能セット」が設定される。
設定される２つの「原点ポート」は、「雇用主のエンティティタイプ」の「原点ポート」及び「プロバイダのエンティティタイプ」の「原点ポート」である。
「アクセス識別子タイプ」は、「雇用主エンティティタイプ」により使用される「顧客グループ番号」及び「プロバイダエンティティタイプ」により使用される「納税識別番号」である。

３つの「システムアプリケーション」がサポートされ、各々は、１つ又は２つの「ビジネス機能」を有する。「雇用主サポートアプリケーション」は、「オンライン会計」及び「会員ＩＤカード交換」を実行する。「プロバイダサポートアプリケーション」は、「保険金請求問い合わせ」及び「適格性問い合わせ」を実行する。「アカウント管理アプリケーション」は、「新規ユーザの登録」を実行する。
「雇用主サポートアプリケーション」の「所有者」は、会社の「会計及び登録部」である。「プロバイダサポートアプリケーション」の「所有者」は、会社の「プロバイダ渉外部」である。「アカウント管理アプリケーション」の「所有者」は、会社の「社内セキュリティ部」である。

５つの「ビジネス機能セット」、すなわち、「会員ＩＤカード交換」を含む「雇用主会員機能」セット、「オンライン会計」を含む「雇用主会計機能」セット、「新規ユーザの登録」を含む「雇用主アカウント管理」セット、「保険金請求問い合わせ」及び「紹介問い合わせ」を含む「プロバイダ機能」セット、及び「新規ユーザの登録」を含む「プロバイダアカウント管理」セットが存在する。
異なる「ビジネス機能セット」が、各「エンティティタイプ」に関連付けられる。「雇用主エンティティタイプ」は、「雇用主会員機能」、「雇用主会計機能」、及び「雇用主アカウント管理」という「ビジネス機能セット」を使用する。「プロバイダエンティティタイプ」は、「プロバイダ機能」及び「プロバイダアカウント管理」という「ビジネス機能セット」を使用する。

「雇用主原点ポート」の「原点ポートメニュー」には、個々の「ビジネス機能」、すなわち、「会員ＩＤカード交換」、「オンライン会計」、及び「雇用主アカウント管理」が列挙されている。
「プロバイダ原点ポート」の「原点ポートメニュー」には、まず個々の「プロバイダアカウント管理」機能、次に「プロバイダ機能」セットがユニットとして列挙されている。
セキュリティ保護ログオンアプリケーションとして存在する項目は、何が起こるかに依存する。この例においては、２つの組織、すなわち、「ポプキンス内科」及び「アクメ放送」が登録される。「ポプキンス内科」は、２つのユーザを登録し、「アクメ放送」は、１つのユーザを登録する。これらのアクションの結果として、存在する項目は、２つの「エンティティ」、２つの「アクセス識別子」、３つの「ユーザ」、及び３つの「エンティティユーザ」である。

２つの「エンティティ」、すなわち、スポンサー組織により保険が掛けられた個人に医療を行い、「プロバイダエンティティタイプ」として登録される「ポプキンス内科」と、スポンサー組織を通じて自社従業員に保険を掛け、「雇用主エンティティタイプ」として登録される「アクメ放送」とが存在する。
「ポプキンス内科」の「アクセス識別子」の値は、１２３４５６７８９であり、「納税識別番号」の「アクセス識別子タイプ」を有する。「アクメ放送」の「アクセス識別子」値は、ＡＢ１２３４５であり、「顧客グループ番号」の「アクセス識別子タイプ」を有する。
３つのユーザとは、「ポプキンス内科」により「ユーザ」として登録されるアイリーン・ポプキンス、「ポプキンス内科」により「ユーザ」として登録されるマーチン・カーバー、及び「アクメ放送」の「ユーザ」として登録されるメリー・スミスである。

１つよりも多いエンティティに付随する「ユーザ」がいないので、３つの「エンティティユーザ」、すなわち、「ポプキンス内科」に対するアイリーン・ポプキンス、「ポプキンス内科」に対するマーチン・カーバ、及び「アクメ放送」に対するメリー・スミスも存在する。
「エンティティユーザビジネス機能」は、「エンティティタイプ」に付随する「ビジネス機能セット」内の「ビジネス機能」から付与される。「ポプキンス内科」のアイリーン・ポプキンスには、「プロバイダ機能」及び「プロバイダアカウント管理」セットからの機能を付与することができ、実際には、「新規ユーザの登録」、「保険金請求問い合わせ」、及び「紹介問い合わせ」が付与される。「ポプキンス内科」のマーチン・カーバには、「プロバイダ機能」及び「プロバイダアカウント管理」セットからの機能を付与することができ、実際には、「保険金請求問い合わせ」及び「紹介問い合わせ」が付与される。

「アクメ放送」のメリー・スミスには、「雇用主会員機能」、「雇用主会計機能」、及び「雇用主アカウント管理」セットからの機能を付与することができ、実際には、「会員ＩＤカード交換」、「オンライン会計」、及び「新規ユーザの登録」が付与される。
「プロバイダ原点ポート」内のアイリーン・ポプキンスの「ユーザメニュー」は、「新規ユーザの登録」及び「プロバイダ機能」を表示する。「プロバイダ原点ポート」内のマーチン・カーバのユーザメニューは、「プロバイダ機能」を表示する。「雇用主原点ポート」内のメリー・スミスのユーザメニューは、「会員ＩＤカード交換」、「オンライン会計」、及び「新規ユーザの登録」を表示する。

例２：エンティティとしての２つの個人
エンティティは、組織と同様に人々とすることができる。一般的に、スポンサー組織は、組織及び人々とも直接的な関係を有する。これらの人々又は組織は、スポンサー組織と異なる種類の関係を有する。これらの人々又は組織がエンティティとして設定された時、各エンティティは、そのエンティティがスポンサー組織と有する関係を表すエンティティタイプで設定される。これは、異なるビジネス機能を異なるエンティティタイプについて確立することができるようにするため、及び、時間と共にエンティティ間で容易に関係を確立するために行われる。健康保険スポンサー組織でのこれらの状況の例は、以下の通りである。

健康保険プランの会員：一般的に、個人は、健康保険プランを購入する雇用主により雇用されることにより健康保険プランの会員になる。一見すると、会員は、雇用主に付随するユーザとして設定されるであろうという期待があるかもしれない。しかし、会員については、雇用主に対するのとは異なるビジネス機能が利用可能であり、会員は、時間と共に雇用主を変更することができる。別々の会員エンティティタイプを有することにより、これらの状況の各々が容易になる。

一般的に、内科医は、プロバイダ組織と関連付けられることにより健康保険会社と取引きする。一見すると、内科医は、プロバイダ組織に付随するユーザとして設定されるであろうという期待があるかもしれない。しかし、内科医については、異なるビジネス機能が利用可能であり、そのいくつかは、医療の実施を処理するものであり、また、内科医は、時間と共にプロバイダ組織を変えることができる。別々の内科医エンティティタイプを有することにより、これらの状況の各々が容易になる。

以下は、会員をエンティティとして示すことにより上述の実施例１の上に構築される例である。
セキュリティ保護ログオンアプリケーションが確立された時、以下の項目、すなわち、３つの「原点ポート」、３つの「アクセス識別子タイプ」、４つの「システムアプリケーション」、４つの「所有者」、及び７つの「ビジネス機能セット」が設定される。
設定される３つの「原点ポート」は、「雇用主のエンティティタイプ」に対する「原点ポート」、「プロバイダのエンティティタイプ」に対する「原点ポート」、及び「会員のエンティティタイプ」に対する「原点ポート」である。
「アクセス識別子タイプ」は、「雇用主エンティティタイプ」により使用される「顧客グループ番号」、「プロバイダエンティティタイプ」により使用される「納税識別番号」、及び「会員エンティティタイプ」により使用される「会員ＩＤ」である。

４つの「システムアプリケーション」がサポートされ、各々は、１つ又は２つの「ビジネス機能」を有する。「雇用主サポートアプリケーション」は、「オンライン会計」及び「会員ＩＤカード交換」を実行する。「プロバイダサポートアプリケーション」は、「保険金請求問い合わせ」及び「適格性問い合わせ」を実行する。「会員サポートアプリケーション」は、「紹介問い合わせ」及び「主治医（ＰＣＰ）の変更」を実行する。「アカウント管理アプリケーション」は、「新規ユーザの登録」及び「別のユーザへ自分のアカウントを開く」を実行する。
「雇用主サポートアプリケーション」の「所有者」は、会社の「会計及び登録部」である。「プロバイダサポートアプリケーション」の「所有者」は、会社の「プロバイダ渉外部」である。「会員サポートアプリケーション」の「所有者」は、会社の「会員渉外部」である。「アカウント管理アプリケーション」の「所有者」は、会社の「社内セキュリティ部」である。

７つの「ビジネス機能セット」は、「会員ＩＤカード交換」を含む「雇用主会員機能」セット、「オンライン会計」を含む「雇用主会計機能」セット、「新規ユーザの登録」を含む「雇用主アカウント管理」セット、「保険金請求問い合わせ」及び「紹介問い合わせ」を含む「プロバイダ機能」セット、「新規ユーザの登録」を含む「プロバイダアカウント管理」セット、「紹介問い合わせ」及び「ＰＣＰの変更」を含む「会員機能」セット、及び、「別のユーザへ自分のアカウントを開く」を含む「会員アカウント管理」セットである。

異なる「ビジネス機能セット」は、各「エンティティタイプ」に付随する。「雇用主エンティティタイプ」は、「雇用主会員機能」、「雇用主会計機能」、及び「雇用主アカウント管理」の「ビジネス機能セット」を使用する。「プロバイダエンティティタイプ」は、「プロバイダ機能」及び「プロバイダアカウント管理」の「ビジネス機能セット」を使用する。「会員エンティティタイプ」は、「会員機能」及び「会員アカウント管理」の「ビジネス機能セット」を使用する。

「雇用主原点ポート」用の「原点ポートメニュー」には、個々の「ビジネス機能」、すなわち、「会員ＩＤカード交換」、「オンライン会計」、及び「雇用主アカウント管理」が列挙されている。
「プロバイダ原点ポート」用の「原点ポートメニュー」には、最初に個々の「プロバイダアカウント管理」機能、次に「プロバイダ機能」セットがユニットとして列挙されている。
「会員原点ポート」用の「原点ポートメニュー」には、「会員機能」セットがユニットとして、次に「会員アカウント管理」セットがユニットとして列挙されている。

セキュリティ保護ログオンアプリケーションが使用される時に存在してくる項目は、何が起こるかに依存する。この例においては、２つの組織及び１つの個人がエンティティとして登録され、すなわち、「ポプキンス内科」、「アクメ放送」、及びスチーブン・タワーズである。「ポプキンス内科」は、２つのユーザを登録し、「アクメ放送」は１つのユーザを登録し、スチーブン・タワーズは、彼のエンティティ内の唯一のユーザである。これらのアクションの結果として、存在してくる項目は、３つの「エンティティ」、３つの「アクセス識別子」、４つの「ユーザ」、及び４つの「エンティティユーザ」である。

３つのエンティティは、スポンサー組織により保険が掛けられた個人に医療を行い、「プロバイダエンティティタイプ」として登録される「ポプキンス内科」、スポンサー組織を通じて自社従業員に保険を掛け、「雇用主エンティティタイプ」として登録される「アクメ放送」、及び「アクメ放送」に勤務し、その結果としてスポンサー組織により保険が掛けられ、かつ、「会員エンティティタイプ」として登録されるスチーブン・タワーズである。
「ポプキンス内科」は、「納税識別番号」の「アクセス識別子タイプ」を有する１２３４５６７８９の「アクセス識別子」を使用する。「アクメ放送」は、「顧客グループ番号」の「アクセス識別子タイプ」を有するＡＢ１２３４５の「アクセス識別子」を使用する。スチーブン・タワーズは、「会員ＩＤ」の「アクセス識別子タイプ」を有するＳＴＡＢ１２３４５の「アクセス識別子」を使用する。

４つの「ユーザ」は、「ポプキンス内科」により「ユーザ」として登録されるアイリーン・ポプキンス、「ポプキンス内科」により「ユーザ」として登録されるマーチン・カーバ、「アクメ放送」の「ユーザ」として登録されるメリー・スミス、及び、自分自身のエンティティ、すなわち、「スチーブン・タワーズ」エンティティの「ユーザ」として登録されるスチーブン・タワーズである。
１つよりも多いエンティティに付随する「ユーザ」がいないので、４つの「エンティティユーザ」、すなわち、「ポプキンス内科」に対するアイリーン・ポプキンス、「ポプキンス内科」に対するマーチン・カーバ、「アクメ放送」に対するメリー・スミス、「スチーブン・タワーズ」（エンティティ）に対するスチーブン・タワーズも存在する。

「エンティティユーザビジネス機能」は、「エンティティタイプ」に付随する「ビジネス機能セット」内の「ビジネス機能」から付与される。「ポプキンス内科」のアイリーン・ポプキンスには、「プロバイダ機能」及び「プロバイダアカウント管理」セットから機能を付与することができ、実際に「新規ユーザの登録」、「保険金請求問い合わせ」、及び「紹介問い合わせ」が付与される。
「ポプキンス内科」のマーチン・カーバには、「プロバイダ機能」及び「プロバイダアカウント管理」セットから機能を付与することができ、実際に「保険金請求問い合わせ」及び「紹介問い合わせ」が付与される。
「アクメ放送」のメリー・スミスには、「雇用主会員機能」、「雇用主会計機能」、及び「雇用主アカウント管理」セットから機能を付与することができ、実際に「会員ＩＤカード交換」、「オンライン会計」、及び「新規ユーザの登録」が付与される。
「スチーブン・タワーズ」（エンティティ）のスチーブン・タワーズには、「会員機能」及び「会員アカウント管理」セットから機能を付与することができ、実際に「紹介問い合わせ」、「ＰＣＰの変更」、及び「別のユーザへ自分のアカウントを開く」が付与される。

「プロバイダ原点ポート」におけるアイリーン・ポプキンス用の「ユーザメニュー」には、「新規ユーザの登録」及び「プロバイダ機能」が表示される。「プロバイダ原点ポート」におけるマーチン・カーバ用の「ユーザメニュー」には、「プロバイダ機能」が表示される。「雇用主原点ポート」におけるメリー・スミス用の「ユーザメニュー」には、「会員ＩＤカード交換」、「オンライン会計」、及び「新規ユーザの登録」が表示される。「会員原点ポート」におけるスチーブン・タワーズ用の「ユーザメニュー」には、「会員機能」及び「会員アカウント管理」が表示される。

例３：１つよりも多いエンティティに付随するユーザ
ユーザは、１つよりも多いエンティティに付随することができる。一例として、ユーザは、会員であることが可能であり、かつ自分自身と関連付けることができ、また、雇用主組織内の管理者であることが可能である。以下において、上述の実施例１及び実施例２の上に構築することによりこの概念を説明する。全ての新しい項目は下線付きで表示される。

セキュリティ保護ログオンアプリケーションが確立された時の項目は、実施例２と同一であり、変更点はない。
セキュリティ保護ログオンアプリケーションが使用される時に存在してくる項目は、何が起こるかに依存する。この例においては、２つの組織及び２人の人々、すなわち、「ポプキンス内科」、「アクメ放送」、スチーブン・タワーズ、及びメリー・スミスがエンティティとして登録される。「ポプキンス内科」は、２つのユーザを登録し、「アクメ放送」は１つのユーザを登録する。スチーブン・タワーズは、自分のエンティティ内の唯一のユーザであり、メリー・スミスは、自分のエンティティ内の唯一のユーザである。これらのアクションの結果として、存在してくる項目は、４つの「エンティティ」、４つの「アクセス識別子」、４つの「ユーザ」、及び５つの「エンティティユーザ」である。

４つのエンティティは、スポンサー組織により保険が掛けられた個人に医療を行い、「プロバイダエンティティタイプ」として登録される「ポプキンス内科」、スポンサー組織を通じて自社従業員に保険を掛け、「雇用主エンティティタイプ」として登録される「アクメ放送」、「アクメ放送」に勤務し、その結果としてスポンサー組織により保険が掛けられ、かつ、「会員エンティティタイプ」として登録されるスチーブン・タワーズ、及び、上述の例において「アクメ放送」の管理者として登録され、「アクメ放送」に勤務し、その結果としてスポンサー組織により保険が掛けられ、かつ「会員エンティティタイプ」として登録されるメリー・スミスである。

「ポプキンス内科」は、「納税識別番号」の「アクセス識別子タイプ」を有する１２３４５６７８９の「アクセス識別子」を使用する。「アクメ放送」は、「顧客グループ番号」の「アクセス識別子タイプ」を有するＡＢ１２３４５の「アクセス識別子」を使用する。スチーブン・タワーズは、「会員ＩＤ」の「アクセス識別子タイプ」を有するＳＴＡＢ１２３４５の「アクセス識別子」を使用する。メリー・スミスは、「会員ＩＤ」の「アクセス識別子タイプ」を有するＭＳＡＢ１２３４５の「アクセス識別子」を使用する。

４つの「ユーザ」は、「ポプキンス内科」により「ユーザ」として登録されるアイリーン・ポプキンス、「ポプキンス内科」により「ユーザ」として登録されるマーチン・カーバ、「アクメ放送」の「ユーザ」として、及び、自分自身のエンティティ、すなわち、「メリー・スミス」エンティティの「ユーザ」として登録されるメリー・スミス、及び、自分自身のエンティティ、すなわち、「スチーブン・タワーズ」エンティティの「ユーザ」として登録されるスチーブン・タワーズである。
１つの「ユーザ」が２つのエンティティに登録されることから、５つの「エンティティユーザ」、すなわち、「ポプキンス内科」に対するアイリーン・ポプキンス、「ポプキンス内科」に対するマーチン・カーバ、「アクメ放送」に対するメリー・スミス、メリー・スミス（エンティティ）に対するメリー・スミス、「スチーブン・タワーズ」（エンティティ）に対するスチーブン・タワーズが存在する。

「エンティティユーザビジネス機能」は、「エンティティタイプ」に付随する「ビジネス機能セット」内のビジネス機能から付与される。「ポプキンス内科」のアイリーン・ポプキンスには、「プロバイダ機能」及び「プロバイダアカウント管理」セットから機能を付与することができ、実際に「新規ユーザの登録」、「保険金請求問い合わせ」、及び「紹介問い合わせ」が付与される。
「ポプキンス内科」のマーチン・カーバには、「プロバイダ機能」及び「プロバイダアカウント管理」セットから機能を付与することができ、実際に「保険金請求問い合わせ」及び「紹介問い合わせ」が付与される。
「アクメ放送」のメリー・スミスには、「雇用主会員機能」、「雇用主会計機能」、及び「雇用主アカウント管理」セットから機能を付与することができ、実際に「会員ＩＤカード交換」、「オンライン会計」、及び「新規ユーザの登録」が付与される。「メリー・スミス」（エンティティ）のメリー・スミスには、「会員機能」及び「会員アカウント管理」セットから機能を付与することができ、実際に「紹介問い合わせ」、「ＰＣＰの変更」、及び「別のユーザへ自分のアカウントを開く」が付与される。
「スチーブン・タワーズ」（エンティティ）のスチーブン・タワーズには、「会員機能」及び「会員アカウント管理」セットから機能を付与することができ、実際に「紹介問い合わせ」、「ＰＣＰの変更」、及び「別のユーザへ自分のアカウントを開く」が付与される。

「プロバイダ原点ポート」におけるアイリーン・ポプキンス用の「ユーザメニュー」には、「新規ユーザの登録」及び「プロバイダ機能」が表示される。「プロバイダ原点ポート」におけるマーチン・カーバ用の「ユーザメニュー」には、「プロバイダ機能」が表示される。「雇用主原点ポート」におけるメリー・スミス用の「ユーザメニュー」には、「会員ＩＤカード交換」、「オンライン会計」、及び「新規ユーザの登録」が表示される。「会員原点ポート」におけるメリー・スミス用の「ユーザメニュー」には、「会員機能」及び「会員アカウント管理」が表示される。「会員原点ポート」におけるスチーブン・タワーズ用の「ユーザメニュー」には、「会員機能」及び「会員アカウント管理」が表示される。

Ｅ．ユーザステータス
１．概要
ビジネス機能を実行するためのユーザステータスの判断は、４つの異なる項目、すなわち、（１）エンティティ、（２）ユーザ、（３）エンティティユーザ（実際及び仮想）、及び（４）エンティティユーザアクセス（ビジネス機能及びデータの組合せ）のステータスに支配される。
ステータスの組合せは、任意のユーザが特定のデータに対して任意のエンティティのために何かを行うことができるか否かを制御する。これを行うために、ユーザは、アクティブでなければならず、エンティティもアクティブでなければならず、ユーザは、エンティティとアクティブに関連付けられるべきであり（エンティティユーザ）、また、ビジネス機能及びデータの組合せは、エンティティのユーザに対してアクティブでなければならない（エンティティユーザアクセス）。これらの項目のどの１つも、「アクティブ」以外のステータスを有することができ、これは、作業が失敗する原因となる。

ステータスは、様々な方法で管理される。スポンサー組織の「ＩＴ」セキュリティ担当者は、４つの項目の全てのステータスを管理することができる。外部「アクセス管理者」は、これらの項目のうちの２つ、すなわち、エンティティユーザ及びエンティティユーザアクセスを管理することができる。全ては、一定期間は非アクティブ、その後に再度アクティブになることができる。１つの項目、すなわち、エンティティユーザアクセスは、先に論じたアクセス権処理の割当てを通じていつでも簡単にオンオフすることができる。他の３つの項目、すなわち、エンティティ、ユーザ、及びエンティティユーザのオンオフには複雑性が伴うので、オフにすることなく一時的にこれらの３つの項目を非アクティブにすることができる明示的な方法がある。エンティティ、ユーザ、及びエンティティユーザを非アクティブにするには、計画された「保留期間」を予め設定することができることが含まれる。

また、セキュリティ保護ログオンアプリケーションが「委任」を提供するためには、仮想エンティティユーザについて「処理ステータス」を判断するための論理（以下の「ステータスタイプ」の説明を参照）は、複数のエンティティ、すなわち、ユーザの管理組織及びユーザが代わりに作業しているエンティティのステータスを検討する段階が含まれるべきである。
全ての状況において、日付により、様々なステータスが有効である期間が定義される。
計画された将来のステータス変更を確立し、ステータスを変更し、又は、計画された将来のステータス変更を変更する全てのアクションについて記録が保持されるべきである。

２．ステータスタイプ
状況及び位置により、ステータスを表す方法が４通りある。
日付ステータス：これは、項目に付随するステータス日付により判断される項目のステータスを意味する。
表示ステータス：これは、画面に表示される項目のステータスであり、常に現在の日付及び時間に関連するものである。エンティティユーザについては、このステータスは、実際のエンティティユーザのみに適用される。
「処理ステータス」：これは、実際及び仮想の両方のエンティティユーザに適用される。これは、エンティティユーザが何らかの機能を実行することを許可されているか否かを示す。
「選択ステータス」：これは、実際のエンティティユーザのみに適用される。これは、アクセス管理者及び／又は「社内セキュリティ」により使用される選択リストに対してどのエンティティユーザを表示すべきかを判断するために使用される。

３．エンティティユーザアクセスステータス
任意の「Ｅｎｔｉｔｙ＿Ｕｓｅｒ＿Ａｃｃｅｓｓ」行（エンティティ、ユーザ、機能、及びデータの組合せ）は、ユーザ、「Ａｄｍｉｎ」エンティティ、「ＢｅｈａｌｆＯｆ」エンティティ（「Ａｄｍｉｎ」エンティティと異なる場合）、及び実際のエンティティユーザ（「エンティティユーザアクセス」が実際又は仮想エンティティユーザに対するか否かにかかわらず実際のエンティティユーザ）が全てアクティブである限り、かつ、委任が１つのレベルを超えて拡張されない限り（すなわち、「委任先」組織が委任された作業を次に別の組織に委任しない限り）、アクティブである。委任を１つのレベルを超えて拡張することができる時（すなわち、「委任先」組織が別の組織に委任された作業を委任した時）、任意の「Ｅｎｔｉｔｙ＿Ｕｓｅｒ＿Ａｃｃｅｓｓ」行は、「ＢｅｈａｌｆＯｆ」エンティティと「Ａｄｍｉｎ」エンティティとの間の委任チェーン内の全てのエンティティが上述の全ての判断基準に加えてアクティブである限りアクティブであることになる。

４．業務規則
ａ）実際エンティティユーザのステータス
「実際エンティティユーザ」のステータス、すなわち、「エンティティユーザ表示ステータス」、「処理ステータス」、及び「選択ステータス」は、「エンティティユーザ日付ステータス」ばかりでなく、「エンティティ日付ステータス」及び「ユーザ日付ステータス」にも依存する。この依存性は、付録Ａに示す「エンティティユーザステータス派生物」マトリックスに反映されている。
一般に、ステータスの相互作用に影響を与える規則は、以下の通りである。
１．「エンティティユーザ表示ステータス」、「終了日付」、及び「取消し時間」（存在する場合）は、エンティティ又はユーザのいずれかに発生している可能性がある全ての他の事柄よりも優先される。これは、「アクセス管理者」又は「社内セキュリティ」からの明示的な命令が、「終了日付」及び「取消し時間」により反映される時、他のイベントのいずれも取り消される場合に支配することになるようにするためである。
２．「エンティティユーザ処理ステータス」は、「エンティティ日付ステータス」が「アクティブ」であり、「ユーザ日付ステータス」が「アクティブ」であり、「エンティティユーザ日付ステータス」が「アクティブ」ある限り、「アクティブ」であることになる。そうでなければ、それは「非アクティブ」である。
３．「アクセス管理者」（ＡＡ）の「エンティティユーザ選択ステータス」は、ユーザが保留されるか又は取り消されておらず、かつ、エンティティが依然としてアクティブである限り、「アクティブ」であることになる。ステータスという観点から、ユーザは、「エンティティユーザ表示ステータス」が「登録済み」、「アクティブ」、又は「一時非アクティブ」の時、エンティティに対する現在の選択リスト上に現れる。「エンティティユーザ表示ステータス」が「取り消された」時、ユーザは、「取消し」選択リスト上に表示される。

ｂ）仮想エンティティユーザ処理ステータス
委任が１つのレベルを超えて拡張されていない限り（すなわち、「委任先」組織が委任された作業を次に別の組織に委任しない限り）、仮想「エンティティユーザ処理ステータス」は、この仮想「エンティティユーザ」、「ユーザ日付ステータス」、「Ａｄｍｉｎエンティティ」の「日付ステータス」、及び「ＢｅｈａｌｆＯｆエンティティ」の「日付ステータス」に対応する実際の「エンティティユーザ」の「日付ステータス」に依存する。委任が１つのレベルを超えて拡張された場合（すなわち、「委任先」組織が委任された作業を別の組織に委任することができる場合）、「ＢｅｈａｌｆＯＦ」エンティティと「Ａｄｍｉｎ」エンティティとの間の委任チェーン内の全てのエンティティの「日付ステータス」も同じく検査する必要があることになる。これらの依存性は、付録Ｂに示す「仮想エンティティユーザステータス派生物」マトリックスの「仮想エンティティユーザステータス派生物」に反映されている。

一般に、ステータスの相互作用に影響を与える規則は、以下の通りである。
１．仮想エンティティユーザに対応する実際のエンティティユーザの処理ステータスが「非アクティブ」である場合、仮想エンティティユーザの処理ステータスは「非アクティブ」である。基本的に、これは、このユーザを使用する会社がそのユーザを保留するか又は取り消した場合、いかなる委任されたアクセスも「非アクティブ」であることを意味する。
２．委任に関与するエンティティのいずれかが保留されたか又は取り消された場合、処理ステータスは「非アクティブ」である。

ｃ）ステータスに影響を与えるアクション及び活動
（１）申請の承認
スポンサー組織の「ＩＴ」セキュリティ担当者は、確認処理の通過後に申請を承認することができる。また、セキュリティ保護ログオンアプリケーションは、予め承認された申請を信用のあるソースから受け取ることができる。いずれの場合も、これにより、結果的にエンティティが確立され、「ＰＡＡ」のユーザアカウントが、それがまだ確立されていない場合は確立され、エンティティと「ＰＡＡ」の間の関係（「エンティティユーザ」記録が作成される）が確立される。これにより、登録されたアクティブなステータス記録が、エンティティ、まだ確立されていない場合はユーザ、及びエンティティユーザに対して設定されることになる。

（２）自動ポスト処理
申請処理を通過しなくても、信用あるソースがエンティティ、「ＰＡＡ」、及びエンティティと「ＰＡＡ」の関係を追加することができる処理がある。上述と同じく、これにより、登録されたアクティブなステータス記録が、エンティティ、まだ確立されていない場合はユーザ、及びエンティティユーザについて設定されることになる。
（３）ユーザの登録
エンティティに対するアクセス管理者又は「社内セキュリティ」は、そのエンティティに対してユーザを登録することができる。これは、アクセス管理者用の「ユーザ登録」機能により達成される。スポンサー組織の「社内セキュリティ」担当者の場合、これは、２つの場所のいずれかにおいて行うことができる。１番目は、「このエンティティの管理者の関係を変更／更新する」ページ上の「新規関係の追加」機能によるものであり、２番目は、社内サイト上のいくつかの場所で表示される「管理者の追加」機能によるものである。

一般に、ユーザの登録に影響を与える規則は、以下の通りである。
１．登録を行う時、「有効日付及び時間」を与えるべきである。「現在」は、容認可能なオプションであり、これは、ソフトウエアにより適切な日付及び時間として解釈されるべきである。「有効日付及び時間」は、「現在」又は将来でなければならない。
２．「終了日付及び時間」は、オプションである。「終了日付」が与えられた場合、取消し記録がその日付に対して作成されることになる。「終了日付及び時間」は、「有効日付及び時間」よりも大きくなければならない。
３．１つのエンティティにユーザを登録し、そのユーザ用に確立されたアカウントを異なるエンティティのコンテキストで使用することが可能である。これが「単一サインオン」を達成する方法である。それは、登録時に適切な情報を提供することにより行うことができる。しかし、ユーザが「社内セキュリティ」により保留されたか又は取り消された場合、又は、ユーザが以前にそのエンティティで登録されており、ステータスが取り消されていない場合は、既存のユーザアカウントを流用することは許可されない。
ユーザの登録の１つの結果として、ユーザアカウントが存在するようになり、ユーザがまだ確立されていない場合は、ユーザのための登録されたアクティブステータス記録が作成される。それはまた、エンティティユーザに対する登録されたアクティブステータス記録の設定をもたらす。

（４）ユーザの復活
「ユーザの復活」は、「ユーザの登録」に相当するものであり、ユーザがエンティティに以前に登録されていた場合は既存のユーザアカウントが使用され、ステータスが「取り消される」。これにより、エンティティユーザについて、登録されたアクティブステータス記録が設定されることになる。
（５）「有効日付及び時間」の調節
エンティティに対する「アクセス管理者」又はスポンサー組織の「社内セキュリティ」は、エンティティのユーザに対するいかなる将来の「有効日付及び時間」も調節することができる。これは、「アクション選択」ページ上でエンティティユーザのための「有効日付及び時間」を選択することにより達成される。
一般に、「有効日付及び時間」の調節に影響を与える規則は、以下の通りである。
１．「有効日付及び時間」は、「現在」又は将来でなければならない。それが「現在」である場合、ソフトウエアは、それを適切な時間として解釈すべきである。
２．「有効日付及び時間」は、「終了日付」が存在する場合は、「終了日付及び時間」よりも以前でなければならない。
３．「有効日付及び時間」は、全ての「保留日付及び時間」よりも以前でなければならない。このステータスが編集時に検出された場合、ユーザは、警告を受けかつ自分で対処法を選択することなる。発行なしとなるように日付を変更するか、又は、発行なしになるまで既存の「保留期間」を取り消す、という２つの対処法がある。既存「保留期間」の取消しが解決策として選択された場合、その記録は無効と標記され、従って、有効日付が仮に再変更された場合でも、セキュリティ保護ログオンアプリケーションは、これらの無効記録についても同じく尋ねることができる。
有効日付及び時間が調節される結果として、新しい有効日付及び時間が記録され、その変更の監査記録が作成される。

（６）エンティティ、ユーザ、又はエンティティユーザの保留
エンティティのアクセス管理者又はスポンサー組織の「ＩＴ」セキュリティ担当者は、エンティティのユーザを一時的に保留することができる。「ＩＴ」セキュリティ担当者のみが、エンティティ又はユーザを一時的に保留することができる。これは、「保留期間」を定義することにより達成される。「保留期間」は、「アクション選択」ページから管理される。「保留期間」を設定する結果として、開始日付及び終了日付の記録が作成される。「保留期間」に付随する日付の任意の変更の結果として、新しい日付の記録が作成され、古い日付に対する変更内容の監査記録が作成される。図１５Ａ及び図１５Ｂは、ユーザを一時的に保留する段階を示す。

一般に、エンティティ、ユーザ、又はエンティティユーザの保留に影響を与える規則は、以下の通りである。
１．「保留期間」は、エンティティ、ユーザ、又はエンティティユーザの「有効日付」後に開始すべきである。
２．「保留期間」は、取消「日付及び時間」が存在する場合は、その前に終了すべきである。
３．各「保留期間」については、「保留日付及び時間」が提供されるべきである。「現在」は、他の編集を満足する限り、容認可能なオプションである。「現在」は、ソフトウエアにより適切な時間として解釈されるべきである。
４．各「保留期間」について、「再開日付及び時間」はオプションであり、すなわち、それは、全ての他の編集を満足する限り無期限とすることができる。それが与えられる場合は、「保留日付及び時間」以降のものでなければならない。「再開日付及び時間」が入力されない場合、デフォルト「再開日付及び時間」が使用される。これは、１２／３０／９９９９の最大日付か、又は、取消し「日付及び時間」が存在する場合は取消し「日付及び時間」のいずれかであることになる。アクティブ「保留期間」について日付を調節した時、「現在」は、他の編集を満足する場合は「再開日付及び時間」に対する満足することができるオプションである。

５．複数の「保留期間」を指定することができる。これらのうちの最後の「保留期間」のみを無制限とすることができる。
６．「保留期間」間の重複はあり得ない。編集時に重複が検出された時、ユーザは、警告を受け、自分で対処法を選択することになる。重複がないように新しい「保留期間」の日付を変更する、既存の「保留期間」の日付を変更する、又は、重複がなくなるまで既存の「保留期間」を取り消すという対処法がある。既存「保留期間」の取消しが解決策として選択された場合、その記録は無効と標記され、従って、仮に日付が再変更された場合でも、セキュリティ保護ログオンアプリケーションは、これらの無効記録について同じく尋ねることができる。
７．既存「保留期間」の「保留日付及び時間」は、以下である限り変更することができる。
ａ）既存「保留日付及び時間」は、将来のものである。
ｂ）新しい「保留日付及び時間」は、将来のものである。
ｃ）新しい「保留日付及び時間」は、「再開日付及び時間」よりも以前のものである。
ｄ）新しい「保留日付及び時間」は、「有効日付及び時間」以降のものである。
ｅ）別の「保留期間」との重複が作成されない。

８．既存「保留期間」の「再開日付及び時間」は、以下である限り変更することができる。
ａ）既存の「再開日付及び時間」は、将来のものである。
ｂ）新しい「再開日付及び時間」は、将来のものである。
ｃ）新しい「再開日付及び時間」は、「保留日付及び時間」以降のものである。
ｄ）新しい「再開日付及び時間」は、「取消日付及び時間」が存在する場合は、それに等しいか又はそれ以下である。
ｅ）別の「保留期間」との重複が作成されない。
９．「保留期間」は、エンティティユーザアクセス、及び、このエンティティユーザに付随する仮想エンティティユーザまでカスケードしない。その結果、実際のアクセス特権を判断するためには、ユーザ、全てのエンティティ、及び実際のエンティティユーザレベルでステータスを確認すべきである。

１０．「保留期間」は、「保留日付及び時間」及び「再開日付及び時間」の両方が将来のものである限り、取り消すことができる。
１１．ユーザ又はエンティティは、スポンサー組織の「ＩＴ」セキュリティ担当者により保留されるが、エンティティユーザに関する将来の保留期間は、依然として確立することができる。これらは、許可されることになり、それによってユーザ又はエンティティの保留が解除された場合にそれらを有効にすることができる。「アクセス管理者」又は「ＩＴ」セキュリティ担当者は、ユーザが保留されている間にこのような期間を設定することができる。「アクセス管理者」は、エンティティが「保留されている」間はエンティティについて何も行うことができなくなるので、「ＩＴ」セキュリティ担当者のみが、エンティティが「保留されている」間にこのような期間を設定することができる。
１２．ステータスを取り囲む全てのアクションの履歴は、「アクセス管理者」、「社内セキュリティ」、及び監査人に表示されることになる。

（７）エンティティ、ユーザ、又はエンティティユーザの取消し
エンティティのアクセス管理者又はスポンサー組織の「ＩＴ」セキュリティ担当者は、エンティティに対するユーザを取り消すことができる。「ＩＴ」セキュリティ担当者は、エンティティ又はユーザを取り消すことができる。これは、外部サイトにおいて、「アクション選択」画面上の「ユーザ取消し」ボタンをクリックすることにより、又は、「アクション追加」ボタンを選択し、理由コードとして「取消し開始」を選択し、そのアクションを開始するために日付及び時間を選択することにより達成される。どちらの方法を選択するかを問わず、取消しの開始日付を入力する機会がもたらされる。取り消す結果として、取消日付の記録が作成される。取消日付の任意の変更の結果として、新しい日付（新しい日付を作成した場合）の記録が行われ、古い日付に対する変更の監査記録が作成される。

一般的に、エンティティ、ユーザ、又はエンティティユーザの取消しに影響を与える規則は、以下の通りである。
１．取消日付は、将来のものとするか、又は、他の編集を満足する限り、「現在」とすることができる。
２．取消しは、ファイル上での他の全てのアクション日付よりも大きくなければならない。他の全てのアクション日付よりも大きくない場合、ユーザは、警告を受け、自分で対処法を選択することになる。対処法は、編集を満足するように「保留期間」の日付を変更するか、編集を満足するように既存「保留期間」を取り消すか（既存「保留期間」取消しが解決策として選択された場合、記録は無効と標記され、それによって有効日付が再度変更されることがあった場合でも、セキュリティ保護ログオンアプリケーションは、これらの無効記録について同じく尋ねることができる）、又は、編集を満足するようにアクションを変更することである。
３．ただ１つの将来の取消日付のみが存在することができる。

（８）エンティティユーザアクセスステータス
「役割割当て」処理及び全てのその変形により、エンティティユーザに対するエンティティユーザアクセスステータスが制御される。通常、ビジネス機能及びその関連データがユーザに割り当てられた時、ビジネス機能／データ対は、直接の有効日付及び時間で設定される。通常、ビジネス機能／データ対がエンティティユーザから除去された時、それは、直接の「終了日付及び時間」でタグ付けされる。トランザクション受領者によるトランザクションを通じて割当てが行われた場合、将来の有効及び終了日付を確立することができる。
（９）記録の監査
計画された将来のステータス変更を確立し、ステータスを変更し、又は、計画された将来のステータス変更を変更する全てのアクションの記録は保管すべきである。

Ｆ．セキュリティ保護ログオンアプリケーション内の動的メニュー
動的メニューは、アクセスを制御する別の方法である。セキュリティ保護ログオンアプリケーション内の情報に基づいて、ユーザがアクセスを有するビジネス機能のみをそのユーザに表示するメニューを構築することができる。
Ｇ．セキュリティ保護ログオンアプリケーション内のセッション管理
セキュリティ保護ログオンアプリケーションは、それを通じてログオンするユーザに対してセッション管理を行う。これは、アクセスを制御する別の方法を提供する。ユーザがある期間全く活動を行わない場合、そのユーザのログオンが開始したセッションは期限切れとなる。

Ｈ．セキュリティ保護ログオンアプリケーション内のユーザアカウント
セキュリティ保護ログオンアプリケーションは、各ユーザがセキュリティ関連情報を明かすことなく使用することができる独自の公開名を有することを要求し、ユーザが複数のコンテキストに対して単一サインオンを有することを可能にし、セキュリティで保護された機能性及び情報へのアクセスを得るために各ユーザが様々な条件に同意する要件をサポートする。スポンサー組織のセキュリティ保護機能性及び情報へのアクセスを得るために、各ユーザは、「ＵｓｅｒＩＤ」、「ＡＫＡＮａｍｅ」、及び「ＰＩＮ／Ｐａｓｓｗｏｒｄ」を有するべきである。「ＵｓｅｒＩＤ」及び「ＰＩＮ／Ｐａｓｓｗｏｒｄ」は、ログオンするために使用され、従って、セキュリティ関連のものである。「ＡＫＡＮａｍｅ」は、公開ユーザＩＤ又はユーザの別名である。「ＡＫＡ」名は、ユーザＩＤと同様にユーザ独自のものである。それは、ログオンするのに使用することができるいかなる情報も漏らすことなくユーザを指す代替方法である。

セキュリティ保護ログオンアプリケーションは、そのユーザの「ＵｓｅｒＩＤ」及び「ＡＫＡＮａｍｅ」が独自のものであることを保証し、同時に、ユーザが同じ「ＵｓｅｒＩＤ」及び「ＡＫＡＮａｍｅ」を複数のコンテキストにおいて使用することを可能にする論理をサポートする。アプリケーション保存処理（内部及び外部の両方）及びユーザ保存処理（内部及び外部の両方）において、矛盾管理処理が利用される。
「ユーザＩＤ」及び「ＡＫＡ」名の矛盾管理処理を示す流れ図を図４に示す。
矛盾管理処理には、二重検査論理と「ユーザＩＤ」及び「ＡＫＡ名」矛盾管理処理という２つの部分がある。二重検査論理は、セキュリティ保護ログオンアプリケーションに追加されるユーザの「ユーザＩＤ」、「ＡＫＡ名」、姓、及び名前がこれらの判断基準の４つの全てに対して全くの符合を有して既に存在するかを見るために検査する。符合が見つかった場合、このユーザが既に存在しているように見えるので、これは二重であるかもしれないと説明する画面がユーザに呈示される。ユーザは、同意して別のユーザを作成しないか、又は、「いいえ、これは同じユーザではありません。」というオプションを有する。同意した場合、ユーザは、自分の「ＵｓｅｒＩＤ」及び「ＡＫＡＮａｍｅ」を新しいコンテキストにおいて流用していることになる。
ユーザが「いいえ」と言った場合、「ユーザＩＤ」及び「ＡＫＡ名」矛盾画面により、ユーザは、現在使用していない新しい「ユーザＩＤ」及び「ＡＫＡ名」を選択するように強制されることになる。

上述のようにユーザの「ユーザＩＤ」、「ＡＫＡ名」、姓、及び名前について符合が見つからなかった場合、「ユーザＩＤ」及び「ＡＫＡ名」矛盾管理処理が次に呼び出される。この処理は、既存の値と照らし合わせて「ユーザＩＤ」を検査するものであり、この処理が取られた場合、ユーザに代案が提案されるか、又は、ユーザに自分自身の別の選択肢を選択させることになる。ユーザが新しい「ユーザＩＤ」を選択した状態で、それもまた、既に使用されていないことを確実にするために検査される。新しい「ユーザＩＤ」が既に使用されている場合、ユーザが独自の「ユーザＩＤ」を選択するまで処理が繰り返される。この処理は、「ＡＫＡ名」についても繰り返される。

初めてユーザがログオンした時、セキュリティ保護機能性及び情報へのアクセスを有するための条件を検討して受理することをユーザに要請することができる。その後、これらの条件が変更になるか、又は新しい条件が追加された場合、変更後に初めてログオンした時に、ユーザに新しい条件を検討して受理することを要請することができる。個人が同意するであろう同意の一例は、図１３に示すようなウェブページを通じて呈示される守秘義務に関する同意である。

ＩＩＩ．未知のユーザのためのサポート
Ａ．登録処理
セキュリティ保護ログオンアプリケーションによりサポートされる複数の登録処理がある。人々であるエンティティは、スポンサー組織と直接的関係を有することが多く、従って、スポンサー組織に既知である。人々にとっては、スポンサー組織がその個人に関してそのバックエンドシステムに有する情報を利用する滑らかな処理を有することが可能である。
組織であるエンティティの場合、より複雑な登録処理が必要である。これは、主として３つの理由、すなわち、登録時に指名された個人又は人々がスポンサー組織には既知でないことが多いこと、その組織に対する極秘情報にセキュリティが付与されていること、及び、その組織のためのセキュリティ管理が組織に分配されていることから必要である。第１の理由は、スポンサー組織バックエンドシステムには、確認処理を支援するために使用することができる情報がないことを意味する。第２の理由は、登録時に指名された個人又は人々が、登録時に彼等に概説された役割に適切であることが重要であることを意味する。第３の理由は、セキュリティ管理者（主アクセス管理者）を登録時に指名しなければならず、また、組織を法的に拘束することができる個人（主制御権限）は、セキュリティの責任を受容し、特定の方法で行動することに同意する法的合意事項に署名すべきであることを意味する。申請時に「主アクセス管理者」として指名される個人は、スポンサー組織に既知ではない可能性があることから、その個人が「主アクセス管理者」に指名されるのに適切であることを確認するために何らかの処理が必要である。また、登録に署名する個人が適切に署名していることを確認するために何らかの処理が必要である。

組織エンティティに対する登録には、登録、確認、及び法的同意の取得という３つの段階が含まれる。第１段階である登録は、個人がその組織の代行として、スポンサー組織のセキュリティ保護ウェブセルフサービス機能及びデータへのアクセスを要請する処理である。それはまた、スポンサー組織が「主制御権限」になる個人、「主アクセス管理者」になる個人、及び組織に関する特定データを収集する処理である。登録及びデータ収集に使用されるアプリケーションは、ウェブベースのアプリケーションである。個人の組織及びその組織の主連絡先（主制御権限）に関する情報を取得するためのウェブベースの登録アプリケーションで使用される画面の例を図１０から図１２に示す。

第２の登録段階である確認は、登録アプリケーションから得られた情報の正しさを確認し、「主アクセス管理者」及び「主アクセス管理者」が付随する組織が、安全なウェブセルフサービス機能を使用する権利及び必要性を有するようなスポンサー組織との関係が存在することを確認する処理である。
第３の登録段階である法的合意の取得では、スポンサー組織、組織の代行としてアクセスを取得する任意の個人、及びその個人が付随する組織の間の相互関係に適用可能な特定の法的合意が、その個人及びその組織により署名又は合意される。組織に関しては、これは、登録が完了した時点に行うことができる。個人に関しては、これは、上述の節で参照したように初回ログオン時に行われる。

ＩＶ．セキュリティ管理の分配
セキュリティ管理機能性は、「外部エンティティ」における「ＰＡＡ」及び「ＡＡ」と「システムアプリケーション所有者」とに分配される。
Ａ．外部エンティティにおけるＰＡＡ及びＡＡのための機能
「外部エンティティ」における「ＰＡＡ」及び「ＡＡ」のための機能には、以下の項目が含まれる。
新規ユーザを登録する
ウェブアクセス権を割り当てる
ユーザステータスを管理する
ユーザ情報を維持する
組織情報を維持する
セキュリティ変更をモニタする
現在のセキュリティプロフィールを検討する
貴組織をセグメント化する
委任された作業を受理するように準備する
あなたに委任された作業を閲覧する
委任された作業を割り当てる
作業を別の組織に委任する
別の組織に委任された作業を変更する
作業を別の組織に委任することを止める

Ｂ．システムアプリケーション所有者のための機能
システムアプリケーション所有者が責任を有するビジネス機能とそれらのビジネス機能に固有のアクセス識別子とを管理するのにシステムアプリケーション所有者に対して利用可能な３つの機能が存在する。
１．機能へのアクセスを付与するシステムアプリケーション所有者
システムアプリケーション所有者は、その主アクセス管理者を通じて組織のビジネス機能を維持する。この処理は、システムアプリケーション所有者が、そのシステムアプリケーション所有者のためのビジネス機能のみを閲覧、追加、及び削除することができ、組織の他のユーザのいずれかではなく主アクセス管理者のための役割を維持することができるのみであるという点を除き、スポンサー組織「ＩＴ」セキュリティの維持機能と類似のものである。この維持管理は、一度に一組織で行われる。

２．システムアプリケーション所有者の識別子維持
システムアプリケーション所有者が組織の識別子を維持する処理は、システムアプリケーション所有者が、そのシステムアプリケーション所有者のためのアクセス識別子のみを編集、追加、及び削除することができる点を除き、スポンサー組織「ＩＴ」セキュリティのアクセス識別子維持と非常に類似のものである。システムアプリケーション所有者は、スポンサー組織「ＩＴ」セキュリティ担当者により維持されるアクセス識別子を見ることができる。それは、他のシステムアプリケーションの所有者により維持されるアクセス識別子を見ることはできない。この維持管理は、一度に一組織で行われる。

３．新しいビジネス機能を確立する
選択された組織の主アクセス管理者（ＰＡＡ）への新しいビジネス機能の分配を自動化する機能は、スポンサー組織「ＩＴ」セキュリティ担当者、又はシステムアプリケーション所有者が実行することができる。それがシステムアプリケーション所有者により実行された時にデータがシステムアプリケーション所有者により濾過される点を除き、両方のグループに対して画面は同じように見えるであろう。このビジネス機能の分配に関する組織の選択は、個々の組織によってではなく、広い範疇の組織により実行される。

Ｖ．複数の環境のためのサポート
Ａ．原点ポートの機能性
セキュリティ保護ログオンアプリケーションにおける重要な概念の１つは、原点ポートである。原点ポートの機能及び動的メニュー作成を用いることにより、ユーザがセキュリティ保護ログオンアプリケーションに入った時に通過した原点ポートに基づき、ビジネス機能アクセスを制御又は限定することができる。それが機能する方法の一例は、以下の通りである。ユーザは、「プロバイダ組織」の管理者である。ユーザは、「プロバイダ組織」のためにプロバイダ管理活動を行い（会員の適格性を検査して保険金請求を提出する）、また、「プロバイダ組織」のために雇用主特典管理を行う（新入社員を入会させ、保険料請求書を検討する）。この個人は、「プロバイダ組織」のために２つの帽子を効果的にかぶる。医局においては管理者の帽子をかぶり、このユーザは、医療提供者用のスポンサー組織の原点ポートを通じてセキュリティ保護ログオンアプリケーションに入る。ユーザが認証されてセキュリティ保護ログオンアプリケーションに入った状態で、ユーザには、その原点ポートにより形成されるような、内科医の組織のための管理者というコンテキストにおいて自分が有するビジネス機能（すなわち、患者の紹介、承認のような）のリストが呈示される。ここで、その同じ管理者は、医療提供者用のスポンサー組織の原点ポートから出て、再び入るが、今度は、同じ「ユーザＩＤ」及び「ＰＩＮ／Ｐａｓｓｗｏｒｄ」を使用して、雇用主用のスポンサー組織の原点ポートを通じて入る。この時には、雇用主グループが行うことができる事柄に関係するオプションのメニューがその管理者に呈示される。この「ＰＯ」を利用してログインした後に、オンライン請求書ルックアップ及び内科医ディレクトリの検討のようなような事柄が管理者に呈示されるであろう。

図２は、セキュリティ保護ログオンアプリケーションのユーザが、登録された原点ポートからセキュリティ保護ログオンアプリケーション内に設定されたビジネス機能にアクセスした時に従うことになる流れを示す流れ図である。
「ＰＯ」がセキュリティ保護ログオンアプリケーションリソースとリンクしてそれに対してアクセスを付与するためには、いくつかの事柄が発生すべきである。これらは、 (１)原点ポートからセキュリティ保護ログオンアプリケーションにアクセスする、（２）原点ポートの体裁及び感じをカスタム化する、（３）セキュリティ保護ログオンアプリケーションから出る、（４）ダウンロードに利用可能な「ＰＤＦ」及び他の文書を作る、（５）「ＰＯ」独自のログオンページを使用する、及び（６）「ＰＯ」のメニュー構造を定義するという６つの範疇にグループ分けすることができる。

１．原点ポートからのセキュリティ保護ログオンアプリケーションへのアクセス
セキュリティ保護ログオンアプリケーションへのアクセスは、セキュリティ保護ログオンアプリケーションを呼び出すか、又は他の方法で利用するために必要とされる要件及び処理として定義される。これを行うための２つの方法、つまり、フレームなしアクセス及びフレーム付きアクセスがある。ビジネス機能へのアクセスを制御することに加えて、セキュリティ保護ログオンアプリケーションによる複数の「ＰＯ」のためのサポートもまた、以下で説明するように「ＰＯ」がセキュリティ保護ログオンアプリケーションのいくつかの他の機能を制御することを考慮している。

ａ）フレーム付きアクセス
ユーザが「ＰＯ」からフレームを使用してセキュリティ保護ログオンアプリケーションにアクセスするためには、その「ＰＯ」は以下のことを行う。
１．上部フレームが上部で揃えられた少なくとも２フレームのページを定義する。下部フレームは、ページの残り部分を利用することができる。セキュリティ保護ログオンアプリケーションは、「ＰＯ」が２つよりも多いフレームを定義することを可能にするが、これは、セキュリティ保護ログオンアプリケーションの内容の望ましくないスクロール及びレイアウトをもたらす場合がある。
２．２フレームページからセキュリティ保護ログオンアプリケーションを呼び出す。
３．ユーザが上部フレームでセキュリティ保護ログオンアプリケーションを利用している間に、「ＰＯ」が表示を望むヘッダ／ロゴを含める。
４．セキュリティ保護ログオンアプリケーション管理チームに、「ＰＯ」がセキュリティ保護ログオンアプリケーションに使用して欲しいと思うスタイルシートを提出する（このスタイルシートは、セキュリティ保護ログオンアプリケーションがアクセスされた時に下部フレームにより使用される）。「ＰＯ」が特定のスタイルシートの使用を望まない場合、セキュリティ保護ログオンアプリケーション用のデフォルトスタイルシートが利用されることになる。スタイルシートは、セキュリティ保護ログオンアプリケーションにより供給されたテンプレートを使用して原点ポートにより作成される。

５．「ＰＯ」が利用したいと思うナビゲーション及び他のグラフィックを提出する。
６．「ＰＯ」が各画面上でユーザに提供することを欲するヘルプテキストを提出する。
７．ユーザがセキュリティ保護ログオンアプリケーションにより確保された原点ポートにログオンした時、「ＰＯ」に割り当てられた原点ポートキーを渡す。原点ポートキーは、「ＰＯ」が初回に登録された時にセキュリティ保護ログオンアプリケーション管理者により「ＰＯ」に割り当てられる。この「原点ポート」キーはまた、後述するようにセキュリティ保護ログオンアプリケーションへのフレームなしアクセスが利用された場合に使用することができる上部、左側、及び下部ナビゲーションバー、ナビゲーショングラフィック、ヘルプテキスト、及び他の全ての原点ポートに特異な内容のような他の「ＰＯ」特異項目を含むフォルダを参照するために使用される。フレーム付きアクセスに使用される全ての内容は、「ＰＯ」により割り当てられたフォルダに含まれており、同じ「ＰＯ」キーにより参照される。

ｂ）フレームなしアクセス
「ＰＯ」がフレームなしアクセスを利用することを望む場合、フレーム付きアクセスに関連して上述した行為を行うことに加えて、以下を行わなければならない。
１．セキュリティ保護ログオンアプリケーションにより含まれ、かつ、フレーム付きアクセスの場合と同じ位置でユーザに呈示される上部ナビゲーションファイルを準備する。上部ナビゲーションファイルは、フレーム付きアクセスで使用される上部フレームグラフィックの代替である。
２．オプションの左側及び下部ナビゲーションファイル、又は「ＰＯ」がユーザに表示したいと思う他の組込みファイルを準備する。
３．上部、左側、及び下部ナビゲーション組込みファイル（以後、それぞれ、「上部ナビゲーションファイル」、「左側ナビゲーションファイル」、及び「下部ナビゲーションファイル」）に、セキュリティ保護ログオンアプリケーションにより指定された名称を与える。
４．上部、左側、及び下部ナビゲーションファイルの表示サイズを供給する（すなわち、８００ｘ１００画素）。この情報は、フレームセット内で絶対的位置決め又は提示を必要とするいくつかの項目の配置を制御するために、セキュリティ保護ログオンアプリケーションに記録される。

２．原点ポートの体裁及び感じをカスタム化する
フレーム付き又はフレームなしアクセスを選択することに加えて、「ＰＯ」は、更に、ログオンページに続いてセキュリティ保護ログオンアプリケーションにより供給されるページの「体裁及び感じ」をカスタム化することができる。セキュリティ保護ログオンアプリケーションを通じて制御することができる特徴のいくつかは、以下のものである。
１．ページの上部に表示されるヘッダ／ロゴ。
２．左側及び下部ナビゲーションバー。
３．スタイルシートを通じてセキュリティ保護ログオンアプリケーションにより表示されるメニュー項目の体裁及び感じ。
４．ユーザがセキュリティ保護ログオンアプリケーションによってもたらされたビジネス機能を完了した時に戻される位置。セキュリティ保護ログオンアプリケーション内の「原点ポート」戻り「ＵＲＬ」の設定によりこれが為される。
５．ナビゲーションに使用されるボタン又は「ＧＩＦ」。
６．所要フィールド及び行方不明データを指定するために使用される「ＧＩＦ」。
７．セキュリティ保護ログオンアプリケーションにより提供された各外部画面上に呈示されるヘルプテキスト。
８．アクセスが付与された時にユーザに呈示されるメニュー項目。
９．セキュリティ保護ログオンアプリケーションの機能性を利用している間にユーザに呈示されるエラーメッセージの大部分のテキスト。

これらの機能が制御される方法は、一般的に従来のものである。「ＰＯ」が独自のナビゲーショングラフィックを利用することを選択した場合、原点ポートは、セキュリティ保護ログオンアプリケーションにそのナビゲーション用のファイルを供給しなければならず、また、セキュリティ保護ログオンアプリケーションにより指定された命名法の慣例を厳守すべきである。セキュリティ保護ログオンアプリケーションは、これらのファイルをそのサーバに記憶し、画像は、ユーザがセキュリティ保護ログオンアプリケーションの機能性をナビゲートする時にもたらされる。
セキュリティ保護ログオンアプリケーションはまた、各原点ポートが、セキュリティ保護ログオンアプリケーションにより供給された画面上に位置するヘルプボタンの１つをクリックした時に表示されるヘルプテキストを開発することを可能にする。ヘルプテキスト画面のサンプルを図３に示す。ヘルプファイルは、原点ポートがユーザに表示したいと思ういかなるヘルプテキストでも含むことができる。

上述の「ＰＯ」によるカスタム化に加えて、セキュリティ保護ログオンアプリケーションはまた、原点ポートが、セキュリティ保護ログオンアプリケーションにより呈示される画面の「体裁及び感じ」を制御するのに使用されるスタイルシートテンプレートをカスタム化することを可能にする。
サーバ側のエラーを処理するために、セキュリティ保護ログオンアプリケーションは、いくつかの状況においてユーザに呈示されるエラーメッセージをカスタム化する能力を原点ポートに与える。更に、原点ポートは、そのユーザがＯＫボタンをクリックすることによりエラーを認めた状態で、特定のページにユーザに導くことができる。セキュリティ保護ログオンアプリケーションがこれらの機能を達成する方法は、主として従来のものである。

これらの機能性をサポートするために、セキュリティ保護ログオンアプリケーションは、中央エラー処理ダイアログページに方向転換することによりサーバ側エラーを処理する。エラータイプは、エラーメッセージ表で定義され、それらは原点ポート特異であり、原点ポート０がデフォルト原点ポートである。エラーダイアログは、「原点ポートＩＤ」及び「エラーメッセージＩＤ」に基づいて、データベースからエラーメッセージを検索する。原点ポートに対してデフォルトメッセージが存在しない場合は、デフォルトメッセージが表示される。「エラー」ダイアログは、エラーメッセージと、クリックすると方向転換を実行するＯＫボタンとを常に表示する。ＯＫ方向転換「ＵＲＬ」は、エラーメッセージ表に記憶される。

３．セキュリティ保護ログオンアプリケーションから出る
「ＰＯ」は、ユーザが最終的にセキュリティ保護ログオンアプリケーションメニュー内に表示されるメニュー項目になることになるセキュリティ保護ログオンアプリケーション内のビジネス機能を設定することによりセキュリティ保護ログオンアプリケーションから出た時に、ユーザを特定の「ＵＲＬ」に戻すように要求することができる。このビジネス機能は、単に、「ＰＯ」がユーザに戻って欲しいと思う位置への「ＵＲＬ」／方向転換と、「ＰＯ」が戻して欲しいと思う静的データのストリング（データの戻りが必要な場合）とを含むウェブページに対する「ＵＲＬ」である。

４．ダウンロードに利用可能なＰＤＦ及び他の文書を作る
セキュリティ保護ログオンアプリケーションは、「ＰＯ」が、ユーザによるオンラインでのその後の呈示及びダウンロードのための文書を記憶することを可能にする。セキュリティ保護ログオンアプリケーションは、原点ポートのディレクトリ構造の下の「文書」というフォルダ内にこれらの文書を記憶することによりこの機能性をサポートする。セキュリティ保護ログオンアプリケーションは、その後、「ＡＳＰ」ページ上のリンクとしてディレクトリの内容を表示する。ユーザがリンクの１つを選択した時、ダウンロードセッションが、ユーザのコンピュータとセキュリティ保護ログオンアプリケーションとの間で自動的に開始される。この機能性を利用するために、原点ポートの文書は、システム内に更新されるべきである。これが行われた状態で、ビジネス機能は、ディレクトリの内容を表示することになるページへのリンクと共に原点ポートに対して登録される。

５．ＰＯ自身のログオンページを使用する
異なる「原点ポート」（ＰＯ）が認証処理を通じてその「体裁及び感じ」を持ちたいと思う場合があると認識して（認証処理は、「ＰＯ」のリソースへのアクセスを確保及び管理するためにセキュリティ保護ログオンアプリケーションを使用する全ての「ＰＯ」に共通である）、セキュリティ保護ログオンアプリケーションは、セキュリティ保護ログオンアプリケーションを通じて利用可能な標準的「ＡＳＰ」ログイン画面ページ／処理の代わりに、「ＰＯ」にそれ自体のログインページを作成する能力を与える。「ＰＯ」がこれを行うことを欲する場合、それは、「ユーザＩＤ」（ｕｓｅｉｄ）、「ＰＩＮ／パスワード」（ｔｘｔｐａｓｓｗｏｒｄ）、値「ＳＥＣＵＲＩＴＹＬＩＮＫ」（＿ｒｅｆｅｒｒｅｒ）、及びセキュリティ保護ログオンアプリケーションにより「ＰＯ」に割り当てられた「ＰＯ」数値（ｐｏｒｔｏｆｏｒｉｇｉｎ）を含むセキュリティ保護ログオンアプリケーション内のページ（以下、「セキュリティリンクページ」と呼ぶ）にフォームを提示すべきである。
「原点ポート」はまた、先に参照したページ内で「ユーザＩＤ」、「ＰＩＮ／パスワード」、及び指定された変数に対する「ＰＩＮ／パスワード」変更値の１を呈示することにより「ＰＩＮ／パスワード」変更処理を開始することができる。

６．ＰＯのメニュー構造を定義する
動的メニューは、各「原点ポート」に対するウェブアプリケーション内のカスタム化メニューを準備するためにセキュリティ保護ログオンアプリケーションから利用可能である。これは、「原点ポート」にセキュリティ保護ログオンアプリケーションがアクセスを制御する機能のためのナビゲーションを定義させることによりパーソナライゼーションのレベルを組み込む。セキュリティ保護ログオンアプリケーションは、ユーザアクセスに関するセキュリティ情報、及び、「原点ポート」により定義されたメニュー構造を記憶する。「原点ポート」は、メニューテンプレートのレベル、シーケンス、及び詳細を定義することができる。
セキュリティ保護ログオンアプリケーションはまた、「原点ポート」がそれ自体のメニューの体裁及び感じを定義するためのデータ記憶を提供する。これは、データベース内の所定フィールドとユーザ定義フィールドとの両方を通じて達成される。
「原点ポート」は、セキュリティ保護ログオンアプリケーション内で定義された情報を使用して独自のメニューを開発することができるか、又は、セキュリティ保護ログオンアプリケーションが提供するメニューを使用することができる。

ＶＩ．システム統括者インタフェース
Ａ．セキュリティ保護ログオンアプリケーションからのデータを得る
ビジネス機能が動的メニューから起動された時、セキュリティ保護ログオンアプリケーションは、ログオンされたユーザの「ＡＫＡ名」と起動されたメニュー項目の識別とを有するビジネス機能「ＵＲＬ」に起動ストリングを提供する。その後、ビジネス機能は、「ＡＫＡ名」及びメニュー情報を様々な方法を用いて使用し、独自の処理のためにセキュリティ保護ログオンアプリケーションから情報を取得する。
「ＶＢ６ ＣＯＭ ＤＬＬ」は、ビジネス機能がスポンサー組織のセキュリティ保護ログオンアプリケーションに付随するデータにアクセスすることを可能にする方法を含む単一クラス（ｂ＿ＳｙｓｔｅｍＡｐｐｌｉｃａｔｉｏｎ）を露出する。記憶及び露出されたデータには、「エンティティ」及び「ユーザ」セキュリティ情報、及び、セキュリティ保護ログオンアプリケーションデータストア内で定義された機能セットが含まれる。データは、「ＸＭＬ」フォーマットか、又は情報のフラットデータ表現による「ＡＤＯＤＢ」レコードセットとして戻される。非「ＣＯＭ」準拠システムを除いて同じ機能性を提供する「ＶＢ６ ＣＯＭ ＤＬＬ」の同等「Ｊａｖａ（登録商標）」バージョンも利用可能である。
システム開発担当者は、セキュリティ保護ログオンアプリケーション構成要素と信頼することができる接続を行うことができ、かつ、セキュリティ保護ログオンアプリケーション「データベース」へのアクセスを有するアカウントのコンテキストの下で構成要素を実行できる限り、「ＣＯＭ」インタフェースを通じて露出された方法を呼び出すことができる。

Ｂ．システムアプリケーションの登録
ビジネス機能がセキュリティ保護ログオンアプリケーション内でメニュー項目として呈示されるように、ビジネス機能に「サービスを提供する」アプリケーションは、セキュリティ保護ログオンアプリケーション内に登録されるべきである。システムアプリケーションの一例は、適格性、保険金請求、認証（これらの各々は、個々のビジネス機能である）などをもたらすシステムアプリケーションであるトリゼットの「ｅＰｌａｎ」アプリケーションである。
セキュリティ保護ログオンアプリケーションは、個々の「システムアプリケーション」に関する所要の情報を維持する。新しい「システムアプリケーション」をセキュリティ保護ログオンアプリケーションに追加するためには、「システムアプリケーション管理者」は、セキュリティ保護ログオンアプリケーション「管理者」に「システムアプリケーション略称」及び「システムアプリケーション説明」を提供すべきである。

Ｃ．ビジネス機能の登録
上述のように、セキュリティ保護ログオンアプリケーションは、スポンサー組織におけるセキュリティ保護リソースへのゲートウェイを提供する。新しい「ＰＯ」及び／又はシステムアプリケーションが追記され、それらは、セキュリティ保護ログオンアプリケーションを通じてユーザに提供したいと思う追加のビジネス機能を有することができる。このような新しいビジネス機能は、「ＰＯ」及び／又はシステムアプリケーションのプロジェクトチームからの代表者にセキュリティ保護ログオンアプリケーション管理者に連絡させ、そのビジネス機能に関する様々な説明的及び処理上の情報を提供させることにより登録又は実行することができる。

Ｄ．ビジネス機能及びビジネス機能セットの制限事項
ビジネス機能は、最初は１つのビジネス機能セット及び１つの原点ポートにのみ存在することができる。１つよりも多いビジネス機能セット又は１つよりも多い原点ポートにビジネス機能を存在させる必要性がある場合、そのビジネス機能は、それが使用される各場合について複製が作られるべきである（一度を超えて登録される）。
その一例は、スポンサー組織がプロバイダポータル及び会員ポータルの両方で利用するつもりである「保険金請求を閲覧する」というビジネス機能を作成することを欲する場合であろう。プロバイダポータルにおいて、事務員は、この機能を使用して患者の保険金請求を検討する。会員ポータルにおいては、会員は、この機能を利用して自分の個人的な保険金請求を検討するであろう。この例においては、ビジネス機能「保険金請求を閲覧する」は、２度登録する必要があると考えられる。両方のビジネス機能は、同じ説明を利用し、同じ起動「ＵＲＬ」を使用することができるが、各々は、それらのビジネス機能セットの関連性を通じて異なる原点ポートと関連付けられるであろう。

セキュリティ保護ログオンアプリケーションは、ビジネス機能が複数のビジネス機能セット又は複数の原点ポートにより共有することができないように設計されるが、ビジネス機能が１つよりも多いビジネス機能セット内に存在する必要性があり得る状況がある。このような状況の一例は、「職員」というセットが事務員について作成され、「管理」というセットがマネージャについて作成される場合である。両方のグループは、「ユーザ人口統計」のようなビジネス機能セットを利用することができるであろう。
このような構成に関する主な問題は、ユーザインタフェースエリアにある。図６は、ユーザ「ジョー・アルファ」が記されている「役割を割り当てる」メニューの例示的な画面を示す。一例として、ユーザ「ジョー・アルファ」に「職員」ビジネス機能セット内の機能の全てへのアクセスを付与するが、「管理」ビジネス機能セット内の機能へのアクセスは付与しないものとすると仮定する。セキュリティ保護ログオンアプリケーションが、「ユーザ人口統計」ビジネス機能が両方のセットにより共有されることを可能にする場合、ユーザ「ジョー・アルファ」に「職員」ビジネス機能セットへのアクセスが付与されるとすぐに、「ユーザ人口統計」は両方のセットに対して同じ機能であるから、ビジネス機能「ユーザ人口統計」はまた、「管理」セット内で調べられる時に表示されるであろう。

ユーザが恐らく行う反応は、「管理」ビジネス機能セットの「ユーザ人口統計」オプションを非選択にするか又は未検査にすることであると考えられる。ユーザがこれを行った場合、ユーザは、うっかり「ユーザ人口統計」ビジネス機能への「ジョー・アルファ」のアクセスを「職員」セットから同じく除外することになる。この結果は、ユーザが管理者の職員機能を除去し、その後に管理者にマネージャ機能を与え、両方のセットの共通機能が今度は職員セットで再び起動されたことが画面上で分った場合は、ユーザにとって特に紛らわしいであろう。
また、ビジネス機能が複数の原点ポートに亘って存在する必要があると考えられる状況がある。しかし、セキュリティ保護ログオンアプリケーションは、不要なアクセスが生じる場合があるために、ビジネス機能セットが１つよりも多い原点ポートで使用されることを可能にしない。例えば、「保険金請求を閲覧する」というビジネス機能が作成されたと仮定すると、これは、かなり一般的なビジネス機能であり、恐らくは、何らかの方法で多くのポータルで使用されることになる。

セキュリティ保護ログオンアプリケーションのアーキテクチャの下では、ビジネス機能がユーザに付与され、そのビジネス機能が複数のポータルで使用された場合、そのユーザがそのビジネス機能を含む全てのポータルへのアクセスを有することを防止する方法はない。換言すると、「保険金請求を閲覧する」へアクセスすることができる会員は、プロバイダポータルに対して有効であるアクティブビジネス機能「保険金請求を閲覧する」を有するので、プロバイダポータルにログインすると、セキュリティ保護プロバイダ機能にアクセスすることができるであろう。アクセス識別子であれば会員が自分のものではない保険金請求を閲覧することを防止するであろうが、会員は、アクセス識別子を必要しない場合がある他のセキュリティ保護内容（例えば、プロバイダマニュアル、規定書、他）にアクセスすることができる。

Ｅ．セキュリティ保護ログオンアプリケーション活動セッションの維持
ユーザがセキュリティ保護ログオンアプリケーションにログインした時、セッションが確立される。ユーザがセキュリティ保護ログオンアプリケーションにより供給された機能（例えば、組織情報を管理する）を実行しているか、又は、セキュリティ保護ログオンアプリケーションにより供給されたユーザメニューに戻る限り、セキュリティ保護ログオンアプリケーションは、セッションを現在のまま及び更新して維持する。しかし、ユーザがセキュリティ保護ログオンアプリケーションにより提供されないメニュー項目を起動すると、又は、「ＰＯ」がセキュリティ保護ログオンアプリケーションにより供給されないメニューを使用した場合、セキュリティ保護ログオンアプリケーションには、ユーザのセッションを更新する方法がなく、指定された何分かの経過の後に、ユーザのセッションは時間切れになることになる。ユーザがメニューに戻ろうとするか、又は、セキュリティ保護ログオンアプリケーションセッション管理を利用する機能のいずれかにアクセスしようとする場合、ユーザは、強制的に再ログインさせられることになる。トランザクションの一部である各ページは、活動セッションを維持するように試みるべきである。これは、セキュリティ保護ログオンアプリケーションが実行されているドメインと同じドメインか又は異なるドメインのどちらの下でトランザクションが実行されているかにより２つの方法のいずれかにより為される。
同じドメイン：「ｇｅｔＳｅｓｓｉｏｎ＿ＲＳ ＡＰＩ」を使用する。
異なるドメイン：アプリケーションのためにこれを行う「ＡＳＰ」ページに提示する。

Ｆ．ページレベルでのユーザアクセスの確認
セキュリティの追加レベルとして、セキュリティ保護ビジネス機能をもたらす各ページは、ページレベルのアクセス確認を実行する組込みファイル又は方法を組み入れることができる。この処理は、ユーザがアクセスしようとするビジネス機能への現在のアクセスをユーザが依然として有することを確認する最終検証を行うものである。これは、ユーザが「ＵＲＬ」を直接ブラウザに入力することによりビジネス機能にアクセスすることを防止する。

Ｇ．フォームへの提示によるトランザクション
セキュリティ保護ログオンアプリケーションは、指定されたフィールドをフォームに提示することによりいくつかの機能を実行する能力を原点ポートに与える。サポートされる機能は、エンティティ及びユーザを「自動作成する」こと、及び、アプリケーションを「自動作成する」ことである。提示発生元である「ＵＲＬ」は、最初にセキュリティ保護ログオンアプリケーション内に登録されるべきである。セキュリティ上の理由から、この方法はまた、セキュリティ保護ログオンアプリケーション内の特定ページが示されることを要求する。

両方の機能に対して、提示に加えて、原点ポートはまた、ユーザが欲する目標とする「ユーザＩＤ」、「ＡＫＡ名」、及び「ＰＩＮ／パスワード」を捕捉するための画面を実施すべきである。有用性の理由から、提示は、この選択画面から始まることが好ましいが、必ずしもそうすべきというわけではない。これは、仮にユーザが選択した「ユーザＩＤ」又は「ＡＫＡ名」が既にセキュリティ保護ログオンアプリケーションで使用されている場合に、セキュリティ保護ログオンアプリケーションによる「ユーザＩＤ」及び「ＡＫＡ名」矛盾画面の呈示を次の段階として準備することになる。
原点ポートにエンティティ及びユーザを「自動作成する」能力を与えるために使用されるフォーム提示の例を図５に示す。

Ｈ．セキュリティ保護ログオンアプリケーションにおけるデータのプログラム的更新
いくつかの場合においては、システムアプリケーション又は処理がセキュリティ保護ログオンアプリケーション内のデータを更新することが必要又は望ましい場合がある。この機能性を達成するために、セキュリティ保護ログオンアプリケーションは、汎用「ＸＭＬ」トランザクションプロセッサを含む。トランザクションアクセスハンドラへのアクセスは、「ＳｅｅＬｉｎｋＳｙｓＡｐｐ．ｄｌｌ」を通じて利用可能である。
トランザクションハンドラを利用するために、システムアプリケーション所有者は、セキュリティ保護ログオンアプリケーション内にシステムアプリケーションを登録し、そのトランザクションに対する業務及びセキュリティ規則を実行するための処理を構築すべきである。

セキュリティ保護ログオンアプリケーションの本実施形態は、以下のトランザクションタイプに対するサポートを含むが、他のトランザクションを追加することができると想定されている。
１．「ＰＡＡ」機能データアクセストランザクション
２．アクセス識別子トランザクション
３．アクセス識別子グループトランザクション
４．ユーザアクセストランザクション
５．エンティティユーザ属性トランザクション
６．ユーザ属性トランザクション
ユーザのアクセスをプログラム的に更新するための例示的な「ＸＭＬ」トランザクションを図７に示す。

Ｉ．セキュリティ保護ログオンアプリケーションにおけるセキュリティプロフィール変更の通知
セキュリティ保護ログオンアプリケーションは、セキュリティプロフィールの変更の当事者への通知を準備する。通知は、「ＸＭＬ」トランザクションを通じて行われる。セキュリティ保護ログオンアプリケーションの本実施形態は、以下のトランザクションタイプのサポートを含むが、他のトランザクションを追加することができると想定されている。
１．申請が入力ステータスに到達中
２．申請を承認中
３．エンティティ情報を変更中
４．エンティティアクセス識別子を変更中
５．「ＰＡＡ」情報を変更中
６．「ＰＡＡ」ビジネス機能を変更中
７．ユーザ情報を変更中
８．ユーザビジネス機能を変更中
９．制御権限情報を変更完了

ＶＩＩ．他のシステム情報
Ａ．セキュリティ保護ログオンアプリケーション内部画面
「ＡＳＰ」画面は、アクセスを管理し、セキュリティ保護ログオンアプリケーションを内部的に管理するために従来の方法で使用される。この画面は、適正なアクセス権を有するスポンサー組織の同僚に対してのみ利用可能である。
Ｂ．セキュリティ保護ログオンアプリケーションのデータオブジェクト
データオブジェクトは、データアクセスを提供するためにビジネスオブジェクトにより使用される。データオブジェクトは、ウェブアプリケーションから直接アクセスすることはできない。データオブジェクトは、次に、「ｕ＿Ｕｔｉｌ」オブジェクトを使用してデータベース接続性を提供し、データベースに対する実際の指令を実行する。
Ｃ．セキュリティ保護ログオンアプリケーションのユーティリティオブジェクト
ユーティリティオブジェクトは、データオブジェクトがデータベースに接続し、データベースに対する指令を実行するのに使用する方法を提供するために使用される。

ＶＩＩＩ．データモデル
セキュリティ保護ログオンアプリケーションは、以下の「ＭＳ ＳＱＬサーバ」表によりサポートされる。
ＡＣＣＥＳＳ＿ＡＰＰＬＩＣＡＴＩＯＮ
ＡＣＣＥＳＳ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＡＤＤＲＥＳＳ
ＡＣＣＥＳＳ＿ＧＲＯＵＰ
ＡＣＣＥＳＳ＿ＧＲＯＵＰ＿ＩＤ＿ＡＳＳＯＣ
ＡＣＣＥＳＳ＿ＧＲＯＵＰ＿ＩＤ＿ＡＳＳＯＣ＿ＬＯＧ
ＡＣＣＥＳＳ＿ＧＲＯＵＰ＿ＬＯＧ
ＡＣＣＥＳＳ＿ＩＮＤＥＮＴＩＦＩＥＲ
ＡＣＣＥＳＳ＿ＩＮＤＥＮＴＩＦＩＥＲ＿ＬＯＧ
ＡＣＣＥＳＳ＿ＭＯＤＵＬＥ＿ＳＥＱＵＥＮＣＥ
ＡＧＲＥＥＭＥＮＴＳ
ＡＬＬＯＷＥＤ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＴＡＴＵＳ＿ＴＯ＿ＲＥＡＳＯＮ＿ＡＳＳＯＣＩＡＴＩＯＮ
ＡＬＬＯＷＥＤ＿ＭＩＬＥＳＴＯＮＥＳ＿ＡＮＤ＿ＳＴＡＴＥ＿ＴＲＡＮＳＩＴＩＯＮＳ
ＡＰＰＬ＿ＡＣＣＥＳＳ＿ＩＤＥＮＴＩＦＩＥＲ
ＡＰＰＬＩＣＡＴＩＯＮ＿ＭＯＤＵＬＥ
ＡＰＰＬＩＣＡＴＩＯＮ＿ＰＯＲＴ＿ＯＦ＿ＯＲＩＧＩＮ＿ＥＮＴＩＴＹ＿ＴＹＰＥ＿ＡＣＣＥＳＳ＿ＩＤ＿ＴＹＰＥ＿ＡＳＳＯＣＩＡＴＩＯＮ
ＡＰＰＬＩＣＡＴＩＯＮ＿ＰＲＯＣＥＳＳＩＮＧ＿ＴＹＰＥ
ＡＰＰＬＩＣＡＴＩＯＮ＿ＲＥＰＯＲＴＩＮＧ＿ＴＡＢＬＥ
ＡＰＰＬＩＣＡＴＩＯＮ＿ＲＯＵＴＩＮＧ＿ＣＯＮＴＲＯＬ
ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＴＡＴＵＳ
ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＴＡＴＵＳ＿ＨＩＳＴＯＲＹ
ＡＰＰＬＩＣＡＴＩＯＮ＿ＴＹＰＥ＿ＲＥＰＯＲＴＩＮＧ
ＡＰＰＬＩＣＡＴＩＯＮ＿ＶＩＥＷ＿ＣＯＮＴＲＯＬ
ＢＦ＿ＡＬＬＯＷＥＤ＿ＢＹＣＯＶＥＲＡＧＥ
ＢＵＳ＿ＦＵＮＣ＿ＩＤ＿ＴＹＰＥ＿ＡＳＳＯＣ
ＢＵＳＩＮＥＳＳ＿ＦＵＮＣＴＩＯＮ
ＢＵＳＩＮＥＳＳ＿ＦＵＮＣＴＩＯＮ＿ＡＳＳＯＣ
ＢＵＳＩＮＥＳＳ＿ＦＵＮＣＴＩＯＮ＿ＳＥＴ
ＣＯＮＴＲＯＬＬＬＩＮＧ＿ＡＵＴＨＯＲＩＴＹ
ＣＯＮＴＲＯＬＬＬＩＮＧ＿ＡＵＴＨＯＲＩＴＹ＿ＨＩＳＴ
ＣＯＶＥＲＡＧＥ＿ＱＵＡＬＦＩＥＲＳ
ＣＯＶＥＲＡＧＥＳ
ＤＥＬＥＧＡＴＩＯＮ
ＤＥＬＥＧＡＴＩＯＮ＿ＡＵＴＨＯＲＩＺＡＴＩＯＮ
ＤＥＭＯ＿ＩＤＳ
ＤＹＮＡＭＩＣ＿ＬＩＮＫ
ＤＹＮＡＭＩＣ＿ＬＩＮＫ＿ＴＹＰＥ
ＥＭＡＩＬ＿ＡＤＤＲＥＳＳ
ＥＮＴＩＴＹ＿ＴＹＰＥ＿ＥＮＴＩＴＹ＿ＴＹＰＥ＿ＡＳＳＯＣ
ＥＮＴＩＴＹ＿ＴＹＰＥ＿ＦＵＮＣＴＩＯＮ
ＥＮＴＩＴＹ＿ＵＳＥＲ
ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＡＣＣＥＳＳ
ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＡＣＣＥＳＳ＿ＬＯＧ
ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＡＴＴＲＩＢＵＴＥＳ
ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＬＯＧ
ＥＲＲＯＲ＿ＥＭＡＩＬ＿ＡＳＳＯＣ
ＥＲＲＯＲ＿ＫＥＹＷＯＲＤ
ＥＲＲＯＲ＿ＫＥＹＷＯＲＤ＿ＡＳＳＯＣ
ＥＲＲＯＲ＿ＭＳＧ
ＥＲＲＯＲ＿ＲＥＦＥＲＥＮＣＥ
ＥＵ＿ＡＴＴＲＩＢＵＴＥ＿ＨＩＳＴ
ＥＵＡ＿ＤＥＬＥＧＡＴＩＯＮ＿ＡＳＳＯＣ
ＥＸＣＥＰＴＩＯＮ＿ＰＲＯＦＩＬＥ
ＥＸＣＥＰＴＩＯＮ＿ＰＲＯＦＩＬＥ＿ＬＯＧ
ＥＸＣＥＰＴＩＯＮ＿ＳＥＴ
ＥＸＣＥＰＴＩＯＮ＿ＳＥＴ＿ＬＯＧ
ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ
ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ＿ＡＤＤＲＥＳＳ
ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ＿ＡＤＤＲＥＳＳ＿ＨＩＳＴ
ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ＿ＡＴＴＲＩＢＵＴＥＳ
ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ＿ＨＩＳＴ
ＦＩＮＡＬ＿ＤＩＳＰＯＳＩＴＩＯＮ＿ＲＥＰＯＲＴＩＮＧ
ＨＥＬＰ＿ＧＲＯＵＰ
ＨＥＬＰ＿ＧＲＯＵＰ＿ＯＲＩＧＩＮ＿ＡＳＳＯＣ
ＨＥＬＰ＿ＧＲＯＵＰ＿ＯＲＩＧＩＮ＿ＢＵＳ＿ＦＵＮＣ＿ＡＳＳＯＣ
ＨＥＬＰ＿ＧＲＯＵＰ＿ＴＯＰＩＣ＿ＡＳＳＯＣ
ＨＥＬＰ＿ＳＥＣＴＩＯＮ
ＨＥＬＰ＿ＴＯＰＩＣ
ＩＭＭＵＴＡＢＬＥ＿ＢＵＳＩＮＥＳＳ＿ＦＵＮＣＴＩＯＮＳ
ＩＮＣＯＭＰＬＥＴＥ＿ＤＢ２＿ＵＰＤＡＴＥＳ
ＬＯＧ＿ＤＥＴＡＩＬ
ＬＯＧ＿ＲＯＬＥ
ＬＯＧ＿ＳＵＭＭＡＲＹ
ＬＯＯＫＵＰ＿ＣＯＤＥ＿ＧＲＯＵＰＳ
ＬＯＯＫＵＰ＿ＣＯＤＥＳ
ＭＥＭＢＥＲ＿ＸＭＬ＿ＨＩＳＴ
ＭＥＮＵ＿ＴＥＭＰＬＡＴＥ
ＮＯＴＩＦＩＣＡＴＩＯＮ
ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＣＯＮＦＩＲＭＡＴＩＯＮＳ
ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＨＩＳＴ
ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＭＳＧ＿ＣＲＥＡＴＩＯＮ＿ＦＡＩＬＥＤ
ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＰＡＹＯＲ＿ＬＩＳＴ
ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＰＡＹＯＲ＿ＭＳＧ＿Ｑ
ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＰＡＹＯＲ＿ＭＳＧ＿ＴＹＰＥＳ
ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＰＯＳＴ＿ＦＡＩＬＵＲＥＳ
ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＴＲＡＮＳＡＣＴＩＯＮ
ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＨＩＳＴ
ＯＲＩＧＩＮ＿ＬＯＯＫＵＰ＿ＣＯＤＥ＿ＯＶＥＲＲＩＤＥＳ
ＰＡＳＳＷＯＲＤ＿ＣＨＡＮＧＥ＿ＨＩＳＴＯＲＹ
ＰＯＲＴ＿ＯＦ＿ＯＲＩＧＩＮ
ＰＯＲＴ＿ＯＦ＿ＯＲＩＧＩＮ＿ＡＴＴＲＩＢＵＴＥＳ
ＳＩＴＥ＿ＭＯＮＩＴＯＲ
ＳＴＡＴＵＳ＿ＣＯＮＴＲＯＬ
ＳＹＳＴＥＭ＿ＡＰＰＬＩＣＡＴＩＯＮ
ＳＹＳＴＥＭ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＡＴＴＲＩＢＵＴＥＳ
ＳＹＳＴＥＭ＿ＣＯＮＦＩＧ
ＳＹＳＴＥＭ＿ＮＯＴＩＦＩＣＡＴＩＯＮＳ
ＳＹＳＴＥＭ＿ＮＯＴＩＦＩＣＡＴＩＯＮＳ＿ＨＩＳＴ
ＴＲＡＮＳＡＣＴＩＯＮ＿ＤＥＦＩＮＩＴＩＯＮ
ＴＲＡＮＳＡＣＴＩＯＮ＿ＳＣＲＩＰＴ＿ＳＥＱＵＥＮＣＥ
ＴＲＡＮＳＡＣＴＩＯＮ＿ＳＣＲＩＰＴＳ
ＵＳＥＲ
ＵＳＥＲ＿ＡＧＲＥＥＭＥＮＴ＿ＡＣＣＥＰＴＡＮＣＥ
ＵＳＥＲ＿ＡＴＴＲＩＢＵＴＥＳ
ＵＳＥＲ＿ＡＴＴＲＩＢＵＴＥＳ＿ＨＩＳＴ
ＵＳＥＲ＿ＨＩＳＴ
ＵＳＥＲ＿ＬＯＧＩＮ
ＵＳＥＲ＿ＳＥＳＳＩＯＮ
ＵＳＥＲ＿ＳＥＳＳＩＯＮ＿ＨＩＳＴ
ＸＭＬ＿ＴＲＡＮＳ＿ＤＥＦ
ＸＭＬ＿ＴＲＡＮＳ＿ＴＹＰＥＳ

全てのデータ検索は、外部クラス及びその関連方法を通じて実行される。
「ＡＣＣＥＳＳ＿ＡＰＰＬＩＣＡＴＩＯＮ」表は、「セキュリティ保護ログオン」によりセキュリティで保護された機能及び情報へのアクセスを得るための登録処理中に「外部エンティティ」に関して収集された情報を含む。
「ＡＣＣＥＳＳ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＡＤＤＲＥＳＳ」表は、「ＡＣＣＥＳＳ ＡＰＰＬＩＣＡＴＩＯＮ」の完了中に捕捉することができる代替アドレスに関する情報を含む。
「ＡＣＣＥＳＳ＿ＧＲＯＵＰ」表は、アクセス識別子の分類に基づいて組織の部分（セグメント）を定義するために使用される「アクセスＩＤグループ」（セグメント）に関する定義上の情報を含む。

「ＡＣＣＥＳＳ＿ＧＲＯＵＰ＿ＩＤ＿ＡＳＳＯＣ」表は、「アクセスＩＤグループ」（セグメント）と、「アクセスＩＤグループ」（セグメント）の内容を構成する「アクセス識別子」との間の関連性を含む。
「ＡＣＣＥＳＳ＿ＧＲＯＵＰ＿ＩＤ＿ＡＳＳＯＣ＿ＬＯＧ」表は、「Ａｃｃｅｓｓ＿Ｇｒｏｕｐ＿ＩＤ＿Ａｓｓｏｃ」の初期の作成を含む「ＡＣＣＥＳＳ＿ＧＲＯＵＰ＿ＩＤ＿ＡＳＳＯＣ」に対して為される全ての変更の監査記録を捕捉する。
「ＡＣＣＥＳＳ＿ＧＲＯＵＰ＿ＬＯＧ」表は、「Ａｃｃｅｓｓ＿Ｇｒｏｕｐ」（セグメント）の初期の作成を含む「ＡＣＣＥＳＳ＿ＧＲＯＵＰ」に対して行われた全ての変更の監査記録を捕捉する。
「ＡＣＣＥＳＳ＿ＩＮＤＥＮＴＩＦＩＥＲ」表は、外部エンティティのための「アクセス識別子」に関する情報を含む。これらは、バックエンドシステム内の外部エンティティに関するデータのキーである。例示的な識別子は、「連邦納税識別番号（ＴＩＮ）」、「ブローカーＩＤ」、「州政府免許番号」とすることができる。
「ＡＣＣＥＳＳ＿ＩＮＤＥＮＴＩＦＩＥＲ＿ＬＯＧ」表は、「Ａｃｃｅｓｓ＿Ｉｎｄｅｎｔｉｆｉｅｒ」の初期の作成を含む「ＡＣＣＥＳＳ＿ＩＮＤＥＮＴＩＦＩＥＲ」に対して行われた全ての変更の監査記録を捕捉する。

「Ａｃｃｅｓｓ＿Ａｐｐｌｉｃａｔｉｏｎ＿Ｎｅｗ」情報を収集する処理は、いくつかのアプリケーションモジュールから成ることができる。「ＡＣＣＥＳＳ＿ＭＯＤＵＬＥ＿ＳＥＱＵＥＮＣＥ」表は、アプリケーションモジュールが特定の「原点ポート」及び「エンティティ」に対して実行されるシーケンスを形成する。
「ＡＧＲＥＥＭＥＮＴＳ」表は、「セキュリティ保護ログオン」によりセキュリティで保護された機能及び情報へのアクセスを得るためにユーザが承諾すべき各合意に関する情報を記憶する。
「ＡＬＬＯＷＥＤ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＴＡＴＵＳ＿ＴＯ＿ＲＥＡＳＯＮ＿ＡＳＳＯＩＡＴＩＯＮ」表は、申請ステータスをそのステータスに関する有効理由コードと関連付ける。
「ＡＬＬＯＷＥＤ＿ＭＩＬＥＳＴＯＮＥＳ＿ＡＮＤ＿ＳＴＡＴＥ＿ＴＲＡＮＳＩＴＩＯＮＳ」表は、任意の申請マイルストーン及びステータスに対して、申請処理の次の段階に関して可能な有効申請マイルストーン及びステータスのセットを示す。

「ＡＰＰＬ＿ＡＣＣＥＳＳ＿ＩＤＥＮＴＩＦＩＥＲ」表は、「セキュリティ保護ログオン」によりセキュリティで保護された機能及び情報へのアクセスを得るための登録処理中に捕捉される「外部エンティティ」用のアクセス識別子に関する情報を含む。「アクセス識別子」は、バックエンドシステムにおける「外部エンティティ」に関するデータのキーである。
「ＡＰＰＬＩＣＡＴＩＯＮ＿ＭＯＤＵＬＥ」表は、「Ａｃｃｅｓｓ＿Ａｐｐｌｉｃａｔｉｏｎ＿Ｎｅｗ」情報を収集するために使用されるモジュールの各々に関する情報を含む。各「原点ポート」及び「エンティティタイプ」について異なるセットのモジュールが存在する可能性がある。
「ＡＰＰＬＩＣＡＴＩＯＮ＿ＰＯＲＴ＿ＯＦ＿ＯＲＩＧＩＮ＿ＥＮＴＩＴＹ＿ＴＹＰＥ＿ＡＣＣＥＳＳ＿ＩＤ＿ＴＹＰＥ＿ＡＳＳＯＣＩＡＴＩＯＮ」表は、「セキュリティ保護ログオン」によりセキュリティで保護された機能及び情報へのアクセスを得るための登録処理中に任意の「原点ポート」／「エンティティタイプ」対についてどの「アクセス識別子タイプ」を収集することができるかを判断するために「原点ポート」及び「エンティティタイプ」を「アクセス識別子タイプ」と関連付ける。

「ＡＰＰＬＩＣＡＴＩＯＮ＿ＰＲＯＣＥＳＳＩＮＧ＿ＴＹＰＥ」表は、任意の「エンティティタイプ」及び「原点ポート」についてどのような種類アプリケーション申請処理が行われるかを示す。その例は、「ペーパー処理」、「ペーパーレス」、及び「自動承認」である。
「ＡＰＰＬＩＣＡＴＩＯＮ＿ＲＥＰＯＲＴＩＮＧ＿ＴＡＢＬＥ」表は、各マイルストーンに到達している日付及び時間を含み、最新のステータスを示す各「Ａｃｃｅｓｓ＿Ａｐｐｌｉｃａｔｉｏｎ＿Ｎｅｗ」に関する１つの行を含む。表は、承認の指標及び申請の完了を提供する。
「ＡＰＰＬＩＣＡＴＩＯＮ＿ＲＯＵＴＩＮＧ＿ＣＯＮＴＲＯＬ」表は、「原点ポート」、「エンティティタイプ」、「現在のステータス／マイルストーン」、及び「アクセス申請」を現在担当中のグループに基づいて「アクセス申請」の有効な経路指定宛先を示す。

「ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＴＡＴＵＳ」表は、申請に関して発生した各マイルストーン、ステータス、及び活動の組合せの記録を含む。これらの記録は、承認処理を通じた申請の進行状況を文書で表す。
「ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＴＡＴＵＳ＿ＨＩＳＴＯＲＹ」表は、「ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＴＡＴＵＳ」に対して行われた全ての変更の監査記録を捕捉する。
「ＡＰＰＬＩＣＡＴＩＯＮ＿ＴＹＰＥ＿ＲＥＰＯＲＴＩＮＧ」表は、カウントを素早く判断する際に使用される特化された表である。この表は、各タイプの申請（自動承認、ペーパー処理、ペーパーレス）のための行と、０又は１の値を含む各タイプの申請のための列とを含む。
「ＡＰＰＬＩＣＡＴＩＯＮ＿ＶＩＥＷ＿ＣＯＮＴＲＯＬ」表は、「原点ポート」及び「エンティティタイプ」に基づいてどのグループの人々が申請ステータスを見ることができるかを制御する。

「ＢＦ＿ＡＬＬＯＷＥＤ＿ＢＹＣＯＶＥＲＡＧＥ」表は、「ビジネス機能」を特定の補償範囲タイプと関連付ける。
「ＢＵＳ＿ＦＵＮＣ＿ＩＤ＿ＴＹＰＥ＿ＡＳＳＯＣ」表は、各「ビジネス機能」をそれが処理のために使用する「アクセスＩＤ」のタイプと関連付ける。「ビジネス機能」がこの表に表示されない場合、その「ビジネス機能」には、その処理を行うのにいかなる「アクセスＩｄ」も不要であることを意味する。
「ＢＵＳＩＮＥＳＳ＿ＦＵＮＣＴＩＯＮ」表は、ユーザが実行することができる機能又は活動であり、「セキュリティ保護ログオン」によりセキュリティで保護された各「ビジネス機能」を定義する。
「ＢＵＳＩＮＥＳＳ＿ＦＵＮＣＴＩＯＮ＿ＡＳＳＯＣ」表は、各「ビジネス機能」をそれが属する「ビジネス機能セット」と関連付ける。
「ＢＵＳＩＮＥＳＳ＿ＦＵＮＣＴＩＯＮ＿ＳＥＴ」表は、「ビジネス機能」の論理的グループ分けである各「ビジネス機能セット」を定義する。

「ＣＯＮＴＲＯＬＬＩＮＧ＿ＡＵＴＨＯＲＩＴＹ」表は、「外部エンティティ」を制御し、「外部エンティティ」を契約の合意事項に拘束する法的権利を有する個人に関する情報を含む。
「ＣＯＮＴＲＯＬＬＩＮＧ＿ＡＵＴＨＯＲＩＴＹ＿ＨＩＳＴ」表は、「ＣＯＮＴＲＯＬＬＩＮＧ＿ＡＵＴＨＯＲＩＴＹ」表内の行の更新後の画像を含む。
「ＣＯＶＥＲＡＧＥ＿ＱＵＡＬＦＩＥＲＳ」表は、会員ステータスに基づいて申請可能な補償有資格者を定義する。有資格者は、補償が標準的規則セットを超えて拡張されることを可能にする。
「ＣＯＶＥＲＡＧＥＳ」表は、「ビジネス機能」規則を判断する際の使用に利用可能な補償を識別する。
「ＤＥＬＥＧＡＴＩＯＮ」表は、第三者組織（エンティティ）が、それが業務関係を有する別の組織のために作業を行うことを可能にする情報を定義する。
「ＤＥＬＥＧＡＴＩＯＮ＿ＡＵＴＯＲＩＺＡＴＩＯＮ」表は、組織が別の組織のために作業を行う意思を示す「委任受理コード」を保持する。
「ＤＥＭＯ＿ＩＤＳ」表は、試験及び実証のための「セキュリティ保護ログオン」へのゲストアクセスのために設定される「外部エンティティ」及び「ユーザ」を識別する。

「ＤＹＮＡＭＩＣ＿ＬＩＮＫ」表は、画面上に表示することができる動的に発生されたリンクを定義するために使用される情報を含む。
「ＤＹＮＡＭＩＣ＿ＬＩＮＫ＿ＴＹＰＥ」表は、使用するのに利用可能な動的リンクのタイプを定義する判断基準のリストである。この時点で利用可能なたった１つは、「派生」リンクである。
「ＥＭＡＩＬ＿ＡＤＤＲＥＳＳ」表は、サポートチームの構成員の電子メールアドレスを含む。この表は、エラーメッセージ通知をチームの構成員に送るために使用される。
「ＥＮＴＩＴＹ＿ＴＹＰＥ＿ＥＮＴＩＴＹ＿ＴＹＰＥ＿ＡＳＳＯＣ」表は、どのような組織（Ｆｒｏｍ＿Ｅｎｔｉｔｙ＿Ｔｙｐｅ）を別のタイプの組織（Ｔｏ＿Ｅｎｔｉｔｙ＿Ｔｙｐｅ）に委任することができるかを定義するために「委任」処理において使用される。
「ＥＮＴＩＴＹ＿ＴＹＰＥ＿ＦＵＮＣＴＩＯＮ」表は、「ビジネス機能セット」を「ビジネス機能セット」内で「ビジネス機能」を有効に実行することができる「外部エンティティ」の「エンティティタイプ」と関連付ける。

「ＥＮＴＩＴＹ＿ＵＳＥＲ」表は、「外部エンティティ」の代行として作業を行う許可を受けた「ユーザ」に対するその「外部エンティティ」の関連性を含む。「実際」の「Ｅｎｔｉｔｙ＿Ｕｓｅｒ」は、「外部エンティティ」のために作業を行い、通常の割当て処理を通じて許可を受けた「ユーザ」を識別する。「仮想」の「Ｅｎｔｉｔｙ＿Ｕｓｅｒ」は、別の「外部エンティティ」のために作業を行い、委任処理を通じて許可を受けたユーザを識別する。
「ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＡＣＣＥＳＳ」表は、「ユーザ」が作業することができる「ビジネス機能／データ」対に関して「ユーザ」が「外部エンティティ」に対して有するアクセス権を定義する。
「ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＡＣＣＥＳＳ＿ＬＯＧ」表は、「Ｅｎｔｉｔｙ＿Ｕｓｅｒ＿Ａｃｃｅｓｓ」の初期の作成を含む「ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＡＣＣＥＳＳ」に対して行われた全ての変更の監査記録を捕捉する。
「ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＡＴＴＲＩＢＵＴＥＳ」表は、「ＥＮＴＩＴＹ＿ＵＳＥＲ」に関する情報を記憶する。
「ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＬＯＧ」表は、「ＥＮＴＩＴＹ＿ＵＳＥＲ」の初期の作成を含む「Ｅｎｔｉｔｙ＿Ｕｓｅｒ」に対して行われた全ての変更の監査記録を捕捉する。

「ＥＲＲＯＲ＿ＥＭＡＩＬ＿ＡＳＳＯＣ」表は、サーバ側システムエラーを特定の電子メールアドレスと関連付ける。
「ＥＲＲＯＲ＿ＫＥＹＷＯＲＤ」表は、サーバ側システムエラーに関係する言葉を確立する。いくつかの現在のキーワードは、「申請」及び「ログオン」である。
「ＥＲＲＯＲ＿ＫＥＹＷＯＲＤ＿ＡＳＳＯＣ」表は、特別キーワードをサーバ側システムエラーと関連付け、それによって「顧客サービス担当者」は、そのキーワードに関係する全てのエラーを検索することができる。
「ＥＲＲＯＲ＿ＭＳＧ」表は、サーバ側システムエラー用のエラーメッセージを記憶する。メッセージ内容は、「原点ポート」により異なる可能性がある。「原点ポート」＝０に対しては、デフォルトエラーメッセージが記憶される。
「ＥＲＲＯＲ＿ＲＥＦＥＲＥＮＣＥ」表は、サーバ側システムエラーに関する情報を含む。
「ＥＵ＿ＡＴＴＲＩＢＵＴＥ＿ＨＩＳＴ」表は、「Ｅｎｔｉｔｙ＿Ｕｓｅｒ＿Ａｔｔｒｉｂｕｔｅ」の初期の作成を含む「ＥＮＴＩＴＹ＿ＵＳＥＲ＿ＡＴＴＲＩＢＵＴＥＳ」に対して行われた全ての変更の監査記録を捕捉する。

「ＥＵＡ＿ＤＥＬＥＧＡＴＩＯＮ＿ＡＳＳＯＣ」表は、「Ｅｎｔｉｔｙ＿Ｕｓｅｒ＿Ａｃｃｅｓｓ」表内の行（表内で参照される「委任」）が「仮想ユーザ」に対して存在することが許可された理由を与える。この表は、委任が取り扱われている間だけ使用される。この表には、「Ｅｎｔｉｔｙ＿Ｕｓｅｒ＿Ａｃｃｅｓｓ」表内の行を正当化する複数の行がある可能性があり、すなわち、このエンティティ／ユーザ／ビジネス機能／アクセスＩＤ（又は、アクセスグループ）に対する複数の委任チェーンがある。「ＥＵＡ＿Ｄｅｌｅｇａｔｉｏｎ＿Ａｓｓｏｃ」表は、自己文書化表である。いかなる委任も許可されない。
「ＥＸＣＥＰＴＩＯＮ＿ＰＲＯＦＩＬＥ」表は、ユーザの閲覧から除外されるビジネス機能を定義する。
「ＥＸＣＥＰＴＩＯＮ＿ＰＲＯＦＩＬＥ＿ＬＯＧ」表は、「ＥＸＣＥＰＴＩＯＮ＿ＰＲＯＦＩＬＥ」に対して行われた全ての変更の監査記録を捕捉する。
「ＥＸＣＥＰＴＩＯＮ＿ＳＥＴ」表は、「ＡＳＯ」グループプロファイリングに関する。この表は、ユーザのアクセスを無効にするために使用されるグループの定義を含む。
「ＥＸＣＥＰＴＩＯＮ＿ＳＥＴ＿ＬＯＧ」表は、「ＥＸＣＥＰＴＩＯＮ＿ＳＥＴ」に対して行われた全ての変更の監査記録を捕捉する。

「ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ」表は、「セキュリティ保護ログオン」によりセキュリティで保護された機能及び情報へのアクセスを得るために承認された「外部エンティティ」に関する情報を含む。
「ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ＿ＡＤＤＲＥＳＳ」表は、「外部エンティティ」に対して利用可能としてもよい代替アドレスに関する情報を含む。
「ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ＿ＡＤＤＲＥＳＳ＿ＨＩＳＴ」表は、「ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ＿ＡＤＤＲＥＳＳ」表に対する更新後の画像を含む。
「ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ＿ＡＴＴＲＩＢＵＴＥＳ」表は、「ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ」に関する情報を記憶する。
「ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ＿ＨＩＳＴ」表は、「ＥＸＥＴＥＲＮＡＬ＿ＥＮＴＩＴＹ」表に対する更新後の画像を含む。
「ＦＩＮＡＬ＿ＤＩＳＰＯＳＩＴＩＯＮ＿ＲＥＰＯＲＴＩＮＧ」表は、カウントを素早く判断する際に使用される特化された表である。この表は、申請の各最終処理（承認、拒否、撤回、他）に対する行と、０又は１の値を含む各最終処理に対する列を含む。

「ＨＥＬＰ＿ＧＲＯＵＰ」表は、ユーザが「セキュリティ保護ログオン」を使用する時に実行された様々なビジネス機能に関する「ヘルプ」情報をまとめる「ヘルプグループ」を定義する。
「ＨＥＬＰ＿ＧＲＯＵＰ＿ＯＲＩＧＩＮ＿ＡＳＳＯＣ」表は、各「ヘルプグループ」をそれが有効である「原点ポート」と関連付ける。各「ヘルプグループ」は、「ヘルプグループ」が追加された「原点ポート」と最初に関連付けられるが、「セキュリティ保護ログオンヘルプ」システム内の複数の「原点ポート」に割り当てることができる。
「ＨＥＬＰ＿ＧＲＯＵＰ＿ＯＲＩＧＩＮ＿ＢＵＳ＿ＦＵＮＣ＿ＡＳＳＯＣ」表は、「原点ポート」内の各「ヘルプグループ」を、各「ヘルプグループ」が「ヘルプ」情報をまとめる「ビジネス機能」と関連付ける。どの「原点ポート」内のどの「ヘルプグループ」にもビジネス機能が割り当てられるべきである。

「ＨＥＬＰ＿ＧＲＯＵＰ＿ＴＯＰＩＣ＿ＡＳＳＯＣ」表は、各「ヘルプグループ」を、その「ヘルプグループ」を構成する「ヘルプトピック」と関連付け、その「ヘルプグループ」内で「ヘルプトピック」が表示されることになるシーケンスを示す。
「ＨＥＬＰ＿ＳＥＣＴＩＯＮ」表は、「ヘルプ」情報内の実際の内容である「ヘルプセクション」を定義する。「ヘルプセクション」は、「ヘルプトピック」内で、各タスクを文書化するテキストを書く場所を提供する。
「ＨＥＬＰ＿ＴＯＰＩＣ」表は、「ビジネス機能」内の各画面に関する「ヘルプ」情報をまとめる「ヘルプトピック」を定義する。
「ＩＭＭＵＴＡＢＬＥ＿ＢＵＳＩＮＥＳＳ＿ＦＵＮＣＴＩＯＮＳ」表は、「ＥＸＣＥＰＴＩＯＮ＿ＰＲＯＦＩＬＥ」及び「ＥＸＣＥＰＴＩＯＮ＿ＳＥＴ」内のエントリを無効にする方法を可能にする。

トランザクションが「ＳＱＬサーバ」及び「ＤＢ２」の両方に変更を加える時、「ＤＢ２」を利用不能にすることが可能である。トランザクション全体を強制的に無効にするのでなく、トランザクション内の任意の「ＤＢ２」更新内容は、それらが後で実行されるように記憶されるこの表に書き込まれることになる。「ＩＮＣＯＭＰＬＥＴＥ＿ＤＢ２＿ＵＰＤＡＴＥＳ」表に記憶された「ＤＢ２」更新内容を後で順番に実行することにより、トランザクションの完全性が維持されることになる。

「ＬＯＧ＿ＤＥＴＡＩＬ」表は、詳細ログオプションが「オン」の場合、「ＬＯＧ＿ＳＵＭＭＡＲＹ」内のエラーに関する詳細な情報を含む。
「ＬＯＧ＿ＲＯＬＥ」表は、エラー記録が行われる処理を定義する。
「ＬＯＧ＿ＳＵＭＭＡＲＹ」表は、「セキュリティ保護ログオン」内で発生したエラーに関する情報を含む。
「ＬＯＯＫＵＰ＿ＣＯＤＥ＿ＧＲＯＵＰＳ」表は、「Ｌｏｏｋｕｐ＿Ｃｏｄｅｓ」表内のコードを論理的に別個のコードグループにグループ分けする方法を提供する。「Ｌｏｏｋｕｐ＿Ｃｏｄｅ＿Ｇｒｏｕｐｓ」表は、異なるコードグループを定義する。「ＬＯＯＫＵＰ＿ＣＯＤＥ＿ＧＲＯＵＰＳ」及び「ＬＯＯＫＵＰ＿ＣＯＤＥＳ」は協働し、そうでなければドロップダウンボックス及びリスト用のコード及びその説明を保持するために作成されたであろう複数の物理的な表を置換する汎用構造を形成する。
「ＬＯＯＫＵＰ＿ＣＯＤＥＳ」表は、「Ｌｏｏｋｕｐ＿Ｃｏｄｅ＿Ｇｒｏｕｐｓ」表で定義されたコードグループを構成するコード値を含む。「ＬＯＯＫＵＰ＿ＣＯＤＥ＿ＧＲＯＵＰＳ」と共に、これらの２つの表は、そうでなければドロップダウンボックス及びリスト用のコード及びその説明を保持するために作成されたであろう複数の物理的な表を置換する汎用構造を形成する。

「ＭＥＮＵ＿ＴＥＭＰＬＡＴＥ」表は、実行する権利を各々が有する「ビジネス機能」を含む各ユーザのための特別メニューを作成する際に使用することができるテンプレートを定義する。
「ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＣＯＮＦＩＲＭＡＴＩＯＮＳ」表は、「ＸＭＬ通知」の受領に関する確認情報を含む。
「ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＰＡＹＯＲ＿ＬＩＳＴ」表は、１つのタイプ又は別のタイプの「ＸＭＬ通知」と「ＸＭＬ」通知の送付先である「ＵＲＬ」とを受信するように選ぶ「システムアプリケーション」所有者のリストを含む。
「ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＰＡＹＯＲ＿ＭＳＧ＿Ｑ」表は、各「システムアプリケーション」所有者に対して処理準備完了である「通知」の待ち行列を含む。
「ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＰＡＹＯＲ＿ＭＳＧ＿ＴＹＰＥＳ」表は、「システムアプリケーション」所有者が受信することを選ぶ「通知」タイプの「システムアプリケーション」所有者によるリストを含む。

「ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＰＯＳＴ＿ＦＡＩＬＵＲＥＳ」は、処理を失敗した全ての「通知」の履歴を記憶する。
「ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＴＲＡＮＳＡＣＴＩＯＮ」表は、「ＸＭＬ」通知プロセッサが処理するのを待っている「通知」の待ち行列を含む。
「ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＨＩＳＴ」表は、「ＸＭＬ」トランザクションプロセッサにより失敗なく処理された全ての「通知」の履歴を記憶する。これには、欲する人がおらず、従ってどこにも送信されなかった「通知」が含まれる。
「ＯＲＩＧＩＮ＿ＬＯＯＫＵＰ＿ＣＯＤＥ＿ＯＶＥＲＲＩＤＥＳ」表は、「ＬＯＯＫＵＰ＿ＣＯＤＥＳ」表に対する「原点ポート」特異の追加、置換、及び除外を含む。
「ＰＡＳＳＷＯＲＤ＿ＣＨＡＮＧＥ＿ＨＩＳＴＯＲＹ」表は、ユーザに関するパスワード変更履歴を記録する。

「ＰＯＲＴ＿ＯＦ＿ＯＲＩＧＩＮ」表は、「セキュリティ保護ログオン」によりセキュリティで保護された「原点ポート」を定義し、「原点ポート」は、「セキュリティ保護ログオン」を通じてセキュリティで保護されたビジネス機能及びリソースへのアクセスを得るための開始点又はエントリ点である。
「ＰＯＲＴ＿ＯＦ＿ＯＲＩＧＩＮ＿ＡＴＴＲＩＢＵＴＥＳ」表は、「原点ポート」に関する情報を記憶する。
「Ｓｉｔｅ＿Ｍｏｎｉｔｏｒ」表は、サイトがアクティブのままであることを見るためにそのサイトをモニタするのに使用される情報を含む。
「ＳＴＡＴＵＳ＿ＣＯＮＴＲＯＬ」表は、「ユーザ」、「エンティティ」、及び「Ｅｎｔｉｔｙ＿Ｕｓｅｒ」の「ステータス」を制御する。ステータスは、「アクティブ」、「取消し済み」、又は「非アクティブ」を含むことができる。

「ＳＹＳＴＥＭ＿ＡＰＰＬＩＣＡＴＩＯＮ」表は、ビジネス機能又はビジネス機能セットを実行するコードである各「システムアプリケーション」に関する情報を含む。
「ＳＹＳＴＥＭ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＡＴＴＲＩＢＵＴＥＳ」表は、「システムアプリケーション」に関する情報を記憶する。
「ＳＹＳＴＥＭ＿ＣＯＮＦＩＧ」表は、「セキュリティ保護ログオン」の特定のインストール／設定に関する情報を記憶する。
「ＳＹＳＴＥＭ＿ＮＯＴＩＦＩＣＡＴＩＯＮＳ」表は、広範囲のクラスのユーザに対する「システム通知」の同報通信を可能にする情報を含む。
「ＳＹＳＴＥＭ＿ＮＯＴＩＦＩＣＡＴＩＯＮＳ＿ＨＩＳＴ」表は、「ＳＹＳＴＥＭ＿ＮＯＴＩＦＩＣＡＴＩＯＮＳ」の履歴を記憶する。
「ＵＳＥＲ」表は、「セキュリティ保護ログオン」によりセキュリティで保護されたビジネス機能及びリソースに対する「Ｅｘｔｅｒｎａｌ＿Ｅｎｔｉｔｙ」により付与された権利をかつて有したことがある各ユーザに関する情報を含む。
「ＵＳＥＲ＿ＡＧＲＥＥＭＥＮＴ＿ＡＣＣＥＰＴＡＮＣＥ」表は、各「ユーザ」が承諾した各「合意」に関する情報を記憶する。

「ＵＳＥＲ＿ＡＴＴＲＩＢＵＴＥＳ」表は、「ＵＳＥＲ」に関する情報を記憶する。
「ＵＳＥＲ＿ＡＴＴＲＩＢＵＴＥ＿ＨＩＳＴ」表は、「ＵＳＥＲ＿ＡＴＴＲＩＢＵＴＥＳ」に関する履歴を記憶する。
「ＵＳＥＲ＿ＨＩＳＴ」表は、「ＵＳＥＲ」表の更新後の画像を含む。
「ＵＳＥＲ＿ＬＯＧＩＮ」表は、各「ユーザ」のセキュリティ確認情報を記憶し、失敗した「ユーザ」ログオン試行に関する統計を蓄積する。
「ＵＳＥＲ＿ＳＥＳＳＩＯＮ」表は、現在アクティブである「ログオンセッション」に関する情報を記憶する。
「ＵＳＥＲ＿ＳＥＳＳＩＯＮ＿ＨＩＳＴ」表は、「セキュリティ保護ログオン」に対する各「ユーザ」の以前の全ての「ログオンセッション」に関する情報を記憶する。
「ＸＭＬ＿ＴＲＡＮＳ＿ＤＥＦ」表は、「ＸＭＬ通知」プロセッサのバージョンに関する情報を記憶する。
「ＸＭＬ＿ＴＲＡＮＳ＿ＴＹＰＥＳ」表は、「ＸＭＬ」通知トランザクションを起動することができるイベントを説明する情報を記憶する。
表の一部に対するデータの定義は、以下の通りである。

上述の教示内容に照らして当業者が認めるように、本発明の上述の実施形態の修正及び変形が可能である。従って、特許請求の範囲及びその均等物の範囲において、本発明が具体的に説明した以外の方法で実施することができることは理解されるものとする。

ＰＡＡ 主アクセス管理者

Claims (31)

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. 前記異なる種類の環境内への組込みをサポートする手段は、「両方向音声応答（ＩＶＲ）」システムと統合する手段を含むことを特徴とする請求項１に記載のセキュリティシステム。

Images