JP4481059B2 - 通信装置とその遠隔管理システム，ｏｓ更新方法，プログラム，および記録媒体 - Google Patents

Description

この発明は、通信装置、この電子装置とこれをネットワークを介して遠隔管理する管理装置とによって構成された遠隔管理システム、上記電子装置におけるソフトウェア更新方法、上記電子装置を制御するコンピュータに必要な機能（この発明に係わる機能）を実現させるためのプログラム、およびそのプログラムを記録した記録媒体に関する。

従来から、通信機能を備えたプリンタ，ファクシミリ（ＦＡＸ）装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等に通信機能を持たせた通信装置（電子装置）を被管理装置とし、外部装置であるサービスセンタ（管理センタ）の管理装置が公衆回線やインタネット等のネットワーク経由でこれらの被管理装置を遠隔管理する遠隔管理システムが提案されている。

このような遠隔管理システムに使用されている通信装置は、一般に、内部に当該通信装置全体の動作を制御するＣＰＵ（中央処理装置）と、ＣＰＵにその制御を行わせるためのソフトウェア（プログラム）を記憶するメモリとを有している。
通常、ソフトウェアを記憶するメモリとしてＲＯＭが用いられ、そのＲＯＭに、通信装置の基本動作を制御するプログラムを始めとして、各種パラメータやプログラムコードを含むファームウェアが格納されている。

ところで、通信装置の性能を向上させたり、通信装置の不具合を解消するために設計変更等を行い、それによりソフトウェア（一般にはファームウェア）の更新（バージョンアップ）が必要となる場合がある。なお、ファームウェアの例としては、アプリ（アプリケーションプログラム）やＯＳ（オペレーティングシステム）が挙げられる。
従来、この種の通信装置のソフトウェアの更新（例えばパラメータの書き換え等の更新を含む）は、サービスエンジニア（カスタマエンジニア）が顧客先を訪問し、その顧客先に設置されている通信装置の内部のＲＯＭを差し替えることによって行っていた。

一方、最近では、通信装置の工場出荷時に、その通信装置の動作を制御するためのソフトウェアをＥＰＲＯＭ(Erasable Programmable Read Only Memory)やフラッシュＲＯＭ等の不揮発性メモリ（不揮発性記憶手段）に書き込み、その不揮発性メモリを通信装置に実装しているが、この場合、その通信装置のＳＣＳＩポート，ＲＳ−２３２ＣポートやＩＣカードスロット等から所定の機器を使用してソフトウェアを入力し、不揮発性メモリのソフトウェアの更新を行うことが可能になっている。

ところが、このような従来の通信装置にあっては、実行すべき処理内容を示すソフトウェアを直接ＲＯＭに焼き込んだり、必要に応じてＳＣＳＩポート，ＲＳ―２３２ＣポートやＩＣカードスロット等からソフトウェアを入力してソフトウェアの更新を行う方法では、以下の（１）（２）に示すような問題点があり、多大な時間と費用がかかり、ひいてはサービス性向上の妨げとなっていた。

（１）ＲＯＭにソフトウェアを焼き込む場合、ソフトウェアの更新には人を介してＲＯＭの交換を行う必要があり、交換すべきＲＯＭの個数が多ければ多いほど、莫大な費用と人と時間を費やしてしまう。
（２）ソフトウェアの更新は、ＲＯＭを交換するか、ＳＣＳＩポート，ＲＳ―２３２ＣポートやＩＣカードスロット等からローカルな場所でしかできなかったので、遠隔地に設置されている通信装置のソフトウェアの更新は、直接サービスエンジニアがその設置場所を訪問して行うか、ソフトウェアを郵送など別の手段であらかじめ送っておいて、ローカルで行うしかなかった。

そこで、近年、電気的に書き換え可能な不揮発性メモリが搭載されている場合、外部装置からネットワーク等を介して送られてくるソフトウェアに基づいて不揮発性メモリ内のソフトウェアを更新する機能を有する通信装置が製品化されている。
ところが、このような通信装置では、ソフトウェアの更新中に電源遮断等のトラブル発生によってそのソフトウェアの更新に失敗すると、ソフトウェアが壊れるなどの理由で、それ以降電源投入等によって再起動させても、正常に動作しなくなる場合があり、結局はＳＣＳＩポート，ＲＳ―２３２ＣポートやＩＣカードスロット等からソフトウェアを入力したり、不揮発性メモリを交換したりして、ソフトウェアの更新を行わなければならない。

そこで、第１，第２の不揮発性メモリを備え、外部装置から更新用ソフトウェア（新バージョンのソフトウェア）をダウンロードして、その更新用ソフトウェアに基づいて第２の不揮発性メモリ内のソフトウェアを更新し（新バーションに書き換え）、その後の再起動時（電源投入時）に第２の不揮発性メモリ内のソフトウェアが正常か否かを判断し、正常ならばそのソフトウェアを、異常ならば第１の不揮発性メモリ内のソフトウェア（例えば固定ソフトウェア）をそれぞれ起動（実行）する機能を備えた通信装置（例えば特許文献１参照）が提案されている。
特開平９−２３１０３２号公報

このような通信装置（例えばパーソナルコンピュータ）では、通常、ソフトウェアの更新は機器利用者の操作によって開始されるため、ソフトウェアの更新中に電源遮断のトラブル発生によってそのソフトウェアの更新が失敗しても、すぐにソフトウェアを再ダウンロードしてソフトウェアの更新を開始させ、確実にソフトウェアの更新を完了させることが可能である。

一方、外部装置である管理装置からソフトウェア更新要求があった場合に、その外部装置から更新用ソフトウェアを自動的にダウンロードして第２の不揮発性メモリのソフトウェアを更新するタイプの通信装置、つまり上述したような遠隔管理システムにおける通信装置では、ソフトウェアの更新中に機器利用者が通信装置を利用しているとは限らないが、その時にトラブル発生によってソフトウェアの更新が失敗しても、その外部装置から再度ソフトウェア更新要求があれば、その外部装置から更新用ソフトウェアを自動的に再ダウンロードしてソフトウェアの更新を開始させ、ソフトウェアの更新を完了させることは可能である。

そのため、管理装置（外部装置）側では、通信装置側のソフトウェアの更新状況を知る必要があるが、従来は、通信装置側でＯＳの更新が失敗した場合には以下の理由によりその旨を管理装置へ通知できなかったため、管理装置に対して再度ソフトウェア更新要求を出すことができず、通信装置側でＯＳの更新を完了できない場合もあった。
特許文献１に記載された通信装置では、管理装置から更新用ＯＳをダウンロードしてＯＳの更新を行う場合には、そのＯＳ更新中に電源遮断等のトラブル発生によってそのＯＳ更新が失敗しても、その後の電源投入による再起動時にその失敗を判断することはできない。

すなわち、電源投入によって当該通信装置を再起動する場合、ＯＳ起動前にＲＯＭ等に記憶されているブートローダ（ブートプログラム）が起動するため、そのブートローダがＯＳ更新が成功したか否かをチェックする必要がある。しかし、このブートローダは、第２の不揮発性メモリにおけるＯＳの有無をその名称等の識別情報を参照することによって判断することはできるが、ＯＳの内容をチェックしてそのＯＳが正常か否かを判断するはできない。よって、ＯＳ更新が失敗していても、それを判断することはできない。

この発明は上記の問題点に鑑みてなされたものであり、通信装置において、管理装置等の外部装置から更新用ＯＳをダウンロードしてＯＳの更新を行う場合に、電源遮断等のトラブル発生によってそのＯＳ更新が失敗した場合でも、その後の電源投入による再起動時にその失敗を簡単且つ確実に判断できるようにすることを目的とする。

この発明は、上記の目的を達成するため、通信装置と、その遠隔管理システム、および上記通信装置の異常発生時の制御方法、並びに上記通信装置を制御するコンピュータに必要な機能を実現させるためのプログラムを提供する。

請求項１の発明による通信装置は、第１，第２の不揮発性記憶手段と、外部装置からＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードするダウンロード手段と、該手段によってダウンロードされたＯＳに基づいて上記第１，第２の不揮発性記憶手段内のＯＳを更新するＯＳ更新手段とを有する通信装置であって、上記ダウンロード手段による更新用ＯＳのダウンロードが成功した場合に、ＯＳ更新中を示す更新中情報を上記第１の不揮発性記憶手段に設定する第１の状態情報制御手段と、当該通信装置の起動時に、上記更新中情報の設定の有無をチェックし、該更新中情報が設定されていない場合には上記第２の不揮発性記憶手段内のＯＳを、該更新中情報が設定されている場合には上記第１の不揮発性記憶手段内のＯＳをそれぞれ起動させるＯＳ起動手段と、該手段によって上記第２の不揮発性記憶手段内のＯＳが起動された後、該不揮発性記憶手段内のアプリケーションプログラムを起動させるアプリケーションプログラム起動手段と、上記ＯＳ更新手段による上記第２の不揮発性記憶手段内のＯＳの更新が成功した場合に、上記更新中情報の設定を解除すると共に、ＯＳ更新完了を示す更新完了情報を上記第１の不揮発性記憶手段に設定する第２の状態情報制御手段と、上記ＯＳ起動手段および上記アプリケーションプログラム起動手段によって上記第２の不揮発性記憶手段内のＯＳおよびアプリケーションプログラムが順次起動し、且つ上記更新完了情報が設定されている場合には、ＯＳ更新完了を上記外部装置へ通知するＯＳ更新完了通知手段と、該手段による通知が終了した後、上記更新完了情報の設定を解除する第３の状態情報制御手段とを設け、上記ＯＳ更新手段に、上記第１の状態情報制御手段によって上記更新中情報が設定された後、上記更新用ＯＳに基づいて上記第２の不揮発性記憶手段内のＯＳを更新する手段と、上記第３の状態情報制御手段によって上記更新完了情報の設定が解除された後、上記第２の不揮発性記憶手段内のＯＳに基づいて上記第１の不揮発性記憶手段内のＯＳを更新する手段とを備えたものである。

請求項２の発明による通信装置は、請求項１の通信装置において、上記ＯＳ起動手段によって上記第１の不揮発性記憶手段内のＯＳが起動された場合には、ＯＳ更新失敗を上記外部装置へ通知するＯＳ更新失敗通知手段を設けたものである。
請求項３の発明による通信装置は、請求項２の通信装置において、上記ダウンロード手段は、上記ＯＳ更新失敗通知手段による上記外部装置へのＯＳ更新失敗の通知に対して、該外部装置から再びＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードする手段を備えたものである。

請求項４の発明による遠隔管理システムは、管理装置によってネットワーク経由で複数の通信装置を遠隔管理する遠隔管理システムであって、上記通信装置に、第１，第２の不揮発性記憶手段と、上記管理装置からＯＳ更新要求があった場合に、該管理装置から更新用ＯＳをダウンロードするダウンロード手段と、該手段によってダウンロードされたＯＳに基づいて上記第１，第２の不揮発性記憶手段内のＯＳを更新するＯＳ更新手段と、上記ダウンロード手段による更新用ＯＳのダウンロードが成功した場合に、ＯＳ更新中を示す更新中情報を上記第１の不揮発性記憶手段に設定する第１の状態情報制御手段と、当該通信装置の起動時に、上記更新中情報の設定の有無をチェックし、該更新中情報が設定されていない場合には上記第２の不揮発性記憶手段内のＯＳを、該更新中情報が設定されている場合には上記第１の不揮発性記憶手段内のＯＳをそれぞれ起動させるＯＳ起動手段と、該手段によって上記第２の不揮発性記憶手段内のＯＳが起動された後、該不揮発性記憶手段内のアプリケーションプログラムを起動させるアプリケーションプログラム起動手段と、上記ＯＳ更新手段による上記第２の不揮発性記憶手段内のＯＳの更新が成功した場合に、上記更新中情報の設定を解除すると共に、ＯＳ更新完了を示す更新完了情報を上記第１の不揮発性記憶手段に設定する第２の状態情報制御手段と、上記ＯＳ起動手段および上記アプリケーションプログラム起動手段によって上記第２の不揮発性記憶手段内のＯＳおよびアプリケーションプログラムが順次起動し、且つ上記更新完了情報が設定されている場合には、ＯＳ更新完了を当該通信装置の識別情報と共に上記管理装置へ通知するＯＳ更新完了通知手段と、該手段による通知が終了した後、上記更新完了情報の設定を解除する第３の状態情報制御手段とを設け、上記通信装置のＯＳ更新手段に、上記第１の状態情報制御手段によって上記更新中情報が設定された後、上記更新用ＯＳに基づいて上記第２の不揮発性記憶手段内のＯＳを更新する手段と、上記第３の状態情報制御手段によって上記更新完了情報の設定が解除された後、上記第２の不揮発性記憶手段内のＯＳに基づいて上記第１の不揮発性記憶手段内のＯＳを更新する手段とを備えたものである。

請求項５の発明による遠隔管理システムは、請求項４の遠隔管理システムにおいて、上記通信装置に、上記ＯＳ起動手段によって上記第１の不揮発性記憶手段内のＯＳが起動された場合には、ＯＳ更新失敗を当該通信装置の識別情報と共に上記管理装置へ通知するＯＳ更新失敗通知手段を設けたものである。
請求項６の発明による遠隔管理システムは、請求項５の遠隔管理システムにおいて、上記通信装置に、上記管理装置に対して定期的に送信要求があるかどうかの問い合わせを行う送信要求有無問合手段を設け、上記通信装置のダウンロード手段を、上記送信要求有無問合手段による上記管理装置への送信要求の問い合わせに対して、該管理装置からＯＳ更新要求があった場合に、該管理装置に対して更新用ＯＳを要求することにより、該管理装置から更新用ＯＳをダウンロードする手段としたものである。

請求項７の発明による遠隔管理システムは、請求項５又は６の遠隔管理システムにおいて、上記通信装置のダウンロード手段に、上記ＯＳ更新失敗通知手段による上記管理装置へのＯＳ更新失敗の通知に対して、該外部装置から再びＯＳ更新要求があった場合に、該管理装置に対して更新用ＯＳを要求することにより、該管理装置から更新用ＯＳをダウンロードする手段を備えたものである。

請求項８の発明によるＯＳ更新方法は、第１，第２の不揮発性記憶手段と、外部装置から更新用ＯＳをダウンロードし、該ＯＳに基づいて上記第１，第２の不揮発性記憶手段内のＯＳを更新する通信装置におけるＯＳ更新方法であって、外部装置からＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードし、該ダウンロードが成功した場合に、ＯＳ更新中を示す更新中情報を上記第１の不揮発性記憶手段に設定した後、上記更新用ＯＳに基づいて上記第２の不揮発性記憶手段内のＯＳを更新し、その更新が成功した場合に、上記更新中情報の設定を解除すると共に、ＯＳ更新完了を示す更新完了情報を上記第１の不揮発性記憶手段に設定し、当該通信装置の起動時に、上記更新中情報の設定の有無をチェックし、該更新中情報が設定されていない場合には、上記第２の不揮発性記憶手段内のＯＳおよびアプリケーションプログラムを順次起動させた後、上記更新完了情報が設定されている場合には、ＯＳ更新完了を上記外部装置へ通知して、上記更新完了情報の設定を解除した後、上記第２の不揮発性記憶手段内のＯＳに基づいて上記第１の不揮発性記憶手段内のＯＳを更新し、上記更新中情報が設定されている場合には、上記第１の不揮発性記憶手段内のＯＳを起動させるものである。

請求項９の発明によるＯＳ更新方法は、請求項８のＯＳ更新方法において、上記第１の不揮発性記憶手段内のＯＳが起動した場合には、ＯＳ更新失敗を上記外部装置へ通知するものである。
請求項１０の発明によるＯＳ更新方法は、請求項９のＯＳ更新方法において、上記外部装置への上記ＯＳ更新失敗の通知に対して、該外部装置から再びＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードするものである。

請求項１１の発明によるプログラムは、第１，第２の不揮発性記憶手段を有する通信装置を制御するコンピュータに、外部装置からＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードするダウンロード機能と、該機能による更新用ＯＳのダウンロードが成功した場合に、ＯＳ更新中を示す更新中情報を上記第１の不揮発性記憶手段に設定する第１の状態情報制御機能と、該機能によって上記更新中情報が設定された後、上記更新用ＯＳに基づいて上記第２の不揮発性記憶手段内のＯＳを更新するＯＳ更新機能と、該機能による更新が成功した場合に、上記更新中情報の設定を解除すると共に、ＯＳ更新完了を示す更新完了情報を上記第１の不揮発性記憶手段に設定する第２の状態情報制御機能と、当該通信装置の起動時に、上記更新中情報の設定の有無をチェックし、該更新中情報が設定されていない場合には上記第２の不揮発性記憶手段内のＯＳを、該更新中情報が設定されている場合には上記第１の不揮発性記憶手段内のＯＳをそれぞれ起動させるＯＳ起動機能と、該機能によって上記第２の不揮発性記憶手段内のＯＳが起動された後、該不揮発性記憶手段内のアプリケーションプログラムを起動させるアプリケーションプログラム起動機能と、上記ＯＳ起動機能および上記アプリケーションプログラム起動機能によって上記第２の不揮発性記憶手段内のＯＳおよびアプリケーションプログラムが順次起動し、且つ上記更新完了情報が設定されている場合には、ＯＳ更新完了を上記外部装置へ通知するＯＳ更新完了通知機能と、該機能による通知が終了した後、上記更新完了情報の設定を解除する第３の状態情報制御機能とを実現させるためのプログラムであり、上記ＯＳ更新機能に、上記第３の状態情報制御機能によって上記更新完了情報の設定が解除された後、上記第２の不揮発性記憶手段内のＯＳに基づいて上記第１の不揮発性記憶手段内のＯＳを更新する機能を備えたものである。

請求項１２の発明によるプログラムは、請求項１１のプログラムにおいて、上記コンピュータに、上記ＯＳ起動機能によって上記第１の不揮発性記憶手段内のＯＳが起動された場合には、ＯＳ更新失敗を上記外部装置へ通知するＯＳ更新失敗通知機能をも実現させるためのものである。
請求項１３の発明によるプログラムは、請求項１２のプログラムにおいて、上記ダウンロード機能に、上記ＯＳ更新失敗通知機能による上記外部装置へのＯＳ更新失敗の通知に対して、該外部装置から再びＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードする機能を備えたものである。

請求項１４の発明による記録媒体は、請求項１１〜１３のいずれかのプログラムを記録したコンピュータ読み取り可能な記録媒体である。

この発明によれば、通信装置が、管理装置等の外部装置から更新用ＯＳをダウンロードしてＯＳの更新を行う場合に、電源遮断等のトラブル発生によってそのＯＳ更新が失敗した場合でも、その後の電源投入による再起動時にその失敗を簡単且つ確実に判断することができる。よって、すぐに更新用のＯＳを再ダウンロードしてＯＳの更新を開始させることができるため、ＯＳの更新を確実に完了させることが可能になる。

以下、この発明を実施するための最良の形態を図面に基づいて具体的に説明する。
まず、この発明による通信装置を被管理装置とする遠隔管理システムの構成例について説明する。図１は、その遠隔管理システムの構成の一例を示す概念図である。

この遠隔管理システムは、プリンタ，ＦＡＸ装置，デジタル複写機，デジタル複合機等の画像形成装置やスキャナ装置などの画像処理装置やスキャナ装置などの画像処理装置、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等に通信機能を持たせた通信装置（電子装置）１（１ａ，１ｂ，１ｃ，１ｄ，１ｅ，１ｆ，１ｇ）を被管理装置とする遠隔管理システムである。そして、この各通信装置１と接続される（通信装置側から見た）外部装置として、各通信装置１とインタネット５（公衆回線等の他のネットワークでもよい）を介して接続されるサーバ装置として機能する管理装置３を備え、その管理装置３が、インタネット５経由で各通信装置１を集中的に遠隔管理できるようにしたものである。なお、公衆回線（又は専用回線）としては、アナログ回線，ＡＤＳＬ回線，デジタル回線（ＩＳＤＮ回線），光ファイバー利用回線等の固定電話回線や、携帯電話回線，ＰＨＳ回線等の移動電話回線がある。

例えば、図１に示す設置環境Ａでは、管理装置３とＨＴＴＰ（Hyper Text Transfer Protocol）による直接的なコネクションを確立できる通信装置１ａ，１ｂが、設置環境Ｂでは、管理装置３とＨＴＴＰによる直接的なコネクションを確立できる通信装置１ｃ，１ｄ，１ｅが、設置環境Ｃでは、管理装置３とＨＴＴＰによる直接的なコネクションを確立できる通信装置１ｆ，１ｇがそれぞれ設置されている。
なお、各設置環境Ａ，Ｂ，Ｃには、セキュリティ面を考慮し、ファイアウォール７（７ａ，７ｂ，７ｃ）を設置する。

このような遠隔管理システムにおいて、各通信装置１は、自己の制御管理のためのアプリ（アプリケーションプログラム）を実装している。
管理装置３は、各通信装置１の制御管理を行うためのアプリを実装している。そして、この遠隔管理システムにおけるこれら各通信装置１は、ＲＰＣ（remote procedure call）により、相互の実装するアプリのメソッドに対する処理の依頼である「要求」を通知し、この依頼された処理の結果である「応答」を取得することができるようになっている。

すなわち、通信装置１では、管理装置３への要求を生成してこれを管理装置３へ引き渡し（通知し）、この要求に対する応答を取得できる一方で、管理装置３は、通信装置１側への要求を生成してこれを通信装置１側へ引き渡し、この要求に対する応答を取得できるようになっている。
なお、ＲＰＣを実現するために、ＳＯＡＰ（Simple Object Access Protocol），ＨＴＴＰ，ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。

この送受信のデータ送受モデルを図２の概念図に示す。
（Ａ）は、通信装置１で管理装置３に対する要求が発生したケースである。このケースでは、通信装置１が通信装置側要求ａを生成し、これを受け取った管理装置３がこの要求に対する応答ａを返すというモデルになる。なお、（Ａ）では、応答ａだけでなく応答遅延通知ａ′を返信するケースが表記されている。これは、管理装置３を、通信装置側要求を受け取って、当該要求に対する応答を即座に返せないと判断したときには、応答遅延通知を通知して一旦接続状態を切断し、次回の接続の際に上記要求に対する応答を改めて引き渡す構成としているためである。

（Ｂ）は、管理装置３で通信装置１に対する要求が発生したケースである。このケースでは、管理装置３が管理装置側要求ｂを生成し、これを受け取った通信装置１が、当該要求に対する応答ｂを返すというモデルになっている。なお、（Ｂ）のケースでも、応答を即座に返せないときに応答遅延通知ｂ′を返すことは（Ａ）のケースと同様である。

次に、通信装置１のハードウェア構成について図３を参照して説明する。
図３は、通信装置１内のハードウェア構成例を示すブロック図である。
この通信装置１は、ＣＰＵ１１，ＤＲＡＭ１２，フラッシュＲＯＭ１３，カードメモリコントローラ１４，カードメモリ１５，リアルタイムクロック回路（ＲＴＣ）１６，モデム１７，ＮＣＵ（網制御装置）１８，ＮＩＣ１９，２０，および電源回路２１等によって構成されている。

ＣＰＵ１１は、ＤＲＡＭ１２内の基本動作を制御するＯＳ（オペレーションシステム）を含む各種プログラム（ソフトウェア）に基づいて、通信装置１の動作を制御したり、ＮＣＵ１８又はＮＩＣ１９，２０等により、図示しない公衆回線又はインタネット５経由で管理装置３に対する各種データ（又は信号）の送受信を制御したり、公衆回線経由で管理装置３に対して発呼を行うなど、この通信装置１全体を統括的に制御する中央処理装置である。
ＤＲＡＭ１２には、ＯＳを含む各種プログラムを記憶するプログラムメモリや、ＣＰＵ１１がデータ処理を行う際に使用するワークメモリ等として使用するメインメモリである。なお、このＤＲＡＭ１２の代わりに、ＳＲＡＭを使用してもよい。

フラッシュＲＯＭ１３は、この通信装置１を起動させるブートローダ（ブートプログラム）を記憶するブートローダメモリ、ＯＳのファイルであるＯＳイメージを記憶するＯＳイメージメモリ、ファームウェア書き換え中を示すファームウェア書き換え中フラグ（ＯＳ更新中を示す更新中情報を含む）およびファームウェア書き換え完了を示すファームウェア書き換え完了フラグ（ＯＳ更新完了を示す更新完了情報を含む）フラグメモリ、ファームウェアの再書き換えを実行するためのリカバリプログラムを記憶するリカバリプログラムメモリ、管理装置３および各通信装置１の一方から他方への送信データ、各通信装置１の中から１台を特定するそれぞれの機番情報（識別情報）、管理装置３等の通信先のＩＰアドレス，電話番号（発呼先電話番号）、回線接続が成功しなかった場合の再発呼回数（リトライ回数），再発呼間隔などを記憶するデータメモリ（データ領域）として使用する不揮発性メモリ（第１の不揮発性記憶手段）であり、電源がオフになっても記憶内容を保持するようになっている。なお、このフラッシュＲＯＭ１３の代わりに、ＥＥＰＲＯＭ等の他の不揮発性メモリを使用してもよい。

カードメモリコントローラ１４は、カードメモリ１５に対する各種データの読み書きを制御するものである。
カードメモリ１５は、ＳＤメモリ等の記録媒体であり、ＯＳイメージを記憶するＯＳイメージメモリ，アプリ（アプリケーションプログラム）を記憶するアプリメモリや、各種データを記憶するデータメモリとして使用する不揮発性メモリ（第２の不揮発性記憶手段）である。なお、この実施例では、アプリおよびＯＳイメージ（ＯＳファイル）をファームウェアとするが、それらのいずれか、あるいは他のデータをファームウェアとしても構わない。
なお、フラッシュＲＯＭ１３やカードメモリ１５の代わりに、ハードディスク装置等の大容量記憶装置（大容量記憶手段）を用いることもできる。あるいは、不揮発性記憶手段としてフラッシュＲＯＭ１３や大容量記憶装置等の記憶装置を１個のみ使用し、そこにフラッシュＲＯＭ１３として使用する記憶領域とカードメモリ１５として使用する記憶領域を確保するようにしてもよい。

リアルタイムクロック回路１６は、時刻情報を発生するものであり、ＣＰＵ１１がそれを読み込むことによって現在の時刻を知ることができる。
モデム１７は、変復調手段であり、管理装置３へ公衆回線経由でデータを送信する場合、そのデータを公衆回線に流せる形に変調する。また、管理装置３から送られてくる変調されたデータを受信した場合、そのデータを復調する。
ＮＣＵ１８は、公衆回線経由で管理装置３を含む各種外部装置との通信（データの送受信）を制御するものである。
ＮＩＣ１９，２０は、ＬＡＮ（他のネットワークでもよい）上の他の通信装置との通信を制御したり、インタネット５を介して管理装置３を含む各種の外部装置と通信を制御するものである。
電源回路２１は、ＡＣアダプタ２２からのＡＣ電源（商用電源）をＤＣ電源に変換して通信装置１内の上述した各部に供給するものである。

ここで、モデム１７とＣＰＵ１１とは、送信データ（ＴＸ），受信データ（ＲＸ）のデータ線、および送信可能信号（ＣＴＳ），送信要求信号（ＲＴＳ），データセットレディ信号（ＤＳＲ），キャリア検出信号（ＤＣＤ）の信号線によって接続されており、モデム１７はＣＰＵ１１からの送信要求信号（ＲＴＳ）およびキャリア検出信号（ＤＣＤ）に従って制御する。
また、ＮＣＵ１８とモデム１７とは、受信データ（ＲＸＤ）および送信データ（ＴＸＤ）の信号線によって接続されている。受信データ（ＲＸＤ）は管理装置３のモデムにより変調されたアナログ信号、送信データ（ＴＸＤ）はモデム１７によって変調されたアナログ信号である。

次に、管理装置３のハードウェア構成について図４を参照して説明する。
図４は、管理装置３内のハードウェア構成例を示すブロック図である。
この管理装置３は、モデム３１，通信端末３２，プロキシ（Ｐｒｏｘｙ）サーバ３３，操作者端末３４，データベース３５，制御装置３６等からなる。
モデム３１は、公衆回線を介して機器利用者側（通信装置１を利用している顧客先）の通信装置１と通信するものであり、送受信するデータを変復調する。
通信端末３２は、モデム３１による通信を制御するものである。
プロキシサーバ３３は、インタネット５を介して機器利用者側の通信装置１との通信およびセキュリティ管理を行う。

操作者端末３４は、各種データの入力をオペレータによるキーボード又はポインティングデバイス（マウス等）などの入力装置上の操作により受け付ける。入力されるデータとしては、各機器利用者側の通信装置１と通信する際に使用するそれらのＩＰアドレスや電話番号（発呼先電話番号）等の顧客情報がある。
データベース３５は、図示しないサーバのハードディスク装置等の大容量記憶装置に存在し、各機器利用者側の顧客情報および通信装置１の更新用ファームウェア（新バージョンのファームウェア）や制御装置３６のＣＰＵを動作させるためのプログラムを含む各種ソフトウェア、通信装置１から受信したデータ、操作者端末３４から入力されたデータ等を記憶する。
制御装置３６は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ等からなるマイクロコンピュータを備えており、管理装置３全体を統括的に制御する。そのＣＰＵが、データベース３５内の所定のプログラムに従って動作する。

以下、このように構成した遠隔管理システムにおけるこの実施例の特徴となる処理動作について、図５〜図８も参照して具体的に説明する。
まず、通信装置１のＣＰＵ１１による起動時の動作の概要について、図５を参照して説明する。
図５は、通信装置１のＣＰＵ１１による起動時の動作の概要例を示すフローチャートである。
通信装置１のＣＰＵ１１は、電源投入（電源回路２１からの給電）時に、フラッシュＲＯＭ１３内のブートローダに従い、図５の動作を開始する。

そして、まずステップＳ１でフラッシュＲＯＭ１３内のファームウェア書き換え中フラグを参照してファームウェアの書き換えが正常に終了しているか否かをチェックし、正常に終了していなければステップＳ４でフラッシュＲＯＭ１３内のＯＳを起動させる。
すなわち、フラッシュＲＯＭ１３内のＯＳイメージを読み出し、それをＤＲＡＭ１２にロードして使用可能なＯＳに展開した後、そのＯＳを起動させる。
次に、ステップＳ５で後述するリカバリ処理を行う。
すなわち、フラッシュＲＯＭ１３内のリカバリプログラムを読み出し、それをＤＲＡＭ１２にロードして展開した後、そのリカバリプログラムを起動させてリカバリ処理を行う。

一方、ファームウェアの書き換えが正常に終了している場合には、ステップＳ２でカードメモリ１５内のＯＳを起動させる。
すなわち、カードメモリコントローラ１４を制御してカードメモリ１５内のＯＳイメージを読み出し、それをＤＲＡＭ１２にロードして使用可能なＯＳに展開した後、そのＯＳを起動させる。
そして、正常に起動すると、ステップＳ３の通常動作のモードに進む。
このモード時には、何らかの要求があった場合に、その要求に応じた動作（通常動作）を行う。このとき、必要に応じて所要のアプリをカードメモリ１５から読み出し、それをＤＲＡＭ１２にロードして展開して起動させる。

ここで、通信装置１のＣＰＵ１１が、フラッシュＲＯＭ１３内のブートローダに基づいて動作することによってＯＳ起動手段としての機能を、ＤＲＡＭ１２に展開したＯＳおよびリカバリプログラムに基づいて動作することによって送信要求有無問合手段，ダウンロード手段，第１の状態情報制御手段，ＯＳ更新手段，第２の状態情報制御手段，ＯＳ起動手段，ＯＳ更新失敗通知手段，ＯＳ更新失敗通知手段，第３の状態情報制御手段を含む各種手段としての機能をそれぞれ実現することができる。

次に、通信装置１のＣＰＵ１１による起動（再起動を含む）時の動作の詳細と管理装置３によるファームウェアの更新（書き換え）に関する動作の概要について、図６〜図８を参照して説明する。なお、ここでは、通信装置１がＮＩＣ１９又は２０を、管理装置３がプロキシサーバ３３をそれぞれ使用することにより、互いにインタネット５経由で通信を行うものとするが、通信装置１がモデム１７およびＮＣＵ１８を、管理装置３がモデム３１および通信端末３２をそれぞれ使用することにより、互いに図示しない公衆回線経由で通信を行うこともできる。

図６および図７は、通信装置１のＣＰＵ１１による起動時の動作の詳細例を示すフローチャートである。
図８は、通信装置１と管理装置３との通信シーケンスの一例を示す説明図である。
通信装置１のＣＰＵ１１は、電源投入（電源回路２１からの給電）時に図６，図７の動作を開始し、まずステップＳ１１でフラッシュＲＯＭ１３内のブートローダを起動させ、そのブートローダに従い、ステップＳ１２でフラッシュＲＯＭ１３内のファームウェア書き換え中フラグ（以下「ファーム書き換え中フラグ」ともいう）の状態（有無）をチェックし、ファーム書き換え中フラグが“０”にリセット（設定解除）されていればステップＳ１３へ、“１”にセット（設定）されていればステップＳ２６へそれぞれ移行する。

ステップＳ１３では、カードメモリ１５内のＯＳイメージ（当該通信装置１の通常動作用ＯＳ）を読み出し、それをＤＲＡＭ１２にロードして使用可能なＯＳに展開する。
ＤＲＡＭ１２へのＯＳの展開が完了すると、ステップＳ１４でそのＯＳを起動させ、ステップＳ１５へ移行する。
ステップＳ１５では、カードメモリ１５内のアプリ（当該通信装置１の通常動作用アプリ）を読み出し、それをＤＲＡＭ１２にロードして展開した後、そのアプリを起動させる。このアプリの起動により、通信装置１としての動作が可能になる。
その後、ステップＳ１６でフラッシュＲＯＭ１３内のファームウェア書き換え完了フラグ（以下「ファーム書き換え完了フラグ」ともいう）の状態をチェックし、ファーム書き換えフラグが“０”にリセットされていればステップＳ２０へ、“１”にセットされていればステップＳ１７へそれぞれ移行する。

ステップＳ２０の通常動作のモード時には、前述したように、何らかの要求があった場合に、その要求に応じた動作（通常動作）を行う。
この通常動作のモード中に、定期的にステップＳ２１へ移行し、管理装置３からインタネット５経由でファームウェア書き換え要求（以下「ファーム書き換え要求」ともいう）がなければステップＳ２０へ戻るが、ファーム書き換え要求があればステップＳ２２へ移る。そして、管理装置３から書き換え（更新）用のファームウェア（例えば新バージョンのＯＳ，アプリ，又はその両者）をダウンロードする。

ここで、通信装置１は、ファイアウォール７経由で管理装置３と通信可能にするため、図示しないタイマを使用して時間管理を行い、例えば図８に示すように、管理装置３に対してファイアウォール７およびインタネット５経由で定期的にポーリング（送信要求があるかどうかの問い合わせ）を行うようにしている。
管理装置３の制御装置３６は、データベース３５に書き換え用のファームウェアがある場合、いずれかの通信装置１からのポーリングにより、ファーム書き換えをその通信装置１に対して要求する。
通信装置１のＣＰＵ１１は、管理装置３からファーム書き換え要求があった場合に、ファーム書き換え要求を受けた旨（応答）を管理装置３へ通知した後、書き換え用のファームウェアを管理装置３に対して要求する。
管理装置３の制御装置３６は、ポーリング元の通信装置１から書き換え用のファームウェアの要求があると、データベース３５内の書き換え用のファームウェアをその通信装置１へダウンロードする。

なお、通信装置１側にファイアウォール７が設けられ、そのファイアウォール７が管理装置３からの通信要求を通信装置１へ通さないように設定されている場合には、管理装置３は通信装置１に対してファーム書き換え要求を行っても、その要求がファイアウォール７で遮断され、通信装置１に届かない。しかし、通信装置１から管理装置３に対してポーリングを行った場合に、管理装置３からの通信要求を通信装置１へ通すような設定がファイアウォール７でなされていれば、管理装置３はポーリングを受けた時に、通信装置１に対してファーム書き換え要求を行うことにより、その要求はファイアウォール７を介して通信装置１に届くことになる。
もし、通信装置１側でセキュリティ面を考慮する必要がなければ、ファイアウォール７を設けないか、そのファイアウォール７に対して管理装置３からの通信要求を通信装置１へ通すように設定すればよく、その場合には、管理装置３は通信装置１からポーリングを受けることなく、その通信装置３に対してファーム書き換え要求を行えば、その要求は通信装置１に届くことになる。

通信装置１のＣＰＵ１１は、管理装置３からの書き換え用ファームウェアのダウンロードが終了すると、図６のステップＳ２４でそのダウンロードの結果をチェックし、そのダウンロードが失敗した場合にはその旨を通信装置１の識別情報と共に管理装置３へ通知し、ステップＳ２０へ戻る。書き換え用ファームウェアのダウンロードが失敗した旨を管理装置３へ通知するのは、管理装置３にそのダウンロードが失敗したことを認識させ、同じ書き換え用ファームウェアを再度送ってもらうためである。
書き換え用ファームウェアのダウンロードが成功した場合には、図７のＡへ移行し、ステップＳ３３で書き換え用ファームウェアのダウンロードが成功した旨を通信装置１の識別情報と共に管理装置３へ通知し、ステップＳ３４でフラッシュＲＯＭ１３内のファーム書き換え中フラグを“１”にセットする。

その後、ステップＳ３５でダウンロードした書き換え用のファームウェアに基づいてカードメモリ１５内のファームウェアの書き換えを実施する。
すなわち、ダウンロードした書き換え用のファームウェアがアプリであれば、カードメモリ１５内のアプリをダウンロードしたアプリに書き換える。ダウンロードした書き換え用のファームウェアがＯＳとアプリであれば、カードメモリ１５内のＯＳとアプリをダウンロードしたＯＳとアプリに書き換える。

ファームウェアの書き換えが終了すると、ステップＳ３６でその書き換えが成功したか失敗したかをチェックし、失敗すればステップＳ３９へ移行する。
ファームウェアの書き換えが成功した場合には、ステップＳ３７でフラッシュＲＯＭ１３内のファーム書き換え中フラグを“０”にリセットすると共に、ファーム書き換え完了フラグを“１”にセットした後、ステップＳ３９でこの通信装置１を再起動させ、図６のＢへ移行して、再びステップＳ１１以降の各処理を行う。

ファームウェアの書き換えが成功し、フラッシュＲＯＭ１３内のファーム書き換え中フラグが“０”にリセットされ、且つファーム書き換え完了フラグが“１”にセットされている場合には、ステップＳ１１〜Ｓ１５の処理を行い、ステップＳ１６のファーム書き換え完了フラグの状態チェックで“１”と判断するため、ステップＳ１７でファームウェアの書き換え完了を通信装置１の識別情報と共に管理装置３へ通知し、ステップＳ１８でフラッシュＲＯＭ１３内のファーム書き換え完了フラグを“０”にリセットした後、ステップＳ１９でカードメモリ１５内の書き換え後のファームウェアに基づいてフラッシュＲＯＭ１３内のファームウェアを書き換える。但し、その書き換えは、カードメモリ１５内の書き換え後のファームウェアにＯＳが含まれている場合だけ行う。

ここで、図７のステップＳ３５でファームウェアの書き換えを実施している最中に、機器利用者の誤操作等によって電源が遮断された場合、フラッシュＲＯＭ１３内のファーム書き換え中フラグは“１”を保持している。
そして、この状態で再び電源が投入された場合には、ＣＰＵ１１は図６の動作を再開し、上述と同様にステップＳ１１でフラッシュＲＯＭ１３内のブートローダを起動させ、そのブートローダに従い、ステップＳ１２でフラッシュＲＯＭ１３内のファーム書き換え中フラグの状態をチェックする。

この場合、フラッシュＲＯＭ１３内のファーム書き換え中フラグは“１”であるため、カードメモリ１５内のＯＳイメージの書き換え失敗を判断して、ステップＳ２６へ移行する。
ステップＳ２６では、フラッシュＲＯＭ１３内のレスキュー用ＯＳイメージを読み出し、それをＤＲＡＭ１２にロードして使用可能なＯＳに展開する。
ＤＲＡＭ１２へのレスキュー用ＯＳの展開が完了すると、ステップＳ２７でそのＯＳを起動させ、ステップＳ２８へ移行する。
ステップＳ２８では、フラッシュＲＯＭ１３内のリカバリプログラムを読み出し、それをＤＲＡＭ１２にロードして展開した後、そのリカバリプログラムを起動させる。

その後、リカバリプログラムに従い、ステップＳ２９で書き換え用ファームウェアの書き換え（更新）が失敗した旨を通信装置１の識別情報と共に管理装置３へ通知してステップＳ３０へ移行し、管理装置３からファーム書き換え要求がなければ、ステップＳ３２でファームウェアの書き換えが失敗した旨を図示しない表示部に表示するなどのエラー処理を行って、処理を終了する。書き換え用ファームウェアの書き換えが失敗した旨を管理装置３へ通知するのは、管理装置３にその書き換えが失敗したことを認識させ、同じ書き換え用ファームウェアを再度送ってもらうためである。
管理装置３からファーム書き換え要求があった場合には、ステップＳ３１で管理装置３に対して書き換え用ファームウェアのダウンロードを要求し、ステップＳ２３で管理装置３から書き換え用ファームウェアをダウンロードし、以後上述と同様の処理を繰り返す。

この実施例の通信装置１によれば、以下の（１）〜（８）に示す作用効果を得ることができる。
（１）通信装置１のＣＰＵ１１が、管理装置３からファームウェア（ＯＳを含む）の書き換え（更新）要求があった場合に、管理装置３から書き換え用のファームウェアをダウンロードし、そのダウンロードが成功した場合に、フラッシュＲＯＭ１３内のファーム書き換え中フラグを“１”にセットし、その後の通信装置１の起動（ブートローダの起動）時に、ファーム書き換え中フラグの状態をチェックし、ファーム書き換え中フラグが“０”にリセットされている場合には、カードメモリ１５内のＯＳおよびアプリを順次ＤＲＡＭ１２に展開させて起動させ、ファーム書き換え中フラグが“１”にセットされている場合には、フラッシュＲＯＭ１３内のＯＳおよびリカバリプログラムを順次ＤＲＡＭ１２に展開させて起動させることにより、管理装置３から書き換え用ファームウェアをダウンロードしてファームウェアの書き換えを行う場合に、電源遮断（他のトラブル発生でもよい）によってそのファームウェアの書き換えが失敗した場合でも、その後の電源投入による再起動時にその失敗を簡単且つ確実に判断することができる。

（２）通信装置１のＣＰＵ１１が、上述したようにフラッシュＲＯＭ１３内のＯＳおよびリカバリプログラムを順次ＤＲＡＭ１２に展開させて起動させた場合には、その後ファームウェア書き換え失敗を通信装置１の識別情報と共に管理装置３へ通知することにより、その管理装置３から書き換え用ファームウェアを再ダウンロードしてファームウェアの書き換えを開始させることが可能になるため、ファームウェアの書き換えを確実に完了させることが可能になる。

（３）通信装置１のＣＰＵ１１が、フラッシュＲＯＭ１３内のファーム書き換え中フラグを“１”にセットした後、上記書き換え用ファームウェアに基づいてカードメモリ１５内のファームウェアを書き換えることにより、管理装置３から書き換え用ファームウェアをダウンロードしてファームウェアの書き換えを行っている最中に、電源遮断によってそのファームウェアの書き換えが失敗した場合でも、その後の電源投入による再起動時にその失敗を簡単且つ確実に判断することができる。

（４）通信装置１のＣＰＵ１１が、管理装置３へのファームウェア書き換え失敗の通知に対して、その管理装置３から再びファームウェアの書き換え要求があった場合に、書き換え用ファームウェアを再ダウンロードしてファームウェアの書き換えを開始させることにより、ファームウェアの書き換えをより確実に完了させることが可能になる。

（５）通信装置１のＣＰＵ１１が、管理装置３へのファームウェア書き換え失敗の通知に対して、その管理装置３から再びファームウェアの書き換え要求があった場合に、ファームウェア書き換え要求を受けた旨を通信装置１の識別情報と共に管理装置３へ通知すれば、管理装置３側では通信装置１でファームウェアの書き換え要求を受けたことを確認できるため、書き換え用ファームウェアを通信装置１へ直ちにダウンロードできるように準備しておくことができる。

（６）通信装置１のＣＰＵ１１が、管理装置３に対して定期的に送信要求があるかどうかの問い合わせを行い、その問い合わせに対して、管理装置３からファームウェア書き換え要求があった場合に、管理装置３に対して書き換え用ファームウェアを要求することにより、管理装置３から書き換え用ファームウェアをダウンロードできるため、管理装置３に書き換え用ファームウェアがある場合、管理装置３からファームウェア書き換え要求を確実に受けることができる。

（７）通信装置１のＣＰＵ１１が、フラッシュＲＯＭ１３内のファーム書き換え中フラグを“１”にセットした後、管理装置３からダウンロードした書き換え用ファームウェアに基づいてカードメモリ１５内のファームウェアの書き換えを行い、その書き換えが成功した場合に、フラッシュＲＯＭ１３内のファーム書き換え中フラグを“０”にリセットすると共に、ファーム書き換え完了フラグを“１”にリセットすれば、そのファーム書き換え完了フラグの状態を参照することにより、フラッシュＲＯＭ１３内のファームウェアの書き換えが完了したことを確実に認識することが可能になる。

（８）通信装置１のＣＰＵ１１が、カードメモリ１５内のファームウェアが起動し、フラッシュＲＯＭ１３内のファーム書き換え完了フラグが“１”にセットされている場合には、ファーム書き換え完了を管理装置３へ通知し、該通知が終了した後、ファーム書き換え完了フラグを“０”にリセットし、カードメモリ１５内のファームウェアに基づいてフラッシュＲＯＭ１３内のファームウェアを書き換えることにより、以後のファームウェア書き換え失敗時にも比較的新しいファームウェアを用いて処理を行うことができる。

なお、この発明によるプログラムは、通信装置１を制御するコンピュータに、送信要求有無問合手段，ダウンロード手段，第１の状態情報制御手段，ＯＳ更新手段，第２の状態情報制御手段，ＯＳ起動手段，ＯＳ更新失敗通知手段，ＯＳ更新失敗通知手段，第３の状態情報制御手段を含む各種手段としての機能を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。

このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。

この発明を、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等や、ネットワークに接続可能なコンピュータ等も含め、通信機能を備えた各種通信装置（被管理装置）、その通信装置とそれを管理する管理装置とからなる遠隔管理システムに適用可能である。

この発明による通信装置を被管理装置とする遠隔管理システムの構成例を示す概念図である。 その遠隔管理システムにおけるデータ送受モデルを示す概念図である。 図１の通信装置１のハードウェア構成例を示すブロック図である。 図１の管理装置３内のハードウェア構成例を示すブロック図である。 図３のＣＰＵ１１による起動時の動作の概要例を示すフロー図である。 同じく起動時の動作の詳細例を示すフロー図である。 その続きを示すフロー図である。 図１の通信装置１と管理装置３との通信シーケンスの一例を示す説明図である。

符号の説明

１：通信装置 ３：管理装置 ５：インタネット ７：ファイアウォール １１：ＣＰＵ １２：ＤＲＡＭ １３：フラッシュＲＯＭ １４：カードメモリコントローラ １５：カードメモリ １６：リアルタイムクロック回路 １７：モデム １８：ＮＣＵ １９，２０：ＮＩＣ ２１：電源回路 ３１：モデム ３２：通信端末 ３３：プロキシサーバ ３４：操作者端末 ３５：データベース ３６：制御装置

Claims (14)

1. 第１，第２の不揮発性記憶手段と、外部装置からＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードするダウンロード手段と、該手段によってダウンロードされたＯＳに基づいて前記第１，第２の不揮発性記憶手段内のＯＳを更新するＯＳ更新手段とを有する通信装置であって、
   前記ダウンロード手段による更新用ＯＳのダウンロードが成功した場合に、ＯＳ更新中を示す更新中情報を前記第１の不揮発性記憶手段に設定する第１の状態情報制御手段と、
   当該通信装置の起動時に、前記更新中情報の設定の有無をチェックし、該更新中情報が設定されていない場合には前記第２の不揮発性記憶手段内のＯＳを、該更新中情報が設定されている場合には前記第１の不揮発性記憶手段内のＯＳをそれぞれ起動させるＯＳ起動手段と、
   該手段によって前記第２の不揮発性記憶手段内のＯＳが起動された後、該不揮発性記憶手段内のアプリケーションプログラムを起動させるアプリケーションプログラム起動手段と、
   前記ＯＳ更新手段による前記第２の不揮発性記憶手段内のＯＳの更新が成功した場合に、前記更新中情報の設定を解除すると共に、ＯＳ更新完了を示す更新完了情報を前記第１の不揮発性記憶手段に設定する第２の状態情報制御手段と、
   前記ＯＳ起動手段および前記アプリケーションプログラム起動手段によって前記第２の不揮発性記憶手段内のＯＳおよびアプリケーションプログラムが順次起動し、且つ前記更新完了情報が設定されている場合には、ＯＳ更新完了を前記外部装置へ通知するＯＳ更新完了通知手段と、
   該手段による通知が終了した後、前記更新完了情報の設定を解除する第３の状態情報制御手段とを設け、
   前記ＯＳ更新手段は、前記第１の状態情報制御手段によって前記更新中情報が設定された後、前記更新用ＯＳに基づいて前記第２の不揮発性記憶手段内のＯＳを更新する手段と、前記第３の状態情報制御手段によって前記更新完了情報の設定が解除された後、前記第２の不揮発性記憶手段内のＯＳに基づいて前記第１の不揮発性記憶手段内のＯＳを更新する手段とを有することを特徴とする通信装置。
2. 請求項１記載の通信装置において、
   前記ＯＳ起動手段によって前記第１の不揮発性記憶手段内のＯＳが起動された場合には、ＯＳ更新失敗を前記外部装置へ通知するＯＳ更新失敗通知手段を設けたことを特徴とする通信装置。
3. 請求項２記載の通信装置において、
   前記ダウンロード手段は、前記ＯＳ更新失敗通知手段による前記外部装置へのＯＳ更新失敗の通知に対して、該外部装置から再びＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードする手段を有することを特徴とする通信装置。
4. 管理装置によってネットワーク経由で複数の通信装置を遠隔管理する遠隔管理システムであって、
   前記通信装置に、第１，第２の不揮発性記憶手段と、前記管理装置からＯＳ更新要求があった場合に、該管理装置から更新用ＯＳをダウンロードするダウンロード手段と、該手段によってダウンロードされたＯＳに基づいて前記第１，第２の不揮発性記憶手段内のＯＳを更新するＯＳ更新手段と、前記ダウンロード手段による更新用ＯＳのダウンロードが成功した場合に、ＯＳ更新中を示す更新中情報を前記第１の不揮発性記憶手段に設定する第１の状態情報制御手段と、当該通信装置の起動時に、前記更新中情報の設定の有無をチェックし、該更新中情報が設定されていない場合には前記第２の不揮発性記憶手段内のＯＳを、該更新中情報が設定されている場合には前記第１の不揮発性記憶手段内のＯＳをそれぞれ起動させるＯＳ起動手段と、該手段によって前記第２の不揮発性記憶手段内のＯＳが起動された後、該不揮発性記憶手段内のアプリケーションプログラムを起動させるアプリケーションプログラム起動手段と、前記ＯＳ更新手段による前記第２の不揮発性記憶手段内のＯＳの更新が成功した場合に、前記更新中情報の設定を解除すると共に、ＯＳ更新完了を示す更新完了情報を前記第１の不揮発性記憶手段に設定する第２の状態情報制御手段と、前記ＯＳ起動手段および前記アプリケーションプログラム起動手段によって前記第２の不揮発性記憶手段内のＯＳおよびアプリケーションプログラムが順次起動し、且つ前記更新完了情報が設定されている場合には、ＯＳ更新完了を当該通信装置の識別情報と共に前記管理装置へ通知するＯＳ更新完了通知手段と、該手段による通知が終了した後、前記更新完了情報の設定を解除する第３の状態情報制御手段とを設け、
   前記通信装置のＯＳ更新手段は、前記第１の状態情報制御手段によって前記更新中情報が設定された後、前記更新用ＯＳに基づいて前記第２の不揮発性記憶手段内のＯＳを更新する手段と、前記第３の状態情報制御手段によって前記更新完了情報の設定が解除された後、前記第２の不揮発性記憶手段内のＯＳに基づいて前記第１の不揮発性記憶手段内のＯＳを更新する手段とを有することを特徴とする遠隔管理システム。
5. 請求項４記載の遠隔管理システムにおいて、
   前記通信装置に、前記ＯＳ起動手段によって前記第１の不揮発性記憶手段内のＯＳが起動された場合には、ＯＳ更新失敗を当該通信装置の識別情報と共に前記管理装置へ通知するＯＳ更新失敗通知手段を設けたことを特徴とする遠隔管理システム。
6. 請求項５記載の遠隔管理システムにおいて、
   前記通信装置に、前記管理装置に対して定期的に送信要求があるかどうかの問い合わせを行う送信要求有無問合手段を設け、
   前記通信装置のダウンロード手段は、前記送信要求有無問合手段による前記管理装置への送信要求の問い合わせに対して、該管理装置からＯＳ更新要求があった場合に、該管理装置に対して更新用ＯＳを要求することにより、該管理装置から更新用ＯＳをダウンロードする手段であることを特徴とする遠隔管理システム。
7. 請求項５又は６記載の遠隔管理システムにおいて、
   前記通信装置のダウンロード手段は、前記ＯＳ更新失敗通知手段による前記管理装置へのＯＳ更新失敗の通知に対して、該外部装置から再びＯＳ更新要求があった場合に、該管理装置に対して更新用ＯＳを要求することにより、該管理装置から更新用ＯＳをダウンロードする手段を有することを特徴とする遠隔管理システム。
8. 第１，第２の不揮発性記憶手段と、外部装置から更新用ＯＳをダウンロードし、該ＯＳに基づいて前記第１，第２の不揮発性記憶手段内のＯＳを更新する通信装置におけるＯＳ更新方法であって、
   外部装置からＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードし、
   該ダウンロードが成功した場合に、ＯＳ更新中を示す更新中情報を前記第１の不揮発性記憶手段に設定した後、前記更新用ＯＳに基づいて前記第２の不揮発性記憶手段内のＯＳを更新し、
   該更新が成功した場合に、前記更新中情報の設定を解除すると共に、ＯＳ更新完了を示す更新完了情報を前記第１の不揮発性記憶手段に設定し、
   当該通信装置の起動時に、前記更新中情報の設定の有無をチェックし、
   該更新中情報が設定されていない場合には、前記第２の不揮発性記憶手段内のＯＳおよびアプリケーションプログラムを順次起動させた後、前記更新完了情報が設定されている場合には、ＯＳ更新完了を前記外部装置へ通知して、前記更新完了情報の設定を解除した後、前記第２の不揮発性記憶手段内のＯＳに基づいて前記第１の不揮発性記憶手段内のＯＳを更新し、
   前記更新中情報が設定されている場合には、前記第１の不揮発性記憶手段内のＯＳを起動させることを特徴とするＯＳ更新方法。
9. 請求項８記載のＯＳ更新方法において、
   前記第１の不揮発性記憶手段内のＯＳが起動した場合には、ＯＳ更新失敗を前記外部装置へ通知することを特徴とするＯＳ更新方法。
10. 請求項９記載のＯＳ更新方法において、
    前記外部装置への前記ＯＳ更新失敗の通知に対して、該外部装置から再びＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードすることを特徴とするＯＳ更新方法。
11. 第１，第２の不揮発性記憶手段を有する通信装置を制御するコンピュータに、
    外部装置からＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードするダウンロード機能と、該機能による更新用ＯＳのダウンロードが成功した場合に、ＯＳ更新中を示す更新中情報を前記第１の不揮発性記憶手段に設定する第１の状態情報制御機能と、該機能によって前記更新中情報が設定された後、前記更新用ＯＳに基づいて前記第２の不揮発性記憶手段内のＯＳを更新するＯＳ更新機能と、該機能による更新が成功した場合に、前記更新中情報の設定を解除すると共に、ＯＳ更新完了を示す更新完了情報を前記第１の不揮発性記憶手段に設定する第２の状態情報制御機能と、当該通信装置の起動時に、前記更新中情報の設定の有無をチェックし、該更新中情報が設定されていない場合には前記第２の不揮発性記憶手段内のＯＳを、該更新中情報が設定されている場合には前記第１の不揮発性記憶手段内のＯＳをそれぞれ起動させるＯＳ起動機能と、該機能によって前記第２の不揮発性記憶手段内のＯＳが起動された後、該不揮発性記憶手段内のアプリケーションプログラムを起動させるアプリケーションプログラム起動機能と、前記ＯＳ起動機能および前記アプリケーションプログラム起動機能によって前記第２の不揮発性記憶手段内のＯＳおよびアプリケーションプログラムが順次起動し、且つ前記更新完了情報が設定されている場合には、ＯＳ更新完了を前記外部装置へ通知するＯＳ更新完了通知機能と、該機能による通知が終了した後、前記更新完了情報の設定を解除する第３の状態情報制御機能とを実現させるためのプログラムであり、
    前記ＯＳ更新機能が、前記第３の状態情報制御機能によって前記更新完了情報の設定が解除された後、前記第２の不揮発性記憶手段内のＯＳに基づいて前記第１の不揮発性記憶手段内のＯＳを更新する機能を有することを特徴とするプログラム。
12. 請求項１１記載のプログラムにおいて、
    前記コンピュータに、
    前記ＯＳ起動機能によって前記第１の不揮発性記憶手段内のＯＳが起動された場合には、ＯＳ更新失敗を前記外部装置へ通知するＯＳ更新失敗通知機能をも実現させるためのプログラム。
13. 請求項１２記載のプログラムにおいて、
    前記ダウンロード機能が、前記ＯＳ更新失敗通知機能による前記外部装置へのＯＳ更新失敗の通知に対して、該外部装置から再びＯＳ更新要求があった場合に、該外部装置から更新用ＯＳをダウンロードする機能を有することを特徴とするプログラム。
14. 請求項１１乃至１３のいずれか一項に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images