JP6021329B2 - 配信装置、制御方法およびコンピュータプログラム - Google Patents

Description

本発明は、配信装置、制御方法およびコンピュータプログラムに関する。

クライアント装置に対してプリンタからジョブの状態などのイベントを配信する技術が提案されている。特許文献１は、複合機が、自装置においてイベントが発生したことを検出し、検出したイベントの種別の監視を要求したクライアントに対して、このイベントをマルチキャストやブロードキャストで通知するイベント通知方法を開示する。

特開２００９−２３０４７７号公報

イベントを配信する配信装置が、特許文献１が開示するイベント通知方法を適用し、プリンタにおいて発生したイベントを、イベントの配信要求をしているクライアント装置に配信することが考えられる。しかし、この配信装置が、クライアント装置に対し、ブロードキャスト方式やマルチキャスト方式でイベントを配信する方法では、例えば、以下の課題がある。この方法では、配信装置が、イベントの配信要求をしているクライアント装置がイベントを受信したかを確認しないので、クライアント装置が起動していない場合や、クライアント装置が配信装置と通信できない場合に、イベントをとりこぼす。

本発明は、上述した課題を解決するためになされたものである。本発明は、プリンタにおいて発生するイベントをクライアント装置に配信し、クライアント装置がイベントを受信したことを確認できるようにする配信装置の提供を目的とする。

本発明の一実施形態の配信装置は、１以上のクライアント装置のそれぞれから印刷装置において発生するイベントの配信に関する設定情報の登録要求を受け付け、前記設定情報を登録する登録手段と、印刷装置から該印刷装置において発生したイベントに関するイベント情報を取得する取得手段と、前記取得されたイベント情報と前記登録された設定情報とに基づいて、配信対象とするイベント情報を決定する決定手段と、前記配信対象として決定されたイベント情報を、前記登録された設定情報の登録要求元の１以上のクライアント装置とは異なるクライアント装置を含む複数のクライアント装置に配信する配信手段と、前記クライアント装置が前記イベント情報を受け取ったことを確認する確認手段とを備え、前記設定情報は、印刷装置のステータスに対応するステータスパスを有し、前記取得手段が取得するイベント情報は、印刷装置のステータスに対応するステータスパス、またはステータスとステータスパスを有し、前記決定手段は、前記イベント情報が有するステータスパスが前記設定情報に存在するかを判断し、前記イベント情報が有するステータスパスが前記設定情報に存在する場合に、該イベント情報を配信対象として決定し、前記クライアント装置は、リーフノードまたはリーフノード以外のノードとを含むＸＭＬ形式のステータス情報内のいずれかのノードを指定することにより、前記設定情報の登録要求を行い、前記イベント情報の配信を受けたクライアント装置は、該イベント情報が含むステータスパスが前記リーフノードかリーフノード以外のノードであるかを判断し、前記イベント情報が含むステータスパスがリーフノードである場合は、該イベント情報が含むステータスを取得し、前記イベント情報が含むステータスパスがリーフノード以外のノードである場合は、前記配信装置に対して該ステータスパスに対応するステータスの配信を要求する。

本発明の配信装置によれば、イベントの配信を求めるクライアント装置がイベントを受信したことを確認できるようになる。したがって、当該クライアント装置がイベントをとりこぼすことを防止することができる。

実施例１のシステム構成例を示す図である。 ステータス情報の例を示す図である。 クライアント管理テーブルの例を示す図である。 印刷装置情報リストの例を示す図である。 クライアントが画面に表示するダイアログの一例を示す図である。 ステータスパスの登録処理を説明するフローチャートである。 ステータスパス管理テーブルの例を示す図である。 配信方法保持テーブルの一例を示す図である。 イベント配信を受けるクライアントの動作処理の例を説明する図である。 ジョブの発行処理と、ジョブ状態のイベントの受信処理の例を説明するフローチャートである。 実施例２におけるイベント配信装置の構成の一部を示す図である。 イベント圧縮ルールテーブルの例を示す図である。 本発明に適用可能な情報処理装置のハードウェアの構成例を示す図である。

（実施例１）
図１は、実施例１のシステム構成例を示す図である。図１の１０１はクライアントＡ、１０２はクライアントＢ、１０３はクライアントＣを示す。クライアントＡ、Ｂ、Ｃは、クライアント装置上で動作するクライアントアプリケーション（以下、クライアントと記述）である。

イベント配信装置１００は、本実施形態の配信装置である。イベント配信装置１００は、ネットワーク上のサーバ装置として配置され、クライアントＰＣとプリンタと通信を行うことが可能になっている。１０５、１０６、１０７で示されるプリンタＸ、プリンタＹ、プリンタＺは、イベント配信装置１００が管理する印刷装置であり、ネットワークやＵＳＢケーブル等を経由して接続されている。各プリンタには、任意のステータスの変化を知るため、もしくは任意のステータスの値を取得するために、ステータスパスを登録することができる。

図１３は、本発明に適用可能な情報処理装置（イベント配信装置１００、クライアントＰＣ）のハードウェアの構成例を示す図である。ＣＰＵ１３０１は、装置内の全体の制御を司る。補助記憶装置１３０３には、ＯＳ（オペレーティングシステム）や後述の本発明に係る制御処理を実現するためのコンピュータプログラムや各種データが記憶されている。補助記憶装置１３０３に記憶されたコンピュータプログラムはメモリ１３０２に展開されるなどして、ＣＰＵ１３０１により実行される。入力デバイス１３０４は、ユーザより入力を受け付けるためのデバイスである。ネットワーク接続デバイス１３０５は、ネットワーク上からのデータを受け取ったり、ネットワーク上へデータを送信したりする制御を行うためのデバイスである。クライアントＰＣなどにおいては、さらにディスプレイなどの出力デバイスを追加された構成であってもよい。

図２は、プリンタにおける、各印刷装置のステータスを管理するステータス情報の例を示す図である。ステータス情報は、図２（Ａ）に示すように、ＸＭＬ形式（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）のデータとして保存される。クライアントが、ステータス情報のうち、変化通知を受け取りたいステータスを配信対象データとして指定するには、ＸＰａｔｈ（ＸＭＬ Ｐａｔｈ Ｌａｎｇｕａｇｅ）に準じた記法でスタータスパスを指定する。図２（Ｂ）は、ステータスパスの記述例である。図２（Ａ）に示すステータス情報内のノードのうち、リーフノード以外のノードを指定することによって、その子ノード全てを指定することができる。

例えば、ステータスパスに、リーフノード以外のノードである「／Ｓｔａｔｕｓ／Ｐｒｉｎｔｅｒ／ＤｅｖｉｃｅＳｔａｔｕｓ」を指定した場合は、図２（Ａ）の例における、
・Ｓｕｍｍａｒｙ
・Ｓｅｖｅｒｉｔｙ
・Ｄｅｔａｉｌ
という３種類のリーフノードのいずれかのステータスが変化した際に、プリンタからステータス変化のイベントを受信する事ができる。すなわち、クライアントは、リーフノードまたはリーフノード以外のノードとを含むＸＭＬ形式のステータス情報内のいずれかのノードを指定することにより、イベント設定情報の登録要求を行う。本実施例において、イベント配信装置１００は、プリンタ同様に、クライアントから指定されたステータスパスを登録する。

図１に戻って、イベント配信装置１００は、モジュール１０８乃至１１４を備える。本実施形態の配信装置における制御方法は、モジュール１０８乃至１１４の機能によって実現される。

クライアント管理モジュール１０８は、クライアント１０１、１０２、１０３からの接続、切断要求を受け付け、また、各クライアントとの接続を管理する。デバイス管理モジュール１０９は、それぞれ、プリンタＸ１０５、プリンタＹ１０６、プリンタＺ１０７と接続し、デバイスの接続状態を管理する。イベント管理モジュール１１０は、イベント管理モジュールを構成する内部モジュール１１１乃至１１３を備える。なお、図中の１０４は、配信モジュールであって、クライアント装置モジュール１０８乃至イベント管理モジュール１１０を備える。

また、ジョブ管理モジュール１１４は、各印刷装置にジョブを発行するモジュールである。例えば、ジョブ管理モジュール１１４は、各印刷装置にジョブを発行する印刷ジョブ管理モジュールとして機能する。イベント配信装置がジョブ管理モジュールを備えない構成をとるようにしてもよい。

イベント配信装置１００は、例えば、ＯＳに常駐するプロセスとして実装される。本実施例では、イベント配信装置１００は、マイクロソフトウィンドウズ（登録商標）ＭＩＣＲＯＳＯＦＴＷＩＮＤＯＷＳ（登録商標）ＯＳ上のサービスとして実装される。

また、イベント配信装置１００は、クライアントＰＣに対してＡＰＩ（アプリケーション・インターフェース）を提供する。本実施例では、当該ＡＰＩとして、ＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）インタフェースを適用する。

＜クライアントの接続＞
次に、各クライアントＰＣがイベント配信装置に接続する処理フローを説明する。まず、クライアント１０１が、イベント配信装置１００が提供するＡＰＩを使用して、自身を識別するためのインスタンスを生成し、その識別子（クライアント識別子）を得る。以降のクライアントからのＡＰＩの呼び出しは、該クライアント識別子を指定することにより、イベント配信装置に対して要求を伝えることができる。

インスタンスの生成要求は、ＡＰＩを経由してクライアント管理モジュール１０８に送られる。クライアント管理モジュール１０８は、インスタンス生成要求ごとに新規、かつユニークなクライアント識別子を発行し、クライアント１０１に該識別子を送信する。この際、クライアント管理モジュール１０８は、クライアント識別子をクライアントの識別情報と関連付けて、クライアント管理テーブルに保存する。

図３は、クライアント管理テーブルの例を示す図である。クライアント管理テーブル３０１は、クライアント識別子、ＮｅｔＢＩＯＳ名、ＩＰ ＡＤＤＲＥＳＳといったデータ項目を有する。１つのクライアントが複数のクライアント識別子を持つことも可能である。

次に、クライアント１０１は、イベント配信装置１００から印刷装置の各種ステータスやエラー通知を受けるためのコールバック用イベント受信オブジェクトを登録する。クライアント１０１は、既定のインタフェースを実装しており、イベント受信オブジェクト登録用ＡＰＩを使用してイベント受信オブジェクトを登録する。

＜対象印刷装置の指定＞
上述したイベント受信オブジェクトの登録が完了した後、クライアント１０１は、印刷装置一覧取得用のＡＰＩを使用して、イベント配信装置に登録された印刷装置の一覧情報を取得する。印刷装置一覧情報としては、デバイス管理モジュール１０９が保持する印刷装置情報リストがクライアント１０１に返される。

図４は、印刷装置情報リストの例を示す図である。イベント配信装置１００が印刷情報リスト４０１を管理している。イベント配信装置１００は、例えば、印刷装置情報リストを、ＯＳ上のファイルやＤＢ（Database）として管理する。印刷装置情報リストを更新する場合、直接エディター等から更新してもよいし、ＧＵＩ（Graphical User Interface
）を用意し、該ＧＵＩから更新してもよい。

クライアント１０１は、印刷装置一覧（リスト）を取得した後、印刷装置一覧からクライアント１０１で使用する印刷装置を指定し、対応する印刷装置識別情報を取得する。

図５は、クライアントが画面に表示するダイアログの一例を示す図である。クライアントＰＣのユーザは、図５に示すダイアログを用いて、使用する印刷装置を指定する。ユーザが、図５中の印刷装置一覧表示部５０１に列挙された印刷装置のうち、使用する印刷装置を選択し、設定ボタン５０２を押下する。クライアント１０１は、ユーザが選択した印刷装置に対応する印刷装置識別情報を引数として、印刷装置インスタンス生成のＡＰＩを呼び、生成された印刷装置インスタンスの識別子を得る。以降のＡＰＩ呼び出しにおいては、得られた印刷装置インスタンス識別子（以下、印刷装置識別子）を指定することにより、ＡＰＩに対応する処理の対象となる印刷装置を指定することが可能となる。

＜イベントの登録＞
クライアント１０１が、特定の印刷装置について、該印刷装置のステータスや該印刷装置で実行される印刷ジョブのステータスの変化の通知が必要な場合、クライアント１０１は、該ステータスを表すパス（ステータスパス）を専用のＡＰＩにより登録する。これにより、クライアント１０１が、イベントの配信要求を行う。

図６は、ステータスパスの登録処理を説明するフローチャートである。クライアント１０１が、ステータスパスをイベント配信設定情報の引数とするイベント配信設定用ＡＰＩを呼ぶ（ステータス登録要求を行う）と、この要求がイベント登録モジュール１１１に送信される。イベント配信設定情報は、印刷装置において発生するイベントの配信に関する設定情報である。そして、ステータス登録要求は、イベント配信設定情報（この例ではステータスパス）の登録要求である。

図６（Ａ）は、イベント登録モジュールの動作処理フローの例である。イベント登録モジュール１１１は、ステータス登録要求の内容をチェック後、ステータス登録要求をステータスパス管理テーブル７０１に登録する。具体的には、イベント登録モジュール１１１が、ステータス登録要求に含まれる各識別子、ステータスパスの妥当性をチェックする（ステップＳ１）。各識別子、ステータスパスの妥当性がない（ＮＧである）場合は、処理を終了する。各識別子、ステータスパスの妥当性がある（ＯＫである）場合は、処理がステップＳ２に進む。

次に、イベント登録モジュール１１１が、ステータス登録要求に含まれる各識別子、ステータスパス等の全ての登録対象の要素が一致するレコードがステータスパス管理テーブル７０１に存在しないかを判断する（ステップＳ２）。ステータス登録要求に含まれる全ての登録対象の要素が一致するレコードがステータスパス管理テーブル７０１に存在する場合は、処理を終了する。ステータス登録要求に含まれる全ての登録対象の要素が一致するレコードがステータスパス管理テーブル７０１に存在しない場合は、イベント登録モジュール１１１が、ステータスパス管理テーブル７０１に登録対象の要素を登録する（ステップＳ３）。すなわち、イベント登録モジュール１１１は、クライアント装置からイベント配信設定情報（この例ではステータスパス）を受け付けて登録する設定情報登録手段として機能する。

図７は、ステータスパス管理テーブルの例を示す図である。図７（Ａ）は、イベント登録モジュール１１１用のステータスパス管理テーブルの例を示す。ステータスパス管理テーブル７０１には、ステータスパスと印刷装置識別子とがクライアント識別子と関連付けて登録される。

図６（Ａ）に戻って、イベント登録モジュール１１１は、ステータスパス管理テーブル７０１にステータス登録要求の内容を登録後、このステータス登録要求をデバイス管理モジュール１０９に対して送信する（ステップＳ４）。

デバイス管理モジュール１０９は、イベント登録モジュール１１１からステータスパス登録要求を受けると、印刷装置識別子とステータスパスとをイベント受信モジュール１１３に送信する。イベント受信モジュール１１３は、イベント配信装置１００に接続されるプリンタのステータスやステータス変化イベント、エラーイベントを含むイベントを受信する。すなわち、イベント受信モジュール１１３は、印刷装置から該印刷装置において発生したイベントに関するイベント情報を取得する取得手段として機能する。イベント受信モジュール１１３は、ステータス変化イベントを受信するための、イベント受信モジュール用のステータスパス管理テーブルを有している。

図７（Ｂ）は、イベント受信モジュール用のステータスパス管理テーブルの例を示す。ステータスパス管理テーブル７０２には、ステータスパスとステータスと印刷装置識別子とがクライアント識別子と関連付けて登録される。ステータスパス管理テーブル７０２に登録されたステータスパスは、ステータスパス管理テーブル７０１に登録されたステータスパスと同様に、イベント配信設定情報として機能する。

図６（Ｂ）は、イベント受信モジュールの動作処理フローの例である。まず、イベント受信モジュール１１３が、デバイス管理モジュール１０９からステータス登録要求を受信し、ステータス登録要求に含まれる印刷装置識別子とステータスパスとを受信する（ステップＳ１１）。

次に、イベント受信モジュール１１３が、ステータスパス管理テーブル７０２に、ステータス登録要求に含まれるステータスパスがあるかをチェックする（ステップＳ１２）。イベント受信モジュール１１３が、ステータスパス管理テーブル７０２に、ステータス登録要求に含まれるステータスパスと一致するステータスパスに対応するレコードがあるかを判断する（ステップＳ１３）。ステータスパス管理テーブル７０２に、ステータス登録要求に含まれるステータスパスと一致するステータスパスに対応するレコードがある場合は、イベント受信モジュール１１３が、レコードの参照カウンタを１増やす（ステップＳ１６）。そして、デバイス管理モジュール１０９に制御を戻す。

ステータスパス管理テーブル７０２に、ステータス登録要求に含まれるステータスパスと一致するステータスパスに対応するレコードがない場合は、ステップＳ１４に進む。そして、イベント受信モジュール１１３は、ステータスパス管理テーブル７０２に、ステータス登録要求に含まれる印刷装置識別子、ステータスパスを１つのレコードとして保存する（ステップＳ１４）。そして、イベント受信モジュール１１３が、参照カウンタの値を１に設定した後、デバイス管理モジュール１０９に、上記ステップＳ１２のチェック結果を返信する。

デバイス管理モジュール１０９が、チェック結果の返信を受けると、プリンタＸ１０５に対してステータスパスを登録する。これにより、プリンタに対して、重複したステータスパスが登録されるのを避けることができる。

本実施例では、プリンタＸ１０５からのイベントをイベント受信モジュール１１３で受けるようにしているが、デバイス管理モジュール１０９がプリンタＸ１０５に必要なステータスをポーリングして、ステータスが変化することを検知してもよい。また、本実施例では、プリンタＸ１０５について説明しているが、プリンタＹ１０６、プリンタＺ１０７についても同様である。

＜イベントの発生とステータス受信＞
プリンタＸ１０５において、登録ステータスパスに対応するステータスに変化があると、イベント受信モジュール１１３にステータス変更の通知がなされる。ステータス変更の通知は、例えば、以下の（ｉ）、（ｉｉ）のステータス配信ルールを有する。
（ｉ）プリンタＸ１０５に登録したステータスパスが、リーフノードを示す場合、リーフノードの指し示すステータスが変化した際に、ステータスパス、およびステータスそのものが通知される。
（ｉｉ）登録したステータスパスがリーフノード以外のノードを示す場合、該ノード以下のいずれかのリーフノードのステータスが変化した際に、該ノードのステータスパスが通知される。
すなわち、イベント受信モジュール１１３が取得するイベント情報は、印刷装置のステータスに対応するステータスパス、またはステータスとステータスパスを有する。

登録されたプリンタＸ１０５のステータスの変化通知を受けたイベント受信モジュール１１３は、プリンタＸ１０５に対応するステータス情報内の、対応するノードの値を更新する。

次に、イベント受信モジュール１１３が、図７（Ｂ）のステータスパス管理テーブル７０２を参照して、イベント配信モジュール１１２にステータスの変化を通知するか否かを決定する。変化したステータスに対応するステータスパスがステータスパス管理テーブル７０２内に存在する場合、イベント受信モジュール１１３がステータスの変化をイベント配信モジュール１１２に通知する。

すなわち、イベント受信モジュール１１３は、印刷装置から取得されたイベント情報と、ステータスパス管理テーブルに登録された設定情報（ステータスパス）とに基づいて、配信対象とするイベント情報を決定する決定手段として機能する。具体的には、イベント受信モジュール１１３は、イベント情報が有するステータスパスがステータスパス管理テーブル７０２に登録されたステータスパスに存在するかを判断する。イベント受信モジュール１１３は、イベント情報が有するステータスパスがステータスパス管理テーブル７０２に登録されたステータスパスに存在する場合に、該イベント情報を配信対象として決定する。

＜イベントの配信＞
イベント配信装置１００のイベント配信モジュール１１２が、イベント配信対象データであるステータス変化イベントや、ステータス、エラー等を配信する。すなわち、イベント配信モジュール１１２は、配信対象として決定されたイベント情報をクライアント装置に配信する配信手段として機能する。具体的には、イベント配信モジュール１１２が、イベント受信モジュール１１２からステータスの変化通知を受けると、イベント配信モジュール１１２は、配信方法保持テーブルを参照する。

図８は、配信方法保持テーブルの一例を示す図である。配信方法保持テーブル８０１は、パラメータ、値、備考といったデータ項目を有する。この例では、パラメータ８０１には、配信対象クライアント８０２が格納されている。値は、パラメータの値である。備考は、パラメータの値の説明が格納されている。この例では、パラメータの値「Ａｌｌ」は、全クライアントに配信することを示す。また、パラメータの値「依頼元」は、依頼元すなわちイベントの配信要求元のクライアントにのみ配信することを示す。

したがって、例えば、配信対象クライアント８０２の値が「Ａｌｌ」である場合、イベント配信モジュール１１２は、クライアント管理テーブル３０１を参照し、登録されている全てのクライアントに対してステータスの変化をイベント配信する。この際、イベント配信モジュールは、個々のクライアント毎のイベント配信を並行処理し、各クライアントがイベントを受信したことを確認しながら、イベントを順次配信する。クライアント１０１は、イベント配信を受けて、ステータスの処理を行う。

また、配信対象クライアント８０２の値が「依頼元」である場合、イベント配信モジュール１１２は、クライアント管理テーブル３０１を参照し、イベントの配信要求元のクライアントに対してイベント配信を行う。すなわち、イベント配信モジュール１１２は、以下の処理を実行する配信先切り替え手段として機能する。イベント配信モジュール１１２は、配信対象として決定されたイベント情報の配信先をイベント配信装置に接続中の全てのクライアント装置か、または当該イベント情報に対応するイベント配信設定情報の登録要求元のクライアント装置とするかを切り替える。

イベント配信モジュール１１２は、ステータスの変化をイベント配信する際に、配信対象のイベント情報を、イベント配信の要求元であるクライアントのクライアント識別子とともにクライアント装置に配信する。

図９は、イベント配信を受けるクライアントの動作処理の例を説明する図である。この例では、１つのイベント配信にて複数のステータスパス、つまり該ステータスパスのイベントが配信される。クライアント１０１は、イベント配信情報に含まれるステータスパスの数だけ、以下の処理を繰り返し実行する（ステップＳ２１）。

クライアント１０１は、ステータスパスがリーフノードであるかを判断する（ステップＳ２２）。ステータスパスがリーフノード以外のノードである場合は、クライアント１０１は、ステータスの値を取得するＡＰＩを呼び出し、該ステータスパスに対応したステータスの値を取得する（ステップＳ２４）。また、ステータスパスがリーフノードである場合は、配信された情報自体にステータスの値が含まれる。したがって、クライアント１０１は、この配信された情報自体に含まれるステータスを取得する（ステップＳ２３）クライアント１０１は、このように取得したステータスを利用して画面表示を更新する。

本実施例においては、イベントを必要としないクライアントにもイベントが配信される場合がある。したがって、クライアントは、イベント情報に含まれるクライアント識別子に基づいて、該クライアントにおいて不要なイベントを無視することが可能となる。また、イベント配信の要求元のクライアント以外のクライアントがイベント配信を受けた場合には、当該イベント配信を受けたクライアントは、以下の確認を行うことができる。すなわち、当該イベント配信を受けたクライアントは、イベント配信情報に含まれるクライアント識別子に基づいて、イベント配信の要求元のクライアントがイベント配信を受けたことを確認することができる。

＜印刷ジョブの発行と印刷ジョブ監視の設定＞
次に、クライアントＰＣが印刷ジョブを発行し、この印刷ジョブのイベントを受信する処理について説明する。

図１０は、ジョブの発行処理と、ジョブ状態のイベントの受信処理の例を説明するフローチャートである。まず、クライアント１０１が、印刷ジョブを構成する印刷チケットと実データとを準備する（ステップＳ３１）。印刷チケットには、印刷ジョブの構成と各ページの印刷設定および実データ名が記述されている。実データは、ＪＰＥＧ等の画像データや、ＰＤＬファイルである。

次に、クライアント１０１が、印刷ジョブ開始ＡＰＩを呼び、印刷ジョブを開始する（ステップＳ３２）。クライアント１０１は、印刷ジョブ開始ＡＰＩに対して、入力としてクライアント識別子、印刷装置識別子、チケットを指定し、出力としてジョブを識別するためのジョブ識別子を得る。印刷ジョブ開始ＡＰＩの呼び出しは、印刷ジョブ管理モジュール１１４を経由してデバイス管理モジュール１０９、またはプリンタＸ１０５まで同期処理される。

次に、クライアント１０１が、ステータスパス登録用ＡＰＩを呼ぶ。クライアント１０１は、ステータスパス登録用ＡＰＩを呼ぶ際に、ステータスパスとして、上記ステップＳ３２において得たジョブ識別子を含むステータスパスを指定する（ステップＳ３３）。これにより、クライアント１０１は、印刷ジョブのステータスが変化したことをイベントとして受信することが可能となる。

次に、クライアント１０１が、印刷データ送信ＡＰＩを呼ぶ。クライアント１０１は、印刷データ送信ＡＰＩに対し、入力としてクライアント識別子、印刷装置識別子、ジョブ識別子、実データを格納した領域のポインター、実データサイズを指定する。これにより、印刷データが印刷ジョブ管理モジュール１１４に送信される（ステップＳ３４）。印刷ジョブ管理モジュール１１４が、クライアント１０１からの印刷データ送信ＡＰＩの呼び出しを管理する。具体的には、印刷ジョブ管理モジュール１１４が、当該呼び出しを、印刷データの送付先の印刷装置毎に要求キューで管理する。クライアント１０１からの印刷データ送信ＡＰＩの呼び出し自体は、印刷データが印刷ジョブ管理モジュール１１４に転送終了した時点で終了する。

次に、クライアント１０１が、印刷ジョブに必要な全てのデータを送信し終わったかを判断する（ステップＳ３５）。クライアント１０１が、印刷ジョブに必要な全てのデータを送信し終わった場合は、クライアント１０１が印刷ジョブを終了して（ステップＳ３６）、ステップＳ３７に進む。クライアント１０１が、印刷ジョブに必要な全てのデータを送信し終わっていない場合は、ステップＳ３５に戻る。

ステップＳ３７において、クライアント１０１が、印刷ジョブ終了ＡＰＩを呼ぶ。クライアント１０１は、印刷ジョブ終了ＡＰＩに対し、入力としてクライアント識別子、印刷装置識別子、ジョブ識別子を指定する。印刷ジョブ管理モジュール１１４が、印刷ジョブ終了ＡＰＩの呼び出しを、印刷データの送付先の印刷装置毎にキュー管理する。クライアント１０１からの印刷ジョブ終了ＡＰＩの呼び出しは、印刷ジョブ管理モジュール１１４への要求が終了した時点で終了する。これにより、クライアント１０１が、デバイス管理モジュール１０９に対して印刷ジョブを送信することが可能となる。

印刷ジョブの状態が変化した場合、クライアント１０１は、イベント配信装置１００から、当該変化した印刷ジョブの状態をイベントとして配信される（ステップＳ３８）。また、印刷装置が実行する印刷ジョブが終了した場合、クライアント１０１は、イベント配信装置１００から、当該印刷ジョブの終了をイベントとして配信される（ステップＳ３９）。

図１０では、クライアント１０１が実行する処理について説明したが、他のクライアントでも同様に処理をすることで、印刷ジョブを発行可能となる。

＜印刷ジョブの制御＞
クライアントは、印刷ジョブを発行した後に、印刷ジョブ制御ＡＰＩを使用して該印刷ジョブの制御を行うことができる。クライアントは、印刷ジョブ制御ＡＰＩに対し、入力としてクライアント識別子、印刷装置識別子、ジョブ識別子、制御種別を指定する。制御種別には、キャンセル、削除などがある。

＜ジョブの監視用クライアントにおける印刷ジョブの監視＞
図１中のクライアントＣ１０３は、ジョブ監視用クライアントである。ジョブ監視用クライアントは、クライアント自身では印刷ジョブを発行せずに、他のクライアントが発行した印刷ジョブの状態監視を行う。

クライアントＣ１０３が、他クライアント、例えば印刷ジョブの発行を行うジョブ発行クライアントの発行する印刷ジョブを監視するには、前述の＜クライアントの接続＞において説明した、イベント配信装置への接続処理フローを実行する。

ジョブ発行クライアントであるクライアント１０１が、図１０のステップＳ３３において、ジョブのステータスパスを登録する。イベント配信装置１００が、接続中の全てのクライアントに対して、ジョブの状態をイベントとして配信する（図１０のステップＳ３８、Ｓ３９）。これにより、クライアントＣ１０３が、該イベントを受信することができる。

＜ジョブ監視用クライアントにおける印刷ジョブの監視＞
ジョブ監視用クライアントであるクライアントＣ１０３は、ジョブ状態のイベント配信を受信する際に、ステータスパスからジョブのジョブ識別子を取り出す。そして、クライアントＣ１０３は、取り出したジョブ識別子を用いて、印刷ジョブの制御を実行する。前述した印刷ジョブ制御ＡＰＩでは、印刷ジョブ制御ＡＰＩには、入力としてクライアント識別子、印刷装置識別子、ジョブ識別子が必要となる。以下、各識別子をクライアントＣ１０３が入手する処理について説明する。

クライアントＣ１０３は、前述した＜クライアントの接続＞において説明した、イベント配信装置への接続処理フローを実行しておく、これにより、クライアントＣ１０３が、クライアント識別子および全てのプリンタの印刷識別子を入手できる。また、他クライアントが、図１０を参照して説明したジョブの発行処理を実行して、ジョブ識別子を含むステータスパスを登録する。これにより、クライアントＣ１０３に対して、当該クライアントの発行するジョブのステータスがイベントとして通知され、この際にクライアントＣ１０３が、ステータスとステータスパスを入手できる。ステータスパスにはジョブ識別子が含まれるので、クライアントＣ１０３は、文字列操作によりジョブ識別子を取り出すことができる。

本実施例において、例えば、ジョブ識別子がプリンタ識別子を内包するようにしてもよい。つまり、イベント配信モジュール１１２が、イベント情報をイベント配信設定情報の登録要求元のクライアント装置の識別情報とイベント情報の取得元の印刷装置のプリンタ識別子と該印刷装置が実行中のジョブの識別情報とともにクライアント装置に配信する。これにより、ジョブ情報の配信を受けたクライアントＣ１０３が、文字列操作によって、ジョブを発行したプリンタのプリンタ識別子を特定可能となる。クライアントＣ１０３が、各プリンタのプリンタ識別子を使用して、当該プリンタの処理中のジョブ識別子一覧を定期的に取得するようにしてもよい。

（実施例２）
以下に、実施例２について説明する。実施例２では、図１１に示すように、イベント管理モジュール１１０が、イベント登録モジュール１１１乃至イベント受信モジュール１１３に加えて、イベント蓄積モジュール１１０１を備える。

イベント蓄積モジュール１１０１は、イベント配信モジュール１１２が配信するイベント情報を蓄積するサブモジュールである。イベント蓄積モジュール１１０１がイベント情報を蓄積するトリガとしては、以下のいずれか、ないしはその組み合わせを適用することができる。
・イベントの発生毎
・クライアントがイベントを受信できなくなった場合
・クライアントにイベントを最後に配信してから、一定時間が経過した場合
・イベントキューにおけるイベントの蓄積量が一定の値を超えた場合
・蓄積中のイベント数

イベント蓄積モジュール１１０１によれば、クライアントがイベントを受信できない場合や、受信できるがイベント配信よりもイベント発生頻度が高い場合などに、イベントを蓄積しておくことが可能となる。例えば、イベント蓄積モジュール１１０１が、クライアントがイベント情報を受けとったことを確認する確認手段として機能し、クライアントがイベントを受信できない場合にイベント情報を蓄積する。そして、イベント配信モジュール１１２が、当該クライアントがイベント情報を受信できた場合に、上記蓄積されていたイベント情報をクライアントに配信する。

イベント蓄積モジュール１１０１は、イベントの蓄積の際、メモリにイベントを保持してもよいし、データベース等に永続化をしてもよい。これにより、イベントが大量になったとしても、消費するメモリの量を一定以内に保つことができる。また、イベント蓄積モジュール１１０１は、データベース等にイベントを蓄積する場合は、データ配信装置の電源供給を断たれたとしてもイベントを保持しておくことができる。

なお、イベント管理モジュール１２０が、図示を省略するイベント圧縮モジュールを備えるようにしてもよい。イベント圧縮モジュールは、以下の処理を実行する圧縮手段として機能する。イベント圧縮モジュールは、イベント蓄積モジュール１１０１がイベント情報を蓄積する際、または、イベント配信モジュール１１２がイベント情報を配信する際に、予め決められたイベント情報の圧縮に関する圧縮ルールに基づいて、該イベント情報を圧縮する。

イベント圧縮モジュールは、以下に示すようなイベント圧縮ルールやイベント保持ルールを適用することができる。このために、イベント圧縮モジュールが、イベント圧縮ルールテーブルを保持するようにしてもよい。
（ｉ）イベント種別に応じた圧縮ルールを適用する。例えば、イベント圧縮モジュールが、印刷ジョブ状態やプリンタ状態については最終ステータスのみを保存し、エラーイベントは非圧縮にする。
（ｉｉ）また、ＸＭＬ形式の要素種別毎に圧縮ルールを変更する。例えば、イベント圧縮モジュールが、ステータスを指し示すステータスパスがリーフノード以外のノードの時は、ステータスパス同士をマージして一つのイベントとして保存する。
（ｉｉｉ）ステータスを指し示すステータスパスがリーフノード以外のノードの場合は該ノード以下のリーフノードのステータスそのものを取得し、取得したステータスを保存する。
（ｉｖ）上記（ｉ）、（ｉｉ）（ｉｉｉ）を組み合わせた圧縮ルールを適用する。

図１２は、イベント圧縮ルールテーブルの例を示す図である。イベント圧縮ルールテーブル１２０１は、パラメータ、値、備考といったデータ項目を有する。この例では、パラメータ１２０１には、イベント蓄積、イベント圧縮ルールとしてのステータス別圧縮、ステータスパス種類別圧縮などが格納されている。値は、パラメータに格納された処理を実行するか否かを切り替える情報（”Ｏｎ”または”Ｏｆｆ”）が格納される。備考は、パラメータの値の説明が格納されている。”Ｏｎ”は、パラメータに格納されている処理を実行することを示す。”Ｏｆｆ”は、パラメータに格納されている処理を実行しないことを示す。

イベント圧縮モジュールが、圧縮処理を実行するトリガとして、以下のいずれかの値を閾値とし、同閾値を超えた際に圧縮を実施するようにしてもよい。
（ｉ）クライアントがイベントを受信できなくなってからの経過時間や最後のイベント配信からの経過時間
（ｉｉ）蓄積するイベントデータの量
（ｉｉｉ）蓄積したイベント数

本実施例では、イベント蓄積モジュールを記憶する手段としてデータベースを使用する。しかし、他の方法として、ファイルなど、情報を永続的に保存できるものであれば任意の記憶手段を用いることができる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

Claims (10)

1. 配信装置であって、
   １以上のクライアント装置のそれぞれから印刷装置において発生するイベントの配信に関する設定情報の登録要求を受け付け、前記設定情報を登録する登録手段と、
   印刷装置から該印刷装置において発生したイベントに関するイベント情報を取得する取得手段と、
   前記取得されたイベント情報と前記登録された設定情報とに基づいて、配信対象とするイベント情報を決定する決定手段と、
   前記配信対象として決定されたイベント情報を、前記登録された設定情報の登録要求元の１以上のクライアント装置とは異なるクライアント装置を含む複数のクライアント装置に配信する配信手段と、
   前記クライアント装置が前記イベント情報を受け取ったことを確認する確認手段とを備え、
   前記設定情報は、印刷装置のステータスに対応するステータスパスを有し、
   前記取得手段が取得するイベント情報は、印刷装置のステータスに対応するステータスパス、またはステータスとステータスパスを有し、
   前記決定手段は、前記イベント情報が有するステータスパスが前記設定情報に存在するかを判断し、前記イベント情報が有するステータスパスが前記設定情報に存在する場合に、該イベント情報を配信対象として決定し、
   前記クライアント装置は、リーフノードまたはリーフノード以外のノードとを含むＸＭＬ形式のステータス情報内のいずれかのノードを指定することにより、前記設定情報の登録要求を行い、
   前記イベント情報の配信を受けたクライアント装置は、該イベント情報が含むステータスパスが前記リーフノードかリーフノード以外のノードであるかを判断し、前記イベント情報が含むステータスパスがリーフノードである場合は、該イベント情報が含むステータスを取得し、前記イベント情報が含むステータスパスがリーフノード以外のノードである場合は、前記配信装置に対して該ステータスパスに対応するステータスの配信を要求する
   ことを特徴とする配信装置。
2. 前記配信対象として決定されたイベント情報の配信先を前記配信装置に接続中の、前記複数のクライアント装置としての全てのクライアント装置とするか、または前記イベント情報に対応する前記設定情報の登録要求元の１以上のクライアント装置とするかを切り替える切り替え手段を備える
   ことを特徴とする請求項１に記載の配信装置。
3. 前記配信手段は、前記配信対象として決定されたイベント情報を、該イベント情報に対応する前記設定情報の登録要求元のクライアント装置の識別情報とともにクライアント装置に配信する
   ことを特徴とする請求項１または請求項２に記載の配信装置。
4. 前記配信手段は、前記配信対象として決定されたイベント情報を、該イベント情報に対応する前記設定情報の登録要求元のクライアント装置の識別情報と、前記イベント情報の取得元の印刷装置の識別情報と、該印刷装置が実行中のジョブの識別情報とともにクライアント装置に配信する
   ことを特徴とする請求項１または請求項２に記載の配信装置。
5. 前記イベント情報の配信先のクライアント装置が該イベント情報を受信できない場合に、該イベント情報を蓄積する蓄積手段を備え、
   前記配信手段は、イベント情報の配信先のクライアント装置が前記イベント情報を受信できる状態になった場合に、前記蓄積手段に蓄積された該イベント情報を該クライアント装置に配信する
   ことを特徴とする請求項１乃至４のいずれか１項に記載の配信装置。
6. 前記蓄積手段が前記イベント情報を蓄積する際、または前記配信手段が該イベント情報を配信する際に、予め決められたイベント情報の圧縮に関する圧縮ルールに基づいて、該イベント情報を圧縮する圧縮手段を備える
   ことを特徴とする請求項５に記載の配信装置。
7. 配信装置における制御方法であって、
   １以上のクライアント装置のそれぞれから印刷装置において発生するイベントの配信に関する設定情報の登録要求を受け付け、前記設定情報を登録する登録工程と、
   印刷装置から少なくとも該印刷装置において発生したイベントに関するイベント情報を含む印刷装置情報を取得する取得工程と、
   前記取得された印刷装置情報が含む前記イベント情報と前記登録された設定情報とに基づいて、配信対象とするイベント情報を決定する決定工程と、
   前記配信対象として決定されたイベント情報を、前記登録された設定情報の登録要求元の１以上のクライアント装置とは異なるクライアント装置を含む複数のクライアント装置に配信する配信工程と、
   前記クライアント装置が前記イベント情報を受け取ったことを確認する確認工程とを有し、
   前記設定情報は、印刷装置のステータスに対応するステータスパスを有し、
   前記取得工程において取得されるイベント情報は、印刷装置のステータスに対応するステータスパス、またはステータスとステータスパスを有し、
   前記決定工程において、前記イベント情報が有するステータスパスが前記設定情報に存在するかを判断し、前記イベント情報が有するステータスパスが前記設定情報に存在する場合に、該イベント情報を配信対象として決定し、
   前記クライアント装置は、リーフノードまたはリーフノード以外のノードとを含むＸＭＬ形式のステータス情報内のいずれかのノードを指定することにより、前記設定情報の登録要求を行い、
   前記イベント情報の配信を受けたクライアント装置は、該イベント情報が含むステータスパスが前記リーフノードかリーフノード以外のノードであるかを判断し、前記イベント情報が含むステータスパスがリーフノードである場合は、該イベント情報が含むステータスを取得し、前記イベント情報が含むステータスパスがリーフノード以外のノードである場合は、前記配信装置に対して該ステータスパスに対応するステータスの配信を要求する
   ことを特徴とする配信装置における制御方法。
8. 前記配信対象として決定されたイベント情報の配信先を前記配信装置に接続中の、前記複数のクライアント装置としての全てのクライアント装置とするか、または前記イベント情報に対応する前記設定情報の登録要求元の１以上のクライアント装置とするかを切り替える切り替え工程をさらに有することを特徴とする請求項７に記載の制御方法。
9. 前記配信工程では、前記配信対象として決定されたイベント情報が、該イベント情報に対応する前記設定情報の登録要求元のクライアント装置の識別情報とともにクライアント装置に配信されることを特徴とする請求項７または請求項８に記載の制御方法。
10. 請求項１乃至６のいずれか１項に記載の手段としてコンピュータを機能させることを特徴とするコンピュータプログラム。

Images