JP2009020916A - 制御装置、制御プログラム、制御方法 - Google Patents

Abstract

【課題】 デバイスがネットワークを探索すると、プロトコルＡで探索されたデバイスと、プロトコルＢで探索されたデバイスが別デバイスとして、認識されてしまう場合があった。
【解決手段】 ネットワークシステムにおいてプロトコル変換処理を行なうプロキシサーバ９３００において、ネットワーク上に所定のプロトコル処理を行う他のプロトコル変換装置が存在しないか否かを探索し、ネットワーク上に他のプロトコル変換装置が探索された場合に、前記探索されたプロトコル変換装置が、プロトコル変換処理を行っているかどうかを判定する。
【選択図】 図１０

Description

本願発明は、所定のプロトコルに従って通信処理を行うネットワークデバイス、サーバ装置、及びこれらを含むシステム、方法、制御プログラムなどに関するものである。

従来から、ネットワーク上のクライアント装置からのサービス要求に応え、サービスを提供するサービス提供装置及び、サービス提供システムが知られている。

例えば、インターネットによる通信の飛躍的な普及に伴い、ネットワーク対応型機器も、従来のパーソナルコンピュータから、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）、携帯電話等のユーザインタラクティブなデバイスや、スキャナ、プリンタ、複写機、デジタルカメラ等の画像処理装置、テレビ、エアコン、冷蔵庫等の家電製品に至るまでネットワーク対応が急速に進められつつある。

それに伴い、これらネットワーク対応型デバイスを利用する上での利便性、簡易性を高めるために、ネットワークアドレスの自動設定手段、ネットワークデバイスの探索、検索手段、ネットワーク対応型デバイスを制御するためのアプリケーションソフトウエア、ユーティリティソフトウエア、オペレーティングシステム等の自動セットアップ手段を提供する、さまざまなプロトコルが提案されている。たとえば、Ｍｉｃｒｏｓｏｆｔが主体となって策定を進めるＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ、日本事務機工業会（ＪＢＭＩＡ）が推進するＢＭＬｉｎｋＳ、Ａｐｐｌｅ ＯＳ ＸでサポートされるＲｅｎｅｄｚｖｏｕｓなどがその一例である。

このようなプロトコルが提案されることで利便性、簡易性が向上する一方で、ネットワークデバイスはこれら複数のプロトコルに対応する必要が生じることにもなった。ハードウエア、ソフトウエアリソースともに潤沢な大型複写機、プリンタ等のデバイスにおいては、これら複数のプロトコルを実装することも可能であるが、それ以外のデバイスに関しては個々のプロトコルを用途に応じて実装する以外なく、開発コストを引き上げる要因となっていた。またすでに市場に投入されネットワーク上で稼動状態にあるデバイスに関しては、このようなプロトコルに対応することは不可能であった。

このような問題を解決する手段として、通常プロキシ（Ｐｒｏｘｙ）、あるいはブリッジ（Ｂｒｉｄｇｅ）とよばれるデバイスをネットワーク上で稼動させ、これらデバイスにプロトコル対応のための代行処理を実行させる方法が採られつつある。
特開２００３−００６１３３号公報（ＵＳ対応 ＡＡ２００２１５６９４７）

しかしながら、従来例によれば、プロトコル変換処理を行おうとした場合、例えば、複数のプロトコルＡ，Ｂに対応したある一台のデバイスが混在している場合、デバイスがネットワークを探索すると、プロトコルＡで探索されたデバイスと、プロトコルＢで探索されたデバイスが別デバイスとして、認識されてしまう場合があった。

また、デバイスが所定のプロトコルで探索を行う場合、プロキシサーバ（プロトコル変換サーバ）を介して、応答を受信する。この際、複数のプロトコル変換サーバが起動した場合、探索要求に対して一台のデバイスが応答すると、該応答が複数台のプロトコル変換を行うプロキシサーバ（代理サーバ）によってそれぞれ変換され、探索されたデバイスからの応答がそれぞれのプロキシサーバから複数なされる問題があった。このため、探索を行うと、複数台のプロキシサーバが存在している場合には複数台のデバイスに見えることがあった。

複数種類のプロトコルが混在するネットワークシステムにおいてプロトコル変換処理を行なう制御装置において、ネットワーク上に所定のプロトコル処理を行う他のプロトコル変換装置が存在しないか否かを、探索要求をネットワークにマルチキャストを行い起動時に探索する探索手段と、前記探索手段によって、ネットワーク上に他のプロトコル変換装置が探索された場合に、前記探索されたプロトコル変換装置が、プロトコル変換処理を行うことが可能か、又は、プロトコル変換処理を行っているかどうかを判定する判定手段と、前記判定手段が前記探索されたプロトコル変換装置がプロトコル変換処理を可能ではない、又は、プロトコル変換処理を行っていないと判定した場合に、プロトコル変換処理を起動する起動手段とを備えたことを有することを特徴とする制御装置とその装置に適用される方法、制御プログラムが開示される。

複数のプロトコルを使用しているデバイスを対象にプロトコル変換制御を行う制御装置であって、第一のプロトコルを使用しているデバイスを探索する探索手段と、第二のプロトコルを、前記第一のプロトコルに従ってデバイスを通信させるべくプロトコル変換を行う変換手段と、前記探索手段が探索したデバイス前記第一のプロトコルに対応しているか否かを認識する認識手段と、前記探索手段が探索したデバイスが前記第一のプロトコルに対応しているとは前記認識手段が認識したデバイスに対しては、第一のプロトコルへのプロトコルの変換は行わないよう前記変換手段を制御する制御手段を備えることを特徴とする制御装置とその装置に適用可能な方法、制御プログラムが開示される。

以上説明したように、本願発明の第一の側面によれば、プロトコル変換処理を行う際、複数のプロトコルに対応したデバイスが混在している場合、デバイスがネットワークを探索すると、プロトコルＡで探索されたデバイスと、プロトコルＢで探索されたデバイスを適切に整合的に認識することができるようになる。

本願発明の第二の側面によれば、複数のプロキシサーバが起動した場合でも、適切にプロキシサーバ同士が適切に調停を行い、デバイスのプロトコル変換を適切に行い、デバイス管理を適切に行うことができるようになる。

（第一実施形態）
ネットワーク上にプロトコルＡをサポートするデバイスがｘ台、およびプロトコルＡ，Ｂの双方をサポートするデバイスがｙ台、それぞれ稼動している状態において（ｘ，ｙともに１以上の整数）、プロトコルＡをプロトコルＢに変換するプロキシが稼動した場合、プロキシはプロトコルＡ，Ｂの双方をサポートするデバイスに対して、プロトコルＡを使用してプロトコルＢへの変換を実施してしまう。そのため、該プロキシの介在により、プロトコルＢを使用するネットワーククライアントに対し、プロトコルＢ対応のデバイスがｘ＋２ｙ台稼動、即ち、プロトコルＡ，Ｂの双方をサポートするデバイスに関して、全く同一のデバイスでありながらネットワーク上には実際の２倍の台数が稼動しているように処理される可能性があり、それを使用するユーザーに対し混乱を招く要因となりうる問題を抱えている。

以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されているプロトコル、ヴァージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。

本発明に係るサービス提供システムの一実施形態としてのプロトコル変換システムについて説明する。図１は本発明の一実施形態としてのプリントシステムの構成を示すブロック図である。

クライアント１００は、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ社のＭａｃ ＯＳ等の汎用オペレーティングシステム、およびその上で実行可能な汎用アプリケーションがインストールされており、本実施例で示したＷｉｎｄｏｗｓ（登録商標） ＯＳ １の場合、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＸＭＬ）／Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ （ＳＯＡＰ）を利用したＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ（ＵＰｎＰ）プロトコル２を使用して、ネットワーク上のデバイスのディスカバリ、制御、ステータスの取得等を実現しており、例えばアプリケーションソフトであるワードプロセッサ４で作成されたドキュメントは、ＵＰｎＰ Ｐｒｏｔｏｃｏｌ ２が検索発見したＵＰｎＰプロトコル対応プリンタに対し、Ｐｒｉｎｔ Ｄｒｉｖｅｒ ３で印字可能なデータに変換された後、ＵＰｎＰプロトコル ２を使用してプリントジョブの発行を実行する。

一方、ネットワーク対応デバイス、本実施の形態ではネットワーク対応型プリンタ２００は、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック５を備え、そのプロトコルスタック上にＳｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）処理部６を備え、また、プロトコルスタック５上にはプリントプロトコル処理部７が実装され、クライアントから発行されるプリント要求を解析し、プリンタコントローラ８に対し、そのプリント要求を送出する機能を備える。

該プリンタはＵＰｎＰプロトコル処理部を備えておらず、該プリンタ単独では、クライアント１００から発行されるＵＰｎＰプロトコルを使用したデバイス検索要求、およびＵＰｎＰ印刷ジョブ要求に対し応じることはできない。

もうひとつのネットワーク対応型デバイス、本実施の形態ではネットワーク対応型プリンタ４００は、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１７を備え、そのプロトコルスタック上にＨＴＴＰ１９を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。

プロトコルスタック１９上には、ネットワークプリンタ２００同様、Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）１８処理部を備える。

ＨＴＴＰ １９の上位層にはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部２０を備え、ＵＰｎＰプロトコル処理部２１を備える。ネットワーク対応型プリンタ４００はＵＰｎＰ Ｆｏｒｕｍで策定されたＰｒｉｎｔＢａｓｉｃサービスを実装しており、ＵＰｎＰプロトコル処理部は該サービスで定義されたプリントジョブ、および属性情報を解析し、プリンタコントローラ２２に対し、そのプリント要求を送出する機能を備える。

プロキシサーバ３００も同様に、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック９を備え、そのプロトコルスタック上にＨＴＴＰ１０を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。

プロトコルスタック９上にはＳｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）１１処理部を備え、ＵＰｎＰプロトコル処理部を備えていないネットワーク対応型プリンタ２００の検索、および情報の取得を該プロトコルにより実施する。

プロトコルスタック９上にはＰｒｉｎｔ Ｐｒｏｔｏｃｏｌ処理部１２を備え、ＵＰｎＰプロトコル処理部を備えていないネットワーク対応型プリンタ２００に対し、プリントジョブの発行を該Ｐｒｉｎｔ Ｐｒｏｔｏｃｏｌ部１２で実行する。

ＨＴＴＰ１０の上位層にはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部１３を備え、ＵＰｎＰプロトコル処理部１４、およびプロトコル変換処理部１６がそれぞれ、該処理部１３を介してそれぞれ、クライアント２００、およびプロキシサーバが複数ネットワーク上に存在する場合、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）で記述されたデータの双方向通信を実現する。

プロトコル変換処理部１６は、ＳＮＭＰ処理部１１、ＳＯＡＰ処理部１３、ＵＰｎＰ処理部１４、プリントプロトコル処理部１２、および記録装置制御部１５の上位層にあり、ＳＮＭＰ処理部１１を介して取得したネットワーク対応型プリンタの情報を、ＵＰｎＰプロトコルで使用される各種ＸＭＬドキュメントを作成した上で、記録装置制御部１５が制御する記録装置に記録、あるいはＵＰｎＰプロトコルから要求があった際に該当する管理テーブルに記録されたＸＭＬドキュメントを記録制御装置部１５を介して読み出し、ＵＰｎＰプロトコル処理部１４に送信するなどの処理を実行する。

またプロトコル変換処理部１６は、ＵＰｎＰプロトコルによるプリントジョブのリクエストを受信した場合、ＳＯＡＰ処理部１４を介して、ジョブコマンド、ジョブ属性情報を取得し、その内容を出力指定されたプリンタがサポートするプリントプロトコルに変換したのち、プリントプロトコル制御部１２を介して、指定プリンタにジョブを送信する。

また、プロトコル変換処理部１６は、プロキシサーバー３００が管理する管理テーブルを記録装置制御部１５を介して、該制御部が制御する記録装置に対し書き込み、読み出し処理を行なう。また同様に、プロトコル変換処理部１６は、ネットワーク上に存在する他のプロキシサーバーが管理する管理テーブルを取得した場合、記録装置制御部１５を介して、該制御部が制御する記録装置に対し書き込み、読み出し処理を行なう。

以下に、これら本システムの制御の流れを図２フローチャートに従い説明する。

プロキシサーバー３００のプロトコル変換処理部１６は起動後、記録装置制御部１５を介し、プロトコル変換処理を実施しているネットワークデバイス情報を記録する管理テーブルの内容をクリアするｓｔｅｐ２−１。該管理テーブルの詳細に関しては以下のプロセスで説明する。

次にネットワークに参加しサービスを開始するにあたり、同ネットワーク上に存在するＵＰｎＰ対応プリンタを検索する（ｓｔｅｐ２−２）。以下、図３を用いて、ＳＴＥＰ２−２を詳細に説明することにする。図３に示すフローチャートｓｔｅｐ３−１に示すように、マルチキャストアドレス２３９．２５５．２５５．２５０、ポート番号１９００に対し、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ１．０に規定される図４に示すフォーマットのＨＴＴＰ Ｍ−ＳＥＡＲＣＨパケットを発行する。

プロキシサーバー３００のプロトコル変換処理部１６は、Ｍ−ＳＥＡＲＣＨパケットを発行した後、予め規定された一定時間内、本実施例においては３０秒以内に応答があった場合、その全ての応答に対しレスポンスパケットの解析を実行する。

図５は、ネットワークデバイスの一例としてのプリンタからのレスポンスパケットのフォーマットを示すものであり、プロキシサーバー３００のプロトコル変換処理部１６は、該パケットに記載されるネットワークプリンタのＵＲＬを、記録装置制御部１５を介して、該制御部が制御する記録装置に対し記録する。該処理は受信した全レスポンスパケットに対して実施され、プロキシサーバー３００は、ネットワーク上に存在する全てのＵＰｎＰ対応プリンタのＵＲＬを記録する（ｓｔｅｐ３−２）。

以上のプロセスが完了した場合、あるいは、ステップにおいて応答が無い場合ｓｔｅｐ３−３、プロキシサーバー３００のプロトコル変換処理部１６は、ＵＰｎＰ検索処理を終了して、ｓｔｅｐ２−３に進み、プリンタ情報の取得を開始する。

図５には、ＵＲＬとして、１２３．１２３．１２３．１２３が記述されている。ＵＲＬは、ネットワークデバイスの識別情報の好適な一例である。ＳＴは、サービスタイプを意味する。

フローチャート図６はプリンタ情報取得の制御の流れを示したものである。プロキシサーバー３００の持つプロトコル変換処理部１６はＳＮＭＰ制御モジュール部１１より、以下のＭＩＢオブジェクトに対してＳＮＭＰ Ｇｅｔリクエストをブロードキャストすることで、ネットワーク上に存在するプリンタ情報を取得する（ｓｔｅｐ６−１）。

ＰｒｉｎｔｅｒＭａｋｅＡｎｄＭｏｄｅｌ：プリンタベンダ・製品名称
ＰｒｉｎｔｅｒＮａｍｅ：プリンタ名
ＰｒｉｎｔｅｒＬｏｃａｔｉｏｎ：プリンタ設置場所
ＩＰＡｄｄｒｅｓｓ：プリンタ ＩＰ アドレス
ＭＡＣＡｄｄｒｅｓｓ：プリンタＭＡＣ アドレス
ＳｕｐｐｏｒｔｅｄＰＤＬ：サポートするページ記述言語
ＳｕｐｐｏｒｔｅｄＰｒｉｎｔＰｒｏｔｏｃｏｌ：サポートするプリントプロトコル
該ＳＮＭＰ Ｇｅｔリクエストを受信したネットワーク対応プリンタ２００、および４００は、ＳＮＭＰ処理部６において、各オブジェクトに該当する情報を生成した後に、ＳＮＭＰレスポンスとしてプロキシサーバ３００に対し、ユニキャストで応答を送信する。

Ｓ６−１−１で、レスポンスを受信したかどうかを判定する。Ｓ６−１−１で，レスポンスがあった判定した場合、Ｓ６−２へ進む。レスポンスが無かったと判断した場合、Ｓ６−９へ進む。各ネットワーク対応プリンタからレスポンスを受け取ったプロキシサーバー３００のプロトコル変換処理部１６は、各レスポンス内容を記録装置に既に登録済みの管理テーブルの内容と比較し（ｓｔｅｐ６−２）、既にプロトコル変換を実施しているプリンタか否かを判断する（ｓｔｅｐ６−３）。

Ｓ６−３で、プロトコル変換を実施していないプリンタ、即ち、新規に発見されたプリンタと判断された場合、次にプロキシサーバー３００のプロトコル変換処理部１６は、該プリンタがＵＰｎＰ対応つまり、ＳＳＤＰに対応するプリンタであるか否を、先に記録装置に記録したＵＰｎＰ対応プリンタのＵＲＬと比較することで判定処理を行なう（ｓｔｅｐ６−４）。ネットワーク上に接続されたデバイスの発見と機能の把握は、ＳＳＤＰ（Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒ Ｐｒｏｔｏｃｏｌ）を用いる。ＳＳＤＰは、ＵＰｎＰを構成するための基幹部分で、ＩＥＴＦから標準仕様が発行されている。

デバイスの発見も、名前解決と同じくＩＰブロードキャストを用いる。ブロードで問合せ送信すると、条件に合うデバイスが自主的に問い合わせ元に対してＩＰアドレスとホスト名を送信する。また、具体的にどのような機能を持っているかなど、機器固有の情報もこのときに交換する。

この場合、ＳＮＭＰ ＧＥＴリクエストのレスポンスとして取得したプリンタＩＰアドレスと、記録装置に記録されたＵＲＬが一致する場合（ＳＴＥＰ６−５）、新規に発見されたプリンタはＵＰｎＰ対応プリンタであると判断し、該プリンタに対してはプロトコル変換を実施しない。

一方、ｓｔｅｐ６−４において、ＵＰｎＰ対応プリンタでは無いと判断した場合、プロキシサーバー３００のプロトコル変換処理部１６は、ＳＮＭＰＧＥＴリクエストのレスポンスとして取得した情報を管理テーブルに追加更新し、記録装置制御部１５を介して記録装置に記録する（ｓｔｅｐ６−６）。

次に、新規に管理テーブルに登録されたプリンタに関して、取得した情報を元にＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔを生成し、記録装置制御部１５を介して記録装置に記録し（ｓｔｅｐ６−７）、ｓｔｅｐ６−８においてＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、ＵＰｎＰプロトコル処理部１４より、管理テーブルに記録された全てのプリンタに関するＮｏｔｉｆｙパケットを発行し、これらプリンタがネットワーク上でのサービスを実行中であることを通知する。

プロキシサーバー３００より発行されたＳＮＭＰＧｅｔ要求に対し、何のレスポンスが得られなかった場合（ｓｔｅｐ６−１−ＮＯ）、ＳＴＥＰ６−９へ進む。ＳＴＥＰ６−９で管理テーブルを検索し、登録済みプリンタを確認する。

プロキシサーバー３００より発行されたＳＮＭＰＧｅｔ要求に対し、レスポンスが得られた場合（ｓｔｅｐ６−１−ＹＥＳ）、ＳＴＥＰ６−２へ進み、プロキシサーバ３００に登録されているプリンタデバイスと、応答のあったプリンタ情報を比較して、ＳＴＥＰ６−１探索したプリンタが管理テーブルにあるかを、管理テーブルとＳＮＭＰパケットの発行対象であるプリンタのＩＰアドレスやＵＲＬ情報などを比較して確認し、ＳＴＥＰ６−３に進む。

既に自身の管理テーブルに登録ずみのプリンタがありながら、該プリンタからレスポンスが得られなかった場合（ＳＴＥＰ６−９−１−ＹＥＳ）、プロキシサーバー３００のプロトコル変換処理部１６は管理テーブルより該プリンタ情報の削除更新し（ｓｔｅｐ６−１０）、続いてＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔを削除する（ｓｔｅｐ６−１１）。

既に自身の管理テーブルに登録ずみのプリンタがありながら、該プリンタからレスポンスが得られた場合（ＳＴＥＰ６−９−１−ＮＯ）、プリンタ情報取得処理を終了し、次の処理へ進む。

プロキシサーバー３００のプロトコル変換処理部１６は、記録装置制御部１５を介して、更新された管理テーブルを記録装置に記録した後、プロトコル変換処理部は、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、ＵＰｎＰプロトコル処理部１４より、管理テーブルから削除された全てのプリンタに関するＮｏｔｉｆｙパケットを発行し、これらプリンタがネットワーク上でのサービスを停止したことを通知する（ｓｔｅｐ６−１２）。

なお、本発明において管理テーブルは図７に示すように、先に記述した取得したＳＮＭＰオブジェクトの内容をＸＭＬで記述したテキストファイルの形式で管理される。上述のプリンタ情報所得のプロセスを完了すると、プロキシーサーバー３００のプロトコル変換処理部１６は、プロトコル変換処理（ｓｔｅｐ２−４）を開始する。フローチャート図８はプロトコル変換処理の流れを示したものである。

プロキシサーバー３００のプロトコル変換処理部は１６、クライアントから発行されるＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるデバイス検索プロトコル Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ（ＳＳＤＰ）パケットの受信通知をＵＰｎＰプロトコル処理部１４から受けたどうかを判断し、受けたと判断した場合（ｓｔｅｐ８−１―ＹＥＳ）、プロキシサーバー３００ プロトコル変換処理部１６が管理する管理テーブルを、記録装置制御部１５を介して検索し、ＳＳＤＰパケットの検索条件に該当するプリンタのＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔが記録されているＵＲＬをＳＳＤＰレスポンスとしてＵＰｎＰプロトコル処理部１４を介して返送する（ｓｔｅｐ８−２）。そして、ＳＴＥＰ８−３へ進む。

また、該ＵＲＬを取得したクライアントデバイスから、ＨＴＴＰ ＧＥＴリクエストによりＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔの取得要求をＵＰｎＰプロトコル処理部１４から受けたどうかを判断し場合受けたと判断した場合（ｓｔｅｐ８−３―ＹＥＳ）、プロキシサーバー３００ プロトコル変換処理部１６が管理する管理テーブルを、記録装置制御部１５を介して検索し、指定ＵＲＬに記録されたＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔを読み出した後、ＵＰｎＰプロトコル処理部１４を介して返送する（ｓｔｅｐ８−４）。

また、該Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔを取得したクライアントデバイスから、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定される制御手段に基づき、プリントジョブが発行された場合、この場合、ジョブコマンド、およびジョブ属性はＸＭＬの形式で記述されており、プロキシサーバー３００のプロトコル変換処理部１６は、ＵＰｎＰプロトコル処理部１４を介して該プリントジョブを受信した場合（ｓｔｅｐ８−５―ＹＥＳ）、プロトコル変換処理部１６はＳＯＡＰ処理部において該コマンド、およびジョブ属性を解析し、次に記録装置制御部１５を介して出力指定されたプリンタに該当する管理テーブル情報のうち、サポートするプリントプロトコル、およびＩＰアドレスを取得し、受信したコマンド、属性情報を該プリントプロトコルに変換したのち（ｓｔｅｐ８−６）、出力指定されたプリンタのＩＰアドレスに対し変換後の情報を送信する（ｓｔｅｐ８−７）。

プリントジョブを発行したクライアントは引き続きＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定される制御手段に基づきジョブデータ、この場合ＰＤＬをＨＴＴＰ ＰＯＳＴコマンドを使用してプロキシサーバー３００に対し送信する。該ジョブデータを受信したプロキシサーバー３００のプロトコル変換処理部１６は先のステップ同様に受信したジョブデータを指定されたプリンタがサポートするプリントプロトコルに変換し（ｓｔｅｐ８−８）、先に取得したプリンタＩＰアドレスに対しジョブデータを送信する（ｓｔｅｐ８−９）。

ＵＰｎＰジョブデータを受信したか否かの判定処理を行う（Ｓｔｅｐ８−８−１）
なお、規定時間内、本実施例においては３０秒以内にクライアントからジョブデータの受信が開始しないかどうかを判定し、開始しないと判定した場合（ＳＴＥＰ８−８−２−ＹＥＳ）、ジョブは破棄される（ｓｔｅｐ８−１０）。開始した場合は、ジョブは破棄されないで、またＳ８−８−１で受信待ちになる（ＳＴＥＰ８−８−２−ＮＯ）。

ジョブコマンド、ジョブ属性、およびジョブデータを受信したプリンタは、プリント制御部においてジョブコマンド、ジョブ属性を解析した後、プリンタコントローラに対しプリントジョブを送信しプリントを実行する。

本発明におけるプロキシサーバー３００は以上のプロセスｓｔｅｐ２−２からｓｔｅｐ２−４を繰り返し実行することで、定期的にネットワークプリンタの稼動状況を更新し、その更新情報に従いプロトコル変換処理を実行する。

ｓｔｅｐ２−５において、パワーオフによりプロキシサーバー３００のプロトコル変換処理部１６がプロトコル変換処理を停止する場合は、プロトコル変換処理部１６は、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、記録装置制御部１５を介して全ての管理テーブルを読み出し、管理テーブルに記録された全てのプリンタに関するＮｏｔｉｆｙパケットをＵＰｎＰプロトコル処理部１４を介して発行し、これらプリンタがネットワーク上でのサービスを停止したことを通知する（ｓｔｅｐ２−６）。ＳＴＥＰ２−５で、プロトコル変換処理を停止しない場合は、ＳＴＥＰ２−２へ戻る。

以上説明したように、複数のプロトコルを使用しているデバイスを対象にプロトコル変換制御を行う制御装置の一例であるプロキシサーバ３００において、第一のプロトコルの一例であるＵＰｎＰのＳＳＤＰを使用しているデバイスを探索する探索手段（図３の３−１乃至３−２）と、第二のプロトコルの一例であるＳＮＭＰの探索パケットを、ＳＳＤＰに従ってデバイスを通信させるべくプロトコル変換を行う変換手段（例えば２−４及び図８の処理）と、前記探索手段が探索したデバイスがＳＳＤＰに対応しているか否かを認識する認識手段と（ＳＴＥＰ６−３）、前記探索手段が探索したデバイスがＳＳＤＰに対応しているとは前記認識手段が認識したデバイスに対しては、ＳＳＤＰへのプロトコルの変換は行わないよう前記変換手段を制御する制御手段（ＳＴＥＰ６−４）を備えることを特徴とする制御装置。

前述の実施形態ではプリンタをネットワークデバイスとした実施の形態を示しているが、ネットワーク対応型デバイスとしてはハードディスク等のストレージデバイス、スキャナ、複写機、およびそれら複合機能を備えるデバイスであって、通信機能を介してプロキシサーバーと属性情報の交換、ジョブの送受信が可能な装置であればいずれの場合においても実現可能である。また、この場合プロキシサーバーとネットワーク対応型デバイス間の通信プロトコルは標準化された、あるいは汎用プロトコルであっても、ベンダ固有のプロトコルであっても同様に実現可能である。

また本実施形態においてはネットワーク対応型デバイスを例とした実施の形態を示しているが、デバイスとプロキシサーバー間は、ＵＳＢ、ＩＥＥＥ１３９４、パラレルなどのローカル接続による通信によっても実現可能である。

また本実施形態では、独立した形態でプロキシサーバーがネットワーク上に存在していたが、該プロキシサーバー機能は、ネットワーク対応型デバイスの内部に物理的に、あるいは論理的に組み込まれている場合においても実現可能である。

本実施形態において、プロキシが提供するプロトコル変換の組み合わせとしてＭｉｃｒｏｓｏｆｔが主体となって策定しているＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙと、ネットワーク対応型プリンタが実装するＳＮＭＰ、およびプリントプロトコルとの例を示しているが、Ａｐｐｌｅの提案するＲｅｎｄｅｚｖｏｕｓ、ＪＢＭＩＡが提案するＢＭＬｉｎｋＳなどのプロトコルに対しても実現可能であり、また、これらデバイスの検索、デバイスの制御が統合化されたプロトコルのみならず、Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＬＰ） 、Ｍｕｌｔｉｃａｓｔ ＤＮＳ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ等のデバイスが提供するサービスを検索するためのプロトコルへの利用、およびＷｅｂ ＳｅｒｖｉｃｅのようにＸＭＬ／ＳＯＡＰをベースとしたＲｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ（ＲＰＣ）形式によるデバイスの制御を、従来の制御プロトコルに変換するために利用することも可能である。

本実施形態においてプロキシサーバー間の情報通知プロトコルとしてＨＴＴＰ／ＴＣＰ／ＵＤＰ／ＩＰプロトコルを使用した例を示しているが、本発明はトランスポート手段に依存するものではなく、双方向の通信が可能であれば他の汎用プロトコル、あるいは独自プロトコルを使用した場合でも実現可能である。

（第二実施形態）
本実施形態が解決すべき別の側面として、ネットワーク上に同一のプロトコル対応、例えばプロトコルＡをプロトコルＢに変換するプロキシがＮ台稼動した場合、ひとつのネットワークデバイスがこれらＮ台のプロキシによって、それぞれ代行制御されてしまうため、プロトコルＢを使用するネットワーククライアントに対して、同一のネットワークデバイスでありながら、ネットワーク上に異なるネットワークデバイスがＮ台稼動しているかのように処理される可能性があり、それを使用するユーザーに対し混乱を招く要因となりうる問題を抱えている。

また、通常プロキシがプロトコルの代行処理が可能な処理台数には限度があり、例えばプロトコルＡをプロトコルＢに変換するプロキシ１、およびプロキシ２の２台がネットワーク上に稼動している状態において、プロキシ１のプロトコル変換処理可能台数がＭ、プロキシ１のプロトコル変換処理可能台数がＮ（Ｍ＞Ｎ）である場合、プロキシ１およびプロキシ２が互いに同一ネットワークデバイスに対しプロトコル変換処理を実施してしまう可能性があり、２台のプロキシによりＭ＋Ｎ台のネットワークデバイスのプロトコル変換処理が可能であるにも関わらず、Ｍ台までの処理しか実施できない場合がありうる。この場合、Ｎ台のネットワークデバイスに対し、２台のプロキシが重複処理を実施することになり、しかも前述のとおり、この重複処理分に関しては、あたかも２ｘＮ台分の異なるネットワークデバイスが存在するかのごとく処理されてしまうことになる。

以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されているプロトコル、ヴァージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。

本発明に係るサービス提供システムの一実施形態としてのプロトコル変換システムについて説明する。図９は本発明の一実施形態としてのプリントシステムの構成を示すブロック図である。

クライアント１００は、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ社のＭａｃ ＯＳ（登録商標）等の汎用オペレーティングシステム、およびその上で実行可能な汎用アプリケーションがインストールされており、本実施例で示したＯＳ９０１の場合、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＸＭＬ）／Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）を利用したＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ（ＵＰｎＰ）プロトコル２を使用して、ネットワーク上のデバイスのディスカバリ、制御、ステータスの取得等を実現しており、例えばアプリケーションソフトであるワードプロセッサ４で作成されたドキュメンは、ＵＰｎＰ Ｐｒｏｔｏｃｏｌ９０２（登録商標）が検索発見したＵＰｎＰプロトコル対応プリンタに対し、Ｐｒｉｎｔ Ｄｒｉｖｅｒ９０３で印字可能なデータに変換された後、ＵＰｎＰプロトコル９０２を使用してプリントジョブの発行を実行する。

一方、ネットワーク対応デバイス、本実施の形態ではネットワーク対応型プリンタ９２００は、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック５を備え、そのプロトコルスタック上にＳｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）処理部９０６を備え、また、プロトコルスタック９０５上にはプリントプロトコル処理部９０７が実装され、クライアントから発行されるプリント要求を解析し、プリンタコントローラ９０８に対し、そのプリント要求を送出する機能を備える。

該プリンタはＵＰｎＰプロトコル処理部を備えておらず、該プリンタ単独では、クライアント９１００から発行されるＵＰｎＰプロトコルを使用したデバイス検索要求、およびＵＰｎＰ印刷ジョブ要求に対し応じることはできない。

プロキシサーバ９３００も同様に、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック９０９を備え、そのプロトコルスタック上にＨＴＴＰ１０を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。

プロトコルスタック９０９上にはＳｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）１１処理部を備え、ＵＰｎＰプロトコル処理部を備えていないネットワーク対応型プリンタ２００の検索、および情報の取得を該プロトコルにより実施する。

プロトコルスタック９０９上にはＰｒｉｎｔ Ｐｒｏｔｏｃｏｌ処理部９０１２を備え、ＵＰｎＰプロトコル処理部を備えていないネットワーク対応型プリンタ２００に対し、プリントジョブの発行を該Ｐｒｉｎｔ Ｐｒｏｔｏｃｏｌ部９０１２で実行する。

ＨＴＴＰ１０の上位層にはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部１３を備え、ＵＰｎＰプロトコル処理部１４、およびプロトコル変換処理部１６がそれぞれ、該処理部９０１３を介してそれぞれ、クライアント９２００、およびプロキシサーバが複数ネットワーク上に存在する場合、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）で記述されたデータの双方向通信を実現する。

プロトコル変換処理部９０１６は、ＳＮＭＰ処理部９０１１、ＳＯＡＰ処理部９０１３、ＵＰｎＰ処理部９０１４、プリントプロトコル処理部９０１２、および記録装置制御部９０１５の上位層にあり、ＳＮＭＰ処理部１１を介して取得したネットワーク対応型プリンタの情報を、ＵＰｎＰプロトコルで使用される各種ＸＭＬドキュメントを作成した上で、記録装置制御部９０１５が制御する記録装置に記録、あるいはＵＰｎＰプロトコルから要求があった際に該当する管理テーブルに記録されたＸＭＬドキュメントを記録制御装置部９０１５を介して読み出し、ＵＰｎＰプロトコル処理部９０１４に送信するなどの処理を実行する。

またプロトコル変換処理部９０１６は、ＵＰｎＰプロトコルによるプリントジョブのリクエストを受信した場合、ＳＯＡＰ処理部９０１４を介して、ジョブコマンド、ジョブ属性情報を取得し、その内容を出力指定されたプリンタがサポートするプリントプロトコルに変換したのち、プリントプロトコル制御部９０１２を介して、指定プリンタにジョブを送信する。

また、プロトコル変換処理部９０１６はＳＯＡＰ処理部９０１３を介して他のプロキシサーバーから発行されたＮｏｔｉｆｙリクエストの詳細内容を取得し、その内容に応じた処理を実行する。

また、プロトコル変換処理部９０１６は、プロキシサーバー９３００が管理する管理テーブルを記録装置制御部９０１５を介して、該制御部が制御する記録装置に対し書き込み、読み出し処理を行なう。

また同様に、プロトコル変換処理部９０１６は、ネットワーク上に存在する他のプロキシサーバーが管理する管理テーブルを取得した場合、記録装置制御部９０１５を介して、該制御部が制御する記録装置に対し書き込み、読み出し処理を行なう。

以下に、これら本システムの制御の流れを図１０のフローチャートに従い説明する。図１０は、プロトコル変換を行うためのプロキシサーバの調停処理のフローチャートを示す図である。図１３は、既に起動しているプロキシサーバが、起動直後のプロキシサーバからのＮｏｔｉｆｙパケットを受信した場合の処理を示すフローチャートである。各図の処理により、ネットワーク上ではＷＯＲＫＩＮＧ状態のプロキシサーバが一台となることを保証するよう、各プロキシサーバが制御される。本実施例では、ＷＯＲＫＩＮＧ状態のプロキシサーバだけが、新たに追加されるデバイスのプロトコル処理を新たに受け付けるようにしている。これにより、複数のプロキシサーバがネットワーク上に乱立して、無秩序にプロトコル変換処理を行ってしまうことを防止できる。

図１０の処理は、プロキシサーバが、起動されるとスタートする。この処理では、新たに起動したプロキシサーバ９３００が、ネットワーク上に他に既にプロキシサーバ（図示省略）が起動していないか否かを判断する処理である。

プロキシサーバー９３００のプロトコル変換処理部９０１６は起動後、記録装置制御部９０１５を制御し、プロトコル変換処理を実施しているネットワークデバイス情報を記録する管理テーブルの内容をクリアして初期化する（ｓｔｅｐ１０−１）。該管理テーブルの詳細に関しては以下のプロセスで説明する。次にネットワークに参加しサービスを開始するにあたり、同ネットワーク上に存在する他のプロキシサーバーに対しＮｏｔｉｆｙパケットを発行する（ｓｔｅｐ１０−２）。

この際、マルチキャストアドレス２３９．２５５．２５５．２５０ ポート番号１９００に対し図１４に示すフォーマットのＨＴＴＰ ＮｏｔｉｆｙリクエストをＨＴＴＰパケットとして発行する。

本実施形態においては、ＨＴＴＰ Ｎｏｔｉｆｙリクエストのエンティティボディに、プロキシサーバーのステータス情報、該プロキシサーバーがサポートしているプロトコル変換処理名称、および該プロキシサーバーのＵＲＬ、物理アドレス、および管理テーブルの格納先ＵＲＬをＸＭＬ形式で記述し通知する。

ここで
＜ｓｔａｔｕｓ＞はプロキシサーバーの動作ステータスを示すものであり、起動時はＷａｋｅＵＰを記述する。
＜ｐｒｏｔｏｃｏｌ＞はプロキシサーバーが変換可能なプロトコルを示すものであり、ＵＰｎＰ、ＢＭＬｉｎｋＳ、Ｒｅｎｄｅｚｖｏｕｓなどプロトコル名称を記述する。本実施例ではＭｉｃｒｏｓｏｆｔが主体となって提案するＵＰｎＰを例として記述する。
＜ＰｒｏｘｙＵＲＬ＞は、プロキシサーバーのＩＰアドレスをＵＲＬ形式で記述する。
＜ＰｒｏｘｙＭＡＣ＞は、プロキシサーバーの物理アドレス（ＭＡＣ）を記述する。
＜ＴａｂｌｅＵＲＬ＞は、プロキシサーバーが管理する管理テーブルの格納アドレスをＵＲＬ形式で記述する。

フローチャート図１３は、ネットワーク上に既に存在する他のプロキシサーバーが、プロキシサーバ９３００から該Ｎｏｔｉｆｙパケットを受信した場合の制御フローを示すものであり、ネットワーク上にプロキシサーバー９３００以外のプロキシサーバーが存在し、これらプロキシサーバーがプロトコル変換処理を実行している場合、ＨＴＴＰ９０１０においてＨＴＴＰ Ｎｏｔｉｆｙリクエスト３００を受信した後、ＳＴＥＰ１３−１では、ＳＯＡＰ処理部９０１３においてそのリクエストのエンティティボディ３０１の解析を実行して、Ｎｏｔｉｆｙパケットの送信元のプロキシサーバが変換対象としているプロトコルと、Ｎｏｔｉｆｙパケットを受け取ったプロキシサーバが変換対象としているプロトコルとが一致するかどうかを判断する。

ＳＴＥＰ１３−１で、ＳＯＡＰ処理部９０１３が、＜ｐｒｏｔｏｃｏｌ＞内容をチェックし対応プロトコルの名称が、自身が提供するプロトコル変換処理と一致しないと判定した場合は、ＳＯＡＰ処理部９０１３は、Ｎｏｔｉｆｙリクエストを無視する。

ＳＴＥＰ１３−１で、自身が提供するプロトコル変換処理と一致すると判定した場合、ＳＴＥＰ１３−３に進む。ＳＴＥＰ１３−３では、ＳＯＡＰ処理部９０１３は、＜ｓｔａｔｕｓ＞タグの内容をチェックし、その要素がＷａｋｅＵＰであるか否かを判定する。

ＳＴＥＰ１３−３で要素がＷＡＫＥＵＰであると判定した場合、ＳＴＥＰ１３−４に進み、プロトコル変換処理部１６は記録装置制御部１３を介して、管理テーブルを読み出し、現在自身が実行しているプロトコル変換処理の状況が、プロトコル変換処理可能なデバイス数＝プロトコル変換処理実行中のデバイス数であるかどうかを判定する。ＳＴＥＰ１３−４で、これ以上、新規にプロトコル変換処理を提供できない状態にあると判定した場合、ｓｔｅｐ１３−９に進み、図１５に示すフォーマットのＨＴＴＰレスポンス４００をＨＴＴＰ Ｎｏｔｉｆｙリクエストを発行したプロキシサーバー９２００に対しユニキャストで発行する。その際、ＨＴＴＰレスポンス４００のエンティティボディとして以下の情報をＸＭＬ形式のデータをＳＯＡＰ処理部９０１３が生成し、プロキシサーバの９３００のＴＣＰ／ＵＤＰ／ＩＰプロトコルスタックを介して不図示のネットワークインタフェースを制御して通知するものとする。ここで、ＦＵＬＬとは、プロキシサーバの管理テーブルが一杯になっており、プロキシサーバにおけるプロトコル変換処理の台数が最大値に達したことを示す。

ここで、図１５の各ラベルについて説明する。＜ｓｔａｔｕｓ＞はプロキシサーバーの動作ステータスを示すラベル（タグ・記述子、識別可能な情報であればなんでもよい）であり、この場合、ＦＵＬＬ即ちこれ以上変換処理を提供できない状態であることを通知するためのものである。＜ｐｒｏｔｏｃｏｌ＞はプロキシサーバーが変換可能なプロトコルを示すものであり、ＵＰｎＰ、ＢＭＬｉｎｋＳ、Ｒｅｎｄｅｚｖｏｕｓなどプロトコル名称を記述する。本実施例ではＭｉｃｒｏｓｏｆｔが主体となって提案するＵＰｎＰを例として記述する。＜ＰｒｏｘｙＵＲＬ＞は、プロキシサーバーのＩＰアドレスをＵＲＬ形式で記述する。＜ＰｒｏｘｙＭＡＣ＞は、プロキシサーバーの物理アドレス（ＭＡＣ）を記述する。＜ＴａｂｌｅＵＲＬ＞は、プロキシサーバーが管理する管理テーブルの格納アドレスをＵＲＬ形式で記述する。

一方、現在自身が実行しているプロトコル変換処理の状況が、プロトコル変換処理可能なデバイス数がプロトコル変換処理実行中のデバイス数より大きい場合、即ち、新規にプロトコル変換処理が提供可能な状態にある場合、ｓｔｅｐ１３−５に進み、図２３に示すフォーマットのＨＴＴＰレスポンス４００をＨＴＴＰ Ｎｏｔｉｆｙリクエストを発行したプロキシサーバー９２００に対しユニキャストで発行する。その際、ＨＴＴＰレスポンス４００のエンティティボディとして以下の情報をＸＭＬ形式で記述し通知する。ここで、＜ｓｔａｔｕｓ＞はプロキシサーバーの動作ステータスを示すものであり、この場合、ＷＯＲＫＩＮＧ、即ち他のプロトコル変換プロキシサーバーが稼動する必要が無いことを通知する。＜ｐｒｏｔｏｃｏｌ＞はプロキシサーバーが変換可能なプロトコルを示すものであり、ＵＰｎＰ、ＢＭＬｉｎｋＳ、Ｒｅｎｄｅｚｖｏｕｓなどプロトコル名称を記述する。本実施例ではＭｉｃｒｏｓｏｆｔが主体となって提案するＵＰｎＰを例として記述する。＜ＰｒｏｘｙＵＲＬ＞は、プロキシサーバーのＩＰアドレスをＵＲＬ形式で記述する。＜ＰｒｏｘｙＭＡＣ＞は、プロキシサーバーの物理アドレス（ＭＡＣ）を記述する。＜ＴａｂｌｅＵＲＬ＞は、プロキシサーバーが管理する管理テーブルの格納アドレスをＵＲＬ形式で記述する。

また、ＳＴＥＰ１３−３で要素がＷＡＫＥＵＰでないと判定した場合、ＳＴＥＰ１３−６に進み、プロキシサーバがシャントダウンすることを示すＮＯＴＩＦＹパケットがＢＹＥＢＹＥパケットであるかいなかを判定する。ＳＴＥＰ１３−３で、ＢＹＥＢＹＥパケットでない場合には、処理を終了する。ＢＹＥＢＹＥパケットであると判定した場合は、Ｓ１３−７に進む。Ｓ１３−７、ＢＹＥＢＹＥパケットの送信元のプロキシサーバから取得済みであるかどうかを判定する。取得済みである場合は、当該管理テーブルを削除して処理を終了する。取得済みでない場合は、処理をそのまま終了する。

さて、フローチャート図１０に戻り、新たに起動したプロキシサーバー９３００側の処理を説明する。プロトコル変換処理部９０１６は、Ｎｏｔｉｆｙパケットを発行した後、予め規定された一定時間内、本実施例においては３０秒以内に応答があった場合ｓｔｅｐ１０−３、その全ての応答に対しレスポンスパケットのエンティティボディの解析を実行する。

ＳＯＡＰ処理部９０１３における解析処理の結果、エンティティボディのうち＜ｓｔａｔｕｓ＞タグの要素の記述が、一台でもＷＯＲＫＩＮＧのステータスの応答が返信されているか否かを判定（ｓｔｅｐ１０−４）する。

ここで既に図１３を用いて説明したように外部のプロキシサーバからっ受信されるＮＯＴＩＦＹパケットは、ＳＴＡＴＵＳ＝ＦＵＬＬか、又はＳＴＡＴＵＳ＝ＷＯＲＫＩＮＧのいずれかである。

ＳＴＥＰ１０−４の判定がＹＥＳであった場合、つまり、ＳＴＡＴＵＳ＝ＷＯＲＫＩＮＧである場合は、サーバー９３００自身がサービスを開始しなくても、既にネットワーク上で稼動状態にあるプロキシにより処理が可能であると判断される。この場合、プロキシーサーバ９３００のプロトコル変換処理部はスリープ状態に移行し（ｓｔｅｐ１０−５）、他のプロキシからＮｏｔｉｆｙメッセージを受け取るまでスリープ状態となって待ち状態となる（ＳＴＥＰ１０−６）。ＳＴＥＰ１０−６でＮＯＴＩＦＹパケットを受信した場合、この後は、プロトコル変換処理は実施せず、乱数を発生させてその乱数に応じた時間経過後（ＳＴＥＰ１０−７）、ＷＡＫＥＵＰパケットを他のプロキシサーバに対して再度発行する（ＳＴＥＰ１０―２）。

ＳＯＡＰ処理部９０１４における解析処理の結果、ＳＴＥＰ１０−３で受信した外部のプロキシーサーバからの応答のエンティティボディのうち＜ｓｔａｔｕｓ＞タグの要素の記述が、全てＦＵＬＬのステータスであるか、又は、ＷＯＲＫＩＮＧの応答が一つも無かったとＳＯＡＰ処理部９０１４が判定した場合は、現在稼動中のプロキシがネットワーク上に存在するが、これ以上、稼動中プロキシでは新規サービスの提供が不可能であるとＳＯＡＰ処理部９０１４は、判定することになる。つまり、ＳＴＥＰ１０―４で、ひとつでもＷＯＲＫＩＮＧのステータスの他のプロキシーサーバからの応答から返却されていると判定された場合は、ＳＴＡＴＵＳ＝ＦＵＬＬであることになる。

この場合、プロキシサーバー９３００のプロトコル変換処理部９０１６は、＜ｓｔａｔｕｓ＞＝ＦＵＬＬのレスポンスを送信してきた全プロキシより管理テーブルを取得要求を行う（ｓｔｅｐ１０−８）。即ち、＜ＴａｂｌｅＵＲＬ＞に記述されたＵＲＬに対しＨＴＴＰ ＧＥＴリクエストをＨＴＴＰ処理部９０１０より発行し、ＦＵＬＬステータスにあるプロキシから管理テーブルを取得する。

続いてＳＴＥＰ１０−１０で取得許可がなされるか否かを判断し、取得許可がなされた場合には、ＳＴＥＰ１０−５に進む。取得許可ななされない場合には、ＳＴＥＰ１０−９に進む。続いて、取得した管理テーブルは記録装置制御部９０１５を介してプロキシサーバ９３００の記録装置に記録される（ｓｔｅｐ１０−９）。

なお、図示しないが、外部のプロキシ―サーバから全く応答が無かった場合には、プロキシ―が存在しない旨のエラー処理に移行してもよい。

取得した管理テーブルに記録されたプリンタデバイスは、ＦＵＬＬステータスの状態にあるプロキシによりプロトコル変換処理を実施中である。従って該テーブルに記録されたプリンタデバイスに対し、プロキシサーバー９３００内のＣＰＵはプロトコル変換処理を実行しないようプロトコル変換処理部９０１６を実行する。

したがって、この発明により同一のネットワーク対応デバイス、本発明においてはネットワーク対応プリンタに対し複数のプロキシサーバーが重複してプロトコル変換処理を実施することを回避することが可能となる。

一方、ネットワーク上のＦＵＬＬステータスの状態にある、取得許可を受け取った他のプロキシサーバーは、この管理テーブル取得要求に対し、すなわちＷａｋｅＵＰステータスに移行した自身が管理する管理テーブルを、１回のみ送信するように実装される。また、プロキシーが複数存在する場合、そのうち１台にのみ送信する。一度、管理テーブルの送信を実行したプロキシサーバー内のＣＰＵは、それ以降、管理テーブルの取得要求には応じないよう制御する。この処理は図１２にて説明する。

すなわちこの発明により、ＷａｋｅＵＰステータスからプロトコル変換処理に移行が可能なプロキシサーバーは１台に限定され、同時にＷａｋｅＵＰステータスにあった複数のプロキシサーバーが稼動することを回避する。

すなわち、フローチャート図１２のｓｔｅｐ１２−１４において、ＷａｋｅＵｐステータスに移行したプロキシサーバーから管理テーブル送信要求を受信した場合、プロキシサーバー９３００のプロトコル変換処理部９０１６は該テーブルがロック中か否かを判断し、ロック中でなければ管理テーブル送信要求に応じ管理テーブルを送信し（ｓｔｅｐ１２−１５、）以降管理テーブルをロックする（ｓｔｅｐ１２−１６）。

このように、アクティブにテーブルを配布できるロックされていないプロキシサーバは、デバイス一台について、プロキシサーバ一台のみになるように制御される。

再びフローチャート図１０において、管理テーブルの取得ができなかった場合（ｓｔｅｐ１０−１０）、プロキシサーバー９３００のプロトコル変換処理部９０１６スリープ状態に移行しｓｔｅｐ１０−５、他のプロキシからＮｏｔｉｆｙメッセージを受け取るまでスリープ状態を継続し、プロトコル変換処理は実施しない（ｓｔｅｐ１０−６）。

ＳＴＥＰ１０−１０で管理テーブルの取得が許可され取得完了した場合、プロキシサーバー９３００のプロトコル変換処理部９０１６は、ＳＴＥＰ１０−１２でプリンタ情報の取得を開始する（ｓｔｅｐ１０−１２）。

ところで、Ｓｔｅｐ１０−３で、予め設定された一定時間、例えば、本実施形態においては３０ｓｅｃ以内に、応答が無い場合は、プロキシサーバー９３００のプロトコル変換処理部９０１６は、ｓｔｅｐ１０−９に進む。

図１１はプロキシサーバ９３００におけるプリンタ情報取得の制御の流れを示したものである。プロキシサーバー９３００ プロトコル変換処理部９０１６はＳＮＭＰ制御モジュール部９０１１より、以下のＭＩＢオブジェクトに対してＳＮＭＰ Ｇｅｔリクエストをパケット形式でブロードキャストすることで、ネットワーク上に存在するプリンタ情報を取得する（ｓｔｅｐ１１−１）。
ＰｒｉｎｔｅｒＭａｋｅＡｎｄＭｏｄｅｌ：プリンタベンダ・製品名称
ＰｒｉｎｔｅｒＮａｍｅ：プリンタ名
ＰｒｉｎｔｅｒＬｏｃａｔｉｏｎ：プリンタ設置場所
ＩＰＡｄｄｒｅｓｓ：プリンタ ＩＰ アドレス
ＭＡＣＡｄｄｒｅｓｓ：プリンタＭＡＣ アドレス
ＳｕｐｐｏｒｔｅｄＰＤＬ：サポートするページ記述言語
ＳｕｐｐｏｒｔｅｄＰｒｉｎｔＰｒｏｔｏｃｏｌ：サポートするプリントプロトコル
該ＳＮＭＰ Ｇｅｔリクエストを受信したネットワーク対応プリンタ９２００は、ＳＮＭＰ処理部９０６において、各オブジェクトに該当する情報を生成した後に、ＳＮＭＰレスポンスとしてプロキシサーバ９３００に対し、ユニキャストで応答を送信する。

ｓｔｅｐ１１−２で、各ネットワーク対応プリンタからレスポンスを受け取った場合、プロキシサーバー９３００のプロトコル変換処理部９０１６は、各レスポンス内容を記録装置に既に登録済みの管理テーブルの内容と比較する（ｓｔｅｐ１１−３）。ＳＴＥＰ１１−２でレスポンスを受信しない場合は処理を終了する。

ここで、プロキシサーバには、管理テーブルがＦＵＬＬとなった場合に、状態が二種類あることに注意されたい。第一が、デバイスから新たにレスポンスがあった場合、その時点でそのデバイスを含めて管理テーブルがはじめてＦＵＬＬになる状態であり、第二が、管理テーブルがＦＵＬＬに既になっており、さらに、もう一台デバイスからのレスポンスを認識した状態がある。本実施形態では、この第二のプロキシサーバのＦＵＬＬ状態をＳＴＡＴＵＳ＝ＦＵＬＬモード状態として区別する。

また、図１０の前述のｓｔｅｐ１０−９においてｓｔａｔｕｓ＝ＦＵＬＬ状態にあるプロキシから管理テーブルを取得した取得済みの全管理テーブルの内容と比較することにより、既にプロトコル変換を実施しているプリンタがあるか否かを判定する（ｓｔｅｐ１１−４）。

プロトコル変換処理を実施していないネットワークプリンタがあると判定した場合、プロトコル変換処理をしていないプリンタを検出して、ＳＴＥＰ１１−８に進む。

ＳＴＥＰ１１−８で、プロキシサーバー３００が管理する管理テーブルがフルの状態、すなわちプロキシーサーバー９３００のプロトコル変換処理部１６においてプロトコル変換処理が可能なプリンタデバイス数に到達している、又は、既に到達していたと判定した場合、ＳＴＥＰ１１−７へ進む。

次に、先のＳＴＥＰ１１−４において検出されたデバイスのステータスがＦＵＬＬモードに設定されているか否かを判定する（ＳＴＥＰ１１−７）。ＳＴＥＰ１１−７で、検出されたデバイスがフルモードではないと判定された場合、プロキシサーバー９３００のプロトコル変換処理部９０１６はステータスをＦＵＬＬモードに移行設定する（ｓｔｅｐ １１−５）。その後、図２４に示すフォーマットのＨＴＴＰ Ｎｏｔｉｆｙリクエストをマルチキャストアドレス２３９．２５５．２５５．２５０ ポート番号１９００に対し発行する ｓｔｅｐ１１−６。その際、ＨＴＴＰリクエストのエンティティボディとして、前述の図７に示す情報を通知する。このＮｏｔｉｆｙパケットにより、ネットワーク上に存在するプロキシサーバ９３００以外のプロキシサーバーに対しプロキシサーバー３００がＦＵＬＬステータスに移行したことを通知する。すなわちプロトコル変換処理部９０１６が稼動を始めて、初めて管理テーブルがフルになった場合にのみ、Ｎｏｔｉｆｙパケットが発行される。

ＳＴＥＰ１１−８で、プロキシサーバー９３００のプロトコル変換処理部９０１６が、現在プロトコル変換処理をしているデバイスの数が、プロトコル変換処理が可能なプリンタデバイス数に満たないと判定、つまり、新規に検出されたプリンタに対しプロトコル変換処理の実行が可能であるか否かを判定する。

ＳＴＥＰ１１−８で、プリンタに対しプロトコル変換処理の実行が可能であると判定した場合には、ＳＴＥＰ１１−７に進み、既にＳＴＡＴＵＳがＦＵＬＬモードであるかどうかを判定する。ＦＵＬＬモードであると判定した場合には、プロキシサーバが扱ったことがない、新規デバイスであるかどうかを判定する（ＳＴＥＰ１１−１５）。

新規デバイスであると判定した場合には、ＳＴＥＰ１１−１１に進む。新規デバイスでないと判定した場合には、過去にプロキシサーバが扱ったデバイスが、スタンバイモード、ディープスリープモード、スリープモード又はオフライン、停止状態などから復帰して再度プロトコル変換処理が必要になったことを示しているので、ＳＴＥＰ１１−９に進む。ＳＴＥＰ１１−９では、プロキシサーバー９３００のプロトコル変換処理部９０１６は、記録装置制御部１５を介して、更新された管理テーブルを記録装置に記録した後、新規に管理テーブルに登録されたプリンタに関して、取得した情報を元にＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔを生成し、記録装置制御部９０１５を介して記録装置に記録する（ｓｔｅｐ１１−９）。続いて、ｓｔｅｐ１１−１０においてＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、ＵＰｎＰプロトコル処理部１４より、管理テーブルに記録された全てのプリンタに関するＮｏｔｉｆｙパケットを発行し、これらプリンタがネットワーク上でのサービスを実行中であることを通知する。

ｓｔｅｐ１１−９で、プロトコル変換を停止していたネットワークプリンタを検出した場合も、Ｓ１１−９に進み、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔを生成し、記録装置制御部９０１５を介して記録装置に記録する。続いて、ｓｔｅｐ１１−１０においてＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、ＵＰｎＰプロトコル処理部９０１４より、管理テーブルに記録された全てのプリンタに関するＮｏｔｉｆｙパケットを発行し、これらプリンタがネットワーク上でのサービスを実行中であることをネットワーク上のデバイスに通知する。

以上の各処理に続いて、ＳＴＥＰ１１−１１で、プロキシサーバー９３００より発行されたＳＮＭＰ Ｇｅｔ要求に対し、何のレスポンスが得られなかった場合で、既に自身の管理テーブルに登録ずみのプリンタでありながら、該プリンタからレスポンスが得られるかどうかを判定する。ｓｔｅｐ１１−１１で、応答が得られなかった場合、ＳＵＡＴＵＳがＦＵＬＬモードかどうかを判定する（ＳＴＥＰ１１−１４）。ＳＴＥＰ１１−１４で、ＳＴＡＴＵＳがＦＵＬＬモードでないと判定した場合は、プロキシサーバー９３００のプロトコル変換処理部９０１６は管理テーブルより該プリンタ情報、およびＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔを削除する（ｓｔｅｐ１１−１２）そして、ＳＴＥＰ１１−１３に進む。

そして、ＳＴＥＰ１１−１３で、プロキシサーバー９３００のプロトコル変換処理部９０１６は、記録装置制御部９０１５を介して、更新された管理テーブルを記録装置に記録した後、プロトコル変換処理部は、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、ＵＰｎＰプロトコル処理部１４より、管理テーブルから削除された全てのプリンタに関するＮｏｔｉｆｙパケットを発行し、これらプリンタがネットワーク上でのサービスを停止したことを通知する。

ただし、ＳＴＥＰ１１−１４で、プロキシサーバー９３００のプロトコル変換処理部１６がＦＵＬＬステータスに移行していると判定した場合、 管理テーブルから該当するプリンタ情報の削除は実行しないで、プロキシサーバー９３００のプロトコル変換処理部１６は、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、ＵＰｎＰプロトコル処理部１４より、応答の無くなった全てのネットワークプリンタに関するＮｏｔｉｆｙパケットを発行し、これらプリンタがネットワーク上でのサービスを停止したことを通知し（ｓｔｅｐ１１−１３）、処理を終了する。

なお、本発明において管理テーブルは図２５に示すように、先に記述した取得したＳＮＭＰオブジェクトの内容をＸＭＬで記述したテキストファイルの形式で管理される。図２５には、プリンタのテーブルが定義されている。プリンタタグ＜Ｐｒｉｎｔｅｒ＞＜／Ｐｒｉｎｔｅｒ＞で挟まれた間には、各プリンタが定義されている。図では、タグの間に記述されているように、プリンタ名、設置場所、ＩＰアドレス、ＭＡＣアドレス、対応する言語、サポートする印刷プロトコルなどが定義されている。＊＊＊マークの場所には、同様に複数のプリンタから情報が取得された場合、複数プリンタの情報が書き込まれ管理可能である。

プリンタ情報所得のプロセスを完了すると、プロキシサーバー９３００のプロトコル変換処理部９０１６は、プロトコル変換処理ｓｔｅｐ１０−１３を開始する。

フローチャート図１２はプロトコル変換処理の流れを示したものである。

プロキシサーバー３００のプロトコル変換処理部は９０１６、クライアントから発行されるＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるデバイス検索プロトコル Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ（ＳＳＤＰ）パケットの受信通知をＵＰｎＰプロトコル処理部９０１４から受けた場合ｓｔｅｐ１２−１、プロキシサーバー９３００ プロトコル変換処理部９０１６が管理する管理テーブルを、記録装置制御部１５を介して検索し、ＳＳＤＰパケットの検索条件に該当するプリンタのＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔが記録されているＵＲＬをＳＳＤＰレスポンスとしてＵＰｎＰプロトコル処理部９０１４を介して返送する ｓｔｅｐ１２−２。

また、該ＵＲＬを取得したクライアントデバイスから、ＨＴＴＰ ＧＥＴリクエストによりＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔの取得要求をＵＰｎＰプロトコル処理部９０１４から受けた場合 ｓｔｅｐ１２−３、プロキシサーバー９３００ プロトコル変換処理部１６が管理する管理テーブルを、記録装置制御部９０１５を介して検索し、指定ＵＲＬに記録されたＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔを読み出した後、ＵＰｎＰプロトコル処理部９０１４を介して返送する ｓｔｅｐ１２−４。

また、該Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔを取得したクライアントデバイスから、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定される制御手段に基づき、プリントジョブが発行された場合、この場合、ジョブコマンド、およびジョブ属性はＸＭＬの形式で記述されており、プロキシサーバー３００のプロトコル変換処理部９０１６は、ＵＰｎＰプロトコル処理部１４を介して該プリントジョブを受信した場合ｓｔｅｐ１２−５、プロトコル変換処理部１６はＳＯＡＰ処理部において該コマンド、およびジョブ属性を解析し、次に記録装置制御部１５を介して出力指定されたプリンタに該当する管理テーブル情報のうち、サポートするプリントプロトコル、およびＩＰアドレスを取得し、受信したコマンド、属性情報を該プリントプロトコルに変換したのちｓｔｅｐ１２−６、出力指定されたプリンタのＩＰアドレスに対し変換後の情報を送信するｓｔｅｐ１２−７。プリントジョブを発行したクライアントは引き続きＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定される制御手段に基づきジョブデータ、この場合ＰＤＬをＨＴＴＰ ＰＯＳＴコマンドを使用してプロキシサーバー９３００に対し送信する。該ジョブデータを受信したプロキシサーバー９３００のプロトコル変換処理部１６は先のステップ同様に受信したジョブデータを指定されたプリンタがサポートするプリントプロトコルに変換しｓｔｅｐ１２−８、先に取得したプリンタＩＰアドレスに対しジョブデータを送信するｓｔｅｐ１２−９。

なお、規定時間内、本実施例においては３０秒以内にクライアントからジョブデータの受信が開始しなかった場合、ジョブは破棄されるｓｔｅｐ１２−１０。

ジョブコマンド、ジョブ属性、およびジョブデータを受信したプリンタは、プリント制御部においてジョブコマンド、ジョブ属性を解析した後、プリンタコントローラに対しプリントジョブを送信しプリントを実行する。

本発明におけるプロキシサーバー９３００は以上のプロセスを繰り返し実行することで、定期的にネットワークプリンタの稼動状況を更新し、その更新情報に従いプロトコル変換処理を実行する。

ｓｔｅｐ１０−１４において、パワーオフによりプロキシサーバー９３００のプロトコル変換処理部９０１６がプロトコル変換処理を停止する場合は、プロトコル変換処理部１６は、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、記録装置制御部９０１５を介して全ての管理テーブルを読み出し、管理テーブルに記録された全てのプリンタに関するＮｏｔｉｆｙパケットをＵＰｎＰプロトコル処理部１４を介して発行し、これらプリンタがネットワーク上でのサービスを停止したことを通知するｓｔｅｐ１０−１５。ＵＰｎＰプロトコルによるＮｏｔｉｆｙ処理を実行した後、プロトコル変換処理部９０１６は、図１１に示すフォーマットでＨＴＴＰ Ｎｏｔｉｆｙリクエストをマルチキャストアドレス２３９．２５５．２５５．２５０ ポート番号１９００に対し発行するｓｔｅｐ１０−１６。その際、ＨＴＴＰリクエストのエンティティボディとして以下の情報をＸＭＬ形式で記述し通知する。

ここで、
＜ｓｔａｔｕｓ＞はプロキシサーバーの動作ステータスを示すものであり、この場合、ＢｙｅＢｙｅ即ち、プロトコル変換処理の停止を通知する。
＜ｐｒｏｔｏｃｏｌ＞はプロキシサーバーが変換可能なプロトコルを示すものであり、ＵＰｎＰ、ＢＭＬｉｎｋＳ、Ｒｅｎｄｅｚｖｏｕｓなどプロトコル名称を記述する。本実施例ではＭｉｃｒｏｓｏｆｔが主体となって提案するＵＰｎＰを例として記述する。
＜ＰｒｏｘｙＵＲＬ＞は、プロキシサーバーのＩＰアドレスをＵＲＬ形式で記述する。
＜ＰｒｏｘｙＭＡＣ＞は、プロキシサーバーの物理アドレス（ＭＡＣ）を記述する。
＜ＴａｂｌｅＵＲＬ＞は、プロキシサーバーが管理する管理テーブルの格納アドレスをＵＲＬ形式で記述する。

以上のプロセスを実施することで、プロキシサーバ３００は、ネットワーク上で稼動する他のプロキシサーバーに対しプロトコル変換処理を停止したことを通知する。

なお、フローチャート図１３のｓｔｅｐ１３−６においてプロキシーサーバ９３００のプロトコル変換処理部９０１６が、ネットワーク上で稼動していた他のプロキシサーバーからプ該プロトコル変換処理停止のＮｏｔｉｆｙパケットを受信した際、ＳＯＡＰ処理部１３において、該パケットのエンティティボディを解析し、Ｎｏｔｉｆｙパケットを発行したプロキシサーバーから管理テーブルを取得したか否かをチェックし、管理テーブルを取得している場合ｓｔｅｐ１３−７、この管理テーブルを記録装置制御部１５を介して削除するｓｔｅｐ１３−８。

すなわち、ＢｙｅＢｙｅを発行したプロキシサーバがプロトコル変換処理を提供していたプリンタの変換処理は、現在Ｗｏｒｋｉｎｇ状態にあるプロキシサーバ３００により変換処理が受け継がれることになる。

フローチャート図１０のｓｔｅｐ１０−５においてＳＬＥＥＰ状態に移行したプロキシサーバ９３００のプロトコル変換処理部９０１６は、他のプロキシサーバーから発行されるＮｏｔｉｆｙパケットの監視を行う。ＳＯＡＰ処理部１３を介して受信したＮｏｔｉｆｙパケットのエンティティボディのうち＜ｓｔａｔｕｓ＞の要素がＢｙｅＢｙｅ、あるいはＦＵＬＬであるパケットが１パケットでも存在した場合、プロトコル変換処理部１６はあらかじめ規定されたアルゴリズムに従い１−３０の整数の乱数を生成したのち、生成した乱数の値と等価な秒数だけウエイトした後にｓｔｅｐ１０−７、ｓｔｅｐ１０−２のＮｏｔｉｆｙ発行プロセスを実行する。

以上述べたように、複数種類のプロトコルが混在するネットワークシステムにおいてプロトコル変換処理を行なう制御装置の一例であるプロキシサーバ９３００において、ネットワーク上に他のプロキシサーバ（図示省略）が存在しないか否かを、探索要求をネットワークにマルチキャストを行い起動時に探索し（図１０のＳＴＥＰ１０−３，１０−４にように、プロキシサーバ９３００内のＣＰＵがメモリに記憶された制御プログラムを実行して実現する機能）、前記探索手段によって、ネットワーク上に他のプロトコル変換装置が探索された場合に、前記探索されたプロトコル変換装置が、プロトコル変換処理を行うことが可能か、又は、プロトコル変換処理を行っているかどうかを判定する判定手段と（ＳＴＥＰ１０−４）、前記判定手段が前記探索されたプロトコル変換装置がプロトコル変換処理を可能ではない、又は、プロトコル変換処理を行っていないと判定した場合に、プロトコル変換処理の一例である図１０のＳＴＥＰ１０―１３を起動する起動手段（一例として図９の９０１４そのものが起動実行してもよいし、又は、不図示の探索アプリケーションプログラムやＯＳから起動してもよい。）とを備えている。

本実施例ではプリンタをネットワークデバイスとした実施の形態を示しているが、ネットワーク対応型デバイスとしてはハードディスク当のストレージデバイス、スキャナ、複写機、およびそれら複合機能を備えるデバイスであって、通信機能を介してプロキシサーバーと属性情報の交換、ジョブの送受信が可能な装置であればいずれの場合においても実現可能である。

また、この場合プロキシサーバーとネットワーク対応型デバイス間の通信プロトコルは標準化された、あるいは汎用プロトコルであっても、ベンダ固有のプロトコルであっても同様に実現可能である。

また本実施例においてはネットワーク対応型デバイスを例とした実施の形態を示しているが、デバイスとプロキシサーバー間は、ＵＳＢ、ＩＥＥＥ１３９４、パラレルなどのローカル接続による通信によっても実現可能である。

また本実施例では、独立した形態でプロキシサーバーがネットワーク上に存在していたが、該プロキシサーバー機能は、ネットワーク対応型デバイスの内部に物理的に、あるいは論理的に組み込まれている場合においても実現可能である。

本実施例において、プロキシが提供するプロトコル変換の組み合わせとしてＭｉｃｒｏｓｏｆｔが主体となって策定しているＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙと、ネットワーク対応型プリンタが実装するＳＮＭＰ、およびプリントプロトコルとの例を示しているが、Ａｐｐｌｅの提案するＲｅｎｄｅｚｖｏｕｓ、ＪＢＭＩＡが提案するＢＭＬｉｎｋＳなどのプロトコルに対しても実現可能であり、また、これらデバイスの検索、デバイスの制御が統合化されたプロトコルのみならず、Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＬＰ）、Ｍｕｌｔｉｃａｓｔ ＤＮＳ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ等のデバイスが提供するサービスを検索するためのプロトコルへの利用、およびＷｅｂ ＳｅｒｖｉｃｅのようにＸＭＬ／ＳＯＡＰをベースとしたＲｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ（ＲＰＣ）形式によるデバイスの制御を、従来の制御プロトコルに変換するために利用することも可能である。

本実施例において、ＨＴＴＰによるＮｏｔｉｆｙパケット発行の際に、該パケットのエンティティにＸＭＬの形式で付加情報を記述して送信しているが、該エンティティの記述にはバイナリデータを利用した記述によっても実現可能である。また、新規にＨＴＴＰヘッダを定義し、該ヘッダを使用する形態での通知手段を用いても実現可能である。

本実施例においてプロキシサーバー間の情報通知プロトコルとしてＨＴＴＰ／ＴＣＰ／ＵＤＰ／ＩＰプロトコルを使用した例を示しているが、本発明はトランスポート手段に依存するものではなく、双方向の通信が可能であれば他の汎用プロトコル、あるいは独自プロトコルを使用した場合でも実現可能である。

以上説明したように、本実施形態の一つの側面によれば、同一のプロトコル変換機能を備えたプロトコル変換装が同一通信回線上で稼動状態にある場合、プロトコル変換処理装置が自動的に他のプロトコル変換処理装置のステータスを取得し、プロトコル変換処理の実行、待機を判断することが可能となり、またプロトコル変換処理を実行する際、既に同一プロトコル変換処理を実行しているプロトコル変換処理装置からプロトコル変換を実施している情報処理装置情報を取得し、これら情報処理装置に対してはプロトコル変換を実施しない機能をそなえるため、同一プロトコル変換処理を提供するプロトコル変換処理装置の間で同一の情報処理装置に対して、重複してプロトコル変換処理を実施することを回避することが可能となる。

さらに、本実施形態他の別の側面によれば、これら処理は本発明を適用したプロトコル変換処理装置が自動的に処理するものであり、ネットワーク管理者を含むネットワーク上の情報処理装置を使用するユーザーが特別な設定、制御等関与することなく、プロトコル変換処理装置が備える変換能力を最大限利用することが可能となる。

（第三実施形態）
以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されているプロトコル、ヴァージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではないことはこれまでと同様である。

本発明に係るサービス提供システムの一実施形態としてのプロトコル変換システムについて説明する。図１６は本発明の一実施形態としてのプリントシステムの構成を示すブロック図である。

クライアント１６１００は、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ社のＭａｃ ＯＳ（登録商標）等の汎用オペレーティングシステム、およびその上で実行可能な汎用Ｗｅｂブラウザ、アプリケーションソフトなどがインストールされている。

本実施例で示したＷｉｎｄｏｗｓ（登録商標） ＯＳ １６１の場合、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＸＭＬ） ／ Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ （ＳＯＡＰ）を利用したＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ（ＵＰｎＰ）プロトコル１６２を使用して、ネットワーク上のデバイスのディスカバリ、制御、ステータスの取得等を実現しており、ＵＰｎＰ対応デバイスから取得したＨＴＭＬで記述されたプレゼンテーションドキュメントをＷｅｂブラウザ１６３で表示し、該Ｗｅｂブラウザに組み込まれたスクリプト等を利用することで、例えばアプリケーションソフトであるワードプロセッサ４で作成したドキュメントを、プレゼンテーションドキュメントを送信したＵＰｎＰプロトコル対応プリンタに対して、プリント属性情報と共に送信する。

一方、ネットワーク対応デバイス、本実施の形態ではネットワーク対応型プリンタ１６２００は、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１６５を備え、そのプロトコルスタック上にＳｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）処理部１６６を備え、また、プロトコルスタック５上にはプリントプロトコル処理部１６７が実装され、クライアントから発行されるプリント要求を解析し、プリンタコントローラ１６８に対し、そのプリント要求を送出する機能を備える。

該プリンタはＵＰｎＰプロトコル処理部を備えておらず、該プリンタ単独では、クライアント１６１００から発行されるＵＰｎＰプロトコルを使用したデバイス検索要求、およびＵＰｎＰ印刷ジョブ要求に対し応じることはできない。

プロキシサーバ１６３００も同様に、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１６９を備え、そのプロトコルスタック上にＨＴＴＰ１０を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。

プロトコルスタック１６９上にはＳｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）１６１１処理部を備え、ＵＰｎＰプロトコル処理部を備えていないネットワーク対応型プリンタ２００の検索、および情報の取得を該プロトコルにより実施する。

プロトコルスタック９上にはＰｒｉｎｔ Ｐｒｏｔｏｃｏｌ処理部１６１２を備え、ＵＰｎＰプロトコル処理部を備えていないネットワーク対応型プリンタ１６２００に対し、プリントジョブの発行を該Ｐｒｉｎｔ Ｐｒｏｔｏｃｏｌ部１６１２で実行する。

ＨＴＴＰ１６１０の上位層にはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部１６１３を備え、ＵＰｎＰプロトコル処理部１６１４、およびプロトコル変換処理部１６１６がそれぞれ、該処理部１６１３を介してそれぞれ、クライアント１６２００、およびプロキシサーバが複数ネットワーク上に存在する場合、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）で記述されたデータの双方向通信を実現する。

プロトコル変換処理部１６１６は、ＳＮＭＰ処理部１６１１、ＳＯＡＰ処理部１６１３、ＵＰｎＰ処理部１６１４、プリントプロトコル処理部１６１２、記録装置制御部１６１５、ＸＭＬ生成部１６１７、ＨＴＭＬ生成部１６１８およびファイル変換処理部１６１９の上位層にあり、ＳＮＭＰ処理部１６１１を介して取得したネットワーク対応型プリンタの情報を、ＵＰｎＰプロトコルで使用される各種ＸＭＬドキュメントをＸＭＬ生成部１６１７で作成し、ＵＰｎＰプロトコルで使用されるプレゼンテーションドキュメントをＨＴＭＬ生成部１８で生成した上で、記録装置制御部１６１５が制御する記録装置に記録、あるいはＵＰｎＰプロトコルから要求があった際に該当する管理テーブルに記録されたＸＭＬドキュメント、プレゼンテーションドキュメントを記録制御装置部１５を介して読み出し、ＵＰｎＰプロトコル処理部１４に送信するなどの処理を実行する。

またプロトコル変換処理部１６１６は、ＵＰｎＰプロトコルによるプリントジョブのリクエストを受信した場合、ＳＯＡＰ処理部１６１４を介して、ジョブコマンド、ジョブ属性情報を取得し、その内容を出力指定されたプリンタがサポートするプリントプロトコルに変換したのち、プリントプロトコル制御部１６１２を介して、指定プリンタにジョブを送信する。この際にジョブ属性を解析し、受信したジョブデータが指定プリンタでサポートされていないデータタイプである場合、ファイル変換処理部１６１９で、指定プリンタがサポートしている印字可能データに変換した後にプリントプロトコル制御部１６１２を介して、指定プリンタにジョブを送信する。

また、プロトコル変換処理部１６１６は、プロキシサーバー１６３００が管理する管理テーブルを記録装置制御部１６１５を介して、該制御部が制御する記録装置に対し書き込み、読み出し処理を行なう。

また同様に、プロトコル変換処理部１６１６は、ネットワーク上に存在する他のプロキシサーバーが管理する管理テーブルを取得した場合、記録装置制御部１６１５を介して、該制御部が制御する記録装置に対し書き込み、読み出し処理を行なう。

以下に、これら本システムの制御の流れを図１７のフローチャートに従い説明する。

プロキシサーバー３００のプロトコル変換処理部１６１６は起動後、記録装置制御部１５を介し、プロトコル変換処理を実施しているネットワークデバイス情報を記録する管理テーブルの内容をクリアするｓｔｅｐ１７−１。該管理テーブルの詳細に関しては以下のプロセスで説明する。

次にネットワークに参加しサービスを開始するにあたり、同ネットワーク上に存在するネットワーク対応プリンタを検索するためｓｔｅｐ１７−２に進みプリンタ情報の取得を開始する。

フローチャート図１８はプリンタ情報取得の制御の流れを示したものである。

プロキシサーバー１６３００ プロトコル変換処理部１６１６はＳＮＭＰ制御モジュール部１６１１より、ネットワーク上に存在するプリンタ情報を取得するため、以下のＭＩＢオブジェクトに対してＳＮＭＰ Ｇｅｔリクエストをブロードキャストする（ｓｔｅｐ１８−１）。ＳＴＥＰ１８−１−２で、レスポンスを受信したかどうかを判定する、ＳＴＥＰ１８−１−２でレスポンスを受信した場合には、ＳＴＥＰ１８−２に進む。ＳＴＥＰ１８−１−２でレスポンスを受信していない場合には、ＳＴＥＰ１８−８へ進む。

ＰｒｉｎｔｅｒＭａｋｅＡｎｄＭｏｄｅｌ：プリンタベンダ・製品名称
ＰｒｉｎｔｅｒＮａｍｅ：プリンタ名
ＰｒｉｎｔｅｒＬｏｃａｔｉｏｎ：プリンタ設置場所
ＩＰＡｄｄｒｅｓｓ：プリンタ ＩＰ アドレス
ＭＡＣＡｄｄｒｅｓｓ：プリンタＭＡＣ アドレス
ＳｕｐｐｏｒｔｅｄＰＤＬ：サポートするページ記述言語
ＳｕｐｐｏｒｔｅｄＰｒｉｎｔＰｒｏｔｏｃｏｌ：サポートするプリントプロトコル
ＳＴＥＰ１８−１において、プロキシサーバで発行された該ＳＮＭＰ Ｇｅｔリクエストを受信したネットワーク対応プリンタ１６２００は、ＳＮＭＰ処理部１６６において、各オブジェクトに該当する情報を生成した後に、ＳＮＭＰレスポンスとしてプロキシサーバ１６３００に対し、ユニキャストで応答を送信する。

Ｓ１８−１−２で各ネットワーク対応プリンタからレスポンスを受け取ったプロキシサーバー１６３００のプロトコル変換処理部１６１６は、各レスポンス内容を記録装置に既に登録済みの管理テーブルの内容と比較する（ｓｔｅｐ１８−２）。続いて、プロトコル変換処理部１６１６は、既にプロトコル変換を実施しているプリンタか否かを判断する（ｓｔｅｐ１８−３）。ＳＴＥＰ１８−３で、プロトコル変換処理しているプリンタであると判断した場合は、処理を終了する。

ＳＴＥＰ１８−３で、プロトコル変換を実施していないプリンタ、即ち、新規に発見されたプリンタと判断した場合、プロキシサーバー１６３００のプロトコル変換処理部１６１６は、ＳＮＭＰ ＧＥＴリクエストのレスポンスとして取得した情報を管理テーブルに追加更新し、記録装置制御部１６１５を介して記録装置に記録する（ｓｔｅｐ１８−４）。

次に、新規に管理テーブルに登録されたプリンタに関して、取得した情報を元にＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ ＤｏｃｕｍｅｎｔをＸＭＬ生成部１７を介して生成し、生成した該ドキュメントを、記録装置制御部１６１５を介して記録装置に記録しｓｔｅｐ１８−５、さらにＨＴＭＬ生成部１６１８においてＨＴＭＬで記述されたプレゼンテーションドキュメントを生成する。該プレゼンテーション作成に必要なアイコン、イメージデータ類は記録装置に記録されており、ＨＴＭＬ生成部１６１８は記録制御装置１６１５を介して必要な情報を取得する。ＨＴＭＬ生成部１６１８により生成されたプレゼンテーションドキュメントは、記録装置制御部１５を介して記録装置に記録するｓｔｅｐ１８−６。

Ｓｔｅｐ１８−７においてＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、ＵＰｎＰプロトコル処理部１６１４より、管理テーブルに記録された全てのプリンタに関するＮｏｔｉｆｙパケットを発行し、これらプリンタがネットワーク上でのサービスを実行中であることを通知する。

プロキシサーバー１６３００より発行されたＳＮＭＰ Ｇｅｔ要求に対し、何のレスポンスが得られなかった場合はｓｔｅｐ１８−８に進む、ＳＴＥＰ１８−８では、既に自身の管理テーブルに登録ずみのプリンタがあるかどうかを調べる。Ｓ１８−８−１では、既に登録ずみのプリンタであるかどうかを判断する。Ｓ１８−１−１で、登録済みのプリンタがあると判断した場合、プロキシサーバー１６３００のプロトコル変換処理部１６１６は管理テーブルより該プリンタ情報の削除更新を行う（ＳＴＥＰ１８−９）。次に、Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔの削除（ｓｔｅｐ１８−１０）、およびプレゼンテーションドキュメントの削除（ｓｔｅｐ１８−１１）を実行する。

プロキシサーバー１６３００のプロトコル変換処理部１６１６は、記録装置制御部１６１５を介して、更新された管理テーブルを記録装置に記録した後、プロトコル変換処理部は、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、ＵＰｎＰプロトコル処理部１４より、管理テーブルから削除された全てのプリンタに関するＮｏｔｉｆｙパケットを発行し、これらプリンタがネットワーク上でのサービスを停止したことを通知する ｓｔｅｐ１８−１２。

なお、本発明において管理テーブルは図２６に示すように、先に記述した取得したＳＮＭＰオブジェクトの内容をＸＭＬで記述したテキストファイルの形式で管理される。

以上図１８で説明した処理が、図１７のプリンタ情報取得処理である。図１７に話を戻す。プリンタ情報所得のプロセスを完了すると、プロキシサーバー１６３００のプロトコル変換処理部１６１６は、プロトコル変換処理 ｓｔｅｐ１７−３を開始する。

以下、図２０を用いて詳細処理を示す。フローチャート図２０はプロトコル変換処理の流れを示したものである。プロキシサーバー１６３００のプロトコル変換処理部１６１６は、クライアントから発行されるＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるデバイス検索プロトコル Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ（ＳＳＤＰ）パケットの受信通知をＵＰｎＰプロトコル処理部１６１４から受けたどうかを判定する（ｓｔｅｐ２０−１）。Ｓ２０−１で受信したと判定した場合、Ｓ２０−２へ進む。受信していないと判断した場合、Ｓ２０−３に進む。

Ｓ２０−２では、プロキシサーバー１６３００ プロトコル変換処理部１６１６が管理する管理テーブルを、記録装置制御部１６１５を介して検索し、ＳＳＤＰパケットの検索条件に該当するプリンタのＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔが記録されているＵＲＬをＳＳＤＰレスポンスとしてＵＰｎＰプロトコル処理部１６１４を介して返送する（ｓｔｅｐ２０−２）。

また、該ＵＲＬを取得したクライアントデバイスから、ＨＴＴＰ ＧＥＴリクエストによりＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔの取得要求をＵＰｎＰプロトコル処理部１６１４から受けたかどうかを判定する（ｓｔｅｐ２０−３）。Ｓ２０−３で、取得要求を受けたと判断した場合、プロキシサーバー１６３００ プロトコル変換処理部１６１６が管理する管理テーブルを、記録装置制御部１６１５を介して検索し、指定ＵＲＬに記録されたＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔを読み出した後、ＵＰｎＰプロトコル処理部１６１４を介して返送する（ｓｔｅｐ２０−４）。そして、Ｓ２０−５へ進む。Ｓ２０−３で、該取得要求を受信していないと判断した場合、Ｓ２０−５へ進む。

該Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｏｃｕｍｅｎｔには、ステップにおいて作成されたプレゼンテーションドキュメントの格納先がＵＲＬで記録されており、クライアントデバイスから、ＨＴＴＰ ＧＥＴリクエストによりプレゼンテーションドキュメントの取得要求をＵＰｎＰプロトコル処理部１６１４から受けたかどうかを判断する（ｓｔｅｐ２０−５）。プレゼンテーションドキュメントの取得要求を受信したと判断した場合、Ｓ２０−６へ進む。Ｓ２０−６では、プロキシサーバー１６３００ プロトコル変換処理部１６１６が管理する管理テーブルを記録装置制御部１６１５を介して検索し、指定ＵＲＬに記録されたプレゼンテーションドキュメントを読み出した後、ＵＰｎＰプロトコル処理部１６１４を介して返送する。プレゼンテーションドキュメントの取得要求を受信していないと判断した場合は、そのままＳ２０−７に進む。

本実施例で示したクライアント１６１００の場合、オペレーティングシステムがＵＰｎＰプロトコル対応しており、ｓｔｅｐ２０−６によりプロキシサーバー３００からプレゼンテーションドキュメントの受信が完了すると、Ｗｅｂブラウザを自動的に起動し受信したプレゼンテーションドキュメントを表示する。

図２１はクライアント１００のディスプレイ上に表示されたプレゼンテーション内容であり、この表示によりクライアント１００を使用しているユーザーは、該表示内容を介してネットワーク対応プリンタ２００に関するデバイス名称、モデル名、ＩＰアドレス、オプションの装着状態等の情報を視覚的に確認できる。

ここで、該表示における“Ｐｒｉｎｔ Ｄｏｃｕｍｅｎｔ”をクリックすると、図２２に示すページに切り替わり、ここでネットワーク対応プリンタ２００に対し、出力すべきファイルの指定：Ｐｒｉｎｔ Ｆｉｌｅ、および、出力部数：Ｃｏｐｙ、出力用紙サイズ：Ｍｅｄｉａ Ｓｉｚｅ、ページレイアウト：Ｎ−Ｕｐ、両面・片面印刷指定：Ｔｗｏ−ｓｉｄｅｄ Ｐｒｉｎｔｉｎｇ、印字品位：Ｐｒｉｎｔ Ｑｕａｌｉｔｙ、オリエンテーション：Ｏｒｉｅｎｔａｔｉｏｎ等のジョブ属性の指定が可能となる。これら属性情報の設定が完了した後に、Ｐｒｉｎｔボタンを押下すると、プレゼンテーションドキュメントに記述されたスクリプトがＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるスキーマに従いＳＯＡＰエンベロープを生成した後、プロキシ３００に対しＨＴＴＰ ＰＯＳＴリクエストを発行する。

プロキシサーバー１６３００のプロトコル変換処理部１６は、ＵＰｎＰプロトコル処理部１６１４を介して該リクエストを受信した場合ｓｔｅｐ２０−７、プロトコル変換処理部１６１６はＳＯＡＰ処理部において該コマンド、およびジョブ属性を解析し、次に記録装置制御部１６１５を介して出力指定されたプリンタに該当する管理テーブル情報のうち、サポートするプリントプロトコル、およびＩＰアドレスを取得し、受信したコマンド、属性情報を該プリントプロトコルに変換したのち（ｓｔｅｐ２０−８）、出力指定されたプリンタのＩＰアドレスに対し変換後の情報を送信する（ｓｔｅｐ２０−９）。

プリントジョブを発行したクライアントは引き続きＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定される制御手段に基づきジョブデータをＨＴＴＰ ＰＯＳＴコマンドを使用してプロキシサーバー１６３００に対し送信する。該ジョブデータを受信したプロキシサーバー１６３００のプロトコル変換処理部１６１６は、受信データのデータタイプを解析し、該データタイプがｓｔｅｐ１８−４で取得した管理情報に記録されるＳｕｐｐｏｒｔｅｄＰＤＬ：サポートするページ記述言語と一致している場合、先のステップ同様に受信したジョブデータを指定されたプリンタがサポートするプリントプロトコルに変換しｓｔｅｐ２０−１０、先に取得したプリンタＩＰアドレスに対しジョブデータを送信する ｓｔｅｐ２０−１１。

Ｓ２０−９−１で、ＵＰｎＰジョブデータを受信したかどうかを判定する。Ｓ２０―９−１でＵＰＮＰジョブデータを受信したと判定した場合、Ｓ２０−９−２へ進む。Ｓ２０−９−２では、受信データのデータタイプを解析した結果、ｓｔｅｐ１８−４の処理で取得した管理情報に記録されるＳｕｐｐｏｒｔｅｄＰＤＬ：サポートするページ記述言語と一致ないと判定した場合、プロトコル変換処理部１６１６は受信したデータをファイル変換処理部１６１９において、ｓｔｅｐ２０−１２で、取得したプリンタＰＤＬデータに変換した後、指定されたプリンタがサポートするプリントプロトコルに変換する（ｓｔｅｐ２０−１０）。続いて、先に取得したプリンタＩＰアドレスに対し変換後のジョブデータを送信する（ｓｔｅｐ２０−１１）そして、処理を終了する。

Ｓ２０−９−２で、受信データのデータタイプを解析した結果、ｓｔｅｐ１８−４の処理で取得した管理情報に記録されるＳｕｐｐｏｒｔｅｄＰＤＬ：サポートするページ記述言語と一致すると判定した場合、Ｓ２０−１０に進んで同様にＳ２０−１１の処理へ抜け、処理を終了する。

Ｓ２０−９−１で、ジョブデータが、受信されず、Ｓ２０−１１−１で規定時間経過したと判断された場合、本実施例においては３０秒以内にクライアントからジョブデータの受信が開始しなかった場合、ジョブは破棄される（ｓｔｅｐ２０−１３）。

ジョブコマンド、ジョブ属性、およびジョブデータを受信したプリンタは、プリント制御部においてジョブコマンド、ジョブ属性を解析した後、プリンタコントローラに対しプリントジョブを送信しプリントを実行する。

本発明におけるプロキシサーバー１６３００は以上のプロセスｓｔｅｐ１７−２からｓｔｅｐ１７−３を繰り返し実行することで、定期的にネットワークプリンタの稼動状況を更新し、その更新情報に従いプロトコル変換処理を実行する。

ｓｔｅｐ１７−４において、パワーオフによりプロキシサーバー３００のプロトコル変換処理部１６がプロトコル変換処理を停止するかどうかを判定する。Ｓ１７−４で、停止すると判定した場合、プロトコル変換処理部１６は、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１．０において規定されるＮｏｔｉｆｉｃａｔｉｏｎ手段に基づき、記録装置制御部１５を介して全ての管理テーブルを読み出し、管理テーブルに記録された全てのプリンタに関するＮｏｔｉｆｙパケットをＵＰｎＰプロトコル処理部１４を介して発行し、これらプリンタがネットワーク上でのサービスを停止したことを通知する ｓｔｅｐ１７−５。

Ｓ１７−４で停止しないと判定した場合は、プリンタ情報取得処理（Ｓ１７−２）へ戻る。

本実施例ではプリンタをネットワークデバイスとした実施の形態を示しているが、ネットワーク対応型デバイスとしてはハードディスク等のストレージデバイス、複写機、および複合機能を備えるデバイスであって、通信機能を介してプロキシサーバーと属性情報の交換、ジョブの送受信が可能な装置であればいずれの場合においても実現可能である。

また、この場合プロキシサーバーとネットワーク対応型デバイス間の通信プロトコルは標準化された、あるいは汎用プロトコルであっても、ベンダ固有のプロトコルであっても同様に実現可能である。

また本実施例においてはネットワーク対応型デバイスを例とした実施の形態を示しているが、デバイスとプロキシサーバー間は、ＵＳＢ、ＩＥＥＥ１３９４、パラレルなどのローカル接続による通信によっても実現可能である。

また本実施例では、独立した形態でプロキシサーバーがネットワーク上に存在していたが、該プロキシサーバー機能は、ネットワーク対応型デバイスの内部に物理的に、あるいは論理的に組み込まれている場合においても実現可能である。また同様にネットワーククライアントデバイスの内部に物理的に、あるいは論理的に組み込まれている場合においても実現可能である。

本実施例において、プロキシが提供するプロトコル変換の組み合わせとしてＭｉｃｒｏｓｏｆｔが主体となって策定しているＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙと、ネットワーク対応型プリンタが実装するＳＮＭＰ、およびプリントプロトコルとの例を示しているが、Ａｐｐｌｅの提案するＲｅｎｄｅｚｖｏｕｓ、ＪＢＭＩＡが提案するＢＭＬｉｎｋＳなどのプロトコルに対しても実現可能であり、また、これらデバイスの検索、デバイスの制御が統合化されたプロトコルのみならず、Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＬＰ）、Ｍｕｌｔｉｃａｓｔ ＤＮＳ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ等のデバイスが提供するサービスを検索するためのプロトコルへの利用、およびＷｅｂ ＳｅｒｖｉｃｅのようにＸＭＬ／ＳＯＡＰをベースとしたＲｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ（ＲＰＣ）形式によるデバイスの制御を、従来の制御プロトコルに変換するために利用することも可能である。

本実施例においてプロキシサーバー間の情報通知プロトコルとしてＨＴＴＰ／ＴＣＰ／ＵＤＰ／ＩＰプロトコルを使用した例を示しているが、本発明はトランスポート手段に依存するものではなく、双方向の通信が可能であれば他の汎用プロトコル、あるいは独自プロトコルを使用した場合でも実現可能である。

（他の実施形態）
本実施形態における各図に示す処理が、外部からインストールされるプログラムによって、クライアント、プロキシサーバ、プリンタが備えるＣＰＵ（中央制御装置）により、それぞれ遂行される。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群をホストコンピュータに供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、又は、外部サーバ（図示省略）からダウンロードすることで、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。プログラムコードを供給するための記憶媒体としては、たとえば、フロッピィーディスク、ハードディスク、光ディスク、光磁気ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

（他の発明の実施態様）
（実施態様１）
ネットワークデバイスの変換に対応可能なプロトコル管理装置。

（実施態様２）
プロトコル変換処理装置であって、通信回線上に存在し稼動状態にある情報処理装置に対し、プロトコル変換処理装置が変換処理を実行する被変換通信プロトコルを該情報処理装置が利用しているか否か判断する手段と、プロトコル変換処理装置が変換処理を実行する通信プロトコルを該情報処理装置が使用しているか否かを判断する手段を備え、該情報処理装置が被変換通信プロトコルおよび通信プロトコルの双方を使用している場合は、プロトコル変換処理が不要であると判断し、プロトコル変換処理を実行しない機能を有するプロトコル変換処理装置。

（実施態様３）
実施態様１のプロトコル変換処理装置であって、通信回線上に存在し稼動状態にある情報処理装置に対し、プロトコル変換処理装置が変換処理を実行する被変換通信プロトコルを該情報処理装置が利用しているか否か判断する手段と、プロトコル変換処理装置が変換処理を実行する通信プロトコルを該情報処理装置が使用しているか否かを判断する手段を備え、該情報処理装置が被変換通信プロトコルを使用している場合は、プロトコル変換処理が必要であると判断し、プロトコル変換処理を実行する機能を有するプロトコル変換処理装置。

（実施態様４）
実施態様１のプロトコル変換処理装置であって、被変換通信プロトコルで規定されるディスカバリリクエストを発行する手段と、該発行に対し応答した情報処理装置に付加された識別情報を取得し記憶する手段と、変換通信プロトコルで規定されるディスカバリリクエストを発行する手段、該発行に対し応答した情報処理装置に付加された識別情報を取得、記憶する手段とを備え、双方の記憶手段に記憶された内容を比較する手段を備え、双方の記憶手段に同一の識別情報を発見した場合、該識別情報が付加された情報処理装置に対してはプロトコル変換処理が不要であると判断し、プロトコル変換処理を実行しない機能を有するプロトコル変換処理装置。

（実施態様５）
実施態様１のプロトコル変換処理装置であって、被変換通信プロトコルで規定されるディスカバリリクエストを発行する手段と、該発行に対し応答した情報処理装置に付加された識別情報を取得し記憶する手段と、変換通信プロトコルで規定されるディスカバリリクエストを発行する手段、該発行に対し応答した情報処理装置に付加された識別情報を取得、記憶する手段とを備え、双方の記憶手段に記憶された内容を比較する手段を備え、前者の記憶手段には記憶されながら、後者の記憶手段には記憶されていない識別情報を発見した場合、該識別情報が付加された情報処理装置に対してはプロトコル変換処理が必要であると判断し、プロトコル変換処理を実行する機能を有するプロトコル変換処理装置。

（実施態様６）
互換性の無い通信プロトコルを使用する情報処理装置が複数稼動する通信回線において、情報処理装置に代行して通信プロトコルを他の通信プロトコルに変換することで、異なる通信プロトコルを使用する情報処理装置間の通信を可能ならしめる機能を有するプロトコル変換処理装置であって、
通信回線上に存在する同じプロトコル変換機能を有する他のプロトコル変換処理装置を発見し、発見したプロトコル変換処理装置から、該変換処理装置のステータス情報を取得し、該ステータス情報に応じて自動的にプロトコル変換処理を開始、あるいは待機する機能を有するプロトコル変換処理装置。

（実施態様７）
実施態様１のプロトコル変換処理装置であって、通信回線上に存在する同じプロトコル変換機能を有する他のプロトコル変換処理装置から通知されるステータス情報を取得し、該ステータス情報に応じて自動的にプロトコル変換処理を開始、あるいは待機する機能を有するプロトコル変換処理装置。

（実施態様８）
実施態様１のプロトコル変換装置であって、通信回線上に存在する同じプロトコル変換機能を有する他のプロトコル変換処理装置を発見し、発見したプロトコル変換処理装置から該変換処理装置の管理情報を取得し、該管理情報に記録された情報処理装置に対しては、プロトコル変換処理を実施しない機能を有するプロトコル変換処理装置。

（実施態様９）
実施態様１のプロトコル変換処理装置であって、通信回線上に存在する同じプロトコル変換機能を有する他のプロトコル変換処理装置から通知される装置情報を取得し、該装置情報に記載されたアドレスから管理情報を取得する手段を有し、該管理情報に記録された情報処理装置に対しては、プロトコル変換処理を実施しない機能を有するプロトコル変換処理装置。

（実施態様１０）
実施態様１のプロトコル変換処理装置であって、プロトコル変換処理の実行状態を管理する手段を有し、通信回線上に存在する他のプロトコル変換装置から発行された要求に応じて実行状態を通知する機能を有するプロトコル変換装置。

（実施態様１１）
実施態様１のプロトコル変換処理装置であって、プロトコル変換処理の実行状態を管理する手段を有し、該実行状態が変化した場合、通信回線上に存在する他のプロトコル変換装置に対し実行状態を通知する機能を有するプロトコル変換装置。

（実施態様１２）
実施態様１のプロトコル変換処理装置であって、代行してプロトコル変換を実施している情報処理装置の情報を管理情報として記録する手段を有するプロトコル変換装置。

（実施態様１３）
実施態様１のプロトコル変換装置であって、代行してプロトコル変換を実施している情報処理装置の総数ｎと、代行してプロトコル変換することが可能な総情報処理装置数ｍとを比較する機能を有し、ｎ＜ｍが成立する場合と、ｎ＝ｍが成立する場合とで異なるステータスとなる機能を有するプロトコル変換処理装置。

（実施態様１４）
実施態様１のプロトコル変換処理装置であって、代行してプロトコル変換を実施している情報処理装置の総数ｎと、代行してプロトコル変換することが可能な総情報処理装置数ｍとを比較する機能を有し、ｎ＝ｍが成立した時点において、通信回線上に存在する他のプロトコル変換装置に対しステータスが変化したことを知する機能を有するプロトコル変換装置。

（実施態様１５）
プロトコル変換処理装置であって、代行してプロトコル変換を実施している情報処理装置の総数ｎと、代行してプロトコル変換することが可能な総情報処理装置数ｍとを比較する機能を有し、ｎ＝ｍが成立した時点において、管理情報に登録された情報処理装置に対してのみプロトコル変換処理を実施する機能を有するプロトコル変換処理装置。

（実施態様１６）
プロトコル変換処理装置であって、代行してプロトコル変換を実施している情報処理装置の総数ｎと、代行してプロトコル変換することが可能な総情報処理装置数ｍとを比較する機能を有し、ｎ＝ｍが成立した場合、通信回線上に存在する同じプロトコル変換機能を有する他のプロトコル変換処理装置からの管理情報取得要求に応じる機能を有するプロトコル変換処理装置。

（実施態様１７）
プロトコル変換処理装置であって、代行してプロトコル変換を実施している情報処理装置の総数ｎと、代行してプロトコル変換することが可能な総情報処理装置数ｍとを比較する機能を有し、ｎ＝ｍが成立した場合、通信回線上に存在する同じプロトコル変換機能を有する他のプロトコル変換処理装置からの管理情報取得要求のうち、最初に受信した取得要求にのみ応じる機能と、それ以降受信した管理情報取得要求に対しては応じない機能を有するプロトコル変換処理装置。

（実施態様１８）
実施態様８のプロトコル変換処理装置であって、代行してプロトコル変換を実施している情報処理装置の総数ｎと、代行してプロトコル変換することが可能な総情報処理装置数ｍとを比較する機能を有し、ｎ＜ｍが成立する場合、通信回線上に存在する同じプロトコル変換機能を有する他のプロトコル変換処理装置からのステータス取得要求に応じる機能を有するプロトコル変換処理装置。

（実施態様１９）
プロトコル変換処理装置であって、代行してプロトコル変換を実施している情報処理装置の総数ｎと、代行してプロトコル変換することが可能な総情報処理装置数ｍとを比較する機能を有し、ｎ＜ｍが成立する場合、通信回線上に存在する同じプロトコル変換機能を有する他のプロトコル変換処理装置からのステータス取得要求に応じる機能を有するプロトコル変換処理装置。

（実施態様２０）
プロトコル変換処理装置であって、通信回線上に存在する同じプロトコル変換機能を有する他のプロトコル変換処理装置から取得したステータスがｎ＜ｍであるプロトコル変換処理装置を発見した場合、プロトコル変換処理を待機する機能を有するプロトコル変換処理装置。

（実施態様２１）
プロトコル変換処理装置であって、該プロトコル変換処理装置によって生成されるスクリプトは、通信回線上に存在し稼動状態にある情報処理装置が保持するデータを選択する制御手段と、該データを加工するための属性情報を指示する制御手段、および該データおよびデータを加工するための属性情報をプロトコル変換処理装置に対し送信する機能を有し、該スクリプトは請求項２のプロトコル変換処理装置によって生成されるハイパーテキストにより、その起動手順が記述されることを特徴とするプロトコル変換処理装置。

（実施態様２２）
プロトコル変換処理装置であって、該プロトコル変換処理装置によって生成されるハイパーテキストにプロファイル情報を記述した情報処理装置が処理可能なデータ情報を取得する手段を有し、該情報をスクリプトを実行した情報処理装置から送信されたデータと比較する手段を備え、処理可能なデータと判断した場合、スクリプトを実行した情報処理装置から送信されたデータを、ハイパーテキストにプロファイル情報を記述した情報処理装置に対し送信する機能を備え、
処理不能なデータと判断した場合、スクリプトを実行した情報処理装置から送信されたデータを、該プロトコル変換処理装置で処理可能なデータに変換した後に、ハイパーテキストにプロファイル情報を記述した情報処理装置に対し送信する機能を備えたプロトコル変換処理装置。

（実施態様２３）
プロトコル変換処理装置であって、該プロトコル変換処理装置によって生成されるスクリプトは汎用Ｗｅｂブラウザで実行可能なスクリプトであり、該プロトコル変換処理装置によって生成されるハイパーテキストは汎用Ｗｅｂブラウザで表示可能なハイパーテキストであることを特徴とするプロトコル変換処理装置。

以上説明したように、本発明によればプロトコル変換処理装置が、通信回線上に存在し稼動状態にある情報処理装置に対し、該情報処理装置が使用する通信プロトコルを他の通信プロトコルへの変換処理が必要であるか否かを判断する手段を備え、必要であると判断した場合には該情報処理装置に対し、プロトコル変換処理を実行する機能を備えることで、プロトコル変換処理装置が提供する通信プロトコルに対応している情報処理装置に対してプロトコル変換処理を実施することを回避することが可能となる。

また、これら処理は本発明を適用したプロトコル変換処理装置が自動的に処理するものであり、ネットワーク管理者を含むネットワーク上の情報処理装置を使用するユーザーが特別な設定、制御等関与することなく、プロトコル変換処理装置が備える変換能力を最大限利用することが可能となる。

本発明の一実施形態としてのプロトコル変換システムを構成するクライアント、プロキシサーバー、およびネットワーク対応プリンタの各機能構成を示す図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法を示す全体フローチャート図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法のうち、ＵＰｎＰ対応プリンタ検索のプロセスを示すフローチャート図である。 Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１で規定されるＭ−ＳＥＡＲＣＨディスカバリパケットのフォーマットを示す図である。 Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖ１で規定されるＭ−ＳＥＡＲＣＨディスカバリパケットに対するレスポンスパケットフォーマットを示す図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法のうち、プリンタ情報取得のプロセスを示すフローチャート図である。 管理テーブルのフォーマットを示す図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法のうち、プロトコル変換処理のプロセスを示すフローチャート図である。 本発明の一実施形態としてのプロトコル変換システムを構成するクライアント、プロキシサーバー、およびネットワーク対応プリンタの各機能構成を示す図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法を示す全体フローチャート図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法のうち、プリンタ情報取得のプロセスを示すフローチャート図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法のうち、プロトコル変換処理のプロセスを示すフローチャート図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法のうち、Ｎｏｔｉｆｙパケット処理のプロセスを示すフローチャート図である。 Ｎｏｔｉｆｙ ｓｔａｔｕｓ＝ＷａｋｅＵＰのパケットフォーマットを示す図である。 Ｎｏｔｉｆｙ レスポンスパケットｓｔａｔｕｓ＝ＦＵＬＬのパケットフォーマットを示す図である。 本発明の一実施形態としてのプロトコル変換システムを構成するクライアント、プロキシサーバー、およびネットワーク対応プリンタの各機能構成を示す図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法を示す全体フローチャート図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法のうち、ＵＰｎＰ対応プリンタ情報取得のプロセスを示すフローチャート図である。 管理テーブルのフォーマットを示す図である。 本発明におけるプロトコル変換システムのプロトコル変換処理方法のうち、プロトコル変換処理のプロセスを示すフローチャート図である。 本発明においてプロトコル変換装置が生成するプレゼンテーションドキュメントである。 本発明においてプロトコル変換装置が生成するプレゼンテーションドキュメントである。 Ｎｏｔｉｆｙ レスポンスパケットｓｔａｔｕｓ＝ＷＯＲＫＩＮＧのパケットフォーマットを示す図である。 Ｎｏｔｉｆｙ ｓｔａｔｕｓ＝ＦＵＬＬのパケットフォーマットを示す図である。 管理テーブルのフォーマットを示す図である。 Ｎｏｔｉｆｙ ｓｔａｔｕｓ＝ＢｙｅＢｙｅのパケットフォーマットを示す図である。

Claims (16)

1. 複数種類のプロトコルが混在するネットワークシステムにおいてプロトコル変換処理を行なう制御装置において、
   ネットワーク上に所定のプロトコル処理を行う他のプロトコル変換装置が存在しないか否かを、探索要求をネットワークにマルチキャストを行い起動時に探索する探索手段と、
   前記探索手段によって、ネットワーク上に他のプロトコル変換装置が探索された場合に、前記探索されたプロトコル変換装置が、プロトコル変換処理を行うことが可能か、又は、プロトコル変換処理を行っているかどうかを判定する判定手段と、
   前記判定手段が前記探索されたプロトコル変換装置がプロトコル変換処理を可能ではない、又は、プロトコル変換処理を行っていないと判定した場合に、プロトコル変換処理を起動する起動手段とを備えたことを有することを特徴とする制御装置。
2. 前記探索されたプロトコル変換装置がプロトコル変換処理を行なうことが可能であるか否かは、前記プロトコル変換装置が処理可能なプロトコル変換処理の数によって前記判定手段は判定することを特徴とする請求項１に記載の制御装置。
3. 前記判定手段が前記探索されたプロトコル変換装置がプロトコル変換処理を行なうことが可能であると判定した場合には、スリープモードに移行することを特徴とする請求項１又は２に記載の制御装置。
4. プロトコル変換処理対象のデバイスを管理する管理手段と、
   前記判定手段が前記探索されたプロトコル変換装置がプロトコル変換処理を行なうことが可能でないと判定した場合には、前記管理手段が管理するプロトコル処理対象のデバイス数が、予め設定された最大数を超えているか否かを判断する判断手段をさらに備え、
   前記判断手段が、前記管理手段が管理するプロトコル処理対象のデバイス数が、予め設定された最大数を超えていないと判断した場合に、前記起動手段は、前記プロトコル変換処理を起動することを特徴とする請求項１乃至３のいずれかに記載の制御装置。
5. 前記判断手段が、前記管理手段が管理するプロトコル処理対象のデバイス数が、予め設定された最大数を超えていると判断した場合には、ネットワークデバイスに対して、スリープモードに移行することを示すパケットをマルチキャストすることを特徴とする請求項４に記載の制御装置。
6. 複数種類のプロトコルが混在するネットワークシステムにおいてプロトコル変換処理を行う制御方法において、
   起動時に、ネットワーク上に所定のプロトコル処理を行う他のプロトコル変換装置が存在しないか否かを、探索要求に基づいて探索する探索工程と、
   前記探索工程によって、ネットワーク上に他のプロトコル変換装置が探索された場合に、前記探索されたプロトコル変換工程が、プロトコル変換処理を行うことが可能か、プロトコル変換処理を行っているかどうかを判定する判定工程と、
   前記判定工程が前記探索されたプロトコル変換装置がプロトコル変換処理を行なうことが可能ではない、又は、プロトコル変換処理を行っていないと判定した場合に、プロトコル変換処理を起動する起動工程とを備えたことを有することを特徴とする制御方法。
7. 前記探索されたプロトコル変換装置がプロトコル変換処理を行なうことが可能であるか否かは、前記プロトコル変換装置が処理可能なプロトコル変換処理の数によって前記判定工程にて判定ることを特徴とする請求項６に記載の制御装方法。
8. 前記判定工程が前記探索されたプロトコル変換装置がプロトコル変換処理を行なうことが可能であると判定した場合には、スリープモードに移行することを特徴とする請求項６又は７に記載の制御装置。
9. プロトコル変換処理対象のデバイスを管理する管理工程と、
   前記判定工程が前記探索されたプロトコル変換装置がプロトコル変換処理を行なうことが可能でないと判定した場合には、前記管理工程が管理するプロトコル処理対象のデバイス数が、予め設定された最大数を超えているか否かを判断する判断工程をさらに備え、
   前記判断工程が、前記管理工程が管理するプロトコル処理対象のデバイス数が、予め設定された最大数を超えていないと判断した場合に、前記起動工程は、前記プロトコル変換処理を起動することを特徴とする請求項６乃至８のいずれかに記載の制御装置。
10. 前記判断工程が、前記管理工程が管理するプロトコル処理対象のデバイス数が、予め設定された最大数を超えていると判断した場合には、ネットワークデバイスに対して、スリープモードに移行することを示すパケットをマルチキャストすることを特徴とする請求項９に記載の制御方法。
11. 複数種類のプロトコルが混在するネットワークシステムにおいてプロトコル変換処理を行う制御をコンピュータに実行させる制御プログラムにおいて、
    ネットワーク上に所定のプロトコル処理を行う他のプロトコル変換プログラムが存在しないか否かを、探索要求に基づいて起動時に探索する探索工程と、
    前記探索工程によって、ネットワーク上に他のプロトコル変換プログラムが探索された場合に、前記探索されたプロトコル変換装置が、プロトコル変換処理を行うことが可能かどうか、又は、プロトコル変換処理を行っているかどうかを判定する判定工程と、
    前記判定工程が前記探索されたプロトコル変換装置がプロトコル変換処理を行なうことが可能ではない、又は、プロトコル変換処理を行っていないと判定した場合に、プロトコル変換処理を起動する起動工程とをコンピュータに実行させることを特徴とする制御プログラム。
12. 複数のプロトコルを使用しているデバイスを対象にプロトコル変換制御を行う制御方法であって、
    第一のプロトコルを使用しているデバイスを探索する探索工程と、
    第二のプロトコルを、前記第一のプロトコルに従ってデバイスを通信させるべくプロトコル変換を行う変換工程と、
    前記探索工程が探索したデバイス前記第一のプロトコルに対応しているか否かを認識する認識工程と、
    前記探索工程が探索したデバイスが前記第一のプロトコルに対応しているとは前記認識工程が認識したデバイスに対しては、第一のプロトコルへのプロトコルの変換は行わないよう前記変換工程を制御する制御工程を備えることを特徴とする制御方法。
13. デバイスを探索する探索要求を取得する取得工程と、
    プロトコル変換対象のデバイスのリストを管理するテーブルを用いて管理する管理工程と、
    前記取得工程が取得した探索要求が探索するデバイスが、前記管理工程が管理するテーブルに登録されているか否かを判定する判定工程とをさらに備え、
    前記デバイスが前記管理工程が管理するテーブルに登録されていると前記判定工程が判定した場合には、前記第一のプロトコルに前記デバイスが対応していると前記認識工程が認識することを特徴とする請求項１２に記載の制御方法。
14. 複数のプロトコルを使用しているデバイスを対象にプロトコル変換制御を行う制御装置であって、
    第一のプロトコルを使用しているデバイスを探索する探索手段と、
    第二のプロトコルを、前記第一のプロトコルに従ってデバイスを通信させるべくプロトコル変換を行う変換手段と、
    前記探索手段が探索したデバイス前記第一のプロトコルに対応しているか否かを認識する認識手段と、
    前記探索手段が探索したデバイスが前記第一のプロトコルに対応しているとは前記認識手段が認識したデバイスに対しては、第一のプロトコルへのプロトコルの変換は行わないよう前記変換手段を制御する制御手段を備えることを特徴とする制御装置。
15. デバイスを探索する探索要求を取得する取得手段と、
    プロトコル変換対象のデバイスのリストを管理するテーブルを用いて管理する管理手段と、
    前記取得手段が取得した探索要求が探索するデバイスが、前記管理手段が管理するテーブルに登録されているか否かを判定する判定手段とをさらに備え、
    前記デバイスが前記管理手段が管理するテーブルに登録されていると前記判定手段が判定した場合には、前記第一のプロトコルに前記デバイスが対応していると前記認識手段が認識することを特徴とする請求項１４に記載の制御装置。
16. 複数のプロトコルを使用しているデバイスを対象にプロトコル変換制御を行う処理をコンピュータに実行させる制御プログラムであって、
    第一のプロトコルを使用しているデバイスを探索する探索工程と、
    第二のプロトコルを、前記第一のプロトコルに従ってデバイスを通信させるべくプロトコル変換を行う変換工程と、
    前記探索工程が探索したデバイス前記第一のプロトコルに対応しているか否かを認識する認識工程と、
    前記探索工程が探索したデバイスが前記第一のプロトコルに対応しているとは前記認識工程が認識したデバイスに対しては、第一のプロトコルへのプロトコルの変換は行わないよう前記変換工程を制御する制御工程をコンピュータに実行させることを特徴とする制御プログラム。

Images