(57)【要約】【課題】  中間サーバが端末にインストールされたソフトウェアの更新のための情報を配布サーバや端末への最小限のアクセス及び最小限の情報量により効率よく行なうことできる。【解決手段】  中間サーバ２００が、端末３００によりソフトウェアの更新要求が送信された時にこの更新要求に対応した過去更新情報と過去差分情報とを自らが保存していない場合にソフトウェアを更新する新旧ソフトウェアの差分情報が保存された配布サーバ１００から更新要求に対応した差分情報を取得し、この差分情報に基づいて更新要求に対応した更新情報を生成し、この生成した更新情報とこの更新情報を端末３００にインストールする手順とがパッケージされた配布パッケージを生成し、この配布パッケージを端末３００に送信する。【選択図】        図１
2006293512.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアを更新する新旧ソフトウェアの差分情報が保存された配布サーバと、
インストールされたソフトウェアの更新要求を送信する端末と、
過去のソフトウェア更新に利用された過去更新情報と過去差分情報とが保持された更新情報保持手段と、前記端末により前記更新要求が送信された時にこの更新要求に対応した前記過去更新情報と前記過去差分情報とが前記更新情報保持手段に存在しない場合に前記配布サーバに保存された前記差分情報の中から前記更新要求に対応した差分情報を取得する差分情報取得手段と、前記差分情報取得手段により取得された前記差分情報に基づいて前記更新要求に対応した前記更新情報を生成する更新情報生成手段と、前記更新情報生成手段により生成された前記更新情報とこの更新情報を前記端末にインストールする手順とがパッケージされた配布パッケージを生成する配布パッケージ生成手段と、前記配布パッケージ生成手段により生成された配布パッケージを前記端末に送信する配布パッケージ送信手段とを有する中間サーバと、
を備えたことを特徴とするソフトウェア更新情報配布システム。
【請求項２】
前記配布サーバは、ソフトウェアを構成する複数のコンポーネントとソフトウェアのバージョンとの対応関係が定義された構成情報を管理する構成情報管理手段と、前記構成情報に基づいて前記差分情報を生成する差分情報生成手段と、を備えたことを特徴とする請求項１記載のソフトウェア更新情報配布システム。
【請求項３】
前記構成情報管理手段は、ソフトウェアのプログラム実態を示す配布プログラムを前記配布サーバに登録し、
前記配布サーバは、前記構成情報管理手段により前記配布プログラムが登録された時に前記構成情報を前記中間サーバに送信し、
前記中間サーバは、前記端末から前記更新要求が送信された時に前記配布サーバにより送信された更新情報に基づいて更新するコンポーネントとソフトウェアのバージョンとを確認することを特徴とする請求項２記載のソフトウェア更新情報配布システム。
【請求項４】
前記更新情報生成手段は、前記端末により前記更新要求が送信された時にこの更新要求に対応した前記過去更新情報が前記更新情報保持手段に存在した場合にこの過去更新情報に基づいて前記更新要求に対応した前記更新情報を生成することを特徴とする請求項１記載のソフトウェア更新情報配布システム。
【請求項５】
前記更新情報生成手段は、前記端末により前記更新要求が送信された時にこの更新要求に対応した前記過去差分情報が前記更新情報保持手段に存在した場合にこの過去差分情報に基づいて前記更新要求に対応した前記更新情報を生成することを特徴とする請求項１記載のソフトウェア更新情報配布システム。
【請求項６】
前記中間サーバは、前記配布パッケージ生成手段により生成された前記配布パッケージを前記端末で利用するための記憶媒体にコピーすることを特徴とする請求項１記載のソフトウェア更新情報配布システム。
【請求項７】
前記中間サーバは、前記更新情報生成手段により生成された前記更新情報に基づいて前記端末に送信する配布用差分情報を生成する差分情報生成手段を備え、
前記配布パッケージ生成手段は、前記差分情報生成手段により生成された前記配布用差分情報とこの配布用差分情報を前記端末にインストールされたソフトウェアに適用する手順とがパッケージされた差分情報配布パッケージを生成し、
前記配布パッケージ送信手段は、前記配布パッケージ生成手段により生成された差分情報配布パッケージを前記端末に送信することを特徴とする請求項１記載のソフトウェア更新情報配布システム。
【請求項８】
過去のソフトウェア更新に利用された過去更新情報と過去差分情報とが保持された更新情報保持ステップと、
端末によりインストールされたソフトウェアの更新要求が送信された時にこの更新要求に対応した前記過去更新情報と前記過去差分情報とが存在しない場合にソフトウェアを更新する新旧ソフトウェアの差分情報が保存された配布サーバから前記更新要求に対応した差分情報を取得する差分情報取得ステップと、
前記差分情報取得ステップにより取得された前記差分情報に基づいて前記更新要求に対応した前記更新情報を生成する更新情報生成ステップと、
前記更新情報生成ステップにより生成された前記更新情報とこの更新情報を前記端末にインストールする手順とがパッケージされた配布パッケージを生成する配布パッケージ生成ステップと、
前記配布パッケージ生成ステップにより生成された配布パッケージを前記端末に送信する配布パッケージ送信ステップと、
を備えたことを特徴とするソフトウェア更新情報配布方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末にインストールされているソフトウェアのバージョンアップに関するものである。
【背景技術】
【０００２】
配布サーバとターゲット端末間に中間サーバを配置したソフトウェアの２次配布については、例えば、配布サーバの負荷削減、中間サーバのリソース節約を図りながら、多数のターゲット端末のソフトウェアのバージョンアップを効率化する技術が示されている。
しかし、中間サーバ配下のターゲット端末間で使用するソフトウェアバージョンは同一版とすることを前提としており、個々のターゲット端末で異なるバージョンを使用するケースについては開示されていない。また、差分情報の配布によるバージョンアップや、ソフトウェアが複数コンポーネント構成である場合の方法についても開示されていない（例えば、特許文献１）。
【０００３】
また、中間サーバを配置したソフトウェア配布において、配布サーバと中間サーバ間でバージョン間・ファイル間等の差分情報を送付することで、ネットワーク負荷を軽減し、他のアプリケーションの実行の妨げとなる危険を回避する技術についても示されている。
しかし、差分情報の生成は配布サーバ上で行い、中間サーバに配布するものとしており、必要に応じて中間サーバ上で作成する技術については開示されていない。また、 ソフトウェアが複数コンポーネント構成である場合の方法についても開示されていない（例えば、特許文献２）。
【特許文献１】特開平９−１４６８６１号公報
【特許文献２】特開２００３−９９２９７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
比較的大規模なソフトウェアにおいては、複数のコンポーネントから構成される傾向にある。コンポーネントとは、１つのまとまった機能単位として提供されるもので、特に大規模なソフトウェアなどで多く見られる形態であり、ソフトウェアを機能単位で部品化し、独立性・共有化/再利用性を高めることでソフトウェア開発・保守を効率化できるといった利点がある。
複数のコンポーネント構成を持つソフトウェアはこれらのコンポーネントを組み合わせた形でリリースされる。
なおこのような複数コンポーネントからなるソフトウェアの開発は、通常、コンポーネント単位で行われるため、バージョンアップの実施タイミングもコンポーネント間で異なるケースが多い。
【０００５】
また、使用するコンポーネント間には通常バージョンの依存関係あることが多い。この場合、各コンポーネントは適切なバージョンの組み合わせで使用しないと、正常に動作しない場合もありうる。このような場合、ソフトウェアのバージョンアップ時においては、各コンポーネントのバージョン依存関係に従い適切なバージョンのコンポーネントを選択する必要があり、運用手続きが煩雑化する。
さらに、中間サーバ配下の端末で使用するソフトウェアのバージョンが単一ではなく異なる複数バージョンを使用する運用においては、バージョンアップする新版のバージョンが端末間で同一でない場合もありうる。そのため、同じユーザ拠点内の端末でも、バージョンアップ時の更新パターン（旧版と新版のソフトウェアのバージョンの組み合わせ）が複数となる（端末により異なる）場合が生じ、運用が一層煩雑となる。
また、このような複数コンポーネント構成を持つソフトウェアはサイズが大きくなる傾向がある。バージョンアップする場合、必要コンポーネントを配布サーバから取得すれば良いが、サイズの面から、このように複数コンポーネントで構成されるソフトウェアバージョンアップデータの配布にはネットワークへの負荷が増大することが懸念される。
【０００６】
本発明は上記のような問題点を解決するためになされたもので、配布サーバから中間サーバに配布するデータは、各コンポーネントのバージョン間差分データとし、転送データ量を抑え、両者間のネットワーク負荷の軽減を図る。
また、配布サーバは、各コンポーネント毎のバージョン間差分情報と、各ソフトウェアのバージョン毎に必要なコンポーネントとそのバージョン情報のみを提供・管理するだけでよく、各端末にインストールされたソフトウェアのあらゆるコンポーネント構成を考慮したバージョンアップデータを用意する必要はなく、サーバ運用の作業負荷軽減を図る。
【０００７】
さらに、中間サーバは、配下の端末に必要なコンポーネントのみの差分情報を取得、新版配布イメージ作成、端末へ配布を行なうことで、配布サーバや中間サーバのリソース節約及びネットワーク負荷の軽減を図る。またこれと同時に、端末間で複数バージョンのソフトウェアを混在使用するケースや、直接配布サーバにアクセスすることが出来ない端末が存在するケースでのバージョンアップ業務を簡易・効率的に行なうことを実現する。
【０００８】
また、中間サーバから端末に、バージョンアップのためのバージョン間差分データを送付し、これを受信した端末上で差分適用による新版の配布イメージ作成及びインストールを行なうことで、中間サーバから端末に配布するバージョンアップ用データのサイズを抑制し、両者間のネットワーク負荷を削減することができる。
さらに、中間サーバと配布サーバ間のネットワーク負荷を削減することができる。
【課題を解決するための手段】
【０００９】
この発明に係るソフトウェア更新情報配布システムは、ソフトウェアを更新する新旧ソフトウェアの差分情報が保存された配布サーバと、
インストールされたソフトウェアの更新要求を送信する端末と、
過去のソフトウェア更新に利用された過去更新情報と過去差分情報とが保持された更新情報保持手段と、前記端末により前記更新要求が送信された時にこの更新要求に対応した前記過去更新情報と前記過去差分情報とが前記更新情報保持手段に存在しない場合に前記配布サーバに保存された前記差分情報の中から前記更新要求に対応した差分情報を取得する差分情報取得手段と、前記差分情報取得手段により取得された前記差分情報に基づいて前記更新要求に対応した前記更新情報を生成する更新情報生成手段と、前記更新情報生成手段により生成された前記更新情報とこの更新情報を前記端末にインストールする手順とがパッケージされた配布パッケージを生成する配布パッケージ生成手段と、前記配布パッケージ生成手段により生成された配布パッケージを前記端末に送信する配布パッケージ送信手段とを有する中間サーバと、を備えたものである。
【発明の効果】
【００１０】
この発明は、中間サーバが、端末によりソフトウェアの更新要求が送信された時にこの更新要求に対応した過去更新情報と過去差分情報とを自らが保存していない場合にソフトウェアを更新する新旧ソフトウェアの差分情報が保存された配布サーバから更新要求に対応した差分情報を取得し、この差分情報に基づいて更新要求に対応した更新情報を生成し、この生成した更新情報とこの更新情報を端末にインストールする手順とがパッケージされた配布パッケージを生成し、この配布パッケージを端末に送信することにより、中間サーバが端末のソフトウェアの更新のための情報を配布サーバや端末へ最小限のアクセス及び最小限の情報量により行なうことできるので、ネットワークの負荷削減ができ、端末のソフトウェアの更新を短時間に効率よく実行することができる。
【発明を実施するための最良の形態】
【００１１】
実施の形態１．
図１は、実施の形態１のソフトウェア２次配布システムの構成図である。
図に示すように、ソフトウェア２次配布システムは、ソフトウェアを配布するための配布サーバ１００と、これとネットワークで接続された１台以上の中間サーバ２００が存在する。また、中間サーバ２００の配下には、１台以上の端末３００（端末３００ａ、端末３００ｂ、端末３００ｃ、・・・）が存在する。中間サーバ２００と配下の端末３００は、ネットワークで接続されたオンライン状態と、ネットワーク接続されていないオフライン状態の２種類の状態で存在する。
【００１２】
端末３００には、配布サーバ１００で配布するソフトウェアがインストールされており、ユーザがこれらのソフトウェアを利用している。
なお、図中では中間サーバ２００は１台しか図示していないが、１台以上の構成とし、各中間サーバ２００はそれぞれ、上記のように配下に１台以上の端末３００がオンライン状態あるいはオフライン状態で接続されているものとする。
【００１３】
次に、コンポーネントの一般概要について説明する。
図２は、配布対象となるソフトウェアの構成と更新状況（更新履歴）の説明図である。
配布対象となるソフトウェアは複数のコンポーネントにより構成され、本実施の形態ではＣｏｍｐ１、Ｃｏｍｐ２という名称の２つのコンポーネントから構成されている。
一般的に、コンポーネントとは、それぞれがまとまったプログラムの単位であり、ソフトウェアの部品化・再利用性を高め、開発・保守の効率化を図るために導入された考え方である。
【００１４】
１つのコンポーネントに相当するプログラム実体は、１つ以上のプログラムファイルから構成され、プログラムから参照される１つ以上のデータファイルが含まれる場合もありうるものとする。また、コンポーネントは個別にバージョンアップを行っており、バージョンアップの実施タイミングはコンポーネント間で異なる場合がありうるものとする。さらに、各コンポーネントはコンポーネント間でバージョンの依存関係があり、各コンポーネントは正しいバージョンの組み合わせでないと正常に動作しない場合もありうるものとする。
【００１５】
次に、本実施の形態のソフトウェアのコンポーネントについて説明する。
本実施の形態では、例えば、Ｃｏｍｐ2は他のソフトウェアでも利用されるコンポーネント（共通コンポーネントとする）であり、Ｃｏｍｐ1はこのソフトウェアのみで使用するコンポーネント（専用コンポーネントとする）といった性質を持つコンポーネントと考えても良い。従って、共通コンポーネントＣｏｍｐ２は、Ｃｏｍｐ１以外の専用コンポーネントと組み合わせ他のソフトウェアとして利用することも可能性である。
【００１６】
次に、本実施の形態のソフトウェアのコンポーネントのリリース状況について説明する。
図２に示すように、Ｃｏｍｐ１とＣｏｍｐ２はバージョン８.０Ａを同時にリリースしており、現在各コンポーネントのバージョンは、Ｃｏｍｐ１は８.０Ａから８.３Ｄまでの４種類のバージョン、Ｃｏｍｐ２は８.０Ａと８.１Ｂの２種類のバージョンがリリースされている。
専用コンポーネントＣｏｍｐ１は共通コンポーネントＣｏｍｐ２を必要とする。また両者はバージョンに関して依存関係があり、Ｃｏｍｐ１８.０ＡはＣｏｍｐ２の８.０Ａを前提として開発されたものである。
【００１７】
なお、Ｃｏｍｐ１は８.０Ａリリース後、８.１Ｂ、８.２Ｃ、８.３Ｄと３回のバージョンアップを実施している。一方、その間Ｃｏｍｐ２は８.１Ｂと１回だけバージョンアップを実施している。このため、Ｃｏｍｐ１のＣｏｍｐ２とのバージョン依存関係は、Ｃｏｍｐ１が８.０Ａ〜８.１ＢまではＣｏｍｐ２は８.０Ａで、Ｃｏｍｐ１が８.２ＣからはＣｏｍｐ２は８.１Ｂのリリース後ということもあり、Ｃｏｍｐ２は８.１Ｂとなっているものとする。
【００１８】
次に、本実施の形態のソフトウェアの更新パターンについて説明する。
図２に示す端末３００ａ、端末３００ｂの２台の端末をバージョンアップするケースを例に説明する。本実施の形態でのバージョンタイミングは以下のとおりとする。
端末３００ａは、前回バージョンアップにより、現在Ｃｏｍｐ１が８.１Ｂ、Ｃｏｍｐ２が８.０Ａの状態である。また、端末３００ｂは、前回バージョンアップにより、現在Ｃｏｍｐ１が８.２Ｃ、Ｃｏｍｐ２が８.１Ｂの状態である。
今回のバージョンアップは、端末３００ａ、端末３００ｂの２台共、Ｃｏｍｐ１が８.３Ｄ、Ｃｏｍｐ２が８.１Ｂのそれぞれ最新版に更新するケースを例に説明する。
【００１９】
まず、配布サーバ１００の構成について説明する。
図３は、配布サーバ１００の構成図である。
配布サーバ１００は、構成情報管理手段１０１と差分情報生成手段１０２とを有し、構成情報管理手段１０１は配布対象とするソフトウェアの管理を行っている。具体的にはソフトウェアの各コンポーネントの構成とソフトウェアのバージョンの対応関係が定義された構成情報１００ａと、ソフトウェアのプログラム実体に相当する配布プログラム１００ｂと、の登録・管理を行っている。また、差分情報生成手段１０２は、登録された配布プログラム１００ｂの２つのバージョン間の差分情報１００ｃの生成を行なう。
【００２０】
次に、構成情報１００ａ、配布プログラム１００ｂ、差分情報１００ｃについて詳細に説明する。
構成情報１００ａは、図３に示すとおり、ソフトウェアの各バージョン番号とソフトウェアを構成するコンポーネントのバージョンとの対応関係を定義したテーブル情報である。
なお先に記載したように、Ｃｏｍｐ１を専用コンポーネント、Ｃｏｍｐ２を共通コンポーネントとすると、本実施の形態でのバージョンアップ対象とするソフトウェアは、専用コンポーネントであるＣｏｍｐ１のバージョンアップの都度、ソフトウェアのバージョン番号が更新され、これに伴ってソフトウェアのバージョンアップが発生することになる。これは次のことによるものである。
【００２１】
共通コンポーネントであるＣｏｍｐ２は、専用コンポーネントであるＣｏｍｐ１とは別に独自のスケジュールでバージョンアップがなされる場合もありうるが、Ｃｏｍｐ２がバージョンアップすると、依存関係にあるＣｏｍｐ１もこのバージョンアップに対応するための何らかの改修が必要となる可能性があり、Ｃｏｍｐ２のみバージョンアップしてもＣｏｍｐ１は正常動作しない可能性もある。またＣｏｍｐ１が影響を受けず、正常動作しうる場合でも、Ｃｏｍｐ２だけ個別にバージョンアップするためにソフトウェアのバージョンアップを実施するのは、運用上、手間やコストがかかり、またユーザへの負担も大きくなってしまう。
【００２２】
このようにＣｏｍｐ１は、Ｃｏｍｐ２のバージョンに依存するため、Ｃｏｍｐ１のバージョンアップ時には、Ｃｏｍｐ２のどのバージョンを対象とするか決定し、動作を保証する必要がある。このため、Ｃｏｍｐ１を前回リリース後、Ｃｏｍｐ２がバージョンアップされた場合、通常、期間的に間に合えば次のＣｏｍｐ１のバージョンアップで新しいＣｏｍｐ２に対応すること、つまりＣｏｍｐ１と一緒にＣｏｍｐ２もバージョンアップすることを考える。
よって、専用コンポーネントであるＣｏｍｐ１をバージョンアップした際にソフトウェアのバージョンも更新され、共通コンポーネントであるＣｏｍｐ２がバージョンアップされた場合は、専用コンポーネントであるＣｏｍｐ１のバージョンアップのタイミングに合わせて共通コンポーネントであるＣｏｍｐ２のバージョンアップも同時に実施するというケースが妥当と考える。
【００２３】
以上のことにより、構成情報１００ａの更新タイミングは、Ｃｏｍｐ１がバージョンアップされ、ソフトウェアのバージョンが更新となる場合とする。
本実施の形態では、Ｃｏｍｐ１：８.０Ａ、Ｃｏｍｐ２：８.０Ａはバージョン１、Ｃｏｍｐ１：８.１Ｂ、Ｃｏｍｐ２：８.０Ａはバージョン２、・・・と定義しており、最新版はバージョン４で、Ｃｏｍｐ１が８.３Ｄ、 Ｃｏｍｐ２が８.１Ｂの対応関係となっている。
【００２４】
また、これと同時に、構成情報管理手段１０１は該当する配布プログラム１００ｂを配布サーバ１００に登録するものとする。さらに、この登録後、配布サーバ１００は、中間サーバ２００に更新した構成情報１００ａを送信し、バージョンアップのあったことを通知するものとする。
中間サーバ２００は、受信した構成情報１００ａを構成情報２００ａとして保持し、端末３００からバージョンアップ要求があった場合は、保持した構成情報２００ａを参照してソフトウェアのバージョンに対応した必要コンポーネントのバージョンを確認するものとする。
【００２５】
次に、配布プログラム１００ｂについて説明する。
図４は、配布プログラム１００ｂの説明図である。
配布プログラム１００ｂは、各コンポーネントの各バージョン毎に生成・登録されるものとする。そしてその実体は、プログラム本体（実行プログラムファイル類、及びこれが参照するデータファイル類）と、このプログラムをインストールするためのインストーラ用ファイル（ｗｉｎｄｏｗｓのレジストリ情報などの動作環境設定情報ファイルやインストールスクリプトファイル）の２種類が含まれる。実体を構成するこれらのファイル群をまとめてプログラムファイルと呼ぶこととする。
【００２６】
配布プログラム１００ｂの配布サーバ１００への登録タイミングは、Ｃｏｍｐ１のバージョンアップタイミング、つまりソフトウェアのバージョンアップタイミングで行われる。その際、構成情報１００ａも同時に更新を行い、構成情報１００ａに定義されたソフトウェアのコンポーネントの構成とソフトウェアのバージョンとの対応関係の実体である配布プログラム１００ｂが必ず登録されているものとする。
【００２７】
次に、差分情報１００ｃについて説明する。
図５は、差分情報１００ｃの説明図である。
差分情報１００ｃは、差分情報生成手段１０２によりコンポーネント単位で生成・登録される。差分情報１００ｃの生成は、新旧各版の配布プログラム１００ｂ中のプログラムファイルを対象に行なう。
また、差分情報１００ｃの生成・登録のタイミングは、通常は、各コンポーネント毎の配布プログラムが登録された後に、直前の版との差分生成を行なうものとする。あるいは、バージョンアップの運用形態に応じ、最も実施ケースの多い更新パターンで生成する運用としても良い。
【００２８】
以下、図５に従って、差分情報１００ｃの構成について説明する。
差分情報１００ｃは、更新情報ファイル、バイナリ差分ファイル、追加ファイルの３種類のファイルから構成される。
更新情報ファイルは、バージョンアップ時のファイル更新状況及び各ファイルのインストール先情報を記述したファイルである。ここで、ファイル更新状況とは、旧版ファイルの全ファイルに対する新版での更新状態（更新なし、更新あり、削除のいずれか）及び新版で追加されたファイルの情報（ある場合のみ）で、インストール先情報とは更新ファイル、追加ファイルに関しての端末上でのインストール先ディレクトリを示した情報である。
【００２９】
バイナリ差分ファイルは、配布プログラム１００ｂのプログラムファイルのうち、更新のあったファイルに対しファイル毎に生成され、新旧バージョン間でファイルのバイナリ比較を行い、その結果の差分データを出力したファイルである。
追加ファイルは、旧版には存在せず新版で追加されたファイルが存在する場合のみ含まれる。実体は追加されたファイルそのものとする。
なお、プログラムファイルのうち、インストール用のファイルもバイナリ差分抽出対象としているが、バイナリ差分抽出対象外とし、上記の各ファイルとは別に、インストールファイルとして新版のインストールファイルをそのまま差分情報１００ｂに含める方式としても構わない。
【００３０】
次に、中間サーバ２００の構成について説明する。
図６は、中間サーバ２００の構成図である。
中間サーバ２００は、バージョン確認手段２０１、差分情報取得手段２０２、配布イメージ生成手段２０３、配布イメージ保持手段２０４、配布パッケージ生成手段２０５、配布パッケージ送信手段２０６を有する。
また、中間サーバ２００は配布サーバ１００より構成情報１００ａを受信し、構成情報２００ａとして保持する。同様に、配布サーバ１００が送信した差分情報１００ｂを差分情報２００ｂとして保持する。
【００３１】
配布イメージ生成手段２０３は、旧版の配布プログラム１００ｂ（中間サーバ２００上の配布イメージ２００ｃ）と上記差分情報２００ｂとに基づいて配布イメージ２００ｃを生成する。なお、配布イメージ２００ｃは、配布サーバ１００上の同一コンポーネント・バージョンの配布プログラム１００ｂとは同一であり、端末３００のソフトウェアを更新する更新情報となるものである。
また、配布パッケージ生成手段２０５は、各端末３００のバージョンアップに応じた配布パッケージ２００ｄを作成する。作成した配布パッケージ２００ｄを各端末３００へそれぞれ配布し、各端末３００でそれぞれ配布パッケージ２００ｄを受信してソフトウェアのバージョンアップを行なう。
【００３２】
次に、端末のバージョンアップにおける中間サーバ２００の動作について説明する。
図７は、端末のバージョンアップ例についての説明図である。
図7のバージョンアップ例に従って、バージョンアップ時におけるソフトウェアの配布手順について説明する。
図１の配布サーバ２００の配下に端末として端末３００ａと３００ｂの２台が存在し、２台の端末で異なるバージョンのソフトウェアを使用している。図３の構成情報１００ａに示すところのソフトウェアバージョンは、図２に示すように端末３００ａがバージョン２（Ｃｏｍｐ１が８.１Ｂ、Ｃｏｍｐ２が８.０Ａ）、端末３００ｂがバージョン３（Ｃｏｍｐ１は８.２Ｃ、Ｃｏｍｐ２は８.１Ｂを使用）となっている。
【００３３】
これまで、端末３００ｂでは最新バージョンのソフトウェアを動作させており、端末３００ａではバックアップ用に最新バージョンより１つ古いバージョンのソフトウェアが動作する運用となっていたとすると、端末３００ｂで最新版であるがために発生しうる未知の障害が発生した場合でも、動作実績のある旧版である端末３００ａでいつでも動作可能な状態として運用されるような状態になっていた。
しかし、図７に示す今回のバージョンアップでは、ソフトウェアの最新バージョンであるバージョン４（Ｃｏｍｐ１：８.３Ｄ、Ｃｏｍｐ２：８.１Ｂ）がリリース後の時間経過により品質が安定してきた等の理由により、今回は１つ古いバージョンを残す運用はやめ、端末３００ａ、端末３００ｂとも、ソフトウェアを最新のバージョン４にバージョンアップすることとした。
【００３４】
端末３００ａで必要となるコンポーネントは、構成情報２００ａの定義によると、Ｃｏｍｐ１の８.３ＤはＣｏｍｐ２が８.１Ｂである必要があることから、端末３００ａはＣｏｍｐ１が８.１Ｂから８.３Ｄへバージョンアップする際、Ｃｏｍｐ２も８.０Ａから８.１Ｂとバージョンアップする必要がある。
このことから、必要となる差分情報２００ｂは、Ｃｏｍｐ１が８.１Ｂ→８.３Ｄの差分情報、Ｃｏｍｐ２が８.０Ａ→８.１Ｂの差分情報と２種類の差分情報が必要となる。
【００３５】
一方、端末３００ｂで必要となるコンポーネントは、構成情報２００ａの定義によると、Ｃｏｍｐ１が８.２Ｃに対しＣｏｍｐ２は８.１Ｂがインストールされている状態のため、Ｃｏｍｐ１を８.３Ｄにバージョンアップする場合、Ｃｏｍｐ２は８.１Ｂが必要だが、Ｃｏｍｐ２は既に８.１Ｂであるため、Ｃｏｍｐ１のみバージョンアップすれば良いことになる。
このことから、必要となる差分情報２００ｂは、Ｃｏｍｐ１が８.２Ｃ→８.３Ｄの１種類のみとなる。
【００３６】
次に、中間サーバ２００のバージョンアップの処理について説明する。
図８は、端末３００のソフトウェアをバージョンアップする際の中間サーバ２００の処理手順を示したフローチャートである。
図８に従い、図７のバージョンアップ例を例に、中間サーバ２００で行なうバージョンアップの処理手順について説明する。
本実施の形態では、図７のバージョンアップ例に従い、端末３００ａと端末３００ｂとを同時にバージョンアップする場合について説明する。
なおここでは、中間サーバ２００は、バージョンアップ対象となるソフトウェアを利用しているユーザ拠点内にあり、中間サーバ２００と端末３００ａ、端末３００ｂの２台の端末はネットワークで接続されているものとする。
まず、ステップＳ１で、中間サーバ２００のバージョンアップ要求受信手段２０１は、ユーザが端末３００ａ、端末３００ｂの入力装置あるいは直接中間サーバ２００上の入力装置からバージョンアップ対象とする端末情報（端末３００ａと端末３００ｂ）とバージョンアップするバージョン番号とを入力することにより発行されるバージョンアップ要求を受信する。ここで、端末３００ａ、端末３００ｂの入力装置への入力によるバージョンアップ要求はネットワークを介して中間サーバ２００に送信される。
【００３７】
ここで、中間サーバ２００へのバージョンアップ要求の発行は、端末３００ａ、端末３００ｂから、それぞれ個別のタイミングでも、同時に行っても構わないものとする。
また、中間サーバ２００上に専用のアプリケーションを用意するなどして、一括して複数端末・複数更新パターンのバージョンアップ要求を同時に発行できるようにしても良い。この場合、中間サーバ２００は、要求を解析して必要な更新パターンの数、及びそれぞれに必要な配布イメージを判定し、さらにより効率的な配布イメージや配布パッケージの生成方法の決定・生成処理を行なうものとし、これによりユーザのバージョンアップ運用を簡易にかつ効率的に行なえるようにすることができる。
【００３８】
次に、ステップＳ２で、中間サーバ２００は、上記バージョンアップ要求を受信すると、バージョンアップ対象に指定した端末３００ａ、端末３００ｂにインストールされているソフトウェアのバージョンを確認する。
端末３００ａ、端末３００ｂに対するバージョン確認は、中間サーバ２００がネットワークを介して、端末３００ａ、端末３００ｂの端末上のセットアップ時に設定されたバージョン情報などを参照するなどの既存方式により行なう。あるいは、バージョンアップ実施の都度、中間サーバ２００上に各端末のインストールバージョン情報を記録しておき、これを参照するなどの既存方式としても良い。
【００３９】
なお、中間サーバ２００とネットワーク接続されていない端末３００の場合は、中間サーバ２００上でユーザ入力等により、前回バージョンアップ時の情報を中間サーバ２００上に保持しておきこれを参照する、あるいは中間サーバ２００上で現在インストールされているバージョン番号を手動でユーザが入力する、といった方式で対応することも考えられる。
また、バージョン確認は、端末３００から構成情報１００ａまたは構成情報２００ａで定義されているソフトウェアとしてのバージョン番号（バージョン１〜バージョン４）あるいは、この各バージョンに対応する個々の構成コンポーネントのバージョン番号（Ｃｏｍｐ１、Ｃｏｍｐ２のバージョン番号）、またはこれら双方を取得することにより行なうものとする。
本実施の形態では、ステップＳ２において端末３００ａの現在バージョンがバージョン２（Ｃｏｍｐ１：８.１Ｂ、Ｃｏｍｐ２：８.０Ａ）、端末３００ａの現在バージョンがバージョン３（Ｃｏｍｐ１：８.３Ｃ、Ｃｏｍｐ２：８.１Ｂ）であるとの情報を得る。
【００４０】
次に、中間サーバ２００はステップＳ２に続き、以下のステップＳ３〜Ｓ６の処理を行なう。
ステップＳ３で、中間サーバ２００上に存在する構成情報２００ａあるいは配布サーバ１００上に存在する構成情報１００ａの確認をして構成情報を得る。これによりソフトウェアを現在のバージョンから指定されたバージョンにバージョンアップする場合の各コンポーネント毎のバージョンアップパターンを判別し、必要コンポーネント及びバージョン情報を得る。
ここで、中間サーバ２００上の構成情報２００ａには、これまで各端末のバージョンアップ時に配布サーバから得た構成情報が保持されており、この構成情報２００ａと、現時点で配布サーバに保持されている構成情報１００ａと、により今回のバージョンアップに必要となるコンポーネント及びバージョン情報を得るようにしている。
【００４１】
ここでは、端末３００ａは、ソフトウェアのバージョン２からバージョン４へのバージョンアップであり、コンポーネント別にみた場合Ｃｏｍｐ１は８.１Ｂ→８.３Ｄ、Ｃｏｍｐ２は８.０Ａ→８.１Ｂの更新が必要であるという判断を行なう。
また、端末３００ｂは、ソフトウェアのバージョン３から４へのバージョンアップであり、コンポーネント別にみた場合Ｃｏｍｐ１は８.２Ｃ→８.３Ｄ、Ｃｏｍｐ２は８.１Ｂのまま更新の必要なしであるという判断を行なう。
【００４２】
なお、本実施の形態では、端末３００ａ、端末３００ｂ同時に更新要求を受けたケースとするので、両者の旧版・新版から必要なコンポーネント・バージョンを一括して判断する。本実施の形態では、これらをまとめた必要なコンポーネント、即ちコンポネントの配布イメージ２００ｃは、Ｃｏｍｐ１が８.３Ｄ、Ｃｏｍｐ２が８.１Ｂの２つである。
また、この配布イメージ２００ｃを差分情報２００ｂにより生成するとした場合、必要になる差分情報２００ｂは、Ｃｏｍｐ１が８.１Ｂ→８.３Ｄと８.２Ｃ→８.３Ｄの２つ、Ｃｏｍｐ２が８.０Ａ→８.１Ｂの１つの合計３つとなる。
【００４３】
複数の端末３００で同一の配布プログラム１００ｂと差分情報２００ｂを必要とする場合でも、中間サーバに必要な配布プログラム１００ｂと差分情報２００ｂの数は端末数分そろえる必要はなく１つあればよい。例えば、端末３００ａ、端末３００ｂのほかにもう一台端末３００ｘが存在し、３台同時に、なおかつ端末３００ｘは、端末３００ａあるいは端末３００ｂと同様のバージョンアップパターンとする場合、中間サーバ２００で必要な差分情報１００ｂと差分情報２００ｂは１つあればよい。
【００４４】
次に、ステップＳ４で、中間サーバ２００は、ステップＳ３の構成情報確認で得た配布イメージ２００ｃが中間サーバ２００上に存在するか否か確認する。
存在しない場合は、配布イメージ２００ｃを生成する必要があり、そのためには差分情報２００ｂが必要となる。このため、まず、ステップＳ５で、自身の中間サーバ２００上に所望の差分情報２００ｂが存在するかを確認する。この結果、中間サーバ上に存在しない場合は、ステップＳ６で差分情報取得手段２０３が配布サーバ１００より所望の差分情報１００ｃの取得を行なう。
【００４５】
本システムにおいては、バージョンアップ対象となる端末３００に対し、中間サーバ２００は所望のソフトウェアバージョンに対応する特定バージョンの各コンポーネントの配布イメージ２００ｃを作成し、これを配布することにより、端末３００のバージョンアップを行なう。
配布イメージ２００ｃは、配布イメージ生成手段２０３により生成されるものであり、生成には、旧版の配布プログラム１００ｂと、所望のバージョンとの間にバイナリ差分抽出により生成した差分情報１００ｃまたは、差分情報２００ｂが必要である。
このため、まず中間サーバ２００上で完成品である配布イメージ２００ｃが、既に生成済みでないかをステップＳ４でチェックし、存在する場合はこれを利用する。
一方、存在しない場合は、ステップＳ５で自身の中間サーバ２００上に差分情報２００ｂが存在しないかを確認し、存在しない場合のみ、ステップＳ６で配布サーバ１００から差分情報１００ｃを取得する。
【００４６】
このように中間サーバ２００は、配下の複数の端末３００をバージョンアップするためのデータの生成・配布の中継処理を行っている。ここで、中間サーバ２００は今回実行する端末３００のバージョンアップと同一の配布イメージ２００ｃの生成・配布を過去に別の端末３００で実施している場合には、過去に使用した配布イメージ２００ｃやこの配布イメージ２００ｃを生成するための差分情報２００ｂを保存する機能を有している。
従って、中間サーバ２００は、これらの配布イメージ２００ｃや差分情報２００ｂを保持していれば、これらを再利用して配布イメージ２００ｃの生成・配布を行なうことができる。これが、このようにユーザ拠点に複数端末３００が存在するケースにおいて中間サーバ２００を導入するメリットともいえる。
【００４７】
これより、ステップＳ４、ステップＳ５のように端末３００のバージョンアップに必要な情報（構成情報１００ａ、配布プログラム１００ｂ，差分情報１００ｃ）をいきなり配布サーバ１００から取得するのではなく、中間サーバ２００上に端末３００のバージョンアップに必要な配布イメージ２００ｃや差分情報２００ｂが保存されていないか確認し、保存されていない場合にのみステップＳ６のように配布サーバ１００から端末３００のバージョンアップに必要な情報の取得を行なうことにしている。
なお、ステップＳ４の結果、必要となるバージョンアップデータのうち必要な配布イメージ２００ｃが中間サーバ２００上に存在する場合は、ステップＳ５、ステップＳ６の処理はスキップしてステップＳ７に進む。あるいは中間サーバ２００上に、配布イメージ２００ｃはないが、差分情報２００ｂが存在する場合は、ステップＳ６の処理をスキップしてステップＳ７に進む。
【００４８】
次に、図７の端末のバージョンアップ例に従い、上記で説明したステップＳ４〜ステップＳ６の詳細について説明する。
ステップＳ３により、図７のバージョンアップ例で必要なコンポーネント（コンポネントの配布イメージ２００ｃ）は、Ｃｏｍｐ１が８.３Ｄ、Ｃｏｍｐ２が８.１Ｂの２つである。また、この配布イメージ２００ｃを差分情報２００ｂにより生成するとした場合、必要になる差分情報２００ｂは、Ｃｏｍｐ１が８.１Ｂ→８.３Ｄ（端末３００ａ用）と８.２Ｃ→８.３Ｄ（端末３００ｂ用）の２つ、Ｃｏｍｐ２が８.０Ａ→８.１Ｂ（端末３００ａと端末３００ｂとで共通）の１つの合計３つとなることについては先に記載したとおりである。
【００４９】
本実施の形態では、中間サーバ２００は、配下の端末３００ａ、端末３００ｂのこれまでのバージョンアップ履歴に従い、配布イメージ保持手段２０４により以下の配布イメージ２００ｃを持つものとする。
Ｃｏｍｐ１：８.０Ａ、８.１Ｂ、８.２Ｃ（３種類）
Ｃｏｍｐ２：８. ０Ａ、８.１Ｂ（２種類）
また、中間サーバ２００は、配布イメージ２００ｃ生成のために、差分情報２００ｂとして以下を持つものとする。
Ｃｏｍｐ１：８.０Ａ→８.１Ｂ、 ８.１Ｂ→８.２Ｃ（２種類）
Ｃｏｍｐ２：８.０Ａ→８.１Ｂ（３種類）
【００５０】
Ｃｏｍｐ１に関しては、まずステップＳ４で、配布イメージ２００ｃの有無をチェックする。ここで、必要な配布イメージ２００ｃはＣｏｍｐ１の８．３Ｄ、Ｃｏｍｐ２の８.１Ｂの２つであるが、中間サーバ２００にはＣｏｍｐ１の８．３Ｄは存在しない、Ｃｏｍｐ２の８.１Ｂは存在するとの判定結果を得る。
この後、ステップＳ５に進み、ステップＳ４で存在しなかった８．３Ｄの配布イメージ２００ｃの生成に必要な差分情報２００ｂ（８.２Ｃ→８.３Ｄ）の有無をチェックする。
Ｃｏｍｐ２はステップＳ４で所望の８.１Ｂの配布イメージ２００ｃが存在するので、ステップＳ５、ステップＳ６をスキップし、ステップＳ７に進む。
【００５１】
なお、本実施の形態において、端末３００ａ、端末３００ｂの同時バージョンアップケースで必要なＣｏｍｐ１の差分情報２００ｂは、先に８.１Ｂ→８.３Ｄと８.２Ｃ→８.３Ｄの２つと述べたにも関わらず、ステップＳ５では８.２Ｃ→８.３Ｄの１種類としている。この理由は、端末３００ｂ用の８.２Ｃ→８.３Ｄの差分情報２００ｂにより生成した８.３Ｄの配布イメージ２００ｃがあり、これを端末３００ａ用にも流用できるからであり、端末３００ａ用の差分情報２００ｂ（８.１Ｂ→８.３Ｄ）は不要となるからである。
【００５２】
中間サーバ２００は、既にＣｏｍｐ１を８.１Ｂ→８.２Ｃにするバージョンアップを実施済みのため、端末３００ｂ用に８.２Ｃの配布イメージ２００ｃを保持している。従って、端末３００ｂ用のＣｏｍｐ１の８.２Ｃを８．３Ｄにバージョンアップするための差分情報を配布サーバから入手し、これに基づいてＣｏｍｐ１の８.３Ｄの配布イメージ２００ｃを作成することができるため、端末３００ａで必要なＣｏｍｐ１の８.３Ｄの配布イメージ２００ｃはこれを利用することができるので、端末３００ａとして必要であったＣｏｍｐ１の８.１Ｂ→８.３Ｄの差分情報は不要となる。
また、Ｃｏｍｐ２に関しては、端末３００ｂで既に８.１Ｂとなっていることから、ステップＳ４では中間サーバ２００上に所望の８.１Ｂの配布イメージ２００ｃが存在すると判定され、ステップＳ５〜ステップＳ７の処理は不要となり、既存の８.１Ｂの配布イメージ２００ｃを再利用する形で端末３００ａに送付すれば良い。
【００５３】
このように中間サーバ２００では、端末のバージョンアップに必要となる差分情報１００ｂを配布サーバ１００から取得することを、配布サーバ１００への最小限のアクセスにより効率よく行なうことでき、ネットワークの負荷削減、ＣＰＵ／ディスク容量などのリソース節約、実行時間短縮といった効果を得ることができる。
【００５４】
次に、ステップＳ４〜ステップＳ６の処理に続き、中間サーバ２００は配布イメージ生成手段２０３によりステップＳ７の処理を行なう。ステップＳ７では、配布イメージ生成手段２０３が、バージョンアップが必要な端末３００で必要とされる配布イメージ２００ｃを生成する。
さらに、ステップＳ８で、配布パッケージ生成手段２０５が、更新パターン毎に必要な配布イメージ２００ｃ（新規生成した配布イメージ及び既存配布イメージ）の組み合わせと、さらにこれらのインストール処理起動などを行なうためのインストールスクリプトとをパッケージした配布パッケージ２００ｄを生成する。
この後、ステップＳ９で、配布パッケージ送信手段が、バージョンアップ対象端末３００に対し、それぞれの端末の更新パターンに対応した配布パッケージ２００ｄを選択し、これを配布する。 
【００５５】
なお、配布イメージ生成手段２０３は、中間サーバ２００上で差分情報２００ｂの適用により配布イメージ２００ｃを最初に生成すると共に、配布イメージ生成手段２０３が過去に差分情報を利用して生成し、配布イメージ保持手段２０４により保存された配布イメージ２００ｃに対し、新たに差分情報を適用し新たに配布イメージ２００ｃを生成することを行なうものである。
【００５６】
次に、ステップＳ７の配布イメージ生成処理及びステップＳ８の配布パッケージ生成処理の概要について説明する。
先に記載したとおり、端末３００ａと端末３００ｂを同時バージョンアップする場合に必要な配布イメージ２００ｃのうち、Ｃｏｍｐ１の８.３Ｄは中間サーバ２００になかったので新規生成し、Ｃｏｍｐ２の８.１Ｂは中間サーバ２００にあったのでこれを流用することとしている。
まず、配布イメージ生成手段２０３は、ステップＳ７での配布イメージ生成処理においてＣｏｍｐ１の８.３Ｄの配布イメージ２００ｃの新規生成を行なう。
【００５７】
続いて、ステップＳ８で配布パッケージ生成手段２０５が配布パッケージ生成処理において次の処理を行なう。
（１）各更新パターンに対し、必要な配布イメージ２００ｃをインストールするためのインストールスクリプトを生成する。
（２）上記（１）で生成されたインストールスクリプトと所望の配布イメージ２００ｃをパッケージした配布パッケージ２００ｄの生成を行なう。
ここで、上記のインストールスクリプトは、更新パターン（インストールする配布イメージ２００ｃの組み合わせ）の数に応じて生成する必要がある。
図７のバージョンアップ例では、端末３００ａと端末３００ｂとで異なる更新パターンになるため、この２台の端末別に２種類の配布パッケージ２００ｄを生成する必要がある。
【００５８】
次に、ステップＳ７の配布イメージ生成処理とステップＳ８の配布パッケージ生成処理についてさらに詳細に説明する。
まず、ステップＳ７で配布イメージ生成手段２０３がＣｏｍｐ１の８.３Ｄの配布イメージ２００ｃを生成する処理について説明する。
Ｃｏｍｐ１の８.３Ｄの配布イメージ２００ｃは、ステップＳ６で配布サーバ１００から取得した８.２Ｃ→８.３Ｄの差分情報２００ｂを、既に中間サーバ２００上に配布イメージ２００ｃとして配布イメージ保持手段２０４により保存されている８.２Ｃのプログラムファイルに適用することにより生成する。
なお、差分情報２００ｂを旧版（ここでは８.２Ｃ）の配布イメージ２００ｃに適用して新版（ここでは８.３Ｄ）のプログラムファイルを生成する処理は、中間サーバ２００上に用意した差分適用プログラムにより行なうものとする。
【００５９】
また、差分適用プログラムは既存方式によるものとし、詳細はここでは省略するが、以下のような処理を行なうものとする。即ち、差分適用プログラムは、差分情報及び旧版に相当するＣｏｍｐ１のバージョンチェックを行い、続いてバージョンが適合した場合更新情報ファイルの内容に従い、旧版のＣｏｍｐ１の８.２Ｃのプログラムファイルに対し、追加ファイルのコピー、更新ファイルに対するバイナリ差分ファイルの差分情報の解析・適用、削除ファイルの削除を行い、新版の８.３Ｄのプログラムファイルへの書き換えを行なう。
さらに、差分情報１００ｃの利用による新規生成が必要な配布イメージ２００ｃは、図７のバージョンアップ例のケースでは、Ｃｏｍｐ１の８.３Ｄが１個のみであるが、複数ある場合は、２つ目以降の配布イメージ２００ｃの生成処理を続けて行なう。
【００６０】
次に、図７のバージョンアップ例の場合に、ステップＳ８で配布パッケージ生成手段２０５が配布パッケージ２００ｄを生成する処理について説明する。
図９は、配布パッケージ２００ｄの構成図である。
まず、配布パッケージ生成手段２０５がステップＳ８の配布パッケージ生成処理で行なう配布パッケージ向けインストールスクリプトの生成について説明する。
インストールスクリプトの内容は共通とし、先に記載したＣｏｍｐ１とＣｏｍｐ２のそれぞれの旧版（現在バージョン）と新版のバージョンを元に、インストール実行前のバージョンチェック処理、及び必要に応じＣｏｍｐ１及びＣｏｍｐ２それぞれのインストールプログラムを起動する処理がスクリプトとして記述されているものとする
図７に示すバージョンアップ例の更新パターンの例では、先に述べた通り端末３００ａと端末３００ｂで異なる更新パターンとなるため、この２台の端末個別に２種類生成する必要がある。
【００６１】
次に、配布パッケージ生成手段２０５がステップＳ８で行なう配布パッケージ２００ｄの生成について説明する。
端末３００ａの更新パターンはソフトウェアのバージョン２→バージョン４のケースである。このため、図９に示すとおり、端末３００ａの更新パターン用配布パッケージ２００ｄとして、インストールスクリプトと、Ｃｏｍｐ１の８.３ＤとＣｏｍｐ２の８.１Ｂの配布イメージ２００ｃを合わせたものを生成する。
なおインストールスクリプトには、Ｃｏｍｐ１とＣｏｍｐ２それぞれの旧版（現在バージョン）と新版のバージョン情報を与え、さらにＣｏｍｐ１、Ｃｏｍｐ２双方をバージョンアップする必要があるため、それぞれのインストーラを起動する処理を含んだ処理を記述しておく。
【００６２】
また、端末３００ｂの更新パターンは、ソフトウェアのバージョン３→バージョン４のケースである。このため、図９に示すとおり、端末３００ｂの更新パターン用配布パッケージ２００ｄとして、インストールスクリプトとＣｏｍｐ１の８.３Ｄの配布イメージ２００ｃを合わせたものを生成する。
なおインストールスクリプトには、Ｃｏｍｐ１とＣｏｍｐ２それぞれの旧版（現在バージョン）と新版のバージョン情報を与え、さらにＣｏｍｐ１のみをバージョンアップする必要があるため、Ｃｏｍｐ１のインストーラを起動する処理を記述しておく。
また、配布パッケージ２００ｄは、端末３００ａ、端末３００ｂへの配布時には、配布時のサイズ削減、操作性向上のために、通常のインストーラのような圧縮・自己解凍、自己実行形式で配布されることが望ましい。
【００６３】
次に、ステップＳ９の配布パッケージ配布処理について説明する。
上記のように生成された配布パッケージ２００ｄを、ステップＳ９で配布パッケージ送信手段２０６がそれぞれ端末３００ａ、端末３００ｂにネットワークを介して送付する。
端末３００ａ、端末３００ｂはそれぞれ、配布パッケージを受信後、ユーザがこの適用を実行することでソフトウェアのバージョン４へのバージョンアップが実行される。
【００６４】
なお、端末３００ｃのように中間サーバ２００とネットワーク接続していないオフライン状態の場合は、ステップＳ７で生成した配布パッケージ２００ｄをＣＤ−ＲＯＭなどの記憶媒体にコピーし、これを端末３００ｃへ配布する運用でも良い。
この方式の場合、特に、運用を簡単にする、コストを削減するなどの理由でユーザ拠点で中間サーバ２００を持たない、または持ちたくないケースにおいて、拠点外の計算機を中間サーバ２００としてユーザ拠点の端末３００に応じたバージョンアップ用メディアを生成し、配布する運用とすることも可能である。
また、このような方式により、例えばソフトウェアの販売代理店などが保守サービスの一環として行なうバージョンアップサービスを効率的に行なうことができる。
【００６５】
次に、ステップＳ５、ステップＳ６のより効率的な処理方法について説明する。
なお、ここでは、図７に示すバージョンアップ例の場合を例に、端末３００ａと端末３００ｂが同時ではなく別のタイミングで中間サーバ１００にバージョンアップ要求を発行したケースについて説明する。具体的には、端末３００ａのバージョンアップ要求後に端末３００ｂのバージョンアップ要求を行なう場合について説明する。
【００６６】
まず、端末３００ａでは、必要となる配布イメージ２００ｃはＣｏｍｐ１が８.３Ｄ、 Ｃｏｍｐ２が８.１Ｂであり、Ｃｏｍｐ２は、先に記載した端末３００ａ、端末３００ｂ同時更新の場合と同様、端末３００ｂで既に８.１Ｂとなっていることから、中間サーバ２００上にすでに８.１Ｂが存在するのでこれを再利用すればよい。即ち、ステップＳ４からステップＳ８へスキップする。
【００６７】
次に、Ｃｏｍｐ１に関する処理について説明する。
ステップＳ４で、必要となる配布イメージ２００ｃのうち、Ｃｏｍｐ１の８.３Ｄは中間サーバ２００上に存在しない。このため、差分情報により配布イメージを生成することが必要となることからステップＳ５に進む。
ステップＳ５で、必要となる差分情報１００ｃは、Ｃｏｍｐ１の８.１Ｂ→８.３Ｄとなる。しかしこの差分は２バージョン違いの差分である。即ち、必要となる差分情報１００ｃのＣｏｍｐ１の８.１Ｂ→８.３Ｄは、８.１Ｂ→８.２Ｃと８.２Ｃ→８.３Ｄの２回のバージョンアップからなるものである。
【００６８】
先に述べたように、配布サーバ１００で生成・配布可能な差分情報１００ｃが１バージョン分（１回のバージョンアップ分）のみを対象とするケースでは、配布サーバ１００上には、必要とするＣｏｍｐ１の８.１Ｂ→８.３Ｄの差分情報１００ｃは存在しない。そこで、中間サーバ２００の差分情報取得手段２０２は、８.１Ｂ→８.３Ｄの差分情報１００ｃがなくとも、中間サーバ２００上で所望のＣｏｍｐ１の８.３Ｄの配布イメージ２００ｃを何とか生成する方法、しかも極力配布サーバ１００にはアクセスせずにすむ方法として、中間サーバ２００上の既存の差分情報２００ｂを使って、所望のバージョンの配布イメージ２００ｃを生成できないかチェックする。
【００６９】
この例では、まず中間サーバ２００上に、配布イメージ保持手段２０４により保持されているＣｏｍｐ１の最新バージョンをチェックし、端末３００ｂのバージョンアップ用に使用した８.２Ｃの配布イメージ２００ｃがあることを確認する。
配布イメージ２００ｃの８.２Ｃは、端末３００ａで必要とする８.３Ｄのバージョンとは１つ違うだけなので、８.２Ｃ→８.３Ｄの差分情報を入手し、この差分情報から８.３Ｄの配布イメージ２００ｃを生成することを検討する。
そこでまず中間サーバ２００上に差分情報２００ｂとして存在しないか確認する。しかし、８.３Ｄの配布イメージ２００ｃを生成した実績がないので、当然存在しないため、ステップＳ６に進む。
【００７０】
ステップＳ６で、配布サーバ１００から８.２Ｃ→８.３Ｄの差分情報１００ｃを取得する。
続いて、ステップＳ７で配布イメージ生成手段２０３が、既に存在する８.２Ｃの配布イメージ２００ｃに、上記で取得した８.２Ｃ→８.３Ｄの差分情報２００ｂを適用し、端末３００ａで必要とする８.３Ｄの配布イメージ２００ｃを生成する。その後、配布イメージ保持手段２０４により、中間サーバ２００上に８.３Ｄの配布イメージ２００ｃが保存される。
以上のことにより、端末３００ａに必要な配布イメージ２００ｃのＣｏｍｐ１の８.３Ｄ、Ｃｏｍｐ２の８.１Ｂを中間サーバ２００上に用意でき、ステップＳ８で配布パッケージ生成手段２０５が、配布イメージ２００ｃのＣｏｍｐ１の８.３Ｄ、Ｃｏｍｐ２の８.１Ｂを用いて配布パッケージ２００ｄを生成する。その後、ステップＳ９で配布パッケージ送信手段２０６が配布パッケージ生成手段２０５により生成された配布パッケージ２００ｄを端末３００ａに送信する。
【００７１】
次に、上記に記載した端末３００ａの処理に続いて行なう端末３００ｂのバージョンアップでは、必要となる配布イメージ２００ｃはＣｏｍｐ１の８.３Ｄ１つであるが、これは先の端末３００ａのバージョンアップ用に生成済なのでこれを再利用することとして、ステップＳ８で配布パッケージ２００ｄを生成すればよい。
この例で示すように、配布サーバ１００上には１バージョン間の差分情報１００ｂだけ生成しておけばよく、配布サーバ１００は２回以上のあらゆる更新パターンの差分情報１００ｃを事前、あるいは動的に生成し、配布する必要はない。
【００７２】
これは、中間サーバ２００の配布イメージ生成手段２０３及び配布イメージ保持手段２０４により、中間サーバ２００の配下の他の端末３００のバージョンアップで生成した既存の配布イメージ２００ｃと、配布サーバ１００から取得した既存の１バージョン分の差分情報１００ｂにより、所望の配布イメージ２００ｃを生成することが可能であるため、このような動作を行なうことができるものである。
【００７３】
以上のように本実施の形態によれば、中間サーバ２００が端末３００のソフトウェアバージョンアップに必要となる差分情報１００ｂを配布サーバ１００から取得し、端末３００のソフトウェアバージョンアップのための配布イメージ２００ｃを端末３００に配布することにより、中間サーバ２００が端末３００にインストールされたソフトウェアの更新のための情報を配布サーバ１００や端末３００への最小限のアクセス及び最小限の情報量により効率よく行なうことできるので、ネットワークの負荷削減、ＣＰＵ／ディスク容量などのリソース節約、実行時間短縮といった効果を得ることができる。また、これにより、端末３００のソフトウェアのバージョンアップが短時間にでき、効率的な端末ソフトウェアのバージョンアップを実行することができる。
【００７４】
実施の形態２．
実施の形態１では、端末３００のバージョンアップの方式として、中間サーバ２００上で端末３００に必要な新版の配布イメージ２００ｃを生成し、配布する方式について説明したが、これ以外にも、新版の配布イメージ２００ｃの替わりに、中間サーバ２００が新版にバージョンアップするための差分情報２００ｂを各端末３００に配布することにより、各端末３００にインストールされたソフトウェアのバージョンアップを行なうことができる。以下、本実施の形態では、この差分情報２００ｂの配布による方式について説明する。
ここで、本実施の形態のソフトウェア２次配布システムの構成は、実施の形態１とほぼ同様でであるが、本実施の形態の中間サーバ２００には、端末３００に配布する配布用差分情報の生成を行なう差分情報生成手段２０７（図６参照）が追加された構成となっている。
なお、実施の形態１の方式と区別するため、実施の形態１の方式を配布イメージ方式、本実施の形態の方式を差分方式とする。
【００７５】
本実施の形態の差分方式は、中間サーバ２００に多数の端末３００がネットワークで接続されているが、帯域が狭く、なおかつ端末３００の台数が多いようなケースに適している。
ネットワークの制約によりネットワーク負荷をかけたくない場合は、オフライン用の配布メディアを用意し、手動で端末３００に１台ずつバージョンアップ作業を実施する方法もあるが、１台１台作業を行なう必要があり、このための手間や時間がかかってしまう問題がある。このような場合、本実施の形態の差分配布によるバージョンアップ方式にすれば、ネットワークに負荷をかけずにオンラインで効率的なバージョンアップデータの配布をすることができるといった効果が得られる。
【００７６】
以下、差分方式の詳細について説明する。
図１０は、本実施の形態における中間サーバ２００の処理手順を示したフローチャートである。図１０に従い、中間サーバ２００で行なうバージョンアップの処理手順について説明する。
ステップＳ１０以前の処理動作は、実施の形態１の図８と同様であるので、ここでは説明を省略する。
まず、ステップＳ１０では、配布イメージ方式での配布イメージ２００ｃに替えて、これを生成するために必要な差分情報２００ｂが、中間サーバ２００上に既に存在するか否か確認する。存在する場合は、これを再利用すればよいので、ステップＳ１６へ進む。
【００７７】
一方、差分情報２００ｂが存在しない場合は、配布サーバ１００上に差分情報２００ｂに相当する差分情報１００ｃが存在するか否か確認し、配布サーバ１００上に差分情報１００ｃが存在する場合は、配布サーバ１００から差分情報１００ｃを取得し、ステップＳ１６へ進む（図中せず）。配布サーバ１００にも差分情報１００ｃが存在しない場合は、ステップＳ１１へ進む。
ステップＳ１１では、中間サーバ２００上にバージョンアップする新版の配布イメージ２００ｃが存在するか否か確認する。存在する場合は、ステップＳ１５へ進む。一方、存在しない場合は、新版の配布イメージ２００ｃを生成する必要があることからステップＳ１２へ進む。
【００７８】
ステップＳ１２では、中間サーバ２００上に新版の配布イメージ２００ｃを生成するのに必要な差分情報２００ｂが存在するか確認する。存在する場合は、これを流用できるので、ステップＳ１４へ進む。一方、存在しない場合は、配布サーバ１００より差分情報１００ｃを取得する必要があるので、Ｓ１３に進む。
ステップＳ１３では、配布サーバ１００から、新版の配布イメージ２００ｃの生成に必要な差分情報１００ｃの取得を行なう。
【００７９】
次に、ステップＳ１４では、配布イメージ生成手段２０３が新版の配布イメージ２００ｃの生成を行なう。ここでの、新版の配布イメージ２００ｃの生成は、ステップＳ１２で中間サーバ２００上に既に存在することが確認された差分情報２００ｂ、あるいはステップＳ１３で新たに取得した差分情報２００ｂを、中間サーバ２００上にすでにある旧版の配布イメージ２００ｃに適用することで生成する。
なお、ここで行なう差分適用の方式は、実施の形態１で説明した配布イメージ生成手段２０３による方法と同様とする。
【００８０】
ステップＳ１５では、差分情報生成手段２０７が端末３００に配布する配布用差分情報２００ｂ’の生成を行なう。この配布用差分情報２００ｂ’の生成は、この時点で新版・旧版それぞれの配布イメージ２００ｃが揃ったことになっているため、両者のバージョン間でのバイナリ差分抽出を行い生成する。
なお、上記のステップＳ１５で生成した配布用差分情報２００ｂ’は、配布イメージ２００ｃと同様に、中間サーバ２００上に保持され、再利用することができる。
【００８１】
ステップＳ１６では、配布パッケージ生成手段２０５が各更新パターン別の端末３００向け配布パッケージ２００ｄ’の生成を行なう。構成詳細は後述するが、配布用パッケージ２００ｄと配布パッケージ２００ｄ‘の構成の違いは２点ある。
１点目は、配布用パッケージ２００ｄは必要コンポーネントの配布イメージ２００ｃを送付していたが、配布パッケージ２００ｄ’は配布イメージ２００ｃを配布用差分情報２００ｂ’に替えたもの、即ち差分情報配布パッケージとなっており、これにより後者は前者に比べ端末３００に送信する情報のサイズを大幅に削減する効果を得ることができる。
また、２点目は、インストールスクリプト中に、パッケージされている配布用差分情報２００ｂ’を、端末３００上の旧版配布イメージ２００ｃに適用して新版の配布イメージ２００ｃを生成する処理手順が追加された内容となっている。
ステップＳ１６で生成された配布パッケージ２００ｄ’は、配布パッケージ２００ｄ同様、対象となる端末の更新パターンに適合するものを選択し、端末３００に送付される。
【００８２】
次に、端末へ差分情報を配布するときの配布物の構成について説明する。
図１１は、配布パッケージ生成手段２０５によりステップＳ１６で生成された配布パッケージ２００ｄ’の構成図である。
まず、以下の手順で差分方式用の配布パッケージ２００ｄ’の生成を行なう。
（Ａ）各更新パターンに対し、必要な差分情報２００ｂ’によりソフトウェアを差分更新するためのインストールスクリプトを生成する。
（Ｂ）必要な差分更新用の差分情報２００ｂと上記（Ａ）で生成されたインストールスクリプトをパッケージした配布パッケージ２００ｄ’の生成を行なう。
なお、上記（Ａ）のインストールスクリプトは、実施の形態１のステップＳ８で説明したものと同様、更新パターン（インストールする配布イメージ２００ｃの組み合わせ）の数に応じて、生成する必要がある。
また、図７のバージョンアップ例の場合には、端末３００ａと端末３００ｂで異なる更新パターンとなるため、配布パッケージ２００ｄ’はこの２台の端末別に生成する必要がある。
【００８３】
配布パッケージ２００ｄ’を生成するにあたり、上記（Ａ）で生成するインストールスクリプトの内容は、実施の形態１のステップＳ８で生成したインストールスクリプトに以下の処理を追加したものとなっている。
即ち、新版の配布イメージ２００ｃをインストールする前に、この新版の配布イメージ２００ｃを端末上の旧版配布イメージ２００ｃと配布パッケージ２００ｄ’中の差分情報２００ｂ’から差分適用により生成するための差分適用処理が追加で記述されている。
なお、上記の差分適用処理は、差分適用プログラム（図示せず）を用意して行なうものとする。この差分適用プログラムの提供方法は、配布パッケージ２００ｄ’に添付する、あるいは事前に各端末３００上に配布して用意しておく、などにより行なうものとする。
【００８４】
次に、端末に差分情報を配布するケース１の方式について、図７のバージョンアップ例の場合を例に、図１０のフローチャートに従い説明する。
具体的には、中間サーバ２００に対し、端末３００ａ、端末３００ｂの２台の端末が同時にバージョンアップ要求を発行する場合の動作について説明する。
この場合、２台合わせて必要となる差分情報２００ｂ’は以下のとおりである。
（Ｘ）Ｃｏｍｐ１の８.１Ｂ→８.３Ｄ（端末３００ａ用）
（Ｙ）Ｃｏｍｐ１の８.２Ｃ→８.３Ｄ（端末３００ｂ用）
（Ｚ）Ｃｏｍｐ２の８.０Ａ→８.１Ｂ（端末３００ａ用）
次に、上記の（Ｘ）〜（Ｚ）について、それぞれ必要となる差分情報２００ｂを準備する手順について説明する。
ステップＳ１０〜ステップＳ１５の動作を、上記の（Ｘ）〜（Ｚ）の順で実行する場合について説明する。
【００８５】
まず、最初に実行する（Ｘ）の場合は、Ｃｏｍｐ１の８.３Ｄのバージョンアップを配下の端末３００で一度も実施していないため、中間サーバ２００上には差分情報２００ｂは存在しない。
ステップＳ１０では、差分情報取得手段２０２により、（Ｚ）の配布用差分情報２００ｂは存在しないと判定される。
ステップＳ１１では、差分情報取得手段２０２により、（Ｚ）を作成するための新版の８．３Ｄの配布イメージ２００ｃが存在するか否か確認され、ここでは存在しないと判定される。
ステップＳ１２では、差分情報取得手段２０２により、ステップＳ１１で存在しないと判定された新版の８．３Ｄの配布イメージ２００ｃを作成するのに必要となる差分情報８．２Ｃ→８．３Ｄの差分情報２００ｂが中間サーバ２００上に存在するか否か確認される。ここでは、過去に新版の８．３Ｄの配布イメージ２００ｃを生成した実績がないので、存在しないと判定される。
【００８６】
次に、ステップＳ１３では、差分情報取得手段２０２により、配信サーバ１００から、８．２Ｃ→８．３Ｄの差分情報１００ｃを取得する。
ステップＳ１４では、配布イメージ生成手段２０３により、新版の８．３Ｄの配布イメージ２００ｃ‘が生成される。新版の８．３Ｄの配布イメージ２００ｃ‘の生成は、ステップＳ１３で取得された差分情報を、既存の旧版８．２Ｃの配布イメージ２００ｃに適用することにより生成される。
ステップＳ１５では、差分情報生成手段２０６により、（Ｚ）の配布用差分情報２００ｂ’を、ステップＳ１４で作成された新版の配布イメージ２００ｃ‘と既存の旧版の配布イメージ２００ｃとにより生成される。
【００８７】
次に、２番目に実行する（Ｙ）の場合は、上記の（Ｘ）のステップＳ１３で配信サーバ１００から取得した８．２Ｃ→８．３Ｄの差分情報１００ｃを再利用する。
また、３番目に実行する（Ｚ）の場合は、既に過去に、端末３００ｂで８．０Ａ→８．１Ｂの更新が実行されているので、その差分情報２００ｂが中間サーバ２００上に残っており、これを再利用するものとする．
【００８８】
この結果、ステップＳ１６の配布パッケージ２００ｄ’の生成では、端末３００ａ用にパッケージする差分情報２００ｂ’は、Ｃｏｍｐ１用には上記で説明したように新たに中間サーバ上でローカルに生成したもの、Ｃｏｍｐ２用には既存のものを選択すればよい。また、端末３００ｂ用には、上記のステップＳ１３３で配布サーバ１００から取得したものを再利用することとして選択すればよい。
【００８９】
次に、上記のケース１で説明した方式とは違う端末に差分情報を配布するケース２の方式について説明する。
具体的には、例えば、端末３００ａ、端末３００ｂの２台の端末を、異なるタイミングで、この順序で、中間サーバ２００にバージョンアップ要求を発行する場合の動作について説明する。
まず、端末３００ａに必要な差分情報２００ｂは、上記の２台の端末が同時にバージョンアップ要求を発行する場合であるケース１の（Ｘ）、（Ｚ）であるとする。
また、上記のケース１と同様に、（Ｚ）は中間サーバ上に既にあるので再利用できる。
さらに、上記のケース１と同様に、（Ｘ）は中間サーバ２００上になく、また配布サーバ１００上にもない。
【００９０】
これより、上記のケース１と同様のステップＳ１０〜ステップＳ１４の手順にて、新版の８．３Ｄの配布イメージ２００ｃ‘を生成し、上記の２台の端末が同時にバージョンアップ要求を発行する場合と同様に端末３００ａ用の配布パッケージ２００ｄ’を生成すればよい。
また、端末３００ｂ用に必要な差分情報２００ｂは、上記のケース１の（Ｙ）であるため、上記と同様、中間サーバ２０上に存在するので、これを再利用すればよい。
さらに、配布パッケージ２００ｄ’も上記のケース１と同様に生成すればよい。
【００９１】
次に、上記のケース１、ケース２で説明した方式とは違う端末に差分情報を配布するケース３の方式について説明する。
例えば、端末３００ｂ、３００ａをこの順序で異なるタイミングで中間サーバ２００にバージョンアップ要求を発行する場合の動作について説明する。
まず、先の端末３００ｂで必要な差分情報２００ｂは、上記のケース１、２で説明したとおり、（Ｙ）である。
しかし、Ｃｏｍｐ１の８.３Ｄのバージョンアップの実績がないので、中間サーバ２００上には存在しない。また、Ｃｏｍｐ１の８.３Ｄにバージョンアップするための８.２Ｃ→８.３Ｄの差分情報２００ｂも存在しない。
この差分は、バージョンアップ１回分の差分であるので配布サーバ１００より取得する。
これにより、必要な配布用差分情報２００ｂが準備できたので、これをパッケージした配布パッケージ２００ｄ’を生成すればよい。
【００９２】
次に、端末３００ａ用であるが、必要な差分情報２００ｂは上記のケース１、２で説明したとおり（Ｘ）、（Ｚ）である。
（Ｚ）は上記のケース１、２と同様に、中間サーバ２００上に既にあるのでこれを再利用できる。
また、（Ｘ）は中間サーバ２００上にも、配布サーバ１００上にもない。このため、上記の２台同一の場合と同様にステップＳ１０〜ステップＳ１４の手順にて生成すればよい。ただし、このうちステップＳ１３で取得する８.２Ｃ→８.３Ｄの差分情報１００ｂは、先の端末３００ｂ用に中間サーバ上に取得すみであるので、ステップＳ１２からステップＳ１４へスキップする形となる。
以上のように、端末３００ａ用の配布パッケージ２００ｄ’は、先の同時のケースと同様、（Ｘ）と（Ｚ）をパッケージして生成すればよい。
【００９３】
なお、本発明では、実施の形態１で説明した配布イメージ配布方式と実施の形態２で説明した差分配布方式を併用しても良い。このようにすることにより、中間サーバ２００上に既に生成済みの配布イメージ２００ｃあるいは差分情報２００ｂ及び差分情報２００ｂ’を極力利用するような運用も可能であり、中間サーバ２００の負荷削減、配布サーバ１００との通信削減の効果を期待できる。
例えば、バージョンアップに必要な配布イメージ２００ｃがなくても、これを生成するための差分情報２００ｂがある場合は、差分方式の配布パッケージ２００ｄ’を生成、配布することが可能となる。
【００９４】
以上のように本実施の形態によれば、中間サーバ２００が、端末３００のソフトウェアバージョンアップのために必要な差分情報を端末３００に配布することにより、中間サーバ２００が端末３００のバージョンアップのために端末３００に配布する情報を最小限のアクセス及び最小限の情報量により効率よく行なうことできるので、ネットワークの負荷削減、ＣＰＵ／ディスク容量などのリソース節約、実行時間短縮といった効果を得ることができる。また、これにより、端末３００のソフトウェアのバージョンアップが短時間にでき、効率的な端末ソフトウェアのバージョンアップを実行することができる。
【図面の簡単な説明】
【００９５】
【図１】実施の形態１のソフトウェア２次配布システムの構成図。
【図２】実施の形態１において配布対象となるソフトウェアの構成と更新状況の説明図。
【図３】実施の形態１における配布サーバ１００の構成図。
【図４】実施の形態１における配布プログラム１００ｂの説明図。
【図５】実施の形態１における差分情報１００ｃの説明図。
【図６】実施の形態１における中間サーバ２００の構成図。
【図７】実施の形態１における端末のバージョンアップ例についての説明図。
【図８】実施の形態１における中間サーバ２００の処理手順を示したフローチャート。
【図９】実施の形態１における配布パッケージ２００ｄの構成図。
【図１０】実施の形態２における中間サーバ２００の処理手順を示したフローチャート。
【図１１】実施の形態２において配布パッケージ生成手段２０５により生成された配布パッケージ２００ｄ’の構成図。
【符号の説明】
【００９６】
１００  配布サーバ、１０１  構成情報管理手段、１０２  差分情報生成手段、２００  中間サーバ、２０１  バージョン確認手段、２０２  差分情報取得手段、２０３  配布イメージ生成手段、２０４  配布イメージ保持手段、２０５  配布パッケージ生成手段、  ２０６  配布パッケージ送信手段、２０７  差分情報生成手段、３００  端末。
【図１】
2006293512.tif 000003
【図２】
2006293512.tif 000004
【図３】
2006293512.tif 000005
【図４】
2006293512.tif 000006
【図５】
2006293512.tif 000007
【図６】
2006293512.tif 000008
【図７】
2006293512.tif 000009
【図８】
2006293512.tif 000010
【図９】
2006293512.tif 000011
【図１０】
2006293512.tif 000012
【図１１】
2006293512.tif 000013