(57)【要約】【課題】  サーバとの通信テスト前に、シリアル番号や、MACアドレスのキーを事前にサーバに登録せずに、デバイス設置時を経た任意の期間において、再び設置へ行くことなくサーバへの契約登録を済ませることを可能にする。【解決手段】  契約する／しないの判断を後日行い、ネットワークメンテナンス対象外と判断したシリアル番号をサーバに登録する。サーバは、カウンタ送信やアラート送信等のいずれかのパケットのレスポンスで、サーバから指示確認パケットの要求を出し、次に指示確認パケットのレスポンスでパケットごとのunavailableを発行して、デバイスによるカウンタ送信などを中断させる。【選択図】  図９
2006031344.tif 000002
【特許請求の範囲】
【請求項１】
種々のネットワークデバイスと種々のコンピュータが接続されたインターネットにおいて、デバイスは、デバイス固有の識別子を付加してサーバに対してデバイス情報を送信する手段と、サーバがあるデバイスと通信すべきか否かを、前記識別子により判断する手段と、サーバが通信すべきでないデバイスからのデバイス情報送信を確認した場合、前記要求の応答においてオペレーション指示要求を行う手段と、
前記オペレーション指示がある場合には、デバイスは、直ちにサーバへオペレーション指示要求を実行する手段と、
前記通信すべきでないデバイスからオペレーション指示要求を受信した際に、デバイス情報の送信を不可とするよう、サーバが指示変更する手段を有することを特徴とするネットワークシステム。
【請求項２】
上記請求項１のネットワーク通知方式であって、請求項１の指示変更の際に、デバイスが送信するオペレーション指示要求のみ、サーバが送信を可能とし、それ以外のデバイス情報送信は、不可とすることを特徴とするネットワークシステム。
【請求項３】
上記請求項２のネットワーク通知方式であって、オペレーション指示要求をデバイスが定期的にサーバに送信する手段と、サーバが前記要求の応答において、デバイス情報送信を可能とする手段を有することを特徴とするネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク環境に接続されるMFP（Multi Function Peripheral）などのネットワークデバイス装置に関する。
【背景技術】
【０００２】
近年、Web技術であるSOAP/XMLを利用して、インターネット上で、カウンタ情報収集やエラー情報収集をホストサーバに集約し、デバイスを管理するシステムが開発されつつある。こうしたシステムを用いて、デバイスを管理するニーズは、高まりつつあり、今後、ますます普及することが予想される。
【特許文献１】特開2004-40630号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、こうした通信に関しては、通常、メンテナンス契約となり、その際には、サーバとの通信テスト前に、シリアル番号や、MACアドレスのキーを事前にサーバに登録しておく必要があった。従って、デバイス設置時に必ずサーバへの契約登録を済ませる必要があったが、それが困難だった。
【課題を解決するための手段】
【０００４】
デバイス設置時に、通信をカウンタ送信、アラート送信、指示確認のそれぞれのパケット送信を開始する。契約する／しないの判断を後日行い、ネットワークメンテナンス対象外と判断したシリアル番号をサーバに登録する。カウンタ送信やアラート送信等のいずれかのパケットのレスポンスで、サーバから指示確認パケットの要求を出し、次に指示確認パケットのレスポンスで、パケットごとのunavailableを発行して送信を中断する。なお、指示確認パケットに関しては、ネットワークメンテナンス対象外と判断した後も、availableを発行しておき、後ほど、契約が成立した時点で、指示確認要求のレスポンスで、パケットごとのavailableを発行することにより、再度、カウンタ送信等を行う。
【発明の効果】
【０００５】
デバイス設置時に、通信をカウンタ送信、アラート送信、指示確認のそれぞれのパケット送信を開始する。契約する／しないの判断を後日行い、ネットワークメンテナンス対象外と判断したシリアル番号をサーバに登録する。カウンタ送信やアラート送信等のいずれかのパケットのレスポンスで、サーバから指示確認パケットの要求を出し、次に指示確認パケットのレスポンスで、パケットごとのunavailableを発行して送信を中断する。なお、指示確認パケットに関しては、ネットワークメンテナンス対象外と判断した後も、availableを発行しておき、後ほど、契約が成立した時点で、指示確認要求のレスポンスで、パケットごとのavailableを発行することにより、再度、カウンタ送信等を行う。
【０００６】
上記手段により、サーバとの通信テスト前に、シリアル番号や、MACアドレスのキーを事前にサーバに登録せずに、デバイス設置時を経た任意の期間において、再び設置へ行くことなくサーバへの契約登録を済ませることが可能となる。
【発明を実施するための最良の形態】
【０００７】
（実施例１）
以下、図面を参照にして本発明の実施の形態を説明する。
【０００８】
図１は、本発明の一実施形態に係わるネットワークシステムの全体構成を示す図である。１−１は、デバイス装置であり、インターネットを経由して、１−７のホストサーバ装置に、カウンタ情報やエラー情報等のデバイス情報を定期、または不定期に送信するものである。１−２は、PCであり、１−４のイントラネットLANに接続されている。ネットワークを通じて、１−１のデバイス装置と通信することが可能であり、印刷ジョブを１−１のデバイス装置に送出することにより、ネットワーク印刷を行うことができる。１−３はゲートウェイ装置であり、１−５、１−６のインターネットへ接続するためのファイアーウォールの役目を果たす。１−８は、１−４と同様のイントラネットLANであり、ホストサーバ装置のあるLANである。
【０００９】
なお、PC、印刷デバイス装置は、同図に示す台数と異なる台数が接続されていもよい。
【００１０】
図２は、本発明の一実施形態に係わるネットワークデバイス装置の内部構成を示した図である。本内部構成では、１ＣＰＵにおいてネットワーク制御部とデバイス（プリンタ）制御部が動作する形態で実現されている。この印刷デバイス装置は、２−３に格納されているプログラムを実行するＣＰＵ２−１を備え、システムバス２−１１に接続される各デバイスを総括的に制御する。また、２−２はＲＡＭで、ＣＰＵ２−１の主メモリ、ワークエリア等として機能する。このＲＡＭにホストサーバ通知先アドレスやカウンタ情報の更新間隔、印刷ジョブ情報やジョブを保存する。そして、ホストサーバ通知先アドレスやカウンタ情報の更新間隔等のシステム情報を保存するバックアップＲＡＭも構成される。２−４は、キーボードコントローラ（ＫＢＣ）で、２−８のキーボード（ＫＢ）からの指示入力を制御する。２−５は、ＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）２−９の表示を制御する。２−８のキーボードおよび２−９のＣＲＴディスプレイを用いてユーザは、アプリケーション情報、タイマを編集することができる。２−６は、デバイスコントローラ（ＤＶＣ）で、２−１０のプリンタ（ＤＶ）などを制御する。２−７はネットワークインタフェースカード（ＮＩＣ）で、ＬＡＮ２−１２を介して、他のネットワーク機器あるいは他のＰＣと双方向にデータをやりとりする。
【００１１】
また、本実施例においては、ＬＡＮ２−１２は図１におけるＬＡＮ１−４、１−８と同じものである。
【００１２】
なお、ホストサーバ通知先アドレスやカウンタ情報の更新間隔、印刷ジョブ情報やジョブは、ハードディスク等のその他の記憶装置に保存してもよい。また、液晶パネルのタッチパネル等を用いて、仮想キーボードとし、キーボードの代わりとしても良い。
【００１３】
図３は、本発明の一実施形態に係わるネットワークホストサーバ装置の内部構成を示した図である。本内部構成では、１ＣＰＵにおいてネットワーク制御部とデバイス（プリンタ）制御部が動作する形態で実現されている。この印刷デバイス装置は、３−３に格納されているプログラムを実行するＣＰＵ３−１を備え、システムバス３−１１に接続される各デバイスを総括的に制御する。また、３−２はＲＡＭで、ＣＰＵ３−１の主メモリ、ワークエリア等として機能する。このＲＡＭにデバイスごとの管理情報を保存する。そして、システム情報はバックアップＲＡＭにも構成される。３−４は、キーボードコントローラ（ＫＢＣ）で、３−８のキーボード（ＫＢ）からの指示入力を制御する。３−５は、ＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）３−９の表示を制御する。３−８のキーボードおよび３−９のＣＲＴディスプレイを用いてユーザは、各デバイスに対する指示を要求することができる。３−６は、IOコントローラ（IOC）で、３−１０のシリアルやパラレルなどを制御する。３−７はネットワークインタフェースカード（ＮＩＣ）で、ＬＡＮ３−１２を介して、他のネットワーク機器あるいは他のＰＣと双方向にデータをやりとりする。
【００１４】
また、本実施例においては、ＬＡＮ３−１２は図１におけるＬＡＮ１−４、ＬＡＮ１−８、ＬＡＮ２−１２、と同じものである。
【００１５】
なお、デバイスごとの管理情報や指示情報は、ハードディスク等のその他の記憶装置に保存してもよい。また、液晶パネルのタッチパネル等を用いて、仮想キーボードとし、キーボードの代わりとしても良い。
【００１６】
図４は、本実施例におけるホストサーバにおけるデバイスごとの制御情報の一例である。４−１は、デバイスごとの分類であり、本例のテーブルでは、シリアル番号11111111と22222222のデバイスを管理している。４−２の更新項目とは、デバイスのパケットごとに更新させたい項目をテーブル情報として、記述するものである。ここでは、エラーチェック：id=1、課金カウンタ取得：id=2、ROMオペレーション：id=3オペレーション指示：id=4のパケットを指示可能である。４−３の制御情報は、デバイスごとに通信を行うか否かを決定するために、unavailableまたは、availableを登録する。契約してないことが明確になった時点で、該当のデバイスをunavailableにすることで、サーバは、デバイスに対して、送信不可（停止）要求を送出することができるようになる。
【００１７】
なお、更新項目は、本例の４つに言及されるものでもないし、また、制御情報も使用不可にするか可能にするかの識別子であれば、本例に言及されるものではない。
【００１８】
図５は、本実施例におけるHTTP上のSOAPを用いてクライアントから印刷装置に送信されるpsotAlertと称されるパケットデータの一例である。このデータはXML形式で記述されている。postAlertパケットは、デバイスにエラーが発生した際に、ホストサーバにエラー情報を通知するコマンドであり、クライアント情報（<client>タグ）やアラート情報リスト（<alertList>タグ）等の情報が記述されている。<client>タグには、クライアントを識別する<id>、クライアントのタイプを識別する<type>、アプリケーションのバージョンを識別する<appVersion>が含まれる。また、alertListには、デバイスを識別する<device>と<alert>のリスト、カウンター情報<counterList>が構成され、<device>には、MACアドレスの下位４バイトを識別する<mac>、IPアドレスを識別する<ip>、シリアル番号<serialNumber>、製品名<produceName>、形式<type>が記述され、<alert>には、エラーコード<code>、大分類の<majorstatus>、エラーを示す文字情報<opmessage>、タイムスタンプ情報<timestamp>が記述され、<counterList>には、サービスモード番号<id>とサービスモード番号で指定されたカウンタ値<value>が記述されている。
【００１９】
図６は、図５のpostAlertパケットに対する応答パケットデータの一例である。本データも図５と同様にXML形式で記述され、本実施例においてはHTTP上のSOAPを用いて送受信される。postAlert応答パケットには、postAlertコマンド対する結果情報<return>として、結果コード(<result>タグ)やデバイスへの指示要求<nextOperation>、タイムスタンプ情報<timeStamp>、詳細をあらわす<detail>がある。また、nextOperationは、NULLで記述すれば、ホストサーバからのオペレーション支持がないことを示す。
【００２０】
なお、ここでは、<nextOparation>でgetOparationListを要求したが、その他のコマンド（カウンタ情報の要求等を示すpostServiceModeCounter等）の要求を入れても良い。
【００２１】
図７は、図６のgetOparationListを要求した場合の要求パケットデータの一例である。本データも図５と同様にXML形式で記述され、本実施例においてはHTTP上のSOAPを用いて送受信される。getOparatinList要求パケットには、クライアント情報（<client>タグ）において、<client>タグには、クライアントを識別する<id>、クライアントのタイプを識別する<type>、アプリケーションのバージョンを識別する<appVersion>が含まれる。
【００２２】
なお、getOparationListを意味するのパケットであれば、このタグの構成には限定されない。
【００２３】
図８は、図５のgetOparationListパケットに対する通信不可／可応答パケットデータの一例である。本データも図５と同様にXML形式で記述され、本実施例においてはHTTP上のSOAPを用いて送受信される。getOparationList応答パケットには、getOparationListコマンド対する結果情報として、ホストサーバの<address>、スケジュール情報のリスト<scheduleList>で構成される。<scheduleLsit>は、スケジュール情報<schedule>で構成され、開始時刻<startReference>、更新識別情報<id>は、図４の例と同様の形式をとり（エラーチェック:id=1、課金カウンタ取得:id=2、ROMバージョン取得:id=3、オペレーション指示:id=4）、制御情報<available>（0:不可、1:可）が指定されている。つまり、この場合、オペレーション指示のみ許可する形式となる。
【００２４】
なお、このgetOparationListの応答パケットは、<address>と<scheduleList>で構成されているがそれに言及されるものではない。また、スキーマは、サーバからの制御を指示する主旨のスキーマであれば、特に特に本例に言及されるものではない。
【００２５】
図９は、ホストサーバ装置からの通信不可／可指示をデバイス装置に通知するためのシーケンスを示すフローチャートである。
【００２６】
以下、図９を用いて、本実施例のホストサーバ装置の動作を説明する。
【００２７】
デバイス装置から例えば、図５に示すようなpostAlertパケットがホストサーバに送信されると、ホストサーバ装置において、コマンドを受信（Ｓ９−１）し、図４に示したようなデバイスごとの制御テーブルを参照し、制御すべき項目があるか判断（Ｓ９−２）する。Ｓ９−３において、通信不可（unavailable）に制御すべきデバイスかどうか判定する。通信不可にすべきデバイスであれば、Ｓ９−４へ進み、そうでなければ、Ｓ９−１０へ進む。Ｓ９−４において、図６に示すようにgetOparationListをXMLデータに付加する。Ｓ９−５では、postAlertResponceを送信する。Ｓ９−６では、getOparationListコマンドを受信する。Ｓ９−７で、再度、Ｓ９−２のテーブルを参照し、通信不可（unavailable）に制御すべきデバイスかどうか判断する。Ｓ９−８において、あるかどうか判断し、通信不可にすべきであれば、Ｓ９−９へ進み、そうでなければ、Ｓ９−１１へ進む。Ｓ９−９では、getOparationListResponceを送信し、Ｓ９−１１に進む。
【００２８】
Ｓ９−１０では、通常のレスポンスデータを作成する。また、Ｓ９−１１で終了する。
【００２９】
なお、サーバは、postAlertに限定せず、デバイスから送信されるあらゆるパケットに対して、オペレーション指示ができる。また、指示のunavailable／availableの通信上での表現は、特にこれらに言及されるものではない。
【００３０】
図１０は、デバイス装置おいてホストサーバ装置からの通信不可／可要求を処理するためのシーケンスを示フローチャートである。
【００３１】
以下、図１０を用いて本実施例のデバイス装置の動作を説明する。
【００３２】
デバイス装置で、デバイス装置内で障害が発生したかどうかを監視する（Ｓ１０−１）。
【００３３】
Ｓ１０−２において、障害が発生したかどうかを判定し、あれば、Ｓ１０−３へ進み、なければ、Ｓ１０−１に戻る。Ｓ１０−３において、postAlertを送信する。Ｓ１０−４において、ホストサーバからpostAlertResponceを受信し、そして、そのXMLデータ内部にgetOparationListが含まれているかどうかを確認する。Ｓ１０−５において、getOparationListが含まれているかどうかを判定し、あれば、Ｓ１０−６へ進み、なければ、Ｓ１０−１０へ進む。Ｓ１０−６では、getOparationListを送信し、Ｓ１０−７へ進む。Ｓ１０−７では、getOparationListResponceを受信し、Ｓ１０−８へ進む。Ｓ１０−８において、getOparationListResponceにホストからの通信不可（unavailable）および可（available）の要求があるかどうかを判定し、あれば、Ｓ１０−９へ進み、なければＳ１０−１０へ進む。Ｓ１０−９では、ホストサーバからの要求の指示に従い、おのおの通信を不可とさせるか、可とさせるかを決定する。そして、通信不可とするデータは次回以降通信しない。Ｓ１０−１０で終了する。
【００３４】
なお、Ｓ１０−１で障害のみが発生する不定期のホストサーバへ送信の場合の適用例を示したが、電源ON時やオペレータ指示により行う通信テスト、定期間隔で送信するカウンタ送信等のすべてのレスポンスで本提案を実現することができる。また、指示のunavailable／availableの通信上での表現は、特にこれらに言及されるものではない。
【００３５】
図１１は、デバイス装置おいてホストサーバ装置からの通信可要求で再開を処理するためのシーケンスを示フローチャートである。Ｓ１１−１では、getOparationListを送信し、Ｓ１１−２へ進む。また、この時のgetOparationListは、定期的（１時間）にサーバに送信される。Ｓ１１−２では、getOparationListResponceを受信し、Ｓ１１−３へ進む。Ｓ１１−４において、getOparationListResponceにホストからの通信可（available）の要求があるかどうかを判定し、あれば、Ｓ１１−４へ進み、なければＳ１１−５へ進む。Ｓ１１−４では、ホストサーバからの要求の指示に従い、おのおの通信を可とさせるかを決定する。そして、通信可とするデータは次回以降通信する。Ｓ１１−５で終了する。
【図面の簡単な説明】
【００３６】
【図１】発明の一実施形態に係わるネットワークシステムの全体構成を示す図。
【図２】本発明の一実施形態に係わるネットワークデバイス装置の内部構成を示した図。
【図３】本発明の一実施形態に係わるネットワークホストサーバ装置の内部構成を示した図。
【図４】本実施例におけるホストサーバにおけるデバイスごとの制御情報の一例。
【図５】本実施例におけるHTTP上のSOAPを用いてクライアントから印刷装置に送信されるCreateJobと称されるパケットデータの一例。
【図６】図５のpostAlertパケットに対する応答パケットデータの一例。
【図７】図６のgetOparationListを要求した場合の要求パケットデータの一例。
【図８】図５のgetOparationListパケットに対する通信不可／可つき応答パケットデータの一例。
【図９】ホストサーバ装置からの通信不可／可指示をデバイス装置に通知するためのシーケンスを示すフローチャート。
【図１０】デバイス装置おいてホストサーバ装置からの通信不可／可要求を処理するためのシーケンスを示フローチャート。
【図１１】デバイス装置おいてホストサーバ装置からの通信可要求で再開を処理するためのシーケンスを示フローチャート。
【符号の説明】
【００３７】
１−１  デバイス装置
２―７、３−７  ネットワーク通信制御部
１−４、１−８、２−１２、３−１２  ネットワーク
【図１】
2006031344.tif 000003
【図２】
2006031344.tif 000004
【図３】
2006031344.tif 000005
【図４】
2006031344.tif 000006
【図５】
2006031344.tif 000007
【図６】
2006031344.tif 000008
【図７】
2006031344.tif 000009
【図８】
2006031344.tif 000010
【図９】
2006031344.tif 000011
【図１０】
2006031344.tif 000012
【図１１】
2006031344.tif 000013