(57)【要約】【課題】有効に存在していない通知先を効率的に通知先情報テーブルから削除する。【解決手段】デバイス状態通知装置は、ネットワークに接続されたデバイスの状態変化を、前記ネットワークに接続された通知先に、前記ネットワークを介して通知するデバイス状態通知装置であって、前記デバイスの状態変化があった場合に、その状態変化があったことを通知する通知先が登録されている通知先情報テーブルと、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する第１通知先有効性確認手段と、前記第１通知先有効性確認手段により、有効に存在することが確認できなかった通知先を、前記通知先情報テーブルから削除して、サスペンドテーブルに移行する、第１移行手段と、を備えて構成されている。【選択図】図１
2010113400.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続されたデバイスの状態変化を、前記ネットワークに接続された通知先に、前記ネットワークを介して通知するデバイス状態通知装置であって、
前記デバイスの状態変化があった場合に、その状態変化があったことを通知する通知先が登録されている通知先情報テーブルと、
前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する第１通知先有効性確認手段と、
前記第１通知先有効性確認手段により、有効に存在することが確認できなかった通知先を、前記通知先情報テーブルから削除して、サスペンドテーブルに移行する、第１移行手段と、
を備えることを特徴とするデバイス状態通知装置。
【請求項２】
前記第１通知先有効性確認手段は、前記通知先情報テーブルに登録されている通知先に、何らかの応答を要求する応答要求を発行し、この応答要求に対する応答が得られない場合には、その通知先が有効に存在していないと判断する、ことを特徴とする請求項１に記載のデバイス状態通知装置。
【請求項３】
前記第１通知先有効性確認手段は、前記応答要求を発行しても通知先から応答が得られない場合、その通知先への前記応答要求を規定回数まで発行し、規定回数を超えて前記応答要求を発行しても応答が得られない通知先については有効に存在していないと判断する、ことを特徴とする請求項２に記載のデバイス状態通知装置。
【請求項４】
前記第１移行手段は、有効に存在することを確認できなかった通知先が複数ある場合には、有効に存在することを確認できた日時の最も古い通知先を、前記サスペンドテーブルに移行する、ことを特徴とする請求項１乃至請求項３のいずれかに記載のデバイス状態通知装置。
【請求項５】
前記第１移行手段は、前記通知先情報テーブルにあるすべての通知先が有効に存在すると確認された場合には、前記通知先情報テーブルに登録された日時が最も古い通知先を、前記サスペンドテーブルに移行する、ことを特徴とする請求項１乃至請求項４のいずれかに記載のデバイス状態通知装置。
【請求項６】
通知先を新規に登録する要求を受け付けたが、前記通知先情報テーブルに空きが無く、そのままでは、新規の通知先の登録ができない場合に、前記第１通知先有効性確認手段は、前記通知先情報テーブルに登録さている通知先が有効に存在するか否かを確認し、前記第１移行手段は、有効に存在することが確認できなかった通知先の移行を行う、ことを特徴とする請求項１乃至請求項５のいずれかに記載のデバイス状態通知装置。
【請求項７】
前記通知先情報テーブルに空きができた場合に、前記サスペンドテーブルに登録されている通知先が有効に存在するか否かを確認する、第２通知先有効性確認手段と、
前記第２通知先有効性確認手段により、有効に存在することが確認できた通知先を、前記サスペンドテーブルから削除して、前記通知先情報テーブルに移行する、第２移行手段と、
をさらに備えることを特徴とする請求項１乃至請求項６のいずれかに記載のデバイス状態通知装置。
【請求項８】
前記第２通知先有効性確認手段で、有効に存在すると確認できなかった通知先を、前記サスペンドテーブルから削除する、削除手段を、さらに備えることを特徴とする請求項７に記載のデバイス状態通知装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイス状態通知装置に関し、特に、デバイスの状態が変化した際に、その変化を通知する機能を有するデバイス状態通知装置に関する。
【背景技術】
【０００２】
ネットワークを介して、プリンタと、複数のホストコンピュータとを相互に接続し、１台のプリンタを複数のホストコンピュータで共有する利用態様が普及している。このような利用態様の場合、各ホストコンピュータは、プリンタの状態変化を監視し、印刷ジョブの開始や終了、プリンタの障害などを監視する必要がある。このような状態変化の監視がホストコンピュータから出来るようにするため、プリンタ側にデバイス状態通知装置が設けられている。
【０００３】
例えば、プリンタとホストコンピュータとの間を接続するネットワークの規格がＴＣＰ／ＩＰである場合、ＳＮＭＰ（Simple Network Management Protocol）を用いることにより、プリンタの監視を実現する。すなわち、ホストコンピュータ側に、ＳＮＭＰに準拠した管理アプリケーションを搭載し、プリンタ側に、同じくＳＮＭＰに準拠したネットワークインターフェースを搭載し、ＳＮＭＰ  Ｔｒａｐという監視手段を用いて、ホストコンピュータはプリンタの状態監視を行う。
【０００４】
プリンタ側で予め指定された状態変化が発生したときに、どのホストコンピュータに通知をするのかは、プリンタ側に設けられた通知先情報テーブルに事前に登録されている。しかし、一般的に、通知先情報テーブルに登録できる通知先アドレスの数には制限がある。このため、新たにプリンタの監視を開始しようとしたホストコンピュータが、プリンタの通知先情報テーブルに、自らの通知先アドレスを登録しようとしても、既に通知先情報テーブルに空きがない場合には、その登録ができなくなってしまう。通知先情報テーブルに通知先アドレスの登録ができないと、ホストコンピュータは、そのプリンタの状態監視ができないこととなる。
【０００５】
その一方で、以前に通知先情報テーブルに登録されていた通知先であっても、既に動作を停止していたり、ネットワーク接続を切断していたりして、使用されていない通知先が存在することもある。このような有効に存在していない通知先が通知先情報テーブルに登録されている場合、新しい通知先の登録ができないばかりか、プリンタは、通知先情報テーブルの登録に従って、状態変化の通知を送信し続けることとなり、ネットワーク上を無用なパケットが流れ、ネットワーク負荷の増大を招くこととなる。
【０００６】
このため、例えば、特開２００３−９９３４２号公報（特許文献１）には、ホストコンピュータの管理アプリケーションからの削除要求に基づいて、通知先情報テーブルから通知先を削除する手法を開示している。しかし、この手法は、管理アプリケーションからの削除要求に基づいて通知先を削除するため、ホストコンピュータ側にその管理が委ねられてしまう。このため、何らかの理由で、ホストコンピュータが、この削除要求を出すことなく、ネットワークから外れてしまったような場合には、その通知先は通知先情報テーブルに残ってしまう。
【０００７】
このような問題は、プリンタだけに限られたものではなく、プリンタ以外のデバイスにであっても、その状態変化を通知先に通知するデバイス状態通知装置を有するデバイスであれば、同様に生じ得る。
【特許文献１】特開２００３−９９３４２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
そこで本発明は、前記課題に鑑みてなされたものであり、有効に存在していない通知先を効率的に通知先情報テーブルから削除することを可能にしたデバイス状態通知装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するため、本発明に係るデバイス状態通知装置は、
ネットワークに接続されたデバイスの状態変化を、前記ネットワークに接続された通知先に、前記ネットワークを介して通知するデバイス状態通知装置であって、
前記デバイスの状態変化があった場合に、その状態変化があったことを通知する通知先が登録されている通知先情報テーブルと、
前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する第１通知先有効性確認手段と、
前記第１通知先有効性確認手段により、有効に存在することが確認できなかった通知先を、前記通知先情報テーブルから削除して、サスペンドテーブルに移行する、第１移行手段と、
を備えることを特徴とする。
【００１０】
この場合、前記第１通知先有効性確認手段は、前記通知先情報テーブルに登録されている通知先に、何らかの応答を要求する応答要求を発行し、この応答要求に対する応答が得られない場合には、その通知先が有効に存在していないと判断するようにしてもよい。
【００１１】
この場合、前記第１通知先有効性確認手段は、前記応答要求を発行しても通知先から応答が得られない場合、その通知先への前記応答要求を規定回数まで発行し、規定回数を超えて前記応答要求を発行しても応答が得られない通知先については有効に存在していないと判断するようにしてもよい。
【００１２】
また、前記第１移行手段は、有効に存在することを確認できなかった通知先が複数ある場合には、有効に存在することを確認できた日時の最も古い通知先を、前記サスペンドテーブルに移行するようにしてもよい。
【００１３】
また、前記第１移行手段は、前記通知先情報テーブルにあるすべての通知先が有効に存在すると確認された場合には、前記通知先情報テーブルに登録された日時が最も古い通知先を、前記サスペンドテーブルに移行するようにしてもよい。
【００１４】
また、通知先を新規に登録する要求を受け付けたが、前記通知先情報テーブルに空きが無く、そのままでは、新規の通知先の登録ができない場合に、前記第１通知先有効性確認手段は、前記通知先情報テーブルに登録さている通知先が有効に存在するか否かを確認し、前記第１移行手段は、有効に存在することが確認できなかった通知先の移行を行うようにしてもよい。
【００１５】
また、前記通知先情報テーブルに空きができた場合に、前記サスペンドテーブルに登録されている通知先が有効に存在するか否かを確認する、第２通知先有効性確認手段と、
前記第２通知先有効性確認手段により、有効に存在することが確認できた通知先を、前記サスペンドテーブルから削除して、前記通知先情報テーブルに移行する、第２移行手段と、
をさらに備えるようにしてもよい。
【００１６】
この場合、前記第２通知先有効性確認手段で、有効に存在すると確認できなかった通知先を、前記サスペンドテーブルから削除する、削除手段を、さらに備えるようにしてもよい。
【発明を実施するための形態】
【００１７】
以下、図面を参照して、本発明の実施形態を説明する。なお、以下に説明する実施形態は、本発明の技術的範囲を限定するものではない。
【００１８】
図１は、本実施形態に係るデバイスネットワークシステム１０の全体構成を示すブロック図である。この図１に示すように、本実施形態に係るデバイスネットワークシステム１０は、ネットワーク１２に接続された、１又は複数のホストコンピュータ１４と、１又は複数のプリンタ１６とを備えて、構成されている。この図１の例では、４台のホストコンピュータ１４Ａ〜１４Ｄが、ネットワーク１２に接続されており、１台のプリンタ１６が、ネットワーク１２に接続されている。
【００１９】
本実施形態においては、ネットワーク１２は、例えば、ＴＣＰ／ＩＰの規格に準拠しており、このネットワーク１２に、同じくＴＣＰ／ＩＰの規格に準拠したホストコンピュータ１４とプリンタ１６とが接続されている。ホストコンピュータ１４は、プリンタ１６の状態をＳＮＭＰ  Ｔｒａｐを用いて監視する。この監視を行うために、ホストコンピュータ１４では、管理アプリケーションが起動されている。
【００２０】
この管理アプリケーションは、例えば、このプリンタ１６に送信した印刷データの印刷開始、その印刷の終了、紙無しエラーの発生、トナー無しエラーの発生などを、ＳＮＭＰ  Ｔｒａｐを用いて監視する。プリンタ１６では、予め指定されたこれらの状態が発生すると、ＳＮＭＰ  Ｔｒａｐを用いて、指定されたホストコンピュータ１４の管理アプリケーションに通知する。すなわち、プリンタ１６は、これらの状態変化が発生した通知を、通知先アドレス宛に送信する。プリンタ１６は、このような状態の監視がなされるデバイスの一例である。
【００２１】
図２は、本実施形態に係るプリンタ１６の内部構成の一例を示すブロック図である。この図２に示すように、本実施形態に係るプリンタ１６は、ＣＰＵ（Central Processing Unit）２０と、ＲＡＭ（Random Access Memory）２２と、ＲＯＭ（Read Only Memory）２４と、ハードディスクドライブ２６と、印刷機構部２８と、通信インターフェース３０とを備えて構成されている。これらＣＰＵ２０と、ＲＡＭ２２と、ＲＯＭ２４と、ハードディスクドライブ２６と、印刷機構部２８と、通信インターフェース３０とは、内部バス３２を介して相互に接続されている。
【００２２】
ＣＰＵ２０は、このプリンタ１６の全体的な制御を行う制御部を構成する。具体的には、ＣＰＵ２０は、プリンタ１６がネットワーク１２を介してホストコンピュータ１４から印刷データを受信し、印刷機構部２８で印刷を行う際に必要となる各種の制御を行う。また、ＣＰＵ２０は、この各種の制御を実現するにあたり、必要なプログラムをＲＯＭ２４やハードディスクドライブ２６から読み込んだり、生成されたデータをＲＡＭ２２に書き込んだりする。
【００２３】
ハードディスクドライブ２６は、いわゆる大容量の補助記憶装置を構成しており、プログラムの他、印刷データや各種制御データなども不揮発的に記憶される。印刷機構部２８は、印刷を実際に行うプリンタエンジンにより構成されており、例えば、本実施形態ではレーザービーム式の印刷機構により構成されている。
【００２４】
通信インターフェース３０は、プリンタ１６をネットワーク１２に接続するためのインターフェースである。本実施形態においては、この通信インターフェース３０は、ＴＣＰ／ＩＰのプロトコルに準拠しており、ＳＮＭＰ  Ｔｒａｐを用いて、ホストコンピュータ１４がこのプリンタ１６を監視することができるように構成されている。
【００２５】
本実施形態においては、このプリンタ１６にデバイス状態通知装置が組み込まれている。特に本実施形態においては、プリンタ１６が、後述する通知先登録処理や、サスペンドテーブル更新処理、ＳＮＭＰ  Ｔｒａｐ発行処理を行うことにより、本実施形態に係るデバイス状態通知装置がプリンタ１６で実現される。
【００２６】
次に、図３及び図４に基づいて、本実施形態に係るプリンタ１６で実行される通知先登録処理について説明する。この図３及び図４の通知先登録処理は、プリンタ１６がホストコンピュータ１４から通知先の新規登録要求を受けた場合に、起動される処理である。すなわち、プリンタ１６が新たな通知先を登録しようとする際に、起動される処理である。
【００２７】
また、この通知先登録処理は、プリンタ１６のＣＰＵ２０が、ＲＯＭ２４又はハードディスクドライブ２６に格納されている通知先登録処理プログラムを読み込んで実行することにより、実現される処理である。
【００２８】
この通知先登録処理が起動されると、まず、図３に示すように、プリンタ１６は、通知先情報テーブルに、新たな通知先を登録するための空きがあるかどうかを判断する（ステップＳ１０）。図５は、本実施形態に係る通知先情報テーブルＴＢ１０の構成の一例を示す図である。この通知先情報テーブルＴＢ１０は、例えば、プリンタ１６のハードディスクドライブ２６に格納されて、保持されている。
【００２９】
この図５に示すように、本実施形態に係る通知先情報テーブルＴＢ１０は、所定の状態変化がプリンタ１６Ａに発生した場合に、その状態変化が発生した旨を通知する通知先に関する種々の情報が格納されている。具体的には、通知先情報テーブルＴＢ１０は、通知先アドレスと、登録日時と、最終有効確認日時と、無効情報とを、保持している。
【００３０】
通知先アドレスは、所定の状態変化が発生した旨を通知すべき通知先を特定する情報である、ホストコンピュータ１４のアドレスが格納されている。登録日時には、通知先を通知先情報テーブルＴＢ１０に登録した日付と時刻を特定する情報が格納されている。最終有効確認日時には、このプリンタ１６が、その通知先が有効に存在することを最後に確認した日時が格納されている。無効情報には、この通知先登録処理で、その通知先が有効に存在していなかったことが確認できた旨の情報が格納される。例えば、本実施形態では、この無効情報が「０」の場合には、その通知先が有効に存在していたことを示しており、この無効情報が「１」の場合には、その通知先が有効に存在していなかったことを示している。
【００３１】
なお、この図５から分かるように、本実施形態においては、通知先情報テーブルＴＢ１０には、最大４個の通知先を登録することができるように構成されている。換言すれば、本実施形態においては、通知先情報テーブルＴＢ１０には、５個以上の通知先は登録できないことを前提としている。
【００３２】
図３に示すように、通知先情報テーブルＴＢ１０に空きがあると判断した場合（ステップＳ１０：ＹＥＳ）には、プリンタ１６は、登録要求を受けた通知先を、新規に通知先情報テーブルＴＢ１０に登録する（ステップＳ１２）。すなわち、図５の通知先情報テーブルＴＢ１０の空いている領域に、登録要求のあった通知先を登録する。この登録の際には、プリンタ１６は、通知先アドレスを通知先情報テーブルＴＢ１０の「通知先アドレス」に登録するとともに、この登録を行った日時を通知先情報テーブルＴＢ１０の「登録日時」に格納する。登録を行った日時は、例えば、プリンタ１６が内蔵する時計により特定することができる。
【００３３】
一方、通知先情報テーブルＴＢ１０に空きが無いと判断した場合（ステップＳ１０：ＮＯ）には、プリンタ１６は、通知先情報テーブルＴＢ１０から、通知先アドレスを取得する（ステップＳ１４）。
【００３４】
次に、プリンタ１６は、死活確認を実行する（ステップＳ１６）。すなわち、ステップＳ１４で取得した通知先アドレスのホストコンピュータ１４が、現時点で、ネットワーク１２上に有効に存在しているのか、それとも、有効に存在していないのかを確認する。
【００３５】
この死活確認には、様々な手法が考えられるが、本実施形態では、図６に示すように、Ｐｉｎｇを発行することにより、確認する。すなわち、プリンタ１６は、ステップＳ１４で取得した通知先アドレス宛に、Ｐｉｎｇを発行する。このＰｉｎｇを受信したホストコンピュータ１４の管理アプリケーションは、Ｐｉｎｇ応答を応答パケットとして返信する。したがって、プリンタ１６は、このＰｉｎｇ応答が所定時間内に返信されるか否かにより、通知先アドレスのホストコンピュータ１４がネットワーク１２上に有効に存在するか否かを判断する。
【００３６】
このため、図３に示すように、プリンタ１６は、所定時間内にホストコンピュータ１４からの応答を受信したかどうかを判断する（ステップＳ１８）。具体的には、Ｐｉｎｇを発行した後、タイムアウトになるまでに、ホストコンピュータ１４からＰｉｎｇ応答を受信したかどうかを判断する。
【００３７】
所定時間内に応答を受信できなかった場合（ステップＳ１８：ＮＯ）には、プリンタ１６は、確認回数を１つカウントアップする（ステップＳ２０）。確認回数の初期値はゼロに設定されており、Ｐｉｎｇを１回発行する度に、確認回数は１増えることとなる。
【００３８】
次に、プリンタ１６は、確認回数が規定回数を超えたかどうかを判断する（ステップＳ２２）。例えば、本実施形態においては、規定回数が３回に設定されている。このため、プリンタ１６は、ステップＳ２０でカウントアップした後の確認回数が、３回を越えたかどうかを判断する。
【００３９】
確認回数が３回を越えていないと判断した場合（ステップＳ２２：ＮＯ）には、プリンタ１６は、上述したステップＳ１６に戻り、再度、死活確認を実行する。一方、確認回数が３回を越えた場合（ステップＳ２２：ＹＥＳ）、つまり、確認回数が４回だった場合には、プリンタ１６は、通知先情報テーブルＴＢ１０における対応する通知先に、無効情報を付加する（ステップＳ２４）。具体的には、プリンタ１６は、通知先の通知先情報テーブルＴＢ１０における対応する通知先の「無効情報」の値を１にして、フラグを立てる。
【００４０】
図７は、本実施形態において、プリンタ１６が３回、Ｐｉｎｇを発行しても、ホストコンピュータ１４から応答が得られなかった場合のプリンタ１６とホストコンピュータ１４との間のやり取りを示している。この図７に示すように、最初にＰｉｎｇを発行し、タイムアウトになると２回目のＰｉｎｇを発行し、さらにこれもタイムアウトになると３回目のＰｉｎｇを発行する。しかし、これもタイムアウトになると、プリンタ１６は、その通知先に無効情報を付加するのである。
【００４１】
これに対して、図３に示すように、ステップＳ１８において、ホストコンピュータ１４から応答があった場合（ステップＳ１８：ＹＥＳ）には、プリンタ１６、確認回数をゼロにリセットする（ステップＳ２６）。
【００４２】
次に、プリンタ１６は、その通知先の最終有効確認日時を更新する（ステップＳ２８）。すなわち、プリンタ１６は、存在の有効性が確認できた通知先について、通知先情報テーブルＴＢ１０の「最終有効確認日時」を、その時点の日時に変更する。上述したように、この日時は、プリンタ１６が内蔵する時計により特定することができる。
【００４３】
このステップＳ２８の後、又は、上述したステップＳ２４の後、プリンタ１６は、通知先情報テーブルＴＢ１０に登録されているすべての通知先の死活確認を行ったかどうかを判断する（ステップＳ３０）。例えば、図５の例では、４つの通知先が通知先情報テーブルＴＢ１０に登録されているので、これら４つの通知先について、死活確認を行ったかどうかを判断する。
【００４４】
通知先情報テーブルＴＢ１０に登録されているすべての登録先の死活確認が完了していない場合（ステップＳ３０：ＮＯ）には、上述したステップＳ１４に戻り、通知先情報テーブルＴＢ１０から次の通知先の通知先アドレスを取得し、死活確認を行う。一方、通知先情報テーブルＴＢ１０に登録されているすべての登録先の死活確認が完了した場合（ステップＳ３０：ＹＥＳ）には、プリンタ１６は、図４に示すように、通知先情報テーブルＴＢ１０に無効の通知先が存在するか否かを判断する（ステップＳ４０）。具体的には、通知先情報テーブルＴＢ１０における「無効情報」が「１」になっている通知先が存在するか否かを判断する。
【００４５】
通知先情報テーブルＴＢ１０に無効になっている通知先が存在する場合（ステップＳ４０：ＹＥＳ）には、無効になっている通知先のうち、最も最終有効確認日時の古い通知先を通知先情報テーブルＴＢ１０から削除し、サスペンドテーブルに移行する（ステップＳ４２）。サスペンドテーブルに移行することにより、通知先の通知先情報テーブルＴＢ１０には、移行した通知先の領域に、空きができることとなる。
【００４６】
図５に示した通知先情報テーブルＴＢ１０の例では、「無効情報」が「１」になっている通知先が２つあるが、上から３番目の通知先の「最終有効確認日時」が「２００８年１０月９日８時１０分」であり、上から４番目の通知先の「最終有効確認日時」が「２００８年１０月９日１８時１５分」であることから、３番目の通知先をサスペンドテーブルに移行する。
【００４７】
図８は、本実施形態に係るサスペンドテーブルＴＢ２０の構成の一例を示す図である。このサスペンドテーブルＴＢ２０は、例えば、プリンタ１６のハードディスクドライブ２６に格納されて、保持されている。
【００４８】
この図８に示すように、本実施形態に係るサスペンドテーブルＴＢ２０は、通知先アドレスと、登録日時とを保持している。すなわち、通知先情報テーブルＴＢ１０から移行された通知先の通知先アドレスと、その通知先の通知先情報テーブルＴＢ１０への登録日時とが、格納されている。なお、本実施形態におけるサスペンドテーブルＴＢ２０には、格納できる通知先の数に、実質的な制限は設けられていない。すなわち、サスペンドテーブルＴＢ２０は、格納する必要のある通知先の数に応じて、任意にその領域を拡大及び縮小できるように構成されている。
【００４９】
一方、上述したステップＳ４０において、通知先情報テーブルＴＢ１０に無効になっている通知先が存在しないと判断した場合（ステップＳ４０：ＮＯ）には、プリンタ１６は、登録日時の最も古い通知先を、通知先情報テーブルＴＢ１０から削除して、サスペンドテーブルＴＢ２０に移行する（ステップＳ４４）。サスペンドテーブルＴＢ２０に移行することにより、通知先の通知先情報テーブルＴＢ１０には、移行した通知先の領域に、空きができることとなる。
【００５０】
このステップＳ４４の後、又は、上述したステップＳ４２の後、プリンタ１６は、新しい通知先を、通知先の通知先情報テーブルＴＢ１０に登録する（ステップＳ４６）。具体的には、ステップＳ４２又はステップＳ４４で形成された通知先情報テーブルＴＢ１０の空き領域に、登録要求のあった通知先を登録する。この登録の際には、上述したステップＳ１２と同様に、プリンタ１６は、通知先アドレスを通知先情報テーブルＴＢ１０の「通知先アドレス」に登録するとともに、この登録を行った日時を通知先情報テーブルＴＢ１０の「登録日時」に格納する。上述したように、登録を行った日時は、例えば、プリンタ１６が内蔵する時計により特定することができる。
【００５１】
次に、プリンタ１６は、通知先情報テーブルＴＢ１０の「無効情報」をクリアする（ステップＳ４８）。すなわち、通知先情報テーブルＴＢ１０の「無効情報」をすべて「０」に設定して、フラグを降ろす。これにより、本実施形態に係る通知先登録処理が終了する。
【００５２】
次に、図９に基づいて、本実施形態に係るサスペンドテーブル更新処理について説明する。この図９のサスペンドテーブル更新処理は、このプリンタ１６により定期的に起動され、実行される処理である。すなわち、このサスペンドテーブル更新処理は、例えば、１時間に１回、または３時間に１回という所定の時間間隔で、プリンタ１６自身により起動される処理である。
【００５３】
また、このサスペンドテーブル更新処理は、プリンタ１６のＣＰＵ２０が、ＲＯＭ２４又はハードディスクドライブ２６に格納されているサスペンドテーブル更新処理プログラムを読み込んで実行することにより、実現される処理である。
【００５４】
このサスペンドテーブル更新処理が起動されると、まず、プリンタ１６は、通知先情報テーブルＴＢ１０に空きがあるかどうかを判断する（ステップＳ６０）。本実施形態においては、例えば、ホストコンピュータ１４の管理アプリケーションが、ホストコンピュータ１４の電源がオフにされる際に、その前処理で、通知先情報テーブルＴＢ１０から自らの登録を削除するようにプリンタ１６に要求した後に、電源をオフするように構成されている。このため、一旦、満杯になった通知先情報テーブルＴＢ１０であっても、時間の経過とともに、空き領域が形成されることがあるのである。
【００５５】
通知先情報テーブルＴＢ１０に空きが無い場合（ステップＳ６０：ＮＯ）には、プリンタ１６は、このサスペンドテーブル更新処理を終了する。
【００５６】
一方、通知先情報テーブルＴＢ１０に空きがある場合（ステップＳ６０：ＹＥＳ）には、プリンタ１６は、サスペンドテーブルＴＢ２０から通知先アドレスを１つ取得する（ステップＳ６２）。例えば、本実施形態においては、プリンタ１６は、サスペンドテーブルＴＢ２０に登録されている通知先を上から順番に取得する。
【００５７】
次に、プリンタ１６は、死活確認を実行する（ステップＳ６４）。すなわち、ステップＳ６２で取得した通知先アドレスのホストコンピュータ１４が、現時点で、ネットワーク１２上に有効に存在しているのか、それとも、有効に存在していないのかを確認する。この死活確認は、例えば、上述した通知先登録処理と同様に、Ｐｉｎｇを発行して、ホストコンピュータ１４から応答があるかどうかで判断することができる。
【００５８】
次に、プリンタ１６は、所定時間内にホストコンピュータ１４からの応答を受信したかどうかを判断する（ステップＳ６６）。具体的には、Ｐｉｎｇを発行した後、タイムアウトになるまでに、ホストコンピュータ１４からＰｉｎｇ応答を受信したかどうかを判断する。
【００５９】
所定時間内にホストコンピュータ１４から応答を受信した場合（ステップＳ６６：ＹＥＳ）には、その通知先を、通知先情報テーブルＴＢ１０に復活させる（ステップＳ６８）。すなわち、以前の死活確認では有効に存在することを確認できなかったホストコンピュータ１４が、このときは、有効に存在することが改めて確認できたので、このホストコンピュータ１４を通知先として、サスペンドテーブルＴＢ２０から通知先の通知先情報テーブルＴＢ１０に移行する。
【００６０】
この移行にあたっては、プリンタ１６は、サスペンドテーブルＴＢ２０の「通知先アドレス」に格納されている通知先の通知先アドレスを、通知先情報テーブルＴＢ１０の「通知先アドレス」に移行し、サスペンドテーブルＴＢ２０の「登録日時」に格納されている登録日時を、通知先情報テーブルＴＢ１０の「登録日時」に移行する。これにより、移行された通知先は、サスペンドテーブルＴＢ２０から削除される。
【００６１】
このステップＳ６８の通知先の復活が完了した後、プリンタ１６は、再びステップＳ６０に戻り、通知先情報テーブルＴＢ１０にまだ空き領域があるかどうかを判断し、空き領域があれば、ステップＳ６２からを繰り返す。
【００６２】
一方、上述したステップＳ６６で、所定時間内に応答を受信できなかったと判断した場合（ステップＳ６６：ＮＯ）には、プリンタ１６は、確認回数を１つカウントアップする（ステップＳ７０）。確認回数の初期値はゼロに設定されており、Ｐｉｎｇを１回発行する度に、確認回数は１増えることとなる。
【００６３】
次に、プリンタ１６は、確認回数が規定回数を超えたかどうかを判断する（ステップＳ７２）。例えば、本実施形態においては、規定回数が３回に設定されている。このため、プリンタ１６は、ステップＳ７０でカウントアップした後の確認回数が、３回を越えたかどうかを判断する。
【００６４】
確認回数が３回を越えていないと判断した場合（ステップＳ７２：ＮＯ）には、プリンタ１６は、上述したステップＳ６４に戻り、再度、死活確認を実行する。一方、確認回数が３回を越えた場合（ステップＳ７２：ＹＥＳ）、つまり、確認回数が４回だった場合には、プリンタ１６は、サスペンドテーブルＴＢ２０から、その通知先を削除する（ステップＳ７４）。すなわち、以前の通知先登録処理においても有効に存在することを確認できず、また、今回のサスペンドテーブル更新処理においても有効に存在することを確認できなかったホストコンピュータ１４については、もはやネットワーク１２上には有効に存在していないであろうとみなして、サスペンドテーブルＴＢ２０から削除する。
【００６５】
次に、プリンタ１６は、サスペンドテーブルＴＢ２０に登録されているすべての通知先の死活確認を行ったかどうかを判断する（ステップＳ７６）。サスペンドテーブルＴＢ２０に登録されているすべての登録先の死活確認が完了していない場合（ステップＳ７６：ＮＯ）には、上述したステップＳ６２に戻り、サスペンドテーブルＴＢ２０から次の通知先の通知先アドレスを取得し、死活確認を行う。一方、サスペンドテーブルＴＢ２０に登録されているすべての登録先の死活確認が完了した場合（ステップＳ７６：ＹＥＳ）には、プリンタ１６は、このサスペンドテーブル更新処理を終了する。
【００６６】
次に、図１０に基づいて、本実施形態に係るプリンタ１６が実行するＳＮＭＰ  Ｔｒａｐ発行処理について説明する。この図１０のＳＮＭＰ  Ｔｒａｐ発行処理は、このプリンタ１６において予め定められた所定の状態変化が発生し、その状態変化が発生した旨の通知をＳＮＭＰ  Ｔｒａｐにより、ホストコンピュータ１４に知らせる場合に、起動される処理である。すなわち、所定の状態変化をきっかけとして、プリンタ１６で実行される処理である。
【００６７】
また、このサスペンドテーブル更新処理は、プリンタ１６のＣＰＵ２０が、ＲＯＭ２４又はハードディスクドライブ２６に格納されているＳＮＭＰ  Ｔｒａｐ発行処理プログラムを読み込んで実行することにより、実現される処理である。
【００６８】
このＳＮＭＰ  Ｔｒａｐ発行処理が起動されると、まず、プリンタ１６は、通知先の通知先情報テーブルＴＢ１０から、通知先アドレスを取得する（ステップＳ９０）。そして、この通知先アドレスを宛先として、ＳＮＭＰ  Ｔｒａｐを発行する（ステップＳ９２）。
【００６９】
次に、プリンタ１６は、通知先情報テーブルＴＢ１０に登録されているすべての通知先にＳＮＭＰ  Ｔｒａｐを発行したかどうかを判断する（ステップＳ９２）。通知先情報テーブルＴＢ１０に登録されているすべての登録先にＳＮＭＰ  Ｔｒａｐを発行し終えていない場合（ステップＳ９４：ＮＯ）には、上述したステップＳ９０に戻り、次の通知先アドレスを通知先情報テーブルＴＢ１０から取得する。
【００７０】
一方、通知先情報テーブルＴＢ１０に登録されているすべての通知先にＳＮＭＰ  Ｔｒａｐを発行し終えた場合（ステップＳ９４：ＹＥＳ）には、このＳＮＭＰ  Ｔｒａｐ発行処理を終了する。
【００７１】
以上のように、本実施形態に係るデバイスネットワークシステム１０によれば、新しい通知先を通知先情報テーブルＴＢ１０に登録しようとした際に、通知先情報テーブルＴＢ１０に空きが無い場合には、有効に存在していることを確認できない通知先を通知先情報テーブルＴＢ１０からサスペンドテーブルＴＢ２０に移行し、新たな通知先を通知先情報テーブルＴＢ１０に登録できるようにした。このため、通知先情報テーブルＴＢ１０が満杯で新しい通知先が登録できないという事態が発生するのを、可及的に回避して、通知先情報テーブルＴＢ１０の有効利用を図ることができる。
【００７２】
また、通知先情報テーブルＴＢ１０に登録されているすべての通知先が有効に存在していることを確認できた場合でも、最も登録日時の古い通知先をサスペンドテーブルＴＢ２０に移行し、新しい通知先を通知先情報テーブルＴＢ１０に登録できるようにした。このため、通知先情報テーブルＴＢ１０が満杯で新しい通知先が登録できないという事態が発生するのを、回避することができる。
【００７３】
また、通知先情報テーブルＴＢ１０に空き領域ができた場合には、サスペンドテーブルＴＢ２０に移行した通知先であっても、ネットワーク１２上に有効に存在することを確認できた場合には、通知先情報テーブルＴＢ１０に復活できるようにした。このため、何らかの事情により、通知先登録処理で発行されたＰｉｎｇに対して一時的に応答できなかったに過ぎないホストコンピュータ１４は、事後的に救済され、通知先情報テーブルＴＢ１０に戻ることができる。これにより、ネットワーク１２上に有効に存在するホストコンピュータ１４が、誤って通知先情報テーブルＴＢ１０から削除され、所定の状態変化が発生した旨の通知を受信できなくなってしまうのを可及的に回避することができる。
【００７４】
また、ネットワーク１２上に有効に存在しなくなった通知先については、通知先情報テーブルＴＢ１０からサスペンドテーブルＴＢ２０に移行されるので、無駄なＳＮＭＰ  Ｔｒａｐが発行されるのを抑制でき、ネットワーク１２上の無駄なトラフィックを削減することができる。
【００７５】
なお、本発明は上記実施形態に限定されず種々に変形可能である。例えば、上述した実施形態においては、デバイスの状態変化を監視する対象がプリンタ１６である場合を例にして、本発明を説明したが、状態変化を監視する対象のデバイスはプリンタ１６に限られるものではない。換言すれば、本発明に係るデバイス状態通知装置を搭載できるのは、プリンタに限られるものではなく、種々のデバイスに搭載することが可能である。
【００７６】
また、上述した実施形態では、通知先情報テーブルＴＢ１０には、４個まで通知先に関する情報が格納できる場合を例に本発明を説明したが、通知先情報テーブルＴＢ１０に格納できる通知先の数は、任意に設計することができる。
【００７７】
また、上述した実施形態では、ネットワーク１２がＴＣＰ／ＩＰに準拠しており、ＳＮＭＰ  Ｔｒａｐを用いて、監視対象となっているデバイスの状態変化を、ホストコンピュータ１４に通知することしたが、他の通信規格やプロトコルを用いて、この通知を実現できるようにしてもよい。
【００７８】
また、上述した実施形態では、１つのホストコンピュータ１４には、１つの管理アプリケーションが生成されることを前提に説明をしたが、１つのホストコンピュータ１４に複数の管理アプリケーションが生成されてもよい。この場合、プリンタ１６は各管理アプリケーションに対して、上述した各処理を行うこととなる。すなわち、プリンタ１６は、各アプリケーションに対して、死活確認を行ったり、ＳＮＭＰ  Ｔｒａｐを発行したりすればよい。
【００７９】
また、上述した実施形態で説明した通知先登録処理、及び、サスペンドテーブル更新処理、及び、ＳＮＭＰ  Ｔｒａｐ発行処理については、これら各処理を実行するためのプログラムをフレキシブルディスク、ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory）、ＲＯＭ、メモリカード等の記録媒体に記録して、記録媒体の形で頒布することが可能である。この場合、この記録媒体に記録されたプログラムをプリンタ１６に読み込ませ、実行させることにより、上述した実施形態を実現することができる。
【００８０】
また、プリンタ１６は、オペレーティングシステムや別のアプリケーションプログラム等の他のプログラムを備える場合がある。この場合、プリンタ１６の備える他のプログラムを活用するために、そのプリンタ１６が備えるプログラムの中から、上述した実施形態と同等の処理を実現するプログラムを呼び出すような命令を含むプログラムを、記録媒体に記録するようにしてもよい。
【００８１】
さらに、このようなプログラムは、記録媒体の形ではなく、ネットワークを通じて搬送波として頒布することも可能である。ネットワーク上を搬送波の形で伝送されたプログラムは、プリンタ１６に取り込まれて、このプログラムを実行することにより上述した実施形態を実現することができる。
【００８２】
また、記録媒体にプログラムを記録する際や、ネットワーク上を搬送波として伝送される際に、プログラムの暗号化や圧縮化がなされている場合がある。この場合には、これら記録媒体や搬送波からプログラムを読み込んだプリンタ１６は、そのプログラムの復号や伸張を行った上で、実行する必要がある。
【００８３】
また、上述した実施形態では、通知先登録処理、及び、サスペンドテーブル更新処理、及び、ＳＮＭＰ  Ｔｒａｐ発行処理を、ソフトウェアにより実現する場合を例に説明したが、これらの各処理をＡＳＩＣ（Application Specific IC）などのハードウェアにより実現するようにしてもよい。さらには、これらの各処理を、ソフトウェアとハードウェアとが協働して実現するようにしてもよい。
【図面の簡単な説明】
【００８４】
【図１】本発明を適用したデバイスネットワークシステムのネットワーク構成の一例を説明するブロック図。
【図２】本発明を適用したプリンタの内部構成の一例を示すブロック図。
【図３】本発明の一実施形態に係るプリンタで実行される通知先登録処理の内容の一例を説明するフローチャートを示す図（その１）。
【図４】本発明の一実施形態に係るプリンタで実行される通知先登録処理の内容の一例を説明するフローチャートを示す図（その２）。
【図５】図２のプリンタが保持する通知先情報テーブルの構成の一例を示す図。
【図６】図３及び図４の通知先登録処理において、プリンタがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プリンタとホストコンピュータとの間のやり取りの一例を示す図。
【図７】図３及び図４の通知先登録処理において、プリンタがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られなかった場合における、プリンタとホストコンピュータとの間のやり取りの一例を示す図。
【図８】図２のプリンタが保持するサスペンドテーブルの構成の一例を示す図。
【図９】本発明の一実施形態に係るプリンタで実行されるサスペンドテーブル更新処理の内容の一例を説明するフローチャートを示す図。
【図１０】本発明の一実施形態に係るプリンタで実行されるＳＮＭＰ  Ｔｒａｐ発行処理の内容の一例を説明するフローチャートを示す図。
【符号の説明】
【００８５】
１０  デバイスネットワークシステム
１２  ネットワーク
１４（１４Ａ〜１４Ｄ）  ホストコンピュータ
１６  プリンタ
２０  ＣＰＵ
２２  ＲＡＭ
２４  ＲＯＭ
２６  ハードディスクドライブ
２８  印刷機構部
３０  通信インターフェース
【図１】
2010113400.tif 000003
【図２】
2010113400.tif 000004
【図３】
2010113400.tif 000005
【図４】
2010113400.tif 000006
【図５】
2010113400.tif 000007
【図６】
2010113400.tif 000008
【図７】
2010113400.tif 000009
【図８】
2010113400.tif 000010
【図９】
2010113400.tif 000011
【図１０】
2010113400.tif 000012