JP6188368B2 - 印刷装置および情報処理装置、制御方法、プログラム - Google Patents

Description

本発明は、情報処理装置と印刷装置が通信する技術に関する。

非特許文献１はクライアントコンピュータがプリンタに特定の要素のリクエストを行う技術と、プリンタが特定の要素のレスポンスを行う技術を開示している。

Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ Ｄｅｆｉｎｉｔｉｏｎ ｖ１．１ ｆｏｒ Ｗｅｂ Ｓｅｒｖｉｃｅｓ ｏｎ Ｄｅｖｉｃｅｓ［ＷＳＤＰｒｉｎｔＳｅｒｖｉｃｅＶ１１．ｄｏｃ］２０１２年７月２４日、［２０１３年３月６日検索］、インターネット（ＵＲＬ：ｈｔｔｐ：／／ｄｏｗｎｌｏａｄ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｄｏｗｎｌｏａｄ／Ｅ／９／７／Ｅ９７４ＣＦＣＢ−４Ｂ３Ｂ−４０ＣＣ−ＡＦ９２−４Ｆ７Ｆ８４４７７Ｆ０Ｂ／Ｐｒｉｎｔｅｒ．ｚｉｐ）

ここで画像処理装置が応答する応答データのサイズに制限サイズがあって、応答データのサイズが制限サイズを超えると応答できないか、あるいはエラーになる環境を想定する。

しかしながら、非特許文献１はレスポンス時の応答データが制限サイズを超える場合について想定していない。よって、非特許文献１の技術を用いても前述の環境では応答（レスポンス）ができないか、エラーになる虞がある。

本発明は応答データのサイズが制限サイズを超える可能性を低減することを目的とする。

上記の目的を達成するための本発明に係る画像処理装置は、第１の要素データと第２の要素データの要求を受信する受信手段と、前記第２の要素データがプライベート要素のデータであるかを判断する第１の判断手段と、前記第２の要素データは遅延して通知可能であるかを判断する第２の判断手段と、前記第１の判断手段が前記第２の要素データはプライベート要素のデータでありかつ前記第２の判断手段が前記第２の要素データは遅延して通知可能であると判断した場合に、前記第２の要素データを遅延して通知することを示す遅延データと前記第１の要素データを、前記受信手段が受信した前記要求に対応する応答データとして応答する応答手段と、前記応答手段が前記応答データを応答した後に、前記第２の要素データを通知する通知手段と、を有することを特徴とする。

本発明によれば応答データのサイズが制限サイズを超える可能性を低減できる。

印刷装置と情報処理装置の構成図 情報処理装置のソフトウェア構成図 アプリケーションから印刷装置までのデータの流れを説明するためのブロック図 情報処理装置と印刷装置の情報通信の流れを示すシーケンス図 Ｂｉｄｉ拡張ファイルの内容を示す図 情報取得要求受信後の印刷装置の処理を示すフローチャート 情報取得要求の内容を示す図 応答データを示す図 イベント通知情報の内容を示す図 情報取得要求受信後の印刷装置の処理を示すフローチャート 情報取得要求受信後の印刷装置の処理を示すフローチャート 情報処理装置の情報取得要求処理を示すフローチャート 情報処理装置の情報取得要求処理を示すフローチャート

以下、添付図面を参照して本発明の実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

複数の情報処理装置によって画像処理装置の一例である印刷装置を共有するネットワーク印刷システムにおける標準化が進んでいる。例えば、ＷＳＤ（Ｗｅｂ Ｓｅｒｖｉｃｅ ｏｎ Ｄｅｖｉｃｅｓ）のプリントサービスを利用したネットワーク印刷システムについて説明する。このネットワーク印刷システムではイベントベースのプロトコルが利用できる。さらに、印刷装置から情報処理装置に対して通知されるイベントを利用して、情報処理装置がこのイベントにより様々な制御を行うことができる。例えば、印刷装置は状態が変化したこと通知するイベント（ＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅ Ｅｖｅｎｔ）によって、情報処理装置に印刷装置の現在の状態を伝える。

ところで、新たにネットワークに接続した情報処理装置は、イベントベースの情報通知処理のみを利用すると、ネットワークに接続されてから印刷装置の状態が遷移するまで印刷装置の状態情報が通知されない。つまり新たにネットワークに接続した情報処理装置内で動作するアプリケーションは、次に印刷装置の状態が遷移するまで印刷装置の情報を知り得ないことになる。そのため、情報処理装置側から能動的に印刷装置の情報を要求する（ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ Ｏｐｅｒａｔｉｏｎ）手段が設けられている。新たにネットワークに接続した情報処理装置は、印刷装置との接続が確立すると、最初に印刷装置の各種情報を要求することによって印刷装置の情報を取得することを可能としている。

また、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔは、一度に複数の情報の取得要求が行えるように設計されている。取得要求に対する応答であるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅは、一度のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対して一度の応答を行うよう設計されている。

しかしながら、近年の印刷装置の高機能化に伴い、印刷装置の持つ情報のサイズは大きいものになっている。情報処理装置の受信可能なＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅのサイズには一定量の制限が存在する。ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対する応答であるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅは、情報処理装置の受信可能な受信データサイズを越えてしまう虞があった。受信データサイズの制限を超えないよう情報取得要求を一つずつ行えば、一つの要求に対する受信データサイズは小さくなる。しかし、印刷装置の応答処理負荷は、複数のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対して複数の応答を行う必要があるため、大きくなってしまう。以降、このような課題を解決し得るシステムに関して説明する。

＜実施形態１＞
図１を参照して本実施形態における情報処理装置と印刷装置の構成を説明する。

情報処理装置１００は入力インタフェース１０２とＣＰＵ１０３、ＲＯＭ１０４、ＲＡＭ１０５、外部記憶装置１０６、出力インタフェース１０８、表示部１０７、キーボード１０１、マウス１０９、ネットワークインタフェース１１０を有する。ネットワークインタフェース１１０はネットワーク１９０にネットワークケーブル１１１を介して接続してある。ＲＯＭ１０４には初期化プログラムが入っており、外部記憶装置１０６にはアプリケーションプログラム群、とＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、プリンタドライバやその他各種のデータが保存されている。ＲＡＭ１０５は外部記憶装置１０６に格納される各種プログラムがワークメモリとして使用する。加えて、ＣＰＵ１０３が外部記憶装置１０６に記憶されているプログラムに基づき処理を実行することによって、図２に示されるような情報処理装置１００のソフトウェア構成及び後述するフローチャートの各ステップの処理が実現される。

印刷装置１５０はネットワークインタフェース１５１とＲＡＭ１５２、プリントエンジン１５３、ＲＯＭ１５４、ＣＰＵ１５６を有する。ネットワークインタフェース１５１はネットワーク１９０にネットワークケーブル１５７を介して接続してある。ＲＡＭ１５２はＣＰＵ１５６の主メモリとワークメモリとして用いられ、受信した印刷ジョブを一旦保存するための受信バッファーや各種のデータを保存する。プリントエンジン１５３はＲＡＭ１５２に保存されたデータに基づき印刷を行う。ＲＯＭ１５４にはステータス管理プログラム１５５等、各種の制御プログラムや各制御プログラムが使用するデータが入っており、ＣＰＵ１５６はこれらの制御プログラムに従って印刷装置１５０の各部を制御する。ステータス管理プログラム１５５は図示していない印刷装置内部にある各種のセンサの情報を元に印刷装置１５０の状態を監視し、ステータス情報を作成、ＲＡＭ１５２にストアするプログラムである。印刷装置１５０はこうして作成したステータス情報に基づいて後述する応答データやイベントデータを生成する。加えて、ＣＰＵ１５６がＲＯＭ１５４に記憶されているプログラムに基づき処理を実行することによって後述するフローチャートの各ステップの処理が実現される。

ここでは例として情報処理装置１００と印刷装置１５０の処理分担を上記のように示したが、特にこの分担形態限らず他の形態であっても構わない。

図２は情報処理装置２００（１００）のソフトウェア構成を示す図である。同図において、２０７はＥｔｈｅｒｎｅｔ（登録商標）を制御するＥｔｈｅｒｎｅｔ（登録商標）制御スタックである。２０６はＩＰ Ｎｅｔｗｏｒｋを制御するＩＰ Ｎｅｔｗｏｒｋ制御スタックである。２０４はＷＳＤを制御するＷＳＤ制御スタック、２０５はＩＨＶ（Ｉｎｄｅｐｅｎｄｅｎｔ Ｈａｒｄｗａｒｅ Ｖｅｎｄｏｒ）の独自プロトコルを制御するＩＨＶネイティブプロトコル制御スタックである。２０３はデバイスドライバ群であり、ＯＳに標準で同梱されている標準ドライバ群とＩＨＶから提供されるＩＨＶ製ドライバ群から構成される。印刷装置を制御する後述のプリンタドライバ３２１もドライバ群のひとつである。２０２はアプリケーション／ＤＤＩインタフェースであり、Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）、Ｄｅｖｉｃｅ Ｄｒｉｖｅｒ Ｉｎｔｅｒｆａｃｅ（ＤＤＩ）から構成される。２０１はアプリケーション群である。

図３はアプリケーションから印刷装置までのデータの流れを説明するためのブロック図である。アプリケーション３０１（アプリケーション群２０１内の一つのアプリケーション）は、ＯＳの提供する印刷指示を行うＡＰＩを利用し、ＯＳへ印刷処理の要求を行う。印刷処理の要求はＯＳ内のスプーラ３１１にて処理される。スプーラ３１１はアプリケーション３０１からの印刷要求を受け、プリントキュー３１２に印刷ジョブ３１３として格納する。スプーラ３１１は情報処理装置１００内の複数のアプリケーション３０１からの複数の印刷ジョブ３１３をプリントキュー３１２に格納する。スプーラ３１１はプリントキュー３１２に格納した印刷ジョブ３１３を順次プリンタドライバ３２１へ送信する。プリンタドライバ３２１は、印刷ジョブ３１３を受信すると、ページ構成モジュール３２２にてページ構成処理を行う。ページ構成処理とは、アプリケーション３０１から指示された印刷設定情報が印刷ジョブ３１３に付加されており、印刷設定情報に基づいて一つの印刷ジョブ３１３内のページの順序を並べ替える処理や、複数ページを１ページにレイアウトする処理を指す。ページ構成モジュール３２２によるページ構成処理が終了すると、プリンタドライバ３２１はコマンド生成モジュール３２３で印刷ジョブ３１３を印刷データの形式へ変換する処理を行う。印刷データの形式とは印刷装置１５０が解釈可能なデータの形式である。コマンド生成モジュール３２３によって印刷ジョブ３１３を印刷データの形式に変換する処理が完了すると、プリンタドライバ３２１は印刷装置３３１（１５０）へポートモニター３１４を介して印刷ジョブ３１３を送信する。印刷装置３３１は印刷ジョブ３１３に基づいて用紙などの記録媒体にインクなどの記録材料を用いて印刷を行う。ポートモニター３１４は、印刷装置１５０へ情報取得要求および印刷装置１５０から情報受信、又は印刷装置１５０からのイベントを受信する役割も担う。ポートモニター３１４は、プリンタドライバ３２１が必要とする情報を知るために、プリンタドライバ３２１のＢｉｄｉ拡張ファイル３２４（後述する）を参照する。

なお、ポートモニター３１４はＯＳ標準のものであっても構わないし、ベンダー独自のものであっても構わない。

図４は、情報処理装置１００と印刷装置１５０の情報通信処理の流れを示すシーケンス図である。情報処理装置１００が印刷装置１５０の情報を取得する流れを説明する。情報処理装置１００はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ Ｏｐｅｒａｔｉｏｎ（情報取得要求）を印刷装置１５０に発行する（Ｓ４０１）ことによって印刷装置１５０へ情報の要求を行う。情報取得要求には固有のＩＤ（識別子）であるメッセージＩＤが格納されている。印刷装置１５０は情報取得要求を受信する（Ｓ４０２）と、要求に応じた情報を収集し、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ Ｏｐｅｒａｔｉｏｎ（情報取得応答）を発行することにより情報処理装置１００へ応答する（Ｓ４０３）。情報取得応答では情報処理装置１００へ応答データを送信する。応答データには情報取得要求時に送信されたメッセージＩＤが情報取得応答に関連するＩＤとして格納されている。これによりどの情報取得要求に対応する情報取得応答（あるいは応答データ）であるのかを情報処理装置１００が特定することができる。情報処理装置１００は情報取得応答を受信する（Ｓ４０４）と、受信した情報で記憶領域（Ｓ４５０）内の情報を更新する（Ｓ４０５）。

次に、印刷装置１５０が印刷装置１５０内の情報に遷移が発生した際に、情報処理装置１００へイベント通知を行う流れを説明する。印刷装置１５０は印刷装置１５０内の情報に遷移が発生したことを検知する（Ｓ４１１）と、イベントデータを生成してＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔを情報処理装置１００へ発行する（Ｓ４１２）。ＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔ発行処理をイベント通知、イベント通知の内容をイベントデータと称す。イベント通知は前述の情報取得応答とは異なり、情報処理装置１００が要求していなくとも送信することができる。また、イベント通知に関連するＩＤも存在しない。情報処理装置１００は、イベント通知を受信する（Ｓ４１３）と、受信した情報で記憶領域（Ｓ４５０）内の情報を更新する（Ｓ４１４）。

本明細書では情報取得要求を受信した際に、その要求に応えて情報取得応答を発行することを「応答」と表現する。一方、前述のように関連するＩＤを指定せずにイベントデータを自発的に送信することを「通知」と表現する。

なお、本実施形態において、情報処理装置１００側で行う情報取得要求の発行、応答データの受信、イベントデータの受信、受信情報を記憶領域Ｓ４５０へ更新する処理は、ＯＳのポートモニター（ＷＳＤポートモニター）３１４にて行う構成にて説明する。

図５（ａ）は、Ｂｉｄｉ拡張ファイル３２４の内容を示す図である。Ｂｉｄｉ拡張ファイル３２４には印刷装置に要求すべきプライベート要素のデータが記載されている。プライベート要素のデータについては後述する。以降Ｂｉｄｉ拡張ファイル３２４に記載されている内容について詳細に説明する。５０１は、ネームスペース「ｈｔｔｐ：／／ｗｗｗ．ｉｈｖ．ｃｏｍ／２００８／０１／ｐｒｉｎｔ」の略称が「ｉｈｖ」である旨を定義している。以降、「ｉｈｖ」という接頭辞が付されたＸＭＬ要素や属性情報やデータは、ＩＨＶによりカスタマイズされたＶｅｎｄｅｒ独自（プライベート）の要素や属性情報やデータであることを意味する。

ここで本明細書における属性情報と属性値の関係について５０２を例に説明すると、「ｑｕｅｒｙ＝“ｉｈｖ：Ｓｔａｔｕｓ”」が属性情報であり、属性情報の中でダブルクォーテーションに囲まれた「ｉｈｖ：Ｓｔａｔｕｓ」が属性値である。

５０２の「ｑｕｅｒｙ＝“ｉｈｖ：Ｓｔａｔｕｓ”」属性情報は、「ｉｈｖ：Ｓｔａｔｕｓ」という印刷装置１５０の要素データを情報処理装置１００内のプリンタドライバ３２１が必要としている旨を示す。「ｉｈｖ：Ｓｔａｔｕｓ」を必要とすることをポートモニター３１４が知ることにより、ポートモニター３１４は記憶領域Ｓ４５０内に「ｉｈｖ：Ｓｔａｔｕｓ」要素データを残すよう動作する。同様に、５０３の「ｑｕｅｒｙ＝“ｉｈｖ：Ｃａｐａｂｉｌｉｔｙ”」属性情報は、「ｉｈｖ：Ｃａｐａｂｉｌｉｔｙ」という印刷装置１５０の要素データを情報処理装置１００内のプリンタドライバ３２１が必要としている旨を示す。「ｉｈｖ：Ｓｔａｔｕｓ」や「ｉｈｖ：Ｃａｐａｂｉｌｉｔｙ」等のｉｈｖから始まる要素をプライベート要素と称す。印刷装置１５０がＸＭＬ構成上プライベート要素で括って情報処理装置１００へ情報取得応答またはイベント通知する要素データをプライベート要素のデータと称す。要素と要素データの関係については後述する。

情報処理装置１００と印刷装置１５０との接続が確立したことを確認すると、ＯＳは印刷装置１５０の情報を情報取得要求によって印刷装置１５０へ取得を要求する。ＯＳが取得を要求する情報は、ＷＳＤプリントサービス標準（パブリック）の要素（パブリック要素）とともに、Ｂｉｄｉ拡張ファイル３２４に記されたプライベート要素の要求も併せて行う。

次に要素データと要素の関係について図７の７０２を用いて説明する。本明細書において＜ｗｓｄｓｔ：Ｎａｍｅ＞や＜／ｗｓｄｓｔ：Ｎａｍｅ＞のように括弧によって括られている記述を要素と呼ぶ。また先頭にスラッシュを含まないものが開始要素であり、スラッシュを含むものが終了要素である。そして、この開始要素と終了要素の間にある記述（データ）を本明細書では要素データと呼ぶ。本明細書では要素データを要素によって括られているデータとも表現する。

図７（ａ）はパブリック要素とプライベート要素を同時に要求する際の情報取得要求で要求する要素データを示す情報である。７０１に示す「ｗｓｄｓｔ：ＲｅｑｕｅｓｔｅｄＥｌｅｍｅｎｔｓ」要素の子要素である「ｗｓｄｓｔ：Ｎａｍｅ」要素の要素データは、印刷装置１５０に要求する要素データ（パブリック要素のデータ若しくはプライベート要素のデータ）の名称を示す。情報取得要求の内容には「ｗｓｄｓｔ：ＲｅｑｕｅｓｔｅｄＥｌｅｍｅｎｔｓ」要素の子要素として「ｗｓｄｓｔ：Ｎａｍｅ」を複数記述することが可能である。ここで、「ｗｓｄｓｔ」という接頭辞は、標準的（パブリック）なＷＳＤプリントサービスのネームスペースの略称である。７０２は「ｗｓｄｓｔ：Ｎａｍｅ」要素に「ｗｓｄｓｔ：ＰｒｉｎｔｅｒＳｔａｔｕｓ」データが括られた様子を示している。７０３は「ｗｓｄｓｔ：Ｎａｍｅ」要素に「ｗｓｄｓｔ：ＤｅｆａｕｌｔＰｒｉｎｔＴｉｃｋｅｔ」データが括られた様子を示している。７０４は「ｗｓｄｓｔ：Ｎａｍｅ」要素に「ｉｈｖ：Ｓｔａｔｕｓ」データが括られた様子を示している。７０５は「ｗｓｄｓｔ：Ｎａｍｅ」要素に「ｉｈｖ：Ｃａｐａｂｉｌｉｔｙ」データが括られた様子を示している。以上のとおり、図７（ａ）の情報取得要求には、７０２〜７０４の「ｗｓｄｓｔ：Ｎａｍｅ」要素で括られた複数のデータを一度に印刷装置に要求する旨が記されている。

情報処理装置１００と印刷装置１５０との接続が確立した直後のＯＳは、図７（ａ）に示すように複数のデータを一度に要求する。しかしながら、情報取得要求に対して印刷装置１５０が応答する情報取得応答のデータ（応答データ）のサイズには制限がある。応答データのサイズを小さくし、且つ、全ての印刷装置１５０の情報を得るために、単純に全てのパブリック要素とプライベート要素を一つずつ分割して情報取得要求を行う手法が考えられる。しかし、全ての要素を分割して情報取得要求を行うと、情報処理装置１００が情報取得要求を行う回数が増えてしまう。また、情報取得要求に対する応答データを応答する印刷装置１５０の負荷も増えてしまう。そのため、情報処理装置１００はできる限りまとめて印刷装置１５０の情報取得の要求を行うことが求められる。また、パブリック要素のデータは、ＯＳも利用することが考えられるため、情報取得要求を分割して情報の取得の遅延を発生させることは望ましくない。そのため、パブリック要素のデータ取得はまとめて行い、プライベート要素のデータ取得は可能な限り分割する手法について、図５（ｂ）、図６、図７（ｂ）を用いて説明する。

図５（ｂ）は、Ｂｉｄｉ拡張ファイル３２４の内容を示す図である。５１１の「ｑｕｅｒｙ＝“ｉｈｖ：Ｓｔａｔｕｓ”」属性情報は、「ｉｈｖ：Ｓｔａｔｕｓ」という印刷装置１５０の要素データを情報処理装置１００内のプリンタドライバ３２１が必要としている旨を示す。５１３の「ｑｕｅｒｙ＝“ｉｈｖ：Ｃａｐａｂｉｌｉｔｙ”」属性情報は、「ｉｈｖ：Ｃａｐａｂｉｌｉｔｙ」という印刷装置１５０の要素データを情報処理装置１００内のプリンタドライバ３２１が必要としている旨を示す。５１２の「ｑｕｅｒｙ＝“ｉｈｖ：Ｓｔａｔｕｓ＿ｄｅｌａｙ”」属性情報は、５１１の「ｉｈｖ：Ｓｔａｔｕｓ」という要素名に「＿ｄｅｌａｙ」という識別子が付与されている様子を示す。「＿ｄｅｌａｙ」という識別子が付与された「ｉｈｖ：Ｓｔａｔｕｓ＿ｄｅｌａｙ」５１２は、「ｉｈｖ：Ｓｔａｔｕｓ」要素データ（以降単に「Ｓｔａｔｕｓ」データと呼ぶ。）の取得要求に対して、「Ｓｔａｔｕｓ」データを遅延して通知してもよい旨を示す。要素データを遅延して通知する処理については、後に図６を用いて説明する。ＯＳは印刷装置１５０との接続が確立すると、複数のパブリック要素とともに３つのプライベート要素（「ｉｈｖ：Ｓｔａｔｕｓ」、「ｉｈｖ：Ｓｔａｔｕｓ＿ｄｅｌａｙ」、「ｉｈｖ：Ｃａｐａｂｉｌｉｔｙ」）の要素データをまとめて要求する。

図７（ｂ）は図５（ｂ）のＢｉｄｉ拡張ファイル３２４を読み取ったＯＳが要求する情報取得要求の内容を示す。図７（ａ）と比べて、図７（ｂ）は７１１の要素が追加されている。７１１は「ｗｓｄｓｔ：Ｎａｍｅ」要素に「ｉｈｖ：Ｓｔａｔｕｓ＿ｄｅｌａｙ」データが括られた様子を示している。これは「ｉｈｖ：Ｓｔａｔｕｓ」データの取得要求に対して、「Ｓｔａｔｕｓ」データを遅延して通知してもよい旨を示す。

図６は情報取得要求を受信後（Ｓ４０２）の印刷装置１５０の処理を示すフローチャートである。印刷装置１５０は、情報取得要求を受信する（Ｓ６０１）と要求された要素データの確認を行う（Ｓ６０２）。要素データの確認処理（Ｓ６０２）は、要求された要素データの数と、パブリック要素かプライベート要素かの要素タイプと、要素タイプがプライベート要素であった場合は遅延可能か、を確認する処理である。次に印刷装置１５０は要素タイプの判断（Ｓ６０３）を行い、要素タイプがパブリック要素である場合は応答データとして要求されたパブリック要素のデータを収集し、要素データを応答データとして記憶領域Ａ（Ｓ６５０）に保存する（Ｓ６０４）。その後、印刷装置１５０は要求された要素データの中で処理していない残りの要素データが存在するか否かを判断（Ｓ６０５）し、残りの要素データが存在する場合は、処理Ｓ６０２に戻る。判断Ｓ６０３において、印刷装置１５０は要素データがプライベート要素のデータであると判断した場合、遅延して通知可能かどうかを判断する（Ｓ６０６）。判断Ｓ６０６において、印刷装置１５０は遅延して通知してもよい要素データではないと判断した場合、プライベート要素のデータを収集して応答データとして記憶領域Ａ（Ｓ６５０）に保存する（Ｓ６０４）。判断Ｓ６０６において、印刷装置１５０は遅延して通知してもよい要素データであると判断した場合、プライベート要素のデータを収集して、イベント通知用の要素データ（イベントデータ）として記憶領域Ｂ（Ｓ６５１）に保存する（Ｓ６０７）。さらに、遅延して通知してもよい要素データ（５１１）と遅延識別子が付加された要素データ（５１２）の空データ（ＥｍｐｔｙＥｌｅｍｅｎｔ）を生成し、記憶領域Ａ（Ｓ６５０）の応答データに保存する（Ｓ６０８）。判断Ｓ６０５にて、全ての要求のあった要素データに対する処理が完了したと判断すると、印刷装置１５０は処理Ｓ６０９へ進む。処理Ｓ６０９では、印刷装置１５０は記憶領域Ａ（Ｓ６５０）に保存された応答データを取り出し、情報取得要求のあった情報処理装置１００にまとめて応答する。本実施例ではこのように要素データを遅延して通知することを示す遅延データとして空データを応答する。空データにすることで要求された要素データのサイズよりも小さくすることが可能である。その後、イベントデータが記憶領域Ｂ（Ｓ６５１）に保存されていた場合、印刷装置１５０は要求元の情報処理装置１００へイベント通知する（Ｓ６１０）。処理Ｓ６１０でイベントを通知する先は、情報取得要求にて要求があった情報処理装置１００のみに限定してもよい。何故ならばその他のネットワーク上の情報処理装置は、情報取得要求にて要求があった情報処理装置１００の要求が行われる前に印刷装置のイベント通知を受けて、既に最新の情報を得ている可能性があるためである。その後、印刷装置１５０は情報取得要求受信後の処理を終了する（Ｓ６１１）。

なお、本実施例では応答データの応答（Ｓ６０９）直後にイベント通知する例を示したが、これに限らず次に印刷装置１５０の情報に遷移が発生したときに他の情報処理装置への通知と合わせてイベント通知するように構成しても構わない。

このように、遅延して通知してもよい要素データについては情報取得要求に対する応答データには含めず（空データとして含める）に、イベントデータとして通知することにより、応答データのサイズを縮小することができる。

図８（ａ）を用いて印刷装置から要求された要素データのうち全ての要素データを応答した場合の応答データを説明する。８０１は「ｗｓｄｓｔ：ＥｌｅｍｅｎｔＤａｔａ」要素に、「Ｎａｍｅ＝“ｗｓｄｓｔ：ＰｒｉｎｔｅｒＳｔａｔｕｓ”」属性情報と、「Ｖａｌｉｄ＝”ｔｒｕｅ”」属性情報が付加されている様子を示している。「ｗｓｄｓｔ：ＰｒｉｎｔｅｒＳｔａｔｕｓ」属性値は、「ｗｓｄｓｔ：ＥｌｅｍｅｎｔＤａｔａ」の要素データが「ＰｒｉｎｔｅｒＳｔａｔｕｓ」である旨を示している。「ｔｒｕｅ」属性値は、「ｗｓｄｓｔ：ＥｌｅｍｅｎｔＤａｔａ」要素で括られたデータが有効である旨を示している。８０２は、「ｗｓｄｓｔ：ＰｒｉｎｔｅｒＳｔａｔｕｓ」開始要素であり、開始要素から終了要素の間に「ＰｒｉｎｔｅｒＳｔａｔｕｓ」要素データが格納されている。「ｗｓｄｓｔ：ＰｒｉｎｔｅｒＳｔａｔｕｓ」開始要素８０２は、「ｗｓｄｓｔ」という接頭辞で括られていることから、「ＰｒｉｎｔｅｒＳｔａｔｕｓ」データはパブリック要素のデータである旨を示している。同様に８０３は、「ｗｓｄｓｔ：ＤｅｆａｕｌｔＰｒｉｎｔＴｉｃｋｅｔ」開始要素であり、開始要素から終了要素の間にパブリック要素の「ＤｅｆａｕｌｔＰｒｉｎｔＴｉｃｋｅｔ」要素データが格納されていることを示している。８０４と８０５はそれぞれ「ｉｈｖ：Ｓｔａｔｕｓ」開始要素と「ｉｈｖ：Ｃａｐａｂｉｌｉｔｙ」開始要素であり、「ｉｈｖ」という接頭辞であるためプライベート要素であることを示している。また、それぞれの開始要素から終了要素の間に「Ｓｔａｔｕｓ」データと「Ｃａｐａｂｉｌｉｔｙ」要素データがそれぞれ格納されている。このように、図８（ａ）で示す応答データは、複数のデータが一度に返却される様子を示している。図８（ａ）で示す応答データには複数のプライベート要素のデータと複数のパブリック要素のデータとが含まれるため、情報処理装置１００が受信可能なデータサイズ制限を越える恐れがある。

一方、図８（ｂ）は、図８（ａ）の「Ｓｔａｔｕｓ」データが空データで返却された様子を示している。８１１は「ｗｓｄｓｔ：ＥｌｅｍｅｎｔＤａｔａ」要素に、「Ｎａｍｅ＝“ｉｈｖ：Ｓｔａｔｕｓ”」属性情報と、「Ｖａｌｉｄ＝“ｆａｌｓｅ”」属性情報が付加されている様子を示している。８０１の「ｗｓｄｓｔ：ＥｌｅｍｅｎｔＤａｔａ」要素とは異なり、８１１の「ｗｓｄｓｔ：ＥｌｅｍｅｎｔＤａｔａ」要素は、最後が「／＞」で閉じられている空データとなっている。「ｆａｌｓｅ」属性値は、「ｗｓｄｓｔ：ＥｌｅｍｅｎｔＤａｔａ」要素の要素データが無効である（存在しない）旨を示している。また、８１２も同様に空データとなっている。８１２は８１１の要素を空データとしてもよい、即ち遅延してもよいことを示すための要素データ「＿ｄｅｌａｙ」に対する応答であるため印刷装置１５０は８１２を空データで応答する。

なお、空データは最後が「／＞」で閉じられている要素として示す他に、ｎｕｌｌや何も記述していないデータとして表現しても構わない。

このように、図８（ｂ）は、図５（ｂ）のＢｉｄｉ拡張ファイルの５１２を参照した印刷装置１５０が、図６の処理Ｓ６０６で「Ｓｔａｔｕｓ」要素のデータは遅延してもよい事を確認し、「Ｓｔａｔｕｓ」データを間引いた情報取得要求の内容を示している。印刷装置１５０は、この図８（ｂ）の情報取得応答を、図６の処理Ｓ６０９で応答する。

図９は図６の処理Ｓ６１０で通知するＰｉｒｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔの内容を示している。９０１は「ｗｓｄｓｔ：ＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔ」要素である。前述したように９０２は「ｉｈｖ：Ｓｔａｔｕｓ」開始要素であり、プライベート要素の「Ｓｔａｔｕｓ」データが要素９０２に括られている様子を示している。図８（ｂ）の情報取得応答で空データとして応答した「Ｓｔａｔｕｓ」データは、処理Ｓ６１０で図９のイベントデータとして通知される。情報処理装置１００は、図８（ｂ）の情報取得応答を受信（Ｓ４０４）し、後に図９のイベントデータを受信（Ｓ４１３）することとなる。つまり、情報処理装置１００のＳ４０５の情報更新処理時は「Ｓｔａｔｕｓ」データは空データである。しかし、情報処理装置１００はＳ４１４の情報更新処理時によって「Ｓｔａｔｕｓ」データを得ることができる。

なお、本実施形態では、情報処理装置１００と印刷装置１５０の接続が確立した直後にＯＳが複数の要素データをまとめて情報取得要求を行う際の動作を想定して説明した。しかし、情報処理装置１００内のＯＳ以外のソフトウェアが複数の要素データをまとめて情報取得要求を行う際の動作であってもよい。

＜実施形態２＞
実施形態１では、情報取得応答のサイズ制限を越えないための手段として、遅延して通知してもよいことを示す識別子「＿Ｄｅｌａｙ」が付加されたプライベート要素（５１２）に対応するプライベート要素（５１１）を、遅延データの一例である空データ（８１１）として通知する構成を説明した。

本実施形態では、パブリック要素のデータ（８０２・８０３）のみを応答し、プライベート要素のデータはイベント通知（９０２）することにより課題を解決する手段を説明する。また、本実施形態では、情報処理装置１００から簡易を示す識別子「＿Ｄｅｌａｙ」が付加されたプライベート要素（５１２）を送信することが不要な構成である。

図１０は情報取得要求を受信後（Ｓ４０２）の印刷装置１５０の処理を示すフローチャートである。印刷装置１５０は、情報取得要求を受信する（Ｓ１００１）と要求された要素データの確認を行う（Ｓ１００２）。印刷装置１５０は、情報取得要求で要求する要素データにパブリック要素のデータとプライベート要素のデータが含まれているかを判断する（判断Ｓ１００３）。判断Ｓ１００３にて要求された情報はパブリック要素のデータのみ若しくはプライベート要素のデータのみであると判断した場合、印刷装置１５０は応答データを生成する（Ｓ１００４）。処理Ｓ１００４で生成される応答データは、パブリック要素のデータのみ若しくはプライベート要素のデータのみで構成される。印刷装置１５０は、処理Ｓ１００４で生成した応答データを情報処理装置１００へ応答する（Ｓ１００６）。その後、印刷装置１５０は、記憶領域Ｓ１０５０にイベントデータが保存されているかを確認し（Ｓ１００７）、イベントデータが保存されていなければ情報取得要求受信後の処理を終了する（Ｓ１００８）。

一方、判断Ｓ１００３にて、印刷装置１５０は要求された情報は、パブリック要素のデータ且つプライベート要素のデータであると判断した場合、印刷装置は要求されたプライベート要素をイベントデータとして記憶領域Ｓ１０５０に保存する（Ｓ１００５）。その後、印刷装置１５０は要求されたパブリック要素のデータと要求されたプライベート要素のデータに対応する空データで構成される応答データを生成し（Ｓ１００４）、生成した応答データを情報処理装置１００へ応答する（Ｓ１００６）。印刷装置１５０は記憶領域Ｓ１０５０に保存されたイベントデータを読み出して、情報取得要求のあった情報処理装置１００へイベントデータを送信することでイベント通知し（Ｓ１００７）、情報取得要求受信後の処理を終了する（Ｓ１００８）。

以上のように、本実施形態によれば、パブリック要素のデータのみを応答し、プライベート要素のデータはイベント通知することで、情報取得応答のサイズを縮小することを可能とする。なお、イベント通知によって情報処理装置１００へ送信するプライベート要素のデータが複数ある場合、印刷装置１５０は複数のプライベート要素のデータをまとめてイベント通知してもよいし、一つずつイベント通知してもよい。

＜実施形態３＞
実施形態２では、情報取得応答のサイズを縮小する手段として、パブリック要素のデータ（８０２・８０３）とプライベート要素のデータ（９０２）とを分割する（Ｓ１００３・Ｓ１００５）構成を説明した。

本実施形態では、応答データのサイズが制限を越える場合のみ、プライベート要素（５１１）をイベント通知する（９０２）ことにより課題を解決する手段を説明する。

図１１は情報取得要求を受信後（Ｓ４０２）の印刷装置１５０の処理を示すフローチャートである。印刷装置１５０は、情報取得要求を受信する（Ｓ１１０１）と要求された要素データの確認を行う（Ｓ１１０２）。印刷装置１５０は、要求されたパブリック要素とプライベート要素のデータをまとめて応答データとして生成する（Ｓ１１０３）。印刷装置１５０は、処理Ｓ１１０３で生成した応答データのサイズが制限量を越えているか否かを判断する（Ｓ１１０４）。応答データのサイズが制限サイズを越えていない場合と判断した場合、印刷装置１５０は処理Ｓ１１０３で生成した応答データを情報処理装置１００へ応答する（Ｓ１１０５）。その後、印刷装置１５０は記憶領域Ｓ１１５０にイベントデータが保存されているかを確認し（Ｓ１１０６）、イベントデータが保存されていなければ情報取得要求受信後の処理を終了する（Ｓ１１０７）。

一方、判断Ｓ１１０４にて、印刷装置１５０は応答データが制限サイズを越えていると判断した場合、印刷装置１５０は応答データから一つ以上のプライベート要素のデータを間引いて、間引いたプライベート要素のデータを記憶領域Ｓ１１５０へ保存する（Ｓ１１０８）。ここで、プライベート要素のデータを間引くとは、応答データにおける間引く対象のプライベート要素のデータを、具体的には図８（ｂ）の８１１で示すような空データとすることを指す。その後、印刷装置１５０は処理Ｓ１１０８でプライベート要素のデータを間引いた後の応答データを情報処理装置１００へ応答する（１１０５）。続いて、印刷装置１５０は記憶領域Ｓ１１５０に保存されたプライベート要素の要素データを読み出して、情報取得要求のあった情報処理装置１００へイベントデータとしてイベント通知し（Ｓ１１０６）、情報取得要求受信後の処理を終了する（Ｓ１１０７）。

以上のように、本実施形態によれば、応答データのサイズが制限を越える場合にのみ、印刷装置１５０はプライベート要素（５０２・５０３）の要素データをイベント通知することで、情報取得応答のサイズを適切に縮小することを可能とする。

＜実施形態４＞
実施形態１〜３では、情報取得応答のサイズ制限を越えないための手段として、プライベート要素のデータをイベント通知することによって解決した。

本実施形態では、情報処理装置１００が情報取得要求を分割して行うことによって解決する。しかし、情報処理装置１００は、印刷装置１５０との接続が確立した後に行う情報取得要求を、すべての要素を分割して一つずつ要求ことは通信の無駄となる。また、情報処理装置１００内のソフトウェア（ＯＳ及びプリンタドライバ３２１、アプリケーション３０１）によっては、印刷装置１５０との接続確立後に即座に得たい要素データである場合も想定される。よって、分割して要求すべき要素データは、プライベート要素であり、且つ、印刷装置１５０との接続確立後に即座に得られなくとも支障のない要素データであることが望まれる。

印刷装置１５０との接続確立後に即座に得たい要素データの一例としては、印刷装置１５０の印刷能力を示す情報「Ｃａｐａｂｉｌｉｔｙ」８０５が挙げられる。ＯＳは「Ｃａｐａｂｉｌｉｔｙ」８０５の情報を元に、アプリケーション３０１へ印刷設定として用いることのできる用紙のサイズや、用紙の種類などの設定可能情報を生成する。ユーザーは情報処理装置１００と印刷装置１５０とを接続した後に、アプリケーション３０１で設定可能情報が適用された印刷設定が即座に行えることを望む。

図５（ｃ）は、Ｂｉｄｉ拡張ファイル３２４の内容を示す図である。図５（ａ）との差異は、５２１に示す通り「ｄｅｌａｙ＝“ｔｒｕｅ”」属性情報が付加されている点である。「ｄｅｌａｙ」属性の属性値が「ｔｒｕｅ」であることにより、情報処理装置１００は「ｉｈｖ：Ｓｔａｔｕｓ」という印刷装置１５０の情報は遅れて情報取得要求（遅延データ取得要求）を行ってもよいことを示す。

図１２は情報処理装置１００の情報取得要求処理を示すフローチャートである。情報処理装置１００は情報取得要求処理を開始する（Ｓ１２０１）と、Ｂｉｄｉ拡張ファイル３２４の内容を参照し、要求すべきプライベート要素のデータと遅延データ取得要求の可否を確認する（Ｓ１２０２）。情報処理装置１００は、要求すべき要素のデータはパブリック要素のデータのみか否かを判断し（Ｓ１２０３）、パブリック要素のデータのみであった場合は、全てのパブリック要素のデータをまとめて情報取得要求する（Ｓ１２０４）。

ここで、Ｓ１２０３の判断はＢｉｄｉ拡張ファイルに要求すべきプライベート要素のデータが記載されているかどうか判断することにより行う。Ｂｉｄｉ拡張ファイルに要求すべきプライベート要素のデータが記載されていなければ、要求すべき要素データはＯＳによるパブリック要素のデータの要求のみであると判断し、Ｓ１２０３ではＹＥＳと判断される。一方、Ｂｉｄｉ拡張ファイルに要求すべきプライベート要素のデータが記載されていれば、要求すべき要素データはＯＳによるパブリック要素のデータとＢｉｄｉ拡張ファイルによるプライベート要素のデータであると判断する。よって、Ｓ１２０３ではＮＯと判断される。

処理Ｓ１２０４に対する応答データを得ると、情報処理装置１００は取得した応答データを記憶領域Ｓ１２５０へ保存（Ｓ１２０５）後、情報取得要求処理を終了する（Ｓ１２０６）。

一方、判断Ｓ１２０３で取得すべき要素のデータはパブリック要素のデータのみではないと判断した場合、情報処理装置１００は全てのパブリック要素のデータと、全ての遅延が許可されていないプライベート要素のデータをまとめて情報取得要求する（Ｓ１２０７）。処理Ｓ１２０７に対する応答データを得ると、情報処理装置１００は取得した応答データを記憶領域Ｓ１２５０へ保存（Ｓ１２０８）する。その後、情報処理装置１００は遅延許可されたプライベート要素のデータを情報取得要求する（Ｓ１２０９）。処理Ｓ１２０９に対する応答データを得ると、情報処理装置１００は取得した応答データを記憶領域Ｓ１２５０へ保存（Ｓ１２１０）後、情報取得要求処理を終了する（Ｓ１２０６）。
以上のように、本実施形態によれば、遅延データ取得要求を行ってもよい情報のみ遅延して要求を行うことにより、応答データが制限サイズを越えることが無いよう、適切に分割して情報取得要求を行うことができる。

上記のようにＳ１２０８の処理の完了後にＳ１２０９を行うことにより、画像処理装置の単位時間あたりの処理負荷を減らすことが可能である。なお、Ｓ１２０８の処理の完了後にＳ１２０９を行わずに、すなわち、Ｓ１２０８の応答データの受信や保存を待たずに、Ｓ１２０９のプライベートデータの要求を行うように構成しても構わない。

本実施形態においては、図１２の処理をＯＳのポートモニター３１４で行う想定である。そのため、遅延データ取得要求が発生することを想定していないＩＨＶ製のプリンタドライバ３２１に影響が発生しないよう、遅延データ取得要求を許可する旨をプリンタドライバ３２１のＢｉｄｉ拡張ファイル３２４によってポートモニター３１４に伝える構成である。

しかし、全てのＩＨＶ製プリンタドライバが、遅延データ取得要求が起こり得ることを認識している場合、Ｂｉｄｉ拡張ファイル３２４の遅延許可情報５２１は必須ではない。つまり、ポートモニター３１４は常にプライベート要素のデータとパブリック要素のデータとを分けて情報取得要求を行うよう構成しても、本件における課題は解決することが可能である。

＜実施形態５＞
実施形態４は情報処理装置１００で行う情報取得要求を予め分割する構成を説明した。実施形態４は応答データのサイズを予め情報処理装置１００が知ることができないため、予め分割して情報取得要求を行う構成であった。

本実施形態では、情報処理装置１００は全ての要素データをまとめて情報取得要求を行い、例えば応答データが制限サイズを越える場合に、情報処理装置１００から再度情報取得要求を行う構成について説明する。

図１３は情報処理装置１００の情報取得要求処理を示すフローチャートである。情報処理装置１００は情報取得要求処理を開始する（Ｓ１３０１）と、Ｂｉｄｉ拡張ファイル３２４を参照し要求すべきプライベート要素のデータを確認する（Ｓ１３０２）。次に、情報処理装置１００は全ての要素のデータをまとめて情報取得要求を行う（Ｓ１３０３）。ここでは印刷装置１５０は情報取得要求を受信後に要求された要素データのうち少なくとも一つの要素データに後述する「ｒｅｔｒｙ」属性値を付与して応答データを送信する。処理Ｓ１３０３に対する応答データを得ると、情報処理装置１００は取得した応答データを記憶領域Ｓ１３５０へ保存する（Ｓ１３０４）。その後、情報処理装置１００は処理１３０４で受信した応答データを確認し、再試行識別子が付加されたデータが存在するか否かを判断する（Ｓ１３０５）。

再試行識別子は情報処理装置１００が印刷装置１５０から識別子が付与された要素データを再度取得することを示す識別子である。ここで図８（ｃ）を用いて、再試行識別子について詳しく説明する。図８（ｃ）は応答データを示している。８２１の要素には、「Ｖａｌｉｄ」属性に「ｒｅｔｒｙ」属性値が付加されている。「ｒｅｔｒｙ」属性値は、「ｉｈｖ：Ｓｔａｔｕｓ」要素のデータを取得するには再度情報取得要求が必要である旨を示している。

判断Ｓ１３０５で再試行識別子「ｒｅｔｒｙ」が付加された要素があると判断した場合、情報処理装置１００は再試行識別子「ｒｅｔｒｙ」が付加された要素「ｉｈｖ：Ｓｔａｔｕｓ」のみ再度要求する（Ｓ１３０６）。具体的には再度情報取得要求を行うことにより実現する。処理Ｓ１３０６に対する応答データを得ると、情報処理装置１００は取得した応答データを記憶領域Ｓ１３５０へ保存（Ｓ１３０７）後、情報取得要求処理を終了する（Ｓ１３０８）。

一方、判断Ｓ１３０５で再試行識別子「ｒｅｔｒｙ」が付加された要素がないと判断した場合、情報処理装置１００は情報取得要求処理を終了する。

以上のように、本実施形態によれば、例えば応答データが制限サイズを越える場合に、情報処理装置１００は再試行識別子が付加された要素のデータのみ、再度情報取得要求を行えばよく、情報取得要求を行う回数を最低限に留めることが可能となる。

なお、再試行識別子は「ｖａｌｉｄ」属性の「ｒｅｔｒｙ」属性値を用いる構成で説明したが、「ｖａｌｉｄ」属性とは異なる属性によって表現されてもよい。

＜実施形態６＞
本発明の目的は前述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

Claims (8)

1. 第１の要素データと第２の要素データの要求を受信する受信手段と、
   前記第２の要素データがプライベート要素のデータであるかを判断する第１の判断手段と、
   前記第２の要素データは遅延して通知可能であるかを判断する第２の判断手段と、
   前記第１の判断手段が前記第２の要素データはプライベート要素のデータでありかつ前記第２の判断手段が前記第２の要素データは遅延して通知可能であると判断した場合に、前記第２の要素データを遅延して通知することを示す遅延データと前記第１の要素データを、前記受信手段が受信した前記要求に対応する応答データとして応答する応答手段と、
   前記応答手段が前記応答データを応答した後に、前記第２の要素データを通知する通知手段と、を有することを特徴とする画像処理装置。
2. 第１の要素データと第２の要素データの要求を受信する受信手段と、
   前記第１の要素データがパブリック要素のデータでありかつ前記第２の要素データがプライベート要素のデータであるかを判断する判断手段と、
   前記判断手段が前記第１の要素データはパブリック要素のデータでありかつ前記第２の要素データはプライベート要素のデータであると判断した場合に前記第２の要素データを遅延して通知することを示す遅延データと前記第１の要素データを、前記受信手段が受信した前記要求に対応する応答データとして応答する応答手段と、
   前記応答手段が前記応答データを応答した後に、前記第２の要素データを通知する通知手段と、を有することを特徴とする画像処理装置。
3. 前記遅延データは空データであることを特徴とする請求項１または２に記載の画像処理装置。
4. 前記受信手段は識別子を受信して、
   前記応答手段は前記応答データに前記識別子を含めることにより、前記受信手段が受信する前記要求に対応する前記応答データとして応答することを特徴とする請求項１乃至３のいずれか１項に記載の画像処理装置。
5. コンピュータに、
   第１の要素データと第２の要素データの要求を受信する受信工程と、
   前記第２の要素データがプライベート要素のデータであるかを判断する第１の判断工程と、
   前記第２の要素データは遅延して通知可能であるかを判断する第２の判断工程と、
   前記第１の判断工程で前記第２の要素データはプライベート要素のデータでありかつ前記第２の判断工程で前記第２の要素データは遅延して通知可能であると判断した場合に、前記第２の要素データを遅延して通知することを示す遅延データと前記第１の要素データを、前記受信工程で受信した前記要求に対応する応答データとして応答する応答工程と、
   前記応答工程で前記応答データを応答した後に、前記第２の要素データを通知する通知工程と、を実行させることを特徴とするプログラム。
6. コンピュータに、
   第１の要素データと第２の要素データの要求を受信する受信工程と、
   前記第１の要素データがパブリック要素のデータでありかつ前記第２の要素データがプライベート要素のデータであるかを判断する判断工程と、
   前記判断工程で前記第１の要素データはパブリック要素のデータでありかつ前記第２の要素データはプライベート要素のデータであると判断した場合に、前記第２の要素データを遅延して通知することを示す遅延データと前記第１の要素データを、前記受信工程で受信した前記要求に対応する応答データとして応答する応答工程と、
   前記応答工程で前記応答データを応答した後に、前記第２の要素データを通知する通知工程と、を実行させることを特徴とするプログラム。
7. 前記遅延データは空データであることを特徴とする請求項５または６に記載のプログラム。
8. 前記受信工程は識別子を受信して、
   前記応答工程は前記応答データに前記識別子を含めることにより、前記受信工程で受信する前記要求に対応する前記応答データとして応答することを特徴とする請求項５乃至７のいずれか１項に記載のプログラム。

Images