JP2007072793A - ネットワーク型プラグアンドプレイに対応したネットワーク装置の制御 - Google Patents

Abstract

【課題】 ネットワーク型プラグアンドプレイに対応したネットワーク装置における制御を単純化できる技術を提供する。
【解決手段】 ネットワークプロトコル制御部３０２は、リクエストの宛先の最上位パス名に応じて論理チャンネルを選択する。デバイス制御部４０２は、リクエストの宛先の下位パス名に応じてデータの転送先のデバイス／サービスを切り換える。
【選択図】 図１０

Description

この発明は、ネットワーク型プラグアンドプレイに対応したネットワーク装置の制御技術に関する。

プラグアンドプレイは、よく知られているように、コンピュータの起動後に、周辺装置を任意のタイミングでコンピュータに接続したり、コンピュータから切断したりすることができる技術である。近年では、プラグアンドプレイ技術をネットワークに適用したものとして、ユニバーサルプラグアンドプレイ（以下、「ＵＰｎＰ」と呼ぶ。ＵＰｎＰは UPnP Implementers Corporationの商標）が開発されてきている。ＵＰｎＰを用いると、ネットワーク装置を任意のタイミングでネットワークに接続したり、ネットワークから切断したりすることができる。本明細書では、ＵＰｎＰのように、ネットワークにおいてプラグアンドプレイを実現するアーキテクチャを、「ネットワーク型プラグアンドプレイ」と呼ぶ。

特開２００１−２９０７２４

ＵＰｎＰ対応のネットワーク装置は、種々のサービスデバイスとして機能することが可能である。ここで、「サービスデバイス」とは、外部からの要求に応じてサービスを実行するデバイスを意味している。サービスデバイスは、プリンタや、スキャナ、ファクシミリ、コピー機、記憶装置、カメラ、時計などの種々の装置として実現可能である。また、１つの装置で複数のサービスデバイスの機能を実現することも可能である。

このように、ＵＰｎＰ対応のネットワーク装置は多様な形態を採り得る。しかし、その反面、ネットワーク装置の制御が複雑になり易いという問題があった。

本発明は、ネットワーク型プラグアンドプレイに対応したネットワーク装置における制御を単純化することのできる技術を提供することを目的とする。

本発明は、ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
ネットワーク上のクライアントからの要求に応じてサービスを実行する１つ以上のサービスデバイスと、
前記サービスデバイスの制御を行うデバイス制御部と、
メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの情報を前記デバイス制御部に転送するネットワークプロトコル制御部と、
を備え、
前記ネットワークプロトコル制御部と前記デバイス制御部とは、複数の論理チャンネルで接続されており、
前記ネットワークプロトコル制御部は、前記クライアントから受信したメッセージの宛先であるパス名のうちの最上位層の名前である最上位パス名に応じて前記複数の論理チャンネルの１つを選択し、選択された論理チャンネルを用いて前記メッセージボディの内容を前記デバイス制御部に転送する。

このネットワーク装置によれば、ネットワークプロトコル制御部が最上位パス名に応じて論理チャンネルを選択してデバイス制御部にメッセージボディを送信するので、ネットワークプロトコル制御部における制御を単純化することができる。

なお、前記デバイス制御部は、複数の前記サービスデバイスを含んでおり、
前記ネットワークプロトコル制御部は、前記メッセージボディの情報の他に前記メッセージのパス名も前記デバイス制御部に転送し、
前記デバイス制御部は、前記メッセージのパス名のうちの前記最上位層よりも下位の名前である下位パス名に応じて前記複数のサービスデバイスのうちの１つを選択し、選択されたサービスデバイスに前記メッセージボディの情報を供給するものとしてもよい。

この構成によれば、下位パス名に応じて適切なサービスデバイスを容易に選択することができる。

前記複数のサービスデバイスのうちの少なくとも１つの特定のサービスデバイスは、複数のサービスを実行するための複数のサービスモジュールを有しており、
前記デバイス制御部は、前記下位パス名が前記特定のサービスデバイスを示すデバイス名と、前記複数のサービスモジュールのうちの１つを示すサービス名とを含む場合に、前記サービス名に応じて前記複数のサービスモジュールのうちの１つを選択し、選択されたサービスモジュールに前記メッセージボディの情報を供給するようにしてもよい。

この構成によれば、下位パス名に応じて適切なサービスモジュールを容易に選択することができる。

前記複数の論理チャンネルは、例えばＤ４パケットを利用したＵＳＢ転送用の論理チャンネルとすることが好ましい。

この構成によれば、Ｄ４パケットのヘッダ部を利用して多様な論理チャンネルを構成できるので、多様な論理チャンネルを用いて多様なデータ転送を実現することが可能である。

なお、本発明は、種々の形態で実現することが可能であり、例えば、ネットワーク装置、ネットワークプロトコル制御装置、それらの装置の制御方法及び制御装置、それらの方法または装置の機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体、そのコンピュータプログラムを含み搬送波内に具現化されたデータ信号、等の形態で実現することができる。

次に、本発明の実施の形態を以下の順序で説明する。
A．用語の説明：
B．システムの概要：
C．複合機のデバイス構成及びデバイスディスクリプション：
D．データ転送の概要：
E．各種のデータ転送シーケンス：
F．他の実施例：
G．変形例：

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）：拡張マークアップ言語。

なお、ＵＰｎＰでは上述した多数のプロトコルが使用されるが、以下ではこれらを総称して「ＵＰｎＰプロトコル」と呼ぶ。

B．システムの概要：
図１は、本発明の実施例を適用するネットワークシステムの構成を示す概念図である。このネットワークシステムは、パーソナルコンピュータ１００と、デジタルカメラ１１０と、ＴＶセット１２０と、画像サーバ１３０と、複合機２００とがＬＡＮを介して相互に接続された構成を有している。ＬＡＮは、ＩＥＥＥ８０２．３のような有線ネットワークでも、ＩＥＥＥ８０２．１１ｂ／ｇ／ａなどの無線ネットワークでもよい。デジタルカメラ１１０と、ＴＶセット１２０と、複合機２００とは、ＵＰｎＰ対応のネットワーク装置である。デジタルカメラ１１０とＴＶセット１２０は、ＵＰｎＰアーキテクチャにおけるコントロールポイント１１０Ｃ，１２０Ｃを備えている。ＵＰｎＰアーキテクチャ及びコントロールポイントについては後述する。パーソナルコンピュータ１００と画像サーバ１３０もこのネットワークシステムの構成要素の１つであるが、ＵＰｎＰには対応していない。

パーソナルコンピュータ１００は、プリンタドライバ１００Ｄを用いて画像の印刷データを作成し、ＬＡＮを介してこの印刷データを複合機２００に転送して印刷を実行させる機能を有している。この印刷処理の際には、複合機２００はＵＰｎＰのプロトコルを使用せず、通常のネットワークプリンタとして機能する。一方、コントロールポイント（例えば１１０Ｃ）からの要求に従って印刷を行う場合には、複合機２００はＵＰｎＰ対応のプリンタデバイスとして機能する。

複合機２００は、ＭＦＰサーバ３００と、ＭＦＰデバイスユニット４００とを有している。ＭＦＰサーバ３００は、ＬＡＮ上の他の装置とＭＦＰデバイスユニット４００との間で交換されるメッセージを仲介するネットワークプロトコル制御部３０２としての機能を有している。後述するように、ＭＦＰサーバ３００は、典型的な場合において、メッセージの転送の際にメッセージヘッダに関してＵＰｎＰのプロトコルを解釈するが、メッセージボディの解釈や処理は行わない。ＭＦＰデバイスユニット４００は、３つのサービスデバイス（プリンタ４０４，スキャナ４０６，ストレージ４０８）と、これらを制御するデバイス制御部４０２とを備えている。なお、プリンタ４０４，スキャナ４０６，ストレージ４０８以外のサービスデバイスを追加することも可能である。ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間は、ＵＳＢ（Universal Serial Bus）で接続されている。但し、両者の間をＵＳＢ以外の他の物理的インタフェースで接続することも可能である。

ＵＰｎＰは、ネットワーク装置を任意のタイミングでネットワークに接続したり、ネットワークから切断したりすることを実現するアーキテクチャである。ＵＰｎＰネットワークは、コントロールポイント１１０Ｃ，１２０Ｃと、デバイス４０４，４０６，４０８とで構成される。ここで、「デバイス」とは、サービスを提供する装置を意味している。本明細書においては、特に断らない限り、「デバイス」と「サービスデバイス」は同義語として使用されている。「コントロールポイント」は、ネットワーク上の他のデバイスを検出したり制御したりするコントローラを意味しており、サービスデバイスに対するクライアントとして機能する。ＵＰｎＰ対応のネットワーク装置が有する各種の機能については後述する。

図２は、複合機２００の内部構成を示すブロック図である。ＭＦＰサーバ３００は、中央制御部（ＣＰＵ）３１０と、ＲＡＭ３２０と、ＲＯＭ３３０と、ネットワーク制御部３４０と、ＵＳＢホスト制御部３５０とを有している。ネットワーク制御部３４０は、コネクタ３４２を介して有線ネットワークに接続される。ＵＳＢホスト制御部３５０は、ルートハブ３５２を有しており、ルートハブ３５２には２つのＵＳＢコネクタ３５４，３５６が設けられている。第１のＵＳＢコネクタ３５４は、ＵＳＢケーブルを介してＭＦＰデバイスユニット４００のＵＳＢコネクタ４６２に接続されている。第２のＵＳＢコネクタ３５６には、追加のデバイス（例えば無線ＬＡＮネットワークへ通信するための無線通信回路）を接続可能である。

ＭＦＰデバイスユニット４００は、中央制御部（ＣＰＵ）４１０と、ＲＡＭ４２０と、ＲＯＭ４３０と、印刷エンジン４４０と、スキャナエンジン４５０と、２つのＵＳＢデバイス制御部４６０，４７０と、ＰＣカードインタフェース４８０と、操作パネル制御部４９０と、ビューワ制御部５００と、ＵＳＢホスト制御部５１０とを有している。

印刷エンジン４４０は、与えられた印刷データに応じて印刷を実行する印刷機構である。本実施例では、コントロールポイント１１０Ｃ，１２０ＣがＸＨＴＭＬデータに基づいて印刷を行う場合には、中央制御部４１０がＸＨＴＭＬデータを解釈し、色変換やハーフトーン処理を実行して印刷データを作成し、この印刷データを印刷エンジン４４０に供給する。但し、中央制御部４１０の代わりに印刷エンジン４４０が色変換やハーフトーン処理の機能を有するように構成することも可能である。一方、パーソナルコンピュータ１００から印刷を行う場合は、プリンタドライバ１００Ｄが生成するページ記述言語を中央制御部４１０が解析して印刷データを作成し、印刷エンジン４４０に供給する。なお、本明細書において、「印刷データ」とは印刷媒体上におけるドットの形成状態を示すドットデータによって印刷物を表すデータを意味している。印刷データは、プリンタ固有の制御コマンドで構成されている。ＸＨＴＭＬは、印刷データには該当せず、文書を記述する文書記述言語である。スキャナエンジン４５０は、画像をスキャンして画像データを生成する機構である。

ＭＦＰデバイスユニット４００の第１のＵＳＢデバイス制御部４６０は、ＵＳＢコネクタ４６２を介してＭＦＰサーバ３００のＵＳＢホスト制御部３５０に接続されている。第２のＵＳＢデバイス制御部４７０は、ＵＳＢコネクタ４７２を有しており、ここにパーソナルコンピュータなどの任意のＵＳＢホストを接続することが可能である。ＰＣカードインタフェース４８０は、ＰＣカード用のスロット４８２を有している。操作パネル制御部４９０には、入力手段としての操作パネル４９２が接続されている。ビューワ制御部５００には、画像表示手段としてのビューワ５０２が接続されている。ユーザは、ビューワ５０２上に表示された画像やメニューを観察しながら、操作パネル４９２を用いて種々の指示を入力することができる。ＵＳＢホスト制御部５１０は、ルートハブ５１２を有しており、ルートハブ５１２にはＵＳＢコネクタ５１４が設けられている。このコネクタ５１４には、有限責任中間法人カメラ映像機器工業会が策定したＣＩＰＡ ＤＣ−００１−２００３などに準拠したデジタルカメラなどのＵＳＢデバイスを接続することが可能である。

ＭＦＰサーバ３００の中央制御部３１０とネットワーク制御部３４０とＵＳＢホスト制御部３５０は、図１におけるネットワークプロトコル制御部３０２としての機能を実現する。より具体的には、ネットワーク制御部３４０は、各種のネットワークプロトコルに従ってメッセージの送受信を行う。また、中央制御部３１０は、ＵＰｎＰのプロトコルを解釈して転送先を決定する。ＵＳＢホスト制御部３５０は、ＭＦＰデバイスユニット４００との間でメッセージを転送する。これらの制御部３１０，３４０，３５０は、メッセージボディの解釈や処理は行わずにメッセージを転送している。

ＭＦＰデバイスユニット４００のＵＳＢデバイス制御部４６０及び中央制御部４１０は、図１におけるデバイス制御部４０２としての機能を実現する。より具体的には、ＵＳＢデバイス制御部４６０は、ＵＳＢの転送プロトコルに従ってメッセージの送受信を行う。また、中央制御部４１０は、ＭＦＰサーバ３００を介して転送されたメッセージの内容を解釈し、メッセージの内容に応じた処理を実行して、印刷エンジン４４０やスキャナエンジン４５０を動作させる。印刷エンジン４４０は図１のプリンタ４０４のハードウェア部分に相当し、スキャナエンジン４５０は図１のスキャナ４０６のハードウェア部分に対応する。また、ＰＣカードインタフェース４８０のスロット４８２に挿入されたメモリカードは、図１のストレージ４０８のハードウェア部分に相当する。

図３は、ＭＦＰサーバ３００の各種のプロトコルの階層構造を示すブロック図である。ＭＦＰサーバ３００は、各種のネットワークプロトコルを解釈するためのサービスプロトコル解釈部１０００を備えている。このサービスプロトコル解釈部１０００には、ネットワークアーキテクチャの下位層と、ＵＳＢアーキテクチャの下位層とが存在する。ネットワークアーキテクチャの下位層としては、ＵＰｎＰデバイスアーキテクチャ１１００と、３つの非ＵＰｎＰデバイス機能部１２１０，１２２０，１２３０が設けられている。これらのさらに下位には、ＵＤＰ層又はＴＣＰ層と、インターネットプロトコル（ＩＰ）層と、ドライバ層と、ネットワークインタフェース層と、が存在する。

サービスプロトコル解釈部１０００のＵＳＢアーキテクチャの下位層としては、Ｄ４パケット処理部１３００及びＵＳＢプリンタクラスドライバ１３１０と、ＵＳＢスキャナクラスドライバ１３２０と、ＵＳＢストレージクラスドライバ１３３０とが設けられている。これらの３つのデバイスドライバ１３１０，１３２０，１３３０の下位には、ＵＳＢシステムソフトウェアとＵＳＢホストインタフェース（ハードウェア）とが存在する。なお、この図からも理解できるように、ＵＳＢのプリンタクラスドライバ１３１０は、いわゆる「Ｄ４パケット」（ＩＥＥＥ１２８４．４に即したパケット構造）を利用してデータ転送を行うのに対して、スキャナクラスドライバ１３２０やストレージクラスドライバ１３３０ではＤ４パケットは利用されていない。この理由は、標準的なＵＳＢのデバイスクラスのうちで、プリンタクラスではＤ４パケットが上位プロトコルとして採用されているが、スキャナクラス及びストレージクラスでは、Ｄ４パケットを用いない制御スタック（アプリケーション層から物理層に至るまでのアーキテクチャ）がＯＳの標準となっているからである。

ＵＰｎＰデバイスアーキテクチャは、ＨＴＴＰＭＵや、ＨＴＴＰＵ，ＳＯＡＰ／ＨＴＴＰ，ＨＴＴＰなどの各種のプロトコルに従って構成されている。ＵＰｎＰは、これらのプロトコルを用いて、以下のような各種の処理を実現している。

（１）アドレッシング：
ＵＰｎＰデバイス（以下、単に「デバイス」と呼ぶ）がネットワークに接続すると、アドレッシングによってネットワークアドレス（ＩＰアドレス）を取得する。アドレッシングには、ＤＨＣＰサーバまたはAuto-IPが利用される。ネットワークにＤＨＣＰサーバが設けられている場合には、デバイスはＤＨＣＰサーバによって割り当てられるＩＰアドレスを使用する。ＤＨＣＰサーバが無い場合には、Auto-IPと呼ばれる自動ＩＰアドレッシング機能を用いて、デバイスが自分のアドレスを決定する。なお、本実施例では、複合機２００に対して１つのＩＰアドレスのみが割り当てられ、複合機２００全体が単一のネットワーク装置として認識される。

（２）ディスカバリ（検出）：
ディスカバリは、コントロールポイントが、デバイスがどこにいるかを見つけ出す処理である。ディスカバリは、コントロールポイントがディスカバリメッセージをマルチキャストすることによって実現することができ、あるいは、デバイスがネットワークに参加したときに、その旨をコントロールポイントにアドバタイズすることによっても実現できる。ディスカバリは、ＨＴＴＰＭＵ／ＳＳＤＰやＨＴＴＰＵ／ＳＳＤＰを用いて行われる。ディスカバリの結果、コントロールポイントとデバイスがピアツーピアで処理を進められるようになる。

（３）ディスクリプション：
デバイスの構成の詳細は、デバイスディスクリプションとしてＸＭＬで記述されている。また、デバイスのサービスの詳細は、サービスディスクリプションとしてＸＭＬで記述されている。これらのディスクリプションは、デバイスによって所有されており、コントロールポイントに提供される。コントロールポイントは、これらのディスクリプションを参照することによって、デバイスやサービスの詳細を知ることができる。デバイスディスクリプションの例については後述する。

（４）コントロール：
コントロールは、コントロールポイントが、アクション要求を含む制御メッセージをデバイスに転送して、デバイスの制御を行う処理である。コントロールは、ＨＴＴＰ／ＳＯＡＰを用いて行われる。

（５）イベント：
所定のイベントが発生すると、デバイス内のサービスが、コントロールポイントにイベントの発生を通知する。イベント発生の通知を受けるコントロールポイントは、そのサービスに「サブスクライブ（購読）」する。イベントは、サブスクライブしているコントロールポイントに転送される。イベントの通知は、ＨＴＴＰ／ＧＥＮＡを用いて行われる。

（６）プレゼンテーション：
プレゼンテーションは、デバイスディスクリプションに登録されているプレゼンテーション用のＵＲＬからコントロールポイントがＨＴＭＬで記述されたプレゼンテーション用ページを取得する処理である。このプレゼンテーションによって、例えばコントロールポイントがデバイスの各種の状態を表示することができる。

なお、本発明はＵＰｎＰの将来のバージョンにも適用可能である。また、ネットワーク型プラグアンドプレイとして、アドレッシング（自動的なＩＰアドレス決定）と、デバイスのディスカバリにより、任意のコントロールポイントとデバイスとがピアツーピアで通信が可能で、コントロールポイントとデバイスがメッセージの交換を行うアーキテクチャであれば、ＵＰｎＰ以外のネットワーク型プラグアンドプレイ仕様にも本発明を適用することが可能である。

図４は、ＭＦＰデバイスユニット４００の各種プロトコルの階層構造を示すブロック図である。ＭＦＰデバイスユニット４００は、ＵＰｎＰデバイス機能部２４００と、３つの非ＵＰｎＰデバイス機能部２２１０，２２２０，２２３０とを有している。ＵＰｎＰデバイス機能部２４００は、３つのＵＰｎＰデバイスモジュール（図１のプリンタ４０４，スキャナ４０６，ストレージ４０８）を含んでいる。各デバイスモジュール内には、サービスを実行するサービスモジュールが含まれているが、ここでは図示が省略されている。ＵＰｎＰデバイス機能部２４００と非ＵＰｎＰプリンタ機能部２２１０の下位には、Ｄ４パケット処理部２３００及びＵＳＢプリンタクラスドライバ２３１０が存在する。非ＵＰｎＰスキャナ機能部２２２０及び非ＵＰｎＰストレージ機能部２２３０の下位には、ＵＳＢスキャナクラスドライバ２３２０とＵＳＢストレージクラスドライバ２３３０が存在する。３つのデバイスドライバ２３１０，２３２０，２３３０の下位には、ＵＳＢ論理デバイスとＵＳＢデバイスインタフェース（ハードウェア）とが存在する。この階層構造からも理解できるように、ＵＰｎＰスキャナデバイスやＵＰｎＰストレージデバイスがコントロールポイントに対してサービスを行う場合には、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００間では、ＵＳＢプリンタクラスドライバ２３１０を利用してデータ転送が行われる。従って、ＵＰｎＰスキャナデバイスやＵＰｎＰストレージデバイス用のデータ転送の際にも、Ｄ４パケットを利用することができる。

図４に示すように、ＭＦＰサーバ３００のＵＳＢプリンタクラスドライバ１３１０とＭＦＰデバイスユニット４００のＵＳＢプリンタクラスドライバ２３１０の間には、７種類のＵＰｎＰ用双方向通信チャンネルが設けられている。これらは、Ｄ４パケットを用いた論理チャンネルであり、複合機２００がＵＰｎＰデバイスとして機能する場合に使用される。サービスプロトコル解釈部１０００とＵＰｎＰデバイス機能部２４００の間にも、プリンタクラスドライバ１３１０，２３１０の間の７種類の論理チャンネルに対応する７種類のＵＰｎＰ用論理チャンネルが存在するが、図４では図示が省略されている。以下ではまず、Ｄ４パケットを用いた論理チャンネルについて説明する。

図５は、ＵＳＢのインタフェース／エンドポイント構成と論理チャンネルの構成とを示す説明図である。一般に、ＵＳＢデバイスは、インタフェースとエンドポイントとを有している。ＵＳＢの転送は、ＵＳＢのホストとエンドポイントとの間で行われる。すなわち、「エンドポイント」とは、ホストと通信を行う論理的なリソースである。図５（Ａ）の例では、７つのエンドポイントＥＰ＃０〜ＥＰ＃６が示されている。コントロールエンドポイントＥＰ＃０は、標準デバイスリクエストの送受信を行うためのエンドポイントである。「標準デバイスリクエスト」とは、すべてのＵＳＢでサポートする必要がある基本的なリクエストである。従って、コントロールエンドポイントＥＰ＃０は、１つのＵＳＢデバイスに必ず１つ設けられている。

プリンタ用のバルクアウトエンドポイントＥＰ＃１とバルクインエンドポイントＥＰ＃２は、印刷エンジン４４０用のメッセージの受信と送信を行うためのエンドポイントである。同様に、スキャナ用のバルクアウトエンドポイントＥＰ＃３とバルクインエンドポイントＥＰ＃４は、スキャナエンジン４５０用のメッセージの受信と送信を行うためのエンドポイントである。また、ストレージ用のエンドポイントＥＰ＃５，ＥＰ＃６は、メモリーカード用のメッセージの受信と送信を行うためのエンドポイントである。一般に、ＵＳＢデバイスでは、コントロールエンドポイントＥＰ＃０以外のエンドポイントは、論理的なインタフェースによって区分されている。図５（Ａ）の例では、論理的なインタフェースとして、プリンタインタフェースＩＦ＃０とスキャナインタフェースＩＦ＃１とストレージインタフェースＩＦ＃２とが設けられている。

本実施例では、図５（Ｂ）に示すように、プリンタインタフェースＩＦ＃０に９つの論理的なチャンネルが設けられている。これらの各チャンネルの機能は以下の通りである。

（１）PRINT-DATAチャンネルＣＨ＃１１：
ネットワーク上のパーソナルコンピュータ１００から、印刷ポート（ＬＰＲポートに従ったポート番号又はボート番号９１００）を用いてプリンタドライバ１００Ｄ（図１）から転送される印刷データの送受信を行うためのチャンネル。図４には図示されていない。

（２）PRINT-STATUSチャンネルＣＨ＃１２：
ＭＦＰサーバ３００が、印刷エンジン４４０の状態を示す情報を送受信するためのチャンネルであり、ＳＮＭＰ等のプロトコルにより、ＭＦＰサーバ３００からネットワーク上のパーソナルコンピュータ１００に対して提供される。図４には図示されていない。

（３）UPNP-LOCALCONTROLチャンネルＣＨ＃２１：
ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の間において、ＭＦＰサーバ３００を要求者とし、ＭＦＰデバイスユニット４００を応答者とする通信を行うためのＵＰｎＰ用チャンネル。ＭＦＰサーバ３００は、このチャンネルを用いて、ＭＦＰデバイスユニット４００から各種の情報を取得することができる。

（４）UPNP-LOCALEVENTチャンネルＣＨ＃２２：
ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の間において、ＭＦＰデバイスユニット４００を要求者とし、ＭＦＰサーバ３００を応答者とする通信を行うためのＵＰｎＰ用チャンネル。ＭＦＰデバイスユニット４００は、このチャンネルを用いて、例えばユーザが行った設定変更の内容をＭＦＰサーバ３００に通知することができ、また、ＭＦＰデバイスユニット４００が電源ＯＦＦしようとするときに、ＵＰｎＰプロトコルの終了要求をＭＦＰサーバ３００に通知することができる。

（５）UPNP-PRESENTATIONチャンネルＣＨ＃２３：
ＵＰｎＰのプレゼンテーションデータ（Ｗｅｂページデータ）を送受信するためのチャンネル。なお、コントロールポイントの要求に応じてプレゼンテーションデータをＭＦＰデバイスユニット４００からコントロールポイントに送信するためのチャンネル（ダウンチャンネル）と、新たなプレゼンテーションデータをコントロールポイントからＭＦＰデバイスユニット４００にアップロードするためのチャンネル（アップチャンネル）とを別々に設けるようにしたもよい。

（６）UPNP-CONTROLチャンネルＣＨ＃２４：
ＵＰｎＰにおいて、コントロールポイントから発信されたアクションに関連するデータを送受信するためのチャンネル。なお、上述のUPNP-LOCALCONTROLチャンネルに”LOCAL”という接頭語が付されている理由は、UPNP-LOCALTONTROLチャンネルが、コントロールポイントからのアクションの内容の転送には使用されないからである。換言すれば、UPNP-CONTROLチャンネルＣＨ＃２４は、コントロールポイントから発信されたアクションに関連するデータの送受信のためにのみ使用される。

（７）UPNP-EVENTチャンネルＣＨ＃２５：
ＵＰｎＰにおいて、イベントをサブスクライブしているコントロールポイントに送信するためのチャンネル。上述のUPNP-LOCALEVENTチャンネルに”LOCAL”という接頭語が付されている理由は、このUPNP-LOCALEVENTチャンネルが、コントロールポイントへのイベントの送信には使用されないからである。換言すれば、UPNP-EVENTチャンネルＣＨ＃２５は、複合機２００で発生したイベントをコントロールポイントに送信するためにのみ使用される。

（８）UPNP-DOWNCONTENTxチャンネルＣＨ＃２６ｘ：
ＵＰｎＰにおいて、コンテンツデータをコントロールポイントからＭＦＰデバイスユニット４００にダウンロードする際に使用される送受信チャンネル。ここで、接尾辞”ｘ”は、Ｎdown個（Ｎdownは２以上の整数）のUPNP-DOWNCONTENTチャンネルのうちのｘ番目のチャンネルを意味している。利用可能なUPNP-DOWNCONTENTxチャンネルの個数Ｎdownは、１以上の任意に設定可能であるが、２以上の値に設定することが好ましい。Ｎdownを２以上の値に設定すれば、複数のコントロールのコンテンツデータを並行して受信することが可能である。

（９）UPNP-UPCONTENTxチャンネルＣＨ＃２７ｘ：
ＵＰｎＰにおいて、コンテンツデータをＭＦＰデバイスユニット４００からコントロールポイントにアップロードする際に使用される送受信チャンネル。接尾辞”ｘ”は、Ｎ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”を有している。各サービスは、状態テーブルと、コントロールサーバと、イベントサーバとで構成されている。状態テーブルには、サービスの状態を示す状態変数が登録されている。コントロールサーバは、コントロールポイントからのアクション要求を受け付けて処理を実行する。イベントサーバは、状態変数の値が変更されると、その変更をイベントとしてコントロールポイントに通知する。通知対象となるのは、そのサービスに予めサブスクライブ（購読）しているコントロールポイントである。

本明細書では、サービスを含むデバイスを「サービスデバイス」と呼んでいる。図８からも理解できるように、各サービスデバイスは、１つ以上の任意の数のサービスを含むことが可能である。また、あるサービスデバイスが、他のサービスデバイスを含むようにデバイス構成を構築することが可能である。

なお、図８の構成の代わりに、ルートデバイスとしてＵＰｎＰで規格化されているベーシックデバイス”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>：プリンタデバイス内のイベントサーバのパス名。イベントサーバは、サブスクライブ（購読）しているコントロールポイントにイベントを発行するサーバであり、一般にデバイスのサービス内に設けられている。

スキャナ用及びストレージ用のディスクリプションにも、プリンタ用のものと同様な項目が記述されている。なお、デバイスディスクリプションには、この他にデバイスのフレンドリ名や、製造者名、モデル名、アイコンなどの種々のプロパティが記述されているが、ここでは図示が省略されている。

D．データ転送の概要：
図１０は、コントロールポイントからリクエスト（ＨＴＴＰリクエスト）を受けたときの複合機２００内のデータ転送の流れを示す説明図である。ここでは、ＨＴＴＰリエストの宛先のパス名が”/CONTROL/PRINTER/PRINTBASIC1”である場合を示している。一般に、パス名は、１つ以上の階層で構成されており、各階層はスラッシュ”／”で区切られている。本明細書では、パス名のうちの最上位層の部分を「最上位パス名」と呼ぶ。また、最上位パス名よりも下位の部分を「下位パス名」と呼ぶ。図１０の例では、最上位パス名は”/CONTROL”であり、下位パス名は”/PRINTER/PRINTBASIC1”である。なお、この例では、下位パス名”/PRINTER/PRINTBASIC1”は、図９に示したデバイスディスクリプションで記述されているコントロールサーバのパス名（要素<controlURL>）の値と同じものに設定されている。

この下位パス名のうちの１番目の部分”/PRINTER”はデバイスモジュール”Printer”を示すデバイス名であり、２番目の部分”/PRINTBASIC1”はサービスモジュール”PrintEnhanced”を示すサービス名である。なお、パス名で使用されるデバイス名とサービス名は、デバイスディスクリプションの要素<deviceType>，<serviceType>と同じものである必要はない。但し、デバイス制御部４０２内のディスパッチャ４０１（振り分け処理部）には、パス名で使用されるデバイス名とデバイスモジュールとの対応関係、及び、パス名で使用されるサービス名とサービスモジュールとの対応関係が予め設定されていることが好ましい。

ＭＦＰサーバ３００のネットワークプロトコル制御部３０２は、ＨＴＴＰリクエストの最上位パス名に応じて、図５（Ｂ）に示したＵＰｎＰ用の複数の論理チャンネルの中から１つを選択する。図１０の例では、最上位パス名は”/CONTROL”なので、UPNP-CONTROLチャンネルが選択され、このチャンネル経由でリクエストのメッセージボディがＭＦＰサーバ３００からＭＦＰデバイスユニット４００に転送される。

デバイス制御部４０２にディスパッチャ４０１は、下位パス名に応じてデータの転送先（デバイスモジュールとサービスモジュール）を切り換える。ここでは、下位パス名は”/PRINTER/PRINTBASIC1”なので、このうちの上位の階層名”/PRINTER”に応じてデバイスモジュール”Printer”が選択され、また、下位の階層名”/PRINTBASIC1”に応じてサービスモジュール”PrintBasic”が選択される。そして、このサービスモジュール”PrintBasic”にメッセージボディが供給される。図１０においては、ＭＦＰデバイスユニット４００内におけるデータ転送の経路が矢印で示されている。

なお、通常はサービスモジュールがメッセージボディの処理を実行する場合が多いが、サービスモジュールではなくデバイスモジュールが実行する処理（例えばデバイスディスクリプションの生成）も存在する。このような処理のリクエストを受けた場合には、そのリクエストのメッセージボディは、下位パス名に応じてデバイスモジュールに転送されて処理される。

このように、本実施例では、ネットワークプロトコル制御部３０２がリクエストの宛先の最上位パス名に応じて論理チャンネルを選択するので、多数の論理チャンネルの中から適切な論理チャンネルを容易に選択することができる。この際、ネットワークプロトコル制御部３０２は、パス名の他の部分やメッセージボディの内容を解釈する必要がなく、最上位パス名のみを解釈すれば済むという利点がある。さらに、デバイス制御部４０２は、宛先の下位パス名に応じてデータの転送先（デバイスモジュールとサービスモジュール）を切り換えるので、リクエストを適切なデバイスモジュールやサービスモジュールに容易に供給することができる。この際、デバイス制御部４０２は、下位パス名のみを解釈すれば済むという利点がある。

E．各種のデータ転送シーケンス：
図１１は、コントロールポイントから複合機２００にアクション要求が発行された場合の手順を示すシーケンス図である。図１１のステップ[1]では、コントロールポイント１１０Ｃが、アクション要求のリクエストメッセージＦ１１をＭＦＰサーバ３００に転送する。このリクエストメッセージＦ１１のヘッダには、宛先のパス名”/CONTROL/PRINTER/PRINTBASIC1”と、複合機２００のＩＰアドレス”169.254.100.100”とが記述されている。さらに、メッセージボディには、アクション要求の内容を示すＳＯＡＰエンベロープが含まれている。

アクション要求が、例えば、新たな印刷ジョブのＩＤを作成する要求（CreateJob命令）である場合には、ＳＯＡＰエンベロープには、ジョブの属性として以下のような印刷仕様を設定することが可能である。
・コピー部数
・レイアウト（１頁／１枚，２頁／１枚，デバイス設定値等）
・印刷の向き（ポートレイト／ランドスケープ、デバイス設定値等）
・用紙サイズ（Ａ４，Ｂ４，デバイス設定値等）
・印刷用紙の種類（普通紙、写真用紙、透明シート、封筒、デバイス設定値等）
・印刷品質（低画質、通常、高画質、デバイス設定値等）
なお、「デバイス設定値」とは、複合機２００に設定されている設定値を使用することを意味している。CreateJob命令には、このような種々の印刷仕様を設定することができるので、コントロールポイントを操作しているユーザが、所望の印刷仕様で複合機２００に印刷を実行させることができる。

図１１のステップ[2]では、ＭＦＰサーバ３００が、リクエストメッセージＦ１１についてＵＰｎＰプロトコルの解析を行う。具体的には、ＭＦＰサーバ３００は、宛先の最上位パス名”/CONTROL”を解釈してUPNP-CONTROLチャンネルを選択する。ステップ[3]では、ＭＦＰサーバ３００が、UPNP-CONTROLチャンネルを用いて、宛先のパス名とＳＯＡＰエンベロープとを含むメッセージＦ１２をＭＦＰデバイスユニット４００に転送する。このメッセージＦ１２内のＳＯＡＰエンベロープは、コントロールポイントから送られてきたＳＯＡＰエンベロープをそのままコピーしたものである。

図１２のステップ[4]では、ＭＦＰデバイスユニット４００が、受信したメッセージＦ１２内のＳＯＡＰエンベロープに含まれているＳＯＡＰアクションを解析し、ＳＯＡＰアクションに応じて処理を実行する。例えば、ＳＯＡＰアクションが印刷ジョブの作成要求の場合には、印刷すべき文書を表す文書データ（ＸＨＴＭＬデータ）の送付先ＵＲＩが設定された返信用のＳＯＡＰエンベロープが作成される。このＳＯＡＰアクションに応じた処理は、宛先の下位パス名”/PRINTER/PRINTBASIC1”で指定されたサービスモジュール”PrintBasic”（図１０）によって実行される。

ステップ[5]では、ＭＦＰデバイスユニット４００が、このＳＯＡＰエンベロープを含むメッセージＲ１１をＭＦＰサーバ３００に転送する。このときも、ステップ[4]で使用されたものと同じチャン論理チャンネル（UPNP-CONTROLチャンネル）が使用される。メッセージパケットＲ１１のエラーコードフィールド（図６）には、ＭＦＰデバイスユニット４００での処理が成功したか否かを示すエラーコード等が設定される。

ステップ[6]では、ＭＦＰサーバ３００がメッセージＲ１１のエラーコードを参照し、これに応じてＳＯＡＰエンベロープにＨＴＴＰのヘッダを付加する。ステップ[7]では、こうして作成されたＨＴＴＰのレスポンスメッセージＲ１２がＭＦＰサーバ３００からコントロールポイント１１０Ｃに転送される。

なお、アクション要求が印刷ジョブ作成要求である場合には、図１１のステップ[7]の後に、コントロールポイント１１０Ｃが、ＸＨＴＭＬデータをＭＦＰサーバ３００に送信し、これに応じて印刷が実行されるが、ここではその説明は省略する。

図１２は、アクション要求の他のシーケンスを示す図である。図１２の例は、宛先のパス名が図１１の例と異なる。すなわち、図１２では、パス名が”/CONTROL/PRINTER/PRINTENHANCED1”である。最上位パス名”/CONTRL”は図１１と同じなので、使用される論理チャンネルも図１１と同じである。一方、下位パス名”/PRINTER/PRINTENHANCED1”のうちのサービス名に相当する部分”/PRINTENHANCED1”は図１１の例と異なる。従って、図１２のステップ[4]では、メッセージボディはサービスモジュール”PrintEnhanced”（図１０）に転送されて、ここで処理される。なお、下位パス名”/PRINTER/PRINTENHANCED1”は、図９に示したデバイスディスクリプションで記述されているコントロールサーバのパス名（要素<controlURL>）の値と同じものに設定されている。図１２における他の処理内容は、図１１と同じである。

図１３は、アクション要求のさらに他のシーケンスを示す図である。図１３の例も、宛先のパス名が図１１、図１２の例と異なる。すなわち、図１３ではパス名が”/CONTROL/SCANNER/SCAN1”である。最上位パス名”/CONTRL”は、図１１、図１２と同じなので、使用される論理チャンネルも図１１、図１２と同じである。一方、下位パス名”/SCANNER/SCAN1”は図１１、図１２の例と異なる。従って、図１３のステップ[4]では、メッセージボディは、下位パス名”/SCANNER/SCAN1”に対応付けられたサービスモジュール”Scan”（図１０）に転送されて、ここで処理される。図１３における他の処理内容は、図１１、図１２と同じである。

このように、図１１ないし図１３の例から、アクション要求の宛先の最上パス名”/CONTROL”に応じてＵＳＢ転送の論理チャンネルが選択され、また、下位パス名に応じてメッセージの宛先であるサービスモジュールが決定されていることが理解できる。

図１４は、コントロールポイント１１０Ｃがイベント初期値を複合機２００から取得する場合の手順を示すシーケンス図である。図１４のステップ[1]では、コントロールポイント１１０Ｃが、イベント初期値要求のリクエストメッセージＦ２１をＭＦＰサーバ３００に転送する。このリクエストメッセージＦ２１のヘッダには、宛先のパス名”/EVENT/PRINTER/PRINTENHANCED1”と、複合機２００のＩＰアドレス”169.254.100.100”とが記述されている。このパス名は、図９に示したデバイスディスクリプションで記述されているイベントサーバのパス名（要素<eventSubURL>）の値と同じものに設定されている。

図１４のステップ[2]では、ＭＦＰサーバ３００が、リクエストメッセージＦ２１の宛先の最上位パス名"/EVENT"を解釈して論理チャンネルを選択する。図５で説明したように、イベントに関連して使用されるチャンネルとしては、UPNP-EVENTチャンネルがあるが、UPNP-EVENTチャンネルは、複合機２００で発生したイベントをコントロールポイントに送信するためにのみ使用される。また、UPNP-LOCALEVENTチャンネルは、ＭＦＰデバイスユニット４００を要求者としＭＦＰサーバ３００を応答者とする通信を行うためのチャンネルなので、イベント初期値のリクエストをＭＦＰサーバ３００からＭＦＰデバイスユニット４００に送信するには不適切である。そこで、図１４の例では、UPNP-LOCALCONTROLチャンネルが利用される。このチャンネルは、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の間において、ＭＦＰサーバ３００を要求者とし、ＭＦＰデバイスユニット４００を応答者とする通信を行う場合に使用されるチャンネルである。ＭＦＰサーバ３００内のネットワークプロトコル制御部３０２内には、ＨＴＴＰリクエストの宛先の最上位パス名”/EVENT”とUPNP-LOCALCONTROLチャンネルとの対応関係が予め設定されている。従って、図１４のステップ[3]では、ＭＦＰサーバ３００が、UPNP-LOCALCONTROLチャンネルを用いて、イベント初期値を要求するメッセージＦ２２をＭＦＰデバイスユニット４００に転送する。このメッセージＦ２２のボディには、宛先のパス名”/EVENT/PRINTER/PRINTENHANCED1”がそのまま記述される。このメッセージＦ２２は、下位パス名”/PRINTER/PRINTENHANCED1”に従って、プリンタデバイスのサービスモジュール”PrintEnhanced”（図１０）に送られる。

図１４のステップ[4]では、サービスモジュール”PrintEnhanced”が、イベント初期値を記述したＸＭＬデータを生成する。図８に示したように、ＵＰｎＰデバイスのサービスには、イベントサーバと状態テーブルとが設けられている。状態テーブルは、そのサービスの種々の状態を示す状態変数を格納したテーブルである。「イベント初期値」とは、状態テーブルの初期値（状態変数の初期値）を意味している。図１４のステップ[5]では、ＭＦＰデバイスユニット４００が、このＸＭＬデータを含むメッセージＲ２１をＭＦＰサーバ３００に転送する。このときも、ステップ[4]で使用されたものと同じUPNP-LOCALCONTROLチャンネルが使用される。ステップ[6]では、ＭＦＰサーバ３００がメッセージＲ２１のエラーコードを参照し、これに応じてＨＴＴＰのヘッダを付加する。ステップ[7]では、こうして作成されたＨＴＴＰのレスポンスメッセージＲ２２がＭＦＰサーバ３００からコントロールポイント１１０Ｃに転送される。

図１４の例から理解できるように、コントロールポイント１１０Ｃからのメッセージの宛先の最上位パス名”/EVENT”と、使用される論理チャンネル”UPNP-LOCALCONTROL”とは、互いの文字が全く一致しない場合がある。しかしながら、この場合にも、最上位パス名と、使用される論理チャンネルとの関係はＭＦＰサーバ３００内に予め設定されており、これに応じて論理チャンネルが選択される。従って、最上位パス名のみから論理チャンネルを容易に選択することが可能である。

図１５は、イベント発生時のシーケンスの一例を示す図である。「イベント」とは、いずれかのサービスの状態テーブル（図８）の値（状態変数）が変化したことを意味する。イベントサーバは、状態テーブルの値が変化すると、そのサービスにサブスクライブ（購読）しているコントロールポイントにイベントの発生を通知する。

イベントが発生すると、まず図１５のステップ[1]において、ＭＦＰデバイスユニット４００が、発生したイベントを記述したＸＭＬデータを作成する。ステップ[2]では、ＭＦＰデバイスユニット４００が、イベント発生のメッセージＦ３１をＭＦＰサーバ３００にＵＳＢで転送する。図５でも説明したように、イベント発生時のメッセージのＵＳＢ転送にはUPNP-EVENTチャンネルが使用される。ステップ[3]では、ＭＦＰサーバ３００が、メッセージＦ３１にＨＴＴＰヘッダを追加して、コントロールポイントへのメッセージＦ３２を作成する。このメッセージＦ３２は、ステップ[4]において、イベントが発生したサービスにサブスクライブしているコントロールポイントに送信される。このとき、ＮＯＴＩＦＹメソッドが使用されている。コントロールポイント１１０Ｃは、メッセージＦ３２を受信すると、ステップ[5]においてレスポンスメッセージＲ３１をＭＦＰサーバ３００に返信する。

このように、イベントの発生の際にも、ＭＦＰサーバ３００は、メッセージを単に転送するだけであり、メッセージの内容の解析や解釈は行わない。従って、ＭＦＰサーバ３００の構成を簡易なものとすることが可能である。

図１６は、コントロールポイントから複合機２００にサービスコンテンツを送信する場合の手順を示すシーケンス図である。ステップ[1]では、コントロールポイント１１０ＣからＭＦＰサーバ３００に、リクエストメッセージＦ４１が転送される。このメッセージＦ４１には、リクエスト命令のメソッド（ＰＯＳＴメソッド）と、宛先のパス名”/DOWN/PRINTER/PRINTENHANCED1”と、複合機２００のＩＰアドレス”169.254.100.100”とが記述されている。ステップ[2]では、ＭＦＰサーバ３００が、このメッセージＦ４１のヘッダを解析し、ＰＯＳＴ処理のデータ転送に使用するリクエストＩＤをＭＦＰデバイスユニット４００から取得する必要があることを判断する。リクエストＩＤは、コンテンツデータをＭＦＰサーバ３００からＭＦＰデバイスユニット４００に転送する際に、すべてのＤ４パケットのヘッダ（図６）に付して、他のパケットと区別するために使用されるＩＤである。ステップ[3]では、ＭＦＰサーバ３００が、リクエストＩＤを要求するメッセージＦ４２をＭＦＰデバイスユニット４００に転送する。このメッセージＦ４２のボディには、リクエスト命令のメソッド（ＰＯＳＴメソッド）と、宛先のパス名”/DOWN/PRINTER/PRINTENHANCED1”とが記述されている。また、メッセージＦ４２の転送には、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]では、こうして作成されたＨＴＴＰのレスポンスメッセージＲ４３がＭＦＰサーバ３００からコントロールポイント１１０Ｃに転送される。

このように、サービスコンテンツの送信（ダウンロード）の際には、まずUPNP-LOCALCONTROLチャンネルを使用して、Ｄ４パケットを識別するためのリクエストＩＤと、使用する論理チャンネルを指定するためのチャンネルＩＤが取得される。従って、同一のコンテンツデータの転送処理に用いられるパケットを容易に識別することができる。また、複数のUPNP-DOWNCONTENTxチャンネルの中から、使用可能なチャンネルを容易に選択することができる。

図１７は、コントロールポイントが複合機２００からサービスコンテンツを取得する場合の手順を示すシーケンス図である。ステップ[1]では、コントロールポイント１１０ＣからＭＦＰサーバ３００に、リクエストメッセージＦ５１が転送される。このメッセージＦ５１には、リクエスト命令のメソッド（ＧＥＴメソッド）と、宛先のパス名”/UP/PRINTER/PRINTENHANCED1”と、複合機２００のＩＰアドレス”169.254.100.100”とが記述されている。ステップ[2]では、ＭＦＰサーバ３００が、このメッセージＦ５１のヘッダを解析し、ＧＥＴ処理のデータ転送に使用するリクエストＩＤをＭＦＰデバイスユニット４００から取得する必要があることを判断する。ステップ[3]では、ＭＦＰサーバ３００が、リクエストＩＤを要求するメッセージＦ５２をＭＦＰデバイスユニット４００に転送する。このメッセージＦ５２のボディには、リクエスト命令のメソッド（ＧＥＴメソッド）と、宛先のパス名”/UP/PRINTER/PRINTENHANCED1”とが記述されている。このときの転送には、UPNP-LOCALCONTROLチャンネルが使用される。

ステップ[4]では、ＭＦＰデバイスユニット４００が、メッセージＦ５２の要求に従ってリクエストＩＤを生成し、また、Ｎup個のUPNP-UPCONTENTxチャンネルのうちの１つを指定するためのチャンネルＩＤも生成する。チャンネルＩＤの値としては、その時点で使用されていないUPNP-UPCONTENTxチャンネルのチャンネルＩＤの中で最も小さな値が割り当てられる。ステップ[5]では、ＭＦＰデバイスユニット４００からＭＦＰサーバ３００に、リクエストＩＤとチャンネルＩＤを含むメッセージＲ５１が返信される。この際にも、UPNP-LOCALCONTROLチャンネルが使用される。

こうしてリクエストＩＤとチャンネルＩＤがＭＦＰサーバ３００に通知された後、ステップ[6]においてコンテンツデータの生成が完了すると、ステップ[7]において、ＭＦＰデバイスユニット４００がコンテンツデータを含むメッセージＲ５２をＭＦＰサーバ３００に転送する。このメッセージＲ５２の各パケットのヘッダには、ステップ[5]でＭＦＰサーバ３００に通知されたリクエストＩＤが記入されている。また、論理チャンネルとしては、Ｎup個のUPNP-UPCONTENTxチャンネルの中で、チャンネルＩＤで指定された１つのチャンネルが使用される。図１７の例では、チャンネルＩＤの値が”１”なので、１番目のチャンネルUPNP-UPCONTENT1が使用されている。ＭＦＰデバイスユニット４００は、メッセージＲ５２のリクエストＩＤを参照することによって、これらのパケットがステップ[3]で要求された処理のためのパケットであることを容易に認識することができる。また、コンテンツデータのＵＳＢ転送の際には、予め設けられたＮup個の論理チャンネルUPNP-UPCONTENTxのうちの１つを使用するので、多数のコンテンツ転送処理を並行して行うことが可能である。

コンテンツデータのＵＳＢ転送が終了すると、ステップ[8]において、ＭＦＰサーバ３００が、コンテンツデータにＨＴＴＰのヘッダを付加してメッセージＲ５３を生成する。ステップ[9]では、こうして作成されたメッセージＲ５３がＭＦＰサーバ３００からコントロールポイント１１０Ｃに転送される。

このように、コントロールポイントからの要求に応じてサービスコンテンツをコントロールポイントに転送する際には、まずUPNP-LOCALCONTROLチャンネルを使用して、転送処理用のパケットを識別するためのリクエストＩＤと、使用する論理チャンネルを指定するためのチャンネルＩＤが取得される。従って、１つのコンテンツの転送処理に用いられる複数のパケットを容易に識別することができる。また、複数のUPNP-UPCONTENTxチャンネルの中から、使用可能なチャンネルを容易に選択することができる。

F．他の実施例：
図１８は、本発明の第２実施例における複合機システムの構成を示すブロック図である。この複合機システムは、中継ユニット６００とデバイスユニット８００とがＵＳＢ接続された構成を有している。中継ユニット６００は、ＭＦＰサーバ３００とＭＦＰデバイス制御ユニット７００とを有している。ＭＦＰサーバ３００は、図２に示したものと同じである。ＭＦＰデバイス制御ユニット７００は、図２に示したＭＦＰデバイスユニット４００から、ＵＳＢデバイス制御部４７０と、ＰＣカードインタフェース４８０と、操作パネル制御部４９０及び操作パネル４９２と、ビューワ制御部５００及びビューワ５０２と、印刷エンジン４４０と、スキャナエンジン４５０とを省略したものである。ＵＳＢホスト制御部５１０のルートハブ５１２には、デバイスユニット８００が接続されている。

デバイスユニット８００は、印刷エンジン８１０と、スキャナエンジン８２０と、ＰＣカードインタフェース８３０とを有している。また、図示は省略されているが、デバイスユニット８００に操作パネルとビューワを設けておくことが好ましい。この複合機システムは、図２の複合機２００から３つのデバイス（プリンタ、スキャナ、ストレージ）を分離して、デバイスユニット８００として独立させたものであることが理解できる。

図１９は、第２実施例において、コントロールポイントからリクエスト（ＨＴＴＰリクエスト）を受けたときのデータ転送の流れを示す説明図である。ＭＦＰサーバ３００（図１８）はネットワークプロトコル制御部３０２としての機能を有しており、ＭＦＰデバイス制御ユニット７００はディスパッチャ４０１としての機能を有している。ネットワークプロトコル制御部３０２とディスパッチャ４０１の機能は、図１０に示したこれらの機能と同じである。すなわち、ネットワークプロトコル制御部３０２は、最上位パス名に応じて論理チャンネルを選択して、メッセージをＭＦＰデバイス制御ユニット７００に転送する。また、ＭＦＰデバイス制御ユニット７００のディスパッチャ４０１は、下位パス名に応じてメッセージの転送先のデバイスモジュール及びサービスモジュールを切り換える。なお、デバイスモジュール及びサービスモジュールのソフトウェア部分は、ＭＦＰデバイス制御ユニット７００内に設けておくようにしてもよい。

なお、第２実施例では、ＭＦＰデバイス制御ユニット７００とデバイスユニット８００との間もＵＳＢ接続されているので、これらの間においても、図４に示したものと同じ論理チャンネルを設けるおくことが好ましい。こうすれば、２つのユニット７００，８００間の転送に用いる論理チャンネルを容易に選択できるので、ＭＦＰデバイス制御ユニット７００の制御がより容易になる。

この第２実施例においても、ネットワークプロトコル制御部３０２がリクエストの宛先の最上位パス名に応じて論理チャンネルを選択するので、多数の論理チャンネルの中から適切な論理チャンネルを容易に選択することができる。また、ＭＦＰデバイス制御ユニット７００は、下位パス名に応じてデータ転送先のサービスデバイスを切り換えるので、リクエストを適切なサービスデバイスに容易に供給することができる。

G．変形例：
なお、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。

G１．変形例１：
上記実施例では、ＵＰｎＰ対応のネットワーク装置として複数のデバイスを含む複合機２００を用いていたが、この代わりに、１つのデバイス（例えばプリンタ）のみを含む単機能のネットワーク装置を採用することも可能である。換言すれば、ネットワーク装置は、少なくとも１つのデバイスを有していれば良い。

G２．変形例２：
上記実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。

本発明の実施例を適用するネットワークシステムの構成を示す概念図である。 複合機の内部構成を示すブロック図である。 ＭＦＰサーバの各種プロトコルの階層構造を示すブロック図である。 ＭＦＰデバイスユニットの各種プロトコルの階層構造を示すブロック図である。 ＵＳＢのインタフェース／エンドポイント構成と論理チャンネルの構成とを示す説明図である。 プリンタインタフェースを介したＵＳＢ転送に用いられるパケットの構成を示す説明図である。 ＵＰｎＰアーキテクチャを利用した処理の典型例を示すシーケンス図である。 実施例のＵＰｎＰデバイス構成を示す説明図である。 複合機のデバイスディスクリプションの例を示す説明図である。 コントロールポイントからＨＴＴＰリクエストを受けたときの複合機内のデータ転送の流れを示す説明図である。 アクション要求の手順を示すシーケンス図である。 アクション要求の他の手順を示すシーケンス図である。 アクション要求のさらに他の手順を示すシーケンス図である。 コントロールポイントがイベント初期値を取得する手順を示すシーケンス図である。 イベント発生時の手順を示すシーケンス図である。 コントロールポイントから複合機にサービスコンテンツを送信する場合の手順を示すシーケンス図である。 コントロールポイントが複合機からサービスコンテンツを取得する場合の手順を示すシーケンス図である。 第２実施例における複合機システムの内部構成を示すブロック図である。 第２実施例におけるデータ転送の流れを示す説明図である。

符号の説明

１００…パーソナルコンピュータ
１００Ｄ…プリンタドライバ
１１０…デジタルカメラ
１１０Ｃ，１２０Ｃ…コントロールポイント
１２０…ＴＶセット
１３０…画像サーバ
２００…複合機
３００…ＭＦＰサーバ
３０２…ネットワークプロトコル制御部
３１０…中央制御部
３２０…ＲＡＭ
３３０…ＲＯＭ
３４０…ネットワーク制御部
３４２…コネクタ
３５０…ＵＳＢホスト制御部
３５２…ルートハブ
３５４，３５６…ＵＳＢコネクタ
４００…ＭＦＰデバイスユニット
４０１…ディスパッチャ
４０２…デバイス制御部
４０４…プリンタデバイス
４０６…スキャナデバイス
４０８…ストレージデバイス
４１０…中央制御部
４２０…ＲＡＭ
４３０…ＲＯＭ
４４０…印刷エンジン
４５０…スキャナエンジン
４６０…ＵＳＢデバイス制御部
４６２…ＵＳＢコネクタ
４７０…ＵＳＢデバイス制御部
４７２…ＵＳＢコネクタ
４８０…ＰＣカードインタフェース
４８２…スロット
４９０…操作パネル制御部
４９２…操作パネル
５００…ビューワ制御部
５０２…ビューワ
５１０…ＵＳＢホスト制御部
５１２…ルートハブ
５１４…ＵＳＢコネクタ
６００…中継ユニット
７００…ＭＦＰデバイス制御ユニット
８００…デバイスユニット
８１０…印刷エンジン
８２０…スキャナエンジン
８３０…ＰＣカードインタフェース
１０００…サービスプロトコル解釈部
１１００…ＵＰｎＰデバイスアーキテクチャ
１２１０…非ＵＰｎＰプリンタ機能部
１２２０…非ＵＰｎＰスキャナ機能部
１２３０…非ＵＰｎＰストレージ機能部
１３１０…ＵＳＢプリンタクラスドライバ
１３２０…ＵＳＢスキャナクラスドライバ
１３３０…ＵＳＢストレージクラスドライバ
２２１０…非ＵＰｎＰプリンタ機能部
２２２０…非ＵＰｎＰスキャナ機能部
２２３０…非ＵＰｎＰストレージ機能部
２３１０…ＵＳＢプリンタクラスドライバ
２３２０…ＵＳＢスキャナクラスドライバ
２３３０…ＵＳＢストレージクラスドライバ
２４００…ＵＰｎＰデバイス機能部

Claims (5)

1. ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
   ネットワーク上のクライアントからの要求に応じてサービスを実行する１つ以上のサービスデバイスと、
   前記サービスデバイスの制御を行うデバイス制御部と、
   メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの情報を前記デバイス制御部に転送するネットワークプロトコル制御部と、
   を備え、
   前記ネットワークプロトコル制御部と前記デバイス制御部とは、複数の論理チャンネルで接続されており、
   前記ネットワークプロトコル制御部は、前記クライアントから受信したメッセージの宛先であるパス名のうちの最上位層の名前である最上位パス名に応じて前記複数の論理チャンネルの１つを選択し、選択された論理チャンネルを用いて前記メッセージボディの内容を前記デバイス制御部に転送する、ネットワーク装置。
2. 請求項１記載のネットワーク装置であって、
   前記デバイス制御部は、複数の前記サービスデバイスを含んでおり、
   前記ネットワークプロトコル制御部は、前記メッセージボディの情報の他に前記メッセージのパス名も前記デバイス制御部に転送し、
   前記デバイス制御部は、前記メッセージのパス名のうちの前記最上位層よりも下位の名前である下位パス名に応じて前記複数のサービスデバイスのうちの１つを選択し、選択されたサービスデバイスに前記メッセージボディの情報を供給する、ネットワーク装置。
3. 請求項２記載のネットワーク装置であって、
   前記複数のサービスデバイスのうちの少なくとも１つの特定のサービスデバイスは、複数のサービスを実行するための複数のサービスモジュールを有しており、
   前記デバイス制御部は、前記下位パス名が前記特定のサービスデバイスを示すデバイス名と、前記複数のサービスモジュールのうちの１つを示すサービス名とを含む場合に、前記サービス名に応じて前記複数のサービスモジュールのうちの１つを選択し、選択されたサービスモジュールに前記メッセージボディの情報を供給する、ネットワーク装置。
4. 請求項１ないし３のいずれかに記載のネットワーク装置であって、
   前記複数の論理チャンネルは、Ｄ４パケットを利用したＵＳＢ転送用の論理チャンネルである、
   ネットワーク装置。
5. ネットワーク上のクライアントからの要求に応じてサービスを実行する１つ以上のサービスデバイスと、前記サービスデバイスの制御を行うデバイス制御部と、前記ネットワーク上のクライアントから受信したメッセージを前記デバイス制御部に転送するネットワークプロトコル制御部とを含むネットワーク型プラグアンドプレイに対応したネットワーク装置を制御する方法であって、
   （ａ）メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信する工程と、
   （ｂ）前記クライアントから受信したメッセージの宛先であるパス名のうちの最上位層の名前である最上位パス名に応じて複数の論理チャンネルの１つを選択し、選択された論理チャンネルを用いて、前記メッセージボディの内容を前記ネットワークプロトコル制御部から前記デバイス制御部に転送する工程と、
   を備える方法。

Images