JPH11219284A

JPH11219284A - バージョンアップ方法

Info

Publication number: JPH11219284A
Application number: JP10019402A
Authority: JP
Inventors: Yoshiaki Tanaka; 義昭田中
Original assignee: Sanyo Electric Co Ltd
Current assignee: Sanyo Electric Co Ltd
Priority date: 1998-01-30
Filing date: 1998-01-30
Publication date: 1999-08-10

Abstract

(57)【要約】【課題】サーバは、すべてのクライアントがバージョ
ンアップを終了するまで、現在保持するソフトウェアを
次のバージョンに更新することができない。【解決手段】クライアント／サーバ方式のＬＡＮシス
テムにおいて、クライアントが導入するソフトウェアの
バージョンアップデータを複数バージョンにわたってサ
ーバに保持し、そのバージョンアップデータをバージョ
ンの順に連結して管理すると共に、クライアントはサー
バに保持されたバージョンアップデータを参照して、自
クライアントのソフトウェアのバージョン以降のバージ
ョンに順次バージョンアップする構成である。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアント／サ
ーバ方式のＬＡＮシステム等において、クライアントの
ソフトウェアのバージョンアップデータをサーバ上で一
元的に管理して、クライアントソフトウェアのバージョ
ンアップを行う方法に関する。

【０００２】

【従来の技術】クライアント／サーバ方式のＬＡＮシス
テム等でクライアントのソフトウェアのバージョンアッ
プを行う場合、個々のクライアントが、バージョンアッ
プデータが記録されたＣＤ−ＲＯＭ等の記憶媒体からバ
ージョンアップデータを読み取って、バージョンアップ
を行っていた。しかし、この方法ではそれぞれのクライ
アントで人手を要するので、コストがかかる問題があっ
た。そこで、例えば、特開平９−２９２９８０号公報に
記載のファイル配布システムのように、サーバの記憶装
置にクライアントソフトの最新のバージョンアップデー
タを保持し、クライアントがそのデータを自動的にダウ
ンロードして、バージョンアップを行う方法が行われて
いる。

【０００３】

【発明が解決しようとする課題】このようなシステムで
は、クライアントのソフトウェアのバージョンアップが
個々のクライアントの責任において行われるので、サー
バに保持されたソフトウェアが最新のバージョンに更新
されていても、必ずしもすべてのクライアントが一時に
一斉にバージョンアップを行って、そのソフトウェアを
最新のバージョンに保っている保証はない。従って、サ
ーバは、すべてのクライアントがバージョンアップを終
了するまで、現在保持するソフトウェアを次のバージョ
ンに更新することはできない。

【０００４】また、それを防止するために、サーバが各
クライアントを監視してクライアントソフトのバージョ
ンアップを実施する方法もあるが、この方法は前記公報
の従来技術にも記載されている通り、サーバの負荷が大
きいという問題がある。従って、頻繁にバージョンアッ
プを行う必要があるシステムでは、最新バージョンのみ
をサーバに保持する従来の方法ではうまく機能しない問
題がある。

【０００５】ところで、ソフトウェアのバージョンアッ
プを行う場合、そのソフトウェア全体をそっくり新しい
ものに入れ替える方法もあるが、他の方法として、その
ソフトウェアを構成する一部のプログラムファイルやデ
ータファイルだけを更新する、部分的なバージョンアッ
プも多用される。複数のプログラムファイルによって構
成されたソフトウェアのうち、ある機能を受け持つプロ
グラムだけを更新したり、ソフトウェア内部で参照する
テーブルのデータだけを更新するのがそれである。こう
することでバージョンアップにかかる時間も費用も節約
できるものである。これら更新部分は、ソフトウェア全
体から見ると新バージョンと旧バージョンとの差に相当
するので、差分ファイルや差分データとも呼んでいる。

【０００６】例えば、病院の会計処理を行うソフトウェ
アでは、患者が受けた行為を入力してその診療報酬額や
患者への請求額を算定する。その際、薬価の合計を計算
するために処方薬の単価を記憶した薬価テーブルを参照
する。また、ある種の診療行為については組み合わされ
る条件によって報酬額が変わってくるので、それを判定
するプログラムが実行される。そして、これら薬価や組
み合わせの条件は法令の改正に伴い変更され得るので、
その時は、薬価テーブルを記憶したデータファイルだ
け、あるいは、該当の判定プログラムが入ったプログラ
ムファイルだけを、バージョンアップデータとしてクラ
イアントに供給することが行われる。

【０００７】しかし、クライアントにおいて、現行バー
ジョンのソフトウェアで処理すべきデータが残っている
場合は、供給された新バージョンの差分ファイルをイン
ストールすることを控え、現行バージョンをそのままし
ばらく使い続けることもある。また、何らかの理由によ
ってバージョンアップを行わない、あるいは行えないク
ライアントもある。そして、その間にもさらに新しいバ
ージョンが出ることもあるが、この場合、２世代前のバ
ージョンを飛ばして最新のバージョンだけをインストー
ルすると不都合が生じる可能性がある。なぜなら、２世
代前のバージョンアップの内容が最新バージョンの差分
ファイルに反映されていない可能性があるからである。
これが差分ファイルの意味であり、歴代の差分ファイル
を順番にインストールすること、即ちすべてのバージョ
ンでバージョンアップ作業をすることが必要である。そ
して、このような複数のバージョンアップデータを混在
させて管理できる手法が求められていた。

【０００８】

【課題を解決するための手段】本発明は、クライアント
／サーバ方式のＬＡＮシステムにおいて、クライアント
が導入するソフトウェアのバージョンアップデータを複
数バージョンにわたってサーバに保持し、そのバージョ
ンアップデータをバージョンの順に連結して管理すると
共に、クライアントはサーバに保持されたバージョンア
ップデータを参照して、自クライアントのソフトウェア
のバージョン以降のバージョンに順次バージョンアップ
することで、上記課題を解決するものである。

【０００９】

【実施例】図７は、本発明に係るバージョンアップ方法
を実施するクライアント／サーバ方式ＬＡＮシステムの
概略構成を示している。７１はサーバマシンであり、磁
気ディスク等の記憶装置72を持ち、また、ＣＤ−ＲＯＭ
ドライブ装置等の外付けの第２の記憶装置75を持ってい
る。記憶装置72には、サーバ固有のデータやプログラム
に加えて、さらにクライアントのバージョンアップデー
タを記憶するバージョンアップデータテーブル73と、ク
ライアント各々の現在のバージョンを管理するクライア
ント管理テーブル74とを記憶している。また、第２の記
憶装置75は外部からバージョンアップデータをサーバ内
に入力するために使われる。

【００１０】７６はクライアントマシンであり、サーバ
71と同様に磁気ディスク等の記憶装置77を内蔵してい
る。この記憶装置77にはクライアント上で動作するプロ
グラムやデータ等のソフトウェアが記憶されている。そ
して、必要に応じてＬＡＮ回線70を介してサーバ71のバ
ージョンアップデータを取込み、クライアントソフトウ
ェアのバージョンアップが行われる。１つまたは複数の
クライアント76がＬＡＮ回線70に接続可能であり、個々
のクライアント76それぞれが、独立にバージョンアップ
を適宜実施するものである。

【００１１】サーバ71に記憶されたクライアント管理テ
ーブル74の例を図５に示す。複数のクライアント76に固
有のクライアント番号51に対応付けて、現在それぞれの
クライアント76に導入されているクライアントソフトウ
ェアのバージョン情報52を記憶する。このクライアント
管理テーブル74はクライアント76から参照可能であり、
クライアント76は、バージョンアップを実施した時、ク
ライアント管理テーブル74の自分のバージョン情報52を
更新するものである。

【００１２】また、バージョンアップデータテーブル73
の例を図４に示す。テーブルの先頭にはリンク情報があ
り、後続するテーブルのアドレスを指す「次アドレス」
と、先行するテーブルのアドレスを指す「前アドレス」
が記憶される。これにより各バージョンアップデータが
バージョンの順にチェーンされる。そして、リンク情報
の後ろにバージョンアップデータの実体が記憶される。
但し、先頭のテーブルだけは特別で、リンク情報のみで
構成されている。

【００１３】同図（ａ）に示すように、先頭のテーブル
の次アドレスは「Ｂ」であり、一方前アドレスは、先行
するテーブルが存在しないので「終端」コードが記憶さ
れている。後続する２番目のテーブルでは、次アドレス
が３番目のテーブルのアドレス「Ｃ」であり、前アドレ
スは「Ａ」である。そして、バージョンアップデータの
実体として、バージョン番号等のバージョン情報と、プ
ログラムやデータ等のバージョンアップデータが記憶さ
れている。３番目のテーブルはこの例では末尾のテーブ
ルになり、これは即ち最新のバージョンアップデータで
ある。従って、次アドレスは「終端」である。前アドレ
スは先行する２番目のテーブルのアドレス「Ｂ」であ
る。

【００１４】クライアント76は、サーバ71の記憶装置72
にあるこのバージョンアップデータテーブル73を参照
し、リンク情報の中の次アドレスを追っていくことによ
って、サーバ71に格納されているすべてのバージョンア
ップデータのバージョン情報を確認することができ、所
望のバージョンをダウンロード可能である。

【００１５】次に、実施例の動作を説明する。先ず、バ
ージョンアップデータをサーバ71に格納する場合を図１
を参照して説明する。サーバ71は、バージョンアップデ
ータの格納が指示されると、バージョンアップデータテ
ーブル73のうち、先頭のテーブルをカレントテーブル、
即ち操作の対象テーブルに設定する（ステップS101）。
以下、テーブルの次アドレスや前アドレスと言うときに
は、カレントテーブルのそれを意味するものとする。そ
して、そのカレントテーブルの次アドレスが「終端」か
否かを判定する（同S102）。終端でなければ、後続する
テーブルをカレントテーブルに設定して（同S103）、再
びステップＳ１０２の判定を実施する。こうして次アド
レスが終端になるまでこの処理を繰り返し、最終的に末
尾のテーブルをカレントテーブルに設定する。

【００１６】次アドレスが終端であると判定されると、
カレントテーブルは末尾のバージョンアップデータ、即
ち最新のバージョンであるということである。そこでサ
ーバ71は、新バージョンのバージョンアップデータを第
２の記憶装置75から内部の記憶装置72にコピーしておい
て（同S104）、カレントテーブルの次アドレスにはコピ
ーした新バージョンのアドレスを記憶し（同S105）、新
バージョンの前アドレスにはカレントテーブルのアドレ
スを記憶し（同S106）、そして、新バージョンの次アド
レスには終端コードを記憶する（同S107）。このように
して、コピーした新バージョンのバージョンアップデー
タを、バージョンアップデータテーブル73の末尾に連結
するのである。

【００１７】図４（ｂ）は、同図（ａ）の状態に新バー
ジョンが追加された様子を示している。同図（ａ）にお
いて末尾にあったテーブル、即ちカレントテーブルの次
アドレスには最新バージョンのアドレス「Ｄ」が記憶さ
れ、最新バージョンの前アドレスにはアドレス「Ｃ」、
同次アドレスには「終端」が記憶されている。

【００１８】次に、クライアント76がバージョンアップ
を実施する場合を図２を参照して説明する。クライアン
ト76は、サーバ71のバージョンアップデータテーブル73
を参照し、先頭テーブルをカレントテーブルに設定して
（ステップS201）、その次アドレスが終端かどうか判定
する（同S202）。終端でなければ、後続のテーブルをカ
レントテーブルに設定しておいて（同S203）、カレント
テーブルのバージョン情報と自身のクライアントソフト
ウェアのバージョンとを比較し（同S204）、バージョン
アップが必要か否かを判定する。具体的には、カレント
テーブルのバージョンがクライアント自身のそれより新
しいか否かを判定して、新しければバージョンアップが
必要と判定する。バージョンアップが必要な場合は、ク
ライアント76はサーバ71から該当するバージョンアップ
データ、即ちカレントテーブルに記憶されているバージ
ョンアップデータの実体データをダウンロードし、バー
ジョンアップを実施する（同S205）。そして今度は、サ
ーバ71のクライアント管理テーブル74を参照し、自身の
クライアント番号に対応するバージョン情報52を、バー
ジョンアップしたバージョンに更新する（同S206）。つ
まり、クライアント管理テーブル74の該当箇所に、カレ
ントテーブルのバージョン情報を記録するのである。そ
の後、ステップＳ２０２に復帰する。

【００１９】一方、ステップＳ２０４において、カレン
トテーブルのバージョンがクライアント自身のそれより
古い場合は、バージョンアップが不必要と判定してステ
ップＳ２０２に直接復帰する。そして、次アドレス＝終
端となって後続するテーブルが無くなったら処理を終了
する。

【００２０】このように、サーバ71の記憶装置72上に連
結して格納されているバージョンアップデータのバージ
ョンを先頭から順に参照し、クライアント自身のバージ
ョンより新しいものが見つかる度にバージョンアップを
繰り返すのである。

【００２１】バージョンアップデータはバージョンの古
いものから順に新しいものが後ろに連結され、末尾に最
新のバージョンアップデータがある。クライアント76
は、サーバ71にある最も古いバージョンのバージョンア
ップデータから開始して、１つ１つ自身のバージョンと
比較してそれらが古い間は無視し、自身のバージョンよ
り新しいものが現れてからは、最新のバージョンに到る
まで全世代のバージョンにわたって、それらバージョン
アップデータを使って順にバージョンアップを実施する
のである。その結果、２世代以上遅れてバージョンアッ
プする場合にも、最新バージョンに含まれない旧世代の
差分データをも漏れなく取込んでバージョンアップでき
るものである。

【００２２】次に、不要になったバージョンアップデー
タを削除する場合を図３を参照して説明する。サーバ71
は先ず、バージョンアップデータテーブル73の先頭テー
ブルをカレントテーブルに設定する（ステップS301）。
そして、次アドレスが終端か否か判定する（同S302）。
終端でなければ、後続するテーブルをカレントテーブル
に設定し、その次アドレスと前アドレスを別途記憶して
おく（同S303）。次にカレントテーブルのバージョン情
報と、クライアント管理テーブル74に記憶されている全
クライアントのバージョン情報52とを比較し（同S30
4）、いずれのクライアント76もカレントテーブルのバ
ージョンに既にバージョンアップ済みであるか判定す
る。ここでは、クライアント76のバージョンがカレント
テーブルのそれより新しいか同じである場合は、カレン
トテーブルのバージョンに既に更新済みであると判定す
るのである。

【００２３】そこで、更新済みの場合には、カレントテ
ーブルであるバージョンアップデータを削除し（同S30
5）、別途記憶しておいたカレントテーブルの次アドレ
スを先行するテーブルの次アドレスに記憶する（同S30
6）。そして、その次アドレスが終端か否か判定し（同S
307）、終端でなければ、記憶してあるカレントテーブ
ルの前アドレスを後続するテーブルの前アドレスに記憶
する（同S305）。その後、ステップＳ３０２に復帰す
る。尚、末尾のテーブル即ち最新のバージョンアップデ
ータを削除したときは、後続のテーブルは存在しないの
で、ステップＳ３０７から同Ｓ３０２に復帰するように
している。

【００２４】他方、ステップＳ３０４において、１つで
も未更新のクライアント76があると判定すると、直接ス
テップＳ３０２に復帰する。こうして次アドレスが終端
になるまでこの処理を繰り返し、バージョンの古いもの
から順に、全クライアントでバージョンアップが済んで
いるバージョンアップデータを、サーバ71から削除して
いくのである。そして、次アドレス＝終端となったとこ
ろで処理を終了する。

【００２５】尚、ステップＳ３０４で未更新ありと判定
したとき、ステップＳ３０２に復帰せずに、その時点で
処理を終了してもよい。バージョンアップデータはバー
ジョンの古い順に連結されていて、しかも、クライアン
ト76は途中のバージョンを飛ばしてバージョンアップを
することはない。従って、クライアントが未だ導入して
いないバージョンがあれば、それ以降のバージョンも同
じくクライアントが未導入であると判定して差し支えな
いからである。そして、さらに、この古いバージョンの
削除処理は、先に述べた新しいバージョンのサーバ71へ
の格納処理と同期する必要はない。また、クライアント
76のバージョンアップ処理とも同期の必要はなく、サー
バ71の都合のよい時に任意に実施できるものである。

【００２６】ところで、本実施例では、図４に示したよ
うに、バージョンアップデータをテーブル先頭に付加し
たリンク情報で連結して管理しているが、この方法に限
るものではない。図６にバージョンアップデータテーブ
ルの別の実施例を示す。バージョンアップデータテーブ
ル60は、古いものから順にバージョン番号62と、そのバ
ージョンのバージョンアップデータの実体が記憶されて
いるアドレス63とを対にして記憶する。テーブルのレコ
ード番号61から分かるように、この例では現在サーバ71
にｎ個のバージョンアップデータが保持されている。
尚、このレコード番号61は、図５に示すクライアント管
理テーブル74のクライアント番号51とは何の関係も無
い。

【００２７】そして、クライアント76は、サーバ71にあ
るこのバージョンアップデータテーブル60を参照し、先
頭レコードのバージョン番号62と自身のクライアントソ
フトウェアのバージョンとを比較して、バージョンアッ
プが必要か否かを判定する。具体的には、レコードに記
憶されたバージョン62がクライアント自身のそれより新
しいか否かを判定して、新しければバージョンアップが
必要と判定する。バージョンアップ要の場合は、対応す
るアドレス63を参照してバージョンアップデータの実体
データをダウンロードし、バージョンアップを実施す
る。そして次に、サーバ71のクライアント管理テーブル
74を参照し、自身のクライアント番号51に対応するバー
ジョン情報52を、バージョンアップ後のバージョンに更
新する。つまり、クライアント管理テーブル74の該当箇
所に、導入したバージョン番号を記録するのである。ク
ライアント76はこの処理をすべてのレコードにわたって
順に実施し、クライアント自身のバージョンより新しい
ものが見つかる度に、バージョンアップを繰り返せばよ
い。

【００２８】一方、不要になった古いバージョンアップ
データを削除するときサーバは、バージョンアップデー
タテーブル60の先頭レコードから順に、そこに記録され
ているバージョン番号62と、クライアント管理テーブル
74に記憶されている全クライアントのバージョン情報52
とを比較して、どのクライアント76もそのバージョンに
既にバージョンアップ済みであるか否か判定する。そし
て、バージョンアップ済みであるときは、当該レコード
のアドレス63を参照して、そのバージョン番号62に対応
するバージョンアップデータの実体を削除すると共に、
当該レコードも削除する。その後、後続のレコードのレ
コード番号61を付け替えておいて、以降のレコードに対
しても同様の処理を繰り返せばよい。

【００２９】ところで、クライアントにおけるバージョ
ンアップ処理は、サーバとの関係においても、またクラ
イアント相互の関係においても全く独立に実施できるも
のである。即ち、サーバにおける新バージョンの格納処
理、及び古いバージョンの削除処理と、クライアントの
バージョンアップ処理とは同期をとる必要はなく、それ
ぞれ任意に実施してよい。また、クライアント相互にお
いても同期を取ってバージョンアップ処理を行う必要は
ない。個々のクライアントが任意に実施すればよいもの
である。

【００３０】

【発明の効果】本発明によれば、複数のバージョンのク
ライアントソフトをそのバージョンの順に連結してサー
バに保持することができる。その為、クライアントはそ
れぞれに必要なバージョンを容易に探すことができ、所
望のバージョンデータを任意にダウンロードしてバージ
ョンアップができる。そして、クライアントは相互に独
立にバージョンアップができるので、ＬＡＮで結ばれた
クライアント／サーバシステムの内部に、クライアント
ソフトの複数バージョンの混在を許容する事ができる。
また、サーバは古いバージョンのクライアントソフトの
バージョンアップデータを、クライアントのバージョン
アップ処理とは非同期に削除できるようになる。さら
に、バージョンアップデータが差分データで構成されて
いても、クライアントはバージョンの古い順に１つ１つ
バージョンアップ処理するので、漏れなく正しく最新バ
ージョンに移行できる。

【図面の簡単な説明】

【図１】実施例におけるサーバへの新バージョンの格納
手順を示すである。

【図２】実施例におけるクライアントのバージョンアッ
プ処理の手順を示す図である。

【図３】実施例におけるサーバから旧バージョンを削除
する手順を示す図である。

【図４】実施例のバージョンアップデータテーブルを示
す図である。

【図５】実施例のクライアント管理テーブルを示す図で
ある。

【図６】バージョンアップデータテーブルの別の実施例
を示す図である。

【図７】実施例のクライアント／サーバシステムの構成
を示すブロック図である。

【符号の説明】

７０ＬＡＮ回線７１サーバ７２記憶
装置７３バージョンアップデータテーブル７４クライアント管理テーブル７６クライアント７７記憶装置

Claims

【特許請求の範囲】

【請求項１】クライアント／サーバ方式のＬＡＮシス
テムにおいて、クライアントが導入するソフトウェアの
バージョンアップデータを複数バージョンにわたってサ
ーバに保持し、そのバージョンアップデータをバージョ
ンの順に連結して管理することを特徴とするバージョン
アップ方法。
【請求項２】クライアント／サーバ方式のＬＡＮシス
テムにおいて、クライアントが導入するソフトウェアの
バージョンアップデータを複数バージョンにわたってサ
ーバに保持し、そのバージョンアップデータをバージョ
ンの順に連結して管理すると共に、クライアントはサー
バに保持されたバージョンアップデータを参照して、自
クライアントのソフトウェアのバージョン以降のバージ
ョンに順次バージョンアップすることを特徴とするバー
ジョンアップ方法。
【請求項３】クライアント／サーバ方式のＬＡＮシス
テムにおいて、クライアントが導入するソフトウェアの
バージョンアップデータを複数バージョンにわたってサ
ーバに保持し、そのバージョンアップデータをバージョ
ンの順に連結して管理すると共に、クライアントが導入
したソフトウェアのバージョン情報をサーバに保持する
ようになし、サーバはそのバージョン情報を参照してク
ライアントがバージョンアップを終了したバージョンア
ップデータを削除することを特徴とするバージョンアッ
プ方法。
【請求項４】クライアントは、サーバが保持するクラ
イアントが導入したソフトウェアのバージョン情報を、
バージョンアップ後の自クライアントのソフトウェアの
バージョンに変更することを特徴とする請求項２または
３に記載のバージョンアップ方法。
【請求項５】サーバはバージョンアップデータを管理
する際に、バージョンアップデータのバージョン情報
と、バージョンアップデータの実体と、バージョン順の
リンク情報とをテーブルに記憶して管理することを特徴
とする１乃至４のいずれかに記載のバージョンアップ方
法。
【請求項６】クライアント／サーバ方式のＬＡＮシス
テムにおいて、クライアントが導入するソフトウェアの
バージョンアップデータを複数バージョンにわたってサ
ーバに保持し、そのバージョンアップデータをバージョ
ンの順に連結して管理すると共に、クライアントが導入
したソフトウェアのバージョン情報をサーバに保持する
ようになし、クライアントはバージョンアップを行うと
き、ａ．サーバに保持されたバージョンアップデータを参照
して最も古いバージョンのバージョンアップデータを対
象とし、ｂ．対象のバージョンアップデータのバージョンと自ク
ライアントソフトのバージョンとを比較し、ｃ．自クライアントソフトのバージョンが古い場合に、
対象のバージョンアップデータをサーバから取り込んで
バージョンアップを行い、ｄ．サーバが保持するバージョン情報を、前ステップで
導入したバージョンアップデータのバージョンに変更
し、ｅ．後続するバージョンのバージョンアップデータを新
たな対象とし、ｆ．ステップｂに復帰して処理を繰り返す、ステップを
有することを特徴とするバージョンアップ方法。
【請求項７】クライアント／サーバ方式のＬＡＮシス
テムにおいて、クライアントが導入するソフトウェアの
バージョンアップデータを複数バージョンにわたってサ
ーバに保持し、そのバージョンアップデータをバージョ
ンの順に連結して管理すると共に、クライアントが導入
したソフトウェアのバージョン情報をサーバに保持する
ようになし、サーバはバージョンアップデータの削除を
行うとき、ａ．最も古いバージョンのバージョンアップデータを対
象とし、ｂ．対象のバージョンアップデータのバージョンと、サ
ーバが保持するクライアントが導入したソフトウェアの
バージョン情報とを比較し、ｃ．すべてのクライアントがそのバージョンに更新済み
のとき、対象のバージョンアップデータを削除し、ｄ．後続するバージョンのバージョンアップデータを新
たな対象とし、ｅ．ステップｂに復帰して処理を繰り返す、ステップを
有することを特徴とするバージョンアップ方法。