JP2005503596A - リソース共有システムと方法 - Google Patents

リソース共有システムと方法 Download PDF

Info

Publication number
JP2005503596A
JP2005503596A JP2002561749A JP2002561749A JP2005503596A JP 2005503596 A JP2005503596 A JP 2005503596A JP 2002561749 A JP2002561749 A JP 2002561749A JP 2002561749 A JP2002561749 A JP 2002561749A JP 2005503596 A JP2005503596 A JP 2005503596A
Authority
JP
Japan
Prior art keywords
user
resource
information
resources
sharing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2002561749A
Other languages
English (en)
Other versions
JP2005503596A5 (ja
Inventor
トニー ジェイ グロッタ
ジェフリー エス ボウレン
リアントン チェン
ジェフリー シー キューリー
カイ ミルデンベルゲール
フランク ジュニア イエイ
ラルフ エム アルヴァレス
トッド エム ケニヨン
アン キャサリーン バレッタ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/772,486 external-priority patent/US6985955B2/en
Priority claimed from US09/774,265 external-priority patent/US6947989B2/en
Priority claimed from US09/800,098 external-priority patent/US6871232B2/en
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2005503596A publication Critical patent/JP2005503596A/ja
Publication of JP2005503596A5 publication Critical patent/JP2005503596A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

ユーザへのリソース共有のためのシステムと方法が開示される。この方法には、一連の属性、組織情報、ユーザの役割を確立するステップと、選択された属性、組織情報、ユーザの役割に基づいて複数のリソース共有方針を定義するステップを含む。このステップはまた、特定のユーザまたはリソースに関する属性情報とユーザの役割情報を受け取るステップと、受け取ったユーザ役割情報、組織情報、属性情報に基づいて、そのユーザにはどのリソース共有方針が適当であるかを判断するステップと、適当なリソース共有方針に従い、必要に応じて第三者にその他の情報または許可を求めるステップと、適当なリソース共有方針によって特定されるリソースをユーザに割り当てるステップを含む。リソースは、第三者リソース共有管理（ＲＰＭ）サービスプロバイダを介して、中央から割り当てることができる。リソースには、たとえば、電話、コンピュータ、机等の「ハード」のリソースと、たとえば、電子メールおよびボイスメールアカウント、インターネット等の「ソフト」のリソースがある。さらに、ユーザには「ハード」も割り当てられる。さらに、ユーザには、リソースのバンドルも割り当てられる。また、ＲＰＭシステムから管理されたリソースにアクセスするためのエージェントの効率的な開発を可能にするツールキットを生成するシステムと方法も含まれる。

Description

【技術分野】
【０００１】
本発明は、一般にユーザアカウントとリソースの管理に関し、好ましい実施形態において、方針、役割、組織情報、属性、許可または他のユーザからの情報に基づいてユーザへのリソース共有（provision）を行うためのシステムとプロセスに関する。
【背景技術】
【０００２】
通信ネットワークの一般的な用途は、ネットワークに接続されたストレージシステムまたはデータベースに含まれるソフトウェア、電子データまたはファイル等のネットワークリソースへのアクセスをユーザに提供することである。ひとつのネットワーク上のユーザ数が増えると、そのネットワーク上のリソースへのユーザのアクセス権を管理する必要がしばしば生じる。ネットワーク環境にはさまざまなネットワークユーザが関与する場合が多く、ユーザは、それぞれがその環境において有する関係や役割によってグループ分け、あるいは分類される。たとえば、エンジニアリングまたは技術開発会社の環境の場合、その会社のコンピュータネットワークのユーザには、会社の役員、取締役、エンジニア、技術支援スタッフ、オフィス支援スタッフ、経理部門のスタッフ、情報テクノロジー（ＩＴ）部門のスタッフ、契約業者、コンサルタント、短期従業員その他、関係または役割ごとにグループ分けまたは分類されるネットワークユーザが含まれる。その他の会社、組織またはネットワーク環境には、また別の関係または役割に基づくユーザグループがある。
【０００３】
各ユーザには、本人の関係や役割に応じた特定のネットワークリソースにアクセスする必要性がある。さらに、たとえばセキュリティ、プライバシー保護等の理由により、特定の関係や役割を有するユーザを特定のリソースにアクセスさせないよう制限することが好ましい場合がある。ネットワーク環境に応じて、その環境におけるユーザの関係または役割に基づき、他のタイプのリソースをユーザに割り当てる（あるいはそのユーザによるアクセスを制限する）こともある。
【０００４】
たとえば、上述のエンジニアリングまたは開発会社の環境において、ユーザには、役割やその会社との関係に基づいて、電話、電話アカウント、コンピュータ、インターネットアカウント、電子メールアカウント、オフィス機器および補給品、研究室またはエンジニアリング関連設備と補給品またはその他のリソースが割り当てられる。一部のネットワークリソースは、ユーザのローカルエリアネットワーク（ＬＡＮ）または「イントラネット」に接続された１台または複数のコンピュータシステムによって提供される。たとえば、ＬＡＮ上のコンピュータシステムはサーバとして機能し、ＬＡＮユーザにそのサーバが提供するソフトウェア、電子データ、ファイルその他のネットワークリソースにアクセスさせる。
【０００５】
そのほかの割当可能リソースとしては、インターネットのように、ワイドエリアネットワーク（ＷＡＮ）を通じてユーザまたはＬＡＮに接続された遠隔コンピュータシステムから利用できる管理されたサービスもある。たとえば、データベース、電子メールシステム、金融サービス等の管理されたサービスは、インターネット接続を通じてユーザに提供される。インターネット環境の成長に伴い、インターネット上では多種多様な管理されたサービスのリソースを利用することが可能となっており、今後もさらに可能となる。
【０００６】
たとえば、データベース等のリソースは、米国特許商標局が提供、維持する検索データベースに代表されるように、インターネット上で一般的に利用できる。インターネット上では上記以外のデータベースやその他のタイプのリソースがサービス会社によって提供、維持され、サービス会社はそのリソースを使用する権利の代金を加入者に請求する。このようなサービス会社は一般に、リソースと同じサイトにあるコンピュータ上で実行するソフトウェアであるアカウントエージェントを利用して、リソースのユーザのためのユーザアカウントを管理する。こうしたアカウントエージェントの一例が、本発明の譲受人であるカリフォルニア州アービンのＡＣＣＥＳＳ３６０が製造したenRole（商標）である。
【０００７】
ＬＡＮ上のユーザは、たとえばＬＡＮまたはそのユーザのコンピュータを直接インターネットに接続するインターネット接続を通じてこれらのリソースにアクセスできる。ＬＡＮを、他のＬＡＮや遠隔データベースのような外部リソースに連結する接続手段は、ブリッジ、ルータ、ゲートウェイと呼ばれる。ブリッジは２つ以上のＬＡＮの間で情報を伝達する。ルータは、プロトコル情報を解釈し、利用可能な効率的ルートによってパケットを異なるＬＡＮまたはＷＡＮ接続に選択的に伝送することにより、ＬＡＮをより大きなＬＡＮまたはＷＡＮに接続する。ゲートウェイは、異なる通信プロトコルを使用するネットワーク間の接続、変換を行う。
【０００８】
ＬＡＮコンピュータは通常、ゲートウェイまたはルータを使ってインターネット等のＷＡＮに接続する。しかしながら、このような接続はＬＡＮにとってセキュリティ上のリスクとなりうる。ＬＡＮ上でインターネットから受け取るアプリケーション、ファイルまたはその他の情報にコンピュータウィルスが含まれるかもしれない。さらに、このような接続は、インターネットユーザに対し、ＬＡＮ上の機密ファイルへの不正なアクセスを得るルートを提供する可能性がある。したがって、ファイアウォールと呼ばれる特定のタイプのゲートウェイを使い、ＬＡＮ上のリソースへの不正アクセスを禁止しながら、許可を受けたＬＡＮユーザにＷＡＮ上のリソースへアクセスさせる。ファイアウォールはまた、ＬＡＮへのウイルスの侵入を検出し、禁止することもできる。ファイアウォールは、ＷＡＮへのＬＡＮのゲートウェイとして機能するコンピュータ上、またはＬＡＮとＷＡＮの間に設置された専用コンピュータ上で実行するソフトウェアである。ファイアウォールデバイスは、ハードウェア、ファームウェアあるいはソフトウェア、ハードウェア、ファームウェアの組み合わせでも構成できる。
【０００９】
従来のシステム環境の一例が先行技術の図１８に示されており、同図では、データベースとして描かれているリソース９００が、リソースエージェント９０２とファイアウォール９０４を通じてインターネット９０６に接続される。ユーザＵ１，Ｕ２もインターネットに接続されている。他のユーザＵ３，Ｕ４は、ゲートウェイコンピュータＧ１を介してインターネットに接続されるＬＡＮにおいて接続されている。同図には示されていないが、各ユーザとゲートウェアにはそれぞれのファイアウォールを備えてもよい。
【００１０】
図１８の例において、リソース９００には、料金を支払う加入者等、許可を受けたユーザがアクセスできる。リソースエージェント９０２は、パスワード、個人識別情報、アクセス権情報をはじめとする許可を受けたユーザに関する情報を記憶し、データベースへのアクセスを管理して、許可を受けたユーザにはデータベースにアクセスさせ、無許可のユーザによるデータベースへのアクセスを禁じる。リソースエージェント９０２はアクセス権を提供し、保守するため、エージェントはリソース９００のあるサイト等、ユーザに関して安全なロケーションに配置される。
【００１１】
多くの企業や組織において、会社の社員、企業に顧客、組織のメンバーといったユーザグループにリソース９００へのアクセス権を提供することが望ましい。たとえば、エンジニアリング会社の場合、その技術部門の社員一人一人のためにデータベースサービスを提供するユーザアカウントを開き、技術データまたは技術関連記事のデータベースへのアクセスを認めてもよい。
【００１２】
あるいはまた、エンジニアリング会社は会社の各社員のために電子メールを提供するユーザアカウントを開くこともできる。このような例の場合、リソース９００は技術的データベースまたは電子メールサービスデータベースと考えることができる。
【００１３】
パスワード、個人識別情報、アクセス権情報等、各ユーザに関連する情報は、前述のように、リソースエージェント９０２によって記憶、維持される。しかしながら、時間が経過すると、ユーザの役割や状態が変化する可能性がある。上記のエンジニアリング会社の例でいえば、何人かの社員が退職し、何人かが新規に採用され、また何人かの社員は異なる技術関連のポストに配置換えされるであろう。このような社員の役割または状態の変化により、リソースエージェントが維持するアカウント情報を変える必要が生じる。たとえば、ある社員がそのエンジニアリング会社を退社すると、その社員に関するアカウントはキャンセルされる。新規社員が採用されると、新たなアカウントが追加される。社内における社員の役割や状態の変化により、そのアクセス権も変化する。もちろん、リソースエージェント９０２に、これらの社員に関する変化を知らせ、そのアカウントを更新する必要がある。会社または組織によっては、ユーザの役割または状態は頻繁に変化するため、リソースエージェント９０２が維持するユーザアカウントを更新のための通信がしばしば必要となる。これらの更新が正確かつタイミングよく伝えられ、導入されないと、その内容に応じてさまざまな問題が生じる。
【００１４】
たとえば、元社員に関するユーザアカウントが速やかにキャンセルされないと、その元社員は会社を辞めた後にも機密情報にアクセスできてしまう。また、新規社員のユーザアカウントが速やかに追加されないと、その新規社員は、仕事の上で必要な重要なリソースにアクセスできない。会社がその社員に提供するリソースの数とアクセス権の異なる社員の数が増えると、社員の役割または状態の変化によって影響を受ける各リソースに関するアカウント情報変更を伝えるタスクは膨大なものとなる。
【００１５】
従来の企業または組織の多くにおいては、特定の担当者がその役割に応じたユーザの共有業務を行う。たとえば、オフィス管理者は、その組織に新たなユーザが加わった日に、コンピュータ、電話、ボイスメール、電子メールおよび特定のアプリケーションとデータベースを利用可能な状態にするよう組織のＩＴ部門に対して注文を出す。すると、ＩＴ部門の担当者はこれらのリソースを手作業でセットアップする。他のオフィス担当者は倉庫から机、椅子、キャビネットを出してそのユーザのオフィスをセットアップする。そのうちに、組織内でのそのユーザの関係または役割は、たとえば、本人の転籍、昇格、降格、解雇等、変化するかもしれない。組織とユーザとの関係または役割が変化すると、そのユーザがリソースにアクセスする必要性やアクセス権も変化するであろう。
【００１６】
上記のような例においてオフィス管理者やオフィス担当者がリソースへのユーザのアクセスを手作業で管理する負担は通常、組織の規模（ユーザ数）と組織におけるユーザの出入りその他役割の変化の頻度に応じて異なる。オフィス管理者とオフィス担当者の作業を効率化し、その負担を軽減するために、特定の、限られたタイプのリソースのユーザへの共有に関する作業の一部を自動化または一部自動化するソフトウェアアプリケーションを使用している組織がある。
【００１７】
Ｒｏｌｅ Ｂａｓｅｄ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＲＢＡＣ）は、市販されているＬＡＮベースの自動共有の一例である。ＲＢＡＣは、個人の組織における役割に基づき、ネットワーク上で利用できる特定アカウント（ファイル、ウェブページ等）へのアクセス許可（アクセス権）をユーザに提供する。たとえば、ファイルまたはフォルダはその制作者だけが見られるようにすることも、あるいはそのファイルまたはフォルダについて確立された許可権に応じて、組織のネットワークを通じ、より大きなユーザグループにとってアクセス可能とすることもできる。
【００１８】
従来のＲＢＡＣシステムにおいて、これらの許可は、組織内の個人の役割に基づいて与えられる。しかしながら、現代の組織はいくつかの共通集合に沿って構成されている。たとえば、組織は役職（社長、副社長、取締役、部門長、監督等）、テクノロジー（電子、機械、ソフトウェア等）、プロジェクト（製品Ａ，Ｂ，Ｃ等）、場所（アービン、ニューヨーク等）その他に沿って構成される。一人のユーザがこれらの組織構造のうちのいくつかまたは全部に現れ、組織内の他のユーザと比較し、固有と思われる全体的役割を担うこともある。これにより、多くのユーザへの固有の共有が必要となるため、そのような共有を自動化するためには、システム内で多くの固有の役割を定義しなければならない。
【００１９】
さらに、従来のＲＢＡＣは、電話、コンピュータ、机といった「ハード」のリソースに対して、アカウント、アプリケーション、データベース、ファイル、ウェブページ等、「ソフト」のリソースのみの共有を行う。特定の、限定されたタイプのリソースをユーザに割り当てることに関する作業の一部を自動化または一部自動化するソフトウェアアプリケーションは、予め設定した基準に従ってリソースをユーザに割り当てるための通信ネットワーク上で運用できる。このようなソフトウェアアプリケーションを利用するシステムを、ここでは一般にＲｅｓｏｕｒｃｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｍａｎａｇｅｍｅｎｔ（ＲＰＭ）システムと呼ぶ。
【００２０】
第三者サービスプロバイダまたは第三者が管理するサービス（一般に、管理されたリソースという）は、人が管理されたリソースに変更を加えることのできるユーザ管理コンソールを用意しているかもしれないが、このコンソールやインタフェースはＲＰＭシステムと相互運用できない可能性がある。このため、ソフトウェアエージェントをＲＰＭシステムと管理されたリソースとの間の変換手段として利用する場合がある。エージェントは基本的に、人による介入を同じ機能を実行する自動ステップに置き換えるものである。
【００２１】
エージェントはＲＰＭシステムからのメッセージまたはリクエストを受け取り、そのリクエストを管理されたリソースのＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）とインタフェースできるコードに変換することができる。管理されたリソースがリクエストの特定の機能を実行した後、管理されたリソースはエージェントに数値を伝え、次にエージェントがその数値をＲＰＭシステムに戻す。
【００２２】
時々、ＲＰＭシステムの実現には、一部の会社または組織にとってコスト面で利用不能なリソースが必要となる。ＲＰＭシステムの実現には通常、システムサーバ、端末、システムソフトウェア、エージェントおよび通信ネットワークに関連するその他のアイテムが必要である。これらのアイテムの費用は膨大で、数万から数十万ドルかかる。このような費用は、中規模の会社や組織にとって圧倒的であり、このためにＲＰＭシステムの取得や導入が手の届かないものとなっている。
【００２３】
また、ＲＰＭシステムを導入する場合、担当者がシステムの操作に専念しなければならないのが普通である。このための担当者を採用し、訓練するのに必要な費用と関連諸掛りが、一部の会社や組織にＲＰＭシステムの導入を断念させている。このように、ＲＰＭサービスの現実的な代用品がなければ、こうした会社や組織はＲＰＭシステムの恩恵を受けることができない。
【００２４】
ＲＰＭシステムの取得と導入のための資源を持たない、あるいはその他の理由でこれを断念した会社その他の組織は、ＲＰＭシステムのプロバイダとなる第三者から大いに恩恵を受ける。しかしながら、現在のところ、第三者のＲＰＭサービスを提供するシステムと方法が存在しない。一般に、ＲＰＭシステムと方法はこれまで、企業またはアプリケーションサービスプロバイダの環境においてリソースを利用する組織内で導入されてきた。第三者のＲＰＭサービスプロバイダを利用する会社や組織が共有されるリソースを社内または組織内で共有できれば、非常に大きな利益を享受できる。このような関連会社内での共有により、コスト削減と管理の効率化が実現する。しかしながら、繰り返しになるが、現時点では、第三者のＲＰＭサービスプロバイダを利用する関連会社または組織間でリソースを共有するメカニズムが存在しない。ＲＰＭ分野全般についての公共インフラストラクチャも必要である。リソース共有が必要となったときに一般民衆が利用するアイデンティティ、エンタイトルメント、方針、役割等の共有サービスを提供する第三者のＲＰＭサービスプロバイダは現在存在しない。
【００２５】
ＲＰＭシステムにおいて特に関心の高い領域のひとつは、リソースの利用に関する。社員あるいはその他、リソースを利用できる人が長期間アクセスしないリソース、つまり休眠リソースおよび、これとは逆に過剰にアクセスされるリソースは、そのリソースを管理する組織に複数の問題を生じさせる。たとえば、長期間アクセスされないまま社員にとって利用可能な状態となっているリソースはリソース共有管理システムに不必要に負担を与える。動作可能な状態にするために、リソースはシステムのオーバーヘッドを必要とする。たとえば、リソースは、社員またはそのリソースを利用するその他の人物にとって機能的であるようにするために、システムのメモリ、システムプロセッサ時間およびリソース共有管理システムのその他要素を利用する。
【００２６】
リソースは、このような利用に関連して、リソース共有管理システムのオーバーヘッドに負担を与える。このような負担は、定期的にアクセスのあるリソースにとっては容認可能であるものの、定期的にアクセスされないリソースにとっては不要な負担である。さらに、リソース共有管理システム内の休眠リソースは、システムを非効率にする。社員その他のユーザにリソースの共有を行うために、そのリソースについて、たとえばシステムメモリの割当、システム管理時間の割当その他、リソースの適正な機能に必要な割当等、システムのさまざまな割当を行わなければならない。これらの割当および、リソースの共有に必要なその他の作業および適当な担当者がこれらの割当を行うのに必要な時間は、長期間そのリソースが休眠状態のままであれば、完全に無駄である。
【００２７】
休眠リソースはまた、リソース共有管理システムのセキュリティを損なう可能性もある。いずれかのリソース上のオープンアカウントは、さまざまなレベルの脆弱性を伴う。ハッカーは常に、システムサーバやデータベースに入るために、ほとんどまたはまったく使用されていないアカウントを探している。オープンアカウントがまったくまたはあまり使用されていないと、システム管理者がそのアカウントに注意をむけなくなりがちになる。つまり、その特定のアカウントを通じてシステムセキュリティが破られたことにシステム管理者が気付く可能性が低くなる。
【００２８】
そこで、技術分野の各セグメントで、休眠リソースを照合確認する試みが行われてきた。たとえば、自主的な電子メールサービスプロバイダの多くは、そのシステム上の各電子メールアカウントの利用状況をモニターしている。ある電子メールアカウントが一定期間、たとえば６カ月間にわたって利用されないと、そのアカウントはシステム管理者によってシステムから自動的に排除される。このように自動的にアカウントを除外するシステムは定期的に使用されるアカウントにとって、追加のシステムリソースを利用可能にする役割を果たすが、このようなシステムは、そのリソースの休眠の理由を確認する、あるいはそのリソースの効率的かつフレキシブルな照合確認を規定する方針を策定する手段を実現しない。
【００２９】
ＲＰＭシステムにおいて特に関心の高い別の領域は、管理されたリソースのユーザの個人識別情報に関する。各ユーザの固有の識別情報を明確にするのに十分なアイデンティティ方針がないと、リソースのユーザの識別は、システム上のユーザ数が増加し始めるとすぐに管理不能となる。さらに、十分な個人アイデンティティ方針が整備されていないと、リソース共有管理システムが複数のリソースにわたるユーザの識別を管理することが事実上、不可能となる。たとえば、リソース共有管理システムにおいて、電話アカウント等、特定のリソースのユーザの各々をユーザの名の頭文字に姓を続けて識別するアイデンティティ方針が存在するとする。つまり、“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”という氏名のユーザの場合、そのアカウントアイデンティティは“ｊｗｉｌｌｉａｍｓ”となる。しかしながら、アイデンティティ方針の中に、同姓同名のユーザを区別するための規定がさらにないと、そのリソースを使用する“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”という名前の他のユーザは、まったく同じアカウントアイデンティティを持つことになり、最初の“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”と区別できない。また、“Ｊａｍｅｓ Ｗｉｌｌｉａｍｓ”，“Ｊａｓｏｎ Ｗｉｌｌｉａｍｓ”，“ Ｊｏｓｈｕａ Ｗｉｌｌｉａｍｓ”，“Ｊｏａｎ Ｗｉｌｌｉａｍｓ”およびその他、姓が“Ｗｉｌｌｉａｍｓ”で名が“Ｊ”から始まる人は、このような人々とそれぞれに対応するユーザアカウントを区別することのできるアイデンティティ方針がなければ、他の姓が“Ｗｉｌｌｉａｍｓ”で名が“Ｊ”から始まるすべての人と区別されない。
【００３０】
別の例として、同じＲＰＭシステムが別のリソースを管理していると仮定した場合、たとえば携帯電話ネットワークはそのユーザを、ユーザの姓に名の頭文字を続けることによって識別する。つまり、“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”という名前のユーザは、“ｗｉｌｌｉａｍｓｊ”と識別される。リソース共有管理システムが、名の頭文字に姓を続けたもので識別される前の例のユーザと携帯電話ネットワークユーザと調整しようとした場合、同じシステムの中の別のリソースについて、同一人物が別のアイデンティティを持つことになる。これは少数のユーザと限られた資源のリソースについては容認できるが、システム内のユーザとリソースの数が増えると、管理が不可能ではなくても困難になる。アイデンティティ方針が、同じ識別名を有する複数のユーザまたは複数のプラットフォームにわたる複数のユーザを扱うのに不十分であると、ＲＰＭシステムの管理リソースに不必要な負担をかける。システムユーザの数が増えると、ユーザのアイデンティティを記憶し、処理するのに必要なシステムメモリとシステムプロセッサ時間も相応に増大する。システム上のすべてのアカウントホルダを効率的に識別し、管理するアイデンティティ方針が実現されていないと、システム全体の性能が大幅に低下する。さらに、できの悪いアイデンティティ方針では、システムセキュリティが損なわれる。ＲＰＭシステム内のアカウントホルダがシステム内でいくつかの方法によって識別され、システム内で実現されているアイデンティティ方針が複数のアカウントのアイデンティティを調整するのに不十分なものであると、ＲＰＭシステムがどのアカウントについてシステムセキュリティが破られ、誰がそれを破ったかを特定することが困難または不可能となる。
【００３１】
現在リソースを提供する各種の組織が採用しているアイデンティティ方針には、システムとアカウントホルダの間で、アイデンティティを対話的に選択できるものがある。たとえば、一部のインターネット電子メールサービスプロバイダは、アカウントホルダが電子メールのためのアイデンティティを選択できるようにしている。このため、“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”という名前のアカウントホルダはその電子メール用のアイデンティティとして“ｊｗｉｌｌｉａｍｓ”と入力できる。しかしながら、“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”は比較的ありふれた名前であり、Ｊｏｈｎ Ｗｉｌｌｉａｍｓという名前の人物がそのアカウントのためのアイデンティティを確立しようとしたときに、電子メールアイデンティティの“ｊｗｉｌｌｉａｍｓ”はすでに使われている可能性が高いため、システムはアカウントホルダにこれを伝え、別のアイデンティティを選択するよう要求することができる。このような状況により、一人の人物または同姓同名の複数の人物を区別するのにある程度役立つ“ｊｗｉｌｌｉａｍｓ１００”または“ｊｗｉｌｌｉａｍｓｍｉａｍｉ”といったタイプの電子メールアイデンティティの増殖が起こる。システムとアカウントホルダとの間でシステム上のアイデンティティを確立するための対話が可能となれば、システムアイデンティティにおける統一性が完全に失われ、システムアカウントの管理がより困難となる。
【００３２】
ＲＰＭシステムにおいて関心の高いさらに別の領域は、ユーザがこれらのリソースを入力し、利用するために必要なパスワードに関する。パスワードを確立するための堅牢で十分に考慮された方針は、システムのプライバシーとセキュリティを維持するためのメカニズムを提供する。反対に、ＲＰＭシステムのパスワード方針のできが貧弱であると、システムのセキュリティが損なわれる。ハッカーに対する最大限の保護を提供するパスワードの構築を必要とする十分なパスワード方針がなければ、ＲＰＭシステム内のすべてのリソースはハッカーの攻撃を受けやすくなり、システム全体が危険にさらされる。リソースを提供し、利用する各種の組織が使用しているパスワードメカニズムの中には、リソースの入力と利用にとって容認可能なパスワードの種類に関する制約を、事実上、まったく設けていないものがある。これらの組織は、パスワードが最低文字数さえ含んでいれば、どのような文字でも使用できるとしていることは珍しくない。たとえば、ある会社が、そのネットワーク用オペレーティングシステムに入るために、少なくとも８文字の長さであれば、どの文字を使ってパスワードを作ってもよいとしたとする。このような種類のルールでは、システムユーザのうち特定の割合のものが、パスワードを作るのに“ａｓｄｆｊｋｌ；”のキーを入力することはよくある。これらの文字は、左から右に、コンピュータキーボードのホームキーに対応し、一般的で、容易に構築でき、容易に覚えられ、残念ながら容易に発見されるパスワードである。
【発明の開示】
【発明が解決しようとする課題】
【００３３】
従って、本発明の実施形態は、考案しなければならない固有の役割の数を減らす、または最小限にする、方針、ユーザの役割、属性に基づいてユーザへの共有を行うシステムと方法に関する。本発明の別の実施形態は、「ソフト」と「ハード」両方のリソースの共有を可能にする方針に基づいてユーザへの共有を行うシステムと方法に関する。本発明のさらに別の実施形態は、いくつかのリソースをまとめて共有を行うためのシステムと方法に関する。本発明のまた別の実施形態は、ユーザパラメータの入力の結果として構築される各種の処理経路をとることのできる方針に基づいてユーザへの共有を行うシステムと方法に関する。本発明の別の実施形態は、別の人物からの情報または許可を必要とする方針に基づいてユーザへの共有を行うシステムと方法に関する。
【課題を解決するための手段】
【００３４】
これらおよびその他の利点は、ユーザへのリソースの共有を行う方法とシステムに従って実現される。この方法とシステムには、一連の属性とユーザの役割を確定し、選択された属性とユーザの役割に基づいて複数のリソースアクセス方針を定義することが関与する。この方法とシステムには、特定のユーザまたはリソースに関する属性情報とユーザの役割情報を受け取り、受け取ったユーザの役割情報と属性情報に基づいて、そのユーザにどのリソースアクセス方針を適用するかを決定し、適用されるリソースアクセス方針に基づいてユーザへのリソースの共有を行うことが関与する。この方法はまた、一連の属性、組織情報、ユーザの役割を確立し、選択された属性、組織情報、ユーザの役割に基づいて、複数のリソース共有方針を定義するステップを含む。
【００３５】
この方法はさらに、特定のユーザまたはリソースに関する属性情報とユーザの役割情報を受け取り、受け取ったユーザ役割情報、組織情報、属性情報に基づいて、そのユーザにどのリソース共有方針を適用するかを決定し、適用されるリソース共有方針に従って第三者からのその他の情報または許可を求め、第三者から必要な追加情報または許可をすべて受け取ったところで、適用されるリソース共有方針によって特定されるリソースをユーザに割り当てるステップを含む。この方法には、ネットワーク上での共有とユーザへの外部リソースの共有を含めることもできる。単独の論理サーバを使用して、それぞれ内部リソースを有する複数の組織のリソースの共有を行う方法にはまた、各組織に関する一連の属性、組織情報、ユーザの役割を確立するステップと、選択された属性、組織情報、ユーザの役割に基づいて各組織のための複数のリソースアクセス共有方針を定義するステップと、特定のユーザまたはリソースまたはデータベースに関する各組織からの属性情報、組織情報、ユーザの役割情報を受け取るステップと、受け取ったユーザの役割情報、組織情報、属性情報に基づいて、どのリソース共有方針をユーザに適用できるかを判断するステップと、各組織をリソース取引所（エクスチェンジ:exchange）にグループ分けするステップと、適用可能なリソースアクセス共有方針に基づいて、遠隔の中央集中管理化されたロケーションからのユーザとリソース取引所内の組織からのユーザとが相互共有を行うステップを含めることができる。
【００３６】
この方法にはさらに、リソース取引所内で組織に関する変換マップを設けるステップを含めてもよい。また、この方法には、リソース取引所内に、ハイレベルの組織認証を提供するステップを設けることができる。この方法にはさらに、リソース取引所内に、組織のアイデンティティ同期を設けるステップを含めてもよい。この方法はさらに、リソース取引所内に組織に関するオーディットトレールを設けるステップや、リソース取引所内に組織に関する無名性（アノニミティ: anonymity）を設けるステップを含めることもできる。
【００３７】
公共共有インフラストラクチャにおけるサービスを使って複数の組織のリソースを共有する方法は、リソースを有する各組織の一連の属性、組織情報、ユーザの役割を確立するステップと、選択された属性、組織情報、ユーザの役割に基づいて、リソースを有する各組織のための複数のリソースアクセス共有方針を定義するステップと、特定のユーザまたはリソースまたはデータベースについて、各組織から属性情報、組織情報、ユーザの役割情報を受け取るステップと、公共共有インフラストラクチャ内のリソースを使用したいと希望する一般民衆のメンバーから、属性情報、組織情報、ユーザの役割情報を受け取るステップと、一般民衆のそのメンバーのためにリソース共有チケットを生成するステップと、受け取ったユーザの役割情報、組織情報、属性情報に基づいて、どのリソース共有方針をユーザに適用するかを決定するステップと、特定のリソースのベンダに共有チケットを送るステップとを含む。
【００３８】
複数の組織のリソースの共有を行うシステムは、第三者リソース共有管理サービスプロバイダと、リソースの共有を行うためのサーバと、サーバは第三者リソース共有管理サービスプロバイダによって運営され、各組織に属する内部リソースと、サーバと内部リソースの間のリンクを提供するネットワークとを供え、第三者リソース共有管理サービスプロバイダは、組織の要請に応じて、ネットワーク上で各組織の内部リソースの共有を行う。システムはさらに、外部リソースを備え、外部リソースは各組織に共有される。複数の組織のリソースの共有を行うシステムはさらに、第三者リソース共有管理サービスプロバイダと、リソースの共有を行うためのサーバと、サーバは第三者リソース共有管理サービスプロバイダによって運営され、複数の組織からなるリソース交換所と、各組織は内部リソースを有し、サーバと内部リソースの間のリンクを提供するネットワークとを備え、第三者リソース共有管理サービスプロバイダは、各組織の要求に応じて、ネットワーク上でリソース取引所内の各組織の内部リソースを相互共有する。
【００３９】
システムはさらに、リソース取引所内の組織の変換マップと、リソース取引所内の組織の各々のハイレベル認証のための手段と、リソース取引所内の組織アイデンティティ同期手段と、リソース取引所内の組織のオーディットトレールを提供する手段を備えてもよい。複数の組織のリソースを共有するシステムはまた、リソースを有する各組織に関する一連の属性、組織情報、ユーザの役割を確立する手段と、選択された属性、組織情報、ユーザの役割に基づいて、リソースを有する各組織のための複数のリソースアクセス共有方針を定義する手段と、特定のユーザまたはリソースまたはデータベースについて、各組織から属性情報、組織情報、ユーザ役割情報を受け取る手段と、公共共有インフラストラクチャ内のリソースを使用したいと希望する一般民衆のメンバーから属性情報、組織情報、ユーザの役割情報を受け取る手段と、一般民衆のメンバーのためのリソース共有チケットを生成する手段と、受け取ったユーザの役割情報、組織情報、属性情報に基づいて、どのリソース共有方針がユーザに適用できるかを判断する手段と、特定のリソースのベンダに対し、共有チケットを送る手段とを備える。
【００４０】
本発明の別の実施形態は、共有がリソースから離れているが、インターネット上でリソースに接続されているロケーションから管理されるこれらのシステムと方法に関する。好ましい実施形態において、このようなシステムと方法は、ＸＭＬ等の適当なメッセージフォーマットでトンネリングするＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を採用する。本発明のさらに別の実施形態は、方針、ユーザの役割、属性に基づいてユーザへの共有を行い、創出しなければならない固有の役割の数を減らす、または最小限にするシステムと方法に関する。共有が行われるリソースには、「ハード」のリソースと「ソフト」のリソースがある。「ソフト」のリソースは、電子メール、ボイスメールアカウント、アプリケーションプログラム、データベース、ファイル、フォルダ、インターネット、ウェブページ、組織内イントラネット、第三者へのメッセージ、ユーザによる暗号化リソースへのアクセスを可能にするためのデジタル認証、インターネット上での商品注文機能、コーポーレートクレジットカードの注文機能、金融サービス提供者へのアクセス等である。「ソフト」のリソースには、ワイドエリアネットワーク（ＷＡＮ）上の遠隔サイトで管理されるリソースが含まれる。
【００４１】
本発明の別の面によれば、所定のユーザはＷＡＮ上の遠隔サイトから、ワークフローを追加、削除、変更することができる。さらに、ユーザには、電話、コンピュータ、携帯電話、ページャ、携帯通信端末、机、椅子、ファイルキャビネット、その他の物理的コンポーネント等の「ハード」なリソースも割り当てられる。別の実施形態において、複数のリソースをひとつまたは複数のグループにまとめ、ユーザにいくつかのリソースのまとまり（バンドル）を割り当てることができる。本発明の実施形態はまた、休眠とみなされるリソースとそれに対してどのような行動をとるかに関する休眠リソース方針を決定するシステムと方法に関する。本発明のさらに別の実施形態は、リソースの過剰な使用とそれに対してどのような行動をとるかに関する方針を決定するシステムと方法に関する。本発明のまた別の実施形態は、システムのオーバーヘッドの必要性をなくす、リソースの使用に関する使用方針を決定するシステムと方法に関する。本発明のさらにまた別の実施形態は、システムコンポーネントを効率的に利用するリソースの使用に関する使用方針を決定するシステムと方法に関する。本発明のまた別の実施形態は、システムの完全性を維持するためのリソースの使用に関する使用方針を決定するシステムと方法に関する。本発明のさらに別の実施形態は、休眠の理由を確認し、リソースを照合確認するための休眠リソース方針を決定するシステムと方法に関する。
【００４２】
本発明の実施形態はまた、管理されたリソースのユーザのためのアイデンティティを確立するシステムと方法に関する。本発明のまた別の実施形態は、システム内の各ユーザをシステムが個々に識別できるようにするルールを提供する、ＲＰＭシステム内のアイデンティティ方針に関する。本発明の別の実施形態は、ＲＰＭシステム内のユーザがシステム内およびそのシステムが管理する各リソース内でどのように識別されるかを決定するルールを含む、ＲＰＭシステム内のアイデンティティ方針に関する。本発明のさらに別の実施形態は、複数の管理されたリソースのユーザが、複数のリソース内および複数のリソース間でどのように識別されるかを決定する、ＲＰＭシステム内のアイデンティティ方針に関する。本発明のさらに別の実施形態は、たとえばユーザの氏名と組織内でのユーザの役割を含むユーザの属性からシステムリソースのユーザのアイデンティティを作るためのルールを提供し、さらに、属性の異なる組み合わせを使って固有のアイデンティティを構築する能力を提供する、ＲＰＭシステム内のアイデンティティ方針に関する。本発明のさらに別の実施形態は、ユーザの属性がリソースの別のユーザと衝突した場合に、特定のユーザについて合理的なユーザアイデンティティが生成できるようにユーザの属性を組み合わせる、ＲＰＭシステム内のアイデンティティ方針に関する。このように、あるユーザのためのアイデンティティを生成する際、本発明のある実施形態によるアイデンティティ方針はそのアイデンティティが生成されたユーザの属性だけでなく、リソースの他のユーザの属性も考慮する。本発明の別の実施形態は、ユーザアイデンティティ間の衝突を自動的に解決するルールを提供する、ＲＰＭシステム内のアイデンティティ方針に関する。本発明のさらに別の実施形態は、ユーザが介入することなく、ユーザアイデンティティを創出するためのルールを提供する、ＲＰＭシステム内のアイデンティティ方針に関する。
【００４３】
本発明の実施形態はまた、ＲＰＭシステムにおけるパスワードを確立する方法とシステムに関する。本発明の別の実施形態は、ユーザが特定のパスワードをシステム上で使用できないように制限するＲＰＭシステム内のパスワード方針を決定する方法とシステムに関する。本発明の別の実施形態は、ユーザに対し、システム内の各リソースにアクセスでき、パスワード一般に関する会社または組織の方針に適合したパスワードを構築するよう求める、ＲＰＭシステム内のパスワード方針を決定する方法とシステムに関する。本発明のまた別の実施形態は、システム内の各リソースに関するパスワードルールを組み合わせて、システム内の全リソースに適用できる統一化された方針にする、ＲＰＭシステム内のパスワード方針を決定する方法と手段に関する。本発明のさらにまた別の実施形態は、その実施形態におけるパスワードシンタックスの中の矛盾を認識する、ＲＰＭシステム内のパスワード方針を決定する方法とシステムに関する。本発明の別の実施形態は、ハッカーからの保護を弱め、その結果システム全体をセキュリティ崩壊の危機にさらすことになるルールセットを排除する、ＲＰＭシステム内のパスワード方針を決定する方法と手段に関する。本発明の別の実施形態は、各方針と一致するパスワードの自動生成を可能にする、ＲＰＭシステム内のパスワード方針を決定する方法とシステムに関する。
【００４４】
本発明のさらに別の実施形態は、特定の機能を実行する、標準化されたソフトウェアモジュールセットを使って、管理されたリソースにアクセスするエージェントのモジュール開発のためのシステム、デバイス、方法に関し、このソフトウェアモジュールセットは、リソースを管理するどのエージェントにも共通の特徴を考慮して開発される。本発明の別の実施形態は、プロトコルに無関係なエージェント開発を可能にする、特定の機能を実行する、標準化されたソフトウェアモジュールセットを使って、管理されたリソースにアクセスするエージェントのモジュール開発のためのシステム、デバイス、方法に関する。本発明のまた別の実施形態は、エージェント開発者が他の開発者のエージェントソフトウェアの作業を共有し、理解し、あるいはデバッギングする、または他の開発者のエージェントの開発を引き継ぐことを可能にする、特定の機能を実行する、標準化されたソフトウェアモジュールセットを使って、管理されたリソースにアクセスするエージェントのモジュール開発のためのシステム、デバイス、方法に関する。
【００４５】
本発明の他の実施形態は、エージェント開発者が、ソフトウェアモジュールのプレファブリケーションにより、より早く、より効率的に作業することを可能にする、特定の機能を実行する、標準化されたソフトウェアモジュールセットを使って、管理されたリソースにアクセスするエージェントのモジュール開発のためのシステム、デバイス、方法に関する。これらおよびその他の利点は、リソース共有管理（ＲＰＭ）システムから管理されたリソースにアクセスするためのエージェントを効率的に開発することを可能にするツールキットを生成する方法によって実現する。この方法は、２つの主要なステップで構成される。第一のステップは、リソース管理のために開発されたエージェントに共通する特徴を決定することである。第二のステップは、多数の特徴を実行するための複数のソフトウェア機能を開発することである。このソフトウェアの機能には、ある具体的な要求された行動を含むプロトコル別のメッセージをプロトコルとは無関係なメッセージに変換するためのプロトコルプラグイン機能のライブラリがある。また、このソフトウェア機能には、プロトコルとは無関係なメッセージから上記の具体的な要求された行動を実行するのに必要なデータを抽出する機能のメッセージ抽出ライブラリと、抽出されたデータについて特定の操作を実行する機能のインタフェースライブラリがある。さまざまなソフトウェア機能により、ＲＰＭシステムからの特定の管理されたリソースにアクセスするためのエージェントの開発者は、具体的な要求された行動を実行するためのソフトウェア機能のひとつまたは複数を求めるエージェントプログラムを書くことができるようにする。
【００４６】
本発明の実施形態の上記およびその他の目的、特徴、利点は、図面と添付の特許請求範囲を参照しながら以下の本発明の実施形態の詳細な説明を読むことにより、当業者にとって明らかとなる。
【発明を実施するための最良の形態】
【００４７】
以下の好ましい実施形態の説明において、本明細書の一部を構成する添付の図面を参照するが、これは、本発明を実施する具体的実施形態を例示している。本発明の好ましい実施形態の範囲から逸脱することなく、他の実施形態を利用し、また構造上の変更を加えることも可能であると理解すべきである。
【００４８】
システムの概要
本発明の実施形態は、方針、役割、属性に基づいて、リソースをユーザに割り当てるための通信ネットワーク上で動作するシステムに関する。本発明の実施形態は本明細書において一般にリソース共有管理（ＲＰＭ）システム、あるいは単純に「システム」という。システムは、ひとつまたは複数のネットワークまたはネットワーク以外のリンク上での通信用に接続された各種のプロセッサまたはコンピュータシステム上に配置されたソフトウェアアプリケーションおよびモジュールを用いて実現することができる。詳しく後述するように、モジュールとアプリケーションが配置されているプロセッサは、システムの実施形態ごとに異なる。さらに、ユーザ、管理者およびシステムと対話するその他の実体のタイプもシステムの実施形態ごとに異なる。システムの好ましい実施形態は、各種の用途のニーズに対応できる高レベルのフレキシビリティを提供するよう設計されている。
【００４９】
本発明の実施形態が動作するシステム環境の２つの代表例をそれぞれ図１，２に示す。図１はアプリケーションサービスプロバイダ（ＡＳＰ）環境の実施形態、図２はシステムの企業環境実施形態の一般化された表現を示す。図１、図２の各々において、プラットフォームコンピュータシステム１０は、システムのニーズに応じて、複数のユーザのコンピュータ、管理者のコンピュータおよびその他の実体とネットワーク１２上で通信するよう接続されている。外部システム、データベースおよびディレクトリ、第三者のサービスプロバイダ、管理されたサービスおよびシステム管理者を含むその他の実体を、システムのニーズに応じ、通信のために、同じネットワークまたはその他のネットワークまたは専用通信リンクを通じてプラットフォームシステム１０に接続することができる。このような実体の多くがここで開示される実施形態に関して示され、説明されているが、本発明の実施形態のその他のシステム環境が必ずしも本明細書に記載するすべての実体を含んでいる必要はないことがわかるであろう。
【００５０】
ネットワーク環境には、ひとつまたは複数のネットワークサーバ、ルータその他のネットワーク構造とデバイス（図示せず）を含めることも可能である。ネットワーク環境は、たとえばオフィスまたはビル内のローカルエリアネットワーク（ＬＡＮ）であってもよい。別の実施形態において、ネットワーク環境は、たとえばインターネットを含むワイドエリアネットワーク（ＷＡＮ）であってもよい。
【００５１】
プラットフォームシステム１０は、たとえば、本明細書において説明する各種の機能を実行するための関連するメモリとソフトウェアモジュールおよびアプリケーションを備える、またはこれらと動作するひとつまたは複数のプロセッサまたはコンピュータを使用して実現することもできる。プラットフォームシステム１０は、後述のように、方針、役割、組織情報、属性に基づいた、ユーザへのリソースの共有に関連する各種の機能を実行する。後述のように、たとえば、これらのコンピュータ上で実行するソフトウェアによって実現されるユーザ、管理者、サービスプロバイダに関連する他の機能がプロセッサまたはコンピュータ上で実行される。このため、本発明の実施形態は何台ものコンピュータ上でも、単独のコンピュータ上でも実行できる。これらのコンピュータは、複数のプロセッサを有するものとそうでないものがある。ユーザおよび管理者の役割を果たすユーザは、たとえば表示装置、キーボード、マウス等、ユーザがそのネットワークまたはその他の通信リンク上で情報を取得、通信することができるようにする、適当なプロセッサ、メモリデバイス、ユーザインタフェースデバイスを備えるコンピュータを操作する。適当なソフトウェアは、ユーザと管理者のウェブブラウザまたはコンピュータに記憶され、あるいはアクセスでき、ユーザと管理者にインタフェース機能を提供し、データ、ファイル、プログラムその他のソフトウェア等の電子情報とコンテンツを、周知のネットワーク通信技術を使い、ネットワーク上で通信することが可能となる。
【００５２】
さらに、本発明の実施形態による、ユーザと管理者に関連する機能を実行するためのソフトウェアも、それぞれユーザおよび管理者のウェブブラウザに記憶される、あるいはアクセス可能な場合がある。システム１０は、方針を定義し、システムと対話するユーザまたはシステムが動作しているネットワークと対話するユーザにサービスを割り当てるためのプラットフォームを提供する。システムは、ザービスのタイプや多数のユーザのためのこれらのサービスへのアクセスのタイプを指定し、追跡することができる。
【００５３】
図１，２の一般化された例において、プラットフォームシステム１０は、ユーザコンピュータからのサービスに対するリクエストを受け取る。プラットフォームシステム１０はまた、たとえばユーザのリクエストの認証またはユーザ、方針、役割の変更等に関する情報を管理者のコンピュータから受け取る。プラットフォームシステム１０はさらに、たとえば操作およびサービスの利用状況に関するレポート等、管理者のウェブブラウザまたはコンピュータに情報を提供する。プラットフォーム１０は、ユーザのリクエスト、方針、役割、組織情報、属性に基づいて、ユーザにサービスを提供することに関し、サービスプロバイダまたは管理されたサービスコンピュータに、リクエスト、命令その他の情報を提供する。プラットフォームシステム１０は、ユーザのリクエスト、方針、役割、組織情報、属性に基づいて、データベースまたは記憶システムからユーザへのデータ、ファイル、プログラムまたはその他電子情報等のサービスへのアクセスを管理する。
【００５４】
上述のように、図１の実施形態によるシステムは、ＡＳＰ環境において実施される。ＡＳＰは、中央集中的に管理される施設から複数の当事者へのソフトウェアおよびその他のリソース等のアプリケーションへのアクセスを実現、ホスト、管理する組織として説明することができる。アプリケーションは通常、たとえばインターネット等のネットワーク上で、加入ベースにより提供される。ＡＳＰ環境において、ＡＳＰ内の一人または複数のユーザは、同じ会社の他のユーザより大きなアクセス権を有するＲＰＭシステム管理者１４に指定されることがある。ＲＰＭシステム管理者は、同じ会社の他のユーザと同様に、各ユーザに関する役割と組織情報に基づいて、ＡＳＰ顧客が設定する方針に従い、動作を実行することができる。しかしながら、後述のように、これらのＲＰＭシステム管理者にはさらに、システムの特定のモジュールまたはアプリケーションが実現されるプロセッサを選択する等、特定のシステム構成に関する責任が与えられる。
【００５５】
さらに、ＲＰＭシステム管理者は、たとえば、組織、ユーザ、サービス、役割、ワークフローに関するルール、方針、システムそのものを管理することができるかもしれない。ＲＰＭ共有システム管理者はまた、システムの現在および過去の状況を精査するためのレポートを生成し、さらに、そのデータへのアクセスを許可されることにより、システムのデータの異なる部分を管理することもできる。一人のＲＰＭシステム管理者の責任は、そのＲＰＭシステム管理者に与えられた許可またはアクセス権に応じて、組織のみの管理からシステム全体の管理まで、幅がある。
【００５６】
図１のシステムはまた、たとえば、一人または複数の顧客エンドユーザ１６、顧客管理者１８、顧客監督者２０ともインタフェースする。図の例において、顧客エンドユーザ１６、顧客管理者１８、顧客監督者２０に関するインタフェースは、インターネット１２上の接続が可能なウェブである。顧客エンドユーザ１６は、顧客が設定した方針に従ってリソースにアクセスできるユーザである。顧客エンドユーザ１６は、特定のＡＳＰリソースへのアクセスが認められたＡＳＰの顧客の社員であってもよい。顧客エンドユーザ１６は、一般に、ウェブブラウザを使用してネットワーク上でサービス／リソースを割り当てることを求める要求を伝えることにより、ライトウェイトディスレクトリアクセスプロトコル（ＬＤＡＰ）ディレクトリサーバ（図１には示されていない）に記憶された、個人およびアカウント情報の自己管理を実行することのみ認められている。顧客管理者１８も、図１に示されているように、顧客が設定する方針に従ってリソースにアクセスできるユーザである。
【００５７】
顧客管理者１８は、組織およびユーザ情報の管理等、顧客の組織の一部を管理する責任を負い、したがって、そのような機能を果たすために適当なシステムデータにアクセスする許可または権利を与えられたＡＳＰの顧客の社員であってもよい。たとえば、顧客管理者は、ユーザの役割と方針と用途を定義、管理し、したがって、ＬＤＡＰディスレクトリサーバへのアクセスの許可または権利が与えられる。このように、顧客管理者は、ユーザ、役割、方針、組織内の階級等を定義または変更することができる。顧客管理者は、システムの現在および過去における状態を精査するためのレポートを生成し、したがって、レポートエンジン１５０を含むＲＰＭシステムサーバにアクセスする許可または権利が与えられる（図３参照）。顧客管理者１８は通常、そのデータへのアクセスが認められることにより、システムのデータの異なる部分を管理する権限を有する。顧客管理者１８の責任は、顧客管理者に認められた許可や権利に応じて、組織のみの管理からシステム全体の管理まで、幅がある。
【００５８】
図１に示すように、顧客監督者２０もまた、顧客が設定した方針に従ってリソースにアクセスできるユーザである。顧客監督者２０は、顧客組織におけるユーザグループを管理または監督する責任を負う、ＡＳＰの顧客の社員とすることができる。顧客監督者２０は、別の顧客監督者に責任を委託してもよい。好ましい実施形態において、責任の委託は事前に決定された期間中について認められる。顧客監督者２０は、現在のユーザリストに変更を加え、ユーザの要求に承認が必要な場合、その要求を承認することができる。顧客監督者２０はまた、システムの現在および過去の状態を精査するためのレポートを生成する。好ましい実施形態において、レポートは記憶されないと理解すべきである。これらは必要に応じて生成され、ユーザがレポートを記憶したい場合は、ユーザのウェブブラウザに保存しなければならない。
【００５９】
図１はまた、システムがひとつまたは複数の外部システム２２とインタフェースすることを示している。外部システム２２は、システム１０によって管理される顧客または管理されたリソース情報を呼び出すことを希望する、どのようなＡＳＰシステムでもよい。これは、システム１０がその情報を記憶するのに使用するＲＰＭディレクトリ（図３の参照番号５８参照）への直接インタフェースを通じて実現される。
【００６０】
図１に示すように、システムはひとつまたは複数の顧客データストア２４ともインタフェースする。好ましい実施形態において、このインタフェースはインターネット対応である。顧客データストア２４は、ＡＳＰ顧客情報を記憶するリレーショナルインタフェースまたはディレクトリとすることができる。顧客の組織、役割、アカウント情報、ユーザ情報等の顧客関連データは、顧客データストア２４内のディレクトリに記憶され、処理中のワークフロー情報、オーディットログ、過去のオーディットトレール情報（承認されたリクエスト等）、システム状態情報（ワークフロー状態、未承認のリクエスト等）および遠隔サービスに関する情報は、顧客データストア２４内のデータベースに記憶される。
【００６１】
システム１０はまた、図１に示すように、たとえば管理されたサービス２６ともインタフェースする。好ましい実施形態において、このインタフェースはインターネット対応である。管理されたサービス２６は、システム１０が積極的に管理するアプリケーション、デバイスまたはデータストアである。管理されたサービスは、ＲＰＭシステム、オペレーティングシステム、アプリケーション（人材（ＨＲ）システム、企業リソース計画（ＥＲＰ）システム等）、パブリックキーインフラストラクチャ（ＰＫＩ）認証、データベース、金融サービス等、アカウントメンテナンスシステムを有するネットワークデバイスとすることができる。管理されたサービスのシステムは、独立して機能する。このように、システム１０のデータストアと管理されたサービスのそれは、たとえばデータベースを更新するために、定期的に、あるいは所定の、または不規則的な間隔で同期される。
【００６２】
システムはまた、図１に示すように、たとえば第三者サービスプロバイダ２８ともインタフェースする。好ましい実施形態において、このインタフェースはインターネット対応である。第三者サービスプロバイダ２８は、システム１０を通じて割り当てられるサービスを提供する外部組織とすることができる。第三者サービスプロバイダ２８は、たとえば、システム１０を通じて割り当てられるクレジットカードまたはクレジットアカウントを提供するクレジットカードサービスとすることができる。別の例として、第三者サービスプロバイダ２８は、システムを通じて割り当てられる電話回線アカウントを提供する電話サービス会社でもよい。これらは単に代表例にすぎないと理解すべきである。別のシステム実施形態によれば、その他多くのタイプのサービスが、第三者サービスプロバイダによって提供される。
【００６３】
システム１０はまた、図１に示すように、たとえばパートナーシステム３０ともインタフェースする。好ましい実施形態において、このインタフェースはインターネット対応である。パートナーシステム３０はシステム１０と同様または同一とすることができるが、ビジネスパートナーまたは顧客によって使用され、システム１０の中に統合される。このように、パートナーシステム３０はシステム間のインタフェースを表し、これは、好ましい実施形態において、複数のシステムのシームレスな統合を提供するのに使用できる。
【００６４】
前述のように、図２の実施形態によるシステムは、企業環境において実現される。企業は、たとえば会社、教育機関、政府機関またはその他のグループまたは団体等、そのリソースの運用、管理を希望する、または必要とするどのような組織でもよい。図２の実施形態において、システム１０は図１について上述したものと同じ機能をサポートするが、異なる種類のユーザについて、若干の相違がある。たとえば、システム１０は、図１について前述したＲＰＭシステム管理者とのインタフェースに似た方法で、システム管理者５０とインタフェースする。
【００６５】
システム管理者５０は、企業の社員とすることができ、システムを構成する責任を負う。システム管理者５０は、組織、ユーザ、サービス、役割、ワークフローに関するルール、方針、システムそのものを管理することができる。システム管理者５０はまた、システムの現在および過去の状態を精査するためのレポートを生成する。システム管理者５０は、そのデータへのアクセスを認められることにより、システムのデータの異なる部分を管理することができる。システム管理者５０の責任は、組織のみの管理からシステム全体の管理まで、幅がある。図１について説明した顧客エンドユーザ、顧客管理者および顧客監督者の代わりに、図２の環境には社員（またはパートナー）５２、社員管理者５４、監督者５６が含まれる。それぞれ、システム１０とインタフェースし、好ましくは、インターネット上でシステム１０とインタフェースするためにウェブ対応とする。社員は、企業の社員とすることができる。社員５２は、企業が設定した方針に従って、リソースにアクセスすることのできるユーザである。一般に、社員はその社員自身の個人情報の自己管理を行うことのみ許可されている。図２に示す社員管理者５４は、企業社員の管理について責任を負う企業の社員とすることができる。社員管理者５４は、企業が設定する方針に従ってリソースにアクセスでき、企業の組織およびユーザ情報を管理する責任を負うユーザである。これには、ユーザの役割と方針を定義、変更、管理することがかかわる。社員管理者５４はまた、システムの現在および過去の状態を精査するためのレポートを生成する。社員管理者５４は、そのデータへのアクセスを認められることにより、システムデータの別の部分を管理することができるかもしれない。社員管理者５４の責任は、組織のみの管理からシステム全体の管理まで、幅がある。社員監督者５６は、企業内のユーザグループを管理する責任を負う、企業の社員とすることができる。一般に、企業監督者５６は、ユーザに変更を加え、ユーザによるリクエストを承認する。企業監督者５６は、システムの現在および過去の状態を精査するためのレポートを生成する。
【００６６】
図２はまた、システムがディレクトリ５８とインタフェースすることを示している。システムはディレクトリ５８を使い、組織情報、ユーザまたは社員情報、パートナー情報、役割情報、アカウント情報、リソース情報その他を記憶する。ある実施形態において、ディレクトリはＬＤＡＰｖ３ディレクトリである。ディレクトリは、企業顧客によって供給されるか、あるいはシステム１０のためにのみインストールしてもよい。
【００６７】
図２に示すように、システムは人材データステア６０とインタフェースする。人材データストア６０は、企業の社員およびパートナー情報を記憶するデータベースまたはディレクトリとすることができる。システム１０はまた、パートナーシステム６２、第三者サービスプロバイダ６４、管理されたサービス６６と、図１におけるパートナーシステム３０、第三者サービスプロバイダ２８管理されたサービス２６について前述したものと同様にインタフェースする。
【００６８】
図１，２のシステム１０は、各種のサービスまたはリソースのユーザへの共有を管理するのに使用できる。サービスは、システムのユーザが１回または複数回アクセスできる、どのようなタイプのリソースであってもよい。たとえば、携帯電話アカウントまたはクレジットカード会社とのアカウントがサービスである。これらのサービスを一例とすると、システムは、たとえば、特定のユーザが携帯電話アカウントとクレジットカードアカウントにアクセスできると指定し、ユーザによるこれらのアカウントの利用状況を追跡する。システムはまた、ユーザの状態に応じて、ユーザによるこれらのアカウントの利用状況に関する各種のルールと方針を設定する。
【００６９】
システムを使い、組織は、所定の方針、組織情報、属性および組織内のユーザの役割に基づいて、組織内のユーザにサービスを提供または割り当てる。方針またはルールは、組織のニーズに基づいて組織が事前に設定し、システムの中に組み入れることができる。方針は、組織内の各種の役割や各役割が必要とするサービスを考慮に入れられる柔軟なものとすることができる。たとえば、ある組織がシステム管理者として新規社員を採用したとする。システムを使い、複数のアクションが自動的に開始される。たとえば、組織に関する事前設定された方針が、各社員に定期的な電話サービス、一般の電話、電子メールアカウントを提供すると規定している場合、新規システム管理者の採用にあたり、システムは適当な当事者に対し、そのシステム管理者のために定期的な電話アカウントと電子メールアカウントをセットアップし、システム管理者のオフィスに一般の電話を届けるよう自動的に通知する。また、組織に関する事前設定された方針が、各システム管理者はすべてのシステムデータベースにアクセスできるというものであるとする。
【００７０】
すると、システムは、システム管理者に対してすべてのシステムデータベースへのアクセスを自動的に認める。単に一例として、同じ組織が社外販売員として新規社員を採用すると仮定する。前述のように、各社員が定期的な電話サービス、一般の電話、電子メールアカウントを得るという方針を含め、組織について事前設定された方針により、システムは適当な当事者に対し、その社外販売員のために定期的電話アカウントと電子メールアカウントをセットアップし、一般の電話をその社外販売員のオフィスに届けるよう自動的に通知する。しかしながら、組織に、社外販売員はシステム管理者のように、システムデータベース全部にアクセスできるわけではないとの事前設定された方針がある場合、システムは社外販売員に対し、これらのデータベースへのアクセスを自動的に拒否する。しかしながら、組織に、すべての社外販売員が携帯電話を受け取るという事前設定された方針があれば、システムは自動的に社外販売員のために携帯電話アカウントを設定し、同販売員に携帯電話を届けるよう注文する。ここで説明するシステムの好ましい実施形態は、組織内のその人物の役割とその組織のための事前設定された方針に基づいて、自動的にこれらの行動を実行する。方針は、リソースが組織内でのユーザの特定の役割のニーズと要件を満たすように各ユーザに割り当てられるよう、組織のニーズと組織内の特定の役割の要件に基づいて決定される。
【００７１】
システムの論理アーキテクチャ
本発明のひとつの実施形態によるシステム１０のアプリケーションとモジュールの論理アーキテクチャを図３に示す。図３にあるように、システム例の実施形態は、モジュール同士が共同してシステムの機能を実現することができるようなインタフェースを有するソフトウェアモジュール群として特徴付けられる。好ましい実施形態において、各モジュールは、交換されたモジュールのインタフェースが保たれるかぎり、システムの統合性を損なうことなくシステム内で交換できるソフトウェアの自立ユニットとすることができる。モジュールとのインタフェースはそのままで、各モジュールの内部アーキテクチャは、使用するアプリケーションに応じて異なることがある。モジュールは、アプリケーションサブシステム１０２とプラットフォームサブシステム１０４に分類される。アプリケーションサブシステム１０２は、ユーザまたは管理者が特定の機能を実行するのを助けるアプリケーションのためのものであり、したがって、ユーザまたは管理者が操作するコンピュータ上で実行するソフトウェアとして実現できる。
【００７２】
プラットフォームサブシステムは、アプリケーションがネットワークの状態と管理されているネットワーク上のサービスを含むディレクトリおよびデータベースと対話できるようにするサービスとユーティリティのためのものである。プラットフォームサブシステムは、プラットフォームコンピュータシステム上で実行するソフトウェアとして実現できる。アプリケーションサブシステム１０２は、たとえば、管理アプリケーション１０６、アプリケーションフレームワーク１０８およびユーザアプリケーション１１０を備える。管理アプリケーション１０６は、各種の管理目的のために、ネットワークを通じて、管理者によって使用されるアプリケーションである。
【００７３】
これらのアプリケーションには、管理者がシステムの特定の特性を構成できるようにするインタフェースを提供するひとつまたは複数のシステムコンフィギュレーションアプリケーション１１２が含まれる。たとえば、管理者インタフェースにより、管理者は、ディレクトリ通信セッティング、ロギング特性、電子メールサービスセッティング、ガーベジコレクションその他を行うことができる。システムコンフィギュレーションアプリケーション１１２は、システムによって管理されるデータに関するカスタムフォームを提供するように呼び出されるフォーム生成アプリケーション１１４を含んでもよい。このようなフォームの一例を図８に示す。フォーム生成アプリケーション１１４により、管理者はユーザおよび管理者アプリケーションにおいて表示されるカスタムフォームを創出することもできる。フォーム生成アプリケーションは、システムデータの属性を、たとえば"What You See Is What You Get" (WYSIWYG)のグラフィカルユーザインタフェースビルダ等、グラフィクスによるコントロールと関連付けるグラフィカルユーザインタフェースビルダとすることができる。
【００７４】
管理アプリケーション１０６はまた、ひとつまたは複数のサービスコンフィギュレーションアプリケーション１１６を含む場合があり、これらは、管理者がシステムによって管理されるサービスの特定の特性を構成できるようにするためのインタフェースを提供する。管理されるサービスの特性の例としては、たとえば、ネットワークロケーション（ＩＰアドレスとポート番号）、使用と管理のための暗号、管理者ログイン（ＩＤとパスワード）、管理プロトコル等が挙げられる。好ましい実施形態において、サービスは、管理者インタフェースを通じて定義される管理者が決定する依存性によって関連付けられる他のサービスとまとめられる。サービスコンフィギュレーションアプリケーション１１６は、ユーザ管理ウェブユーザアプリケーションの中で使用されるアカウント情報についてのカスタムフォームを提供する、フォーム生成アプリケーション１１４とのインタフェースを含み、これは、ユーザが他のユーザを追加、変更、削除することのできるウェブベースのユーザインタフェースである。
【００７５】
アプリケーションフレームワーク１０８は、管理者およびユーザアプリケーションを統合するフレームワークである。アプリケーションフレームワークには、システム管理者がアクセスでき、好ましくは使いやすいフォーマットでシステムの管理された内容すべてをグラフィカルに表示するひとつまたは複数のシステムブラウザアプリケーション１１８を含む。ユーザアプリケーション１１０は、エンドユーザがネットワーク上で各種の目的のために使用するアプリケーションである。ユーザアプリケーション１１０は、好ましくは使いやすいフォーマットでデータの組織内での階層をグラフィカルに表示するひとつまたは複数の組織管理アプリケーション１２０を含む。このインタフェースから、組織のユニット、ロケーション、ビジネスパートナーの組織、ユーザ、システムの役割と組織における役割を枝分かれ図として構成し、また変更することができる。ユーザのアクセスレベルに応じて、ユーザは階層の異なる領域を見て、また変更することができる。
【００７６】
システムが複数の組織を管理する実施形態において、ある組織のユーザは他の組織のデータへのアクセスを禁じられる。しかしながら、システム管理者（下記の社員管理者または顧客管理者と混同しないように注意）は、すべての組織のデータにアクセスすることを認められる。ユーザアプリケーション１１０は、ユーザがシステム内の未対応の変更要求を検討し、管理できるようにするためのインタフェースを提供するひとつまたは複数のリクエスト管理アプリケーション１２２を含む。変更要求とは、ユーザのひとつまたは複数の属性を変更するリクエスト、あるいはそのユーザに帰属するサービスのひとつまたは複数の属性を変更するリクエストである。たとえば、このインタフェースにより、ユーザは変更要求を承認または拒否する監督者としての役割を果たすことができる。
【００７７】
ユーザアプリケーション１１０はまた、フォーム生成管理アプリケーション１１４によって設計されたフォームを動的に表示するひとつまたは複数のフォームビューワアプリケーション１２４を備えてもよい。ユーザのアクセスレベルにより、個々の状況においてフォームビューワアプリケーションがどのフォームを表示するかが決まる。ユーザがプラットフォームサブシステム１０４内のレポートエンジンに対し、所定のレポートを作成するよう指示し、結果がユーザに対して表示されるよう、ひとつまたは複数のレポートビューワアプリケーション１２６を含めることができる。ユーザのアクセスレベルに応じて、レポートビューワがどのレポートを提供するかが決まる。
【００７８】
さらに、ユーザアプリケーションには、ユーザが割り当てられたサービスの要求を出すことのできるアプリケーションが含まれる。ユーザアプリケーション１１０はまた、ユーザへのサービスの共有を管理する方針を定義するためのインタフェースを提供する方針管理アプリケーション１２８を含む。このほか、サービスの各属性に関する制約も定義される。方針は、属性とユーザの役割に基づいて、ユーザとサービスまたはリソースの間の関係とそのユーザに割り当てられるサービスに関する制約を決定する。方針は、特定のサービスまたはいずれかのサービスをユーザに割り当てる前に、どのようなひとつまたは一連の承認が必要となるかを決定する。たとえば、監督者として行為する一人または複数の他のユーザに、このような承認を求めることになるかもしれない。方針は、属性に関する制約についての違反があると、ひとつまたは複数の承認を必要としてもよい。承認は、ワークフロー管理アプリケーション１３０を使って定義でき、これはシステム内のリクエストに必要な承認プロセスを決定するインタフェースを提供する。前述のように、プラットフォームサブシステム１０４は、システムの各種のアプリケーションが、システムの状態とそのネットワーク上で利用できるサービスに関する情報を保有するディレクトリやデータベースと対話できるようにするサービスおよびユーティリティモジュールを含む。プラットフォームサブシステム１０４は、たとえば、アプリケーションサービス１３２、データサービス１３４および遠隔サービス１３６等を含む。好ましい実施形態において、プラットフォームモジュールは、ドメイン専用情報とはできるだけ独立して設計される。これにより、プラットフォームは異なるドメインに容易に適用され、まったく（またはほとんど）リアーキテクチャを必要とせずに、新しいアプリケーションセットをサポートすることができる。
【００７９】
アプリケーションサービス１３２は、いくつかの他のシステムアプリケーション（クライアントアプリケーション）がサービスを実行するために使用するモジュールを含む。これらのサービスモジュールは、そのクライアントアプリケーションとは別の、独立した一連の機能を提供する。アプリケーションサービスモジュール１３２は、クライアントアプリケーションが使用する一連の認証インプリメンテーションを提供する認証モジュール１３８を含んでもよい。このようなインプリメンテーションは、たとえば、単純なパスワードによる認証テクニックあるいはＸ．５０９認証等が含まれる。アプリケーションサービス１３２には、許可を受けたユーザが認証ルールを決定することのできるインタフェースを提供し、クライアントアプリケーションがたとえばサービスやデータを要求するなど、システム上の動作を試みたときにこれらのルールを強制する認証モジュール１４０が含まれてもよい。これらのルールは、システム内のデータへのアクセスのほか、追加、変更または削除作業等、システムデータに適用可能な動作にも適用される。
【００８０】
本明細書で説明するＲＰＭシステムやこれと同等の第三者システム等の外部アクセス管理システムへのインタフェースを提供するために、Ｂｕｓｉｎｅｓｓ−Ｔｏ−Ｂｕｓｉｎｅｓｓ（Ｂ２Ｂ）ゲートウェイモジュール１４２を設けることができる。Ｂ２Ｂゲートウェイモジュール１４２により、外部システムは、ユーザ情報の追加、削除、検索を行うことができる。好ましい実施形態において、これらの機能はたとえば、インターネットを通じた安全な通信を可能にするＳｅｃｕｒｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰＳ）等のオープンプロトコルを通じて実行される。
【００８１】
好ましい実施形態において、これらの機能の実行に対する外部システムの要求は、オーディットのために、ＲＰＭデータベースまたはその他の記憶手段１４４の中に記憶される。アプリケーションサービス１３２はまた、アラームや履歴データ等の情報をプラットフォームシステムに関連する永久記憶手段（たとえば、ＲＰＭデータベース１４４）の中にログインするためのユーティリティを提供するロギングモジュール１４６を含んでもよい。アプリケーションサービス１３２はまた、ユーザをサービスと関連付ける方針を実行するポリシーエンジン１４８を含んでもよい。ポリシーエンジン１４８は、共有要求が所定の方針に適合するか否かを判断し、方針と異なる場合に、是正復旧手順を提供する。共有要求について承認が必要な場合、ポリシーエンジン１４８はワークフローエンジン１５０とインタフェースし、たとえば、所定の監督者としての役割を担う一人または複数のユーザである適当な認証提供者に通知し、この認証提供者から認証の指示を受ける。ワークフローエンジン１５０は、システム内のトランザクションを実行、追跡する。このようなトランザクションには、サービスの共有と共有解除、ユーザ状態の変更、システム内の共有要求に関連する承認プロセスが含まれる。
【００８２】
好ましい実施形態において、適当なアクセスレベルを有するユーザは、クライアントアプリケーションを通じて、ワークフローエンジンに対し、システムが実行中のトランザクション（共有要求等）に関する状態情報を求めることができる。アプリケーションサービスモジュールはまた、所定のレポートを作成し、要求された情報のフォーマッティングを行うレポートエンジン１５２も含む。レポートの要求は、システムのユーザまたはシステム管理者からのみ直接発信されることに注意する。これらは、他のシステムからは発信されない。データサービスモジュール１３６は、他のモジュールが、ネットワークの状態とシステムの構成を記憶するディレクトリとデータベースと対話するのを援助するモジュールを含む。データサービスモジュール１３６は、データを保有するデータソースのタイプに関係なく、永久記憶手段の中のデータの論理ビューを提供する情報モデル１５４を含んでもよい。このモデルは、ＬＤＡＰベースのデータモデルの上にオブジェクト指向レイヤを追加することにより、記憶されたデータの詳細をユーザ、グループ、サービス等、より有益な構造の中に抽出する。このモデルはまた、これらの構造に対応するカスタマイズされた属性を容認できるような拡張可能なインタフェースも提供する。
【００８３】
データサービスモジュール１３６は、クライアントがディレクトリスキームのデザインを特定するためのインタフェースを提供するメタデータモジュール１５６を含んでいてもよい。メタデータとは、実際のデータの内容を定義するデータである。これは、クライアントが永久記憶手段の中のデータを動的なアプローチによって管理する場合に使用される。遠隔サービスモジュール１３４は、サービスの共有と共有解除のための外部システムとの対話を提供する。遠隔サービスで記憶された情報とＲＰＭシステムの中に記憶された情報が一致し、また更新されていることを確認するためのプロセスである、サービス情報とユーザ情報の同期もまた、遠隔サービスモジュール１３４によって実行される。
【００８４】
遠隔サービスモジュール１３４は、追加、変更、削除、検索等のメッセージのフォーマット変換を定義し、実行するためのユーティリティを提供するメッセージ変換モジュール１５８を含んでいてもよい。このモジュールは、デリバリプロトコルではなく、メッセージフォーマットを扱う。実際に使用されるプロトコルはランタイムで決定され、たとえば、Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＲＡＭＰ），Ｅｎｃｒｙｐｔｅｄ Ｓｏｃｋｅｔ Ｐｒｏｔｏｃｏｌ（ＥＳＰ），Ｄｅｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ ｏｖｅｒ ＨＴＴＰＳ（ＤＡＭＬ／ＨＴＴＰＳ）等が含まれる。メッセージ変換モジュール１５８は、ＬＤＡＰディレクトリの中で使用されるデータフォーマットと外部システムで使用されるフォーマットとを相互に変換する。どちらのフォーマットも、キーの数値に基づくペアであるが、キーの名前を変換プロセスの一部としてマッピングしなければならない。遠隔サービスモジュール１３４はまた、外部システムを通じて製品とサービスを割り当てるためのアブストラクションレイヤを提供するための共有モジュール１６０を含んでもよい。アブストラクションレイヤは、使用されているプロトコルを共有システムから隠す。上記のような、共有を実行するために使用される具体的なプロトコルは、好ましくは、モジュールのクライアントから分離する。
【００８５】
好ましい実施形態において、モジュールインタフェースを破壊することなく、新しい共有プロトコルをモジュールに追加することができる。遠隔サービスモジュール１３４はまた、外部システムからのサービス情報を呼び出し、システムによって記憶されるサービス情報が常に更新されるようにする同期モジュール１６２を含んでもよい。さらに、同期モジュール１６２は、組織ユニットやユーザ情報等の組織情報を呼び出す。このモジュールは、必要なデータ、その呼び出し方法、その記憶先、呼び出し実行頻度を決定するよう事前設定または構成されていることが好ましい。このモジュールはまた、外部システムから呼び出された情報と現在記憶されているデータの間の矛盾を解消するためのルールも定義する。
【００８６】
システムコンポーネント
システムのコンポーネントの外観の実施形態の一例を図４に示す。図４では、図３の論理アプリケーションとモジュールがシステムコンポーネントの中に組み込まれている。コンポーネントは、システム内の他のコンポーネントとは別にコンピュータとネットワーキングハードウェア上に配置できる、自立、独立型のソフトウェアエンティティである。
【００８７】
図４の実施形態において、アプリケーションとモジュールは、アプリケーションサーバコンポーネント２０２、Ｂ２Ｂサーバコンポーネント２０４、サービスサーバコンポーネント２０６、同期サーバコンポーネント２０８、ウェブサーバコンポーネント２１０およびワークフローサーバコンポーネント２１２を形成するよう配置されている。これらのコンポーネントの各々は、アントラステッドドメイン２１８に対して、トラステッドドメイン２１４と非武装地帯（ＤＭＺ）ドメイン２１６の２つのドメインのうち一方に配置されている。ＤＭＺは会社の内部ネットワーク（トラステッドドメイン）から保護されるが、インターネットからはアクセス可能なコンピュータネットワーク（または単独のコンピュータ）である。ＤＭＺドメイン２１６は、インターネットからアクセス可能なシステムを含み、社内ネットワーク（トラステッドドメイン）にアクセスすることができる。ＤＭＺドメイン２１６は通常、機密情報や重要なシステムを含まない。ＤＭＺドメイン２１６は、ハッカーがＤＭＺの中に侵入したとしても、さらにＤＭＺから社内ネットワークに侵入しなければならないように構成されている。ＤＭＺをハッカーから保護するよう万全が期されているが、ＤＭＺにおけるセキュリティが破られたことによってデータの盗難や破壊あるいは重要なシステムの喪失が発生してはならない。社内ネットワークであるトラステッドドメインは、これよりはるかに機密性が高いと考えられる。トラステッドドメインへの侵入は、セキュリティの重大な侵害とみなされる。
【００８８】
アプリケーションサーバコンポーネント２０２は、たとえばウェブサーバコンポーネント２１０を通じて、システムとインタフェースするユーザをサポートするためのモジュールで構成される。アプリケーションサーバコンポーネント２０２は、安全なＲｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ（ＲＭＩ）のような安全な接続を通じて、接続ウェブサーバコンポーネント２１０とワークフローサーバに連結される。アプリケーションサーバコンポーネント２０２は、図３に示されるアプリケーションサービス１３２とデータサービスモジュール１３６の認証、許可、レポートエンジンおよびロギングモジュールを含む。好ましい実施形態において、アプリケーションサーバコンポーネントはまた、アプリケーションサービスモジュールを提示するためのロジックを実行し、ウェブサーバコンポーネントができるだけシンプルなままですむようにする。これは、アプリケーションモジュール用のセキュリティ上の境界も提供する。好ましい実施形態において、アプリケーションサーバへの各要求（割り当てられるサービスに対するユーザからの要求）は、それが実行される前に認証、許可される。このレベルにおいて、認証には、有効なウェブサーバがその要求を行っているかどうかを判断するために、適正なシステム証明だけで十分である。しかしながら、要求が実行する前に要求するユーザの認証を必要とすることにより、ウェブサーバコンポーネントはアントラステッドドメインに留まる。
【００８９】
Ｂ２Ｂサーバコンポーネント２０４は、本明細書で説明するタイプの別の共有システムまたは、プラットフォームシステムに要求を伝える第三者の共有システム等の外部システムとのインタフェースを提供するモジュールで構成される。図の実施形態において、Ｂ２Ｂサーバコンポーネント２０４は、Ｂ２Ｂゲートウェイモジュール１４２と、Ｂ２Ｂ要求を認証するための認証モジュール（図３の参照記号１３８参照）を備えている。インタフェースは、データ転送を暗号化し、要求発信者を認証するため、ＨＴＴＰＳ等の安全ネットワークプロトコルを使って提供される。好ましい実施形態において、すべての要求発信者は、要求が実行される前に認証、許可されなければならない。Ｂ２Ｂサーバコンポーネントはまた、好ましくは安全なＲＭＩ接続等の安全な接続手段を通じてワークフローサーバ２１２に連結される。サービスサーバコンポーネント２０６は、管理されたリソース２６，６６とのインタフェースおよびシステムに任意の警告または非同期共有確認を発行するサービスを提供するモジュールで構成される。
【００９０】
サービスサーバコンポーネント２０６は、たとえばＤＡＭＬ／ＨＴＴＰＳ接続を通じて、管理されたサービスリソース２６，６６に接続されてもよい。さらに、サービスサーバコンポーネント２０６は、ＨＴＴＰＳ接続またはベンダ専用接続等の適当な接続手段を通じて顧客データベース２４のようなデータベースと第三者のサーバプロバイダシステム２８，６４に接続される。サービスサーバコンポーネント２０６は、安全なＲＭＩ接続等の安全な接続手段を通じて、同期サーバ２０８とワークフローサーバ２１２コンポーネントのそれぞれ同期および共有モジュールと対話する受信ロジックを提供するノーティフィケーションゲートウェイモジュールを含む。ノーティフィケーションゲートウェイモジュールを同期および共有モジュールから分離することにより、アントラステッドドメインとトラステッドドメインの間にセキュリティ上の境界ができる。
【００９１】
好ましい実施形態において、すべての要求発信者は、トラステッドドメイン内のモジュールに情報を送る前に、認証、許可を受けなければならない。動機サーバコンポーネント２０８は、サービスプロバイダ２８，６４およびローカルデータレポジトリの間のサービス情報を定期的に同期するためのモジュールを含む。同期サーバコンポーネント２は、所望の情報を抽出するためにサービスプロバイダのインタフェースに適応するよう構成される。同期サーバコンポーネント２０８は、図３に示される遠隔サービス１３４の同期およびメッセージ変換モジュール、アプリケーションサービス１３２の認証、許可、ロギングモジュール、データサービスモジュール１３６を含む。ウェブサーバコンポーネント２１０は、ユーザにグラフィカルインタフェースを提供するモジュールを含む。ウェブサーバコンポーネントは、エンドユーザ向けのウェブページを制作するアプリケーションプレゼンテーションモジュールと、アプリケーションサービスモジュールグループ１３２の認証モジュールを含む。ウェブサーバコンポーネントは、たとえばＨＴＭＬ／ＨＴＴＰＳ接続により、クライアントシステム１６，５２に接続される。
【００９２】
好ましくは、すべてのクライアントは、システムに要求を行う際に認証される。たとえば、ウェブサーバは、ＨＴＴＰＳを使用するとき、パスワード認証、Ｘ．５０９認証またはその両方を必要とするよう構成される。ワークフローサーバコンポーネント２１２は、システム内の共有および共有解除サービス用のモジュールを含む。ワークフローサーバコンポーネントは、アプリケーションサービスモジュールグループ１３２のポリシーエンジン、ワークフローエンジン、ロギング、電子メール、認証および許可モジュール、データサービスモジュール１３６および遠隔サービスモジュールグループ１３４の共有およびメッセージ変換モジュールを含む。
【００９３】
システムコンポーネントの配置
図４の実施形態のコンポーネント２０２−２１２は、さまざまな方法でハードウェア（プロセッサまたはコンピュータシステム）内に配置できる。コンポーネントは、たとえばシステムの複雑さと運用コストを最小限にするために、できるだけ少ないプロセッサ上に配置する。あるいは、コンポーネントの一部または全部を分離して別のプロセッサに分散させ、演算リソースを最大限にすることもできる。コンポーネント内のモジュールとアプリケーションの多くを分散させ、さらに演算能力を高めることも可能である。さらに、コンポーネントの一部または全部をいくつかのかたまりに構成し、ロードバランシングアルゴリズムとフェイルオーバー機能を利用してもよい。
【００９４】
システムの配置を構成する責任は、システム管理者に割り振ることができる。したがって、上記のアプリケーションまたはモジュールグループを含むアプリケーション、モジュールまたはコンポーネントは、たとえば、ソフトウェアの形態（コンピュータによる読み出し可能な記憶媒体等）、ハードウェアまたはファームウェアの形態（コンピュータシステムに取り付けられる回路板またはカード等）またはその組み合わせによってシステム管理者に提供される。次にシステム管理者は、組織のパフォーマンスおよびセキュリティ上のニーズを満たすような配置戦略を立て、所望の戦略に適合する適当なハードウェアデバイス上に適当なモジュールを配置する。システム管理者は自由に、システムのコンポーネント全部をひとつのプロセッサ上に配置するか、あるいは希望に応じて、ほとんどあらゆる組み合わせで、各コンポーネントのかたまりを分散させてもよい。
【００９５】
単純な配置例を図５に示す。この図では、図４の６つのコンポーネント２０２−２１２がプラットフォームシステムを構成するひとつのプロセッサ３０２の上にかたまり状に配置されている。つまり、プロセッサ３０２は、本明細書で説明する本発明の実施形態による共有システムを実行するサーバを示す。プラットフォームプロセッサ３０２は、ウェブサーバロードバランサ３０８を通じて、ネットワーク３０６上で外部システムとクライアントに接続される。ひとつまたは複数のデータサーバプロセッサ３０４は、ＲＰＭディレクトリとＲＰＭデータベースを配置するためのプラットフォームプロセッサ３０２に接続される。データサーバプロセッサ３０４は、リレーショナルデータベースサーバとＬＤＡＰディレクトリサーバを実行するサーバを備える。
【００９６】
図５の実施形態は、システムのすべてのコンポーネントを配置するサーバのかたまり状の配置で単純な配置を表している。ロードバランシングアルゴリズムが、特定のプロセッサ上でどのコンポーネントを実行するかを決定する。しかしなから、このような配置例では、上述のように、コンポーネントが別のトラステッドドメインの別のハードウェア上に配置されないため、セキュリティ上のリスクがある。
【００９７】
別の配置例を図６に示す。図６の配置は、図５のものより複雑ではあるが、図５の配置に伴うセキュリティ上の問題のいくつかが回避される。図４におけるＤＭＺドメイン内に示され、インターネットを通じて外部クライアントとシステムとインタフェースするコンポーネント２１０，２０４，２０６がすべて、図６のひとつまたは複数の専用ウェブサーバプロセッサ４０２にかたまって配置され、アントラステッドドメインとトラステッドドメインの間に境界が設けられ、ウェブクライアントはアントラステッドドメインに、システムコンポーネントの残りはトラステッドドメインにあることになる。同期サーバコンポーネント２０８は別のかたまりに配置され、サービスプロバイダとの通信が他のかたまりとは別に構成できるようになっている。
【００９８】
このように、外部クライアントとシステムへのインタフェースは、システムが害でとのインタフェースに必要とするコンポーネントだけを含むひとつまたは複数のサーバに分離する。システムのその他のコンポーネント、たとえば安全に保持しなければならないコンポーネントは、外部のクライアントやサーバとインタフェースしないサーバ上に設置する。このように、その信用性が検証されていないシステムの外部ユーザは、システムの安全部分からは分離し、システム内の別のサーバ上に設置されたシステムの安全部分の完全性が保護されるようにする。
【００９９】
システム機能エリア
以上、一般的なシステムと、システムを作動させる環境の例を含む、システムのさまざまな面を説明したところで、システムの特徴を機能エリアにまとめることができることが理解できるであろう。システムの中に含めることのできる機能エリアのいくつかを以下に説明するが、これらはシステムが使用できる機能エリアのタイプの例にすぎない。たとえば、承認のための署名を定義し、これを強制するためのすべての要求事項を承認管理機能エリアに分類できる。別の例として、認証および許可機能エリアには、システムへのユーザ認証とシステム内の機能とデータへのユーザによるアクセスの管理に関するすべての要求事項が分類される。システムの機能エリアのさらに別の例として、ビジネスパートナー機能エリアには、ビジネスパートナーの関係を管理するためのすべての要求事項が分類される。Ｂｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓ機能エリアには、企業間取引のためのすべての要求事項が分類される。これは、パートナーとサービス加入者のシステムとのすべての外部インタフェースが含まれる。
【０１００】
外部データ入力機能エリアには、既存のユーザとリソース等、現在の顧客情報をシステム内に取り入れるためのすべての要求事項が分類される。組織管理機能エリアには、組織の追加、変更、削除のためのすべての要求事項が分類される。ポリシーベース共有機能エリアには、属性または役割、グループ、組織ユニットまたは組織内のユーザの地位に基づいてサービスの共有を決定するためのすべての要求事項が分類される。レポート生成機能エリアには、システムが提供するレポート機能のためのすべての要求事項が分類される。サービス管理機能エリアには、システムが割り当てるサービスを定義するためのすべての要求事項が分類される。システム管理機能エリアには、システムを構成するためのすべての要求事項が分類される。これには、システムを設置し、その構成パラメータを変更するための要求事項が含まれる。ユーザインタフェースカスタマイゼーション機能エリアには、ユーザにユーザインタフェースをカスタマイズする能力を提供するためのすべての要求事項が分類される。ユーザ管理機能エリアには、ユーザの追加、変更、削除のためのすべての要求事項が分類される。システムユーザのニーズに基づき、その他の機能エリアを作ることもできる。
【０１０１】
システムの動作
システムの特定の動作の例を図７Ａ−７Ｅのシーケンス図で示す。図７Ａは、システムへのユーザ認証を実現するための動作のシーケンス図である。認証が終了したところで、ユーザにはシステム動作を実行するためのアプリケーションインタフェースが提示される。図の実施形態において、ユーザには、組織管理アプリケーションへのインタフェースが提示される。図７Ｂは、システムにユーザを追加するための動作のシーケンス図である。図７Ｃは、あるユーザにとっての要求に応じたサービスの共有を実現するための動作のシーケンス図である。図７Ｄは、サービスデータを遠隔ホストと同期し、遠隔ホストに加えられた変更を検出することにより、侵害されていた方針を強制するための動作のシーケンス図である。図７Ｅは、システムにユーザを追加し、共有方針に基づいてそのユーザにサービスを割り当てるための動作のシーケンス図である。
【０１０２】
本発明の実施形態において、ユーザ共有は、前述のＲＰＭシステムによって実現され、これは、組織のＬＡＮに接続されたサーバの中にプログラムされ、好ましくはインターネットであるＷＡＮにも接続される。役割にのみ基づいて「ソフト」のリソース（アカウント等）をユーザに割り当てるＲＢＡＣと異なり、ＲＰＭは、ユーザの役割と属性に応じて定義される方針に基づいて「ハード」と「ソフト」、両方のリソースをユーザに割り当てる。
【０１０３】
したがって、本発明の好ましい実施形態において、ＲＰＭシステムは、たとえばパスワード、電子メールおよび電子メールアカウント、アプリケーションプログラム、データベース、ファイル、フォルダ、インターネット、ウェブページ、組織内イントラネット等、「ソフト」のリソースをユーザに割り当てる。その他の、より一般的でない「ソフト」のリソースには、第三者へのメッセージ、ユーザが暗号化されたリソースにアクセスするのを可能にするためのデジタル認証、インターネット上での製品注文機能、企業クレジットカードの注文機能、金融サービスプロバイダへのアクセス等がある。
【０１０４】
さらに、ＲＰＭは、電話、コンピュータ、携帯電話、ページャ、携帯用通信端末、机、椅子、ファイルキャビネットおよびその他の物理的コンポーネント等の「ハード」のリソースを割り当てる。ＲＰＭは、一般的に一緒に割当てられる、事前にパッケージされたリソース群であるリソースのまとまり（バンドル）を提供することもできる。たとえば、リソースのまとまりには、携帯電話、電話サービス、ページャアカウント、ボイスメール、インターネットアクセスがある。バンドルアカウントの別の例としては、Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ（ＤＳＬ）アクセスとＩｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ（ＩＳＰ）アカウントがある。
【０１０５】
本発明の実施形態によるＲＰＭシステムはまた、ユーザの役割や属性が変化した場合、共有解除等、共有の調整を行う機能を備え、特に、ユーザが会社を辞めた場合、割り当てられたすべてのリソースを共有解除する。
【０１０６】
本発明の好ましい実施形態において、ＲＰＭシステムは、役割や属性に基づいて決定された方針に基づき、ユーザにリソースを割り当てる。役割とは、組織におけるその人の責任であり、マネージャ、秘書、システム管理者、委員等の役職が含まれる。各役割には２つの数値しかない。たとえば、あるユーザがマネージャであるか（「イエス」の数値）、そうでないか（「ノー」の数値）。属性とは、「移動に費やす時間」、「費用」といった、ユーザまたはリソースの特性または質である。役割と異なり、各属性には複数の数値がある。たとえば、「移動に費やす時間」という属性には、「３０％未満」、「３０％から６０％の間」、「６０％超」等の数値がある。方針はこれらの役割と属性に基づいて書かれる。方針を決定するために、役割のほかに属性が用いられるため、ユーザとリソースの間の関係を定義する作業が効率化される。属性は、複数の数値を取りうるため、ＩＦ−ＴＨＥＮの条件文を使った複数の役割の定義ではなく、ＩＦ−ＴＨＥＮ−ＥＬＳＥ ＩＦの条件文を使ったブール型（またはこれと同等のもの）で、単独の方針定義を書くことができる。ＩＦ−ＴＨＥＮ−ＥＬＳＥの条件文はここでは一例として挙げたが、本発明の実施形態においては、ブール型の条件文に匹敵するものを実現できる、いかなるプログラム言語やシンタックスでも使用できることに注意すべきである。
る。
【０１０７】
簡単な例を挙げる。役割に基づくシステムが次の３つの役割を定義したとする。
【表１】
Figure 2005503596
【０１０８】
今度は、新規社員であるユーザＡはマーケティングマネージャであり、移動時間が３０％未満であるとする。また、新規社員であるユーザＢは、マーケティングマネージャであり、移動時間が３０％から６０％の間であるとする。役割に基づくシステムは、ユーザＡには役割１，３が当てはまり、ユーザＡにはページャと売上額のデータベースへのアクセスを割り当てるべきであると判断する。役割に基づくシステムはまた、ユーザＢには役割２，３が当てはまり、ユーザＢには携帯電話と売上額のデータベースへのアクセスを割り当てるべきであると判断する。
【０１０９】
次に、本発明の実施形態による方針ベースのシステムが次のように２つの方針を定義したとする。
【表２】
Figure 2005503596
【０１１０】
方針に基づくシステムは、方針１，２がユーザＡに当てはまり、ユーザＡにはページャと売上額のデータベースへのアクセスを割り当てるべきであると判断する。方針に基づくシステムはまた、方針１，２がユーザＢに当てはまり、ユーザＢには携帯電話と売上額のデータベースへのアクセスを割り当てるべきであると判断する。
【０１１１】
上記の例から、本発明の実施形態では、複数の属性の数値をカバーするひとつの方針を定義できるため、役割に基づくシステムにおいて定義しなければならない役割の数と比較して、少ない数の方針だけ定義すればよいことがわかる。上記の単純な例において、方針に基づくシステムの方針１は、役割に基づくシステムの役割１と２の代わりとなる。評価すべき方針が少ないと、使用するメモリも少なくて済む。
【０１１２】
さらに、好ましい実施形態において、リソースの決定がより迅速に実行できる。上記の単純な例において、ユーザＡを評価する際、役割１，２における両方のＩＦ−ＴＨＥＮの条件文を評価してからでなければ、役割に基づくシステムはユーザ１に役割１が当てはまり、役割２が当てはまらないと判断することができない。これに対し、方針１における「ユーザの移動時間が３０％未満であると」の条件文があっていることがわかれば、方針１のＥＬＳＥ ＩＦの条件文は飛ばすことができる。前述のように、ユーザに関する役割と属性は、ユーザの業務開始日以前に人事担当者または組織の他の社員が割り当てることができる。本発明の好ましい実施形態において、ユーザの共有は、組織のネットワークに接続されたウェブブラウザ上の共有ユーザインタフェース（スクリーン）を呼び出すことによって開始できる。このスクリーンにより、人事担当者は、わかっている役割と属性を入力できる。すると、ＲＰＭシステムは記憶された方針を検索し、ユーザの役割と属性に基づいて、割り当てるべき一連のリソースを判断することができる。あるいは、人事担当者が単純に人事（ＨＲ）システムデータベースに社員情報を入力すれば、ＲＰＭシステムはダイレクトフィードを使ってこのデータベースから自動的に情報を引き出し、共有プロセスを開始する。さらに、業務開始日その他の日時情報を入力し、この日時情報によってトリガーされたときにＲＰＭシステムが共有作業を開始することもできる。
【０１１３】
実際のリソースの共有には、電子通信や人の介入がかかわる。たとえば、特定の日付までに特定のオフィスに机と椅子を届けるために、それぞれのオフィス担当者に電子メールが送信される。また、その後の日付までに、オフィスにコンピュータと電話を届け、また別の日付までにコンピュータアカウントをイネーブルし、各種のアプリケーションとデータベース、電子メール、ボイスメールを提供するよう、別の電子メールがＩＴ担当者に送信される。ＷＡＮ上の遠隔サイトから管理されるリソースについては、ＲＰＭシステムは、これらのリソースがたとえばアカウントを追加、アカウントを削除またはアカウント内のアクセス権を変更するよう、リソースエージェントに対し、ＷＡＮ上で電子通信が送信される。このような通信は、適当なＷＡＮプロトコルにしたがって行われ、これは、インターネット環境においては、好ましくはＨＴＴＰＳトンネリングとする。
【０１１４】
外部調達サービス会社もまた、共有作業の一部または全部について採用される場合がある。さらに、ＡＳＰ等の外部システムが保持するアカウントの共有はＲＰＭシステムと、外部システム内のサーバの中にある「エージェント」ソフトウェアとの間の通信によって促進される。「エージェント」はポータルとして機能し、外部システムからのアカウントはこのポータルを通じて管理、アクセスされる。ユーザに一連のリソースが割り当てられると、これらの既存のリソースのリストはＲＰＭシステムによって維持される。その後、ユーザの役割や属性が変化した場合、方針が再評価され、割り当てられるリソースの新たなリストが作られる。この新しいリソースリストは既存のリソースリストと比較され、その違いに応じて、そのユーザへの共有または共有解除が行われる。
【０１１５】
好ましい実施形態において、特定の既存のリソースが新規リソースリストにも入っている場合、ＲＰＭシステムはこのリソースについては共有解除してから共有するのではなく、変更しない。ユーザの退職、停職にあたり、あるいはユーザが休暇をとった、または休職した場合、本発明の実施形態はやはりリソースの共有解除を行うのではなく、リソースの共有を停止する。たとえば、退職したユーザが会社を相手取って裁判を起こそうとしている場合、そのユーザの電子メールアカウントは停止するが削除せず、ユーザが電子メールにアクセスすることはできないが、会社は訴訟を予想してその電子メールを見ることができるようにしておく。
【０１１６】
本発明の実施形態において、ＲＰＭシステムが最初に呼び出されたときに、照合確認プロセスが実行される。照合確認において、ＲＰＭシステムは現在割り当てられているリソースのリストを、各ユーザの役割と属性の現状に基づいてすでに割り当てられているべきリソースのリストと比較する。２つのリストの相違は、共有または共有解除によって解決する。
【０１１７】
上記の例はユーザの属性（「移動に費やす時間」）を説明したが、本発明の実施形態において、ＲＰＭシステムはリソースの属性も維持することができる。リソースの属性は、共有プロセスによってリソースの選択が可能になる場合に役割を果たす。たとえば、ユーザが組織で業務を開始すると、そのユーザは共有ユーザインタフェーススクリーンを呼び出し、オプションのリソースを要求することができる。追加情報を入力すると、そのユーザが特定の属性の数値を持っていれば、オプションのリソースを選択できる。この例で説明を続ければ、ユーザＡ（マーケティングマネージャで、移動時間は３０％未満であり、自動的に携帯電話が与えられることはない）はそれでも、その他の特定の役割と属性を満たせば、携帯電話を要求することができる。ユーザＡは共有スクリーンを呼び出し、「クライアントのロケーション」の属性に「ヨーロッパ」と入力する。共有スクリーンには、ユーザＡに対し、携帯電話のいくつかの選択肢が表示される。ユーザＡが２００ドル未満の携帯電話を選択すると、「２００ドル未満」という数値を有する「携帯電話の費用」の属性がユーザと関連付けられ、システムは、たとえば、携帯電話プロバイダに電子メールの注文を送ることにより、自動的にその電話をユーザＡに割り当てる。しかしながら、選択された電話がいわゆる「ワールドフォン」のような２００ドル以上のものであった場合、「２００ドル以上」の数値を有する「携帯電話の費用」の属性がユーザＡに関連付けられ、承認が必要となる。たとえば、電子メールが副社長に送信され、副社長に共有スクリーンへのアクセスが提供され、電話を承認するかしないかを入力するよう求められる。この情報が提供されると、ＲＰＭは電話を注文するか、あるいはユーザに拒絶のメッセージを送信する。ＷＡＮ上の遠隔サイトから利用できるリソースを含めた、他のタイプのリソースについても同様の手順がとられる。
【０１１８】
この例をカバーする方針の定義の一例は次のとおり。
【表３】
Figure 2005503596
【０１１９】
リソース属性の他の例としては、色、機能、メーカー等がある。上述のように、本発明の実施形態には、共有を続ける前に別の人物からの入力が必要となる場合がある。別の例で説明すれば、新規社員がシステムに入ると、人事担当者は、新規社員の配属部署等のわかっている役割と属性を入力し、このとき、方針は共有スクリーンへの情報の入力を停止し、その部署のマネージャに電子メールを送信して、同マネージャに共有スクリーンへのアクセスを提供し、作業部屋またはオフィスのロケーションを入力するよう要求する。この情報が提供されると、人事担当者に通知され、そのオフィスへの机、椅子その他の割当が再開する。
【０１２０】
より一般的に、共有シーケンスのどの時点においても、方針は、別の人物に対して共有を再開する前に新規社員の役割、属性、職務内容等を提供するよう要求する。上記の例は、別の人物に情報または承認を求める、あるいはリソースを注文するための手段として電子メールを用いたが、ウェブページへのハイパーリンクやオンラインリソースプロバイダオーダーシートを使ったインターネット上での自動リソース注文等、他の通信手段も使用できると理解すべきである。
【０１２１】
前述のように、本発明の実施形態において、共有プロセスは一連のステップであり、その一部には、情報または認証の提供等、人間の介入が必要となる。このシーケンスの例を次に紹介する。図８において、ひとつまたは複数のリソースの割当を希望するユーザは、ネットワーク化されたコンピュータから共有ユーザインタフェーススクリーン７００にアクセスする。本発明の実施形態において、共有スクリーン７００には説明文と、情報を入力するためのボックスまたはフィールドが含まれる。ユーザは、フィールドに情報を打ち込む、あるいは所定の選択肢のプルダウンメニューから選択する。たとえば、ユーザが自分の苗字と名前を入力するためのフィールド７０２，７０４や利用可能なリソースのプルダウンメニュー７０６が設けられている。別の実施形態において、共有スクリーン７００には、オプション情報のためのフィールド、要求するユーザが知らない（したがって、別の人物が提供しなければならない）必要な情報のためのフィールド等がある。しかしながら、好ましい実施形態において、要求するユーザに見える共有スクリーンには、ユーザが提供できる情報のフィールドだけが設けられる。
【０１２２】
図８の例で説明を続けると、ユーザが電子メールアカウントを要求すると仮定する。本発明の実施形態において、ＲＰＭが共有スクリーンをマネージャに送信する、マネージャに対し、共有スクリーンを見るよう特定のハイパーリンクへのアクセスを電子メールで伝える、あるいはその他の方法で、共有の要求を処理する。参照番号７０８で表される部門マネージャは、要求するユーザとは異なる共有スクリーン７０８を見ることができる。たとえば、共有スクリーン７０８には、マネージャが要求を承認または拒否することができ、承認された場合に、どの部門が承認を与えたかを入力するための別のフィールド７１０，７１２がある。
【０１２３】
図８の例で説明を続けると、承認されると、共有スクリーンはＩＴ部門に伝えられ、ＩＴ部門は部門マネージャとは異なる共有スクリーン７１４を見ることができる。たとえば、共有スクリーン７１４には、ＩＴ担当者が部門情報に依存し、部門マネージャが知らない特定のメールサーバを指定するための別のフィールド７１６がある。前の例が示しているように、本発明の好ましい実施形態において、オプションによる共有プロセスを管理するためのソフトウェアが個人によってどの情報が提供されるか、どの個人が許可または拒否権を持っているか等を決定することができる。共有プロセスはまた、誰が情報を変更でき、どの情報が変更できないかを決定することもできる。共有プロセスはまた、共有要求を次の人物に送る前に、どの情報を追加しなければならないかも決定する。別の実施形態においては、共有要求を要求するユーザに返送し、追加情報や既存情報の変更（つまり、リソース要求の変更）を求めることもある。好ましい実施形態おいて、認証権は、要求フィールドに何が入力されたかによって異なる。
【０１２４】
このように、このリクエストフォームが流れる処理経路はひとつではない。処理経路は実際に、リクエストフォームのフィールドにどのような情報が入力されたかによって、異なる方向に枝分かれする。この流れを総称してワークフロープロセスという。したがって、本発明の実施形態は、ユーザの役割と属性という点で決定され、考案しなければならない固有の役割数が少なくて済む方針に基づいてユーザへの共有を行うシステムと方法を提供する。さらに、本発明の実施形態は、「ソフト」と「ハード」両方のリソース、遠隔ＷＡＮサイトで管理されるリソースおよびリソースのバンドルの共有を可能にする方針に基づいてユーザへの共有を行うシステムと方法を提供する。本発明の実施形態はまた、ユーザパラメータを入力した結果として確立され、別の人物からの情報または認証を必要とするかもしれない各種の処理経路を利用する方針に基づいてユーザへの共有を行うシステムと方法を提供する。本発明の別の実施形態は、特定のユーザが、ユーザの役割、方針、属性、組織情報に基づいて、遠隔ＷＡＮサイトからワークフローの定義を追加、削除または変更することを可能にする。
【０１２５】
ＲＰＭサービスプロバイダとして第三者を使ったシステムの動作
これまでに説明した本発明の実施形態は、図９においてごく簡単に示されている。第一の組織８００は、第一の組織のエージェント８０４を通じてリソースとインタフェースすることにより、第一のサーバ８０２を使ってリソース（図示せず）を割り当てる。これと独立して、第二の組織８０６は、第二の組織のエージェント８１０を通じてリソースとインタフェースすることにより、第二のサーバ８０８を使ってリソース（図示せず）を割り当てる。この構成において、２つの論理上のサーバおよびおそらくははるかに多くの物理的サーバが、同じ目的のために２つの独立したベンダによって利用されていることに注意されたい。この構成は一般的であり、必要かもしれないが、多くの環境においては冗長である。
【０１２６】
本発明の別の実施形態を図１０に示す。ここでも第一の組織８００はリソースを割り当てるが、サーバを使ってリソースを割り当てるのではなく、第一の組織８００は、第三者のサーバ８２０を運営する第三者ＲＰＭサービスプロバイダにリソースを割り当ててもらう。第一の組織８００は、たとえばインターネット等のネットワーク８２２を通じて、第三者のサーバ８２０とインタフェースする。同様に、第三者ＲＰＭサービスプロバイダは、ネットワーク８２２を通じて第一の組織のエージェント８０４とインタフェースし、第一の組織８００のためのリソースを割り当てる。同様に、第二の組織８０６は、第三者ＲＰＭサービスプロバイダにより、ネットワーク８２２を通じて第三者のサーバ８２０を使ってそのリソースを割り当ててもらう。第三者のＲＰＭサービスプロバイダは、ネットワーク８２２を通じて第二の組織のエージェント８１０とインタフェースし、第二の組織８０６のためのリソースを割り当てる。このように、両方の組織８００，８０６は、第三者ＲＰＭサービスプロバイダが運営、管理するひとつの論理サーバ８２０を利用する。
【０１２７】
本発明のこの実施形態によれば、２つの組織はネットワーク８２２上で第三者が運営する単独の第三者論理サーバ８２０の効率のよさを利用し、リソース共有活動のためにサーバを購入、運用することにかかわる費用を省くことができる。また、第三者ＲＰＭサービスプロバイダは、データセンターとして機能し、組織８００，８０６に対して管理されたサービスとしてリソース共有を提供するため、組織８００，８０６は第三者ＲＰＭサーバプロバイダの顧客となる。管理されたサービスは加入ベースで提供され、これにより、このようなサービスを希望する組織は、そのリソース共有のニーズすべてについて、一定の期間料金を支払う。たとえば、第一の会社はその営業担当者に電子メールアカウントとその顧客データベースへのアクセスを提供することを方針としていると仮定する。また、この第一の会社は、そのリソース共有を、委託された第三者ＲＰＭサービスプロバイダにアウトソースすることにしたとする。第二の会社は、全社員にそのネットワーキングオペレーティングシステム上のアカウントを割り当てることを方針とし、第二の会社もまたリソース共有を、委託された第三者ＲＰＭサービスプロバイダにアウトソースすることにしたとする。どちらも、その委託した第三者ＲＰＭサービスプロバイダに、関係する社員情報と第一の会社の営業担当者と第二の会社の社員に認められるアクセス権の性質を提供する。
【０１２８】
これらの情報は、たとえばインターネット等のネットワーク上で、両方の会社から委託された第三者ＲＰＭサービスプロバイダに提供される。委託された第三者ＲＰＭサービスプロバイダは、その単独または複数のサーバ上でこれらの情報を維持する。これにより、委託された第三者ＲＰＭサービスプロバイダは新しい営業担当者または新規社員に必要なリソースを即座に割り当てることができる。このような共有を行うために必要なのは、各会社が委託された第三者ＲＰＭサービスプロバイダに対し、営業担当者または社員情報の変更を提供することだけである。このような変更に基づき、委託された第三者ＲＰＭサービスプロバイダは、アカウントを設置、変更または削除する、あるいは必要なリソースに関する共有をその他変更することができる。あるいは、各会社は、委託された第三者ＲＰＭサービスプロバイダに、共有をどのように変更する必要があるかを正確に伝える。
【０１２９】
図１０の実施形態を実現する方法を詳細に示すフローチャートが図１１Ａである。ステップ８３０において、第三者ＲＰＭサービスプロバイダが共有サービスへの要求を受け取る。このような要求は、そのサービスを必要とする１社または複数の会社から行われる。要求は、会社の担当者と第三者ＲＰＭサービスプロバイダの担当者との間で電子的手段を介して、あるいは個人的接触によって行われる。ステップ８３４で、第三者ＲＰＭサービスプロバイダは、要求を行う会社からユーザ情報を受け取る。この情報には、たとえば、ユーザ名、ユーザ番号、ユーザがアクセスできるリソースのリスト、アクセス権の性質その他が含まれる。この情報は、たとえばインターネット等のネットワークを使って、顧客から第三者ＲＰＭサービスプロバイダに電子的に送信される。ステップ８３６において、第三者ＲＰＭサービスプロバイダはまた、ユーザが適当なリソースにアクセスする許可を受けたというノーティフィケーションを顧客から受け取る。この情報も、たとえばインターネット等のネットワークを使って、顧客から第三者ＲＰＭサービスプロバイダに電子的に送信される。ステップ８３８において、第三者ＲＰＭサービスプロバイダはエージェントを通じて単数または複数の関連するリソースをユーザに割り当てる。このステップでは、必要な共有を実現するために多くのシステムが割り当てられることに注意すべきである。このような共有はネットワーク上でも行われる。単数または複数のリソースがユーザに割り当てられると、ステップ８３９でユーザにはそのように伝えられ、その後ユーザは、その雇用主が確立した共有方針に従って、リソースを自由に利用することができる。このプロセスは、そのリソースの共有を第三者ＲＰＭサービスプロバイダに要求する各社にとって必要な回数だけ繰り返される。
【０１３０】
図１０の実施形態を実現するための別の方法を詳細に示したフローチャートが図１１Ｂである。ステップ８３１で、第三者ＲＰＭサービスプロバイダはユーザ情報の変更を受け取る。変更は、たとえばインターネット等のネットワーク上で電子的手段によって、あるいは会社と第三者ＲＰＭサービスプロバイダの担当者同士の個人的接触によって受け取られ、たとえば、ユーザ名、ユーザの役割、ユーザの組織、ユーザの役職、ユーザのロケーション等の変更である。また、これらの変更は自動的にも受け取られる。たとえば、会社の人事データベースの変更が、第三者ＲＰＭサービスプロバイダに自動的に送信されるか、あるいは受信されるようなメカニズムを実現することができる。ステップ８３２において、第三者ＲＰＭサービスプロバイダは、受け取ったユーザ情報の変更に基づき、リソースアクセス権にどのような変更が必要かを判断する。これは、ユーザ情報の変更を送信する会社とは独立して行われる。ステップ８３３において、第三者ＲＰＭサービスプロバイダは、その共有を実行する前に必要な承認を得る。ステップ８３５において、必要な承認が得られると、第三者ＲＰＭサービスプロバイダは、エージェントを通じて、ユーザのための関連するリソースの共有を行い、これにはたとえば共有解除も含まれる。このステップで、必要な共有を実行するために、多くのシステムが割り当てられる。また、リソースを平行して割り当てることもできる。これらの共有は、ネットワークを通じて行ってもよい。ひとつまたは複数のリソースがユーザのために割り当てられると、ステップ８３７でユーザにその旨通知され、その後、ユーザは雇用主が決定した共有方針に従って自由にそのリソースを使用することができる。
【０１３１】
図１０の本発明の実施形態において、割り当てられるリソースは顧客の「情報テクノロジー」スペースにすべて含められる。つまり、割り当てられるリソースは、必ずしも顧客のサイトに存在するとは限らず、顧客の領域内にある、あるいは顧客が管理しているかもしれない。たとえば、これらのタイプのリソースには、電子メール、オペレーティングシステム、データベース等がある。これらのリソースは世界中に存在し、しかも顧客が管理する。
【０１３２】
図１０の実施形態を改良したものを図１２に示す。この実施形態において、第一の組織８００と第二の組織８０６の外部にあるリソース８４０には両方の組織、８００，８０６がネットワーク８２２を通じてアクセスし、これを利用することができ、第三者ＲＰＭサービスプロバイダは第三者のサーバ８２０を使って両方の組織８００，８０６のためにこれらのリソースを割り当てる。第三者ＲＰＭサービスプロバイダと組織８００，８０６は、エージェントを通じてこれらのリソース８４０とインタフェースする。
【０１３３】
たとえば、図１０の例で説明を続けると、第一の会社と第二の会社がその管理職レベルの社員全体に、たとえばＡＭＥＲＩＣＡＮ ＥＸＰＲＥＳＳカード等のクレジットカードアカウントを提供するものとする。また、どちらの会社も、このリソースに関する共有を、委託された第三者ＲＰＭサービスプロバイダにアウトソースすることに決めたとする。両社は委託された第三者ＲＰＭサービスプロバイダに、たとえば各々の社内で管理職にある社員の氏名、その社員の社員番号、各社員に与えられるカード使用許可等、関連する社員情報を提供する。両社は委託された第三者ＲＰＭサービスプロバイダに対し、たとえばインターネット等のネットワーク上でこれらの情報を提供する。委託された第三者ＲＰＭサービスプロバイダは次に、委託された第三者ＲＰＭサービスプロバイダが会社に代わってアカウントを確立するのに必要な権限を持つように、クレジットカード会社と適正な関係を築き、エージェントを通じて、そのようなアカウントのためのクレジットカードを両社の社員に割り当てる。会社と委託された第三者ＲＰＭサービスプロバイダ、会社とクレジットカード会社および委託された第三者ＲＰＭサービスプロバイダとクレジットカード会社との関係が構築されると、各会社の社員へのクレジットカードアカウントの共有が即座に行われるようになる。必要なのは、会社が委託された第三者ＲＰＭサービスプロバイダに対し、その共有関連の要求事項を知らせ、委託された第三者ＲＰＭサービスプロバイダに必要な社員情報を提供することだけである。すると、委託された第三者ＲＰＭサービスプロバイダは、クレジットカード会社とアカウントを確立し、クレジットカード会社に対し、アカウントを構築しようとしている会社の社員に１枚または複数のクレジットカードを送付するよう指示することができる。
【０１３４】
本発明の別の実施形態を図１３に示す。この実施形態において、会社８００，８０６は何社でも第三者ＲＰＭサービスプロバイダを使い、エージェント８０４，８１０を通じてリソースの共有を行うことができる。これらの会社８００，８０６は自己のリソースを利用し、これらのリソースが第三者ＲＰＭサービスプロバイダにより、第三者のサーバ８２０を使って、たとえばインターネット等のネットワーク８２２で割り当てられるようにする。しかしながら、これらの会社８００，８０６は、各々のリソースのベンダとみなされ、自分たち自身を相互に関連付け、リソースを共有することも選択できる。これは、第三者ＲＰＭサービスプロバイダが各ベンダに対して共通の、委託されたリンクであるため、容易に実行できる。したがって、各関連組織が所有、運用するリソースは、第三者ＲＰＭサービスプロバイダにより、関連組織間で「相互共有」される。本発明のこの実施形態は、「リソース取引所(exchange)」として説明することもできる。また、本発明のこの実施形態によれば、インフラストラクチャは、前述の企業やＡＳＰの実施形態のような完全に私的なものではないが、完全に公共化されてもいないため、セミプライベートと考えることができる。インフラストラクチャおよび、そのインフラストラクチャ内で利用できるリソースは、そのサービスプロバイダにリソースを割り当ててもらうために第三者ＲＰＭサービスプロバイダを利用する他のベンダと関連付けられることを選択したリソースのベンダのみ利用できる。
【０１３５】
図１３に示す本発明の実施形態を例にとり、リソース交換所に属する、つまり共有インフラストラクチャに属する第一のベンダは、他の組織に電子メールシステムを提供できるものとする。また、同じリソース取引所内の第二のベンダは、各種の消費者リストへのデータベースアクセスを提供するものとする。さらに、第一のベンダは、各種の消費者リストが必要であると判断し、第二のベンダが管理するデータベース情報を入手したいとする。最後に、第二のベンダは、その社員のための電子メールシステムを導入したいと判断したとする。この場合、各社が第三者ＲＰＭサービスプロバイダに通知したところで、第三者ＲＰＭサービスプロバイダは第一のベンダに第二のベンダが有するデータベースリソースの相互共有を行う。同様に、第三者ＲＰＭサービスプロバイダは第二のベンダに対し、第一のベンダが提供する電子メールシステムの相互共有を行う。このような相互共有の実施形態その他において、第三者ＲＰＭシステムプロバイダは委託を受けたものであるため、第二のベンダに「擬似アカウント」を割り当てることにより、当初の、あるいは真実のアイデンティティである社員のアイデンティティを隠すことができる。ベンダはどちらもリソース取引所のメンバーであるため、第三者ＲＰＭサービスプロバイダが各ベンダへのリソース共有のために必要な情報は、すべてでなくともその多くは、第三者ＲＰＭサービスプロバイダがすでに利用できるものである。さらに、両ベンダは一般に、リソースの相互共有に関する契約を締結しており、これらの契約がリソース取引所のメンバーとなる前提条件であるのが普通であるため、そのような相互共有に関する詳細事項はすでに整っている。したがって、所望のリソースの共有は、共有が要求されるとすぐに行われる。
【０１３６】
図１３に示す本発明の実施形態の別の例として、リソース取引所内の組織はクレジットカード会社と契約し、その組織の各副社長にクレジットカード会社のチャージアカウント(charge accounts)のひとつへのアクセスを与えることを定めたものとする。クレジットカード会社もまたリソース取引所のメンバーであり、契約が発効するとすぐ、組織内の各副社長には、第三者ＲＰＭサービスプロバイダにより、リソース取引所を通じてクレジットカード会社のチャージアカウントが即座に自動的に割り当てられる。共有を実行するために、その他の個人情報は不要である。組織とクレジットカード会社がどちらもすでにリソース取引所のメンバーであるため、組織の副社長にチャージアカウントを割り当てるのに必要な情報はすべて、すでにシステムが利用できるものであるからである。しかしながら、希望に応じて、共有の前に承認プロセスを追加して実行することもできる。
【０１３７】
また、共有はまとめて行ってもよい。組織は第三者ＲＰＭサービスプロバイダに対し、副社長に適用される方針等、組織内の人物の役割と属性に関する方針をすでに伝えており、クレジットカード会社は第三者ＲＰＭサービスプロバイダに対し、そのチャージアカウントのひとつを誰に割り当てる必要があるかに関する方針をすでに特定しているため、第三者ＲＰＭサービスプロバイダは両組織の要求事項を調整し、迅速に副社長にチャージアカウントを割り当てることができる。たとえば、組織は副社長に１００，０００ドルの年間使用限度額を認める方針を持っている。すると、チャージアカウントは、副社長の年間購入限度額を１００，０００ドルに制限するよう設定される。また、組織は副社長による1回の購入額は、社長の許可なく１０，０００ドルを超えてはならないとする方針を持っているかもしれない。したがって、チャージアカウントは、副社長の１回の購入限度額を１０，０００ドルとして設定される。このため、役割とその属性がシステム内で確立されると、組織がそれ以上何もすることなく、これがただちにリソースの共有に適用される。この実施形態において、ユーザの共有解除も非常に素早く行われる。たとえば、組織の副社長が退社または退職したとする。その小切手は即座に停止できるが、同人のチャージアカウントは普通、月末まで開いたままである。これは、副社長が組織と無関係となってもなおそのチャージアカウントでの購入権を持つという点で、組織にとって非常に危険である。
【０１３８】
この実施形態において、組織が第三者ＲＰＭサービスプロバイダに対し、その副社長が組織と無関係になったことを伝えれば、第三者ＲＰＭサービスプロバイダは即座にその副社長についてクレジットカードアカウントを共有解除し、これによって組織は不正使用から保護されることになる。
【０１３９】
図１３の実施形態を実現するための方法を詳細に示すフローチャートが図１４Ａである。ステップ８５０で、第三者ＲＰＭサービスプロバイダは共有サービスの要求を受け取る。この要求は、そのサービスを必要とする１社または複数の会社によって受け取られる。要求は、会社の担当者と第三者ＲＰＭサービスプロバイダの担当者との間で、電子的手段を通じて、あるいは個人的接触によって行われる。しかしながら、この実施形態において、共有要求は、その要求を行う会社が所有または運営していないリソースについて行われる。たとえば、会社は電子メールの共有の要求を行うが、実際には会社に電子メールのリソースがないかもしれない。したがって、その会社はリソース取引所内の関連会社に電子メールサービスを提供するよう求め、第三者ＲＰＭサービスプロバイダにこのようなサービスの共有を求める。ステップ８５４において、第三者ＲＰＭサービスプロバイダは、共有要求を行った会社のために、リソース取引所内の適当なリソースを割り当てる。共有が完了すると、ステップ８５６において、ユーザにはその旨伝えられ、その後、ユーザは会社の共有方針と、そのリソースの共有を要求する会社と共有のためにリソースを提供する会社との間の契約に従って、自由にそのリソースを使用することができる。一般に、このような契約は取引所のメンバーになるための前提条件である。
【０１４０】
図１３の実施形態を実現する別の方法を詳細に示すフローチャートが図１４Ｂである。ステップ８５１において、第三者ＲＰＭサービスプロバイダはユーザ情報の変更を受け取る。この変更は、この変更を有する１社または複数の会社によって受け取られる。変更は、会社の担当者と第三者ＲＰＭサービスプロバイダの担当者との間で、電子的手段を通じて、あるいは個人的接触によって受け取られる。また、この変更は自動的に受け取ることもできる。たとえば、会社の人事ベースの変更が第三者ＲＰＭサービスプロバイダに自動的に送信される、または呼び出される。また、この実施形態において、変更は、そのユーザを雇用している会社が所有または運営していないリソースが割り当てられるユーザに関するものかもしれない。たとえば、会社には電子メールに関するユーザの変更があるが、実際には会社に電子メールのリソースがないかもしれない。したがって、会社は、リソース取引所内の関連会社にその電子メールサービスを提供するよう求める。ステップ８５２において、第三者ＲＰＭサービスプロバイダは、受け取ったユーザ情報の変更に基づき、リソースアクセス権のどの変更が必要かを判断する。これは、ユーザ情報の変更を送信した会社とは独立して行われる。ステップ８５３において、第三者ＲＰＭサービスプロバイダは、その共有を行う前に変更の共有に必要な承認を得る。ステップ８５５において、第三者ＲＰＭサービスプロバイダは、ユーザ情報の変更を提供する会社のために、リソース取引所内の適当なリソースの共有を行い、これには、共有解除等も含まれる。共有が完了すると、ステップ８５７においてユーザにその旨通知され、その後ユーザは会社の共有方針と、そのリソースの共有を要求する会社と共有のためにリソースを提供する会社の間の契約に従って、そのリソースを自由に使用することができる。
【０１４１】
一般に、このような契約は取引所のメンバーとなるための前提条件である。関連会社間の相互共有サービスの代金請求は、さまざまな形態で行われる。たとえば、取引料は、リソースの共有が行われるたびにベンダによって適用される。この料金は、共有を要求する顧客からリソースのベンダに支払われ、その一部が第三者ＲＰＭサービスプロバイダに支払われる。あるいは、共有を要求する顧客がリソースのベンダに加入料を支払い、すべての共有料が加入料に含まれるようにすることもできる。このような料金請求方式は、共有のニーズが大きいと予想される顧客にとって魅力的であるたとえば、図１３に示す実施形態には、関連会社間のリソースの相互割当を実行するための各種の方法が含まれる。たとえば、リソース取引所内のリソースの相互共有を実行するために、取引所内の各関連組織内の役割と属性の「足跡」を汎用的なものにすることができる。つまり、ひとつの関連組織内の役割はそれぞれ、別の関連組織における、これに対応する役割に変換される。これは、ひとつの関連組織から別の組織に役割を変換する変換マップによって可能となる。たとえば、ひとつの関連組織のセールスエンジニアは、別の組織ではテクニカルセールスコンサルタントと呼ばれるかもしれない。これらの２つの役職がそれぞれの組織で別の呼び方をされているとしても、その役職に必要な任務は取引所の中では同じかもしれない。したがって、第三者ＲＰＭサービスプロバイダは、関連リソース間で、これら２つの役職のアクセス権とエンタイトルメントを調整する変換マップを維持する。このため、第一の関連組織のセールスエンジニアは、第二の関連組織のテクニカルセールスコンサルタントと組織に対して同じエンタイトルメントを有し、またその逆でもある。第三者ＲＰＭサービスプロバイダは、標準的関連組織の足跡へのマッピングまたは標準方針を提供する。
【０１４２】
図１３に示す実施形態における関連組織間でのリソースの相互共有を実現するために使用する別の方法は、関連組織のハイレベルな認証に関する。関連リソース取引所を成功させるためには、各関連組織が、たとえば背景確認、信用度確認、キャッシュフロー確認、その他、関連組織の業務および財務上の健全性に関する面等、関連組織の各種の業務、財務面で認証されることが必要となる。こうしたハイレベルな認証は、第三者ＲＰＭサービスプロバイダによって実行され、たとえばパスワードや、ＰＫＩとバイオメトリクス等のマルチファクタ方式を含む各種のテクニックによって提供されるアイデンティティの認証に加えて使用される。
【０１４３】
図１３の実施形態における関連組織間のリソースの相互共有を実行するために使用されるまた別のテクニックは、アイデンティティ同期に関する。リソース取引所において円滑なリソースの相互共有を行うためには、リソースのユーザと取引所内の関連組織に関する最新情報が常に利用可能でなければならない。たとえば、ある関連組織が取引所から脱退した場合、これはできるだけ早くリソース取引所関連組織リストに反映し、特に、個人の脱退によって別の関連組織の重要なリソースが失われるような場合、他の関連組織が相応の対策を計画、実行できるようにしなければならない。反対に、重要なリソースを提供する組織が取引所のメンバーとなった場合、この情報も取引所の他の関連組織に提供し、他の組織が新たなリソースを容易に利用できるようにすべきである。このようなリソースは、第三者ＲＰＭサービスプロバイダによって取引所内に登録され、適当に共有される。第三者ＲＰＭサービスプロバイダは、リソース取引所内のこのようなアイデンティティ同期を提供する。このような同期は、第三者ＲＰＭサービスプロバイダがリソース取引所の全関連メンバーにとってのデータセンターとして機能するという事実により、実践的な観点から実現される。したがって、リソース取引所の情報を更新するために必要なすべての情報は、ひとつの論理サーバ上で利用できるため、更新は迅速かつ効率的に行われる。
【０１４４】
図１３に示す実施形態における関連組織間のリソースの相互共有を実行するためさらに別の方法は、オーディットトレールに関する。リソース取引所の各関連組織が第三者ＲＰＭサービスプロバイダによって自己のリソースについて行われた個々の相互共有トランザクションの記録を持つことができれば、セキュリティ、説明責任、その他の理由で有利である。さらに、取引所の各関連組織が別の関連組織のリソースのユーザについて行われた個々の相互共有トランザクションの記録を持つことも有利である。第三者ＲＰＭサービスプロバイダは、リソース取引所の関連会社に関するオーディットトレール、つまり各共有トランザクションの記録を提供できる。このようなオーディットトレールは、前述のように、第三者ＲＰＭサービスプロバイダがリソース取引所の全関連メンバーにとってのデータセンターとしての役割を果たすため、第三者ＲＰＭサービスプロバイダによって実行される。このように、共有トランザクションに関するすべての情報は容易に記録され、関連メンバーの要求に応じて提供される。
【０１４５】
図１３の実施形態において関連組織内のリソースの相互共有を実行するためのまた別の方法は、リソースと対話する個人と組織の匿名性に関する。リソース取引所内のリソース利用が、たとえば入札等のインタラクションの対象である場合、そのインタラクションに係わる関連組織のアイデンティティはそのインタラクションの過程において匿名とされる。つまり、そのインタラクションにおいて、関連組織のアイデンティティは、インタラクションが関連組織のアイデンティティによって公正を欠くものとされることがないように、伏せられる。リソース取引所で採用される匿名性には３つのレベルがある。第一に、まったく匿名性がないもの。入札を例にとると、関連組織にとって、入札中にそのアイデンティティを匿名にしたままであることは重要でない。したがって、そのアイデンティティはリソースに関する入札中も他の関連組織に知らされる。第二に、リソースについて入札する関連組織のアイデンティティは隠匿されるが、実際の入札を行うユーザには、すべての入札セッションに使用するためのある種の固有の識別子が与えられる。第三に、リソースについて入札する関連組織のアイデンティティは隠匿され、１回の入札セッションにのみ使用できる一般的な識別子が、実際の入札を行うユーザに与えられ、その後の入札セッションでは、実際の入札を行う同じユーザに別の一般的識別子が与えられる。第三者ＲＰＭサービスプロバイダはリソース取引所の全関連メンバーにとって、共有サービスの中央集中的プロバイダとして機能するため、このような匿名性は第三者ＲＰＭサービスプロバイダによって実行される。このように、関連組織のアイデンティティは、の第三者ＦＰＭサービスプロバイダによってその関連組織の任意で隠匿され、関連組織が希望すれば、そのアイデンティティは匿名のままとされる。
【０１４６】
本発明の別の実施形態を図１５に示す。この実施形態において、一般の個別組織８６０は、リソース取引所において関連組織が使用するために共有されるリソースを提供するベンダに対し、リソースを共有する第三者ＲＰＭサービスプロバイダを使用する。ここで、第三者ＲＰＭサービスプロバイダは、共有サービスを必要とする一般の個別組織がそのようなサービスを得ることができるようなインフラストラクチャを提供し、こうして公共共有インフラストラクチャを提供する。このような構成は、リソースを持たない顧客がリソース取引所のリソースまたは公共共有インフラストラクチャの一部であるその他の外部リソースを利用するのを助ける。
【０１４７】
図１５に示す本発明の実施形態を実現するために、第三者ＲＰＭサービスプロバイダはたとえば、ユーザ、組織または関連会社を含む一般の個別組織８６０に対し、ユーザアイデンティティの検証後に「チケット」を提供する。「チケット」は、ユーザを割り当てられたリソースに関連するエンタイトルメント、方針、属性、役割、ルールに関連付けるものである。組織は、たとえば、組織のどの役職が各種のリソースを得る権利を有するかを定義し、特定の役職が受けることのできるリソースへのアクセスおよびその利用レベルを定義する「組織の足跡」を有する。たとえば、ある組織におけるある人物が営業担当者である場合、チケットによってその営業担当者は、組織の足跡において定義されたルールに基づいて同人が得ることのできるすべてのリソースにアクセスできる。したがって、たとえば、誰かがチケットを取得した場合、その人物は、足跡、チケット、ユーザの識別認証の結果、インフラストラクチャまたはリソース取引所のリソースへの足跡アクセスを利用できることになる。チケットは、委託を受けた第三者ＲＰＭサービスプロバイダによって認証、確認される。チケットに関する属性は多岐にわたる。チケットは譲渡可能でも、特定の期間についてのみ有効でも、それに関連したさまざまなアクセス権を伴ってもよい。チケットは、１人の人物、複数の人物または組織全体について存在してもよい。たとえば、法律事務所が情報データベース等のリソースを使用する必要性を有しているとする。この法律事務所は、情報データベースリソースプロバイダと契約し、その社員にデータベースへのアクセスを提供するよう第三者ＲＰＭサービスプロバイダとも契約を交わしたとする。すると、この委託を受けた第三者ＲＰＭサービスプロバイダはこのようなアクセスのためのチケットを発行する。その法律事務所の各弁護士は、同事務所の方針に従ってデータベースにアクセスするためにチケットを取得する。あるいは、事務所全体でデータベースにアクセスするためのチケットを１枚受け取る。チケットは、特定の期間について有効であり、各弁護士に対し、データベースに関する特定のアクセス権を提供する。特定期間終了時に、この法律事務所はデータベースに関連する利用と費用を分析し、チケットのアクセス権を変更する。
【０１４８】
この例で説明を続けると、新しい弁護士がその弁護士事務所に加わったとする。その事務所はすでに第三者のサービスプロバイダとその弁護士にデータベースを提供する契約を締結しており、すでにデータベースリソースプロバイダとデータベース利用のための契約を締結しているため、法律事務所が新入りの弁護士にデータベースへのアクセスを割り当てるためにしなければならないことは、第三者ＲＰＭサービスプロバイダに対し、新たな弁護士が事務所に加わったという情報を与え、第三者ＲＰＭサービスプロバイダに新たな弁護士に関する関連情報を提供することだけである。リソースプロバイダにはチケットが提供されるため、第三者ＲＰＭサービスプロバイダは次にチケットを発行し、データベースリソースプロバイダに送付する。このデータベースリソースプロバイダは、新しい弁護士のためのアカウントをセットアップする。その後、新たな弁護士はＰＫＩまたはその他のアイデンティティ認証方法によってそのアイデンティティの認証を受けるだけで、データベースにアクセスすることができる。
【０１４９】
図１５の実施形態を実行する方法を詳細に示すフローチャートが図１６である。ステップ８７０で、第三者ＲＰＭサービスプロバイダは共有サービスの要求を受け取る。このような要求は、そのサービスを必要とする一般の個別組織によって行われる。要求は、組織の担当者と第三者ＲＰＭサービスプロバイダの担当者の間で、電子的手段または個人的接触によって行われる。ステップ８７２において、第三者ＲＰＭサービスプロバイダはサービス要求を行う組織のデータ処理ニーズに対応するために、そのサーバ上に適当なスペースを割り振る。ステップ８７４では、第三者ＲＰＭサービスプロバイダは、要求を行う組織からユーザ情報を受け取る。この情報にはたとえば、ユーザ名、ユーザ番号、ユーザがアクセスを希望するリソースのリスト、アクセス権の性質その他が含まれる。この情報は、たとえばインターネット等のネットワークを使い、組織から第三者ＲＰＭサービスプロバイダに電子的に送信される。第三者ＲＰＭサービスプロバイダはステップ８７６において、要求されたリソースをユーザに割り当てる。ユーザにリソースが割り当てられると、ユーザは第三者ＲＰＭサービスプロバイダと個別組織およびリソースプロバイダと個別組織の間で交わされた契約にしたがって、そのリソースを自由に使用することができる。図１５の実施形態は、ハブおよびスポーク構成に接続され、第三者ＲＰＭサービスプロバイダはハブであり、各スポークの末端に、関連組織または一般の個別組織のグループが存在する。この実施形態において、公共共有インフラストラクチャの範囲内で、あらゆるレベルのアクセスが認められる。たとえば、クレジットカードアカウント等の演算以外のリソースが関連会社のリソース取引所の中に存在する。リソース取引所のメンバーではない一般の個別組織がそのようなチャージアカウントの共有を希望する場合、その組織は、委託された第三者ＲＰＭサービスプロバイダに取引所内のチャージアカウントにアクセスするためのチケットを発行するよう求めることによって、そのインフラストラクチャに入ることができる。
【０１５０】
本発明の実施形態の各レベルを示すグラフィクスによる略図が図１７である。中央ロケーション共有レベル８８０において、各種の組織８８１が第三者ＲＰＭリソースプロバイダからリソース共有を受ける。関連組織レベル８８２において、各種のリソースベンダ８８３がリソース取引所に参加し、取引所内の他の関連組織８８３とリソースを共有する。公共共有インフラストラクチャレベル８８４において、個別組織８８５が、適当なチケットと適当なアイデンティティ認証を受けることを条件として、インフラストラクチャ内のリソースにアクセスすることができる。
【０１５１】
図９−１７の実施形態は、ＰＫＩ、つまり、アイデンティティ認証と証明を提供するインフラストラクチャと関連して使用できる。ＰＫＩを使い、会社、組織、ベンダ、関連会社および一般民衆のメンバーを含む本発明の実施形態のユーザのアイデンティティ、プライバシー、否認防止が確保される。アイデンティティがＰＫＩによって確認されると、そのユーザのためのリソース共有が行われます。共有インフラストラクチャはＰＫＩと連結され、アイデンティティが認証され、リソース共有がそのアイデンティティおよび、アイデンティティとユーザにリソースを提供する組織の共有方針との関係に基づいて提供される。ＰＫＩは周知であり、ここでは詳細に説明しない。ＰＫＩは第三者ＲＰＭサービスプロバイダがその共有サービスを提供する際に利用するインフラストラクチャの一部とすることができるが、リソース取引所または公共共有インフラストラクチャの中に、共有可能なリソースとして存在させることもできる。
【０１５２】
システム環境
上述のように、本発明の実施形態は、コンピュータのユーザにリソースを共有するシステムとプロセスであり、リソースがインターネット等のワイドエリアネットワーク上でアクセス可能であるものに関する。好ましい実施形態において、このようなリソースは所定の方針、役割、組織情報、属性に基づいて割り当てられる。
【０１５３】
本発明の実施形態によるシステム環境を図１９に示し、この中で、リソース９１０はリソースエージェント９１２とファイアウォール９１４を通じて、またはこれとともにワイドエリアネットワーク（ＷＡＮ）９１６に接続される。図による実施形態において、ＷＡＮ９１６はインターネットである。リソース９１０はＷＡＮ９１６上でアクセス可能な適当なリソースであり、たとえば、データベース、電子メールシステム等、管理されたリソースである。図の実施形態において、リソース９１０は管理されたデータベースサービスのためのデータベースとして描かれている。リソースエージェント９１２はコンピュータ上で実行するソフトウェアで、リソースのユーザのためのユーザアカウントを維持、管理し、図１８のリソースエージェント９０２について説明したように、パスワード、識別情報、アクセス権情報等、許可を受けたユーザに関する情報を記憶する。リソースエージェント９１２はデータベースへのアクセスを管理し、許可を受けたユーザによるデータベースへのアクセスを許可し、無許可のユーザによるデータベースへのアクセスは禁止する。リソースエージェントの一例は、本発明の譲受人であるカリフォルニア州アービンのＡＣＣＥＳＳ３６０によるenRole（商標）である。図１８に示す構成と同様に、リソース９１０とリソースエージェント９１２は共通のネットワークサイト上にあり、これを第一のサイトという。
【０１５４】
別の実施形態において、エージェント２２はリソース９１０とは異なるサイトにある。好ましい実施形態では、リソース９１０とリソースエージェント９１２はそれぞれ安全なサイトに配置され、ここで、リソースへのアクセスはエージェントによって安全に管理される。ＲＰＭシステム９１８はまた、ファイアウォール９２０を通じてインターネット９１６に接続される。ＲＰＭシステム９１８は、リソース９１０とリソースエージェント９１２のサイトとは離れた第二のネットワークサイトに配置される。ＲＰＭシステム９１８は、リソースの割り振りを所定のユーザグループに制約する適当なシステムである。所定のグループ内のユーザは、図１９のＵ１，Ｕ２等、他のインターネットリンクを通じてインターネットに接続されたユーザである。あるいは、またそのほか、所定のグループ内のユーザは図１９のユーザＵ３，Ｕ４，Ｕ５等、ＲＰＭシステム９１８と同じローカルエリアネットワーク（ＬＡＮ）３４の中のユーザとすることができる。ＲＰＭシステム９１８は、ソフトウェア、ハードウェア、ファームウェアまたはその組み合わせで実現できる。図の実施形態において、ＲＰＭシステム９１８は、ＬＡＮ９２２のためのゲートウェイコンピュータ上で実行するソフトウェアで実現されている。
【０１５５】
別の実施形態において、ＲＰＭシステム９１８はＬＡＮ９２２またはＬＡＮとは異なるＷＡＮサイトの他のコンピュータで実現できる。好ましい実施形態において、ＲＰＭシステム９１８は、方針、役割、組織情報、属性に基づいてリソースをユーザに割り当てるソフトウェア、ハードウェア、ファームウェアまたはこれらの組み合わせである。一般に、ＲＰＭシステム９１８は、システムのニーズに応じて、複数のユーザコンピュータ、管理者のコンピュータ、外部システム、データベースおよびディレクトリ、第三者サービスプロバイダ、管理されたサービスおよびシステム管理者、ＬＡＮ９２２およびＷＡＮ９１７上の他の実体と通信するために接続されたプラットフォームコンピュータシステムを利用する。ＲＰＭシステム９１８により、組織は所定の方針、組織情報、属性、組織におけるユーザの役割に基づいて、組織内のユーザにサービスを割り当て、または割り振る。方針またはルールは、組織のために、その組織のニーズに基づいて予め決定され、システム内に組み込まれる。方針は、組織内のさまざまな役割と各役割に必要なサービスに対応できる、フレキシブルなものである。たとえば、組織が新しい社員をシステム管理者として採用するものとする。システムを使い、いくつかの作業が自動的に開始される。たとえば、その組織で事前設定されている方針が。各従業員に一般電話サービス、一般の電話、電子メールアカウントを与えるというものである場合、新規システム管理者の採用にあたり、ＲＰＭシステム９１８は自動的に担当者にそのシステム管理者のための一般電話アカウントと電子メールアカウントをセットアップし、システム管理者のオフィスに一般の電話を届けるよう通知する。また、その組織の所定の方針が、各システム管理者はすべてのシステムデータベースにアクセスできるというものであったとする。すると、ＲＰＭシステム９１８は自動的に、すべてのシステムデータベースへのアクセスをシステム管理者に認める。今度は、一例にすぎないが、同じ組織が社外販売員として新規社員を採用するものとする。
【０１５６】
前述のように、たとえば、各社員が一般的な電話サービス、一般の電話、電子メールアカウントを受けるという方針を含め、組織に所定の方針があると、ＲＰＭシステム９１８は自動的に担当者に対し、その社外販売員に一般の電話アカウントと電子メールアカウントをセットアップし、その社外販売員の事務所に一般の電話を届けるよう通知する。しかしながら、組織の所定の方針が、システム管理者とは異なり、社外販売員にはすべてのシステムデータベースへのアクセスを与えないというものであると、ＲＰＭシステム９１８は社外販売員によるこれらのデータベースへのアクセスを自動的に拒否する。ＲＰＭシステム９１８は、組織内の人物の役割とその組織のための所定の方針に基づいて、これらの作業を自動的に扱う。方針は、組織のニーズと組織内の特定の役割の要求事項に基づくもので、組織におけるユーザの具体的な役割のニーズと要求事項を満たすようにリソースが各ユーザに割り当てられるものとする。
【０１５７】
好ましい実施形態において、ＲＰＭシステム９１８によって割り当てられるリソースは、インターネット９１６上でアクセス可能なリソースである。これを実現するために、ＲＰＭシステム９１８は、インターネット上でファイアウォール２６，３２を通じてリソースエージェント９１２と通信し、アカウント管理を行うようプログラムされた少なくともひとつのプロセッサを備え、あるいは利用する。このようなアカウント管理機能には、好ましくはユーザアカウントの追加、ユーザアカウントの削除およびユーザアカウントに関する情報の変更が含まれる。
【０１５８】
このように、組織の方針が管理されたデータベースリソース９１０へのアクセスをシステム管理者全員に割り当てるというものである場合、組織に新しいシステム管理者を採用する際、ＲＰＭシステム９１８は自動的にリソースエージェント９１２と通信し、新規システム管理者のための新たなアカウントを追加する。同様に、組織によるシステム管理者の雇用が終了した場合、ＲＰＭシステム９１８は自動的にリソースエージェントと通信し、そのシステム管理者のアカウントを取り消す。ＲＰＭはまた、たとえば、組織内での役割が変化した従業員に関するアクセス権を変更するために、ユーザアカウントに関するその他の情報を伝える。このように、ユーザのアクセス権は、ユーザの新しい役割におけるそのユーザのニーズに基づき、アクセス権を増減するよう変更される。ＲＰＭシステム９１８とリソースエージェント９１２はＷＡＮ９１６上の異なるサイトにあるため、これらの実体の間の通信はＷＡＮプロトコルに適合し、ファイアウォール９０４，９２０を通過できなければならない。したがって、好ましいインターネットでの実施形態において、ＲＰＭシステム９１８はインターネット通信用の適当なプロトコル、好ましくはＨｙｐｅｒＴｅｘｔ Ｔｒａｈｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）、より好ましくは、ＨＴＴＰＳ等、安全なＨＴＴＰ接続を採用するものとする。ＸＭＬ等の適当なフォーマットも利用可能である。このように、ＨＴＴＰＳ等の適当なＷＡＮプロトコルを使って遠隔リソースエージェントと通信することにより、遠隔リソースの共有がＲＰＭシステム９１８によって実現される。暗号化ソケットプロトコル（ＥＳＰ）等、ＷＡＮと相互運用可能なその他の適当なプロトコルとフォーマットも利用可能である。遠隔リソース（遠隔ＷＡＮサイトにあるリソース）を割り当てる能力は、ＲＰＭシステム９１８のフレキシビリティとユーティリティを大幅に増大させる。このような能力により、ＲＰＭシステム９１８はＲＰＭにとってローカルなリソース（たとえば、ＲＰＭと同じＬＡＮ内にあるもの）だけでなく、事実上、世界のどこにあるかを問わず、インターネット上でアクセス可能なリソースの共有を行うことができる。図の実施形態は、ＷＡＮ９１６上でアクセス可能なひとつだけのリソース９１０とリソースエージェント９１２を示しているが、好ましい実施形態は、複数のリソースおよびリソースエージェントで運用できる。この点で、ＲＰＭシステム９１８は各リソースの各リソースエージェントと通信してリソース９１０とリソースエージェント９１２について上で説明したアカウント管理機能を提供する。
【０１５９】
本発明の別の面によれば、ＲＰＭシステム９１８はワークフローの定義で動作する。このようなワークフローの定義は、たとえば監督者等、専門的役割を有するユーザによって追加、削除または変更される。好ましい実施形態において、ワークフローの定義はＷＡＮ９１６上の遠隔サイト等、ＲＰＭシステム９１８から離れた場所から追加、削除または変更できる。より具体的には、図２０のように、ＲＰＭシステム９１８は、ワークフローの定義ＷＤＦ１−ＷＤＦｎのデータベースまたは記憶装置９３２とともに動作するワークフローエンジン９３０を備える。上記のような役割に基づくシステムを使い、ＲＰＭシステム９１８は、所定の方針、ユーザ役割、組織情報、属性に基づき、アクセス権等のリソースをユーザＵ１，Ｕ２，Ｕ３，Ｕ４，Ｕ５に割り当てる。さらに、ＲＰＭシステム９１８は専門的役割を有するユーザＵ６に、そのユーザがワークフローデータベース内のワークフローの定義にアクセスし、これを追加、削除または変更できるアクセス権を割り当てる。
【０１６０】
好ましい実施形態において、ユーザＵ６はＲＰＭシステム９１８があるＷＡＮサイトとは離れたＷＡＮ９１６上のサイトに配置する。遠隔サイトには、ブラウザソフトウェア等、ＷＡＮ９１６上でＲＰＭシステム９１８のウェブサーバ９３４と通信するための適当なソフトウェアを備えたコンピュータを設置する。このように、ユーザＵ６は、そのユーザのコンピュータかせＲＰＭシステム９１８にログインすることができる。好ましいインターネットによる実施形態において、ユーザＵ６はインターネット接続を有するどこにでも設置でき、したがって、ＲＰＭシステム９１８にとってローカルなコンピュータにおく必要はない。さらに好ましい実施形態において、ＲＰＭシステム９１８は複数のワークフローの定義で動作し、ユーザＵ６は、ＲＰＭシステム１９８の役割に基づく共有ルールの下で、ユーザＵ６がデータベース３８内のすべてではなく、ひとつまたは複数の所定のワークフローの定義を追加、削除または変更できるような役割を担う。このような好ましい実施形態において、別のユーザＵ７は、ＲＰＭシステム１９８の役割に基づく共有ルールの下で、ユーザＵ７がひとつまたは複数の所定の定義を追加、削除または変更できるような専門化された役割を担う。ユーザＵ７がアクセスできる所定のワークフローの定義は、Ｕ６がアクセスできるワークフローの定義の一部または全部を含んでも、含まなくてもよい。代表的な例として、ユーザＵ６はワークフローの定義ＷＤＦ１を追加、削除または変更できる監督者としての役割を持ち、ユーザＵ７はワークフローの定義ＷＤＦ１−ＷＤＦｎのいずれも追加、削除または変更できる、より広い監督者としての役割を有する。あるいは、ユーザＵ７はワークフローの定義ＷＤＦ２−ＷＤＦｎを追加、削除または変更できる役割を持つ。使用するアプリケーションに応じて、適当な数のユーザに対し、所定のグループのワークフローの定義を追加、削除または変更するアクセス権を与えることができる。
【０１６１】
リソースの利用に関するシステムの動作
ＲＰＭシステム内のリソースの利用は、過剰、中程度またはわずかである。リソースの利用がわずかであるとそのリソースは休眠状態となる。休眠リソースは、そのリソースまたはそのリソースのユーザについて確立されているルールまたは方針によって定義される状況下で、所定の期間にわたり利用されなかったリソースまたはそのリソース上のアカウントである。ＲＰＭシステムにおいて、システム内の各ユーザにはさまざまなルールと属性が関係する。
【０１６２】
本発明の実施形態によれば、利用方針を確立する際、これらのルールと属性を特定のリソースに関連して使用し、ＲＰＭシステムが、どのような場合にリソースまたはそのリソース上のアカウントが休眠であるとみなされるか、あるいはどのような場合にそのリソースの利用が過剰であるとみなされるか、およびその場合に取るべき対策を決定する。つまり、使用方針の実施形態により、ＲＰＭシステムは、リソースまたはアカウントの作業および特定のリソースまたはアカウントについて確立されたルールと方針に基づき、どのような場合にリソースまたはそのリソース上のアカウントが休眠とみなされるか、あるいは過剰に使用されているとみなされるかを定義するルールに従って動作する。
【０１６３】
本発明の一般化された実施形態を図２１に示す。ステップ９４０でリソース利用方針を決定する。この方針は、ＲＰＭシステムにおいて実行され、システム内でのリソースの利用に反応してとられる行動を管理する。ステップ９４２において、システムはそのユーザに対し、各種のデータとユーザの属性および会社の方針に従ってリソースを割り当てる。するとユーザはシステム上のリソースを使用できる。ステップ９４４において、システムはシステム上のリソースの利用をモニターする。これは、エージェントまたはリソースそのものによって行われる。ステップ９４６で、システムユーザまたはリソースの利用に関するデータがシステムに入力される。ステップ９４８で、モニターされ、入力された利用データと外部データがＲＰＭシステムに送信され、データはここでユーザ方針に従って分析される。リソース利用とユーザの属性の性質およびその他のデータに基づき、システムは、リソースの共有の変更が必要であることをステップ９５０で判断する。この場合、ステップ９４２で、ユーザにはリソースのリ共有が行われる。これにはたとえば、ユーザにリソースに対するユーザの権利を向上させる、あるいはその権利を排除することが含まれる。あるいは、リソース利用とユーザの属性の性質が、利用方針を変更するトリガとなる。この場合、ステップ９４０で方針が定義しなおされ、システムはその後、同様の動作を続ける。たとえば、ローカルエリアネットワーク上にあるシステムにアカウントを持つシステム管理者が６ヶ月間にわたり、システムにログオンしなかったとする。そのシステムとシステム管理者の特定のアカウントについてすでに確立されているルールと方針に基づき、そのアカウントは休眠状態とみなされる。このように、アカウントが休眠状態であることが確認されると、そのアカウントについて適当な対策がとられる。この対策は、そのシステムとシステム管理者の特定のアカウントについてすでに確立されているルールと方針に基づいており、たとえば、まったく何もしないか、あるいはアカウントを使用不可にするなど、さまざまな行動が含まれる。アカウントが使用不可状態にされると、確立されたルールと方針に基づき、システム管理者はアカウントを再び使用するためには、ＲＰＭシステムを通じてそのアカウントを使用可能にしなおさなければならない。
【０１６４】
リソース利用状況管理の別の例を詳細に示すフローチャートが図２２である。会社の営業担当者は普通、毎日のように常に携帯電話を使用するため、会社は、営業担当者が携帯電話のアカウントを持ち、これが１ヶ月以上使用されないと、携帯電話のリソースは休眠状態であるとする方針を作ったと仮定する。ステップ９６０で、システムは該当する携帯電話リソースからこの営業担当者に関する携帯電話利用データを呼び出す。この呼び出しを実行するために、システムは適当なエージェントに照会し、このエージェントがリソースまたはエージェント自身の内部記憶メカニズムからデータを呼び出し、システムにそのデータで応答する。次に、ステップ９６２で、当該携帯電話アカウントがシステムの利用方針からみて休眠状態であるかを判断する。この特定の携帯電話アカウントが前月中に使用されていれば、システムはステップ９６６でその照会を終了する。しかしながら、この例では、営業担当者がその携帯電話を１ヶ月以上使用していないため、ステップ９６４において、その営業担当者が保持する携帯電話アカウントは休眠状態であるとみなされる。ステップ９６４ではまた、営業担当者が保持する休眠状態の携帯電話アカウントについてすでに確立されている会社のルールと方針に基づき、会社は適切な行動をとる。たとえば、この例においては、その営業担当者の監督者に通知し、携帯電話アカウントが動いていない理由についての調査を行うようにする。あるいは、会社は、その携帯電話アカウントを使用不可常態にするか、またはこれらの案の中間にある適当な行動をとる。
【０１６５】
次に、上記の例を実行するための擬似コードの例を示す。
ＩＦ（（ｅｍｐｌｏｙｅｅ＝”ｓａｌｅｓｐｅｒｓｏｎ”）ａｎｄ
（ｌａｓｔ ｃｅｌｌ ｐｈｏｎｅ ｕｓａｇｅ＞ｔｏｄａｙ−３０ｄａｙｓ））
ｔｈｅｎ
ｎｏｔｉｆｙ ｍａｎａｇｅｒ；
【０１６６】
ＲＰＭシステムが休眠状態のリソースを照合確認する本発明の実施形態によるシステムを図２３に示す。図のように、ＲＰＭシステム９７０は、エージェント９７２を通じて管理されたリソース９７４とインタフェースする。エージェント９７２は、リソース９７４の利用に関する情報を維持する。エージェント９７２は、たとえば、リソース９７４への各アクセスを表に記入する等、さまざまな方法でこれらの情報を維持する。あるいは、リソース９７４が十分に高度なものであれば、このような活動情報はリソース９７４の中に記憶される。この場合、エージェント９７２は単純に、リソース９７４から利用情報を抽出する。リソース９７４が、たとえば、システム上の各アカウントの使用量を追跡するオペレーティングシステムである場合、これがあてはまる。
【０１６７】
引き続き図２３において、ＲＰＭシステム９７０が、リソース９７４またはリソース９７４に関するアカウントが休眠状態となっているかを判断するためにリソース９７４に関する活動情報を必要とする場合、ＲＰＭシステム９７０はエージェント９７２に照会する。エージェント９７２はＲＰＭシステム９７０に応答し、要求された利用状況情報を提供する。ＲＰＭシステム９７０は、さまざまな時点でエージェント９７２に情報を要求し、ＲＰＭシステム９７０がエージェント９７２に情報を求める頻度は、ＲＰＭシステム管理者によって変更される。たとえば、会社のエンジニアがネットワーク用オペレーティングシステムを使った会社ネットワーク上のアカウントを持っているとする。オペレーティングシステムは、たとえば関連するユーザＩＤ、そのエンジニアが所属する社内の部署、エンジニアが所属する部署の中の作業グループ等、エンジニアに関する情報を保持する。オペレーティングシステムはまた、そのエンジニアによるオペレーティングシステムのすべての使用とエンジニアによるオペレーティングシステムの利用時間を詳細に記録したログをつけてもよい。エージェントは、随時、あるいは指示のあったときに、オペレーティングシステムにその情報を照会し、テーブル、データベースその他の記憶素子に情報を保存し、ＲＰＭシステムがその情報を容易に利用できるようにする。ＲＰＭシステムが、リソースが休眠状態であるか否かを判断するためにエージェントへの照会を行うと、エージェントは求められた情報をＲＰＭシステムに提示する。
【０１６８】
以下に、上記の例に似た状況を実現する擬似コードの例を示す。
ＩＦ（（ｇｒｏｕｐ＝”ｍａｎｕｆａｃｔｕｒｉｎｇ”） ａｎｄ
（ｌａｓｔ＿ａｃｃｅｓｓ＞ｔｏｄａｙ−１８０ｄａｙｓ））
ｔｈｅｎ
ｓｕｓｐｅｎｄ ａｃｃｏｕｎｔ
ｎｏｔｉｆｙ ｕｓｅｒ
ｎｏｔｉｆｙ ｍａｎａｇｅｒ；
【０１６９】
上の例において、会社内の製造グループのメンバーである社員が過去６ヶ月間にわたりオペレーティングシステムにアクセスしていないと（つまり、そのアカウントへのアクセスが１８０日以上ない場合、つまり”ｌａｓｔ＿ａｃｃｅｓｓ＞ｔｏｄａｙ＝１８０ｄａｙｓ”）、オペレーティングシステムに関するその社員のアカウントは中止され、その社員とその社員のマネージャに通知される。利用方針の実施形態は、ＲＰＭシステム全体が十分な柔軟になるように設計される。方針はユーザのタイプやアカウントのタイプによって異なる。また、休眠期間はアカウントによってその定義が異なる。たとえば、ユーザがシステムまたはデータベースへのルートアクセスを持つ、つまり、ユーザが特権的な操作を行うことのできるアクセスを持つ場合、この種のアカウントの休眠状態は事実上存在しないのが望ましい。言い換えれば、システム内の利用方針は、システムまたはデータベースへのルートアクセスアカウントは頻繁に利用するか、頻繁に利用されないのであれば削除するよう求める。したがって、システムの設計は、アカウントのタイプ、アカウントへのアクセス、ユーザがだれか、その他のパラメータに応じて異なるレベルの念入りさ、厳格さで行われる。
【０１７０】
本発明の実施形態による利用方針の中に含める柔軟性の別の例として、携帯電話エージェントが、たとえば携帯電話サービスプロバイダである携帯電話リソースとＲＰＭシステムとのインタフェースとなると仮定する。エージェントは、定期的に携帯電話リソースから課金情報を呼び出すが、これには、携帯電話の使用時間等が含まれる。ＲＰＭシステムはそのシステム内のすべての携帯電話アカウントを定期的に照合確認し、エージェントに利用状況に関する情報を求める。要求された情報を使い、携帯電話リソースと携帯電話リソースのユーザについて事前に確立されていた方針でその情報を照合確認することにより、ＲＰＭシステムは特定の携帯電話アカウントが休眠状態となっているか否か、そしてなっている場合はどのような行動をとるべきかを判断する。
【０１７１】
上の例の方針は、次の擬似コードの例によって示されるように実現できる。
ＩＦ（ｓａｌｅｓ＿ｕｓａｇｅ＜”４０ ｍｉｎｕｔｅｓ ｐｅｒ ｍｏｎｔｈ”）
ｔｈｅｎ
ｃａｎｃｅｌ ａｃｃｏｕｎｔ
ｎｏｔｉｆｙ ｕｓｅｒ；
【０１７２】
この例において、携帯電話のユーザが、前月に会社製品の営業に関連して少なくとも４０分間その携帯電話を使用しなかった場合、ＲＰＭシステムは担当者に対し、そのアカウントを取り消し、取り消したことをユーザに通知するよう指示する。携帯電話が会社製品の営業に関連するか否かを判断するひとつの方法は、実際に営業の電話をかける前に、営業による電話のコードを入力する方法である。前述のように、システムは非常に柔軟に設計でき、これによって会社の経営陣は、各種のパラメータに基づいて個々のリソースに対する方針を作ることができる。たとえば、営業およびマーケティング担当の副社長が産休に入ったものの、携帯電話を使ってスタッフと連絡をとっているとする。この副社長は６週間、会社が使用するネットワーキングオペレーティングシステムにアクセスすることはできない。しかし、産休中も会社のスタッフと連絡をとるが、２週間は、携帯電話を使わずにすごす。さらに、会社は、アカウントの所有者が産休中である等、特別な状況にあたらないかぎり、２週間アクセスがないと、ネットワーキングオペレーティングシステムのアカウントは休眠状態であるとみなすことになっているものとする。また、会社は、アカウントの所有者が副社長のような会社役員でないかぎり、１週間アクセスがないと、その携帯電話アカウントは休眠状態であるとみなすものとする。
【０１７３】
したがって、休眠状態のリソースに関して会社が定める方針は、たとえば次の擬似コードで表される。
ＩＦ（（ｌａｓｔ＿ａｃｃｅｓｓ＿ｏｐｅｒａｔｉｎｇ＿ｓｙｓｔｅｍ＞ｔｗｏ ｗｅｅｋｓ）
ａｎｄ（ｎｏｔ ｍａｔｅｒｎｉｔｙ ｌｅａｖｅ））
ＴＨＥＮ
ｓｕｓｐｅｎｄ ａｃｃｏｕｎｔ
ｎｏｔｉｆｙ ｕｓｅｒ
ｎｏｔｉｆｙ ｍａｎａｇｅｒ
ＩＦ（（ｌａｓｔ＿ａｃｃｅｓｓ＿ｃｅｌｌ ｐｈｏｎｅ＞ｏｎｅ ｗｅｅｋ）
ａｎｄ（ｎｏｔ ｖｉｃｅ−ｐｒｅｓｉｄｅｎｔ））
ＴＨＥＮ
ｓｕｓｐｅｎｄ ａｃｃｏｕｎｔ
ｎｏｔｉｆｙ ｕｓｅｒ
ｎｏｔｉｆｙ ｍａｎａｇｅｒ
【０１７４】
したがって、この例において、副社長がオペレーティングシステムに最後にアクセスしたのは２週間以上前であるが、産休中であるため、そのアカウントは停止されない。さらに、最後に携帯電話アカウントにアクセスしたのは１週間以上前であるが、副社長であるため、そのアカウントは開かれたままとなる。このように、ＲＰＭシステム全体が、リソースまたはリソースに関するアカウントに最後にアクセスされたのはいつかをシステムが確認したという事実、および各アカウントについてさまざまな属性が存在するという事実により、リソースをどのように管理すべきかに関する会社の考え方に基づいてルールを決定する、非常に豊富な環境を提供するように方針が決定される。これにより、会社の方針を反映しながらシステムが動作する。さらに、システムを容易に変更することができる。会社または組織はそのシステムを監視し、システムが会社にとって容認できる方法で動作するまで、微調整を行う。
【０１７５】
本発明の別の実施形態によれば、ＲＰＭシステムのリソース利用方針により、会社と組織は管理されたリソースの利用およびアクセスパターンを認識することができる。たとえば、個々の携帯電話アカウントの利用状況とアクセス状況を監視するのに桑か、会社または組織内のすべての携帯電話アカウントも監視される。このように、全体の利用およびアクセスパターンを検出し、リソース利用方針をそのパターンに応じて導入できる。たとえば、会社または組織内のすべての携帯電話利用状況は、毎年クリスマスから正月まで、大幅に低下する。この情報を使い、会社または組織はこの情報をＲＰＭシステムの利用方針に反映させ、そのような利用状況に対する一般的な反応を相応に変更する。この特定の方針は、他の期間や他の利用、アクセスパターンにも拡張される。
【０１７６】
本発明の別の実施形態によれば、休眠状態のアカウントについて対策を講じる会社またはその他の組織は、この対策によって生まれるユーザ全体からの応答を観察する。このように、会社またはその他の組織は、休眠状態のリソースのユーザから受け取ったフィードバックに基づき、その対策が過剰か不足かを容易に判断できる。このようなフィードバックに応答し、会社または組織が、講じられた対策へのユーザの反応から修正が必要であると感じた場合、方針を素早く修正することができる。
【０１７７】
本発明のまた別の実施形態によれば、会社またはその他の組織は、アカウントの平均しように基づいて、そのアカウントについての対策を講じる。たとえば、会社が、すべての携帯電話のユーザに対し、たとえば３０日等の所定の期間中の一般的なアカウントの利用を求めるのではなく、その携帯電話アカウントをたとえば３０日等の所定の期間中、毎日平均して少なくとも１時間使用するよう求める携帯電話利用方針を立てたとする。そこで、アカウントユーザが１ヶ月のうち大部分の期間、たとえば２５日間、携帯電話を使用しない場合、その月末に、形態電話のユーザがその月の残りの日に平均使用時間が毎日１時間になるのに十分な時間だけログできないかぎり、アカウントは方針に反するとみなされ、適正な対策が講じられる。このような方針は、会社の社員の過失や怠慢を防止する。あるいは、アカウントの過剰な利用を監視するという利用方針が立てられる。たとえば、携帯電話アカウントを、平均して１時間８時間以上使用してはならないという利用方針とする。このように、月末に携帯電話がたとえば、ひとつの携帯電話アカウントで３００時間を超えてログされていたとすると、上記の方針を立てた会社はそのアカウントについて適切な対策を講じる。この例において、そのような携帯電話の使用がすべての会社の業務に関連している可能性は低く、会社は使用の性質を調査する。
【０１７８】
本発明の別の実施形態によれば、使用のタイプを監視するＲＰＭシステムにおいて、利用方針が立てられる。たとえば、利用方針は、データベースへのすべてのアクセスを監視し、各アカウントにおいてどのようなタイプのデータベースアクセスが行われているかを判断するというものである。たとえば、システムが、特定のアカウントが常にデータベースを読み、データベースへの書き込みを行わないと判断した場合、システムは、そのデータベースについて定められている利用方針に従い、そのアカウントにはデータベースへの読取専用のアクセスを与える。アカウントが読取専用にされてから、そのアカウントの所有者がデータベースへの書き込みを行う必要が生じた場合、アカウントの所有者は経営陣とシステム管理者に通知し、データベースへの書き込みによるアクセスが再びできるようにはる。
【０１７９】
本発明の他の実施形態によれば、ユーザアカウントの使用を特定の状況の下ではトールするという利用方針がある。たとえば、特定のアカウントユーザが長期休暇をとる場合、このユーザのアカウントアクセスはゼロになる。このような場合、システムがこのユーザのアカウント利用を確認する際、システムが休暇をカウントすることは不適切である。したがって、アカウントユーザに対し、アカウントを使用しないことがわかっている期間をシステムに通知することを可能にする利用方針とする。次に、システムはその期間についての利用活動をトールする。このようなノーティフィケーションは、会社のスケジューリングサービスやカレンダー作成プログラムと調整し、アカウントの使用を会社のスケジュールの中に取り入れる。さらに、管理されたリソースに利用方針を拡張する。たとえば、クレジットカードアカウント、一般の電話、データベースおよび、管理され、共有が行われる会社または組織が使用する事実上すべてのリソースについて、利用方針を適用する。ＲＰＭシステムの利用方針は、柔軟性、セキュリティ、コスト削減を実現する。柔軟性は、リソースに関するアカウントを開いておくままにすべきときに関する会社の考え方に沿って、アカウンの所有者とリソースユーザのさまざまな属性を使い、実現する方針を変えることによって得られる。この例では、会社が所有、運用するすべての携帯電話の平均７０％が毎日会社の営業担当者によって使用されている。しかしながら、クリスマスから正月までの週は、１日の携帯電話の利用率は２０％に低下する。会社は、１日の平均使用率が７０％以下になると、その携帯電話は休眠状態であると一般に判断するものの、クリスマスから正月までの週については、１日の平均使用率が２０％以下になれば、その携帯電話は休眠状態であると判断する。このように、携帯電話の低い使用率に応答して通常とられる行動は、利用方針に反映されているように、利用率の低い期間中は回避される。このような方針は、リソースを利用する会社または組織の判断で導入され、希望に応じて厳しくも甘くもできる。コスト削減は、アクセスされなかったアカウントを削除することによって実現する。
【０１８０】
一般に、会社または組織は、使用されていないアカウントについて、そのアカウントの維持に関連する費用を発生させたくないと考える。利用方針において、使用されていないアカウントは、会社または組織がそれを最も費用対効果が高いと感じれば、排除できる。セキュリティのレベルも、会社または組織が、オープン、したがって被害を受けやすいアカウントを遅滞なく、有効な方法で削除できるようにすることによって高められる。ＲＰＭシステムで利用方針をル要することにより、会社または組織はそのセキュリティレベルを希望に応じて決めることができる。つまり、会社または組織は、それが適当と判断するようにリスク管理を行うことができる。たとえば、独立した契約業者のためのアカウントアクセスは、会社のＣＥＯのアカウントアクセスに関連して、素早く排除される。
【０１８１】
アイデンティティ方針に関するシステムの運用
本発明の実施形態によれば、ＲＰＭシステムはアイデンティティ方針を含む。本発明の実施形態によるＲＰＭシステムのアイデンティティ方針により、システムがシステム内の各ユーザを個々に識別することができる。本発明の実施形態によるアイデンティティ方針は、ＲＰＭシステム内のユーザがシステム内およびシステムによって管理される各リソース内で識別される方法を決定するルールを含む。本発明の実施形態によるアイデンティティ方針は、複数の管理されたリソース内のユーザが、複数のリソース内およびこれらにまたがってどのように識別されるかを決定する。ひとつの特定のリソースについて、そのリソースのユーザが個々に識別され、同じリソースの他のユーザと混同されないように、アイデンティティは固有のものでなければならない。本発明の実施形態によるアイデンティティ方針は、システムリソースのユーザのアイデンティティを、たとえばユーザの氏名や組織におけるユーザの役割を含むユーザの属性から作るルールを提供し、さらに、属性の異なる組み合わせを使って固有のアイデンティティを構成することを可能にする。
【０１８２】
さらに、本発明の実施形態によるアイデンティティ方針はまた、非常に柔軟であるため、特定のユーザについて、そのユーザの属性のいくつかがそのリソースの別のユーザと衝突する場合に、そのユーザの合理的なユーザアイデンティティを作ることができるようにユーザの属性を組み合わせることができる。したがって、あるユーザのアイデンティティを作る際、本発明の実施形態によるアイデンティティ方針は、そのアイデンティティを作る相手となるユーザの属性だけでなく、そのリソースの他のユーザの属性も考慮する。
【０１８３】
あるリソースのユーザアイデンティティは、図２４に示すアイデンティティ方針の実施形態に従って作られる。ステップ９８０において、ＲＰＭシステムはリソースユーザの属性を取得する。これらの属性は、さまざまな方法で入手できる。たとえば、組織の新入社員が就職願書に記入したとする。記入された就職願書には通常、たとえばその社員のフルネーム、自宅住所、電話番号、社会保障番号等のさまざまなユーザ属性が含まれる。ＲＰＭシステムは、システムリソースに関するこの社員のアイデンティティを決定する際、これらの属性を使用する。さらに、その社員が採用される理由となる組織内の役割からも、ユーザ属性が得られる。たとえば、その社員がエンジニアリング組織に配置され、試験および測定部門で働き、技術者として採用される。ＲＰＭシステムはこれらの属性のすべてを取得する。そのユーザの属性は、データ入力係またはその他の人物によってＲＰＭシステムに入力される。次に、ステップ９８２において、ＲＰＭシステムは、ユーザが利用する特定のリソースについて、既定のアイデンティティ方針に従ってそのユーザのアイデンティティを生成する。
【０１８４】
アイデンティティ方針は、組織の希望に従って、それを使用することによって決定され、ユーザアイデンティティが生成されているリソースのアイデンティティルールを含む。たとえば、ＬＡＮのためのアイデンティティ方針は、ＬＡＮユーザの名の頭文字にＬＡＮユーザの姓を続けたものを使って、ユーザアイデンティティを割り当てる。つまり、ＬＡＮユーザの名前が“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”であると、アイデンティティ方針によって決められるユーザアイデンティティは“ｊｗｉｌｌｉａｍｓ”となる。ユーザアイデンティティが生成されると、ステップ９８４において、生成されたアイデンティティが衝突を起こしていないか、つまり、問題のリソースの他のユーザにすでにそのアイデンティティが与えられていないかが確認される。生成されたアイデンティティがすでに割り振られていなければ、ステップ９８６で、生成されたアイデンティティがそのユーザに与えられる。しかしながら、生成されたアイデンティティがすでに割り振られていれば、ＲＰＭシステムはステップＢに戻り、アイデンティティ方針に従って新しいアイデンティティを決定する。たとえば、上記のＬＡＮに関するアイデンティティ方針では、ＬＡＮユーザの名の頭文字と姓から作ったアイデンティティがすでに使用されていると、ＬＡＮユーザの名の頭文字に、そのＬＡＮユーザのミドルネームの頭文字と姓を続けたアイデンティティを与える。
【０１８５】
このように、ＬＡＮユーザのフルネームがＪｏｈｎ Ｍａｒｋ Ｗｉｌｌｉａｍｓである場合、アイデンティティ方針によって決定されるユーザアイデンティティは、“ｊｗｉｌｌｉａｍｓ”がすでに使われていれば“ｊｍｗｉｌｌｉａｍｓ”となる。
【０１８６】
図２４について説明した例の擬似コードのサンプルを以下に示す。
ＬＡＮ ＵＳＥＲＩＤ＝ｆｉｒｓｔ ｉｎｉｔｉａｌ＋ｌａｓｔ ｎａｍｅ
Ｉｆ（ＬＡＮ ＵＳＥＲＩＤ＝ａｌｒｅａｄｙ ａｓｓｉｇｎｅｄ）
ｔｈｅｎ （ＬＡＮ ＵＳＥＲＩＤ）＝ｆｉｒｓｔ ｉｎｉｔｉａｌ＋ｍｉｄｄｌｅ ｉｎｉｔｉａｌ＋ｌａｓｔ ｎａｍｅ
【０１８７】
上記の擬似コードは、衝突が存在するかぎり、ＵＳＥＲＩＤを変えて永遠に延長できると理解すべきである。たとえば、すでに使用されているＵＳＥＲＩＤの終わりにランダムの数字を追加し（たとえば、ｊｗｉｌｌｉａｍｓ３５７９）、あるいはすでに使用されているＵＳＥＲＩＤの終わりに追加された数字をひとつずつ増やす（たとえば、ｊｗｉｌｌｉａｍｓ１がすでに使用されていればｊｗｉｌｉａｍｓ２とする）。
【０１８８】
本発明の実施形態によるアイデンティティ方針を使って複数のリソースにまたがるユーザアイデンティティを付与する方法を図２５に示す。ステップ９９０において、ＲＰＭシステムはリソースのユーザの属性を取得する。これらの属性は、図２４について述べたように、さまざまな方法で取得できる。ステップ９９２において、ＲＰＭシステムは、図２４において行ったように、ユーザが使用する特定のリソースについて、ユーザアイデンティティが生成されるリソースのアイデンティティルールを含む既定のアイデンティティ方針に従って、そのユーザのアイデンティティを生成する。ユーザアイデンティティが生成されると、ステップ９９４でそのアイデンティティに衝突がないかが確認される。生成されたアイデンティティが過去に付与されていなければ、ステップ９９６でそのユーザに与えられる。しかしながら、生成されたアイデンティティがすでに使用されていれば、ＲＰＭシステムはステップＢに戻り、アイデンティティ方針に従って別のアイデンティティが決定される。
【０１８９】
次に、ステップ９９８で、ＲＰＭシステムは、そのユーザが別のリソースを利用するかを判断する。そのユーザが別のリソースを使用しない場合、アイデンティティ生成はステップ１０００で終了する。ユーザが別のリソースを利用する場合、ステップ９９２において、これらのリソースについてのアイデンティティが、このユーザアイデンティティが生成される追加リソースの各々のアイデンティティルールを含むアイデンティティ方針に従って生成され、このプロセスが続く。各リソースには、ユーザアイデンティティに関するそれぞれの要求事項があるため、ＲＰＭシステムのアイデンティティ方針はこれらの要求事項を考慮する。したがって、ユーザが、たとえばＬＡＮと会社データベースという２つのリソースにアクセスする必要がある場合、アイデンティティはそれぞれのリソースについて生成される。ＬＡＮと会社データベースの両方が、ユーザアイデンティティの中に英数字が含まれることを認めるのであれば、両方のリソースについて、ユーザに同じアイデンティティを与えることも可能である。たとえば、ＲＰＭシステムのアイデンティティ方針がユーザの姓に名の頭文字を続けることによってユーザアイデンティティを付与しようとする。したがって、“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”という名前のユーザがＬＡＮと会社データベースの両方にアクセスする必要がある場合、各リソースについて与えられるユーザアイデンティティは、衝突がなければ“ｗｉｌｌｉａｍｓｊ”となる。アイデンティティが付与されるリソースの数に応じて、複数のリソースに同じユーザアイデンティティを付与することも可能である。しかしながら、リソースのアイデンティティに関する要求事項によっては、ＲＰＭシステムが管理するすべてのリソースに同じユーザアイデンティティを付与することが不可能な場合もある。たとえば、ＬＡＮ等のネットワークが英数字でのアイデンティティを認め、ＰＢＸ等の別のリソースが数字のアイデンティティしか認めない場合、これらのアイデンティティの各々についてのユーザアイデンティティを同じにすることができない。リソースのアイデンティティに関する要求事項は、アイデンティティ方針を決定する前に決めることができるため、両立するリソースのアイデンティティに関する要求事項を持つリソースについて、ひとつのアイデンティティを作ることができるようにアイデンティティ方針を決定することができる。
【０１９０】
このようなアイデンティティ方針において、ひとつのユーザアイデンティティが生成されると、両立可能なリソースのすべてについてそのアイデンティティが固有であることが明確になるまで、両立可能なすべてのリソースについて固有性が確認される。このようなアイデンティティ方針のフローチャートを図２６に示す。ステップ１０１０で、ＲＰＭシステムのアイデンティティ方針は、ユーザに共有されるリソースのリストを得る。ステップ１０１２で、アイデンティティ方針はまた、リソースの共有が行われるユーザの属性を入手する。ステップ１０１４において、ＲＰＭシステムはリストの全リソースについて、そのユーザのユーザアイデンティティを生成する。このアイデンティティは、ユーザの属性に基づき、リスト上のリソースのアイデンティティに関するすべての要求事項を満たすアイデンティティを生成する最初の候補である。最初の候補が生成され、ユーザにアイデンティティが付与されると、システムはステップ１０１６でそのアイデンティティをチェックし、リスト上のいずれかのリソースにおいてすでにそれが使用されていないか確認する。そのアイデンティティがすでに使用されていると、ステップ１０１８において、そのユーザに別のアイデンティティが生成され、ステップ１０１６で再びその固有性が確認される。そのアイデンティティが固有であると、プロセスはステップ１０２０で終了し、そのアイデンティティがユーザに付与される。
【０１９１】
本発明の実施形態によるアイデンティティ方針を使ってユーザアイデンティティを付与するシステムを図２７に示す。ＲＰＭシステム１０３０は、たとえばシステム上の各種ユーザに関する個人情報、ユーザが利用するすべてのリソースのリスト、特定の各リソースに関するユーザのアイデンティティ等、システム上のすべてのアカウントの記録１０３２を維持する。ＲＰＭシステム１０３０が特定のリソース１０３６のユーザのためにアイデンティティ１０３４を生成すると、リソース１０３６がユーザに割り当てられるときに、アイデンティティ１０３４はエージェント１０３８を通じてリソース１０３６に送られる。
【０１９２】
本発明の実施形態によれば、ユーザはＲＰＭシステム専用のアイデンティティを持ち、これはそのユーザが利用する各種のリソースに与えられたアイデンティティと同じかもしれないし違うかもしれない。ＲＰＭシステム専用のユーザアイデンティティには、ユーザを特定し、そのユーザをユーザが利用するすべてのリソースと関連付けるためにシステムオペレータが必要と判断するあらゆる情報が含まれる。たとえば、小さな組織においては、ＲＰＭシステム上のユーザを、そのユーザの名の頭文字に姓を続けたもので識別するというアイデンティティ方針を導入すれば十分である。したがって、“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”という名前のユーザの場合、そのユーザのＲＰＭシステム上のアイデンティティは“ｊｗｉｌｌｉａｍｓ”となる。しかしながら、この単純なアイデンティティ方針はより大規模な組織においては不十分である。大規模な組織の場合、アイデンティティ方針は、名の頭文字、姓、会社組織、社内の地位を使って、ＲＰＭシステム上のユーザを特定する。このようなアイデンティティ方針を使い、エンジニアリング会社で技術者として働く“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”というＲＰＭシステムのユーザのＲＰＭシステム上のアイデンティティは“ｊｗｉｌｌｉａｍｓ， ｅｎｇｉｎｅｅｒｉｎｇ， ｔｅｃｈｎｉｃｉｏｎ”となる。ユーザが特定のリソースにアクセスしたことは、ＲＰＭシステムにとって無関係である。しかしながら、ユーザがリソースにアクセスする以前のいずれかの時点で、たとえばそのリソース上のユーザのアイデンティティ（街頭張る場合）、そのリソースに関するユーザのパスワード等、そのリソースに関する関連ユーザ情報がＲＰＭシステムに入力または保存される。リソースは、ユーザがリソース上のアカウントを持ち、そのアカウントに関連して、たとえばアイデンティティとパスワード等、特定の関連情報を持つことを除き、ユーザに関する何も認識しない。これに対し、ＲＰＭシステムは、たとえばそのユーザが利用するリソースおよびこれらのリソース上でのユーザのアイデンティティ等、ユーザに関する詳細な情報を知る。本発明の他の実施形態によれば、ひとつのリソースのユーザは、そのリソース上に複数のアカウントを有する。たとえば、ＬＡＮのシステム管理者は、個人と管理者の２つのレベルでリソースを利用する。アカウントが２つの目的のために使用されるため、管理の点から見ると、システム管理者は２つの異なるアイデンティティを使ってＬＡＮにアクセスすることが望ましい。
【０１９３】
このように、システム管理者の名前が“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”の場合、そのシステム管理者を採用する会社のアイデンティティ方針により、ＬＡＮ上での個人的アイデンティティは“ｊｓｉｌｌｉａｍｓ”、管理者としてのアイデンティティは“ｊｗｉｌｌｉａｍｓ＿ａｄｍｉｎ”となる。
【０１９４】
この例の一部の擬似コードは次のとおり。
ＩＦ ｐｒｉｖｉｌｅｇｅ＝ａｄｍｉｎｓｔｒａｔｏｒ
ｔｈｅｎ ｉｄｎｅｔｉｔｙ＝ｆｉｒｓｔ ｉｎｉｔｉａｌ＋ｌａｓｔ ｎａｍｅ＋ ”ａｄｍｉｎ”
【０１９５】
本発明の実施形態によれば、アイデンティティはユーザの介入なく確立できる。ＲＰＭシステムがリソースユーザのひとつの属性を得ると、ユーザからそれ以上情報を必要とすることなく、アイデンティティ方針に従ってアイデンティティが生成される。
【０１９６】
このように、たとえば、ある社員について、その社員が組織での勤務を開始する前であっても、その社員の十分な属性がＲＰＭシステムに入力されていればアイデンティティは生成される。本発明の別の実施形態によれば、アイデンティティ方針は、アイデンティティの衝突に対応できるよう、十分柔軟性をもって設計できる。アイデンティティ方針を使い、ＲＰＭシステムは、衝突があった場合、ユーザに照会することなく、あるいはユーザに対話的なプロ施肥に関与させることなく、別のアイデンティティを生成する。ユーザの属性を入手しておけば、アイデンティティ生成プロセスは自動化できる。本発明のさらに別の実施形態により、ユーザアイデンティティはさまざまなレベルで特定のユーザに合わせて作ることができる。たとえば、ある組織は、組織が使用するリソースについてのユーザアイデンティティを、組織内でのユーザの地位を反映するものにしたいとする。このため、組織内の“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”というエンジニアの場合、ＲＰＭシステムのアイデンティティ方針はそのアイデンティティを“ｊｗｉｌｌｉａｍｓ＿ｅｎｇ”とする。同様に、組織内の“Ｍａｒｙ Ｓｍｉｔｈ”という秘書であれば、ＰＲＭシステムのアイデンティティ方針は“ｍｓｎｉｔｈ＿ｓｅｃ”というアイデンティティにする。本発明のさらに別の実施形態によれば、ＲＰＭシステム内のアイデンティティ方針は各種分野のユーザアイデンティティを作ることができる。たとえば、アイデンティティ方針により、デジタル認証、デジタルキー、研究設備、オフィス用ハードウェアあるいはクレジットカードアカウントについてのアイデンティティが作られる。
【０１９７】
パスワード方針に関するシステムの動作
本発明の実施形態によれば、ＲＰＭシステムはひとつまたは複数のパスワード方針を含む。本発明の実施形態によるＲＰＭシステムのパスワード方針は、特定のパスワードが特定のシステムにおいてユーザによって使用されないようにする。本発明の実施形態によるパスワード方針はまた、ユーザに対し、システム内の各リソースについて容認でき、会社または組織のパスワード全般に関する方針と一致するパスワードを作るよう求めるものとすることができる。本発明の実施形態によるパスワード方針はさらに、システム内の各リソースに関するパスワードルールをまとめて、システム内のすべてのリソースに適用できる統一方針とすることもできる。さらに、本発明の実施形態によるパスワード方針は、そのような実施形態におけるパスワードシンタックスとの衝突を認識できる。本発明の実施形態によるパスワード方針は、ハッカーに対する十分な保護を提供できず、システム全体をセキュリティのもろいものとするようなルールセットを排除する。このほか、本発明の実施形態によるパスワード方針は、その方針に適合するパスワードを自動的に生成できる。
【０１９８】
本発明の実施形態により、パスワードは図２８に示すように作られる。ステップ１０４０において、ＲＰＭシステムのリソースのユーザは、所望のパスワードを入力する。このパスワードは、それがＲＰＭシステムにより導入されているパスワード方針と一致するかぎり、ユーザが選ぶどのようなパスワードでもよい。理想的には、ユーザはその方針を知った上で、これに準じてパスワードを選択する。しかしながら、必ずしもそうとは限らず、ユーザはシステムのパスワード方針に適合しないパスワードを入力することもある。すると、ステップ１０４２において、ユーザが選択し、入力したパスワードがシステム内で採用されているパスワード方針と一致するかが確認される。そのパスワードがシステムのパスワード方針と一致していれば、ステップ１０４４でシステムがそのパスワードを受け入れる。しかし、パスワードがシステムのパスワード方針に適合しない場合、ステップ１０４０で再び別のパスワードを入力しなければならず、システムのパスワード方針に適合するパスワードがユーザによって入力されるまで、このプロセスが繰り返される。図２８のステップ１０４２に戻ると、ユーザが入力したパスワードがパスワード方針により定められたルールにより容認されないと、システムはそのルールのユーザを通知する。たとえば、特定のリソースに関するパスワード方針のルールの中に、すべてのパスワードの長さは少なくとも６文字でなければならないというものが含まれ、ユーザが４文字しかないパスワードを入力しようとした場合、システムは次のノーティフィケーションを表示する。「パスワードの長さは少なくとも６文字でなければなりません。もう一度入力してください。」このように、ユーザは次にパスワードを入力しようとしたときに、パスワード方針のパスワードの長さに関するルールを知り、望ましくは、このルールに適合するパスワードを作る。あるいは、ユーザが初めてパスワードを入力する前に、パスワード方針のルール一覧をユーザに提供する。こうすることにより、ユーザが入力するパスワードはすでにパスワード方針に適合しており、システムがユーザにさらに通知する必要がなくなる。まだＲＰＭシステムに入っていない会社または組織の新入社員あるいは何らかの理由によって始めてシステムに入ろうとしているその他の社員について、システムは、図２９に示すように、その社員がシステムに入るために必要なパスワードを自動的に生成する。ステップ１０５０において、システムは、パスワード方針に記載されたルールに従って、その社員のパスワードを生成する。たとえば、システムにまだ入ったことのない社員のパスワードを生成するためのルールでは、その社員の名の頭文字、ピリオド、その社員の姓の順で続ける。しかしながら、システムのパスワード方針には、すべてのパスワードは、長さがピリオド等の特殊文字を含めて少なくとも６文字で、１０文字を超えてはならないという制約がある。したがって、新入社員の名前が“Ｊｏｈｎ Ｗｉｌｌｉａｍｓ”であれば、システムはその社員が初めてシステムに入るときに使用するものとして、“ｊ．ｗｉｌｌｉａｍｓ”というパスワードを自動的に生成する。
【０１９９】
このように、このバスワードは、この例のＲＰＭシステムにおける、すぐ上で説明したばかりのルールに準じている。しかしながら、写真の名前が“Ｊｏｈｎ Ｓｔｅｖｅｎｓｏｎ”であったとする。この例では、自動的に生成されるパスワード“ｊ．ｓｔｅｖｅｎｓｏｎ”は、長さが１０文字を超えてしまうため、ＲＰＭシステムのパスワード方針にはさらにルールを追加しなければならない。この場合、システムのパスワード方針は、たとえば自動生成されたパスワードの長さが１０文字を超えた場合、その社員の姓を切り詰める別のルールを採用する。この例では、システムは、そり社員が初めてシステムに入る時に使用するパスワード、“ｊ．ｓｔｅｖｅｎｓｏ”を自動的に生成する。システムに初めて入るユーザのパスワードの自動生成において必要な追加ルールの別の例として、上の例と同じＲＰＭシステムで、新入社員の名前が“Ｊｏｈｎ Ｌｅｅ”であるとする。自動生成されるパスワード“ｊ．ｌｅｅ”は、パスワード方針の要求事項である６文字に満たないため、パスワード方針に適合しない。
【０２００】
このように、パスワード方針における追加のルールは、自動生成されたパスワードが６文字未満であれば、その社員の名の頭文字ではなく、名をパスワードの最初の部分とする、となる。このように、この例では、パスワード“ｊｏｈｎ．ｌｅｅ”がシステムによって自動的に生成される。このパスワードはパスワード方針を満たしている。パスワードの自動生成に発生するさまざまな状況に対応するために、そのほかのルールをパスワード方針に含めることができる。図２９に戻ると、システムがシステムで採用されているパスワード方針に従ってパスワードを自動生成すると、ステップ１０５２において、そのパスワードは付与の相手となる社員に与えられる。これは、さまざまな方法で行われる。一般的には、パスワードはシステム管理者がその社員に口頭で伝える。社員が自動生成されたパスワードを与えられ、システムに入ることのできる状態となると、この社員は、ステップ１０５４において、システムに自動生成されたパスワードを入力して、システムに入る。システムの中には、ユーザに対し、システムによって与えられた自動生成によるパスワードを変更するよう求めないものもあり、このようなシステムの場合、一部のユーザは、システムによって当初与えられた自動児童生成によるパスワードと同じものを自分のパスワードとして使い続ける。しかしながら、これは賢明な方針ではなく、システムのセキュリティを大きく損なう。よりセキュリティの高いパスワード方針では、ユーザが自動生成されたパスワードでシステムに入った後、すぐにパスワードを変更するよう求められる。したがって、図２９において、社員はステップ１０５４で自動生成されたパスワードを入力した直後のステップ１０５６において、新しいパスワードを入力しなければならない。ここで、プロセスは図２８について説明したものと同様に続けられる。図２９のステップ１０５８において、社員が選択したパスワードをシステムがチェックし、その社員が選択したパスワードがシステムで採用されているパスワード方針に適合しているか判断する。選択されたパスワードがパスワード方針に適合していれば、ステップ１０６０でそのパスワードが容認される。選択されたパスワードがパスワード方針に適合しない場合、ステップ８２６において別のパスワードを入力しなければならず、このプロセスは、社員がシステムのパスワード方針に適合するパスワードを入力するまで繰り返される。
【０２０１】
図２９に示す本発明の実施形態は、いろいろな方法で変更できる。たとえば、システムリソースを使用する社員が自分のパスワードを忘れてしまうことは珍しくない。この場合、自分のパスワードを忘れた社員はシステム管理者に通知する。いくつかの実施形態において、システム管理者またはその他の人物はその社員に対し、セキュリティを守るために、その社員の認証を確認するための質問をする。たとえば、社員がパスワードを忘れたとシステム管理者に伝えたとすると、システム管理者はその社員に対し、その身元を確認するために、社会保障番号を聞く、あるいはその他の質問を行う。社員が確認のための質問に正しく答えられると、システム管理者は、図２９のステップ１０５０に示すように、システムにそのユーザのためのパスワードを自動生成するよう指示する。次に、ステップ１０５２でそのユーザに付与される。社員はすでにシステムで使用するアカウントを持っているため、システムは、これが可能であれば、その社員にパスワードを電子メールで伝える。次に、ユーザはパスワードを入力してシステムに入り、図２９のプロセスが続けられる。
【０２０２】
本発明の実施形態によるパスワード方針により、その方針を採用する会社または組織は、システムのユーザが選択したパスワードについてさまざまな制約を設けることができる。たとえば、前述のように、パスワードの長さが制限される。パスワード方針は、システム内のすべてのパスワードの長さを少なくとも６文字とする、あるいは最低６文字で１０文字を超えない、等のルールを設ける。別の例として、パスワード方針は、システム内のすべてのパスワードが、たとえば句読点その他英数字以外の文字のような特殊な文字を少なくとも１つ含む。このほかにも、パスワード方針の中でパスワードを制約する実施形態が多数ある。たとえば、本発明の実施形態によるパスワード方針は、特定の文字の使用を禁じる。このような方針において、たとえば、フォワードスラッシュ“／”、バックワードスラッシュ“ ”等の文字は、パスワードの中で使用することを禁じられている。あるいは、本発明の実施形態によるパスワード方針は、特定の文字を使用しなければならないと要求する。たとえば、パスワード方針は、パスワードとして有効にするために、すべてのパスワードにピリオド“．”を使用するよう求める。パスワードを制限するパスワード方針の他の実施形態において、文字の繰り返しを限定する。たとえば、パスワード方針の中のひとつのルールが、ひとつの文字を３回以上繰り返さないように求める。これは、怠惰またはシステムのセキュリティに対する意識の低いユーザの場合に往々にして起こる、システムに急いで入ろうとするために“ａａａ”または“ｊｊｊ”等と打ち込むことを禁じる。比較的判断しやすい文字の繰り返しを制限することで、システムのセキュリティレベルが高まる。
【０２０３】
パスワード方針の実施形態によるパスワード制約の別の例を図３０に示す。これは、コンピュータのキーボード１０７０の３列のキーの基本的レイアウトである。一部のユーザは、システムリソースに早く入るために、パスワードとしてキーボード上のシーケンスを入力する。たとえば、シーケンス“ａｓｄｆｊｋｌ”は、多くのシステムユーザがパスワードとして入力するタイプのシーケンスの代表的なものである。このシーケンスは、キーボードのホームキー１０７２を左から右に打ったものであり、システムリソースユーザはしばしば、システムにパスワードを入力するための簡単で素早い方法としてこれを使用する。このようなパスワードは、簡単で素早いため、ハッカーによって発見されやすく、したがって、システムのセキュリティが損なわれる。このため、本発明の実施形態によるパスワード方針は、このようなシーケンスをパスワードとして使用することを制限する。
【０２０４】
このような制限、およびキーボードのシーケンスに関連するその他の制限を実現する擬似コードの例を以下に示す。
ＩＦｐａｓｓｗｏｒｄ＝“ａｓｄｆｊｋｌ”
ｏｒ ｐａｓｓｗｏｒｄ＝“ｊｆｋｄｌｓ；ａ”
ｏｒ ｐａｓｓｗｏｒｄ＝“ｚａｑ１ｘｓｗ２”
ＴＨＥＮ ｄｅｎｙ ｐａｓｓｗｏｒｄ．
【０２０５】
上記の擬似コードの１行目は、パスワードを、コンピュータのキーボードのホームキーを左から右に打ったシーケンスとすることを制限する。２行目は、パスワードを、“ｊ”から始めて別の順番でホームキーを打ち込んだシーケンスとすることを制限する。３行目は、パスワードを、“ｚ”から始めて準水平列の最後のキー“ｌ”を打った後に“ｘ”に戻る、準水平の打鍵シーケンスとすることを制限する。その他多くのキーボードシーケンスが考えられ、パスワード方針はどのシーケンスを制限することもできる。たとえば、パスワード方針は、ある列のいずれか５つのキーのシーケンスを制限する。したがって、このような方針の下では、キーボードのシーケンス、“ａｓｄｆｇ”はパスワードとして認められず、“１２３４５”や“ｚｘｃｖｂ”も認められない。多くのバリエーションが可能であり、これらをパスワード方針に含めることができる。キーボードのシーケンスに基づく制限のほか、本発明の実施形態によれば、パスワード方針で、たとえば個人的情報を含むパスワードを制限できる。したがって、パスワード方針の実施形態は、ユーザの姓または名をパスワードの中に使用することを禁じる。
【０２０６】
パスワード方針の実施例はまた、パスワードの中でユーザの姓または名を逆転させたものを使用することを禁じる。たとえば、ユーザの名が“Ｊｏｈｎ”の場合、パスワード方針のひとつの実施形態は、パスワードまたはその一部として“ｎｈｏｊ”を使用することを禁じる。本発明の実施形態によれば、パスワード方針はまた、パスワードをひとつのリソースで再利用することを制限する。本発明の別の実施形態は、ＲＰＭシステムにより管理されるすべてのリソースでのパスワードの再利用を制限する。たとえば、ＲＰＭシステムは、システム上のすべてのユーザが、定期的、たとえば６ヶ月おきにパスワードを変更するよう求める。ＲＰＭシステムのユーザが、ネットワーキングオペレーティングシステム上のアカウントと会社データベース上のアカウントを持っているものとする。ネットワーキングオペレーティングシステムと課データベースに、相互に矛盾するパスワードに関するルールがあると、両方のリソースのユーザは、それぞれのリソースについて別のパスワードを持つことになる。ＲＰＭシステムで採用されているパスワード方針がユーザに対し、これらのリソースについてパスワードを変更するよう求めると、ユーザはネットワーキングオペレーティングシステムで以前に使用していたパスワードを出たーベース用の新しいパスワードとして使用する、あるいはその逆にすることができる。
【０２０７】
これにより、ユーザにとってパスワードの選択は楽になるが、パスワードが本質的には変更されておらず、単に割り当てなおしただけであるという点で、システム全体にとっては不満足な方針である。このような、割り当てなおすという方法により、ハッカーはシステムに侵入しやすくなり、したがって、システムセキュリティが低下する。本発明の実施形態によるパスワード方針は、このようなタイプの再利用を制限し、システム内のひとつのリソースについて使用されたパスワードを後日、同じまたは別のリソースに使用することができないようにする。
【０２０８】
本発明の実施形態によれば、パスワード方針は、国際的な文字や特殊文字に関するルールを含む。たとえば、文字の場合、漢字等がパスワード方針のルールに含められる。しかしながら、特殊文字や国際的な文字は、組織が採用するパスワード方針によって定義される。一般に、特殊文字は、標準的ＡＳＣＩＩ文字セットに含められていない文字である。しかしながら、本発明の実施形態によれば、特殊文字は、米国で使用されている標準的文字セットに含まれない文字ではなく、会社または組織が採用するパスワード方針で定義された文字である。したがって、本発明の実施形態によるパスワード方針は、国際的に採用される。システムに入力できる文字は、特殊または非特殊文字として指定される。たとえば、特定の漢字がある会社によって特殊文字とみなされると、そのように指定される。さらに、システムは、国ごとに異なるルールを提供するパスワード方針の実施形態を採用することができる。このように、本発明の実施形態によれば、パスワード方針は、たとえば、米国についてはひとつの特殊文字セット、中国その他の外国については別の特殊文字セットを利用できる。さらに、本発明の実施形態によれば、パスワード方針は、たとえば、米国についてはひとつのルールセット、中国その他の外国については別のルールセットを使用できる。
【０２０９】
本発明のある実施形態によれば、各種のリソースについてのパスワードルールセットを、図３１に示すようなＲＰＭシステムのひとつのパスワード方針にまとめることができる。たとえば、ネットワーキングオペレーティングシステムである第一のリソース１０８０は、第一のリソース１０８０にアクセスするためのパスワードに制約を設ける第一のルールセット１０８４を含む。たとえばデータベースである第二のリソース１０８２は、第二のリソース１０８２にアクセスするためのパスワードに制約を設ける第二のルールセット１０８６を含む。第一のルールセット１０８４と第二のルールセット１０８６は、ＲＰＭシステムで採用されるパスワード方針１０９０を構成する第三のルールセット１０８８にまとめることができる。あらゆる数のリソースに専用のあらゆる数のルールセットをひとつのパスワード方針にまとめることが可能である。したがって、本発明の実施形態によれば、パスワード方針は複数のリソースについて定められたパスワードに関するルールの組み合わせである。しかしながら、パスワード方針を採用する会社または組織は、各種のリソースのためのルールの単なる組み合わせより限定的である。実際、いくつかのリソースにはパスワードに関するルールや制約がまったくない。図３１を再び参照し、たとえば、第一のリソース１０８０が、すべてのパスワードは少なくとも６文字の長さでなければならないとするルールを採用しているとする。また、第二のリソース１０８２が、すべてのパスワードは１０文字またはそれ以下の長さでなければならないとするルールを採用するとする。そして、そのシステムにはこれらの２つのリソースしかないとすると、これらのルールを組み合わせることでパスワード方針１０９０ができ、すべてのパスワードは少なくとも６文字から多くとも１０文字までの長さとしなければならないことが求められる。この要求事項にあてはまるパスワードは、両リソースの要求事項を満たす。
【０２１０】
この方針を採用する擬似コードを次に示す。
ＩＦ ｐａｓｓｗｏｒｄ＞＝ｓｉｘ ｃｈａｒａｃｔｅｒｓ
ａｎｄ ｐａｓｓｗｏｒｄ＜＝ｔｅｎ ｃｈａｒａｃｔｅｒｓ
ＴＨＥＮ ａｃｃｅｐｔ ｐａｓｓｗｏｒｄ
ＥＬＳＥ ｇｅｔ ｎｅｗ ｐａｓｓｗｏｒｄ
【０２１１】
しかしながら、パスワード方針１０９０を採用する会社または組織は、第一のリソース１８０１と第二のリソース１０８２に求められるルールは、ユーザが持つパスワードのタイプに十分な制約を加えないと感じる。したがって、第一のリソース１０８０と第二のリソース１０８２について存在する、パスワードの制約に関するルールに加え、本発明の実施形態によれば、パスワード方針１０９０が第一のリソース１０８０と第二のリソース１０８２のいずれにも要求されなかった新たなルールと制約を利用する。たとえば、パスワード方針１０９０を利用する会社または組織が、各パスワードに少なくとも２つの特殊文字を含めることにしたいとする。そこで、パスワード方針１０９０は、すべてのパスワードの長さを少なくとも６文字から多くとも１０文字にすることに加え、これらの文字の２つは、たとえば！，＠，＃，＄，％，Λ，＆，＊等の特殊文字とするよう求める。多くの特殊文字が利用でき、会社や組織はどの文字を特殊文字と定義することもできる。このように、上記の文字が特殊文字であり、あるいは会社または組織が句読点や国際的文字を特
殊文字に定義する。
【０２１２】
この方針を実現する擬似コードの例を以下に示す。
ＩＦ ｐａｓｓｗｏｒｄ＞＝ｓｉｘ ｃｈａｒａｃｔｅｒｓ
ａｎｄ ｐａｓｓｗｏｒｄ＜＝ｔｅｎ ｃｈａｒａｃｔｅｒｓ
ａｎｄ ｔｗｏ ｃｈａｒａｃｔｅｒｓ＝ｓｐｅｃｉａｌ ｃｈａｒａｃｔｅｒｓ
ＴＨＥＮ ａｃｃｅｐｔ ｐａｓｓｗｏｒｄ
ＥＬＳＥ ｇｅｔ ｎｅｗ ｐａｓｓｗｏｒｄ
【０２１３】
本発明のある実施形態によれば、ＲＰＭシステムで採用されているパスワード方針はまた、システム上のリソース間のシンタックスの矛盾を検出する。再び図３１において、第一のリソース１０８０と第二のリソース１０８２は、パスワード方針の一部として、どの英数字でも含められるとしているとする。しかしながら、たとえばＰＢＸ等の第三のリソース（図示せず）がすべてのパスワードを数字だけにするよう求めたとする。すると、第一のリソース１０８０、第二のリソース１０８２および第三のリソースを満足するパスワードを作ることは不可能である。したがって、本発明の実施形態によれば、パスワード方針１０９０は、第一のリソース１０８０と第二のリソース１０８２および第三のリソースを使用するユーザのための２つのパスワードを作る。
【０２１４】
本発明の実施形態によるパスワード方針は、システム内のすべてのリソースにまたがって利用できるパスワードを提供するが、本発明の実施形態によるパスワード方針では、システム上の各種のリソースのパスワードルールに矛盾がある場合、できるだけ少ないパスワードを作るようなルールも利用できる。あるシステム上の各種のリソースに関するルールセットをひとつのパスワード方針にまとめる際、そのパスワード方針のルールセットは過剰に限定的となる場合がある。
【０２１５】
このように、本発明の実施形態によれば、パスワード方針は、それが、時として「弱い」パスワードルールセットと呼ばれる、過剰に限定的なパスワードルールセットを自動的に検出するようにＲＰＭシステムの中で利用することができる。たとえば、再び図３１において、第一のリソース１０８０がすべてのパスワードを少なくとも６文字の長さにするよう求めるとする。さらに、第二のリソース１０８２が、すべてのパスワードを６文字より長くするよう求めるとする。パスワード方針１０９０がこれらのルールセットを第三のルールセット１０８８にまとめた場合、システム内で利用できるパスワードは６文字ちょうどのながさとなり、６文字のパスワードが、第一のリソース１０８０のルールセットと第二のリソース１０８２のルールセットを同時に満足する唯一のパスワードとなる。このようなパスワードの限定により、ハッカーに対するセキュリティがほとんどなくなるため、パスワード方針１０９０を利用する会社その他の組織は、より限定的でないルールセットを設計する。図３１を使った直前の例では、パスワード方針１０９０が第一のリソース１０８０のルールセットと第二のリソース１０８２のルールセットを第三のルールセット１０８８にまとめると、長さがちょうど６文字のパスワードができる。パスワード方針１０９０を利用する会社またはその他の組織が、その第三のルールセット１０８８は限定的すぎ、ハッカーがパスワードを特定し、システムに侵入しやすくなると判断した場合、その会社または組織は第一のリソース１０８０と第二のリソース１０８２についてそれぞれ異なるパスワード、あるいは別の、より限定的でないルールセットが必要であると考える。
【０２１６】
本発明の実施形態によって弱い、つまり限定的すぎるルールセットを判断する方法を図３２に示す。図の実施形態は、ランダムの数を使った数字によるシミュレーション方法であるモンテカルロ方式を利用したものである。モンテカルロ方式は当業界で周知であるため、ここでは詳細な説明を割愛する。ステップ１１００において、システムは、システムのすべてのリソースのルールセットの組み合わせとＲＰＭシステムを利用する組織が設けたその他のルールに基づいて、パスワードに関する制約（仮のパスワード方針）を決定する。ステップ１１０２で仮のパスワード方針が決定すると、ステップ１１０４でシステムがランダムのパスワードを生成する。ステップ１１０４で生成された各パスワードは、ステップ１１０６でチェックされ、生成されたパスワードがそのシステムについて認められたパスワード群に入るか判断される。所定の数のランダムなパスワードを一巡した後に、そのシステムについて認められるパスワード群に入るものがないと、そのパスワード方針は限定的すぎる、つまり「弱い」と判断され、その制限の範囲で利用できるパスワードがあまりにも少ないため、ハッカーが容易にパスワードを特定し、システムに入ってしまう。このように、ステップ１１０８において、パスワード方針は、より限定的でなく、もっと多くのパスワードが利用でき、ハッカーによるパスワードの特定とシステムへの侵入が困難なものとなるように変更される。しかしながら、所定の数のランダムに生成されたパスワードを一巡し、ひとつまたは複数がそのシステムについて認められるパスワード群に入る場合、そのパスワード方針は限定的すぎないと判断され、この試験はステップ１１１０で終了する。
【０２１７】
図３２に示す実施形態を、以下に別の方法で説明する。考案されたパスワード方針が限定的すぎるか否か、つまり弱いか否かを試験するために、ひとつのパスワードをランダムに選択する。選択されたパスワードがそのシステムについて使用可能なパスワード群に入れば、そのパスワード方針は限定的すぎず、その目的に適合すると判断される。しかしながら、選択されたパスワードがシステムで利用可能なパスワード群に入らなければ、別のパスワードをランダムに選択し、それがシステムについて利用可能なパスワードの中に入るかを確認する。このプロセスは、ランダムに選択されたパスワードがシステムで利用できるものとなるまで、そのパスワード方針を利用する会社または組織が適当と判断する試行回数の範囲で繰り返される。たとえば、パスワード方針が、ランダムに選択されたパスワードが５００回以内にシステムによって認められなければそれは限定的すぎる、と定める。試行回数は、そのパスワード方針を利用する会社または組織が適当と判断するどのような回数でもよい。モンテカルロ方式は一般に、パスワード方針が限定的すぎるか否かを判断するために行われる従来の分析と比較して、計算上、低コストである。さらに、モンテカルロ方式は一般に高速で信頼性が高い。パスワード方針が限定的すぎるか否かを判断するための、モンテカルロ方式を使用した別の実施形態も可能である。たとえば、前述の実施形態において、ランダムに生成されたパスワードが特定の試行回数内に仮のパスワード方針を満足すれば、たとえランダムに生成されたパスワードが「まぐれ当たり」で、偶然、実際には限定的すぎるパスワード方針を満足しただけであったとしても、そのパスワード方針は限定的すぎないと判断される。
【０２１８】
このような誤った判断を避けるために、本発明の別の実施形態によれば、一定数のランダムに生成されたパスワードについて、ＲＰＭシステム内のパスワード方針に適合するか試験する。一定数の生成されたパスワードの中の容認されたパスワードの数が、そのパスワード方針を利用する会社または組織によって決定されるパーセンテージと同じまたはこれを超えた場合、そのパスワード方針は限定的すぎないと判断される。あるいは、ランダムに生成されたパスワードが、特定の試行回数の中で仮のパスワード方針を満足した場合、容認されたパスワードが単なる「まぐれ」ではないことを確認するために、このプロセスをさらに１，２回繰り返す。
【０２１９】
モンテカルロ方式に代わるものとして、本発明の別の実施形態によれば、従来の分析によってパスワード方針が限定的すぎるか否かを判断する。たとえば、パスワード方針の範囲で、統計的分析を行って、容認されるパスワードの総数を調べ、また、ハッカーが容認可能なパスワードを特定する可能性が判断される。ＲＰＭシステムが本発明の実施形態によってパスワードを決定するシステムを図３３に示す。図のように、ＲＰＭシステム１１２０はエージェント１１２２を介して管理されたリソース１１２４とインタフェースする。エージェント１１２２は、これらの情報を、たとえばアカウントパスワードテーブルを維持する等、さまざまな方法で保持される。あるいは、これらの情報はリソース１１２４の中に保存され、エージェント１１２２の要求に応じてエージェント１１２２に伝えられる。図３３において、ＲＰＭシステム１１２０が、ユーザによって端末１１２６に入力されたユーザからのパスワードを受け入れると、ＲＰＭシステム１１２０はエージェント１１２２に通知し、エージェント１１２２にパスワードを渡す。エージェント１１２２は次に、リソース１１２４に通知し、パスワードをリソース１１２４に渡し、ユーザがそのパスワードでリソース１１２４にアクセスできるようにする。
【０２２０】
エージェントの説明
ＲＰＭシステムと管理されたリソースのインタフェースに互換性がないため、ソフトウェアエージェントを、ＲＰＭシステムと管理されたリソースの間の変換機として書き、配置する。本発明の実施形態は、エージェント開発者用キット（ＡＤＫ）を使って、管理されたリソースにアクセスするためのエージェントをモジュール形式で開発するためのシステム、デバイス、方法に関する。このようなエージェントのモジュール形式の開発のためのシステム、デバイス、方法により、開発者は作業を共有し、別のエージェントのソフトウェアを理解し、またデバッギングを行い、あるいは他のエージェントの開発を引き継ぐことができる。ＡＤＫは、特定の機能を実行するためのソフトウェアモジュールの標準化されたセットを含み、このソフトウェアモジュールセットは、リソースの管理のためにエージェントに共通する特徴にしたがって開発される。
【０２２１】
このようなソフトウェアモジュールと機能のセットを開発することにより、本発明は、開発者が最小限のコードで、リソースを管理する均一なエージェントを素早く、効率的に、一貫して製造するために使用する「ビルディングブロック」セットを提供する。たとえば、特定のプロトコル別モジュールを利用することにより、開発者はプロトコル別の“ａｄｄ ｕｓｅｒ”メッセージをプロトコルとは独立したメッセージに変換することができる。開発者は、特定の機能に、プロトコルとは独立したメッセージから“ａｄｄ ｕｓｅｒ”要求に必要なデータを抽出させ、このデータを管理されているリソースに送信するコードを書くことができる。完成したエージェントは、ソフトウェアモジュールと機能、開発者のコード、管理されているリソースのためのＡＰＩのコピーを含む。
【０２２２】
図３４に示すように、ＦＴＰプロトコル１１３４は、エージェント１１３２を通じてＲＰＭシステム１１３０と第三者サービスプロバイダまたは管理されたサービス（まとめて、管理されたリソース１１３６という）との間の通信を行うのに使用される。したがって、ＲＰＭシステム１１３０は、ＦＴＰプロトコル１１３４を使って要求をエージェント１１３２に送り、エージェント１１３２はＦＴＰプロトコル１１３４を使ってＲＰＭシステム１１３０に応答する。ＦＴＰプロトコルによるメッセージフォーマットは基本的にパケットまたはファイルである。エージェント１１３２は、ＲＰＭシステム１１３０によって送られるこのパケットまたはファイルを読み、関連するデータを抽出し、一般に管理されたリソース１１３６によって提供されるＡＰＩを呼び出してファイルまたはパケットを要求に変換する。注意が必要なのは、ＲＰＭシステム１１３０は、管理されたリソース１１３６に直接アクセスするのではなく、ＲＰＭシステム１１３０はエージェント１１３２と協力し、管理されたリソース１１３６へのアクセスを管理する。
【０２２３】
図３５に示すように、本発明の実施形態によるエージェント１１３２は複数の主要な要素で構成される。エージェントには、エージェント開発者用キット（ＡＤＫ）（後述）の一部として提供されるソフトウェアモジュールのひとつまたは複数のライブラリ１１４０、エージェントプログラム１１４２（開発者によって書かれるコード）および管理されたリソース１１３６のためのＡＰＩ １１４４が含まれる。ひとつのライブラリには、クライアント（たとえば、ＲＰＭシステムサーバ）とサーバ（たとえば、管理されたリソース用のサーバ）の間でメッセージを通信するためのプロトコルプラグイン１１５４が含まれる。ＲＰＭシステムからの要求という形態でのメッセージ１１４６は、たとえばファイルトランスファプロトコル（ＦＴＰ）やＴｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＴＣＰ／ＩＰ）等、多数のプロトコルを使って通信される。これらのプロトコルのいずれかを使って通信されるメッセージ１１４６を受け取るために、本発明の好ましい実施形態において、ライブラリ１１４０は書くプロトコルのためのソフトウェアモジュールを有する。このように、図３５に示すように、プロトコルプラグインライブラリ１１５４は、ＦＴＰソフトウェアモジュール１１４６、ＴＣＰ／ＩＰモジュール１１５６、汎用Ｘプロトコルモジュール１１６２を含み、他のプロトコルもサポートされることを示している。メッセージ１１４６が特定のポートで受け取られると、プロトコルプラグインライブラリ１１５４の中の、そのポートに関連するプロトコル別モジュールは通信から関連情報を抽出し、メッセージをプロトコルとは独立したものとし、エージェント１１３２の残りが読むことのできるフォーマットにメッセージの内容をマッピングする。さらに、ＲＰＭシステムとエージェントを製造する会社は、新しいプロトコルを作り、エージェントがＲＰＭシステムとエージェントの間で通信できるようにするためのプロトコル別モジュールを書く。
【０２２４】
別の例において、エージェントは、新しいプロトコルを作り、エージェントのための新しいプロトコル別モジュールを書く第三者に販売される場合もある。別のライブラリはＥｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ ＡＰＩ（ＥＲＭＡ）ライブラリ１１５８というメッセージ抽出ライブラリである。ＥＲＭＡライブラリ１１５８の中のひとつのモジュールは、動的にプロトコルプラグイン１１５４をロードする。
【０２２５】
さらに、開発者はＥＲＭＡライブラリ１１５８における別のソフトウェアモジュールを使って、発信源（たとえば、ＲＰＭシステムサーバ）からメッセージを抽出する。ＡＤＫの一部として提供されるＥＲＭＡライブラリ１１５８は、リソースを管理するためのエージェントが必要とする機能（たとえば、ユーザの追加、削除その他）を考慮して書かれたソフトウェアモジュールを含む。ソフトウェアモジュールは、プロトコルプラグインモジュールによって定義されたフォーマットに従ってメッセージの内容にアクセスするために使用されるメッセージングまたはルーチンを含む。ＥＲＭＡライブラリ１１５８は、こうして、エージェントプログラム１１４２のためのプロトコル抽出レイヤを提供する。インタフェースライブラリ１１６０は、エージェントプログラム１１４２と抽出されたメッセージのインタフェースであり、アクティビティロギング機能１１５２、コンフィギュレーションデータおよびメッセージデータそのものが含まれる。ＥＲＭＡライブラリ１１５８によって抽出されたデータにアクセスするために、エージェントプログラム１１４２は、インタフェースライブラリ１１６０の中の各種の機能にＡＰＩコールを行わなければならず、これがＥＲＭＡライブラリ１１５８の中のプロトコルとは無関係の各種ルーチンに対し、当初のメッセージ１１４６のプロトコルにかかわらず、メッセージから追加ユーザ情報を抽出させる。さらに、前述のプロトコルはすべてメッセージの暗号化、復号をサポートするため、好ましい実施形態は、インタフェースライブラリ１１６０の中に暗号化および復号ソフトウェアモジュール１１５０を含む。エージェント１１３２は、エージェントに係わる管理されたリソースのためのＡＰＩ １１４４のコピーを含む。ＡＰＩ １１４４の中に、メッセージ１１４６の中で指定されたあらゆるタイプの要求（たとえば、追加、変更、削除、検索）を実行するファンクションコールがある。ファンクションコールはＡＰＩ内のコードであり、開発者によってかかれたものではないことに注意されたい。エージェント１１３２はまた、管理されたリソース１１３６と通信するための、管理されたリソース１１３６専用のアプリケーションプログラムインタフェース（ＡＰＩ）を備える。
【０２２６】
図３５のエージェントの使用例について説明する。ＲＰＭシステムを使ったクライアントがエージェント１１３２を通じて、管理されたリソース１１３６にメッセージ１１４６を送るとする。メッセージ１１４６は、たとえば、追加、ム変更、削除または検索要求等である。メッセージ１１４６が受信されると、プロトコルプラグインライブラリ１１５４内のプロトコル別モジュールが該当する情報を通信から抽出し、メッセージはプロトコルとは独立したものとなる。エージェントプログラム１１４２は、メッセージの中で特定された要求の種類を判断し、インタフェースライブラリ１１６０の中のひとつまたは複数の機能を呼び出し、これがＥＲＭＡライブラリ１１５８の中のその要求に応じたモジュールに対し、メッセージから要求の実行に必要なデータを抽出させる。データには、メッセージの発信者は誰か、アカウント番号、追加すべての属性等が含まれる。たとえば、管理されたリソース１１３６がＮＴオペレーティングシステムであるとすると、追加要求にはユーザ名、ユーザＩＤ、ホームディレクトリ、グループ名が必要となる。
【０２２７】
別の例において、ユーザのホームディレクトリを変更するための変更要求が受信されると、新しいホームディレクトリ情報がメッセージの中に含まれる。さらに、メッセージが終了すると、エージェントプログラム１１４２が暗号化／復号モジュール１１５０に対し、必要な暗号化または復号を実行させる。同様に、アクティビティロギングが必要な場合、アクティビティロギングモジュール１１５２が呼び出される。開発者には、ＲＰＭシステムに関連する人物、独立した契約者または管理されたリソースに関係する人物が含まれる。これにかかわらず、すべてのエージェント開発者の目標は、ＲＰＭシステムが特定の管理されたリソースへのアクセスを管理できるようなエージェントプログラム１１４２を開発することである。
【０２２８】
本発明の実施形態において、開発者は、エージェントプログラム１１４２を書くために、ソフトウェアモジュールの詳細を知る必要がある。開発者の見地から、開発者は、ソフトウェアモジュールが何を実行するか、どのパラメータが必要か、見返りに何が得られるかだけがわかればよい。たとえば、上述のように、インタフェースライブラリ１１６０内の２つのソフトウェアモジュールは、アクティビティロギングと暗号化または復号を実行する。開発者は、その所期の機能を実行するエージェントプログラムを書くために、これらのモジュールを正しく呼び出す方法だけが理解できればよい。インタフェースライブラリ１１６０の中の各種機能に対し、メッセージデータに関する特定の動作を抽出し、実行させた後、エージェントプログラム１１６０は、ＡＰＩ １１４４の中からその要求専用の適当な機能を呼び出し、これらの機能にデータを送る。次にＡＰＩ １１４４は、管理されたリソース１１３６に要求を伝える。管理されたリソース１１３６は、要求が完了すると、ＲＰＭシステムにメッセージを戻す。
【０２２９】
共通のエージェント機能に基づくソフトウェアの機能
本発明の好ましい実施形態は、リソースを管理するすべてのエージェントが一連の共通の機能を共有するという事実を利用している。好ましい実施形態において、ＡＤＫが開発される前に、リソースを管理するためのすべてのエージェントに共通の機能を特定しなければならない。次に、ソフトウェアモジュールを含む一連のライブラリを開発し、開発者が特定された共通の機能のすべてを実行できる、リソース管理用エージェントを書くことができるようにしなければならない。たとえば、アクティビティロギングは共通のエージェント機能であるため、アクティビティロギングソフトウェアモジュール５６（図３５参照）を開発することができる。その後、開発者が行動ロギングを可能にしたい場合、開発者は最初からアクティビティロギングコードを書くのではなく、エージェントプログラム１１４２の中からアクティビティロギングソフトウェアモジュール１１５２を呼び出すだけでよい。実行されると、アクティビティロギングソフトウェアモジュール１１５２は、いくつかの可変値を受け取り、アクティビティロギングを行い、その結果をメインエージェントプログラム１１４２に渡す。しかしながら、共通のエージェント機能とソフトウェアモジュールが必ずしも１対１で対応するとはかぎらないと理解すべきである。
【０２３０】
言い換えれば、共通のエージェント機能には、複数のソフトウェアモジュールを必要とするエージェントコードを書かなければ実現できないものもある。たとえば、開発者がユーザアカウントを追加することを可能にしたい場合、開発者はそのコードを最初から書くのではなく、ライブラリの中からいくつかのソフトウェアモジュールを呼び出すだけでよい。実行サルと、これらのソフトウェアモジュールは、ユーザが求める追加を実行する。共通のエージェント機能のいくつかについてすでに説明したが、エージェント機能のより完全なリストを以下に示す。リソースを管理するための各エージェントには、ｒｐｍシステムから、ユーザアカウントの追加、無策所、変更、停止、再開を行う要求を受け取り、アプリケーションデータベースを検索する能力が必要である。したがって、本発明の好ましい実施形態において、ユーザアカウントの追加、削除、変更、停止、再開を行うのに必要なデータを受信するメッセージから抽出する別の機能がインタフェースライブラリ１１６０に含まれる。
【０２３１】
前述のように、別の一般的なエージェントの機能はアクティビティロギングである。アクティビティロギングは、エージェントがログファイルによって実行する各種の作業のリアルタイムの状態を保持する機能である。たとえば、エージェントは、特定の数のログファイルを構成することに使用でき、この限界に到達すると、最も古いログファイルの上に新しいログファイル情報が書き込まれる。アクティビティロギングは主として、管理されたリソースの管理者またはＲＰＭシステム管理者のためのものである。したがって、本発明の好ましい実施形態において、アクティビティロギング機能５６は、インタフェースライブラリ１１６０に含まれる。
【０２３２】
別の共通のエージェント機能はメッセージの認証と許可である。エージェントがＲＰＭシステムからメッセージを受けると、メッセージの中には、そのメッセージを送信したユーザを特定する情報とユーザの許可レベルに関する情報が埋め込まれている。認証は、そのメッセージが予想される発信源からのものであることを判断する機能であり、許可はそのユーザがメッセージに含まれる要求を実行する権利があることを判断する機能である。したがって、本発明の好ましい実施形態において、認証および許可機能１１６４がインタフェースライブラリ１１６０の中に含まれる。別の共通のエージェント機能は、メッセージプロトコルである。前述のように、ＲＰＭシステムからの要求は、ＦＴＰ、ＴＣＰ／ＩＰ等、各種のプロトコルを使って通信される。受信メッセージのプロトコルは、情報を受け取ったポート１１７０に基づいて決定される。
【０２３３】
図３５に示すように、管理されたリソース１１３６のためのサーバは常に、特定のポート上の特定のプロトコルを使ってメッセージを聞く。すべてのパーソナルコンピュータ（ＰＣ）、メインフレーム、あるいはＵｎｉｘ（登録商標）ベースのシステムには、Ｉｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ａｎｕｍｂｅｒｓ Ａｕｔｈｏｒｉｔｙ（ＩＡＮＡ）デーモンが含まれ、これがポート番号を書くプロトコルに割り当てる（たとえば、ポート１０００が特定のプロトコルに割り当てられる）。サーバは次に、ポート１０００から、そのプロトコルを使って伝えられたメッセージがあるか聞く。各メッセージは特定のプロトコルを使って符号化されているため、ＲＰＭシステムサーバ等のクライアントは、特定のホストアドレス（ＩＰアドレス）とメッセージに含まれるポート番号にしたがって、管理されたリソース１１３６のサーバに接続する。したがって、本発明の好ましい実施形態において、プロトコルプラグインのライブラリ１１５４は、サポートされているプロトコルのいずれかを使って通信されるメッセージを受信するために含められる。
【０２３４】
図３５はひとつの汎用エージェント１１３２を示しているが、本発明の好ましい実施形態において、各エージェントは、たとえばＮＴ、Ｕｎｉｘ（登録商標），ｌｉｎｕｘ，ＡＩＳ等、多数のオペレーティングシステムプラットフォームの中で一貫したＡＰＩインタフェースを提供する。こうして、図３６のように、好ましい実施形態において、各エージェント１１３２は、サポートされるそれぞれのオペレーティングシステムについて、別のプロトコルプラグインライブラリ１１５４とＥＲＭＡライブラリ１１５８を有する。しかしながら、エージェントプログラム１１４２から見ると、インタフェースライブラリ１１６０は、各オペレーティングシステムについて、ＥＲＭＡライブラリへの同じファンクションコールを使用する。しかしながら、本発明の別の実施形態において、各エージェント１１３２が出荷される際、エージェント１１３２は管理対象のリソースの特定のオペレーティングシステムのために構成される。特定のオペレーティングシステムのインストールファイルを製品とともに提供し、ユーザには、特定のオペレーティングシステムのためにエージェント１１３２を構成する際、インストールファイルを実行するよう指示を与えることもできる。構成後、エージェント１１３２のうち、特定のオペレーティングシステムに専用の部分のみイネーブルされる。また、管理されたリソース各々のＡＰＩ １１４４は、特に管理されたリソースのオペレーティングシステムについて描かれていることにも注意すべきである。たとえば、同一の２つの管理されたリソースがあり、ただし、それぞれが相互運用できるオペレーティングシステムが異なる場合、管理されたリソースの各々は、特定のオペレーティングシステムのために特に書かれた異なるＡＰＩを使用する。管理されたリソースと使用されるオペレーティングシステムは、エージェント１１３２の完成前に決定できるため、そのオペレーティングシステムのために特に書かれたＡＰＩ １１４４は、エージェント１１３２の中にコピーでき、開発者のエージェントプログラム１１４２は、そのＡＰＩ １１４４と相互運用可能になるよう特に書くことができ、これを呼び出すことができる。エージェント１１３２にはまた、共通のコンフィギュレーション設定とレジストリ設定があり、これらのオペレーショなるプラメータをエージェント１１３２が受け取り、確認してからでないと、エージェントプログラム１１４２の実質的部分の実行を進めることができない。コンフィギュレーション設定は、エージェント１１３２がサポートするプロトコルを示す。
【０２３５】
このように、すべてのコンフィギュレーションデータはすべてのエージェントについて同じでなければならない。レジストリ設定にはアクセス情報が含まれる。たとえば、ほとんどのエージェント１１３２は、ユーザに管理されたリソース１１３６へのアクセスが認められる前に、ユーザ名とパスワードを必要とする。このレジストリ情報は、管理されたリソースのサーバ内のシステムレジスタに記憶することができる。別のレジストリ情報としては、前述のログファイルサイズがある。
【０２３６】
したがって、本発明の好ましい実施形態において、コンフィギュレーションおよびレジストレーション機能１１６６は、インタフェースライブラリ１１６０に含まれる。別の共通のエージェント機能はインターナショナリゼーションであり、これは、エージェントが複数の言語でユーザの要求を扱い、これらの言語を、ＡＰＩを通じてサポートする能力である。たとえば、Ｗｉｎｄｏｗｓ ＮＴ（登録商標）のために書かれたエージェントにより、英語のＲＰＭシステム要求がＷｉｎｄｏｗｓ ＮＴ（登録商標）の英語バージョンに流れ、また中国語のＲＰＭシステム要求はＷｉｎｄｏｗｓ ＮＴ（登録商標）の中国語バージョンに流れる。英語は、８ビット（シングルバイト）のストリングであるＡｍｅｒｉｃａｎ Ｓｔａｎｄａｒｄ Ｃｏｄｅ ｆｏｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｉｎｔｅｒｃｈａｎｇｅ（ＡＳＣＩＩストリング）を使用する。
【０２３７】
したがって、英語の文字はすべて、２５５文字またはそれ以下で表すことができる。ラインフィードやタブ等、非視覚的文字は、ゼロから３１までのバイト値によって表される。印刷可能なＡＳＣＩＩ文字は、３２から１２７までのバイト値によって表される。グラフィクスに文字やウムラウト等の特殊文字を含む拡張ＡＳＣＩＩは、１２８から２５５までのバイト値で表される。他の言語には２バイトが必要であり、これは６８，５３６文字を表すことができる。ほとんどのオペレーティングシステムは２バイトエンコーディングをサポートする。ＵＴＦ−８エンコーディングは、言語に応じて、１から４バイトのデータで世界中のあらゆる文字を表記する方法である。したがって、たとえば、エージェント１１３２は、管理されたリソースのためのＡＰＩがインターナショナライズされたストリングをサポートするかぎり、中国語に基づくＲＰＭシステムからの中国語の文字を受信できる。中国語に基づくＲＰＭシステムのためのエージェントの開発者は、エージェントが受信するＵＴＦ−８コーディングのタイプ（たとえば３バイトＵＴＦ−８）を事前に知ることになる。ほとんどのＡＰＩが２バイトフォーマットであるＵＣＳ−２をサポートする。したがって、エージェントプログラム１１４２は、管理されるリソースがＵＣＳ−２をサポートするかぎり、ＵＴＦ−８コード化された文字をＵＳＣ−２フォーマットにマッピングするためのインターナショナリゼーション機能１１６８へのコールを含めるよう書くことができる。
【０２３８】
エージェントプログラムは、文字を正しいフォーマットで抽出するために、インタフェースライブラリの中に適当な「ストリング入手」機能を必要とする。たとえば、再び図３５において、ＲＰＭシステムが中国語を使って要求をエージェント１１３２に送り、通信プロトコルはＴＣＰ／ＩＰであると仮定する。この要求は、ＴＣＰ／ＩＰプロトコルソフトウェアモジュール１１５６により、プロトコルに関係のないデータに変換される。この時点で、要求はまだ中国語のままである。エージェントプログラム１１４２は、中国語を予想して書かれているため、中国語のデータを処理する。さらに、たとえば、要求がＵＴＦ−８のフォーマットであり、管理されたリソースがＵＣＳ−２しか受け入れないことがわかっている場合、エージェントプログラム１１４２によってＵＴＦ−８からＵＣＳ−２への変換を行うためのインターナショナリゼーションＡＰＩ １１６８が要求される。別の共通のエージェント機能は、インストールとパッケージである。エージェントのパッケージは、できるだけ同様であるべきである。インストールプログラムは、エージェント１１３２をインストールするために、完成したエージェント１１３３２と一緒に管理されているリソースの管理者に提供することもできる。書くエージェント１１３２は、インストールプロセスがエージェントごとに同じになるように、同じインストールソフトウェアを使用すべきである。
【０２３９】
要求とエージェントプログラムのサンプル
前述のように、リソースを管理するためのエージェントに共通の機能を特定し、これらの機能を実行するための一連のソフトウェアモジュールと機能を開発することにより、本発明は、開発者が最小限のコードでリソースを管理するための均一なエージェントを迅速に、効率的に、一貫して制作するために使用できる、一連の「ビルディングブロック」を提供する。一例として、ＲＰＭシステムからの要求のサンプルセグメントと開発者のエージェントプログラムのサンプルセグメントを詳細に説明する。ＲＰＭシステムがエージェントに要求を送ると、これはプロトコルデータユニット（ＰＤＵ）の形態である。
【０２４０】
ＰＤＵのサンプルを次に示す。
Figure 2005503596
【０２４１】
ＰＤＵは、追加、変更、削除または検索作業といった“ｏｐｅｒａｔｉｏｎ”の数値を含む。ＰＤＵはまた、エントリと呼ばれるサブオブジェクトを含み、これには２つのタイプのパラメータ、“ｔｙｐｅ”と“ｎａｍｅ”がある。“ｔｙｐｅ”のパラメータは要求をさらに特定し、“ｕｓｅｒ”（要求を行っている実体のタイプを特定する）等の値を含み、“ｎａｍｅ”のパラメータは要求しているユーザのＩＤを含む。各エントリにはまた、属性（ａｔｔｒｉｂｕｔｅ）と呼ばれるひとつまたは複数のオブジェクトを含み、さらに要求を特定する。属性には“ｏｐｅｒａｔｉｏｎ”と“ｎａｍｅ”という２つの値がある。“ｏｐｅｒａｔｉｏｎ”の値には、たとえば、追加、変更、削除、“ｎａｍｅ”の値にはたとえば「ディレクトリへのアクセス」（“ｄｉｒｅｃｔｏｒｙ ａｃｃｅｓｓ”）がある。ＰＤＵレベルでの追加、変更または削除作業は、前述のように、属性レベルでの追加、変更または削除作業とは異なるかもしれない点に注意されたい。たとえば、ＰＤＵレベルにおいて、“ｏｐｅｒａｔｉｏｎ”の値は“ｍｏｄｉｆｙ”（変更）かもしれないが、同じＰＤＵの属性レベルでは、変更要求を実行するために、特定の属性を“ａｄｄ”（追加）する必要があるかもしれない。属性はまた、要求に関連するひとつまたは複数の値を含む場合がある。ひとつの要求の中の複数の属性を変更するために、複数の属性が各エントリの中に含まれることもある。ＲＰＭシステムは、上記の情報を入力するためのフィールドを含むグラフィクスによるフォームをユーザに提供する。開発者のエージェントプログラムにおいて、開発者は、エージェントに対し、特定の要求を受け取ったときにどのように「起こす」べきかを指示する、コールバックまたはトリガーをエージェントに登
録する。
【０２４２】
たとえば、ＡＰＩのファンクションコール、
ＡＤＫ＿ｒｅｇｉｓｔｅｒ＿ｍｏｄｉｆｙ＿ｃａｌｌｂａｃｋ（ｍｙ＿ｍｏｄｉｆｙ＿ｈａｎｄｌｅｒ）
は、エージェントに対し、変更要求を受け取ったとき、開発者のエージェントプログラムのどの領域を呼び出すか（この例では、ｍｙ＿ｍｏｄｉｆｙ＿ｈａｎｄｌｅｒ）を伝える。たとえば、エージェントプログラムのうち、ｍｙ＿ａｄｄ＿ｈａｎｄｌｅｒ，ｍｙ＿ｄｅｌｅｔｅ＿ｈａｎｄｌｅｒ，ｍｙ＿ｓｅａｒｃｈ＿ｈａｎｄｌｅｒとして特定される部分を呼び出すための追加、削除、検索作業のために、同様のＡＰＩファンクションコールを開始できる。これらのコールバックを入れることで、エージェントは、特定の要求を受け取ったときに、開発者のエージェントプログラムのうちどの部分を呼び出すかがわかる。変更要求等の要求を受け取ると、適当なコールバック（この例ではｍｙ＿ｍｏｄｉｆｙ＿ｈａｎｄｌｅｒ）が呼び出される。
【０２４３】
このコールバックは次のように現れる。
Ｍｙ＿ｍｏｄｉｆｙ＿ｈａｎｄｌｅｒ（ＰＤＵ） （１）
Ｅｎｔｒｙ＝ｅｒｍａ＿ｇｅｔ＿ｅｎｔｒｙ（ｐｄｕ） （２）
Ｔｙｐｅ＿ｏｆ＿ｒｅｑｕｅｓｔ＝ｅｒｍａ＿ｇｅｔ＿ｅｎｔｒｙ＿ｔｙｐｅ（ｅｎ ｔｙ） （３）
Ｕｓｅｒｎａｍｅ＝ｅｒｍａ＿ｇｅｔ＿ｅｎｔｒｙ＿ｎａｍｅ（ｅｎｔｒｙ）（４）
Ｆｏｒ ａｌｌ ａｔｔｒｉｂｕｔｅｓ ｉｎ ｅｎｔｒｙ， （５）
Ａｔｔｒｉｂｕｔｅ＝ｅｒｍａ＿ｇｅｔ＿ｅｎｔｒｙ（ｅｎｔｒｙ）（６）
Ｐｒｏｃｅｓｓ＿ａｔｔｒｉｂｕｔｅｓ（ａｔｔｒｉｂｕｔｅ） （７）
【０２４４】
この例において、１行目では、エージェントがＰＤＵをｍｙ＿ｍｏｄｉｆｙ＿ｈａｎｄｌｅｒに渡す。２行目で、エントリがＰＤＵから読み出される。３行目で、要求のタイプがエントリから読み出される。４行目で、ユーザ名がエントリから読み出される。５行目はループを表し、ループの中で、（６行目）特定のエントリの中の各属性が読み出され、７行目で、機能ｐｒｏｃｅｓｓ＿ａｔｔｒｉｂｕｔｅを呼び出すことによって各属性が処理される。この処理ステップの中で、たとえば追加、削除、変更、検索等の具体的作業を実行するために、各種のＡＰＩが呼び出される。
【０２４５】
エージェント開発者用キット
上記のように、ソフトウェアモジュールと機能のライブラリを使い、開発者は、各種のソフトウェアモジュールを呼び出し、ＲＰＭシステムに特定の管理されたリソースへのアクセスを管理させるエージェントプログラムを書くことができる。しかしながら、エージェントプログラムを書く作業は、何もない状態では行われない。ソフトウェアライブラリに加え、開発者には、エージェント開発プロセス全体に役立つその他の資材が提供される。これらのライブラリと資材がエージェント開発者用キット（ＡＤＫ）である。たとえば、開発者には、開発の各ステップで通常生成される文書の作成を容易にする各種のテンプレートが提供される。利用できるテンプレートには、たとえば、Ｍａｒｋｅｔｉｎｇ Ｒｅｑｕｉｒｅｍｅｎｔｓ Ｄｏｃｕｍｅｎｔ（ＭＲＤ）、エージェントの設計の元になる機能仕様書、エージェントがコード化または開発されるもとになるエージェント設計仕様書がある。さらに、ＡＤＫには、エージェント開発者の環境にＡＤＫをロードするためのキットインストーラ、指定された機能性とインタフェース標準に照らしてエージェントを検証するのに使用されるテストケースのスイート、ラボ環境へのアクセスを得るための方法、ドライバまたはその他、試験または検証方法とツールが含まれる。そのほか、文書類とトレーニング用資料一式もＡＤＫに含まれる。これらは、ハードコピーでも、オンラインで利用できるように実現されていてもよい。文書類には、たとえば、ＡＤＫの概要とエージェント開発プロセス、システムコンテクスト、インタフェースの説明（プロトコル、メッセージ、セキュリティその他）、たとえば使用、コール、可変値その他を含むＡＰＩに関する説明、コメント付コードリスト等のインプリメンテーションサンプル、および、提案、よく聞かれる質問、事例を含むその他の知識ベースの材料等が含まれる。さらに、ＡＤＫには、一定品質での効率的なエージェント開発を助けるプロセスと標準も含まれる。
【０２４６】
これらのプロセスは、たとえば、契約上の要求事項、文書に関する要求事項、コード化水準、メトリクス、認証要件、その他、エージェントの効率的開発のために必要とみなされるその他のプロセスと標準を含む。したがって、本発明の実施形態は、特定の機能を実行するための標準化されたソフトウェアモジュールセットを使用して、管理されたリソースにアクセスするためのエージェントをモジュール形式で開発するシステム、デバイス、方法であって、ソフトウェアモジュールセットは、すべてのエージェントに共通する機能を考慮して開発されているシステム、デバイス、方法を提供する。本発明の実施形態はまた、プロトコルに無関係なエージェントの開発を可能にし、ソフトウェアモジュールのプレファプリケーションにより、開発者がより早く、より効率的に作業を行うことができるようにし、開発者が他の開発者のエージェントソフトウェアと作業を共有し、これを理解し、あるいはデバッギングし、あるいは他の開発者のエージェントの開発を引き継ぐことを可能にする。本発明は、好ましい実施形態を参照しながら説明したが、上記の説明から、当業者は機器、動作条件、構成に、添付の特許請求範囲でのみ限定される本発明の精神と範囲から逸脱することなく、さまざまな変更を加えることが可能であると理解できる。
【図面の簡単な説明】
【０２４７】
【図１】本発明のアプリケーションサービスプロバイダ（ＡＳＰ）の外観を示す略図である。
【図２】本発明の法人企業環境の実施形態の外観を示す略図である。
【図３】本発明の実施形態によるシステムの論理アーキテクチャを示す略図である。
【図４】本発明の実施形態によるシステムのコンポーネント配置を示す略図である。
【図５】本発明の実施形態によるシステムの配置例を示す略図である。
【図６】本発明の実施形態によるシステムの別の配置例を示す略図である。
【図７Ａ】ユーザの認証、ユーザの追加、サービスのためのサービス共有、方針に基づく新規ユーザのためのサービス共有、サービスの同期、方針違反の強制に関する相互作用のシーケンスを示す図である。
【図７Ｂ】ユーザの認証、ユーザの追加、サービスのためのサービス共有、方針に基づく新規ユーザのためのサービス共有、サービスの同期、方針違反の強制に関する相互作用のシーケンスを示す図である。
【図７Ｃ】ユーザの認証、ユーザの追加、サービスのためのサービス共有、方針に基づく新規ユーザのためのサービス共有、サービスの同期、方針違反の強制に関する相互作用のシーケンスを示す図である。
【図７Ｄ】ユーザの認証、ユーザの追加、サービスのためのサービス共有、方針に基づく新規ユーザのためのサービス共有、サービスの同期、方針違反の強制に関する相互作用のシーケンスを示す図である。
【図７Ｅ】ユーザの認証、ユーザの追加、サービスのためのサービス共有、方針に基づく新規ユーザのためのサービス共有、サービスの同期、方針違反の強制に関する相互作用のシーケンスを示す図である。
【図８】共有プロセスに関するシーケンスにおけるグラフィカルインタフェースを示す図である。
【図９】本発明の実施形態によるリソース共有管理システムの一般的アーキテクチャを示す略図である。
【図１０】本発明の実施形態による中央集中化されたサーバを利用したリソース共有管理システムの略図である。
【図１１Ａ】本発明の実施形態による中央集中化されたサーバを利用したリソース共有管理のフロー図である。
【図１１Ｂ】本発明の実施形態による中央集中化されたサーバを利用したリソース共有管理の別のフロー図である。
【図１２】本発明の実施形態による中央集中化されたサーバと外部リソースを利用したリソース共有管理システムの略図である。
【図１３】本発明の実施形態によるリソース交換機能における関連リソースの相互割当を提供する中央集中化されたサーバを利用したリソース共有管理システムの略図である。
【図１４Ａ】本発明の実施形態によるリソース交換機能における関連リソースの相互割当を提供する中央集中化されたサーバを利用したリソース共有管理方法のフロー図である。
【図１４Ｂ】本発明の実施形態によるリソース交換機能における関連リソースの相互割当を提供する中央集中化されたサーバを利用したリソース共有管理方法のフロー図である。
【図１５】本発明の実施形態による公共共有インフラストラクチャを提供する中央集中化されたサーバを利用したリソース共有管理システムの略図である。
【図１６】本発明の実施形態による公共共有インフラストラクチャを提供する中央集中化されたサーバを利用したリソース共有管理方法のフロー図である。
【図１７】本発明の実施形態による中央集中化されたサーバを利用したリソース共有管理システムの各種レベルの略図である。
【図１８】先行技術のワイドエリアネットワーク環境の略図である。
【図１９】本発明の実施形態によるリソース共有システム環境の略図である。
【図２０】本発明の別の実施形態によるリソース共有管理システム環境の略図である。
【図２１】本発明の実施形態による利用状況を管理するための一般化された方法のフロー図である。
【図２２】本発明の実施形態による利用状況を管理するための方法のフロー図である。
【図２３】本発明の実施形態における利用方針に応じてアカウント利用状況を照合確認するためのシステムのブロック図である。
【図２４】アイデンティティ方針に応じてユーザアイデンティティを生成する方法のフロー図である。
【図２５】アイデンティティ方針に応じて複数のリソースにわたりユーザアイデンティティを生成する方法のフロー図である。
【図２６】本発明の実施形態におけるアイデンティティ方針に応じてユーザアイデンティティを生成するためのフロー図である。
【図２７】エージェントを介してＲＰＭシステムにおけるユーザアイデンティティを付与するためのシステムのブロック図である。
【図２８】パスワード方針に適合するパスワードを確立するための方法のフロー図である。
【図２９】ユーザがシステムに入る前に、パスワード方針に適合するパスワードを自動的に生成、確立する方法のフロー図である。
【図３０】キーボードシーケンスに基づいてパスワードを詳細に示すコンピュータキーボードの図である。
【図３１】各種のリソースパスワードルールセットを結合してひとつのパスワード方針にするシステムの略図である。
【図３２】過剰に限定的なルールセットを決定する方法のフロー図である。
【図３３】エージェントを介してＲＰＭシステムにおけるパスワードを確立するためのシステムのブロック図である。
【図３４】本発明の実施形態による、リソース共有管理システムと管理されたリソースの間の変換手段として機能するエージェントのブロック図である。
【図３５】本発明の実施形態による、リソース共有管理システムと管理されたリソースの間の変換手段として機能するエージェントの、より詳細なブロック図である。
【図３６】本発明の実施形態による、サポートされている各オペレーティングシステムについての別のプロトコルプラグインライブラリとＥＲＭＡライブラリを有するエージェントを示すブロック図である。

Claims (111)

  1. ユーザに対してリソースの共有を行う方法であって、
    一連の属性、組織情報、ユーザの役割を確立するステップと、
    選択された属性、組織情報、ユーザの役割に基づいて複数のリソース共有方針を定義するステップと、
    特定のユーザ、リソースまたはデータベースに関する属性情報、組織情報、ユーザの役割情報を受け取るステップと、
    前記受け取ったユーザの役割情報、組織情報、属性情報に基づいて、前記ユーザにはどのリソース共有情報が適用可能かを判断するステップと、
    前記適用可能なリソース共有方針に基づいて、前記ユーザに対してリソースの共有を行うステップと、
    を含むことを特徴とする方法。
  2. 請求項１に記載の方法であって、
    前記ユーザの役割は、「はい」と「いいえ」の値を持ち、前記属性は複数の非バイナリ値であることを特徴とする方法。
  3. 請求項２に記載の方法であって、
    さらに、現在前記ユーザに割り当てられているリソースを、前記適用可能なリソースアクセス方針に基づいて前記ユーザに割り当てられるはずのリソースのリストと比較し、相違を特定することにより、リソースの照合確認を行うステップを含むことを特徴とする方法。
  4. 請求項３に記載の方法であって、
    さらに、照合確認によって検出された前記相違に基づいて、前記ユーザへのリソースの共有または共有解除を行うステップを含むことを特徴とする方法。
  5. 請求項２に記載の方法であって、
    さらに、前記ユーザが退職、休職した、または休暇をとった場合に、前記ユーザが割り当てを受けていたリソースの一部または全部について、前記ユーザの共有解除を行うステップを含むことを特徴とする方法。
  6. 請求項２に記載の方法であって、
    さらに、共有のタイミングまたはリソースに関するタイミング情報を受け取るステップと、
    前記タイミング情報によって指定された特定のタイミングで前記ユーザにリソースの共有を行うステップと、
    を含むことを特徴とする方法。
  7. 請求項２に記載の方法であって、
    前記属性はユーザ属性とリソース属性であることを特徴とする方法。
  8. 請求項２に記載の方法であって、
    さらに、前記ユーザに対し、「ハード」のリソースと「ソフト」のリソースの共有を行うステップを含むことを特徴とする方法。
  9. 請求項２に記載の方法であって、
    さらに、前記ユーザに対し、いくつかのリソースのまとまり（バンドル）の共有を行うステップを含むことを特徴とする方法。
  10. 請求項２に記載の方法であって、
    さらに、決定ステートメントを利用して複数のリソース共有方針を定義するステップを含み、これによって無関係なステップを省略することができることを特徴とする方法。
  11. 請求項２に記載の方法であって、
    前記ユーザにリソースの共有を行うステップは、前記リソースの要求をアプリケーションまたは人物に通信するステップを含むことを特徴とする方法。
  12. 請求項１に記載の方法であって、
    さらに、リソースの利用状況に基づいて前記ユーザに対するリソースの共有または共有解除を行うステップを含むことを特徴とする方法。
  13. 請求項１に記載の方法であって、
    さらに、アイデンティティ方針を使って前記ユーザに対するリソースの共有または共有解除を行うステップを含むことを特徴とする方法。
  14. 請求項１に記載の方法であって、
    さらに、パスワード方針を使って前記ユーザに対するリソースの共有または共有解除を行うステップを含むことを特徴とする方法。
  15. ユーザに対するリソースの共有を行うシステムであって、
    一連の属性、組織情報、ユーザの役割、選択された属性、組織情報、ユーザの役割に基づく複数のリソース共有方針、特定のユーザまたはリソースに関する属性情報とユーザの役割情報を記憶するメモリと、
    前記メモリと組織ネットワークに連結されたひとつまたは複数のプロセッサと、
    を備え、
    前記プロセッサは、
    前記記憶されたユーザの役割情報、組織情報、属性情報に基づいて、特定のユーザにどのリソース共有方針が適用可能かを判断し、前記適用可能なリソース共有方針に基づいて、ユーザに対するリソース共有を行うようプログラムされていることを特徴とするシステム。
  16. 請求項１５に記載のシステムであって、
    前記ユーザの役割は「はい」と「いいえ」の値を有し、前記属性は複数の非バイナリ値であることを特徴とするシステム。
  17. 請求項１６に記載のシステムであって、
    前記ひとつまたは複数のプロセッサはさらに、前記ユーザに現在共有されているリソースと、前記適用可能なリソース共有方針に基づいて前記ユーザに割り当てられるはずのリソースリストとを比較し、相違を特定することによってリソースの照合確認を行うようプログラムされていることを特徴とするシステム。
  18. 請求項１７に記載のシステムであって、
    前記ひとつまたは複数のプロセッサはさらに、照合確認によって検出された相違に基づいて、前記ユーザに対するリソースの共有と共有解除を行うようプログラムされていることを特徴とするシステム。
  19. 請求項１６に記載のシステムであって、
    前記ひとつまたは複数のプロセッサはさらに、前記ユーザが退職、停職した、または休暇に入った場合に、前記ユーザに割り当てられているリソースの一部または全部について、前記ユーザへの共有解除を行うようプログラムされていることを特徴とするシステム。
  20. 請求項１６に記載のシステムであって、
    前記ひとつまたは複数のプロセッサはさらに、
    共有のタイミングまたはリソースに関するタイミング情報を受け取り、前記タイミング情報により指定された特定のタイミングで前記ユーザへのリソースの共有を行うようプログラムされていることを特徴とするシステム。
  21. 請求項１６に記載のシステムであって、
    前記属性はユーザ属性とリソース属性であることを特徴とするシステム。
  22. 請求項１６に記載のシステムであって、
    前記ユーザには「ハード」のリソースと「ソフト」のリソースの共有が行われることを特徴とするシステム。
  23. 請求項１６に記載のシステムであって、
    前記ユーザにはいくつかのリソースのバンドルの共有が行われることを特徴とするシステム。
  24. 請求項１６に記載のシステムであって、
    決定ステートメントを利用して複数のリソース共有方針を立て、これによって無関係なステップが省略されることを特徴とするシステム。
  25. ユーザに対するリソース共有のための方法であって、
    一連の属性、組織情報、ユーザの役割を確立するステップと、
    選択された属性、組織情報、ユーザの役割に基づいて複数のリソース共有方針を定義するステップと、
    特定のユーザ、リソースまたはデータベースに関する属性情報、組織情報およびユーザの役割情報を受け取るステップと、
    前記受け取ったユーザの役割情報、組織情報、属性情報に基づいて、どのリソース共有方針が前記ユーザに適用可能かを決定するステップと、
    適用可能なリソース共有方針に従って、第三者にその他の情報または許可を求めるステップと、
    すべての必要な追加情報または許可が前記第三者から受け取られた場合、前記適用可能なリソース共有方針によって指定されたリソースの前記ユーザへの共有を行うステップと
    を含むことを特徴とする方法。
  26. 請求項２５に記載の方法であって、
    属性情報、組織情報、ユーザの役割情報を受け取る前記ステップは、ユーザインタフェースからの入力を受け取るステップであることを特徴とする方法。
  27. 請求項２５に記載の方法であって、
    特定のユーザに関する属性情報、組織情報、ユーザの役割情報を受け取る前記ステップは、社員記録データベースから属性情報とユーザの役割情報を受け取るステップであることを特徴とする方法。
  28. 請求項２６に記載の方法であって、
    第三者に追加情報または許可を求める前記ステップは、
    前記第三者に前記ユーザインタフェースへのアクセスを提供するステップと、
    前記第三者に対し、どの情報または許可が必要かを示すステップと、
    前記追加情報または許可が提供されるまで、前記ユーザに対するリソースの共有を停止するステップと、
    を含むことを特徴とする方法。
  29. 請求項２５に記載の方法であって、
    前記第三者に追加情報または許可を求める前記ステップは、
    前記適用可能なリソース共有方針に従って、第三者から第一の追加情報または許可を受け取るステップと、
    受け取った第一の追加情報または許可と受け取った属性情報、組織情報、ユーザの役割情報に基づいて、他の第三者または前記ユーザに第二の追加情報または許可を求めるステップと、
    を含むことを特徴とする方法。
  30. ユーザに対してリソースの共有を行うためのシステムであって、
    一連の属性、組織情報、ユーザの役割、選択された属性、組織情報、ユーザの役割に基く複数のリソース共有方針、特定のユーザまたはリソースに関する属性情報およびユーザの役割情報を記憶するデータサーバと、
    前記メモリと組織ネットワークに連結されたひとつまたは複数のプロセッサと、
    を備え、
    前記プロセッサは、
    前記記憶されたユーザの役割情報、組織情報、属性情報にどのリソース共有方針が適用可能かを判断し、前記適用可能なリソース共有方針に従って、第三者に追加情報または許可を求め、すべての必要な追加情報または許可を前記第三者から受け取ったところで、前記適用可能なリソース共有方針によって指定された前記リソースのユーザへの共有を行うようプログラムされていることを特徴とするシステム。
  31. 請求項３０に記載のシステムであって、
    さらに、特定のユーザまたはリソースに関する前記属性情報およびユーザの役割情報を入力するためのユーザインタフェースを備えることを特徴とするシステム。
  32. 請求項３０に記載のシステムであって、
    前記データサーバはさらに、特定のユーザに関する属性情報とユーザの役割情報を記憶するための社員記録データベースを備えることを特徴とするシステム。
  33. 請求項３１に記載のシステムであって、
    前記プロセッサはさらに、前記第三者に前記ユーザインタフェースへのアクセスを提供し、前記第三者に対し、どの情報または許可が必要かを示し、前記追加情報または許可が提供されるまで、前記ユーザに対するリソースの共有を停止するようプログラムされていることを特徴とするシステム。
  34. 請求項３０に記載のシステムであって、
    前記プロセッサはさらに、前記適用可能なリソース共有方針に従って、第三者から第一の追加情報または許可を受け取り、受け取った第一の追加情報または許可と受け取った属性情報、組織情報、ユーザの役割情報に基づいて、他の第三者または前記ユーザに第二の追加情報または許可を求めるようプログラムされていることを特徴とするシステム。
  35. サーバを使用して複数の組織に対するリソース共有を行う方法であって、各組織は内部リソースを有し、
    各組織に関する一連の属性、組織情報、ユーザの役割を確立するステップと、
    選択された属性、組織情報、ユーザの役割に基づいて各組織のための複数のリソース共有方針を定義するステップと、
    特定のユーザまたはリソースに関する属性情報、組織情報、ユーザの役割情報を各組織から受け取るステップと、
    前記受け取ったユーザの役割情報、組織情報、属性情報に基づいて、ユーザにはどのリソース共有方針が適用可能かを判断するステップと、
    前記適用可能なリソースアクセス共有方針に基づいて、中央集中化された遠隔ロケーションから前記ユーザへのリソース共有を行うステップと、
    を含むことを特徴とする方法。
  36. 請求項３５に記載の方法であって、
    前記共有を行うステップは、ネットワーク上で行われることを特徴とする方法。
  37. 請求項３５に記載の方法であって、
    さらに、ユーザに外部リソースの共有を行うステップを含むことを特徴とする方法。
  38. 請求項３５に記載の方法であって、
    前記受け取るステップにおいて、前記属性情報、組織情報、ユーザの役割情報は自動的に受け取られることを特徴とする方法。
  39. 請求項３５に記載の方法であって、
    複数のリソースの共有が平行して行われることを特徴とする方法。
  40. サーバを使用して複数の組織に対するリソース共有を行う方法であって、各組織は内部リソースを有し、
    各組織に関する一連の属性、組織情報、ユーザの役割を確立するステップと、
    選択された属性、組織情報、ユーザの役割に基づいて各組織のための複数のリソース共有方針を定義するステップと、
    特定のユーザまたはリソースに関する属性情報、組織情報、ユーザの役割情報を各組織から受け取るステップと、
    前記受け取ったユーザの役割情報、組織情報、属性情報に基づいて、ユーザにはどのリソース共有方針が適用可能かを判断するステップと、
    組織をリソース取引所（エクスチェンジ:exchange）に分類するステップと、
    前記適用可能なリソースアクセス共有方針に基いて、前記リソース取引所内で、中央集中化された遠隔ロケーションからユーザへの相互リソース共有を行うステップと、
    を含むことを特徴とする方法。
  41. 請求項４０に記載の方法であって、
    さらに、前記リソース取引所内の組織の変換マップを提供するステップを含むことを特徴とする方法。
  42. 請求項４０に記載の方法であって、
    さらに、前記リソース取引所内の組織の高レベル認証を提供するステップを含むことを特徴とする方法。
  43. 請求項４０に記載の方法であって、
    さらに、前記リソース取引所内の組織のアイデンティティ同期を行うステップを含むことを特徴とする方法。
  44. 請求項４０に記載の方法であって、
    さらに、前記リソース取引所内でリソース登録を行うステップを含むことを特徴とする方法。
  45. 請求項４０に記載の方法であって、
    さらに、前記リソース取引所内で組織に関するオーディットトレールを提供するステップを含むことを特徴とする方法。
  46. 請求項４０に記載の方法であって、
    さらに、前記リソース取引所内で組織のための匿名性を提供するステップを含むことを特徴とする方法。
  47. 請求項４０に記載の方法であって、
    複数のリソースの共有が平行して行われることを特徴とする方法。
  48. 請求項４０に記載の方法であって、
    前記受け取るステップにおいて、属性情報、組織情報、ユーザの役割情報は自動的に受け取られることを特徴とする方法。
  49. 公共共有インフラストラクチャにおいてサーバを使って複数の組織へのリソース共有を行う方法であって、
    それぞれリソースを有する各組織についての一連の属性、組織情報、ユーザの役割を確立するステップと、
    選択された属性、組織情報、ユーザの役割に基づいて、リソースを有する各組織のための複数のリソースアクセス共有方針を定義するステップと、
    特定のユーザまたはリソースまたはデータベースについて、各組織から属性情報、組織情報、ユーザの役割情報を受け取るステップと、
    前記公共共有インフラストラクチャ内のリソースを使用したいと希望する一般民衆のメンバーから、属性情報、組織情報、ユーザの役割情報を受け取るステップと、
    前記一般民衆のメンバーのためのリソース共有チケットを生成するステップと、
    前記受け取ったユーザの役割情報、組織情報、属性情報に基づいて、ユーザに対してどのリソース共有方針が適用可能かを判断するステップと、
    前記共有チケットを特定のリソースのベンダに送るステップと、
    を含むことを特徴とする方法。
  50. 複数の組織のリソース共有を行うシステムであって、
    第三者リソース共有管理サービスプロバイダと、
    リソース共有のためのサーバと、前記サーバは前記第三者リソース共有管理サービスプロバイダによって運営され、
    各組織に属する内部リソースと、
    前記サーバと前記内部リソースの連結を提供するネットワークと、
    を備えることを特徴とするシステム。
  51. 請求項５０に記載のシステムであって、
    前記第三者リソース共有管理サービスプロバイダは、前記組織の要求に応じて、前記ネットヨーク上で各組織の前記内部リソースの共有を行うことを特徴とするシステム。
  52. 請求項５０に記載のシステムであって、
    前記第三者リソース共有管理サービスプロバイダは、前記ネットワーク上で各組織の前記内部リソースの共有を自動的に行うことを特徴とするシステム。
  53. 請求項５０に記載のシステムであって、
    さらに外部リソースを有し、前記外部リソースは各組織のために共有されることを特徴とするシステム。
  54. 複数の組織にリソース共有を行うシステムであって、
    第三者リソース共有管理サービスプロバイダと、
    リソース共有を行う論理サーバと、前記サーバは前記第三者リソース共有管理サービスプロバイダによって運営され、
    前記複数の組織のために作られたリソース取引所と、
    各組織は内部リソースを有し、
    前記サーバと前記内部リソースの間の連結を提供するネットワークと、
    を備えることを特徴とするシステム。
  55. 請求項５４に記載のシステムであって、
    前記第三者リソース共有管理サービスプロバイダは、各組織の要求に応じて、前記ネットワーク上で前記リソース取引所内において各組織の前記社内リソースの相互共有を行うことを特徴とするシステム。
  56. 請求項５４に記載のシステムであって、
    前記第三者リソース共有管理サービスプロバイダは、前記リソース取引所内の各組織の内部リソースの相互共有を自動的に行うことを特徴とするシステム。
  57. 請求項５４に記載のシステムであって、
    さらに、前記リソース取引所内の組織のための変換マップを備えることを特徴とするシステム。
  58. 請求項５４に記載のシステムであって、
    さらに、前記リソース取引所内の各組織の高レベル認証を行うための手段を備えることを特徴とするシステム。
  59. 請求項５４に記載のシステムであって、
    さらに、前記リソース取引所内の組織のアイデンティティ同期を行うための手段を備えることを特徴とするシステム。
  60. 請求項５４に記載のシステムであって、
    さらに、前記リソース取引所内のリソース登録を行うステップを含むことを特徴とするシステム。
  61. 請求項５４に記載のシステムであって、
    さらに、前記リソース取引所内の組織のためのオーディットトレールを提供する手段を備えることを特徴とするシステム。
  62. 請求項５４に記載のシステムであって、
    複数のリソースの共有が平行して行われることを特徴とするシステム。
  63. 複数の組織のリソース共有を行うシステムであって、
    それぞれリソースを有する各組織についての一連の属性、組織情報、ユーザの役割を確立する手段と、
    選択された属性、組織情報、ユーザの役割に基づいて、リソースを有する各組織のための複数のリソースアクセス共有方針を定義する手段と、
    特定のユーザまたはリソースまたはデータベースについて、各組織から属性情報、組織情報、ユーザの役割情報を受け取る手段と、
    公共共有インフラストラクチャ内のリソースを使用したいと希望する一般民衆のメンバーから、属性情報、組織情報、ユーザの役割情報を受け取る手段と、
    前記一般民衆のメンバーのためのリソース共有チケットを生成する手段と、
    前記受け取ったユーザの役割情報、組織情報、属性情報に基づいて、ユーザに対してどのリソース共有方針が適用可能かを判断する手段と、
    前記共有チケットを特定のリソースのベンダに送る手段と、
    を備えることを特徴とするシステム。
  64. リソース共有管理（ＲＰＭ）システムであって、
    所定のワークフロー定義、役割、方針に基づいて、ユーザへのリソースを管理するようプログラムされたプロセッサシステムを備え、ユーザは、前記方針が前記ワークフロー定義の少なくともひとつを追加、削除または変更する権利を与える少なくともひとつの管理者としての役割を含め、前記方針が特定のリソースに関連付ける特定の役割を有し、前記プロセッサシステムは、ワイドエリアネットワーク（ＷＡＮ）上で通信するよう接続され、さらに、前記プロセッサシステムとは離れたＷＡＮサイトにおいて、少なくとも一人の管理者からＷＡＮ上で指示を受け、前記ワークフロー定義の少なくともひとつを追加、削除または変更するよう受け取った指示に従うようにプログラムされていることを特徴とするＲＰＭシステム。
  65. 請求項６４に記載のＲＰＭシステムであって、
    前記ワークフロー定義は、第一のワークフロー定義セットと第二のワークフロー定義セットでなり、各セットは少なくともひとつのワークフロー定義を有し、前記第一のワークフロー定義セットは前記第二のワークフロー定義セットとは異なり、前記少なくともひとつの管理者としての役割は第一の管理者の役割と第二の管理者の役割でなり、前記プロセッサシステムは、前記第一の管理者の役割を有するユーザに対し、前記第一のワークフロー定義セットの中のワークフロー定義だけを追加、削除または変更することを認め、前記第二の管理者としての役割を有するユーザに対しては、前記第二のワークフロー定義セットの中のワークフロー定義だけを追加、削除または変更することを認めるようプログラムされていることを特徴とするＲＰＭシステム。
  66. 請求項６５に記載のＲＰＭシステムであって、
    前記第一のワークフロー定義セットは複数のワークフロー定義を含み、前記第二のワークフロー定義セットの少なくともひとつのワークフロー定義は、前記第一のワークフロー定義セットにも含まれていることを特徴とするＲＰＭシステム。
  67. 請求項６４に記載のＲＰＭシステムであって、
    前記プロセッサシステムは、ＷＡＮ上のＨＴＴＰ接続によって指示を受けるようプログラムされていることを特徴とするＲＰＭシステム。
  68. 請求項６４に記載のシステムであって、
    前記プロセッサシステムは、ＷＡＮ上の安全なＨＴＴＰＳ接続によって指示を受けるようプログラムされていることを特徴とするＲＰＭシステム。
  69. 請求項６４に記載のシステムであって、
    前記ＷＡＮはインターネットであることを特徴とするシステム。
  70. ワイドエリアネットワーク上のリソース管理システムを管理するためのシステムであって、
    ファイアウォールを介してＷＡＮに接続されたリソース共有管理（ＲＰＭ）システムと、所定のワークフロー定義に基づいて、ユーザへのリソースを管理するようプログラムされたリソース割当システムと、管理者としての役割を有する少なくとも一人のユーザが操作するための、ＷＡＮ上で通信を行うために接続され、ＷＡＮ上で、ファイアウォールを介して前記リソース共有管理システムに指示を伝え、管理者としての役割を有する少なくとも一人のユーザがワークロー定義を追加、削除または変更できるようにする少なくとも１台のコンピュータと、
    を備えることを特徴とするシステム。
  71. 請求項７０に記載のシステムであって、
    前記ワークフロー定義は第一のワークフロー定義セットと第二のワークフロー定義セットでなり、各セットは少なくともひとつのワークフロー定義を含み、前記第一のワークフロー定義セットは前記第二のワークフロー定義セットとは異なり、前記管理者としての役割を有する少なくともひとりのユーザは第一の管理者としての役割を有するユーザと第二の管理者としての役割を有するユーザであり、前記少なくとも１台のコンピュータは、前記第一の管理者としての役割を有するユーザが前記第一のワークフロー定義セットの中のワークフロー定義のみ追加、削除、変更し、前記第二の管理者としての役割を有するユーザが前記第二のワークフロー定義セットの中のワークフロー定義のみ追加、削除、変更するようプログラムされていることを特徴とするシステム。
  72. 請求項７１に記載のシステムであって、
    前記第一のワークフロー定義セットは複数のワークフロー定義を含み、前記第二のワークフロー定義セットの中の少なくともひとつのワークフロー定義は前記第一のワークフロー定義セットにも含まれることを特徴とするシステム。
  73. 請求項７０に記載のシステムであって、
    前記指示の通信は、ＷＡＮ上のＨＴＴＰ接続での通信であることを特徴とするシステム。
  74. 請求項７０に記載のシステムであって、
    前記指示の通信は、ＷＡＮ上の安全なＨＴＴＰＳ接続での通信であることを特徴とするシステム。
  75. 請求項７０に記載のシステムであって、
    前記ＷＡＮはインターネットであることを特徴とするシステム。
  76. ワイドエリアネットワーク上のリソース管理システムを管理するプロセスであって、
    リソース共有管理（ＲＰＭ）システムを、ファイアウォールを介してＷＡＮに接続するステップと、
    リソース割当システムを、所定のワークフロー定義に基づいてユーザへのリソースを管理するようプログラムするステップと、
    管理者としての役割を有する少なくとも一人のユーザが操作する少なくとも１台のコンピュータから、ワークフロー定義を追加、削除または変更するよう、ＷＡＮ上で前記ＲＰＭシステムに指示を伝えるステップと、
    ＷＡＮ上でＲＰＭに伝えられた、ワークフロー定義を追加、削除または変更する指示を実行するステップと、
    を含むことを特徴とするプロセス。
  77. 請求項７６に記載のプロセスであって、
    前記ワークフロー定義は第一のワークフロー定義セットと第二のワークフロー定義セットでなり、各セットは少なくともひとつのワークフロー定義を含み、前記第一のワークフロー定義セットは前記第二のワークフロー定義セットとは異なり、前記管理者としての役割を有する少なくともひとりのユーザは第一の管理者としての役割を有するユーザと第二の管理者としての役割を有するユーザであり、前記ＲＰＭシステムはさらに、前記第一の管理者としての役割を有するユーザが前記第一のワークフロー定義セットの中のワークフロー定義のみ追加、削除、変更し、前記第二の管理者としての役割を有するユーザが前記第二のワークフロー定義セットの中のワークフロー定義のみ追加、削除、変更するようプログラムされていることを特徴とするプロセス。
  78. 請求項７７に記載のシステムであって、
    前記第一のワークフロー定義セットは複数のワークフロー定義を含み、前記第二のワークフロー定義セットの少なくともひとつのワークフロー定義は、前記第一のワークフロー定義セットにも含まれていることを特徴とするシステム。
  79. 請求項７６に記載のシステムであって、
    前記指示の通信は、ＷＡＮ上のＨＴＴＰ接続による通信であることを特徴とするシステム。
  80. 請求項７６に記載のシステムであって、
    前記指示の通信は、ＷＡＮ上の安全なＨＴＴＰＳ接続による通信であることを特徴とするシステム。
  81. 請求項７６に記載のシステムであって、
    前記ＷＡＮはインターネットであることを特徴とするシステム。
  82. ワイドエリアネットワーク（ＷＡＮ）上でファイアウォールの背後にあるリソースエージェントによって管理されるリソースのユーザへの共有を行うためのリソース共有管理（ＲＰＭ）システムであって、
    前記ユーザへのリソース共有を管理するようプログラムされた少なくとも１つのプロセッサと、
    前記少なくともひとつのプロセッサはＷＡＮに接続され、前記少なくともひとつのプロセッサは、ＷＡＮ上で、ファイアウォールを介して前記リソースエージェントと通信し、前記リソースエージェントによって管理されるアカウントに関して、ＷＡＮ上でアカウント管理機能を提供するようプログラムされていることを特徴とするシステム。
  83. 請求項８２に記載のシステムであって、
    前記アカウント管理機能は、リソース用のアカウントを追加し、リソースにアクセスするためのアカウントを削除し、リソース用アカウントを変更することからなる少なくともひとつのグループであることを特徴とするシステム。
  84. 請求項８２に記載のシステムであって、
    前記少なくともひとつのプロセッサは、ＸＭＬで前記リソースエージェントと通信するようプログラムされていることを特徴とするシステム。
  85. 請求項８２に記載のシステムであって、
    前記少なくともひとつのプロセッサは、ＨＴＴＰで前記リソースエージェントと通信するようプログラムされていることを特徴とするシステム。
  86. 請求項８２に記載のシステムであって、
    前記少なくともひとつのプロセッサは、ＨＴＴＰトンネリングで前記リソースエージェントと通信するようプログラムされていることを特徴とするシステム。
  87. 請求項８２に記載のシステムであって、
    前記少なくともひとつのプロセッサは、ＨＴＴＰＳで前記リソースエージェントと通信するようプログラムされていることを特徴とするシステム。
  88. 請求項８２に記載のシステムであって、
    前記リソースはデータベースであることを特徴とするシステム。
  89. 請求項８２に記載のシステムであって、
    前記リソースは電子メールサービスであることを特徴とするシステム。
  90. インターネット上でリソース管理を行うシステムであって、
    インターネットに接続されたリソース共有システムと、
    前記リソース共有システムに関連して遠隔にあり、アカウントホルダによって利用されるリソースと、
    第一のファイアウォールを介してインターネットに接続され、リソースのためのアカウントを管理するリソースエージェントと、
    を備え、
    前記リソース共有システムは、
    インターネットに上で第一のファイアウォールを介してリソースエージェントと通信し、前記リソースエージェントが管理するアカウントに関して、インターネット上でアカウント管理機能を提供するようプログラムされた少なくともひとつのプロセッサを備えることを特徴とするシステム。
  91. 請求項９０に記載のシステムであって、
    前記アカウント管理機能は、リソース用のアカウントを追加し、リソースにアクセスするためのアカウントを削除し、リソース用アカウントを変更することからなる少なくともひとつのグループであることを特徴とするシステム。
  92. 請求項９０に記載のシステムであって、
    前記少なくともひとつのプロセッサは、ＸＭＬで前記リソースエージェントと通信するようプログラムされていることを特徴とするシステム。
  93. 請求項９０に記載のシステムであって、
    前記少なくともひとつのプロセッサは、ＨＴＴＰで前記リソースエージェントと通信するようプログラムされていることを特徴とするシステム。
  94. 請求項９０に記載のシステムであって、
    前記少なくともひとつのプロセッサは、ＨＴＴＰトンネリングで前記リソースエージェントと通信するようプログラムされていることを特徴とするシステム。
  95. 請求項９０に記載のシステムであって、
    前記少なくともひとつのプロセッサは、ＨＴＴＰＳで前記リソースエージェントと通信するようプログラムされていることを特徴とするシステム。
  96. 請求項９０に記載のシステムであって、
    前記リソースはデータベースであることを特徴とするシステム。
  97. 請求項９０に記載のシステムであって、
    前記リソースは電子メールサービスであることを特徴とするシステム。
  98. ワイドエリアネットワーク（ＷＡＮ）上でファイアウォールの背後のリソースエージェントによって管理されるリソースのユーザへの共有を行うプロセスであって、
    ＷＡＮに接続された少なくともひとつのプログラムされたプロセッサでユーザへのリソース共有を行うステップと、
    前記リソースエージェントによって管理されるアカウントに関する情報を、少なくともひとつのプログラムされたプロセッサから前記リソースエージェントに、ＷＡＮ上で前記ファイアウォールを介して通信するステップと、
    を含み、前記情報はアカウント管理機能であることを特徴とするプロセス。
  99. 請求項９８に記載のプロセスであって、
    前記アカウント管理機能は、アカウントの追加、アカウントの削除、アカウントの変更からなる少なくともひとつのグループであることを特徴とするプロセス。
  100. 請求項９８に記載のプロセスであって、
    前記情報を通信するステップは、ＨＴＴＰトンネルングで前記リソースエージェントと通信するステップであることを特徴とするプロセス。
  101. 請求項９８に記載のプロセスであって、
    前記情報を通信するステップは、ＨＴＴＰＳで前記リソースエージェントと通信するステップであることを特徴とするプロセス。
  102. 請求項９８に記載のプロセスであって、
    前記リソース共有を行うステップは、
    一連の属性とユーザの役割を確立するステップと、
    選択された属性とユーザの役割に基づいて複数のリソースアクセス方針を定義するステップと、
    特定のユーザまたはリソースに関する属性情報とユーザの役割情報を受け取るステップと、
    受け取ったユーザの約九割情報と属性情報に基づいて、前記ユーザにどのリソースアクセス方針が適用可能かを判断するステップと、
    前記適用可能なリソースアクセス方針にしたがって、第三者に追加情報または許可を求めるステップと、
    すべての必要な追加情報または許可が第三者から得られた場合、前記適用可能なリソースアクセス方針によって指定されるリソースのユーザへの共有を行うステップと、
    を含むことを特徴とするプロセス。
  103. 請求項１０２に記載のプロセスであって、
    前記追加情報または許可を第三者に求めるステップは、
    前記第三者にユーザインタフェースへのアクセスを提供するステップと、
    前記第三者に、どの情報または許可が必要かを示すステップと、
    追加情報または許可が提供されるまでプロセスを停止するステップと、
    を含むことを特徴とするプロセス。
  104. 請求項１０２に記載のプロセスであって、
    前記第三者に追加情報または許可を求めるステップは、
    前記適用可能なリソースアクセス方針に従って、第三者から第一の追加情報または許可を受け取るステップと、
    受け取った第一の追加情報または許可および受け取った属性情報とユーザの役割情報に基づいて、他の第三者または前記ユーザに第二の追加情報または許可を求めるステップと、
    を含むことを特徴とするプロセス。
  105. リソース共有管理システムにおけるモジュラーエージェント開発のためのシステムであって、
    機能を実行するソフトウェアモジュールのライブラリと、
    リソースのためのアプリケーションプログラミングインタフェースと、
    を備え、
    前記エージェントはリソース共有管理システムと前記リソースとの間で、前記ソフトウェアモジュールを使い、前記アプリケーションプログラミングインタフェースを通じて変換することを特徴とするシステム。
  106. 請求項１０５に記載のシステムであって、
    前記ソフトウェアモジュールのライブラリは、アカウント追加、アカウント削除、アカウント変更、アカウント停止、アカウント再開機能を含むことを特徴とするシステム。
  107. 請求項１０５に記載のシステムであって、
    前記ソフトウェアモジュールのライブラリは、アクティビティロギング機能を含むことを特徴とするシステム。
  108. 請求項１０５に記載のシステムであって、
    前記ソフトウェアモジュールのライブラリは、認証および許可機能を含むことを特徴とするシステム。
  109. 請求項１０５に記載のシステムであって、
    前記ソフトウェアモジュールのライブラリは、メッセージプロトコル決定機能を含むことを特徴とするシステム。
  110. 請求項１０５に記載のシステムであって、
    前記ソフトウェアモジュールのライブラリは、インターナショナリゼーション機能を含むことを特徴とするシステム。
  111. リソース共有管理システムにおけるモジュラーエージェント開発方法であって、
    リソースを管理するためのエージェントに共通する機能を特定するステップと、
    前記機能に基づいてソフトウェアモジュールのライブラリを開発するステップと、
    前記リソースのためのアプリケーションプログラミングインタフェースを提供するステップと、
    を含むことを特徴とする方法。
JP2002561749A 2001-01-29 2002-01-28 リソース共有システムと方法 Pending JP2005503596A (ja)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US09/772,486 US6985955B2 (en) 2001-01-29 2001-01-29 System and method for provisioning resources to users based on roles, organizational information, attributes and third-party information or authorizations
US09/774,265 US6947989B2 (en) 2001-01-29 2001-01-29 System and method for provisioning resources to users based on policies, roles, organizational information, and attributes
US26785301P 2001-02-09 2001-02-09
US26924201P 2001-02-15 2001-02-15
US26929601P 2001-02-15 2001-02-15
US26921701P 2001-02-15 2001-02-15
US27210801P 2001-02-28 2001-02-28
US27210901P 2001-02-28 2001-02-28
US09/800,098 US6871232B2 (en) 2001-03-06 2001-03-06 Method and system for third party resource provisioning management
PCT/US2002/002411 WO2002061653A2 (en) 2001-01-29 2002-01-28 System and method for resource provisioning

Publications (2)

Publication Number Publication Date
JP2005503596A true JP2005503596A (ja) 2005-02-03
JP2005503596A5 JP2005503596A5 (ja) 2009-03-26

Family

ID=27578762

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002561749A Pending JP2005503596A (ja) 2001-01-29 2002-01-28 リソース共有システムと方法

Country Status (3)

Country Link
EP (1) EP1364331A1 (ja)
JP (1) JP2005503596A (ja)
WO (1) WO2002061653A2 (ja)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006012117A (ja) * 2004-05-21 2006-01-12 Nec Corp アクセス制御システム、アクセス制御方法およびアクセス制御用プログラム
WO2006082732A1 (ja) * 2005-02-04 2006-08-10 Nec Corporation アクセス制御装置
JP2006253769A (ja) * 2005-03-08 2006-09-21 National Institute Of Advanced Industrial & Technology 情報処理システムおよび方法
JP2006344198A (ja) * 2005-06-10 2006-12-21 Microsoft Corp スクリプトを介してメンバシップの割当てを行うための方法およびシステム
JP2007004549A (ja) * 2005-06-24 2007-01-11 Nippon Telegr & Teleph Corp <Ntt> アクセス制御方法
JP2008525917A (ja) * 2004-12-29 2008-07-17 リーマン・ブラザーズ・インコーポレーテッド 企業全体にわたるポリシー管理のシステムおよび方法
JP2009508208A (ja) * 2005-09-09 2009-02-26 セールスフォース ドット コム インコーポレイティッド マルチテナントデータベース環境において、オンデマンドアプリケーションをエクスポートし、公表し、ブラウズし、インストールするためのシステムおよび方法
JP2009230279A (ja) * 2008-03-19 2009-10-08 Toshiba Corp 情報処理装置および情報処理プログラム
JP2012524951A (ja) * 2009-04-27 2012-10-18 ファーウェイ デバイス カンパニー リミテッド ホームネットワーク、ホームネットワーク間での装置情報共有方法、及びホームネットワークシステム
JP2013516719A (ja) * 2010-01-11 2013-05-13 マイクロソフト コーポレーション 複数のサービスインスタンスのシンジケーション
JP2014059886A (ja) * 2002-11-12 2014-04-03 E M D Millipore Corp 機器アクセス制御システム
JP2017219880A (ja) * 2016-06-02 2017-12-14 三菱電機株式会社 認可システム、アクセス制御方法およびアクセス制御プログラム
US20210320927A1 (en) * 2020-04-14 2021-10-14 Salesforce.Com, Inc. System mode override during flow execution
US20210367966A1 (en) * 2020-05-22 2021-11-25 AuthMind Inc. Systems and methods for network security

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7596523B2 (en) 2002-09-09 2009-09-29 Barra, Inc. Method and apparatus for network-based portfolio management and risk-analysis
US7761320B2 (en) * 2003-07-25 2010-07-20 Sap Aktiengesellschaft System and method for generating role templates based on skills lists using keyword extraction
US8539568B1 (en) 2007-10-03 2013-09-17 Courion Corporation Identity map creation
US8601562B2 (en) 2007-12-10 2013-12-03 Courion Corporation Policy enforcement using ESSO
WO2021044197A1 (en) * 2019-09-06 2021-03-11 Hitachi, Ltd. Blockchain for workflow
CN113723930A (zh) * 2021-09-07 2021-11-30 深圳市致尚信息技术有限公司 一种数据库状态机工作流系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000020378A (ja) * 1998-06-30 2000-01-21 Lion Corp データベースシステム、データ管理方法及びデータ管理用ソフトウェアを記録した記録媒体
JP2000020377A (ja) * 1998-06-30 2000-01-21 Lion Corp データベースシステム、データ管理方法及びデータ管理用ソフトウェアを記録した記録媒体
US6161139A (en) * 1998-07-10 2000-12-12 Encommerce, Inc. Administrative roles that govern access to administrative functions

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000020378A (ja) * 1998-06-30 2000-01-21 Lion Corp データベースシステム、データ管理方法及びデータ管理用ソフトウェアを記録した記録媒体
JP2000020377A (ja) * 1998-06-30 2000-01-21 Lion Corp データベースシステム、データ管理方法及びデータ管理用ソフトウェアを記録した記録媒体
US6161139A (en) * 1998-07-10 2000-12-12 Encommerce, Inc. Administrative roles that govern access to administrative functions
US6182142B1 (en) * 1998-07-10 2001-01-30 Encommerce, Inc. Distributed access management of information resources

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"アクセス制御の設計ポイント−イントラのセキュリティ問題を設計段階で解きほぐす", ネットワークコンピューティング, vol. 第１１巻，第３号, JPN6008001493, 1 March 1999 (1999-03-01), JP, pages 72 - 75, ISSN: 0001127053 *
佐々木 元也: "利便性と安全性を両立シングル・サインオンを目指す", 日経インターネットテクノロジー 第２０号 NIKKEI INTERNET TECHNOLOGY, JPN6008045104, 22 February 1999 (1999-02-22), JP, pages 90 - 95, ISSN: 0001127054 *
河井 保博: "ポリシー・ネットへのアプローチ：アクセス制御や帯域制御を容易に実現可能に", 日経インターネットテクノロジー 第２７号 NIKKEI INTERNET TECHNOLOGY, JPN6008045108, 22 September 1999 (1999-09-22), JP, pages 84 - 105, ISSN: 0001127055 *

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014059886A (ja) * 2002-11-12 2014-04-03 E M D Millipore Corp 機器アクセス制御システム
JP2006012117A (ja) * 2004-05-21 2006-01-12 Nec Corp アクセス制御システム、アクセス制御方法およびアクセス制御用プログラム
JP4706262B2 (ja) * 2004-05-21 2011-06-22 日本電気株式会社 アクセス制御システム、アクセス制御方法およびアクセス制御用プログラム
JP4652418B2 (ja) * 2004-12-29 2011-03-16 バークレイズ・キャピタル・インコーポレーテッド 企業全体にわたるポリシー管理のシステムおよび方法
JP2008525917A (ja) * 2004-12-29 2008-07-17 リーマン・ブラザーズ・インコーポレーテッド 企業全体にわたるポリシー管理のシステムおよび方法
JP2011048843A (ja) * 2004-12-29 2011-03-10 Barclays Capital Inc 企業全体にわたるポリシー管理のシステムおよび方法
US8099509B2 (en) 2005-02-04 2012-01-17 Nec Corporation Access control unit
WO2006082732A1 (ja) * 2005-02-04 2006-08-10 Nec Corporation アクセス制御装置
JP4788711B2 (ja) * 2005-02-04 2011-10-05 日本電気株式会社 ワークフロー実行システム、ワークフロー実行方法、及び、プログラム
JP2006253769A (ja) * 2005-03-08 2006-09-21 National Institute Of Advanced Industrial & Technology 情報処理システムおよび方法
JP2006344198A (ja) * 2005-06-10 2006-12-21 Microsoft Corp スクリプトを介してメンバシップの割当てを行うための方法およびシステム
JP4726581B2 (ja) * 2005-06-10 2011-07-20 マイクロソフト コーポレーション スクリプトを介してメンバシップの割当てを行うための方法およびシステム
JP2007004549A (ja) * 2005-06-24 2007-01-11 Nippon Telegr & Teleph Corp <Ntt> アクセス制御方法
US10235148B2 (en) 2005-09-09 2019-03-19 Salesforce.Com, Inc. Systems and methods for exporting, publishing, browsing and installing on-demand applications in a multi-tenant database environment
JP2009508208A (ja) * 2005-09-09 2009-02-26 セールスフォース ドット コム インコーポレイティッド マルチテナントデータベース環境において、オンデマンドアプリケーションをエクスポートし、公表し、ブラウズし、インストールするためのシステムおよび方法
JP2013061972A (ja) * 2005-09-09 2013-04-04 Salesforce.Com Inc マルチテナントデータベース環境において、オンデマンドアプリケーションをエクスポートし、公表し、ブラウズし、インストールするためのシステム及び方法
US11704102B2 (en) 2005-09-09 2023-07-18 Salesforce, Inc. Systems and methods for exporting, publishing, browsing and installing on-demand applications in a multi-tenant database environment
US8635232B2 (en) 2005-09-09 2014-01-21 Salesforce.Com, Inc. Systems and methods for exporting, publishing, browsing and installing on-demand applications in a multi-tenant database environment
US11314494B2 (en) 2005-09-09 2022-04-26 Salesforce.Com, Inc. Systems and methods for exporting, publishing, browsing and installing on-demand applications in a multi-tenant database environment
US9195687B2 (en) 2005-09-09 2015-11-24 Salesforce.Com, Inc. System, method and computer program product for validating one or more metadata objects
US9298750B2 (en) 2005-09-09 2016-03-29 Salesforce.Com, Inc. System, method and computer program product for validating one or more metadata objects
US10521211B2 (en) 2005-09-09 2019-12-31 Salesforce.Com, Inc. Systems and methods for exporting, publishing, browsing and installing on-demand applications in a multi-tenant database environment
US9378227B2 (en) 2005-09-09 2016-06-28 Salesforce.Com, Inc. Systems and methods for exporting, publishing, browsing and installing on-demand applications in a multi-tenant database environment
JP2009230279A (ja) * 2008-03-19 2009-10-08 Toshiba Corp 情報処理装置および情報処理プログラム
US9331863B2 (en) 2009-04-27 2016-05-03 Huawei Device Co., Ltd. Home network, method for sharing device information among home networks and home network system
JP2012524951A (ja) * 2009-04-27 2012-10-18 ファーウェイ デバイス カンパニー リミテッド ホームネットワーク、ホームネットワーク間での装置情報共有方法、及びホームネットワークシステム
JP2013516719A (ja) * 2010-01-11 2013-05-13 マイクロソフト コーポレーション 複数のサービスインスタンスのシンジケーション
JP2017219880A (ja) * 2016-06-02 2017-12-14 三菱電機株式会社 認可システム、アクセス制御方法およびアクセス制御プログラム
US20210320927A1 (en) * 2020-04-14 2021-10-14 Salesforce.Com, Inc. System mode override during flow execution
US11916918B2 (en) * 2020-04-14 2024-02-27 Salesforce, Inc. System mode override during flow execution
US20210367966A1 (en) * 2020-05-22 2021-11-25 AuthMind Inc. Systems and methods for network security
US11895144B2 (en) * 2020-05-22 2024-02-06 AuthMind Inc. Systems and methods for network security

Also Published As

Publication number Publication date
WO2002061653A9 (en) 2003-12-11
WO2002061653A8 (en) 2003-08-07
EP1364331A1 (en) 2003-11-26
WO2002061653A2 (en) 2002-08-08

Similar Documents

Publication Publication Date Title
US8069119B2 (en) System and method for software license management for concurrent license management and issuance
US6871232B2 (en) Method and system for third party resource provisioning management
JP2005503596A (ja) リソース共有システムと方法
US8332922B2 (en) Transferable restricted security tokens
US7761306B2 (en) icFoundation web site development software and icFoundation biztalk server 2000 integration
US8655712B2 (en) Identity management system and method
US20070033194A1 (en) System and method for actively managing service-oriented architecture
US20070233538A1 (en) Systems, methods, and apparatus to manage offshore software development
US20050060572A1 (en) System and method for managing access entitlements in a computing network
US20070233600A1 (en) Identity management maturity system and method
JP2009211728A (ja) データ及びリソースに対するアクセス制御を有するウェブベースセキュリティ
US20040073668A1 (en) Policy delegation for access control
EP1978464A1 (en) Federated role provisioning
US20070240223A1 (en) Systems, methods, and apparatus to manage offshore software development
JP2007004786A (ja) 顧客サポートシステム及び顧客サポート方法
Irvine et al. MYSEA security architecture
Müller Security Mechanisms for Workflows in Service-Oriented Architectures
Buecker et al. Identity management design guide with IBM Tivoli Identity Manager
Lowman et al. Applying the DoD Goal Security Architecture as a methodology for the development of system and enterprise security architectures
CN117195184A (zh) 一种统一管理权限的方法及系统
Ahukanna et al. IBM Business Process Manager Version 8.0 Production Topologies
Buecker et al. Integrating ibm security and sap solutions
Fitzgerald Security and data integrity for LANs and WANs
Krull Summary of papers to be presented at the Eleventh computer security group conference
Allen Information Systems Security in an Open Systems Environment

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050125

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050510

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20071219

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20071225

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080909

RD12 Notification of acceptance of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7432

Effective date: 20080922

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20080922

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20081208

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20090107

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20090120

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090128

A524 Written submission of copy of amendment under article 19 pct

Free format text: JAPANESE INTERMEDIATE CODE: A524

Effective date: 20090128

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090602

RD14 Notification of resignation of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7434

Effective date: 20090603

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20091104