(57)【要約】【課題】ルール・システムにてリソース・ベースのイベントをタイプ付けするコンピュータ実装可能な方法、システム、およびコンピュータ媒体を提供する。【解決手段】一実施形態では、コンピュータ実装可能な方法が、以下のステップ群を含む：イベント・タイプを、そのイベント・タイプに関連するリソース特性に従って定義するステップ；１つ以上のどのイベント・タイプがリソースにて発生し得るかを記述するリソース定義を作成するステップ；リソース定義をルール・システムに保存するステップ；データ処理システム内の特定のリソースから非同期データを受信するステップ；非同期データと、特定のリソース用のリソース定義に関連する特定のルールとを、互いに関係付けるステップ；特定のルールを非同期データに適用するステップ。【選択図】図４
2010505166.tif 000002
【特許請求の範囲】
【請求項１】
ルール・システムにてリソース・ベースのイベントをタイプ付けするコンピュータ実装可能な方法であって、前記コンピュータ実装可能な方法が、
イベント・タイプを、前記イベント・タイプに関連するリソース特性に従って、定義するステップと、
１つ以上のどのイベント・タイプがリソースにて発生し得るかを記述するリソース定義を作成するステップと、
前記リソース定義を前記ルール・システムに保存するステップと、
前記データ処理システム内の特定のリソースから非同期データを受信するステップと、
前記非同期データと、前記特定のリソース用のリソース定義に関連する特定のルールとを、互いに関係付けるステップと、
前記特定のルールを前記非同期データに適用するステップと、
を含む、コンピュータ実装可能な方法。
【請求項２】
前記リソース定義が、さらに、前記リソースから前記ルール・システムによってどのような特性データをプルすることができるかを記述する、請求項１に記載のコンピュータ実装可能な方法。
【請求項３】
前記ルール・システム内のルール論理が、前記特定のルールに従って前記非同期データを操作して出力を生成し、前記コンピュータ実装可能な方法が、前記特定のルールの前記出力を前記特定のリソースへ送信するステップをさらに含む、請求項１に記載のコンピュータ実装可能な方法。
【請求項４】
前記特定のリソースによる使用が認められている複数のルールから、前記特定のルールを選択するステップをさらに含む、請求項１に記載のコンピュータ実装可能な方法。
【請求項５】
前記複数のルールの各々を、同期データまたは非同期データのいずれかに対して適用可能なものとして定義するステップであって、前記同期データは特定のルールを求める要求を含み、前記非同期データは、受信されたデータの適用対象となる特定のルールを指定しない、前記定義するステップと、
前記ルール・システムによって受信されたデータが、同期であるか非同期であるかを判断するステップと、
前記ルール・システムによって受信された前記データは非同期であるという判断に応えて、入力として非同期データを用いるルールのみを探して前記ルール・システムを検索するステップと、
をさらに含む、請求項４に記載のコンピュータ実装可能な方法。
【請求項６】
前記ルール・システムが、前記データ処理システム内の少なくとも１つのリソースを管理するリソース・マネージャの一部である、請求項１に記載のコンピュータ実装可能な方法。
【請求項７】
プロセッサと、
前記プロセッサに接続されたデータ・バスと、
前記データ・バスに接続されたメモリと、
コンピュータ・プログラム・コードを具現化している、コンピュータが使用可能な媒体と、
を含むシステムであって、前記コンピュータ・プログラム・コードが命令を含み、前記命令は、前記プロセッサによって実行可能であり、かつ以下のこと：
イベント・タイプを、前記イベント・タイプに関連するリソース特性に従って定義すること；
１つ以上のどのイベント・タイプがリソースにて発生し得るかを記述するリソース定義を作成すること；
前記リソース定義をルール・システムに保存すること；
データ処理システム内の特定のリソースから非同期データを受信すること；
前記非同期データと、前記特定のリソース用のリソース定義に関連する特定のルールとを、互いに関係付けること；
前記特定のルールを前記非同期データに適用すること、
を行うように構成されている、システム。
【請求項８】
前記リソース定義が、さらに、前記リソースから前記ルール・システムによってどのような特性データをプルすることができるかを記述する、請求項７に記載のシステム。
【請求項９】
前記ルール・システム内のルール論理が、前記特定のルールに従って前記非同期データを操作して出力を生成し、前記命令が、さらに、前記特定のルールの前記出力を前記特定のリソースへ送信するように構成されている、請求項７に記載のシステム。
【請求項１０】
前記命令が、さらに、前記特定のリソースによる使用が認められている複数のルールから前記特定のルールを選択するように構成されている、請求項７に記載のシステム。
【請求項１１】
前記命令が、さらに以下のこと：
前記複数のルールの各々を、同期データまたは非同期データのいずれかに対して適用可能なものとして定義することであって、前記同期データは特定のルールを求める要求を含み、前記非同期データは、受信されたデータの適用対象となる特定のルールを指定しない、前記定義すること；
前記ルール・システムによって受信されたデータが、同期であるか非同期であるかを判断すること；
前記ルール・システムによって受信された前記データは非同期であるという判断に応えて、入力として非同期データを用いるルールのみを探して前記ルール・システムを検索すること、
を行うように構成されている、請求項１０に記載のシステム。
【請求項１２】
前記ルール・システムが、前記データ処理システム内の少なくとも１つのリソースを管理するリソース・マネージャの一部である、請求項７に記載のシステム。
【請求項１３】
コンピュータ・プログラム・コードを具現化している、コンピュータが使用可能な媒体であって、前記コンピュータ・プログラム・コードが、コンピュータ実行可能な命令を含み、前記命令は、以下のこと：
イベント・タイプを、前記イベント・タイプに関連するリソース特性に従って定義すること；
１つ以上のどのイベント・タイプがリソースにて発生し得るかを記述するリソース定義を作成すること；
前記リソース定義をルール・システムに保存すること；
データ処理システム内の特定のリソースから非同期データを受信すること；
前記非同期データと、前記特定のリソース用のリソース定義に関連する特定のルールとを、互いに関係付けること；
前記特定のルールを前記非同期データに適用すること、
を行うように構成されている、コンピュータが使用可能な媒体。
【請求項１４】
前記リソース定義が、さらに、前記リソースから前記ルール・システムによってどのような特性データをプルすることができるかを記述する、請求項１３に記載のコンピュータが使用可能な媒体。
【請求項１５】
前記ルール・システム内のルール論理が、前記特定のルールに従って前記非同期データを操作して出力を生成し、前記コンピュータ実行可能な命令が、さらに、前記特定のルールの前記出力を前記特定のリソースへ送信するように構成されている、請求項１３に記載のコンピュータが使用可能な媒体。
【請求項１６】
前記コンピュータ実行可能な命令が、さらに、前記特定のリソースによる使用が認められている複数のルールから前記特定のルールを選択するように構成されている、請求項１３に記載のコンピュータが使用可能な媒体。
【請求項１７】
前記コンピュータ実行可能な命令が、さらに以下のこと：
前記複数のルールの各々を、同期データまたは非同期データのいずれかに対して適用可能なものとして定義することであって、前記同期データは特定のルールを求める要求を含み、前記非同期データは、受信されたデータの適用対象となる特定のルールを指定しない、前記定義すること；
前記ルール・システムによって受信されたデータが、同期であるか非同期であるかを判断すること；
前記ルール・システムによって受信された前記データは非同期であるという判断に応えて、入力として非同期データを用いるルールのみを探して前記ルール・システムを検索すること、
を行うように構成されている、請求項１６に記載のコンピュータが使用可能な媒体。
【請求項１８】
前記ルール・システムが、前記データ処理システム内の少なくとも１つのリソースを管理するリソース・マネージャの一部である、請求項１３に記載のコンピュータが使用可能な媒体。
【請求項１９】
前記コンピュータが使用可能な媒体が、リモート・サーバのコンポーネントであり、前記コンピュータ実行可能な命令が、前記リモート・サーバからクライアント・コンピュータへデプロイ可能である、請求項１３に記載のコンピュータが使用可能な媒体。
【請求項２０】
前記コンピュータ実行可能な命令が、サービス・プロバイダによって顧客へオンデマンド・ベースで提供されることが可能である、請求項１３に記載のコンピュータが使用可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的に、ハードウェア、ソフトウェアおよびプロセッサを含む、コンピュータおよびその他のデータ処理システムの分野に関する。特に、本発明は、リソース・ベースのルールを用いてデータ処理システムのリソースを管理することに関する。
【背景技術】
【０００２】
コンピュータ・システムは、システムの一部として多数のリソースを有することができる。これらのリソースには、ハードウェア（クライアント・コンピュータ、サーバ、プリンタ、ストレージ・デバイスなど）、ならびにソフトウェア（オペレーティング・システム、アプリケーションなど）の双方が含まれる。このようなリソースは、多くの場合、ルール・システムなどを含み得る中央論理による技術支援を受けている。ルール・システムのルールは、「プル」または「プッシュ」のいずれかによって利用することができる。
【０００３】
「プル」の例として、図１を考察する。リソース１０２が、ルール・システム１０４によって支援されており、ルール・システムには、ルール・データベース１０８と相互に作用するルール論理１０６が含まれる。例示のために、リソース１０２はサーバであると仮定する。リソース１０２は、リソース１０２の中央処理装置（ＣＰＵ：Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１０の管理のやり方に関するルールがルール・システム１０４のルール・データベース１０８にあることを「知っている」が、その一方でリソース１０２は、ＣＰＵ１１０の正確な管理のやり方を「知らない」。従って、リソース１０２は、「プル」ルール・コールをルール・システム１０４へ送信し（ステップ１）、ＣＰＵ１１０を管理するのに適切なルールを処理するようルール・システム１０４に依頼する。ルール・システム１０４は、ウェブ・サービス記述言語（ＷＳＤＬ：Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）などの記述言語を使用して、上記の要求されたルールを処理するのにリソース１０２からどのようなデータを「プルする」ことが可能であるかを理解する。次にルール・システム１０４が、そのデータをリソース１０２に要求し（言い換えれば、「プルする」−ステップ２）、結果的に、リソース１０２が、ルールに適切な入力データを送信することになる（ステップ３）。ルール・システム１０４は、その後、ルール論理１０６を使って入力データを適切なルールへ適用し、結果のデータをリソース１０２へ出力する（ステップ４）。
【０００４】
次に、図１での例示のために、「連続した３つのサンプリングに対してＣＰＵ使用率が７０％を超過する場合、優先度の低いソフトウェア処理は無効にする」と述べるルールがルール・データベース１０８にあると仮定する。実際にＣＰＵ１１０にて、連続した３つのサンプリングに対してＣＰＵ使用率が７０％を超過したら、ステップ１乃至４の実行後、優先度の低い処理を無効にし、それらがＣＰＵ１１０の容量を全く使えないようにする。
【０００５】
上述の例は、単なる例示に過ぎない。具体的に言えば、上記のようなルールは、ソフトウェア・リソースにも適用可能である。言い換えれば、リソース１０２の例を、上述のサーバではなく、実際にはソフトウェア・プログラムであるものとして考察する。このソフトウェア・プログラムは、或る特定の注文に対して割引の価格設定を行うべきであることを「知っている」と考えられるが、そのような割引をいつ行うのか、あるいはいくらの場合に行うのかという詳細については何も「知らない」。従って、リソース１０２は、価格設定についてのルールを求める要求をルール・システム１０４へ送信し（ステップ１）、ルール・システムは、（ＷＳＤＬを使い、どのようなデータをプルすることが可能かを判断して）その注文の規模に関するデータをプルする（ステップ２）。次いでリソース１０２は、ステップ３に示すように、注文の規模（例えば、金額）を返答する。ルール・システム１０４は、その後、その注文はいくら割引されるべきであるのかを返答する（ステップ４）。
【０００６】
ルール利用のもう１つのタイプは、「プッシュ」システムとして知られている。「プッシュ」は、同期式または非同期式の場合がある。まず図２に示す「同期式プッシュ」を考察する。このシナリオでは、リソース１０２は、（ルール・データベース１０８の提供する）どのルールが必要であるのかを「知っている」だけではなく、さらに、必要なルールのためにはどの入力パラメータが必要とされるのかをも知っている。従って、リソース１０２は、ルール・データベース１０８にある特定のルールを求める要求のほかに、必要な入力データも同時に送信する（ステップ１）。次にルール・システム１０４が、ルール論理１０６を使って、受信した入力データを、ルール・データベース１０８の提供する、要求されたルールへ適用して、（入力データの特定のルールへの適用により生じる）出力データを、リソース１０２へ送信する（ステップ２）。なお、図１および図２に示すシステムは類似しているが、図１では、ルール・システム１０４が、後から再びリソース１０２に向かって追加的な情報を求めている（図１にて「値を求めてプル」に示す）ことに留意されたい。
【０００７】
図１および図２は相違する「プル」システムおよび「同期式プッシュ」システムを示しているが、図１乃至２で説明されているシステムはどちらも、ルール・エンジンがデータを求めてリソースへ問い合わせを行うことを可能にしている。しかし、「非同期式プッシュ」システムは、これが当てはまらない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
図３には、そのような「非同期式プッシュ」が示されており、この場合、特定のルールを求める要求を待たずに、データがルール・システム１０４へプッシュされる。残念なことに、コンピュータ・システムではこのシナリオがよく見られる。言い換えれば、リソース１０２は、ルール・システム１０４を含み得る中央マネージャへ、多種多様なイベント・データを機械的に送信する。例えばリソース１０２がサーバである場合、イベント・データは、外部気温、ＣＰＵ使用率、ページ切り替え、現地時刻、クロック速度、ログオンしているユーザ数などといった共通点のないアイテム群に関するものとなり得る。この中央マネージャおよびその関連ルール・システム１０４は、受信したイベント・データの処理方法を「知らない」。より具体的に言えば、ルール・システム１０４は、受信した非同期データに関し、ルール・データベース１０８にあるどのルールが適切であるのかを知らない。
【課題を解決するための手段】
【０００９】
上述の非同期式データ・プッシュに対処するべく、本発明は、ルール・システムにてリソース・ベースのイベントをタイプ付けするコンピュータ実装可能な方法、システムおよびコンピュータ媒体を提示する。一実施形態では、コンピュータ実装可能な方法が、以下のステップ群を含む：イベント・タイプを、そのイベント・タイプに関連するリソース特性に従って定義するステップ；１つ以上のどのイベント・タイプがリソースにて発生し得るかを記述するリソース定義を作成するステップ；リソース定義をルール・システムへ保存するステップ；データ処理システム内の特定のリソースから非同期データを受信するステップ；非同期データと、特定のリソース用のリソース定義に関連する特定のルールとを、互いに関係付けるステップ；特定のルールを非同期データへ適用するステップ。
【００１０】
ここで、本発明を、ほんの一例として添付の図面に関連して説明する。
【発明を実施するための最良の形態】
【００１１】
ここで図４を参照すると、リソース：イベント・マッピング論理（ＲＥＭＬ：Ｒｅｓｏｕｒｃｅ：Ｅｖｅｎｔ  Ｍａｐｐｉｎｇ  Ｌｏｇｉｃ）２１２の例示的な利用が提示されている。リソース２０２が、ルール・システム２０４へデータをプッシュする。リソース２０２がサーバなどのハードウェア・リソースである場合、データは、ＣＰＵ使用率、ページ切り替え速度、メモリ・リーク・レベル（ローカル動的メモリに保存されている不要なデータが原因で使用不可能になっている、ローカル動的メモリ量）などとすればよい。同様に、リソース２０２がソフトウェア・リソースである場合、ルール・システム２０４へプッシュされるデータは、ソフトウェアによる実行に向けてキー入力されたデータ値、ソフトウェアの現在のユーザ数、ソフトウェアの実行速度、データ要求の頻度（リソース２０２がデータベースである場合）などとすればよい。ルール・システム２０４がリソース２０２からデータを受信するとき、ＲＥＭＬ２１２は、（特定のポートのモニタリング、またはデータ・パケット・ヘッダの構文解析などにより）データが特定のリソース２０２から来たことと、（ルール・システム２０４に保存されている、特定のリソース２０２用の定義により、またはデータ・パケット・ヘッダの構文解析により）データが同期であるか非同期であるかということと、（ＲＥＭＬ２１２が利用可能な、図示しないマッピング・テーブルによる定義に従って）そのタイプのデータに関してその特定のリソース２０２がルール・データベース２０８内のどのルールを使用可能であるかということと、を「知っている」。
【００１２】
例えば、リソース２０２が、自身のＣＰＵ２１０の使用率を機械的に送信しているサーバであると仮定する。これらの使用率測定値データがルール・システム２０４へ到着すると（ステップ１）、ＲＥＭＬ２１２が、特定のリソース２０２に関して、ルール・データベース２０８からどのルール（単数または複数）をコールするべきかを判断する。この判断は、（図５にてさらに詳細に説明するように）リソース２０２用のリソース定義とリソース２０２から受信したデータのタイプに適切なイベント・ルールとを互いに関係付ける、ＲＥＭＬ２１２内の論理によって下される。次にステップ２に示すように、ＲＥＭＬ２１２は、受信した使用率測定値データに加えて、ルール・データベース２０８から特定のルールをコールしその適切なルールへ上記の受信した使用率測定値データを入力させるための指示を、ルール論理２０６に対して送信する（ステップ３）。その後、適切なルールによって、そのルールからの出力がリソース２０２へ送信される（ステップ４）。（なお、ルールは、「もし」の条件が満たされるか否かに応じて、データを出力してもしなくてもよい。言い換えれば、大部分のルールは、「もし」特定のリソース２０２から、ルール・システム２０４内の、その特定のリソース２０２に対応するルールに関して適切な入力データを受信した場合に限り、データを出力する。）このように、さらに大きいリソース・マネージャ２１４の一部であり得るルール・システム２０４が、必要なルールを割り当てるために、リソース２０２からの多数のデータを評価しフィルタにかけることが可能になる。なお、ＲＥＭＬ２１２は、リソース・マネージャ２１４内のルール・システム２０４の一部として説明され提示されているが、当然のことながら、ＲＥＭＬ２１２は、本明細書に記載のプロセスを実行するルール論理の例示的な説明／提示である。故に、本発明の実施形態は、ルール・システム２０４の内部で名付けられ限定された論理に制限されるものではなく、むしろ本明細書に記載の諸目的のためにルール・システム２０４によって利用しやすい論理として理解される。
【００１３】
ここで図５を参照すると、ＲＥＭＬ２１２の作成および利用の仕方についてさらなる詳細が提示されている。開始ブロック２１６に続き、イベント・デザイナがイベント・タイプに名前を付け、各イベント・タイプにどのような特性を持たせるかを決定する（ブロック２１８）。例として、「サーバ状態を記述するデータを出力する」というようなイベントを考察する。イベント・デザイナは、このイベントに「サーバ状態」という名前を付け、次いで「サーバ状態」に関連するデータを定義すればよい。このようなデータとしては、そのサーバ・リソース２０２に関するＣＰＵ使用率、ページ切り替え速度、プロセッサ温度、ログオンしているユーザ数などが挙げられる。
【００１４】
ブロック２２０に示すように、リソース・デファイナが、リソースにてどのようなイベント・タイプが発生し得るか、ならびにルール・システム２０４によってそのリソース２０２から（例えば、ＷＳＤＬ、すなわちこれの拡張子を用いて）どのような特性がプルされ得るかを記述するリソース定義を作成する。上記のイベント・タイプがリソース２０２からデータを呼び出す場合もあり、このことは（上述の定義の通り）プル、同期式プッシュ、または非同期式プッシュに分類することができる。例示のために、引き続きリソース２０２はサーバであると仮定する。リソース定義には、上述の例の「サーバ状態」など、どのようなイベントがリソース２０２にて発生し得るかということが含まれる。言い換えれば、リソース２０２が「サーバ状態を記述するデータを出力する」イベントなどの１つ以上のイベントを経験できるようにするとよい。従ってこの能力が、リソース定義に記述される。リソース定義は、さらに、そのリソース２０２からどのような特性がプルされ得るかということも記述する。こうした特性には、特定のイベント・タイプに関連する全ての特性を含めても含めなくてもよい。言い換えれば、リソース定義が、サーバ・リソース２０２は「サーバ状態を記述するデータを出力する」イベントを経験することができると述べていたとしても、「サーバ状態」に記述されたデータ（ブロック２１８に関連して上述）の一部のみを、サーバ・リソース２０２から入手可能としてもよい。それでもなお、「サーバ状態」に記述されたデータの一部分のみでも、データ送信元のリソース２０２に関してＲＥＭＬ２１２によるルールのコールおよび実行を引き起こすのに十分なものとすることができる。
【００１５】
リソース・デファイナ（イベント・デザイナと同様に、人、あるいはハードウェア／ソフトウェア論理のインテリジェント部分とすればよい）によってリソース定義が作成されたら、ブロック２２２に示すように、ルール・システム２０４が、リソース定義をＲＥＭＬ２１２へロードし、その後、非同期データが受信されるのを待つ（問い合わせブロック２２４）。このデータをリソース２０２から受信したら、次にＲＥＭＬ２１２は、受信したデータ（リソース・パラメータ）と、１つ以上の適切なルールとを、互いに関係付ける（ブロック２２６）。例えば、受信データが特定のサーバにおけるＣＰＵ使用率を記述しているとＲＥＭＬ２１２が判断した場合、ＲＥＭＬ２１２は、ルール・データベース２０８から得る特定のルールは、このＣＰＵ使用率の評価に使用されるべきものであることを「知っている」。なお、ＲＥＭＬ２１２は、どのルールが同期式イベント用であって、どのルールが非同期式イベント用であるかということも知っているとよい。一実施形態では、ＲＥＭＬ２１２が、イベント・タイプの定義に含まれているパラメータによって、どのルールが同期式イベント用／非同期式イベント用であるかを「知っている」。故に、（上述のように）非同期データが受信された場合には、非同期式のイベント・ルールのみを適用するように評価し、ひいては最適化されたルール処理が可能になる。
【００１６】
その後、ルール論理２０６による使用に向けて、ＲＥＭＬ２１２によって適切なルールがコールされる（ブロック２２８）。適切なルールは、受信したデータに適用され、結果として生じる出力データ（コールされたルールにおいて受信したデータが「もし」の条件を満たすか否かに応じて、何らかの出力データがある場合）は、リソースへ送信される（ブロック２３０）。プロセスは、終了ブロック２３２にて終わる。
【００１７】
ここで図６を参照すると、本発明の実施形態を利用するとよい、例示的なクライアント・コンピュータ３０２のブロック図が示されている。クライアント・コンピュータ３０２は、システム・バス３０６に接続されているプロセッサ・ユニット３０４を含む。システム・バス３０６には、ディスプレイ３１０を駆動／支援するビデオ・アダプタ３０８も接続されている。システム・バス３０６は、バス・ブリッジ３１２を介して、入力／出力（Ｉ／Ｏ：Ｉｍｐｕｔ／Ｏｕｔｐｕｔ）バス３１４に接続されている。Ｉ／Ｏバス３１４には、Ｉ／Ｏインターフェース３１６が接続されている。Ｉ／Ｏインターフェース３１６は、キーボード３１８、マウス３２０、コンパクト・ディスク−読み取り専用メモリ（ＣＤ−ＲＯＭ：Ｃｏｍｐａｃｔ  Ｄｉｓｋ−Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）ドライブ３２２、フレキシブル・ディスク・ドライブ３２４、フラッシュ・ドライブ・メモリ３２６などの多様なＩ／Ｏデバイスとの通信を提供する。Ｉ／Ｏインターフェース３１６に接続されるポートの形式は、コンピュータ・アーキテクチャ分野の当業者に周知の形式であればいかなる形式であってもよく、ユニバーサル・シリアル・バス（ＵＳＢ：Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）ポートを含むがこれに限定されない。
【００１８】
クライアント・コンピュータ３０２は、システム・バス３０６に接続されたネットワーク・インターフェース３３０を用いネットワーク３２８を介して、サービス・プロバイダ・サーバ４０２と通信することができる。ネットワーク３２８は、インターネットなどの外部ネットワークであってもよいし、またはＥｔｈｅｒｎｅｔ（Ｒ）もしくは仮想プライベート・ネットワーク（ＶＰＮ：Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）などの内部ネットワークであってもよい。ネットワーク３２８を使用することにより、クライアント・コンピュータ３０２は、本発明の実施形態を用いてサービス・プロバイダ・サーバ４０２にアクセスすることができる。
【００１９】
システム・バス３０６には、ハード・ドライブ・インターフェース３３２も接続されている。ハード・ドライブ・インターフェース３３２は、ハード・ドライブ３３４と接続して機能する。好適な一実施形態では、ハード・ドライブ３３４は、同様にシステム・バス３０６に接続されているシステム・メモリ３３６を実装する。システム・メモリは、クライアント・コンピュータ３０２において、揮発性メモリの最下位レベルとして定義される。この揮発性メモリには、揮発性メモリの追加的な上位レベル（図示せず）を含めることもでき、これにはキャッシュ・メモリ、レジスタ、バッファなどが含まれるがこれらに限定されない。システム・メモリ３３６にポピュレートするデータとしては、クライアント・コンピュータ３０２のオペレーティング・システム（ＯＳ：ｏｐｅｒａｔｉｎｇ  ｓｙｓｔｅｍ）３３８およびアプリケーション・プログラム３４４がある。
【００２０】
ＯＳ３３８は、アプリケーション・プログラム３４４などのリソースへの透過的なユーザ・アクセスを提供する、シェル３４０を含む。一般に、シェル３４０は、ユーザとオペレーティング・システムとの間のインタープリタおよびインターフェースを提供するプログラムである。より具体的には、シェル３４０は、コマンド・ライン・ユーザ・インターフェースに入力されたか、またはファイルから得られたコマンドを実行する。それ故に、Ｗｉｎｄｏｗｓ（Ｒ）ではコマンド・プロセッサとも称されるシェル３４０（ＵＮＩＸ（Ｒ）にてこう称される）は、一般に、オペレーティング・システムのソフトウェア階層構造の最上位レベルであり、コマンド・インタープリタとして機能する。シェルは、システム・プロンプトを提供し、キーボード、マウスまたは他のユーザ入力媒体によって入力されたコマンドを解釈して、解釈後のコマンド（単数または複数）をオペレーティング・システムの適切な下位レベル（例えば、カーネル３４２）へ処理のために送信する。なお、シェル３４０はテキストベース、ライン指向のユーザ・インターフェースであるが、その一方で、本発明の実施形態は、グラフィカル、音声、ジェスチャなど他のユーザ・インターフェース・モードにも同様に申し分なく対応する。
【００２１】
図に示すように、ＯＳ３３８は、さらにカーネル３４２を含み、カーネルには、ＯＳ３３８の機能性の低位レベルが備わっており、例えば、メモリ管理、プロセスおよびタスク管理、ディスク管理、マウスおよびキーボード管理など、ＯＳ３３８の別の部分およびアプリケーション・プログラム３４４によって要求される必要不可欠なサービスを提供することなどを含む。
【００２２】
アプリケーション・プログラム３４４は、ブラウザ３４６を含む。ブラウザ３４６は、ワールド・ワイド・ウェブ（ＷＷＷ：Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）クライアント（言い換えれば、クライアント・コンピュータ３０２）が、ハイパーテキスト転送プロトコル（ＨＴＴＰ：ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）メッセージングを用いてインターネットに対してネットワーク・メッセージを送受信できるようにし、ひいてはサービス・プロバイダ・サーバ４０２と通信できるようにする、プログラム・モジュールおよびプログラム命令を含む。
【００２３】
クライアント・コンピュータ３０２のシステム・メモリ内のアプリケーション・プログラム３４４は、さらに、図４乃至５に記載したプロセスを実現するためのコードを有するリソース・ベースのイベントタイプ付け用プログラム（ＲＢＥＴＰ：Ｒｅｓｏｕｒｃｅ−Ｂａｓｅｄ  Ｅｖｅｎｔ  Ｔｙｐｉｎｇ  Ｐｒｏｇｒａｍ）３４８を含む。一実施形態では、クライアント・コンピュータ３０２が、ＲＢＥＴＰ３４８をサービス・プロバイダ・サーバ４０２からダウンロードすることができる。
【００２４】
クライアント・コンピュータ３０２内に図示するハードウェア要素は、網羅的であることを意図するものではなく、むしろ本発明の実施形態に必要な基本的なコンポーネントを強調するための代表的なものである。例えば、クライアント・コンピュータ３０２には、磁気カセット、デジタル多用途ディスク（ＤＶＤ：Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）、Ｂｅｒｎｏｕｌｌｉカートリッジなどといった他のメモリ・ストレージ・デバイスを含めてもよい。
【００２５】
上記のように、ＲＢＥＴＰ３４８は、図７に例示的な形で示すサービス・プロバイダ・サーバ４０２からクライアント・コンピュータ３０２へダウンロードすることができる。サービス・プロバイダ・サーバ４０２は、システム・バス４０６に接続されているプロセッサ・ユニット４０４を含む。システム・バス４０６には、ビデオ・アダプタ４０８も接続されている。ビデオ・アダプタ４０８は、ディスプレイ４１０を駆動／支援する。システム・バス４０６は、バス・ブリッジ４１２を介して入力／出力（Ｉ／Ｏ）バス４１４に接続されている。Ｉ／Ｏバス４１４には、Ｉ／Ｏインターフェース４１６が接続されている。Ｉ／Ｏインターフェース４１６は、キーボード４１８、マウス４２０、コンパクト・ディスク−読み取り専用メモリ（ＣＤ−ＲＯＭ）ドライブ４２２、フレキシブル・ディスク・ドライブ４２４、フラッシュ・ドライブ・メモリ４２６などの多様なＩ／Ｏデバイスとの通信を提供する。Ｉ／Ｏインターフェース４１６に接続されるポートの形式は、コンピュータ・アーキテクチャ分野の当業者に周知の形式であればいかなる形式であってもよく、ユニバーサル・シリアル・バス（ＵＳＢ）ポートを含むがこれに限定されない。
【００２６】
サービス・プロバイダ・サーバ４０２は、システム・バス４０６に接続されたネットワーク・インターフェース４３０を用いネットワーク３２８を介して、クライアント・コンピュータ３０２と通信することができる。ネットワーク３２８へアクセスすることにより、サービス・プロバイダ・サーバ４０２は、ＲＢＥＴＰ３４８の実行またはクライアント・コンピュータ３０２へのダウンロードあるいはその両方を行うことが可能になる。
【００２７】
システム・バス４０６には、さらに、ハード・ドライブ４３４と接続して機能するハード・ドライブ・インターフェース４３２も接続されている。好適な一実施形態では、ハード・ドライブ４３４は、同様にシステム・バス４０６に接続されているシステム・メモリ４３６を実装する。システム・メモリ４３６にポピュレートするデータとしては、サービス・プロバイダ・サーバ４０２のオペレーティング・システム４３８があり、オペレーティング・システムは、シェル４４０およびカーネル４４２を含む。シェル４４０は、上位レベルのオペレーティング・システム層に組み込まれており、ブラウザ４４６を含むアプリケーション・プログラム４４４などのリソース、およびクライアント・コンピュータ３０２へデプロイ可能な上述のＲＢＥＴＰ３４８のコピーへの、透過的なユーザ・アクセスを提供するのに利用される。
【００２８】
サービス・プロバイダ・サーバ４０２内に図示するハードウェア要素は、網羅的であることを意図するものではなく、むしろ本発明の実施形態に必要な基本的なコンポーネントを強調するための代表的なものである。例えば、サービス・プロバイダ・サーバ４０２には、フラッシュ・ドライブ、磁気カセット、デジタル多用途ディスク（ＤＶＤ）、Ｂｅｒｎｏｕｌｌｉカートリッジなどといった他のメモリ・ストレージ・デバイスを含めてもよい。
【００２９】
さらになお、本発明の好適な一実施形態では、本発明の実施形態に関連する（ＲＢＥＴＰ３４８の実行を含む）全ての機能がサービス・プロバイダ・サーバ４０２によって果たされ、ひいてはクライアント・コンピュータ３０２は自身のリソースを使用する必要がなくなる。
【００３０】
当然のことながら、本発明の実施形態は、別の選択肢として、プログラム製品が含まれた、コンピュータが使用可能な媒体において実現することもできる。機能を定義するプログラム群は、データ・ストレージ・システムまたはコンピュータ・システムへ、多様な信号担持媒体を介して配信可能であり、信号担持媒体としては、書き込み不可能なストレージ媒体（例えば、ＣＤ−ＲＯＭなど）、書き込み可能なストレージ媒体（例えば、ハード・ディスク・ドライブ、読み書きＣＤ  ＲＯＭ、光媒体など）、ならびにＥｔｈｅｒｎｅｔ、インターネット、ワイヤレス・ネットワーク、さらに同様のネットワーク・システムを含むコンピュータ・ネットワークおよび電話ネットワークといった通信媒体などがあるが、これらに限定されるものではない。従って当然のことながら、上記のような信号担持媒体が本発明の実施形態における方法機能を指示するコンピュータ可読命令を搬送または符号化している場合、本発明の別の実施形態を表している。さらに、当然のことながら、本発明の実施形態は、本明細書に記載するようなハードウェア、ソフトウェア、またはソフトウェアとハードウェアとの組み合わせの形をした手段、あるいはその同等物を備えたシステムによって実現されてもよい。
【００３１】
ソフトウェア・デプロイメント
上述のように、本発明の実施形態により説明されるプロセスは、ＲＢＥＴＰ３４８の機能も含め、サービス・プロバイダ・サーバ４０２が実行する。あるいは、ＲＢＥＴＰ３４８、ならびに本明細書に記載され特に図４乃至５にて図示および説明されている方法を、プロセス・ソフトウェアとして、サービス・プロバイダ・サーバ４０２からクライアント・コンピュータ３０２へデプロイすることができる。加えて特に、そのように記述されている本方法用のプロセス・ソフトウェアを、別のサービス・プロバイダ・サーバ（図示せず）によってサービス・プロバイダ・サーバ４０２へデプロイすることもできる。
【００３２】
続いて図８乃至９を参照すると、ステップ５００にてプロセス・ソフトウェアのデプロイメントが開始される。最初に、プロセス・ソフトウェアの実行に際しサーバ（単数または複数）上へ備える何らかのプログラムがあるか否かを判断する（問い合わせブロック５０２）。プログラムがある場合、実行ファイルを含めることになるサーバを特定する（ブロック５０４）。そのサーバ（単数または複数）用のプロセス・ソフトウェアを、ファイル転送プロトコル（ＦＴＰ：Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）または他の何らかのプロトコルを介して、あるいは共有ファイル・システムの使用を通じてコピーすることによって、そのサーバのストレージへ直接移す（ブロック５０６）。その後、プロセス・ソフトウェアは、サーバへインストールされる（ブロック５０８）。
【００３３】
次に、サーバ（単数または複数）上のプロセス・ソフトウェアへユーザをアクセスさせることによってプロセス・ソフトウェアをデプロイするか否かについて、判断が下される（問い合わせブロック５１０）。ユーザが、サーバ上のプロセス・ソフトウェアへアクセスする場合、プロセス・ソフトウェアを保存することになるサーバ・アドレスを特定する（ブロック５１２）。
【００３４】
プロセス・ソフトウェアを保存するのにプロキシ・サーバを構築するべきか否かについて、判断が下される（問い合わせブロック５１４）。プロキシ・サーバは、ウェブ・ブラウザなどのクライアント・アプリケーションと実際のサーバとの間に置かれるサーバである。プロキシ・サーバは、実際のサーバへの要求を全て傍受し、プロキシ・サーバ自身がその要求に応えることが可能か否かを確かめる。要求に応えることができない場合、プロキシ・サーバは、その要求を実際のサーバへ転送する。プロキシ・サーバの２つの主要な利点として、性能が向上すること、および要求がフィルタに掛けられることがある。プロキシ・サーバが必要な場合、プロキシ・サーバをインストールする（ブロック５１６）。プロセス・ソフトウェアは、ＦＴＰなどのプロトコルを介してサーバへ送信されるか、あるいはファイルの共有を通じて、リソース・ファイルからサーバ・ファイルへ直接コピーされる（ブロック５１８）。別の実施形態としては、プロセス・ソフトウェアを含んだサーバへトランザクションを送信してサーバにトランザクションを処理させ、次いでプロセス・ソフトウェアを受信しサーバのファイル・システムにコピーすることが考えられる。サーバにてプロセス・ソフトウェアが保存されたら、その後ユーザが、自身のクライアント・コンピュータを介してサーバ上のプロセス・ソフトウェアへアクセスし、自身のクライアント・コンピュータのファイル・システムへコピーする（ブロック５２０）。別の実施形態として、サーバから各クライアントへプロセス・ソフトウェアを自動的にコピーさせ、次いで各クライアント・コンピュータにて、プロセス・ソフトウェア用のインストール・プログラムを起動させるものがある。ユーザは、自身のクライアント・コンピュータへプロセス・ソフトウェアをインストールするプログラムを実行し（ブロック５２２）、その後プロセスを終える（終了ブロック５２４）。
【００３５】
問い合わせステップ５２６にて、プロセス・ソフトウェアをユーザへ電子メールで送信することによってプロセス・ソフトウェアをデプロイするか否かについて、判断が下される。プロセス・ソフトウェアをデプロイする一連のユーザを、ユーザのクライアント・コンピュータのアドレスとともに特定する（ブロック５２８）。プロセス・ソフトウェアが、ユーザのクライアント・コンピュータの各々へ電子メールで送信される（ブロック５３０）。次いでユーザが電子メールを受信し（ブロック５３２）、その後プロセス・ソフトウェアを自身のクライアント・コンピュータ上のディレクトリへ電子メールからデタッチする（ブロック５３４）。ユーザは、プロセス・ソフトウェアを自身のクライアント・コンピュータへインストールするプログラムを実行し（ブロック５２２）、その後プロセスを終える（終了ブロック５２４）。
【００３６】
最後に、プロセス・ソフトウェアを、ユーザのクライアント・コンピュータ上のユーザ・ディレクトリへ直接送信するか否かに関して、判断が下される（問い合わせブロック５３６）。そうである場合、ユーザ・ディレクトリを特定する（ブロック５３８）。プロセス・ソフトウェアを、ユーザのクライアント・コンピュータのディレクトリへ直接移す（ブロック５４０）。このことは、いくつかのやり方で行うことができ、やり方には、例えばファイル・システム・ディレクトリを共有して送信側のファイル・システムから受信側ユーザのファイル・システムへコピーすること、あるいはファイル転送プロトコル（ＦＴＰ）などの転送プロトコルを使用することなどがあるが、これらに限定されない。ユーザは、プロセス・ソフトウェアのインストールに向けて、自身のクライアント・ファイル・システム上のディレクトリへアクセスする（ブロック５４２）。ユーザは、プロセス・ソフトウェアを自身のクライアント・コンピュータへインストールするプログラムを実行し（ブロック５２２）、その後プロセスを終える（終了ブロック５２４）。
【００３７】
ＶＰＮデプロイメント
本発明のソフトウェアは、サービスの一部として第三者へデプロイすることが可能であり、その場合、安全なデプロイメント手段として第三者ＶＰＮサービスを提供するか、あるいは個別のデプロイメント要求に応じて、オンデマンドでＶＰＮを構築する。
【００３８】
仮想プライベート・ネットワーク（ＶＰＮ）は、そうしないと安全でない、あるいは信頼できないネットワークを通じての接続を安全にするために用いることのできる、技術の任意の組み合わせである。ＶＰＮは、安全性を高め、動作コストを減少させる。ＶＰＮは、通例はインターネットであるパブリック・ネットワークを活用して、リモートのサイトまたはユーザを接続する。専用線など、専用の実在する接続を使用する代わりに、ＶＰＮでは、会社のプライベート・ネットワークからリモートのサイトまたは従業員へインターネットを経由して通じる「仮想の」接続を使用する。プロセス・ソフトウェア（言い換えれば、どこか他の場所に備わったソフトウェア）の配信または実行を目的として個別にＶＰＮを構成することによって、ＶＰＮを介したソフトウェアへのアクセスをサービスとして提供することが可能であり、この場合ＶＰＮの持続時間は、支払額に基づく所与の期間または所与のデプロイメント数に制限される。
【００３９】
プロセス・ソフトウェアは、リモート・アクセスＶＰＮまたはサイト間ＶＰＮのいずれかによって、デプロイ、アクセスおよび実行されればよい。リモート・アクセスＶＰＮを用いる場合、プロセス・ソフトウェアは、会社のプライベート・ネットワークとリモート・ユーザとの間の、第三者サービス・プロバイダを通じた安全で暗号化された接続を介して、デプロイ、アクセスおよび実行される。企業システム・サービス・プロバイダ（ＥＳＰ：ｅｎｔｅｒｐｒｉｓｅ  ｓｅｒｖｉｃｅ  ｐｒｏｖｉｄｅｒ）が、ネットワーク・アクセス・サーバ（ＮＡＳ：ｎｅｔｗｏｒｋ  ａｃｃｅｓｓ  ｓｅｒｖｅｒ）を設定して、リモート・ユーザへ、そのユーザのコンピュータ向けのデスクトップ・クライアント・ソフトウェアを提供する。ひいては、在宅勤務者が、料金無料の電話番号をダイヤルするか、あるいはケーブルまたはＤＳＬモデムを介して直接アタッチしてＮＡＳへ接触し、企業ネットワークへのアクセス、ならびにプロセス・ソフトウェアに対するアクセス、ダウンロード、実行のために、自身のＶＰＮクライアント・ソフトウェアを使用することが可能になる。
【００４０】
サイト間ＶＰＮを用いる場合、プロセス・ソフトウェアは、会社の複数の固定サイトをインターネットなどのパブリック・ネットワークで接続するのに使われる専用の機器および大規模な暗号化を使用することによって、デプロイ、アクセスおよび実行される。
【００４１】
プロセス・ソフトウェアは、パケット全体を別のパケット内に置いてそれをネットワークで送信するプロセスであるトンネリングを介して、ＶＰＮ上を伝送される。外側のパケットのプロトコルは、ネットワークによって、さらにトンネル・インターフェースと呼ばれる、パケットがネットワークに出入りする両ポイントによって、理解されている。
【００４２】
ソフトウェア統合
本明細書に記載のプロセスを実現するためのコードからなるプロセス・ソフトウェアは、アプリケーション、オペレーティング・システム、ネットワーク・オペレーティング・システムのソフトウェアと共存するようにプロセス・ソフトウェアを準備し、その後プロセス・ソフトウェアが機能することになる環境にてクライアントおよびサーバ上へそのプロセス・ソフトウェアをインストールすることによって、クライアント、サーバ、およびネットワーク環境へ統合することもできる。
【００４３】
第１のステップは、プロセス・ソフトウェアがデプロイされることになるクライアントおよびサーバ上の、プロセス・ソフトウェアが必要とするかまたはプロセス・ソフトウェアと連携して動作する、ネットワーク・オペレーティング・システムなどの任意のソフトウェアを特定することである。これには、ネットワーク機能を加えることによって基本的なオペレーティング・システムを高度化するソフトウェアである、ネットワーク・オペレーティング・システムが含まれる。
【００４４】
次に、ソフトウェア・アプリケーションおよびバージョン番号を特定し、プロセス・ソフトウェアとともに動作することを試験済みのソフトウェア・アプリケーションおよびバージョン番号のリストと比較する。脱落している、あるいは適正なバージョンと合致しないソフトウェア・アプリケーションは、適正なバージョン番号にアップグレードされる。プロセス・ソフトウェアからソフトウェア・アプリケーションへパラメータを渡すプログラム命令を確認して、パラメータ・リストが、プロセス・ソフトウェアに必要なパラメータ・リストと確実に合致するようにする。逆の面から言えば、ソフトウェア・アプリケーションによってプロセス・ソフトウェアへ渡されるパラメータを確認して、パラメータが、プロセス・ソフトウェアに必要なパラメータと確実に合致するようにする。ネットワーク・オペレーティング・システムを含む、クライアントおよびサーバのオペレーティング・システムを特定し、プロセス・ソフトウェアとともに動作することを試験済みのオペレーティング・システム、バージョン番号、およびネットワーク・ソフトウェアのリストと比較する。試験済みのオペレーティング・システムおよびバージョン番号のリストと合致しないオペレーティング・システム、バージョン番号およびネットワーク・ソフトウェアは、クライアントおよびサーバ上で、必要なレベルまでアップグレードされる。
【００４５】
プロセス・ソフトウェアがデプロイされるところにあるソフトウェアを、プロセス・ソフトウェアとともに動作することを試験済みの適正なバージョン・レベルに確実にした後で、プロセス・ソフトウェアをクライアントおよびサーバ上にインストールし、統合を完了する。
【００４６】
オンデマンド
プロセス・ソフトウェアは、共有されており、同時に複数の顧客に対してフレキシブルな自動化されたやり方で機能している。プロセス・ソフトウェアは、標準化されていてカスタマイゼーションをほとんど必要とせず、加えて適応性があって、従量料金モデルのオンデマンドで容量を提供する。
【００４７】
プロセス・ソフトウェアは、１つ以上のサーバからアクセス可能な共有ファイル・システム上に保存することができる。プロセス・ソフトウェアは、データと、アクセスされたサーバ上のＣＰＵ単位を使用するサーバ処理要求とを含む、トランザクションを介して実行される。ＣＰＵ単位は、サーバの中央プロセッサにおける分、秒、時間などの時間単位である。加えて、評価されたサーバは、他のサーバに対して、ＣＰＵ単位を求める要求を行うこともできる。ＣＰＵ単位は、使用状況測定値のほんの１つを表す例である。他の使用状況測定値としては、ネットワーク帯域幅、メモリ使用率、ストレージ使用率、パケット転送、完了したトランザクションなどがあるが、これらに限定されない。
【００４８】
複数の顧客が同一のプロセス・ソフトウェア・アプリケーションを使用する場合、それら顧客のトランザクションは、トランザクションに含まれた、一意の顧客とその顧客向けのサービスのタイプとを特定するパラメータによって区別される。各顧客向けのサービスに使用されるＣＰＵ単位および他の使用状況測定値は、全て記録される。いずれか１つのサーバへのトランザクション数がサーバの性能に影響を及ぼし始める数に達すると、他のサーバがアクセスを受けることで、容量を増やし作業負荷を共有する。同様に、ネットワーク帯域幅、メモリ使用率、ストレージ使用率など他の使用状況測定値が性能に影響を及ぼすほどの容量に近づくと、追加的なネットワーク帯域幅、メモリ使用率、ストレージなどが、作業負荷の共有のために追加される。
【００４９】
各サービスおよび顧客用に使われた使用状況測定値は収集サーバへ送信され、収集サーバが、プロセス・ソフトウェアを共有して実行するサーバ・ネットワーク内のあらゆるところで処理された各顧客用の各サービスに関する使用状況測定値を合計する。合計された使用状況測定値の単位量に周期的に単位コストを乗じ、結果として生じるプロセス・ソフトウェア・アプリケーション・サービス・コストの総額について、選択的に、顧客への送信または顧客によってアクセスされるウェブ・サイト上での表示あるいはその両方を行い、その後顧客によってサービス・プロバイダへ支払額が送金される。
【００５０】
別の実施形態では、サービス・プロバイダが、銀行または金融機関の顧客の口座からの直接的な支払を要求する。
【００５１】
別の実施形態では、サービス・プロバイダも、プロセス・ソフトウェア・アプリケーションを使用している顧客の顧客である場合、支払額の受け渡しをできるだけ少なくするように、サービス・プロバイダへの支払額を、サービス・プロバイダからの支払額で調整する。
【００５２】
ここで図１０乃至１１を参照すると、開始ブロック６０２にて、オンデマンド・プロセスが開始される。一意の顧客識別表示と、要求されるサービス・タイプと、サービスのタイプをさらに指定するサービス・パラメータとを含むトランザクションが作成される（ブロック６０４）。次いでトランザクションがメイン・サーバへ送信される（ブロック６０６）。オンデマンド環境では、初めはメイン・サーバを唯一のサーバとすることができ、その後容量が消費されるに従って、他のサーバをオンデマンド環境へ追加する。
【００５３】
オンデマンド環境における、サーバの中央処理装置（ＣＰＵ）容量を問い合わせる（ブロック６０８）。トランザクションのＣＰＵ要件を見積もり、次いで、オンデマンド環境におけるサーバの利用可能ＣＰＵ容量と、トランザクションのＣＰＵ要件とを比較して、トランザクションを処理するのに十分なＣＰＵ利用可能容量がいずれかのサーバにあるか否かを確かめる（問い合わせブロック６１０）。サーバのＣＰＵ利用可能容量が十分にない場合、トランザクションの処理のために、追加的なサーバＣＰＵ容量が割り当てられる（ブロック６１２）。既に十分な利用可能ＣＰＵ容量があった場合は、選択したサーバへトランザクションを送信する（ブロック６１４）。
【００５４】
トランザクションを実行する前に、残りのオンデマンド環境について確認がなされ、この環境がトランザクションの処理に十分な利用可能容量を有するか否かについて判断する。この環境容量は、ネットワーク帯域幅、プロセッサ・メモリ、ストレージなどからなるが、これらに限定されない（ブロック６１６）。十分な利用可能容量がない場合、オンデマンド環境へ容量が追加される（ブロック６１８）。次に、トランザクションを処理するのに必要なソフトウェアへアクセスしてメモリへロードし、その後、トランザクションを実行する（ブロック６２０）。
【００５５】
使用量測定値が記録される（ブロック６２２）。使用量測定値は、オンデマンド環境において、そのトランザクションを処理するのに使用される機能の各部分からなる。記録されるのは、ネットワーク帯域幅、プロセッサ・メモリ、ストレージ、およびＣＰＵサイクルなどといった機能の使用量であるが、これらに限定されない。使用量測定値は、合計して単位コストを乗じ、その後、要求元の顧客の料金として記録する（ブロック６２４）。
【００５６】
顧客が、オンデマンド・コストをウェブ・サイトへ掲載するように要求していた場合（問い合わせブロック６２６）、コストが掲載される（ブロック６２８）。顧客が、オンデマンド・コストを電子メールで顧客のアドレスへ送信するように要求していた場合（問い合わせブロック６３０）、これらのコストが顧客へ送信される（ブロック６３２）。顧客が、オンデマンド・コストを顧客の口座から直接支払うように要求していた場合（問い合わせブロック６３４）、支払額は顧客の口座から直接受け取られる（ブロック６３６）。その後、終了ブロック６３８にて、オンデマンド・プロセスを終える。
【００５７】
本発明の実施形態は、このように、ルール・システムにてリソース・ベースのイベントをタイプ付けするコンピュータ実装可能な方法、システムおよびコンピュータ媒体を提示する。一実施形態では、コンピュータ実装可能な方法は以下のステップ群を含む：イベント・タイプを、そのイベント・タイプに関連するリソース特性に従って、定義するステップ；１つ以上のどのイベント・タイプがリソースにて発生し得るかを記述するリソース定義を作成するステップ；ルール・システム内のリソース：イベント・マッピング論理（ＲＥＭＬ）にリソース定義を保存するステップ；データ処理システム内の特定のリソースから非同期データを受信するステップ；非同期データと、その特定のリソース用のリソース定義に関連する特定のルールとを互いに関係付けるように、ＲＥＭＬを利用するステップ；特定のルールを非同期データに適用するステップ。リソース定義は、そのリソースからルール・システムによってどのような特性データをプルすることができるのかを記述するとよい。一実施形態では、ルール・システム内のルール論理が、特定のルールに従って非同期データを操作して出力を生成し、コンピュータ実装可能な方法が、特定のルールのこの出力を特定のリソースへ送信するステップをさらに含む。コンピュータ実装可能な方法は、同様に以下のステップ群も含むとよい：特定のリソースによる使用が認められている複数のルールから、特定のルールを選択するステップ；複数のルールの各々を、同期データまたは非同期データのいずれかに対して適用可能なものとして定義するステップ、ただし、同期データは特定のルールを求める要求を含み、非同期データは、受信されたデータの適用対象となる特定のルールを指定しない；ルール・システムによって受信されたデータが同期であるか非同期であるかを判断するステップ；ルール・システムによって受信されたデータは非同期であるという判断に応えて、入力として非同期データを用いるルールのみを探してルール・システムを検索するステップ。ルール・システムは、データ処理システム内の少なくとも１つのリソースを管理するリソース・マネージャの一部であってもよい。
【００５８】
さらになお、上述のように、コンピュータが使用可能な媒体の各実施形態にて使用される命令は、サービス・プロバイダからユーザへデプロイされてもよい。このデプロイメントは、本明細書に記載したように「オンデマンド」ベースで行われるとよい。
【００５９】
本明細書および添付の請求項で用いられる用語「コンピュータ」または「システム」または「コンピュータ・システム」または「コンピュータ・デバイス」には、パーソナル・コンピュータ、サーバ、ワークステーション、ネットワーク・コンピュータ、メインフレーム・コンピュータ、ルータ、スイッチ、パーソナル・デジタル・アシスタント（ＰＤＡ：Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）、電話、およびデータの処理、送信、受信、取り込みまたは保存あるいはその両方が可能な他のあらゆるシステムを含む任意のデータ処理システムが含まれるが、これらに限定されるものではない。
【図面の簡単な説明】
【００６０】
【図１】従来技術の「プル」ルール・コールを示す図である。
【図２】従来技術の同期式「プッシュ」ルール・コールを示す図である。
【図３】従来技術の非同期式「プッシュ」ルール・コールを示す図である。
【図４】リソース：イベント・マッピング論理（ＲＥＭＬ）を利用している非同期式「プッシュ」ルール・コールを示す図である。
【図５】図４に示すＲＥＭＬを作成し利用するのにとられる例示的なステップ群を示すフロー図である。
【図６】本発明の実施形態を実装するとよい例示的なクライアント・コンピュータを示す図である。
【図７】図６に示すクライアント・コンピュータのユーザのために、本発明の実施形態を実行するソフトウェアがそこからデプロイまたは実装あるいはその両方が行われるとよい例示的なサーバを示す図である。
【図８】図４乃至５で示し説明したステップ群を実行することのできるソフトウェアをデプロイするのにとられるステップ群のフロー図である。
【図９】図４乃至５で示し説明したステップ群を実行することのできるソフトウェアをデプロイするのにとられるステップ群のフロー図である。
【図１０】図４乃至５で示し説明したステップ群をオンデマンド・サービス・プロバイダを使って実行するのにとられるステップ群を示すフロー図である。
【図１１】図４乃至５で示し説明したステップ群をオンデマンド・サービス・プロバイダを使って実行するのにとられるステップ群を示すフロー図である。
【図１】
2010505166.tif 000003
【図２】
2010505166.tif 000004
【図３】
2010505166.tif 000005
【図４】
2010505166.tif 000006
【図５】
2010505166.tif 000007
【図６】
2010505166.tif 000008
【図７】
2010505166.tif 000009
【図８】
2010505166.tif 000010
【図９】
2010505166.tif 000011
【図１０】
2010505166.tif 000012
【図１１】
2010505166.tif 000013
【手続補正書】
【提出日】平成21年4月7日(2009.4.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ルール・システムにてリソース・ベースのイベントをタイプ付けする、コンピュータ実装可能な方法であって、
イベント・タイプを、前記イベント・タイプに関連するリソース特性に従って、定義するステップと、
１つ以上のどのイベント・タイプがリソースにて発生し得るかを記述するリソース定義を作成するステップと、
前記リソース定義を前記ルール・システムに保存するステップと、
データ処理システム内の特定のリソースから非同期データを受信するステップと、
前記非同期データと、前記特定のリソース用のリソース定義に関連する特定のルールとを、互いに関係付けるステップと、
前記特定のルールを前記非同期データに適用するステップと、
をコンピュータに実行させる、
方法。
【請求項２】
前記リソース定義が、さらに、前記リソースから前記ルール・システムによってどのような特性データをプルすることができるかを記述する、請求項１に記載の方法。
【請求項３】
前記ルール・システム内のルール論理が、前記特定のルールに従って前記非同期データを操作して出力を生成し、前記方法が、前記特定のルールの前記出力を前記特定のリソースへ送信するステップをさらに含む、請求項１に記載の方法。
【請求項４】
前記特定のリソースによる使用が認められている複数のルールから、前記特定のルールを選択するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記複数のルールの各々を、同期データまたは非同期データのいずれかに対して適用可能なものとして定義するステップであって、前記同期データは特定のルールを求める要求を含み、前記非同期データは、受信されたデータの適用対象となる特定のルールを指定しない、前記定義するステップと、
前記ルール・システムによって受信されたデータが、同期であるか非同期であるかを判断するステップと、
前記ルール・システムによって受信された前記データは非同期であるという判断に応えて、入力として非同期データを用いるルールのみを探して前記ルール・システムを検索するステップと、
をさらに含む、請求項４に記載の方法。
【請求項６】
前記ルール・システムが、前記データ処理システム内の少なくとも１つのリソースを管理するリソース・マネージャの一部である、請求項１に記載の方法。
【請求項７】
プロセッサと、
前記プロセッサに接続されたデータ・バスと、
前記データ・バスに接続されたメモリと、
コンピュータ・プログラムと、
を含むシステムであって、前記コンピュータ・プログラムが命令を含み、前記命令は、前記プロセッサに実行させるものであり、かつ以下のこと：
イベント・タイプを、前記イベント・タイプに関連するリソース特性に従って定義すること；
１つ以上のどのイベント・タイプがリソースにて発生し得るかを記述するリソース定義を作成すること；
前記リソース定義をルール・システムに保存すること；
データ処理システム内の特定のリソースから非同期データを受信すること；
前記非同期データと、前記特定のリソース用のリソース定義に関連する特定のルールとを、互いに関係付けること；
前記特定のルールを前記非同期データに適用すること、
を行うように構成されている、システム。
【請求項８】
前記リソース定義が、さらに、前記リソースから前記ルール・システムによってどのような特性データをプルすることができるかを記述する、請求項７に記載のシステム。
【請求項９】
前記ルール・システム内のルール論理が、前記特定のルールに従って前記非同期データを操作して出力を生成し、前記命令が、さらに、前記特定のルールの前記出力を前記特定のリソースへ送信するように構成されている、請求項７に記載のシステム。
【請求項１０】
前記命令が、さらに、前記特定のリソースによる使用が認められている複数のルールから前記特定のルールを選択するように構成されている、請求項７に記載のシステム。
【請求項１１】
前記命令が、さらに以下のこと：
前記複数のルールの各々を、同期データまたは非同期データのいずれかに対して適用可能なものとして定義することであって、前記同期データは特定のルールを求める要求を含み、前記非同期データは、受信されたデータの適用対象となる特定のルールを指定しない、前記定義すること；
前記ルール・システムによって受信されたデータが、同期であるか非同期であるかを判断すること；
前記ルール・システムによって受信された前記データは非同期であるという判断に応えて、入力として非同期データを用いるルールのみを探して前記ルール・システムを検索すること、
を行うように構成されている、請求項１０に記載のシステム。
【請求項１２】
前記ルール・システムが、前記データ処理システム内の少なくとも１つのリソースを管理するリソース・マネージャの一部である、請求項７に記載のシステム。
【請求項１３】
コンピュータ・プログラムであって、前記コンピュータ・プログラムが、コンピュータに実行させる命令を含み、前記命令は、以下のこと：
イベント・タイプを、前記イベント・タイプに関連するリソース特性に従って定義すること；
１つ以上のどのイベント・タイプがリソースにて発生し得るかを記述するリソース定義を作成すること；
前記リソース定義をルール・システムに保存すること；
データ処理システム内の特定のリソースから非同期データを受信すること；
前記非同期データと、前記特定のリソース用のリソース定義に関連する特定のルールとを、互いに関係付けること；
前記特定のルールを前記非同期データに適用すること、
を行うように構成されている、コンピュータ・プログラム。
【請求項１４】
前記リソース定義が、さらに、前記リソースから前記ルール・システムによってどのような特性データをプルすることができるかを記述する、請求項１３に記載のコンピュータ・プログラム。
【請求項１５】
前記ルール・システム内のルール論理が、前記特定のルールに従って前記非同期データを操作して出力を生成し、前記コンピュータに実行させる命令が、さらに、前記特定のルールの前記出力を前記特定のリソースへ送信するように構成されている、請求項１３に記載のコンピュータ・プログラム。
【請求項１６】
前記コンピュータに実行させる命令が、さらに、前記特定のリソースによる使用が認められている複数のルールから前記特定のルールを選択するように構成されている、請求項１３に記載のコンピュータ・プログラム。
【請求項１７】
前記コンピュータに実行させる命令が、さらに以下のこと：
前記複数のルールの各々を、同期データまたは非同期データのいずれかに対して適用可能なものとして定義することであって、前記同期データは特定のルールを求める要求を含み、前記非同期データは、受信されたデータの適用対象となる特定のルールを指定しない、前記定義すること；
前記ルール・システムによって受信されたデータが、同期であるか非同期であるかを判断すること；
前記ルール・システムによって受信された前記データは非同期であるという判断に応えて、入力として非同期データを用いるルールのみを探して前記ルール・システムを検索すること、
を行うように構成されている、請求項１６に記載のコンピュータ・プログラム。
【請求項１８】
前記ルール・システムが、前記データ処理システム内の少なくとも１つのリソースを管理するリソース・マネージャの一部である、請求項１３に記載のコンピュータ・プログラム。
【請求項１９】
前記コンピュータ・プログラムが、リモート・サーバのコンポーネントであり、前記コンピュータに実行させる命令が、前記リモート・サーバからクライアント・コンピュータへデプロイ可能である、請求項１３に記載のコンピュータ・プログラム。
【請求項２０】
前記コンピュータに実行させる命令が、サービス・プロバイダによって顧客へオンデマンド・ベースで提供されることが可能である、請求項１３に記載のコンピュータ・プログラム。
【国際調査報告】
2010505166.tif 000014
2010505166.tif 000015
2010505166.tif 000016