第1のコンピューティングデバイスがリソース所有者を表し、第2のコンピューティングデバイスがリソース要求者を表す通信ネットワークにおいて、リソース所有者は、イベントの発生を検出し、イベント発生は、リソース所在地に格納されるリソース所有者の1つまたは複数のリソースにアクセスする要求を表し、リソース所有者は、イベント発生に応答して、リソース要求者に許可トークンを送信し、許可トークンは、リソース要求者が、リソース所在地に格納される1つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース要求者によりリソース所在地に提示されることになる、リソース所有者により委譲される許可の証明の働きをすることを含む、方法。イベント発生が、リソース要求者およびリソース所有者が、プル通信方法によって要求および応答を交換するような、リソース所有者によるリソース要求者からのリソース要求の受信である、請求項1に記載の方法。イベント発生が、リソース要求者とリソース所有者との間の通信方法が、プッシュ通信方法であるような、アプリケーションプログラムに関連するトリガイベントの発生である、請求項1に記載の方法。他のリソース要求者が、リソース所在地に格納される1つまたは複数の要求されるリソースにアクセスすることを認可するように、他のリソース要求者が、別の許可トークンをリソース所在地に提示し得るように、リソース所有者により委譲される許可の証明が、リソース要求者から少なくとも別のリソース要求者に譲渡可能である、請求項1に記載の方法。許可トークンを取得すること、ならびに、1つもしくは複数の要求されるリソースへのアクセスを得るための許可トークンの提示が、既存のアプリケーションプロトコルに結合される、請求項1に記載の方法。メモリと、メモリに結合され、請求項1に記載のステップを実施するように構成されるプロセッサとを備える、リソース所有者を表す第1のコンピューティングデバイスを実施するための、装置。第1のコンピューティングデバイスがリソース所有者を表し、第2のコンピューティングデバイスがリソース要求者を表し、リソース所有者が、イベントの発生を検出し、イベント発生が、リソース所在地に格納されるリソース所有者の1つまたは複数のリソースにアクセスする要求を表す通信ネットワークにおいて、リソース要求者は、イベント発生に応答して、リソース所有者により送信される許可トークンを受信し、許可トークンは、リソース要求者が、リソース所在地に格納される1つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース要求者によりリソース所在地に提示されることになる、リソース所有者により委譲される許可の証明の働きをすることを含む、方法。リソース所在地が、リソース要求者が許可トークンをリソース所在地に提示する前、および、リソース要求者が許可トークンをリソース所在地に提示した後の少なくとも1つで、リソース要求者を認証することをさらに含む、請求項7に記載の方法。リソース所在地が、1つまたは複数の要求されるリソースに関してアクションを行う前に、リソース要求者により提示される許可トークンを検証することをさらに含む、請求項7に記載の方法。第1のコンピューティングデバイスがリソース所有者を表し、第2のコンピューティングデバイスがリソース要求者を表し、リソース所有者が、イベントの発生を検出し、イベント発生が、リソース所在地に格納されるリソース所有者の1つまたは複数のリソースにアクセスする要求を表し、リソース要求者が、イベント発生に応答して、リソース所有者により送信される許可トークンを受信する通信ネットワークにおいて、リソース所在地は、許可トークンを受信し、許可トークンは、リソース要求者が、リソース所在地に格納される1つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース所有者によりリソース要求者に委譲される許可の証明の働きをすることを含む、方法。したがって、これらおよび他の欠点を克服する権限委譲に対する改善された手法が求められている。本発明の実施形態は、リソース所有者以外のエンティティによる保護されたリソースへのアクセスを伴う、例えば、ワールドワイドウェブ、または次世代ネットワーク内の通信ネットワーク上のアプリケーション例えば、マッシュアップおよびサードパーティアプリケーションを使用可能にする、権限の動的委譲のための一般的、効果的、かつセキュアな方法を提供する。第1の態様では、方法は、以下のステップを含む。第1のコンピューティングデバイスがリソース所有者を表し、第2のコンピューティングデバイスがリソース要求者を表す通信ネットワークにおいて、リソース所有者は、イベントの発生を検出し、イベント発生は、リソース所在地に格納されるリソース所有者の1つまたは複数のリソースにアクセスする要求を表す。リソース所有者は、イベント発生に応答して、リソース要求者に許可トークンを送信し、許可トークンは、リソース要求者が、リソース所在地に格納される1つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース要求者によりリソース所在地に提示されることになる、リソース所有者により委譲される許可の証明の働きをする。1つまたは複数の実施形態では、イベント発生は、リソース所有者によるリソース要求者からのリソース要求の受信であり得る例えば、プル方法。あるいは、イベント発生は、アプリケーションプログラムに関連するトリガイベントの発生であり得る例えば、プッシュ方法。リソース所在地は、第3のコンピューティングデバイスに存在し得る、または、それは、第1のコンピューティングデバイスに存在し得る。許可トークンは、検証可能な構造、有限の生存期間の1つまたは複数を有し得るとともに、リソース要求者を認証するための方法、または、リソース要求者を認証するための保証のレベルを指定することができる。検証可能な構造は、リソース所有者のデジタル署名を含み得る。許可トークンは、1つまたは複数の要求されるリソースによって実施されることが認可される、1つまたは複数のアクションを指定することができる。リソース要求者は、1回の往復で、リソース所有者から許可トークンを取得することができる。トークンを取得するための機構は、既存のアプリケーションプロトコルに結合され得る。1つまたは複数の要求されるリソースへのアクセスを得るための許可トークンの提示もまた、既存のアプリケーションプロトコルに結合され得る。さらに、他のリソース要求者が、リソース所在地に格納される1つまたは複数の要求されるリソースにアクセスすることを認可するように、他のリソース要求者が、別の許可トークンをリソース所在地に提示し得るように、リソース所有者により委譲される許可の証明が、リソース要求者から少なくとも別のリソース要求者に譲渡され得る。他のリソース要求者により取得される他の許可トークンは、リソース要求者によりリソース所有者から直接取得される許可トークン内で指定されるアクション認可範囲のサブセットであるアクション認可範囲を指定することができる。一実施形態では、他のリソース要求者により取得される他の許可トークンは、リソース要求者を認証するための方法、または、リソース要求者を認証するための保証のレベルを変更しない。さらに、他の許可トークンは、最初に受信された許可トークンの修正された形式であり得るとともに、前のリソース要求者が、他のリソース要求者に許可トークンの修正された形式を送信する前に、修正を実施する。さらに、リソース所有者は、リソース要求者に許可トークンを送信する前に、リソース要求者を認証することができる。第2の態様では、方法は、以下のステップを含む。第1のコンピューティングデバイスがリソース所有者を表し、第2のコンピューティングデバイスがリソース要求者を表し、リソース所有者が、イベントの発生を検出し、イベント発生が、リソース所在地に格納されるリソース所有者の1つまたは複数のリソースにアクセスする要求を表す通信ネットワークにおいて、リソース要求者は、イベント発生に応答して、リソース所有者により送信される許可トークンを受信し、許可トークンは、リソース要求者が、リソース所在地に格納される1つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース要求者によりリソース所在地に提示されることになる、リソース所有者により委譲される許可の証明の働きをする。1つまたは複数の実施形態では、リソース所在地は、リソース要求者が許可トークンをリソース所在地に提示する前に、リソース要求者を認証することができる。リソース所在地は、1つまたは複数の要求されるリソースに関してアクションを行う前に、リソース要求者により提示される許可トークンを検証する。さらに、リソース所在地は、リソース要求者が許可トークンをリソース所在地に提示した後に、リソース要求者を認証することができる。リソース要求者はさらに、少なくとも別のリソース要求者に、リソース所有者により委譲される許可の証明を譲渡することができる。そのような譲渡は、他のリソース要求者が、リソース所在地に格納される1つまたは複数の要求されるリソースにアクセスすることを認可するように、他のリソース要求者が、他の許可トークンをリソース所在地に提示し得るように、リソース要求者が、別の許可トークンを他のリソース要求者に送信することを含み得る。第3の態様では、方法は、以下のステップを含む。第1のコンピューティングデバイスがリソース所有者を表し、第2のコンピューティングデバイスがリソース要求者を表し、リソース所有者が、イベントの発生を検出し、イベント発生が、リソース所在地に格納されるリソース所有者の1つまたは複数のリソースにアクセスする要求を表し、リソース要求者が、イベント発生に応答して、リソース所有者により送信される許可トークンを受信する通信ネットワークにおいて、リソース所在地は、許可トークンを受信し、許可トークンは、リソース要求者が、リソース所在地に格納される1つまたは複数の要求されるリソースにアクセスすることを認可するように、リソース所有者によりリソース要求者に委譲される許可の証明の働きをする。有利には、本発明の動的権限委譲技法は、ウェブおよび非ウェブのアプリケーションに適用可能である。前記の本発明の技法は、HTTPリダイレクションの使用に依存せず、委譲される許可を取得するために複数の往復を必要としない。さらに、前記の本発明の技法は、既存の権限委譲体系より複雑でない。本発明のこれらおよび他の、目的、特徴および利点が、添付の図面と併せ読むべきその例示的な実施形態の以下の詳細な説明から明らかとなろう。本発明は、一例としての通信ネットワークおよび一例としてのアプリケーションに連関して、以下に例示される。しかしながら、本発明は、任意の特定のタイプの通信ネットワークまたはアプリケーションとともに使用することに限定されないことを理解されたい。開示される技法は、ウェブベースおよび非ウェブベースのネットワークを含む多種多様の通信ネットワークを用いた、ならびに、数多くのアプリケーションでの使用に適する。実際、開示される技法は、リソース所有者以外のエンティティによる保護されたリソースへのアクセスを伴う、通信ネットワーク上のアプリケーションを使用可能にするための、権限の動的委譲を提供することが望ましいことになる、任意の適した通信ネットワークにおいて、任意の適したアプリケーションとともに実施され得る。本明細書では、権限委譲は、一般には、何らかのアイテムへのアクセスを有するある当事者が、別の当事者にそのアイテムにアクセスする認可を与えることを指す。例として、以下の実施形態では、リソース所有者は、許可トークンを使用して、何らかのリソースにアクセスする認可をリソース要求者に与える。その動作は、委譲が、プロビジョニングによってではなく、必要に応じてリアルタイムに行われるという意味で動的とみなされる。本明細書では、トークンは、一般には、検証可能である、または認証され得る、アクセス制御の基準および動作を表す、データオブジェクトまたは構造を指す。本明細書では、リソースは、一般には、通信ネットワークを介してアクセス可能であり得る任意のアイテム、データ、情報等を指す。本明細書では、アプリケーションは、一般には、ユーザまたはエンティティが、1つまたは複数の具体的なタスクを実施するのに役立つように設計されたコンピュータソフトウェアを指す。本明細書で解説されるように、本発明の例示的な実施形態は、それによって、リソース要求者が、リソース所有者から直接、リソース所在地内のそのリソースにアクセスする認可を動的に取得することができる技法を提供する。本明細書では、所在地は、一般には、通信ネットワークを介してアクセス可能な格納場所を指す。リソース要求者は、リソース所有者により委譲される許可の証明を提示することにより、リソース所在地内の保護されたリソースにアクセスすることができる。証明すなわち許可トークンは、検証可能な構造および有限の生存期間を有し、中でも、リソース要求者を認証するための方法または保証のレベルを指定する。リソース要求者は、要求応答ベースであり、既存のアプリケーションプロトコルに結合され得る機構によって、1回の往復で、リソース所有者から動的に許可トークンを取得することができる。例えば、リソーストークンの要求/応答は、メッセージのヘッダまたは本体または両方の一部として、HTTPまたはセッション開始プロトコルSIPによって搬送され得る。保護されたリソースへのアクセスを得るためにリソーストークンを提示するための機構は、要求応答ベースであり、既存のアプリケーションプロトコルに結合され得る。例えば、トークンは、メッセージのヘッダまたは本体の一部として、HTPPまたはSIPによって搬送され得る。図1は、エンティティが、本発明の一実施形態による、セキュアな動的権限委譲に関与するシステム100を例示する。示されるように、システムは、3つのタイプのアクタ、すなわち、リソース所有者102、リソース要求者104、およびリソース所在地106を必要とする。3つのアクタは、各個が、以下でさらに解説されるように、1つまたは複数のコンピューティングデバイスとして実施され得ることを理解されたい。リソース所有者102は、エンドユーザの場合ではユーザエージェントとして、またはサービスプロバイダまたは組織の場合では許可サーバとして実施され得る。同様に、リソース要求者104は、エンドユーザの場合ではユーザエージェントとして、またはサービスプロバイダまたは組織の場合ではアプリケーションサーバとして実施され得る。コンピューティングデバイスAを操作するアリスが、写真プリントサービスプロバイダに、サーバに格納された自分のモスクワ旅行に関する自分の写真をプリントするように求めるユースケースでは、リソース所有者102アリスは、ユーザエージェント例えば、コンピューティングデバイスA上で実行するウェブブラウザプログラムにより表されることになり、リソース要求者104写真プリントサービスプロバイダは、アプリケーションサーバにより表されることになる。コンピューティングデバイスBを操作するボブが、オンライン映画サービスの加入者である別のユースケースでは、リソース所有者102オンライン映画サービスプロバイダは、許可サーバにより表されることになり、リソース要求者104ボブは、ユーザエージェント例えば、コンピューティングデバイスB上で実行するウェブブラウザプログラムにより表されることになる。リソース所在地106内のある決まった保護されたリソースへのアクセスを得るために、リソース要求者104は、以下でさらに考察されることになる図2に例示的に示されるような基本構造200を有する許可トークンを、リソース所有者102から直接取得する必要がある。その目的のために、2つの方法、すなわちプルおよびプッシュが考えられる。プル方法では、リソース要求者104およびリソース所有者102は、要求および応答を交換する。トークン要求は、少なくとも、要求者、ならびに目標リソースおよび関連するアクションを特定するものとする。以下で解説される図3および4は、それぞれ、リソース要求者104およびリソース所有者102の観点からのプル方法を図示する。プッシュ方法では、リソース所有者102は、リソース要求者からの明示的な要求ではなく、アプリケーションのトリガの結果として、リソース要求者104に許可トークンを発行することができる。図3は、基本的な許可トークンを要求するための、リソース要求者例えば、図1での104側に関するプル方法300を示す。ステップ302では、リソース要求者は、要求所有者に対する許可トークン要求を生成かつ送信する。ステップ304では、リソース要求者は、それがリソース所有者から受信する第1の応答をチェックし、ステップ306では、第1の応答がそれによって、リソース所有者が、所有者が要求者に許可トークンを送信する前に要求者が認証されることを要求している認証要求を含むかどうか、または、第1の応答が許可トークンを含むかどうかを判定する。リソース所有者からの第1の応答が、認証要求ではなく、許可トークンを含み、したがって、ステップ308すなわち、以下で説明される失敗トークン応答の受信に対するチェックが否定をもたらす場合、要求者は、ステップ310で、リソース所在地への後に続く伝送のために許可トークンを保存する。これに対して、リソース所有者からの第1の応答が、認証要求である場合、ステップ312で、リソース要求者は、リソース所有者に対する認証応答を生成かつ送信する。ステップ314では、リソース要求者は、次いで、それがリソース所有者から受信する第2の応答をチェックし、第2の応答が許可トークンを含むしたがって、認証が成功したと推定するかどうかを判定する。そうである場合、ステップ308失敗トークン応答が否定をもたらし、要求者は、ステップ310で、リソース所在地への後に続く伝送のために許可トークンを保存する。これに対して、認証が失敗した場合、リソース所有者から受信される第2の応答は、失敗トークン応答であり、すなわち、リソース所有者が要求者に許可トークンを発行しないことになることを意味する。要求者を認証するために使用される技法は、任意の従来の認証技法を含み得ることを理解されたい。図4は、トークン要求に対処するための、リソース所有者例えば、図1での102側に関するプル方法400を示す。ステップ402では、リソース所有者は、そこからトークン要求が受信されたリソース要求者が認証されているか否かをチェックする。そうでない場合、ステップ404で、リソース所有者は、認証要求を生成し、それをリソース要求者に送信する。ステップ406では、リソース所有者は、リソース要求者から受信された認証応答をチェックする。ステップ408では、認証が成功したかどうかを判定するためにチェックが行われる。いいえである場合、リソース所有者は、ステップ410で、要求者に失敗トークン応答を送信するすなわち、許可トークンは要求者に送信されない。これに対して、認証が成功した場合、所有者は、ステップ412で、要求者は所有者のリソース複数可へのアクセスが与えられるべきかどうかを判断し、そうである場合、ステップ414で、許可トークンを生成し、それを要求者に送信する。これに対して、アクセスが拒否される場合、ステップ410で、失敗トークン応答が送信される。許可トークンが供給されると、リソース要求者104は、次いで、リソース所在地106内の保護されたリソースへのアクセスを要求することができる。リソース要求を受信する際に図1を参照、リソース所在地106は、以下のアクションを行う:1-要求に関連するデジタル署名が有効であることを、トークンで指定されたデジタル署名方法に基づいて検証する、2-トークンが、時間および使用の最大数に関して失効していないことを検証する、3-要求されるリソースおよび実施されるべきアクションが、トークンで指定されたリソースおよび関連する権利のリストの一部であることを検証する、4-リソース要求者の名前が、トークン内の要求者の名前と一致することを検証する、ならびに、5-トークンで指定された方法または強度レベルの方法を使用して、リソース要求者を認証する。図5Aおよび5Bは、リソース所在地例えば、図1での106により保持される、初期の要求では必ずしも許可トークンを含まない保護されたリソースへのアクセスのための、リソース要求者例えば、図1での104側に関する方法500を示す。ステップ502では、リソース要求者は、要求所在地に対するリソース要求を生成かつ送信する。ステップ504では、リソース要求者は、それがリソース所在地から受信する第1の応答をチェックし、ステップ506では、第1の応答がそれによって、リソース所在地が、所在地が要求者によるリソースへのアクセスを認可する前に要求者が認証されることを要求している認証要求を含むかどうか、または、第1の応答が許可トークンを求めているかどうかを判定する。リソース所在地からの第1の応答が、認証要求ではなく、許可トークンを求めており以下で説明される514、したがって、ステップ508すなわち、以下で説明される失敗応答の受信に対するチェックが否定をもたらす場合、要求者は、許可トークンを送信する以下で説明される516。これに対して、リソース所在地からの第1の応答が、認証要求である場合、ステップ510で、リソース要求者は、リソース所在地に対する認証応答を生成かつ送信する。ステップ512では、リソース要求者は、次いで、それがリソース所在地から受信する第2の応答をチェックし、第2の応答が、失敗応答であるか508、それとも、許可トークンに対する要求であり514、したがって、認証が成功したと推定するかを判定する。後者場合、要求者は、ステップ516で、それが、図3および4の脈絡において上記で説明されたプロトコルによってリソース所有者から受信した許可トークンを送信する。ステップ518では、リソース要求者は、次いで、それがリソース所在地から受信する第3の応答をチェックし、第3の応答が、別の認証要求、すなわち、要求者がトークンで規定された方法によって認証されることを確実にするための、所在地による後に続く認証要求であるかどうかを判定する。すなわち、追加的なセキュリティのために、リソース所在地は、トークンが受信されるたびに、要求者を再認証する必要がある場合がある。そうである場合、上記で説明されているステップ510、512および508と同様である、ステップ524、526および528が実施される。ステップ530では、要求者は、典型的には要求されるリソースを包含する応答を処理する。図6Aおよび6Bは、リソース要求者例えば、図1での104からのリソース要求に対処するための、リソース所在地例えば、図1での106側に関する方法600を示す。ステップ602では、リソース所在地は、リソース要求者が認証されているかどうかをチェックする。はいである場合、ステップ604で、リソース所在地は、要求者がリソース所有者であるその場合には、要求者は、許可トークンを必要としないことになるかどうかを確認する。はいである場合、ステップ606で、所在地は、適切なリソースのアクションを適用し、応答を送信する例えば、要求されるリソース複数可へのアクセスを付与する。これに対して、ステップ602に戻って、要求者が認証されておらず、許可トークンが要求者によりまだ提供されていないステップ608場合、認証処理が、ステップ610要求者に対する要求を生成かつ送信する、612認証応答をチェックする、および614認証成功を確認するで実施される。成功でない場合、ステップ616で、失敗応答が要求者に送信される。これに対して、認証が成功した場合、ステップ604が実施され要求者が所有者であるかどうかをチェックする、肯定的である場合、ステップ606リソースのアクションを適用し、応答を送信するが実施される。これに対して、ステップ614での成功した認証、および、ステップ604での要求者がリソース所有者でないことの検証の後で、所在地は、ステップ618で、要求者に許可トークンを求め、ステップ620で、それが要求者により提供されたかどうかをチェックする。そうでない場合、ステップ616で、失敗応答が送信される。トークンが受信された後、リソース所在地は、ステップ622で、トークンを検証する。例えば、検証は、トークン署名が有効であるかどうか、要求およびトークン内の要求者の名前が一致するかどうか、トークンが失効していないかどうか、要求されるリソースおよびアクションが範囲内であるすなわち、要求者および/または要求されているリソースに対して認可されるものであるかどうかを判定するように実施される。トークンの構造に応じて、より少ない、またはより多い検証が、トークンおよびその内容に対して行われ得ることを理解されたい。トークンの1つまたは複数の構成が検証され得ない場合、ステップ624で、失敗応答が要求者に送信され、したがって、リソースは要求者に対して利用可能にされない。これに対して、受信されたトークンのすべての構成が検証される場合、別の認証処理が、トークンで指定された方法または保証レベルに関する認証要件によって所在地により要求され得る。これは、ステップ610、612、および614と同様である、ステップ626、628、630および632によって行われる。第2の認証が成功していると推定すると、ステップ634で、リソースのアクションが適用され、応答が送信されるすなわち、リソースへのアクセスが認可される。そうでない場合、ステップ624で、失敗応答が送信される。再び図2に戻ると、許可トークンの基本構造は、名前-値の対に関するフィールドのリスト、および、発行者の秘密鍵または共有秘密に基づいて、指定された署名アルゴリズム210例えば、RSA-SHA1およびHMAC-SHA256を使用して、フィールドにわたって計算された発行者の署名202で構成される。一意的トークン識別子204は、発行者の名前206およびタイムスタンプを連結することにより構築され得る。発行者の証明書または証明書へのポインタのチェーン208が、トークンで指定される。このフィールドは、発行者の署名を計算するために使用されるアルゴリズムが秘密鍵ベースである場合に、全体的な性能を向上させるために含まれる必要があるに過ぎないことに留意されたい。フィールド212は、リソース要求者の名前識別情報を指定する。フィールド214は、要求者を認証するための方法または方法の強度を指定する。フィールド216は、受信者、すなわち、リソース所在地の働きをするデバイスまたはサーバの名前識別情報を指定する。リソースおよび権利のリスト218、失効時間220、ならびに使用の最大数222の複合的なフィールドが、全体的な委譲範囲を設定する。譲渡可能性の程度224は、リソース所有者により発行されるトークンが、最初の要求者から開始して、一連のトークン要求者に至るまで転送され得る程度を指し示す。それは、非負の整数の値をとり得る。譲渡可能性の第0の程度のトークンは、転送され得ない。譲渡可能性の第Nの程度のトークンは、最初のトークン要求者により、第2のトークン要求者に、第3の要求者に、以下同様にして、最多で第Nの要求者に譲渡され得る。譲渡可能なトークンを取得した後で、要求者は、新しいトークンを古いものに基づいて、新しい要求者に発行することができる。図7に示されるように、新しいトークン700は、前と同じ方法により認証されることになる新しい要求者708の識別情報、および場合によっては、格下げされた委譲範囲710を指定する。一実施形態では、新しいトークン700は、古いトークン704すなわち、図2に示されるトークン構造、および、前の要求者今では発行者の証明書または証明書へのポインタのチェーン706をさらに包含する。発行者の署名702は、発行者の秘密鍵または共有秘密に基づいて、古いトークンで指定された署名アルゴリズムと同じであり得る署名アルゴリズムを使用して、フィールドにわたって計算される。転送されるトークンを検証する場合に、リソース所在地は、加えて、以下のことをチェックする必要がある:1-譲渡可能性の程度が、存在する新しい要求者の数より大きい、2-すべての署名が有効である、および、3-トークンが転送される際に、範囲が途中で広げられない。譲渡可能なトークンのユースケースは、以下のようなものである。アリスは、ある決まったコンテンツをコンテンツサーバ上で公表し、自分のコンテンツへの他者によるアクセスに対処するために、関連するコンテンツマネージャを自分のプロキシにする。譲渡可能である、または使用の数が制限されているトークンをサポートするために、リソース所在地は状態を維持する必要があることに留意されたい。最後に、図8は、本発明の上記で説明された原理による、セキュアな動的権限委譲を実施するのに適した通信ネットワーク800の一般化されたハードウェアアーキテクチャを例示する。示されるように、リソース所有者810用のコンピューティングデバイス例えば、図1での102、リソース所在地820用のコンピューティングデバイス例えば、図1での106、およびリソース要求者830用のコンピューティングデバイス例えば、図1での104は、通信ネットワーク媒体850を介して動作可能に結合される。ネットワーク媒体は、コンピューティングデバイスが通信することを望む任意のネットワーク媒体であり得る。例として、ネットワーク媒体は、IPパケットをエンドツーエンドで搬送し得るものであり、アクセスネットワークではUMTSユニバーサル移動体通信システムもしくはWiFiもしくはDSLデジタル加入者線を、メトロネットワークではイーサネット登録商標を、ならびにバックボーンではMPLSマルチプロトコルラベルスイッチングを必要とし得る。しかしながら、本発明は、特定のタイプのネットワーク媒体に限定されない。典型的には、各個のコンピューティングデバイスは、実施されている権限委譲のシナリオに応じて、クライアントマシンまたはサーバマシンとして機能し得る。リソース所在地は、別個のコンピューティングデバイスとして示されるが、所在地は、所有者または要求者と同じコンピューティングデバイスの一部であり得ることをさらに理解されたい。さらに、リソース所有者、要求者および所在地は、各個が、1つのコンピューティングデバイスによって実施されているように図8で示されるが、各個は、2つ以上のそのようなコンピューティングデバイスによって実施され得ることを理解されたい。当業者には容易に明らかとなるように、コンピューティングデバイスは、コンピュータプログラムコードの制御のもとで動作するプログラムされたコンピュータとして実施され得る。コンピュータプログラムコードは、コンピュータまたはプロセッサまたは機械可読記憶媒体例えば、メモリに記憶されることになり、コードは、コンピュータのプロセッサにより実行されることになる。本発明の本開示が与えられれば、当業者は、本明細書で説明されたプロトコルを実施するために、適切なコンピュータプログラムコードを容易に生み出すことができる。それでも、図8は、ネットワーク媒体を介して通信する各個のデバイスに対する一例としてのアーキテクチャを全体的に例示する。示されるように、リソース所有者810は、I/Oデバイス812、プロセッサ814、およびメモリ816を備える。リソース所在地820は、I/Oデバイス822、プロセッサ824、およびメモリ826を備える。リソース要求者830は、I/Oデバイス832、プロセッサ834、およびメモリ836を備える。本明細書で使用される用語プロセッサは、1つまたは複数の信号プロセッサ、1つまたは複数の集積回路等を含むが、それらに限定されない、中央処理装置CPUまたは他の処理回路網を含む、1つまたは複数の処理デバイスを含むことが意図されるということを理解されたい。さらに、本明細書で使用される用語メモリは、RAM、ROM、固定メモリデバイス例えば、ハードドライブ、またはリムーバブルメモリデバイス例えば、ディスケットまたはCDROMなどの、プロセッサまたはCPUと関連するメモリを含むことが意図される。加えて、本明細書で使用される用語I/Oデバイスは、データを処理装置に入力するための1つもしくは複数の入力デバイス例えば、キーボード、マウス、ならびに、処理装置に関連する結果を提供するための1つもしくは複数の出力デバイス例えば、CRTディスプレイを含むことが意図される。したがって、本明細書で説明された、本発明の方法論を実施するためのソフトウェア命令またはコードは、関連するメモリデバイス、例えば、ROM、固定メモリまたはリムーバブルメモリの、1つまたは複数に記憶され得るとともに、利用される準備ができた場合に、RAMにロードされ、CPUにより実行され得る。すなわち、図8に示される各個のコンピューティングデバイス810、820、および830は、図1および7に図示されるプロトコルのそれらのそれぞれのステップを実施するように、個別にプログラムされ得る。本発明の例示的な実施形態が、添付の図面を参照して本明細書で説明されたが、本発明はそれらのまさにその実施形態に限定されないこと、ならびに、様々な他の変更および修正が、本発明の範囲または趣旨から逸脱することなく、当業者により行われ得ることを理解されたい。