(57)【要約】【課題】  被管理装置の低電力消費状態をなるべく維持することを目的とする。【解決手段】  管理装置１０１と被管理装置１０２の間のホップ数と、被管理装置から電源状態に関する不特定通知の通知先範囲を取得し（Ｓ６０４）、それらに基づいて被管理装置１０２から電源状態に関する不特定通知を受信できるか否かを判断し（Ｓ６０７）、その判断結果に基づいて、被管理装置１０２に個別通知の登録を要求する。【選択図】  図１
2014238762.tif 000002
【特許請求の範囲】
【請求項１】
複数の電源状態を有する１つ以上の被管理装置をネットワークを介して管理する管理装置であって、
前記管理装置と前記被管理装置の間のホップ数を取得する第１取得手段と、
前記被管理装置から電源状態に関する不特定通知の通知先範囲を取得する第２取得手段と、
前記第１取得手段により取得されたホップ数と前記第２取得手段により取得された前記通知先範囲に基づいて前記被管理装置から前記電源状態に関する不特定通知を受信できるか否かを判断する判断手段と、
前記判断手段の判断結果に基づいて、前記被管理装置に個別通知の登録を要求する要求手段と
を有することを特徴とする管理装置。
【請求項２】
前記判断手段は、さらに、前記被管理装置が低電力消費状態において通信処理部による応答処理ができるか否かを判断し、
前記判断手段により前記被管理装置から前記電源状態に関する不特定通知を受信することができず、且つ、前記低電力消費状態において前記通信処理部による応答処理ができないと判断された場合に、前記登録手段は前記被管理装置に前記個別通知の登録を行うことを特徴とする請求項１に記載の管理装置。
【請求項３】
管理対象外とする被管理装置の個別通知の登録を削除する削除手段を有することを特徴とする請求項１または２のいずれかに記載の管理装置。
【請求項４】
前記被管理装置は画像形成装置であることを特徴とする請求項１に記載の管理装置。
【請求項５】
複数の電源状態を有する１つ以上の被管理装置と、前記被管理装置をネットワークを介して管理する管理装置を含む管理システムであって、
前記管理装置は、
前記管理装置と前記被管理装置の間のホップ数を取得する第１取得手段と、
前記被管理装置から電源状態に関する不特定通知の通知先範囲を取得する第２取得手段と、
前記第１取得手段により取得されたホップ数と前記第２取得手段により取得された前記通知先範囲に基づいて前記被管理装置から前記電源状態に関する不特定通知を受信できるか否かを判断する判断手段と、
前記判断手段の判断結果に基づいて、前記被管理装置に個別通知の登録を要求する要求手段とを有し、
前記被管理装置は、
前記管理装置からの電源状態に関する個別通知の登録の要求に応じて、前記管理装置を、前記電源状態に関する個別通知の宛先として登録する登録手段とを有する
ことを特徴とする管理装置。
【請求項６】
前記被管理装置は、
前記管理装置からの情報取得の要求に対して低電力消費状態のまま応答処理できない場合に、通常電力消費状態へ移行する電力制御手段を有し、
前記判断手段は、受信した情報取得要求の内容に基づき、前記管理装置を前記個別通知の宛先として登録するか否かを判断し、
前記管理装置を前記個別通知の宛先として登録すると前記判断手段により判断された場合に、前記登録手段は、前記管理装置を前記電源状態に関する個別通知の宛先として登録することを特徴とする請求項５に記載の管理システム。
【請求項７】
前記被管理装置は、
前記電源状態に関する個別通知の宛先のリストを、最終応答時間に基づいて定期的に更新する更新手段を有することを特徴とする請求項５に記載の管理システム。
【請求項８】
前記被管理装置は画像形成装置であることを特徴とする請求項５に記載の管理システム。
【請求項９】
複数の電源状態を有する１つ以上の被管理装置をネットワークを介して管理する管理装置の制御方法であって、
前記管理装置と前記被管理装置の間のホップ数を取得する第１取得ステップと、
前記被管理装置から電源状態に関する不特定通知の通知先範囲を取得する第２取得ステップと、
前記第１取得ステップにより取得されたホップ数と前記第２取得ステップにより取得された前記通知先範囲に基づいて前記被管理装置から前記電源状態に関する不特定通知を受信できるか否かを判断する判断ステップと、
前記判断ステップの判断結果に基づいて、前記被管理装置に個別通知の登録を要求する要求ステップと
を有することを特徴とする管理装置の制御方法。
【請求項１０】
複数の電源状態を有する１つ以上の被管理装置と、前記被管理装置をネットワークを介して管理する管理装置を含む管理システムの制御方法であって、
前記管理装置が、
前記管理装置と前記被管理装置の間のホップ数を取得する第１取得ステップと、
前記被管理装置から電源状態に関する不特定通知の通知先範囲を取得する第２取得ステップと、
前記第１取得ステップにより取得されたホップ数と前記第２取得ステップにより取得された前記通知先範囲に基づいて前記被管理装置から前記電源状態に関する不特定通知を受信できるか否かを判断する判断ステップと、
前記判断ステップの判断結果に基づいて、前記被管理装置に個別通知の登録を要求する要求ステップとを実行し、
前記被管理装置は、
前記管理装置からの電源状態に関する個別通知の登録の要求に応じて、前記管理装置を、前記電源状態に関する個別通知の宛先として登録する登録ステップを登録する
ことを特徴とする管理システムの制御方法。
【請求項１１】
請求項９または１０に記載の制御方法を少なくとも１つ以上のコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
複数の電源状態を有するデバイスの管理方法に関する。
【背景技術】
【０００２】
プリンタやコンピューターなどの被管理装置を管理する管理装置が前記被管理装置に対して状態情報などの定期的な情報取得要求を行っている場合がある。この要求に対して被管理装置が管理装置に応答するためには、ある程度の電力が装置に供給される必要があり、被管理装置は低電力消費状態を維持することが難しい。
【０００３】
これに対して、低電力消費状態に入る際と低電力消費状態から復帰した際に被管理装置が管理装置に対して電源状態を通知し、それを受信した管理装置は被管理装置が低電力消費状態であれば、情報取得を行わないことで、低電力消費状態を維持する方法が考えられている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−２１５６８６
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、被管理装置が電源状態を通知していても、マルチキャストによる不特定の宛先への電源状態の通知の場合には、ホップ数に対して適切なＴＴＬ値の設定が必要である。前記ＴＴＬ値の設定が適切でないと、管理装置に通知が届かず、低電力消費状態からの復帰が必要となる。また、被管理装置が低電力消費状態を維持したまま管理装置からの定期的な情報取得の要求に応答する方法もあるが、低電力消費状態のまま応答を行うには規定の問い合わせに制約される。
【課題を解決するための手段】
【０００６】
本発明は、複数の電源状態を有する１つ以上の被管理装置をネットワークを介して管理する管理装置であって、前記管理装置と前記被管理装置の間のホップ数を取得する第１取得手段と、前記被管理装置から電源状態に関する不特定通知の通知先範囲を取得する第２取得手段と、前記第１取得手段により取得されたホップ数と前記第２取得手段により取得された前記通知先範囲に基づいて前記被管理装置から前記電源状態に関する不特定通知を受信できるか否かを判断する判断手段と、前記判断手段の判断結果に基づいて、前記被管理装置に個別通知の登録を要求する要求手段とを有することを特徴とする。
【発明の効果】
【０００７】
本発明により、管理装置からの情報取得の要求に対する被管理装置の低電力消費状態からの復帰を最小限に抑えることが可能となる。被管理装置の低電力消費状態をより長く保つことができるようになる。
【図面の簡単な説明】
【０００８】
【図１】システムの全体構成
【図２】システムの詳細なハードウェア構成
【図３】システムの詳細なソフトウェア構成
【図４】被管理装置がマルチキャストで通知するパケットの内容
【図５】被管理装置が通知する電源状態の種類
【図６】（ａ）実施例１のフローチャート（管理装置側）  （ｂ）実施例１のフローチャート（被管理装置側）  （ｃ）管理装置側の削除要求に関する実施例１のフローチャート
【図７】管理対象リスト
【図８】ＰＩＮＧのパケットの内容
【図９】ＮＩＣで応答可能なパターン
【図１０】管理装置からの個別通知登録するパケット
【図１１】（電源状態）個別通知リスト
【図１２】被管理装置が個別通知するパケットの内容
【図１３】管理装置から発呼される個別通知リストからの削除要求パケット
【図１４】実施例２におけるシステムの詳細なソフトウェア構成
【図１５】実施例２における被管理装置の個別通知に対する管理装置の応答パケット
【図１６】実施例２における応答時間付の個別応答リスト
【図１７】実施例３における通信制御部での処理のフローチャート
【図１８】実施例３における本体での処理のフローチャート
【図１９】管理系リスト
【図２０】定期更新のフローチャート
【発明を実施するための形態】
【０００９】
以下、本発明を実施するための最良の形態について図面を用いて説明する。なお、特に動作の主体が記載されていない場合には、各装置の各部におけるＣＰＵ（コンピュータ）が動作の主体となる。
【実施例１】
【００１０】
図１は、本発明を実施するための管理システム全体の構成図である。管理装置１０１はネットワーク１０３を介してプリンタなどの被管理装置１０２と接続されている。管理装置１０１は、画像形成装置である被管理装置１０２に対して、定期的に印刷状態などの情報取得を行う。被管理装置１０２は、後述するマルチキャストやブロードキャストなどで、不特定宛先に対して電源状態通知を行う。なお、この不特定宛先に対する通知を不特定通知とよぶ。前記電源状態通知を受信する管理装置１０１は、被管理装置が低電力消費状態の場合には、情報取得を抑制する。これによって、印刷処理など必要に応じて被管理装置を低電力消費状態から通常電力消費状態へ復帰させることができる。ここでいう情報取得ではＳＮＭＰなどの装置管理用のプロトコルを用いる。なお、管理装置１０１（ａ）と被管理装置１０２（ａ）及び１０２（ｂ）の間には１つのルーター１０４が存在し、管理装置１０１（ｂ）と被管理装置１０１の間にはルーターが存在しない例を示している。被管理装置１０１からの電源状態通知のＴＴＬ値の指定が０の場合には、管理装置１０１（ｂ）には通知が届くが、管理装置１０１（ｂ）には通知が届かないことになる。ここでいうＴＴＬ値とは、パケットの有効期間を表す値で、最大２５５までの整数値で表され、ルーターなどを１回経由されるたびに値が１減少する。ＴＴＬが０になったパケットはその時点で廃棄される。
【００１１】
図２は、本発明を実施するためのシステム全体のハードウェア構成図である。図２の管理装置１０１のＣＰＵ２０１は本発明に関するプログラムをＨＤＤ２０３からメモリ２０２にロードし、前記プログラムを実行する。出力装置２０５は前記プログラムの実行に必要な管理対象の被管理装置のＩＰアドレスなどの情報入力画面を表示する。入力装置２０４は前記出力装置２０５に表示された内容に対するユーザーからの入力を受け付ける。ＮＩＣ（通信制御部）２０６はパケット送受信を行う。
【００１２】
図２の被管理装置１０２は、本体制御部２１０、通信制御部２２０、電源制御部２３０で構成されている。印刷を行うなど本体制御部２０１の機能を使う場合は、被管理装置１０２の本体制御部２１０と通信制御部２２０に通電される通常電力消費状態となるように電力制御部２３０が電力制御を行う。一方、本体制御部２１０の機能を使わない場合には、本体制御部２１０の主要部への電源供給を遮断し、本体制御部２１０のＵＩ操作部２１３の一部（非図示の電源ボタン）と通信制御部２２０にのみ通電された低電力消費状態となるように電源制御部２３０が電力制御を行う。本体制御部２１０のＣＰＵ２１１は本発明に関するプログラムをＨＤＤ２１４からメモリ２１２にロードし、前記プログラムを実行する。ＵＩ操作部２１３は、後述するＴＴＬ値などのデバイス設定情報をユーザーから受け付け、ＨＤＤ２１４に格納する。通信制御部２２１のＣＰＵ２２１は本発明に関するプログラムをＲＯＭ２２２からＲＡＭ２２３にロードし、前記プログラムを実行する。ＮＩＣ２２４はパケット送受信の処理を行う。なお、電力制御部２１０は、上記の２種の電源状態にとどまらず、３種以上の複数の電源状態で段階的な電力制御をおこなってもよい。
【００１３】
図３は本発明を実施するためのソフトウェア構成図である。管理装置１０１のＩＣＭＰ送受信部３０１は、ＩＣＭＰプロトコルでＰＩＮＧパケットの送受信を行う。ここでいうＩＣＭＰとは、ＩＰのエラーメッセージや制御メッセージを転送するプロトコルで、ＴＣＰ／ＩＰで接続されたコンピューターやネットワーク機器間で、互いの状態を確認するために用いられる。デバイス設定取得部３０２は、被管理装置１０２からマルチキャストでの電源状態通知のＴＴＬ値を取得し、被管理装置１０２の通信制御部２２０で管理装置１０１からの要求への応答を行うための後述のＮＩＣ応答パターンの取得を被管理装置１０２から行う。通知登録・削除部３０３は被管理装置１０２の個別通知リストへの登録要求と削除要求を行う。デバイス情報取得部３０４は、被管理装置１０２に状態取得要求を定期的に行うが、被管理装置１０２の電源状態が低電力消費状態の場合には情報取得要求を行わない。電源状態受信部３０５は、被管理装置１０２から後述する電源状態通知の受信を行う。通信処理部３０６は、パケット送受信を制御する。
【００１４】
被管理装置１０２の電源制御部３３０は、本体制御部２１０で行う処理がない場合には、本体制御部２１０の通電を遮断する。また、電源制御部３３０は本体制御部２１０で行う処理が発生した場合には、本体制御部２１０の通電を開始する。本体制御部２１０の電源状態通知部３２４は、電源状態が変化する際、すなわち本体制御部２１０の通電が遮断される際と通電状態に戻った際に、本体制御部２１０のメモリ２１２にあるマルチキャストで用いるＴＴＬ値の設定値を参照して、マルチキャストでの電源状態通知パケットを作成する。前記で作成した電源状態通知パケットを通信処理部３１０が送信する。マルチキャストでの電源状態通知パケットは図４のようなマルチキャストアドレス、ＴＴＬ値、電源状態を示す属性を含む構成となっている。図５に被管理装置１０２が通知する電源状態の通知内容を示す。通電が遮断された場合には、「ＳＬＥＥＰ」を図４の電源状態を示す属性に入れて通知し、通電状態に戻る場合には、図４の電源状態を示す属性に「ＷＡＫＥＵＰ」を入れて通知する。また、電源状態通知部３２４は管理装置１０１に後述するユニキャストでの個別宛先への電源状態通知も行う。なお、この個別宛先に対する通知を個別通知とよぶ。情報取得応答部３２３は、管理装置１０１からのデバイス情報の取得要求に対する応答を行う。ＩＣＭＰ応答部３２０は、管理装置１０１からのＰＩＮＧパケットの要求に応じて、返信を行う。その際、使用するＴＴＬ値は被管理装置１０２に設定されたＰＩＮＧ用のＴＴＬ値を用いる。設定取得応答部３２１は、管理装置１０１のＴＴＬ値、ＮＩＣ応答パターンなどの設定情報の取得に応答する。通知登録・削除部３２２は、管理装置１０１からの個別通知リストへの登録要求と削除要求に基づき、個別通知リストに電源状態の個別通知先の登録及び削除を行う。個別通知については後述する。通信制御部２２０の通信処理部３１０は、管理装置１０１とのパケット送受信を行う。ＮＩＣ応答部３１１は、管理装置１０１からの情報取得要求に対して、後述するＮＩＣ応答パターンにより、本体制御部２１０を用いずに管理装置１０１への応答パケットを作成する。つまり、登録されたＮＩＣ応答パターンであれば、本体制御部２１０に通電することなく、管理装置１０１に応答を行うことができる。
【００１５】
図６は本発明を実施するためのフローチャートである。図６（ａ）は管理装置側の処理のフローチャートである。図６（ｂ）は被管理装置側の処理のフローチャートである。図６（ｃ）は管理対象から外れた際の管理装置側の処理のフローチャートである。図６を用いて、処理の流れについて説明する。管理装置１０１は、図７で示す管理対象リスト７０１で被管理装置１０２を管理している。管理対象リスト７０１には、管理対象のＭＡＣアドレス、ＩＰアドレス、被管理装置名、被管理装置が印刷可能かを否か示す状態、被管理装置の電源状態を含む。入力装置２０４から入力された被管理装置１０２のＩＰアドレスなどの情報が管理対象リスト７０１に登録されると、図６のステップＳ６０１において、管理装置１０１は、ＩＣＭＰ送受信部３０１において、ＰＩＮＧ送信パケットを生成する。前記で生成されたＰＩＮＧ送信パケットは通信処理部３０６によってネットワーク１０３を介して被管理装置１０２に送信される。送信されるＰＩＮＧパケットは図８のようにＴＴＬ値を含み、ＴＴＬ値はルーターを１つ越えるごとに１つずつ減っていく。ステップ６０２において、被管理装置１０２から返信されるＰＩＮＧ返信パケットを受信したか否かを判断する。被管理装置からＰＩＮＧ返信パケットを受信できた場合には、ステップＳ６０３において、ＩＣＭＰ送受信部３０１は受信したパケットからＴＴＬ値を取り出し、メモリ２０２上に格納する。次にステップＳ６０４において、デバイス設定取得部３０２は、被管理装置１０２にマルチキャストのＴＴＬ値、ＰＩＮＧのＴＴＬ値の規定値の取得要求を行う。なお、このマルチキャストのＴＴＬ値が、不特定通知の通知先範囲に相当し、該通知範囲を取得する動作が第２取得に相当する。ステップＳ６０５において、デバイス設定取得部３０２は、被管理装置１０２からＴＴＬ値の取得要求の応答があったか否かを判断し、応答があった場合には、ステップＳ６０６に移行する。ステップＳ６０６において、通知登録・削除部３０３は、被管理装置１０２から取得したＰＩＮＧのＴＴＬ値の規定値からステップＳ６０３で格納したＴＴＬ値を引くことにより、経由したルーターの数、すなわち管理装置１０１と被管理装置１０２の間のホップ数を算出する。この動作が第１取得に相当する。さらにステップＳ６０７において、通知登録・削除部３０３は、ステップＳ６０４で取得したマルチキャストのＴＴＬ値と比較して、被管理装置１０２が送信するマルチキャストの電源状態通知を管理装置１０１が受信可能か否かを判断する。ステップＳ６０６でマルチキャストの電源状態通知を管理装置１０１が受信できるという判断結果であった場合には、処理を終了する。ステップＳ６０６でマルチキャストの電源状態通知を管理装置１０１が受信できないと判断した場合には、ステップＳ６０８に移行する。
【００１６】
ステップＳ６０８において、デバイス設定取得部３０２は、被管理装置１０２のＮＩＣ応答部３１１が有するＮＩＣ応答パターン取得の要求を行う。前記ＮＩＣ応答パターンは図９に示す構成で、受信するパケットのパターンと受信したパターンに対応する応答パケットが記載されている。例えば、図９の表９０１のＩＤ１に一致するパケットを被管理措置１０２が受信した場合には、表９０２のＩＤ１の構成でパケットをＮＩＣ応答部３１１が管理装置１０１に送信する。ステップＳ６０２及びステップＳ６０５で一定時間以内に返信パケットを受信しなかった場合にも、ステップＳ６０８へ移行する。ステップＳ６０９において、通知リスト登録・削除部３０３は、被管理装置１０２からＮＩＣ応答パターンを取得できたか否かを判断し、取得できなった場合には、ステップＳ６１１に移行する。ステップＳ６０９において、ＮＩＣ応答パターンを取得できた場合には、ステップＳＳ６１０に移行する。ステップＳ６１０において、通知リスト登録・削除部３０３は、管理装置１０１が送信する被管理装置１０２に対する情報取得のパケットがＮＩＣ応答パターンと一致するかを判断する。これは、被管理装置１０２が低電力消費状態を維持したたま、通信処理部のみによる応答処理ができるか否かを判断することに相当する。ステップＳ６０９において、ＮＩＣ応答パターンと一致すると判断された場合には、処理を終了する。ステップＳ６１０において、ＮＩＣ応答パターンと一致しないと判断した場合には、ステップＳ６１１に移行する。ステップＳ６１１において、通知リスト登録・削除部３０３は、被管理装置１０２に対して電源状態の個別通知登録要求を行う。前記の個別通知登録要求は図１０に示す電源状態通知登録用の属性を含むＳＬＰのパケットで行う。
【００１７】
被管理装置１０２は、図６（ｂ）のステップ６２１において、ステップＳ６１１において管理装置１０１が送信した電源状態の個別通知に関する要求を受信する。ステップＳ６２２において、受信した個別通知に関する要求が登録要求か削除要求かを判定し、登録要求の場合には、ステップＳ６２３において、通知リスト登録・削除部３２２は、被管理装置１０２の図１１の個別通知リスト１１０１に、その要求の送り元である管理装置のＩＰアドレスを通知先ＩＰアドレスとして格納する。一方、削除要求の場合には、ステップＳ６２４において、通知リスト登録・削除部３２２は、被管理装置１０２の図１１の個別通知リスト１１０１から、その要求の送り元である管理装置のＩＰアドレスを削除する。なお、管理装置１０１は、管理対象リスト７０１から被管理装置を削除することにより被管理装置を管理対象外にした場合に、該被管理装置へ電源状態の個別通知の削除要求を送信する。
【００１８】
個別通知リスト１１０１はＨＤＤ１０２などの不揮発性記憶領域に格納されるため、電源断後に被管理装置１０２を再起動された後も、電源状態は個別通知リスト１１０１により通知されることになる。
【００１９】
被管理装置１０２において電源状態が変化した場合には、電源状態通知部３２４は、図４の４０１に示すマルチキャストの電源状態通知を行うとともに、図１１の個別通知リスト１１０１に格納された通知先ＩＰアドレスごとに、図１２に示すように宛先指定での電源状態通知を管理装置１０１に送信する。被管理装置１０２が通知する電源状態通知は図５で示した内容と同様で、通常電力消費状態から低電力消費状態へ移行する際には、「ＳＬＥＥＰ」を、低電力消費状態から通常電力消費状態へ復帰した際には「ＷＡＫＥＵＰ」を通知する。
【００２０】
電源状態通知を受信した管理装置１０１は、図７の管理対象リスト７０１において該当する被管理装置１０２の電源状態を更新する。管理装置１０１は、被管理装置１０２に定期的な情報取得要求を行う前に、管理対象リストの電源状態を確認し、電源状態がＳＬＥＥＰのときには情報取得要求を行わず、電源状態がＳＬＥＥＰでないときに、情報取得要求を行うように制御する。これによって、低電力消費状態の場合には、被管理装置１０２に情報取得要求を行わないことになり、被管理装置１０２の低電力消費状態を長く保つことができるようになる。
【００２１】
また、図６（ｃ）のステップＳ６３１において、被管理装置１０２が管理対象リスト７０１から削除されたか否かを判断し、削除されたと判断した場合には、ステップＳ６３２に移行する。ステップＳ６３２において、通知リスト登録・削除部３０３は、図１３で示した削除の属性を有するパケットを削除要求として被管理装置１０２に送信する。削除要求を受信した被管理装置１０２は、ステップＳ６２２において、削除要求か否かを判断する。前記ステップで削除要求と判断した場合には、ステップＳ６２４において、通知登録・削除部３２２は、図１１の個別通知リスト１１０１から管理装置１０１を削除する。これによって、不揮発性の記憶装置に格納された個別通知リスト１１０１を実際の管理状況に合わせて更新することができ、不要な電源状態通知を抑制することが可能となる。
【実施例２】
【００２２】
次に実施例２の説明を行う。実施例２は、実施例１とネットワーク構成及びハードウェア構成は同じである。図１４に実施例２のソフトウェア構成を示す。実施例１のソフトウェア構成に対して、被管理装置１０２では通知リスト定期更新部３２５をさらに設けて、個別通知リストの定期的な更新を行えるようにする。また、図１１の個別通知リスト１１０１に対して、図１６の個別通知リスト１６０１に示すように電源状態通知に対する管理装置からの応答を受信した応答時間の記録を行えるようにする。図２０は個別通知リスト１６０１の定期的な更新を行うためのフローチャートである。実施例２では、管理装置１０１が被管理装置１０２から電源状態の変化による電源状態通知を受信した場合には、管理装置１０１は電源状態受信・応答部３０５によって、図１５に示す応答を被管理装置１０２に送信する。前記応答を受信した被管理装置１０２において、図１６に示す個別通知リスト１６０１に応答を受信した日時を最終応答時間に上書きする。
【００２３】
図１９は個別通知リスト１６０１の定期更新のフローチャートである。被管理装置１０２に定義された間隔で定期更新の処理が開始されると、図１９のステップＳ２００１において、個別通知リスト１６０１から削除するか否かに関する被管理装置１０２の規定時間の取得を行う。前記図１９のステップＳ２００２において、被管理装置１０２は個別通知リスト１６０１上の最終応答時間を確認し、前記ステップＳ２００２で取得した規定時間を過ぎている管理装置１０１があれば個別通知リスト１６０１から削除する。これによって、管理装置１０１から削除要求が発生しない場合にも個別通知リスト１６０１の登録が必要以上に増えることを防ぐことが可能となる。
【実施例３】
【００２４】
実施例３は、実施例１及び実施例２とネットワーク構成、ハードウェア構成、ソフトウェア構成は同じである。ただし、管理装置１０１からの情報取得要求に対して、被管理装置１０２の通信制御部２２０が応答できなった場合に、被管理装置１０２の本体制御部２１０において電源状態の個別通知先を登録する点が異なる。
【００２５】
実施例３の処理の流れについてフローチャートを用いて説明する。まず、図１７を用いて被管理装置１０２の通知制御部２２０での処理の流れについて説明する。管理装置１０１から情報取得要求を受信した場合、ステップＳ１７０１において、ＮＩＣ応答パターン（図９）に該当するかを確認する。ステップＳ１７０２でＮＩＣ応答パターンに該当すると判断された場合には、ステップＳ１７０４に移行する。ステップＳ１７０４では、被管理装置１０２のＮＩＣ応答部３１１は、ＮＩＣ応答パターン（図９）に基づき、管理装置１０１に応答を行う。ステップＳ１７０２でＮＩＣ応答パターンに該当しないと判断された場合には、ステップＳ１７０３に移行する。ステップＳ１７０３において、電源制御部３３０に本体制御部２１０への通電を要求する。通電を要求された電源制御部３３０は、本体制御部２１０への通電を行うことにより本体制御部２１０を励起する。通知制御部２２０は通電された本体制御部２１０に受信したパケット情報を送る。
【００２６】
次に前述のステップＳ１７０３で励起された後の本体制御部２１０の処理の流れについて図１８のフローチャートを用いて説明する。パケット受信により励起された本体制御部２１０は、ステップＳ１８０１において、通知リスト登録・削除部３２２により、ネットワークからのパケット受信で励起したか否かの判断を行う。ステップＳ１８０１で、ネットワークからのパケット受信による励起ではないと判断した場合には、処理を終了する。ネットワークからのパケット受信で励起したと判断した場合には、ステップＳ１８０２に移行する。ステップＳ１８０２において、通知リスト登録・削除部３２２は、受信したパケットの内容が管理系であるか否かをポート番号等で判断する。例えば、図１９の管理系のポート番号のリストを用いて受信したパケットが管理系のパケットであるか否かを判断する。ステップＳ１８０２で管理系のパケットでないと判断した場合には、処理を終了する。ステップＳ１８０２で管理系のパケットであると判断した場合には、ステップＳ１８０３に移行する。ステップＳ１８０３では、通知リスト登録・削除部３２２は、図１１または図１６の電源状態の個別通知リストに通知先として登録されているか否かを判断し、前記個別通知リストに通知先として登録されていると判断した場合には、処理を終了する。また、ステップＳ１８０３の判断で、前記個別通知リストに登録されていないと判断した場合には、ステップＳ１８０４に移行する。ステップ１８０４において、通知リスト登録・削除部３２２は、個別通知リストに管理装置１０１の登録を行う。最後に、ステップＳ１８０５において、情報取得応答部３２３は管理装置１０１からの情報取得要求への応答パケットを作成し、管理装置１０１に通信処理部３１０を通じて応答を行う。実施例３によって、管理装置１０１の要求による個別通知の登録がされずに、管理装置１０１からの情報取得要求が為された場合にも、個別通知を行うことができるようになる。また、印刷要求などで励起した場合には、個別通知リストに登録する必要がないので、管理系のパケットか否かを判断（ステップ１８０２）することによって、不要な登録を軽減することができる。
【図１】
2014238762.tif 000003
【図２】
2014238762.tif 000004
【図３】
2014238762.tif 000005
【図４】
2014238762.tif 000006
【図５】
2014238762.tif 000007
【図６】
2014238762.tif 000008
【図７】
2014238762.tif 000009
【図８】
2014238762.tif 000010
【図９】
2014238762.tif 000011
【図１０】
2014238762.tif 000012
【図１１】
2014238762.tif 000013
【図１２】
2014238762.tif 000014
【図１３】
2014238762.tif 000015
【図１４】
2014238762.tif 000016
【図１５】
2014238762.tif 000017
【図１６】
2014238762.tif 000018
【図１７】
2014238762.tif 000019
【図１８】
2014238762.tif 000020
【図１９】
2014238762.tif 000021
【図２０】
2014238762.tif 000022