JP4765496B2 - ネットワーク型プラグアンドプレイに対応したネットワーク装置及びその制御方法 - Google Patents
ネットワーク型プラグアンドプレイに対応したネットワーク装置及びその制御方法 Download PDFInfo
- Publication number
- JP4765496B2 JP4765496B2 JP2005261979A JP2005261979A JP4765496B2 JP 4765496 B2 JP4765496 B2 JP 4765496B2 JP 2005261979 A JP2005261979 A JP 2005261979A JP 2005261979 A JP2005261979 A JP 2005261979A JP 4765496 B2 JP4765496 B2 JP 4765496B2
- Authority
- JP
- Japan
- Prior art keywords
- network
- message
- control unit
- upnp
- protocol
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Accessory Devices And Overall Control Thereof (AREA)
- Information Transfer Systems (AREA)
- Facsimiles In General (AREA)
Description
この発明は、ネットワーク型プラグアンドプレイに対応したネットワーク装置における制御技術に関する。
プラグアンドプレイは、よく知られているように、コンピュータの起動後に、周辺装置を任意のタイミングでコンピュータに接続したり、コンピュータから切断したりすることができる技術である。近年では、プラグアンドプレイ技術をネットワークに適用したものとして、ユニバーサルプラグアンドプレイ（以下、「ＵＰｎＰ」と呼ぶ。ＵＰｎＰは UPnP Implementers Corporationの商標）が開発されてきている。ＵＰｎＰを用いると、ネットワーク装置を任意のタイミングでネットワークに接続したり、ネットワークから切断したりすることができる。本明細書では、ＵＰｎＰのように、ネットワークにおいてプラグアンドプレイを実現するアーキテクチャを、「ネットワーク型プラグアンドプレイ」と呼ぶ。
ＵＰｎＰ対応のネットワーク装置は、種々のサービスデバイスとして機能することが可能である。ここで、「サービスデバイス」とは、外部からの要求に応じてサービスを実行するデバイスを意味している。サービスデバイスは、プリンタや、スキャナ、ファクシミリ、コピー機、記憶装置、カメラ、時計などの種々の装置として実現可能である。また、１つの装置で複数のサービスデバイスの機能を実現することも可能である。
このように、ＵＰｎＰ対応のネットワーク装置は多様な形態を採り得る。しかし、その反面、ネットワーク装置の実装が複雑になり易いという問題があった。
本発明は、ネットワーク型プラグアンドプレイに対応したネットワーク装置における実装を単純化することのできる技術を提供することを目的とする。
本発明による第１の装置は、ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
ネットワーク上のクライアントからの要求に応じてサービスを実行する複数のサービスデバイスと、
前記複数のサービスデバイスの制御を行うデバイス制御部と、
メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの内容を前記デバイス制御部に転送するネットワークプロトコル制御部と、
を備え、
前記複数のサービスデバイスは、第１のデバイスと、前記第１のデバイスとは種類の異なる第２のデバイスとを含んでおり、
前記ネットワークプロトコル制御部と前記デバイス制御部とは、前記第１のデバイスのデバイスクラス用の論理チャンネルと、前記第２のデバイスのデバイスクラス用の論理チャンネルと、を介してそれぞれ接続されており、
前記ネットワークプロトコル制御部は、
（ｉ）前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで受信したときに、前記第１のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送し、
（ｉｉ）前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで無いネットワークプロトコルで受信したときには、前記第２のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する。
ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
ネットワーク上のクライアントからの要求に応じてサービスを実行する複数のサービスデバイスと、
前記複数のサービスデバイスの制御を行うデバイス制御部と、
メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの内容を前記デバイス制御部に転送するネットワークプロトコル制御部と、
を備え、
前記複数のサービスデバイスは、第１のデバイスと、前記第１のデバイスとは種類の異なる第２のデバイスとを含んでおり、
前記ネットワークプロトコル制御部と前記デバイス制御部とは、前記第１のデバイスのデバイスクラス用の論理チャンネルと、前記第２のデバイスのデバイスクラス用の論理チャンネルと、を介してそれぞれ接続されており、
前記ネットワークプロトコル制御部は、
（ｉ）前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで受信したときに、前記第１のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送し、
（ｉｉ）前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで無いネットワークプロトコルで受信したときには、前記第２のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する。
この装置によれば、第２のデバイス宛のメッセージをネットワーク型プラグアンドプレイのプロトコルで受信したときに、第１のデバイスのデバイスクラス用の論理チャンネルを利用してメッセージボディの内容をデバイス制御部に転送することができる。従って、複数のクライアントから第２のデバイス宛のメッセージが送られてきた場合にも、パケットの構造を利用してそれぞれのメッセージを識別しつつデバイス制御部に転送することができる。この結果、第２のデバイス宛てのメッセージ転送に関して、ネットワーク型プラグアンドプレイに対応したネットワーク装置における実装を単純化することが可能である。また、第２のデバイス宛てのメッセージをネットワーク型プラグアンドプレイのプロトコルで無いネットワークプロトコルで受信したときには、第２のデバイスのデバイスクラス用の論理チャンネルを利用してメッセージボディの内容をデバイス制御部に転送するので、ネットワーク型プラグアンドプレイのプロトコルで受信したメッセージと、他のネットワークプロトコルで受信したメッセージとを並行してデバイス制御部に転送することが可能である。
本発明による第２の装置は、ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
ネットワーク上のクライアントからの要求に応じてサービスを実行する複数のサービスデバイスと、
前記複数のサービスデバイスの制御を行うデバイス制御部と、
メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの内容を前記デバイス制御部に転送するネットワークプロトコル制御部と、
を備え、
前記複数のサービスデバイスは、第１のデバイスと、前記第１のデバイスとは種類の異なる第２のデバイスとを含んでおり、
前記ネットワークプロトコル制御部と前記デバイス制御部とは、前記第１のデバイスのデバイスクラス用の論理チャンネルを介して接続されており、
前記第２のデバイス宛のメッセージの宛先のパス名は、前記第１のデバイスのデバイスクラス用の論理チャンネルを使用することを示す第１の部分と、最終的な宛先が前記第２のデバイスであることを示す第２の部分とを含み、
前記ネットワークプロトコル制御部は、前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで受信したときに、前記第１のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する。
ネットワーク上のクライアントからの要求に応じてサービスを実行する複数のサービスデバイスと、
前記複数のサービスデバイスの制御を行うデバイス制御部と、
メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの内容を前記デバイス制御部に転送するネットワークプロトコル制御部と、
を備え、
前記複数のサービスデバイスは、第１のデバイスと、前記第１のデバイスとは種類の異なる第２のデバイスとを含んでおり、
前記ネットワークプロトコル制御部と前記デバイス制御部とは、前記第１のデバイスのデバイスクラス用の論理チャンネルを介して接続されており、
前記第２のデバイス宛のメッセージの宛先のパス名は、前記第１のデバイスのデバイスクラス用の論理チャンネルを使用することを示す第１の部分と、最終的な宛先が前記第２のデバイスであることを示す第２の部分とを含み、
前記ネットワークプロトコル制御部は、前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで受信したときに、前記第１のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する。
この構成によれば、第２のデバイス宛のメッセージをネットワーク型プラグアンドプレイのプロトコルで受信したときに、第１のデバイスのデバイスクラス用の論理チャンネルを利用してメッセージボディの内容をデバイス制御部に転送することができる。従って、複数のクライアントから第２のデバイス宛のメッセージが送られてきた場合にも、パケットの構造を利用してそれぞれのメッセージを識別しつつデバイス制御部に転送することができる。この結果、第２のデバイス宛てのメッセージ転送に関して、ネットワーク型プラグアンドプレイに対応したネットワーク装置における実装を単純化することが可能である。また、前記第１のデバイスのデバイスクラス用の論理チャンネルを使用することと、最終的な宛先が前記第２のデバイスであることを、容易に判定することが可能である。
なお、上記第１の装置においても、前記第２のデバイス宛のメッセージの宛先のパス名は、前記第１のデバイスのデバイスクラス用の論理チャンネルを使用することを示す第１の部分と、最終的な宛先が前記第２のデバイスであることを示す第２の部分とを含むものとしてもよい。
この構成によれば、前記第１のデバイス用の論理チャンネルを使用することと、最終的な宛先が前記第２のデバイスであることを、容易に判定することが可能である。
前記ネットワーク制御部と前記デバイス制御部との間はＵＳＢで接続されており、
前記第１のデバイスは、プリンタデバイスであるとしてもよい。
前記第１のデバイスは、プリンタデバイスであるとしてもよい。
この構成によれば、ＵＳＢ接続におけるプリンタデバイス用の論理チャンネルとして、パケット化された論理パケットを容易に構成することが可能である。
なお、本発明は、種々の形態で実現することが可能であり、例えば、ネットワーク装置、ネットワークプロトコル制御装置、それらの装置の制御方法及び制御装置、それらの方法または装置の機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体、そのコンピュータプログラムを含み搬送波内に具現化されたデータ信号、等の形態で実現することができる。
次に、本発明の実施の形態を以下の順序で説明する。
A．用語の説明：
B．システムの概要：
C．複合機のデバイス構成及びデバイスディスクリプション：
D．プリンタデバイス以外のサービスデバイスへのデータ転送シーケンス：
E．変形例：
A．用語の説明：
B．システムの概要：
C．複合機のデバイス構成及びデバイスディスクリプション：
D．プリンタデバイス以外のサービスデバイスへのデータ転送シーケンス：
E．変形例：
A．用語の説明：
以下の説明で使用する用語の意味は以下の通りである。
・ＤＨＣＰ（Dynamic Host Configuration Protocol）：ダイナミックホストコンフィギュレーションプロトコル。動的にＩＰアドレスを割り当てるプロトコル。
・ＧＥＮＡ（General Event Notification Architecture）：一般イベント通知アーキテクチャ。ＵＰｎＰアーキテクチャにおいてイベントを発行する際に使用される。
・ＨＴＴＰ（HyperText Transfer Protocol）：ハイパーテキスト転送プロトコル。
・ＨＴＴＰＭＵ（HTTP Multicast over UDP）：ＵＤＰ（User Datagram Protocol）を用いたＨＴＴＰマルチキャスト。
・ＨＴＴＰＵ（HTTP(unicast) over UDP）：ＵＤＰを用いたＨＴＴＰユニキャスト。
・ＭＦＰ（Multi Function Peripheral）：複数のデバイスの機能を有する複合周辺装置。
・ＳＯＡＰ（Simple Object Access Protocol）：シンプルオブジェクトアクセスプロトコル。ＵＰｎＰアーキテクチャにおいて、ＲＰＣ（リモートプロシージャコール）によるアクションの要求とレスポンスとに使用される。
・ＳＳＤＰ（Simple Service Discovery Protocol）：シンプルサービス検出プロトコル。ＵＰｎＰアーキテクチャにおいて、サービスのディスカバリ（検出）に使用される。
・ＵＰｎＰ（Universal Plug and Play）：ユニバーサルプラグアンドプレイ（ＵＰｎＰは UPnP Implementers Corporationの商標）。
・ＵＲＩ（Uniform Resource Identifier）：ユニフォームリソース識別子。ＵＲＬ（Uniform Resouce Locator）の上位概念であり、リソースの固有の位置を示す識別子。
・ＸＨＴＭＬ（eXtensible HyperText Markup Language）：拡張ハイパーテキストマークアップ言語。ＨＴＭＬと互換性を有する文書記述言語の一種であり、ＸＭＬの実装の一形態である。後述するＸＨＴＭＬ−ｐｒｉｎｔは、ＸＨＴＭＬ文書を印刷するための仕様である。
・ＸＭＬ（eXtensible Markup Language）：拡張マークアップ言語。
以下の説明で使用する用語の意味は以下の通りである。
・ＤＨＣＰ（Dynamic Host Configuration Protocol）：ダイナミックホストコンフィギュレーションプロトコル。動的にＩＰアドレスを割り当てるプロトコル。
・ＧＥＮＡ（General Event Notification Architecture）：一般イベント通知アーキテクチャ。ＵＰｎＰアーキテクチャにおいてイベントを発行する際に使用される。
・ＨＴＴＰ（HyperText Transfer Protocol）：ハイパーテキスト転送プロトコル。
・ＨＴＴＰＭＵ（HTTP Multicast over UDP）：ＵＤＰ（User Datagram Protocol）を用いたＨＴＴＰマルチキャスト。
・ＨＴＴＰＵ（HTTP(unicast) over UDP）：ＵＤＰを用いたＨＴＴＰユニキャスト。
・ＭＦＰ（Multi Function Peripheral）：複数のデバイスの機能を有する複合周辺装置。
・ＳＯＡＰ（Simple Object Access Protocol）：シンプルオブジェクトアクセスプロトコル。ＵＰｎＰアーキテクチャにおいて、ＲＰＣ（リモートプロシージャコール）によるアクションの要求とレスポンスとに使用される。
・ＳＳＤＰ（Simple Service Discovery Protocol）：シンプルサービス検出プロトコル。ＵＰｎＰアーキテクチャにおいて、サービスのディスカバリ（検出）に使用される。
・ＵＰｎＰ（Universal Plug and Play）：ユニバーサルプラグアンドプレイ（ＵＰｎＰは UPnP Implementers Corporationの商標）。
・ＵＲＩ（Uniform Resource Identifier）：ユニフォームリソース識別子。ＵＲＬ（Uniform Resouce Locator）の上位概念であり、リソースの固有の位置を示す識別子。
・ＸＨＴＭＬ（eXtensible HyperText Markup Language）：拡張ハイパーテキストマークアップ言語。ＨＴＭＬと互換性を有する文書記述言語の一種であり、ＸＭＬの実装の一形態である。後述するＸＨＴＭＬ−ｐｒｉｎｔは、ＸＨＴＭＬ文書を印刷するための仕様である。
・ＸＭＬ（eXtensible Markup Language）：拡張マークアップ言語。
なお、ＵＰｎＰでは上述した多数のプロトコルが使用されるが、以下ではこれらを総称して「ＵＰｎＰプロトコル」と呼ぶ。
B．システムの概要：
図１は、本発明の実施例を適用するネットワークシステムの構成を示す概念図である。このネットワークシステムは、パーソナルコンピュータ１００と、デジタルカメラ１１０と、ＴＶセット１２０と、画像サーバ１３０と、複合機２００とがＬＡＮを介して相互に接続された構成を有している。ＬＡＮは、ＩＥＥＥ８０２．３のような有線ネットワークでも、ＩＥＥＥ８０２．１１ｂ／ｇ／ａなどの無線ネットワークでもよい。デジタルカメラ１１０と、ＴＶセット１２０と、複合機２００とは、ＵＰｎＰ対応のネットワーク装置である。デジタルカメラ１１０とＴＶセット１２０は、ＵＰｎＰアーキテクチャにおけるコントロールポイント１１０Ｃ，１２０Ｃを備えている。ＵＰｎＰアーキテクチャ及びコントロールポイントについては後述する。パーソナルコンピュータ１００と画像サーバ１３０もこのネットワークシステムの構成要素の１つであるが、ＵＰｎＰには対応していない。
図１は、本発明の実施例を適用するネットワークシステムの構成を示す概念図である。このネットワークシステムは、パーソナルコンピュータ１００と、デジタルカメラ１１０と、ＴＶセット１２０と、画像サーバ１３０と、複合機２００とがＬＡＮを介して相互に接続された構成を有している。ＬＡＮは、ＩＥＥＥ８０２．３のような有線ネットワークでも、ＩＥＥＥ８０２．１１ｂ／ｇ／ａなどの無線ネットワークでもよい。デジタルカメラ１１０と、ＴＶセット１２０と、複合機２００とは、ＵＰｎＰ対応のネットワーク装置である。デジタルカメラ１１０とＴＶセット１２０は、ＵＰｎＰアーキテクチャにおけるコントロールポイント１１０Ｃ，１２０Ｃを備えている。ＵＰｎＰアーキテクチャ及びコントロールポイントについては後述する。パーソナルコンピュータ１００と画像サーバ１３０もこのネットワークシステムの構成要素の１つであるが、ＵＰｎＰには対応していない。
パーソナルコンピュータ１００は、プリンタドライバ１００Ｄを用いて画像の印刷データを作成し、ＬＡＮを介してこの印刷データを複合機２００に転送して印刷を実行させる機能を有している。この印刷処理の際には、複合機２００はＵＰｎＰのプロトコルを使用せず、通常のネットワークプリンタとして機能する。一方、コントロールポイント（例えば１１０Ｃ）からの要求に従って印刷を行う場合には、複合機２００はＵＰｎＰ対応のプリンタデバイスとして機能する。
複合機２００は、ＭＦＰサーバ３００と、ＭＦＰデバイスユニット４００とを有している。ＭＦＰサーバ３００は、ＬＡＮ上の他の装置とＭＦＰデバイスユニット４００との間で交換されるメッセージを仲介するネットワークプロトコル制御部３０２としての機能を有している。後述するように、ＭＦＰサーバ３００は、典型的な場合において、メッセージの転送の際にメッセージヘッダに関してＵＰｎＰのプロトコルを解釈するが、メッセージボディの解釈や処理は行わない。ＭＦＰデバイスユニット４００は、３つのサービスデバイス（プリンタ４０４，スキャナ４０６，ストレージ４０８）と、これらを制御するデバイス制御部４０２とを備えている。なお、プリンタ４０４，スキャナ４０６，ストレージ４０８以外のサービスデバイスを追加することも可能である。ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間は、ＵＳＢ（Universal Serial Bus）で接続されている。但し、両者の間をＵＳＢ以外の他の物理的インタフェースで接続することも可能である。
ＵＰｎＰは、ネットワーク装置を任意のタイミングでネットワークに接続したり、ネットワークから切断したりすることを実現するアーキテクチャである。ＵＰｎＰネットワークは、コントロールポイント１１０Ｃ，１２０Ｃと、デバイス４０４，４０６，４０８とで構成される。ここで、「デバイス」とは、サービスを提供する装置を意味している。本明細書においては、特に断らない限り、「デバイス」と「サービスデバイス」は同義語として使用されている。「コントロールポイント」は、ネットワーク上の他のデバイスを検出したり制御したりするコントローラを意味しており、サービスデバイスに対するクライアントとして機能する。ＵＰｎＰ対応のネットワーク装置が有する各種の機能については後述する。
図２は、複合機２００の内部構成を示すブロック図である。ＭＦＰサーバ３００は、中央制御部（ＣＰＵ）３１０と、ＲＡＭ３２０と、ＲＯＭ３３０と、ネットワーク制御部３４０と、ＵＳＢホスト制御部３５０とを有している。ネットワーク制御部３４０は、コネクタ３４２を介して有線ネットワークに接続される。ＵＳＢホスト制御部３５０は、ルートハブ３５２を有しており、ルートハブ３５２には２つのＵＳＢコネクタ３５４，３５６が設けられている。第１のＵＳＢコネクタ３５４は、ＵＳＢケーブルを介してＭＦＰデバイスユニット４００のＵＳＢコネクタ４６２に接続されている。第２のＵＳＢコネクタ３５６には、追加のデバイス（例えば無線ＬＡＮネットワークへ通信するための無線通信回路）を接続可能である。
ＭＦＰデバイスユニット４００は、中央制御部（ＣＰＵ）４１０と、ＲＡＭ４２０と、ＲＯＭ４３０と、印刷エンジン４４０と、スキャナエンジン４５０と、２つのＵＳＢデバイス制御部４６０，４７０と、ＰＣカードインタフェース４８０と、操作パネル制御部４９０と、ビューワ制御部５００と、ＵＳＢホスト制御部５１０とを有している。
印刷エンジン４４０は、与えられた印刷データに応じて印刷を実行する印刷機構である。本実施例では、コントロールポイント１１０Ｃ，１２０ＣがＸＨＴＭＬデータに基づいて印刷を行う場合には、中央制御部４１０がＸＨＴＭＬデータを解釈し、色変換やハーフトーン処理を実行して印刷データを作成し、この印刷データを印刷エンジン４４０に供給する。但し、中央制御部４１０の代わりに印刷エンジン４４０が色変換やハーフトーン処理の機能を有するように構成することも可能である。一方、パーソナルコンピュータ１００から印刷を行う場合は、プリンタドライバ１００Ｄが生成するページ記述言語を中央制御部４１０が解析して印刷データを作成し、印刷エンジン４４０に供給する。なお、本明細書において、「印刷データ」とは印刷媒体上におけるドットの形成状態を示すドットデータによって印刷物を表すデータを意味している。印刷データは、プリンタ固有の制御コマンドで構成されている。ＸＨＴＭＬは、印刷データには該当せず、文書を記述する文書記述言語である。スキャナエンジン４５０は、画像をスキャンして画像データを生成する機構である。
ＭＦＰデバイスユニット４００の第１のＵＳＢデバイス制御部４６０は、ＵＳＢコネクタ４６２を介してＭＦＰサーバ３００のＵＳＢホスト制御部３５０に接続されている。第２のＵＳＢデバイス制御部４７０は、ＵＳＢコネクタ４７２を有しており、ここにパーソナルコンピュータなどの任意のＵＳＢホストを接続することが可能である。ＰＣカードインタフェース４８０は、ＰＣカード用のスロット４８２を有している。操作パネル制御部４９０には、入力手段としての操作パネル４９２が接続されている。ビューワ制御部５００には、画像表示手段としてのビューワ５０２が接続されている。ユーザは、ビューワ５０２上に表示された画像やメニューを観察しながら、操作パネル４９２を用いて種々の指示を入力することができる。ＵＳＢホスト制御部５１０は、ルートハブ５１２を有しており、ルートハブ５１２にはＵＳＢコネクタ５１４が設けられている。このコネクタ５１４には、有限責任中間法人カメラ映像機器工業会が策定したＣＩＰＡ ＤＣ−００１−２００３などに準拠したデジタルカメラなどのＵＳＢデバイスを接続することが可能である。
ＭＦＰサーバ３００の中央制御部３１０とネットワーク制御部３４０とＵＳＢホスト制御部３５０は、図１におけるネットワークプロトコル制御部３０２としての機能を実現する。より具体的には、ネットワーク制御部３４０は、各種のネットワークプロトコルに従ってメッセージの送受信を行う。また、中央制御部３１０は、ＵＰｎＰのプロトコルを解釈して転送先を決定する。ＵＳＢホスト制御部３５０は、ＭＦＰデバイスユニット４００との間でメッセージを転送する。これらの制御部３１０，３４０，３５０は、メッセージボディの解釈や処理は行わずにメッセージを転送している。
ＭＦＰデバイスユニット４００のＵＳＢデバイス制御部４６０及び中央制御部４１０は、図１におけるデバイス制御部４０２としての機能を実現する。より具体的には、ＵＳＢデバイス制御部４６０は、ＵＳＢの転送プロトコルに従ってメッセージの送受信を行う。また、中央制御部４１０は、ＭＦＰサーバ３００を介して転送されたメッセージの内容を解釈し、メッセージの内容に応じた処理を実行して、印刷エンジン４４０やスキャナエンジン４５０を動作させる。印刷エンジン４４０は図１のプリンタ４０４のハードウェア部分に相当し、スキャナエンジン４５０は図１のスキャナ４０６のハードウェア部分に対応する。また、ＰＣカードインタフェース４８０のスロット４８２に挿入されたメモリカードは、図１のストレージ４０８のハードウェア部分に相当する。
図３は、ＭＦＰサーバ３００の各種のプロトコルの階層構造を示すブロック図である。ＭＦＰサーバ３００は、各種のネットワークプロトコルを解釈するためのサービスプロトコル解釈部１０００を備えている。このサービスプロトコル解釈部１０００には、ネットワークアーキテクチャの下位層と、ＵＳＢアーキテクチャの下位層とが存在する。ネットワークアーキテクチャの下位層としては、ＵＰｎＰデバイスアーキテクチャ１１００と、３つの非ＵＰｎＰデバイス機能部１２１０，１２２０，１２３０が設けられている。これらのさらに下位には、ＵＤＰ層又はＴＣＰ層と、インターネットプロトコル（ＩＰ）層と、ドライバ層と、ネットワークインタフェース層と、が存在する。
サービスプロトコル解釈部１０００のＵＳＢアーキテクチャの下位層としては、Ｄ４パケット処理部１３００及びＵＳＢプリンタクラスドライバ１３１０と、ＵＳＢスキャナクラスドライバ１３２０と、ＵＳＢストレージクラスドライバ１３３０とが設けられている。これらの３つのデバイスドライバ１３１０，１３２０，１３３０の下位には、ＵＳＢシステムソフトウェアとＵＳＢホストインタフェース（ハードウェア）とが存在する。なお、この図からも理解できるように、ＵＳＢのプリンタクラスドライバ１３１０は、いわゆる「Ｄ４パケット」（ＩＥＥＥ１２８４．４に即したパケット構造）を利用してデータ転送を行うのに対して、スキャナクラスドライバ１３２０やストレージクラスドライバ１３３０ではＤ４パケットは利用されていない。この理由は、標準的なＵＳＢのデバイスクラスのうちで、プリンタクラスではＤ４パケットが上位プロトコルとして採用されているが、スキャナクラス及びストレージクラスでは、Ｄ４パケットを用いない制御スタック（アプリケーション層から物理層に至るまでのアーキテクチャ）がＯＳの標準となっているからである。
ＵＰｎＰデバイスアーキテクチャは、ＨＴＴＰＭＵや、ＨＴＴＰＵ，ＳＯＡＰ／ＨＴＴＰ，ＨＴＴＰなどの各種のプロトコルに従って構成されている。ＵＰｎＰは、これらのプロトコルを用いて、以下のような各種の処理を実現している。
（１）アドレッシング：
ＵＰｎＰデバイス（以下、単に「デバイス」と呼ぶ）がネットワークに接続すると、アドレッシングによってネットワークアドレス（ＩＰアドレス）を取得する。アドレッシングには、ＤＨＣＰサーバまたはAuto-IPが利用される。ネットワークにＤＨＣＰサーバが設けられている場合には、デバイスはＤＨＣＰサーバによって割り当てられるＩＰアドレスを使用する。ＤＨＣＰサーバが無い場合には、Auto-IPと呼ばれる自動ＩＰアドレッシング機能を用いて、デバイスが自分のアドレスを決定する。なお、本実施例では、複合機２００に対して１つのＩＰアドレスのみが割り当てられ、複合機２００全体が単一のネットワーク装置として認識される。
ＵＰｎＰデバイス（以下、単に「デバイス」と呼ぶ）がネットワークに接続すると、アドレッシングによってネットワークアドレス（ＩＰアドレス）を取得する。アドレッシングには、ＤＨＣＰサーバまたはAuto-IPが利用される。ネットワークにＤＨＣＰサーバが設けられている場合には、デバイスはＤＨＣＰサーバによって割り当てられるＩＰアドレスを使用する。ＤＨＣＰサーバが無い場合には、Auto-IPと呼ばれる自動ＩＰアドレッシング機能を用いて、デバイスが自分のアドレスを決定する。なお、本実施例では、複合機２００に対して１つのＩＰアドレスのみが割り当てられ、複合機２００全体が単一のネットワーク装置として認識される。
（２）ディスカバリ（検出）：
ディスカバリは、コントロールポイントが、デバイスがどこにいるかを見つけ出す処理である。ディスカバリは、コントロールポイントがディスカバリメッセージをマルチキャストすることによって実現することができ、あるいは、デバイスがネットワークに参加したときに、その旨をコントロールポイントにアドバタイズすることによっても実現できる。ディスカバリは、ＨＴＴＰＭＵ／ＳＳＤＰやＨＴＴＰＵ／ＳＳＤＰを用いて行われる。ディスカバリの結果、コントロールポイントとデバイスがピアツーピアで処理を進められるようになる。
ディスカバリは、コントロールポイントが、デバイスがどこにいるかを見つけ出す処理である。ディスカバリは、コントロールポイントがディスカバリメッセージをマルチキャストすることによって実現することができ、あるいは、デバイスがネットワークに参加したときに、その旨をコントロールポイントにアドバタイズすることによっても実現できる。ディスカバリは、ＨＴＴＰＭＵ／ＳＳＤＰやＨＴＴＰＵ／ＳＳＤＰを用いて行われる。ディスカバリの結果、コントロールポイントとデバイスがピアツーピアで処理を進められるようになる。
（３）ディスクリプション：
デバイスの構成の詳細は、デバイスディスクリプションとしてＸＭＬで記述されている。また、デバイスのサービスの詳細は、サービスディスクリプションとしてＸＭＬで記述されている。これらのディスクリプションは、デバイスによって所有されており、コントロールポイントに提供される。コントロールポイントは、これらのディスクリプションを参照することによって、デバイスやサービスの詳細を知ることができる。デバイスディスクリプションの例については後述する。
デバイスの構成の詳細は、デバイスディスクリプションとしてＸＭＬで記述されている。また、デバイスのサービスの詳細は、サービスディスクリプションとしてＸＭＬで記述されている。これらのディスクリプションは、デバイスによって所有されており、コントロールポイントに提供される。コントロールポイントは、これらのディスクリプションを参照することによって、デバイスやサービスの詳細を知ることができる。デバイスディスクリプションの例については後述する。
（４）コントロール：
コントロールは、コントロールポイントが、アクション要求を含む制御メッセージをデバイスに転送して、デバイスの制御を行う処理である。コントロールは、ＨＴＴＰ／ＳＯＡＰを用いて行われる。
コントロールは、コントロールポイントが、アクション要求を含む制御メッセージをデバイスに転送して、デバイスの制御を行う処理である。コントロールは、ＨＴＴＰ／ＳＯＡＰを用いて行われる。
（５）イベント：
所定のイベントが発生すると、デバイス内のサービスが、コントロールポイントにイベントの発生を通知する。イベント発生の通知を受けるコントロールポイントは、そのサービスに「サブスクライブ（購読）」する。イベントは、サブスクライブしているコントロールポイントに転送される。イベントの通知は、ＨＴＴＰ／ＧＥＮＡを用いて行われる。
所定のイベントが発生すると、デバイス内のサービスが、コントロールポイントにイベントの発生を通知する。イベント発生の通知を受けるコントロールポイントは、そのサービスに「サブスクライブ（購読）」する。イベントは、サブスクライブしているコントロールポイントに転送される。イベントの通知は、ＨＴＴＰ／ＧＥＮＡを用いて行われる。
（６）プレゼンテーション：
プレゼンテーションは、デバイスディスクリプションに登録されているプレゼンテーション用のＵＲＬからコントロールポイントがＨＴＭＬで記述されたプレゼンテーション用ページを取得する処理である。このプレゼンテーションによって、例えばコントロールポイントがデバイスの各種の状態を表示することができる。
プレゼンテーションは、デバイスディスクリプションに登録されているプレゼンテーション用のＵＲＬからコントロールポイントがＨＴＭＬで記述されたプレゼンテーション用ページを取得する処理である。このプレゼンテーションによって、例えばコントロールポイントがデバイスの各種の状態を表示することができる。
なお、本発明はＵＰｎＰの将来のバージョンにも適用可能である。また、ネットワーク型プラグアンドプレイとして、アドレッシング（自動的なＩＰアドレス決定）と、デバイスのディスカバリにより、任意のコントロールポイントとデバイスとがピアツーピアで通信が可能で、コントロールポイントとデバイスがメッセージの交換を行うアーキテクチャであれば、ＵＰｎＰ以外のネットワーク型プラグアンドプレイ仕様にも本発明を適用することが可能である。
図４は、ＭＦＰデバイスユニット４００の各種プロトコルの階層構造を示すブロック図である。ＭＦＰデバイスユニット４００は、ＵＰｎＰデバイス機能部２４００と、３つの非ＵＰｎＰデバイス機能部２２１０，２２２０，２２３０とを有している。ＵＰｎＰデバイス機能部２４００は、３つのＵＰｎＰデバイスモジュール（図１のプリンタ４０４，スキャナ４０６，ストレージ４０８）を含んでいる。各デバイスモジュール内には、サービスを実行するサービスモジュールが含まれているが、ここでは図示が省略されている。ＵＰｎＰデバイス機能部２４００と非ＵＰｎＰプリンタ機能部２２１０の下位には、Ｄ４パケット処理部２３００及びＵＳＢプリンタクラスドライバ２３１０が存在する。非ＵＰｎＰスキャナ機能部２２２０及び非ＵＰｎＰストレージ機能部２２３０の下位には、ＵＳＢスキャナクラスドライバ２３２０とＵＳＢストレージクラスドライバ２３３０が存在する。３つのデバイスドライバ２３１０，２３２０，２３３０の下位には、ＵＳＢ論理デバイスとＵＳＢデバイスインタフェース（ハードウェア）とが存在する。この階層構造からも理解できるように、ＵＰｎＰスキャナデバイスやＵＰｎＰストレージデバイスがコントロールポイントに対してサービスを行う場合には、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００間では、ＵＳＢプリンタクラスドライバ２３１０を利用してデータ転送が行われる。従って、ＵＰｎＰスキャナデバイスやＵＰｎＰストレージデバイス用のデータ転送の際にも、Ｄ４パケットを利用することができる。
図４に示すように、ＭＦＰサーバ３００のＵＳＢプリンタクラスドライバ１３１０とＭＦＰデバイスユニット４００のＵＳＢプリンタクラスドライバ２３１０の間には、７種類のＵＰｎＰ用双方向通信チャンネルが設けられている。これらは、Ｄ４パケットを用いた論理チャンネルであり、複合機２００がＵＰｎＰデバイスとして機能する場合に使用される。サービスプロトコル解釈部１０００とＵＰｎＰデバイス機能部２４００の間にも、プリンタクラスドライバ１３１０，２３１０の間の７種類の論理チャンネルに対応する７種類のＵＰｎＰ用論理チャンネルが存在するが、図４では図示が省略されている。以下ではまず、Ｄ４パケットを用いた論理チャンネルについて説明する。
図５は、ＵＳＢのインタフェース／エンドポイント構成と論理チャンネルの構成とを示す説明図である。一般に、ＵＳＢデバイスは、インタフェースとエンドポイントとを有している。ＵＳＢの転送は、ＵＳＢのホストとエンドポイントとの間で行われる。すなわち、「エンドポイント」とは、ホストと通信を行う論理的なリソースである。図５（Ａ）の例では、７つのエンドポイントＥＰ＃０〜ＥＰ＃６が示されている。コントロールエンドポイントＥＰ＃０は、標準デバイスリクエストの送受信を行うためのエンドポイントである。「標準デバイスリクエスト」とは、すべてのＵＳＢでサポートする必要がある基本的なリクエストである。従って、コントロールエンドポイントＥＰ＃０は、１つのＵＳＢデバイスに必ず１つ設けられている。
プリンタ用のバルクアウトエンドポイントＥＰ＃１とバルクインエンドポイントＥＰ＃２は、印刷エンジン４４０用のメッセージの受信と送信を行うためのエンドポイントである。同様に、スキャナ用のバルクアウトエンドポイントＥＰ＃３とバルクインエンドポイントＥＰ＃４は、スキャナエンジン４５０用のメッセージの受信と送信を行うためのエンドポイントである。また、ストレージ用のエンドポイントＥＰ＃５，ＥＰ＃６は、メモリーカード用のメッセージの受信と送信を行うためのエンドポイントである。一般に、ＵＳＢデバイスでは、コントロールエンドポイントＥＰ＃０以外のエンドポイントは、論理的なインタフェースによって区分されている。図５（Ａ）の例では、論理的なインタフェースとして、プリンタインタフェースＩＦ＃０とスキャナインタフェースＩＦ＃１とストレージインタフェースＩＦ＃２とが設けられている。
本実施例では、図５（Ｂ）に示すように、プリンタインタフェースＩＦ＃０に９つの論理的なチャンネルが設けられている。これらの各チャンネルの機能は以下の通りである。
（１）PRINT-DATAチャンネルＣＨ＃１１：
ネットワーク上のパーソナルコンピュータ１００から、印刷ポート（ＬＰＲポートに従ったポート番号又はボート番号９１００）を用いてプリンタドライバ１００Ｄ（図１）から転送される印刷データの送受信を行うためのチャンネル。図４には図示されていない。
ネットワーク上のパーソナルコンピュータ１００から、印刷ポート（ＬＰＲポートに従ったポート番号又はボート番号９１００）を用いてプリンタドライバ１００Ｄ（図１）から転送される印刷データの送受信を行うためのチャンネル。図４には図示されていない。
（２）PRINT-STATUSチャンネルＣＨ＃１２：
ＭＦＰサーバ３００が、印刷エンジン４４０の状態を示す情報を送受信するためのチャンネルであり、ＳＮＭＰ等のプロトコルにより、ＭＦＰサーバ３００からネットワーク上のパーソナルコンピュータ１００に対して提供される。図４には図示されていない。
ＭＦＰサーバ３００が、印刷エンジン４４０の状態を示す情報を送受信するためのチャンネルであり、ＳＮＭＰ等のプロトコルにより、ＭＦＰサーバ３００からネットワーク上のパーソナルコンピュータ１００に対して提供される。図４には図示されていない。
（３）UPNP-LOCALCONTROLチャンネルＣＨ＃２１：
ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の間において、ＭＦＰサーバ３００を要求者とし、ＭＦＰデバイスユニット４００を応答者とする通信を行うためのＵＰｎＰ用チャンネル。ＭＦＰサーバ３００は、このチャンネルを用いて、ＭＦＰデバイスユニット４００から各種の情報を取得することができる。
ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の間において、ＭＦＰサーバ３００を要求者とし、ＭＦＰデバイスユニット４００を応答者とする通信を行うためのＵＰｎＰ用チャンネル。ＭＦＰサーバ３００は、このチャンネルを用いて、ＭＦＰデバイスユニット４００から各種の情報を取得することができる。
（４）UPNP-LOCALEVENTチャンネルＣＨ＃２２：
ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の間において、ＭＦＰデバイスユニット４００を要求者とし、ＭＦＰサーバ３００を応答者とする通信を行うためのＵＰｎＰ用チャンネル。ＭＦＰデバイスユニット４００は、このチャンネルを用いて、例えばユーザが行った設定変更の内容をＭＦＰサーバ３００に通知することができ、また、ＭＦＰデバイスユニット４００が電源ＯＦＦしようとするときに、ＵＰｎＰプロトコルの終了要求をＭＦＰサーバ３００に通知することができる。
ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の間において、ＭＦＰデバイスユニット４００を要求者とし、ＭＦＰサーバ３００を応答者とする通信を行うためのＵＰｎＰ用チャンネル。ＭＦＰデバイスユニット４００は、このチャンネルを用いて、例えばユーザが行った設定変更の内容をＭＦＰサーバ３００に通知することができ、また、ＭＦＰデバイスユニット４００が電源ＯＦＦしようとするときに、ＵＰｎＰプロトコルの終了要求をＭＦＰサーバ３００に通知することができる。
（５）UPNP-PRESENTATIONチャンネルＣＨ＃２３：
ＵＰｎＰのプレゼンテーションデータ（Ｗｅｂページデータ）を送受信するためのチャンネル。なお、コントロールポイントの要求に応じてプレゼンテーションデータをＭＦＰデバイスユニット４００からコントロールポイントに送信するためのチャンネル（ダウンチャンネル）と、新たなプレゼンテーションデータをコントロールポイントからＭＦＰデバイスユニット４００にアップロードするためのチャンネル（アップチャンネル）とを別々に設けるようにしたもよい。
ＵＰｎＰのプレゼンテーションデータ（Ｗｅｂページデータ）を送受信するためのチャンネル。なお、コントロールポイントの要求に応じてプレゼンテーションデータをＭＦＰデバイスユニット４００からコントロールポイントに送信するためのチャンネル（ダウンチャンネル）と、新たなプレゼンテーションデータをコントロールポイントからＭＦＰデバイスユニット４００にアップロードするためのチャンネル（アップチャンネル）とを別々に設けるようにしたもよい。
（６）UPNP-CONTROLチャンネルＣＨ＃２４：
ＵＰｎＰにおいて、コントロールポイントから発信されたアクションに関連するデータを送受信するためのチャンネル。なお、上述のUPNP-LOCALCONTROLチャンネルに”LOCAL”という接頭語が付されている理由は、UPNP-LOCALTONTROLチャンネルが、コントロールポイントからのアクションの内容の転送には使用されないからである。換言すれば、UPNP-CONTROLチャンネルＣＨ＃２４は、コントロールポイントから発信されたアクションに関連するデータの送受信のためにのみ使用される。
ＵＰｎＰにおいて、コントロールポイントから発信されたアクションに関連するデータを送受信するためのチャンネル。なお、上述のUPNP-LOCALCONTROLチャンネルに”LOCAL”という接頭語が付されている理由は、UPNP-LOCALTONTROLチャンネルが、コントロールポイントからのアクションの内容の転送には使用されないからである。換言すれば、UPNP-CONTROLチャンネルＣＨ＃２４は、コントロールポイントから発信されたアクションに関連するデータの送受信のためにのみ使用される。
（７）UPNP-EVENTチャンネルＣＨ＃２５：
ＵＰｎＰにおいて、イベントをサブスクライブしているコントロールポイントに送信するためのチャンネル。上述のUPNP-LOCALEVENTチャンネルに”LOCAL”という接頭語が付されている理由は、このUPNP-LOCALEVENTチャンネルが、コントロールポイントへのイベントの送信には使用されないからである。換言すれば、UPNP-EVENTチャンネルＣＨ＃２５は、複合機２００で発生したイベントをコントロールポイントに送信するためにのみ使用される。
ＵＰｎＰにおいて、イベントをサブスクライブしているコントロールポイントに送信するためのチャンネル。上述のUPNP-LOCALEVENTチャンネルに”LOCAL”という接頭語が付されている理由は、このUPNP-LOCALEVENTチャンネルが、コントロールポイントへのイベントの送信には使用されないからである。換言すれば、UPNP-EVENTチャンネルＣＨ＃２５は、複合機２００で発生したイベントをコントロールポイントに送信するためにのみ使用される。
（８）UPNP-DOWNCONTENTxチャンネルＣＨ＃２６ｘ：
ＵＰｎＰにおいて、コンテンツデータをコントロールポイントからＭＦＰデバイスユニット４００にダウンロードする際に使用される送受信チャンネル。ここで、接尾辞”ｘ”は、Ｎdown個（Ｎdownは２以上の整数）のUPNP-DOWNCONTENTチャンネルのうちのｘ番目のチャンネルを意味している。利用可能なUPNP-DOWNCONTENTxチャンネルの個数Ｎdownは、１以上の任意に設定可能であるが、２以上の値に設定することが好ましい。Ｎdownを２以上の値に設定すれば、複数のコントロールのコンテンツデータを並行して受信することが可能である。
ＵＰｎＰにおいて、コンテンツデータをコントロールポイントからＭＦＰデバイスユニット４００にダウンロードする際に使用される送受信チャンネル。ここで、接尾辞”ｘ”は、Ｎdown個（Ｎdownは２以上の整数）のUPNP-DOWNCONTENTチャンネルのうちのｘ番目のチャンネルを意味している。利用可能なUPNP-DOWNCONTENTxチャンネルの個数Ｎdownは、１以上の任意に設定可能であるが、２以上の値に設定することが好ましい。Ｎdownを２以上の値に設定すれば、複数のコントロールのコンテンツデータを並行して受信することが可能である。
（９）UPNP-UPCONTENTxチャンネルＣＨ＃２７ｘ：
ＵＰｎＰにおいて、コンテンツデータをＭＦＰデバイスユニット４００からコントロールポイントにアップロードする際に使用される送受信チャンネル。接尾辞”ｘ”は、Ｎup個（Ｎupは２以上の整数）のUPNP-UPCONTENTチャンネルのうちのｘ番目のチャンネルを意味している。UPNP-DOWNCONTENTxチャンネルの個数ＮdownとUPNP-UPCONTENTxチャンネルの個数Ｎupは、同じでも良く、また、異なっていてもよい。なお、実際の図５（Ｂ）のＵＰｎＰ用の論理チャンネルの数は、（５＋Ｎdown＋Ｎup）個となることが理解できる。
ＵＰｎＰにおいて、コンテンツデータをＭＦＰデバイスユニット４００からコントロールポイントにアップロードする際に使用される送受信チャンネル。接尾辞”ｘ”は、Ｎup個（Ｎupは２以上の整数）のUPNP-UPCONTENTチャンネルのうちのｘ番目のチャンネルを意味している。UPNP-DOWNCONTENTxチャンネルの個数ＮdownとUPNP-UPCONTENTxチャンネルの個数Ｎupは、同じでも良く、また、異なっていてもよい。なお、実際の図５（Ｂ）のＵＰｎＰ用の論理チャンネルの数は、（５＋Ｎdown＋Ｎup）個となることが理解できる。
なお、各論理チャンネルは、いずれもバルクアウトエンドポイントＥＰ＃１とバルクインエンドポイントＥＰ＃２の両方を利用して双方向通信を行うことができる。論理チャンネルの識別情報は、Ｄ４パケットのヘッダに登録される。
スキャナインタフェースＩＦ＃１のエンドポイントＥＰ＃３，ＥＰ＃４は、スキャナクラスドライバ１３２０，２３２０（図４）間の論理チャンネルを介した通信に用いられる。また、ストレージインタフェースＩＦ＃２のエンドポイントＥＰ＃５，ＥＰ＃６は、ストレージクラスドライバ１３３０，２３３０間の論理チャンネルを介した通信に用いられる。これらの論理チャンネルは、Ｄ４パケットによるパケット化がなされていない点で、プリンタクラスドライバ１３１０，２３１０間の論理チャンネル（図５（Ｂ））と異なる。但し、スキャナインタフェースＩＦ＃１とストレージインタフェースＩＦ＃２を用いたデータ転送においても、ＵＳＢの物理層はＵＳＢ規格に従ってパケット化されている点に注意すべきである。
図６は、プリンタインタフェースＩＦ＃０を介したＵＳＢ転送に用いられるＤ４パケットの構成を示す説明図である。これは、ＩＥＥＥ１２８４．４に即したパケット構造である。このＤ４パケットは、１２バイトのヘッダ部と、０バイト以上のメッセージ部から構成されている。ヘッダ部は、６バイトのＤ４標準ヘッダと、４バイトのＩＤフィールドと、２バイトのエラーコードフィールドとを有している。Ｄ４標準ヘッダには、図５（Ｂ）に示した９種類の（７＋２Ｎ）個の論理チャンネルを識別するためのソケットＩＤ（論理チャンネルＩＤ）が登録される。ＩＤフィールドには、リクエストＩＤが登録される。このリクエストＩＤは、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間のデータ転送（特にUPNP-DOWNCONTENTxチャンネルやUPNP-UPCONTENTxチャンネル）において、同じメッセージを構成するパケットを識別するために使用される。なお、リクエストＩＤは、ＭＦＰサーバ３００が割り当てる場合と、ＭＦＰデバイスユニット４００が割り当てる場合とが存在する。従って、リクエストＩＤには、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００のいずれが割当てたかを一意に識別できるビット（例えば最上位ビット）を設けておくことが好ましい。なお、リクエストＩＤを「ジョブＩＤ」とも呼ぶ。
Ｄ４パケットでは、ヘッダ部を利用して多様な論理チャンネルを構成できるので、多様な論理チャンネルを用いて多様なデータ転送を実現することが可能である。また、Ｄ４標準ヘッダ以外のヘッダ情報をある程度任意に設定することができるので、各種の制御を実行するための工夫の自由度が高いという利点がある。
図４からも理解できるように、プリンタクラスドライバ１３１０，２３１０間の論理チャンネルの通信ではＤ４パケットが利用され、一方、スキャナクラスドライバ１３２０，２３２０間の論理チャンネルの通信と、ストレージクラスドライバ１３３０，２３３０間の論理チャンネルの通信ではＤ４パケットは利用されない。従って、プリンタクラス方が、スキャナクラスやストレージクラスよりも多様な通信を実現することが可能である。なお、Ｄ４パケットは、ＵＳＢ規格に従って物理層で再度パケット化される。すなわち、Ｄ４パケットは、ＵＳＢ物理層のパケット（「ＵＳＢパケット」と呼ぶ）のペイロードとして、ＵＳＢパケット（データパケット）内に梱包される。このように、Ｄ４パケット処理部１３００，２３００は、ＵＳＢパケットよりも上位のプロトコル層でパケット化を実行していることが理解できる。
本実施例のＤ４パケットを用いてリクエストを転送する場合には、エラーフィールドの後のメッセージの先頭（「メッセージヘッダ」とも呼ぶ）には、メッセージの送り元から送り先（受け手）へ通知するＵＲＩ（通常は相対ＵＲＩ）が付加される。メッセージの受け手は、このＵＲＩから、リクエストの内容や宛先を容易に判定することが可能である。なお、Ｄ４パケットのメッセージの具体的な内容については後述する。
図５（Ｂ）に示したように、本実施例では、ＵＳＢ転送用の論理チャンネルとして、印刷ポート用の論理チャンネルＣＨ＃１１〜ＣＨ＃１２と、ＵＰｎＰ用の論理チャンネルＣＨ＃２１〜ＣＨ＃２７ｘとを別個に設けている。従って、ネットワーク印刷ポートを介してＭＦＰデバイスユニット４００に転送されてくる印刷データと、ＵＰｎＰ用のポートを介してＭＦＰデバイスユニット４００に転送されてくるコンテンツデータ（例えば印刷用のＸＨＴＭＬデータ）とを容易に識別することができる。また、本実施例では、ＵＰｎＰプロトコルによるメッセージのＵＳＢ転送のために、用途の異なる複数の論理チャンネルＣＨ＃２１〜ＣＨ＃２７ｘを設けているので、メッセージの受信側において、メッセージの内容の処理をより高速に処理することが可能である。特に、本実施例ではコントロールポイントとの間の通信の際に利用される論理チャンネルＣＨ＃２３〜ＣＨ＃２７ｘの他に、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間のローカルな情報の転送に使用される論理チャンネルＣＨ＃２１，ＣＨ＃２２が別個に設けられている。従って、例えばクライアント（コントロール）から送られたメッセージと、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間で通知される特定の情報とを容易に区別して、それぞれに適した処理を素早く実行することが可能である。
図７は、ＵＰｎＰアーキテクチャを利用した処理の典型例を示すシーケンス図である。ここでは、コントロールポイント１１０Ｃと、ＭＦＰサーバ３００と、ＭＦＰデバイスユニット４００の間でメッセージが転送される場合を示している。ステップ[1]では、コントロールポイント１１０ＣがＨＴＴＰのリクエストメッセージＦ１をＭＦＰサーバ３００に転送する。メッセージＦ１のヘッダには、リクエスト命令のメソッド（ＰＯＳＴやＧＥＴなど）と、ＭＦＰデバイスユニット４００内の宛先を示すＵＲＩと、複合機２００のホスト名（この例ではＩＰアドレス”169.254.100.100”）とが記述されている。なお、ＩＰアドレスは、複合機２００に１つだけば割り当てられるので、このＩＰアドレスは、ＭＦＰサーバ３００のＩＰアドレス又はＭＦＰデバイスユニット４００のＩＰアドレスと考えることも可能である。
ステップ[2]では、ＭＦＰサーバ３００が、リクエストメッセージＦ１を解析する。ここで解析（解釈）されるのは、メッセージＦ１のヘッダ部分だけであり、送信データ（すなわちメッセージボディ）の内容の解釈は行わない。より具体的には、ステップ[2]において、メッセージＦ１のＵＲＩが解析され、ＭＦＰデバイスユニット４００に対してどの論理チャンネルを用いてメッセージを転送すべきかが判定される。なお、メッセージＦ１には、実質的なメッセージボディが無いものも存在する。
ステップ[3]では、ＭＦＰサーバ３００が、ＵＲＩとメッセージボディ（存在する場合）とを含むメッセージＦ２を、ＵＳＢでＭＦＰデバイスユニット４００に転送する。この転送の際には、ＵＲＩに応じて選択された論理チャンネルが利用される。
ステップ[4]では、ＭＦＰデバイスユニット４００が、受信したメッセージＦ２内のＵＲＩ及びメッセージボディ（存在する場合）に応じて処理を実行する。この例については後述する。ステップ[5]では、ＭＦＰデバイスユニット４００が、レスポンスデータを含むメッセージＲ１をＵＳＢでＭＦＰサーバ３００に転送する。ステップ[6]では、ＭＦＰサーバ３００が送信データにＨＴＴＰヘッダを付加する。このＨＴＴＰヘッダは、ＨＴＴＰリクエストの処理結果を示すステータスコードを含んでいる。例えば、処理結果がＯＫであればステータスコードが”２００”に設定され、エラーであれば”５００”に設定される。ステップ[7]では、こうして作成されたＨＴＴＰのレスポンスメッセージＲ２がＭＦＰサーバ３００からコントロールポイント１１０Ｃに転送される。
このように、本実施例では、ＭＦＰサーバ３００は、コントロールポイントから受信したリクエストメッセージのうちで、ヘッダの解析（解釈）は行うが、メッセージボディの内容の解釈は行わず、メッセージボディはＭＦＰデバイスユニット４００によって処理される。この構成には以下のような利点がある。第１の利点は、ＭＦＰサーバ３００が、ＭＦＰデバイスユニット４００のデバイス構成とサービスの内容を把握する必要が無く、任意の構成を有するデバイスユニット宛に送られたメッセージを転送するためのネットワークプロトコル制御部として機能することができる点である。第２の利点は、ＭＦＰデバイスユニット４００のデバイス構成やサービスの内容が変更されても、ＭＦＰサーバ３００の構成や機能を変更する必要が無い点である。第３の利点は、ＭＦＰサーバ３００にメッセージボディの内容の解釈を行う解釈部（パーサ）を実装する必要が無いので、ＭＦＰサーバ３００の構成が単純で済む点である。
C．複合機のデバイス構成及びデバイスディスクリプション：
図８（Ａ）は、複合機２００のＵＰｎＰプロトコル上のデバイス構成を示す説明図である。本実施例の複合機２００のＵＰｎＰデバイスとしての構成では、ルートデバイスとしてのプリンタ”Printer”の中に、スキャナデバイス”Scnanner”とストレージデバイス”Storage”とが包含されている。換言すれば、スキャナデバイス”Scnanner”とストレージデバイス”Storage”は、プリンタデバイス”Printer”内の埋込デバイスである。プリンタデバイス”Printer”は２つのプリントサービス”PrintBasic”，”PrintEnhanced”を有している。これらの２つのサービスは、ＵＰｎＰで規格化されている標準的なプリントサービスである。スキャナデバイス”Scanner”はスキャンサービス”Scan”を有しており、ストレージデバイス”Storage”はストレージサービス”Storage”を有している。各サービスは、状態テーブルと、コントロールサーバと、イベントサーバとで構成されている。状態テーブルには、サービスの状態を示す状態変数が登録されている。コントロールサーバは、コントロールポイントからのアクション要求を受け付けて処理を実行する。イベントサーバは、状態変数の値が変更されると、その変更をイベントとしてコントロールポイントに通知する。通知対象となるのは、そのサービスに予めサブスクライブ（購読）しているコントロールポイントである。
図８（Ａ）は、複合機２００のＵＰｎＰプロトコル上のデバイス構成を示す説明図である。本実施例の複合機２００のＵＰｎＰデバイスとしての構成では、ルートデバイスとしてのプリンタ”Printer”の中に、スキャナデバイス”Scnanner”とストレージデバイス”Storage”とが包含されている。換言すれば、スキャナデバイス”Scnanner”とストレージデバイス”Storage”は、プリンタデバイス”Printer”内の埋込デバイスである。プリンタデバイス”Printer”は２つのプリントサービス”PrintBasic”，”PrintEnhanced”を有している。これらの２つのサービスは、ＵＰｎＰで規格化されている標準的なプリントサービスである。スキャナデバイス”Scanner”はスキャンサービス”Scan”を有しており、ストレージデバイス”Storage”はストレージサービス”Storage”を有している。各サービスは、状態テーブルと、コントロールサーバと、イベントサーバとで構成されている。状態テーブルには、サービスの状態を示す状態変数が登録されている。コントロールサーバは、コントロールポイントからのアクション要求を受け付けて処理を実行する。イベントサーバは、状態変数の値が変更されると、その変更をイベントとしてコントロールポイントに通知する。通知対象となるのは、そのサービスに予めサブスクライブ（購読）しているコントロールポイントである。
本明細書では、サービスを含むデバイスを「サービスデバイス」と呼んでいる。図８からも理解できるように、各サービスデバイスは、１つ以上の任意の数のサービスを含むことが可能である。また、あるサービスデバイスが、他のサービスデバイスを含むようにデバイス構成を構築することが可能である。
なお、図８の構成の代わりに、ルートデバイスとしてＵＰｎＰで規格化されているベーシックデバイス”Basic”を使用し、このベーシックデバイス”Basic”の下位の同じ階層に３つのサービスデバイス”Printer”，”Scanner”，”Storage”が並置されるようなデバイス構成を採用することも可能である。ベーシックデバイス”Basic”は、１つ以上のサービスデバイスを含み、かつ、サービスデバイスが実行するサービスの他には自分自身が実行する固有のサービスを有さないデバイスである。この場合にも、複合機２００が１つのルートデバイスによって代表されるので、複合機２００に対して１つのＩＰアドレスを割り当てるだけで済むという利点が維持される。
図８にも示したように、本実施例では、複合機２００全体に対してＩＰアドレスが１つだけ割り当てられるので、コントロールポイントは、この１つのＩＰアドレスを用いて複合機２００（ＭＦＰサーバ３００）の種々のサービスデバイスにアクセスできるという利点がある。また、本実施例では、ＩＰアドレスの数が比較例よりも少なくて済むので、ネットワーク内におけるＩＰアドレスの管理がより容易であるという利点がある。
ＵＰｎＰの各デバイスは、自身の構成や機能をデバイスディスクリプションという形式で予め保持しており、コントロールポイントからの要求に応じてデバイスディスクリプションを提供する機能を有している。また、サービスの内容は、サービスディスクリプションとして形でデバイス内に保持され、コントロールポイントに提供される。図８の例では、３つのデバイスのデバイスディスクリプションと、４つのサービスのサービスディスクリプションとが、ＭＦＰデバイスユニット４００内に予め保持されている。
図９は、複合機２００全体のデバイスディスクリプションの例を示している。デバイスディスクリプションは、ＸＭＬで記述されている。アンダーラインを付した部分は、本実施例に特有の設定を示している。要素<URLBase>の内容”http://169.254.100.100:80”は、複合機２００のホスト名（ここではＩＰアドレス）と、ＨＴＴＰを用いる場合のポート番号を含んでいる。ディスクリプション内の各種のＵＲＩは、このＩＰアドレスに対する相対アドレスとして記述されている。なお、本明細書において、「ＵＲＩ」（又はＵＲＬ）という用語は、絶対アドレスで記述されている場合と、相対アドレスで記述されている場合の両方を含んでいる。以下では、ＩＰアドレスに対する相対アドレスを「パス名」と呼ぶ。
要素<root>の下には一つの要素<device>が存在し、この要素の中にさらに２つの要素<device>が包含されている。１つ目の要素<device>はプリンタデバイス（ルートデバイス）であり、その下位にある２番目と３番目のデバイスはスキャナデバイスとストレージデバイスである。
プリンタデバイス用のディスクリプションには、以下の内容が記述されている。
・<presentation URL>：コントロールポイントがプリンタデバイスのプレゼンテーション用のページを取得する際のＵＲＬ。このＵＲＬは、パス名”/PRESENTATION/PRINTER”で構成されている。
・<serviceList> :プリンタデバイスが提供するサービスのリスト。
・<serviceType>：プリンタが提供するサービスのタイプ。”PrintBasic”，”PrintEnhanced”は、いずれもＵＰｎＰアーキテクチャの標準的なプリントサービスである。
・<SCPDURL>：プリンタのデバイスディスクリプションのパス名。
・<controlURL>：プリンタデバイス内のコントロールサーバのパス名。コントロールサーバは、コントロールポイントに対してコントロール（コントロールポイントがアクション要求を含む制御メッセージをデバイスに転送して、デバイスの制御を行う処理）の機能を提供するサーバであり、一般にＵＰｎＰデバイスのサービス内に設けられている。
・<eventSubURL>：プリンタデバイス内のイベントサーバのパス名。イベントサーバは、サブスクライブ（購読）しているコントロールポイントにイベントを発行するサーバであり、一般にデバイスのサービス内に設けられている。
・<presentation URL>：コントロールポイントがプリンタデバイスのプレゼンテーション用のページを取得する際のＵＲＬ。このＵＲＬは、パス名”/PRESENTATION/PRINTER”で構成されている。
・<serviceList> :プリンタデバイスが提供するサービスのリスト。
・<serviceType>：プリンタが提供するサービスのタイプ。”PrintBasic”，”PrintEnhanced”は、いずれもＵＰｎＰアーキテクチャの標準的なプリントサービスである。
・<SCPDURL>：プリンタのデバイスディスクリプションのパス名。
・<controlURL>：プリンタデバイス内のコントロールサーバのパス名。コントロールサーバは、コントロールポイントに対してコントロール（コントロールポイントがアクション要求を含む制御メッセージをデバイスに転送して、デバイスの制御を行う処理）の機能を提供するサーバであり、一般にＵＰｎＰデバイスのサービス内に設けられている。
・<eventSubURL>：プリンタデバイス内のイベントサーバのパス名。イベントサーバは、サブスクライブ（購読）しているコントロールポイントにイベントを発行するサーバであり、一般にデバイスのサービス内に設けられている。
スキャナ用及びストレージ用のディスクリプションにも、プリンタ用のものと同様な項目が記述されている。なお、デバイスディスクリプションには、この他にデバイスのフレンドリ名や、製造者名、モデル名、アイコンなどの種々のプロパティが記述されているが、ここでは図示が省略されている。
D．プリンタデバイス以外のサービスデバイスへのデータ転送シーケンス：
図１０は、ＵＰｎＰプロトコルに従ってストレージデバイスにメッセージを転送する手順を示すシーケンス図である。ステップ[1]では、コントロールポイント１１０ＣからＭＦＰサーバ３００に、ＵＰｎＰプロトコルに従ってリクエストメッセージＦ１１が転送される。このメッセージＦ１１には、リクエスト命令のメソッド（ＰＯＳＴメソッド）と、宛先のパス名”/DOWN/PRINTER/CDH”と、複合機２００のＩＰアドレス”169.254.100.100”とが記述されている。
図１０は、ＵＰｎＰプロトコルに従ってストレージデバイスにメッセージを転送する手順を示すシーケンス図である。ステップ[1]では、コントロールポイント１１０ＣからＭＦＰサーバ３００に、ＵＰｎＰプロトコルに従ってリクエストメッセージＦ１１が転送される。このメッセージＦ１１には、リクエスト命令のメソッド（ＰＯＳＴメソッド）と、宛先のパス名”/DOWN/PRINTER/CDH”と、複合機２００のＩＰアドレス”169.254.100.100”とが記述されている。
宛先のパス名”/DOWN/PRINTER/CDH”の前半部分”/DOWN/PRINTER”は、プリンタデバイス用のUPNP-DOWNCONTENTxチャンネルを用いることを意味しており、後半部分”CDH”は最終的な宛先がストレージデバイスであることを意味している。最終的な宛先がスキャナデバイスである場合には、宛名のパス名の後半部分は、スキャナデバイスを示す名前（例えば”/SCN”）となる。また、最終的な宛先がプリンタデバイスである場合には、宛名のパス名は”/DOWN/PRINTER”となる。
このように、コントロールポイントは、ＵＰｎＰプロトコルを用いて、複合機２００のプリンタデバイス以外のサービスデバイス宛てにメッセージを送信することができる。この際、メッセージの宛名は、プリンタデバイス用の特定の論理チャンネルを使用することを意味する部分と、プリンタデバイス以外の他のサービスデバイスが最終的な宛先であることを意味する部分とを含むことが好ましい。
ステップ[2]では、ＭＦＰサーバ３００が、このメッセージＦ１１のヘッダを解析し、ＰＯＳＴ処理のデータ転送に使用するリクエストＩＤをＭＦＰデバイスユニット４００から取得する必要があることを判断する。リクエストＩＤは、コンテンツデータをＭＦＰサーバ３００からＭＦＰデバイスユニット４００に転送する際に、すべてのＤ４パケットのヘッダ（図６）に付して、他のメッセージのパケットと区別するために使用されるＩＤである。ステップ[3]では、ＭＦＰサーバ３００が、リクエストＩＤを要求するメッセージＦ１２をＭＦＰデバイスユニット４００に転送する。このメッセージＦ１２のボディには、リクエスト命令のメソッド（ＰＯＳＴメソッド）と、宛先のパス名”/DOWN/PRINTER/CDH”とが記述されている。また、メッセージＦ１２の転送には、UPNP-LOCALCONTROLチャンネルが使用される。図５で説明したように、コンテンツデータの転送に使用されるチャンネルとしては、コンテンツチャンネル（UPNP-DOWNCONTENTxチャンネルとUPNP-UPCONTENTxチャンネル）があるが、これらのコンテンツチャンネルは、コンテンツデータそのものを転送するためにのみ使用される。そこで、図１０の例では、リクエストＩＤの取得要求のメッセージＦ１２の転送には、UPNP-LOCALCONTROLチャンネルが利用される。このチャンネルは、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の間において、ＭＦＰサーバ３００を要求者とし、ＭＦＰデバイスユニット４００を応答者とする通信を行う場合に使用されるチャンネルである。ＭＦＰサーバ３００のネットワークプロトコル制御部３０２内には、ＨＴＴＰリクエストの宛先の最上位パス名”/DOWN”とUPNP-LOCALCONTROLチャンネルとの対応関係が予め設定されている。図１０のステップ[3]では、ＭＦＰサーバ３００がこの対応関係を参照してUPNP-LOCALCONTROLチャンネルを用いることを決定し、リクエストＩＤを要求するメッセージＦ１２をＭＦＰデバイスユニット４００に転送する。
ステップ[4]では、ＭＦＰデバイスユニット４００が、このメッセージＦ１２の要求に従ってリクエストＩＤを生成し、また、Ｎdown個のUPNP-DOWNCONTENTxチャンネルのうちの１つを指定するためのチャンネルＩＤも生成する。チャンネルＩＤの値としては、例えば、その時点で使用されていないUPNP-DOWNCONTENTxチャンネルのチャンネルＩＤの中で最も小さな値が割り当てられる。なお、リクエストＩＤとチャンネルＩＤの生成は、デバイス制御部４０２（図１）によって行われる。ステップ[5]では、ＭＦＰデバイスユニット４００からＭＦＰサーバ３００に、リクエストＩＤとチャンネルＩＤを含むメッセージＲ１１が返信される。この際にも、UPNP-LOCALCONTROLチャンネルが使用される。
こうしてリクエストＩＤとチャンネルＩＤがＭＦＰサーバ３００に通知され、また、ステップ[6]においてＭＦＰサーバ３００がコンテンツデータの受信を完了すると、ステップ[7]において、ＭＦＰサーバ３００がコンテンツデータ（例えばＪＰＥＧデータ）を含むメッセージＦ１３をＭＦＰデバイスユニット４００に転送する。このメッセージＦ１３の各パケットのヘッダには、ステップ[5]で通知されたリクエストＩＤが記入されている。また、論理チャンネルとしては、Ｎdown個のUPNP-DOWNCONTENTxチャンネルの中で、チャンネルＩＤで指定された１つのチャンネルが使用される。図１０の例では、チャンネルＩＤの値が”１”なので、１番目のチャンネルUPNP-DOWNCONTENT1が使用されている。ＭＦＰデバイスユニット４００は、メッセージＦ１３のリクエストＩＤを参照することによって、これらのパケットがステップ[3]で要求された処理のためのパケットであることを容易に認識することができる。また、コンテンツデータの送信処理の際には、予め設けられたＮdown個の論理チャンネルUPNP-DOWNCONTENTxのうちの１つを１つのコンテンツに割り当てるので、多数のコンテンツ送信処理を並行して行うことが可能である。
ステップ[8]では、こうしてＭＦＰデバイスユニット４００に転送されたコンテンツデータが、最終的な宛先であるストレージデバイスに格納される。コンテンツデータの格納が終了すると、ステップ[9]において、処理が完了したことを示すレスポンスメッセージＲ１２がＭＦＰデバイスユニット４００からＭＦＰサーバ３００に転送される。ステップ[10]では、ＭＦＰサーバ３００がメッセージＲ１２のエラーコードを参照し、これに応じてＨＴＴＰのヘッダを付加する。ステップ[11]では、こうして作成されたＨＴＴＰのレスポンスメッセージＲ１３がＭＦＰサーバ３００からコントロールポイント１１０Ｃに転送される。
前述したように、プリンタデバイス宛てにコンテンツデータを転送する場合には、メッセージの宛名が、図１０に示したメッセージＦ１１の宛名のパス名の最後の部分”/CDH”が無いもの（”/DOWN/PRINTER”）になる。このとき、ステップ[8]では、ストレージデバイスでは無く、プリンタデバイスにコンテンツデータが転送される。他の点は、図１０のシーケンスと同じである。
図１１は、ＵＰｎＰプロトコルに従ってストレージデバイスにメッセージを転送する経路を示す説明図である。破線で示すように、コントロールポイントからのメッセージは、ＭＦＰサーバ３００内において、ＴＣＰ／ＩＰ層と、ＵＰｎＰデバイスアーキテクチャ１１００とを介してサービスプロトコル解釈部１０００に供給される。サービスプロトコル解釈部１０００は、このメッセージのヘッダ部を解釈して転送先を判断する。このメッセージは、Ｄ４パケット処理部１３００でパケット化された後、プリンタクラスドライバ１３１０を介してＵＳＢ転送される。
宛先がＵＰｎＰストレージデバイスであった場合には、ＭＦＰデバイスユニット４００に送られたメッセージは、プリンタクラスドライバ２３１０と、Ｄ４パケット処理部２３００とを介してＵＰｎＰデバイス機能部２４００のストレージデバイスに供給される。
なお、ＵＰｎＰプロトコルに従ってスキャナデバイス宛てにメッセージを転送する際にも、図１１と同様にプリンタクラスを用いて転送が実行される。このように、ＵＰｎＰプロトコルに従ってプリントデバイス以外のサービスデバイス宛てにメッセージを転送する際にプリンタクラスを用いることができる。この利点は以下の通りである。一般に、メモリカードのためのＵＳＢクラスとしては、マスストレージクラスを利用可能である。しかし、マスストレージクラスでは、ホストからは一時に一つのメッセージしか転送できず、複数のメッセージを並行して転送することはできない。これは、スキャナクラスも同様である。一方、プリンタクラスでは、Ｄ４パケットが用いた通信が標準的であり、Ｄ４パケットの構造はある程度任意に設計可能である。従って、プリンタクラスでは、ホストから複数のメッセージを並行して転送することが可能である。このとき、複数のメッセージの区別は、例えば図１０で説明したリクエストＩＤによって行うことができる。ＵＰｎＰプロトコルでは、複数のコントロールポイントから同じサービスデバイス宛てに同時にメッセージが転送される場合がある。ＵＳＢのマスストレージクラスやスキャナクラスでは、一時に１つのコントロールポイントからのメッセージしか転送できないので不便である。そこで、上述したように、Ｄ４パケットを用いるプリンタクラスを利用すれば、複数のコントロールポイントからのメッセージを同じサービスデバイスに並行して転送することができるという利点がある。
図１２は、ＵＰｎＰプロトコルで無いネットワークプロトコルに従ってストレージデバイスにメッセージを転送する経路を示す説明図である。ここでは、ＭＦＰデバイスユニット４００のストレージデバイス４０８がＬＡＮ上の記憶装置として認識されており、ネットワーク上のクライアント（例えば図１のパーソナルコンピュータ１００）から、このストレージデバイス４０８にアクセスする場合を想定している。このとき、クライアントからのメッセージは、ＴＣＰ／ＩＰ層と、非ＰｎＰストレージ機能部１２３０を介してサービスプロトコル解釈部１０００に供給される。サービスプロトコル解釈部１０００は、このメッセージのヘッダ部を解釈して転送先を判断する。このメッセージは、ストレージクラスドライバ１３３０を介してＵＳＢ転送される。ＭＦＰデバイスユニット４００に送られたメッセージのメッセージボディは、ストレージクラスドライバ２３３０を介して非ＵＰｎＰストレージ機能部２２３０に供給される。
このように、ＵＰｎＰプロトコル以外のネットワークプロトコルに従ってプリンタデバイス以外のデバイス宛てに転送されてきたメッセージは、プリンタクラスを利用せずに、それぞれのデバイス用のデバイスクラスを利用して転送される。従って、例えば、ＵＰｎＰプロトコルに従ったストレージデバイスへのメッセージ転送（図１１）と、ＵＰｎＰプロトコル以外のネットワークプロトコルに従ってストレージデバイスへのメッセージ転送（図１２）とを、並行して実行することが可能である。
E．変形例：
なお、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。
なお、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。
E１．変形例１：
上記実施例では、プリンタデバイス以外の種類のサービスデバイスとして、スキャナとストレージとを用いていたが、複合機は、プリンタデバイス以外の種類のサービスデバイスとして少なくとも１つのデバイスを有していれば良い。
上記実施例では、プリンタデバイス以外の種類のサービスデバイスとして、スキャナとストレージとを用いていたが、複合機は、プリンタデバイス以外の種類のサービスデバイスとして少なくとも１つのデバイスを有していれば良い。
E２．変形例２：
パケット化された論理チャンネルを用いるデバイスとしては、プリンタ以外の任意の種類のデバイスも使用することが可能である。例えば、スキャナ用のパケット化された論理チャンネルを用いるようにしてもよい。このとき、他の種類のデバイス（例えばストレージ）のメッセージの転送の際に、スキャナ用のパケット化された論理チャンネルを使用することができる。
パケット化された論理チャンネルを用いるデバイスとしては、プリンタ以外の任意の種類のデバイスも使用することが可能である。例えば、スキャナ用のパケット化された論理チャンネルを用いるようにしてもよい。このとき、他の種類のデバイス（例えばストレージ）のメッセージの転送の際に、スキャナ用のパケット化された論理チャンネルを使用することができる。
また、ネットワーク制御部３０２とデバイス制御部４０２との間の物理的な接続は、ＵＳＢに限らず、任意の形態で接続することが可能である。例えば、これらの制御部３０２，４０２をバスを介して接続するようにしてもよい。但し、ＵＳＢ接続を利用すれば、パケット化された論理チャンネルを容易に構成できるという利点がある。
E３．変形例３：
上記実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。
上記実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。
１００…パーソナルコンピュータ
１００Ｄ…プリンタドライバ
１１０…デジタルカメラ
１１０Ｃ…コントロールポイント
１２０…ＴＶセット
１２０Ｃ…コントロールポイント
１３０…画像サーバ
２００…複合機
３００…ＭＦＰサーバ
３０２…ネットワークプロトコル制御部
３１０…中央制御部
３２０…ＲＡＭ
３３０…ＲＯＭ
３４０…ネットワーク制御部
３４２…コネクタ
３５０…ＵＳＢホスト制御部
３５２…ルートハブ
３５４，３５６…ＵＳＢコネクタ
４００…ＭＦＰデバイスユニット
４０２…デバイス制御部
４０４…プリンタ
４０６…スキャナ
４０８…ストレージ
４１０…中央制御部
４２０…ＲＡＭ
４３０…ＲＯＭ
４４０…印刷エンジン
４５０…スキャナエンジン
４６０…ＵＳＢデバイス制御部
４６２…ＵＳＢコネクタ
４７０…ＵＳＢデバイス制御部
４７２…ＵＳＢコネクタ
４８０…ＰＣカードインタフェース
４８２…スロット
４９０…操作パネル制御部
４９２…操作パネル
５００…ビューワ制御部
５０２…ビューワ
５１０…ＵＳＢホスト制御部
５１２…ルートハブ
５１４…ＵＳＢコネクタ
１０００…サービスプロトコル解釈部
１１００…ＵＰｎＰデバイスアーキテクチャ
１２１０…非ＵＰｎＰプリンタ機能部
１２２０…非ＵＰｎＰスキャナ機能部
１２３０…非ＵＰｎＰストレージ機能部
１３１０…ＵＳＢプリンタクラスドライバ
１３２０…ＵＳＢスキャナクラスドライバ
１３３０…ＵＳＢストレージクラスドライバ
２２１０…非ＵＰｎＰプリンタ機能部
２２２０…非ＵＰｎＰスキャナ機能部
２２３０…非ＵＰｎＰストレージ機能部
２３１０…ＵＳＢプリンタクラスドライバ
２３２０…ＵＳＢスキャナクラスドライバ
２３３０…ＵＳＢストレージクラスドライバ
２４００…ＵＰｎＰデバイス機能部
１００Ｄ…プリンタドライバ
１１０…デジタルカメラ
１１０Ｃ…コントロールポイント
１２０…ＴＶセット
１２０Ｃ…コントロールポイント
１３０…画像サーバ
２００…複合機
３００…ＭＦＰサーバ
３０２…ネットワークプロトコル制御部
３１０…中央制御部
３２０…ＲＡＭ
３３０…ＲＯＭ
３４０…ネットワーク制御部
３４２…コネクタ
３５０…ＵＳＢホスト制御部
３５２…ルートハブ
３５４，３５６…ＵＳＢコネクタ
４００…ＭＦＰデバイスユニット
４０２…デバイス制御部
４０４…プリンタ
４０６…スキャナ
４０８…ストレージ
４１０…中央制御部
４２０…ＲＡＭ
４３０…ＲＯＭ
４４０…印刷エンジン
４５０…スキャナエンジン
４６０…ＵＳＢデバイス制御部
４６２…ＵＳＢコネクタ
４７０…ＵＳＢデバイス制御部
４７２…ＵＳＢコネクタ
４８０…ＰＣカードインタフェース
４８２…スロット
４９０…操作パネル制御部
４９２…操作パネル
５００…ビューワ制御部
５０２…ビューワ
５１０…ＵＳＢホスト制御部
５１２…ルートハブ
５１４…ＵＳＢコネクタ
１０００…サービスプロトコル解釈部
１１００…ＵＰｎＰデバイスアーキテクチャ
１２１０…非ＵＰｎＰプリンタ機能部
１２２０…非ＵＰｎＰスキャナ機能部
１２３０…非ＵＰｎＰストレージ機能部
１３１０…ＵＳＢプリンタクラスドライバ
１３２０…ＵＳＢスキャナクラスドライバ
１３３０…ＵＳＢストレージクラスドライバ
２２１０…非ＵＰｎＰプリンタ機能部
２２２０…非ＵＰｎＰスキャナ機能部
２２３０…非ＵＰｎＰストレージ機能部
２３１０…ＵＳＢプリンタクラスドライバ
２３２０…ＵＳＢスキャナクラスドライバ
２３３０…ＵＳＢストレージクラスドライバ
２４００…ＵＰｎＰデバイス機能部
Claims (5)
- ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
ネットワーク上のクライアントからの要求に応じてサービスを実行する複数のサービスデバイスと、
前記複数のサービスデバイスの制御を行うデバイス制御部と、
メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの内容を前記デバイス制御部に転送するネットワークプロトコル制御部と、
を備え、
前記複数のサービスデバイスは、第１のデバイスと、前記第１のデバイスとは種類の異なる第２のデバイスとを含んでおり、
前記ネットワークプロトコル制御部と前記デバイス制御部とは、前記第１のデバイスのデバイスクラス用の論理チャンネルと、前記第２のデバイスのデバイスクラス用の論理チャンネルと、を介してそれぞれ接続されており、
前記ネットワークプロトコル制御部は、
（ｉ）前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで受信したときに、前記第１のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送し、
（ｉｉ）前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで無いネットワークプロトコルで受信したときには、前記第２のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する、ネットワーク装置。 - 請求項１記載のネットワーク装置であって、
前記第２のデバイス宛のメッセージの宛先のパス名は、前記第１のデバイスのデバイスクラス用の論理チャンネルを使用することを示す第１の部分と、最終的な宛先が前記第２のデバイスであることを示す第２の部分とを含む、ネットワーク装置。 - ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
ネットワーク上のクライアントからの要求に応じてサービスを実行する複数のサービスデバイスと、
前記複数のサービスデバイスの制御を行うデバイス制御部と、
メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの内容を前記デバイス制御部に転送するネットワークプロトコル制御部と、
を備え、
前記複数のサービスデバイスは、第１のデバイスと、前記第１のデバイスとは種類の異なる第２のデバイスとを含んでおり、
前記ネットワークプロトコル制御部と前記デバイス制御部とは、前記第１のデバイスのデバイスクラス用の論理チャンネルを介して接続されており、
前記第２のデバイス宛のメッセージの宛先のパス名は、前記第１のデバイスのデバイスクラス用の論理チャンネルを使用することを示す第１の部分と、最終的な宛先が前記第２のデバイスであることを示す第２の部分とを含み、
前記ネットワークプロトコル制御部は、前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで受信したときに、前記第１のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する、ネットワーク装置。 - ネットワーク上のクライアントからの要求に応じてサービスを実行する複数のサービスデバイスと、前記複数のサービスデバイスの制御を行うデバイス制御部と、前記ネットワーク上のクライアントから受信したメッセージを前記デバイス制御部に転送するネットワークプロトコル制御部とを含むネットワーク型プラグアンドプレイに対応したネットワーク装置を制御する方法であって、
前記複数のサービスデバイスは、第１のデバイスと、前記第１のデバイスとは種類の異なる第２のデバイスとを含んでおり、
前記ネットワークプロトコル制御部と前記デバイス制御部とは、前記第１のデバイスのデバイスクラス用の論理チャンネルと、前記第２のデバイスのデバイスクラス用の論理チャンネルと、を介してそれぞれ接続されており、
前記方法は、
（ａ）メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信する工程と、
（ｂ）前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する工程と、
を備え、
前記工程（ｂ）は、前記ネットワークプロトコル制御部が、
（ｉ）前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで受信したときに、前記第１のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する工程と、
（ｉｉ）前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで無いネットワークプロトコルで受信したときには、前記第２のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する工程と、
を含む、方法。 - ネットワーク上のクライアントからの要求に応じてサービスを実行する複数のサービスデバイスと、前記複数のサービスデバイスの制御を行うデバイス制御部と、前記ネットワーク上のクライアントから受信したメッセージを前記デバイス制御部に転送するネットワークプロトコル制御部とを含むネットワーク型プラグアンドプレイに対応したネットワーク装置を制御する方法であって、
前記複数のサービスデバイスは、第１のデバイスと、前記第１のデバイスとは種類の異なる第２のデバイスとを含んでおり、
前記ネットワークプロトコル制御部と前記デバイス制御部とは、前記第１のデバイスのデバイスクラス用の論理チャンネルを介して接続されており、
前記方法は、
（ａ）メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信する工程と、
（ｂ）前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する工程と、
を備え、
前記第２のデバイス宛のメッセージの宛先のパス名は、前記第１のデバイスのデバイスクラス用の論理チャンネルを使用することを示す第１の部分と、最終的な宛先が前記第２のデバイスであることを示す第２の部分とを含み、
前記工程（ｂ）は、前記ネットワークプロトコル制御部が、前記第２のデバイス宛てのメッセージを前記ネットワーク型プラグアンドプレイのプロトコルで受信したときに、前記第１のデバイスのデバイスクラス用の論理チャンネルを利用して前記受信したメッセージのメッセージボディの内容を前記デバイス制御部に転送する工程を含む、方法。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005261979A JP4765496B2 (ja) | 2005-09-09 | 2005-09-09 | ネットワーク型プラグアンドプレイに対応したネットワーク装置及びその制御方法 |
| EP06254584A EP1763198A3 (en) | 2005-09-07 | 2006-09-04 | Control of network plug-and-play compliant device |
| US11/517,439 US7664135B2 (en) | 2005-09-07 | 2006-09-06 | Control of network plug-and-play compliant device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005261979A JP4765496B2 (ja) | 2005-09-09 | 2005-09-09 | ネットワーク型プラグアンドプレイに対応したネットワーク装置及びその制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2007072953A JP2007072953A (ja) | 2007-03-22 |
| JP4765496B2 true JP4765496B2 (ja) | 2011-09-07 |
Family
ID=37934317
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005261979A Expired - Fee Related JP4765496B2 (ja) | 2005-09-07 | 2005-09-09 | ネットワーク型プラグアンドプレイに対応したネットワーク装置及びその制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4765496B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5131463B2 (ja) * | 2008-03-13 | 2013-01-30 | セイコーエプソン株式会社 | 電子機器システム及び電子機器システムにおける制御方法 |
| JP5163193B2 (ja) * | 2008-03-13 | 2013-03-13 | セイコーエプソン株式会社 | プリンタシステム及びプリンタシステムにおける制御方法 |
| JP6025547B2 (ja) * | 2012-12-21 | 2016-11-16 | キヤノンイメージングシステムズ株式会社 | 情報処理装置、デバイス制御装置、およびその制御方法、並びにデバイス制御システム |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6412022B1 (en) * | 1998-09-30 | 2002-06-25 | Hewlett-Packard Company | Simultaneous print and scan logical channel network multifunction peripheral |
| JP2001094621A (ja) * | 1999-09-21 | 2001-04-06 | Canon Inc | 通信制御回路および方法 |
| JP3791290B2 (ja) * | 2000-02-29 | 2006-06-28 | 富士ゼロックス株式会社 | 通信装置及び通信方法 |
| US20020083143A1 (en) * | 2000-12-13 | 2002-06-27 | Philips Electronics North America Corporation | UPnP architecture for heterogeneous networks of slave devices |
| US7058088B2 (en) * | 2001-03-28 | 2006-06-06 | Minolta Co., Ltd. | Data communication program product to rewrite simultaneously firmware of plurality of devices connected to network |
| JP4238618B2 (ja) * | 2003-03-28 | 2009-03-18 | ブラザー工業株式会社 | 複合機 |
-
2005
- 2005-09-09 JP JP2005261979A patent/JP4765496B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2007072953A (ja) | 2007-03-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4645164B2 (ja) | ネットワーク型プラグアンドプレイに対応したネットワーク装置の制御 | |
| US7664135B2 (en) | Control of network plug-and-play compliant device | |
| JP4508114B2 (ja) | ネットワーク型プラグアンドプレイに対応したネットワーク中継制御 | |
| US7594040B2 (en) | Network relay device having network plug-and-play compliant protocols for network relay | |
| US20060150236A1 (en) | Control of network plug-and-play compliant device | |
| US7869073B2 (en) | Image forming system, image forming method and information terminal device | |
| JP4741768B2 (ja) | ネットワーク制御装置、ネットワーク制御方法及びプログラム | |
| JP4774973B2 (ja) | ネットワーク型プラグアンドプレイに対応したネットワーク中継制御 | |
| US6431772B1 (en) | Broadcast printing system and method | |
| JP5063253B2 (ja) | ネットワークシステムおよび通信方法 | |
| US8259332B2 (en) | Printing apparatus and printing system | |
| JP4765496B2 (ja) | ネットワーク型プラグアンドプレイに対応したネットワーク装置及びその制御方法 | |
| JP4760425B2 (ja) | プリンタを用いた印刷におけるスタイルシートの切替 | |
| JP2007156691A (ja) | ネットワーク型プラグアンドプレイに対応したネットワーク中継制御 | |
| EP2390782A2 (en) | Method and apparatus for forming an image | |
| JP4935027B2 (ja) | ネットワーク型プラグアンドプレイに対応したネットワーク装置及びその制御方法 | |
| JP4640147B2 (ja) | ネットワーク型プラグアンドプレイに対応したネットワーク中継制御 | |
| JP4378372B2 (ja) | 情報処理方法、情報処理装置、及び記憶媒体 | |
| JP2007080126A (ja) | ネットワーク型プラグアンドプレイに対応したネットワーク装置の制御 | |
| JP2007128215A (ja) | ネットワークデバイスに関する情報収集 | |
| JP2007072795A (ja) | Ｕｓｂ論理チャンネルのオープン制御 | |
| JP2005157540A (ja) | 印刷プロトコル変換装置及びデータ蓄積デバイス | |
| JP2004157960A (ja) | 印刷データ転送方法、印刷システム及びプリンタ装置 | |
| JP4665705B2 (ja) | ネットワークプリンタにおけるデータ通信用クレジットの取得 | |
| JP2008193381A (ja) | オーダーシート、オーダーシートの作成方法、オーダーシートを用いた処理方法、及び、それらのための装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080212 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100827 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100831 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101101 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110517 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110530 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4765496 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140624 Year of fee payment: 3 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |