JP2014164553A - 配信システム、配信システムの配信方法 - Google Patents

Abstract

【課題】リモートでのプログラム配信が可能なネットワークデバイスで障害が発生した場合でも、リブートコマンドを用いることなく、リモートからネットワークデバイスを再起動して障害を解消すること。
【解決手段】配信サーバ１３３は、ネットワークデバイスから障害情報を取得し（Ｓ１５０１）、該障害情報の種別を特定し（Ｓ１５０３）、該障害情報の種別が第１の種別であった場合には、当該障害を前記ネットワークデバイスのリブートにより解消させるために、前記ネットワークデバイスに既に配信されたプログラムと同一のプログラムを、差分配信で前記ネットワークデバイスに配信し（Ｓ１５０４〜Ｓ１５０７，Ｓ１５１０）、また、該障害情報の種別が第２の種別であった場合には、前記ネットワークデバイスに既に配信されたプログラムと同一のプログラムを、上書き配信で前記ネットワークデバイスに配信する（Ｓ１５０４〜Ｓ１５０７，Ｓ１５１１）。
【選択図】図１５

Description

本発明は、ネットワークデバイスとインターネットを介して接続する配信システム、配信システムの配信方法に関するものである。

従来、ネットワークデバイス（例えば、画像形成装置）のファームウェアのアップデートは、機能アップもしくは障害等の理由により更新する必要が生じた場合に行われる。アップデート方法としては、インターネット経由で配信サーバから配信を行う方法がある。配信サーバでデバイスのファームウェアのアップデートを行う場合、Ｗｅｂ画面で配信対象のデバイスを指定し、配信日時を設定して、インターネット経由で配信を行う。
このような状況において、配信サーバでアップデートしたデバイスで障害が発生する場合がある。その原因として多いのが、再起動などで復旧するエラーである。

特許文献１には、デバイスで障害が発生した際に、リカバリ用のファームウェアをデバイスの内部に持つことで、解決するシステムが提案されている。特許文献１は、デバイスで障害が発生した際に、デバイス内に予め保存してあるファームウェアを適用し、デバイスを復旧するものである。

特開平５−１５１００９号公報

上述のように、配信サーバでファームウェアをアップデートしたデバイスにエラーが発生した場合、再起動などでデバイスが復旧するケースがある。しかし、現状では、インターネットを介した通信では、ファイアウォールの外からリブートコマンドをファイアウォール内のデバイスに送信することは、セキュリティの問題等で行われておらず、インターネットを介してリモートでデバイスを再起動することができない。このため、サービスマンが出動することとなり、サービスコストが大きくなっている。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、リモートでのプログラム配信が可能なネットワークデバイスで障害が発生した場合でも、リブートコマンドを用いることなく、リモートからネットワークデバイスを再起動して障害を解消することができる仕組みを提供することである。

本発明は、ネットワークデバイスとインターネットを介して接続する配信システムであって、ネットワークデバイスから障害情報を取得する取得手段と、前記障害情報の種別を特定する特定手段と、前記障害情報の種別が第１の種別であった場合には、当該障害を前記ネットワークデバイスのリブートにより解消させるために、前記ネットワークデバイスに既に配信されたプログラムと同一のプログラムを、前記ネットワークデバイスに既に配信されたプログラムとの差分のみを配信する差分配信で、前記ネットワークデバイスに配信し、また、前記障害情報の種別が第２の種別であった場合には、前記ネットワークデバイスに既に配信されたプログラムと同一のプログラムを、前記ネットワークデバイスに既に配信されたプログラムを含めて配信する上書き配信で、前記ネットワークデバイスに配信する配信手段と、を有することを特徴とする。

本発明によれば、リモートでのプログラム配信が可能なネットワークデバイスで障害が発生した場合でも、リブートコマンドを用いることなく、リモートからネットワークデバイスを再起動して障害を解消することができる。

配信システムを含むシステムの全体構成を示す図。 監視センタホスト、配信サーバ等のハードウェア構成図。 デバイスのハードウェア構成図。 監視センタホスト、配信サーバ等における通信部分のソフトウェア構成図。 監視装置や各デバイスにおける通信部分のソフトウェア構成図。 本発明を実施したシステムの一例を示す図。 エラーコードとケースの紐づけテーブル及びエラーの種別と配信サーバの対応テーブルを示す図。 デバイス機種別の管理ファームバージョンテーブルを示す図。 デバイス毎のファームウェア動作実績テーブルを示す図。 本発明におけるシーケンス図。 監視装置の処理を示すフローチャート。 監視センタホストの処理を示すフローチャート。 クライアントモジュールの処理を示すフローチャート。 配信サーバのファームウェア配信処理を示すフローチャート。 配信サーバの再配信予約設定処理を示すフローチャート。

以下、発明を実施するための形態について図面を用いて説明する。

図１は、本発明の一実施例を示す配信システムを含むシステムの全体構成の一例を示す図であり、複数のシステムが接続されている。
操作システム１０１では、ホスト１０２、データベース１０３、ＰＣ１０４が、ＬＡＮ１０５で接続されており、ＬＡＮ１０５はインターネット１３２に接続されている。ＰＣ１０４は、データベース１０３へのデータ登録や修正などの制御を行なうためのものである。また、ＰＣ１０４は、監視センタホスト１１１、配信サーバ１３３が提供するＷｅｂサイトへアクセスしてデータの閲覧及び、ファームウェアの配信予約等を行うことができる。なお、図１では、操作システム１０１には、複数の装置から構成されるよう示されているが同等機能を達成できれば同一の構成でなくてもよい。例えば、データベース１０３は、物理的にホスト１０２内に存在してもよい。さらに、データベース１０３は、ホスト１０２からアクセス可能であれば、インターネット１３２を経由した別の場所に存在しても構わない。つまり、操作システム１０１には、複数の装置から構成されるようにしてもよいし、１つの装置から構成するようにしてもよい。

外部システム１０６では、ホスト１０７、データベース１０８が、ＬＡＮ１０９で接続されており、ＬＡＮ１０９はインターネット１３２に接続されている。外部システム１０６は、配信サーバ１３３のファームウェアを高速に配信するためサービスを提供する。

次に、監視センタホスト１１１について説明する。監視センタホスト１１１は、後述する監視装置からネットワークデバイスの稼働情報を受信し、データベース１１２に蓄積するデバイス監視システムである。データベース１１２は、監視のための情報や、デバイスの稼働状態などを蓄積する履歴記憶部としてのデータベースである。監視センタホスト１１１とデータベース１１２は、ＬＡＮ１１３で接続されており、ＬＡＮ１１３はインターネット１３２に接続されている。なお、データベース１１２は、物理的に監視センタホスト１１１内に存在してもよい。さらに、データベース１１２は、監視センタホスト１１１からアクセス可能であれば、インターネットを経由した別の場所に存在しても構わない。監視センタホスト１１１は、監視装置１１７、１２２、１２３やデバイス１３１から監視対象としてのデバイスの情報、稼働状態を示す情報を収集、蓄積、加工し、警告等を外部に提供する機能を有する。

次に、配信サーバ１３３ついて説明する。配信サーバ１３３は、データベース１３４に格納されたファームウェアをネットワークデバイス（以下、デバイス）に配信するファームウェア配信システムである。データベース１３４は、デバイスに適用するためのファームウェアを蓄積する記憶部としてのデータベースである。配信サーバ１３３とデータベース１３４は、ＬＡＮ１３５で接続されており、ＬＡＮ１３５はインターネット１３２に接続されている。なお、データベース１３４は、物理的に配信サーバ１３３内に存在してもよい。さらに、データベース１３４は、配信サーバ１３３からアクセス可能であれば、インターネット１３２を経由した別の場所に存在しても構わない。なお、ＬＡＮ１１３とＬＡＮ１３５は同一のＬＡＮでもよく、データベース１３４とデータベース１１２はデータを送受信しても構わない。

図１には、監視センタホスト１１１およびデータベース１１２と、配信サーバ１３３およびデータベース１３４が１つずつしか示されていない。しかし、実際には、多くのデバイスおよび監視装置からの情報収集や、ファームウェア配信の負荷分散を行なうために、それぞれ複数の監視センタホスト１１１、データベース１１２、配信サーバ１３３、データベース１３４に分散処理をさせるケースもある。

次に、顧客側のシステム構成について説明する。顧客側のシステムは、顧客により構成が異なる。図１の例では、顧客システム１１４、１１９、１２９が示されている。
顧客システム１１４（Ａ社Ｘ事業所）においては、デバイス１１５、１１６、監視装置１１７が、インターネット１３２に接続されたＬＡＮ１１８に接続されている。監視装置１１７は、デバイス１１５、１１６を監視し、インターネット１３２経由で、デバイス１１５、１１６の稼働情報を監視センタホスト１１１に送信している。一方、顧客システム１１９（Ａ社Ｙ事業所）においては、デバイス１２０、１２１、１２４〜１２７、監視装置１２２、１２３が、インターネット１３２に接続されたＬＡＮ１２８に接続されている。監視装置１２２、１２３は、ＬＡＮ１２８上のデバイス１２０、１２１、１２４〜１２７を管理している。監視装置１２２は、デバイス１２０、１２１、１２４、１２５を監視し、インターネット１３２経由で、デバイス１２０、１２１、１２４、１２５の稼働情報を監視センタホスト１１１に送信している。監視装置１２３は、デバイス１２６、１２７を監視し、インターネット１３２経由で、デバイス１２６、１２７の稼働情報を監視センタホスト１１１に送信している。

顧客１２９システム（Ｂ社）においては、インターネット１３２に接続されたＬＡＮ１３０に接続されたデバイス１３１自身が、直接インターネット１３２経由で監視センタホスト１１１と通信している。デバイス１３１は、監視装置１１７、１２２、１２３と同等の機能を有しており、自身の稼働情報を監視センタホスト１１１に送信している。

図２は、監視センタホスト１１１、配信サーバ１３３、ホスト１０２、監視装置１１７、１２２、１２３、ＰＣ１０４のハードウェア構成の一例を示す図である。
図２において、ＣＰＵ２０１は、本装置上の各処理を司る。書換え不可能なＲＯＭ２０２は、本装置の各処理に関わるプログラムやデータを記憶する。ＲＡＭ２０３は、本装置の各処理に関わる一時的なデータを電気的に記憶でき、かつ書き換え可能である。

ＨＤＤ２０４は、本装置の各処理に関わるプログラムやデータ、および一時的なデータ等の各種データを記憶する。監視センタホスト１１１の場合、監視対象のデバイスに関する情報、およびデバイスから収集した情報（例えば、デバイスの稼働情報）などをＨＤＤ２０４に記憶する。また、監視センタホスト１１１の場合、後述する図４の処理を行うプログラムをＨＤＤ２０４に記憶している。このプログラムは、ＲＡＭ２０３を一時保存領域として使用し、ＣＰＵ２０１によって呼び出され実行される。また、配信サーバ１３３の場合も同様に、後述する図４の処理を行うプログラムをＨＤＤ２０４に記憶している。なお、ＨＤＤ２０４は、ハードディスクに限定されるものではなく、ＳＳＤ（Solid State Drive）等の他の記憶装置であってもよい。

操作部２０５は、本装置への指示入力を受け付けるものであり、例えばキーボードやポインティングデイバイス等である。表示部２０６は、本装置の動作状況や、本装置上で動作する各プログラムが出力する情報を表示する。ＮｅｔｗｏｒｋＩ／Ｆ２０８は、ネットワーク経由でＬＡＮおよびインターネットに接続し、外部と情報交換を行う。外部機器Ｉ／Ｆ２０７は、外部記憶機器等を接続するためのものであり、例えば、ＵＳＢ Ｉ／Ｆ等である。なお、上述したこれら要素２０１〜２０８がシステムバス２０９により結び付き、データをやりとりしている。

図３は、デバイス１１５、１１６、１２０、１２１、１２４、１２５、１２６、１２７、１３１の構成の一例を示す図である。
まず、図３（ａ）を用いて、デバイスのハードウェア構成の一例を説明する。
デバイスとしては、例えば、プリンタ及びファクシミリ機能が統合的に設けられた複合機、ＰＣなどからデータを受信し印刷するプリンタ（電子写真方式及びインクジェット方式を含む）や、スキャナや、ファクシミリなどの画像形成装置が挙げられるが、これらに限定されるものではなく各種ネットワークデバイスを適用可能である。本図では、デバイスの一例として複合機の構成を示している。

イメージリーダ３０２は、原稿給送部３０１で給送された原稿から画像データを読み取る。画像形成部３０３は、イメージリーダ３０２で読み込んだ原稿の画像データやＮｏｔｗｏｒｋＩ／Ｆ３０５からネットワーク経由で受信したデータを印刷画像に変換・印刷出力する。排紙部３０４は印刷出力した紙を排出し、ソートやステイプルといった処理を施す。

ＮｅｔｗｏｒｋＩ／Ｆ３０５は、ネットワーク経由でＬＡＮおよびインターネットに接続し、外部と情報交換を行う。ＣＰＵ３０６は、本装置上の各処理を司る。ＣＰＵ３０６は、デバイスの動作状態を監視し、障害等の特定のイベントが発生した場合には、その状態を示す状態情報を、あらかじめ定めた宛先へと送信する制御を行う。なお、送信の宛先は、例えば、監視センタホスト１１１や監視装置などである。

書換え不可能なＲＯＭ３０７は、本装置の各処理に関わるプログラムやデータを記憶する。ＲＡＭ３０８は、本装置の各処理に関わる一時的なデータを電気的に記憶でき、かつ書き換え可能である。ＨＤＤ３０９は、本装置の各処理に関わるプログラムやデータ、および一時的なデータ、本装置へ送信されてきたユーザデータなどを記憶する。デバイスは、後述する図５の処理を行うプログラムをＨＤＤ３０９に記憶している。このプログラムは、ＲＡＭ３０８を一時保存領域として使用し、ＣＰＵ３０６によって呼び出され実行される。なお、ＨＤＤ３０９は、ハードディスクに限定されるものではなく、ＳＳＤ（Solid State Drive）等の他の記憶装置であってもよい。

操作部３１０は、本装置への指示入力を受け付ける。表示部３１１は、本装置の動作状況および操作部３１０に対する操作に関わる情報を表示する。そして、上述したこれら要素３０１〜３１１がシステムバス３１２により結び付き、データをやりとりしている。
なお、デバイス自身が監視のための情報を送信する機能を持つデバイス１３１では、ＲＯＭ３０７或いはＨＤＤ３０９内に、前記監視データ送出処理にかかわるプログラムやデータを保持している。

次に、図３（ｂ）を用いて、デバイス内のクライアントモジュール３１３について説明する。
クライアントモジュール３１３とは、デバイス内のモジュールであり、監視センタホスト１１１や配信サーバ１３３と通信し、配信サーバ１３３からファームウェアをダウンロードし、デバイスにインストールする役割を持つ。クライアントモジュール３１３は、ＨＤＤ３０９に記憶されＣＰＵ３０６で実行される。

図４は、監視センタホスト１１１、配信サーバ１３３における通信部分のソフトウェア構成の一例を示す図である。
ＳＯＡＰ通信部４０１は、監視装置１１７、１２２、１２３またはデバイス１３１より、ＮｅｔｗｏｒｋＩ／Ｆ２０８を介して受信したＳＯＡＰデータを、ＳＯＡＰメッセージ解析部４０２に渡す。また、ＳＯＡＰ通信部４０１は、ＳＯＡＰメッセージ作成部４０３により作成されたＳＯＡＰデータを、ＮｅｔｗｏｒｋＩ／Ｆ２０８を介して監視装置１１７、１２２、１２３またはデバイス１３１に送信する。ＳＯＡＰメッセージ解析部４０２は、ＳＯＡＰ通信部４０１から渡されたＳＯＡＰデータを解析する。ＳＯＡＰメッセージ作成部４０３は、ＳＯＡＰデータを作成する。

収集情報処理部４０４では、監視装置１１７、１２２、１２３またはデバイス１３１から受信した情報をそのまま、または加工し、データベースアクセス部４０６を介してデータベース１１２、あるいはデータベース１３４に格納する。
監視制御部４０５は、監視センタホスト１１１においては、監視装置１１７、１２２、１２３またはデバイス１３１のスケジュール管理などの制御を行なう。また、監視制御部４０５は、配信サーバ１３３においては、監視装置１１７、１２２、１２３またはデバイス１３１のポーリング処理などの制御を行う。

図５は、監視装置１１７、１２２、１２３またはデバイス１３１内の通信部分のソフトウェア構成の一例を示す図である。
ＳＯＡＰ通信部５０１は、監視センタホスト１１１もしくは配信サーバ１３３により、ＮｅｔｗｏｒｋＩ／Ｆ２０８を介して受信したＳＯＡＰデータを、ＳＯＡＰメッセージ解析部５０３に渡す。また、ＳＯＡＰ通信部５０１は、ＳＯＡＰメッセージ作成部５０２により作成したＳＯＡＰデータを、ＮｅｔｗｏｒｋＩ／Ｆ２０８を介して監視センタホスト１１１や配信サーバ１３３に送信する。

ＳＯＡＰメッセージ解析部５０３は、ＳＯＡＰ通信部５０１から渡されたＳＯＡＰデータを解析する。ＳＯＡＰメッセージ作成部５０２は、ＳＯＡＰデータを作成する。
監視制御部５０４は、情報蓄積部５０６に保持する監視対象のデバイス情報の更新や、デバイス１１５、１１６の情報取得を行なう。デバイス情報処理部５０５は、デバイスの稼働情報を、情報蓄積部５０６に蓄積する。情報蓄積部５０６に蓄積したデータは、デバイス情報処理部５０５を介してそのままＳＯＡＰメッセージ作成部５０２に渡され、ＳＯＡＰ通信部５０１を介して監視センタホスト１１１へ送信される。

ここで、監視センタホスト１１１、配信サーバ１３３或いは、監視装置１１７、１２２、１２３或いは、各デバイスにおけるメモリ構成について説明する。
監視センタホスト１１１、配信サーバ１３３或いは、監視装置１１７、１２２、１２３或いは、各デバイスでは、本発明に係る処理プログラムを実行する際、ＣＰＵが、ＲＡＭ上にプログラムをロードして実行する。ＲＡＭ上には、基本Ｉ／Ｏプログラム、システム・プログラム、本実施例の処理プログラムを初めとする各種処理プログラム、関連データを格納するエリア、プログラムのワークエリア等の記憶エリアが確保される。なお、上述した基本Ｉ／Ｏプログラムは、本装置上の入出力を司る。また、システム・プログラムは、各処理プログラムに動作環境を提供するものである。

図６は、本発明を実施したシステムの一例を示す図である。
７０１、７０２、７０３は、顧客に設置されたデバイスを示す。デバイス７０１、７０２、７０３は全て、クライアントモジュール３１３をデバイスに内蔵している。７０１、７０２、７０３は、それぞれデバイス固有の番号であるシリアルＮｏ.を持つ。

監視センタホスト１１１は、インターネット１３２を介して、デバイス７０１、７０２、７０３から通知されたデバイスの稼働状態などを、データベース１１２に蓄積する。配信サーバ１３３は、データベース１３４に格納されたファームウェアなどを、インターネット１３２を介して、デバイス７０１、７０２、７０３に配信する。
また、配信サーバ１３３は、図７、図８、図９に示すテーブルをデータベース１３４に有し、デバイス７０１、７０２、７０３で発生した障害に対処する。

図７は、エラーコードとケースの紐づけテーブル８０１、エラーの種別と配信サーバの対応テーブル８０５の一例を示す図である。
テーブル８０１において、８０２は、配信サーバ１３３が受信するエラーコードを示す。８０３は、エラーコード８０２の概要を示す。８０４は、エラーコード８０２に対応したケースを示す。

テーブル８０５において、８０６は、配信サーバ１３３の対応ケースを示す。８０７は、エラーケースの分類を示す。８０８は、ケース８０６における配信サーバの対応として、配信対象のファームウェアを示す。８０９は、ケース８０６における配信サーバの対応として、配信方法を「上書き配信」とするか、「差分配信」とするかを示す。
配信サーバ１３３は、ネットワークデバイスにプログラムを配信する場合に、前記ネットワークデバイスに既に配信されたプログラムとの差分のみを配信する「差分配信」、前記ネットワークデバイスに既に配信されたプログラムを含めて配信する「上書き配信」等の配信方法で、配信する機能を有する。

なお、クライアントモジュール３１３は、差分配信によるファーム構成の更新が可能である。配信サーバ１３３は、更新すべきプログラムを含む複数のプログラムを含むグループをデバイスに差分配信する場合、該デバイスの現在のファーム構成との差分となる当該グループに含まれるプログラムだけを、該デバイスに送信する。該デバイスのクライアントモジュール３１３は、配信サーバ１３３から実際に送信されたプログラムのみを用いて該デバイスのファーム構成を更新する。このため、配信サーバ１３３から既に該デバイスに適用されているプログラムと同一プログラムのみが含まれるグループが該デバイスに差分配信された場合、差分が無いため、該デバイスではプログラムの更新がなくリブートのみが行われることになる。
一方、配信サーバ１３３は、更新すべきプログラムを含む複数のプログラムを含むグループをデバイスに「上書き配信」する場合、当該グループに含まれる全プログラムを、該デバイスに送信する。該デバイスのクライアントモジュール３１３は、配信サーバ１３３から送信された該グループに含まれる全プログラムを用いて該デバイスのファーム構成を更新する。

図８は、デバイス機種別の管理ファームバージョンテーブル９０１の一例を示す図である。
テーブル９０１において、９０２は、デバイスの機種を示す。９０３は、デバイスの機種の最新のファームウェアバージョンを示す。９０３は、過去に配信サーバ１３３に登録されたファームウェアのバージョンを示す。

図９に、デバイス毎のファームウェア動作実績テーブル１００１の一例を示す図である。
テーブル１００１において、１００２は、デバイスのシリアルＮｏ.を示す。１００３は、デバイスの機種を示す。１００４は、デバイスの現在のファームウェアバージョンを示す。１００５は、過去に配信したファームウェアで正常に動作したバージョンを示す。１００６は、過去に配信したファームウェアでエラーが発生したバージョンを示す。
なお、エラーコードとケースの紐づけテーブル８０１、エラーの種別と配信サーバの対応テーブル８０５、デバイス機種別の管理ファームバージョンテーブル９０１、デバイス毎のファームウェア動作実績テーブル１００１は、配信サーバ１３３のＨＤＤ２０４等に格納されている。

以下、本実施例のシステムの処理について説明する。
まず、図１０を用いて、システム全体での処理の流れを説明し、その後、図１１〜図１５を用いて、各装置の処理を個別に説明する。なお、図１０、図１１における監視装置の処理は、監視装置のＣＰＵがＨＤＤに格納されたプログラムを読み出して実行することにより実現されるものである。また、図１０、図１２における監視センタホスト１１１の処理は、監視センタホスト１１１のＣＰＵ２０１がＨＤＤ２０４に格納されたプログラムを読み出して実行することにより実現されるものである。さらに、図１０、図１３におけるクライアントモジュール３１３の処理は、クライアントモジュール３１３のＣＰＵ２０１がＨＤＤ２０４に格納されたプログラムを読み出して実行することにより実現されるものである。また、図１０、図１４、図１５における配信サーバ１３３の処理は、配信サーバ１３３のＣＰＵ２０１がＨＤＤ２０４に格納されたプログラムを読み出して実行することにより実現されるものである。

図１０は、クライアントモジュール３１３、配信サーバ１３３、監視センタホスト１１１、監視装置１１７、１２２、１２３、１３１の処理の全体を示すシーケンス図である。なお、監視装置については、監視装置１３１を用いて説明するが、他の監視装置の処理も同一である。
監視センタホスト１１１が監視するデバイスは、配信サーバ１３３からファームウェアを配信可能である。１１０１において、監視センタホスト１１１は、ＰＣ１０４からのユーザ操作に応じて、配信サーバ１３３に配信対象のデバイスの選択情報を通知する。１１０２において、配信サーバ１３３は、ＰＣ１０４からのユーザ操作に応じて、ファームウェアの配信予約を行う。次に、１１０３において、配信サーバ１３３は、配信予約されたデバイスのリストを監視センタホスト１１１に通知する。

１１０４において、監視装置１３１は、配信予約用ポーリングを一定間隔で行う。監視装置１３１は、配信予約用ポーリング（１１０４）を実行した際に、監視センタホスト１１１に配信予約情報があることを確認すると、１１０５において、監視センタホスト１１１から配信予約情報を受信する。さらに、１１０６において、監視装置１３１は、配信情報要求指示をクライアントモジュール３１３に行う。
１１０７において、クライアントモジュール３１３は、配信サーバ１３３に対して、配信情報要求を行い、その返答として、１１０８において、配信サーバ１３３から配信開始時刻を取得する。

次に、１１０９において、クライアントモジュール３１３は、配信予約情報が変更されていないかの確認のために、配信サーバ１３３に対して、予約情報確認を行い、その返答として、１１１０において、配信サーバ１３３から配信開始時刻を取得する。なお、クライアントモジュール３１３は、配信開始時刻（１１１０）と配信開始時刻（１１０８）が異なっていれば、不整合として予約をキャンセルする。配信開始時刻（１１１０）と配信開始時刻（１１０８）が合致していれば、クライアントモジュール３１３は、１１１１に処理を進める。

１１１１において、クライアントモジュール３１３は、配信サーバ１３３にファーム配送情報要求を行い、その返答として、１１１２において、配信サーバ１３３からダウンロード先ＵＲＬ情報を取得する。
１１１３において、クライアントモジュール３１３は、１１１２で取得したダウンロード先ＵＲＬ情報内のＵＲＬリストを参照し、配信サーバ１３３に対してファーム取得要求を行い、その返答として、１１１４において、配信サーバ１３３からファームウェアを受信して、アップデート処理を行う。

１１１５は、ファームウェアのアップデート処理においてエラーが発生しなかった場合を示す。この場合、クライアントモジュール３１３は、配信サーバ１３３に受信完了通知を行い、１１１６に示されるように、配信サーバ１３３はファームウェアの配信処理を正常終了とする。

１１１７は、ファームウェアのアップデート時にエラーが発生した場合を示す。１１１８においてエラーが発生した場合、クライアントモジュール３１３は、配信サーバ１３３にエラーコードを通知する。そして、１１１９において、クライアントモジュール３１３は、配信サーバ１３３に対する再配信用のポーリングを開始する。１１２０において、クライアントモジュール３１３は、配信サーバ１３３で再配信用のダウンロード先ＵＲＬ情報の送信がなければ、クライアントモジュール３１３は、一定時間をあけてポーリングを繰り返す。

１１２１において、配信サーバ１３３は、再配信用のファームウェアを指示する。１１２２において、配信サーバ１３３は、再配信用ポーリングの返答として、再配信用のダウンロード先ＵＲＬ情報を、クライアントモジュール３１３に送信する。
１１２３において、クライアントモジュール３１３は、配信サーバ１３３にファーム取得要求を行い、その返答として、１１２４において、配信サーバ１３３からファームウェアを受信し、ファームウェアを受信してアップデートする。

１１２５において、ファームウェアをアップデートした際に、エラーがなければ、クライアントモジュール３１３は、配信サーバ１３３に受信完了通知を行い、１１２６に示されるように、配信サーバ１３３はファームウェアの配信処理を正常終了する。

ステップ１１２７では、監視装置１３１により、ファームウェアアップデート後の監視動作が実行される。１１２７において、監視装置１３１は、定期的にデバイス稼働情報を監視センタホストに通知する。デバイスの稼働情報とは、コピー枚数を計測したカウンタ情報などである。

１１２８において、監視センタホスト１３３は、デバイスの稼働情報チェックを行い、カウンタ情報などに不具合がないかをチェックする。その結果、エラーがなければ、稼働情報チェックを正常終了するが、エラーが発生した場合、１１３０において、監視センタホスト１１１は、監視装置１３１にエラー通知を行う。

１１３０でエラー通知を受信した監視装置１３１は、１１３１において、再配信用ポーリング開始指示をクライアントモジュール３１３に対して行う。一方、監視センタホスト１１１は、１１３２において、配信サーバ１３３に対して、エラーコード通知を行う。

１１３３において、クライアントモジュール３１３は、配信サーバ１３３に対して、再配信用のポーリングを開始する。１１３４において、クライアントモジュール３１３は、再配信用のファームがないかを、配信サーバ１３３に問い合わせる。

１１３５において、配信サーバ１３３は、再配信用のファームウェアを指示し、再配信用ポーリング（１１３４）の返答として、１１３６において、ダウンロード先ＵＲＬ情報を、クライアントモジュール３１３に送信する。

１１３７において、クライアントモジュール３１３は、配信サーバ１３３にファーム取得要求を行い、その返答として、配信サーバ１３３は、１１３８において、ファーム送信を行う。クライアントモジュール３１３は、ファームウェアを受信して、ファームウェアをアップデートする。

１１３９において、ファームウェアのアップデート処理でエラーが発生しなければ、クライアントモジュール３１３は、配信サーバ１３３に、受信完了通知を行い、１１４０において、配信サーバ１３３はファームウェアの配信処理を正常終了する。

＜監視装置の処理＞
図１１は、本発明における監視装置の処理の一例を示すフローチャートである。
まず、図１１（ａ）を用いて、監視装置の配信予約用ポーリング処理について説明する。
Ｓ１２０１において、監視装置１３１は、配信予約用ポーリングを監視センタホスト１３３に行う（図１０の１１０４に対応）。

次に、Ｓ１２０２において、監視装置１３１は、配信予約情報があるか否かを確認する。そして、配信予約情報があると判定した場合(Ｓ１２０２でＹｅｓの場合)、監視装置１３１は、Ｓ１２０３に処理を進める。一方、配信予約情報が無いと判定した場合(Ｓ１２０２でＮｏの場合)、監視装置１３１は、そのままＳ１２０４に処理を進める。

Ｓ１２０３において、監視装置１３１は、クライアントモジュール３１３に配信要求指示を行う（図１０の１１０６に対応）。そして、Ｓ１２０４に処理を進める。Ｓ１２０４において、監視装置１３１は、次回のポーリング時間まで、一定時間待機し、Ｓ１２０１に処理を移行する。

次に、図１１（ｂ）を用いて、監視装置のデバイス稼働情報通知処理について説明する。
Ｓ１２０５において、監視装置１３１は、デバイス稼動情報通知を、監視センタホスト１１１に行う（図１０の１１２７に対応）。
次に、Ｓ１２０６において、監視装置１３１は、監視センタホスト１３３からエラーが通知されたか否かを判定する。そして、エラーが通知されていないと判定した場合(Ｓ１２０６でＮｏの場合)、監視装置１３１は、そのままＳ１２０８に処理を進める。一方、エラーが通知された（図１０の１１３０に対応）と判定した場合(Ｓ１２０６でＹｅｓの場合)、監視装置１３１は、Ｓ１２０７に処理を進める。

Ｓ１２０７において、監視装置１３１は、クライアントモジュール３１３に再配信用ポーリングの開始指示を行う（図１０の１１３１に対応）。そして、Ｓ１２０８に処理を進める。Ｓ１２０８において、監視装置１３１は、一定時間待機し、Ｓ１２０５に処理を移行する。

＜監視センタホストの処理＞
図１２は、本発明における監視センタホストの処理の一例を示すフローチャートである。
Ｓ１３０１において、監視センタホスト１１１は、監視装置１３１からデバイス稼動情報通知を受信すると（図１０の１１２７に対応）、Ｓ１３０２に処理を進める。
Ｓ１３０２において、監視センタホスト１１１は、稼動情報の不整合チェックを行う。稼働情報とは、コピー枚数を計測したカウンタ情報などであり、カウンタ情報がカウントアップされない等の不整合チェックをこのステップで行う（図１０の１１２８に対応）。

次に、Ｓ１３０３において、監視センタホスト１１１は、カウンタ情報が正常に取得されており、不整合がないかどうかを判定する。そして、不整合がないと判定した場合(Ｓ１３０３でＮｏの場合)、監視センタホスト１１１は、本フローチャートの処理を終了する。
一方、上記Ｓ１３０３において、不整合があると判定した場合(Ｓ１３０３でＹｅｓの場合)、監視センタホスト１１１は、エラー発生と判断し（図１０の１１２９に対応）、Ｓ１３０４に処理を進める。

Ｓ１３０４において、監視センタホスト１１１は、監視装置１３１に、デバイス稼動情報通知の返答として、エラー通知を行う。（図１０の１１３０に対応）。また、Ｓ１３０５において、監視センタホスト１１１は、配信サーバ１３３にエラーコード通知を行う（図１０の１１３２に対応）。そして、本フローチャートの処理を終了する。

＜クライアントモジュールの処理＞
図１３は、本発明におけるクライアントモジュールの処理の一例を示すフローチャートである。
Ｓ１４０１において、クライアントモジュール３１３は、監視装置１３１から再配信用ポーリング開始指示（図１０の１１３１に対応）を受信したか否かを判定する。そして、再配信用ポーリング開始指示を受信していないと判定した場合(Ｓ１４０１でＮｏの場合)、クライアントモジュール３１３は、Ｓ１４０２に処理を進める。

Ｓ１４０２において、クライアントモジュール３１３は、監視装置１３１から配信情報要求指示（図１０の１１０６に対応）を受信したか否かを判定する。そして、配信情報要求指示を受信していないと判定した場合(Ｓ１４０２でＮｏの場合)、クライアントモジュール３１３は、本フローチャートの処理を終了する。一方、配信情報要求指示を受信したと判定した場合(Ｓ１４０２でＹｅｓの場合)、クライアントモジュール３１３は、Ｓ１４０３以降のステップに処理を進める。

Ｓ１４０３において、クライアントモジュール３１３は、配信予約の確認のため、配信情報要求で、配信サーバ１３３に問い合わせを行う（図１０の１１０７に対応）。Ｓ１４０４において、クライアントモジュール３１３は、配信情報要求の返答として、配信サーバ１３３から配信開始時刻を受信する（図１０の１１０８に対応）。

次に、Ｓ１４０５において、クライアントモジュール３１３は、予約情報確認で、配信サーバに問いあわせを行う（図１０の１１０９に対応）。Ｓ１４０６において、クライアントモジュール３１３は、予約情報確認の返答として、配信サーバ１３３から配信開始時刻を受信する（図１０の１１１０に対応）。

次に、Ｓ１４０７において、クライアントモジュール３１３は、上記Ｓ１４０６で受信した配信開始時刻に基づいて、配信スケジュールに変更があるか否かを確認する。そして、配信スケジュールに変更があると判定した場合(Ｓ１４０７でＹｅｓの場合)、クライアントモジュール３１３は、Ｓ１４０８に処理を進める。Ｓ１４０８において、クライアントモジュール３１３は、配信エラーを配信サーバ１３３に通知し、本フローチャートの処理を終了する。

一方、上記Ｓ１４０７において、配信スケジュールに変更がないと判定した場合(Ｓ１４０７でＮｏの場合)、クライアントモジュール３１３は、Ｓ１４０９に処理を進める。
Ｓ１４０９〜Ｓ１４１０において、クライアントモジュール３１３は、配信開始時刻まで待機する。そして、クライアントモジュール３１３は、配信開始時刻になったと判定した場合(Ｓ１４１０でＹｅｓの場合)、Ｓ１４１１に処理を進める。

Ｓ１４１１において、クライアントモジュール３１３は、ファーム配送情報要求で、配信サーバ１３３に問い合わせを行う。（図１０の１１１１に対応）。Ｓ１４１２において、クライアントモジュール３１３は、ファーム配送情報要求の返答として、ダウンロード先ＵＲＬ情報を、配信サーバ１３３から受信する（図１０の１１１２に対応）。

次に、Ｓ１４１３において、クライアントモジュール３１３は、上記Ｓ１４１２のファーム配送情報要求（又は、後述するＳ１４２６の再配信用ポーリング（図１０の１１２０、１１３４に対応））の返答として受信した、ダウンロード先ＵＲＬ情報に、ダウンロード先のＵＲＬリストが含まれているかどうかを判断する。
そして、ダウンロード先のＵＲＬリストが含まれていると判定した場合(Ｓ１４１３でＹｅｓの場合)、クライアントモジュール３１３は、Ｓ１４１４に処理を進める。

Ｓ１４１４において、クライアントモジュール３１３は、ファーム取得要求で、ＵＲＬリストのリンク先に問い合わせを行う。（図１０の１１１３、１１２３、１１３７に対応）。次に、Ｓ１４１５において、クライアントモジュール３１３は、ファーム取得要求の返答として、ファームウェアを受信する。（図１０の１１１４、１１２４、１１３８に対応）。次に、Ｓ１４１６において、クライアントモジュール３１３は、受信したファームウェアをデバイスにインストールし、アップデート処理を行い、Ｓ１４１７に処理を進める。

一方、上記Ｓ１４１３において、ダウンロード先のＵＲＬリストが含まれていない（ダウンロード先のＵＲＬなしを示す情報が含まれている）と判定した場合(Ｓ１４１３でＮｏの場合)、クライアントモジュール３１３は、そのままＳ１４１７に処理を進める。

Ｓ１４１７において、クライアントモジュール３１３は、デバイスの再起動処理を行う。次に、Ｓ１４１８において、クライアントモジュール３１３は、ファームウェアのアップデート処理でエラーが発生したかどうか確認する。そして、エラーが発生していないと判定した場合（Ｓ１４１８でＮｏの場合）、クライアントモジュール３１３は、Ｓ１４１９に処理を進める。

Ｓ１４１９において、クライアントモジュール３１３は、配信サーバ１３３に対して、受信完了通知を行い（図１０の１１１５、１１２５、１１３９に対応）、Ｓ１４２１に処理を進める。
Ｓ１４２１において、クライアントモジュール３１３は、再配信用ポーリングを行っているか判定する。そして、再配信用ポーリングを行っていると判定した場合（Ｓ１４２１でＹｅｓの場合）、クライアントモジュール３１３は、再配信用ポーリングを停止し（Ｓ１４２２）、本フローチャートの処理を終了する。

一方、再配信用ポーリングを行っていないと判定した場合（Ｓ１４２１でＮｏの場合）、クライアントモジュール３１３は、そのまま本フローチャートの処理を終了する。

また、上記Ｓ１４１８において、エラーが発生したと判定した場合（Ｓ１４１８でＹｅｓの場合）、クライアントモジュール３１３は、Ｓ１４２０に処理を進める。Ｓ１４２０において、クライアントモジュール３１３は、障害情報としてエラーコードを配信サーバ１３３に通知し（図１０の１１１８に対応）、Ｓ１４２３に処理を進め、再配信用ポーリングの動作に移行する。

次に、監視装置から再配信用ポーリングを行う場合の動作を説明する。
上記Ｓ１４０１において、再配信用ポーリング指示（図１０の１１３１に対応）を受信したと判定した場合(Ｓ１４０１でＹｅｓの場合)、クライアントモジュール３１３は、Ｓ１４２３以降のステップに処理を進め、再配信用ポーリングの動作に移行する。
Ｓ１４２３において、クライアントモジュール３１３は、配信サーバ１３３に対して、再配信用ポーリングを開始する（図１０の１１１９、１１３３に対応）。

次に、Ｓ１４２４〜Ｓ１４２５において、クライアントモジュール３１３は、ポーリング時間まで待機する。そして、クライアントモジュール３１３は、ポーリング時間になったと判定した場合（Ｓ１４２５でＹｅｓの場合）、Ｓ１４２６に処理を進める。

Ｓ１４２６において、クライアントモジュール３１３は、配信サーバ１３３に対して、再配信用ポーリングで、問い合わせを行う（図１０の１１２０、１１３４に対応）。そして、Ｓ１４２７において、クライアントモジュール３１３は、問い合わせの返答として、配信サーバ１３３からダウンロード先ＵＲＬ情報（図１０の１１２２、１１３６に対応）を受信したか否かを判定する。

そして、ダウンロード先ＵＲＬ情報を受信していないと判定した場合（Ｓ１４２７でＮｏの場合）、クライアントモジュール３１３は、まだ配信サーバ１３３で再配信ファームが指示がされていないと判断し、Ｓ１４２４に処理を移行し、再度ポーリングを行う。

一方、Ｓ１４２７において、ダウンロード先ＵＲＬ情報を受信したと判定した場合（Ｓ１４２７でＹｅｓの場合）、クライアントモジュール３１３は、Ｓ１４１３に処理を移行する。そして、上述したＳ１４１３以降の処理を実行する。

なお、クライアントモジュール３１３は、上記Ｓ１４１８でエラーが発生を確認した場合に、配信サーバ１３３にエラーコードを通知しているが、上記タイミングに限らず、エラーが発生したタイミングでいつでも、クライアントモジュール３１３は、配信サーバ１３３や管理センタホスト１１１にエラーコードを通知する構成となっている。また、この際、エラーの種類は、どのようなエラーの種類でもよい。

＜配信サーバの処理＞
図１４は、本発明における配信サーバのファームウェア配信処理の一例を示すフローチャートである。
Ｓ１６０１において、配信サーバ１３３は、監視センタホスト１１１より、配信対象デバイスの通知（図１０の１１０１に対応）を受けたかどうか判定する。そして、配信対象デバイスの通知を受けたと判定した場合（Ｓ１６０１でＹｅｓの場合）、配信サーバ１３３は、Ｓ１６０３に処理を進める。

Ｓ１６０３において、配信サーバ１３３は、ユーザがＰＣ１０４を介して配信サーバ１３３の画面を使用して行った配信予約（図１０の１１０２に対応）の設定を受けう付け、Ｓ１６０３に処理を進める。Ｓ１６０４において、配信サーバ１３３は、上記ユーザからの配信予約に基づいて、監視センタホスト１１１に、配信対象デバイス情報を通知する（図１０の１１０３に対応）。

次に、Ｓ１６０５において、配信サーバ１３３は、クライアントモジュール３１３からアクセスが来るまで待機し、アクセスがあると、Ｓ１６０６に処理を進める。
Ｓ１６０６において、配信サーバ１３３は、クライアントモジュール３１３から配信情報要求（図１０の１１０７に対応）が通知されたか判定する。そして、配信情報要求が通知されたと判定した場合（Ｓ１６０６でＹｅｓの場合）、Ｓ１６０７に処理を進める。

Ｓ１６０７において、配信サーバ１３３は、上記配信情報要求（図１０の１１０７に対応）の応答として、クライアントモジュール３１３に配信開始時刻を返信し（図１１の１１０８に対応）、Ｓ１６０５に処理を移行する。
一方、上記Ｓ１６０６において、配信情報要求が通知されていないと判定した場合（Ｓ１６０６でＮｏの場合）、配信サーバ１３３は、Ｓ１６０８に処理を進める。

Ｓ１６０８において、配信サーバ１３３は、クライアントモジュール３１３から予約情報確認（図１１の１１０９に対応）が通知されたかどうか判定する。そして、予約情報確認が通知されたと判定した場合（Ｓ１６０８でＹｅｓの場合）、配信サーバ１３３は、Ｓ１６０９に処理を進める。

Ｓ１６０９において、配信サーバ１３３は、上記予約情報確認（図１１の１１０９に対応）の返答として、クライアントモジュール３１３に配信開始時刻を返信し（図１１の１１１０に対応）、Ｓ１６０５に処理を移行する。
一方、上記Ｓ１６０８において、予約情報確認が通知されていないと判定した場合（Ｓ１６０８でＮｏの場合）、配信サーバ１３３は、Ｓ１６１０に処理を進める。

Ｓ１６１０において、配信サーバ１３３は、クライアントモジュール３１３からファーム配送情報要求（図１０の１１１１に対応）もしくは再配信用ポーリング（図１０の１１２０、１１３４に対応）が通知されたかどうかを判定する。
そして、ファーム配送情報要求もしくは再配信用ポーリングが通知されたと判定した場合（Ｓ１６１０でＹｅｓの場合）、配信サーバ１３３は、Ｓ１６１１に処理を進める。

Ｓ１６１１において、配信サーバ１３３は、ファーム配送情報要求（図１０の１１１１に対応）もしくは再配信用ポーリング（図１０の１１２０、１１３４に対応）の返答として、クライアントモジュール３１３にダウンロード先ＵＲＬ情報を返信し（図１０の１１１２、１１２２、１１３６に対応）、Ｓ１６０５に処理を移行する。

なお、配信サーバ１３３は、ダウンロードするファームウェアがある場合は、ダウンロード先のＵＲＬリストをダウンロード先ＵＲＬ情報に含めて返信する。一方、ダウンロードするファームウェアがない場合は、配信サーバ１３３は、ダウンロード先のＵＲＬなしを示す情報をダウンロード先ＵＲＬ情報に含めて返信する。

一方、ファーム配送情報要求及び再配信用ポーリングのいずれも通知されていないと判定した場合（Ｓ１６１０でＮｏの場合）、配信サーバ１３３は、Ｓ１６１２に処理を進める。
Ｓ１６１２において、配信サーバ１３３は、クライアントモジュール３１３からファーム取得要求（図１０の１１１３、１１２３、１１３７に対応）が通知されたかどうかを判定する。

そして、ファーム取得要求が通知されたと判定した場合（Ｓ１６１２でＹｅｓの場合）、配信サーバ１３３は、Ｓ１６１３に処理を進める。
Ｓ１６１３において、配信サーバ１３３は、ファーム取得要求（図１０の１１１３、１１２３、１１３７に対応）の返答として、クライアントモジュール３１３にファームウェアを送信し（図１０の１１１４、１１２４、１１３８に対応）、Ｓ１６０５に処理を移行する。

一方、ファーム取得要求が通知されていないと判定した場合（Ｓ１６１２でＮｏの場合）、配信サーバ１３３は、Ｓ１６１４に処理を進める。
Ｓ１６１４において、配信サーバ１３３は、クライアントモジュール３１３から、エラーコード（図１０の１１１８に対応）が通知されたかどうかを判定する。そして、エラーコードが通知されたと判定した場合（Ｓ１６１４でＹｅｓの場合）、配信サーバ１３３は、Ｓ１６１５に処理を進める。
Ｓ１６１５において、配信サーバ１３３は、再配信予約設定処理（詳細は図１５に示す）を実行し、Ｓ１６０２に処理を移行する。

一方、エラーコードが通知されていないと判定した場合（Ｓ１６１４でＮｏの場合）、配信サーバ１３３は、Ｓ１６１６に処理を進める。Ｓ１６１６において、配信サーバ１３３は、クライアントモジュール３１３から、受信完了通知を受信したかどうかを判定する。
そして、受信完了通知を受信していないと判定した場合（Ｓ１６１６でＮｏの場合）、配信サーバ１３３は、Ｓ１６０５に処理を移行する。

一方、受信完了通知を受信したと判定した場合（Ｓ１６１６でＹｅｓの場合）、配信サーバ１３３は、Ｓ１６１７に処理を進める。Ｓ１６１７において、配信サーバ１３３は、配信処理を正常終了し（図１０の１１１６、１１２６、１１４０に対応）、本フローチャートの処理を終了する。

図１５は、本発明における配信サーバがエラーを受信した場合に実行される再配信予約設定処理の一例を示すフローチャートである。なお、このフローチャートの処理は、図１４のＳ１６１５の処理を詳細化したものである。
配信サーバ１３３は、クライアントモジュール３１３、もしくは、監視センタホスト１１１からのエラー通知を受信すると（Ｓ１５０１）、Ｓ１５０２に処理を進める。なお、エラー通知には、デバイスのシリアルＮｏ.含まれるものとする。

Ｓ１５０２において、配信サーバ１３３は、上記通知された障害情報としてのエラーコードを、データベース１３４で検索する。次に、Ｓ１５０３において、配信サーバ１３３は、図７に示すような、エラーコードとケースの紐づけテーブル８０１を参照し、エラーコードに対応するケースを決定する。

次に、Ｓ１５０４において、配信サーバ１３３は、図７に示すような、デバイス機種別の管理ファームバージョンテーブル８０５を参照し、ケースに対応する配信サーバの処理を決定する。ここで決定する配信サーバの処理は、上記ケースに対応する配信対象ファームウェア８０８、差分配信／上書き配信８０９となる。

次に、Ｓ１５０５において、配信サーバ１３３は、図９に示すような、デバイス毎のファームウェア動作実績テーブル１００１を参照し、上記エラー通知に含まれるデバイスのシリアルＮｏ.から、デバイスの現在バージョンと機種を抽出する。

次に、Ｓ１５０６において、配信サーバ１３３は、同一ファームを配信するかどうかを判定する。この判定では、上記Ｓ１５０４で決定した配信対象ファームウェア８０８が「同一ファームウェア」の場合に同一ファームを配信すると判定し、他の場合に、同一ファームを配信しないと判定するものとする。

そして、上記Ｓ１５０６において、同一ファームを配信すると判定した場合（Ｓ１５０６でＹｅｓの場合）、配信サーバ１３３は、Ｓ１５０７に処理を進める。Ｓ１５０７において、配信サーバ１３３は、デバイスの現在バージョンと同じバージョンのファームウェアを選択し、Ｓ１５０９に処理を進める。

一方、上記Ｓ１５０６において、同一ファームを配信しないと判定した場合（Ｓ１５０６でＮｏの場合）、配信サーバ１３３は、Ｓ１５０８に処理を進める。Ｓ１５０８において、配信サーバ１３３は、図９に示すような、デバイス毎のファームウェア動作実績テーブル１００１、及び図８に示すような、デバイス機種別の管理ファームバージョンテーブル９０１等を参照し、上記エラーが発生したデバイスと同機種のデバイスにおいて動作実績のある最新ファームウェアを選択し、Ｓ１５０９に処理を進める。

Ｓ１５０９において、配信サーバ１３３は、差分配信するかどうかを判定する。この判定では、上記Ｓ１５０４で決定した差分配信／上書き配信８０９が「差分配信」の場合に差分配信を行うと判定し、他の場合に、差分配信を行わないと判定するものとする。

そして、上記Ｓ１５０９において、差分配信を行うと判定した場合（Ｓ１５０９でＹｅｓの場合）、配信サーバ１３３は、Ｓ１５１０に処理を進める。Ｓ１５１０において、配信サーバ１３３は、上記Ｓ１５０７又はＳ１５０８で決定したバージョンのファームウェアを「差分配信」で配信する再配信予約を行う。この再配信予約により、再配信ファームが指示される。なお、「差分配信」とは、デバイスにインストールされているファームウェアと、配信対象のファームウェアを比較して、同じモジュールは配信対象とせず、差分のモジュールのみを配信対象とする方法である。差分配信を使用することで、配信サーバ１３３は、差分のみデバイスに配信すればよいため、通信データ量、通信コスト、サーバ負荷等を削減することができる。

一方、上記Ｓ１５０９において、差分配信を行わないと判定した場合（Ｓ１５０９でＮｏの場合）、配信サーバ１３３は、Ｓ１５１１に処理を進める。Ｓ１５１１において、配信サーバ１３３は、上記Ｓ１５０７又はＳ１５０８で決定したバージョンのファームウェアを「上書き配信」で配信する再配信予約を行う。この再配信予約により、再配信ファームが指示される。なお、「上書き配信」とは、デバイスにインストールされているファームウェアと、配信対象のファームウェアに、同じモジュールがあったとしても上書き処理を行う配信方法である。すなわち、差分のモジュールなどの判断は行わず、そのファームウェアの全モジュールを配信対象とする方法である。

なお、デバイスにインストールされているファームウェアと「同じバージョン」のファームウェアを「差分配信」で再配信予約した場合（「同じバージョン」且つ「差分配信」の場合）、差分のモジュールが存在しないため、ダウンロードされるファームウェアは存在しない。このため、配信サーバ１３３は、クライアントモジュール３１３から、再配信用ポーリングが通知されると（図１４のＳ１６１０でＹｅｓ）、「ダウンロード先のＵＲＬなし」を示す情報をダウンロード先ＵＲＬ情報に含め、クライアントモジュール３１３に返信する。
また、上記以外で再配信予約した場合（「異なるバージョン」又は「上書き配信」の場合）、クライアントモジュール３１３から、再配信用ポーリングが通知されると（図１４のＳ１６１０でＹｅｓ）、配信サーバ１３３は、ダウンロードするファームウェアのダウンロード先のＵＲＬリストをダウンロード先ＵＲＬ情報に含め、クライアントモジュール３１３に返信する。

次に、上述した図６に示したデバイス７０１、７０２、７０３にエラーが発生した場合の動作について具体的に説明する。
＜デバイス７０１＞
まず、デバイス７０１に、ファームウェアを適用した際に、エラー（エラーコード：９２００１１３）が発生した場合の動作を以下に説明する。
クライアントモジュール３１３は、Ｓ１４１７のファームウェア適用後に、エラーが発生したので、Ｓ１４２０で、エラーコード「９２００１１３」を配信サーバ１３３に通知し、Ｓ１４２６で、配信サーバ１３３に対して、再配信用のポーリングを定期的に実行する。

配信サーバ１３３は、Ｓ１５０３の処理で、エラーコードとケースの紐づけテーブル８０１を参照し、エラーコードから対応すべきケースを選択する。この場合、エラーコードが「９２００１１３」なので、ケース(1)と判定する。
次に、配信サーバ１３３は、Ｓ１５０４の処理で、エラーの種別と配信サーバの対応テーブル８０５を参照し、ケース(1)の配信サーバの対応を参照する。ケース(1)は、エラーの種別と配信サーバの対応テーブル８０５を参照すると、「同一ファームウェア」を「差分配信」するという対応である。

さらに、配信サーバ１３３は、Ｓ１５０５の処理で、デバイス毎のファームウェア動作実績テーブル１００１を参照し、デバイス７０１の機種と、現在バージョンを特定する。デバイス７０１のシリアルＮｏ.は「ＺＺＺ００００１」なので、機種は「ｉＲ Ａ」、現在バージョンは「１９．００」と特定される。
さらに、配信サーバ１３３は、データベース１３４を参照し、バージョン「１９．００」の「ｉＲ Ａ」用のファームウェアを配信予約する。同一ファームウェアの差分配信なので、Ｓ１５０６において「同一ファーム」と判断し、Ｓ１５０９において「差分配信」と判断し、Ｓ１６１１において、再配信用のポーリングの返答（ダウンロード先ＵＲＬ情報）として「ＵＲＬリストがない」を通知する。

デバイス７０１は、再配信用ポーリングの返答を受信し、「ＵＲＬリストがない」と認識するため、Ｓ１４１３の判断により、そのままＳ１４１７の再起動処理を実行する。すなわち、ファームのダウンロードや適用は行わず、デバイス再起動処理のみを行う。エラーコード「９２００１１３」は、図７に示されるように、「再起動で復旧するエラー」に分類され、「同一ファームウェア」の「差分配信」で復旧するエラーであるので、上記処理により、デバイス７０１は、エラーより復旧する。

＜デバイス７０２＞
次に、デバイス７０２に、ファームウェアを適用した際に、エラー（エラーコード：９９９００２１）が発生した場合の動作を以下に説明する。
クライアントモジュール３１３は、Ｓ１４１７のファームウェア適用時に、エラーが発生したので、Ｓ１４２０で、エラーコード「９９９００２１」を配信サーバ１３３に通知し、Ｓ１４２６で、配信サーバ１３３に対して、再配信用のポーリングを定期的に実行する。

配信サーバ１３３は、Ｓ１５０３の処理で、エラーコードとケースの紐づけテーブル８０１を参照し、エラーコードから対応すべきケースを選択する。この場合、エラーコードが「９２００１１３」なので、ケース(2)と判定する。
次に、配信サーバ１３３は、Ｓ１５０４の処理で、エラーの種別と配信サーバの対応テーブル８０５を参照し、ケース(2)の配信サーバの対応を参照する。ケース(2)は、エラーの種別と配信サーバの対応テーブル８０５を参照すると、「同一ファームウェア」を「上書き配信」するという対応である。

さらに、配信サーバ１３３は、Ｓ１５０５の処理で、デバイス毎のファームウェア動作実績テーブル１００１を参照し、デバイス７０２の機種と、現在バージョンを特定する。デバイス７０２のシリアルＮｏ.は「ＺＺＺ００００２」なので、機種は「ｉＲ Ｂ」、現在バージョンは「２８．００」と特定される。
さらに、配信サーバ１３３は、データベース１３４を参照し、バージョン「２８．００」の「ｉＲ Ｂ」用のファームウェアを配信予約する。同一ファームウェアの上書き配信なので、Ｓ１５０６において「同一ファーム」と判断し、Ｓ１５０９において「上書き配信」と判断し、Ｓ１６１１において、再配信用のポーリングの返答（ダウンロード先ＵＲＬ情報）として、ダウンロード先ＵＲＬを通知する。

デバイス７０２は、再配信用ポーリングの返答を受信し、ダウンロード先ＵＲＬを参照して、Ｓ１４１３の判断により、Ｓ１４１４〜１４１７のファームインストール処理を実行する。エラーコード「９９９００２１」は、図７に示されるように、「上書きアップデートで復旧するエラー」に分類され、「同一ファームウェア」の「上書き配信」し、再起動を行うことで復旧するエラーであるので、上記処理により、デバイス７０２は、エラーより復旧する。

＜デバイス７０３＞
次に、デバイス７０３に、ファームウェア（バージョン１５．０３）を適用した際に、エラー（エラーコード：９９０３１１３）が発生した場合の動作を以下に説明する。
クライアントモジュール３１３は、Ｓ１４１７のファームウェア適用時に、エラーが発生したので、Ｓ１４２０で、エラーコード「９９９０３１１３」を配信サーバ１３３に通知し、Ｓ１４２６で、配信サーバ１３３に対して、再配信用のポーリングを定期的に実行する。

配信サーバ１３３は、Ｓ１５０３の処理で、エラーコードとケースの紐づけテーブル８０１を参照し、エラーコードから対応すべきケースを選択する。エラーコードが「９９９０３１１３」なので、ケース(3)と判定する。
次に、配信サーバ１３３は、Ｓ１５０４の処理で、エラーの種別と配信サーバの対応テーブル８０５を参照し、ケース(3)の配信サーバの対応を参照する。ケース(3)は、エラーの種別と配信サーバの対応テーブル８０５を参照すると、「動作実績のある最新ファームウェア」を「差分配信」するという対応である。

さらに、配信サーバ１３３は、Ｓ１５０５の処理で、デバイス毎のファームウェア動作実績テーブル１００１を参照し、デバイス７０３の機種と、現在バージョンを特定する。デバイス７０３のシリアルＮｏ.は「ＺＺＺ００００３」なので、機種は「ｉＲ Ｃ」、現在バージョンは「１５．０１」と特定される。「ｉＲ Ｃ」の最新ファームウェアのバージョンは、デバイス機種別の管理ファームバージョンテーブル９０１を参照すると、「１５．０３」であるが、「１５．０３」の適用に失敗しているので、「ｉＲ Ｃ」で動作実績のある最新ファームウェアは、過去バージョン９０１から「１５．０２」となる。

そして、配信サーバ１３３は、データベース１３４を参照し、バージョン「１５．０２」の「ｉＲ Ｃ」用のファームウェアを配信予約する。動作実績のある最新のファームウェアを差分配信なので、Ｓ１５０６において「同一ファームではない」と判断し、Ｓ１５０９において「差分配信」と判断し、Ｓ１６１１により、再配信用のポーリングの返答（ダウンロード先ＵＲＬ情報）として、ダウンロード先ＵＲＬを通知する。

デバイス７０３は、再配信用ポーリングの返答を受信し、ダウンロード先ＵＲＬを参照して、Ｓ１４１３の判断により、Ｓ１４１４〜１４１７のファームインストール処理を実行する。エラーコード「９９０３１１３」は、図７に示されるように、「ファームウェア不整合に関するエラー」に分類され、「動作実績のある最新ファームウェア」の「差分配信」し、再起動を行うことで復旧するエラーであるので、上記処理により、デバイス７０３は、エラーより復旧する。

以上示したように、本実施例によれば、デバイスでエラーが発生した際に、配信サーバからデバイスのファームウェアの再配信処理を行うことで、遠隔地等からインターネットを介してデバイスの再起動を行い、デバイスの障害を復旧することができる。このため、サービスマンの出動を大幅に削減でき、コスト削減を図ることができる。また、本実施例によれば、新たにリモートでの再起動コマンド等を設けることなく、インターネットを介したリモートからデバイスの再起動を実現することができる。
即ち、リモートでのプログラム配信が可能なネットワークデバイスで障害が発生した場合でも、リブートコマンドを用いることなく、リモートからネットワークデバイスを再起動して障害を解消することができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

Claims (6)

1. ネットワークデバイスとインターネットを介して接続する配信システムであって、
   ネットワークデバイスから障害情報を取得する取得手段と、
   前記障害情報の種別を特定する特定手段と、
   前記障害情報の種別が第１の種別であった場合には、当該障害を前記ネットワークデバイスのリブートにより解消させるために、前記ネットワークデバイスに既に配信されたプログラムと同一のプログラムを、前記ネットワークデバイスに既に配信されたプログラムとの差分のみを配信する差分配信で、前記ネットワークデバイスに配信し、また、前記障害情報の種別が第２の種別であった場合には、前記ネットワークデバイスに既に配信されたプログラムと同一のプログラムを、前記ネットワークデバイスに既に配信されたプログラムを含めて配信する上書き配信で、前記ネットワークデバイスに配信する配信手段と、
   を有することを特徴とする配信システム。
2. 前記第１の種別は、再起動により解消する障害に分類される種別であり、
   前記第２の種別は、プログラムを上書きすることにより解消する障害に分類される種別であることを特徴とする請求項１に記載の配信システム。
3. 前記配信手段は、前記障害情報の種別が第３の種別であった場合には、前記ネットワークデバイスと同機種のネットワークデバイスで実績のある最も新しいバージョンのプログラムを、前記ネットワークデバイスに配信することを特徴とする請求項１又は２に記載の配信システム。
4. 前記ネットワークデバイスは、前記配信手段によりプログラムが配信されると、該配信されたプログラムで前記ネットワークデバイスのプログラムが更新され、前記ネットワークデバイスがリブートされるものであり、前記差分配信において差分が存在しない場合には、前記プログラムは更新されず、前記ネットワークデバイスがリブートされることを特徴とする請求項１乃至３のいずれか１項に記載の配信システム。
5. 前記障害は、前記ネットワークデバイスにおいて、前記配信システムから配信されたプログラムを適用した場合に発生した障害を含むことを特徴とする請求項１乃至４のいずれか１項に記載の配信システム。
6. ネットワークデバイスとインターネットを介して接続する配信システムの制御方法であって、
   ネットワークデバイスから障害情報を取得する取得ステップと、
   前記障害情報の種別を特定する特定ステップと、
   前記障害情報の種別が第１の種別であった場合には、当該障害を前記ネットワークデバイスのリブートにより解消させるために、前記ネットワークデバイスに既に配信されたプログラムと同一のプログラムを、前記ネットワークデバイスに既に配信されたプログラムとの差分のみを配信する差分配信で、前記ネットワークデバイスに配信し、また、前記障害情報の種別が第２の種別であった場合には、前記ネットワークデバイスに既に配信されたプログラムと同一のプログラムを、前記ネットワークデバイスに既に配信されたプログラムを含めて配信する上書き配信で、前記ネットワークデバイスに配信する配信ステップと、
   を有することを特徴とする配信システムの制御方法。

Images