デバイス状態通知装置
【課題】有効に存在していない通知先を通知先情報テーブルから削除することを可能にしつつ、煩雑な通知先情報テーブルの管理を必要としないデバイス状態通知装置を提供する。
【解決手段】デバイス状態通知装置は、ネットワークに接続されたデバイスの状態変化を、前記ネットワークに接続された通知先に、前記ネットワークを介して通知するデバイス状態通知装置であって、前記デバイスの状態変化があった場合に、その状態変化があったことを通知する通知先が登録されている通知先情報テーブルと、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する通知先有効性確認手段と、前記通知先有効性確認手段により、有効に存在することが確認できなかった通知先を、前記通知先情報テーブルから削除する、登録削除手段と、を備えることを特徴とする。
【解決手段】デバイス状態通知装置は、ネットワークに接続されたデバイスの状態変化を、前記ネットワークに接続された通知先に、前記ネットワークを介して通知するデバイス状態通知装置であって、前記デバイスの状態変化があった場合に、その状態変化があったことを通知する通知先が登録されている通知先情報テーブルと、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する通知先有効性確認手段と、前記通知先有効性確認手段により、有効に存在することが確認できなかった通知先を、前記通知先情報テーブルから削除する、登録削除手段と、を備えることを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイス状態通知装置に関し、特に、デバイスの状態が変化した際に、その変化を通知する機能を有するデバイス状態通知装置に関する。
【背景技術】
【０００２】
ネットワークを介して、プリンタと、複数のホストコンピュータとを相互に接続し、１台のプリンタを複数のホストコンピュータで共有する利用態様が普及している。このような利用態様の場合、各ホストコンピュータは、プリンタの状態変化を監視し、印刷ジョブの開始や終了、プリンタの障害などを監視する必要がある。このような状態変化の監視がホストコンピュータで出来るようにするため、プリンタ側にデバイス状態通知装置が設けられている。
【０００３】
例えば、プリンタとホストコンピュータとの間を接続するネットワークの規格がＴＣＰ／ＩＰである場合、ＳＮＭＰ（Simple Network Management Protocol）を用いることにより、プリンタの監視を実現する。すなわち、ホストコンピュータ側に、ＳＮＭＰに準拠した管理アプリケーションを搭載し、プリンタ側に、同じくＳＮＭＰに準拠したネットワークインターフェースを搭載し、ＳＮＭＰ Ｔｒａｐという監視手段を用いて、ホストコンピュータはプリンタの状態監視を行う。
【０００４】
プリンタ側で予め指定された状態変化が発生したときに、どのホストコンピュータに通知をするのかは、プリンタ側に設けられた通知先情報テーブルに事前に登録されている。しかし、一般的に、通知先情報テーブルに登録できる通知先アドレスの数には制限がある。このため、新たにプリンタの監視を開始しようとしたホストコンピュータが、プリンタの通知先情報テーブルに、自らの通知先アドレスを登録しようとしても、既に通知先情報テーブルに空きがない場合には、その登録ができなくなってしまう。通知先情報テーブルに通知先アドレスの登録ができないと、ホストコンピュータは、そのプリンタの状態監視ができないこととなる。
【０００５】
その一方で、以前に通知先情報テーブルに登録されてた通知先であっても、既に動作を停止していたり、ネットワーク接続を切断していたりして、使用されていない通知先が存在することもある。このような有効に存在していない通知先が通知先情報テーブルに登録されている場合、新しい通知先の登録ができないばかりか、プリンタは、通知先情報テーブルの登録に従って、状態変化の通知を送信し続けることとなり、ネットワーク上を無用なパケットが流れ、ネットワーク負荷の増大を招くこととなる。
【０００６】
このため、例えば、特開２００３−９９３４２号公報（特許文献１）には、ホストコンピュータの管理アプリケーションからの削除要求に基づいて、通知先情報テーブルから通知先を削除する手法を開示している。しかし、この手法は、管理アプリケーションからの削除要求に基づいて通知先を削除するため、ホストコンピュータ側にその管理が委ねられてしまう。このため、何らかの理由で、ホストコンピュータが、この削除要求を出すことなく、ネットワークから外れてしまったような場合には、その通知先は通知先情報テーブルに残ってしまう。
【０００７】
また、例えば、特開２００１−１９７０５９号公報（特許文献２）には、通知先情報テーブルに登録する通知先に有効期限を設ける技術を開示している。しかし、この手法は、通知先情報テーブルにおいて、通知先毎に有効期限を管理しなければならず、その管理が煩雑であるという問題が生じる。
【０００８】
さらにまた、このような問題は、プリンタだけに限られたものではなく、プリンタ以外の様々な種類のデバイスにおいて、その状態変化を通知先に通知するデバイス状態通知装置であれば生じ得る。
【特許文献１】特開２００３−９９３４２号公報
【特許文献２】特開２００１−１９７０５９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
そこで本発明は、前記課題に鑑みてなされたものであり、有効に存在していない通知先を通知先情報テーブルから削除することを可能にしつつ、煩雑な通知先情報テーブルの管理を必要としないデバイス状態通知装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明に係るデバイス状態通知装置は、
ネットワークに接続されたデバイスの状態変化を、前記ネットワークに接続された通知先に、前記ネットワークを介して通知するデバイス状態通知装置であって、
前記デバイスの状態変化があった場合に、その状態変化があったことを通知する通知先が登録されている通知先情報テーブルと、
前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する通知先有効性確認手段と、
前記通知先有効性確認手段により、有効に存在することが確認できなかった通知先を、前記通知先情報テーブルから削除する、登録削除手段と、
を備えることを特徴とする。
【００１１】
この場合、前記通知先有効性確認手段は、前記通知先情報テーブルに登録されている通知先に、何らかの応答を要求する応答要求を発行し、この応答要求に対する応答が得られない場合には、その通知先が有効に存在していないと判断するようにしてもよい。
【００１２】
また、前記通知先有効性確認手段は、定期的に、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認するようにしてもよい。
【００１３】
或いは、前記通知先有効性確認手段は、デバイスに状態変化があったことを通知する際に、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認するようにしてもよい。
【００１４】
また、前記通知先有効性確認手段は、前記応答要求を発行しても通知先から応答が得られない場合、その通知先への前記応答要求を規定回数まで発行し、規定回数を超えて前記応答要求を発行しても応答が得られない通知先については有効に存在していないと判断するようにしてもよい。
【００１５】
或いは、前記通知先有効性確認手段は、通知先へ前記応答要求を発行した後、所定時間が経過しても応答が得られない場合、連続して次の応答要求は発行せずに、確認回数をカウントアップし、
前記登録削除手段は、この確認回数が規定回数を超えた場合に、その通知先を前記通知先情報テーブルから削除するようにしてもよい。
【００１６】
また、前記デバイス状態通知装置は、前記状態変化が監視される前記デイバスに設けられているようにしてもよい。
【００１７】
或いは、前記デバイス状態通知装置はプロキシサーバであり、前記ネットワークを介して、前記状態変化が監視される前記デバイスに接続されるようにしてもよい。
【発明を実施するための形態】
【００１８】
以下、図面を参照して、本発明の実施形態を説明する。なお、以下に説明する実施形態は、本発明の技術的範囲を限定するものではない。
【００１９】
〔第１実施形態〕
図１は、本実施形態に係るデバイスネットワークシステム１０の全体構成を示すブロック図である。この図１に示すように、本実施形態に係るデバイスネットワークシステム１０は、ネットワーク１２に接続された、１又は複数のホストコンピュータ１４と、１又は複数のプリンタ１６とを備えて、構成されている。この図１の例では、４台のホストコンピュータ１４Ａ〜１４Ｄが、ネットワーク１２に接続されており、１台のプリンタ１６が、ネットワーク１２に接続されている。
【００２０】
本実施形態においては、ネットワーク１２は、例えば、ＴＣＰ／ＩＰの規格に準拠しており、このネットワーク１２に、同じくＴＣＰ／ＩＰの規格に準拠したホストコンピュータ１４とプリンタ１６とが接続されている。ホストコンピュータ１４は、プリンタ１６の状態をＳＮＭＰ Ｔｒａｐを用いて監視する。この監視を行うために、ホストコンピュータ１４では、管理アプリケーションが起動されている。
【００２１】
この管理アプリケーションは、例えば、このプリンタ１６に送信した印刷データの印刷開始、その印刷の終了、紙無しエラーの発生、トナー無しエラーの発生などを、ＳＮＭＰ Ｔｒａｐを用いて監視する。プリンタ１６では、予め指定されたこれらの状態が発生すると、ＳＮＭＰ Ｔｒａｐを用いて、指定されたホストコンピュータ１４の管理アプリケーションに通知する。すなわち、プリンタ１６は、これらの状態変化が発生した通知を、通知先アドレス宛に送信する。プリンタ１６は、このような状態の監視がなされるデバイスの一例である。
【００２２】
図２は、本実施形態に係るプリンタ１６の内部構成の一例を示すブロック図である。この図２に示すように、本実施形態に係るプリンタ１６は、ネットワークインターフェース２０と、印刷機能部２２とを備えて、構成されている。ネットワークインターフェース２０は、このプリンタ１６を、ネットワーク１２に接続するためのインターフェースである。このネットワークインターフェース２０が、本実施形態におけるデバイス状態通知装置に相当する。また、印刷機能部２２は、このプリンタ１６で印刷を行うための機能部であり、ネットワークインターフェース２０から受信した印刷データに基づいて、印刷を行う。
【００２３】
さらに、本実施形態においては、ネットワークインターフェース２０は、通知先情報テーブル３０と、状態検知機能部３２と、状態通知機能部３４と、通知先情報テーブル管理機能部３６と、通知先有効性確認機能部３８とを備えている。通知先情報テーブル３０は、ＥＥＰＲＯＭなどの書き換え可能な不揮発性記憶装置に形成されており、プリンタ１６の電源がオフにされても、その内容が保持されように構成されている。
【００２４】
また、状態検知機能部３２と状態通知機能部３４と通知先情報テーブル管理機能部３６と通知先有効性確認機能部３８の各機能部は、ソフトウェア又はハードウェアで実現することができる。例えば、ソフトウェアで実現する場合には、各機能部の機能を実現するプログラムをＣＰＵが読み込んで実行することにより、実現することができる。また、ハードウェアで実現する場合には、各機能部の機能を実現するように設計されたＡＳＩＣ（Application Specific IC）を組み込むことにより、実現することができる。さらに、ソフトウェアとハードウェアとが協働して、これらの各機能部を実現するようにしてもよい。
【００２５】
より具体的には、通知先情報テーブル３０は、予め定められた状態変化がプリンタ１６で発生した場合に、その通知を行う通知先に関する情報を保持するテーブルである。状態検知機能部３２は、各種のプログラムやセンサを用いて、プリンタ１６の状態変化を検出するための機能部である。状態通知機能部３４は、予め定められた状態変化が状態検知機能部３２で検出された場合に、ＳＮＭＰ Ｔｒａｐを用いて、ホストコンピュータ１４に通知するための機能部である。通知すべき通知先アドレスは、状態通知機能部３４が通知先情報テーブル３０を検索して取得する。
【００２６】
通知先情報テーブル管理機能部３６は、ホストコンピュータ１４からの要求や指示に基づいて、通知先情報テーブル３０に新しい通知先を登録したり、既に登録されている通知先を削除したりする。通知先有効性確認機能部３８は、通知先情報テーブル３０に登録されている通知先の有効性を確認し、その通知先が有効に存在しない場合には、通知先情報テーブル３０から削除する処理を行う機能部である。
【００２７】
次に、図３に基づいて、この通知先有効性確認機能部３８が行う処理について、詳細に説明する。この図３は、通知先有効性確認機能部３８が実行する定期死活確認処理の内容を説明するフローチャートを示す図である。この定期死活確認処理は、所定の時間間隔で定期的に起動される処理である。本実施形態においては、例えば、１時間に１回、或いは、２時間に１回といった間隔で起動される。
【００２８】
この図３に示すように、まず、通知先有効性確認機能部３８は、通知先情報テーブル３０から、通知先アドレスを取得する（ステップＳ１０）。図４は、本実施形態に係る通知先情報テーブル３０の内部構成の一例を示す図である。この図４に示すように、通知先情報テーブル３０には、通知先として登録されているホストコンピュータ１４の通知先アドレスが格納されている。本実施形態では、この通知先情報テーブル３０には、最大で４個の通知先アドレスが格納可能である。つまり、本実施形態に係る通知先情報テーブル３０には、４個までしか、通知先アドレスが登録できない。
【００２９】
次に、図３に示すように、通知先有効性確認機能部３８は、死活確認を実行する（ステップＳ１２）。すなわち、ステップＳ１０で取得した通知先アドレスのホストコンピュータ１４が、現時点で、ネットワーク１２上に有効に存在しているのか、それとも、存在していないのかを確認する。
【００３０】
この死活確認には、様々な手法が考えられるが、本実施形態では、図５に示すように、Ｐｉｎｇを発行することにより、確認する。すなわち、プリンタ１６の通知先有効性確認機能部３８は、ステップＳ１０で取得した通知先アドレス宛に、Ｐｉｎｇを発行する。このＰｉｎｇを受信したホストコンピュータ１４の管理アプリケーションは、Ｐｉｎｇ応答を応答パケットとして返信する。したがって、プリンタ１６の通知先有効性確認機能部３８は、このＰｉｎｇ応答が所定時間内に返信されるか否かにより、通知先アドレスのホストコンピュータ１４が有効に存在するか否かを判断する。
【００３１】
このため、図３に示すように、プリンタ１６の通知先有効性確認機能部３８は、所定時間内にホストコンピュータ１４からの応答を受信したかどうかを判断する（ステップＳ１４）。具体的には、Ｐｉｎｇを発行した後、タイムアウトになるまでに、ホストコンピュータ１４からＰｉｎｇ応答を受信したかどうかを判断する。
【００３２】
所定時間内に応答を受信できなかった場合（ステップＳ１４：ＮＯ）には、通知先有効性確認機能部３８は、確認回数を１つカウントアップする（ステップＳ１６）。確認回数の初期値はゼロに設定されており、Ｐｉｎｇを１回発行する度に、確認回数は１増えることとなる。
【００３３】
次に、通知先有効性確認機能部３８は、確認回数が規定回数を超えたかどうかを判断する（ステップＳ１８）。例えば、本実施形態においては、規定回数が３回に設定されている。このため、通知先有効性確認機能部３８は、ステップＳ１６でカウントアップした確認回数が、３回を越えたかどうかを判断する。
【００３４】
確認回数が３回を越えていないと判断した場合（ステップＳ１８：ＮＯ）には、通知先有効性確認機能部３８は、上述したステップＳ１２に戻り、再度、死活確認を実行する。一方、確認回数が３回を越えた場合（ステップＳ１８：ＹＥＳ）、つまり、確認回数が４回だった場合には、通知先有効性確認機能部３８は、通知先情報テーブル３０から、その通知先を削除する（ステップＳ２０）。すなわち、ステップＳ１０で取得した通知先アドレスを、通知先情報テーブル３０から削除する。
【００３５】
図６は、本実施形態において、プリンタ１６の通知先有効性確認機能部３８が３回、Ｐｉｎｇを発行しても、ホストコンピュータ１４から応答が得られなかった場合のプリンタ１６とホストコンピュータ１４との間のやり取りを示している。この図６に示すように、最初にＰｉｎｇを発行し、タイムアウトになると２回目のＰｉｎｇを発行し、さらにこれもタイムアウトになると３回目のＰｉｎｇを発行する。しかし、これもタイムアウトになると、通知先有効性確認機能部３８は、通知先情報テーブル３０から通知先アドレスを削除するのである。
【００３６】
これに対して、図３に示すように、ステップＳ１４において、ホストコンピュータ１４から応答があった場合（ステップＳ１４：ＹＥＳ）には、通知先有効性確認機能部３８は、確認回数をゼロにリセットする（ステップＳ２２）。
【００３７】
このステップＳ２２の後、又は、上述したステップＳ２０の後、通知先有効性確認機能部３８は、通知先情報テーブル３０に登録されているすべての通知先の死活確認を行ったかどうかを判断する（ステップＳ２４）。例えば、図４の例では、２つの通知先が通知先情報テーブル３０に登録されているので、これら２つの通知先について、死活確認を行ったかどうかを判断する。
【００３８】
通知先情報テーブル３０に登録されているすべての登録先の死活確認が完了していない場合（ステップＳ２４：ＮＯ）には、上述したステップＳ１０に戻り、通知先情報テーブル３０から次の通知先の通知先アドレスを取得し、死活確認を行う。一方、通知先情報テーブル３０に登録されているすべての登録先の死活確認が完了した場合（ステップＳ２４：ＹＥＳ）には、この定期死活確認処理を終了する。
【００３９】
なお、図３に示した定期死活確認処理は、通知先情報テーブルに登録された通知先の格納数が通知先情報テーブルに格納できる通知先の最大数に達したときにこの処理を開始することとしてもよい。
【００４０】
以上のように、本実施形態に係るデバイスネットワークシステム１０によれば、通知先情報テーブル３０に登録されているホストコンピュータ１４に対して、定期的に死活確認処理を実行し、応答が得られないホストコンピュータ１４については、通知先情報テーブル３０から通知先アドレスを削除することとした。このため、デバイスネットワークシステム１０に有効に存在していないにも拘わらず、通知先が通知先情報テーブル３０に登録されたままとなってしまうことを回避することができる。これにより、不要な通知先を通知先情報テーブル３０から削除し、新たなホストコンピュータ１４からの登録要求があった場合に、通知先情報テーブル３０に空きが無く、登録ができないという事態が生ずるのを、極力避けることができる。
【００４１】
また、不要な通知先は通知先情報テーブル３０から削除されるため、通知先の存在しないＳＮＭＰ Ｔｒａｐのパケットがネットワーク１２上を流れないようにすることができる。このため、ネットワーク１２上を流れる無駄なパケットを削減することができる。さらに、ホストコンピュータ１４の管理アプリケーションは、従来のアプリケーションをそのまま利用できるので、ホストコンピュータ１４側の設定変更も不要である。
【００４２】
〔第２実施形態〕
上述した第１実施形態では、通知先有効性確認機能部３８は、Ｐｉｎｇ発行後に応答が無い場合、所定時間経過後（タイムアウト後）に、連続的に次のＰｉｎｇを発行することとしたが、本実施形態においては、次に定期死活確認処理が起動された際に、再度Ｐｉｎｇを発行するようにしたものである。すなわち、連続的にＰｉｎｇを再発行するのではなく、所定の時間間隔をおいてから、次のＰｉｎｇを発行するようにしたものである。以下、上述した第１実施形態と異なる部分を説明する。
【００４３】
図７は、本実施形態に係る通知先有効性確認機能部３８が実行する定期死活確認処理の内容を説明するフローチャートを示す図であり、上述した第１実施形態における図３に対応する図である。この定期死活確認処理は、所定の時間間隔で定期的に起動される処理である。本実施形態においても、上述した第１実施形態と同様に、例えば、１時間に１回、或いは、２時間に１回といった間隔で起動される。
【００４４】
この図７に示すように、まず、通知先有効性確認機能部３８は、通知先情報テーブル３０から、通知先アドレスと確認回数を取得する（ステップＳ３０）。図８は、本実施形態に係る通知先情報テーブル３０の内部構成の一例を示す図である。この図８に示すように、本実施形態に係る通知先情報テーブル３０には、通知先として登録されているホストコンピュータ１４の通知先アドレスに加えて、確認回数が格納されている。この確認回数は、対応する通知先アドレスの死活確認を行った際に、応答が返ってこなかった回数を示している。また、この確認回数は、死活確認を行って、存在が確認できた場合には、ゼロにリセットされる回数である。
【００４５】
次に、図７に示すように、通知先有効性確認機能部３８は、死活確認を実行する（ステップＳ３２）。すなわち、上述した第１実施形態と同様の手法で、ステップＳ３０で取得した通知先アドレスのホストコンピュータ１４が、現時点で、ネットワーク１２上に有効に存在しているのか、それとも、存在していないのかを確認する。
【００４６】
次に、プリンタ１６の通知先有効性確認機能部３８は、所定時間内にホストコンピュータ１４からの応答を受信したかどうかを判断する（ステップＳ３４）。具体的には、Ｐｉｎｇを発行した後、タイムアウトになるまでに、ホストコンピュータ１４からＰｉｎｇ応答を受信したかどうかを判断する。
【００４７】
所定時間内に応答を受信できなかった場合（ステップＳ３４：ＮＯ）には、通知先有効性確認機能部３８は、確認回数を１つカウントアップし、カウントアップ後の確認回数を通知先情報テーブル３０に格納する（ステップＳ３６）。
【００４８】
次に、通知先有効性確認機能部３８は、確認回数が規定回数を超えたかどうかを判断する（ステップＳ３８）。例えば、本実施形態においては、規定回数が３回に設定されている。このため、通知先有効性確認機能部３８は、ステップＳ３６でカウントアップした確認回数が、３回を越えたかどうかを判断する。
【００４９】
確認回数が３回を越えたと判断した場合（ステップＳ３８：ＹＥＳ）、つまり、確認回数が４回だった場合には、通知先有効性確認機能部３８は、通知先情報テーブル３０から、その通知先を削除する（ステップＳ４０）。すなわち、ステップＳ３０で取得した通知先アドレスと確認回数を、通知先情報テーブル３０から削除する。
【００５０】
これに対して、ステップＳ３４において、ホストコンピュータ１４から応答があった場合（ステップＳ３４：ＹＥＳ）には、通知先有効性確認機能部３８は、通知先情報テーブル３０の対応する確認回数を、ゼロにリセットする（ステップＳ４２）。
【００５１】
このステップＳ４２の後、又は、上述したステップＳ４０の後、又は、上述したステップＳ３８で確認回数が規定回数を超えていないと判断した場合（ステップＳ３８：ＮＯ）には、通知先有効性確認機能部３８は、通知先情報テーブル３０に登録されているすべての通知先の死活確認を行ったかどうかを判断する（ステップＳ４４）。例えば、図８の例では、２つの通知先が通知先情報テーブル３０に登録されているので、これら２つの通知先について、それぞれ１回ずつ死活確認を行ったかどうかを判断する。
【００５２】
通知先情報テーブル３０に登録されているすべての登録先の死活確認が完了していない場合（ステップＳ４４：ＮＯ）には、上述したステップＳ３０に戻り、通知先情報テーブル３０から次の通知先の通知先アドレスと確認回数を取得し、死活確認を行う。一方、通知先情報テーブル３０に登録されているすべての登録先の死活確認が完了した場合（ステップＳ４４：ＹＥＳ）には、この定期死活確認処理を終了する。
【００５３】
なお、図７に示した定期死活確認処理は、通知先情報テーブルに登録された通知先の格納数が通知先情報テーブルに格納できる通知先の最大数に達したときにこの処理を開始することとしてもよい。
【００５４】
以上のように、本実施形態に係るデバイスネットワークシステム１０によっても、通知先情報テーブル３０に登録されているホストコンピュータ１４に対して、定期的に死活確認処理を実行し、応答が得られないホストコンピュータ１４については、通知先情報テーブル３０から通知先アドレスを削除することとした。このため、デバイスネットワークシステム１０に有効に存在していないにも拘わらず、通知先が通知先情報テーブル３０に登録されたままとなってしまうことを回避することができる。
【００５５】
また、ステップＳ３４において、タイムアウトとなってホストコンピュータ１４の存在が確認できなかった場合、連続的に次の死活確認を行うのではなく、次の定期死活確認処理で、そのホストコンピュータ１４の死活確認を行うこととしたので、何らかの理由でホストコンピュータ１４が一時的に応答できなかったに過ぎないような場合に、その登録が通知先情報テーブル３０から削除されてしまうのを回避することができる。
【００５６】
〔第３実施形態〕
上述した第１実施形態では、通知先情報テーブル３０に登録されている通知先のホストコンピュータ１４の有効性を、定期的に確認することとしたが、本実施形態では、通知先にＳＮＭＰ Ｔｒａｐを発行する際に合わせて確認するようにしたものである。以下、上述した第１実施形態と異なる部分を説明する。
【００５７】
図９は、本実施形態に係るＴｒａｐ発行処理の内容を説明するフローチャートを示す図である。このＴｒａｐ発行処理は、上述した第１実施形態と同様に通知先有効性確認機能部３８が実行する処理であるが、本実施形態においては、このＴｒａｐ発行処理は、第１実施形態のように定期的に起動されるのではなく、ＳＮＭＰ Ｔｒａｐを発行する際に起動される処理である。
【００５８】
図９に示すように、本実施形態に係るＴｒａｐ発行処理は、ステップＳ１０〜ステップＳ２０及びステップＳ２４の処理内容は、上述した第１実施形態と同様であるが、ステップＳ１４において、死活確認に対する応答を受信した場合の処理が、第１実施形態と異なる。
【００５９】
すなわち、本実施形態においては、死活確認に対する応答を受信した場合（ステップＳ１４：ＹＥＳ）には、通知先有効性確認機能部３８は、状態通知機能部３４を介して、ステップＳ１０で取得した通知先アドレスに、ＳＮＭＰ Ｔｒａｐを発行する（ステップＳ５０）。すなわち、図１０に示すように、状態通知機能部３４を起動して、Ｐｉｎｇ応答が受信できた通知先に対して、ＳＮＭＰ Ｔｒａｐを発行する。但し、プリンタ１６で発生した状態変化の種別によっては、その状態変化を通知するような設定になっていない通知先も存在し得る。このように、発生した状態変化が、通知を求める種別の状態変化ではない通知先については、ＳＮＭＰ Ｔｒａｐは発行しない。続いて、通知先有効性確認機能部３８は、確認回数をゼロにリセットする（ステップＳ５２）。
【００６０】
このステップＳ５２の後、又は、ステップＳ２０の後、通知先有効性確認機能部３８は、上述した第１実施形態と同様に、通知先情報テーブル３０に登録されているすべての通知先の死活確認を行ったかどうかを判断し（ステップＳ２４）、すべての登録先の死活確認が完了していない場合（ステップＳ２４：ＮＯ）には、上述したステップＳ１０に戻り、通知先情報テーブル３０から次の通知先の通知先アドレスを取得し、死活確認を行う。一方、通知先情報テーブル３０に登録されているすべての登録先の死活確認が完了した場合（ステップＳ２４：ＹＥＳ）には、この定期死活確認処理を終了する。
【００６１】
以上のように、本実施形態に係るデバイスネットワークシステム１０によっても、通知先情報テーブル３０に登録されているホストコンピュータ１４に対して、定期的に死活確認処理を実行し、応答が得られないホストコンピュータ１４については、通知先情報テーブル３０から通知先アドレスを削除することとした。このため、デバイスネットワークシステム１０に有効に存在していないにも拘わらず、通知先情報テーブル３０に登録されたままとなってしまうことを回避することができる。これにより、不要な通知先を通知先情報テーブル３０から削除し、新たなホストコンピュータ１４からの登録要求があった場合に、通知先情報テーブル３０に空きが無く、登録ができないという事態が生ずるのを、極力避けることができる。
【００６２】
また、ＳＮＭＰ Ｔｒａｐを発行する際に、通知先情報テーブル３０に登録されている登録先の有効性も合わせて確認することとしたので、定期的に死活確認処理を起動するための管理が不要になる。
【００６３】
〔第１乃至第３実施形態の変形例〕
上述した第１実施形態乃至第３実施形態のデバイスネットワークシステム１０では、プリンタ１６が通知先情報テーブル３０を保持して管理することとしたが、このデバイスネットワークシステム１０にプロキシサーバを設けて、このプロキシサーバが通知先情報テーブル３０を保持して管理するようにしてもよい。
【００６４】
図１１は、デバイスネットワークシステム１０にプロキシサーバ４０を設けた場合の全体システム構成の一例を示すブロック図である。この図１１に示すように、プロキシサーバ４０は、ネットワーク１２に接続され、このネットワーク１２に関する管理を行う。本実施形態では、このプロキシサーバ４０は、Ｔｒａｐ発行の管理を行うとともに、上述したデバイス状態通知装置が組み込まれており、通知先情報テーブル３０の管理を行う。このようなデバイスネットワークシステム１０の構成であっても、上述した第１実施形態乃至第３実施形態のそれぞれ実施形態を実現することができる。
【００６５】
図１１のデバイスネットワークシステム１０に、第１実施形態を適用する場合には、プロキシサーバ４０が、図３に示した定期死活確認処理を実行する。そして、上述したステップＳ１２の死活確認を実行する際に、図１２に示すように、プロキシサーバ４０が、ステップＳ１０で取得した通知先アドレスにＰｉｎｇを発行する。この発行したＰｉｎｇに対する応答が得られるか否かで、通知先アドレスに対応するホストコンピュータ１４の存在を確認する。図１２に示すように、発行したＰｉｎｇに対する応答が得られた場合（ステップＳ１４：ＹＥＳ）には、プロキシサーバ４０は、通知先情報テーブル３０の登録をそのまま維持する。
【００６６】
一方、図１３に示すように、Ｐｉｎｇを発行しても応答が得られない場合（ステップＳ１４：ＮＯ）には、プロキシサーバ４０は、タイムアウト発生後に、規定回数まではＰｉｎｇの発行を連続的に繰り返す。本実施形態においては、規定回数は３回であるので、最初にＰｉｎｇを発行し、タイムアウトになると２回目のＰｉｎｇを発行し、さらにこれもタイムアウトになると３回目のＰｉｎｇを発行する。しかし、これもタイムアウトになると、プロキシサーバ４０は、通知先情報テーブル３０から通知先アドレスを削除するのである。
【００６７】
この図１１のデバイスネットワークシステム１０のネットワーク構成においては、プリンタ１６でＳＮＭＰ Ｔｒａｐを発行すべき状態変化が生じた場合、プリンタ１６は、そのＳＮＭＰ Ｔｒａｐをプロキシサーバ４０に対して発行する。このＳＮＭＰ Ｔｒａｐを受信したプロキシサーバ４０は、通知先情報テーブル３０を検索し、この状態変化を通知すべきホストコンピュータ１４の通知先アドレスを取得し、ＳＮＭＰ Ｔｒａｐをそれぞれの通知先に対して発行する。
【００６８】
一方、図１１のデバイスネットワークシステム１０に、第２実施形態を適用する場合には、プロキシサーバ４０が、図７に示した定期死活確認処理を実行する。すなわち、プロキシサーバ４０が、定期的に起動される定期死活確認処理において、死活確認の実行を各通知先について１回ずつ行い（ステップＳ３２）、応答が得られない場合（ステップＳ３４：ＮＯ）でも、連続して死活確認は行わない。そして、次の定期死活確認処理において、再び死活確認を行い、死活確認の確認回数が規定回数を超えるまで、通知先情報テーブル３０から削除しない（ステップＳ３８：ＮＯ）。この死活確認を繰り返し、確認回数が規定回数を超えた場合（ステップＳ３８：ＹＥＳ）には、そのホストコンピュータ１４の通知先アドレスを、通知先情報テーブル３０から削除する（ステップＳ４０）。
【００６９】
また、図１１のデバイスネットワークシステム１０に、第３実施形態を適用する場合には、プロキシサーバ４０が、図９に示したＴｒａｐ発行処理を実行する。すなわち、プロキシサーバ４０がプリンタ１６からＳＮＭＰ Ｔｒａｐを受信した場合に、図９に示すＴｒａｐ発行処理を実行する。
【００７０】
具体的には、この図９のＴｒａｐ発行処理において、プロキシサーバ４０が、ステップＳ１０で取得した通知先アドレスにＰｉｎｇを発行する（ステップＳ１２）。そして、Ｐｉｎｇ応答が得られるか否かで、通知先アドレスに対応するホストコンピュータ１４の存在を確認する。図１４に示すように、Ｐｉｎｇ応答が得られた場合（ステップＳ１４：ＹＥＳ）には、プロキシサーバ４０は、その通知先にＳＮＭＰ Ｔｒａｐを発行する（ステップＳ５０）。
【００７１】
一方、図１５に示すように、Ｐｉｎｇを発行しても応答が得られない場合（ステップＳ１４：ＮＯ）には、プロキシサーバ４０は、タイムアウト発生後に、規定回数まではＰｉｎｇの発行を連続的に繰り返す。本実施形態においては、規定回数は３回であるので、最初にＰｉｎｇを発行し、タイムアウトになると２回目のＰｉｎｇを発行し、さらにこれもタイムアウトになると３回目のＰｉｎｇを発行する。しかし、これもタイムアウトになると、プロキシサーバ４０は、通知先情報テーブル３０から通知先アドレスを削除するのである。
【００７２】
このように、プロキシサーバ４０を用いても、上述した第１実施形態乃至第３実施形態と同様の通知先情報テーブル３０の管理を、プロキシサーバ４０で実現することができる。
【００７３】
なお、本発明は上記実施形態に限定されず種々に変形可能である。例えば、上述した実施形態においては、デバイスの状態変化を監視する対象がプリンタ１６である場合を例にして、本発明を説明したが、状態変化を監視する対象のデバイスはプリンタ１６に限られるものではない。
【００７４】
また、上述した実施形態では、通知先情報テーブル３０には、４個まで通知先に関する情報が格納できる場合を例に本発明を説明したが、通知先情報テーブル３０に格納できる通知先の数は、任意に設計することができる。
【００７５】
また、上述した実施形態では、ネットワーク１２がＴＣＰ／ＩＰに準拠しており、ＳＮＭＰ Ｔｒａｐを用いて、監視対象となっているデバイスの状態変化を、ホストコンピュータ１４に通知することしたが、他の通信規格やプロトコルを用いて、この通知を実現できるようにしてもよい。
【００７６】
また、上述した実施形態では、１つのホストコンピュータ１４には、１つの管理アプリケーションが生成されることを前提に説明をしたが、１つのホストコンピュータ１４に複数の管理アプリケーションが生成されてもよい。この場合、プリンタ１６は各管理アプリケーションに対して、上述した各処理を行うこととなる。すなわち、プリンタ１６は、各アプリケーションに対して、死活確認を行ったり、ＳＮＭＰ Ｔｒａｐを発行したりすればよい。
【図面の簡単な説明】
【００７７】
【図１】本発明の適用されたデバイスネットワークシステムのネットワーク構成の一例を説明するブロック図。
【図２】本発明を適用したプリンタの内部構成の一例を示す機能ブロック図。
【図３】本発明の第１実施形態に係るプリンタで実行される定期死活確認処理の内容の一例を説明するフローチャートを示す図。
【図４】図２のプリンタが保持する通知先情報テーブルの構成の一例を示す図。
【図５】図３の定期死活確認処理において、プリンタがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プリンタとホストコンピュータとの間のやり取りの一例を示す図。
【図６】図３の定期死活確認処理において、プリンタがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られなかった場合における、プリンタとホストコンピュータとの間のやり取りの一例を示す図。
【図７】本発明の第２実施形態に係るプリンタで実行される定期死活確認処理の内容の一例を説明するフローチャートを示す図。
【図８】図２のプリンタが保持する通知先情報テーブルの構成の一例を示す図。
【図９】本発明の第３実施形態に係るプリンタで実行されるＴｒａｐ発行処理の内容の一例を説明するフローチャートを示す図。
【図１０】図９のＴｒａｐ発行処理において、プリンタがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プリンタとホストコンピュータとの間のやり取りの一例を示す図。
【図１１】図１のデバイスネットワークシステムにプロキシサーバを追加した場合のネットワーク構成の一例を説明するブロック図。
【図１２】図１１のデバイスネットワークシステムのプロキシサーバに、第１実施形態を適用した場合において、プロキシサーバがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プロキシサーバとホストコンピュータとの間のやり取りの一例を示す図。
【図１３】図１１のデバイスネットワークシステムのプロキシサーバに、第１実施形態を適用した場合において、プロキシサーバがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られなかった場合における、プロキシサーバとホストコンピュータとの間のやり取りの一例を示す図。
【図１４】図１１のデバイスネットワークシステムのプロキシサーバに、第３実施形態を適用した場合において、プロキシサーバがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プリンタとプロキシサーバとホストコンピュータとの間のやり取りの一例を示す図。
【図１５】図１１のデバイスネットワークシステムのプロキシサーバに、第３実施形態を適用した場合において、プロキシサーバがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プリンタとプロキシサーバとホストコンピュータとの間のやり取りの一例を示す図。
【符号の説明】
【００７８】
１０ デバイスネットワークシステム
１２ ネットワーク
１４（１４Ａ〜１４Ｄ） ホストコンピュータ
１６ プリンタ
２０ ネットワークインターフェース
２２ 印刷機能部
３０ 通知先情報テーブル
３２ 状態検知機能部
３４ 状態通知機能部
３６ 通知先情報テーブル管理機能部
３８ 通知先有効性確認機能部
【技術分野】
【０００１】
本発明は、デバイス状態通知装置に関し、特に、デバイスの状態が変化した際に、その変化を通知する機能を有するデバイス状態通知装置に関する。
【背景技術】
【０００２】
ネットワークを介して、プリンタと、複数のホストコンピュータとを相互に接続し、１台のプリンタを複数のホストコンピュータで共有する利用態様が普及している。このような利用態様の場合、各ホストコンピュータは、プリンタの状態変化を監視し、印刷ジョブの開始や終了、プリンタの障害などを監視する必要がある。このような状態変化の監視がホストコンピュータで出来るようにするため、プリンタ側にデバイス状態通知装置が設けられている。
【０００３】
例えば、プリンタとホストコンピュータとの間を接続するネットワークの規格がＴＣＰ／ＩＰである場合、ＳＮＭＰ（Simple Network Management Protocol）を用いることにより、プリンタの監視を実現する。すなわち、ホストコンピュータ側に、ＳＮＭＰに準拠した管理アプリケーションを搭載し、プリンタ側に、同じくＳＮＭＰに準拠したネットワークインターフェースを搭載し、ＳＮＭＰ Ｔｒａｐという監視手段を用いて、ホストコンピュータはプリンタの状態監視を行う。
【０００４】
プリンタ側で予め指定された状態変化が発生したときに、どのホストコンピュータに通知をするのかは、プリンタ側に設けられた通知先情報テーブルに事前に登録されている。しかし、一般的に、通知先情報テーブルに登録できる通知先アドレスの数には制限がある。このため、新たにプリンタの監視を開始しようとしたホストコンピュータが、プリンタの通知先情報テーブルに、自らの通知先アドレスを登録しようとしても、既に通知先情報テーブルに空きがない場合には、その登録ができなくなってしまう。通知先情報テーブルに通知先アドレスの登録ができないと、ホストコンピュータは、そのプリンタの状態監視ができないこととなる。
【０００５】
その一方で、以前に通知先情報テーブルに登録されてた通知先であっても、既に動作を停止していたり、ネットワーク接続を切断していたりして、使用されていない通知先が存在することもある。このような有効に存在していない通知先が通知先情報テーブルに登録されている場合、新しい通知先の登録ができないばかりか、プリンタは、通知先情報テーブルの登録に従って、状態変化の通知を送信し続けることとなり、ネットワーク上を無用なパケットが流れ、ネットワーク負荷の増大を招くこととなる。
【０００６】
このため、例えば、特開２００３−９９３４２号公報（特許文献１）には、ホストコンピュータの管理アプリケーションからの削除要求に基づいて、通知先情報テーブルから通知先を削除する手法を開示している。しかし、この手法は、管理アプリケーションからの削除要求に基づいて通知先を削除するため、ホストコンピュータ側にその管理が委ねられてしまう。このため、何らかの理由で、ホストコンピュータが、この削除要求を出すことなく、ネットワークから外れてしまったような場合には、その通知先は通知先情報テーブルに残ってしまう。
【０００７】
また、例えば、特開２００１−１９７０５９号公報（特許文献２）には、通知先情報テーブルに登録する通知先に有効期限を設ける技術を開示している。しかし、この手法は、通知先情報テーブルにおいて、通知先毎に有効期限を管理しなければならず、その管理が煩雑であるという問題が生じる。
【０００８】
さらにまた、このような問題は、プリンタだけに限られたものではなく、プリンタ以外の様々な種類のデバイスにおいて、その状態変化を通知先に通知するデバイス状態通知装置であれば生じ得る。
【特許文献１】特開２００３−９９３４２号公報
【特許文献２】特開２００１−１９７０５９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
そこで本発明は、前記課題に鑑みてなされたものであり、有効に存在していない通知先を通知先情報テーブルから削除することを可能にしつつ、煩雑な通知先情報テーブルの管理を必要としないデバイス状態通知装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明に係るデバイス状態通知装置は、
ネットワークに接続されたデバイスの状態変化を、前記ネットワークに接続された通知先に、前記ネットワークを介して通知するデバイス状態通知装置であって、
前記デバイスの状態変化があった場合に、その状態変化があったことを通知する通知先が登録されている通知先情報テーブルと、
前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する通知先有効性確認手段と、
前記通知先有効性確認手段により、有効に存在することが確認できなかった通知先を、前記通知先情報テーブルから削除する、登録削除手段と、
を備えることを特徴とする。
【００１１】
この場合、前記通知先有効性確認手段は、前記通知先情報テーブルに登録されている通知先に、何らかの応答を要求する応答要求を発行し、この応答要求に対する応答が得られない場合には、その通知先が有効に存在していないと判断するようにしてもよい。
【００１２】
また、前記通知先有効性確認手段は、定期的に、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認するようにしてもよい。
【００１３】
或いは、前記通知先有効性確認手段は、デバイスに状態変化があったことを通知する際に、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認するようにしてもよい。
【００１４】
また、前記通知先有効性確認手段は、前記応答要求を発行しても通知先から応答が得られない場合、その通知先への前記応答要求を規定回数まで発行し、規定回数を超えて前記応答要求を発行しても応答が得られない通知先については有効に存在していないと判断するようにしてもよい。
【００１５】
或いは、前記通知先有効性確認手段は、通知先へ前記応答要求を発行した後、所定時間が経過しても応答が得られない場合、連続して次の応答要求は発行せずに、確認回数をカウントアップし、
前記登録削除手段は、この確認回数が規定回数を超えた場合に、その通知先を前記通知先情報テーブルから削除するようにしてもよい。
【００１６】
また、前記デバイス状態通知装置は、前記状態変化が監視される前記デイバスに設けられているようにしてもよい。
【００１７】
或いは、前記デバイス状態通知装置はプロキシサーバであり、前記ネットワークを介して、前記状態変化が監視される前記デバイスに接続されるようにしてもよい。
【発明を実施するための形態】
【００１８】
以下、図面を参照して、本発明の実施形態を説明する。なお、以下に説明する実施形態は、本発明の技術的範囲を限定するものではない。
【００１９】
〔第１実施形態〕
図１は、本実施形態に係るデバイスネットワークシステム１０の全体構成を示すブロック図である。この図１に示すように、本実施形態に係るデバイスネットワークシステム１０は、ネットワーク１２に接続された、１又は複数のホストコンピュータ１４と、１又は複数のプリンタ１６とを備えて、構成されている。この図１の例では、４台のホストコンピュータ１４Ａ〜１４Ｄが、ネットワーク１２に接続されており、１台のプリンタ１６が、ネットワーク１２に接続されている。
【００２０】
本実施形態においては、ネットワーク１２は、例えば、ＴＣＰ／ＩＰの規格に準拠しており、このネットワーク１２に、同じくＴＣＰ／ＩＰの規格に準拠したホストコンピュータ１４とプリンタ１６とが接続されている。ホストコンピュータ１４は、プリンタ１６の状態をＳＮＭＰ Ｔｒａｐを用いて監視する。この監視を行うために、ホストコンピュータ１４では、管理アプリケーションが起動されている。
【００２１】
この管理アプリケーションは、例えば、このプリンタ１６に送信した印刷データの印刷開始、その印刷の終了、紙無しエラーの発生、トナー無しエラーの発生などを、ＳＮＭＰ Ｔｒａｐを用いて監視する。プリンタ１６では、予め指定されたこれらの状態が発生すると、ＳＮＭＰ Ｔｒａｐを用いて、指定されたホストコンピュータ１４の管理アプリケーションに通知する。すなわち、プリンタ１６は、これらの状態変化が発生した通知を、通知先アドレス宛に送信する。プリンタ１６は、このような状態の監視がなされるデバイスの一例である。
【００２２】
図２は、本実施形態に係るプリンタ１６の内部構成の一例を示すブロック図である。この図２に示すように、本実施形態に係るプリンタ１６は、ネットワークインターフェース２０と、印刷機能部２２とを備えて、構成されている。ネットワークインターフェース２０は、このプリンタ１６を、ネットワーク１２に接続するためのインターフェースである。このネットワークインターフェース２０が、本実施形態におけるデバイス状態通知装置に相当する。また、印刷機能部２２は、このプリンタ１６で印刷を行うための機能部であり、ネットワークインターフェース２０から受信した印刷データに基づいて、印刷を行う。
【００２３】
さらに、本実施形態においては、ネットワークインターフェース２０は、通知先情報テーブル３０と、状態検知機能部３２と、状態通知機能部３４と、通知先情報テーブル管理機能部３６と、通知先有効性確認機能部３８とを備えている。通知先情報テーブル３０は、ＥＥＰＲＯＭなどの書き換え可能な不揮発性記憶装置に形成されており、プリンタ１６の電源がオフにされても、その内容が保持されように構成されている。
【００２４】
また、状態検知機能部３２と状態通知機能部３４と通知先情報テーブル管理機能部３６と通知先有効性確認機能部３８の各機能部は、ソフトウェア又はハードウェアで実現することができる。例えば、ソフトウェアで実現する場合には、各機能部の機能を実現するプログラムをＣＰＵが読み込んで実行することにより、実現することができる。また、ハードウェアで実現する場合には、各機能部の機能を実現するように設計されたＡＳＩＣ（Application Specific IC）を組み込むことにより、実現することができる。さらに、ソフトウェアとハードウェアとが協働して、これらの各機能部を実現するようにしてもよい。
【００２５】
より具体的には、通知先情報テーブル３０は、予め定められた状態変化がプリンタ１６で発生した場合に、その通知を行う通知先に関する情報を保持するテーブルである。状態検知機能部３２は、各種のプログラムやセンサを用いて、プリンタ１６の状態変化を検出するための機能部である。状態通知機能部３４は、予め定められた状態変化が状態検知機能部３２で検出された場合に、ＳＮＭＰ Ｔｒａｐを用いて、ホストコンピュータ１４に通知するための機能部である。通知すべき通知先アドレスは、状態通知機能部３４が通知先情報テーブル３０を検索して取得する。
【００２６】
通知先情報テーブル管理機能部３６は、ホストコンピュータ１４からの要求や指示に基づいて、通知先情報テーブル３０に新しい通知先を登録したり、既に登録されている通知先を削除したりする。通知先有効性確認機能部３８は、通知先情報テーブル３０に登録されている通知先の有効性を確認し、その通知先が有効に存在しない場合には、通知先情報テーブル３０から削除する処理を行う機能部である。
【００２７】
次に、図３に基づいて、この通知先有効性確認機能部３８が行う処理について、詳細に説明する。この図３は、通知先有効性確認機能部３８が実行する定期死活確認処理の内容を説明するフローチャートを示す図である。この定期死活確認処理は、所定の時間間隔で定期的に起動される処理である。本実施形態においては、例えば、１時間に１回、或いは、２時間に１回といった間隔で起動される。
【００２８】
この図３に示すように、まず、通知先有効性確認機能部３８は、通知先情報テーブル３０から、通知先アドレスを取得する（ステップＳ１０）。図４は、本実施形態に係る通知先情報テーブル３０の内部構成の一例を示す図である。この図４に示すように、通知先情報テーブル３０には、通知先として登録されているホストコンピュータ１４の通知先アドレスが格納されている。本実施形態では、この通知先情報テーブル３０には、最大で４個の通知先アドレスが格納可能である。つまり、本実施形態に係る通知先情報テーブル３０には、４個までしか、通知先アドレスが登録できない。
【００２９】
次に、図３に示すように、通知先有効性確認機能部３８は、死活確認を実行する（ステップＳ１２）。すなわち、ステップＳ１０で取得した通知先アドレスのホストコンピュータ１４が、現時点で、ネットワーク１２上に有効に存在しているのか、それとも、存在していないのかを確認する。
【００３０】
この死活確認には、様々な手法が考えられるが、本実施形態では、図５に示すように、Ｐｉｎｇを発行することにより、確認する。すなわち、プリンタ１６の通知先有効性確認機能部３８は、ステップＳ１０で取得した通知先アドレス宛に、Ｐｉｎｇを発行する。このＰｉｎｇを受信したホストコンピュータ１４の管理アプリケーションは、Ｐｉｎｇ応答を応答パケットとして返信する。したがって、プリンタ１６の通知先有効性確認機能部３８は、このＰｉｎｇ応答が所定時間内に返信されるか否かにより、通知先アドレスのホストコンピュータ１４が有効に存在するか否かを判断する。
【００３１】
このため、図３に示すように、プリンタ１６の通知先有効性確認機能部３８は、所定時間内にホストコンピュータ１４からの応答を受信したかどうかを判断する（ステップＳ１４）。具体的には、Ｐｉｎｇを発行した後、タイムアウトになるまでに、ホストコンピュータ１４からＰｉｎｇ応答を受信したかどうかを判断する。
【００３２】
所定時間内に応答を受信できなかった場合（ステップＳ１４：ＮＯ）には、通知先有効性確認機能部３８は、確認回数を１つカウントアップする（ステップＳ１６）。確認回数の初期値はゼロに設定されており、Ｐｉｎｇを１回発行する度に、確認回数は１増えることとなる。
【００３３】
次に、通知先有効性確認機能部３８は、確認回数が規定回数を超えたかどうかを判断する（ステップＳ１８）。例えば、本実施形態においては、規定回数が３回に設定されている。このため、通知先有効性確認機能部３８は、ステップＳ１６でカウントアップした確認回数が、３回を越えたかどうかを判断する。
【００３４】
確認回数が３回を越えていないと判断した場合（ステップＳ１８：ＮＯ）には、通知先有効性確認機能部３８は、上述したステップＳ１２に戻り、再度、死活確認を実行する。一方、確認回数が３回を越えた場合（ステップＳ１８：ＹＥＳ）、つまり、確認回数が４回だった場合には、通知先有効性確認機能部３８は、通知先情報テーブル３０から、その通知先を削除する（ステップＳ２０）。すなわち、ステップＳ１０で取得した通知先アドレスを、通知先情報テーブル３０から削除する。
【００３５】
図６は、本実施形態において、プリンタ１６の通知先有効性確認機能部３８が３回、Ｐｉｎｇを発行しても、ホストコンピュータ１４から応答が得られなかった場合のプリンタ１６とホストコンピュータ１４との間のやり取りを示している。この図６に示すように、最初にＰｉｎｇを発行し、タイムアウトになると２回目のＰｉｎｇを発行し、さらにこれもタイムアウトになると３回目のＰｉｎｇを発行する。しかし、これもタイムアウトになると、通知先有効性確認機能部３８は、通知先情報テーブル３０から通知先アドレスを削除するのである。
【００３６】
これに対して、図３に示すように、ステップＳ１４において、ホストコンピュータ１４から応答があった場合（ステップＳ１４：ＹＥＳ）には、通知先有効性確認機能部３８は、確認回数をゼロにリセットする（ステップＳ２２）。
【００３７】
このステップＳ２２の後、又は、上述したステップＳ２０の後、通知先有効性確認機能部３８は、通知先情報テーブル３０に登録されているすべての通知先の死活確認を行ったかどうかを判断する（ステップＳ２４）。例えば、図４の例では、２つの通知先が通知先情報テーブル３０に登録されているので、これら２つの通知先について、死活確認を行ったかどうかを判断する。
【００３８】
通知先情報テーブル３０に登録されているすべての登録先の死活確認が完了していない場合（ステップＳ２４：ＮＯ）には、上述したステップＳ１０に戻り、通知先情報テーブル３０から次の通知先の通知先アドレスを取得し、死活確認を行う。一方、通知先情報テーブル３０に登録されているすべての登録先の死活確認が完了した場合（ステップＳ２４：ＹＥＳ）には、この定期死活確認処理を終了する。
【００３９】
なお、図３に示した定期死活確認処理は、通知先情報テーブルに登録された通知先の格納数が通知先情報テーブルに格納できる通知先の最大数に達したときにこの処理を開始することとしてもよい。
【００４０】
以上のように、本実施形態に係るデバイスネットワークシステム１０によれば、通知先情報テーブル３０に登録されているホストコンピュータ１４に対して、定期的に死活確認処理を実行し、応答が得られないホストコンピュータ１４については、通知先情報テーブル３０から通知先アドレスを削除することとした。このため、デバイスネットワークシステム１０に有効に存在していないにも拘わらず、通知先が通知先情報テーブル３０に登録されたままとなってしまうことを回避することができる。これにより、不要な通知先を通知先情報テーブル３０から削除し、新たなホストコンピュータ１４からの登録要求があった場合に、通知先情報テーブル３０に空きが無く、登録ができないという事態が生ずるのを、極力避けることができる。
【００４１】
また、不要な通知先は通知先情報テーブル３０から削除されるため、通知先の存在しないＳＮＭＰ Ｔｒａｐのパケットがネットワーク１２上を流れないようにすることができる。このため、ネットワーク１２上を流れる無駄なパケットを削減することができる。さらに、ホストコンピュータ１４の管理アプリケーションは、従来のアプリケーションをそのまま利用できるので、ホストコンピュータ１４側の設定変更も不要である。
【００４２】
〔第２実施形態〕
上述した第１実施形態では、通知先有効性確認機能部３８は、Ｐｉｎｇ発行後に応答が無い場合、所定時間経過後（タイムアウト後）に、連続的に次のＰｉｎｇを発行することとしたが、本実施形態においては、次に定期死活確認処理が起動された際に、再度Ｐｉｎｇを発行するようにしたものである。すなわち、連続的にＰｉｎｇを再発行するのではなく、所定の時間間隔をおいてから、次のＰｉｎｇを発行するようにしたものである。以下、上述した第１実施形態と異なる部分を説明する。
【００４３】
図７は、本実施形態に係る通知先有効性確認機能部３８が実行する定期死活確認処理の内容を説明するフローチャートを示す図であり、上述した第１実施形態における図３に対応する図である。この定期死活確認処理は、所定の時間間隔で定期的に起動される処理である。本実施形態においても、上述した第１実施形態と同様に、例えば、１時間に１回、或いは、２時間に１回といった間隔で起動される。
【００４４】
この図７に示すように、まず、通知先有効性確認機能部３８は、通知先情報テーブル３０から、通知先アドレスと確認回数を取得する（ステップＳ３０）。図８は、本実施形態に係る通知先情報テーブル３０の内部構成の一例を示す図である。この図８に示すように、本実施形態に係る通知先情報テーブル３０には、通知先として登録されているホストコンピュータ１４の通知先アドレスに加えて、確認回数が格納されている。この確認回数は、対応する通知先アドレスの死活確認を行った際に、応答が返ってこなかった回数を示している。また、この確認回数は、死活確認を行って、存在が確認できた場合には、ゼロにリセットされる回数である。
【００４５】
次に、図７に示すように、通知先有効性確認機能部３８は、死活確認を実行する（ステップＳ３２）。すなわち、上述した第１実施形態と同様の手法で、ステップＳ３０で取得した通知先アドレスのホストコンピュータ１４が、現時点で、ネットワーク１２上に有効に存在しているのか、それとも、存在していないのかを確認する。
【００４６】
次に、プリンタ１６の通知先有効性確認機能部３８は、所定時間内にホストコンピュータ１４からの応答を受信したかどうかを判断する（ステップＳ３４）。具体的には、Ｐｉｎｇを発行した後、タイムアウトになるまでに、ホストコンピュータ１４からＰｉｎｇ応答を受信したかどうかを判断する。
【００４７】
所定時間内に応答を受信できなかった場合（ステップＳ３４：ＮＯ）には、通知先有効性確認機能部３８は、確認回数を１つカウントアップし、カウントアップ後の確認回数を通知先情報テーブル３０に格納する（ステップＳ３６）。
【００４８】
次に、通知先有効性確認機能部３８は、確認回数が規定回数を超えたかどうかを判断する（ステップＳ３８）。例えば、本実施形態においては、規定回数が３回に設定されている。このため、通知先有効性確認機能部３８は、ステップＳ３６でカウントアップした確認回数が、３回を越えたかどうかを判断する。
【００４９】
確認回数が３回を越えたと判断した場合（ステップＳ３８：ＹＥＳ）、つまり、確認回数が４回だった場合には、通知先有効性確認機能部３８は、通知先情報テーブル３０から、その通知先を削除する（ステップＳ４０）。すなわち、ステップＳ３０で取得した通知先アドレスと確認回数を、通知先情報テーブル３０から削除する。
【００５０】
これに対して、ステップＳ３４において、ホストコンピュータ１４から応答があった場合（ステップＳ３４：ＹＥＳ）には、通知先有効性確認機能部３８は、通知先情報テーブル３０の対応する確認回数を、ゼロにリセットする（ステップＳ４２）。
【００５１】
このステップＳ４２の後、又は、上述したステップＳ４０の後、又は、上述したステップＳ３８で確認回数が規定回数を超えていないと判断した場合（ステップＳ３８：ＮＯ）には、通知先有効性確認機能部３８は、通知先情報テーブル３０に登録されているすべての通知先の死活確認を行ったかどうかを判断する（ステップＳ４４）。例えば、図８の例では、２つの通知先が通知先情報テーブル３０に登録されているので、これら２つの通知先について、それぞれ１回ずつ死活確認を行ったかどうかを判断する。
【００５２】
通知先情報テーブル３０に登録されているすべての登録先の死活確認が完了していない場合（ステップＳ４４：ＮＯ）には、上述したステップＳ３０に戻り、通知先情報テーブル３０から次の通知先の通知先アドレスと確認回数を取得し、死活確認を行う。一方、通知先情報テーブル３０に登録されているすべての登録先の死活確認が完了した場合（ステップＳ４４：ＹＥＳ）には、この定期死活確認処理を終了する。
【００５３】
なお、図７に示した定期死活確認処理は、通知先情報テーブルに登録された通知先の格納数が通知先情報テーブルに格納できる通知先の最大数に達したときにこの処理を開始することとしてもよい。
【００５４】
以上のように、本実施形態に係るデバイスネットワークシステム１０によっても、通知先情報テーブル３０に登録されているホストコンピュータ１４に対して、定期的に死活確認処理を実行し、応答が得られないホストコンピュータ１４については、通知先情報テーブル３０から通知先アドレスを削除することとした。このため、デバイスネットワークシステム１０に有効に存在していないにも拘わらず、通知先が通知先情報テーブル３０に登録されたままとなってしまうことを回避することができる。
【００５５】
また、ステップＳ３４において、タイムアウトとなってホストコンピュータ１４の存在が確認できなかった場合、連続的に次の死活確認を行うのではなく、次の定期死活確認処理で、そのホストコンピュータ１４の死活確認を行うこととしたので、何らかの理由でホストコンピュータ１４が一時的に応答できなかったに過ぎないような場合に、その登録が通知先情報テーブル３０から削除されてしまうのを回避することができる。
【００５６】
〔第３実施形態〕
上述した第１実施形態では、通知先情報テーブル３０に登録されている通知先のホストコンピュータ１４の有効性を、定期的に確認することとしたが、本実施形態では、通知先にＳＮＭＰ Ｔｒａｐを発行する際に合わせて確認するようにしたものである。以下、上述した第１実施形態と異なる部分を説明する。
【００５７】
図９は、本実施形態に係るＴｒａｐ発行処理の内容を説明するフローチャートを示す図である。このＴｒａｐ発行処理は、上述した第１実施形態と同様に通知先有効性確認機能部３８が実行する処理であるが、本実施形態においては、このＴｒａｐ発行処理は、第１実施形態のように定期的に起動されるのではなく、ＳＮＭＰ Ｔｒａｐを発行する際に起動される処理である。
【００５８】
図９に示すように、本実施形態に係るＴｒａｐ発行処理は、ステップＳ１０〜ステップＳ２０及びステップＳ２４の処理内容は、上述した第１実施形態と同様であるが、ステップＳ１４において、死活確認に対する応答を受信した場合の処理が、第１実施形態と異なる。
【００５９】
すなわち、本実施形態においては、死活確認に対する応答を受信した場合（ステップＳ１４：ＹＥＳ）には、通知先有効性確認機能部３８は、状態通知機能部３４を介して、ステップＳ１０で取得した通知先アドレスに、ＳＮＭＰ Ｔｒａｐを発行する（ステップＳ５０）。すなわち、図１０に示すように、状態通知機能部３４を起動して、Ｐｉｎｇ応答が受信できた通知先に対して、ＳＮＭＰ Ｔｒａｐを発行する。但し、プリンタ１６で発生した状態変化の種別によっては、その状態変化を通知するような設定になっていない通知先も存在し得る。このように、発生した状態変化が、通知を求める種別の状態変化ではない通知先については、ＳＮＭＰ Ｔｒａｐは発行しない。続いて、通知先有効性確認機能部３８は、確認回数をゼロにリセットする（ステップＳ５２）。
【００６０】
このステップＳ５２の後、又は、ステップＳ２０の後、通知先有効性確認機能部３８は、上述した第１実施形態と同様に、通知先情報テーブル３０に登録されているすべての通知先の死活確認を行ったかどうかを判断し（ステップＳ２４）、すべての登録先の死活確認が完了していない場合（ステップＳ２４：ＮＯ）には、上述したステップＳ１０に戻り、通知先情報テーブル３０から次の通知先の通知先アドレスを取得し、死活確認を行う。一方、通知先情報テーブル３０に登録されているすべての登録先の死活確認が完了した場合（ステップＳ２４：ＹＥＳ）には、この定期死活確認処理を終了する。
【００６１】
以上のように、本実施形態に係るデバイスネットワークシステム１０によっても、通知先情報テーブル３０に登録されているホストコンピュータ１４に対して、定期的に死活確認処理を実行し、応答が得られないホストコンピュータ１４については、通知先情報テーブル３０から通知先アドレスを削除することとした。このため、デバイスネットワークシステム１０に有効に存在していないにも拘わらず、通知先情報テーブル３０に登録されたままとなってしまうことを回避することができる。これにより、不要な通知先を通知先情報テーブル３０から削除し、新たなホストコンピュータ１４からの登録要求があった場合に、通知先情報テーブル３０に空きが無く、登録ができないという事態が生ずるのを、極力避けることができる。
【００６２】
また、ＳＮＭＰ Ｔｒａｐを発行する際に、通知先情報テーブル３０に登録されている登録先の有効性も合わせて確認することとしたので、定期的に死活確認処理を起動するための管理が不要になる。
【００６３】
〔第１乃至第３実施形態の変形例〕
上述した第１実施形態乃至第３実施形態のデバイスネットワークシステム１０では、プリンタ１６が通知先情報テーブル３０を保持して管理することとしたが、このデバイスネットワークシステム１０にプロキシサーバを設けて、このプロキシサーバが通知先情報テーブル３０を保持して管理するようにしてもよい。
【００６４】
図１１は、デバイスネットワークシステム１０にプロキシサーバ４０を設けた場合の全体システム構成の一例を示すブロック図である。この図１１に示すように、プロキシサーバ４０は、ネットワーク１２に接続され、このネットワーク１２に関する管理を行う。本実施形態では、このプロキシサーバ４０は、Ｔｒａｐ発行の管理を行うとともに、上述したデバイス状態通知装置が組み込まれており、通知先情報テーブル３０の管理を行う。このようなデバイスネットワークシステム１０の構成であっても、上述した第１実施形態乃至第３実施形態のそれぞれ実施形態を実現することができる。
【００６５】
図１１のデバイスネットワークシステム１０に、第１実施形態を適用する場合には、プロキシサーバ４０が、図３に示した定期死活確認処理を実行する。そして、上述したステップＳ１２の死活確認を実行する際に、図１２に示すように、プロキシサーバ４０が、ステップＳ１０で取得した通知先アドレスにＰｉｎｇを発行する。この発行したＰｉｎｇに対する応答が得られるか否かで、通知先アドレスに対応するホストコンピュータ１４の存在を確認する。図１２に示すように、発行したＰｉｎｇに対する応答が得られた場合（ステップＳ１４：ＹＥＳ）には、プロキシサーバ４０は、通知先情報テーブル３０の登録をそのまま維持する。
【００６６】
一方、図１３に示すように、Ｐｉｎｇを発行しても応答が得られない場合（ステップＳ１４：ＮＯ）には、プロキシサーバ４０は、タイムアウト発生後に、規定回数まではＰｉｎｇの発行を連続的に繰り返す。本実施形態においては、規定回数は３回であるので、最初にＰｉｎｇを発行し、タイムアウトになると２回目のＰｉｎｇを発行し、さらにこれもタイムアウトになると３回目のＰｉｎｇを発行する。しかし、これもタイムアウトになると、プロキシサーバ４０は、通知先情報テーブル３０から通知先アドレスを削除するのである。
【００６７】
この図１１のデバイスネットワークシステム１０のネットワーク構成においては、プリンタ１６でＳＮＭＰ Ｔｒａｐを発行すべき状態変化が生じた場合、プリンタ１６は、そのＳＮＭＰ Ｔｒａｐをプロキシサーバ４０に対して発行する。このＳＮＭＰ Ｔｒａｐを受信したプロキシサーバ４０は、通知先情報テーブル３０を検索し、この状態変化を通知すべきホストコンピュータ１４の通知先アドレスを取得し、ＳＮＭＰ Ｔｒａｐをそれぞれの通知先に対して発行する。
【００６８】
一方、図１１のデバイスネットワークシステム１０に、第２実施形態を適用する場合には、プロキシサーバ４０が、図７に示した定期死活確認処理を実行する。すなわち、プロキシサーバ４０が、定期的に起動される定期死活確認処理において、死活確認の実行を各通知先について１回ずつ行い（ステップＳ３２）、応答が得られない場合（ステップＳ３４：ＮＯ）でも、連続して死活確認は行わない。そして、次の定期死活確認処理において、再び死活確認を行い、死活確認の確認回数が規定回数を超えるまで、通知先情報テーブル３０から削除しない（ステップＳ３８：ＮＯ）。この死活確認を繰り返し、確認回数が規定回数を超えた場合（ステップＳ３８：ＹＥＳ）には、そのホストコンピュータ１４の通知先アドレスを、通知先情報テーブル３０から削除する（ステップＳ４０）。
【００６９】
また、図１１のデバイスネットワークシステム１０に、第３実施形態を適用する場合には、プロキシサーバ４０が、図９に示したＴｒａｐ発行処理を実行する。すなわち、プロキシサーバ４０がプリンタ１６からＳＮＭＰ Ｔｒａｐを受信した場合に、図９に示すＴｒａｐ発行処理を実行する。
【００７０】
具体的には、この図９のＴｒａｐ発行処理において、プロキシサーバ４０が、ステップＳ１０で取得した通知先アドレスにＰｉｎｇを発行する（ステップＳ１２）。そして、Ｐｉｎｇ応答が得られるか否かで、通知先アドレスに対応するホストコンピュータ１４の存在を確認する。図１４に示すように、Ｐｉｎｇ応答が得られた場合（ステップＳ１４：ＹＥＳ）には、プロキシサーバ４０は、その通知先にＳＮＭＰ Ｔｒａｐを発行する（ステップＳ５０）。
【００７１】
一方、図１５に示すように、Ｐｉｎｇを発行しても応答が得られない場合（ステップＳ１４：ＮＯ）には、プロキシサーバ４０は、タイムアウト発生後に、規定回数まではＰｉｎｇの発行を連続的に繰り返す。本実施形態においては、規定回数は３回であるので、最初にＰｉｎｇを発行し、タイムアウトになると２回目のＰｉｎｇを発行し、さらにこれもタイムアウトになると３回目のＰｉｎｇを発行する。しかし、これもタイムアウトになると、プロキシサーバ４０は、通知先情報テーブル３０から通知先アドレスを削除するのである。
【００７２】
このように、プロキシサーバ４０を用いても、上述した第１実施形態乃至第３実施形態と同様の通知先情報テーブル３０の管理を、プロキシサーバ４０で実現することができる。
【００７３】
なお、本発明は上記実施形態に限定されず種々に変形可能である。例えば、上述した実施形態においては、デバイスの状態変化を監視する対象がプリンタ１６である場合を例にして、本発明を説明したが、状態変化を監視する対象のデバイスはプリンタ１６に限られるものではない。
【００７４】
また、上述した実施形態では、通知先情報テーブル３０には、４個まで通知先に関する情報が格納できる場合を例に本発明を説明したが、通知先情報テーブル３０に格納できる通知先の数は、任意に設計することができる。
【００７５】
また、上述した実施形態では、ネットワーク１２がＴＣＰ／ＩＰに準拠しており、ＳＮＭＰ Ｔｒａｐを用いて、監視対象となっているデバイスの状態変化を、ホストコンピュータ１４に通知することしたが、他の通信規格やプロトコルを用いて、この通知を実現できるようにしてもよい。
【００７６】
また、上述した実施形態では、１つのホストコンピュータ１４には、１つの管理アプリケーションが生成されることを前提に説明をしたが、１つのホストコンピュータ１４に複数の管理アプリケーションが生成されてもよい。この場合、プリンタ１６は各管理アプリケーションに対して、上述した各処理を行うこととなる。すなわち、プリンタ１６は、各アプリケーションに対して、死活確認を行ったり、ＳＮＭＰ Ｔｒａｐを発行したりすればよい。
【図面の簡単な説明】
【００７７】
【図１】本発明の適用されたデバイスネットワークシステムのネットワーク構成の一例を説明するブロック図。
【図２】本発明を適用したプリンタの内部構成の一例を示す機能ブロック図。
【図３】本発明の第１実施形態に係るプリンタで実行される定期死活確認処理の内容の一例を説明するフローチャートを示す図。
【図４】図２のプリンタが保持する通知先情報テーブルの構成の一例を示す図。
【図５】図３の定期死活確認処理において、プリンタがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プリンタとホストコンピュータとの間のやり取りの一例を示す図。
【図６】図３の定期死活確認処理において、プリンタがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られなかった場合における、プリンタとホストコンピュータとの間のやり取りの一例を示す図。
【図７】本発明の第２実施形態に係るプリンタで実行される定期死活確認処理の内容の一例を説明するフローチャートを示す図。
【図８】図２のプリンタが保持する通知先情報テーブルの構成の一例を示す図。
【図９】本発明の第３実施形態に係るプリンタで実行されるＴｒａｐ発行処理の内容の一例を説明するフローチャートを示す図。
【図１０】図９のＴｒａｐ発行処理において、プリンタがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プリンタとホストコンピュータとの間のやり取りの一例を示す図。
【図１１】図１のデバイスネットワークシステムにプロキシサーバを追加した場合のネットワーク構成の一例を説明するブロック図。
【図１２】図１１のデバイスネットワークシステムのプロキシサーバに、第１実施形態を適用した場合において、プロキシサーバがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プロキシサーバとホストコンピュータとの間のやり取りの一例を示す図。
【図１３】図１１のデバイスネットワークシステムのプロキシサーバに、第１実施形態を適用した場合において、プロキシサーバがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られなかった場合における、プロキシサーバとホストコンピュータとの間のやり取りの一例を示す図。
【図１４】図１１のデバイスネットワークシステムのプロキシサーバに、第３実施形態を適用した場合において、プロキシサーバがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プリンタとプロキシサーバとホストコンピュータとの間のやり取りの一例を示す図。
【図１５】図１１のデバイスネットワークシステムのプロキシサーバに、第３実施形態を適用した場合において、プロキシサーバがＰｉｎｇを発行し、ホストコンピュータからＰｉｎｇ応答が得られた場合における、プリンタとプロキシサーバとホストコンピュータとの間のやり取りの一例を示す図。
【符号の説明】
【００７８】
１０ デバイスネットワークシステム
１２ ネットワーク
１４（１４Ａ〜１４Ｄ） ホストコンピュータ
１６ プリンタ
２０ ネットワークインターフェース
２２ 印刷機能部
３０ 通知先情報テーブル
３２ 状態検知機能部
３４ 状態通知機能部
３６ 通知先情報テーブル管理機能部
３８ 通知先有効性確認機能部
【特許請求の範囲】
【請求項１】
ネットワークに接続されたデバイスの状態変化を、前記ネットワークに接続された通知先に、前記ネットワークを介して通知するデバイス状態通知装置であって、
前記デバイスの状態変化があった場合に、その状態変化があったことを通知する通知先が登録されている通知先情報テーブルと、
前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する通知先有効性確認手段と、
前記通知先有効性確認手段により、有効に存在することが確認できなかった通知先を、前記通知先情報テーブルから削除する、登録削除手段と、
を備えることを特徴とするデバイス状態通知装置。
【請求項２】
前記通知先有効性確認手段は、前記通知先情報テーブルに登録されている通知先に、何らかの応答を要求する応答要求を発行し、この応答要求に対する応答が得られない場合には、その通知先が有効に存在していないと判断する、ことを特徴とする請求項１に記載のデバイス状態通知装置。
【請求項３】
前記通知先有効性確認手段は、定期的に、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する、ことを特徴とする請求項１又は請求項２に記載のデバイス状態通知装置。
【請求項４】
前記通知先有効性確認手段は、デバイスに状態変化があったことを通知する際に、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する、ことを特徴とする請求項１又は請求項２に記載のデバイス状態通知装置。
【請求項５】
前記通知先有効性確認手段は、前記応答要求を発行しても通知先から応答が得られない場合、その通知先への前記応答要求を規定回数まで発行し、規定回数を超えて前記応答要求を発行しても応答が得られない通知先については有効に存在していないと判断する、ことを特徴とする請求項３又は請求項４に記載のデバイス状態通知装置。
【請求項６】
前記通知先有効性確認手段は、通知先へ前記応答要求を発行した後、所定時間が経過しても応答が得られない場合、連続して次の応答要求は発行せずに、確認回数をカウントアップし、
前記登録削除手段は、この確認回数が規定回数を超えた場合に、その通知先を前記通知先情報テーブルから削除する、
ことを特徴とする請求項３に記載のデバイス状態通知装置。
【請求項７】
前記デバイス状態通知装置は、前記状態変化が監視される前記デイバスに設けられている、ことを特徴とする請求項１乃至請求項６のいずれかに記載のデバイス状態通知装置。
【請求項８】
前記デバイス状態通知装置はプロキシサーバであり、前記ネットワークを介して、前記状態変化が監視される前記デバイスに接続される、ことを特徴とする請求項１乃至請求項６のいずれかに記載のデバイス状態通知装置。
【請求項１】
ネットワークに接続されたデバイスの状態変化を、前記ネットワークに接続された通知先に、前記ネットワークを介して通知するデバイス状態通知装置であって、
前記デバイスの状態変化があった場合に、その状態変化があったことを通知する通知先が登録されている通知先情報テーブルと、
前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する通知先有効性確認手段と、
前記通知先有効性確認手段により、有効に存在することが確認できなかった通知先を、前記通知先情報テーブルから削除する、登録削除手段と、
を備えることを特徴とするデバイス状態通知装置。
【請求項２】
前記通知先有効性確認手段は、前記通知先情報テーブルに登録されている通知先に、何らかの応答を要求する応答要求を発行し、この応答要求に対する応答が得られない場合には、その通知先が有効に存在していないと判断する、ことを特徴とする請求項１に記載のデバイス状態通知装置。
【請求項３】
前記通知先有効性確認手段は、定期的に、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する、ことを特徴とする請求項１又は請求項２に記載のデバイス状態通知装置。
【請求項４】
前記通知先有効性確認手段は、デバイスに状態変化があったことを通知する際に、前記通知先情報テーブルに登録されている通知先が有効に存在するか否かを確認する、ことを特徴とする請求項１又は請求項２に記載のデバイス状態通知装置。
【請求項５】
前記通知先有効性確認手段は、前記応答要求を発行しても通知先から応答が得られない場合、その通知先への前記応答要求を規定回数まで発行し、規定回数を超えて前記応答要求を発行しても応答が得られない通知先については有効に存在していないと判断する、ことを特徴とする請求項３又は請求項４に記載のデバイス状態通知装置。
【請求項６】
前記通知先有効性確認手段は、通知先へ前記応答要求を発行した後、所定時間が経過しても応答が得られない場合、連続して次の応答要求は発行せずに、確認回数をカウントアップし、
前記登録削除手段は、この確認回数が規定回数を超えた場合に、その通知先を前記通知先情報テーブルから削除する、
ことを特徴とする請求項３に記載のデバイス状態通知装置。
【請求項７】
前記デバイス状態通知装置は、前記状態変化が監視される前記デイバスに設けられている、ことを特徴とする請求項１乃至請求項６のいずれかに記載のデバイス状態通知装置。
【請求項８】
前記デバイス状態通知装置はプロキシサーバであり、前記ネットワークを介して、前記状態変化が監視される前記デバイスに接続される、ことを特徴とする請求項１乃至請求項６のいずれかに記載のデバイス状態通知装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１０−１０２６１２（Ｐ２０１０−１０２６１２Ａ）
【公開日】平成２２年５月６日（２０１０．５．６）
【国際特許分類】
【出願番号】特願２００８−２７５２２８（Ｐ２００８−２７５２２８）
【出願日】平成２０年１０月２７日（２００８．１０．２７）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【Ｆターム（参考）】
【公開日】平成２２年５月６日（２０１０．５．６）
【国際特許分類】
【出願日】平成２０年１０月２７日（２００８．１０．２７）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【Ｆターム（参考）】
[ Back to top ]