(57)【要約】【課題】複数の利用側エンティティ（クライアントなど）によるデータ処理システム（サーバなど）内の共有リソースへのアクセスについての解決策を提供すること。【解決手段】対応する方法（５００）は、アクティブ・エンティティのセットの各１つに、共有リソースの特権使用に関する特権限度（クレジットの形でなど）を関連付けるステップ（５１８〜５２４）から始まる。アクティブ・エンティティごとに使用インジケータが測定され（５７５）、使用インジケータは、アクティブ・エンティティによる共有リソースの実際の使用（所望の応答を受け取った回数によって定義されるものなど）を示す。この方法は、アクティブ・エンティティの新しい１つによる共有リソースへのアクセスに関するアクセス要求を受け取ること（５３３）によって継続される。この方法は、共有リソースのクリティカル条件（サービスを活用するためのハンドルが使用可能でない時など）を検出する（５３３、５５１）。共有リソースに現在アクセスしているイネーブルされたエンティティのセットのうちの少なくとも１つに与えられたアクセスが、解放され（５５４〜５６３）、これは、特権限度に達しない新しいアクティブ・エンティティの使用インジケータを用いるクリティカル条件でのアクセス要求に応答して発生する。次いで、アクセスは新しいアクティブ・エンティティに与えられる（５６６〜５６７）【選択図】図３
2010539570.tif 000002
【特許請求の範囲】
【請求項１】
複数の利用側エンティティによるデータ処理システム内の共有リソースへのアクセスの方法（５００）であって、
アクティブ・エンティティのセットの各１つに、前記共有リソースの特権使用に関する特権限度を関連付けるステップ（５１８〜５２４）と、
アクティブ・エンティティごとに使用インジケータを測定するステップ（５７５）であって、前記使用インジケータが、前記アクティブ・エンティティによる前記共有リソースの実際の使用を示す、ステップ（５７５）と、
前記アクティブ・エンティティの新しい１つによる前記共有リソースへのアクセスに関するアクセス要求を受け取るステップ（５３３）と、
前記共有リソースのクリティカル条件を判定するステップ（５３３、５５１）と、
前記新しいアクティブ・エンティティの前記使用インジケータを用いる前記クリティカル条件での前記アクセス要求が前記特権限度に達しないことに応答して前記共有リソースに現在アクセスしているイネーブルされたエンティティのセットのうちの少なくとも１つに与えられたアクセスを解放するステップ（５５４〜５６３）と、
前記アクセスを前記新しいアクティブ・エンティティに与えるステップ（５６６〜５６７）と
を含む方法（５００）。
【請求項２】
最大個数のアクセスが、前記共有リソースに対して同時に許可され、前記クリティカル状態を検出する前記ステップ（５３３、５５１）が、
アクセスの前記最大個数に達した後に前記アクセス要求を受け取ること（５３３）
を含む、請求項１に記載の方法（５００）。
【請求項３】
前記少なくとも１つのイネーブルされたエンティティに許可された前記アクセスを解放する前記ステップ（５５４〜５６３）が、
前記特権制限に最も近い対応する使用インジケータを有する前記イネーブルされたエンティティのうちの１つを選択すること（５６０）と、
前記選択されたイネーブルされたエンティティに許可された前記アクセスを解放すること（５６３）と、
を含む、請求項１または２に記載の方法（５００）。
【請求項４】
前記少なくとも１つのイネーブルされたエンティティに許可された前記アクセスの前記解放（５５４〜５６３）を解放する条件に条件付けるステップ（５６０〜５６１）
をさらに含む、請求項１ないし３のいずれかに記載の方法（５００）。
【請求項５】
前記共有リソースが、サービスを提供するように適合されたサーバを含み、各利用側エンティティが、前記サービスを活用するように適合されたクライアントを含み、各アクセス要求が、前記サービスを活用するためのサービス要求を含み、各イネーブルされたエンティティが、前記サービスを現在活用しているイネーブルされたクライアントを含み、作業セッションのハンドルが、各イネーブルされたクライアントに割り振られ、
前記新しいアクティブ・クライアントに前記アクセスを許可する前記ステップ（５６６〜５６７）が、対応する新しいハンドルを割り振ること（５６６）を含み、
前記少なくとも１つのイネーブルされたクライアントに許可された前記アクセスを解放する前記ステップ（５５４〜５６３）が、各対応するハンドルを解放すること（５６３）を含み、
前記方法が、さらに、前記新しいアクティブ・クライアントからの前記サービス要求の前記受取に応答して、
使用可能な場合に前記新しいアクティブ・クライアントに以前に割り振られたハンドルを使用するステップ（５６８）
を含む、請求項１ないし４のいずれかに記載の方法（５００）。
【請求項６】
各セッションが、前記サービスを活用する前記対応するイネーブルされたクライアントのコンテキスト情報の維持を含み、
前記新しいアクティブ・クライアントに前記アクセスを許可する前記ステップ（５６６〜５６７）が、さらに、前記対応するコンテキスト情報をロードすること（５６７）を含み、
前記少なくとも１つのイネーブルされたクライアントに許可された前記アクセスを解放する前記ステップ（５５４〜５６３）が、さらに、各対応するコンテキスト情報を破棄すること（５６３）を含む
請求項５に記載の方法（５００）。
【請求項７】
各イネーブルされたクライアントのアクティビティを監視するステップ（５０６）と、
前記対応するイネーブルされたクライアントのインアクティビティ・インジケータが第１しきい値に達する時に各ハンドルを解放するステップ（５０９〜５１０）と
をさらに含む、請求項５または６に記載の方法（５００）。
【請求項８】
前記少なくとも１つのイネーブルされたクライアントに許可された前記アクセス（５５４〜５６３）の前記解放を条件付ける前記ステップ（５６０〜５６１）が、
前記第１しきい値に先行する第２しきい値を超える前記インアクティビティ・インジケータを有する前記イネーブルされたクライアントに前記解放を制限すること（５６０）
を含む、請求項４に依存する時の請求項７に記載の方法（５００）。
【請求項９】
各アクティブ・クライアントに前記特権限度を関連付ける前記ステップ（５１８〜５２４）が、
前記アクティブ・クライアントによる前記サービスの活用の開始に関する接続要求を受け取ること（５１８）と、
前記アクティブ・クライアントの前記コンテキスト情報を収集すること（５２１）と、
前記サービスを活用するための前記アクティブ・クライアントの許可のためのトークンを作成すること（５２２）であって、前記トークンが、開始値に初期化された前記アクティブ・クライアントの前記特権限度に関連する、作成すること（５２２）と、
前記トークンに関連するプロファイルに前記アクティブ・クライアントの前記コンテキスト情報を格納すること（５２４）と
を含み、前記新しいアクティブ・クライアントに前記アクセスを許可する前記ステップ（５６６〜５６７）が、
前記対応するトークンを前記新しいハンドルに関連付けること（５６６）と、
前記対応するトークンの前記プロファイルから前記対応するコンテキスト情報を取り出すこと（５６７）と
を含み、前記少なくとも１つのイネーブルされたクライアントに許可された前記アクセスを解放する前記ステップ（５５４〜５６３）が、
前記対応するトークンの前記プロファイルに各対応するコンテキスト情報を保存すること（５６２）
を含む、請求項６ないし８のいずれかに記載の方法（５００）。
【請求項１０】
前記クリティカル状態にはない各アクティブ・クライアントへの前記特権限度の前記関連付け（５１８〜５２４）に応答して、
前記アクティブ・エンティティに前記アクセスを許可するステップ（５３０〜５３１）
をさらに含む、請求項９に記載の方法（５００）。
【請求項１１】
使用限度に達した後に前記トークンを解放するステップ（５４０）
をさらに含む、請求項９または１０に記載の方法（５００）。
【請求項１２】
請求項１ないし１１のいずれかに記載の方法（５００）を実施する、データ処理システム（１００）内で展開されるサービス（４００）。
【請求項１３】
データ処理システム（１０５）上で実行される時に、請求項１ないし１１のいずれかの方法（５００）を実行する前記コンピュータ・プログラム（４００）。
【請求項１４】
請求項１ないし１１のいずれかに記載の方法（５００）のステップを実行する手段（４００）を含むシステム（１０５）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理の分野に関する。より具体的には、本発明は、データ処理システムでの共有リソースへのアクセスに関する。
【背景技術】
【０００２】
共有リソースは、現代のデータ処理システムでありふれたものである。一般的に言って、共有リソースは、複数の利用側によって順番にアクセスできるすべての（論理的または物理的あるいはその両方の）コンポーネントからなる。共有リソースの例は、クライアント・コンピュータ（または、単にクライアント）によってサーバ・コンピュータ（または、単にサーバ）にアクセスする多数のユーザに対応するサービスを提供するサーバである。上で説明したクライアント／サーバ構造の通常の応用例が、たとえばＤＡＭ（ディジタル資産管理（Digital Asset Management））タイプのサービスの実施のための、ＳＯＡ（サービス指向アーキテクチャ）環境にある。
【０００３】
使用可能なサービスの一部は、無料であるが、サービスのほとんどの活用は、ユーザによるある種の支払いの対象である。
【０００４】
具体的に言うと、ＵＳ−Ａ−２００３／００２８６５３に記載されているように、プリペイド・クレジット（prepaid credit）を各ユーザに関連付けることができ、この形で、ユーザは、彼／彼女のクレジットが使い果たされるまで、特定のサービスを活用することを許可される。この文書は、暗号化されたトークンの使用に基づくセキュリティ改善を提案し、この暗号化されたトークンは、認証情報（ユーザおよびクライアントに関する）、許可情報（アクセスの許可されるレベルに関する）、およびアカウンティング情報（クレジットおよび既に費やされた合計に関する）を格納し、たとえば、このトークンを、ユーザに与えられるスマート・カードに格納することができる。トークンは、ユーザが、サーバによって提供されるアプリケーションへのアクセスを望む時に、必ずそのサーバに送られる。サーバは、トークンを暗号化解除し、抽出された情報を使用して、彼／彼女のアイデンティティ、許可、および残りクレジットを検証し、上で述べた検証の結果が肯定である場合には、ユーザは、所望のアプリケーションにアクセスすることを許可される。その後、サーバは、ユーザによるアプリケーションへのアクセスを監視し、残りクレジットが使い果たされた時に、サーバは、それ相応にユーザに警告し、その結果、彼／彼女が、進行中の作業を保存し、アプリケーションを終了できるようにするか、アプリケーションへのアクセスを継続するためにさらなるクレジットを入手できるようにする。
【０００５】
クレジットの概念は、ＵＳ−Ａ−２００６／０２７１６９２で、サーバにサブミットされるコマンドの実行を制御するのにも活用される。この目的で、クレジットは、数のセットによって表され、各サブミットされるコマンドは、これらの数のうちの１つを含み、その結果、数が有効ウィンドウ内にあり、まだ使用されていない場合に限って、そのコマンドが処理されるようになる。この形で、サーバは、クレジットを動的に（有効ウィンドウを拡大し、または縮小することによって）管理でき、さらに、同一の番号を再利用することの不可能性は、サーバへのフラッディング攻撃を防ぐことを可能にする。
【０００６】
類似するトークンを、さらなる目的に使用することもできる。
【０００７】
たとえば、ＵＳ−Ｂ−６７１５０８２は、異なるユーザの証明書をサーバに格納することを提案し、トークンは、ユーザによる再強奪を防ぐために、各証明書に関連付けられる。
【０００８】
さらに、ＵＳ−Ｂ−７０２８０９０では、トークンは、各ユーザの妥当性検査の後に、彼／彼女に発行され、トークンは、制限された時間の間にそのユーザに許可される特定の許可を格納する。
【０００９】
最後に、ＵＳ−Ｂ−６０６５１１７は、対応するクライアントに関するサーバ上の状態情報を取り出すためのトークンの使用を開示する。
【００１０】
どの場合でも、サーバ（およびより一般的にはすべての共有リソース）の問題は、これらが、本質的に制限されていることである。たとえば、各サービスを同時に活用することを許可されるユーザは、事前定義の最大人数を超えることができない。この制限は、客観的制約または主観的制約のいずれかに起因する可能性がある。実際に、サーバの処理能力は、サービスを活用するために確立できる（サーバとクライアントとの間で）作業セッションの個数を定義する。それに加えてまたは代替案では、同時ユーザの個数を、サービス品質の適当なレベルを保証するためにまたは特定のライセンス合意（たとえば、同時ユーザの個数に対するサービスのコストに関する）に従って減らすことができる。これに関して、タイムアウト機構（各セッションが、対応するユーザの非アクティブ時間が所定のしきい値に達する時に自動的にクローズされる）が、通常、無用なセッションに関してサーバをビジーに保つことを避けるために実施される。しかし、この場合に、最大個数の同時ユーザに達した後に、新しいユーザによるサービスを活用するための要求のすべてが、拒否される。
【００１１】
これは、サーバの可用性を強く制限し、この問題は、その活用をすべての情況で（たとえば、要求のピークの場合であっても）最大の可能な数の異なるユーザに保証しなければならないサービス（ＤＡＭタイプのサービスなど）において特に激しい。上で述べた必要が、しばしば、サーバの過剰な過負荷を避けるという反対の要件とバランスをとられなければならないことに留意されたい。たとえば、これは、各セッションが、対応するユーザのコンテキスト情報を維持する時に発生し、通常は、コンテキスト情報は、複雑なハンドシェーキング手順（ユーザの妥当性検査および許可に関する）によって収集される。したがって、コンテキスト情報（セッションがクローズされる時に失われる）は、同一ユーザが別のセッションによって処理されるさらなる要求をサブミットする時に、必ず再収集されなければならない。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】ＵＳ−Ａ−２００３／００２８６５３
【特許文献２】ＵＳ−Ａ−２００６／０２７１６９２
【特許文献３】ＵＳ−Ｂ−６７１５０８２
【特許文献４】ＵＳ−Ｂ−７０２８０９０
【特許文献５】ＵＳ−Ｂ−６０６５１１７
【特許文献６】米国特許出願第ＥＰ０７１１１０６９．７号
【発明の概要】
【発明が解決しようとする課題】
【００１３】
【課題を解決するための手段】
【００１４】
一般論として、本開示は、アクセスの解放を強制するために共有リソースの限られた特権使用（たとえば、経時的に減少するクレジットの形での）を定義するという発想に基づく。
【００１５】
具体的に言うと、本発明の異なる態様は、独立請求項に示された解決策を提供する。本発明の有利な実施形態は、従属請求項で説明される。
【００１６】
より具体的には、本発明の態様は、複数の利用側エンティティ（クライアントなど）によるデータ処理システム（サーバなど）内の共有リソースへのアクセスの方法を提案する。この方法は、アクティブ・エンティティのセットの各１つに、共有リソースの特権使用に関する特権限度（クレジットの形でなど）を関連付けるステップから始まる。使用インジケータが、アクティブ・エンティティごとに測定され、使用インジケータは、アクティブ・エンティティによる共有リソースの実際の使用（所望の応答を受け取った回数によって定義されるものなど）を示す。この方法は、アクティブ・エンティティの新しい１つによる共有リソースへのアクセスに関するアクセス要求を受け取ることによって継続される。この方法は、共有リソースのクリティカル条件（サービスを活用するためのハンドルが使用可能でない時など）を検出する。共有リソースに現在アクセスしているイネーブルされたエンティティのセットのうちの少なくとも１つに与えられたアクセスが、解放され、これは、特権限度に達しない新しいアクティブ・エンティティの使用インジケータを用いるクリティカル条件でのアクセス要求に応答して発生する。その後、アクセスは、新しいアクティブ・エンティティに与えられる。
【００１７】
通常、この方法は、共有リソースに対して同時に許可されるアクセスの最大個数に達した後に応用例を見出す。
【００１８】
好ましくは、解放されるアクセスは、特権制限に最も近い（たとえば、最低のクレジットを有する）対応する使用インジケータを有するアクセスとして選択される。
【００１９】
さらなる改善として、アクセスの強制される解放は、条件付けられる（たとえば、対応するエンティティのアクティビティに従って）。
【００２０】
提案される解決策は、クライアント／サーバ・アーキテクチャ（作業セッションのハンドルがアクセスごとに割り振られる）を有するシステムで実施することができる。
【００２１】
通常、コンテキスト情報は、各ハンドルに関連付けられる（ステートフル・アプリケーションの場合など）。
【００２２】
さらなる改善として、各ハンドルは、対応するクライアントのインアクティビティ・インジケータがしきい値に達する（すなわち、タイムアウト）時に、解放される。
【００２３】
この場合に、アクセスの強制解放を、そのインアクティビティ・インジケータがもう１つのしきい値（上で述べたものに先立つ）を超えるクライアントに制限することができる。
【００２４】
本発明の実施形態は、トークン（対応するクライアントにアクセスを許可するための）の使用に基づき、トークンは、異なるセッションの間でクライアントのコンテキスト情報を保存するためのプロファイルに関連する。
【００２５】
この解決策をさらに改善する形は、各トークンの作成時にハンドルを割り振る（可能な場合に）ことである。
【００２６】
好ましくは、各トークンは、使用限度（もう１つのタイム・アウトなど）に達した後に解放される。
【００２７】
本発明のさらなる態様は、対応するサービスを提案する。
【００２８】
本発明のもう１つの態様は、上で説明した方法を実行するコンピュータ・プログラムを提案する。
【００２９】
本発明の異なる態様は、対応するシステムを提案する。
【００３０】
本発明自体ならびに本発明のさらなる特徴および利益は、添付図面に関して読まれるべき非限定的な表示としてのみ与えられる次の詳細な説明を参照して最もよく理解される。
【図面の簡単な説明】
【００３１】
【図１】本発明の実施形態による解決策を適用できるデータ処理システムを示す概略ブロック図である。
【図２】本発明の実施形態による解決策の応用例に関する例示的シナリオを示す例示的時間図である。
【図３】本発明の実施形態による解決策の応用例に関する例示的シナリオを示す例示的時間図である。
【図４】本発明の実施形態による解決策を実施するのに使用できる主ソフトウェア・コンポーネントを示す図である。
【図５】本発明の実施形態による解決策の実施態様に関するアクティビティの流れを示す図である。
【図６】本発明の実施形態による解決策の実施態様に関するアクティビティの流れを示す図である。
【発明を実施するための形態】
【００３２】
特に図１を参照すると、分散データ処理システム１００が示されている。分散データ処理システム１００は、通常はインターネットに基づく、クライアント／サーバ・アーキテクチャを有する。インターネットは、グローバル通信ネットワーク１１０を介して相互接続された数百万台のサーバ１０５（この図には１つだけを図示）からなる。各サーバ１０５は、１つまたは複数のサービスを提供する。クライアント１１５のユーザは、提供されるサービスを活用するために、サーバ１０５に（インターネットに関するアクセス・プロバイダとして動作する、この図には示されていないコンピュータを介して）アクセスする。
【００３３】
たとえば、サービスは、ＳＯＡ仕様に準拠する。この場合に、各サービスは、独立型の基本タスクからなり、これらの基本タスクは、その基礎になる実装と独立の明確に定義されたインターフェースを介して呼び出され得、ＳＯＡ環境は、本質的にステートレスであり、これは、サービスのすべての呼出しが、自己完結的である（以前の処理の知識を全く有しない）ことを意味する。サービスは、ＤＡＭタイプであるすなわち、ディジタル資産（写真、ビデオ、音楽、および類似物）の獲得、格納、および取出をサポートするものとすることができる。たとえば、各サービスを、ＳＯＡ環境内で働くようにラッピングされたレガシ・アプリケーションを用いて実施することができる。レガシ・アプリケーションは、その代わりに、ステートフルであることができ、これは、各ユーザの文脈情報が異なる処理のために維持されることを意味する。通常、コンテキスト情報は、個人データ（ユーザまたは対応するクライアントあるいはその両方に関する）および状況データ（処理の現在の進行状況に関する）を含む。一般に、個人データは、ハンドシェーキング手順によって収集され、このハンドシェーキング手順は、ユーザのアイデンティティおよび所望のサービスを活用するための彼／彼女の許可を検証することを可能にする。
【００３４】
具体的に言うと、サーバ１０５は、システム・バス１２０に並列に接続された複数のユニットによって形成されるコンピュータからなる。詳細に言うと、１つまたは複数のマイクロプロセッサ（μＰ）１２５が、サーバ１０５の動作を制御し、ＲＡＭ  １３０は、作業メモリとしてマイクロプロセッサ１２５によって直接に使用され、ＲＯＭ  １３５は、サーバ１０５のブートストラップ用の基本コードを格納する。複数の周辺ユニットが、ローカル・バス１４０の周囲でクラスタ化される（それぞれのインターフェースによって）。具体的に言うと、マス・メモリは、１つまたは複数のハードディスク１４５およびＣＤ−ＲＯＭ  １５５を読み取るドライブ１５０からなる。さらに、サーバ１０５は、入力ユニット１６０（たとえば、キーボードおよびマウス）および出力ユニット１６５（たとえば、モニタおよびプリンタ）を含む。アダプタ１７０は、サーバ１０５をグローバル通信ネットワーク１１０に接続するのに使用される。ブリッジ・ユニット１７５は、システム・バス１２０をローカル・バス１４０にインターフェースする。各マイクロプロセッサ１２５およびブリッジ・ユニット１７５は、情報を送るためにシステム・バス１２０へのアクセスを要求するマスタ・エージェントとして動作することができる。アービタ１８０は、システム・バス１２０への相互除外を有するアクセスの許可を管理する。
【００３５】
上で述べたサーバにアクセスする一般的ユーザの時間（ｔ）にまたがるアクティビティに関する例示的シナリオを、図２に示す。サーバによって提供されるサービスを現在活用している各（イネーブルされた）ユーザについて、対応する作業セッションが、接続ハンドルの割振りを伴って確立され、この接続ハンドルは、ユーザのコンテキスト情報にアクセスするのに使用される。ユーザは、一連のサービス要求（たとえば、特定のディジタル資産をアップロードし、検索し、またはダウンロードするため）をサブミットすることによってサーバと対話する。サーバは、各サービス要求を処理し（ユーザのコンテキスト情報を活用することによって。このコンテキスト情報は、その後、それ相応に更新される）、たとえば、これは、アップロードされたディジタル資産の格納、使用可能なディジタル資産の検索、または要求されたディジタル資産の取出（実行される動作のすべてについてユーザに請求する）を伴う。次に、サーバは、対応する応答をユーザに返し、通常、この応答は、アップロードの戻りコード、所望の検索を満足するディジタル資産のリスト、または選択されたディジタル資産からなる。ハンドルは、ユーザまたはサーバがセッションをクローズする時（たとえば、ユーザがすべての所望の情報を入手した後または出費限度に達した後）に、破棄される対応するコンテキスト情報と共に、解放される。どの場合でも、ハンドルは、ユーザが事前定義のタイムアウトＬｈ（１５〜３０分など）より長い期間の間にサーバと対話せずにインアクティブのままになる（すなわち、ハンドルが割り振られた後または以前のサービス要求に対する応答が受け取られた後に、サブミットされるサービス要求がない）時に、自動的に解放される。たとえば、この図は、それぞれ開始時刻Ｓ１〜Ｓ４から終了時刻Ｅ１〜Ｅ４まで続く４つのハンドルＨ１〜Ｈ４を示す。
【００３６】
サーバは、最大個数のハンドル（たとえば、数百個程度）を同時に管理することができ、このハンドルの最大個数に達した後には、さらなるハンドルを、サービスの活用を望む新しいユーザに割り振ることはできない。この図に示された非常に単純化された例で、ハンドルの最大個数が４つであると仮定すると、この限度には、時刻Ｓ４に達する。したがって、時刻Ｓ４の後の新しいユーザによるすべてのサービス要求は、拒否され、サーバは、ハンドルＨ１〜Ｈ４のうちの１つが解放されるまで、使用不能（新しいユーザにとって）のままになり、問題の例では、この使用不能時間Ｔｉは、時刻Ｅ２（ハンドルＨ２が解放される時）まで続く。
【００３７】
この問題を軽減するために、本発明の実施形態（次で詳細に説明する）による解決策では、サーバの特権使用が、各（アクティブ）ユーザに許可されるが、特権使用は、そのユーザによって行われたサーバの実際の使用に従って制限される。たとえば、この制限は、ユーザがサーバにサブミットされたサービス要求に対する応答を受け取るたびに減らされるクレジットによって定義される。クレジットは、ハンドルが使用可能ではない（その最大個数に達したので）時にサービスの活用のバランスをとるのに使用される。この場合に、サービス要求が、使い果たされていない対応するクレジットを有する新しいユーザによってサブミットされる場合に、サーバは、別のユーザに現在割り振られているハンドルの解放を強制し、この解放されたハンドルは、その後、新しいユーザ（そうでない場合に、その代わりに通常通りに拒否されるサービス要求を有する）に割り振られる。
【００３８】
上で述べた特権使用（ハンドルの解放を強制するための）は、サーバの可用性を大きく高め、その利益は、すべての情況で（たとえば、要求のピークの場合であっても）最大の可能な数の異なるユーザにその活用を保証しなければならないサービス（ＤＡＭタイプのサービスなど）で特に明白である。
【００３９】
しかし、この特権使用についてセットされた限度（経時的に減るクレジットによって）は、ハンドルの継続的解放によって引き起こされるはずの、サーバのすべての過度の過負荷を避ける。
【００４０】
言い換えると、提案される解決策は、サーバの高可用性およびサーバの低オーバーヘッドという対向する要件の間の優秀なトレードオフを提供する。
【００４１】
たとえば、図３に示されているように、ハンドルＨ１がユーザＵａに割り振られ、ハンドルＨ２がユーザＵｂに割り振られる状況を検討されたい。時刻ｔ１に、新しいユーザＵｃが、サービスの活用を開始するために接続要求をサブミットする。これに応答して、サーバは、ユーザＵｃのアイデンティティおよび彼／彼女の許可を検証するためにハンドシェーキング手順を実行し、このハンドシェーキング手順が成功すると仮定すると、ユーザＵｃは、サーバへの要求されたアクセスを許可される。
【００４２】
このために、サーバは、ユーザＵｃのための新しいアクセス・トークンＫｃを作成する。トークンＫｃは、プロファイルにアクセスするのに使用され、このプロファイルは、ハンドシェーキング手順中に収集されたユーザＵｃの個人データを格納する。プロファイルは、ユーザＵｃに割り当てられたクレジットＣｃの現在値をも含み、クレジットＣｃは、開始値Ｃｃ０（数十程度など）に初期化される。
【００４３】
サーバは、可能な場合に即座にトークンＫｃのハンドルを割り振る（対応するプロファイルに保存されるこの情報を用いて）。問題の状況では、ハンドルＨ３が使用可能であり、その結果、これをトークンＫｃに割り振ることができ、このために、このハンドルのコンテキスト情報は、トークンＫｃのプロファイルからロードされるユーザＵｃの個人データを用いて初期化される。この追加の特徴は、ハンドルを最初のサービス要求のために準備ができている状態にすることを試み、この最初のサービス要求は、サーバへのアクセスを許可されたばかりのユーザによって短い時間のうちにサブミットされる可能性が非常に高い。
【００４４】
ユーザＵｃがサーバにサービス要求をサブミットする時に、必ず、サービス要求は、ハンドルＨ３（彼／彼女のトークンＫｃに関連付けられる）によって処理され、ハンドルＨ３は、対応する応答をユーザＵｃに返し（問題の例では時刻ｔ２およびｔ３に）、ユーザＵｃへのすべての応答の返しは、対応するクレジットＣｃを１つ減らすことをも引きこす。その後、ハンドルＨ３は、時刻ｔ４に解放される。というのは、タイムアウトＬｈが、ユーザＵｃによるさらなるサービス要求のサブミッションなしに達するからである。しかし、ハンドルＨ３のコンテキスト情報は、破棄される前にトークンＫｃのプロファイルに保存される。その後、同一のハンドルＨ３が、さらなるユーザＵｄに割り振られる。
【００４５】
ハンドルのタイムアウト機構は、サーバでの競合の可能性を減らす。というのは、ハンドルが、もはや必要ではなくなった（たとえば、対応するユーザが、サーバから所望の応答のすべてを既に入手したが、セッションをクローズし忘れているので）時に解放されるからである。この形で、ハンドルの解放を強制するために上で述べた手順を実施する必要が、減る。
【００４６】
後に（時刻ｔ５に）、ユーザＵｃは、別のサービス要求をサーバにサブミットする。この場合に、ハンドルは、彼／彼女のトークンＫｃのために割り振られない。したがって、サーバは、トークンＫｃのためにハンドルを割り振ることを試み、問題の状況では、ハンドルＨ４が使用可能であり、その結果、これをトークンＫｃに割り振ることができる。このために、ユーザＵｃのコンテキスト情報が、トークンＫｃのプロファイルから再ロードされる。この形で、必要な情報が、即座に使用可能である（その収集に関するサーバの過負荷を全く伴わずに）。上と同様に、ユーザＵｃは、サービス要求をサブミットし、このサービス要求は、ハンドルＨ４によって処理され、対応する応答が、ユーザＵｃに返され（問題の例では時刻ｔ６、ｔ７、およびｔ８に）、それに従って減らされるクレジットＣｃを伴う。その後、ハンドルＨ４は、タイムアウトＬｈに達する時刻ｔ９に解放され、トークンＫｃのプロファイルに保存されるハンドルＨ４のコンテキスト情報を伴う。同一のハンドルＨ４が、その後、さらなるユーザＵｅに割り振られる。
【００４７】
この形で、トークンＫｃは、ハンドルＨ１〜Ｈ４から完全に結合解除される（異なるハンドルＨ１〜Ｈ４を経時的に同一のトークンＫｃについて使用できるので）。どの場合でも、トークンＫｃのプロファイルに保存されたコンテキスト情報（対応するハンドルの作成時にそのハンドルのためにロードされる）は、サーバにサブミットされる異なるサービス要求の間の連続性を提供する（これによって、ハンドシェーキング手順によってコンテキスト情報を再収集するためにその代わりに必要になるはずのスタートアップ・コストを回避する）。
【００４８】
後に（時刻ｔ１０に）、ユーザＵｃは、別のサービス要求をサーバにサブミットする。この場合にも、ハンドルは彼／彼女のトークンＫｃのためには割り振られないが、さらなるハンドルは、現在は使用可能ではない（４つという最大個数に既に達しているので）。それでも、クレジットＣｃが使い果たされてはいないので、ハンドルＨ１〜Ｈ４のうちの１つが、解放され、トークンＫｃに割り振られ、問題の例では、ハンドルＨ２（現在はユーザＵｂに割り振られている）が、解放され、トークンＫｃに割り振られる。
【００４９】
好ましくは、解放されるハンドルは、対応するユーザのクレジットに従って選択され、具体的に言うと、サーバは、そのユーザが最低のクレジットを有するハンドルを解放する。この追加の特徴は、サーバへのアクセスを許可されたばかりのユーザにペナルティを与えるのを回避する。
【００５０】
上と同様に、ユーザＵｃは、サービス要求をサブミットし、このサービス要求は、ハンドルＨ２によって処理され、対応する応答が、ユーザＵｃに返され（問題の例では時刻ｔ１１およびｔ１２に）、それに従って、時刻ｔ１２に０になるまで減らされるクレジットＣｃを伴う。その後、ハンドルＨ２は、タイムアウトＬｈに達する時刻ｔ１３に解放され、トークンＫｃのプロファイルに保存されるハンドルＨ２のコンテキスト情報を伴う。その後、同一のハンドルＨ２が、さらなるユーザＵｆに割り振られる。
【００５１】
後に（時刻ｔ１４に）、ユーザＵｃは、別のサービス要求をサーバにサブミットする。この場合にも、ハンドルは彼／彼女のトークンＫｃのためには割り振られず、さらなるハンドルは、使用可能ではない。しかし、クレジットＣｃは現在は使い果たされており、したがって、サーバによるサービス要求の処理は、この図の×によって示されるように、通常通り拒否される。
【００５２】
提案されるクレジットが、対応するユーザによるサーバへのアクセスをイネーブル／ディスエーブルするのに使用される（各ユーザが、彼／彼女のクレジットが使い果たされない場合に限ってサーバへのアクセスを許可される、当技術分野で既知のプリペイド・クレジットのように）のではないことは明白である。逆に、クレジットは、１つまたは複数のハンドルがまだ使用可能である（無料または任意の支払い技法によって制御されるのいずれかとすることができるサーバへのアクセスを伴って）時に、サーバには完全に不透明である。クレジットは、その代わりに、ハンドルが使用可能でない時に限ってサーバへのアクセスのバランスをとるために考慮に入れられる。
【００５３】
好ましくは、図面に示されているように、トークンＫｃは、通常はハンドルのタイムアウトＬｈよりはるかに長い（たとえば、数日程度）事前定義のタイムアウトＬｔの後に満了する。この場合に、トークンＫｃは、解放され、これは、対応するプロファイルの破棄と、それに関連するハンドル（存在する場合に）の解放とを伴う。このために、トークンＫｃの作成時刻を示すタイムスタンプをそのプロファイルに格納することが可能である。その後、トークンＫｃの満了の後にサブミットされるすべてのさらなるサービス要求は、拒否され、彼／彼女のアイデンティティおよび許可をもう一度検証するために上で説明したハンドシェーキング手順を繰り返すことおよびその後に同一ユーザＵｃの新しいトークンを作成することによってサーバに再アクセスすることを要求できるユーザＵｃを伴う。この追加の特徴は、提案される解決策のセキュリティを高める。というのは、これが、サーバへの許可されるアクセスを一時的に制限する（各ユーザの同一の検証について）からである。
【００５４】
図４に移ると、上で説明した解決策を実施するのに使用できる主ソフトウェア・コンポーネントが、全体として符号４００を用いて表されている。情報（プログラムおよびデータ）は、通常、ハード・ディスクに格納され、プログラムが動作しつつある時に、オペレーティング・システムおよび他のアプリケーション・プログラム（この図には図示せず）と一緒に、サーバの作業メモリにロードされる（少なくとも部分的に）。プログラムは、当初は、たとえばＣＤ−ＲＯＭから、ハード・ディスクにインストールされる。
【００５５】
詳細に言うと、ウェブ・サーバ４０５は、異なるユーザによって、対応するクライアントで動作するブラウザ（この図には図示せず）を介して、サーバと対話するのに使用される。具体的に言うと、ウェブ・サーバ４０５は、１つまたは複数のウェブ・アプリケーション４１０（問題の例ではＤＡＭタイプの）によって提供されるサービスの（接続／サービス）要求を受け取り、対応する応答を返す。
【００５６】
ウェブ・サーバ４０５は、ディスパッチャ４１５とインターフェースし、ディスパッチャ４１５は、サーバ上のすべてのセッションを管理する。このために、ディスパッチャ４１５は、リポジトリ４２０を制御し、リポジトリ４２０は、対応するコンテキスト情報と共に各割り振られたハンドルを格納する。ユーザ・データベース４２５は、サーバにアクセスすることを許可されたすべてのユーザの個人データを含むが、ディスパッチャ４１５によって、ハンドシェーキング手順中に各ユーザを検証するのに活用される。ディスパッチャ４１５は、さらなるリポジトリ４３０をも制御し、このリポジトリ４３０は、対応するプロファイルと共に使用中の各トークンを格納する。
【００５７】
ここで図５および６を検討すると、上で説明したシステムで実施できる（サーバへのアクセスを制御するために）例示的プロセスの論理フローが、方法５００を用いて表されている。この方法は、ブロック開始の円５０３で開始され、その後、いずれかのハンドルのタイムアウトＬｈが満了する時に、必ずブロック５０６に進む。たとえば、この結果は、ハンドルごとのカウンタによって達成され、このカウンタは、バックグラウンドで継続的に動作するが、ハンドルのサービス要求が対応するユーザによってサブミットされる時に必ずリセットされる。タイムアウトが満了する時に、ハンドルのコンテキスト情報は、ブロック５０９で、対応するトークンのプロファイルに保存される。その後、ハンドルは、ブロック５１０で解放される（破棄されるコンテキスト情報と共に）。
【００５８】
ブロック５１２を参照すると、この方法は、サーバが対応するアクセスをクローズする要求をユーザから受け取る（パラメータとしてトークンを渡すことによって）時に、必ず、ブロック５１５に進む。これに応答して、対応するプロファイル（存在する場合に）内のトークンに関連するハンドルが、そのコンテキスト情報を破棄することによって解放される。この方法は、ブロック５１６に進み、ここで、破棄される対応するプロファイルと共に、トークンを解放することができる。
【００５９】
ブロック５１８に移ると、サーバは、新しいユーザから接続要求を受け取る。その後、アクティビティの流れは、ブロック５２１に移り、ここで、ハンドシェーキング手順が、ユーザのアイデンティティおよび彼／彼女の許可を検証するために実行される。ハンドシェーキング手順が成功すると仮定すると、サーバは、ブロック５２２で、ユーザの新しいトークンを作成し、それと同時に、対応するクレジットが、開始値に初期化され、トークンのタイムスタンプは、現在時刻にセットされる。ブロック５２４に継続して、対応するプロファイルが、ユーザの個人データ（ハンドシェーキング手順中に収集される）を投入される。
【００６０】
次に、ブロック５２７でテストを実行して、いずれかのハンドルが使用可能である（その最大個数にまだ達していないので）かどうかを判定する。そうである場合には、ブロック５３０でトークンのためにハンドルを割り振る（対応するプロファイルに追加される割り振られたハンドルの表示と共に）。ブロック５３１に継続して、ハンドルのコンテキスト情報が、トークンのプロファイルからロードされるユーザの個人データを用いて初期化される。その後、この方法は、ブロック５３３に下り、同一の点に、ハンドルが使用可能でない時にブロック５２７からも直接に達する。
【００６１】
ブロック５３３で、サーバが、包括的ユーザからサービス要求を（割り当てられたトークンと一緒に）受け取るたびに、アクティビティのフローは、ブロック５３６に進み、このフェーズでは、サーバは、受け取られたトークンのプロファイルを取り出す。その後、トークンの作成から経過した時間（そのプロファイル内のタイムスタンプによって示される）が、ブロック５３７で、タイムアウトＬｔと比較される。今や、トークンの状況が、ブロック５３９で検証される。トークンが満了している（その作成から経過した時間がタイムアウトＬｔを超えるので）場合には、サーバは、ブロック５４０で、トークンを解放する（それに関連する可能なハンドルと一緒に）。その後、サービス要求が、ブロック５４２で拒否される（ユーザに返される対応するエラー・メッセージと共に）。この方法は、同心円の白／黒停止円５４５で終了する。
【００６２】
逆に、トークンが、まだ有効である時には、サーバは、ブロック５４８で、ハンドルがトークンに関連するかどうかを（そのプロファイルで示される）検証する。ハンドルが見つからない場合には、ブロック５５１でテストを行って、ハンドルの最大個数に達したかどうかを判定する。そうである場合には、サーバは、ブロック５５４で、トークンのプロファイルからユーザのクレジットを取り出す。次に、この方法は、ブロック５５７に継続し、ここで、サーバは、ユーザに残されているクレジットを検証する。クレジットが使い果たされている（すなわち、０以下である）場合には、サービス要求を、やはりブロック５４２で拒否する（停止の円５４５で終了するこの方法と共に）。
【００６３】
反対に（すなわち、クレジットが０を超える時に）、最低のクレジットを有するユーザに割り振られたハンドルが、ブロック５６０で選択される。好ましくは、この選択は、許可期間（タイムアウトＬｈより短い）より長いインアクティビティ時間を有するユーザに関連するハンドルに制限される。この許可時間は、まだアライブであるユーザの通常の最大インアクティビティ時間を表す。というのは、彼らが、まだサーバからすべての所望の応答を入手していない（その結果、さらなるサービス要求が、その後にサブミットされる可能性が高い）からである。たとえば、許可期間未満のインアクティビティ時間は、サブミットされるサービス要求の選択に、受け取られたディジタル資産の再生に、および類似物に対応する可能性がある。この特徴に関するさらなる詳細は、２００７年６月２６日に出願した同時係属の米国特許出願第ＥＰ０７１１１０６９．７号（その開示全体が、参照によって本明細書に組み込まれている）に見出すことができる。その後、ブロック５６１でテストを行って、ハンドルが見つかったかどうかを判定することができる。見つからない場合には、サービス要求を、やはりブロック５４２で拒否する（停止円５４５で終了するこの方法と共に）。逆に、選択されたハンドルのコンテキスト情報は、ブロック５６２で対応するトークンのプロファイルに保存される。その後、選択されたハンドルは、ブロック５６３で解放される（破棄されるそのコンテキスト情報と共に）。
【００６４】
アクティビティのフローは、今や、ブロック５６６に下り、同一の点に、１つまたは複数のハンドルがそれでも使用可能である（その最大個数にまだ達していないので）時にブロック５５１から直接にも達する。このフェーズでは、新しいハンドルが、トークンのために割り振られる（対応するプロファイルに追加される割り振られたハンドルの表示を伴って）。ブロック５６７に継続して、ハンドルのコンテキスト情報が、トークンのプロファイルから直接にロードされる。その後、この方法は、ブロック５６９に下る。戻ってブロック５４８を参照すると、ハンドルが既にトークンに関連付けられている時には、対応するコンテキスト情報が、ブロック５６８で取り出される。この場合にも、この方法は、その後、ブロック５６９に下る。
【００６５】
この点で、ユーザによってサブミットされたサービス要求が処理され、このために、サーバは、対応するハンドルのコンテキスト情報を活用し、このコンテキスト情報は、その後、それ相応に（必要な場合に）更新される。
【００６６】
アクティビティのフローは、その後、ブロック５７２で、サービス要求の結果に従って分岐する。サービス要求の処理が成功であった（ユーザに返される対応する結果を伴う）場合には、ユーザのクレジットを、ブロック５７５で、トークンのプロファイル内で減らす。その後、この方法は、停止円５４５で終了し、同一の点に、そうでない場合にブロック５７２からも直接に達する。
【００６７】
当然、ローカル要件および特定の要件を満足するために、当業者は、多数の論理的または物理的あるいはその両方の変更および代替案を上で説明した解決策に適用することができる。より具体的には、本発明を、その好ましい実施形態（１つまたは複数）を参照してある度合の詳細で説明したが、形態および詳細におけるさまざまな省略、置換、および変更ならびに他の実施形態が可能であることを理解されたい。具体的に言うと、提案される解決策は、そのより完全な理解を提供するために前の説明で示された特定の詳細（数値の例など）を用いずに実践することさえでき、逆に、周知の特徴が、不必要な詳細で説明を不明瞭にしないようにするために省略されまたは単純化された場合がある。さらに、本発明の任意の開示された実施形態に関して説明された特定の要素または方法あるいはその両方を、一般的な設計選択の問題として任意の他の実施形態に組み込むことができる。
【００６８】
具体的に言うと、提案された解決策は、同等の方法と共に実施されることに向いており（類似するステップの使用、本質的でない一部のステップの除去、またはさらなるオプションのステップの追加によって）、さらに、ステップを、異なる順序で、同時に、またはインターリーブされた形で（少なくとも部分的に）実行することができる。
【００６９】
前の説明で、クレジット（応答がユーザに返されるたびに減らされる整数値からなる）に言及したが、これは、限定的な形であることを意図されてはいない。たとえば、カウンタが、応答がユーザに返される回数について使用される場合に、同様の考慮があてはまり（カウンタが事前定義の値に達する時に使い果たされるクレジットと共に）、より一般的に、たとえば、処理されたサービス要求の個数（その結果と独立に）、接続時間、サービスの消費、および類似物に基づく、サーバの特権使用に関するすべての他の限度を考慮に入れることができる。さらに、提案されるクレジットは、無差別にすべてのユーザに、またはそのサブセットだけにのいずれかに許可され得る。
【００７０】
類似する考察が、最大個数のハンドルが別の形で（たとえば、１日の中で動的に変更する）定義される場合にあてはまる。しかし、提案される解決策は、異なるクリティカルな条件（使用可能なサーバを見つけるのに必要な時間が許容できる値を超える時、またはサービスの品質が保証される限度未満になる時など）の検出に応答して適用されることに向いている。
【００７１】
本発明の異なる実施形態（他のクリティカルな条件が検出される時）では、複数のハンドルの解放を強制する可能性が除外されない（さらなるサービス要求が、クレジットが使い果たされていないユーザから受け取られる時）。どの場合でも、解放されるハンドルは、対応するクレジットと独立でさえある、異なる判断基準に従って選択することができ、たとえば、最長のインアクティビティ時間を有するユーザに関連するハンドルを解放することが可能である。
【００７２】
本発明の代替実施態様では、ハンドルの強制解放を、無条件とすることができ、その結果、使い果たされていないクレジットを有する新しいユーザによってサブミットされるすべてのサービス要求が（ハンドルの最大個数に達した後に）、必ずサービスされるようになる。
【００７３】
提案される解決策を、ＳＯＡサービス（特にＤＡＭタイプのサービス）を参照して説明したが、これを限定的な形で解釈してはならない。実際に、類似する考慮が、他のＳＯＡサービス（たとえば、オンライン・インスタント・メッセージング・アプリケーション）にあてはまり、あるいは、任意の他のアーキテクチャに基づく（たとえば、ＣＯＲＢＡ仕様に準拠する）サービスにあてはまる。より一般的に、提案される解決策は、論理的または物理的あるいはその両方の利用側エンティティ（オペレーティング・システム、ソフトウェア・アプリケーション、ルータ、スイッチ、および類似物など）の何であれ、それによる任意の他の論理的または物理的あるいはその両方の共有リソース（ファイル、データベース、ディスク、プリンタ、スキャナ、および類似物など）ヘのアクセスの管理に適用されることに向いている。
【００７４】
同様に、任意の他のコンテキスト情報を使用して、任意の他の種類の作業セッションで要求されるサービスを提供することができる（その管理のための同等のハンドルを用いて）。どの場合でも、同一の解決策をステートレス・タイプのサービスに適用することを妨げるものはない。
【００７５】
さらに、異なる形で各ユーザの（イン）アクティビティを監視することが可能であり、たとえば、インアクティビティ時間を、別の形で（散在するサービス要求をフィルタリングすることによるなど）測定することができ、あるいは、これを、任意の類似するインジケータ（サーバへのアクセス全体の中でのユーザの増分インアクティビティ時間と等しいものなど）によって置換することができる。しかし、ハンドルの最大個数に達した後に他のユーザによって要求されなくなるまで、対応するユーザのアクティビティと独立に、割り振られる各ハンドルを維持することを妨げるものはない。
【００７６】
代替案では、ハンドルの強制される解放を、任意の他の形で条件付けることができる（たとえば、これを、新しいユーザのうちの１つより少ないクレジットを有するユーザに制限することによって）。
【００７７】
同様に、任意の他の手順を用いて（ユーザに彼／彼女の個人データを入力するように要求するなど）コンテキスト情報を収集することが可能であり、コンテキスト情報を、任意の同等の構造（分散タイプのものにさえ）に格納することができる。さらに、トークンを、サービスの活用を許可するための任意の同等の要素に置換することができる（たとえば、サーバ上でそれ相応に各許可されるユーザの識別子に単純にフラグを立てることによって）。同様に、プロファイルを、任意の同等の構造に置換することができ、あるいは、リアルタイムで対応するハンドルのコンテキスト情報と同期化されて（ハンドルが解放される時だけではなく）維持することができる。どの場合でも、ハンドルのレベルでのみ働く異なる実施態様は、除外されない。
【００７８】
新しいトークンごとに即座にハンドルを割り振る試みに関する特徴は、厳密に必要ではない。
【００７９】
本発明の代替実施形態では、トークンを、任意の他のポリシ（たとえば、サービスの消費が事前定義の限度に達する時）に従って解放することができ、どの場合でも、満了を全く伴わないトークンの使用は、特定の応用例で除外されない（たとえば、厳密なセキュリティ要件なしで）。
【００８０】
類似する考慮事項が、プログラム（本発明の各実施形態を実施するのに使用できる）が異なる形で構成される場合、または追加のモジュールもしくは機能が提供される場合にあてはまり、同様に、メモリ構造を、他のタイプとすることができ、あるいは、同等のエンティティ（必ずしも物理記憶媒体からなるのではない）と置換することができる。どの場合でも、プログラムは、外部または常駐のソフトウェア、ファームウェア、またはマイクロコード（オブジェクト・コード内またはたとえばコンパイルされるか解釈されるソース・コード内のいずれか）など、任意のデータ処理システムによってまたはこれに関連して使用されるのに適する任意の形とすることができる。さらに、任意のコンピュータ使用可能媒体上でプログラムを提供することができ、媒体は、プログラムを含み、格納し、通信し、伝搬し、または転送することに参加するのに適する任意の要素とすることができる。たとえば、媒体を、電子タイプ、磁気タイプ、光タイプ、電磁タイプ、赤外線タイプ、または半導体タイプとすることができ、そのような媒体の例は、固定ディスク（プログラムを事前にロードすることができる）、リムーバブル・ディスク、テープ、カード、ワイヤ、ファイバ、無線接続、ネットワーク、放送波、および類似物である。どの場合でも、本発明の実施形態による解決策は、ハードウェア構造（たとえば、半導体材料のチップに集積される）またはソフトウェアおよびハードウェアの組合せを用いて実施されるのに向いている。
【００８１】
さらに、提案されるサービスを、サービスのクラスタからなるものなど、任意の同等のサービス・プロバイダによって実施することができる。どの場合でも、本発明による解決策は、サービスベースではない古典的環境で適用されることにも向いている。
【００８２】
提案される方法を、異なるアーキテクチャを有するまたは同等のユニットを含む（たとえば、ローカル・ネットワークに基づく）システム上で実行することができる。さらに、各コンピュータは、類似する要素（実行中のマス・メモリへのアクセスを減らすためにプログラムまたはその諸部分を一時的に格納するキャッシュ・メモリなど）を含むことができ、どの場合でも、コンピュータを、任意のコード実行エンティティ（ＰＤＡ、携帯電話機、および類似物など）またはその組合せ（マルチティア・サーバ・アーキテクチャ、グリッド・コンピューティング・インフラストラクチャ、および類似物など）と置換することが可能である。
【図１】
2010539570.tif 000003
【図２】
2010539570.tif 000004
【図３】
2010539570.tif 000005
【図４】
2010539570.tif 000006
【図５】
2010539570.tif 000007
【図６】
2010539570.tif 000008
【手続補正書】
【提出日】平成22年3月31日(2010.3.31)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数の利用側エンティティによるデータ処理システム内の共有リソースへのアクセスの方法（５００）であって、
アクティブ・エンティティのセットの各１つに、前記共有リソースの特権使用に関する特権限度を関連付けるステップ（５１８〜５２４）と、
アクティブ・エンティティごとに使用インジケータを測定するステップ（５７５）であって、前記使用インジケータが、前記アクティブ・エンティティによる前記共有リソースの実際の使用を示す、ステップ（５７５）と、
前記アクティブ・エンティティの新しい１つによる前記共有リソースへのアクセスに関するアクセス要求を受け取るステップ（５３３）と、
前記共有リソースのクリティカル条件を判定するステップ（５３３、５５１）と、
前記新しいアクティブ・エンティティの前記使用インジケータを用いる前記クリティカル条件での前記アクセス要求が前記特権限度に達しないことに応答して前記共有リソースに現在アクセスしているイネーブルされたエンティティのセットのうちの少なくとも１つに与えられたアクセスを解放するステップ（５５４〜５６３）と、
前記アクセスを前記新しいアクティブ・エンティティに与えるステップ（５６６〜５６７）と
を含む方法（５００）。
【請求項２】
最大個数のアクセスが、前記共有リソースに対して同時に許可され、前記クリティカル条件を判定する前記ステップ（５３３、５５１）が、
アクセスの前記最大個数に達した後に前記アクセス要求を受け取ること（５３３）
を含む、請求項１に記載の方法（５００）。
【請求項３】
前記少なくとも１つのイネーブルされたエンティティに許可された前記アクセスを解放する前記ステップ（５５４〜５６３）が、
前記特権限度に最も近い対応する使用インジケータを有する前記イネーブルされたエンティティのうちの１つを選択すること（５６０）と、
前記選択されたイネーブルされたエンティティに許可された前記アクセスを解放すること（５６３）と、
を含む、請求項１または２に記載の方法（５００）。
【請求項４】
前記少なくとも１つのイネーブルされたエンティティに許可された前記アクセスの前記解放（５５４〜５６３）を解放する条件に条件付けるステップ（５６０〜５６１）
をさらに含む、請求項１ないし３のいずれかに記載の方法（５００）。
【請求項５】
前記共有リソースが、サービスを提供するように適合されたサーバを含み、各利用側エンティティが、前記サービスを活用するように適合されたクライアントを含み、各アクセス要求が、前記サービスを活用するためのサービス要求を含み、各イネーブルされたエンティティが、前記サービスを現在活用しているイネーブルされたクライアントを含み、作業セッションのハンドルが、各イネーブルされたクライアントに割り振られ、
前記新しいアクティブ・クライアントに前記アクセスを許可する前記ステップ（５６６〜５６７）が、対応する新しいハンドルを割り振ること（５６６）を含み、
前記少なくとも１つのイネーブルされたクライアントに許可された前記アクセスを解放する前記ステップ（５５４〜５６３）が、各対応するハンドルを解放すること（５６３）を含み、
前記方法が、さらに、前記新しいアクティブ・クライアントからの前記サービス要求の受取に応答して、
使用可能な場合に前記新しいアクティブ・クライアントに以前に割り振られたハンドルを使用するステップ（５６８）
を含む、請求項１ないし４のいずれかに記載の方法（５００）。
【請求項６】
各セッションが、前記サービスを活用する前記対応するイネーブルされたクライアントのコンテキスト情報の維持を含み、
前記新しいアクティブ・クライアントに前記アクセスを許可する前記ステップ（５６６〜５６７）が、さらに、前記対応するコンテキスト情報をロードすること（５６７）を含み、
前記少なくとも１つのイネーブルされたクライアントに許可された前記アクセスを解放する前記ステップ（５５４〜５６３）が、さらに、各対応するコンテキスト情報を破棄すること（５６３）を含む
請求項５に記載の方法（５００）。
【請求項７】
各イネーブルされたクライアントのアクティビティを監視するステップ（５０６）と、
前記対応するイネーブルされたクライアントのインアクティビティ・インジケータが第１しきい値に達する時に各ハンドルを解放するステップ（５０９〜５１０）と
をさらに含む、請求項５または６に記載の方法（５００）。
【請求項８】
前記少なくとも１つのイネーブルされたクライアントに許可された前記アクセス（５５４〜５６３）の前記解放を条件付ける前記ステップ（５６０〜５６１）が、
前記第１しきい値に先行する第２しきい値を超える前記インアクティビティ・インジケータを有する前記イネーブルされたクライアントに前記解放を制限すること（５６０）
を含む、請求項４に依存する時の請求項７に記載の方法（５００）。
【請求項９】
各アクティブ・クライアントに前記特権限度を関連付ける前記ステップ（５１８〜５２４）が、
前記アクティブ・クライアントによる前記サービスの活用の開始に関する接続要求を受け取ること（５１８）と、
前記アクティブ・クライアントの前記コンテキスト情報を収集すること（５２１）と、
前記サービスを活用するための前記アクティブ・クライアントの許可のためのトークンを作成すること（５２２）であって、前記トークンが、開始値に初期化された前記アクティブ・クライアントの前記特権限度に関連する、作成すること（５２２）と、
前記トークンに関連するプロファイルに前記アクティブ・クライアントの前記コンテキスト情報を格納すること（５２４）と
を含み、前記新しいアクティブ・クライアントに前記アクセスを許可する前記ステップ（５６６〜５６７）が、
前記対応するトークンを前記新しいハンドルに関連付けること（５６６）と、
前記対応するトークンの前記プロファイルから前記対応するコンテキスト情報を取り出すこと（５６７）と
を含み、前記少なくとも１つのイネーブルされたクライアントに許可された前記アクセスを解放する前記ステップ（５５４〜５６３）が、
前記対応するトークンの前記プロファイルに各対応するコンテキスト情報を保存すること（５６２）
を含む、請求項６ないし８のいずれかに記載の方法（５００）。
【請求項１０】
前記クリティカル状態にはない各アクティブ・クライアントへの前記特権限度の前記関連付け（５１８〜５２４）に応答して、
前記アクティブ・エンティティに前記アクセスを許可するステップ（５３０〜５３１）
をさらに含む、請求項９に記載の方法（５００）。
【請求項１１】
使用限度に達した後に前記トークンを解放するステップ（５４０）
をさらに含む、請求項９または１０に記載の方法（５００）。
【請求項１２】
請求項１ないし１１のいずれかに記載の方法（５００）を実施する、データ処理システム（１００）内で展開されるサービス（４００）。
【請求項１３】
データ処理システム（１０５）上で実行される時に、請求項１ないし１１のいずれかの方法（５００）の各ステップをコンピュータに実行させる、コンピュータ・プログラム（４００）。
【請求項１４】
請求項１ないし１１のいずれかに記載の方法（５００）のステップを実行する手段（４００）を含むシステム（１０５）。
【国際調査報告】
2010539570.tif 000009
2010539570.tif 000010
2010539570.tif 000011