(57)【要約】【課題】  データ処理システムのコンピューティング・リソースを予約するためのメカニズムを提供する。【解決手段】  これらのメカニズムは、１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成し、それぞれのＣＥＥＣデータ構造は契約当事者とデータ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義する。これらのメカニズムは、コンピューティング・リソースのセットをＣＥＥＣデータ構造に関連付ける。これらのメカニズムは、関連付けられたＣＥＥＣに従って１つまたは複数のコンピューティング・リソースのセットを管理する。このような管理は、おおよそ指定の期間の間、おおよそ指定のレベルおよびパターンの強度で、指定の目的のために、選択されたコンピューティング・リソース・コホート内のコンピューティング・リソースを契約当事者が使用し損なったことに応答することを含み、そのすべてはＣＥＥＣデータ構造に識別され、その後、ＣＥＥＣデータ構造は失効するかまたは無効になる。【選択図】  図３
2014525078.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースを含むデータ処理システムで使用するための方法であって、前記データ処理システムのコンピューティング・リソースを予約するための方法であって、
前記少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成することであって、それぞれのＣＥＥＣデータ構造が契約当事者と前記データ処理システムのコンピューティング・リソースのプロバイダとの間のビジネス・レベル協定の条件を定義し、前記ＣＥＥＣの前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、前記契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
前記少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のコンピューティング・リソースのセットをＣＥＥＣデータ構造に関連付けることと、
前記少なくとも１つのコンピューティング・デバイスにより、前記関連付けられたＣＥＥＣデータ構造に従って前記１つまたは複数のコンピューティング・リソースのセットを管理することであって、前記ＣＥＥＣデータ構造に関連して指定されたおおよそ前記指定の期間の間、おおよそ前記指定のレベルおよびパターンの強度で、前記指定の目的のために、前記１つまたは複数のコンピューティング・リソースのセットを前記契約当事者が使用し損なったことに応答して、前記少なくとも１つのコンピューティング・デバイスのロジックが前記ＣＥＥＣデータ構造を無効にすること
を含む、方法。
【請求項２】
前記１つまたは複数のコンピューティング・リソースのセットをＣＥＥＣデータ構造に関連付けることが、
前記コンピューティング・リソースのそれぞれに関する構成情報に基づいて、複数のコンピューティング・リソースからなる１つまたは複数のコンピューティング・リソース・コホートの第１のセットを決定することであって、１つのコンピューティング・リソース・コホートに関連する複数のコンピューティング・リソースが、互いに同様のタイプのものであり、互いに同様の構成を有することと、
前記データ処理システムによって維持される１つまたは複数のＣＥＥＣデータ構造の属性に基づいて、複数のＣＥＥＣデータ構造からなる１つまたは複数のＣＥＥＣコホートの第２のセットを決定することと、
前記第２のセットに関連する選択されたＣＥＥＣコホートに関連するＣＥＥＣデータ構造の条件ならびに前記第１のセットに関連する選択されたコンピューティング・リソース・コホートの特性に基づいて、前記選択されたＣＥＥＣコホートと前記選択されたコンピューティング・リソース・コホートを突き合わせること
を含む、請求項１記載の方法。
【請求項３】
前記ＣＥＥＣデータ構造が、前記ＣＥＥＣデータ構造の個々の条件に基づいて、２つ以上のＣＥＥＣコホートに関連付けられる、請求項２記載の方法。
【請求項４】
前記関連付けられたＣＥＥＣデータ構造に従って前記１つまたは複数のコンピューティング・リソースのセットを管理することが、前記関連付けられたＣＥＥＣデータ構造に関連して指定された条件に従って前記１つまたは複数のコンピューティング・リソースのセットに関連するコンピューティング・リソースに作業負荷を経路指定することを含む、請求項２または請求項３記載の方法。
【請求項５】
作業負荷を経路指定することが、
契約当事者から作業負荷を受け取ることと、
前記契約当事者に関連する１つまたは複数のＣＥＥＣデータ構造を取り出すことと、
前記作業負荷のタイプを決定することと、
前記取り出された１つまたは複数のＣＥＥＣデータ構造に関連する事業目的のタイプを決定することと、
前記作業負荷タイプおよび前記決定されたタイプの事業目的に基づいて前記取り出された１つまたは複数のＣＥＥＣデータ構造のうちの少なくとも１つに指定されたコンピューティング・リソースに前記作業負荷を経路指定すること
を含む、請求項４記載の方法。
【請求項６】
前記作業負荷タイプおよび前記決定されたタイプの事業目的に基づいて前記取り出された１つまたは複数のＣＥＥＣデータ構造のうちの少なくとも１つに指定されたコンピューティング・リソースに前記作業負荷を経路指定することが、前記作業負荷のタイプと一致するタイプの事業目的を有するＣＥＥＣデータ構造に関連するコンピューティング・リソース・コホートに関連するコンピューティング・リソースを見つけることを含む、請求項５記載の方法。
【請求項７】
前記関連付けられたＣＥＥＣデータ構造に従って前記１つまたは複数のコンピューティング・リソースのセットを管理することが、
前記１つまたは複数のコンピューティング・リソースからリソース使用状況メトリック情報を収集することと、
前記リソース使用状況メトリック情報を、前記関連付けられたＣＥＥＣデータ構造に関連して指定された前記指定のレベルおよびパターンの使用強度と比較することと、
前記収集したリソース使用状況メトリック情報が、前記関連付けられたＣＥＥＣデータ構造に関連して指定された前記指定のレベルおよびパターンの使用強度とは著しく異なるかどうかを判断することと、
前記収集したリソース使用状況メトリック情報が前記指定のレベルおよびパターンの強度とは著しく異なることに応答して、あるＣＥＥＣコホートに関連する前記ＣＥＥＣデータ構造のメンバーシップのうちの少なくとも１つを変更するか、または前記１つまたは複数のコンピューティング・リソースのセットに対する前記ＣＥＥＣデータ構造の関連付けを変更すること
を含む、請求項１ないし６のいずれかに記載の方法。
【請求項８】
前記ＣＥＥＣデータ構造のメンバーシップのうちの少なくとも１つを変更するか、または前記１つまたは複数のコンピューティング・リソースのセットに対する前記ＣＥＥＣデータ構造の関連付けを変更することが、その指定のレベルおよびパターンの使用強度が前記収集したリソース使用状況メトリック情報とは著しく異なる前記ＣＥＥＣデータ構造を異なるＣＥＥＣコホートに移行することにより、前記ＣＥＥＣデータ構造のメンバーシップを変更することを含む、請求項７記載の方法。
【請求項９】
前記ＣＥＥＣデータ構造のメンバーシップのうちの少なくとも１つを変更し、前記１つまたは複数のコンピューティング・リソースのセットに対する前記ＣＥＥＣデータ構造の関連付けを変更することが、前記１つまたは複数のコンピューティング・リソースのセットに関連付けられることから、１つまたは複数のコンピューティング・リソースの異なるセットに関連付けられることに、前記ＣＥＥＣデータ構造を移行することにより、前記１つまたは複数のコンピューティング・リソースのセットに対する前記ＣＥＥＣデータ構造の関連付けを変更することを含む、請求項７記載の方法。
【請求項１０】
前記ＣＥＥＣを異なるＣＥＥＣコホートに移行することが、その指定のレベルおよびパターンの使用強度が前記収集したリソース使用状況メトリック情報とは著しく異なる前記ＣＥＥＣを無効にすることと、前記無効にしたＣＥＥＣを前記異なるＣＥＥＣコホートに関連する新しいＣＥＥＣで置き換えることを含む、請求項９記載の方法。
【請求項１１】
前記１つまたは複数のコンピューティング・リソースのセットに関連付けられることから、１つまたは複数のコンピューティング・リソースの異なるセットに関連付けられることに、前記ＣＥＥＣを移行することが、前記ＣＥＥＣを無効にすることと、新しいＣＥＥＣを作成することと、前記新しいＣＥＥＣを前記１つまたは複数のコンピューティング・リソースの異なるセットに関連付けることを含む、請求項９または請求項１０記載の方法。
【請求項１２】
前記ＣＥＥＣデータ構造が、
前記ＣＥＥＣの識別情報を指定するＣＥＥＣ  ＩＤフィールドと、
前記ＣＥＥＣデータ構造が関連付けられた契約当事者または契約当事者のグループを明確に識別するために契約当事者ＩＤを保管する契約当事者ＩＤフィールドと、
前記ＣＥＥＣデータ構造が関連付けられた前記コンピューティング・リソース（複数も可）、コンピューティング・リソース・コホート、またはコンピューティング・リソース（複数も可）の他のグループを明確に識別する１つまたは複数のコンピューティング・リソースＩＤフィールドと、
前記ＣＥＥＣに従って前記１つまたは複数のコンピューティング・リソースＩＤフィールドに関連して識別された前記コンピューティング・リソース（複数も可）を使用することができる１つまたは複数の指定の事業目的を識別する１つまたは複数の事業目的フィールドと、
前記ＣＥＥＣの前記条件を満足するためにコンピューティング・リソース構成要件を指定する１つまたは複数のコンピューティング・リソース構成フィールドと、
１つまたは複数のコンピューティング・リソースＩＤフィールドに指定された前記コンピューティング・リソースを使用するために前記契約当事者が要求される所与の期間の間、所与のレベルおよびパターンの使用強度を指定する１つまたは複数の使用状況フィールドと
を含む、請求項１ないし１１のいずれかに記載の方法。
【請求項１３】
データ処理システムのコンピューティング・リソースを予約するための装置であって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合可能な少なくとも１つのメモリであって、前記少なくとも１つのプロセッサによって実行されたときに、
１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成することであって、それぞれのＣＥＥＣデータ構造が契約当事者と前記データ処理システムのコンピューティング・リソースのプロバイダとの間のビジネス・レベル協定の条件を定義し、前記ＣＥＥＣの前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、前記契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
１つまたは複数のコンピューティング・リソースのセットをＣＥＥＣデータ構造に関連付けることと、
前記関連付けられたＣＥＥＣデータ構造に従って前記１つまたは複数のコンピューティング・リソースのセットを管理することであって、前記ＣＥＥＣデータ構造に関連して指定されたおおよそ前記指定の期間の間、おおよそ前記指定のレベルおよびパターンの強度で、前記指定の目的のために、前記１つまたは複数のコンピューティング・リソースのセットを前記契約当事者が使用し損なったことに応答して、前記プロセッサが前記ＣＥＥＣデータ構造を無効にするように動作可能であること
を前記少なくとも１つのプロセッサに実行させる命令を含む、少なくとも１つのメモリと
を含む、装置。
【請求項１４】
少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースを含むデータ処理システムで使用するための方法であって、コンピューティング環境受給権契約に対して前記コンピューティング・リソースの使用をモニターするための方法であって、
前記少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成することであって、それぞれのＣＥＥＣデータ構造が契約当事者と前記データ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義し、前記ＣＥＥＣデータ構造の前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、前記契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
前記少なくとも１つのコンピューティング・デバイスにより、同様の条件を有するＣＥＥＣデータ構造の集合を含むＣＥＥＣコホートを生成することと、
前記少なくとも１つのコンピューティング・デバイスにより、前記ＣＥＥＣコホートに関連する使用パターンを識別するために前記ＣＥＥＣデータ構造の集合の前記同様の条件に従ってコンピューティング・リソースの集合の使用状況をモニターすることと、
前記少なくとも１つのコンピューティング・デバイスにより、前記識別された使用パターンに基づいて前記ＣＥＥＣコホートに関連するＣＥＥＣデータ構造のメンバーシップを変更すること
を含む、方法。
【請求項１５】
同様の条件を有するＣＥＥＣデータ構造の集合を含むＣＥＥＣコホートを生成することが、
ＣＥＥＣコホートを定義するために使用されるパラメータを指定し、前記ＣＥＥＣコホートのメンバーとして含めることができるＣＥＥＣデータ構造の特性を指定するプロファイルを定義することと、
前記１つまたは複数のＣＥＥＣデータ構造のうちのＣＥＥＣデータ構造内のデータに前記プロファイルを適用して、どのＣＥＥＣデータ構造が前記プロファイルの前記パラメータによって指定された要件を満たすかを判断することと、
前記ＣＥＥＣコホートの前記ＣＥＥＣデータ構造の集合に含めるための１つまたは複数のＣＥＥＣデータ構造を選択すること
を含む、請求項１４記載の方法。
【請求項１６】
前記ＣＥＥＣコホートに関連する前記ＣＥＥＣデータ構造のメンバーシップならびに前記ＣＥＥＣコホートに関連するＣＥＥＣデータ構造のメンバーシップについて必要なコンピューティング・リソース使用状況メトリック情報に関連する使用状況のパターンを決定するために評価される、前記ＣＥＥＣデータ構造に関連するコンピューティング・リソース使用状況メトリック情報のうちの少なくとも１つを前記プロファイルが指定する、請求項１５記載の方法。
【請求項１７】
前記ＣＥＥＣコホートのメンバーになるためにそれぞれのＣＥＥＣデータ構造が備えていなければならない前記同様の条件を前記プロファイルが指定する、請求項１５または請求項１６記載の方法。
【請求項１８】
選択された１つまたは複数のＣＥＥＣデータ構造に対応するＣＥＥＣデータベースの項目に前記ＣＥＥＣコホートのＩＤを含めるために、前記１つまたは複数のＣＥＥＣデータ構造の選択に基づいて前記ＣＥＥＣデータベースに関連する項目を更新すること
をさらに含む、請求項１５ないし１７のいずれかに記載の方法。
【請求項１９】
前記プロファイルが、前記コンピューティング・リソース使用状況メトリック情報を評価して、ＣＥＥＣデータ構造が前記ＣＥＥＣコホートのメンバーであるかどうかを判断するための第１の基準を含み、前記第１の基準が、前記評価を行うための時間フレームと、前記コンピューティング・リソース使用状況を測定するための基礎と、前記評価を実行するためのバイアスとを含む、請求項１６ないし１８のいずれかに記載の方法。
【請求項２０】
前記プロファイルが、前記ＣＥＥＣコホートに関連するＣＥＥＣデータ構造のメンバーシップを調整すべき時期を決定するための第２の基準と、前記第２の基準に関連する対応するアクションとをさらに含む、請求項１９記載の方法。
【請求項２１】
前記第２の基準および対応するアクションが、その結果、対応するアクションが実行されるコンピューティング・リソース使用状況メトリック情報の範囲を指定し、前記対応するアクションが、ＣＥＥＣ市場を使用して前記ＣＥＥＣコホートに関連する追加のＣＥＥＣデータ構造を取得するための買取アクションと、前記ＣＥＥＣ市場を使用して前記ＣＥＥＣコホートからＣＥＥＣデータ構造を除去するための売却アクションと、何も実行しないための保留アクションと、ＣＥＥＣデータ構造を永続的に廃棄するための廃棄アクションとを含む、請求項２０記載の方法。
【請求項２２】
前記識別された使用パターンに基づいて前記ＣＥＥＣコホートに関連する前記ＣＥＥＣデータ構造の前記メンバーシップを変更することが、
前記識別された使用パターンに前記第２の基準を適用して、対応するアクションを識別することと、
前記ＣＥＥＣデータ構造に対して前記対応するアクションを実行し、それにより、前記ＣＥＥＣコホートの前記メンバーシップを変更すること
を含む、請求項２１記載の方法。
【請求項２３】
前記ＣＥＥＣデータ構造に対して実行される前記対応するアクションが、異なるＣＥＥＣコホートに関連する他のプロファイルに従って前記ＣＥＥＣデータ構造を前記異なるＣＥＥＣコホートに移行することである、請求項２２記載の方法。
【請求項２４】
前記ＣＥＥＣデータ構造を移行することが、前記ＣＥＥＣコホートに関連する前記ＣＥＥＣデータ構造を無効にすることと、前記無効にしたＣＥＥＣデータ構造を置き換えるために前記異なるＣＥＥＣコホートに関連する新しいＣＥＥＣデータ構造を作成することを含む、請求項２３記載の方法。
【請求項２５】
前記新しいＣＥＥＣデータ構造が、前記無効にしたＣＥＥＣデータ構造とは異なる条件を含み、前記新しいＣＥＥＣデータ構造の前記条件が前記識別された使用パターンに接近する、請求項２４記載の方法。
【請求項２６】
コンピューティング環境受給権契約に対してコンピューティング・リソースの使用をモニターするための装置であって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合可能な少なくとも１つのメモリであって、前記少なくとも１つのプロセッサによって実行されたときに、
１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成することであって、それぞれのＣＥＥＣデータ構造が契約当事者とデータ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義し、前記ＣＥＥＣデータ構造の前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、前記契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
同様の条件を有するＣＥＥＣデータ構造の集合を含むＣＥＥＣコホートを生成することと、
前記ＣＥＥＣコホートに関連する使用パターンを識別するために前記ＣＥＥＣデータ構造の集合の前記同様の条件に従ってコンピューティング・リソースの集合の使用状況をモニターすることと、
前記識別された使用パターンに基づいて前記ＣＥＥＣコホートに関連するＣＥＥＣデータ構造のメンバーシップを変更すること
を前記少なくとも１つのプロセッサに実行させる命令を含む、少なくとも１つのメモリと
を含む、装置。
【請求項２７】
少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースを含むデータ処理システムで使用するための方法であって、コンピューティング環境受給権契約に対して前記コンピューティング・リソースの使用を管理するための方法であって、
前記少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成することであって、それぞれのＣＥＥＣデータ構造が契約当事者と前記データ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義し、前記ＣＥＥＣの前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、前記契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
前記少なくとも１つのコンピューティング・デバイスにより、同様の条件を有するＣＥＥＣデータ構造の集合を含むＣＥＥＣコホートを生成することと、
前記少なくとも１つのコンピューティング・デバイスにより、前記ＣＥＥＣコホートの前記同様の条件に従ってコンピューティング・リソースの集合に関連するそれぞれのコンピューティング・リソースの使用量を測定するリソース使用状況メトリクスを収集することと、
前記少なくとも１つのコンピューティング・デバイスにより、前記収集したリソース使用状況メトリクスに基づいて前記ＣＥＥＣコホートに関連するそれぞれのＣＥＥＣデータ構造に基づくリソース使用状況の相対尺度を計算することと、
前記少なくとも１つのコンピューティング・デバイスにより、あるＣＥＥＣコホートに関連するそれぞれのＣＥＥＣデータ構造の前記リソース使用状況の前記相対尺度の報告を出力すること
を含む、方法。
【請求項２８】
前記収集したリソース使用状況メトリクスに基づいて前記ＣＥＥＣコホートに関連するそれぞれのＣＥＥＣデータ構造に基づくリソース使用状況の相対尺度を計算することが、前記ＣＥＥＣコホートに関連する事業目標に基づいて、コンピューティング・リソースの集合に関連する前記コンピューティング・リソースの様々なものに関するリソース使用状況メトリクスの相対的重み付けを決定することをさらに含む、請求項２７記載の方法。
【請求項２９】
リソース使用状況メトリクスの前記相対的重み付けが、前記収集したリソース使用状況メトリクスの統計分析に基づいて動的に決定される、請求項２８記載の方法。
【請求項３０】
前記収集したリソース使用状況メトリクスに基づいて前記ＣＥＥＣコホートに関連するそれぞれのＣＥＥＣデータ構造に基づくリソース使用状況の相対尺度を計算することが、
前記ＣＥＥＣコホートに対応するプロファイルを取り出すことであって、前記プロファイルが、前記ＣＥＥＣデータ構造のそれぞれについてリソース使用状況の相対尺度を計算するための基礎としてどのコンピューティング・リソース使用状況メトリクスを使用すべきかと、前記コンピューティング・リソース使用状況メトリクスを評価して前記ＣＥＥＣデータ構造のそれぞれについてリソース使用状況の前記相対尺度を計算するための基準を指定することと、
前記指定のコンピューティング・リソース使用状況メトリクスおよび前記プロファイルに関連する評価基準に基づいてリソース使用状況の前記相対尺度を計算すること
を含む、請求項２７ないし２９のいずれかに記載の方法。
【請求項３１】
リソース使用状況の前記相対尺度がスコアを含み、前記ＣＥＥＣコホートに関連するそれぞれのＣＥＥＣデータ構造の前記リソース使用状況の前記相対尺度の報告を出力することが、前記対応するＣＥＥＣデータ構造の条件に基づいて前記コンピューティング・リソースの相対的使用状況を示すリソース使用状況スコアの複数のカテゴリからリソース使用状況スコアの１つのカテゴリにそれぞれのＣＥＥＣデータ構造の前記スコアを分類することを含む、請求項２７ないし３０のいずれかに記載の方法。
【請求項３２】
リソース使用状況の前記相対尺度が、前記ＣＥＥＣコホートの一部である前記個々のＣＥＥＣデータ構造のそれぞれに関するスコアに基づいて全体として前記ＣＥＥＣコホートに関するスコアを含み、前記ＣＥＥＣコホートに関連するそれぞれのＣＥＥＣデータ構造の前記リソース使用状況の前記相対尺度の報告を出力することが、互いに似ている前記ＣＥＥＣコホートに関連するＣＥＥＣデータ構造の条件に基づいて前記コンピューティング・リソースの相対的使用状況を示すリソース使用状況スコアの複数のカテゴリから全体としての前記ＣＥＥＣコホートに関するリソース使用状況の１つのカテゴリを出力することを含む、請求項２７ないし３１のいずれかに記載の方法。
【請求項３３】
前記ＣＥＥＣコホートに関する前記スコアおよび前記ＣＥＥＣコホートに関するリソース使用状況の前記カテゴリのうちの少なくとも１つを含むように、前記ＣＥＥＣコホートを生成するために使用されるプロファイルを更新すること
をさらに含む、請求項３２記載の方法。
【請求項３４】
リソース使用状況スコアの前記カテゴリが、コンピューティング・リソース使用状況が対応するＣＥＥＣデータ構造の条件の受け入れられる許容範囲内にあるかどうかを示す、コンピューティング・リソース使用状況スコアの範囲を含む、請求項３１ないし３３のいずれかに記載の方法。
【請求項３５】
リソース使用状況の前記カテゴリのそれぞれが、前記ＣＥＥＣデータ構造に関連するスコアがリソース使用状況の前記特定のカテゴリにカテゴリ化されたことに応答して、対応するＣＥＥＣデータ構造に対して実行すべき対応するアクションを有する、請求項３１ないし３４のいずれかに記載の方法。
【請求項３６】
前記対応するアクションが、前記ＣＥＥＣデータ構造の否定、新しいＣＥＥＣデータ構造による前記ＣＥＥＣデータ構造の置き換え、および前記ＣＥＥＣコホートから他のＣＥＥＣコホートへの前記ＣＥＥＣデータ構造の移行のうちの少なくとも１つを含む、請求項３５記載の方法。
【請求項３７】
あるＣＥＥＣコホートに関連する少なくとも１つのＣＥＥＣデータ構造に関連するスコアの分類に基づいて前記少なくとも１つのＣＥＥＣデータ構造のメンバーシップを変更することと、
前記ＣＥＥＣコホートならびに前記ＣＥＥＣコホートと１つまたは複数のコンピューティング・リソースのセットとの関連付けに基づいて作業負荷実行を制御すること
をさらに含む、請求項３１ないし３６のいずれかに記載の方法。
【請求項３８】
リソース使用状況スコアの前記カテゴリが、前記ＣＥＥＣコホート内の模範ＣＥＥＣデータ構造および逆模範ＣＥＥＣデータ構造のうちの少なくとも１つの選択に基づいて決定される、請求項３１ないし３７のいずれかに記載の方法。
【請求項３９】
コンピューティング環境受給権契約に対してコンピューティング・リソースの使用を管理するための装置であって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合可能な少なくとも１つのメモリであって、前記少なくとも１つのプロセッサによって実行されたときに、
１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成することであって、それぞれのＣＥＥＣデータ構造が契約当事者とデータ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義し、前記ＣＥＥＣの前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、前記契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
同様の条件を有するＣＥＥＣデータ構造の集合を含むＣＥＥＣコホートを生成することと、
前記ＣＥＥＣコホートの前記同様の条件に従ってコンピューティング・リソースの集合に関連するそれぞれのコンピューティング・リソースの使用量を測定するリソース使用状況メトリクスを収集することと、
前記収集したリソース使用状況メトリクスに基づいて前記ＣＥＥＣコホートに関連するそれぞれのＣＥＥＣデータ構造に基づくリソース使用状況の相対尺度を計算することと、
あるＣＥＥＣコホートに関連するそれぞれのＣＥＥＣデータ構造の前記リソース使用状況の前記相対尺度の報告を出力すること
を前記少なくとも１つのプロセッサに実行させる命令を含む、少なくとも１つのメモリと
を含む、装置。
【請求項４０】
少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースを含むデータ処理システムで使用するための方法であって、あるコンピューティング・リソースから他のコンピューティング・リソースにコンピューティング環境受給権契約を移行するための方法であって、
前記少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成することであって、それぞれのＣＥＥＣデータ構造が契約当事者と前記データ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義し、前記ＣＥＥＣの前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、前記契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
前記少なくとも１つのコンピューティング・デバイスにより、前記１つまたは複数のＣＥＥＣデータ構造をコンピューティング・リソース・コホートに関連付けることであって、前記コンピューティング・リソース・コホートが、同様の構成を有するコンピューティング・リソースの集合を含むことと、
前記少なくとも１つのコンピューティング・デバイスにより、前記１つまたは複数のＣＥＥＣデータ構造に関連するＣＥＥＣデータ構造の売却側を識別することと、
前記少なくとも１つのコンピューティング・デバイスにより、前記１つまたは複数のＣＥＥＣデータ構造に関連するＣＥＥＣデータ構造の買取側を識別することと、
前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行することと、
前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行した後に前記買取側で前記ＣＥＥＣデータ構造に関連して指定された条件に従って作業負荷を実行することであって、前記売却側および前記買取側がコンピューティング・リソースまたはコンピューティング・リソースの集合を含むこと
を含む、方法。
【請求項４１】
前記売却側が前記ＣＥＥＣデータ構造に関連して指定された前記条件に従って使用されていないコンピューティング・リソースを含み、前記買取側が前記ＣＥＥＣデータ構造に関連して指定された前記条件を満足できるコンピューティング・リソースを含む、請求項４０記載の方法。
【請求項４２】
前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行するかどうかを判断することが、前記ＣＥＥＣデータ構造に関連して指定された前記条件に基づいて実行される、請求項４０または請求項４１記載の方法。
【請求項４３】
トランザクション指定に関連する事業目標基準に基づいて前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行するかどうかを判断することであって、前記売却側から前記買取側への前記ＣＥＥＣデータ構造の前記移行が、前記ＣＥＥＣデータ構造の前記移行が前記トランザクション指定に関連する前記事業目標基準を満足するという判断に応答してのみ実行されることをさらに含む、請求項４０ないし４２のいずれかに記載の方法。
【請求項４４】
前記トランザクション指定が、トランザクション・ビルダ・ユーザ・インターフェースを使用してユーザによって生成され、前記ユーザが、前記トランザクション・ビルダ・ユーザ・インターフェースを使用して前記事業目標基準を指定する、請求項４３記載の方法。
【請求項４５】
売却側と買取側の間でＣＥＥＣデータ構造を移行するための複数のトランザクション・インスタンスが、前記トランザクション指定に基づいて生成され、それぞれのトランザクション・インスタンスに関連する売却側と買取側の間のＣＥＥＣデータ構造の移行を実行すべきかどうかを判断するために、前記トランザクション指定の前記事業目標基準が前記トランザクション・インスタンスとともに使用される、請求項４３または請求項４４に記載の方法。
【請求項４６】
ＣＥＥＣデータ構造の売却側を識別することと、ＣＥＥＣデータ構造の買取側を識別することと、前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行することが、前記トランザクション指定のインスタンスの前記事業目標基準に従って実行される、請求項４３ないし４５のいずれかに記載の方法。
【請求項４７】
前記売却側または買取側の少なくとも一方が、前記トランザクション指定の前記インスタンスの前記事業目標基準に従って前記売却側および買取側の識別の前に、売却側または買取側になりたいという要望を示さない、請求項４６記載の方法。
【請求項４８】
前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行することが、前記トランザクション指定の前記インスタンスに従って実行され、前記トランザクション指定の前記インスタンスが、前記トランザクション指定の前記インスタンスが作成される作成フェーズと、前記売却側および前記買取側が前記トランザクションの受諾を知らせる組み立てフェーズと、前記移行の完了が前記トランザクション指定の前記インスタンスに関連する前記事業目標基準を満たすかどうかについて判断が行われる開始フェーズと、前記移行が前記売却側と前記買取側の間で完了する決済フェーズとを含む４つのトランザクション・フェーズを使用して実行される、請求項４６または請求項４７に記載の方法。
【請求項４９】
前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行することが、前記売却側で前記ＣＥＥＣデータ構造を無効にすることと、前記買取側で新しいＣＥＥＣデータ構造を作成することを含む、請求項４０ないし４８のいずれかに記載の方法。
【請求項５０】
前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行することが、前記買取側を識別するために前記ＣＥＥＣデータ構造に関連するＩＤをリセットすることを含む、請求項４０ないし４９のいずれかに記載の方法。
【請求項５１】
前記ＣＥＥＣデータ構造が、前記契約当事者と前記プロバイダとの間のＣＥＥＣの一部分（sub-portion）を表し、前記一部分が、前記プロバイダによって提供されるコンピューティング・リソースによって満足することができる前記ＣＥＥＣの前記条件の一部分を定義し、前記ＣＥＥＣの前記条件のその他の部分が、その他のプロバイダによって提供されるその他のコンピューティング・リソースによって満足される、請求項４０ないし５０のいずれかに記載の方法。
【請求項５２】
あるコンピューティング・リソースから他のコンピューティング・リソースにコンピューティング環境受給権契約を移行するための装置であって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合可能な少なくとも１つのメモリであって、前記少なくとも１つのプロセッサによって実行されたときに、
１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成することであって、それぞれのＣＥＥＣデータ構造が契約当事者とデータ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義し、前記ＣＥＥＣの前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、前記契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
前記１つまたは複数のＣＥＥＣデータ構造をコンピューティング・リソース・コホートに関連付けることであって、前記コンピューティング・リソース・コホートが、同様の構成を有するコンピューティング・リソースの集合を含むことと、
前記１つまたは複数のＣＥＥＣデータ構造に関連するＣＥＥＣデータ構造の売却側を識別することと、
前記１つまたは複数のＣＥＥＣデータ構造に関連するＣＥＥＣデータ構造の買取側を識別することと、
前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行することと、
前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行した後に前記買取側で前記ＣＥＥＣデータ構造に関連して指定された条件に従って作業負荷を実行することであって、前記売却側および前記買取側がコンピューティング・リソースまたはコンピューティング・リソースの集合を含むこと
を前記少なくとも１つのプロセッサに実行させる命令を含む、少なくとも１つのメモリと
を含む、装置。
【請求項５３】
少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースを含むデータ処理システムで使用するための方法であって、あるコンピューティング・リソースから他のコンピューティング・リソースにコンピューティング環境受給権契約を移行するための方法であって、
前記少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成することであって、それぞれのＣＥＥＣデータ構造が契約当事者と前記データ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義し、前記ＣＥＥＣの前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、前記契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
前記少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のコンピューティング・リソースを提供するプロバイダ・システムから、ＣＥＥＣデータ構造の買取側になるよう要求する第１の要求を受け取ることであって、前記第１の要求が前記ＣＥＥＣデータ構造の売却側を選択するための第１の選択基準を含むことと、
前記少なくとも１つのコンピューティング・デバイスにより、ＣＥＥＣデータ構造を所有する売却側システムから、前記ＣＥＥＣデータ構造の売却側になるよう要求する第２の要求を受け取ることであって、前記第２の要求が前記ＣＥＥＣデータ構造の買取側を選択するための第２の選択基準を含むことと、
前記少なくとも１つのコンピューティング・デバイスにより、前記第１および第２の選択基準に基づいて前記プロバイダ・システムと前記売却側システムを対にすることと、
前記売却側システムから前記プロバイダ・システムに前記ＣＥＥＣデータ構造を移行することと、
前記移行したＣＥＥＣデータ構造に関連する前記条件に従って前記プロバイダ・システム上で作業負荷を実行すること
を含む、方法。
【請求項５４】
前記第１の選択基準が、前記ＣＥＥＣデータ構造に対応する測定したコンピューティング・リソース使用状況を満足するために特定の量のコンピューティング・リソースおよび特定のタイプのコンピューティング・リソースを提供するための前記買取側の要件のうちの少なくとも１つを指定する、請求項５３記載の方法。
【請求項５５】
前記第２の選択基準が、特定の量のコンピューティング・リソースおよび特定のタイプのコンピューティング・リソースを使用するための前記売却側の要件のうちの少なくとも１つを指定する、請求項５３または請求項５４に記載の方法。
【請求項５６】
トランザクション指定に関連する事業目標基準に基づいて前記売却側システムから前記買取側システムに前記ＣＥＥＣデータ構造を移行するかどうかを判断することであって、前記売却側システムから前記買取側システムへの前記ＣＥＥＣデータ構造の前記移行が、前記ＣＥＥＣデータ構造の前記移行が前記トランザクション指定に関連する前記事業目標基準を満足するという判断に応答してのみ実行されることをさらに含む、請求項５３ないし５５のいずれかに記載の方法。
【請求項５７】
前記トランザクション指定が、トランザクション・ビルダ・ユーザ・インターフェースを使用してユーザによって生成され、前記ユーザが、前記トランザクション・ビルダ・ユーザ・インターフェースを使用して前記事業目標基準を指定する、請求項５６記載の方法。
【請求項５８】
売却側システムと買取側システムの間でＣＥＥＣデータ構造を移行するための複数のトランザクション・インスタンスが、前記トランザクション指定に基づいて生成され、それぞれのトランザクション・インスタンスに関連する売却側システムと買取側システムの間のＣＥＥＣデータ構造の移行を実行すべきかどうかを判断するために、前記トランザクション指定の前記事業目標基準が前記トランザクション・インスタンスとともに使用される、請求項５６または請求項５７に記載の方法。
【請求項５９】
前記売却側システムと前記買取側システムを対にすることが、前記第１の選択基準、前記第２の選択基準、および前記トランザクション指定のインスタンスの前記事業目標基準に従って実行される、請求項５６ないし５８のいずれかに記載の方法。
【請求項６０】
前記買取側システムの少なくとも１つが、前記ＣＥＥＣデータ構造に関連する前記条件に基づいて前記ＣＥＥＣデータ構造を構成部分に分離することにより、それぞれが前記ＣＥＥＣデータ構造の一部分を買い取る複数の買取側システムのうちの１つである、請求項５９記載の方法。
【請求項６１】
前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行することが、前記トランザクション指定の前記インスタンスに従って実行され、前記トランザクション指定の前記インスタンスが、前記トランザクション指定の前記インスタンスが作成される作成フェーズと、前記売却側システムおよび前記買取側システムが前記トランザクションの受諾を知らせる組み立てフェーズと、前記移行の完了が前記トランザクション指定の前記インスタンスに関連する前記事業目標基準を満たすかどうかについて判断が行われる開始フェーズと、前記移行が前記売却側システムと前記買取側システムの間で完了する決済フェーズとを含む４つのトランザクション・フェーズを使用して実行される、請求項５９または請求項６０に記載の方法。
【請求項６２】
前記売却側から前記買取側に前記ＣＥＥＣデータ構造を移行することが、前記売却側システム上で前記ＣＥＥＣデータ構造を無効にすることと、前記買取側システム上で新しいＣＥＥＣデータ構造を作成することを含む、請求項５３ないし６１のいずれかに記載の方法。
【請求項６３】
前記売却側システムから前記買取側システムに前記ＣＥＥＣデータ構造を移行することが、前記買取側システムを識別するために前記ＣＥＥＣデータ構造に関連するＩＤをリセットすることを含む、請求項５３ないし６２のいずれかに記載の方法。
【請求項６４】
前記買取側システムおよび前記売却側システムのそれぞれが、複数のコンピューティング・リソースを含むコンピューティング・リソース・コホートを含む、請求項５３ないし６３のいずれかに記載の方法。
【請求項６５】
あるコンピューティング・リソースから他のコンピューティング・リソースにコンピューティング環境受給権契約を移行するための装置であって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合可能な少なくとも１つのメモリであって、前記少なくとも１つのプロセッサによって実行されたときに、
１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を生成することであって、それぞれのＣＥＥＣデータ構造が契約当事者とデータ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義し、前記ＣＥＥＣの前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、前記契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
１つまたは複数のコンピューティング・リソースを提供するプロバイダ・システムから、ＣＥＥＣデータ構造の買取側になるよう要求する第１の要求を受け取ることであって、前記第１の要求が前記ＣＥＥＣデータ構造の売却側を選択するための第１の選択基準を含むことと、
ＣＥＥＣデータ構造を所有する売却側システムから、前記ＣＥＥＣデータ構造の売却側になるよう要求する第２の要求を受け取ることであって、前記第２の要求が前記ＣＥＥＣデータ構造の買取側を選択するための第２の選択基準を含むことと、
前記第１および第２の選択基準に基づいて前記プロバイダ・システムと前記売却側システムを対にすることと、
前記売却側システムから前記プロバイダ・システムに前記ＣＥＥＣデータ構造を移行することと、
前記移行したＣＥＥＣデータ構造に関連する前記条件に従って前記プロバイダ・システム上で作業負荷を実行すること
を前記少なくとも１つのプロセッサに実行させる命令を含む、少なくとも１つのメモリと
を含む、装置。
【請求項６６】
少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースを含むデータ処理システムで使用するための方法であって、前記コンピューティング・リソースの使用を管理するための方法であって、
コンピューティング環境受給権契約（ＣＥＥＣ）マネージャにより、１つまたは複数のＣＥＥＣを生成することであって、それぞれのＣＥＥＣが複数の条件を含み、ＣＥＥＣの前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定することと、
コホートおよびプロファイル・マネージャにより、１つまたは複数のコホート・プロファイルを生成することであって、それぞれのコホート・プロファイルが、１つのコホートに関連付けるためにそのコホートのそれぞれのメンバーが含む、そのコホートの共通特性を指定することと、
コホート管理サービスにより、前記コホートおよびプロファイル・マネージャによって生成された１つまたは複数のプロファイルに基づいて、前記複数のコンピューティング・リソースからのコンピューティング・リソースのグループを表すコンピューティング・リソース・コホートを定義し、前記コホートおよびプロファイル・マネージャによって生成された１つまたは複数のプロファイルに基づいて、ＣＥＥＣのグループを表すＣＥＥＣコホートを定義することと、
データベース・システムにより、前記複数のコンピューティング・リソースに対応するデータ、前記１つまたは複数のＣＥＥＣ、および前記定義されたコンピューティング・リソース・コホートおよびＣＥＥＣコホートに基づくコンピューティング・リソースとＣＥＥＣとの関連付けを保管すること
を含む、方法。
【請求項６７】
使用状況スコアリング・サービスにより、前記ＣＥＥＣコホートに関連するそれぞれのＣＥＥＣについて、前記コンピューティング・リソース・コホートに関連する前記コンピューティング・リソースから収集されたコンピューティング・リソース使用状況メトリック情報の分析に基づいてスコア値を生成すること
をさらに含む、請求項６６記載の方法。
【請求項６８】
前記コホート管理サービスが、前記使用状況スコアリング・サービスによって生成された前記スコア値に基づいて、前記コンピューティング・リソース・コホートに関連するコンピューティング・リソースのメンバーシップならびに前記ＣＥＥＣコホートに関連するＣＥＥＣのメンバーシップを管理する、請求項６７記載の方法。
【請求項６９】
ＣＥＥＣマーケット・メーカ・サービスにより、買取側コンピューティング・リソースと売却側コンピューティング・リソースの間でＣＥＥＣを交換するためにＣＥＥＣ市場に関連するトランザクションを実行すること
をさらに含む、請求項６６ないし６８のいずれかに記載の方法。
【請求項７０】
前記買取側コンピューティング・リソースが、前記売却側コンピューティング・リソースによって売却されるＣＥＥＣの１つまたは複数の条件を満足するために使用可能なコンピューティング・リソースを有する買取側コンピューティング・リソース・コホートを含み、前記売却側コンピューティング・リソースが、売却される前記ＣＥＥＣの前記条件が前記売却側コンピューティング・リソース・コホートに関連する前記コンピューティング・リソースの使用状況によって満足されないことをそれに関するコンピューティング・リソース使用状況メトリック情報が示す売却側コンピューティング・リソース・コホートを含む、請求項６９記載の方法。
【請求項７１】
トランザクション・ビルダのユーザ・インターフェースを使用して、ユーザにより、トランザクション・プロファイルを指定することであって、前記トランザクション・プロファイルが、前記トランザクション・プロファイルのインスタンスを実行するための買取側コンピューティング・リソースおよび売却側コンピューティング・リソースの特性を指定すること
をさらに含む、請求項６６ないし７０のいずれかに記載の方法。
【請求項７２】
前記ＣＥＥＣマーケット・メーカ・サービスが、買取側コンピューティング・リソースおよび売却側コンピューティング・リソースの前記特性に従って前記買取側コンピューティング・リソースおよび売却側コンピューティング・リソースを選択する、請求項７１記載の方法。
【請求項７３】
ユーザが、前記トランザクション・ビルダの前記ユーザ・インターフェースを使用して、前記トランザクション・プロファイルの事業目標基準を指定し、前記事業目標基準が、前記トランザクション・プロファイルのインスタンスの前記実行の完了を承認するための基準を指定する、請求項７１または請求項７２に記載の方法。
【請求項７４】
前記ＣＥＥＣマーケット・メーカ・サービスが、前記事業目標基準に基づいて前記トランザクション指定のインスタンスに関連するコストを決定し、前記ＣＥＥＣマーケット・メーカ・サービスが、前記トランザクションの前記インスタンスに関連する前記コストに基づいて前記トランザクション指定の前記インスタンスの完了を許可するかどうかを判断する、請求項７１ないし７３のいずれかに記載の方法。
【請求項７５】
組織の１つまたは複数のサイトのそれぞれが複数のコンピューティング・リソースを含み、前記組織の前記１つまたは複数のサイトに関連する１つまたは複数の情報技術管理ウェアハウス・システムにより、前記１つまたは複数の情報技術ウェアハウス・システムが関連付けられるサイトの前記複数のコンピューティング・リソースからコンピューティング・リソース使用状況メトリック情報を収集すること
をさらに含む、請求項６６ないし７４のいずれかに記載の方法。
【請求項７６】
作業負荷管理サービスにより、前記コンピューティング・リソース・コホートに対する前記ＣＥＥＣコホートの関連付けに基づいて作業負荷をコンピューティング・リソースに経路指定すること
をさらに含む、請求項６６ないし７５のいずれかに記載の方法。
【請求項７７】
インターフェースにより、前記組織の組織構造に関する情報を提供する既存の組織的コンピューティング・システムと前記データベース・システムとのインターフェースを取ることであって、前記ＣＥＥＣコホートの前記ＣＥＥＣおよび前記コンピューティング・リソース・コホートの前記コンピューティング・リソースに対応する前記データベース・システムに関連する項目が、前記既存の組織的コンピューティング・システムから入手した前記組織の前記組織構造に関する情報を含むように、前記インターフェースを使用して更新されること
をさらに含む、請求項６６ないし７６のいずれかに記載の方法。
【請求項７８】
コンピューティング・リソースの使用を管理するための装置であって、
１つまたは複数のＣＥＥＣを生成するように動作可能なコンピューティング環境受給権契約（ＣＥＥＣ）マネージャであって、それぞれのＣＥＥＣが複数の条件を含み、ＣＥＥＣの前記条件が、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定する、コンピューティング環境受給権契約（ＣＥＥＣ）マネージャと、
１つまたは複数のコホート・プロファイルを生成するように動作可能なコホートおよびプロファイル・マネージャであって、それぞれのコホート・プロファイルが、１つのコホートに関連付けるためにそのコホートのそれぞれのメンバーが含む、そのコホートの共通特性を指定する、コホートおよびプロファイル・マネージャと、
前記コホートおよびプロファイル・マネージャによって生成された１つまたは複数のプロファイルに基づいて、前記複数のコンピューティング・リソースからのコンピューティング・リソースのグループを表すコンピューティング・リソース・コホートを定義し、前記コホートおよびプロファイル・マネージャによって生成された１つまたは複数のプロファイルに基づいて、ＣＥＥＣのグループを表すＣＥＥＣコホートを定義するように動作可能なコホート管理サービスと、
前記複数のコンピューティング・リソースに対応するデータ、前記１つまたは複数のＣＥＥＣ、および前記定義されたコンピューティング・リソース・コホートおよびＣＥＥＣコホートに基づくコンピューティング・リソースとＣＥＥＣとの関連付けを保管するためのデータベース・システムと
を含む、装置。
【請求項７９】
請求項１ないし１２、請求項１４ないし２５、請求項２７ないし３８、請求項４０ないし５１、請求項５３ないし６４、および請求項６６ないし７７のいずれかに記載のすべてのステップを実行するように適合されたプログラム・コード手段を含む、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、一般に、改良されたデータ処理装置および方法に関し、より具体的には、確立されたコンピューティング環境受給権契約（computing environment entitlement contract）に従って組織のコンピューティング・リソース（computing resource）を管理するためのメカニズムに関する。
【背景技術】
【０００２】
コンピューティング・リソースへの投資は、現代社会では大規模組織に関する重要な諸経費を表すものである。米国連邦政府、政府の個々の部門および機関、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ社、バンク・オブ・アメリカ、ゼネラル・エレクトロニック社、シティグループなどの企業、ならびにその他多数などの大規模組織は、様々なタイプ、構成、機能、および効率レベルの何千ものコンピュータを有する可能性がある。これらの組織がこれらのコンピューティング・リソースを効率よく最適に利用するようにこれらのコンピューティング・リソースをすべて管理することは困難な作業である。これらのコンピューティング・リソースの効率的かつ最適な利用は、廃止（decommission）および交換のために、使用されないか、十分使用されていないか、または単純に時代遅れの技術を識別することを含む。
【０００３】
ある組織のコンピューティング・リソースを最適化することに対する重大なハードルの１つは、組織の職員が変化を嫌がることである。すなわち、職員に対してコンピューティング・リソース、たとえば、ラップトップ、デスクトップ・コンピュータなどが支給される場合、そのコンピューティング・リソースを完全に自分専用のものと見なし、すなわち、その従業員が実際にこれらのコンピューティング・リソースを使用しているかどうかにかかわらず、その従業員がそのコンピューティング・リソースに対する１００％の受給権を有すると考える。これは、従業員がコンピューティング・リソースを必要とする場合、その従業員がこれらのコンピューティング・リソースに対する１００％の受給権を有するのでそのコンピューティング・リソースが使用可能になるという信頼感を従業員に与えるものである。その結果、その従業員は、共用コンピューティング・リソース環境、たとえば、仮想化コンピューティング環境など、コンピューティング・リソースについて１００％未満の受給権が与えられると感じるようなその他のコンピュータ・リソースのためにこれらのコンピューティング・リソースを断念することを嫌がる。すなわち、その従業員がコンピューティング・リソースを使用していないかまたは少なくとも完全に使用しているわけではない可能性がある場合でも、必要なときに新しいコンピューティング・リソースが使用可能にならないリスクを冒すよりはむしろ、これらのコンピューティング・リソースがどの程度非効率または時代遅れであるかにかかわらず、そのコンピューティング・リソースが自分にとって使用可能になるという保証を保持したいので、これらのコンピューティング・リソースを断念しない。
【０００４】
さらに、既知のメカニズムは、コンピューティング・リソースを従業員に割り振るが、従業員がこれらのコンピューティング・リソースを与えられた事業目的を達成するためにそのコンピューティング・リソースを使用しているかどうかを判断するメカニズムを備えてない。したがって、往々にして、コンピューティング・リソースがある従業員に割り振られ、その従業員がそのコンピューティング・リソースを使用するが、そのコンピューティング・リソースが意図された事業目的を達成するために使用していない可能性があり、実際に他の目的のためにコンピューティング・リソースを使用している可能性がある。したがって、コンピューティング・リソースが使用されているように見える可能性があるが、実際には組織に利するために使用されていない。このような状況を検出し、組織に対するコンピューティング・リソース割り振りの利益を最適化するように処理するための既知のメカニズムはまったく存在しない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
新しいコンピューティング・リソースで従業員の要求が満たされるという信頼感を与えるような方法で、新しいコンピューティング・リソースのために、使用されないか、十分使用されていないか、または時代遅れのコンピューティング・リソースを放棄するよう従業員を奨励するためのメカニズムが必要である。その上、コンピューティング・リソースが割り振られた事業目的を達成するためにそのコンピューティング・リソースが使用されていないという状況を検出し、全体として組織の利益になるようにコンピューティング・リソースの割り振りを最適化するようにこのような状況を処理するためのメカニズムが必要である。
【０００６】
さらに、現在、原子的作業負荷の実行を越えるコンピューティング・リソースの「使用」を定義するためのサポートは弱いものである。コンピューティング・リソースの「使用」は、そのユーザが考えるように、一般に、秒単位ではなく月単位の時間尺度で行われ、任意の数の異なる交互配置作業負荷をカプセル化し、複数日という持続期間になる可能性のある予想不使用期間を含むものである。したがって、「使用」がこのように定義される環境の最適化は、原子的作業負荷に関する実行環境を単純に見つけることよりかなり入り組んだものになる。
【課題を解決するための手段】
【０００７】
例示的な一実施形態では、少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースを含むデータ処理システムにおいて、データ処理システムのコンピューティング・リソースを予約するための方法が提供される。この方法は、少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を確立することを含み、それぞれのＣＥＥＣデータ構造が契約当事者（contracting party）とデータ処理システムのプロバイダとの間のビジネス・レベル協定（business level agreement）の条件を定義する。ＣＥＥＣの条件は、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定する。
【０００８】
この方法は、少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のコンピューティング・リソースのセットをＣＥＥＣデータ構造に関連付けることをさらに含む。その上、この方法は、少なくとも１つのコンピューティング・デバイスにより、関連付けられたＣＥＥＣデータ構造に従って１つまたは複数のコンピューティング・リソースのセットを管理することを含む。おおよそ指定の期間の間、おおよそ指定のレベルおよびパターンの強度で、指定の目的のために、選択されたコンピューティング・リソース・コホート（cohort）内のコンピューティング・リソースを契約当事者が使用し損なったことに応答して、データ処理システムのロジックがＣＥＥＣデータ構造を無効にする。
【０００９】
他の例示的な諸実施形態では、コンピュータ可読プログラムを有するコンピュータ使用可能または可読媒体を含むコンピュータ・プログラム製品（computer program product）が提供される。このコンピュータ可読プログラムは、コンピューティング・デバイス上で実行されると、方法の例示的な実施形態に関して上記で概説した動作のうちの様々なものおよびその動作の組み合わせをコンピューティング・デバイスに実行させる。
【００１０】
さらに他の例示的な実施形態では、システム／装置が提供される。このシステム／装置は、１つまたは複数のプロセッサと、１つまたは複数のプロセッサに結合された１つまたは複数のメモリとを含むことができる。この１つまたは複数のメモリは、１つまたは複数のプロセッサによって実行されると、方法の例示的な実施形態に関して上記で概説した動作のうちの様々なものおよびその動作の組み合わせを１つまたは複数のプロセッサに実行させる命令を含むことができる。
【００１１】
本発明の上記その他の特徴および利点は、本発明の諸実施形態例に関する以下の詳細な説明に記載されるか、あるいはその詳細な説明を考慮すると当業者にとって自明なものになる。
【００１２】
本発明ならびにその好ましい使用態様および追加の目的および利点は、添付図面に併せて読んだときに例示的な諸実施形態に関する以下の詳細な説明を参照することにより最も良く理解されるであろう。
【図面の簡単な説明】
【００１３】
【図１】例示的な諸実施形態の諸態様を実現することができる分散データ処理システムの図の例である。
【図２】例示的な諸実施形態の諸態様を実現することができるコンピューティング・デバイスの図の例である。
【図３】例示的な一実施形態によりコンピューティング環境受給権契約ベースの管理システムを実現するための１次動作コンピューティング・デバイスの図の例である。
【図４】例示的な一実施形態によりコンピューティング環境受給権契約（ＣＥＥＣ）データ構造の図の例である。
【図５】例示的な一実施形態によりコホートの関連付けを生成するための動作例を概説する流れ図である。
【図６】例示的な一実施形態によるコホート・プロファイル・データ構造の図の例である。
【図７】例示的な一実施形態によりコンピューティング・リソース使用状況スコアを生成するための動作例を概説する流れ図である。
【図８】例示的な一実施形態によりコホートの模範（exemplar）および逆模範（counter-exemplar）メンバーを選択し、この選択を使用して、プロファイル内の評価基準および関連アクションを定義するための動作例を概説する流れ図である。
【図９】例示的な一実施形態によりＣＥＥＣ遵守（compliance）を評価するための動作例を概説する流れ図である。
【図１０】例示的な一実施形態によりＣＥＥＣマーケット・メーカ（market maker）・ベースのシナリオの一例に関するトランザクションの様々なフェーズを示す図の例である。
【図１１】例示的な一実施形態によりＣＥＥＣマーケット・メーカ・ベースのシナリオの一例に関するトランザクションの様々なフェーズを示す図の例である。
【図１２】例示的な一実施形態によりＣＥＥＣマーケット・メーカ・ベースのシナリオの一例に関するトランザクションの様々なフェーズを示す図の例である。
【図１３】例示的な一実施形態によりＣＥＥＣマーケット・メーカ・ベースのシナリオの一例に関するトランザクションの様々なフェーズを示す図の例である。
【図１４】例示的な一実施形態によるトランザクション指定の図の例である。
【図１５】例示的な一実施形態によるトランザクション指定の図の例である。
【図１６】例示的な一実施形態によるトランザクション指定の図の例である。
【図１７】例示的な一実施形態によりＣＥＥＣマーケット・トランザクションを実行するための動作例を概説する流れ図である。
【発明を実施するための形態】
【００１４】
例示的な諸実施形態は、確立されたコンピューティング環境受給権契約（ＣＥＥＣ）に従って組織のコンピューティング・リソースを管理するためのメカニズムを提供する。例示的な諸実施形態のメカニズムにより、ＣＥＥＣは組織の１つまたは複数のコンピューティング・リソースを有する契約当事者の対ごとに確立され、典型的に大規模組織は様々なタイプ、構成、機能、用途などの何百または何千ものコンピューティング・リソースを有する。ＣＥＥＣは、適切なコンピューティング・リソースを有する契約当事者を対にし、契約当事者が関連付けられているコンピューティング・リソースについて契約当事者の使用状況を評価し、適切なコンピューティング・リソースに契約当事者を動的に再割り振りし、マーケット・メーカ環境内のＣＥＥＣの買取側（buyer）と売却側（seller）を突き合わせ、以下に記載するようにその他のコンピューティング・リソース管理動作を実行するための基礎として使用される。これらのＣＥＥＣに基づくコンピューティング・リソースの管理の結果として、組織のコンピューティング・リソースの使用状況を最適化するように、作業負荷の均衡化、移行、管理などを行うことができる。しかし、この作業負荷の管理、均衡化、移行などは、これらのＣＥＥＣに基づくコンピューティング・リソースの管理の結果であり、効率を達成するための１次メカニズムではない。すなわち、最適化の対象は管理されたコンピューティング環境の全体であり、任意の所与の作業負荷実行はそのうちの小さな部分であり、本質的にしかも自然にＣＥＥＣを定義するものではない。
【００１５】
ＣＥＥＣは、所与の期間の間、所与のレベルおよびパターンの使用強度（intensity of utilization）で、所与の事業目的のために、所与の方法で構成された（その結果、コンピューティング環境を定義する）１つまたは複数のコンピューティング・リソース（たとえば、ハードウェアあるいはソフトウェアまたはその両方のリソース）のセットを、所与の契約当事者、たとえば、個人、団体、部門、部局、企業などが使用するという明示的な合意である。この所与のレベルは、たとえば、使用量（amount of utilization）の最小、最大、平均、またはその他の表現として表すことができる。使用強度のパターンは、所与の期間において１つまたは複数の指定の間隔で複数の所与のレベルの使用状況に関して定義することができる。ＣＥＥＣは、コンピューティング・リソースのあるセットから他のセットにＣＥＥＣを移行するための移行機能を制限する移行基準をさらに定義することができる。それぞれのＣＥＥＣは、以下に明記したコンピューティング・リソース管理動作を達成するために例示的な諸実施形態の１つまたは複数のハードウェアあるいはソフトウェアまたはその両方のメカニズムによってアクセス可能な１つまたは複数のデータ構造で定義することができる。
【００１６】
例示的な諸実施形態によるデータ処理システムは、識別された契約当事者がＣＥＥＣに指定されたコンピューティング・リソースのセットを指定の事業目的に実際に使用しているかどうかにかかわらず、そのコンピューティング・リソースのセットまたはそのコンピューティング・リソースのセットの一部分が識別された契約当事者による使用のために予約され、契約当事者がＣＥＥＣの条件内で指定の事業目的のためにそのコンピューティング・リソースのセットを使用し損なった場合にＣＥＥＣが無効化されるように、データ処理システムおよび識別された契約当事者の両方についてＣＥＥＣを執行するためのロジックを含む。すなわち、契約当事者がＣＥＥＣに基づくコンピューティング・リソースを実際に使用するかどうかにかかわらず、ＣＥＥＣはコンピューティング・リソースのプロバイダ側で執行可能である。しかし、同時に、契約当事者がＣＥＥＣの条件に従ってＣＥＥＣの対象であるコンピューティング・リソースを使用し損なった場合、ＣＥＥＣは、コンピューティング・リソースのプロバイダまたは契約当事者のいずれでも執行可能にならないように、データ処理システムによって無効にするかまたは否定することができる。典型的に、このような否定は、このＣＥＥＣを、契約当事者によるコンピューティング・リソースの使用により適した新しいＣＥＥＣで置き換えることと結合され、新しいＣＥＥＣはおそらくこの時点で否定されたＣＥＥＣに関連する１つまたは複数のコンピューティング・リソースの以前のセットとは異なる可能性のある１つまたは複数のコンピューティング・リソースの新しいセットに関連付けられる。ＣＥＥＣの否定に関する権限は、コンピューティング・リソースを最終的に所有し、その使用による恩恵を受け、本発明の例示的な諸実施形態のうちの１つまたは複数のメカニズムを採用した企業／組織によって提供される。
【００１７】
また、ＣＥＥＣは、それによりマーケット・メーカ・メカニズム内でコンピューティング・リソースに対する受給権の価格査定および取引を実行できるメカニズムも提供する。このマーケット・メーカ・メカニズムは、ＣＥＥＣならびに、その結果、それに関連する作業負荷および機能を交換するためのマーケットを確立するが、これは「自由市場」ではない。これは、特定の組織によって所有されるマーケットであり、特定の組織の特定の利益になるように管理される。すなわち、自由市場システムのように最高入札者を単純に決定するのではなく、例示的な諸実施形態のＣＥＥＣマーケット・メーカは、特定の組織が確立されたマーケット内でＣＥＥＣの買取側と売却側を突き合わせるための好みを定義できるようにすることができる。したがって、マーケットを介して実行された取引によってその価値が強化され認識されることを保証するために、特定の企業／組織によって市場要因が利用される。
【００１８】
ＣＥＥＣベースのコンピューティング・リソース管理システム内のＣＥＥＣおよびその使用の単純な例は、企業、たとえば、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ社（ＩＢＭ）が従業員にラップトップ・コンピュータを提供することである。このシナリオでは、コンピューティング・リソースはラップトップ・コンピュータであると見なすことができ、契約当事者は従業員であると見なすことができ、コンピューティング・リソースのプロバイダは企業、すなわち、ＩＢＭ社である。従業員にラップトップを割り振る際に、従業員にラップトップを提供するためのプロバイダの要件、すなわち、コンピューティング・リソースに対する従業員の受給権と、所与の期間（たとえば、１年）の間、所与のレベルおよびパターンの使用強度（たとえば、月曜日〜金曜日の午前９時〜午後５時という勤務時間の間、約５０％の使用状況でのラップトップ・リソースの使用）で、所与の方法で構成され（たとえば、指定の事業目的を達成するためにハードウェアあるいはソフトウェアまたはその両方の特定のセットを有する）、指定の事業目的（たとえば、ソフトウェア開発）のためにラップトップを使用するための従業員の要件の両方を管理するためにＣＥＥＣが確立される。次に、このシステムは、ＣＥＥＣに従って従業員によるラップトップの使用状況をモニターし、ＣＥＥＣに指定された条件に基づいて、買取側と売却側との間のＣＥＥＣの移転、ＣＥＥＣの否定、従業員のための新しいＣＥＥＣの作成などを制御することができる。
【００１９】
たとえば、例示的な諸実施形態のデータ処理システムは、どの程度頻繁に従業員がラップトップを使用しているか、従業員がラップトップを使用しているときにどのプロセスが実行されるか、従業員がラップトップを使用しているときにラップトップのリソースのうちのどの程度が使用されるか、ならびにＣＥＥＣに基づくコンピューティング・リソース（ラップトップ）に関する従業員の使用状況を示す任意のその他のメトリクスを判断することにより、従業員によるラップトップの使用をモニターすることができる。このモニターにより、ＣＥＥＣに指定された条件の所与の許容範囲内で従業員がラップトップを使用しているかどうかを判断することができ、そうではない場合に従業員によるラップトップの実際の使用状況とＣＥＥＣに基づく予想使用状況との差異が、ＣＥＥＣの交換、ＣＥＥＣの否定、および新しいＣＥＥＣの作成、またはその他の管理動作を正当化するかどうかを判断することができる。ＣＥＥＣに関連する交換、否定、作成、またはその他の管理動作の結果、さらに、ＣＥＥＣに関連するコンピューティング・リソース（複数も可）がコンピューティング・リソース・プロバイダ、たとえば、ＩＢＭ社によって交換されるかまたはその他の方法で回収あるいは再配分またはその両方が行われる可能性がある。
【００２０】
この例は、２台のラップトップ、すなわち、基本的な営業時間中の伝統的なビジネス使用のための１台と、１月あたり１回程度の頻度で不定期の顧客向けデモに使用され、デモ間の使用がまったく期待されないもう１台について考慮するように拡張することができる。これらは、このパターンの使用強度について非常に異なる予想をカプセル化する２つの異なるＣＥＥＣである。
【００２１】
これは、中程度のレベルの強度、すなわち、２４／７で使用されると予想され、すべての時間帯について顧客にとって使用可能な顧客対応Ｗｅｂサイトをホストとして処理するサーバを追加するようにさらに拡張することができる。この場合も、まったく異なるＣＥＥＣがこのパターンの使用強度について非常に異なる予想をカプセル化する。
【００２２】
したがって、ＣＥＥＣは、特定の方法で構成された１つまたは複数のコンピューティング・リソースの特定のセット、すなわち、契約当事者によって使用される予定の特定のコンピューティング環境を提供するためのコンピューティング・リソースのプロバイダに関する要件を指定するだけでなく、契約当事者の規定の使用状況に関して契約当事者に関する要件も指定する。これは、いくつかの点で契約当事者間、たとえば、コンピューティング・リソースのユーザとプロバイダとの間の既知の契約関係とは著しく異なるものである。たとえば、コンピューティング・リソースのユーザとプロバイダとの間の既知の契約関係の１つはサービス品質保証制度（ＳＬＡ）として知られている。ＳＬＡにより、コンピューティング・リソースのプロバイダは、指定のレベルのサービスに対するユーザによる支払と引き替えに、特定のコンピューティング・リソースの指定なしに、一般的な点、たとえば、特定の帯域幅、ビット・レート、平均故障間隔、平均修復時間、ジッタなどに関して定義された特定のレベルのサービスを提供することが要求される。ユーザの側には、指定のレベルの強度または使用パターンで、任意の特定の事業目的のためになど、コンピューティング・リソースを使用するための要件はまったくなく、ユーザに関する唯一の要件は、ユーザが指定のレベルのサービスに対して支払うことである。
【００２３】
同様に、コンピューティング・リソースのユーザとプロバイダとの間のもう１つのタイプの契約関係は、たとえば、必要なビット・レート、遅延、ジッタ、パケット脱落確率、ビット誤り率など、全体としてシステム内のデータ・フローの特定のレベルのパフォーマンスの保証が提供される、サービス品質（ＱｏＳ）協定として知られている。この場合も、指定のレベルの強度または使用パターンで、特定の事業目的のためになど、システムを使用するための要件はユーザ側にはまったくない。ユーザに関する唯一の要件は、ユーザがこのサービス品質に対して支払うことである。
【００２４】
従来のクラウド・コンピューティング・メカニズムは、このようなＳＬＡまたはＱｏＳタイプの取り決めに基づくものである。すなわち、ユーザがクラウド・コンピューティング・リソース・プロバイダと契約する場合、そのユーザは一般的なレベルのサービスまたはサービス品質について契約しており、このレベルのサービスまたはサービス品質がどのように提供されるかについて心配しておらず、すなわち、このレベルのサービスまたはサービス品質を提供するためにどの特定のコンピューティング・リソースが使用されるかについて心配していない。ユーザは単に「クラウド」にアクセスし、クラウド・リソース・プロバイダがこのレベルのサービスまたはサービス品質を提供するために決定した方法がどのような方法であってもこの特定のレベルのサービスまたはサービス品質が提供されることを期待している。この場合も、任意の最小レベルの強度で、任意の最小使用パターンで、任意の特定の事業目的のためになど、クラウドのリソースを実際に使用するための要件はユーザ側にはまったくない。ユーザが実行する必要があるのは、クラウドから要求されたＳＬＡまたはＱｏＳに関する支払だけである。これを他の方法で説明すると、クラウドはリソースの使用について考慮する際に客観的（non-judgmental）であり、すなわち、割り振られたリソースのセットが使用される事業目標がある場合にその事業目標が何であるかについて把握せず心配もしない。これは、クラウドに資本を割り振る際の企業の目標とは対照的であり、すなわち、企業は特定の業績を達成することを期待してこのように実行する。
【００２５】
したがって、ＣＥＥＣと、契約当事者とコンピューティング・リソース・プロバイダとの間の既知の契約関係との主な相違点の１つは、ＣＥＥＣ内の契約当事者が規定のレベルでコンピューティング・リソース（複数も可）を使用しなければならないことであり、さもなければ、ＣＥＥＣについて否定または交換などが行われる可能性があり、契約当事者は、契約当事者がＣＥＥＣに基づいて保有していた関連のコンピューティング・リソース（複数も可）に対する契約当事者の受給権を放棄しなければならない可能性がある。既存のＣＥＥＣが否定された場合に新しいＣＥＥＣが生成される場合もあれば、既存のＣＥＥＣが１つまたは複数のコンピューティング・リソースの新しいセットに再関連付けされる場合もある。新しいＣＥＥＣまたは既存のＣＥＥＣの新しい関連付けは、どのコンピューティング・リソースが契約当事者によるコンピューティング・リソースの使用状況に最も密接に合致しているか、あるいは新しいＣＥＥＣまたは既存のＣＥＥＣに基づく要件に最も密接に合致しているか、またはその両方について判断するために、契約当事者によるコンピューティング・リソース（複数も可）の測定使用状況ならびにコンピューティング・リソースの機能、構成などに基づいて実行することができる。これはいずれも、以下に記載するように、ＣＥＥＣおよびコンピューティング・リソースのセットに対して作用するマーケット・メーカ・システムによって確立された組織のマーケット内で実行される。この組織のマーケットは、組織によって指定された基準によって定義されるように、契約当事者に対してコンピューティング・リソースの最も効率的な割り振りを達成することに関して定義される。例示的な諸実施形態の上記その他のメカニズムについて、以下により詳細に説明する。
【００２６】
当業者によって認識されるように、本発明は、システム、方法、またはコンピュータ・プログラム製品として実施することができる。したがって、本発明の諸態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはソフトウェアとハードウェアの諸態様を組み合わせる実施形態の形を取ることができ、いずれも本明細書では一般に「回路」、「モジュール」、または「システム」と呼ぶことができる。さらに、本発明の諸態様は、そこにコンピュータ使用可能プログラム・コードが実施されている任意の１つまたは複数のコンピュータ可読媒体に実施されたコンピュータ・プログラム製品の形を取ることができる。
【００２７】
１つまたは複数のコンピュータ可読媒体の任意の組み合わせを使用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体にすることができる。コンピュータ可読記憶媒体は、たとえば、電子、磁気、光、電磁、赤外線、または半導体のシステム、装置、またはデバイス、あるいは上記のものの任意の適切な組み合わせにすることができるが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例（非網羅的リスト）としては、１つまたは複数のワイヤを有する電気接続、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、光学記憶装置、磁気記憶装置、あるいは上記のものの任意の適切な組み合わせを含むであろう。本明細書の文脈では、コンピュータ可読記憶媒体は、命令実行システム、装置、またはデバイスによりあるいはそれに関連して使用するためのプログラムを収容または保管することができる任意の有形媒体にすることができる。
【００２８】
コンピュータ可読信号媒体は、たとえば、ベースバンド内でまたは搬送波の一部として、そこに実施されたコンピュータ可読プログラム・コードを含む伝搬データ信号を含むことができる。このような伝搬信号は、電磁、光、またはそれらの任意の適切な組み合わせを含むがこれらに限定されない様々な形のうちのいずれかを取ることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、命令実行システム、装置、またはデバイスによりあるいはそれに関連して使用するためのプログラムを通信、伝搬、または輸送することができる任意のコンピュータ可読記憶媒体にすることができる。
【００２９】
コンピュータ可読媒体上に実施されたプログラム・コードは、無線、有線、光ファイバ・ケーブル、無線周波数（ＲＦ）など、あるいはこれらの任意の適切な組み合わせを含むがこれらに限定されない任意の適切な媒体を使用して伝送することができる。
【００３０】
本発明の諸態様の動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ（ＪａｖａおよびすべてのＪａｖａベースの商標およびロゴはオラクル社あるいはその関連会社またはその両方の商標または登録商標である）、Ｓｍａｌｌｔａｌｋ（ＴＭ）、Ｃ＋＋などのオブジェクト指向プログラミング言語あるいは「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで作成することができる。プログラム・コードは、完全にユーザのコンピュータ上で、一部分はユーザのコンピュータ上で、スタンドアロン・ソフトウェア・パッケージとして、一部分はユーザのコンピュータ上でしかも一部分はリモート・コンピュータ上で、あるいは完全にリモート・コンピュータまたはサーバ上で実行することができる。後者のシナリオでは、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してリモート・コンピュータがユーザのコンピュータに接続される場合もあれば、（たとえば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに接続が行われる場合もある。
【００３１】
本発明の諸態様は、本発明の例示的な諸実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品の流れ図あるいはブロック図またはその両方に関連して以下に記載されている。流れ図あるいはブロック図またはその両方の各ブロックおよび流れ図あるいはブロック図またはその両方内の複数ブロックの組み合わせは、コンピュータ・プログラム命令によって実現可能であることが理解されるであろう。これらのコンピュータ・プログラム命令は、汎用コンピュータ、特殊目的コンピュータ、またはその他のプログラマブル・データ処理装置のプロセッサに提供し、コンピュータまたはその他のプログラマブル・データ処理装置のプロセッサにより実行された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／行為を実現するための手段を作成するようなマシンを生産することができる。
【００３２】
また、これらのコンピュータ・プログラム命令は、コンピュータ可読媒体に保管された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／行為を実現する命令を含む装置（article of manufacture）を生産するような特定の方法で機能するよう、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイスに指示することができるコンピュータ可読媒体に保管することもできる。
【００３３】
また、コンピュータ・プログラム命令は、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイス上にロードし、コンピュータまたはその他のプログラマブル装置上で実行された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／行為を実現するためのプロセスを提供するようなコンピュータで実行されるプロセスを生産するように、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイス上で一連の動作ステップを実行させることもできる。
【００３４】
図面内の流れ図およびブロック図は、本発明の様々な諸実施形態によるシステム、方法、およびコンピュータ・プログラム製品について可能な実現例のアーキテクチャ、機能、および動作を例示している。この点に関しては、流れ図またはブロック図内の各ブロックは、指定の論理機能（複数も可）を実現するための１つまたは複数の実行可能命令を含む、コードのモジュール、セグメント、または一部分を表すことができる。また、いくつかの代替実現例では、ブロック内に示された機能は図面内に示された順序から外れて行われる可能性があることにも留意されたい。たとえば、連続して示されている２つのブロックは、関係する機能次第で、実際にはほぼ同時に実行される場合もあれば、ときには逆の順序で実行される場合もある。また、ブロック図あるいは流れ図またはその両方の各ブロックおよびブロック図あるいは流れ図またはその両方内の複数ブロックの組み合わせは、指定の機能または行為を実行する特殊目的ハードウェアベースのシステムあるいは特殊目的ハードウェアとコンピュータ命令との組み合わせによって実現可能であることも留意されるであろう。
【００３５】
したがって、例示的な諸実施形態は、分散データ処理環境、単一データ処理装置などを含む、多種多様なタイプのデータ処理環境で使用することができる。例示的な諸実施形態の特定の要素および機能の記述のためのコンテキストを提供するために、図１および図２は、例示的な諸実施形態の諸態様を実現することができる環境例として以下に提供される。図１〜図２は例に過ぎず、本発明の諸態様または諸実施形態を実現することができる環境に関する制限を断言または暗示するためのものではないことを認識されたい。本発明の精神および範囲を逸脱せずに、描写されている環境に対して多くの変更を行うことができる。
【００３６】
次に図面に関連して説明すると、図１は、例示的な諸実施形態の諸態様を実現することができる分散データ処理システム例の図表現を描写している。分散データ処理システム１００は、例示的な諸実施形態の諸態様を実現することができる複数コンピュータのネットワークを含むことができる。分散データ処理システム１００は、分散データ処理システム１００内にまとめて接続された様々なデバイスおよびコンピュータ間の通信リンクを提供するために使用される媒体である少なくとも１つのネットワーク１０２を含む。ネットワーク１０２は、ワイヤ、無線通信リンク、または光ファイバ・ケーブルなどの接続を含むことができる。
【００３７】
描写されている例では、サーバ１０４およびサーバ１０６は、ストレージ・ユニット１０８とともにネットワーク１０２に接続されている。加えて、クライアント１１０、１１２、および１１４もネットワーク１０２に接続されている。これらのクライアント１１０、１１２、および１１４は、たとえば、パーソナル・コンピュータ、ネットワーク・コンピュータなどにすることができる。描写されている例では、サーバ１０４は、ブート・ファイル、オペレーティング・システム・イメージ、およびアプリケーションなどのデータをクライアント１１０、１１２、および１１４に提供する。描写されている例では、クライアント１１０、１１２、および１１４はサーバ１０４に対するクライアントである。分散データ処理システム１００は、図示されていない追加のサーバ、クライアント、およびその他のデバイスを含むことができる。
【００３８】
描写されている例では、分散データ処理システム１００は、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）というプロトコル・スイートを使用して互いに通信する複数ネットワークおよびゲートウェイの世界的集合を表すネットワーク１０２を含むインターネットである。インターネットの中心には、データおよびメッセージを経路指定する何千もの商用、行政、教育、およびその他のコンピュータ・システムからなる、大ノードまたはホスト・コンピュータ間の高速データ通信回線のバックボーンがある。当然のことながら、分散データ処理システム１００は、たとえば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）などのいくつかの異なるタイプのネットワークを含むように実現することもできる。上記のように、図１は、本発明の異なる諸実施形態に関するアーキテクチャ上の制限としてではなく、一例として意図されており、したがって、図１に示されている特定の諸要素は、本発明の例示的な諸実施形態を実現することができる環境に関する制限と見なしてはならない。
【００３９】
次に図２に関連して説明すると、例示的な諸実施形態の諸態様を実現することができる分散データ処理システム例のブロック図が示されている。データ処理システム２００は、本発明の例示的な諸実施形態に関するプロセスを実現するコンピュータ使用可能コードまたは命令が位置する可能性のある、図１のクライアント１１０などのコンピュータの一例である。
【００４０】
描写されている例では、データ処理システム２００は、ノースブリッジおよびメモリ・コントローラ・ハブ（ＮＢ／ＭＣＨ）２０２とサウスブリッジおよび入出力（Ｉ／Ｏ）コントローラ・ハブ（ＳＢ／ＩＣＨ）２０４とを含む、ハブ・アーキテクチャを使用する。処理装置２０６、メイン・メモリ２０８、およびグラフィックス・プロセッサ２１０はＮＢ／ＭＣＨ２０２に接続される。グラフィックス・プロセッサ２１０は、アクセラレイテッド・グラフィックス・ポート（ＡＧＰ）を介してＮＢ／ＭＣＨ２０２に接続することができる。
【００４１】
描写されている例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ２１２はＳＢ／ＩＣＨ２０４に接続する。オーディオ・アダプタ２１６、キーボードおよびマウス・アダプタ２２０、モデム２２２、読み取り専用メモリ（ＲＯＭ）２２４、ハードディスク・ドライブ（ＨＤＤ）２２６、ＣＤ−ＲＯＭドライブ２３０、ユニバーサル・シリアル・バス（ＵＳＢ）ポートおよびその他の通信ポート２３２、ならびにＰＣＩ／ＰＣＩｅデバイス２３４は、バス２３８およびバス２４０を介してＳＢ／ＩＣＨ２０４に接続する。ＰＣＩ／ＰＣＩｅデバイスとしては、たとえば、イーサネット・アダプタ、アドイン・カード、およびノートブック・コンピュータ用のＰＣカードを含むことができる。ＰＣＩはカード・バス・コントローラを使用し、ＰＣＩｅは使用しない。ＲＯＭ２２４は、たとえば、フラッシュ基本入出力システム（ＢＩＯＳ）にすることができる。
【００４２】
ＨＤＤ２２６およびＣＤ−ＲＯＭドライブ２３０はバス２４０を介してＳＢ／ＩＣＨ２０４に接続する。ＨＤＤ２２６およびＣＤ−ＲＯＭドライブ２３０は、たとえば、インテグレイテッド・ドライブ・エレクトロニクス（ＩＤＥ）またはシリアル・アドバンスト・テクノロジー・アタッチメント（ＳＡＴＡ）インターフェースを使用することができる。スーパー入出力（ＳＩＯ）デバイス２３６はＳＢ／ＩＣＨ２０４に接続することができる。
【００４３】
オペレーティング・システムは処理装置２０６上で実行される。オペレーティング・システムは、図２のデータ処理システム２００内の様々なコンポーネントを調整し制御する。クライアントとして、オペレーティング・システムは、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ７などの市販のオペレーティング・システムにすることができる（ＭｉｃｒｏｓｏｆｔおよびＷｉｎｄｏｗｓは米国、その他の国、またはその両方におけるマイクロソフト社の商標である）。Ｊａｖａプログラミング・システムなどのオブジェクト指向プログラミング・システムは、オペレーティング・システムに併せて実行することができ、データ処理システム２００上で実行されるＪａｖａプログラムまたはアプリケーションからオペレーティング・システムに呼び出しを行う（Ｊａｖａはオラクル社あるいはその関連会社またはその両方の商標である）。
【００４４】
サーバとして、データ処理システム２００は、たとえば、アドバンスト・インタラクティブ・エグゼクティブ（ＡＩＸ（Ｒ））オペレーティング・システムまたはＬＩＮＵＸオペレーティング・システムを実行するＩＢＭ（Ｒ）ｅＳｅｒｖｅｒ（ＴＭ）Ｓｙｓｔｅｍ  ｐ（Ｒ）コンピュータ・システムにすることができる（ＩＢＭ、ｅＳｅｒｖｅｒ、Ｓｙｓｔｅｍ  ｐ、およびＡＩＸは米国、その他の国、またはその両方におけるインターナショナル・ビジネス・マシーンズ社の商標であり、ＬＩＮＵＸは米国、その他の国、またはその両方におけるライナス・トルボールズの登録商標である）。データ処理システム２００は、処理装置２０６内に複数のプロセッサを含む対称型マルチプロセッサ（ＳＭＰ）システムにすることができる。代わって、単一プロセッサ・システムを使用することもできる。
【００４５】
オペレーティング・システム、オブジェクト指向プログラミング・システム、およびアプリケーションまたはプログラム用の命令は、ＨＤＤ２２６などのストレージ・デバイス上に位置し、処理装置２０６による実行のためにメイン・メモリ２０８にロードすることができる。本発明の例示的な諸実施形態に関するプロセスは、たとえば、メイン・メモリ２０８、ＲＯＭ２２４などのメモリ内、あるいは、たとえば、１つまたは複数の周辺装置２２６および２３０内に位置することができるコンピュータ使用可能プログラム・コードを使用して処理装置２０６によって実行することができる。
【００４６】
図２に示されているように、バス２３８またはバス２４０などのバス・システムは１つまたは複数のバスで構成することができる。当然のことながら、バス・システムは、任意のタイプの通信ファブリックまたはアーキテクチャに接続された異なるコンポーネントまたはデバイス間でデータの転送を可能にする、任意のタイプの通信ファブリックまたはアーキテクチャを使用して実現することができる。図２のモデム２２２またはネットワーク・アダプタ２１２などの通信ユニットは、データを送受信するために使用される１つまたは複数のデバイスを含むことができる。メモリは、たとえば、メイン・メモリ２０８、ＲＯＭ２２４、または図２のＮＢ／ＭＣＨ２０２内に見られるようなキャッシュにすることができる。
【００４７】
当業者であれば、図１〜図２のハードウェアが実現例次第で様々になる可能性があることを認識するであろう。フラッシュ・メモリ、同等の不揮発性メモリ、または光ディスク・ドライブなど、その他の内部ハードウェアまたは周辺装置は、図１〜図２に描写されているハードウェアに加えてまたはその代わりに使用することができる。また、例示的な諸実施形態のプロセスは、本発明の精神および範囲を逸脱せずに、前述のＳＭＰシステム以外のマルチプロセッサ・データ処理システムに適用することができる。
【００４８】
その上、データ処理システム２００は、クライアント・コンピューティング・デバイス、サーバ・コンピューティング・デバイス、タブレット・コンピュータ、ラップトップ・コンピュータ、電話またはその他の通信装置、携帯情報端末（ＰＤＡ）などを含む、いくつかの異なるデータ処理システムのいずれかの形を取ることができる。いくつかの例示的な例では、データ処理システム２００は、たとえば、オペレーティング・システム・ファイルあるいはユーザ生成データまたはその両方を保管するために不揮発性メモリを提供するようにフラッシュ・メモリで構成されたポータブル・コンピューティング・デバイスにすることができる。本質的に、データ処理システム２００は、アーキテクチャ上の制限なしに、任意の既知のまたは今後開発されるデータ処理システムにすることができる。
【００４９】
図１に示されているものまたはそれと同等のものなど、多くのネットワーク・ベースのシステムは、組織、たとえば、企業、政府、民間団体、またはその他の法人のコンピューティング・リソースのネットワークを生成するためにまとめて結合することができる。これらのコンピューティング・リソースは、コンピューティング・リソースの小さいセット、たとえば、数十〜数百のコンピューティング・リソースを含む場合もあれば、コンピューティング・リソースの大きいセット、たとえば、様々なタイプ、機能、構成などの数千のコンピューティング・リソースを含む場合もある。たとえば、コンピューティング・リソースは、デスクトップ・コンピュータから、ラップトップ・コンピュータ、プリンタ、ルータ、スイッチ、ストレージ・デバイス、コンピューティング・デバイス内の特定のプロセッサ、メモリまたはメモリの一部分、ネットワーク・デバイスまたは電気製品、あるいは任意のその他のコンピューティング・リソースに及ぶ可能性がある。これらのコンピューティング・リソースのそれぞれは、異なるタイプ、機能、構成などのものにすることができ、たとえば、その組織が数千のデスクトップ・コンピュータを有することができ、そのうちの一部がｘ８６プロセッサ・チップを有することができ、その他のものはセル・ブロードバンド・エンジン・プロセッサ・チップを有するものもあれば、Ｐ７プロセッサ・チップを有するものもあり、それぞれには異なる数のプロセッサ・コア、異なるソフトウェア・リソースがロードされる可能性があり、異なるタイプ、構成、および機能が提供されるようになっている。
【００５０】
その組織のコンピューティング・リソースのネットワークのうちの１つまたは複数のサーバまたはその他のコンピューティング・デバイスは、本明細書に記載された例示的な諸実施形態によりＣＥＥＣベースのコンピューティング・リソース管理システムを実現するためのハードウェアあるいはソフトウェアまたはその両方のメカニズムを提供するように構成することができる。たとえば、ＣＥＥＣを確立し、保管し、管理し、特定の契約当事者ならびにコンピューティング・リソースの１つまたは複数の特定のコホートにこれらのＣＥＥＣを関連付けるために、１つまたは複数のサーバあるいはネットワーク接続のストレージ・デバイスまたはその両方を提供することができる。いくつかの例示的な諸実施形態では、例示的な諸実施形態のメカニズムは、特定の契約当事者および特定のコンピューティング・リソースにＣＥＥＣを関連付けるために、人的資源システムなどの既存の組織的システムとのインターフェースを取ることができる。
【００５１】
その上、その組織のコンピューティング・リソースのネットワークのうちのコンピューティング・リソースに関する構成情報を入手し保管するための構成管理データベース（ＣＭＤＢ）システムとして、１つまたは複数のサーバあるいはネットワーク接続のストレージ・デバイスまたはその両方を提供することができる。加えて、その組織のコンピューティング・リソースのネットワークのうちの１つまたは複数のサーバまたはその他のコンピューティング・デバイスは、以下により詳細に説明するように、マーケット・メーカ・サービス、コホート管理サービス、使用状況スコアリング・サービス、トランザクション・ビルダ・サービス、コホートおよびプロファイル管理サービス、システム使用状況管理サービスなどを提供するように構成することができる。
【００５２】
ＣＥＥＣベースのリソース管理システムの概要
図３は、例示的な一実施形態によりコンピューティング環境受給権契約ベースの管理システムを実現するための１次動作コンピューティング・デバイスの図の例である。図３に示されている要素は、たとえば、サーバなどの１つまたは複数のコンピューティング・デバイスの１つまたは複数のプロセッサによって実行されるソフトウェア命令として実現することができる。いくつかの例示的な諸実施形態では、図３に示されているメカニズムのうちのいくつかは、たとえば、特定用途向け集積回路（ＡＳＩＣ）などの特殊目的ハードウェア・デバイスとして、または、たとえば、ファームウェアなどのハードウェアとソフトウェアの組み合わせとして、完全にコンピューティング・システムのハードウェア内で実現することができる。例示的な諸実施形態の範囲は、制限なしに、純粋にハードウェアの諸実施形態ならびに例示的な諸実施形態の特定の実現例に適切なものであると判断された任意の特定の構成でハードウェアとソフトウェアの組み合わせを含む諸実施形態を対象として含むものである。
【００５３】
図３に示されているように、コンピューティング環境受給権契約（ＣＥＥＣ）ベースのリソース管理システム３００は、１つまたは複数のＷｅｂアプリケーション・サーバ３１０の一部として提供されたトランザクション・ビルダ３１２、コホートおよびプロファイル・マネージャ３１４、システム使用状況マネージャ３１６、ならびにＣＥＥＣマネージャ３１８を含む。第２のＷｅｂアプリケーション・サーバ（ＷＡＳ）３２０は、マーケット・メーカ・サービス３２２、コホート管理サービス３２４、使用状況スコアリング・サービス３２６、およびＣＥＥＣベースの予約サービス３２８を含む、Ｗｅｂサービス３２２〜３２８で構成することができる。構成管理データベース３３２およびＣＥＥＣデータベース３３４を含むデータベース・システム３３０が提供される。加えて、データベース・システム３３０は、１つまたは複数の人的資源システムなど、その他の組織的システムまたはエンタープライズ・システム３４０とのインターフェースを取るためのインターフェース３３６を含むことができる。
【００５４】
システム３００は、１つまたは複数の情報技術管理ウェアハウス・システム３５２〜３５６を含む情報技術管理システム３５０をさらに含む。情報技術管理ウェアハウス・システム３５２〜３５６は、組織の様々なサイト・システム３６０〜３６４に関連するコンピューティング・リソースから使用状況情報を収集する。情報技術管理ウェアハウス・システム３５２〜３５６によって収集されたこのコンピューティング・リソース使用状況情報は、リソース使用状況の評価（使用状況スコアリング・サービス３２６などによる）、ＣＥＥＣベースのコンピューティング・リソース予約の実行（ＣＥＥＣベースの予約サービス３２８などによる）、ＣＥＥＣのマーケット・ベースの交換の実行（マーケット・メーカ・サービス３２２などによる）、コンピューティング・リソースのコホートおよびＣＥＥＣのコホートに関するコホート管理の実行（コホート管理サービス３２４などによる）のために、Ｗｅｂアプリケーション・サービス３２２〜３２８によって使用することができ、これらのすべてついては、以下により詳細に説明する。
【００５５】
データベース・システム３３０は、サイト・システム３６０〜３６４の様々なコンピューティング・リソースおよびＣＥＥＣの基本的な構成情報をＣＭＤＢ３３２およびＣＥＥＣデータベース３３４に保管し、これらのデータベースは、ＣＥＥＣに対する遵守を保証し、マーケット・トランザクションを実行し、コホート管理を実行し、リソース使用状況にスコアを付けるための様々な動作をＷｅｂアプリケーション・サービス３２０により実行するために、情報技術管理ウェアハウス３５２〜３５６から入手したリソース使用状況情報とともに使用される。ＣＭＤＢ３３２は、たとえば、様々なコンピューティング・リソースに関する日単位リソース使用状況メトリック情報、週単位リソース使用状況メトリック情報、使用状況スコアリング・サービス３２６から入手した公式リソース使用状況スコア、プロファイル指定、コホート指定、コホート割り当て、システム構成情報、およびシステム指定を含む、様々なテーブルまたは様々なタイプのその他のデータ構造を保管することができる。ＣＭＤＢ３３２に保管された情報は、コホートおよびプロファイル・マネージャ３１４、情報技術モニタリング・ウェアハウス３５２〜３５６、使用状況スコアリング・サービス３２６、コホート管理サービス３２４、および、チボリ構成マネージャ、チボリ・アプリケーション依存性発見マネージャ、ＨＰオープン・ビュー、ＭＳシステム・センター構成管理クライアントなどの構成走査および発見クライアントから入手することができる。プロファイル指定は、使用状況データを解釈するために使用されるプロファイルの属性であり、たとえば、最良または移動平均データを使用すべきか、週単位または日単位の時間尺度を使用すべきか、何日分の履歴を考慮すべきかなどの属性である。
【００５６】
ＣＥＥＣデータベース３３４に保管された情報は、ＣＥＥＣマネージャ・インターフェース３１８を介して指定されたＣＥＥＣの条件および基準のユーザ指定から入手することができる。また、この情報は、ＣＥＥＣデータベース３３４に記載されたＣＥＥＣに関連付けられるＣＥＥＣのコホートを識別するコホート管理サービス３２４から入手された情報で増強することもできる。その上、ＣＥＥＣは、ＣＥＥＣデータベース３３４を介して特定のコンピューティング・リソースまたはコンピューティング・リソースのコホートの特定のＩＤに関連付けることができる。ＣＥＥＣの内容については、以下により詳細に説明する。
【００５７】
Ｗｅｂアプリケーション・サービス３１０は、マーケット・メーカ・サービス３２２によるＣＥＥＣのマーケット・ベースの交換、コホートおよびプロファイル・マネージャ３１４によるコホートおよびプロファイル管理、システム使用状況マネージャ３１６によるシステム使用状況管理、ならびにＣＥＥＣマネージャ３１８によるＣＥＥＣ管理を実行する際に使用するために、トランザクション・ビルダ３１２によりトランザクションを構築することを含む様々な動作を実行するためにユーザ・アクセス可能なＷｅｂアプリケーション・サービスを提供する。これらの様々なユーザ・アクセス可能なＷｅｂアプリケーション・サービス３１０の使用については、以下により詳細に説明する。
【００５８】
コンピューティング環境受給権契約（ＣＥＥＣ）
例示的な諸実施形態が構築される基本要素はコンピューティング環境受給権契約（ＣＥＥＣ）である。ＣＥＥＣは、所与の期間の間、所与のレベルおよびパターンの使用強度で、指定の事業目的のために、特定の方法で構成された（コンピューティング環境を定義する）コンピューティング・リソース（たとえば、ハードウェア（ＣＰＵ、ＲＡＭ、ディスクＩＯ、ネットワークＩＯ、ディスク・ストレージなど）、ソフトウェア、物理的インフラストラクチャ（暖房、冷房、ラック・スペースなど）あるいはサービス（管理、ＩＴセキュリティ、バックアップなど）、またはこれらの組み合わせ）の特定のセットを、所与の契約当事者、たとえば、個人、団体、部門、部局、企業、またはその他の法人が使用するという明示的な合意である。ＣＥＥＣは、上記で概説したＣＥＥＣの特性を含むＣＥＥＣの様々な条件を指定する１つまたは複数のデータ構造に関して指定することができる。すなわち、１つまたは複数のデータ構造は、個別にまたは以下に記載するコンピューティング・リソースのコホートに関してのいずれかで、ＣＥＥＣが関連付けられたコンピューティング・リソースの特定のセットを指定する。１つまたは複数のデータ構造は、ＣＥＥＣが有効である指定のコンピューティング・リソースのハードウェア／ソフトウェアの特定の構成、ＣＥＥＣの特定の事業目的、所定の期間にわたる数量化可能なメトリクスに関する所与のレベルおよびパターンの使用強度、および以下に述べるようにＣＥＥＣの要件に適合していないことにより否定されない限りＣＥＥＣが有効である所与の期間をさらに指定する。加えて、１つまたは複数のデータ構造は、ＣＥＥＣの移行あるいは否定またはその両方に関する条件を指定することができる。
【００５９】
図４は、例示的な一実施形態によりＣＥＥＣデータ構造例の図の例である。図４に示されているように、ＣＥＥＣデータ構造４００は、ＣＥＥＣデータ構造４００が対応するＣＥＥＣの識別情報を指定するためのＣＥＥＣ  ＩＤフィールド４１０を含む。フィールド４１０内のＣＥＥＣ  ＩＤは、他のＣＥＥＣのコホート、コンピューティング・リソースのコホートにそのＣＥＥＣを関連付け、マーケット・メーカ・メカニズムによるＣＥＥＣの移行、ＣＥＥＣの否定および置き換えなどを含むその他の管理動作を実行する際に使用するためにＣＥＥＣを識別する固有のＩＤである。本質的に、ＣＥＥＣ  ＩＤは、例示的な諸実施形態のＣＥＥＣベースのリソース管理システムによって管理される他のＣＥＥＣからこのＣＥＥＣを明確に区別するための方法として使用される。
【００６０】
ＣＥＥＣデータ構造４００は、ＣＥＥＣが関連付けられた契約当事者または契約当事者のグループを明確に識別するために契約当事者ＩＤを保管する契約当事者ＩＤフィールド４２０をさらに含む。たとえば、フィールド４２０内の契約当事者ＩＤは、固有の従業員ＩＤ、部門または作業グループＩＤ、ユーザＩＤなどにすることができる。この契約当事者ＩＤは、人的資源システムなどの他のエンタープライズ・システムからの情報を相関させるために使用することができ、その結果、これらの他のシステムからの情報をＣＥＥＣデータ構造４００によって識別されたＣＥＥＣに関連付けることができる。また、この契約当事者ＩＤは、使用状況メトリック情報あるいはこのような使用状況メトリック情報から入手したスコアリング・メトリクスまたはその両方を、たとえば、特定の契約当事者および対応するＣＥＥＣに相関させるために使用することもできる。
【００６１】
ＣＥＥＣデータ構造４００は、ＣＥＥＣが関連付けられたコンピューティング・リソース（複数も可）、コンピューティング・リソース・コホート、またはコンピューティング・リソース（複数も可）の他のグループ、ならびにそれらに関連する必須ハードウェア／ソフトウェア構成を明確に識別するための１つまたは複数のコンピューティング・リソースＩＤフィールド４３０をさらに含む。すなわち、たとえば、ある組織のデータ・ネットワーク（複数も可）のコンピューティング・リソース（複数も可）は以下に説明するようにコホートに編成することができ、そのＣＥＥＣはそのコンピューティング・リソースのコホートに関連付けることができる。代わって、ＣＥＥＣは、特定のコンピューティング・リソース、たとえば、ラップトップ、デスクトップ・コンピュータなどに関連付けることができる。特定の構成情報は、たとえば、プロセッサの数およびタイプ、使用可能メモリの量、使用可能な帯域幅の量、インストールされた特定のソフトウェア・パッケージ、またはそのためにＣＥＥＣが確立された事業目的を指定するために必要な任意のその他の識別可能構成要素を指定することができる。
【００６２】
加えて、ＣＥＥＣデータ構造４００は、ＣＥＥＣに従ってフィールド４３０で識別されたコンピューティング・リソース（複数も可）を使用することができる１つまたは複数の指定の事業目的を識別するための１つまたは複数のフィールド４４０をさらに含む。すなわち、ある組織のプロジェクト、作業グループ、部門、またはその他の組織的区分は、その組織的区分が充てられる事業目的のＩＤ、たとえば、ソフトウェア開発、特定のプロジェクト、会計、管理、人的資源などに関する固有のＩＤに関連付けることができる。また、特定のコンピューティング・リソースもこれらの事業目的ＩＤに関連付けることができ、たとえば、特定のソフトウェア・パッケージを特定の事業目的ＩＤに関連付けることができ、たとえば、ＸＹＺ会計ソフトウェアは「会計」に対応する事業目的ＩＤに関連付けることができ、ＸＹＺワード・プロセシング・ソフトウェアは「管理」などの事業目的ＩＤに関連付けることができる。特定のコンピューティング・リソース、コンピューティング・リソースのコホートなどは、２つ以上の事業目的ＩＤに関連付けることができる。その上、一般にすべての事業分野に使用されるコンピューティング・リソース、たとえば、ワード・プロセシング・ソフトウェア、特定のサーバ・コンピューティング・デバイスなどのために、総称事業目的ＩＤをさらに提供することができる。フィールド４４０は、フィールド４３０で識別されたコンピューティング・リソースをどの事業目的に使用できるかをＣＥＥＣが識別するように、ＣＥＥＣが関連付けられた事業目的ＩＤを含むことができる。
【００６３】
ＣＥＥＣデータ構造４００は、ＣＥＥＣの条件を満足するためにコンピューティング・リソース構成要件を指定するための１つまたは複数のフィールド４５０と、フィールド４３０に指定されたコンピューティング・リソースを使用するために契約当事者が要求される所与の期間に関する所与のレベルおよびパターンの使用強度を指定するための１つまたは複数のフィールド４６０とをさらに含む。使用強度のレベルおよびパターンは、多種多様な方法で指定することができるが、一般に、ＣＥＥＣの条件および要件に従って契約当事者がコンピューティング・リソースを使用するために指定の期間について要求される、フィールド４３０に指定されたコンピューティング・リソースの使用量を指定するためのものである。たとえば、フィールド４６０は、契約当事者がＣＥＥＣの条件を遵守するために、平日の午前９時〜午後５時の間の少なくとも５０％の時間、指定の事業目的にコンピューティング・リソースを使用する必要があることを指定することができる。使用状況パターンは、パーセンテージによる許容範囲などの許容変動とともに、日単位、週単位、および月単位のピーク／トラフの高さおよび持続期間を記述することができる、模範システムに関して定義することができる。このようなパターンは、直接または、たとえば、可視化インターフェースによるかのいずれかで、数値的に記録することができる。
【００６４】
ＣＥＥＣデータ構造４００は、任意選択で、１つのコンピューティング・リソース、コンピューティング・リソースのコホートなどからＣＥＥＣを移行するために移行基準を指定するためのフィールド４７０をさらに含むことができる。たとえば、フィールド４７０は、ＣＥＥＣデータ構造４００を移行、すなわち、再関連付けすることができるコンピューティング・リソースのタイプ、これらのコンピューティング・リソースの最小要件または構成、ＣＥＥＣデータ構造４００を移行することができる特定の条件などを指定することができる。たとえば、ｘ８６ＣＰＵとともに３ギガのＲＡＭおよび５００ギガのローカル・ストレージを使用し、Ｗｉｎｄｏｗｓサーバ２００８を実行し、部門別ストレージ・サーバとして動作するデスクトップ・ワークステーションは、ｘ８６またはｘ８６−６４ＣＰＵ上で実行し、３ギガ以上の使用可能メモリを備えた仮想化クラスタのみに移行できるであろう。さらに、ＣＥＥＣは、たとえば、４００ワットというデスクトップ消費ワット数とは対照的に、移行先で消費されるワット数（加重平均）が５０ワット以下であることを指定できるであろう。
【００６５】
ＣＥＥＣデータ構造４００によって記述されるＣＥＥＣは不可分な実体ではないが、その代わりに、様々なコンピュータ・リソース・プロバイダがＣＥＥＣの条件を満足するために必要なコンピュータ・リソースを提供するために協力できるように、区分化することができる。すなわち、ＣＥＥＣは２当事者間、すなわち、単一コンピューティング・リソース・プロバイダと単一契約当事者との間で確立しなければならないわけではないが、３者またはそれ以上の当事者間で確立することができる。したがって、たとえば、一方のコンピューティング・リソース・プロバイダがＣＥＥＣの条件のうちの第１のサブセット（たとえば、プロセッサ・スループット）を満足することができ、第２のコンピューティング・リソース・プロバイダがＣＥＥＣの条件のうちの第２のサブセット（たとえば、記憶容量）を満足することができる場合、そのＣＥＥＣは、個別のコンピューティング・リソース・プロバイダによって別々に満足しなければならない元のＣＥＥＣの各条件ごとに１つずつ、個別のサブＣＥＥＣに区分化することができる。これにより、以下により詳細に説明するように、ＣＥＥＣマーケットを介して「売却」されているＣＥＥＣの要件のすべてを単一の「買取側」が満足できなければならないという要件がなくなるので、ＣＥＥＣマーケットにおいてトランザクションが成功する機会が増加する。既知の作業負荷管理メカニズムは典型的に、不可分である全体として作業負荷を移動するので、これは、例示的な諸実施形態のＣＥＥＣメカニズムとこのような既知の作業負荷管理メカニズムをさらに区別するものである。
【００６６】
例示的な諸実施形態のＣＥＥＣデータ構造４００は、特権ユーザが１つまたは複数のコンピューティング・リソースを特定の契約当事者に割り振りたいと希望するときに、システム管理者またはその他の特権ユーザによって作成することができる。他の事例では、以下により詳細に説明するように、既存のＣＥＥＣを否定し、否定されたＣＥＥＣを置き換えＣＥＥＣで置き換える必要性が存在するという判断に応答する場合など、ＣＥＥＣデータ構造４００をＣＥＥＣベースのリソース管理システムによって自動的に作成することができる。特権ユーザがＣＥＥＣデータ構造４００を作成しているものであると想定すると、このＣＥＥＣデータ構造４００は、たとえば、図３のＣＥＥＣマネージャ３１８によって提供できるようなユーザ・インターフェースを介して作成することができる。このユーザ・インターフェースにより、当技術分野で一般的に知られているセキュリティ・ログイン手順を使用してＣＥＥＣマネージャにログインすることができる特権ユーザに対して、コンピューティング・リソース、コンピューティング・リソースのコホート、契約当事者情報の様々なリストとともに、ＣＥＥＣデータ構造４００のフィールド４１０〜４７０の様々なその他のパラメータを指定するためのオプションを提示することができる。このようなリストに入力するための情報は、たとえば、図３のシステム３００のＣＭＤＢ３３２、コホート管理サービス３２４、使用状況スコアリング・サービス３２６、あるいはその他の要素、またはこれらの組み合わせから入手することができる。結果として得られるＣＥＥＣデータ構造４００は、以下に説明するように、ＣＥＥＣベースのリソース管理動作を実行するためにシステム３００のその他の要素によって後でアクセスするために図３のＣＥＥＣデータベース３３４に保管することができる。
【００６７】
したがって、ＣＥＥＣは、例示的な諸実施形態のシステムにおいてリソース管理を実行するための基礎を形成する。ＣＥＥＣは、特定の方法で構成された特定のコンピューティング・リソースを提供するためのコンピューティング・リソース・プロバイダ側の義務だけでなく、指定のレベルおよびパターンの使用強度で特定の事業目的にこれらのコンピューティング・リソースを使用するための契約当事者の義務も定義するという点で、その他のコンピューティング・リソースの取り決めとは異なる。既知のコンピューティング・リソースの取り決めは、一般的なコンピューティング・リソースの能力、たとえば、帯域幅、記憶容量などを提供するためにプロバイダに対して義務を負わせるが、特定のコンピューティング・リソースおよびその特定の構成を識別せず、より重要なことに、契約当事者の側の使用要件を指定しない。それとは反対に、契約当事者側の唯一の義務は、契約当事者がこれらのコンピューティング・リソースを実際に使用するかどうかにかかわらず、これらのコンピューティング・リソースの使用のレベルまたはパターンまたは強度にかかわらず、そしてその使用の事業目的にかかわらず、コンピューティング・リソースに対する支払を行うことである。
【００６８】
ＣＥＥＣを基礎として使用して、システム３００は、リソースおよび契約当事者受給権管理を実行するためにＣＥＥＣに対して作用するためのロジックを含む。このロジックは、その条件に対する遵守を判断すること、ＣＥＥＣを否定し置き換える必要性を判断すること、ＣＥＥＣのあるコホートあるいはコンピューティング・リソースのあるコホートまたはその両方から他のものにＣＥＥＣを移行する必要性を判断すること、ＣＥＥＣの否定、置き換え、および移行を容易にするためにマーケット・メーカ・メカニズムを提供することを含み、コンピューティング・リソース・プロバイダおよび契約当事者の両方に対してＣＥＥＣの条件を執行するためのメカニズムを提供する。その上、この執行は、以下に記載するコホート・メカニズムなどにより、ＣＥＥＣとコンピューティング・リソースとの間の関連付けに従って（既存のまたは計画された）適切なコンピューティング・リソースに対する作業負荷を処理して経路指定することを含む。
【００６９】
例示的な諸実施形態のＣＥＥＣおよびＣＥＥＣメカニズムの一例として、特定の組織が「ＤＢ２パフォーマンス・テスト」という事業目的を有すると想定する。その上、このＤＢ２パフォーマンス・テストを実行するために、ＲＨＥＬサーバ５．５を実行し、１５００ワットを消費し、ギガビット・イーサネットおよびファイバ接続のＳＡＮストレージを備え、２４／７のオンコール管理サポートを備え、１６コア、６４ＧのＲＡＭ、１０テラバイトのシステムを有するコンピューティング環境が必要であると想定する。これらの条件は、ＣＥＥＣの条件において識別されると思われるすべての条件である。このＣＥＥＣの条件に基づいてこれらの要件を満たすコンピューティング・システム上で任意の数のＤＢ２パフォーマンス・テスト活動を実行することができ、このＣＥＥＣは本質的にＤＢ２パフォーマンス・テスト活動の目的を達成するためにこのコンピューティング・システム上で活動を実行するためにコンピューティング・システムのリソースに対するユーザの受給権を定義する。
【００７０】
ＤＢ２パフォーマンス・テストの作業負荷を異なるコンピューティング・システムに移行する予定である場合、まずＣＥＥＣを移行しなければならず、その結果、ユーザによって移行先コンピューティング・システムに対する信頼が発生する。移行先コンピューティング・システムは、新しいかまたは異なる資産（コンピューティング・システム）だけでなく、ＣＥＥＣに基づいて要求されるようにコンピューティング環境の必要な要素のすべてが提供されることを保証する新しいＣＥＥＣでも構成される。その上、ユーザは、ＣＥＥＣの自分の側を遂行するためにＤＢ２パフォーマンス・テストに関連する作業負荷を実行する義務を負い、すなわち、ユーザには、ビジネス使用、たとえば、ＤＢ２パフォーマンス・テストの出力と引き替えにコンピューティング環境が提供される。
【００７１】
例示的な諸実施形態は、それなしでは移行を行うための十分な自信を持てないと思われ、それなしでは拡張された時間尺度について定義された入力作業負荷の強度およびサイズが提供側に完全に通知されないと思われる、新しいＣＥＥＣに契約当事者を参加させることにより作業負荷（複数も可）の移行を容易にする。さらに、以下により詳細に説明するように、例示的な諸実施形態のＣＥＥＣマーケット・メーカ・メカニズムにより、組織または企業はトランザクションの両側に正しく価格査定することができるが、これは考慮中のものがいずれも計算作業負荷の配置である場合には不可能である。すなわち、既存の環境のコストに価格査定することができ、移行先環境のコストに価格査定することができ、ビジネス出力の価値に価格査定することができる。これらの価格は、どの移行が最も有益であるかを判断するために、任意のまたはすべての代替例と比較することができる。
【００７２】
ＣＥＥＣマーケット・メーカ・メカニズムの概要
ＣＥＥＣの主要目的の１つは、組織または企業におけるコンピューティング・リソースの使用状況を最適化するために、コンピューティング・リソースに対する受給権の価格査定および取引を可能にすることであり、この場合の最適化は、その組織または企業によって所有されるコンピューティング・リソースの使用状況について１つまたは複数の所望の事業目標を達成することとして定義される。この価格査定により、受給権の価格査定および取引のためのＣＥＥＣマーケットの確立が可能になるが、これは自由市場ではない。それとは反対に、ＣＥＥＣマーケットは、その組織または企業によって所有されるマーケットであり、その組織／企業の利益になるように定義され設計されたパラメータおよびルールに従って設計され、機能する。自由市場では、そのトランザクションの当事者が良いトランザクション（たとえば、特定の製品と引き替えに最も高い価格）であると示すものは何でも良いトランザクションである。しかし、ＣＥＥＣマーケットでは、その組織または企業は、トランザクションの当事者、すなわち、トランザクションの買取側および売却側に対して何が最も利益をもたらすかではなく、どのトランザクションがその組織または企業の目標に最も利益をもたらすかに基づいて、何が良いトランザクションであるかを定義する。したがって、市場要因は、取引の勢いによってその価値が強化され実現されることを保証するためにその組織および企業によって利用される。
【００７３】
例示的な諸実施形態により、その組織または企業に関連してトランザクションを価格査定し、市場要因によりその目標を表している組織または企業に関連して有益なトランザクションの数を増加することが可能になる。この結果、ＣＥＥＣのコホート、コンピューティング・リソースのコホート、契約当事者などの間で、ＣＥＥＣならびにそれに関連する受給権および義務の否定、置き換え、および移行が行われ、いずれもその組織または企業の最終的な利益になるように行われ、ときには個々の契約当事者にとって害のあるものになる可能性があるが、このような状況は最小限に保持されるであろう。
【００７４】
たとえば、ある企業において、特定のプラットフォームから移行するか、特定の物理的空間を明け渡すか、または専用リソースのセットを廃止しなければならない緊急課題が発生する可能性がある。これらは、純粋にその利益がこのような否定を要求するという理由で、その企業がＣＥＥＣを否定できる３通りの例である。否定されたＣＥＥＣの保有者は、買取側を見つけるために市場参入を余儀なくされるであろう。このような買取側は、不十分な使用のために自分のＣＥＥＣが否定されており、（その企業にとって）望ましいプラットフォーム上で使用可能な容量が得られることになる。
【００７５】
作業負荷移行は、このＣＥＥＣマーケット・プロセスの結果の１つである。しかし、作業負荷移行はＣＥＥＣの最終目的ではない。その目的は、市場要因を介してコンピューティング・リソースおよびリソース使用に対する受給権を効率よく割り振ることである。これには、所与のコンピューティング環境（すなわち、コンピューティング・リソースおよびその構成）の実行の一部である義務、条件、および考慮事項のすべてを１つの契約、すなわち、ＣＥＥＣにカプセル化しなければならず、そのＣＥＥＣは、使用条件などにより、既知の事業目的に割り振られているコンピューティング・リソース（複数も可）を契約当事者が使用でき、使用しなければならない方法を定義する。「作業負荷」はＣＥＥＣのパラメータの範囲内で実行され、ＣＥＥＣが移行される場合、移行されるＣＥＥＣに指定することができる任意の移行基準に従って、あるＣＥＥＣを他のＣＥＥＣと取引した結果としてのみ、そのように実行することができる。
【００７６】
ＣＥＥＣは資産の適切な使用を保証するために静的状況において価値を有するが、何千もの潜在的な対が存在し、作業負荷の自由な流れを抑制するものが多数存在するような組織または企業において、あるユーザ（すなわち、契約当事者）を１つまたは複数のコンピューティング・リソースから他のコンピューティング・リソースに（たとえば、あるハードウェア環境から他のハードウェア環境に）移動させようと試みるときにＣＥＥＣの必要性は特に切実である。すなわち、作業負荷はより効率的な手段に自然に流れるわけではない。たとえば、上記で前述したように、ユーザは、既存のコンピューティング・リソースがどの程度、十分使用されていないかにかかわらず、既存のコンピューティング・リソースによって保有していた十分な機能を共用コンピューティング・リソースが提供するという確信を持てないために、より効率的なコンピューティング・リソースへの共用アクセスと引き替えに、完全に使用していない自分の既存の潜在的に非効率なコンピューティング・リソース（たとえば、ラップトップ）を放棄することを嫌がる場合が多い。
【００７７】
より単純に言えば、従業員は、１００％の受給権を有するラップトップをたとえ使用していなくても、より新しくより効率的なコンピューティング・リソース（たとえば、サーバ上など）が現在のラップトップと同じように自分にとってアクセス可能なものになるという保証について主観的感覚を持てないので、たとえ使用していなくても現在のラップトップを接収された場合、より新しくより効率的なコンピューティング・リソースへの共用アクセスと引き替えに、そのラップトップを断念することを嫌がる可能性がある。すなわち、人は、「手中の一羽はやぶの中の二羽の価値がある」という古い諺を守る傾向があり、コンピューティング・リソースおよびその効率的な割り振りに関して組織または企業全体の最良の利益より自分自身の目前の必要性について心配する傾向が強く、たとえば、「自分のプロジェクトにＸという量の記憶空間が必要であることが分かっているが、会計部門の人がその人のプロジェクトに何を必要としているかは知らないか関心がない」。
【００７８】
複雑な組織では、現在の非効率なハードウェアを使用する代わりにより効率的なハードウェアを買い取ることを困難にするような、地理的範囲、部門レベルの予算編成、資本対支出の格差に対処しなければならない、計算作業負荷の流れに対する非技術的なバリアも数多く存在する。最適化は一般に集中化および整理統合によって実現されるが、組織の境界がこのような活動に障害をもたらす場合が多い。ＣＥＥＣは、この障害をクリアできるようにするメカニズムである。
【００７９】
例示的な諸実施形態のメカニズムにより、図３のＣＥＥＣマーケット・メーカ・サービス３２２などのＣＥＥＣマーケット・メーカは、契約当事者が基本的な技術要件（ＣＰＵ、ＲＡＭなど）とともに形式的に列挙しなければならない要素（ネットワーク帯域幅、記憶空間、管理サポートなど）のすべてを含むことができる新しいＣＥＥＣと既存のＣＥＥＣを取引できるようにする。決済時（settlement time）に問題が発生する場合でも（組織または企業の遊休在庫品を保持し、ときには明示的に要求されたものよりわずかに多く購入することにより、満足することができる）、トランザクションの両側を完全なものにするために必要なロジックおよび機構を有することなどにより自分の使用要件が満足されるという確信をＣＥＥＣマーケット・メーカが契約当事者に提供できる限り、コンピューティング・リソースの効率的な割り振りを抑制する重要なものは解消される。さらに、ＣＥＥＣは、ＣＥＥＣによりその既存のリソース要件に対するすべての権利を依然として保持しながら、組織内のグループが共用プールにリソースを提供することを可能にする。
【００８０】
この場合も、例示的な諸実施形態のＣＥＥＣマーケット・メーカ・メカニズムが中立の第三者として機能しないことに留意されたい。それとは反対に、このメカニズムは、組織または企業を特定の方向に駆り立てるための推進力として機能し、その特定の方向に偏った市場要因を作成し操作することによってこのように機能する。ＣＥＥＣマーケット・メーカ、たとえば、ＣＥＥＣマーケット・メーカ・サービス３２２は、マーケット（組織または企業）においてすべての使用の効率（作業負荷）を最適化するためにＣＥＥＣマーケット・メーカのハードウェア／ソフトウェア・ロジックに表された特定の意図を有する。組織または企業の運用目標を達成するようにＣＥＥＣマーケット・メーカ・メカニズムがマーケットを駆り立てるための特定の方法は、ＣＥＥＣマーケットにおける買取側、売却側、および買取側と売却側の対の選択、ならびに、ＣＥＥＣマーケットによるＣＥＥＣの作成、否定、および置き換えを制御するためにＣＥＥＣマーケット・メーカ・メカニズムによって処理され、まとめて「プロファイル」と呼ばれる、ＣＥＥＣマーケット・パラメータ、ルールなどのセットに定義することができる。その上、これは、本明細書で「コホート」と呼ばれる、コンピューティング・リソースあるいはＣＥＥＣまたはその両方の定義された集合体に関して実行することができ、このようなコホートおよびそのメンバーシップを定義するための基準はＣＭＤＢに指定されている。
【００８１】
ＣＥＥＣマーケット内で、売却側および買取側は売却側および買取側になることを自分自身で決定しない。それとは反対に、ＣＥＥＣマーケット・メーカ・メカニズムは、組織または企業の目標を表し、コンピューティング・リソースおよびＣＥＥＣのコホートを識別するとともに、どの要素が買取側および売却側になるべきかを決定するために、使用状況および構成データにそのプロファイルを適用する。適用されるプロファイルは、複数のコンピューティング・リソースを組み合わせてコホートにする方法およびそのための基礎（「コホート」という用語は同様の要素の「集合（collection）」を意味する）、複数のＣＥＥＣを組み合わせてコホートにする方法およびそのための基礎、使用状況情報がコホート・メンバーシップを変更する必要性を示す方法および時期、いつコンピューティング・リソースまたはコホートをＣＥＥＣの買取側または売却側と見なすべきかを特定の使用状況情報が示す方法および時期を含むＣＥＥＣマーケットの様々な面を規定する、１つまたは複数のパラメータあるいはルールまたはその両方などの集合、ならびに例示的な諸実施形態のＣＥＥＣメカニズムが実行または動作するための方法を規定するためのその他のパラメータおよびルールの集合である。ＣＥＥＣマーケット動作を容易にするための特定の基本要素はトランザクションであり、これは、たとえば、図３のトランザクション・ビルダ３１２などにより、自動的に、手動で、または自動プロセスおよび手動プロセスの組み合わせを使用して、作成することができる。
【００８２】
ＣＥＥＣマーケット・メーカはトランザクションを組み立てることができるが、買取側および売却側システムの個々の所有者はシステム使用状況マネージャ３１６を介して先回りしてトランザクションに参加することもできる。すなわち、トランザクション・ビルダ３１２により計画者、設計者、および管理者が売却側ＣＥＥＣのセットを買取側に移行することについて計画あるいは記録またはその両方を行える場合、システム使用状況マネージャ３１６は、買取側または売却側として指定されているその個別システムに関連して個々のユーザがマーケットに参加できるようにする。さらに、トランザクション・ビルダ３１２が移行のセットを提案する場合、場合によっては、このようなシステムのユーザは、システム使用状況マネージャ３１６を介してこのようなトランザクションに参加するための勧誘を肯定的に受け入れなければならないであろう。さらに、システム使用状況マネージャ３１６は、それにより特定のシステムのユーザが自分のＣＥＥＣの義務に気付かされ、異なるビジネス使用を請求することによりＣＥＥＣの否定を懇願することができ、将来のトランザクションに参加する意志を知らせることができるメカニズムである。
【００８３】
例示的な諸実施形態のＣＥＥＣマーケット・メーカ・メカニズムはＣＥＥＣマーケットで使用しているすべてのＣＥＥＣを管理するので、このようなＣＥＥＣマーケット・メーカ・メカニズムは、ある当事者が自分の義務を果たすことができなかった場合にＣＥＥＣを無効にする権限を有する。これは、自分に割り振られたコンピューティング・リソースを使用するか、または正当な理由なしに古いハードウェアを使用しているときに自分の契約の無効化を行うことによりこのようなコンピューティング・リソースを放棄し、すなわち、売却側になるか、またはＣＥＥＣによって定義されている予想と一致しない方法でハードウェアを使用するための動機付けを契約当事者に提供するものである。したがって、例示的な諸実施形態のＣＥＥＣマーケット・メカニズム内で、売却側は、自分に割り振られたコンピューティング・リソースを所有する組織または企業により、そのコンピューティング・リソースを使用するための有効なＣＥＥＣを持たないために売却側になる。また、契約の無効化は買取側でも作用し、完全に使用されていない良好な新しいコンピューティング・リソースはその契約が無効になっており、ＣＥＥＣおよびこれらのＣＥＥＣに関連する結果的な作業負荷の移転により、売却側から追加の作業負荷を買い取ることを強要する。
【００８４】
ＣＥＥＣに基づく作業負荷管理
例示的な諸実施形態のメカニズムは、使用状況が最小要件を満たしていない場合に受給権が無効化されるというリスクとともに、契約当事者によるコンピューティング・リソースの使用状況の関連予想により、ＣＥＥＣに指定された受給権とコンピューティング・リソースとの関連付けを容易にするようにＣＥＥＣを操作する。例示的な諸実施形態のメカニズムを使用するＣＥＥＣの管理の結果として、作業負荷管理が可能になる。これらのＣＥＥＣおよびそれとコンピューティング・リソースとの関連付けに従って、作業負荷はコンピューティング・リソースに経路指定され、コンピューティング・リソースの使用状況はモニターされる。したがって、作業負荷が特定の契約当事者によって提示されると、その契約当事者に関連するＣＥＥＣは、作業負荷を実行するかまたはその他の方法で遂行するためにどのコンピューティング・リソースが使用されるかを決定するための基礎として使用することができる。
【００８５】
図３の作業負荷管理メカニズム３８０は、作業負荷を提示する特定の契約当事者に関連するＣＥＥＣおよび提示される作業負荷のタイプに従って、作業負荷を制御し、コンピューティング・リソースに経路指定することができる。例示的な一実施形態では、契約当事者のコンピューティング・リソースから作業負荷を受け取ると、その契約当事者に関連する１つまたは複数のＣＥＥＣデータ構造をＣＥＥＣデータベースから取り出すことができ、提示される作業負荷のタイプ、たとえば、記憶作業負荷、処理作業負荷などを決定することができる。取り出された１つまたは複数のＣＥＥＣデータ構造に関連する事業目的のタイプを決定し、作業負荷のタイプと突き合わせることができる。その結果、作業負荷と同じ事業目的に向けられたＣＥＥＣデータ構造、したがって、そのタイプの作業負荷を処理することができるタイプのコンピューティング・リソースを管理するＣＥＥＣデータ構造が識別される。次に、そのＣＥＥＣデータ構造を使用して、そのＣＥＥＣデータ構造によって管理される対応するコンピューティング・リソースを識別することができ、次に、作業負荷管理メカニズム３８０は、ＣＥＥＣデータ構造に指定されたコンピューティング・リソースに作業負荷を経路指定することができる。たとえば、ストレージ・システムにデータを保管するために作業負荷が提示される場合、ストレージ・システムに関係があり、本明細書に記載された方法で（たとえば、本明細書に記載されたコホート関連付けを使用して）ストレージ・システム・コンピューティング・リソースに関連付けられた作業負荷を提示した契約当事者に関連するＣＥＥＣを使用して、作業負荷が向けられる場所、すなわち、作業負荷の送信先であるコンピューティング・リソースを管理することができる。
【００８６】
したがって、例示的な諸実施形態は作業負荷管理を直接実行するわけではないが、作業負荷管理は、例示的な諸実施形態のＣＥＥＣベースのメカニズムにより得られる有益な結果である。たとえば、新しい「ワークステーション」に関する要求は、ＣＥＥＣが指定のパターンの使用強度で、何らかの技術基準、すなわち、究極の新しい売却ＣＥＥＣにより、指定の作業負荷を実行するための要求として公式化されるであろう。これは、意図されたビジネス使用を基礎としてコホート化され、使用可能な適合容量を備えた買取側と突き合わされるであろう。
【００８７】
コホート
前述の通り、例示的な諸実施形態のマーケット・メーカ・メカニズムが動作する方法の１つは、図３のコホートおよびプロファイル・マネージャ３１４あるいはコホート管理サービス３２４またはその両方などによりロジックを提供する際に、ＣＥＥＣのコンピューティング・リソース使用状況データ、条件、および条件情報、ならびにコンピューティング・リソースおよびＣＥＥＣの構成データにプロファイルを適用することにより、コンピューティング・リソースおよびＣＥＥＣのコホートを生成し管理することである。この結果、コホートは、例示的な諸実施形態のマーケット・メーカ・メカニズム内で買取側あるいは売却側またはその両方として機能することができる。
【００８８】
コホートは、何らかの定義可能な点で似ている複数のコンピューティング・リソースあるいは複数のＣＥＥＣまたはその両方の集合を表す。たとえば、同じかまたは同様の構成、同じかまたは同様のタイプ、同じかまたは同様の組織的割り振り（たとえば、ある組織の特定のサイトまたは位置に関連する）、物理的位置、組織または企業のデータ・ネットワーク内の論理的位置などを有する複数のコンピューティング・リソースを組み合わせて同じコホートにすることができる。同様に、同じかまたは同様の条件あるいは条件のサブセット（複数も可）を有する複数のＣＥＥＣを組み合わせて複数ＣＥＥＣの同じコホートにすることができ、たとえば、記憶容量を管理する複数のＣＥＥＣを１つのコホートに集めることができ、その組織または企業の同じかまたは同様の部局または部門内の契約当事者に関連する複数のＣＥＥＣを１つのコホートに集めることができ、同じかまたは同様の事業目的を有する複数のＣＥＥＣを１つのコホートに集めることなどができる。このような同様のコンピューティング・リソースおよびＣＥＥＣを組み合わせてコンピューティング・リソースおよびＣＥＥＣの集合またはコホートにすることができるように、クラスタ分析メカニズムを使用して、これらのコンピューティング・リソースおよびＣＥＥＣを識別することができる。
【００８９】
たとえば、コホート管理サービス３２４は、構成管理データベース３３２に保管されたコンピューティング・リソースに関する構成情報と、ＣＥＥＣデータベース３３４の項目で識別されたＣＥＥＣ条件とを分析し、この情報についてクラスタ分析を実行して、コンピューティング・リソースの１つまたは複数のコホートおよびＣＥＥＣの１つまたは複数のコホートを生成することができ、この場合、それぞれのコホートはそのコホートの他のメンバーと同様の特性を有するメンバーを有する。「類似性」は、多種多様な点、たとえば、同じかまたは同様の（すなわち、定義された許容範囲内の）数のプロセッサ、同じかまたは同様の量のメモリ、同じかまたは同様のソフトウェア構成、同じかまたは同様のリソース使用要件、同じかまたは同様の事業目的、同じかまたは同様の組織的位置などについて測定することができる。コホートを確立するために使用される特定のルールおよびパラメータは、そのコホートを定義するプロファイルで識別され、以下に説明するように、ＣＭＤＢに記録することができる。
【００９０】
コンピューティング・リソースのコホートが作成され、ＣＥＥＣのコホートが作成されると、コホート管理サービス３２４は、ＣＥＥＣのコホート（または単純に「ＣＥＥＣコホート」）内のＣＥＥＣの同じかまたは同様の条件を満足するために必要であると判断されたコンピューティング・リソースを提供するコンピューティング・リソースの１つまたは複数のコホート（または単純に「コンピューティング・リソース・コホート」）に基づいて、ＣＥＥＣコホートをコンピューティング・リソース・コホートと突き合わせるためのロジックを有することができる。このようにして、ユーザに関連する受給権契約は、自動化された方法でこのような契約を満足するための１つまたは複数のコンピューティング・リソースに関連付けることができる。当然のことながら、望ましいときにその個人がコホートおよびその関連付けについて検討、取消、修正、指定変更、またはその他の変更を行えるように、コホート情報およびコホート間の関連付けは、コホートおよびプロファイル・マネージャ３１４を介してシステム管理者またはその他の許可ユーザに出力することができる。１つのＣＥＥＣコホートと１つまたは複数のコンピューティング・リソース・コホートとの関連付けは本質的に、ＣＥＥＣコホート内のＣＥＥＣに対する契約当事者により有用なコンピューティング・リソース・コホート（複数も可）のコンピューティング・リソースまたはそのコンピューティング・リソースの少なくとも一部分を予約するものである。したがって、ＣＥＥＣコホートとコンピューティング・リソース・コホートとの関連付けが行われると、ＣＥＥＣ執行ロジックは効力を発生する。
【００９１】
このようにして互いに突き合わされ関連付けられたコホートは、コホート間の関連付けを考慮してその使用状況がモニターされ分析されている可能性がある。すなわち、コンピューティング・リソース・コホートに関連するＣＥＥＣコホート（複数も可）のＣＥＥＣに指定された条件に基づいてコンピューティング・リソース・コホートのメンバーであるコンピューティング・リソースについて、コンピューティング・リソース使用状況情報を収集し分析しモニターすることができる。本質的に、この情報の収集、分析、およびモニターは、ＣＥＥＣの条件がコンピューティング・リソース・プロバイダおよび契約当事者、たとえば、エンド・ユーザの両方によって遵守されていることを保証するために実行される。したがって、使用状況情報の収集、その分析およびモニターは、ＣＥＥＣコホートのＣＥＥＣに指定された特定のコンピューティング・リソース使用条件に関して実行されるが、その収集は、ＣＥＥＣが関連付けられているコンピューティング・リソース・コホート（複数も可）に指定されたコンピューティング・リソースから実行される。したがって、たとえば、ユーザが、会計動作に向けられたソフトウェア・パッケージを実行するために、その時間の５０％の間、自分に割り振られたプロセッサを使用しなければならないことをあるＣＥＥＣが指定している場合、このＣＥＥＣが関連付けられているコンピューティング・リソース・コホートのコンピューティング・リソースについて収集されたプロセッサ使用状況メトリクスを分析して、このユーザが指定の期間中にその時間の少なくとも５０％の間、会計ソフトウェアを実行していたかどうかを判断することになる。
【００９２】
コンピューティング・リソースおよびＣＥＥＣを集めてコホートにすることは、全体としてコンピューティング・リソース構成またはＣＥＥＣ条件に基づく集合に限定する必要はないことを認識されたい。それとは反対に、たとえば、１つのＣＥＥＣの準部分（ｓｕｂ−ｐａｒｔ）は、その準部分に関連するＣＥＥＣの条件に基づいて異なるＣＥＥＣコホートに個別に割り当てることができる。たとえば、ＣＥＥＣは、プロセッサ・リソース、ストレージ・システム・リソース、Ｗｅｂアプリケーション・リソースなどの割り振りおよび契約当事者による使用に関連する条件を指定することができる。これらはそれぞれ、組織または企業の異なるコンピューティング・リソースによって個別に満足させることができる可能性があり、したがって、１つのＣＥＥＣを複数のＣＥＥＣコホートに関連付けることができるように個別のＣＥＥＣコホートに分離することができ、個別のＣＥＥＣコホートとのこのような関連付けのそれぞれは例示的な諸実施形態のメカニズムによって個別に管理することができ、個別にＣＥＥＣマーケット・メーカ動作の対象にすることができる。
【００９３】
同様に、コホート・メンバーシップは、ＣＥＥＣ内の同様の条件またはコンピューティング・リソースの同様の構成に基づくだけでなく、さらに同様の使用状況メトリクスに基づくこともできる。すなわち、２つのコンピューティング・リソースが同様の構成を有する可能性があり、したがって、通常、同じコホートの一部になると思われる場合でも、これらのコンピューティング・リソースが著しく異なる方法であるいは異なるレベルまたはパターンの使用強度で使用されていることをその使用状況メトリクスが示す場合、これらの２つのコンピューティング・リソースは異なるコホートに個別に分類可能である可能性がある。あるＣＥＥＣを特定のコホートに分類しなければならないかどうかを判断するための基礎としてそのＣＥＥＣに関連する使用状況メトリクスを使用できる場合、ＣＥＥＣにおいても同じことが当てはまる。使用状況メトリクスは、コンピューティング・リソース上でデーモン・プロセスとして実行されるエージェント・アプリケーションを使用すること、コンピューティング・リソースを探査することなど、任意の既知の方法で入手することができる。使用状況メトリクスは、図３の情報技術モニタリング・ウェアハウス３５２〜３５６などのデータ収集メカニズムによって収集し、たとえば、使用状況スコアリング・サービス３２６を介して使用状況スコアを生成するなど、分析して使用状況情報を生成することができる。この使用状況情報は、データベース・システム３３０を介して様々なコンピューティング・リソースおよびＣＥＥＣに関連付けることができ、コホート管理サービス３２４などのコホートおよびプロファイル管理メカニズムによって使用して、コホート・メンバーシップを動的に評価し、コンピューティング・リソースおよびＣＥＥＣの使用状況の変化に従ってコホート・メンバーシップを再調整することができる。同様に、コンピューティング・リソースの構成の変化は、データベース・システム３３０により識別し、組織または企業のコンピューティング・リソース使用状況を最適化するために必要と判断されたときにコホート・メンバーシップを動的に調整するための基礎として使用することができる。
【００９４】
使用状況スコアリング・サービス３２６は、以下により詳細に説明するように、構成管理データベース（ＣＭＤＢ）３３２あるいはＣＥＥＣデータベース３３４またはその両方に保管して、関心のあるメトリクスについてコホートのそれぞれのメンバーに関するスコアならびに特定のコホートを定義するプロファイルに指定されたそのコホートについて関心のある統計表現を生成できるなど、収集された使用状況メトリクスについて操作することができる。これらのスコアは、使用状況サービスのロジックのルールおよびパラメータに従って生成するか、同じく以下に説明するように、静的であるかまたは動的に決定された重みにすることができるコホートのプロファイルに定義された重みにするか、またはその両方にすることができる。結果として得られるスコアは、コホートの他のメンバーに対するコホートのあるメンバーの使用状況を示す相対尺度を提供する。この使用状況は、ＣＥＥＣの条件に従ってコンピューティング・リソースが使用されているかどうかあるいはＣＥＥＣの条件が分析されたコンピューティング・リソース使用によって満足されているかどうかを示す全体的な表現を生成するために、コンピューティング・リソース・コホートのメンバーが関連付けられるＣＥＥＣの条件に指定された要求使用状況と比較することができる。結果として得られるスコアは、コホートのメンバーシップの調整、ＣＥＥＣの否定、置き換え、あるいは移行、またはこれらの組み合わせなどのための基礎として使用することができる。
【００９５】
これらのスコアの表現は、たとえば、コホートおよびプロファイル・マネージャ３１４により生成し、許可ユーザに提示することができる。たとえば、あるＣＥＥＣコホートのＣＥＥＣのスコアのグラフ表現は、そのＣＥＥＣコホートが関連付けられている１つまたは複数のコンピューティング・リソース・コホートのコンピューティング・リソースのスコアリングとともに、多軸グラフなどで提示することができ、その結果、どのＣＥＥＣがコンピューティング・リソースの使用によって満足されているか、ならびにどのコンピューティング・リソースがＣＥＥＣコホートのＣＥＥＣ条件を満足するために使用されているかを判断することができる。たとえば、赤／黄／緑という色分けの使用を含む、この情報の可視化を支援するために、様々なグラフ表現を使用し、ＣＥＥＣコホート内のＣＥＥＣの条件に関する遵守情報および報告をさらに識別し提供することができる。このようなグラフ表現は、たとえば、ＣＥＥＣごとを基礎として、ＣＥＥＣコホートを基礎として、またはＣＥＥＣコホートの集合を基礎として、提供することができる。
【００９６】
図５は、例示的な一実施形態によりコホートの関連付けを生成するための動作例を概説する流れ図である。図５に概説された動作は、たとえば、コホート管理サービス３２４によって単独で、または、たとえば、図３のコホートおよびプロファイル・マネージャ３１４と組み合わせてのいずれかで、実行することができる。図５は概要であり、例示的な諸実施形態の特定の実現例に特有の多くの詳細は図５に明示的に示されていない可能性があるが、この説明を考慮すれば当事者にとって容易に自明なものになることを認識されたい。
【００９７】
図５に示されているように、この動作は、コンピューティング・リソース・コホートを指定するための少なくとも１つと、ＣＥＥＣコホートを指定するための１つという、１つまたは複数のコホート・プロファイルの定義から始まる（ステップ５１０）。定義されたコホート・プロファイルを、データベース・システム内のコンピューティング・リソース構成情報およびＣＥＥＣ情報に対して適用し、１つまたは複数のメンバーを有する少なくとも１つのコンピューティング・リソース・コホートと、少なくとも１つのメンバーを有する少なくとも１つのＣＥＥＣコホートを生成する（ステップ５２０）。ＣＥＥＣおよびコンピューティング・リソースのコホート・メンバーシップに注目し、コンピューティング・リソースおよびＣＥＥＣに関する項目に関連してデータベース・システムに保管する（５３０）。前述の通り、１つのＣＥＥＣの条件が細分される場合など、単一のＣＥＥＣが複数のＣＥＥＣコホートの一部になることは可能である。同様に、コンピューティング・リソースは、その構成情報を個別のタイプの構成項目に細分することにより、複数のコンピューティング・リソース・コホートの一部にすることができる。したがって、１つのＣＥＥＣコホートが複数のコンピューティング・リソース・コホートに関連付けられる場合もあれば、その逆の場合もある。
【００９８】
その後、ＣＥＥＣコホート（複数も可）の共通または同様の条件を、コンピューティング・リソース・コホートに関する共通または同様の構成情報と照らし合わせて比較し、１つまたは複数のコンピューティング・リソース・コホートを１つまたは複数のＣＥＥＣコホートと突き合わせる（ステップ５４０）。コホート間の関連付けを作成し、これらの関連付けをその後の使用のために保管することができる（ステップ５５０）。これらの関連付けに基づいて、コンピューティング・リソースまたはコンピューティング・リソースの一部分を予約するかまたは関連するＣＥＥＣコホート内のＣＥＥＣに割り振る（ステップ５６０）。
【００９９】
コンピューティング・リソース使用状況メトリクスを、様々なコンピューティング・リソースから収集し、生形式で、分析済み使用状況情報として、またはその両方で、データベース・システムに保管する（ステップ５７０）。コホートの関連付けに基づいて、データベース・システム内のコンピューティング・リソース使用状況情報を分析し、ＣＥＥＣが関連付けられているコンピューティング・リソース・コホート（複数も可）内のコンピューティング・リソースに関するその使用状況に基づいて、ＣＥＥＣコホート内のＣＥＥＣの条件が契約当事者によって遵守されているかどうかを判断する（ステップ５８０）。ＣＥＥＣ条件に対する遵守の判断に基づいて、遵守報告のグラフ表現を生成することができ（ステップ５９０）、コホート・メンバーシップを更新することができる（ステップ５９５）。その後、この動作は終了する。
【０１００】
したがって、例示的な諸実施形態により、少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースとを含むデータ処理システムにおいて、データ処理システムのコンピューティング・リソースを予約するためのメカニズムが提供される。これらのメカニズムは、１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を確立することができ、それぞれのＣＥＥＣデータ構造は契約当事者とデータ処理システムのコンピューティング・リソースのプロバイダとの間のビジネス・レベル協定の条件を定義し、ＣＥＥＣの条件は、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定する。これらのメカニズムはさらに、１つまたは複数のコンピューティング・リソースのセットを１つまたは複数のＣＥＥＣのセットに関連付けることができる。さらに、このメカニズムは、１つまたは複数のＣＥＥＣの関連セットに従って１つまたは複数のコンピューティング・リソースのセットを管理することができる。おおよそ指定の期間の間、おおよそ指定のレベルおよびパターンの強度で、指定の目的のために、選択されたコンピューティング・リソース・コホート内のコンピューティング・リソースを契約当事者が使用し損なったことに応答して、少なくとも１つのコンピューティング・デバイスのロジックがＣＥＥＣを無効にする。このような無効化の結果、そのＣＥＥＣが他のＣＥＥＣと置き換えられるか、あるいは無効なＣＥＥＣがコンピューティング・リソースのあるセットから他のセットに移行するか、またはその両方が行われる可能性がある。
【０１０１】
リソース、作業負荷、およびＣＥＥＣの間の関係は、前述のように非常に複雑になる場合もあれば、非常に単純である場合もある。単純なＣＥＥＣを取引でより複雑な環境に導入できることは注目すべき重要なことである。たとえば、ＣＥＥＣは、「基本的なオフィス生産性」（電子メール、ワードプロセシングなど）に使用すべきスタンドアロン・デスクトップ・ワークステーションを要求する場合がある。このＣＥＥＣは取引で非常に複雑で集中化した仮想化クラスタに導入することができ、その場合、同じビジネス活動が非常に複雑なプラットフォーム上で実行されることになるが、ユーザにとってはあまり異なるものには思われず、スタンドアロン・デスクトップ・ワークステーション上と同じことを実行するために同じように使用されることになる。これは、自分が完全に制御できる環境から、自分の制御が限られているかまたは自分がまったく制御できない環境、自分が理解できない環境、自分が知らない人によって運営される可能性のある環境、異なる地理にある環境などに移動するこのプロセスにより自分の要件が保護されるという確信をユーザに提供することがＣＥＥＣに要求される理由を強調するものである。
【０１０２】
１つまたは複数のコンピューティング・リソースのセットと、１つまたは複数のＣＥＥＣとの関連付けは、複数のコンピューティング・リソースのそれぞれに関する構成情報に基づいて、その複数のコンピューティング・リソースからなる１つまたは複数のコンピューティング・リソース・コホートの第１のセットを決定することを含むことができる。１つのコンピューティング・リソース・コホート内の複数のコンピューティング・リソースは、互いに同様のタイプのものにすることができ、互いに同様の構成を有することができる。この関連付けは、データ処理システムによって維持される１つまたは複数のＣＥＥＣの属性に基づいて、複数のＣＥＥＣからなる１つまたは複数のＣＥＥＣコホートの第２のセットを決定することと、第２のセット内の選択されたＣＥＥＣコホート内のＣＥＥＣの条件ならびに第１のセット内の選択されたコンピューティング・リソース・コホートの特性に基づいて、選択されたＣＥＥＣコホートと選択されたコンピューティング・リソース・コホートを突き合わせることをさらに含むことができる。
【０１０３】
１つまたは複数のＣＥＥＣの関連セットに従って１つまたは複数のコンピューティング・リソースのセットを管理することは、選択されたＣＥＥＣコホート内のＣＥＥＣの条件に従って、選択されたコンピューティング・リソース・コホート内のコンピューティング・リソース上で、そのＣＥＥＣを執行することを含むことができる。ＣＥＥＣの執行は、リソース使用状況メトリック情報を入手することと、コンピューティング・リソース使用状況メトリック情報に基づいてＣＥＥＣ条件が遵守されているかどうかを判断することと、ＣＥＥＣ内の条件と比較したときに実際のコンピューティング・リソース使用状況に基づいて、ＣＥＥＣを否定するか、ＣＥＥＣを置き換えるか、あるＣＥＥＣコホートから他のＣＥＥＣコホートにまたはあるコンピューティング・リソース・コホートから他のコンピューティング・リソース・コホートにＣＥＥＣを移行するか、またはこれらの組み合わせを行うかどうかを判断することを含むことができる。
【０１０４】
ＣＥＥＣおよびコホートと既存の組織的システム情報との関連付け
ＣＥＥＣ、コホートなどは、従業員情報、部門、部局、および位置情報、事業単位などの既存の組織情報に関連付けることができる。たとえば、データベース・システム３３０は、データベース・システム３３０とこれらの既存の組織的システムとのインターフェースを取り、それにより、これらの既存の組織的システムから追加の情報を入手するか、あるいはＣＥＥＣベースのリソース管理システム３００のＣＥＥＣ、コホート、およびその他のデータ構造をこれらの既存の組織的システムとリンクするか、またはその両方を行うための１つまたは複数の組織的システム・インターフェース３３６を含むことができる。例示的な一実施形態では、契約当事者は組織または企業の従業員または部門にすることができ、これらの従業員または部門に関する識別情報は、従業員ディレクトリ、組織的構成システム、人的資源システムなどを含むことができる組織的システム３４０から入手することができる。
【０１０５】
既存の組織的システム３４０から入手した情報は、ＣＥＥＣデータベース３３４あるいはＣＭＤＢ３３２またはその両方の項目のフィールドに入力し、それにより、これらの他の組織的システム３４０からの情報をＣＥＥＣおよびコンピューティング・リソースならびにそれらのコホートと関連付けるためにデータベース・システム３３０によって使用することができる。たとえば、特定の従業員にＣＥＥＣを割り振ることができ、その従業員の情報を既存の組織的システム３４０、たとえば、人的資源システムから自動的に取り出して、ＣＥＥＣに関するＣＥＥＣデータベース３３４の項目、たとえば、従業員識別番号、名前、部門、事業単位などのフィールドに入力するために使用することができる。同様に、データベース・システムからの情報を契約当事者に関する項目、たとえば、従業員に関連するＣＥＥＣのＩＤ、従業員に関連付けられたＣＥＥＣに関連するコンピューティング・リソース・コホートのＩＤなどとリンクするように、既存の組織的システム３４０を更新することができる。
【０１０６】
その上、既存の組織的システム３４０から入手した情報は、コホートのメンバーの識別を支援するため、すなわち、コホートの生成を支援するために、コホート管理サービス３２４ならびにコホートおよびプロファイル・マネージャ３１４によって使用することができる。たとえば、組織または企業内の特定の事業単位、部門、またはその他の組織単位に関するプロファイルを生成することができ、既存の組織的システム３４０から入手した情報を使用して、これらのプロファイルを生成し、対応するコホートに入力することができる。
【０１０７】
コホートの作成および管理を支援するためにこれらの組織的システム３４０を使用できる方法の他の例として、様々なコホートについてコンピューティング・リソース使用状況情報を入手し分析して、コンピューティング・リソースに関連するＣＥＥＣに基づいて使用状況の傾向およびパターンを識別することができ、組織的システム３４０からの組織情報を使用して、その結果報告が生成される同様の使用状況傾向およびパターンを有する他のコホートに関連付けることができる他の契約当事者、事業単位などを識別することができる。次に、この情報を使用して、このような組織的実体、たとえば、従業員、事業単位、部門などの間のコホート・メンバーシップを決定することができる。
【０１０８】
プロファイル
コホートを定義するためのプロファイルは、たとえば、図３のコホートおよびプロファイル・マネージャ３１４によって単独でまたはコホート管理サービス３２４のロジックと協力して提供される１つまたは複数のユーザ・インターフェースを介して、システム管理者またはその他の許可された個人によって定義することができる。プロファイルは、コンピューティング・リソースあるいはＣＥＥＣまたはその両方の様々なコホートを定義するために生成することができる。プロファイルは、コホートを定義するために使用されるパラメータならびにどのコンピューティング・リソース／ＣＥＥＣが定義されたコホートのメンバーになることができるかを指定する。プロファイルは、コホート内のメンバーシップを決定するためにどの使用状況メトリクスが評価されるかならびにこれらのメトリクスに関連するどのレベルあるいはパターンまたはその両方の使用状況がコホート内のメンバーシップ、コホートからの除去などを示すかを指定することができる。以下に述べるように、コホート内のメンバーシップを調整するためのこれらの使用状況のレベルあるいはパターンまたはその両方は、生成された使用状況情報に基づいて、たとえば、コホートの模範および逆模範メンバーの選択により、動的に決定することができる。
【０１０９】
プロファイルは、コンピューティング・リソース構成情報（たとえば、ＣＭＤＢ３３２から入手できるもの）およびＣＥＥＣデータ（たとえば、ＣＥＥＣデータベース３３４から入手できるもの）に適用することができ、１つまたは複数のメトリクスに対応する使用状況情報が生のメトリック・データであるかまたは生のメトリック・データを処理した結果、たとえば、使用状況スコアなどであるかにかかわらず、どちらのデータベースもこの使用状況情報を保管することができる。プロファイルは、どのコンピューティング・リソースおよびどのＣＥＥＣが対応するコホートのメンバーになるはずであるかを識別するためにコンピューティング・リソース構成情報およびＣＥＥＣデータに適用することができる。データベース・システム３３０は、特定のコンピューティング・リソースおよびＣＥＥＣが関連付けられるコホートのＩＤを含むように、それに応じて更新することができる。
【０１１０】
プロファイルは、特定の実現例次第で多種多様な方法で定義することができる。好ましくは、図６に示されているように、プロファイル６００は、プロファイルの固有のＩＤ６１０、プロファイルに対応するコホート内のメンバーシップを示すコンピューティング・リソースの特性またはＣＥＥＣの条件６２０、対応するコホート内のメンバーシップを評価するために使用する予定の特定の使用状況メトリクスの識別情報６３０、これらのメトリクスを評価するための基準６４０、対応するコホート内のメンバーシップを調整する時期を決定するための基準６５０、これらの調整基準に関連する対応するアクション６５５、そのプロファイルのその他のパラメータおよびルール６６０を含む。コホート内のメンバーシップを決定するためのメトリクスを評価するための基準６４０は、たとえば、評価を行うための時間フレーム、使用状況を測定するための基礎（たとえば、最大、最小、平均など）、このような評価のためのバイアス（たとえば、最良、最悪、最新、移動平均など）など、あるいはこれらの組み合わせを含むことができる。
【０１１１】
調整基準６５０および対応するアクション６５５は、たとえば、その結果、特定のアクションを行うことが必要になるような、メトリック使用状況情報の範囲を指定することができる。これらのアクション６５５は、ＣＥＥＣマーケット・メーカ・アクション、たとえば、買取、売却、保留、または廃棄（retire）、あるいはその他の方法でＣＥＥＣ／ＣＥＥＣコホートを否定することにすることができ、この場合、買取はコンピューティング・リソースまたはコホートにより多くのＣＥＥＣを追加することを指し、売却はコンピューティング・リソースまたはコホートからＣＥＥＣを移行することを指し、保留はいかなるアクションも行わないことを意味し、廃棄はそれが再使用されないようにコンピューティング・リソースまたはコホートを永続的に廃棄することを意味する。したがって、ＣＥＥＣマーケット・メーカ・サービス３２２は、ＣＥＥＣマーケット・メーカ・サービス３２２によって管理されるＣＥＥＣマーケット内で買取側および売却側の選択を支援するためのメカニズムとしてプロファイルを使用することができる。
【０１１２】
コホート管理サービス３２４は、ＣＭＤＢ３３２内のコンピューティング・リソース構成情報およびＣＥＥＣデータベース３３４に保管されたＣＥＥＣに指定されたＣＥＥＣ条件に適用できるように、システム管理者またはその他の許可ユーザによって生成されたプロファイル６００を保管することができる。始めに、システムが初期設定するとき、新しいコンピューティング・リソースがシステムに追加されるとき、または新しいＣＥＥＣが作成されるときに、様々なプロファイル６００によって定義されたコホート内のメンバーシップを決定するための基礎として使用するための使用状況情報はデータベース・システム３３０内にまったく存在しないであろう。したがって、コホート内のメンバーシップは、始めに、データベース・システム３３０に指定されたコンピューティング・リソース構成情報およびＣＥＥＣ条件に基づいて決定することができる。その後、様々なＣＥＥＣに基づいてコンピューティング・リソースを使用するにつれて、使用状況情報を収集／生成し、これらのプロファイル６００に指定された調整基準に従って、このプロファイルによって定義された様々なコホート内のコンピューティング・リソースおよびＣＥＥＣのメンバーシップを動的に調整するための基礎として使用することができる。したがって、コホート管理サービス３２４は、連続的にまたは定期的に、プロファイルをモニターし、データベース・システム３３０に保管された情報にプロファイルを適用して、コホート・メンバーシップに対する調整を決定することができる。
【０１１３】
コホートおよびプロファイル・マネージャ３１４を介して作成および管理され、コホート管理サービス３２４に関連して保管されるプロファイル６００は、コホートおよびプロファイル・マネージャ３１４によって提供された１つまたは複数のユーザ・インターフェースを介して許可ユーザによって更新可能である。その上、これらのプロファイル６００は、以下に説明するように、コホートのメンバーに関する使用状況メトリクスの分析に基づいて、たとえば、使用状況メトリクスの分布、代表的なコホート・メンバー、アウトライア・メンバーなどの識別情報に基づいてコホートの動作を評価するために使用するための異なる使用状況メトリクスまたは異なる重み付けを選択して、自動的に更新することができる。これらのプロファイル６００が更新されたことに応答して、更新されたプロファイル６００を考慮してそのコホートに含めるための候補になり得るその他のコンピューティング・リソースあるいはＣＥＥＣまたはその両方に関するデータベース・システム３３０内の構成情報およびＣＥＥＣ情報とともに、更新されたプロファイル６００をコホート管理サービス３２４によってコホートの既存のメンバーに適用し、メンバーシップを維持すべきかまたは変更すべきかを判断することができる。
【０１１４】
コホートを管理するための使用状況情報のスコアリングのためのプロファイルの使用
前述の通り、プロファイル６００は、それによりコホートのメンバーの使用状況を評価するためのコンピューティング・リソース使用状況情報を指定することができる。コホートの各メンバーは、そのコホートを定義する同じプロファイル６００に従って評価される。このような評価は、たとえば、コホート管理サービス３２４によって単独でまたはコホートおよびプロファイル・マネージャ３１４と組み合わせてのいずれかで、自動的にまたは許可ユーザによる手動介入により、実行することができる。この評価は、使用状況スコアリング・サービス３２６によって生成された使用状況スコアを含むことができるデータベース・システム３３０から入手できるコンピューティング・リソース使用状況情報に適用されるときに、プロファイル６００に指定されたルール、パラメータなどに基づいて実行することができる。
【０１１５】
たとえば、プロファイル６００は、特定のコホートについて、そのコホートのメンバーを評価するために使用すべき最も重要な使用状況情報が記憶容量メトリクス、プロセッサ・サイクル統計、所定の期間について実行されたプロセスの平均数などにすることができると指定することができる。このコンピューティング・リソース使用状況情報は、たとえば、データベース・システム３３０あるいは使用状況スコアリング・サービス３２６またはその両方から入手することができる。使用状況情報は、スコアリング・ルールおよび重み付けに従って、あるコホートのメンバーあるいはそのコホート全体またはその両方に「スコアを付ける」ために使用することができる。このようなスコアリングは、たとえば、図３の使用状況スコアリング・サービス３２６によって実行することができる。結果として得られるスコアは、使用状況スコアリングが望ましいＣＥＥＣコホートの関連付けられたＣＥＥＣに基づくコンピューティング・リソースの相対的な使用状況を示すリソース使用状況スコアの定義済みカテゴリにカテゴリ化することができ、たとえば、リソース使用状況が、コンピューティング・リソースまたはコホートがＣＥＥＣ条件に従って使用されていることを示す範囲内にあるか、ＣＥＥＣ条件の受け入れられる許容範囲内にあるか、またはＣＥＥＣ条件の受け入れられる許容範囲内にないかを示す「緑」、「黄」、および「赤」のカテゴリにスコアをカテゴリ化することができる。プロファイル６００が更新されると、コホートのメンバーあるいはコホートのメンバーになり得るその他のコンピューティング・リソース／ＣＥＥＣまたはその両方のスコアリングは、更新されたプロファイル内の変更されたリソース使用状況情報パラメータ、重み付けなどに基づいて、同様に更新することができる。
【０１１６】
たとえば、このカテゴリ化のベースは、緑（このセットのリソースについてそれ以上の使用状況が合理的に予想できないことを示す）、赤（これらのリソースが使用されていない）、および黄（赤および緑のカテゴリ化を定義するしきい値の間の使用状況）にすることができる。次にこれらのカテゴリ化は、実行されると予想される対応するアクションに関連付けることができ、そのアクションは、ＣＥＥＣの否定、ＣＥＥＣの置き換え、ＣＥＥＣの移行などを含むことができる。
【０１１７】
たとえば、ＣＥＥＣのコホートに関するプロファイルは、そのコホートのＣＥＥＣに基づいてコンピューティング・リソース使用状況を評価するための評価基準を指定することができる（この場合も、あるコホートのメンバーはそのコホートの定義を指定する同じプロファイルに従って評価されることに注意されたい）。これらの評価基準は、プロファイルに指定された関心のあるそれぞれのコンピューティング・リソース・メトリックについて、測定基礎（たとえば、最小、最大、平均、変動率（volatility）など）、時間尺度（たとえば、時間単位、日単位、週単位）、スコアリング時間フレーム（たとえば、考慮すべき日数）、および任意のスコアリング・バイアス（たとえば、最良、移動平均、最新）を含むことができる。これらの評価基準は、コンピューティング・リソース使用状況を示す単一スコアに到達するためにコンピューティング・リソース使用状況メトリック測定を解釈し処理する方法と、ＣＥＥＣコホートのＣＥＥＣの条件についてコンピューティング・リソース使用状況をどのように測定するかを指定する。これらの評価基準は、どのようにコンピューティング・リソース使用状況データを解釈し、ＣＥＥＣ条件が契約当事者およびコンピューティング・リソース・プロバイダによって遵守されているかどうかに関する判断にそれを適用するかを決定するために、組織または企業の事業目標に従って設定することができる。
【０１１８】
評価は直接または総計で使用することができ、受け入れられる使用状況パターンは所与の時間尺度の範囲内でまたは所与の時間尺度の複数のインスタンスのセット内などで識別可能である可能性があることを意味する。たとえば、過去６週間という時間フレームにおいて少なくとも週に１日の受け入れられる使用状況について評価を実行することができる。
【０１１９】
使用状況スコアリング・サービス３２６によって実行されるスコアリング動作は、そのコホートに関するプロファイルに指定された評価基準に基づいて様々な方法で実行することができる。そのスコアを生成するために使用される特定の関数または数理アルゴリズムは本発明の焦点ではなく、プロファイルに指定された評価基準を取ることができ、ＣＥＥＣあるいはコンピューティング・リソースまたはその両方について単一の統一されたスコアを生成することができる任意の適切な関数または数理アルゴリズムは例示的な諸実施形態の精神および範囲内に入るよう意図されている。
【０１２０】
いくつかの例示的な諸実施形態では、これらの関数あるいは数理アルゴリズムまたはその両方は、プロファイルに指定されたコンピューティング・リソース使用状況メトリクスあるいは評価基準またはその両方のうちの様々なものに適用される重み付けを利用することができる。これらの重み付けは一定かつ既定のものにすることができ、たとえば、ＣＰＵ使用率は１．０という重みを有し、記憶容量使用状況は１．２５という重み付けを有し、平均週単位帯域幅使用状況は２．１５という重み付けを有する。これらの重み付けは、ＣＥＥＣおよびコンピューティング・リソース管理に関して組織または企業の事業目標を達成するために任意の望ましい値に設定することができる。
【０１２１】
代わって、これらの重み付けは、動的に決定することができ、特定のプロファイルおよびコホートに特有のものにすることができ、異なるプロファイルおよびコホートが同じコンピューティング・リソース使用状況メトリクスについて異なる重み付けを使用することができる。これらの動的に決定された重み付けは、ＣＥＥＣコホートのＣＥＥＣが関連付けられるコンピューティング・リソース・コホート（複数も可）のコンピューティング・リソースについて収集されたコンピューティング・リソース使用状況メトリクスの統計分析に基づいてさらに決定することができる。すなわち、コンピューティング・リソースに関するコンピューティング・リソース使用状況メトリクスの統計分析は、特定のコンピューティング・リソース、たとえば、ＣＰＵ容量、記憶容量、メモリ容量、帯域幅などが、コホート内の他のコンピューティング・リソースと比較したときにそのコンピューティング・リソースの実際の相対的使用状況をより強く示す傾向があることを示す可能性があり、コンピューティング・リソース・コホートが関連付けられているＣＥＥＣの条件を遵守してコンピューティング・リソースが使用されているかどうかをより強く示す可能性があり、したがって、このコンピューティング・リソース使用状況メトリクスの重み付けは、コンピューティング・リソース・コホート（複数も可）についてこのＣＥＥＣコホートに関するプロファイルに基づいてモニターされている他のコンピューティング・リソース使用状況メトリクスに対して動的に増加することができる。したがって、コンピューティング・リソース使用状況メトリクスの統計分析は、コンピューティング・リソース、コンピューティング・リソース・コホート、ＣＥＥＣ、またはＣＥＥＣコホートに関するスコアを生成するときに、これらのコンピューティング・リソース使用状況メトリクスの動的重み付けを決定するための基礎として使用することができる。
【０１２２】
さらに、重み付けの比率により、割り当てられたコホートに関する予想に適合しないかまたは何らかの他のコホートの予想に適合する使用状況パターンの検出が可能になる。場合によっては、低いＲＡＭ使用率と１００％のＣＰＵ使用率の組み合わせなど、比率が崩れた使用状況パターンはシステム問題を示す。プロファイルに定義されたしきい値は、このような使用状況をコホートに関連してどのように解釈すべきかを決定する。
【０１２３】
重み付けは、プロファイルがそのプロファイルによって定義されたコホートのコンピューティング・リソースの確定的制限に適したものになるようにするためのメカニズムとして使用することができる。したがって、たとえば、その使用状況が主に使用可能なメモリ・リソースの量によって制限されるコンピューティング・リソースでは、メモリ・リソースに関する重み付けは、メモリ・リソースが制限通りではないコンピューティング・リソースを有する他のコホートより重くなる可能性がある。したがって、そのプロファイルによって定義されたコホートを含む、特定のセットのコンピューティング・リソースおよびＣＥＥＣに関して適切に設定できるように、重み付けはそれぞれのプロファイルでカスタマイズ可能である。
【０１２４】
上記を考慮すると、例示的な諸実施形態は、少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースを含むデータ処理システムにおいて、コンピューティング環境受給権契約に対してコンピューティング・リソースの使用をモニターするためのメカニズムを提供するものであることを認識することができる。これらのメカニズムは、１つまたは複数のコンピューティング環境受給権契約（ＣＥＥＣ）データ構造を確立し、それぞれのＣＥＥＣデータ構造が契約当事者とデータ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義し、ＣＥＥＣの条件は、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定する。これらのメカニズムは、同様の条件を有するＣＥＥＣの集合と、ＣＥＥＣの集合内のＣＥＥＣの同様の条件を満足する特性を有するコンピューティング・リソースの集合とを含む、ＣＥＥＣコホートをさらに生成する。さらに、これらのメカニズムは、１つまたは複数のコンピューティング・リソース集合またはコホート内で、ＣＥＥＣの集合の同様の条件に従ってコンピューティング・リソースの集合内のそれぞれのコンピューティング・リソースの使用量を測定するリソース使用状況メトリクスを収集する。さらに、例示的な諸実施形態のメカニズムは、ＣＥＥＣコホートについて定義された事業目標に基づいて、コンピューティング・リソースの集合内のコンピューティング・リソースの様々なものに関するリソース使用状況メトリクスの相対的重み付けを決定する。その上、例示的な諸実施形態のメカニズムは、収集したリソース使用状況メトリクスおよびリソース使用状況メトリクスについて決定した相対的重み付けに基づいて、コンピューティング・リソースの集合のＣＥＥＣコホート使用状況を報告する。
【０１２５】
図７は、例示的な一実施形態によりコンピューティング・リソース使用状況スコアを生成するための動作例を概説する流れ図である。図７に概説されている動作は、たとえば、コンピューティング・リソース・コホートあるいはＣＥＥＣコホートまたはその両方内のコンピューティング・リソースに関する使用状況メトリクスにスコアを付けるときに、たとえば、使用状況スコアリング・サービス３２６によって実行することができる。
【０１２６】
図７に示されているように、この動作は、使用状況スコアリング・サービス３２６が使用状況スコアリング動作の対象であるコホートに関するプロファイルを取り出すことから始まる（ステップ７１０）。取り出したプロファイルからそのコホートに関する評価メトリックおよび評価基準情報を抽出し（ステップ７２０）、そのコホートに関連するコンピューティング・リソース（複数も可）に関する使用状況メトリック情報を取り出すかまたは収集する（ステップ７３０）。この取り出しは、たとえば、データがすでに情報技術管理システム３５２〜３５６から収集されている場合に、データベース・システム３３０から使用状況メトリック・データを取り出すことになる場合もあれば、特定のコンピューティング・リソースについて情報技術管理システム３５２〜３５６から使用状況メトリック・データを実際に収集することになる場合もある。
【０１２７】
取り出した／収集した評価使用状況メトリクスに適用すべき重み付けを決定する（ステップ７４０）。これは、たとえば、プロファイル６００に指定できる静的な定義済みの重み付けを取り出すことによって実行することができる。代わって、この重み付けは、この特定のコホートについて前に収集し分析した使用状況メトリクスからの傾向および統計情報の分析によって動的に決定することもできる。重み付けが動的に決定される場合、これらの重み付けは、使用状況スコアリング・サービス３２６による取り出しのためにプロファイル６００のフィールドに同様に保管することができるが、動的に更新することもできる。特定の実現例にかかわらず、この重み付けはスコアが付けられるコホートに特有のものであり、同じタイプの使用状況メトリクスまたはその他のタイプの使用状況メトリクスのいずれかについて、その他のコホートに関するその他の重み付けは現在のコホートに関する重み付けとは異なるものになる可能性がある。
【０１２８】
この重み付けを対応する使用状況メトリクスに適用し（ステップ７５０）、重み付けされた使用状況メトリクスおよびコホート・プロファイル６００に指定された評価基準に基づいてスコアを計算する（ステップ７６０）。前述の通り、評価基準は、評価を行うための時間フレーム、評価を行うための基礎（たとえば、最大、最小、平均など）、このような評価のためのバイアス（たとえば、最良、最悪、最新、移動平均など）など、あるいはこれらの組み合わせを含む、重み付けされた使用状況メトリクスを評価するための様々な基準を指定することができる。これらは、そのコホートまたはコホートのメンバーに関する単一のスコアを生成するために１つまたは複数の数理アルゴリズムあるいは公式を使用して、重み付けとともに使用状況メトリクスに適用することができる。スコアは、時間尺度内で直接決定する場合もあれば、たとえば、最新日単位スコア、または、時間フレーム内のそれぞれの日に関する日単位スコアなど、時間フレーム内のそれぞれの時間尺度について集計する場合もある。
【０１２９】
次に、このスコアを１つまたは複数のしきい値と比較して、使用状況がコホートの使用要件を遵守しているかどうかについてコホートの使用状況をカテゴリ化する（ステップ７７０）。このように生成したスコア（複数も可）をデータベース・システム内のコホートに対応する項目に関連して保管することができ（ステップ７７５）、スコアリングに基づく使用状況のカテゴリ化がコホート管理アクションを実行する必要性を示すかどうか、ならびにそのカテゴリ化に基づいてどのアクションを実行すべきかについて判断を行う（ステップ７８０）。これらのコホート管理動作は、たとえば、そのコホートに関連するＣＥＥＣを買取、売却、保留、または除去すること、追加のコンピューティング・リソースをコホートに追加するためのチケットを起動すること、そのコホートに関連するコンピューティング・リソースを廃止するためのチケットを起動することなどにすることができる。次に、たとえば、ＣＥＥＣマーケット・メーカ・メカニズム３３２などを介して、決定したコホート管理アクションを起動することができ（ステップ７９０）、この動作は終了する。
【０１３０】
コホートの模範メンバーの選択
上記に加えて、プロファイル６００およびコンピューティング・リソース使用状況情報に従って、使用状況スコアリング・サービス３２６によって実行されるスコアリングは、コホートの１つまたは複数の模範メンバーを選択するための基礎として使用することができる。たとえば、コホートのメンバーのリストを提供し、スコアで順序付けることができ、次に、コホートの模範メンバー、たとえば、コホートのメンバーの平均スコアを表すメンバー、コホート全体に関する全スコアに最も近いスコアを有するメンバーなどをそのリストから選択することができる。模範メンバー（典型的に、そのビジネス状況内で良好／受け入れ可能で達成可能と見なされるコンピューティング・リソース使用状況を有するコホート内のメンバー）は、そのコホート内の他のメンバーについて受け入れられる使用の境界を記述するために使用される。模範メンバーは、選択基準および順序付けられたメンバーのリストを使用してコホート管理サービス３２４によって自動的に選択するか、あるいはそれを介して順序付けられたメンバーのリストをユーザに提示することができ、ユーザがそのリストから模範メンバーを選択することができるグラフィカル・ユーザ・インターフェースを使用してコホートおよびプロファイル・マネージャ３１４を介して手動で選択することができる。
【０１３１】
同様に、逆模範メンバーは、自動的にまたは手動で、同様の方法で選択することができる。コホートの逆模範メンバーは、好ましくは、そのビジネス状況内で使用されていないコホート内のメンバーから選択され、たとえば、「赤」カテゴリ内にあるコンピュータ・リソース使用状況情報はそのコホート内の他のメンバーについて不使用の境界を記述するために使用される。このような逆模範はコホートの「ノイズ・フロア」、すなわち、「不使用」と見なすべきバックグラウンドまたはベースライン活動の最大量を定義する。たとえば、ＲＡＭの場合、逆模範は、他には何も行わずにＯＳをロードするために必要なＲＡＭの量を定義する。
【０１３２】
コホートの模範および逆模範メンバーは、そのコホートに対応するプロファイル６００内の境界、たとえば、対応するコホートにおけるメンバーシップを調整すべき時期を決定するための基準６５０およびこれらの調整基準に関連する対応するアクション６５５を設定するための基礎として使用することができる。したがって、たとえば、特定のコホートにとって重要である特定の使用状況情報に基づいて、そのコホートのメンバーについて収集した実際の使用状況情報の統計表現を生成することができ、たとえば、関心のあるメトリクスに関する使用状況情報の分布、正規化曲線、またはその他の統計表現をそのコホートについて生成することができる。この統計表現は、使用状況メトリクスの様々な要素に提供された重み付けに基づくものにすることができ、前に述べたように、その重み付けは既定のものであるかまたは動的に決定される。その上、統計表現は、特定の期間について入手した使用状況情報に基づいて生成することができ、したがって、統計表現は、コホート内のコンピューティング・リソース使用状況挙動の傾向を経時的に表すことができる。
【０１３３】
結果として得られる統計表現は、そのコホートにおけるメンバーシップを考慮するためのコンピューティング・リソース使用状況の上限および下限を設定する際に使用するためにそのコホートの模範および逆模範メンバーを自動的に識別するためにコホート管理サービス３２４によって分析することができる。代わってまたは加えて、許可ユーザが模範および逆模範メンバーを選択するかまたはコホート管理サービス３２４によって行われた自動選択を指定変更できるように、コホートおよびプロファイル・マネージャ３１４を介して統計表現のグラフ出力を生成し、許可ユーザに提示することができる。
【０１３４】
コホート管理サービス３２４によって実行されたリソース使用状況情報の統計表現の生成およびその分析は、複数のコホートを互いに比較する方法として使用することができる。すなわち、あるコホートの傾向（パターン）および統計表現を他のコホートのものと比較して、どのコホートが同様のリソース使用状況傾向を有するかを判断することができる。コホート・メンバーシップを変更する必要があるときに、論理的に接続されたコホート同士を最初にチェックして、あるコホートのメンバーを論理的に接続されたコホートに移転すべきかどうかを判断できるように、これらの同様のコホートはコホート管理サービス３２４内で論理的に接続することができる。このようにして、あるタイプの「連結リスト」手法を使用して、まず第１のコホートに直接、論理的に連結されたものを探し、次に第１のコホートに直接連結されたコホートに論理的に連結されたコホートへと探索を続けることなどにより、第１のコホートから追い出されるメンバーの移転先である新しいコホートを探すことができる。特に、同様の使用状況パターンまたは傾向を有する複数のコホートのコストが著しく異なる場合、このようなコホート再割り当てはコストあるいは価値またはその両方を基礎として実行することができるであろう。
【０１３５】
リソース使用状況情報の統計表現またはその他の分析は、アウトライアであって、コホートから追い出さなければならないコホートのメンバーを決定するためにさらに使用することができる。すなわち、あるコホートの模範または逆模範メンバーとは著しく異なる（たとえば、所定のしきい値に基づいて著しく異なると判断することができる）ことを示すスコアまたはコンピュータ・リソース使用状況情報を有するコホートのメンバーは、アウトライアとしておよびコホートからの立ち退き（eviction）の候補として識別することができる。立ち退きにより、そのメンバーはもはやそのコホートに関連付けられず、したがって、そのコホートの詳細の評価に含まれなくなるが、さらにそのメンバーは以下に説明するようにマーケット・メーカ・メカニズムを介して他のより適切なコホートに関連付けられる。本質的に、立ち退きにより、現在のコホートはＣＥＥＣまたはコンピューティング・リソースの売却側になり、他のコホートはそのＣＥＥＣまたはコンピューティング・リソースの潜在的な買取側として機能する。ＣＥＥＣマーケット・メーカ・サービス３２２などのＣＥＥＣベースのマーケット・メーカ・メカニズムにおける買取側、売却側の選択および市場要因の使用については、以下により詳細に説明する。
【０１３６】
図８は、例示的な一実施形態によりコホートの模範および逆模範メンバーを選択し、この選択を使用して、プロファイル内の評価基準および関連アクションを定義するための動作例を概説する流れ図である。図８に概説されている動作は、たとえば、コホート管理サービス３２４とともに使用状況スコアリング・サービス３２６によって実現することができる。
【０１３７】
図８に示されているように、この動作は、コホートのメンバーに関する使用状況スコアを入手することから始まり、これらのメンバーはコンピューティング・リソースまたはＣＥＥＣにすることができる（ステップ８１０）。コホートのメンバーに関連するスコアに応じて、そのメンバーの順序付きリストまたはその他の順序付き配列を生成し、順序付ける（ステップ８２０）。模範選択基準、たとえば、平均、平均スコアに最も近いものなどに基づいて、メンバーの順序付き配列からコホートの模範メンバーを選択する（ステップ８３０）。逆模範選択基準、たとえば、平均から最も遠いスコア、最高または最低スコアなどに基づいて、メンバーの順序付き配列からコホートの逆模範メンバーを選択する（ステップ８４０）。模範メンバーの使用状況メトリクスに基づいて、そのコホートに関する使用状況境界、たとえば、しきい値および使用状況範囲またはスコア範囲、ならびに関連アクションを設定する（ステップ８５０）。その後、この動作は終了する。
【０１３８】
ＣＥＥＣおよびコホートの関連付けに基づくコンピューティング・リソース予約
確立されたコホートおよびその関連付けに基づいて、コンピューティング・リソース・コホートに関連するＣＥＥＣコホート内のＣＥＥＣの契約当事者による使用のために、コホートのコンピューティング・リソースの様々なものが予約される。ＣＥＥＣベースの予約サービス３２８は、以下に説明するように、組織システムまたはエンタープライズ・システム内でこのような予約を実行し、あるトランザクションのトランザクション決済フェーズの一部など、コンピューティング・リソースに関する予約を除去するためのロジックを含む。このような予約は、ユーザ・アカウントを生成すること、ユーザ・アカウントを移行すること、契約当事者に対してコンピューティング・リソース、たとえば、ラップトップ・コンピュータ、デスクトップ・コンピュータなどを接収するための接収チケットを生成すること、契約当事者からコンピューティングｒ・リソースを回収する、たとえば、契約当事者から使用されないかまたは十分使用されていないラップトップ・コンピュータ、デスクトップ・コンピュータなどを回収するための回収チケットを生成することなどを含むことができる。
【０１３９】
コンピューティング・リソースの予約は、そのコンピューティング・リソースが同じかまたは異なるＣＥＥＣコホートの他のＣＥＥＣによる予約のために使用可能であるかどうかならびにそのコンピューティング・リソースのうちのどのくらいが使用可能であるかを判断するために、コンピューティング・リソース・コホートに関連するＣＥＥＣコホートのＣＥＥＣに指定された受給権の対象であるコンピューティング・リソース・コホートのコンピューティング・リソースの総量をモニターすることをさらに含むことができる。たとえば、現在、そのコンピューティング・リソース・コホートに関連するＣＥＥＣコホートのＣＥＥＣは、予約されているコンピューティング・リソース・コホートのＣＰＵコンピューティング・リソースのうちの９０％を表すと判断することができる。確立されたコンピューティング・リソース予約しきい値に基づいて、予約されたコンピューティング・リソースのこの量をしきい値と比較して、追加のＣＥＥＣに対処できるかどうかを判断することができ、コホート管理動作、たとえば、ＣＥＥＣとコホートとの関連付け、コンピューティング・リソースとコホートとの関連付け、コホート間のＣＥＥＣの移行などを決定するときに、このような判断を使用することができる。さらに、このようなしきい値との比較は、ＣＥＥＣと関連付けるために使用できる使用可能なコンピューティング・リソースの量を増加するために組織システムまたはエンタープライズ・システムに追加のコンピューティング・リソースを追加する必要性についてシステム管理者またはその他の許可ユーザに対して警報または通知を発生する方法として使用することができる。
【０１４０】
したがって、ＣＥＥＣの生成、プロファイルの生成、これらのプロファイルに基づくコホートの生成、およびＣＥＥＣコホートとコンピューティング・リソース・コホートとの関連付けに基づいて、これらのＣＥＥＣの契約当事者による使用のためにコンピューティング・リソースを予約することができる。その上、ＣＥＥＣとコホートのコンピューティング・リソースとの関連付けをサポートするために十分なコンピューティング・リソースが使用可能であるかどうか、ＣＥＥＣの移行が適切であるかどうか、あるいはＣＥＥＣコホートのＣＥＥＣをサポートするために追加のコンピューティング・リソースを追加する必要性についてならびにこのような追加が適している場所、すなわち、どのコンピューティング・リソース・コホートが適しているかについて、システム管理者またはその他の許可された個人に通知すべきかどうか、またはこれらの組み合わせについて判断を行うことができる。
【０１４１】
加えて、コンピューティング・リソースがもはや特定のＣＥＥＣに関連付けられない場合、ＣＥＥＣによるこれらのコンピューティング・リソースの予約を除去することができる。廃止する必要があるコンピューティング・リソースからＣＥＥＣを移行するような事例では、ＣＥＥＣベースの予約サービス３２８は、システム管理者またはその他の許可ユーザが組織／企業内で有用な状態からそのコンピューティング・リソースを実際に除去するために、作業チケットまたは通知を生成して発行することができ、その組織／企業は、物理的なハードウェア・デバイスの場合、物理的なハードウェア・デバイスを除去するために組織システム／エンタープライズ・システムを再構成すること、ハードウェア・デバイスを物理的に切り離すこと、物理的なハードウェア・デバイスの除去および処分が必要になる可能性がある。これは、たとえば、使用されていないか、十分使用されていないか、またはＣＥＥＣに指定された通りに使用することが意図されていたものとは異なる目的に使用されている、古く潜在的に時代遅れのコンピューティング・リソースからＣＥＥＣを移行し、より新しく潜在的により効率的なコンピューティング・リソースにＣＥＥＣを移行するというシナリオに該当する可能性がある。
【０１４２】
ＣＥＥＣ遵守の判断
上記のメカニズムにより、例示的な諸実施形態のＣＥＥＣベースのマーケット・メーカ・システム３００は、コンピューティング・リソースが契約当事者に関連するＣＥＥＣを遵守して契約当事者によって使用されている時期を決定することができる。特に、ＣＥＥＣベースのマーケット・メーカ・システム３００によって提供されるロジックは、ＣＥＥＣコホートを操作して、ＣＥＥＣコホート内のＣＥＥＣの条件がこれらのＣＥＥＣに関連するコンピューティング・リソース・コホート（複数も可）内のコンピューティング・リソースに関する契約当事者の使用状況によって満足されているかどうかを判断することができる。情報技術モニター・システム３５０から入手し、データベース・システム３３０に保管されたコンピューティング・リソース使用状況メトリック情報ならびに使用状況スコアリング・サービス３２６から入手したスコアリング情報を使用して、コンピューティング・リソース・コホート内のこれらのコンピューティング・リソースがＣＥＥＣコホートのＣＥＥＣに指定された所定の使用要件を満たすように使用されているかどうかを判断することができる。
【０１４３】
一例として、この例を単純にするため、ＣＥＥＣコホートが単一のＣＥＥＣからなり、このＣＥＥＣコホートが複数のコンピューティング・リソースを含む単一のコンピューティング・リソース・コホートに関連付けられるものと想定する。ＣＥＥＣコホートとコンピューティング・リソース・コホートとのこの関連付けは、前述のメカニズムに従って実行することができる。定期的に、連続的に、またはシステム管理者または許可ユーザがＣＥＥＣ遵守の判断を要求するなどのイベントに応答して、ＣＥＥＣデータベース３３４で識別されたＣＥＥＣについてＣＥＥＣマネージャ３１８によってＣＥＥＣ遵守動作を実行することができる。ＣＥＥＣ遵守動作の結果として、遵守報告を生成して、システム管理者またはその他の許可ユーザに出力することができ、ＣＥＥＣコホートの調整を開始することができる。
【０１４４】
ＣＥＥＣ遵守動作は、ＣＥＥＣコホートのＣＥＥＣについて（または１つのＣＥＥＣコホートに複数のＣＥＥＣが存在する例では１つのＣＥＥＣコホート内のそれぞれのＣＥＥＣについて）そのＣＥＥＣの条件に指定された最小使用要件を決定することができ、たとえば、１日あたりの平均ＣＰＵ使用率の５０％が会計ソフトウェアの実行に向けられる。そのＣＥＥＣコホートに関連するプロファイルに基づいて、ＣＥＥＣ遵守動作は、そのＣＥＥＣコホートが関連付けられているコンピューティング・リソース・コホート（複数も可）の特定のコンピューティング・リソースについて収集されたコンピューティング・リソース・メトリック情報からコンピューティング・リソース使用状況情報を入手することができる。たとえば、ＣＥＥＣコホートが、そのＣＥＥＣコホートのプロファイルに指定することができる特定のタイプ、コア数、速度などのプロセッサに対応するコンピューティング・リソース・コホートに関連付けられ、毎分のプロセッサ・サイクル・ピーク数に関してリソース使用状況評価を実行しなければならないことをそのＣＥＥＣコホートのプロファイルが示している場合、コンピューティング・リソース・コホート内のプロセッサについて収集した毎分のプロセッサ・サイクル・ピーク数情報に基づいて、コンピューティング・リソース情報を決定することができる。この情報は、このピーク・サイクル数の間にどのプロセスが実行されていたかを示す情報と相関させることができる。これにより、そのコンピューティング・リソースが様々なプロセスの実行に専念していた時間の長さおよびプロセッサ・サイクル数に接近することができる。
【０１４５】
この精査の特異性はＣＥＥＣのコスト次第で変動する可能性がある。たとえば、最も高価なＣＥＥＣはこのプロセス・レベルで評価することができ、最も安価なＣＥＥＣは平均的な一般的使用状況を基礎としてより単純に測定することができる。後者の場合、遵守チェックは、重み付きの複合使用状況スコアがしきい値より上かどうかを判断することだけである。２つの極値間の任意の程度の特異性をサポートすることができる。
【０１４６】
このコンピューティング・リソース使用状況情報およびＣＥＥＣコホートのプロファイルに指定された評価基準に基づいて、１日あたりのＣＰＵ使用率の少なくとも５０％が会計ソフトウェアの実行に向けられるかどうかについて判断が行われる。したがって、たとえば、コンピューティング・リソース使用状況情報により、他のタイプのプロセスと対照的に会計ソフトウェア・プロセスの実行に専念していた全ピーク・サイクル数を決定することができる。これにより、指定の期間、たとえば、１日について、平均またはその他の評価基準指定値を生成することができる。次に、この値をＣＥＥＣの条件に指定された最小要件と比較して、そのＣＥＥＣが関連付けられているコンピューティング・リソース・コホート内のコンピューティング・リソースの契約当事者による使用によってそのＣＥＥＣが遵守されているかどうかを判断することができる。
【０１４７】
遵守は、厳格または柔軟な遵守標準に基づいて判断することができる。厳格な遵守では、ＣＥＥＣの特定の条件が満たされることを要求し、そうではない場合に、ＣＥＥＣは遵守されていないと判断される。柔軟な遵守では、ＣＥＥＣに遵守していると見なされるが、たとえば、追加のモニタリングのためのフラグが立てられる可能性がある、ＣＥＥＣの条件周辺の許容範囲を斟酌する。したがって、あるＣＥＥＣに追加のモニタリングのためのフラグが立てられる場合、たとえば、開始したＣＥＥＣ遵守動作に関するイベントを高い頻度でスケジューリングすることができる。厳格か柔軟かにかかわらず、ＣＥＥＣ条件に対する遵守の判断に基づいて、遵守度の表現を生成し、ＣＥＥＣコホートのプロファイルに関連しプロファイルに定義されたアクションとともに、実行すべき適切なアクションを決定するための基礎として使用することができる。たとえば、上記で前述したように、ＣＥＥＣを遵守しているか、厳格な遵守の許容範囲内であるが、さらにモニターする必要があるか、あるいは遵守していないかを、色分けなどにより識別する、多軸グラフなどのグラフ表現を生成することができる。このグラフ表現は、組織または企業の事業目標を達成するために、ＣＥＥＣを変更する方法、コホートの関連付けなどに関する決定を行えるように、システム管理者またはその他の許可ユーザに出力することができる。
【０１４８】
これは、移行を処理するための企業の意欲あるいは能力またはその両方によって左右される可能性がある。たとえば、その企業が１ヶ月で１００件のＣＥＥＣを移動できる場合、１００００件のＣＥＥＣを識別してもほとんど意味がない。したがって、しきい値は始めに「緩く」定義され、それにより最も遵守度が低いＣＥＥＣのみが識別されるようになり、その後、進行するにつれて、より厳しく定義することができる。
【０１４９】
その上、様々な遵守度に対応してＣＥＥＣコホートに関するプロファイルに指定されたアクションは、ＣＥＥＣマーケット・メーカ・サービス３２２を使用して、自動的に開始することができる。これらのアクションは、たとえば、売却、保留、または排除にすることができる。たとえば、そのＣＥＥＣが遵守されているかまたは厳格な遵守の許容範囲内であることを遵守度が示す場合、そのＣＥＥＣの移行について何も実行されない保留アクションを実行することができ、したがって、そのＣＥＥＣはＣＥＥＣコホートの一部のままであり、ＣＥＥＣコホートは１つまたは複数のコンピューティング・リソース・コホート（複数も可）に関連付けられたままになる。そのＣＥＥＣが遵守されていないが、ＣＥＥＣ条件に基づく何らかの使用状況が存在することを遵守度が示す場合、売却アクションを開始して、そのＣＥＥＣを否定し、実際の使用状況に対応する新しい条件を有する新しいＣＥＥＣで置き換えることができるか、あるいはそのＣＥＥＣまたは置き換えＣＥＥＣを他の１つまたは複数のコンピューティング・リソース・コホート（複数も可）に移行するか、またはその両方を行う。そのＣＥＥＣの条件に関する使用状況がまったくないことを遵守度が示す場合、そのアクションは、ＣＥＥＣの置き換えなしにそのＣＥＥＣを排除することになる可能性がある。
【０１５０】
コンピューティング・リソース・コホートを定義するプロファイルに指定された使用要件に対するコンピューティング・リソース使用状況の遵守について、同様の遵守判断を行えることを認識されたい。このような遵守判断は、典型的に、そのコホートが追加のＣＥＥＣの「買取」を保証するために十分な使用可能なリソースを有すること、そのコホート・リソースが他のコンピューティング・リソース・コホートへのＣＥＥＣの「売却」を保証するために十分に使用されること、あるいはいかなる変更も行ってはならない、すなわち、「保留」アクションを実行しなければならないような効率的なレベルでコホート・リソースが使用されていることを、コンピューティング・リソース・コホートの使用状況が示すかどうかを判断するために行われる。したがって、コンピューティング・リソース・コホートは、ＣＥＥＣマーケットにおける買取側または売却側として指定することができ、ＣＥＥＣマーケットにおける商業単位はＣＥＥＣであり、すなわち、コンピューティング・リソース・コホートはＣＥＥＣの買取側または売却側のいずれかであり、それが買取側であるかまたは売却側であるかという判断は、コンピューティング・リソース使用状況分析ならびにＣＥＥＣ条件に対する遵守に基づいて行うことができる。
【０１５１】
ＣＥＥＣ遵守動作を介して識別される特定のアクションは、トランザクション・ビルダ３１２を使用してＣＥＥＣマーケット・メーカ・サービス３２２を介して実行することができる。すなわち、ＣＥＥＣを買い取るかまたは売却するためにトランザクションを作成することができる。ＣＥＥＣマーケット・メーカ・サービス３２２は、組織または企業の事業目標を達成するためにＣＥＥＣマーケット・メーカ・サービス３２２に指定されたルールおよびパラメータに従って、買取側および売却側を対にすることによってトランザクションを処理することができる。これらのルールまたはパラメータは、評価基準およびＣＥＥＣ遵守判断とともに、本質的に、ＣＥＥＣコホートを介してＣＥＥＣを移行し、コンピューティング・リソース・コホートを介してコンピューティング・リソースと関連付けるための市場要因を定義するものである。ＣＥＥＣマーケット・メーカ・サービス３２２の実際の動作については、以下により詳細に説明する。
【０１５２】
図９は、例示的な一実施形態によりＣＥＥＣ遵守を評価するための動作例を概説する流れ図である。図９に示されているように、この動作は、遵守が評価されるＣＥＥＣに関するＣＥＥＣ条件の識別から始まる（ステップ９１０）。ＣＥＥＣが関連付けられているコンピューティング・リソース・コホート（複数も可）からコンピューティング・リソース使用状況情報を収集する（ステップ９２０）。コンピューティング・リソースがＣＥＥＣの条件を遵守して使用されていることをコンピューティング・リソース使用状況情報が示すかどうかについて判断を行う（ステップ９３０）。そうである場合、ＣＥＥＣコホートまたはコンピューティング・リソース・コホート（複数も可）の変更をまったく行わないように「保留」アクションを実行する（ステップ９４０）。ＣＥＥＣ条件が遵守されていないことをコンピューティング・リソース使用状況情報が示す場合、ＣＥＥＣコホートに対応するコンピューティング・リソース・コホート（複数も可）がＣＥＥＣマーケット・メーカ・システムにおいてＣＥＥＣの売却側になるように、「売却」アクションを実行することができる（ステップ９５０）。コンピューティング・リソース・コホート（複数も可）が追加のＣＥＥＣを受け入れるために十分なリソースを有することをコンピューティング・リソース使用状況情報が示す場合（ステップ９６０）、これらのコンピューティング・リソース・コホート（複数も可）はＣＥＥＣマーケット・メーカ・システムにおいて買取側になることができる（ステップ９７０）。その後、この動作は終了する。
【０１５３】
したがって、ＣＥＥＣ遵守動作を介して、コンピューティング・リソース・プロバイダがＣＥＥＣに基づいて必要なリソースを提供するだけでなく、契約当事者がＣＥＥＣの条件を遵守してコンピューティング・リソースを使用していることにより、ＣＥＥＣ条件が満足されているかどうかについて判断を行うことができる。ＣＥＥＣ条件が契約当事者によって満足されていない場合、そのＣＥＥＣは、他のコンピューティング・リソース・コホート（複数も可）に移行されるか、否定され、同じかまたは異なるコンピューティング・リソース・コホート（複数も可）に関連して同じかまたは異なるＣＥＥＣコホート内の新しいＣＥＥＣと置き換えられるか、または望ましい場合に置き換えられずに単純に排除される可能性がある。これは、事実上、コンピューティング・リソースおよび契約当事者についてＣＥＥＣの条件を執行するものである。
【０１５４】
否定されたＣＥＥＣはすべて等しいわけではない。このため、最もコストが高いＣＥＥＣの価値が最も高くなるように価格査定できるか、または最も容易な節約を提供するＣＥＥＣをその企業が優先できることが重要になる。
【０１５５】
さらに、企業は、以下に説明するＣＥＥＣマーケット・メーカを介して、その短期または長期の目標にかなうように任意の他のことを基礎としてＣＥＥＣを否定する能力を有する。このような否定は、任意の自動化されたＣＥＥＣ遵守評価を指定変更するものである。したがって、企業は、たとえば、特定のデータ・センターにおけるリースを終了し、すべての作業負荷を他の場所に移行したいということ以外の理由なしに、そのデータ・センターにおけるシステムのＣＥＥＣを否定することができる。
【０１５６】
ＣＥＥＣマーケット・メーカ・サービス
ＣＥＥＣマーケット・メーキングは、一般に、支援なしに互いを見つけることが難しいと思われる環境でＣＥＥＣの買取側と売却側を招集することを指す。ＣＥＥＣマーケット・メーカ・サービス３２２は、買取側コンピューティング・リソース・コホートと売却側コンピューティング・リソース・コホートを招集するメカニズムであり、売却側から買取側に既存のＣＥＥＣを再割り当てすることまたは売却側でＣＥＥＣを否定して買取側に関連する新しいＣＥＥＣでそのＣＥＥＣを置き換えることのいずれかを介して、売却側コンピューティング・リソース・コホートから買取側コンピューティング・リソース・コホートにＣＥＥＣを移行するためのトランザクションを容易にするものである。場合によっては、ＣＥＥＣマーケット・メーカ・サービスは、トランザクションの時点でＣＥＥＣの買取側と売却側の両方が分かっている同期トランザクションに関する買取側と売却側の単純な突き合わせを越えるものであるが、その代わりに、ＣＥＥＣマーケット・メーカは、トランザクションの一方の側（買取側または売却側）が分かっており、指定の基準を使用してもう一方の側（買取側または売却側のうちのもう一方）を見つけるか、買取側がまだ間近ではない予定の購入に関連付けられる非同期トランザクションに関する能力を提供することができる。
【０１５７】
ＣＥＥＣマーケット・メーカ・サービス内で買取側と売却側を関連付けるためのトランザクションは、ＣＥＥＣの条件を満足できるようにあるいは前のＣＥＥＣに基づく実際の使用状況により密接に適合する新しいＣＥＥＣが作成され、コンピューティング・リソース・コホートに関連付けられるように、ＣＥＥＣの移転を容易にするだけでなく、組織または企業に関する事業目標を達成するように機能する。すなわち、組織または企業は、ＣＥＥＣマーケット・メーカ・サービス３２２が特定の目標を達成するように機能する方法を案内するためのルールおよびパラメータを明記することができる。このような目標の例としては、たとえば、特定の省エネ目標を達成すること、組織内の所与の位置を明け渡すためにその位置に関連するＣＥＥＣのすべてを売却すること、新しいハードウェアの購入のために指定の目標ドル建て金額でビジネス・ケースを構築すること、価値が最も高い資産（コンピューティング・リソース）の使用状況を目標使用状況にすること、新しいコンピューティング・リソース（たとえば、ハードウェアまたはソフトウェア）を配置するために最も安価な場所を決定すること、最大コスト削減になる新しいコンピューティング・リソースのための場所を特定すること、移行の推定値に基づいてＣＥＥＣの移行の優先順位付きリストを作成することなどを含むことができる。
【０１５８】
ＣＥＥＣマーケット・メーカ・サービス３２２の基本的目標は、所望の目標を達成するために、移行元（migration source）、たとえば、旧式のハードウェア／ソフトウェア、十分使用されていないハードウェア／ソフトウェアなど（売却側）から、移行先（migration sink）、たとえば、新しいハードウェア／ソフトウェア、仮想化コストなど（買取側）へのＣＥＥＣおよびそれに関連する作業負荷の移行に関するものである。ＣＥＥＣ遵守動作の結果に対する応答として、または、所望の目標およびこのような所望の目標を達成するために生成された１つまたは複数の取引指定に基づいて潜在的な買取側および売却側についてＣＥＥＣマーケット・メーカ・サービス３２２により独立した識別を行うことにより、コホートをこのＣＥＥＣマーケット内で買取側または売却側として指定することができる。この移行は、ＣＥＥＣマーケット・メーカ・サービス３２２が操作するトランザクションにより容易になる。トランザクションは、自動的に、半自動的に、またはトランザクション・ビルダ３１２を介して手動で、生成することができる。
【０１５９】
ＣＥＥＣマーケット・メーカ・サービス３２２内のトランザクションのライフ・サイクルには４つのフェーズ、すなわち、作成、組み立て、開始、および決済がある。作成フェーズ中に、トランザクション・ビルダ３１２を使用して、スクラッチからまたは既存の取引指定からトランザクション・レコードが作成される。トランザクションの作成者は、人間のユーザまたは自動プロセスにすることができ、トランザクション・ビルダ３１２を介して買取側および売却側に関する指定、たとえば、売却側に関するＣＥＥＣ条件、買取側のコンピューティング・リソースまたはコホートに関する構成要件などを作成または選択し、たとえば、これらの選択された指定は、コンピューティング・リソース上でどのオペレーティング・システムが実行されるか、どのタイプのプロセッサか、プロセッサの数量、メモリ・リソースの量、ＣＥＥＣの事業目的、ＣＥＥＣに関連する組織部門、あるいはコンピューティング・リソースまたはＣＥＥＣに関する任意の他の識別可能なパラメータを含むことができる。この選択は、トランザクション・ビルダ３１２のユーザ・インターフェース要素に様々な指定パラメータを許可ユーザに入力させること、潜在的な指定パラメータのリストからこれらの指定パラメータを選択することなどにより、実行することができる。
【０１６０】
トランザクションの組み立てフェーズ中に、トランザクション作成者または自動ＣＥＥＣマーケット・メーカ・サービス３２２は、この指定を使用して、組織システムまたはエンタープライズ・システム内で特定の売却側および買取側のコンピューティング・リソース・コホートを選択する。たとえば、売却側は、ＣＥＥＣ遵守動作の結果がＣＥＥＣを売却する必要性を示した結果として売却側になりたいという要望を示したコンピューティング・リソース・コホートのセットから選択することができる。代わって、売却側になりたいという要望を示したかどうかにかかわらず、売却側になるべきコンピューティング・リソース・コホートを選択することにより、指定の事業目標に従って売却側を選択することができる。
【０１６１】
同様に、買取側は、買取側になりたいという要望を示したコンピューティング・リソース・コホートのセットから選択することができる。このような表示は、コンピューティング・リソース・コホートが十分使用されておらず、追加のＣＥＥＣを受け入れるための能力があるという判断に対する応答として行うことができる。代わって、買取側になりたいという要望を示したかどうかにかかわらず、買取側になるべきコンピューティング・リソース・コホートを選択することにより、指定の事業目標に従って買取側を選択することができる。さらに、これらの手法の組み合わせを使用して、買取側を選択することができる。
【０１６２】
コンピューティング・リソース・コホート内の使用可能なコンピューティング・リソース容量あるいはＣＥＥＣ遵守動作により決定されたＣＥＥＣ条件に対する非遵守またはその両方により売却側および買取側が識別される場合、ＣＥＥＣマーケットは、移行されるＣＥＥＣを満足する方法で使用される可能性が大きいコンピューティング・リソース・コホートにＣＥＥＣを移行する方法として機能する。前述の通り、この移行の結果、場合によっては、移行される元のＣＥＥＣが否定され、新しいＣＥＥＣに基づいてコンピューティング・リソースを提供できるコンピューティング・リソース・コホート（複数も可）に関連するＣＥＥＣコホートに関連して新しいＣＥＥＣが作成される可能性がある。この新しいＣＥＥＣは、契約当事者によるＣＥＥＣの実際の測定使用状況に基づいて、元のＣＥＥＣとは異なる使用要件を有することができる。したがって、たとえば、第１のＣＥＥＣに基づいて契約当事者がＸという第１のレベルで毎週Ｙという平均使用量の第１の強度パターンでコンピューティング・リソースを使用することを要求されていたが、その代わりに、測定使用状況はＺという使用状況レベルで毎週Ｗという平均使用量の第２の強度パターンを示した場合、元のＣＥＥＣが否定される可能性があり、毎週Ｗという平均使用量である強度パターンでＺという使用状況を要求する新しいＣＥＥＣが作成される可能性がある。この新しいＣＥＥＣは、新しいＣＥＥＣの条件を満足することができるコンピューティング・リソース・コホートに関連するＣＥＥＣコホートのメンバーとして追加することができる。このような状況では、元のＣＥＥＣコホートに関連する元のコンピューティング・リソース・コホートは元のＣＥＥＣの売却側であり、新しいＣＥＥＣコホートに関連するコンピューティング・リソース・コホートはＣＥＥＣマーケット内の新しいＣＥＥＣの買取側である。
【０１６３】
買取側／売却側になりたいという要望をコホートが示したかどうかにかかわらず、事業目標に基づいて売却側および買取側が選択される場合、その事業目標を識別することができ、これらの事業目標を満たす特性を有する対応するコンピューティング・リソース・コホートが選択される。これは、コンピューティング・リソース使用状況情報、構成情報、ＣＥＥＣコホート関連付け情報などを分析して、どのコンピューティング・リソース・コホートが事業目標に指定された基準を満たす特性を有するかを判断することを含むことができる。一例として、事業目標がＣＥＥＣおよびそれに関連する作業負荷をデスクトップ・コンピューティング・デバイスから仮想計算機またはサーバに移動させることである場合、デスクトップ・コンピューティング・デバイスを含むコンピューティング・リソース・コホートは、コンピューティング・リソース・コホートのコンピューティング・リソースに関連する構成情報に基づいて識別することができる。これらのコンピューティング・リソース・コホートは、ＣＥＥＣマーケット内でＣＥＥＣの売却側として選択することができる。同様に、仮想サーバ・ソフトウェア・メカニズムを有するサーバ・コンピューティング・デバイスを示す構成情報を有するコンピューティング・リソース・コホートを識別し、ＣＥＥＣマーケット内でＣＥＥＣの買取側として選択することができる。
【０１６４】
組み立てフェーズ中に、選択された売却側および買取側はいずれもトランザクションの受諾または拒否を知らせる。取引は将来のある時点で決済できるの、これにより選択された売却側および買取側は、まだ確認されていない「候補」買取側および売却側になる。しかし、買取側および売却側は、自分の過失ではないのに決済時に自分の義務を果たすことができない可能性がある。トランザクションの目標を満たすのに十分な売却側および買取側が現れるまで、組み立てフェーズは完了しない。したがって、たとえば、トランザクションの事業目標がＣＥＥＣおよびその作業負荷を組織のサイトＡに関連するすべてのコンピューティング・リソースから移行することである場合、サイトＡに関連するすべてのコンピューティング・リソース・コホートがＣＥＥＣの売却側として識別され、サイトＡに関連するすべてのＣＥＥＣコホートを他のサイトに移行できるようにするために他のサイトの十分なコンピューティング・リソース・コホートがＣＥＥＣの買取側として識別されるまで、トランザクションの組み立てフェーズは完了しない。
【０１６５】
トランザクションの事業組織を満足するために十分な買取側および売却側が存在すると判断され、トランザクションの成立の結果が満足のいくものであると判断されたことに応答して、トランザクションの開始フェーズが実行される。トランザクション成立結果が満足のいくものであるかどうかという判断は、成立のメトリックを１つまたは複数の所定のしきい値と比較することにより、自動的に行うことができる。たとえば、コストおよび価値をトランザクションの様々な面に関連付けることができ、特定の選択された買取側および売却側についてこれらのコストおよび価値を計算して、そのトランザクションに関する実際のコスト／価値メトリックを決定することができる。次に、トランザクションに関するこのコスト／価値メトリックを１つまたは複数のしきい値と照らし合わせて比較して、そのトランザクションを完了しなければならないような組織／企業にとって十分な利益をそのトランザクションのコスト／価値が示すかどうかを判断することができる。
【０１６６】
コスト／価値メトリックがそのトランザクションを完了することが望ましいことを示すと想定して、売却側から買取側へのＣＥＥＣの移行を容易にするために必要な動作が開始される。これらの動作は、たとえば、図３のＣＥＥＣベースのリソース予約サービス３２８を使用して、たとえば、様々なリソース予約を実行することを含むことができる。また、この動作は、たとえば、任意の本質的ではないストレージの解消、買取側システム上のＯＳインスタンス・コンテナの作成などを含む、ＣＥＥＣに基づいて作業負荷移行を準備するための動作も含むことができる。これらの動作が実行されると、買取側および売却側は、候補ではなくなり、この時点で正式に、一緒にトランザクションを満足する買取側と売却側との間の取引の要件を遂行する義務を負う。トランザクションの適正な決済を保証するために、取引に基づく任意の期間限定義務に関するタイマを始動し、モニターすることができる。
【０１６７】
取引が開始されると、トランザクションが決済されるまで、すなわち、すべての取引が正常に完了するまで、買取側と売却側との間の実際の取引を実行するためのアクションが開始される。このプロセスの間、トランザクションは決済フェーズにあると言われる。この決済フェーズ中に、取引を実行するために必要な様々なアクションを実行するために必要な個別の基礎に基づいて、個々のＣＥＥＣを無効にし、作成し、変更することができる。たとえば、売却側コンピューティング・リソース・コホートに関連するＣＥＥＣコホートにおいてＣＥＥＣを無効にすることができ、新しいＣＥＥＣを生成し、買取側コンピューティング・リソース・コホートに関連するＣＥＥＣコホートに関連付けることができる。他の例として、ＣＥＥＣとＣＥＥＣコホートとの関連付けは、異なるＣＥＥＣコホートを指すようにＣＥＥＣで変更することができ、すなわち、売却側コンピューティング・リソース・コホートに関連する元のＣＥＥＣコホートのＩＤが買取側コンピューティング・リソース・コホートに関連するＣＥＥＣコホートを指すＩＤで指定変更されるように、ＣＥＥＣが変更される。
【０１６８】
トランザクション指定に基づいて取引を行う前に、取引のコスト対価値（コスト／価値）を決定し、実際にその取引を実行すべきかどうかならびに進行中の他の取引に対してそれを優先する方法について判断するための基礎として使用することができる。コスト／価値は、トランザクション指定に指定されたコスト属性に従って決定することができる。すなわち、トランザクション指定は、買取側と売却側の両方について、取引のコスト対価値がその取引を実行しなければならないようなものであるかどうかを判断する際に関心のあるコスト属性を指定することができる。これらのコストおよび価値は貨幣単位として指定する必要はないが、買取側と売却側との比較に適した任意の単位にすることができる。取引の価値がしきい金額だけコストを上回り、そのしきい値が所定のものであるかまたはトランザクション指定に指定できる場合、その取引は行うことが許可されるはずであり、そうでなければ、取引は取り消されるはずである。
【０１６９】
実際のコスト計算は、取引される予定のＣＥＥＣに基づいて作業負荷を実行するために売却側で使用されたコンピューティング・リソースおよびサポート・インフラストラクチャ、ならびに、ＣＥＥＣまたは置き換えＣＥＥＣに基づいてこのような作業負荷を実行するために買取側で使用する必要がある予想コンピューティング・リソースについて、買取側および売却側に関するコンピューティング・リソース使用状況メトリック情報に基づいて実行することができる。売却側コスト情報はデータベース・システム３３０から入手することができ、買取側に関するコスト情報は、データベース・システム３３０からの構成情報と、買取側に関する構成情報およびＣＥＥＣに関連する作業負荷の測定使用状況に基づいて、どのようなコストが買取側コンピューティング・リソース・コホート上に発生するかを予測する予測メカニズムからの構成情報に基づくものにすることができる。これらの動作は、たとえば、トランザクション・ビルダ３１２によって提供されたトランザクション指定に基づいてトランクションを開始することを決定する際に、ＣＥＥＣマーケット・メーカ・サービス３２２のロジック内で実行することができる。
【０１７０】
取引を評価するために使用される特定の原価計算フレームワークは、多種多様な形を取ることができるが、一般に、固定資産コスト、インフラストラクチャ・コスト、ハードウェア・リソース割り振りコスト、およびソフトウェア・インスタンス・コストを考慮に入れることになる。固定資産コストは、ホストとして処理されるソフトウェア・インスタンスの数がどれほど多いか少ないかにかかわらず、ハードウェア・プラットフォームをソフトウェア・インスタンスに提供するためのコストである。すなわち、コストをこの変数にカプセル化しなければならないかどうかを判断するためのテストは、ソフトウェア・インスタンスにかかわらず、それが分担しなければならない程度である。ハードウェア・リソース割り振りコストは、そのサイズ（したがって、パーセンテージ単位のハードウェアの使用率）に基づいて所与のソフトウェア・インスタンスについて請求しなければならないハードウェア・コストのパーセンテージである。ソフトウェア・インスタンス・コストは、特定のソフトウェア・インスタンスのコストである。多くのより古いシステムから、より新しくより高密度のシステム上に移行する場合、必要なフロア面積の量、消費するワット数の量、必要な冷房量の点で容易に計算可能な違いが存在する。既存の買取側に移行する場合、この違いはさらに大きくなる。
【０１７１】
前述の通り、トランザクションが決済フェーズに到達したときに、そのトランザクションに基づいて取引を実行するために互いに関連付けられている特定の当事者（買取側および売却側）がその義務を果たすことができない、たとえば、トランザクションの初期設定で使用可能であったリソースがその時点で使用可能ではないことが該当する可能性がある。このような場合、組織／企業は全体として予約コンピューティング・リソースを維持することができ、これは１つまたは複数のコンピューティング・リソース・コホートに編成することができ、完了すべき決済を実行するために使用することができる。しかし、これらの予約コンピューティング・リソースは、必要があれば将来のトランザクションの決済を支援するために使用できるように、時間の経過につれて再取得する必要がある。したがって、ＣＥＥＣマーケット・メーカ・サービス３２２は、これらの予約コンピューティング・リソースから買取側コンピューティング・リソース・コホートへＣＥＥＣおよび作業負荷を移行するためのスケジュールを生成することができ、このスケジュールは、予約コンピューティング・リソースまたは少なくともその一部分がＣＥＥＣマーケット内でＣＥＥＣまたはＣＥＥＣの一部分の売却側になりたいという要望を示す時間フレームを提供する。ＣＥＥＣを促進するために予約コンピューティング・リソースを使用した時間が増加するにつれてより頻繁に売却が行われるように、このスケジュールは時間が経過するにつれて加速することができる。
【０１７２】
さらに、ＣＥＥＣマーケット・メーカ・サービス３２２の予約は、ストレージなど、買取側が制約を受けていると気付く可能性のある要素の利益となるように均衡化することができる。このような場合、トランザクションはそのストレージを別々に分割して、予約リソースを信用取引し、トランザクションの残りは通常通りに進展する。
【０１７３】
したがって、ＣＥＥＣベースのコンピューティング・リソース管理システム３００の予約コンピューティング・リソースにより、トランザクションの当事者は、相手方が自分の義務を果たし損なった場合でも完全なものになることができる。これは、ＣＥＥＣマーケット・メーカ・サービス３２２が、接続を行う中立側としてのみ機能するのではなく、その代わりに、「企業の意思」の表明になり、企業の事業目標が達成されることを確認するための企業の資力を備えていることを認識することが重要であるもう１つのケースである。
【０１７４】
図１０〜図１３は、例示的な一実施形態によりＣＥＥＣマーケット・メーカ・ベースのシナリオの一例に関するトランザクションの様々なフェーズを示す図の例である。描写されている例では、２次使用デスクトップ、すなわち、契約当事者のための１次コンピューティング・リソースではないデスクトップから、仮想化クラスタである１つまたは複数の共用サーバ・コンピューティング・デバイス上の仮想計算機などに、ＣＥＥＣを移動するためのトランザクション指定１０１４が生成される。すなわち、トランザクション指定１０１４は、ＣＥＥＣおよびその関連作業負荷を仮想化環境内で物理コンピューティング・デバイスから仮想コンピューティング・デバイスに移動するために使用される。トランザクション指定１０１４は、予め定義され、トランザクション・ビルダ１０１２に関連してすでに保管されている可能性があるか、またはトランザクション・ビルダによって提供されるユーザ・インターフェースによるスクラッチおよび許可ユーザから受け取ったユーザ入力１０１０から生成することができる。トランザクション指定が予め定義される場合、ユーザ入力１０１０は、トランザクション・ビルダ１０１２によって提供されるユーザ・インターフェース内のリストを介するなど、トランザクション・ビルダ１０１２に関連するトランザクション指定のストアから定義済みのトランザクション指定を選択することになる可能性がある。売却側の数が一度に移行を処理する能力を超えている場合、既存のトランザクション・テンプレートにより、企業は何度も実行しなければならないトランザクションを容易に再現することができる。
【０１７５】
トランザクション指定１０１４の選択または作成は、トランザクションの作成フェーズ中にトランザクション・ビルダ１０１２を使用して実行される。加えて、トランザクション指定１０１４はＣＥＥＣマーケット・メーカ・サービス１０１６に提供され、そのＣＥＥＣマーケット・メーカ・サービス１０１６はそのトランザクション指定から１つまたは複数の取引インスタンス１０１８を生成する。取引インスタンス１０１８は、少なくとも１つの売却側と少なくとも１つの買取側との間で取引を実行するために使用されるトランザクション指定のインスタンスであり、売却側および買取側はコンピューティング・リソース・コホートである。描写されている例では、トランザクション指定１０１４は、複数のコンピューティング・リソースからなる特定の仮想化クラスタ上の５０台の仮想計算機（ＶＭ）に関するＣＥＥＣのために２次ワークステーションとして使用されている５０台の特定のデスクトップに関するＣＥＥＣを取引するための取引インスタンス１０１８を作成するためにＣＥＥＣマーケット・メーカ・サービス１０１６によって使用される。この取引インスタンス１０１８は、売却側に関するＣＥＥＣ指定１０２２に対応するＣＥＥＣインスタンスなどのＣＥＥＣおよび取引インスタンスの基準を満たす買取側に関するＣＥＥＣ指定１０３２に対応するＣＥＥＣインスタンスなどのＣＥＥＣを見つけるためにＣＥＥＣマーケット・メーカ・サービス１０１６によって使用される。
【０１７６】
図１０〜図１３には単一の売却側ＣＥＥＣ指定１０２２および単一の買取側ＣＥＥＣ指定１０３２のみが示されているが、実際には、これらのＣＥＥＣ指定１０２２、１０３２から生成された複数の買取側および売却側ＣＥＥＣ指定あるいはＣＥＥＣインスタンスまたはその両方を使用して、取引インスタンス１０１８およびトランザクションを全体として満足できることを認識されたい。たとえば、描写されている例では、それぞれのデスクトップに１件ずつ、ＣＥＥＣ指定１０２２に対応する５０件の売却側ＣＥＥＣインスタンスを使用することができ、５０件の売却側ＣＥＥＣインスタンスのすべてを買い取る買取側仮想化クラスタを表すためにＣＥＥＣ指定１０３２に対応する１件の買取側ＣＥＥＣインスタンスを使用することができる。
【０１７７】
図１０に示されているトランザクションの作成に続いて、トランザクションは図１１に示されている組み立てフェーズに移行する。図示の通り、組み立てフェーズでは、それぞれトランザクションの売却側１０２０および買取側１０３０に関連する特定のＣＥＥＣインスタンス１０２４および１０３４が識別される。この識別は、たとえば、トランザクション指定１０１４および取引インスタンス１０１８の売却側要件の少なくとも一部分を満足する売却側１０２０のＣＥＥＣインスタンス１０２４を識別することにより、トランザクション指定１０１４および取引インスタンス１０１８に基づいて、ＣＥＥＣマーケット・メーカ・サービス１０１６によって実行することができる。その上、この識別は、トランザクション指定１０１４および取引インスタンス１０１８の買取側要件の少なくとも一部分を満足する買取側１０３０のＣＥＥＣインスタンス１０３４の識別を含むことができる。これらのＣＥＥＣインスタンス１０２４および１０３４は、それ自体が関連のインフラストラクチャおよびサポート（たとえば、人間サポート）リソース１０２７、１０３７を有する、特定のソフトウェア・リソース１０２５、１０３５ならびにハードウェア・リソース１０２６、１０３６に関連付けられる。
【０１７８】
トランザクションのこのフェーズでは、実際の売却側コホートおよび買取側コホートは、「要請済み（solicited）」であったと見なされるだけであり、候補売却側および買取側に過ぎない。取引インスタンス１０１８の受諾または拒否を知らせるまで、売却側コホートおよび買取側コホートが実際に取引に携わることになるという要件または予想はまったくない。売却側／買取側が取引インスタンス１０１８を受諾し、取引インスタンス１０１８のそれぞれの部分を決済できると判断された場合、図１２に示されているように、確認済み（confirmed）になる。取引インスタンス１０１８の拒否を知らせた場合、取引インスタンスを満足するための候補として除去される。したがって、取引の組み立てフェーズでは、トランザクション１０１４の１つまたは複数の取引インスタンス１０１８を満足するための売却側および買取側が組み立てられる。トランザクション要件を満足するために十分な売却側および買取側が存在するかどうかについて判断を行うことができ、存在しない場合、十分な数の売却側および買取側が識別され、取引インスタンス（複数も可）１０１８を受諾するまでまたはタイムアウト条件が発生した場合に、組み立てフェーズを続行することができる。タイムアウト条件が発生した場合、そのトランザクションを正常に完了できなかったことを示すエラー条件を返すことができる。たとえば、トランザクション指定を変更すること、売却側および買取側を手動で選択することなど、適切な是正処置を行えるように、このエラー条件は、トランザクション・ビルダ１０１２などを介して、適切な許可ユーザに通知することができる。
【０１７９】
トランザクションの組み立てフェーズ中に十分な売却側および買取側が組み立てられると、トランザクションは図１２に示されているように開始フェーズに移行する。開始フェーズ中に、取引インスタンス（複数も可）１０１８を実行するために必要な個別作業が１０６０で開始される。開始される（しかも、完了したときにトランザクション決済を構成することになる）作業は、たとえば、５０台のＶＭを提供するための仮想化インフラストラクチャを構成すること、不必要なソフトウェアをアンインストールし、不必要なファイルを除去してそのイメージを可能な限り小さくすることにより、移行のために売却側を準備すること、売却側のスナップショットを撮り、それを仮想化クラスタ内で再確立すること、適切なユーザへのアクセスを許可すること、売却側ハードウェアからすべてのＩＰを除去すること、売却側ハードウェアをプラグ／ラックから外すこと、および売却側ハードウェアをそのフロアから除去することを含むことができる。１０６０で個別作業が実行されると、図１３に示されているように、トランザクションの決済フェーズが実行される。決済フェーズ中に、売却側１０２０のＣＥＥＣインスタンス１０２４が買取側１０３０に取引されるか、または買取側１０３０上の新しいＣＥＥＣ１０３４と引き替えにそれ以外の方法で廃棄され、たとえば、それぞれが単一のデスクトップ・コンピュータに関する５０件のＣＥＥＣインスタンスが取引または廃棄され、仮想化クラスタ上の５０台の仮想計算機を表す単一の新しいＣＥＥＣインスタンスで置き換えられる。その結果、決済フェーズの一部として、取引／廃棄されたＣＥＥＣインスタンス（複数も可）１０２４に関連付けられた売却側１０２０のソフトウェア・リソース・ライセンス受給権１０２５を買取側１０３０に移行することができる。これらのソフトウェア・リソース・ライセンス受給権１０２５は、ＯＳインスタンス、すなわち、資産または個人に関連付けることができ、これは買取側コホートで正しく再関連付けすることが必要になる。買取側は「ライセンス能力」を有することを期待されないが、マーケット・メーカは、売却側が移行するときに追加のライセンスが必要である場合にライセンスの流動性を有するものと推定される（これは、移転できない「事前ロード」としてソフトウェアが資産にライセンスされる場合に該当する可能性がある）。典型的に、売却側１０２０のハードウェア・リソース１０２６がもはやＣＥＥＣインスタンス１０２４の契約当事者によって使用されておらず、そのリソース（電力、冷房など）消費の停止がトランザクションの目標の一部であるので、そのハードウェア・リソース１０２６を廃棄しなければならない要件が存在する。ソフトウェア・リソース１０２５およびハードウェア・リソース１０２６は移行され廃棄されるので、インフラストラクチャおよびサポート・リソース１０２７の必要性が取り除かれ、実現された節約がトランザクションに関連付けられる。
【０１８０】
決済フェーズの一部として、その取引の結果を評価するために取引結果を生成することができる。このような取引結果は、取引が完了した後の新しいコンピューティング・リソース割り振りと比較して、以前のコンピューティング・リソース割り振りに関連するコストに関する表示を提供することができる。このようなコスト比較は、消費電力コスト、冷房コスト、平方フィート数コスト、減価償却コスト、サポート・コスト、ライセンス・コスト、その他のコスト／利益を含む、様々な原価計算要因について実行することができる。描写されている例では、これらのコストはいずれも、単純に５０の契約当事者の受給権をサポートするために必要なハードウェア・リソースの数が少なくなったことにより、５０台のデスクトップ・コンピュータを有する場合とは対照的に、仮想化クラスタの場合に著しく低くなっていなければならない。このようなコスト節約は、たとえば、ユーザ・インターフェースなどを介してコストの比較を提供することにより、トランザクション・ビルダ１０１２などを介して、許可ユーザに報告することができる。
【０１８１】
トランザクションの決済フェーズの結果として、トランザクションが完了し、その完了をトランザクション・ビルダ１０１２に知らせることができるので、その結果、適切な通知を生成して許可ユーザに出力することができる。この通知は、前に述べたようにコスト比較結果を含むことができる。次に、新しいＣＥＥＣ取り決めに従って作業負荷を管理し経路指定し実行することができ、ハードウェア・リソースを廃棄するための適切なチケットを生成することができ、サポート職員およびインフラストラクチャ・リソースを再割り当てすることなどができる。たとえば、５０台のデスクトップ・コンピュータ上で前に実行されたと思われる作業負荷は、この時点で、仮想化クラスタ上の５０件の仮想計算機インスタンスを使用して実行され、契約当事者にはそれぞれ、５０件の仮想計算機インスタンスのうちのそれぞれ１件に対するＣＥＥＣ１０３４に基づく受給権が与えられ、それぞれの契約当事者にはＣＥＥＣインスタンス１０３４の自分の分に関連する仮想計算機インスタンスに対する同じ程度の受給権が与えられる。
【０１８２】
図１４〜図１６は、例示的な一実施形態によるトランザクション指定の図の例を描写している。トランザクション指定１１００は、たとえば、トランザクション・ビルダ３１２を介して許可ユーザによって作成することができる。トランザクション・ビルダ３１２は、企業の目標およびトランザクション・タイプの一般的特徴を指定する、ユーザからの入力に基づくトランザクション指定を構築する。しかし、トランザクション指定が作成されると、トランザクション指定に適合する任意の数のトランザクション・インスタンスをトランザクション・ビルダ３１２によって自動的に作成することができる。トランザクション指定は、ＣＥＥＣマーケット・メーカ・サービス３２２に提供して買取側および売却側を識別する際に使用し、取引のコストを決定し、これらのコストに基づいてＣＥＥＣマーケット内で取引を実行すべきかどうかを判断し、その他のサービス、たとえば、ＣＥＥＣベースの予約サービス３２８、データベース・システム３３０などの援助によって取引を実行することができる。
【０１８３】
図１４〜図１６に示されているように、描写されている例では、１つのトランザクションについて５つのセクションが存在する。トランザクション指定の第１のセクション１１１０は、節約目標、すなわち、トランザクションの作成者が節約の点で何を達成しようとしているかを表している。第２のセクション１１２０は、トランザクションの売却側フィルタ、すなわち、トランザクションの事業目標を満足するために適切な売却側を選択するために潜在的な売却側に適用しなければならないフィルタを表している。これらの売却側フィルタとしては、アーキテクチャ、地理、および事業単位の属性、十分な数の売却側が選択された時期を示す目標値などを含むことができる。
【０１８４】
トランザクション指定の第３のセクション１１３０は、売却側コスト属性を表している。売却側コスト属性は、売却側で現在のＣＥＥＣに基づいて作業負荷を実行するコストを表す属性である。これらは必ずしも金銭的コストではないが、たとえば、コンピューティング・リソース使用または予約の金額で指定することができる。一例として、現在のＣＥＥＣに基づく作業負荷は、たとえば、５ギガのＲＡＭを「要する」可能性がある。任意のコスト・メトリクスがＣＥＥＣマーケットの売却側と買取側とのコスト／価値の比較を容易にすることができる限り、例示的な諸実施形態の精神および範囲を逸脱せずに、このようなコスト・メトリクスを使用することができる。例示的な諸実施形態のメカニズムは、すべてのコストを貨幣単位に変換する能力を有するが、これは例示的な諸実施形態が機能するために必須のものではない。
【０１８５】
トランザクション指定の第４のセクション１１４０は、買取側フィルタを表している。これは、トランザクションの事業目標を満足するために適切な売却側を選択するために潜在的な買取側のセットに適用しなければならないフィルタを表している。これらのフィルタとしては、アーキテクチャ、地理、および事業単位の属性、ならびにトランザクションの事業目標を満足するために十分な買取側が選択された時期を示す目標値を含むことができる。
【０１８６】
トランザクション指定の第５のセクション１１５０は、買取側コストを表している。買取側コストは、買取側コンピューティング・リソース・コホート（複数も可）上で既存のＣＥＥＣまたは新しいＣＥＥＣに基づいて売却側の作業負荷を実行するコストである。この場合も、これらは必ずしも金銭的コストではないが、コンピューティング・リソース使用／予約について指定することができる。これらのコストは金額に変換することができるが、これは例示的な諸実施形態の動作にとって必要なものではない。
【０１８７】
トランザクション指定は、組織／企業の全体的な目的を達成するために売却側から買取側にＣＥＥＣを移行できるように、ＣＥＥＣマーケットにおいて買取側と売却側との間の取引を実行するためのコンテキストおよびガイダンスを提供する。したがって、トランザクション指定は、ＣＥＥＣマーケットを事業目的の達成に向けさせるために非中立ＣＥＥＣマーケット・メーカによる市場要因の導入をさらに表している。実行される実際の取引は、取引されている品物としてＣＥＥＣに対して行われる。すなわち、売却側はＣＥＥＣまたはＣＥＥＣの一部分の売却側であり、買取側はＣＥＥＣまたはＣＥＥＣの一部分の買取側である。
【０１８８】
図３のＣＥＥＣマーケット・メーカ・メカニズム３２２は、効率の低い手段から効率の高い手段に、たとえば、デスクトップから仮想サーバに、古い技術のラップトップ・コンピュータからより新しいサーバ・ベースのサービスになど、ＣＥＥＣおよびそれに関連するコンピューティング作業負荷の移動を最大限にして、トランザクション指定に指定されたように組織／企業の所定の目的に従って組織／企業の最適化を達成するために使用することができる。すなわち、組織は、その不動産の使い方を最適化し、その電力の使い方を最適化し、特定の地理においてその管理リソースの使い方を最適化することなどを試みる可能性がある。
【０１８９】
ＣＥＥＣおよびそれに関連する作業負荷の取引を可能にするために、契約文書、すなわち、ＣＥＥＣを作成することにより、所与のＣＥＥＣが単一のシステムおよびその使用の全体を表す必要がないように同じＣＥＥＣを分解し集約するためのメカニズムも提供される。簡単に言うと、例示的な実施形態のＣＥＥＣおよびＣＥＥＣマーケット・メーカ・サービス３２２により、受給権およびその作業負荷は、システムＡからシステムＢに全体として移行する必要はなく、したがって、その移行を実行するためにシステムＡおよびシステムＢの所有者間の合意を得る必要もない。それとは反対に、例示的な諸実施形態のＣＥＥＣメカニズムにより、システムＡのＣＥＥＣおよびそれに関連する受給権および対応する作業負荷を必要な数の断片に分割し、契約全体（ＣＥＥＣ）より容易に個々の断片を売却できる取引を見つけることができる。すなわち、作業負荷の代わりに、ＣＥＥＣが取引の基礎である場合、いずれも取引単位（ＣＥＥＣ）の移動に対するバリアを除去する目的で、これらの取引単位（ＣＥＥＣ）のそれぞれを分離して集約し、分解し、結束し、再結束することができる環境が作成される。作業負荷は、作業負荷の破損の可能性を持ち込まずに、集約し、分解し、結束し、再結束することができない。
【０１９０】
したがって、たとえば、例示的な諸実施形態のＣＥＥＣおよびＣＥＥＣマーケット・メーカ・サービス３２２により、売却側が売却したいと希望するものをすべて買い取りたいと希望する単一の相手方あるいは買取側が買い取りたいと希望するものをすべて売却したいと希望する売却側を見つける必要性を取り除いて、多種多様な当事者間で取引を行えるように、３者以上の相手方を備えることができる。たとえば、相手方（買取側または売却側）は、ＣＥＥＣの１つの要素だけ、たとえば、買取側がストレージ契約の買取側である（すなわち、使用可能な記憶容量を有する）のでストレージ条件だけ、あるいは、買取側が管理サポート・リソース容量を有するがハードウェア容量をまったく持たないのでＣＥＥＣの管理サポート条件だけを切り取ることができる。したがって、ＣＥＥＣを複数の構成部分に分解できることにより、買取側および売却側のプールが増加するので、ＣＥＥＣマーケット・メーカ・サービス３２２はＣＥＥＣの買取側と売却側を対にできる可能性が高くなる。その結果、トランザクション指定に指定された事業目標は、ＣＥＥＣマーケット・メーカ・サービス３２２を介して達成される可能性が高くなる。
【０１９１】
その上、ＣＥＥＣマーケット内の「買取側」および「売却側」はコンピューティング・リソース・コホートであって、必ずしも単一のシステムではないことを認識されたい。買取側は、追加のＣＥＥＣまたはＣＥＥＣの一部分を取得することができるコンピューティング・リソース・コホートである。売却側は、ＣＥＥＣまたはＣＥＥＣの一部分を買取側に明け渡すことができるコンピューティング・リソース・コホートである。したがって、ＣＥＥＣマーケット・メーキングの本質的な機能は、主に単一の売却側と単一の買取側を招集することではないが、これは、例示的な諸実施形態のメカニズムにより可能であり、たとえば、１０００単位の単一の売却側と、１０００単位の単一の買取側が可能である。それとは反対に、ＣＥＥＣマーケットは、たとえば、結合されたときに１０００単位を売却し、１０００単位を買い取りたいと希望する、買取側のグループまたはコホートと、売却側のグループまたはコホートを見つける。重要な点は、両者が互いに正確に同じ金額を買い取る／売却する義務を負っている対の当事者間のトランザクションを有することができるマーケットでは、トランザクションの数は劇的に低減されることになり、これをシステム最適化に適用すると、システムを最適化する機会が削減されることである。したがって、例示的な諸実施形態のメカニズムは、取引の単位、すなわち、ＣＥＥＣの分解を可能にし、ＣＥＥＣマーケットを介してより多数のトランザクションを正常に完了することができ、したがって、組織／企業内のコンピューティング・リソースについて最適化されより効率的な割り振りおよび使用を達成する機会および可能性を増すことができる。
【０１９２】
例示的な諸実施形態のＣＥＥＣマーケット・メーカ・サービス３２２では、トランザクション指定を適切に定義し、ＣＥＥＣベースのメカニズムを使用して買取側、売却側を決定し、１つまたは複数の買取側と１つまたは複数の売却側を対にすることにより、いくつかの異なるシナリオでいくつかの異なるタイプの取引が可能になる。たとえば、例示的な諸実施形態のメカニズムにより、あるタイプの取引は、一方のコンピューティング・リソース・コホートが「間近の」必要なコンピューティング・リソースの一部分を有し、もう一方のコンピューティング・リソース・コホートが組織または企業によって取得すべきコンピューティング・リソースを含むことに基づいて、十分使用されていないかまたは時代遅れの１つのコンピューティング・リソース・コホートから２つの異なるコンピューティング・リソース・コホートにＣＥＥＣを取引することになる可能性がある。このような状況では、売却されるＣＥＥＣの条件は、２つのコンピューティング・リソース・コホート間で分割することができ、たとえば、ＣＥＥＣの記憶容量条件は、第１のコンピューティング・リソース・コホート内で使用可能な記憶容量と、第２のコンピューティング・リソース・コホート内で購入したハードウェア上で使用可能になる記憶容量とに分割することができる。
【０１９３】
もう１つのシナリオでは、コンピューティング・リソースの排他的使用のためのＣＥＥＣは、そのコンピューティング・リソースが売却側コンピューティング・リソース・コホート内で十分に使用されないときに無効にすることができる。この無効にしたＣＥＥＣは、新しいＣＥＥＣに契約上列挙された条件に基づいて、使用されないコンピューティング・リソースが他のものと共用されるという新しいＣＥＥＣのために取引することができる。この例では、作業負荷は移動せず、むしろ、その既存の容量を共用し、このように実行する際に有効なＣＥＥＣを再確立する。
【０１９４】
さらに他のシナリオでは、ＣＥＥＣは、物理的なハードウェア・コンピューティング・リソースから仮想化コンピューティング・リソースに、たとえば、デスクトップから仮想計算機（ＶＭ）に移行することができる。物理デバイスから仮想デバイスに、たとえば、デスクトップからＶＭに移行する場合、ユーザの受給権および作業負荷は、平凡な大容量ローカル・ストレージ・パラダイムから、ストレージが仮想化され、ギガバイトあたりの価格がより高くなっているストレージ・パラダイムに移行する。物理デバイスの領域で大量の安価で妨げのないローカル・ストレージにより、ユーザは、そのローカル・ストレージを完全に使用するために余分なコストが発生しないと正しく想定するので、このローカル・ストレージをいっぱいにする傾向がある。これは、それぞれの余分なギガバイトが著しくより多くのコストを要するストレージに移動するときに、移行問題を提示することになる。
【０１９５】
例示的な諸実施形態は、ＣＥＥＣのストレージ・コンポーネントを分割し、そのストレージ・コンポーネントを「時限爆弾（time-bombing）」にして、「提供されたストレージ」がＣＥＥＣの移行後に毎月一定のパーセンテージずつ縮小するようにすることにより、この問題に対する解決策を提供する。したがって、たとえば、移行時に、割り振りが５０ギガに達するまでこの割り振りが毎月２５％ずつ削減されるという明示的なＣＥＥＣベースの合意により、ＶＭには２００ギガバイトのストレージが割り振られる。したがって、ユーザは、契約上の義務に従ってシステムから不必要なソフトウェアおよびデータ（重複データ、冗長バックアップ、バックレベル・ソフトウェア、もはや使用されていないソフトウェアなど）を削除する義務を負う。ユーザがこのような削減を行えることを把握して、しかも、１５０ギガの不必要なデータを識別して削除することはある程度の時間を要することを理解した上で、このようなＣＥＥＣを締結することになるであろう。
【０１９６】
図１７は、例示的な一実施形態によりＣＥＥＣマーケット・トランザクションを実行するための動作例を概説する流れ図である。図１７に概説された動作は、たとえば、主に図３のＣＥＥＣマーケット・メーカ・サービス３２２とともに、それによりトランザクション指定を生成し、ＣＥＥＣマーケット・メーカ・サービス３２２に提示することができるインターフェースを提供するトランザクション・ビルダ３１２を使用して、実行することができる。
【０１９７】
図１７に示されているように、この動作は、あるトランザクションの１つまたは複数の取引を実行する際に使用するために、トランザクション指定を定義するユーザ入力の受け取りまたは既存のトランザクション指定の選択の受け取りから始まる（ステップ１２１０）。トランザクション指定に基づいて、トランザクション指定のインスタンスを作成する（ステップ１２２０）。トランザクション指定に指定された基準に従って、売却側および買取側のコンピューティング・リソース・コホートを選択する（ステップ１２３０）。
【０１９８】
選択した売却側および買取側の両方がトランザクションの受諾または拒否を知らせる（ステップ１２４０）。受諾を知らせる場合、選択した売却側および買取側は「候補」買取側および売却側であり、拒否を知らせる場合、選択した潜在的な売却側および買取側から除去される。トランザクションの目標を満たすために十分な売却側および買取側が存在するかどうかについて判断を行う（ステップ１２５０）。存在しない場合、この動作はステップ１２３０に戻り、十分な売却側および買取側が選択され、候補になることに同意するまで、追加の選択を行えるようにする。
【０１９９】
トランザクションの目標を満たすために十分な売却側および買取側が存在することに応答して、トランザクションの開始フェーズを実行する（ステップ１２６０）。トランザクションのコスト／価値がトランザクションを完了するのに望ましいことを示しているかどうかについて判断を行う（ステップ１２７０）。示していない場合、トランザクションを打ち切り（ステップ１２８０）、この動作はエラーで終了する。示している場合、トランザクションの事業目的を達成するために買取側と売却側との間でＣＥＥＣの取引を実行するために必要な様々な動作を実行する（ステップ１２９０）。トランザクションを完了するための取引のいずれかが正常に決済できなかったかどうかについて判断を行う（ステップ１３００）。決済できた場合、予約コンピューティング・リソースを使用して、これらの取引の正常な決済を保証することができる（ステップ１３１０）。その後、トランザクションの完了をＣＥＥＣマーケット・メーカ・サービスに知らせ（ステップ１３２０）、この動作は終了する。
【０２００】
したがって、例示的な諸実施形態のＣＥＥＣマーケット・メーカ・サービスにより、少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースを含むデータ処理システムにおいて、コンピューティング環境受給権契約（ＣＥＥＣ）に対してコンピューティング・リソースの使用をモニターするためのメカニズムが提供される。これらのメカニズムは、少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のＣＥＥＣデータ構造を確立し、それぞれのＣＥＥＣデータ構造が契約当事者とデータ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義するように動作することができる。ＣＥＥＣの条件は、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定する。これらのメカニズムは、少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のＣＥＥＣデータ構造をコンピューティング・リソース・コホートに関連付け、そのコンピューティング・リソース・コホートが同様の構成を有するコンピューティング・リソースの集合になるようにさらに動作することができる。
【０２０１】
その上、これらのメカニズムは、少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のＣＥＥＣデータ構造内の１つのＣＥＥＣデータ構造の売却側を識別し、その売却側がそのＣＥＥＣデータ構造に指定された条件に従って使用されていないコンピューティング・リソースであるように動作することできる。さらに、これらのメカニズムは、少なくとも１つのコンピューティング・デバイスにより、１つまたは複数のＣＥＥＣデータ構造内の１つのＣＥＥＣデータ構造の買取側を識別し、その買取側がそのＣＥＥＣデータ構造に指定された条件を満足できるコンピューティング・リソースであるように動作することできる。
【０２０２】
また、これらのメカニズムは、ＣＥＥＣデータ構造に指定された条件に基づいて、売却側から買取側にＣＥＥＣデータ構造を移行すべきかどうかを判断するように動作することもできる。この判断はさらに、たとえば、トランザクション指定に指定された事業目標およびその他の基準に基づいて行うことができる。売却側から買取側にＣＥＥＣデータ構造を移行すべきであるという判断に応答して、ＣＥＥＣデータ構造を売却側から買取側に移行することができる。この移行は、売却側に関連するＣＥＥＣデータ構造の無効化、買取側に関連する置き換えＣＥＥＣデータ構造の作成、それがもはや売却側に関連付けられず、その時点で買取側に関連付けられるようなＣＥＥＣデータ構造の変更、たとえば、コホート関連付けのＩＤを更新することを必要とする可能性がある。
【０２０３】
したがって、上記のメカニズムでは、ＣＥＥＣマーケット・メーカ・サービスは、移行されるＣＥＥＣの条件およびＣＥＥＣのこのような移行によって満たす必要がある事業目標を定義するトランザクション指定の条件に従って買取側および売却側を選択するように動作する。これらのメカニズムは、買取側がＣＥＥＣマーケット内で買取側になることに対する関心を表明したか、売却側がＣＥＥＣマーケット内で売却側になることに対する関心を表明したか、買取側または売却側になることに対する関心の表明とは無関係に買取側と売却側が選択される状況で動作することができる。その上、これらのメカニズムは、単一の買取側と複数の売却側、単一の売却側と複数の買取側、または複数の買取側と複数の売却側を対にするように動作することができる。このような１対多、多対１、または多対多のトランザクションを容易にするために、ＣＥＥＣを分解することができ、買取側は１つのＣＥＥＣの個別部分を買い取ることができ、売却側はＣＥＥＣの各部分を異なる買取側に売却することができる。
【０２０４】
その他の実現例では、例示的な諸実施形態により、コンピューティング・リソース・コホートは買取側および売却側としてＣＥＥＣマーケット・メーカ・サービスに登録し、ＣＥＥＣマーケット・メーカ・サービスによって有効な売却側／買取側を選択できる基準を指定することができる。このような基準は、排他的に、または、たとえば、トランザクション指定に指定された条件と組み合わせてのいずれかで、使用することができる。その場合、ＣＥＥＣマーケット・メーカ・サービスは、買取側／売却側としての登録時に指定された条件ならびにトランザクション指定の条件に従って、１つまたは複数の買取側と１つまたは複数の売却側を対にするように動作する。たとえば、ＣＥＥＣに関連するコンピューティング・リソース・コホートのコンピューティング・リソースが契約当事者によりＣＥＥＣの条件に従って使用されていないことをＣＥＥＣ遵守動作が示したことに応答して、登録通知をＣＥＥＣマーケット・メーカ・サービス３２２に送信して、コンピューティング・リソース・コホートをＣＥＥＣの売却側としてＣＥＥＣマーケットに追加することができ、買取側の選択ための条件を指定することができ、たとえば、買取側は、契約当事者について測定された実際の使用状況を満足するために十分なリソースおよびリソースのタイプを提供しなければならず、このような実際の使用状況測定値と一致する新しいＣＥＥＣを提供できなければならない。
【０２０５】
すなわち、例示的な諸実施形態は、少なくとも１つのコンピューティング・デバイスと複数のコンピューティング・リソースを含むデータ処理システムにおいて、コンピューティング環境受給権契約（ＣＥＥＣ）に対してコンピューティング・リソースの使用をモニターするためのメカニズムを提供することができる。これらのメカニズムは、１つまたは複数のＣＥＥＣデータ構造を確立し、それぞれのＣＥＥＣデータ構造が契約当事者とデータ処理システムのプロバイダとの間のビジネス・レベル協定の条件を定義することができる。ＣＥＥＣの条件は、指定の期間の間、指定のレベルおよびパターンの強度で、指定の目的のために、契約当事者によって使用される予定の、指定の構成を有するコンピューティング・リソースのセットを指定する。これらのメカニズムは、１つまたは複数のコンピューティング・リソースを提供するプロバイダ・システムから、ＣＥＥＣデータ構造の買取側になるよう要求する第１の要求を受け取り、第１の要求がＣＥＥＣデータ構造の売却側を選択するための第１の選択基準を含むようにさらに動作する。
【０２０６】
加えて、例示的な諸実施形態のメカニズムは、ＣＥＥＣデータ構造を所有する売却側システムから、ＣＥＥＣデータ構造の売却側になるよう要求する第２の要求を受け取るように動作することもできる。第２の要求は、ＣＥＥＣデータ構造の買取側を選択するための第２の選択基準を含むことができる。その場合、ＣＥＥＣマーケット・メーカ・サービスは、第１および第２の選択基準に基づいてプロバイダ・システムと売却側システムを対にすることができ、売却側システムからプロバイダ・システムにＣＥＥＣデータ構造を移行することができる。次に、ＣＥＥＣデータ構造に指定された条件に従って、プロバイダ・システム上で作業負荷を実行することができる。この移行は、元のＣＥＥＣデータ構造の無効化および同様のまたは異なる条件を有する新しいものとの置き換えを必要とする可能性があることを認識されたい。その上、ＣＥＥＣ全体を移行する必要があるのではなく、ＣＥＥＣデータ構造はＣＥＥＣの一部分のみを表すこともできる。
【０２０７】
したがって、例示的な諸実施形態のメカニズムにより、指定の事業目的のために、契約当事者による使用の必要なレベルおよびパターンを規定する契約メカニズム、すなわち、ＣＥＥＣにコンピューティング・リソースに対する契約当事者の受給権をカプセル化することにより、これらの受給権を管理するための機構が提供され、違反の結果はＣＥＥＣの無効化および同じかまたは異なるコンピューティング・リソースに関する新しいＣＥＥＣによる潜在的な置き換えになる。新しいＣＥＥＣは、元のＣＥＥＣが要求するレベルおよびパターンの使用ではなく、ユーザの実際の測定使用状況に対応するように調整することができる。
【０２０８】
例示的な諸実施形態は、ＣＥＥＣマーケットを使用してこのようなＣＥＥＣを移行するためのメカニズムをさらに提供し、組織または企業の事業目標を表す市場要因が導入される。作業負荷は経路指定され、契約当事者はこの時点で新しいかまたは移行されたＣＥＥＣに関連するコンピューティング・リソース・コホート（複数も可）に関連付けられるので、この移行の結果、移行されるＣＥＥＣに関連する作業負荷の移行が行われる。しかし、この場合も、例示的な諸実施形態のメカニズムは既知の作業負荷移行メカニズムとは著しく異なるものであることに注意されたい。
【０２０９】
たとえば、既知の作業負荷移行メカニズムは、あるシステムが作業負荷全体を１つの他のシステムに移行することを意味する、１対１の移行メカニズムである。例示的な諸実施形態のメカニズムを使用するＣＥＥＣの移行は、それぞれの部分を異なるターゲット・コンピューティング・リソースまたはコンピューティング・リソース・コホートに移行できるように、１つのＣＥＥＣを複数の構成部分に分割することを可能にする。その上、作業負荷移行メカニズムは、事業目的および使用法について無関心かつ客観的であり、すなわち、コンピューティング・リソースが指定の事業目的に使用されているかどうかを判断せず、作業負荷の移行が効率を増すことになるかどうかのみを判断する。作業負荷移行は、特に古いシステムに対して何かを行うために、移行するコンピューティング・リソースに対していかなる義務も負わせず、例示的な諸実施形態のメカニズムによる多くの場合では、ＣＥＥＣはより古いシステムを廃止する特定の義務を含み、実行されない場合にはＣＥＥＣを無効にし、したがって、その新しいホームでシステムを使用するユーザの権利を取り消すものである。
【０２１０】
前に述べたように、例示的な諸実施形態のメカニズムは、サービス品質保証制度、サービス品質協定など、他のタイプの作業負荷ベースの取り決めとも異なるものである。このような協定では、プロバイダが提供する義務を負っているサービス・レベルまたはサービス品質について契約当事者によって支払われている限り、プロバイダはサービスがどのように使用されているかまたはそのうちのどのくらいが使用されているかに関心がない。例示的な諸実施形態のＣＥＥＣベースのメカニズムにより、ＣＥＥＣは、契約当事者が、指定の事業目的に従って、ＣＥＥＣに指定されたレベルおよびパターンの使用に従って、関連付けられたコンピューティング・リソースを使用することを保証し、そうでなければ、ＣＥＥＣの無効化あるいは移行またはその両方が実行される。
【０２１１】
さらに、ＳＬＡまたはＱｏＳ協定のユーザは、サービスがどのように提供されるか、すなわち、どの特定のタイプのコンピューティング・リソースを使用してサービス・レベルまたはサービス品質を提供するかについて心配していない。しかし、例示的な諸実施形態のＣＥＥＣベースのメカニズムでは、ＣＥＥＣは、ＣＥＥＣに基づいて提供する予定のタイプのコンピューティング・リソースについて要件を指定することができ、ＣＥＥＣマーケット・メーカは、コンピューティング・リソースが最も効率的で可能な方法で提供されることを保証するために企業に代わってこのような条件を執行する。
【０２１２】
上記の通り、例示的な諸実施形態は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはハードウェア要素とソフトウェア要素の両方を含む実施形態の形を取ることができることを認識されたい。一実施形態例では、例示的な諸実施形態のメカニズムは、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むが、これらに限定されない、ソフトウェアまたはプログラム・コードで実現される。
【０２１３】
プログラム・コードの保管あるいは実行またはその両方に適したデータ処理システムは、システム・バスを介してメモリ・エレメントに直接または間接的に結合された少なくとも１つのプロセッサを含むことになる。メモリ・エレメントとしては、プログラム・コードの実際の実行中に使用されるローカル・メモリと、大容量記憶装置と、実行中に大容量記憶装置からコードを取り出さなければならない回数を削減するために少なくとも何らかのプログラム・コードの一時記憶域を提供するキャッシュ・メモリとを含むことができる。
【０２１４】
入出力またはＩ／Ｏ装置（キーボード、ディスプレイ、ポインティング・デバイスなどを含むがこれらに限定されない）は、直接あるいは介在する入出力コントローラを介して、システムに結合することができる。データ処理システムが介在する私設網または公衆網を介してその他のデータ処理システムあるいはリモート・プリンタまたはストレージ・デバイスに結合された状態になれるようにするために、ネットワーク・アダプタもシステムに結合することができる。モデム、ケーブル・モデム、およびイーサネット・カードは、現在使用可能なタイプのネットワーク・アダプタのうちのいくつかに過ぎない。
【０２１５】
本発明の説明は、例示および解説のために提示されたものであり、網羅するためまたは開示された形式に本発明を限定するためのものではない。多くの変更および変形は当業者にとって自明なものになる。この実施形態は、本発明の原理、実用的な適用例を最も良く説明するため、ならびにその他の当業者が企図された特定の用途に適した様々な変更を含む様々な実施形態について本発明を理解できるようにするために、選択され記載されたものである。
【図１】
2014525078.tif 000003
【図２】
2014525078.tif 000004
【図３】
2014525078.tif 000005
【図４】
2014525078.tif 000006
【図５】
2014525078.tif 000007
【図６】
2014525078.tif 000008
【図７】
2014525078.tif 000009
【図８】
2014525078.tif 000010
【図９】
2014525078.tif 000011
【図１０】
2014525078.tif 000012
【図１１】
2014525078.tif 000013
【図１２】
2014525078.tif 000014
【図１３】
2014525078.tif 000015
【図１４】
2014525078.tif 000016
【図１５】
2014525078.tif 000017
【図１６】
2014525078.tif 000018
【図１７】
2014525078.tif 000019
2014525078.tif 000020
2014525078.tif 000021
2014525078.tif 000022
2014525078.tif 000023
2014525078.tif 000024
2014525078.tif 000025
2014525078.tif 000026
2014525078.tif 000027
【国際調査報告】
2014525078.tif 000028