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

Abstract

【課題】 ネットワーク型プラグアンドプレイに対応したネットワーク装置における制御を単純化できる技術を提供する。
【解決手段】 デバイス制御部４０２は、コンテンツデータと参照ファイルを異なる受信バッファに格納する。一実施例では、コンテンツデータと参照ファイルは、異なる論理チャンネルを介して転送され、論理チャンネルに対応付けられた受信バッファにそれぞれ格納される。他の実施例では、コンテンツデータと参照ファイルは異なる識別子が付与されて転送され、識別子に応じて異なる受信バッファにそれぞれ格納されることが判断される。
【選択図】 図８

Description

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

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

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

ＵＰｎＰプロトコルでは、クライアントからネットワーク装置に対してＸＨＴＭＬデータなどのマークアップ言語で記述されたコンテンツデータを送付することができる。このようなコンテンツデータには、画像ファイルなどのファイルの参照が含まれている場合がある。以下では、コンテンツデータの中で参照されているファイルを「参照ファイル」と呼ぶ。

コンテンツデータと参照ファイルは、別のセッションでネットワーク装置に供給されるが、ネットワーク装置内の同じ受信バッファに受信される。しかし、コンテンツデータと参照ファイルに対しては、全く異なる処理が実行される場合が多い。例えば、ＸＨＴＭＬデータでは、ＸＨＴＭＬパーサが解釈を行って描画を行なう必要があるが、参照ファイルが画像データである場合にはこれらの処理を実行する必要は無い。このため、従来は、ネットワーク装置内におけるコンテンツデータと参照ファイルの処理の制御が複雑になるという問題があった。

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

本発明による装置は、ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
ネットワーク上のクライアントからの要求に応じてサービスを実行する１つ以上のサービスデバイスと、
前記サービスデバイスの制御を行うデバイス制御部と、
メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの内容を前記デバイス制御部に転送するネットワークプロトコル制御部と、
を備え、
前記デバイス制御部は、前記メッセージボディがマークアップ言語で記述されたコンテンツデータであってファイルの参照を含むコンテンツデータである場合には、前記コンテンツデータと前記参照されたファイルとを異なる受信バッファ内に格納する。

このネットワーク装置によれば、コンテンツデータと参照ファイルとを異なる受信バッファ内に格納するので、コンテンツデータと参照ファイルとに対して異なる処理をそれぞれ別個に実行することができる。この結果、コンテンツデータと参照ファイルの処理に関する制御を単純化することが可能である。

前記ネットワークプロトコル制御部と前記デバイス制御部とは、コンテンツデータを転送するための第１と第２の論理チャンネルを有しており、
前記デバイス制御部は、前記第１と第２の論理チャンネルに対応付けられた第１と第２の受信バッファを有しており、
前記コンテンツデータと前記参照されたファイルは、前記第１と第２の論理チャンネルによってそれぞれ転送されて前記第１と第２の受信バッファ内にそれぞれ格納されるようにしてもよい。

この構成によれば、コンテンツデータと参照ファイルの転送に使用する論理チャンネルを分けるので、転送処理を含む全体の処理の制御がより容易になる。

前記ネットワークプロトコル制御部と前記デバイス制御部とは、コンテンツデータを転送するための少なくとも１つの論理チャンネルを有しており、
前記ネットワークプロトコル制御部は、前記論理チャンネルを介して前記前記コンテンツデータと前記参照されたファイルを前記デバイス制御部に転送する際に、前記コンテンツデータと前記参照されたファイルに対して異なる識別子を付与して転送し、
前記デバイス制御部は、前記識別子に応じて、前記コンテンツデータと前記参照されたファイルとを異なる受信バッファ内に格納することを判断するようにしてもよい。

この構成によれば、同じ論理チャンネルを用いた場合にも、識別子に応じて、コンテンツデータと参照ファイルとを別々の受信バッファにそれぞれ格納することが可能である。

前記コンテンツデータが複数の参照ファイルを含む場合には、個々の参照ファイルを異なる受信バッファ内に格納することが好ましい。

この構成によれば、個々の参照ファイルに関する処理を別個に実行できるので、処理の制御がさらに容易になる。

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

次に、本発明の実施の形態を以下の順序で説明する。
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）：拡張マークアップ言語。

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

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-DOWNCONTENTチャンネルの個数Ｎ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．コンテンツデータ転送の第１実施例：
図８は、第１実施例においてコントロールポイントからコンテンツデータを受けたときの複合機２００内のデータ転送の流れを示す説明図である。ここでは、コンテンツデータがマークアップ言語（具体的にはＸＨＴＭＬ）で記述されており、また、画像ファイルの参照を含んでいると仮定している。ネットワークプロトコル制御部３０２は、コンテンツデータと参照ファイルとを異なる論理チャンネルを介してデバイス制御部４０２に転送する。デバイス制御部４０２は、各論理チャンネルに対応付けられた受信バッファを有している。図８では、UPNP-DOWNCONTENT1チャンネルとUPNP-DOWNCONTENT2チャンネルとに対応付けられた２つの受信バッファ４１００，４２００が例示されている。

２つの受信バッファ４１００，４２００に格納されたコンテンツデータと参照ファイルは、同じ宛先のサービスデバイスによって処理される。例えば、コンテンツデータが印刷データである場合には、コンテンツデータと参照ファイルは両方ともにプリンタ４０４に供給され、コンテンツデータと参照ファイルによって表現されたページが印刷される。

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

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

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

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

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

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

続いて、図１０のステップ[8]では、コントロールポイント１１０ＣがＭＦＰサーバ３００に対してコンテンツデータ（ＸＨＴＭＬデータ）を含むリクエストメッセージＦ１３を転送する。このメッセージＦ１３のヘッダには、リクエスト命令のメソッド（ＰＯＳＴメソッド）と、宛先のパス名”/DOWN/PRINTER/PRINTENHANCED”と、複合機２００のＩＰアドレス”169.254.100.100”とが記述されている。なお、宛先のパス名は、図９のステップ[7]で通知されたものである。

ステップ[9]では、ＭＦＰサーバ３００が、このメッセージＦ１３のヘッダを解析し、ＰＯＳＴ処理のデータ転送に使用するリクエストＩＤをＭＦＰデバイスユニット４００から取得する必要があることを判断する。リクエストＩＤは、コンテンツデータをＭＦＰサーバ３００からＭＦＰデバイスユニット４００に転送する際に、すべてのＤ４パケットのヘッダ（図６）に付して、他のメッセージと区別するために使用されるＩＤである。ステップ[10]では、ＭＦＰサーバ３００が、リクエストＩＤを要求するメッセージＦ１４をＭＦＰデバイスユニット４００に転送する。このメッセージＦ１４のボディには、リクエスト命令のメソッド（ＰＯＳＴメソッド）と、宛先のパス名”/DOWN/PRINTER/PRINTENHANCED”とが記述されている。また、メッセージＦ１４の転送には、UPNP-LOCALCONTROLチャンネルが使用される。図５で説明したように、コンテンツデータの転送に使用されるチャンネルとしては、コンテンツチャンネル（UPNP-DOWNCONTENTxチャンネルとUPNP-UPCONTENTxチャンネル）があるが、これらのコンテンツチャンネルは、コンテンツデータそのものを転送するためにのみ使用される。そこで、図１０の例では、リクエストＩＤの取得要求のメッセージＦ１４の転送には、UPNP-LOCALCONTROLチャンネルが利用される。このチャンネルは、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の間において、ＭＦＰサーバ３００を要求者とし、ＭＦＰデバイスユニット４００を応答者とする通信を行う場合に使用されるチャンネルである。ＭＦＰサーバ３００のネットワークプロトコル制御部３０２内には、ＨＴＴＰリクエストの宛先の最上位パス名”/DOWN”とUPNP-LOCALCONTROLチャンネルとの対応関係が予め設定されている。図１０のステップ[10]では、ＭＦＰサーバ３００がこの対応関係を参照してUPNP-LOCALCONTROLチャンネルを用いることを決定し、リクエストＩＤを要求するメッセージＦ１４をＭＦＰデバイスユニット４００に転送する。

ステップ[11]では、ＭＦＰデバイスユニット４００が、このメッセージＦ１４の要求に従ってリクエストＩＤを生成し、また、Ｎdown個のUPNP-DOWNCONTENTxチャンネルのうちの１つを指定するためのチャンネルＩＤも生成する。チャンネルＩＤの値としては、例えば、その時点で使用されていないUPNP-DOWNCONTENTxチャンネルのチャンネルＩＤの中で最も小さな値が割り当てられる。なお、リクエストＩＤとチャンネルＩＤの生成は、デバイス制御部４０２（図１）によって行われる。ステップ[12]では、ＭＦＰデバイスユニット４００からＭＦＰサーバ３００に、リクエストＩＤとチャンネルＩＤを含むメッセージＲ１３が返信される。この例では、リクエストＩＤは”００１０”であり、チャンネルＩＤは”１”である。このレスポンスにも、UPNP-LOCALCONTROLチャンネルが使用される。

こうしてリクエストＩＤとチャンネルＩＤがＭＦＰサーバ３００に通知され、また、ステップ[13]においてＭＦＰサーバ３００がコンテンツデータの受信を完了すると、ステップ[14]において、ＭＦＰサーバ３００がコンテンツデータ（ＸＨＴＭＬデータ）を含むメッセージＦ１５をＭＦＰデバイスユニット４００に転送する。ＸＨＴＭＬデータには、参照される画像データのＵＲＩ”ImageURI”が記述されている。このメッセージＦ１５の各パケットのヘッダには、ステップ[12]で通知されたリクエストＩＤが記入されている。また、論理チャンネルとしては、Ｎdown個のUPNP-DOWNCONTENTxチャンネルの中で、チャンネルＩＤで指定された１つのチャンネルが使用される。図１０の例では、チャンネルＩＤの値が”１”なので、１番目のチャンネルUPNP-DOWNCONTENT1が使用されている。ＭＦＰデバイスユニット４００は、メッセージＦ１５のリクエストＩＤを参照することによって、これらのパケットがステップ[10]で要求された処理のためのパケットであることを容易に認識することができる。また、コンテンツデータの送信処理の際には、予め設けられたＮdown個の論理チャンネルUPNP-DOWNCONTENTxのうちの１つを１つのコンテンツに割り当てるので、多数のコンテンツ送信処理を並行して行うことが可能である。転送されたコンテンツデータは、第１の受信バッファ４１００（図８）に格納される。

コンテンツデータの転送処理が終了すると、ステップ[15]において、処理が完了したことを示すレスポンスメッセージＲ１４がＭＦＰデバイスユニット４００からＭＦＰサーバ３００に転送される。ステップ[16]では、ＭＦＰサーバ３００がメッセージＲ１４のエラーコードを参照し、これに応じてＨＴＴＰのヘッダを付加する。ステップ[17]では、こうして作成されたＨＴＴＰのレスポンスメッセージＲ１５がＭＦＰサーバ３００からコントロールポイント１１０Ｃに転送される。

続いて、図１１のステップ[18]において、ＭＦＰデバイスユニット４００内のパーサがＸＨＴＭＬを解釈し、コンテンツデータに画像データの参照が含まれていることが検出されると、ステップ[19]において、ＭＦＰデバイスユニット４００からＭＦＰサーバ３００に対して参照ファイルの取得要求を含むメッセージＲ１６が転送される。このメッセージＲ１６のボディには、リクエスト命令のメソッド（ＧＥＴメソッド）と、宛先のＵＲＩ”ImageURI”とが記述されている。また、参照ファイルの転送で使用されるべきUPNP-DOWNCONTENTxチャンネルのチャンネルＩＤの値も記述されている。この例では、図１０のステップ[14]で使用されたチャンネルＩＤ＝１の次のチャンネルＩＤ＝２が使用されている。このメッセージＲ１６はUPNP-LOCALEVENTチャンネルを用いて行われる。このチャンネルは、前述したように、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の間において、ＭＦＰデバイスユニット４００を要求者とし、ＭＦＰサーバ３００を応答者とする通信を行う場合に使用されるチャンネルである。

ステップ[20]では、ＭＦＰサーバ３００がこのメッセージＲ１６を解析して、参照ファイル転送用のリクエストＩＤを作成する。そして、この新たなリクエストＩＤを含むメッセージＦ１６が、ステップ[21]でＭＦＰデバイスユニット４００に返信される。図１１の例では、リクエストＩＤは、”００１１”に設定されている。ＭＦＰサーバ３００は、さらに、ステップ[22]において、参照ファイルをそのＵＲＩ（＝”ImageURI”）に従って取得するためのＨＴＴＰリクエストメッセージＲ１７をネットワークを介して発信する。得１１では、参照ファイルがコントロールポイント１１０Ｃから取得されるものと仮定しているが、他の任意のネットワーク装置（例えば図１の画像サーバ１３０）から参照ファイルを取得することが可能である。

ステップ[23]では、参照ファイルとしての画像データを含むレスポンスメッセージＦ１７がＭＦＰサーバ３００に返信される。ステップ[24]では、ＭＦＰサーバ３００が、この画像データを含むメッセージＦ１８をＭＦＰデバイスユニット４００に転送する。このメッセージＦ１８のヘッダには、ステップ[14]で通知されたリクエストＩＤが記述されている。また、論理チャンネルとしては、Ｎdown個のUPNP-DOWNCONTENTxチャンネルの中で、ステップ[19]で通知されたチャンネルＩＤに対応する１つのチャンネル（UPNP-DOWNCONTENT2）が使用される。こうしてＭＦＰデバイスユニット４００に転送された参照ファイル（画像データファイル）は、第２の受信バッファ４２００（図８）に格納される。ステップ[25]では、ＭＦＰデバイスユニット４００のプリンタ４０４が、ＸＨＴＭＬデータ及び画像データを用いて、ＸＨＴＭＬデータで記述された画像の印刷を実行する。

このように、コンテンツデータと参照ファイルとを異なる受信バッファに格納することの利点は以下の通りである。従来のように、同じ受信バッファ内にコンテンツデータと参照ファイルとを格納すると、これらを組み合わせたコンテンツ（通常は画像）を再現するために複雑な制御が必要になる。例えば、ＸＨＴＭＬデータ（「ＸＨＴＭＬ文書」とも呼ぶ）は、パーサによって解析された後、描画処理が実行される。一方、参照ファイルとしての画像データは、圧縮データの伸長処理と、ＸＨＴＭＬ文書の画像に貼り付ける処理とが実行される。このように、コンテンツデータと参照ファイルに対しては全く異なる処理が実行されるのが普通なので、これらを同じ受信バッファ内に同時に格納すると、それぞれの格納位置を厳密に管理しておく必要が生じる。また、仮に、コンテンツデータの処理完了後に参照ファイルを受信するようにした場合には、コンテンツデータの処理完了によって受信バッファが空くまで参照ファイルを取得できないので、全体の処理速度が低下する。これに対して、本実施例では、コンテンツデータと参照ファイルを別個の受信バッファに格納するので、両者を並行してそれぞれ処理することが可能であり、制御がより単純になるという利点がある。

また、本実施例では、複数のコンテンツ転送用チャンネル（UPNP-DOWNCONTENTxチャンネル）の各チャンネルに受信バッファがそれぞれ１つずつ対応付けられているので、コンテンツデータ及び参照ファイルの転送とその後の処理をそれぞれ容易に制御することができる。

なお、参照ファイルが複数存在する場合には、複数の参照ファイルを互いに異なる論理チャンネルを介して転送し、異なる受信バッファに格納するようにしてもよい。こうすれば、個々の参照ファイルの格納や処理を別個に行えるので、それぞれの処理の制御が容易になる。また、１つの参照ファイル（例えば画像ファイル）を、レンジ指定付きのＧＥＴメソッドによって複数回のセッションで取得する場合がある。このような場合にも、各レンジの参照ファイルを異なる論理チャンネルで転送して異なる受信バッファに格納するようにしてもよい。但し、複数の参照ファイルや、レンジ指定されて複数個に分割された参照ファイルを、１つの受信バッファに格納することも可能である。

D．コンテンツデータ転送の第２実施例：
図１２は、第２実施例におけるデータ転送の流れを示す説明図である。第２実施例では、コンテンツデータと参照ファイルが同じ論地チャンネル（UPNP-DOWNCONTENT）を使用する。なお、第２実施例では、ダウンロード用のコンテンツチャンネルUPNP-DOWNCONTENTが１つだけしか設けられていないものと仮定している。但し、第１実施例で説明した複数のコンテンツチャンネルUPNP-DOWNCONTENTxのうちの１つを用いてコンテンツデータと参照ファイルの両方を転送するものとしてもよい。

第２実施例においても、コンテンツデータと参照ファイルが異なる受信バッファ４１００，４２００に格納される点は図８に示した第１実施例と同じである。デバイス制御部４０２は、Ｄ４パケットのヘッダ部に付与される識別子に応じて、コンテンツデータと参照ファイルを異なる受信バッファに格納すべきであることを判定する。

図１３は、第２実施例で使用するＤ４パケットの構成を示す説明図である。前述した図６のＤ４パケットとの違いは、ＩＤフィールドにおいてリクエストＩＤの代わりにジョブＩＤを格納する点である。第１実施例で使用したリクエストＩＤは、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の一方が他方の要求に応じて付与していた。第２実施例で使用されるジョブＩＤは、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の一方が自ら付与する点でリクエストＩＤと異なっている。但し、リクエストＩＤもジョブＩＤも、転送されるメッセージを識別するために使用する識別子（「転送識別子」とも呼ぶ）としての機能は同じである。従って、第２実施例においても、ジョブＩＤの代わりにリクエストＩＤを用いても良い。

図１４〜図１６は、第２実施例におけるコンテンツデータの転送手順を示すシーケンス図である。図１４のステップ[1]では、コントロールポイント１１０Ｃが、印刷ジョブの作成を要求するリクエストメッセージＦ２１をＭＦＰサーバ３００に転送する。このリクエストメッセージＦ２１は、図９のメッセージＦ１１と同じものである。

図１４のステップ[2]では、ＭＦＰサーバ３００が、リクエストメッセージＦ２１についてＵＰｎＰプロトコルの解析を行う。この解析の結果、このメッセージＦ２１がプリンタデバイスのコントロールサーバに転送すべきものであることが認識され、また、印刷ジョブ作成要求であることを認識されてジョブＩＤが割り当てられる。各印刷ジョブにはそれぞれ固有のジョブＩＤが割り当てられるので、複数の印刷ジョブを複合機２００が並行して受信し、それぞれの印刷処理を実行することができる。

ステップ[3]では、ＭＦＰサーバ３００が、ジョブＩＤと、宛先のパス名と、ＳＯＡＰエンベロープとを含むメッセージＦ２２をＭＦＰデバイスユニット４００に転送する。このメッセージＦ２２は、ＩＤフィールドにジョブＩＤが設定されている点で図９に示した第１実施例のメッセージＦ１２と異なっている。

図１４のステップ[4]では、ＭＦＰデバイスユニット４００が、受信したメッセージＦ２２内のＳＯＡＰアクションを処理し、返信用のＳＯＡＰエンベロープを作成する。ステップ[5]では、ＭＦＰデバイスユニット４００が、このＳＯＡＰエンベロープを含むメッセージＲ２１をＭＦＰサーバ３００に転送する。このメッセージＲ２１のＳＯＡＰエンベロープには、ＸＨＴＭＬデータの送付先ＵＲＩ（DataSinkURI）が含まれている。このＵＲＩのパス名”/DOWN/PRINTER/PRINTENHANCED/00000001”の最下層の部分”/00000001”は、ステップ[3]で通知されたジョブＩＤである。また、ジョブＩＤを除いたパス名”/DOWN/PRINTER/PRINTENHANCED”は、ＸＨＴＭＬデータの真の送付先ＵＲＩである。図９と比較すれば理解できるように、このメッセージＲ２１と図９のメッセージＲ１１との差違は、このジョブＩＤの部分だけである。

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

続いて、図１５のステップ[8]では、コントロールポイント１１０Ｃが、ＭＦＰサーバ３００に対してコンテンツデータ（ＸＨＴＭＬデータ）を含むリクエストメッセージＦ２３を転送する。このメッセージＦ２３の宛先のパス名は、図１４のステップ[7]で通知されたものである。

ステップ[9]では、ＭＦＰサーバ３００が、リクエストメッセージＦ２３についてＵＰｎＰプロトコルの解析を実行する。この解析の結果、このメッセージＦ２３の宛先の真のＵＲＩ”/DOWN/PRINTER/PRINTENHANCED”が認識され、またジョブＩＤ”00000001”が抽出される。

ステップ[10]では、ＭＦＰサーバ３００が、宛先のパス名”/DOWN/PRINTER/PRINTENHANCED”とＸＨＴＭＬデータとを含むメッセージＦ２４をＭＦＰデバイスユニット４００に転送する。このとき、Ｄ４パケットのＩＤフィールド（図１３）にはジョブＩＤが設定される。この転送にはUPNP-DOWNCONTENTチャンネルが利用される。転送されたＸＨＴＭＬデータは、第１の受信バッファ４１００（図１２）に格納される。

コンテンツデータの転送処理が終了すると、ステップ[12]において、処理が完了したことを示すレスポンスメッセージＲ２３がＭＦＰデバイスユニット４００からＭＦＰサーバ３００に転送される。このメッセージＲ２３にもジョブＩＤが付されている。従って、ＭＦＰサーバ３００は、このジョブＩＤのジョブ（ＸＨＴＭＬデータの転送）が終了したことを認識することができる。ステップ[13]では、ＭＦＰサーバ３００がメッセージＲ２３のエラーコードを参照し、これに応じてＨＴＴＰのヘッダを付加する。ステップ[14]では、こうして作成されたＨＴＴＰのレスポンスメッセージＲ２４がＭＦＰサーバ３００からコントロールポイント１１０Ｃに転送される。

続いて、図１６のステップ[15]において、ＭＦＰデバイスユニット４００内のパーサがＸＨＴＭＬを解釈し、コンテンツデータに画像データの参照が含まれていることが検出されると、ステップ[16]において、ＭＦＰデバイスユニット４００からＭＦＰサーバ３００に対して参照ファイルの取得要求を含むメッセージＲ２５が転送される。このメッセージＲ１６のヘッダには、参照ファイル転送のための新たなジョブＩＤ”10000001”が付加されている。このジョブＩＤは、そのＭＳＢがコンテンツデータ転送用のジョブＩＤ（図１５のメッセージＦ２４参照）と異なるだけであり、他のビットはコンテンツデータ転送用のジョブＩＤと同じ値に設定されていることが好ましい。こうすれば、両者が同じコンテンツの再現に使用されるものであることを容易に認識することができる。メッセージＲ２５のボディには、リクエスト命令のメソッド（ＧＥＴメソッド）と、宛先のＵＲＩ”ImageURI”とが記述されている。なお、このメッセージＲ２５と、図１１のメッセージＲ１６との差違は、メッセージＲ２５ではヘッダにジョブＩＤが設定されている点と、ボディにチャンネルＩＤが設定されていない点だけである。

ステップ[17]では、ＭＦＰサーバ３００がこのメッセージＲ１６を解釈し、ステップ[18]ではＭＦＰデバイスユニット４００にそのレスポンスメッセージＦ２５を返信する。ＭＦＰサーバ３００は、さらに、ステップ[19]において、参照ファイルをそのＵＲＩ（＝”ImageURI”）に従って取得するためのＨＴＴＰリクエストメッセージＲ２６をネットワークに対して発信する。このメッセージＲ２６は、図１１のメッセージＲ１７と同じものである。

ステップ[20]では、参照ファイルとしての画像データを含むレスポンスメッセージＦ２６がＭＦＰサーバ３００に返信される。ステップ[21]では、ＭＦＰサーバ３００が、この画像データを含むメッセージＦ２７をＭＦＰデバイスユニット４００に転送する。このメッセージＦ２７のヘッダには、ステップ[16]で通知されたジョブＩＤが記述されている。また、論理チャンネルとしては、ＸＨＴＭＬデータの転送時と同じ論理チャンネルUPNP-DOWNCONTENTが使用される。こうしてＭＦＰデバイスユニット４００に転送された参照ファイル（画像データファイル）は、第２の受信バッファ４２００（図１２）に格納される。ステップ[22]では、ＭＦＰデバイスユニット４００のプリンタ４０４が、ＸＨＴＭＬデータ及び画像データを用いて、ＸＨＴＭＬデータで記述された画像の印刷を実行する。

このように、第２実施例では、コンテンツデータと参照ファイルの両方を同一の論理チャンネルを介して転送おり、論理チャンネルで用いられるパケットの識別子（ジョブＩＤ）を用いてコンテンツデータと参照ファイルとを区別している。そして、それぞれの識別子に応じて、コンテンツデータと参照ファイルを異なる受信バッファに格納する。この結果、第１実施例と同様に、コンテンツデータ及び参照ファイルの転送とその後の処理を容易に制御することができる。

なお、第２実施例においても、参照ファイルが複数存在する場合に、個々の参照ファイルを異なる受信バッファに格納するようにしてもよい。この場合には、個々の参照ファイルに対して固有の識別子を付与すれば良い。

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

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

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

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

符号の説明

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

Claims (5)

1. ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
   ネットワーク上のクライアントからの要求に応じてサービスを実行する１つ以上のサービスデバイスと、
   前記サービスデバイスの制御を行うデバイス制御部と、
   メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの内容を前記デバイス制御部に転送するネットワークプロトコル制御部と、
   を備え、
   前記デバイス制御部は、前記メッセージボディがマークアップ言語で記述されたコンテンツデータであってファイルの参照を含むコンテンツデータである場合には、前記コンテンツデータと前記参照されたファイルとを異なる受信バッファ内に格納する、ネットワーク装置。
2. 請求項１記載のネットワーク装置であって、
   前記ネットワークプロトコル制御部と前記デバイス制御部とは、コンテンツデータを転送するための第１と第２の論理チャンネルを有しており、
   前記デバイス制御部は、前記第１と第２の論理チャンネルに対応付けられた第１と第２の受信バッファを有しており、
   前記コンテンツデータと前記参照されたファイルは、前記第１と第２の論理チャンネルによってそれぞれ転送されて前記第１と第２の受信バッファ内にそれぞれ格納される、ネットワーク装置。
3. 請求項１記載のネットワーク装置であって、
   前記ネットワークプロトコル制御部と前記デバイス制御部とは、コンテンツデータを転送するための少なくとも１つの論理チャンネルを有しており、
   前記ネットワークプロトコル制御部は、前記論理チャンネルを介して前記前記コンテンツデータと前記参照されたファイルを前記デバイス制御部に転送する際に、前記コンテンツデータと前記参照されたファイルに対して異なる識別子を付与して転送し、
   前記デバイス制御部は、前記識別子に応じて、前記コンテンツデータと前記参照されたファイルとを異なる受信バッファ内に格納することを判断する、ネットワーク装置。
4. 請求項１ないし３のいずれかに記載のネットワーク装置であって、
   前記コンテンツデータが複数の参照ファイルを含む場合には、個々の参照ファイルを異なる受信バッファ内に格納する、ネットワーク装置。
5. ネットワーク上のクライアントからの要求に応じてサービスを実行する１つ以上のサービスデバイスと、前記サービスデバイスの制御を行うデバイス制御部と、前記ネットワーク上のクライアントから受信したメッセージを前記デバイス制御部に転送するネットワークプロトコル制御部とを含むネットワーク型プラグアンドプレイに対応したネットワーク装置を制御する方法であって、
   （ａ）メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信する工程と、
   （ｂ）前記メッセージボディがマークアップ言語で記述されたコンテンツデータであってファイルの参照を含むコンテンツデータである場合には、前記コンテンツデータと前記参照されたファイルとを異なる受信バッファ内に格納する工程と、
   を備える方法。

Images