JP2016004349A - ソフトウェア情報管理プログラム、ソフトウェア情報管理装置およびソフトウェア情報管理方法 - Google Patents

Abstract

【課題】管理対象のコンピュータのファイルや設定を、ソフトウェアと対応づけて管理すること。【解決手段】記憶部１ａは、ソフトウェアαのプログラムを記憶する。演算部１ｂは、ソフトウェアαのインストールの際に、ソフトウェアαのインストーラが生成するプロセスＰ１，Ｐ２，Ｐ３を監視する。演算部１ｂは、生成されたプロセスＰ１，Ｐ２，Ｐ３それぞれがアクセスしたファイルＦ１，Ｆ２，Ｆ３それぞれのファイル情報、および、プロセス間の関係に基づき、ファイルＦ１，Ｆ２，Ｆ３に対応する複数のファイル情報を、ソフトウェアαに関連づけた、ソフトウェア構成情報２を生成する。【選択図】図１

Description

本発明はソフトウェア情報管理プログラム、ソフトウェア情報管理装置およびソフトウェア情報管理方法に関する。

複数のコンピュータを含むシステムにおいて、各コンピュータで利用されるソフトウェアを管理することがある。例えば、ライセンス管理を目的として、ソフトウェア辞書を用いたインベントリ収集により、管理対象のコンピュータのファイルやレジストリ項目の存否から、管理対象のコンピュータにおけるソフトウェアの有無を特定する技術が知られている。インストール中のファイルやレジストリの変化をモニタする技術も知られている。

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

管理対象のコンピュータ数が増大したクラウド環境等において、各コンピュータにインストールされているソフトウェアの同一性を確認できることが求められている。
しかしながら、インベントリ収集やレジストリ情報の差分管理等で把握できる差分は、管理者が管理可能な単位（例えば、製品単位）よりもはるかに細かい単位となる。

そのため、インベントリ収集等により、コンピュータ間でファイルやレジストリ項目に相違が存在し、同一でないことが判明したとしても、個別のファイルやレジストリ項目と、管理者が管理可能な単位とは対応づけられていないため、どのような対処が必要であるか（逆引き）がわからない。

また、ソフトウェア辞書では、全ての製品について、個別のファイルとの対応づけが十分ではない。
従来技術として、インストールにより追加されたファイルの所有者等を特定するためにプロセスをモニタする技術が知られているが、上記同様、個別のファイルの属性を特定するにとどまっている。

１つの側面では、本発明は、管理対象のコンピュータのファイルや設定を、ソフトウェアと対応づけて管理することができるソフトウェア情報管理プログラム、ソフトウェア情報管理装置およびソフトウェア情報管理方法を提供することを目的とする。

１つの態様では、ソフトウェア情報管理プログラムが提供される。このソフトウェア情報管理プログラムは、コンピュータに、ソフトウェアのインストールの際に、ソフトウェアのインストーラが生成する複数のプロセスを監視し、生成された複数のプロセスそれぞれがアクセスした複数のファイルそれぞれのファイル情報、および、複数のプロセス間の関係に基づき、複数のファイルに対応する複数のファイル情報を、ソフトウェアに関連づけた、ソフトウェア構成情報を生成する、処理を実行させる。

また、１つの態様では、ソフトウェア情報管理装置が提供される。このソフトウェア情報管理装置は記憶部と演算部とを有する。記憶部は、ソフトウェアのプログラムを記憶する。演算部は、ソフトウェアのインストールの際に、ソフトウェアのインストーラが生成する複数のプロセスを監視し、生成された複数のプロセスそれぞれがアクセスした複数のファイルそれぞれのファイル情報、および、複数のプロセス間の関係に基づき、複数のファイルに対応する複数のファイル情報を、ソフトウェアに関連づけた、ソフトウェア構成情報を生成する。

また、１つの態様では、ソフトウェア情報管理方法が提供される。このソフトウェア情報管理方法では、コンピュータが、ソフトウェアのインストールの際に、ソフトウェアのインストーラが生成する複数のプロセスを監視し、生成された複数のプロセスそれぞれがアクセスした複数のファイルそれぞれのファイル情報、および、複数のプロセス間の関係に基づき、複数のファイルに対応する複数のファイル情報を、ソフトウェアに関連づけた、ソフトウェア構成情報を生成する。

１つの側面では、管理対象のコンピュータのファイルや設定を、ソフトウェアと対応づけて管理することができる。

第１の実施の形態のソフトウェア情報管理装置を示す図である。 第２の実施の形態の情報処理システムを示す図である。 サーバのハードウェア例を示す図である。 サーバおよび管理サーバの機能例を示す図である。 プロセスの監視例を示す図である。 インストールプロセス管理テーブルの例を示す図である。 コンポーネント構成管理テーブルの例を示す図である。 チェック開始時刻管理テーブルの例を示す図である。 ソフトウェア辞書テーブルの例を示す図である。 コンポーネント構成管理辞書テーブルの例を示す図である。 時間間隔テーブルの例を示す図である。 ファイル／レジストリの更新時刻の時系列の例を示す図である。 インストール時の処理例を示すフローチャートである。 ファイルアクセス時の処理例を示すフローチャートである。 レジストリアクセス時の処理例を示すフローチャートである。 チェック開始時刻の確認例を示すフローチャートである。 ソフトウェアの同一性チェックの例を示すフローチャートである。 スイート製品の検出例を示す図である。 ソフトウェアの同一性チェックの例を示す図である。 ソフトウェア辞書の拡張の例を示す図である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態のソフトウェア情報管理装置を示す図である。ソフトウェア情報管理装置１は、ソフトウェア情報管理装置１にインストールされるソフトウェアのソフトウェア構成情報を生成し、管理する。ソフトウェア構成情報は、ソフトウェアの識別情報とソフトウェアに関係する情報（ソフトウェアのプログラムやソフトウェアの処理に利用されるデータ等）とを関連づけた情報である。このような情報をインベントリ情報と呼ぶこともある。ソフトウェア情報管理装置１は、ソフトウェア情報管理装置１以外の装置にインストールされるソフトウェアのソフトウェア構成情報を管理してもよい。

ソフトウェア情報管理装置１は、記憶部１ａおよび演算部１ｂを有する。記憶部１ａは、ＲＡＭ（Random Access Memory）等の揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ等の不揮発性記憶装置でもよい。演算部１ｂは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等を含み得る。演算部１ｂはプログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。

記憶部１ａは、ソフトウェアαのプログラムを記憶する。ソフトウェアαのプログラムには、インストーラのプログラムも含まれる。インストーラのプログラムは、ソフトウェア情報管理装置１にソフトウェアαをインストールするためのプログラムである。例えば、演算部１ｂがインストーラのプログラムを実行することで、インストーラの機能がソフトウェア情報管理装置１上で発揮される。インストーラは、ソフトウェアαの処理に用いられるデータを、ソフトウェア情報管理装置１が備えるＨＤＤ等の記憶装置に配置する。

演算部１ｂは、ソフトウェアのインストールの際に、ソフトウェアのインストーラが生成する複数のプロセスを監視する。プロセスは、ソフトウェア情報管理装置１で実行されるオペレーティングシステム（ＯＳ：Operating System）によるプログラムの実行単位である。ソフトウェア情報管理装置１で実行されるＯＳは、あるソフトウェアのプログラムを実行するとき、プログラムを実行するためのプロセスを生成する。プロセスは、プログラムを実行するために割り当てられた種々のリソースの情報を含む。

例えば、ソフトウェアαのインストーラのプログラムがソフトウェア情報管理装置１で実行されるとき、ソフトウェア情報管理装置１のＯＳは、ソフトウェアαのインストーラのプログラムを実行するためのプロセスＰ１を生成する。ソフトウェアαが別のプログラムを呼び出すこともある。すなわち、プロセスＰ１（ソフトウェアαのインストーラ）により別のプロセスが生成され得る。

例えば、ソフトウェアαが、コンポーネントとなる他のソフトウェアを含む場合、ソフトウェアαのインストーラが、他のソフトウェアのインストーラのプログラムを呼び出す。すると、ＯＳは呼び出されたプログラムを実行するために、他のプロセスを生成する。例えば、ソフトウェアαのインストーラにより呼び出されたあるプログラムに対してプロセスＰ２を生成し、ソフトウェアαのインストーラにより呼び出された別のプログラムに対してプロセスＰ３を生成する。この場合、プロセスＰ１は、プロセスＰ２，Ｐ３の親プロセスである。プロセスＰ２，Ｐ３は、プロセスＰ１の子プロセスである。プロセスの親子関係は、ＯＳにより管理され得る。

演算部１ｂは、生成された複数のプロセスそれぞれがアクセスした複数のファイルそれぞれのファイル情報、および、複数のプロセス間の関係に基づき、複数のファイルに対応する複数のファイル情報を、ソフトウェアに関連づけた、ソフトウェア構成情報を生成する。

例えば、プロセスＰ１は、ファイルＦ１にアクセスする。プロセスＰ２は、ファイルＦ２にアクセスする。プロセスＰ３は、ファイルＦ３にアクセスする。ファイルＦ１，Ｆ２，Ｆ３は、例えばプログラムの実行可能コードやプログラムの処理に用いられるデータ等である。ファイル情報は、例えばファイルＦ１，Ｆ２，Ｆ３の識別情報である。ファイル情報は、ソフトウェア情報管理装置１におけるファイルＦ１，Ｆ２，Ｆ３のパス、更新日時およびサイズ等の情報を含み得る。

例えば、演算部１ｂは、プロセスＰ１，Ｐ２の親子関係、および、プロセスＰ１，Ｐ３の親子関係を特定する。前述のように各プロセスの親子関係はＯＳから取得される。演算部１ｂは、プロセスＰ１，Ｐ２の親子関係およびプロセスＰ１，Ｐ３の親子関係に基づき、ファイルＦ１，Ｆ２，Ｆ３それぞれのファイル情報を、ソフトウェアαに関連づけたソフトウェア構成情報２を生成する。すなわち、プロセスＰ１によりアクセスされたファイルＦ１のファイル情報だけでなく、プロセスＰ１の子プロセスであるプロセスＰ２によりアクセスされたファイルＦ２のファイル情報をソフトウェアαに関連づける。同様に、プロセスＰ１の子プロセスであるプロセスＰ３によりアクセスされたファイルＦ３のファイル情報をソフトウェアαに関連づける。

ソフトウェア情報管理装置１によれば、ソフトウェアαのインストールの際に、ソフトウェアαのインストーラが生成するプロセスＰ１，Ｐ２，Ｐ３が監視される。プロセスＰ１，Ｐ２，Ｐ３それぞれがアクセスしたファイルＦ１，Ｆ２，Ｆ３それぞれのファイル情報、および、プロセスＰ１，Ｐ２，Ｐ３間の関係に基づき、ファイルＦ１，Ｆ２，Ｆ３に対応する複数のファイル情報を、ソフトウェアαに関連づけた、ソフトウェア構成情報２が生成される。これにより、管理対象のコンピュータのファイルや設定を、ソフトウェアと対応づけて管理することができる。

ここで、管理対象のコンピュータ数が増大したクラウド環境等において、システムの安定稼働や保守作業の効率化の観点から、各コンピュータにインストールされているソフトウェアの同一性を確認できることが求められている。しかしながら、インベントリ収集等で把握できる差分は、管理者が管理可能な単位（例えば、製品単位）よりもはるかに細かい単位となる。

個別のファイルやレジストリ項目と、管理者が管理可能な単位とが対応づけられていなければ、インベントリ収集等によりコンピュータ間でファイルに相違が存在し、同一でないことが判明したとしても、どのような対処が必要であるか（逆引き）がわからない。

また、予め用意されたソフトウェア辞書では、全てのソフトウェア製品について、個別のファイルとの対応づけが十分に網羅されているとは限らない。例えば、ソフトウェアαが他のソフトウェアをコンポーネントとして含むスイート（Suite）製品である場合もある。この場合、単にソフトウェア毎にファイルの情報が対応づけられているのみでは、ソフトウェアαの処理に影響する他のソフトウェアのファイルを把握するのが容易でない。

そこで、ソフトウェア情報管理装置１では、ソフトウェアαのインストールの際に生成されたプロセス間の関係に基づいて、各プロセスがアクセスした各ファイルのファイル情報をソフトウェアαに対応づける。

ソフトウェアαのインストール時には、ソフトウェアαの動作に関連するファイルがソフトウェア情報管理装置１に一括して生成／変更される。このため、インストーラのプロセスＰ１およびインストーラのプロセスＰ１に関係するプロセスＰ２，Ｐ３によりアクセスされたファイルＦ１，Ｆ２，Ｆ３を、ソフトウェアαに対応づけることができる。

特に、ソフトウェアαが他のソフトウェアをコンポーネントとして含む場合、ソフトウェアαのインストール時に、ソフトウェアαのインストーラにより他のソフトウェアのインストールも行われる。この場合、ソフトウェアαのインストーラのプロセスＰ１が、他のソフトウェアのインストーラを起動する。すると、他のソフトウェアのインストーラを実行するためのプロセス（例えば、プロセスＰ２，Ｐ３）が生成される。

この場合、プロセスＰ２やプロセスＰ３は、プロセスＰ１の子プロセスとして管理される。したがって、プロセスＰ１の子プロセスであるプロセスＰ２，Ｐ３によりアクセスされたファイルＦ２，Ｆ３をソフトウェアαに対応づけることで、ソフトウェアαのコンポーネントとなる他のソフトウェアのファイルを、ソフトウェアαに対応づけることができる。

また、ソフトウェア情報管理装置１では、インストーラとは関係ないプロセスも多数存在している。ソフトウェア情報管理装置１は、ソフトウェアαに関係しないファイルを、プロセス間の関係に基づいて判断できる。例えば、ソフトウェア情報管理装置１は、プロセスＰ１と親子関係にないプロセスＰ４によりアクセスされたファイルＦ４のファイル情報を、ソフトウェアαに対応づけない。このため、余計なファイル情報がソフトウェアαに対応づけられてしまうことを防げる。このように、ソフトウェア情報管理装置１は、ソフトウェアαとファイルＦ１，Ｆ２，Ｆ３とを適切に対応づけることができる。

更に、ソフトウェア情報管理装置１は、既存のソフトウェア辞書にソフトウェアαの情報が予め登録されていなくても、ソフトウェアαに関連するファイル情報を取得できる。このため、ソフトウェア辞書の拡張を容易に行える。また、他の装置もソフトウェア構成情報を同様にして生成できる。

ソフトウェア情報管理装置１は、生成したソフトウェア辞書を用いて、他のコンピュータにインストールされたソフトウェアが、ソフトウェア辞書に登録されたソフトウェアと同一であるかを確認できる。特に、スイート製品のようなソフトウェアのグループ単位での同一性を確認できるようになる。例えば、複数のソフトウェアが、他のコンピュータにおいて、スイート製品としてまとめてインストールされたものか、それとも個別にインストールされたものかといった確認も可能となる。

なお、上記の例では、ソフトウェア情報管理装置１にソフトウェアαをインストールする場合を示したが、他の場合も考えられる。例えば、ソフトウェア情報管理装置１で動作する仮想マシンにソフトウェアαをインストールするときも、演算部１ｂは第１の実施の形態の処理を行える。その場合、ソフトウェア情報管理装置１で動作する複数の仮想マシン間で、インストールされたソフトウェアの同一性のチェックを行うことも考えられる。

［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、サーバ１００，１００ａ，１００ｂ、管理サーバ２００および端末装置２１，２２を含む。サーバ１００，１００ａ，１００ｂおよび管理サーバ２００は、ネットワーク１０に接続されている。ネットワーク１０は、例えば、ＬＡＮ（Local Area Network）である。ネットワーク１０は、ネットワーク２０に接続されている。ネットワーク２０は、例えば、ＷＡＮ（Wide Area Network）やインターネット等の広域ネットワークである。

サーバ１００，１００ａ，１００ｂは、端末装置２１，２２に対して所定のサービスを提供するサーバコンピュータである。例えば、サーバ１００，１００ａ，１００ｂには種々のソフトウェアがインストールされる。サーバ１００，１００ａ，１００ｂは、第１の実施の形態のソフトウェア情報管理装置１の一例と考えることができる。

管理サーバ２００は、サーバ１００，１００ａ，１００ｂにインストールされたソフトウェアのソフトウェア情報を一元管理するサーバコンピュータである。管理サーバ２００は、サーバ１００，１００ａ，１００ｂにインストールされたソフトウェアの同一性の管理も行う。

端末装置２１，２２は、ネットワーク１０，２０を介してサーバ１００，１００ａ，１００ｂにアクセスするクライアントコンピュータである。端末装置２１，２２それぞれのユーザは、ネットワーク１０，２０を介して、サーバ１００，１００ａ，１００ｂにインストールされたソフトウェアを利用できる。

図３は、サーバのハードウェア例を示す図である。サーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、読み取り装置１０６および通信インタフェース１０７を有する。各ユニットはサーバ１００のバスに接続されている。サーバ１００ａ，１００ｂおよび管理サーバ２００もサーバ１００と同様のハードウェアにより実現できる。

プロセッサ１０１は、サーバ１００の情報処理を制御する。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡ等である。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ等のうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、サーバ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。

ＨＤＤ１０３は、サーバ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）等の他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。

画像信号処理部１０４は、プロセッサ１０１からの命令に従って、サーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイ等を用いることができる。

入力信号処理部１０５は、サーバ１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２としては、例えば、マウスやタッチパネル等のポインティングデバイス、キーボード等を用いることができる。

読み取り装置１０６は、記録媒体１３に記録されたプログラムやデータを読み取る装置である。記録媒体１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤ等の磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）等の光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体１３として、例えば、フラッシュメモリカード等の不揮発性の半導体メモリを使用することもできる。読み取り装置１０６は、例えば、プロセッサ１０１からの命令に従って、記録媒体１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

通信インタフェース１０７は、ネットワーク１０を介して他の装置と通信を行う。通信インタフェース１０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。

図４は、サーバおよび管理サーバの機能例を示す図である。サーバ１００は、記憶部１１０、プロセス群１２０、ソフトウェア構成情報記憶部１３０、監視部１４０および生成部１５０を有する。記憶部１１０およびソフトウェア構成情報記憶部１３０は、ＲＡＭ１０２やＨＤＤ１０３に確保された記憶領域を用いて実現できる。監視部１４０および生成部１５０は、プロセッサ１０１によって実行されるプログラムのモジュールであってもよい。なお、サーバ１００ａ，１００ｂもサーバ１００と同様の機能を有している。

記憶部１１０は、各種ファイル（ソフトウェアのプログラムやレジストリなどのＯＳの設定項目を含む）を記憶する。
プロセス群１２０は、種々のプログラムを実行するためにＯＳが生成する複数のプロセスである。例えば、あるプログラムを実行するために、ＯＳはプロセスを生成する。プログラムはプロセスを用いて実行される。

例えば、ＯＳがプロセスを生成するタイミングとして、ＯＳ起動に伴い所定のプログラムを実行するタイミング、あるプログラムの実行をユーザによって指示されたタイミング、あるプロセスが他のプログラムを呼び出したタイミング等が考えられる。各プロセスは、プログラムを実行する際に、プログラムのファイル（例えば、実行可能コード）にアクセスする。また、各プロセスは、プログラムの実行に応じて、プログラムの処理に用いられる各種の設定を登録したファイルにアクセスすることもある。

ソフトウェア構成情報記憶部１３０は、ソフトウェア構成情報を記憶する。ソフトウェア構成情報は、ソフトウェアの識別情報とソフトウェアに関係する情報（ソフトウェアのプログラムやソフトウェアの処理に利用されるデータ等）とを関連づけた情報である。このような情報をインベントリ情報と呼ぶこともある。

監視部１４０は、プロセスの生成状況、プロセス間の関係、プロセスによる記憶部１１０へのアクセス状況を監視し、監視結果を生成部１５０に提供する。監視部１４０は、プロセス監視部１４１、ファイルアクセス監視部１４２およびレジストリアクセス監視部１４３を有する。

プロセス監視部１４１は、プロセスの生成状況およびプロセス間の関係を監視する。プロセス監視部１４１は、プロセスが生成された時刻やプロセス間の関係の情報をＯＳから取得し、生成部１５０に提供する。

ファイルアクセス監視部１４２は、プロセスによるファイルへのアクセスを監視する。ファイルアクセス監視部１４２は、プロセスによるファイルへのアクセスを検出し、アクセスしたプロセスやアクセス対象のファイル等の情報を生成部１５０に提供する。

レジストリアクセス監視部１４３は、プロセスによるレジストリへのアクセスを監視する。レジストリアクセス監視部１４３は、プロセスによるレジストリへのアクセスを検出し、アクセスしたプロセスやアクセス対象のレジストリ等の情報を生成部１５０に提供する。

生成部１５０は、監視部１４０による監視結果に基づいて、ソフトウェア構成情報を生成し、ソフトウェア構成情報記憶部１３０に格納する。監視部１４０による監視結果には、前述のプロセス監視部１４１、ファイルアクセス監視部１４２およびレジストリアクセス監視部１４３により提供される情報が含まれる。

具体的には、生成部１５０は、あるソフトウェアがインストールされるときに、該当のソフトウェアのインストーラのプロセスおよび当該プロセスに関連するプロセスの情報を取得する。更に、生成部１５０は、取得した各プロセスによってアクセスされたファイルの情報を取得する。生成部１５０は、取得した情報に基づいて、インストールされたソフトウェアと、インストールされたソフトウェアに関連するファイルやレジストリの情報とを対応づけることで、ソフトウェア構成情報を生成する。生成部１５０は、生成したソフトウェア構成情報を管理サーバ２００に送信する。

ここで、上記の説明ではサーバ１００の機能を説明したが、サーバ１００ａ，１００ｂもサーバ１００と同様の機能を有している。
管理サーバ２００は、記憶部２１０および管理部２２０を有する。記憶部２１０は、管理サーバ２００が備えるＲＡＭやＨＤＤに確保された記憶領域を用いて実現できる。管理部２２０は、管理サーバ２００が備えるプロセッサによって実行されるプログラムのモジュールであってもよい。

記憶部２１０は、サーバ１００，１００ａ，１００ｂから受信したソフトウェア構成情報を記憶する。記憶部２１０は、複数のソフトウェアに関するソフトウェア構成情報を記憶する。

管理部２２０は、記憶部２１０に記憶された情報に基づいて、サーバ１００，１００ａ，１００ｂに記憶されたソフトウェアの同一性をチェックする。管理部２２０は、サーバ１００，１００ａ，１００ｂにインストールされたソフトウェアの管理も行う。

図５は、プロセスの監視例を示す図である。プロセス群１２０は、プロセスＰｘ，Ｐａ，Ｐｂ，Ｐｃを含む。プロセスＰｘは、ソフトウェアＸのインストーラのプログラムを実行するためのプロセスである。ここで、ソフトウェアＸは、ソフトウェアＡ，Ｂ，Ｃを含むスイート製品である。

プロセスＰａは、ソフトウェアＡのインストーラのプログラムを実行するためのプロセスである。プロセスＰｂは、ソフトウェアＢのインストーラのプログラムを実行するためのプロセスである。プロセスＰｃは、ソフトウェアＣのインストーラのプログラムを実行するためのプロセスである。

プロセスＰｘは、プロセスＰａ，Ｐｂ，Ｐｃの親プロセスである。プロセスＰａ，Ｐｂ，Ｐｃは、プロセスＰｘの子プロセスである。
プロセス監視部１４１は、プロセスＰｘ，Ｐａ，Ｐｂ，Ｐｃの生成・消滅等を監視する。プロセス監視部１４１は、プロセスＰｘ，Ｐａ，Ｐｂ，Ｐｃの親子関係をＯＳに問い合わせることもある。

ファイルアクセス監視部１４２は、プロセスＰｘ，Ｐａ，Ｐｂ，Ｐｃによるファイルへのアクセス（ファイルアクセス）を監視する。プロセスＰｘ，Ｐａ，Ｐｂ，Ｐｃがアクセスするファイルには、インストーラプログラムのファイルやインストールされるファイル（インストールファイル）等が含まれる。

レジストリアクセス監視部１４３は、プロセスＰｘ，Ｐａ，Ｐｂ，Ｐｃによるレジストリへのアクセス（レジストリアクセス）を監視する。
図６は、インストールプロセス管理テーブルの例を示す図である。インストールプロセス管理テーブル１３１は、ソフトウェア構成情報記憶部１３０に記憶される。インストールプロセス管理テーブル１３１は、親プロセスＩＤ（IDentifier）、子プロセスＩＤ、ファイル情報格納先およびレジストリ情報格納先の項目を有する。

親プロセスＩＤには、親プロセスの識別情報が登録される。子プロセスＩＤの項目には、親プロセスに関連する子プロセスの識別情報が登録される。ファイル情報格納先の項目には、親プロセスおよび子プロセスによってアクセスされたファイルのファイル情報が登録される。ファイル情報には、プロセスの識別情報に対応づけて、各プロセスがアクセスしたファイルの情報（ファイル名、パスおよび更新日時等）が記録される。レジストリ情報格納先の項目には、親プロセスおよび子プロセスによってアクセスされたレジストリのレジストリ情報（レジストリ設定を識別する名称（レジストリ名）、パスおよび更新日時等）が登録される。レジストリ情報には、プロセスの識別情報に対応づけて、各プロセスがアクセスしたレジストリの情報が記録される。

例えば、インストールプロセス管理テーブル１３１には、親プロセスＩＤが“１２３４”、子プロセスＩＤが“１２３５”、“１２３６”、“１３００”、ファイル情報格納先が“ｆｉｌｅ００００．ｔｘｔ”、レジストリ情報格納先が“ｒｅｇ００００．ｔｘｔ”という情報が登録される。

これは、プロセスＩＤ“１２３４”のプロセスに対して、プロセスＩＤ“１２３５”、“１２３６”、“１３００”が子プロセスとして生成されたことを示す。また、これらのプロセスによってアクセスされたファイルのファイル情報が“ｆｉｌｅ００００．ｔｘｔ”であることを示す。ファイル情報“ｆｉｌｅ００００．ｔｘｔ”には、プロセスＩＤ“１２３５”、“１２３６”、“１３００”の各プロセスによってアクセスされたファイルのファイル名、パスおよび作成日時等が、プロセスＩＤに対応づけて記録されている。

更に、これらのプロセスによってアクセスされたレジストリのレジストリ情報が“ｒｅｇ００００．ｔｘｔ”であることを示す。レジストリ情報“ｒｅｇ００００．ｔｘｔ”には、プロセスＩＤ“１２３５”、“１２３６”、“１３００”の各プロセスによってアクセスされたレジストリのレジストリ名、パスおよび作成日時等が、プロセスＩＤに対応づけて記録されている。なお、子プロセスＩＤの項目における設定“−”（ハイフン）は、設定なしを示している。

図７は、コンポーネント構成管理テーブルの例を示す図である。コンポーネント構成管理テーブル１３２は、ソフトウェア構成情報記憶部１３０に記憶される。コンポーネント構成管理テーブル１３２は、プロセスＩＤ、最初に更新されたファイルまたはレジストリ名、最後に更新されたファイルまたはレジストリ名、更新時刻（最初）、更新時刻（最後）の項目を含む。

プロセスＩＤの項目には、プロセスの識別情報が登録される。最初に更新されたファイルまたはレジストリ名の項目には、当該プロセスによって最初に更新されたファイルまたはレジストリの名称（識別情報）が登録される。最後に更新されたファイルまたはレジストリ名の項目には、当該プロセスによって最後に更新されたファイルまたはレジストリの名称が登録される。なお、「更新」は、新たなファイル／レジストリ設定の生成、または、既存のファイル／レジストリ設定の変更の何れかである。更新時刻（最初）の項目には、最初に更新されたファイルまたはレジストリの更新時刻が登録される。更新時刻（最後）の項目には、最後に更新されたファイルまたはレジストリの更新時刻が登録される。

例えば、コンポーネント構成管理テーブル１３２には、プロセスＩＤが“１２３４”、最初に更新されたファイルまたはレジストリ名が“ａａａ”、最後に更新されたファイルまたはレジストリ名が“ｂｂｂ”、更新時刻（最初）が“１２：２１：１９：００”、更新時刻（最後）が“１２：３０：００：００”という情報が登録される。

これは、プロセスＩＤ“１２３４”のプロセスが、“ａａａ”の名称で示されるファイルまたはレジストリを最初に更新しており、当該最初の更新の時刻が１２時２１分１９秒であることを示す。また、プロセスＩＤ“１２３４”のプロセスが、“ｂｂｂ”の名称で示されるファイルまたはレジストリを最後に更新しており、当該最後の更新の時刻が１２時３０分００秒であることを示す。

図８は、チェック開始時刻管理テーブルの例を示す図である。チェック開始時刻管理テーブル１３３は、ソフトウェア構成情報記憶部１３０に記憶される。チェック開始時刻管理テーブル１３３は、起動順番、起動開始時刻およびプロセスＩＤの項目を含む。

起動順番の項目には、プロセス毎の起動された（生成された）順番（起動順番）が登録される。起動順番は１以上の整数であり、値が小さい程、早い時刻に起動されたことを示す。起動時刻の項目には、該当のプロセスの起動時刻が登録される。プロセスＩＤの項目には、プロセスの識別情報が登録される。

例えば、チェック開始時刻管理テーブル１３３には、起動順番が“１”、起動時刻が“１２：２１：１９：００”、プロセスＩＤが“１２３４”という情報が登録される。これは、プロセスＩＤ“１２３４”のプロセスが、起動順番“１”のプロセスであり、起動時刻が１２時２１分１９秒であることを示す。

プロセス監視部１４１は、チェック開始時刻管理テーブル１３３に登録された起動時刻のうち、最も古い起動時刻をチェック開始時刻とする。
図９は、ソフトウェア辞書テーブルの例を示す図である。ソフトウェア辞書テーブル１３４は、ソフトウェア構成情報記憶部１３０に記憶される。ソフトウェア辞書テーブル１３４は、ソフトウェア名、対応するスイート製品、ファイル情報格納先およびレジストリ情報格納先の項目を含む。

ソフトウェア名の項目には、ソフトウェアの名称が登録される。対応するスイート製品の項目には、該当のソフトウェアが属するスイート製品（ソフトウェア）の名称が登録される。ファイル情報格納先の項目には、該当のソフトウェアに関連するファイルに関する情報（ファイル情報）が登録される。レジストリ情報格納先の項目には、該当のソフトウェアに関連するレジストリに関する情報（レジストリ情報）が登録される。

例えば、ソフトウェア辞書テーブル１３４には、ソフトウェア名が“Ｘ”、対応するスイート製品が設定なし“−”（ハイフン）、ファイル情報格納先が“ｆｉｌｅ００００Ｘ．ｔｘｔ”、レジストリ情報格納先が“ｒｅｇ００００Ｘ．ｔｘｔ”という情報が登録される。これは、ソフトウェアＸに関連するファイル情報として“ｆｉｌｅ００００Ｘ．ｔｘｔ”が取得されていること、ソフトウェアＸに関連するレジストリ情報として“ｒｅｇ００００Ｘ．ｔｘｔ”が取得されていることを示す。ソフトウェアＸは、ソフトウェアＸ自身がスイート製品の名称なので、対応するスイート製品の項目は設定なしとなる。

また、ソフトウェア辞書テーブル１３４には、ソフトウェア名が“Ａ”、対応するスイート製品が“Ｘ”、ファイル情報格納先が“ｆｉｌｅ００００Ａ．ｔｘｔ”、レジストリ情報格納先が“ｒｅｇ００００Ａ．ｔｘｔ”という情報が登録される。これは、ソフトウェアＡに関連するファイル情報として“ｆｉｌｅ００００Ａ．ｔｘｔ”が取得されていること、ソフトウェアＡに関連するレジストリ情報として“ｒｅｇ００００Ａ．ｔｘｔ”が取得されていることを示す。また、ソフトウェアＡが属するスイート製品がソフトウェアＸであること、すなわち、ソフトウェアＡはソフトウェアＸのコンポーネントのソフトウェアであることを示す。

ソフトウェア辞書テーブル１３４の例では、ソフトウェアＡ，Ｂ，Ｃそれぞれのレコードに対し、対応するスイート製品としてソフトウェアＸが登録されている。このため、ソフトウェア辞書テーブル１３４により、ソフトウェアＡ，Ｂ，Ｃは、ソフトウェアＸのコンポーネントのソフトウェアであることが分かる。

図１０は、コンポーネント構成管理辞書テーブルの例を示す図である。コンポーネント構成管理辞書テーブル１３５は、ソフトウェア構成情報記憶部１３０に記憶される。コンポーネント構成管理辞書テーブル１３５は、ソフトウェア名、対応するスイート製品、最初に更新されたファイルまたはレジストリ名、最後に更新されたファイルまたはレジストリ名およびコンポーネントのインストール順序の項目を含む。

ソフトウェア名の項目には、ソフトウェアの名称が登録される。対応するスイート製品の項目には、該当のソフトウェアが属するスイート製品の名称が登録される。最初に更新されたファイルまたはレジストリ名、および、最後に更新されたファイルまたはレジストリ名の項目の設定内容は、コンポーネント構成管理テーブル１３２の同名の項目と同じである。コンポーネントのインストール順序の項目には、対応するスイート製品のインストールの際に、コンポーネントのソフトウェアがどの順番でインストールされたかを示す値が登録される。スイート製品本体を示すエントリに対しては、コンポーネントのインストール順序の設定値は設定なし“−”となる。

例えば、コンポーネント構成管理辞書テーブル１３５には、ソフトウェア名が“Ｘ”、対応するスイート製品が設定なし“−”、最初に更新されたファイルまたはレジストリ名が“ａａａ”、最後に更新されたファイルまたはレジストリ名が“ｂｂｂ”、コンポーネントのインストール順序が設定なし“−”という情報が登録される。これは、ソフトウェアＸが、“ａａａ”の名称で示されるファイルまたはレジストリを最初に更新することを示す。また、ソフトウェアＸが、“ｂｂｂ”の名称で示されるファイルまたはレジストリを最後に更新することを示す。ソフトウェアＸは、ソフトウェアＸ自身がスイート製品の名称なので、対応するスイート製品およびコンポーネントのインストール順序の項目は設定なしとなる。

また、コンポーネント構成管理辞書テーブル１３５には、ソフトウェア名が“Ａ”、対応するスイート製品が“Ｘ”、最初に更新されたファイルまたはレジストリ名が“ｃｃｃ”、最後に更新されたファイルまたはレジストリ名が“ｄｄｄ”、コンポーネントのインストール順序が“１”という情報が登録される。これは、ソフトウェアＡが、スイート製品であるソフトウェアＸのコンポーネントであること、ソフトウェアＸのインストール時に、コンポーネントとして１番目にインストールされることを示す。また、ソフトウェアＡが、“ｃｃｃ”の名称で示されるファイルまたはレジストリを最初に更新することを示す。更に、ソフトウェアＡが、“ｄｄｄ”の名称で示されるファイルまたはレジストリを最後に更新することを示す。

図１１は、時間間隔テーブルの例を示す図である。時間間隔テーブル１３６は、スイート製品のソフトウェアに対して、コンポーネントのソフトウェアがインストールされる時間間隔の情報を保持する。ここでいう時間間隔とは、あるコンポーネントのソフトウェアのインストールが完了してから、次のコンポーネントのソフトウェアのインストールが開始されるまでの時間間隔を示す。時間間隔テーブル１３６は、ソフトウェアの同一性をチェックするための情報として利用される。時間間隔テーブル１３６は、ソフトウェア構成情報記憶部１３０に記憶される。時間間隔テーブル１３６は、ソフトウェア名の項目、平均時間間隔および標準偏差の項目を含む。

ソフトウェア名の項目には、スイート製品のソフトウェア名が登録される。平均時間間隔の項目には、コンポーネントのソフトウェアがインストールされる時間間隔の平均値が登録される。

例えば、時間間隔テーブル１３６には、ソフトウェア名が“Ｘ”、平均時間間隔が“９ｓｅｃ”、標準偏差が“１ｓｅｃ”という情報が登録される。これは、ソフトウェアＸのコンポーネントであるソフトウェアＡ，Ｂ，Ｃをインストールする際の、ソフトウェアＡ，Ｂ，Ｃのインストールの時間間隔の平均が９秒であり、計測された時間間隔の標準偏差が１秒であることを示す。ここで、時間間隔の情報は、ソフトウェアＡ，Ｂ，Ｃそれぞれのインストーラによる、ファイルやレジストリの更新時刻に基づいて取得できる。

図１２は、ファイル／レジストリの更新時刻の時系列の例を示す図である。ソフトウェアＸのコンポーネントであるソフトウェアＡ，Ｂ，Ｃは、直列にインストールされる。複数のソフトウェアを並列にインストールすると、共通のファイルや共通のレジストリに対する複数のインストーラによる操作が競合する可能性があり、インストールの失敗や不具合の要因となり得るからである。ソフトウェアＸの例では、ソフトウェアＡ，Ｂ，Ｃの順番でインストールが行われる。インストール順序は、例えばソフトウェアＸのインストーラによって制御される。

時刻Ｔａ１は、ソフトウェアＡのインストーラによるファイルまたはレジストリの最初の更新時刻である。時刻Ｔａ２は、ソフトウェアＡのインストーラによるファイルまたはレジストリの最後の更新時刻である。この場合、ソフトウェアＡのインストーラは、ソフトウェアＡのインストールを、時刻Ｔａ１から時刻Ｔａ２の期間に行っていたことになる。

時刻Ｔｂ１は、ソフトウェアＢのインストーラによるファイルまたはレジストリの最初の更新時刻である。時刻Ｔｂ２は、ソフトウェアＢのインストーラによるファイルまたはレジストリの最後の更新時刻である。この場合、ソフトウェアＢのインストーラは、ソフトウェアＢのインストールを、時刻Ｔｂ１から時刻Ｔｂ２の期間に行っていたことになる。

時刻Ｔｃ１は、ソフトウェアＣのインストーラによるファイルまたはレジストリの最初の更新時刻である。時刻Ｔｃ２は、ソフトウェアＣのインストーラによるファイルまたはレジストリの最後の更新時刻である。この場合、ソフトウェアＣのインストーラは、ソフトウェアＣのインストールを、時刻Ｔｃ１から時刻Ｔｃ２の期間に行っていたことになる。

時刻Ｔａ２，Ｔｂ１の時間間隔ΔＴ１は、ソフトウェアＡ，Ｂそれぞれのインストール期間の間の時間間隔に相当する。時刻Ｔｂ２，Ｔｃ１の時間間隔ΔＴ２は、ソフトウェアＢ，Ｃそれぞれのインストール期間の間の時間間隔に相当する。時間間隔ΔＴ１，ΔＴ２の平均が平均時間間隔である。平均時間間隔に対して、時間間隔ΔＴ１，ΔＴ２の分散や標準偏差を求めることができる。コンポーネントのソフトウェアが４つ以上である場合も平均時間間隔や標準偏差等を求めることができる。

また、ソフトウェアＡ，Ｂ，Ｃの各インストーラによるファイルまたはレジストリの最初／最後の更新時刻の時系列により、ソフトウェアＡ，Ｂ，Ｃのインストール順序を判断できる。例えば、時刻Ｔａ１は、時刻Ｔｂ１，Ｔｃ１よりも前である。このため、ソフトウェアＡは、ソフトウェアＢ，Ｃよりも前にインストールされたことになる。同様に、時刻Ｔｂ１は、時刻Ｔｃ１よりも前である。このため、ソフトウェアＢは、ソフトウェアＣよりも前にインストールされたことになる。この場合、ソフトウェアＸのコンポーネントとしてのソフトウェアＡ，Ｂ，Ｃのインストール順序は、ソフトウェアＡが最初（１番目）、ソフトウェアＢが次（２番目）、ソフトウェアＣが最後（３番目）ということになる。

図１３は、インストール時の処理例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。以下では、ソフトウェアＸのインストールがサーバ１００により行われる場合を想定する。

（Ｓ１）監視部１４０は、イベントの発生の有無を検出する。イベントの種類は、何れかのプロセスによるファイルアクセス、レジストリアクセスおよび一定時間経過したことの何れかである。監視部１４０は、ファイルアクセスの発生を検出すると、処理をステップＳ２に進める。監視部１４０は、レジストリアクセスの発生を検出すると、処理をステップＳ３に進める。監視部１４０は、一定時間経過したことを検出すると、処理をステップＳ４に進める。ここで、「一定時間経過」とは、ソフトウェアＸのインストールが開始された時刻から一定時間が経過したこと、または、前回ステップＳ４を実行完了してから一定時間が経過したこと、の何れかである。「一定時間」の時間間隔としては、例えば、３０秒または１分等が考えられる。

（Ｓ２）監視部１４０は、ファイルアクセス時の処理を実行する。具体的には、アクセスされたファイルの種類やアクセス時刻、ファイルアクセスを行ったプロセスの特定、プロセスの親子関係の記録等を行う。詳細については、後述する。

（Ｓ３）監視部１４０は、レジストリアクセス時の処理を実行する。具体的には、アクセス時刻やレジストリアクセスを行ったプロセスの特定、プロセスの親子関係の記録等を行う。詳細については後述する。

（Ｓ４）監視部１４０は、チェック開始時刻の確認を行う。チェック開始時刻の確認は、ソフトウェアＸのインストーラとは明らかに関係のないプロセスを除外するために行われる。詳細については後述する。

このように、監視部１４０はソフトウェアＸのインストール開始に応じて、各プロセスによるファイルアクセスやレジストリアクセスを監視し、何れかのイベントを検出するたびに上記の手順を実行する。例えば、ユーザは、ソフトウェアＸのインストールを開始する際に、上記の監視を開始するようサーバ１００に指示することもできる。監視部１４０はソフトウェアＸのインストールが完了するまで（すなわち、ソフトウェアＸのインストーラのプロセスＰｘがＯＳにより消去されるまで）、上記の監視を行う。

図１４は、ファイルアクセス時の処理例を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。以下の手順は、図１３のステップＳ２に相当する。

（Ｓ１１）ファイルアクセス監視部１４２は、ファイルにアクセスしたプロセスのプロセスＩＤをプロセス監視部１４１に通知する。プロセス監視部１４１は、通知されたプロセスＩＤに対応するプロセスの起動時刻をＯＳから取得する。

（Ｓ１２）プロセス監視部１４１は、チェック開始時刻管理テーブル１３３を参照して、ステップＳ１１で取得した起動時刻が、チェック開始時刻管理テーブル１３３に登録された最も過去の起動時刻（チェック開始時刻）以降の時刻であるか否かを判定する。チェック開始時刻以降の時刻である場合、処理をステップＳ１３に進める。チェック開始時刻よりも前の時刻である場合、処理を終了する。

（Ｓ１３）プロセス監視部１４１は、着目するプロセスのプロセスＩＤ（子プロセスＩＤ）と当該プロセスの親プロセスのプロセスＩＤ（親プロセスＩＤ）とを取得する。着目するプロセスのプロセスＩＤは、ステップＳ１１においてファイルアクセス監視部１４２から通知されるプロセスＩＤである。プロセス監視部１４１は、当該プロセスＩＤに対応する親プロセスＩＤをＯＳから取得する。

（Ｓ１４）ファイルアクセス監視部１４２は、着目するプロセスによるアクセス先のファイルがインストールプログラムであるか否かを判定する。インストールプログラムである場合、処理をステップＳ１５に進める。インストールプログラムでない場合、処理をステップＳ１９に進める。例えば、ファイルアクセス監視部１４２は、アクセス先のファイルのファイル名やアクセスに用いられたコマンドによって本判定を行える。具体的には、ファイル名にｓｅｔｕｐ．ｅｘｅ等の文字列を含むファイル、ｍｓｉ形式やｒｐｍ形式のファイル（拡張子がｍｓｉやｒｐｍのファイル）およびｐｋｇａｄｄコマンドによりアクセスされるファイル等をインストールプログラムであると判定する。あるいは、ｔａｒ、ｚｉｐおよびｇｚｉｐ等のアーカイブ形式のファイルをインストールプログラムであると判定することも考えられる。

（Ｓ１５）プロセス監視部１４１は、着目するプロセスのプロセスＩＤ（ステップＳ１３の子プロセスＩＤ）と起動時刻（ステップＳ１１で取得した起動時刻）とを、チェック開始時刻管理テーブル１３３に登録する。

（Ｓ１６）生成部１５０は、プロセス監視部１４１およびファイルアクセス監視部１４２からステップＳ１１〜Ｓ１４で取得された情報を収集する。生成部１５０は、ステップＳ１３で取得された親プロセスＩＤが、インストールプロセス管理テーブル１３１の親プロセスＩＤの項目に登録されているか否かを判定する。登録されている場合、処理をステップＳ１７に進める。登録されていない場合、処理をステップＳ１８に進める。

（Ｓ１７）生成部１５０は、ステップＳ１３で取得された親プロセスＩＤに対応づけて、着目するプロセスのプロセスＩＤをインストールプロセス管理テーブル１３１に登録する。この場合、親プロセスＩＤは、インストールプロセス管理テーブル１３１に既に登録済であるから、当該親プロセスＩＤの子プロセスＩＤとして着目するプロセスのプロセスＩＤを登録すればよい。そして、処理を終了する。

（Ｓ１８）生成部１５０は、着目するプロセスのプロセスＩＤをインストールプロセス管理テーブル１３１の親プロセスＩＤの項目に登録する。例えば、ソフトウェアＸのインストーラのプロセスＰｘのように親プロセスとなり得るプロセスが本ステップで登録されることになる。そして、処理を終了する。

（Ｓ１９）生成部１５０は、プロセス監視部１４１およびファイルアクセス監視部１４２からステップＳ１１〜Ｓ１４で取得された情報を収集する。このとき、生成部１５０は、着目するプロセスによるファイルアクセスがファイルの更新（変更または生成の何れか）であるか否かという情報もファイルアクセス監視部１４２から取得する。生成部１５０は、ステップＳ１３で取得されたプロセスＩＤがインストールプロセス管理テーブル１３１の親プロセスＩＤまたは子プロセスＩＤの項目に登録されているか否かを判定する。登録されている場合、処理をステップＳ２０に進める。登録されていない場合、処理を終了する。

（Ｓ２０）生成部１５０は、着目するプロセスのプロセスＩＤに対応づけて、アクセスされたファイルのファイル情報を登録する。インストールプロセス管理テーブル１３１の例において、着目するプロセスのプロセスＩＤが“１２３５”であれば、生成部１５０は、“ｆｉｌｅ００００．ｔｘｔ”にファイル情報を登録することになる。

（Ｓ２１）生成部１５０は、着目するプロセスによるファイルアクセスがファイルの更新である場合、当該プロセスのプロセスＩＤに対応づけて、更新されたファイルのファイル名およびファイル更新時刻を、コンポーネント構成管理テーブル１３２に登録する。このとき、生成部１５０は、コンポーネント構成管理テーブル１３２に該当のプロセスのレコードが存在していないときは、最初のファイル更新として登録する。一方、該当のプロセスに対して、最初または最後の更新情報が登録済であれば、最後のファイル更新として登録する（最後のファイルやレジストリ更新に関する情報がある場合は上書きする）。なお、生成部１５０は、着目するプロセスによるファイルアクセスがファイルの更新でなければ（例えば、ファイルの読み出し等）、ステップＳ２１をスキップしてよい。そして、処理を終了する。

このようにして、サーバ１００は、インストーラのプロセス（インストールプロセス）の生成状況を管理する。また、サーバ１００は、インストーラのプロセスによるファイルアクセスを管理する。

なお、ステップＳ１１やステップＳ１３において、プロセス監視部１４１は、プロセスの起動時刻やプロセスの親子関係の情報をＯＳから取得するものとした。例えば、ＯＳがＷｉｎｄｏｗｓ（登録商標）であれば、ｗｍｉ（Windows Management Instrumentation）やｗｍｉｃ（Windows Management Instrumentation Command line）等を用いて、各プロセスの起動時間や、あるプロセスに対する親プロセス等の情報をＯＳから取得することが考えられる。また、例えばＯＳがＵＮＩＸ（登録商標）やＬｉｎｕｘ（登録商標）であれば、ｐｓコマンド等を用いて、各プロセスの起動時刻や親プロセス等の情報をＯＳから取得することが考えられる。

図１５は、レジストリアクセス時の処理例を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。以下の手順は、図１３のステップＳ３に相当する。

（Ｓ３１）レジストリアクセス監視部１４３は、レジストリにアクセスしたプロセスのプロセスＩＤをプロセス監視部１４１に通知する。プロセス監視部１４１は、通知されたプロセスＩＤに対応するプロセスの起動時刻をＯＳから取得する。

（Ｓ３２）プロセス監視部１４１は、チェック開始時刻管理テーブル１３３を参照して、ステップＳ３１で取得した起動時刻が、チェック開始時刻管理テーブル１３３に登録された最も過去の起動時刻（チェック開始時刻）以降の時刻であるか否かを判定する。チェック開始時刻以降の時刻である場合、処理をステップＳ３３に進める。チェック開始時刻よりも前の時刻である場合、処理を終了する。

（Ｓ３３）プロセス監視部１４１は、着目するプロセスのプロセスＩＤ（子プロセスＩＤ）と当該プロセスの親プロセスのプロセスＩＤ（親プロセスＩＤ）とを取得する。着目するプロセスのプロセスＩＤは、ステップＳ３１においてレジストリアクセス監視部１４３から通知されるプロセスＩＤである。プロセス監視部１４１は、当該プロセスＩＤに対応する親プロセスＩＤをＯＳから取得する。

（Ｓ３４）生成部１５０は、プロセス監視部１４１およびレジストリアクセス監視部１４３からステップＳ３１〜Ｓ３３で取得された情報を収集する。このとき、生成部１５０は、着目するプロセスによるレジストリアクセスがレジストリの設定内容の更新（変更または生成の何れか）であるか否かという情報もファイルアクセス監視部１４２から取得する。生成部１５０は、ステップＳ３３で取得されたプロセスＩＤがインストールプロセス管理テーブル１３１の親プロセスＩＤまたは子プロセスＩＤの項目に登録されているか否かを判定する。登録されている場合、処理をステップＳ３５に進める。登録されていない場合、処理をステップＳ３７に進める。

（Ｓ３５）生成部１５０は、着目するプロセスのプロセスＩＤに対応づけて、アクセスされたレジストリ情報を登録する。インストールプロセス管理テーブル１３１の例において、着目するプロセスのプロセスＩＤが“１２３５”であれば、生成部１５０は、“ｒｅｇ００００．ｔｘｔ”にレジストリ情報を登録することになる。

（Ｓ３６）生成部１５０は、着目するプロセスによるレジストリアクセスがレジストリにおける設定内容の更新である場合、当該プロセスのプロセスＩＤに対応づけて、更新されたレジストリのレジストリ名および更新時刻を、コンポーネント構成管理テーブル１３２に登録する。生成部１５０は、コンポーネント構成管理テーブル１３２に該当のプロセスのレコードが存在していないときは、最初のレジストリ更新として登録する。一方、該当のプロセスに対して最初または最後の更新情報が登録済であれば、最後のレジストリ更新として登録する（最後のファイルまたはレジストリ更新の情報がある場合は上書きする）。そして、処理を終了する。なお、生成部１５０は、着目するプロセスによるレジストリアクセスがレジストリ更新でなければ、ステップＳ３６をスキップし、処理を終了してよい。

（Ｓ３７）生成部１５０は、ステップＳ３３で取得された親プロセスＩＤがインストールプロセス管理テーブル１３１の親プロセスＩＤの項目に登録されているか否かを判定する。登録されている場合、処理をステップＳ３８に進める。登録されていない場合、処理を終了する。

（Ｓ３８）生成部１５０は、ステップＳ３３で取得された親プロセスＩＤに対応づけて、着目するプロセスのプロセスＩＤをインストールプロセス管理テーブル１３１に登録する。この場合、親プロセスＩＤは、インストールプロセス管理テーブル１３１に既に登録済であるから、当該親プロセスＩＤの子プロセスＩＤとして着目するプロセスのプロセスＩＤを登録すればよい。

（Ｓ３９）プロセス監視部１４１は、チェック開始時刻管理テーブル１３３に、着目するプロセスのプロセスＩＤ（ステップＳ３３の子プロセスＩＤ）と起動時刻（ステップＳ３１で取得した起動時刻）とを登録する。

このようにして、サーバ１００は、インストーラのプロセスによるレジストリアクセスを管理する。
図１６は、チェック開始時刻の確認例を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。以下の手順は、図１３のステップＳ４に相当する。

（Ｓ４１）プロセス監視部１４１は、チェック開始時刻管理テーブル１３３の先頭プロセスが既に終了しているか否かを判定する。ここで、チェック開始時刻管理テーブル１３３の先頭プロセスとは、起動順序の番号が最小のレコードのプロセスＩＤに対応するプロセスである。当該プロセスが既に終了している場合、処理をステップＳ４２に進める。当該プロセスが未だ終了していない場合、処理を終了する。

（Ｓ４２）プロセス監視部１４１は、チェック開始時刻管理テーブル１３３の先頭プロセスのエントリを削除する。
このようにして、サーバ１００は、チェック開始時刻管理テーブル１３３で管理されるチェック開始時刻を更新する。ここで、図１４のステップＳ１２や図１５のステップＳ３２の判定により、ソフトウェアＸのインストール開始前に起動されたプロセスによるファイルアクセスを処理の対象から除外できる。これにより、サーバ１００による処理量を低減でき、サーバ１００の負荷を軽減できる。

その後、ソフトウェアＸのインストールが完了すると、生成部１５０は、インストールプロセス管理テーブル１３１およびコンポーネント構成管理テーブル１３２に基づいて、ソフトウェア辞書テーブル１３４およびコンポーネント構成管理辞書テーブル１３５を生成し、ソフトウェア構成情報記憶部１３０に格納する。

具体的には、生成部１５０は、インストールプロセス管理テーブル１３１に登録された親プロセスＩＤと子プロセスＩＤとの関係から、スイート製品のソフトウェアと、コンポーネントのソフトウェアとを特定する。例えば、生成部１５０は、各プロセスに対応するファイル情報から、各プロセスによって更新されたファイルを特定する。そして、生成部１５０は、各プロセスによって更新されたファイルのヘッダ等を参照して、各プロセスに対応するソフトウェア名（製品名）やソフトウェアの製造元等の情報を特定する。また、生成部１５０は、図１２で例示したように、コンポーネントの各ソフトウェアによるファイルやレジストリの更新時刻から、コンポーネントの各ソフトウェアのインストール順序を把握できる。

更に、生成部１５０は、コンポーネント構成管理テーブル１３２に基づいて、時間間隔テーブル１３６を生成し、ソフトウェア構成情報記憶部１３０に格納する。具体的には、生成部１５０は、ソフトウェアＸのコンポーネントの各ソフトウェアによる、ファイルまたはレジストリの最初の更新時刻と最後の更新時刻とをコンポーネント構成管理テーブル１３２から取得できる。このため、生成部１５０は、図１２で例示したように各ソフトウェアのインストールの時間間隔ΔＴ１，ΔＴ２を計算でき、各時間間隔を用いて、平均時間間隔および標準偏差を求めることができる。

生成部１５０は、生成したソフトウェア辞書テーブル１３４、コンポーネント構成管理辞書テーブル１３５および時間間隔テーブル１３６を管理サーバ２００に送信する。
管理部２２０は、ソフトウェア辞書テーブル１３４、コンポーネント構成管理辞書テーブル１３５および時間間隔テーブル１３６を受信し、記憶部２１０に格納する。これにより、記憶部２１０にソフトウェアＸの情報が追加される。なお、管理部２２０は、ソフトウェアＸの情報をサーバ１００の識別情報に対応づけて記憶することで、サーバ１００にソフトウェアＸがインストールされていることを管理する。

ここで、以下の説明では、ソフトウェア辞書テーブル１３４と同様の情報を複数のスイート製品に関して登録した情報を、ソフトウェア辞書と称する。また、コンポーネント構成管理辞書テーブル１３５と同様の情報を複数のスイート製品に関して登録した情報を、コンポーネント構成管理辞書と称する。

そして、管理部２２０は、記憶部２１０に記憶されたソフトウェア辞書に基づいて、あるサーバ（例えば、サーバ１００）と他のサーバ（例えば、サーバ１００ａ）とにインストールされたソフトウェアの同一性のチェックを行える。

図１７は、ソフトウェアの同一性チェックの例を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。以下では、サーバ１００ａにインストールされたソフトウェアと、ソフトウェア辞書に登録済のソフトウェアとの同一性のチェックを行う場合を想定する。

（Ｓ５１）管理部２２０は、サーバ１００ａからインベントリ情報を収集する。インベントリ情報は、サーバ１００ａにインストールされているソフトウェアのファイル情報およびレジストリ情報を含む。

（Ｓ５２）管理部２２０は、取得したインベントリ情報と記憶部２１０に記憶されたソフトウェア辞書のファイル情報およびレジストリ情報とを比較し、サーバ１００ａにインストールされているソフトウェアを検出する。ソフトウェア辞書テーブル１３４の例によれば、ソフトウェアＡは、インストールの際に、ファイル情報“ｆｉｌｅ００００Ａ．ｔｘｔ”で示されるファイルおよびレジストリ情報“ｒｅｇ００００Ａ．ｔｘｔ”で示されるレジストリ設定を生成することが分かる。よって、ファイル情報“ｆｉｌｅ００００Ａ．ｔｘｔ”で示されるファイルおよびレジストリ情報“ｒｅｇ００００Ａ．ｔｘｔ”で示されるレジストリ設定が、サーバ１００ａのインベントリ情報で示されるファイル／レジストリ設定に全て含まれていれば、サーバ１００ａにソフトウェアＡがインストールされていることになる。他のソフトウェアについても同様である。

（Ｓ５３）管理部２２０は、記憶部２１０に記憶されたソフトウェア辞書からスイート製品のソフトウェア（着目するスイート製品）を１つ選択する。例えば、ソフトウェアＸを選択する。

（Ｓ５４）管理部２２０は、ステップＳ５２の検出結果を基に、着目するスイート製品に含まれる全ソフトウェアを検出したか否かを判定する。着目するスイート製品に含まれる全ソフトウェアを検出した場合、処理をステップＳ５５に進める。着目するスイート製品に対して、少なくとも何れかのソフトウェアを未検出の場合、処理をステップＳ５８に進める。例えば、着目するスイート製品がソフトウェアＸであるとき、サーバ１００ａのインベントリ情報からソフトウェアＸ，Ａ，Ｂ，Ｃを全て検出できていればステップＳ５５に進める。一方、ソフトウェアＸ，Ａ，Ｂ，Ｃのうち少なくとも何れかを検出できていなければ処理をステップＳ５８に進める。

（Ｓ５５）管理部２２０は、記憶部２１０に記憶されたコンポーネント構成管理辞書を参照して、着目するスイート製品のコンポーネントのソフトウェアにより最初／最後に更新されたファイルまたはレジストリ名を取得する。そして、ステップＳ５１で収集したサーバ１００ａのインベントリ情報に含まれる各ファイルやレジストリの更新時刻に基づき、ステップＳ５４で検出した各ソフトウェアのインストール順序を特定する。特定方法は、図１２の説明と同様である。

具体的には、サーバ１００ａのインベントリ情報には、各ファイルおよびレジストリ毎の更新時刻が含まれる。このため、管理部２２０は、各ソフトウェアが、どの時間帯にサーバ１００ａにインストールされたかを把握でき、インストールの時系列から、サーバ１００ａにおける各ソフトウェアのインストール順序を特定できる。管理部２２０は、記憶部２１０に記憶されたコンポーネント構成管理辞書を参照して、着目するスイート製品に対して取得済のインストール順序と、サーバ１００ａのインベントリ情報から取得したインストール順序とが一致するか否かを判定する。一致する場合、処理をステップＳ５６に進める。一致しない場合、処理をステップＳ５８に進める。ソフトウェアＸの例でいえば、コンポーネント構成管理辞書テーブル１３５から、ソフトウェアＡ，Ｂ，Ｃの順にインストールされることが分かる。サーバ１００ａのインベントリ情報から、ソフトウェアＡ，Ｂ，Ｃの順にインストールされたことが分かれば、インストール順序が一致していることになる。

（Ｓ５６）管理部２２０は、記憶部２１０に記憶されたコンポーネント構成管理辞書を参照して、着目するスイート製品に対応するコンポーネントのソフトウェアにより最初／最後に更新されたファイルまたはレジストリ名を取得する。そして、ステップＳ５１で収集したインベントリ情報に含まれる各ファイルやレジストリの更新時刻に基づき、ステップＳ５４で検出した各ソフトウェアのサーバ１００ａにおけるインストールの時間間隔を計算する。計算方法は、図１２の説明と同様である。管理部２２０は、記憶部２１０に記憶された時間間隔テーブル１３６を参照して、計算した各時間間隔が、着目するスイート製品に対して取得済の平均時間間隔と所定の誤差内で一致するか否かを判定する。一致する場合、処理をステップＳ５７に進める。一致しない場合、処理をステップＳ５８に進める。例えば、着目するスイート製品がソフトウェアＸの場合、管理部２２０は、サーバ１００ａにおけるソフトウェアＡ，Ｂ，Ｃのインストールの各時間間隔（ΔＴ１，ΔＴ２に対応する時間間隔）を計算する。例えば、管理部２２０は、計算した各時間間隔が、ソフトウェアＸに対して取得済の平均時間間隔＋標準偏差×２よりも小さい場合は、一致すると判定する。一方、計算した各時間間隔が、当該平均時間間隔＋標準偏差×２以上である場合は、一致しないと判定する。

（Ｓ５７）管理部２２０は、着目するスイート製品がサーバ１００ａにインストールされていると判断し、ステップＳ５４で検出した各ソフトウェアを、ステップＳ５３で選択したスイート製品に関連づける。すなわち、管理部２２０は、ステップＳ５４で検出された複数のソフトウェアをグループ化する。

（Ｓ５８）管理部２２０は、記憶部２１０に記憶されたソフトウェア辞書に含まれる全てのスイート製品を選択し、ステップＳ５４以降の確認を行ったか否かを判定する。全スイート製品を確認済みの場合、処理をステップＳ５９に進める。未確認のスイート製品がある場合、処理をステップＳ５３に進める。なお、以後のステップＳ５３では、未確認のスイート製品が選択の対象となる。

（Ｓ５９）管理部２２０は、ステップＳ５７における関連づけの結果に基づいて、サーバ１００ａにインストールされたソフトウェアの一覧を作成する。例えば、ユーザは、作成されたソフトウェアの一覧を参照することで、サーバ１００ａにインストールされたスイート製品およびコンポーネントのソフトウェアを確認できる。例えば、ユーザは、ソフトウェアＸというスイート製品およびソフトウェアＸのコンポーネントとしてのソフトウェアＡ，Ｂ，Ｃがサーバ１００ａにインストールされていることを確認できる。

このようにして、管理サーバ２００は、サーバ１００，１００ａ，１００ｂにインストールされているソフトウェアとソフトウェア辞書に登録されたソフトウェアとの同一性を確認する。このとき、ソフトウェア単体の同一性だけでなく、あるソフトウェアが他のソフトウェアのコンポーネントであることも確認できる。

特に、ステップＳ５５やステップＳ５６の判定を行うことで、スイート製品を適切に特定できる。具体的には、スイート製品によるインストールの順序は、スイート製品のインストーラによる制御を反映するものであり、異なる順序でインストールされている場合は、当該スイート製品に相当するものではないと判断できる。また、複数のソフトウェアが、比較的長い時間間隔でインストールされたものであれば、各ソフトウェアは、スイート製品のコンポーネントに相当するものではないと判断できる。

なお、サーバ１００，１００ａ，１００ｂの何れかに、管理部２２０の機能を設けてもよい。すなわち、サーバ１００，１００ａ，１００ｂにより、ステップＳ５７における、複数のソフトウェアのグループ化を実行してもよい。

図１８は、スイート製品の検出例を示す図である。例えば、ソフトウェアＸをサーバ１００にインストールする際、サーバ１００のＯＳは、ソフトウェアＸのインストーラを実行するためにプロセスＰｘを生成する。プロセスＰｘは、ソフトウェアＸのインストーラのプログラム“ＳｅｔｕｐＸ．ｅｘｅ”の実行に用いられる。また、プロセスＰｘは、インストール手順において種々のファイルやレジストリにアクセスする。

そして、ソフトウェアＸのインストーラは、ソフトウェアＡ，Ｂ，Ｃのインストーラを順次呼び出して、ソフトウェアＡ，Ｂ，Ｃのインストールを行う。すなわち、プロセスＰｘは、ソフトウェアＡのインストーラ（“ＳｅｔｕｐＡ．ｅｘｅ”）を実行するためのプロセスＰａを生成する。また、プロセスＰｘは、ソフトウェアＢのインストーラ（“ＳｅｔｕｐＢ．ｅｘｅ”）を実行するためのプロセスＰｂを生成する。更に、プロセスＰｘは、ソフトウェアＣのインストーラ（“ＳｅｔｕｐＣ．ｅｘｅ”）を実行するためのプロセスＰｃを生成する。プロセスＰａ，Ｐｂ，Ｐｃも、インストール手順において種々のファイルやレジストリにアクセスする。

この場合、プロセスＰｘ，Ｐａ，Ｐｂ，Ｐｃの親子関係により、プロセスＰｘの子プロセスであるプロセスＰａ，Ｐｂ，Ｐｃがアクセスしたファイル／レジストリの情報を、ソフトウェアＸの情報として対応づけることができる。また、プロセスＰａ，Ｐｂ，Ｐｃは、それぞれソフトウェアＡ，Ｂ，Ｃに対応する。このため、ソフトウェアＡ，Ｂ，Ｃを、ソフトウェアＸというスイート製品に同梱される一群のソフトウェアとして管理できる。

すなわち、サーバ１００は、複数のプロセスの親子関係に基づいて、ソフトウェアＸの実行に応じて生成されたプロセスＰｘ，Ｐａ，Ｐｂ，Ｐｃを特定する。サーバ１００は、プロセスＰｘ，Ｐａ，Ｐｂ，Ｐｃによってアクセスされたファイル／レジストリの情報をソフトウェアＸに対応づけたソフトウェア構成情報を生成する。

図１９は、ソフトウェアの同一性チェックの例を示す図である。図１９（Ａ）は、第２の実施の形態の方法で生成されたソフトウェア辞書を用いた場合のソフトウェアの同一性チェックを例示している。図１９（Ｂ）は、第２の実施の形態の方法を用いない場合を示す比較例である。ここでは、ソフトウェアＸ，Ｘ’の区別を考える。ソフトウェアＸ’は、ソフトウェアＢ，Ｃを含む点はソフトウェアＸと変わらない。ソフトウェアＸ’は、ソフトウェアＡの代わりにソフトウェアＡのバグ修正後のバージョンであるソフトウェアＡ’を含む点がソフトウェアＸと異なる。

図１９（Ａ）で示されるように、第２の実施の形態で作成されるソフトウェア辞書によれば、ソフトウェアＸの情報の中にソフトウェアＡの情報を含めることができ、ソフトウェアＸ’の情報の中にソフトウェアＡ’の情報を含めることができる。このため、ソフトウェアＡとソフトウェアＡ’との相違を、スイート製品であるソフトウェアＸとソフトウェアＸ’との相違として区別できるようになる。

他方、各ソフトウェアをスイート製品として関連づけない場合、ソフトウェア辞書では、各ソフトウェアは個別に管理されることになる。すると、図１９（Ｂ）で示されるように、ソフトウェアＡ，Ａ’の相違を把握できるとしても、ソフトウェアＡ，Ａ’の相違をソフトウェアＸ，Ｘ’の相違として識別することができない。

例えば、サーバ１００，１００ａ，１００ｂで同一の処理を行う場合、システムの安定稼働維持のため、各サーバにインストールされているソフトウェアを全く同一のものとしたいことがある。ところが、図１９（Ｂ）の例のように、ソフトウェアを個別に管理していると、各サーバにインストールされているソフトウェアＡ，Ａ’の相違が分かるだけである。すなわち、ソフトウェアＡ，Ａ’が単一製品としてインストールされたのか、スイート製品の一部としてインストールされたのかを把握できない。このため、各サーバのソフトウェアを全く同一のものとするために、ソフトウェアＡをソフトウェアＡ’に置き換えればよいのか、あるいは、スイート製品であるソフトウェアＸをソフトウェアＸ’に置き換えればよいのか、の判断が容易でない。

これに対し、第２の実施の形態の方法によれば、ソフトウェアＡ，Ａ’がスイート製品であるソフトウェアＸ，Ｘ’のコンポーネントである場合に、ソフトウェアＡ，Ａ’の相違をソフトウェアＸ，Ｘ’の相違として適切に把握できる。例えば、あるソフトウェアに問題が検出された場合、問題の影響範囲（単一ソフトウェア単位かスイート製品単位か）を容易に把握でき、適切な対処を行える。このように、システムの安定稼働維持のためのソフトウェア管理を効率的に行うことができる。

図２０は、ソフトウェア辞書の拡張の例を示す図である。例えば、管理サーバ２００の記憶部２１０に記憶されたソフトウェア辞書に、ソフトウェアＹ１の情報が登録されていないこともある。この場合、サーバ１００は、ソフトウェアＹ１のインストール時に、ソフトウェアＹ１の情報をソフトウェア辞書に追加する。ここで、例えばソフトウェアＹ１はコンポーネントのソフトウェアＡ，Ｂを含む。この場合、サーバ１００は、ソフトウェアＹ１のインストール時、記憶部２１０に記憶されたソフトウェア辞書およびコンポーネント構成管理辞書に、ソフトウェアＹ１とソフトウェアＡ，Ｂとの関係や各ソフトウェアのファイル／レジストリ情報を登録する。

同様に、サーバ１００ａはソフトウェアＹ２の情報をソフトウェア辞書およびコンポーネント構成管理辞書に追加する。例えば、ソフトウェアＹ２は、コンポーネントのソフトウェアＡ，Ｂおよび同梱のオープンソースソフトウェア（ＯＳＳ：Open Source Software、同梱ＯＳＳという）を含む。この場合、サーバ１００ａは、ソフトウェアＹ２のインストール時、コンポーネント構成管理辞書およびソフトウェア辞書に、ソフトウェアＹ２とソフトウェアＡ，Ｂおよび同梱ＯＳＳとの関係や各ソフトウェアのファイル／レジストリ情報を登録する。

すると、管理サーバ２００は、記憶部２１０に記憶されたコンポーネント構成管理辞書やソフトウェア辞書を用いて、他のサーバにインストールされているスイート製品のソフトウェアＹ１，Ｙ２を検出できるようになる。

特に、ＯＳＳやフリーのソフトウェアは、無数に存在しておりソフトウェア辞書に予め登録されていないことも多い。第２の実施の形態の方法によれば、ＯＳＳやフリーのソフトウェアについても、スイート製品に同梱されるコンポーネントのソフトウェアとしてソフトウェア辞書に登録できる。また、このように拡張されたソフトウェア辞書を用いて、ＯＳＳやフリーのソフトウェアを同梱するスイート製品が他のサーバにインストールされていても、適切に検出可能となる。また、例えば、当該ＯＳＳなどのソフトウェアがスイート製品とは別個にインストールされている場合と、当該ＯＳＳなどのソフトウェアがスイート製品に同梱されてインストールされている場合とを適切に区別可能となる。

なお、サーバ１００，１００ａ，１００ｂの何れかに、管理部２２０の機能を設けてもよい。その場合、管理サーバ２００を別個に設けなくてもよい。
また、上記の例では、サーバ１００，１００ａ，１００ｂにソフトウェアをインストールする場合を示したが、ソフトウェアをインストールする対象のマシンは仮想マシンでもよい。例えば、サーバ１００で動作する仮想マシンにソフトウェアＸをインストールするときも、当該仮想マシンにより監視部１４０や生成部１５０の機能を実現できる。第２の実施の形態と同様の方法により、複数の仮想マシンにインストールされた各ソフトウェアの同一性のチェックを行うこともできる。

なお、第１の実施の形態の情報処理は、演算部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１３に記録できる。

例えば、プログラムを記録した記録媒体１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３等の記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。

１ ソフトウェア情報管理装置
１ａ 記憶部
１ｂ 演算部
２ ソフトウェア構成情報

Claims (6)

1. コンピュータに、
   ソフトウェアのインストールの際に、前記ソフトウェアのインストーラが生成する複数のプロセスを監視し、
   生成された前記複数のプロセスそれぞれがアクセスした複数のファイルそれぞれのファイル情報、および、前記複数のプロセス間の関係に基づき、前記複数のファイルに対応する複数のファイル情報を、前記ソフトウェアに関連づけた、ソフトウェア構成情報を生成する、
   処理を実行させるソフトウェア情報管理プログラム。
2. 前記ソフトウェア構成情報の生成の際に、生成された前記複数のプロセスそれぞれがアクセスした複数のレジストリ情報を前記ソフトウェアに関連づける、請求項１記載のソフトウェア情報管理プログラム。
3. 前記ソフトウェア構成情報を参照して複数のソフトウェアをグループ化する、請求項１または２記載のソフトウェア情報管理プログラム。
4. グループ化の際は、ファイルまたは設定項目の更新時刻に基づき前記複数のソフトウェアをグループ化する、請求項３記載のソフトウェア情報管理プログラム。
5. ソフトウェアのプログラムを記憶する記憶部と、
   前記ソフトウェアのインストールの際に、前記ソフトウェアのインストーラが生成する複数のプロセスを監視し、
   生成された前記複数のプロセスそれぞれがアクセスした複数のファイルそれぞれのファイル情報、および、前記複数のプロセス間の関係に基づき、前記複数のファイルに対応する複数のファイル情報を、前記ソフトウェアに関連づけた、ソフトウェア構成情報を生成する、演算部と、
   を有するソフトウェア情報管理装置。
6. コンピュータが、
   ソフトウェアのインストールの際に、前記ソフトウェアのインストーラが生成する複数のプロセスを監視し、
   生成された前記複数のプロセスそれぞれがアクセスした複数のファイルそれぞれのファイル情報、および、前記複数のプロセス間の関係に基づき、前記複数のファイルに対応する複数のファイル情報を、前記ソフトウェアに関連づけた、ソフトウェア構成情報を生成する、
   ソフトウェア情報管理方法。

Images