画像形成装置、画像形成装置の制御方法、及びプログラム
【課題】スリープ状態から復帰した機器から不正なネットワークパケットを送信せず、且つ、機器を管理する管理アプリケーションも機器の状態を不整合なく正確に管理することができる機器管理環境を構築すること。
【解決手段】画像形成装置１をスリープ状態に移行する場合に、スリープ通知制御部２０６が画像形成装置１が受信するデータをプロトコルスタック２０１で破棄する受信フィルタ制御処理機能を有効にし、該受信フィルタ制御処理機能を有効にした後に、スリープ通知送信部２０７がプロトコルスタック２０１を介してスリープ通知をスリープ通知先ＤＢ２０８に登録されている宛先へ送信し、該スリープ通知の完了の後に、スリープ通知制御部２０６が送信フィルタ制御処理機能を有効にし、該送信フィルタ制御処理機能を有効にした後に、スリープ制御部２０５が画像形成装置１をスリープ状態に移行させる。
【解決手段】画像形成装置１をスリープ状態に移行する場合に、スリープ通知制御部２０６が画像形成装置１が受信するデータをプロトコルスタック２０１で破棄する受信フィルタ制御処理機能を有効にし、該受信フィルタ制御処理機能を有効にした後に、スリープ通知送信部２０７がプロトコルスタック２０１を介してスリープ通知をスリープ通知先ＤＢ２０８に登録されている宛先へ送信し、該スリープ通知の完了の後に、スリープ通知制御部２０６が送信フィルタ制御処理機能を有効にし、該送信フィルタ制御処理機能を有効にした後に、スリープ制御部２０５が画像形成装置１をスリープ状態に移行させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成装置における状態遷移時のパケット制御技術に関する。
【背景技術】
【０００２】
近年、画像形成装置等の機器が消費する電力を低減するため、稼動していない状態が一定時間以上経過した場合は、電力の供給を機器の一部に限定し低電力で動作する「スリープ状態」へ遷移する省電力機能が進歩している。
【０００３】
また、ネットワーク技術の普及に伴い、ネットワークを利用して機器とホスト間で定期的にデータのやりとりを行う状況が想定される。機器が「スリープ状態」であっても、このようなネットワーク経由のデータの処理を行うために、機器に複数のＣＰＵを搭載し、非スリープ時にはメインＣＰＵで処理を行うが、スリープ時には、電力消費の小さいサブＣＰＵでメインＣＰＵの処理を代替させる手法が考えられている（特許文献１参照）。
【０００４】
このようなシステムでは、サブＣＰＵは受信したネットワークパケットに対して代理応答するか破棄するか、メインＣＰＵをスリープ状態から復帰させるかを判断し処理する機能を有している。
【０００５】
一方、近年、機器の多機能化に伴い、機器を制御するメインＣＰＵには多くのドライバが搭載されている。その為、スリープ状態に遷移する場合、これらのドライバに対してスリープ状態遷移の為の停止処理を実施する必要がある。また、機器が画像形成装置である場合、定着器等のエンジンを停止するための処理も必要となる。
【０００６】
これらの処理を実施するには数秒間の時間が必要である。つまり、機器がスリープ移行を決定してから、実際にスリープ移行するまで、スリープ準備処理を実行している時間が数秒間発生していた。
【０００７】
このスリープ準備中にメインＣＰＵが外部ホストからネットワークパケットを受信すると、タイミングによってはプロトコルスタック、あるいはアプリケーションで処理中に機器がスリープ状態に遷移してしまう場合がある（図７参照）。
【０００８】
図７のように、スリープ移行（７１０）している間では、画像形成装置７０１は、外部ホスト７０２から処理を要求するリクエストパケット（ＳＮＭＰ Ｒｅｑｕｅｓｔ）７１１を受信しても、プロトコルスタックあるいはアプリケーションで処理中に、スリープ状態に遷移する（７１２）。そして、次にスリープ復帰（７１３）した瞬間にリクエストパケット７１１の処理を進め、応答パケット（７１４）を外部ホスト７０２に送信する。
【０００９】
しかし、次にスリープ復帰した際にパケット処理を進めて応答パケットを送信しても、一定時間が経過しているため応答したパケットの内容が不正になる、あるいは外部ホスト７０２から見れば意図しない時間に応答パケットが来るため攻撃パケットとみなされる可能性もある。
【００１０】
そのため、メインＣＰＵではスリープ準備処理中の送受信パケットをドライバあるいはプロトコルスタックレベルで破棄するという処理が一般的である（図８参照）。
図８のように、スリープ移行（８１０）している間では、画像形成装置８０１は、外部ホスト８０２から処理を要求するリクエストパケット（ＳＮＭＰ Ｒｅｑｕｅｓｔ）８１１を受信しても、パケットを破棄し（８１２）、スリープ状態に遷移する（８１３）。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００６−２５９９０６号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかしながら、従来のスリープ遷移中に送受信パケットを破棄する制御では、機器を管理する管理アプリケーションが正確に機器管理できない問題が発生してしまう（図９参照）。
【００１３】
近年の機器管理アプリケーションは、機器のスリープ状態も把握する機能が一般的である。例えば、機器が何時にスリープ状態に遷移したか、何時にスリープ状態から復帰したかを管理することで機器の消費電力を計算し、ユーザに提示する機能等がある。
【００１４】
そのため、機器はスリープ状態に遷移する直前や、スリープ状態から復帰した直後は管理アプリケーションに対して通知パケットを送信する機能を有している。しかし、前述のように機器においてスリープ状態遷移中は送受信パケットを破棄するため、実際にスリープ状態移行通知パケットを送信するのは状態遷移前となる。
【００１５】
例えば、機器が２種類のスリープ状態通知機能を有しているとする。１つはマルチキャストでスリープ状態通知を行うプロトコルであり、もう１つは予め登録されたホストに対してユニキャストのＴＣＰあるいはＵＤＰでスリープ状態通知を行うプロトコルとする。
【００１６】
スリープ状態への遷移が仮決定したら、図９のように、機器（９０１）は、まずマルチキャストパケットで管理アプリケーションに対してスリープ通知を行う（９１０）。管理アプリケーションは、スリープ通知パケットを受信したら、機器の状態を「通常状態」から「スリープ状態」に変更する。
【００１７】
次に、機器（９０１）は、予め登録されているホストに対してユニキャストで１台１台にスリープ通知を行っていく（９１１，９１２）。もしこの間に、ある外部ホストから機器に対してネットワークアクセス（９１３）が発生すると、機器（９０１）はスリープ状態への移行を延期してしまう（９１４）。例えば、あるホストから印刷処理が実行された場合、機器は、印刷が完了し機器のハードディスク保護時間が経過するまではスリープ状態へ遷移しない（９１５）。
【００１８】
このような場合、機器の管理アプリケーションではスリープ通知（９１０）を受信したのに、実際に機器はスリープ状態に遷移していない、という管理不整合（９１６）が発生してしまう問題があった。
【００１９】
本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、スリープ状態から復帰した機器から不正なネットワークパケットを送信せず、且つ、機器を管理する管理アプリケーションも機器の状態を不整合なく正確に管理することができる仕組みを提供することである。
【課題を解決するための手段】
【００２０】
本発明は、画像形成装置であって、ネットワークを介して外部装置とデータの送受信を行う送受信手段とを有する画像形成装置であって、前記画像形成装置をスリープ状態に移行させるスリープ手段と、前記スリープ状態に移行する旨を通知する宛先を記憶する記憶手段と、前記スリープ状態に移行する場合に、前記画像形成装置が受信するデータを前記送受信手段で破棄する受信フィルタ制御処理を有効にする受信データ破棄設定手段と、前記受信フィルタ制御処理を有効にした後に、前記送受信手段を介して、前記画像形成装置がスリープ状態に移行する旨を示すスリープ通知を前記記憶手段に登録されている宛先へ送信する通知手段と、前記スリープ通知の完了の後に、前記画像形成装置から送信するデータを前記送受信手段で破棄する送信フィルタ制御処理を有効にする送信データ破棄設定手段とを有し、前記スリープ手段は、前記送信フィルタ制御処理を有効にした後に、前記画像形成装置をスリープ状態に移行させることを特徴とする。
【発明の効果】
【００２１】
本発明によれば、スリープ状態から復帰した画像形成装置から不正なネットワークパケットを送信せず、且つ、画像形成装置を管理する管理アプリケーションも画像形成装置の状態を不整合なく正確に管理することができる。
【図面の簡単な説明】
【００２２】
【図１】本発明の一実施例を示す画像形成装置のハードウェア構成の一例を示すブロック図である。
【図２】図１に示した画像形成装置１のソフトウェア構成の一例を示すブロック図である。
【図３】図２に示した画像形成装置ソフトウェア２の動作の一例を示すフローチャートである。
【図４】実施例１のスリープ通知先ＤＢ２０８の一例を示す図である。
【図５】実施例１におけるネットワークシーケンスの一例を示す図である
【図６】実施例２のスリープ通知先ＤＢ２０８の一例を示す図である。
【図７】従来のネットワークシーケンスの一例を示す図である
【図８】従来のネットワークシーケンスの一例を示す図である
【図９】従来のネットワークシーケンスの一例を示す図である
【発明を実施するための形態】
【００２３】
以下、本発明を実施するための最良の形態について図面を用いて説明する。ここでは、本発明の機器として、画像形成装置を例に説明する。
【実施例１】
【００２４】
実施例１として、本発明を適用した画像形成装置がＵＤＰを用いてスリープ通知を送信する場合について説明する。
図１は、本発明の一実施例を示す画像形成装置のハードウェア構成の一例を示すブロック図である。
図１に示すように、本実施例の画像形成装置１は、コントローラ１００、スキャナ１１１、プリンタエンジン１１２、オペレーションパネル１１３を有する。
ＲＯＭ１０３のプログラム用ＲＯＭには、ＣＰＵ１０９が実行可能な制御プログラム等が記録されている。ＲＯＭ１０３のデータ用ＲＯＭには、画像形成装置１で利用される情報等が記録されている。
【００２５】
ＣＰＵ１０９は、ＲＯＭ１０３のプログラム用ＲＯＭにコンピュータ読み取り可能に記録された制御プログラムに基づいて、システムバス１１０に接続される各種のデバイスとのアクセスを総括的に制御する。
【００２６】
また、ＣＰＵ１０９は、プリンタＩ／Ｆ１０６を介して接続されるプリンタエンジン１１２に出力情報としての画像信号を出力したり、スキャナＩ／Ｆ１０１を介して接続されるスキャナ１１１から入力される画像信号を制御する。
【００２７】
ＲＡＭ１０４は、主としてＣＰＵ１０９の主メモリ，ワークエリア等として機能する。なお、ＲＡＭ１０４は、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。
【００２８】
ハードディスク（ＨＤＤ）１０５は、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶、プリントジョブを一時的にスプールし、スプールされたジョブを外部から制御するためのジョブ格納領域として使用される。また、ＨＤＤ１０５は、スキャナ１１１から読み取った画像データやプリントジョブの画像データをＢＯＸデータとして保持し、ネットワークから参照、印刷を行うＢＯＸデータ格納領域としても使用される。
【００２９】
不揮発性メモリ（ＮＶＲＡＭ）１０７は、オペレーションパネル１１３で設定される各種設定情報をパネル制御部１０８経由で記憶している。ネットワークインタフェース（ＮＷ Ｉ／Ｆ）１０２は、ネットワークケーブルを経由して外部ネットワーク１２０とデータ通信を行う。
【００３０】
図２は、図１に示した画像形成装置１のソフトウェア構成の一例を示すブロック図である。
図２に示す画像形成装置ソフトウェア２は、画像形成装置１のＣＰＵ１０９がＲＯＭ１０３にコンピュータ読み取り可能に記録されたプログラムを読み出して実行することにより実現される機能である。
【００３１】
図２に示すように、画像形成装置ソフトウェア２の構成は、大きく分けて、カーネル空間で動作するカーネル部分と、ユーザ空間で動作するアプリケーション部分（アプリケーション２０２）とに分けられる。このカーネル部分にネットワーク送受信を制御するネットワークプロトコルスタック（プロトコルスタック２０１）が搭載されている。
【００３２】
まず、アプリケーション２０２について説明する。
アプリケーション２０２は、スリープ制御部２０５、スリープ通知制御部２０６、スリープ通知送信部２０７、スリープ通知先ＤＢ２０８を有する。
スリープ制御部２０５は、画像形成装置の全ユニットに電力が供給されている「通常状態」から、１部のユニットへのみ電力が供給される「スリープ状態」に移行するかどうかの制御を行う。スリープ状態に移行すると決定した場合、スリープ制御部２０５は、スリープ通知制御部２０６へスリープ移行決定の情報を通知する。
【００３３】
スリープ通知制御部２０６は、スリープ移行決定の情報の通知を受けると、スリープ通知送信部２０７を介して外部ホスト宛にスリープ通知パケットを送信する。スリープ通知パケットのフォーマットは、Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＬＰ）などの汎用プロトコルを使用してもよいし、独自プロトコルを定義してもよい。この時、スリープ通知を送信する宛先は、スリープ通知先ＤＢ２０８に格納されている宛先ＩＰアドレスに基づいて決定される。
【００３４】
同様に、スリープ制御部２０５は、「スリープ状態」から「通常状態」に復帰した場合、スリープ通知制御部２０６へスリープ復帰の情報を通知する。
スリープ通知制御部２０６は、スリープ復帰の情報の通知を受けると、スリープ通知送信部２０７を介して外部ホスト宛にスリープ復帰通知パケットを送信する。
【００３５】
次に、プロトコルスタック２０１について説明する。
プロトコルスタック２０１は、ＩＰヘッダやＴＣＰヘッダを解釈し、アプリケーション２０２と外部ホストとのデータ通信のパケット制御を行う。プロトコルスタック２０１は、受信フィルタ制御部２０４、送信フィルタ制御部２０３を有する。
【００３６】
受信フィルタ制御部２０４は、特定の宛先からのアクセスや特定のポート番号へのアクセスに対して、受信パケットの破棄、許可を処理できる機能（受信フィルタ制御処理機能）を有する。同様に、送信フィルタ制御部２０３は、特定の宛先へのアクセスやポート番号への送信に対して、送信パケットの破棄、許可を処理できる機能（送信フィルタ制御処理機能）を有する。
【００３７】
本実施例では、物理層であるドライバレベルでフィルタ制御する例を説明するが、本制御は、物理層、ＩＰ層、ＴＣＰ／ＵＤＰ層、アプリケーション層いずれのレイヤーで実施されてもよい。
【００３８】
以下、図３を用いて、画像形成装置ソフトウェア２の動作について説明する。
図３は、図２に示した画像形成装置ソフトウェア２の動作の一例を示すフローチャートである。即ち、本フローチャートの動作は、画像形成装置１のＣＰＵ１０９がＲＯＭ１０３にコンピュータ読み取り可能に記録されたプログラムを読み出して実行することにより実現されるものである。
【００３９】
Ｓ３０１において、スリープ制御部２０５は、画像形成装置１がスリープ状態に移行できるかどうかを判断する。スリープ状態移行の判断基準としては、例えば、最後にハードディスク１０５にアクセスしてから、ハードディスク保護時間が経過しているか否か等で判断を行うものとする。
【００４０】
前記Ｓ３０１において、スリープ移行可能でないと判断した場合（Ｎｏ）、スリープ制御部２０５は、Ｓ３０１に処理を戻す。
一方、前記Ｓ３０１において、スリープ移行可能と判断した場合（Ｙｅｓ）、スリープ制御部２０５は、スリープ通知制御部２０６にスリープ移行可能の旨を通知する。
【００４１】
スリープ移行可能の旨の通知を受けると、スリープ通知制御部２０６は、Ｓ３０２において、プロトコルスタック２０１の受信フィルタ制御部２０４を起動させ、受信パケットを全て破棄する処理（受信フィルタ制御処理）の設定（受信データ破棄設定）を有効にする。
【００４２】
次に、Ｓ３０３において、スリープ通知制御部２０６は、スリープ通知先ＤＢ２０８を参照し、スリープ通知を送信すべき宛先が存在するか否かを判断する。スリープ通知先ＤＢ２０８は、例えば図４のようなリストとなっている。
【００４３】
図４は、実施例１のスリープ通知先ＤＢ２０８の一例を示す図である。
図４に示すように、スリープ通知先ＤＢ２０８が管理する通知先データ（宛先）は、宛先ＩＰアドレス、プロトコル種別（例えば、ＳＬＰ）、トランスポート種別（例えば、ＵＤＰ）、パターン（例えば、マルチキャスト、ユニキャスト）を含むものとする。
【００４４】
例えば、図４のＮｏ１には、ＳＬＰマルチキャストでスリープ通知送信を行うための宛先が格納されている。また、Ｎｏ２には、１９２．１６８．１．１に対してＵＤＰを使用してＳＬＰユニキャストでスリープ通知送信を行うための宛先が格納されている。また、Ｎｏ３には、１９２．１６８．１．２に対してＵＤＰを使用してＳＬＰユニキャストでスリープ通知送信を行うための宛先が格納されている。また、Ｎｏ４には、１９２．１６８．１．３に対してＵＤＰを使用してＳＬＰユニキャストでスリープ通知送信を行うための宛先が格納されている。なお、スリープ通知先ＤＢ２０８が管理する通知先データは、ポート番号やアドレスファミリー（ＡＦ_ＩＮＥＴ、ＡＦ_ＩＮＥＴ６等）等の属性を含んでいてもよい。
なお、スリープ通知先ＤＢ２０８は、工場出荷時等に予めＲＯＭ１０３等に格納されている静的な宛先と、ユーザにより登録される動的な宛先を記憶管理している。
【００４５】
以下、図３の説明にもどる。
前記Ｓ３０３において、送信すべき宛先が存在すると判断した場合（Ｙｅｓ）、スリープ通知送信部２０７は、Ｓ３０４に処理を進める。
Ｓ３０４では、スリープ通知送信部２０７は、前記スリープ通知先ＤＢ２０８に存在する宛先を読み出して、該宛先にスリープ通知を送信する。
【００４６】
送信が完了したら、Ｓ３０５において、スリープ通知送信部２０７は、次の宛先が存在するかスリープ通知先ＤＢ２０８を参照する。
なお、上記Ｓ３０２で受信パケット破棄設定を有効にされた受信フィルタ制御部２０４は、前記Ｓ３０３〜Ｓ３０５の手順の間に、外部ホストからネットワークパケットを受信したと判断した場合（Ｓ３０６でＹｅｓ）、受信フィルタ制御部２０４が受信パケットを破棄する（Ｓ３０７）。この処理によって、機器はネットワーク受信によってスリープ移行が延期されることを防止できる。
【００４７】
次に、スリープ通知送信部２０７は、Ｓ３０３に処理を戻し、前記Ｓ３０５での次の宛先の参照結果に基づいて、次にスリープ通知を送信すべき宛先が存在するか否かを判断する。そして、送信すべき宛先が存在する間（Ｓ３０３でＹｅｓの間）、スリープ通知送信部２０７は、Ｓ３０４〜Ｓ３０５の処理を繰り返す。
【００４８】
図４に示した例の場合、まずＳＬＰマルチキャストでスリープ通知を送信する。次に、１９２．１６８．１．１に対してＵＤＰを使用してＳＬＰユニキャストでスリープ通知を送信する。次に、１９２．１６８．１．２に対してスリープ通知を送信する。さらに、１９２．１６８．１．３に対してスリープ通知を送信する。これにより、スリープ通知を受信した管理アプリケーション側は、画像形成装置１の状態をスリープ状態として管理を始める。
【００４９】
そして、前記Ｓ３０３において、次にスリープ通知を送信すべき宛先が存在しないと判断した場合（Ｎｏ）、スリープ通知送信部２０７は、Ｓ３０８に処理を進める。
Ｓ３０８において、スリープ通知制御部２０６は、プロトコルスタック２０１の送信フィルタ制御部２０３を起動させ、送信パケットを全て破棄する処理（送信フィルタ制御処理）の設定（送信データ破棄設定）を有効にする。さらに、スリープ通知制御部２０６は、スリープ制御部２０５に対して、スリープ通知およびフィルタ制御が完了した旨の通知を行う。
【００５０】
スリープ制御部２０５は、スリープ通知制御部２０６からスリープ通知およびフィルタ制御が完了した旨の通知を受けると、Ｓ３０９において、スリープ移行処理を開始し、移行処理が完了次第、スリープ状態に移行する（Ｓ３１０）。
【００５１】
スリープ制御部２０５は、スリープ状態から復帰した場合（Ｓ３１１でＹｅｓ）、スリープ通知制御部２０６に対して、スリープ状態から復帰した旨の通知を行う。
スリープ状態から復帰した旨の通知を受けると、スリープ通知制御部２０６は、Ｓ３１２において、前記Ｓ３０２で有効にしていた受信フィルタ制御部２０４の受信パケット破棄の設定、及び前記Ｓ３０８で有効にしていた送信フィルタ制御部２０３の送信パケット破棄の設定をそれぞれ無効にする。
【００５２】
次に、Ｓ３１３において、スリープ通知制御部２０６は、スリープ通知送信部２０７を介して、スリープ通知先ＤＢ２０８に格納されている全ての宛先に対して、スリープ復帰通知を送信する。図４に示した例の場合、まずＳＬＰマルチキャストでスリープ復帰通知を送信する。次に、１９２．１６８．１．１に対してＵＤＰを使用してＳＬＰユニキャストでスリープ復帰通知を送信する。次に、１９２．１６８．１．２に対してスリープ復帰通知を送信する。さらに、１９２．１６８．１．３に対してスリープ復帰通知を送信する。これにより、スリープ復帰通知を受信した管理アプリケーション側は、画像形成装置１の状態を通常状態として管理を始める。
【００５３】
以下、図５を用いて、具体的例を示す。
図５は、実施例１におけるネットワークシーケンスの一例を示す図である
図３に示した処理を実行することで、図５のように、スリープ通知（５１１〜５１３）を送信している間では、画像形成装置１は、外部ホスト５０１から印刷処理を要求するＬＰＤリクエストパケット（ＬＰＤ Ｐｒｉｎｔ Ｒｅｑｕｅｓｔ）５１４を受信しても、受信パケット破棄設定が有効（５１０）になっているので、印刷を受け付けることなく受信パケットを破棄する（５１５）。
【００５４】
そのため画像形成装置１は、スリープ通知を送信した場合は、必ずスリープ状態に移行することができるため（５１６）、管理アプリケーションへの通知と実際の画像形成装置１の状態との間の不整合を解消できる。
【００５５】
また、管理アプリケーション側でもスリープ通知を受信したのに、画像形成装置１がスリープ状態に移行していない、という不整合が発生することもない。
図５に示した例では、外部ホストから印刷要求リクエストを受信した場合であったが、特にプロトコルを限定することはなく本発明を適用できる。
【００５６】
なお、プロトコル処理によってスリープ移行をどれだけの時間延期させるかは、機器構成によって異なるものとする。例えば、ＨＤＤにアクセスするようなプロトコル受信の場合は、少なくともハードディスク保護時間分はスリープ移行時間を延期しなければならない。また、ＳＮＭＰやＳＬＰ等の機器の情報取得系のプロトコルであれば連続してアクセスしてくる可能性があるため、一般的には数十秒間はスリープ移行しないように時間を延期する。
【００５７】
なお、機器は画像形成装置に限定されるものではなくスリープ状態に遷移するネットワーク機器であれば、本発明を適用可能である。
以上示したように、本実施例によれば、スリープ状態に遷移する機器において不正なネットワークパケットの送信を防止し、かつ機器を管理する管理アプリケーションも機器の状態を不整合なく正確に管理することができるネットワーク環境を構築することができる。
【００５８】
なお、スリープ通知制御部２０６は、画像形成装置１がスリープ状態に遷移する直前に、前記Ｓ３０２で有効にしていた受信フィルタ制御部２０４の受信パケット破棄の設定、及び前記Ｓ３０８で有効にしていた送信フィルタ制御部２０３の送信パケット破棄の設定をそれぞれ無効にするように構成してもよい。この構成の場合、スリープ通知制御部２０６は、スリープ復帰した場合に、Ｓ３１２の送受信パケット破棄設定の無効処理を行うことなく、Ｓ３１３のスリープ復帰通知の送信を行うものとする。
【実施例２】
【００５９】
実施例２では、本発明を適用した画像形成装置１がＴＣＰを用いてスリープ通知を送信する場合について説明する。
図６は、実施例２のスリープ通知先ＤＢ２０８の一例を示す図である。
図６に示す例の場合、画像形成装置１は、まずＳＬＰマルチキャストでスリープ通知を送信する。次に、１９２．１６８．１．１に対してＴＣＰを使用してＳＬＰユニキャストでスリープ通知を送信する。次に、１９２．１６８．１．２に対してＵＤＰを使用してＳＬＰユニキャストでスリープ通知を送信する。さらに、１９２．１６８．１．３に対してＴＣＰを使用してＳＬＰユニキャストでスリープ通知を送信する。
【００６０】
即ち、スリープ通知先ＤＢ２０８に図６のように宛先が登録されている場合、画像形成装置１は、１９２．１６８．１．１や１９２．１６８．１．３に対して、スリープ通知をＴＣＰで送信する必要がある。管理アプリケーションによっては、確実に通知を受信したいため、ＴＣＰでスリープ通知を送信してほしい場合がある。
【００６１】
このような場合、画像形成装置１が図３のＳ３０４において、１９２．１６８．１．１に対してＴＣＰでスリープ通知を送信すると、まずはＴＣＰ ＳＹＮパケットが送信される。ＳＹＮに対して、１９２．１６８．１．１がＳＹＮ ＡＣＫの応答を画像形成装置１に対して送信すると、実施例１の構成では、受信フィルタ制御部２０４で破棄設定が有効になっているので、受信フィルタ制御部２０４がＳＹＮ ＡＣＫパケットを破棄してしまう。そのため、ＴＣＰセッションが確立せずに、ＴＣＰでスリープ通知を登録していた１９２．１６８．１．１や１９２．１６８．１．３の宛先に対しては、スリープ通知することができない。
【００６２】
この問題を解決するために、実施例２では、ＴＣＰでスリープ通知を登録している宛先が存在する場合、プロトコルスタック２０１において、ステートフルインスペクション機能を有効にして、受信フィルタ制御処理を実行する。例えば、図３のＳ３０２において受信パケット破棄設定を有効にする場合に、スリープ通知制御部２０６が、ＴＣＰでスリープ通知を登録している宛先が存在するか判定し、存在する場合、受信フィルタ制御部２０４のステートフルインスペクション機能も有効に設定する。
【００６３】
ステートフルインスペクション機能とは、例えば画像形成装置１がクライアントとなってリクエストパケットデータを送信する場合、該送信したパケットデータをログとして保管しておき、受信フィルタ制御部２０４が、このログに基づいて、受信したパケットデータが該当の応答データであるか判断し、該当の応答データであれば受信フィルタ対象とみなさずに受信処理を行うように制御する機能である。
【００６４】
このステートフルインスペクション機能を有効にすることで、ＴＣＰで登録されている宛先に対してもスリープ通知を行うことが可能となる。即ち、実施例２によれば、ＴＣＰのように、送達確認等を行うプロトコルを使用して通信する宛先に対しても、スリープ通知を行うことが可能となる。
【実施例３】
【００６５】
実施例３として、本発明を適用した画像形成装置が、シャットダウンする場合について説明する。
画像形成装置１をシャットダウンする場合も、スリープ状態に移行する場合と同様の課題が存在する。
シャットダウン処理中は、送受信パケットを破棄するフィルタ制御を有効にするため、フィルタ有効前にシャットダウン通知を送信する必要がある。
この場合も、通知宛先が多く存在し、通知処理中に外部ホストから印刷ジョブ等を受信してしまった場合、画像形成装置のシャットダウンは延期されるため、管理不整合が発生してしまう。
【００６６】
本実施例においても、シャットダウンする場合、まずは受信フィルタ制御処理機能のみを有効にして、該受信フィルタ制御処理機能が有効になった後にシャットダウン通知を送信し、該シャットダウン通知の送信が完了したら送信フィルタ制御処理機能を有効にし、該送信フィルタ制御処理機能が有効になったらシャットダウン処理を開始する制御を画像形成装置ソフトウェア２に搭載することで解決できる。
【００６７】
以上示したように、本実施例によれば、画像形成装置等のネットワーク機器からの不正なネットワークパケットの送信を防止し、かつ機器を管理する管理アプリケーションも画像形成装置等の機器の状態を不整合なく正確に管理することができるネットワーク環境を構築することができる。
【００６８】
なお、上記各実施例では、本発明の機器の例として画像形成装置を用いて説明した。しかし、本発明の機器は、画像形成装置に限定されるものではなく、ネットワーク通信可能な機器であってスリープ状態に遷移する機器であればよい。
【００６９】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。
【００７０】
（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００７１】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【００７２】
１ 画像形成装置
２ 画像形成装置ソフトウェア
２０１ プロトコルスタック
２０３ 送信フィルタ制御部
２０４ 受信フィルタ制御部
２０５ スリープ制御部
２０６ スリープ通知制御部
２０７ スリープ通知送信部
２０８ スリープ通知先ＤＢ
【技術分野】
【０００１】
本発明は、画像形成装置における状態遷移時のパケット制御技術に関する。
【背景技術】
【０００２】
近年、画像形成装置等の機器が消費する電力を低減するため、稼動していない状態が一定時間以上経過した場合は、電力の供給を機器の一部に限定し低電力で動作する「スリープ状態」へ遷移する省電力機能が進歩している。
【０００３】
また、ネットワーク技術の普及に伴い、ネットワークを利用して機器とホスト間で定期的にデータのやりとりを行う状況が想定される。機器が「スリープ状態」であっても、このようなネットワーク経由のデータの処理を行うために、機器に複数のＣＰＵを搭載し、非スリープ時にはメインＣＰＵで処理を行うが、スリープ時には、電力消費の小さいサブＣＰＵでメインＣＰＵの処理を代替させる手法が考えられている（特許文献１参照）。
【０００４】
このようなシステムでは、サブＣＰＵは受信したネットワークパケットに対して代理応答するか破棄するか、メインＣＰＵをスリープ状態から復帰させるかを判断し処理する機能を有している。
【０００５】
一方、近年、機器の多機能化に伴い、機器を制御するメインＣＰＵには多くのドライバが搭載されている。その為、スリープ状態に遷移する場合、これらのドライバに対してスリープ状態遷移の為の停止処理を実施する必要がある。また、機器が画像形成装置である場合、定着器等のエンジンを停止するための処理も必要となる。
【０００６】
これらの処理を実施するには数秒間の時間が必要である。つまり、機器がスリープ移行を決定してから、実際にスリープ移行するまで、スリープ準備処理を実行している時間が数秒間発生していた。
【０００７】
このスリープ準備中にメインＣＰＵが外部ホストからネットワークパケットを受信すると、タイミングによってはプロトコルスタック、あるいはアプリケーションで処理中に機器がスリープ状態に遷移してしまう場合がある（図７参照）。
【０００８】
図７のように、スリープ移行（７１０）している間では、画像形成装置７０１は、外部ホスト７０２から処理を要求するリクエストパケット（ＳＮＭＰ Ｒｅｑｕｅｓｔ）７１１を受信しても、プロトコルスタックあるいはアプリケーションで処理中に、スリープ状態に遷移する（７１２）。そして、次にスリープ復帰（７１３）した瞬間にリクエストパケット７１１の処理を進め、応答パケット（７１４）を外部ホスト７０２に送信する。
【０００９】
しかし、次にスリープ復帰した際にパケット処理を進めて応答パケットを送信しても、一定時間が経過しているため応答したパケットの内容が不正になる、あるいは外部ホスト７０２から見れば意図しない時間に応答パケットが来るため攻撃パケットとみなされる可能性もある。
【００１０】
そのため、メインＣＰＵではスリープ準備処理中の送受信パケットをドライバあるいはプロトコルスタックレベルで破棄するという処理が一般的である（図８参照）。
図８のように、スリープ移行（８１０）している間では、画像形成装置８０１は、外部ホスト８０２から処理を要求するリクエストパケット（ＳＮＭＰ Ｒｅｑｕｅｓｔ）８１１を受信しても、パケットを破棄し（８１２）、スリープ状態に遷移する（８１３）。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００６−２５９９０６号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかしながら、従来のスリープ遷移中に送受信パケットを破棄する制御では、機器を管理する管理アプリケーションが正確に機器管理できない問題が発生してしまう（図９参照）。
【００１３】
近年の機器管理アプリケーションは、機器のスリープ状態も把握する機能が一般的である。例えば、機器が何時にスリープ状態に遷移したか、何時にスリープ状態から復帰したかを管理することで機器の消費電力を計算し、ユーザに提示する機能等がある。
【００１４】
そのため、機器はスリープ状態に遷移する直前や、スリープ状態から復帰した直後は管理アプリケーションに対して通知パケットを送信する機能を有している。しかし、前述のように機器においてスリープ状態遷移中は送受信パケットを破棄するため、実際にスリープ状態移行通知パケットを送信するのは状態遷移前となる。
【００１５】
例えば、機器が２種類のスリープ状態通知機能を有しているとする。１つはマルチキャストでスリープ状態通知を行うプロトコルであり、もう１つは予め登録されたホストに対してユニキャストのＴＣＰあるいはＵＤＰでスリープ状態通知を行うプロトコルとする。
【００１６】
スリープ状態への遷移が仮決定したら、図９のように、機器（９０１）は、まずマルチキャストパケットで管理アプリケーションに対してスリープ通知を行う（９１０）。管理アプリケーションは、スリープ通知パケットを受信したら、機器の状態を「通常状態」から「スリープ状態」に変更する。
【００１７】
次に、機器（９０１）は、予め登録されているホストに対してユニキャストで１台１台にスリープ通知を行っていく（９１１，９１２）。もしこの間に、ある外部ホストから機器に対してネットワークアクセス（９１３）が発生すると、機器（９０１）はスリープ状態への移行を延期してしまう（９１４）。例えば、あるホストから印刷処理が実行された場合、機器は、印刷が完了し機器のハードディスク保護時間が経過するまではスリープ状態へ遷移しない（９１５）。
【００１８】
このような場合、機器の管理アプリケーションではスリープ通知（９１０）を受信したのに、実際に機器はスリープ状態に遷移していない、という管理不整合（９１６）が発生してしまう問題があった。
【００１９】
本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、スリープ状態から復帰した機器から不正なネットワークパケットを送信せず、且つ、機器を管理する管理アプリケーションも機器の状態を不整合なく正確に管理することができる仕組みを提供することである。
【課題を解決するための手段】
【００２０】
本発明は、画像形成装置であって、ネットワークを介して外部装置とデータの送受信を行う送受信手段とを有する画像形成装置であって、前記画像形成装置をスリープ状態に移行させるスリープ手段と、前記スリープ状態に移行する旨を通知する宛先を記憶する記憶手段と、前記スリープ状態に移行する場合に、前記画像形成装置が受信するデータを前記送受信手段で破棄する受信フィルタ制御処理を有効にする受信データ破棄設定手段と、前記受信フィルタ制御処理を有効にした後に、前記送受信手段を介して、前記画像形成装置がスリープ状態に移行する旨を示すスリープ通知を前記記憶手段に登録されている宛先へ送信する通知手段と、前記スリープ通知の完了の後に、前記画像形成装置から送信するデータを前記送受信手段で破棄する送信フィルタ制御処理を有効にする送信データ破棄設定手段とを有し、前記スリープ手段は、前記送信フィルタ制御処理を有効にした後に、前記画像形成装置をスリープ状態に移行させることを特徴とする。
【発明の効果】
【００２１】
本発明によれば、スリープ状態から復帰した画像形成装置から不正なネットワークパケットを送信せず、且つ、画像形成装置を管理する管理アプリケーションも画像形成装置の状態を不整合なく正確に管理することができる。
【図面の簡単な説明】
【００２２】
【図１】本発明の一実施例を示す画像形成装置のハードウェア構成の一例を示すブロック図である。
【図２】図１に示した画像形成装置１のソフトウェア構成の一例を示すブロック図である。
【図３】図２に示した画像形成装置ソフトウェア２の動作の一例を示すフローチャートである。
【図４】実施例１のスリープ通知先ＤＢ２０８の一例を示す図である。
【図５】実施例１におけるネットワークシーケンスの一例を示す図である
【図６】実施例２のスリープ通知先ＤＢ２０８の一例を示す図である。
【図７】従来のネットワークシーケンスの一例を示す図である
【図８】従来のネットワークシーケンスの一例を示す図である
【図９】従来のネットワークシーケンスの一例を示す図である
【発明を実施するための形態】
【００２３】
以下、本発明を実施するための最良の形態について図面を用いて説明する。ここでは、本発明の機器として、画像形成装置を例に説明する。
【実施例１】
【００２４】
実施例１として、本発明を適用した画像形成装置がＵＤＰを用いてスリープ通知を送信する場合について説明する。
図１は、本発明の一実施例を示す画像形成装置のハードウェア構成の一例を示すブロック図である。
図１に示すように、本実施例の画像形成装置１は、コントローラ１００、スキャナ１１１、プリンタエンジン１１２、オペレーションパネル１１３を有する。
ＲＯＭ１０３のプログラム用ＲＯＭには、ＣＰＵ１０９が実行可能な制御プログラム等が記録されている。ＲＯＭ１０３のデータ用ＲＯＭには、画像形成装置１で利用される情報等が記録されている。
【００２５】
ＣＰＵ１０９は、ＲＯＭ１０３のプログラム用ＲＯＭにコンピュータ読み取り可能に記録された制御プログラムに基づいて、システムバス１１０に接続される各種のデバイスとのアクセスを総括的に制御する。
【００２６】
また、ＣＰＵ１０９は、プリンタＩ／Ｆ１０６を介して接続されるプリンタエンジン１１２に出力情報としての画像信号を出力したり、スキャナＩ／Ｆ１０１を介して接続されるスキャナ１１１から入力される画像信号を制御する。
【００２７】
ＲＡＭ１０４は、主としてＣＰＵ１０９の主メモリ，ワークエリア等として機能する。なお、ＲＡＭ１０４は、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。
【００２８】
ハードディスク（ＨＤＤ）１０５は、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶、プリントジョブを一時的にスプールし、スプールされたジョブを外部から制御するためのジョブ格納領域として使用される。また、ＨＤＤ１０５は、スキャナ１１１から読み取った画像データやプリントジョブの画像データをＢＯＸデータとして保持し、ネットワークから参照、印刷を行うＢＯＸデータ格納領域としても使用される。
【００２９】
不揮発性メモリ（ＮＶＲＡＭ）１０７は、オペレーションパネル１１３で設定される各種設定情報をパネル制御部１０８経由で記憶している。ネットワークインタフェース（ＮＷ Ｉ／Ｆ）１０２は、ネットワークケーブルを経由して外部ネットワーク１２０とデータ通信を行う。
【００３０】
図２は、図１に示した画像形成装置１のソフトウェア構成の一例を示すブロック図である。
図２に示す画像形成装置ソフトウェア２は、画像形成装置１のＣＰＵ１０９がＲＯＭ１０３にコンピュータ読み取り可能に記録されたプログラムを読み出して実行することにより実現される機能である。
【００３１】
図２に示すように、画像形成装置ソフトウェア２の構成は、大きく分けて、カーネル空間で動作するカーネル部分と、ユーザ空間で動作するアプリケーション部分（アプリケーション２０２）とに分けられる。このカーネル部分にネットワーク送受信を制御するネットワークプロトコルスタック（プロトコルスタック２０１）が搭載されている。
【００３２】
まず、アプリケーション２０２について説明する。
アプリケーション２０２は、スリープ制御部２０５、スリープ通知制御部２０６、スリープ通知送信部２０７、スリープ通知先ＤＢ２０８を有する。
スリープ制御部２０５は、画像形成装置の全ユニットに電力が供給されている「通常状態」から、１部のユニットへのみ電力が供給される「スリープ状態」に移行するかどうかの制御を行う。スリープ状態に移行すると決定した場合、スリープ制御部２０５は、スリープ通知制御部２０６へスリープ移行決定の情報を通知する。
【００３３】
スリープ通知制御部２０６は、スリープ移行決定の情報の通知を受けると、スリープ通知送信部２０７を介して外部ホスト宛にスリープ通知パケットを送信する。スリープ通知パケットのフォーマットは、Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＬＰ）などの汎用プロトコルを使用してもよいし、独自プロトコルを定義してもよい。この時、スリープ通知を送信する宛先は、スリープ通知先ＤＢ２０８に格納されている宛先ＩＰアドレスに基づいて決定される。
【００３４】
同様に、スリープ制御部２０５は、「スリープ状態」から「通常状態」に復帰した場合、スリープ通知制御部２０６へスリープ復帰の情報を通知する。
スリープ通知制御部２０６は、スリープ復帰の情報の通知を受けると、スリープ通知送信部２０７を介して外部ホスト宛にスリープ復帰通知パケットを送信する。
【００３５】
次に、プロトコルスタック２０１について説明する。
プロトコルスタック２０１は、ＩＰヘッダやＴＣＰヘッダを解釈し、アプリケーション２０２と外部ホストとのデータ通信のパケット制御を行う。プロトコルスタック２０１は、受信フィルタ制御部２０４、送信フィルタ制御部２０３を有する。
【００３６】
受信フィルタ制御部２０４は、特定の宛先からのアクセスや特定のポート番号へのアクセスに対して、受信パケットの破棄、許可を処理できる機能（受信フィルタ制御処理機能）を有する。同様に、送信フィルタ制御部２０３は、特定の宛先へのアクセスやポート番号への送信に対して、送信パケットの破棄、許可を処理できる機能（送信フィルタ制御処理機能）を有する。
【００３７】
本実施例では、物理層であるドライバレベルでフィルタ制御する例を説明するが、本制御は、物理層、ＩＰ層、ＴＣＰ／ＵＤＰ層、アプリケーション層いずれのレイヤーで実施されてもよい。
【００３８】
以下、図３を用いて、画像形成装置ソフトウェア２の動作について説明する。
図３は、図２に示した画像形成装置ソフトウェア２の動作の一例を示すフローチャートである。即ち、本フローチャートの動作は、画像形成装置１のＣＰＵ１０９がＲＯＭ１０３にコンピュータ読み取り可能に記録されたプログラムを読み出して実行することにより実現されるものである。
【００３９】
Ｓ３０１において、スリープ制御部２０５は、画像形成装置１がスリープ状態に移行できるかどうかを判断する。スリープ状態移行の判断基準としては、例えば、最後にハードディスク１０５にアクセスしてから、ハードディスク保護時間が経過しているか否か等で判断を行うものとする。
【００４０】
前記Ｓ３０１において、スリープ移行可能でないと判断した場合（Ｎｏ）、スリープ制御部２０５は、Ｓ３０１に処理を戻す。
一方、前記Ｓ３０１において、スリープ移行可能と判断した場合（Ｙｅｓ）、スリープ制御部２０５は、スリープ通知制御部２０６にスリープ移行可能の旨を通知する。
【００４１】
スリープ移行可能の旨の通知を受けると、スリープ通知制御部２０６は、Ｓ３０２において、プロトコルスタック２０１の受信フィルタ制御部２０４を起動させ、受信パケットを全て破棄する処理（受信フィルタ制御処理）の設定（受信データ破棄設定）を有効にする。
【００４２】
次に、Ｓ３０３において、スリープ通知制御部２０６は、スリープ通知先ＤＢ２０８を参照し、スリープ通知を送信すべき宛先が存在するか否かを判断する。スリープ通知先ＤＢ２０８は、例えば図４のようなリストとなっている。
【００４３】
図４は、実施例１のスリープ通知先ＤＢ２０８の一例を示す図である。
図４に示すように、スリープ通知先ＤＢ２０８が管理する通知先データ（宛先）は、宛先ＩＰアドレス、プロトコル種別（例えば、ＳＬＰ）、トランスポート種別（例えば、ＵＤＰ）、パターン（例えば、マルチキャスト、ユニキャスト）を含むものとする。
【００４４】
例えば、図４のＮｏ１には、ＳＬＰマルチキャストでスリープ通知送信を行うための宛先が格納されている。また、Ｎｏ２には、１９２．１６８．１．１に対してＵＤＰを使用してＳＬＰユニキャストでスリープ通知送信を行うための宛先が格納されている。また、Ｎｏ３には、１９２．１６８．１．２に対してＵＤＰを使用してＳＬＰユニキャストでスリープ通知送信を行うための宛先が格納されている。また、Ｎｏ４には、１９２．１６８．１．３に対してＵＤＰを使用してＳＬＰユニキャストでスリープ通知送信を行うための宛先が格納されている。なお、スリープ通知先ＤＢ２０８が管理する通知先データは、ポート番号やアドレスファミリー（ＡＦ_ＩＮＥＴ、ＡＦ_ＩＮＥＴ６等）等の属性を含んでいてもよい。
なお、スリープ通知先ＤＢ２０８は、工場出荷時等に予めＲＯＭ１０３等に格納されている静的な宛先と、ユーザにより登録される動的な宛先を記憶管理している。
【００４５】
以下、図３の説明にもどる。
前記Ｓ３０３において、送信すべき宛先が存在すると判断した場合（Ｙｅｓ）、スリープ通知送信部２０７は、Ｓ３０４に処理を進める。
Ｓ３０４では、スリープ通知送信部２０７は、前記スリープ通知先ＤＢ２０８に存在する宛先を読み出して、該宛先にスリープ通知を送信する。
【００４６】
送信が完了したら、Ｓ３０５において、スリープ通知送信部２０７は、次の宛先が存在するかスリープ通知先ＤＢ２０８を参照する。
なお、上記Ｓ３０２で受信パケット破棄設定を有効にされた受信フィルタ制御部２０４は、前記Ｓ３０３〜Ｓ３０５の手順の間に、外部ホストからネットワークパケットを受信したと判断した場合（Ｓ３０６でＹｅｓ）、受信フィルタ制御部２０４が受信パケットを破棄する（Ｓ３０７）。この処理によって、機器はネットワーク受信によってスリープ移行が延期されることを防止できる。
【００４７】
次に、スリープ通知送信部２０７は、Ｓ３０３に処理を戻し、前記Ｓ３０５での次の宛先の参照結果に基づいて、次にスリープ通知を送信すべき宛先が存在するか否かを判断する。そして、送信すべき宛先が存在する間（Ｓ３０３でＹｅｓの間）、スリープ通知送信部２０７は、Ｓ３０４〜Ｓ３０５の処理を繰り返す。
【００４８】
図４に示した例の場合、まずＳＬＰマルチキャストでスリープ通知を送信する。次に、１９２．１６８．１．１に対してＵＤＰを使用してＳＬＰユニキャストでスリープ通知を送信する。次に、１９２．１６８．１．２に対してスリープ通知を送信する。さらに、１９２．１６８．１．３に対してスリープ通知を送信する。これにより、スリープ通知を受信した管理アプリケーション側は、画像形成装置１の状態をスリープ状態として管理を始める。
【００４９】
そして、前記Ｓ３０３において、次にスリープ通知を送信すべき宛先が存在しないと判断した場合（Ｎｏ）、スリープ通知送信部２０７は、Ｓ３０８に処理を進める。
Ｓ３０８において、スリープ通知制御部２０６は、プロトコルスタック２０１の送信フィルタ制御部２０３を起動させ、送信パケットを全て破棄する処理（送信フィルタ制御処理）の設定（送信データ破棄設定）を有効にする。さらに、スリープ通知制御部２０６は、スリープ制御部２０５に対して、スリープ通知およびフィルタ制御が完了した旨の通知を行う。
【００５０】
スリープ制御部２０５は、スリープ通知制御部２０６からスリープ通知およびフィルタ制御が完了した旨の通知を受けると、Ｓ３０９において、スリープ移行処理を開始し、移行処理が完了次第、スリープ状態に移行する（Ｓ３１０）。
【００５１】
スリープ制御部２０５は、スリープ状態から復帰した場合（Ｓ３１１でＹｅｓ）、スリープ通知制御部２０６に対して、スリープ状態から復帰した旨の通知を行う。
スリープ状態から復帰した旨の通知を受けると、スリープ通知制御部２０６は、Ｓ３１２において、前記Ｓ３０２で有効にしていた受信フィルタ制御部２０４の受信パケット破棄の設定、及び前記Ｓ３０８で有効にしていた送信フィルタ制御部２０３の送信パケット破棄の設定をそれぞれ無効にする。
【００５２】
次に、Ｓ３１３において、スリープ通知制御部２０６は、スリープ通知送信部２０７を介して、スリープ通知先ＤＢ２０８に格納されている全ての宛先に対して、スリープ復帰通知を送信する。図４に示した例の場合、まずＳＬＰマルチキャストでスリープ復帰通知を送信する。次に、１９２．１６８．１．１に対してＵＤＰを使用してＳＬＰユニキャストでスリープ復帰通知を送信する。次に、１９２．１６８．１．２に対してスリープ復帰通知を送信する。さらに、１９２．１６８．１．３に対してスリープ復帰通知を送信する。これにより、スリープ復帰通知を受信した管理アプリケーション側は、画像形成装置１の状態を通常状態として管理を始める。
【００５３】
以下、図５を用いて、具体的例を示す。
図５は、実施例１におけるネットワークシーケンスの一例を示す図である
図３に示した処理を実行することで、図５のように、スリープ通知（５１１〜５１３）を送信している間では、画像形成装置１は、外部ホスト５０１から印刷処理を要求するＬＰＤリクエストパケット（ＬＰＤ Ｐｒｉｎｔ Ｒｅｑｕｅｓｔ）５１４を受信しても、受信パケット破棄設定が有効（５１０）になっているので、印刷を受け付けることなく受信パケットを破棄する（５１５）。
【００５４】
そのため画像形成装置１は、スリープ通知を送信した場合は、必ずスリープ状態に移行することができるため（５１６）、管理アプリケーションへの通知と実際の画像形成装置１の状態との間の不整合を解消できる。
【００５５】
また、管理アプリケーション側でもスリープ通知を受信したのに、画像形成装置１がスリープ状態に移行していない、という不整合が発生することもない。
図５に示した例では、外部ホストから印刷要求リクエストを受信した場合であったが、特にプロトコルを限定することはなく本発明を適用できる。
【００５６】
なお、プロトコル処理によってスリープ移行をどれだけの時間延期させるかは、機器構成によって異なるものとする。例えば、ＨＤＤにアクセスするようなプロトコル受信の場合は、少なくともハードディスク保護時間分はスリープ移行時間を延期しなければならない。また、ＳＮＭＰやＳＬＰ等の機器の情報取得系のプロトコルであれば連続してアクセスしてくる可能性があるため、一般的には数十秒間はスリープ移行しないように時間を延期する。
【００５７】
なお、機器は画像形成装置に限定されるものではなくスリープ状態に遷移するネットワーク機器であれば、本発明を適用可能である。
以上示したように、本実施例によれば、スリープ状態に遷移する機器において不正なネットワークパケットの送信を防止し、かつ機器を管理する管理アプリケーションも機器の状態を不整合なく正確に管理することができるネットワーク環境を構築することができる。
【００５８】
なお、スリープ通知制御部２０６は、画像形成装置１がスリープ状態に遷移する直前に、前記Ｓ３０２で有効にしていた受信フィルタ制御部２０４の受信パケット破棄の設定、及び前記Ｓ３０８で有効にしていた送信フィルタ制御部２０３の送信パケット破棄の設定をそれぞれ無効にするように構成してもよい。この構成の場合、スリープ通知制御部２０６は、スリープ復帰した場合に、Ｓ３１２の送受信パケット破棄設定の無効処理を行うことなく、Ｓ３１３のスリープ復帰通知の送信を行うものとする。
【実施例２】
【００５９】
実施例２では、本発明を適用した画像形成装置１がＴＣＰを用いてスリープ通知を送信する場合について説明する。
図６は、実施例２のスリープ通知先ＤＢ２０８の一例を示す図である。
図６に示す例の場合、画像形成装置１は、まずＳＬＰマルチキャストでスリープ通知を送信する。次に、１９２．１６８．１．１に対してＴＣＰを使用してＳＬＰユニキャストでスリープ通知を送信する。次に、１９２．１６８．１．２に対してＵＤＰを使用してＳＬＰユニキャストでスリープ通知を送信する。さらに、１９２．１６８．１．３に対してＴＣＰを使用してＳＬＰユニキャストでスリープ通知を送信する。
【００６０】
即ち、スリープ通知先ＤＢ２０８に図６のように宛先が登録されている場合、画像形成装置１は、１９２．１６８．１．１や１９２．１６８．１．３に対して、スリープ通知をＴＣＰで送信する必要がある。管理アプリケーションによっては、確実に通知を受信したいため、ＴＣＰでスリープ通知を送信してほしい場合がある。
【００６１】
このような場合、画像形成装置１が図３のＳ３０４において、１９２．１６８．１．１に対してＴＣＰでスリープ通知を送信すると、まずはＴＣＰ ＳＹＮパケットが送信される。ＳＹＮに対して、１９２．１６８．１．１がＳＹＮ ＡＣＫの応答を画像形成装置１に対して送信すると、実施例１の構成では、受信フィルタ制御部２０４で破棄設定が有効になっているので、受信フィルタ制御部２０４がＳＹＮ ＡＣＫパケットを破棄してしまう。そのため、ＴＣＰセッションが確立せずに、ＴＣＰでスリープ通知を登録していた１９２．１６８．１．１や１９２．１６８．１．３の宛先に対しては、スリープ通知することができない。
【００６２】
この問題を解決するために、実施例２では、ＴＣＰでスリープ通知を登録している宛先が存在する場合、プロトコルスタック２０１において、ステートフルインスペクション機能を有効にして、受信フィルタ制御処理を実行する。例えば、図３のＳ３０２において受信パケット破棄設定を有効にする場合に、スリープ通知制御部２０６が、ＴＣＰでスリープ通知を登録している宛先が存在するか判定し、存在する場合、受信フィルタ制御部２０４のステートフルインスペクション機能も有効に設定する。
【００６３】
ステートフルインスペクション機能とは、例えば画像形成装置１がクライアントとなってリクエストパケットデータを送信する場合、該送信したパケットデータをログとして保管しておき、受信フィルタ制御部２０４が、このログに基づいて、受信したパケットデータが該当の応答データであるか判断し、該当の応答データであれば受信フィルタ対象とみなさずに受信処理を行うように制御する機能である。
【００６４】
このステートフルインスペクション機能を有効にすることで、ＴＣＰで登録されている宛先に対してもスリープ通知を行うことが可能となる。即ち、実施例２によれば、ＴＣＰのように、送達確認等を行うプロトコルを使用して通信する宛先に対しても、スリープ通知を行うことが可能となる。
【実施例３】
【００６５】
実施例３として、本発明を適用した画像形成装置が、シャットダウンする場合について説明する。
画像形成装置１をシャットダウンする場合も、スリープ状態に移行する場合と同様の課題が存在する。
シャットダウン処理中は、送受信パケットを破棄するフィルタ制御を有効にするため、フィルタ有効前にシャットダウン通知を送信する必要がある。
この場合も、通知宛先が多く存在し、通知処理中に外部ホストから印刷ジョブ等を受信してしまった場合、画像形成装置のシャットダウンは延期されるため、管理不整合が発生してしまう。
【００６６】
本実施例においても、シャットダウンする場合、まずは受信フィルタ制御処理機能のみを有効にして、該受信フィルタ制御処理機能が有効になった後にシャットダウン通知を送信し、該シャットダウン通知の送信が完了したら送信フィルタ制御処理機能を有効にし、該送信フィルタ制御処理機能が有効になったらシャットダウン処理を開始する制御を画像形成装置ソフトウェア２に搭載することで解決できる。
【００６７】
以上示したように、本実施例によれば、画像形成装置等のネットワーク機器からの不正なネットワークパケットの送信を防止し、かつ機器を管理する管理アプリケーションも画像形成装置等の機器の状態を不整合なく正確に管理することができるネットワーク環境を構築することができる。
【００６８】
なお、上記各実施例では、本発明の機器の例として画像形成装置を用いて説明した。しかし、本発明の機器は、画像形成装置に限定されるものではなく、ネットワーク通信可能な機器であってスリープ状態に遷移する機器であればよい。
【００６９】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。
【００７０】
（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００７１】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【００７２】
１ 画像形成装置
２ 画像形成装置ソフトウェア
２０１ プロトコルスタック
２０３ 送信フィルタ制御部
２０４ 受信フィルタ制御部
２０５ スリープ制御部
２０６ スリープ通知制御部
２０７ スリープ通知送信部
２０８ スリープ通知先ＤＢ
【特許請求の範囲】
【請求項１】
ネットワークを介して外部装置とデータの送受信を行う送受信手段とを有する画像形成装置であって、
前記画像形成装置をスリープ状態に移行させるスリープ手段と、
前記スリープ状態に移行する旨を通知する宛先を記憶する記憶手段と、
前記スリープ状態に移行する場合に、前記画像形成装置が受信するデータを前記送受信手段で破棄する受信フィルタ制御処理を有効にする受信データ破棄設定手段と、
前記受信フィルタ制御処理を有効にした後に、前記送受信手段を介して、前記画像形成装置がスリープ状態に移行する旨を示すスリープ通知を前記記憶手段に登録されている宛先へ送信する通知手段と、
前記スリープ通知の完了の後に、前記画像形成装置から送信するデータを前記送受信手段で破棄する送信フィルタ制御処理を有効にする送信データ破棄設定手段とを有し、
前記スリープ手段は、前記送信フィルタ制御処理を有効にした後に、前記画像形成装置をスリープ状態に移行させることを特徴とする画像形成装置。
【請求項２】
前記記憶手段に記憶される宛先は、ＩＰアドレス、プロトコル種別、トランスポート種別の属性を有するデータであることを特徴とする請求項１に記載の画像形成装置。
【請求項３】
前記受信データ破棄設定手段は、前記宛先のトランスポート種別がＴＣＰである場合、前記受信フィルタ制御処理を有効にする場合に、前記画像形成装置が受信したデータが前記画像形成装置より送信したデータの応答データである場合には、前記受信フィルタ制御処理において当該受信したデータを破棄しない機能をも有効にすることを特徴とする請求項２に記載の画像形成装置。
【請求項４】
前記記憶手段は、予め登録されている静的な宛先と、ユーザにより登録される動的な宛先を記憶することを特徴とする請求項１乃至３のいずれか１項に記載の画像形成装置。
【請求項５】
前記画像形成装置がスリープ状態から復帰した場合に、前記送信フィルタ制御処理、及び前記受信フィルタ制御処理を無効にする設定手段を有することを特徴とする請求項１乃至４のいずれか１項に記載の画像形成装置。
【請求項６】
前記画像形成装置がスリープ状態に遷移する直前に、前記送信フィルタ制御処理、及び前記受信フィルタ制御処理を無効にする設定手段を有することを特徴とする請求項１乃至４のいずれか１項に記載の画像形成装置。
【請求項７】
前記通知手段は、前記スリープ状態から復帰した場合に、前記送受信手段を介して、前記画像形成装置がスリープ状態から復帰した旨を示すスリープ復帰通知を前記記憶手段に登録されている宛先へ送信することを特徴とする請求項１乃至６のいずれか１項に記載の画像形成装置。
【請求項８】
前記受信データ破棄設定手段は、前記画像形成装置をシャットダウンする場合に、前記受信フィルタ制御処理を有効にし、
前記通知手段は、前記シャットダウンのために前記受信フィルタ制御処理を有効にした後に、前記送受信手段を介して、前記画像形成装置をシャットダウンする旨を示すシャットダウン通知を前記記憶手段に登録されている宛先へ送信し、
前記シャットダウン通知の完了の後に、前記送信フィルタ制御処理を有効にし、
前記シャットダウンのために前記送信フィルタ制御処理を有効にした後に、前記画像形成装置をシャットダウンするシャットダウン手段を有することを特徴とする請求項１乃至７のいずれか１項に記載の画像形成装置。
【請求項９】
ネットワークを介して外部装置とデータの送受信を行う送受信手段とを有する画像形成装置の制御方法であって、
前記画像形成装置をスリープ状態に移行する場合に、前記画像形成装置が受信するデータを前記送受信手段で破棄する受信フィルタ制御処理を有効にする受信データ破棄設定ステップと、
前記受信フィルタ制御処理を有効にした後に、前記送受信手段を介して、前記画像形成装置がスリープ状態に移行する旨を示すスリープ通知を記憶手段に登録されている宛先へ送信する通知ステップと、
前記スリープ通知の完了の後に、前記画像形成装置から送信するデータを前記送受信手段で破棄する送信フィルタ制御処理を有効にする送信データ破棄設定ステップと、
前記送信フィルタ制御処理を有効にした後に、前記画像形成装置をスリープ状態に移行させるスリープ移行ステップと、
を有することを特徴とする画像形成装置の制御方法。
【請求項１０】
コンピュータを、請求項１乃至８のいずれか１項に記載の手段として機能させるためのプログラム。
【請求項１】
ネットワークを介して外部装置とデータの送受信を行う送受信手段とを有する画像形成装置であって、
前記画像形成装置をスリープ状態に移行させるスリープ手段と、
前記スリープ状態に移行する旨を通知する宛先を記憶する記憶手段と、
前記スリープ状態に移行する場合に、前記画像形成装置が受信するデータを前記送受信手段で破棄する受信フィルタ制御処理を有効にする受信データ破棄設定手段と、
前記受信フィルタ制御処理を有効にした後に、前記送受信手段を介して、前記画像形成装置がスリープ状態に移行する旨を示すスリープ通知を前記記憶手段に登録されている宛先へ送信する通知手段と、
前記スリープ通知の完了の後に、前記画像形成装置から送信するデータを前記送受信手段で破棄する送信フィルタ制御処理を有効にする送信データ破棄設定手段とを有し、
前記スリープ手段は、前記送信フィルタ制御処理を有効にした後に、前記画像形成装置をスリープ状態に移行させることを特徴とする画像形成装置。
【請求項２】
前記記憶手段に記憶される宛先は、ＩＰアドレス、プロトコル種別、トランスポート種別の属性を有するデータであることを特徴とする請求項１に記載の画像形成装置。
【請求項３】
前記受信データ破棄設定手段は、前記宛先のトランスポート種別がＴＣＰである場合、前記受信フィルタ制御処理を有効にする場合に、前記画像形成装置が受信したデータが前記画像形成装置より送信したデータの応答データである場合には、前記受信フィルタ制御処理において当該受信したデータを破棄しない機能をも有効にすることを特徴とする請求項２に記載の画像形成装置。
【請求項４】
前記記憶手段は、予め登録されている静的な宛先と、ユーザにより登録される動的な宛先を記憶することを特徴とする請求項１乃至３のいずれか１項に記載の画像形成装置。
【請求項５】
前記画像形成装置がスリープ状態から復帰した場合に、前記送信フィルタ制御処理、及び前記受信フィルタ制御処理を無効にする設定手段を有することを特徴とする請求項１乃至４のいずれか１項に記載の画像形成装置。
【請求項６】
前記画像形成装置がスリープ状態に遷移する直前に、前記送信フィルタ制御処理、及び前記受信フィルタ制御処理を無効にする設定手段を有することを特徴とする請求項１乃至４のいずれか１項に記載の画像形成装置。
【請求項７】
前記通知手段は、前記スリープ状態から復帰した場合に、前記送受信手段を介して、前記画像形成装置がスリープ状態から復帰した旨を示すスリープ復帰通知を前記記憶手段に登録されている宛先へ送信することを特徴とする請求項１乃至６のいずれか１項に記載の画像形成装置。
【請求項８】
前記受信データ破棄設定手段は、前記画像形成装置をシャットダウンする場合に、前記受信フィルタ制御処理を有効にし、
前記通知手段は、前記シャットダウンのために前記受信フィルタ制御処理を有効にした後に、前記送受信手段を介して、前記画像形成装置をシャットダウンする旨を示すシャットダウン通知を前記記憶手段に登録されている宛先へ送信し、
前記シャットダウン通知の完了の後に、前記送信フィルタ制御処理を有効にし、
前記シャットダウンのために前記送信フィルタ制御処理を有効にした後に、前記画像形成装置をシャットダウンするシャットダウン手段を有することを特徴とする請求項１乃至７のいずれか１項に記載の画像形成装置。
【請求項９】
ネットワークを介して外部装置とデータの送受信を行う送受信手段とを有する画像形成装置の制御方法であって、
前記画像形成装置をスリープ状態に移行する場合に、前記画像形成装置が受信するデータを前記送受信手段で破棄する受信フィルタ制御処理を有効にする受信データ破棄設定ステップと、
前記受信フィルタ制御処理を有効にした後に、前記送受信手段を介して、前記画像形成装置がスリープ状態に移行する旨を示すスリープ通知を記憶手段に登録されている宛先へ送信する通知ステップと、
前記スリープ通知の完了の後に、前記画像形成装置から送信するデータを前記送受信手段で破棄する送信フィルタ制御処理を有効にする送信データ破棄設定ステップと、
前記送信フィルタ制御処理を有効にした後に、前記画像形成装置をスリープ状態に移行させるスリープ移行ステップと、
を有することを特徴とする画像形成装置の制御方法。
【請求項１０】
コンピュータを、請求項１乃至８のいずれか１項に記載の手段として機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１３−１０３４４７（Ｐ２０１３−１０３４４７Ａ）
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願番号】特願２０１１−２４９８９７（Ｐ２０１１−２４９８９７）
【出願日】平成２３年１１月１５日（２０１１．１１．１５）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願日】平成２３年１１月１５日（２０１１．１１．１５）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]