(57)【要約】  本発明は、ローカルネットワークに接続するためのネットワーク装置およびこの種の装置のスタートアップを監視するための方法に関する。  この装置はソフトウエア（５，６，７）を記憶するための１つの永続メモリ（４）を有しており、かつ有利には次の構成要素も有している：  −  前記ネットワークに接続するための通信手段（８，９）、  −  ソフトウェア故障を検出するための装置のスタートアップを監視するための手段（１０）、  −  該監視手段による故障の検出に応答してソフトウェア故障信号を生成しかつネットワーク上に前記故障の通報を自動的に送信するための手段（１０）、ここで該通報は前記少なくとも１つのソフトウェアサーバによって受信されるようにネットワーク上に同報される。【特許請求の範囲】
【請求項１】
ローカルネットワークに接続するためのネットワーク装置であって、
前記ネットワークは少なくとも１つのソフトウェアサーバを有しており、
前記装置はソフトウエア（５，６，７）を記憶するための１つの永続メモリ（４）を有している
形式のものにおいて、
−  前記ネットワークに接続するための通信手段（８，９）を備え、
−  ソフトウェア故障を検出するための装置のスタートアップを監視するための手段（１０）を備え、
−  該監視手段による故障の検出に応答してソフトウェア故障信号を生成しかつネットワーク上に前記故障の通報を自動的に送信するための手段（１０）を備え、ここで該通報は前記少なくとも１つのソフトウェアサーバによって受信されるようにネットワーク上に同報される
ことを特徴とするネットワーク装置。
【請求項２】
故障信号は次のものの少なくとも１つを特定するための情報を有している：
−  故障の性質もしくはその内容、
−  ダウンロードされるべきリプレースメントソフトウェアの識別、
−  永続メモリに現在記憶されているソフトウェアのバージョンの識別
請求項１記載の装置。
【請求項３】
ソフトウェアは次のものの少なくとも１つを特定するための情報を有している：
−  ブートプログラム（６）、
−  コンフィギュレーションデータ（５）、
−  ファームウェア（７）
請求項１または２記載の装置。
【請求項４】
ソフトウェアはファームウェアを有しており、
スタートアップを監視するための手段（１０）は
−  現在のファームウェア検証パターンの妥当性をチェックする（３６）ための手段（１０）を備え、および
−  前記検証パターンが妥当ではないときに特定のソフトウェアスタートアップ故障信号（３７）を生成する（３９）ための手段（１０）を備えている
請求項３記載の装置。
【請求項５】
スタートアップを監視するための手段（１０）は
−  現在のソフトウェアのチェックサムを計算する（３３）ための手段を備え、
−  前記計算されたチェックサムを予め記憶されているチェックサムと比較する（３３）ための手段を備え、
−  前記計算されたチェックサムが記憶されているものと一致しないときにスタートアップ故障信号（３４）を生成する（３９）ための手段を備えている
請求項１記載の装置。
【請求項６】
前記メモリはファームウェアを有しており、
スタートアップを監視するための手段（１０）は
−  前記メモリ手段（４）におけるファームウェアの存在をチェックする（４３）ための手段を備え、
−  前記メモリ（４）にファームウェアが記憶されていないときにスタンドアローン形装置を再度立ち上げる（３０）ための手段を備え、
−  前記メモリ（４）にファームウェアが記憶されていないときにソフトウェアスタートアップ故障信号（４４）を生成する（３９）ための手段を備えている
請求項３記載の装置。
【請求項７】
スタートアップを監視するための手段（１０）は
−  リプレースメントソフトウェアの、前記メモリ（４）へのダウンロードをチェックする（４０）ための手段を備え、
−  当該装置を再度立ち上げるための手段および前記ダウンロードの期間に問題が検出されたときソフトウェアスタートアップ故障信号（４２）を生成するための手段を備えている
請求項１から６までのいずれか１項記載の装置。
【請求項８】
ソフトウェアはファームウェアを有しており、かつ
当該装置は
−  リプレースメントファームウェア（７）が前記メモリに適正に記録されたとき、ダウンロードされたリプレースメントファームウェアに相応してリプレースメント検証パターン（１７）を前記メモリ（４）に書き込む（４１）ための手段を備えている
請求項３、４または７のいずれか１項記載の装置。
【請求項９】
スタートアップを監視するための手段（１０）は
−  ソフトウェアをロードする過程を監視する（４６）ための手段を備え、
−  スタンドアローン形装置を再度立ち上げる（３０）ための手段および前記ロード期間に問題が生じたときにソフトウェアスタートアップ故障信号（４８）を生成するための手段を備えている
請求項１から８までのいずれか１項記載の装置。
【請求項１０】
ソフトウェアスタートアップを監視するための手段（１０）は
−  スタートアップタイムリミットを検出するためのタイマーを備え、
−  ソフトウェアスタートアップを開始させる（４５）ための手段を備え、該ソフトウェアはスタートアップの完了後の、前記監視手段に対するスタートアップ終了指示に適合しており、
−  タイムリミットの終了前にスタートアップが完了しなかった場合に、ソフトウェアスタートアップ故障信号（４８）を生成するための手段を備えている
請求項１から９までのいずれか１項記載の装置。
【請求項１１】
当該装置は更に監視手段（１０）に接続されている、ユーザがリプレースメントソフトウェアのダウンロードを手動で要求できるようにするためのユーザ処置可能な手段（１１）を有している
請求項１から１０までのいずれか１項記載の装置。
【請求項１２】
当該装置は更に監視手段（１０）に接続されている、スタートアップ故障をユーザに通報するためのアラーム（１２）を有している
請求項１から１１までのいずれか１項記載の装置。
【請求項１３】
ソフトウェアスタートアップ故障信号を生成するための手段（１０）は
−  故障フラグのセットを監視する（３８）ための手段を備え、
−  ソフトウェア故障信号を生成し（３９）かつセットされた故障フラグの検出に応答して該ソフトウェア故障信号をネットワーク上に伝送するための手段を備えている
請求項１から１２までのいずれか１項記載の装置。
【請求項１４】
故障の性質もしくは内容の指示は一連の状態フラグを有している
請求項１から１３までのいずれか１項記載の装置。
【請求項１５】
前記通報は更に永続メモリに現在記憶されているソフトウェアのバージョンの識別を有している
請求項１４記載の装置。
【請求項１６】
ネットワーク装置がソフトウエア（５，６，７）を記憶するための１つの永続メモリ（４）と少なくとも１つのソフトウェアサーバ（３）を有しているネットワーク（２）に接続するための通信手段（８，９）とを有しているという、ネットワーク装置のソフトウェアスタートアップを監視するための方法であって、該過程は次のステップを有している：
−  ソフトウェアスタートアップ故障を検出するために装置のソフトウェアスタートアップを監視し（３２，３３，３６，３８，４０，４３，４６）、
−  スタートアップソフトウェア故障の検出に応答してソフトウェアスタートアップ故障信号を生成し（３４，３５，３７，４２，４４，４８）、
−  前記少なくとも１つのソフトウェアサーバに受信されるようにするためにソフトウェア故障信号をネットワーク（２）上に自動的に同報する（３９）
方法。
【請求項１７】
ソフトウェア故障信号はリプレースメントソフトウェアを前記メモリ（４）にダウンロードするようにする、少なくとも１つのソフトウェアサーバに対する要求（３９）を有している
請求項１６記載の方法。
【請求項１８】
ソフトウェア故障信号は前記少なくとも１つのサーバによって解析されるための、故障の識別を有している
請求項１６記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク装置およびこの種の装置のソフトウェアスタートアップを監視するための方法に関する。
【０００２】
ＤＳＬモデム、ブリッジまたはルータまたはその組み合わせのようなスタンドアローン形ネットワーキング装置は例えばローカルエリアネットワークをインターネットのようなアクセスネットワークと取り持つために使用される。
【０００３】
一般に、スタンドアローン形装置はリード・オンリーメモリ（ＲＯＭ）および／または電気的に消去可能なプログラマブルリード・オンリーメモリ（ＥＥＰＲＯＭ）のような永続メモリ、すなわちいわゆるオンボードメモリ手段を有している。このメモリはとりわけ、スタートアップを開始しかつ装置コンフィギュレーションパラメータ、立ち上げ、すなわちブートソフトウエアおよびファームウェアのような装置を実行するために必要であるデータおよびソフトウェアを含んでいる。
【０００４】
スタートアップを保証するために、スタンドアローン形装置には上述したアイテムのいくつかの２つのコピー、すなわち装置コンフィギュレーション、ブートソフトウェアおよびファームウェアを含んでいるものがある。しかしモデムのいくつかはこれらデータシングルコピーを格納するのがやっとである大きさの永続メモリを有してさえいればよい。
【０００５】
その場合、これらのデータが歪みを受けているとすれば、装置は当然機能するのをやめかつ永続メモリは新しい有効なファームウェアまたはコンフィギュレーションまたはブートプログラムをリカバーする。
【０００６】
この状況は例えば、モデムが適当なサーバーからアプグレードなソフトウェアをダウンロードするとき起こる可能性がある。永続メモリはソフトウェアのワンコピーしか保持することができないので、古いソフトウェアは更新されたソフトウェアが完全に記録される前に消去される。コネクションが遮断されるまたは装置がダウンロードの期間にパワーダウンすると、ソフトウェアは歪みを受ける。
【０００７】
従ってソフトウェアまたはハードウェア不足もしくは欠如のために装置はパワーアップフェーズまたは再立ち上げの期間に自動的に停止に至る可能性がある。
【０００８】
このような場合、装置は通例当然機能するのを停止しかつＬＥＤインジケータによりエンドユーザに問題状態を通知する。
【０００９】
例えばＵＳ６５２６０９２からモデムがホストパーソナルコンピュータに通じている電話線を介して更新されたオペレーティングコードをダウンロードしかつホストパーソナルコンピュータからシリアルポートを介してモデムのメモリをリプログラミングできるようにすることが公知である。
【００１０】
本発明は、ローカルネットワークに接続するためのネットワーク装置であって、ネットワークは少なくとも１つのソフトウェアサーバを有しており、この装置はソフトウエアを記憶するための１つの永続メモリを有している形式のものにおいて、
−  ネットワークに接続するための通信手段を備え、
−  ソフトウェア故障を検出するための装置のスタートアップを監視するための手段を備え、
−  該監視手段による故障の検出に応答してソフトウェア故障信号を生成しかつネットワーク上に故障の通報を自動的に送信するための手段を備え、ここで該通報は少なくとも１つのソフトウェアサーバによって受信されるようにネットワーク上に同報される
ことを特徴とするネットワーク装置を提供する。
【００１１】
従ってユーザは、サーバが必要ありと決定しない限りは、故障手直し過程に介入する必要はない。有利には、サーバは故障タイプを解析するためおよび正しい処置（アクション）を自動的にとるためのアプリケーションを有している。
【００１２】
殊に、本発明の有利な実施形態によれば、故障がソフトウェアスタートアップ故障であるとき、故障信号を生成するための手段は、ソフトウェアサーバからリプレースメントソフトウェアをメモリ手段に自動的にダウンロードするよう要求するのに適している。
【００１３】
従って、この実施形態の永続メモリは１つのソフトウェアコピーだけを保持していればよくかつソフトウェアまたはデータの２つのコピーを保持している装置と同レベルのロバスト性を有している。
【００１４】
有利には、ソフトウェアダウンロードはいずれの遅延もなく行われる。
【００１５】
本発明はまた、ネットワーク装置がソフトウエアを記憶するための１つの永続メモリと、少なくとも１つのソフトウェアサーバを有しているネットワークに接続するための通信手段とを有しているという、ネットワーク装置のソフトウェアスタートアップを監視するための方法であって、この監視過程は次のステップを有している：
−  ソフトウェアスタートアップ故障を検出するために装置のソフトウェアスタートアップを監視し、
−  スタートアップソフトウェア故障の検出に応答してソフトウェアスタートアップ故障信号を生成し、
−  少なくとも１つのソフトウェアサーバに受信されるようにするためにソフトウェア故障信号をネットワーク上に自動的に同報する
方法を提供する。
【００１６】
本発明の思想は以下の詳細だが、それに制限されているわけではない本発明の実施例の説明およびを各図を参照して考察することによって容易に理解することができる。その際
図１は本発明の実施例のネットワーク装置を含んでいるシステムのブロック線図を示し、
図２は図１のシステムに使用されるのに適しておりかつ本発明の実施例の原理に従っている処理方法のフローチャートを略示し、
図３は図２に示されている方法をより詳しく説明するフローチャートを略示している。
【００１７】
図１には本発明の実施例のスタンドアローン形装置１が組み込まれているシステムのブロック線図が示されている。
【００１８】
このネットワーク装置１はデータ転送通信を処理することができるいずれかのデバイスから成っている。それは例えばＤＳＬタイプのモデムまたは別のスタンドアローン形のネットワーク装置であってよい。装置はローカルエリアネットワーク２に接続されており、ネットワークにはサーバ３および／または故障処理アプリケーション（図示なし）を備えてるデバイスに接続されている。
【００１９】
ネットワーク装置１は電気的に消去可能なプログラマブルリードオンリーメモリ（Electrically Erasable Programmable Read Only Memory＝ＥＥＰＲＯＭ）のような永続的オンボードメモリ手段４を備えている。この永続メモリは複数のアイテムを保持している。この実施例によれば、それはその他のデータとともに、装置のスタートアップおよび機能のために必要なソフトウェアプログラム、例えば装置コンフィギュレーションパラメータ５、立ち上げ、すなわちブートソフトウエア６およびファームウェア７を記憶している。
【００２０】
装置コンフィギュレーション５はとりわけ、モデムのシリアルナンバーおよびネットワークアドレスを含んでいるパラメータのセットである。
【００２１】
ファームウェア７はアプリケーションレベルソフトウェアによって消去可能ではないメモリに書き込まれている、すなわち所定のプロテクションを有しているいずれかのソフトウェアから成っている。この実施例において、ファームウェアは例えばモデムのオペレーティングシステムを有している。以下に示すように、ファームウェアはダウンロードによって大域的に置換されることもできるが、ファームウェアは独特なアイテムを有していてもよく、かつ本発明は大容量ダウンロードに制限されておらず、その範囲は個別のアイテムのテストおよびダウンロードも含んでいる。
【００２２】
実際には、スタンドアローン形装置１は、分かり易くするために示されていないが、種々のプログラムを実行するマイクロプロセッサのようなデータ処理ユニットおよび非永続メモリも有している。実行の前に、永続メモリに記憶されているソフトウェアは非永続メモリ（例えばＲＡＭ）にコピーされる。
【００２３】
スタンドアローン形装置はオンボードメモリ手段４と、ネットワーク２に接続されているネットワーク通信手段９との間にデータ転送モジュール８も有している。
【００２４】
この転送モジュール８は例えば標準化されたブートストラップ・プロトコル（ＢＯＯＴＰ）、およびローカルエリアネットワーク２を介してサーバ３と装置１との間で情報交換するためのファイルトランスファプロトコル（ＴＦＴＰ）を使用することができる。装置はこの実施例によればＤＳＬモデムであるので、相応のＰＳＴＮインタフェースおよびそのＤＳＬ機能を実行するための関連回路も有している。これらのアイテムはそれ自体よく知られているので、図１には示されていない。
【００２５】
モジュール８および１０は具体化実現された、つまりインプリメンテド・ハードウェアかまたは非永続メモリからマイクロプロセッサによって実行されるソフトウェアモジュールであってよい。
【００２６】
本発明によれば、スタンドアローン形装置１は装置のソフトウェアのスタートアップを制御することができる監視手段も有している。
【００２７】
これら監視手段１０は、とりわけ、ファームウェア７の妥当性、存在および正しいスタートアップおよびコンフィギュレーションデータ５の妥当性をチェックする。永続メモリにおけるブートソフトウエアコピーのチェックも可能であるが、詳しい説明はしないものとする。
【００２８】
殊にスタートアッププロセスの期間に何らかの問題がある場合、これら監視手段１０はファームウェアスタートアップ故障信号を生成する。これは転送モジュール８および通信手段９によってデータ伝送ネットワーク２を介してソフトウェアサーバ３に伝送される。
【００２９】
ソフトウェアサーバ３に知らされるこの故障信号はサーバによってリプレースメントファームウェアのダウンロードのＢＯＯＴＰ要求に関連付けられる。この故障信号を送出するために使用されるＢＯＯＴＰプロトコルのフレーム部分はダウンロードされるべきソフトウェアの種類かまたは適当な故障信号を特定する。このフレーム部分は例えば、ＢＯＯＴＰプロトコルの「ベンダ専有オプショナルフィールド」であってよい。
【００３０】
ソフトウェアサーバ３で示されている、データ転送ネットワーク２におけるアプリケーションは、プログラムコードおよびリプレースメントソフトウェアおよび／またはコンフィギュレーションデータが記憶されているデータベースを維持しているものとする。
【００３１】
このＢＯＯＴＰ要求に応答して、このサーバ３はリプレースメントソフトウェアをネットワーク装置に、転送モジュール８および通信手段９のＴＦＴＰプロトコルを使用してネットワーク２を介して転送する。
【００３２】
実際には、ＢＯＯＴＰメッセージは、過程については以下に詳細に説明するが、装置の複数の故障状態を有している。ローカルエリアネットワーク上のその他のデバイスはこれらの状態を解釈しかつ正しい処置を決定しようとする。処置は典型的にはリプレースメントソフトウェアのダウンロードを含んでいるが、ユーザに対する故障情報の通報を含んでいてもよい。
【００３３】
有利には、監視手段１０はボタン１１に関連付けられるようにすることができる。ボタンはユーザによって手動で操作されて、ネットワークを介するファームウェアおよび／またはブートソフトウエアのダウンロードの要求がトリガされるようにすることができる。
【００３４】
有利には、ユーザにスタートアップ故障を通報するために監視手段１０に視認または音響警報１２が接続されている。
【００３５】
図２には、この実施例による、スタンドアローン形装置１のスタートアッププロセスお簡素化されたバージョンが示されている。図示のステップは主に、妥当性のテストに関しかつ例えばメモリ４におけるファームウェア７のようなソフトウェアを表している。
【００３６】
スタンドアローン形装置１のパワーオン時に（ステップ２０）、監視手段１０は装置１のスタートアップのために必要なファームウェアに関するファームウェアテストステップ２１を開始する。このテストステップの期間に問題が検出されなければ、監視手段１０はステップ２２において、ファームウェアがオンボードメモリ手段４に記憶されているかどうかをチェックする。
【００３７】
ファームウェアが見つからなければ、監視手段１０はスタートアップ故障信号Ｆを生成し、かつ装置１を再度立ち上げする。
【００３８】
ステップ２３において、テストステップ２１が成功裡に実行されないならば、監視手段１０は、伝送モジュール８および通信手段９のＢＯＯＴＰプロトコルを使用して、伝送ネットワークネット２を介してソフトウェアサーバ３からリプレースメントファームウェアのダウンロードを要求する。
【００３９】
ステップ２４において、ソフトウェアサーバ３は、転送モジュール８および通信手段９のＴＦＴＰプロトコルを使用して、転送ネットワークネット２を介してリプレースメントファームウェアをダウンロードする。
【００４０】
ステップ２５において、監視手段１０はダウンロードが正しく行われるように制御する。例えばダウンロードが中断されたとき、監視手段１０は固有のファームウェア故障信号Ｆ（故障のタイプの識別を含んでいる）を生成し、かつ装置１を再立ち上げするので、新しいダウンロードが開始されるようになる。
【００４１】
テストが正しく実行されるならば、監視手段１０はステップ２６において、ファームウェアをロードしかつスタートアップ故障フラグおよびタイマーをセットしてスタートアップタイムリミットが決定されるようにする。このフラグは、ファームウェアがスタートアップを正しく実行した場合にファームウェアによってリセットされる。スタートアップタイムリミットが過ぎたのにソフトウェアスタートアップが完了していない場合、フラグは依然セットされたままで、かつ監視手段１０はソフトウェアスタートアップ故障信号Ｆ（これも故障のタイプの識別を含んでいるが、上に述べた第１の故障タイプとは別のものである）を生成し、かつ装置１を再立ち上げする。その他の場合、ステップ２７において、ソフトウェアスタートアップが正しく実行されたとき、それはソフトウェアスタートアップフラグをリセットしかつ故障信号は生成されない。
【００４２】
有利にも、この実施例によれば、ネットワークネット装置１はファームウェアスタートアップ故障またはファームウェア不在の場合にリプレースメントファームウェアの自動的なリクエストおよび自動的なダウンロードを行う。従って、例えばスタートアップ故障は自動的に修復されかつユーザは故障の存在に気付きもしない。
【００４３】
殊に、図３のブロック線図には本発明の実施例によるスタンドアローン形装置のスタートアップ過程の詳細が示されている。
【００４４】
過程は、ネットワーク装置に対するパワーオン状態が起動されたときステップ３０においてに始まる。それから図３の過程は、よく知られているＢＯＯＴＰおよびＴＦＴＰプロトコルを使用して、監視手段１０によって実行される。
【００４５】
ステップ３１において、初期テストが実行される。典型的には、監視手段１０は永続メモリ４のアベイラビリティおよび非永続メモリの適正な動作をチェックする。
【００４６】
ステップ３２において、有利にはおよびこの実施例によれば、装置コンフィギュレーション故障があるかどうかまたはエンドユーザが操作ボタン１１を押圧してソフトウェアダウンロードを要求しているかどうかの検出が行われる。
【００４７】
これらの状況の１つが生じると、監視手段１０はステップ３３にジャンプし、オンボードメモリ手段４に記憶されているコンフィギュレーションデータの妥当性を制御する。
【００４８】
装置コンフィギュレーション５はしばしば、サインまたはチェックサムによってセキュリティが施されている。このサインまたはチェックサムは装置１のオンボードメモリ手段４に登録されている。装置コンフィギュレーションの妥当性を制御するための従来の簡単な手法は、そのチェックサムを再計算しかつそれを登録されているものと比較することである。整合しなければ、装置コンフィギュレーション５はもはや妥当ではない。この場合、監視手段１０は相応の故障フラグ３４をセットアップする。
【００４９】
有利には、このフラグ３４は生じている故障のタイプについての情報を伝えるように符号化されている。この場合、故障フラグ３４は装置コンフィギュレーション故障の存在を指示する情報状態を有している。
【００５０】
コンフィギュレーションデータのタイプに依存して、コンフィギュレーションデータ故障はダウンロードにより手直し可能のこともあるし手直し可能でないこともある。後者の場合、装置によって発生されるＢＯＯＴＰメッセージは、当該装置がもはや使用され得ずかつデッドとして考察されるべきであることを指示するものとして、他のネットワークによって解釈される。
【００５１】
コンフィギュレーションがステップ３３において妥当であるならば、このことはエンドユーザがボタン１１を押圧してファームウェアのダウンロードをトリガしたことを意味している。従って、監視手段１０はソフトウェアスタートアップ故障フラグ３５をセットもする。この故障フラグ３５はユーザがファームウェアのダウンロードを要求したことを特定する。
【００５２】
ダウンロードが要求されずかつ装置コンフィギュレーション問題が生じない場合、監視手段１０はステップ３２の後、ステップ３６の期間に、オンボードメモリ手段４に登録されているファームウェアプログラム７の妥当性をチェックする。
【００５３】
それを行う最も簡単な手法は、その検証パターン（フラッシュ検証パターンの場合はＦＶＰ＝Flash Verification Pattern）の存在および妥当性を制御することである。検証パターンはソフトウェアまたはデータの完全性をチェックするための従来よりのツールである。ファームウェアが永続メモリ４に首尾よく記録されているとき、検証パターンが計算されかつメモリ４に書き込まれもする。装置阿ファームウェアの記憶期間にパワー故障または別の問題を蒙っているならば、このファームウェアに相応する検証パターンは記憶されていないかまたは誤っている。
【００５４】
それ故に、ステップ３６において、監視手段１０はファームウェア検証パターンを用いてファームウェアの妥当性をチェックする。パターンが妥当でなければ、故障フラグ３７がセットされる。別のテストステップの場合のように、この特別な故障フラグは故障の性質つまりその内容を指示している。
【００５５】
ステップ３８において、監視手段１０は故障フラグ３４、３５、３７のセッティング状態をチェックする。少なくとも１つのフラグがセットされているならば、監視手段１０は自動的に、転送モジュール８および通信手段９のＢＯＯＴＰプロトコルを使用して転送ネットワーク２を介して故障信号をサーバ３に送信する。このメッセージは故障フラグ状態を含んでいる。
【００５６】
ソフトウェアサーバ３のアプリケーションのような、ネットワークデバイスにまとめられているアプリケーションはこれらの信号に注意しかつ故障状態情報を解釈する。この情報の解釈の後、これらのアプリケーションは、有利にはいずれのエンドユーザの介入もなしに、ネットワーク装置１に対するファームウェアダウンロードの少なくとも１つのスタートを有しているおよび／またはユーザへ問題を通報する処置を行う決定をする。通報は、例えば重大なコンフィギュレーション故障の発生の場合、故障の是正が可能ではなくなった後にユーザに通報される。この目的のために試行のカウンタがインプリメントされかつ例えばファームウェアダウンロードを要求するそれぞれのＢＯＯＴＰメッセージの後に漸次的にインクリメントされるようにするとよい。
【００５７】
殊に、伝送モジュール８は問題状態を監視手段１０によってネットワークに送信された適当なＢＯＯＴＰプロトコルメッセージの「ベンダオプショナル専用フィールド」において指示する。このフィールドはアプリケーション確定制限または付加的なクライアント情報を通信するために標準的に使用されるものである。
【００５８】
換言すれば、メッセージは有利には予め定めたサーバに限ってではなく、ネットワーク上に同報される。ネットワーク上のデバイスのいずれか１つは、それがそのメッセージに注意し、解析しかつ応答するための正当なアプリケーションを有しているならば、サーバとして動作するようであってもよい。
【００５９】
そのダウンロードの後、リプレースメントファームウェアは永続性のオンボードメモリ手段４に記憶される。このステップは参照番号３９を有している。
【００６０】
ステップ４０において、監視手段１０はリプレースメントソフトウェアがいずれの中断もなくダウンロードされかつそれが正しく記録されるように制御する。
【００６１】
ダウンロードされるソフトウェアがファームウェアであるとき、データ処理ユニットはリプレースメントファームウェアをチェックしかつそのフラッシュな検証パターン（flash verification pattern）を計算しかつそれをステップ４１でメモリ４に記録する。
【００６２】
リプレースメントソフトウェアがダメージを受けているまたは正しくダウンロードされないまたは正しく記録されなかったならば、監視手段１０は相応の故障フラグ４２をセットする。それから、スタンドアローン形装置１は再度立ち上げられる。勿論、フラグは再立ち上げ過程によって影響されないような仕方で記憶される。ステップ３１において、デバイスはフラグ４２がセットされているかどうかをテストしかつ相応のＢＯＯＴＰメッセージを送信してファームウェアがダウンロードされるようにする。
【００６３】
ステップ４３において、ステップ３８において故障フラグが検出されなかった場合、監視手段１０はオンボードメモリ手段４におけるファームウェアの存在を制御する。この存在をチェックするために使用可能な種々の方法がある。例えば、ファームウェアの存在はファームウェアコードの固定のロケーションにおける特定の識別コードの検出によりチェックすることができる。本発明によればその他の方法も使用することができる。
【００６４】
ソフトウェアが登録されていなければ、監視手段１０は故障フラグ４４をセットしかつモデムはステップ３０において再度立ち上げられて、上述のセットされたフラグに基づいて故障が処理されるようにする。
【００６５】
ステップ４１またはステップ４３が何の問題もなく実行されたならば、監視手段１０はスタートアップフラグをセットしかつ、ステップ４６においてファームウェアをロードしかつスタートする前に、スタートタイマーをトリガする。
【００６６】
成功したスタートアップの後、ファームウェアによってスタートアップフラグがリセットされ、それが正しくスタートしたことを確認する。しかしスタート時間が経過終了する前にスタートアップが実行されなかったならば、監視手段１０は問題フラグ４８をセットしかつステップ３０において装置を再度立ち上げて相応の故障が処理されるようにする。
【００６７】
要約すると、図３の過程は５つの問題状態を定義している：
−  ソフトウェア（ファームウェア）スタートアップエラー：ファームウェアはスタートアップか再立ち上げの期間に正しくスタートアップすることなくて停止する；
−  不当なコンフィギュレーション；
−  失敗したソフトウェア（ファームウェア）ダウンロード（例えばダウンロード過程の中断）；
−  ソフトウェアの不在；
−  ダウンロードされたソフトウェアの、永続メモリに対する書き込み失敗（検証パターン不正）。
【００６８】
その他の状態はソフトウェアのダウンロードをトリガすることができる：
−  デバイスの機械的なボタンがユーザにより押圧されてファームウェアのダウンロードが要求される；
−  ファームウェアはネットワークを介してファームウェア更新を実行するようにという要求を受信する。
【００６９】
フラグは立ち上げ過程の開始時、またはその実行期間に監視手段によってチェックされる。ダウンロードは明示的に要求することができるまたはダウンロードに関する決定がデバイスメッセージに注意するアプリケーションに任されるようになっている。
【００７０】
本発明はここまで説明してきた有利な実施例に限定されておらず、いずれの種類のソフトウェアまたはデータをダウンロードすることができる。そしてこの過程はＴＦＴＰおよびＢＯＯＴＰプロトコルとは異なっているプロトコルによって実行することもできる。
【図面の簡単な説明】
【００７１】
【図１】本発明の実施例のネットワーク装置を含んでいるシステムのブロック線図
【図２】図１のシステムに使用されるのに適しておりかつ本発明の実施例の原理に従っている処理方法のフローチャート
【図３】図２に示されている方法をより詳しく説明するフローチャート
【図１】
2009514042.tif 000002
【図２】
2009514042.tif 000003
【図３】
2009514042.tif 000004
【国際調査報告】
2009514042.tif 000005
2009514042.tif 000006
2009514042.tif 000007