(57)【要約】【課題】  コンピュータ・システム内で一時キャパシティ・オンデマンドを測定する機能を提供する装置および方法を提供することにある。【解決手段】  プロセッサ日などのリソース時間が指定される。リソースの実際の使用量がモニターされ、顧客はリソースの実際の使用量分のみ課金される。このように、顧客は指定のリソース時間を購入することができ、リソースが実際に使用された時間分のみ課金される。好ましい諸実施形態は、ロジカル・パーティション・コンピュータ・システム内で一時キャパシティ・オンデマンドを測定することに及ぶ。あるリソースが共用される場合、そのリソースの実際の使用量がモニターされ、顧客は、所定の非ゼロのしきい値を超える実際の使用量分のみ請求される。
2006523875.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合されたメモリと、
前記少なくとも１つのプロセッサに結合された少なくとも１つのリソースであって、装置のユーザによって要求されたときに一時キャパシティを提供する少なくとも１つのリソースと、
前記メモリ内に常駐し、前記少なくとも１つのプロセッサによって実行されるキャパシティ・マネージャであって、前記ユーザによって要求されたときに、前記少なくとも１つのリソースへのアクセスを管理し、前記少なくとも１つのリソースの実使用分を測定し、前記実使用分を請求するキャパシティ・マネージャと、
を有する装置。
【請求項２】
前記少なくとも１つのリソースの実使用分を表す測定リソース時間分の請求書を生成することにより、前記キャパシティ・マネージャが前記実使用分を請求する、請求項１に記載の装置。
【請求項３】
前払いしたリソース時間から測定リソース時間を差し引くことにより、前記キャパシティ・マネージャが前記実使用分を請求する、請求項１に記載の装置。
【請求項４】
使用可能化コードを評価して、前記コードが有効であるかどうかを判別する使用可能化コード・メカニズムであって、前記使用可能化コードが指定のリソース時間を含む使用可能化コード・メカニズムをさらに有する、請求項１に記載の装置。
【請求項５】
前記キャパシティ・マネージャが前記少なくとも１つのリソースの前記実使用分を測定する前に前記少なくとも１つのリソースを使用可能にするリソース・アロケータをさらに有する、請求項１に記載の装置。
【請求項６】
前記少なくとも１つのリソースの前記キャパシティ・マネージャの測定実使用分が指定のリソース時間を超えたときに前記リソース・アロケータが前記少なくとも１つのリソースを使用不可にする、請求項５に記載の装置。
【請求項７】
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合されたメモリと、
装置上で定義された複数のロジカル・パーティションと、
前記装置のユーザによって要求されたときに一時キャパシティを提供する少なくとも１つのリソースと、
前記メモリ内に常駐し、前記少なくとも１つのプロセッサによって実行されるキャパシティ・マネージャであって、前記複数のロジカル・パーティションによる前記少なくとも１つのリソースへのアクセスを管理し、各ロジカル・パーティションによる前記少なくとも１つのリソースの実使用分を測定し、各ロジカル・パーティションによる前記実使用分を請求するキャパシティ・マネージャと、
を有する装置。
【請求項８】
前記ロジカル・パーティションによる前記少なくとも１つのリソースの実使用分を表す各ロジカル・パーティションに関する測定リソース時間分の請求書を生成することにより、前記キャパシティ・マネージャが各ロジカル・パーティションによる前記実使用分を請求する、請求項７に記載の装置。
【請求項９】
各ロジカル・パーティションに関する前払いしたリソース時間から各ロジカル・パーティションに関する測定リソース時間を差し引くことにより、前記キャパシティ・マネージャが各ロジカル・パーティションによる前記実使用分を請求する、請求項７に記載の装置。
【請求項１０】
使用可能化コードを評価して、前記コードが有効であるかどうかを判別する使用可能化コード・メカニズムであって、前記使用可能化コードが指定のリソース時間を含む使用可能化コード・メカニズムをさらに有する、請求項７に記載の装置。
【請求項１１】
前記キャパシティ・マネージャが前記少なくとも１つのリソースの前記実使用分を測定する前に前記少なくとも１つのリソースを使用可能にするリソース・アロケータをさらに有する、請求項７に記載の装置。
【請求項１２】
前記少なくとも１つのリソースの前記キャパシティ・マネージャの測定実使用分が指定のリソース時間を超えたときにリソース・アロケータが前記少なくとも１つのリソースを使用不可にする、請求項７に記載の装置。
【請求項１３】
リソースが共用されるかどうかを前記キャパシティ・マネージャが判別し、前記リソースが共用される場合に、所定の非ゼロのしきい値を上回る共用リソースの使用量を前記キャパシティ・マネージャが測定する、請求項７に記載の装置。
【請求項１４】
少なくとも１つの一時リソース・オンデマンドの測定キャパシティを提供するためのコンピュータ実現方法であって、
測定動作のために前記少なくとも１つのリソースを使用可能にするステップと、
前記少なくとも１つのリソースの実際の使用量を測定するステップと、
前記少なくとも１つのリソースの前記実際の使用量分を請求するステップと、
を有する方法。
【請求項１５】
前記実際の使用量分を請求する前記ステップが、前記少なくとも１つのリソースの実使用分を表す測定リソース時間分の請求書を生成するステップを有する、請求項１４に記載の方法。
【請求項１６】
前記実際の使用量分を請求する前記ステップが、前払いしたリソース時間から測定リソース時間を差し引くステップを有する、請求項１４に記載の方法。
【請求項１７】
使用可能化コードが有効であるかどうかを判別するステップであって、前記使用可能化コードが指定のリソース時間を含むステップをさらに有する、請求項１４に記載の方法。
【請求項１８】
前記少なくとも１つのリソースの前記測定した実際の使用量が指定のリソース時間を超えたときに前記少なくとも１つのリソースを使用不可にするステップをさらに有する、請求項１４に記載の方法。
【請求項１９】
複数のロジカル・パーティションを含むコンピュータ・システム内で少なくとも１つの一時リソース・オンデマンドの測定キャパシティを提供するためのコンピュータ実現方法であって、
選択されたロジカル・パーティションによる測定動作のために前記少なくとも１つのリソースを使用可能にするステップと、
前記選択されたロジカル・パーティションによる前記少なくとも１つのリソースの実際の使用量を測定するステップと、
前記選択されたロジカル・パーティションによる前記少なくとも１つのリソースの前記実際の使用量分を請求するステップと、
を有する方法。
【請求項２０】
前記実際の使用量分を請求する前記ステップが、前記少なくとも１つのリソースの実使用分を表す測定リソース時間分の請求書を生成するステップを有する、請求項１９に記載の方法。
【請求項２１】
前記実際の使用量分を請求する前記ステップが、前払いしたリソース時間から測定リソース時間を差し引くステップを有する、請求項１９に記載の方法。
【請求項２２】
使用可能化コードが有効であるかどうかを判別するステップであって、前記使用可能化コードが指定のリソース時間を含むステップをさらに有する、請求項１９に記載の方法。
【請求項２３】
前記少なくとも１つのリソースの前記測定した実際の使用量が指定のリソース時間を超えたときに前記少なくとも１つのリソースを使用不可にするステップをさらに有する、請求項１９に記載の方法。
【請求項２４】
リソースが共用されるかどうかを判別し、前記リソースが共用される場合に、所定の非ゼロのしきい値を上回る共用リソースの使用量を測定するステップをさらに有する、請求項１９に記載の方法。
【請求項２５】
ビジネスを実行するための方法であって、
（１）顧客にコンピュータ・システムを提供するステップであって、前記コンピュータ・システムが測定キャパシティ・オンデマンドを提供する少なくとも１つのリソースを含むステップと、
（２）前記顧客の要求により、前記少なくとも１つのリソースを使用可能にするステップと、
（３）前記少なくとも１つのリソースの実際の使用量を測定するステップと、
（４）前記少なくとも１つのリソースの前記実際の使用量分を前記顧客に請求するステップと、
を有する方法。
【請求項２６】
ビジネスを実行するための方法であって、
（１）顧客にコンピュータ・システムを提供するステップであって、前記コンピュータ・システムが測定キャパシティ・オンデマンドを提供する少なくとも１つのリソースを含むステップと、
（２）前記少なくとも１つのリソースの指定のリソース時間について前記顧客による前払いを受け取るステップと、
（３）前記少なくとも１つのリソースを使用可能にするステップと、
（４）前記少なくとも１つのリソースの実際の使用量を測定するステップと、
（５）前記前払いした指定のリソース時間から前記実際の使用量を差し引くステップと、
を有する方法。
【請求項２７】
前記実際の使用量が前記前払いした指定のリソース時間未満ではないときに前記少なくとも１つのリソースを使用不可にするステップをさらに有する、請求項２６に記載の方法。
【請求項２８】
ユーザによって要求されたときに一時増加キャパシティを提供するコンピュータ・システム内の少なくとも１つのリソースへのアクセスを管理するキャパシティ・マネージャであって、前記少なくとも１つのリソースの実使用分を測定し、前記実使用分を請求するキャパシティ・マネージャと、
前記キャパシティ・マネージャを担持するコンピュータ可読信号伝送媒体と、
を有するプログラム。
【請求項２９】
前記信号伝送媒体が記録可能媒体を有する、請求項２８に記載のプログラム。
【請求項３０】
前記信号伝送媒体が伝送媒体を有する、請求項２８に記載のプログラム。
【請求項３１】
前記少なくとも１つのリソースの実使用分を表す測定リソース時間分の請求書を生成することにより、前記キャパシティ・マネージャが前記実使用分を請求する、請求項２８に記載のプログラム。
【請求項３２】
前払いしたリソース時間から測定リソース時間を差し引くことにより、前記キャパシティ・マネージャが前記実使用分を請求する、請求項２８に記載のプログラム。
【請求項３３】
使用可能化コードを評価して、前記コードが有効であるかどうかを判別する使用可能化コード・メカニズムであって、前記使用可能化コードが指定のリソース時間を含む使用可能化コード・メカニズムをさらに有する、請求項２８に記載のプログラム。
【請求項３４】
前記キャパシティ・マネージャが前記少なくとも１つのリソースの前記実使用分を測定する前に、前記少なくとも１つのリソースを使用可能にするリソース・アロケータをさらに有する、請求項２８に記載のプログラム。
【請求項３５】
前記少なくとも１つのリソースの前記キャパシティ・マネージャの測定実使用分が指定のリソース時間を超えたときに前記リソース・アロケータが前記少なくとも１つのリソースを使用不可にする、請求項３４に記載のプログラム。
【請求項３６】
（１）コンピュータ・システム内の複数のロジカル・パーティションによる少なくとも１つのリソースへのアクセスを管理するキャパシティ・マネージャであって、各ロジカル・パーティションによる前記少なくとも１つのリソースの実使用分を測定し、各ロジカル・パーティションによる前記実使用分を請求するキャパシティ・マネージャと、
（２）前記キャパシティ・マネージャを担持するコンピュータ可読信号伝送媒体と、
を有するプログラム。
【請求項３７】
前記信号伝送媒体が記録可能媒体を有する、請求項３６に記載のプログラム。
【請求項３８】
前記信号伝送媒体が伝送媒体を有する、請求項３６に記載のプログラム。
【請求項３９】
前記ロジカル・パーティションによる前記少なくとも１つのリソースの実使用分を表す各ロジカル・パーティションに関する測定リソース時間分の請求書を生成することにより、前記キャパシティ・マネージャが各ロジカル・パーティションによる前記実使用分を請求する、請求項３６に記載のプログラム。
【請求項４０】
各ロジカル・パーティションに関する前払いしたリソース時間から各ロジカル・パーティションに関する測定リソース時間を差し引くことにより、前記キャパシティ・マネージャが各ロジカル・パーティションによる前記実使用分を請求する、請求項３６に記載のプログラム。
【請求項４１】
使用可能化コードを評価して、前記コードが有効であるかどうかを判別する使用可能化コード・メカニズムであって、前記使用可能化コードが指定のリソース時間を含む使用可能化コード・メカニズムをさらに有する、請求項３６に記載のプログラム。
【請求項４２】
前記キャパシティ・マネージャが前記少なくとも１つのリソースの前記実使用分を測定する前に前記少なくとも１つのリソースを使用可能にするリソース・アロケータをさらに有する、請求項３６に記載のプログラム。
【請求項４３】
前記少なくとも１つのリソースの前記キャパシティ・マネージャの測定実使用分が指定のリソース時間を超えたときに前記リソース・アロケータが前記少なくとも１つのリソースを使用不可にする、請求項４２に記載のプログラム。
【請求項４４】
リソースが共用されるかどうかを前記キャパシティ・マネージャが判別し、前記リソースが共用される場合に、所定の非ゼロのしきい値を上回る共用リソースの使用量を前記キャパシティ・マネージャが測定する、請求項３６に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データ処理に関し、より具体的には、コンピュータ・システム内のリソースの使用状況に関する。
【背景技術】
【０００２】
コンピュータ時代の幕開け以来、コンピュータ・システムは、多種多様な設定で提供可能な極めて精巧な装置に進化している。コンピュータ・システムは概して、ハードウェア（たとえば、半導体、回路基板など）とソフトウェア（たとえば、コンピュータ・プログラム）の組合せを含む。半導体処理およびコンピュータ・アーキテクチャの進歩によってコンピュータ・ハードウェアのパフォーマンスが押し上げられるにつれて、ハードウェアのパフォーマンスの向上を利用するためにより精巧なコンピュータ・ソフトウェアが発生し、その結果、現在では、わずか数年前よりはるかに強力なコンピュータ・システムになっている。
【０００３】
現在のコンピュータ・システムに関する課題の１つは、コンピュータ・ハードウェアのコストと、コンピュータ・リソースに対する需要の変動とのバランスを取ることである。ほとんどのネットワーク・コンピュータ・システムでは、コンピューティング需要が比較的低い時間と、コンピューティング需要が非常に高い時間がある。ある会社がピーク需要を満たすことができるコンピュータ・システムを購入する場合、そのコンピュータ・システムのキャパシティの多くは非ピーク時に未使用になる。加えて、ピーク需要を満たすためのキャパシティの購入は費用がかかる。ある会社が平均需要を満たすことができるコンピュータ・システムを購入する場合、コストはより低くなるが、コンピュータ・システムのパフォーマンスはピーク時に低下する。
【０００４】
より柔軟な解決策を提供するための１つの方法では、コンピュータ・ユーザは、いくつかのリソースがインストールされているが最初は使用不可になっているコンピュータ・システムを購入することができる。より多くのキャパシティが必要であると顧客が判断した場合、顧客は、一定の期間の間、特定のリソースを使用可能にするためにコンピュータ・システムのプロバイダと協定を結ぶことができる。これは、季節的ピークがある会社には特に有効である。会社は、ピーク・シーズン中に強化した計算能力を提供する機能を有するコンピュータ・システムを妥当なコストで購入することができる。一時キャパシティ・オンデマンド（temporary capacity on demand）を提供するという概念は、２００３年３月４日に出願された「Ｍｅｔｈｏｄ  ｔｏ  Ｐｒｏｖｉｄｅ  Ｏｎ−Ｄｅｍａｎｄ  Ｒｅｓｏｕｒｃｅ  Ａｃｃｅｓｓ」という関連特許出願第１０／４０６６５２号の主題である。
【０００５】
図２を参照すると、一時キャパシティ・オンデマンドを提供するための１つの適切な方法２００の流れ図は、顧客がメーカから使用可能化コード（enablement code）を要求することによって始まる（ステップ２１０）。顧客はリソース時間（resource-time）の指定を含む使用可能化コードを受信する（ステップ２２０）。「リソース時間」という用語は、任意の適切な期間の間、任意のリソースまたは複数リソースの組合せを指定できるようにする一般的な用語である。リソース時間の一例はプロセッサ日（processor-day）である。顧客は使用可能化コードを入力し、これがコンピュータ・システム上のリソースを使用可能にする（ステップ２３０）。次にタイマが始動される（ステップ２４０）。その後、ユーザは、リソース時間が満了しない限り（ステップ２６０＝ＮＯ）、リソースを使用することができる（ステップ２５０）。リソース時間が満了すると（ステップ２６０＝ＹＥＳ）、リソースは使用不可になる（ステップ２７０）。
【０００６】
単純な例により方法２００の有用性を示すことにする。カタログ販売により商品を販売する会社は休日ショッピングのために毎年１１月と１２月にピーク需要を経験するものと想定する。この会社は、インストールされているが最初は使用不可になっている１つまたは複数の追加プロセッサを有するコンピュータ・システムを購入できるであろう。その場合、会社は、設定期間の間、追加プロセッサ（複数も可）を使用可能にするためにコンピュータ・システムのプロバイダと契約を結ぶことができる。そのコンピュータ・システムが２つの追加プロセッサを有するものと想定し、ピーク購入期間が１１月１５日から１２月１４日までの３０日間継続するものと想定する。顧客は、１１月１５日から６０プロセッサ日（processor-days）分の追加キャパシティを購入できるであろう。その場合、この２つの追加プロセッサは、３０日間使用可能になる（６０プロセッサ日分の追加キャパシティを提供する）。６０プロセッサ日が経過すると、２つの追加プロセッサは使用不可になる。
【０００７】
方法２００に関する問題の１つは、リソースがリソース時間の一部分しか使用できない場合でも顧客はそのリソース時間分を支払うことである。たとえば、追加プロセッサが主に８時間の昼間の勤務時間帯に使用される場合、顧客は結局、残りの２通りの勤務時間帯にはほとんど未使用になるキャパシティ分も支払うことになる。上記の例では、顧客が６０プロセッサ日分を購入し、２つのプロセッサが使用可能になっている場合、この２つのプロセッサは、その時間帯のワークロードにかかわらず、正確に３０日間使用可能になる。これは、一時キャパシティ・オンデマンドを提供しない従来のシステムより大幅な改善であるが、依然としていくつかの欠点がある。
【特許文献１】米国特許出願第１０／４０６６５２号
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明はこの問題に対処しようとするものである。
【課題を解決するための手段】
【０００９】
装置および方法は、コンピュータ・システム内で一時キャパシティ・オンデマンドを測定する機能を提供する。プロセッサ日などのリソース時間が指定される。リソースの実際の使用量がモニターされ、顧客はリソースの実際の使用量分のみ課金される。このように、顧客は指定のリソース時間を購入することができ、リソースが実際に使用された時間分のみ課金される。好ましい諸実施形態は、ロジカル・パーティション・コンピュータ・システム内で一時キャパシティ・オンデマンドを測定することに及ぶ。あるリソースが共用される場合、そのリソースの実際の使用量がモニターされ、顧客は、所定の非ゼロのしきい値を超える実際の使用量分のみ請求される。
【００１０】
本発明の上記その他の特徴および利点は、添付図面に図示した本発明の好ましい諸実施形態に関する以下のより詳細な説明から明らかになるであろう。
【００１１】
本発明の好ましい諸実施形態については添付図面に併せて以下に説明するが、添付図面では同様の名称は同様の要素を示している。
【発明を実施するための最良の形態】
【００１２】
図１を参照すると、コンピュータ・システム１００は、拡張ＩＢＭ  ｅＳｅｒｖｅｒ  ｉＳｅｒｉｅｓコンピュータ・システムであり、好ましい諸実施形態による１つの適切なタイプのコンピュータ・システムを表す。当業者であれば、本発明のメカニズムおよび装置は任意のコンピュータ・システムに等しく適用されることが分かるであろう。図１に示した通り、コンピュータ・システム１００は、メイン・メモリ１２０に接続された１つまたは複数のプロセッサ１１０と、大容量ストレージ・インターフェース１３０と、ディスプレイ・インターフェース１４０と、ネットワーク・インターフェース１５０と、複数の入出力スロット１８０とを有する。これらのシステム・コンポーネントは、システム・バス１６０の使用により相互接続される。大容量ストレージ・インターフェース１３０は、大容量ストレージ・デバイス（直接アクセス・ストレージ・デバイス１５５など）をコンピュータ・システム１００に接続するために使用する。１つの特定のタイプの直接アクセス・ストレージ・デバイスはＣＤ  ＲＷドライブであり、これはＣＤ  ＲＷ１９５からデータを読み取ることができる。大容量ストレージ・インターフェース１３０、ディスプレイ・インターフェース１４０、およびネットワーク・インターフェース１５０は、実際には入出力スロット１８０に結合されたアダプタとして実現可能であることに留意されたい。
【００１３】
メイン・メモリ１２０は、データ１２１と、オペレーティング・システム１２２と、キャパシティ・マネージャ１２３とを収容する。データ１２１は、任意のプロセッサ１１０またはメイン・メモリ１２０にアクセス可能な任意のその他のデバイスによって読取り、または書込みが可能な任意のデータである。オペレーティング・システム１２２は、ＯＳ／４００、ＡＩＸ、またはＬｉｎｕｘなどのマルチタスキング・オペレーティング・システムであるが、当業者であれば、本発明の趣旨および範囲は任意の１つのオペレーティング・システムに限定されないことが分かるであろう。適切なものであれば、どのオペレーティング・システムも使用することができる。オペレーティング・システム１２２は、コンピュータ・システム１００のリソースを管理するための低レベル・コードを含む精巧なプログラムである。これらのリソースのうちのいくつかは、プロセッサ１１０、メイン・メモリ１２０、大容量ストレージ・インターフェース１３０、ディスプレイ・インターフェース１４０、ネットワーク・インターフェース１５０、システム・バス１６０、および入出力スロット１８０である。
【００１４】
キャパシティ・マネージャ１２３は、測定キャパシティ・オンデマンド（metered capacity on demand）を提供する。キャパシティ・マネージャ１２３は、使用可能化コード１２５が有効であるかどうかを判別し、使用可能化コードが有効であると判別されたときに１つまたは複数のリソースを使用可能にするために使用される使用可能化コード・メカニズム１２４を含む。リソース・アロケータ１２６は、使用のためにリソースを割り振るメカニズムである。したがって、使用可能化コード１２５が有効であると使用可能化コード・メカニズム１２４が判別すると、リソース・アロケータ１２６は対応するリソース（複数も可）を使用可能なものにする。また、キャパシティ・マネージャ１２３は、リソース時間単位（resource-timeunit）１２８で使用量を測定する実使用メータ（actual use meter）１２７も含む。第１の実施形態では、実使用メータはリソース時間単位で実際の使用量を追跡し、顧客は実際の使用量分を請求される。第２の実施形態では、実使用メータは前払いした分のリソース時間単位を有し、前払いしたリソース時間単位が使い果たされるまで前払いしたリソース時間単位から実使用分が差し引かれる。
【００１５】
コンピュータ・システム１００は、コンピュータ・システム１００のプログラムがメイン・メモリ１２０およびＤＡＳＤデバイス１５５などの複数の小規模ストレージ・エンティティへのアクセスの代わりに大規模単一ストレージ・エンティティにのみアクセスできる場合と同様に振る舞えるようにする、周知の仮想アドレッシング・メカニズムを使用する。したがって、データ１２１、オペレーティング・システム１２２、およびキャパシティ・マネージャ１２３はメイン・メモリ１２０内に常駐するものとして示されているが、当業者であれば、これらの項目が必ずしもすべて同時にメイン・メモリ１２０に完全に収容されるわけではないことを認識するであろう。また、「メモリ」という用語はコンピュータ・システム１００の仮想メモリ全体を総称的に指すために本明細書で使用することにも留意されたい。
【００１６】
プロセッサ１１０は、１つまたは複数のマイクロプロセッサあるいは集積回路またはその両方から構築することができる。プロセッサ１１０は、メイン・メモリ１２０に保管されたプログラム命令を実行する。メイン・メモリ１２０は、プロセッサ１１０がアクセス可能なプログラムおよびデータを保管する。コンピュータ・システム１００が始動すると、プロセッサ１１０は最初に、オペレーティング・システム１２２を構成するプログラム命令を実行する。
【００１７】
コンピュータ・システム１００は単一システム・バスのみを含むものとして示されているが、当業者であれば、本発明は複数のバスを有するコンピュータ・システムを使用して実施可能であることが分かるであろう。加えて、好ましい実施形態で使用される入出力インターフェースはそれぞれ、ｉＳｅｒｉｅｓ入出力プロセッサ内など、プロセッサ１１０から計算主体の処理をオフロードするために使用する、個別の完全にプログラミングされたマイクロプロセッサを含む場合もあれば、単純な業界標準の入出力アダプタ（ＩＯＡ）である場合もある。
【００１８】
ディスプレイ・インターフェース１４０は、１つまたは複数のディスプレイ１６５をコンピュータ・システム１００に直接接続するために使用する。これらのディスプレイ１６５は、非インテリジェント（すなわち、ダム）端末または完全プログラマブル・ワークステーションである場合もあり、システム管理者およびユーザがコンピュータ・システム１００と通信できるようにするために使用する。しかし、ディスプレイ・インターフェース１４０は１つまたは複数のディスプレイ１６５との通信をサポートするために設けられているが、ユーザおよびその他のプロセスとの必要な対話はすべてネットワーク・インターフェース１５０を介して行うことができるので、コンピュータ・システム１００は必ずしもディスプレイ１６５を必要とするわけではないことに留意されたい。
【００１９】
ネットワーク・インターフェース１５０は、他のコンピュータ・システムあるいはワークステーションまたはその両方（たとえば、図１の１７５）をネットワーク１７０によりコンピュータ・システム１００に接続するために使用する。本発明は、ネットワーク接続１７０が現代のアナログ技術あるいはディジタル技術またはその両方を使用して行われるか、将来の何らかのネットワーキング・メカニズムを介して行われるかにかかわらず、コンピュータ・システム１００がどのような方法で他のコンピュータ・システムあるいはワークステーションまたはその両方に接続可能であろうとも、等しく適用される。加えて、ネットワークを実現するために、多種多様なネットワーク・プロトコルを使用することができる。これらのプロトコルは、コンピュータがネットワーク１７０により通信できるようにする特殊コンピュータ・プログラムである。ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）は、適切なネットワーク・プロトコルの一例である。
【００２０】
この時点では、完全に機能しうるコンピュータ・システムに関連して本発明をこれまで説明し、今後も説明し続けるが、当業者であれば、本発明は様々な形のプログラム（program product）として配布可能であり、本発明はその配布を実際に実行するために使用されるコンピュータ可読信号伝送媒体の特定のタイプにかかわらず等しく適用されることが分かるであろうということは、留意すべき重要なことである。適切な信号伝送媒体の例としては、フレキシブル・ディスクおよびＣＤ  ＲＷ（たとえば、図１の１９５）などの記録可能タイプの媒体と、ディジタルおよびアナログ通信リンクなどの伝送タイプの媒体とを含む。
【００２１】
次に図３を参照すると、第１の実施形態による方法３００は、コンピュータ・システム内の一時リソースの実使用分を顧客に請求する。まず、顧客は使用可能化コードを要求する（ステップ３１０）。コンピュータ・システムのプロバイダは顧客に使用可能化コードを送信する（ステップ３２０）。使用可能化コードはリソース時間の指定を含むことに留意されたい。次に、使用可能化コードに指定されたリソースが使用可能になる（ステップ３３０）。その後、顧客はリソースを使用することができる（ステップ３４０）。リソースの実際の使用量が測定される（ステップ３５０）。ステップ３４０のリソースの使用と、ステップ３５０の実際の使用量の測定は、請求時期でない限り（ステップ３６０＝ＮＯ）、続行される。請求時期になると（ステップ３６０＝ＹＥＳ）、測定リソース使用量の記録がリソース・プロバイダに送信され（ステップ３７０）、次にリソース・プロバイダは測定リソース使用量分の請求書を顧客に送信する（ステップ３８０）。図２の方法２００と比較した場合の方法３００の利点は、顧客がリソースの実際の使用量分のみ課金されることである。したがって、２つのプロセッサが６０プロセッサ日の間、使用可能になり、２つのプロセッサが毎日２４時間のうち平均８時間のみ使用される場合、６０プロセッサ日は、図２の方法２００によって提供される３０日間の代わりに、合計９０日間、続くことになる。２つのプロセッサに、暦日あたり１日の使用量の１／３を掛けると、暦日あたり１プロセッサ日の２／３になる。暦日あたり１プロセッサ日の２／３のみが費やされるので、６０プロセッサ日は、図２の方法２００を使用して得られると思われる３０暦日の代わりに、９０暦日続くことになる。加えて、方法３００は、所定のリソース時間（６０プロセッサ日など）について高料金で請求し、所定のリソース時間が使用された後は低料金で請求する能力を含むことができる。
【００２２】
測定リソース使用量の記録は、任意の適切なキャリアによりプロバイダに送信することができる。手動の例では、顧客は、測定使用量を決定するようコンピュータ・システムに照会し、リソース・プロバイダに送信またはファックス送信される書式で測定使用量を報告する。自動の例では、キャパシティ・マネージャは、インターネットによりプロバイダに測定使用量の記録を自動的に送信し、その後、顧客は測定使用量分を請求される。当然のことながら、その他の組合せおよび変形例も可能であり、そのいずれも好ましい諸実施形態の範囲内である。
【００２３】
もう１つのオプションは、顧客が所定の量のリソース時間分を前払いできるようにし、前払いした量から実際の使用量を差し引くことである。これは、指定の度数を有するプリペイド・テレホンカードと同様のものであり、使用された度数を総量から差し引く。プリペイド方法の実現例の１つは図４の方法４００として示されている。顧客は指定のリソース時間分を前払いする（ステップ４１０）。次に顧客は、前払いしたリソース時間分の使用可能化コードを要求する（ステップ４２０）。次にリソース供給業者は、前払いしたリソース時間の指定を含む使用可能化コードを顧客に提供する（ステップ４３０）。その後、リソースは使用可能になり（ステップ４４０）、使用される（ステップ４５０）。リソースの実際の使用量が測定され（ステップ４６０）、前払いしたリソース時間から差し引かれる。ステップ４５０および４６０は、測定使用分が前払いしたリソース時間未満である限り（ステップ４７０＝ＹＥＳ）、続行される。測定使用分がもはや前払いしたリソース時間未満ではなくなると（ステップ４７０＝ＮＯ）、リソースは使用不可になる（ステップ４８０）。
【００２４】
好ましい諸実施形態の範囲内で図４の方法４００に対して行われる変更は、前払いしたリソース時間を更新する能力である。したがって、前払いしたリソース時間が何らかの所定のしきい値（たとえば、初期量の２０％）になった場合、顧客は、追加のリソース時間分を前払いするようプロンプトで指示される可能性がある。前払いしたリソース時間が使い果たされる前に顧客がこれを行った場合、追加のリソース時間が残高に追加され、コンピュータ・システムは中断なしに追加のリソースで動作し続けることができる。
【００２５】
上記の図１、図３、および図４に関連して述べた例はロジカル・パーティション（logical partitions）を備えていないが、好ましい諸実施形態はロジカル・パーティション・コンピュータ・システムにも及ぶ。図５を参照すると、ロジカル・パーティション・コンピュータ・システム５００の特定の一実現例はＮ個のロジカル・パーティションを含み、各ロジカル・パーティションはそれぞれのオペレーティング・システム５２６を実行する。図５では、ロジカル・パーティション５２５Ａ・・・５２５Ｎはそれぞれのオペレーティング・システム５２６Ａ・・・５２６Ｎを実行しているものとして示されている。各ロジカル・パーティション内のオペレーティング・システム５２６は、他のパーティション内のオペレーティング・システムと同じである場合もあれば、まったく異なるオペレーティング・システムである場合もある。したがって、あるパーティションがＯＳ／４００オペレーティング・システムを実行し、異なるパーティションがＯＳ／４００の他のインスタンス、おそらく異なるリリースを実行するか、または異なる環境設定（たとえば、時間帯）で実行することができる。ロジカル・パーティション内のオペレーティング・システムは、ハードウェアとの互換性があるという条件で、ＯＳ／４００とは異なるもの（ＡＩＸまたはＬｉｎｕｘなど）にすることもできるであろう。このように、ロジカル・パーティションは、同じ物理的コンピュータ・システム上でまったく異なるコンピューティング環境を提供することができる。
【００２６】
ロジカル・パーティションはパーティション・マネージャ５４０によって管理される。適切なパーティション・マネージャ５４０の一例は、ＩＢＭ用語の「ハイパーバイザ（hypervisor）」として知られている。パーティション・マネージャ５４０は、リソース５５０Ａ〜リソース５５０Ｘとして図５に示されているリソース５５０を管理する。これに関連する「リソース」は、パーティション・マネージャ５４０によって制御可能な任意のハードウェアまたはソフトウェアにすることができる。ハードウェア・リソースの例としては、プロセッサ、メモリ、およびハード・ディスク・ドライブを含む。ソフトウェア・リソースの例としては、データベース、内部通信（ロジカルＬＡＮなど）、またはアプリケーション（ワード・プロセッサ、電子メールなど）を含む。パーティション・マネージャ５４０は、ロジカル・パーティション５２５がどのリソース５５０を使用できるかを制御する。リソースは、パーティション・マネージャ５４０にとって使用可能なものになると、まだロジカル・パーティションに割り当てられていない場合に使用可能リソース５６０としてカテゴリ化され、複数ロジカル・パーティションがそのリソースにアクセスできる場合に共用リソース５７０としてカテゴリ化され、ロジカル・パーティションに排他的に割り当てられている場合に専用リソース５８０としてカテゴリ化される。図５は、各ロジカル・パーティション５２５Ａ・・・５２５Ｎに対応する専用リソース５８０Ａ・・・５８０Ｎを示している。
【００２７】
図６を参照すると、好ましい諸実施形態による方法６００は、顧客がロジカル・パーティションを含むコンピュータ・システム上で一時リソースに関する使用可能化コードを要求すると始まる（ステップ６０２）。コンピュータ供給業者は、どのリソースを使用可能にするかという指定を含む使用可能化コードを顧客に提供する（ステップ６０４）。その後、リソースは、使用可能なものとしてマークが付けられる（ステップ６０６）。これは、まだどのロジカル・パーティションにも割り当てられていない使用可能リソース５６０のプール内にそのリソースが置かれていることを意味する。次に行われることは、そのリソースがパーティション・マネージャによって特定のパーティションに対して専用リソースとして割り振られるか、またはそのリソースが共用使用のために割り振られるかによって決まる（ステップ６１０）。そのリソースがあるロジカル・パーティションに対して専用リソースになる場合（ステップ６１０＝ＹＥＳ）、メータ・タイマが始動され（ステップ６２０）、リソースが使用される（ステップ６２２）。これは、請求時期であること（ステップ６３０＝ＹＥＳ）をメータ・タイマが示すまで続行される（ステップ６３０＝ＮＯ）。次に測定リソース使用量の記録がリソース・プロバイダに送信され（ステップ６３２）、その後、リソース・プロバイダは測定リソース使用量分の請求書を顧客に送信する（ステップ６３４）。リソースが専用パーティションに構成される場合（ステップ６１０＝ＹＥＳ）、リソースは、専用パーティション内の実際の使用量にかかわらず、１００％使用中であると見なされることに留意されたい。したがって、リソースがあるパーティションに対して専用のものである実際の１分は、いずれも顧客に対して課金される１リソース分（resource-minute）になる。このため、ステップ６２０でメータ・タイマが始動され、ステップ６３２の測定使用量の記録はリソースにメータ・タイマ上で経過した時間を掛けたものになる。この意味で、方法６００は、その実使用分にかかわらず、リソースが使用可能になっている時間に応じて顧客に請求する図２の方法２００と同様のものになる。そのリソースは他のロジカル・パーティションによる使用には使用不能であるので、このタイプの請求はリソースの専用使用を有するロジカル・パーティションの場合に意味をなす。
【００２８】
そのリソースがパーティション・マネージャによって共用リソースとして割り振られる場合（ステップ６１０＝ＮＯ）、複数のロジカル・パーティションがその共用リソースを使用することができる（ステップ６４０）。共用使用のためのしきい値が指定されるものと想定する。共用使用分がしきい値を超えない限り（ステップ６５０＝ＮＯ）、いずれの時間も測定されない。共用使用分が指定のしきい値を超える場合のみ（ステップ６５０＝ＹＥＳ）、キャパシティ・マネージャは共用使用分を測定し、しきい値を上回る共用使用分のみ測定される（ステップ６５２）。請求時期になると（ステップ６６０＝ＹＥＳ）、測定リソース使用量の記録がリソース・プロバイダに送信され（ステップ６６２）、リソース・プロバイダは測定リソース使用量分の請求書を顧客に送信する（ステップ６６４）。
【００２９】
顧客が課金される時期を決定するしきい値は、好ましくは、一時リソースが使用可能になる前にシステムのキャパシティによって決定される。たとえば、そのプールに等しくアクセスするために構成された５個の共用パーティション用の共用プールに１つのプロセッサが割り振られる場合、それぞれのパーティションは、プロセッサ・クロック・サイクルの２０％を使い果たすことができる。使用量はある期間について平均され、任意のパーティションの使用量がプロセッサ・サイクルの２０％を超える場合、そのパーティションからの作業は、他のパーティションからの作業の前にプロセッサにディスパッチされることはなく、他のパーティションの使用量がそれぞれの構成済み２０％に達することができる。次に、２つの追加プロセッサがオンデマンドで使用可能なものになるものと想定する。この２つのプロセッサは最初は使用可能なものとしてマークが付けられ（ステップ６０６）、次に共用リソースとして割り振られる（ステップ６１０＝ＮＯ）。プロセッサ・クロック・サイクルの総プール使用量が、１つのプロセッサが平均期間に提供する量を超える場合、使用した追加サイクルが測定され、１プロセッサ分（processor-minute）に相当するサイクル数が使用されるまで累積され、１プロセッサ分が顧客に対して課金される。当然のことながら、任意の適切なリソース時間増分を使用することができる。このように、種々のロジカル・パーティションは、ロジカル・パーティション・コンピュータ・システム内の１つのリソースを共用することができ、そのリソースに関するそれぞれの実使用分に応じてのみ課金されることになる。本発明の利点の１つは、サービス・プロバイダが測定キャパシティを使用する顧客に請求できるように、どのロジカル・パーティションが割振り分を超えた（そのように測定された）かをロジカル・パーティション・サービス・プロバイダが決定できる能力である。
【００３０】
次に図７を参照すると、好ましい諸実施形態による方法７００は、請求される（図６に示した通り）のではなく、顧客がロジカル・パーティション・コンピュータ・システム内のリソース時間分を前払いする（ステップ７１０）ケースを示している。使用可能化コードが要求され（ステップ７１２）、受信され（ステップ７１４）、リソースがロジカル・パーティションに割り当てるために使用可能なものになる（ステップ７１６）。リソースがパーティションに対して専用のものである場合（ステップ７２０＝ＹＥＳ）、メータ・タイマが始動され（ステップ７３０）、測定使用分が前払いしたリソース時間に等しくなる（ステップ７４０＝ＮＯ）までリソースが使用される（ステップ７３２）。この時点で、リソースが使用不可になる（ステップ７４２）。リソースがロジカル・パーティション間で共用される場合（ステップ７２０＝ＮＯ）、共用リソースはロジカル・パーティションによって使用される（ステップ７５０）。共用使用分が指定のしきい値を超える場合（ステップ７６０＝ＹＥＳ）、しきい値を上回る実際の使用量が測定され（ステップ７６２）、測定使用分が前払いしたリソース時間と比較される。測定使用分が前払いしたリソース時間に等しくなると（ステップ７７０＝ＮＯ）、いかなる新しい作業もプロセッサにディスパッチされないように、リソースが使用不可になる（ステップ７７２）。方法７００は、リソース測定使用分が前払いしたリソース時間に到達しないように前払い時間の更新を可能にするステップをふくむことができ、それによりリソースが使用不可にならないように防止できることに留意されたい。
【００３１】
好ましい諸実施形態は、既知の従来技術を超える重大な利点を提供する。ここでは、一時キャパシティ・オンデマンドを測定ベースで提供することができ、顧客はリソースの実際の使用量分のみ請求される。これは、顧客がリソースの実際の使用量に基づいて支払う電話料金や電気料金の請求に類似している。実際の使用量に基づいて測定し請求する能力はロジカル・パーティション・コンピュータ・システム内で拡張機能を提供する。それは、リソースを共用する複数のロジカル・パーティションはそれぞれ、共用リソースの実際の使用量分のみ請求される可能性があるからである。実際の使用量が測定され請求される可能性があるので、顧客に課金するための細分性のレベルが引き下げられる。たとえば、プロセッサ日について請求する代わりに、プロセッサ分、プロセッサ秒（processor-second）、プロセッサ・サイクルについて請求できるであろう。
【００３２】
当業者であれば、多くの変形例が本発明の範囲内で可能であることが分かるであろう。したがって、その好ましい諸実施形態に関連して本発明を特に図示し説明してきたが、当業者であれば、形式および詳細の点で上記その他の変更が可能であることを理解できるであろう。
【００３３】
この開示内容の範囲は、本明細書に開示されている任意の新規の特徴および複数の特徴の組合せを含む。これにより本出願人は、本出願またはそこから派生する任意の追加出願の手続追行中にこのような特徴または複数の特徴の組合せに合わせて新しい特許請求の範囲を明確に表現できることを通知する。特に、本明細書の特許請求の範囲に関連して、従属請求項による特徴は独立請求項による特徴と組み合わせることができ、それぞれの独立請求項による特徴同士は、特許請求の範囲に列挙された特定の組合せだけでなく、任意の適切な方法で組み合わせることができる。
【００３４】
疑義を回避するため、説明および特許請求の範囲全体を通して本明細書で使用する「有する（comprising）」という用語は、「のみから構成される（consisting only of）」を意味するものと解釈してはならない。
【図面の簡単な説明】
【００３５】
【図１】好ましい諸実施形態によるコンピュータ装置のブロック図である。
【図２】一時キャパシティ・オンデマンドを提供するための方法の流れ図である。
【図３】一時リソースの測定使用量分を顧客に請求できるようにする、好ましい諸実施形態による第１の方法の流れ図である。
【図４】一時リソースの測定使用量分を顧客が前払いできるようにする、好ましい諸実施形態による第２の方法の流れ図である。
【図５】ロジカル・パーティション・コンピュータ・システム内の論理コンポーネントを示すブロック図である。
【図６】ロジカル・パーティション・コンピュータ・システム内で一時リソースの測定使用量分を顧客に請求できるようにする、好ましい諸実施形態による第３の方法の流れ図である。
【図７】ロジカル・パーティション・コンピュータ・システム内で一時リソースの測定使用量分を顧客が前払いできるようにする、好ましい諸実施形態による第４の方法の流れ図である。
【図１】
2006523875.tif 000003
【図２】
2006523875.tif 000004
【図３】
2006523875.tif 000005
【図４】
2006523875.tif 000006
【図５】
2006523875.tif 000007
【図６】
2006523875.tif 000008
【図７】
2006523875.tif 000009
【国際調査報告】
2006523875.tif 000010
2006523875.tif 000011
2006523875.tif 000012