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

Description

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

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

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

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

このように、ＵＰｎＰ対応のネットワーク装置は多様な形態を採り得る。しかし、その反面、個々のネットワーク装置毎にその装置に適した構成を採用するようにした場合には、ネットワーク装置の制御が複雑になったり、あるいは、個々のネットワーク装置毎に制御方法を変更しなくてはならず、その設計・製作に多大な手間を要するという問題があった。

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

本発明は、ネットワーク型プラグアンドプレイに対応したネットワーク装置に関する。本発明によるネットワーク装置は、ネットワーク上のクライアントからの要求に応じてサービスを実行する１つの以上のサービスデバイスと、
前記サービスデバイスの制御を行うデバイス制御部と、
メッセージヘッダとメッセージボディとを有するメッセージを、前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの情報を前記デバイス制御部に転送するネットワークプロトコル制御部と、を備える。
前記ネットワークプロトコル制御部は、前記クライアントから受信した前記メッセージボディの内容を解釈すること無く前記ネットワーク型プラグアンドプレイのプロトコルに従って前記メッセージヘッダを解釈するとともに、前記ネットワーク型プラグアンドプレイのプロトコルとは異なる通信プロトコルに従って前記メッセージボディを前記デバイス制御部に送信し、
前記デバイス制御部は、前記ネットワークプロトコル制御部から受信した前記メッセージボディの内容を解釈するとともに、前記解釈の結果に応じて前記サービスデバイスにサービスを実行させる。

このネットワーク装置によれば、ネットワークプロトコル制御部がメッセージボディの内容を解釈すること無くヘッダを解釈してメッセージボディをデバイス制御部に送信するので、ネットワークプロトコル制御部における制御が、実装されているサービスデバイスの種類や数に依存しない。この結果、ネットワークプロトコル制御部における制御を単純化することができる。

前記ネットワークプロトコル制御部は、前記デバイス制御部から受信したメッセージを、メッセージボディとし、メッセージヘッダを付加した上で、前記ネットワーク上のクライアントへ送信する機能を有し、
前記デバイス制御部は、前記クライアントに送信したい情報をメッセージとして、前記ネットワーク型プラグアンドプレイのプロトコルとは異なる通信プロトコルに従って前記ネットワークプロトコル制御部に送信し、
前記ネットワークプロトコル制御部は、前記デバイス制御部から受信した前記メッセージボディの内容を解釈すること無く前記ネットワーク型プラグアンドプレイのプロトコルに従って前記メッセージヘッダを付加するとともに、前記メッセージヘッダと前記メッセージボディからなるメッセージを前記クライアントに送信するようにしてもよい。

この構成によれば、デバイス制御部からクライアントにメッセージを転送する際にも、ネットワークプロトコル制御部の制御を単純化することができる。

前記ネットワーク装置は、単一のＩＰアドレスが割り当てられる単一のネットワーク装置として機能し、
個々のサービスデバイスは、前記ネットワーク装置のＩＰアドレスと、各サービスデバイスに割り当てられたデバイス識別子とによって識別されるようにしてもよい。

この構成によれば、単一のＩＰアドレスとデバイス識別子とによってネットワーク装置内のすべてのサービスデバイスを識別できるので、外部からのアクセスが容易になる。また、ＩＰアドレスが少なくて済むので、ネットワークにおけるアドレス管理がより容易になる。

前記ネットワーク装置は、前記ネットワーク型プラグアンドプレイのアーキテクチャに従ったデバイス構成として、前記ネットワーク装置を代表する単一のベーシックデバイス内に前記サービスデバイスが包含されているネストされたデバイス構成を有しているものとしてもよい。

また、前記ベーシックデバイスは、前記サービスデバイスが実行するサービスの他には、前記ベーシックデバイス自身が実行する固有のサービスを有さないデバイスとして構成されているものとしてもよい。

これらの構成によれば、ネットワーク装置のデバイス構成がより単純化される。

前記ネットワークプロトコル制御部と前記デバイス制御部との間の通信は、異なる用途にそれぞれ割り当てられた複数の双方向論理チャンネルを用いたパケット通信によって実行されるものとしてもよい。

この構成によれば、受信側が論理チャンネルに応じて通信の用途を判断することができるので、その後の処理を迅速に進めることができる。

前記各論理チャネルは、目的に応じて前記ネットワークプロトコル制御部がリクエスト側になる第１の動作モードと、前記デバイス制御部がリクエスト側になる第２の動作モードとを実現可能であり、
各論理チャネルのリクエストおよびリプライメッセージのボディ部には、送り元から送り先へ通知される特定種類の情報を格納するための所定のフィールドが設けられているようにしてもよい。

この構成によれば、前記ネットワークプロトコル制御部と前記デバイス制御部との間で、メッセージの送り元から送り先に特定の種類の情報（ジョブＩＤやエラーなどの情報）を通知することができる。

前記論理チャネルのメッセージボディ部から前記フィールドを除いたメッセージボディ部において、当該メッセージボディ部の先頭に、メッセージの送り元から送り先へ通知するＵＲＩが付加されるようにしてもよい。

この構成によれば、前記ネットワークプロトコル制御部と前記デバイス制御部との間で、メッセージの送り元から送り先に、リクエストの内容や宛先を示すＵＲＩを通知することができる。

前記ネットワークプロトコル制御部と前記デバイス制御部は、
（ｉ）前記デバイス制御部と前記ネットワーク上のクライアントとの間で交換されるグローバルな情報を、前記ネットワークプロトコル制御部と前記デバイス制御部との間で送受信するグローバル情報送受信モードと、
（ｉｉ）前記ネットワーク上のクライアントには無関係に、前記ネットワークプロトコル制御部と前記デバイス制御部との間で交換されるローカルな情報を送受信するローカル情報送受信モードとを有しており、
前記グローバル情報送受信モードとローカル情報送受信モードは、メッセージのヘッダによって識別されるものとしてもよい。

この構成によれば、２つの受信モードの区別をヘッダで行っているので、受信後の処理を迅速に行うことができる。

前記ネットワーク装置は、前記ネットワーク型プラグアンドプレイのプロトコルに対応した第１の装置としての機能と、前記ネットワーク型プラグアンドプレイ以外のネットワークプロトコルに対応した第２の装置としての機能とを有しており、
前記ネットワーク装置は、前記第１の装置として機能するときには所定の第１のポート番号によってアクセスされ、前記第２の装置として機能するときには前記第１のポート番号とは異なる第２のポート番号によってアクセスされるようにしてもよい。

この構成によれば、１つのネットワーク装置が２つの異なるプロトコルで動作する装置として機能することができる。また、２つの装置には異なるポート番号が割り当てられているので、いずれのプロトコルの通信かを容易に判断することができる。

前記サービスデバイスは、印刷機構を含み、
前記第１の装置は、前記ネットワーク型プラグアンドプレイのプロトコルに対応した第１のプリンタであり、
前記第２の装置は、前記ネットワーク型プラグアンドプレイのプロトコル以外のネットワークプロトコルに対応した第２のプリンタであり、
前記デバイス制御部は、
（ｉ）前記ネットワーク装置が前記第１のプリンタとして機能するときには、文書記述言語を含むメッセージボディを前記ネットワーク上のクライアントから受信し、前記文書記述言語を解釈してドットの形成状態を表す印刷データを作成するとともに、作成した印刷データを前記印刷機構に供給し、
（ｉｉ）前記ネットワーク装置が前記第２のプリンタとして機能するときには、前記第２のプリンタ固有の制御コマンドからなる印刷データを前記ネットワーク上のクライアントから受信して前記印刷機構に供給するものとしてもよい。

この構成によれば、通ネットワーク装置が、ネットワーク型のプラグアンドプレイ対応のプリンタとして機能することができ、また、通常のネットワークプリンタとして機能することも可能である。

前記ネットワークプロトコル制御部と前記デバイス制御部との間の通信は、前記ネットワーク装置が前記第１のプリンタとして機能するときに利用される第１種の論理チャンネル群と、前記ネットワーク装置が前記第２のプリンタとして機能するときに利用される第２種の論理チャンネル群と、を用いたパケット通信によって実行されるようにしてもよい。

この構成によれば、ネットワークプロトコル制御部とデバイス制御部との間の通信に異なる論理チャンネルが使用されるので、受信側が論理チャンネルに応じていずれのプロトコルで転送されたものかを直ちに判断することができ、その後の処理を迅速に進めることができる。

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

次に、本発明の実施の形態を実施例に基づいて以下の順序で説明する。
A．用語の説明：
B．システムの概要：
C．複合機のデバイス構成及びデバイスディスクリプション：
D．印刷ジョブ実行シーケンス：
E．アクション実行シーケンス：
F．イベント発行シーケンス：
G．第２実施例：
H．変形例：

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-DESCRIPTIONチャンネルＣＨ＃２１：ＵＰｎＰにおいてディスクリプション（後述する）を送受信するためのチャンネル。
（４）UPNP-ACTIONチャンネルＣＨ＃２２：ＵＰｎＰにおいて、アクション（後述する）を送受信するためのチャンネル。
（５）UPNP-EVENTチャンネルＣＨ＃２３：ＵＰｎＰにおいて、イベント（後述する）を送受信するためのチャンネル。
（６）UPNP-XHTML-PRINTチャンネルＣＨ＃２４：ＵＰｎＰにおいて、印刷対象となる文書を記述したＸＨＴＭＬデータを送受信するためのチャンネル。
（７）UPNP-HTTP-CLIENTチャンネルＣＨ＃２５：ＵＰｎＰにおいて、他のネットワーク装置のＵＲＩを参照してデータを取得する際のメッセージを送受信するためのチャンネル。
（８）UPNP-HTTP-DEAMONチャンネルＣＨ＃２６：ＵＰｎＰにおいて、プレゼンテーション（後述する）を行う際のメッセージを送受信するためのチャンネル。

なお、各論理チャンネルは、いずれもバルクアウトエンドポイントＥＰ＃１とバルクインエンドポイントＥＰ＃２の両方を利用して双方向通信を行うことができる。論理チャンネルの識別情報は、ＵＳＢパケットのヘッダに登録される。

図５は、ＵＳＢ転送に用いられるパケットの構成を示す説明図である。これは、ＩＥＥＥ１２８４．４に即したパケット構造であり、「Ｄ４パケット」と呼ばれている。Ｄ４パケットは、６バイトのヘッダと、ボディ部分からなり、ボディ部分は４バイトのＩＤフィールドと、２バイトのエラーコードと、０バイト以上のメッセージとで構成されている。図４（Ｂ）に示した８つの論理チャンネルを識別するＩＤは、ソケットＩＤとしてヘッダ内に登録される。後述するように、コントロールポイントから複合機２００に対して印刷ジョブが要求されたときには、ジョブ識別子がＩＤフィールドに設定される。

各論理チャンネルにおいてＩＤフィールドとエラーコードに設定される情報は以下の通りである。

表１中の矢印は、通信が行われる順序を示している。すなわち、矢印の元の側がリクエスト時の転送を示し、矢印の先がリプライ時の転送を示している。例えば、UPNP-ACTIONチャンネルでは、ＭＦＰサーバ３００からＭＦＰデバイスユニット４００へのリクエストの転送時には、ＩＤフィールドは常にゼロであり、エラーコードがあればエラーフィールドに設定される。なお、このエラーコードとしては、例えば、ＨＴＴＰのステータスコードが設定される。このリクエストに対するＭＦＰデバイスユニット４００からＭＦＰサーバ３００へのリプライの転送時には、ＩＤフィールドもエラーフィールドも常に０に設定される。なお、UPNP-HTTP-CLIENTチャンネルやUPNP-HTTP-DAEMONチャンネルで使用される”RequestID”は、これらのチャンネルで送信される個々のリクエストを識別するための識別子である。

なお、表１は、各論理チャンネルにおいて、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００の一方がリクエスト側になるときの情報が例示したものである。但し、各論理チャンネルのそれぞれは、目的に応じて、ＭＦＰサーバ３００（ネットワークプロトコル制御部３０２）がリクエスト側になる第１の動作モードと、ＭＦＰデバイスユニット４００（デバイス制御部４０２）がリクエスト側になる第２の動作モードとを実現可能である。

このように、本実施例においてＵＳＢ転送に使用されるパケットでは、メッセージボディ部内に、ＩＤフィールドとエラーコードの２つのフィールドが設けられており、これらのフィールドを用いて、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間で特定の情報を送受信することができる。従って、例えばクライアントから送られたメッセージと、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間で通知される特定の情報とを容易に区別することが可能である。なお、このような特定のフィールドとしては、ＩＤフィールドやエラーコードに限らず、任意の特定のフィールドを利用することが可能である。このようなフィールドは、固定長とすることが好ましい。

なお、本実施例では、Ｄ４パケットによって、グローバルメッセージとローカルメッセージの両方を転送することが可能である。「グローバルメッセージ」は、ＵＰｎＰアーキテクチャのコントロールポイントとデバイス（この例ではＭＦＰデバイスユニット４００）との間で交換されるメッセージを意味する。また、「ローカルメッセージ」とは、ＵＰｎＰアーキテクチャのコントロールポイントが関与せず、単にＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間で交換されるメッセージを意味する。グローバルメッセージとローカルメッセージの例については後述する。なお、グローバルメッセージを転送する動作モードを「グローバル情報送受信モード」とも呼び、ローカルメッセージを転送する動作モードを「ローカル情報送受信モード」とも呼ぶ。

本実施例のＤ４パケットを用いてリクエストを転送する場合には、エラーフィールドの後のメッセージの先頭には、メッセージの送り元から送り先（受け手）へ通知するＵＲＩ（通常は相対ＵＲＩ）が付加される。メッセージの受け手は、このＵＲＩから、リクエストの内容や宛先を容易に判定することが可能である。なお、Ｄ４パケットのメッセージの具体的な内容については後述する。

本実施例では、ＵＳＢ転送用の論理チャンネルとして、印刷ポート用の論理チャンネルＣ＃１１〜ＣＨ＃１２と、ＵＰｎＰ用の論理チャンネルＣＨ＃２１〜ＣＨ＃２６とを別個に設けている。従って、ネットワーク印刷ポートを介してＭＦＰデバイスユニット４００に転送されてくる印刷データと、ＵＰｎＰ用のポートを介してＭＦＰデバイスユニット４００に転送されてくるＸＨＴＭＬデータとを容易に識別することができる。また、印刷データとＸＨＴＭＬデータにそれぞれに適した処理を実行して、正しく印刷を行うことができる。また、本実施例では、ＵＰｎＰプロトコルによるメッセージのＵＳＢ転送のために、用途の異なる複数の論理チャンネルＣＨ＃２１〜ＣＨ＃２６を設けているので、メッセージの受信側において、メッセージの内容の処理をより高速に処理することが可能である。但し、論理チャンネルの数や区分としては、これ以外の任意のものを採用することができる。また、本実施例では、論理チャンネルの識別子をＤ４パケットのヘッダ情報として設定しているので、異なる論理チャンネル用のパケットを容易に識別することが可能である。

図６は、ＵＰｎＰアーキテクチャを利用した処理の典型例を示すシーケンス図である。ここでは、コントロールポイント１１０Ｃと、ＭＦＰサーバ３００と、ＭＦＰデバイスユニット４００の間でメッセージが転送される場合を示している。ステップ[1]では、コントロールポイント１１０ＣがＨＴＴＰのリクエストメッセージＦ１をＭＦＰサーバ３００に転送する。メッセージＦ１のヘッダには、リクエスト命令（ＰＯＳＴやＧＥＴなどのメソッド）と、ＭＦＰデバイスユニット４００の１つのデバイスまたはサービスのＵＲＩと、複合機２００のＩＰアドレス（この例では169.254.100.100）とが記述されている。なお、ＩＰアドレスは、複合機２００に１つだけば割り当てられるので、このＩＰアドレスは、ＭＦＰサーバ３００のＩＰアドレス又はＭＦＰデバイスユニット４００のＩＰアドレスと考えることも可能である。

ステップ[2]では、ＭＦＰサーバ３００が、リクエストメッセージＦ１を解析する。ここで解析（解釈）されるのは、メッセージＦ１のヘッダ部分だけであり、送信データ（すなわちメッセージボディ）の内容の解釈は行わない。より具体的には、ステップ[2]において、メッセージＦ１のＵＲＩが解析され、ＭＦＰデバイスユニット４００内のどのデバイス又はサービスに送信データを転送すべきかが判定される。但し、リクエストメッセージＦ１に送信データが存在せず、ＵＲＩのみが送信される場合も存在する。

ステップ[3]では、ＭＦＰサーバ３００が、ＵＲＩと送信データ（存在する場合）とを含むメッセージＦ２を、ＵＳＢでＭＦＰデバイスユニット４００に転送する。この転送の際には、ＵＲＩに応じて、上述したＵＰｎＰの６つの論理チャンネルのいずれか１つが選択されて利用される。

ステップ[4]では、ＭＦＰデバイスユニット４００が、受信したメッセージＦ２内のＵＲＩ及び送信データ（存在する場合）に応じて処理を実行する。この例については後述する。ステップ[5]では、ＭＦＰデバイスユニット４００が、返信データを含むメッセージＲ１をＵＳＢでＭＦＰサーバ３００に転送する。ステップ[6]では、ＭＦＰサーバ３００が送信データにＨＴＴＰヘッダを付加する。このＨＴＴＰヘッダは、ＨＴＴＰリクエストの処理結果を示すステータスコードを含んでいる。例えば、処理結果がＯＫであればステータスコードが”２００”に設定され、エラーであれば”５００”に設定される。ステップ[7]では、こうして作成されたＨＴＴＰのレスポンスメッセージＲ２がＭＦＰサーバ３００からコントロールポイント１１０Ｃに転送される。

このように、本実施例では、ＭＦＰサーバ３００は、コントロールポイントから受信したリクエストメッセージのうちで、ヘッダの解析（解釈）は行うが、メッセージボディの内容の解釈は行わず、メッセージボディの内容はＭＦＰデバイスユニット４００によって解釈される。この構成には以下のような利点がある。第１の利点は、ＭＦＰサーバ３００が、ＭＦＰデバイスユニット４００のデバイス構成とサービスの内容を把握する必要が無く、任意の構成を有するデバイスユニット宛に送られたメッセージを転送するためのネットワークプロトコル制御部として機能することができる点である。第２の利点は、ＭＦＰデバイスユニット４００のデバイス構成やサービスの内容が変更されても、ＭＦＰサーバ３００の構成や機能を変更する必要が無い点である。第３の利点は、ＭＦＰサーバ３００にメッセージボディの内容の解釈を行う解釈部（パーサ）を実装する必要が無いので、ＭＦＰサーバ３００の構成が単純で済む点である。

C．複合機のデバイス構成及びデバイスディスクリプション：
図７（Ａ）は、複合機２００のＵＰｎＰプロトコル上のデバイス構成を示す説明図である。本実施例の複合機２００のＵＰｎＰデバイスとしての構成では、ルートデバイス（root Device）としてのベーシックデバイスＢＤの中に、プリンタデバイスPrinter1とスキャナデバイスScanner1とが包含されている。換言すれば、プリンタデバイスPrinter1とスキャナデバイスScanner1は、ベーシックデバイスＢＤにネストされている。プリンタデバイスPrinter1はプリントサービスを有しており、スキャナデバイスScanner1はスキャンサービスを有している。各サービスは、状態テーブルと、コントロールサーバと、イベントサーバとで構成されている。状態テーブルには、サービスの状態を示す状態変数が登録されている。コントロールサーバは、コントロールポイントからのアクション要求を受け付けて処理を実行する。イベントサーバは、状態変数の値が変更されると、その変更をイベントとしてコントロールポイントに通知する。通知対象となるのは、そのサービスに予めサブスクライブ（購読）しているコントロールポイントである。

本明細書では、サービスを含むデバイスを「サービスデバイス」と呼んでいる。なお、各サービスデバイスは、１つ以上の任意の数のサービスを含むことが可能である。また、サービスデバイスが、他のサービスデバイス（例えば記憶装置）を含むようにデバイス構成を構築することも可能である。

ベーシックデバイスＢＤは、１つ以上のサービスデバイスを含み、かつ、サービスデバイスが実行するサービスの他には自分自身が実行する固有のサービスを有さないデバイスとして構成される。このように、本実施例では、ＵＰｎＰプロトコルの上では複合機２００が１つのベーシックデバイスＢＤによって代表されているので、複合機２００に対して１つのＩＰアドレスを割り当てるだけで済むという利点がある。

図７（Ｂ）は、比較例のＵＰｎＰデバイス構成の一例を示している。この比較例では、プリンタデバイスPrinter1とスキャナデバイスScanner1とが別個のＵＰｎＰデバイスとして構成されている。この場合には、プリンタデバイスPrinter1とスキャナデバイスScanner1とに別個のＩＰアドレスが割り当てられる。

図７（Ａ）に示したように、本実施例では、複合機２００全体に対してＩＰアドレスが１つだけ割り当てられるので、コントロールポイントは、この１つのＩＰアドレスを用いて複合機２００（ＭＦＰサーバ３００）の種々のサービスデバイスにアクセスできるという利点がある。また、本実施例では、ＩＰアドレスの数が比較例よりも少なくて済むので、ネットワーク内におけるＩＰアドレスの管理がより容易であるという利点がある。

ＵＰｎＰの各デバイスは、自身の構成や機能をデバイスディスクリプションという形式で予め保持しており、コントロールポイントからの要求に応じてデバイスディスクリプションを提供する機能を有している。また、サービスの内容は、サービスディスクリプションとして形でデバイス内に保持され、コントロールポイントに提供される。図７（Ａ）の例では、プリンタデバイスPrinter1のデバイスディスクリプションと、プリントサービスのサービスディスクリプションと、スキャナデバイスScanner1のデバイスディスクリプションと、スキャンサービスのサービスディスクリプションとが、ＭＦＰデバイスユニット４００内に予め保持されている。但し、デバイスディスクリプション内のパラメータの一部は、複合機２００の構成（例えばサービスデバイスの数）に依存しているので、これらのパラメータは複合機２００の起動時に設定される。

図８は、複合機２００の起動時におけるデバイスディスクリプションの作成手順を示すフローチャートである。まず、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００が起動すると、ステップＳ１からステップＳ２に移行し、ＭＦＰサーバ３００が、ＭＦＰデバイスユニット４００から、ＭＦＰデバイスユニット４００のＵＳＢデバイスとしての構成を取得する。ここで、「ＵＳＢデバイスとしての構成」とは、図４（Ａ）に示したインタフェース／エンドポイント構成を意味している。ＭＦＰサーバ３００は、ＵＳＢの１つのインタフェース（論理的インタフェース）を、ＵＰｎＰアーキテクチャの１つのデバイス（本実施例における「サービスデバイス」）として認識することができる。ＭＦＰサーバ３００は、各デバイスに異なるデバイス識別子を割り当てる。

次に、複合機２００がネットワークに参加すると、ステップＳ３からステップＳ４に移行し、上述したアドレッシングによってＭＦＰサーバ３００がＩＰアドレスを取得する。ステップＳ５では、ＭＦＰサーバ３００が、ＩＰアドレスと各デバイスのデバイス識別子をＭＦＰデバイスユニット４００に送信する。ステップＳ６では、このＩＰアドレスとデバイス識別子とを用いてＭＦＰデバイスユニット４００（又はＭＦＰサーバ３００）がデバイスディスクリプションを作成する。

図９は、複合機２００のデバイスディスクリプションの例を示している。デバイスディスクリプションは、ＸＭＬで記述されている。アンダーラインを付した部分は、本実施例に特有の設定を示している。要素<URLBase>の内容”169.254.100.100:80”は、複合機２００のＩＰアドレスと、ＨＴＴＰを用いる場合のポート番号である。ディスクリプション内のいくつかのＵＲＩは、このＩＰアドレスに対する相対アドレスとして記述されている。なお、本明細書において、ＵＲＩ（又はＵＲＬ）は、絶対アドレスで記述されている場合と、相対アドレスで記述されている場合の両方を含んでいる。

要素<root>の下には二つの要素<device>が存在し、各デバイスの要素<deviceType>に示されているように、１番目のデバイスはプリンタであり、２番目のデバイスはスキャナである。

プリンタ用のディスクリプション内には、以下の内容が記述されている。
・<presentation URL>：コントロールポイントがプリンタデバイスのプレゼンテーション用のページを取得する際のＵＲＬ。このＵＲＬは、複合機２００のＩＰアドレス”169.254.100.100”と、ポート番号”８０”と、プリンタのデバイス識別子”Printer1”とで構成されている。ポート番号は省略可能である。
・<serviceList> :プリンタが提供するサービスのリスト。
・<serviceType>：プリンタが提供するサービスのタイプ。”PrintBasic”は、ＵＰｎＰアーキテクチャの標準的なプリントサービスである。
・<SCPDURL>：プリンタのデバイスディスクリプションのＵＲＬ。
・<controlURL>：プリンタデバイス内のコントロールサーバのＵＲＬ。「コントロールサーバ」とは、コントロールポイントに対してコントロール（コントロールポイントがアクション要求を含む制御メッセージをデバイスに転送して、デバイスの制御を行う処理）の機能を提供するサーバであり、一般にＵＰｎＰデバイスのサービス内に設けられている。コントロールサーバのＵＲＬは、プリンタのデバイス識別子と、サーバ名”control”とで構成されている。
・<eventSubURL>：プリンタデバイス内のイベントサーバのＵＲＬ。「イベントサーバ」とは、サブスクライブ（購読）しているコントロールポイントにイベントを発行するサーバであり、一般にデバイスのサービス内に設けられている。イベントサーバのＵＲＬは、プリンタのデバイス識別子と、サーバ名”event”とで構成されている。

以上の要素の内容（パラメータ）のうちで、ＩＰアドレス”169.254.100.100”と、デバイス識別子”Printer1”とは、図８のステップＳ５においてＭＦＰサーバ３００からＭＦＰデバイスユニット４００に送信された値に応じて設定されたものである。

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

図１０は、コントロールポイントによるデバイスディスクリプション取得のシーケンスを示している。ステップ[1]では、コントロールポイント１１０Ｃが、ＭＦＰサーバ３００にデバイスディスクリプションのリクエストメッセージＦ１１を発行する。このメッセージＦ１１は、デバイスディスクリプションを示すＵＲＩ”/DevDesc.xml”と、複合機２００のＩＰアドレス”169.254.100.100”とを含んでいる。なお、デバイスディスクリプションを示すＵＲＩ”/DevDesc.xml”は、ＵＰｎＰディスカバリにおいて、デバイスからコントロールポイントに通知する、ルートデバイスのディスクリプション用URLがもとになっている。

ステップ[2]では、ＭＦＰサーバ３００が、リクエストメッセージＦ１１のＵＰｎＰプロトコルを解析し、ステップ[3]においてリクエスト先のＵＲＩ”/DevDesc.xml”を含むメッセージＦ１２をＭＦＰデバイスユニット４００に転送する。この転送は、ＵＳＢのUPNP-DESCRIPTIONチャンネルを用いて行われる。

ステップ[4]では、ＭＦＰデバイスユニット４００が、受信したメッセージＦ１２の内容を解釈して、デバイスディスクリプションを要求していることを判定する。ステップ[5]では、ＭＦＰデバイスユニット４００が、デバイスディスクリプションを含むメッセージＲ１１をＵＳＢでＭＦＰサーバ３００に転送する。なお、このメッセージＲ１１の先頭部分には、リクエストの結果を示すフィールド”RE”と、ＨＴＴＰの結果を示すフィールド”HR”とが設定される。REフィールドの値は、リクエストが成功した場合には”００００”に設定され、失敗した場合には”００００”以外の値に設定される。HRフィールドの値は、処理結果がＯＫであれば”２００”に設定され、エラーであれば”５００”に設定される。なお、HRフィールドの値は、ＨＴＴＰのステータスコードとしてそのまま使用される。

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

以上のように、本実施例では、１つのベーシックデバイスＢＤにサービスデバイスがネストされたデバイス構成を有しているので、デバイスディスクリプションの作成が容易であるというという利点がある。この利点は、特に、サービスデバイスの個数や種類が変更された場合に顕著である。すなわち、複合機が多種多様なサービスデバイスを含んでいる場合にも、すべてのサービスデバイスをベーシックデバイスＢＤ内にネストすれば良いので、デバイスディスクリプションを容易に作成することが可能である。

図１０の説明では、複合機２００全体のデバイスディスクリプション（図９）をＭＦＰデバイスユニット４００が作成するものとしていたが、この代わりに、ＭＦＰサーバ３００がこの全体のデバイスディスクリプションを作成するものとしてもよい。この場合には、ＭＦＰサーバ３００が各デバイスのデバイスディスクプリション（図９の場合にはプリンタ用とスキャナ用の２つのデバイスディスクリプション）を各デバイスから受け取り、これを利用して全体のデバイスディスクリプションを作成することができる。全体のデバイスディスクリプションの作成は、図１０に示すようにコントロールポイントからの要求があった場合に実行してもよく、あるいは、全体のデバイスディスクリプションを予め作成してＭＦＰサーバ３００内に保持しておいてもよい。

なお、図２に示すように、複合機２００のＵＳＢ端子３５６には、追加のＭＦＰデバイスユニットを接続することが可能である。この追加のＭＦＰデバイスユニットが接続された場合には、複合機２００のデバイス構成が再構築される。

図１１は、デバイスユニットが追加された場合のデバイス構成の再構築処理を示すフローチャートである。ステップＳ１１でデバイスユニットが追加されると、ステップＳ１２において、ＭＦＰサーバ３００がネットワークから切断することをブロードキャスト（退出のアドバタイズ）する。ステップＳ１３では、ＭＦＰサーバ３００が、追加デバイスユニットからＵＳＢデバイス構成（インタフェース／エンドポイント構成）を取得する。ステップＳ１４では、ＭＦＰサーバ３００から追加デバイスユニットに、ＩＰアドレスとデバイス識別子を送信する。ステップＳ１５では、このＩＰアドレスとデバイス識別子とを用いて複合機２００全体のデバイスディスクリプションが再作成される。ステップＳ１６では、ＭＦＰサーバ３００が、ネットワークに接続したことをマルチキャスト（接続のアドバタイズ）する。この接続のアドバタイズからディスカバリが開始され、複合機２００が各コントロールポイントによって検出される。

図１２は、ＭＦＰデバイスユニットを追加した場合の複合機２００のＵＰｎＰデバイス構成を示す説明図である。ここでは、追加デバイスユニットが、プリンタデバイスのみを有しているものと仮定している。図７（Ａ）と比較すれば理解できるように、この追加プリンタデバイスは、ベーシックデバイスＢＤの下位のデバイスとして、ベーシックデバイスＢＤにネストされる。また、この追加プリンタデバイスには、ＭＦＰデバイスユニット４００のプリンタデバイスのデバイス識別子”Printer1”とは異なるデバイス識別子”Printer2”が割り当てられる。なお、追加デバイスユニットとして、他の種類のサービスデバイス（例えば外部記憶装置）が接続された場合には、そのデバイスの種類に応じたデバイス識別子が割り当てられる。

図示は省略するが、複合機２００全体のデバイスディスクリプションとしては、図９に示したデバイスディスクリプションのスキャナ用のディスクリプションの後に、２番目のプリンタデバイスのデバイスディスクリプションが追加される。

なお、このようなデバイスユニットの追加を許容するようにＭＦＰサーバ３００を構成する場合には、複合機２００全体のデバイスディスクリプションを、ＭＦＰサーバ３００が作成することが好ましい。この理由は、ＭＦＰデバイスユニット４００は、他のデバイスユニットがＭＦＰサーバ３００に接続されているか否かが解らないためである。従って、ＭＦＰサーバ３００は、各デバイスユニットからデバイスディスクリプションを取得して、図９のような複合機２００全体のデバイスディスクリプションを作成し、保持することが好ましい。この場合には、図１０に示したシーケンスにおいて、ステップ[3]〜[5]を行わずに、ＭＦＰサーバ３００が、予め保持したおいたデバイスディスクリプションをコントロールポイント１１０Ｃに返送することができる。

図９に示したように、各デバイスユニットからＭＦＰサーバ３００に転送される個々のデバイスのデバイスディスクリプションは、ＩＰアドレスとデバイス識別子とが埋め込まれたものである。従って、ＭＦＰサーバ３００は、図９のデバイスディスクリプションの中で、個々のデバイス（サービスデバイス）のディスクリプションを含まないものをテンプレートとして準備しておき、各デバイスから転送されてきたデバイスディスクリプションをテンプレートに埋め込むことによって複合機２００全体のデバイスディスクリプションを作成することができる。

なお、ＭＦＰサーバ３００に複数のデバイスユニットが接続されている状態から、１つのデバイスユニットが取り外されたときには、図１１と同様な手順によってデバイス構成及びデバイスディスクリプションが再構築される。

このように、本実施例のＭＦＰサーバ３００には、種々のデバイスユニットを着脱することができ、また、実際にＭＦＰサーバ３００に接続されているデバイスユニットの数と種類に応じて複合機２００全体のデバイスディスクリプションが生成される。従って、ＵＰｎＰ対応の複合機２００として、種々のデバイス構成を容易に実現することが可能である。

D．印刷ジョブ実行シーケンス：
図１３、図１４は、コントロールポイントからの要求に応じて複合機２００が印刷を実行する手順を示すシーケンス図である。図１３のステップ[1]では、コントロールポイント１１０Ｃが、印刷ジョブの作成を要求するリクエストメッセージＦ２１をＭＦＰサーバ３００に転送する。図１５に示すように、このリクエストメッセージＦ２１のヘッダには、プリンタデバイスのコントロールＵＲＩ”/Printer1/Control”と、複合機２００のＩＰアドレス”169.254.100.100”とが記述されている。さらに、SOAPACTIONヘッダには、ＵＰｎＰのサービスタイプを示す文字列”PrintBasic”と、印刷ジョブを作成する命令であることを示す文字列”CreateJob”とが設定されている。また、ＨＴＴＰヘッダの後には、ＳＯＡＰデータ（「ＳＯＡＰメッセージ」とも呼ぶ）が付加されている。また、ＳＯＡＰエンベロープにも、サービスタイプと、命令の種類を示す文字列が設定されている。ＳＯＡＰエンベロープは、このメッセージＦ２１のボディに相当する。なお、図１５のメッセージＦ２１において、アンダーラインが付されている部分は、このメッセージＦ２１に特有な部分である。

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

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

ステップ[3]では、ＭＦＰサーバ３００が、プリンタデバイスのコントロールＵＲＬとＳＯＡＰデータとを含むメッセージＦ２２をＭＦＰデバイスユニット４００に転送する。このメッセージＦ２２は、図１５に示すように、コントロールポイントから送られてきたＳＯＡＰデータをそのままコピーし、その先頭にコントロールＵＲＬ”URI:/Printer1/control”を付加したものである。なお、ＵＳＢパケットのＩＤフィールド（図５参照）にはジョブ識別子が設定される。また、転送にはUPNP-ACTIONチャンネルが利用される。

図１３のステップ[4]では、ＭＦＰデバイスユニット４００が、受信したメッセージＦ２２内のＳＯＡＰアクションを解析し、ＳＯＡＰアクションに応じて処理を実行する。ここでは、ＳＯＡＰアクションがジョブ作成要求なので、印刷すべき文書を表す文書データ（ＸＨＴＭＬデータ）の送付先ＵＲＩが設定された返信用のＳＯＡＰデータが作成される。ステップ[5]では、ＭＦＰデバイスユニット４００が、このＳＯＡＰデータを含むメッセージＲ２１をＵＳＢでＭＦＰサーバ３００に転送する。図１５に示すように、このメッセージＲ２１は、リクエストの結果を示すREフィールドと、ＨＴＴＰの結果を示すHRフィールドと、ＳＯＡＰデータ（ＳＯＡＰエンベロープ）とで構成されている。ここでは、リクエスト（印刷ジョブの作成）が成功したので、REフィールドには”0000”が設定され、HRフィールドには”200”が設定されている。リクエストが失敗したときには、他の所定の値がそれぞれ設定される。なお、ＳＯＡＰデータは、ジョブ作成命令の応答であることを示す文字列”CreateJobResponse”を含むＳＯＡＰエンベロープである。このＳＯＡＰエンベロープには、ＸＨＴＭＬデータの送付先ＵＲＩ”/Printer1/DataSink/00000003”と、ジョブ識別子”３”とが埋め込まれている。ジョブ識別子の値”３”は、ステップ[3]でＭＦＰサーバ３００から供給されたものが使用される。なお、本実施例では、ＸＨＴＭＬ送付先ＵＲＩの末尾は、ジョブ識別子と同じ値を示す８桁の１６進数に設定されている。

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

図１４のステップ[8]では、コントロールポイント１１０Ｃが、ＸＨＴＭＬ送付先ＵＲＩ”/Printer1/DataSink/00000003”に対してＸＨＴＭＬデータを送るためのリクエストメッセージＦ３１を送信する。

ＸＨＴＭＬデータには、ＸＨＴＭＬの規定に従ってレイアウトされたテキストおよび画像が含まれる。

なお、ＸＨＴＭＬデータに含まれる画像データは、Internet Engineering Task Forceが規定したＲＦＣ３３９１に準拠した方式でＸＨＴＭＬデータ内に埋め込むことも可能であり、また、画像サーバ１３０（図１）から画像を取得するための参照ＵＲＩを設定することも可能である。

ステップ[9]では、ＭＦＰサーバ３００が、リクエストメッセージＦ３１についてＵＰｎＰプロトコルの解析を実行する。この解析の結果、このメッセージＦ３１の宛先のＵＲＩ”/Printer1/DataSink/00000003”が認識され、また、このＵＲＩの末尾からジョブ識別子の値”３”が抽出される。

ステップ[10]では、ＭＦＰサーバ３００が、ＸＨＴＭＬ送付先ＵＲＬ”/Printer1/DataSink/00000003”とＸＨＴＭＬデータとを含むメッセージＦ３２をＭＦＰデバイスユニット４００に転送する。また、ＵＳＢパケットのＩＤフィールド（図５参照）にはジョブ識別子が設定される。この、転送にはUPNP-XHTML-PRINTチャンネルが利用される。

図１４のステップ[11]では、ＭＦＰデバイスユニット４００が、受信したメッセージＦ３２内のＸＨＴＭＬデータを解析し、印刷を実行する。なお、ＸＨＴＭＬデータ内に画像データ取得用の参照ＵＲＩが設定されている場合には、ＭＦＰデバイスユニット４００は、この参照ＵＲＩを用いて画像サーバ１３０から画像データを取得する。この画像データの取得の際には、ＵＳＢのUPNP-HTTP-CLIENTチャンネル（図３）が使用される。

ステップ[12]では、ＭＦＰデバイスユニット４００が、ジョブ識別子と、リクエストの結果を示すREフィールド及びHRフィールドを含むメッセージＲ３１をＵＳＢでＭＦＰサーバ３００に転送する。なお、ジョブ識別子は、ＵＳＢパケットのＩＤフィールドに埋め込まれている。

ステップ[13]では、ＭＦＰサーバ３００がメッセージＲ３１のHRフィールドを解析し、その値をＨＴＴＰヘッダのステータスコードとして設定する。ステップ[14]では、こうして作成されたＨＴＴＰのレスポンスメッセージＲ３２がＭＦＰサーバ３００からコントロールポイント１１０Ｃに転送される。

このように、印刷ジョブ実行シーケンスでは、印刷すべき文書を表すＸＨＴＭＬデータの内容は、ＭＦＰサーバ３００によって解析されず、ＭＦＰデバイスユニット４００によって解析される。従って、ＭＦＰサーバ３００に、ＸＨＴＭＬパーサを実装しなくても済むという利点がある。

仮に、ＭＦＰサーバ３００にＸＨＴＭＬパーサを実装する場合には、ＸＨＴＭＬデータに含まれる印刷仕様（特に印刷用紙の種類や用紙サイズ）にＭＦＰデバイスユニット４００が対応しているか否かをＭＦＰサーバ３００が把握する必要が生じる。これに対して、上記実施例では、ＭＦＰデバイスユニット４００が対応可能な印刷仕様をＭＦＰサーバ３００が把握している必要が無いので、ＭＦＰサーバ３００の実装がより容易であるという利点がある。

E．アクション実行シーケンス：
ＵＳＢのUPNP-ACTIONチャンネル（図４）を用いて転送されるアクションには、以下に説明するように、グローバルアクションとローカルアクションとが存在する。

図１６は、グローバルアクションの実行シーケンスの一例を示す図である。ここでは、図１３で開始した印刷ジョブをキャンセルする場合を示している。なお、図１３のステップ[1]〜[7]で説明した印刷ジョブの作成も、グローバルアクションの一種である。

図１６のステップ[1]では、コントロールポイント１１０Ｃが、印刷ジョブのキャンセルを要求するリクエストメッセージＦ４１をＭＦＰサーバ３００に転送する。図１７に示すように、このリクエストメッセージＦ４１のヘッダには、プリンタデバイスのコントロールＵＲＩ”/Printer1/Control”と、複合機２００のＩＰアドレス”169.254.100.100”とが記述されている。また、メッセージＦ４１内のSOAPACTIONヘッダには、ＵＰｎＰのサービスタイプを示す文字列”PrintBasic”と、印刷ジョブをキャンセルする命令であることを示す文字列”CancelJob”とが設定されている。ＳＯＡＰエンベロープにも、これらの文字列が設定されており、また、キャンセルすべきジョブのジョブ識別子の値”３”も設定されている。

図１６のステップ[2]では、ＭＦＰサーバ３００が、リクエストメッセージＦ４１についてＨＴＴＰヘッダ部の解析を実行し、このメッセージＦ４１の宛先であるコントロールＵＲＩ”/Printer1/Control”を認識し、また、アクションの内容が印刷ジョブのキャンセル要求であることを認識する。

ステップ[3]では、ＭＦＰサーバ３００が、プリンタデバイスのコントロールＵＲＩ”/Printer1/Control”とＳＯＡＰデータとを含むメッセージＦ４２をＵＳＢでＭＦＰデバイスユニット４００に転送する。このメッセージＦ４２は、図１７に示すように、コントロールポイントから送られてきたＳＯＡＰデータをそのままコピーし、その先頭にコントロールＵＲＩを付加したものである。なお、転送にはUPNP-ACTIONチャンネルが利用される。

図１６のステップ[4]では、ＭＦＰデバイスユニット４００が、受信したメッセージＦ４２内のＳＯＡＰアクションを解析し、ＳＯＡＰアクションに応じて処理を実行する。ここでは、ＳＯＡＰアクションがジョブのキャンセル要求なので、ジョブ識別子が”３”である印刷ジョブがキャンセルされる。ステップ[5]では、ＭＦＰデバイスユニット４００が、返信用のＳＯＡＰデータを含むメッセージＲ４１をＵＳＢでＭＦＰサーバ３００に転送する。図１７に示すように、このメッセージＲ４１は、リクエストの結果を示すREフィールドと、ＨＴＴＰの結果を示すREフィールドと、ＳＯＡＰデータとで構成されている。ＳＯＡＰデータは、ジョブのキャンセル命令の応答であることを示す文字列”CancelJobResponse”を含むＳＯＡＰエンベロープである。

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

以上の例からも理解できるように、一般に、コントロールポイントからデバイスへのアクションの要求（リクエスト）と応答（レスポンス）には、ＳＯＡＰデータが使用される。

図１８は、ローカルアクションの実行シーケンスの一例を示す図である。ローカルアクションでは、コントロールポイント１１０Ｃは関与せず、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間でのみメッセージが交換される。ステップ[1]では、ＭＦＰサーバ３００が、ローカルアクションのメッセージＦ５１をＵＳＢでＭＦＰデバイスユニット４００に転送する。このメッセージＦ５１は、図１９に示すように、プリンタデバイスのコントロールＵＲＩ”URI:/Local/Control”と、ＳＯＡＰデータを含んでいる。このメッセージヘッダの文字列”/Local/control”は、ローカルアクションであることを示している。ＳＯＡＰエンベロープには、ローカルな情報取得命令として”X_GetInfo”が設定されている。なお、ローカルアクションの命令は、デバイス毎に任意に定義することが可能である。

このメッセージＦ５１は、グローバルアクションにおいてＭＦＰサーバ３００からＭＦＰデバイスユニット４００にＵＳＢ転送されるメッセージＦ４２（図１７）と類似している。但し、グローバルアクションのメッセージＦ４２では、ヘッダ部分がURI:/Printer1/controlであるのに対して、ローカルアクションのメッセージＦ５１では、ヘッダ部分が/Local/controlに設定されている点が異なる。従って、ＭＦＰデバイスユニット４００のプリンタデバイスは、メッセージのヘッダに応じて、グローバルアクションかローカルアクションかを識別することができる。

図１８のステップ[2]では、ＭＦＰデバイスユニット４００が、受信したメッセージＦ５１内のＳＯＡＰアクションを解析し、ＳＯＡＰアクションに応じて処理を実行する。ここでは、ＳＯＡＰアクションが情報取得要求なので、ＭＦＰデバイスユニット４００の所定の情報を含むＳＯＡＰデータが作成される。ステップ[3]では、ＭＦＰデバイスユニット４００が、返信用のＳＯＡＰデータを含むメッセージＲ５１をＵＳＢでＭＦＰサーバ３００に転送する。図１９に示すように、このメッセージＲ５１は、リクエストの結果を示すREフィールドと、ＳＯＡＰデータとで構成されている。なお、ローカルアクションの返信メッセージＲ５１では、ＨＴＴＰの結果を示すHRフィールドは設定されておらず、この点でグローバルアクションの返信メッセージＲ４１（図１７）と異なっている。

ＭＦＰサーバ３００は、メッセージＲ５１を受け取ると、そのREフィールドを解析し、ローカルアクションが成功したか否かを判定する。なお、このメッセージＲ５１には、HRフィールドが含まれていないので、コントロールポイントにレスポンスを返すことは無い。

このように、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間においては、グローバルなメッセージＦ４２，Ｒ４１（図１７）を交換することができ、また、ローカルなメッセージＦ５１，Ｒ５１（図１９）を交換することも可能である。上述したように、グローバルなメッセージ交換であるか、ローカルなメッセージ交換であるかは、ＭＦＰサーバ３００からＭＦＰデバイスユニット４００に転送されるメッセージＦ５１の先頭部分に設けられたヘッダによって判別されるので、ＭＦＰデバイスユニット４００は、両者の区別を容易に行うことが可能である。

F．イベント発行シーケンス：
図２０は、イベント発生時のシーケンスの一例を示す図である。図７（Ａ）に示したように、ＵＰｎＰデバイスのサービスには、イベントサーバと状態テーブルとが設けられている。状態テーブルは、そのサービスの種々の状態を示す状態変数を格納したテーブルである。「イベント」とは、状態テーブルの値（状態変数）が変化したことを意味する。イベントサーバは、状態テーブルの値が変化すると、そのサービスにサブスクライブ（購読）しているコントロールポイントにイベントの発生を通知する。

イベントが発生すると、まず図２０のステップ[1]において、ＭＦＰデバイスユニット４００が、発生したイベントを記述したＸＭＬデータＥ０（以下、「状態変数ＸＭＬデータ」と呼ぶ）を作成する。図２１に示すように、この状態変数ＸＭＬデータＥ０の先頭にある<e:propertyset>タグには、イベントの発生であることを示す属性”event”が設定されている。また、状態変数としては、<PrinterState>がアイドル（非動作）に変更されたことを示す文字列”idle”が設定されている。ここでは、プリンタサービスの状態変数が、動作中（processing）から非動作（idle）に変化したものと仮定している。

ステップ[2]では、ＭＦＰデバイスユニット４００が、イベント発生のメッセージＥ１をＭＦＰサーバ３００にＵＳＢで転送する。このメッセージＥ１は、図２１に示すように、プリンタデバイスPrinter1のイベントであることを示すヘッダ”ESU:/Printer1/event;”が、元の状態変数ＸＭＬデータＥ０の前に付加されたものである。この転送には、ＵＳＢのUPNP-EVENTチャンネルが使用される。

図２０のステップ[3]では、ＭＦＰサーバ３００が、メッセージＥ１を正常に受信したことを示す返信メッセージＥ２をＭＦＰデバイスユニット４００にＵＳＢで転送する。この返信メッセージＥ２には、レスポンスフィールドが含まれている。

ステップ[4]では、ＭＦＰサーバ３００が、ステップ[2]で受信したメッセージＥ２にＨＴＴＰヘッダを追加して、コントロールポイントへのメッセージＥ３を作成する。図２１に示すように、このメッセージＥ３のＨＴＴＰヘッダは、イベントの宛先の相対ＵＲＬ”/UCPE/EVENTNOTIFY”と、イベントの宛先であるコントロールポイントのＩＰアドレス”169.254.10.116:8000”とが含まれている。なお、ポート番号”8000”は、イベントの通知用に予め設定された値である。

コントロールポイント１１０Ｃは、メッセージＥ３を受信すると、ステップ[6]においてＨＴＴＰレスポンスのメッセージＥ４をＭＦＰサーバ３００に返信する。

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

G．第２実施例：
図２２は、本発明の第２実施例における複合機２００ａの内部構成を示すブロック図である。図２に示した第１実施例の複合機２００との差異は、ＭＦＰサーバ３００ａとＭＦＰデバイスユニット４００ａとの間がＵＳＢ接続ではなく、両者がバスで接続されている点である。これに伴って、第２実施例では、両者を接続するためのＵＳＢ機器（コネクタ３５４，４６２，ＵＳＢデバイス制御部４６０）が省略されている。但し、ＵＳＢホスト制御部３５０は、他の装置（無線通信回路や追加のデバイスユニット）の接続のために残されている。また、第２実施例において、中央制御部３１０とＲＡＭ３２０とＲＯＭ３３０は、ＭＦＰサーバ３００ａとＭＦＰデバイスユニット４００ａとで共用されている。従って、中央制御部３１０は、ＭＦＰサーバ３００ａの制御機能を実現するためのプログラムと、ＭＦＰデバイスユニット４００ａの制御機能を実現するためのプログラムと、の両方を実行する。第２実施例の他のハードウェア構成は、第１実施例と同じである。

図２３は、第２実施例におけるＭＦＰサーバ３００ａとＭＦＰデバイスユニット４００ａのＵＰｎＰアーキテクチャに関連する機能の階層構造を示すブロック図である。図３に示す第１実施例の構造と比較すれば理解できるように、第２実施例では、ＵＳＢ転送のための階層が省略されている。但し、ＭＦＰサーバ３００ａのサービスプロトコル解釈部１０００と、ＭＦＰデバイスユニット４００ａの印刷サービス解釈部２０００との間の６つの双方向論理チャンネルは、第１実施例と同じである。第２実施例では、ＭＦＰサーバ３００ａの制御機能とＭＦＰデバイスユニット４００ａの制御機能が、同一の中央制御部（ＣＰＵ）３１０で実行される異なるプロセスとして実現されている。従って、ＭＦＰサーバ３００ａとＭＦＰデバイスユニット４００ａとの間のメッセージの交換は、ＵＳＢ転送でなく、これらのプロセス間のメッセージ交換によって行われる。

第１，第２実施例から理解できるように、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間のメッセージ交換は、ＵＰｎＰプロトコルとは異なる通信プロトコルによって行われる。

この第２実施例によっても、第１実施例と同様に、ＭＦＰサーバ３００ａは、ＬＡＮ上の他の装置とＭＦＰデバイスユニット４００ａとの間で交換されるメッセージを仲介するネットワークプロトコル制御部３０２（図１）としての機能を有している。従って、ＭＦＰデバイスユニット４００ａの構成に依存せずに、ＭＦＰサーバ３００ａを容易に構成することができるという利点がある。

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

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

H２．変形例２：
上記実施例では、印刷すべき文書を表す言語としてＸＨＴＭＬを用いていたが、ＸＨＴＭＬ以外の文書記述言語を用いることも可能である。

H３．変形例３：
上記実施例では、印刷サービスを有するプリンタに関して説明したが、本実施例では、他の任意のサービスを提供するデバイスにも適用可能である。例えば、スキャンサービスや、コンテントディレクトリサービスなどを提供するデバイスにも適用可能である。ここで、「コンテントディレクトリサービス」とは、静止画、動画、音楽などのコンテンツを提供するサービスである。

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

本発明の実施例を適用するネットワークシステムの構成を示す概念図である。 複合機の内部構成を示すブロック図である。 ＭＦＰサーバとＭＦＰデバイスユニットのＵＰｎＰアーキテクチャに関連する機能の階層構造を示すブロック図である。 ＵＳＢのインタフェース／エンドポイント構成と論理チャンネルの構成とを示す説明図である。 ＵＳＢ転送に用いられるパケットの構成を示す説明図である。 ＵＰｎＰアーキテクチャを利用した処理の典型例を示すシーケンス図である。 実施例と比較例のＵＰｎＰデバイス構成を示す説明図である。 複合機の起動時におけるデバイスディスクリプションの作成手順を示すフローチャートである。 複合機のデバイスディスクリプションの例を示す説明図である。 コントロールポイントによるデバイスディスクリプション取得のシーケンス図である。 デバイスユニットが追加された場合のデバイス構成の再構築処理を示すフローチャートである。 ＭＦＰデバイスユニットを追加した場合の複合機のＵＰｎＰデバイス構成を示す説明図である。 コントロールポイントからの要求に応じて印刷を実行する手順を示すシーケンス図である。 コントロールポイントからの要求に応じて印刷を実行する手順を示すシーケンス図である。 印刷ジョブ実行時のメッセージの例を示す説明図である。 グローバルアクションの実行手順を示すシーケンス図である。 グローバルアクションのメッセージの例を示す説明図である。 ローカルアクションの実行手順を示すシーケンス図である。 ローカルアクションのメッセージの例を示す説明図である。 イベント発生時の処理手順を示すシーケンス図である。 イベント発生時のメッセージの例を示す説明図である。 第２実施例における複合機の内部構成を示すブロック図である。 第２実施例におけるＭＦＰサーバとＭＦＰデバイスユニットのＵＰｎＰアーキテクチャに関連する機能の階層構造を示すブロック図である。

符号の説明

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

Claims (14)

1. ネットワーク型プラグアンドプレイに対応したネットワーク装置であって、
   ネットワーク上のクライアントからの要求に応じてサービスを実行する１つ以上のサービスデバイスと、
   前記サービスデバイスの制御を行うデバイス制御部と、
   メッセージヘッダとメッセージボディとを有するメッセージを、前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの情報を前記デバイス制御部に転送するネットワークプロトコル制御部と、
   を備え、
   前記ネットワークプロトコル制御部は、前記クライアントから受信した前記メッセージボディの内容を解釈すること無く前記ネットワーク型プラグアンドプレイのプロトコルに従って前記メッセージヘッダを解釈するとともに、前記ネットワーク型プラグアンドプレイのプロトコルとは異なる通信プロトコルに従って前記メッセージボディを前記デバイス制御部に送信し、
   前記デバイス制御部は、前記ネットワークプロトコル制御部から受信した前記メッセージボディの内容を解釈するとともに、前記解釈の結果に応じて前記サービスデバイスにサービスを実行させる、ネットワーク装置。
2. 請求項１記載のネットワーク装置であって、
   前記ネットワークプロトコル制御部は、前記デバイス制御部から受信したメッセージを、メッセージボディとし、メッセージヘッダを付加した上で、前記ネットワーク上のクライアントへ送信する機能を有し、
   前記デバイス制御部は、前記クライアントに送信したい情報をメッセージとして、前記ネットワーク型プラグアンドプレイのプロトコルとは異なる通信プロトコルに従って前記ネットワークプロトコル制御部に送信し、
   前記ネットワークプロトコル制御部は、前記デバイス制御部から受信した前記メッセージボディの内容を解釈すること無く前記ネットワーク型プラグアンドプレイのプロトコルに従って前記メッセージヘッダを付加するとともに、前記メッセージヘッダと前記メッセージボディからなるメッセージを前記クライアントに送信する、ネットワーク装置。
3. 請求項１又は２記載のネットワーク装置であって、
   前記ネットワーク装置は、単一のＩＰアドレスが割り当てられる単一のネットワーク装置として機能し、
   個々のサービスデバイスは、前記ネットワーク装置のＩＰアドレスと、各サービスデバイスに割り当てられたデバイス識別子とによって識別される、ネットワーク装置。
4. 請求項３記載のネットワーク装置であって、
   前記ネットワーク装置は、前記ネットワーク型プラグアンドプレイのアーキテクチャに従ったデバイス構成として、前記ネットワーク装置を代表する単一のルートデバイスとしてのベーシックデバイス内に前記サービスデバイスが包含されているネストされたデバイス構成を有している、ネットワーク装置。
5. 請求項４記載のネットワーク装置であって、
   前記ベーシックデバイスは、前記サービスデバイスが実行するサービスの他には、前記ベーシックデバイス自身が実行する固有のサービスを有さないデバイスとして構成されている、ネットワーク装置。
6. 請求項１ないし５のいずれかに記載のネットワーク装置であって、
   前記ネットワークプロトコル制御部と前記デバイス制御部との間の通信は、異なる用途にそれぞれ割り当てられた複数の双方向論理チャンネルを用いたパケット通信によって実行される、ネットワーク装置。
7. 請求項６に記載のネットワーク装置であって、
   前記各論理チャネルは、目的に応じて、前記ネットワークプロトコル制御部がリクエスト側になる第１の動作モードと前記デバイス制御部がリクエスト側になる第２の動作モードとを実現可能であり、
   各論理チャネルのリクエストおよびリプライメッセージのボディ部には、送り元から送り先へ通知される特定種類の情報を格納するための所定のフィールドが設けられている、ネットワーク装置。
8. 請求項７に記載のネットワーク装置であって、
   前記論理チャネルのメッセージボディ部から前記所定のフィールドを除いたメッセージボディ部において、当該メッセージボディ部の先頭に、メッセージの送り元から送り先へ通知するＵＲＩが付加される、ネットワーク装置。
9. 請求項６記載のネットワーク装置であって、
   前記ネットワークプロトコル制御部と前記デバイス制御部は、
   （ｉ）前記デバイス制御部と前記ネットワーク上のクライアントとの間で交換されるグローバルな情報を、前記ネットワークプロトコル制御部と前記デバイス制御部との間で送受信するグローバル情報送受信モードと、
   （ｉｉ）前記ネットワーク上のクライアントには無関係に、前記ネットワークプロトコル制御部と前記デバイス制御部との間で交換されるローカルな情報を送受信するローカル情報送受信モードとを有しており、
   前記グローバル情報送受信モードとローカル情報送受信モードは、メッセージのヘッダによって識別される、ネットワーク装置。
10. 請求項３記載のネットワーク装置であって、
    前記ネットワーク装置は、前記ネットワーク型プラグアンドプレイのプロトコルに対応した第１の装置としての機能と、前記ネットワーク型プラグアンドプレイ以外のネットワークプロトコルに対応した第２の装置としての機能とを有しており、
    前記ネットワーク装置は、前記第１の装置として機能するときには所定の第１のポート番号によってアクセスされ、前記第２の装置として機能するときには前記第１のポート番号とは異なる第２のポート番号によってアクセスされる、ネットワーク装置。
11. 請求項１０記載のネットワーク装置であって、
    前記サービスデバイスは、印刷機構を含み、
    前記第１の装置は、前記ネットワーク型プラグアンドプレイのプロトコルに対応した第１のプリンタであり、
    前記第２の装置は、前記ネットワーク型プラグアンドプレイのプロトコル以外のネットワークプロトコルに対応した第２のプリンタであり、
    前記デバイス制御部は、
    （ｉ）前記ネットワーク装置が前記第１のプリンタとして機能するときには、文書記述言語を含むメッセージボディを前記ネットワーク上のクライアントから受信し、前記文書記述言語を解釈してドットの形成状態を表す印刷データを作成するとともに、作成した印刷データを前記印刷機構に供給し、
    （ｉｉ）前記ネットワーク装置が前記第２のプリンタとして機能するときには、前記第２のプリンタ固有の制御コマンドからなる印刷データを前記ネットワーク上のクライアントから受信して前記印刷機構に供給する、ネットワーク装置。
12. 請求項１１記載のネットワーク装置であって、
    前記ネットワークプロトコル制御部と前記デバイス制御部との間の通信は、前記ネットワーク装置が前記第１のプリンタとして機能するときに利用される第１種の論理チャンネル群と、前記ネットワーク装置が前記第２のプリンタとして機能するときに利用される第２種の論理チャンネル群と、を用いたパケット通信によって実行される、ネットワーク装置。
13. ネットワーク上のクライアントからの要求に応じてサービスを実行する１つ以上のサービスデバイスと、前記サービスデバイスの制御を行うデバイス制御部とを含むネットワーク型プラグアンドプレイに対応したネットワーク装置を制御する方法であって、
    （Ａ）メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの情報を前記デバイス制御部に転送する工程、
    を備え、
    前記工程（Ａ）は、
    前記クライアントから受信した前記メッセージボディの内容を解釈すること無く前記ネットワーク型プラグアンドプレイのプロトコルに従って前記メッセージヘッダを解釈するとともに、前記ネットワーク型プラグアンドプレイのプロトコルとは異なる通信プロトコルに従って前記メッセージボディを前記デバイス制御部に送信する工程と、
    前記デバイス制御部が、前記ネットワークプロトコル制御部から受信した前記メッセージボディの内容を解釈するとともに、前記解釈の結果に応じて前記サービスデバイスにサービスを実行させる工程と、
    を含む、ネットワーク装置の制御方法。
14. ネットワーク上のクライアントからの要求に応じてサービスを実行する１つ以上のサービスデバイスと、前記サービスデバイスの制御を行うデバイス制御部と、を含むネットワーク型プラグアンドプレイに対応したネットワーク装置のためのネットワークプロトコル制御装置であって、
    メッセージヘッダとメッセージボディとを有するメッセージを前記ネットワーク上のクライアントから受信するとともに、前記メッセージボディの情報を前記デバイス制御部に転送し、
    前記転送の際に、前記クライアントから受信した前記メッセージボディの内容を解釈すること無く前記ネットワーク型プラグアンドプレイのプロトコルに従って前記メッセージヘッダを解釈するとともに、前記ネットワーク型プラグアンドプレイのプロトコルとは異なる通信プロトコルに従って前記メッセージボディを前記デバイス制御部に送信する、ネットワークプロトコル制御装置。

Images