JP2005309617A - ネットワークデバイス管理装置及びその制御方法、並びに、コンピュータプログラム及びコピー可読記憶媒体。 - Google Patents

Abstract

【課題】ネットワーク対応型プラグアンドプレイをサポートしないデバイスを、対応するデバイスとしてネットワーク上の他のデバイスに認識しさせ機能させる。
【解決手段】プロキシサーバ３００はネットワーク５００上に存在するプラグアンドプレイに非対応するプリンタ２００を探索し、それを記憶装置制御部１５を介してハードディスクに登録する。こうして登録するプリンタに対してはあたかもプラグアンドプレイのデバイスであるかのように振る舞うために、プラグアンドプレイのDeviceDEscriptionを作成する。ネットワークからプラグアンドプレイの探索メッセージを受信した場合には、プロキシサーバがプリンタに代わってＵＰｎＰデバイスであることを示すため、作成したDeviceDEscriptionを応答メッセージとして送信する。ネットワークから印刷ジョブデータを受信した場合には、その印刷装置用のプロトコルを変換し、その印刷装置にジョブデータを送信する。
【選択図】図１

Description

本発明は、ネットワークデバイスを管理する技術に関するものである。

特定の情報処理装置や、情報処理装置内で動作するオペレーションシステム（以下ＯＳと略す）、またそのＯＳ上で動作するアプリケーションに依存しないように、印刷装置はＰＤＬ(Page Description Langauage)などの独自の描画言語体系であるコマンドインターフェースを有している。

その描画言語体系は個々の印刷装置に依存する。よってその依存性をカプセル化するために、ＯＳは、標準的な描画インターフェースを入力とし、その印刷装置依存の描画言語体系のコマンドに変換し出力するプリンタドライバというモジュールを定義している。このプリンタドライバは、一般には、印刷装置の製造元やＯＳ開発者などによって作成され、情報処理装置内に格納される。

情報処理装置内に格納されるプリンタドライバは多数存在する。そのため情報処理装置に存在する全てのプリンタドライバをユーザに示すのは混乱の元である。つまり、ユーザの使用する印刷装置のみだけ効率的に結びつけ、ユーザが使用可能な状態にしたい。よってＯＳの初期状態ではプリンタドライバは情報処理装置内に格納されるだけであり、ユーザは特定の印刷装置にプリンタドライバを結びつける作業であるＯＳへのプリンタドライバのインストールを行う必要がある。

このインストール作業は従来ユーザが手動で行っていた。しかしユーザは煩雑な印刷装置ドラバのインストール作業を行う必要があり、また異なる描画言語体系のコマンドを、その描画体系をサポートしていない印刷装置に送った場合、印刷エラーとなるため、該当の印刷装置に対応したプリンタドライバを正しくインストールする必要があり、初心者には難しい作業であった。

この煩雑なインストール作業を軽減するために、米国セントロニクス社使用のパラレルインタフェースやＵＳＢ（Universal Serial Bus）インタフェースなどの通信媒介を用いて情報処理装置と印刷装置を接続するだけで、ユーザが操作を行わなくても自動的に情報処理装置と印刷装置で双方向通信を行い、その印刷装置に該当するドライバを情報処理装置にインストールする機能をＯＳに導入している。この機能をプラグアンドプレイと呼ぶ（特許文献１）。

上記プラグアンドプレイは直接的な一対一の接続であった。近年、ネットワークのインフラが整備されるに従い、ネットワーク対応型の印刷装置、スキャナ、複写機等のネットワーク周辺デバイスが急速に普及しつつある。ネットワーク上の各種サービスを提供するデバイスを、ネットワークを介して探索する技術が開発されつつある。例えば、このような技術には米国マイクロソフト社の提唱するＵｎｉｖｅｒｓａｌＰｌｕｇａｎｄＰｌａｙ（以下、ＵＰｎＰと略す）が存在する（特許文献２）。

これらのネットワーク対応型のネットワークデバイスとしての印刷装置を例にとると、事前に使用するクライアント、例えばパーソナルコンピュータ上に、そのクライアント上で稼動するオペレーティングシステム、例えばＷｉｎｄｏｗｓ（登録商標）によりデータベース上に登録管理された該当ドライバをインストールするか、あるいは、印刷装置ベンダからフレキシブルディスク、ＣＤ−ＲＯＭ等の記録媒体を介して提供されるドライバソフトウエア（ドライバ）をインストールした上で、印刷装置に割り当てられたＩＰアドレス、印刷装置ポート、使用するプリントプロトコル、デバイスドライバ等の印刷装置を動作させるための情報を把握する必要がある。

また、その印刷装置を他のネットワークへの移動したり、そのネットワークへの新規加入などにより、ネットワークシステムに接続されている装置の構成は刻々と変化しているすることを鑑み、ネットワーク上に存在する印刷装置を管理するためには、該印刷装置の情報を把握して管理する技術が開発されつつある。

しかし、ＵＰｎＰなどの既存の管理システムは、印刷装置とコンピュータを接続するための技術仕様であるが、機器同士が通信するためのプロトコルとデータフォーマットについて規定しているだけである。

従って、ＵＰｎＰなどの管理システムが管理している情報を用いたとしても、デバイスドライバなど、印刷装置を制御する制御プログラムをコンピュータにインストールするには、煩雑な設定が必要であるという問題は依然として存在する。

さらに、複数のネットワーク対応の印刷装置を管理する管理方式がネットワーク上に並存している場合、ある特定の管理方式に対応した管理システムからは、該特定の管理方式には対応していないネットワーク上の他の印刷装置を認識することができないという問題もある。

またユーザや各国市場の要求を満たすために、多種多様な印刷装置のための描画言語体系が作られ、市場に送り出されている。それぞれの描画言語体系のために印刷装置を一から開発するのは費用がかさむ。このコストを軽減するために各描画言語体系に依存する部分を拡張ボードやソフトウェアとして分離し、ユーザの要求や各国市場要求に応じて、印刷装置に、その拡張ボードやソフトウェアを搭載し直すことが可能な印刷装置が出てきた。

加えて、ユーザが好む描画言語体系が複数個存在する環境のために、一つの印刷装置で複数個の描画言語体系をサポートする印刷装置も登場している。

上記、描画言語体系が拡張ボードやソフトウェアによって変更可能な印刷装置や、複数個の描画言語体系がサポートする印刷装置は、プラグアンドプレイ搭載時には想定されていなかった。

またプラグアンドプレイは、ユーザの煩雑なインストール作業を軽減するために導入されたので、発見された一つの印刷装置に対して複数の描画言語体系からのPDLの選択などの、印刷装置に詳しくないユーザが混乱する選択作業を不要するユーザインターフェイスが望まれている。

上記２つの理由により、あるＯＳで搭載されているプラグアンドプレイでは、印刷装置から情報処理装置に受け渡される印刷装置の識別データ（DevicID）のうち、描画言語体系を示す情報を無視して、製造者名と印刷装置名でのみ、その印刷装置に該当するプリンタドライバを情報処理装置内から検索し、最初に発見したものをインストールする動作を行う。
特開２００３−２１６３７８公報 特開２００３−６１３３公報

以上、プラグアンドプレイについて説明したが、これには以下のような欠点がある。

第１には、例えば、印刷装置に拡張ボードを搭載することによりサポート描画体系を切り替え可能な印刷装置に、ＰＤＬ１、ＰＤＬ２という２つの描画言語体系（プリンタ言語インタプリタ）が搭載可能だが、ＰＤＬ１のみが実際に印刷装置に搭載されているものとする。また、そのプリンタドライバが既に情報処理装置に格納されているものとする。この場合プラグアンドプレイは、印刷装置から情報処理装置に受け渡される印刷装置の識別データのうち、描画言語体系を示す情報を無視して、製造者名と印刷装置名でのみ、その印刷装置に該当するプリンタドライバを情報処理装置から検索する。もしＰＤＬ２のプリンタドライバが先にプラグアンドプレイによって発見された場合、この印刷装置のためにＰＤＬ２がＯＳにインストールされてしまう。当然、ＰＤＬ１用の描画言語系を処理する拡張ボードは、ＰＤＬ２を認識しないので、印刷エラーとなってしまう。

第２には、複数個の描画言語体系をサポート可能な印刷装置の場合、製造元があまりお奨めできないエミュレーションのための描画体系用のプリンタドライバが先にプラグアンドプレイに発見されてしまい、他の効率的な描画体系があまり利用されないということが存在する。

本発明は、ネットワーク対応型プラグアンドプレイをサポートしないデバイスを、ネットワーク対応型プラグアンドプレイに対応するデバイスとしてネットワーク上の他のデバイスに認識しさせ、機能させる技術を提供しようとするものである。

この課題を解決するため、本発明の、例えばネットワークデバイス管理装置は以下の構成を備える。すなわち、
ネットワーク接続手段を有し、ネットワークに接続された複数の機能を備えたネットワークデバイスを管理するネットワークデバイス管理装置であって、
ネットワーク対応型プラグアンドプレイをサポートしていない、少なくとも１つのネットワークデバイスのネットワークアドレスと、当該ネットワークデバイスが備える複数の機能に関する機能情報とを記憶する記憶手段と、
前記ネットワーク接続手段を介して、ネットワーク対応型プラグアンドプレイのデバイスの所在確認要求があった場合、前記記憶手段に記憶された複数の機能情報が示す機能それぞれに対応した別個の複数の仮想ネットワーク対応型プラグアンドプレイデバイスとして、当該仮想ネットワーク対応型プラグアンドプレイデバイスを特定する識別情報を含むメッセージを生成し、応答する応答手段とを備える。

本発明によれば、本発明のネットワークデバイス管理装置が、ネットワーク上に存在するネットワーク対応型プラグアンドプレイをサポートしないデバイスを代理し、そのデバイスを仮想的にネットワーク対応型プラグアンドプレイに対応するデバイスとしてネットワーク上の他のデバイスに認識しさせ、機能させることが可能になる。

以下、添付図面に従って本発明に係る実施形態を詳細に説明する。

本発明に係るサービス提供システムの一実施形態としてのプロトコル変換システムについて説明する。

図１は本発明の一実施形態としてのプリントシステムの構成をソフトウェア面からみたブロック図である。

クライアント１００には、不図示の米国マイクロソフト社が提供するＯＳであるwindows（登録商標）や米国Ａｐｐｌｅ社が提供するＭａｃ ＯＳ（登録商標）等の汎用オペレーティングシステム、およびその上で実行可能な汎用アプリケーションがインストールされている。

上記汎用オペレーティングシステムは、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１０７を備え、そのプロトコルスタック上にＨＴＴＰ１０６を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行い、ＨＴＴＰ１０６上には、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部１０３を備え、ＵＰｎＰに関する通信手段を形成している。ＵＰｎＰのためのドライバ自動ダウンロード・設定モジュール部１０１は、ネットワーク上のＵＰｎＰ対応印刷装置および実施形態で述べる代理応答装置と通信を行うために、上記通信手段を用いることになる。

クライアント１００にＵＰｎＰで発見した印刷装置を表示し、ユーザに選択させるために、ドライバ自動ダウンロード・設定モジュール部１０１はＧＵＩ部１０２を利用する。

またＣｏｎｆｉｇｕｒａｔｏｒモジュール部（Ｃｏｎｆｉｇｕｒａｔｏｒ）１０４は、ネットワークを介して印刷装置より取得した情報に基づいて、予めハードディスクに格納された中から該当するプリンタドライバをＯＳに登録（インストール）する。

なお、イントール実行の際には、記憶装置制御部１０５を介してメモリスペースの有無、およびイントール先の管理制御を実行する。記憶装置制御部１０５は、後述するようにハードディスクドライブ（ＯＳ、各種アプリケーション、上記ソフトウェアモジュール、並びに各種アプリケーションで作成されたデータファイルが格納される）を制御するものである。

一方、本実施の形態ではネットワーク対応型印刷装置２００は、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック５を備え、そのプロトコルスタック上にＳｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）処理部６を備え、また、プロトコルスタック５上にはプリントプロトコル処理部７が実装され、クライアントから発行されるプリント要求を解析し、印刷装置コントローラ８に対し、そのプリント要求を送出する機能を備える。なお印刷装置２００は、複数のＰＤＬに対する印刷装置コントローラ８を同時に有することが出来る。また印刷装置コントローラ８を脱着可能にし、ユーザの要求に応じて差し替えて、印刷装置２００がサポートするＰＤＬを変更することも可能である。本実施形態では、ＰＤＬ１、ＰＤＬ２の２つのＰＤＬのための印刷装置コントローラ８ａ，８ｂが印刷装置２００内部に存在しているものとする。また、この印刷装置はＵＰｎＰプロトコル処理部を備えておらず、該印刷装置単独では、クライアント１００から発行されるＵＰｎＰプロトコルを使用したデバイス検索要求、およびＵＰｎＰ印刷ジョブ要求に対し応じることはできない。

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

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

ＨＴＴＰ１９の上位層にはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部２０を備え、ＵＰｎＰプロトコル処理部２１を備える。ネットワーク対応型印刷装置４００はＵＰｎＰ Ｆｏｒｕｍで策定されたＰｒｉｎｔＢａｓｉｃサービスを実装しており、ＵＰｎＰプロトコル処理部は該サービスで定義されたプリントジョブ、および属性情報を解析し、印刷装置コントローラ２２に対し、そのプリント要求を送出する機能を備える。印刷装置４００は、複数のＰＤＬに対する印刷装置コントローラ２２を同時に有することが出来る。また印刷装置コントローラ２２を脱着可能にし、ユーザの要求に応じて差し替えて、印刷装置４００がサポートするＰＤＬを変更することも可能である。本実施形態におけるこの印刷装置４００は、ＰＤＬ１、ＰＤＬ３の２つのＰＤＬのための印刷装置コントローラ２２ａ、２２ｂを搭載しているものとする。

実施形態における特徴となるネットワークデバイス管理装置として機能するプロキシサーバ（代理サーバ）３００も同様で、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック９を備え、そのプロトコルスタック上にＨＴＴＰ１０を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。

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

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

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

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

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

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

以上は、各装置のプリントに関する実装されるコンピュータプログラムの構成であるが、クライアント１００、プロキシサーバ３００は、通常のパーソナルコンピュータ等の汎用情報処理装置で実現できる。ハードウェアとしての構成は例えば図１１のようになる。

図示において、１００１は装置全体の制御を司るＣＰＵであり、１００２はＢＩＯＳやブートプログラムを記憶するＲＯＭである。１０３はＣＰＵ１００１のワークエリアとして使用されるＲＡＭである。１００４はハードディスク装置であって、ここにはＯＳ、アプリケーションや各種プログラム、並びに、データファイル等が格納される。１００５はネットワークインタフェースであり、実施形態ではイーサネット(登録商標)カードとするが、無線ＬＡＮカードでも構わない。１００６は表示制御部であり、ビデオメモリ及びＣＰＵ１００１の制御により描画を行うと共にビデオメモリに記憶された画像データをビデオ信号として出力するビデオコントローラが内蔵される。１００７は表示装置であって、液晶表示器やＣＲＴに代表されるものである。１００８はキーボードやマウス等の入力装置である。

上記構成において、装置の電源がＯＮになると、ＣＰＵ１００１はＲＯＭ１００２のブートプログラムに従って、ハードディスク１００４からＯＳをＲＡＭ１００２にロードし、各種デバイスドライバをロードすることになる。図１１の装置が上記クライアント１００であるとするなら、図１に示す構成に該当するプログラムをＲＡＭ１００２にロードし、実行することになる。これはプロキシサーバ３００でも同様である。プロキシサーバ３００の場合には、ＯＳがロードされた後、図１に示す構成に該当するプログラムをＲＡＭ１００２にロードし、且つ、後述する処理を行うことになる。

図１２は、ネットワークプリンタのブロック構成図である。図示において、２００１はプリンタ全体の制御を司るＣＰＵであり、２００２はＣＰＵ２００１が実行する印刷処理プログラムやフォントデータを格納するＲＯＭである。２００３はＣＰＵ２００１のワークエリア、受信バッファ、画像描画に使用されるＲＡＭであり、２００４は各種スイッチやボタン、並びに、メッセージ表示用の液晶表示部で構成される操作パネルである。２００５はネットワークに接続するためのネットワークインタフェース、２００６はレンダリング部、２００７は実際に記録紙に印刷を行うプリンタエンジンである。

図１における印刷装置２００、４００はハードウェアを巨視的に見た場合の構成は図１２のようになる。図１の印刷装置２００、４００の構成の違いは、ＲＯＭ２００２に格納されるファームウェアの違いであると言える。場合によっては、各種拡張ボードによる違いであると見ることも可能である。

以上の構成の元、実施形態におけるシステムの制御の流れを図２フローチャートに従い説明する。

図２は、実施形態におけるプロキシサーバ３００の処理手順を示すフローチャートである。このフローチャートに示す処理は、プロキシサーバ３００の電源がＯＮになってＯＳが起動した後に、ハードディスク１００４からＲＡＭ１００３にロードされ実行されるサーバアプリケーションでもある。

プロキシサーバ３００のプロトコル変換処理部１６は起動後、記録装置制御部１５を介し、ハードディスク１００４内に予め確保された、プロトコル変換処理を実施しているネットワークデバイス情報を記録する管理テーブルの内容をクリアする（ステップＳ２−１）。該管理テーブルの詳細に関しては以下のプロセスで説明する。

次にネットワークに参加しサービスを開始するにあたり、同ネットワーク上に存在するＵＰｎＰ対応印刷装置を検索する（ステップＳ２−２）。この探索処理は図３に示し、以下に説明する。

先ず、ステップＳ３−１にて、マルチキャストアドレスに対し、ＵＰｎＰで規定される図４に示すフォーマットのProbeパケットを発行する。つまり、ネットワーク上に参加し、ＵＰｎＰ対応のネットワークデバイスの所在を取得するメッセージを送信する。なお、図４中のパケットメッセージ中のｕｕｉｄ（Universally Unique Identifier）は、ＵＰｎＰデバイスに固有の識別子であって、プロキシサーバ３００があたかもＵＰｎＰデバイスとして機能することを示すためのものでもある（予め設定されて、保持されている）。 プロキシサーバ３００のプロトコル変換処理部１６は、図４に示すProbeパケットを発行した後、予め規定された所定時間内に、ネットワークからの全レスポンスに対し解析を実行する。

実施形態の場合、ネットワーク５００上の印刷装置４００は、ＵＰｎＰ対応印刷装置であるものとしているので、上記プロキシサーバ３００からのProbeパケットに対するレスポンスメッセージをプロキシサーバ３００に応答することになるが、印刷装置２００は非ＵＰｎＰであるので、応答しないことになる。

図５は、ネットワークデバイスの一例としてのＵＰｎＰ対応印刷装置４００からのレスポンスパケットであるProbeMatchの例を示している。プロキシサーバ３００のプロトコル変換処理部１６は、このパケットを渡してきたネットワーク印刷装置（ＵＰｎＰ対応印刷装置４００）へのＵＲＬを、記録装置制御部１５を介して、該制御部が制御する記録装置（実施形態ではハードディスク）に対し記録保存する。該処理は受信した全レスポンスパケットに対して実施され、プロキシサーバ３００は、ネットワーク上に存在する全てのＵＰｎＰ対応印刷装置のＵＲＬを記録することになる（ステップＳ３−２）。

以上のプロセスが完了した場合、ステップＳ３−３において応答が無い場合、プロキシサーバ３００のプロトコル変換処理部１６は、ＵＰｎＰ検索処理を終了して、図２のステップＳ２−３に処理を進め、印刷装置情報の取得処理を開始する。

ここで、ＵＰｎＰ対応印刷装置は、Probeパケットに対してその印刷装置がサポートするＰＤＬ毎に１つのProbeMatchフォーマットの応答を返す。図５に示すように、ＵＰｎＰ対応印刷装置４００は、印刷装置コントローラ２２ａ, ２２ｂのために同一のＵＲＬを有する２つのProbeMatchパケットを発行する。それぞれのProbeMatchパケットは、それぞれのサービスを一意に指定可能なように＜Address＞タグ内にユニークなuuidを有する。

図５の例では、それぞれＰＤＬに対するのｕｕｉｄは、PDL1では uuid:98190dc2-0890-4ef8-ac9a-5940995e611a、PDL3ではuuid:98190dc2-0890-4ef8-ac9a-5940995e611bである。

図６は、図２のステップＳ２−３の印刷装置情報取得の処理の詳細を示すフローチャートである。

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

ステップＳ６−１−１では、レスポンスを受信したかどうかを判定し、レスポンスがあった判定した場合にはステップＳ６−２へ、レスポンスが無かったと判断した場合にはステップＳ６−９へ進む。

各ネットワーク対応印刷装置からレスポンスを受け取ったプロキシサーバ３００のプロトコル変換処理部１６は、各レスポンス内容を記録装置に既に登録済みの印刷装置管理テーブルの内容と比較し（ステップＳ６−２）、既にプロトコル変換を実施している印刷装置か否かを判断する（ステップＳ６−３）。この判定は、ｕｕｉｄもしくはＩＰアドレスを照合することで判定する。

ステップＳ６−３では、プロトコル変換を実施していない印刷装置、即ち、新規に発見された印刷装置であるか否かを判断する。新規発見の印刷装置である場合には、プロキシサーバ３００のプロトコル変換処理部１６は、該印刷装置がＵＰｎＰ対応する印刷装置であるか否を、先に記録装置に記録したＵＰｎＰ対応印刷装置のＵＲＬLと比較することで判定処理を行なう（ステップＳ６−４）。

つまり、ＳＮＭＰ ＧＥＴリクエストのレスポンスとして取得した印刷装置ＩＰアドレスと、記録装置に記録されたＵＲＬが一致する場合、図２のステップＳ２−２の探索処理に対して応答し、且つ、ステップＳ６−１に対しても応答した場合、その印刷装置はＵＰｎＰ対応印刷装置であると判断し、該印刷装置に対してはプロトコル変換を実施しない。つまり、管理テーブルには登録しない。

換言すれば、図２のステップＳ２−２の探索処理に対して応答せず、ステップＳ６−１に対して応答した印刷装置は、非ＵＰｎＰ対応印刷装置であると判断することになる。この場合、ステップＳ６−６に進んで、記録装置制御部１５を介してハードディスクに確保された管理テーブルに追加登録する。

この場合、実施形態では、ＳＮＭＰＧＥＴリクエストのレスポンスとして取得した情報の印刷装置ベンダ・製品名称に対して検索をかけて、もしその印刷装置が複数言語のプリントコントローラを搭載可能または、脱着可能な印刷装置コントローラに対応しているモデルである場合、 ＳｕｐｐｏｒｔｅｄＰＤＬよりサポートしているＰＤＬを確認し、個々のＰＤＬをサポートするコントローラに対して、それぞれ論理的に別の印刷装置として、管理テーブルにＵＰｎＰ対応の印刷装置であるかのようにするため、PrinterDescriptionエレメントを追加する。

実施形態のシステム構成の場合、印刷装置２００が非ＵＰｎＰ印刷装置であり、図７に示すように、印刷装置コントローラ８ａ，８ｂに対して、論理的な別の印刷装置として印刷装置管理テーブルにPrinterDescriptionエレメントが２つ追加登録される。図７に示す情報は、クライアントからのProbeパケットや所定の探索パケットに応じて、プロキシサーバ３００がネットワーク上に、送出する。図７に示すパケットは、プリンタ８ａ用のデバイスＩＤ,プリンタ８ｂ用のデバイスＩＤとして、分割して、又は、ひとまとまりにして、別個のデバイスＩＤとして認識可能な形態で、クライアント側で受信される。そして、それぞれのデバイスＩＤごとに、プラグアンドプレイが実行することになる。つまり、プリンタ８ａ用のデバイスＩＤをクライアント側のインストーラが取得することにより、ＰＤＬ１をインストールし、プリンタ８ｂ用のデバイスＩＤをクライアント側のインストーラが取得することにより、別のＰＤＬ２のドライバがインストールされる。また、クライアントが、該デバイスの探索要求を発行した場合は、一つのデバイスではなく、複数の論理的な装置として表示されることになる。どのプリンタドライバをインストールするかは、予めクライアント側の、デバイスＩＤとドライバの格納位置を示す情報の組を示すデータベースを引くことにより決定される。例えば、クライアントがプロキシサーバ３００から取得したプリンタ８a用のデバイスＩＤのうち、MANUFACTURED、MODELの組をクライアント側のインストーラが認識すると、当該８a用のMANUFACTURED、MODELの組をキーにしてデータベースを引いて、プリンタドライバの格納位置を認識して、インストールを行う。別の実施形としては、８a用のプリンタドライバ部MANUFACTURED、COMMAND,MODELの全ての組を認識し、MANUFACTURED、MODELに対応する複数のデバイスドライバの中から、ＰＤＬ１用のデバイスドライバを自動的に認識してインストールしても良い。

PrinterDescriptionエレメントのDeviceIDとして、クライアント１００に格納されているそれぞれのＰＤＬに対応するプリンタドライバを一意に指定できるデバイスＩＤ（図示の場合には、「LaserBeamPrinter777 PDL1」及び「LaserBeamPrinter777 PDL2」の２つ）をプロトコル変換処理部１６は、ここのPrinterDescriptionエレメントに登録する。またそれぞれの論理印刷装置をＵＰｎＰパケットで指定可能なように、＜Address＞タグ内に異なるuuidを持つように登録する。

以上の情報を、記録装置制御部１５を介してハードディスクに記録し（ステップＳ６−７）、ステップＳ６−８においてＵＰｎＰプロトコル処理部１４より、管理テーブルに記録された全ての印刷装置に関するＨｅｌｌｏパケットを発行し、あたかも２つのＵＰｎＰ印刷装置（仮想的ＵＰｎＰ印刷装置が２つ）がそのサービスを開始していることをネットワーク上に通知する。

一方、プロキシサーバ３００より発行されたＳＮＭＰＧｅｔ要求に対し、何のレスポンスが得られなかった場合、つまり、ステップＳ６−１−１がＮｏと判定された場合、処理はステップＳ６−９へ進み、管理テーブルを検索し、登録済み印刷装置を確認する。

そして、既に管理テーブルに登録ずみの印刷装置がありながら、レスポンスが得られなかった印刷装置があるか否かを判断する（ステップＳ６−９−１）。登録済みでレスポンスがなかった場合、該当する印刷装置は、電源がＯＦＦになった、もしくはネットワークから離脱したことを示す。この場合、ステップＳ６−１０に進み、プロキシサーバ３００のプロトコル変換処理部１６は管理テーブルより該印刷装置の情報の削除更新し、ステップＳ６−１１にて、該当する印刷装置のPrinterDescriptionエレメントを削除する。

そして、プロキシサーバ３００のプロトコル変換処理部１６は、ＵＰｎＰプロトコル処理部１４より、管理テーブルから削除された全ての印刷装置に関するByeパケットを発行し、これら管理テーブルから削除された印刷装置がネットワーク上でのサービスを停止したことを通知する（ステップＳ６−１２）。

次に、図２におけるプロトコル変換処理（ステップＳ２−５）の詳細を図８のフローチャートに従って説明する。

プロキシサーバ３００のプロトコル変換処理部１６、ネットワーク上のクライアントから発行されるデバイス検索プロトコルProbeパケットの受信通知をＵＰｎＰプロトコル処理部１４から受けか否かを判断する（ステップＳ８−１）。つまり、クライアントがネットワーク上のＵＰｎＰネットワークデバイスの探索を行っているか否かを判断する。

Probeパケットを受信したと判断した場合には、処理はステップＳ８−２に進み、プロキシサーバ３００のプロトコル変換処理部１６が管理する、図７に示す印刷装置管理テーブルを、記録装置制御部１５を介してハードディスクから検索する。そして、Probeパケットの検索条件に該当する印刷装置がその管理テーブルに登録されている場合、Probe Matchパケットを印刷装置管理テーブルより生成しＵＰｎＰプロトコル処理部１４を介して返送する。

Probe Matchパケットは図５のような構造をしており、Probeパケットの検索条件に該当するそれぞれの印刷装置コントローラに対して一つ発行される。またProbe Matchパケットは、そのＰＤＬに関する論理的な印刷装置を一意に指定できるように、＜Address＞タグにユニークなuuidをもつ。実施形態におけるプロキシサーバ３００は、管理テーブルに登録されている該当する印刷装置のすべてについて上記Probe Matchパケットを返答する。

この結果、上記のProbeパケットを送信したクライアントは、プロキシサーバ３００ＵＰｎＰ印刷装置（実施形態では、印刷装置２００が２つの言語のコントローラを有することになるので、２つのＵＰｎＰ印刷装置）であるかのように見えることになる。

処理がステップＳ８−３に進むと、ＵＰｎＰプロトコル処理部１４が図９に示すようなPrinterDescriptionRequestパケットを受信したか否かを判断する。このパケットを受信すると、プロキシサーバ３００は、プロトコル変換処理部１６が管理する印刷装置管理テーブルの＜Address＞タグを、PrinterDescriptionの取得要求中の＜To＞タグで示されるuuidで検索し、図１０に示すようなPrinterDescriptionReｓponseパケットを、印刷装置管理テーブルより生成する。そして、生成したPrinterDescriptionReｓponseパケットをＵＰｎＰプロトコル処理部１４を介して要求元に返送する（ステップＳ８−４）。

ステップＳ８−５では、上記のPrinterDescriptionReｓponseを取得したクライアントデバイスから、ＵＰｎＰによるプリントジョブ要求を受信したか否かを判断する。この要求のジョブコマンド、およびジョブ属性はＸＭＬの形式で記述されているので、そのままでは非ＵＰｎＰデバイスである印刷装置２００は解釈できない。そこで、プロキシサーバ３００のプロトコル変換処理部１６が、ＵＰｎＰプロトコル処理部１４を介して該プリントジョブを受信した場合（ステップＳ８−５がＹＥＳの場合）、プロトコル変換処理部１６はＳＯＡＰ処理部において該コマンド、およびジョブ属性を解析し、次に記録装置制御部１５を介して出力指定された印刷装置に該当する管理テーブル情報のうち、サポートするプリントプロトコル（図７の＜SupportedPrintProtocol＞〜＜／SupportedPrintProtocol＞で記述されたプロトコルで、図示の場合には「ＬＰＲ」となる）、およびＩＰアドレスを取得し、受信したコマンド、属性情報を該プリントプロトコルに変換する（ステップＳ８−６）。そして、出力指定された印刷装置のＩＰアドレスに向けて、変換後の情報を送信する（ステップＳ８−８）。

なお、クライアントからのプリントジョブには、印刷するべき印刷装置のｕｕｉｄ（プロキシサーバ３００が印刷装置２００のために作成したｕｕｉｄでもある）が含まれているので、これをキーにして、本来の印刷装置のＩＰアドレスを取得することができる。

プリントジョブを発行したクライアントは、引き続きジョブデータ（この場合ＰＤＬデータ）をＨＴＴＰ ＰＯＳＴコマンドを使用してプロキシサーバ３００に対し送信することになる。ステップＳ８−８−１では、このジョブデータを受信したか否かを判断する。

そして、この判断を、ステップＳ８−８−２で所定時間経過するまで行い、所定時間経過してもジョブデータを受信しない場合には、ステップＳ８−１０にてそのジョブ要求を破棄する。このとき、指定された印刷装置にも破棄要求を行う。

また、プリントジョブ要求を受信してから所定時間以内に、ジョブデータを受信した場合、プロキシサーバ３００のプロトコル変換処理部１６は、先のステップ同様に受信したジョブデータを指定された印刷装置がサポートするプリントプロトコルに変換し（ステップＳ８−８ー３）、先に取得した印刷装置ＩＰアドレスに対しジョブデータを送信する（ステップＳ８−９）。

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

なお、図２からもわかるように、プロキシサーバ３００は電源断の指示が成されない限り、以上のプロセス、すなわち、ステップＳ２−２乃至Ｓ２−４を繰り返し実行することで、定期的にネットワーク印刷装置の稼動状況を更新し、その更新情報に従いプロトコル変換処理を実行する。

そして、図２において、プロキシサーバ３００の電源断の指示が与えられたと判断した場合、処理はステップＳ２−５からステップＳ２−６に進む。この場合、プロキシサーバ３００のプロトコル変換処理部１６はプロトコル変換処理を停止するため、プロトコル変換処理部１６は、記録装置制御部１５を介して全ての管理テーブルを読み出し、管理テーブルに記録された全ての印刷装置に関するByeパケット（ＵＰｎＰネットワーク離脱メッセージ）を、ＵＰｎＰプロトコル処理部１４を介して発行し、これら印刷装置がネットワーク上でのサービスを停止したことネットワークの他のデバイス（クライアント）に通知する。

以上説明したように、本実施形態によると、プロキシサーバ３００は、ネットワーク上の非ＵＰｎＰ印刷装置プリンタを、ＳＮＭＰプロトコルを用いて検出し登録する。そして。その非ＵＰｎＰプリンタに代わってあたかもＵＰｎＰ印刷装置であるかのように振る舞い、印刷ジョブを受信した場合には、その印刷ジョブを、指定された非ＵＰｎＰ印刷装置に出力する。この結果、非ＵＰｎＰ印刷装置が、ＵＰｎＰネットワークのメンバとして機能することになる。

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

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

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

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

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

以上説明したように、ネットワーク対応型プラグアンドプレイをサポートしていない印刷装置に対して代理応答装置を設け、上記印刷装置がサポートしているネットワーク対応型プラグアンドプレイ以外のプロトコルで取得したデバイスIDのモデル名称がPDL名称の属性を持たない場合、ネットワーク対応型プラグアンドプレイの周辺装置検索プロトコルの応答として、PDL名称をモデル名に付加して返すことにより、適切なプリンタドライバを情報処理装置に自動インストールすることが可能である。

またネットワーク対応型プラグアンドプレイをサポートしていない印刷装置に対して代理応答装置を設け、上記印刷装置がサポートしているネットワーク対応型プラグアンドプレイ以外のプロトコルで取得したデバイスIDが複数個のPDLをサポートしている場合、PDLの個数分論理的な印刷装置と認識させるように、デバイスIDのモデル名称に、それぞれのPDL名称を付加したデバイスIDを含むネットワーク対応型プラグアンドプレイの周辺装置検索プロトコルへ応答を行うことにより、情報処理装置に別の論理的な実態であると認識させることが可能になる。

なお、実施形態で説明したように、本実施形態の主要部分はプロキシサーバ３００の処理にある。プロキシサーバ３００は、先に説明したように、ハードディスク等の記憶装置を必要とするものの、パーソナルコンピュータ等の汎用情報処理装置上で動さするサーバアプリケーションプログラムで実現しているわけであるから、本発明は、コンピュータプログラムをその範疇とするのは明らかである。また、通常、コンピュータプログラムは、ＣＤＲＯＭ等のコンピュータ可読記憶媒体をコンピュータにセットし、システムにコピーもしはインストールすることで実行可能になるわけであるから、当然、そのようなコンピュータ可読記憶媒体も本発明の範疇に含まれる。

実施形態におけるネットワークシステムを構成する各デバイスのソフトウェアの構成を示す図である。 実施形態におけるプロキシサーバの処理手順を示すフローチャートである。 ＵＰｎＰ対応印刷装置検索のプロセスを示すフローチャート図である。 Probeパケットの一例を示す図である。 ProbeパケットのレスポンスパケットであるProbe Matchパケットの一例を示す図である。 印刷装置情報取得のプロセスを示すフローチャート図である。 管理テーブルのフォーマットを示す図である。 プロトコル変換処理のプロセスを示すフローチャート図である。 PrinterDescriptionのRequestパケットの一例を示す図である。 PrinterDescriptionのResponseパケットの一例を示す図である。 実施形態におけるクライアント及びプロキシサーバのハードウェアブロック構成図である。 実施形態におけるプリンタ２００、４００のハードウェアブロック構成図である。

Claims (11)

1. ネットワーク接続手段を有し、ネットワークに接続された複数の機能を備えたネットワークデバイスを管理するネットワークデバイス管理装置であって、
   ネットワーク対応型プラグアンドプレイをサポートしていない、少なくとも１つのネットワークデバイスのネットワークアドレスと、当該ネットワークデバイスが備える複数の機能に関する機能情報とを記憶する記憶手段と、
   前記ネットワーク接続手段を介して、ネットワーク対応型プラグアンドプレイのデバイスの所在確認要求があった場合、前記記憶手段に記憶された複数の機能情報が示す機能それぞれに対応した別個の複数の仮想ネットワーク対応型プラグアンドプレイデバイスとして、当該仮想ネットワーク対応型プラグアンドプレイデバイスを特定する識別情報を含むメッセージを生成し、応答する応答手段と
   を備えることを特徴とするネットワークデバイス管理装置。
2. 前記記憶手段が記憶する機能情報には、記憶対象のネットワークデバイスと通信するためのプロトコル情報が含まれることを特徴とする請求項１に記載のネットワークデバイス管理装置。
3. 更に、前記ネットワーク接続手段を介して、仮想ネットワーク対応型プラグアンドプレイデバイス宛にジョブ情報を受信した場合、当該ジョブ情報中に記述された識別情報に基づき、前記記憶手段から該当するネットワークデバイスのアドレスとプロトコル情報を取得すると共に、前記ジョブ情報を取得したプロトコルに変換し、取得したアドレスに向けて送信する制御手段と
   を備えることを特徴とする請求項２に記載のネットワークデバイス管理装置。
4. 前記機能情報が示す機能とは、前記ネットワークデバイスが処理可能な印刷データを生成することができる複数種類のプリンタドライバの機能を含むことを特徴とする請求項１に記載のネットワークデバイス管理装置。
5. 更に、ネットワーク対応型プラグアンドプレイの非サポートのネットワークデバイスを探索する探索手段と、
   該探索手段で得られたネットワークデバイスのネットワークアドレス、及び、探索して得られたネットワークデバイスとの通信の際に用いるプロトコルを特定する情報を前記記憶手段に登録する登録手段と、
   登録したネットワークデバイスに代わって前記応答手段で応答する際のメッセージを作成する作成手段と
   を備えることを特徴とする請求項１に記載のネットワークデバイス管理装置。
6. 前記探索手段は、ＳＮＭＰプロトコルでの探索して検出されたネットワークデバイス群から、ＵＰｎＰネットワークプロトコルでの探索結果で検出されたネットワークデバイスを除外することで残ったネットワークデバイス群を、ネットワーク対応型プラグアンドプレイの非サポートのネットワークデバイス群とすることを特徴とする請求項５に記載のネットワークデバイス管理装置。
7. 前記ネットワークデバイスは、ネットワークプリンタとすることを特徴とする請求項１乃至６のいずれか１項に記載のネットワークデバイス管理装置。
8. 前記ネットワークデバイスが複数のプリンタ言語をサポートしている場合、前記応答手段は、個々のプリンタ言語毎に独立した論理的な仮想ネットワーク対応型プラグアンドプレイプリンタとして応答することを特徴とする請求項７に記載のネットワークデバイス管理装置。
9. ネットワーク接続手段と、ネットワーク対応型プラグアンドプレイをサポートしていない、少なくとも１つのネットワークデバイスのネットワークアドレスと当該ネットワークデバイスと通信するための際のプロトコル情報を記憶する記憶手段とを有し、ネットワークに接続されたネットワークデバイスを管理するネットワークデバイス管理装置の制御方法であって、
   前記ネットワーク接続手段を介して、ネットワーク対応型プラグアンドプレイのデバイスの所在確認要求があった場合、前記記憶手段に記憶された複数の機能情報が示す機能それぞれに対応した別個の複数の仮想ネットワーク対応型プラグアンドプレイデバイスとして、当該仮想ネットワーク対応型プラグアンドプレイデバイスを特定する識別情報を含むメッセージを生成し、応答する
   ことを特徴とするネットワークデバイス管理装置の制御方法。
10. ネットワーク接続手段と、ネットワーク対応型プラグアンドプレイをサポートしていない、少なくとも１つのネットワークデバイスのネットワークアドレスと当該ネットワークデバイスと通信するための際のプロトコル情報を記憶する記憶手段とを有し、ネットワークに接続されたネットワークデバイスを管理するネットワークデバイス管理装置として機能するコンピュータプログラムであって、
    前記ネットワーク接続手段を介して、ネットワーク対応型プラグアンドプレイのデバイスの所在確認要求があった場合、前記記憶手段に記憶された複数の機能情報が示す機能それぞれに対応した別個の複数の仮想ネットワーク対応型プラグアンドプレイデバイスとして、当該仮想ネットワーク対応型プラグアンドプレイデバイスを特定する識別情報を含むメッセージを生成し、応答する
    ことを特徴とするコンピュータプログラム。
11. 請求項１０に記載のコンピュータプログラムを格納したことを特徴とするコンピュータ可読記憶媒体。

Images