JP5578239B2 - ブレード、管理プログラム、および管理方法 - Google Patents

Description

この発明は、ライセンスを管理・運用するブレード、管理プログラム、および管理方法に関する。

近年、オフィスの省スペース化のために、ブレードを集積して電源供給や空調管理を行うことができるブレードサーバがオフィスで使用されている。ブレードサーバは、複数のブレードを着脱するための差し込み口が設けられた筐体にブレードを接続して構成される。

このブレード上で使用されるソフトウェアは、容易に複製・改造が可能であり、不正使用されることがある。そのため、ソフトウェアの供給元となるベンダは、ソフトウェア的な錠前をソフトウェアに組み込んで、ソフトウェアや当該ソフトウェアのオプション機能の不正使用を防止している。そして、ライセンスを結んだユーザに対してのみ、ソフトウェアの使用を許可するライセンスキーを供与している。

さらに、ベンダは、ソフトウェア（特に、高額なソフトウェア）に対して、ある決められたブレード１台のみがソフトウェアを固定的に使用するように、ブレードの固有情報にライセンスキーをロックすることがある（ノードロックライセンス）。ブレードの固有情報とは、例えば、ＭＡＣアドレス（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ ａｄｄｒｅｓｓ）やＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）である。

一方、ネットワーク上でソフトウェアを同時に使用可能なライセンスの数（以下、「使用可能数」という）をベンダが設定するライセンス方式がある。そして、ソフトウェアを同時に使用中のライセンスの数（以下、「使用数」という）が使用可能数の範囲内であれば、ユーザがソフトウェアを自由に使用できるようになっている（フローティングライセンス）。

このようなフローティングライセンスでは、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を介して複数のブレードと接続してネットワーク全体のライセンスキーの発行数を管理するライセンス管理ユニットが設けられる。そして、ライセンス管理ユニットがライセンスキーを発行し、その発行数を管理することで、使用数が使用可能数を超えないようにして、ソフトウェアの不正使用を防いでいる。また、ＬＡＮを介して、ブレード間でライセンスを移行することが可能となっている。

特開２００８−１０７８７９号公報 特開２００８−１５８６３９号公報 特開平５−３４６８５１号公報

しかしながら、上述したノードロックライセンスでは、ソフトウェアを使用する可能性のあるブレード全てにライセンスが必要となる。よって、普段運用しない待機系ブレードにもライセンスが必要となってしまう。また、ブレードの交換を行った場合にはブレード交換前後でブレードの固有情報が異なるため、交換前のブレードのライセンスは交換後のブレードでは使用できず、ライセンスの速やかな移行ができない。そのため、ライセンスの運用に支障をきたすという問題があった。

一方、上述したフローティングライセンスでは、ＬＡＮ経由でのライセンスの移動を行うため、ライセンスの移動中に意図的にＬＡＮからブレードを切り離すことでソフトウェアの不正使用がされてしまう可能性があるという問題があった。また、管理ユニットを不正改造し、例えば使用可能数や発行数を書き換えて、ソフトウェアの不正使用がされてしまう可能性があるという問題があった。

本発明は、かかる問題点に鑑み、ソフトウェアの不正使用を防止しつつライセンスの柔軟な運用ができるブレード、管理プログラム、および管理方法を提供することを目的とする。

上記課題を解決し、目的を達成するため、ブレードサーバの筐体に着脱可能なブレードであって、対象ソフトウェアの機能を使用可能な数を示す第１のライセンス数および筐体に固有な識別情報を筐体内の他ブレードから受信し、筐体から筐体に固有な識別情報を取得し、受信された識別情報と取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、第１のライセンス数と、対象ソフトウェアの機能を用いているブレードサーバ内のブレード数を示す第２のライセンス数とを比較することにより、対象ソフトウェアの機能が使用可能か否かを判断し、対象ソフトウェアの機能が使用可能と判断された場合、対象ソフトウェアの機能を実行可能な状態に設定し、自ブレードが実行可能な状態に設定された場合、第２のライセンス数を更新し、第１のライセンス数と更新後の第２のライセンス数とを、ブレードサーバ内のブレードのうち対象ソフトウェアの機能が未設定のブレードに送信するブレード、管理プログラムおよび管理方法が、一例として提案される。

本発明にかかるブレード、管理プログラム、および管理方法によれば、ソフトウェアの不正使用を防止しつつライセンスの柔軟な運用ができるという効果を奏する。

ライセンスキー取得とライセンス有効化の内容を示す説明図である。 複数のブレードを含む筐体のハードウェア構成を示すブロック図である。 ブレードのハードウェア構成を示すブロック図である。 管理ユニットのハードウェア構成を示すブロック図である。 管理テーブルの構成を示す説明図である。 ライセンスキー取得の流れを示すシーケンス図である。 実施例１にかかるライセンス管理装置の機能ブロック図である。 実施例１にかかる優先度を使用したライセンス有効化判定処理の詳細を示すフローチャート（その１）である。 実施例１にかかる優先度を使用したライセンス有効化判定処理の詳細を示すフローチャート（その２）である。 故障検出の流れを示すフローチャートである。 実施例１の具体例を示す説明図（その１）である。 実施例１の具体例を示す説明図（その２）である。 実施例１の具体例を示す説明図（その３）である。 実施例１の具体例を示す説明図（その４）である。 実施例１の具体例を示す説明図（その５）である。 実施例１の具体例を示す説明図（その６）である。 実施例１の具体例を示す説明図（その７）である。 実施例２にかかるライセンス管理装置の機能ブロック図である。 実施例２にかかる優先度（ｃｏｍｐ）を使用したライセンス有効化判定処理の詳細を示すフローチャート（その１）である。 実施例２にかかる優先度（ｃｏｍｐ）を使用したライセンス有効化判定処理の詳細を示すフローチャート（その２）である。 図１９のステップＳ１９０４に示した優先度（ｃｏｍｐ）の算出の流れを示すフローチャートである。 優先度（ｃｏｍｐ）算出の具体例を示す説明図である。 実施例２の具体例を示す説明図（その１）である。 実施例２の具体例を示す説明図（その２）である。 実施例２の具体例を示す説明図（その３）である。 実施例２の具体例を示す説明図（その４）である。 実施例２の具体例を示す説明図（その５）である。 実施例２の具体例を示す説明図（その６）である。 実施例１および実施例２の実用例を示す説明図（その１）である。 実施例１および実施例２の実用例を示す説明図（その２）である。

以下に添付図面を参照して、本発明にかかるライセンス管理装置の実施の形態を詳細に説明する。以下の実施の形態では、ライセンス有効化によりソフトウェアのオプション機能を使用可能にする例について説明するが、ライセンス有効化によりソフトウェアそのものの機能を使用可能にするようにしてもよい。まず、図１を用いてライセンスキー取得とライセンス有効化について説明する。

（ライセンスキー取得とライセンス有効化の内容）
図１は、ライセンスキー取得とライセンス有効化の内容を示す説明図である。顧客がソフトウェアのオプション機能を購入すると、ベンダからオプション機能購入証書が送信される。なお、オプション機能とは、ソフトウェアの基本機能に一定条件下（オプション機能購入）で追加可能な機能である。例えば、ソフトウェアがＣＡＤソフトである場合、汎用的に製図を行う基本機能以外の、半導体設計用や構造物設計用に特化した機能である。

オプション機能購入証書には、ベンダが正規に販売したオプション機能購入証書であることを示す文字列と使用可能数が記載されている。なお、オプション機能はＷＥＢで購入してもよいし店頭で購入してもよい。また、オプション機能購入証書はＥメールで送信されてもよいし、郵送で送られてもよい。

まず、顧客が、ベンダからライセンスキーを取得する手順について説明する。図１に示すように、顧客は、購入したオプション機能購入証書に記載された文字列と使用可能数と、オプション機能を使用するブレードを搭載する筐体の固有情報（ここでは、例として、筐体のシリアルナンバー）と、をベンダに送信する。

ベンダは、受信した文字列が発行済み文字列であることと、使用実績がないことと、顧客から要求された使用可能数と顧客が購入した使用可能数とが一致することと、を確認することで、顧客のオプション機能購入証書の正当性を確認する。顧客のオプション機能購入証書の正当性が確認された場合、ベンダは、受信した文字列と使用可能数と筐体の固有情報とを結合し、結合した情報を暗号化したライセンスキーを顧客に送信する。

次に、ブレードのライセンスを有効化する手順について説明する。ここで、顧客は、受信したライセンスキーをブレードに入力する。ブレードは復号鍵を有しており、ライセンスキーを復号して文字列と使用可能数と筐体の固有情報とを取得する。そして、ブレードは、筐体から得た筐体の固有情報とライセンスキーを復号して得た筐体の固有情報とが一致するか確認する。それぞれが一致した場合、ブレードは使用可能数の範囲であればライセンスを有効化して、オプション機能を使用できる。

例えば、使用可能数が３であったとした場合、図１のように、３つ目までのブレードはライセンスを有効化してオプション機能を使用することができるが、４つ目以降のブレードはライセンスを有効化できなくなる。

なお、ここでは、顧客がソフトウェアのオプション機能を購入した場合について説明したが、顧客がソフトウェアそのものを購入した場合であってもよい。この場合、ベンダからソフトウェア購入証書が送信されるようにし、ブレードはライセンスを有効化してソフトウェアそのものの機能を使用可能にする。

（筐体のハードウェア構成）
以下に、図２〜図４を用いて複数のブレードを含む筐体のハードウェア構成について説明する。筐体は管理ユニットを有し、複数のブレードを着脱するための差し込み口が設けられたシャーシである。また、筐体は、ブレード同士の通信のためのバスを有する。筐体の差し込み口はブレードをバスに結線するためのコネクタを有する。管理ユニットはバスを介して筐体に接続された複数のブレードを管理するユニットである。管理ユニットは筐体に固定されている。複数のブレードはそれぞれ独立に動作するコンピュータであり、バスを介して通信可能である。ブレードを接続した筐体をブレードサーバという。

図２は、複数のブレードを含む筐体のハードウェア構成を示すブロック図である。図２において、筐体（ブレードサーバ）２００は、複数のブレード２０１と、管理ユニット２０２と、を備えている。また、各構成部はバス２０３によってそれぞれ接続されている。

ブレードサーバでは、各ブレード２０１は、差し込み口のコネクタを用いてバス２０３と結線できる構造になっている。また、通常、各ブレード２０１は、筐体２００の電源を入れたままでの取り付け・取り外しができ、増設・交換の対象となるブレード２０１以外は業務を継続したままの状態でシステムの拡張・変更を行うことができる。

（ブレードのハードウェア構成）
次に、図３を用いてブレード２０１のハードウェア構成について説明する。

図３は、ブレード２０１のハードウェア構成を示すブロック図である。図３において、ブレード２０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０３と、優先度設定ＳＷ（ＳＷｉｔｃｈ）３０４と、を備えている。

ＣＰＵ３０１は、ブレード２０１全体の制御を司る。メモリ３０２は、ブートプログラムなどのプログラムを記憶している。メモリ３０２はまた、管理テーブル３０２ａを記憶している。Ｉ／Ｆ３０３は、バス２０３に接続され、このバス２０３を介して他の装置に接続される。そして、Ｉ／Ｆ３０３は、バス２０３と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。

優先度設定ＳＷ３０４は、ブレード２０１の優先度設定を保持しておくためのスイッチである。優先度とは、どのブレード２０１のライセンスを優先的に有効化するかを示す度合いである。このスイッチとして、例えば、ＤＩＰスイッチが採用される。なお、不揮発性メモリに優先度を保持しておくことにしてもよい。

（管理ユニットのハードウェア構成）
次に、図４を用いて管理ユニット２０２のハードウェア構成について説明する。

図４は、管理ユニット２０２のハードウェア構成を示すブロック図である。図４において、管理ユニット２０２は、ＣＰＵ４０１と、メモリ４０２と、Ｉ／Ｆ４０３と、を備えている。

ＣＰＵ４０１は、管理ユニット２０２全体の制御を司る。メモリ４０２は、ブートプログラムなどのプログラムを記憶している。Ｉ／Ｆ４０３は、バス２０３に接続され、このバス２０３を介して管理ユニット２０２が他の装置に接続される。そして、Ｉ／Ｆ４０３は、バス２０３と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。

（管理テーブルの構成）
次に、図３に示した管理テーブル３０２ａの構成について説明する。

図５は、管理テーブル３０２ａの構成を示す説明図である。図５に示すように、管理テーブル３０２ａは、筐体固有情報項目と、使用可能数項目と、使用数項目と、優先度項目と、優先度（ｃｏｍｐ）項目と、ライセンスステータス項目と、ライセンスキー項目と、故障ビット項目とを有する。

筐体固有情報項目には、ブレード２０１が接続されている筐体２００の固有情報（以下、「筐体固有情報」という）が記憶される。ここで、筐体固有情報は、予め管理ユニット２０２のメモリ４０２に記憶されている。ブレード２０１は、管理ユニット２０２から筐体固有情報を取得して筐体固有情報項目に書き込む。なお、筐体固有情報は筐体２００を一意に特定できる情報であればよい。例えば、筐体２００のシリアルナンバーが採用される。

使用可能数項目には、ブレード２０１がライセンスキーから復号して得た、筐体２００での使用可能数が記憶される。使用可能数とは、ネットワーク上でソフトウェアのオプション機能を同時に使用可能なライセンスの数である。なお、使用可能数とは、ネットワーク上でソフトウェアそのものの機能を同時に使用可能なライセンスの数であってもよい。

使用数項目には、ソフトウェアのオプション機能のライセンスを有効化しているブレード２０１の数が記憶される。なお、使用数項目には、ソフトウェアそのものの機能のライセンスを有効化しているブレード２０１の数が記憶されてもよい。なお、各ブレードがライセンスを有効化する毎に、使用数はインクリメントされる。

優先度項目には、優先度設定ＳＷ３０４によって自ブレードに対して設定された優先度が記憶される。優先度（ｃｏｍｐ）項目には、１から始まる連続番号のうち、自ブレードに対応した番号が記憶される。なお、優先度は、ユーザが任意に設定した優先度であり、固定値である。一方、優先度（ｃｏｍｐ）は、具体的には、ブレード２０１が、筐体２００内での全ブレードの優先度をソートして、自ブレードの優先度が上位から何番目かを求めた値（以下、「序列」という）であり、運用状態に変化がある度に算出し直される。

よって、例えば筐体２００内のブレード１〜３の優先度がそれぞれ「１，６，４」となっていた場合、ブレード１〜３の優先度（ｃｏｍｐ）は、それぞれ「１，３，２」となる。またブレード３が筐体２００から外れた場合には、優先度（ｃｏｍｐ）は算出し直され、ブレード１，２の優先度（ｃｏｍｐ）は、それぞれ「１，２」となる。なお、優先度を使用する例については、後述の実施例１で、優先度（ｃｏｍｐ）を使用する例については、後述する実施例２で説明する。

ライセンスステータス項目には、自ブレードのライセンスのステータスが記憶される。ライセンスのステータスとしては、例えば、「有効（判定済）」と、「無効（判定済）」と、「有効（判定中）」と、「無効（判定中）」とがある。

「有効（判定済）」とは、ブレード２０１のライセンスの有効／無効の判定が終了しブレード２０１が通常運用状態になっており、かつ、ブレード２０１のライセンスが有効である状態を示すステータスである。「無効（判定済）」とは、ブレード２０１のライセンスの有効／無効の判定が終了しブレード２０１が通常運用状態になっており、かつ、ブレード２０１のライセンスが無効である状態を示すステータスである。

「有効（判定中）」とは、ブレード２０１のライセンスが有効／無効の判定中であって、判定前にライセンスが有効であった状態を示すステータスである。これにより、ライセンスの有効／無効の判定終了までは、ブレード２０１のライセンスを有効の状態に維持しておくことができる。そのため、ブレード２０１の交換や増設によってライセンスを再判定する必要が生じた場合に、ライセンスを無効に設定してしまうことによる業務停止を未然に防止することができる。

「無効（判定中）」とは、ブレード２０１のライセンスが有効／無効の判定中であって、判定前にライセンスが無効であった状態、または、ブレード２０１のライセンスが初回の有効／無効の判定中である状態を示すステータスである。これにより、ライセンスの有効／無効の判定終了まではライセンスを無効の状態に維持しておくことができる。そのため、使用可能数の範囲外での使用を防止し、セキュリティを確保することができる。

ライセンスキー項目には、管理ユニット２０２から取得したライセンスキーが記憶される。ライセンスキーは、オプション機能購入証書に記載された文字列と使用可能数と、筐体固有情報とを暗号化して作成した文字列である。ブレード２０１は、ライセンスキーを復号することで使用可能数と筐体固有情報とを取得することができる。なお、オプション機能購入証書ではなく、上述したソフトウェア購入証書であってもよい。

故障ビット項目には、自ブレードが通常運用状態であるか故障中であるかが記憶される。例えば、通常運用状態時を０に、故障時を１に割り振っておく。ブレード２０１は自身の故障を検出した場合、故障ビットを１にセットする。

図６は、ライセンスキー取得の流れを示すシーケンス図である。まず、管理ユニット２０２は、オプション機能購入証書に記載された文字列と使用可能数と、オプション機能を使用するブレード２０１を搭載する筐体固有情報と、をベンダ側コンピュータに送信する（ステップＳ６０１）。

ベンダ側コンピュータは受信した文字列が未使用文字列であるか認証し（ステップＳ６０２）、文字列が未使用文字列であると認証できれば、受信した文字列と使用可能数と筐体固有情報とを暗号化してライセンスキーを作成する（ステップＳ６０３）。そして、ベンダ側コンピュータは、作成したライセンスキーを管理ユニット２０２に送信する（ステップＳ６０４）。

次に、管理ユニット２０２は、受信したライセンスキーを筐体２００内の全ブレードに送信する（ステップＳ６０５）。ライセンスキーを受信した各ブレードは、ライセンスキーを復号する（ステップＳ６０６）。そして、各ブレードは、管理ユニット２０２に筐体固有情報を要求する（ステップＳ６０７）。要求を受けた管理ユニット２０２は、筐体固有情報を各ブレードに送信する（ステップＳ６０８）。

そして、各ブレードは、管理ユニット２０２から受信した筐体固有情報とライセンスキーから復号した筐体固有情報との一致を確認し、使用数がライセンスキーから復号した使用可能数の範囲内であることを確認し、ライセンスの有効／無効を判定する（ステップＳ６０９）。

例えば、管理ユニット２０２から受信した筐体固有情報とライセンスキーから復号した筐体固有情報とが一致すれば、正当なライセンスであると判断でき、ブレード２０１は、使用可能数の範囲内であれば自由にライセンスを有効化できる。一方、受信した筐体固有情報とライセンスキーから復号した筐体固有情報とが一致しない場合、不正なライセンスと判断され、ブレード２０１は、ライセンスを有効化できない。また、使用数が使用可能数を超える場合も、ブレード２０１は、ライセンスを有効化できない。このようにして、ブレード２０１は、筐体固有情報と使用可能数とを含むライセンスキーを取得し、ライセンスの有効／無効を判定することができる。

なお、このライセンス有効化判定処理（ステップＳ６０６〜ステップＳ６０９）の詳細について、実施例１においては、図８、図９を用いて後述する。また、このライセンス有効化判定処理（ステップＳ６０６〜ステップＳ６０９）の詳細について、実施例２においては、図１９、図２０を用いて後述する。

次に、各ブレードが、ライセンスを有効化する順序を設定した場合の具体例について説明する。ここで、顧客は、どのブレード２０１がライセンスを優先的に有効化するかを示す優先度をブレード毎に設定している。そのため、各ブレードは、ブレード２０１の故障や交換による運用形態変化時に、自身に設定された優先度に従って自動的にライセンスを移行し、円滑な運用を行うことができる。

（実施例１）
実施例１は、優先度の高いブレード２０１から優先的にライセンス有効化判定処理を行い、他ブレードは優先度の高いブレード２０１のライセンス有効化判定処理終了まで待機するようにした実施例である。これにより、優先度の高いブレード２０１から順に、筐体２００内での使用可能数の範囲内でライセンスを有効化することができる。

（実施例１にかかるライセンス管理装置の機能的構成）
次に、図７を用いて実施例１にかかるライセンス管理装置の機能的構成について説明する。ライセンス管理装置の機能は、本実施例ではブレード２０１内のＣＰＵ３０１により実現される。なお、以下では、ソフトウェアのオプション機能のライセンスを有効化する場合について説明するが、ソフトウェアそのものの機能のライセンスを有効化する場合であってもよい。

図７は、実施例１にかかるライセンス管理装置の機能ブロック図である。図７に示すように、ライセンス管理装置は、受信部７０１と、取得部７０２と、判断部７０３と、設定部７０４と、更新部７０５と、送信部７０６と、検出部７０７と、を備える。

受信部７０１は、ソフトウェアの機能を使用可能な数を示す第１のライセンス数と筐体２００に固有な識別情報とを受信する機能を有する。ここで、ソフトウェアの機能とは、上述したオプション機能である。また、第１のライセンス数とは、上述した使用可能数である。即ち、ソフトウェアのオプション機能を同時に使用可能なライセンスの数である。筐体２００に固有な識別情報とは、上述した筐体固有情報をいう。例えば、筐体２００のシリアルナンバーである。

具体的には、例えば、受信部７０１は、他ブレードから使用可能数と筐体固有情報を受信する。そして、受信部７０１は、取得した使用可能数と筐体固有情報を管理テーブル３０２ａに保持する。受信部７０１は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。

これにより、受信部７０１は、使用可能数と筐体固有情報を外部から受信することができる。受信部７０１は、使用可能数と筐体固有情報を、管理ユニット２０２から受信してもよい。なお、受信部７０１は、使用可能数と筐体固有情報とが含まれるライセンスキーを受信することで、間接的に使用可能数と筐体固有情報とを受信している。

取得部７０２は、筐体２００から筐体２００に固有な識別情報を取得する機能を有する。具体的には、例えば、取得部７０２は、筐体２００から筐体固有情報を取得し、筐体固有情報を管理テーブル３０２ａに保持する。筐体２００から取得された筐体固有情報は、ライセンスキーから得られる筐体固有情報との認証に用いられる。

取得部７０２は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。これにより、取得部７０２は、筐体固有情報を取得することができる。

判断部７０３は、受信された第１のライセンス数と、現在筐体２００内のブレードが使用中の第２のライセンス数とを比較することにより、ソフトウェアの機能が使用可能か否かを判断する機能を有する。また、判断部７０３は、取得部７０２によって取得された筐体２００に固有な識別情報と受信部７０１によって受信された筐体２００に固有な識別情報とが一致するかを判断する機能を有する。ここで、第２のライセンス数とは、上述した使用数である。即ち、第２のライセンス数とはソフトウェアのオプション機能を同時に使用中のライセンスの数である。

したがって、判断部７０３は、使用可能数と使用数を比較する。そして、使用数が使用可能数以上であればオプション機能は使用不能と判断する。これにより、判断部７０３は、使用可能数を超えた個数のオプション機能が使用されることを防止できる。また、使用数が使用可能数より少なければオプション機能は使用可能と判断する。これにより、判断部７０３は、使用可能数の範囲内であればオプション機能が使用可能と判断できる。

また、使用可能数と使用数との比較に先だって、判断部７０３は、取得部７０２によって取得された筐体固有情報と受信部７０１によって受信された筐体固有情報とが一致するか否かを判断する。判断部７０３は、一致する場合に正当なライセンスであると判断する。これにより、判断部７０３は、ライセンスがベンダから正当に付与されたライセンスか否かを判別することができる。そのため、不正なライセンスを用いてオプション機能が不正使用されることを防止できる。なお、不一致の場合は、使用可能数と使用数との比較は実行されない。

また、判断部７０３は、ブレード２０１毎の固有情報ではなく、どのブレード２０１でも共通の筐体固有情報を用いてライセンスの正当性を判断している。これにより、筐体２００内のブレード２０１であればどのブレード２０１でもオプション機能が使用可能かの判断を行うことができる。また、筐体２００からブレード２０１が外された場合、オプション機能を使用できないようにすることができる。

判断部７０３は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。

設定部７０４は、判断部７０３によってソフトウェアの機能が使用可能と判断された場合、ソフトウェアの機能を実行可能な状態に設定する機能を有する。また、設定部７０４は、検出部７０７によって自ブレード内の故障が検出された場合、判断部７０３によって判断を行わずにソフトウェアの機能を実行不能な状態に設定する機能を有する。具体的には、例えば、設定部７０４は、ライセンスを有効化することでオプション機能を使用可能な状態に設定する。またライセンスを無効化することでオプション機能を使用不能な状態に設定する。

設定部７０４は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。これにより、設定部７０４は、ブレード２０１を、オプション機能を使用可能な状態に設定でき、また、ブレード２０１を、オプション機能を使用不能な状態に設定できる。

更新部７０５は、第２のライセンス数を更新する機能を有する。具体的には、例えば、更新部７０５は、設定部７０４によりオプション機能を使用可能な状態に設定された場合、使用数をインクリメントして管理テーブル３０２ａに保持する。

更新部７０５は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。これにより、更新部７０５は、使用数を最新の情報に更新することができる。

送信部７０６は、第１のライセンス数と更新部７０５による更新後の第２のライセンス数とを送信する機能を有する。具体的には、例えば、送信部７０６は、第１のライセンス数をまだ受信していないブレード２０１から送信要求を受けて、第１のライセンス数を送信する。また、送信部７０６は、更新部７０５による更新後の使用数を他ブレードに送信する。そして、他ブレードは、管理テーブル３０２ａに保持されている使用数を最新の情報に更新する。

送信部７０６は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。これにより、送信部７０６は、使用可能数をまだ受信していないブレード２０１に対して使用可能数を送信することができる。また、これにより、他ブレードは、管理テーブル３０２ａに保持されている使用数を最新の情報に更新することができる。

なお、送信部７０６は、全ブレードに対して、使用可能数と更新部７０５による更新後の使用数とを送信してもよい。送信部７０６はまた、自ブレードの次の優先度となるブレード２０１に対してのみ使用可能数と更新部７０５による更新後の使用数とを送信してもよい。

検出部７０７は、自ブレードの故障を検出する機能を有する。具体的には、例えば、検出部７０７は、自ブレードの故障を検出して、管理テーブル３０２ａに保持されている故障ビットを１にセットする。なお、周知技術のため詳細な説明は省略するが、故障の検出は、例えば、ブレード２０１内部のメモリ３０２や信号処理デバイスや基板に対して、周期的に自己診断プログラムを実行することにより行われる。そして、各部が正常動作か否かを確認し、正常動作していない場合、故障していると判断する。

検出部７０７は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。これにより、検出部７０７は、自ブレードの故障を検出することができる。

図８は、実施例１にかかる優先度を使用したライセンス有効化判定処理（図６のステップＳ６０６〜ステップＳ６０９）の詳細を示すフローチャート（その１）である。ここでは、ブレード２０１の電源投入時に全ブレードがライセンス有効化判定処理を同時に開始するものとする。また、各ブレードには、優先度設定ＳＷ３０４によって優先度が設定されている。なお、不揮発性メモリに優先度を保持しておくことにしてもよい。

まず、ブレード２０１は、優先度設定ＳＷ３０４によって設定された自ブレードの優先度を取得し、管理テーブル３０２ａに保持する（ステップＳ８０１）。次に、ブレード２０１は、他ブレードの管理テーブル３０２ａに保持されている他ブレードの優先度を取得し、メモリ３０２に保持する（ステップＳ８０２）。

ここで、ブレード２０１は、他ブレードの優先度と自ブレードの優先度が重複しているか否かを判定する（ステップＳ８０３）。他ブレードの優先度と自ブレードの優先度が重複している場合（ステップＳ８０３：Ｙｅｓ）、不正な優先度設定であるとして、ブレード２０１は、自ブレードの起動を停止し（ステップＳ８０５）、ライセンス有効化判定処理を終了する。

一方、他ブレードの優先度と自ブレードの優先度が重複していない場合（ステップＳ８０３：Ｎｏ）、ステップＳ８０４に進む。

次に、ブレード２０１は、自ブレードのライセンスのステータスを「無効（判定中）」に設定する（ステップＳ８０４）。ただし、ライセンス有効化判定処理に入る前に自ブレードのライセンスが有効であった場合は自ブレードのライセンスのステータスを「有効（判定中）」に設定する。

ここで、ブレード２０１は、自ブレードの管理テーブル３０２ａにライセンスキーが保持されているか判定する（ステップＳ８０６）。自ブレードの管理テーブル３０２ａにライセンスキーが保持されている場合（ステップＳ８０６：Ｙｅｓ）、ステップＳ８１０に進む。

自ブレードの管理テーブル３０２ａにライセンスキーが保持されていない場合（ステップＳ８０６：Ｎｏ）、ブレード２０１は、他ブレードの管理テーブル３０２ａにライセンスキーが保持されているか判定する（ステップＳ８０７）。他ブレードの管理テーブル３０２ａにライセンスキーが保持されている場合（ステップＳ８０７：Ｙｅｓ）、ブレード２０１は、他ブレードの管理テーブル３０２ａからライセンスキーを取得し（ステップＳ８０８）、取得したライセンスキーを自ブレードの管理テーブル３０２ａに保持し、ステップＳ８１０に進む。

他ブレードの管理テーブル３０２ａにもライセンスキーが保持されていない場合（ステップＳ８０７：Ｎｏ）、ブレード２０１は、ライセンスキーを管理ユニットから受信したか判定する（ステップＳ８０９）。ライセンスキーを受信していない場合（ステップＳ８０９：Ｎｏ）、ステップＳ８０９に戻る。ライセンスキーを受信した場合（ステップＳ８０９：Ｙｅｓ）、ステップＳ８１０に進む。

ここで、全ブレードがライセンス有効化判定処理を開始しておりこの時点でライセンスを有効化しているブレード２０１は存在しないため、ブレード２０１は、管理テーブル３０２ａに保持されている使用数の値を０に設定して（ステップＳ８１０）、図９のステップＳ９０１に進む。

図９は、実施例１にかかる優先度を使用したライセンス有効化判定処理（図６のステップＳ６０６〜ステップＳ６０９）の詳細を示すフローチャート（その２）である。図９において、ブレード２０１は、管理ユニット２０２から筐体固有情報を取得し（ステップＳ９０１）、管理テーブル３０２ａに保持する。また、ブレード２０１は、ライセンスキーを復号して筐体固有情報と使用可能数を取得し（ステップＳ９０２）、管理テーブル３０２ａに保持する。

そして、ブレード２０１は、復号した筐体固有情報と取得した筐体固有情報とが一致するか判定する（ステップＳ９０３）。復号した筐体固有情報と取得した筐体固有情報とが一致しない場合（ステップＳ９０３：Ｎｏ）、不正なライセンスであるとして、ブレード２０１は、自ブレードの起動を停止し（ステップＳ８０５）、ライセンス有効化判定処理を終了する。復号した筐体固有情報と取得した筐体固有情報とが一致する場合（ステップＳ９０３：Ｙｅｓ）、正式なライセンスであるとしてステップＳ９０４に進む。

次に、ブレード２０１は、自ブレードよりも優先度が高いブレード２０１（以下、「上位ブレード」という）のライセンス有効化判定処理が終了したか判定する（ステップＳ９０４）。上位ブレードのライセンス有効化判定処理が終了していない場合（ステップＳ９０４：Ｎｏ）、ステップＳ９０４に戻る。上位ブレードのライセンス有効化判定処理が終了した場合（ステップＳ９０４：Ｙｅｓ）、ブレード２０１は、上位ブレードから使用数を受信して、ステップＳ９０５に進む。

そして、ブレード２０１は、自ブレードの故障ビットが立っているか判定する（ステップＳ９０５）。自ブレードの故障ビットが立っている場合（ステップＳ９０５：Ｙｅｓ）、自ブレードは故障しているものとして、ブレード２０１は、ライセンスを無効（判定済）に設定し（ステップＳ９０８）、ステップＳ９１０に進む。自ブレードの故障ビットが立っていない場合（ステップＳ９０５：Ｎｏ）、自ブレードは通常運用状態であるとして、ステップＳ９０６へ進む。

次に、ブレード２０１は、使用可能数＞使用数であるか判定する（ステップＳ９０６）。使用可能数＞使用数でない場合（ステップＳ９０６：Ｎｏ）、未使用のライセンスはないとして、ブレード２０１は、ライセンスを無効（判定済）に設定し（ステップＳ９０８）、ステップＳ９１０に進む。使用可能数＞使用数である場合（ステップＳ９０６：Ｙｅｓ）、未使用のライセンスがあるとして、ブレード２０１は、ライセンスを有効（判定済）に設定し（ステップＳ９０７）、使用数をインクリメントして管理テーブル３０２ａに保持し、インクリメントした使用数を他ブレードへ配信する（ステップＳ９０９）。そして、ステップＳ９１０に進む。

最後に、ブレード２０１は、メモリ３０２に保持されている他ブレードの優先度を参照して、次点の優先度のブレード２０１へ、自ブレードのライセンス有効化判定処理が終了したことを通知する（ステップＳ９１０）。なお、次点の優先度のブレード２０１が存在しない場合はライセンス有効化判定処理の終了を通知しない。そして、ライセンス有効化判定処理を終了し、通常運用状態に移行する。ライセンス有効化判定処理によって、ブレード２０１は、使用可能数の範囲内であればライセンスを有効化することができる。

なお、ライセンス有効化判定処理は、ブレード２０１の初めの電源投入時に行われるが、ブレード２０１の増設・交換時をトリガとしてこの処理を行ってもよいし、故障検出時をトリガとしてライセンス有効化判定処理を行ってもよい。その際、全ブレードがライセンス有効化判定処理を行うようにした場合は、ステップＳ８１０において全ブレードで使用数を「０」に設定する。

また、増設・交換したブレード２０１と増設・交換したブレード２０１より優先度が低いブレード２０１のみライセンス有効化判定処理を行ってもよい。この場合、ステップＳ８１０において、ライセンス有効化判定処理を行わないブレード２０１のうちソフトウェアまたはソフトウェアのオプション機能のライセンスを有効化しているブレード２０１の数を使用数として設定する。そして、増設・交換したブレード２０１では、ステップＳ９０４の処理を省略してもよい。また、不正防止のために一定の時間間隔でライセンス有効化判定処理を繰り返し行ってもよい。

なお、ここでは、各ブレードは全ブレードに対して、インクリメントした使用数を送信したが、自ブレードの次の優先度となるブレード２０１のみにインクリメントした使用数を送信してもよい。また、ここでは、自ブレードのライセンス有効化判定処理終了を自ブレードの次の優先度となるブレード２０１のみに通知したが、全ブレードに対して、自ブレードのライセンス有効化判定処理終了を通知し、各ブレードがそれぞれライセンス有効化判定処理を開始するか否かを判断してもよい。

このように、優先度の高いブレード２０１から順に、筐体２００内での使用可能数の範囲内でライセンスを有効化することができる。また、ブレード２０１の交換・増設・故障時に、優先度に従って自動でライセンスを有効化／無効化することができる。

次に、通常運用状態に移行した後、ブレード２０１に故障が発生した場合の処理について説明する。

図１０は、故障検出の流れを示すフローチャートである。まず、ブレード２０１は、自ブレードに故障が発生したか判断する（ステップＳ１００１）。自ブレードに故障が発生していない場合（ステップＳ１００１：Ｎｏ）、ステップＳ１００１に戻る。

自ブレードに故障が発生した場合（ステップＳ１００１：Ｙｅｓ）、ブレード２０１は、自ブレードの管理テーブル３０２ａの故障ビットを立てる（ステップＳ１００２）。そして、故障検出の処理を終了する。この処理によって、ブレード２０１は、自ブレードの故障を検出することができる。

なお、故障検出をトリガに全ブレードがライセンス有効化判定処理を行うようにしてもよい。例えば、故障したブレード２０１が他ブレードに対して故障検出の通知を行い、故障したブレード２０１と通知を受けたブレード２０１とがライセンス有効化判定処理を行うようにする。この際、故障したブレード２０１と故障したブレード２０１より優先度が低いブレード２０１とのみがライセンス有効化判定処理を行うようにしてもよい。これにより、故障したブレード２０１の上位ブレードではライセンス有効化判定処理による負担がなくなる。

また、故障検出時にディスプレイ（不図示）に故障発生のアナウンスを表示して、ユーザにブレード２０１の交換の必要性を通知するようにしてもよい。また、ミドルウェアを用いて故障発生時のブレード２０１の切り替え先を設定しておき、切り替え先と切り替え元の２つのブレード２０１のみライセンス有効化判定処理を行うようにしてもよい。

一度ライセンス有効化判定処理を行ったブレード２０１で、再度ライセンス有効化判定処理を行う場合は、既にブレード２０１の管理テーブル３０２ａに優先度とライセンスキーが保持されている。よって、ブレード２０１が、図８のステップＳ８０８からライセンス有効化判定処理を始めるようにしてもよい。これにより、ライセンス有効化判定処理が高速化する。ここで、図１１〜図１７を用いて、実施例１の具体例について説明する。

図１１〜図１７は、実施例１の具体例を示す説明図である。まず、図１１において、筐体２００に、ブレード１が差し込まれたとする。ここで、ブレード１は、（１）優先度設定ＳＷ３０４によって設定された自身の優先度を管理テーブル３０２ａに保持する。次に、図１１の状況では（２）他ブレードがないため、他ブレードから優先度を取得せず処理を続ける。

次に、ブレード１は、（３）自ブレードの管理テーブル３０２ａにライセンスキーが保持されていないため、他ブレードからライセンスキーを取得しようとする。しかし、筐体２００内には（４）他ブレードがなく、ブレード１は他ブレードからライセンスキーを取得できない。よって、（５）ブレード１は管理ユニット２０２からライセンスキーが入力されるのを待つ。

ここでは、管理ユニット２０２からブレード１にライセンスキーが入力されたとする。ブレード１は、（６）使用数を０として管理テーブル３０２ａに保持する。

図１２において、ブレード１は、（７）管理ユニット２０２から筐体固有情報を受信する。ここで、ブレード１は、ライセンスキーを復号して、筐体固有情報と使用可能数を取得する。そして、ブレード１は、（８）受信した筐体固有情報と復号した筐体固有情報とが一致するため、正当なライセンスキーと判断して次の処理に進む。

次に、ブレード１は、使用可能数と使用数を比較する。ここで、（９）使用可能数は２であり、使用数は０であるから、まだライセンスは有効化できると判断する。そして、ブレード１は、（１０）ライセンスを有効化する。また、使用数をインクリメントして管理テーブル３０２ａに保持する。なお、ブレード１は、筐体２００内に他ブレードが存在しないため、自ブレードの処理終了の通知を行わない。

次に、筐体２００に、新たにブレード２が差し込まれたとする。ここでは、ブレード２０１の増設に伴い全ブレードがライセンス有効化判定処理を行うとする。

ここで、各ブレードは、（１１）優先度設定ＳＷ３０４によって設定された優先度を管理テーブル３０２ａに保持する。次に、各ブレードは、（１２）他ブレードから優先度を取得し、メモリ３０２に保持する。

次に、ブレード２は、（１３）自ブレードの管理テーブル３０２ａにライセンスキーが保持されていないため、（１４）他ブレード（ここではブレード１）からライセンスキーを取得しようとする。（１５）ブレード２は、ブレード１からライセンスキーを受信し管理テーブル３０２ａに保持する。そして、各ブレードは、（１６）使用数を０として管理テーブル３０２ａに保持する。

図１３において、各ブレードは、（１７）管理ユニット２０２から筐体固有情報を受信する。ここで、各ブレードは、ライセンスキーを復号して、筐体固有情報と使用可能数を取得する。そして、各ブレードは、（１８）受信した筐体固有情報と復号した筐体固有情報とが一致するため、正当なライセンスキーと判断して次の処理に進む。

各ブレードは、管理テーブル３０２ａに保持された自身の優先度とメモリ３０２に保持された他ブレードの優先度に基づいて上位ブレードがどのブレード２０１かを判断する。そして、各ブレードは、（１９）上位ブレードの処理終了を待つ。ブレード１の優先度が最も高く上位ブレードがないため、ブレード１が処理を開始する。ブレード２は、ブレード１の処理終了を待つ。

次に、ブレード１は、使用可能数と使用数を比較する。ここで、（２０）使用可能数は２であり、使用数は０であるから、まだライセンスは有効化できると判断する。そして、ブレード１は、（２１）ライセンスを有効化する。また、使用数をインクリメントして管理テーブル３０２ａに保持する。

次に、ブレード１は、（２２）インクリメントした使用数を他ブレードへ送信する。ここで、ブレード２は、ブレード１から受信した使用数を管理テーブル３０２ａに保持する。そして、ブレード１は、（２３）自ブレードの処理終了をブレード２に通知する。

ブレード１から処理終了の通知を受けたブレード２は処理を開始する。ブレード２は、使用可能数と使用数を比較する。ここで、（２４）使用可能数は２であり、使用数は１であるから、まだライセンスは有効化できると判断する。そして、ブレード２は、（２５）ライセンスを有効化する。また、使用数をインクリメントして管理テーブル３０２ａに保持する。

次に、ブレード２は、（２６）インクリメントした使用数を他ブレードへ送信する。ここで、ブレード２からブレード１は、受信した使用数を管理テーブル３０２ａに保持する。なお、ブレード２は、図１２の例では自ブレードより優先度の低いブレード（以下、「下位ブレード」という）が存在しないため、自ブレードの処理終了を他ブレードに通知しない。

次に、筐体２００に、新たにブレード３が差し込まれたとする。ここでは、ブレード２０１の増設に伴い全ブレードがライセンス有効化判定処理を行うとする。

図１４において、各ブレードは、（２７）優先度設定ＳＷ３０４によって設定された優先度を管理テーブル３０２ａに保持する。次に、（２８）他ブレードから優先度を取得し、メモリ３０２に保持する。

次に、ブレード３は、（２９）自ブレードの管理テーブル３０２ａにライセンスキーが保持されていないため、（３０）他ブレード（ここではブレード１）からライセンスキーを取得しようとする。（３１）ブレード３は、ブレード１からライセンスキーを受信し管理テーブル３０２ａに保持する。そして、各ブレードは、（３２）使用数を０として管理テーブル３０２ａに保持する。

次に、各ブレードは、（３３）管理ユニット２０２から筐体固有情報を受信する。ここで、各ブレードは、ライセンスキーを復号して、筐体固有情報と使用可能数を取得する。そして、（３４）受信した筐体固有情報と復号した筐体固有情報とが一致するため、正当なライセンスキーと判断して次の処理に進む。

そして、各ブレードは、（３５）上位ブレードの処理終了を待つ。ブレード１の優先度が最も高く上位ブレードがないため、ブレード１が処理を開始する。また、ブレード３は、優先度が２番目に高いため、ブレード１の処理終了を待ち、処理を開始する。そして、ブレード２は優先度が最も低いため、ブレード３の処理終了を待ち、最後に処理を開始する。

図１５において、ブレード１は、使用可能数と使用数を比較する。ここで、（３６）使用可能数は２であり、使用数は０であるから、まだライセンスは有効化できると判断する。そして、ブレード１は、（３７）ライセンスを有効化する。また、使用数をインクリメントして管理テーブル３０２ａに保持する。

次に、ブレード１は、（３８）インクリメントした使用数を他ブレードへ送信する。ここで、ブレード２，３は、受信した使用数を管理テーブル３０２ａに保持する。そして、ブレード１は、（３９）自ブレードの処理終了をブレード３に通知する。

通知を受けたブレード３は処理を開始する。ブレード３は、使用可能数と使用数を比較する。ここで、（４０）使用可能数は２であり、使用数は１であるから、まだライセンスは有効化できると判断する。そして、ブレード３は、（４１）ライセンスを有効化する。また、使用数をインクリメントして管理テーブル３０２ａに保持する。

次に、ブレード３は、（４２）インクリメントした使用数を他ブレードへ送信する。ここで、ブレード１，２は、受信した使用数を管理テーブル３０２ａに保持する。そして、ブレード３は、（４３）自ブレードの処理終了をブレード２に通知する。

通知を受けたブレード２は処理を開始する。ブレード２は、使用可能数と使用数を比較する。ここで、（４４）使用可能数は２であり、使用数は２であるから、ライセンスは有効化できないと判断する。そして、ブレード２は、（４５）ライセンスを無効化する。なお、ブレード２は、下位ブレードが存在しないため、自ブレードの処理終了を他ブレードに通知しない。

ここで、ブレード１に故障が発生した場合について説明する。ここでは、ブレード２０１の故障発生に伴い全ブレードがライセンス有効化判定処理を行うとする。

図１６において、ブレード１は、故障を検出すると、（４６）故障ビットを１にセットして管理テーブル３０２ａに保持する。また、ブレード１は、故障検出を他ブレードに通知する。そして、故障を検出したブレード１と、故障検出の通知を受けたブレード２とブレード３はライセンス有効化処理を開始する。

ここで、各ブレードは、（４７）優先度設定ＳＷ３０４によって設定された優先度を管理テーブル３０２ａに保持する。次に、各ブレードは、（４８）他ブレードから優先度を取得し、メモリ３０２に保持する。各ブレードは、ライセンスキーを保持しているため、そのまま次の処理に進む。そして、各ブレードは、（４９）使用数を０として管理テーブル３０２ａに保持する。

次に、各ブレードは、（５０）管理ユニット２０２から筐体固有情報を受信する。ここで、各ブレードは、ライセンスキーを復号して、筐体固有情報と使用可能数を取得する。そして、（５１）受信した筐体固有情報と復号した筐体固有情報とが一致するため、正当なライセンスキーと判断して次の処理に進む。

そして、各ブレードは、（５２）上位ブレードの処理終了を待つ。ブレード１の優先度が最も高く上位ブレードがないため、ブレード１が処理を開始する。また、ブレード２は、ブレード３の処理終了を待ち、ブレード３は、ブレード１の処理終了を待つ。

図１７において、（５３）故障ビットが立っているため、ブレード１は、（５４）自身のライセンスを無効化して、（５５）自ブレードの処理終了をブレード３に通知する。

通知を受けたブレード３は処理を開始する。ブレード３は、使用可能数と使用数を比較する。ここで、（５６）使用可能数は２であり、使用数は０であるから、まだライセンスは有効化できると判断する。そして、ブレード３は、（５７）ライセンスを有効化する。また、使用数をインクリメントして管理テーブル３０２ａに保持する。

次に、ブレード３は、（５８）インクリメントした使用数を他ブレードへ送信する。ここで、ブレード１，２は、受信した使用数を管理テーブル３０２ａに保持する。そして、ブレード３は、（５９）自ブレードの処理終了をブレード２に通知する。

次に、ブレード２は、使用可能数と使用数を比較する。ここで、（６０）使用可能数は２であり、使用数は１であるから、まだライセンスは有効化できると判断する。そして、ブレード２は、（６１）ライセンスを有効化する。また、使用数をインクリメントして管理テーブル３０２ａに保持する。

次に、ブレード２は、（６２）インクリメントした使用数を他ブレードへ送信する。ここで、ブレード１，３は、受信した使用数を管理テーブル３０２ａに保持する。なお、ブレード２は、下位ブレードが存在しないため、自ブレードの処理終了を他ブレードに通知しない。

このように、上述した実施例１では、各ブレードが相互に使用数を監視して、使用可能数を使用数が超えないようにしている。そのため、使用可能数の範囲内ならどのブレード２０１でも自由にライセンスを有効化してソフトウェアまたはソフトウェアのオプション機能を使用できる。また、各ブレードが相互に使用数を監視するため、外部にライセンス管理用ユニットを設置する必要がなくコストを削減できる。さらに、各ブレードが相互に使用数を監視するため、ライセンス管理用ユニットの不正改造によってソフトウェアまたはソフトウェアのオプション機能を不正使用される虞もなくなる。そして、外部にライセンス管理用ユニットを設置する必要がないため、ライセンス管理用ユニットの故障による業務停止を防止できる。

また、上位ブレードのライセンス有効化判定処理の終了を待つようにしたため、誤動作によって使用数が使用可能数を超えることを防止できる。さらに、ライセンスキーを筐体固有情報にロックしたため、バス２０３からブレード２０１を切り離すことによる、ソフトウェアまたはソフトウェアのオプション機能の不正使用を防止することができる。

また、上述した実施例１では、ブレード２０１の増設・故障を検出した場合に、ライセンス有効化判定処理を再度行い、ブレード２０１を、優先度に従って自動でライセンスを有効化／無効化するようにした。同時に、故障したブレード２０１のライセンスは無効化されるようにしたため、速やかな保守が自動的に行えるようになる。

（実施例２）
次に、実施例２について説明する。実施例１では、優先度を用いたが、実施例２では、優先度（ｃｏｍｐ）を用いる。そして、実施例２では、ライセンスを有効化可能なブレード２０１を判定し、各ブレードのライセンス有効化判定処理を並列して行うようにする。これにより、優先度の高いブレード２０１の処理を待たずに、各ブレードは、筐体内での使用可能数の範囲内であればライセンスを有効化することができる。

（実施例２にかかるライセンス管理装置の機能的構成）
次に、図１８を用いて実施例２にかかるライセンス管理装置の機能的構成について説明する。ライセンス管理装置の機能は、本実施例ではブレード２０１内のＣＰＵ３０１により実現される。なお、以下では、ソフトウェアのオプション機能のライセンスを有効化する場合について説明するが、ソフトウェアそのものの機能のライセンスを有効化する場合であってもよい。

図１８は、実施例２にかかるライセンス管理装置の機能ブロック図である。図１８に示すように、ライセンス管理装置は、受信部１８０１と、取得部１８０２と、変換部１８０３と、判断部１８０４と、設定部１８０５と、検出部１８０６と、を備える。

受信部１８０１は、ソフトウェアの機能を使用可能なライセンス数を他ブレードから受信する機能を有する。また、受信部１８０１は、筐体２００に固有な識別情報を受信する機能を有する。ここで、ソフトウェアの機能とは、上述したオプション機能である。使用可能なライセンス数とは、上述した使用可能数である。即ち、ネットワーク上でソフトウェアのオプション機能を同時に使用可能なライセンスの数である。筐体２００に固有な識別情報とは、上述した筐体固有情報をいう。例えば、筐体２００のシリアルナンバーである。

具体的には、例えば、受信部１８０１は、他ユニットから使用可能数と筐体固有情報を受信する。そして、受信部１８０１は、取得した使用可能数と筐体固有情報を管理テーブル３０２ａに保持する。受信部１８０１は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。

これにより、受信部１８０１は、使用可能数と筐体固有情報を受信することができる。受信部１８０１は、使用可能数と筐体固有情報を、管理ユニット２０２から受信してもよい。なお、実際には、受信部１８０１は、使用可能数と筐体固有情報とが含まれるライセンスキーを受信することで、間接的に使用可能数と筐体固有情報とを受信している。

取得部１８０２は、優先度を各ブレードから取得する機能を有する。なお、優先度は、優先度設定ＳＷ３０４によってブレード２０１毎に設定されている。また、取得部１８０２は、筐体２００から筐体２００に固有な識別情報を取得する機能を有する。

具体的には、例えば、取得部１８０２は、各ブレードの優先度を取得し、メモリ３０２に保持する。また、具体的には、例えば、取得部１８０２は、筐体２００から筐体固有情報を取得し、筐体固有情報を管理テーブル３０２ａに保持する。取得部１８０２は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。これにより、取得部１８０２は各ブレードの優先度を取得することができる。また、これにより、取得部１８０２は、筐体固有情報を取得することができる。

変換部１８０３は、取得部１８０２によって取得された自ブレードの優先度を、１から始まる連続番号のうち、自ブレードの優先度に応じた番号に変換する機能を有する。ここで、１から始まる連続番号のうち、自ブレードの優先度に応じた番号とは、上述した優先度（ｃｏｍｐ）である。具体的には、例えば、数字の小さい優先度が優先度が高いとした場合には、変換部１８０３は、各ブレードの優先度を降順にソートし、その序列を優先度（ｃｏｍｐ）として管理テーブル３０２ａに保持する。

変換部１８０３は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。これにより、変換部１８０３は優先度（ｃｏｍｐ）を得ることができる。

判断部１８０４は、受信部１８０１によって受信されたライセンス数と変換部１８０３によって変換された自ブレードに対応する番号とを比較することにより、ソフトウェアの機能が使用可能か否かを判断する機能を有する。また、判断部１８０４は、取得部１８０２によって取得された筐体２００に固有な識別情報と受信部１８０１によって受信された筐体２００に固有な識別情報とが一致するかを判断する機能を有する。

具体的には、例えば、判断部１８０４は、自ブレードの優先度（ｃｏｍｐ）が使用可能数以下であればオプション機能を使用可能と判断する。具体的には、例えば、判断部１８０４は、取得部１８０２によって取得された筐体固有情報と受信部１８０１によって受信された筐体固有情報とが一致する場合に正当なライセンスであると判断する。

判断部１８０４は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。これにより、判断部１８０４は、使用可能数を超えた個数のオプション機能が使用されることを防止できる。また、これにより、判断部１８０４は、ライセンスがベンダから正当に付与されたライセンスか否かを判別することができる。

設定部１８０５は、判断部１８０４によってソフトウェアの機能が使用可能と判断された場合、ソフトウェアの機能を実行可能な状態に設定する機能を有する。また、設定部１８０５は、検出部１８０６によって故障が検出された場合、判断部１８０４によって判断を行わずにソフトウェアの機能を実行不能な状態に設定する機能を有する。具体的には、例えば、設定部１８０５は、ライセンスを有効化することでオプション機能を使用可能な状態に設定する。またライセンスを無効化することでオプション機能を使用不能な状態に設定する。

設定部１８０５は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。これにより、設定部１８０５は、ブレード２０１を、オプション機能を使用可能な状態に設定でき、また、ブレード２０１を、オプション機能を使用不能な状態に設定できる。

検出部１８０６は、自ブレードの故障を検出する機能を有する。具体的には、例えば、検出部１８０６は、自ブレードの故障を検出して、管理テーブル３０２ａに保持されている故障ビットを１にセットする。

検出部１８０６は、具体的には、例えば、図３に示したメモリ３０２に記憶されたプログラムをＣＰＵ３０１に実行させることにより、その機能を実現する。これにより、検出部１８０６は、自ブレードの故障を検出することができる。

図１９は、実施例２にかかる優先度（ｃｏｍｐ）を使用したライセンス有効化（図６のステップＳ６０６〜ステップＳ６０９）の詳細を示すフローチャート（その１）である。ここで、各ブレードには、優先度設定ＳＷ３０４によって優先度が設定されている。

まず、ブレード２０１は、優先度設定ＳＷ３０４によって設定された自ブレードの優先度を取得し、管理テーブル３０２ａに保持する（ステップＳ１９０１）。次に、ブレード２０１は、他ブレードの管理テーブル３０２ａに保持されている他ブレードの優先度を取得し、メモリ３０２に保持する（ステップＳ１９０２）。

ここで、ブレード２０１は、他ブレードの優先度と自ブレードの優先度が重複しているか否かを判定する（ステップＳ１９０３）。他ブレードの優先度と自ブレードの優先度が重複している場合（ステップＳ１９０３：Ｙｅｓ）、不正な優先度設定であるとして、ブレード２０１は、自ブレードの起動を停止し（ステップＳ１９０５）、ライセンス有効化判定処理を終了する。

他ブレードの優先度と自ブレードの優先度が重複していない場合（ステップＳ１９０３：Ｎｏ）、ブレード２０１は、優先度（ｃｏｍｐ）を算出する（ステップＳ１９０４）。ステップＳ１９０４については図２１において後述する。

次に、ブレード２０１は、自ブレードのライセンスのステータスを無効（判定中）に設定する（ステップＳ１９０６）。ただし、ライセンス有効化判定処理に入る前にライセンスが有効であった場合は自ブレードのライセンスのステータスを有効（判定中）に設定する。

ここで、ブレード２０１は、自ブレードの管理テーブル３０２ａにライセンスキーが保持されているか判定する（ステップＳ１９０７）。自ブレードの管理テーブル３０２ａにライセンスキーが保持されている場合（ステップＳ１９０７：Ｙｅｓ）、図２０のステップＳ２００１に進む。

自ブレードの管理テーブル３０２ａにライセンスキーが保持されていない場合（ステップＳ１９０７：Ｎｏ）、ブレード２０１は、他ブレードの管理テーブル３０２ａにライセンスキーが保持されているか判定する（ステップＳ１９０８）。他ブレードの管理テーブル３０２ａにライセンスキーが保持されている場合（ステップＳ１９０８：Ｙｅｓ）、ブレード２０１は、他ブレードの管理テーブル３０２ａからライセンスキーを取得し、取得したライセンスキーを自ブレードの管理テーブル３０２ａに保持し（ステップＳ１９０９）、図２０のステップＳ２００１に進む。

他ブレードの管理テーブル３０２ａにライセンスキーが保持されていない場合（ステップＳ１９０８：Ｎｏ）、ブレード２０１は、ライセンスキーを受信したか判定する（ステップＳ１９１０）。ライセンスキーを受信していない場合（ステップＳ１９１０：Ｎｏ）、ステップＳ１９１０に戻る。ライセンスキーを受信した場合（ステップＳ１９１０：Ｙｅｓ）、図２０のステップＳ２００１に進む。

図２０は、実施例２にかかる優先度（ｃｏｍｐ）を使用したライセンス有効化（図６のステップＳ６０６〜ステップＳ６０９）の詳細を示すフローチャート（その２）である。図２０においてブレード２０１は、管理ユニット２０２から筐体固有情報を取得し、管理テーブル３０２ａに保持する（ステップＳ２００１）。また、ブレード２０１は、ライセンスキーを復号して筐体固有情報と使用可能数を取得し、管理テーブル３０２ａに保持する（ステップＳ２００２）。

そして、ブレード２０１は、復号した筐体固有情報と取得した筐体固有情報とが一致するか判定する（ステップＳ２００３）。復号した筐体固有情報と取得した筐体固有情報とが一致しない場合（ステップＳ２００３：Ｎｏ）、不正なライセンスであるとして、ブレード２０１は、自ブレードの起動を停止し（ステップＳ１９０５）、ライセンス有効化判定処理を終了する。復号した筐体固有情報と取得した筐体固有情報とが一致する場合（ステップＳ２００３：Ｙｅｓ）、正式なライセンスであるとしてステップＳ２００４に進む。

そして、ブレード２０１は、自ブレードの故障ビットが立っているか判定する（ステップＳ２００４）。自ブレードの故障ビットが立っている場合（ステップＳ２００４：Ｙｅｓ）、自ブレードは故障しているものとして、ブレード２０１は、ライセンスを無効（判定済）に設定し（ステップＳ２００７）、ライセンス有効化判定処理を終了し、通常運用状態に移行する。自ブレードの故障ビットが立っていない場合（ステップＳ２００４：Ｎｏ）、自ブレードは通常運用状態であるとして、ステップＳ２００５へ進む。

次に、ブレード２０１は、自ブレードの管理テーブル３０２ａに保持されている使用可能数≧優先度（ｃｏｍｐ）であるかを判定する（ステップＳ２００５）。使用可能数≧優先度（ｃｏｍｐ）でない場合（ステップＳ２００５：Ｎｏ）、ブレード２０１は、ライセンスを無効（判定済）に設定し（ステップＳ２００７）、ライセンス有効化判定処理を終了し、通常運用状態に移行する。使用可能数≧優先度（ｃｏｍｐ）である場合（ステップＳ２００５：Ｙｅｓ）、ブレード２０１は、ライセンスを有効（判定済）に設定し（ステップＳ２００６）、ライセンス有効化判定処理を終了し、通常運用状態に移行する。

ライセンス有効化判定処理によって、ブレード２０１は、使用可能数の範囲内であればライセンスを有効化することができる。

なお、ライセンス有効化判定処理は、ブレード２０１の初めの電源投入時に行われるが、ブレード２０１の増設・交換時をトリガとしてこの処理を行ってもよいし、故障検出時をトリガとしてライセンス有効化判定処理を行ってもよい。その際、全ブレードがこの処理を行ってもよいし、増設・交換したブレード２０１より優先度が低いブレード２０１のみライセンス有効化判定処理を行ってもよい。また、不正防止のために一定の時間間隔でライセンス有効化判定処理を繰り返し行ってもよい。

ここで、図１９のステップＳ１９０４の優先度（ｃｏｍｐ）を算出する処理について説明する。なお、優先度（ｃｏｍｐ）とは、故障中のブレードを除いた全ブレード中で、自ブレードの優先度が上位から何番目かを示している。なお、ここでは、数字の小さい優先度のブレード２０１が優先してライセンスを有効化することとする。よって、各ブレードの優先度を降順にソートした場合の序列が優先度（ｃｏｍｐ）である。

図２１は、図１９のステップＳ１９０４に示した優先度（ｃｏｍｐ）の算出の流れを示すフローチャートである。まず、ブレード２０１は、自ブレードが故障中であるか判断する（ステップＳ２１０１）。自ブレードが故障中の場合（ステップＳ２１０１：Ｙｅｓ）、優先度（ｃｏｍｐ）を算出する処理を終了する。

自ブレードが故障中でない場合（ステップＳ２１０１：Ｎｏ）、ブレード２０１は、故障中のブレード２０１を除く他ブレードの優先度を取得する（ステップＳ２１０２）。ブレード２０１は、管理テーブル３０２ａに保持されている自ブレードの優先度と取得した他ブレードの優先度とを降順にソートして、その序列を、自ブレードの優先度（ｃｏｍｐ）として算出する（ステップＳ２１０３）。

ブレード２０１は、算出した自ブレードの優先度（ｃｏｍｐ）を管理テーブル３０２ａに保持する（ステップＳ２１０４）。そして、優先度（ｃｏｍｐ）を算出する処理を終了する。優先度（ｃｏｍｐ）を算出する処理によって、ブレード２０１は、自ブレードの優先度（ｃｏｍｐ）を算出することができる。次に、図２２を用いて、この処理によって優先度（ｃｏｍｐ）を算出した場合の具体例について説明する。

これにより、優先度の高いブレード２０１の処理を待たずに、各ブレードは、筐体内での使用可能数の範囲内であればライセンスを有効化することができる。また、ブレード２０１の交換・増設・故障時に、優先度に従って自動でライセンスを有効化／無効化することができる。

図２２は、優先度（ｃｏｍｐ）算出の具体例を示す説明図である。図２２に示すように、例えば、筐体２００に４つのブレード２０１が差し込まれているとする。それぞれのブレード２０１をブレード１〜４とする。ここで、ブレード１は優先度２に設定され、ブレード２は優先度９に設定され、ブレード３は優先度５に設定され、ブレード４は優先度６に設定されているとする。また、ブレード４は故障中である（故障ビットが立っている）。

通常運用状態のブレード１〜３は、それぞれ、故障中のブレード４を除く他ブレードの優先度を取得する。ここで、これらの優先度を降順にソートすると、「優先度２（ブレード１）、優先度５（ブレード３）、優先度９（ブレード２）」となる。ブレード１〜３は、それぞれ、このソート結果に基づいて、優先度（ｃｏｍｐ）を算出し管理テーブル３０２ａに保持する。

即ち、ブレード１の序列は１番目であるから、ブレード１は、優先度（ｃｏｍｐ）を１として自ブレードの管理テーブル３０２ａに保持する。また、ブレード２の序列は３番目であるから、ブレード２は、優先度（ｃｏｍｐ）を３として自ブレードの管理テーブル３０２ａに保持する。そして、ブレード３の序列は２番目であるから、ブレード３は、優先度（ｃｏｍｐ）を２として自ブレードの管理テーブル３０２ａに保持する。一方、故障中のブレード４は、優先度（ｃｏｍｐ）を算出しない。

次に、通常運用状態に移行した後、ブレードに故障が発生した場合の処理について説明する。実施例２においても、図１０に示した故障検出の処理によって、ブレード２０１は、自ブレードの故障を検出する。

なお、故障検出をトリガに全ブレードがライセンス有効化判定処理を行うようにしてもよい。例えば、故障したブレード２０１が他ブレードに対して故障検出の通知を行い、故障したブレード２０１と通知を受けたブレード２０１とがライセンス有効化判定処理を行うようにする。この際、故障したブレード２０１と故障したブレード２０１の下位ブレードとのみライセンス有効化判定処理を行うようにしてもよい。これにより、故障したブレード２０１の上位ブレードではライセンス有効化判定処理による負担がなくなる。また、故障検出時にディスプレイ（不図示）に故障発生のアナウンスを表示して、ユーザにブレード２０１の交換の必要性を通知するようにしてもよい。また、ミドルウェアを用いて故障発生時のブレード２０１の切り替え先を設定しておき、切り替え先と切り替え元の２つのブレード２０１のみライセンス有効化判定処理を行うようにしてもよい。

一度ライセンス有効化判定処理を行ったブレード２０１で、再度ライセンス有効化判定処理を行う場合は、既にブレード２０１の管理テーブル３０２ａに優先度とライセンスキーが保持されている。よって、ブレード２０１が、図２０のステップＳ２００１からライセンス有効化判定処理を始めるようにしてもよい。これにより、ライセンス有効化判定処理が高速化する。ここで、図２３〜図２８を用いて、実施例２の具体例について説明する。

図２３〜図２８は、実施例２の具体例を示す説明図である。まず、図２３において、筐体２００に、ブレード１が差し込まれたとする。ここで、ブレード１は、（１）優先度設定ＳＷ３０４によって設定された優先度を管理テーブル３０２ａに保持する。次に、ブレード１は、（２）優先度（ｃｏｍｐ）を算出する。ここでは、他ブレードがないため、ブレード１は、優先度（ｃｏｍｐ）を１として管理テーブル３０２ａに保持する。

次に、ブレード１は、（３）自ブレードの管理テーブル３０２ａにライセンスキーが保持されていないため、他ブレードからライセンスキーを取得しようとする。しかし、（４）他ブレードがなく、他ブレードからライセンスキーを取得できない。よって、（５）ユーザからライセンスキーが入力されるのを待つ。ここでは、管理ユニット２０２からライセンスキーが入力されたとする。

そして、ブレード１は、（６）管理ユニット２０２から筐体固有情報を受信する。ここで、ブレード１は、ライセンスキーを復号して、筐体固有情報と使用可能数を取得する。そして、ブレード１は、（７）受信した筐体固有情報と復号した筐体固有情報とが一致するため、管理テーブル３０２ａに保持されているライセンスキーは正当なライセンスキーであると判断して次の処理に進む。

次に、ブレード１は、使用可能数と優先度（ｃｏｍｐ）を比較する。ここで、（８）使用可能数は２であり、優先度（ｃｏｍｐ）は１であるから、まだライセンスは有効化できると判断する。そして、ブレード１は、（９）ライセンスを有効化する。

次に、筐体２００に、新たにブレード２が差し込まれたとする。ここでは、ブレード２０１の増設に伴い全ブレードがライセンス有効化判定処理を行うとする。

図２４において、各ブレードは、（１０）優先度設定ＳＷ３０４によって設定された優先度を管理テーブル３０２ａに保持する。次に、各ブレードは、（１１）他ブレードから優先度を取得し、メモリ３０２に保持する。そして、各ブレードは、（１２）優先度（ｃｏｍｐ）を算出する。ここでは、ブレード１の優先度が１であり、ブレード２の優先度が３であるから、ブレード１の優先度（ｃｏｍｐ）は１となり、ブレード２の優先度（ｃｏｍｐ）は２となる。各ブレードは、この優先度（ｃｏｍｐ）を管理テーブル３０２ａに保持する。

次に、ブレード２は、（１３）自ブレードの管理テーブル３０２ａにライセンスキーが保持されていないため、（１４）他ブレード（ここではブレード１）からライセンスキーを取得しようとする。（１５）ブレード２は、ブレード１からライセンスキーを受信し管理テーブル３０２ａに保持する。

そして、各ブレードは、（１６）管理ユニット２０２から筐体固有情報を受信する。ここで、各ブレードは、ライセンスキーを復号して、筐体固有情報と使用可能数を取得する。そして、各ブレードは、（１７）受信した筐体固有情報と復号した筐体固有情報とが一致するため、管理テーブル３０２ａに保持されているライセンスキーは正当なライセンスキーであると判断して次の処理に進む。

図２５において、各ブレードは、使用可能数と優先度（ｃｏｍｐ）を比較する。ここで、（１８）ブレード１では、使用可能数は２であり、優先度（ｃｏｍｐ）は１であるから、まだライセンスは有効化できると判断する。また、ブレード２では、使用可能数は２であり、優先度（ｃｏｍｐ）は２であるから、まだライセンスは有効化できると判断する。そして、各ブレードは、（１９）ライセンスを有効化する。

次に、筐体２００に、新たにブレード３が差し込まれたとする。ここでは、ブレード２０１の増設に伴い全ブレードがライセンス有効化判定処理を行うとする。

ここで、各ブレードは、（２０）優先度設定ＳＷ３０４によって設定された優先度を管理テーブル３０２ａに保持する。次に、各ブレードは、（２１）他ブレードから優先度を取得し、メモリ３０２に保持する。そして、各ブレードは、（２２）優先度（ｃｏｍｐ）を算出する。ここでは、ブレード１の優先度が１であり、ブレード２の優先度が３であり、ブレード３の優先度が２であるから、ブレード１の優先度（ｃｏｍｐ）は１となり、ブレード２の優先度（ｃｏｍｐ）は３となり、ブレード３の優先度（ｃｏｍｐ）は２となる。各ブレードは、この優先度（ｃｏｍｐ）を管理テーブル３０２ａに保持する。

次に、ブレード３は、（２３）自ブレードの管理テーブル３０２ａにライセンスキーが保持されていないため、（２４）他ブレード（ここではブレード１）からライセンスキーを取得しようとする。（２５）ブレード３は、ブレード１からライセンスキーを受信し管理テーブル３０２ａに保持する。

図２６において、各ブレードは、（２６）管理ユニット２０２から筐体固有情報を受信する。ここで、各ブレードは、ライセンスキーを復号して、筐体固有情報と使用可能数を取得する。そして、各ブレードは、（２７）受信した筐体固有情報と復号した筐体固有情報とが一致するため、管理テーブル３０２ａに保持されているライセンスキーは正当なライセンスキーであると判断して次の処理に進む。

次に、各ブレードは、使用可能数と優先度（ｃｏｍｐ）を比較する。ここで、（２８）ブレード１では、使用可能数は２であり、優先度（ｃｏｍｐ）は１であるから、まだライセンスは有効化できると判断する。また、ブレード２では、使用可能数は２であり、優先度（ｃｏｍｐ）は３であるから、ライセンスは有効化できないと判断する。さらに、ブレード３では、使用可能数は２であり、優先度（ｃｏｍｐ）は２であるから、まだライセンスは有効化できると判断する。そして、（２９）ブレード１，３は、ライセンスを有効化し、ブレード２は、ライセンスを無効化する。

ここで、ブレード１に故障が発生した場合について説明する。ここでは、ブレード２０１の故障発生に伴い全ブレードがライセンス有効化判定処理を行うとする。

図２７において、ブレード１は、（３０）故障を検出すると、故障ビットを１にセットして管理テーブル３０２ａに保持する。また、ブレード１は、故障検出を他ブレードに通知する。そして、故障を検出したブレード１と、故障検出の通知を受けたブレード２とブレード３はライセンス有効化処理を開始する。

ここで、各ブレードは、（３１）優先度設定ＳＷ３０４によって設定された優先度を管理テーブル３０２ａに保持する。次に、各ブレードは、（３２）他ブレードから優先度を取得し、メモリ３０２に保持する。そして、（３３）優先度（ｃｏｍｐ）を算出する。ここでは、ブレード１の優先度が１であり、ブレード２の優先度が３であり、ブレード３の優先度が２であるが、故障したブレード１を除いて優先度（ｃｏｍｐ）を算出する。即ち、ブレード１の優先度（ｃｏｍｐ）はなしであり、ブレード２の優先度（ｃｏｍｐ）は２となり、ブレード３の優先度（ｃｏｍｐ）は１となる。各ブレードは、この優先度（ｃｏｍｐ）を管理テーブル３０２ａに保持する。

各ブレードは、ライセンスキーを保持しているため、そのまま次の処理に進む。そして、各ブレードは、（３４）管理ユニット２０２から筐体固有情報を受信する。ここで、各ブレードは、ライセンスキーを復号して、筐体固有情報と使用可能数を取得する。そして、（３５）受信した筐体固有情報と復号した筐体固有情報とが一致するため、正当なライセンスキーと判断して次の処理に進む。

図２８において、各ブレードは、使用可能数と優先度（ｃｏｍｐ）を比較する。ここで、（３６）ブレード１では、故障ビットが立っているから、ライセンスを無効化すると判断する。また、ブレード２では、使用可能数は２であり、優先度（ｃｏｍｐ）は２であるから、まだライセンスは有効化できると判断する。さらに、ブレード３では、使用可能数は２であり、優先度（ｃｏｍｐ）は１であるから、まだライセンスは有効化できると判断する。そして、（３７）ブレード２，３は、ライセンスを有効化し、ブレード１は、ライセンスを無効化する。

このように、ブレード２０１の増設・故障時に、優先度に従って自動でライセンスを有効化／無効化することができる。

図２９は、実施例１および実施例２の実用例を示す説明図（その１）である。ここでは、数字の小さい優先度のブレード２０１が優先してライセンスを有効化することとする。また、各ブレード２０１は優先度設定ＳＷ３０４によって優先度が設定されている。

図２９は、運用系のブレード２０１と待機系のブレード２０１を用意し、故障発生時に待機系のブレード２０１にライセンスが引き継がれるようにした例である。ここでは、ブレード２０１は４つであり、使用可能数は２である。それぞれのブレード２０１を、ブレード１〜４とする。また、運用系であるブレード１とブレード３の優先度を高く設定している。

そのため、（Ａ）のように、通常は運用系のブレード１，３がライセンス有効化されている。一方、（Ｂ）のように、運用系のブレード１が故障した場合には、自動的に待機系のブレード２にライセンスが引き継がれるため、円滑な保守が可能となる。

図３０は、実施例１および実施例２の実用例を示す説明図（その２）である。ここでは、数字の小さい優先度のブレード２０１が優先してライセンスを有効化することとする。また、各ブレードは優先度設定ＳＷ３０４によって優先度が設定されている。

図３０は、本番系のブレード２０１と開発系のブレード２０１を用意し、開発完了に伴って本番系のブレード２０１を使用するようにした例である。ここでは、ブレードは４つであり、使用可能数は１である。それぞれのブレード２０１をブレード１〜４とする。また、本番系のブレード１〜３の優先度を高く設定し、開発系のブレード４の優先度を低く設定している。そのため、（Ａ）のように本番系のブレード１〜３は、まだ開発完了していない時点ではライセンス有効となっていないが、（Ｂ）のように、開発完了に伴い自動的にライセンスが引き継がれるため、円滑な保守が可能となる。

また、上述した実施例２では、各ブレードが優先度（ｃｏｍｐ）を算出することで、ソフトウェアまたはソフトウェアのオプション機能を使用可能か判断する。そのため、他ブレードのライセンス有効化判定処理の終了を待たずにライセンスを有効化してソフトウェアまたはソフトウェアのオプション機能を使用できる。また、優先度（ｃｏｍｐ）を用いることで、使用可能数を使用数が超えないようにしているため、使用可能数の範囲内ならどのブレード２０１でも自由にライセンスを有効化してソフトウェアまたはソフトウェアのオプション機能を使用できる。

そして、各ブレードが相互に使用数を監視するため、外部にライセンス管理用ユニットを設置する必要がなくコストを削減できる。さらに、各ブレードが相互に使用数を監視するため、ライセンス管理用ユニットの不正改造によってソフトウェアまたはソフトウェアのオプション機能を不正使用される虞もなくなる。そして、外部にライセンス管理用ユニットを設置する必要がないため、ライセンス管理用ユニットの故障による業務停止を防止できる。

さらに、ライセンスキーを筐体固有情報にロックしたため、バス２０３からブレード２０１を切り離すことによる、ソフトウェアまたはソフトウェアのオプション機能の不正使用を防止することができる。

また、上述した実施例２では、故障を検出した場合に、ライセンス有効化判定処理を再度行い、故障したブレード２０１のライセンスが無効化されるようにしたので、速やかな保守が自動的に行えるようになる。

なお、本実施の形態で説明した管理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本管理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本管理プログラムは、インターネット等のネットワークを介して配布することとしてもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）ブレードサーバの筐体に着脱可能なブレードであって、
対象ソフトウェアの機能を使用可能な数を示す第１のライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信手段と、
前記筐体から前記筐体に固有な識別情報を取得する取得手段と、
前記受信手段によって受信された識別情報と前記取得手段によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記第１のライセンス数と、前記対象ソフトウェアの機能を用いている前記ブレードサーバ内のブレード数を示す第２のライセンス数とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断手段と、
前記判断手段によって対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に設定する設定手段と、
自ブレードが前記設定手段によって設定された場合、前記第２のライセンス数を更新する更新手段と、
前記第１のライセンス数と前記更新手段による更新後の第２のライセンス数とを、前記ブレードサーバ内のブレードのうち前記対象ソフトウェアの機能が未設定のブレードに送信する送信手段と、
を備えることを特徴とするブレード。

（付記２）前記受信手段は、
前記対象ソフトウェアの機能が設定済みのブレードが前記ブレードサーバに存在しない場合、前記第１のライセンス数の発行元から前記第１のライセンス数を受信することを特徴とする付記１に記載のブレード。

（付記３）前記送信手段は、
前記ブレードサーバ内のブレードに設定されている優先度に基づいて、前記第１および第２のライセンス数を、前記対象ソフトウェアの機能が未設定のブレードのうち、自ブレードの次の優先度となるブレードに送信することを特徴とする付記１に記載のブレード。

（付記４）前記送信手段は、
前記ブレードサーバ内のブレードに設定されている優先度に基づいて、前記第１および第２のライセンス数を、前記対象ソフトウェアの機能が未設定のブレードのうち、自ブレードの次の優先度となるブレードに送信することを特徴とする付記２に記載のブレード。

（付記５）ブレードサーバの筐体に着脱可能なブレードであって、
対象ソフトウェアの機能を使用可能な数を示すライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信手段と、
前記筐体から前記筐体に固有な識別情報を取得し、前記筐体内の各ブレードに設定されている優先度を前記各ブレードから取得する取得手段と、
前記取得手段によって取得された自ブレードの優先度を、１から始まる連続番号のうち、自ブレードの優先度に応じた番号に変換する変換手段と、
前記受信手段によって受信された識別情報と前記取得手段によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記ライセンス数と前記変換手段によって変換された自ブレードに対応する番号とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断手段と、
前記判断手段によって前記対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に自ブレードを設定する設定手段と、
を備えることを特徴とするブレード。

（付記６）自ブレードの故障を検出する検出手段を備え、
前記設定手段は、
前記検出手段によって故障が検出された場合、前記判断手段による判断をおこなうことなく、前記対象ソフトウェアの機能を実行不能な状態に設定する付記１〜５のいずれか一つに記載のブレード。

（付記７）ブレードサーバの筐体に着脱可能なブレードに、
対象ソフトウェアの機能を使用可能な数を示す第１のライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信工程と、
前記筐体から前記筐体に固有な識別情報を取得する取得工程と、
前記受信工程によって受信された識別情報と前記取得工程によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記第１のライセンス数と、前記対象ソフトウェアの機能を用いている前記ブレードサーバ内のブレード数を示す第２のライセンス数とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断工程と、
前記判断工程によって対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に設定する設定工程と、
自ブレードが前記設定工程によって設定された場合、前記第２のライセンス数を更新する更新工程と、
前記第１のライセンス数と前記更新工程による更新後の第２のライセンス数とを、前記ブレードサーバ内のブレードのうち前記対象ソフトウェアの機能が未設定のブレードに送信する送信工程と、
を実行させることを特徴とする管理プログラム。

（付記８）ブレードサーバの筐体に着脱可能なブレードに、
対象ソフトウェアの機能を使用可能な数を示すライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信工程と、
前記筐体から前記筐体に固有な識別情報を取得し、前記筐体内の各ブレードに設定されている優先度を前記各ブレードから取得する取得工程と、
前記取得工程によって取得された自ブレードの優先度を、１から始まる連続番号のうち、自ブレードの優先度に応じた番号に変換する変換工程と、
前記受信工程によって受信された識別情報と前記取得工程によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記ライセンス数と前記変換工程によって変換された自ブレードに対応する番号とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断工程と、
前記判断工程によって前記対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に自ブレードを設定する設定工程と、
を実行させることを特徴とする管理プログラム。

（付記９）ブレードサーバの筐体に着脱可能なブレードが、
対象ソフトウェアの機能を使用可能な数を示す第１のライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信工程と、
前記筐体から前記筐体に固有な識別情報を取得する取得工程と、
前記受信工程によって受信された識別情報と前記取得工程によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記第１のライセンス数と、前記対象ソフトウェアの機能を用いている前記ブレードサーバ内のブレード数を示す第２のライセンス数とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断工程と、
前記判断工程によって対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に設定する設定工程と、
自ブレードが前記設定工程によって設定された場合、前記第２のライセンス数を更新する更新工程と、
前記第１のライセンス数と前記更新工程による更新後の第２のライセンス数とを、前記ブレードサーバ内のブレードのうち前記対象ソフトウェアの機能が未設定のブレードに送信する送信工程と、
を実行することを特徴とする管理方法。

（付記１０）ブレードサーバの筐体に着脱可能なブレードが、
対象ソフトウェアの機能を使用可能な数を示すライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信工程と、
前記筐体から前記筐体に固有な識別情報を取得し、前記筐体内の各ブレードに設定されている優先度を前記各ブレードから取得する取得工程と、
前記取得工程によって取得された自ブレードの優先度を、１から始まる連続番号のうち、自ブレードの優先度に応じた番号に変換する変換工程と、
前記受信工程によって受信された識別情報と前記取得工程によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記ライセンス数と前記変換工程によって変換された自ブレードに対応する番号とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断工程と、
前記判断工程によって前記対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に自ブレードを設定する設定工程と、
を実行することを特徴とする管理方法。

２００ 筐体
２０１ ブレード
２０２ 管理ユニット
３０１ ＣＰＵ
３０２ メモリ
３０２ａ 管理テーブル
３０４ 優先度設定ＳＷ
７０１ 受信部
７０２ 取得部
７０３ 判断部
７０４ 設定部
７０５ 更新部
７０６ 送信部
７０７ 検出部
１８０１ 受信部
１８０２ 取得部
１８０３ 変換部
１８０４ 判断部
１８０５ 設定部
１８０６ 検出部

Claims (9)

1. ブレードサーバの筐体に着脱可能なブレードであって、
   対象ソフトウェアの機能を使用可能な数を示す第１のライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信手段と、
   前記筐体から前記筐体に固有な識別情報を取得する取得手段と、
   前記受信手段によって受信された識別情報と前記取得手段によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記第１のライセンス数と、前記対象ソフトウェアの機能を用いている前記ブレードサーバ内のブレード数を示す第２のライセンス数とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断手段と、
   前記判断手段によって対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に設定する設定手段と、
   自ブレードが前記設定手段によって設定された場合、前記第２のライセンス数を更新する更新手段と、
   前記第１のライセンス数と前記更新手段による更新後の第２のライセンス数とを、前記ブレードサーバ内のブレードのうち前記対象ソフトウェアの機能が未設定のブレードに送信する送信手段と、
   を備えることを特徴とするブレード。
2. 前記受信手段は、
   前記対象ソフトウェアの機能が設定済みのブレードが前記ブレードサーバに存在しない場合、前記第１のライセンス数の発行元から前記第１のライセンス数を受信することを特徴とする請求項１に記載のブレード。
3. 前記送信手段は、
   前記ブレードサーバ内のブレードに設定されている優先度に基づいて、前記第１および第２のライセンス数を、前記対象ソフトウェアの機能が未設定のブレードのうち、自ブレードの次の優先度となるブレードに送信することを特徴とする請求項１に記載のブレード。
4. 前記送信手段は、
   前記ブレードサーバ内のブレードに設定されている優先度に基づいて、前記第１および第２のライセンス数を、前記対象ソフトウェアの機能が未設定のブレードのうち、自ブレードの次の優先度となるブレードに送信することを特徴とする請求項２に記載のブレード。
5. ブレードサーバの筐体に着脱可能なブレードであって、
   対象ソフトウェアの機能を使用可能な数を示すライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信手段と、
   前記筐体から前記筐体に固有な識別情報を取得し、前記筐体内の各ブレードに設定されている優先度を前記各ブレードから取得する取得手段と、
   前記取得手段によって取得された自ブレードの優先度を、１から始まる連続番号のうち、自ブレードの優先度に応じた番号に変換する変換手段と、
   前記受信手段によって受信された識別情報と前記取得手段によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記ライセンス数と前記変換手段によって変換された自ブレードに対応する番号とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断手段と、
   前記判断手段によって前記対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に自ブレードを設定する設定手段と、
   を備えることを特徴とするブレード。
6. 自ブレードの故障を検出する検出手段を備え、
   前記設定手段は、
   前記検出手段によって故障が検出された場合、前記判断手段による判断をおこなうことなく、前記対象ソフトウェアの機能を実行不能な状態に設定する請求項１〜５のいずれか一つに記載のブレード。
7. ブレードサーバの筐体に着脱可能なブレードに、
   対象ソフトウェアの機能を使用可能な数を示す第１のライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信工程と、
   前記筐体から前記筐体に固有な識別情報を取得する取得工程と、
   前記受信工程によって受信された識別情報と前記取得工程によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記第１のライセンス数と、前記対象ソフトウェアの機能を用いている前記ブレードサーバ内のブレード数を示す第２のライセンス数とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断工程と、
   前記判断工程によって対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に設定する設定工程と、
   自ブレードが前記設定工程によって設定された場合、前記第２のライセンス数を更新する更新工程と、
   前記第１のライセンス数と前記更新工程による更新後の第２のライセンス数とを、前記ブレードサーバ内のブレードのうち前記対象ソフトウェアの機能が未設定のブレードに送信する送信工程と、
   を実行させることを特徴とする管理プログラム。
8. ブレードサーバの筐体に着脱可能なブレードに、
   対象ソフトウェアの機能を使用可能な数を示すライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信工程と、
   前記筐体から前記筐体に固有な識別情報を取得し、前記筐体内の各ブレードに設定されている優先度を前記各ブレードから取得する取得工程と、
   前記取得工程によって取得された自ブレードの優先度を、１から始まる連続番号のうち、自ブレードの優先度に応じた番号に変換する変換工程と、
   前記受信工程によって受信された識別情報と前記取得工程によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記ライセンス数と前記変換工程によって変換された自ブレードに対応する番号とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断工程と、
   前記判断工程によって前記対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に自ブレードを設定する設定工程と、
   を実行させることを特徴とする管理プログラム。
9. ブレードサーバの筐体に着脱可能なブレードが、
   対象ソフトウェアの機能を使用可能な数を示す第１のライセンス数および前記筐体に固有な識別情報を前記筐体内の他ブレードから受信する受信工程と、
   前記筐体から前記筐体に固有な識別情報を取得する取得工程と、
   前記受信工程によって受信された識別情報と前記取得工程によって取得された識別情報とが一致するか否かを判断し、一致すると判断された場合、前記第１のライセンス数と、前記対象ソフトウェアの機能を用いている前記ブレードサーバ内のブレード数を示す第２のライセンス数とを比較することにより、前記対象ソフトウェアの機能が使用可能か否かを判断する判断工程と、
   前記判断工程によって対象ソフトウェアの機能が使用可能と判断された場合、前記対象ソフトウェアの機能を実行可能な状態に設定する設定工程と、
   自ブレードが前記設定工程によって設定された場合、前記第２のライセンス数を更新する更新工程と、
   前記第１のライセンス数と前記更新工程による更新後の第２のライセンス数とを、前記ブレードサーバ内のブレードのうち前記対象ソフトウェアの機能が未設定のブレードに送信する送信工程と、
   を実行することを特徴とする管理方法。

Images