JP2019106152A - コンピュータプログラム、および、通信装置 - Google Patents

Abstract

【課題】機能実行装置の状態を示す情報を管理装置に送信するタイミングに適したタイミングで、機能実行装置の状態を示す情報を機能実行装置から受信する。【解決手段】コンピュータプログラムは、状態情報の要求である第１の管理要求を第１種の通信インタフェースを介して管理装置から受信する機能と、第１の管理要求を受信した後に第２の管理要求を管理装置から受信する機能と、状態情報を問い合わせるための要求を第２種の通信インタフェースを介して機能実行装置に送信する送信タイミングを第１の管理要求の受信のタイミングと第２の管理要求の受信のタイミングとの間の期間を利用して決定する機能と、決定された送信タイミングに従って第２種の通信インタフェースを介して第１の状態要求が機能実行装置に送信されることに応じて第１の状態情報を含む情報を機能実行装置から受信する機能とをコンピュータに実現させる。【選択図】 図１

Description

本明細書は、周辺装置と管理装置とに接続される通信装置、および、通信装置のコンピュータによって実行されるコンピュータプログラムに関する。

特許文献１では、マネージャ機能を有するデータ処理装置と、エージェント機能を有するデータ処理装置と、エージェント機能を有するデータ処理装置にローカル接続されるプリンタと、を含むシステムが提案されている。エージェント機能を有するデータ処理装置は、マネージャ機能を有するデータ処理装置からのリクエストを取得し、リクエストに適した情報をプリンタから取得する。エージェント機能を有するデータ処理装置は、リクエストに対する応答として、マネージャ機能を有するデータ処理装置に取得した情報を送信する。

特開２０００−２９３３２４号公報

通信装置は、互いに異なる通信インタフェースを介して、管理装置と機能実行装置（例えば、プリンタ）とに接続され得る。通信装置は、一の通信インタフェースを介して、機能実行装置の状態を表す情報を機能実行装置から受信する。また、通信装置は、他の通信インタフェースを介して、機能実行装置の状態を表す情報を管理装置に送信する。ここで、機能実行装置の状態を表す情報を機能実行装置から受信するタイミングと、機能実行装置の状態を表す情報を管理装置に送信するタイミングと、の関係については、改善の余地があった。

本明細書は、機能実行装置の状態を示す情報を管理装置に送信するタイミングに適したタイミングで、機能実行装置の状態を示す情報を機能実行装置から受信できる技術を開示する。

本明細書は、例えば、以下の適用例を開示する。

［適用例１］第１種の通信インタフェースと、第２種の通信インタフェースと、を備える通信装置のコンピュータのためのコンピュータプログラムであって、前記第１種の通信インタフェースを介して、機能実行装置の状態を示す第１の状態情報の要求である第１の管理要求を管理装置から受信する第１の要求受信機能であって、前記機能実行装置は前記第２種の通信インタフェースを介して前記通信装置と接続される、前記第１の要求受信機能と、前記管理装置から前記第１の管理要求を受信した後に、前記第１種の通信インタフェースを介して、前記第１の状態情報の新たな要求である第２の管理要求を前記管理装置から受信する第２の要求受信機能と、前記第２種の通信インタフェースを介して前記第１の状態情報を問い合わせるための第１の状態要求を前記機能実行装置に送信する送信タイミングを、前記第１の管理要求の受信のタイミングと前記第２の管理要求の受信のタイミングとの間の第１の期間を利用して決定する決定機能と、前記決定された送信タイミングに従って前記第２種の通信インタフェースを介して前記第１の状態要求が前記機能実行装置に送信されることに応じて、前記第１の状態情報を含む情報を前記機能実行装置から受信する第１の状態受信機能と、を前記コンピュータに実現させる、コンピュータプログラム。

この構成によれば、通信装置が互いに異なる通信インタフェースを介して管理装置と機能実行装置とに接続されている場合に、管理装置からの要求の受信のタイミングに適したタイミングで機能実行装置から状態情報を受信できる。

なお、本明細書に開示の技術は、種々の態様で実現することが可能であり、例えば、通信方法および通信装置、それらの方法または装置の機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体（例えば、一時的ではない記録媒体）、等の形態で実現することができる。

システム１０００の構成を示すブロック図である。 システム１０００の動作を示す概略図である。 応答処理の例を示すフローチャートである。 テーブルＴ１、Ｔ２、Ｔ３とパケットの説明図である。 タイマ処理の例を示すフローチャートである。 応答処理の別の実施例を示すフローチャートである。 タイマ処理の別の実施例を示すフローチャートである。

Ａ．第１実施例：
Ａ−１：システム１０００の構成
図１は、本実施例のシステム１０００の構成を示すブロック図である。システム１０００は、通信装置の例である端末装置１００と、機能実行装置の例であるプリンタ２００と、管理装置の例である管理サーバ３００、３２０と、を備える。端末装置１００と、管理サーバ３００、３２０とは、ローカルエリアネットワークＮＴに接続されている。これらの装置（１００、３００、３２０）は、ローカルエリアネットワークＮＴを介して、互いに通信可能である。プリンタ２００は、ＵＳＢケーブルを介して端末装置１００と接続可能である。

端末装置１００は、端末装置１００のコントローラとしてのＣＰＵ１１０と、記憶装置１１５と、画像を表示する液晶ディスプレイなどの表示部１４０と、ユーザによる操作を取得するためのキーボードやマウスなどの操作部１５０と、タイマ１６０と、ＵＳＢインタフェース（ＩＦ）１７０と、ネットワークインタフェース（ＩＦ）１８０と、を備えている。記憶装置１１５は、ＤＲＡＭなどの揮発性記憶装置１２０と、ハードディスクやフラッシュメモリなどの不揮発性記憶装置１３０と、を含んでいる。タイマ１６０は、現在日時を測定する装置である。ＣＰＵ１１０は、タイマ１６０からの情報を用いることによって、現在日時を特定できる。

ＵＳＢＩＦ１７０は、シリアルバス規格の一つであるＵＳＢ（Universal Serial Bus）規格に従ったデータ通信を行うためのインタフェースである。端末装置１００は、ＵＳＢインタフェース１７０とプリンタ２００とがＵＳＢケーブルを介して接続された状態で、ＵＳＢＩＦ１７０を介して、プリンタ２００と通信可能である。

ネットワークＩＦ１８０は、ローカルエリアネットワークＮＴに接続されている。ネットワークＩＦ１８０は、ＯＳＩ参照モデルのネットワーク層のプロトコルとしてＩＰ（Internet Protocol）を用いる通信規格に従ってデータ通信を行うためのインタフェースである。具体的には、ネットワークＩＦ１８０は、イーサネット（登録商標）に準拠した有線のインタフェースや、Ｗｉ−Ｆｉ規格（ＩＥＥＥ（The Institute of Electrical and Electronics Engineers, Inc.の略）の８０２．１１の規格又はそれに準ずる規格（例えば、８０２．１１ａ，１１ｂ，１１ｇ，１１ｎ等）に従った規格）に準拠した無線のインタフェースである。

ＣＰＵ１１０は、データ処理を行う演算装置（プロセッサ）である。記憶装置１１５（揮発性記憶装置１２０と不揮発性記憶装置１３０との少なくとも一方）は、ＣＰＵ１１０が処理を行う際に生成される種々の中間データを一時的に格納するバッファ領域を提供する。本実施例では、不揮発性記憶装置１３０は、コンピュータプログラムＰＧと、状態テーブルＴ１と、定期テーブルＴ２と、要求テーブルＴ３と、を格納している。

コンピュータプログラムＰＧは、例えば、プリンタ２００のベンダによって運営されるサーバ（図示省略）からダウンロードされる形態で提供されるアプリケーションプログラムである。これに代えて、コンピュータプログラムＰＧは、ＣＤ−ＲＯＭなどに記録された形態で提供されても良く、端末装置１００の製造時に不揮発性記憶装置１３０に予め格納されて提供されても良い。

状態テーブルＴ１は、プリンタ２００の状態情報を格納するテーブルである。定期テーブルＴ２は、状態テーブルＴ１の定期的な更新日時を規定するテーブルである。要求テーブルＴ３は、管理サーバ３００、３２０から送信されるＳＮＭＰ要求の受信履歴を格納するテーブルである（履歴テーブルＴ３とも呼ぶ）。これらのテーブルＴ１、Ｔ２、Ｔ３の詳細については、後述する。

ＣＰＵ１１０は、コンピュータプログラムＰＧを実行することによって、後述する応答処理と、タイマ処理と、を実行する。これによって、端末装置１００は、ＵＳＢＩＦ１７０に接続されたプリンタ２００の状態情報をプリンタ２００から受信し、受信した状態情報を管理サーバ３００、３２０に送信する。

プリンタ２００は、上述したように、ＵＳＢケーブルを介して端末装置１００と接続されるローカルプリンタである。プリンタ２００は、印刷実行部２４０と、情報データベース（ＤＢ）２５０と、を備えている。

印刷実行部２４０は、例えば、端末装置１００から受信される印刷ジョブに従って、印刷処理を実行する。印刷処理は、所定の方式（例えば、レーザ方式や、インクジェット方式）に従って、色材（例えば、トナーやインク）を用いて、用紙（印刷媒体の一例）上に画像を印刷する処理である。

情報ＤＢ２５０は、プリンタ２００に関する装置情報が格納されたデータベースである。プリンタ２００に関する装置情報は、シリアル番号を示す情報と、モデル名を示す情報と、プリンタ２００の状態（ステータス）を示す状態情報と、を含む。状態情報は、複数個の項目を含む。複数個の項目は、例えば、印刷実行部２４０における消耗品の残量を示す情報と、消耗品の交換回数を示す情報と、印刷枚数を示す情報と、印刷実行部２４０におけるエラーに関する情報と、を含む。消耗品の残量は、例えば、トナーやインクなどの色材の残量、印刷実行部２４０の用紙トレイの用紙の残量（残りの枚数）を含む。消耗品の交換回数は、例えば、トナーカートリッジやインクカートリッジなどの色材の容器の交換回数を含む。印刷枚数は、例えば、印刷実行部２４０の累積印刷枚数や、用紙のサイズごとの印刷枚数を含む。エラーに関する情報は、例えば、エラーの有無（正常か否かか）を示す情報や、発生しているエラーの種類を示す情報を含む。

第１管理サーバ３００は、図示しないＣＰＵとメモリとを備える計算機である（以下、単に管理サーバ３００とも呼ぶ）。管理サーバ３００は、ローカルエリアネットワークＮＴを介して、システム１０００内のプリンタ、すなわち、プリンタ２００の状態情報を収集する。状態情報の収集には、本実施例では、ＳＮＭＰ（Simple Network Management Protocol）が用いられる。管理サーバ３００は、収集された状態情報を、例えば、システム１０００を管理する事業者のサーバ（図示省略）に対して、インターネットを介して送信する。事業者は、たとえば、管理サーバ３００から送信された状態情報に基づいて、システム１０００内のプリンタの印刷枚数や、色材などの消耗品の残量を把握し、例えば、印刷枚数に応じた課金や色材の供給を行う。第２管理サーバ３２０の構成は、第１管理サーバ３００の構成と、同じである。

図２は、システム１０００の動作を示す概略図である。図中には、端末装置１００と、プリンタ２００と、管理サーバ３００とが、示されている。管理サーバ３００は、ＳＮＭＰマネージャとしての機能を備えている。管理サーバ３００は、プリンタ２００の状態情報を、定期的、例えば、１日あたり１〜数回の頻度で、収集する。本実施例では、プリンタ２００はローカルエリアネットワークＮＴ（図１）に接続されず、端末装置１００に接続されている。管理サーバ３００は、プリンタ２００ではなく端末装置１００に、ＳＮＭＰ要求を送信する。本実施例では、管理サーバ３００は、ＳＮＭＰのＧｅｔＲｅｑｕｅｓｔのパケットを、端末装置１００に送信する。図中の文字「Ｓ」と数字との組み合わせによって示される符号は、後述する図３、図５のフローチャートの対応するステップの符号を、示している。

図２中には、端末装置１００の機能を示すブロック図が示されている。端末装置１００（図１）のＣＰＵ１１０は、ＳＮＭＰ要求応答部Ｂ１００と、要求分析部Ｂ１２０と、スケジュールタイマＢ１３０と、情報収集部Ｂ１４０と、印刷スプーラＢ１５０と、のそれぞれとして、動作する。

情報収集部Ｂ１４０は、プリンタ２００に状態情報の要求を送信するための処理を実行する。状態情報の要求には、例えば、ＰＪＬ（Printer Job Language）を用いて記述されたコマンドが用いられる。情報収集部Ｂ１４０は、コマンドを含む印刷ジョブ（収集ジョブとも呼ぶ）を、印刷スプーラＢ１５０に供給する。印刷スプーラＢ１５０は、通常の印刷ジョブと同様に、収集ジョブをプリンタ２００に送信する。プリンタ２００は、受信した収集ジョブに含まれるコマンドを解析し、要求された情報（ここでは、値）を端末装置１００へ送信する。情報収集部Ｂ１４０は、取得した情報を、状態テーブルＴ１に格納する。

端末装置１００は、ＳＮＭＰエージェントとしての機能を備えている。端末装置１００の要求応答部Ｂ１００は、管理サーバ３００からのＳＮＭＰ要求に応じて、要求された情報を状態テーブルＴ１から取得し、取得した情報を端末装置１００へ送信する。

要求分析部Ｂ１２０は、ＳＮＭＰ要求を受信した日時を特定し、繰り返されるＳＮＭＰ要求の受信のタイミングの期間差を算出する。要求分析部Ｂ１２０は、期間差を用いて、状態情報の要求をプリンタ２００に送信する送信タイミングを決定する。送信タイミングは、管理サーバ３００から新たなＳＮＭＰ要求を受信する時に、新しい状態情報がプリンタ２００から取得済であるように、決定される（詳細は、後述）。

スケジュールタイマＢ１３０は、決定された送信タイミングに従って、情報収集部Ｂ１４０が収集ジョブを送信するための処理を実行する。

このように、端末装置１００のＣＰＵ１１０は、管理サーバ３００からのＳＮＭＰ要求を受信するタイミングの期間差を利用して、プリンタ２００へ収集ジョブを送信する送信タイミングを決定する。従って、端末装置１００は、管理サーバ３００からのＳＮＭＰ要求の受信タイミングに適したタイミングで、プリンタ２００から状態情報を受信できる。端末装置１００が第２管理サーバ３２０からＳＮＭＰ要求を受信する場合も、同様に、端末装置１００は、第２管理サーバ３２０からのＳＮＭＰ要求の受信タイミングに適したタイミングで、プリンタ２００から状態情報を受信する。詳細については後述するが、プリンタ２００に収集ジョブを送信すべき送信タイミングは、管理装置毎に、設定される。以下、端末装置１００の処理の詳細について、説明する。

図３は、応答処理の例を示すフローチャートである。端末装置１００（図１）は、ＳＮＭＰエージェントとして機能し、管理サーバ（例えば、管理サーバ３００）からのＳＮＭＰ要求に対して応答する。この応答処理は、端末装置１００のＣＰＵ１１０によって実行される。ＣＰＵ１１０は、端末装置１００の電源が投入された場合に、図３の応答処理を開始する。

Ｓ１００では、ＣＰＵ１１０は、ＳＮＭＰ要求を受信したか否かを判断する。ＳＮＭＰ要求が受信されていない場合（Ｓ１００：Ｎｏ）、ＣＰＵ１１０は、ＳＮＭＰ要求を受信するまで待機する。

ＳＮＭＰ要求が受信された場合（Ｓ１００：Ｙｅｓ）、Ｓ１０５で、ＣＰＵ１１０は、タイマ１６０からの情報を用いることによって、ＳＮＭＰの受信日時を特定する。Ｓ１１０では、ＳＮＭＰ要求によって問い合わされる全ての項目の情報が、状態テーブルＴ１に格納済であるか否かを判断する。ＳＮＭＰ要求は、Ｎ個（Ｎは１以上の整数）の項目の問い合わせを、含んでいる。以下、ＳＮＭＰ要求に含まれる項目を、要求項目とも呼ぶ。

図４（Ａ）は、状態テーブルＴ１の例を示す説明図である。状態テーブルＴ１は、項目の名前と、オブジェクトＩＤと、スクリプトと、値と、定期フラグと、の対応関係を示している。オブジェクトＩＤは、項目の識別子である。スクリプトは、プリンタ２００に項目の情報を問い合わせるコマンドである。値は、プリンタ２００から取得された最新の情報を示している。各項目の値は、プリンタ２００の状態情報の例である。定期フラグは、定期的な情報の更新を行うか否かを示している。「定期フラグ＝１」は、管理サーバからの繰り返される要求の期間差とは独立に、定期的に情報の更新が行われる項目を示している。「定期フラグ＝ゼロ」は、そのような定期的な更新の対象外の項目を示している。以下、「１」の定期フラグに対応付けられる項目を、特定項目とも呼ぶ。

プリンタ２００の状態の管理には、予め決められたＭ個（Ｍは１以上の整数）の項目が用いられる（管理項目とも呼ぶ）。Ｍ個の管理項目のそれぞれの名前とオブジェクトＩＤとスクリプトと定期フラグとは、プリンタ２００のベンダによって予め決められている。状態テーブルＴ１は、Ｍ個の管理項目のそれぞれの名前とオブジェクトＩＤとスクリプトと定期フラグとを、予め格納している。各項目の値は、後述するタイマ処理によって、更新される。なお、状態テーブルＴ１のようにＳＮＭＰエージェントによって管理される情報を格納するデータベースは、ＭＩＢ（Management information base）とも呼ばれる。

図４（Ａ）の例では、状態テーブルＴ１は、８個の項目１１〜１８の情報を格納している。第１項目１１は、モデル名を示し、第２項目１２は、シリアル番号を示し、第３項目１３は、動作状態を示し、第４項目１４は、色材の種類を示し、第５〜第８項目１５〜１８は、それぞれ、プリンタ２００で利用される消耗品（例えば、色材）の残量を示している。第３項目１３の動作状態は、予め決められた複数の動作状態（例えば、「待機中」、「印刷中」、「色材切れ」、「用紙詰まり」）のうちの１つを示している。

管理サーバ３００、３２０は、消耗品の残量などの情報を問い合わせるためのＳＮＭＰ要求を、定期的に、端末装置１００に送信する。図４（Ｂ）は、管理サーバ（例えば、管理サーバ３００）からのＳＮＭＰ要求のパケットの例を示す説明図である。図中には、１回の要求のためのパケットの例が、示されている。図示するように、要求のパケットは、パケットヘッダと、問い合わせの対象の項目である要求項目のオブジェクトＩＤを示すデータと、を含んでいる。図示するように、１回の要求は、複数の要求項目を、問い合わせ得る（図４（Ｂ）の例では、要求項目の数は、３個）。

また、管理サーバ３００、３２０は、ユーザの指示に応じて、ＳＮＭＰ要求を端末装置１００に送信し得る。図４（Ｄ）は、ユーザの指示に応じて送信されるＳＮＭＰ要求のパケットの例を示す説明図である。例えば、ユーザは、プリンタ２００の不具合の内容を特定するために、第３項目１３の動作状態を問い合わせるＳＮＭＰ要求を、管理サーバ３００、３２０に送信させる。このように、不規則なタイミングで要求される可能性の高い項目（例えば、第３項目１３）の定期フラグが、「１」に設定されている。

本実施例では、状態テーブルＴ１に予め格納されているＭ個の項目が、適切な管理サーバからのＳＮＭＰ要求の要求項目の候補として用いられる。ＳＮＭＰ要求に含まれる少なくとも１個の要求項目の情報が状態テーブルＴ１に格納されていない場合（図３：Ｓ１１０：Ｎｏ）、ＳＮＭＰ要求の送信元が適切な管理サーバとして扱われず、そして、応答処理が終了する。具体的には、Ｓ１２０で、ＣＰＵ１１０は、エラーが発生したことを通知する応答を、送信元の装置に送信する。本実施例では、ＣＰＵ１１０は、ＳＮＭＰのＧｅｔＲｅｓｐｏｎｓｅのパケットを、送信元の装置に送信する。ここで、ＧｅｔＲｅｓｐｏｎｓｅのパケットのエラーステータスは、要求項目のオブジェクトＩＤが存在しないことを示す「noSuchName」に設定される。Ｓ１２０の後、ＣＰＵ１１０は、Ｓ１００へ戻り、新たなＳＮＭＰ要求を受信するまで、待機する。

ＳＮＭＰ要求に含まれる全ての要求項目の情報が状態テーブルＴ１に格納済である場合（図３：Ｓ１１０：Ｙｅｓ）、ＳＮＭＰ要求の送信元が適切な管理サーバとして扱われ、そして、応答処理が進行する。本実施例では、第１管理サーバ３００からのＳＮＭＰ要求と、第２管理サーバ３２０からのＳＮＭＰ要求とは、いずれも、Ｓ１１０の条件を満たすこととする。

Ｓ１１０の判断結果がＹｅｓである場合、Ｓ１９０で、ＣＰＵ１１０は、送信元の通信アドレスが、履歴テーブルＴ３に格納済の通信アドレスと一致するか否かを、判断する。本実施例では、通信アドレスとして、ＩＰアドレスが用いられる。以下、ＳＮＭＰ要求の送信元の通信アドレスを、要求アドレスとも呼ぶ。

図４（Ｆ）は、履歴テーブルＴ３の例を示す説明図である。後述するように、履歴テーブルＴ３には、適切な管理サーバから受信したＳＮＭＰ要求に関連する情報が、格納される。具体的には、履歴テーブルＴ３は、ＩＰアドレスと、前回日時と、期間差（時間間隔とも呼ぶ）と、取得時間と、設定日時と、オブジェクトＩＤのリストと、の対応関係の履歴を示している。以下、履歴テーブルＴ３に格納された各対応関係を、要求履歴情報とも呼ぶ。ＩＰアドレスは、ＳＮＭＰ要求の送信元のＩＰアドレスである。前回日時は、前回にＳＮＭＰ要求を受信した日時である。取得時間は、プリンタ２００から状態情報を取得するのに要する時間である。取得すべき項目の総数が複数である場合であって、複数の項目の情報がプリンタ２００から順次に受信される場合には、取得時間は、最後に受信される項目の情報が受信された時刻に基づいて、決定される。設定日時は、収集ジョブをプリンタ２００へ送信すべき日時である。時間間隔は、前回のＳＮＭＰ要求の受信（すなわち、最新のＳＮＭＰ要求の受信）のタイミングと、その１つ前のＳＮＭＰ要求の受信のタイミングと、の間の期間の時間幅である。オブジェクトＩＤのリストは、ＳＮＭＰ要求に含まれる要求項目のオブジェクトＩＤのリストである。

送信元が適切な管理サーバであっても、今回のＳＮＭＰ要求がその送信元からの初めてのＳＮＭＰ要求である場合には、今回のＳＮＭＰ要求に関連する要求履歴情報は履歴テーブルＴ３に格納されていない。そして、要求アドレスは、履歴テーブルＴ３に格納済のいずれの要求履歴情報の通信アドレスとも一致しない。すなわち、要求アドレスと同じ通信アドレスの要求履歴情報は、履歴テーブルＴ３に格納されていない。この場合（Ｓ１９０：Ｎｏ）、Ｓ２１０で、ＣＰＵ１１０は、今回のＳＮＭＰ要求に関連する要求履歴情報を、履歴テーブルＴ３に追加し、Ｓ２４５へ移行する。ここで、ＩＰアドレスは、ＳＮＭＰ要求の送信元のＩＰアドレスに設定される。前回日時は、Ｓ１０５で特定された今回のＳＮＭＰ要求を受信した日時に設定される。時間間隔は、予め決められた値であるデフォルト値（例えば、８時間）に設定される。取得時間は、予め決められた初期値（例えば、ゼロ分）に設定される。設定日時は、前回日時に時間間隔を加算して得られる日時に、設定される。オブジェクトＩＤのリストは、ＳＮＭＰ要求に含まれる全ての要求項目のオブジェクトＩＤのリストに、設定される。通常は、ＩＰアドレスは、管理サーバ毎に異なっている。従って、履歴テーブルＴ３は、管理サーバ毎に異なる要求履歴情報を格納する。図４（Ｆ）の例では、第１要求履歴情報３１は、第１管理サーバ３００の情報であり、第２要求履歴情報３２は、第２管理サーバ３２０の情報である。

要求アドレスが、履歴テーブルＴ３に格納済のいずれかの要求履歴情報の通信アドレスと一致する場合（Ｓ１９０：Ｙｅｓ）、すなわち、送信元の通信アドレスと同じ通信アドレスの要求履歴情報が履歴テーブルＴ３に格納されている場合、処理は、Ｓ２００へ移行する。Ｓ２００で、ＣＰＵ１１０は、履歴テーブルＴ３から要求アドレスと同じ通信アドレスの要求履歴情報を検索し、見つかった要求履歴情報のオブジェクトＩＤのリストが要求項目のオブジェクトＩＤの組み合わせに一致するか否かを判断する。１つの管理サーバは、互いに異なる項目を、互いに異なる周期で、端末装置１００に問い合わせる場合がある。このような場合、要求項目のオブジェクトＩＤの組み合わせは、履歴テーブルＴ３中の要求アドレスに対応するオブジェクトＩＤのリストとは異なり得る。

以下、履歴テーブルＴ３に格納された要求履歴情報のうち、通信アドレスが要求アドレスと同じであり、かつ、オブジェクトＩＤのリストが要求項目のオブジェクトＩＤの組み合わせに一致する要求履歴情報を、第１対象履歴情報と呼ぶ。

Ｓ２００では、ＣＰＵ１１０は、履歴テーブルＴ３を参照し、要求項目のオブジェクトＩＤの組み合わせと一致するオブジェクトＩＤのリストが、通信アドレスが要求アドレスと同じである要求履歴情報に記録されているか否かを判断する。Ｓ１９０の判断結果がＹｅｓであり、かつ、Ｓ２００の判断結果がＹｅｓであることは、履歴テーブルＴ３が第１対象履歴情報を格納していることを、示している。

Ｓ２００の判断結果がＮｏである場合、Ｓ２１０で、ＣＰＵ１１０は、今回のＳＮＭＰ要求に関連する要求履歴情報を、履歴テーブルＴ３に追加し、Ｓ２４５へ移行する。このように、本実施例では、履歴テーブルＴ３は、ＩＰアドレスが同じであり、かつ、オブジェクトＩＤのリストが互いに異なる複数の要求履歴情報を格納し得る。すなわち、履歴テーブルＴ３は、項目のリストとＩＰアドレスとの組み合わせ毎に、要求履歴情報を格納する。

Ｓ２００の判断結果がＹｅｓである場合、Ｓ２２０で、ＣＰＵ１１０は、履歴テーブルＴ３を参照して、第１対象履歴情報の前回日時を特定する。そして、ＣＰＵ１１０は、前回日時と、今回のＳＮＭＰ要求を受信した日時と、の間の期間の時間幅である時間間隔を算出する。今回の日時は、Ｓ１０５で特定された日時である。Ｓ２３０では、ＣＰＵ１１０は、Ｓ２２０で算出された時間間隔を、履歴テーブルＴ３の第１対象履歴情報の時間間隔に登録する。これにより、第１対象履歴情報の時間間隔が、更新される。Ｓ２４０では、ＣＰＵ１１０は、履歴テーブルＴ３の第１対象履歴情報の前回日時を、今回の日時に更新する。

Ｓ２４５では、ＣＰＵ１１０は、状態テーブルＴ１を参照し、ＳＮＭＰ要求の全ての要求項目の情報を検索し、見つかった情報を取得する。Ｓ２５０では、ＣＰＵ１１０は、取得した情報を含むＳＮＭＰ応答を、ＳＮＭＰ要求の送信元（例えば、管理サーバ３００）に送信する。本実施例では、ＣＰＵ１１０は、ＳＮＭＰのＧｅｔＲｅｓｐｏｎｓｅのパケットを、送信元に送信する。

図４（Ｃ）は、端末装置１００からのＳＮＭＰ応答のパケットの例を示す説明図である。この応答のパケットは、図４（Ｂ）の要求のパケットに対する応答の例を示している。図示するように、この応答パケット（ここでは、ＧｅｔＲｅｓｐｏｎｓｅのパケット）は、要求パケットに含まれる全ての要求項目に関して、オブジェクトＩＤと対応する情報とを示すデータを含んでいる。

Ｓ２５０の処理（すなわち、ＳＮＭＰ応答の送信）の後、ＣＰＵ１１０は、Ｓ１００へ戻り、新たなＳＮＭＰ要求を受信するまで、待機する。以上のように、ＣＰＵ１１０は、図３の応答処理を継続する。

図５は、タイマ処理の例を示すフローチャートである。このタイマ処理は、端末装置１００のＣＰＵ１１０によって実行される。ＣＰＵ１１０は、端末装置１００の電源が投入された場合に、図５のタイマ処理を開始する。ＣＰＵ１１０は、タイマ処理を、図３の応答処理と並行して、実行する。

Ｓ３００では、ＣＰＵ１１０は、状態テーブルＴ１（図４（Ａ））によって規定されるＭ個の管理項目の全ての情報を、プリンタ２００から取得する。本実施例では、ＣＰＵ１１０は、状態テーブルＴ１を参照することによって、各管理項目のスクリプトを特定する。そして、ＣＰＵ１１０は、各管理項目のスクリプトを含む収集ジョブを生成し、生成した収集ジョブを、印刷スプーラＢ１５０（図２）に供給する。印刷スプーラＢ１５０として動作するＣＰＵ１１０は、収集ジョブを、プリンタ２００に送信する。プリンタ２００は、受信した収集ジョブに含まれるスクリプトを解析し、要求された情報（ここでは、各管理項目の値を示すデータ）を端末装置１００へ送信する。ＣＰＵ１１０は、プリンタ２００からの情報を取得する。Ｓ３０２では、ＣＰＵ１１０は、取得した情報を状態テーブルＴ１に登録する。これにより、状態テーブルＴ１の全ての項目の値が更新される。

Ｓ３０５では、ＣＰＵ１１０は、管理項目の更新の時間間隔を、予め決められた値であるデフォルト値に設定する。この時間間隔は、図３のＳ２１０で、デフォルト値として用いられる。Ｓ３０８では、ＣＰＵ１１０は、タイマ１６０からの情報を用いて、現在日時を特定する。Ｓ３１０では、ＣＰＵ１１０は、収集ジョブをプリンタ２００へ送信すべき設定日時を、現在日時に時間間隔を加算して得られる日時に、設定する。この設定日時は、ゼロの定期フラグ（図４（Ａ））に対応する項目の収集ジョブをプリンタ２００に送信すべき日時を示している。履歴テーブルＴ３（図４（Ｆ））が要求履歴情報を格納している場合、ＣＰＵ１１０は、各要求履歴情報の設定日時に、現在日時に時間間隔を加算して得られる日時を登録する。

Ｓ３１５では、ＣＰＵ１１０は、定期日時を、現在日時に定期間隔を加算して得られる日時に、設定する。定期日時は、「１」の定期フラグ（図４（Ａ））に対応する項目の収集ジョブをプリンタ２００へ送信すべき日時である。定期間隔は、予め決められており、定期テーブルＴ２（図１）によって規定されている。図４（Ｅ）は、定期テーブルＴ２の例を示す説明図である。定期テーブルＴ２は、定期間隔と、定期日時と、を示している。定期間隔は、予め決められている（図４（Ｅ）の例では、１時間）。ＣＰＵ１１０は、算出した定期日時を、定期テーブルＴ２の定期日時に登録する。

Ｓ３１８で、ＣＰＵ１１０は、タイマ１６０からの情報を用いて現在日時を特定する。Ｓ３２０で、ＣＰＵ１１０は、現在日時が設定日時であるか否かを判断する。本実施例では、ＣＰＵ１１０は、現在日時を、履歴テーブルＴ３（図４（Ｆ））に格納済の各要求履歴情報の設定日時と、比較する。そして、現在日時がいずれかの要求履歴情報の設定日時と同じである場合（Ｓ３２０：Ｙｅｓ）、ＣＰＵ１１０は、現在日時と同じ設定日時の要求履歴情報のオブジェクトＩＤの情報を更新するためのステップＳ３４０〜Ｓ３５５を実行する。以下、設定日時が現在日時と同じである要求履歴情報を、第２対象履歴情報と呼ぶ。第２対象履歴情報のオブジェクトＩＤのリストによって特定される項目を、対象項目と呼ぶ。

Ｓ３４０では、ＣＰＵ１１０は、各対象項目のスクリプトを含む収集ジョブを生成し、生成した収集ジョブを、印刷スプーラＢ１５０（図２）に供給する。印刷スプーラＢ１５０として動作するＣＰＵ１１０は、収集ジョブを、プリンタ２００に送信する。また、ＣＰＵ１１０は、タイマ１６０からの情報を用いて、収集ジョブがプリンタ２００に送信された日時を特定する（送信日時と呼ぶ）。プリンタ２００は、受信した収集ジョブに含まれるスクリプトを解析し、要求された情報を端末装置１００へ送信する。Ｓ３４５では、ＣＰＵ１１０は、プリンタ２００からの各対象項目の情報を、取得する。また、ＣＰＵ１１０は、タイマ１６０からの情報を用いて、プリンタ２００からの情報が受信された日時を特定する（受信日時と呼ぶ）。Ｓ３４７では、ＣＰＵ１１０は、取得した情報を、状態テーブルＴ１（図４（Ａ））の対応する対象項目の値に登録する。これにより、状態テーブルＴ１の全ての対象項目の値が更新される。

Ｓ３５０では、ＣＰＵ１１０は、送信日時と受信日時との間の期間の時間幅である取得時間を算出する。取得時間は、受信日時−送信日時によって、算出される。ＣＰＵ１１０は、算出した取得時間を、履歴テーブルＴ３（図４（Ｆ））の第２対象履歴情報の取得時間に登録する。Ｓ３５５では、ＣＰＵ１１０は、新たな設定日時を算出する。設定日時は、現在日時＋時間間隔−取得時間によって、算出される。時間間隔は、履歴テーブルＴ３（図４（Ｆ））の第２対象履歴情報の時間間隔である。ＣＰＵ１１０は、算出した設定日時を、履歴テーブルＴ３の第２対象履歴情報の設定日時に登録する。そして、ＣＰＵ１１０は、Ｓ３１８へ移行する。

Ｓ３２０の判断結果がＮｏである場合、Ｓ３２５で、ＣＰＵ１１０は、定期テーブルＴ２（図４（Ｅ））を参照して定期日時を特定し、現在日時が定期日時であるか否かを判断する。現在日時が定期日時と同じである場合（Ｓ３２５：Ｙｅｓ）、ＣＰＵ１１０は、特定項目の情報を更新するためのステップＳ３６０〜Ｓ３７０を実行する。

Ｓ３６０では、ＣＰＵ１１０は、各特定項目のスクリプトを含む収集ジョブを生成し、生成した収集ジョブを、印刷スプーラＢ１５０（図２）に供給する。印刷スプーラＢ１５０として動作するＣＰＵ１１０は、収集ジョブを、プリンタ２００に送信する。プリンタ２００は、受信した収集ジョブに含まれるスクリプトを解析し、要求された情報を端末装置１００へ送信する。Ｓ３６５では、ＣＰＵ１１０は、プリンタ２００からの各特定項目の情報を、取得する。Ｓ３６７では、ＣＰＵ１１０は、取得した情報を、状態テーブルＴ１（図４（Ａ））の対応する特定項目の値に登録する。これにより、状態テーブルＴ１の全ての特定項目の値が更新される。

Ｓ３７０では、ＣＰＵ１１０は、現在日時に定期間隔を加算することによって、新たな定期日時を算出する。ＣＰＵ１１０は、算出した定期日時を定期テーブルＴ２（図４（Ｅ））に登録する。そして、ＣＰＵ１１０は、Ｓ３１８へ移行する。

Ｓ３２５の判断結果がＮｏである場合、Ｓ３３０で、ＣＰＵ１１０は、履歴テーブルＴ３（図４（Ｆ））を参照し、少なくとも１つの要求履歴情報の時間間隔が更新済であるか否かを判断する。時間間隔の更新は、図３のＳ２３０で行われる。ＣＰＵ１１０は、履歴テーブルＴ３の設定日時が設定された後に時間間隔が更新された場合に、時間間隔が更新されたと判断する。後述するように、履歴テーブルＴ３の設定日時は、更新済の時間間隔を用いて更新される。設定日時が更新された後に時間間隔が更新されていない場合には、ＣＰＵ１１０は、時間間隔は更新されていないと判断する。

履歴テーブルＴ３の少なくとも１つの要求履歴情報の時間間隔が更新済である場合（Ｓ３３０：Ｙｅｓ）、ＣＰＵ１１０は、Ｓ３５５で、履歴テーブルＴ３の更新済の時間間隔に対応する設定日時を更新する。ＣＰＵ１１０は、更新済の時間間隔を用いて新たな設定日時を算出し、算出した設定日時を、更新済の時間間隔に対応する設定日時に登録する。そして、ＣＰＵ１１０は、Ｓ３１８へ移行する。

履歴テーブルＴ３の全ての要求履歴情報の時間間隔が更新済ではない場合（Ｓ３３０：Ｎｏ）、ＣＰＵ１１０は、Ｓ３１８へ移行する。以上のように、ＣＰＵ１１０は、設定時刻に従って対象項目の情報を更新し、定期時刻に従って特定項目の情報を更新する。

以上のように、端末装置１００（図１）は、ネットワークＩＦ１８０とＵＳＢインタフェース１７０とを備えている。プリンタ２００は、ＵＳＢインタフェース１７０を介して、端末装置１００に接続される。図３のＳ１００では、ＣＰＵ１１０は、ネットワークＩＦ１８０を介して、プリンタ２００の状態情報の要求であるＳＮＭＰ要求を、管理サーバ（例えば、管理サーバ３００、３２０）から受信する。上述したように、管理サーバは、定期的に、ＳＮＭＰ要求を端末装置１００に送信する。そして、図３の処理は、繰り返し実行される。従って、ＣＰＵ１１０は、Ｓ１００で、同じ管理サーバからのＳＮＭＰ要求を、定期的に、受信する。例えば、ＣＰＵ１１０は、第１のＳＮＭＰ要求を受信した後に、同じ状態情報の新たな要求である第２のＳＮＭＰ要求を、同じ管理サーバから受信する。また、図５のＳ３５５では、ＣＰＵ１１０は、ＵＳＢインタフェース１７０を介して収集ジョブをプリンタ２００に送信する送信タイミング（具体的には、設定日時）を、第１のＳＮＭＰ要求の受信のタイミングと第２のＳＮＭＰ要求の受信のタイミングとの間の第１の期間を利用して決定する。ここで、収集ジョブは、管理サーバからのＳＮＭＰ要求の対象項目を問い合わせるための要求の例である。そして、図５のＳ３２０、Ｓ３４０では、決定された設定日時に従って、収集ジョブが、プリンタ２００に送信される。プリンタ２００は、受信した収集ジョブに応じて、対象項目の情報を、端末装置１００へ送信する。Ｓ３４５では、ＣＰＵ１１０は、プリンタ２００からの対象項目の情報を、受信する。

このように、端末装置１００は、互いに異なる通信インタフェース１７０、１８０を介して管理サーバ（例えば、管理サーバ３００、３２０）とプリンタ２００とに接続されている。そして、図５のＳ３５５で、収集ジョブの送信タイミングは、管理サーバからの繰り返されるＳＮＭＰ要求の時間間隔に適したタイミングに決定される。従って、端末装置１００は、管理サーバからのＳＮＭＰ要求の受信のタイミングに適したタイミングでプリンタ２００から対象項目の情報を受信できる。例えば、ＣＰＵ１１０は、管理サーバ３００からＳＮＭＰ要求を受信するタイミングとおおよそ同じタイミングで、プリンタ２００から最新の状態情報を受信できるように、送信タイミングを決定できる。これにより、端末装置１００が管理サーバ３００からのＳＮＭＰ要求を受信したことに応じてプリンタ２００に収集ジョブを送信する場合と比べて、端末装置１００は、速やかに、新しい状態情報を管理サーバ３００へ送信できる。

また、図３の処理は、繰り返し実行される。従って、ＣＰＵ１１０は、第２のＳＮＭＰ要求を受信した後に、同じ状態情報の新たな要求である第３のＳＮＭＰ要求を、同じ管理サーバから受信する。そして、Ｓ２３０で、時間間隔が更新される。また、図５の処理は、繰り返し実行される。第３の管理要求が受信される場合に、上記の通り時間間隔が更新されるので、図５のＳ３３０の判断結果がＹｅｓになる。この結果、第３の管理要求が受信される場合に、図５のＳ３５５では、ＣＰＵ１１０は、第２の管理要求の受信のタイミングと第３の管理要求の受信のタイミングとの間の第２の期間を利用して、送信タイミングを決定する。このように、新たなＳＮＭＰ要求が受信される場合に、送信タイミングが更新されるので、端末装置１００は、適切なタイミングで、プリンタ２００から状態情報を受信できる。

また、図５のＳ３４０、Ｓ３４５では、ＣＰＵ１１０は、収集ジョブがプリンタ２００に送信されてから、プリンタ２００からの状態情報が受信されるまでの期間である取得期間を特定する（具体的には、収集ジョブの送信日時から、対応項目の情報の受信日時までの期間）。Ｓ３５０、Ｓ３５５では、ＣＰＵ１１０は、送信タイミング（すなわち、新たな設定日時）を、時間間隔に基づいて特定されるタイミングから取得期間の時間幅（すなわち、取得時間）だけ早いタイミングに決定する。具体的には、新たな送信タイミングは、現在日時＋時間間隔−取得時間に設定される。この結果、取得時間が長い場合であっても、端末装置１００は、適切なタイミングで、プリンタ２００から状態情報を受信できる。例えば、管理サーバ３００からＳＮＭＰ要求を受信するタイミングとおおよそ同じタイミングで、端末装置１００は、プリンタ２００からの状態情報の取得を完了できる。従って、端末装置１００は、速やかに、管理サーバ３００に、新しい状態情報を送信できる。

また、図５のＳ３２０、Ｓ３４０では、ＣＰＵ１１０は、収集ジョブをプリンタ２００に送信するための処理を、Ｓ３５５で決定された送信タイミングに従って、実行する。従って、端末装置１００は、適切なタイミングで、プリンタ２００から状態情報を受信できる。

また、図５のＳ３４７では、ＣＰＵ１１０は、プリンタ２００から受信した情報を、記憶装置１１５（ここでは、不揮発性記憶装置１３０の状態テーブルＴ１）に、格納する。そして、図３のＳ２４５、Ｓ２５０では、ＣＰＵ１１０は、記憶装置１１５（ここでは、不揮発性記憶装置１３０の状態テーブルＴ１）に格納済みの情報のうちＳＮＭＰ要求の対象項目の情報を、管理サーバ（例えば、管理サーバ３００）に送信する。従って、ＣＰＵ１１０は、管理サーバからのＳＮＭＰ要求に適した状態情報を、管理サーバに送信できる。

また、図３の処理では、ＣＰＵ１１０は、ＳＮＭＰ要求を受信した場合に、ＳＮＭＰ要求の送信元が、状態情報を返信するための特定の条件（ここでは、Ｓ１１０の条件）を満たす管理装置であるか否かを判断する。そして、Ｓ１１０の条件が満たされない場合（Ｓ１１０：Ｎｏ）、ＣＰＵ１１０は、状態情報を送信元に送信しない。Ｓ１１０の条件が満たされる場合（Ｓ１１０：Ｙｅｓ）、ＣＰＵ１１０は、記憶装置１１５（ここでは、不揮発性記憶装置１３０の状態テーブルＴ１）に格納済の情報のうちＳＮＭＰ要求の対象項目の情報を、管理装置（例えば、管理サーバ３００）に送信する。従って、適切な管理装置とは異なる装置に状態情報が送信されることが、抑制される。例えば、端末装置１００は、ルータなどのネットワーク装置を管理するネットワーク管理装置からＳＮＭＰ要求を受信し得る。このような場合に、端末装置１００が、プリンタ２００の状態情報をネットワーク管理装置に送信することが、抑制される。

また、図３のＳ１１０では、ＣＰＵ１１０は、ＳＮＭＰ要求を解析することによって、ＳＮＭＰ要求の送信元が特定の条件を満たす管理装置であるか否かを判断する。従って、適切な判断が、可能である。なお、本実施例では、Ｓ１１０の条件は、ＳＮＭＰ要求の全ての対象項目のオブジェクトＩＤが、予め決められた候補に含まれることである。

また、図５のＳ３２５、Ｓ３６０では、ＣＰＵ１１０は、特定項目の状態を問い合わせるための収集ジョブをプリンタ２００に送信するための処理を、Ｓ３５５で決定される送信タイミング（ここでは、設定日時）とは独立に、定期的に、実行する。そして、Ｓ３６５では、ＣＰＵ１１０は、Ｓ３６０の収集ジョブに応じてプリンタ２００によって送信される特定項目の状態を示す状態情報を、プリンタ２００から受信する。従って、端末装置１００は、特定項目の状態を示す新しい情報を、適切に、準備できる。図４（Ａ）で説明したように、状態テーブルＴ１の複数の項目１１〜１８のうち、不規則なタイミングで要求され得る特定項目（ここでは、第３項目１３）の定期フラグは、「１」に設定されている。従って、特定項目１３の値は、Ｓ３５５で決定される設定日時とは独立に、定期的に、更新される。この結果、管理サーバ３００、３２０が、ユーザの指示に応じて、不規則なタイミングで、ＳＮＭＰ要求を端末装置１００に送信する場合に、端末装置１００は、特定項目の新しい情報を、管理サーバ３００、３２０に送信できる。

また、図３のＳ１９０、Ｓ２１０、図４（Ｆ）で説明したように、ＣＰＵ１１０は、管理サーバ毎に異なる要求履歴情報を、履歴テーブルＴ３に格納する。すなわち、収集ジョブを送信すべき送信タイミングである設定日時は、管理サーバ毎に、決定される。例えば、図４（Ｆ）の実施例では、第１要求履歴情報３１の設定日時は、第１管理サーバ３００によって要求される項目の情報をプリンタ２００に要求する収集ジョブの送信タイミングを示している。第２要求履歴情報３２の設定日時は、第１管理サーバ３００とは異なる第２管理サーバ３２０によって要求される項目の情報をプリンタ２００に要求する収集ジョブの送信タイミングを示している。これにより、プリンタ２００から情報を取得するための処理は、第１管理サーバ３００と第２管理サーバ３２０とのそれぞれに適したタイミングで、実行される。なお、図４（Ｆ）に示すように、第２管理サーバ３２０のための送信タイミング（ここでは、設定日時）は、第１管理サーバ３００のための送信タイミングとは異なるタイミングに、決定され得る。

Ｂ．第２実施例：
図６は、応答処理の別の実施例を示すフローチャートである。図６には、図３の実施例から変更された部分を含む一部が、示されている。図３の実施例との差異は、ＳＮＭＰ要求の送信元に状態情報を返信するための条件が、異なっている点だけである。

Ｓ１１０の判断結果がＹｅｓである場合、Ｓ１３０で、ＣＰＵ１１０は、ＳＮＭＰ要求の送信元の通信アドレスが、履歴テーブルＴ３に格納済の通信アドレスと一致するか否かを、判断する。この判断は、図３のＳ１９０と同様に、行われる。

今回のＳＮＭＰ要求に関連する要求履歴情報が履歴テーブルＴ３に格納されていない場合、Ｓ１３０の判断結果はＮｏである。例えば、今回のＳＮＭＰ要求がその送信元からの初めてのＳＮＭＰ要求である場合に、Ｓ１３０の判断結果がＮｏである。Ｓ１３０の判断結果がＮｏである場合、Ｓ１４０で、ＣＰＵ１１０は、ＳＮＭＰ要求に含まれる要求項目の組み合わせが、予め決められた組み合わせである想定組み合わせと一致するか否かを判断する。想定組み合わせは、例えば、図４（Ｂ）に示すパケットのオブジェクトＩＤの組み合わせであってよい。少なくとも１個の要求項目が、想定組み合わせに含まれない場合（Ｓ１４０：Ｎｏ）、ＣＰＵ１１０は、Ｓ１２０（図３）へ移行して、エラーが発生したことを通知する応答を、送信元の装置に送信する。この場合、今回のＳＮＭＰ要求に関連する要求履歴情報は、履歴テーブルＴ３（図４（Ｆ））には、格納されない。

要求項目の組み合わせが、想定組み合わせと一致する場合（Ｓ１４０：Ｙｅｓ）、Ｓ１５０で、ＣＰＵ１１０は、ＳＮＭＰ要求の送信元の通信アドレスを含む要求履歴情報を、履歴テーブルＴ３（図４（Ｆ））に追加する。Ｓ１５０で追加される要求履歴情報は、有効な情報としてＩＰアドレスのみを含んでいる。前回日時などの他の情報は、後述するＳ２１０（図３）で登録される。従って、ＩＰアドレス以外の他の情報は、空欄であってよい。Ｓ１５０の完了に応じて、処理は、Ｓ１９０（図３）へ移行する。

今回のＳＮＭＰ要求に関連する要求履歴情報が履歴テーブルＴ３に格納済である場合、Ｓ１３０の判断結果がＹｅｓである。この場合、ＣＰＵ１１０は、Ｓ１９０（図３）へ移行する。

Ｓ１９０以降の処理は、図３の実施例の対応する部分の処理と、同じである。ＣＰＵ１１０は、図３の実施例と同様に、今回のＳＮＭＰ要求に関連する要求履歴情報を、追加（Ｓ２１０）、または、更新する（Ｓ２２０〜Ｓ２４０）。そして、ＣＰＵ１１０は、ＳＮＭＰ要求の全ての要求項目の情報を含むＳＮＭＰ応答を、ＳＮＭＰ要求の送信元（例えば、管理サーバ３００）に送信する（Ｓ２４５、Ｓ２５０）。

このように、本実施例では、ＳＮＭＰ要求の要求項目の組み合わせが想定組み合わせと異なる場合（Ｓ１４０：Ｎｏ）、そのＳＮＭＰ要求に関連する要求履歴情報は、履歴テーブルＴ３に登録されず、また、プリンタ２００の状態情報を含むＳＮＭＰ応答は、ＳＮＭＰ要求の送信元には返信されない。ＳＮＭＰ要求の要求項目の組み合わせが想定組み合わせと同じである場合（Ｓ１４０：Ｙｅｓ）、そのＳＮＭＰ要求に関連する要求履歴情報は、履歴テーブルＴ３に登録され（Ｓ１５０）、また、プリンタ２００の状態情報を含むＳＮＭＰ応答は、ＳＮＭＰ要求の送信元に返信される（Ｓ２４５、Ｓ２５０）。このように、状態情報を含むＳＮＭＰ応答が返信されるための条件は、ＳＮＭＰ要求の要求項目の組み合わせが予め決められた想定組み合わせと同じであることを含む。従って、端末装置１００は、想定組み合わせの要求項目のＳＮＭＰ要求を送信する適切な管理装置のみに、状態情報を提供できる。

また、ＣＰＵ１１０は、ＳＮＭＰ要求を解析することによって、Ｓ１４０の条件が満たされるか否かを判断する。従って、適切な判断が、可能である。

Ｃ．第３実施例：
図７は、タイマ処理の別の実施例を示すフローチャートである。図７には、図５の実施例から変更された部分を含む一部が、示されている。図５の実施例との差異は、一度算出された取得時間が、更新されずに、継続して用いられる点だけである。

Ｓ３４７の後、Ｓ３４８で、ＣＰＵ１１０は、第２対象履歴情報の取得時間が算出済であるか否かを判断する。本実施例では、ＣＰＵ１１０は、履歴テーブルＴ３（図４（Ｆ））の第２対象履歴情報の取得時間を参照し、取得時間が登録済である場合に、取得時間が算出済であると判断する。

取得時間が算出済ではない場合（Ｓ３４８：Ｎｏ）、Ｓ３５０で、ＣＰＵ１１０は、取得時間を算出する。Ｓ３５０は、図５のＳ３５０と同じである。Ｓ３５０の後、ＣＰＵ１１０は、Ｓ３５５（図５）へ移行する。

取得時間が算出済である場合（Ｓ３４８：Ｙｅｓ）、ＣＰＵ１１０は、Ｓ３５０をスキップして、Ｓ３５５へ移行する。これにより、第２対象履歴情報の取得時間は更新されずに維持される。

一般的に、収集ジョブに対するプリンタ２００の応答の速度は、おおよそ一定である。従って、算出された取得時間は、更新されずに、継続して利用されてよい。この場合も、端末装置１００は、適切なタイミングで、プリンタ２００から状態情報を受信できる。

Ｄ．変形例：
（１）応答処理とタイマ処理とは、上記の処理に代えて、他の種々の処理であってよい。例えば、管理装置（例えば、管理サーバ３００、３２０）が繰り返し送信するＳＮＭＰ要求の時間間隔は、通常は、一定である。従って、履歴テーブルＴ３（図４（Ｆ））の要求履歴情報の時間間隔が図３のＳ２３０で設定された後には、同じ要求履歴情報の時間間隔の更新（Ｓ２３０）が省略されてもいい。

（２）図５のＳ３５５で算出される設定日時は、「現在日時＋時間間隔−取得時間」よりも早い日時であってよい。例えば、設定日時＝現在日時＋時間間隔−取得時間−Ｔｘであってよい（Ｔｘは、予め決められた正の時間（例えば、１０分））。また、設定日時の決定に利用される時間間隔は、複数回のＳＮＭＰ要求の受信に応じて特定される複数個の時間間隔の平均値であってよい。また、時間間隔の変化量が所定の閾値以下である場合には、時間間隔の更新（図３：Ｓ２３０）が省略されてよい。

また、図５のＳ３５５の設定日時の計算から、取得時間が省略されてよい。例えば、設定日時は、「現在日時＋時間間隔」であってよく、また、「現在日時＋時間間隔−Ｔｘ」であってよい。プリンタ２００の収集ジョブに対する応答速度が十分に速い場合には、取得時間が省略された場合であっても、適切な設定日時を決定できる。

（３）図６の実施例で、Ｓ１１０が省略されてもよい。この場合、状態テーブルＴ１（図４（Ａ））には、Ｓ１４０で用いられる想定組み合わせの項目の情報と、図５のＳ３６０〜Ｓ３６７で用いられる特定項目の情報と、のみが、登録されてもよい。

（４）状態情報を含むＳＮＭＰ応答を返信するための条件である特定の条件は、図３のＳ１１０の条件や、図６のＳ１１０、Ｓ１４０の条件に限らず、種々の条件であってよい。例えば、特定の条件は、ＳＮＭＰ要求の送信元のＩＰアドレスが、予め決められたＩＰアドレスであることを含んでよい。

（５）図５の処理において、特定項目の情報を定期的に更新するための処理（Ｓ３２５、Ｓ３６０〜Ｓ３７０）は、省略されてもよい。また、図４（Ｆ）の実施例では、履歴テーブルＴ３は、管理装置毎に異なる設定日時（すなわち、収集ジョブの送信タイミング）を規定している。これに代えて、送信タイミングは、複数の管理装置に共通であってもよい。

（６）上記の実施例では、種々のタイミング（例えば、送信タイミング、受信タイミングなど）を特定するために、日時が用いられている。これに代えて、タイミングは、日付を用いずに時刻を用いて、特定されてよい。管理装置（例えば、管理サーバ３００、３２０）からの繰り返されるＳＮＭＰ要求の時間間隔は、通常は、１日よりも短い。従って、日付が省略される場合であっても、時刻を用いることによって、適切にタイミングを特定できる。また、タイマ１６０は、現在日時を測定する装置に代えて、基準時刻からの経過時間を測定する装置であってよい。基準時刻は、例えば、端末装置１００の電源が投入された時刻であってよい。タイミングは、タイマ１６０によって測定される経過時間を用いて、特定されてよい。

（７）図３のＳ１２０、Ｓ２５０のＳＮＭＰ応答を外部装置へ送信する応答送信機能は、端末装置１００上で動作するシステム（例えば、オペレーティングシステム）に組み込まれた機能であってよい。そして、図３の処理を実行するためのプログラムは、ＳＮＭＰ応答を送信するための処理として、応答送信機能に指示を供給する処理をＣＰＵ１１０に実現させるように、構成されてよい。これに代えて、図３の処理を実行するためのプログラムは、ＳＮＭＰ応答を送信するための処理として、ＳＮＭＰ応答を送信する処理をＣＰＵ１１０に実現させるように、構成されてよい。

（８）図５のＳ３４０、Ｓ３６０の状態情報を要求する収集ジョブをプリンタ２００へ送信する要求送信機能（例えば、図２の印刷スプーラＢ１５０の機能）は、端末装置１００上で動作するシステム（例えば、オペレーティングシステム）に組み込まれた機能であってよい。そして、図５の処理を実行するためのプログラムは、収集ジョブを送信するための処理として、要求送信機能に指示を供給する処理をＣＰＵ１１０に実現させるように、構成されてよい。これに代えて、図５の処理を実行するためのプログラムは、収集ジョブを送信するための処理として、収集ジョブを送信する処理をＣＰＵ１１０に実現させるように、構成されてよい。また、プリンタ２００によって受け付けられる状態情報の要求の形式は、印刷ジョブを利用する形式に代えて、他の任意の形式であってよい。例えば、プリンタ２００は、印刷ジョブのためのプロトコルとは異なる別のプロトコルに従って、状態情報の要求を受け付けてよい。また、プリンタ２００は、マークアップ言語（例えば、XML（Extensible Markup Language）など）で記述された要求を受け付けてよい。プリンタ２００によって送信される状態情報を含む応答の形式についても、同様に、任意の形式であってよい。

（９）上記実施例の端末装置１００では、管理サーバ３００、３２０と通信する第１種のインタフェースは、ネットワークＩＦ１８０であり、プリンタ２００と通信する第２種のインタフェースは、ＵＳＢＩＦ１７０である。このように、第１種のインタフェースの通信が従う通信規格と、第２種のインタフェースの通信が従う通信規格とは、異なっている。これに代えて、例えば、第１種のインタフェースの通信が従う通信規格と、第２種のインタフェースの通信が従う通信規格とは、同じ通信規格（例えば、イーサネット（登録商標））であっても良い。

この場合には、端末装置１００は、第１種のインタフェースとして第１のネットワークＩＦを備え、第２種のインタフェースとして第２のネットワークＩＦを備えてよい。そして、第１のネットワークＩＦは、インターネットに接続され、該インターネットを介して管理サーバ３００、３２０と接続されてよい。第２のネットワークＩＦは、ローカルエリアネットワークに接続され、該ローカルエリアネットワークを介してネットワークプリンタに接続されてよい。端末装置１００は、送信タイミングに従ってＳＮＭＰ要求をネットワークプリンタに送信することによって、プリンタから状態情報を受信する。そして、端末装置１００は、管理サーバ３００、３２０からのＳＮＭＰ要求に応じて、状態情報を含むＳＮＭＰ応答を管理サーバ３００、３２０に送信してよい。

また、第１のネットワークＩＦは、イーサネット（登録商標）規格に従う有線インタフェースであり、第２のネットワークＩＦは、Ｗｉ−ｆｉ規格に従う無線インタフェースであってよい。逆に、第１のネットワークＩＦは、Ｗｉ−ｆｉ規格に従う無線インタフェースであり、第２のネットワークＩＦは、イーサネット（登録商標）規格に従う有線インタフェースであってよい。また、第１のネットワークＩＦは、Ｗｉ−ｆｉ規格に従う無線インタフェースであり、第２のネットワークＩＦは、Ｗｉ−ｆｉ Ｄｉｒｅｃｔの規格に従う無線インタフェースであってもよい。

（１０）端末装置１００によって受け付けられる状態情報の要求の形式は、ＳＮＭＰ要求の形式に代えて、任意の形式であってよい。例えば、端末装置１００は、専用のプロトコルに従って、管理装置からの状態情報の要求を受け付けてよい。また、端末装置１００は、マークアップ言語（例えば、XML（Extensible Markup Language）など）で記述された要求を受け付けてよい。端末装置１００によって送信される状態情報を含む応答の形式についても、同様に、ＳＮＭＰ応答の形式に代えて、任意の形式であってよい。

（１１）端末装置１００による管理の対象である機能実行装置は、プリンタ２００に代えて、スキャナやファイルサーバなどの特定の機能を実行する任意の装置であってよい。端末装置１００は、スキャナの状態情報（例えば、スキャン回数、エラー情報）や、ファイルサーバの状態情報（例えば、空き容量、エラー情報）を管理してよい。

（１２）上記各実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部あるいは全部をハードウェアに置き換えるようにしてもよい。例えば、図３のＳ２４５の機能を、専用のハードウェア回路によって実現してもよい。

また、本発明の機能の一部または全部がコンピュータプログラムで実現される場合には、そのプログラムは、コンピュータ読み取り可能な記録媒体（例えば、一時的ではない記録媒体）に格納された形で提供することができる。プログラムは、提供時と同一または異なる記録媒体（コンピュータ読み取り可能な記録媒体）に格納された状態で、使用され得る。「コンピュータ読み取り可能な記録媒体」は、メモリーカードやＣＤ−ＲＯＭのような携帯型の記録媒体に限らず、各種ＲＯＭ等のコンピュータ内の内部記憶装置や、ハードディスクドライブ等のコンピュータに接続されている外部記憶装置も含み得る。

以上、実施例、変形例に基づき本発明について説明してきたが、上記した発明の実施の形態は、本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物が含まれる。

１００…端末装置、１１０…ＣＰＵ、１１５…記憶装置、１２０…揮発性記憶装置、１３０…不揮発性記憶装置、１４０…表示部、１５０…操作部、１６０…タイマ、１７０…ＵＳＢインタフェース、１８０…ネットワークインタフェース、２００…プリンタ、２４０…印刷実行部、２５０…情報データベース、３００…第１管理サーバ、３２０…第２管理サーバ、１０００…システム、Ｂ１００…要求応答部、Ｂ１２０…要求分析部、Ｂ１３０…スケジュールタイマ、Ｂ１４０…情報収集部、Ｂ１５０…印刷スプーラ、Ｔ１…状態テーブル、Ｔ２…定期テーブル、Ｔ３…要求テーブル（履歴テーブル）、ＰＧ…コンピュータプログラム、ＮＴ…ローカルエリアネットワーク

Claims (11)

1. 第１種の通信インタフェースと、第２種の通信インタフェースと、を備える通信装置のコンピュータのためのコンピュータプログラムであって、
   前記第１種の通信インタフェースを介して、機能実行装置の状態を示す第１の状態情報の要求である第１の管理要求を管理装置から受信する第１の要求受信機能であって、前記機能実行装置は前記第２種の通信インタフェースを介して前記通信装置と接続される、前記第１の要求受信機能と、
   前記管理装置から前記第１の管理要求を受信した後に、前記第１種の通信インタフェースを介して、前記第１の状態情報の新たな要求である第２の管理要求を前記管理装置から受信する第２の要求受信機能と、
   前記第２種の通信インタフェースを介して前記第１の状態情報を問い合わせるための第１の状態要求を前記機能実行装置に送信する送信タイミングを、前記第１の管理要求の受信のタイミングと前記第２の管理要求の受信のタイミングとの間の第１の期間を利用して決定する決定機能と、
   前記決定された送信タイミングに従って前記第２種の通信インタフェースを介して前記第１の状態要求が前記機能実行装置に送信されることに応じて、前記第１の状態情報を含む情報を前記機能実行装置から受信する第１の状態受信機能と、
   を前記コンピュータに実現させる、コンピュータプログラム。
2. 請求項１に記載のコンピュータプログラムであって、
   さらに、前記第２の管理要求を受信した後に、前記第１種の通信インタフェースを介して、前記第１の状態情報の新たな要求である第３の管理要求を前記管理装置から受信する第３の要求受信機能を、前記コンピュータに実現させ、
   前記決定機能は、前記第３の管理要求が受信される場合に、前記第２の管理要求の受信のタイミングと前記第３の管理要求の受信のタイミングとの間の第２の期間を利用して、前記送信タイミングを決定する、
   コンピュータプログラム。
3. 請求項１または２に記載のコンピュータプログラムであって、
   前記決定機能は、
   前記第１の状態要求が前記機能実行装置に送信されてから、前記機能実行装置からの前記第１の状態情報を含む前記情報が受信されるまでの期間である取得期間を特定し、
   前記第１の期間を利用して前記送信タイミングを決定する場合に、前記送信タイミングを、前記第１の期間に基づいて特定されるタイミングから前記取得期間以上早いタイミングに決定する、
   コンピュータプログラム。
4. 請求項１から３のいずれかに記載のコンピュータプログラムであって、
   前記第１の状態受信機能によって受信される前記情報を、前記コンピュータの記憶装置に格納する格納機能と、
   前記第１種の通信インタフェースを介して前記管理装置から前記第１の状態情報の前記要求が受信される場合に、前記記憶装置に格納済の前記情報のうちの前記第１の状態情報に対応する情報を、前記第１種の通信インタフェースを介して前記管理装置に送信する送信機能と、
   を、前記コンピュータに実現させる、コンピュータプログラム。
5. 請求項４に記載のコンピュータプログラムであって、
   前記第１の要求受信機能は、前記第１種の通信インタフェースを介して要求を受信した場合に、前記要求の送信元が、特定の条件を満たす前記管理装置であるか否かを判断し、
   前記送信機能は、
   前記要求の前記送信元が前記特定の条件を満たす前記管理装置ではないと判断される場合に、前記機能実行装置の状態を示す情報を前記要求の前記送信元に送信せず、
   前記要求の前記送信元が前記特定の条件を満たす前記管理装置であると判断される場合に、前記記憶装置に格納済の前記情報のうちの前記第１の状態情報に対応する情報を前記第１種の通信インタフェースを介して前記管理装置に送信する、
   コンピュータプログラム。
6. 請求項５に記載のコンピュータプログラムであって、
   前記第１の要求受信機能は、前記第１種の通信インタフェースを介して受信した前記要求を解析することによって、前記要求の前記送信元が前記管理装置であるか否かを判断する、
   コンピュータプログラム。
7. 請求項１から６のいずれかに記載のコンピュータプログラムであって、
   前記機能実行装置の特定の項目の状態を問い合わせるための第２の状態要求を前記第２種の通信インタフェースを介して前記機能実行装置に送信するための処理を、前記送信タイミングとは独立に、定期的に、実行する要求実行機能と、
   前記第２の状態要求に応じて前記機能実行装置によって送信される情報であって前記機能実行装置の前記特定の項目の状態を示す第３の状態情報を、前記機能実行装置から受信する第２の状態受信機能と、
   を、前記コンピュータに実現させる、コンピュータプログラム。
8. 請求項１から７のいずれかに記載のコンピュータプログラムであって、
   前記決定機能は、
   第１の管理装置によって要求される状態情報を前記機能実行装置に問い合わせるための状態要求を送信する送信タイミングとして、第１の送信タイミングを決定し、
   前記第１の管理装置とは異なる第２の管理装置によって要求される状態情報を前記機能実行装置に問い合わせるための状態要求を送信する送信タイミングとして、前記第１の送信タイミングとは異なる第２の送信タイミングを決定する、
   コンピュータプログラム。
9. 請求項１から８のいずれかに記載のコンピュータプログラムであって、
   前記第１種の通信インタフェースは、第１の通信規格に従う通信を行うインタフェースであり、
   前記第２種の通信インタフェースは、前記第１の通信規格とは異なる第２の通信規格に従う通信を行うインタフェースである、コンピュータプログラム。
10. 請求項９に記載のコンピュータプログラムであって、
    前記第１の通信規格は、ＩＰ（Internet Protocolの略）であり、
    前記第２の通信規格は、ＵＳＢ（Universal Serial Busの略）である、コンピュータプログラム。
11. 通信装置であって、
    第１種の通信インタフェースと、
    第２種の通信インタフェースと、
    前記第１種の通信インタフェースを介して、機能実行装置の状態を示す第１の状態情報の要求である第１の管理要求を管理装置から受信する第１の要求受信部であって、前記機能実行装置は前記第２種の通信インタフェースを介して前記通信装置と接続される、前記第１の要求受信部と、
    前記管理装置から前記第１の管理要求を受信した後に、前記第１種の通信インタフェースを介して、前記第１の状態情報の新たな要求である第２の管理要求を前記管理装置から受信する第２の要求受信部と、
    前記第２種の通信インタフェースを介して前記第１の状態情報を問い合わせるための第１の状態要求を前記機能実行装置に送信する送信タイミングを、前記第１の管理要求の受信のタイミングと前記第２の管理要求の受信のタイミングとの間の第１の期間を利用して決定する決定部と、
    前記決定された送信タイミングに従って前記第２種の通信インタフェースを介して前記第１の状態要求が前記機能実行装置に送信されることに応じて、前記第１の状態情報を含む情報を前記機能実行装置から受信する第１の状態受信部と、
    を備える、通信装置。

Images