JPH1185527A - ソフトウェア配布システムにおける配布対象ファイルの選定方法 - Google Patents

Abstract

(57)【要約】 【課題】 ソフトウェアの配布元がすべての配布先に同
一バージョンのファイルを画一的に配布するのではな
く、配布先の現在のバージョンに応じて遷移に必要とす
る配布対象ファイルを選定する方法。 【解決手段】 ソフトウェア送信処理部２は、関連する
いくつかのソフトウェアファイルをそれぞれまとめた複
数の各グループにバージョン番号を付与し、前記各グル
ープのバージョン更新時に実施された各ソフトウェアフ
ァイル単位毎の操作をファイル操作管理情報３として記
憶しておき、ソフトウェア受信処理部５からの現在のグ
ループバージョンより所望のグループバージョンへ遷移
するのに各ソフトウェアファイル毎に必要とする操作の
問い合わせに基づき、配布対象のバージョンに応じて必
要とする配布対象ソフトウェアファイルを選定する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、例えばクライアン
ト／サーバ型等の分散システムにおける各コンピュータ
に配布するソフトウェアの配布対象ファイルの選定方法
に関するものである。

【０００２】

【従来の技術】例えばソフトウェア開発システムの場合
に、従来はホスト集中型のシステム形態が主流であった
が、現在ではシステムのダウンサイジングに伴い、クラ
イアント／サーバ型の分散環境が構築されることが一般
的となっている。そしてこのクライアント／サーバ型の
分散システムでは、物理的にも、また台数的にも広範囲
に及ぶクライアント及びサーバのソフトウェアの入れ替
え作業は、ホスト集中型システムの場合とは異なり、相
応の人的及び時間的コストを必要とし、また管理者に依
存する作業では、人為的なミスが少なからず発生するこ
とが多い。そこで、１つの拠点機器から、複数のコンピ
ュータに対して、自動的にソフトウェアの配布やバージ
ョン（版数）アップが可能なソフトウェア配布システム
が開発されるようになった。

【０００３】

【発明が解決しようとする課題】しかしながら、従来の
上記ソフトウェア配布システムでは、“指定されたソフ
トウェアを指定されたディレクトリ配下へと配布する”
ことのみを目的としており、“配布対象コンピュータに
既に搭載されているソフトウェアのバージョンに応じて
動的に配布対象ソフトウェアを選択する”ことが不可能
であった。即ち、現在のクライアント／サーバシステム
におけるソフトウェアのバージョン管理業務において
は、一般的に、全てのコンピュータ（特にクライアン
ト）が全て同一のバージョンのソフトウェアを搭載して
いるとは限らないため、各配布対象コンピュータの現時
点でのバージョンを確認したうえで、各々のバージョン
から特定のバージョンへと遷移させるためのソフトウェ
アの組み合わせを各々別個に登録する必要があるという
課題が残っていた。

【０００４】

【課題を解決するための手段】本発明に係るソフトウェ
ア配布システムにおける配布対象ファイルの選定方法
は、ソフトウェア送信処理手段を含む単一の配布元マシ
ンと、この配布元マシンとネットワークを介して接続さ
れるそれぞれソフトウェア受信手段を含む単数又は複数
の配布先マシンとよりなるソフトウェア配布システムに
おいて、前記ソフトウェア送信手段は、関連するいくつ
かのソフトウェアファイルをそれぞれまとめた複数の各
グループにバージョン番号を付与し、前記各グループの
バージョン更新時に実施された各ソフトウェアファイル
単位毎の操作をファイル操作管理情報として記憶してお
き、前記ソフトウェア受信処理手段からの現在のグルー
プバージョンより所望のグループバージョンへ遷移する
のに各ソフトウェアファイル毎に必要とする操作の問い
合わせに基づき、配布対象のバージョンに応じて必要と
する配布対象ソフトウェアファイルを選定するものであ
る。

【０００５】その結果、ソフトウェア受信手段がソフト
ウェア送信手段に１回アクセスするのみで、ソフトウェ
ア受信手段の現在のグループバージョンがどのようなバ
ージョンであっても、この現在のグループバージョンか
ら所望のグループバージョンへ遷移する際に必要且つ十
分な配布対象ソフトウェアファイルがダイナミックに選
定されて配布され、ファイル転送処理を必要最低限の回
数にとどめて所望のグループバージョンへ遷移すること
ができる。

【０００６】

【発明の実施の形態】

実施形態１ 図１は本発明の実施形態１、２に係るソフトウェア配布
システムの構成図である。図１のシステムは、基本的に
は、内部にソフトウェア送信処理部２を含む配布元マシ
ン１と、この配布元マシン１とネットワーク７を介して
接続される内部にソフトウェア受信処理部５を含む配布
先マシン４とにより構成されるが、前記ソフトウェア送
信処理部２はその送信処理に必要なバージョン管理情報
３を保有し、またソフトウェア受信処理部５はその受信
処理なバージョン管理情報６を保有している。

【０００７】即ち、ソフトウェア送信処理部２は、ソフ
トウェア受信処理部５へと配布するソフトウェアに関し
て、そのファイル名やバージョン番号等を管理し、自身
のバージョン管理情報３として保有している。またソフ
トウェア受信処理部５は、自身がソフトウェア送信処理
部２から受信したソフトウェアに関してのみ、そのバー
ジョン番号等を自身のバージョン管理情報６として保有
している。なお図１の配布元マシン１はこのシステムに
おいて１つのみ存在するが、配布先マシン４はネットワ
ーク７に複数Ｎ個を接続できる。そして配布先マシン４
が複数Ｎ個存在する場合に、各配布先マシン４に個別に
ソフトウェアを配布することもできるが、ある何個かの
配布先マシン４に並列的にソフトウェアを配布すること
も可能である。

【０００８】図１の動作を説明する。最初に、配布元マ
シン１上のソフトウェア送信処理部２が管理しているバ
ージョン管理情報３について説明する。まず配布元マシ
ン１上のソフトウェア送信処理部２に対して、実際に配
布を行うファイルを登録する。この時、ファイルのグル
ープ化及びグループセット化を行い、そのグループ及び
グループセットに対して各々バージョン番号を１つ付与
する。

【０００９】図２はソフトウェアのファイル、グループ
及びグループセットの関係を示す図である。図２におい
て、グループ１２とは、関連するいくつかのファイル１
３をまとめたものである。また、グループセット１１と
は関連するいくつかのグループ１２をまとめたものであ
る。グループ１２とグループセット１１は、ともにバー
ジョン管理を行うための論理的な管理単位である。ソフ
トウェア送信処理部２では、上記のグループセット１
１、グループ１２及びファイル１３の関係を管理し、バ
ージョン管理情報３として保有している。また、ソフト
ウェア送信処理部２では、グループセット１１及びグル
ープ１２に関して、１世代前のバージョンからどの様な
操作を受けることにより本バージョンへ遷移したのかと
いう情報も管理する。

【００１０】グループセット１１の場合にはグループ１
２の“操作”が操作対象となり、グループ１２の場合に
はファイル１３の“操作”が操作対象になる。また、こ
こで、“操作”とは、“追加”、“変更”、“削除”の
何れかである。更に、グループセット１１の場合には各
々のグループセットバージョンのメンバーグループ及び
そのバージョンの管理を行い、またグループ１２の場合
には各々のグループバージョンに関してメンバーファイ
ル及びそのバージョン識別情報の管理を行う。

【００１１】図３は図１のソフトウェア送信処理部２が
保有するバージョン管理情報３の概要図である。図３の
バージョン管理情報３には、グループセットバージョン
管理情報（イ）と、この（イ）に関連するグループ操作
管理情報（ロ）及びメンバーグルーブ管理情報（ハ）
と、この（ハ）に関連するグループバージョン管理情報
（ニ）と、前記（ロ）及び（ニ）に関連するファイル操
作情報（ホ）と、前記（ニ）に関連するメンバーファイ
ル管理情報（ヘ）がある。また前記（ホ）及び（ヘ）に
関連してデポー（ト）がある。なお、図３においては、
グループセットＡのみの管理情報とデポー（ＤＥＰＯ
Ｔ、保管所）の関連を示しているが、グループセット
Ｂ、Ｃにおいても同様に存在する。

【００１２】図３のグループセットバージョン管理情報
（イ）は、グループセット単位毎に存在し、各グループ
セットのバージョン履歴管理状態、即ち履歴管理中（こ
の例ではバージョン３３，３４）、切戻待機中（この例
ではバージョン３５，３６）、現適用中（この例ではバ
ージョン３７）及び予約中（この例ではバージョン３
８，３９）の情報を保有する。従って履歴管理世代数で
４バージョン、切戻待機世代数で２バージョンの情報を
保有する。グループ操作管理情報（ロ）は、管理対象と
なる全更新分に関する情報を保有し、メンバーグループ
管理情報（ハ）は活性化し得る全グループセットバージ
ョンに関する情報を保有する。

【００１３】グループバージョン管理情報（ニ）は全メ
ンバーグループに関するバージョン履歴管理情報を保有
し、ファイル操作情報（ホ）は各グループ毎に管理対象
となる全更新分に関する情報を保有する。またメンバー
ファイル管理情報（ヘ）は各グループ毎に活性化し得る
全グループバージョンに関する情報を保有する。デポー
（ト）は、ソフトウェアの切戻実体（この例ではバージ
ョン１７から１６への切戻しの際に再び必要となる旧フ
ァイルの実体）、予約実体（この例ではバージョン１７
から１８へ更新の際に追加・変更する新ファイルの実
体）及び現適用中実体（この例では現在適用中のバージ
ョン１７の全ファイルの実体）を保管する。

【００１４】図４は図３のグループバージョン管理情
報、メンバーファイル管理情報及びファイル操作管理情
報の格納例（１）を示す図である。図４のグループバー
ジョン管理情報４１は、全ての各グループに関して、バ
ージョン遷移の履歴を管理するための情報であり、ここ
には次の情報が格納される。 グループ名４２：対象となるグループの名称である。 バージョン番号４３：グループのバージョン番号であ
る。 登録シーケンス番号４４：バージョン番号の更新順序を
記録するものである。 状態４５：各グループバージョンの現在の状態である。

【００１５】図４のメンバーファイル管理情報４６は、
状態が“現適用中”もしくは“切戻待機中”のグループ
バージョンに関して、メンバーファイルを定義するため
の情報であり、ここには、次の情報が格納される。 グループ名４７：対象となるグループの名称である。 バージョン番号４８：対象となるグループバージョン番
号である。 内部ファイル番号４９：ソフトウェア送信処理部２が自
身の管理・保有している配布対象ファイルを一意に識別
するために、内部的に付与する番号である。 内部バージョン番号５０：ソフトウェア送信処理部２
が、内部ファイル番号４９で識別される各ファイル毎
に、バージョンを識別するために付与する番号である。

【００１６】図４のファイル操作管理情報５１は、グル
ープバージョン遷移に際して、どのファイルがどの様な
操作を受けたかを管理するための情報であり、ここには
次の情報が格納される。 グループ名５２：対象となるグループの名称である。 Ｆｒｏｍバージョン番号５３：対象となるグループバー
ジョン遷移の、遷移元バージョン番号である。 Ｔｏバージョン番号５４：対象となるグループバージョ
ン遷移の、遷移先バージョン番号である。 操作対象内部ファイル番号５５：対象となるグループバ
ージョン遷移時に何らかの操作を受けたファイルの内フ
ァイル番号である。 操作５６：受けた操作である。即ち“追加”、“変
更”、“削除”の何れかである。 Ｆｒｏｍ内部バージョン５７：ファイルがバージョン遷
移した際の、遷移元内部バージョン番号である。 Ｔｏ内部バージョン５８：ファイルがバージョン遷移し
た際の、遷移先内部バージョン番号である。

【００１７】本実施形態においては、ソフトウェアの配
布先であるソフトウェア受信処理部５が、現在のバージ
ョンから例えば最新のバージョンや切戻しする旧バージ
ョン等の所望のバージョンへの変更を希望する場合に、
ソフトウェア受信処理部５がソフトウェアの配布元であ
るソフトウェア送信処理部２にアクセスすることによっ
てソフトウェアの配布動作が起動される。即ちソフトウ
ェア送信処理部２から能動的に（一方的に）ソフトウェ
ア受信処理部５に最新バージョン等を配布するものでは
ない。以下ソフトウェア送信処理部２が、ソフトウェア
受信処理部５からバージョン変更の問い合わせがあった
ときに、ソフトウェア受信処理部５の現在のバージョン
から所望のバージョンへの変更希望に応じて、ダイナミ
ックに配布対象ファイルを選択する動作原理につてい説
明する。

【００１８】まず、ソフトウェア受信処理部５がソフト
ウェア送信処理部２にアクセスし、最新のグループバー
ジョンを認識する。ソフトウェア受信処理部５は、自身
のバージョン管理情報６で保有しているグループバージ
ョンと比較することにより、もし異なっている場合に
は、自身の現在のグループバージョンから所望のグルー
プバージョンに遷移するためには、どのファイルに対し
てどの様な操作を実行する必要があるかをソフトウェア
送信処理部２に問い合わせる。次に、ソフトウェア送信
処理部２では、図３のバージョン管理情報を参照して、
ソフトウェア受信処理部５のグループバージョンから希
望のグループバージョンに遷移するために、必要なファ
イル及びその操作を検索する。

【００１９】以下、図４を用いて、上記配布対象ファイ
ルを選択する具体例を示す。なお、図４では、Ｇｒｏｕ
ｐ＃１の現適用中バージョンは“１７．００”としてい
る。従って、各ソフトウェア受信処理部搭載マシン上の
Ｇｒｏｕｐ＃１のバージョンを、“１７．００”に整合
することになる。また、ここでは、ソフトウェア受信処
理部５が、Ｇｒｏｕｐ＃１という１つのグループのみを
サポートするケースで説明を行うが、通常はソフトウェ
ア受信処理部５は複数のグループをサポートして良く、
その場合には各々のグループ単位毎に下記の様な処理が
行われる。

【００２０】実施形態１の具体例 例１：ソフトウェア受信処理部のバージョンが“１６．
００”の場合 グループバージョン管理情報４１を検索することによ
り、Ｇｒｏｕｐ＃１のバージョン“１６．００”から
“１７．００”に遷移するためには、”１６．００→
“１７．００”の１回のバージョンアップを行えば良い
ことがわかる。ここで、ファイル操作管理情報５１を
“Ｆｒｏｍバージョン番号５３＝１６．００、Ｔｏバー
ジョン番号５４＝１７．００”の条件で検索すると、
“操作対象内部ファイル番号５５＝１のファイルが内部
バージョン９から１０にバージョンアップされたこと”
と、“内部ファイル番号５５＝４のファイルが新たに追
加されたこと（内部バージョン１）”が分かる。従っ
て、このソフトウェア受信処理部が“１７．００”に遷
移するためには、“内部ファイル番号＝１で内部バージ
ョン＝１０のファイル”と、“内部ファイル番号＝４で
内部バージョン＝１のファイル”を転送すれば良いこと
が分かる。

【００２１】例２：ソフトウェア受信処理部のバージョ
ンが“１５．００”の場合（例えば長期休眠から復帰等
の場合） グループバージョン管理情報４１を検索することによ
り、Ｇｒｏｕｐ＃１のバージョン“１５．００”から
“１７．００”に遷移するためには、まず“１５．００
→１６．００”のバージョンアップ、更に“１６．００
→１７．００”のバージョンアップと２度のバージョン
アップを行えば良いことが分かる。そこで、ファイル操
作管理情報５１をまず“Ｆｒｏｍバージョン番号５３＝
１５．００、Ｔｏバージョン番号５４＝１６．００”の
条件で検索すると、“内部ファイル番号５５＝１のファ
イルが内部バージョン＝８から９へバージョンアップさ
れたこと”と、“内部ファイル番号５４＝２のファイル
が内部バージョン３から４へバージョンアップされたこ
と”が分かる。従って、このソフトウェア受信処理部が
“１６．００”に遷移するためには、“内部ファイル番
号＝１で内部バージョン＝９のファイル”と、“内部フ
ァイル番号＝２で内部バージョン＝４のファイル”を転
送すれば良いことが分かる。

【００２２】次に、ファイル操作管理情報５１を“Ｆｒ
ｏｍバージョン番号５３＝１６．００、Ｔｏバージョン
番号５４＝１７．００”で検索すると、“内部ファイル
番号＝１のファイルが内部バージョン９から１０にバー
ジョンアップされたこと”と、“内部ファイル番号＝４
のファイルが新たに追加されたこと（内部バージョン
１）”が分かる。従って、“１６．００”の状態から
“１７．００”に遷移するためには、“内部ファイル番
号＝１で内部バージョン＝１０のファイル”と、“内部
ファイル番号＝４で内部バージョン＝１のファイル”を
転送すれば良いことが分かる。

【００２３】ここで、“１５．００→１６．００”の遷
移と“１６．００→１７．００”の遷移をマージ（併
合）してみると、結果的には、“内部ファイル番号＝１
のファイルが内部バージョン＝８から１０へバージョン
アップされたこと”と、“内部ファイル番号＝２のファ
イルが内部バージョン＝３から４へバージョンアップさ
れたこと”と、“内部ファイル番号＝４のファイルが新
たに追加されたこと（内部バージョン＝１）”になる。
従ってこのソフトウェア受信処理部が“１５．００”か
ら“１７．００”へ遷移するためには、“内部ファイル
番号＝１で内部バージョン＝１０のファイル”と、“内
部ファイル番号＝２で内部バージョン＝４のファイル”
と、“内部ファイル番号＝４で内部バージョン＝１のフ
ァイル”を転送すれば良いことが分かる。

【００２４】例３：ソフトウェア受信処理部にＧｒｏｕ
ｐ＃１を未配布の場合 ソフトウェア受信機能に対してＧｒｏｕｐ＃１をまだ配
布していないため、Ｇｒｏｕｐ＃１のバージョン“１
７．００”を構成するための全てのファイルを転送する
必要がある。この場合には、図４のメンバーファイル管
理情報４６を“バージョン番号４８＝１７．００”の条
件で検索することにより、Ｇｒｏｕｐ＃１のバージョン
“１７．００”を構成するためには、“内部ファイル番
号＝１で内部バージョン＝１０のファイル”と、“内部
ファイル番号＝２で内部バージョン＝４のファイル”
と、“内部ファイル番号＝３で内部バージョン＝８のフ
ァイル”と、“内部ファイル番号＝４で内部バージョン
＝１のファイル”が必要であることが分かる。従って、
このソフトウェア受信処理部には、これら４つのファイ
ルを転送すれば良いことが分かる。

【００２５】例４：ソフトウェア受信処理部のバージョ
ンが“１８．００”の場合（切戻して旧バージョンに戻
る場合） 何らかの要因で、ソフトウェア受信処理部のバージョン
が先行してしまったケースである。この場合、グループ
バージョン管理情報４１を検索することにより、Ｇｒｏ
ｕｐ＃１のバージョン“１８．００”は、“１７．０
０”からバージョンアップされたことが分かる。従っ
て、バージョン“１８．００”から“１７．００”に遷
移するためには、“１７．００→１８．００”の１回の
バージョンアップ時に行われた操作の逆操作を実施すれ
ば良いことが分かる。ここで、ファイル操作管理情報５
１を“Ｆｒｏｍバージョン５３＝１７．００、Ｔｏバー
ジョン５４＝１８．００”の条件で検索すると、“内部
ファイル番号＝１で内部バージョン＝１０のファイルが
削除されたこと”と、“内部ファイル番号＝３のファイ
ルが内部バージョン＝８から９にバージョンアップされ
たこと”が分かる。従って、その逆の操作は“内部ファ
イル番号＝１で内部バージョン＝１０のファイルを追加
すること”と、“内部ファイル番号＝３のファイルを内
部バージョン＝９から８にバージョンダウンすること”
である。従って、このソフトウェア受信処理部が“１
７．００”に遷移するためには、“内部ファイル番号＝
１で内部バージョン＝１０のファイル”と、“内部ファ
イル番号＝３で内部バージョン＝８”のファイルを転送
すれば良いことが分かる。

【００２６】実施形態２ 図５は図３のグループバージョン管理情報、メンバーフ
ァイル管理情報及びファイル管理情報の格納例（２）を
示す図である。図５では、Ｇｒｏｕｐ＃１について、バ
ージョン“１７．００”に遷移した際に、バージョン
“１６．００”のメンバーファイルを全て削除したケー
スを示している。従って、図５により“１７．００”に
遷移するということは、Ｇｒｏｕｐ＃１のファイルを全
て削除することであることを実施形態２の具体例として
説明する。

【００２７】実施形態２の具体例 例５：ソフトウェア受信処理部のバージョンが“１６．
００”の場合 グループバージョン管理情報６１を検索することによ
り、Ｇｒｏｕｐ＃１のバージョン“１６．００”から
“１７．００”に遷移するためには、“１６．００→１
７．００”の１回のバージョンアップを行えば良いこと
が分かる。ここで、ファイル操作管理情報７１を“Ｆｒ
ｏｍバージョン番号７３＝１６．００、Ｔｏバージョン
番号７４＝１７．００”の条件で検索すると、“内部フ
ァイル番号＝１（内部バージョン＝９）のファイルが削
除されたこと”と、“内部ファイル番号＝２（内部バー
ジョン＝４）のファイルが削除されたこと”と、“内部
ファイル番号＝３（内部バージョン＝８）のファイルが
削除されたこと”が分かる。従って、このソフトウェア
受信処理部が“１７．００”に遷移する（Ｇｒｏｕｐ＃
１のファイルを全て削除した状態になる）ためには、
“内部ファイル番号＝１（内部バージョン＝９）のファ
イル”と、“内部ファイル番号＝２（内部バージョン＝
４）のファイル”と、“内部ファイル番号＝３（内部バ
ージョン＝８）のファイル”を削除すれば良いことが分
かる。

【００２８】例６：ソフトウェア受信処理部のバージョ
ンが“１５．００”の場合 グループバージョン管理情報６１を検索することによ
り、Ｇｒｏｕｐ＃１のバージョン“１５．００”から
“１７．００”に遷移するためには、まず“１５．００
→１６．００”のバージョンアップ、更に“１６．００
→１７．００”へのバージョンアップと２度のバージョ
ンアップを行えば良いことが分かる。そこで、ファイル
操作管理情報７１をまず“Ｆｒｏｍバージョン番号７３
＝１５．００、Ｔｏバージョン番号７４＝１６．００”
の条件で検索すると、“内部ファイル番号＝１のファイ
ルが内部バージョン＝８から９へバージョンアップされ
たこと”と、“内部ファイル番号＝２のファイルが内部
バージョン＝３から４にバージョンアップされたこと”
が分かる。従って、このソフトウェア受信処理部が“１
６．００”に遷移するためには、“内部ファイル番号＝
１で内部バージョン＝９のファイル”と、“内部ファイ
ル番号＝２で内部バージョン＝４のファイル”を転送す
れば良いことが分かる。

【００２９】次に、ファイル操作管理情報７１を“Ｆｒ
ｏｍバージョン番号７３＝１６．００、Ｔｏバージョン
番号７４＝１７．００”の条件で検索すると、“内部フ
ァイル番号＝１（内部バージョン＝９）のファイルが削
除されたこと”と、“内部ファイル番号＝２（内部バー
ジョン＝４）のファイルが削除されたこと”と、“内部
ファイル番号＝３（内部バージョン＝８）のファイルが
削除されたこと”が分かる。従って、このソフトウェア
受信処理部が“１６．００”の状態から“１７．００”
に遷移するためには、“内部ファイル番号＝１（内部バ
ージョン＝９）のファイル”と、“内部ファイル番号＝
２（内部バージョン＝４）のファイル”と、“内部ファ
イル番号＝３（内部バージョン＝８）のファイル”を削
除すれば良いことが分かる。

【００３０】ここで、“１５．００→１６．００”の遷
移と“１６．００→１７．００”の遷移をマージしてみ
ると、結果的には“内部ファイル番号＝１（内部バージ
ョン＝９）が削除されたこと”と、“内部ファイル番号
＝２（内部バージョン＝４）のファイルが削除されたこ
と”と、“内部ファイル番号＝３（内部バージョン＝
８）のファイルが削除されたこと”になる。従って、こ
のソフトウェア受信処理部が“１７．００”に遷移する
（Ｇｒｏｕｐ＃１のファイルを全て削除した状態にな
る）ためには、“内部ファイル番号＝１（内部バージョ
ン＝９）のファイル”と、“内部ファイル番号＝２（内
部バージョン＝４）のファイル”と、“内部ファイル番
号＝３（内部バージョン＝８）のファイル”を削除すれ
ば良いことが分かる。

【００３１】なお、クライアント／サーバシステム等に
おいては、すべてのクライアントが、それぞれのコンピ
ュータに搭載するソフトウェアについては、常に最新の
バージョンへ自動的に遷移されることを希望するとは限
らない場合がある。即ちクライアントは自己のコンピュ
ータに接続される入出力機器等の設置状況や、使用する
ソフトウェアファイルの内容に応じて、自己のコンピュ
ータに搭載するソフトウェアバージョンを自己の意思で
選択できることを望む場合があり、このような場合に本
実施形態は有効である。即ち本実施形態においては、ソ
フトウェアの配布先であるソフトウェア受信処理部５
が、ソフトウェア配布元であるソフトウェア送信処理部
２に対して、現在のグループバージョンから希望するグ
ループバージョンへ遷移するのに各ソフトウェアファイ
ル毎に必要とする操作を問い合わせ、ソフトウェア送信
処理部２は、この問い合わせに基づき、配布対象のバー
ジョンに応じて必要とする配布対象ソフトウェアファイ
ルをダイナミックに選定して配布するようにしているか
らである。このように本実施形態においては、すべての
ソフトウェアの配布先が最新のバージョンを希望する場
合は、この希望の通り最新バージョンが配布されるが、
ソフトウェアの配布元の意思によって画一的にすべての
配布先に最新バージョンを配布するものではない。

【００３２】以上の様に本実施形態１、２によれば、ソ
フトウェア送信処理部では、ソフトウェア受信処理部で
の現在のバージョンに応じて、動的に配布対象のファイ
ルを選択することが可能である。即ち、ネットワーク内
に存在するソフトウェア受信処理部がどの様なバージョ
ンであっても、１度のソフトウェア送信処理部へのアク
セスで、ソフトウェア送信処理部で必要なファイル・操
作を検索し、ファイル転送処理を必要最低限の回数に止
めつつ、所望のバージョンへと遷移することが可能であ
る。また本実施形態１、２によれば、新規にネットワー
クにコンピュータを増設する場合でも、所望のバージョ
ンのファイルを転送・インストールすることが可能であ
り、また障害等で長期間休眠しており、その間のバージ
ョンアップを受けることができなかったコンピュータに
対しても、ネットワークに復帰後１度ソフトウェア送信
処理部にアクセスするだけで、所望のバージョンへと遷
移することが可能である。

【００３３】また本実施形態２によれば、前記ソフトウ
ェア受信処理部からの現在のグループバージョンより、
所望のグループバージョンへ遷移するのに各ソフトウェ
アファイル毎に必要とする操作の問い合わせに基づき、
配布対象のバージョンに応じて必要とする配布対象ソフ
トウェアファイルの追加・変更に伴うソフトウェアファ
イルを選定して転送するのみならず、不要なソフトウェ
アファイルを削除することが可能となる。

【００３４】

【発明の効果】以上のように本発明によれば、ソフトウ
ェア送信処理手段を含む単一の配布元マシンと、この配
布元マシンとネットワークを介して接続されるそれぞれ
ソフトウェア受信手段を含む単数又は複数の配布先マシ
ンとよりなるソフトウェア配布システムにおいて、前記
ソフトウェア送信手段は、関連するいくつかのソフトウ
ェアファイルをそれぞれまとめた複数の各グループにバ
ージョン番号を付与し、前記各グループのバージョン更
新時に実施された各ソフトウェアファイル単位毎の操作
をファイル操作管理情報として記憶しておき、前記ソフ
トウェア受信処理手段からの現在のグループバージョン
より所望のグループバージョンへ遷移するのに各ソフト
ウェアファイル毎に必要とする操作の問い合わせに基づ
き、配布対象のバージョンに応じて必要とする配布対象
ソフトウェアファイルを選定するようにしたので、その
結果ソフトウェア受信手段がソフトウェア送信手段に１
回アクセスするのみで、ソフトウェア受信手段の現在の
グループバージョンがどのようなバージョンであって
も、この現在のグループバージョンから所望のグループ
バージョンへ遷移する際に必要且つ十分な配布対象ソフ
トウェアファイルがダイナミックに選定されて配布さ
れ、ファイル転送処理を必要最低限の回数にとどめて所
望のグループバージョンへ遷移することができる。

【図面の簡単な説明】

【図１】本発明の実施形態１、２に係るソフトウェア配
布システムの構成図である。

【図２】ソフトウェアのファイル、グループ及びグルー
プセットの関係を示す図である。

【図３】図１のソフトウェア送信処理部２が保有するバ
ージョン管理情報３の概要図である。

【図４】図３のグループバージョン管理情報、メンバー
ファイル管理情報及びファイル操作管理情報の格納例
（１）を示す図である。

【図５】図３のグループバージョン管理情報、メンバー
ファイル管理情報及びファイル操作管理情報の格納例
（２）を示す図である。

【符号の説明】

１ 配布元マシン ２ ソフトウェア送信処理部 ３ バージョン管理情報 ４ 配布先マシン ５ ソフトウェア受信処理部 ６ バージョン管理情報 １１ グループセット １２ グループ １３ ファイル ４１，６１ グループバージョン管理情報 ４６，６６ メンバーファイル管理情報 ５１，７１ ファイル操作管理情報

Claims (2)

【特許請求の範囲】
1. 【請求項１】 ソフトウェア送信処理手段を含む単一の
   配布元マシンと、この配布元マシンとネットワークを介
   して接続されるそれぞれソフトウェア受信手段を含む単
   数又は複数の配布先マシンとよりなるソフトウェア配布
   システムにおいて、 前記ソフトウェア送信手段は、関連するいくつかのソフ
   トウェアファイルをそれぞれまとめた複数の各グループ
   にバージョン番号を付与し、前記各グループのバージョ
   ン更新時に実施された各ソフトウェアファイル単位毎の
   操作をファイル操作管理情報として記憶しておき、前記
   ソフトウェア受信処理手段からの現在のグループバージ
   ョンより所望のグループバージョンへ遷移するのに各ソ
   フトウェアファイル毎に必要とする操作の問い合わせに
   基づき、配布対象のバージョンに応じて必要とする配布
   対象ソフトウェアファイルを選定することを特徴とする
   ソフトウェア配布システムにおける配布対象ファイルの
   選定方法。
2. 【請求項２】 ソフトウェア送信処理手段を含む単一の
   配布元マシンと、この配布元マシンとネットワークを介
   して接続されるそれぞれソフトウェア受信手段を含む単
   数又は複数の配布先マシンとよりなるソフトウェア配布
   システムにおいて、 前記ソフトウェア送信手段は、関連するいくつかのソフ
   トウェアファイルをそれぞれまとめた複数の各グループ
   にバージョン番号を付与し、前記各グループのバージョ
   ン更新時に実施された各ソフトウェアファイル単位毎の
   操作をファイル操作管理情報として記憶しておき、前記
   ソフトウェア受信処理手段からの現在のグループバージ
   ョンより所望のグループバージョンへ遷移するのに各ソ
   フトウェアファイル毎に必要とする操作の問い合わせに
   基づき、配布対象のバージョンに応じて必要とする配布
   対象ソフトウェアファイルの追加・変更に伴うソフトウ
   ェアファイルを選定して転送するのみならず、不要なソ
   フトウェアファイルを削除することを特徴とするソフト
   ウェア配布システムにおける配布対象ファイルの選定方
   法。