通信装置
【課題】 複数個の装置のそれぞれから要求パケットが繰り返し受信される状況において、複数個の装置間の要求パケットの受信タイミングを近づけ得る技術を提供する。
【解決手段】 多機能機１０は、ＰＣ１００からステータス要求パケットを受信し、ＰＣ２００からステータス要求パケットを受信する。多機能機１０は、ＰＣ１００からのステータス要求パケットに対する応答パケットをＰＣ１００に送信し、ＰＣ２００からのステータス要求パケットに対する応答パケットをＰＣ２００に送信する。多機能機１０は、ＰＣ２００からのステータス要求パケットの受信からＰＣ２００への応答パケットの送信までの時間が、ＰＣ１００からのステータス要求パケットの受信からＰＣ２００への応答パケットの送信までの時間よりも長くなるように、ＰＣ２００への送信タイミングを決定する。
【解決手段】 多機能機１０は、ＰＣ１００からステータス要求パケットを受信し、ＰＣ２００からステータス要求パケットを受信する。多機能機１０は、ＰＣ１００からのステータス要求パケットに対する応答パケットをＰＣ１００に送信し、ＰＣ２００からのステータス要求パケットに対する応答パケットをＰＣ２００に送信する。多機能機１０は、ＰＣ２００からのステータス要求パケットの受信からＰＣ２００への応答パケットの送信までの時間が、ＰＣ１００からのステータス要求パケットの受信からＰＣ２００への応答パケットの送信までの時間よりも長くなるように、ＰＣ２００への送信タイミングを決定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書では、外部装置から送信される要求パケットに対する応答パケットを送信する通信装置を開示する。
【背景技術】
【０００２】
特許文献１には、クライアントコンピュータに接続されるＭＦＰ（多機能周辺装置）が開示されている。ＭＦＰは、クライアントコンピュータからイベント記述子列が受信されると、イベント記述子列に対する応答として、成功メッセージ又はエラーメッセージを、クライアントコンピュータに送信する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−１５４８２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記の特許文献１の技術では、例えば、ＭＦＰが、複数個のクライアントコンピュータのそれぞれから、イベント記述子列を繰り返し受信する状況では、イベント記述子列の受信タイミングにばらつきが生じる可能性がある。この場合、ＭＦＰは、効率的な処理を実行することができない可能性がある。
【０００５】
本明細書では、複数個の装置のそれぞれから要求パケットが繰り返し受信される状況において、複数個の装置間の要求パケットの受信タイミングを近づけ得る技術を提供する。
【課題を解決するための手段】
【０００６】
本明細書によって開示される技術は、第１の装置と第２の装置とのそれぞれに接続される通信装置である。第１の装置は、第１の要求パケットを通信装置に送信して、第１の要求パケットに対する第１の応答パケットを、通信装置から受信する処理を繰り返し実行する。第１の装置は、第１の応答パケットを受信してから所定の期間が経過する際に、第１の要求パケットを新たに送信する。第２の装置は、第２の要求パケットを通信装置に送信して、第２の要求パケットに対する第２の応答パケットを、通信装置から受信する処理を繰り返し実行する。第２の装置は、第２の応答パケットを受信してから上記の所定の期間が経過する際に、第２の要求パケットを新たに送信する。通信装置は、受信制御部と、送信制御部と、決定部と、を備える。受信制御部は、第１の装置から第１の要求パケットを受信し、第２の装置から第２の要求パケットを受信する。送信制御部は、第１の要求パケットに対する第１の応答パケットを第１の装置に送信し、第２の要求パケットに対する第２の応答パケットを第２の装置に送信する。決定部は、第２の応答パケットを第２の装置に送信するための送信タイミングを決定する。決定部は、第２の要求パケットの受信から当該第２の要求パケットに対する第２の応答パケットの送信までの期間が、第１の要求パケットの受信から当該第１の要求パケットに対する第１の応答パケットの送信までの期間よりも長くなるように、送信タイミングを決定する。送信制御部は、決定済みの送信タイミングで、第２の応答パケットを第２の装置に送信する。
【０００７】
上記の構成では、通信装置は、第２の要求パケットの受信から第２の応答パケットの送信までの期間が、第１の要求パケットの受信から第１の応答パケットの送信までの期間よりも長くなるようなタイミングで、第２の応答パケットを送信する。この構成によれば、特定の第２の要求パケットに対する第２の応答パケットの送信タイミングを、上記の特定の第２の要求パケットの次に受信される特定の第１の要求パケットに対する第１の応答パケットの送信タイミングに近づけ得る。第１の装置と第２の装置との両者は、応答パケットを受信してから所定の期間が経過すると、次の要求パケットを送信する。このため、上記の特定の第２の要求パケットの次に受信される第２の要求パケットの受信タイミングを、上記の特定の第１の要求パケットの次に受信される第１の要求パケットの受信タイミングに近づけ得る。
【０００８】
なお、上記の通信装置を実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムが記憶された記憶媒体も、新規で有用である。また、上記の通信装置と上記の第１及び第２の装置とを含むシステムも新規で有用である。
【図面の簡単な説明】
【０００９】
【図１】ネットワークシステムの構成を示す。
【図２】応答処理のフローチャートを示す。
【図３】各装置の動作を表わすシーケンス図を示す。
【発明を実施するための形態】
【００１０】
図１に示すように、ネットワークシステム２は、ＰＣ１００，２００と、多機能機（即ちＰＣ１００，２００の周辺機器）１０と、を備える。各装置１０，１００，２００は、ＬＡＮ４を介して、相互に通信可能である。
【００１１】
（多機能機１０の構成）
図１に示すように、多機能機１０は、ＡＳＩＣ（Application Specific Integrated Circuit）１２、フラッシュメモリ７０、ＳＤＲＡＭ８０、ネットワークインターフェイス９０、表示パネル９２、及び、画像形成部９４を備える。
【００１２】
ＡＳＩＣ１２は、メインＣＰＵ２０、メイン用クロック回路３０、サブＣＰＵ４０、サブ用クロック回路５０、ＳＲＡＭ６０、ＳＤＲＡＭ制御回路６４、及び、ＭＡＣコントローラ６６を備える。
【００１３】
メインＣＰＵ２０は、ＳＤＲＡＭ８０に記憶されているプログラム８２に従って様々な処理を実行する。これにより、受信制御部２２と送信制御部２４と決定部２６との各機能が実現される。メイン用クロック回路３０は、メインＣＰＵ２０にクロック信号を供給する。メイン用クロック回路３０からメインＣＰＵ２０にクロック信号が供給されている間は、メインＣＰＵ２０は非スリープ状態である。メインＣＰＵ２０にクロック信号が供給されていない間は、メインＣＰＵ２０はスリープ状態である。メインＣＰＵ２０のスリープ状態は、メインＣＰＵ２０の非スリープ状態と比較して、消費電力が低い状態である。メイン用クロック回路３０は、サブＣＰＵ４０によって制御される。即ち、サブＣＰＵ４０によって、メインＣＰＵ２０へのクロック信号の供給及び停止が制御される。
【００１４】
サブＣＰＵ４０は、ＳＲＡＭ６０に記憶されているプログラム６２に従って様々な処理を実行する。これにより、受信制御部４２と移行制御部４８との各機能が実現される。サブ用クロック回路５０は、サブＣＰＵ４０にクロック信号を供給する。サブ用クロック回路５０のクロック信号の周波数は、メイン用クロック回路３０のクロック信号の周波数よりも低い。従って、メインＣＰＵ２０を駆動するための消費電力と比べて、サブＣＰＵ４０を駆動するための消費電力は低い。なお、メインＣＰＵ２０の処理速度は、サブＣＰＵ４０の処理速度よりも速い。サブ用クロック回路５０は、多機能機１０の電源がＯＮにされるとサブＣＰＵ４０にクロック信号を供給し、多機能機１０の電源がＯＦＦにされるとクロック信号を停止する。即ち、サブＣＰＵ４０は、多機能機１０の電源がＯＮされている間、クロック信号が供給されている状態（非スリープ状態）で維持される。変形例では、サブＣＰＵ４０は、メインＣＰＵ２０が非スリープ状態である間、スリープ状態であってもよい。即ち、サブ用クロック回路５０は、メインＣＰＵ２０が非スリープ状態である間、サブＣＰＵ４０へのクロック信号を停止してもよい。
【００１５】
ＳＲＡＭ６０は、各ＣＰＵ２０，４０からアクセス可能である。多機能機１０の電源がＯＮされると、メインＣＰＵ２０は、フラッシュメモリ７０内の圧縮されたプログラム７２を展開して、展開済みのプログラム６２をＳＲＡＭ６０に記憶する。
【００１６】
ＳＤＲＡＭ制御回路６４は、サブＣＰＵ４０からの指示に従って、ＳＤＲＡＭ８０に対するクロック信号の供給の開始又は停止をして、消費電力が比較的に高い通常動作モードと、消費電力が比較的に低いセルフリフレッシュモードと、の間でＳＤＲＡＭ８０の状態を移行させる。
【００１７】
ＭＡＣコントローラ６６は、ネットワークインターフェイス９０に接続されている。ＭＡＣコントローラ６６は、ＬＡＮ４を介して、ネットワークインターフェイス９０でパケットが受信されると、メインＣＰＵ２０又はサブＣＰＵ４０の割込コントローラ（図示省略）にパケット割込要求信号を供給する。
【００１８】
フラッシュメモリ７０は、ＡＳＩＣ１２の外部に設けられている。フラッシュメモリ７０は、各ＣＰＵ２０，４０からアクセス可能である。フラッシュメモリ７０は、各ＣＰＵ２０，４０によって実行されるプログラム６２，８２が圧縮された状態のプログラム７２を記憶している。
【００１９】
ＳＤＲＡＭ８０は、メインＣＰＵ２０からアクセス可能である。ＳＤＲＡＭ８０は、ＳＲＡＭ６０よりもメモリの総容量が大きく、各ＣＰＵ２０，４０がアクセス（読み出し、書き込み）可能な速度が高速である。このため、ＳＤＲＡＭ８０の消費電力は、ＳＲＡＭ６０の消費電力と比べて高い。ＳＤＲＡＭ８０は、ＳＤＲＡＭ制御回路６４によって制御され、通常動作モードとセルフリフレッシュモードとの間で状態が移行する。また、ＳＤＲＡＭ８０は、パケット情報８４を記憶することができる。パケット情報８４とは、ステータス要求パケットの受信時刻と、当該ステータス要求パケットの送信元のデバイス（例えばＰＣ１００）のＭＡＣアドレスと、が対応付けられた情報である（図３参照）。
【００２０】
表示パネル９２は、メインＣＰＵ２０からの指示に従って、情報を表示する。表示パネル９２には、ユーザからの操作を受け付けるためのタッチボタンが配置される。画像形成部９４は、インクジェット方式又はレーザ方式の画像形成機構を備え、メインＣＰＵ２０からの指示に従って、外部のデバイス（例えばＰＣ１００，２００）から受信される印刷データによって表わされる画像を、印刷用紙に印刷する。
【００２１】
（多機能機１０の状態移行）
多機能機１０の状態は、レディ状態とスリープ状態との間で移行する。多機能機１０の電源がＯＮされると、多機能機１０は、レディ状態となる。
【００２２】
（レディ状態）
多機能機１０がレディ状態である場合、２個のＣＰＵ２０，４０は非スリープ状態（２個のクロック回路３０，５０からそれぞれクロック信号が供給されている状態）であり、２個のＲＡＭ６０，８０は通常動作モードである。この状態では、メインＣＰＵ２０は、通常の処理を実行することができる。上記の通常の処理は、印刷指示パケットに従った印刷処理、ユーザの表示パネル９２への操作に従った表示処理等を含む。なお、メインＣＰＵ２０は、多機能機１０がレディ状態である場合、ＳＤＲＡＭ８０に、レディ状態を示す状態変数を記憶させる。
【００２３】
（スリープ状態）
多機能機１０は、サブＣＰＵ４０が後述する図２のＳ１６等の処理を実行することによって、レディ状態からスリープ状態に移行する。多機能機１０がスリープ状態である場合、メインＣＰＵ２０はスリープ状態であり（メイン用クロック回路３０からのクロック信号が停止されている状態）、サブＣＰＵ４０は非スリープ状態であり（サブ用クロック回路５０からのクロック信号が供給されている状態）、ＳＲＡＭ６０は通常動作モードであり、ＳＤＲＡＭ８０はセルフリフレッシュモードである。多機能機１０がスリープ状態であって、メインＣＰＵ２０が上記の通常の処理（印刷処理、表示処理等）を実行すべき場合には、多機能機１０は、レディ状態に移行する。
【００２４】
なお、メインＣＰＵ２０は、多機能機１０がレディ状態からスリープ状態に移行される際に、ＳＤＲＡＭ８０内の状態変数を、ＳＲＡＭ６０に移動させる。サブＣＰＵ４０は、多機能機１０がスリープ状態に移行されると、ＳＲＡＭ６０内の状態変数を、スリープ状態を示す状態変数に変更する。さらに、サブＣＰＵ４０は、多機能機１０がスリープ状態からレディ状態に移行される際に、ＳＲＡＭ６０内の状態変数を、ＳＤＲＡＭ８０に移動させる。メインＣＰＵ２０は、多機能機１０がレディ状態に移行されると、ＳＤＲＡＭ８０内の状態変数を、レディ状態を示す状態変数に変更する。
【００２５】
（ＰＣ１００の構成）
ＰＣ１００には、多機能機１０のステータスを監視するためのステータス監視プログラム（例えばステータスモニタ）がインストールされている。ユーザは、ＰＣ１００を操作することによって、ステータス監視プログラムを起動させることができる。ＰＣ１００は、ステータス監視プログラムが起動されると、多機能機１０から多機能機１０のステータス情報を取得する。
【００２６】
具体的には、ＰＣ１００は、ステータス監視プログラムが起動されると、ステータス要求パケットを、多機能機１０に送信する。なお、ステータス要求パケットは、ＰＣ１００のＭＡＣアドレスを含む。ＰＣ１００は、ステータス要求パケットの応答として、多機能機１０からステータス情報を含む応答パケットを受信する。ＰＣ１００は、受信された応答パケットに従って、ステータス情報をＰＣ１００の表示部に表示させる。ＰＣ１００は、応答パケットの受信から予め決められた待機期間（本実施例では３０秒間）が経過する際に、ステータス要求パケットを、多機能機１０に新たに送信する。即ち、ＰＣ１００は、ステータス監視プログラムが起動されている間、ステータス要求パケットの送信処理と、応答パケットの受信処理と、を繰り返し実行する。
【００２７】
なお、ステータス情報は、多機能機１０の状態（スリープ状態又はレディ状態）、印刷用紙の有無、トナーの有無、及び、実行中の印刷のエラー情報（例えば用紙詰まり、画像形成部の故障等）を示す情報を含む。
【００２８】
ＰＣ１００は、およそ３０秒間隔（上記の待機期間）で、多機能機１０からステータス情報を繰り返し取得する。これにより、ＰＣ１００のユーザは、多機能機１０の最新のステータスを確認することができる。この構成によれば、例えば、ＰＣ１００のユーザは、多機能機１０の画像形成部９４に印刷処理を実行させている場合に、印刷用紙が無くなったことを早期に知ることができる。また、ＰＣ１００がステータス情報を多機能機１０から定期的に取得するため、ＰＣ１００のユーザは、多機能機１０のステータス情報を、ＰＣ１００に取得させるための操作を実行しなくて済む。
【００２９】
ＰＣ１００は、ステータス要求パケットを多機能機１０に送信してから、２秒間（以下では「タイムアウト時間」と呼ぶ）経過しても、応答パケットが多機能機１０から受信されない場合、応答パケットを受信できないと判断する。この場合、ＰＣ１００は、再度、ステータス要求パケットを、多機能機１０に送信する。ＰＣ１００は、予め決められた個数のステータス要求パケットを送信しても、タイムアウト時間内に応答パケットが受信されない場合、通信エラーを示す情報を、ＰＣ１００の表示部に表示させる。これにより、ＰＣ１００のユーザは、多機能機１０とＰＣ１００とが通信できないことを知ることができる。
【００３０】
なお、ＰＣ１００は、ステータス要求パケットを多機能機１０に送信してからタイムアウト時間が経過した後に、応答パケットが多機能機１０から受信されたとしても、応答パケットに従ったステータス情報を、ＰＣ１００の表示部に表示させない。
【００３１】
ＰＣ２００は、ＰＣ１００と同様の構成を備える。即ち、ＰＣ２００は、ステータス監視プログラムが起動されると、ステータス要求パケットを、多機能機１０に送信する送信処理と、多機能機１０から応答パケットを受信する受信処理と、を繰り返し実行する。
【００３２】
（メインＣＰＵ２０及びサブＣＰＵ４０が実行する処理）
次いで、図２を参照して、メインＣＰＵ２０及びサブＣＰＵ４０が実行する処理の内容について説明する。本処理は、多機能機１０の電源がＯＮされている間、繰り返し実行される。多機能機１０の電源がＯＮされたタイミングでは、多機能機１０はレディ状態である。即ち、多機能機１０の電源がＯＮされたタイミングでは、メインＣＰＵ２０が本処理を実行する。
【００３３】
Ｓ１２では、受信制御部２２は、ＬＡＮ４を介して、パケットが受信されたのか否かを判断する。ネットワークインターフェイス９０でパケットが受信される場合、ＭＡＣコントローラ６６は、パケット割込要求信号を、メインＣＰＵ２０に供給する。受信制御部２２は、パケット割込要求信号を取得すると、受信されたパケットを、ネットワークインターフェイス９０からＳＤＲＡＭ８０に移動させる。Ｓ１２では、受信制御部２２は、ＳＤＲＡＭ８０に受信済みのパケットが存在するのか否かを判断する。
【００３４】
パケットが受信されていない場合（Ｓ１２でＮＯ）、Ｓ１４において、メインＣＰＵ２０は、メインＣＰＵ２０をスリープ状態に移行可能（即ち多機能機１０をスリープ状態に移行可能）であるのか否かを判断する。例えば、メインＣＰＵ２０は、以下の（１）〜（５）の条件を含む複数個の条件の全てでＮＯと判断される場合に、スリープ状態に移行可能（Ｓ１４でＹＥＳ）と判断し、複数個の条件のうち、少なくとも１個の条件でＹＥＳと判断される場合に、スリープ状態に移行不可能（Ｓ１４でＮＯ）と判断する。
【００３５】
上記の複数個の条件は、（１）多機能機１０がパケットを外部に送信中であるのか否か、（２）未処理パケットがＳＤＲＡＭ８０に記憶されているのか否か、（３）多機能機１０にＴＣＰ接続しているデバイス（例えばＰＣ１００）があるのか否か、（４）多機能機１０が起動又はシャットダウンのための処理を実行しているのか否か、（５）ネットワークの負荷が高いのか否か、を含む。
【００３６】
例えば、メインＣＰＵ２０がＰＣ１００等からのパケットに対する応答を送信している場合には、上記の（１）でＹＥＳと判断される。例えば、多機能機１０がＷｅｂサーバ機能を有しており、ＰＣ１００が多機能機１０のＷｅｂサーバにＴＣＰ接続中である場合には、上記の（３）でＹＥＳと判断される。例えば、Ｓ１４の処理を実行する直前の所定の期間に受信されたパケット数が所定の個数を超えている場合には、多機能機１０が処理すべきパケットを受信する可能性が高いために、上記の（５）でＹＥＳと判断される。従って、ここで示されるように、上記の（１）〜（５）の条件のうち、少なくとも１個の条件でＹＥＳと判断される場合に、スリープ状態に移行不可能（Ｓ１４でＮＯ）と判断する。
【００３７】
一方、上記の（１）〜（５）の条件の全てでＮＯと判断される場合に、メインＣＰＵ２０がスリープ状態に移行可能（Ｓ１４でＹＥＳ）と判断される。このＳ１４でＹＥＳの場合、Ｓ１６において、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる。具体的には、移行制御部４８は、メイン用クロック回路３０にクロック供給の停止を指示する。この結果、メインＣＰＵ２０は、非スリープ状態からスリープ状態に移行する。なお、Ｓ１６では、さらに、移行制御部４８は、ＳＤＲＡＭ８０を通常動作モードからセルフリフレッシュモードに移行させる。これにより、多機能機１０は、スリープ状態となる。なお、ＳＤＲＡＭ８０がセルフリフレッシュモードである間は、ＳＤＲＡＭ８０に情報を書き込んだり、ＳＤＲＡＭ８０から情報を読み込んだりすることができない。例えば、ネットワークインターフェイス９０で受信されたパケットをＳＤＲＡＭ８０に記憶させることができない。
【００３８】
なお、メインＣＰＵ２０は、Ｓ１６でスリープ状態に移行する前に、多機能機１０をレディ状態からスリープ状態に移行するために、以下の処理を実行する。即ち、メインＣＰＵ２０は、代理応答情報を、ＳＤＲＡＭ８０からＳＲＡＭ６０に移動させる。代理応答情報は、メインＣＰＵ２０がスリープ状態である間に受信されたパケットに従った処理を、サブＣＰＵ４０が実行するための情報（例えば多機能機１０のＩＰアドレス、ＭＡＣアドレス、ノード名等）を含む。また、メインＣＰＵ２０は、ＬＡＮ４を介して受信されるパケットを記憶するためのＲＡＭを、ＳＤＲＡＭ８０からＳＲＡＭ６０に切り替える。続いて、メインＣＰＵ２０は、サブＣＰＵ４０以外からの割込要求をマスク（禁止）する。次いで、メインＣＰＵ２０は、サブＣＰＵ４０に処理を開始させるための開始信号を、サブＣＰＵ４０に供給する。サブＣＰＵ４０は、開始信号が取得されると、Ｓ１６の処理を実行する。なお、メインＣＰＵ２０は、ＷＡＩＴ命令を実行する。ＷＡＩＴ命令が実行されると、メインＣＰＵ２０は、サブＣＰＵ４０から割込要求信号が供給されるまで待機する実行停止状態となる。
【００３９】
Ｓ１６が終了すると、Ｓ１２に戻る。即ち、メインＣＰＵ２０がスリープ状態である間に、Ｓ１２が実行される。この場合、サブＣＰＵ４０の受信制御部４２がＳ１２を実行する。Ｓ１２でＮＯの場合、Ｓ１４において、メインＣＰＵ２０が既にスリープ状態であるために、ＮＯと判断され、Ｓ１２に戻る。
【００４０】
以下のＳ１８の処理では、Ｓ１２において、サブＣＰＵ４０の受信制御部４２が、パケットが受信されたと判断する場合（メインＣＰＵ２０がスリープ状態である間にパケットが受信される場合）について説明する。
【００４１】
Ｓ１８では、サブＣＰＵ４０は、メインＣＰＵ２０がスリープ状態であるのか否かを判断する。具体的には、サブＣＰＵ４０は、ＳＲＡＭ６０内の状態変数を確認して、多機能機１０がスリープ状態であるのか否かを判断することによって、メインＣＰＵ２０がスリープ状態であるのか否かを判断する。この場合では、Ｓ１８にてＹＥＳと判断され、次いで、Ｓ２０では、サブＣＰＵ４０は、Ｓ１２で受信されたパケットを解析することによって、サブＣＰＵ４０自身がパケットに従った処理を実行することができるのか否かを判断する。
【００４２】
例えば、サブＣＰＵ４０は、ＳＲＡＭ６０内の代理応答情報を用いて、Ｓ１２で受信されたパケットに従った応答処理を実行可能であるのか否かを判断する。サブＣＰＵ４０が代理して実行可能な応答処理は、例えば、ＰＩＮＧに対する応答、ＡＲＰ（Address Resolution Protocol）のパケットに対する応答等を含む。なお、Ｓ１２で受信されたパケットがＰＣ１００，２００からのステータス要求パケットである場合、サブＣＰＵ４０は、サブＣＰＵ４０自身がパケットに従った処理を実行することができないと判断する。
【００４３】
Ｓ２０でＹＥＳの場合、Ｓ２２において、サブＣＰＵ４０は、Ｓ１２で受信されたパケットに従った処理を実行して、Ｓ１２に戻る。Ｓ２０でＮＯの場合、Ｓ２４において、移行制御部４８は、メインＣＰＵ２０をスリープ状態から非スリープ状態に移行する。具体的には、移行制御部４８は、メイン用クロック回路３０に、メインＣＰＵ２０にクロック供給を開始するよう指示する。この結果、メインＣＰＵ２０にクロックが供給され、メインＣＰＵ２０がスリープ状態から非スリープ状態に移行する。移行制御部４８は、メインＣＰＵ２０に割込要求信号を供給する。
【００４４】
サブＣＰＵ４０は、さらに、ＳＤＲＡＭ８０をセルフリフレッシュモードから通常動作モードに移行させる処理、外部デバイスからの受信パケットの記憶先をＳＲＡＭ６０からＳＤＲＡＭ８０に切り替える処理、ＳＲＡＭ６０内の情報をＳＤＲＡＭ８０に移動させる処理等を実行する。
【００４５】
メインＣＰＵ２０は、サブＣＰＵ４０から割込要求信号が供給されると、ＷＡＩＴ命令を解除する。メインＣＰＵ２０は、ＳＲＡＭ６０に記憶されている未処理のパケットを、ＳＤＲＡＭ８０に移動させる。
【００４６】
Ｓ２６において、メインＣＰＵ２０は、Ｓ１２で受信されたパケットが、ステータス要求パケットであるのか否かを判断する。具体的には、メインＣＰＵ２０は、Ｓ１２で受信されたパケットが、ＳＮＭＰ（Simple Network Management Protocol）のオブジェクトデータを要求するパケットであるのか否かを判断する。例えば、メインＣＰＵ２０は、パケットの宛先ポート番号がＳＮＭＰを示すポート番号（即ち「１６１」）であり、かつ、パケットのＳＮＭＰメッセージに含まれるＰＤＵ（Protocol Data Unit）タイプがGetRequest又はGetNextRequestを示す場合に、ステータス要求パケットであると判断する。
【００４７】
ステータス要求パケットでないと判断される場合（Ｓ２６でＮＯ）、Ｓ２８において、メインＣＰＵ２０は、Ｓ１２で受信されたパケットに応じた処理（例えば上記の通常の処理（印刷指示パケットに従った印刷処理等））を実行して、Ｓ１２に戻る。
【００４８】
一方、ステータス要求パケットであると判断される場合（Ｓ２６でＹＥＳ）、Ｓ３０において、メインＣＰＵ２０は、ＳＤＲＡＭ８０にパケット情報８４が記憶されているのか否かを判断する。パケット情報８４がＳＤＲＡＭ８０に記憶されていない場合（Ｓ３０でＮＯ）にＳ３４に進み、記憶されている場合（Ｓ３０でＹＥＳ）にＳ３２に進む。
【００４９】
Ｓ３２では、メインＣＰＵ２０は、Ｓ１２で受信されたステータス要求パケットの送信元のデバイスが、パケット情報８４として記憶されているデバイスと一致するのか否かを判断する。具体的には、メインＣＰＵ２０は、ステータス要求パケットに含まれる送信元のデバイスのＭＡＣアドレスと、パケット情報８４に含まれるＭＡＣアドレスと、が一致するのか否かを判断する。ここで、上述した２つのＭＡＣアドレスが一致する場合、Ｓ３２でＹＥＳと判断されＳ３４に進み、一方、上述した２つのＭＡＣアドレスが異なる場合、Ｓ３２でＮＯと判断されＳ３６に進む。
【００５０】
Ｓ３４では、メインＣＰＵ２０は、ＳＤＲＡＭ８０に、パケット情報８４を記憶させる。Ｓ３０でＮＯと判断された場合（即ちパケット情報８４が記憶されていない場合）に実行されるＳ３４では、メインＣＰＵ２０は、ステータス要求パケットの送信元デバイスのＭＡＣアドレスと、当該ステータス要求パケットの受信時刻と、を対応付けて、ＳＤＲＡＭ８０に記憶させる。一方、Ｓ３２でＹＥＳと判断された場合（即ちＳＤＲＡＭ８０に既にパケット情報８４が記憶されている場合）に実行されるＳ３４では、メインＣＰＵ２０は、パケット情報８４に含まれる前回のステータス要求パケットの受信時刻を、今回のステータス要求パケットの受信時刻に更新する。Ｓ３４が終了すると、Ｓ４６に進む。なお、メインＣＰＵ２０は、ＳＤＲＡＭ８０に記憶されているパケット情報８４に含まれるＭＡＣアドレスに対応するデバイス（例えばＰＣ１００）から予め決められた期間（例えば１分間）が経過しても、次のステータス要求が受信されない場合、ＳＤＲＡＭ８０に記憶されているパケット情報８４を削除する。
【００５１】
一方、上述したように、今回のＳ１２で受信されたステータス要求パケットの送信元のデバイス（以下では「ＰＣ２００」を例として説明する）が、パケット情報８４として記憶されているデバイス（以下では「ＰＣ１００」を例として説明する）と異なる場合（Ｓ３２でＮＯの場合）に、Ｓ３６の処理が実行される。Ｓ３６では、決定部２６は、ＳＤＲＡＭ８０に記憶されているパケット情報８４を用いて、ＰＣ１００から次回のステータス要求パケットを受信する時刻である次回パケット受信時刻を算出する。具体的には、決定部２６は、パケット情報８４に含まれる受信時刻に、ＳＤＲＡＭ８０に予め記憶されている待機期間（即ち３０秒）を加算することによって、次回パケット受信時刻を算出する。なお、多機能機１０のベンダは、待機期間（即ち３０秒）を、予めＳＤＲＡＭ８０に記憶させる。変形例では、メインＣＰＵ２０は、ＰＣ１００からステータス要求パケットが受信される間隔を用いて、待機期間を特定し、特定された待機期間をＳＤＲＡＭ８０に記憶させてもよい。
【００５２】
次いで、Ｓ３８では、Ｓ１２でＰＣ２００から受信されたステータス要求パケットの受信時刻が、Ｓ３６で算出されたＰＣ１００の次回パケット受信時刻とほぼ等しいのか否かを判断する。ここで「受信時刻がほぼ等しい」とは、例えば、ステータス要求パケットの受信時刻と次回パケット受信時刻との差分が、上記のタイムアウト時間よりも短い（例えば上記のタイムアウト時間の１０分の１（即ち０．２秒））状態を意味する。
【００５３】
なお、ＰＣ１００は、前回のステータス要求パケットに対する応答パケットを受信してから待機期間が経過する際に、次回のステータス要求パケットを送信する。従って、厳密には、決定部２６は、ＰＣ１００が前回のステータス要求パケットに対する応答パケットを受信した時刻に、待機期間を加算することによって、次回パケット受信時刻を算出しなければならない。しかしながら、多機能機１０がＰＣ１００からステータス要求パケットを受信してから、ＰＣが多機能機１０からステータス要求パケットに対する応答パケットを受信するまでの期間は、非常に短い。そのため、実質的に、ステータス要求パケットを多機能機１０が受信する時刻と、当該ステータス要求パケットに対する応答パケットをＰＣ１００が受信する時刻とは、ほぼ等しい。
【００５４】
ここで、上述した２つのパケット受信時刻がほぼ等しい場合、Ｓ３８でＹＥＳと判断されＳ４６に進み、一方、上述した２つのパケット受信時刻が略等しくない場合、Ｓ３８でＮＯと判断され、Ｓ４０に進む。Ｓ４０では、決定部２６は、Ｓ３６で算出された次回パケット受信時刻と、Ｓ１２におけるステータス要求パケットの受信時刻と、の差分（即ちＸ秒）が、上記のタイムアウト時間（即ち２秒間）よりも大きいのか否かを判断する。上記の差分（即ちＸ秒）がタイムアウト時間よりも大きい場合（Ｓ４０でＹＥＳ）、Ｓ４２において、決定部２６は、Ｓ１２で受信されたステータス要求パケットの応答パケットを送信する送信タイミングを、Ｓ１２で受信されたＰＣ２００のステータス要求パケットの受信時刻にタイムアウト時間（即ち２秒間）を加算した時刻に決定する。Ｓ４２が終了すると、Ｓ４６に進む。この構成によれば、ステータス要求パケットの送信元のデバイス（即ちＰＣ２００）が、ステータス要求パケットの応答を受信できないと判断することを回避することができる。
【００５５】
なお、ＰＣ２００は、ステータス要求パケットを送信してからタイムアウト時間が経過しても、応答パケットが多機能機１０から受信されない場合に、応答を受信できないと判断する。従って、厳密には、決定部２６は、Ｓ４０及びＳ４２において、以下の処理を実行すべきである。即ち、Ｓ４０の処理では、決定部２６は、上記の差分（即ちＸ秒）が、タイムアウト時間から多機能機１０とＰＣ２００との間の往復の通信時間を減算した特定の時間よりも大きいのか否かを判断すべきである。そして、Ｓ４２の処理では、決定部２６は、Ｓ１２で受信されたＰＣ２００のステータス要求パケットに対する応答パケットを送信する送信タイミングを、当該ステータス要求パケットの受信時刻に上記の特定の時間を加算した時刻に決定すべきである。しかしながら、多機能機１０とＰＣ２００との間の往復の通信時間は、タイムアウト時間と比較して、無視できるほど短い。このため、Ｓ４０及びＳ４２の処理のように、タイムアウト時間を用いて決定された送信タイミングで応答パケットが送信されても、ＰＣ２００がステータス要求パケットの応答を受信できないと判断するという事態は発生しない。
【００５６】
一方、Ｓ４０でＮＯの場合、即ち、Ｘ秒がタイムアウト時間よりも小さい場合、Ｓ４４において、決定部２６は、応答パケットの送信タイミングを、Ｓ１２で受信されたＰＣ２００のステータス要求パケットの受信時刻にＸ秒を加算した時刻に決定する。Ｓ４４が終了すると、Ｓ４６に進む。Ｓ３４、Ｓ４２、又はＳ４４の処理が終了した後、又はＳ３８でＹＥＳと判断された後、Ｓ４６では、送信制御部２４は、Ｓ１２のステータス要求パケットの応答として、多機能機１０の現在のステータス情報を含む応答パケットを、Ｓ１２のステータス要求パケットの送信元のデバイスに送信して、Ｓ１２に戻る。Ｓ３４の処理が実行され又はＳ３８でＹＥＳと判断された後に実行されるＳ４６では、送信制御部２４は、ステータス要求パケットに対応する応答パケットを生成すると直ちに（待機せずに）、応答パケットを送信する。この場合、ステータス要求パケットが受信されてから、応答パケットが送信されるまでの時間は、非常に短い。一方、Ｓ４２又はＳ４４の処理が実行された後に実行されるＳ３４では、送信制御部２４は、ステータス要求パケットに対応する応答パケットを生成した後に、Ｓ４２又はＳ４４で決定されたタイミングまで待機し、決定されたタイミングが到来すると、応答パケットを送信する。
【００５７】
なお、メインＣＰＵ２０の受信制御部２２が、Ｓ１２において、パケットを受信したと判断した場合（多機能機１０がレディ状態である間にパケットが受信された場合）には、メインＣＰＵ２０は、Ｓ１８でＮＯと判断し、Ｓ２６以降の処理を実行する。Ｓ２６以降の処理は、上記と同様である。
【００５８】
（本実施例の効果）
図３を参照して、各装置１０，１００，２００の動作と、本実施例の効果と、を説明する。なお、図３では、メインＣＰＵ２０がスリープ状態である状況で開始される。
【００５９】
１２：００：００では、ＰＣ１００は、Ｍ（Ｍは１以上の整数）番目のステータス要求パケットを、多機能機１０に送信する。Ｍ番目のステータス要求パケットが受信されると、移行制御部４８は、メインＣＰＵ２０を非スリープ状態に移行させる（図２のＳ２４）。メインＣＰＵ２０は、ＰＣ１００のＭＡＣアドレス（即ち「ＰＣ１００」）と対応付けて、受信時刻（即ち「１２：００：００」）を、記憶させる（即ちパケット情報８４）（図２のＳ３４）。送信制御部２４は、Ｍ番目のステータス要求パケットの応答として、Ｍ番目の応答パケットを生成する。送信制御部２４は、Ｍ番目の応答パケットが生成されると、直ちに、ＰＣ１００に送信する（図２のＳ４６）。
【００６０】
Ｍ番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００６１】
次いで、１２：００：２５では、ＰＣ２００は、Ｎ（Ｎは１以上の整数）番目のステータス要求パケットを、多機能機１０に送信する。Ｎ番目のステータス要求パケットが受信されると、移行制御部４８は、メインＣＰＵ２０を非スリープ状態に移行させる（図２のＳ２４）。
【００６２】
決定部２６は、パケット情報８４の受信時刻「１２：００：００」に、待機期間（即ち３０秒間）を加算して、次回パケット受信時刻（ＰＣ１００からＭ＋１番目のステータス要求パケットの受信時刻）（即ち「１２：００：３０」）を算出する（図２のＳ３６）。算出された次回パケット受信時刻と、Ｎ番目のステータス要求パケットの受信時刻（即ち「１２：００：２５」）と、の差分（即ち５秒間）が、タイムアウト時間（即ち２秒間）よりも長い（図２のＳ４０でＹＥＳ）。このため、決定部２６は、Ｎ番目のステータス要求パケットの応答として、Ｎ番目の応答パケットを送信する送信タイミングを、Ｎ番目のステータス要求パケットの受信時刻「１２：００：２５」にタイムアウト時間を加算した「１２：００：２７」に決定する（図２のＳ４２）。送信制御部２４は、Ｎ番目の応答パケットを、１２：００：２７に送信する（図２のＳ４６）。上記の構成によれば、多機能機１０は、Ｎ番目の応答パケットの送信タイミングを、Ｍ＋１番目のステータス要求パケットに対するＭ＋１番目の応答パケットの送信タイミングに近づけることができる。この結果、Ｎ＋１番目の要求パケットの受信タイミングを、Ｍ＋２番目の要求パケットの受信タイミングに近づけることができる。
【００６３】
Ｎ番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００６４】
次いで、１２：００：３０では、ＰＣ１００は、Ｍ＋１番目のステータス要求パケットを、多機能機１０に送信する。なお、厳密には、ＰＣ１００は、Ｍ番目の応答パケットを受信してから３０秒後に、Ｍ＋１番目のステータス要求パケットを送信する。しかしながら、ＰＣ１００は、Ｍ番目のステータス要求パケットを送信してから、Ｍ番目の応答パケットを受信するまでの期間が非常に短いため、実質的に、Ｍ番目のステータス要求パケットの送信からＭ＋１番目のステータス要求パケットの送信までの期間が、３０秒間であると言うことができる。
【００６５】
移行制御部４８は、Ｍ＋１番目のステータス要求パケットが受信されると、メインＣＰＵ２０を非スリープ状態に移行する（図２のＳ２４）。メインＣＰＵ２０は、パケット情報８４を記憶（図２のＳ３４）する。送信制御部２４は、Ｍ＋１番目のステータス要求パケットの応答として、Ｍ＋１番目の応答パケットを生成し、生成されたＭ＋１番目の応答パケットを、直ちに送信する（図２のＳ４６）。Ｍ＋１番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００６６】
１２：００：５７では、ＰＣ２００は、Ｎ＋１番目のステータス要求パケットを、多機能機１０に送信する。移行制御部４８は、Ｎ＋１番目のステータス要求パケットが受信されると、メインＣＰＵ２０を非スリープ状態に移行する（図２のＳ２４）。
【００６７】
決定部２６は、パケット情報８４の受信時刻「１２：００：３０」に、待機期間（３０秒）を加算して、次回パケット受信時刻（ＰＣ１００からＭ＋１番目のステータス要求パケットの受信時刻）（即ち「１２：０１：００」）を算出する（図２のＳ３６）。算出された次回パケット受信時刻と、Ｎ＋１番目のステータス要求パケットの受信時刻（即ち「１２：００：５７」）と、の差分（即ち３秒間）が、タイムアウト時間（即ち２秒間）よりも長い（図２のＳ４０でＹＥＳ）。このため、決定部２６は、Ｎ＋１番目のステータス要求パケットの応答として、Ｎ＋１番目の応答パケットを送信する送信タイミングを、Ｎ＋１番目のステータス要求パケットの受信時刻「１２：００：５７」にタイムアウト時間を加算した「１２：００：５９」に決定する（図２のＳ４２）。送信制御部２４は、Ｎ＋１番目の応答パケットを、１２：００：５９に送信する（図２のＳ４６）。上記の構成では、多機能機１０は、Ｎ＋１番目の応答パケットの送信タイミングを、Ｍ＋２番目の要求パケットに対するＭ＋２番目の応答パケットの送信タイミングに近づけることができる。この結果、Ｎ＋２番目の要求パケットの受信タイミングを、Ｍ＋３番目の要求パケットの受信タイミングに近づけることができる。
【００６８】
Ｎ＋１番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００６９】
時刻１２：０１：００において、ＰＣ１００は、Ｍ＋２番目のステータス要求パケットを、多機能機１０に送信する。Ｍ＋２番目のステータス要求パケットが受信されると、移行制御部４８は、メインＣＰＵ２０を非スリープ状態に移行する（図２のＳ２４）。メインＣＰＵ２０は、パケット情報８４を記憶（図２のＳ３４）する。送信制御部２４は、Ｍ＋２番目のステータス要求パケットの応答として、Ｍ＋２番目の応答パケットを生成し、生成されたＭ＋２番目の応答パケットを、直ちに送信する（図２のＳ４６）。Ｍ＋２番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００７０】
時刻１２：０１：２９において、ＰＣ２００は、Ｎ＋２番目のステータス要求パケットを、多機能機１０に送信する。Ｎ＋２番目のステータス要求パケットが受信されると、移行制御部４８は、メインＣＰＵ２０を非スリープ状態に移行する（図２のＳ２４）。
【００７１】
決定部２６は、パケット情報８４の受信時刻「１２：００：３０」に、待機期間（３０秒）を加算して、次回パケット受信時刻（ＰＣ１００からＭ＋３番目のステータス要求パケットの受信時刻）（即ち「１２：０１：３０」）を算出する（図２のＳ３６）。算出された次回パケット受信時刻と、Ｎ＋２番目のステータス要求パケットの受信時刻（即ち「１２：０１：２９」）と、の差分が、タイムアウト時間（即ち２秒間）よりも短い（図２のＳ４０でＮＯ）。このため、決定部２６は、Ｎ＋２番目のステータス要求パケットの応答として、Ｎ＋２番目の応答パケットを送信する送信タイミングを、Ｎ＋２番目のステータス要求パケットの受信時刻「１２：０１：２９」に、差分である１秒間を加算した「１２：０１：３０」に決定する（図２のＳ４４）。この構成では、ＰＣ２００への応答パケットの送信タイミングを、ＰＣ１００からのステータス要求パケットの受信タイミングを用いて決定している。この結果、ＰＣ２００からのステータス要求パケットの受信タイミングを、ＰＣ１００からのステータス要求パケットの受信タイミングに、適切に近づけることができる。
【００７２】
ＰＣ１００は、１２：０１：３０に、Ｍ＋３番目のステータス要求パケットを、多機能機１０に送信する。このタイミングは、Ｎ＋２番目の応答パケットを送信する送信タイミングに等しいため、メインＣＰＵ２０は、非スリープ状態に維持されている。送信制御部２４は、Ｍ＋３番目のステータス要求パケットの応答として、生成されたＭ＋３番目の応答パケットを、直ちに、ＰＣ１００に送信する（図２のＳ４６）。さらに、送信制御部２４は、Ｎ＋２番目の応答パケットの送信タイミング「１２：０１：３０」が到来したため、Ｎ＋２番目の応答パケットを、ＰＣ２００に送信する（図２のＳ４６）。この結果、Ｍ＋３番目の応答パケットの送信タイミングと、Ｎ＋２番目の応答パケットの送信タイミングと、をほぼ等しくさせることができる。なお、実際には、送信制御部２４は、応答パケットを順番に送信するために、送信タイミングが厳密的な意味で一致しない。
【００７３】
Ｍ＋２番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００７４】
１２：０２：００になると、受信制御部４２は、ＰＣ１００及びＰＣ２００のそれぞれから、Ｍ＋４番目のステータス要求パケットと、Ｎ＋３番目のステータス要求パケットと、を受信する。この構成によれば、多機能機１０は、ＰＣ１００からのステータス要求パケットとＰＣ２００からのステータス要求パケットとを、ほぼ等しいタイミングで受信することができる。
【００７５】
なお、「ほぼ等しいタイミングで受信する」とは、例えば、例えば、ステータス要求パケットの受信時刻とＳ３６で算出された次回パケット受信時刻との差分が、上記のタイムアウト時間よりも短い（例えば上記のタイムアウト時間の１０分の１（即ち０．２秒））状態を意味する。あるいは、「ほぼ等しいタイミングで受信する」とは、図２のＳ１２で受信されたステータス要求パケットについて、図２のＳ４６の処理が実行された後、図２のＳ１２に戻るまでの期間よりも短い状態を意味する。
【００７６】
また、多機能機１０は、ＰＣ２００からのステータス要求パケットの受信タイミングを、ＰＣ１００からのステータス要求パケットの受信タイミングに、近づけることによって、メインＣＰＵ２００がスリープ状態から非スリープ状態に移行される頻度を低くすることができる。この結果、多機能機１０の省電力を低減することができる。特に、図２のＳ１２においてＰＣ１００から受信されたステータス要求パケットについての応答パケットの送信（図２のＳ４６）後、図２のＳ１２に戻るまでの間に、ＰＣ２００からのステータス要求パケットが受信されている場合、Ｓ１２でＹＥＳと判断され、メインＣＰＵ２０がスリープ状態に移行されることを回避することができる。
【００７７】
本実施例では、多機能機１０は、ＰＣ２００からのステータス要求パケットの受信から応答パケットの送信までの時間が、ＰＣ１００からの要求パケットの受信から応答パケットの送信までの時間よりも長くなるようなタイミングで、ＰＣ２００からの応答パケットを送信する。この構成によれば、ＰＣ２００からのステータス要求パケットに対する応答パケットの送信タイミングを、ＰＣ２００からのステータス要求パケットの次に受信されるＰＣ１００からのステータスの要求パケットに対する応答パケットの送信タイミングに近づけることができる。この結果、ＰＣ２００からのステータス要求パケットの受信タイミングを、ＰＣ１００からのステータス要求パケットの受信タイミングに近づける。
【００７８】
（対応関係）
上記の多機能機１０、ＰＣ１００及びＰＣ２００のそれぞれが、「通信装置」、「第１の装置」及び「第２の装置」の一例である。ＰＣ１００から送信されるステータス要求パケットが「第１の要求パケット」の一例であり、ＰＣ２００から送信されるステータス要求パケットが「第２の要求パケット」の一例である。メインＣＰＵ２０とサブＣＰＵ４０とが「プロセッサ」の一例である。２個のＰＣＵ２０，４０が共に非スリープ状態である状態が「高消費状態」の一例であり、メインＰＣＵ２０がスリープ状態であり、サブＣＰＵ４０が非スリープ状態である状態が「低消費状態」の一例である。
【００７９】
以上、本発明の実施形態について詳細に説明したが、これらは例示に過ぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。
【００８０】
（変形例）
（１）上記の実施例では、多機能機１０は、２個のＣＰＵ２０，４０を備えるが、これに代えて、多機能機１０は、メインＣＰＵ２０のみを備えていてもよい。この場合、メインＣＰＵ２０に供給されるクロック信号の周波数が低い状態と高い状態とに移行してもよい。クロック信号の周波数が高い状態では、メインＣＰＵ２０の消費電力が比較的に高く、クロック信号の周波数が低い状態では、メインＣＰＵ２０の消費電力が比較的に低い。この変形例では、メインＣＰＵ２０が「プロセッサ」の一例であり、メインＣＰＵ２０に供給されるクロック信号の周波数が高い状態が「高消費状態」の一例であり、メインＣＰＵ２０に供給されるクロック信号の周波数が低い状態が「低消費状態」の一例である。
【００８１】
（２）上記の実施例では、決定部２６は、ＳＤＲＡＭ８０に記憶されているパケット情報８４を用いて、応答パケットの送信タイミングを決定している（図２のＳ３６からＳ４４）。しかしながら、決定部２６は、ＰＣ１００からのステータス要求パケットの受信タイミングと、ＰＣ２００からのステータス要求パケットの受信タイミングと、が予め決められた間隔（例えば１秒間）以下となるまで、ＰＣ２００からのステータス要求パケットに対する応答パケットの送信タイミングを、ステータス要求パケットの受信タイミングから予め決められた時間（例えば１秒間）だけ加算したタイミングに決定してもよい。本変形例も、「決定部は、第２の要求パケットの受信から当該第２の要求パケットに対する第２の応答パケットの送信までの時間が、第１の要求パケットの受信から当該第１の要求パケットに対する第１の応答パケットの送信までの時間よりも長くなるように、送信タイミングを決定する」という構成に含まれる。
【００８２】
（３）上記の実施例では、メインＣＰＵ２０がプログラム８２に従って処理を実行することによって、決定部２６の機能が実現されている。しかしながら、サブＣＰＵ４０がプログラム６２に従って処理を実行することによって、決定部の機能が実行されてもよい。この場合、図２のＳ２６、Ｓ３０からＳ４４までの処理を、サブＣＰＵ４０が実行してもよい。
【００８３】
（４）上記の実施例では、メインＣＰＵ２０が非スリープ状態である間にステータス要求パケットが受信される場合と、メインＣＰＵ２０がスリープ状態である間にステータス要求パケットが受信される場合と、の両方の場合において、決定部２６は、送信タイミングを決定している（図２のＳ４２及びＳ４４）。しかしながら、メインＣＰＵ２０が非スリープ状態である間にステータス要求パケットが受信される場合には、決定部２６は、送信タイミングを決定せず、直ちに、応答パケットを送信してもよい。この構成によれば、メインＣＰＵ２０が非スリープ状態である間にステータス要求パケットが受信される場合には、応答パケットの送信タイミングの決定処理を実行しなくて済む。
【００８４】
（５）上記の実施例では、決定部２６は、パケット情報８４に記憶されているデバイス（例えばＰＣ１００）への応答パケットの送信タイミングを決定しない。しかしながら、決定部２６は、パケット情報８４に記憶されているデバイス（例えばＰＣ１００）への応答パケットの送信タイミングを決定してもよい。即ち、決定部２６は、受信される全てのステータス要求パケットへの応答パケットの送信タイミングを決定してもよい。
【００８５】
（６）多機能機１０に接続されるＰＣの個数に限りはない。多機能機１０は、多数個のＰＣからのステータス要求パケットの受信タイミングが、パケット情報８４に記憶されているＰＣ１００のステータス要求パケットの受信タイミングに近づくように、多数個のＰＣへの応答パケットの送信タイミングを決定してもよい。さらに、多数個のＰＣが多機能機１０に接続される場合、多機能機１０は、１個以上のＰＣのステータス要求パケットの受信時刻を、パケット情報８４に記憶してもよい。そして、多機能機１０は、パケット情報８４に記憶されているＰＣ以外の多数個のＰＣのステータス要求パケットのそれぞれの受信タイミングが、パケット情報８４に含まれる１個以上ＰＣのいずれかのＰＣに対応する受信タイミングに近づくように、応答パケットの送信タイミングを決定してもよい。例えば、多機能機１０に１０個のＰＣが接続されている場合、多機能機１０は、５個のＰＣを第１グループとして、他の５個のグループを第２グループとして分類してもよい。多機能機１０は、第１グループの中の１個の基準ＰＣの受信タイミングに、第１グループの中の他の４個のＰＣの受信タイミングを近づけてもよい。同様に、多機能機１０は、第２グループの中の１個の基準ＰＣの受信タイミングに、第２グループの中の他の４個のＰＣの受信タイミングを近づけてもよい。この場合、第１グループの中の上記の基準ＰＣの受信タイミングと、第２グループの中の上記の基準ＰＣの受信タイミングと、は一致しなくてもよい。
【００８６】
（７）上記の実施例では、決定部２６は、ＰＣ１００からのステータス要求パケットの受信時刻と待機期間とを用いて、ＰＣ２００への応答パケットの送信タイミングを決定する（図２のＳ４０）。しかしながら、決定部２６は、多機能機１０がＰＣ１００からのステータス要求パケットに対する応答パケットの送信タイミング、あるいは、ＰＣ１００がステータス要求パケットに対する応答パケットの受信タイミングを用いて、ＰＣ２００への応答パケットの送信タイミングを決定してもよい。本変形例では、多機能機１０がＰＣ１００からのステータス要求パケットに対する応答パケットの送信タイミング、あるいは、ＰＣ１００がステータス要求パケットに対する応答パケットの受信イミングが、「第１の要求パケットの受信に関するタイミング」の一例である。
【００８７】
（８）上記の実施例では、メインＣＰＵ２０がプログラム８２に従って処理を実行することによって、各部２２〜２６が実現されるが、各部２２〜２６の少なくとも１個は、論理回路等のハードウェアで実現されてもよい。また、サブＣＰＵ４０がプログラム６２に従って処理を実行することによって、各部４２、４８が実現されるが、各部４２、４８の少なくとも１個は、論理回路等のハードウェアで実現されてもよい。
【００８８】
（８）「通信装置」は、多機能機でなくてもよく、ＰＣ、プリンタ、サーバ、ＰＤＡ等の通信装置であってもよい。
【００８９】
また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
【符号の説明】
【００９０】
２：ネットワークシステム、１０：多機能機、２０：メインＣＰＵ、２２：受信制御部、２４：送信制御部、２６：決定部、４０：サブＣＰＵ、４２：受信制御部、４８：移行制御部、６０：ＳＲＡＭ、７０：フラッシュメモリ、８０：ＳＤＲＡＭ、１００，２００：ＰＣ
【技術分野】
【０００１】
本明細書では、外部装置から送信される要求パケットに対する応答パケットを送信する通信装置を開示する。
【背景技術】
【０００２】
特許文献１には、クライアントコンピュータに接続されるＭＦＰ（多機能周辺装置）が開示されている。ＭＦＰは、クライアントコンピュータからイベント記述子列が受信されると、イベント記述子列に対する応答として、成功メッセージ又はエラーメッセージを、クライアントコンピュータに送信する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−１５４８２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記の特許文献１の技術では、例えば、ＭＦＰが、複数個のクライアントコンピュータのそれぞれから、イベント記述子列を繰り返し受信する状況では、イベント記述子列の受信タイミングにばらつきが生じる可能性がある。この場合、ＭＦＰは、効率的な処理を実行することができない可能性がある。
【０００５】
本明細書では、複数個の装置のそれぞれから要求パケットが繰り返し受信される状況において、複数個の装置間の要求パケットの受信タイミングを近づけ得る技術を提供する。
【課題を解決するための手段】
【０００６】
本明細書によって開示される技術は、第１の装置と第２の装置とのそれぞれに接続される通信装置である。第１の装置は、第１の要求パケットを通信装置に送信して、第１の要求パケットに対する第１の応答パケットを、通信装置から受信する処理を繰り返し実行する。第１の装置は、第１の応答パケットを受信してから所定の期間が経過する際に、第１の要求パケットを新たに送信する。第２の装置は、第２の要求パケットを通信装置に送信して、第２の要求パケットに対する第２の応答パケットを、通信装置から受信する処理を繰り返し実行する。第２の装置は、第２の応答パケットを受信してから上記の所定の期間が経過する際に、第２の要求パケットを新たに送信する。通信装置は、受信制御部と、送信制御部と、決定部と、を備える。受信制御部は、第１の装置から第１の要求パケットを受信し、第２の装置から第２の要求パケットを受信する。送信制御部は、第１の要求パケットに対する第１の応答パケットを第１の装置に送信し、第２の要求パケットに対する第２の応答パケットを第２の装置に送信する。決定部は、第２の応答パケットを第２の装置に送信するための送信タイミングを決定する。決定部は、第２の要求パケットの受信から当該第２の要求パケットに対する第２の応答パケットの送信までの期間が、第１の要求パケットの受信から当該第１の要求パケットに対する第１の応答パケットの送信までの期間よりも長くなるように、送信タイミングを決定する。送信制御部は、決定済みの送信タイミングで、第２の応答パケットを第２の装置に送信する。
【０００７】
上記の構成では、通信装置は、第２の要求パケットの受信から第２の応答パケットの送信までの期間が、第１の要求パケットの受信から第１の応答パケットの送信までの期間よりも長くなるようなタイミングで、第２の応答パケットを送信する。この構成によれば、特定の第２の要求パケットに対する第２の応答パケットの送信タイミングを、上記の特定の第２の要求パケットの次に受信される特定の第１の要求パケットに対する第１の応答パケットの送信タイミングに近づけ得る。第１の装置と第２の装置との両者は、応答パケットを受信してから所定の期間が経過すると、次の要求パケットを送信する。このため、上記の特定の第２の要求パケットの次に受信される第２の要求パケットの受信タイミングを、上記の特定の第１の要求パケットの次に受信される第１の要求パケットの受信タイミングに近づけ得る。
【０００８】
なお、上記の通信装置を実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムが記憶された記憶媒体も、新規で有用である。また、上記の通信装置と上記の第１及び第２の装置とを含むシステムも新規で有用である。
【図面の簡単な説明】
【０００９】
【図１】ネットワークシステムの構成を示す。
【図２】応答処理のフローチャートを示す。
【図３】各装置の動作を表わすシーケンス図を示す。
【発明を実施するための形態】
【００１０】
図１に示すように、ネットワークシステム２は、ＰＣ１００，２００と、多機能機（即ちＰＣ１００，２００の周辺機器）１０と、を備える。各装置１０，１００，２００は、ＬＡＮ４を介して、相互に通信可能である。
【００１１】
（多機能機１０の構成）
図１に示すように、多機能機１０は、ＡＳＩＣ（Application Specific Integrated Circuit）１２、フラッシュメモリ７０、ＳＤＲＡＭ８０、ネットワークインターフェイス９０、表示パネル９２、及び、画像形成部９４を備える。
【００１２】
ＡＳＩＣ１２は、メインＣＰＵ２０、メイン用クロック回路３０、サブＣＰＵ４０、サブ用クロック回路５０、ＳＲＡＭ６０、ＳＤＲＡＭ制御回路６４、及び、ＭＡＣコントローラ６６を備える。
【００１３】
メインＣＰＵ２０は、ＳＤＲＡＭ８０に記憶されているプログラム８２に従って様々な処理を実行する。これにより、受信制御部２２と送信制御部２４と決定部２６との各機能が実現される。メイン用クロック回路３０は、メインＣＰＵ２０にクロック信号を供給する。メイン用クロック回路３０からメインＣＰＵ２０にクロック信号が供給されている間は、メインＣＰＵ２０は非スリープ状態である。メインＣＰＵ２０にクロック信号が供給されていない間は、メインＣＰＵ２０はスリープ状態である。メインＣＰＵ２０のスリープ状態は、メインＣＰＵ２０の非スリープ状態と比較して、消費電力が低い状態である。メイン用クロック回路３０は、サブＣＰＵ４０によって制御される。即ち、サブＣＰＵ４０によって、メインＣＰＵ２０へのクロック信号の供給及び停止が制御される。
【００１４】
サブＣＰＵ４０は、ＳＲＡＭ６０に記憶されているプログラム６２に従って様々な処理を実行する。これにより、受信制御部４２と移行制御部４８との各機能が実現される。サブ用クロック回路５０は、サブＣＰＵ４０にクロック信号を供給する。サブ用クロック回路５０のクロック信号の周波数は、メイン用クロック回路３０のクロック信号の周波数よりも低い。従って、メインＣＰＵ２０を駆動するための消費電力と比べて、サブＣＰＵ４０を駆動するための消費電力は低い。なお、メインＣＰＵ２０の処理速度は、サブＣＰＵ４０の処理速度よりも速い。サブ用クロック回路５０は、多機能機１０の電源がＯＮにされるとサブＣＰＵ４０にクロック信号を供給し、多機能機１０の電源がＯＦＦにされるとクロック信号を停止する。即ち、サブＣＰＵ４０は、多機能機１０の電源がＯＮされている間、クロック信号が供給されている状態（非スリープ状態）で維持される。変形例では、サブＣＰＵ４０は、メインＣＰＵ２０が非スリープ状態である間、スリープ状態であってもよい。即ち、サブ用クロック回路５０は、メインＣＰＵ２０が非スリープ状態である間、サブＣＰＵ４０へのクロック信号を停止してもよい。
【００１５】
ＳＲＡＭ６０は、各ＣＰＵ２０，４０からアクセス可能である。多機能機１０の電源がＯＮされると、メインＣＰＵ２０は、フラッシュメモリ７０内の圧縮されたプログラム７２を展開して、展開済みのプログラム６２をＳＲＡＭ６０に記憶する。
【００１６】
ＳＤＲＡＭ制御回路６４は、サブＣＰＵ４０からの指示に従って、ＳＤＲＡＭ８０に対するクロック信号の供給の開始又は停止をして、消費電力が比較的に高い通常動作モードと、消費電力が比較的に低いセルフリフレッシュモードと、の間でＳＤＲＡＭ８０の状態を移行させる。
【００１７】
ＭＡＣコントローラ６６は、ネットワークインターフェイス９０に接続されている。ＭＡＣコントローラ６６は、ＬＡＮ４を介して、ネットワークインターフェイス９０でパケットが受信されると、メインＣＰＵ２０又はサブＣＰＵ４０の割込コントローラ（図示省略）にパケット割込要求信号を供給する。
【００１８】
フラッシュメモリ７０は、ＡＳＩＣ１２の外部に設けられている。フラッシュメモリ７０は、各ＣＰＵ２０，４０からアクセス可能である。フラッシュメモリ７０は、各ＣＰＵ２０，４０によって実行されるプログラム６２，８２が圧縮された状態のプログラム７２を記憶している。
【００１９】
ＳＤＲＡＭ８０は、メインＣＰＵ２０からアクセス可能である。ＳＤＲＡＭ８０は、ＳＲＡＭ６０よりもメモリの総容量が大きく、各ＣＰＵ２０，４０がアクセス（読み出し、書き込み）可能な速度が高速である。このため、ＳＤＲＡＭ８０の消費電力は、ＳＲＡＭ６０の消費電力と比べて高い。ＳＤＲＡＭ８０は、ＳＤＲＡＭ制御回路６４によって制御され、通常動作モードとセルフリフレッシュモードとの間で状態が移行する。また、ＳＤＲＡＭ８０は、パケット情報８４を記憶することができる。パケット情報８４とは、ステータス要求パケットの受信時刻と、当該ステータス要求パケットの送信元のデバイス（例えばＰＣ１００）のＭＡＣアドレスと、が対応付けられた情報である（図３参照）。
【００２０】
表示パネル９２は、メインＣＰＵ２０からの指示に従って、情報を表示する。表示パネル９２には、ユーザからの操作を受け付けるためのタッチボタンが配置される。画像形成部９４は、インクジェット方式又はレーザ方式の画像形成機構を備え、メインＣＰＵ２０からの指示に従って、外部のデバイス（例えばＰＣ１００，２００）から受信される印刷データによって表わされる画像を、印刷用紙に印刷する。
【００２１】
（多機能機１０の状態移行）
多機能機１０の状態は、レディ状態とスリープ状態との間で移行する。多機能機１０の電源がＯＮされると、多機能機１０は、レディ状態となる。
【００２２】
（レディ状態）
多機能機１０がレディ状態である場合、２個のＣＰＵ２０，４０は非スリープ状態（２個のクロック回路３０，５０からそれぞれクロック信号が供給されている状態）であり、２個のＲＡＭ６０，８０は通常動作モードである。この状態では、メインＣＰＵ２０は、通常の処理を実行することができる。上記の通常の処理は、印刷指示パケットに従った印刷処理、ユーザの表示パネル９２への操作に従った表示処理等を含む。なお、メインＣＰＵ２０は、多機能機１０がレディ状態である場合、ＳＤＲＡＭ８０に、レディ状態を示す状態変数を記憶させる。
【００２３】
（スリープ状態）
多機能機１０は、サブＣＰＵ４０が後述する図２のＳ１６等の処理を実行することによって、レディ状態からスリープ状態に移行する。多機能機１０がスリープ状態である場合、メインＣＰＵ２０はスリープ状態であり（メイン用クロック回路３０からのクロック信号が停止されている状態）、サブＣＰＵ４０は非スリープ状態であり（サブ用クロック回路５０からのクロック信号が供給されている状態）、ＳＲＡＭ６０は通常動作モードであり、ＳＤＲＡＭ８０はセルフリフレッシュモードである。多機能機１０がスリープ状態であって、メインＣＰＵ２０が上記の通常の処理（印刷処理、表示処理等）を実行すべき場合には、多機能機１０は、レディ状態に移行する。
【００２４】
なお、メインＣＰＵ２０は、多機能機１０がレディ状態からスリープ状態に移行される際に、ＳＤＲＡＭ８０内の状態変数を、ＳＲＡＭ６０に移動させる。サブＣＰＵ４０は、多機能機１０がスリープ状態に移行されると、ＳＲＡＭ６０内の状態変数を、スリープ状態を示す状態変数に変更する。さらに、サブＣＰＵ４０は、多機能機１０がスリープ状態からレディ状態に移行される際に、ＳＲＡＭ６０内の状態変数を、ＳＤＲＡＭ８０に移動させる。メインＣＰＵ２０は、多機能機１０がレディ状態に移行されると、ＳＤＲＡＭ８０内の状態変数を、レディ状態を示す状態変数に変更する。
【００２５】
（ＰＣ１００の構成）
ＰＣ１００には、多機能機１０のステータスを監視するためのステータス監視プログラム（例えばステータスモニタ）がインストールされている。ユーザは、ＰＣ１００を操作することによって、ステータス監視プログラムを起動させることができる。ＰＣ１００は、ステータス監視プログラムが起動されると、多機能機１０から多機能機１０のステータス情報を取得する。
【００２６】
具体的には、ＰＣ１００は、ステータス監視プログラムが起動されると、ステータス要求パケットを、多機能機１０に送信する。なお、ステータス要求パケットは、ＰＣ１００のＭＡＣアドレスを含む。ＰＣ１００は、ステータス要求パケットの応答として、多機能機１０からステータス情報を含む応答パケットを受信する。ＰＣ１００は、受信された応答パケットに従って、ステータス情報をＰＣ１００の表示部に表示させる。ＰＣ１００は、応答パケットの受信から予め決められた待機期間（本実施例では３０秒間）が経過する際に、ステータス要求パケットを、多機能機１０に新たに送信する。即ち、ＰＣ１００は、ステータス監視プログラムが起動されている間、ステータス要求パケットの送信処理と、応答パケットの受信処理と、を繰り返し実行する。
【００２７】
なお、ステータス情報は、多機能機１０の状態（スリープ状態又はレディ状態）、印刷用紙の有無、トナーの有無、及び、実行中の印刷のエラー情報（例えば用紙詰まり、画像形成部の故障等）を示す情報を含む。
【００２８】
ＰＣ１００は、およそ３０秒間隔（上記の待機期間）で、多機能機１０からステータス情報を繰り返し取得する。これにより、ＰＣ１００のユーザは、多機能機１０の最新のステータスを確認することができる。この構成によれば、例えば、ＰＣ１００のユーザは、多機能機１０の画像形成部９４に印刷処理を実行させている場合に、印刷用紙が無くなったことを早期に知ることができる。また、ＰＣ１００がステータス情報を多機能機１０から定期的に取得するため、ＰＣ１００のユーザは、多機能機１０のステータス情報を、ＰＣ１００に取得させるための操作を実行しなくて済む。
【００２９】
ＰＣ１００は、ステータス要求パケットを多機能機１０に送信してから、２秒間（以下では「タイムアウト時間」と呼ぶ）経過しても、応答パケットが多機能機１０から受信されない場合、応答パケットを受信できないと判断する。この場合、ＰＣ１００は、再度、ステータス要求パケットを、多機能機１０に送信する。ＰＣ１００は、予め決められた個数のステータス要求パケットを送信しても、タイムアウト時間内に応答パケットが受信されない場合、通信エラーを示す情報を、ＰＣ１００の表示部に表示させる。これにより、ＰＣ１００のユーザは、多機能機１０とＰＣ１００とが通信できないことを知ることができる。
【００３０】
なお、ＰＣ１００は、ステータス要求パケットを多機能機１０に送信してからタイムアウト時間が経過した後に、応答パケットが多機能機１０から受信されたとしても、応答パケットに従ったステータス情報を、ＰＣ１００の表示部に表示させない。
【００３１】
ＰＣ２００は、ＰＣ１００と同様の構成を備える。即ち、ＰＣ２００は、ステータス監視プログラムが起動されると、ステータス要求パケットを、多機能機１０に送信する送信処理と、多機能機１０から応答パケットを受信する受信処理と、を繰り返し実行する。
【００３２】
（メインＣＰＵ２０及びサブＣＰＵ４０が実行する処理）
次いで、図２を参照して、メインＣＰＵ２０及びサブＣＰＵ４０が実行する処理の内容について説明する。本処理は、多機能機１０の電源がＯＮされている間、繰り返し実行される。多機能機１０の電源がＯＮされたタイミングでは、多機能機１０はレディ状態である。即ち、多機能機１０の電源がＯＮされたタイミングでは、メインＣＰＵ２０が本処理を実行する。
【００３３】
Ｓ１２では、受信制御部２２は、ＬＡＮ４を介して、パケットが受信されたのか否かを判断する。ネットワークインターフェイス９０でパケットが受信される場合、ＭＡＣコントローラ６６は、パケット割込要求信号を、メインＣＰＵ２０に供給する。受信制御部２２は、パケット割込要求信号を取得すると、受信されたパケットを、ネットワークインターフェイス９０からＳＤＲＡＭ８０に移動させる。Ｓ１２では、受信制御部２２は、ＳＤＲＡＭ８０に受信済みのパケットが存在するのか否かを判断する。
【００３４】
パケットが受信されていない場合（Ｓ１２でＮＯ）、Ｓ１４において、メインＣＰＵ２０は、メインＣＰＵ２０をスリープ状態に移行可能（即ち多機能機１０をスリープ状態に移行可能）であるのか否かを判断する。例えば、メインＣＰＵ２０は、以下の（１）〜（５）の条件を含む複数個の条件の全てでＮＯと判断される場合に、スリープ状態に移行可能（Ｓ１４でＹＥＳ）と判断し、複数個の条件のうち、少なくとも１個の条件でＹＥＳと判断される場合に、スリープ状態に移行不可能（Ｓ１４でＮＯ）と判断する。
【００３５】
上記の複数個の条件は、（１）多機能機１０がパケットを外部に送信中であるのか否か、（２）未処理パケットがＳＤＲＡＭ８０に記憶されているのか否か、（３）多機能機１０にＴＣＰ接続しているデバイス（例えばＰＣ１００）があるのか否か、（４）多機能機１０が起動又はシャットダウンのための処理を実行しているのか否か、（５）ネットワークの負荷が高いのか否か、を含む。
【００３６】
例えば、メインＣＰＵ２０がＰＣ１００等からのパケットに対する応答を送信している場合には、上記の（１）でＹＥＳと判断される。例えば、多機能機１０がＷｅｂサーバ機能を有しており、ＰＣ１００が多機能機１０のＷｅｂサーバにＴＣＰ接続中である場合には、上記の（３）でＹＥＳと判断される。例えば、Ｓ１４の処理を実行する直前の所定の期間に受信されたパケット数が所定の個数を超えている場合には、多機能機１０が処理すべきパケットを受信する可能性が高いために、上記の（５）でＹＥＳと判断される。従って、ここで示されるように、上記の（１）〜（５）の条件のうち、少なくとも１個の条件でＹＥＳと判断される場合に、スリープ状態に移行不可能（Ｓ１４でＮＯ）と判断する。
【００３７】
一方、上記の（１）〜（５）の条件の全てでＮＯと判断される場合に、メインＣＰＵ２０がスリープ状態に移行可能（Ｓ１４でＹＥＳ）と判断される。このＳ１４でＹＥＳの場合、Ｓ１６において、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる。具体的には、移行制御部４８は、メイン用クロック回路３０にクロック供給の停止を指示する。この結果、メインＣＰＵ２０は、非スリープ状態からスリープ状態に移行する。なお、Ｓ１６では、さらに、移行制御部４８は、ＳＤＲＡＭ８０を通常動作モードからセルフリフレッシュモードに移行させる。これにより、多機能機１０は、スリープ状態となる。なお、ＳＤＲＡＭ８０がセルフリフレッシュモードである間は、ＳＤＲＡＭ８０に情報を書き込んだり、ＳＤＲＡＭ８０から情報を読み込んだりすることができない。例えば、ネットワークインターフェイス９０で受信されたパケットをＳＤＲＡＭ８０に記憶させることができない。
【００３８】
なお、メインＣＰＵ２０は、Ｓ１６でスリープ状態に移行する前に、多機能機１０をレディ状態からスリープ状態に移行するために、以下の処理を実行する。即ち、メインＣＰＵ２０は、代理応答情報を、ＳＤＲＡＭ８０からＳＲＡＭ６０に移動させる。代理応答情報は、メインＣＰＵ２０がスリープ状態である間に受信されたパケットに従った処理を、サブＣＰＵ４０が実行するための情報（例えば多機能機１０のＩＰアドレス、ＭＡＣアドレス、ノード名等）を含む。また、メインＣＰＵ２０は、ＬＡＮ４を介して受信されるパケットを記憶するためのＲＡＭを、ＳＤＲＡＭ８０からＳＲＡＭ６０に切り替える。続いて、メインＣＰＵ２０は、サブＣＰＵ４０以外からの割込要求をマスク（禁止）する。次いで、メインＣＰＵ２０は、サブＣＰＵ４０に処理を開始させるための開始信号を、サブＣＰＵ４０に供給する。サブＣＰＵ４０は、開始信号が取得されると、Ｓ１６の処理を実行する。なお、メインＣＰＵ２０は、ＷＡＩＴ命令を実行する。ＷＡＩＴ命令が実行されると、メインＣＰＵ２０は、サブＣＰＵ４０から割込要求信号が供給されるまで待機する実行停止状態となる。
【００３９】
Ｓ１６が終了すると、Ｓ１２に戻る。即ち、メインＣＰＵ２０がスリープ状態である間に、Ｓ１２が実行される。この場合、サブＣＰＵ４０の受信制御部４２がＳ１２を実行する。Ｓ１２でＮＯの場合、Ｓ１４において、メインＣＰＵ２０が既にスリープ状態であるために、ＮＯと判断され、Ｓ１２に戻る。
【００４０】
以下のＳ１８の処理では、Ｓ１２において、サブＣＰＵ４０の受信制御部４２が、パケットが受信されたと判断する場合（メインＣＰＵ２０がスリープ状態である間にパケットが受信される場合）について説明する。
【００４１】
Ｓ１８では、サブＣＰＵ４０は、メインＣＰＵ２０がスリープ状態であるのか否かを判断する。具体的には、サブＣＰＵ４０は、ＳＲＡＭ６０内の状態変数を確認して、多機能機１０がスリープ状態であるのか否かを判断することによって、メインＣＰＵ２０がスリープ状態であるのか否かを判断する。この場合では、Ｓ１８にてＹＥＳと判断され、次いで、Ｓ２０では、サブＣＰＵ４０は、Ｓ１２で受信されたパケットを解析することによって、サブＣＰＵ４０自身がパケットに従った処理を実行することができるのか否かを判断する。
【００４２】
例えば、サブＣＰＵ４０は、ＳＲＡＭ６０内の代理応答情報を用いて、Ｓ１２で受信されたパケットに従った応答処理を実行可能であるのか否かを判断する。サブＣＰＵ４０が代理して実行可能な応答処理は、例えば、ＰＩＮＧに対する応答、ＡＲＰ（Address Resolution Protocol）のパケットに対する応答等を含む。なお、Ｓ１２で受信されたパケットがＰＣ１００，２００からのステータス要求パケットである場合、サブＣＰＵ４０は、サブＣＰＵ４０自身がパケットに従った処理を実行することができないと判断する。
【００４３】
Ｓ２０でＹＥＳの場合、Ｓ２２において、サブＣＰＵ４０は、Ｓ１２で受信されたパケットに従った処理を実行して、Ｓ１２に戻る。Ｓ２０でＮＯの場合、Ｓ２４において、移行制御部４８は、メインＣＰＵ２０をスリープ状態から非スリープ状態に移行する。具体的には、移行制御部４８は、メイン用クロック回路３０に、メインＣＰＵ２０にクロック供給を開始するよう指示する。この結果、メインＣＰＵ２０にクロックが供給され、メインＣＰＵ２０がスリープ状態から非スリープ状態に移行する。移行制御部４８は、メインＣＰＵ２０に割込要求信号を供給する。
【００４４】
サブＣＰＵ４０は、さらに、ＳＤＲＡＭ８０をセルフリフレッシュモードから通常動作モードに移行させる処理、外部デバイスからの受信パケットの記憶先をＳＲＡＭ６０からＳＤＲＡＭ８０に切り替える処理、ＳＲＡＭ６０内の情報をＳＤＲＡＭ８０に移動させる処理等を実行する。
【００４５】
メインＣＰＵ２０は、サブＣＰＵ４０から割込要求信号が供給されると、ＷＡＩＴ命令を解除する。メインＣＰＵ２０は、ＳＲＡＭ６０に記憶されている未処理のパケットを、ＳＤＲＡＭ８０に移動させる。
【００４６】
Ｓ２６において、メインＣＰＵ２０は、Ｓ１２で受信されたパケットが、ステータス要求パケットであるのか否かを判断する。具体的には、メインＣＰＵ２０は、Ｓ１２で受信されたパケットが、ＳＮＭＰ（Simple Network Management Protocol）のオブジェクトデータを要求するパケットであるのか否かを判断する。例えば、メインＣＰＵ２０は、パケットの宛先ポート番号がＳＮＭＰを示すポート番号（即ち「１６１」）であり、かつ、パケットのＳＮＭＰメッセージに含まれるＰＤＵ（Protocol Data Unit）タイプがGetRequest又はGetNextRequestを示す場合に、ステータス要求パケットであると判断する。
【００４７】
ステータス要求パケットでないと判断される場合（Ｓ２６でＮＯ）、Ｓ２８において、メインＣＰＵ２０は、Ｓ１２で受信されたパケットに応じた処理（例えば上記の通常の処理（印刷指示パケットに従った印刷処理等））を実行して、Ｓ１２に戻る。
【００４８】
一方、ステータス要求パケットであると判断される場合（Ｓ２６でＹＥＳ）、Ｓ３０において、メインＣＰＵ２０は、ＳＤＲＡＭ８０にパケット情報８４が記憶されているのか否かを判断する。パケット情報８４がＳＤＲＡＭ８０に記憶されていない場合（Ｓ３０でＮＯ）にＳ３４に進み、記憶されている場合（Ｓ３０でＹＥＳ）にＳ３２に進む。
【００４９】
Ｓ３２では、メインＣＰＵ２０は、Ｓ１２で受信されたステータス要求パケットの送信元のデバイスが、パケット情報８４として記憶されているデバイスと一致するのか否かを判断する。具体的には、メインＣＰＵ２０は、ステータス要求パケットに含まれる送信元のデバイスのＭＡＣアドレスと、パケット情報８４に含まれるＭＡＣアドレスと、が一致するのか否かを判断する。ここで、上述した２つのＭＡＣアドレスが一致する場合、Ｓ３２でＹＥＳと判断されＳ３４に進み、一方、上述した２つのＭＡＣアドレスが異なる場合、Ｓ３２でＮＯと判断されＳ３６に進む。
【００５０】
Ｓ３４では、メインＣＰＵ２０は、ＳＤＲＡＭ８０に、パケット情報８４を記憶させる。Ｓ３０でＮＯと判断された場合（即ちパケット情報８４が記憶されていない場合）に実行されるＳ３４では、メインＣＰＵ２０は、ステータス要求パケットの送信元デバイスのＭＡＣアドレスと、当該ステータス要求パケットの受信時刻と、を対応付けて、ＳＤＲＡＭ８０に記憶させる。一方、Ｓ３２でＹＥＳと判断された場合（即ちＳＤＲＡＭ８０に既にパケット情報８４が記憶されている場合）に実行されるＳ３４では、メインＣＰＵ２０は、パケット情報８４に含まれる前回のステータス要求パケットの受信時刻を、今回のステータス要求パケットの受信時刻に更新する。Ｓ３４が終了すると、Ｓ４６に進む。なお、メインＣＰＵ２０は、ＳＤＲＡＭ８０に記憶されているパケット情報８４に含まれるＭＡＣアドレスに対応するデバイス（例えばＰＣ１００）から予め決められた期間（例えば１分間）が経過しても、次のステータス要求が受信されない場合、ＳＤＲＡＭ８０に記憶されているパケット情報８４を削除する。
【００５１】
一方、上述したように、今回のＳ１２で受信されたステータス要求パケットの送信元のデバイス（以下では「ＰＣ２００」を例として説明する）が、パケット情報８４として記憶されているデバイス（以下では「ＰＣ１００」を例として説明する）と異なる場合（Ｓ３２でＮＯの場合）に、Ｓ３６の処理が実行される。Ｓ３６では、決定部２６は、ＳＤＲＡＭ８０に記憶されているパケット情報８４を用いて、ＰＣ１００から次回のステータス要求パケットを受信する時刻である次回パケット受信時刻を算出する。具体的には、決定部２６は、パケット情報８４に含まれる受信時刻に、ＳＤＲＡＭ８０に予め記憶されている待機期間（即ち３０秒）を加算することによって、次回パケット受信時刻を算出する。なお、多機能機１０のベンダは、待機期間（即ち３０秒）を、予めＳＤＲＡＭ８０に記憶させる。変形例では、メインＣＰＵ２０は、ＰＣ１００からステータス要求パケットが受信される間隔を用いて、待機期間を特定し、特定された待機期間をＳＤＲＡＭ８０に記憶させてもよい。
【００５２】
次いで、Ｓ３８では、Ｓ１２でＰＣ２００から受信されたステータス要求パケットの受信時刻が、Ｓ３６で算出されたＰＣ１００の次回パケット受信時刻とほぼ等しいのか否かを判断する。ここで「受信時刻がほぼ等しい」とは、例えば、ステータス要求パケットの受信時刻と次回パケット受信時刻との差分が、上記のタイムアウト時間よりも短い（例えば上記のタイムアウト時間の１０分の１（即ち０．２秒））状態を意味する。
【００５３】
なお、ＰＣ１００は、前回のステータス要求パケットに対する応答パケットを受信してから待機期間が経過する際に、次回のステータス要求パケットを送信する。従って、厳密には、決定部２６は、ＰＣ１００が前回のステータス要求パケットに対する応答パケットを受信した時刻に、待機期間を加算することによって、次回パケット受信時刻を算出しなければならない。しかしながら、多機能機１０がＰＣ１００からステータス要求パケットを受信してから、ＰＣが多機能機１０からステータス要求パケットに対する応答パケットを受信するまでの期間は、非常に短い。そのため、実質的に、ステータス要求パケットを多機能機１０が受信する時刻と、当該ステータス要求パケットに対する応答パケットをＰＣ１００が受信する時刻とは、ほぼ等しい。
【００５４】
ここで、上述した２つのパケット受信時刻がほぼ等しい場合、Ｓ３８でＹＥＳと判断されＳ４６に進み、一方、上述した２つのパケット受信時刻が略等しくない場合、Ｓ３８でＮＯと判断され、Ｓ４０に進む。Ｓ４０では、決定部２６は、Ｓ３６で算出された次回パケット受信時刻と、Ｓ１２におけるステータス要求パケットの受信時刻と、の差分（即ちＸ秒）が、上記のタイムアウト時間（即ち２秒間）よりも大きいのか否かを判断する。上記の差分（即ちＸ秒）がタイムアウト時間よりも大きい場合（Ｓ４０でＹＥＳ）、Ｓ４２において、決定部２６は、Ｓ１２で受信されたステータス要求パケットの応答パケットを送信する送信タイミングを、Ｓ１２で受信されたＰＣ２００のステータス要求パケットの受信時刻にタイムアウト時間（即ち２秒間）を加算した時刻に決定する。Ｓ４２が終了すると、Ｓ４６に進む。この構成によれば、ステータス要求パケットの送信元のデバイス（即ちＰＣ２００）が、ステータス要求パケットの応答を受信できないと判断することを回避することができる。
【００５５】
なお、ＰＣ２００は、ステータス要求パケットを送信してからタイムアウト時間が経過しても、応答パケットが多機能機１０から受信されない場合に、応答を受信できないと判断する。従って、厳密には、決定部２６は、Ｓ４０及びＳ４２において、以下の処理を実行すべきである。即ち、Ｓ４０の処理では、決定部２６は、上記の差分（即ちＸ秒）が、タイムアウト時間から多機能機１０とＰＣ２００との間の往復の通信時間を減算した特定の時間よりも大きいのか否かを判断すべきである。そして、Ｓ４２の処理では、決定部２６は、Ｓ１２で受信されたＰＣ２００のステータス要求パケットに対する応答パケットを送信する送信タイミングを、当該ステータス要求パケットの受信時刻に上記の特定の時間を加算した時刻に決定すべきである。しかしながら、多機能機１０とＰＣ２００との間の往復の通信時間は、タイムアウト時間と比較して、無視できるほど短い。このため、Ｓ４０及びＳ４２の処理のように、タイムアウト時間を用いて決定された送信タイミングで応答パケットが送信されても、ＰＣ２００がステータス要求パケットの応答を受信できないと判断するという事態は発生しない。
【００５６】
一方、Ｓ４０でＮＯの場合、即ち、Ｘ秒がタイムアウト時間よりも小さい場合、Ｓ４４において、決定部２６は、応答パケットの送信タイミングを、Ｓ１２で受信されたＰＣ２００のステータス要求パケットの受信時刻にＸ秒を加算した時刻に決定する。Ｓ４４が終了すると、Ｓ４６に進む。Ｓ３４、Ｓ４２、又はＳ４４の処理が終了した後、又はＳ３８でＹＥＳと判断された後、Ｓ４６では、送信制御部２４は、Ｓ１２のステータス要求パケットの応答として、多機能機１０の現在のステータス情報を含む応答パケットを、Ｓ１２のステータス要求パケットの送信元のデバイスに送信して、Ｓ１２に戻る。Ｓ３４の処理が実行され又はＳ３８でＹＥＳと判断された後に実行されるＳ４６では、送信制御部２４は、ステータス要求パケットに対応する応答パケットを生成すると直ちに（待機せずに）、応答パケットを送信する。この場合、ステータス要求パケットが受信されてから、応答パケットが送信されるまでの時間は、非常に短い。一方、Ｓ４２又はＳ４４の処理が実行された後に実行されるＳ３４では、送信制御部２４は、ステータス要求パケットに対応する応答パケットを生成した後に、Ｓ４２又はＳ４４で決定されたタイミングまで待機し、決定されたタイミングが到来すると、応答パケットを送信する。
【００５７】
なお、メインＣＰＵ２０の受信制御部２２が、Ｓ１２において、パケットを受信したと判断した場合（多機能機１０がレディ状態である間にパケットが受信された場合）には、メインＣＰＵ２０は、Ｓ１８でＮＯと判断し、Ｓ２６以降の処理を実行する。Ｓ２６以降の処理は、上記と同様である。
【００５８】
（本実施例の効果）
図３を参照して、各装置１０，１００，２００の動作と、本実施例の効果と、を説明する。なお、図３では、メインＣＰＵ２０がスリープ状態である状況で開始される。
【００５９】
１２：００：００では、ＰＣ１００は、Ｍ（Ｍは１以上の整数）番目のステータス要求パケットを、多機能機１０に送信する。Ｍ番目のステータス要求パケットが受信されると、移行制御部４８は、メインＣＰＵ２０を非スリープ状態に移行させる（図２のＳ２４）。メインＣＰＵ２０は、ＰＣ１００のＭＡＣアドレス（即ち「ＰＣ１００」）と対応付けて、受信時刻（即ち「１２：００：００」）を、記憶させる（即ちパケット情報８４）（図２のＳ３４）。送信制御部２４は、Ｍ番目のステータス要求パケットの応答として、Ｍ番目の応答パケットを生成する。送信制御部２４は、Ｍ番目の応答パケットが生成されると、直ちに、ＰＣ１００に送信する（図２のＳ４６）。
【００６０】
Ｍ番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００６１】
次いで、１２：００：２５では、ＰＣ２００は、Ｎ（Ｎは１以上の整数）番目のステータス要求パケットを、多機能機１０に送信する。Ｎ番目のステータス要求パケットが受信されると、移行制御部４８は、メインＣＰＵ２０を非スリープ状態に移行させる（図２のＳ２４）。
【００６２】
決定部２６は、パケット情報８４の受信時刻「１２：００：００」に、待機期間（即ち３０秒間）を加算して、次回パケット受信時刻（ＰＣ１００からＭ＋１番目のステータス要求パケットの受信時刻）（即ち「１２：００：３０」）を算出する（図２のＳ３６）。算出された次回パケット受信時刻と、Ｎ番目のステータス要求パケットの受信時刻（即ち「１２：００：２５」）と、の差分（即ち５秒間）が、タイムアウト時間（即ち２秒間）よりも長い（図２のＳ４０でＹＥＳ）。このため、決定部２６は、Ｎ番目のステータス要求パケットの応答として、Ｎ番目の応答パケットを送信する送信タイミングを、Ｎ番目のステータス要求パケットの受信時刻「１２：００：２５」にタイムアウト時間を加算した「１２：００：２７」に決定する（図２のＳ４２）。送信制御部２４は、Ｎ番目の応答パケットを、１２：００：２７に送信する（図２のＳ４６）。上記の構成によれば、多機能機１０は、Ｎ番目の応答パケットの送信タイミングを、Ｍ＋１番目のステータス要求パケットに対するＭ＋１番目の応答パケットの送信タイミングに近づけることができる。この結果、Ｎ＋１番目の要求パケットの受信タイミングを、Ｍ＋２番目の要求パケットの受信タイミングに近づけることができる。
【００６３】
Ｎ番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００６４】
次いで、１２：００：３０では、ＰＣ１００は、Ｍ＋１番目のステータス要求パケットを、多機能機１０に送信する。なお、厳密には、ＰＣ１００は、Ｍ番目の応答パケットを受信してから３０秒後に、Ｍ＋１番目のステータス要求パケットを送信する。しかしながら、ＰＣ１００は、Ｍ番目のステータス要求パケットを送信してから、Ｍ番目の応答パケットを受信するまでの期間が非常に短いため、実質的に、Ｍ番目のステータス要求パケットの送信からＭ＋１番目のステータス要求パケットの送信までの期間が、３０秒間であると言うことができる。
【００６５】
移行制御部４８は、Ｍ＋１番目のステータス要求パケットが受信されると、メインＣＰＵ２０を非スリープ状態に移行する（図２のＳ２４）。メインＣＰＵ２０は、パケット情報８４を記憶（図２のＳ３４）する。送信制御部２４は、Ｍ＋１番目のステータス要求パケットの応答として、Ｍ＋１番目の応答パケットを生成し、生成されたＭ＋１番目の応答パケットを、直ちに送信する（図２のＳ４６）。Ｍ＋１番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００６６】
１２：００：５７では、ＰＣ２００は、Ｎ＋１番目のステータス要求パケットを、多機能機１０に送信する。移行制御部４８は、Ｎ＋１番目のステータス要求パケットが受信されると、メインＣＰＵ２０を非スリープ状態に移行する（図２のＳ２４）。
【００６７】
決定部２６は、パケット情報８４の受信時刻「１２：００：３０」に、待機期間（３０秒）を加算して、次回パケット受信時刻（ＰＣ１００からＭ＋１番目のステータス要求パケットの受信時刻）（即ち「１２：０１：００」）を算出する（図２のＳ３６）。算出された次回パケット受信時刻と、Ｎ＋１番目のステータス要求パケットの受信時刻（即ち「１２：００：５７」）と、の差分（即ち３秒間）が、タイムアウト時間（即ち２秒間）よりも長い（図２のＳ４０でＹＥＳ）。このため、決定部２６は、Ｎ＋１番目のステータス要求パケットの応答として、Ｎ＋１番目の応答パケットを送信する送信タイミングを、Ｎ＋１番目のステータス要求パケットの受信時刻「１２：００：５７」にタイムアウト時間を加算した「１２：００：５９」に決定する（図２のＳ４２）。送信制御部２４は、Ｎ＋１番目の応答パケットを、１２：００：５９に送信する（図２のＳ４６）。上記の構成では、多機能機１０は、Ｎ＋１番目の応答パケットの送信タイミングを、Ｍ＋２番目の要求パケットに対するＭ＋２番目の応答パケットの送信タイミングに近づけることができる。この結果、Ｎ＋２番目の要求パケットの受信タイミングを、Ｍ＋３番目の要求パケットの受信タイミングに近づけることができる。
【００６８】
Ｎ＋１番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００６９】
時刻１２：０１：００において、ＰＣ１００は、Ｍ＋２番目のステータス要求パケットを、多機能機１０に送信する。Ｍ＋２番目のステータス要求パケットが受信されると、移行制御部４８は、メインＣＰＵ２０を非スリープ状態に移行する（図２のＳ２４）。メインＣＰＵ２０は、パケット情報８４を記憶（図２のＳ３４）する。送信制御部２４は、Ｍ＋２番目のステータス要求パケットの応答として、Ｍ＋２番目の応答パケットを生成し、生成されたＭ＋２番目の応答パケットを、直ちに送信する（図２のＳ４６）。Ｍ＋２番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００７０】
時刻１２：０１：２９において、ＰＣ２００は、Ｎ＋２番目のステータス要求パケットを、多機能機１０に送信する。Ｎ＋２番目のステータス要求パケットが受信されると、移行制御部４８は、メインＣＰＵ２０を非スリープ状態に移行する（図２のＳ２４）。
【００７１】
決定部２６は、パケット情報８４の受信時刻「１２：００：３０」に、待機期間（３０秒）を加算して、次回パケット受信時刻（ＰＣ１００からＭ＋３番目のステータス要求パケットの受信時刻）（即ち「１２：０１：３０」）を算出する（図２のＳ３６）。算出された次回パケット受信時刻と、Ｎ＋２番目のステータス要求パケットの受信時刻（即ち「１２：０１：２９」）と、の差分が、タイムアウト時間（即ち２秒間）よりも短い（図２のＳ４０でＮＯ）。このため、決定部２６は、Ｎ＋２番目のステータス要求パケットの応答として、Ｎ＋２番目の応答パケットを送信する送信タイミングを、Ｎ＋２番目のステータス要求パケットの受信時刻「１２：０１：２９」に、差分である１秒間を加算した「１２：０１：３０」に決定する（図２のＳ４４）。この構成では、ＰＣ２００への応答パケットの送信タイミングを、ＰＣ１００からのステータス要求パケットの受信タイミングを用いて決定している。この結果、ＰＣ２００からのステータス要求パケットの受信タイミングを、ＰＣ１００からのステータス要求パケットの受信タイミングに、適切に近づけることができる。
【００７２】
ＰＣ１００は、１２：０１：３０に、Ｍ＋３番目のステータス要求パケットを、多機能機１０に送信する。このタイミングは、Ｎ＋２番目の応答パケットを送信する送信タイミングに等しいため、メインＣＰＵ２０は、非スリープ状態に維持されている。送信制御部２４は、Ｍ＋３番目のステータス要求パケットの応答として、生成されたＭ＋３番目の応答パケットを、直ちに、ＰＣ１００に送信する（図２のＳ４６）。さらに、送信制御部２４は、Ｎ＋２番目の応答パケットの送信タイミング「１２：０１：３０」が到来したため、Ｎ＋２番目の応答パケットを、ＰＣ２００に送信する（図２のＳ４６）。この結果、Ｍ＋３番目の応答パケットの送信タイミングと、Ｎ＋２番目の応答パケットの送信タイミングと、をほぼ等しくさせることができる。なお、実際には、送信制御部２４は、応答パケットを順番に送信するために、送信タイミングが厳密的な意味で一致しない。
【００７３】
Ｍ＋２番目の応答パケットが送信されると、移行制御部４８は、メインＣＰＵ２０を、非スリープ状態からスリープ状態に移行させる（図２のＳ１６）。
【００７４】
１２：０２：００になると、受信制御部４２は、ＰＣ１００及びＰＣ２００のそれぞれから、Ｍ＋４番目のステータス要求パケットと、Ｎ＋３番目のステータス要求パケットと、を受信する。この構成によれば、多機能機１０は、ＰＣ１００からのステータス要求パケットとＰＣ２００からのステータス要求パケットとを、ほぼ等しいタイミングで受信することができる。
【００７５】
なお、「ほぼ等しいタイミングで受信する」とは、例えば、例えば、ステータス要求パケットの受信時刻とＳ３６で算出された次回パケット受信時刻との差分が、上記のタイムアウト時間よりも短い（例えば上記のタイムアウト時間の１０分の１（即ち０．２秒））状態を意味する。あるいは、「ほぼ等しいタイミングで受信する」とは、図２のＳ１２で受信されたステータス要求パケットについて、図２のＳ４６の処理が実行された後、図２のＳ１２に戻るまでの期間よりも短い状態を意味する。
【００７６】
また、多機能機１０は、ＰＣ２００からのステータス要求パケットの受信タイミングを、ＰＣ１００からのステータス要求パケットの受信タイミングに、近づけることによって、メインＣＰＵ２００がスリープ状態から非スリープ状態に移行される頻度を低くすることができる。この結果、多機能機１０の省電力を低減することができる。特に、図２のＳ１２においてＰＣ１００から受信されたステータス要求パケットについての応答パケットの送信（図２のＳ４６）後、図２のＳ１２に戻るまでの間に、ＰＣ２００からのステータス要求パケットが受信されている場合、Ｓ１２でＹＥＳと判断され、メインＣＰＵ２０がスリープ状態に移行されることを回避することができる。
【００７７】
本実施例では、多機能機１０は、ＰＣ２００からのステータス要求パケットの受信から応答パケットの送信までの時間が、ＰＣ１００からの要求パケットの受信から応答パケットの送信までの時間よりも長くなるようなタイミングで、ＰＣ２００からの応答パケットを送信する。この構成によれば、ＰＣ２００からのステータス要求パケットに対する応答パケットの送信タイミングを、ＰＣ２００からのステータス要求パケットの次に受信されるＰＣ１００からのステータスの要求パケットに対する応答パケットの送信タイミングに近づけることができる。この結果、ＰＣ２００からのステータス要求パケットの受信タイミングを、ＰＣ１００からのステータス要求パケットの受信タイミングに近づける。
【００７８】
（対応関係）
上記の多機能機１０、ＰＣ１００及びＰＣ２００のそれぞれが、「通信装置」、「第１の装置」及び「第２の装置」の一例である。ＰＣ１００から送信されるステータス要求パケットが「第１の要求パケット」の一例であり、ＰＣ２００から送信されるステータス要求パケットが「第２の要求パケット」の一例である。メインＣＰＵ２０とサブＣＰＵ４０とが「プロセッサ」の一例である。２個のＰＣＵ２０，４０が共に非スリープ状態である状態が「高消費状態」の一例であり、メインＰＣＵ２０がスリープ状態であり、サブＣＰＵ４０が非スリープ状態である状態が「低消費状態」の一例である。
【００７９】
以上、本発明の実施形態について詳細に説明したが、これらは例示に過ぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。
【００８０】
（変形例）
（１）上記の実施例では、多機能機１０は、２個のＣＰＵ２０，４０を備えるが、これに代えて、多機能機１０は、メインＣＰＵ２０のみを備えていてもよい。この場合、メインＣＰＵ２０に供給されるクロック信号の周波数が低い状態と高い状態とに移行してもよい。クロック信号の周波数が高い状態では、メインＣＰＵ２０の消費電力が比較的に高く、クロック信号の周波数が低い状態では、メインＣＰＵ２０の消費電力が比較的に低い。この変形例では、メインＣＰＵ２０が「プロセッサ」の一例であり、メインＣＰＵ２０に供給されるクロック信号の周波数が高い状態が「高消費状態」の一例であり、メインＣＰＵ２０に供給されるクロック信号の周波数が低い状態が「低消費状態」の一例である。
【００８１】
（２）上記の実施例では、決定部２６は、ＳＤＲＡＭ８０に記憶されているパケット情報８４を用いて、応答パケットの送信タイミングを決定している（図２のＳ３６からＳ４４）。しかしながら、決定部２６は、ＰＣ１００からのステータス要求パケットの受信タイミングと、ＰＣ２００からのステータス要求パケットの受信タイミングと、が予め決められた間隔（例えば１秒間）以下となるまで、ＰＣ２００からのステータス要求パケットに対する応答パケットの送信タイミングを、ステータス要求パケットの受信タイミングから予め決められた時間（例えば１秒間）だけ加算したタイミングに決定してもよい。本変形例も、「決定部は、第２の要求パケットの受信から当該第２の要求パケットに対する第２の応答パケットの送信までの時間が、第１の要求パケットの受信から当該第１の要求パケットに対する第１の応答パケットの送信までの時間よりも長くなるように、送信タイミングを決定する」という構成に含まれる。
【００８２】
（３）上記の実施例では、メインＣＰＵ２０がプログラム８２に従って処理を実行することによって、決定部２６の機能が実現されている。しかしながら、サブＣＰＵ４０がプログラム６２に従って処理を実行することによって、決定部の機能が実行されてもよい。この場合、図２のＳ２６、Ｓ３０からＳ４４までの処理を、サブＣＰＵ４０が実行してもよい。
【００８３】
（４）上記の実施例では、メインＣＰＵ２０が非スリープ状態である間にステータス要求パケットが受信される場合と、メインＣＰＵ２０がスリープ状態である間にステータス要求パケットが受信される場合と、の両方の場合において、決定部２６は、送信タイミングを決定している（図２のＳ４２及びＳ４４）。しかしながら、メインＣＰＵ２０が非スリープ状態である間にステータス要求パケットが受信される場合には、決定部２６は、送信タイミングを決定せず、直ちに、応答パケットを送信してもよい。この構成によれば、メインＣＰＵ２０が非スリープ状態である間にステータス要求パケットが受信される場合には、応答パケットの送信タイミングの決定処理を実行しなくて済む。
【００８４】
（５）上記の実施例では、決定部２６は、パケット情報８４に記憶されているデバイス（例えばＰＣ１００）への応答パケットの送信タイミングを決定しない。しかしながら、決定部２６は、パケット情報８４に記憶されているデバイス（例えばＰＣ１００）への応答パケットの送信タイミングを決定してもよい。即ち、決定部２６は、受信される全てのステータス要求パケットへの応答パケットの送信タイミングを決定してもよい。
【００８５】
（６）多機能機１０に接続されるＰＣの個数に限りはない。多機能機１０は、多数個のＰＣからのステータス要求パケットの受信タイミングが、パケット情報８４に記憶されているＰＣ１００のステータス要求パケットの受信タイミングに近づくように、多数個のＰＣへの応答パケットの送信タイミングを決定してもよい。さらに、多数個のＰＣが多機能機１０に接続される場合、多機能機１０は、１個以上のＰＣのステータス要求パケットの受信時刻を、パケット情報８４に記憶してもよい。そして、多機能機１０は、パケット情報８４に記憶されているＰＣ以外の多数個のＰＣのステータス要求パケットのそれぞれの受信タイミングが、パケット情報８４に含まれる１個以上ＰＣのいずれかのＰＣに対応する受信タイミングに近づくように、応答パケットの送信タイミングを決定してもよい。例えば、多機能機１０に１０個のＰＣが接続されている場合、多機能機１０は、５個のＰＣを第１グループとして、他の５個のグループを第２グループとして分類してもよい。多機能機１０は、第１グループの中の１個の基準ＰＣの受信タイミングに、第１グループの中の他の４個のＰＣの受信タイミングを近づけてもよい。同様に、多機能機１０は、第２グループの中の１個の基準ＰＣの受信タイミングに、第２グループの中の他の４個のＰＣの受信タイミングを近づけてもよい。この場合、第１グループの中の上記の基準ＰＣの受信タイミングと、第２グループの中の上記の基準ＰＣの受信タイミングと、は一致しなくてもよい。
【００８６】
（７）上記の実施例では、決定部２６は、ＰＣ１００からのステータス要求パケットの受信時刻と待機期間とを用いて、ＰＣ２００への応答パケットの送信タイミングを決定する（図２のＳ４０）。しかしながら、決定部２６は、多機能機１０がＰＣ１００からのステータス要求パケットに対する応答パケットの送信タイミング、あるいは、ＰＣ１００がステータス要求パケットに対する応答パケットの受信タイミングを用いて、ＰＣ２００への応答パケットの送信タイミングを決定してもよい。本変形例では、多機能機１０がＰＣ１００からのステータス要求パケットに対する応答パケットの送信タイミング、あるいは、ＰＣ１００がステータス要求パケットに対する応答パケットの受信イミングが、「第１の要求パケットの受信に関するタイミング」の一例である。
【００８７】
（８）上記の実施例では、メインＣＰＵ２０がプログラム８２に従って処理を実行することによって、各部２２〜２６が実現されるが、各部２２〜２６の少なくとも１個は、論理回路等のハードウェアで実現されてもよい。また、サブＣＰＵ４０がプログラム６２に従って処理を実行することによって、各部４２、４８が実現されるが、各部４２、４８の少なくとも１個は、論理回路等のハードウェアで実現されてもよい。
【００８８】
（８）「通信装置」は、多機能機でなくてもよく、ＰＣ、プリンタ、サーバ、ＰＤＡ等の通信装置であってもよい。
【００８９】
また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
【符号の説明】
【００９０】
２：ネットワークシステム、１０：多機能機、２０：メインＣＰＵ、２２：受信制御部、２４：送信制御部、２６：決定部、４０：サブＣＰＵ、４２：受信制御部、４８：移行制御部、６０：ＳＲＡＭ、７０：フラッシュメモリ、８０：ＳＤＲＡＭ、１００，２００：ＰＣ
【特許請求の範囲】
【請求項１】
第１の要求パケットを通信装置に送信して、前記第１の要求パケットに対する第１の応答パケットを、前記通信装置から受信する処理を繰り返し実行し、前記第１の応答パケットを受信してから所定の期間が経過する際に、前記第１の要求パケットを新たに送信する第１の装置と、
第２の要求パケットを前記通信装置に送信して、前記第２の要求パケットに対する第２の応答パケットを、前記通信装置から受信する処理を繰り返し実行し、前記第２の応答パケットを受信してから前記所定の期間が経過する際に、前記第２の要求パケットを新たに送信する第２の装置と、
のそれぞれに接続される前記通信装置であって、
前記第１の装置から前記第１の要求パケットを受信し、前記第２の装置から前記第２の要求パケットを受信する受信制御部と、
前記第１の要求パケットに対する前記第１の応答パケットを前記第１の装置に送信し、前記第２の要求パケットに対する前記第２の応答パケットを前記第２の装置に送信する送信制御部と、
前記第２の応答パケットを前記第２の装置に送信するための送信タイミングを決定する決定部であって、前記第２の要求パケットの受信から当該第２の要求パケットに対する前記第２の応答パケットの送信までの期間が、前記第１の要求パケットの受信から当該第１の要求パケットに対する前記第１の応答パケットの送信までの期間よりも長くなるように、前記送信タイミングを決定する前記決定部と、
を備え、
前記送信制御部は、決定済みの前記送信タイミングで、前記第２の応答パケットを前記第２の装置に送信する、通信装置。
【請求項２】
前記受信制御部は、前記第１の装置からＭ番目（前記Ｍは１以上の整数）の前記第１の要求パケットを受信し、前記第１の装置から前記Ｍ番目の前記第１の要求パケットが受信された後であって、前記第１の装置からＭ＋１番目の前記第１の要求パケットが受信される前に、前記第２の装置からＮ番目（前記Ｎは１以上の整数）の前記第２の要求パケットを受信し、
前記送信制御部は、前記Ｍ番目の第１の要求パケットに対するＭ番目の前記第１の応答パケットを前記第１の装置に送信し、前記Ｎ番目の第２の要求パケットに対するＮ番目の前記第２の応答パケットを前記第２の装置に送信し、
前記決定部は、前記Ｎ番目の第２の要求パケットの受信から前記Ｎ番目の第２の応答パケットの送信までの期間が、前記Ｍ番目の第１の要求パケットの受信から前記Ｍ番目の第１の応答パケットの送信までの期間よりも長くなるように、前記Ｎ番目の第２の応答パケットの送信タイミングを決定し、
前記送信制御部は、決定済みの前記送信タイミングで、前記Ｎ番目の第２の応答パケットを前記第２の装置に送信する、請求項１に記載の通信装置。
【請求項３】
前記決定部は、前記第１の要求パケットの受信に関するタイミングを用いて、前記第２の応答パケットの前記送信タイミングを決定する、請求項１又は２に記載の通信装置。
【請求項４】
前記決定部は、前記第１の要求パケットが受信されるタイミングと、前記第２の要求パケットが受信されるタイミングと、がほぼ等しくなるまで、前記第２の要求パケットが受信される毎に、前記第２の応答パケットの前記送信タイミングを決定し、
前記送信制御部は、前記第２の要求パケットが受信される毎に、当該第２の要求パケットについて決定される前記送信タイミングで、当該第２の要求パケットに対する前記第２の応答パケットを送信する、請求項１から３のいずれか一項に記載の通信装置。
【請求項５】
前記第２の装置は、
前記第２の要求パケットを前記通信装置に送信してから特定の期間が経過する前に、当該第２の要求パケットに対する前記第２の応答パケットが受信される場合には、前記第２の応答パケットに従った処理を実行し、
前記第２の要求パケットを前記通信装置に送信してから前記特定の期間が経過した後に、当該第２の要求パケットに対する前記第２の応答パケットが受信されても、前記第２の応答パケットに従った処理を実行せず、
前記決定部は、前記第２の要求パケットの受信から当該第２の要求パケットに対する前記第２の応答パケットの送信までの前記期間が、前記特定の期間以下になるように、前記送信タイミングを決定する、請求項１から４のいずれか一項に記載の通信装置。
【請求項６】
前記受信制御部は、前記第１の装置からＭ番目（前記Ｍは１以上の整数）の前記第１の要求パケットを受信し、前記第１の装置から前記Ｍ番目の前記第１の要求パケットが受信された後であって、前記第１の装置からＭ＋１番目の前記第１の要求パケットが受信される前に、前記第２の装置からＮ番目（前記Ｎは１以上の整数）の前記第２の要求パケットを受信し、
前記送信制御部は、前記Ｍ番目の第１の要求パケットに対するＭ番目の前記第１の応答パケットを前記第１の装置に送信し、前記Ｎ番目の第２の要求パケットに対するＮ番目の前記第２の応答パケットを前記第２の装置に送信し、
前記決定部は、
前記Ｍ＋１番目の第１の要求パケットの受信タイミングと、前記Ｎ番目の第２の要求パケットの受信タイミングと、の間の特定の差分が、前記特定の期間よりも長い場合に、前記Ｎ番目の第２の要求パケットの受信から、前記Ｎ番目の第２の応答パケットの送信までの期間が、前記特定の期間に一致するように、前記Ｎ番目の第２の応答パケットの前記送信タイミングを決定し、
前記特定の差分が、前記特定の期間よりも短い場合に、前記Ｎ番目の第２の要求パケットの受信から、前記Ｎ番目の第２の応答パケットの送信までの期間が、前記特定の差分に一致するように、前記Ｎ番目の第２の応答パケットの前記送信タイミングを決定する、請求項５に記載の通信装置。
【請求項７】
消費電力が比較的に高い高消費状態と、消費電力が比較的に低い低消費状態と、の間で移行可能であるプロセッサを備え、
前記プロセッサは、前記受信制御部と、前記送信制御部と、前記決定部と、移行制御部と、を備え、
前記移行制御部は、前記プロセッサを前記高消費状態と前記低消費状態との間で移行させ、
前記プロセッサが前記低消費状態である間に、前記第１の要求パケットが受信される場合に、
前記移行制御部は、前記プロセッサを前記低消費状態から前記高消費状態に移行させ、
前記送信制御部は、前記プロセッサが前記高消費状態である間に、前記第１の要求パケットに対する前記第１の応答パケットを送信し、
前記プロセッサが前記低消費状態である間に、前記第２の要求パケットが受信される場合に、
前記移行制御部は、前記プロセッサを前記低消費状態から前記高消費状態に移行させ、
前記送信制御部は、前記プロセッサが前記高消費状態である間に、前記第２の要求パケットに対する前記第２の応答パケットを送信する、請求項１から６のいずれか一項に記載の通信装置。
【請求項８】
第１の要求パケットを通信装置に送信して、前記第１の要求パケットに対する第１の応答パケットを、前記通信装置から受信する処理を繰り返し実行し、前記第１の応答パケットを受信してから所定の期間が経過する際に、前記第１の要求パケットを新たに送信する第１の装置と、
第２の要求パケットを前記通信装置に送信して、前記第２の要求パケットに対する第２の応答パケットを、前記通信装置から受信する処理を繰り返し実行し、前記第２の応答パケットを受信してから前記所定の期間が経過する際に、前記第２の要求パケットを新たに送信する第２の装置と、
のそれぞれに接続される前記通信装置のためのコンピュータプログラムであって、
前記通信装置に搭載されるコンピュータに、
前記第１の装置から前記第１の要求パケットを受信し、前記第２の装置から前記第２の要求パケットを受信する受信制御処理と、
前記第１の要求パケットに対する前記第１の応答パケットを前記第１の装置に送信し、前記第２の要求パケットに対する前記第２の応答パケットを前記第２の装置に送信する送信制御処理と、
前記第２の応答パケットを前記第２の装置に送信するための送信タイミングを決定する決定処理であって、前記第２の要求パケットの受信から当該第２の要求パケットに対する前記第２の応答パケットの送信までの時間が、前記第１の要求パケットの受信から当該第１の要求パケットに対する前記第１の応答パケットの送信までの時間よりも長くなるように、前記送信タイミングを決定する前記決定処理と、
を実行させ、
前記送信制御処理では、決定済みの前記送信タイミングで、前記第２の応答パケットを前記第２の装置に送信する、コンピュータプログラム。
【請求項１】
第１の要求パケットを通信装置に送信して、前記第１の要求パケットに対する第１の応答パケットを、前記通信装置から受信する処理を繰り返し実行し、前記第１の応答パケットを受信してから所定の期間が経過する際に、前記第１の要求パケットを新たに送信する第１の装置と、
第２の要求パケットを前記通信装置に送信して、前記第２の要求パケットに対する第２の応答パケットを、前記通信装置から受信する処理を繰り返し実行し、前記第２の応答パケットを受信してから前記所定の期間が経過する際に、前記第２の要求パケットを新たに送信する第２の装置と、
のそれぞれに接続される前記通信装置であって、
前記第１の装置から前記第１の要求パケットを受信し、前記第２の装置から前記第２の要求パケットを受信する受信制御部と、
前記第１の要求パケットに対する前記第１の応答パケットを前記第１の装置に送信し、前記第２の要求パケットに対する前記第２の応答パケットを前記第２の装置に送信する送信制御部と、
前記第２の応答パケットを前記第２の装置に送信するための送信タイミングを決定する決定部であって、前記第２の要求パケットの受信から当該第２の要求パケットに対する前記第２の応答パケットの送信までの期間が、前記第１の要求パケットの受信から当該第１の要求パケットに対する前記第１の応答パケットの送信までの期間よりも長くなるように、前記送信タイミングを決定する前記決定部と、
を備え、
前記送信制御部は、決定済みの前記送信タイミングで、前記第２の応答パケットを前記第２の装置に送信する、通信装置。
【請求項２】
前記受信制御部は、前記第１の装置からＭ番目（前記Ｍは１以上の整数）の前記第１の要求パケットを受信し、前記第１の装置から前記Ｍ番目の前記第１の要求パケットが受信された後であって、前記第１の装置からＭ＋１番目の前記第１の要求パケットが受信される前に、前記第２の装置からＮ番目（前記Ｎは１以上の整数）の前記第２の要求パケットを受信し、
前記送信制御部は、前記Ｍ番目の第１の要求パケットに対するＭ番目の前記第１の応答パケットを前記第１の装置に送信し、前記Ｎ番目の第２の要求パケットに対するＮ番目の前記第２の応答パケットを前記第２の装置に送信し、
前記決定部は、前記Ｎ番目の第２の要求パケットの受信から前記Ｎ番目の第２の応答パケットの送信までの期間が、前記Ｍ番目の第１の要求パケットの受信から前記Ｍ番目の第１の応答パケットの送信までの期間よりも長くなるように、前記Ｎ番目の第２の応答パケットの送信タイミングを決定し、
前記送信制御部は、決定済みの前記送信タイミングで、前記Ｎ番目の第２の応答パケットを前記第２の装置に送信する、請求項１に記載の通信装置。
【請求項３】
前記決定部は、前記第１の要求パケットの受信に関するタイミングを用いて、前記第２の応答パケットの前記送信タイミングを決定する、請求項１又は２に記載の通信装置。
【請求項４】
前記決定部は、前記第１の要求パケットが受信されるタイミングと、前記第２の要求パケットが受信されるタイミングと、がほぼ等しくなるまで、前記第２の要求パケットが受信される毎に、前記第２の応答パケットの前記送信タイミングを決定し、
前記送信制御部は、前記第２の要求パケットが受信される毎に、当該第２の要求パケットについて決定される前記送信タイミングで、当該第２の要求パケットに対する前記第２の応答パケットを送信する、請求項１から３のいずれか一項に記載の通信装置。
【請求項５】
前記第２の装置は、
前記第２の要求パケットを前記通信装置に送信してから特定の期間が経過する前に、当該第２の要求パケットに対する前記第２の応答パケットが受信される場合には、前記第２の応答パケットに従った処理を実行し、
前記第２の要求パケットを前記通信装置に送信してから前記特定の期間が経過した後に、当該第２の要求パケットに対する前記第２の応答パケットが受信されても、前記第２の応答パケットに従った処理を実行せず、
前記決定部は、前記第２の要求パケットの受信から当該第２の要求パケットに対する前記第２の応答パケットの送信までの前記期間が、前記特定の期間以下になるように、前記送信タイミングを決定する、請求項１から４のいずれか一項に記載の通信装置。
【請求項６】
前記受信制御部は、前記第１の装置からＭ番目（前記Ｍは１以上の整数）の前記第１の要求パケットを受信し、前記第１の装置から前記Ｍ番目の前記第１の要求パケットが受信された後であって、前記第１の装置からＭ＋１番目の前記第１の要求パケットが受信される前に、前記第２の装置からＮ番目（前記Ｎは１以上の整数）の前記第２の要求パケットを受信し、
前記送信制御部は、前記Ｍ番目の第１の要求パケットに対するＭ番目の前記第１の応答パケットを前記第１の装置に送信し、前記Ｎ番目の第２の要求パケットに対するＮ番目の前記第２の応答パケットを前記第２の装置に送信し、
前記決定部は、
前記Ｍ＋１番目の第１の要求パケットの受信タイミングと、前記Ｎ番目の第２の要求パケットの受信タイミングと、の間の特定の差分が、前記特定の期間よりも長い場合に、前記Ｎ番目の第２の要求パケットの受信から、前記Ｎ番目の第２の応答パケットの送信までの期間が、前記特定の期間に一致するように、前記Ｎ番目の第２の応答パケットの前記送信タイミングを決定し、
前記特定の差分が、前記特定の期間よりも短い場合に、前記Ｎ番目の第２の要求パケットの受信から、前記Ｎ番目の第２の応答パケットの送信までの期間が、前記特定の差分に一致するように、前記Ｎ番目の第２の応答パケットの前記送信タイミングを決定する、請求項５に記載の通信装置。
【請求項７】
消費電力が比較的に高い高消費状態と、消費電力が比較的に低い低消費状態と、の間で移行可能であるプロセッサを備え、
前記プロセッサは、前記受信制御部と、前記送信制御部と、前記決定部と、移行制御部と、を備え、
前記移行制御部は、前記プロセッサを前記高消費状態と前記低消費状態との間で移行させ、
前記プロセッサが前記低消費状態である間に、前記第１の要求パケットが受信される場合に、
前記移行制御部は、前記プロセッサを前記低消費状態から前記高消費状態に移行させ、
前記送信制御部は、前記プロセッサが前記高消費状態である間に、前記第１の要求パケットに対する前記第１の応答パケットを送信し、
前記プロセッサが前記低消費状態である間に、前記第２の要求パケットが受信される場合に、
前記移行制御部は、前記プロセッサを前記低消費状態から前記高消費状態に移行させ、
前記送信制御部は、前記プロセッサが前記高消費状態である間に、前記第２の要求パケットに対する前記第２の応答パケットを送信する、請求項１から６のいずれか一項に記載の通信装置。
【請求項８】
第１の要求パケットを通信装置に送信して、前記第１の要求パケットに対する第１の応答パケットを、前記通信装置から受信する処理を繰り返し実行し、前記第１の応答パケットを受信してから所定の期間が経過する際に、前記第１の要求パケットを新たに送信する第１の装置と、
第２の要求パケットを前記通信装置に送信して、前記第２の要求パケットに対する第２の応答パケットを、前記通信装置から受信する処理を繰り返し実行し、前記第２の応答パケットを受信してから前記所定の期間が経過する際に、前記第２の要求パケットを新たに送信する第２の装置と、
のそれぞれに接続される前記通信装置のためのコンピュータプログラムであって、
前記通信装置に搭載されるコンピュータに、
前記第１の装置から前記第１の要求パケットを受信し、前記第２の装置から前記第２の要求パケットを受信する受信制御処理と、
前記第１の要求パケットに対する前記第１の応答パケットを前記第１の装置に送信し、前記第２の要求パケットに対する前記第２の応答パケットを前記第２の装置に送信する送信制御処理と、
前記第２の応答パケットを前記第２の装置に送信するための送信タイミングを決定する決定処理であって、前記第２の要求パケットの受信から当該第２の要求パケットに対する前記第２の応答パケットの送信までの時間が、前記第１の要求パケットの受信から当該第１の要求パケットに対する前記第１の応答パケットの送信までの時間よりも長くなるように、前記送信タイミングを決定する前記決定処理と、
を実行させ、
前記送信制御処理では、決定済みの前記送信タイミングで、前記第２の応答パケットを前記第２の装置に送信する、コンピュータプログラム。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１２−２１３０７４（Ｐ２０１２−２１３０７４Ａ）
【公開日】平成２４年１１月１日（２０１２．１１．１）
【国際特許分類】
【出願番号】特願２０１１−７８１０７（Ｐ２０１１−７８１０７）
【出願日】平成２３年３月３１日（２０１１．３．３１）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
【公開日】平成２４年１１月１日（２０１２．１１．１）
【国際特許分類】
【出願日】平成２３年３月３１日（２０１１．３．３１）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
[ Back to top ]