JP2013246447A - ネットワークデバイス、プログラム、システムおよび方法 - Google Patents

Abstract

【課題】ネットワークデバイスが、管理装置とのＰｕｓｈ通信のＨａｎｄｓｈａｋｅに失敗したとしても、管理装置がＰｕｓｈ通信を用いて行った指示を受けることができる仕組みを提供する。
【解決手段】第一のクライアントコンピュータ１１０が、第二のクライアントコンピュータ１７０を経由したサーバコンピュータ１００とのＰｕｓｈ通信である間接的なＰｕｓｈ通信の要求を第二のクライアントコンピュータ１７０に対して行う。第二のクライアントコンピュータ１７０が、間接的なＰｕｓｈ通信の後に、サーバコンピュータ１００から第一のクライアントコンピュータ１１０に対してＰｕｓｈ通信を用いて行われた指示を、第一のクライアントコンピュータ１１０に転送する。
【選択図】図１

Description

本発明は、ネットワーク上のサーバとネットワークデバイスとの間の通信を制御する技術に関する。

インターネット環境におけるクライアント・サーバシステムにおいて、各種印刷サービスの発信元となるサーバ側から、各種印刷サービスの実行元となるクライアント側の画像形成装置へデータ送信することは、ファイアウォールにより不可能である。そこで、クライアント側の画像形成装置から各種印刷サービスの発信元となるサーバ側に対し、コマンドの有無を問い合わせるポーリング形式の通信方式が提案されている。特許文献１は、管理装置が、被管理デバイスからのファイアウォール越えの指示の有無の問いあわせを受け、問いあわせに対して、当該指示を、問いあわせを受けた際に張られたセッションにおいて返信するデバイス管理システムを提案している。

特開２００７−３３４６１２号公報

クライアントからの初期通信（Ｈａｎｄｓｈａｋｅ）を起点として、インターネット上のサーバ（管理装置）からファイアウォール内のイントラネットワーク上のネットワークデバイスに対してＰｕｓｈ通信を行う通信方式（Ｐｕｓｈ通信方式）が考えられる。Ｐｕｓｈ通信方式は、ファイアウォール内からの指示要求（ＨＴＴＰリクエストなど）なしに管理装置からの指示が可能となる通信方式である。Ｐｕｓｈ通信方式には、例えば、ＷｅｂＳｏｃｋｅｔと呼ばれるプロトコル（RFC 6455）が含まれる。

管理装置は、Ｐｕｓｈ通信方式で通信することによって、リアルタイムのコマンド配信が可能となるので、ネットワークデバイス側から管理装置側へのポーリング形式によるコマンド有無の問い合わせは必要なくなる。つまり、Ｐｕｓｈ通信によれば、従来発生していた、ポーリングの間隔がもたらすタイムロスをなくすことができる。

しかし、Ｐｕｓｈ通信は、ネットワークデバイスと管理装置間の通信コネクションを持続的に維持するという特徴がある。したがって、コスト等の観点からネットワークデバイスと管理装置間の通信コネクション数の上限が定められているシステムにおいては、容易にコネクション数が上限値に到達してしまう。その結果、ネットワークデバイスと管理装置間で、Ｐｕｓｈ通信が確立できない（Ｈａｎｄｓｈａｋｅが開始できない）ケースが発生する。

本発明は、ネットワークデバイスが、管理装置とのＰｕｓｈ通信のＨａｎｄｓｈａｋｅに失敗したとしても、管理装置がＰｕｓｈ通信を用いて行った指示を受けることができる仕組みの提供を目的とする。

本発明の一実施形態のネットワークデバイスは、ファイアウォールを介して、外部の管理装置と通信するネットワークデバイスである。前記ネットワークデバイスは、前記管理装置との通信方式として前記ファイアウォール内からの指示要求なしに前記管理装置からの指示が可能となる所定の通信方式を利用するための要求を、他のネットワークデバイスから受信する受信手段と、前記所定の通信方式を利用するための要求の後に、前記管理装置から前記他のネットワークデバイスに対して前記所定の通信方式を用いて行われた指示を、前記他のネットワークデバイスに転送する転送手段と、を備える。

本発明によれば、ネットワークデバイスが、管理装置とのＰｕｓｈ通信のＨａｎｄｓｈａｋｅに失敗したとしても、他のネットワークデバイスを介して、管理装置がＰｕｓｈ通信を用いて行った指示を受けることができる。したがって、例えば、ネットワークデバイスと管理装置との間の通信コネクション数が上限に達していたとしても、ネットワークデバイスは、管理装置からリアルタイムに行われる指示を受けることができる。

本実施形態の情報処理システムの構成例を示す図である。 情報処理システムのソフトウェア構成例を説明する図である。 第一のクライアントコンピュータの動作処理の例を説明する図である。 サーバコンピュータの動作処理の例を説明する図である。 第二のクライアントコンピュータの動作処理の例を説明する図である。 第二のクライアントコンピュータにおけるスケジュールの例である。 第一のクライアントコンピュータの動作処理の例を説明する図である。

（実施例１）
図１は、本実施形態の情報処理システムの構成例を示す図である。
本実施形態の情報処理システムは、Ｐｕｓｈ通信型クライアント・サーバシステムである。Ｐｕｓｈ通信は、ファイアウォール内からの指示要求なしにサーバコンピュータ１００からの指示が可能となる所定の通信方式である。本実施形態では、Ｐｕｓｈ通信のプロトコルとして、ＷｅｂＳｏｃｋｅｔプロトコルを用いる。ＷｅｂＳｏｃｋｅｔプロトコルによる通信を、以下ではＷｅｂＳｏｃｋｅｔ通信とも記述する。

図１に示す情報処理システムは、第一のクライアントコンピュータ１１０、第一のプリンタ１３０、第二のクライアントコンピュータ１７０、第二のプリンタ１８０、サーバコンピュータ１００を備える。第一、第二のクライアントコンピュータは、サーバコンピュータ１００からのネットワークを介した監視の対象となるネットワークデバイスである。第一、第二のクライアントコンピュータは、ファイアウォール１６０を介して、ファイアウォール１６０の外部に配置される管理装置であるサーバコンピュータ１００と通信する。第一、第二のクライアントコンピュータは、例えば、画像形成装置、携帯情報端末、クライアントＰＣ等のネットワークデバイスである。

サーバコンピュータ１００は、第一、第二のクライアントコンピュータと、ファイアウォール１６０越しにＷＡＮ（Wide Area Network）３０１を介して接続されている。第一のクライアントコンピュータ１１０と第二のクライアントコンピュータ１７０とは、ＬＡＮ（Local Area Network）３００を介して接続されている。第一のプリンタ１３０は、第一のクライアントコンピュータ１１０と接続されている。また、第二のプリンタ１８０は、第二のクライアントコンピュータ１７０と接続されている。

サーバコンピュータ１００、第一のクライアントコンピュータ１１０、および第二のクライアントコンピュータ１７０は、汎用コンピュータの構成を有する。以下の説明では、サーバコンピュータ１００、第一のクライアントコンピュータ１１０、第二のクライアントコンピュータ１７０のハードウェア構成で、重複するものについては、どちらか一方のみを説明し、もう一方については説明を省略する。

サーバコンピュータ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ネットワークＩ／Ｆ１０４、外部メモリＩ／Ｆ１０５、外部メモリ１０６を備える。ＣＰＵは、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略称である。ＲＡＭは、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略称である。ＲＯＭは、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略称である。

ＣＰＵ１０１は、ＲＯＭ１０３または外部メモリ１０６に記憶されたアプリケーションプログラム等に基づいて処理を実行する。また、ＣＰＵ１０１は、システムバス１０７に接続される各デバイスを総括的に制御する。ＲＡＭ１０２は、ＣＰＵ１０１の主メモリ、ワークエリア等である。

ＲＯＭ１０３は、基本Ｉ／Ｏプログラム等の記憶領域として機能する読み出し専用のメモリである。ＲＯＭ１０３または外部メモリ１０６には、ＣＰＵ１０１の制御プログラムであるオペレーティングシステムプログラム（以下ＯＳ）等が記憶される。また、ＲＯＭ１０３または外部メモリ１０６には、上記アプリケーションプログラム等に基づく処理の際に使用するファイルやその他各種データが記憶される。

ネットワークＩ／Ｆ１０４は、ネットワークに接続しネットワーク通信を行う。外部メモリＩ／Ｆ１０５は、ハードディスク（ＨＤ）等の外部メモリ１０６とのアクセスを制御する。外部メモリ１０６は、ブートプログラム、各種のアプリケーション、ユーザファイル、編集ファイル等を記憶する。

サーバコンピュータ１００は、ＣＰＵ１０１が、ＲＯＭ１０３や外部メモリ１０６に書き込まれた基本Ｉ／ＯプログラムおよびＯＳを実行している状態で動作する。基本Ｉ／Ｏプログラムは、ＲＯＭ１０３に書き込まれている。また、ＯＳは、ＲＯＭ１０３または外部メモリ１０６に書き込まれている。コンピュータの電源がＯＮされたときに、基本Ｉ／Ｏプログラム中のイニシャルプログラムロード機能により、ＲＯＭ１０３または外部メモリ１０６からＯＳがＲＡＭ１０２に書き込まれ、ＯＳの動作が開始される。１０７はシステムバスであり、各デバイスを接続する。

第一のクライアントコンピュータ１１０は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、ネットワークＩ／Ｆ１１４、キーボードＩ／Ｆ１１５、キーボード１１６を備える。また、第一のクライアントコンピュータ１１０は、ディスプレイＩ／Ｆ１１７、ディスプレイ１１８、外部メモリＩ／Ｆ１１９、外部メモリ１２０を備える。

キーボードＩ／Ｆ１１５は、キーボード１１６や不図示のポインティングデバイスからの入力を制御する。ディスプレイＩ／Ｆ１１７は、ディスプレイ１１８の表示を制御する。ＣＰＵ１１１は、ディスプレイ１１８上の不図示のマウスカーソル等で指示されたコマンドに基づいて、登録された種々のウインドウを開き、種々のデータ処理を実行する。

第一のプリンタ１３０は、ネットワークＩ／Ｆ１３１、ＣＰＵ１３２、ＲＡＭ１３３、ＲＯＭ１３４、操作部Ｉ／Ｆ１３５、操作部１３６、プリンタＩ／Ｆ１３７、プリンタ１３８を備える。また、第一のプリンタ１３０は、外部メモリＩ／Ｆ１３９、外部メモリ１４０を備える。

ネットワークＩ／Ｆ１３１は、第一のクライアントコンピュータ１１０との接続バスとして使用される。ＣＰＵ１３２は、制御プログラム等に基づいて、システムバス１４１に接続されるプリンタＩ／Ｆ１３７を介してプリンタ１３８に出力情報としての画像信号を出力する。なお、制御プログラムは、ＲＯＭ１３４や外部メモリ１４０等に記憶されている。ＣＰＵ１３２は、ネットワークＩ／Ｆ１３１を介して、コンピュータとの通信処理が可能である。これにより、ＣＰＵ１３２は、第一のプリンタ１３０内の情報等を第一のクライアントコンピュータ１１０に通知する。また、ＣＰＵ１３２は、ＲＯＭ１３４または外部メモリ１４０に記憶されたアプリケーションプログラム等に基づいて処理を実行する。

ＲＡＭ１３３は、ＣＰＵ１３２の主メモリ、ワークエリア等として機能し、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができる。なお、ＲＡＭ１３３は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ（Non Volatile Random Access Memory）等に用いられる。また、外部メモリ１４０は、例えばハードディスク（ＨＤ）等である。ＲＯＭ１３４または外部メモリ１４０には、ＣＰＵ１３２の制御プログラムや上記出力情報を生成する際に使用するフォントデータ、第一のプリンタ１３０上で利用される情報等が記憶されている。操作部Ｉ／Ｆ１３５は、操作部１３６との間のインタフェースをつかさどり、表示すべき画像データを操作部１３６に対して出力する。

また、操作部Ｉ／Ｆ１３５は、ユーザが操作部１３６を介して入力した情報の受信も行う。操作部１３６は、操作のためのスイッチおよびＬＥＤ表示器等が配されている操作パネル等に相当する。プリンタＩ／Ｆ１３７は、プリンタ１３８（プリンタエンジン）に出力情報としての画像信号を出力する。外部メモリＩ／Ｆ１３９は、ハードディスク（ＨＤ）、ＵＳＢストレージ、ＩＣカード等の外部メモリ１４０のアクセスを制御する。外部メモリは１個に限らず、少なくとも１個以上あればよい。また、第一のプリンタ１３０は、内蔵フォントに加えて、オプションフォントカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていてもよい。さらに、第一のプリンタ１３０は、図示しないＮＶＲＡＭを有し、操作部１３６からのプリンタモード設定情報を記憶するようにしてもよい。１４１はシステムバスであり、各デバイスを接続する。

第二のクライアントコンピュータ１７０の構成は、第一のクライアントコンピュータ１１０の構成と同様であるので、説明を省略する。また、第二のプリンタ１８０の構成は、第一のプリンタ１３０の構成と同様であるので、説明を省略する。

図２は、本実施形態の情報処理システムのソフトウェア構成例を説明する図である。図２（Ａ）は、サーバコンピュータ１００のソフトウェア構成を示す。サーバコンピュータ１００において、アプリケーション２０５および各モジュールは、外部メモリ１０６に保存されたファイルとして存在するプログラムモジュールである。アプリケーション２０５および各モジュールは、ＲＡＭ１０２にロードされ、実行される。

外部メモリ１０６が有する不図示のＣＤ−ＲＯＭ、またはネットワークを経由して、アプリケーション２０５を外部メモリ１０６のＨＤに追加することが可能である。２００はネットワークモジュールであり、クライアントコンピュータとのネットワーク通信を行う。

ネットワークモジュール２００は、ＴＣＰ／ＩＰモジュール２０１、ＨＴＴＰモジュール２０２、ＷｅｂＳｏｃｋｅｔモジュール２０３を有する。ＴＣＰ／ＩＰモジュール２０１は、ＴＣＰ／ＩＰプロトコルでのネットワーク通信を行う。ＨＴＴＰモジュール２０２はトランスポート・プロトコルとしてＴＣＰを使用し、ＨＴＴＰプロトコルでのネットワーク通信を行う。

ＷｅｂＳｏｃｋｅｔモジュール２０３は、トランスポート・プロトコルとしてＴＣＰを使用し、ＷｅｂＳｏｃｋｅｔプロトコルでのネットワーク通信を行う。Ｗｅｂサーバサービスモジュール２０４は、クライアントコンピュータ１１０からＨＴＴＰリクエストを受け取り、ＨＴＴＰレスポンスを応答するサービスを提供する。

アプリケーション２０５は、クライアントコンピュータ１１０から送信される各種データファイルを、クライアントコンピュータ１１０に接続されたプリンタ１３０が印刷可能なデータ形式に変換する。各種データファイルは、例えば、ＭｉｃｒｏｓｏｆｔＯｆｆｉｃｅＷＯＲＤ／Ｅｘｃｅｌ／ＰｏｗｅｒＰｏｉｎｔから生成されるデータファイルである。アプリケーション２０５は、プリンタ１３０が印刷可能なデータ形式に変換されたデータファイルをクライアントコンピュータ１１０に送信する。

アプリケーション２０５は、例えば、ＨＴＴＰリクエストに応答して処理を実行するプログラムとして実装される。アプリケーション２０５は、Ｗｅｂサーバサービスモジュール２０４とともに、以下の処理を実現するＷｅｂアプリケーションを実現している。このＷｅｂアプリケーションは、クライアントコンピュータ１１０から各種データファイルを受け取り、クライアントコンピュータ１１０に接続されたプリンタ１３０が印刷可能なデータ形式に変換する。

アプリケーション２０５は、レンダリングモジュール２０６と通信管理モジュール２０７とを有する。レンダリングモジュール２０６はは、各種データファイルのインタープリットを行う。各種データファイルは、外部メモリ１４０を介してユーザから入稿される。各種データファイルが、プリンタ１３０が印刷可能な形式にレンダリングすることが不可能である場合、クライアントコンピュータ１１０からサーバコンピュータ１００に対してデータファイルが送信される。このデータファイルを受け取ったレンダリングモジュール２０６が、クライアントコンピュータ１１０に接続されたプリンタ１３０が印刷可能なデータファイルに変換する。通信管理モジュール２０７は、ＷｅｂＳｏｃｋｅｔプロトコルによってセッションを維持しているクライアントコンピュータとの接続管理を行う。

図２（Ｂ）は、第一のクライアントコンピュータ１１０と、第一のプリンタ１３０のソフトウェア構成を示す。クライアントコンピュータ１１０を構成する各モジュールは、ＲＯＭ１１３または外部メモリ１２０に保存されたファイルとして存在するプログラムモジュールである。そして、各モジュールは、実行時にＯＳやそのモジュールを利用するモジュールによってＲＡＭ１１２にロードされ実行される。

ネットワークモジュール２１０は、サーバコンピュータ１００やネットワークプリンタ１３０とのネットワーク通信を行う。ネットワークモジュール２１０は、ＴＣＰ／ＩＰモジュール２１１、ＨＴＴＰモジュール２１２、ＷｅｂＳｏｃｋｅｔモジュール２１３を有する。ＴＣＰ／ＩＰモジュール２１１は、ＴＣＰ／ＩＰプロトコルでのネットワーク通信を行う。ＨＴＴＰモジュール２１２は、トランスポート・プロトコルとしてＴＣＰを使用し、ＨＴＴＰプロトコルでのネットワーク通信を行う。ＷｅｂＳｏｃｋｅｔモジュール２１３は、トランスポート・プロトコルとしてＴＣＰを使用し、ＷｅｂＳｏｃｋｅｔプロトコルでのネットワーク通信を行う。アプリケーション２１４に含まれる通信管理モジュール２１５は、サーバコンピュータ１００との通信、および第一プリンタ１３０との通信を管理する。

次に、第一のプリンタ１３０のソフトウェア構成について説明する。第一のプリンタ１３０において、各種モジュールは、ＲＯＭ１３４または外部メモリ１４０に保存されたファイルとして存在し、実行時にＲＡＭ１３３にロードされ実行される。ネットワークモジュール２２０であり、任意の通信プロトコルを使用して第一のクライアントコンピュータ１１０とのネットワーク通信を行う。印刷処理モジュール２２２は、第一のクライアントコンピュータ１１０から送信された印刷ジョブの受信および制御、印刷処理を行う。データ受付モジュール２２１は、外部メモリ１４０を通して、ユーザから入力されたデータファイルを受け付け、本印刷システムに係る印刷処理を開始する。

図２（Ｃ）は、第二のクライアントコンピュータ１７０と、第二のプリンタ１８０のソフトウェア構成を示す。第二のクライアントコンピュータ１７０のソフトウェア構成は、上述した第一のクライアントコンピュータ１１０のソフトウェア構成と同様である。また、第二のプリンタ１８０のソフトウェア構成は、上述した第一のプリンタ１７０のソフトウェア構成と同様である。本実施形態のプログラムは、図２（Ａ）乃至（Ｃ）の各々に示すアプリケーションまたはモジュールとして実現される。

以下に、実施例１の情報処理システムにおける、サーバコンピュータ１００、第一のクライアントコンピュータ１１０、第二のクライアントコンピュータ１７０の動作について説明する。

図３は、第一のクライアントコンピュータの動作処理の例を説明するフローチャートである。
図３に示す各ステップの処理は、アプリケーション２１４の通信管理モジュール２１５の制御にしたがって実行される。まず、第一のクライアントコンピュータ上で、Ｈａｎｄｓｈａｋｅ開始イベントの発生を検知する（ステップＳ３０１）。Ｈａｎｄｓｈａｋｅは、例えば、予め設定されたタイミング、第一のクライアントコンピュータ１１０または第一のプリンタ１３０の電源ＯＮ時、および外部からの管理コマンドの少なくともいずれかに従って試行される。Ｈａｎｄｓｈａｋｅ開始のトリガーを、ユーザから外部メモリＩ／Ｆ１３０にＵＳＢストレージやＩＣカードといった外部メモリ１４０の入力が発生したタイミングとしてもよい。また、このトリガーは、第一のプリンタ１３０が備える不図示の近接センサーが、ユーザが第一のプリンタ１３０に近づいたことを検知したタイミングとしてもよい。

次に、ステップＳ３０２では、ＨＴＴＰモジュール２１２が、インターネット接続の確認と、サーバコンピュータ１００との通信可否を判断する（ステップＳ３０２）。具体的には、ＨＴＴＰモジュール２１２は、ＴＣＰ／ＩＰモジュール２１１を介してＨＴＴＰリクエストをサーバコンピュータ１００に送信し、ＨＴＴＰレスポンスが得られるか否かを判断する。

サーバコンピュータ１００からＨＴＴＰレスポンスを得られる場合、ＨＴＴＰモジュール２１２は、自装置がインターネット接続されており、サーバコンピュータ１００と通信可能であると判断する。サーバコンピュータ１００からＨＴＴＰレスポンスを得られない場合、ＨＴＴＰモジュール２１２は、自装置がインターネット接続されておらず、サーバコンピュータ１００と通信可能でないと判断する。なお、ステップＳ３０２の判断処理では、ＨＴＴＰリクエストに対するＨＴＴＰレスポンスが得られるか否かを判断基準としたが、当該判断処理に他の任意の通信方法を用いてもよい。

自装置がインターネット接続されており、サーバコンピュータ１００と通信可能である場合は、ステップＳ３０３に進む。自装置がインターネット接続されておらず、サーバコンピュータ１００と通信可能でない場合は、ステップＳ３０５に進む。

ステップＳ３０３において、ＷｅｂＳｏｃｋｅｔモジュール２１３が、ＴＣＰ／ＩＰモジュール２１１を介して、サーバコンピュータ１００にＷｅｂＳｏｃｋｅｔのＨａｎｄｓｈａｋｅ要求を行い、サーバコンピュータ１００からの応答を待つ。続いて、ＷｅｂＳｏｃｋｅｔモジュール２１３が、サーバコンピュータ１００とのＨａｎｄＳｈａｋｅに成功したかを判断する（ステップＳ３０４）。

サーバコンピュータ１００からＨａｎｄｓｈａｋｅ応答が返された場合、ＷｅｂＳｏｃｋｅｔモジュール２１３が、サーバコンピュータ１００とのＨａｎｄＳｈａｋｅに成功したと判断する。一方、ＨａｎｄＳｈａｋｅの失敗時には、ＷｅｂＳｏｃｋｅｔ通信の要求先のコンピュータからＨＴＴＰ Ｅｒｒｏｒ Ｃｏｄｅが返信される。したがって、サーバコンピュータ１００からＨＴＴＰ Ｅｒｒｏｒ Ｃｏｄｅが返信された場合、ＷｅｂＳｏｃｋｅｔモジュール２１３が、サーバコンピュータ１００とのＨａｎｄＳｈａｋｅに失敗したと判断する。サーバコンピュータ１００とのＨａｎｄＳｈａｋｅに成功した場合は、処理を終了する。サーバコンピュータ１００とのＨａｎｄＳｈａｋｅに失敗した場合は、ステップＳ３０５に進む。

ステップＳ３０５において、通信管理モジュール２１５が、自装置が属するセグメントと同じセグメントのネットワークに属し、かつサーバコンピュータ１００とＷｅｂＳｏｃｋｅｔ通信中の第二のクライアントコンピュータ１７０を探索する。そして、通信管理モジュール２１５が、探索された第二のクライアントコンピュータ１７０に対して、以下の要求を行う。通信管理モジュール２１５は、第二のクライアントコンピュータ１７０経由でのサーバコンピュータ１００とのＰｕｓｈ通信を要求（間接的なＰｕｓｈ通信を要求）する。間接的なＰｕｓｈ通信は、第二のクライアントコンピュータ１７０経由でのサーバコンピュータ１００とのＰｕｓｈ通信である。つまり、間接的なＰｕｓｈ通信の要求は、サーバコンピュータ１００との通信方式としてＰｕｓｈ通信を利用するための要求である。

間接的なＰｕｓｈ通信を要求するために、通信管理モジュール２１５は、要求先の第二のクライアントコンピュータ１７０を以下のようにして探索する。第一のクライアントコンピュータ１１０がサーバコンピュータ１００と通信可能であり（Ｓ３０２でＹｅｓ）、Ｈａｎｄｓｈａｋｅに失敗した場合、サーバコンピュータ１００が、例えば、以下の処理を実行する。サーバコンピュータ１００は、サーバコンピュータ１００とＷｅｂＳｏｃｋｅｔ通信中であって、第一のクライアントコンピュータが属するセグメントと同じセグメントに属する第二のクライアントコンピュータを第一のクライアントコンピュータに通知する。具体的には、サーバコンピュータ１００は、当該第二のクライアントコンピュータのアドレス情報を通知する。このアドレス情報は、例えば、ＩＰｖ４ネットワークにおけるＩＰアドレスである。

通信管理モジュール２１５は、通知されたアドレス情報に対応する第二のクライアントコンピュータを間接的なＰｕｓｈ通信の要求先とする。サーバコンピュータ１００からのＷｅｂＳｏｃｋｅｔ通信中のクライアントコンピュータのアドレス情報の通知については、図４を参照して後述する。

第一のクライアントコンピュータ１１０が、第二のクライアントコンピュータ１７０を通じてサーバコンピュータ１００と間接的にＰｕｓｈ通信するためには、以下の処理が実行されていることが前提となる。すなわち、サーバコンピュータ１００と間接的にＰｕｓｈ通信するためには、第二のクライアントコンピュータ１７０が、サーバコンピュータ１００とＨａｎｄＳｈａｋｅ開始済みであり、ＷｅｂＳｏｃｋｅｔ通信が確立していなければならない。

また、自装置がインターネット接続されておらず、サーバコンピュータ１００と通信可能でない場合（Ｓ３０２でＮｏ）には、ステップＳ３０５において、以下の処理が実行される。通信管理モジュール２１５が、ブロードキャストによって、サーバコンピュータ１００とＷｅｂＳｏｃｋｅｔ通信中であって、かつ、自装置が属するセグメントと同じセグメントのネットワークに属する第二のクライアントコンピュータ１７０を探索する。そして、通信管理モジュール２１５が、探索された第二のクライアントコンピュータ１７０に対して、間接的なＰｕｓｈ通信を要求する。そして、第二のクライアントコンピュータ１７０の通信管理モジュール２３５が、間接的なＰｕｓｈ通信の要求を受信する。

自装置が属するセグメントと同じセグメントのネットワークに属する第二のクライアントコンピュータ１７０が探索されたとしても、探索された第二のクライアントコンピュータ１７０が、サーバコンピュータ１００とＷｅｂＳｏｃｋｅｔ通信中でない場合がある。この場合には、通信管理モジュール２１５は、探索された第二のクライアントコンピュータ１７０に対して、間接的なＰｕｓｈ通信を要求する。

間接的なＰｕｓｈ通信の要求を受けた第二のクライアントコンピュータ１７０の通信管理モジュール２３５が、この要求に応じて、新たに、第二のクライアントコンピュータ１７０とサーバコンピュータ１００との間のＷｅｂＳｏｃｋｅｔによる接続確立を行う。そして、通信管理モジュール２３５が、第一のクライアントコンピュータ１１０とサーバコンピュータ１００との間の間接的なＰｕｓｈ通信を実現する。つまり、通信管理モジュール２３５が、間接的なＰｕｓｈ通信の要求の後、サーバコンピュータ１００から第一のクライアントコンピュータ１１０に対してＷｅｂＳｏｃｋｅｔを用いて行われた指示を、第一のクライアントコンピュータ１１０に転送する。具体的には、通信管理モジュール２３５が、上記ＷｅｂＳｏｃｋｅｔによる接続の確立後に、上記指示を第一のクライアントコンピュータ１１０に転送する。すなわち、本実施形態において、第二のクライアントコンピュータ１７０は、Ｐｕｓｈ通信を仲介するブローカーサーバである。

次に、通信管理モジュール２１５が、サーバコンピュータ１００との間接的なＰｕｓｈ通信に成功したかを判断する（ステップＳ３０６）。サーバコンピュータ１００との間接的なＰｕｓｈ通信に成功した場合、通信管理モジュール２１５が、当該間接的なＰｕｓｈ通信を開始する（ステップＳ３０７）。ステップＳ３０７の処理によって、第一のクライアントコンピュータ１１０は、第二のクライアントコンピュータ１７０を通じてサーバコンピュータ１００とＰｕｓｈ通信することが可能となる。例えば、通信管理モジュール２１５が、第二のクライアントコンピュータ１７０から転送されてきた、サーバコンピュータ１００からＷｅｂＳｏｃｋｅｔ通信により行われた指示を受信する。そして、ＣＰＵ１１１（図１）が、上記受信された指示を実行する。

サーバコンピュータ１００からの指示がプリント指示である場合の動作例について以下に説明する。第一のクライアントコンピュータ１１０は、ユーザから外部メモリＩ／Ｆ１３９および外部メモリ１４０を介して入力されたデータファイルを、第一のクライアントコンピュータ１１０に接続された第一のプリンタ１３０が印刷可能なデータ形式に変換する。第一のクライアントコンピュータ１１０は、サーバコンピュータ１００に上記データファイルを送信し、サーバコンピュータ１００は、レンダリングモジュール２０６で第一のプリンタ１３０が印刷可能なデータ形式への変換を開始する。第一のコンピュータ１１０と、サーバコンピュータ１００とはＰｕｓｈ通信が確立されている。したがって、サーバコンピュータ１００において、レンダリングモジュール２０６の処理が完了すると、即時に第一のクライアントコンピュータ１００に対して、第一のプリンタ１３０が印刷可能なデータ形式に変換されたファイルが送信される。

サーバコンピュータ１００との間接的なＰｕｓｈ通信に失敗した場合、通信管理モジュール２１５が、サーバコンピュータ１００と、Ｐｕｓｈ通信以外の通信方式での通信を開始する（ステップＳ３０８）。例えば、ステップＳ３０２の判断処理において、ＨＴＴＰによるサーバコンピュータ１００との通信が可能であると判断された場合、通信管理モジュール２１５が、ＨＴＴＰによるポーリング方式で通信を行う。ただし、ＨＴＴＰによるポーリング方式の通信であるので、サーバコンピュータ１００においてレンダリングモジュール２０６の処理が完了しても、第一のクライアントコンピュータ１１０からのポーリング問い合わせが来ない限り、一連の印刷処理が中断してしまう。したがって、ステップＳ３０７で開始される間接的なＰｕｓｈ通信では発生しないタイムロスが生じてしまうことになる。なお、上記ステップＳ３０２の判断処理が失敗した場合、通信管理モジュール２１５が、第一のプリンタ１３０の操作部１３６にエラー状態を表示するようにしてもよい。

図４は、サーバコンピュータの動作処理の例を説明するフローチャートである。
サーバコンピュータ１００が備えるＷｅｂＳｏｃｋｅｔモジュール２０３が、図３のステップＳ３０３において第一のクライアントコンピュータ１１０から送信されたＨａｎｄｓｈａｋｅ要求をＴＣＰ／ＩＰモジュール２０１を介して受信する（ステップＳ４０１）。

次に、通信管理モジュール２０７が、Ｈａｎｄｓｈａｋｅを開始できるかを判断する（ステップＳ４０２）。通信管理モジュール２０７は、例えば、Ｗｅｂｓｏｃｋｅｔプロトコルによる通信コネクションの数が上限値に達しているかを判断し、当該通信コネクションの数が上限値に達している場合に、Ｈａｎｄｓｈａｋｅを開始できないと判断する。例えば、Ｗｅｂｓｏｃｋｅｔプロトコルによる通信コネクションの数が上限値に達していない場合、通信管理モジュール２０７は、Ｈａｎｄｓｈａｋｅを開始できると判断する。なお、本実施形態のシステムの管理者等が、許容できる通信コスト等に基づいて、通信管理モジュール２０７に予めＷｅｂｓｏｃｋｅｔプロトコルによる通信コネクションの上限値を設定する。

通信管理モジュール２０７がＨａｎｄｓｈａｋｅを開始できると判断した場合は、ステップＳ４０３に進む。通信管理モジュール２０７がＨａｎｄｓｈａｋｅを開始できないと判断した場合は、ステップＳ４０４に進む。

ステップＳ４０３において、通信管理モジュール２０７が、第一のクライアントコンピュータ１１０とＨａｎｄｓｈａｋｅを開始する。このタイミングで、第一のクライアントコンピュータ１１０と、サーバコンピュータ１００とのＷｅｂｓｏｃｋｅｔ通信が確立する。

ステップＳ４０４においては、通信管理モジュール２０７が、以下の処理を実行する。通信管理モジュール２０７は、Ｈａｎｄｓｈａｋｅの要求元の第一のクライアントコンピュータ１１０が属するセグメントと同じセグメント内に、サーバコンピュータとＷｅｂＳｏｃｋｅｔ通信を確立中の第二のクライアントコンピュータが存在するかを判断する。

ステップＳ４０４においては、通信管理モジュール２０７は、第一のクライアントコンピュータ１１０が属するセグメントと同じセグメント内の第二のクライアントコンピュータ１７０を以下のようにして特定する。例えば、サーバコンピュータ１００がＩＰｖ４にしたがったネットワーク通信を行っている場合を想定する。通信管理モジュール２０７は、第一のクライアントコンピュータ１１０と第３セグメントまで同一のＩＰアドレスを有する第二のクライアントコンピュータが存在するかを判断する。通信管理モジュール２０７は、第一のクライアントコンピュータ１１０と第３セグメントまで同一のＩＰアドレスを有する第二のクライアントコンピュータを特定する。そして、通信管理モジュール２０７は、第一のクライアントコンピュータ１１０が属するセグメントと同じセグメント内の第二のクライアントコンピュータとする。

通信管理モジュール２０７が、当該第二のクライアントコンピュータ１７０が存在すると判断した場合は、ステップＳ４０６に進む。通信管理モジュール２０７が、当該第二のクライアントコンピュータ１７０が存在しないと判断した場合は、ステップＳ４０５に進む。

ステップＳ４０６において、通信管理モジュール２０７が、ＷｅｂＳｏｃｋｅｔ通信を確立している第二のクライアントコンピュータ１７０のアドレス情報を第一のクライアントコンピュータ１１０に通知する。通信管理モジュール２０７は、上記アドレス情報として例えばＩＰアドレスを用いる。

ステップＳ４０５において、通信管理モジュール２０７が、ＷｅｂＳｏｃｋｅｔ通信を確立している第二のクライアントコンピュータ１７０が存在しないことを第一のクライアントコンピュータ１１０に通知する。

図５は、第二のクライアントコンピュータの動作処理の例を説明するフローチャートである。
この例では、第一のクライアントコンピュータ１１０から間接的なＰｕｓｈ通信の要求を受けた第二のクライアントコンピュータ１７０の動作処理について説明する。まず、第二のクライアントコンピュータ１７０が備える通信管理モジュール２３５が、以下の処理を実行する第一の判断手段として機能する。通信管理モジュール２３５が、自装置がサーバコンピュータ１００とＨａｎｄｓｈａｋｅ済みであり、Ｗｅｂｓｏｃｋｅｔ通信を継続中であるかを判断する（ステップＳ５０１）。自装置がサーバコンピュータ１００とＨａｎｄｓｈａｋｅ済みであり、Ｗｅｂｓｏｃｋｅｔ通信を継続中である場合は、ステップＳ５０３に進む。自装置がサーバコンピュータ１００とＷｅｂｓｏｃｋｅｔ通信を継続中でない場合は、ステップＳ５０２に進む。

ステップＳ５０３において、通信管理モジュール２３５が、以下の処理を実行する第二の判断手段として機能する。通信管理モジュール２３５が、第二のクライアントコンピュータ１７０におけるスケジュールを確認する（ステップＳ５０３）。具体的には、通信管理モジュール２３５が、通信が遮断されてしまうスケジュールを確認する。

図６は、第二のクライアントコンピュータにおけるスケジュールの例である。この例では、スケジュール６０１として、第二のクライアントコンピュータにおいて予定されている処理等（インストール、リブート、シャットダウン）と、当該処理等が実行される日時とが設定されている。スケジュール６０１は、予め記憶手段に記憶されている。

図５に戻って、ステップＳ５０４において、通信管理モジュール２３５が、ステップＳ５０３で確認したスケジュールに基づいて、間接的なＰｕｓｈ通信を許可するかを判断する（ステップＳ５０４）。具体的には、通信管理モジュール２３５が、ステップＳ５０３における確認処理の開始時刻から、サーバコンピュータ１００と通信不可となる時刻までの時間間隔が閾値以上であるかを判断する。この閾値は、例えば、予め管理者によって設定される。上記時間間隔が閾値以上である場合、通信管理モジュール２３５が、間接的なＰｕｓｈ通信を許可すると判断し、ステップＳ５０５に進む。上記時間間隔が閾値以上でない場合、通信管理モジュール２３５が、間接的なＰｕｓｈ通信を許可しないと判断し、ステップＳ５０５に進む。

ステップＳ５０２において、通信管理モジュール２３５が、第一のクライアントコンピュータ１３０に対して、第二のクライアントコンピュータ１７０を介してサーバコンピュータ１００とのＰｕｓｈ通信することができないことを通知する。

ステップＳ５０５において、通信管理モジュール２３５が、第二のクライアントコンピュータ１７０を介して、第一のクライアントコンピュータ１１０がサーバコンピュータ１００とＰｕｓｈ通信することができるようにする。具体的には、通信管理モジュール２３５が、ＷｅｂＳｏｃｋｅｔ通信を行うサーバコンピュータ１００と第一のクライアントコンピュータ１１０との間の通信路を確立する（通信路確立手段として機能する）。そして、通信管理モジュール２３５が、サーバコンピュータ１００が送信した指示を第一のクライアントコンピュータ１１０に転送する。

以上の処理により、第一のクライアントコンピュータ１３０は、サーバコンピュータ１００に対してＰｕｓｈ通信開始のＨａｎｄｓｈａｋｅに失敗したとしても、以下の処理を実行できる。第一のクライアントコンピュータ１３０は、すでにＨａｎｄｓｈａｋｅに成功している第二のクライアントコンピュータ１７０を通じて、サーバコンピュータ１００と間接的にＰｕｓｈ通信を開始することができる。したがって、クライアント・サーバ間の通信コネクション数が上限値に到達していたとしても、新規にＰｕｓｈ通信を開始したいクライアントコンピュータとサーバコンピュータとは、他のクライアントコンピュータを介して、間接的にＰｕｓｈ通信を開始できる。

（実施例２）
実施例２においては、第一のクライアントコンピュータ１１０と同じセグメント内に第二のクライアントコンピュータ１７０が複数存在するシステムを想定する。

実施例２においては、図４のステップＳ４０６において、サーバコンピュータ１００が、複数の第二のクライアントコンピュータのアドレス情報を第一のクライアントコンピュータ１１０に通知する。第一のクライアントコンピュータ１１０は、図３のステップＳ３０５において、通知されたアドレス情報のうちの一つを選択し、選択したアドレス情報に対応する第二のクライアントコンピュータ宛てに間接的なＰｕｓｈ通信を要求する。この要求に失敗した場合、第一のクライアントコンピュータ１１０は、通知されたアドレス情報のうちの他の一つを選択して、選択したアドレス情報に対応する第二のクライアントコンピュータ宛てに間接的なＰｕｓｈ通信を要求する。これにより、第一のクライアントコンピュータ１１０が、サーバコンピュータ１００との間接的なＰｕｓｈ通信をすることができる可能性が高くなる。

さらに、サーバコンピュータ１００は、ＷｅｂＳｏｃｋｅｔ通信を確立している全てのクライアントコンピュータとの通信状況を把握できる。したがって、例えば、サーバコンピュータ１００は、間接的なＰｕｓｈ通信の要求先として、通信トラフィックが少ない第二のクライアントコンピュータを優先的に選択してもよい。これにより、通信リソースの最適化（分散）を実現することができる。

（実施例３）
実施例３においては、図３のステップＳ３０５の処理を実行するタイミングにおいて、第一のクライアントコンピュータ１１０が、以下の処理を実行する。第一のクライアントコンピュータ１１０は、サーバコンピュータ１００と間接的なＰｕｓｈ通信をするために必要な通信接続を維持する時間（接続維持時間）を、第二のクライアントコンピュータ１７０に通知する。このために、図３のステップＳ３０１におけるＨａｎｄｓｈａｋｅ開始イベントにおいて、通信管理モジュール２１５が、ユーザから外部メモリ１４０を介して入稿されたデータファイルのファイルサイズやページ数に基づいて、接続維持時間を決定する。

インターネット経由でデータファイルをサーバコンピュータ１００に送信し、サーバコンピュータ１００でレンダリングし、レンダリング結果をＰｕｓｈ通信で受け取るまでの、１ページ当たりの時間が、管理者によって予め定義されているものとする。例えば、データファイルの１ページ当たり１分の接続維持時間が定義されているものとする。したがって、入稿されたデータファイルが１０ページで構成されている場合、第一のクライアントコンピュータ１１０は第二のクライアントコンピュータに１０分の接続維持時間を要求する。

図５のステップＳ５０４においては、通信管理モジュール２３５は、ステップＳ５０３で確認したスケジュールと、第一のクライアントコンピュータ１１０から通知された接続維持時間とに基づいて、間接的なＰｕｓｈ通信を許可するかを判断する。具体的には、通信管理モジュール２３５が、図５のステップＳ５０３における確認処理の開始時刻から通信が遮断されてしまう時刻までの時間間隔が接続維持時間以上であるかを判断する。この時間間隔が接続維持時間以上である場合、通信管理モジュール２３５が、間接的なＰｕｓｈ通信を許可すると判断する。

実施例３によれば、処理データ量に応じて必要な接続維持時間を確保しつつ、間接的なＰｕｓｈ通信を実現することができる。したがって、データファイルに対する処理量が多く、必要な接続維持時間が長い場合に、その処理途中にサーバコンピュータ１００との接続が途切れるリスクを減らすことができる。また、データファイルに対する処理量が少なく、必要な接続維持時間が短い場合に、図５のステップＳ５０４で間接的なＰｕｓｈ通信が許可される可能性が高まる。

（実施例４）
実施例４では、第一のクライアントコンピュータ１１０が、Ｈａｎｄｓｈａｋｅ開始イベントが発生した直後に、第二のクライアントコンピュータ１７０に対して、サーバコンピュータ１００との間接的なＰｕｓｈ通信を要求する。そして、間接的なＰｕｓｈ通信に失敗した場合に、第一のクライアントコンピュータ１００が、サーバコンピュータ１００に対して直接Ｈａｎｄｓｈａｋｅを要求する。

図７は、実施例４における第一のクライアントコンピュータの動作処理の例を説明するフローチャートである。
図７のステップＳ７０１、Ｓ７０２、Ｓ７０３、Ｓ７０４、Ｓ７０８は、それぞれ、図３のステップＳ３０１、Ｓ３０５、Ｓ３０６，Ｓ３０７、Ｓ３０８と同様である。また、図７のステップ７０５乃至Ｓ７０７は、図３のステップＳ３０２乃至Ｓ３０４と同様である。

実施例４では、第一のクライアントコンピュータ１１０は、まず、第二のクライアントコンピュータ１７０に対して間接的なＰｕｓｈ通信を要求する（ステップＳ７０２）。そして、間接的なＰｕｓｈ通信に失敗した場合に、第一のクライアントコンピュータ１００が、サーバコンピュータ１００に対して、ＷｅｂＳｏｃｋｅｔのＨａｎｄｓｈａｋｅ要求を試行する（ステップＳ７０６）。したがって、第一のクライアントコンピュータ１１０が、サーバコンピュータ１００にＨａｎｄｓｈａｋｅを要求して新規に通信コネクションを生成する機会が減る。これにより、サーバコンピュータ１００とのコネクション等のリソース消費を減らすことができる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

Claims (21)

1. ファイアウォールを介して、外部の管理装置と通信するネットワークデバイスであって、
   前記管理装置との通信方式として前記ファイアウォール内からの指示要求なしに前記管理装置からの指示が可能となる所定の通信方式を利用するための要求を、他のネットワークデバイスから受信する受信手段と、
   前記所定の通信方式を利用するための要求の後に、前記管理装置から前記他のネットワークデバイスに対して前記所定の通信方式を用いて行われた指示を、前記他のネットワークデバイスに転送する転送手段と、を備えることを特徴とするネットワークデバイス。
2. 前記受信された所定の通信方式を利用するための要求に応じて、新たに前記管理装置と前記所定の通信方式による接続を確立する接続確立手段をさらに備え、
   前記転送手段は、前記管理装置から、前記接続の確立後に前記所定の通信方式を用いて行われた前記指示を前記他のネットワークデバイスに転送することを特徴とする請求項１に記載のネットワークデバイス。
3. 前記受信手段が前記要求を受信した後、自装置が前記管理装置と前記所定の通信方式を利用して通信中であるかを判断する第一の判断手段と、
   自装置が前記管理装置と前記所定の通信方式を利用して通信中であると判断された場合に、前記転送手段は、前記所定の通信方式を利用して通信中である前記管理装置からの前記指示を前記他のネットワークデバイスに転送することを特徴とする請求項１または２に記載のネットワークデバイス。
4. 自装置が前記管理装置と前記所定の通信方式を利用して通信中であると判断された場合に、自装置のスケジュールに基づいて、自装置が前記管理装置と通信不可となるまでの時間が予め決められた閾値以上であるかを判断する第二の判断手段と、
   自装置が前記管理装置と通信不可となるまでの時間が予め決められた閾値以上であると判断された場合に、前記転送手段は、前記所定の通信方式を利用して通信中である前記管理装置からの前記指示を前記他のネットワークデバイスに転送することを特徴とする請求項３に記載のネットワークデバイス。
5. 自装置が前記管理装置と通信不可となるまでの時間が予め決められた閾値以上であると判断された場合に、前記所定の通信方式を用いる前記管理装置と前記他のネットワークデバイスとの間の通信路を確立する通信路確立手段を備え、
   前記転送手段は、前記確立された通信路を用いて、前記所定の通信方式を用いて行われた前記指示を前記他のネットワークデバイスに転送することを特徴とする請求項４に記載のネットワークデバイス。
6. 前記閾値は、前記他のネットワークデバイスから通知される、前記他のネットワークデバイスの処理データ量に応じて決まる前記管理装置との接続維持時間であることを特徴とする請求項４または５に記載のネットワークデバイス。
7. ファイアウォールを介して、外部の管理装置と通信するネットワークデバイスであって、
   前記管理装置との通信方式として前記ファイアウォール内からの指示要求なしに前記管理装置からの指示が可能となる所定の通信方式を利用するための要求を、前記ファイアウォール内の他のネットワークデバイスに行う要求手段と、
   所定の通信方式を利用するための要求の後に、前記他のネットワークデバイスから転送されてきた、前記管理装置から前記所定の通信方式を用いて行われた指示を受信する受信手段と、
   前記受信された指示を実行する実行手段と、を備えることを特徴とするネットワークデバイス。
8. 前記他のネットワークデバイスは、前記所定の通信方式を仲介するブローカーサーバであることを特徴とする請求項７に記載のネットワークデバイス。
9. 前記要求手段は、自装置による前記所定の通信方式を用いた前記管理装置との接続が確立できなかった場合に前記要求を行うことを特徴とする請求項７または８に記載のネットワークデバイス。
10. 前記要求手段は、自装置による前記所定の通信方式を用いた前記管理装置との接続が確立できなかった場合に、前記管理装置から通知される、前記管理装置と前記所定の通信方式を利用して通信中の前記他のネットワークデバイスに対して前記要求を行うことを特徴とする請求項７または８に記載のネットワークデバイス。
11. 前記自装置による前記所定の通信方式を用いた前記管理装置との接続は、予め設定されたタイミング、前記自装置の電源ＯＮ時、および外部からの管理コマンドの少なくともいずれかに従って試行されることを特徴とする請求項９または１０に記載のネットワークデバイス。
12. 前記要求を受けた他のネットワークデバイスの前記所定の通信方式の利用が許可されなかった場合に、自装置による前記所定の通信方式を用いた前記管理装置との接続が試行されることを特徴とする請求項７または８に記載のネットワークデバイス。
13. 自装置が前記管理装置と通信できるかを判断する判断手段と、
    自装置が前記管理装置と通信できないと判断された場合に、前記管理装置と前記所定の通信方式を利用して通信中の前記他のネットワークデバイスを探索する探索手段とを備え、
    前記要求手段は、前記探索された前記他のネットワークデバイスに対して前記要求を行うことを特徴とする請求項７乃至１２のいずれか１項に記載のネットワークデバイス。
14. 前記所定の通信方式は、ＷｅｂＳｏｃｋｅｔプロトコルであることを特徴とする請求項１乃至１３のいずれか１項に記載のネットワークデバイス。
15. ファイアウォールを介して、外部の管理装置と通信するネットワークデバイスにおける方法であって、
    前記管理装置との通信方式として前記ファイアウォール内からの指示要求なしに前記管理装置からの指示が可能となる所定の通信方式を利用するための要求を、他のネットワークデバイスから受信する受信工程と、
    前記所定の通信方式を利用するための要求の後に、前記管理装置から前記他のネットワークデバイスに対して前記所定の通信方式を用いて行われた指示を、前記他のネットワークデバイスに転送する転送工程と、を有することを特徴とする方法。
16. ファイアウォールを介して、外部の管理装置と通信するネットワークデバイスにおける方法であって、
    前記管理装置との通信方式として前記ファイアウォール内からの指示要求なしに前記管理装置からの指示が可能となる所定の通信方式を利用するための要求を、前記ファイアウォール内の他のネットワークデバイスに行う要求工程と、
    所定の通信方式を利用するための要求の後に、前記他のネットワークデバイスから転送されてきた、前記管理装置から前記所定の通信方式を用いて行われた指示を受信する受信工程と、
    前記受信された指示を実行する実行工程と、を有することを特徴とする方法。
17. 前記所定の通信方式は、ＷｅｂＳｏｃｋｅｔプロトコルであることを特徴とする請求項１５または１６に記載の方法。
18. 請求項１乃至６のいずれか１項に記載の手段としてコンピュータを機能させるためのプログラム。
19. 請求項７乃至１４のいずれか１項に記載の手段としてコンピュータを機能させるためのプログラム。
20. 管理装置と、ファイアウォールを介して、前記ファイアウォールの外部に配置される前記管理装置と通信するネットワークデバイスおよびブローカーサーバとを含むシステムであって、
    前記ブローカーサーバは、
    前記管理装置との通信方式として前記ファイアウォール内からの指示要求なしに前記管理装置からの指示が可能となる所定の通信方式を利用するための要求を、前記ネットワークデバイスから受信する受信手段と、
    前記所定の通信方式を利用するための要求の後に、前記管理装置から前記ネットワークデバイスに対して前記所定の通信方式を用いて行われた指示を、前記ネットワークデバイスに転送する転送手段と、を備え、
    前記ネットワークデバイスは、
    前記管理装置との通信方式として前記所定の通信方式を利用するための要求を、前記ブローカーサーバに行う要求手段と、
    前記所定の通信方式を利用するための要求の後に、前記ブローカーサーバから転送されてきた、前記管理装置から前記所定の通信方式を用いて行われた指示を受信する受信手段と、
    前記受信された指示を実行する実行手段と、を備えることを特徴とするシステム。
21. 管理装置と、ファイアウォールを介して、前記ファイアウォールの外部に配置される前記管理装置と通信するネットワークデバイスおよびブローカーサーバとを含むシステムにおける方法であって、
    前記ネットワークデバイスが、前記管理装置との通信方式として前記ファイアウォール内からの指示要求なしに前記管理装置からの指示が可能となる所定の通信方式を利用するための要求を、前記ブローカーサーバに行う工程と、
    前記ブローカーサーバが、前記所定の通信方式を利用するための要求を、前記ネットワークデバイスから受信する工程と、
    前記ブローカーサーバが、前記所定の通信方式を利用するための要求の後に、前記管理装置から前記ネットワークデバイスに対して前記所定の通信方式を用いて行われた指示を、前記ネットワークデバイスに転送する工程と、
    前記ネットワークデバイスが、前記ブローカーサーバから転送されてきた、前記管理装置から前記所定の通信方式を用いて行われた指示を受信する工程と、
    前記ネットワークデバイスが、前記受信された指示を実行する工程と、を有することを特徴とする方法。

Images