JP2009119849A - 情報処理装置、情報処理方法及びプログラム - Google Patents

Abstract

【課題】 主制御部への電源供給を停止する低消費電力モード時にトランザクションＩＤの変更が必要なプロトコルによる定期送信を行えるようにする。
【解決手段】 ＰＥ２４は、ＣＰＵが動作しない省エネルギーモードでも、ネットワーク送信制御部２４１の制御によって定期送信間隔時間設定部２４９のＴｉｍｅｒ(1)に設定した時間間隔でＩＰパケット生成部２４７が自発的にＤＨＣＰ ＲＥＱＵＥＳＴを生成し、定期送信を行う。また、ＤＨＣＰ ＲＥＱＵＥＳＴパケットの定期送信は、リクエストに応答するＤＨＣＰ ＡＣＫの受信がある間、継続して行われ、通信条件を保つが、ＤＨＣＰ ＲＥＱＵＥＳＴパケットに対してＴｉｍｅｒ(2)に設定した時間内に何の応答もない場合には、定期送信は中断され、再送制御部２４１１で当該パケットを再送する。
【選択図】 図１３

Description

本発明は、ネットワークと処理対象情報及び機器情報等の情報交換ができる画像形成装置、スキャナ、プリンタ、複合機等を含む情報処理装置に関し、主制御部への電源供給を停止する低消費電力モード時にネットワークに定期的にリクエストパケットの送信を可能にした情報処理装置及び情報処理方法に関する。

従来、ネットワークにサービスを提供し、或いはネットワークからサービスの提供を受ける画像形成装置、スキャナ、プリンタ、複合機等の情報処理装置において、低消費電力モード（「省エネルギーモード」或いは「スリープモード」ともいわれる）時にもネットワークとの交信を可能にする機能が提案されている。
例えば、ネットワークに接続された画像形成装置において、低消費電力モード時に、複数種類のパケットデータをそれぞれ予め設定した送信条件に従って、定期的にネットワークに自動送信する手段を備えることが提案されている（例えば、下記特許文献１、参照）。
また、受取ったステータス要求に応答する場合に、ネットワークインターフェースでハードウェア応答を可能とする機能を持つ回路（例えば、下記特許文献２、参照）や受信パケットに特定のデータがある場合にデータを送信する機能（例えば、下記特許文献３、参照）が提案されている。このような回路や機能は、省エネルギーモードを保ったままで、ネットワークに機器のステータス等の機器情報を知らせることを可能にする。
特開２００６−２７０８９８号公報 特開２００３−３０３０８０号公報 特許第３７７３６８８号公報

しかしながら、低消費電力モード時に定期的にネットワークに複数種類のパケットデータを自動送信できるようにした従来の提案では、ＤＨＣＰ（Dynamic Host Configuration Protocol）プロトコルのように、トランザクション（Transaction）ＩＤの変更が必要な場合への対応ができない。というのは、ＤＨＣＰのプロトコルでは、トランザクションＩＤの変更ができないと、最初にＤＨＣＰに従いＩＰ（Internet Protocol）アドレスを割り当てることができても、次回のＩＰアドレスの使用延長要求時に、前回と同じトランザクションＩＤを使用した場合、ＤＨＣＰサーバ側で前回のトランザクションＩＤは無視されてしまうので、ＩＰアドレスの延長処理ができなくなり、ＩＰアドレスを使用できなくなるという問題が生じるからである。
この問題を回避するための従来の方法は、低消費電力モードから通常モードに移行して主制御部に電源を供給し、トランザクションＩＤを変更できるようにして、正常なデータ送信を行えるようにしていたが、この方法は、主制御部のＣＰＵ及びメモリの消費電力が大きいので、消費電力の低減効果を減殺してしまう。

また、ネットワーク接続されたこの種の情報処理装置では、低消費電力を維持したままで、ネットワークにステータスを知らせる例（上記特許文献１、参照）では、自動送信であり、ネットワークからの要求に応答していないので、低消費電力にとってはマイナス要因になる。また、ネットワークからの要求に応答する例（上記特許文献２、参照）では、ステータス要求に限定されているので、適応性が低い、という問題がある。
この発明は、上記従来技術の問題に鑑みてなされたものであり、主制御部への電源供給を停止する低消費電力モード時に、トランザクションＩＤの変更が必要なプロトコルによる定期送信を行えるようにすることを解決すべき課題とする。
さらに、低消費電力モード時に、ネットワークからの要求に応答する際に、低消費電力を維持したままで、多様なネットワークからの要求に応えることができるようにすることを解決すべき課題とする。

本発明は、ＣＰＵを有する主制御部と、少なくとも前記主制御部のＣＰＵへの電源供給を停止する低消費電力モードの電源供給制御をする電源制御部と、ネットワークとパケットを交信する通信部と、前記通信部を経て送信する所定フレーム構造のパケットを生成するパケット生成部と、前記通信部で受信したパケットから所定フレーム構造を持つ受取るべきパケットを検出するパケットフィルタ部と、前記パケット生成部によって生成されたパケットを所定のタイミングで送信する送信制御部を有する情報処理装置であって、前記電源制御部は、低消費電力モード時に前記通信部、前記パケットフィルタ部及び前記パケット生成部を動作させるための電源供給を行い、前記パケット生成部は、送信データを記憶する送信データ記憶手段と、前記送信データを送信ごとに識別するための識別データを生成する識別データ生成手段と、前記識別データ生成手段で生成した識別データと前記送信データ記憶手段からの送信データを組合せてパケットを生成する手段を備え、前記送信制御部は、低消費電力モード時に前記パケット生成部によって生成された送信データのパケットを予め設定された送信時間間隔で定期的に送信することを特徴とする。
本発明は、主制御部への電源供給を停止する低消費電力モード時に、所定フレーム構造の送信パケットを生成し、生成したパケットをネットワークに送信し、かつネットワークから所定フレーム構造を持つパケットを受信できる情報処理装置における情報処理方法であって、送信ごとに送信データを識別するための識別データを生成する識別データ生成工程と、前記識別データ生成工程で生成した識別データと送信データを組合せてパケットを生成するパケット生成工程と、低消費電力モード時に前記パケット生成工程によって生成された送信データのパケットを予め設定された送信時間間隔で定期的にネットワークに送信する送信制御工程を有したことを特徴とする。

本発明によると、ネットワークにサービスを提供し、或いはネットワークからサービスの提供を受ける画像形成装置、スキャナ、プリンタ、複合機等々の情報処理装置において、主制御部への電源供給を停止する低消費電力モードを維持したままでトランザクションＩＤの変更が必要なプロトコルによる定期送信が行えるようになり、低消費電力モードに適応した動作を実現することができる。
また、低消費電力を維持したままで多様なネットワークからの要求に応えるメッセージを簡単な手順により、高速に送ることができる。

以下、本発明の情報処理装置に係る実施形態を図面に基づいて説明する。以下には、情報処理装置に係る実施形態としてプリンタを例示する。
図１は、この実施形態に係るプリンタの制御を司るコントローラボード１と記録媒体へ印字するプロッタ２からなる機能構成を示すブロック図である。

「コントローラの概要」
コントローラボード１は、ＡＳＩＣ（Application Specific Integrated Circuit：特定用途向け集積回路）１０、ＤＤＲ−ＳＤＲＡＭ（Double Data Rate -Synchronous Dynamic Random Access Memory）を含むメモリ１１、ネットワークとの間で各種のパケットデータ（以下、単に「パケット」ともいう）の送受信をするネットワーク用の物理層部（physical layer、以下「ＰＨＹ」という）１２、ＰＨＹクロック生成部１３、ＡＳＩＣクロック生成部１４、記録媒体としてのMemory Card（登録商標）１５、操作部（Operation Panel、以下「ＯＰ」という）１６、ハードディスク装置（HDD）１７、ボード電力制御部１８、外部電力制御部１９、不揮発性メモリ（ＲＡＭ；Random Access Memory）３６、プログラムとデータが格納されている第１のＲＯＭ（Read Only Memory）(1)３７、ＭＡＣ（Media Access Control）アドレスが格納されている第２のＲＯＭ(2)３８を搭載している。
なお、上記記録媒体としてのMemory Card１５は、これ以外に、例えば、セキュアデジタルカード（Secure Digital Card：ＳＤカード、登録商標）を含む各種のメディアが使用可能である。また、上記ＭＡＣアドレスとは、ユニークなハードウェアアドレスである。

ＲＯＭ(1)３７には、２つのプログラムとデータが格納されている。この２つのプログラムとは、電源ＯＮ時に動作する第１のプログラムと、第１のプログラムから起動する第２のプログラムである。
電源ＯＮ時に、ＲＯＭ(1)３７上の第１のプログラムをＣＰＵ（Central Processing Unit）２０が実行して、第２のプログラムをメモリ１１上にロードする。
メモリ１１上にロードした第２のプログラムは、第１のプログラムを実行後に実行される。
第２のプログラムに下記の省エネルギーモードにおけるネットワークとのパケット通信処理を実行するプログラムを記録（記憶）しておくことで、ＣＰＵ２０が、この記録媒体に記録した制御・処理プログラムや制御データ等をメモリ１１に読込み、処理の実行時に当該プログラムを駆動することによって、ＣＰＵ２０（コンピュータ）を当該処理の実行手段として機能させることができる。

コントローラボード１のＡＳＩＣ１０は、主制御部であるＣＰＵ２０、メモリ１１とデータのやり取りをするためのメモリインタフェース（ＭＥＭＩ／Ｆ）部２１、ＰＨＹ１２と通信するメディアアクセス制御部（Media Access Control：ＭＡＣ）２２、ＭＡＣ２２から出力されるパケットを受信して、そのパケットの種類を選別するパケットフィルタ部（以下「ＰＦ」という）２３、ＰＦ２３から出力されるパケットの処理及び所定のプロトコルに従い自発的に或いは受信パケットに応答してネットワークに送信するパケットの処理を行うネットワークパケットエンジン処理部（ＰＥ）２４及びＰＥ２４で処理されたデータと内部バス（インターナルバス：Internal BUS）３４からきたデータを受信し、そのいずれか一方をＭＡＣ２２に送信するセレクタ（ＳＥＬ）２５を搭載している。

ＡＳＩＣ１０は、また、ＡＳＩＣクロック生成部１４をもとにＡＳＩＣのクロックを発生するＣＧ２６、ＰＣＩバス３にデータ転送を行うＰＣＩインタフェース（ＰＣＩ Ｉ／Ｆ）部２７、Memory Card １５に対してデータの読み書きをするメモリカード インタフェース部（ Memory Card Ｉ／Ｆ）２８、ＯＰ１６の入出力を制御するオペレーションパネルインタフェース部（ＯＰＥ Ｉ／Ｆ）２９、ＨＤＤ１７に対するデータの読み書きを制御するハードディスクドライブインタフェース部（ＨＤＤ Ｉ／Ｆ）３０、汎用インプットアウトプット インタフェース部（Ｉ／Ｏ Ｉ／Ｆ）３１を搭載している。

ＣＰＵ２０は、上記のように第２のプログラム起動し、プリンタの初期化を行った後、プリンタのＩＰアドレスの設定を行う。
本実施形態では、ＤＨＣＰ（Dynamic Host Configuration Protocol）プロトコルによってネットワーク上の送信元或いは送信先のＩＰアドレス等の設定を行う。このＩＰアドレスの設定動作の概要について、次に説明する。
図１７は、ＤＨＣＰプロトコル・シーケンスの概要である。また、図１８は、ＤＨＣＰプロトコルに用いるＵＤＰパケット（後述する“ＵＤＰパケット”の説明、参照）のフォーマットであり、図１９は、ＵＤＰパケットに埋め込むＵＤＰデータの構成を示す。なお、ＤＨＣＰプロトコルについては、ＲＦＣ（Request For Comments）１５４１に詳細が記載されている。

ここで、図１７のシーケンスに従ってＤＨＣＰクライアント（Ｃｌｉｅｎｔ）側で行うＩＰアドレス等の設定の処理フローを図２０のフロー図を参照して説明する。
ＣＰＵ２０は、プリンタを稼動状態にするために行う初期設定を実行した（ステップＳ１０１）後、ＤＨＣＰ Ｄｉｓｃｏｖｅｒコマンドをブロードキャストパケットで送信する（シーケンスＳｑ I）（ステップＳ１０２）。
送信されたＤＨＣＰ Ｄｉｓｃｏｖｅｒコマンドを受信するＤＨＣＰサーバ（Ｓｅｒｖｅｒ）が、コマンドに応えてＤＨＣＰ ＯｆｆｅｒによってＩＰアドレスを提示する（シーケンスＳｑ II）（ステップＳ１０３）。このとき、複数のＤＨＣＰサーバからＩＰアドレスを提示される可能性があるので、ＤＨＣＰクライアント側は、どのＤＨＣＰサーバからのＩＰアドレスを受け付けるかを予め決めておく必要がある。例えば、設定対象とするＤＨＣＰサーバのＩＰアドレスを予め決めておけば、特定のＤＨＣＰサーバからのＤＨＣＰ Ｏｆｆｅｒを受け付けることができる。

予め決定しておいたＤＨＣＰサーバからのＤＨＣＰ Ｏｆｆｅｒを受け付けた（ステップＳ１０４）後、ＤＨＣＰクライアントは、ＤＨＣＰ Ｏｆｆｅｒを受け付けたＤＨＣＰサーバからＤＨＣＰ ＡＣＫの応答を得るために、このＤＨＣＰサーバを指定してＤＨＣＰ ＲＥＱＵＥＳＴで再度ブロードキャストする（シーケンスＳｑ III）（ステップＳ１０５）。なお、ＤＨＣＰ ＡＣＫには、設定されるＩＰアドレス等が記されている（詳細は後述）。
この後、ＤＨＣＰクライアントは、ＤＨＣＰ ＲＥＱＵＥＳＴに応えてＤＨＣＰサーバから送信されてくるＤＨＣＰ ＡＣＫを受信する（シーケンスＳｑ IV）（ステップＳ１０６）。この受信動作において、ＤＨＣＰ ＲＥＱＵＥＳＴを送信してから所定の時間が経過してもＤＨＣＰ ＡＣＫが受信できない場合には、延長要求としてＤＨＣＰ ＲＥＱＵＥＳＴを繰り返して送信する。このときには、図２１に示すＤＨＣＰ ＲＥＱＵＥＳＴ（延長要求時）を発行する。なお、延長要求時には、図１７のシーケンスに示した、ＤＨＣＰ Ｄｉｓｃｏｖｅｒ→ＤＨＣＰ Ｏｆｆｅｒは、省略可能である。

ＤＨＣＰプロトコルに用いるＵＤＰパケットに埋め込むＵＤＰデータ（図１８のフォーマットにおいてＵＤＰヘッダに続いて設定されるデータ部分）の構成は、図１９に示すフィールドをなす。図１９に示すフィールド構成における各データの定義とデータサイズは以下のとおりである。
ＯＰは、オペレーションコードである。データサイズは１バイトで、１の時はＢＯＯＴ ＲＥＱＵＥＳＴであり、２の時は ＢＯＯＴ ＲＥＰＬＹを示す。
ｈｔｙｐｅは、ハードウェア番号である。データサイズは１バイトで、１はイーサネット（登録商標）を示す。
ｈｌｅｎは、ハードウェアアドレス長である。データサイズは１バイトで、イーサネット（登録商標）では６である。
ｈｏｐｓは、転送回数である。データサイズは１バイトで、ＤＨＣＰクライアントは使用しない。
ｘｉｄは、トランザクションＩＤである。データサイズは４バイトである。
ｓｅｃｓは、経過時間である。データサイズは２バイトである。
ｆｌａｇｓは、ブロードキャストフラグである。データサイズは２バイトである。０ｘ８０００はブロードキャストであることを示し、０の時はユニキャストである。

ｃｉａｄｄｒは、クライアントＩＰアドレスである。データサイズは４バイトである。ＤＨＣＰ ＲＥＱＵＥＳＴでクライアントが以前に割り当てられたアドレスを設定する。
ｙｉａｄｄｒは、要求者ＩＰアドレスである。データサイズは４バイトである。
ｓｉａｄｄｒは、次回の初期化で使用すべきサーバのＩＰアドレスである。データサイズは４バイトである。 ＤＨＣＰ Ｏｆｆｅｒ、ＤＨＣＰ ＡＣＫ、ＤＨＣＰ ＮＡＫでサーバが返答する。
ｇｉａｄｄｒは、リレイエージェントＩＰアドレスである。データサイズは４バイトである。リレイエージェントを 使用する時に使用される。
ｃｈａｄｄｒは、クライアントハードウェアアドレスである。データサイズは１６バイトである。
ｓｎａｍｅは、サーバのホスト名である。データサイズは６４バイトである。オプションで、ヌル文字で終わる文字列で示す。
ｆｉｌｅは、ブートファイル名である。データサイズは１２８バイトである。ヌル文字で終わる文字列で示す。
ｏｐｔｉｏｎｓは、オプションである。データサイズは３１２バイトである。オプションについては、ＲＦＣ１５３３に詳細が記載されている。

図２０のフローに戻ると、ステップＳ１０６の後、ＤＨＣＰクライアントは、ＤＨＣＰ ＡＣＫに記されたＩＰアドレス等をＤＨＣＰサーバに使用するＩＰアドレス等のパラメータとして設定する。
即ち、ＣＰＵ２０は、ＲＯＭ(2)３８に格納してあるＭＡＣアドレスをＰＥ２４（図１５を参照して詳細は後述）のレジスタ部２４２にある要求元ハードウェアアドレス（ＳＨＡ）に格納する。また、選択したＤＨＣＰサーバから受信したＤＨＣＰ ＡＣＫプロトコル上のＣｌｉｅｎｔＩＰアドレスがプリンタ（本機）のＩＰアドレス（図１９のＤＨＣＰプロトコルのデータ構成におけるｃｉａｄｄｅｒ）となる。このＩＰアドレスをＣＰＵ２０は、ＰＥ２４のレジスタ部２４２にある要求元ＩＰアドレス（ＳＩＰ）に格納しておく。

さらに、予めＤＨＣＰサーバのＩＰアドレスを決めておくのでそのＩＰアドレスを送信先ＩＰアドレス（ＤＩＰ）に設定しておく。ＤＨＣＰサーバのハードウェアアドレスは、ＤＨＣＰプロトコルから求めることができる。例えば、ＤＨＣＰ ＡＣＫプロトコルから求める場合、ＤＨＣＰ ＡＣＫプロトコルで使用したイーサネット（登録商標）ヘッダの送信元ＭＡＣアドレスからハードウェアアドレスを求めることができる。イーサネット（登録商標）ヘッダの送信元ＭＡＣアドレスを送信先ハードウエアアドレス（ＤＨＡ）に格納しておく。また、ＤＨＣＰ ｏｆｆｅｒプロトコルを利用してもＤＨＣＰ ＡＣＫプロトコルと同様にハードウェアアドレスを求めることができる。
このようにして、ＣＰＵ２０がＤＨＣＰサーバとプリンタ（本機）のＩＰアドレス、ハードウェアアドレスを求めることができる。
また、ＤＨＣＰ ＡＣＫプロトコルにはＩＰアドレスのリース時間が設定されているので、この時間の半分の値をＰＥ２４の定期送信間隔時間設定部２４９にＴｉｍｅｒ１として保存しておく（後記ＰＥ２４の説明で詳述）。

“電源供給制御とコントローラの動作”
ＡＳＩＣ１０は、さらに、コントローラボード１の内外の各部への電源（図示を省略）からの給電を制御するパワーマネジメント部（以下「ＰＭ」という）３２、タイマ（Timer）３３を搭載している。
ＡＳＩＣ１０の内部には、ＣＰＵ２０、メモリ１１及びパワーオフ領域（Power OFF Area）３５という、ＰＭ３２によって電源から電力の供給、停止を制御できる回路要素や領域がある。なお、上記以外のコントローラボード１上の回路要素には常に電力が供給される。
パワーオフ領域３５は、ＰＣＩ Ｉ／Ｆ２７、Ｍｅｍｏｒｙ Ｃａｒｄ Ｉ／Ｆ２８、ＯＰＥ Ｉ／Ｆ２９、ＨＤＤ Ｉ／Ｆ３０、Ｉ／Ｏ Ｉ／Ｆ３１からなり、ネットワーク動作に直接関係しない回路部の領域である。

ＡＳＩＣ１０のＰＭ３２は、プリンタに電源が投入された後、機器の使用状態に応じて、電源供給モードを設定することで電源の消費を管理する。電源供給モードとして、機器全体の動作が可能な状態に電力供給を行う通常動作モードと、一部の電力供給を停止する低消費電力モードを設け、各モードにおいて設定された制御条件に従い電源供給を制御する。
この実施形態では、基本的には、各電源供給モード間の移行動作の遷移を示す図２（Ａ）に示すように、プリンタ全体が動作可能な状態となるように電源を供給する通常動作モードと、低消費電力モード（以下「省エネモード」という）として、ボード電力制御部１８と外部電力制御部１９をそれぞれ制御して、ＣＰＵ２０、メモリ１１及びパワーオフ領域（Power OFF Area）３５への電力供給を停止し、同時に、コントローラボード１とＰＣＩバス３を介して接続されるプロッタ２等へも電力供給を停止する動作を行う。

プリンタの電源ボタン（図示を省略）がオンにされ、ＡＳＩＣ１０に電源からの電力が供給されると、ＰＭ３２が通常動作モードの設定で電源を供給する。
通常動作モードの場合、ＰＭ３２は、ＣＰＵ２０とメモリ１１に電源からの電力を供給する。さらに、パワーオフ領域３５の各部（ＰＣＩ Ｉ／Ｆ２７、Ｍｅｍｏｒｙ Ｃａｒｄ Ｉ／Ｆ２８、ＯＰＥ Ｉ／Ｆ２９、ＨＤＤ Ｉ／Ｆ３０、Ｉ／Ｏ Ｉ／Ｆ３１）への電力の供給を開始し、ボード電力制御部１８、外部電力制御部１９によってコントローラボード１内外の各部へも電力を供給する。この状態で、ＡＳＩＣ１０はこのプリンタ全体の制御を開始し、通常の動作が可能になる。

また、通常動作モードになると、ＰＭ３２は、タイマ３３を起動し、タイマ３３の時間が通常動作モードの設定から予め設定した所定時間を経過しても、ネットワークからこのプリンタ（自局）宛のパケットの受信が無いことがＰＦ２３によって確認され、かつ、ＣＰＵ２０上で動作しているアプリケーション全てがアイドル状態になった場合、省エネモードに移行する制御を行う（図２（Ａ）中の（２）の遷移）。
プリンタ（自局）宛のパケットの受信が無いことは、ＰＦ２３のバッファ（後述する図１３のバッファ２３５）からのエンプティフラグで認識できる。

ＰＭ３２は、電源供給モードを省エネモードに移行すると、ＣＰＵ２０とメモリ１１への電力の供給を停止する低消費電力モードに設定する。さらに、ＡＳＩＣ１０の内部のパワーオフ領域３５内の各部への電力の供給を停止し、ボード電力制御部１８によってＭｅｍｏｒｙ Ｃａｒｄ １５、ＯＰＥ １６、及びＨＤＤ１７への電源からの電力の供給を停止し、外部電力制御部１９によってコントローラボード１外のプロッタ２を含む各部（プロッタ２以外の図示を省略）への電源からの電力の供給を停止する。さらに、ＰＭ３２は、ＳＥＬ２５に対してＰＥ２４の出力を選択することを指示する。

また、電源供給モードを移行する際に、ＰＭ３２は、ＭＥＭＩ／Ｆ２１に移行を通知することによって、ＭＥＭＩ／Ｆ２１を介してメモリ１１の消費電力も制御する。
上記メモリ１１の消費電力の制御は、省エネモードに移行すると、ＰＭ３２がＭＥＭＩ／Ｆ２１を介してメモリ１１をセルフリフレッシュモードに移行させ、メモリ１１は省エネルギーモードに移行前の状態の情報を保存し、省エネモードに移行する。
また、通常動作モード又はコントローラモードに移行する場合、ＰＭ３２がＭＥＭＩ／Ｆ２１を介してメモリ１１を通常動作モードに移行させ、メモリ１１に対して内部バス３４を介してアクセスが可能になる。
省エネルギーモードから通常動作モードに復帰する場合、メモリ１１は、省エネルギーモードに移行する前の状態の情報に復帰させる。

ＰＨＹ１２には、常時給電が行われるので、低消費電力モードでも、ネットワークとパケットを交信することが可能である。
この実施形態では、省エネルギーモードに移行したときでも、常時給電が行われるＰＥ２４で自発的に所定のパケットデータを生成する処理を行い、ＰＨＹ１２を介してネットワークにパケットを送信する。具体的には、省エネルギーモードに移行したときから、電力の供給が停止されているＣＰＵ２０を動作させることなく、ＰＥ２４でＤＨＣＰ ＲＥＱＵＥＳＴパケットを生成し、送信する処理を行う。また、ＤＨＣＰプロトコルに従い、ＤＨＣＰ ＲＥＱＵＥＳＴの送信先からの応答パケットをＰＦ２３によって受取ることを可能にする。
さらに、この実施形態では、低消費電力モード時に受信したパケットが自局宛ではない場合、パケットフィルタ部ＰＦ２３でそれらのパケットを破棄するが、自局宛のパケットの場合には、ＰＥ２４で所定のパケットのリクエストに応えるために予め設定しておいたデータを送信元が受取ることができる所定フレーム構造のパケットとして生成し、応答することを可能にする。

なお、電源供給モード間の移行動作の遷移を示す図２（Ｂ）には、低消費電力モードとして、コントローラモードを付加した例を示している。省エネモード時にＰＨＹ１２を介して受取るパケットのうち、後記で詳述する、ＣＰＵ２０の動作を必要としないで、ネットワークへ応答する動作を行うことができるものがあるが、それ以外のパケットを受取った場合には、ＣＰＵ２０の動作が必要であり、停止していたＣＰＵ２０への給電を復帰する。ただ、コントローラモードでは、印刷を要求しない（以下「非印刷要求」という）パケットに対して、ＣＰＵ２０のコントローラとしての動作を確保するために限定的な給電を行い、パワーオフ領域（Power OFF Area）３５への電力供給を停止させ、プロッタ２の動作も停止させたままであるから、低消費電力モードの１形態である。
よって、図２（Ｂ）における省エネモードからの遷移では、印刷を要求するパケットに対しては、通常動作モードに復帰させる（図２（Ｂ）中の（１）の遷移）が、非印刷要求のパケットに対しては、コントローラモードへ移行する（図２（Ｂ）中の（３）の遷移）動作となる。なお、コントローラモードにおいても、省エネモードへの移行（図２（Ｂ）中の（４）の遷移）及び通常モードへの移行（図２（Ｂ）中の（５）の遷移）は、図２（Ａ）の基本動作と同様の条件で行われる。

「ネットワークと交信可能なパケット」
ここで、このプリンタがネットワークと交信することができる所定フレーム構造のパケットの例として、イーサネット（登録商標）フレームとパケットの種類について説明する。
“イーサネット（登録商標）フレーム”
図３は、イーサネット（登録商標）フレームの構造及びフォーマットを説明する図で、（Ａ）にはフレーム構造を示し、（Ｂ）にはフレーム内の各フィールドのデータ内容の一例を示す表である。
図３（Ａ）に示すように、イーサネット（登録商標）フレームは、プリアンブル、宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、タイプ、データ、及びＦＣＳ（Frame Check Sequence）からなる。
プリアンブルは、図３（Ｂ）に示すように、データ長が６４ビット（８バイト）であるフレームの開始を示す情報であり、「１０」を交互に入力して最後の２ビットが「１１」になる入力値「１０１０．．．１１」が入力される。
宛先ＭＡＣアドレスと送信元ＭＡＣアドレスは、それぞれパケットの宛先の装置（例えば、ＬＡＮ接続されたプリンタ等の機器）のアドレスとパケットの送り主の装置のアドレスであり、ともにデータ長は４８ビット（６バイト）である。上記ＭＡＣ（Media Access Control）は、ＩＥＥＥ８０２−１９９０で規定されている。

宛先ＭＡＣアドレスには、ネットワーク内の個々の通信機器を特定するユニキャストアドレス、ネットワーク内のブロードキャストドメイン内全体の通信機器を宛先対象とするブロードキャストアドレス、ネットワーク内の所定の通信機器のグループ内の各通信機器を宛先対象とするマルチキャストアドレスがある。ブロードキャストアドレスの場合は、全てのビットが１になる。
タイプは、「０ｘ０８００」の時はＩＰｖ４（Internet Protocol Version 4）プロトコルを、「０ｘ０８０６」の時はＡＲＰ（Address Resolution Protocol）プロトコルを、「０ｘ８６ＤＤ」の時はＩＰｖ６プロトコルを、「０ｘ８０９Ｂ」の時はＡｐｐｌｅＴａｌｋのプロトコルを、「０ｘ８０３７」の時はＩＰＸ（ＮｅｔＷａｒｅ）のプロトコルを、「０ｘ８１９１」の時はＮｅｔＢＩＯＳ／ＮｅｔＢＥＵＩ（NetBIOS Extended User Interface）のプロトコル（上記各プロトコルは登録商標である）をそれぞれ指定する。
データは、４６〜１５００バイト長まで指定可能である。
ＦＣＳは、チェックサムでＣＲＣ（Cyclic Redundancy Check）−３２の多項式で生成されたものである。

“ＩＰパケット”
図４（Ａ）はイーサネット（登録商標）パケットフォーマットである。図４（Ｂ）は、イーサネット（登録商標）フレーム（図３）におけるＩＰパケットのフォーマットを示す図である。
図４（Ｂ）に示すＩＰパケットのフレームは、イーサネット（登録商標）フレーム（図３）におけるイーサネット（登録商標）ヘッダのタイプに、同図（Ｂ）に破線で示すように、「０ｘ０８００」を入れる。
ＩＰパケットを構成する場合、図４（Ｂ）に示すように、上記イーサネット（登録商標）フレームのデータに、ＩＰヘッダとデータを含める。

図５は、ＩＰパケットのフォーマットを示す説明図である。
図５に示すように、ヘッダ部（ＩＰヘッダ）とデータ部とからなるＩＰパケットのヘッダ部は、バージョン（Version）フィールド、ヘッダ長（IHL）フィールド、サービスタイプ（Type Of Service）フィールド、パケット長（Total Length）フィールド、識別子（Identification）フィールド、フラグ（Flags）フィールド、フラグメントオフセット（Flagment Offset）フィールド、生存時間（Time To Live）フィールド、プロトコル番号（Protocol）フィールド、ヘッダチェックサム（Header Checksum）フィールド、送信元ＩＰアドレス（Source Address）フィールド、宛先ＩＰアドレス（Destination Address）フィールドからなる。
さらに、オプションが付く場合があり、オプション（Options）とパディング（Padding）を含めたフィールドのデータ長が３２ビットの倍数になるようにパディングする。ただ、オプションは、通常使用されない。

図５に示すＩＰヘッダのバージョンフィールドは、データ長が４ビットであり、ＩＰｖ４プロトコルの場合は「４」が、ＩＰｖ６プロトコルの場合は「６」がそれぞれ格納される。
ヘッダ長フィールドは、データ長が４ビットであり、ＩＰｖ４プロトコルの場合は２０バイトである。
生存時間フィールドは、ネットワーク上でのパケットの生存時間の値が格納され、ルータを通過するたびにその値が１つずつ減らされ、「０」になったらパケットは破棄される。その詳細はＲＦＣ（Request For Comments）２２００に記載されているので、説明を省略する。
サービスタイプはＲＦＣ７９１、プロトコル番号の詳細については、ＲＦＣ１７００に記載されているので、説明を省略する。
識別子フィールドに格納される値は、フラグメントを復元する際の識別子として使用される。
フラグフィールドは、パケットの分割に関する制御を示す値が格納される。

“ＵＤＰパケット”
図４（Ｂ）、（Ｃ）は、イーサネット（登録商標）フレーム（図３）におけるＩＰパケットとＵＤＰ（User Datagram Protocol）パケットのフォーマットを示す図である。また、図６は、ＵＤＰパケット内の各フィールドのデータ内容を示す説明図である。
図４（Ａ）に示すＵＤＰ（User Datagram Protocol）パケットのフレームは、イーサネット（登録商標）フレーム（図３）におけるイーサネット（登録商標）ヘッダのタイプに、同図（Ｂ）に波線で示すように、「０ｘ０８００」を入れる。
ＩＰパケットを構成する場合、図４（Ｂ）に示すように、上記イーサネット（登録商標）フレームのデータに、ＩＰヘッダとデータを含める。
ＵＤＰパケットを構成する場合、ＩＰヘッダ内にはプロトコルのデータとして、ＵＤＰを指定するデータを格納し、ＩＰパケットのデータに、ＵＤＰヘッダとデータを含める。

図６は、ＵＤＰパケット内の各フィールドのデータ内容を示す説明図である。
ＵＤＰパケットは、送信元ポート番号（１６ビット）フィールド、宛先ポート番号（１６ビット）フィールド、セグメント長（１６ビット）フィールド、チェックサム（１６ビット）フィールド及びデータからなる。
上記送信元ポート番号フィールドと宛先ポート番号フィールドに格納される送信元ポート番号と宛先ポート番号のポート番号は、アプリケーションの識別に使用される。また、ウェルノウンポート番号として標準で決められている番号（ＲＦＣ１７００で公開済）がある。ＵＤＰの詳細は、ＲＦＣ７６８に記載されているので、説明を省略する。

“ＴＣＰパケット”
図７（Ａ）はイーサネット（登録商標）パケットフォーマットである。図７（Ｂ）、（Ｃ）は、イーサネット（登録商標）フレーム（図３）におけるＩＰパケットとＴＣＰ（Transmission Control Protocol）パケットのフォーマットを示す図である。また、図８は、ＴＣＰパケット内の各フィールドのデータ内容を示す説明図である。
図７（Ａ）に示すＴＣＰパケットのフレームは、イーサネット（登録商標）フレーム（図３）におけるイーサネット（登録商標）ヘッダのタイプに、同図（Ｂ）に波線で示すように、「０ｘ０８００」を入れる。
ＩＰパケットを構成する場合、図６（Ｂ）に示すように、上記イーサネット（登録商標）フレームのデータに、ＩＰヘッダとデータを含める。
ＴＣＰパケットを構成する場合、図７（Ｃ）に示すように、上記ＩＰパケットのデータに、ＴＣＰヘッダとデータを含める。ＴＣＰヘッダ内にはコードビットとして、０ビット目に「ＦＩＮ」、１ビット目に「ＳＹＮ」、２ビット目に「ＲＳＴ」、３ビット目に「ＰＳＨ」、４ビット目に「ＡＣＫ」、５ビット目に「ＵＲＧ」を格納する。また、同図（Ｃ）に波線で示すように、ＩＰヘッダのプロトコルには、ＴＣＰプロトコルを示すデータの「６」を入れる。

図８に示すように、ヘッダ部（ＴＣＰヘッダ）とデータ部とからなるＴＣＰパケットのヘッダ部は、送信元ポート番号（Source Port 、１６ビット）フィールド、宛先ポート番号（Destination Port 、１６ビット）フィールド、シーケンス番号（Sequence Number 、３２ビット）フィールド、確認応答番号（Acknowledgement Number 、３２ビット）フィールド、データオフセット（Data Offset 、４ビット）フィールド、予約（Reserved 、６ビット）フィールド、コードビット（６ビット）フィールド、ウインドウサイズ（１６ビット）フィールド、チェックサム（Checksum 、１６ビット）フィールド、緊急ポインタ（Urgent Pointer 、１６ビット）フィールドからなる。
さらに、オプションとパディングがある場合があり、その後にデータがある。
上記送信元ポート番号フィールドと宛先ポート番号フィールドに格納される送信元ポート番号と宛先ポート番号のポート番号は、アプリケーションの識別に使用される。また、ウェルノウンポート番号として標準で決められている番号（ＲＦＣ１７００で公開済）がある。ＴＣＰの詳細はＲＦＣ７９３に記載されているので、説明を省略する。

“ＩＣＭＰパケット”
図９（Ａ）はイーサネット（登録商標）パケットフォーマットである。図９（Ｂ）、（Ｃ）は、イーサネット（登録商標）フレーム（図３）におけるＩＰパケットとＩＣＭＰ（Internet Control Message Protocol）パケットのフォーマットを示す図である。また、図１０は、ＩＣＭＰエコーリクエストとＩＣＭＰエコーリプライのパケットの各フィールドのデータ内容を示す説明図である。
ＩＣＭＰパケットのフレームは、図９（Ａ）、（Ｂ）に示すように、イーサネット（登録商標）フレーム（図３）におけるイーサネット（登録商標）ヘッダのタイプに「０ｘ０８００」を入れ、イーサネット（登録商標）フレームのデータに、ＩＰヘッダとデータを含める。この点は、基本的に上記ＴＣＰパケットやＵＤＰパケットと同じである。
ただ、ＩＣＭＰパケットを構成する場合、ＩＰヘッダ内にはプロトコルのデータとして、図９（Ｃ）に示すように、ＩＣＭＰを指定するデータ「１」を格納し、ＩＰパケットのデータに、ＩＣＭＰヘッダとデータを含める。また、ＩＣＭＰヘッダのタイプには、ＩＣＭＰエコーリクエスト（エコー要求）パケットの場合は「８」であり、ＩＣＭＰエコーリプライ（エコー応答）パケットの場合は「０」を入れる。また、ＩＣＭＰヘッダ内には、ＩＣＭＰエコーリクエストパケットとＩＣＭＰエコーリプライパケットにおけるコードビットとして、常に「０」が格納される。さらに、データは任意の長さであるが、通常は６４バイトのデータ長である。

図１０は、ＩＣＭＰエコーリクエストとＩＣＭＰエコーリプライのパケット内の各フィールドのデータ内容を示す説明図である。
ＩＣＭＰエコーリクエストとＩＣＭＰエコーリプライのパケットは、メッセージタイプフィールド、コードフィールド、チェックサムフィールド、識別子フィールド、シーケンス番号フィールドとデータからなる。
ＩＣＭＰエコーパケットは、公知技術なのでその詳細な説明は省略するが、メッセージタイプフィールドには、上述したＩＣＭＰエコーリクエストパケットの場合は「８」を、ＩＣＭＰエコーリプライパケットの場合は「０」を格納する領域である。コードフィールドには、上述したように、ＩＣＭＰエコーリクエストパケットとＩＣＭＰエコーリプライパケットの場合は常に「０」を格納する領域である。

“ＡＲＰパケット”
図１１は、イーサネット（登録商標）フレーム（図３）におけるＡＲＰパケットのフォーマットを示す図である。
図１１（Ｂ）に示すＡＲＰパケットのフレームは、イーサネット（登録商標）フレーム（図３）におけるイーサネット（登録商標）ヘッダのタイプに、同図（Ｂ）に波線で示すように、「０ｘ０８０６」を入れる。
ＡＲＰパケットを構成する場合、図１１（Ｂ）に示すように、上記イーサネット（登録商標）フレームのデータに、オペレーションコードフィールドとＡＲＰパケットを含め、オペレーションコードフィールドに「１」が格納されている場合はＡＲＰリクエストパケットを指定し、「２」が格納されている場合はＡＲＰレスポンスパケットを指定する。

図１２（Ａ）は、ＡＲＰパケットのフォーマットを示す説明図、図１２（Ｂ）は、ＡＲＰパケット内の各フィールドのデータ内容の一例を示す説明図である。
図１２（Ａ）に示すように、ＡＲＰパケットは、ハードウェアタイプフィールド、プロトコルタイプフィールド、ＭＡＣアドレス長（ＨＬＥＮ）フィールド、プロトコルアドレス長（ＰＬＥＮ）フィールド、オペレーションコードフィールド、送信元ＭＡＣアドレスフィールド、送信元ＩＰアドレスフィールド、宛先ＭＡＣアドレスフィールド、宛先ＩＰアドレスフィールドからなる。

図１２（Ｂ）に示すように、ハードウェアタイプフィールドは、１６ビットのデータ長であり、イーサネット（登録商標）を示す場合は「１」が格納される。
プロトコルタイプフィールドは、１６ビットのデータ長であり、ＩＰアドレスを使用し、ＩＰｖ４プロトコルを示す場合は「２０４８」が格納される。
ＭＡＣアドレス長フィールドは、４８ビットのデータ長であり、ＭＡＣアドレスを示す６バイトのデータが格納される。ＩＰｖ４プロトコルを示す場合、「６」が格納される。
プロトコルアドレス長フィールドは、３２ビットのデータ長であり、ＩＰｖ４プロトコルを示す場合、「４」が格納される。

オペレーションコードフィールドは、１６ビットのデータ長であり、１の時はＡＲＰリクエストを、２の時はＡＲＰリプライをそれぞれ示す。
送信元ＭＡＣアドレスフィールド、送信元ＩＰアドレスフィールド、宛先ＭＡＣアドレスフィールド、宛先ＩＰアドレスフィールドは、それぞれ４８，３２，４８，３２の各データ長であり、それぞれ送信元ＭＡＣアドレス、送信元ＩＰアドレス、宛先ＭＡＣアドレス、宛先ＩＰアドレスが格納される。

「ネットワークパケットエンジン処理部：ＰＥ（実施形態１）」
次に、省エネルギーモードにおいて動作が可能なネットワークパケットエンジン処理部（ＰＥ）２４について説明する。
ここで実施形態１として例示するＰＥ２４は、省エネルギーモードでも、自発的に所定のパケットデータを生成し、ネットワークにパケットを送信する処理を行うもので、具体的には、省エネルギーモードに移行したときから（即ち、電力の供給が停止されているＣＰＵ２０を動作させずに）、ＤＨＣＰ ＲＥＱＵＥＳＴパケットを生成し、このパケットを予め設定した送信時間間隔で定期的に送信する処理を行えるようにする。また、送信したＤＨＣＰ ＲＥＱＵＥＳＴパケットに対して所定時間内に何の応答もない場合には、省エネルギーモードを維持したまま当該パケットの再送を行えるようにする。

図１３は、本実施形態のＰＥ２４の内部構成例を示すブロック図である。
ＰＥ２４は、ネットワーク送信制御部２４１、レジスタ部２４２、Ｅｔｈｅｒ（イーサネット（登録商標））フレームヘッダ生成部２４３、ＩＰパケット生成部２４７、定期送信間隔時間設定部２４９からなる。
ネットワーク送信制御部２４１は、定期送信間隔時間設定部２４９のＴｉｍｅｒ(1)２４９ｔに設定した時間間隔でＩＰパケットとしてのＤＨＣＰ ＲＥＱＵＥＳＴが生成できるように定期送信時間間隔を制御する。

また、ネットワーク送信制御部２４１は、再送制御部２４１１を備える。ＤＨＣＰ ＲＥＱＵＥＳＴパケットの定期送信は、リクエストに応答するＤＨＣＰ ＡＣＫの受信がある間、継続して行われ、必要なデータの収集を行う。ただ、ＤＨＣＰ ＲＥＱＵＥＳＴパケットに対して所定時間内に何の応答もない場合には、定期送信は中断され、該当する送信データの再送が行われる。
再送制御部２４１１は、このために備わり、前記所定時間をＴｉｍｅｒ(2)２４１１ｔに設定し、ここに設定された時間を越えて、何の応答もない場合に再送処理を行う。再送制御部２４１１は、繰返し回数２４１ｎを限度に再送処理を行う。なお、ネットワーク送信制御部２４１の動作の詳細は、後述する図２２及び図２３に示す制御フローを参照して説明する。

ＩＰパケット生成部２４７は、識別データ生成部２４７３、ＤＨＣＰパケット生成部２４７６、ＵＤＰヘッダ生成部２４７２、ＩＰヘッダ生成部２４７１からなる。
識別データ生成部２４７３は、ＤＨＣＰ ＲＥＱＵＥＳＴパケットで使用するＴｒａｎｓｃｔｉｏｎＩＤを生成するトランザクション（Transaction）ＩＤ生成部２４７３ｔ、ＵＤＰパケットのポート番号を生成するポート番号生成部２４７３ｎ、ＩＰパケットの識別子を生成する識別子生成部２４７３ｉからなる。なお、ポート番号生成部２４７３ｎは、送信先ポート番号として６７、宛先ポート番号として６８をそれぞれ生成する。

ＤＨＣＰパケット生成部２４７６では、トランザクションＩＤ生成部２４７３ｔで生成したトランザクションＩＤを使用してＤＨＣＰ ＲＥＱＵＥＳＴパケットを生成する。
ＵＤＰヘッダ生成部２４７２では、図６の送信元ポート番号、宛先ポート番号、セグメント長及びチェックサムよりなるＵＤＰヘッダを生成する。宛先ポート番号及び送信元ポート番号は、識別データ生成部２４７３で生成したデータを埋め込む。セグメント長は、ＵＤＰデータの長さを設定する。なお、ＵＤＰデータは、ＤＨＣＰ ＲＥＱＵＥＳＴパケットなので、ＤＨＣＰ ＲＥＱＵＥＳＴパケットの長さを設定すればよい。ＣｈｅｃｋＳＵＭ（チェックサム）は、ヘッダ、ＵＤＰデータの１の補数を１６ビットで示す。チェックサムの計算は、ＩＰのチェックサム計算と同様であり、この計算は、例えば、オーム社発行の書籍「マスタリングＴＣＰ／ＩＰ 応用編」で記載されている１の補数演算方法を使用することにより実施し得る。

ＩＰヘッダ生成部２４７１では、ＩＰパケットフォーマット（図５）の中のオプション、Ｐａｄｄｉｎｇ及びデータ部を除いた箇所をＩＰパケットのヘッダとして生成する。
ＩＰパケットのヘッダの生成に用いるデータとして、予め、プリンタの自局ＩＰアドレスをレジスタ部２４２のＳＩＰに、プリンタの自局のハードウェアアドレスをレジスタ部２４２のＳＨＡに設定しておく。また、レジスタ部２４２には、ＤＨＣＰサーバのＩＰアドレスをＤＩＰに、ハードウェアアドレスをＤＨＡに設定しておく。なお、レジスタ部２４２におけるこれらの設定については、ＩＰアドレス設定の処理フローを示す図２０、特にステップＳ１０７の説明を参照されたい。

ＩＰパケットフォーマット（図５）中のＴＹＰＥには、ＩＰを示す０ｘ８００を設定する。バージョンは４、ヘッダ長は５を設定する。サービスタイプは０を設定する。パケット長は、ＩＰヘッダ長、ＵＤＰヘッダ長及びＵＤＰデータ長の和を設定する。
また、識別子は、識別データ生成部２４７３の識別子生成部２４７３ｉで生成した識別子を設定する。この識別子は、ＩＰパケットを送信する度に新たに生成する。
また、フラグには、分割不可、後続フラグメント無しを設定して、フラグメントオフセットは０に設定する。生存時間は最大値の２５５を設定する。プロトコルにはＵＤＰを示す値である１７を設定する。ヘッダチェックサムは、ＩＰヘッダとデータのチェックサムを計算する。送信元ＩＰアドレスと宛先ＩＰアドレスは、レジスタ部２４２に設定してあるＳＩＰ、ＤＩＰをそれぞれ設定する。また、ヘッダのオプションは生成しない。
イーサネット（登録商標）フレームヘッダ生成部２４３は、レジスタ部２４２に設定してあるＤＨＡからあて先ＭＡＣアドレス、ＳＨＡから送信元ＭＡＣアドレス、ＴＹＰＥからタイプを取出してイーサフレームの所定のフィールドに設定してイーサネット（登録商標）フレームのヘッダを生成する。
イーサネット（登録商標）パケットのＦＣＳは、ＭＡＣ２２で自動生成されるので、パケット生成部では生成する必要はない。

省エネルギーモード時には、パワーマネジメント部（ＰＭ）３２からセレクタ（ＳＥＬ）２５に対してＰＥ２４の出力を選択する指示が与えられる。また、ＰＭ３２は、省エネモードから通常モードに移行するときは、ＳＥＬ２５の入力がＰＥ２４からではなく、ＩｎｔｅｒｎａｌＢｕｓとなって、ここからのデータをＭＡＣ２２に入力する。
以上のようにして、省エネルギーモード時にＰＥ２４で生成されたＩＰパケット（ＤＨＣＰ ＲＥＱＵＥＳＴ）を含む各種のイーサネット（登録商標）パケットは、セレクタ２５、ＭＡＣ２２及びＰＨＹ１２を経由してネットワークに送信される。

「パケットフィルタ部：ＰＦ（実施形態１）」
上記で実施形態１として例示したＰＥ２４は、省エネルギーモードにおいて、自発的にＤＨＣＰ ＲＥＱＵＥＳＴパケットを生成し、生成したパケットを予め設定した送信時間間隔で定期的に送信する処理を行うので、送信したＤＨＣＰ ＲＥＱＵＥＳＴパケットへの応答として送られてくるパケットをパケットフィルタ部（ＰＦ）２３で受取らなければならない。
このため、ＰＦ２３は、ＤＨＣＰプロトコルに従って発行したＤＨＣＰ ＲＥＱＵＥＳＴの送信先からの応答として受取るＤＨＣＰ ＡＣＫ又はＤＨＣＰ ＮＡＫパケットを検出する機能を用意する。
なお、ＰＦ２３によるＤＨＣＰ ＡＣＫ又はＤＨＣＰ ＮＡＫパケットの検出結果に従って、省エネルギーモードを維持してＰＥ２４によるＤＨＣＰ ＲＥＱＵＥＳＴパケットの定期送信を継続するか、或いは省エネルギーモードから通常モードへ移行させ、主制御部のＣＰＵ２０によって行うＤＨＣＰサーバのＩＰアドレス等の設定処理（図２０のフロー、参照）を行う。この省エネルギーモード時のＰＥ２４及びＰＦ２３の動作については、フロー図（図２２，２３）を参照して後記で詳述する。

図１４は、本実施形態のＰＦ２３の内部構成例を示すブロック図である。
ＰＦ２３は、アドレスフィルタ２３１、パターンフィルタ２３３、バッファ２３５を構成要素とする。
アドレスフィルタ２３１には、ユニキャストアドレスとマルチキャストアドレスが登録可能である。また、このプリンタ自身やプリンタ内のアクセス可能なデバイス（例えば、プロッタ２など）のアドレスが設定可能である。
アドレスフィルタ２３１は、ＭＡＣ２２から入力したパケットのタイプを参照し、そのタイプからパケットの種類を判断し、設定されたアドレスをチェックすることで、アクセス可能な機器やデバイスに対するパケットのみを通過させ、パターンフィルタ２３３へ送り、その他のパケットは破棄する選別を行う。
また、ブロードキャストパケットは、アドレスフィルタ２３１の設定に関係無く、通過させてパターンフィルタ２３３へ送る。
自局宛アドレスのパケットとは、アドレスフィルタ２３１を通過させるパケットである。従って、自局宛アドレスには、登録したユニキャストアドレス（このプリンタ自身やプリンタ内のデバイスのＩＰアドレス）登録したマルチキャストアドレス及びブロードキャストアドレスが含まれる。

パターンフィルタ２３３は、マスク領域と非マスク領域からなる。非マスク領域は、バイト単位で比較データを設定できる。
マスク領域は、パケットの値に関係なく一致条件となり、この領域もバイト単位で設定できる。マスク領域のデータ長と非マスク領域のデータ長の合計がパターンフィルタ長になる。例えば、パターンフィルタ長は、２５６バイトをとる。
パターンフィルタ２３３には、パターンオフセットとしてオフセット値が設定でき、その１つは、パターンオフセット１であり、イーサネット（登録商標）フレームの開始からのオフセット長になる。パターンフィルタ２３３によるフィルタリングをイーサネット（登録商標）フレームのタイプから開始する場合は、宛先ＭＡＣアドレス長と送信元ＭＡＣアドレスを加算した値が、パターンオフセット１の長さになる。
もう１つのパターンオフセットであるパターンオフセット２は、パターンフィルタ２３３の先頭からのオフセットを示す。パターンオフセットからの１バイトはビットマスク値によって、ビットごとにフィルタリングが可能である。ビットマスク値で「１」を設定したビットはマスク領域である。

図１５は、図１４のパターンフィルタ２３３の内部構成例を示すブロック図である。
図１５に示すパターンフィルタ２３３は、ＤＨＣＰ ＡＣＫ用ＰＦ２３３ａ、ＤＨＣＰ ＮＡＫ用ＰＦ２３３ｎ、自局宛ＰＦ２３３ｓ、の各パターンフィルタを備える。パターンフィルタ２３３には、アドレスフィルタ２３１を通過したパケットが入力され、処理結果として、ＤＨＣＰ（ＡＣＫ）要求、非ＤＨＣＰ（ＤＨＣＫ ＮＡＫ）要求又は時局宛要求を出力する。なお、パターンフィルタ２３３には自局宛のパケットしかこないので、ＤＨＣＰ ＡＣＫ、またはＤＨＣＰ ＮＡＫ以外のパケットを自局宛パケットとして検出できる。即ち、ＤＨＣＰ ＡＣＫ用ＰＦ２３３ａで検出されるＤＨＣＰ（ＡＣＫ）要求ではなく、またＤＨＣＰ ＮＡＫ用ＰＦ２３３で検出される非ＤＨＣＰ（ＤＨＣＫ ＮＡＫ）要求ではない場合（或いは上記と処理順序を逆にした場合でもよい）に自局宛要求のパケットであるとみなし、自局宛要求を出力する処理方法により実施することができる。

パターンフィルタ２３３の処理として、まず、ＤＨＣＰ ＡＣＫパケットのフィルタリングの処理例を説明する。
図１６は、パターンフィルタ２３３におけるＤＨＣＰ ＡＣＫパケットのフィルタリング処理を説明する図である。図１６（ａ）は、ＵＤＰパケットのネットワークフレームのフォーマット（図４及び図１８、参照）を示し、同図（ｂ）には、ＰＦ２３のパターンフィルタ２３３に処理条件として設定する、マスク領域と非マスク領域及び非マスク領域の処理対象として参照するデータを示す。なお、ＤＨＣＰ ＡＣＫパケットは、ＤＨＣＰプロトコルにおけるＵＤＰデータの構成を基本とするので、図１９をもとに説明した先の記載を参照する。
ＤＨＣＰ ＡＣＫパケットの長さが、２５６バイト以上あるので、この実施形態のパターンフィルタ２３３におけるＤＨＣＰ ＡＣＫ用ＰＦ２３３ａでは、第１及び第２の２つのパターンフィルタを使用する。

ＤＨＣＰ ＡＣＫ用ＰＦ２３３ａの第１のパターンフィルタにおいて、パターンオフセット１として、図１６に示すように、宛先ＭＡＣアドレス長と送信元ＭＡＣアドレスを加算した値を設定し、ＵＤＰパケットの先頭の１６ビット（イーサネット（登録商標）ヘッダ）のタイプを参照するので、ここを非マスク領域として設定する。なお、ＵＤＰパケットの先頭の１６ビットにはＩＰプロトコルを示す０ｘ８００が設定されている。
イーサネット（登録商標）ヘッダのタイプの次は、ＩＰヘッダとの比較値を設定する。ＩＰヘッダのバージョン（Ｖｅｒ）にはＩＰｖ４の４を、ヘッダ長には「５」を、プロトコル番号にはＵＤＰプロトコル番号を、宛先ＩＰアドレスにはこのプリンタのＩＰアドレス（自局アドレス）をそれぞれ設定し、その他のＩＰヘッダはマスク領域（図中に斜線を施した部分）として設定する。

次にＵＤＰヘッダとの比較値を設定する。ＵＤＰヘッダのポート番号は、ＤＨＣＰプロトコルが使用するポート番号を設定する。宛先ポート番号は６７、送信元ポート番号は６８を設定する。その他ＵＤＰのヘッダ領域は、マスク領域とする。また、ＵＤＰヘッダ領域後のパターンフィルタ部もマスク領域に設定する。
さらに、ＵＤＰデータ領域については、ＤＨＣＰ ＡＣＫに対応するので、ＤＨＣＰ ＡＣＫパケットのＯＰ、ｈｔｙｐｅ、Ｈｌｅｎ、ｈｏｐｓ、ｘｉｄ、ｆｌａｇｓ、ｙｉａｄｄｒ、ｃｈａｄｄｒまでを非マスク領域として使用する。ＯＰに０ｘ０２、ｈｔｙｐｅに０ｘ０１、ｈｌｅｎに０ｘ０６、ｈｏｐｓに０ｘ００、ｘｉｄにはＰＥ２４のＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔで生成するＴｒａｎｓａｃｔｉｏｎＩＤ、ｙｉａｄｄｒにはＣｌｉｅｎｔ ＩＰ Ａｄｄｒｅｓｓなのでレジスタ部２４２のＳＩＰ、ｃｈａｄｄｒにはＣｌｉｅｎｔ ＭＡＣ Ａｄｄｒｅｓｓなのでレジスタ部２４２のＳＨＡを設定する。ＤＨＣＰ ＡＣＫプロトコルのｓｅｃｓ，ｃｉａｄｄｒ，ｇｉａｄｄｒの各領域は、マスク領域に設定する。

また、ＤＨＣＰ ＡＣＫ用ＰＦ２３３ａの第２のパターンフィルタでは、パターンオフセット１として、イーサネット（登録商標）ヘッダ長（宛先ＭＡＣアドレス長、送信元ＭＡＣアドレス、タイプの長さ）、ＩＰヘッダ長、ＵＤＰヘッダ長とＵＤＰデータ領域におけるＤＨＣＰ ＡＣＫパケットの先頭（ＯＰ）からｆｉｌｅ迄の長さを加算した値である２３６を設定する。
非マスク領域として、ＭａｇｉｃＣｏｄｅ（０ｘ６３８２５３６３）、ＤＨＣＰ ＡＣＫ（０ｘ３５０１０５）を設定する。残りの部分はマスク領域とする。
このようにして、第１及び第２のパターンフィルタにそれぞれ分けたパケットデータ領域のパターンフィルタ条件の設定を行う。第１、第２のパターンフィルタ両方の処理で設定したパターンフィルタ条件と受信したパケットデータが一致した場合にのみ、ＤＨＣＫ ＡＣＫプロトコルであることが検出されるようにする。よって、第１及び第２のパターンフィルタそれぞれの処理結果のＡＮＤをとることにより、ＤＨＣＰ ＡＣＫであることを検出し、ＤＨＣＰ ＡＣＫ要求を発生することができる。

次にＤＨＣＫ ＮＡＫパケットのフィルタリングの処理例を説明する。
ＤＨＣＰ ＮＡＫパケットの場合、パケットの長さが２５６バイト以上あるので、ＤＨＣＰ ＮＡＫ用ＰＦ２３３ｎでも、第１及び第２の２つのパターンフィルタを使用する。
第１のパターンフィルタは、上記したＤＨＣＰ ＡＣＫ用ＰＦ２３３ａのパターンフィルタと同じパターンフィルタ条件の設定でよい。
また、ＤＨＣＰ ＮＡＫ用ＰＦ２３３ｎの第２のパターンフィルタでは、パターンオフセット１として、イーサネット（登録商標）ヘッダ長（宛先ＭＡＣアドレス長、送信元ＭＡＣアドレス、タイプの長さ）、ＩＰヘッダ長、ＵＤＰヘッダ長とＵＤＰデータ領域におけるＤＨＣＰ ＡＣＫパケットの先頭（ＯＰ）からｆｉｌｅ迄の長さを加算した値である２３６を設定する。
非マスク領域として、ＭａｇｉｃＣｏｄｅ（０ｘ６３８２５３６３）、ＤＨＣＰ ＮＡＫ（０ｘ３５０１０６）を設定する。残りの部分はマスク領域とする。
このようにして、第１及び第２のパターンフィルタにそれぞれ分けたパケットデータ領域のパターンフィルタ条件の設定を行う。第１、第２のパターンフィルタ両方の処理で設定したパターンフィルタ条件と受信したパケットデータが一致した場合にのみ、ＤＨＣＰ ＮＡＫプロトコルであることが検出されるようにする。よって、第１及び第２のパターンフィルタそれぞれの処理結果のＡＮＤをとることにより、ＤＨＣＰ ＮＡＫであることを検出し、ＤＨＣＰ ＮＡＫ要求を発生することができる。

「省エネモードにおけるＤＨＣＰプロトコルに従う通信動作（実施形態１）」
ここで、省エネルギーモードにおける上記したネットワークパケットエンジン処理部（ＰＥ）２４とパケットフィルタ部（ＰＦ）２３の動作を図２２に示す制御フローに基づいて説明する。
図２２に示す制御フローは、省エネルギーモードの間、ＰＥ２４によって自発的にＤＨＣＰ ＲＥＱＵＥＳＴの定期送信を行い、送信したＤＨＣＰ ＲＥＱＵＥＳＴに対する応答として送信先から送られてくるＤＨＣＰ ＡＣＫ又はＤＨＣＰ ＮＡＫをＰＦ２３によって検出し、検出結果に応じて該送信先との通信条件を保つための処理及び動作を行う。ただ、省エネルギーモードでは、ＣＰＵ２０は動作しないので、省エネルギーモードへの移行に先立ち、ＣＰＵ２０は、ＰＥ２４及びＰＦ２３の動作に必要な設定を行った後、省エネルギーモードへ移行させる。
また、省エネルギーモード時に送信したＤＨＣＰ ＲＥＱＵＥＳＴに対するＤＨＣＰ ＡＣＫ応答がある場合に、省エネルギーモードを維持したまま、ＤＨＣＰプロトコルの通信条件を保持する動作を行う。
さらに、省エネルギーモード時に送信したＤＨＣＰ ＲＥＱＵＥＳＴに対するＤＨＣＰ ＮＡＫ応答或いは時間内に何の応答もない場合に、通常モードに復帰させ、ＣＰＵ２０による通信条件を確認する動作を行う。

よって、省エネルギーモードにおいてＤＨＣＰ ＲＥＱＵＥＳＴパケットを定期送信し、通信条件を保つための処理プログラムを起動すると、ＣＰＵ２０は、省エネルギーモードへの移行に先立って、当該通信動作に必要な設定を行う。
即ち、図２２の処理フローの始めに、ＣＰＵ２０は、ＤＨＣＰプロトコルを定めたＲＦＣ２１３１の規定に従って、ＩＰアドレスのリース期間の半分の値をＰＥ２４の定期送信間隔時間設定部２４９のＴｉｍｅｒ(1)２４９ｔに定期送信間隔時間として設定する（ステップＳ２０１）。
また、同規定に従いＰＥ２４のネットワーク送信制御部２４１のＤＨＣＰ ＲＥＱＵＥＳＴパケットを再送するための繰り返し回数（Ｎ）２４１ｎを４に設定し（ステップＳ２０２）、再送制御部２４１１のＴｉｍｅｒ (2) ２４１１ｔの初期値を４秒に設定する（ステップＳ２０３）。

また、ＰＥ２４の識別データ生成部２４７３に備えたポート番号生成部２４７３ｎにＤＨＣＰ ＲＥＱＵＥＳＴの送信のためにＵＤＰプロトコルのポート番号として、Ｓｏｕｒｅｃｅ Ｐｏｒｔは６８、Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔは６７を設定する（ステップＳ２０４）。
次にＣＰＵ２０は、ＴＣＰ／ＩＰネットワークの次のパケット転送で使用するＩＰの識別子をＰＥ２４の識別子生成部２４７３ｉに設定する（ステップＳ２０５）。
さらにＣＰＵ２０は、次のＤＨＣＰ ＲＥＱＵＥＳＴパケットの転送で使用するトランザクションＩＤをＰＥ２４のＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔに設定する（ステップＳ２０６）。

次いで、この実施形態では、省エネルギーモードにおいてＤＨＣＰ ＲＥＱＵＥＳＴパケットを定期送信するので、ＰＥ２４の識別データ生成部２４７３にＤＨＣＰ ＲＥＱＵＥＳＴパケットを生成するための設定を行う（ステップＳ２０７）。ＤＨＣＰ ＲＥＱＵＥＳＴは、ＵＤＰデータとして図２１に示した延長要求時のＤＨＣＰ ＲＥＱＵＥＳＴ（図１７〜２０による電源ＯＮ時のＤＨＣＰプロトコルの説明、参照）のプログラムに従ってパケットデータを生成する。即ち、Ｃｌｉｅｎｔ ＩＰ Ａｄｄｒｅｓｓには、レジスタ部２４２に記憶されたＳＩＰの値を設定する。Ｃｌｉｅｎｔ ＭＡＣ ＡｄｄｒｅｓｓとＭＡＣ Ａｄｄｒｅｓｓには、レジスタ部２４２のＳＨＡを設定する。ＴｒａｎｓａｃｔｉｏｎＩＤには、ＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔからの値を使用して、ＤＨＣＰパケット生成部２４７６にて、ＤＨＣＰ ＲＥＱＵＥＳＴパケット（図２１）を生成するための設定を行う。

次に、上記ＤＨＣＰ ＲＥＱＵＥＳＴに対する応答として送信先から送られてくるＤＨＣＰ ＡＣＫ及びＤＨＣＰ ＮＡＫをＰＦ２３によって検出するので、ＰＦ２３にＤＨＣＰ ＡＣＫ及びＤＨＣＰ ＮＡＫを検出するための設定を行う（ステップＳ２０８）。ＤＨＣＰ ＡＣＫは、ＵＤＰデータとして図１６に示したＤＨＣＰ ＡＣＫのフィルタリング処理の処理条件を設定する。即ち、ＴｒａｎｓａｃｔｉｏｎＩＤには、ＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔからの値を使用して設定する。この設定に従って、上記でパターンフィルタ２３３について説明したように、第１及び第２のパターンフィルタを使用してＤＨＣＰ ＡＣＫパケットを検出することを可能にする。
また、ＤＨＣＰ ＮＡＫパケットのフィルタリング処理の処理条件についても、ＴｒａｎｓａｃｔｉｏｎＩＤには、ＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔからの値を使用して設定する。この設定に従って、上記でパターンフィルタ２３３について説明したように、第１及び第２のパターンフィルタを使用してＤＨＣＰ ＮＡＫパケットを検出することを可能にする。

この時点で、パワーマネジメント部（ＰＭ）３２によって通常モードにおける所定のタイミングで起動されたＴＩＭＥＲ３３が指定の時間を経過しても、この指定時間内にＰＦ２３で自局宛受信データがなく、かつＣＰＵ２０上で動作しているアプリケーション全てがアイドル状態となっている場合、ＣＰＵ２０は、この状態をＰＭ３２に通知する。この通知を受けてＰＭ３２は、省エネモードの電源供給状態への移行制御を行う（ステップＳ２０９）。
同時に、ＣＰＵ２０は、ＳＥＬ２５の設定をＰＥ２４からの出力を選択する方に切り替えて、ＭＡＣ２２に送り、ＤＨＣＰ ＲＥＱＵＥＳＴパケットをネットワークに送信するための準備をする（ステップＳ２１０）。

省エネモードに移行すると、ＰＥ２４によってＤＨＣＰ ＲＥＱＵＥＳＴパケットを定期送信する動作が始まる。まず、Ｔｉｍｅｒ(1)２４９ｔを起動して（ステップＳ２１１）、起動したＴｉｍｅｒ(1)２４９ｔが切れるのを確認し（ステップＳ２１２）、切れたら（ステップＳ２１２-YES）、ＤＨＣＰ ＲＥＱＵＥＳＴパケットを発行する手順に入る。
ＤＨＣＰ ＲＥＱＵＥＳＴパケットを発行する手順として、まず、ＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔで新たに生成したトランザクションＩＤをＤＨＣＰ ＡＣＫのフィルタリング処理を行うＰＦ２３のパターンフィルタ２３３に設定して、送信するＤＨＣＰ ＲＥＱＵＥＳＴパケットに対するＤＨＣＰ ＡＣＫパケットを検出できるように設定する（ステップＳ２１３）。
また、ネットワーク送信制御部２４１のＴｉｍｅｒ(2)２４１１ｔを起動する（ステップＳ２１４）。これは、Ｔｉｍｅｒ(2)２４１１ｔに設定された所定時間以内に送信するＤＨＣＰ ＲＥＱＵＥＳＴパケットに対するＤＨＣＰ ＡＣＫパケットが受信できたか否かを確認するために必要な動作である。

次に、ネットワーク送信制御部２４１は、ＤＨＣＰ ＲＥＱＵＥＳＴパケットを送信する要求をＩＰパケット生成部２４７に行う（ステップＳ２１５）。
ＤＨＣＰ ＲＥＱＵＥＳＴパケット送信要求を受けたＩＰパケット生成部２４７は、ＤＨＣＰ ＲＥＱＵＥＳＴパケットを生成する一連の処理を行う。即ち、ＤＨＣＰパケット生成部２４７６でＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔによって生成されたトランザクションＩＤを使用して、ＤＨＣＰ ＲＥＱＵＥＳＴ（図２１、参照）に従うＵＤＰデータの部分を生成し（ステップＳ２１６）、また、ＵＤＰヘッダ生成部２４７２でＵＤＰヘッダを生成する（ステップＳ２１７）。なお、ここまでに生成されたＵＤＰデータとＵＤＰヘッダがＩＰのデータになる。
さらに、ＩＰヘッダ生成部２４７１で識別子生成部２４７３ｉより生成した識別子を使用してＩＰヘッダを生成する（ステップＳ２１８）。ここまでに生成されたＩＰデータともとＩＰヘッダがイーサネット（登録商標）フレームのデータ部分となる。
さらに、イーサネット（登録商標）フレームヘッダ生成部２４３では、ここで生成されるイーサネット（登録商標）フレームのヘッダとイーサネット（登録商標）フレームのデータ部分を結合して、イーサネット（登録商標）フレームを構成するＤＨＣＰ ＲＥＱＵＥＳＴパケットを生成する（ステップＳ２１９）。
ＰＥ２４は、生成したＤＨＣＰ ＲＥＱＵＥＳＴパケットをＳＥＬ２５へ出力すると、このパケットは、ＭＡＣ２２及びＰＨＹ１２を介してネットワークに出力される（ステップＳ２２０）。

ＤＨＣＰ ＲＥＱＵＥＳＴパケットを送信した後、ＰＦ２３は、送信したＤＨＣＰ ＲＥＱＵＥＳＴパケットに応答して送信先から送られてくるＤＨＣＰ ＡＣＫパケット及びＤＨＣＰ ＮＡＫパケットを検出する。
手順としては、まずＰＦ２３がＤＨＣＰ ＡＣＫパケットを検出したか否かを確認する（ステップＳ２２１）。ＤＨＣＰ ＡＣＫパケットが検出できない場合に（ステップＳ２２１-NO）、ＰＦ２３がＤＨＣＰ ＮＡＫパケットを検出したか否かを確認する（ステップＳ２２２）。
ＤＨＣＰ ＮＡＫパケットも検出できない場合に（ステップＳ２２２-NO）、Ｔｉｍｅｒ(2)２４１１ｔが切れたか否かを確認する（ステップＳ２２３）。ここで、Ｔｉｍｅｒ(2)２４１１ｔが切れていない場合に（ステップＳ２２３-NO）、ＤＨＣＰ ＡＣＫパケットを検出したか否かを確認するステップＳ２２１に戻す。

ステップＳ２２１でＤＨＣＰ ＡＣＫパケットが検出できた場合には（ステップＳ２２１-YES）、次のＤＨＣＰ ＲＥＱＵＥＳＴパケットの送信周期に移行する。
移行の手続きとして、次のＤＨＣＰ ＲＥＱＵＥＳＴパケットの転送で使用するために、ＰＥ２４のＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔに設定されているトランザクションＩＤを更新する（ステップＳ２３１）。トランザクションＩＤの更新方法は、現在のトランザクションＩＤに１を加えた値を新しいトランザクションＩＤにする方法により実施することができる。
同時に、ＴＣＰ／ＩＰネットワークの次のパケット転送で使用するために、ＰＥ２４の識別子生成部２４７３ｉに設定されているＩＰの識別子を更新する（ステップＳ２３２）。識別子の更新方法は、現在の識別子に１を加えた値を新しい識別子にする方法により実施することができる。
この後、ＤＨＣＰ ＲＥＱＵＥＳＴパケットの次の送信周期を開始すべく、ステップＳ２１１に戻し、Ｔｉｍｅｒ(1)２４９ｔを再起動する。ＤＨＣＰ ＡＣＫパケットが検出されている間、ここまでの手順でＤＨＣＰ ＲＥＱＵＥＳＴパケットの送信が繰り返される。

また、ステップＳ２２２でＤＨＣＰ ＮＡＫパケットが検出できた場合には（ステップＳ２２２-YES）、送信先との間の通信条件に変動が生じたとみなされるので、新たに通信を確立する必要がある。
そこで、ＰＦ２３は、ＤＨＣＰ ＮＡＫを検出したときに、ＤＨＣＰ ＮＡＫ要求をＰＭ３２に通知する。ＤＨＣＰ ＮＡＫ要求を受取るＰＭ３２は、消費電力モードを省エネルギーモードから通常モードに移行する（ステップＳ２４１）。
また、通常モードに移行するときの手続きとして、ＰＥ２４は、識別子生成部２４７３ｉの識別子とＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔのトランザクションＩＤを通常モードへの移行により稼動状態になったＣＰＵ２０に通知し、同様にＰＦ２３は、ＤＨＣＰ ＮＡＫを検出したことを通知する（ステップＳ２４２）。この通知を行った後、この制御フローを終了する。

なお、ＤＨＣＰ ＮＡＫの検出を通知されたＣＰＵ２０は、新たにＤＨＣＰ Ｄｉｓｃｏｖｅｒコマンドをブロードキャストすることにより始まる図１７に示したＤＨＣＰプロトコルに従ったやり取りを行うことで、ＤＨＣＰサーバからＩＰアドレスを設定することができ、ＤＨＣＰサーバとの通信を確立することができる。この際、上記のように、通常モードに復帰させた時に、低消費電力モードで使用していた識別子とトランザクションＩＤをＣＰＵ２０に通知するので、低消費電力モードと通常モードで同じ識別子、トランザクションＩＤを使用しないので、ＴＣＰ／ＩＰプロトコル上問題が発生することなく通信が可能になる。

また、ＤＨＣＰ ＡＣＫパケット及びＤＨＣＰ ＮＡＫパケットのどちらも検出できず、Ｔｉｍｅｒ(2)２４１１ｔが切れた場合に（ステップＳ２２３-YES）、繰返し回数Ｎとして設定した回数にわたりＤＨＣＰ ＲＥＱＵＥＳＴパケットを再送する。
ＤＨＣＰ ＲＥＱＵＥＳＴパケットを再送するときの手続きとして、今回の再送に先立ち繰返し回数Ｎを１減算し、即ち、Ｎ＝Ｎ−１を求め（ステップＳ２２４）、求めたＮが０であるか、即ち、指定回数Ｎ再送を繰り返してＮ＝０となっているか否かをチェックする（ステップＳ２２５）。
ここで、Ｎ＝０でなければ（ステップＳ２２５-NO）、設定した繰返し回数Ｎに達していないので、ＤＨＣＰ ＲＥＱＵＥＳＴパケットを再送する。
ＤＨＣＰ ＲＥＱＵＥＳＴパケットの再送の手順は、ＴＣＰ／ＩＰネットワークの次のパケット転送で使用するために、ＰＥ２４の識別子生成部２４７３ｉに設定されているＩＰの識別子を更新する（ステップＳ２２６）。

次にＴｉｍｅｒ(2)２４１１ｔを初期化して（ステップＳ２２７）、ステップＳ２１４に戻してＴｉｍｅｒ(2)２４１１ｔを再起動し、ＤＨＣＰ ＲＥＱＵＥＳＴパケットの送信及び応答パケットの検出に至る手順を再び行う。
このとき、ステップＳ２２７で行うＴｉｍｅｒ(2)２４１１ｔの初期化は、ＲＦＣ２１３１の規定に従って、前回の２倍の値、即ち、前回の値が４秒ならば、８秒に設定する、という方法により実施することができる。

他方、ステップＳ２２５でＮ＝０となって（ステップＳ２２５-YES）、設定した繰返し回数Ｎに達した場合は、送信先との間の通信条件に何らかの異常が生じたとみなされるので、新たに通信を確立する必要がある。
そこで、ＰＦ２３は、応答パケットの検出ができなかった場合に、これを自局宛要求としてＰＭ３２に通知する。自局宛要求を受取るＰＭ３２は、消費電力モードを省エネルギーモードから通常モードに移行する（ステップＳ２４１）。
また、通常モードに移行するときの手続きとして、ＰＥ２４は、識別子生成部２４７３ｉの識別子とＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔのトランザクションＩＤを通常モードへの移行により稼動状態になったＣＰＵ２０に通知し、同様にＰＦ２３は、応答パケットの検出ができなかったことを通知する（ステップＳ２４２）。この通知を行った後、この制御フローを終了する。

次に、上記した図２２の制御フローの改変例を示す。
上記した図２２の制御フローにおいて、ＤＨＣＰ ＡＣＫパケット及びＤＨＣＰ ＮＡＫパケットのどちらも検出できない状態にあって（ステップ２２２-NO）、Ｔｉｍｅｒ(2)２４１１ｔが切れ（ステップＳ２２３-YES）、さらに設定した繰返し回数Ｎに達していない場合に（ステップＳ２２５-NO）、ＤＨＣＰ ＲＥＱＵＥＳＴパケットを再送する。
このとき、ＤＨＣＰ ＲＥＱＵＥＳＴパケットの再送の手順として、ＴＣＰ／ＩＰネットワークへの再送パケットの転送に使用するために、ＰＥ２４の識別子生成部２４７３ｉに設定されているＩＰの識別子を更新する（ステップＳ２２６）としているが、ＰＥ２４のＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔに設定されているトランザクションＩＤについては、更新していない。

この場合、同一のトランザクションＩＤを用いて先に行ったＤＨＣＰ ＲＥＱＵＥＳＴパケットの送信の際、例えば、送信したパケットが送信先に届かないような通信条件の変更や異常が生じていた場合には、問題なく、次に行う送信に同一のトランザクションＩＤを用いることができる。この方法によると、生成可能なＴｒａｎｓａｃｔｉｏｎＩＤにも限度があるので、資源の節約につながる。
ただ、同一のトランザクションＩＤを用いて先に送信したＤＨＣＰ ＲＥＱＵＥＳＴパケットパケットが送信先に届いて、送信先では正常に処理された場合、次に行う再送に同一のトランザクションＩＤを用いると、送信先では、このトランザクションＩＤは、無視されてしまうので、通信が維持できなくなる。

そこで、この改変例では、ＤＨＣＰ ＲＥＱＵＥＳＴパケットの再送の手順に、次のＤＨＣＰ ＲＥＱＵＥＳＴパケットの再送で使用するために、ＰＥ２４のＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔに設定されているトランザクションＩＤを更新する手順を用意する。
図２３は、この改変例の制御フロー図である。
図２３に示す制御フローと図２２に示した制御フローの相違は、ＤＨＣＰ ＲＥＱＵＥＳＴパケットの再送動作に移行する際の手順において、ＰＥ２４のＴｒａｎｓａｃｔｉｏｎＩＤ生成部２４７３ｔに設定されているトランザクションＩＤを更新するステップＳ３２７を付加した点にある。つまり、ステップＳ３２７は、ＤＨＣＰ ＡＣＫパケット及びＤＨＣＰ ＮＡＫパケットのどちらも検出できない状態にあって（ステップ３２２-NO）、Ｔｉｍｅｒ(2)２４１１ｔが切れ（ステップＳ３２３-YES）、さらに設定した繰返し回数Ｎに達していない場合に（ステップＳ３２５-NO）、ＤＨＣＰ ＲＥＱＵＥＳＴパケットを再送する手順に移行し、その移行手順において、再送するＤＨＣＰ ＲＥＱＵＥＳＴパケットに埋め込むトランザクションＩＤを更新する。

ステップＳ３２７を付加したことにより、ＤＨＣＰ ＲＥＱＵＥＳＴパケットの再送動作に移行する際に、低消費電力モードを継続させたまま、ＤＨＣＰのトランザクションＩＤを更新するので、低消費電力でＤＨＣＰプロトコルの通信条件を保つことができる。
なお、図２３に示す制御フローは、上記ステップＳ３２７を付加した点以外に図２２に示した制御フローの各ステップと変わりがない。よって、先に説明した図２２の制御フローの説明を参照することとし、ここでは記載を省略する。

上記図２２又は図２３の制御フローによる動作によると、ＣＰＵ２０を使用しない省エネルギーモードにおいて、送信データに識別データを付加してＩＰパケットデータを送信し、低消費電力モードのまま送信したパケットに対する応答パケットを受信できるので、消費電力を削減でき、また、上記と同様に省エネルギーモードで送信したパケットに対する応答パケットが受信できない場合に、パケットデータを省エネルギーモードのまま再送できるので、消費電力を削減できる。
また、上記ようにパケットデータを再送するとき或いは所定のパケット（ＤＨＣＰ ＡＣＫ）を受信したときに識別データを更新するので、低消費電力を維持したまま、ＴＣＰ／ＩＰの通信が可能となる。
また、上記の低消費電力を維持した交信動作をＤＨＣＰプロトコル通信で実現できる。
また、ＤＨＣＰプロトコルのＤＨＣＰ ＲＥＱＵＥＳＴパケット及びＤＨＣＰ ＡＣＫパケットの通信ができるので、低消費電力を維持したまま、ＩＰアドレスの延長要求が可能となる。

また、低消費電力を維持したまま、ＤＨＣＰのトランザクションＩＤを更新するので、低消費電力でＤＨＣＰプロトコルの通信条件を保つことができる。
また、低消費電力モードに移行する際にＣＰＵ２０が通常モードの識別データを通知するので、通常モード時と低消費電力モード時に同じ識別データ使用しないようにすることで、低消費電力中もＴＣＰ／ＩＰプロトコル通信が可能となる。
また、低消費電力モードから通常モードに移行する時、低消費電力モードで使用していた識別子をＣＰＵ２０に通知するので、低消費電力モードから通常モードに移行してもＴＣＰ／ＩＰプロトコル通信が正常に動作する。
また、所定のパケット（ＤＨＣＰ ＡＣＫ）が受信できない場合は、消費電力モードを通常モードに移行して、所定のパケットが受信できないことをＣＰＵ２０に通知できるので、ＤＨＣＰプロトコルのやり取りをＤＨＣＰ ＤＩＳＣＯＶＥＲから始めることが可能になり、ＤＨＣＰサーバからＩＰアドレスを受け取ることができる。
また、プリンタ等の画像形成装置においても、低消費電力を維持したままＤＨＣＰプロトコル通信が行え、低消費電力のまま、ＩＰアドレス使用の延長が可能となる。

「パケットフィルタ部：ＰＦ（実施形態２）」
上記実施形態１では、自発的にＤＨＣＰプロトコルに従い、ＤＨＣＰ ＲＥＱＵＥＳＴをネットワークへ送信することが可能な形態のＰＥ２４及びＤＨＣＰ ＲＥＱＵＥＳＴに対する応答パケットを検出するＰＦ２３について実施形態を示した。次に示す実施形態は、さらに、ＰＦ２３が省エネルギーモードにおいて所定フレーム構造のパケットを受取ることができ、受取ったパケットが自局宛のパケットの場合には、ＰＥ２４で所定のパケットのリクエストに応えるために予め設定しておいたデータを送信元が受取ることができる所定フレーム構造のパケットとして生成し、応答することを可能にする。
なお、ＰＦ２３で選択されたパケットを受取るＰＥ２４は、省エネモードの電源供給状態を維持したまま、自局宛のリクエストパケットに応答するパケットを処理する。また、ＰＥ２４で応答できないパケットの処理は、省エネモードから、ＣＰＵ２０が動作する電源供給モードに移行させた状態で行われる。

図２４は、図１に示すＰＦ２３の内部構成例を示すブロック図である。なお、図２４に示すＰＦ２３は、図１４に示したＰＦ２３と共通の要素には同じ符号を付すが、図１４に示した構成の一部を省略している。
ＰＦ２３は、アドレスフィルタ２３１、パターンフィルタ２３３、バッファ２３５を構成要素とする。
アドレスフィルタ２３１には、ユニキャストアドレスとマルチキャストアドレスが登録可能である。また、このプリンタ機器自身や機器内のアクセス可能なデバイス（例えば、プロッタ２など）のアドレスが設定可能である。
アドレスフィルタ２３１は、ＭＡＣ２２から入力したパケットのタイプを参照し、そのタイプからパケットの種類を判断し、設定されたアドレスをチェックすることで、アクセス可能な機器やデバイスに対するパケットのみを通過させ、パターンフィルタ２３３へ送り、その他のパケットは破棄する選別を行う。
また、ブロードキャストパケットは、アドレスフィルタ２３１の設定に関係無く、通過させてパターンフィルタ２３３へ送る。
自局宛アドレスのパケットとは、アドレスフィルタ２３１を通過させるパケットである。従って、自局宛アドレスには、登録したユニキャストアドレス（機器自身や機器内のデバイスのＩＰアドレス） 登録したマルチキャストアドレス 及びブロードキャストアドレスが含まれる。

パターンフィルタ２３３は、入力されるイーサネット（登録商標）フレームのパケットに対し、マスク領域と非マスク領域を設定して、非マスク領域のデータの一致を条件にパケットを通過させる。つまり、マスク領域は、そのデータ値に関係なく一致条件となるので、非マスク領域に設定されたデータによって、通過させるパケットが決まる。
ここでは、パターンフィルタ２３３において、非マスク領域に設定するデータは、バイト単位で設定できるようにし、入力パケットをこの設定データと比較し、一致した場合にのみ、当該パケットを通過させる。

パターンフィルタ２３３は、マスク領域のデータ長と非マスク領域のデータ長の合計をパターンフィルタ長として、フィルタリングの対象領域を定める。このパターンフィルタ長としては、例えば６４バイトを採用する。
また、所定長のパターンフィルタを所望の対象領域に設定するために、このパターンフィルタ２３３には、パターンオフセットを設定できる。このパターンオフセットは、パターンオフセット１とパターンオフセット２のオフセット値で管理する。
パターンオフセット１は、イーサネット（登録商標）フレームの開始からのオフセット長である。このパターンフィルタ２３３によるフィルタリングをイーサネット（登録商標）フレームのタイプ（後記する図１３、参照）から開始する場合は、パターンオフセット１の長さは、宛先ＭＡＣアドレス長と送信元ＭＡＣアドレス長を加算した値になる。
また、パターンオフセット２は、パターンフィルタ２３１の先頭からのオフセットを示す。パターンオフセットからの１バイトは、ビットマスク値によって、ビット毎にフィルタリングが可能である。ビットマスク値で「１」を設定したビットは、マスク領域である。

この実施形態のプリンタを対象にした場合に、印刷要求に応じるためには、省エネモードでは対応できないので、省エネモードにおいて印刷要求のリクエストを受信した場合には、通常モードに復帰させなければならない。従って、ＰＥ２４で応答可能なリクエストは、非印刷要求になる。
パターンフィルタ２３３では、アドレスフィルタ２３１から受信したパケットが非印刷要求のパケットか印刷要求のパケットかを判断し、非印刷要求のパケットの場合はＰＭ３２にその旨を通知し、印刷要求のパケットの場合はＰＭ３２にその旨を通知し、上述のフィルタリング後のパケットをバッファ２３５へ出力する。また、アドレスフィルタ２３１から受信したパケットがＡＲＰリクエストパケットの場合は、ＳＥＬ２５にＰＥ＿ＯＮ信号を送り、ＰＥ２４へＡＲＰリクエストパケットを出力する。
以下には、非印刷要求のうちＰＥ２４で応答可能なリクエストを設定したパケットを通過させるフィルタリング処理について、異なるパケットの種類を例示し、説明する。

“ＴＣＰパケット”
図２５は、ＰＦ２３におけるＴＣＰパケットのフィルタリング処理を説明する図である。
図２５（ａ）はＴＣＰパケットのネットワークフレームのフォーマット（図７、参照）を示し、図２５（ｂ）には、ＰＦ２３のパターンフィルタ２３３に処理条件として設定する、マスク領域と非マスク領域及び非マスク領域の処理対象として参照するデータを示す。
ＴＣＰパケットのフィルタリング処理条件は、図２５（ｂ）示すように、ＰＦ２３のパターンフィルタ２３３には、パターンオフセット１として、宛先ＭＡＣアドレス長と送信元ＭＡＣアドレス長を加算した値を設定し、ＴＣＰパケットの先頭の１６ビットのタイプを参照するので、ここを非マスク領域として設定する。ＴＣＰパケットの場合、タイプには、パターンフィルタ２３３の先頭の１６ビットにＩＰプロトコルを示す「０ｘ０８００」が設定されている。

さらに、ＴＣＰパケットのＩＰヘッダとの比較値を設定する。ＩＰヘッダのバージョン（Ｖｅｒ）にはＩＰｖ４の「４」を、ヘッダ長には「５」を、プロトコル番号にはＴＣＰプロトコル番号を、宛先ＩＰアドレスにはこのプリンタのＩＰアドレス（自局アドレス）をそれぞれ設定し、その他のＩＰヘッダはマスク領域（図中に斜線を施した部分）として設定する。
さらに、ＴＣＰヘッダとの比較値を設定し、そのＴＣＰヘッダの宛先ポート番号に使用するアプリケーションのポート番号を設定し、ＴＣＰヘッダのコードビットとの比較値を設定する。

次に、パターンフィルタ２３３によってコネクション確立要求であるＳＹＮビットが「１」のＴＣＰパケットを通過させるための設定を行う。
ＴＣＰパケットでは、コードビットはＴＣＰヘッダの先頭から１４バイト目にあるので、図２５（ｂ）に示すように、パターンオフセット２を１３バイトに設定する。
パターンフィルタ２３３の１４バイト目に「０ｘ０２」を設定すると、図２５（ｃ）に示すＴＣＰパケットのコードビットのＳＹＮ（接続要求）と比較することができる。
さらに、ビットマスク値を「０ｘＣ２」に設定すると、コードビットのＳＹＮが１のＴＣＰパケットを通過させることができる。

その他のＴＣＰパケットのヘッダ領域に対応する部分はマスク領域（図中に斜線を施した部分）とする。
さらに、図２５（ｂ）に示す、ビットマスク後の部分もマスク領域（図中に斜線を施した部分）に設定する。
なお、ＴＣＰヘッダの宛先ポート番号を、ｈｔｔｐ（Hypertext Transfer Protocol）のアプリケーションの場合には、８０に設定し、印刷プロトコルであるＬＰＤの場合には、５１５に設定する。
ＳＹＮ以外のビット、例えば、ＡＣＫをフィルタリングする場合は、ビットマスク値を「０ｘＤ０」に変更すればよい。
このようにして、パターンフィルタ２３３は、上記したコードビットのＳＹＮ（接続要求）を通過条件とする設定のように、非印刷要求のうちＰＥ２４で応答可能なリクエストのパケットをフィルタリング処理できる設定とし、設定条件に合うパケットを通過させる場合、ＳＥＬ２５へのＰＥ＿ＯＮ信号をアクティブにするとともに、通過させるパケットをＰＥ２４に出力する。
なお、パターンフィルタ２３３に印刷プロトコルであるＬＰＤアプリケーションの宛先ポート番号「５１５」を設定すると、それに対応するＴＣＰを受信した場合、印刷要求信号をアクティブにして、ＰＭ３２に通知する。

“ＵＤＰパケット”
図２６は、ＰＦ２３におけるＵＤＰパケットのフィルタリング処理を説明する図である。
図２６（ａ）はＵＤＰパケットのネットワークフレームのフォーマット（図４、参照）を示し、図２６（ｂ）には、ＰＦ２３のパターンフィルタ２３３に処理条件として設定する、マスク領域と非マスク領域及び非マスク領域の処理対象として参照するデータを示す。
ＵＤＰパケットのフィルタリング処理条件は、図２６（ｂ）示すように、ＰＦ２３のパターンフィルタ２３３には、パターンオフセット１として、宛先ＭＡＣアドレス長と送信元ＭＡＣアドレス長を加算した値を設定し、ＵＤＰパケットの先頭の１６ビットのタイプを参照するので、ここを非マスク領域として設定する。ＵＤＰパケットの場合、タイプには、パターンフィルタ２３３の先頭の１６ビットにＩＰプロトコルを示す「０ｘ０８００」が設定されている。

さらに、ＴＣＰパケットのＩＰヘッダとの比較値を設定する。ＩＰヘッダのバージョン（Ｖｅｒ）にはＩＰｖ４の４を、ヘッダ長には「５」を、プロトコル番号にはＵＤＰプロトコル番号を、宛先ＩＰアドレスにはこのプリンタのＩＰアドレス（自局アドレス）をそれぞれ設定し、その他のＩＰヘッダはマスク領域（図中に斜線を施した部分）として設定する。
さらに、ＵＤＰヘッダとの比較値を設定し、そのＵＤＰヘッダの宛先ポート番号に使用するアプリケーションのポート番号を設定し、その他のＵＤＰのヘッダ領域はマスク領域（図中に斜線を施した部分）とする。

さらに、ＵＤＰヘッダ領域後の部分もマスク領域（図中に斜線を施した部分）に設定する。
機器の状態を外部に知らせるために公開されるＭＩＢ（Management Information Base）情報をアクセスしに来たときに、応答するためには、ＳＮＭＰ（Simple Network Management Protocol）プロトコルやｈｔｔｐ（Hypertext Transfer Protocol）を使用する必要がある（後述するＰＥ２４の説明、参照）。ＳＮＭＰやｈｔｔｐは、ＵＤＰを利用することができる。ＵＤＰのパターンフィルタ２３３における上記ＵＤＰヘッダの宛先ポート番号を入れる領域に、ＭＩＢ情報にアクセスするアプリケーションのポート番号を設定することで、このリクエストのパケットをフィルタリングすることが可能になる。
このようにして、パターンフィルタ２３３は、上記したＭＩＢ情報にアクセスするアプリケーションのポート番号を通過条件とする設定のように、非印刷要求のうちＰＥ２４で応答可能なリクエストのパケットをフィルタリング処理できる設定とし、設定条件に合うパケットを通過させる場合、ＳＥＬ２５へのＰＥ＿ＯＮ信号をアクティブにするとともに、通過させるパケットをＰＥ２４に出力する。

“ＡＲＰパケット”
図２７は、ＰＦ２３におけるＡＲＰパケットのフィルタリング処理を説明する図である。
図２７（ａ）はＡＲＰパケットのネットワークフレームのフォーマット（図１１、参照）を示し、図２７（ｂ）には、ＰＦ２３のパターンフィルタ２３３に処理条件として設定する、マスク領域と非マスク領域及び非マスク領域の処理対象として参照するデータを示す。
ＡＲＰパケットのフィルタリング処理条件は、図２７（ｂ）示すように、ＰＦ２３のパターンフィルタ２３３には、パターンオフセット１として、「０」を設定して、ＡＲＰパケットのフレームの開始から比較できるようにする。ＡＲＰパケットのイーサネット（登録商標）ヘッダの先頭の宛先ＭＡＣアドレスを参照するので、ここを非マスク領域として設定する。ＡＲＰプロトコルは、ブロードキャストなので、パターンフィルタ２３３のＡＲＰパケットの宛先ＭＡＣアドレスにあたる全てのビットに「１」を設定する。
さらに、イーサネット（登録商標）ヘッダの送信元ＭＡＣアドレスは、マスク領域（図中に斜線を施した部分）として設定する。

イーサネット（登録商標）ヘッダのタイプには、ＡＲＰプロトコルを示す「０ｘ０８０６」が設定されているので、パターンフィルタ２３３にＡＲＰパケットのタイプとの比較値を設定する。
その後に、ハードウェアタイプを「１」、プロトコルフィールドを「ＩＰ」、ＭＡＣアドレス長を「６」、プロトコルアドレス長はＩＰｖ４なので「４」、オペレーションコードにはＡＲＰ要求を示す「１」を設定する。
送信元ハードウェアアドレス（ＳＨＡ）、送信元ＩＰアドレス（ＳＩＰ）、宛先ハードウェアアドレス領域（ＤＨＡ）には、それぞれマスク領域（図中に斜線を施した部分）を設定する。
宛先ＩＰアドレス（ＤＩＰ）にはこのプリンタのＩＰアドレスを設定し、残りの部分はマスク領域（図中に斜線を施した部分）とする。

パターンフィルタ２３３は、上記の設定で受信したパケットをフィルタリング処理することで、ブロードキャストされるＡＲＰリクエストパケットを通過させることができる。
パターンフィルタ２３３に、非印刷プロトコルであるｈｔｔｐアプリケーションの宛先ポート番号「８０」、ＳＮＭＰプロトコルを設定すると、それに対応するＡＲＰリクエストパケットを受信した場合、非印刷要求信号をアクティブにして、ＰＭ３２に通知する。
パターンフィルタ４１にＡＲＰパケットの設定をすると、ＡＲＰリクエストパケットの受信時にＳＥＬ２５へのＰＥ＿ＯＮ信号をアクティブにするとともに、通過させるパケットをＰＥ２４に出力する。

“ＩＣＭＰパケット”
図２８は、ＰＦ２３におけるＩＣＭＰパケットのフィルタリング処理を説明する図である。
図２８（ａ）はＩＣＭＰパケットのネットワークフレームのフォーマット（図９、参照）を示し、図２８（ｂ），（ｄ）には、それぞれＩＣＭＰパケット内の各フィールドのデータ内容を示し、図２８（ｄ）には、ＰＦ２３のパターンフィルタ２３３に処理条件として設定する、マスク領域と非マスク領域及び非マスク領域の処理対象として参照するデータを示す。なお、図２８（ｂ），（ｄ）は、ＩＣＭＰエコーリクエストパケットのデータを示している。
ＩＣＭＰパケットのフィルタリング処理条件は、図２８（ｄ）示すように、ＰＦ２３のパターンフィルタ２３３には、パターンオフセット１として、宛先ＭＡＣアドレス長と送信元ＭＡＣアドレス長を加算した値を設定し、ＴＣＰパケットの先頭の１６ビットのタイプを参照するので、ここを非マスク領域として設定する。ＩＣＭＰパケットの場合、タイプには、パターンフィルタ２３３の先頭の１６ビットにＩＰプロトコルを示す「０ｘ０８００」が設定されている。

また、図２８（ｂ）に示したイーサネット（登録商標）フレームのＩＰヘッダのバージョン（Ｖｅｒ）のフィールドに格納されたＩＰｖ４を示す「４」と、上記ＩＰヘッダのヘッダ長のフィールドに格納された「５」を設定する。
さらに、プロトコル番号にはＩＣＭＰプロトコル番号を、宛先ＩＰアドレスには自局アドレスとしてこのプリンタのＩＰアドレスを設定し、ＩＣＭＰのタイプにはＩＣＭＰエコーリクエストパケットを示す「８」を設定し、その他のＩＰヘッダはマスク領域（図中に斜線を施した部分）として設定する。
ただし、ＩＰヘッダのパケット長の比較値ｌｅｎを９２バイト以下に設定する。この９２バイトは、ＩＣＭＰデータのサイズが６４バイト、ＩＰヘッダ長が２０バイトの場合の設定である。

以上のようなパターンフィルタ２３３の設定によって、ネットワークからのパケットデータをフィルタリング処理する際に、設定した処理条件に一致する６４バイト以下のＩＣＭＰエコーリクエストパケットであることが認識できた場合に、パターンフィルタ２３３は、ＳＥＬ２５へのＰＥ＿ＯＮ信号をアクティブにするとともに、通過させるパケットをＰＥ２４に出力する。ＰＥ２４のＰＩＮＧ応答については、後記で詳述する。
なお、ＰＦ２３は、ＩＣＭＰパケットデータのサイズが６４バイトを超える場合は、非印刷要求パケットを受信したことをＰＭ３２に通知して、バッファ４２に蓄積する。この場合はコントローラモードに遷移して処理を行うことになる。また、ＩＣＭＰパケットデータのサイズは通常６４バイトなので、ハードウェアを簡略化するために、ＩＣＭＰパケットデータが６４の時のみＰＩＮＧパケットであることを認識するように回路設計をしても、実用上問題がない。

宛先ＩＰアドレスがアドレスフィルタに登録されたマルチキャストアドレスの場合について説明する。
登録されたマルチキャストアドレスの場合、登録された個数分のフィルタを用意して、宛先ＩＰアドレスに登録したマルチキャストアドレスを設定すればよい。また、宛先ＩＰアドレスの設定以外は上記の設定と同じである。

「パケットエンジン処理部：ＰＥ（実施形態２）」
図１に示すＰＥ２４のもう１つの実施形態について説明する。
以下には、プリンタがネットワークから受信したパケットのうち、上記した実施形態２のＰＦ２３で所定の設定条件に従い通過させた、ＭＩＢ情報にアクセスするためのＵＤＰパケット、ＡＲＰパケット等へ応答するパケットを生成する手段、及び後述するＳＳＤＰ（Simple Service Discovery Protocol）のアドバタイズとしてＵＤＰパケットを生成する手段としての機能を持つＰＥ２４の構成及び動作を説明する。
本実施形態のＰＥ２４は、省エネモードの電源供給状態を維持したまま、リクエストに応答するリプライパケットを生成する処理を行う。また、ＵＤＰパケットを生成する処理を行う。なお、ＰＥ２４で応答できないパケットは、省エネモードから、ＣＰＵ２０が動作する電源供給モードに移行させた状態で処理される。

図２９は、図１に示すＰＥ２４の内部構成例を示すブロック図である。なお、図２９に示すＰＥ２４は、図１３に示したＰＥ２４と共通の要素には同じ符号を付すが、図１３に示した構成の一部を省略している。
ＰＥ２４は、ネットワーク送信制御部２４１、レジスタ部２４２、Ｅｔｈｅｒ（イーサ）フレームヘッダ生成部２４３、ＡＲＰリプライパケット生成部２４４、ＰＩＮＧリプライパケット生成部２４５、ＩＰパケット生成部２４７、ＡＲＰリプライパケット生成部２４４の出力とＰＩＮＧリプライパケット生成部２４５の出力とＩＰパケット生成部２４７の出力を選択する第１セレクタ２４６からなる。
ネットワーク送信制御部２４１は、レジスタ部２４２、Ｅｔｈｅｒフレームヘッダ生成部２４３、ＡＲＰリプライパケット生成部２４４、ＰＩＮＧリプライパケット生成部２４５、ＩＰパケット生成部２４７、ＡＲＰリプライパケット生成部２４４の出力とＰＩＮＧリプライパケット生成部２４５の出力とＩＰパケット生成部２４７の出力を選択する第１セレクタ２４６を制御する。

以下には、ＰＦ２３で選択される非印刷要求のうちＰＥ２４で応答可能なリクエストとして送られてくるパケットに応じる処理を行うためにＰＥ２４が備える、ＡＲＰリプライパケット生成部２４４、ＰＩＮＧリプライパケット生成部２４５及びＩＰパケット生成部２４７の構成と応答動作を順に説明する。
“ＡＲＰ応答”
図２９のＡＲＰリプライパケット生成部２４４で行うＡＲＰ応答について説明する。
ＡＲＰとは、ＩＰアドレスにより特定される通信相手のＭＡＣアドレスを知るためのプロトコルであり、調査対象の装置に対してＡＲＰリクエストを送って、その装置からＡＲＰリプライを受取る。ＰＥ２４は、ＰＦ２３からフィルタリングされたＡＲＰリクエストパケットを受取り、ＡＲＰ応答としてネットワークに送信するＡＲＰリプライパケットを生成する。
ＡＲＰ応答時には、第１セレクタ２４６では、ＡＲＰリプライパケット生成部２４４の出力を選択する。
図３０にＰＥ２４におけるＡＲＰリプライパケット生成部２４４を示す。ＡＲＰリプライパケット生成部２４４は、パケット解析部２４４１、パケット生成部２４４２、レジスタ部２４２からなる。なお、レジスタ部２４２は、後述するＰＩＮＧリプライパケット生成部２４５と共通に使用される要素である。
パケット解析部２４４１は、ＰＦ２３からのＡＲＰリクエストパケットを入力する。
ＡＲＰリクエストパケットは、図３０のパケット解析部２４４１ブロック内にフレームを示すように、宛先ＭＡＣアドレスフィールド、ＳＨＡ（要求元ハードウェアアドレス）、ＡＲＰ、ハードウェアタイプフィールド、プロトコルフィールド、ＭＡＣアドレス長フィールド、プロトコルアドレス長フィールド、ＡＲＰリクエストフィールド、ＳＨＡ、ＳＩＰ（要求元ＩＰアドレス）、ＤＨＡ（宛先ハードウェアアドレス）、ＤＩＰ（宛先ＩＰアドレス）からなる。

パケット解析部２４４１は、ＡＲＰリクエストパケット内のＳＨＡフィールド、ＳＩＰフィールドの各値を解析して、レジスタ部２４２のＤＨＡにＡＲＰリクエストパケットのＳＨＡを、ＤＩＰにＡＲＰリクエストパケットのＳＩＰをそれぞれ設定する。
また、レジスタ部２４２のＳＨＡに、このプリンタのハードウェアアドレスを設定し、ＳＩＰに、このプリンタのＩＰアドレスを設定しておく。このレジスタ部２４２のＳＨＡ及びＳＩＰの設定は、ＣＰＵ２０の動作によって行われ、省エネモード中はできないので、予めＣＰＵ２０が動作しているときに行っておく。

パケット生成部２４４２では、イーサネット（登録商標）ヘッダ２４４２ｅとアープリプライ（ARPReply）パケット２４４２ａからなるＡＲＰレスポンスパケットを生成する。
イーサネット（登録商標）ヘッダ２４４２ｅは、ＤＨＡ、ＳＨＡ、タイプの各フィールドから構成され、レジスタ部２４２のＤＨＡから読み出した値をＤＨＡへ、レジスタ部２４２のＳＨＡから読み出した値をＳＨＡへそれぞれ設定する。また、タイプフィールドにはＡＲＰパケットを示す「０ｘ０８０６」を設定する。
さらに、イーサフレームのデータ部には、アープリプライパケット２４４２ａを設定する。

アープリプライパケット２４４２ａのハードウェアタイプフィールドには、イーサネット（登録商標）の場合は「１」を設定する。同プロトコルフィールドには、ＴＣＰ／ＩＰを使用するので「０ｘ０８０６」を設定し、ＭＡＣアドレス長フィールドには、「６」を設定し、プロトコルアドレス長フィールドには、ＩＰｖ４を使用するので「４」を設定する。
また、ＯＰフィールドには、ＡＲＰリプライを示す２を設定し、ＳＨＡフィールドには、レジスタ部２４２のＳＨＡの値を、ＳＩＰフィールドには、レジスタ部２４２のＳＩＰの値を、ＤＨＡフィールドには、レジスタ部２４２のＤＨＡの値を、ＤＩＰフィールドには、レジスタ部２４２のＤＩＰの値をそれぞれ設定する。

イーサネット（登録商標）フレームのＦＣＳは、ＭＡＣ２２で自動生成されるので、パケット生成部２４４２では生成する必要はない。
パケット生成部２４４２で生成されたＡＲＰレスポンスパケットをネットワークへ送信するには、ＰＦ２３から出力されるＰＥ＿ＯＮ信号がアクティブになると、ＳＥＬ２５がＰＥ２４から出力されたＡＲＰレスポンスパケットをＭＡＣ２２へ送信する。なお、ＰＥ＿ＯＮ信号が非アクティブ時は、内部バス３４からのデータがＭＡＣ２２に入力される。
以上のように、パケット生成部２４４２では、ＡＲＰリクエストの送信元が受取ることができるフレーム構造のパケットとしてＡＲＰレスポンスパケットが、主制御部のＣＰＵ２０、メモリ１１を使用せずに、生成される。生成されたＡＲＰレスポンスパケットは、ＳＥＬ２５、ＭＡＣ２２、ＰＨＹ１２を経由してネットワークへ送信される。

“ＰＩＮＧ応答”
図２９のＰＩＮＧリプライパケット生成部２４５で行うＰＩＮＧ応答について説明する。
ＰＩＮＧとは、ＩＣＭＰプロトコルによって調査対象の装置に対してＩＣＭＰエコーリクエストパケットを送って、その装置からの返信の有無や応答時間などのデータに基づいてネットワークを診断するプログラムである。ＰＥ２４は、ＰＦ２３からフィルタリングされたＩＣＭＰエコーリクエストパケットを受取り、ＰＩＮＧ応答としてネットワークに送信するＰＩＮＧリプライパケットを生成する。
ＰＩＮＧ応答時には、第１セレクタ２４６では、ＰＩＮＧリプライパケット生成部２４５の出力を選択する。
図３１にＰＥ２４におけるＰＩＮＧリプライパケット生成部２４５を示す。ＰＩＮＧリプライパケット生成部２４５は、パケット解析部２４５１、パケット生成部２４５２、レジスタ部２４２からなる。なお、レジスタ部２４２は、前述のＡＲＰリプライパケット生成部２４４と共通に使用される要素である。

パケット解析部２４５１には、ＰＦ２３からのＩＣＭＰエコーリクエストパケットが入力される。
ＩＣＭＰエコーリクエストパケットは、図３１のパケット解析部２４５１ブロック内にフレームを示すように、宛先ＭＡＣアドレス、ＳＨＡ（要求元ハードウェアアドレス）、プロトコルタイプ、バージョン・ヘッダ長、サービスタイプ、パケット長、識別子、フラグ・フラグメントオフセット、ＴＴＬ（生存期間）、プロトコル番号、ヘッダチェックサム、ＳＩＰ（要求元ＩＰアドレス）、宛先ＩＰアドレス（ＤＩＰ）、メッセージタイプ、コードフィールド、チェックサム、識別子、シーケンス番号、ＩＣＭＰデータの各フィールドからなる。

パケット解析部２４５１は、ＩＣＭＰエコーリクエストパケット内のイーサネット（登録商標）ヘッダのＳＨＡと、ＩＰヘッダのＳＩＰの各値を解析して、レジスタ部２４２の宛先ハードウェアアドレス（ＤＨＡ）にＳＨＡを、宛先ＩＰアドレス（ＤＩＰ）にＳＩＰをそれぞれ設定する。
ＩＰデータのメッセージタイプには、ＩＣＭＰエコーリクエストパケットを示す「８」が格納されている。
また、レジスタ部２４２のＳＨＡに、このプリンタのハードウェアアドレスを設定し、ＳＩＰに、このプリンタのＩＰアドレスを設定しておく。このレジスタ部２４２のＳＨＡ及びＳＩＰの設定は、ＣＰＵ２０の動作によって行われ、省エネモード中はできないので、予めＣＰＵ２０が動作しているときに行っておく。

パケット生成部２４５２では、ＩＣＭＰエコーリプライパケットを作成する。まず、イーサネット（登録商標）ヘッダ２４５２ｅの作成では、レジスタ部２４２のＤＨＡに設定した要求元ハードウェアアドレス（ＳＨＡ）と、ＳＨＡに設定したハードウェアアドレスを、パケット生成部２４５２のＩＣＭＰエコーリプライパケットのイーサネット（登録商標）ヘッダ２４５２ｅのＤＨＡのフィールドと、ＳＨＡのフィールドにそれぞれ設定する。
また、ＩＣＭＰエコーリクエストパケットのプロトコルタイプフィールドのＩＰを示す０ｘ８００を、パケット生成部２４５２のＩＣＭＰエコーリプライパケットのイーサネット（登録商標）ヘッダ２４５２ｅのプロトコルタイプフィールドにコピーする。

次に、パケット生成部２４５２のＩＣＭＰエコーリプライパケットのＩＰヘッダ２４５２ｐを作成する。まず、パケット解析部２４５１のＩＣＭＰエコーリクエストパケットのバージョン・ヘッダ長、サービスタイプ、パケット長、識別子、フラグ・フラグメントオフセット、プロトコル番号のフィールドの各データを、パケット生成部２４５２のＩＣＭＰエコーリプライパケットの対応するフィールドにそれぞれコピーする。また、ＴＴＬフィールドには、２５５を設定する。さらに、上記コピー後にチェックサムを計算し、ＩＣＭＰエコーリプライパケットのチェックサムフィールドに設定する。
上記チェックサムの計算は、例えば、オーム社発行の書籍「マスタリングＴＣＰ／ＩＰ 応用編」で記載されている１の補数演算方法を使用することにより実施しうる。
さらに、ＩＣＭＰエコーリプライパケットのＩＰヘッダ２４５２ｐのＳＩＰフィールドには、レジスタ部２４２のＳＩＰのデータを設定し、同ＤＩＰフィールドには、レジスタ部２４２のＤＩＰのデータを設定する。

次に、パケット生成部２４５２のＩＣＭＰエコーリプライパケットのＩＰデータを作成する。まず、ＩＣＭＰヘッダ２４５２ｉのメッセージタイプフィールドには、ＩＣＭＰエコーリプライパケットを示す「０」を設定する。
また、ＩＣＭＰヘッダ２４５２ｉのコードフィールドは「０」を設定し、ＩＰデータのチェックサムを計算して、チェックサム（Ｃｈｅｃｋ ＳＵＭ）フィールドに設定する。
上記チェックサムの計算は公知技術（例えば、オーム社発行の書籍「マスタリングＴＣＰ／ＩＰ 応用編」で記載されている１の補数演算方法）を使用すればよい。

さらに、パケット解析部２４５１のＩＣＭＰエコーリクエストパケットのＩＰデータ識別子フィールドのデータを、パケット生成部２４５２のＩＣＭＰエコーリプライパケットのＩＣＭＰヘッダ２４５２ｉの識別子フィールドにコピーし、同様にパケット解析部２４５１からパケット生成部２４５２にシーケンス番号フィールドのデータをコピーする。
以上のように、パケット生成部２４５２では、ＩＣＭＰエコーリクエストの送信元が受取ることができるフレーム構造のパケットとしてＩＣＭＰエコーリプライパケットが、主制御部のＣＰＵ２０、メモリ１１を使用せずに、生成される。生成されたＩＣＭＰエコーリプライパケットは、ＳＥＬ２５、ＭＡＣ２２、ＰＨＹ１２を経由してネットワークへ送信される。

“ＵＤＰ応答”
図２９のＩＰパケット生成部２４７で行うＵＤＰ応答について説明する。ＵＤＰ応答に使用するＵＤＰパケットのフォーマットとして先に示した図１８を以下の説明で参照する。
ここで説明するＵＤＰ応答の一つは、ＵＤＰを用いるＳＮＭＰやｈｔｔｐの各プロトコルによってアクセスできるＭＩＢ情報を得るために、ネットワークから送信されてくるＵＤＰリクエストに応えて、ＭＩＢ情報をＵＤＰデータとしてネットワークに送信する動作である。
ＰＥ２４は、ＰＦ２３からフィルタリングされたＭＩＢ情報をアクセスできるＵＤＰリクエストパケットを受取り、ＵＤＰ応答としてネットワークにＭＩＢ情報をＵＤＰデータとして設定したＵＤＰパケットを生成する。

ＵＤＰ応答時には、第１セレクタ２４６では、ＩＰパケット生成部２４７の出力を選択する。
ただし、ＩＰパケット生成部２４７の出力と、ＡＲＰリプライパケット生成部２４４の出力、ＰＩＮＧリプライパケット生成部２４５の出力との競合をさけるために、各パケット生成部の出力のタイミングが重なった場合、ネットワーク送信制御部２４１では、予め定めた優先順位に従い出力動作を行うようにする。
優先順位の例は、ＡＲＰリプライパケット生成部２４４の出力、ＰＩＮＧリプライパケット生成部２４５の出力、ＩＰパケット生成部２４７の出力の順とする。

図２９のＰＥ２４におけるＩＰパケット生成部２４７は、ＩＰヘッダ生成部２４７１、ＵＤＰヘッダ生成部２４７２、識別データ生成部２４７３、第２セレクタ２４７４、データ１、データ２、データ３、データ４の各データをそれぞれアクセスできるように格納したデータ記憶部２４７５、第１選択間隔時間生成部２４７８及び第２選択間隔時間生成部２４７９からなる。
なお、ＩＰパケット生成部２４７の出力は、第１セレクタ２４６に入力され、ＵＤＰ応答時に選択され、ネットワークに送信される。

データ記憶部２４７５に格納されたデータ１、データ２、データ３、データ４は、ＵＤＰパケットのＵＤＰデータフィールドに設定するＵＤＰデータである。ここに設定するＵＤＰデータは、例えば、上記したＳＮＭＰやｈｔｔｐにより、ＵＤＰリクエストパケットを用いてアクセスされるＭＩＢ情報等の非印刷要求パケットに応じて送信されるデータである。ＲＦＣ（Request For Comments）１１５５、ＲＦＣ１１５７、ＲＦＣ１２１３等に、ＳＮＭＰの詳細が記載されている。ＭＩＢについても、ＲＦＣ１２１３で規定されている。
データ記憶部２４７５に格納する、非印刷要求パケットに応じて送信されるＭＩＢ情報等のデータの設定は、ＣＰＵ２０の動作によって行われ、省エネモード中はできないので、省エネモードに移行する前にＣＰＵ２０が動作しているときに予め更新しておく。予め更新しておけば、通常時の情報を省エネモード時にアクセス可能となる。

また、ＳＳＤＰ（Simple Service Discovery Protocol）のアドバタイズに対して、ＵＤＰを使用して送信することができる。
ＳＳＤＰは、ネットワーク上の機器を検出するプロトコルであり、機器情報をＵＤＰパケットで送信処理を行う。機器情報についても、データ記憶部２４７５に用意する。このデータも、省エネモードに移行する前のＣＰＵ２０が動作しているときに予め最も新しいデータを用意しておく。

この実施形態では、第２セレクタ２４７４は、設定により、データ記憶部２４７５に格納された複数の応答用データのなかの指定されたデータを一つずつ、所定の順序で選択し、繰返してＵＤＰデータとして送信できるようにする。
このとき、第２セレクタ２４７４により選択される応答用データを取出すタイミングは、第１選択間隔時間生成部２４７８及び第２選択間隔時間生成部２４７９によって、単位サイクル内のデータの間隔と繰り返しサイクルの間隔を決めることができる。
例えば、全データを対象とし、データ１、データ２、データ３、データ４の順で選択する場合、第１選択間隔時間生成部２４７８で生成した第１選択間隔時間で、データ１、データ２、データ３、データ４の順で１サイクルの選択をする。また、データ４を選択後、第２選択間隔時間生成部２４７９で生成した第２選択間隔時間経過後に、次のサイクルに入り、再度、データ１を選択する。このサイクルでも、第１選択間隔時間が経過すれば、再度データ２から順にデータ３、データ４を選択する、という動作を繰返す。

ＵＤＰヘッダ生成部２４７２では、図１８のＵＤＰパケットにおけるＵＤＰヘッダ（図６、参照）の送信元ポート番号（ＳＰＮ）、宛先ポート番号（ＤＰＮ）、セグメント長（ｌｅｎ）、チェックサム（ＳＵＭ）を生成する。
宛先ポート番号（ＤＰＮ）、送信元ポート番号（ＳＰＮ）は、識別データ生成部２４７３で生成する。宛先ポート番号（ＤＰＮ）は、データ１からデータ４共に、同じ値を生成しても良い。例えば、ＳＳＤＰのプロトコルの場合は、「１９００」が宛先番号で、ＳＮＭＰの場合、「１６２」のポート番号というように、使用するプロトコルによって定められた番号を設定する。送信元ポート番号（ＳＰＮ）は、データ１、２、３、４毎に、固有な値を設定しても良い。例えば、データ１のポート番号は「５０００」、データ２のポート番号は「４９９９」、データ３のポート番号は「４９９８」、データ４のポート番号は「４９９７」と設定する。
セグメント長（ｌｅｎ）は、ＵＤＰデータの長さを設定する。チェックサム（ＳＵＭ）は、ヘッダ、ＵＤＰデータの１の補数を１６ビットで示す。

ＩＰパケット生成部２４７では、図１８のＵＤＰパケットにおけるＩＰヘッダ（図５、参照）を生成する。
予め、このプリンタの自局ＩＰアドレスをレジスタ部２４２のＳＩＰに、また、このプリンタの自局のハードウェアアドレスをレジスタ部２４２のＳＨＡに設定しておく。
また、ＵＤＰデータがＳＳＤＰプロトコルの場合には、マルチキャストアドレスを使用するので、マルチキャストアドレスに応じたＩＰアドレスをレジスタ部２４２のＤＩＰに、マルチキャストアドレスに対応したハードウェアアドレスをレジスタ部２４２のＤＨＡに設定しておく。これらのアドレスは、公知技術（例えば、オーム社発行の書籍「マスタリングＴＣＰ／ＩＰ 応用編」Ｐ.３０１に記載されている設定方法）を採用すればよい。
レジスタ部２４２のＴＹＰＥには、ＩＰフォーマットを示す「０ｘ８００」を設定しておく。

ＩＰヘッダにおいて、ＩＰバージョンは「４」、ヘッダ長は「５」を設定する。サービスタイプ（ＴＯＳ）は「０」を設定する。パケット長（ｌｅｎ）は、ＩＰヘッダ長、ＵＤＰヘッダ長とＵＤＰデータ長の和を設定する。
識別子（ＩＤ）は、識別データ生成部２４７３で生成した識別子を設定する。この識別子は、ＩＣＭＰ（ＰＩＮＧ）リプライパケット生成時の識別子としても使用される。識別子は、ＩＰパケットを送信する度に新たに生成する。
フラグには、分割不可、後続フラグメント無し、を設定して、フラグメントオフセットは０に設定する。生存時間（ＴＴＬ）は、最大値の２５５を設定する。プロトコルには、ＵＤＰを示す値である「１７」を設定する。ヘッダチェックサム（ＳＵＭ）は、ＩＰヘッダとＩＰデータのチェックサムを計算する。送信元ＩＰアドレス（ＳＩＰ）、宛先ＩＰアドレス（ＤＩＰ）は、レジスタ部２４２に設定してあるＳＩＰ、ＤＩＰを設定する。
また、ヘッダのオプションは生成しない。

イーサーフレームヘッダ生成部２４３は、第１セレクタ２４６を経て、ＩＰヘッダ生成部２４７１で生成されたＩＰヘッダとＩＰデータを受取り、そのデータのヘッダとして、レジスタ部２４２に設定してあるＤＨＡを宛先ＭＡＣアドレスフィールドに、ＳＨＡを送信元ＭＡＣアドレスフィールドに、ＴＹＰＥをタイプフィールドに設定して、イーサーフレームヘッダを生成する。
イーサネット（登録商標）パケットのＦＣＳは、後段のＭＡＣ２２で自動生成されるので、パケットＰＥ２４では生成する必要はない。

以上に述べたようにして、低消費電力モード時に受信したパケットが、ＭＩＢ情報等の返送といった非印刷要求のリクエストパケットである場合、ＰＥ２４が、応答用のパケットを作成して、応答処理を行い、主制御部のＣＰＵとメモリを動作させないので、主制御部のＣＰＵとメモリの消費電力を削減できる。
また、ＳＳＤＰのアドバタイズ情報を定期的に送信する場合、ＰＥ２４がアドバタイズ情報を作成し送信処理を行い、主制御部のＣＰＵとメモリを動作させないので、主制御部のＣＰＵとメモリの消費電力を削減できる。
また、ＰＥ２４は、低消費電力モード時に非印刷要求に応答する受信したパケットのサイズが所定サイズ以下の場合に応答し、また、応答時の返信情報を予め定めたサイズの複数の応答用データで対応するようにしたので、ＰＥ２４のハードウェアコストを小さくでき、消費電力を削減し、コストを低減できる。
さらに、ＰＥ２４は、受信したパケットの情報の一部を組み込んで応答用のパケットを作成して、応答処理を行うので、ハードウェアコストを小さくでき、消費電力を削減し、コストを低減できる。

また、低消費電力モード時に非印刷要求に応答して返信パケットを生成するＰＥ２４は、ネットワークから送信されてくるＵＤＰリクエストを受け、ＵＤＰデータによる応答を可能にしたので、ＵＤＰを用いるＳＮＭＰやｈｔｔｐによるアクセス要求によって得られるＭＩＢ情報、さらにＳＳＤＰによるリクエスト情報のサービス等、多様な非印刷要求のリクエストに応え、情報を提供することができる。

本発明の一実施形態に係るプリンタの制御を司るコントローラボードの機能構成を示すブロック図である。 図１に示すパワーマネジメント部（ＰＭ）によって管理される各電源供給モード間の移行動作の遷移図である。 イーサネット（登録商標）フレームの構造及びフォーマットを示す説明図である。 イーサネット（登録商標）フレーム（図３）におけるＩＰパケットとＵＤＰパケットのフォーマットを示す説明図である。 ＩＰパケット内の各フィールドのデータ内容を示す説明図である。 ＵＤＰパケット内の各フィールドのデータ内容を示す説明図である。 イーサネット（登録商標）フレーム（図３）におけるＩＰパケットとＴＣＰパケットのフォーマットを示す説明図である。ＩＰパケット内の各フィールドのデータ内容を示す説明図である。 ＴＣＰパケット内の各フィールドのデータ内容を示す説明図である。 イーサネット（登録商標）フレーム（図３）におけるＩＰパケットとＩＣＭＰエコーリクエスト／ＩＣＭＰエコーリプライパケットのフォーマットを示す説明図である。 ＩＣＭＰエコーリクエスト／ＩＣＭＰエコーリプライパケット内の各フィールドのデータ内容を示す説明図である。 イーサネット（登録商標）フレーム（図３）におけるＡＲＰパケットのフォーマットを示す説明図である。 図１２（Ａ）は、ＡＲＰパケットのフォーマットを示し、図１２（Ｂ）は、ＡＲＰパケット内の各フィールドのデータ内容の一例を示す説明図である。 図１に示すパケットエンジン部（ＰＥ）の内部構成例を示すブロック図である。 図１に示すパケットフィルタ部（ＰＦ）の内部構成例を示すブロック図である。 ＰＦ（図１３）におけるパターンフィルタの内部構成例を示すブロック図である。 パターンフィルタ（図１５）における ＤＨＣＰ プロトコルによるＵＤＰパケットのフィルタリング処理を説明する図である。 ＤＨＣＰプロトコル・シーケンスの概要を説明する図である。 ＤＨＣＰプロトコルに用いるＵＤＰパケットのフォーマットを示す図である。 ＤＨＣＰプロトコルにおけるＵＤＰデータの構成を示す。 ＤＨＣＰプロトコル・シーケンスに従ってＤＨＣＰＣｌｉｅｎｔ側で行うＩＰアドレス設定の処理フロー図である。 ＤＨＣＰプロトコル・シーケンス（図１９）におけるＤＨＣＰ ＲＥＱＵＥＳＴを示す図である。 省エネルギーモードにおけるＤＨＣＰプロトコルに従う通信動作の制御フロー図である。 省エネルギーモードにおけるＤＨＣＰプロトコルに従う通信動作の他の制御フロー図である。 図１に示すパケットフィルタ部（ＰＦ）の内部構成例を示すブロック図である。 ＰＦ（図２４）におけるＴＣＰパケットのフィルタリング処理を説明する図である。 ＰＦ（図２４）におけるＵＤＰパケットのフィルタリング処理を説明する図である。 ＰＦ（図２４）におけるＡＲＰパケットのフィルタリング処理を説明する図である。 ＰＦ（図２４）におけるＩＣＭＰパケットのフィルタリング処理を説明する図である。 図１に示すパケットエンジン部（ＰＥ）の内部構成例を示すブロック図である。 ＰＥ（図２９）におけるＡＲＰリプライパケット生成部を示す。 ＰＥ（図２９）におけるＰＩＮＧリプライパケット生成部を示す。

符号の説明

１・・・コントローラボード、２・・・プロッタ、３・・・ＰＣＩバス、１０・・・ＡＳＩＣ、１１・・・メモリ（ＤＤＲ）、１２・・・ＰＨＹ、１３・・・ＰＨＹクロック生成部、１４・・・ＡＳＩＣクロック生成部、１５・・・Memory Card、１６・・・ＯＰ、１７・・・ＨＤＤ、１８・・・ボード電力制御部、１９・・・外部電力制御部、２０・・・ＣＰＵ、２１・・・ＭＥＭ Ｉ／Ｆ、２２・・・ＭＡＣ、２３・・・ＰＦ、２４・・・ＰＥ、２５・・・ＳＥＬ、２６・・・ＣＧ、２７・・・ＰＣＩ Ｉ／Ｆ、２８・・・Memory Card Ｉ／Ｆ、２９・・・ＯＰＥＩ／Ｆ、３０・・・ＨＤＤＩ／Ｆ、３１・・・Ｉ／Ｏ Ｉ／Ｆ、３２・・・ＰＭ、３３・・・タイマ、３４・・・内部バス、３５・・・パワーオフ領域、３６・・・ＲＡＭ、３７・・・ＲＯＭ(1)、３８・・・ＲＯＭ(2)、２３１・・・アドレスフィルタ、２３３・・・パターンフィルタ、２３３ａ・・・ＤＨＣＰ ＡＣＫ用ＰＦ、２３３ｎ・・・ＤＨＣＰ ＮＡＫ用ＰＦ、２３５・・・バッファ、２４１・・・ネットワーク送信制御部、２４２・・・レジスタ部、２４３・・・イーサーフレームヘッダ生成部、２４４・・・ＡＲＰリプライパケット生成部、２４５・・・ＰＩＮＧリプライパケット生成部、２４６・・・第１セレクタ、２４７・・・ＩＰパケット生成部、２４７１・・・ＩＰヘッダ生成部、２４７２・・・ＵＤＰデータ生成部、２４７３・・・識別データ生成部、２４７６・・・ＤＨＣＰパケット生成部、２４９・・・定期送信感覚時間設定部、２４１１・・・再送制御部、２４４１，２５５１・・・パケット解析部、２４４２，２４５２・・・パケット生成部、２４７１・・・ＩＰヘッダ生成部、２４７２・・・ＵＤＰヘッダ生成部、２４７３・・・識別データ生成部、２４７６・・・ＤＨＣＰパケット生成部。

Claims (24)

1. ＣＰＵを有する主制御部と、少なくとも前記主制御部のＣＰＵへの電源供給を停止する低消費電力モードの電源供給制御をする電源制御部と、ネットワークとパケットを交信する通信部と、前記通信部を経て送信する所定フレーム構造のパケットを生成するパケット生成部と、前記通信部で受信したパケットから所定フレーム構造を持つ受取るべきパケットを検出するパケットフィルタ部と、前記パケット生成部によって生成されたパケットを所定のタイミングで送信する送信制御部を有する情報処理装置であって、
   前記電源制御部は、低消費電力モード時に前記通信部、前記パケットフィルタ部及び前記パケット生成部を動作させるための電源供給を行い、
   前記パケット生成部は、送信データを記憶する送信データ記憶手段と、前記送信データを送信ごとに識別するための識別データを生成する識別データ生成手段と、前記識別データ生成手段で生成した識別データと前記送信データ記憶手段からの送信データを組合せてパケットを生成する手段を備え、
   前記送信制御部は、低消費電力モード時に前記パケット生成部によって生成された送信データのパケットを予め設定された送信時間間隔で定期的に送信することを特徴とする情報処理装置。
2. 請求項１に記載された情報処理装置において、
   前記パケット生成部は、ネットワークからの応答を求めるパケットを自発的に生成するとともに、前記パケットフィルタ部は、前記応答を求めるパケットに対する応答パケットを検出し、
   前記送信制御部は、前記応答を求めるパケットを送信した後、当該パケットに対する応答パケットが所定時間内に前記パケットフィルタ部によって検出されないときに、該応答を求めるパケットを再送する動作を所定回数にわたり行うようにしたことを特徴とする情報処理装置。
3. 請求項２に記載された情報処理装置において、
   前記識別データ生成手段は、前記応答を求めるパケットを再送する際、並びに前記パケットフィルタ部を介して前記応答パケットを受信した際に識別データを更新するようにしたことを特徴とする情報処理装置。
4. 請求項２又は３のいずれかに記載された情報処理装置において、
   前記パケットデータ生成部は、前記応答を求めるパケットとして、ＤＨＣＰプロトコルデータによるパケットを生成するようにしたことを特徴とする情報処理装置。
5. 請求項２乃至４のいずれかに記載された情報処理装置において、
   前記パケットフィルタ部は、受信する前記応答パケットとして、ＤＨＣＰプロトコルデータによるパケットを検出するようにしたことを特徴とする情報処理装置。
6. 請求項４又は５に記載された情報処理装置において、
   前記識別データ生成手段は、ＤＨＣＰプロトコルで使用するトランザクションＩＤを識別データとして用いるようにしたことを特徴とする情報処理装置。
7. 請求項１乃至６のいずれかに記載された情報処理装置において、
   前記主制御部のＣＰＵは、低消費電力モードへ移行する際に前記識別データ生成手段へ前記低消費電力モード時に使用する識別データを通知するようにしたことを特徴とする情報処理装置。
8. 請求項１乃至７のいずれかに記載された情報処理装置において、
   前記識別データ生成手段は、低消費電力モードから他のモードに移行する際に低消費電力モードで使用していた識別データを前記主制御部のＣＰＵに通知するようにしたことを特徴とする情報処理装置。
9. 請求項２乃至８のいずれかに記載された情報処理装置において、
   前記パケットフィルタ部は、前記応答パケットを受信できないときに、前記電源制御部に低消費電力モードから通常電力モードに移行する指示するとともに、前記応答パケットを受信できないことを前記主制御部のＣＰＵに通知するようにしたことを特徴とする情報処理装置。
10. 請求項１に記載された情報処理装置において、
    前記パケットフィルタ部は、低消費電力モードで応答を求めるリクエストパケットを検出し、検出結果を前記パケット生成部に通知する手段を備え、
    前記パケット生成部は、前記パケットフィルタ部から前記リクエストパケットの検知結果の通知を受けて、当該リクエストパケットに応答するパケットを生成するための手段として、複数の応答用データを記憶する応答用データ記憶手段と、前記応答用データ記憶手段から送信データを選択する送信データ選択手段をさらに備えたことを特徴とする情報処理装置。
11. 請求項１０に記載された情報処理装置において、
    前記識別データ生成手段は、複数の識別データを生成することを特徴とする情報処理装置。
12. 請求項１０又は１１に記載された情報処理装置において、
    前記パケット生成部は、第１の選択間隔時間を設定する第１選択間隔時間設定部を備え、
    前記送信データ選択手段は、複数の応答用データから、前記第１選択間隔時間設定部で設定した第１の選択間隔時間で、一つずつデータを選択することを特徴とする情報処理装置。
13. 請求項１０乃至１２のいずれかに記載された情報処理装置において、
    前記パケット生成部は、第２の選択間隔時間を設定する第２選択間隔時間設定部を備え、
    前記送信データ選択手段は、前記第１選択間隔時間設定部で設定した第１の選択間隔時間で、一つずつデータを選択する動作を全送信データに対して行った後、前記第２選択間隔時間設定部で設定した第２の選択間隔時間が経過した後、再度、前記第１選択間隔時間設定部で設定した第１の選択間隔時間で、一つずつデータを選択する動作を繰返すことを特徴とする情報処理装置。
14. 請求項１０乃至１３のいずれかに記載された情報処理装置において、
    前記パケット生成部において生成するパケットがＩＰフレーム構造のパケットであることを特徴とする情報処理装置。
15. 請求項１４に記載された情報処理装置において、
    前記識別データ生成手段で生成する複数の識別データがＩＰフレーム構造のパケットにおける識別子であることを特徴とする情報処理装置。
16. 請求項１４又は１５に記載された情報処理装置において、
    複数の応答用データがＵＤＰフレーム構造のパケットにおけるＵＤＰデータであることを特徴とする情報処理装置。
17. 請求項１６に記載された情報処理装置において、
    前記識別データ生成手段において生成する複数の識別データがＵＤＰフレーム構造のパケットにおけるポート番号であることを特徴とする情報処理装置。
18. 請求項１〜１５の情報処理装置と画像形成手段を具備する画像形成装置。
19. コンピュータを請求項１乃至１７のいずれかに記載された情報処理装置における前記主制御部、前記電源制御部、前記パケット生成部、前記パケットフィルタ部、前記送信制御部の各部として機能させるためのプログラム。
20. 請求項１９に記載されたプログラムを記録したコンピュータ読取可能な記録媒体。
21. 主制御部への電源供給を停止する低消費電力モード時に、所定フレーム構造の送信パケットを生成し、生成したパケットをネットワークに送信し、かつネットワークから所定フレーム構造を持つパケットを受信できる情報処理装置における情報処理方法であって、
    送信ごとに送信データを識別するための識別データを生成する識別データ生成工程と、
    前記識別データ生成工程で生成した識別データと送信データを組合せてパケットを生成するパケット生成工程と、
    低消費電力モード時に前記パケット生成工程によって生成された送信データのパケットを予め設定された送信時間間隔で定期的にネットワークに送信する送信制御工程を有したことを特徴とする情報処理方法。
22. 請求項２１に記載された情報処理方法において、
    前記パケット生成工程は、ネットワークからの応答を求めるパケットを自発的に生成する工程であり、
    前記送信制御工程は、前記パケット生成工程で応答を求めるパケットを送信した後、当該パケットに対する応答パケットが受信されないときに、該応答を求めるパケットを再送する動作を指定回数にわたり行うようにした工程であることを特徴とする情報処理方法。
23. 請求項２２に記載された情報処理方法において、
    前記識別データ生成工程は、前記応答を求めるパケットを再送する際、並びに前記パケットフィルタ部を介して前記応答パケットを受信した際に識別データの更新を行う工程であることを特徴とする情報処理方法。
24. 請求項２１に記載された情報処理方法において、
    受信したパケットから所定フレーム構造を持つ受取るべきリクエストパケットを通過させるパケットフィルタリング工程と、
    パケットフィルタリング工程で通過させるパケットが低消費電力モードで応答可能なリクエストパケットであることを、設定されたデータ内容に基づき認識する応答リクエスト認識工程をさらに有し、
    前記パケット生成工程は、応答リクエスト認識工程の認識結果を受けて、複数の応答用データから選択したデータに識別データを組み合わせて、所定フレーム構造のパケットを生成する工程をさらに有したことを特徴とする情報処理方法。

Images