(57)【要約】【課題】従来は、アプリケーションプログラムの能力向上には、人手を介したベンダとの交渉や、ライセンスキーの入手などが必要であったため、業務処理の観点からは短時間に能力を向上する事ができなかった。【解決手段】ＣＯＤの発動を契機として、ソフトウェアベンダに対してもＣＯＤの発動を通知する。ＣＯＤの発動通知を受けたソフトウェアベンダは顧客の計算機に対して自動的に新しい構成で動作するためのライセンスキーを送信する事により、短時間での業務処理能力の向上を実現する。また、アプリケーション使用料の支払いが滞った場合には、アプリケーションベンダから制限付きのライセンスキーを送り込み、不正使用を防ぐ事ができる。さらに顧客システムではライセンスキーをを受け取った契機で、アプリケーション自体に通知を行う事で、アプリケーション動作中に動的に処理能力を向上させる手段を提供する。【選択図】　図１
2004086392.tif 000002
【特許請求の範囲】
【請求項１】
構成を変更可能な計算機システムと、該計算機のハードウェア構成に応じて課金を行うハードウェア管理システムと、該計算機のプログラム構成に応じて課金を行うプログラム管理システムとを備えた計算機構成変更システムにおいて、
上記計算機システムは、構成変更を所望する上記計算機システムのハードウェア構成とプログラム構成とを含む構成変更要求を入力した場合は、該構成変更するハードウェアの課金を変更するために上記構成変更するハードウェア構成情報を上記ハードウェア管理システムへ送り、該構成変更するプログラムの課金を変更するために上記構成変更するハードウェア構成情報と上記構成変更するプログラム構成情報を上記プログラム管理システムへ送り、
上記ハードウェア管理システムは、上記構成変更するハードウェア構成情報を入力すると、該ハードウェア構成情報に基づいて該ハードウェアに対する課金を変更して上記計算機に該ハードウェアの課金情報を送り、
上記プログラム管理システムは、上記構成変更するハードウェア構成情報と上記構成変更するプログラム構成情報とを入力すると、該ハードウェア構成情報と該プログラム構成に基づいて該プログラムに対する課金を変更して上記計算機に該プログラムの課金情報を送り
上記計算機は、上記ハードウェアの課金情報と上記プログラムの課金情報を入力した場合、上記構成変更するハードウェア構成情報に基づいてハードウェア構成を変更し、上記構成変更するプログラム構成情報に基づいてプログラム構成を変更することを特徴とする計算機構成変更システム。
【請求項２】
上記計算機の構成はライセンスキーで管理されており、上記プログラム管理システムから送られた課金情報に含まれるライセンスキーに基づいて該構成を変更する手段を備えたことを特徴とする請求項１記載の計算機構成変更システム。
【請求項３】
上記変更する構成変更を行う場合、上記ライセンスキーに含まれる有効期限に基づいて決定する手段を備えたことを特徴とする請求項２記載の計算機構成変更システム。
【請求項４】
上記構成変更を行う場合、上記送られた課金情報とハードウェア構成およびプログラム構成との一致を判定し、一致しない場合は上記構成変更を行わない手段を備えたことを特徴とする請求項１記載の計算機構成変更システム。
【請求項５】
上記構成変更を行う場合、上記構成変更するハードウェア構成に基づいて上記プログラム構成を変更する手段を備えたことを特徴とする請求項１記載の計算機構成変更システム。
【請求項６】
計算機のハードウェアの構成情報を含むハードウェア構成情報と該ハードウェアのハードウェア契約更改通知先と、上記計算機のプログラムの構成情報と該プログラムのプログラム契約更改通知先とを記憶し、
構成変更を所望する上記計算機のハードウェア構成とプログラム構成とを含むハードウェア構成変更要求を受け付けた場合は、該構成変更するハードウェアの課金を変更するために上記ハードウェア契約更改通知先へ上記構成変更するハードウェア構成情報を上記ハードウェア契約更改通知先へ送り、該構成変更するプログラムの課金を変更するために上記プログラム契約更改通知先へ上記構成変更するハードウェア構成情報と上記構成変更するプログラム構成情報を上記プログラム契約更改通知先へ送り、
上記プログラム契約更改通知先から送られたライセンス情報を入力した場合、上記構成変更するハードウェア構成情報に基づいてハードウェア構成を変更し、上記構成変更するハードウェア構成情報と上記構成変更するプログラム構成情報に基づいてプログラム構成を変更することを特徴とする計算機構成変更方法。
【請求項７】
上記計算機の構成はライセンスキーで管理されており、上記プログラム管理システムから送られた課金情報に含まれるライセンスキーに基づいて該構成を変更することを特徴とする請求項６記載の計算機構成変更方法。
【請求項８】
上記変更する構成変更を行う場合、上記ライセンスキーに含まれる有効期限に基づいて決定することを特徴とする請求項７記載の計算機構成変更方法。
【請求項９】
上記構成変更を行う場合、上記送られた課金情報とハードウェア構成およびプログラム構成との一致を判定し、一致しない場合は上記構成変更を行わないことを特徴とする請求項７記載の計算機構成変更方法。
【請求項１０】
上記構成変更を行う場合、上記構成変更するハードウェア構成に基づいて上記プログラム構成を変更することを特徴とする請求項７記載の計算機構成変更方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
計算機のハードウェアやプログラムの構成を変更する構成変更技術に関する。
【０００２】
【従来の技術】
一般的にキャパシティーオンデマンド（以下、ＣＯＤと省略して記述）と呼ばれるような計算機の利用・契約の形態では、ハードウェアベンダが計算機システムのハードウェアリソース、例えばＣＰＵ、メモリ、ハードディスク（以下「ＨＤ」と略）などの一部を利用できない状態にして顧客に納入する。この時に顧客では、納入された全てのハードウェアリソースに対して料金を支払う事なく、利用可能な部分の料金を支払い使用する（正確には若干高額になる場合が多い）。顧客が計算機を長い期間利用していくと、業務処理量の増加などによりハードウェアの能力不足に直面する事がある。この時顧客は、それまで利用できなかったＣＰＵなどのハードウェア資源を、顧客の指示により活性化し利用する事ができる。そしてハードウェアベンダに対して活性化した部分の使用料を支払う。
【０００３】
ＣＯＤが利用されるようになる前は、顧客がハードウェアの処理能力を増やしたいと考えた時、ハードウェアベンダによる増設工事や、それに伴う運用の停止が必要であり、時間がかかるという問題があった。一般にＣＯＤのような構成変更技術では、コマンド投入や簡単な装置の設定によりハードウェアを活性化させ、リブートを行うだけでハードウェアが増強された状態になる。実装例は少ないがリブートを必要とせずに能力の向上ができる物も知られている。
【０００４】
ＣＯＤではハードウェアの活性化の指示を行った時に、ハードウェアベンダに対して、ネットワークを通じて「ＣＯＤによるハードウェアの活性化」が発生した事を伝える方法がある。これによりハードウェアベンダでは、計算機使用料をＣＯＤ発動後のハードウェア構成に基づいて請求する事が可能である。また、不正使用を防ぐ為に、ＣＯＤ形態で契約した顧客のシステムがハードウェアベンダとの通信ができない状態になった場合には、全てのハードウェア資源を活性化しているとみなして課金する方法が知られている。
【０００５】
【発明が解決しようとする課題】
従来のＣＯＤでは、ハードウェアの能力増強に関しては、部品の到着や増設工事を待つ必要がない分だけ短時間で増強する事ができた。しかしそのハードウェア上で動作しているプログラムには、以下の２つの問題が発生する事があった。
【０００６】
第１に、ハードウェアリソースの追加により、そのハードウェア上で動作するプログラムがハードウェアリソースの追加による能力向上分を利用できるとは限らない事である。例えばＣＰＵの数だけプロセスを起動して、全てのＣＰＵを同時に使うような並列アプリケーションプログラムを想定した場合、ＣＯＤによりＣＰＵが増えているにも関わらず、アプリケーションプログラムが自動的に全てのＣＰＵを利用するようになる事はなかった。このため顧客は手動でアプリケーションプログラムの停止や再起動、構成定義の変更を行う必要があった。
【０００７】
第２に、不正利用を防ぐために、上記プログラム自身がハードウェア構成を認識し、契約した構成以上のハードウェアの上では動作しないように保護をかけているという問題がある。この保護には一般にライセンスキーと呼ばれるデータが使われる。この場合のライセンスキーは、プログラムに対して実行が許可されているハードウェアの構成を伝える役割を持ち、プログラムはライセンスキーの意味するハードウェア構成の上でのみ動作する実装になっている。例えばＣＰＵの数によって使用料金が変わるプログラムにおいては、実行されている計算機のＣＰＵの数を得て、ライセンスキーに含まれる契約以上のＣＰＵ数の計算機上での動作を停止するプログラムや、ライセンスキーが許す範囲までの実行能力に制限するプログラムがある。このようなプログラムを動作させているシステムで、適切なライセンスキーを入手する前に間違ってＣＰＵを増やしてしまった場合、ライセンスキーを入手するまで業務が行えなくなる等の事態が発生する。また、顧客自身があらかじめＣＯＤ発動後のライセンスキーを入手しておかなければならないと認識していた場合も、ＣＯＤを発動したいと考えた後に、各アプリケーションプログラムベンダに連絡し、料金交渉を行い、ライセンスキーが配布されてくるのを待たなければならないというタイムラグが発生してしまい、ＣＯＤの本来の目的である即時能力拡張が実現できなかった。
【０００８】
つまり現在のＣＯＤは「短時間でのハードウェア増設」だけを実現しており、本質的な課題である「顧客業務に対する処理能力の短時間での増強」を実現できていない。
【０００９】
本発明の目的は、ハードウェアの構成変更を反映したプログラムの能力変更を実現する計算機構成変更方法およびシステムを提供することにある。
【００１０】
【課題を解決するための手段】
本発明では上記課題を改善するために、構成を変更可能な計算機システムと、該計算機のハードウェア構成に応じて課金を行うハードウェア管理システムと、該計算機のプログラム構成に応じて課金を行うプログラム管理システムとを備えた計算機構成変更システムにおいて、以下の処理を行う。
（１）上記計算機システムは、構成変更を所望する上記計算機システムのハードウェア構成とプログラム構成とを含む構成変更要求を入力した場合は、該構成変更するハードウェアの課金を変更するために上記構成変更するハードウェア構成情報を上記ハードウェア管理システムへ送り、該構成変更するプログラムの課金を変更するために上記構成変更するハードウェア構成情報と上記構成変更するプログラム構成情報を上記プログラム管理システムへ送り、
（２）上記ハードウェア管理システムは、上記構成変更するハードウェア構成情報を入力すると、該ハードウェア構成情報に基づいて該ハードウェアに対する課金を変更して上記計算機に該ハードウェアの課金情報を送り、
（３）上記プログラム管理システムは、上記構成変更するハードウェア構成情報と上記構成変更するプログラム構成情報とを入力すると、該ハードウェア構成情報と該プログラム構成に基づいて該プログラムに対する課金を変更して上記計算機に該プログラムの課金情報を送り
（４）上記計算機は、上記ハードウェアの課金情報と上記プログラムの課金情報を入力した場合、上記構成変更するハードウェア構成情報に基づいてハードウェア構成を変更し、上記構成変更するプログラム構成情報に基づいてプログラム構成を変更する
以上により、ハードウェアの構成変更を反映したプログラムの能力変更を実現する計算機構成変更方法およびシステムを実現することができる。
【００１１】
【発明の実施の形態】
図１は発明の全体を示すブロック図である。ＣＯＤでの利用契約を適用した顧客システム１０、ＨＷベンダ２０、ＡＰベンダ３０、３８、３９、がある。本実施例では、ＣＯＤを構成変更要求もしくは能力変更要求の一例として説明しているが、ＣＯＤに限定されるものではなく、構成変更要求もしくは能力変更要求により、ハードウェアやプログラムの構成や能力が変更しても良い。
【００１２】
図２は図１で示したブロックのうち、顧客システム１０、ＨＷベンダ２０、ＡＰベンダ３０の通信がどのような順番で起きるかを示した図であり、以降で説明する処理の流れの概要を示している。ＣＯＤ発動コマンド（構成変更要求もしくは能力変更要求でも良い）が投入されるとＣＯＤ発動指示受付部１１が検出し、ＨＷ−ＣＯＤ発動制御部１２がＨＷベンダ２０内のＣＯＤ発動通知受付部２１にＣＯＤが発動された事を通知する。次にＡＰ−ＣＯＤ発動制御部１４がＡＰベンダ３０内のＣＯＤ発動通知受付部３１にＣＯＤが発動された事を通知する。ＡＰベンダ３０からは顧客システム内のＡＰラインセンス管理部１４にライセンスキーが送信される。しばらく後にＨＷ課金管理部２２とＨＷ料金支払い部１３の間で、料金の請求とそれに対する支払いが行われる。さらにＨＷ料金の支払いと独立して、ＡＰ課金管理部とＡＰ料金支払い制御部の間で、料金の請求とそれに対する支払いが行われる。
【００１３】
図１で、顧客システムで顧客がＣＯＤ発動を指示すると、ＣＯＤ発動指示受付部１１が検出する。ＣＯＤ発動指示受付部１１ではＨＷ−ＣＯＤ発動制御部１２に対して指示を出す。
【００１４】
図３はＨＷ−ＣＯＤ発動制御部１２とＣＯＤ発動通知受付部２１のフローチャートである。まずＨＷ−ＣＯＤ発動制御部１２ではＣＯＤ発動指示受付部１１より指示を受けた後、ステップ１２１でハードウェアの構成を変更する。次にステップ１２２でＨＷベンダ２０に対して、ＣＯＤの発動と、ＣＯＤ発動によりハードウェア構成がどのように変化したかを通知する。
【００１５】
ＨＷベンダ２０では、ステップ１２２によるＣＯＤ発動の通知をＣＯＤ発動通知受付部２１にて受信する。ステップ２１１でＣＯＤの発動情報を受け取った後、ステップ２１２で各顧客システムのハードウェア構成がどのようになっているかを管理しているＣＯＤ−ＤＢ２３に反映する。
【００１６】
図８はＨＷベンダ２０内のＣＯＤ−ＤＢ２３の構造である。顧客システム識別子２３０１に対して、顧客毎、つまり顧客Ａ、顧客Ｘおよび顧客Ｙに対するエントリがそれぞれエントリ２３１０、２３２０および２３３０がある。それぞれの顧客に対して、現在のＣＯＤの発動状況を示すＣＰＵの個数２３０２とメモリ容量２３０３とＨＤ量２３０４と、領収済み料金２３０５が格納されている。また、顧客毎にＣＯＤの発動状況を示す指標であるＣＰＵ２３１２、メモリ２３１３、ＨＤ２３１４の値と、それぞれのＣＯＤの状態に対応した料金２３１５が格納される。顧客Ａについては、現在の契約はＣＰＵ数２ヶ、メモリ容量８ＧＢ、ＨＤ容量１００ＧＢであるため、顧客Ａ契約２３１１から１９００円が使用量となる。図８に示すように課金する項目が顧客Ａ、顧客Ｘおよび顧客Ｙで異なるようにしても良い。
【００１７】
計算機の使用料金の請求は、このＣＯＤ−ＤＢ２３に格納されているＣＯＤ発動状況毎の料金に基づいて課金管理部２２とＨＷ料金支払い部１３の間で行われる。
【００１８】
ＣＯＤによるハードウェアリソースの増減は、一旦リブートをしなければ有効にならない実装をされている事が多いが、リブートを行わずに、リソース量を変更することも可能である。
【００１９】
本発明の特徴は、ＣＯＤの発動通知をＡＰベンダ３０、３８、３９にも行う事である。顧客システム１０にはＣＯＤを発動した場合に発動を通知すべきアプリケーションプログラムのベンダを全て含む通知先一覧１５を保持しており、そこに登録されている全てのベンダに通知する。図１では例としてＡＰベンダを３つ書いているが、３８、３９については内容が３０と同一の為、記述を省略している。以降ではＡＰベンダ３０についてのみ説明を行うが、他のベンダ３８、３９についても同一の内容である。ここでアプリケーションプログラムを一例に説明をするが、本発明は、プログラム一般に適用可能であり、アプリケーションプログラムに限定されるものではない。
【００２０】
ＣＯＤ発動指示受付部１１では、ＣＯＤの発動を検出すると、ＡＰ−ＣＯＤ発動制御部１４にも指示を行う。図４は顧客システム内のＡＰ−ＣＯＤ発動制御部１４と、ＡＰベンダ内のＣＯＤ発動通知受付部３１と、顧客システム内のＡＰライセンス管理部１６のフローチャートである。ＡＰ−ＣＯＤ発動制御部１４ではステップ１４１でＣＯＤ発動時の通知先一覧１５から通知先を得て、ステップ１４２でそれぞれの通知先に、ＣＯＤ発動後のハードウェア構成がどのように変化しているかを通知する。
【００２１】
ＡＰベンダ３０では、ＡＰ−ＣＯＤ発動通知受付部３１で通知を受け付ける。ステップ３１１でＣＯＤが発動された事と発動後のハードウェア構成を受信してから、ステップ３１２で各顧客のハードウェア構成がどのようになっているかを管理しているＣＯＤ−ＤＢ３３に反映する。その後ステップ３１３でＣＯＤの発動状況から対応するライセンスキー１７を生成して、ステップ３１４で顧客システム１０のＡＰライセンス管理部１６に対して送信する。ライセンスキー１７は、ＣＰＵ、メモリ、ＨＤなどＣＯＤの対象となるハードウェアリソースの状態と有効期限などから構成される。これらは、暗号化される実装も考えられる。また、あらかじめ乱数等で定義してＣＯＤ−ＤＢ３３内に格納しておく方法も考えられる。
【００２２】
図９はＡＰベンダ内のＣＯＤ−ＤＢ３３の構造である。顧客システム識別子３３０１に対して顧客毎のエントリ３３１０、３３２０、３３３０がある。それぞれの顧客に対して、現在のＣＯＤの発動状況を示すＣＰＵの個数３３０２とメモリ量３３０３とＨＤ量３３０４、領収済み料金３３０５と、ライセンスキーの残り有効期間３３０６が格納されている。また、顧客毎に、ＣＯＤ発動状況を示す指標であるＣＰＵ３３１２、メモリ３３１３、ＨＤ３３１４の値と、そのＣＯＤ状況に対応した料金３３１５が格納されている。ライセンスキーの残り有効期間３３０６が格納されている。顧客Ａについては、現在の契約はＣＰＵ数２ヶ、メモリ容量８ＧＢ、ＨＤ容量１００ＧＢであるため、顧客Ａ契約３３１１から１９００円が使用量となる。図９に示すように課金する項目が顧客Ａ、顧客Ｘおよび顧客Ｙで異なるようにしても良い。
【００２３】
顧客システム１０では、ＡＰライセンス管理部１６でライセンスキー１７を受信する。ステップ１６１でライセンスキーを受け取った後、ステップ１６２でライセンスキー１７を格納する。さらにステップ１６３でアプリケーションプログラム４０に対してライセンスキーが変更になった事を通知する。ライセンスキー１７は通常、暗号化されており構成定義ファイルの中に格納される実装が行われる事が多いが、本発明ではその方法については規定しない。
【００２４】
本発明では上記のように、ＡＰライセンス制御部１６のステップ１６３において、アプリケーションプログラム４０に対してＣＯＤの発動を通知する事も特徴としている。
【００２５】
さらに、ＣＯＤを発動した後、アプリケーションプログラム４０やＯＳを停止せずにハードウェアリソースを増減できる場合、かつ、アプリケーションプログラム４０自体も動作中に使用するハードウェアリソース量を増減できる場合に、アプリケーションプログラム４０を停止する事なく、ＣＯＤを発動した後のハードウェアリソースを使う事ができるようにする事も特徴とする。この実施例は後述する。
【００２６】
次にアプリケーションプログラム４０の実施例として図６、図７の２つの形態を示す。以下で述べるアプリケーションプログラムは実施の一形態であり、本発明の範囲を限定する物ではない。
【００２７】
図６はアプリケーションプログラム４０の実施例の一形態を示すフローチャートである。アプリケーションプログラム４０は起動時にステップ４０１でＨＷ構成取得部１９からハードウェアの構成を得て、ステップ４０２でライセンスキー１７を得る。次にステップ４０３で、そのライセンスキー１７が意味しているアプリケーションプログラム４０の動作が許可されたハードウェアの構成と、動作しようとしている実際のハードウェアの構成とを比較して、不当な利用ではないかのチェックを行う。例えばライセンスキー１７が４ＣＰＵまでの実行を許可していて、実際のＣＰＵが８個であった場合、不当利用であると判定される。この時はステップ４０６で例えばアプリケーションプログラム４０を停止する。逆に、例えばハードウェアの実際の構成とライセンスキー１７に示されている構成が一致した場合は正当利用だと判定され、ステップ４０４でライセンスキー１７内に含まれている有効期間のチェックを行う。ライセンスキー１７の有効期限が切れていれば不正利用であるので、ステップ４０６でアプリケーションプログラム４０を停止する。有効期間内であれば、ステップ４０５にてアプリケーションプログラム４０の本来の作業である業務処理を行う。なおライセンスキー１７の有効期限は時間の経過と共にチェックしなおさねばならないため、ステップ４０５の業務処理は例えば一日一回などの頻度で一時中断し、ステップ４０４に戻り有効期限チェックを行う。
【００２８】
次に、図７はアプリケーションプログラム４０の実施例の図６とは異なる一形態を示すフローチャートである。この例では前述した「ＣＯＤの発動に応じて稼動中にハードウェアの使用量を変更できるアプリケーションプログラム」を示している。
【００２９】
ステップ４０１、ステップ４０２は図６と同様、ハードウェア構成とライセンスキー１７を得る処理である。この実施例のアプリケーションプログラム４０はライセンスキー１７が意味しているハードウェアの構成情報を用いて最適なハードウェア使用量を決める。この方法として一実施例をステップ４０３、４０７、４０８で示している。ステップ４０３で、ライセンスキー１７が意味しているアプリケーションプログラム４０の動作を許可したハードウェアの構成と、動作しようとしている実際のハードウェア構成を比較する。もしライセンスキー１７に示されているハードウェア構成以上のハードウェア上で起動されるという状態であれば、ステップ４０７にてアプリケーション４０が利用するハードウェア量がライセンスキー１７に従って決定される。逆にライセンスキー１７のほうが実際のハードウェア構成より大きければ、ステップ４０８にて、アプリケーション４０が利用するハードウェア量が実際のハードウェア構成を使い切るように決定される。例えば、ライセンスキー１７が４ＣＰＵまでの動作許可を意味していた場合、ハードウェア構成が８ＣＰＵであれば、プロセスを４個だけ起動する。逆にライセンスキー１７が８ＣＰＵまでを意味しており、ハードウェア構成が４ＣＰＵであった場合は、プロセスを４個だけ起動する。そしてステップ４０５の業務処理を行う。本実施例でいう構成変更は、容量変更や能力変更も含んでいる。
【００３０】
ＣＯＤの発動にともない、ステップ４０５の業務処理中に、ライセンスキー１７が変更された事を通知する割り込み４０９が発生する。この場合は割り込み処理によって一旦ステップ４０１の前に処理が戻る。
【００３１】
以下に図７の各ステップにそって、メモリを増加させた場合と、ＣＰＵを増加させた場合の例を二つ示す。
【００３２】
メモリを増加させる例として、実装メモリに応じて業務処理の作業領域を決定するタイプのアプリケーションプログラム４０を想定する。このアプリケーションプログラム４０では、ＯＳの使用量やアプリケーションプログラム４０自体のロードモジュールや固定領域の為に、０．５ＧＢ＋実装メモリの１／４を利用不能領域として引き、残りの部分を業務処理に割り当てるように実装されているとする。搭載メモリ４ＧＢの計算機の場合、ステップ４０１でメモリ量４ＧＢという情報が得られ、ステップ４０２でライセンスキー１７が４ＧＢメモリでの実行を意味している事を得られたとする。ステップ４０３の判定で「ＨＷ構成＝ライセンスキー」であるのでステップ４０７に進む。ステップ４０７ではライセンスキー１７が示す４ＧＢに従い、利用不能領域として０．５＋１ＧＢを引き、２．５ＧＢをアプリケーションプログラム４０の作業領域として割り当て、ステップ４０５で２．５ＧＢを利用して業務処理を行う。
【００３３】
ステップ４０５の業務処理中にメモリを１６ＧＢに増加させるＣＯＤ発動を行うと、ハードウェアの構成が１６ＧＢになりライセンスキー１７が１６ＧＢを意味する状態になった後に、ステップ４０９の割り込みがアプリケーションプログラム４０に対して発生する。すると順にステップをたどり、ステップ４０７によりアプリケーションプログラム４０は１６ＧＢで動作する時の設定である、利用不能領域として０．５＋４ＧＢを引いた残り１１．５ＧＢをアプリケーションプログラム４０自体の作業領域として割り当てなおす。結果としてステップ４０５の業務処理は作業領域が２．５ＧＢから１１．５ＧＢへ増えたので、アプリケーションプログラム４０は業務の処理能力を向上させる事ができる。
【００３４】
なお、一般的にアプリケーションプログラムでは仮想メモリ空間しか確保できないため、仮想メモリの大きさと実メモリの使用量が１対１になっているとは限らない。しかし、実メモリからＯＳの使用量など固定的に必要な容量を引いたメモリ量までの仮想メモリを使用すると、システム上で利用されている全ての仮想メモリ量を実メモリ以下におさえる事ができる。この状態ではアプリケーションプログラムが利用する領域は全て実メモリ上に収まり（ページアウトされる事がなくなり）、高効率で動作することができる。
【００３５】
ＣＰＵを増加させる例として、実装されているＣＰＵの数と同じ数のプロセス（処理単位の例でありスレッドであるケースなどもある）を起動して、業務業務処理を行うタイプのアプリケーションプログラム４０を想定する。搭載ＣＰＵ４個の計算機の場合、ステップ４０１でＣＰＵ数４個という情報が得られ、ステップ４０２でライセンスキー１７がＣＰＵ４個での実行を意味している事を得られたとする。ステップ４０３の判定で「ＨＷ構成＝ライセンスキー」であるのでステップ４０７に進む。ステップ４０７ではライセンスキー１７が示す４ＣＰＵに従い、プロセスを４個起動し、ステップ４０５で４個のプロセスを利用して業務処理を行う。
【００３６】
ステップ４０５の業務処理中にＣＯＤ発動が行われＣＰＵを８個に増加すると、ハードウェアの構成が８ＣＰＵになりライセンスキー１７が８ＣＰＵを意味する状態になった後に、ステップ４０９の割り込みがアプリケーションプログラム４０に対して発生する。すると順にステップをたどり、ステップ４０７によりアプリケーションプログラム４０は８ＣＰＵで動作する時の設定である、プロセス８個を起動しなおす。結果としてステップ４０５の業務処理を処理するプロセスが４個から８個に増えたので、アプリケーションプログラムは業務の処理能力を向上させる事ができる。
【００３７】
なお、図７と図６は分けて記述しているが構成要素を簡潔に説明するためであり、一つの実施形態に上記２つの方式を用いて適用することができる。例えば図６中のステップ４０４、４０６の処理（ライセンス有効期限チェック）は図７に適用可能であるし、ステップ４０３、４０６の処理（不正使用時のアプリケーション停止）も図７に適用可能である。
【００３８】
ＣＯＤ発動後、ＡＰベンダ３０は各顧客に対して新しいハードウェア構成に対応した料金の支払いを求める。図１におけるＡＰ課金管理部３２はＡＰベンダ内に書かれているが、実際には再販業者などＡＰベンダ３０とは別の企業またはシステムの構成を採ることも可能である。ＡＰ課金管理部３２は顧客１０のＡＰ料金支払い制御部１８に対して、新しいハードウェア構成に対応した料金の支払いを要求する。
【００３９】
図５はＡＰ課金管理部３２のフローチャートである。初めにステップ３２１でＣＯＤ−ＤＢ３３を検索し、顧客にどれだけの金額を請求するかをＣＯＤ状況毎の料金３３１５から検出し、ステップ３２２にて料金を請求する。次に例えば毎日１２時などの契機で料金の支払いが行われたかをステップ３２３でチェックする。支払いが無い場合はステップ３２８でＣＯＤ−ＤＢ３３からライセンスキーの有効期間３３０６を調べ、有効期限が過ぎていれば、ステップ３２９にて利用権限が全く無い事を意味するライセンスキーを送り込む。有効期限が切れていなければステップ３２３に戻り、再び支払いを待つ。なお、支払いがあった場合はステップ３２４にてＣＯＤ−ＤＢ３３内の領収済み料金３３０５を更新する。さらにステップ３２５にて、ＣＯＤ状態毎の料金３３１５と比較して支払われた料金に不足があるかを調べる。不足があった場合はステップ３２３の支払い待ちに戻る。不足がなかった場合には次回の支払い期限を決め、ステップ３２６にて顧客に対して新しい有効期間に対応するライセンスキーを送り、ステップ３２７にてＣＯＤ−ＤＢ３３内の有効期間３３０６を更新する。
【００４０】
有効期限の情報が含まれていないライセンスキーで利用を制御していた場合、ＣＯＤ発動後のハードウェア構成に対応したライセンスキーを入手された直後に、通信できないように通信路が切断された場合は、例え不正使用が行われていてもＡＰベンダ３０からアプリケーションプログラム４０の実行制限を行う事ができないという問題が発生する。それに対して、ライセンスキー１７自体に有効期限を持たせる事で不正利用を防ぐ事ができる。ライセンスキー１７の有効期限が切れていた場合には、アプリケーションプログラム４０はステップ４０４の判定により動作しないようになり、ＣＯＤ発動後の状態での不正利用を防ぐ事ができる。
【００４１】
この場合、ライセンスキーの自動更新を行う実施例を以下に示す。ひとつは、ライセンスキー１７の期限切れを検出したアプリケーションプログラム４０自身が、ＡＰベンダ３０に新しいライセンスキーを要求して、入手する実装がある。また、ＡＰベンダ３０が、自身の持つＣＯＤ−ＤＢ３３内のライセンスキー有効期限３３０６を参照し、ライセンスキー１７を送り込む方法もある。いずれの場合でも通信路の切断ではライセンスキー１７の更新ができなくなるため、顧客システム１０内にあるライセンスキー１７の有効期限が切れるため、不正利用を防ぐ事ができる。本発明では上記ライセンスキー更新処理の実施の形態は規定しない。
【００４２】
なお、ＣＯＤ対応のシステムを導入し本番稼動に入る前に、数ヶ月程度一時的にＣＯＤを発動して業務アプリケーションプログラムを含めたシステム全体の動作検証や、ＣＯＤを発動した後の状態での性能検証を行う事が一般的であると想定される。この場合も本発明で述べてきた手段により、一時的なＣＯＤ発動用のライセンスキーの送受信を行う事ができる。
【００４３】
以上により、ＣＯＤ形態で導入したハードウェアの上で動作する業務処理アプリケーションプログラムは、ＣＯＤが発動された後すぐに、ＣＯＤによって増強されたハードウェアリソースを利用することができ、顧客業務に対する処理能力の短時間での増強が達成できる。また、ハードウェアリソースの増加を行った後に、アプリケーションプログラムに対して適切な使用料を支払わず、不当な利用を続けた場合に、適切な支払いが行われるまでアプリケーションプログラムの処理能力を制限や停止する手段をあたえる事で、不正利用に対する保護が可能になる。
【００４４】
【発明の効果】
本発明により、ハードウェアの構成変更を反映したプログラムの能力変更を実現することが可能となる。
【図面の簡単な説明】
【図１】本発明の実施例の全体の構成を示すブロック図である。
【図２】通信を行う各ブロックがどのような順番で動作するかを示したタイミングチャートである。
【図３】顧客システム内のＨＷ−ＣＯＤ発動制御部とＨＷベンダ内のＣＯＤ発動通知受付部のフローチャートである。
【図４】顧客システム内のＡＰ−ＣＯＤ発動制御部とＡＰベンダ内のＣＯＤ発動通知受付部と、顧客システム内のＡＰライセンス管理部のフローチャートである。
【図５】ＡＰベンダ内のＡＰ課金管理部のフローチャートである。
【図６】ＡＰの実施例の一形態である。
【図７】図６とは異なるＡＰの実施例の一形態である。
【図８】ＨＷベンダ内のＣＯＤに関する情報を保持するＣＯＤ−ＤＢの図である。
【図９】ＡＰベンダ内のＣＯＤに関する情報を保持するＣＯＤ−ＤＢの図である。
【符号の説明】
１０：顧客システム
１１：ＣＯＤ発動指示受付部
１２：ＨＷ−ＣＯＤ発動制御部
１３：ＨＷ料金支払い制御部
１４：ＡＰ−ＣＯＤ発動制御部
１５：ＣＯＤ発動時の通知先一覧
１６：ＡＰライセンス管理部
１７：ライセンスキー
１８：ＡＰ料金支払い制御部
１９：ＨＷ構成取得部
２０：ＨＷベンダ
２１：ＨＷベンダ内、ＣＯＤ発動通知受付部
２２：ＨＷ課金管理部
２３：ＨＷベンダ内、ＣＯＤ−ＤＢ
３０：ＡＰベンダその１
３１：ＡＰベンダ内、ＣＯＤ発動通知受付部
３２：ＡＰ課金管理部
３３：ＡＰベンダ内、ＣＯＤ−ＤＢ
３８：ＡＰベンダその２
３９：ＡＰベンダその３
４０：アプリケーションプログラム
２３１０、２３２０、２３３０：ＨＷベンダ内ＣＯＤ−ＤＢにある顧客の現在の状態を示すレコード
２３０１：ＨＷベンダ内ＣＯＤ−ＤＢ内の顧客システム識別子欄
２３０２、２３０３、２３０４：ＨＷベンダ内ＣＯＤ−ＤＢ内の現在のＣＯＤ発動状況欄
２３０５：ＨＷベンダ内ＣＯＤ−ＤＢ内の領収済み料金欄
２３１２、２３１３、２３１４：ＨＷベンダ内ＣＯＤ−ＤＢ内の顧客毎のＣＯＤ発動状況の指標
２３１５：ＨＷベンダ内ＣＯＤ−ＤＢ内の顧客毎のＣＯＤ発動状況毎の料金一覧
３３１０、３３２０、３３３０：ＡＰベンダ内ＣＯＤ−ＤＢ内の顧客毎の現在の状態を示すレコード
３３０１：ＡＰベンダ内ＣＯＤ−ＤＢ内の顧客システム識別子欄
３３０２、３３０３、３３０４：ＡＰベンダ内ＣＯＤ−ＤＢ内の現在のＣＯＤ発動状況欄
３３０５：ＡＰベンダ内ＣＯＤ−ＤＢ内の領収済み料金欄
３３０６：ＡＰベンダ内ＣＯＤ−ＤＢ内のライセンスキーの残り有効期間欄
３３１２、３３１３、３３１４：ＡＰベンダ内ＣＯＤ−ＤＢ内の顧客毎のＣＯＤ発動状況の指標
３３１５：ＡＰベンダ内ＣＯＤ−ＤＢ内の顧客毎のＣＯＤ発動状況毎の料金一覧
【図１】
2004086392.tif 000003
【図２】
2004086392.tif 000004
【図３】
2004086392.tif 000005
【図４】
2004086392.tif 000006
【図５】
2004086392.tif 000007
【図６】
2004086392.tif 000008
【図７】
2004086392.tif 000009
【図８】
2004086392.tif 000010
【図９】
2004086392.tif 000011