JP4760425B2 - プリンタを用いた印刷におけるスタイルシートの切替 - Google Patents

Description

この発明は、プリンタを利用した印刷にスタイルシートを適用する技術に関する。

プリンタとして、ネットワークを介してクライアントから受信した印刷メッセージに従って印刷を実行するネットワークプリンタが広く利用されている。ところで、ネットワークや無線通信技術を介してプリンタに汎用の印刷メッセージ（例えばXHTML-Print）を送信して印刷を行わせる標準規格（Standard）としては、複数のものが存在しうる。ここで、「汎用の印刷メッセージ」とは、プリンタの機種に依存した印刷制御信号ではなく、機種に依存せずに印刷対象物を記述するメッセージを意味する。また、「標準規格」とは、公的な規格に限らず、事実上の標準や、企業団体によって制定された規格も含んでいる。異なる標準規格では、印刷物の標準的なレイアウト（文字の大きさ、位置揃え、フォント等）が互いに異なる場合がある。また、標準的なレイアウトが異なる印刷物は、観察者に異なる印象を与える。従って、プリンタで印刷を行う際にどの標準規格に準拠するかは、印刷物の見栄えに多大な影響を与えることがある。

特開２００４−３４５０８９号公報

しかし、従来は、このような複数の標準規格による印刷物のレイアウトの違いは考慮されていないのが実情であった。

本発明は、プリンタにおいて複数の標準規格による印刷物のレイアウトの違いを印刷物に正しく反映することのできる技術を提供することを目的とする。

上記目的を達成するために、本発明の一形態によるプリンタは、
外部装置から受信した印刷メッセージに従って印刷を実行可能なプリンタであって、
前記プリンタは、互いに異なる標準規格に対応したスタイルシートをそれぞれ適用して印刷物のレイアウトを決定して印刷を行うことが可能であり、
前記外部装置から受信した印刷メッセージ内の所定の記述に基づいて、予め格納されている複数の標準規格に対応したスタイルシートの中から印刷に使用すべきスタイルシートを選択し、選択したスタイルシートを使用して印刷物のレイアウトを決定する印刷制御部を備え、
前記印刷メッセージは、前記外部装置が印刷仕様を指定し印刷ジョブの作成を前記プリンタに要求するＳＯＡＰメッセージを含み、
前記所定の記述は、前記ＳＯＡＰメッセージ内のドキュメントフォーマット要素の記述である。
また、本発明の他の形態によるプリンタは、
外部装置から受信した印刷メッセージに従って印刷を実行可能なプリンタであって、
前記プリンタは、互いに異なる標準規格に対応したスタイルシートをそれぞれ適用して印刷物のレイアウトを決定して印刷を行うことが可能であり、
前記外部装置から受信した印刷メッセージ内の所定の記述に基づいて、予め格納されている複数の標準規格に対応したスタイルシートの中から印刷に使用すべきスタイルシートを選択し、選択したスタイルシートを使用して印刷物のレイアウトを決定する印刷制御部を備え、
前記印刷メッセージは、印刷対象を記述したＸＭＬ文書によるマークアップ言語文書を含み、
前記所定の記述は、前記マークアップ言語文書内のＸＭＬ宣言のエンコーディング属性であることを特徴とする。

このプリンタによれば、外部装置から受信した印刷メッセージの記述やその受信経路に基づいて適切な標準スタイルシートを選択するので、複数の標準規格による印刷物のレイアウトの違いを印刷物に正しく反映することが可能である。

なお、前記印刷メッセージは、印刷仕様を指定する印刷仕様メッセージと、印刷対象を記述したマークアップ言語文書とを含み、
前記印刷制御部は、前記印刷仕様メッセージ内の所定の記述から、前記印刷に使用すべき標準スタイルシートを決定するものとしてもよい。

また、前記印刷仕様メッセージは、前記外部装置が印刷ジョブの作成を前記プリンタに要求するＳＯＡＰメッセージであり、
前記印刷仕様メッセージ内の前記所定の記述は、前記ＳＯＡＰメッセージ内のドキュメントフォーマット要素の内容であるものとしても良い。

この構成によれば、本来はマークアップ言語文書がどのようなバージョンで作成されたものであるかを示すドキュメントフォーマット要素の内容から、印刷時に使用する標準スタイルシートを決定することが可能である。

あるいは、前記印刷メッセージは、印刷仕様を指定する印刷仕様メッセージと、印刷対象を記述したマークアップ言語文書とを含み、
前記印刷制御部は、前記マークアップ言語文書内の所定の記述から、前記印刷に使用すべき標準スタイルシートを決定するものとしてもよい。

また、前記マークアップ言語文書は、ＸＭＬ文書であり、
前記マークアップ言語文書内の前記所定の記述は、ＸＭＬ宣言のエンコーディング属性であるものとしてもよい。

この構成によれば、本来はマークアップ言語文書がどのような文字コードで記述されているかを示すエンコーディング属性の内容から、印刷時に使用する標準スタイルシートを決定することが可能である。

なお、上記プリンタは、
外部装置からの要求に応じてサービスを実行する１つ以上のサービスデバイスとしてのプリンタデバイスと、
前記印刷制御部を含み、前記サービスデバイスの制御を行うデバイス制御部と、
メッセージヘッダとメッセージボディとを有するメッセージを、前記プリンタが接続されているネットワーク上のクライアントから受信するとともに、前記メッセージボディの内容を前記デバイス制御部に転送するネットワークプロトコル制御部と、
を備えるものとしてもよい。

この構成によれば、ネットワークプロトコル制御部が、サービスデバイスの構成とサービスの内容を把握する必要が無く、任意の構成を有するサービスデバイス宛に送られたメッセージをデバイス制御部に転送することができる。また、サービスデバイスの構成やサービスの内容が変更されても、ネットワークプロトコル制御部の構成や機能を変更する必要が無いという効果がある。

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

次に、本発明の実施の形態を実施例に基づいて以下の順序で説明する。
A．用語の説明：
B．システムの概要：
C．第１実施例：
D．第２実施例：
E．第３実施例：
F．変形例

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-LOCALCONTROLチャンネルが、コントロールポイントからのアクションの内容の転送には使用されないからである。換言すれば、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．第１実施例：
図８は、第１実施例におけるデバイス制御部４０２の内部構成と処理内容を示すブロック図である。ここでは、プリンタデバイス４０４（図１）を制御するための構成のみが示されており、スキャナデバイス４０６及びストレージデバイス４０８を制御するための構成は図示が省略されている。

デバイス制御部４０２は、プロトコル処理モジュール６００と、印刷デバイス制御モジュール６１０と、レイアウトモジュール６２０と、XHTML-Print制御モジュール６３０とを備えている。プロトコル処理モジュール６００は、印刷ジョブメッセージＰＪＭと、ユーザインタフェース入力ＵＩＩとを受信して、印刷デバイス制御モジュール６１０にこれらのメッセージを転送する。印刷ジョブメッセージＰＪＭは、ネットワークを介してクライアント（コントロールポイント）から受信されるメッセージであり、プリンタデバイス４０４で印刷を行う際に利用される。本実施例では、印刷ジョブメッセージＰＪＭは、印刷ジョブの作成要求メッセージと、印刷対象文書を記述したXHTML-Printドキュメントとを含んでいる。これらの内容については後述する。ユーザインタフェース入力ＵＩＩは、複合機２００の操作パネル４９２（図２）を用いてユーザによって入力された各種の印刷設定値である。なお、プロトコル処理モジュール６００は、スキャナデバイス用のメッセージやストレージデバイス用のメッセージを各デバイス用の制御モジュール（図示せず）に転送する機能も有している。

印刷デバイス制御モジュール６１０は、プロトコル処理モジュール６００から転送された各種のメッセージに基づいて印刷処理の制御を行う。より具体的には、印刷デバイス制御モジュール６１０は、XHTML-Printドキュメントをレイアウトモジュール６２０に転送し、印刷制御データをXHTML-Print制御モジュール６３０に転送する。印刷制御データは、用紙サイズや、用紙種類、印刷命数などの印刷設定値（「印刷仕様」又は「印刷条件」とも呼ぶ）を含むデータである。

レイアウトモジュール６２０は、印刷デバイス制御モジュール６１０からXHTML-Printドキュメントを受信し、XHTML-Printドキュメントの解釈を行うとともに、印刷対象文書のレイアウトを決定する。なお、印刷対象文書のレイアウトという用語は、典型的には、文字の大きさと、文字の色と、文字の位置揃え（左端揃え、中央揃え、右端揃えなど）と、使用するフォントとを含んでおり、印刷される文字の体裁（スタイル）を意味している。印刷物のレイアウトを決定する際には、複数の標準スタイルシート６２２の中から適切なものが選択されて使用される。標準スタイルシート６２２は、XHTML-Printドキュメントの印刷に関する複数の標準規格（後述する）にそれぞれ対応付けられたものであり、予め準備されてデバイス制御部４０２内に格納されている。レイアウトモジュール６２０は、XHTML-Print制御モジュール６３０から印刷設定値を受信し、その設定値に応じて印刷データを作成するとともにプリンタデバイス４０４に出力する。なお、デバイス制御部４０２内の各構成要素間のデータの転送内容については更に後述する。

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

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

図１１は、印刷ジョブ作成要求のＳＯＡＰエンベロープの例を示す説明図である。図１１（Ａ）は、標準規格ＳＤ１に準拠して印刷を行う場合の例を示し、図１１（Ｂ）は、標準規格ＳＤ２に準拠して印刷を行う場合の例を示している。これらの例においては、アンダーラインを付した要素（ドキュメントフォーマット要素）が両者で異なっているだけであり、他の要素の内容は同一である。ドキュメントフォーマット要素の内容は、標準規格ＳＤ１用のＳＯＡＰエンベロープでは"application /xhtml-print"と記述されているのに対して、標準規格ＳＤ２用のＳＯＡＰエンベロープでは"application /x-inettv-xhtml"と記述されている。なお、標準規格ＳＤ１としては、例えばＷ３Ｃ（World Wide Web Consortium)のXHTML規格を利用することができ、標準規格ＳＤ２としては、例えば電波産業会（Association of Radio Industries and Business）のARIB STD-B24規格「デジタル放送におけるデータ放送符号化方式と伝送方式標準規格」を利用することができる。

これらの標準規格に準拠してXHTML-Printドキュメントの印刷を行う際は、ドキュメントフォーマット要素の内容は以下のように設定されるのが一般的である。
（１）XHTML規格の場合：
"application /xhtml-print"、又は
"application /xhtml-print-e"、又は
"application /vnd.pwg-xhtml-print"
（２）ARIB規格の場合：
"application /x-inettv-xhtml"、又は
"application /x-inettv-mixt"

このように、２つの標準規格ではＳＯＡＰエンベロープに記述されるドキュメントフォーマット要素の内容が互いに異なっているので、この要素の内容から、いずれの標準規格に準拠して文書の印刷を行えば良いかを判定することができる。なお、ドキュメントフォーマット要素は、本来は、ネットワークを介して送信されるXHTML-Printドキュメントがどのバージョンで作成されたものかを示すために記述されている。すなわち、このドキュメントフォーマット要素は、文書の印刷において準拠すべき標準規格を示すために記述されているものでは無いが、本実施例では、この記述から文書の印刷において準拠すべき標準規格を判定しているという点に１つの特徴がある。なお、印刷において準拠すべき標準規格としては、３つの以上の標準規格を利用することも可能である。この場合にも、各標準規格に対応付けられたスタイルシートが予めネットワーク装置内に格納されていることが好ましい。

図１２は、２つの標準規格に準拠して印刷された文書の例を示す説明図である。図１２（Ａ）は、XHTML-Printドキュメントのボディ部分を示している。図１２（Ｂ）は標準規格ＳＤ１に準拠した印刷結果を示しており、図１２（Ｃ）は標準規格ＳＤ２に準拠した印刷結果を示している。標準規格ＳＤ１では、印刷に使用するフォントとしてプリンタ設定フォントが使用されており、禁則処理としてスペースが行末に来ることが禁止されている。なお、ユーザによってプリンタのフォントが設定されていない場合には、プリンタの初期設定フォントが使用される。一方、標準規格ＳＤ２では、印刷に使用するフォントとしてゴシックが使用されており、禁則処理としてコンマが行末に来ることが禁止されている。このように、文書の印刷に関しては、２つの標準規格で文書のレイアウト（スタイル）が異なっており、これらのレイアウトの違いはそれぞれの標準規格に対応付けられた標準スタイルシート６２２（図８）に記述されている。本実施例では、以下で説明するように、ＳＯＡＰエンベロープの記述内容から、印刷時に準拠すべき標準規格を判定し、その標準規格に適したスタイルシートを使用して印刷が実行される。

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

図９のステップ[4]では、ＭＦＰデバイスユニット４００が、受信したメッセージＦ１２内のＳＯＡＰエンベロープに含まれているＳＯＡＰアクションを解析し、ＳＯＡＰアクションに応じて処理を実行する。例えば、ＳＯＡＰアクションが印刷ジョブの作成要求の場合には、図１１で説明したように、ＳＯＡＰエンベロープの記述内容から、印刷で使用すべきスタイルシートが決定される。ステップ[4]の内容をより具体的に説明すれば、図８に示すように、まずステップ[4-1]において、ＳＯＡＰエンベロープが印刷デバイス制御モジュール６１０からXHTML-Print制御モジュール６３０に転送される。そして、ステップ[4-2]では、XHTML-Print制御モジュール６３０によってドキュメントタイプが判別される。ここで、「ドキュメントタイプの判別」とは、図１１で説明したように、ＳＯＡＰエンベロープのドキュメントフォーマット要素の内容から、印刷において準拠すべき標準規格を判定することを意味している。図９のステップ[4]ではさらに、ＭＦＰデバイスユニット４００によって、印刷すべき文書を表す文書データ（XHTML-Printドキュメント）の送付先ＵＲＩが設定された返信用のＳＯＡＰエンベロープが作成される。図９の例では、メッセージＲ１１に示されているように、送付先ＵＲＩ（DataSinkURI）として”/DOWN/PRINTER/PRINTENHANCED”が設定されている。

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

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

続いて、図１０のステップ[8]では、コントロールポイント１１０ＣがＭＦＰサーバ３００に対してコンテンツデータ（XHTML-Printドキュメント）を含むリクエストメッセージＦ１３を転送する。このメッセージＦ１３のヘッダには、リクエスト命令のメソッド（ＰＯＳＴメソッド）と、宛先のパス名”/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]において、ＭＦＰサーバ３００がコンテンツデータ（XHTML-Printドキュメント）を含むメッセージＦ１５をＭＦＰデバイスユニット４００に転送する。このメッセージＦ１５の各パケットのヘッダには、ステップ[12]で通知されたリクエストＩＤが記入されている。また、論理チャンネルとしては、Ｎdown個のUPNP-DOWNCONTENTxチャンネルの中で、チャンネルＩＤで指定された１つのチャンネルが使用される。図１０の例では、チャンネルＩＤの値が”１”なので、１番目のチャンネルUPNP-DOWNCONTENT1が使用されている。ＭＦＰデバイスユニット４００は、メッセージＦ１５のリクエストＩＤを参照することによって、これらのパケットがステップ[10]で要求された処理のためのパケットであることを容易に認識することができる。また、コンテンツデータの送信処理の際には、予め設けられたＮdown個の論理チャンネルUPNP-DOWNCONTENTxのうちの１つを１つのコンテンツに割り当てるので、多数のコンテンツ送信処理を並行して行うことが可能である。

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

XHTML-Printドキュメントの受信が完了すると、ステップ[18]において、ＭＦＰデバイスユニット４００のプリンタデバイス４０４が、XHTML-Printドキュメントで記述された文書の印刷を実行する。ステップ[8]の内容をより具体的に説明すれば、図８に示すように、まずステップ[18-1]において、XHTML-Printドキュメントが印刷デバイス制御モジュール６１０からレイアウトモジュール６２０に転送される。ステップ[18-2]，[18-3]では、レイアウトモジュール６２０からXHTML-Print制御モジュール６３０への印刷設定値の要求と、その返信とが実行される。この印刷設定値は、印刷ジョブメッセージ（具体的には印刷ジョブ作成要求のＳＯＡＰメッセージ（図１１））に含まれる各種の設定値と、複合機２００の操作パネル４９２で設定された各種の設定値とが含まれており、さらに、スタイルシートの切替命令も含まれている。前述したように、複数の標準スタイルシート６２２のいずれを使用するかは、ＳＯＡＰエンベロープに基づいてXHTML-Print制御モジュール６３０によって判定されている。レイアウトモジュール６２０は、これらの印刷設定値に基づいて印刷物のレイアウトを決定するとともに、印刷物を印刷するための印刷データを作成して、プリンタデバイス４０４に出力する（ステップ[18-4]）。

以上のように、本実施例では、ネットワーク上のクライアントから送信された印刷ジョブ作成要求メッセージの記述に基づいて、複数の標準規格のいずれに準拠して印刷を実行すべきかを判定している。従って、印刷ジョブを発行したクライアントの利用者が期待するレイアウトを有する印刷物を正しく印刷することが可能である。また、この判定に使用するドキュメントフォーマット要素は、本来的にはXHTML文書の印刷において準拠すべき標準規格を示すために記述されているものでは無い。すなわち、本実施例では、印刷物のレイアウトの決定時に準拠すべき標準規格の判定に際して、そのために特別に用意された記述を印刷ジョブ作成要求メッセージに追加する必要が無いという利点がある。

D．第２実施例：
図１３は、第２実施例におけるデバイス制御部４０２の内部構成と処理内容を示すブロック図である。第２実施例におけるデバイス制御部４０２内の各構成要素は図８に示したものと同じであり、第２実施例は２つのモジュール６２０，６３０の処理内容が第１実施例と異なるだけである。すなわち、第２実施例では、ドキュメントタイプの判別は、XHTML-Print制御モジュール６３０によっては行われず、レイアウトモジュール６２０によりXHTML-Printドキュメントに基づいて行われる。

図１４は、XHTML-Printドキュメントの例を示す説明図である。図１４（Ａ）は、標準規格ＳＤ１に準拠して印刷を行う場合の例を示し、図１４（Ｂ）は、標準規格ＳＤ２に準拠して印刷を行う場合の例を示している。これらの例においては、ＸＭＬ宣言のアンダーラインを付した属性（エンコーディング属性）が両者で異なっているだけであり、他の記述内容は同一である。すなわち、印刷時に標準規格ＳＤ１を適用すべき文書では、エンコーディング属性は"UTF-8"（又は"UTF-16"）と記述されているのに対して、印刷時に標準規格ＳＤ２を適用すべき文書では、エンコーディング属性は"Shit_JIS"と記述されている。

このように、通常は２つの標準規格でエンコーディング属性の内容が互いに異なっているので、このエンコーディング属性の内容から、いずれの標準規格に準拠して文書の印刷を行えば良いかを判定することができる。なお、エンコーディング属性は、ネットワークを介して送信されるXHTML-Printドキュメントの文字がどの文字コードで記述されているかを示すために記述されている。すなわち、エンコーディング属性は、文書の印刷において準拠すべき標準規格を示すために記述されているものでは無いが、第２実施例では、エンコーディング属性の記述から、文書の印刷において準拠すべき標準規格を判別するという点に１つの特徴がある。なお、よく知られているように、ＸＭＬ宣言は、その文書がＸＭＬ文書であることを意味している。

図１３に示すように、レイアウトモジュール６２０は、XHTML-Printドキュメントから、印刷に使用すべき標準スタイルシートを選択し、これを使用して印刷データの作成を実行する。従って、印刷ジョブを発行したクライアントの利用者が期待している望ましいレイアウトを有する印刷物を正しく印刷することが可能である。

E．第３実施例：
図１５は、第３実施例における複合機の内部構成を示すブロック図である。第３実施例の複合機２００は、図２に示した第１実施例の複合機の構成に、ブルートゥース制御部５２０及びブルートゥースアダプタ５２２（ブルートゥースはBluetooth SIG, INCの商標）と、ＩｒＤＡ制御部５３０及び赤外線ポート５３２とを追加したものであり、他の構成は図２と同じである。第３実施例の複合機２００は、ブルートゥースアダプタ５２２と赤外線ポート５３２からも印刷ジョブ（XHTML-Printメッセージ）を受け取ることが可能である。なお、良く知られているように、ブルートゥースは、電波を利用した携帯情報機器向けの無線通信技術であえる。また、ＩｒＤＡ（Infrared Data Association）規格は、赤外線を利用した近距離無線通信規格である。

図１６は、第３実施例におけるデバイス制御部の内部構成と処理内容を示すブロック図である。第３実施例のデバイス制御部４０２は、図８に示した第１実施例のデバイス制御部の構成に、ブルートゥース入力用のプロトコル処理モジュール６０２と、ＩｒＤＡ入力用のプロトコル処理モジュール６０４とを追加したものであり、他の構成は図８と同じである。なお、第３実施例で追加した処理モジュール６０２，６０４は、第２実施例（図１３）に適用することも可能である。

ブルートゥースアダプタ５２２を介して入力された印刷ジョブ（XHTML-Printメッセージ）は、第２のプロトコル処理モジュール６０２を介して印刷デバイス制御モジュール６１０に供給される。また、赤外線ポート５３２を介して入力された印刷ジョブは、第３のプロトコル処理モジュール６０４を介して印刷デバイス制御モジュール６１０に供給される。本実施例では、ブルートゥースアダプタ５２２を介して入力された印刷ジョブの印刷は、第１の標準規格ＳＤ１に準拠して実行される。一方、赤外線ポート５３２を介して入力された印刷ジョブの印刷は、第２の標準規格ＳＤ２に準拠して実行される。従って、印刷デバイス制御モジュール６１０は、印刷ジョブがこれらの２つのプロトコル処理モジュール６０２，６０４から供給されたときには、その旨をXHTML-Print制御モジュール６３０に通知する。XHTML-Print制御モジュール６３０は、この通知に応じて、いずれの標準スタイルシートを使用すべきかを判断してレイアウトモジュール６２０に指示することが可能である。なお、第１実施例で説明したように、ネットワーク入力用のプロトコル処理モジュール６００によって印刷ジョブが受け取られた場合には、印刷ジョブ作成要求メッセージの記述に基づいて、いずれの標準スタイルシートを使用すべきかが判定される。

このように、第３実施例では、近距離無線通信を介して入力された印刷ジョブに関しては、その入力経路に応じて使用すべき標準スタイルシートを選択する。従って、印刷ジョブを発行した機器の利用者が期待するレイアウトを有する印刷物を正しく印刷することが可能である。

これらの実施例から理解できるように、複数の標準スタイルシートのいずれを使用するかの判定は、印刷メッセージ内の所定の記述と印刷メッセージの受信経路とのうちの少なくとも一方に基づいて実行することが可能である。また、第１、第２実施例のように印刷メッセージの受信経路が１つの場合には、印刷メッセージ内の所定の記述のみに基づいて標準スタイルシートを選択することが可能である。さらに、例えば、汎用の印刷メッセージが複数種類の近距離無線通信を介してのみ受信される場合には、印刷メッセージの受信経路のみに基づいて標準スタイルシートを選択することが可能である。

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

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

F２．変形例２：
第１、第３実施例ではXHTML-Print制御モジュール６３０がドキュメントタイプの判別処理（準拠すべき標準規格の判定）を行い、また、第２実施例ではレイアウトモジュール６２０がこの判別処理を行うものとしていたが、これら以外の任意の構成要素がこの判別処理を行うようにしてもよい。例えば、印刷デバイス制御モジュール６１０がこの判別処理を行うようにしてもよい。さらに、デバイス制御部４０２の構成としては、図８や図１３、図１６以外の構成を採用することも可能である。

F３．変形例３：
上記第１実施例では、印刷ジョブ要求のためのＳＯＡＰエンベロープに含まれるドキュメントフォーマット要素の内容に基づいて、印刷時に準拠すべき標準規格を判定していたが、これ以外の特定の記述（要素や属性）に基づいてこの判定を行ってもよい。同様に、第２実施例では、XHTML-Printドキュメントに含まれるＸＭＬ宣言のエンコーディング属性に基づいて、印刷時に準拠すべき標準規格を判定していたが、これ以外の特定の記述（要素や属性）に基づいてこの判定を行ってもよい。

また、上記各実施例では、印刷メッセージとして、印刷仕様メッセージとしてのＳＯＡＰエンベロープと、マークアップ言語文書としてのXHTML-Printドキュメントとを利用していたが、本発明は、これ以外の任意の形式の印刷メッセージを利用することができる。ここで、「印刷メッセージ」とは、外部装置からプリンタに印刷の実行を要求するメッセージを意味している。

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

本発明の実施例を適用するネットワークシステムの構成を示す概念図である。 複合機の内部構成を示すブロック図である。 ＭＦＰサーバの各種プロトコルの階層構造を示すブロック図である。 ＭＦＰデバイスユニットの各種プロトコルの階層構造を示すブロック図である。 ＵＳＢのインタフェース／エンドポイント構成と論理チャンネルの構成とを示す説明図である。 プリンタインタフェースを介したＵＳＢ転送に用いられるパケットの構成を示す説明図である。 ＵＰｎＰアーキテクチャを利用した処理の典型例を示すシーケンス図である。 第１実施例におけるデバイス制御部の内部構成と処理内容を示すブロック図である。 第１実施例におけるＸＨＴＭＬデータを利用した印刷処理手順を示すシーケンス図である。 第１実施例におけるＸＨＴＭＬデータを利用した印刷処理手順を示すシーケンス図である。 第１実施例においてスタイルシートの選択に使用されるＳＯＡＰエンベロープの例を示す説明図である。 ２つの標準規格に準拠して印刷された文書の例を示す説明図である。 第２実施例におけるデバイス制御部の内部構成と処理内容を示すブロック図である。 第２実施例においてスタイルシートの選択に使用されるドキュメントの例を示す説明図である。 第３実施例における複合機の内部構成を示すブロック図である。 第３実施例におけるデバイス制御部の内部構成と処理内容を示すブロック図である。

符号の説明

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

Claims (6)

1. 外部装置から受信した印刷メッセージに従って印刷を実行可能なプリンタであって、
   前記プリンタは、互いに異なる標準規格に対応したスタイルシートをそれぞれ適用して印刷物のレイアウトを決定して印刷を行うことが可能であり、
   前記外部装置から受信した印刷メッセージ内の所定の記述に基づいて、予め格納されている複数の標準規格に対応したスタイルシートの中から印刷に使用すべきスタイルシートを選択し、選択したスタイルシートを使用して印刷物のレイアウトを決定する印刷制御部を備え、
   前記印刷メッセージは、前記外部装置が印刷仕様を指定し印刷ジョブの作成を前記プリンタに要求するＳＯＡＰメッセージを含み、
   前記所定の記述は、前記ＳＯＡＰメッセージ内のドキュメントフォーマット要素の記述であることを特徴とするプリンタ。
2. 外部装置から受信した印刷メッセージに従って印刷を実行可能なプリンタであって、
   前記プリンタは、互いに異なる標準規格に対応したスタイルシートをそれぞれ適用して印刷物のレイアウトを決定して印刷を行うことが可能であり、
   前記外部装置から受信した印刷メッセージ内の所定の記述に基づいて、予め格納されている複数の標準規格に対応したスタイルシートの中から印刷に使用すべきスタイルシートを選択し、選択したスタイルシートを使用して印刷物のレイアウトを決定する印刷制御部を備え、
   前記印刷メッセージは、印刷対象を記述したＸＭＬ文書によるマークアップ言語文書を含み、
   前記所定の記述は、前記マークアップ言語文書内のＸＭＬ宣言のエンコーディング属性であることを特徴とするプリンタ。
3. 請求項１または２のいずれか１項に記載のプリンタにおいて、
   前記スタイルシートは、互いに異なる標準規格に対応したスタイルシートであり、
   前記プリンタは前記標準規格に対応したスタイルシートをそれぞれ適用して印刷物のレイアウトを決定する複数の標準規格に準拠して印刷を行うことが可能であることを特徴とする。
4. 請求項１または２のいずれかに記載のプリンタであって、
   外部装置からの要求に応じてサービスを実行する１つ以上のサービスデバイスとしてのプリンタデバイスと、
   前記印刷制御部を含み、前記サービスデバイスの制御を行うデバイス制御部と、
   メッセージヘッダとメッセージボディとを有するメッセージを、前記プリンタが接続されているネットワーク上のクライアントから受信するとともに、前記メッセージボディの内容を前記デバイス制御部に転送するネットワークプロトコル制御部と、
   を備えるプリンタ。
5. 外部装置から受信した印刷メッセージに従って印刷を実行可能なプリンタを用いた印刷方法であって、
   前記プリンタは、互いに異なる標準規格に対応したスタイルシートをそれぞれ適用して印刷物のレイアウトを決定して印刷を行うことが可能であり、
   前記方法は、
   前記プリンタが、前記外部装置から受信した印刷メッセージ内の所定の記述に基づいて、予め格納されている複数の標準規格に対応したスタイルシートの中から印刷に使用すべきスタイルシートを選択し、選択したスタイルシートを使用して印刷物のレイアウトを決定する工程と、
   前記決定されたレイアウトに従って前記印刷物を印刷する工程と、
   を備え、
   前記印刷メッセージは、前記外部装置が印刷仕様を指定し印刷ジョブの作成を前記プリンタに要求するＳＯＡＰメッセージを含み、
   前記所定の記述は、前記ＳＯＡＰメッセージ内のドキュメントフォーマット要素の記述であることを特徴とする、プリンタを用いた印刷方法。
6. 外部装置から受信した印刷メッセージに従って印刷を実行可能なプリンタを用いた印刷方法であって、
   前記プリンタは、互いに異なる標準規格に対応したスタイルシートをそれぞれ適用して印刷物のレイアウトを決定して印刷を行うことが可能であり、
   前記方法は、
   前記プリンタが、前記外部装置から受信した印刷メッセージ内の所定の記述に基づいて、予め格納されている複数の標準規格に対応したスタイルシートの中から印刷に使用すべきスタイルシートを選択し、選択したスタイルシートを使用して印刷物のレイアウトを決定する工程と、
   前記決定されたレイアウトに従って前記印刷物を印刷する工程と、
   を備え、
   前記印刷メッセージは、印刷対象を記述したＸＭＬ文書によるマークアップ言語文書を含み、
   前記所定の記述は、前記マークアップ言語文書内のＸＭＬ宣言のエンコーディング属性であることを特徴とする、プリンタを用いた印刷方法。

Images