JP2010063090A - 制御装置、画像処理装置、制御方法およびプログラム - Google Patents

Abstract

【課題】機器の省電力状態からの復帰を出来るだけ少なくして電力消費を抑制することができる制御装置および制御方法を提供する。
【解決手段】この制御装置は、外部装置からイベント監視リクエストを受け付け、イベントが発生した場合に該イベントを通知する機器に用いられるものである。この制御装置は、外部装置から有効期間を有するイベント監視リクエストを受信したことに応答して、機器内の各デバイスの電源状態を確認し、機器が省電力状態へ移行するか否かを判断する判断手段と、移行すると判断された場合に、外部装置へ有効期間を延長したレスポンスを返し、延長した有効期間に基づき再監視リクエストを送信させる通知手段とを備える。
【選択図】図３

Description

本発明は、省電力状態にある機器がネットワークを通じてリクエストを受けることにより省電力状態から復帰する回数を減少させて省電力化を図るために当該機器に組み込まれる制御装置、その制御方法、その制御方法を実現するためのコンピュータ読み取り可能なプログラム、さらにはその制御装置が組み込まれた画像処理装置に関する。

近年、限りあるエネルギー資源の大量消費を抑制し、地球温暖化等の自然環境の悪化を防止するべく、省エネ対応の機器が多く出現している。ＰＣやＭＦＰ（ＭｕｌｔｉＦｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）においても、省エネモードを備えたものが数多く出現し、そのような機器では、ある期間ジョブ処理が行われない場合、省電力状態へ移行するように設定されている。省電力状態へ移行した機器は、ネットワークからリクエストを受け付け、ジョブを処理する必要が生じた場合、省電力状態から復帰する。

省エネモードにおける省電力状態への移行は、現状のパラメータ等をメモリに保存したまま、ＣＰＵやＨＤＤ等のほとんどのデバイスへの電源供給を停止することにより行われる。このとき、ＯＳが起動した状態のデータを保持しているので、復帰時にＯＳは再起動されず、サスペンド前の状態にそのまま復帰することができる。

省エネモードにおいて電源供給が停止されたモジュール数が多いほど、省電力状態から復帰するのに時間を要する。また、製品を構成するハードウェアモジュールとソフトウェアモジュールとが密接に関係していることから、機種毎に復帰時間が異なる。このため、複数の機器がネットワークに接続されたネットワーク環境において、機器の接続状態や動作状態を検索するクライアント装置で、検索応答時間の上限であるタイムアウト時間を一意に決定することはできない。このタイムアウト時間を短く設定すると、タイムアウト時間内に省電力状態から復帰できなかった機器が検索結果に表示されなくなってしまう。

一方、タイムアウト時間を長く設定すると、検索対象の機器が存在しなかった場合であっても、それを判定しなければならず、余計な時間がかかってしまう。

そこで、省エネモードへの移行前に、当該省エネモードからの復帰時間を特定可能な情報を、ネットワークを介して接続される情報処理装置へ通知し、その情報処理装置は、省エネモード搭載装置へ起動要求を送信した後、復帰時間の経過後に、処理要求を省エネモード搭載装置へ送信する技術が提案されている（特許文献１参照）。この技術により、情報処理装置が、省エネモードを備える他の機器と通信するにあたって、他の機器が省エネモードであった場合でも、省エネモードからの復帰時間を考慮して、より効率良く通信することができる。

ネットワークを通じて機器がイベント監視リクエストを受信すると、その機器においてイベントが発生した際に、そのリクエストを送信したイベント監視先にイベントを通知する。このとき機器は、複数のイベント監視先からのイベント監視リクエストをイベント管理テーブル等により管理することができる。Ｗｅｂサービス上で使われるＷＳ−Ｅｖｅｎｔｉｎｇプロトコルは、このイベントの登録および通知のために使用するプロトコルである。ＷＳ−Ｅｖｅｎｔｉｎｇでは、最初の監視リクエストのコマンドをＳｕｂｓｃｒｉｂｅと呼び、２回目以降の監視リクエストのコマンドをＲｅｎｅｗと呼ぶ。イベント管理テーブル等にはイベント監視先ごとに有効期間を設定することができる。これは、有効期間が切れたイベント監視先を削除することで、イベント監視のための機器のリソースを有効に使用することが目的である。よって、イベント監視先は、有効期間が満了する前に再度監視リクエストを送ることで、有効期間の更新を行う。なお、機器の監視に限らず、ネットワークから通知されるリクエストには有効期間という概念が存在しがちである。

このような監視リクエストは、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａが搭載されたＰＣでは３０分に１回ほど送信されるため、機器が省電力状態へ移行してもすぐに復帰してしまうことになり、省エネの点から好ましくはない。

また、機器が属するネットワークで、ＤＨＣＰサーバによりＩＰアドレスの割り当てを実施している場合が多々ある。この場合、ＩＰアドレスを有効に利用するため、一般的にリース期間が設定され、その期間は約２〜８時間を目安に設定されることが多い。これは、１日の作業時間を目安に設定されるからである。これもまた、省電力状態からの復帰が必要となる。

機器がＩＰｖ６環境下に属する場合、ステートレスＩＰｖ６アドレスが使用されることが多い。このアドレスは、他のネットワークと接続するためのルータからのＲＡ（Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ）のプレフィックスを基に、その機器で作成される。ＲＡは、ルータから定期的に送信されるマルチキャストパケットであり、数時間に１回送信される。したがって、これもまた、省電力状態からの復帰が必要となる。

そこで、機器の省電力状態からの復帰を出来るだけ少なくして電力消費を抑制することができる装置および方法が望まれている。

本発明は、上記課題を解決するために、イベント監視リクエストや再監視リクエストを受けたときのレスポンスの有効期間を調整し、再監視リクエストを受ける回数を減らす。これにより、機器の省電力状態からの復帰を少なくして電力消費を抑制することができる。

すなわち、本発明によれば、外部装置からイベント監視リクエストを受け付け、イベントが発生した場合に該イベントを通知する機器に用いられ、イベント監視を制御する制御装置であり、外部装置から有効期間を有するイベント監視リクエストを受信したことに応答して、機器内の各デバイスの電源状態を確認し、機器が省電力状態へ移行するか否かを判断する判断手段と、移行すると判断された場合に、外部装置へ有効期間を変更したレスポンスを返し、変更した有効期間に基づき再監視リクエストを送信させる通知手段とを備える、制御装置が提供される。

監視リクエストおよび再監視リクエストは、いつどこから来るかわからず、有効期間を延長しても、ランダムに監視リクエストが来て、省電力状態から復帰してしまう可能性がある。そこで、通知手段は、複数の外部装置から送信される再監視リクエストの受信時刻がすべて同じ時刻になるように各有効期間を調整し、各調整された有効期間を有するレスポンスを各外部装置へ返すように構成する。これにより、省電力状態からの復帰タイミングを集中させ、省電力状態からの復帰回数を減らすことができる。

イベント監視先が多数存在する場合、すべて同じ時刻になるように有効期間を延長すると、多数のイベント監視先が同時に機器へアクセスすることになり、ある再監視リクエストではセッションタイムアウト等が発生し、再監視が成立しないおそれがある。そこで、通知手段は、複数の外部装置から送信される再監視リクエストの受信時刻が予め設定された時間間隔でずれるように各有効期間を調整し、各調整された有効期間を有するレスポンスを各外部装置へ返すように構成する。これにより、再監視が確実に成立するようにすることができる。

また、通知手段は、省電力状態への移行に応答して、外部装置に省電力状態移行イベントを通知し、外部装置からイベント監視リクエストを送信させないようにすることができる。これにより、再監視リクエストによる省電力状態からの復帰が行われなくなり、機器の電力消費を抑制することができる。

通知手段は、機器が何らかの要因で省電力状態から復帰したことに応答して、外部装置に省電力状態解除イベントを通知し、イベント監視リクエストを送信させることができる。これにより、再監視リクエストを再開することができる。

本発明によれば、上記の制御装置を備える、外部装置と通信を行う省電力状態へ移行可能な画像処理装置、上記の制御装置によりイベント監視を制御する方法、その方法を実現するためのコンピュータにより読み取り可能なプログラムを提供することもできる。

この制御方法は、外部装置から有効期間を有するイベント監視リクエストを受信したことに応答して、機器内の各デバイスの電源状態を確認し、機器が省電力状態へ移行するか否かを判断するステップと、移行すると判断された場合に、外部装置へ有効期間を変更したレスポンスを返し、変更した有効期間に基づき再監視リクエストを送信させるステップとを含む。

また、この方法は、上記制御装置が備える各手段により行われる処理を処理ステップとして含むほか、機器の異常を検知するステップと、外部装置からの問い合わせに対し、レスポンスを返さないことで外部装置にイベント監視を中止させるステップとをさらに含むことができる。

本発明によれば、機器の省電力状態からの復帰を出来るだけ少なくして電力消費を抑制することができる。

第一の実施の形態におけるネットワークに接続された複数の機器からなるネットワークシステムを例示した図。 第一の実施の形態における機器のソフトウェア構成およびハードウェア構成を例示した図。 ネットワーク制御部および電源管理部の構成を例示した図。 ＷＳ−ＥｖｅｎｔｉｎｇプロトコルにおけるＳｕｂｓｃｒｉｂｅリクエストのメッセージを例示した図。 ＳｕｂｓｃｒｉｂｅＲｅｓｐｏｎｓｅのメッセージを例示した図。 ＳｕｂｓｃｒｉｂｅＲｅｓｐｏｎｓｅの別のメッセージを例示した図。 Ｓｕｂｓｃｒｉｂｅリクエストに対するイベントが発生したときの通知メッセージを例示した図。 ＳｕｂｓｃｒｉｂｅリクエストおよびＲｅｎｅｗリクエストを受けたときのＳｕｂｓｃｒｉｂｅｒとイベントを発生する機器との間の処理およびその機器の内部で行われる処理の流れを示したシーケンス図。 イベント発生時に行われる機器の内部シーケンスおよび外部シーケンス図。 イベント管理部が保持するイベント管理テーブルを例示した図。 ＳｕｂｓｃｒｉｂｅリクエストおよびＲｅｎｅｗリクエストに対する処理と、省電力状態移行イベントの通知と省電力状態解除イベントの通知を行う処理の流れを示したシーケンス図。 省電力状態の間、Ｓｕｂｓｃｒｉｂｅｒから機器状態の問い合わせを行う処理の流れを示したシーケンス図。 複数のＳｕｂｓｃｒｉｂｅｒからのＲｅｎｅｗリクエストの受信時刻がほぼ同じになるように有効期間を調整するようＲｅｎｅｗリクエストを同期させ、Ｒｅｎｅｗリクエストによる省電力状態からの復帰タイミングを減少させる例を示した図。 各タイミングにおけるイベント管理テーブルを例示した図。 複数のＳｕｂｓｃｒｉｂｅｒからのＲｅｎｅｗリクエストの受信時刻がわずかにずれるように有効期間を調整し、Ｒｅｎｅｗリクエストによる省電力状態からの復帰タイミングを減少させる例を示した図。 各タイミングにおけるイベント管理テーブルを例示した図。 有効時間を決定後にレスポンスを生成して返す処理の流れを示した図。 複数のＳｕｂｓｃｒｉｂｅｒからのＲｅｎｅｗリクエストの受信時刻がほぼ同じになるように有効時間を調整するようＲｅｎｅｗリクエストを同期させる場合と、Ｒｅｎｅｗリクエストをわずかにずらす場合の処理の流れを示した図。 機器の監視を行う側のモジュール構成を例示した図。 機器の監視を行う側が実行する処理の流れを例示した図。 第二の実施の形態のネットワークシステムの構成例を示す図。 第二の実施の形態における機器のソフトウェア構成およびハードウェア構成を例示した図。 プロバイダアプリによるウィジェットの検索処理の処理手順を説明するためのシーケンス図である。

図１は、第一の実施の形態におけるインターネットやイントラネット等のネットワークに接続された複数の機器からなるネットワークシステムを例示した図である。図１では、複数のＰＣ１０〜１６と機器１７とが通信可能とされており、例えば、ＰＣ１０〜１６が機器１７に対してリクエストを送り、機器１７がそのリクエストに対するレスポンスを返している。

ＰＣ１０〜１６が送るリクエストは、イベントが発生したときに通知するよう要求するイベント監視リクエストや監視対象となるイベントを登録するためのイベント登録リクエスト、イベント監視のための有効期間の満了前に出されるイベント再監視リクエスト等がある。イベントは、機器の省電力状態への移行や復帰、エラーの発生等で通知されるものである。ＰＣ１０〜１６は、機器１７で発生するイベントを監視するために、機器１７に対し、イベント登録リクエストおよび監視リクエストを送る。

ＰＣ１０〜１６は、リクエストを送り、そのリクエストに対するレスポンスを受け取るためのプログラムを格納するメモリと、メモリからそのプログラムを読み出し実行するプロセッサと、ネットワークに接続し、ネットワークとのデータ通信を行うネットワークＩ／Ｆとを含み、その他に、データ等を入力するための入力装置、作業内容や現在の状況等を表示するための表示装置を備える。

ここでは、機器１７以外を、ＰＣ１０〜１６としたが、ＰＣに限られるものではなく、ネットワークを介して通信を行うことができる装置であればいかなる装置であってもよく、ＭＦＰ等の画像形成装置とすることもできる。

図２を参照して、機器１７のソフトウェア構成およびハードウェア構成について説明する。ソフトウェア構成は、アプリケーション部と、プラットフォーム部とに大きく分けることができる。アプリケーション部は、プリンタ、コピー、ファックス、スキャナ等の画像形成処理に関連するユーザサービスに固有の処理を行うものとされている。アプリケーション部は、ページ記述言語およびプリンタ用のアプリケーションであるプリンタアプリ２０と、コピー用のアプリケーションであるコピーアプリ２１と、ファクシミリ用のアプリケーションであるファックスアプリ２２と、スキャナ用のアプリケーションであるスキャナアプリ２３と、ネットワークファイル用のアプリケーションであるネットファイルアプリ２４とを有している。

プラットフォーム部は、アプリケーションから共通して利用される基本的機能を提供し、機器全体の管理を行うＯＳ、そのＯＳの基本機能を実装したカーネルとからなるＯＳ／Ｋｅｒｎｅｌ３０と、アプリケーション部からの処理要求を解釈してハードウェア等の各種リソースの獲得要求を発生する各種制御部とから構成される。ＯＳ／Ｋｅｒｎｅｌ３０には、ＩＰアドレスとポート番号とを組み合わせたソケット以下のネットワーク処理部も存在している。各種制御部は、システム制御部３１、メモリ制御部３２、エンジン制御部３３、ファックス制御部３４、オペレーション制御部３５、配信制御部３６、ネットワーク制御部３７、セキュリティ制御部３８、電源管理部３９等から構成される。

プラットフォーム部は、予め定義されている関数によりアプリケーション部からの処理要求を受信可能とするアプリケーションプログラムインタフェース（ＡＰＩ）４０を有するように構成されている。

プラットフォーム部が備えるシステム制御部３１は、アプリケーションの管理、操作部の制御、システム画面の表示、ＬＥＤの表示、ハードウェアリソースの管理、割り込みアプリケーションの制御等の処理を行う。

メモリ制御部３２は、ＮＶＲＡＭ６２やＲＡＭ６５といったメモリの取得および解放、画像データの圧縮および伸張等のメモリ制御を行う。エンジン制御部３３は、図２には図示していないハードウェアリソースのエンジン制御を行う。ファックス制御部３４は、アナログ公衆電話網（ＧＳＴＮ）Ｉ／Ｆ６８と接続し、システムコントローラの各アプリケーション層からＧＳＴＮ網を利用したファクシミリ送受信、バックアップ用のメモリで管理されている各種ファクシミリデータの登録／引用、ファクシミリ読み取りを行い、ファクシミリ受信印刷等を行うためのＡＰＩを提供する。

オペレーション制御部３５は、オペレータと本体制御との間の情報伝達手段となるオペレーションパネルの制御を行う。配信制御部３６は、他の機器との送受信のためのデータの管理やデータの加工等を行う。ネットワーク制御部３７は、イーサネット（登録商標）等のネットワークＩ／Ｆ６６と接続され、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供し、ネットワークから各プロトコルによって受信したデータを各アプリケーションに振り分け、各アプリケーションからのデータをネットワークに送信する際の仲介を行う。

セキュリティ制御部３８は、アプリケーション部や各制御部に対してセキュリティサービスを行う。例えば、暗号化や復号化の処理を行う。電源管理部３９は、ＣＰＵ６３および他のハードウェアリソースの電気的状態を監視し、また、他の制御部やアプリケーション部での省電力状態の管理や監視を行う。この電源管理部３９は、ＯＳ／Ｋｅｒｎｅｌ３０とも密接に関連して動作する。

ＳＯＡＰ／ＸＭＬ処理部５０は、ＳＯＡＰ／ＸＭＬメッセージのエンコード／デコードを行う。ＳＯＡＰ／ＸＭＬ処理部５０は、アプリケーション部からも、プラットフォーム部からも使用可能とされている。ＳＯＡＰ／ＸＭＬ処理部５０は、通常、ライブラリ形式で提供されるが、アプリケーションや制御部等のプロセス形式であってもよい。

ＣＰＵ６３は、機器１７全体の制御を行い、プラットフォーム部の各制御部として機能し、各制御部を使用するアプリケーション部の各アプリを実行する。なお、図２に示す各制御部および各アプリは、機器構成により、これらすべてを含む必要はなく、その一部のみを含む構成であってもよい。また、機器１７は、アプリケーション等のソフトウェアプログラムを格納するためのＨＤＤ６１、初期化プログラムやブートローダ等を格納するためのＲＯＭ６４、外部デバイスと通信を行うための外部デバイスＩ／Ｆ６７、チャレンジレスポンス認証等の暗号処理を行うセキュアデバイス６０を備えている。セキュアデバイス６０には、ＩＣチップ等がある。

図３は、ネットワーク制御部および電源管理部の構成を例示した図である。図３では、これらとともに、アプリケーションおよびＳＯＡＰ／ＸＭＬ処理部５０も示されている。ここでは、アプリケーションは、プリンタアプリケーション２０とされている。これらネットワーク制御部および電源管理部が、省電力状態へ移行するかを判断する判断手段およびレスポンスを返す通知手段として機能する。

ネットワーク制御部３７は、ネットワークの制御全体を統括するネットワーク全体制御部３７ａ、他のアプリケーションや他の制御部とのメッセージやデータのやり取りを行うネットワーク通信部３７ｂ、ＨＴＴＰ制御部３７ｃ、ＷＳ−Ｅｖｅｎｔｉｎｇプロトコルを処理するＷＳ−Ｅｖｅｎｔｉｎｇ処理部３７ｄ、ＨＴＴＰ以外の各種プロトコル（ＦＴＰ、Ｐｏｒｔ９１００ ＬＰＲ等）を処理するプロトコル制御部３７ｅ、イベントを管理するイベント管理部３７ｆから構成されている。

電源管理部３９は、電源の制御全体を統括する電源全体制御部３９ａ、他のアプリケーションや他の制御部とのメッセージやデータのやり取りを行う電源通信部３９ｂ、ハードウェアリソース等の各デバイスの電源状態の確認を行うハードウェア管理部３９ｃから構成されている。なお、アプリケーション２０は、アプリケーションの制御全体を統括するアプリ全体制御部２０ａ、他のアプリケーションや他の制御部とのメッセージやデータのやり取りを行うアプリ通信部２０ｂ、イベントを検出するイベント検出部２０ｃから構成されている。

図１に示すネットワークに接続されたＰＣ１０〜１６といった外部装置から有効期間を有するイベント監視リクエストがＷＳ−Ｅｖｅｎｔｉｎｇプロトコルを使用して送られてくると、ＷＳ−Ｅｖｅｎｔｉｎｇ処理部３７ｄが処理を行う。図４を参照して、ＷＳ−ＥｖｅｎｔｉｎｇプロトコルにおけるＳｕｂｓｃｒｉｂｅリクエストについて説明する。図４に示すＳｕｂｓｃｒｉｂｅリクエストは、外部装置であるイベント監視先（Ｓｕｂｓｃｒｉｂｅｒ）がＰｒｉｎｔｅｒＳｔａｔｕｓＥｖｅｎｔの登録を行っており、ＰｒｉｎｔｅｒＳｔａｔｕｓが変化したら通知してほしいというリクエストとされている。このリクエストでは、有効期間（Ｅｘｐｉｒｅｓフィールドにおける有効時間）として３０分をリクエストしている。

このリクエストに対して有効期間の更新おこなうが、このとき電源管理部３９は省電力状態へ移行しそうか否かを判断し、移行しそうと判断した場合、有効期間を延長して更新するとともに、延長した有効期間のデータを有するレスポンスを返す。この処理の詳細については後述し、ここでは、そのＳｕｂｓｃｒｉｂｅリクエストに対して機器１７が返すＳｕｂｓｃｒｉｂｅＲｅｓｐｏｎｓｅについて説明する。図５は、ＳｕｂｓｃｒｉｂｅＲｅｓｐｏｎｓｅのメッセージ例である。図５に示すレスポンスでは、省電力状態への移行がないと判定され、リクエストと同じ３０分という有効期間で更新し、その有効期間を含むレスポンスとされている。

省電力状態への移行があると判定されると、有効期間が延長して更新されると、図６に示すように、ＳｕｂｓｃｒｉｂｅＲｅｓｐｏｎｓｅの有効期間がリクエストの３０分から４０分へと延長されたレスポンスとされる。ここでは４０分へ延長したが、これに限られるものではなく、２〜８時間といった数時間へ延長することもできる。この時間は、例えば、予め設定しておき、その設定時間ほど延長するようにすることができる。ただし、単に長ければよいというものではない。前述のようにＤＨＣＰサーバやルータからも定期的にリクエストが通知されるため、これらから通知される期間以上に長くしても省電力の効果は無い。
一方、Ｓｕｂｓｃｒｉｂｅｒは、レスポンスに含まれる有効期間を超えて、さらに監視を続ける必要がある場合、有効時間が経過する前に再監視リクエストであるＲｅｎｅｗリクエストを行って有効期間の更新を行う。これに対し、機器１７は、ＲｅｎｅｗＲｅｓｐｏｎｓｅにより応答する。なお、有効期間が更新されず経過した後は、機器１７は該当するイベントの監視を終了させる。

ここでのＳｕｂｓｃｒｉｂｅリクエストは、ＰｒｉｎｔｅｒＳｔａｔｕｓが変化したら通知してほしいというリクエストであるため、機器１７は、何らかのイベントが発生すれば、そのイベントを通知する。図７は、図４に示すＳｕｂｓｃｒｉｂｅリクエストに対するイベント（ＰｒｉｎｔｅｒＳｔａｔｕｓＥｖｅｎｔ）が発生したときの通知メッセージの例である。この図７に示す通知メッセージは、トナーなしというイベントが発生したため、トナーなしという状況を通知するメッセージとされている。

図８を参照して、ＳｕｂｓｃｒｉｂｅリクエストおよびＲｅｎｅｗリクエストを受けたときのＳｕｂｓｃｒｉｂｅｒ７０とイベントを発生する機器（ＥｖｅｎｔＳｏｕｒｃｅ）１７との間の処理およびその機器１７の内部で行われる処理について詳細に説明する。機器１７は、イベント監視先であるｓｕｂｓｃｒｉｂｅｒ７０からＳｕｂｓｃｒｉｂｅ／Ｒｅｎｅｗリクエストを受信すると、まず、機器１７のネットワーク制御部３７内のＨＴＴＰ制御部３７ｃがそのリクエストを受け取る。ＨＴＴＰ制御部３７ｃは、ＷＳ−Ｅｖｅｎｔｉｎｇ処理部３７ｄにそのリクエストの内容を渡し、ＳＯＡＰ／ＸＭＬ処理部５０でその内容を解析して、イベント管理部３７ｆにＳｕｂｓｃｒｉｂｅリクエストである場合には登録を、Ｒｅｎｅｗリクエストである場合には確認を行う。イベント管理部３７ｆは、必要に応じて関連するアプリケーション２０とのやり取りを行う。その後、イベント管理部３７ｆは、電源管理部３９に問い合わせを行い、電源管理部３９は、ハードウェアリソース等の各デバイスの電源状態を確認し、問い合わせに対する回答を行う。イベント管理部３７ｆは、その回答から省電力状態へ移行しそうか否かを判断して、そのイベントに対する有効期間を決定し、ＷＳ−Ｅｖｅｎｔｉｎｇ処理部３７ｄが、その登録／確認結果をＳＯＡＰ／ＸＭＬ処理部５０を通じてメッセージ化し、ＨＴＴＰ制御部３７ｃを通じてＳｕｂｓｃｒｉｂｅｒ７０にレスポンスを返す。

図８では、イベント管理部３７ｆが電源管理部３９に問い合わせを行っているが、電源管理部３９が電源状態の変化、すなわち省電力状態への移行や省電力状態からの復帰をイベント管理部３７ｆに通知することもできる。この場合には、イベント管理部３７ｆは、電源管理部３９に対し問い合わせはしない。

図９に示すイベント発生時の機器１７の内部シーケンスおよび外部シーケンス（イベント監視先とイベント発生をする機器との間）を参照して、イベントが発生した場合の処理について説明する。アプリケーション２０のイベント検出部２０ｃがイベントを検知すると、イベント管理部３７ｆがそれを受けてＷＳ−Ｅｖｅｎｔｉｎｇ処理部３７ｄへ通知し、ＳＯＡＰ／ＸＭＬ処理部５０を通じてメッセージ化する。ＷＳ−Ｅｖｅｎｔｉｎｇ処理部３７ｄは、ＨＴＴＰ制御部３７ｃを通じてＳｕｂｓｃｒｉｂｅｒ７０にメッセージ化されたイベントの通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）を行う。

イベント管理部３７ｆは、イベント管理テーブルを保持し、そのイベント管理テーブルを使用して、イベント監視先であるＳｕｂｓｃｒｉｂｅｒや有効期間等を管理している。このため、イベント管理部３７ｆは、省電力状態へ移行するかに応じて、有効期間を延長するか、また、どの程度延長するかを決定し、その延長した有効期間を含むＳｕｂｓｃｒｉｂｅ／Ｒｅｎｅｗレスポンスを送信させることができる。例えば、５分以内に省電力状態に移行することが分かった場合は有効期間を延長すると判断する。また、ルータから定期的にマルチキャストパケットが通知されている場合は通知間隔が分かるので、この通知間隔または次回のルータの通知までの期間で延長する。図１０は、イベント管理部３７ｆが保持するイベント管理テーブルの例を示した図である。このテーブルでは、Ｓｕｂｓｃｒｉｂｅｒ、イベントＩＤ、イベント監視先のＩＰアドレス、イベントの内容、有効期間、有効期間の期限切れまでの時間が保持されている。期限切れまでの時間は、時間の経過とともにその値が減少するようになっている。図１０では、図１０（ａ）と図１０（ｂ）との２つのテーブルとされているが、１つのテーブルであってもよい。

イベントの内容には、図１０（ｂ）に示す「トナーなし」、「用紙なし」、「カバーオープン」のほか、省エネイベントを含むことができる。省エネイベントには、「省電力状態移行」と「省電力状態解除」とがあり、Ｓｕｂｓｃｒｉｂｅｒ７０は、これらのＳｕｂｓｃｒｉｂｅリクエストを送信し、機器１７から省電力状態移行イベントと省電力状態解除イベントの通知を受けることができる。

図１１に示すシーケンスを参照して、ＳｕｂｓｃｒｉｂｅリクエストおよびＲｅｎｅｗリクエストに対する処理と、省電力状態移行イベントの通知と省電力状態解除イベントの通知を行う処理について説明する。Ｓｕｂｓｃｒｉｂｅｒ７０は、あるイベントが発生したら通知してほしいというＳｕｂｓｃｒｉｂｅリクエストを送信する。機器１７は、そのリクエストを受け取り、登録し、登録した旨をレスポンスとして返す。このとき、省電力状態へ移行しないため、期限切れまでの時間を更新し有効期間を延長せずにレスポンスが返される。有効期間が経過する（期限切れまでの時間が０になる）前にＳｕｂｓｃｒｉｂｅｒ７０がＲｅｎｅｗリクエストによりイベント監視の更新リクエストを行う。これに対し、機器１７は、その更新リクエストを受け取り、更新した旨をレスポンスとして返す。このときも、省電力状態へ移行しないため、期限切れまでの時間を更新し有効期間を延長せずにレスポンスが返される。

再び有効期間が経過する前にＳｕｂｓｃｒｉｂｅｒ７０がＲｅｎｅｗリクエストによりイベント監視の更新リクエストを行う。これに対し、機器１７は、その更新リクエストを受け取り、更新した旨をレスポンスとして返す。このときは、省電力状態へ移行する予定が近いため、有効期間を延長したレスポンスが返される。

Ｓｕｂｓｃｒｉｂｅｒ７０は、機器１７に対し、省電力状態へ移行したら通知してほしいというリクエスト、省電力状態から復帰したら通知してほしいというリクエストも送信しており、機器１７は、これらのリクエストに対して、省電力状態へ移行すると、省電力状態移行イベントをＳｕｂｓｃｒｉｂｅｒ７０に通知し、また、省電力状態が解除されると、省電力状態解除イベントをＳｕｂｓｃｒｉｂｅｒ７０に通知する。このため、Ｓｕｂｓｃｒｉｂｅｒ７０は、省電力状態の間はＲｅｎｅｗリクエストを送信せず、省電力状態解除イベントの通知を受けた後にＲｅｎｅｗリクエストの送信を再開する。省電力状態の間、イベント管理部３７ｆは、イベント管理テーブル内の有効期間の更新は行わず、有効期間が経過したとしてもイベント管理テーブルから情報の削除は行わない。これにより、Ｓｕｂｓｃｒｉｂｅｒ７０は、省電力状態の解除後でもイベントの監視を継続することができる。

図１２を参照して、省電力状態の間、Ｓｕｂｓｃｒｉｂｅｒ７０から機器状態の問い合わせを行う処理について説明する。有効期間が経過する前にＳｕｂｓｃｒｉｂｅｒ７０がＲｅｎｅｗリクエストによりイベント監視の更新リクエストを行う。これに対し、機器１７は、その更新リクエストを受け取り、更新した旨をレスポンスとして返す。このとき、省電力状態へ移行しないため、有効期間を延長しないレスポンスが返される。

再び有効期間が経過する前にＳｕｂｓｃｒｉｂｅｒ７０がＲｅｎｅｗリクエストによりイベント監視の更新リクエストを行う。これに対し、機器１７は、その更新リクエストを受け取り、更新した旨をレスポンスとして返す。このときは、省電力状態へ移行する予定であるため、有効期間を延長したレスポンスが返される。

Ｓｕｂｓｃｒｉｂｅｒ７０は、機器１７に対し、省電力状態へ移行したら通知してほしいというリクエスト、省電力状態から復帰したら通知してほしいというリクエストも送信しており、機器１７は、省電力状態へ移行すると、省電力状態移行イベントをＳｕｂｓｃｒｉｂｅｒ７０に通知する。すると、Ｓｕｂｓｃｒｉｂｅｒ７０は、省電力状態解除イベントを受け取るまでは、Ｒｅｎｅｗリクエストを送信しない。

Ｓｕｂｓｃｒｉｂｅｒ７０は、省電力状態の間、ｐｉｎｇ等の省電力状態から復帰しなくとも対応できるコマンドにより問い合わせを行うことができる。ｐｉｎｇは、ＴＣＰ／ＩＰネットワークにおいて、相手先と通信できるかを確認するコマンドである。Ｓｕｂｓｃｒｉｂｅｒ７０は、機器１７から応答があれば、省電力状態と判断し、応答がなければ、機器１７に異常があると判断し、機器の監視を中止する。

イベント監視先が１つであれば、省電力状態の間にＲｅｎｅｗリクエストを受信しないように、有効期間を延長するのみでよいが、イベント監視先が複数存在する場合、有効期間の違いから、Ｒｅｎｅｗリクエストを頻繁に受ける可能性がある。これでは、頻繁に省電力状態から復帰してしまい、省電力化を図ることはできない。

そこで、複数のイベント監視先からＲｅｎｅｗリクエストを受信する時刻をほぼ同じになるように調整し、Ｒｅｎｅｗリクエストの受信を集中させる。これにより、省電力状態からの復帰回数を減少させることができる。図１３は、複数のＳｕｂｓｃｒｉｂｅｒからのＲｅｎｅｗリクエストの受信時刻がほぼ同じになるように有効期間を調整するようＲｅｎｅｗリクエストを同期させ、Ｒｅｎｅｗリクエストによる省電力状態からの復帰タイミングを減少させる例を示した図である。ここでは、Ｓｕｂｓｃｒｉｂｅｒが２つあり、機器１７は、それぞれの有効期間を確認し、２つのＳｕｂｓｃｒｉｂｅｒからＲｅｎｅｗリクエストを受信した時刻がほぼ同じ時刻になるように有効期間を調整する。Ｓｕｂｓｃｒｉｂｅｒ７１を基準とし、Ｓｕｂｓｃｒｉｂｅｒ７１からＲｅｎｅｗリクエストを受信した時刻をＳｔａｒｔ Ｐｏｉｎｔとする。Ｓｕｂｓｃｒｉｂｅｒ７１には延長した新しい有効期間Ｃでレスポンスを返す。Ｓｕｂｓｃｒｉｂｅｒ７２に対してはＳｔａｒｔ Ｐｏｉｎｔからの差分Ｄをとり、まず、暫定期間（Ｃ−Ｄ）でレスポンスを返し、次のレスポンス時に、有効期間Ｃでレスポンスを返す。

図１４は、各タイミングにおけるイベント管理テーブルを例示した図である。各タイミングとは、図１３に示すＴ１、Ｔ２、Ｔ３の時点である。図１４（ａ）は、調整前Ｔ１におけるイベント管理テーブルを例示し、図１４（ｂ）は、暫定期間Ｔ２におけるイベント管理テーブルを例示し、図１４（ｃ）は、調整後Ｔ３におけるイベント管理テーブルを例示した図である。図１４（ａ）に示す調整前では、Ｓｕｂｓｃｒｉｂｅｒ７１は有効期間１５分をリクエストし、Ｓｕｂｓｃｒｉｂｅｒ７２は有効期間１０分をリクエストしている。このため、機器１７が、Ｒｅｎｅｗリクエストを受信する時刻が相違している。調整を開始すると、イベント管理部３７ｆにより新しい有効期間として２０分が決定され、Ｓｕｂｓｃｒｉｂｅｒ７１に対しては延長した新しい有効期間２０分でレスポンスを返し、イベント監視テーブルも図１４（ｂ）に示すように２０分に更新する。

Ｓｕｂｓｃｒｉｂｅｒ７２に対しては、Ｓｕｂｓｃｒｉｂｅｒ７１からＲｅｎｅｗリクエストを受信した時刻をＳｔａｒｔ Ｐｏｎｉｔとした場合の差分（Ｓｕｂｓｃｒｉｂｅｒ７１からＲｅｎｅｗリクエストを受信した時刻とＳｕｂｓｃｒｉｂｅｒＢからＲｅｎｅｗリクエストを受信した時刻との時間差）をとる。ここでは、その時間差が２分であったとして、新しく決定した有効期間２０分から減算して、暫定期間１８分でレスポンスを返す。このとき、イベント監視テーブルも図１４（ｂ）に示すように１８分に更新する。

このように調整すると、有効期間の経過前にＳｕｂｓｃｒｉｂｅｒ７１からも、Ｓｕｂｓｃｒｉｂｅｒ７２からも、ほぼ同じ時刻にＲｅｎｅｗリクエストを受け付けることができる。これらのリクエストに対し、機器１７は、Ｓｕｂｓｃｒｉｂｅｒ７１に対しては有効期間を変更することなく有効期間２０分でレスポンスを返し、Ｓｕｂｓｃｒｉｂｅｒ７２に対しては有効期間を２０分にしてレスポンスを返し、イベント監視テーブルを図１４（ｃ）に示すように２０分に更新する。

イベント監視先が多数存在し、それら多数のイベント監視先からのＲｅｎｅｗリクエストが集中すると、同時に機器１７へアクセスが行われ、あるリクエストに対してはセッションタイムアウト等が発生し、再監視が成立しない場合がありうる。そこで、Ｒｅｎｅｗリクエストを受信する時刻をわずかにずらすことで、この問題を解消することができる。

図１５は、複数のＳｕｂｓｃｒｉｂｅｒからのＲｅｎｅｗリクエストの受信時刻がわずかにずれるように有効期間を調整し、Ｒｅｎｅｗリクエストによる省電力状態からの復帰タイミングを減少させる例を示した図である。ここでは、Ｓｕｂｓｃｒｉｂｅｒが２つあり、機器１７は、それぞれの有効期間を確認し、２つのＳｕｂｓｃｒｉｂｅｒからＲｅｎｅｗリクエストを受信する時刻がわずかにずれるように有効期間を調整する。すなわち、Ｓｕｂｓｃｒｉｂｅｒ７１を基準にし、ＳｕｂｓｃｒｉｂｅｒＡには延長した新しい有効期間Ｃでレスポンスを返す。Ｓｕｂｓｃｒｉｂｅｒ７２に対しては、Ｓｔａｒｔ Ｐｏｉｎｔからの差分Ｄをとり、それにずれ量αを加算して、暫定期間（Ｃ−Ｄ＋α）でレスポンスを返し、次のレスポンス時には、Ｓｕｂｓｃｒｉｂｅｒ７１に対するレスポンスと同じ有効期間Ｃでレスポンスを返す。

なお、３つ以上の監視先がある場合、ずれ量をβ、γ、δ等し、暫定期間をＣ−Ｄ＋β、Ｃ−Ｄ＋γ、Ｃ−Ｄ＋δ等として、ずれ量に異なる値を用いる。このようにすることで、複数の監視先からのＲｅｎｅｗリクエストがぶつからなくなり、セッションタイムアウト等も発生せず、確実に再監視を成立させることができる。

図１６は、各タイミングにおけるイベント管理テーブルを例示した図である。各タイミングとは、図１５に示すＴ１、Ｔ２、Ｔ３の時点である。図１６（ａ）は、調整前Ｔ１におけるイベント管理テーブルを例示し、図１６（ｂ）は、暫定期間Ｔ２におけるイベント管理テーブルを例示し、図１６（ｃ）は、調整後Ｔ３におけるイベント管理テーブルを例示した図である。図１６（ａ）に示す調整前では、Ｓｕｂｓｃｒｉｂｅｒ７１は有効期間１５分をリクエストし、Ｓｕｂｓｃｒｉｂｅｒ７２は有効期間１０分をリクエストしている。このため、機器１７が、Ｒｅｎｅｗリクエストを受信する時刻が相違している。調整を開始すると、イベント管理部３７ｆにより新しい有効期間として２０分が決定され、Ｓｕｂｓｃｒｉｂｅｒ７１に対しては延長した新しい有効期間２０分でレスポンスを返し、イベント監視テーブルも図１６（ｂ）に示すように２０分に更新する。

Ｓｕｂｓｃｒｉｂｅｒ７２に対しては、Ｓｕｂｓｃｒｉｂｅｒ７１からＲｅｎｅｗリクエストを受信した時刻をＳｔａｒｔ Ｐｏｉｎｔとした場合の差分（ＳｕｂｓｃｒｉｂｅｒＡからＲｅｎｅｗリクエストを受信した時刻とＳｕｂｓｃｒｉｂｅｒＢからＲｅｎｅｗリクエストを受信した時刻との時間差）をとる。ここでは、その時間差が２分であったとして、新しく決定した有効期間２０分から減算し、ずれ量として１分を加算して、暫定期間１９分でレスポンスを返す。このとき、イベント監視テーブルも図１６（ｂ）に示すように１９分に更新する。

このように調整すると、Ｓｕｂｓｃｒｉｂｅｒ７２からのＲｅｎｅｗリクエストを、Ｓｕｂｓｃｒｉｂｅｒ７１からのＲｅｎｅｗリクエストから１分遅れて受け付けることができる。これらのリクエストに対し、機器１７は、Ｓｕｂｓｃｒｉｂｅｒ７１に対しては有効期間を変更することなく有効期間２０分でレスポンスを返し、Ｓｕｂｓｃｒｉｂｅｒ７２に対しては有効期間を２０分にしてレスポンスを返し、イベント監視テーブルを図１６（ｃ）に示すように２０分に更新する。

図１７は、有効時間を決定後にレスポンスを生成して返す処理の流れを示した図である。まず、ステップ１７００で処理を開始し、ステップ１７１０で、Ｓｕｂｓｃｒｉｂｅｒ７０から監視および更新リクエストを受信する。ステップ１７２０で、省電力状態へ移行するか否かを判定するために電源状態をチェックし、ステップ１７３０で、移行すると判定した場合は有効期間を延長し、移行しないと判定した場合は有効期間の変更はしないと決定する。ステップ１７４０で、有効期間を含むレスポンスをＳｕｂｓｃｒｉｂｅｒ７０へ返し、ステップ１７５０で処理を終了する。

図１８は、複数のＳｕｂｓｃｒｉｂｅｒからのＲｅｎｅｗリクエストの受信時刻がほぼ同じになるように有効時間を調整するようＲｅｎｅｗリクエストを同期させる場合と、Ｒｅｎｅｗリクエストをわずかにずらす場合の処理の流れを示した図である。この図１８に示す処理は、図１３および図１５のシーケンス図に示した処理に対応するものである。

ステップ１８００でこの処理を開始し、まず、ステップ１８１０でＲｅｎｅｗリクエストに対する処理、すなわちＲｅｎｅｗリクエストの受信およびＲｅｎｅｗＲｅｓｐｏｎｓｅの送信を繰り返す。ステップ１８２０で調整を開始すると、すべてのＳｕｂｓｃｒｉｂｅｒがリクエストした有効期間を確認する。これは、イベント管理部３７ｆが管理するイベント監視テーブルを参照することにより確認することができる。

ステップ１８３０で省電力状態へ移行するか否かを判定するために電源状態を確認し、ステップ１８４０で新しい有効期間を決定する。ステップ１８５０で、新しい有効期間を採用する最初のＲｅｎｅｗリクエストに対して、新しい有効期間をもつレスポンスを返し、ステップ１８６０で、それ以降のＲｅｎｅｗリクエストに対して、暫定期間を計算するとともに暫定期間を有するレスポンスを返す。ステップ１８７０で、最初のＲｅｎｅｗリクエスト以降のＲｅｎｅｗリクエストに対して新しい有効時間をもつレスポンスを返し、ステップ１８８０で処理を終了する。

これまで監視される側の機器１７の構成およびその処理について詳細に説明してきたが、以下、監視を行う側の外部装置の構成およびその処理について説明する。

図１９は、機器１７の監視を行う側のモジュール構成を例示した図である。図１に示すように、機器１７の監視を行う側は、ＰＣであることが多いが、上述したように、ＭＦＰ等であってもよい。監視を行う側の装置は、装置全体を制御する全体制御部８０と、ＨＴＴＰ制御部８１を含むネットワーク制御部８２と、ＷＳ−Ｅｖｅｎｔｉｎｇ処理部８３と、イベント管理部８４と、ＳＯＡＰ／ＸＭＬ処理部８５とを含んで構成されている。ここでは、最小限必要なモジュールのみを示し、必要に応じてその他のモジュールを含んで構成されていてもよい。各部の機能については、機器１７における各部の機能と同様のものである。

図２０は、機器の監視を行う側が実行する処理の流れを例示した図である。機器１７の監視を行う側の装置をＰＣ１０として説明を行うと、ステップ２０００で処理を開始し、ステップ２０１０でＰＣ１０は機器１７に対し、Ｒｅｎｅｗリクエストを送信し、ステップ２０２０でその機器１７からレスポンスを受信する。ステップ２０３０で省電力状態移行通知があるかを判定し、通知がある場合、ステップ２０４０へ進み、一定時間スリープする。

その後、ステップ２０５０で省電力状態解除通知があるかを判定し、通知がない場合、ステップ２０６０へ進み、一定時間スリープし、ステップ２０７０で機器１７へｐｉｎｇ等により問い合わせを行い、応答があるか否かを判断する。応答がある場合、省電力状態であるから、ステップ２０４０へ戻り、応答がない場合、ステップ２０８０へ進み、機器１７に異常があると判断し、機器１７の監視を中止する。

一方、ステップ２０３０で省電力状態移行通知がない場合、ステップ２０５０で省電力状態解除通知がある場合には、ステップ２０９０へ進み、一定時間スリープし、ステップ２０１０でＲｅｎｅｗリクエストを送信するまで待機する。なお、機器１７の監視を中止したところで、ステップ２１００において処理が終了する。

次に、第二の実施の形態について説明する。図２１は、第二の実施の形態のネットワークシステムの構成例を示す図である。

同図において、機器１７は、ユーザ端末１２０ａ及びユーザ端末１２０ｂと、ＬＡＮ（Local Area Network）等のネットワーク１４０を介して接続されている。また、機器１７は、ＬＡＮ等のネットワーク１５０に接続されているユーザ端末１２０ｃ及び１２０ｄとルータ１３０を介して接続されている。すなわち、ユーザ端末１２０ａ及び１２０ｂは、機器１７と同一セグメント（同一ネットワーク）に属し、ユーザ端末１２０ｃ及び１２０ｄは、機器１７と別セグメント（別ネットワーク）に属する。なお、ユーザ端末１２０ａ、ユーザ端末１２０ｂを、それぞれローカル端末１２０ａ、ローカル端末１２０ｂともいい、ユーザ端末１２０ｃ、ユーザ端末１２０ｄを、それぞれリモート端末１２０ｃ、リモート端末１２０ｄともいう。「ローカル」は、機器１７と同一セグメントであることを意味し、「リモート」は、機器１７と別セグメントであることを意味する。また、ユーザ端末１２０ａ、１２０ｂ、１２０ｃ、及び１２０ｄを区別しない場合、単に「ユーザ端末１２０」という。また、ネットワーク１４０及びネットワーク１５０は、有線であってもよいし、無線であってもよい。

ユーザ端末１２０は、ユーザが利用する個人端末であり、ソフトウェアプログラムのインストール及び実行が可能であり、通信機能を有するものであれば、特定の装置に限定されない。ユーザ端末１２０の具体例として、デスクトップ型のＰＣ（Personal Computer）、ノートＰＣ、ＰＤＡ（Personal Digital Assistance）、又は携帯電話等の情報処理装置が挙げられる。本実施の形態において、各ユーザ端末１２０には、ウィジェット１２１と呼ばれるアプリケーションプログラムがインストールされている。

近年では、ウィジェット（Ｗｉｄｇｅｔ）又はガジェット（Ｇａｄｇｅｔ）とよばれる手軽なアプリケーションプログラムが流通している。本実施の形態では、手軽にインストールして利用可能なアプリケーションプログラムという程度の意味においてこれらのアプリケーションプログラムをウィジェット１２１と呼ぶ（すなわち、技術的な意義において限定する趣旨ではない）。本実施の形態において、ウィジェット１２１は、機器１７の機能を遠隔的に利用して、所定のサービス（例えば、ワークフロー等の一連の処理フロー）をユーザに提供するという点において共通する。ウィジェット１２１が実行する典型的又は代表的な処理としては、機器１７にスキャンを実行させ、スキャンされた画像データをユーザ端末１２０内に保存するといったものである。なお、各ウィジェット１２１が実行する処理手順（各ウィジェット１２１に実装されている機能）は、それぞれ異なりうる。また、各ウィジェット１２１は、ユーザ端末１２１において任意に起動される。したがって、ネットワークシステム内において起動されているウィジェット１２１の一覧は、極めて流動的なものである。

図２２は、第二の実施の形態における機器のソフトウェア構成およびハードウェア構成を例示した図である。図２２中、図２と同一部分には同一符号を付し、その説明は省略する。

第二の実施の形態において、機器１７は、プロバイダアプリ２５を有する。プロバイダアプリ２５は、機器１７をウィジェット１２１と連携させるための処理を実行するアプリケーションプログラムである。例えば、プロバイダアプリ２５は、ウィジェット１２１が機器１７に要求する処理（スキャン等）を機器１７に実行させるための処理を制御する。ウィジェット１２１との連携を実現するために、プロバイダアプリ２５は、ネットワーク１４０又はネットワーク１５０上において起動されているプロバイダアプリ２５を検索する。斯かる検索処理について説明する。

図２３は、プロバイダアプリによるウィジェットの検索処理の処理手順を説明するためのシーケンス図である。

機器１７の起動時において、プロバイダアプリ２５は、ＲＡＭ６５内において、ウィジェット１２１の一覧情報を記憶するための記憶領域（以下、「ウィジェット一覧情報記憶部」という。）をクリアしておく（Ｓ１１０）。

その後、プロバイダアプリ２５は、リモート端末１２０ｃ及び１２０ｄ（以下、両者を区別しない場合、単に「リモート端末１２０」という。）のそれぞれより、各リモート端末１２０の識別情報の登録要求を受信する（Ｓ１２０、Ｓ１４０）。プロバイダアプリ２５は、受信された識別情報をＲＡＭ６５に記録する（Ｓ１３０、Ｓ１５０）。なお、識別情報は、ＩＰアドレス又はホスト名等、各リモート端末１２０をネットワーク通信において識別可能な情報であればどのようなものでもよい。本実施の形態では、当該識別情報としてＩＰアドレスを採用した例について説明する。

ステップＳ１５０の後、機器１７は操作待ち状態となっている。その後、ユーザによってオペレーションパネルを介してプロバイダアプリ２５の実行指示が入力されると（Ｓ１６０）、プロバイダアプリ２５は、ＲＡＭ６５に登録されているＩＰアドレスを読み出す（取得する）（Ｓ１７０）。続いて、プロバイダアプリ２５は、ウィジェット一覧情報記憶部の内容をクリアする（Ｓ１８０）。ステップＳ１８０におけるウィジェット一覧情報記憶部のクリアは、検索実行前の初期化処理に該当する。すなわち、ステップＳ１６０以降は、機器１７の起動中において、プロバイダアプリ２５が実行対象として選択されるたびに実行される。したがって、２回目以降にプロバイダアプリ２５が実行対象として選択された場合、前回の検索結果が残ったままとなっている。そうすると、これから実行される検索について正しい検索結果を表示させることができないからである。

続いて、プロバイダアプリ２５は、取得された各ＩＰアドレスに対してユニキャストによる検索要求を送出する（Ｓ１９０、Ｓ２００）。続いて、プロバイダアプリ２５は、マルチキャストによる検索要求を機器１７と同一セグメントであるネットワーク１４０上に送出する（Ｓ２１０、Ｓ２２０）。

検索要求が受信されたユーザ端末１２０において起動されているウィジェット１２１は、検索要求に応じて応答情報を返信する。応答情報には、ログインユーザのユーザＩＤ、ユーザ端末１２０の識別情報（ＩＰアドレス）、及びウィジェットの属性情報等が含められる。プロバイダアプリ２５は、ユニキャスト又はマルチキャストによる検索要求に対する応答情報を受信し、ウィジェット一覧情報記憶部に記録する。プロバイダアプリ２５は、ウィジェット一覧情報記憶部に記録された応答情報に基づいて、ウィジェット１２１の一覧画面をオペレーションパネルに表示させる。ユーザは、当該一覧画面に表示された一覧画面において所望のウィジェット１２１を選択することにより、当該ウィジェット１２１を利用することができる。

以上のように、プロバイダアプリ２５は、機器１７と同一セグメント上に存在するウィジェット１２１に関してはマルチキャストを利用して検索を行い、機器１７と別セグメント上に存在するウィジェット１２１に関してはユニキャストを利用して検索を行う。マルチキャストによる検索要求は、別セグメントまで届かないからである。

但し、ユニキャストを利用するためには、プロバイダアプリ２５は、予めユニキャスト先のＩＰアドレスを知っておく必要がある。そこで、少なくとも機器１７と別セグメント上に存在するウィジェット１２１は、定期的に自らのＩＰアドレスの登録要求（以下、「検索先登録要求」という。）をプロバイダアプリ２５に送信する。図２３におけるステップＳ１２０及びステップＳ１４０が検索先登録要求に相当する。なお、検索先登録要求が定期的に送信されるのは、検索先登録要求についても有効期間を有するからである。すなわち、プロバイダアプリ２５は、検索先登録要求に応じてＲＡＭ６５に記録したＩＰアドレスについて、当該検索先登録要求に指定されている有効期間が経過した場合は当該ＩＰアドレスをＲＡＭ６５より削除する。

したがって、機器１７は、定期的に検索先登録要求を受信することになる。検索先登録要求のタイミングはウィジェット１２１ごとに異なる。また、ネットワーク上には多数のウィジェット１２１が起動される可能性がある。

そうすると、機器１７は、省電力状態からから復帰してしまう可能性が高まってしまい、適切に省電力化を図ることができなくなってしまう。

そこで、第二の実施の形態において、プロバイダアプリ２５は、第一の実施の形態と同様の方法によって検索先登録要求による省電力状態の短縮化を回避する。

すなわち、プロバイダアプリ２５は、検索先登録要求を受信した際に、機器１７が省電力状態へ移行しようとしているときは、検索先登録要求に指定された有効期間を延長し、延長された有効期間をウィジェット１２１に対して返信する。ウィジェット１２１は、延長された有効期間に基づいて、次回の検索先登録要求を送信するタイミングを決定する。

また、プロバイダアプリ２５は、省電力状態への移行又は省電力状態からの復帰を各ウィジェット１２１に対して通知してもよい。この場合、ウィジェット１２１は、省電力状態への移行通知を受信してから省電力状態からの復帰までの間（すなわち、機器１７が省電力状態の間）は検索先登録要求の送信を停止する。

また、プロバイダアプリ２５は、各ウィジェット１２１からの検索先登録要求が、同時期になるように調整してもよい。調整の方法は、第一の実施の形態と同様でよい。すなわち、プロバイダアプリ２５は、或るウィジェット１２１からの検索先登録要求の有効期間に基づいて、当該ウィジェット１２１による次回の検索先登録要求のタイミングを判定し、その判定結果に基づいて、他のウィジェット１２１からの検索先登録要求の有効期間を変更する。プロバイダアプリ２５は、ウィジェット１２１ごとに変更された有効期間をそれぞれのウィジェット１２１に返信する。有効期間の変更の際、第一の実施の形態と同様、各ウィジェット１２１からの次回の検索先登録要求が多少ずれるように調整されてもよい。

プロバイダアプリ１２１による上記のような有効期間の調整により、検索先登録要求の受信回数の低減、又は受信時期の集中化等を図ることができる。その結果、検索先登録要求によって機器１７の省電力状態の期間が短縮化されてしまうという不都合を適切に抑制することができる。

これまで本発明を実施の形態をもって説明してきたが、本発明は上述した実施の形態に限定されるものではなく、他の実施の形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。したがって、本発明は、制御装置のほか、その制御装置を備える画像形成装置、その制御装置の機能を実現するためのプログラムとして提供することもできるものである。このプログラムは、FD、MD、SDカード、CD-ROM、DVD-ROM等の記録媒体に格納して提供することができる。

１０〜１６ ＰＣ
１７ 機器
２０ プリンタアプリ
２０ａ アプリ全体制御部
２０ｂ アプリ通信部
２０ｃ イベント検出部
２１ コピーアプリ
２２ ファックスアプリ
２３ スキャナアプリ
２４ ネットワークアプリ
２５ プロバイダアプリ
３０ ＯＳ／Ｋｅｒｎｅｌ
３１ システム制御部
３２ メモリ制御部
３３ エンジン制御部
３４ ファックス制御部
３５ オペレーション制御部
３６ 配信制御部
３７ ネットワーク制御部
３７ａ ネットワーク全体制御部
３７ｂ ネットワーク通信部
３７ｃ ＨＴＴＰ制御部
３７ｄ ＷＳ−Ｅｖｅｎｔｉｎｇ処理部
３７ｅ プロトコル制御部
３７ｆ イベント管理部
３８ セキュリティ制御部
３９ 電源管理部
３９ａ 電源全体制御部
３９ｂ 電源通信部
３９ｃ ハードウェア管理部
４０ ＡＰＩ
５０ ＳＯＡＰ／ＸＭＬ処理部
６０ セキュアデバイス
６１ ＨＤＤ
６２ ＮＶＲＡＭ
６３ ＣＰＵ
６４ ＲＯＭ
６５ ＲＡＭ
６６ ネットワークＩ／Ｆ
６７ 外部デバイスＩ／Ｆ
６８ ＧＳＴＮ Ｉ／Ｆ
７０ Ｓｕｂｓｃｒｉｂｅｒ
８０ 全体制御部
８１ ＨＴＴＰ制御部
８２ ネットワーク制御部
８３ ＷＳ−Ｅｖｅｎｔｉｎｇ処理部
８４ イベント管理部
８５ ＳＯＡＰ／ＸＭＬ処理部
１２０ａ、１２０ｂ、１２０ｃ、１２０ｄ ユーザ端末
１２１ ウィジェット
１３０ ルータ
１４０、１５０ ネットワーク

特開２００７−２９０１７８号公報

Claims (15)

1. 外部装置からイベント監視リクエストを受け付け、イベントが発生した場合に該イベントを通知する機器に用いられ、イベント監視を制御する制御装置であって、
   前記外部装置から有効期間を有するイベント監視リクエストを受信したことに応答して、前記機器内の各デバイスの電源状態を確認し、前記機器が省電力状態へ移行するか否かを判断する判断手段と、
   移行すると判断された場合に、前記外部装置へ前記有効期間を延長したレスポンスを返し、延長した前記有効期間に基づき再監視リクエストを送信させる通知手段とを備える、制御装置。
2. 前記通知手段は、複数の前記外部装置から送信される前記再監視リクエストの受信時刻がすべて同じ時刻になるように各有効期間を調整し、各調整された有効期間を有するレスポンスを各外部装置へ返す、請求項１に記載の制御装置。
3. 前記通知手段は、複数の前記外部装置から送信される前記再監視リクエストの受信時刻が予め設定された時間間隔でずれるように各有効期間を調整し、各調整された有効期間を有するレスポンスを各外部装置へ返す、請求項１に記載の制御装置。
4. 前記イベント監視リクエストおよび前記再監視リクエストの受信、前記レスポンスの送信、および前記イベントの通知に、ＷＳ−Ｅｖｅｎｔｉｎｇプロトコルを使用する、請求項１〜３のいずれか１項に記載の制御装置。
5. 前記通知手段は、前記省電力状態への移行に応答して、前記外部装置に省電力状態移行イベントを通知し、前記外部装置から前記イベント監視リクエストを送信させないようにする、請求項１〜４のいずれか１項に記載の制御装置。
6. 前記通知手段は、前記省電力状態から復帰したことに応答して、前記外部装置に省電力状態解除イベントを通知し、前記イベント監視リクエストを送信させる、請求項５に記載の制御装置。
7. 請求項１〜６のいずれか１項に記載の制御装置を備える、外部装置と通信を行う省電力状態へ移行可能な画像処理装置。
8. 外部装置からイベント監視リクエストを受け付け、イベントが発生した場合に該イベントを通知する機器に用いられる制御装置によりイベント監視を制御する方法であって、
   前記外部装置から有効期間を有するイベント監視リクエストを受信したことに応答して、前記機器内の各デバイスの電源状態を確認し、前記機器が省電力状態へ移行するか否かを判断するステップと、
   移行すると判断された場合に、前記外部装置へ前記有効期間を延長したレスポンスを返し、延長した前記有効期間に基づき再監視リクエストを送信させるステップとを含む、制御方法。
9. 前記送信させるステップでは、複数の前記外部装置から送信される前記再監視リクエストの受信時刻がすべて同じ時刻になるように各有効期間を調整し、各調整された有効期間を有するレスポンスを各外部装置へ返す、請求項８に記載の制御方法。
10. 前記送信させるステップでは、複数の前記外部装置から送信される前記再監視リクエストの受信時刻が予め設定された時間間隔でずれるように各有効期間を調整し、各調整された有効期間を有するレスポンスを各外部装置へ返す、請求項８に記載の制御方法。
11. 前記イベント監視リクエストおよび前記再監視リクエストの受信、前記レスポンスの送信、および前記イベントの通知に、ＷＳ−Ｅｖｅｎｔｉｎｇプロトコルを使用することを特徴とする、請求項８〜１０のいずれか１項に記載の制御方法。
12. 前記省電力状態への移行に応答して、前記外部装置から前記イベント監視リクエストを送信させないように、前記外部装置へ省電力状態移行イベントを通知するステップをさらに含む、請求項８〜１１のいずれか１項に記載の制御方法。
13. 前記省電力状態から復帰したことに応答して、前記外部装置に省電力状態解除イベントを通知し、前記イベント監視リクエストを送信させるステップをさらに含む、請求項１２に記載の制御方法。
14. 前記機器の異常を検知するステップと、前記外部装置からの問い合わせに対し、レスポンスを返さないことで前記外部装置にイベント監視を中止させるステップとをさらに含む、請求項８〜１３のいずれか１項に記載の制御方法。
15. 請求項８〜１４のいずれか１項に記載の制御方法を実行するためのコンピュータにより読み取り可能なプログラム。

Images