(57)【要約】【課題】ネットワーク上の様々なパケットトラフィックに左右されることなく、ネットワーク上の特定のサービス提供デバイスを速やかに節電モードへ移行させ、かつ、節電モードに移行した特定のサービス提供デバイスのみを速やかに通常の機能処理実行可能なアライブ状態に遷移させることである。【解決手段】ＵＰｎＰ（登録商標）規格に準拠するサービス提供デバイスでシステムが構築される場合に、プリンタ４００の通信処理部２２が所定時間、サービス提供が実行されていない状態を検出した場合に、プリンタ４００が提供する通信機能を制限し、該制限された通信機能をプロキシ３００にて代行させて、プリンタコントローラ２３等を含むエンジン部等の電力供給を制限する節電モードへ移行させ、以後、プロキシ３００がプリンタ４００に代わり、プリンタ４００に対する通信機能を代行する構成を特徴とする。【選択図】        図１
2004334792.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムであって、
各サービス提供デバイスは、所定のサービス提供処理が予め定められた時間実行されなかった場合、いずれかのクライアントデバイスからの通信機能要求に応える特定の通信機能を指定して、該指定される特定の通信機能に基づく通信処理をネットワーク上のいずれかのサービス提供デバイスに代行させ、前記ネットワーク上のクライアントデバイスから認識されないネットワークスリープ状態に移行させる代行処理手段を備えることを特徴とするネットワークサービスシステム。
【請求項２】
前記代行処理手段は、前記ネットワークスリープ状態に移行した後、電力消費を抑える動作モード移行処理を実行することを特徴とする請求項１記載のネットワークサービスシステム。
【請求項３】
前記代行処理手段は、前記ネットワークスリープ状態に移行した後、代行依頼したサービス提供デバイスからスリープ解除要求を受けることに応じて、前記ネットワークスリープ状態をネットワークアライブ状態に移行することを特徴とする請求項１記載のネットワークサービスシステム。
【請求項４】
前記ネットワークスリープ状態をネットワークアライブ状態に移行する条件は、指定される前記特定の通信機能あるいは特定の通信機能の組合せに基づいて決定されることを特徴とする請求項１記載のネットワークサービスシステム。
【請求項５】
前記サービス提供デバイスは、プロキシサーバであることを特徴とする請求項１〜４の何れかに記載のネットワークサービスシステム。
【請求項６】
ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムであって、
予め定められた時間、所定のサービス提供処理が実行されなかった場合、サービス提供デバイスが提供する通信機能に制限し、該制限された通信機能を代行して処理する制限手段を前記サービス提供デバイス上に設けたことを特徴とするネットワークサービスシステム。
【請求項７】
前記制限手段は、通信機能に制限を実施する以前に、制限された通信機能を代行して処理するサービス提供デバイスに対して代行処理を委託することを特徴とする請求項６記載のネットワークサービスシステム。
【請求項８】
前記制限手段は、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託する通信機能を指定可能とすることを特徴とする請求項６記載のネットワークサービスシステム。
【請求項９】
前記制限手段は、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託しない通信機能を指定可能とすることを特徴とする請求項６記載のネットワークサービスシステム。
【請求項１０】
前記制限手段は、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託した通信機能に対し全ての機能、あるいは一部の通信機能の代行処理を委託可能とすることを特徴とする請求項６記載のネットワークサービスシステム。
【請求項１１】
通信機能代行処理中のサービス提供デバイスが前記ネットワークを介して、通信機能を代行して処理するサービス提供デバイスが制限された通信機能に関連する通信データを受信した場合、代行処理中のサービス提供デバイスが通信機能が制限されている被制限サービス提供デバイスに対してその旨の通知処理を行うことを特徴とする請求項６記載のネットワークサービスシステム。
【請求項１２】
前記制限手段は、前記通信機能代行処理中のサービス提供デバイスより前記被制限サービス提供デバイスに前記その旨の通知があった場合、通信機能に対する制限を解除する機能を有することを特徴とする請求項６記載のネットワークサービスシステム。
【請求項１３】
前記制限手段は、あらかじめ通知された識別子と同一の識別子をもつ通信機能を代行して処理するサービス提供デバイスよりその旨の通知があった場合に、前記通信機能に対する制限を解除することを特徴とする請求項１２記載のネットワークサービスシステム。
【請求項１４】
ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムにおけるサービス代行処理方法であって、
各サービス提供デバイスは、所定のサービス提供処理が予め定められた時間実行されなかった場合、いずれかのクライアントデバイスからの通信機能要求に応える特定の通信機能を指定して、該指定される特定の通信機能に基づく通信処理をネットワーク上のいずれかのサービス提供デバイスに代行させ、前記ネットワーク上のクライアントデバイスから認識されないネットワークスリープ状態に移行させる代行処理ステップを備えることを特徴とするサービス代行処理方法。
【請求項１５】
前記代行処理ステップは、前記ネットワークスリープ状態に移行した後、電力消費を抑える動作モード移行処理を実行することを特徴とする請求項１４記載のサービス代行処理方法。
【請求項１６】
前記代行処理ステップは、前記ネットワークスリープ状態に移行した後、代行依頼したサービス提供デバイスからスリープ解除要求を受けることに応じて、前記ネットワークスリープ状態をネットワークアライブ状態に移行することを特徴とする請求項１４記載のサービス代行処理方法。
【請求項１７】
前記ネットワークスリープ状態をネットワークアライブ状態に移行する条件は、指定される前記特定の通信機能あるいは特定の通信機能の組合せに基づいて決定されることを特徴とする請求項１４記載のサービス代行処理方法。
【請求項１８】
前記サービス提供デバイスは、プロキシサーバであることを特徴とする請求項１４〜１７の何れかに記載のサービス代行処理方法。
【請求項１９】
ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムにおけるサービス代行処理方法であって、
予め定められた時間、所定のサービス提供処理が実行されなかった場合、サービス提供デバイスが提供する通信機能に制限し、該制限された通信機能を代行して処理する制限ステップを設けたことを特徴とするサービス代行処理方法。
【請求項２０】
前記制限ステップは、通信機能に制限を実施する以前に、制限された通信機能を代行して処理するサービス提供デバイスに対して代行処理を委託することを特徴とする請求項１９記載のサービス代行処理方法。
【請求項２１】
前記制限ステップは、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託する通信機能を指定可能とすることを特徴とする請求項１９記載のサービス代行処理方法。
【請求項２２】
前記制限ステップは、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託しない通信機能を指定可能とすることを特徴とする請求項１９記載のサービス代行処理方法。
【請求項２３】
前記制限ステップは、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託した通信機能に対し全ての機能、あるいは一部の通信機能の代行処理を委託可能とすることを特徴とする請求項１９記載のサービス代行処理方法。
【請求項２４】
通信機能代行処理中のサービス提供デバイスが前記ネットワークを介して、通信機能を代行して処理するサービス提供デバイスが制限された通信機能に関連する通信データを受信した場合、代行処理中のサービス提供デバイスが通信機能が制限されている被制限サービス提供デバイスに対してその旨を通知処理を行うことを特徴とする請求項１９記載のサービス代行処理方法。
【請求項２５】
前記制限ステップは、前記通信機能代行処理中のサービス提供デバイスより前記被制限サービス提供デバイスに前記その旨の通知があった場合、通信機能に対する制限を解除する機能を有することを特徴とする請求項１９記載のサービス代行処理方法。
【請求項２６】
前記制限ステップは、あらかじめ通知された識別子と同一の識別子をもつ通信機能を代行して処理するサービス提供デバイスより前記その旨の通知があった場合に、前記通信機能に対する制限を解除することを特徴とする請求項２５記載のサービス代行処理方法。
【請求項２７】
請求項１４〜２６のいずれかに記載のサービス代行処理方法を実現するプログラムを記憶したことを特徴とするコンピュータが読み取り可能な記憶媒体。
【請求項２８】
請求項１４〜２６のいずれかに記載のサービス代行処理方法を実現することを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上に接続されたサービス提供デバイスの節電制御を行うネットワークサービスシステムおよびサービス代行処理方法およびコンピュータが読取り可能なプログラムを格納した記憶媒体およびプログラムに関するものである。
【０００２】
【従来の技術】
従来、プリンタ（複写機、複合機を含む）とコンピュータとをネットワーク接続したサービス提供装置及び、サービス提供システムが知られている。
【０００３】
例えば、インターネットによる通信の飛躍的な普及に伴い、ネットワーク対応型機器も、従来のパーソナルコンピュータから、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｃｅ）、携帯電話等のユーザインタラクティブなデバイスや、スキャナ、プリンタ、複写機、デジタルカメラ等の画像処理装置、テレビ、エアコン、冷蔵庫等の家電製品に至るまでネットワーク対応が急速に進められつつある。
【０００４】
それに伴い、これらネットワーク対応型デバイスを利用する上での利便性、簡易性を高めるために、ネットワークアドレスの自動設定手段、ネットワークデバイスの探索、検索手段、ネットワーク対応型デバイスを制御するためのアプリケーションソフトウエア、ユーティリティソフトウエア、オペレーティングシステム等の自動セットアップ手段を提供する、さまざまなプロトコルが提案されている。  たとえば、Ｍｉｃｒｏｓｏｆｔが主体となって策定を進めるＵＰｎＰ（登録商標）、日本事務機工業会（ＪＢＭＩＡ）が推進するＢＭＬｉｎｋＳ（登録商標）、Ａｐｐｌｅ  ＯＳ  ＸでサポートされるＲｅｎｅｄｚｖｏｕｓ（登録商標）などがその一例である。
【０００５】
一方で、省エネルギーの観点からこれらネットワーク対応型デバイスに対し、消費電力を抑えるべく改善が進められている。ＰＤＡ、携帯電話のように小型バッテリーで駆動するデバイスの場合、長時間利用可能なように消費電力を抑える必要があり、一方、プリンタ、複写機等、熱定着機のように消費電力の大きな装置をもつデバイスの場合、消費電力がいかに低いかが製品普及のための一因ともなっている。
【０００６】
通常、これらデバイスは一定時間、ユーザからの操作が実行されなかった場合、あるいは一定時間、他のデバイスとの通信が実行されずアイドル状態が継続するとスリープモードに移行し、スリープモードに移行すると、ワンチップマイコン、ＬＡＮコントローラなど低消費電圧のデバイスに対してのみ電力供給を継続することで、必要最低限の通信機能を維持し、不要な電力供給を停止することで消費電力を抑える処理を実施している。
【０００７】
スリープモードの解除には、これらデバイスが、特定データ形式を持つパケットを監視し、特定のデータ形式を持つパケットを受信した場合に、スリープモードが解除され、通常の通信処理を再開するという処理を実施している。
【０００８】
また、ＬＡＮの仮想回線を切断することなく、パソコン等の機器のレジューム機能を自動的に活用できるようにするものも提案（下記特許文献１参照）されている。
【０００９】
【特許文献１】特開平５−１７５９６４号公報
さらに、スタンドアロンタイプのデータ処理装置において、ハードウエアのシステム構成状態を調査して、各種のアプリケーションをインストールする、いわゆるＰｌｕｇ  ａｎｄ  Ｐｌａｙをネットワークに拡張した、各種のフェイズから構成されているＵＰｎＰ（登録商標）、ＢＭＬｉｎｋＳ（登録商標）、Ｒｅｎｄｅｚｖｏｕｓ（登録商標）に代表されるＰｌｕｇ  ａｎｄ  Ｐｌａｙ用のプロトコルを利用する各種のデバイスも家電、コンピュータシステム等の分野で数多く提案されている。
【００１０】
【発明が解決しようとする課題】
しかしながら、上述した従来技術においては下記のような問題があった。
【００１１】
例えばプリンタがスリープモードに移行すると、ワンチップマイコン、ＬＡＮコントローラなど低消費電圧のデバイスがそれ以降、ネットワーク処理を担当する。この際、上記ワンチップマイコン、ＬＡＮコントローラ等のデバイスはインテリジェントでないため、複雑な通信プロトコルで所定の処理を実現することができない。
【００１２】
したがって、データ受信機能のみ稼動して特定データを持つパケットを監視し、該特定のデータ形式を持つパケットを受信した場合に、スリープモードを解除する等によりデータ受信待機状態に移行する節電制御を行っている。
【００１３】
また、上記のシステム構成の場合には、ＴＣＰ／ＩＰ／ＵＤＰに限らず、異なるプロトコル、例えばＮｅｔｗａｒｅ、ＡｐｐｌｅＴａｌｋを使うアプリケーション、ユーティリティの全てが、ジョブ要求（プリントジョブ）を発行する直前に”特定のデータ形式を持つパケット”を発行しなければならない。
【００１４】
このため、上記のようなワンチップマイコン、ＬＡＮコントローラ等のデバイスはインテリジェントでないプリンタ装置に対して、クライアント側のアプリケーション、例えば全てのアプリケーション、ユーティリティが該パケットを発行できるように何らかのプログラム変更あるいは修正処理が必要となってしまう。
【００１５】
また、クライアント側における既存のアプリケーションからは、一旦、スリープ状態に移行していまっているデバイス（プリンタを含む）に対し、ジョブ実行ができなくなる。
【００１６】
一方、”特定のデータ形式を持つパケット”が、誰でも（どのネットワークデバイス）知りうるデータを持つように構成した場合、該パケットがネットワーク上に頻繁に発行され、該スリープ状態から頻繁にＷａｋｅｕｐ（特に、上記ネットワークシステムにおいて、ＵＰｎＰ（登録商標）／  ＢＭＬｉｎｋＳ（登録商標）／Ｒｅｎｄｅｚｖｏｕｓ（登録商標）に代表されるＰｌｕｇ  ａｎｄ  Ｐｌａｙ用のプロトコルを採用した場合には、クライアントノードからＤｉｓｃｏｖｅｒｙパケット等、頻繁に通信要求が発生する）されてしまい、本来の目的である省電力化を実現することができないという問題点があった。
【００１７】
さらに、不特定のクライアントからＷａｋｅＵｐされることを極力避けたいというシステム管理者からの要求にも柔軟に対応させることが困難となる場合も想定されており、これらの改善が切望されている。
【００１８】
本発明は、上記の問題点の少なくとも一つ解決するためになされたもので、本発明の目的は、ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムにおいて、ネットワークに接続された所定の機能処理を実行する特定のサービス提供デバイスが機能処理要求を受け付けない状態が所定時間継続した場合に、特定のサービス提供デバイスの特定の通信機能処理を他のサービス提供デバイスに代行させて速やかに節電モード状態へ移行させるとともに、該節電モード状態時に、通信機能処理を代行するサービス提供デバイスが節電モード状態中のサービス提供デバイスに対する機能処理要求をクライアントから受け付けた場合に、通信機能処理を代行依頼されているサービス提供デバイスを識別して該通信機能が制限されるサービス提供デバイスをアライブ状態に復帰させることにより、ネットワーク上の様々なパケットトラフィックに左右されることなく、ネットワーク上の特定のサービス提供デバイスを速やかに節電モードへ移行させ、かつ、節電モードに移行した特定のサービス提供デバイスのみを速やかに通常の機能処理実行可能なアライブ状態に遷移させることができるネットワークサービスシステム環境を自在に構築することができるネットワークサービスシステムおよびサービス代行処理方法およびコンピュータが読取り可能なプログラムを格納した記憶媒体およびプログラムを提供することである。
【００１９】
【課題を解決するための手段】
上記目的を達成する本発明のネットワークサービスシステムは以下に示す構成を備える。
【００２０】
ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムであって、各サービス提供デバイスは、所定のサービス提供処理が予め定められた時間実行されなかった場合、いずれかのクライアントデバイスからの通信機能要求に応える特定の通信機能を指定して、該指定される特定の通信機能に基づく通信処理をネットワーク上のいずれかのサービス提供デバイスに代行させ、前記ネットワーク上のクライアントデバイスから認識されないネットワークスリープ状態に移行させる代行処理手段を備えることを特徴とする。
【００２１】
また、ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムであって、予め定められた時間、所定のサービス提供処理が実行されなかった場合、サービス提供デバイスが提供する通信機能に制限し、該制限された通信機能を代行して処理する制限手段を前記サービス提供デバイス上に設けたことを特徴とする。
【００２２】
さらに、上記目的を達成する本発明のサービス代行処理方法は以下に示す構成を備える。
【００２３】
ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムにおけるサービス代行処理方法であって、各サービス提供デバイスは、所定のサービス提供処理が予め定められた時間実行されなかった場合、いずれかのクライアントデバイスからの通信機能要求に応える特定の通信機能を指定して、該指定される特定の通信機能に基づく通信処理をネットワーク上のいずれかのサービス提供デバイスに代行させ、前記ネットワーク上のクライアントデバイスから認識されないネットワークスリープ状態に移行させる代行処理ステップを備えることを特徴とする。
【００２４】
また、ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムにおけるサービス代行処理方法であって、予め定められた時間、所定のサービス提供処理が実行されなかった場合、サービス提供デバイスが提供する通信機能に制限し、該制限された通信機能を代行して処理する制限ステップを設けたことを特徴とする。
【００２５】
さらに、上記サービス代行処理方法を実現するプログラムをコンピュータが読み取り可能な記憶媒体に記憶したことを特徴とする。
【００２６】
さらに、上記サービス代行処理方法を実現するプログラムであることを特徴とする。
【００２７】
【発明の実施の形態】
以下に、図面を参照して、本発明の好適な実施形態を例示的に詳しく説明する。ただし、この実施形態に記載されているプロトコル、バージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。
【００２８】
〔第１実施形態〕
図１は、本発明の第１実施形態を示すネットワークサービスシステムの構成を示すブロック図であり、例えばクライアント装置（クライアント）１００がネットワークＮＥＴを介して、プロキシ（サーバ）３００，プリンタ装置（プリンタ４００）と通信可能に構成されている例に対応する。なお、説明上、プリンタ４００は、ネットワークＮＥＴ上に１台接続されるシステム例を示すが複数台のプリンタが接続されるシステムにも適応可能であることはいうまでもない。
【００２９】
また、本実施形態では、サービス提供システムの一実施形態としてのプロトコル変換システム例について説明する。
【００３０】
図１において、クライアント１００は、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ社のＭａｃ  ＯＳ等の汎用のオペレーティングシステム（ＯＳ）１、およびその上で実行可能な汎用アプリケーション４がインストールされており、本実施形態で示すシステム例では、ＯＳ４がＷｉｎｄｏｗｓ（登録商標）等で構成される場合、ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＸＭＬ）／Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）を利用したＵＰｎＰ（登録商標）プロトコルを使用して、ネットワーク上のデバイスのディスカバリ、制御、ステータスの取得等を実現しており、例えばアプリケーション４であるワードプロセッサで作成されたドキュメンは、ＵＰｎＰ（登録商標）Ｐｒｏｔｏｃｏｌが検索発見したＵＰｎＰ（登録商標）プロトコル対応プリンタ４００に対し、プリンタドライバ（Ｐｒｉｎｔ  Ｄｒｉｖｅｒ）３で印字可能なデータに変換された後、ＵＰｎＰ（登録商標）プロトコルを使用してプリントジョブの発行を実行する。
【００３１】
一方、ネットワーク対応デバイス、本実施形態では、ネットワーク対応型のプリンタ４００は、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタックを備え、そのプロトコルスタック１７上にＨＴＴＰ処理部１９を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。
【００３２】
また、プロトコルスタック１７上にはパケット監視処理部２４を備え、通信処理部２２から予め指定されたパケットデータの受信の有無を監視する機能を有する。
【００３３】
ＨＴＴＰ処理部１９の上位層にはＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部２０を備え、ＵＰｎＰ（登録商標）プロトコル処理部２１、および通信処理部２２がそれぞれ、該処理部を介してそれぞれ、クライアント２００、およびプロキシサーバ３００が複数ネットワーク上に存在する場合、ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＸＭＬ）で記述されたデータの双方向通信を実現する。
【００３４】
通信処理部２２は、ＵＰｎＰ（登録商標）処理部２１、ＳＯＡＰ処理部２０、ＨＴＴＰ処理部１９、およびパケット監視処理部２４の上位層にあり、プリンタ４００がサポートする各種ネットワーク通信プロトコルを制御するとともに、プリンタコントローラ（Ｐｒｉｎｔｅｒ  Ｃｏｎｔｒｏｌｌｅｒ）２３との通信も処理する。
【００３５】
なお、スリープモードへの移行、解除情報の通信も、該通信処理部２２で実行される。
【００３６】
また、プロトコルスタック１７とパケット監視処理部２４はハードウエア上、他の処理部とは異なり、プリンタ４００がスリープモードに移行した際も、低消費電力で動作してパケット監視処理を継続して実行し、通信処理部２２により予め指定されたパケット受信を確認した際には、通信処理部２２に通知する機能を有する。
【００３７】
プロキシサーバ３００も同様に、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック９を備え、そのプロトコルスタック上にＨＴＴＰ１０を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。
【００３８】
ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック９上にはＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部１３を備え、その上位層には、ＵＰｎＰ（登録商標）プロトコル処理部１４、ＢＭＬｉｎｋＳ（登録商標）プロトコル処理部７を備える。
【００３９】
また、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック９上にはＡｐｐｌｅ社のネットワークプロトコルに対応するＲｅｎｄｅｚｖｏｕｓ（登録商標）処理部８を備える。
【００４０】
プロトコル代行処理部１６は、ＳＯＡＰ処理部１３、ＵＰｎＰ（登録商標）処理部１４、ＢＭＬｉｎｋＳ（登録商標）プロトコル処理部７、Ｒｅｎｄｅｚｖｏｕｓ（登録商標）処理部８、ＨＴＴＰ処理部１０、プロトコルスタック９の上位層にあり、ネットワーク対応デバイス、本実施形態ではネットワーク対応型プリンタがスリープモードに移行した際、プリンタ４００から指定されたプロトコルに関して代行処理を実行する。
【００４１】
また、プロトコル代行処理部１６は、ネットワーク対応型プリンタの情報を、記録装置制御部１５が制御する記録装置に管理テーブルの形式で記録する。
【００４２】
また、各代行プロトコル実行時に要する各種ドキュメントを記録装置制御部１５を介してＲｅａｄ／Ｗｒｉｔｅを実行する。
【００４３】
また、プロトコル代行処理部１６はＳＯＡＰ処理部１３を介して他のプロキシサーバから発行されたＮｏｔｉｆｙリクエストの詳細内容を取得し、その内容に応じた処理を実行する。
【００４４】
また、プロトコル変換処理部１６は、プロキシサーバ３００が管理する管理テーブルを記録装置制御部１５を介して、該制御部が制御する記録装置に対し書き込み、読み出し処理を行う。
【００４５】
以下に、これら本システムの制御の流れをフローチャートに従い説明する。
【００４６】
図２は、本発明に係るネットワークサービスシステムにおける第１のデータ処理手順の一例を示すフローチャートであり、図１に示したプリンタ４００におけるスリープモード移行処理手順に対応する。なお、（２−１）〜（２−６）は各ステップを示す。また、各ステップは、図１に示したプリンタコントローラ２３が、図示しないＲＯＭを含む記憶デバイスからＲＡＭ上に制御プログラムをロードして実行されるものとする。
【００４７】
まず、プリンタ４００は、所定の初期化処理を起動した後、ステップ（２−１）で、クライアント１００からＵＰｎＰ（登録商標）で規定される通信パケットが発行されてそれを受信しているかどうかを判断して、発行された通信パケットを受信していると判断した場合、およびプリントジョブが発行された場合、ＵＰｎＰ（登録商標）の規定に従い、ステップ（２−２）で、所定の処理を実行する。
【００４８】
次に、ステップ（２−３）で、ＴＣＰ／ＩＰ／ＵＤＰで規定された各種通信プロトコルに対し、プリンタ４００に対して発行された通信リクエストに対する応答処理を実行して、ステップ（２−１）へ戻る。
【００４９】
一方、ステップ（２−１）で、通信パケットを受信していないと判断した場合は、ステップ（２−４）で、プリンタ４００本体の操作部（図示しない）に設けられた特定のスイッチあるいは、所定のスイッチの押下指示によりスリープモードへの移行が指示されているかどうかを判断して、スリープモードへの移行が指示されていると判断した場合は、ステップ（２−６）へ進み、スリープモードに移行する。
【００５０】
一方、ステップ（２−４）で、スリープモードへの移行が指示されていないと判断した場合は、プリンタコントローラ２３内の図示しないタイマ機能を動作させて、あらかじめ設定されているスリープモード移行を決定する規定時間が経過しているかどうかを判断して（２−５）、規定時間が経過していないと判断されている場合には、ステップ（２−１）へ戻り、規定時間が経過していると判断されている場合には、ステップ（２−６）へ進み、スリープモードに移行する。
【００５１】
これにより、予め定められた時間の間に、ネットワークＮＥＴからの通信要求がなかった場合、あるいはプリンタ４００本体の操作部（図示しない）に設けられたスイッチの押下指示が検知されると、プリンタ４００がスリープモードへ移行する。
【００５２】
図３は、本発明に係るネットワークサービスシステムにおける第２のデータ処理手順の一例を示すフローチャートであり、図１に示したプリンタ通信処理部２２によるスリープモード処理において、代行して通信処理を実施可能なプロキシがネットワーク上に存在するか否か検索する手順に対応する。なお、（３−１）〜（３−６）はプリンタ４００側のステップに対応し、（３−１１）〜（３−１４）はプロキシ３００側のステップに対応する。また、各ステップは、各デバイスを記録装置制御部１５，プリンタコントローラ２３等が図示しないメモリデバイスから制御プログラムをロードして実行することにより実現されるものとする。
【００５３】
まず、プリンタ４００のプリンタ通信処理部２２は、図４に示すフォーマットのＨＴＴＰリクエストをＨＴＴＰパケットとして発行する（３−１）。
【００５４】
なお、本実施形態において、検索に使用されるプロトコルはＵＰｎＰ（登録商標）Ａｒｃｈｉｔｅｃｔｕｒｅ１．０にて規定されるＳＳＤＰを使用しており、ステップ（３−１）で、マルチキャストアドレス「２３９．２５５．２５５．２５０」をポート番号１９００に対し、図４に示すフォーマットのＨＴＴＰリクエストをＨＴＴＰパケットとして発行する。
【００５５】
図４は、図１に示したプリンタ４００よりネットワーク上に発行されるＨＴＴＰパケットの一例を示す図である。
【００５６】
本実施形態においては、ＨＴＴＰリクエストのエンティティボディとしてＳＯＡＰを使用し、検索パケット発行時に、プリンタが代行を委託するプロトコル情報を通知する。
【００５７】
その際の書式は、図４に示すように、ＨＴＴＰリクエスト中、Ｅｎｖｅｌｏｐｅタグ４−１−Ａ，４−１−Ｂ内に記述され、ＦｉｎｄＰｒｏｘｙリクエストの引数としてのＭｙＩＤ４−２は、ネットワークデバイス、本実施形態においては、例えばネットワーク上に複数のプリンタが接続されている場合において、図１に示したプリンタ４００のみを一義的に識別するためのユニークな情報（特定ＩＤ）であり、本実施形態においては、例えば１６文字からなるＡＳＣＩＩ文字列をＩＤとして使用している。そして、このＩＤこそが、後述するプロキシ３００がスリープモード状態のプリンタ４００に対する通信要求を受け付けた際に、極めて有効な情報として、すなわち、複数台のプリンタにマルチキャストすることなく、ピンポイントで、該当するプリンタを目覚めさせる通信先としての情報として機能し、後述するように、プロキシ３００がユニキャストでスリープ中の特定のプリンタに通知する際に参照される。
【００５８】
なお、上記ＩＤは、プリンタ４００のハード資源情報（例えばＭＡＣアドレス等）に演算処理を行って生成してもいいし、あらかじめ不揮発性のメモリに固体情報として割り当てても良い。
【００５９】
また、プロキシは複数のネットワークデバイスに対しプロトコル代行処理機能を提供することが可能であり、各デバイスからのリクエストを管理テーブルの形式で記録している。該ＩＤは管理テーブルの内容とデバイスとを対応付けるのに使用される。
【００６０】
ＲｅｑｕｅｓｔｅｄＰｒｏｔｏｃｏｌ４−３は、代行を委託するプロトコルを指定するタグである。
【００６１】
図４に示すＲｅｑｕｅｓｔｅｄＰｒｏｔｏｃｏｌ４−３の例では、プロトコルとして、ＵＰｎＰ（登録商標）  ｖ１プロトコルおよびＡｐｐｌｅ  Ｒｅｎｄｅｚｖｏｕｓ（登録商標）プロトコルが指定されている。これらプロトコルの代行処理が可能なプロキシの検索を意味する。
【００６２】
一方、図１に示したプロトコル代行処理サービスを備えたサーバ３００は、ＨＴＴＰリクエストを受信した後（３−１１）、そのリクエストのＳｅｒｖｉｃｅＴｙｐｅ（ＳＴ）ヘッダを解析する（３−１２）。
【００６３】
ここで、ＰｒｏｘｙＳｅｒｖｉｓ以外のＳＴ指定であったと判断した場合、あるいはパケット内容に不正があったと判断した場合は、所定のエンドに進み、処理を中断し、ＨＴＴＰリクエストに対してレスポンスを発行せずに無視する。そして、結果として、ステップ（３−１１）の検索パケット受信状態に戻る。
【００６４】
一方、ステップ（３−１２）で、ＳＴヘッダの内容がＰｒｏｘｙＳｅｒｖｉｓであったと判断した場合、引き続きＨＴＴＰリクエストのエンティティボディの解析を実行する。
【００６５】
すなわち、ＦｉｎｄＰｒｏｘｙリクエストの引数であるＲｅｑｕｅｓｔｅｄＰＲｏｔｏｃｏｌの内容をチェックし、このプリンタが指定したプロトコルに変換可能か否か（代行処理可能か否か）をプロトコル代行処理部１６が判定して（３−１３）、プリンタ４００が指定したプロトコルの変換の代行処理が不可能であると判断した場合は、エンドに進み、リクエストに対しレスポンスを発行せずに無視する。そして、結果として、ステップ（３−１１）の検索パケット受信状態に戻る。
【００６６】
一方、ステップ（３−１３）で、プロトコル代行処理部１６が代行処理が可能であると判定した場合、例えば図５に示すフォーマットのＨＴＴＰレスポンスをプリンタ４００に対しユニキャストで発行する（３−１４）。
【００６７】
図５は、図１に示したプロキシ３００からネットワークに発行されるＨＴＴＰレスポンスの一例を示す図である。
【００６８】
一方、プリンタ４００側では、レスポンス受信状態を通信処理部２２が判断し（３−２）、ネットワーク上からレスポンスを受信していないと判断した場合は、予め規定した時間、本実施形態では、例えば３０秒を計時するタイマがタイムアウトしたか否か、すなわち、３０秒以内に応答を受信したかどうかを判断して、タイムアウトしたと判断した場合は、本実施形態の場合、ＵＰｎＰ（登録商標）で規定されるｓｓｄｐ（ｂｙｅｂｙｅパケット）をマルチキャスト送信した後（３−４）、ネットワーク通信を一切遮断して、スリープモードへ移行する（３−６）。
【００６９】
これにより、プリンタ４００は、ｂｙｅｂｙｅパケットをマルチキャスト送信して、ネットワークＮＥＴ上のネットワーク対応機器に対し、プリンタ４００がネットワークからＯｆｆ  Ｌｉｎｅ状態になったことを通知される。
【００７０】
その際、ＨＴＴＰレスポンスのエンティティボディとしてＳＯＡＰを使用し、ＫｅｙＣｏｄｅ取得のためのＵＲＬ情報（ＫｅｙＣｏｄｅＵＲＬ）、および代行処理要求通知先ＵＲＬ（ＰｒｏｘｙＲｅｑｕｅｓｔＵＲＬ）を、後述する図６に示すフローチャートの手順に従ってプリンタ４００に対し通知する。
【００７１】
なお、図５において、ＫｅｙＣｏｄｅＵＲＬタグ５−１は、ＫｅｙＣｏｄｅ取得のためにプロキシ３００に対しリクエストを発行する宛先をＵＲＬ形式で記述するものである。
【００７２】
ＰｒｏｘｙＲｅｑｕｅｓｔＵＲＬタグ５−２は、代行処理要求パケットをプロキシに対し要求する際のパケット送信をＵＲＬ形式で記述するものである。
【００７３】
図１に示したプロキシ３００を含め、図１には図示しない複数のプロキシからレスポンスがあった場合は、本実施形態の場合、最初に通信処理部２２がレスポンスを受け取ったプロキシ３００を使用するものとする。
【００７４】
図６は、本発明に係るネットワークサービスシステムにおける第３のデータ処理手順の一例を示すフローチャートであり、図１に示した通信処理部２２によるスリープモード処理において、通信処理部は、プロキシに対しＫｅｙＣｏｄｅ情報取得のリクエストを発行する手順に対応する。なお、（６−１）〜（６−６）はプリンタ４００側のステップに対応し、（６−１１）〜（６−１３）はプロキシ３００側のステップに対応する。
【００７５】
まず、通信処理部２２は、プロキシ３００に対してＫｅｙＣｏｄｅ情報取得のリクエストを発行する（６−１）。
【００７６】
なお、ＫｅｙＣｏｄｅの取得にはＨＴＴＰ  ＰＯＳＴを使用しており、先に取得したプロキシのＫｅｙＣｏｄｅＵＲＬに対し、例えば図７示すフォーマットのＨＴＴＰリクエストを発行する。
【００７７】
図７は、図１に示した通信処理部２２よりネットワーク上に発行されるＨＴＴＰリクエストの一例を示す図である。
【００７８】
図７において、ＭｙＩＤ８−１は、プロキシ３００を一義的に識別するための情報であり、本実施形態においては１６文字からなるＡＳＣＩＩ文字列をＩＤとして使用している。
【００７９】
一度スリープ状態に移行した通信処理部２２は、ステップ（６−１）以降において、該ＫｅｙＣｏｄｅを持つプロキシ（プロキシ３００）からのみ通信を受け付けることになる。
【００８０】
なお、ＫｅｙＣｏｄｅの取得には、ＨＴＴＰ  ＰＯＳＴを使用しており、先に取得したプロキシのＫｅｙＣｏｄｅＵＲＬに対し、例えば図７示すフォーマットのＨＴＴＰリクエストを発行するが、その際、ＨＴＴＰリクエストのエンティティボディとしてＳＯＡＰを使用し、ＫｅｙＣｏｄｅ取得パケット発行時に、プリンタのＩＤ情報を通知する。その際の書式は図７のＨＴＴＰリクエスト中、Ｅｎｖｅｌｏｐｅタグ内に記述され、ＧｅｔＫｅｙＣｏｄｅリクエストの引数として、ＭｙＩＤタグ８−１を先のＤｉｓｃｏｖｅｒｙプロセスにおいて通知したプリンタ識別ＩＤとして通知する。
【００８１】
プロトコル代行処理サービスを備えたサーバ３００は、ＨＴＴＰリクエストを受信した後（６−１１）、ＫｅｙＣｏｄｅの生成を実行する（６−１２）。
【００８２】
なお、本実施形態において、ＫｅｙＣｏｄｅは、例えば１６文字からなるＡＳＣＩＩコードであり、各文字１文字ごとに乱数により生成される。
【００８３】
そして、ＫｅｙＣｏｄｅ生成後、プロキシ３００は受信したプリンタ（例えばプリンタ４００）のＩＤ情報を記録し、図８に示すフォーマットのＨＴＴＰレスポンスをプリンタに対しユニキャストで発行する（６−１３）。
【００８４】
図８は、図１に示したプロキシ３００がネットワークに発行するＨＴＴＰレスポンスの一例を示す図である。
【００８５】
その際、ＨＴＴＰレスポンスのエンティティボディとしてＳＯＡＰを使用し、ＫｅｙＣｏｄｅをプリンタ通信処理部に対し通知する。
【００８６】
一方、プリンタ４００側では、レスポンス受信状態を通信処理部２２が判断し（６−２）、ネットワーク上からレスポンスを受信していないと判断した場合は、予め規定した時間、本実施形態では、例えば３０秒を計時するタイマがタイムアウトしたか否か、すなわち、３０秒以内に応答を受信したかどうかを判断して（６−３）、タイムアウトしたと判断した場合は、本実施形態の場合、ＵＰｎＰ（登録商標）で規定されるｓｓｄｐ（ｂｙｅｂｙｅパケット）をマルチキャスト送信した後（６−４）、ネットワーク通信を一切遮断して、スリープモードへ移行する（６−５）。
【００８７】
一方、ステップ（６−２）で、プロキシ３００からＨＴＴＰレスポンスを受信した場合、ステップ（６−６）で、プリンタ４００の通信処理部２２は、通知されたｋｅｙＣｏｄｅを記録した後、プロキシ３００に対して代行処理を依頼するための、図９に詳細手順を示すプロトコルの指定処理を行う。
【００８８】
図９は、本発明に係るネットワークサービスシステムにおける第４のデータ処理手順の一例を示すフローチャートであり、図１に示した通信処理部２２によるスリープモード処理における、通信処理部がプロキシに対し代行委託リクエストを発行する手順に対応する。なお、（９−１）〜（９−６）はプリンタ４００側のステップに対応し、（９−１１）〜（９−１４）はプロキシ３００側のステップに対応する。
【００８９】
まず、プリンタ４００の通信処理部２２は、ＨＴＴＰリクエストを発行する（９−１）。
【００９０】
なお、本実施形態では、ＵＰｎＰ（登録商標）、ＢＭＬｉｎｋＳ（登録商標）、Ａｐｐｌｅ  Ｒｅｎｄｅｚｖｏｕｓ（登録商標）プロトコルの指定のほか、さらに各フェイズ毎に代行の依頼が可能であり、代行処理の委託にはＨＴＴＰ  ＰＯＳＴを使用しており、先に取得したＰｒｏｘｙＲｅｑｕｅｓｔＵＲＬに対し、例えば図１０示すフォーマットのＨＴＴＰリクエストを発行するものとする。
【００９１】
図１０は、図１に示した通信処理部２２よりネットワーク上に発行されるＨＴＴＰリクエストの一例を示す図である。
【００９２】
なお、本実施形態では、ＨＴＴＰリクエストのエンティティボディとしてＳＯＡＰを使用し、代行処理委託パケット発行時に、プリンタのＩＤ情報を通知する。
【００９３】
その際の書式は、図１０に示すＨＴＴＰリクエスト中、Ｅｎｖｅｌｏｐｅタグ１０−１Ａ，１０−１−Ｂ内に記述され、ＰｒｏｘｙＲｅｑｕｅｓｔ（ＰｒｏｘｙＲｅｑｕｅｓｔｅｄタグ１０−２−Ａ，１０−２−Ｂ内の引数として、ＭｙＩＤ、すなわち先のＤｉｓｃｏｖｅｒｙプロセスにおいて通知した識別ＩＤを通知する。
【００９４】
なお、本実施形態において、プロキシ３００は複数のプロトコルを代行処理することが可能であり、Ｐｒｏｔｏｃｏｌタグ１０−３−Ａ，１０−３−Ｂ内には記述されたプロトコル、および各フェイズに対して指定された代行処理を実行する。この記述において記載されていないプロトコルにに対しては代行実行はされない。すなわち、プロキシはこの記述に記載されていないプロトコル通信には応じない。
【００９５】
また、ＰｒｏｔｏｃｏｌＮａｍｅタグ１０−３には、代行処理を委託するプロトコル名称が記述され、Ｐｒｏｘｙタグ１０−４には、プロキシに全ての処理を委託するフェイズ、プロセスが指定される。
【００９６】
ここで、例えばＡＬＬを記述すると、すべてのフェイズ、プロセスをプロキシに代行処理委託することを意味する。
【００９７】
さらに、ＷａｋｅＵＰタグ１０−５には、ここで指定されたフェイズ、プロセスをプロキシが受信した場合、ＭｙＩＤで識別されるデバイスに対しＷａｋｅＵＰパケットを発行する。
【００９８】
ここで、例えばＡＬＬを記述すると、ＰｒｏｔｏｃｏｌＮａｍｅで指定したプロトコルのすべてのフェイズ、プロセスに関してプロキシからデバイスに対し、ＷａｋｅＵＰパケットを発行することを意味する。
【００９９】
なお、図１０の記述例の場合、ＵＰｎＰ（登録商標）  ｖ１プロトコルを構成する各フェイズに対して、Ｄｉｓｃｏｖｅｒｙ  Ｐｈａｓｅ，Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｈａｓｅ，Ｅｖｅｎｔ  Ｓｕｂｓｃｒｉｂｅはプロキシに代行を委託することが記述されている。
【０１００】
そして、Ｃｏｎｔｒｏｌ，Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｐｈａｓｅに関しては、プロキシ３００がクライアント１００から要求パケットを受け取った場合、プリンタ４００をＷａｋｅＵｐすることを依頼する記述であることを意味する。
【０１０１】
また、Ａｐｐｌｅ  Ｒｅｎｄｅｚｖｏｕｓ（登録商標）プロトコルに対しては、全プロセスに対しプロキシがクライアントから要求パケットを受け取った場合、プリンタ４００をＷａｋｅＵＰすることを依頼することを意味する。
【０１０２】
また、その他のプロトコルに関してはクライアントからの要求パケットに対し、一切応答しないことを依頼することを意味する。
【０１０３】
なお、Ｐｒｏｔｏｃｏｌタグ１０−３−Ａ，１０−３−Ｂ内の定義は任意であり、プロトコルの定義のフォームに従い、例えば応答すべきプロトコルの列挙の場合や、任意のプロトコルの組合せに応答するように記述して、応答すべきプロトコル態様を柔軟に設定できるように構成してもよい。
【０１０４】
これにより、ネットワーク管理者や、特定のユーザがネットワーク上のスリープ状態のプリンタ４００をジョブ受信待機状態に復帰させるために応答すべきパケットを意図する受信環境を自在に整備することができる。
【０１０５】
プロトコル代行処理サービスを備えたサーバ３００は、ＨＴＴＰリクエストを受信した後（９−１１）、エンティティボディの解析を実行し、プリンタ通信処理部からの要求内容をチェックし（９−１２）、要求内容に不正が無いと判断した場合は、通信処理部２２からの要求内容を記録装置制御部１５を介して図示しない記録装置上に確保される管理テーブルに記録する（９−１３）。
【０１０６】
そして、通信処理部２２からの要求内容を管理テーブルを記録した後、プロキシ３００は図１１に示すフォーマットのＨＴＴＰレスポンスをプリンタ４００に対しユニキャストで発行する（９−１４）。
【０１０７】
図１１は、図１に示した通信処理部２２よりネットワーク上に発行されるＨＴＴＰレスポンスの一例を示す図である。
【０１０８】
一方、ステップ（９−２）で、プリンタ４００の通信処理部２２では、プロキシ３００からＨＴＴＰレスポンスを受信していないと判断した場合、ネットワーク上からレスポンスを受信していないと判断した場合は、予め規定した時間、本実施形態では、例えば３０秒を計時するタイマがタイムアウトしたか否か、すなわち、３０秒以内に応答を受信したかどうかを判断して（９−３）、タイムアウトしたと判断した場合は、本実施形態の場合、ＵＰｎＰ（登録商標）で規定されるｓｓｄｐ（ｂｙｅｂｙｅパケット）をマルチキャスト送信した後（９−４）、ネットワーク通信を一切遮断して、スリープモードへ移行する（９−５）。
【０１０９】
一方、ステップ（９−２）で、プロキシ３００から、図１１に示すフォームのＨＴＴＰレスポンス（ＨＴＴＰ／１．１  ２００  ＯＫ）を受信した場合、ステップ（９−６）で、プリンタ４００の通信処理部２２は、図１２に詳細手順を示すスリープモード移行処理を行う。
【０１１０】
図１２は、本発明に係るネットワークサービスシステムにおける第５のデータ処理手順の一例を示すフローチャートであり、図１に示した通信処理部２２によるスリープモード処理手順に対応する。なお、（１２−１）〜（１２−５）はプリンタ４００側のステップに対応し、（１２−１１）〜（１２−１７）はプロキシ３００側のステップに対応する。
【０１１１】
プリンタ４００における通信処理部２２は、プロキシ３００からのレスポンスを受け取った後、スリープ移行処理を開始するが、本実施形態の場合、図１０に示したように、プロキシ３００に対しＵＰｎＰ（登録商標）  ｖ１で規定されるＤｉｓｃｏｖｅｒｙ／Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｈａｓｅの代行処理を委託しており、次のステップとしてプロキシ３００から発行されるＤｉｓｃｏｖｅｒｙ／Ｄｅｓｃｒｉｐｔｉｏｎ要求処理の実行を行う。
【０１１２】
この処理によりプロキシ３００は代行処理に必要な情報をプリンタ４００の通信処理部２２より取得し、該取得した情報は記録装置制御部１５を介して記録装置上に記録される。
【０１１３】
具体的には、プリンタ４００は、Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｈａｓｅの委託が要求されているかどうかを判断して（１２−１）、要求されていないと判断した場合は、ＵＰｎＰ（登録商標）で規定されるｓｓｄｐ（ｂｙｅｂｙｅパケット）をマルチキャスト送信した後（１２−４）、スリープモードへ移行する（１２−５）。
【０１１４】
Ｐｒｏｘｙに代行を委託した場合は、スリープモードに移行すると、ネットワーク通信の主だった処理は遮断される。しかし、ネットワーク通信そのものが完全に遮断されるのではなく、ＷａｋｅＵＰパケット監視を実行する。
【０１１５】
一方、ステップ（１２−１）で、Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｈａｓｅの委託が要求されていると判断した場合には、プロキシ３００からのＤｅｓｃｒｉｐｔｉｏｎに関する属性情報等の取得要求が発行されるのを待ち（１２−２）、プロキシ３００からの取得要求を受け付けると、Ｄｅｓｃｒｉｐｔｉｏｎ要求（応答）を発行した後（１２−３）ＵＰｎＰ（登録商標）で規定されるｓｓｄｐ（ｂｙｅｂｙｅパケット）をマルチキャスト送信した後（１２−４）、スリープモードへ移行する（１２−５）。
【０１１６】
一方、プロキシ３００では、図１０に示したように、ＤｅｓｃｒｉｐｔｉｏｎＰｈａｓｅの代行が指定されているかどうかを判断して（１２−１１）、ＤｅｓｃｒｉｐｔｉｏｎＰｈａｓｅの代行が指定されていないと判断した場合は、ＵＰｎＰ（登録商標）で規定されるｓｓｄｐ（ｂｙｅｂｙｅパケット）をプリンタ４００の通信処理部２２から受信した後（１２−１２）、プロキシ３００は、ＵＰｎＰ（登録商標）  ｖ１で規定されるｓｓｄｐ（ａｌｉｖｅ）パケットをマルチキャストでネットワークＮＥＴ上に送信（発行）した後（１２−１４）、プロキシ代行通信を開始する（１２−１７）。
【０１１７】
一方、ステップ（１２−１１）で、ＤｅｓｃｒｉｐｔｉｏｎＰｈａｓｅの代行が指定されていると判断した場合は、プリンタ４００の通信制御部２２に対して、Ｄｅｓｃｒｉｐｔｉｏｎ要求を発行して（１２−１４）、プリンタ４００の通信制御部２２からＤｅｓｃｒｉｐｔｉｏｎ要求に対するＲｅｓｐｏｎｓｅ受信を待ち（１２−１５）、該Ｄｅｓｃｒｉｐｔｉｏｎ要求に対するＲｅｓｐｏｎｓｅを受信したら、リクエスト内容を記録装置制御部１５内に確保される管理テーブルに記録する（１２−１６）。
【０１１８】
次に、ＵＰｎＰ（登録商標）で規定されるｓｓｄｐ（ｂｙｅｂｙｅパケット）をプリンタ４００の通信処理部２２から受信した後（１２−１２）、プロキシ３００は、ＵＰｎＰ（登録商標）  ｖ１で規定されるｓｓｄｐ（ａｌｉｖｅ）パケットをマルチキャストでネットワークＮＥＴ上に送信（発行）した後（１２−１４）、プロキシ代行通信を開始する（１２−１７）。
【０１１９】
なお、ＵＰｎＰ（登録商標）  ｖ１以外のプロトコルで、あらかじめプロキシ３００に対しプリンタ４００の属性情報等を通知する必要がある場合は、ステップ（１２−１６）で、プリンタ通信処理部２２からプロキシのプロトコル代行処理部１６に対し、各プロトコルで規定された手順に従い通知し、これら属性情報等を受信したプロキシ３００のプロトコル代行処理部１６は記録装置制御部１５を介して記録装置上に記録する。
【０１２０】
これら処理が完了した時点で、プリンタ通信処理部２２は、ネットワークから離脱したことを通知するため、ＵＰｎＰ（登録商標）  ｖ１で規定されるＢｙｅＢｙｅパケットをマルチキャストでネットワーク上に送信した後、プリンタ４００の通信処理部２２はＰｒｉｎｔｅｒ  Ｃｏｎｔｒｏｌｌｅｒに対し、スリープモード移行を通知する。
【０１２１】
これ受けて、Ｐｒｉｎｔｅｒ  Ｃｏｎｔｒｏｌｌｅｒ２３はスリープモードに移行する。パケット監視処理部２４およびＴＣＰ／ＩＰ／ＵＤＰプロトコルスタック部１７のみに、図示しない電源制御部による制御に従い電力供給される省電力モードへ移行する。
【０１２２】
図１３は、本発明に係るネットワークサービスシステムにおける第６のデータ処理手順の一例を示すフローチャートであり、図１に示したプロキシ３００によるプロトコル代行処理手順に対応する。なお、（１３−１）〜（１３−９）はプリンタ４００側のステップに対応し、（１３−１１）〜（１３−２０）はプロキシ３００側のステップに対応する。
【０１２３】
まず、プロキシ３００のプロトコル代行処理部１６は、ネットワークＮＥＴを介してパケットを受信すると（１３−１１）、受信パケットの内容を記録装置制御部１５が管理する管理テーブル上の登録情報と比較しながら参照し（１３−１２）、受信したパケットの内容が管理テーブルに存在しないプロトコル、フェイズであるかどうかを判断して（１３−１３）、存在しないプロトコル、フェイズであると判断した場合は、受信内容を破棄、応答処理を実行することなく、ステップ（１３−１１）のパケット受信待機状態となる。
【０１２４】
一方、ステップ（１３−１３）で、管理テーブルと比較し、管理テーブルに記録されたプロトコル、フェイズと一致したと判断した場合は、ステップ（１３−１４）で、これらプロトコル、フェイズが＜Ｐｒｏｘｙ＞タグに記述されているかどうかを判断して、これらプロトコル、フェイズが＜Ｐｒｏｘｙ＞タグに記述されていると判断した場合、本実施形態の場合、ＵＰｎＰ（登録商標）  ｖ１プロトコルのＤｉｓｃｏｖｅｒｙ／Ｄｅｓｃｒｉｐｔｉｏｎ／Ｅｖｅｎｔ  Ｓｕｂｓｃｒｉｂｅフェイズのいずれかに該当するが、プロキシ３００のプロトコル代行処理部１６は該当するプロトコル処理部７，８，１４のいずれかに対して受信したパケットを通知する。
【０１２５】
そして、プロキシ３００のプロトコル処理部７，８，１４のいずれかは、受信したパケットを解析し、必要に応じ予めデバイスから取得し、記録装置制御部１５の記録装置に記録された属性情報に基づいて、返信パケットを代替生成した後（１３−１５）、返送処理を実行して（１３−１６）、ステップ（１３−１１）のパケット受信待機状態に戻る。
【０１２６】
一方、ステップ（１３−１４）で、＜Ｐｒｏｘｙ＞タグに記述されていないと判断した場合は、記録装置制御部１５が確保して管理する管理テーブル内の属性情報を含む情報とを比較し、管理テーブルに記録されたプロトコル、フェイズであると判断した場合、例えばプロトコル、フェイズが＜ＷａｋｅＵＰ＞タグに記述されている場合、本実施形態の場合、ＵＰｎＰ（登録商標）  ｖ１プロトコルのＣｏｎｔｒｏｌ／Ｐｒｅｓｅｎｔａｔｉｏｎフェイズ、およびＡｐｐｌｅ  Ｒｅｎｄｅｚｖｏｕｓ（登録商標）プロトコルの全フェイズが該当するが、プロキシ３００のプロトコル代行処理部１６は、クライアント１００から受信したパケットを記録装置制御部１５を介して記録装置に記録した後（１３−１７）、管理テーブルに記録された代行処理を委託したデバイス、本実施形態の場合プリンタ４００に対しＷａｋｅＵＰパケットを送信（発行）する（１３−１８）。
【０１２７】
なお、本実施形態において、ＷａｋｅＵＰパケットにはＨＴＴＰ  ＰＯＳＴを使用しており、管理テーブルに記録される代行処理を委託したプリンタ４００のＵＲＬに対し、図１４示すフォーマットのＨＴＴＰリクエストを発行する。
【０１２８】
図１４は、図１に示したプロキシ３００よりネットワーク上に発行されるＨＴＴＰリクエストの一例を示す図である。
【０１２９】
なお、ＨＴＴＰリクエストを発行する際、本実施形態においては、ＨＴＴＰリクエストのエンティティボディとしてＳＯＡＰを使用し、代行処理委託パケット発行時に、プロキシのＫｅｙＣｏｄｅ情報を通知する。その際の書式は、図１４のＨＴＴＰリクエスト中、Ｅｎｖｅｌｏｐｅタグ１４−１−Ａ，１４−１−Ｂ内に記述され、ＷａｋｅＵＰＲｅｑｕｅｓｔタグ１４−２−Ａ，１４−２−Ｂの引数として、＜ＫｅｙＣｏｄｅ＞タグ１４−３でＫｅｙＣｏｄｅを通知する。
【０１３０】
プリンタ４００のパケット監視処理部２４では受信パケットの宛先アドレス、および送信元アドレスのみをチェックし（１３−１）、宛先アドレスが自身のＭＡＣアドレスであり、かつ送信元アドレスがプロキシ３００のＭＡＣアドレスと一致した場合のみ、プリンタ４００の通信処理部２２に対し起動要求を通知する（１３−２）。
【０１３１】
そして、起動要求をうけた通信処理部２２はスリープモードの解除をＰｒｉｎｔｅｒ  Ｃｏｎｔｒｏｌｌｅｒに通知し（１３−３）、次にプロキシ３００から発行されたＨＴＴＰパケットのエンティティをチェックする。
【０１３２】
そして、通知されたＫｅｙＣｏｄｅとステップにおいて取得し、予め記録しておいたＫｅｙＣｏｄｅと比較して一致するかどうかを判断し（１３−４）、該ＫｅｙＣｏｄｅが一致しないと判断した場合、あるいはＫｅｙＣｏｄｅが存在しない場合はプリンタの通信処理部はパケットを無視し、再びスリープモードに移行する（１３−９）。
【０１３３】
これにより、ＰｒｉｎｔｅｒＣｏｎｔｒｏｌｌｅｒ部に通知し省電力モードに移行する。
【０１３４】
一方、ステップ（１３−４）で、該ＫｅｙＣｏｄｅが一致したと判断した場合、プリンタ４００の通信処理部２２はプロキシ３００に対し、図１５に示すフォーマットのＨＴＴＰレスポンスを返信する（１３−５）。
【０１３５】
図１５は、図１に示したプリンタ４００の通信制御部２２より返信されるＨＴＴＰレスポンスの一例を示す図である。
【０１３６】
一方、該ＨＴＴＰレスポンスを受け取とると（１３−１９）、プロキシ３００は、プリンタ４００に対して記録したクライアント１００から受信した要求パケットを、プリンタ４００に対して送信する（１３−２０）。
【０１３７】
そして、プロキシ３００から要求パケットを受信すると（１３−６）、プリンタ４００において、該要求パケットを受信したプリンタ４００の通信処理部２２は、要求パケットの内容を解析し、該当するジョブを実行する（１３−７）。そして、図１６に示す手順に従ってプリンタ４００に対する再起動処理を行う（１３−８）。
【０１３８】
図１６は、本発明に係るネットワークサービスシステムにおける第７のデータ処理手順の一例を示すフローチャートであり、図１に示したプロキシ３００によるプロトコル代行処理手順に対応する。なお、（１６−１），（１６−２）はプリンタ４００側のステップに対応し、（１６−１１）〜（１６−１３）はプロキシ３００側のステップに対応する。
【０１３９】
プリンタ４００側で、ジョブが完了したら（１６−１）、該ジョブが完了した時点で、スリープモードから復帰しサービスを再開したことを他のネットワークデバイスに通知するため、ＵＰｎＰ（登録商標）  ｖ１で規定されるＮｏｔｉｆｙ  ｓｓｄｐ（ａｌｉｖｅパケット）をマルチキャストで発行する（１６−２）。
【０１４０】
一方、該Ｎｏｔｉｆｙパケットを受信したら（１６−１１）、プロキシ３００は、記録装置制御部１５が確保して管理する管理テーブルより、該Ｎｏｔｉｆｙパケットを発行したデバイス情報を削除し（１６−１２）、プロキシは代行処理を停止したことを他のネットワークデバイスに通知するため、ＵＰｎＰ（登録商標）  ｖ１で規定されるＮｏｔｉｆｙ  ｓｓｄｐ：ＢｙｅＢｙｅパケットをマルチキャストで発行して（１６−１３）、該デバイスに対する代行処理を終了する。
【０１４１】
本実施形態では、以上、一連の動作を繰り返すことで、プリンタ４００はスリープモード移行時にプロキシ３００に対し代行処理の委託を実現する。
【０１４２】
〔第２実施形態〕
上記実施形態では、例えばプリンタ４００をネットワークデバイスとした実施形態を示しているが、ネットワーク対応型デバイスとしては、他に、ハードディスク等のストレージデバイス、スキャナ、複写機、およびそれら複合機能を備えるデバイスであって、通信機能を介してプロトコル代行サーバと属性情報の交換、ジョブの送受信が可能な通信機能を備えた装置であればいずれの場合においても実現可能である。
【０１４３】
〔第３実施形態〕
また、上記実施形態では、プロトコルを代行するプロキシをＵＰｎＰ（登録商標）  ｖ１で規定されるＤｉｓｃｏｖｅｒｙプロトコル  ＳＳＤＰ  （Ｓｉｍｐｌｅ  Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ）を使用しているが、ＳＬＰ  （Ｓｅｒｖｉｃｅ  Ｌｏｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）など他の標準化された、あるいは独自のプロトコルを使用して実現することも可能である。
【０１４４】
〔第４実施形態〕
また、上記実施形態のように、動的にプロトコルを代行するプロキシを検索するのではなく、プリンタに予め、操作部等を介して、代行プロキシのアドレスを設定しておく実施形態も可能である。
【０１４５】
〔第５実施形態〕
また、上記実施形態では、ネットワーク対応型デバイスを例として説明したが、デバイスとプロトコルを代行するプロキシサーバ間は、ＵＳＢ、ＩＥＥＥ１３９４、パラレルなどのローカル接続による通信によっても実現可能である。
【０１４６】
〔第６実施形態〕
さらに、上記実施形態において、プロトコルを代行するプロキシは、ネットワーク上、物理的に独立したデバイス上に実装された機能として説明されているが、プリンタ等のデバイスに組み込まれた形でも本発明は実現可能である。
【０１４７】
すなわち、図１におけるプリンタにおいて、プロトコル代行処理部が、プリンタコントローラ、通信制御部と同一のハードウエア上に実装され、プリンタコントローラ、通信制御部とは物理的に電源が独立しており、プリンタコントローラ、通信制御部が省電力モードに移行しても、プロトコル代行処理部が本実施形態で示した機能を実現するだけの電力供給が可能な構成をとる場合においても実現可能である。
【０１４８】
〔第７実施形態〕
また、上記実施形態において、デバイスの識別ＩＤ、およびプロキシのＫｅｙＣｏｄｅとしても１６文字からなる文字列を使用しているが、一義的に識別できる情報ならば、ＭＡＣアドレス、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ  Ｕｎｉｑｕｅ
ＩＤ）などを使用しても実現可能である。
【０１４９】
さらに他のデバイスからの、なりすましを防御する意味から、これらＩＤ、ＫｅｙＣｏｄｅは暗号化手続きにより暗号化された情報を用いる場合も実現可能である。
【０１５０】
〔第８実施形態〕
また、上記実施形態では、代行プロトコル指定の際に代表的なプラグアンドプレイ関係のプロトコルを実施形態として示しているが、特定のデータ列を持つパケットの指定による、パケット単位の代行処理、ＷａｋｅＵＰ指定あるいは、特定のマルチキャストアドレスの指定による、アドレス単位の代行処理、ＷａｋｅＵＰ指定、あるいは、特定のＭＡＣアドレス、ＩＰアドレスを持つパケットに対する代行処理、ＷａｋｅＵＰ指定などを実現することも可能である。
【０１５１】
〔第９実施形態〕
さらに、上記実施形態では、プリンタのパケット監視処理部はパケットの宛先がプリンタ自身のＭＡＣアドレスであり、かつ送信元がプロキシのＭＡＣアドレスであった場合に、通信処理部に対し起動要求を発行しているが、該パケット監視処理部においてＫｅｙＣｏｄｅの判定処理まで実施させ、ＫｅｙＣｏｄｅまで一致した場合にのみ、通信処理部に対し起動要求を発行する処理を実現することも可能である。
【０１５２】
〔第１０実施形態〕
また、上記実施形態では、Ｅｔｈｅｒｎｅｔ（登録商標）を物理層とするネットワークを一例としてあげたが、ＩＥＥＥ８０２．１１  無線ＬＡＮ／Ｂｌｕｅｔｏｏｔｈ（登録商標）や他のネットワークシステムにおいても同様に実施可能である。
【０１５３】
〔第１１実施形態〕
さらに、上記実施形態では、ネットワークデバイスであるプリンタと、プロトコル代行を実行するプロキシとの間の通信にはＸＭＬ／ＳＯＡＰ形式のパケットデータを使用しているが、これらは、独自に定義したバイナリデータを使用することでも実現可能である。
【０１５４】
〔第１２実施形態〕
また、上記実施形態では、ＵＰｎＰ（登録商標）  ｖ１を例として挙げているため、ネットワーク復帰、スリープモード移行の際に該プロトコルで規定されるＮｏｔｉｆｙパケットを発行しているが、その他のプロトコルを実行している場合、各プロトコルで規定された、Ｎｏｔｉｆｙ、通知パケットを発行する必要がある。
【０１５５】
また、プロキシが発見できなかった場合、プロキシからの応答が無かった場合等、上記実施形態では、ネットワーク通信を一切遮断してスリープモードへ移行しているが、この場合、スリープモードへの移行を禁止することで、クライアントからの通信を優先させる設定を設けることも可能である。
【０１５６】
さらに、あるいはパケット監視処理部において、プリンタ自身宛のパケット受信を検出するごとにスリープモードを解除するモードを設けることも可能である。
【０１５７】
〔第１３実施形態〕
さらに、上記実施形態において、プロキシからのＷａｋｅＵＰを受け付けた後、プリンタはスリープモード解除を実行しているが、ジョブ終了後に再びスリープモードに移行するモードを設けることも可能である。
【０１５８】
〔第１４実施形態〕
また、上記実施形態では、プロトコル代行を実施するプロキシは複数のプロトコル代行をサポートしているが、単独のプロトコルのみの代行をサポートするプロキシ、あるいは実施形態以上の複数のプロトコルをサポートするプロキシに対しても本発明は適用してプリントシステムを構築することも能である。
【０１５９】
〔第１５実施形態〕
さらに、特定のサービス提供デバイス１台のみならず、複数の特定のサービス提供デバイスから構成される特定のサービス提供デバイスグループ（メーカ別、あるいは機能処理能力別（カラー印刷の有無、処理スピードの有無、オプション機能の有無等を考慮して）等）を一斉に節電モードへ移行させた、該複数の特定のサービス提供デバイスを一斉にアライブ状態に復帰させる場合と、該複数の特定のサービス提供デバイス中の識別される特定のサービス提供デバイスのみを一斉にアライブ状態に復帰させる場合と切り換え制御可能に構成してもよい。
【０１６０】
これにより、ＵＰｎＰ（登録商標）規格に準ずるネットワーク機器の仕様に左右されることなく、サービス提供デバイスの節電機能を格段に向上させることが可能となるとともに、スリープモードに移行した特定のサービス提供デバイスのみをネットワーク上のトラフィックに影響を与えることなく、簡単な通知パケットを通信するだけでピンポイントに目覚めさせることができる。
【０１６１】
したがって、サービス提供デバイスに要求される節電機能を有効活用し、システム全体として従来に比べて節電効果が格段に向上する。
【０１６２】
〔第１６実施形態〕
なお、上記各実施形態では、有線ネットワークを例とするシステムについて説明したが、無論無線ネットワーク（いわゆる、Ｂｌｕｅｔｏｏｔｈ（登録商標）仕様に準拠するネットワーク）においても、本発明を適用することができる。その際、サービス提供デバイスとして、各種の無線通信可能な携帯ツール、例えばＢｌｏｏｔｏｏｔｈ仕様の通信処理を代行可能なＰＤＡ，携帯電話等を利用して本発明に係るシステムを構築すれば、さらに有用なシステムを構築できることは言うまでもない。
【０１６３】
〔第１７実施形態〕
また、上記実施形態では、通信機能を制限して節電モードへ移行する際に、所定の節電レベルに一斉に移行させる場合について説明したが、節電レベルを段階的に設定可能なデバイスである場合には、節電モードへの移行制御を変更することにより、デバイス特有の機能処理に合わせて柔軟な節電モード処理も可能となる。
【０１６４】
〔第１８実施形態〕
さらに、上記実施形態では、プリンタ４００が、自機宛に対する通信状態を所定時間監視して、上述した代行節電処理を行う場合について説明したが、プリンタ４００の操作部、あるいはクライアント（管理者権限のある）、さらには、プロキシ３００より、当該処理を実行すべき有効な時間帯をスケジュール設定して、当該時間帯において、上述した処理を限定的に実行可能に構成してもよい。
【０１６５】
〔第１９実施形態〕
また、プロキシ３００は、スリープ中のプリンタを識別可能に管理しているので、特定のアクセス権限のあるクライアントから、スリープ中のプリンタに関する情報を取得して、クライアント先でスリープ中のプリンタ一覧（スリープ開始時とその経過時間を表示を含めて）をリスト表示して、システム管理者等がプリンタの節電状況を把握できるように構成してもよい。
【０１６６】
〔第２０実施形態〕
さらに、クライアントがプロキシ３００との通信により、スリープ状態に移行したプリンタの情報に従い、プロキシ３００にブランチするような表示構造で、スリープ中のプリンタアイコンをプロキシ３００に従属表示できるように構成してもよい。
【０１６７】
以下、図１７に示すメモリマップを参照して本発明に係るプリントシステムで読み出し可能なデータ処理プログラムの構成について説明する。
【０１６８】
図１７は、本発明に係るプリントシステムで読み出し可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【０１６９】
なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１７０】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１７１】
本実施形態における図２，図３，図６，図９，図１２，図１３，図１６に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１７２】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１７３】
この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１７４】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ等を用いることができる。
【０１７５】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１７６】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１７７】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から排除するものではない。
【０１７８】
本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではなく、以下の実施態様も含まれることはいうまでもない。以下、その実施態様１〜２８について説明する。
【０１７９】
〔実施態様１〕
ネットワーク（例えば図１に示すネットワークＮＥＴ）に接続された所定の機能処理を実行するサービス提供デバイス（図１に示すプリンタ４００）と、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイス（例えば図１に示すクライアントＰＣ１００を含む）とが通信可能なネットワークサービスシステムであって、各サービス提供デバイスは、所定のサービス提供処理が予め定められた時間実行されなかった場合、いずれかのクライアントデバイスからの通信機能要求に応える特定の通信機能を指定して、該指定される特定の通信機能に基づく通信処理をネットワーク上のいずれかのサービス提供デバイスに代行させ、前記ネットワーク上のクライアントデバイスから認識されないネットワークスリープ状態に移行させる代行処理手段（例えば図１に示すプロキシ３００のプロトコル代行処理部１６等）を備えることを特徴とするネットワークサービスシステム。
【０１８０】
〔実施態様２〕
前記代行処理手段は、前記ネットワークスリープ状態に移行した後、電力消費を抑える動作モード移行処理を実行することを特徴とする実施態様１記載のネットワークサービスシステム。
【０１８１】
〔実施態様３〕
前記代行処理手段は、前記ネットワークスリープ状態に移行した後、代行依頼したサービス提供デバイスからスリープ解除要求を受けることに応じて、前記ネットワークスリープ状態をネットワークアライブ状態に移行することを特徴とする実施態様１記載のネットワークサービスシステム。
【０１８２】
〔実施態様４〕
前記ネットワークスリープ状態をネットワークアライブ状態に移行する条件は、指定される前記特定の通信機能あるいは特定の通信機能の組合せに基づいて決定されることを特徴とする実施態様１記載のネットワークサービスシステム。
【０１８３】
〔実施態様５〕
前記サービス提供デバイスは、プロキシサーバであることを特徴とする実施態様１〜４の何れかに記載のネットワークサービスシステム。
【０１８４】
〔実施態様６〕
ネットワーク（例えば図１に示すネットワークＮＥＴ）に接続された所定の機能処理を実行するサービス提供デバイス（図１に示すプリンタ４００）と、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイス（例えば図１に示すクライアントＰＣ１００を含む）とが通信可能なネットワークサービスシステムであって、予め定められた時間、所定のサービス提供処理が実行されなかった場合、サービス提供デバイスが提供する通信機能に制限し、該制限された通信機能を代行して処理する制限手段（例えば図１に示すプロキシ３００のプロトコル代行処理部１６等）を前記サービス提供デバイス上に設けたことを特徴とするネットワークサービスシステム。
【０１８５】
〔実施態様７〕
前記制限手段は、通信機能に制限を実施する以前に、制限された通信機能を代行して処理するサービス提供デバイスに対して代行処理を委託することを特徴とする実施態様６記載のネットワークサービスシステム。
【０１８６】
〔実施態様８〕
前記制限手段は、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託する通信機能を指定可能とすることを特徴とする実施態様６記載のネットワークサービスシステム。
【０１８７】
〔実施態様９〕
前記制限手段は、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託しない通信機能を指定可能とすることを特徴とする実施態様６記載のネットワークサービスシステム。
【０１８８】
〔実施態様１０〕
前記制限手段は、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託した通信機能に対し全ての機能、あるいは一部の通信機能の代行処理を委託可能とすることを特徴とする実施態様６記載のネットワークサービスシステム。
【０１８９】
〔実施態様１１〕
通信機能代行処理中のサービス提供デバイスが前記ネットワークを介して、通信機能を代行して処理するサービス提供デバイスが制限された通信機能に関連する通信データを受信した場合、代行処理中のサービス提供デバイスが通信機能が制限されている被制限サービス提供デバイスに対してその旨の通知処理を行うことを特徴とする実施態様６記載のネットワークサービスシステム。
【０１９０】
〔実施態様１２〕
前記制限手段は、前記通信機能代行処理中のサービス提供デバイスより前記被制限サービス提供デバイスに前記その旨の通知があった場合、通信機能に対する制限を解除する機能を有することを特徴とする実施態様６記載のネットワークサービスシステム。
【０１９１】
〔実施態様１３〕
前記制限手段は、あらかじめ通知された識別子と同一の識別子をもつ通信機能を代行して処理するサービス提供デバイスより前記その旨の通知があった場合に、前記通信機能に対する制限を解除することを特徴とする実施態様１２記載のネットワークサービスシステム。
【０１９２】
〔実施態様１４〕
ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムにおけるサービス代行処理方法であって、
各サービス提供デバイスは、所定のサービス提供処理が予め定められた時間実行されなかった場合、いずれかのクライアントデバイスからの通信機能要求に応える特定の通信機能を指定して、該指定される特定の通信機能に基づく通信処理をネットワーク上のいずれかのサービス提供デバイスに代行させ（図１２に湿すステップ（１２−１７））、前記ネットワーク上のクライアントデバイスから認識されないネットワークスリープ状態に移行させる代行処理ステップ（図１２に示すステップ（１２−４），（１２−５））を備えることを特徴とするサービス代行処理方法。
【０１９３】
〔実施態様１５〕
前記代行処理ステップは、前記ネットワークスリープ状態に移行した後、電力消費を抑える動作モード移行処理を実行することを特徴とする実施態様１４記載のサービス代行処理方法。
【０１９４】
〔実施態様１６〕
前記代行処理ステップは、前記ネットワークスリープ状態に移行した後、代行依頼したサービス提供デバイスからスリープ解除要求を受けることに応じて、前記ネットワークスリープ状態をネットワークアライブ状態に移行することを特徴とする実施態様１４記載のサービス代行処理方法。
【０１９５】
〔実施態様１７〕
前記ネットワークスリープ状態をネットワークアライブ状態に移行する条件は、指定される前記特定の通信機能あるいは特定の通信機能の組合せに基づいて決定されることを特徴とする請求項１４記載のサービス代行処理方法。
【０１９６】
〔実施態様１８〕
前記サービス提供デバイスは、プロキシサーバであることを特徴とする請求項１４〜１７の何れかに記載のサービス代行処理方法。
【０１９７】
〔実施態様１９〕
ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、前記ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムにおけるサービス代行処理方法であって、予め定められた時間、所定のサービス提供処理が実行されなかった場合、サービス提供デバイスが提供する通信機能を制限し、該制限された通信機能を代行して処理する制限ステップ（図１２のステップ（１２−３），（１２−１２），（１２−１３），（１２−１５），（１２−１６），（１２−１７）を設けたことを特徴とするサービス代行処理方法。
【０１９８】
〔実施態様２０〕
前記制限ステップは、通信機能に制限を実施する以前に、制限された通信機能を代行して処理するサービス提供デバイスに対して代行処理を委託する（図１２のステップ（１２−３））ことを特徴とする実施態様１９記載のサービス代行処理方法。
【０１９９】
〔実施態様２１〕
前記制限ステップは、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託する通信機能を指定可能（図１０参照）とすることを特徴とする実施態様１９記載のサービス代行処理方法。
【０２００】
〔実施態様２２〕
前記制限ステップは、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託しない通信機能を指定可能（図１０）とすることを特徴とする実施態様１９記載のサービス代行処理方法。
【０２０１】
〔実施態様２３〕
前記制限ステップは、制限された通信機能を代行して処理するサービス提供デバイスに対して、代行処理を委託した通信機能に対し全ての機能、あるいは一部の通信機能の代行処理を委託可能とすることを特徴とする実施態様１９記載のサービス代行処理方法。
【０２０２】
〔実施態様２４〕
通信機能代行処理中のサービス提供デバイスが前記ネットワークを介して、通信機能を代行して処理するサービス提供デバイスが制限された通信機能に関連する通信データを受信した場合、代行処理中のサービス提供デバイスが通信機能が制限されている被制限サービス提供デバイスに対してその旨の通知処理を行うことを特徴とする実施態様１９記載のサービス代行処理方法。
【０２０３】
〔実施態様２５〕
前記制限ステップは、前記通信機能代行処理中のサービス提供デバイスより前記被制限サービス提供デバイスに前記その旨の通知があった場合、通信機能に対する制限を解除する機能（図１３に湿すステップ（１３−１８））を有することを特徴とする実施態様１９記載のサービス代行処理方法。
【０２０４】
〔実施態様２６〕
前記制限ステップは、あらかじめ通知された識別子と同一の識別子をもつ通信機能を代行して処理するサービス提供デバイスより前記その旨の通知があった場合に、前記通信機能に対する制限を解除する（図１３に湿すステップ（１３−６））ことを特徴とする実施態様２５記載のサービス代行処理方法。
【０２０５】
〔実施態様２７〕
実施態様１４〜２６のいずれかに記載のサービス代行処理方法を実現するプログラムを記憶したことを特徴とするコンピュータが読み取り可能な記憶媒体。
【０２０６】
〔実施態様２８〕
実施態様１４〜２６のいずれかに記載のサービス代行処理方法を実現することを特徴とするプログラム。
【０２０７】
【発明の効果】
以上説明したように、本発明によれば、ネットワークに接続された所定の機能処理を実行するサービス提供デバイスと、ネットワーク上で各サービス提供デバイスの接続状態を認識可能なネットワーク接続機能処理を行う複数のクライアントデバイスとが通信可能なネットワークサービスシステムにおいて、ネットワークに接続された所定の機能処理を実行する特定のサービス提供デバイスが機能処理要求を受け付けない状態が所定時間継続した場合に、特定のサービス提供デバイスの特定の通信機能処理を他のサービス提供デバイスに代行させて速やかに節電モード状態へ移行させるとともに、該節電モード状態時に、通信機能処理を代行するサービス提供デバイスが節電モード状態中のサービス提供デバイスに対する機能処理要求をクライアントから受け付けた場合に、通信機能処理を代行依頼されているサービス提供デバイスを識別して該通信機能が制限されるサービス提供デバイスをアライブ状態に復帰させることにより、ネットワーク上の様々なパケットトラフィックに左右されることなく、ネットワーク上の特定のサービス提供デバイスを速やかに節電モードへ移行させ、かつ、節電モードに移行した特定のサービス提供デバイスのみを速やかに通常の機能処理実行可能なアライブ状態に遷移させることができるネットワークサービスシステム環境を自在に構築することができるという効果を奏する。
【図面の簡単な説明】
【図１】本発明の第１実施形態を示すネットワークサービスシステムの構成を示すブロック図である。
【図２】本発明に係るネットワークサービスシステムにおける第１のデータ処理手順の一例を示すフローチャートである。
【図３】本発明に係るネットワークサービスシステムにおける第２のデータ処理手順の一例を示すフローチャートである。
【図４】図１に示したプリンタよりネットワーク上に発行されるＨＴＴＰパケットの一例を示す図である。
【図５】図１に示したプロキシからネットワークに発行されるＨＴＴＰレスポンスの一例を示す図である。
【図６】本発明に係るネットワークサービスシステムにおける第３のデータ処理手順の一例を示すフローチャートである。
【図７】図１に示した通信処理部よりネットワーク上に発行されるＨＴＴＰリクエストの一例を示す図である。
【図８】図１に示したプロキシがネットワークに発行するＨＴＴＰレスポンスの一例を示す図である。
【図９】本発明に係るネットワークサービスシステムにおける第４のデータ処理手順の一例を示すフローチャートである。
【図１０】図１に示した通信処理部よりネットワーク上に発行されるＨＴＴＰリクエストの一例を示す図である。
【図１１】図１に示した通信処理部よりネットワーク上に発行されるＨＴＴＰレスポンスの一例を示す図である。
【図１２】本発明に係るネットワークサービスシステムにおける第５のデータ処理手順の一例を示すフローチャートである。
【図１３】本発明に係るネットワークサービスシステムにおける第６のデータ処理手順の一例を示すフローチャートである。
【図１４】図１に示したプロキシよりネットワーク上に発行されるＨＴＴＰリクエストの一例を示す図である。
【図１５】図１に示したプリンタの通信制御部より返信されるＨＴＴＰレスポンスの一例を示す図である。
【図１６】本発明に係るネットワークサービスシステムにおける第７のデータ処理手順の一例を示すフローチャートである。
【図１７】本発明に係るプリントシステムで読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【符号の説明】
１５  記録装置制御部
１６  プロトコル代行処理部
２２  通信処理部
２３  プリンタコントローラ
１００  クライアント
３００  プロキシ
４００  プリンタ
【図１】
2004334792.tif 000003
【図２】
2004334792.tif 000004
【図３】
2004334792.tif 000005
【図４】
2004334792.tif 000006
【図５】
2004334792.tif 000007
【図６】
2004334792.tif 000008
【図７】
2004334792.tif 000009
【図８】
2004334792.tif 000010
【図９】
2004334792.tif 000011
【図１０】
2004334792.tif 000012
【図１１】
2004334792.tif 000013
【図１２】
2004334792.tif 000014
【図１３】
2004334792.tif 000015
【図１４】
2004334792.tif 000016
【図１５】
2004334792.tif 000017
【図１６】
2004334792.tif 000018
【図１７】
2004334792.tif 000019