JP2009157732A - プログラムの配信サーバ、配信システム、配信方法、および、配信対象プログラム - Google Patents

Abstract

【課題】プログラムのバージョンアップに伴う試行の手間を低減すること。
【解決手段】配信サーバ２は、所定端末１に対して既に配信されている配信対象プログラムのバージョン情報と、記憶装置に記憶されている最新版の配信対象プログラムのバージョン情報と、を照合することで、配信が必要か否かを判定し、配信が必要と判定されたとき、最新版の配信対象プログラムの試行履歴データを参照し、所定台数以上の端末１が既に試行を成功している旨の試行要否条件を満たすか否かを判定し、試行要否条件を満たすときには、配信する最新版の配信対象プログラムに対して、試行せずに運用する旨を所定端末１に通知する。
【選択図】図１

Description

本発明は、プログラムの配信サーバ、配信システム、配信方法、および、配信対象プログラムに関する。

コンピュータにインストールされ、実行されるプログラムは、機能の追加や、セキュリティのための修正などの理由により、バージョンアップが行われる。最新のバージョンアップの結果が反映された最新版のプログラムは、プログラムの配信サーバからプログラムがインストールされる端末へと配信される。

ユーザは、プログラムのバージョンアップがなされたことを配信サーバに対して毎回確認する作業を、面倒と感じることもある。そこで、特許文献１には、起動時にプログラムのバージョンを自動で確認し、常に最新版をダウンロードする技術が、開示されている。
特開平９−２９２９８０号公報

多くの場合、プログラムのバージョンアップは、プログラムの供給元であるベンダが、プログラムのユーザにとって利益があると考えられる修正を行うことで実現される。しかし、プログラムのバージョンアップが、ユーザにとって不利益となってしまうケースが発生する。以下、不利益となる事例を列挙する。

例えば、バージョンアップにより、プログラムが扱うデータ形式が変更されたため、データの互換性が無くなってしまった場合であって、ユーザは既に旧形式のデータを多く保持しており、今後も旧形式のデータを使い続けたいと思っている場合である。

別の例では、バージョンアップにより、プログラムが動作するＯＳ（Operating System）が新しいＯＳに変更された場合である。新しいＯＳは、古いＯＳと比較すると、同じ機能を実現するために消費するメモリ量などが増大してしまうので、新しいＯＳ上でのプログラムの動作は、実行時間が長くかかってしまうなどの性能劣化が発生する。

そこで、ユーザは、最新版のプログラムを無条件に受け入れてしまうのではなく、最新版のプログラムを一時的に試行し、ユーザの要求が満たされていることを確認してから、その最新版のプログラムを運用する。つまり、試行とは、各プログラムを用いて行う業務が一通り実行できるか否かを点検する作業を指す。業務は１つ以上の業務シナリオに細分化され、業務シナリオごとにプログラムが試行される。しかし、運用前の試行期間を設けることは、最新版のプログラムの導入を遅らせる上、試行のためのインストール、運用のためのインストールと、２度手間をユーザに強いてしまい、不便である。

そこで、本発明は、前記した問題を解決し、プログラムのバージョンアップに伴う試行の手間を低減することを主な目的とする。

前記課題を解決するため、本発明は、配信対象プログラムを実行する端末に対して、最新版の前記配信対象プログラムを配信する配信サーバであって、
前記配信サーバが、
前記最新版の配信対象プログラムについて、そのバージョン情報と、１台以上の前記端末による試行履歴データと、を対応づけて記憶装置に記憶し、
所定端末から前記配信対象プログラムの更新チェック依頼を受信すると、
前記所定端末に対して既に配信されている前記配信対象プログラムの前記バージョン情報と、前記記憶装置に記憶されている前記最新版の配信対象プログラムの前記バージョン情報と、を照合することで、配信が必要か否かを判定し、
配信が必要と判定されたとき、前記最新版の配信対象プログラムの前記試行履歴データを参照し、所定台数以上の端末が既に試行を成功している旨の試行要否条件を満たすか否かを判定し、
前記試行要否条件を満たすときには、配信する前記最新版の配信対象プログラムに対して、試行せずに運用する旨を前記所定端末に通知するとともに、前記試行要否条件を満たさないときには、配信する前記最新版の配信対象プログラムに対して、試行を要する旨を前記所定端末に通知することを特徴とする。
その他の手段は、後記する。

本発明によれば、プログラムのバージョンアップに伴う試行の手間を低減することが可能になった。

以下に、本発明が適用されるプログラム配信システムの一実施形態について、図面を参照して詳細に説明する。

図１は、プログラム配信システムを示す構成図である。プログラム配信システムは、配信対象プログラム（以下、単にプログラムとする）を実行する１台以上の端末１と、プログラムを端末１へと配信する配信サーバ２とがネットワーク９で接続されて構成される。端末１には、それぞれ他の端末１と区別するための端末ＩＤが割り当てられている。なお、図１では３台の端末１（Ｔ１，Ｔ２，Ｔ３）のうち、Ｔ３の端末１の内部構成を示しているが、他の端末１（Ｔ１，Ｔ２）の内部構成も同様であるため、図示を省略している。

なお、プログラム配信システムにおける端末１は、例えば、金融機関などの自動取引装置や無人契約機などに応用が可能である。そのときには、端末１のユーザは、金融機関に勤務するオペレータでもよいし、金融機関に口座を有する取引者でもよい。

プログラム配信システムを構成する各装置（端末１および配信サーバ２）は、それぞれ演算処理を行う際に用いられる記憶手段としてのメモリと、前記演算処理を行う演算処理装置とを少なくとも備えるコンピュータとして構成される。なお、メモリは、ＲＡＭ（Random Access Memory）などにより構成される。演算処理は、ＣＰＵ（Central Processing Unit）によって構成される演算処理装置が、メモリ上の配信動作プログラムを実行することで、実現される。

端末１は、記憶装置１０、端末制御部１８、通信装置１９ａ、入力装置１９ｂ、表示装置１９ｃを備える。
記憶装置１０は、メモリやハードディスクなどの記憶手段により構成される。記憶装置１０には、試行判定条件管理部１１、試行判定管理部１２、試行記憶部１３ａのプログラム、および、運用記憶部１３ｂのプログラムが記憶される。これらの各データの詳細は、後記する。
端末制御部１８は、演算処理を行う演算処理装置であり、端末１の各処理を制御する。
通信装置１９ａは、ネットワーク９へ接続するための通信用のインタフェースである。
入力装置１９ｂは、マウスやキーボードなどの入力手段により構成され、ユーザからインストールの許可指示などのデータの入力を受け付ける。
表示装置１９ｃは、ディスプレイなどにより構成され、ユーザに通知メッセージなどのデータを提示する。

配信サーバ２は、記憶装置２０、サーバ制御部２８、通信装置２９ａ、入力装置２９ｂ、表示装置２９ｃを備える。
記憶装置２０は、メモリやハードディスクなどの記憶手段により構成される。記憶装置２０には、プログラム更新ＤＢ２１、端末状態ＤＢ２２、試行履歴ＤＢ２３、リポジトリ２４が記憶される。これらの各データの詳細は、後記する。
サーバ制御部２８は、演算処理を行う演算処理装置であり、配信サーバ２の各処理を制御する。
通信装置２９ａは、ネットワーク９へ接続するための通信用のインタフェースである。
入力装置２９ｂは、マウスやキーボードなどの入力手段により構成され、管理者から最新版プログラムの登録などのデータの入力を受け付ける。
表示装置２９ｃは、ディスプレイなどにより構成され、管理者にプログラムの各端末１への配信度合いなどのデータを提示する。

表１に示す試行判定条件管理部１１は、業務と、業務シナリオと、プログラムと、試行判定条件と、を対応づけて管理する。
「業務」は、１つ以上の「業務シナリオ」により構成される。
「プログラム」は、対応する「業務シナリオ」を実施するために実行されるプログラムのＩＤを格納する。
「試行判定条件」は、「プログラム」で示されたプログラムの実行結果をもとに、その実行が「業務シナリオ」への試行として成功しているのか（試行ＯＫ）、失敗してしまったのか（試行ＮＧ）を判定するための条件である。

例えば、業務（Ｂ１）の業務シナリオ（Ｂ１ａ）は、プログラム（Ｐ１）および試行判定条件（正常動作）と対応づけられている。この対応付けは、業務（Ｂ１）の業務シナリオ（Ｂ１ａ）を実施するためには、プログラム（Ｐ１）を実行する必要があり、その実行結果が「正常動作」であれば、試行ＯＫである旨を示す。

なお、試行判定条件の「正常動作」とは、プログラムの実行内容に異常が発生しない旨を示す。例えば、プログラムが実行中に暴走してしまった場合や、プログラムが所定の業務データの読み込みに失敗してしまった場合には、プログラムが正常動作しないこととする。「正常動作」の確認方法としては、例えば、プログラムをシミュレータ上で動作させることによりプログラムの暴走を検知する方法が挙げられる。または、正しい入力データおよび出力データの組を学習データとして記憶装置１０に記憶させた後、学習データの入力データをプログラムに入力して実行させた結果、学習データの出力データと同じデータが出力されたときに、「正常動作」とする方法が挙げられる。

また、試行判定条件の「実行時間＜１分」とは、プログラムの実行時間（実行に要する時間）が１分未満であるときに試行判定条件を満たす旨を示す。なお、プログラムの実行時間を検知する方法として、例えば、プログラムの実行を監視するプロファイラが、プログラムの実行時間を計測する手法がある。

ここで、業務（Ｂ３）は、その業務シナリオ（Ｂ３ａ）を実施するために実行されるプログラム（Ｐ１）と、その業務シナリオ（Ｂ３ｂ）を実施するために実行されるプログラム（Ｐ２）と、が連動する一例である。そして、業務シナリオ（全部）に対応するレコードは、全部の業務シナリオの実行結果をもとに、試行判定が行われることを示す。つまり、業務（Ｂ３）全体として各プログラムが連動して正常に動作し、かつ、実行時間の合計が１０分未満であるときに、試行ＯＫと判定される。

表２に示す試行判定管理部１２は、業務と、業務シナリオと、プログラムと、ver.と、試行履歴と、試行判定と、を対応づけて管理する。
「業務、業務シナリオ、プログラム」は、試行判定条件管理部１１のものと同じ意味である。
「ver.」は、対応するプログラムのバージョン番号を示す。
「試行履歴」は、対応するプログラムの「ver.」で示されるバージョンを試行した結果を示す。
「試行判定」は、対応する「試行履歴」が試行判定条件管理部１１の「試行判定条件」を満たすか（試行ＯＫ）、満たさないか（試行ＮＧ）を示す。

例えば、プログラム（Ｐ１）のバージョン（１．２）は、２つの業務シナリオ（Ｂ１ｃ、Ｂ２ｃ）でそれぞれ試行されている。このプログラムの実行時間が３分であるとき、試行判定条件管理部１１を参照すると、業務シナリオ（Ｂ１ｃ）の試行判定条件（正常動作のみで実行時間に関する条件は存在しない）を満たすが、業務シナリオ（Ｂ２ｃ）の試行判定条件（実行時間が１分未満）を満たさない。よって、同じ「試行履歴」である「実行時間＝３分」であっても、緩い試行判定条件が設定されている業務シナリオ（Ｂ１ｃ）では「試行ＯＫ」となり、厳しい試行判定条件が設定されている業務シナリオ（Ｂ２ｃ）では「試行ＮＧ」となる。

試行記憶部１３ａ、および、運用記憶部１３ｂは、それぞれ更新対象として受信したプログラムのインストール先となる記憶部である。試行記憶部１３ａには、試行のためのプログラムが一時的（試行期間中）にインストールされる。運用記憶部１３ｂには、運用のためのプログラムがインストールされる。

なお、試行記憶部１３ａにプログラムをインストールするときには、インストールされたプログラムが一時的に実行されるという特性を活かした技術を、適宜採用してもよい。例えば、特開２００１−３３１２３０号公報には、プログラム本来の機能と、プログラムを一時的にインストールするための機能（試行プログラムの試行期間や動作環境の設定）とを分離し、後者の機能を環境制御用プログラムとして、配布する旨が記載されている。

表３に示すプログラム更新ＤＢ２１は、プログラムと、ver.と、重要度と、通知内容と、を対応づけて管理する。プログラム更新ＤＢ２１は、リポジトリ２４に反映されている最新版のプログラムを説明する情報を格納する。
「プログラム、ver.」は、試行判定管理部１２のものと同じ意味である。
「重要度」は、対応するプログラムの「ver.」で示されるバージョンについて、更新を行うか否かを判断する際の更新を行った方がいい度合いである。
「通知内容」は、対応するプログラムの「ver.」で示されるバージョンについて、更新時（試行開始時および運用開始時）に表示装置１９ｃを介してユーザに通知されるメッセージである。このメッセージは、更新により得られるメリットが、主な内容である。

表４に示す端末状態ＤＢ２２は、端末と、プログラムと、ver.と、状態と、更新日と、を対応づけて管理する。
「端末」は、対応するプログラムの「ver.」で示されるバージョンについて、試行または運用としてインストールされている端末１の端末ＩＤを示す。
「プログラム、ver.」は、プログラム更新ＤＢ２１のものと同じ意味である。
「状態」は、プログラムのインストールが、「試行」か「運用」かのいずれかを示す。
「更新日」には、プログラムのインストールが行われた日を記録する。この記録は、管理者がプログラムの各端末１への配信度合いを知るためのログとして、表示装置１９ｃに表示される。

表５に示す試行履歴ＤＢ２３は、プログラムと、ver.と、試行ＯＫの端末と、試行ＮＧの端末と、試行要否条件と、試行要否と、を対応づけて管理する。
「プログラム、ver.」は、端末状態ＤＢ２２のものと同じ意味である。
「試行ＯＫの端末」、「試行ＮＧの端末」は、対応する「プログラム、ver.」のプログラムを試行した結果、「試行ＯＫ」または、「試行ＮＧ」となった端末１の端末ＩＤを列挙したものである。
「試行要否条件」は、対応する「試行ＯＫの端末」、「試行ＮＧの端末」の試行結果をもとに、これから試行する必要があるか否かを判断するための条件である。
「試行要否」は、対応する「試行ＯＫの端末」、「試行ＮＧの端末」の試行結果を、対応する「試行要否条件」により判断した結果を示す。

例えば、プログラム（Ｐ１）のバージョン（１．２）は、「試行ＯＫの端末」が２台（Ｔ１，Ｔ２）存在するので、「試行要否条件」（試行ＯＫの端末が２台以上なら試行不要）を満たし、「試行要否」が「不要」となる。これにより、プログラム（Ｐ１）のバージョン（１．２）をまだ試行していない端末１（端末ＩＤ＝Ｔ３）は、他の端末１の試行結果により試行がうまくいっているので、自ら試行することをせず、迅速に運用することができる。

表６に示す試行履歴ＤＢ２３は、表５に示す試行履歴ＤＢ２３の別の一例である。表６は、表５と比較すると、列「業務」が追加されている。これにより、同じ「プログラム、ver.」の試行でも、「業務」が異なると、試行結果が異なることになる。例えば、表５のプログラム（Ｐ１）のバージョン（１．２）は、「試行ＯＫの端末」が２台（Ｔ１，Ｔ２）であるのに対し、表６の同じプログラムでは「試行ＯＫの端末」が１台ずつに分散されている。このように、列「業務」ごとに試行結果を分割することにより、自端末１の「業務」と他端末１の「業務」とが一致する試行結果に絞り込んで、他端末１の試行結果を活用することができる。つまり、「業務」ごとに試行結果を分割する理由は、表１の試行判定条件管理部１１で示したように、同じプログラムを試行するときに、「業務」ごとに多様な試行判定条件が設定されているからである。

リポジトリ２４は、ＣＶＳ（Concurrent Versions System）などのバージョン管理システムにおいて、バージョン毎にプログラムファイルを管理する記憶領域である。リポジトリ２４に対してプログラムをライト（書き込み）することをチェックイン、リード（読み込み）することをチェックアウトと呼ぶ。

図２は、プログラム配信システムの動作を示すフローチャートである。このフローチャートは、端末１が電源投入などにより起動されたとき、または、あらかじめ所定間隔で発生する定期的なイベントを契機に、実行が開始される。
なお、図２における端末１の各動作は、端末１のメモリ上に読み込まれた配信動作プログラムを実行することで、実現される。配信動作プログラムは、配信サーバ２から配信される配信対象プログラムとは別々のプログラムとしてもよいし、配信対象プログラムに組み込まれたプログラムとしてもよい。配信対象プログラムに組み込まれた配信動作プログラムは、配信対象プログラムの実行が指示されると、配信対象プログラムの各処理のうちの最初の処理として実行される。

なお、端末１側の前準備として、ユーザにより試行判定条件管理部１１の業務シナリオを実施するために実行されるプログラムを示す「業務、業務シナリオ、プログラム」の対応情報、および、業務シナリオごとの試行可否を判断するための「試行判定条件」が、入力されている。

また、配信サーバ２側の前準備として、管理者によりリポジトリ２４には最新版のプログラムがチェックインされるとともに、そのチェックインに関する情報が、プログラム更新ＤＢ２１の各列に登録される。

まず、端末１の端末制御部１８は、配信サーバ２のサーバ制御部２８に対して、プログラムの更新チェックを依頼する（Ｓ１１）。この依頼時に通信装置１９ａを介して送信される依頼メッセージには、少なくとも端末１の端末ＩＤが含まれる。さらに、依頼メッセージには、送信元の端末１にインストールされている更新チェック対象のプログラムＩＤとそのバージョンとの組を含めてもよい。

サーバ制御部２８は、受信した依頼メッセージをもとに、プログラムの更新チェックを実行する（Ｓ１２）。このＳ１２の処理の詳細は、後記する図３において詳説する。なお、更新チェックの対象となるプログラムは、以下に示すいずれかの手法により、特定される。
・受信した依頼メッセージで指定されるプログラムＩＤのプログラム。
・受信した端末ＩＤを検索キーとして端末状態ＤＢ２２を検索し、検索結果の各レコードの対応する「プログラム」列のプログラム。

そして、更新チェックの結果として、端末１に返信する通知メッセージが、以下の（１）〜（３）のいずれかとして特定される。
通知メッセージ（１）「更新不要」：現在の端末１が最新版を運用しているか否かにかかわらず、最新版へのプログラムの更新は不要である。
通知メッセージ（２）「更新必要」＆「試行不要」：現在の端末１は最新版を運用していないため、最新版へのプログラムの更新が必要である。ただし、その最新版のプログラムは、既に試行履歴において信頼性が保証されているので、今回は試行を不要（省略）として運用を開始する。
通知メッセージ（３）「更新必要」＆「試行必要」：現在の端末１は最新版を運用していないため、最新版へのプログラムの更新が必要である。そして、その最新版のプログラムは、信頼性が保証されていないので、今回は運用前に試行を必要とする。

サーバ制御部２８は、通知メッセージ（２）を作成したときには端末状態ＤＢ２２の「状態」に「運用」を、通知メッセージ（３）を作成したときには端末状態ＤＢ２２の「状態」に「試行」を、それぞれ書き込む。さらに、サーバ制御部２８は、端末状態ＤＢ２２の「端末」に依頼メッセージの送信元の端末ＩＤを、端末状態ＤＢ２２の「プログラム、ver.」にプログラム更新ＤＢ２１より取得した更新チェック対象のプログラムとそのバージョンを、端末状態ＤＢ２２の「更新日」にプログラムの配信日（Ｓ１３の実行日）を、それぞれ書き込む。

サーバ制御部２８は、Ｓ１２の処理により作成された通知メッセージと、更新対象の最新版のプログラムと、を端末１に送信する（Ｓ１３）。なお、通知メッセージが（１）「更新不要」の場合には、更新が不要なのでプログラムの送信を省略できる。

端末制御部１８は、Ｓ１３で受信した通知メッセージが「更新必要」でない（Ｓ１４，Ｎｏ）、つまり、（１）「更新不要」の場合には、処理を終了する。一方、通知メッセージが「更新必要」である（Ｓ１４，Ｙｅｓ）、つまり、（２）または（３）の場合には、処理をＳ１５に進める。

端末制御部１８は、Ｓ１３で受信した通知メッセージが「試行必要」でない（Ｓ１５，Ｎｏ）、つまり、（２）の場合には、Ｓ１３で受信した最新版のプログラムを試行せずに運用する（Ｓ２１）。具体的には、端末制御部１８は、最新版のプログラムを運用記憶部１３ｂにインストールしてから実行する。一方、通知メッセージが「試行必要」である（Ｓ１５，Ｙｅｓ）、つまり、（３）の場合には、処理をＳ１６に進める。

端末制御部１８は、Ｓ１３で受信した最新版のプログラムを試行記憶部１３ａにインストールしてから実行することで、プログラムを試行する（Ｓ１６）。そして、Ｓ１６の試行結果について、端末１の記憶装置１０に登録する（Ｓ１７）。具体的には、試行判定管理部１２の「試行履歴」に対して、Ｓ１６の試行結果を書き込み、試行判定管理部１２の「試行判定」に対して、書き込んだ「試行履歴」と試行判定条件管理部１１の「試行判定条件」との照合結果（試行ＯＫまたは試行ＮＧ）を書き込む。

さらに、端末制御部１８は、Ｓ１６の試行結果（プログラム、ver.、試行判定の対応情報）を配信サーバ２に通知して、記憶装置２０に登録させる（Ｓ１８）。具体的には、通知された試行判定に応じて、試行履歴ＤＢ２３の「試行ＯＫの端末」、または、「試行ＮＧの端末」のいずれかに、試行結果を通知した端末１の端末ＩＤを追加する。その結果、試行履歴ＤＢ２３の追加されたレコードについて、更新された「試行ＯＫの端末、試行ＮＧの端末」のデータと、対応する「試行要否条件」とを再評価し、対応する「試行要否」を更新する。

ここで、端末制御部１８は、Ｓ１６の試行結果について、Ｓ１７の「試行判定」で書き込んだ値が試行ＯＫなら（Ｓ１９，Ｙｅｓ）、その試行したプログラムを試行記憶部１３ａから運用記憶部１３ｂに移動してから実行することで、運用する（Ｓ２１）。ここで、プログラムの移動に伴い、サーバ制御部２８は、端末状態ＤＢ２２の「状態」を「試行」から「運用」に、「更新日」を運用の開始日に、それぞれ更新する。

一方、Ｓ１６の試行結果について、試行ＮＧなら（Ｓ１９，Ｎｏ）、その試行したプログラムをアンインストールすることで、プログラムを試行前に戻す（Ｓ２０）。ここで、Ｓ２０において、試行したプログラムに関するデータをＳ１２で端末状態ＤＢ２２に書き込んだため、試行したプログラムのアンインストールに伴い、端末状態ＤＢ２２をＳ１２で書き込む前の状態に書き戻す。

以上、図２の各処理について説明した。なお、プログラムの試行（Ｓ１６）および運用（Ｓ２１）前に、それぞれプログラム更新ＤＢ２１の「通知内容」に記載されている更新内容を示すメッセージを表示装置１９ｃに表示するとともに、入力装置１９ｂを介して、試行の許可をユーザに入力させることが望ましい。なお、更新内容を示すメッセージは、メッセージに併せて表示された確認ボタンを押すまでは、メッセージを画面上に表示し続けるようにするとよい。これにより、ユーザが重要事項を見逃すことを抑制できる。

図３は、プログラムの更新チェックの詳細を示すフローチャートである。このフローチャートは、図２のＳ１２から呼び出されて実行が開始されるサブルーチンであり、実行が終了すると図２のＳ１３に処理が戻る。

まず、サーバ制御部２８は、Ｓ１１でプログラムの更新チェックを依頼した端末１に、既にプログラム更新ＤＢ２１に登録されている最新版がインストールされているか、つまり、端末１が最新版を保持しているか否かを判定する（Ｓ１２１）。この判定は、以下に示すいずれかの手法により、実現される。
・受信した依頼メッセージに含まれている、送信元の端末１にインストールされている更新チェック対象のプログラムＩＤとそのバージョンとの組が、プログラム更新ＤＢ２１に登録されている組と一致するときに、最新版を保持していると判定する。
・更新チェックを依頼した端末１の端末ＩＤに対応する端末状態ＤＢ２２に格納されている「プログラムＩＤ、バージョン（ver.）」の組が、プログラム更新ＤＢ２１に登録されている組と一致するときに、最新版を保持していると判定する。

サーバ制御部２８は、最新版を保持しているときには（Ｓ１２１，Ｙｅｓ）、最新版のプログラムを繰り返し端末１に配信することは無駄になるので、通知メッセージ（１）「更新不要」に決定する（Ｓ１２４）。一方、最新版を保持していないとき（Ｓ１２１，Ｎｏ）には、試行履歴ＤＢ２３に記録されている試行履歴を参照する処理を実行する。ここで、プログラム更新ＤＢ２１の「重要度」が「緊急」であるときには、「更新必要」となる通知メッセージ（２）または（３）を選択するようにしてもよい。

次に、サーバ制御部２８は、Ｓ１１でプログラムの更新チェックを依頼した端末１が、過去にプログラム更新ＤＢ２１に登録されている最新版を試行した結果、つまり、自端末１の試行履歴の内容を判定する（Ｓ１２１）。この判定は、端末１の端末ＩＤが、試行履歴ＤＢ２３の更新対象のプログラムのレコードの「試行ＯＫの端末」または「試行ＮＧの端末」に存在するか否かを検索することにより、実現される。この判定により、最新版を保持していない端末１が過去に自端末１で試行ＮＧとなった最新版を受信してしまうことを防ぐことができる。

なお、試行履歴ＤＢ２３のレコードを特定する検索キーは、業務毎に分かれていない試行履歴ＤＢ２３（表５）では「プログラム、ver.」の組、業務毎に分かれている試行履歴ＤＢ２３（表６）では「業務、プログラム、ver.」の組、となる。これらの検索キーは、更新チェックの依頼メッセージまたは端末状態ＤＢ２２に登録されたデータから取得する。

サーバ制御部２８は、試行履歴が「試行ＯＫ」なら（Ｓ１２２，試行ＯＫ）、再度の試行は不要なので、通知メッセージ（２）「更新必要」＆「試行不要」に決定する（Ｓ１２５）。
サーバ制御部２８は、試行履歴が「試行ＮＧ」なら（Ｓ１２２，試行ＮＧ）、更新は不要なので、通知メッセージ（１）「更新不要」に決定する（Ｓ１２４）。
サーバ制御部２８は、試行履歴がないときには（Ｓ１２２，試行履歴なし）、処理をＳ１２３に進める。

サーバ制御部２８は、他端末１の試行履歴をもとに、通知メッセージを選択する（Ｓ１２３）。つまり、他端末１の試行履歴が反映された試行履歴ＤＢ２３の「試行要否」の内容により、分岐する。
サーバ制御部２８は、試行要否が「試行不要」なら（Ｓ１２３，試行不要）、他端末１の試行履歴によりプログラムの信頼性が保証されているので、通知メッセージ（２）「更新必要」＆「試行不要」に決定する（Ｓ１２５）。
サーバ制御部２８は、試行要否が「試行必要」なら（Ｓ１２３，試行必要）、他端末１の試行履歴が不充分なので、通知メッセージ（３）「更新必要」＆「試行必要」に決定する（Ｓ１２６）。そして、図３に示したルーチンが終了する。

以上、図３の各処理を説明した。この図３の処理により、通知メッセージ（１）〜（３）の中からいずれか１つのメッセージが選択される。

ここで、Ｓ１２３の分岐では、通知メッセージ（２）または（３）のいずれかが選択されることとした。しかし、試行履歴ＤＢ２３において多くの（例えば１０台以上の）端末１で「試行ＮＧ」となってしまった所定プログラムの所定バージョンは、今後も異常をきたすおそれがある。よって、そのような所定プログラムの所定バージョンは、通知メッセージ（１）を選択してもよい。さらに、そのような所定プログラムの所定バージョンをプログラム更新ＤＢ２１およびリポジトリ２４から削除するとともに、削除したプログラムを既に運用している端末１には削除前のバージョンのプログラムを配布しなおすようにしてもよい。

以下、図２の試行ＮＧ（Ｓ１９，Ｎｏ）であるときの、プログラムを試行前に戻す（Ｓ２０）処理について、試行が失敗した要因を解析することで、試行前に戻す処理を選択する例を説明する。

表７に示す試行判定管理部１２は、表２の試行判定管理部１２と比較すると、説明用の列（ケース）が追加されている。この４つのケースは、２つのプログラム「Ｐ１，Ｐ２」が連動する例である。各ケースにおいて、「業務、業務シナリオ、プログラム」の値は、互いに同じ値である。

ケース（１）は、２つのプログラムがともにバージョンアップする前を示す。表７のプログラムの「試行履歴」と、表１の試行判定条件管理部１１の「試行判定条件」とを比較すると、プログラム「Ｐ１」の実行時間＝３分＜８分、かつ、プログラム「Ｐ２」の実行時間＝５分＜８分、かつ、プログラムの実行時間の合計＝８分＜１０分なので、すべて試行ＯＫである。

残りのケース（２）からケース（４）までは、ともに、プログラム「Ｐ２」のバージョンはそのまま（１．０）で、プログラム「Ｐ１」のバージョンが１．１から１．２にバージョンアップした例である。

ケース（２）は、最新版プログラム「Ｐ１」が試行ＯＫ、かつ、連動するプログラム「Ｐ２」が試行ＮＧである例である。このときには、端末制御部１８は、プログラム「Ｐ１」のバージョンを更新前（１．１）に戻すか、連動するプログラム「Ｐ２」のバージョンアップを行うかを、ユーザに選択させる。

ケース（３）は、最新版プログラム「Ｐ１」が試行ＮＧ、かつ、連動するプログラム「Ｐ２」が試行ＯＫである例である。このときには、端末制御部１８は、プログラム「Ｐ１」のバージョンを更新前（１．１）に戻す。

ケース（４）は、最新版プログラム「Ｐ１」、および、連動するプログラム「Ｐ２」が試行ＯＫであるが、トータルで試行ＮＧ（実行時間の超過）が発生した例である。端末制御部１８は、最新版プログラム「Ｐ１」の実行時間（７分）が、更新前のプログラム「Ｐ１」の実行時間（３分）より４分のびてしまったことが試行ＮＧの主要因であると解析し、プログラム「Ｐ１」のバージョンを更新前（１．０）に戻す。

表８に示す試行判定管理部１２は、表７と同様に、説明用の列（ケース）が追加されている。表の各データの意味は、表７と同じである。ケース（１）は、表７と同様に、２つのプログラムがともにバージョンアップする前を示す。ケース（５）からケース（７）までは、ともに、双方のプログラム「Ｐ１，Ｐ２」をバージョンアップした例である。

ケース（５）およびケース（６）は、片方のプログラムのみ試行ＮＧとなる例である。この場合は、試行ＮＧとなったプログラムのみ、バージョンを更新前に戻す。

ケース（７）は、双方の最新版プログラム「Ｐ１，Ｐ２」がそれぞれ単体では試行ＯＫであるが、トータルで試行ＮＧ（実行時間の超過）が発生した例である。端末制御部１８は、プログラム「Ｐ１」の実行時間（７分）と、プログラム「Ｐ２」の実行時間（５分）とを比較し、試行ＮＧの発生要因となるプログラムを特定する。その結果、実行時間の長いプログラム「Ｐ１」を特定し、そのプログラム「Ｐ１」のバージョンを更新前（１．１）に戻す。

本発明の一実施形態に関するプログラム配信システムを示す構成図である。 本発明の一実施形態に関するプログラム配信システムの動作を示すフローチャートである。 本発明の一実施形態に関するプログラムの更新チェックの詳細を示すフローチャートである。

符号の説明

１ 端末
１０ 記憶装置
１１ 試行判定条件管理部
１２ 試行判定管理部
１３ａ 試行記憶部
１３ｂ 運用記憶部
１８ 端末制御部
２ 配信サーバ
２０ 記憶装置
２１ プログラム更新ＤＢ
２２ 端末状態ＤＢ
２３ 試行履歴ＤＢ
２４ リポジトリ
２８ サーバ制御部

Claims (7)

1. 配信対象プログラムを実行する端末に対して、最新版の前記配信対象プログラムを配信する配信サーバであって、
   前記配信サーバは、
   前記最新版の配信対象プログラムについて、そのバージョンを示す第１バージョン情報と、１台以上の前記端末による試行履歴データと、を対応づけて記憶装置に記憶し、
   所定端末から前記配信対象プログラムの更新チェック依頼を受信すると、
   前記所定端末に対して既に配信されている前記配信対象プログラムのバージョンを示す第２バージョン情報と、前記記憶装置に記憶されている前記第１バージョン情報と、を照合することで、配信が必要か否かを判定し、
   配信が必要と判定されたとき、前記最新版の配信対象プログラムの前記試行履歴データを参照し、所定台数以上の端末が既に試行を成功している旨の試行要否条件を満たすか否かを判定し、
   前記試行要否条件を満たすときには、配信する前記最新版の配信対象プログラムに対して、試行せずに運用する旨を前記所定端末に通知するとともに、前記試行要否条件を満たさないときには、配信する前記最新版の配信対象プログラムに対して、試行を要する旨を前記所定端末に通知することを特徴とする
   配信サーバ。
2. 前記配信サーバは、前記配信対象プログラムの前記試行履歴データを、前記端末が前記配信対象プログラムを実行することにより実施する業務ごとに分けて前記記憶装置に記憶し、
   前記試行要否条件を満たすか否かを判定するときに、前記試行履歴データにおける試行が成功した端末の台数のうちの前記所定端末が実施する業務を実施した端末の台数が、所定台数以上であるときに、前記試行要否条件を満たすと判定することを特徴とする
   請求項１に記載の配信サーバ。
3. 配信対象プログラムを実行する端末に対して、最新版の前記配信対象プログラムを配信する配信サーバであって、
   前記配信サーバは、
   前記最新版の配信対象プログラムについて、そのバージョンを示す第１バージョン情報と、１台以上の前記端末による試行履歴データと、を対応づけて記憶装置に記憶し、
   所定端末から前記配信対象プログラムの更新チェック依頼を受信すると、
   前記所定端末に対して既に配信されている前記配信対象プログラムのバージョンを示す第２バージョン情報と、前記記憶装置に記憶されている前記第１バージョン情報と、を照合することで、配信が必要か否かを判定し、
   配信が必要と判定されたとき、前記最新版の配信対象プログラムの前記試行履歴データを参照し、
   前記所定端末の試行が成功した旨の履歴が存在するときには、配信する前記最新版の配信対象プログラムに対して、試行せずに運用する旨を前記所定端末に通知するとともに、前記所定端末の試行が失敗した旨の履歴が存在するときには、配信する前記最新版の配信対象プログラムに対して、試行を要する旨を前記所定端末に通知することを特徴とする
   配信サーバ。
4. 前記配信サーバは、さらに、前記最新版の配信対象プログラムに対応づけられている前記試行履歴データにおいて、前記所定台数以上の端末が既に試行を失敗しているときには、配信が不要と判定することを特徴とする
   請求項１ないし請求項３のいずれか１項に記載の配信サーバ。
5. 請求項１ないし請求項４のいずれか１項に記載の配信サーバと、前記端末とを有することを特徴とする
   配信システム。
6. 配信対象プログラムを実行する端末に対して、最新版の前記配信対象プログラムを配信する配信サーバによる配信方法であって、
   前記配信サーバは、
   前記最新版の配信対象プログラムについて、バージョンを示す第１バージョン情報と、１台以上の前記端末による試行履歴データと、を対応づけて記憶装置に記憶し、
   所定端末から前記配信対象プログラムの更新チェック依頼を受信すると、
   前記所定端末に対して既に配信されている前記配信対象プログラムのバージョンを示す第２バージョン情報と、前記記憶装置に記憶されている前記第１バージョン情報とを照合することで、前記所定端末に前記最新版の配信対象プログラムが配信されているか否かを判定し、
   前記所定端末に前記最新版の配信対象プログラムが配信されていないとき、前記最新版の配信対象プログラムの前記試行履歴データを参照し、所定台数以上の端末が既に試行を成功している旨の試行要否条件を満たすか否かを判定し、
   前記試行要否条件を満たすときには、配信する前記最新版の配信対象プログラムに対して、試行せずに運用する旨を前記所定端末に通知するとともに、前記試行要否条件を満たさないときには、配信する前記最新版の配信対象プログラムに対して、試行を要する旨を前記所定端末に通知することを特徴とする
   配信方法。
7. 配信サーバから端末に対して配信される配信対象プログラムであって、
   前記配信対象プログラムに組み込まれている配信動作プログラムは、前記端末に読み込まれ、実行されることにより、前記端末に、
   前記配信サーバに対して、前記配信対象プログラムのバージョンを最新バージョンに更新するためのチェックを依頼させ、
   前記配信サーバから、前記チェックへの返答である通知メッセージを受信すると、
   前記通知メッセージが試行不要であるとき、前記配信サーバから前記通知メッセージとともに配信された最新版の前記配信対象プログラムを、前記端末の記憶装置内の運用のための記憶領域に記憶して実行させ、
   前記通知メッセージが試行必要であるとき、前記配信サーバから前記通知メッセージとともに配信された最新版の前記配信対象プログラムを、前記端末の記憶装置内の試行のための記憶領域に記憶して実行し、その実行結果を前記配信サーバに通知させ、
   前記実行結果が試行成功のとき、前記試行のための記憶領域に記憶した最新版の前記配信対象プログラムを、前記端末の記憶装置内の運用のための記憶領域に記憶して実行させ、
   前記実行結果が試行失敗のとき、前記試行のための記憶領域に記憶した最新版の前記配信対象プログラムを、削除させることを特徴とする
   配信対象プログラム。

Images