JP6218382B2 - デバイス及びプログラム、制御方法 - Google Patents

Description

本発明は情報処理装置に情報を通知する技術に関する。

従来、ステータス通知という技術が存在する。
特許文献１は、印刷装置が印刷装置内のステータスが変化した場合、印刷装置がホストコンピュータにイベント情報としてステータス情報を送信する技術を開示している。

特開平７−１３７３５８号公報

ここで画像形成装置が複数の情報処理装置に情報を通知可能であり、さらに複数の情報処理装置に特定の情報を通知することで通知された情報処理装置が特定の情報を処理する負荷が上昇する環境を想定する。
特許文献１はそもそも印刷装置が複数のホストコンピュータにステータスを通知することを開示していないため、そもそも特許文献１の技術では複数のホストコンピュータにステータスを通知できない虞がある。
よって本発明は、複数の情報処理装置に情報を通知し、さらに特定の情報処理装置を含む複数の情報処理装置に情報を通知する時に、特定の情報処理装置以外の情報処理装置に特定の情報を通知せずに、特定の情報処理装置に特定の情報を通知することを目的とする。

上記の目的を達成するための本発明に係るデバイスは、前記デバイスの第１の情報を第１の情報処理装置と第２の情報処理装置に通知する登録の要求を前記第１の情報処理装置と前記第２の情報処理装置から受付ける登録手段と、前記デバイスの第２の情報を前記第１の情報処理装置に通知する登録の要求を前記第１の情報処理装置から受付ける受付手段と、前記登録手段が前記要求を前記第１の情報処理装置と前記第２の情報処理装置から受け付けた後に前記デバイスの状態が変化した場合に、前記受付手段が要求を受け付けた前記第１の情報処理装置には前記第１の情報と前記第２の情報を通知して、前記第２の情報処理装置には前記第２の情報を通知せずに前記第１の情報を通知する通知手段と、を有し、前記受付手段は、前記デバイスの第１の情報が記載されたイベント内の情報である前記デバイスの第２の情報を前記第１の情報処理装置に特定の期間通知する登録の要求を前記第１の情報処理装置から受付けると、前記通知手段は、前記第１の情報処理装置に前記第２の情報を前記特定の期間通知し、前記特定の期間は前記第１の情報処理装置が送信した印刷ジョブの処理期間であることを特徴とする。

本発明によれば、特定の情報処理装置を含む複数の情報処理装置に情報を通知する時に、特定の情報処理装置以外の情報処理装置に特定の情報を通知せずに、特定の情報処理装置に特定の情報を通知する。これにより、特定の情報処理装置以外の情報処理装置が特定の情報を処理する負荷を低減することを可能とする。

印刷装置のＥｖｅｎｔ通知集約判定処理を示すフローチャート 印刷システム構成図 パソコンのソフトウェア構成図 インク残量表示アプリケーションの画面を示す図 インク残量表示アプリケーションの処理を示すフローチャート Ｐｒｉｖａｔｅ要素通知開始要求、終了要求、及び開始要求に対する応答の内容を示す図 印刷装置がパソコンの要求を受付けることで行う処理のフローチャート Ｐｒｉｖａｔｅ要素管理テーブルを示す図 ＷＳＤポートモニターのＥｌｅｍｅｎｔ Ｃａｓｈ処理とＳｔａｔｕｓ Ｒｅｓｐｏｎｓｅ処理のフローチャート 印刷装置が通知するＥｖｅｎｔデータの内容を示す図 Ｐｒｉｖａｔｅ要素通知開始要求の内容を示す図 インク残量表示アプリケーションのステータス要求処理を示すフローチャート 印刷装置のＰｒｉｖａｔｅ要素の有効期限管理処理を示すフローチャート Ｐｒｉｖａｔｅ要素管理テーブルを示す図 印刷フローを概念的に表した印刷システムの構成図 Ｐｒｉｖａｔｅ要素通知開始要求及び開始要求に対する応答の内容を示す図 印刷ステータス監視アプリケーションの画面を示す図 印刷装置のＥｖｅｎｔ通知判定処理を示すフローチャート Ｐｒｉｖａｔｅ要素管理テーブルを示す図 実施形態４の印刷装置のＥｖｅｎｔ通知処理を示すフローチャート 実施形態１の印刷装置のＥｖｅｎｔ通知処理を示すフローチャート

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

まず本明細書で想定する課題の一例を説明する。

複数の情報処理装置がそれぞれアプリケーションを有していると仮定する。また、デバイスは情報処理装置内のステータス通知先（Ｌｉｓｔｅｎｅｒ）に対して複数のステータス（ステータスＡとステータスＢ）のうち一つのステータス（ステータスＡ）を通知するものとする。さらに複数のアプリケーションがステータスＡを取得していたものとする。このような場合に、複数の情報処理装置のうちの一つの情報処理装置のアプリケーションが必要なステータスとしてステータスＢの通知をデバイスに要求すると、その他のアプリケーションが必要とするステータスＡが通知されなくなる可能性がある。その他のアプリケーションは必要とする情報が不足して、動作や表示に不備をきたすという可能性がある。

さらに、ネットワーク環境においては、ネットワーク上に複数の情報処理装置が存在することが想定される。イベント通知を要求した情報処理装置が複数存在する場合、デバイスはそれら全ての情報処理装置にステータス情報を通知しなければならず、デバイスのイベント通知処理の負荷は非常に高い。

そこで、情報処理装置内の複数のアプリケーションが正常に動作可能なイベント情報の通知要求手段を提供するとともに、ネットワーク環境におけるデバイスのイベント通知負荷をより軽減することを目的の一つとする。

＜実施形態１＞
本明細書では、デバイスは印刷装置、情報処理装置はパソコンを想定して説明する。また、デバイスはスキャナやＦＡＸ等の画像形成装置であっても構わない。

図２を用いて、印刷装置２５０とネットワーク２９０を介して接続されたパソコン２００によって構成された印刷システムを説明する。

なお、ネットワーク２９０には複数の印刷装置やパソコンが接続されていても構わない。

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

加えて、ＣＰＵ２０３が外部記憶装置２０６に記憶されているプログラムに基づき処理を実行することによって、図３に示されるようなパソコン２００のソフトウェア構成及び後述するフローチャートの各ステップの処理が実現される。

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

加えて、ＣＰＵ２５６がＲＯＭ２５４に記憶されているプログラムに基づき処理を実行することによって後述するフローチャートの各ステップの処理が実現される。

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

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

図４に本実施形態におけるインク残量表示アプリケーションの画面を示す。

図４（ａ）の４００はインク残量表示アプリケーション（以後、インク表示アプリと称す）である。インク表示アプリは、印刷装置２５０の消耗品であるインクの残量情報を印刷装置２５０より得て模式的に示す機能を持つ。４０１にインク残量を表示する対象となる印刷装置２５０の名称を表示している。４０２はインク残量表示部であり、４０３に各種インクの名称を表示し、４０４にインクの残量を模式的に表示する。４０５はインクの状態についてユーザーに注意を促すためのアイコン表示部である。４０６は終了ボタンである。インク表示アプリ４００はユーザーにより終了ボタン４０６が選択されると、処理を終了する。

図５はインク表示アプリ４００の処理を示すフローチャートである。

インク表示アプリ４００は、ユーザーによるパソコン２００の操作またはＯＳにより起動指示を受けると処理を開始する（Ｓ５０１）。インク表示アプリ４００は、初期表示状態として、図４（ｂ）の４２０に示すよう、通信確立中である旨を表示する（Ｓ５０２）。続いて、インク表示アプリ４００は、Ｐｒｉｖａｔｅ要素通知開始要求を印刷装置に対して発行する（Ｓ５０３）。

ここで後述するＥｖｅｎｔデータがステータス情報であれば、Ｐｒｉｖａｔｅ要素には後述する詳細なステータス情報が含まれている。本明細書ではステータス情報のＰｒｉｖａｔｅ要素をＰｒｉｖａｔｅステータス情報と呼ぶ。一方、同じく後述するＥｖｅｎｔデータがステータス情報であれば、Ｐｕｂｌｉｃ要素には単純で一般化されたステータス情報が含まれている。本明細書ではステータス情報のＰｕｂｌｉｃ要素をＰｕｂｌｉｃステータス情報と呼ぶ。

パソコン２００はＳ５０３の要求を行うことでＰｒｉｖａｔｅステータス情報とＰｕｂｌｉｃステータス情報の両方を印刷装置２５０から取得することができる。Ｐｒｉｖａｔｅ要素通知開始要求（Ｓ５０３）は、具体的にはマイクロソフト社のＷＳＤ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅで定義されるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを印刷装置２５０に通知する処理である。

（ステータス情報とＥｖｅｎｔデータ）
ここでステータス情報とＥｖｅｎｔデータ、Ｐｕｂｌｉｃ、Ｐｒｉｖａｔｅの関係について説明する。

本明細書ではＰｒｉｖａｔｅ要素を含むＥｖｅｎｔデータをＰｒｉｖａｔｅＥｖｅｎｔデータと呼ぶ。同様にＰｕｂｌｉｃ要素を含むＥｖｅｎｔデータをＰｕｂｌｉｃＥｖｅｎｔデータと呼ぶ。

また、Ｐｕｂｌｉｃステータス情報及びＰｒｉｖａｔｅステータス情報はＥｖｅｎｔデータに含まれる情報の一例である。なお、Ｅｖｅｎｔデータにはステータス情報の他に印刷装置の構成情報や印刷装置の能力情報が含まれていても構わない。

（Ｐｒｉｖａｔｅ要素通知開始・終了要求及び応答）
次に、図６（ａ）を参照して、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔにて発行するＰｒｉｖａｔｅ要素通知開始要求の内容を説明する。ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔはＸＭＬで記述される。６０１はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ開始要素である。ここで、「ｗｓｄｓｔ」という接頭辞は、標準的（Ｐｕｂｌｉｃ）なＷＳＤ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅのネームスペースの略称である。６０２はＲｅｑｕｅｓｔｅｄＥｌｅｍｅｎｔｓ開始要素である。６０３はＮａｍｅ要素に「ｉｈｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」というデータが包まれている様子を示している。「ｉｈｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」データを印刷装置２５０に通知することで、印刷装置２５０は「ｉｈｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」という情報を要求元に応答する処理（後述する）を行う。

ここで、「ｉｈｖ」という接頭辞は、Ｐｒｉｖａｔｅ要素のネームスペースの略称である。ＩＨＶによりカスタマイズされたＶｅｎｄｅｒ独自（Ｐｒｉｖａｔｅ）の要素であることを意味する。

６０４はｐａｒａｍ＝“Ｉｄ”という属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に「１１１１１１１１」というデータが包まれている様子を示している。「１１１１１１１１」というデータはパソコン２００内で動作するアプリケーションの識別子であり、少なくともパソコン２００内で重複しない識別子である。もちろんＧＵＩＤ （Ｇｌｏｂａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）のように、パソコン外においても固有の識別子であってもよい。「Ｉｄ」属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素にて「１１１１１１１１」というデータを通知することで、印刷装置２５０は「ｉｈｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」という情報の通知に関する要求元のアプリケーションを識別する情報として用いる（後述する）。６０５はｐａｒａｍ＝“Ｌｉｓｔｅｎｅｒ”という属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に「Ｒｅｑｕｅｓｔｅｒ Ｏｎｌｙ」というデータが包まれている様子を示している。「Ｌｉｓｔｅｎｅｒ」属性が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素にて「Ｒｅｑｕｅｓｔｅｒ Ｏｎｌｙ」というデータを通知することで、印刷装置２５０は「ｉｈｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」という情報はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔの要求元のパソコンへのみＥｖｅｎｔ通知することを記憶する（後述する）。６０６はｐａｒａｍ＝“ｐｅｒｉｏｄ”という属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に「Ｂｅｇｉｎ」というデータが包まれている様子を示している。「ｐｅｒｉｏｄ」属性が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素にて「Ｂｅｇｉｎ」というデータを通知することで、印刷装置２５０は「ｉｈｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」という情報は、終了指示があるまで要求元のパソコン２００にＥｖｅｎｔ通知し続けることを記憶する（後述する）。

インク表示アプリ４００は、Ｐｒｉｖａｔｅ要素通知開始要求（Ｓ５０３）にて今後ｉｈｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓをＥｖｅｎｔ通知し続けることを要求すると、その応答の有無を判断する（Ｓ５０４）。Ｓ５０４で、インク表示アプリ４００が印刷装置２５０からの応答が得られなかった場合、インク表示アプリ４００は通信エラー表示を行う（Ｓ５０５）。ここで、インク表示アプリ４００の表示は、図４（ｂ）の４２０に印刷装置との通信に失敗した旨を表示する。通信エラー表示（Ｓ５０５）を行った後、インク表示アプリ４００はＩｎｔｅｒｖａｌ処理を行う（Ｓ５０６）。Ｉｎｔｅｒｖａｌ処理（Ｓ５０６）とは、任意の時間を開けて次の処理へ進むためのＷａｉｔ処理である。Ｉｎｔｅｒｖａｌ処理（Ｓ５０６）を終えると、インク表示アプリ４００は再度通信確立中表示（Ｓ５０２）を行う。本実施形態においてＩｎｔｅｒｖａｌ処理でＷａｉｔする時間は任意に設定される時間であり、固定時間であってもよいし、ネットワーク通信状況を踏まえて動的に生成される時間であってもよい。

Ｓ５０４にて応答があった場合、インク表示アプリ４００はＰｒｉｖａｔｅ要素通知開始要求の印刷装置２５０への登録成否を判断する（Ｓ５０７）。登録に失敗した場合は、インク表示アプリ４００は通信エラー表示を行う（Ｓ５０５）。登録に成功した場合は、インク表示アプリ４００は応答情報からＰｒｉｖａｔｅ要素を抽出する（Ｓ５０８）。インク表示アプリ４００はＳ５０８で抽出した印刷装置２５０から得たＰｒｉｖａｔｅステータス情報と、Ｐｕｂｌｉｃステータス情報（後述する）に従ってインク残量表示を行う（Ｓ５０９）。応答情報とは、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対する応答情報であるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅである。

ここで、図６（ｂ）を参照して、Ｐｒｉｖａｔｅ要素通知開始要求の応答情報であるＧｅｔＰｉｒｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅの内容について説明する。ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅはＸＭＬで記述される。６２０はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ開始要素である。６２１はＥｌｅｍｅｎｔＤａｔａ開始要素であり、Ｎａｍｅ属性の属性値に以降のＸＭＬ情報は「ｉｈｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」の応答情報である旨を示し、この応答情報が有効である旨をＶａｌｉｄ属性の「ｔｕｒｅ」属性値にて示している。６２２はＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ開始要素である。６２３はＥｎｔｒｙ開始要素にｎａｍｅ＝“Ｂｌａｃｋ”という属性情報が付されている。この「Ｂｌａｃｋ」という属性値は、以降のＸＭＬ情報は黒色インクに関する情報であることを示している。６２４はＩｎｋＳｔａｔｅ要素に「Ｏｕｔ」というデータが包まれている様子を示す。ＩｎｋＳｔａｔｅの「Ｏｕｔ」というデータはインクが無くなった可能性のある旨を示している。６２５はＭｅｓｓａｇｅ要素にＣＤＡＴＡで包まれたデータとして「Ｉｎｋ ｈａｓ ｒｕｎ ｏｕｔ．」データが包まれた様子を示している。６２６はＩｃｏｎ要素に「Ｃｒｏｓｓ」というデータが包まれている様子を示している。６２７はＳｕｐｐｏｒｔＣｏｄｅ要素に「Ｅ２０００」というデータが包まれている様子を示している。図６（ｂ）で説明したＰｒｉｖａｔｅ要素「ｉｎｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」を抽出（Ｓ５０８）しステータス情報を得て、インク表示アプリ４００は図４（ａ）で説明したインク表示を行う（Ｓ５０９）。

図６（ｃ）はＰｒｉｖａｔｅ要素通知終了要求であるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを示す。６１０のｐａｒａｍ＝“Ｉｄ”という属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に「１１１１１１１１」というアプリケーションの識別子が設定されている。６１１のＲｅｑｕｉｒｅｍｅｎｔｓ ｐａｒａｍ＝“ｐｅｒｉｏｄ”要素には「Ｅｎｄ」データが包まれている。これら６１０・６１１に示す情報を受信した印刷装置２５０はＰｒｉｖａｔｅ要素通知登録を解除する（後述する）。

図６（ｄ）はＰｒｉｖａｔｅ要素の通知を一度だけ要求するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを示す。６３０はｐａｒａｍ＝“ｐｅｒｉｏｄ”という属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に「Ｏｎｃｅ」というデータが包まれている様子を示している。図６（ｄ）の要求を受け付けた印刷装置２５０は要求を受け付けた後にパソコン２００に一度だけＰｒｉｖａｔｅ要素を通知する。

（インク表示アプリ）
図４（ｃ）は図４（ａ）のインク表示アプリをユーザーが操作したときの表示状態を示している。図４（ｃ）の４１０のアイコン表示は、６２６のＩｃｏｎ要素「Ｃｒｏｓｓ」データを基に表示している。４１０アイコンをユーザーが選択した場合、４１１に示すポップアップ表示にて「Ｉｎｋ ｈａｓ ｒｕｎ ｏｕｔ．」というメッセージをユーザーに伝える。このメッセージは、６２５のＭｅｓｓａｇｅ要素「Ｉｎｋ ｈａｓ ｒｕｎ ｏｕｔ．」データを基に表示している。４１２は操作説明書起動ボタンであり、このボタンをユーザーが選択することによって、インク表示アプリは電子的な操作説明書（不図示）を表示する。このとき、操作説明書は「Ｏｕｔ」というインク状態について解説するページが初期画面として開かれる。この「Ｏｕｔ」インク状態の解説ページを開く動作は、６２７のＳｕｐｐｏｒｔＣｏｄｅ要素「Ｅ２０００」データを電子的な操作説明書にパラメータとして渡すことで実現する。ここで説明した各種データは、詳細情報（Ｐｒｉｖａｔｅ要素）であり、図４で説明したようなアプリケーションのみが必要とする。図４で説明したようなアプリケーションが動作しないパソコン２００では、Ｐｒｉｖａｔｅ要素の情報は不要となる。そのため、Ｐｒｉｖａｔｅ要素が不要なパソコンには、印刷装置２５０はＰｒｉｖａｔｅ要素を通知しないことが望まれる。

インク表示アプリ４００は、インク残量表示（Ｓ５０９）を行った後、ステータス要求処理を行う（Ｓ５１０）。ステータス要求処理（Ｓ５１０）とは、印刷装置２５０から通知されたＥｖｅｎｔデータを受信するパソコン２００内のＬｉｓｔｅｎｅｒモジュールから、ステータスを取得する処理である。本実施形態においては、ＬｉｓｔｅｎｅｒモジュールはＷＳＤポートモニターを想定して説明する（後述する）。インク表示アプリ４００は、印刷装置２５０からのステータス要求処理（Ｓ５１０）の応答の有無を判定する（Ｓ５１１）。応答がなかったと判断した場合は、インク表示アプリ４００は通信エラーを表示する（Ｓ５１２）。その後、Ｉｎｔｅｒｖａｌ処理（Ｓ５１３）を行い、再度ステータス要求処理（Ｓ５１０）に戻る。

Ｓ５１１にて応答があったと判断した場合、インク表示アプリ４００は印刷装置２５０のステータス情報を解析し、ステータス情報の更新の有無を判定する（Ｓ５１４）。更新があった場合はインク残量表示を更新し（Ｓ５１５）、アプリ終了判定を行う（Ｓ５１６）。Ｓ５１４でステータス更新がないと判断した場合は、インク残量表示を更新せずアプリ終了判定を行う（Ｓ５１６）。ここで、アプリ終了判定（Ｓ５１６）はインク表示アプリ４００の終了ボタン４０６がユーザーにより選択されたかを判定する処理を一例として示す。Ｓ５１６にてユーザーによるアプリ終了指示がないと判断した場合、インク表示アプリ４００はＩｎｔｅｒｖａｌ処理（Ｓ５１３）を経て、ステータス要求処理（Ｓ５１０）へ戻る。

Ｓ５１６でユーザーによるアプリ終了指示があったと判断した場合、インク表示アプリ４００は図６（ｃ）のＰｒｉｖａｔｅ要素通知終了要求を印刷装置２５０に発行し（Ｓ５１７）、処理を終了する（Ｓ５１８）。

（パソコン要求受付処理）
図７（ａ）は印刷装置２５０がパソコン２００の要求を受付けることで行う処理を示すフローチャートである。要求の一例としてはＳｕｂｓｃｒｉｂｅリクエストが挙げられる。

パソコン２００のＯＳはパソコン２００内にインストールされたＷＳＤプリンタドライバと関連付けられる印刷装置２５０がネットワーク上に存在することを確認するとＳｕｂｓｃｒｉｂｅリクエストを行う。Ｓｕｂｓｃｒｉｂｅとはパソコン２００と印刷装置２５０との間で行うＥｖｅｎｔの通知登録処理である。パソコン２００のＯＳはＳｕｂｓｃｒｉｂｅ時に印刷装置２５０がパソコン２００にどのＥｖｅｎｔを通知するか指定することができる。ここでは印刷装置２５０がパソコン２００に通知できる全てのＥｖｅｎｔをＳｕｂｓｃｒｉｂｅ時に指定したとして説明を進める。

印刷装置２５０はパソコン要求受付処理を開始する（Ｓ７２１）と、パソコン２００の要求がＳｕｂｓｃｒｉｂｅであるかどうかを判定する（Ｓ７２２）。判定の結果ＳｕｂｓｃｒｉｂｅであればＳ７２３に進み、Ｓｕｂｓｃｒｉｂｅでなければ後述するＳ７０１に進む。

Ｓ７２３ではＥｖｅｎｔの通知先としてパソコン２００を登録する。

Ｓ７２４ではパソコン２００にＳｕｂｓｃｒｉｂｅレスポンスを行う。

その後、印刷装置２５０はパソコン要求受付処理を終了する（Ｓ７２５）。

パソコン２００は、ＯＳが終了するタイミング、又は、印刷装置２５０がネットワーク上から存在しなくなる（印刷装置２５０の電源ＯＦＦも含む）タイミングで、Ｕｎｓｕｂｓｃｒｉｂｅを行う。Ｕｎｓｕｂｓｃｒｉｂｅとは、Ｅｖｅｎｔの通知登録を解除する処理である。

なお、パソコンのアプリケーションによっては、Ｓｕｂｓｃｒｉｂｅをしていないにも関わらず、Ｐｒｉｖａｔｅ要素通知開始要求（Ｓ５０３）又はＰｒｉｖａｔｅ要素通知終了要求（Ｓ５１７）を行う可能性が考えられる。よって、Ｓ７２２でＳｕｂｓｃｒｉｂｅでないと判定した場合に、Ｓ７０１の処理の前にパソコンがＳｕｂｓｃｒｉｂｅ済みであるかどうか判定して、Ｓｕｂｓｃｒｉｂｅ済みであると判定した場合にＳ７０１の処理を行うように構成してもよい。また、パソコンがＳｕｂｓｃｒｉｂｅ済みであるかどうかの判定を行う処理を設けた場合は、判定の結果Ｓｕｂｓｃｒｉｂｅ済みでなければ、印刷装置２５０はパソコン要求受付処理を終了する。

（Ｐｒｉｖａｔｅ要素通知先の管理）
図７（ｂ）は印刷装置２５０のＰｒｉｖａｔｅ要素登録及び登録解除処理を示すフローチャートである。図７を参照して、インク表示アプリ４００のＰｒｉｖａｔｅ要素通知開始要求（Ｓ５０３）及びＰｒｉｖａｔｅ要素通知終了要求（Ｓ５１７）を受けて行う、印刷装置２５０のＰｒｉｖａｔｅ要素登録及び登録解除処理を説明する。

印刷装置２５０は、図６（ａ）で示したようなＲｅｑｕｉｒｅｍｅｎｔｓ要素を含むＰｒｉｖａｔｅ要素通知要求を受信すると、Ｐｒｉｖａｔｅ要素登録及び登録解除処理を開始する（Ｓ７０１）。印刷装置２５０は、「ｐｅｒｉｏｄ」属性値が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素のデータを判別する（Ｓ７０２）。図６（ａ）で示すような登録要求であった場合は、印刷装置２５０はＰｒｉｖａｔｅ要素「ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」（６０３）をＥｖｅｎｔ発行するよう記憶する（Ｓ７０３）。さらに、「ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」（６０３）を含んだＥｖｅｎｔを通知する先として、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行したパソコン２００内のＬｉｓｔｅｎｅｒを登録する（Ｓ７０３）。さらに、印刷装置２５０は要求元アプリＩＤを記憶する（７０３）。続いて、印刷装置２５０は現在のステータス収集を行う（Ｓ７０４）。印刷装置２５０は、登録完了の旨として現在のステータス情報をＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ（図６（ｂ））によって応答（Ｓ７０５）した後、Ｐｒｉｖａｔｅ要素登録処理を終了する（Ｓ７０６）。

図８は印刷装置２５０内で管理するＰｒｉｖａｔｅ要素管理テーブルを模式的に示した図である。図６（ａ）のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを印刷装置２５０が受信することにより、印刷装置２５０は図８（ａ）のように情報を保存する。８０１はＰｒｉｖａｔｅ要素名として「ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」が格納されている様子を示す。８０２は通知先として「情報処理装置ｘｘｘ」が格納されている様子を示す。８０３は期間として「Ｂｅｇｉｎ」が格納されている様子を示す。８０４はアプリＩＤとして「１１１１１１１１」が格納されている様子を示す。図８（ａ）のＰｒｉｖａｔｅ要素管理テーブルの登録状況だった場合、印刷装置２５０は「ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」要素８０１以下の情報に遷移があった場合、通知先「情報処理装置ｘｘｘ」８０２に「ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」要素を通知する。

再度図７の説明に戻る。Ｓ７０２にて、図６（ｃ）に示すような登録解除要求であった場合、印刷装置２５０はＰｒｉｖａｔｅ要素通知先として解除すべきアプリＩＤが、通知先のパソコンの中で最後となるアプリＩＤかどうかを判定する（Ｓ７０７）。ここで、図８（ｂ）は同一の通知先「情報処理装置ｘｘｘ」に対し、アプリＩＤが２つ格納されている様子を示す。８１０はアプリＩＤとして「１１１１１１１１」と「２２２２２２２２」とが格納されている。これはパソコン２００内の異なる２つのアプリケーションが、それぞれＰｒｉｖａｔｅ要素「ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」の通知登録要求を行った状態を示している。印刷装置２５０は、Ｓ７０７において、図８（ｂ）のように一つのＰｒｉｖａｔｅ要素の特定の通知先に対し、アプリＩＤが複数登録されている場合は、アプリＩＤをＰｒｉｖａｔｅ要素管理テーブルから削除する（Ｓ７０８）。図８（ｂ）に示すＰｒｉｖａｔｅ要素管理テーブルの状態から、アプリＩＤ「２２２２２２２２」を削除した状態は図８（ａ）に示すＰｒｉｖａｔｅ要素管理テーブルの状態となる。印刷装置２５０は登録解除完了の旨を応答（Ｓ７０９）し、終了する（Ｓ７０６）。この後、「ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」要素８０１以下の情報に遷移があった場合でも、アプリＩＤ「１１１１１１１１」８０４はまだ通知要求を解除していないため、印刷装置２５０は通知先「情報処理装置ｘｘｘ」８０２に「ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」要素を通知する。

Ｓ７０７において、一つのＰｒｉｖａｔｅ要素の特定の通知先に対し、アプリＩＤが一つのみ登録されている状態だった場合は、Ｐｒｉｖａｔｅ要素通知先から通知先８０２を解除する（Ｓ７１０）。以降「ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」要素８０１以下の情報に遷移があった場合、印刷装置２５０は通知先「情報処理装置ｘｘｘ」８０２に「ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ」要素を通知しない。この後、印刷装置２５０は登録解除完了の旨を応答（Ｓ７１１）し、終了する（Ｓ７０６）。

なお、Ｐｒｉｖａｔｅ要素の通知要求が全て解除された状態にあるパソコン２００に対しても、印刷装置２５０はＰｕｂｌｉｃ要素の通知は行う。図６（ｃ）に示すようなＰｒｉｖａｔｅ要素登録解除要求は、Ｐｒｉｖａｔｅ要素をＥｖｅｎｔに追加することを解除するのみの要求であり、Ｅｖｅｎｔの通知登録を解除する要求とは異なる。

（印刷装置のＥｖｅｎｔ通知処理）
図２１は印刷装置２５０のＥｖｅｎｔ通知処理を示すフローチャートである。

印刷装置２５０はＥｖｅｎｔ通知処理を開始する（Ｓ２１５１）と、Ｓ２１５２からＳ２１５４まで印刷装置２５０にＳｕｂｓｃｒｉｂｅしたパソコンごとに処理を行う。

Ｓ２１５２では対象パソコンがＰｕｂｌｉｃＥｖｅｎｔデータを通知する登録であるかどうかを判定する。具体的には対象パソコンがＳ７２３の処理が行われたパソコンであればＰｕｂｌｉｃＥｖｅｎｔデータを通知する登録であると判定する。さらに、Ｓ７１０によってＰｒｉｖａｔｅＥｖｅｎｔデータを通知する登録を解除されたパソコンである場合もＰｕｂｌｉｃＥｖｅｎｔデータを通知する登録であると判定する。一方、対象パソコンがＳ７２３の処理に加えてＳ７０３の処理が行われたパソコン（前述のＰｒｉｖａｔｅ要素通知先）であればＰｕｂｌｉｃＥｖｅｎｔデータとＰｒｉｖａｔｅＥｖｅｎｔデータを通知する登録であると判定する。対象パソコンがＰｕｂｌｉｃＥｖｅｎｔデータを通知する登録である場合はＳ２１５３に進み、対象パソコンがＰｕｂｌｉｃＥｖｅｎｔデータを通知する登録でない場合はＳ２１５４に進む。

Ｓ２１５３では対象パソコンにＰｕｂｌｉｃＥｖｅｎｔデータを通知してＳ２１５５に進む。Ｓ２１５３ではＳ２１５４と異なりＰｒｉｖａｔｅＥｖｅｎｔデータは対象パソコンには通知しない。具体例を挙げると後述する図１０（ａ）に示すＰｕｂｌｉｃＥｖｅｎｔデータを対象パソコンに通知する。

Ｓ２１５４では対象パソコンにＰｕｂｌｉｃＥｖｅｎｔデータとＰｒｉｖａｔｅＥｖｅｎｔデータを通知してＳ２１５５に進む。具体例を挙げると後述する図１０（ａ）と図１０（ｂ）もしくは図１０（ｃ）に示すＰｕｂｌｉｃＥｖｅｎｔデータとＰｒｉｖａｔｅＥｖｅｎｔデータを対象パソコンに通知する。

Ｓ２１５５ではＳｕｂｓｃｒｉｂｅしたパソコン全てにＳ２１５２からＳ２１５４までの処理を行ったかどうかを判定する。行なっていなければ次の対象パソコンについてＳ２１５２以降の処理を行い、行なっていれば処理を終了する（Ｓ２１５６）。

ここで具体的にパソコンＡとパソコンＢという２つのパソコンを例に図２１の処理を説明する。ここでは印刷装置２５０において、パソコンＡはＰｕｂｌｉｃＥｖｅｎｔデータとＰｒｉｖａｔｅＥｖｅｎｔデータを通知する登録であり、パソコンＢはＰｕｂｌｉｃＥｖｅｎｔデータを通知する登録であるとする。

印刷装置２５０はＳ２１５２の判定の結果、対象パソコンがパソコンＡである場合はＳ２１５４の処理を行い、対象パソコンがパソコンＢである場合はＳ２１５３の処理を行う。

（Ｅｌｅｍｅｎｔ Ｃａｓｈ処理とＳｔａｔｕｓ Ｒｅｓｐｏｎｓｅ処理）
図９は、ＷＳＤポートモニターのＥｌｅｍｅｎｔ Ｃａｓｈ処理とＳｔａｔｕｓ Ｒｅｓｐｏｎｓｅ処理を示すフローチャートである。印刷装置２５０から通知されたＥｖｅｎｔデータをパソコン２００内のＬｉｓｔｅｎｅｒモジュールであるＷＳＤポートモニターが受信して記憶し、インク表示アプリ４００からのステータス要求（Ｓ５１０）に対しステータス情報を提供する処理を説明する。

初めにＷＳＤポートモニターのＥｌｅｍｅｎｔ Ｃａｓｈ（要素Ｃａｓｈ）処理について説明する。要素Ｃａｓｈ処理は、印刷装置２５０からのＥｖｅｎｔ通知をＷＳＤポートモニターが受信すると開始する（Ｓ９０１）。要素Ｃａｓｈ処理を開始する（Ｓ９０１）と、ＷＳＤポートモニターは受信したＥｖｅｎｔデータの中身を参照する。ＷＳＤポートモニターはＥｖｅｎｔデータに含まれる要素が、Ｐｒｉｖａｔｅ要素か、Ｐｕｂｌｉｃ要素か、を判定する要素Ｔｙｐｅ判定（Ｓ９０２）を行う。要素Ｔｙｐｅ判定処理（Ｓ９０２）により、Ｐｒｉｖａｔｅ要素が存在すると判断した場合、ＷＳＤポートモニターはＰｒｉｖａｔｅ要素定義ファイル（Ｓ９９１）を参照する（Ｓ９０３）。Ｐｒｉｖａｔｅ要素定義ファイル（Ｓ９９１）とは、Ｍｉｃｒｏｓｏｆｔ社のＯＳであるＷｉｎｄｏｗｓ８（登録商標）に導入されたｖ４ Ｐｒｉｎｔｅｒ Ｄｒｉｖｅｒの構成ファイルのひとつであり、「Ｂｉｄｉ Ｅｘｔｅｎｓｉｏｎ Ｆｉｌｅ」と呼ばれるものである。Ｂｉｄｉ Ｅｘｔｅｎｓｉｏｎ Ｆｉｌｅには、印刷装置２５０から受信したＥｖｅｎｔのＰｒｉｖａｔｅ要素の扱い方も記されている。本発明においては、Ｂｉｄｉ Ｅｘｔｅｎｓｉｏｎ ＦｉｌｅをＰｒｉｖａｔｅ要素定義ファイル（Ｓ９９１）と称す。Ｐｒｉｖａｔｅ要素定義ファイル（Ｓ９９１）を確認（Ｓ９０３）し、受信したＥｖｅｎｔデータに含まれるＰｒｉｖａｔｅ要素をアプリに応答する情報として蓄積すべきかどうかを判断する定義済み判断（Ｓ９０４）を行う。Ｓ９０４にてＰｒｉｖａｔｅ要素データを蓄積すべきと判断した場合、ＷＳＤポートモニターはＰｒｉｖａｔｅ要素データを記憶領域（Ｓ９９０）に保存（Ｓ９０５）した後、処理を終了する（Ｓ９０６）。Ｓ９０４にてＰｒｉｖａｔｅ要素データを蓄積すべきではないと判断した場合、Ｐｒｉｖａｔｅ要素データを保存することなく処理を終了する（Ｓ９０６）。一方、Ｓ９０２により情報はＰｕｂｌｉｃ要素であると判断した場合、ＷＳＤポートモニターはＰｕｂｌｉｃ要素データを記憶領域（Ｓ９９０）に保存（Ｓ９０５）して処理を終了する（Ｓ９０６）。

続いてＷＳＤポートモニターのＳｔａｔｕｓ Ｒｅｓｐｏｎｓｅ（ステータス応答）処理について説明する。ステータス応答処理は、アプリケーション３０１からステータスの応答要求があると開始する（Ｓ９５１）。本実施形態においてはインク表示アプリ４００からステータス応答要求があった場合について説明する。ステータス応答処理を開始する（Ｓ９５１）と、ＷＳＤポートモニターは応答要求された要素データの要素Ｔｙｐｅを判定する（Ｓ９５２）。Ｓ９５２にて応答要求された要素データがＰｒｉｖａｔｅ要素であると判断した場合、ＷＳＤポートモニターはＰｒｉｖａｔｅ要素定義ファイル（Ｓ９９１）を確認する（Ｓ９５３）。Ｓ９５３の後、ＷＳＤポートモニターはステータス応答要求のあったＰｒｉｖａｔｅ要素データが蓄積すべきＰｒｉｖａｔｅ要素データとして蓄積されているかを判断する定義済み判断（Ｓ９５４）を行う。Ｓ９５４でステータス応答要求のあったＰｒｉｖａｔｅ要素データは蓄積しているＰｒｉｖａｔｅ要素データであると判断した場合、ＷＳＤポートモニターはＰｒｉｖａｔｅ要素データを記憶領域（Ｓ９９０）から読み出す（Ｓ９５５）。続いて、ＷＳＤポートモニターは読み出したＰｒｉｖａｔｅ要素データをインク表示アプリ４００へ応答する（Ｓ９５５）。その後、ＷＳＤポートモニターは処理を終了する（Ｓ９５７）。判断（Ｓ９５４）でステータス応答要求のあったＰｒｉｖａｔｅ要素データは蓄積していないＰｒｉｖａｔｅ要素データだと判断した場合、ＷＳＤポートモニターはＰｒｉｖａｔｅ要素データが記憶領域（Ｓ９９０）に存在しない旨をインク表示アプリ４００へ応答（Ｓ９５６）し、処理を終了する（Ｓ９５７）。一方、Ｓ９５２にて応答要求された要素データがＰｕｂｌｉｃ要素であると判断した場合、ＷＳＤポートモニターはＰｕｂｌｉｃ要素データを記憶領域（Ｓ９９０）から読み出してインク表示アプリ４００へ応答する（Ｓ９５５）。その後、ＷＳＤポートモニターは処理を終了する（Ｓ９５７）。本実施形態においては、ＬｉｓｔｅｎｅｒモジュールとしてＷＳＤポートモニターが印刷装置２５０からのＥｖｅｎｔデータを受信し、アプリケーションにＥｖｅｎｔデータ内のステータス情報を供給する構成を説明した。しかし、パソコン２００内にＩＨＶ独自のＬｉｓｔｅｎｅｒモジュールをサービスとしてインストールし、印刷装置２５０からのＥｖｅｎｔデータの受信、及び、アプリケーションへのステータス供給を、ＩＨＶ独自のＬｉｓｔｅｎｅｒモジュールが行ってもよい。

図９の構成を設けることによるメリットを説明する。

例えば図９の構成が用意されていない環境で、印刷装置２５０から通知されたＥｖｅｎｔデータをパソコン２００が受信した後に、インク表示アプリ４００が起動したとする。この場合、Ｅｖｅｎｔデータを誰も記憶していなければ当然インク表示アプリ４００はＥｖｅｎｔデータを取得できない。

しかし、図９のようにＷＳＤポートモニターがＥｖｅｎｔデータを受信して記憶しておくことで、各アプリケーションはアプリケーションが望むタイミングでＥｖｅｎｔデータを取得することができる。

（ＰｕｂｌｉｃＥｖｅｎｔデータとＰｒｉｖａｔｅＥｖｅｎｔデータ）
図１０（ａ）は印刷装置２５０が通知するＥｖｅｎｔデータの内容を示している。１０００はＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔ開始要素である。ＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔはＷＳＤ Ｐｒｉｎｔ ＳｅｒｖｉｃｅのＥｖｅｎｔであり、印刷装置の状態に変化があったときに通知されるＥｖｅｎｔデータのひとつである。１００１はＰｒｉｎｔｅｒＣｏｎｆｉｇｒａｔｉｏｎ開始要素である。１００２はＮａｍｅ＝“Ｂｌａｃｋ”属性情報が付されたＣｏｎｓｕｍａｂｌｅＥｍｐｔｙ開始要素である。この「Ｂｌａｃｋ」という属性値は、以降のＸＭＬ情報は黒色インクに関する情報であることを示している。１００３はＣｏｌｏｒ要素に「Ｂｌａｃｋ」というデータが包まれている様子を示している。インク表示アプリ４００は「Ｂｌａｃｋ」データを基に図４で示すインク名称表示部の色名を表示する。１００４はＬｅｖｅｌ要素に「０」というデータが包まれている様子を示している。インク表示アプリ４００は「０」データを基に図４で示すインク残量を模式的に示した残量を表示している。１００５はＭｏｄｅｌ要素に「Ｋｍ−０１」というデータが包まれている様子を示している。インク表示アプリ４００は「Ｋｍ−０１」データを基に図４で示すインク名称表示部のインク型番を表示する。以上図１０（ａ）で示すＰｒｉｎｔｅｒＣｏｎｆｉｇｒａｔｉｏｎ要素１００１は標準的な通知情報（Ｐｕｂｌｉｃ要素）であり、印刷装置２５０とパソコン２００との間でＷＳＤのＳｕｂｓｃｒｉｂｅが行われた全てのパソコン２００に等しく印刷装置２５０は通知を行う。

ここで、図１０（ｂ）を用いて、印刷装置２５０から通知されるＥｖｅｎｔデータの内容を説明する。本実施形態においては、このＥｖｅｎｔデータを受信するＬｉｓｔｅｎｅｒモジュールはＷＳＤポートモニターである。１０１０はＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔ開始要素である。

１０１１はＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ開始要素である。ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ要素を含むＥｖｅｎｔはパソコン２００側からアプリケーションやＯＳによって通知開始要求がなされた場合にのみ通知するＥｖｅｎｔである。

なお、図６（ｂ）で説明したＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ６２０内のＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ６２２の状態から変化が発生した場合、図１０（ｂ）で示すようにＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔ１０１０として、印刷装置２５０はパソコン２００へＥｖｅｎｔ通知を行う。

１０１２はＥｎｔｒｙ開始要素にｎａｍｅ＝“Ｂｌａｃｋ”という属性情報が付されている。この「Ｂｌａｃｋ」という属性値は、以降のＸＭＬ情報は黒色インクに関する情報であることを示している。

１０１３はＩｎｋＳｔａｔｅ要素に「Ｅｍｐｔｙ」というデータが包まれている様子を示す。ＩｎｋＳｔａｔｅの「Ｅｍｐｔｙ」というデータはインクが全く無い旨を示している。

１０１４はＭｅｓｓａｇｅ要素にＣＤＡＴＡで包まれたデータとして「Ｉｎｋ ｉｓ ｅｍｐｔｙ．」データが包まれた様子を示している。

１０１５はＩｃｏｎ要素に「Ｃｒｏｓｓ」というデータが包まれている様子を示している。

１０１６はＳｕｐｐｏｒｔＣｏｄｅ要素に「Ｅ３０００」というデータが包まれている様子を示している。

なお、図１０（ａ）のＰｒｉｎｔｅｒＣｏｎｆｉｇｒａｔｉｏｎ要素１００１は「ｗｓｄｓｔ」接頭辞の示すとおりＰｕｂｌｉｃな情報であり、図１０（ｂ）のＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ要素１０１１は「ｉｈｖ」接頭辞の示すとおりＰｒｉｖａｔｅな情報である。

印刷装置２５０は、ＰｒｉｎｔｅｒＣｏｎｆｉｇｒａｔｉｏｎ要素１００１以降の情報とＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ要素１０１１以降の情報とが同時に遷移した場合、子要素にＰｒｉｎｔｅｒＣｏｎｆｉｇｒａｔｉｏｎ要素１００１とＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ要素１０１１とを含むＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｎｅｔを発行する。

図１０（ｃ）は図１０（ａ）のＰｕｂｌｉｃＥｖｅｎｔデータと図１０（ｂ）のＰｒｉｖａｔｅＥｖｅｎｔデータを一つのイベント内（ＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔ内）の情報に格納した例を示す。

（インク表示アプリの表示更新）
図４（ｄ）は図１０（ｂ）のＥｖｅｎｔ通知を基にインク表示アプリ４００の表示を更新したときの表示状態を示している。図４（ｄ）の４３０のアイコン表示は、１０１５のＩｃｏｎ要素「Ｃｒｏｓｓ」データを基に表示しているが、ここに更新はない。４３０アイコンをユーザーが選択した場合、４３１に示すポップアップ表示にて「Ｉｎｋ ｉｓ ｅｍｐｔｙ．」という更新メッセージをユーザーに伝える。このメッセージは、１０１４のＭｅｓｓａｇｅ要素のデータを基に表示している。４３２の操作説明書起動ボタンをユーザーが選択することで開く解説ページは、「Ｅｍｐｔｙ」というインク状態について解説するページが初期画面として開かれるよう更新される。この「Ｅｍｐｔｙ」インク状態の解説ページを開く動作は、１０１６のＳｕｐｐｏｒｔＣｏｄｅ要素「Ｅ３０００」データを電子的な操作説明書にパラメータとして渡すことで実現する。

以上説明した本実施形態に依れば、印刷装置２５０はＰｕｂｌｉｃ要素のＥｖｅｎｔ通知に限りＳｕｂｓｃｒｉｂｅした全てのパソコン２００へ通知し、Ｐｒｉｖａｔｅ要素のＥｖｅｎｔ通知をパソコン２００内のアプリケーション３０１が要求した期間に限定して通知を行うことが可能となる。Ｐｒｉｖａｔｅ要素に詳細ステータスを定義しておくことで、印刷装置２５０は詳細ステータスの変化時にＰｒｉｖａｔｅ要素のＥｖｅｎｔ通知を要求したパソコン２００へのみＥｖｅｎｔ通知を行えばよい。よって印刷装置２５０のＥｖｅｎｔ通知の負荷を大幅に軽減することが可能となる。本発明は印刷装置２５０が高機能化し、パソコン２００内のアプリケーション３０１がより詳細なステータス情報が必要になるほど、効果を発揮するものである。

＜実施形態２＞
本実施形態では、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔの発行を、インク表示アプリ４００ではなく、ＯＳのＷＳＤポートモニターが発行する形態について説明する。なお、本実施形態はインク表示アプリ４００が、Ｗｉｎｄｏｗｓ８（登録商標）に導入されたＷｉｎｄｏｗｓＳｔｏｒｅＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎ（ＷＳＤＡ）（登録商標）にである場合を想定したものである。ＷＳＤＡでは使用できるＡＰＩがＯＳにより制限される。例えばＷＳＤＡはＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行することができない。ＷＳＤＡのようなＡｐｐｌｉｃａｔｉｏｎであっても本実施形態によれば本発明の効果を得ることが可能となる。

本実施形態のインク表示アプリ４００は、実施形態１で図５のＰｒｉｖａｔｅ要素通知開始要求処理（Ｓ５０３）とその成否判定（Ｓ５０４・Ｓ５０７）とＰｒｉｖａｔｅ要素抽出処理（Ｓ５０８）、Ｐｒｉｖａｔｅ要素通知終了要求（Ｓ５１７）が異なる。

インク表示アプリ４００は、Ｐｒｉｖａｔｅ要素通知開始要求（Ｓ５０３）をＷＳＤポートモニターに対して発行する。本実施形態におけるＰｒｉｖａｔｅ要素通知開始要求処理（Ｓ５０３）は、具体的にはＯＳのＡＰＩを呼び出す処理である。インク表示アプリ４００は、Ｐｒｉｖａｔｅ要素の要素名と、Ｒｅｑｕｉｒｅｍｅｎｔｓオプションを引数として設定し、このＡＰＩを呼び出す。ＩＨＶカスタム要素の要素名は“ｉｈｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ”を設定し、Ｒｅｑｕｉｒｅｍｅｎｔｓオプションには“Ｉｄ：１１１１１１１１”と、“Ｌｉｓｔｅｎｅｒ：ＲｅｑｕｅｓｔｅｒＯｎｌｙ”と、“ｐｅｒｉｏｄ：Ｂｅｇｉｎ”を設定する。このＡＰＩの呼び出しをＯＳが処理し、ＷＳＤポートモニターが図６（ａ）を用いて説明したＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを印刷装置２５０に発行する。インク表示アプリ４００は、Ｓ５０３でＡＰＩを介してＰｒｉｖａｔｅ要素通知要求を行うと、ＡＰＩの戻り値を参照し要求の成否を判定する（Ｓ５０４・Ｓ５０７）。Ｓ５０４とＳ５０７とでは、インク表示アプリ４００は異なるＡＰＩの戻り値を判定する。Ｓ５０４では、インク表示アプリ４００ＷＳＤポートモニターが発行したＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対する印刷装置２５０からの応答が受信できていない場合のエラー情報がＡＰＩの戻り値として得られるかどうかを判定する。Ｓ５０７では、ＷＳＤポートモニターが印刷装置２５０から応答を受信したＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを参照し、登録が成功したかどうかを判定する。Ｓ５０８では、ＡＰＩの戻り値に含まれるＰｒｉｖａｔｅ要素をインク表示アプリ４００は参照してＰｒｉｖａｔｅ要素を抽出する。Ｓ５１７では、Ｐｒｉｖａｔｅ要素通知終了要求をＷＳＤポートモニターに対してＡＰＩを介して発行する。本実施形態におけるＰｒｉｖａｔｅ要素通知終了要求（Ｓ５１７）は、具体的にはＯＳのＡＰＩを呼び出す処理である。インク表示アプリ４００は、Ｐｒｉｖａｔｅ要素の要素名と、Ｒｅｑｕｉｒｅｍｅｎｔｓオプションを引数として設定し、このＡＰＩを呼び出す。Ｐｒｉｖａｔｅ要素の要素名は“ｉｈｖ：ＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ”を設定し、Ｒｅｑｕｉｒｅｍｅｎｔｓオプションには“Ｉｄ：１１１１１１１１”と、“Ｌｉｓｔｅｎｅｒ：ＲｅｑｕｅｓｔｅｒＯｎｌｙ”と、“ｐｅｒｉｏｄ：Ｅｎｄ”を設定する。このＡＰＩの呼び出しをＯＳが処理し、ＷＳＤポートモニターが図６（ｃ）を用いて説明したＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行する。

以上説明した本実施形態に依れば、インク表示アプリ４００はＷＳＤポートモニターを仲介し印刷装置から通知されるＥｖｅｎｔデータの要素データを取得することが可能となる。そのため、パソコン２００内のアプリケーション３０１がＷＳＤＡである場合においても、本発明の効果を得ることが可能となる。

＜実施形態３＞
本実施形態では、インク表示アプリ４００からのＰｒｉｖａｔｅ要素通知要求の際に、Ｐｒｉｖａｔｅ要素通知期間として制限時間による有効期限を設ける構成について説明する。本実施形態は、インク表示アプリ４００が強制的に終了されるような場合を想定している。強制的に終了とは、ＯＳが何らかの異常を検知した場合や、ＯＳが急遽終了してしまうような場合に、アプリケーション３０１は強制的に処理を終了させられることを想定している。強制的に終了されると、インク表示アプリ４００はＰｒｉｖａｔｅ要素通知終了要求（Ｓ５１７）を発行する間もなく処理を強制的に終了させられる。印刷装置２５０は、インク表示アプリ４００からのＰｒｉｖａｔｅ要素通知終了要求（Ｓ５１７）を受信する機会がなく、インク表示アプリ４００が強制終了した後も、パソコン２００へＰｒｉｖａｔｅ要素の通知を続けてしまう課題があった。本実施形態はこの課題を解決するものである。

なお、ＷＳＤＡは処理が一定時間滞るとＯＳが強制的にアプリケーションを終了する。ＷＳＤＡは、ＯＳから強制的に終了されるケースを考慮して設計することが重要となる。

本実施形態のインク表示アプリ４００は、実施形態１で図５のＰｒｉｖａｔｅ要素通知開始要求処理（Ｓ５０３）とステータス要求処理（Ｓ５０９）が異なる。

図１１は本実施形態におけるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔにて発行するＰｒｉｖａｔｅ要素通知開始要求の内容である。本実施形態のＰｒｉｖａｔｅ要素通知開始要求（Ｓ５０３）は、図６（ａ）で説明した実施形態１のＰｒｉｖａｔｅ要素通知開始要求とは、“Ｐｅｒｉｏｄ”属性値が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に包まれたデータの内容が「６００００」（１１０１）である点が異なる。「６００００」というデータの内容は、図１１のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔをプリンタが受信してから、６０秒間Ｐｒｉｖａｔｅ要素を通知せよというＰｒｉｖａｔｅ要素通知の有効期限を示す。本実施形態におけるＰｒｉｖａｔｅ要素通知開始要求処理（Ｓ５０３）では、図１１で示すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを印刷装置２５０に発行する。なお、本実施形態においては、インク表示アプリ４００が発行するＰｒｉｖａｔｅ要素通知の有効期限を６０秒で説明するが、アプリケーション３０１毎に任意に設定される時間であってよい。

図１４を用いて本実施形態における印刷装置２５０内に保存されたＰｒｉｖａｔｅ要素管理テーブルを説明する。図１４（ａ）は図１１で示すＰｒｉｖａｔｅ要素通知開始要求を受信し、印刷装置２５０がＰｒｉｖａｔｅ要素管理テーブルに保存した状態を示す。図８（ａ）で説明したＰｒｉｖａｔｅ要素管理テーブルの状態とは、期間に設定された情報が異なる。１４０１で示すように、Ｐｒｉｖａｔｅ要素管理テーブルには、期間に６００００という値が保存されている。図１４（ｂ）は異なる２つのアプリケーションから有効期限が設定されたＰｒｉｖａｔｅ要素通知要求を保存した状態を示す。１４１０はアプリＩＤ「１１１１１１１１」と「２２２２２２２２」とが保存されている。１４１１はアプリＩＤ「１１１１１１１１」のＰｒｉｖａｔｅ要素通知期間が残り６００００ｍｓｅｃ、アプリＩＤ「２２２２２２２２」のＰｒｉｖｔｅ要素通知期間が残り５００ｍｓｅｃである状態を示している。

図１２のフローチャートを用いて、本実施形態におけるステータス要求処理の処理を説明する。インク表示アプリ４００はこのステータス要求処理を、図５の表示Ｓ５０９とＳ５１１との間で行う。本実施形態におけるステータス要求処理が開始する（Ｓ１２０１）と、インク表示アプリ４００は前回ステータス要求処理を行ってから経過した時間（Ｎ）が、５０秒（Ｍ）より小さいかどうかを比較する（Ｓ１２０２）。Ｓ１２０２でＮ＜Ｍが成立している場合は、インク表示アプリ４００はステータス要求処理（Ｓ１２０３）を行う。ステータス要求処理（Ｓ１２０３）は、実施形態１で図５を用いて説明したステータス要求処理（Ｓ５０９）と同等である。その後、本実施形態におけるインク表示アプリ４００のステータス要求処理は終了する（Ｓ１２０４）。

Ｓ１２０２でＮ＜Ｍが成立していない場合は、インク表示アプリ４００はＰｒｉｖａｔｅ要素通知開始要求を行う（Ｓ１２０５）。Ｐｒｉｖａｔｅ通知開始要求（Ｓ１２０５）の内容は、図１１を用いて説明したＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔと同等である。続いて、インク表示アプリ４００はＰｒｉｖａｔｅ要素の通知登録が成功したかどうかを判定する（Ｓ１２０６）。失敗した場合、インク表示アプリ４００は処理を終了する（Ｓ１２０４）。成功した場合、図６（ｂ）で説明した、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ内のＰｒｉｖａｔｅ要素を抽出する（Ｓ１２０７）。その後、インク表示アプリ４００のステータス要求処理は終了する（Ｓ１２０４）。このように、Ｐｒｉｖａｔｅ要素通知開始要求（Ｓ１２０５）を定期的に行って有効期限を更新することで、インク表示アプリ４００はＰｒｉｖａｔｅ要素の情報を取得し続けることができる。

図１３は、印刷装置２５０のＰｒｉｖａｔｅ要素の有効期限管理処理を示すフローチャートである。有効期限管理処理は、印刷装置２５０の動作中定期的に行われる。本実施形態においては、印刷装置２５０は有効期限管理処理を１０秒毎に開始する。印刷装置２５０は有効期限管理処理を開始する（Ｓ１３０１）と、図１４で示したＰｒｉｖａｔｅ要素管理テーブルを参照してＰｒｉｖａｔｅ要素の通知有効期限を確認する（１３０２）。本実施形態においては、印刷装置２５０は有効期限管理処理を１０秒毎に行うため、Ｐｒｉｖａｔｅ要素管理テーブルの期間に格納されている秒数から１０秒を減算して保存しなおす。続いて、印刷装置２５０は有効期限の切れたＰｒｉｖａｔｅ要素通知登録の有無を判定する（Ｓ１３０３）。有効期限が切れたＰｒｉｖａｔｅ要素通知登録が存在しない場合、印刷装置２５０は有効期限管理処理を終了する（Ｓ１３０４）。有効期限が切れたＰｒｉｖａｔｅ要素通知登録が存在する場合、印刷装置２５０は判断処理（Ｓ１３０５）へ進む。ここで、図１４（ｂ）のアプリＩＤ「２２２２２２２２」の通知残り期間は、１４１１に示す通り５００ｍｓｅｃであるため、１０秒を減算するとゼロ以下になり、有効期限が切れた状態となる。Ｓ１３０５は、印刷装置２５０がＰｒｉｖａｔｅ要素通知先として解除すべきアプリＩＤが、通知先のパソコン２００の中で最後となるアプリＩＤかどうかを判定する判断処理である。ここで、図１４（ｂ）では同一の通知先「情報処理装置ｘｘｘ」に対し、アプリＩＤが２つ格納されているため、Ｓ１３０６において印刷装置２５０は、アプリＩＤを削除する処理を行う（Ｓ１３０６）。Ｓ１３０６で、印刷装置２５０はアプリＩＤ「２２２２２２２２」をＰｉｖａｔｅ要素管理テーブルから削除して有効期限管理処理を終了する（Ｓ１３０４）。Ｓ１３０５において、一つのＰｒｉｖａｔｅ要素の特定の通知先に対し、アプリＩＤが一つのみ登録されている状態だった場合は、印刷装置２５０はＰｒｉｖａｔｅ要素通知先から通知先を削除（Ｓ１３０７）し、有効期限管理処理を終了する（Ｓ１３０４）。

以上説明した本実施形態に依れば、インク表示アプリ４００が急遽強制終了されてＰｒｉｖａｔｅ要素通知終了要求（Ｓ５１７）が発行できなくなる場合であっても、印刷装置２５０はＰｒｉｖａｔｅ要素通知の有効期限が来れば通知を解除することができる。そのため、印刷装置２５０はＰｒｉｖａｔｅ要素をパソコン２００に通知し続けてしまうという課題が解消し、印刷装置２５０のＥｖｅｎｔ通知負荷は大幅に軽減される。

＜実施形態４＞
本実施形態では、Ｐｒｉｖａｔｅ要素通知要求の際に、Ｐｒｉｖａｔｅ要素通知期間としてパソコン２００からの印刷ジョブの処理期間を指定する構成について説明する。

パソコン２００内のアプリケーション３０１の一つとして、印刷ステータス監視アプリケーション（後述する）を例に挙げる。印刷ステータス監視アプリケーション（ステータス監視アプリ）は、パソコン２００内の印刷機能を持ったアプリケーション３０１から依頼された印刷ジョブを印刷装置２５０が処理する進捗状況を表示するアプリケーションである。パソコン２００内の印刷機能を持ったアプリケーション３０１は、プリンタドライバ３０３を介して印刷装置２５０に印刷ジョブを送信する。

ここで、図１５を参照して本実施形態における印刷フローを概念的に表した印刷システムの構成を説明する。アプリケーション１５０１（アプリケーション群３０１に含まれる１つのアプリケーション）は、ＯＳの提供する印刷指示を行うＡＰＩを利用し、ＯＳへ印刷処理の要求を行う。印刷処理の要求はＯＳ内のスプーラ１５１１にて処理される。スプーラ１５１１はアプリケーション１５０１からの印刷要求を受け、プリントキュー１５１２に印刷ジョブ１５１３として格納する。スプーラ１５１１はパソコン２００内の複数のアプリケーション１５０１からの複数の印刷ジョブ１５１３をプリントキュー１５１２に複数格納する。スプーラ１５１１はプリントキュー１５１２に格納した印刷ジョブ１５１３を順次プリンタドライバ１５２１（３０３）へ送信する。プリンタドライバ１５２１は、印刷ジョブ１５１３を受信すると、ページ構成モジュール１５２２にてページ構成処理を行う。ページ構成処理とは、アプリケーション１５０１から指示された印刷設定情報が印刷ジョブ１５１３に付加されており、印刷設定情報に基づいて一つの印刷ジョブ１５１３内のページの順序を並べ替える処理や、複数ページを１ページに構成する処理を指す。ページ構成モジュール１５２２によるページ構成処理が終了すると、プリンタドライバ１５２１はコマンド生成モジュール１５２３で印刷ジョブ１５１３を印刷データ形式へ変換する処理を行う。印刷データ形式とは印刷装置２５０が解釈可能なデータである。コマンド生成モジュール１５２３によって印刷ジョブ１５１３を印刷データ形式に変換する処理が完了すると、プリンタドライバ１５２１は印刷装置２５０へ印刷ジョブ１５１３を送信する。印刷装置２５０は印刷ジョブ１５１３に基づいて用紙などの記録媒体にインクなどの記録材料を用いて印刷を行う。ここで、プリンタドライバ１５２１は、印刷装置２５０へＰｒｉｖａｔｅ要素通知要求を行う。本実施形態におけるＰｒｉｖａｔｅ要素通知要求は、印刷進捗の詳細を示す情報である。

図１６（ａ）は、プリンタドライバ１５２１がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを用いて発行するＰｒｉｖａｔｅ要素通知開始要求の内容である。１６０１はＮａｍｅ要素に「ｉｈｖ：ＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ」というデータが包まれている様子を示している。「ｉｈｖ：ＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ」データを印刷装置２５０に通知することで、印刷装置２５０は「ｉｈｖ：ＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ」という情報を要求元に応答する処理（後述する）を行う。１６０２はｐａｒａｍ＝“Ｉｄ”という属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に「３３３３３３３３」というデータ（識別子）が包まれている様子を示している。本実施形態においては、「３３３３３３３３」という識別子は、プリンタドライバ１５２１を示す識別子である。「Ｉｄ」属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素にて「３３３３３３３３」というデータを通知することで、印刷装置２５０は「ｉｈｖ：ＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ」という情報の通知に関する要求元のアプリケーションを識別する情報として用いる（後述する）。１６０３はｐａｒａｍ＝“Ｌｉｓｔｅｎｅｒ”という属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に「Ｒｅｑｕｅｓｔｅｒ Ｏｎｌｙ」というデータが包まれている様子を示している。「Ｌｉｓｔｅｎｅｒ」属性が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素にて「Ｒｅｑｕｅｓｔｅｒ Ｏｎｌｙ」というデータを通知することで、印刷装置２５０は「ｉｈｖ：ＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ」という情報はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔの要求元のパソコン２００へのみＥｖｅｎｔ通知することを記憶する（後述する）。１６０４はｐａｒａｍ＝“ｐｅｒｉｏｄ”という属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に「Ｐｒｉｎｔｉｎｇ」というデータが包まれている様子を示している。「ｐｅｒｉｏｄ」属性が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素にて「Ｐｒｉｎｔｉｎｇ」というデータを通知することで、印刷装置２５０は印刷ジョブの処理中のみ「ｉｈｖ：ＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ」という情報は、要求元のパソコン２００にＥｖｅｎｔ通知することを記憶する（後述する）。本実施形態では、図１６（ａ）のＰｒｉｖａｔｅ要素通知開始要求を、印刷装置２５０からのＥｖｅｎｔデータにＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素が含まれていないことを認識したプリンタドライバ１５２１が発行する構成で説明する。しかし、図１６（ａ）のＰｒｉｖａｔｅ要素通知開始要求の発行は、ステータス監視アプリが行う構成であってもよいし、その他のＯＳ内のアプリケーション１５０１が行う構成であってもよい。

図１６（ａ）のＰｒｉｖａｔｅ要素通知開始要求を受信した印刷装置２５０が各種要求情報を登録する処理は、図７を用いて説明したＰｒｉｖａｔｅ要素登録処理と同等である。本実施形態のＰｒｉｖａｔｅ要素通知は印刷中に限定されているため、Ｐｒｉｖａｔｅ要素通知解除を行わなくても印刷装置２５０の負荷はない。そのため、本実施形態におけるＰｒｉｖａｔｅ要素の通知を解除する要求はプリンタドライバ１５３１からは行わず、ＵｎｓｕｂｓｃｒｉｂｅにてＥｖｅｎｔ通知解除とともにＰｒｉｖａｔｅ要素通知解除がなされる構成である。しかし、パソコン２００内のアプリケーション１５０１やプリンタドライバ１５２１が図６（ｃ）を用いて説明したＰｒｉｖａｔｅ要素通知終了要求を行う構成でもよい。Ｐｒｉｖａｔｅ要素通知要求を受けた印刷装置２５０がＰｒｉｖａｔｅ要素通知を登録解除する処理は図７を用いて説明した通りである。

図１６（ｂ）を参照して、Ｐｒｉｖａｔｅ要素通知開始要求の応答情報であるＧｅｔＰｉｒｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅの内容について説明する。１６１１はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ開始要素である。１６１２はＥｌｅｍｅｎｔＤａｔａ開始要素であり、Ｎａｍｅ属性の属性値に以降のＸＭＬ情報は「ｉｈｖ：ＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ」の応答情報である旨が示され、この応答情報が有効である旨がＶａｌｉｄ属性の「ｔｕｒｅ」属性値にて示されている。１６１３はＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ開始要素である。１６１４はＪｏｂＳｔａｔｅ開始要素である。１６１５はＪｏｂＳｔａｔｕｓ要素に「Ｒｅｃｅｉｖｉｎｇ」というデータが包まれている様子を示している。１６１６はＳｕｐｐｏｒｔＣｏｄｅ要素に「Ｎｏｎｅ」というデータが包まれている様子を示している。１６１７はＭｅｓｓａｇｅ要素にＣＤＡＴＡで包まれたデータとして「Ｐｒｉｎｔｅｒ ｈａｓ ｒｅｃｅｉｖｅｄ ｙｏｕｒ ｐｒｉｎｔ ｊｏｂ．」データが包まれた様子を示している。１６１８はＪｏｂＮａｍｅ要素にＣＤＡＴＡで包まれたデータとして「Ｒｅｐｏｒｔ．ｔｘｔ」データが包まれている様子を示している。１６１９はＰｒｏｇｒｅｓｓ開始要素である。１６２０はＴｏｔａｌＰａｇｅｓ要素に「５」というデータが包まれている様子を示している。１６２１はＰｒｉｎｔｅｄＰａｇｅｓ要素に「０」というデータが包まれている様子を示している。１６２２はＰａｇｅＳｔａｔｅ要素に「Ｒｅｃｅｉｖｉｎｇ」というデータが包まれている様子を示している。この応答情報は、図９を用いて説明した通り、記憶領域Ｓ９９０に記憶される。

図１７はステータス監視アプリを示す図である。図１７（ａ）はステータス監視アプリの初期状態、及び、印刷装置２５０が印刷処理を行っていない場合のステータス状態を示している。１７００は、ステータス監視アプリである。１７０１は印刷ステータスの監視対象となる印刷装置２５０の名称を表示している。１７０２はステータス表示領域であり、印刷装置２５０は印刷処理を行っていない旨を表示している。１７０３は終了ボタンであり、ステータス監視アプリ１７００はユーザーにより終了ボタン１７０３が選択されると、処理を終了する。１７０４は印刷ジョブの名前を表示する領域である。１７０５は印刷ジョブの進捗状況を表示する領域である。

図１７（ｂ）は、図１６（ｂ）のＰｒｉｖａｔｅ要素通知開始要求の応答情報のＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素内の情報に基づいて印刷状況を表示した状態を示している。１７１１はＭｅｓｓａｇｅ要素１６１７のデータ「Ｐｒｉｎｔｅｒ ｈａｓ ｒｅｃｅｉｖｅｄ ｙｏｕｒ ｐｒｉｎｔ ｊｏｂ．」をステータス表示領域に表示した様子を示している。１７１２はＪｏｂＮａｍｅ要素１６１８のデータ「Ｒｅｐｏｒｔ．ｔｘｔ」を表示している。１７１３はＴｏｔａｌＰａｇｅｓ要素１６２０のデータ「５」と、ＰｒｉｎｔｅｄＰａｇｅｓ要素１６２１のデータ「０」とに基づいて、印刷の進捗状況「０／５」を表示している。１７１４はプログレスバーであり、印刷の進捗状況を模式的に示す。印刷装置２５０は印刷ジョブの受信中であり、印刷処理は全く処理を行っていない状態として、プログレスバー１７１４は全く進んでいない。

図１８のフローチャートを用いて、印刷装置２５０のＥｖｅｎｔ通知判定処理を説明する。印刷装置２５０はＥｖｅｎｔ通知判定処理を開始する（Ｓ１８０１）と印刷装置２５０内のステータス遷移の有無を確認する（Ｓ１８０２）。Ｓ１８０３にて、印刷装置２５０はステータス遷移の有無を判定し、ステータス遷移は無いと判定した場合はＥｖｅｎｔ通知判定処理を終了する（Ｓ１８０４）。Ｓ１８０４にて、ステータス遷移が有ったと判定した場合、印刷装置２５０は遷移の有ったスタータスはＰｕｂｌｉｃ要素に関する遷移かどうかを判定する（Ｓ１８０５）。Ｐｕｂｌｉｃ要素に遷移があった場合、印刷装置２５０はＰｕｂｌｉｃＥｖｅｎｔデータを生成し、ＰｕｂｌｉｃＥｖｅｎｔデータを記憶領域１８５０に格納する（Ｓ１８０６）。Ｓ１８０５にてＰｕｂｌｉｃ要素に遷移がなかったと判定した場合は、Ｓ１８０６を行わずにＳ１８０７に進む。印刷装置２５０はＰｒｉｖａｔｅ要素に関するステータス遷移の有無を判定する（Ｓ１８０７）。Ｓ１８０７にて、Ｐｒｉｖａｔｅ要素に遷移があった場合、印刷装置２５０はＰｒｉｖａｔｅ要素管理テーブル（図８と図１４と後に説明する図１９を指す）を確認する（Ｓ１８０８）。Ｐｒｉｖａｔｅ要素管理テーブルを確認し、遷移のあったＰｒｉｖａｔｅ要素の通知を要求されているかを判定する（Ｓ１８０９）。Ｓ１８０９にて、いずれのパソコン２００（Ｐｒｉｖａｔｅ要素管理テーブル上の「通知先」）も遷移の有ったＰｒｉｖａｔｅ要素の通知を要求していないと判定した場合、印刷装置２５０はＥｖｅｎｔ通知処理（Ｓ１８１０）に進む。Ｅｖｅｎｔ通知Ｓ１８１０では、印刷装置２５０は記憶領域１８５０から格納したＥｖｅｎｔデータを読み出してＳｕｂｓｃｒｉｂｅしたパソコン２００にＥｖｅｎｔ通知を行う。その後、印刷装置２５０はＥｖｅｎｔ通知判定処理を終了する（Ｓ１８０４）。Ｓ１８０９にて、Ｐｒｉｖａｔｅ要素の通知を要求があると判断した場合、印刷装置２５０は遷移のあったＰｒｉｖａｔｅ要素の通知は通知要求を行ったパソコン２００の印刷ジョブを処理している期間に限定されているかを判定する（Ｓ１８１１）。

ここで、図１９（ａ）を用いて、通知期間として「Ｐｒｉｎｔｉｎｇ」が設定されている状態のＰｒｉｖａｔｅ要素管理テーブルを説明する。１９０１はＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ要素の通知を、通知先のパソコン２００として情報処理装置ｘｘｘ、６００００ｍｓｅｃの間のみという通知期間、要求アプリＩＤ「１１１１１１１１」が登録されている状態を示す。また、１９０２はＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ要素の通知を、通知先のパソコン２００として情報処理装置ｘｘｘ、５００ｍｓｅｃの間のみという通知期間、要求アプリＩＤ「２２２２２２２２」が登録されている状態を示す。１９０１と１９０２の示すＰｒｉｖａｔｅ要素管理テーブルの登録状態は図１４（ｂ）と同等である。１９０３はＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素の通知を、通知先のパソコン２００として情報処理装置ｘｘｘ、「Ｐｒｉｎｔｉｎｇ」という通知期間、要求アプリＩＤ「３３３３３３３３」が登録されている状態を示す。１９０３は、情報処理装置ｘｘｘ内のプリンタドライバ１５２１がアプリＩＤ「３３３３３３３３」を設定してＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素の通知要求を行った状態である。１９０４はＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素の通知を、通知先のパソコン２００として情報処理装置ｙｙｙ、「Ｐｒｉｎｔｉｎｇ」という通知期間、要求アプリＩＤ「４４４４４４４４」が登録されている状態を示す。１９０４は、情報処理装置ｙｙｙ内のプリンタドライバ１５２１がアプリＩＤ「４４４４４４４４」を設定してＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素の通知要求を行った状態である。なお、情報処理装置ｘｘｘはＩｎｋＥｒｒｏｒＤｅｔａｉｌｓとＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓの通知要求を行っているため、印刷装置２５０は情報処理装置ｘｘｘへＩｎｋＥｒｒｏｒＤｅｔａｉｌｓとＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓとを含んだＥｖｅｎｔ通知に含める。

Ｓ１８１１にて、遷移のあったＰｒｉｖａｔｅ要素はＩｎｋＥｒｒｏｒＤｅｔａｉｌｓ要素だった場合、通知期間は「Ｐｒｉｎｔｉｎｇ」という条件ではないため、印刷装置２５０はＰｒｉｖａｔｅＥｖｅｎｔデータ生成Ｓ１８１２に進む。一方、Ｓ１８１１にて、遷移のあったＰｒｉｖａｔｅ要素はＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素だった場合、通知期間は「Ｐｒｉｎｔｉｎｇ」という条件であるため、印刷装置２５０は印刷ジョブの送信元判定処理（Ｓ１８１３）に進む。印刷ジョブの送信元判定処理（Ｓ１８１３）では、印刷装置２５０が印刷処理を行っている印刷ジョブの送信元であるパソコン２００がＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素の通知を要求しているかどうかを判断する。Ｓ１８１３にて、図１９（ａ）のＰｒｉｖａｔｅ要素管理テーブルにおける情報処理装置ｘｘｘ又は情報処理装置ｙｙｙから送信された印刷ジョブを処理中であった場合は、印刷装置２５０はＰｒｉｖａｔｅＥｖｅｎｔデータ生成Ｓ１８１２へ進む。一方、Ｓ１８１３にて、情報処理装置ｘｘｘ又は情報処理装置ｙｙｙ以外のパソコン２００から送信された印刷ジョブだった場合は、印刷装置２５０はＳ１８１２を行わず、Ｅｖｅｎｔ通知処理（Ｓ１８１０）へ進む。さらに、Ｓ１８１３にて、印刷ジョブを処理していない場合、印刷装置２５０はＳ１８１２を行わずＥｖｅｎｔ通知処理（Ｓ１８１０）し、Ｅｖｅｎｔ通知判定処理を終了する（Ｓ１８０４）。Ｅｖｅｎｔ通知処理の詳細は図２０を用いて後に説明する。

Ｓ１８１２では、ＰｒｉｖａｔｅＥｖｅｎｔデータを生成し、ＰｒｉｖａｔｅＥｖｅｎｔデータを記憶領域１８５０に格納する（Ｓ１８１２）。

なお、ＰｕｂｌｉｃＥｖｅｎｔデータが既に記憶領域１８５０に存在していた場合、ＰｕｂｌｉｃＥｖｅｎｔデータを複製し、複製したＰｕｂｌｉｃＥｖｅｎｔデータにＰｒｉｖａｔｅＥｖｅｎｔデータをマージ（ｍｅｒｇｅ）してもよい。

判断１８０７にて、Ｐｒｉｖａｔｅ要素に遷移がなかった場合、印刷装置２５０はＰｕｂｌｉｃ要素の遷移の有無を再度確認（Ｓ１８１４）し、Ｐｕｂｌｉｃ要素に遷移があった場合はＥｖｅｎｔ通知処理（Ｓ１８１０）へ進む。判断１８１４にて、Ｐｕｂｌｉｃ要素に遷移がなかった場合、印刷装置２５０はＥｖｅｎｔ通知判定処理を終了する（Ｓ１８０４）。なお、印刷装置２５０はＥｖｅｎｔ通知Ｓ１８１０を行った後、Ｅｖｅｎｔ通知判定処理を終了する（Ｓ１８０４）前に、記憶領域１８５０内の既に通知したＥｖｅｎｔデータを削除する。

ここで、図２０のフローチャートを用いて、本実施形態におけるＥｖｅｎｔ通知Ｓ１８１０の詳細処理を説明する。

なお、図２０の処理は一律一定時間間隔で実行しても構わない。あるいは印刷装置２５０の印刷中は一定の時間間隔で実行して、印刷装置２５０のアイドル中はエラーが発生したとき又は印刷装置２５０のアイドル中は時間間隔を印刷中の時間時間よりも伸ばしても構わない。

印刷装置２５０はＥｖｅｎｔ通知処理を開始する（Ｓ２００１）と、記憶領域Ｓ２０５０（Ｓ１８５０）からＥｖｅｎｔデータを読み出す（Ｓ２００２）。印刷装置２５０は、読み出したＥｖｅｎｔデータを確認し、Ｐｒｉｖａｔｅ要素のみのＥｖｅｎｔデータであるかを判定する（Ｓ２００３）。判断２００３にて、Ｅｖｅｎｔデータが記憶領域Ｓ２０５０に格納されていなかった場合、印刷装置２５０はＥｖｅｎｔ通知処理を終了する（Ｓ２００５）。Ｓ２００３にて、Ｐｒｉｖａｔｅ要素のみのＥｖｅｎｔデータのみが格納されていたと判断した場合、印刷装置２５０はＰｒｉｖａｔｅ要素の通知を要求しているパソコン２００へのみＥｖｅｎｔデータを通知し（Ｓ２００４）、Ｅｖｅｎｔ通知処理を終了する（Ｓ２００５）。Ｓ２００３にて、Ｐｕｂｌｉｃ要素Ｅｖｅｎｔも記憶領域Ｓ２０５０に格納されていたと判断した場合、ＥｖｅｎｔデータにＰｒｉｖａｔｅＥｖｅｎｔデータの有無を判定する（Ｓ２００６）。Ｓ２００６にて、ＰｒｉｖａｔｅＥｖｅｎｔデータが存在しないと判断した場合、印刷装置２５０はＳｕｂｓｃｒｉｂｅした全てのパソコン２００へＥｖｅｎｔデータを通知し（Ｓ２００７）、Ｅｖｅｎｔ通知処理を終了する（Ｓ２００５）。Ｓ２００６にて、ＰｒｉｖａｔｅＥｖｅｎｔデータとＰｕｂｌｉｃＥｖｅｎｔデータとが格納されていた場合は、Ｐｒｉｖａｔｅ要素の通知要求を行ったパソコン２００へはＰｕｂｌｉｃＥｖｅｎｔデータとＰｒｉｖａｔｅＥｖｅｎｔデータを通知する（Ｓ２００８）。

なお、Ｓ１８１２でＰｕｂｌｉｃＥｖｅｎｔデータにＰｒｉｖａｔｅＥｖｅｎｔデータをマージ（ｍｅｒｇｅ）した場合はＳ２００８でマージされたデータを通知してもよい。

続いて、印刷装置２５０は、Ｓｕｂｓｃｒｉｂｅした全てのパソコン２００のうち、Ｐｒｉｖａｔｅ要素の通知要求の行っていないパソコン２００へＰｕｂｌｉｃ要素のみで構成されるＥｖｅｎｔデータを通知する（Ｓ２００９）。その後、印刷装置２５０はＥｖｅｎｔ通知処理を終了する（Ｓ２００５）。このように、印刷装置２５０は、Ｐｒｉｖａｔｅ要素に関連するステータスに遷移があった場合、Ｐｒｉｖａｔｅ要素の通知を要求したパソコン２００にＰｒｉｖａｔｅ要素を含むＥｖｅｎｔ通知を行うことができる。

なお、Ｓ２００８にてＥｖｅｎｔデータを通知するかどうかは、通知要求を行ったパソコン２００であっても、Ｐｒｉｖａｔｅ要素管理テーブル（図８、図１４、図１９）の登録情報を参照して決定する。本実施形態では、Ｐｒｉｖａｔｅ要素を「Ｐｒｉｎｔｉｎｇ」期間のみ通知するよう要求されている。つまり、要求元のパソコン２００からの印刷ジョブの処理中ではない場合、印刷装置２５０はそのパソコン２００へＰｒｉｖａｔｅ要素を含まないＥｖｅｎｔデータを通知する。

図１０（ｄ）を用いてＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素に遷移があった場合に印刷装置２５０が通知するＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔデータの内容を説明する。１０２１はＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＣｈａｎｇｅＥｖｅｎｔ開始要素である。１０２２はＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ開始要素である。１０２３はＪｏｂＳｔａｔｅ要素に「Ｐｒｏｃｅｓｓｉｎｇ」データが包まれた要素を示す。「Ｐｒｏｃｅｓｓｉｎｇ」というデータにより、印刷装置２５０は印刷ジョブ１５１３の処理中であることが分かる。１０２４はＭｅｓｓａｇｅ要素にＣＤＡＴＡに包まれたデータとして「Ｐｒｉｎｔｉｎｇ．」データが包まれた様子を示している。１０２５はＰｒｉｎｔｅｄＰａｇｅｓ要素に「２」というデータが包まれている様子を示す。ＰｒｉｎｔｅｄＰａｇｅｓ要素１０２５のデータは、印刷装置２５０が既に印刷したページ数を示している。１０２６はＰａｇｅＳｔａｔｅ要素に「Ｅｊｅｃｔｉｎｇ」というデータが包まれている様子を示す。「Ｅｊｅｃｔｉｎｇ」というデータにより、印刷装置２５０は記録媒体を排出している最中であることが分かる。

図１７（ｃ）は、図１０（ｄ）のＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素の情報に基づいて印刷状況を表示した状態を示している。１７２１はＭｅｓｓａｇｅ要素１０２４のデータ「Ｐｒｉｎｔｉｎｇ」をステータス表示領域に表示した様子を示している。１７２２はＰｒｉｎｔｅｄＰａｇｅｓ要素１０２５のデータ「２」に基づいて、印刷の進捗状況を「３／５」と表示している。１７２３はプログレスバーであり、１０２５のデータ「２」という印刷の進捗状況から全体の２／５だけバーを進め、さらにＰａｇｅＳｔａｔｅ要素１０２６のデータ「Ｅｊｅｃｔｉｎｇ」に基づいて全体の２／１５だけ追加でバーを進めた状態を示している。本実施形態におけるプログレスバーの１ページ分の分割量は３を想定しており、内訳は記録媒体を給紙中である「Ｌｏａｄｉｎｇ」と、印刷処理中である「Ｐｒｉｎｔｉｎｇ」と、記録媒体を排紙中である「Ｅｊｅｃｔｉｎｇ」で構成される。

以上説明した本実施形態に依れば、パソコン２００から印刷ジョブ１５１３が送信されると、印刷装置２５０はＰｒｉｖａｔｅ要素を印刷ジョブ１５１３の処理中のみパソコン２００に通知する。また、印刷装置２５０はＰｒｉｖａｔｅ要素を他のパソコンには通知しない。これによって印刷装置２５０のＥｖｅｎｔ通知の負荷を大幅に軽減することが可能となる。

＜実施形態５＞
本実施形態では、印刷装置２５０が任意の期間に発生したＰｒｉｖａｔｅ要素の遷移をまとめて通知する構成について説明する。本実施形態は印刷装置２５０のステータス遷移が頻繁に発生するＰｒｉｖａｔｅ要素の通知処理をさらに軽減することを目的としている。例えば印刷速度の速い印刷装置２５０においては、図１６（ｃ）のＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素１０２２のＰａｇｅＳｔａｔｅ要素１０２６のデータの遷移が頻繁に遷移する。ＰａｇｅＳｔａｔｅ要素１０２６のデータとして、「Ｌｏａｄｉｎｇ」「Ｐｒｉｎｔｉｎｇ」「Ｅｊｅｃｔｉｎｇ」という３つのページの処理状態が定義されている場合、短い時間間隔でＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素１０２２を含むＥｖｅｎｔを通知しなくてはならないため印刷装置２５０のＥｖｅｎｔ通知負荷は大きい。そのため、印刷装置２５０で頻繁なＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素１０２２のデータ遷移があった場合は、印刷装置２５０が勝手にＥｖｅｎｔデータを集約する手法が考えられる。しかし、パソコン２００の役割によっては、そのＥｖｅｎｔデータの頻繁な遷移情報をも必要とする場合がある。そのため、印刷装置２５０で勝手にＥｖｅｎｔデータを集約する判断はできない。本実施形態はこの課題を解決するものである。

図１６（ｃ）は、ステータス監視アプリ１７００がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを用いて発行するＰｒｉｖａｔｅ要素通知開始要求の内容である。実施形態４ではＰｒｉｖａｔｅ要素通知開始要求をプリンタドライバ１５２１が行う構成で説明したが、本実施例においてはＰｒｉｖａｔｅ要素通知開始要求をステータス監視アプリ１７００が行う構成で説明する。ステータス監視アプリ１７００は、起動処理を行うとともに図１６（ｃ）に示すＰｒｉｖａｔｅ要素通知開始要求を行う。１６３１はＮａｍｅ要素に「ＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ」データが格納されている様子を示す。１６３２はｐａｒａｍ＝“Ｉｄ”という属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に「４４４４４４４４」というデータ（識別子）が包まれている様子を示している。本実施形態においては、「４４４４４４４４」という識別子は、ステータス監視アプリ１７００を示す識別子である。１６３３はｐａｒａｍ＝“ｄｅｌａｙ”という属性情報が付されたＲｅｑｕｉｒｅｍｅｎｔｓ要素に「３０００」というデータが包まれている様子を示している。「ｄｅｌａｙ」属性が付されたＲｅｑｕｉｒｅｍｅｎｔ要素にて「３０００」というデータを通知することで、印刷装置２５０はＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素１６３１のＥｖｅｎｔ通知は３０００ｍｓｅｃの期間集約して通知してよいという集約許可情報を記憶する。

図１９（ｂ）は、図１６（ｃ）のＰｒｉｖａｔｅ要素通知要求を受信した印刷装置２５０が登録したＰｒｉｖａｔｅ要素管理テーブルである。１９１１はＰｒｉｎｔＰｒｏｇｒｅｓｓＤｅｔａｉｌｓ要素の通知を、通知先のパソコン２００として情報処理装置ｙｙｙ、「Ｐｒｉｎｔｉｎｇ」という通知期間、要求アプリＩＤ「４４４４４４４４」が登録されている状態を示す。さらに、１９１１には集約許可情報として「３０００」が登録されている。

図１は印刷装置２５０のＥｖｅｎｔ通知集約判定処理と、集約Ｐｒｉｖａｔｅ要素通知タイマー処理である。先ず、Ｅｖｅｎｔ通知集約判定処理について説明する。Ｅｖｅｎｔ通知集約判定処理は、図１８のＳ１８１２の前に行う処理である。Ｅｖｅｎｔ通知集約Ｓ２００１を開始すると、印刷装置２５０は遷移のあったＰｒｉｖａｔｅ要素が集約許可を受けているかどうかを図１９（ｂ）に示すＰｒｉｖａｔｅ要素管理テーブルを参照して判定する（Ｓ２１０２）。Ｓ２１０２にて、集約許可を受けていないと判定した場合、印刷装置２５０はＥｖｅｎｔ通知集約判定処理を終了する（Ｓ２１０３）。Ｓ２１０２にて、集約許可を受けていると判定した場合、印刷装置２５０は集約許可を受けたＰｒｉｖａｔｅＥｖｅｎｔデータを記憶領域Ｓ２１５０（Ｓ１８５０、Ｓ２０５０）に格納する（Ｓ２１０４）。もし、既に同一のＰｒｉｖａｔｅＥｖｅｎｔデータが存在していた場合はＳ２１０４にて、印刷装置２５０は既存のＰｒｉｖａｔｅ要素にデータをマージ（ｍｅｒｇｅ）する（Ｓ２１０４）。その後、印刷装置２５０は、集約Ｐｒｉｖａｔｅ要素通知タイマー処理が開始しているかどうかを判定する（Ｓ２１０５）。Ｓ２１０５にて、既に集約Ｐｒｉｖａｔｅ要素通知タイマー処理が開始していると判断した場合、印刷装置２５０はＥｖｅｎｔ通知集約判定処理を終了する（Ｓ２１０３）。Ｓ２１０５にて、集約Ｐｒｉｖａｔｅ要素通知タイマーが起動していないと判断した場合、印刷装置２５０は集約Ｐｒｉｖａｔｅ要素通知タイマーを起動し（Ｓ２１０６）、Ｅｖｅｎｔ通知集約判定処理を終了する（Ｓ２１０３）。

ここで、Ｓ２１０４において、集約許可を受けたＰｒｉｖａｔｅ要素は既に記憶領域Ｓ２１５０へ格納したため、Ｓ１８１２ではこのＰｒｉｖａｔｅ要素の格納は行わない。また、Ｓ１８１０では、印刷装置２５０は集約許可を受けたＰｒｉｖａｔｅ要素のみを含むＥｖｅｎｔデータのＥｖｅｎｔ通知は行わず、後述のＳ２１２４にて通知する。ただし、印刷装置２５０は、集約許可を受けたＰｒｉｖａｔｅ要素であっても、その他のＰｒｉｖａｔｅ要素やＰｕｂｌｉｃ要素を含んでいるＥｖｅｎｔデータは通知を行う。

Ｓ２１０５にて、集約Ｐｒｉｖａｔｅ要素通知タイマー処理が起動していない場合、印刷装置２５０は集約Ｐｒｉｖａｔｅ要素通知タイマー処理を開始し、Ｅｖｅｎｔ通知集約判定処理を終了する（Ｓ２１０３）。

次に、集約Ｐｒｉｖａｔｅ要素通知タイマー処理について説明する。印刷装置２５０は集約Ｐｒｉｖａｔｅ要素通知タイマー処理を開始する（Ｓ２１２１）と、図１９（ｂ）に示すＰｒｉｖａｔｅ要素管理テーブルを確認する（Ｓ２１２２）。印刷装置２５０は、集約Ｐｒｉｖａｔｅ要素の集約期限は３０００ｍｓｅｃであることを認識する。続いて、印刷装置２５０は集約期限が経過するまで集約期限経過判定処理（Ｓ２１２３）を繰り返す。Ｓ２１２３にて、集約期限が経過したと判断した場合、印刷装置２５０は集約したＰｒｉｖａｔｅＥｖｅｎｔデータを記憶領域Ｓ２１５０から読み出し、通知要求のあったパソコン２００へ集約したＰｒｉｖａｔｅＥｖｅｎｔデータを通知する（Ｓ２１２４）。その後、印刷装置２５０は集約Ｅｖｅｎｔ要素通知タイマー処理を終了する（Ｓ２１２５）。もし、Ｓ２１２４にて既に記憶領域Ｓ２１５０に集約Ｐｒｉｖａｔｅ要素が存在していなかった場合、印刷装置２５０はＳ２１２４ではＥｖｅｎｔデータの通知処理を行わず、集約Ｅｖｅｎｔ要素通知タイマー処理を終了する（Ｓ２１２５）。

以上説明した本実施形態に依れば、パソコン２００からＰｒｉｖａｔｅ要素の集約許可を印刷装置２５０に伝えることで、印刷装置２５０は頻繁なステータス遷移が発生しても即座にＥｖｅｎｔ通知を行う必要がなくなる。そのため、印刷装置２５０のＥｖｅｎｔ通知負荷は大幅に軽減することが可能となる。逆に、頻繁なステータス遷移を取得したいパソコン２００ではＰｒｉｖａｔｅ要素の集約許可を印刷装置２５０に伝えないことで、頻繁なステータス遷移を監視したいパソコン２００では適切にＰｒｉｖａｔｅ要素の情報を得ることができる。

＜実施形態６＞
なお、実施形態１〜５ではインクエラー及びプリントプログレスを例にＥｖｅｎｔデータの説明を行った。

この他にＥｖｅｎｔデータに含める情報の例としては用紙がないことを示す情報及び用紙がない給紙段（カセット）を示す情報、用紙のボリュームを示す情報、ジョブのバッファー量、ジョブのキューの情報が挙げられる。

あるいはＥｖｅｎｔデータとしてメディアの情報を含め、ＰｕｂｌｉｃＥｖｅｎｔデータにメディアの種類の情報を、ＰｒｉｖａｔｅＥｖｅｎｔデータにメディアの型番の情報を含める構成としてもよい。

さらに、実施形態１〜５では、Ｐｒｉｖａｔｅ要素通知及び終了の要求手段として、パソコンからＷＳＤのＷＳＤ Ｐｒｉｎｔ ＳｅｒｖｉｃｅのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを用いる形態で説明したが、ＷＳＤ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅを用いずにＩＨＶ Ｎａｔｉｖｅ Ｐｒｏｔｏｃｏｌを用いることで実現してもよい。

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

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

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

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

以上説明した実施形態１から６に依れば、Ｅｖｅｎｔ通知登録を行っているパソコン２００であっても、Ｐｒｉｖａｔｅ要素を通知する期間と通知先のパソコン２００を限定することができるため、印刷装置２５０（１５３１）のＥｖｅｎｔ通知負荷を大幅に軽減することが可能となる。

Claims (13)

1. デバイスであって、
   前記デバイスの第１の情報を第１の情報処理装置と第２の情報処理装置に通知する登録の要求を前記第１の情報処理装置と前記第２の情報処理装置から受付ける登録手段と、
   前記デバイスの第２の情報を前記第１の情報処理装置に通知する登録の要求を前記第１の情報処理装置から受付ける受付手段と、
   前記登録手段が前記要求を前記第１の情報処理装置と前記第２の情報処理装置から受け付けた後に前記デバイスの状態が変化した場合に、前記受付手段が要求を受け付けた前記第１の情報処理装置には前記第１の情報と前記第２の情報を通知して、前記第２の情報処理装置には前記第２の情報を通知せずに前記第１の情報を通知する通知手段と、を有し、
   前記受付手段は、前記デバイスの第１の情報が記載されたイベント内の情報である前記デバイスの第２の情報を前記第１の情報処理装置に特定の期間通知する登録の要求を前記第１の情報処理装置から受付けると、前記通知手段は、前記第１の情報処理装置に前記第２の情報を前記特定の期間通知し、
   前記特定の期間は前記第１の情報処理装置が送信した印刷ジョブの処理期間であることを特徴とするデバイス。
2. 前記受付手段が前記第２の情報を前記第１の情報処理装置に通知する登録の要求を前記第１の情報処理装置から受付けた後に、前記受付手段が前記第２の情報を前記第１の情報処理装置に通知する登録を解除する要求を受け付けた場合、前記通知手段は前記第２の情報を前記第１の情報処理装置に通知しないことを特徴とする請求項１に記載のデバイス。
3. 前記受付手段が前記第２の情報を前記第１の情報処理装置に通知する登録の要求を前記第１の情報処理装置から受付けた後に、前記受付手段が前記第２の情報を前記第１の情報処理装置のアプリケーションに通知する登録を解除する要求を前記第１の情報処理装置の全てのアプリケーションから受け付けた場合、前記通知手段は前記第２の情報を前記第１の情報処理装置に通知しないことを特徴とする請求項２に記載のデバイス。
4. デバイスであって、
   前記デバイスの第１の情報を第１の情報処理装置と第２の情報処理装置に通知する登録の要求を前記第１の情報処理装置と前記第２の情報処理装置から受付ける登録手段と、
   前記デバイスの第２の情報を前記第１の情報処理装置に通知する登録の要求を前記第１の情報処理装置から受付ける受付手段と、
   前記登録手段が前記要求を前記第１の情報処理装置と前記第２の情報処理装置から受け付けた後に前記デバイスの状態が変化した場合に、前記受付手段が要求を受け付けた前記第１の情報処理装置には前記第１の情報と前記第２の情報を通知して、前記第２の情報処理装置には前記第２の情報を通知せずに前記第１の情報を通知する通知手段と、を有し、
   前記通知手段は、前記第１の情報処理装置に前記第２の情報を前記特定の期間通知し、
   前記特定の期間は前記第１の情報処理装置が送信した印刷ジョブの処理期間であることを特徴とするデバイス。
5. 前記通知手段は、前記受付手段が要求を受け付けた前記第１の情報処理装置に前記第２の情報を特定の期間集約して通知することを特徴とする請求項１乃至４のいずれか１項にデバイス。
6. 前記第１の情報はＰｕｂｌｉｃ要素であり、前記第２の情報はＰｒｉｖａｔｅ要素であることを特徴とする請求項１乃至５のいずれか１項に記載のデバイス。
7. デバイスにおいて実行されるプログラムであって、
   前記デバイスを、
   前記デバイスの第１の情報を第１の情報処理装置と第２の情報処理装置に通知する登録の要求を前記第１の情報処理装置と前記第２の情報処理装置から受付ける登録手段、
   前記デバイスの第２の情報を前記第１の情報処理装置に通知する登録の要求を前記第１の情報処理装置から受付ける受付手段、
   前記登録手段が前記要求を前記第１の情報処理装置と前記第２の情報処理装置から受け付けた後に前記デバイスの状態が変化した場合に、前記受付手段が要求を受け付けた前記第１の情報処理装置には前記第１の情報と前記第２の情報を通知して、前記第２の情報処理装置には前記第２の情報を通知せずに前記第１の情報を通知する通知手段、として機能させ、
   前記受付手段は、前記デバイスの第１の情報が記載されたイベント内の情報である前記デバイスの第２の情報を前記第１の情報処理装置に特定の期間通知する登録の要求を前記第１の情報処理装置から受付けると、前記通知手段は、前記第１の情報処理装置に前記第２の情報を前記特定の期間通知し、
   前記特定の期間は前記第１の情報処理装置が送信した印刷ジョブの処理期間であることを特徴とするプログラム。
8. 前記受付手段が前記第２の情報を前記第１の情報処理装置に通知する登録の要求を前記第１の情報処理装置から受付けた後に、前記受付手段が前記第２の情報を前記第１の情報処理装置に通知する登録を解除する要求を受け付けた場合、前記通知手段は前記第２の情報を前記第１の情報処理装置に通知しないことを特徴とする請求項７に記載のプログラム。
9. 前記受付手段が前記第２の情報を前記第１の情報処理装置に通知する登録の要求を前記第１の情報処理装置から受付けた後に、前記受付手段が前記第２の情報を前記第１の情報処理装置のアプリケーションに通知する登録を解除する要求を前記第１の情報処理装置の全てのアプリケーションから受け付けた場合、前記通知手段は前記第２の情報を前記第１の情報処理装置に通知しないことを特徴とする請求項８に記載のプログラム。
10. デバイスにおいて実行されるプログラムであって、
    前記デバイスを、
    前記デバイスの第１の情報を第１の情報処理装置と第２の情報処理装置に通知する登録の要求を前記第１の情報処理装置と前記第２の情報処理装置から受付ける登録手段と、
    前記デバイスの第２の情報を前記第１の情報処理装置に通知する登録の要求を前記第１の情報処理装置から受付ける受付手段と、
    前記登録手段が前記要求を前記第１の情報処理装置と前記第２の情報処理装置から受け付けた後に前記デバイスの状態が変化した場合に、前記受付手段が要求を受け付けた前記第１の情報処理装置には前記第１の情報と前記第２の情報を通知して、前記第２の情報処理装置には前記第２の情報を通知せずに前記第１の情報を通知する通知手段として機能させ、
    前記通知手段は、前記第１の情報処理装置に前記第２の情報を前記特定の期間通知し、
    前記特定の期間は前記第１の情報処理装置が送信した印刷ジョブの処理期間であることを特徴とするプログラム。
11. 前記特定の期間は時間であることを特徴とする請求項７乃至１０のいずれか１項に記載のプログラム。
12. 前記通知手段は、前記受付手段が要求を受け付けた前記第１の情報処理装置に前記第２の情報を特定の期間集約して通知することを特徴とする請求項７乃至１１のいずれか１項に記載のプログラム。
13. 前記第１の情報はＰｕｂｌｉｃ要素であり、前記第２の情報はＰｒｉｖａｔｅ要素であることを特徴とする請求項７乃至１２のいずれか１項に記載のプログラム。

Images