JP2013200657A - 更新管理システム及び更新管理方法 - Google Patents

Abstract

【課題】不具合を含んだバージョンアップ用データ（更新用プログラム）の配布を迅速に停止することを容易とすること。
【解決手段】端末装置から送信される更新要求に応じて、要求された更新用プログラムを更新用プログラム記憶部から読み出し、読み出した更新用プログラムを更新要求の送信元である端末装置に対して送信し、更新用プログラムを実行した端末装置から送信される障害通知に含まれる障害情報が、更新用プログラムに起因した障害情報であるか否かに基づいて、更新用プログラムの配布の停止を判定し、判定ステップにおいて更新用プログラムの配布の停止が判定された場合、更新要求に応じた更新用プログラムの送信を停止する。
【選択図】図２

Description

本発明は、コンピュータソフトウェアの更新の技術に関する。

近年、コンピュータ上で動作するＯＳ（Operating System）やアプリケーション等のソフトウェアが複雑高度化の一途をたどり、不具合が混入したとしても事前の発見が困難となってきている。そのため、自動的にソフトウェアの不具合を検出する技術が提案されている（特許文献１参照）。

検出された不具合は、電話やネットワークを介してサポートセンターに通知される。サポートセンターでは、通知された不具合の情報に基づいてユーザーに対する対応が行われるとともに、対応履歴が作成される。その後、ソフトウェアの開発技術者等が対応履歴に基づいて不具合の原因の解析を行う。そして、原因に基づいて様々な対処がなされる。例えば、ソフトウェアのバージョンアップが不具合の原因である場合には、バージョンアップを停止することがバージョンアップ用サーバ（更新サーバ）の管理者に通知される。更新サーバの管理者は、バージョンアップ停止の通知を受けると、更新サーバを操作してバージョンアップの停止（バージョンアップ用データの配布停止）を行う。このような作業によって、不具合の波及を防止することができる。

特開２００４−３４８７４０号公報

しかしながら、ソフトウェアの不具合が通知されてからバージョンアップの停止が行われるまでには多大な労力と作業時間を要するため、その間に不具合を含んだバージョンアップ用データが配布され続けてしまうという問題があった。
上記事情に鑑み、本発明は、不具合を含んだバージョンアップ用データ（更新用プログラム）の配布を迅速に停止することを容易とする技術を提供することを目的としている。

本発明の一態様は、端末装置に配布される更新用プログラムを記憶する更新用プログラム記憶部と、前記端末装置から送信される更新要求に応じて、要求された前記更新用プログラムを前記更新用プログラム記憶部から読み出し、読み出した前記更新用プログラムを前記更新要求の送信元である前記端末装置に対して送信する更新制御部と、前記更新用プログラムを実行した前記端末装置から送信される障害通知に含まれる障害情報が、前記更新用プログラムに起因した障害情報であるか否かに基づいて、前記更新用プログラムの配布の停止を判定する判定部と、を備え、前記更新制御部は、前記判定部によって前記更新用プログラムの配布の停止が判定された場合、前記更新要求に応じた前記更新用プログラムの送信を停止する、更新管理システムである。

本発明の一態様は、端末装置に配布される更新用プログラムを記憶する更新用プログラム記憶部を備える更新管理システムが行う更新管理方法であって、前記端末装置から送信される更新要求に応じて、要求された前記更新用プログラムを前記更新用プログラム記憶部から読み出し、読み出した前記更新用プログラムを前記更新要求の送信元である前記端末装置に対して送信する更新制御ステップと、前記更新用プログラムを実行した前記端末装置から送信される障害通知に含まれる障害情報が、前記更新用プログラムに起因した障害情報であるか否かに基づいて、前記更新用プログラムの配布の停止を判定する判定ステップと、前記判定ステップにおいて前記更新用プログラムの配布の停止が判定された場合、前記更新要求に応じた前記更新用プログラムの送信を停止する停止ステップと、を有する更新管理方法である。

本発明により、不具合を含んだバージョンアップ用データ（更新用プログラム）の配布を迅速に停止することが可能となる。

本発明の一実施形態の通信システム１のシステム構成を表すシステム構成図である。 本発明の一実施形態における更新管理システム１０の機能構成を示す概略ブロック図である。 停止情報テーブルの具体例を示す図である。 更新処理に関する処理の流れを示すシーケンス図である。 障害通知処理に関する処理の流れを示すシーケンス図である。 更新処理及び障害通知処理に関する第一の変形例を示すシーケンス図である。 更新処理に関する処理の流れの第二の変形例を示すシーケンス図である。 障害通知処理に関する処理の流れの第二の変形例を示すシーケンス図である。 停止情報テーブルの変形例を示す図である。

図１は、本発明の一実施形態の通信システム１のシステム構成を表すシステム構成図である。通信システム１は、更新管理システム１０、複数台の端末装置２０（２０−１〜２０−ｎ）、ネットワーク３０を備える。更新管理システム１０と各端末装置２０とは、ネットワーク３０に接続されおり、ネットワーク３０を介して互いに通信可能である。図１には更新管理システム１０は一つしか示されていないが、複数あっても良い。

更新管理システム１０は、端末装置２０で動作するソフトウェア（以下、単に「ソフトウェア」という。）のバージョンアップを行うシステムである。更新管理システム１０は、ソフトウェアの更新用プログラムを記憶しており、端末装置２０からの更新要求に応じて更新用プログラムを送信する。更新用プログラムとは、端末装置２０に対して配布されるプログラムである。

端末装置２０は、例えば固定電話機、携帯電話機、ＰＤＡ（Personal Digital Assistant）、スマートフォン、据え置き型パーソナルコンピュータ、タブレット型パーソナルコンピュータ、ノート型パーソナルコンピュータ、各種専用端末装置、ゲーム機、カーナビゲーション装置等の通信可能な情報処理装置である。
端末装置２０は、自装置に障害の発生が検出されると、更新管理システム１０に障害通知を送信する。障害通知は、端末装置２０に生じた障害の内容を示す情報（障害情報）を含む。障害情報は、例えば、障害が生じたソフトウェアのＩＤ（ソフトウェアＩＤ）とバージョンのＩＤ（バージョンＩＤ）、障害が発生した際のログ情報などを含む。なお、端末装置２０が障害の発生を検出する技術にはどのような既存技術が適用されても良い。例えば、上記の特許文献１に開示された技術が適用されても良い。

図２は、本発明の一実施形態における更新管理システム１０の機能構成を示す概略ブロック図である。更新管理システム１０は、１台又は複数台の情報処理装置によって構成される。例えば、更新管理システム１０が一台の情報処理装置で構成される場合、情報処理装置は、バスで接続されたＣＰＵ（Central Processing Unit）やメモリや補助記憶装置などを備え、更新管理プログラムを実行する。更新管理プログラムの実行によって、情報処理装置は、通信部１０１、停止情報記憶部１０２、更新用プログラム記憶部１０３、更新部１０４、判定部１０５、障害情報記憶部１０６を備える装置として機能する。なお、更新管理システム１０の各機能の全て又は一部は、ＡＳＩＣ（Application Specific Integrated Circuit）やＰＬＤ（Programmable Logic Device）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを用いて実現されても良い。また、更新管理システム１０は、専用のハードウェアによって実現されても良い。更新管理プログラムは、コンピュータ読み取り可能な記録媒体に記録されても良い。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。

通信部１０１は、ネットワーク３０を介して端末装置２０とデータを送受信する通信インタフェースである。
停止情報記憶部１０２は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。停止情報記憶部１０２は、停止情報テーブルを記憶する。停止情報テーブルは、更新用プログラム毎に配布の停止が判定されたか否かを表すテーブルである。

図３は、停止情報テーブルの具体例を示す図である。停止情報テーブルは、例えばソフトウェアＩＤ、バージョンＩＤ、停止フラグの各項目を対応付けたレコード３１を複数有する。ソフトウェアＩＤは、ソフトウェアを示す識別情報である。バージョンＩＤは、ソフトウェアのバージョンを示す識別情報である。停止フラグは、レコード３１に対応する更新用プログラムの配布が停止されているか否かを示すフラグである。例えば、“０”は停止されていないことを示し、“１”は停止されていることを示す。

ソフトウェアの更新用プログラムはソフトウェアＩＤ毎に作成される。また、一つのソフトウェアＩＤに対して、複数のバージョンの更新用プログラムが存在する。一つのレコード３１は一つの更新用プログラムを示す。
更新用プログラム記憶部１０３は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。更新用プログラム記憶部１０３は、更新用プログラムを記憶する。例えば、更新用プログラム記憶部１０３は、停止情報テーブルに記録されているレコード３１毎に対応する更新用プログラムを記憶している。

更新部１０４は、端末装置２０から送信される更新要求に応じて更新処理を行う。
判定部１０５は、端末装置２０から送信される障害情報を障害情報記憶部１０６に書き込む。また、判定部１０５は、障害情報記憶部１０６に記録されている障害情報に基づいて障害解析を行い、各更新プログラムについて配布を停止すべきか否か判定する。
障害情報記憶部１０６は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。障害情報記憶部１０６は、端末装置２０から送信される障害情報を記憶する。

図４は、更新処理に関する処理の流れを示すシーケンス図である。まず、端末装置２０が所定のタイミング（更新タイミング）で更新問い合わせを更新管理システム１０に送信する（ステップＳ１０１）。更新問い合わせは、端末装置２０が備えているソフトウェアのＩＤ（ソフトウェアＩＤ）及びバージョンＩＤを含む。更新管理システム１０の更新部１０４は、更新問い合わせを受信すると、受信した更新問い合わせのソフトウェアＩＤの更新用プログラムのうち、受信した更新問い合わせのバージョンＩＤよりも新しいバージョンの更新用プログラムが存在するか否か判定する（ステップＳ１０２）。そして、更新部１０４は、更新問い合わせの送信元の端末装置２０に対し、判定結果を示す更新情報通知を送信する（ステップＳ１０３）。なお、判定結果が更新用プログラムが有ることを示す場合には、更新情報通知は新しいバージョンを示すバージョンＩＤを含む。

端末装置２０は、更新情報通知を受信すると、更新情報通知に含まれる判定結果を参照する。判定結果が、更新用プログラムが無いことを示す場合（ステップＳ１０４−ＮＯ）、端末装置２０は更新に関する処理を終了する（ステップＳ１０５）。一方、判定結果が、更新用プログラムが有ることを示す場合（ステップＳ１０４−ＹＥＳ）、端末装置２０は更新要求を更新管理システム１０に送信する（ステップＳ１０６）。更新要求は、更新を要求するソフトウェアＩＤと、新しいバージョンＩＤとを含む。

更新管理システム１０の更新部１０４は、更新要求を受信すると、更新要求に含まれるソフトウェアＩＤ及びバージョンＩＤに対応するレコード３１を停止情報テーブルから検索する。そして、更新部１０４は、検索されたレコード３１の停止フラグの値を参照する（ステップＳ１０７）。停止フラグの値が“１”である場合、すなわち配布が停止されている場合（ステップＳ１０８−ＮＯ）、更新部１０４は、更新要求の送信元の端末装置２０に対してエラー通知を送信する（ステップＳ１０９）。この場合、端末装置２０は更新に関する処理を終了する。

一方、停止フラグの値が“０”である場合、すなわち配布が停止されていない場合（ステップＳ１０８−ＹＥＳ）、更新部１０４は、更新要求に含まれるソフトウェアＩＤバージョンＩＤに対応する更新用プログラムを更新用プログラム記憶部１０３から検索する。そして、更新部１０４は、検索された更新用プログラムを、更新要求の送信元の端末装置２０に対して送信する（ステップＳ１１１）。
端末装置２０は、更新管理システム１０から更新用プログラムを受信すると、受信した更新用プログラムを記録する（ステップＳ１１２）。端末装置２０は、単に更新用プログラムを自装置の記憶装置に記録するだけでも良いし、既にインストールされているソフトウェアを更新用プログラムによってアップデートする処理を実行しても良い。

図５は、障害通知処理に関する処理の流れを示すシーケンス図である。端末装置２０は所定のタイミング（障害判定タイミング）で、自装置に障害が発生しているか否か判定する（ステップＳ２０１）。障害が発生している場合（ステップＳ２０１−ＹＥＳ）、端末装置２０は、障害通知を更新管理システム１０へ送信する（ステップＳ２０２）。

更新管理システム１０の判定部１０５は、障害通知を受信すると、受信された障害通知に含まれる障害情報を障害情報記憶部１０６に書き込む（ステップＳ２０３）。更新管理システム１０の判定部１０５は、所定のタイミング（停止判定タイミング）で障害情報を解析する（ステップＳ２０４−ＹＥＳ、ステップＳ２０５）。具体的には、判定部１０５は、蓄積されている障害情報に基づいて、更新用プログラム毎に、高い確率で不具合を含んでいると推定できるか否か判定する。このような判定処理は、既存のどのような解析技術が適用されても良い。判定部１０５は、高い確率で不具合を含んでいると推定される更新用プログラムについて、配布を停止すべきと判定する。

判定部１０５は、配布を停止すべきと判定した更新用プログラムが存在する場合（ステップＳ２０６−ＹＥＳ）、該当する更新用プログラムに対応するレコード３１の停止フラグを“０”から“１”に更新する（ステップＳ２０７）。

このように構成された更新管理システム１０では、端末装置２０から通知された障害情報に基づいて、高い確率で不具合を含んでいると推定できる更新用プログラムの配布が自動的に停止される。そのため、不具合を含んだ更新用プログラム（バージョンアップ用データ）の配布を迅速に停止することが可能となる。

＜変形例＞
図６は、更新処理及び障害通知処理に関する第一の変形例を示すシーケンス図である。図６において、図４に示す処理及び図５に示す処理と同じ処理については同じ符号を付している。以下、図６に示される処理の流れについて説明する。
端末装置２０は、障害判定タイミングで、自装置に障害が発生しているか否か判定し、判定結果（障害判定結果）を記憶する。また、端末装置２０は、更新タイミングになると（ステップＳ２１０−ＹＥＳ）、更新障害通知を更新管理システム１０に送信する（ステップＳ２１１）。更新障害通知は、更新問い合わせと障害通知とを含む。すなわち、第一の変形例では、端末装置２０は一度の通信で、更新問い合わせと障害通知とを実行する。更新障害通知に含まれる障害通知の情報は、端末装置２０における最新の障害判定結果である。もし障害が発生していない場合には、障害が発生していないことを示す障害判定結果が更新障害通知に与えられる。

更新管理システム１０の更新部１０４は、更新障害通知を受信すると、受信した更新障害通知に含まれる更新問い合わせのソフトウェアＩＤの更新用プログラムのうち、受信した更新問い合わせのバージョンＩＤよりも新しいバージョンの更新用プログラムが存在するか否か判定する（ステップＳ１０２）。そして、更新部１０４は、更新問い合わせの送信元の端末装置２０に対し、判定結果を示す更新情報通知を送信する（ステップＳ１０３）。なお、判定結果が更新用プログラムが有ることを示す場合には、更新情報通知は新しいバージョンを示すバージョンＩＤを含む。

端末装置２０は、更新情報通知を受信すると、更新情報通知に含まれる判定結果を参照する。判定結果が、更新用プログラムが無いことを示す場合（ステップＳ１０４−ＮＯ）、端末装置２０は更新に関する処理を終了する（ステップＳ１０５）。一方、判定結果が、更新用プログラムが有ることを示す場合（ステップＳ１０４−ＹＥＳ）、端末装置２０は、その時点における状態情報を記録する（ステップＳ２１２）。状態情報は、更新しようとするソフトウェアに関連するログ情報である。そして、端末装置２０は更新要求を更新管理システム１０に送信する（ステップＳ１０６）。更新要求は、更新を要求するソフトウェアＩＤ及び新しいバージョンＩＤを含む。

端末装置２０のステップＳ１０４、Ｓ１０５、Ｓ２１２の処理と独立して、更新管理システム１０は、ステップＳ２１１において受信した更新障害通知の障害通知の情報に基づいて処理を行う。具体的には以下の通りである。
更新管理システム１０の判定部１０５は、受信された障害通知に含まれる障害情報を障害情報記憶部１０６に書き込む（ステップＳ２０３）。更新管理システム１０の判定部１０５は、所定のタイミング（停止判定タイミング）で障害情報を解析する（ステップＳ２０４−ＹＥＳ、ステップＳ２０５）。具体的には、判定部１０５は、蓄積されている障害情報に基づいて、更新用プログラム毎に、高い確率で不具合を含んでいると推定できるか否か判定する。このような判定処理は、既存のどのような解析技術が適用されても良い。判定部１０５は、高い確率で不具合を含んでいると推定される更新用プログラムについて、配布を停止すべきと判定する。

判定部１０５は、配布を停止すべきと判定した更新用プログラムが存在する場合（ステップＳ２０６−ＹＥＳ）、該当する更新用プログラムに対応するレコード３１の停止フラグを“０”から“１”に更新する（ステップＳ２０７）。なお、ステップＳ２０４の処理において停止判定タイミングではない場合や（ステップＳ２０４−ＮＯ）、ステップＳ２０６の処理において停止すべきとの判定がなされない場合は（ステップＳ２０６−ＮＯ）、更新管理システム１０の処理はステップＳ２０７の次の処理に移行する。以上の処理が、端末装置２０のステップＳ１０４、Ｓ１０５、Ｓ２１２の処理と独立して実行される。

ステップＳ１０６において端末装置２０から送信された更新要求を受信すると、更新管理システム１０の更新部１０４は、検索されたレコード３１の停止フラグの値を参照する（ステップＳ１０７）。停止フラグの値が“１”である場合、すなわち配布が停止されている場合（ステップＳ１０８−ＮＯ）、更新部１０４は、更新要求の送信元の端末装置２０に対してエラー通知を送信する（ステップＳ１０９）。この場合、端末装置２０は更新に関する処理を終了する。

一方、停止フラグの値が“０”である場合、すなわち配布が停止されていない場合（ステップＳ１０８−ＹＥＳ）、更新部１０４は、更新要求に含まれるソフトウェアＩＤ及びバージョンＩＤに対応する更新用プログラムを更新用プログラム記憶部１０３から検索する。そして、更新部１０４は、検索された更新用プログラムを、更新要求の送信元の端末装置２０に対して送信する（ステップＳ１１１）。

端末装置２０は、更新管理システム１０から更新用プログラムを受信すると、受信した更新用プログラムを記録する（ステップＳ１１２）。端末装置２０は、単に更新用プログラムを自装置の記憶装置に記録するだけでも良いし、既にインストールされているソフトウェアを更新用プログラムによってアップデートする処理を実行しても良い。

図７は、更新処理に関する処理の流れの第二の変形例を示すシーケンス図である。図７において、図４に示す処理と同じ処理については同じ符号を付している。以下、図７に示される処理の流れについて説明する。ステップＳ１０４の処理の後、端末装置２０は、その時点における状態情報を記録する（ステップＳ３０１）。状態情報は、更新しようとするソフトウェアに関連するログ情報である。

ステップＳ３０１の処理の後、端末装置２０は更新要求を送信し（ステップＳ１０６）、受信した更新用プログラムを記録する（ステップＳ１１２）。その後、端末装置２０は、更新用プログラムを実行し、自装置に障害が発生しているか否か判定する（ステップＳ３０２）。障害が発生している場合、端末装置２０は、障害通知処理を実行する（ステップＳ３０３）。障害通知処理とは、障害が検出された際に端末装置２０が実行する処理であり、例えば図５のステップＳ２０２〜Ｓ２０７の処理であっても良いし、後述する図８に示されるステップＳ２０２〜Ｓ４０５の処理であっても良い。変形例における障害通知処理では、端末装置２０は、ステップＳ３０１において取得した状態情報も障害情報として更新管理システム１０に送信する。

このような処理が行われることにより、端末装置２０において、更新用プログラムの実行前の状態と実行後の状態とを比較可能な障害情報を生成することが可能となる。そのため、更新管理システム１０の判定部１０５において、不具合を含んでいる更新用プログラムをより正確に推定することが可能となる。
なお、ステップＳ３０１の処理は、ステップＳ１１２において更新用プログラムが記録される前であればどの時点で実行されても良い。

図８は、障害通知処理に関する処理の流れの第二の変形例を示すシーケンス図である。図８において、図５に示す処理と同じ処理については同じ符号を付している。以下、図８に示される処理の流れについて説明する。図８に示す処理が行われる更新管理システム１０の更新部１０４は、更新用プログラムを端末装置２０に対して送信すると、送信先となった端末装置２０の識別情報（例えば、ＩＰアドレス、ＭＡＣアドレス、ユーザＩＤ、装置ＩＤなど）と、送信された更新用プログラムとを対応づけて記憶する。

図８のステップＳ２０７の処理の後、更新部１０４は、停止フラグの値が更新されたレコード３１に対応する更新用プログラムについて、これまでに送信先となった端末装置２０の識別情報を検索する（ステップＳ４０１）。更新部１０４は、検索された各端末装置２０に対し、過去に送信された更新用プログラムに不具合が生じている可能性があることを通知するための情報（障害可能性通知）を送信する（ステップＳ４０２）。

障害可能性通知を受信した端末装置２０は、バージョンダウン要求を更新管理システム１０へ送信する（ステップＳ４０３）。バージョンダウン要求は、障害の可能性が通知されたソフトウェアの古いバージョンの更新用プログラムを要求するための更新要求である。すなわち、バージョンダウン要求は、障害可能性通知の対象となっているソフトウェアのＩＤ（ソフトウェアＩＤ）、配信が停止されているバージョンよりも古いバージョンを示すバージョンＩＤを含む。

更新管理システム１０の更新部１０４は、バージョンダウン要求を受信すると、バージョンダウン要求（更新要求）に含まれるソフトウェアＩＤ、バージョンＩＤに対応する更新用プログラムを検索する。更新部１０４は、検索された更新用プログラムを、バージョンダウン用プログラムとして、バージョンダウン要求の送信元の端末装置２０に対して送信する（ステップＳ４０４）。端末装置２０は、バージョンダウン用プログラムを受信すると、受信したバージョンダウン用プログラムを記録する（ステップＳ４０５）。端末装置２０は、単にバージョンダウン用プログラムを自装置の記憶装置に記録するだけでも良いし、既にインストールされているソフトウェアをバージョンダウン用プログラムによって更新する処理を実行しても良い。

図９は、停止情報テーブルの変形例を示す図である。停止情報テーブルは、例えばソフトウェアＩＤ、プラットフォームＩＤ、バージョンＩＤ、停止フラグの各項目を対応付けたレコード３２を複数有する。プラットフォームＩＤは、ソフトウェアが動作するプラットフォームを示す識別情報である。
変形例の場合、ソフトウェアの更新用プログラムはプラットフォーム毎に作成される。また、ソフトウェア及びプラットフォームの一つの組み合わせに対して、複数のバージョンの更新用プログラムが存在する。一つのレコード３２は一つの更新用プログラムを示す。

停止情報テーブルが図９のように構成される場合、端末装置２０から送信される障害情報には、ソフトウェアＩＤとバージョンＩＤとログ情報に加えてさらに、端末装置２０のプラットフォームを示すＩＤ（プラットフォームＩＤ）が含まれる。また、端末装置２０から送信される更新問い合わせには、ソフトウェアＩＤ及びバージョンＩＤに加えてさらに、端末装置２０のプラットフォームＩＤが含まれる。また、端末装置２０から送信される更新要求には、ソフトウェアＩＤ及び新しいバージョンＩＤに加えてさらに、端末装置２０のプラットフォームＩＤが含まれる。

更新管理システム１０の更新部１０４は、ステップＳ１０２の処理において、受信した更新問い合わせのソフトウェアＩＤ及びプラットフォームＩＤの更新用プログラムのうち、受信した更新問い合わせのバージョンＩＤよりも新しいバージョンの更新用プログラムが存在するか否か判定する。
更新管理システム１０の更新部１０４は、ステップＳ１０７の処理において、更新要求に含まれるソフトウェアＩＤ、プラットフォームＩＤ、バージョンＩＤに対応するレコード３２を停止情報テーブルから検索する。そして、更新部１０４は、検索されたレコード３２の停止フラグの値を参照する。

停止情報テーブルが図９のように構成された場合、更新管理システム１０では、不具合を含んでいると推定されたソフトウェアの更新用プログラム全てが配布停止になるのではなく、プラットフォーム毎に配布を停止するか否か判定される。そのため、不必要に配布が停止されてしまうことを防止することが可能となる。例えば、同じソフトウェアＩＤ且つ同じバージョンＩＤの更新用プログラムであっても、障害が通知されていないプラットフォームに対する更新用プログラムは、配布が停止されることなく継続される。

また、判定部１０５は以下のように構成されても良い。判定部１０５は、ステップＳ２０５の処理において、高い確率で不具合を含んでいると推定される更新用プログラムを検出した場合、その更新用プログラムとソフトウェアＩＤ及びバージョンＩＤが共通する全てのレコード３２の停止フラグを“０”から“１”に変更する。その後、所定の時間が経過するまでの間に、配布を停止すべきと判定されたプラットフォームＩＤのレコード３２については、判定部１０５は、所定の時間が経過した後も停止フラグの値を“１”のままに維持する。一方、所定の時間が経過するまでの間に、配布を停止すべきと判定されなかったプラットフォームＩＤのレコード３２については、判定部１０５は、所定の時間が経過した後に停止フラグの値を“１”から“０”に戻す。このように構成されることにより、高い確率で不具合を含んでいると推定された更新用プログラムを、プラットフォームＩＤの相違にかかわらず迅速に配布停止とすることが可能となる。その上で、所定の時間が経過しても不具合が含まれていると判定されなかったプラットフォームＩＤの更新用プログラムについては、たとえ同一のソフトウェアＩＤ及びバージョンＩＤの更新用プログラムについて他のプラットフォームにおいて配布が停止されたとしても、問題がない更新用プログラムとして配布を再開することが可能となる。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１…通信システム， １０…更新管理システム， ２０…端末装置， ３０…ネットワーク， １０１…通信部， １０２…停止情報記憶部， １０３…更新用プログラム記憶部， １０４…更新部（更新制御部）， １０５…判定部， １０６…障害情報記憶部， ３１、３２…レコード

Claims (2)

1. 端末装置に配布される更新用プログラムを記憶する更新用プログラム記憶部と、
   前記端末装置から送信される更新要求に応じて、要求された前記更新用プログラムを前記更新用プログラム記憶部から読み出し、読み出した前記更新用プログラムを前記更新要求の送信元である前記端末装置に対して送信する更新制御部と、
   前記更新用プログラムを実行した前記端末装置から送信される障害通知に含まれる障害情報が、前記更新用プログラムに起因した障害情報であるか否かに基づいて、前記更新用プログラムの配布の停止を判定する判定部と、
   を備え、
   前記更新制御部は、前記判定部によって前記更新用プログラムの配布の停止が判定された場合、前記更新要求に応じた前記更新用プログラムの送信を停止する、更新管理システム。
2. 端末装置に配布される更新用プログラムを記憶する更新用プログラム記憶部を備える更新管理システムが行う更新管理方法であって、
   前記端末装置から送信される更新要求に応じて、要求された前記更新用プログラムを前記更新用プログラム記憶部から読み出し、読み出した前記更新用プログラムを前記更新要求の送信元である前記端末装置に対して送信する更新制御ステップと、
   前記更新用プログラムを実行した前記端末装置から送信される障害通知に含まれる障害情報が、前記更新用プログラムに起因した障害情報であるか否かに基づいて、前記更新用プログラムの配布の停止を判定する判定ステップと、
   前記判定ステップにおいて前記更新用プログラムの配布の停止が判定された場合、前記更新要求に応じた前記更新用プログラムの送信を停止する停止ステップと、
   を有する更新管理方法。

Images