(57)【特許請求の範囲】
【請求項１】
コンピューティングシステムにおいて、複数のコンピュータアプリケーションを動的に管理するための方法であって、
複数のアプリケーションエンタイトルメントを含むデータを受信すること、
複数のグループ定義を受信することであって、前記複数のグループ定義の各々は、グループ組成論理規則の評価を介してグループのメンバを識別するために使用されるグループ組成論理規則を表現する、前記複数のグループ定義を受信すること、
前記複数のグループ定義の各々の前記グループ組成論理規則を評価して、複数のデータレポジトリクエリを生成すること、
前記複数のデータレポジトリクエリを１つまたは複数のデータレポジトリに対して実行させて、複数のユーザを複数のグループにマッピングし、かつ複数のユーザを前記複数のアプリケーションエンタイトルメントにマッピングする１つまたは複数のテーブルを決定すること、
ユーザおよびグループのうちの少なくとも一方に対するユーザ生成変更を受信すること、
前記変更を、複数のユーザを複数のグループにマッピングする前記１つまたは複数のテーブルを介して自動的に伝搬すること、及び前記変更を、複数のユーザを前記複数のアプリケーションエンタイトルメントにマッピングする前記１つまたは複数のテーブルへ自動的に伝搬することのうちの少なくとも一方と、
グループが廃止されるべきことを決定すること、
前記グループ組成論理規則を、前記廃止されるべく決定されたグループから、前記廃止されるべく決定されたグループを指す前記複数のグループ定義のうちの１つまたは複数へと移動させること
を含む方法。
【請求項２】
前記ユーザ生成変更は、ユーザに対する変更であり、複数のユーザを複数のグループにマッピングする前記１つまたは複数のテーブルへの前記変更の自動的伝搬および複数のユーザを前記複数のアプリケーションエンタイトルメントにマッピングする前記１つまたは複数のテーブルへの前記変更の自動的伝搬のうちの少なくとも一方は、前記ユーザ生成変更を、前記複数のデータレポジトリクエリを実行し直させることによって自動的に伝搬する、請求項１に記載の方法。
【請求項３】
前記グループ組成論理規則は、ユーザの属性が値に一致するかどうかを表現する１つまたは複数の属性規則、別のグループのメンバを包含または排除する１つまたは複数のグループ規則、および複数のグループ組成論理規則を組み合わせるために接続または離接を用いる１つまたは複数の複合規則のうちの少なくとも一つを備える、請求項１または請求項２に記載の方法。
【請求項４】
前記受信された複数のグループ定義のうちのグループ定義の各々は、一または複数の排除されたユーザおよび一または複数の包含されたユーザのうちの少なくとも一方も含む、請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
ユーザおよびグループのうちの少なくとも一方に対するユーザ生成変更を受信することは、ユーザの属性を設定すること、ユーザを追加、排除または修正すること、グループを追加、排除または修正すること、および包含されたグループを追加、排除または修正することのうちの少なくとも１つを含む、請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記複数のグループ定義の各々の前記グループ組成論理規則を評価して、複数のデータレポジトリクエリを生成することは、
前記複数のグループ定義の各々の前記グループ組成論理規則を評価して、１つまたは複数のユーザ規則を生成すること、
前記１つまたは複数のユーザ規則を評価して、前記複数のデータレポジトリクエリを生成すること
をさらに含む、請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
ユーザからアクセス要求を受信すること、
複数のユーザを複数のグループにマッピングする前記１つまたは複数のテーブルから、前記ユーザが資格付与されたグループのメンバであるかどうかを決定すること
によって、前記複数のグループのうちの１つにおける前記メンバに対して、アプリケーションリソースへのアクセスを認可することをさらに含む、請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
前記アプリケーションリソースへのアクセスを認可することは、前記リソースのタイプとは独立している、請求項７に記載の方法。
【請求項９】
前記複数のアプリケーションエンタイトルメントは、ソフトウェアアズアサービス（「ＳａａＳ」）アプリケーションのリソース、遠隔デスクトップのリソース、および仮想化環境において実行されるリモートアプリケーションのリソースのうちの少なくとも１つにアクセスするために使用される、請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
前記複数のユーザが人であるユーザまたはコンピュータを含むか、または前記データレポジトリクエリがＳＱＬデータベースクエリであり、或いは、
前記複数のユーザが人であるユーザまたはコンピュータを含み、かつ前記データレポジトリクエリがＳＱＬデータベースクエリである、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
前記複数のグループ定義を分析して、１つまたは複数のグループ定義の前記グループ組成論理規則における冗長性を決定すること、
前記１つまたは複数のグループ定義をリファクタリングして、前記１つまたは複数のグループ定義の前記冗長性を低減すること
をさらに含む、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
前記複数のグループ定義を分析して冗長性を決定すること、および前記１つまたは複数のグループ定義をリファクタリングして前記冗長性を低減することは、
前記グループ組成論理規則を評価することなく前記複数のグループ定義の前記グループ組成論理規則の論理を分析すること、
特定のグループ組成論理規則が、ゼロエンティティまたは可能性のある全てのエンティティに影響することを認識すること、および
第１のグループ組成論理規則が、前記１つまたは複数のグループ定義に含まれる第２のグループ組成論理規則と少なくとも実質的に等価であることを決定し、かつ前記１つまたは複数のグループ定義における第２のグループ組成論理規則を前記第１のグループ組成論理規則で置換すること
のうちの少なくとも一つをさらに含む、請求項１１に記載の方法。
【請求項１３】
前記１つまたは複数のグループ定義をリファクタリングして、前記１つまたは複数のグループ定義の前記冗長性を低減することは、
決定された等価なグループ組成論理規則を前記１つまたは複数のグループ定義から排除すること、
前記決定された等価なグループ組成論理規則を含む新しいグループ定義を生成すること、
前記１つまたは複数のグループ定義に、前記新しいグループ定義の参照を包含させること
をさらに含む、請求項１１に記載の方法。
【請求項１４】
前記グループ組成論理規則が組織内の業務役割に関連するか、またはコンピュータリソースがソフトウェアリソースまたはハードウェアリソースを備え、或いは、
前記グループ組成論理規則が組織内の業務役割に関連し、かつコンピュータリソースがソフトウェアリソースまたはハードウェアリソースを備える、請求項１乃至１３のいずれか一項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、人々およびコンピュータシステムを含むエンティティのグループを管理しかつグループのメンバへコンピュータリソースへのエンタイトルメントおよびアクセスを提供するための方法、技術およびシステムに関し、かつ具体的には、大規模環境においても、グループおよび個々のエンティティのメンバーシップ状態へ効率的かつほぼ瞬時的な更新を提供するための方法、技術およびシステムに関する。
【背景技術】
【０００２】
現代の世界は、コンピュータリソースへのエンタイトルメントおよびアクセスの管理が効率的、正確かつ安全であることを要求している。コンピューティングの遠隔実行がますます進み、かつ組織のサイズおよび複雑さが拡大するにつれて、こうした難題は増大し続ける。テクノロジーの多くの波は、大部分の組織のＩＴインフラを実行が複雑で柔軟性がなく、高価なものにしてきている。人々、デバイスおよびアプリケーションは、密接に結合され、新たなアプリケーションのロールアウト、または新たな作業パターンのサポートを困難にしている。企業内のＩＴ組織は、多様化するテクノロジーを基礎として何千とは言えないまでも何百ものアプリケーションを管理し、かつ各々が固有の動作環境および特異体質を有する何千ものＰＣおよびサーバを実行しなければならない。
【０００３】
分散されたＰＣまたは他のアクセスデバイス上にソフトウェアを保持することは高価であり、かつ多大な時間を要する。ＰＣを介して提供されるアプリケーションおよびサービスの数が増すにつれて、ＰＣコンフィギュレーションの複雑さは高まる。
【０００４】
歴史的に、この問題は、ＰＣに対して行うことができる変更を制限すべくＰＣを「ロックダウン」することによって対処されてきている。プロダクトもやはり、ソフトウェアを物理的デバイスへと「プッシュ」すべく導入されてきているが、これらのアプローチは、少ない十分に規定された数のアクセスデバイスならびに比較的低頻度の更新サイクルが存在することに依存する。数年前までは、これは、困難ではあったが、十分に管理された環境にあっては達成可能であった。しかしながら、（例えば、ウイルス、ワームおよびセキュリティループホールを防止するための）頻繁かつリアルタイムの更新の必要性と組み合わされたアクセスデバイス（現時点でＰＣ、ラップトップ、ＰＤＡおよび携帯電話等のデバイスを包含する）の数およびタイプの急増は、このようなアプローチを役に立たないものにしている。
【０００５】
大規模組織において、アクセスデバイスの多様性の問題は、エンドユーザが多くの異なるプラットフォームで実行されるアプリケーションを用いる、という事実によって一層増す。アプリケーションの中には、ユーザのＰＣ上で実行されるものもあれば、主に端末アプリケーション、シンクライアントまたはウェブサービスとして実行されるものがあり、かつバーチャル・マシン・テクノロジー上で実行されるものもある。これまでは、これらのアプリケーションをサポートしかつ管理するためのインフラは、全く別のものであった。
【図面の簡単な説明】
【０００６】
【図１】図１は、あるエンタイトルメント管理システム例を示す概観ブロック図である。
【図２】図２は、あるエンタイトルメント管理システムの一実施形態例のコンポーネントを示す例示的なブロック図である。
【図３】図３は、あるグループ管理エンジン例のコンポーネントを示す例示的なブロック図である。
【図４】図４は、グループ管理エンジンによる分析およびリファクタリングに使用される論理ツリーの例を示す。
【図５】図５は、グループ管理エンジンによる分析およびリファクタリングのためのさらなる論理ツリー例を示す。
【図６】図６は、エンタイトルメント管理システムの一実施形態例によって実行されることが可能なタスクの概観図である。
【図７】図７は、エンタイトルメント管理システムの実施形態例を実施するためのコンピューティングシステムを示す例示的なブロック図である。
【図８】図８は、ある例示的なグループ管理エンジンにより実行される論理例を示すフロー図である。
【図９】図９は、あるエンタイトルメント管理システムの例示的な分析およびリファクタリングコンポーネントにより実行される論理例を示すフロー図である。
【図１０Ａ】図１０Ａは、あるエンタイトルメント管理システム例の例示的なデータフローを示す。
【図１０Ｂ】図１０Ｂは、あるエンタイトルメント管理システム例の例示的なデータフローを示す。
【発明を実施するための形態】
【０００７】
本明細書に記述される実施形態は、グループメンバーシップを基礎としてエンティティへコンピュータリソースへのアクセスを効率的、正確かつ安全に認可するための増強されたコンピュータおよびネットワークベースの方法およびシステムを提供する。例示的な実施形態は、ＩＴマネージャ、管理ユーザまたはこれらに類似するもの等のユーザが、グループ内のエンドユーザ（または他のエンティティ）メンバーシップに従って「ほぼ」リアルタイムでコンピュータリソースへのエンタイトルメントを認可しかつこれをプロビジョニングできるようにする、エンタイトルメント管理システム（「ＥＭＳ」）を提供する。即ち、例えば組織のニーズが変わるにつれて、グループメンバーシップの変更も、別個の同期プロセス（実行可能なスレッドまたはこれに類似するもの）を用いてほぼ即座に反映され、よって、ユーザに資格付与されるコンピュータリソースおよびこのようなリソースのプロビジョニングが、多大な管理オーバーヘッドなしに事実上瞬間的に最新状態に保たれる。グループメンバーシップは、組織内のエンドユーザロールを基礎とすることが可能であり、潜在的に任意かつすぐに時代遅れになるアクセス制御リストを基礎とするものではない。組織内のエンドユーザロールが変わるにつれて、エンドユーザが属するグループは、迅速に更新される。ほとんど遅延することなく、アクセスおよびセキュリティ上のニーズも保全され得るように、その時点でエンドユーザが利用できるコンピュータリソースも自動的に更新される。さらに、ＥＭＳにより使用される技術は、ターゲットデバイスまたはプロビジョニングさているコンピュータリソースとは独立している。したがって、ＥＭＳがエンタイトルメントおよびプロビジョンアプリケーションおよびこれらの技術を用いる他のソフトウェアを管理する能力は、アプリケーション（例えば、ローカルアプリケーション、仮想化アプリケーション、サービスとしてのソフトウェア等）、デバイスまたは管理されているエンティティのタイプに関わらず管理者がインフラを通じたアクセス完全性を保証する能力を向上させる。本明細書において、グループは、人々、コンピュータシステムまたはこれらの組合せを含むことが可能である。また、本明細書において、ＥＭＳグループを管理し得るユーザ（例えば、管理者、マネージャまたは他のユーザ）、または別段の指摘のない限りリソースへのアクセスを受信するエンドユーザまたは他のエンティティ間に区別はなく、幾つかの実施形態におけるように、アクセスを受信するユーザもまたシステムの管理者であってもよい。
【０００８】
例示的な実施形態において、ＥＭＳは、グループ管理エンジン、エンタイトルメントエンジンおよびプロビジョニングエンジンを含むツールセットを備える。グループ管理エンジン（「ＧＭＥ」）は、エンティティおよび１つまたは複数のグループ内のメンバーシップを規定する１つまたは複数の規則に関する情報を受信し、かつユーザをグループに関連づけるテーブルを生成する。ある実施形態例において、規則は、個々のグループにおけるメンバーシップに関して所定の基準を要求する論理条項である。エンタイトルメントエンジン（「ＥＥ」）は、ＧＭＥから（ＧＭＥが最新状態に維持する）情報を受信し、かつ、個々のユーザエンタイトルメントを要求することなく、グループメンバーシップを基礎としてユーザを適切なリソース（例えば、アプリケーション）エンタイトルメントと相関するテーブルを生成する。プロビジョニングエンジン（「ＰＥ」）は、ＥＥから（ＥＥが最新状態に維持する）情報を受信し、かつ、やはりそのグループメンバーシップを基礎として適切なコンピュータリソースをエンティティに対しプロビジョニングする。
【０００９】
実施形態によっては、ＥＭＳは、様々なコンポーネントの動作がユーザ（例えば、管理者）の目に見えるように構造化される。他の実施形態では、ＥＭＳのコンポーネントは、ユーザが様々なコンポーネントを直接観察する、または同コンポーネントに指示することを要求することなく共に動作する。ＥＭＳのコンポーネントは、ユーザ情報、グループ情報またはエンタイトルメント情報の変更を自動的に伝搬すべく互いにリンクされることが可能である。
【００１０】
実施形態によっては、ＥＭＳのグループ管理エンジンは、グループ定義における規則を非効率、不正確さ、論理的不一致または他の課題に関して分析しかつ課題を最小限に抑える、またはなくすように規則をリファクタリングする分析およびリファクタリングコンポーネントを含む。分析コンポーネントは、グループ定義を、グループ定義を実行した結果を見ることにより経験的に、または所定のエンティティセットに規則を適用した結果とは独立して規則自体を分析することにより理論的に分析することができる。
【００１１】
ＥＭＳは、状況が変わると所定のエンティティによるアクセスを変更する必要性を排除することにより、どのエンティティがどのコンピュータリソースへのアクセスを有するかを管理するタスクを単純化する。あるエンティティのステータスが変われば、この変化はＥＭＳのエンティティ（例えば、ユーザ）データテーブルへ入力され、かつ適切なコンピュータリソース・エンタイトルメントおよびプロビジョニングが自動的に生成される。例えば、ある従業員が解雇されれば、マネージャは、単にステータスの変更を（例えば、適切なデータ構造に）書き留め、よってこの従業員による従業員としてのその役割に基づくコンピュータリソースへの先行アクセスは、ＥＭＳがテーブルを更新する際に自動的に取り消される。
【００１２】
図１は、あるエンタイトルメント管理システム例を示す概観ブロック図である。コンピューティング環境１００において、ＩＴマネージャまたは他の管理者等のユーザ１１０は、ＥＭＳ１２０と相互作用して、１つまたは複数のグループ１２６ａ−１２６ｂへのメンバーシップ１２２ａ−ｂおよびエンタイトルメント１２４ａ−ｂを認可する（例えば、与える、割り当てる、設定する、等々）ことができる。グループ定義および１つまたは複数のグループにおけるエンティティのメンバーシップを基礎として、ＥＭＳ１２０は、１つまたは複数のフルプロビジョニングのアプリケーション（または他のコンピューティングリソース）をエンティティへ配信することができる。
【００１３】
記述しているように、ＥＭＳ１２０は、これらのタスクを、グループ管理エンジン（「ＧＭＥ」）２００、エンタイトルメントエンジン（「ＥＥ」）２２０およびプロビジョニングエンジン（「ＰＥ」）２４０を含む様々なコンポーネントを用いて達成する。ＧＭＥ２００は、様々なエンティティおよび１つまたは複数のグループ定義を記述する情報を受信し、かつこの情報を用いてグループメンバーシップを管理する。各グループ１２６ａ−ｂは、グループ組成規則１３１ａ−ｂ（「ＧＣＲ」）、包含されるエンティティリスト１３２ａ−ｂおよび排除されるエンティティリスト１３３ａ−ｂより成るセットを備える。各ＧＣＲは、グループ内のメンバーシップを規定する１つまたは複数の論理条項を含む。例えば、論理条項は、グループに包含される（またはグループから排除される）ために満たされる必要がある接続的（ｃｏｎｊｕｎｃｔｉｖｅ）または離接的（ｄｉｓｊｕｎｃｔｉｖｅ）特性または属性を含んでもよい。包含されるエンティティおよび排除されるエンティティのリスト（例えば、リスト１３２ａおよび１３２ｂ）は、ＧＣＲより高い、または低い優先順位を与えられることが可能であり、または包含または排除する単一エンティティをリストするＧＣＲとして表現されることが可能である。グループのメンバは、人々、コンピュータリソース、システムまたはこれらの何らかの組合せを含む、エンティティ１４０およびエンティティ１５０等のエンティティであることが可能である。
【００１４】
ＧＭＥ２００は、エンティティ１４０、１５０に関するデータを、例えば名前と値のペアセットとして格納することができ、これは、論理条項が評価される時点で所定のエンティティがグループのメンバであるかどうかを決定するために使用される。例示的なエンティティであるエンティティＡ１５０は、「部門−販売」、「在職期間−２年」および「地域−北米」等の名前／値ペアとして格納された様々な属性を有して示されている。事実上、エンティティ１５０の任意の適切な属性は、格納されかつグループメンバーシップの決定に使用されることが可能である。例えば、グループＡ１２６ａは、販売に携わる従業員であるエンティティを含み、かつ組織における在職期間が１年未満の人々を排除すると定義されているものとする。図示されているように、エンティティＡ１５０は、エンティティ（従業員）が販売部門に２年間在籍し、北米で勤務していることから、何れの基準にも適合し、よって、グループＡ１２６ａのメンバである。別の例として、グループＢ１２６ｂが、組織における在職期間が２年以上である人々として定義されているものとする。図１に示されているように、エンティティＡ１５０は、このグループのメンバでもある。
【００１５】
グループ１２６ａ−ｂのうちの一方または双方におけるメンバーシップは、別のグループにおけるメンバーシップを規定する基準としても使用されることが可能である。例えば、第３のグループが、グループＡ１２６ａに属するが、グループＢ１２６ｂには属さないエンティティを含むものとして定義されているものとする。先の例で論じたエンティティＡ１５０は、双方のグループ１２６ａおよび１２６ｂのメンバであり、この基準に適合せず、またはこれを満たさず、よって、第３のグループから排除される。したがって、論理条項は、場に応じて、かつ組織による必要性に応じて複雑でも単純でもあることが可能である。
【００１６】
所望されるグループが定義されると、管理者１１０は、グループの定義を基礎としてグループ１２６ａ−ｂへエンタイトルメント１２４ａ−ｂを割り当てることができ、コンピュータリソースのサブスクリプション、ライセンスまたは他の属性がプロビジョニングされる。よって、このようなエンタイトルメントを受信するグループは、リソースがプロビジョニングされると、コンピュータリソースにアクセスすることができる。エンタイトルメントエンジン２２０は、異なるグループ１２６ａ−ｂへのエンタイトルメントの割当てを監督する。組織の異なるメンバは、組織の所定のソフトウェアまたはハードウェアリソースに対して異なるニーズを有する場合があり、よってＥＥ２２０は、管理者１１０が従業員を追跡して適宜かつ容易にアクセスを認可することを可能にする。
【００１７】
プロビジョニングエンジン２４０は、次に、グループ１２６ａ−ｂへ割り当てられたエンタイトルメント１２４ａ−ｂを基礎として、様々なエンティティ１４０および１５０へコンピュータリソース（例えば、アプリケーション）をプロビジョニングする。したがって、例えば、グループＢが特定のアプリケーションを用いる資格を与えられていれば、プロビジョニングされたアプリケーション１６０がＰＥ２４０によってエンティティＡ１５０およびエンティティＢ１４０の双方に対し、プロビジョニングされてもよい。
【００１８】
図２は、あるエンタイトルメント管理システムの一実施形態例のコンポーネントを示す例示的なブロック図である。図１に関連して述べたように、ＥＭＳ１２０は、ＧＭＥ２００と、ＥＥ２２０と、ＰＥ２４０とを含む。ＧＭＥ２００は、ユーザに関する属性を決定しかつグループメンバーシップを規定する論理を決定するために、データリポジトリであるグループデータ２０２およびユーザデータ２０４と通信する。グループデータリポジトリ２０２は、ＧＣＲ、包含および排除リスト等のグループ定義を記述する情報を格納する。ユーザデータリポジトリ２０４は、先に述べた名前／値ペア等のエンティティを記述するデータを含む。
【００１９】
ＥＭＳ１２０のコンポーネントは各々、データテーブルを同期するために、（異なる実施形態において、プロセス、タスク、スレッドまたは他の実行可能コードとして実装されてもよい）１つまたは複数のプロセスを含む。具体的には、ＧＭＥ２００は、グループデータリポジトリ２０２またはユーザデータリポジトリ２０４への変更および／または追加によりトリガされてユーザグループテーブル２０６を生成または更新する、ユーザグループ同期２１２と呼ばれるプロセスを含む。実施形態によっては、ユーザグループテーブルは、グループメンバーシップの変更を容易かつ迅速に反映するために、エンティティおよびそれが属するグループのフラットリストを含む。留意すべきこととして、本明細書では「テーブル」と称しているが、等価情報を格納するためには、ファイル、リストまたはこれらに類似するもの等の他のデータ構造が使用されてもよい。また、情報の格納および問い合わせを、例によってはデータベースに関連して記述しているが、他の手段が同様に組み込まれてもよい。ＥＥ２２０は、エンタイトルメントデータとの組合せでユーザグループテーブル２０６の変更によりトリガされて自動的にユーザエンタイトルメントテーブル２０８を生成または更新するエンタイトルメント同期プロセス２１４を含む。ユーザエンタイトルメントテーブル２０８は、エンティティおよびユーザが資格付与されるコンピュータリソースのフラットリストである。ＰＥ２４０は、エンティティおよびエンティティが資格付与されるコンピュータリソースの状態、およびコンピュータリソースをエンティティに対しプロビジョニングする方法を記述するプロビジョン状態テーブル２１０を生成または更新するプロビジョン同期プロセス２１６を含む。プロビジョン状態テーブル２１０の変更は、ユーザエンタイトルメントテーブル２０８の変更によって自動的にトリガされる。ＰＥ２４０は、プロビジョン状態テーブル２１０に従ってリソースのプロビジョニングを実行するデリバリエンジンプロセス２１８も含んでもよい。またＰＥ２４０は、コンピュータリソース（例えば、ソフトウェア・アズ・ア・サービス「ＳａａＳ」アプリケーション）をプロビジョニングするためにサードパーティサービス２２２と通信しかつ協働してもよい。したがって、ＥＭＳ１２０は、ユーザのステータスまたはグループのステータスの変更を受信し、かつこの変更を、所定のエンティティがどのコンピュータリソースに対して資格付与されているかを記述するフラットテーブルを生成するためにシステムを介して伝搬する。よって、管理者は、「エンティティＸは、どのコンピュータリソースへのアクセスを有するか？」または「Ｙグループのメンバはどのエンティティか？」または「どのエンティティがＺコンピュータリソースへのアクセスを有するか？」という問合わせ等の所定の管理タスクを容易に実行することができる。
【００２０】
テーブルが作成されると、これらは、グループメンバーシップとの関連に関わりなく、エンタイトルメントおよびプロビジョニング情報を直接かつ効率的に決定するために使用されてもよい。実施形態によっては、グループ内のメンバーシップは目的そのものではなく、目的を達成するための手段であり、目的は、適切なコンピュータリソースをエンティティに対しプロビジョニングすることにある。例えば、所定のエンティティが所定のコンピュータリソースへのアクセスを試行すると、これらのテーブルは、アクセスを認めるか否かを決定するために迅速にアクセスされることが可能である。テーブルは、グループ情報を用いて要求より先に計算されている場合もあるが、アクセス時には、所定位置に存在し、よってテーブルの再計算は不要である。前もって計算が実行されていることによる、アクセス試行に応じたテーブル再計算の必要性の排除は、本明細書に記述する技術が向上した効率および精度を提供する方法の１つである。さらに、テーブルは、これらを継続的、定期的または時限的に更新することにより、最新状態に保たれてもよい。
【００２１】
ある実施形態例において、ＧＭＥ２００は、エンティティグループの効率的管理を可能にしかつコンピュータリソースへのエンタイトルメントおよびそのプロビジョニングを管理するために共に動作する１つまたは複数の機能コンポーネント／モジュールを備える。図３は、あるグループ管理エンジン例のコンポーネントを示す例示的なブロック図である。ＧＭＥ２００は、先に述べたように、ユーザ１１０（例えば、管理者またはマネージャ）から入力を受信する。ＧＭＥ２００は、グループ組成規則（「ＧＣＲ」）、包含されるユーザリストおよび排除されるユーザリストを含む１つまたは複数のグループ定義３０２を受信しかつ格納する。グループ定義３０２のＧＣＲは、「３０歳を超える人々を包含する」または「米本土外の人々を排除する」または所望される通りの他の任意の適切な規則等の論理条項を含む。「包含されるユーザ」および「排除されるユーザ」の構成要素は、規則に類似するものである可能性があるが、これらは、一人または複数のユーザ固有のものであり、よってエンティティ固有の規則として作り直すことができる。規則は、離接的または接続的組合せ等の、規則の組合せである可能性がある。実施形態によっては、規則は、プログラミング言語において見出されるフロー制御ステートメント等の機能を有する複合論理表現である。
【００２２】
ＧＭＥ２００は、各グループ定義をグループ定義コンパイラ３０４へ伝え（例えば、転送する、方向づける等）、グループ定義コンパイラ３０４は、後に図４および図５に関連してより詳細に論じるように、規則を解析して規則ツリー３０６にする。「コンパイラ」という用語は、概して任意のタイプのプロセッサを指し、本開示の実施形態では、一般性を失うことなく使用される。各規則ツリーの分岐は、各グループ定義３０２からの個々の規則である。ＧＭＥ２００は、ユーザ規則コンパイラ３１０も含み、ユーザ規則コンパイラ３１０は、規則ツリー３０６を受信しかつ各グループに対応する１つまたは複数のデータリポジトリクエリ３１２を作成する。実施形態によっては、データリポジトリクエリは、ＳＱＬクエリまたは他の適切なデータクエリであることが可能である。データリポジトリクエリ３１２からは、図２に関連して先に論じたユーザグループテーブル２１４等の１つまたは複数のテーブル３１４が生成される。これらのテーブル３１４は、どのエンティティがどのコンピュータリソースへのアクセス権を与えられるかを決定するために使用される。
【００２３】
また、ＧＭＥ２００は、グループ定義または規則ツリーをリファクタリングすることによって随時ＧＭＥ２００の精度および効率を分析することができる分析およびリファクタリングコンポーネント３０８も含む。具体的には、分析およびリファクタリングコンポーネント３０８の分析部分は、所定のグループ定義が別のグループ定義に対して冗長性があるかどうか、グループ定義が不正確であるかどうか、またはグループ定義が自明であるかどうか、を決定しようとし、可能性のある全ての結果またはゼロ結果を返す。次に、分析およびリファクタリングコンポーネント３０８のリファクタリング部分は、グループ定義を適宜変更して非効率または不正確さを排除する。
【００２４】
実施形態によっては、分析およびリファクタリングコンポーネント３０８は、単一のコンポーネント３０８として実装される。他の実施形態では、分析およびリファクタリングコンポーネント３０８は、２つの別個のコンポーネント、即ち分析コンポーネント３０９ａおよびリファクタリングコンポーネント３０９ｂ、として実装される。分析コンポーネント（または、部分）３０９ａは、任意数の規則ツリー３０６を調べ、かつ任意のリファクタリングが望ましいかどうかを決定すべくこれらのツリーを比較することができる。規則ツリーにおける非効率の例は、ある規則ツリー内のある論理条項が幾つかの規則ツリーにおいて反復される場合、またはある規則ツリーがゼロ結果を返す場合、または単一の論理条項を２つ以上の論理条項として書いた方がよい可能性がある場合に発生する。リファクタリングコンポーネント（または、部分）３０９ｂは、規則ツリーにおける論理条項を置換すること、または新しい論理条項を新しい規則ツリーとして書くことの何れかによって非効率を矯正する。分析コンポーネント３０９ａは、冗長性、非効率または不正確さを、規則ツリーにより生成されるテーブルを経験的に精査すること、または規則ツリーを理論的に直接分析すること等の異なる方法で決定することができる。規則ツリーを直接分析することにより、分析コンポーネント３０９ａは、ユーザ規則コンパイラ３１０が規則ツリーを実行しかつデータリポジトリクエリ３１２またはテーブル２１６を作成する必要なしに動作することができる。
【００２５】
図４は、グループ管理エンジンによる分析およびリファクタリングに使用される論理ツリーの例を示す。図４に示されているシーケンスは、分析およびリファクタリングコンポーネント３０８により寄与される既存の規則ツリーに対する潜在的改良を示す。この例において、規則ツリー４００は、接続的に組み合わされる、または互いに「ＡＮＤ」される、即ち、条項「テリトリ＝北西部」４０６が「グループ内販売」と組み合わされ、これらが共に「グループ内コントラクタ」４０４と組み合わされる、３つの論理条項を含む。分析コンポーネント３０９ａは、同じ論理条項４０６および４０８を含む別のグループ、即ち「グループ内北西部販売」４１０（論理は不図示）、が既に存在することを検出する。したがって、リファクタリングコンポーネント３０９ｂは、同じユーザグループテーブル・エントリ（例えば、グループメンバーシップ）をより少ない計算で達成するために、論理条項４０６および４０８をグループ４１０で置換する。
【００２６】
図５は、グループ管理エンジンによる分析およびリファクタリングのためのさらなる論理ツリー例を示す。論理ツリーは、分析およびリファクタリングコンポーネント３０８が非効率を最小限に抑える別の方法を示している。本例において、分析コンポーネント３０９ａは、２つ以上の規則ツリー内に１つまたは複数の論理条項が見出されることを決定している。重複した論理条項は、新しい別々のグループに形成されることが可能である。例えば、規則ツリー５００は、「グループ内コントラクタでない」５０８と接続的に組み合わされる論理条項「マネージャである＝真」５０６を含む。これらは共に、「グループ内北西部販売」５０４と接続的に組み合わされる。分離している別の規則ツリー５０１も、「グループ内コントラクタでない」５１４と接続的に組み合わされる「マネージャである＝真」５１２を含む。これらの規則は、「グループ内エンジニアリング」５１０とさらに組み合わされる。分析コンポーネント３０９ａは、これらの論理条項５０６、５０８、５１２および５１４が異なる規則ツリーにおいて同じ組合せで現出することを検出する。したがって、リファクタリングコンポーネント３０９ｂは、論理条項「マネージャである＝真」５１６および「グループ内コントラクタでない」５１８を包含することによって、マネージャを包含しかつコントラクタを排除する新しいグループを規定する新しい規則ツリー５０２を生成する。リファクタリングコンポーネント３０９ｂは、次に、新しい規則ツリー５００ａを生み出すべく規則ツリー５００において論理条項５０６および５０８を新しい条項「グループ内マネージャ」５２０で置換することにより、かつ同様に、新しい規則ツリー５０１ａを生み出すべく、規則ツリー５０１において論理条項５１２および５１４を新しい条項「グループ内マネージャ」５２０で置換することにより、規則ツリー５００および５０１を新しいグループ５０２へ向けるように修正する。
【００２７】
分析コンポーネント３０９ａおよびリファクタリングコンポーネント３０９ｂが、図２に関連して先に述べたテーブルを生成するために必要な計算の効率を向上させることができる方法は、他にも多く存在する。例えば、分析コンポーネント３０９ａは、おそらくは満たすことが不可能である矛盾した論理条項または論理条項ペア（例えば、「マネージャを包含する」および「マネージャを排除する」）の兆候である、規則ツリーがゼロ結果を返すときを検出することができる。または、おそらくは、論理条項は広範過ぎて、可能性のある全ての結果を含む自明な応答を返す。分析およびリファクタリングコンポーネント３０８は、望ましくない結果を回避するために、または単に実行を追認するために、変更を行う前に管理者へ通知することができる。
【００２８】
図６は、エンタイトルメント管理システムの一実施形態例を用いて実行されることが可能なタスクの概観図である。ＥＭＳ１２０は、６２０において、グループの基準および論理条項を記述することにより、管理者（または他のユーザ）がグループを定義することを可能にする。これは、組織内でのエンティティの役割を基礎として行われることが可能である。定義されると、これらのグループは、６３０においていつでも修正されることが可能であり、かつ変更は、ユーザをグループにマッピングしかつ逆もまた同様のフラットテーブルを生成すべくＥＭＳを介して伝搬する。したがって、管理者は、どのユーザが所定のグループに属するか、または所定のメンバがどのグループに属するかを、いつでもシステムに問うことができる。また管理者は、６４０において、グループのエンタイトルメントを定義し、かつ６５０において、グループのエンタイトルメントを修正することができる。このような変更は、ユーザまたはグループ情報が変更されると発生するプロセスに類似する新しいテーブルの計算を開始する。この計算は、任意の理由で、計算がユーザ、グループまたはエンタイトルメントに変化がない場合に実行されるとしても、結果は適切に変わらないままであることにおいて、冪等であるとされる。さらに、管理者は、ＥＭＳ１２０に、任意の所望される時間に、または新しいグループの追加またはグループもしくはユーザ情報の修正等の任意の所望される入力刺激に応答して、分析およびリファクタリングを実行するように命令することができる。これらのタスクは何れも、任意の順序で、または任意の適切なイベントまたは入力に応答して実行されることが可能である。
【００２９】
動的グループおよびＥＭＳを管理しかつこれに資格付与する技術は、概して任意タイプの組織に適用可能であるが、「コンピュータリソース」という言い回しは、概して、任意タイプのリソースを含意して使用され、よって必ずしもコンピュータリソースに限定される必要はない。本開示による技術、システムおよび方法は、単にコンピュータリソースのみでなく、あらゆるものへのアクセスを認可するために使用されることが可能である。基本的に、記述されている概念および技術は、企業、政府、組織または家庭等の任意の組織に適用可能である。
【００３０】
また、本明細書では、所定の用語が主として使用されるが、他の用語を交替で用いて等価の実施形態および例を生み出す可能性もある。例えば、「コンパイラ」、「データベース」、「データリポジトリ」、「ネットワーク」等といった用語が等価用語で置換される可能性もあることは周知である。具体的に、「コンパイラ」という用語は、「プロセッサ」と交替して使用されることが可能である。さらに、用語は、明示的に言及される場合も、されない場合もある代替綴りを有してもよく、このような用語の変形も包含されることが意図されている。
【００３１】
本明細書に記述される実施形態例は、グループを動的に管理しかつグループに資格付与するために使用されるべきエンタイトルメント管理システムを実装するためのアプリケーション、ツール、データ構造および他のサポートを提供する。記述される技術の他の実施形態は、人間および／またはコンピュータシステム等の人間以外のエンティティのグループを動的に管理する目的を含む他の目的で使用されてもよい。以下の説明では、記述される技術の完全な理解をもたらすために、データフォーマットおよびコードシーケンス等の多くの具体的詳細について述べる。また、記述される実施形態は、本明細書に記述される具体的詳細のうちの幾つかを使用することなく実施されることも、論理、異なる論理などの順序づけに関する変更等の他の具体的詳細を用いて実施されることも可能である。したがって、記述される技術および／または機能の範囲は、任意の具体的なルーチン、モジュール、コンポーネントおよびこれらに類似するものに関連して記述される態様の具体的な順序、選定または分解によって限定されない。
【００３２】
図７は、エンタイトルメント管理システムの実施形態例を実施するためのコンピューティングシステムを示す例示的なブロック図である。本コンピューティングシステムは、ＧＭＥ２００と、ＥＥ２２０と、ＰＥ２４０とを有するＥＭＳ１２０を格納する非一時的メモリを含む。ＥＭＳ１２０の実装には、適切に指示された汎用または専用のコンピューティングシステムが使用され得ることに留意されたい。さらに、ＥＭＳ１２０は、本明細書に記述されるケイパビリティを達成するために、ソフトウェア、ハードウェア、ファームウェアまたは何らかの組合せで実装されてもよい。
【００３３】
コンピューティングシステム７００は、１つまたは複数のサーバおよび／またはクライアント・コンピューティングシステムを備えてもよく、かつ分散されたロケーションをスパンしてもよい。さらに、図示されている各ブロックは、具体的な実施形態にとって適切であるような１つまたは複数のブロックを表してもよく、または他のブロックと組み合わされてもよい。さらに、ＥＭＳ１２０の様々なブロックは、物理的に、規格（例えば、ＴＣＰ／ＩＰ）または独自仕様のプロセス間通信機構を用いて互いと通信する１つまたは複数のマシンに存在してもよい。
【００３４】
図示されている実施形態において、コンピュータシステム７００は、コンピュータメモリ（「メモリ」）７０１と、ディスプレイ７０２と、１つまたは複数の中央処理装置（「ＣＰＵ」）７０３と、入力／出力デバイス７０４（例えば、キーボード、マウス、ＣＲＴまたはＬＣＤディスプレイ、他）と、他のコンピュータ読取り可能媒体７０５と、１つまたは複数のネットワーク接続７０６とを備える。ＥＭＳ１２０は、メモリ７０１内に存在して示されている。他の実施形態において、ＥＭＳ１２０のコンテンツの何らかの部分、コンポーネントのうちの幾つか、または全ては、他のコンピュータ読取り可能媒体７０５に格納されても、前記媒体上で伝送されてもよい。ＥＭＳ１２０のコンポーネントは、好ましくは１つまたは複数のＣＰＵ７０３上で実行され、かつ本明細書に記述されているようなＧＭＥ２００、ＥＥ２２０およびＰＥ２４０を管理する。他のコードまたはプログラム７３０および潜在的にデータリポジトリ７０６等の他のデータリポジトリも、メモリ７０１内に存在し、好ましくは１つまたは複数のＣＰＵ７０３上で実行される。留意すべきこととして、任意の具体的な実装では、図７におけるコンポーネントのうちの１つまたは複数が存在しなくてもよい。例えば、他のソフトウェアに埋め込まれる実施形態の中には、ユーザ入力またはディスプレイのための手段を提供しなくてもよいものがある。
【００３５】
ある典型的な実施形態において、ＥＭＳ１２０は、１つまたは複数のＧＭＥ２００と、１つまたは複数のＥＥ２２０と、１つまたは複数のＰＥ２４０と、例えばユーザデータを有するデータリポジトリ２１８および例えばアプリケーションデータを有するデータリポジトリ２３４である１つまたは複数のデータリポジトリとを含む。実施形態によっては、ＥＭＳ１２０は、他のプログラムがＥＭＳデータにアクセスできるようにするＥＭＳアプリケーション・プログラミング・インタフェース（「ＡＰＩ」）２１９を含む。少なくとも幾つかの実施形態において、ＥＥ２２０またはＰＥ２４０はＥＭＳ１２０の外部に設けられ、かつ潜在的に、１つまたは複数のネットワーク７５０上で利用可能である。また、他のモジュールおよび／または異なるモジュールが実装されてもよい。さらに、ＥＭＳ１２０は、ネットワーク７５０を介して、ＥＭＳ１２０、１つまたは複数のクライアント・コンピューティングシステム７６０および／または１つまたは複数の第三者情報プロバイダシステム７６５により計算されるエンタイトルメントデータまたはグループメンバーシップデータを受信するアプリケーションまたはクライアントコード７５５と相互作用してもよい。同じく留意すべきこととして、ユーザデータリポジトリ２１８またはデータアプリケーション属性マップ２３４もやはりＥＭＳ１２０の外部に、例えば１つまたは複数のネットワーク７５０上でアクセス可能なデータリポジトリ内に設けられてもよい。
【００３６】
ある実施形態例では、ＥＭＳ１２０のコンポーネント／モジュールは、標準的なプログラミング技術を用いて実装される。しかしながら、ＥＭＳ１２０およびその様々なコンポーネントは、動的なプログラミング技術、オブジェクト指向の技術を用いて実装されること、または分散されたコンピューティングモデルにも実装されることが可能である。例えば、ＥＭＳ１２０は、１つまたは複数の静的または動的ライブラリと共に、ＣＰＵ７０３上で実行される「ネイティブ」実行ファイルとして実装されてもよい。他の実施形態において、ＥＭＳ１２０は、仮想マシンにより処理される命令として実装されてもよい。概して、技術上知られるプログラミング言語の範囲は、オブジェクト指向型（例えば、Ｊａｖａ（登録商標）、Ｃ＋＋、Ｃ＃、Ｖｉｓｕａｌ  Ｂａｓｉｃ．ＮＥＴ、Ｓｍａｌｌｔａｌｋおよびこれらに類似するもの）、関数型（例えば、ＭＬ、Ｌｉｓｐ、Ｓｃｈｅｍｅおよびこれらに類似するもの）、手続き型（例えば、Ｃ、Ｐａｓｃａｌ、Ａｄａ、Ｍｏｄｕｌａおよびこれらに類似するもの）、スクリプト型（例えば、Ｐｅｒｌ、Ｒｕｂｙ、Ｐｙｔｈｏｎ、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＶＢＳｃｒｉｐｔおよびこれらに類似するもの）および宣言型（例えば、ＳＱＬ、Ｐｒｏｌｏｇおよびこれらに類似するもの）を含む、但しこれらに限定されない様々なプログラミング言語パラダイムの代表的な実装を含み、このような実施形態例を実装するために使用されてもよい。
【００３７】
また、先に述べた実施形態は、周知の、または独自仕様の同期的または非同期的クライアント−サーバ・コンピューティング技術も用いてもよい。また、様々なコンポーネントが、よりモノリシックなプログラミング技術を用いて、例えば単一のＣＰＵコンピュータシステム上で実行される実行ファイルとして実装されてもよく、あるいは、各々が１つまたは複数のＣＰＵを有する１つまたは複数のコンピュータシステム上で実行される、マルチプログラミング、マルチスレッディング、クライアント−サーバまたはピア・ツー・ピアを含む、但しこれらに限定されない技術上知られる様々な構造化技術を用いて分解されてもよい。実施形態の中には、同時的かつ非同期的に実行され、かつメッセージ転送技術を用いて通信し得るものがある。また、等価の同期的実施形態もサポートされる。また、他の機能が各コンポーネント／モジュールによって実装されかつ／または実行される可能性もあり、かつ異なる順序、および異なるコンポーネント／モジュールであっても、記述されている機能は達成される。
【００３８】
さらに、ＥＭＳ１２０の一部として格納される（例えば、データリポジトリ２１８および２３４内の）データへのプログラミングインタフェースは、Ｃ、Ｃ＋＋、Ｃ＃およびＪａｖａ  ＡＰＩ等を介する規格機構；ファイル、データベースまたは他のデータリポジトリにアクセスするためのライブラリ；ＸＭＬ等のスクリプト言語の使用；またはウェブサーバ、ＦＴＰサーバまたは格納データへのアクセスを提供する他のタイプのサーバの使用によって利用できる可能性がある。データリポジトリ２１８、２３４は、分散コンピューティング技術を用いる実装を含む、１つまたは複数のデータベースシステム、ファイルシステムまたはこのような情報を格納するための他の任意の技術またはこれらの任意の組合せとして実装されてもよい。
【００３９】
また、この例示的なＥＭＳ１２０は、複数の、異種でさえあるコンピュータシステムおよびネットワークを備える分散環境において実装されてもよい。プログラムおよびデータの異なる構造およびロケーションは、本明細書に記述される技術によって使用するように企図されている。さらに、ＥＭＳ１２０の複数の部分は、物理的または仮想コンピューティングシステム上で実行されてもよく、かつ同じ物理システム上に存在してもよい。また、モジュールのうちの１つまたは複数は、負荷バランシング、信頼性または安全上等の理由で、これら自体が分散され、プールされ、またはその他グループ化されてもよい。例示されている実施形態のコンポーネントを分散方式で実装するためには、ＴＣＰ／ＩＰソケット、ＲＰＣ、ＲＭＩ、ＨＴＴＰ、ウェブサービス（ＸＭＬ−ＲＰＣ、ＪＡＸ−ＲＰＣ、ＳＯＡＰ、他）およびこれらに類似するものを含む、但しこれらに限定されない様々な分散コンピューティング技術が適切である。また、他の変形例も可能である。また、各コンポーネント／モジュールによって他の機能性が提供される可能性もあり、または、既存の機能がコンポーネント／モジュール間に異なる方式で分散され、なおもＥＭＳ１２０の機能が達成される可能性もある。
【００４０】
さらに、実施形態によっては、ＥＭＳ１２０のコンポーネントのうちの幾つか、または全ては、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、標準集積回路、適切な命令を実行する、かつマイクロコントローラおよび／または埋込みコントローラを含むコントローラ、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、複合プログラマブル・ロジック・デバイス（ＣＰＬＤ）およびこれらに類似するものを含む、但しこれらに限定されない少なくとも部分的にファームウェアおよび／またはハードウェア等の他の方式で実装または提供されてもよい。また、システムコンポーネントおよび／またはデータ構造の幾つか、または全ては、コンピュータ読取り可能媒体が、記述されている技術の少なくとも幾つかを実行すべくコンテンツを実行またはその他使用または提供できるように、コンピュータ読取り可能媒体（例えば、ハードディスク、メモリ、ネットワーク、他のコンピュータ読取り可能媒体、または適切なドライブにより、または適切な接続を介して読み取られるべき、ＤＶＤまたはフラッシュメモリデバイス等の他の携帯媒体物品）上にコンテンツ（例えば、実行可能または他の機械読取り可能ソフトウェア命令または構造化データ）として格納される場合もある。コンポーネントおよび／またはデータ構造のうちの幾つか、または全ては、有形の非一時的格納媒体に格納されてもよい。また、システムコンポーネントおよびデータ構造のうちの幾つか、または全ても、無線ベースおよび有線／ケーブルベース媒体を含む媒体７０５等の様々なコンピュータ読取り可能伝送媒体上で、発生されるデータ信号を介して（例えば、搬送波または他のアナログまたはデジタル伝搬信号の一部として）非一時的に伝送されてもよく、かつ様々な形式を（例えば、単一または多重化されたアナログ信号の一部として、または複数の離散的デジタルパケットまたはフレームとして）とってもよい。また、このようなコンピュータ・プログラム・プロダクトは、他の実施形態では他の形式をとる場合もある。したがって、本開示の実施形態は、他のコンピュータシステム構造で実施されてもよい。
【００４１】
図１−図６に関連して述べたように、エンタイトルメント管理システムの機能の１つは、ユーザエンタイトルメントデータを生成するためにグループメンバーシップを管理することにある。図８は、ある例示的なグループ管理エンジンにより実行される論理例を示すフロー図である。図８の論理は、例えば、図１および図２に示されているＧＭＥ２００によって実行されてもよい。ブロック８０２において、ＧＭＥは、アプリケーション・エンタイトルメントデータを受信する。エンタイトルメントデータは、誰がどのコンピュータリソースへアクセスする資格を付与されるかを記述してもよい。このエンタイトルメントデータは、特定のユーザに関連づけられなくてもよいが、どちらかと言えば、アプリケーションがどのデバイスで、一時に何名のユーザで、何時間に亘って実行されることが可能であるか、等の特性として表現されてもよい。また、エンタイトルメントデータは、資格付与された関係者がサブスクリプションまたはライセンス等によってリソースに、いつ、どのように、かつどのくらいの時間に亘ってアクセスできるかも決定することができる。
【００４２】
ブロック８０４において、ＧＭＥは、グループ定義を受信する。グループ定義は、所定のメンバ候補がグループの一部となるために満たされなければならない１つまたは複数の論理条項を含んでもよい。グループ定義は、先に述べたように、論理条項の任意の適切な組合せおよび／またはこれらの組合せであってもよい。グループ定義は、組織に対するエンティティの役割によって相関されることが可能であり、これは単に、問題のコンピュータリソースがエンティティのその役割を実行する能力に関連する場合にマネジメントにより定義されてもよい。しかしながら、グループ定義は、あらゆる任意の基準であることが可能である。
【００４３】
ブロック８０６−８２０は、ユーザおよび／またはグループデータの変更を処理するために必要なだけ反復されることが可能なループを規定している。ブロック８０６において、ＧＭＥは、グループ組成論理規則を基礎として１つまたは複数のクエリを生成する。この論理部分は、図３に関連して先に述べたように、グループ定義コンパイラ３０４によって実行されることが可能である。
【００４４】
ブロック８０８では、グループ定義の論理条項がメンバ候補（エンティティ候補）に対して実行される。即ち、どの候補がグループ組成規則を満たしているか、または包含リストに含まれ、かつ排除リストに含まれていないかを決定するために、各候補の属性がグループの論理条項と比較される。この処理の結果、各グループにおけるメンバリストに単純かつ効率的にアクセスするために使用されることが可能なフラットテーブルのデータ構造（または等価物）を生成すべく、ＳＱＬデータベースクエリ等のデータベースクエリが生成される。
【００４５】
ブロック８１０では、データベースクエリが実行され、テーブルが生成される。テーブルは、各グループにおけるメンバを単に列挙するフラットテーブルであることが可能である。これらのテーブルは、次に、コンピュータリソースへのアクセス試行に応答して、グループ組成論理規則を計算する必要なしにグループ内のメンバの検索に使用されることが可能である。テーブルが生成されると、これは、どのエンティティが所定のグループのメンバであるかを識別する、または所定のエンティティがどのグループに属するかを識別するために、容易かつ迅速に使用されることが可能である。
【００４６】
ブロック８１２において、論理は、ユーザが組織から退職する、または辞める場合等、ユーザデータが変わっているかどうか、またはグループ内のメンバーシップを規定する１つまたは複数の論理条項に対するユーザのステータスを変える他の任意の変更を決定する。変更が行われると、ブロック８１４において、論理はユーザ属性データを更新し、かつ、テーブル生成のし直しを含むブロック８０６でループ再開を論理に命令する。変更が発生していなければ、ブロック８１６において、論理は、「上級」従業員グループの定義を「３年の経歴を有する者」から「４年の経歴を有する者」に変更すること等、グループ情報に、グループにおける一人または複数のエンティティのメンバーシップに影響する変化があったかどうかを決定する。変化があれば、論理はブロック８１８へと続き、なければブロック８２０へと続く。ブロック８１８において、論理はグループ定義を更新し、かつ論理にブロック８０６でループを再開するように命令する。実施形態によっては、このループは、ユーザのステータスまたはグループのステータスの変更の受信に応答して始めることができる。
【００４７】
ユーザまたはグループに変更が生じていなければ、ブロック８２０において、論理は、ユーザのステータスまたはグループのステータスの変更等の追加入力を待機する。
論理は、ユーザまたはグループ情報に対する変更の有無に関わらず、テーブル内の情報を更新または計算し直す要求に応じてもよい。論理は、これらの再計算が冪等であり、よって、情報に変更がない限り、テーブルの再計算（または継続的計算）にはほとんど計算コストがかからないように構造化されることが可能である。実施形態によっては、テーブルの再計算は、リアルタイムで約１秒未満で発生することが可能であり、情報が同期外れになる時間は最小限に抑えられる。情報の変更に応答して、論理は、テーブル全体を再計算する、または単にテーブルの影響される部分を再計算することができる。実施形態によっては、論理は、テーブルを周期的に再計算するように命令されることが可能である。論理が配備される組織に依存して、テーブルを再計算する周期は変わってもよい。例えば、頻繁なアクセス要求および頻繁なユーザおよび／またはグループ変更を受信する大規模環境では、テーブルは、頻繁な再計算を必要とする場合がある。
【００４８】
同じく図１−図６に関連して述べたように、ＥＭＳは、さらなる効率を生み出すために分析およびリファクタリングコンポーネントを含んでもよい。図９は、あるエンタイトルメント管理システムの例示的な分析およびリファクタリングコンポーネントにより実行される論理例を示すフロー図である。図４および図５に関連して述べたように、論理は、非効率、コンフリクトまたは不正確さを最小限に抑えるために、グループ定義を分析しかつリファクタリングすることができる。図９の論理は、例えば図３における分析およびリファクタリングコンポーネント３０８によって、グループ定義を改善する必要性の決定に応答して、または周期的な保全チェックを実行するために実行されることが可能である。
【００４９】
ブロック９０４において、論理は、ＧＣＲ、包含リストおよび排除リストを含むグループ定義を調べる。ＧＣＲは、１つまたは複数の他のグループにおけるメンバーシップを基礎とする規則を含むことが可能である。
【００５０】
ブロック９０６において、論理は、所定の論理条項が過剰に使用されているか否かを決定する。２つ以上のグループ定義においてこの論理条項が現出すれば、または、この論理条項が同じグループ定義における１つまたは複数の他の論理条項と重なって冗長であれば、これに該当する可能性がある。該当すれば、論理は、ブロック９１４においてグループ定義をリファクタリングする。該当しなければ、論理はブロック９０８へ続く。
【００５１】
ブロック９０８において、論理は、論理条項が所定の時間期間に亘って呼び出されず、グループを他の論理条項を用いて形成することができるかどうか等、所定の論理条項の使用が少ないか否かを決定する。該当すれば、論理は、ブロック９１４においてグループをリファクタリングする。該当しなければ、論理はブロック９１０へ続く。
【００５２】
ブロック９１０において、論理は、所定の論理条項がゼロ結果または可能性がある全ての結果を返すか否かを決定する。多くの場合、可能性がある全てのエンティティまたはゼロエンティティを返す論理条項は、論理的不一致または間違いの兆候である。該当すれば、論理は、ブロック９１４においてグループ定義をリファクタリングする。該当しなければ、論理はブロック９１２へ続く。
【００５３】
ブロック９１２において、論理は、所定の論理条項の精度を決定する。論理条項が、あらゆる理由で不測の結果をもたらせば、これは、不正確の一例である可能性がある。複数のグループ依存性および相互参照メンバーシップ規則を含む複合的な規則スキームは、意図的でないメンバーシップまたは削除を引き起こす場合がある。例えば、所定のグループにおけるメンバーシップが別のグループにおけるメンバーシップの基準であれば、グループ定義の実行順序は、メンバーシップに影響する場合がある。そうであれば、論理は、ブロック９１４においてグループ定義をリファクタリングする。分析およびリファクタリングプロセスの一部は、グループ定義を様々な順序で実行しかつ結果を比較するためのものである可能性がある。不正確さが見出されなければ、論理はブロック９１６へ続く。
【００５４】
ブロック９１６において、論理は、グループ定義に対し、所定の組織または実装により所望される通りの他の任意の適切なチェックを実行する。何か問題が発見されれば、論理は、ブロック９１４でリファクタリングすることができる。さらなる問題が発見されなければ、論理は、ブロック９２０へ進む。
【００５５】
論理がブロック９１４でグループ定義をリファクタリングすると、ブロック９２０において論理は終了する。
論理またはその任意の部分は、任意の順序で実行されることが可能である。論理は、事実上任意の測定可能なイベントに応答して、または任意の、または決定されたスケジュールに従って始めることができる。
【００５６】
図１０Ａおよび図１０Ｂは、あるエンタイトルメント管理システム例の例示的なデータフローを示す。ある例示的な実施形態において、ＥＭＳ１２０の様々なコンポーネントのデータは、表１に記述されているように格納されることが可能である。
【００５７】
【表１】
0005993938.tif 000002
ＥＭＳ１２０の例示的な一実施形態において、持続的計算データは、表２に記述されているように格納される場合もある。
【００５８】
【表２】
0005993938.tif 000003
データは、エンタイトルメントおよびプロビジョニングシステムから一連の同期（ｓｙｎｃ）プロセスを介して流れることができる。ｓｙｎｃプロセスは、そのソーステーブルの変更を検索して宛先テーブルを更新する単一スレッドオペレーションである。ｓｙｎｃプロセスには、次の３つがある。
【００５９】
【表３】
0005993938.tif 000004
あるＥＭＳ例において、各ｓｙｎｃプロセスは、ほぼ同様に動作する。即ち、（１）これは、おそらくは複数のマシン上の（例えば、ｊａｖａプロセスにおける）タイマ上で実行され、かつ（２）（どのｓｙｎｃプロセスが事実上同期を実行すべきかを決定するために）起動し、かつどのインスタンスを発見するかのリーダ選挙に参加する。「リーダ」は、次に、ソーステーブルにおける変更を探し、かつこれを、ターゲットテーブルへの変更生成を担当するコアキャッシュサービサへ入力する。最終更新時間は、グローバル・コンフィギュレーション・パラメータとして格納され、かつｓｙｎｃオペレーションが首尾よく完了したときにのみ更新される。
【００６０】
ユーザグループ同期プロセス（１０１０）は、２つの入力テーブル、即ちユーザおよびグループテーブルを観察する。ある実施形態例では、ユーザグループ同期が、ユーザグループ１０１２テーブルに書込みをする唯一のプロセスである。また、ある実施形態例において、ユーザグループ１０１２テーブルへの書込みは、ユーザグループ同期プロセス（１０１０）の唯一の副次的効果である。下表４は、特有のイベントがユーザおよび／またはグループ入力テーブルに影響を与える場合に生じる作用を示す。
【００６１】
【表４】
0005993938.tif 000005
エンタイトルメント同期プロセス１０１４は、４つの入力テーブル、即ち（１）ユーザグループ１０１２、（２）アプリケーションエンタイトルメント１０２０、（３）アクティブサービス１０２４および（４）ユーザ認証データ１０２２、を（指定の順序で）観察する。ある実施形態例において、エンタイトルメント同期プロセス１０１４は、ユーザエンタイトルメント１０２６テーブルへ書き込む唯一のプロセスである。また、ある実施形態例において、ユーザエンタイトルメント１０２６テーブルへの書込みは、エンタイトルメント同期プロセス１０１４の唯一の副次的効果である。
【００６２】
実施形態によっては、ユーザ認証データ１０２２は精査されるべき最後のテーブルであり、よって、同じ同期周期において起動およびエンタイトルメントが発生しても、これらは正しい順序で処理される。別の実施形態において、エンタイトルメント同期プロセス１０１４は、エンタイトルメント同期プロセス１０１４および起動同期プロセスの２つの部分で実装される。下表５は、特有のイベントがエンタイトルメント同期プロセス１０１４への入力テーブル（１０１２、１０２０、１０２４および１０２２）に影響を与える場合に生じる作用を示す。
【００６３】
【表５】
0005993938.tif 000006
システムの設計は、故障に対して回復力があることが意図されている。ユーザに関連するテーブルの修正は、データベースのトランザクションにおいて発生する単純なオペレーションであることが可能である。計算されたデータテーブルの更新は、周期的に発生する冪等演算である。これは、これらを同期外れにする任意の故障、例えばコードエラー、大規模な使用率のスパイク、データベースのクラッシュ／破損が、同期プロセスを再度実行することによって補正され得ることを意味する。
【００６４】
ある実施形態例において、下表６に示されているような関係性は、システムのセキュリティの一部である。
【００６５】
【表６】
0005993938.tif 000007
以下、発生すると状態間の遷移を生じさせ得るエンタイトルメントおよびユーザベース・オペレーションの異なる状態のうちの幾つかに関して説明する。これらの状態は、下記の異なる３フィールドを介して管理されることが可能である。
（１）アクティブサービス・ステータスは、あるアプリケーションが、ある組織に関してアクティブであるか否かを記述する。これは、アクティブサービス１０２４（ｉｄＳｅｒｖｉｃｅＳｔａｔｕｓ）からもたらされる。
（２）エンタイトルメント状態は、あるアプリケーションが、あるユーザに資格付与されているか否かを記述する。この情報は、ユーザグループ１０１２、ユーザ１０１６およびアプリケーションエンタイトルメント１０２０の各テーブルから計算される。
（３）起動状態は、あるユーザが、あるアプリケーションへの予約を実際に有するべき者であるか否かを記述する。この情報は、ユーザ認証データ１０２２テーブルからもたらされる。
【００６６】
これらの状態は、管理者による操作およびユーザによる操作の双方を介して変更されることが可能である。下記のテーブルは、（１）これらの状態の各々、およびその意味するものを記述し、（２）これらの状態を変更する管理者＋ユーザによる操作を記述し、（３）これらの変更をシステムアーキテクチャのコンテキストで管理するために使用されるプロセスを記述し、かつ（４）（これらの状態変更のプロセスの何れをも記述することなく）ワークフローと統合するための状態モデルへの拡張を記述する。
【００６７】
アプリケーションおよびエンタイトルメント状態遷移は、グローバル状態を、ユーザ操作に直に一致する次の３つの十分に定義された状態に分解するように設計される。
（１）起動サービスステータスは、管理者によって管理される。このステータスは、アプリケーション追加／排除オペレーションによって制御される。
（２）エンタイトルメント状態は、管理者によって管理される。これは、アプリケーションエンタイトルメントの修正によって制御される。
（３）起動状態は、ユーザによって管理される。これは、ユーザに資格付与されるアプリケーションを起動または停止することによって制御される。
【００６８】
これらの状態は、ワークフローと統合すべく状態を追加するように拡張可能である。
ある実施形態例の場合、状態概観は、表７に示されている通りである。
【００６９】
【表７】
0005993938.tif 000008
アクティブサービス・ステータスは、あるアプリケーションが、ある組織に関して起動されるか否かを記述する。ある実施形態例では、同期スレッドではなく、要求スレッドのみがこの状態を設定すべきである。あるアプリケーションに対してアクティブサービスを有していない組織は、あるアプリケーションに対して停止されたアクティブサービスを有する組織と意味的には同じであるべきである。
【００７０】
アクティブサービス・ステータスでのオペレーションを図８に示す。
【００７１】
【表８】
0005993938.tif 000009
アクティブサービス・ステータスの状態を表９に示す。
【００７２】
【表９】
0005993938.tif 000010
エンタイトルメント状態は、アプリケーションエンタイトルメント１０２０、ユーザグループ１０１２およびユーザ１０１６の各テーブルを基礎とする、あるユーザのエンタイトルメント状態である。アプリケーションエンタイトルメントにおけるエンタイトルメント構造内の起動ポリシは、あるエンタイトルメントが「ユーザ」であるか、「オート」であるかを決定する。これが「ユーザ」であれば、ユーザは、例えば入力デバイスでアイコンをダブルクリックすることによって、ユーザに資格付与されるアプリケーションを立ち上げる時を指示する。これが「オート」であれば、システムは、ユーザがログインした時点でアプリケーションを立ち上げてもよい。エンタイトルメント状態「なし」の保有は、弊システムでは、ユーザエンタイトルメント・レコードを保有しないことによって表される。起動ポリシには、明示的な「なし」状態は存在しない。ある実施形態例では、同期スレッドではなく、要求スレッドのみがアプリケーションエンタイトルメント１０２０テーブルの変更を行うべきである。
【００７３】
エンタイトルメント状態でのオペレーションを表１０に示す。
【００７４】
【表１０】
0005993938.tif 000011
エンタイトルメント状態の状態を表１１に示す。
【００７５】
【表１１】
0005993938.tif 000012
起動状態は、あるエンタイトルメントが「起動される」か否かを記述する。これは、プロビジョニングオペレーションおよび予約情報の「期待状態」として作用する。起動状態が起動されると、アプリケーションには予約パラメータが供給されているはずである。これは、適切なパラメータが記入されているかどうかを基礎として、いつプロビジョニングされてもよい。起動状態が起動されない場合、アプリケーションは予約パラメータを、それが以前に起動されていれば関連づけさせてもよい。アプリケーションは、デプロビジョニングされるか、デプロビジョニングのプロセス中であるかの何れかであるものとする。起動状態が削除されると、アプリケーションには予約パラメータが関連づけられないものとする。以前に起動されていれば、そのパラメータは消去されるものとする。
【００７６】
起動状態でのオペレーションを表１２に示す。
これらは、起動状態に直接影響するオペレーションである。結果的に、例えばある組織に関するアプリケーションを無効化して起動状態を変えさせるオペレーションには、先に挙げた幾つかのものが存在する。
【００７７】
【表１２】
0005993938.tif 000013
起動状態の状態を表１３に示す。
【００７８】
【表１３】
0005993938.tif 000014
２０１１年４月３０日に提出された暫定特許出願第６１／４８１，１８４号を含む、但しこれに限定されない、本明細書において言及されかつ／または申請形式で挙げられている上述の米国特許、米国特許出願公開公報、米国特許出願、外国特許、外国特許出願および非特許刊行物は全て、本参照により、その全体が開示に含まれる。
【００７９】
これまでの説明から、本明細書では、例示を目的として特有の実施形態が記述されているが、本発明の精神および範囲を逸脱することなく様々な修正が行われてもよいことは認識されるであろう。例えば、本明細書において論じている動的なグループ管理を実行するための方法およびシステムは、コンピュータリソース・アーキテクチャ以外の他のアーキテクチャに適用可能である。例えば、エンタイトルメントは、施設または組織特権等の他のリソースに関連してもよい。また、本明細書において論じている方法およびシステムは、異なるグループ管理プロトコル、通信媒体（光学的、無線式、ケーブル、他）およびデバイス（無線ハンドセット、電子オーガナイザ、パーソナル・デジタル・アシスタント、携帯電子メールマシン、ゲームマシン、ページャ、ＧＰＳ等のナビゲーションデバイス、受信機、他等）へ適用可能である。
【図１】
0005993938.tif 000015
【図２】
0005993938.tif 000016
【図３】
0005993938.tif 000017
【図４】
0005993938.tif 000018
【図５】
0005993938.tif 000019
【図６】
0005993938.tif 000020
【図７】
0005993938.tif 000021
【図８】
0005993938.tif 000022
【図９】
0005993938.tif 000023
【図１０Ａ】
0005993938.tif 000024
【図１０Ｂ】
0005993938.tif 000025