JP4720596B2 - 画像処理装置、アクセス動作制御方法、及びプログラム - Google Patents

Description

本発明は、ネットワークを介して接続された端末装置の要求に応じて画像処理を行う画像処理装置等に関する。

近年、環境保全を目的とする法律や規制等を背景として、各機器には消費電力の低減による省エネルギー化が求められている。また、環境保全の必要性は一般消費者の間にも浸透してきており、かかる消費電力の低減は、製品のアピールポイントとしても注目されるようになっている。
こうしたことから、コピー、スキャナ、プリンタ、ファクシミリ等の複数の機能を搭載したマルチファンクショナルな事務機器(所謂複合機)においても、消費電力を抑えるための一策として、省電力状態(スリープモード等)が実装されることは多い。

ここで、公報記載の技術にも、複合機において省電力状態を実装したものがある(例えば、特許文献１、２参照)。
このうち、特許文献１は、低消費電力モードを有する画像処理装置をネットワークに接続した際、機器が低消費電力モードに移行することによって、ネットワークから送出されるデータの管理が行えなくなることを防止するものである。そのために、画像情報の処理や記憶が可能なコントローラ部と、ネットワークに対して情報の入出力を行う入出力部とを設けた画像処理装置において、通常稼動モードのときは、コントローラ部が入出力部を制御することでネットワークでの情報の送受信を行い、低消費電力モードのときは、入出力部がデータの送受信を制御している。

また、特許文献２は、プリント処理を行うユーザの待ち時間を増大させることなく、システム全体の消費電力を効率的に節約するものである。そのために、省電力サーバがシステム全体の消費電力に基づいて各画像形成装置を節電状態にするかレディ状態にするかを決定し、その決定した状態にするコマンドを通知している。

特開２００３−８９２５４号公報 特開２００３−３２３９７号公報

ところで、複合機は、一般に複数の端末装置が接続されるネットワーク環境下に設置される。そして、複数の端末装置からのネットワークを介した要求に応じて、プリンタ機能やファクシミリ機能等を動作させる。
一方、昨今、端末装置では、その処理性能が向上したこともあり、様々なプログラムがインストールされ、利用されている。このようなプログラムの中には、複合機の稼働状態や消耗品の残量状態等の機器情報を複合機への定期的なポーリング等により参照するアプリケーションやドライバもある。

しかしながら、このような機器情報を定期的に参照するアプリケーション等が多々導入されると、複合機の状態の如何に関わらず、多くのネットワークパケットが送受信されるようになる。そして、ネットワークパケットを受信した複合機は、その本来の機能(プリンタ機能やファクシミリ機能等)を動作させるためのアクセスではなくても、ＣＰＵ資源を利用してアクセスの内容を解釈しなければならないことになる。
従って、複合機が省電力状態に移行したとしても、ネットワークパケットを受信する度に復帰(Wake Up)する必要が生じ、省電力状態に滞留している期間が短くなってしまう。また、最悪の場合、省電力状態への遷移すらできない状態になることもある。このように、従来技術においては、環境保全を目的として設けた省電力の機能が有効に活用されないという問題点があった。

尚、特許文献１、２には、複合機に省電力状態を実装することについては記載されている。しかし、複合機の本来の機能とは関係ないアクセスがある場合における省電力状態への移行や省電力状態の維持については言及がない。従って、これらの特許文献も、上記問題点に対する有効な解決策を提示するものではない。

本発明は、以上のような技術的課題を解決するためになされたものであって、その目的は、画像処理装置の本来の機能とは関係ないアクセスがある場合にも、省電力の機能を有効に活用できるようにすることにある。
また、本発明の他の目的は、画像処理装置の本来の機能とは関係ないアクセスがある場合において、省電力の機能を活用するための対処を自動的に行えるようにすることにある。

かかる目的のもと、本発明では、省電力機能を備える画像処理装置と、端末装置とがネットワークで接続されている環境において、端末装置が、画像処理装置から送信されてくる省電力に関する状態情報に応じて、機器情報要求の送信を停止、再開するようにした。即ち、本発明の端末装置は、画像処理装置からその省電力に関する状態情報を受信する受信手段と、画像処理装置に対して画像処理を要求しないアクセスを定期的に行う処理手段と、この処理手段に対し、受信手段により受信した状態情報に応じた動作を指示する指示手段とを備えている。

また、本発明では、画像処理装置が、自装置の省電力に関する状態に基づいて、端末装置からのアクセス間隔を制御するようにした。即ち、本発明の画像処理装置は、省電力状態にあると予測される時間を特定する特定手段と、端末装置が画像処理を要求しないアクセスを特定手段により特定された時間に行わないように制御するためのアクセス抑制データを生成する生成手段と、この生成手段により生成されたアクセス抑制データを端末装置に送信する送信手段とを備えている。

更に、本発明は、省電力機能を備える画像処理装置と、端末装置とがネットワークで接続されている環境において、端末装置又は画像処理装置が、画像処理装置の省電力に関する状態情報に応じて、端末装置から画像処理装置へのアクセス動作を制御するアクセス動作制御方法として捉えることもできる。その場合、本発明のアクセス動作制御方法は、画像処理装置の省電力状態に関する状態情報を取得するステップと、取得した状態情報に応じて、端末装置から画像処理装置への画像処理を要求しないアクセスを停止し、又は、そのアクセスの間隔を決定することにより、画像処理装置が省電力状態にあるときにそのアクセスが行われないように制御するステップとを含んでいる。

一方、本発明は、端末装置に所定の機能を実現させるプログラムとして捉えることもできる。その場合、本発明のプログラムは、端末装置に、画像処理装置からその省電力に関する状態情報を取得する機能と、画像処理装置に対して画像処理を要求しないアクセスを定期的に行っている他のプログラムに対し、取得した状態情報に応じた動作を指示する機能とを実現させるためのものである。

また、本発明は、画像処理装置に所定の機能を実現させるプログラムとして捉えることもできる。その場合、本発明のプログラムは、画像処理装置に、省電力状態にあると予測される時間を特定する機能と、端末装置が画像処理を要求しないアクセスをその予測される時間に行わないように制御するためのアクセス抑制データを生成する機能と、生成されたアクセス抑制データを端末装置に送信するための処理を行う機能とを実現させるためのものである。

本発明によれば、画像処理装置の本来の機能とは関係ないアクセスがある場合にも、省電力の機能を有効に活用することが可能となる。

以下、添付図面を参照して、本発明を実施するための最良の形態(以下、「実施の形態」という)について詳細に説明する。
図１は、本実施の形態が適用されるネットワークシステムの構成を示している。
図示するように、このネットワークシステムは、ＭＦ(MultiFunction)機１０と、クライアントＰＣ(Personal Computer)２０ａ、２０ｂ、２０ｃ、…とが、ネットワーク９０で接続されることにより構成されている。

このうち、ＭＦ機１０は、コピー、スキャナ、プリンタ、ファクシミリ等の機能を１つの筐体内で実現するマルチファンクショナルな事務機器(所謂複合機)である。即ち、プリンタ機能を用いて紙面に画像を印刷したり、ファクシミリ機能を用いて他の装置に画像を送信したりする。このように、ＭＦ機１０は、画像を処理する機能を有することから、画像処理装置として捉えることができる。また、ＭＦ機１０は、コピー機能やプリンタ機能を実現するために、画像形成エンジンを備えている。従って、ＭＦ機１０は、画像形成装置と捉えることもできる。ここで、画像形成エンジンとしては、例えば、電子写真方式によるものを用いることができるが、その他の如何なる方式によるものであってもよい。

また、クライアントＰＣ２０ａ、２０ｂ、２０ｃ、…は、ＭＦ機１０に対し、プリンタ機能やファクシミリ機能を動作させるためのデータを送信する。尚、図１には、クライアントＰＣ２０ａ、２０ｂ、２０ｃ、…が示されているが、この中の任意の１台に着目して説明するときは「クライアントＰＣ２０」と表記するものとする。
更に、ネットワーク９０は、ＬＡＮ(Local Area Network)であってもよいし、インターネット等のＷＡＮ(Wide Area Network)であってもよい。

ところで、本実施の形態において、クライアントＰＣ２０には、ＭＦ機１０の機器情報をポーリングによって要求する機能を持つアプリケーションソフトウェアやプリンタドライバ等のプログラムがインストールされているものとする。ＭＦ機１０の機器情報としては、ＭＩＢ(Management Information Base)を想定する。従って、クライアントＰＣ２０は、ＳＮＭＰ(Simple Network Management Protocol)により、機器情報を要求するパケット(以下、「機器情報要求パケット」という)を送信する。ここで、機器情報の具体例としては、ＭＦ機１０における用紙、トナー等の消耗品の残量や、ＭＦ機１０で起動されているサービスに関する情報等がある。尚、この機器情報を要求するアプリケーションソフトウェア等は、ユーザの指示とは無関係にシステムのバックグランドで動作しているのが一般的である。

一方で、ＭＦ機１０は、省電力状態を実現する機能を有するものとする。つまり、ユーザによる画面操作やネットワーク９０からの画像処理の要求がある間は、通常稼動状態にあるが、このような操作や要求がない状態が一定時間続くと、省電力状態となる。例えば、機器を制御するコントローラのＣＰＵをオフにすることで省電力状態は実現できる。このようにＭＦ機１０が省電力状態にある場合に、クライアントＰＣ２０で上記のようなアプリケーションソフトウェアが動作したとする。すると、ＭＦ機１０に対し、機器情報を要求する不必要なポーリングがなされ、省電力状態の実現の妨げとなる。そこで、本実施の形態では、このような不必要なポーリングを停止したり、そのようなポーリングの間隔を調整したりすることにより、省電力状態を確実に実現できるようにする。

以下、不必要なポーリングの停止やポーリング間隔の調整等の制御を行う具体的な実施の形態について述べる。尚、図１に示したようなネットワークシステムでは、クライアントＰＣ２０が主導権を握ってこのような制御を行う場合と、ＭＦ機１０が主導権を握ってこのような制御を行う場合とがある。そこで、前者を第１の実施の形態として、また、後者を第２の実施の形態として説明する。

［第１の実施の形態］
図２は、第１の実施の形態の概略動作を示した模式図である。
本実施の形態では、図示するように、ＭＦ機１０からクライアントＰＣ２０へ、「電源ＯＮ」、「スリープ遷移」、「スリープ復帰」、「シャットダウン」等の機器状態に関する情報(以下、「状態情報」という)を送信する。ここで、「スリープ遷移」とは、通常稼動状態から省電力状態へ移行することを指し、「スリープ復帰」とは、省電力状態から通常稼動状態へ移行することを指している。
一方、クライアントＰＣ２０は、機器情報を問い合わせるポーリングを定期的に行っている。但し、本実施の形態では、ＭＦ機１０から「スリープ遷移」を受信すると、ポーリングを停止し、「スリープ復帰」を受信すると、ポーリングを再開するように制御する。

次に、かかる概略動作を行う本実施の形態について、より詳細に述べる。
まず、本実施の形態におけるＭＦ機１０の構成及び動作について説明する。
図３は、本実施の形態におけるＭＦ機１０の機能構成を示したブロック図である。
図示するように、本実施の形態におけるＭＦ機１０は、ネットワークインターフェイス(以下、「ネットワークＩ/Ｆ」という)１１と、パケット解析部１２と、履歴記憶部１３と、履歴解析部１４と、アドレス記憶部１５と、通知部１６とを備えている。
ネットワークＩ/Ｆ１１は、ＴＣＰ/ＩＰ、ＵＤＰ等のプロトコルをベースとしたネットワーク通信をサポートする。パケット解析部１２は、ネットワークＩ/Ｆ１１が受信したネットワークパケット(以下、単に「パケット」という)を解析する。履歴記憶部１３は、パケット解析部１２による解析後のパケットを履歴データとして記憶する。

履歴解析部１４は、履歴記憶部１３に記憶された履歴データの中から、ＭＦ機１０の本来の機能の動作を要求しないアクセスの履歴データを抽出する。そして、その抽出した履歴データに基づいて、機器情報要求パケットを送信しているクライアントＰＣ２０を特定する。
アドレス記憶部１５は、特定されたクライアントＰＣ２０のアドレスを記憶する。通知部１６は、アドレス記憶部１５に記憶されたアドレスに対して状態情報を送信するようネットワークＩ/Ｆ１１に指示する。

尚、これらの機能は、ソフトウェアとハードウェア資源とが協働することにより実現される。即ち、パケット解析部１２、履歴解析部１４、通知部１６は、ＭＦ機１０の図示しないＣＰＵが、これらの機能を実現するプログラムを、例えばハードディスク等の外部記憶装置からメインメモリに読み込むことにより実現される。
また、履歴記憶部１３、アドレス記憶部１５は、半導体メモリ、磁気ディスク等の種々の記憶媒体を用いて実現することができる。

次に、かかる構成を有するＭＦ機１０の動作について説明する。尚、以下の説明では、クライアントＰＣ２０が利用可能なＭＦ機１０本来の機能として、プリンタ機能のみを考えることにする。
本実施の形態では、まず、ネットワークＩ/Ｆ１１が、ネットワーク９０からパケットを受信する。そして、ＭＦ機１０宛てのパケットであれば、それを取り込み、パケット解析部１２に渡す。これにより、パケット解析部１２は、そのパケットの内容を解析し、必要に応じて返信用のパケットを構成し、ネットワークＩ/Ｆ１１に渡す。そして、ネットワークＩ/Ｆ１１は、この返信用のパケットを送信元のクライアントＰＣ２０に対して送出する。
また、パケット解析部１２は、解析が終了したパケットを、履歴データとして履歴記憶部１３に記憶する。ここで、履歴データは、クライアントＰＣ２０からのアクセスごとに、アクセスの日時と、アクセス元のクライアントＰＣ２０のアドレス(ＭＡＣアドレス)と、そのアクセスで実際に受信したパケットとを少なくとも含んでいる。

このようにして履歴データが履歴記憶部１３に記憶されると、履歴解析部１４が、この履歴データを解析する。
図４は、このときの履歴解析部１４の動作を示したフローチャートである。尚、履歴解析部１４は、ＭＦ機１０の図示しないコントローラによって定期的に起動されることにより、図４に示す処理を実行する。
動作が開始すると、まず、履歴解析部１４は、前回の解析以降に履歴記憶部１３に記憶された履歴データの中から、ＳＮＭＰによるパケット(以下、「ＳＮＭＰパケット」という)を含む履歴データを抽出してメモリに格納する(ステップ１０１)。ここで、ＳＮＭＰパケットであるかどうかは、トランスポート層のプロトコルが、ＴＣＰ/ＩＰであるかＵＤＰであるかに基づいて判定する。トランスポート層のプロトコルとして、ＳＮＭＰパケットの送受信にはＵＤＰが使用され、プリンタ機能を動作させるためのアクセスにはＴＣＰ/ＩＰが使用されるからである。尚、トランスポート層のプロトコルがＴＣＰ/ＩＰであるかＵＤＰであるかは、履歴データ中のパケットのヘッダにおける「ｔｙｐｅ」フィールドを参照することにより判別可能である。

次に、履歴解析部１４は、ＳＮＭＰパケットを含む履歴データを抽出できたかどうかを判定する(ステップ１０２)。
ここで、ＳＮＭＰパケットを含む履歴データを抽出できないと判定された場合、前回の解析以降に機器情報要求パケットを送信したクライアントＰＣ２０はないと考えられる。つまり、アクセスがあったとしても、それは、プリンタ機能を動作させるためのアクセスのみである。従って、履歴解析部１４は、機器情報要求パケットを送信しているクライアントＰＣ２０のアドレスの登録等を行うことなく、処理を終了する。

一方、ＳＮＭＰパケットを含む履歴データを抽出できたと判定された場合、履歴解析部１４は、この抽出された履歴データを送信元アドレスごとに分類してメモリに格納し直す(ステップ１０３)。
次いで、履歴解析部１４は、特定の送信元アドレスに着目し、その送信元アドレスからのＳＮＭＰパケットの送信間隔を検査する(ステップ１０４)。そして、送信間隔が一定であるかどうかを判定する(ステップ１０５)。

ここで、送信間隔が一定でないと判定された場合、その送信元アドレスからのＳＮＭＰパケットは、機器情報要求パケットではないと判定し、ステップ１０８へ進む。
一方、送信間隔が一定であると判定された場合、その送信元アドレスからのＳＮＭＰパケットは、機器情報要求パケットである可能性がある。そこで、履歴解析部１４は、一定間隔で送信されているＳＮＭＰパケットの受信後、一定時間内に、プリント機能の動作を要求するプリントジョブを伴うパケット(以下、「プリント要求パケット」という)を受信しているかどうかを判定する(ステップ１０６)。プリントジョブの実行に伴い、ポーリングがなされることもある。従って、一定の時間間隔でＳＮＭＰパケットが送信されていたとしても、その後、一定時間内にプリント要求パケットが送信されれば、これは機器情報要求パケットではないと判断できるからである。

尚、ここでいう一定時間内とは、繰り返し送信される個々のＳＮＭＰパケットの送信から一定時間内であってもよいし、今回の解析対象の履歴データにおける最後のＳＮＭＰパケットの送信から一定時間内であってもよい。
また、プリント要求パケットは、ＴＣＰ/ＩＰにより送信されるため、ステップ１０１で抽出された履歴データには含まれていない。従って、ここでは、履歴記憶部１３に記憶された履歴データの中から、各履歴データに含まれる受信日時の情報に基づいて、プリント要求パケットの存在を調査することになる。

ここで、プリント要求パケットを一定時間内に受信していると判定された場合、その送信元アドレスからのＳＮＭＰパケットは、機器情報要求パケットではないと判定し、ステップ１０８へ進む。
一方、プリント要求パケットを一定時間内に受信していないと判定された場合、着目している送信元アドレスに対応するクライアントＰＣ２０を、機器情報を参照するための不必要なポーリングを行っているクライアントＰＣ２０と特定する。そして、特定したクライアントＰＣ２０のアドレスをアドレス記憶部１５のデータベースに登録する(ステップ１０７)。即ち、ＳＮＭＰパケットであって、一定の時間間隔で送信され、プリントジョブを伴わないパケットを送出しているクライアントＰＣ２０を、不必要なポーリング動作を行っているクライアントＰＣ２０と特定しているのである。尚、このとき、履歴解析部１４は、クライアントＰＣ２０のアドレスだけでなく、実際に受信したパケットの内容を保存するようにしてもよい。

その後、履歴解析部１４は、ステップ１０３で分類した送信元アドレスの中に、未処理の送信元アドレスがあるかどうかを判定する(ステップ１０８)。
ここで、未処理の送信元アドレスがなければ、処理は終了するが、未処理の送信元アドレスがあれば、ステップ１０４〜１０７の処理を繰り返す。

以上の処理により、機器情報を参照するための不必要なポーリングを行っているクライアントＰＣ２０のアドレスがアドレス記憶部１５に記憶されると、本実施の形態では、通知部１６が、このアドレス記憶部１５に記憶されたアドレスと、そのアドレスに対して送信すべき情報とをネットワークＩ/Ｆ１１に伝える。即ち、通知部１６は、アドレス記憶部１５へのアドレスの登録とは非同期に、ＭＦ機１０の図示しないコントローラから、機器状態の変更の報告を待ち受けている。ここで、機器状態の変更とは、例えば、通常稼動状態から省電力状態への移行や、省電力状態から通常稼動状態への移行である。そして、機器状態に変更があった旨の報告を受けると、通知部１６は、アドレス記憶部１５に記憶されたアドレスに対し、ネットワークＩ/Ｆ１１を介して、その機器状態の変更の情報を送信する。
尚、このとき、通知部１６は、コントローラからの機器状態の変更の報告を待つことなく、アドレス記憶部１５にアドレスが登録された時点での状態情報をその登録されたアドレスに送信するようにしてもよい。

図５は、本実施の形態におけるクライアントＰＣ２０の機能構成を示したブロック図である。ここでは、図４の処理により不必要なポーリングを行っているクライアントＰＣ２０として特定され、ＭＦ機１０から状態情報を受信する可能性のあるクライアントＰＣ２０について示している。
図示するように、この場合のクライアントＰＣ２０は、ネットワークＩ/Ｆ２１と、アクションテーブル記憶部２２と、監視部２３と、プログラムテーブル記憶部２４と、パケット解析部２５と、動作指示部２６と、プログラム実行部２７とを備えている。
ネットワークＩ/Ｆ２１は、ネットワーク９０を介してＭＦ機１０と通信する。
アクションテーブル記憶部２２は、ＭＦ機１０の省電力状態に関する情報と、その状態にあるＭＦ機１０に対する適切な動作(アクション)とを対応付けたアクションテーブルを記憶する。

監視部２３は、プログラムによるネットワークＩ/Ｆ２１の使用状況を随時監視し、特定のアドレスに定期的にパケットを送出しているプログラムを抽出する。例えば、ＨＴＴＰ(HyperText Transfer Protocol)によりネットワーク９０上の機器にアクセスしている場合であれば、ネットワークＩ/Ｆ２１を通過するパケットのデータ領域における「Ｕｓｅｒ−Ａｇｅｎｔ」を参照することにより、使用しているブラウザを特定することができる。このようにして、ＭＦ機１０に対し、その本来の機能(プリンタ機能等)を使用するためではなく、単に機器情報を取得するためにアクセスしているプログラムが特定される。プログラムテーブル記憶部２４は、ここで抽出されたプログラムと、そのプログラムが定期的にパケットを送出している宛先のアドレスとを対応付けたプログラムテーブルを記憶する。
パケット解析部２５は、ネットワークＩ/Ｆ２１が受信したパケットを解析し、パケットの送信元アドレス及び状態情報を取り出す。動作指示部２６は、この取り出された送信元アドレスに対応付けられたプログラムに対し、同じく取り出された状態情報に応じて決定されたアクションを実行するよう指示する。プログラム実行部２７は、動作指示部２６による指示に従い、アプリケーションプログラムやプリンタドライバ等のプログラムを実行する。

尚、これらの機能は、ソフトウェアとハードウェア資源とが協働することにより実現される。即ち、監視部２３、パケット解析部２５、動作指示部２６、プログラム実行部２７は、クライアントＰＣ２０の図示しないＣＰＵが、これらの機能を実現するプログラムを、例えばハードディスク等の外部記憶装置からメインメモリに読み込むことにより実現される。
また、アクションテーブル記憶部２２、プログラムテーブル記憶部２４は、半導体メモリ、磁気ディスク等の種々の記憶媒体を用いて実現することができる。

ここで、本実施の形態におけるアクションテーブル及びプログラムテーブルの具体例を説明する。
図６は、本実施の形態におけるアクションテーブルの内容の一例を示した図である。
図示するように、アクションテーブルは、ＭＦ機１０の状態と、その状態にあるＭＦ機１０に対する適切なアクションとの対応情報を記憶するものである。
まず、状態としては、「電源ＯＮ」、「省電力状態への移行」、「省電力状態からの復帰」、「シャットダウン」が記憶されている。そして、状態が「電源ＯＮ」又は「省電力状態からの復帰」である場合に実行すべきアクションとして「ポーリング開始」が定義されており、状態が「省電力状態への移行」又は「シャットダウン」である場合に実行すべきアクションとして「ポーリング停止」が定義されている。

また、図７は、本実施の形態におけるプログラムテーブルの内容の一例を示した図である。
図示するように、プログラムテーブルは、クライアントＰＣ２０内のプログラムと、そのプログラムが定期的にアクセスしているアドレスとの対応情報を記憶するものである。このプログラムテーブルにおける情報は、上述したように、監視部２３がネットワークＩ/Ｆ２１の使用状況を随時監視することにより取得される。
ここでは、プログラムとして、「Ｐｒｏｇｒａｍ１」、「Ｐｒｏｇｒａｍ２」、「Ｐｒｏｇｒａｍ３」、「Ｐｒｏｇｒａｍ４」が記憶され、それぞれ対し、定期的にアクセスを行っている宛先のアドレスが記憶されている。

次に、かかる構成を有するクライアントＰＣ２０の動作について説明する。
本実施の形態では、まず、ネットワークＩ/Ｆ２１が、ネットワーク９０からパケットを受信し、パケット解析部２５に受け渡す。そして、パケット解析部２５が、受け渡されたパケットに状態情報が含まれているかどうかを判定する。ここで、状態情報は、パケットのデータ領域に予め定義されたコードを埋め込むことにより表現される。そして、状態情報が含まれていると判定すれば、パケット解析部２５は、パケットの送信元アドレスと、状態情報とを取り出す。

このようにしてパケットから状態情報が取り出されると、動作指示部２６の処理が開始する。
図８は、このときの動作指示部２６の動作を示したフローチャートである。尚、この動作に先立って、アクションテーブルがアクションテーブル記憶部２２に記憶され、プログラムテーブルがプログラムテーブル記憶部２４に記憶されているものとする。
まず、動作指示部２６は、パケット解析部２５からパケットの送信元アドレス及び状態情報を取得する(ステップ２０１)。

次に、動作指示部２６は、プログラムテーブル記憶部２４に記憶されたプログラムテーブルを参照する。そして、パケットの送信元アドレスに対して定義されたプログラムを特定する(ステップ２０２)。また、アクションテーブル記憶部２２に記憶されたアクションテーブルを参照する。そして、状態情報に対して定義されたアクションを決定する(ステップ２０３)。
その後、動作指示部２６は、ステップ２０２で特定したプログラムに対し、ステップ２０３で特定したアクションを行うよう指示する(ステップ２０４)。

例えば、図６のようなアクションテーブルが記憶されているとすると、以上の処理により、ＭＦ機１０に対して不必要なポーリングを行っているプログラムは、次のような動作を行う。即ち、ＭＦ機１０から受信した状態情報が「電源ＯＮ」ならばポーリングを開始し、状態情報が「省電力状態への移行」ならばポーリングを停止する。そして、状態情報が「省電力状態からの復帰」ならばポーリングを開始し、状態情報が「シャットダウン」ならばポーリングを停止する。
また、ＭＦ機１０から受信した状態情報が「省電力状態からの復帰」の場合のアクションとして「ポーリング停止」を設定しておけば、省電力状態への移行時に停止したポーリングが、省電力状態からの復帰により再開しないように制御することも可能である。
更に、図６では、アクションとして、ポーリングの停止又は開始を例示したが、これには限らない。例えば、どの程度の間隔でポーリングを行うかといったアクションを定義するようにしてもよい。

尚、上記説明では、動作指示部２６がプログラムに対し、アクションテーブルを参照して得たアクションを指示するようにした。しかしながら、動作指示部２６がプログラムにアクションを伝えるのではなく、プログラムが自らアクションテーブルを参照して動作を決定するようにしてもよい。
また、ＭＦ機１０に対してポーリングを行うのは、必ずしもプログラムである必要はない。即ち、より一般的には、処理手段として捉えることも可能である。

以上により、本実施の形態の動作は終了する。
このように、本実施の形態では、ＭＦ機１０の省電力に関する状態を考慮して、クライアントＰＣ２０が、ＭＦ機１０へのポーリング動作を制御するようにした。これにより、ＭＦ機１０が省電力状態にあるときの無用な復帰(Wake Up)を抑制すると共に、無用なネットワークトラフィックを低減させることが可能となった。

［第２の実施の形態］
第２の実施の形態において、ＭＦ機１０機は、自機の機器情報をＨＴＴＰ(HyperText Transfer Protocol)によりＨＴＭＬ(HyperText Markup Language)データとしてクライアントＰＣ２０に提供する機能を備える。ここで、機器情報としては、用紙やトナー等の消耗品の残量、起動しているサービス、ネットワークプロトコルの情報等がある。また、クライアントＰＣ２０は、このような機器情報を受信すると、汎用的に使用されているＷｅｂブラウザを用いてその情報を参照することができるようになっている。但し、ＭＦ機１０の機器情報は刻々と変化するので、クライアントＰＣ２０は、定期的にＭＦ機１０から機器情報を取得する必要がある。そのため、クライアントＰＣ２０へ送信するＨＴＭＬデータのＭＥＴＡタグに、更新(リロード)時間を設定しておく。例えば、ＨＴＭＬデータに「<META HTTP-EQUIV=“Refresh” CONTENT=“2”>という記述を含める。この場合、クライアントＰＣ２０は、ＭＦ機１０から２秒間隔で機器情報を取得し、自装置で保持する機器情報を更新することができる。

図９は、この第２の実施の形態の概略動作を示した模式図である。
ここでは、更新間隔として１０秒が設定されている。即ち、「スリープ遷移」まで十分な時間があれば、ＭＦ機１０は、更新間隔が１０秒である旨の記述を含むＨＴＭＬデータ(アクセス許可データ)をクライアントＰＣ２０へ送信している。
その後、ユーザ操作が一定時間なく、「スリープ遷移」のタイミングが近づいてきたとする。この場合、ＭＦ機１０は、更新間隔を１０００秒に変更したＨＴＭＬデータ(アクセス抑制データ)をクライアントＰＣ２０へ送信する。或いは、図の右側下方の破線内に示しているように、機器情報要求のためのアクセスを停止させてもよい。

次に、かかる概略動作を行う本実施の形態について、より詳細に述べる。
まず、本実施の形態におけるＭＦ機１０の構成及び動作について説明する。
図１０は、本実施の形態におけるＭＦ機１０の機能構成を示したブロック図である。
図示するように、本実施の形態におけるＭＦ機１０は、ネットワークＩ/Ｆ１１と、計時部１７と、移行条件記憶部１７ａと、予定時間算出部１８と、予定時間記憶部１８ａと、ＨＴＭＬ生成部１９と、更新間隔記憶部１９ａとを備えている。

ネットワークＩ/Ｆ１１は、第１の実施の形態と同様、ＴＣＰ/ＩＰ、ＵＤＰ等のプロトコルをベースとしたネットワーク通信をサポートする。
計時部１７は、ＭＦ機１０に対するユーザによる操作入力やネットワーク９０からの要求入力がない時間(以下、「無入力時間」という)を計測する。移行条件記憶部１７ａは、省電力状態に移行するための条件、つまり、無入力時間がどの程度続いたら省電力状態に移行するかを記憶する。
予定時間算出部１８は、計時部１７で計測された現在の無入力時間と、移行条件記憶部１７ａに記憶された移行条件としての無入力時間とを比較することにより、省電力状態に移行するまでの予定時間を算出する。そして、この予定時間算出部１８は、省電力状態にあると予測される時間を特定する特定手段としての機能を有する。
予定時間記憶部１８ａは、この算出された予定時間を記憶する。ＨＴＭＬ生成部１９は、クライアントＰＣ２０が機器情報を参照するために用いるＨＴＭＬデータを生成する。更新間隔記憶部１９ａは、このＨＴＭＬデータに設定するための予め定義された更新間隔を記憶する。

尚、これらの機能は、ソフトウェアとハードウェア資源とが協働することにより実現される。即ち、計時部１７、予定時間算出部１８、ＨＴＭＬ生成部１９は、ＭＦ機１０の図示しないＣＰＵが、これらの機能を実現するプログラムを、例えばハードディスク等の外部記憶装置からメインメモリに読み込むことにより実現される。
また、移行条件記憶部１７ａ、予定時間記憶部１８ａ、更新間隔記憶部１９ａは、半導体メモリ、磁気ディスク等の種々の記憶媒体を用いて実現することができる。

次に、かかる構成を有するＭＦ機１０の動作について説明する。
図１１は、本実施の形態におけるＭＦ機１０の動作を示したフローチャートである。
まず、初期状態において、ＭＦ機１０は、通常稼働状態にあるものとする。つまり、全てのコントローラは稼働中であり、ネットワーク９０からのデータの受信待ちをしている。そして、データを受信すると動作が開始する。
即ち、まず、ネットワークＩ/Ｆ１１は、クライアントＰＣ２０からＨＴＴＰのＧＥＴコマンドによる機器情報要求を受信する(ステップ１１１)。これにより、ＭＦ機１０の図示しない情報収集部が、要求された機器状態を収集し、ＨＴＭＬ生成部１９に渡しておく。

次に、予定時間算出部１８は、省電力状態に移行するまでの時間を予測する処理を行う。ＭＦ機１０は、ユーザによるＵＩ操作、ネットワーク９０を介したジョブの送受信が最後に行われた時間からの経過時間に基づいて、省電力状態に移行する。従って、まず、予定時間算出部１８は、現時点での無入力時間を計時部１７から取得する(ステップ１１２)。
また、予定時間算出部１８は、移行条件記憶部１７ａを参照し、省電力状態への移行のために必要な無入力時間として予め定義された時間を取得する(ステップ１１３)。
そして、予定時間算出部１８は、ステップ１１３で取得した時間からステップ１１２で取得した時間を減ずることにより、省電力状態へ移行するまでの予定時間を算出する。そして、算出された予定時間を予定時間記憶部１８ａに記憶する(ステップ１１４)。

その後、ＨＴＭＬ生成部１９は、予定時間記憶部１８ａに記憶された予定時間を読み出す(ステップ１１５)。また、更新間隔記憶部１９ａに記憶された更新間隔を読み出す(ステップ１１６)。そして、ＨＴＭＬ生成部１９は、ステップ１１５で読み出した予定時間とステップ１１６で読み出した更新間隔とを比較する。例えば、前者の時間が、後者の時間よりも長いかどうか判定する(ステップ１１７)。
ここで、前者の方が長いと判定された場合は、更新間隔記憶部１９ａから読み出したデフォルトの更新間隔を含むＭＥＴＡタグと、ステップ１１１の後に受け渡された機器情報とから、ＨＴＭＬデータを生成する(ステップ１１８)。次の更新時にはまだＭＦ機１０は省電力状態へ移行していないので、省電力状態が阻害されることはないからである。

一方、後者の方が長いと判定された場合は、更新間隔記憶部１９ａから読み出した更新間隔よりも十分に長い更新間隔を含むＭＥＴＡタグと、ステップ１１１の後に受け渡された機器情報とから、ＨＴＭＬデータを生成する(ステップ１１９)。ＭＦ機１０は程なく省電力状態へ移行してしまうので、そのままの更新間隔を設定しておくと、省電力状態からの無用な復帰が生じてしまうからである。つまり、新たな更新間隔を設定することで、省電力状態が阻害されなくなるのである。尚、ここで設定する十分に長い更新時間とは、省電力状態へ移行してから復帰するまでの時間として経験的又は統計的に想定される時間よりも長い時間を設定することが望ましい。

そして、最後に、ネットワークＩ/Ｆ１１が、この生成されたＨＴＭＬデータを送信する(ステップ１２０)。ここでのＨＴＭＬデータの送信先は、ステップ１１１でＨＴＴＰのＧＥＴコマンドを送信してきたクライアントＰＣ２０である。
尚、以上の説明では、更新間隔を予め定義した間隔よりも長くしたが、これには限らない。即ち、クライアントＰＣ２０が機器情報を更新するためにＭＦ機１０に対して行うアクセスを強制的に停止させてもよい。省電力状態へ移行するということは電力状態が変更されるだけで、消耗品残量等は変動しないため、クライアントＰＣ２０側で機器情報を更新しなくても問題は生じない。

以上により、本実施の形態の動作は終了する。
このように、本実施の形態では、ＭＦ機１０の省電力に関する状態を考慮して、ＭＦ機１０が、クライアントＰＣ２０からのポーリング動作を制御するようにした。これにより、ＭＦ機１０が省電力状態にあるときの無用な復帰(Wake Up)を抑制すると共に、無用なネットワークトラフィックを低減させることが可能となった。特に、ＭＦ機１０がクライアントＰＣ２０に機器情報を提供する場合において、クライアントＰＣ２０がＭＦ機１０に機器情報を要求する間隔を一定にしてしまうと、ＭＦ機１０が省電力状態になった場合に、その省電力状態を阻害してしまう。本実施の形態は、このような場合の問題点を解決するものである。

尚、第１及び第２の実施の形態では、ＭＦ機１０における省電力状態の実現を阻害するアクセスとして、機器情報を参照するアクセスを例示したが、これには限らない。即ち、ＭＦ機１０本来の機能を使用しないアクセスであれば、機器情報を参照するアクセス以外のアクセスを、省電力状態を阻害するアクセスと捉えてもよい。

本発明の実施の形態が適用されるネットワークシステムの構成を示した図である。 本発明の第１の実施の形態の概略動作を説明するための図である。 本発明の第１の実施の形態におけるＭＦ機の機能構成を示したブロック図である。 本発明の第１の実施の形態におけるＭＦ機の履歴解析部の動作を示したフローチャートである。 本発明の第１の実施の形態におけるクライアントＰＣの機能構成を示したブロック図である。 本発明の第１の実施の形態で用いるアクションテーブルの内容の例を示した図である。 本発明の第１の実施の形態で用いるプログラムテーブルの内容の例を示した図である。 本発明の第１の実施の形態におけるクライアントＰＣの動作指示部の動作を示したフローチャートである。 本発明の第２の実施の形態の概略動作を説明するための図である。 本発明の第２の実施の形態におけるＭＦ機の機能構成を示したブロック図である。 本発明の第２の実施の形態におけるＭＦ機の動作を示したフローチャートである。

符号の説明

１０…ＭＦ機、２０ａ、２０ｂ、２０ｃ…クライアントＰＣ

Claims (6)

1. ネットワークを介して接続された端末装置の要求に応じて画像処理を行う画像処理装置であって、
   省電力状態に移行するまでの予定時間を算出する算出手段と、
   前記端末装置が前記画像処理を要求しないアクセスを行う時間間隔として予め定義された所定の時間間隔を取得する取得手段と、
   前記算出手段により算出された前記予定時間が前記取得手段により取得された前記所定の時間間隔よりも長ければ、前記アクセスを当該所定の時間間隔で行うように制御するためのアクセス許可データを生成し、前記算出手段により算出された前記予定時間が前記取得手段により取得された前記所定の時間間隔よりも短ければ、前記アクセスを当該所定の時間間隔よりも長い時間間隔で行うように制御するためのアクセス抑制データを生成する生成手段と、
   前記生成手段により生成された前記アクセス許可データ又は前記アクセス抑制データを前記端末装置に送信する送信手段と
   を備えたことを特徴とする画像処理装置。
2. 前記生成手段は、前記アクセス許可データに含まれる前記所定の時間間隔を、当該所定の時間間隔よりも長い時間間隔に変更することにより、前記アクセス抑制データを生成することを特徴とする請求項１記載の画像処理装置。
3. 前記生成手段は、前記アクセス許可データに含まれる前記所定の時間間隔を、省電力状態へ移行してから復帰するまでの時間よりも長い時間間隔に変更することにより、前記アクセス抑制データを生成することを特徴とする請求項２記載の画像処理装置。
4. 前記アクセス許可データ及び前記アクセス抑制データは、ＨＴＭＬ(HyperText Markup Language)で記述されており、前記時間間隔は、ＭＥＴＡタグ内に記述されていることを
   特徴とする請求項２記載の画像処理装置。
5. ネットワークを介して接続された端末装置の要求に応じて画像処理を行う画像処理装置において、
   省電力状態に移行するまでの予定時間を算出するステップと、
   前記端末装置が前記画像処理を要求しないアクセスを行う時間間隔として予め定義された所定の時間間隔を取得するステップと、
   算出された前記予定時間が取得された前記所定の時間間隔よりも長ければ、前記アクセスを当該所定の時間間隔で行うように制御するためのアクセス許可データを生成し、算出された前記予定時間が取得された前記所定の時間間隔よりも短ければ、前記アクセスを当該所定の時間間隔よりも長い時間間隔で行うように制御するためのアクセス抑制データを生成するステップと、
   生成された前記アクセス許可データ又は前記アクセス抑制データを前記端末装置に送信するステップと
   を含むことを特徴とするアクセス動作制御方法。
6. ネットワークを介して接続された端末装置の要求に応じて画像処理を行う画像処理装置に対し、
   省電力状態に移行するまでの予定時間を算出する機能と、
   前記端末装置が前記画像処理を要求しないアクセスを行う時間間隔として予め定義された所定の時間間隔を取得する機能と、
   算出された前記予定時間が取得された前記所定の時間間隔よりも長ければ、前記アクセスを当該所定の時間間隔で行うように制御するためのアクセス許可データを生成し、算出された前記予定時間が取得された前記所定の時間間隔よりも短ければ、前記アクセスを当該所定の時間間隔よりも長い時間間隔で行うように制御するためのアクセス抑制データを生成する機能と、
   生成された前記アクセス許可データ又は前記アクセス抑制データを前記端末装置に送信するための処理を行う機能と
   を実現させるためのプログラム。

Images