JP3960961B2 - ソフトウェアに修正情報を適用する装置および方法 - Google Patents

Description

本発明は、ソフトウェアを複数のサーバに動的に割り当てて顧客サービスを行うシステムにおいて、ソフトウェアに修正情報を適用する装置および方法に関する。

近年、ネットワーク環境を有しコンピュータシステムの維持管理を行うデータセンタにおいて複数のコンピュータリソースを複数の顧客に動的に割り当てることで、リソースの有効活用を図るシステムが提案されている。このようなシステムとしては、例えば、ＩＢＭ社（International Business Machines Corporation ）のAutonomic Computing や、ＨＰ社（Hewlett-Packard Company ）のUtility Data Center 、サン・マイクロシステムズ社（Sun Microsystems, Inc.）のＮ１等が挙げられる。

リソースの種類としては、ＣＰＵ（中央処理装置）、ネットワーク装置等のハードウェアと、オペレーティングシステム（ＯＳ）、アプリケーションプログラム（以下、アプリケーションと記す）等のソフトウェアがある。ソフトウェアには、ＯＳやアプリケーション等のプログラムの他に、プログラムにより使用されるデータも含まれる。

図２３は、このようなシステムにおいて、各サーバで動作している各顧客の各ソフトウェアについて、どのバージョンのものが稼動しているかを示している。ここでは、サーバＳ１〜Ｓ３が顧客Ａに割り当てられており、サーバＳ５およびＳ６が顧客Ｂに割り当てられており、サーバＳ７が顧客Ｃに割り当てられている。

例えば、サーバＳ１では顧客Ａのシステムとして、オペレーティングシステムＯＳ１とアプリケーションＡＰ１が稼動しており、サーバＳ６では顧客Ｂのシステムとして、オペレーティングシステムＯＳ２とデータベースＤＢ２が稼動している。また、サーバＳ７では顧客Ｃのシステムとして、オペレーティングシステムＯＳ１とデータベースＤＢ２が稼動している。サーバＳ４では何も動作しておらず、このサーバは空き状態となっている。状況によっては、サーバＳ４でいずれかの顧客のシステムが稼動することもあり得る。

このように、複数のサーバを複数の顧客が共有し動的に稼動状態が変更されるシステムは新しいシステムであり、リソースの保守運用についても新しい方法が求められる。特に、ソフトウェアについては、ベンダから頻繁に修正情報（パッチ）が提供されるので、システムの維持管理のためにはそれらのパッチを随時システムに適用して保守していかなければならない。

従来の保守運用方法では、データセンタのオペレータが人手で保守作業を行っていた。例えば、システム上のリソース情報を表形式で管理し、リソースの修正情報がベンダから提供された場合は、オペレータがその情報を分析して、ベンダにより指定されたシステム構成と現状のシステム構成との比較検討を行うことで、修正情報適用の可否を決めていた。実際に修正情報をリソースに適用する際には、あらかじめ顧客との間で取り決められたタイミング（例えば、週２回深夜１時〜３時等）で顧客システムを停止して、人手で修正作業を行うケースがほとんどである。

また、単一の顧客システムに対するプログラム修正の適用を支援するシステムも提案されている（例えば、特許文献１参照）。
特開２０００−１０７６６号公報

しかしながら、上述した従来の保守運用方法には、次のような問題がある。
顧客サービスとして既に割り当てられ稼動しているリソースに対しては、そのままの状態ではパッチを適用することができず、これを適用するためにシステムを停止せざるを得なくなるという危険性がある。

また、リソースが大量になると、どのソフトウェアがどのバージョンになっているのかを簡単に知ることができない。あるアプリケーションに対して緊急のパッチが発行されたとしても、それをどのソフトウェアに適用する必要があるのかを調べるのに手間がかかる。つまり、大量にあるリソースのそれぞれについて、どの程度新しいバージョンのアプリケーションが動作していてどの程度安全であるのかについて、統一的に知る手段がない。

このため、どのサーバでどのソフトウェアが動作しているかを一元管理できて、ソフトウェアのアップデートまで自動化可能なシステムは、まだ実現されていない。しかし、サーバの数が大量になってくるとオペレータが管理可能な限界を超えてしまうので、システム自身が自動的に管理する機能は今後必ず必要になると考えられる。

さらに、ソフトウェアに対するパッチの適用は必ずしもすべて必須というわけではない。また、顧客システムのカスタマイズ内容等によっては、最新のパッチを適用することによって不都合が発生することも考えられる。したがって、パッチ適用の可否を適切に判断する機能も望まれる。

本発明の課題は、複数のソフトウェアを複数のサーバに動的に割り当てて顧客サービスを行うシステムにおいて、ソフトウェアに対して修正情報を的確に適用する装置および方法を提供することである。

図１は、本発明の修正適用装置の原理図である。図１の修正適用装置は、計算手段１０１、格納手段１０２、および適用手段１０３を備え、ソフトウェアを複数のサーバ１０４−１，１０４−２，．．．，１０４−ｍに動的に割り当てて顧客サービスを行うシステムにおいてソフトウェアに修正情報を適用する。

計算手段１０１は、修正情報の発行時に提供される情報を用いて、顧客が使用しているソフトウェア１０５の新しさとソフトウェア１０５のセキュリティレベルを統合した指標を計算する。格納手段１０２は、顧客により指定された、指標に対する制約条件１０５を格納する。適用手段１０３は、計算された指標が制約条件１０６を満たすか否かをチェックし、計算された指標が制約条件１０６を満たさなければ、ソフトウェア１０５に修正情報を適用してソフトウェア１０５をアップデートする。

このような修正適用装置によれば、ソフトウェアの新しさとセキュリティレベルを統合した指標と、顧客毎のカスタマイズレベルを表す制約条件とを用いて、システム上で稼動している各顧客のソフトウェアが統一的に管理される。この指標は、新たな修正情報が発行される度に再計算され、あらかじめ設定された制約条件を満たさなくなると、発行された修正情報が該当する顧客のソフトウェアに適用される。

このとき、適用手段１０３は、いずれの顧客にも割り当てられていない空きサーバ上に、顧客が使用しているソフトウェア１０５が稼動している処理対象サーバ１０４−２と同じソフトウェア構成を用意し、空きサーバ上でソフトウェア１０５に修正情報を適用し、処理対象サーバ１０４−２の代わりに空きサーバを顧客に割り当てることで、ソフトウェア１０５をアップデートすることができる。

また、適用手段１０３は、空きサーバ上で、いずれの顧客にも割り当てられていないソフトウェアに修正情報を適用してそのソフトウェアをアップデートし、そのソフトウェアを必要とする顧客が現れたとき空きサーバをその顧客に割り当てることもできる。

計算手段１０１、格納手段１０２、および適用手段１０３は、例えば、後述する図２のパッチデータ管理部２０５、顧客使用ソフトウェア一覧表２１２、および動的アサイン管理部２０６に対応する。また、計算手段１０１が計算する指標は、後述するクリーンポイントに対応する。
本発明の別の修正適用装置は、格納手段、計算手段１０１、および適用手段１０３を備え、複数のサーバとネットワーク環境により接続され、それらのサーバの各々を複数の顧客のいずれかに動的に割り当て、それぞれのサーバで稼動しているソフトウェアに修正情報を適用する。格納手段は、既に発行された修正情報の適用対象ソフトウェア名、発行日、重要度、およびバージョンの対応関係を示す管理情報と、顧客名、使用ソフトウェア名、および顧客指定の閾値を含む制約条件の対応関係を示す顧客使用ソフトウェア一覧表と、サーバ名、顧客名、インストールソフトウェア名、およびバージョンの対応関係を示す動的アサイン表とを格納する。計算手段１０１は、新たな修正情報の発行時に管理情報を参照して、新たな修正情報の適用対象ソフトウェア名に対応するソフトウェアのそれぞれのバージョンについて、発行日に対応する基本ポイントを計算し、得られた基本ポイントをそれぞれのバージョンの重要度に応じて変更することで、それぞれのバージョンの指標を計算する。適用手段１０３は、顧客使用ソフトウェア一覧表を参照して、新たな修正情報の適用対象ソフトウェア名と同じ使用ソフトウェア名に対応する顧客名および制約条件を取得し、動的アサイン表を参照して、適用対象ソフトウェア名と同じインストールソフトウェア名に対応する顧客名およびバージョンを取得し、顧客名毎に、取得したバージョンについて計算された指標を取得した制約条件の閾値と比較して、計算された指標が制約条件を満たすか否かをチェックし、計算された指標が制約条件を満たさなければ、動的アサイン表を参照して、適用対象ソフトウェア名と同じインストールソフトウェア名に対応するサーバ名を取得し、取得したサーバ名のサーバで稼動しているインストールソフトウェアに新たな修正情報を適用してインストールソフトウェアをアップデートする。

本発明によれば、各顧客システムの稼動状況やカスタマイズレベルに応じて、修正情報適用の可否が的確に判断される。これにより、顧客システムの安定稼動が可能になり、運用オペレータの作業が軽減される。また、空きサーバを利用してソフトウェアをアップデートすることにより、顧客システムを停止せずにリソースを最新かつ安全な状態にすることができる。

以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
一般に、顧客は、システムが一定のセキュリティレベルを維持することを期待するものである。そこで、本実施形態では、このセキュリティレベルを数値で表し、パッチの適用が必要か否かをシステムが自動的に判断できるようにするために、ソフトウェアリソースのクリーンポイントという指標を導入する。

クリーンポイントは、ソフトウェアのクリーンさの程度を表す。ソフトウェアのバージョンが新しいほど、また、ソフトウェアのセキュリティレベルが高いほど、クリーンポイントの数値は大きくなる。

本実施形態の修正適用装置は、以下のような機能を有する。
・各ソフトウェアについてクリーンポイントを計算する。
・各顧客が必要とするソフトウェアとそのソフトウェアに対する制約条件を管理するための顧客使用ソフトウェア一覧表を作成する。
・各顧客に対するリソースの割り当て状況を管理するための動的アサイン表を作成する。
・リソースとパッチの適用状態の組み合わせを管理するためのアップデート適用表を作成する。
・ソフトウェアベンダから提供されるパッチ情報をシステムで一元管理できる状態に正規化するためのパッチ情報解釈部を有する。
・パッチ情報を管理し、すべてのソフトウェアについてのクリーンポイントをあらかじめ計算するためのパッチデータ管理部を有する。
・システム上の全サーバについてどのソフトウェアが稼動しているかを一元管理するための動的アサイン管理部を有する。
・ある時点でどの顧客にも割り当てられていない空きサーバを利用して、あらかじめソフトウェアにアップデートパッチを適用しておき、そのソフトウェアを顧客に割り当てることで、即座にクリーンなソフトウェアを提供する。
・空きサーバを利用してソフトウェアに緊急アップデートパッチを適用し、空きサーバを順番に稼動状態に切り替えることで、稼動中のシステムをクリーンな状態に移行させる。
・各顧客が現有するすべてのソフトウェアについてクリーンポイントを計算し、顧客毎のシステムの安全性を可視化する。

図２は、このような修正適用装置の構成図である。図２の修正適用装置は、パッチ情報解釈部２０３、２０４、パッチデータ管理部２０５、および動的アサイン管理部２０６を備え、共用サーバプール２０７上で動作している各顧客システムのソフトウェアに対して、パッチ提供元２０１および２０２から提供されたパッチを適用する。

パッチ提供元２０１および２０２は、各ソフトウェアを作成するベンダであり、ベンダ毎にパッチ情報およびパッチデータの提供方法が異なる。パッチ情報は、パッチ提供元から提供されるパッチの適用方法に関する情報であり、パッチデータは、ソフトウェアに適用されるパッチ本体のデータである。パッチ情報解釈部２０３および２０４は、ベンダ毎に異なるパッチ提供方法の差異を吸収し、ソフトウェアの名称、バージョン、および重要度を正規化する。

図２では、２つのパッチ提供元に応じて２つのパッチ情報解釈部が示されているが、３つ以上のパッチ提供元が存在する場合は、パッチ提供元の数に応じて複数のパッチ情報解釈部が用意される。また、１つのパッチ情報解釈部が複数のパッチ提供元から提供されるパッチ情報を解釈することも可能である。

パッチデータ管理部２０５は、共用サーバプール２０７で使用される全ソフトウェアについて、データベース２１１に格納されたパッチ情報とパッチデータを管理し、パッチの時系列と重要度に基づいてソフトウェアのクリーンポイントを計算する。また、新しいパッチが発行された場合は、そのパッチ情報を動的アサイン管理部２０６に通知する。

動的アサイン管理部２０６は、顧客使用ソフトウェア一覧表２１２、動的アサイン表２１３、およびアップデート適用表２１４を保持し、これらの表の内容を動的に管理する。そして、顧客使用ソフトウェア一覧表２１２を参照して新しいパッチの適用可否を判断し、適用可と判断したパッチを共用サーバプール２０７上のソフトウェアに適用する。適用処理の詳細については後述することにする。

共用サーバプール２０７は複数のサーバＳ１〜Ｓ７からなり、そのうち１つ以上のサーバ上で各顧客のシステムが動作する。状況に応じて稼動状態は異なり、ある時点で顧客Ａに割り当てられていたリソースが、別の時点では顧客Ｂに割り当てられることもあり得る。

次に、図３から図２０までを参照しながら、図２の修正適用装置の処理についてより詳細に説明する。
図３は、図２のパッチ情報解釈部２０３により行われるパッチ情報解釈処理を示している。パッチ提供元２０１から発行されたパッチ情報３０１は、電子メール等の方法でパッチ情報解釈部２０３に転送される。パッチ情報解釈部２０３は、パッチ情報解釈対応表３０２を参照してパッチ情報３０１を解釈し、パッチ情報３０１から日付、ソフトウェア名、重要度、およびバージョンを含むパッチ管理情報３０３を抽出し、パッチ情報３０１に含まれるリンク先からパッチデータ３０４を取得する。そして、得られたパッチ管理情報３０３およびパッチデータ３０４をデータベース２１１に登録する。

図４は、パッチ情報３０１、パッチ情報解釈対応表３０２、パッチ管理情報３０３、およびパッチデータ３０４の例を示している。パッチ情報３０１には、発行日４０１、影響ソフトウェア名４０２、セキュリティレベル４０３、およびダウンロード情報４０４が含まれている。また、パッチ情報解釈対応表３０２は、日付４０５、ソフトウェア名４０６、重要度４０７、バージョン４０８、およびパッチデータ４０９のエントリを有し、各エントリには必要な管理情報の記載位置が記録されている。

パッチ情報解釈部２０３は、パッチ情報解釈対応表３０２の各エントリに記録された記載位置の情報に基づいて、パッチ情報３０１の対応する位置から管理情報を抽出する。抽出されたバージョンは、パッチのバージョンであると同時に、ソフトウェアのバージョンでもある。

パッチ情報解釈対応表３０２の重要度４０７のエントリには、パッチ情報３０１に記載されたセキュリティレベル４０３の種類に応じて、レベルの低い方から順番に１から始まる番号で重要度が指定されている。ここでは、セキュリティレベル４０３に“緊急”と記載されているので、対応する重要度“４”がパッチ管理情報３０３として出力される。

また、パッチ情報解釈部２０３は、パッチデータ４０９のエントリに記録された記載位置の情報に基づいて、パッチ情報３０１の対応する位置からリンク先の情報を抽出し、そのリンク先からパッチデータ３０４をダウンロードする。

顧客が使用するソフトウェアのパッチ提供元毎にこのようなパッチ情報解釈対応表３０２を用意しておくことで、修正適用装置は、自動的に必要な情報を取得することができるようになる。

図５は、上述したパッチ情報解釈処理のフローチャートである。パッチ情報解釈部２０３は、パッチ提供元２０１から新しいパッチ情報３０１を受け取ると、まず、パッチ情報解釈対応表３０２を参照して、パッチの適用対象となるソフトウェアの名称を抽出し（ステップ５０１）、システムで使用しているソフトウェアか否かをチェックする（ステップ５０２）。ソフトウェア名が使用ソフトウェアに該当しなければ、そのパッチを適用する必要がないので、そのまま処理を終了する。

ソフトウェア名が使用ソフトウェアに該当すれば、次に、パッチの発行日を抽出し（ステップ５０３）、パッチの重要度を抽出し（ステップ５０４）、パッチのバージョンを抽出する（ステップ５０５）。

次に、パッチのダウンロード方法を抽出し（ステップ５０６）、その方法に従ってパッチデータ３０４をダウンロードする（ステップ５０７）。
そして、抽出された日付、ソフトウェア名、重要度、およびバージョンからなるパッチ管理情報３０３と、ダウンロードされたパッチデータ３０４とをデータベース２１１に登録して（ステップ５０８）、処理を終了する。図２のパッチ情報解釈部２０４も、基本的にパッチ情報解釈部２０３と同様の処理を行う。

図６は、図２のパッチデータ管理部２０５により用いられるクリーンポイントの計算方法の例を示している。パッチデータ管理部２０５は、データベース２１１に登録されたソフトウェアＡの各バージョンのパッチ管理情報に基づいて、各バージョンのクリーンポイントを計算する。このとき、まず、各バージョンの基本ポイントと重要度から、各バージョンにおける正規化前のクリーンポイントを計算し、得られた値を最新バージョンの値をもとにして正規化する。

この計算方法では、まず、ソフトウェアＡの初版であるバージョン１．０の発行日と、最新バージョンであるバージョン１．３の発行日をもとに、時間軸が作成される。次に、初版をポイント“１”、最新バージョンをポイント“１００”として、単純に各バージョンの発行日に対応する基本ポイントが計算され、基本ポイントグラフが作成される。

図６の例では、ソフトウェアＡの各バージョンの基本ポイントは、以下のように算出される。

バージョン１．０ 基本ポイント“１”
バージョン１．１ 基本ポイント“８０”
バージョン１．２ 基本ポイント“９５”
バージョン１．３ 基本ポイント“１００”

次に、初版の重要度を“１”として、各バージョンの重要度をもとにした重要度グラフが作成される。最後に、各バージョンの重要度に応じて基本ポイントグラフの傾きを変更したグラフが作成され、最新バージョンのポイントが“１００”となるように、各バージョンのポイントが正規化される。こうして算出された各バージョンのポイントが、クリーンポイントとして記録される。

以上のようなクリーンポイントの計算方法は、次式により表される。

ａ_n＝ａ_n-1＋（ｔ_n−ｔ_n-1）×ｓ_n （ｎ＝１，．．．，Ｎ） （１）
Ｃ₁＝１ （２）
Ｃ_i＝（ａ_i／ａ_N）×１００ （ｉ＝２，．．．，Ｎ） （３）

ただし、（１）式において、ｔ_nはｎ番目のバージョンの基本ポイント、ｓ_nはｎ番目のバージョンの重要度、ａ_nはｎ番目のバージョンの正規化される前のクリーンポイントを表し、ｔ₀＝０、ａ₀＝０とする。１番目のバージョンは初版に相当し、Ｎ番目のバージョンは最新バージョンに相当する。また、（２）および（３）式において、Ｃ_i（ｉ＝１，．．．，Ｎ）はｉ番目のバージョンの正規化されたクリーンポイントを表す。

実際には、パッチデータ管理部２０５は、図６に示したようなグラフを画面上に表示するのではなく、（１）〜（３）式を用いてクリーンポイントを直接算出する。この計算方法によれば、古いけれど重要なパッチや新しいけれどそれほど重要ではないパッチも含めて、すべてのバージョンのパッチを統一的に数値で表現することが可能になる。

なお、（１）〜（３）式はクリーンポイントの計算方法の一例を示しているに過ぎず、クリーンポイントの計算方法はこれに限定されるものではない。
図７は、図２の動的アサイン管理部２０６が保持する顧客使用ソフトウェア一覧表２１２の例を示している。図７の顧客使用ソフトウェア一覧表は、それぞれの顧客が使用するソフトウェアの一覧を管理するために用いられ、顧客名、ソフトウェア名、バージョン束縛条件、およびＣＬ（クリーンポイント）閾値の各欄からなる。

バージョン束縛条件の欄には、ソフトウェアを所定のバージョンで動作させる必要がある場合にそのバージョンを指定する条件が記録され、ＣＬ制約条件の欄には、各顧客により指定された、ソフトウェアのクリーンポイントが満たすべき制約条件が記録される。この制約条件には、例えば、クリーンポイントの閾値が含まれる。

図７の７０１〜７０３の各エントリは、以下のような意味を有する。
７０１：顧客“ＵＳＥＲ１”は、ソフトウェア“Ｓｏｆｔｗａｒｅ１”の様々なバージョンのうち、クリーンポイントが８５以上のものを使用する。
７０２：顧客“ＵＳＥＲ１”は、ソフトウェア“Ｓｏｆｔｗａｒｅ２”の様々なバージョンのうち、クリーンポイントが９０以上のものを使用する。“Ｓｏｆｔｗａｒｅ２”は頻繁にバージョンアップされるので、“Ｓｏｆｔｗａｒｅ１”よりクリーンポイントの閾値が高く設定されている。
７０３：顧客“ＵＳＥＲ１”は、ソフトウェア“Ｓｏｆｔｗａｒｅ３”のバージョン１．３を使用する。ただし、この場合、バージョン１．３のクリーンポイントは“７０”であるものとする。

動的アサイン管理部２０６は、このような顧客使用ソフトウェア一覧表を用いて顧客が要求しているソフトウェアとクリーンレベルとを認識する。
図８は、図２の動的アサイン管理部２０６が保持する動的アサイン表２１３の例を示している。図８の動的アサイン表は、現在のシステムにおいてどのサーバ上でどの顧客に対してどのソフトウェアが割り当てられているかの一覧を管理するために用いられ、サーバ名、顧客名、インストールソフトウェア名、およびバージョンの各欄からなる。インストールソフトウェア名の欄には、サーバにインストールされたソフトウェアの名称が記録され、バージョンの欄には、そのソフトウェアのバージョンが記録される。

図８の８０１〜８０４の各エントリは、以下のような意味を有する。
８０１：サーバ“Ｓ１”上で顧客“ＵＳＥＲ１”のために、ソフトウェア“Ｓｏｆｔｗａｒｅ１”のバージョン“１．３”が動作している。
８０２：サーバ“Ｓ１”上で顧客“ＵＳＥＲ１”のために、ソフトウェア“Ｓｏｆｔｗａｒｅ２”のバージョン“５．２”が動作している。
８０３：サーバ“Ｓ２”上でソフトウェア“Ｓｏｆｔｗａｒｅ１”のバージョン“１．３”が動作しているが、現在どの顧客にも割り当てられていない。
８０４：サーバ“Ｓ３”上で顧客“ＵＳＥＲ２”のために、ソフトウェア“Ｓｏｆｔｗａｒｅ３”のバージョン“３．３”が動作している。

動的アサイン管理部２０６は、このような動的アサイン表を用いて現在サーバ上で稼動している全顧客システムの状態を認識する。
図９は、図２の動的アサイン管理部２０６が保持するアップデート適用表２１４の例を示している。図９のアップデート適用表は、ソフトウェアのどのバージョンがどのサーバ上で動作しているかについてシステムの現状を管理するために用いられ、ソフトウェア名、サーバ名、バージョン、およびＣＬの各欄からなる。

図９の９０１〜９０４の各エントリは、以下のような意味を有する。
９０１：ソフトウェア“Ｓｏｆｔｗａｒｅ１”のバージョン“１．３”（クリーンポイント“７０”）がサーバ“Ｓ１”上で動作している。
９０２：ソフトウェア“Ｓｏｆｔｗａｒｅ１”のバージョン“１．４”（クリーンポイント“８０”）がサーバ“Ｓ２”上で動作している。
９０３：ソフトウェア“Ｓｏｆｔｗａｒｅ１”のバージョン“１．５”（クリーンポイント“１００”）がサーバ“Ｓ３”上で動作している。
９０４：ソフトウェア“Ｓｏｆｔｗａｒｅ２”のバージョン“５．３”（クリーンポイント“８９”）がサーバ“Ｓ２”上で動作している。

動的アサイン管理部２０６は、このようなアップデート適用表を用いて全サーバ上で動作しているソフトウェアの状態を認識する。このアップデート適用表を図８の動的アサイン表と組み合わせて参照すれば、顧客に割り当てられていない空きサーバを利用してソフトウェアの自動アップデートを行うことができる。

図１０は、図２の修正適用装置により行われる修正適用処理のフローチャートである。パッチ提供元から新しいパッチ情報を受け取ると、まず、パッチ情報解釈部は、図５に示したパッチ情報解釈処理を行って、パッチ管理情報およびパッチデータをデータベース２１１に登録する（ステップ１００１）。

次に、パッチデータ管理部２０５は、データベース２１１に格納されたパッチ管理情報を参照して、パッチの適用対象となるソフトウェアの各バージョンのクリーンポイントを計算し、得られたクリーンポイントの値を動的アサイン管理部２０６に通知する（ステップ１００２）。

動的アサイン管理部２０６は、パッチ管理情報のソフトウェア名をキーとして顧客使用ソフトウェア一覧表２１２を検索し、そのソフトウェアに対して各顧客が設定しているＣＬ制約条件を取得する。また、そのソフトウェア名をキーとして動的アサイン表２１３を検索し、各顧客に割り当てられているそのソフトウェアのバージョンを取得する。

そして、通知された各バージョンのクリーンポイントのうち、各顧客のバージョンに対応するクリーンポイントの値がその顧客のＣＬ制約条件を満たすか否かをチェックする（ステップ１００３）。各バージョンのクリーンポイントの値が対応する顧客のＣＬ制約条件を満たしている場合は、パッチを適用する必要がないと判断し、そのまま処理を終了する。

いずれかのバージョンに対応するクリーンポイントの値が対応する顧客のＣＬ制約条件を満たさない場合は、その顧客のソフトウェアに対してパッチを適用する必要があると判断する。そこで、共用サーバプール２０７の空きサーバを利用して、その顧客に割り当てられているサーバと同じソフトウェア構成で、かつ、対象ソフトウェアにパッチが適用された状態を作り出す（ステップ１００４〜１０１０）。このとき、空きサーバ上に必要なソフトウェアがそろっていない場合は、状況に応じて各ソフトウェアのインストール、アップデート、およびアンインストールが行われる。

動的アサイン管理部２０６は、まず、動的アサイン表２１３を参照して、対象ソフトウェアがインストールされているサーバと空きサーバを検出し、前者を処理対象サーバとする。そして、処理対象サーバと同じ構成を実現するために不要なソフトウェアが空きサーバにあるか否かをチェックし（ステップ１００４）、そのようなソフトウェアがあれば、そのソフトウェアのアンインストールを実行する（ステップ１００５）。

次に、動的アサイン表２１３を参照して、対象ソフトウェア以外のソフトウェアであって、処理対象サーバのものより古いバージョンのソフトウェアが空きサーバにあるか否かをチェックする（ステップ１００６）。そして、そのようなソフトウェアがあれば、そのソフトウェアをアップデートする（ステップ１００７）。

次に、動的アサイン表２１３を参照して、処理対象サーバと同じ構成を実現するために必要なソフトウェアがすべて空きサーバにあるか否かをチェックし（ステップ１００８）、不足しているソフトウェアがあれば、そのソフトウェアを空きサーバにインストールする（ステップ１００９）。

そして、空きサーバ上で対象ソフトウェアにパッチを適用してそのソフトウェアをアップデートし（ステップ１０１０）、動的アサイン表２１３を書き換えて、顧客へのサーバの割り当てを処理対象サーバから空きサーバへ変更する（ステップ１０１１）。

次に、動的アサイン表２１３を参照して、同じ顧客に割り当てられた残りのサーバの中にパッチを適用する必要があるサーバがあるか否かをチェックし（ステップ１０１２）、そのようなサーバがあれば、それを処理対象サーバとしてステップ１００４以降の処理を繰り返す。

そして、その顧客のすべてのサーバについて処理が終了すると、次に、動的アサイン表２１３を参照して、残りの顧客に割り当てられたサーバにパッチを適用する必要があるか否かをチェックする（ステップ１０１３）。そのようなサーバがあればステップ１００４以降の処理を繰り返し、すべての顧客のシステムについて処理が終了すると、現状のシステム構成に合わせてアップデート適用表２１４を書き換えて修正適用処理を終了する。

例えば、ある瞬間において、図１１のような状態でシステムが稼動していたとする。この状態では、サーバＳ１、Ｓ２、およびＳ３が顧客Ａに割り当てられており、サーバＳ５およびＳ６が顧客Ｂに割り当てられており、サーバＳ７が顧客Ｃに割り当てられている。サーバＳ４は空きサーバである。

サーバＳ１およびＳ２ではオペレーティングシステムＯＳ１とアプリケーションＡＰ１が稼動しており、サーバＳ３ではオペレーティングシステムＯＳ１とデータベースＤＢ１が稼動しており、サーバＳ４ではオペレーティングシステムＯＳ１のみが稼動している。また、サーバＳ５ではオペレーティングシステムＯＳ２のみが稼動しており、サーバＳ６ではオペレーティングシステムＯＳ２とアプリケーションＡＰ１が稼動しており、サーバＳ７ではオペレーティングシステムＯＳ１とデータベースＤＢ２が稼動している。オペレーティングシステムＯＳ２は、オペレーティングシステムＯＳ１の新しいバージョンに相当する。

ここで、ＡＰ１に対してセキュリティホール対応等の緊急アップデートパッチが発行された場合、以下のような手順で修正適用処理が行われる。
動的アサイン管理部２０６は、まず、サーバＳ１のＡＰ１にパッチを適用してＡＰ２にアップデートすることを決定する。サーバＳ４が空いているので、このサーバを利用して、サーバＳ１と同じソフトウェア構成で、かつ、ＡＰ１がＡＰ２にアップデートされた状態を作り出すことにする。サーバＳ４には既にＯＳ１がインストールされているがＡＰ１がインストールされていないので、図１２に示すように、サーバＳ４にＡＰ１をインストールする。

次に、図１３に示すように、サーバＳ４のＡＰ１にパッチを適用してＡＰ２にアップデートし、サーバＳ１の動的アサインをサーバＳ４に切り替える。これにより、図１４に示すように、サーバＳ４は顧客Ａに割り当てられてクリーンな稼動状態になり、サーバＳ１は空きサーバとなる。

次に、動的アサイン管理部２０６は、サーバＳ２のＡＰ１をＡＰ２にアップデートすることを決定する。サーバＳ１が空いているので、このサーバを利用して、サーバＳ２と同じソフトウェア構成で、かつ、ＡＰ１がＡＰ２にアップデートされた状態を作り出すことにする。サーバＳ１には既にＯＳ１とＡＰ１がインストールされているので、図１５に示すように、サーバＳ１のＡＰ１をＡＰ２にアップデートし、サーバＳ２の動的アサインをサーバＳ１に切り替える。これにより、図１６に示すように、サーバＳ１は再び顧客Ａに割り当てられてクリーンな稼動状態になり、サーバＳ２は空きサーバとなる。

次に、動的アサイン管理部２０６は、サーバＳ６のＡＰ１をＡＰ２にアップデートすることを決定する。サーバＳ２が空いているので、このサーバを利用して、サーバＳ６と同じソフトウェア構成で、かつ、ＡＰ１がＡＰ２にアップデートされた状態を作り出すことにする。サーバＳ２にはＯＳ１とＡＰ１がインストールされているが、必要なのはＯＳ２とＡＰ２がインストールされた状態である。そこで、図１７に示すように、まず、ＯＳ１をＯＳ２にアップデートし、次に、ＡＰ１をＡＰ２にアップデートして、サーバＳ６の動的アサインをサーバＳ２に切り替える。これにより、図１８に示すように、サーバＳ２は顧客Ｂに割り当てられてクリーンな稼動状態になり、サーバＳ６は空きサーバとなる。こうして、稼動中のすべてのＡＰ１についてＡＰ２へのアップデートが完了する。

このような修正適用処理によれば、空きサーバを利用して緊急度の高い顧客システムから玉突き式にパッチを適用することで、パッチ適用のための無駄なシステム停止を最小限に抑えることが可能になる。空きサーバを常に１つ以上確保しておく必要があるので一見無駄が発生するように見えるが、実際には、この空きサーバを修正適用装置の様々な処理に利用することが可能である。例えば、空きサーバの能力を利用してクリーンポイント計算処理や動的アサイン管理を行えば、このサーバを有効に利用することができる。

図１０の修正適用処理では、既に顧客に割り当てられているソフトウェアに対してパッチが適用されているが、空きサーバを利用すれば、まだ顧客に割り当てられていないソフトウェアに対しても事前にパッチを適用しておくことが可能である。これにより、実際にシステムが稼動している状態で、あらかじめ空きサーバにアップデートされたソフトウェアを用意しておくことができ、システムがクリーンな状態に保たれる。したがって、次に顧客への動的アサインが発生したときに、迅速にクリーンなリソースを割り当てることが可能になる。

図１９は、このような事前修正適用処理のフローチャートである。この処理は、例えば、図１０の修正適用処理の後で引き続いて行われる。動的アサイン管理部２０６は、まず、動的アサイン表２１３を参照して空きサーバがあるか否かをチェックし（ステップ１９０１）、空きサーバがなければそのまま処理を終了する。

空きサーバがあれば、動的アサイン表２１３を参照して、そのサーバにパッチの適用対象となるソフトウェアがあるか否かをチェックし（ステップ１９０２）、対象ソフトウェアがなければ、そのソフトウェアを空きサーバにインストールする（ステップ１９０３）。そして、空きサーバ上で対象ソフトウェアにパッチを適用してそのソフトウェアをアップデートする（ステップ１９０４）。

次に、他の対象ソフトウェアがあるか否かをチェックし（ステップ１９０５）、そのようなソフトウェアがあれば、そのソフトウェアについてステップ１９０１以降の処理を繰り返す。そして、すべての対象ソフトウェアについて処理が終了すると、現状のシステム構成に合わせて動的アサイン表２１３およびアップデート適用表２１４を書き換えて、事前修正適用処理を終了する。

例えば、サーバＳ１〜Ｓ８からなる共用サーバプールにおいて、図２０のような状態でシステムが稼動していたとする。この状態では、サーバＳ１、Ｓ２、およびＳ３が顧客Ａに割り当てられており、サーバＳ５およびＳ６が顧客Ｂに割り当てられており、サーバＳ７が顧客Ｃに割り当てられている。サーバＳ４およびＳ８は空きサーバである。

サーバＳ１およびＳ２ではオペレーティングシステムＯＳ１とアプリケーションＡＰ１が稼動しており、サーバＳ３ではオペレーティングシステムＯＳ１とデータベースＤＢ１が稼動しており、サーバＳ４ではオペレーティングシステムＯＳ２とアプリケーションＡＰ１が稼動している。また、サーバＳ５ではオペレーティングシステムＯＳ２のみが稼動しており、サーバＳ６ではオペレーティングシステムＯＳ２とデータベースＤＢ２が稼動している。さらに、サーバＳ７ではオペレーティングシステムＯＳ１とデータベースＤＢ２が稼動しており、サーバＳ８ではオペレーティングシステムＯＳ２のみが稼動している。データベースＤＢ２は、データベースＤＢ１の新しいバージョンに相当する。

ここで、ＡＰ１およびＤＢ２に対してアップデート用のパッチが発行された場合、以下のような手順で事前修正適用処理が行われる。
動的アサイン管理部２０６は、まず、空きサーバＳ４を検出する。サーバＳ４では既にＯＳ２とＡＰ１が稼動しているので、ＡＰ１にパッチを適用してＡＰ２にアップデートする。

次に、空きサーバＳ８を検出する。サーバＳ８ではＯＳ２のみが稼動しているが、ＡＰ１に対するパッチは既にサーバＳ４で適用済みなので、サーバＳ８はＤＢ２に対するパッチを適用するために利用することにする。そこで、まず、サーバＳ８にＤＢ２をインストールし、次に、そのＤＢ２にパッチを適用してＤＢ３にアップデートする。

こうして、共用サーバプールには、ＡＰ１およびＤＢ２の最新バージョンであるＡＰ２およびＤＢ３の稼動状態が実現される。ここで仮に、ＯＳ２とＡＰ２を必要とする顧客への動的アサインが発生すれば、即座にサーバＳ４をその顧客に割り当てることができ、ＯＳ２とＤＢ３を必要とする顧客への動的アサインが発生すれば、即座にサーバＳ８をその顧客に割り当てることができる。

ところで、図２の修正適用装置および各サーバは、例えば、図２１に示すような情報処理装置（コンピュータ）を用いて構成することができる。図２１の情報処理装置は、ＣＰＵ２１０１、メモリ２１０２、入力装置２１０３、出力装置２１０４、外部記憶装置２１０５、媒体駆動装置２１０６、ネットワーク接続装置２１０７を備え、それらはバス２１０８により互いに接続されている。

メモリ２１０２は、例えば、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）等を含み、処理に用いられるプログラムおよびデータを格納する。ＣＰＵ２１０１は、メモリ２１０２を利用してプログラムを実行することにより、必要な処理を行う。

図２のパッチ情報解釈部２０３、２０４、パッチデータ管理部２０５、および動的アサイン管理部２０６は、メモリ２１０２に格納されたプログラムを実行することにより実現される機能に対応する。また、図２の顧客使用ソフトウェア一覧表２１２、動的アサイン表２１３、およびアップデート適用表２１４と図３のパッチ情報解釈対応表３０２は、メモリ２１０２に格納されたデータに対応する。

入力装置２１０３は、例えば、キーボード、ポインティングデバイス、タッチパネル等であり、オペレータからの指示や情報の入力に用いられる。出力装置２１０４は、例えば、ディスプレイ、プリンタ、スピーカ等であり、オペレータへの問い合わせや処理結果の出力に用いられる。

外部記憶装置２１０５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置２１０５に、上記プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ２１０２にロードして使用する。また、外部記憶装置２１０５は、図２のデータベース２１１としても使用される。

媒体駆動装置２１０６は、可搬記録媒体２１０９を駆動し、その記録内容にアクセスする。可搬記録媒体２１０９は、メモリカード、フレキシブルディスク、ＣＤ−ＲＯＭ（compact disk read only memory ）、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体である。オペレータは、この可搬記録媒体２１０９に上記プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ２１０２にロードして使用する。

ネットワーク接続装置２１０７は、ＬＡＮ（local area network）等の任意の通信ネットワークに接続され、通信に伴うデータ変換を行う。情報処理装置は、必要に応じて、上記プログラムおよびデータを外部の装置からネットワーク接続装置２１０７を介して受け取り、それらをメモリ２１０２にロードして使用する。また、ネットワーク接続装置２１０７は、パッチ情報やパッチデータを受信するためにも使用される。

図２２は、図２１の情報処理装置にプログラムおよびデータを供給することのできるコンピュータ読み取り可能な記録媒体を示している。可搬記録媒体２１０９やサーバ２２０１のデータベース２２０３に格納されたプログラムおよびデータは、情報処理装置２２０２のメモリ２１０２にロードされる。サーバ２２０１は、そのプログラムおよびデータを搬送する搬送信号を生成し、ネットワーク上の任意の伝送媒体を介して情報処理装置２２０２に送信する。ＣＰＵ２１０１は、そのデータを用いてそのプログラムを実行し、必要な処理を行う。

（付記１） ソフトウェアを複数のサーバに動的に割り当てて顧客サービスを行うシステムにおいてソフトウェアに修正情報を適用する修正適用装置であって、
前記修正情報の発行時に提供される情報を用いて、顧客が使用しているソフトウェアの新しさと該ソフトウェアのセキュリティレベルを統合した指標を計算する計算手段と、
前記顧客により指定された、前記指標に対する制約条件を格納する格納手段と、
計算された指標が前記制約条件を満たすか否かをチェックし、該計算された指標が該制約条件を満たさなければ、前記顧客が使用しているソフトウェアに前記修正情報を適用して該ソフトウェアをアップデートする適用手段と
を備えることを特徴とする修正適用装置。

（付記２） ソフトウェアを複数のサーバに動的に割り当てて顧客サービスを行うシステムにおいてソフトウェアに修正情報を適用するコンピュータのためのプログラムであって、
前記修正情報の発行時に提供される情報を用いて、顧客が使用しているソフトウェアの新しさと該ソフトウェアのセキュリティレベルを統合した指標を計算し、
前記顧客により指定された、前記指標に対する制約条件を格納手段から読み出し、
計算された指標が前記制約条件を満たすか否かをチェックし、
前記計算された指標が前記制約条件を満たさなければ、前記顧客が使用しているソフトウェアに前記修正情報を適用して該ソフトウェアをアップデートする
処理を前記コンピュータに実行させることを特徴とするプログラム。

（付記３） いずれの顧客にも割り当てられていない空きサーバ上に、前記顧客が使用しているソフトウェアが稼動している処理対象サーバと同じソフトウェア構成を用意し、該空きサーバ上で該顧客が使用しているソフトウェアに前記修正情報を適用し、該処理対象サーバの代わりに該空きサーバを該顧客に割り当てることで、該ソフトウェアをアップデートする処理を前記コンピュータに実行させることを特徴とする付記２記載のプログラム。

（付記４） いずれの顧客にも割り当てられていない空きサーバ上で、いずれの顧客にも割り当てられていないソフトウェアに前記修正情報を適用して該ソフトウェアをアップデートし、該ソフトウェアを必要とする顧客が現れたとき該空きサーバを該顧客に割り当てる処理を前記コンピュータに実行させることを特徴とする付記２記載のプログラム。

（付記５） 前記修正情報の発行時に提供される情報から該修正情報の日付および重要度の情報を抽出し、抽出された情報を用いて前記指標を計算する処理を前記コンピュータに実行させることを特徴とする付記２記載のプログラム。

（付記６） 前記修正情報が適用されるソフトウェアの複数のバージョンのうち前記顧客が使用しているバージョンについて前記指標を計算し、該顧客が使用しているバージョンの指標が前記制約条件を満たさなければ、該バージョンに該修正情報を適用する処理を前記コンピュータに実行させることを特徴とする付記２記載のプログラム。

（付記７） ソフトウェアを複数のサーバに動的に割り当てて顧客サービスを行うシステムにおいてソフトウェアに修正情報を適用するコンピュータのためのプログラムを記録した記録媒体であって、
前記プログラムが、
前記修正情報の発行時に提供される情報を用いて、顧客が使用しているソフトウェアの新しさと該ソフトウェアのセキュリティレベルを統合した指標を計算し、
前記顧客により指定された、前記指標に対する制約条件を格納手段から読み出し、
計算された指標が前記制約条件を満たすか否かをチェックし、
前記計算された指標が前記制約条件を満たさなければ、前記顧客が使用しているソフトウェアに前記修正情報を適用して該ソフトウェアをアップデートする
処理を前記コンピュータに実行させることを特徴とするコンピュータ読み取り可能な記録媒体。

（付記８） ソフトウェアを複数のサーバに動的に割り当てて顧客サービスを行うシステムにおいてソフトウェアに修正情報を適用するコンピュータのためのプログラムを搬送する搬送信号であって、
前記プログラムが、
前記修正情報の発行時に提供される情報を用いて、顧客が使用しているソフトウェアの新しさと該ソフトウェアのセキュリティレベルを統合した指標を計算し、
前記顧客により指定された、前記指標に対する制約条件を格納手段から読み出し、
計算された指標が前記制約条件を満たすか否かをチェックし、
前記計算された指標が前記制約条件を満たさなければ、前記顧客が使用しているソフトウェアに前記修正情報を適用して該ソフトウェアをアップデートする
処理を前記コンピュータに実行させることを特徴とする搬送信号。
（付記９） ソフトウェアを複数のサーバに動的に割り当てて顧客サービスを行うシステムにおいてソフトウェアに修正情報を適用する修正適用方法であって、
計算手段が、前記修正情報の発行時に提供される情報を用いて、顧客が使用しているソフトウェアの新しさと該ソフトウェアのセキュリティレベルを統合した指標を計算し、
適用手段が、前記顧客により指定された、前記指標に対する制約条件を格納手段から読み出し、
前記適用手段が、計算された指標が前記制約条件を満たすか否かをチェックし、該計算された指標が該制約条件を満たさなければ、前記顧客が使用しているソフトウェアに前記修正情報を適用して該ソフトウェアをアップデートする
ことを特徴とする修正適用方法。

多数の顧客システムを取り扱うデータセンタに本発明を適用すれば、稼動中のサービスを停止させることなく、コンピュータリソースが自動的にクリーンな状態に保たれる。

本発明の修正適用装置の原理図である。 修正適用装置の構成図である。 パッチ情報解釈部の処理を示す図である。 パッチ情報を示す図である。 パッチ情報解釈処理のフローチャートである。 クリーンポイントの計算方法を示す図である。 顧客使用ソフトウェア一覧表を示す図である。 動的アサイン表を示す図である。 アップデート適用表を示す図である。 修正適用処理のフローチャートである。 共用サーバプールの第１の状態を示す図である。 共用サーバプールの第２の状態を示す図である。 共用サーバプールの第３の状態を示す図である。 共用サーバプールの第４の状態を示す図である。 共用サーバプールの第５の状態を示す図である。 共用サーバプールの第６の状態を示す図である。 共用サーバプールの第７の状態を示す図である。 共用サーバプールの第８の状態を示す図である。 事前修正適用処理のフローチャートである。 事前修正適用処理を示す図である。 情報処理装置の構成図である。 記録媒体を示す図である。 サーバ共用システムを示す図である。

符号の説明

１０１ 計算手段
１０２ 格納手段
１０３ 適用手段
１０４−１、１０４−２、１０４−ｍ サーバ
１０５ ソフトウェア
１０６ 制約条件
２０１、２０２ パッチ提供元
２０３、２０４ パッチ情報解釈部
２０５ パッチデータ管理部
２０６ 動的アサイン管理部
２０７ 共用サーバプール
２１１ データベース
２１２ 顧客使用ソフトウェア一覧表
２１３ 動的アサイン表
２１４ アップデート適用表
３０１ パッチ情報
３０２ パッチ情報解釈対応表
３０３ パッチ管理情報
３０４、４０９ パッチデータ
４０１ 発行日
４０２ 影響ソフトウェア名
４０３ セキュリティレベル
４０４ ダウンロード情報
４０５ 日付
４０６ ソフトウェア名
４０７ 重要度
４０８ バージョン
７０１、７０２、７０３、８０１、８０２、８０３、８０４、９０１、９０２、９０３、９０４ エントリ
２１０１ ＣＰＵ
２１０２ メモリ
２１０３ 入力装置
２１０４ 出力装置
２１０５ 外部記憶装置
２１０６ 媒体駆動装置
２１０７ ネットワーク接続装置
２１０８ バス
２１０９ 可搬記録媒体
２２０１ サーバ
２２０２ 情報処理装置
２２０３ データベース

Claims (4)

1. 複数のサーバとネットワーク環境により接続され、該複数のサーバの各々を複数の顧客のいずれかに動的に割り当て、それぞれのサーバで稼動しているソフトウェアに修正情報を適用する修正適用装置であって、
   既に発行された修正情報の適用対象ソフトウェア名、発行日、重要度、およびバージョンの対応関係を示す管理情報と、顧客名、使用ソフトウェア名、および顧客指定の閾値を含む制約条件の対応関係を示す顧客使用ソフトウェア一覧表と、サーバ名、顧客名、インストールソフトウェア名、およびバージョンの対応関係を示す動的アサイン表とを格納する格納手段と、
   新たな修正情報の発行時に前記管理情報を参照して、該新たな修正情報の適用対象ソフトウェア名に対応するソフトウェアのそれぞれのバージョンについて、発行日に対応する基本ポイントを計算し、得られた基本ポイントを該それぞれのバージョンの重要度に応じて変更することで、該それぞれのバージョンの指標を計算する計算手段と、
   前記顧客使用ソフトウェア一覧表を参照して、前記新たな修正情報の適用対象ソフトウェア名と同じ使用ソフトウェア名に対応する顧客名および制約条件を取得し、前記動的アサイン表を参照して、該適用対象ソフトウェア名と同じインストールソフトウェア名に対応する顧客名およびバージョンを取得し、顧客名毎に、取得したバージョンについて計算された指標を取得した制約条件の閾値と比較して、該計算された指標が該制約条件を満たすか否かをチェックし、該計算された指標が該制約条件を満たさなければ、該動的アサイン表を参照して、該適用対象ソフトウェア名と同じインストールソフトウェア名に対応するサーバ名を取得し、取得したサーバ名のサーバで稼動している該インストールソフトウェアに該新たな修正情報を適用して該インストールソフトウェアをアップデートする適用手段と
   を備えることを特徴とする修正適用装置。
2. 複数のサーバとネットワーク環境により接続され、該複数のサーバの各々を複数の顧客のいずれかに動的に割り当て、それぞれのサーバで稼動しているソフトウェアに修正情報を適用するコンピュータのためのプログラムであって、
   既に発行された修正情報の適用対象ソフトウェア名、発行日、重要度、およびバージョンの対応関係を示す管理情報と、顧客名、使用ソフトウェア名、および顧客指定の閾値を含む制約条件の対応関係を示す顧客使用ソフトウェア一覧表と、サーバ名、顧客名、インストールソフトウェア名、およびバージョンの対応関係を示す動的アサイン表とを格納する格納手段と、
   新たな修正情報の発行時に前記管理情報を参照して、該新たな修正情報の適用対象ソフトウェア名に対応するソフトウェアのそれぞれのバージョンについて、発行日に対応する基本ポイントを計算し、得られた基本ポイントを該それぞれのバージョンの重要度に応じて変更することで、該それぞれのバージョンの指標を計算する計算手段と、
   前記顧客使用ソフトウェア一覧表を参照して、前記新たな修正情報の適用対象ソフトウェア名と同じ使用ソフトウェア名に対応する顧客名および制約条件を取得し、前記動的アサイン表を参照して、該適用対象ソフトウェア名と同じインストールソフトウェア名に対応する顧客名およびバージョンを取得し、顧客名毎に、取得したバージョンについて計算された指標を取得した制約条件の閾値と比較して、該計算された指標が該制約条件を満たすか否かをチェックし、該計算された指標が該制約条件を満たさなければ、該動的アサイン表を参照して、該適用対象ソフトウェア名と同じインストールソフトウェア名に対応するサーバ名を取得し、取得したサーバ名のサーバで稼動している該インストールソフトウェアに該新たな修正情報を適用して該インストールソフトウェアをアップデートする適用手段として、
   前記コンピュータを機能させることを特徴とするプログラム。
3. 前記適用手段は、いずれの顧客も前記新たな修正情報の適用対象ソフトウェア名のソフトウェアを使用していないとき、いずれの顧客にも割り当てられていない空きサーバ上で、該ソフトウェアに該新たな修正情報を適用して該ソフトウェアをアップデートし、該ソフトウェアを必要とする顧客が現れたとき該空きサーバを該顧客に割り当てることを特徴とする請求項２記載のプログラム。
4. 複数のサーバとネットワーク環境により接続され、格納手段、計算手段、および適用手段を備える修正適用装置が、該複数のサーバの各々を複数の顧客のいずれかに動的に割り当て、それぞれのサーバで稼動しているソフトウェアに修正情報を適用する修正適用方法であって、
   前記計算手段が、前記格納手段に格納された、既に発行された修正情報の適用対象ソフトウェア名、発行日、重要度、およびバージョンの対応関係を示す管理情報を、新たな修正情報の発行時に参照して、該新たな修正情報の適用対象ソフトウェア名に対応するソフトウェアのそれぞれのバージョンについて、発行日に対応する基本ポイントを計算し、得られた基本ポイントを該それぞれのバージョンの重要度に応じて変更することで、該それぞれのバージョンの指標を計算し、
   前記適用手段が、前記格納手段に格納された、顧客名、使用ソフトウェア名、および顧客指定の閾値を含む制約条件の対応関係を示す顧客使用ソフトウェア一覧表を参照して、前記新たな修正情報の適用対象ソフトウェア名と同じ使用ソフトウェア名に対応する顧客名および制約条件を取得し、前記格納手段に格納された、サーバ名、顧客名、インストールソフトウェア名、およびバージョンの対応関係を示す動的アサイン表を参照して、該適用対象ソフトウェア名と同じインストールソフトウェア名に対応する顧客名およびバージョンを取得し、顧客名毎に、取得したバージョンについて計算された指標を取得した制約条件の閾値と比較して、該計算された指標が該制約条件を満たすか否かをチェックし、該計算された指標が該制約条件を満たさなければ、該動的アサイン表を参照して、該適用対象ソフトウェア名と同じインストールソフトウェア名に対応するサーバ名を取得し、取得したサーバ名のサーバで稼動している該インストールソフトウェアに該新たな修正情報を適用して該インストールソフトウェアをアップデートする
   ことを特徴とする修正適用方法。

Images