JP2014021586A - プログラムのアップグレードを実施するサーバ、サーバと複数の機器からなるプログラムのアップグレードシステム及びプログラムのアップグレード方法 - Google Patents

Abstract

【課題】複数の機器のプログラムをアップグレードする際に、プログラムの不具合で機器全台が同時に使用不能となる状況を回避する。
【解決手段】複数台の機器２０（１）〜２０（ｎ）とネットワーク３０で接続し前記機器２０（１）〜２０（ｎ）のプログラムのアップグレードを実施するサーバ１００であって、プログラムのアップグレードを実施する手段と、前記複数台の機器のうち、先行してプログラムのアップグレードを実施する機器を指定する手段と、指定した機器の状態が予め設定した監視終了条件を満たすまで先行アップグレードした機器の状態を監視する機器状態監視部１０７とを有し、先行アップグレード機器監視管理部１０８が先行アップグレード機器の状態が監視終了条件を満たしたと判断したことを条件に、先行アップグレード機器以外の機器に対してプログラムのアップグレードを実施する。
【選択図】図２

Description

本発明は、プログラムのアップグレードを実施するサーバ、サーバと複数の機器からなるプログラムのアップグレードシステム及びプログラムのアップグレード方法に関する。

市場で稼働している機器のプログラムアップグレード（ファームウェアアップグレード及びアプリケーションアップグレードを含む）を行う場合、サービス要員がアップグレードするプログラムを記憶媒体に入れて納品先に持参し、アップグレード作業を行う必要があった。この手間とコストを軽減するため、遠隔地からネットワーク経由でアップグレードするプログラムを機器に送信し、機器は搭載されたプログラムを、受信したプログラムに自動でアップグレードするアップグレード方法が既に知られている。

しかし、従来の遠隔操作によるプログラムアップグレード方法では、実行する時には納品先の同機種全てをアップグレードしていたため、アップグレードしたプログラムに問題が潜在している場合、市場稼動後に不具合が発生し、顧客先で全機種（機器）が使用できないという状況が発生する虞がある。
この場合、不具合対策版のプログラムが完成するまで、該当プログラムで稼働している全ての機器を、正常稼動していたプラグラムにダウングレードすることもできる。しかし、その場合でも一時的には機器が使用できない状態が発生することは避けられない。

従来のプログラムアップグレードを行うシステムとして、特許文献１には、データネットワークに接続された多数の電子装置ファームウェアをアップデートする方法が開示されている。このアップグレードシステムでは、最初に１台の電子装置のファームウェアを構成し、その電子装置のファームウェアからファームウェアのアップデートファイルを生成する。次に、生成したファームウェアアップデートファイルを、データネットワークを介して他の電子装置に送信し、各電子装置で受信したファイルからファームウェアを構成する。

このシステムは、ネットワークを介して複数の機器のプログラム（ファームウェア）をアップグレードする点では以下で説明する本発明と類似する点がある。しかし、プログラムに不具合が潜在していた場合に、アップグレードした納品先の全機器が使用できなくなる虞があるという、前記従来の問題は解消できていない。

本発明は、機器のプログラムアップグレードを行う際における、前記従来の問題に鑑みてなされたものであって、その目的は、複数台の機器を導入している顧客先に対しての遠隔地からのプログラムアップグレードを行う場合に、一部の機器について先行してアップグレードを行い、プログラムに不具合が潜在しているかチェックしてから残りの機器のアップグレードを実行することで、機器全台が同時に使用不能となる状況を回避することである。

本発明は、複数台の機器とネットワークで接続し前記機器のプログラムのアップグレードを実施するサーバであって、プログラムのアップグレードを実施する手段と、前記複数台の機器のうち、先行してプログラムのアップグレードを実施する機器を指定する手段と、先行してプログラムのアップグレードを実施した前記指定した機器の状態が予め設定した監視終了条件を満たすまで当該機器の状態を監視する手段と、を有し、前記監視する手段が前記指定した機器の状態が前記監視終了条件を満たしたと判断したことを条件に、前記指定した機器以外の機器に対してプログラムのアップグレードを実施するサーバである。

本発明によれば、複数台の機器を導入している顧客先に対して遠隔地からプログラムアップグレードを行う場合に、一部の機器について先行してアップグレードを行い、プログラムに不具合が潜在しているかチェックしてから残りの機器のアップグレードを実行するため、機器全台が同時に使用不能となる状況を回避することができる。

本実施形態に係るファームウェアアップグレードを実施するシステムの全体構成を概略的に説明する図である。 サーバの構成について説明する図である。 本実施形態におけるファームウェアのアップグレードの処理手順を示すフロー図である。 本システムにおけるファームウェアアップグレード開始から終了までの処理手順を説明するフロー図である。 本実施形態における監視終了条件の一例について説明する図である。 本実施形態におけるサービスコールとその原因・解決方法を持つデータベースの内容例について説明する図である。 本実施形態におけるサービスコール発生時の、ファームウェアに不具合があるかどうかの判断手順について説明するフロー図である。 本実施形態における監視終了判定の事例について説明する図である。

次に、本発明をその実施形態について詳しく説明するが、まず実施形態を概略的に説明する。
即ち、アップグレード対象の機器とネットワークで接続されたサーバで、プログラムアップグレード（ここではファームウェアアップグレード）する対象の機器のうち一部のみを先行してアップグレードし、複数の条件の組み合わせによる監視終了条件を満たすまで先行アップグレードした機器の状態を監視する。これによって、対象ファームウェアに起因するサービスコールが発生しない（対象ファームウェアに不具合が潜在していない）ことを確認し、その後、残りの機器に対してもファームウェアアップグレードを実施する。これにより、前記監視中に対象ファームウェアに起因するサービスコールが発生した場合でも、残りの機器は稼働可能な状態を保証することができる。
以下、本発明の実施形態を以下の図面を用いて説明する。

図１は、本発明の実施形態に係るファームウェアアップグレードを実施するシステムの全体構成を概略的に説明する図である。
本実施形態に係るファームウェアアップグレードシステムは、概略的にはサービス提供元（サービス・保守会社など）１０のサーバ１００と、納入先（顧客先）２０と、その両者を繋ぐネットワーク３０とから構成されている。
サーバ１００はサービスコールとその原因と解決方法を記録したデータベース１０１と、先行アップグレードした機器の監視終了条件を記録したデータベース１０２と、アップグレード対象ファームウェアでのアップグレード対象機能を記録したデータベース１０３を内部に保持している。
また、納入先２０には、複数のファームウェアアップグレード対象機器２０（１）〜２０（ｎ）が備えられている。複数のファームウェアアップグレード対象機器２０（１）〜２０（ｎ）は、アップグレード開始時、アップグレード中、アップグレード終了時にそれが分かるように、それぞれに対応した表示を行う表示手段を有しており、先行アップグレード中に前記表示を行う。

本実施形態では、ファームウェアアップグレードを行う場合、顧客先２０でネットワーク３０に接続している複数の機器２０（１）〜２０（ｎ）のうち、遠隔地のサービス提供元１０のサーバ１００で複数の機器２０（１）〜２０（ｎ）の一部の機器のみに対する先行アップグレードを行う（本発明では、このアップグレードに必要なサーバ側の処理を行う構成を総称してアップグレードを実施する手段という）。
サーバ１００は、サーバ１００が保持する後述する監視終了条件を満たすと判断したとき監視を終了し、残りの機器に対してファームウェアファイルを送信し、ファームウェアのアップグレードを行う。

機器２０（１）〜２０（ｎ）は、サーバ１００から受信したファームウェアファイルを保存し、前記ファームウェアのアップグレードを行う。また、前記監視中に、機器２０（１）〜２０（ｎ）にサービスコールが発生すると、サービスコールの情報およびログ情報をネットワーク３０経由でサーバ１００に送信する。サーバ１００は、機器２０（１）〜２０（ｎ）からサービスコールの情報およびログ情報を受信すると、両者の内容およびサービスコールとその原因、解決方法を持つデータベース１０１の内容から、ファームウェアの不具合かどうかを判断する。

ここで、サーバ１００がファームウェアの不具合と判断したときは、先行アップグレードした機器をダウングレードするため、サーバ１００から当該機器へ先行アップグレード前のファームウェアファイルを送信し、ファームウェアのダウングレードを行う。

ここで、機器２０（１）〜２０（ｎ）がサーバ１００に送信するサービスコールの情報およびログ情報は以下の情報を含む。
即ち、（１）発生した現象（紙詰まり、エンジンエラー、コントローラエラーなど）とその現象が機器のどこ（どの機能）で発生したかの情報。
（２）サービスコールの履歴（発生したサービスコール番号（サービスコールＩＤ）、発生時間など）の情報。
なお、上述のように、データベース１０１には、前記サービスコールの原因・解決方法、即ち機器の仕様やこれまでの動作実績から収集したサービスコールの発生原因や解決方法・対応方法が格納されている。

図２は、前記サーバ１００の構成について説明する図である。
サーバ１００は、ネットワーク３０を通じて納入先（顧客先）２０の機器２０（１）〜２０（ｎ）およびサービスや設計を司る部署であるサービス・設計区２００と接続され、その内部には、ファームウェア不具合判断部１０４と、調査依頼通知部１０５と、データ送受信部１０６と、機器状態監視部１０７と、先行アップグレード機器監視管理部１０８とを備えている。

ここで、１０１〜１０３の各データベースについては既に説明した通りである。
ファームウェア不具合判断部１０４は、機器状態監視部１０７が受信した機器２０（１）〜２０（ｎ）からのサービスコールがファームウェアの不具合かどうか判断する。即ち、不具合がアップグレードしたファームウェアに起因するものか否か判断する手段を構成する。
調査依頼通知部１０５は、不具合がファームウェアに起因するか否か判断できないとき、不具合の発生を通知し、或いは、前記データ送受信部１０６を通じてサービス・設計区２００へサービスコールの調査依頼を通知する。

データ送受信部１０６は、ネットワーク３０を通じてデータの送受信を行い、ネットワーク経由で先行アップグレード対象かどうかの情報及び監視終了条件及び現時点での状態を機器に通知し、また、ファームウェアファイルを機器に送信する。
機器状態監視部１０７は、前記データ送受信部１０６で受信した機器２０（１）〜２０（ｎ）の状態を監視し、先行アップグレードした機器の状態を監視する。
先行アップグレード機器監視管理部１０８は、先行アップグレードした機器の監視終了条件と、対象ファームウェアでのアップグレード対象の機能と、先行アップグレード機器の情報や監視終了条件の管理を行い、前記機器の状態および監視終了条件とアップグレード機能の情報から監視の終了判断を行う。
先行アップグレード機器監視管理部１０８は、機器から通知される情報と予め定めた監視終了条件とに基づき監視終了を判断する。
また、ユーザインターフェース１０９は、サーバ１００側での監視終了条件の設定を行う。

機器２０（１）〜２０（ｎ）は、サーバ１００のデータ送受信部１０６から、ネットワーク３０を通じて当該機器が先行アップグレード対象かどうかの情報、監視終了条件の情報及び当該機器の現時点での機器状態の情報を受信すると、これらの情報を保存しかつユーザに通知する。

図３は、本実施形態におけるファームウェアのアップグレードの処理手順を示すフロー図である。
まず、サービス要員は、サーバ１００にて顧客先２０の複数の機器２０（１）〜２０（ｎ）の中から先行アップグレードする機器を指定（又は選定）する（Ｓ１０１）。機器の指定は、サーバ１００に接続した図示しないモニタ等に顧客先２０の機器一覧を表示し、その中から任意の機器（複数台可）を指定することで行う。

次に、サービス要員は、サーバ１００にて先行アップグレードする機器の監視終了条件を設定する（Ｓ１０２）。なお、監視終了条件の設定は、サーバ１００にて各監視終了条件を登録することで行う。
サーバ１００は、データ送受信部１０６により顧客先２０の全機器２０（１）〜２０（ｎ）に対して、先行アップグレード対象かどうかの情報及び監視終了条件の情報を通知する（Ｓ１０３）。なお、先行アップグレード対象の機器及び監視終了条件は、サーバ１００から設定する。

ここで、ファームウェアのアップグレードの発生（実行）前であれば、顧客先２０で機器２０（１）〜２０（ｎ）の図示しない入力手段を操作することによって、先行アップグレード対象、監視終了条件の変更を行うことができる。ユーザが監視終了条件を変更したときは、機器２０（１）〜２０（ｎ）は、それをネットワーク３０経由でサーバ１００に通知する。
また、同様に、ファームウェアのアップグレード発生（実行）前であれば、監視終了条件のサーバ１００からの変更も可能である。なお、監視終了条件の詳細は図５を参照して後述する。

図４は、本システムにおけるファームウェアアップグレード開始から終了までの処理手順を説明するフロー図である。
即ち、サーバ１００は、まず、データ送受信部１０６により指定された先行アップグレードを行う機器（先行アップグレード機器という）に対してファームウェアファイルを送信する（Ｓ２０１）。
先行アップグレード機器は、受信したファームウェアファイルでファームウェアをアップグレードする（Ｓ２０２）。なお、アップグレード自体に失敗した場合はアップグレード直前のファームウェアにリカバリする。

ステップＳ２０２で先行アップグレード機器がアップグレードした後、サーバ１００の機器状態監視部１０７は、先行アップグレードした機器を監視する（Ｓ２０３）。即ち、サーバ１００（の機器状態監視部１０７）は、機器からのＳＮＭＰ（Simple Network Management Protocol）などによる通報を待つ。
ここで、ステップＳ２０３の監視中にサービスコールが通知されたときは（Ｓ２０４、ＹＥＳ）、サーバ１００のファームウェア不具合判断部１０４は、発生したサービスコールの不具合調査が必要か否か判断する（Ｓ２０７）。なお、判断方法の詳細は図６を参照して後述する。
ステップＳ２０４でサービスコール（通知）がない場合は（Ｓ２０４、ＮＯ）、サーバ１００の先行アップグレード機器監視管理部１０８は、先行アップグレード機器の機器状態が監視終了条件を満たしているか否か判定する（Ｓ２０５）。

ステップＳ２０５で、先行アップグレード機器監視管理部１０８が、前記機器状態について監視終了条件を満たしていると判断したときは（Ｓ２０５、ＹＥＳ）、サーバ１００は、先行アップグレードしなかった残りの機器のファームウェアをアップグレードする処理を行う（Ｓ２０６）。即ち、サーバ１００は残りの機器に対してデータ送受信部１０６でファームウェアファイルを送信し、残りの機器はファイルを受信するとファームウェアをアップグレードし、ファームウェアアップグレード処理を終了する。
ステップＳ２０５で、サーバ１００（の先行アップグレード機器監視管理部１０８）が監視終了条件を満たしていないと判断したときは（Ｓ２０５、ＮＯ）、ステップＳ２０３へ戻り、引き続き先行アップグレード機器を監視する。

ステップＳ２０４でサービスコール（の通知）があるときは（Ｓ２０４、ＹＥＳ）、不具合調査が必要か否か判断し（Ｓ２０７）、サーバ１００の先行アップグレード機器監視管理部１０８は、ステップＳ２０７で、ファームウェア不具合判断部１０４が、発生したサービスコールの不具合調査が必要（つまり、サーバ１００内のデータベース１０１に記録された原因・解決方法だけでは判断できない）と判断したときは（Ｓ２０７、ＹＥＳ）、調査依頼通知部１０５によりサービス・設計区２００へ不具合調査および対応を依頼して（Ｓ２０８）、サーバ１００での本システムの監視処理自体を終了してサービス・設計区２００による調査を待つ。この際、ＳＤカードによるダウングレードを行うことで以前のバージョンに戻し、機器を利用することができる。

ステップＳ２０７で、ファームウェア不具合判断部１０４がサービスコールの不具合調査が必要でなく（Ｓ２０７、ＮＯ）、発生したサービスコールの不具合がファームウェアに起因する不具合と判断したときは（Ｓ２０９、ＹＥＳ）、サーバ１００の調査依頼通知部１０５で、サービス・設計区２００へ不具合調査および対応を依頼する（Ｓ２１０）。その後、サーバ１００はデータ送受信部１０６を介して、機器に対して正常に動作していたファームウェアを送信し、機器をダウングレードして（ステップＳ２１１）、ファームウェアアップグレード処理を終了する。

ステップＳ２０９で、ファームウェア不具合判断部１０４がファームウェアの不具合ではないと判断したときは（Ｓ２０９、ＮＯ）、サーバ１００はデータ送受信部１０６を介して、データベース１０１の記録内容に基づき当該機器へサービスコールの対応方法を送信し（ステップＳ２１２）、ステップＳ２０３に戻り、それ以降の前記処理を行う。

図５は、本実施形態における予め設定する監視終了条件の一例について説明する図である。
ここでは、機器はプリンタとし、終了条件は、印刷終了日時として２０１２年３月１日、印刷枚数は１００，０００枚、ＵＩ（ユーザインターフェース）操作回数は指定なし、アップグレード対象機能の使用回数とし、２穴パンチ（上）として１００回、２ステープル（上）として２００回、二つ折りは指定なし、等が監視終了条件として設定されている。

先行アップグレード機器の監視を終了する条件としては、図５に記載された条件を組み合わせて使用する。即ち、終了日時では、監視終了予定の日時を指定する、指定した日時（２０１２年３月１日）になれば条件達成となる。印刷枚数では、アップグレード後の印刷枚数を指定する。指定した枚数の印刷が行われると条件達成となる。
ＵＩ操作回数では、アップグレード後のＵＩでの操作回数を指定する。指定した回数ＵＩ操作が行われると条件達成となる。

アップグレード対象機能の使用回数では、アップグレードで変更が発生した機能の使用回数を指定する。指定した回数だけ該当する機能が使用されると条件達成となる。アップグレード対象機能の使用回数については、複数の機能がある場合には、各機能別に使用回数を設定することができるようにしている。これにより、顧客が使用しない機能を監視終了条件としてしまい、先行アップグレードの監視が終了しない、という状況を回避することができる。

また、各条件には図示のような要求レベルを設定する。
要求レベル：
「ＭＵＳＴ」
「ＷＡＮＴ」
「ＭＵＳＴ」に指定した条件は必須条件となり、この条件が達成されていないと本システムによる監視の自動終了も顧客による途中終了もできない。
「ＷＡＮＴ」に指定した条件は必要条件となり、この条件が達成されていないと本システムによる監視の自動終了はできないが、「ＭＵＳＴ」が指定されている条件を全て達成していれば顧客は監視を途中終了させることができる。

図５に示した例では、期間、印刷枚数、アップグレード対象機能（２穴パンチ（上）および２ステープル（上））の使用回数の３条件が全て達成された場合に監視終了とすることができる。また、印刷枚数は要求レベルが「ＷＡＮＴ」であるため、印刷枚数以外の「ＭＵＳＴ」条件が達成されていれば、顧客は先行アップグレード機器の監視を途中終了させることができる。

図６は、本実施形態におけるサービスコールとその原因・解決方法を持つデータベースの内容例について説明する図である。
各サービスコールはサービスコールＩＤ、サービスコール名、サービスコールの詳細、サービスコール種別、サービスコールに関係する機能名、サービスコールの解決方法を持っている。
サービスコールＩＤは、各サービスコールを一意に識別可能なＩＤが振られている。

サービスコール名は、各サービスコールを簡潔に表す名前が設定されている。
サービスコール名には、図６に示すように、ＨＤＤ異常、ＳＤカード異常など、各サービスコールの内容を簡単に説明する文章が設定されている。
詳細には、ＨＤＤへのアクセスでエラー発生など、エラー発生部位が列挙されている。
サービスコール種別は、各サービスコールの種類を表す、表中の例では致命的なサービスコールとログを採取するロギングサービスコールがある。
関係機能名は、各サービスコールが関係する機能の名前、例えばハードウェアなどが設定されている。
解決方法には、例えば、機器再起動、５回連続で本ＳＣ（サービスコール）が発生する場合は、ＨＤＤ交換又はサービス要員への連絡など、顧客がサービスコールを解消するために行うべき項目が列挙されている。

機器２０（１）〜２０（ｎ）からサーバ１００へサービスコールが通知されると、データベース１０１の内容を参照し、解決方法をユーザへ通知する。解決方法がデータベース１０１内に存在しない場合や解決方法の最下行に記載されている条件（即ち、サービス要員へ連絡）に当てはまった場合は、本システムはそのサービスコールに関して不具合調査が必要と判断する。

図７は、本実施形態におけるサービスコール発生時の、サーバ１００が行うファームウェアに不具合があるかどうかの判断手順について説明するフロー図である。
サーバ１００は、機器２０（１）〜２０（ｎ）から送信されたサービスコールの情報から、データベース１０１内のサービスコールの情報を照合する（Ｓ３０１）。

ステップＳ３０１の照合結果から、発生したサービスコールと同様のサービスコールが所定の短期間に複数回発生しているかチェックする（Ｓ３０２）。機器２０（１）〜２０（ｎ）から送信されるサービスコールの情報として、サービスコールの履歴があり、短期間に複数回発生の基準にはこれを利用する（例えば：最新１０回のサービスコールの履歴が送信された場合、そのうち７割以上が同じサービスコールである場合、または最新５回連続で同じサービスコールである場合など、各サービスコール毎の情報がデータベース１０１内に記録されている）。

ステップＳ３０２で、同様のサービスコールが所定の短期間に複数回発生していない場合は（Ｓ３０２、ＮＯ）、ファームウェア不具合判断部１０４は、ユーザがリカバリ不可能かつ致命的なサービスコールであるか否かをチェックする（Ｓ３０３）。
ステップＳ３０２で、同様のサービスコールが所定の短期間に複数回発生している場合は（Ｓ３０２、ＹＥＳ）、ファームウェア不具合判断部１０４が、ファームウェアアップグレードで変更の入った機能で発生したサービスコールか否かをチェックする（Ｓ３０４）。

ステップＳ３０３で、ファームウェア不具合判断部１０４が、ユーザがリカバリ可能でかつ致命的なサービスコールではないと判断した場合は（Ｓ３０３、ＮＯ）、ファームウェアの不具合ではないと判断する（Ｓ３０５）。ファームウェア不具合判断部１０４が、ユーザがリカバリ不可能でかつ致命的なサービスコールであると判断した場合は（Ｓ３０３、ＹＥＳ）、不具合調査が必要と判断し（Ｓ３０６）、サービスや設計など、人手による調査を実施するため、各窓口へ調査依頼を通知（又は報告）する。

ステップＳ３０４で、ファームウェア不具合判断部１０４が、発生したサービスコールがファームウェアアップグレードで変更の入った機能に関するサービスコールであると判断した場合は（Ｓ３０４、ＹＥＳ）、ファームウェアの不具合と判断して（Ｓ３０７）、発生したサービスコールがファームウェアに起因する不具合かどうかの判断を終了する。
ステップＳ３０４で、ファームウェア不具合判断部１０４が、ファームウェアアップグレードで変更の入った機能に関するサービスコールではないと判断したときは（Ｓ３０４、ＮＯ）、不具合調査が必要と判断し（Ｓ３０６）、発生したサービスコールがファームウェアに起因する不具合かどうかの判断を終了する。

図８は、本実施形態における先行アップグレード機器監視管理部１０８による監視終了判定の事例について説明する図である。
図８の事例では、監視終了条件におけるアップグレード対象機能が２穴パンチ（上）、２ステープル（上）、二つ折りで、各監視終了条件は以下の値とする。即ち、
終了日時： ２０１２／０３／０１
印刷枚数： １００，０００枚
UI操作回数： 指定なし
アップグレード対象機能の使用回数：
２穴パンチ（上）： １００回
２ステープル（上）： ２００回
二つ折り： 指定なし
現在の値が図８Ａの状況から、２００枚のジョブ完了、その後３０枚２ステープル（上）のジョブ完了が機器から通知された場合の事例とする。

図８Ａの状態で２００枚のジョブ完了を受信すると、システムは現在の値を更新し（図８Ｂ）、監視終了判定を行う。
印刷枚数は９９，８００枚から１００，０００枚となり、監視終了条件を満たすが、２ステープル（上）の監視終了条件を満たしていないため監視を継続する。

図８Ｂの状態で３０枚２ステープル（上）のジョブ完了を受信すると、システム（機器状態監視部１０７）は現在の値を更新し（図８Ｃ）、監視終了判定を行う。
２ステープル（上）は１９９回から２００回となり、監視終了条件を満たす。ここで、図８Ｃのすべての条件において監視終了条件を達成しているため、システムは監視を終了する。

なお、先行アップグレードに指定された機器は、前記監視終了条件のうち要求レベルが必須（ＭＵＳＴ）に設定されているものが全て達成されたとき、ユーザによる監視の途中終了の指示を受け付けて監視終了要求を前記サーバへ通知する手段を有している。サーバ１００は、先行アップグレード機器からの監視終了要求を受け付けると、サーバで保持する監視終了条件と現時点での状態を対比して両者に不整合がない、つまり必須に設定されている監視終了条件が全て達成されていることを条件に、監視を終了する手段（利用者は監視中に先行アップグレード機器の状態を調べ、それと設定された監視終了条件とを比較して、監視終了条件のうち要求レベルがＭＵＳＴに設定されているものが全て達成されていることを確認したとき、操作する図示しない、例えば監視終了ボタン）を有する。
なお、ここで、不整合の状態としては、例えば、機器側が保持する監視終了条件のその時点での値と、サーバ側が保持する同条件の値にネットワークエラーによる同期失敗など何らかの要因で食い違いが発生し、機器側ではＭＵＳＴ項目が全て達成されているが、サーバ側ではＭＵＳＴ条件に達成されていないものがある状態がある。

以上、本実施形態では、ファームウェアのアップグレードに例を採って説明したが、本発明は、例えば、アプリケーションなどのプログラムをアップグレードする場合にも適用可能である。
また、前記サーバが持つサービスコールのデータベースの内容、監視終了条件、アップグレード対象機能などの情報をカスタマイズすることで、本発明を多くの機器へ適用することができる。

１０・・・サービス提供元、２０・・・納入先、２０（１）〜２０（ｎ）・・・機器、３０・・・ネットワーク、１００・・・サーバ、１０１・・・サービスコールとその原因と解決方法を記録したデータベース、１０２・・・先行アップグレードした機器の監視終了条件を記録したデータベース、１０３・・・対象ファームウェアでのアップグレード対象機能を記録紙データベース、１０４・・・ファームウェア不具合判断部、１０５・・・調査依頼通知部、１０６・・・データ送受信部、１０７・・・機器状態監視部、１０８・・・先行アップグレード機器監視管理部、１０９・・・ユーザインターフェース、２００・・・サービス・設計区。

特表２００９−５３０６９４号公報

Claims (9)

1. 複数台の機器とネットワークで接続し前記機器のプログラムのアップグレードを実施するサーバであって、
   プログラムのアップグレードを実施する手段と、
   前記複数台の機器のうち、先行してプログラムのアップグレードを実施する機器を指定する手段と、
   先行してプログラムのアップグレードを実施した前記指定した機器の状態が予め設定した監視終了条件を満たすまで当該機器の状態を監視する手段と、
   を有し、
   前記監視する手段が前記指定した機器の状態が前記監視終了条件を満たしたと判断したことを条件に、前記指定した機器以外の機器に対してプログラムのアップグレードを実施するサーバ。
2. 請求項１に記載されたサーバにおいて、
   機器の不具合とその原因及び解決方法を記録したデータベースを有し、
   先行アップグレードした機器の状態を監視する手段による監視中に前記機器に不具合が発生したとき、不具合がアップグレードしたプログラムに起因するものか否か判断する手段を有し、
   不具合がアップグレードしたプログラムに起因するものであるときは、前記監視する手段による監視を終了して先行アップグレードした機器をダウングレードし、不具合がプログラムに起因するものでないときは、前記データベースに基づき不具合の解決方法を前記機器に通知するサーバ。
3. 請求項１又は２に記載されたサーバにおいて、
   前記監視する手段は、前記機器から通知される機器情報と予め設定した監視終了条件とに基づき監視終了を判断するサーバ。
4. 請求項１ないし３のいずれかに記載されたサーバと、前記サーバからプログラムを取得して実行する前記機器からなるプログラムのアップグレードシステムであって、
   前記サーバは、ネットワーク経由で指定した先行アップグレード機器にプログラムを送信する手段を有し、
   前記先行アップグレード機器は受信したプログラムを保存する手段と、前記プログラムでアップグレードを行う手段を有するプログラムのアップグレードシステム。
5. 請求項４に記載されたプログラムのアップグレードシステムにおいて、
   前記サーバは、ネットワーク経由で先行アップグレード対象かどうかの情報、前記監視終了条件の情報及び現時点での当該機器の機器状態情報を機器に通知する手段を有し、
   前記機器は受信した前記情報を保持する手段を有し、
   前記機器は、サーバから受信した前記情報をユーザに通知する手段と、ユーザによる前記監視終了条件の変更をネットワーク経由でサーバに通知する手段を有するプログラムのアップグレードシステム。
6. 請求項５に記載されたプログラムのアップグレードシステムにおいて、
   前記機器は、アップグレード開始時、アップグレード中、アップグレード終了時それぞれに対応した表示を行う表示手段を有する、
   プログラムのアップグレードシステム。
7. 請求項５又は６に記載されたプログラムのアップグレードシステムにおいて、
   先行アップグレードに指定された機器は、前記監視終了条件のうち要求レベルが必須に設定されているものが全て達成されたとき、ユーザによる監視の途中終了を受け付けて監視終了要求を前記サーバへ通知する手段を有し、
   前記サーバは、機器からの監視終了要求を受け付け、サーバで保持する監視終了条件と現時点での状態に不整合がないことを条件に、監視を終了する手段を有する、
   プログラムのアップグレードシステム。
8. 複数台の機器とネットワークで接続し、前記機器のプログラムのアップグレードを実施するサーバにおけるプログラムのアップグレード方法であって、
   前記複数台の機器のうち、先行してプログラムのアップグレードを実施する機器を指定する工程と、
   指定した機器に対してプログラムのアップグレードを実施する工程と、
   指定した機器のプログラムのアップグレード後の状態が予め設定した監視終了条件を満たすまで、監視する工程と、
   前記監視する手段が指定した機器の状態が前記監視終了条件を満たしたと判断したことを条件に、前記指定した機器以外の機器に対してプログラムのアップグレードを実施する工程と、
   を有するサーバにおけるプログラムのアップグレード方法。
9. 請求項８に記載されたプログラムのアップグレード方法の各工程を、サーバで実行させるためのプログラム。
   

Images