JP2009020855A - ジョブログ管理システム、ジョブログ管理方法、及びコンピュータプログラム - Google Patents

Abstract

【課題】ジョブの履歴を、出来るだけユーザが望むタイミングで変更できるようにする。
【解決手段】課金先変更依頼ＵＩ９０１を用いて、課金先を変更するジョブの検索条件が指定されると、指定された検索条件に従って、課金先変更依頼が、クライアント端末装置１０１、１０２から管理サーバ１０４に送信される。課金先変更依頼を受信した管理サーバ１０４は、該当するジョブのジョブログを取得できるまで待機し、取得できたらジョブログの課金先の情報を変更し、変更した結果をユーザ（クライアント端末装置１０１、１０２）に送信する。
【選択図】図１

Description

本発明は、ジョブログ管理システム、ジョブログ管理方法、及びコンピュータプログラムに関し、特に、ジョブログ（ジョブの履歴）を管理するために用いて好適なものである。

印刷、スキャン、ＦＡＸ等、ジョブの集計を行って管理するジョブログ管理システムでは、ユーザがジョブを実行する際に、代金を集計するための課金先情報を指定することが可能である。また、ジョブの処理ページ数を集計する対象のユーザ、或いは所属部門等のユーザグループ等の集計先情報を指定することが可能である。
例えば、特許文献１には、印刷物の依頼元と配布先とが異なる印刷依頼に関して、配布先に簡易に課金を行えるようにした技術が開示されている。具体的に特許文献１では、印刷終了後に印刷履歴（ジョブログ）中の印刷依頼者情報を印刷物配布先情報へ変更することを、依頼者の権限に応じて設定可能にすることによって、課金先の指定を実現している。

課金先情報及び集計先情報は、ジョブログ中でユーザが指定するデータであるという点で性質が同じである。他のジョブログのデータは、例えば、印刷ジョブでは、ドキュメント名、印刷ユーザ名（印刷依頼者名）、印刷ページ数、カラー、両面、集約、用紙サイズ、印刷年月日、及び用紙種別等、実績によるものであり、ユーザが変更することができないデータである。
前記課金先情報及び集計先情報は、ユーザが指定するものであるため、指定ミスが起こり得る。ここでジョブログは、通常、システムが管理するデータベース(ＤＢ)に保存されるため、指定ミスがあった場合は、そのデータベースから変更すべきデータを検索し、変更すればよい。

例えば、次のようにすれば、前記課金先情報及び集計先情報を、比較的簡単にユーザに変更させることができる。まず、ユーザが最近実行したジョブログをデータベースから取得し、ユーザが所有するＰＣのＵＩ（User Interface）に一覧表示する。ユーザは、このＵＩを用いて、変更したいジョブを選択し、そのジョブのジョブログに対して正しい情報を入力する。このような機能を設ければ、ユーザが指定したジョブログに対して入力した情報でデータベースを更新することが可能である。

特開２００４−３６２０１５号公報

しかしながら、前述した従来の技術では、前記課金先情報及び集計先情報を変更するためには、ジョブログがデータベースに入っている必要がある。ここで、ユーザが、前記課金先情報及び集計先情報を変更したいと考えるのは、通常、指定ミスが起こった場合である。よって、ユーザが、前記課金先情報及び集計先情報を変更したいと考えるタイミングは、ジョブの終了直後が一番多い。しかしながら、ジョブログがデータベースに入るタイミングは、そのジョブログの取得方法や取得期間、並びにデバイス種類によって異なるのが一般的である。例えば、大容量のハードディスクを搭載した大型の複合機等のデバイスは、ジョブログを大量に保存できる。このため、大容量のハードディスクを搭載したデバイスに保存されているジョブログについては、一日に一度、通信量の少ない夜中にデータベースに取り込むようなことが行われている。また、ハードディスクが未搭載、或いはハードディスクの容量が小さいデバイスにおけるジョブログについては、そのジョブログをデータベースが取り込む間隔は短くなる。しかしながら、それでも、ネットワーク効率を考えると、デバイスの能力に応じて、出来るだけ長い間隔でジョブログをデータベースに取り込むようにすることが実施されている。こういった背景のため、印刷終了後、その印刷に対するジョブログがすぐにデータベースに入らない場合が多い。よって、ユーザは、データベースにジョブログが入るまで待ってからジョブログの変更処理を実行するか、印刷終了後、十分に時間が経ってからジョブログの変更処理を実施しなければならない。このようにすると、ユーザが、ジョブログの変更処理のための操作を忘れたり、ジョブログに対して指定（変更）すべき情報を忘れたりしてしまう可能性がある。

本発明は、このような問題点に鑑みてなされたものであり、ジョブログを、出来るだけユーザが望むタイミングで変更できるようにすることを目的とする。

本発明のジョブログ管理システムは、デバイスで実施されたジョブに対するジョブログをデータベースで管理するジョブログ管理システムであって、前記ジョブログを変更する対象のジョブの検索条件がユーザによって指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索する検索手段と、前記検索手段により、前記検索条件に適合したジョブログが検索されなかった場合、前記ジョブログを管理するデータベースが更新されるまで待機した後、前記ユーザの再検索の指示を受けることなく前記検索条件に適合したジョブログを再検索する再検索手段と、前記検索条件に適合したジョブログが検索されると、ユーザによって指定された変更内容に従って、前記ジョブログを変更する変更手段と、前記変更手段により変更された結果に関わる変更結果情報をユーザに報知する報知手段とを有することを特徴とする。
本発明の管理サーバは、ネットワークを介して接続されたデバイスで実施されたジョブに対するジョブログを管理する管理サーバであって、前記デバイスから取得したジョブログを格納するデータベースと、前記ジョブログを変更する対象のジョブの検索条件がユーザによって指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索する検索手段と、前記検索手段により、前記検索条件に適合したジョブログが検索されなかった場合、前記ジョブログを管理するデータベースが更新されるまで待機した後、前記ユーザの再検索の指示を受けることなく前記検索条件に適合したジョブログを再検索する再検索手段と、前記検索条件に適合したジョブログが検索されると、ユーザによって指定された変更内容に従って、前記ジョブログを変更する変更手段と、前記変更手段により変更された結果に関わる変更結果情報をユーザに報知するためクライアント端末装置に対して送信する送信手段とを有することを特徴とする。
本発明のクライアント端末装置は、デバイスに対してジョブの実行を指示するクライアント端末装置であって、外部のデータベースに記憶されているジョブログを取得する取得手段と、前記データベースから取得されたジョブログと、前記実行を指示したジョブに対応するジョブログとを表示装置上の同じ画面で表示する第１の表示手段と、前記第１の表示手段により表示された画面で前記実行を指示したジョブに対応するジョブログがユーザにより選択され、かつ前記データベースに当該ジョブログが記憶されていない場合、ユーザによる操作の内容に基づき、当該ジョブログを変更する変更手段と、前記第１の表示手段により表示された画面で前記データベースから取得されたジョブログがユーザにより選択された場合、または前記第１の表示手段により表示された画面でユーザにより選択されたジョブログが前記データベースに記憶されている場合、ユーザによる操作の内容に基づくジョブログの変更を、前記データベースに記憶されているジョブログを管理する管理サーバに依頼する依頼手段と、前記依頼手段により依頼されたジョブログの変更の結果を前記管理サーバから受け付ける受け付け手段と、前記変更手段によりジョブログが変更された場合と、前記受け付け手段によりジョブログの変更が受け付けられた場合に、前記変更の内容に関する情報を表示装置に表示する第２の表示手段とを有することを特徴とする。

本発明のジョブログ管理方法は、デバイスで実施されたジョブに対するジョブログをデータベースで管理するジョブログ管理方法であって、前記ジョブログを変更する対象のジョブの検索条件が指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索する検索ステップと、前記検索ステップで前記検索条件に適合したジョブログが検索されなかった場合、前記ジョブログを管理するデータベースが更新されるまで待機した後、ユーザの再検索の指示を受けることなく前記検索条件に適合したジョブログを再検索する再検索ステップと、前記検索条件に適合したジョブログが検索されると、ユーザによって指定された変更内容に従って、前記ジョブログを変更する変更ステップと、前記変更ステップで変更された結果に関わる変更結果情報を報知する報知ステップとを有することを特徴とする。
また、本発明の他の特徴とするところは、ネットワークを介して接続されたデバイスで実施されたジョブに対するジョブログを格納するためのデータベースを有する管理サーバにおけるジョブログ管理方法であって、前記ジョブログを変更する対象のジョブの検索条件がユーザによって指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索する検索ステップと、前記検索ステップで、前記検索条件に適合したジョブログが検索されなかった場合、前記ジョブログを管理するデータベースが更新されるまで待機した後、前記ユーザの再検索の指示を受けることなく前記検索条件に適合したジョブログを再検索する再検索ステップと、前記検索条件に適合したジョブログが検索されると、ユーザによって指定された変更内容に従って、前記ジョブログを変更する変更ステップと、前記変更ステップで変更された結果に関わる変更結果情報をユーザに報知するためクライアント端末装置に対して送信する送信ステップとを有することを特徴とする。
また、本発明のその他の特徴とするところは、デバイスに対してジョブの実行を指示するクライアント端末装置におけるジョブログ管理方法であって、外部のデータベースに記憶されているジョブログを取得する取得ステップと、前記データベースから取得されたジョブログと、前記実行を指示したジョブに対応するジョブログとを表示装置上の同じ画面で表示する第１の表示ステップと、前記第１の表示手段により表示された画面で前記実行を指示したジョブに対応するジョブログがユーザにより選択され、かつ前記データベースに当該ジョブログが記憶されていない場合、ユーザによる操作の内容に基づき、当該ジョブログを変更する変更ステップと、前記第１の表示ステップにおいて表示された画面で前記データベースから取得されたジョブログがユーザにより選択された場合、または前記第１の表示手段により表示された画面でユーザにより選択されたジョブログが前記データベースに記憶されている場合、ユーザによる操作の内容に基づくジョブログの変更を、前記データベースに記憶されているジョブログを管理する管理サーバに依頼する依頼ステップと、前記依頼ステップにより依頼されたジョブログの変更の結果を前記管理サーバから受け付ける受け付けステップと、前記変更ステップによりジョブログが変更された場合と、前記受け付けステップによりジョブログの変更が受け付けられた場合に、前記変更の内容に関する情報を表示装置に表示する第２の表示ステップとを有することを特徴とする。

本発明のコンピュータプログラムは、ネットワークを介して接続されたデバイスで実施されたジョブに対するジョブログを格納するためのデータベースを備える管理サーバにおけるジョブログ管理ステップをコンピュータに実行させるためのコンピュータプログラムであって、前記ジョブログを変更する対象のジョブの検索条件がユーザによって指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索する検索ステップと、前記検索ステップで、前記検索条件に適合したジョブログが検索されなかった場合、前記ジョブログを管理するデータベースが更新されるまで待機した後、前記ユーザの再検索の指示を受けることなく前記検索条件に適合したジョブログを再検索する再検索ステップと、前記検索条件に適合したジョブログが検索されると、ユーザによって指定された変更内容に従って、前記ジョブログを変更する変更ステップと、前記変更ステップで変更された結果に関わる変更結果情報をユーザに報知するためクライアント端末装置に対して送信する送信ステップとをコンピュータに実行させることを特徴とする。
また、本発明の他の特徴とするところは、デバイスに対してジョブの実行を指示するクライアント端末装置におけるジョブログ管理ステップをコンピュータに実行させるためのコンピュータプログラムであって、外部のデータベースに記憶されているジョブログを取得する取得ステップと、前記データベースから取得されたジョブログと、前記実行を指示したジョブに対応するジョブログとを表示装置上の同じ画面で表示する第１の表示ステップと、前記第１の表示ステップにより表示された画面で前記実行を指示したジョブに対応するジョブログがユーザにより選択され、かつ前記データベースに当該ジョブログが記憶されていない場合、ユーザによる操作の内容に基づき、当該ジョブログを変更する変更ステップと、前記第１の表示ステップにより表示された画面で前記データベースから取得されたジョブログがユーザにより選択された場合、または前記第１の表示ステップにより表示された画面でユーザにより選択されたジョブログが前記データベースに記憶されている場合、ユーザによる操作の内容に基づくジョブログの変更を、前記データベースに記憶されているジョブログを管理する管理サーバに依頼する依頼ステップと、前記依頼ステップにより依頼されたジョブログの変更の結果を前記管理サーバから受け付ける受け付けステップと、前記変更ステップによりジョブログが変更された場合と、前記受け付けステップによりジョブログの変更が受け付けられた場合に、前記変更の内容に関する情報を表示装置に表示する第２の表示ステップとをコンピュータに実行させることを特徴とする。

本発明によれば、検索条件に適合したジョブログが検索されなかった場合、ジョブログを再検索するようにしたので、従来よりもジョブログが検索される可能性を高めることができる。したがって、ジョブログを、出来るだけユーザが望むタイミングで変更できるようにすることができ、ユーザの操作忘れ等を防止できる。よって、ユーザの利便性を向上させることができる。

以下、図面を参照しながら、本発明を適用するのに好適である実施形態について説明を行う。
（第１の実施形態）
図１は、ジョブログ管理システムの構成の一例を示すブロック図である。
図１において、クライアント端末装置（情報処理装置）１０１、１０２は、例えばパーソナルコンピュータであり、アプリケーションプログラム等の各種のプログラムを実行することが可能である。これらクライアント端末装置１０１、１０２は、イーサネット（登録商標）等のネットワークケーブルや公衆回線等によって、ＬＡＮ、ＷＡＮ、又はインターネット等のネットワーク１０７に接続されている。クライアント端末装置１０１、１０２は、ジョブの課金情報や集計情報といったジョブログの変更依頼を実施するプログラムを必要に応じて実行することにより、ジョブログを収集してデータベースサーバ１０３に保存するジョブログ収集部を有している。尚、図１では複数台のクライアント端末装置１０１、１０２を記載しているが、クライアント端末装置は、１台でも複数台でもよい。

データベースサーバ１０３は、本実施形態のジョブログを保存する情報処理装置であり、クライアント端末装置１０１、１０２と同様に、ネットワーク１０７に接続されている。尚、本実施形態では、データベースサーバ１０３をジョブログ管理システムに設けるようにしているが、データベースサーバ１０３はなくてもよい。データベースサーバ１０３がない場合、ジョブログは、ユーザが所有するクライアント端末装置１０１、１０２、データベースサーバ１０３以外のサーバ（ファイルサーバ）、又はデバイス（例えばＭＦＰ１０５、ネットワークプリンタ１０６）等に保存される。

管理サーバ１０４は、クライアント端末装置１０１、１０２へデータの送受信を行うための変更要求受信部、確認要求送信部、及び処理結果送信部をプログラムとして格納している情報処理装置である。また、管理サーバ１０４は、データベースサーバ１０３についての処理を行うためのＤＢ検索部、ＤＢ変更部、ＤＢ更新通知生成部、及びＤＢ検索待機部等をプログラムとして格納している。更に、管理サーバ１０４は、クライアント端末装置１０１、１０２（前記ジョブログ収集部）から受信したジョブログを、データベースサーバ１０３に保存するジョブログ保存部をプログラムとして格納している。管理サーバ１０４は、データベースサーバ１０３と同様に、ネットワーク１０７に接続されている。

尚、本実施形態では、管理サーバ１０４をジョブログ管理システムに設けるようにしているが、管理サーバ１０４はなくてもよい。管理サーバ１０４がない場合、ジョブログは、ユーザが所有するクライアント端末装置１０１、１０２、管理サーバ１０４以外のサーバ、又はデバイス（例えばＭＦＰ１０５、ネットワークプリンタ１０６）等に保存される。
また、本実施形態では、データベースサーバ１０３と、管理サーバ１０４とを別々のサーバとしているが、これらを１つのサーバにまとめることも可能である。

複合機（ＭＦＰ）１０５は、印刷制御装置、スキャナ、及びコピー等の機能を持ったデバイスである。ネットワークプリンタ１０６は、画像形成装置である。ＭＦＰ１０５と、ネットワークプリンタ１０６とは共に、クライアント端末装置１０１、１０２から送信される印刷要求を解析して処理する。尚、ネットワークプリンタ１０６として、電子写真方式を最小したレーザービームプリンタや、インクジェット方式を採用したインクジェットプリンタや、熱転写方式を利用したプリンタ等、様々な方式のプリンタを適応させることができる。

クライアント端末装置１０１、１０２、データベースサーバ１０３、及び管理サーバ１０４は、一般的な情報処理装置である。クライアント端末装置１０１、１０２、データベースサーバ１０３、及び管理サーバ１０４には、ジョブログを管理するための処理を行うジョブログ管理プログラムが実行可能に格納されている。

図２は、本実施の形態における情報処理装置の構成を説明するブロック図である。尚、情報処理装置の一例であるクライアント端末装置１０１、１０２、データベースサーバ１０３、及び管理サーバ１０４は、同様或いは同等のハードウェア構成を有するものとする。よって、ここでは、クライアント端末装置１０１、１０２、データベースサーバ１０３、及び管理サーバ１０４の構成を説明するブロック図として、図２を説明する。

図２において、ＣＰＵ２００は、情報処理装置の制御手段であり、ハードディスク（ＨＤ）２０５に格納されているアプリケーションプログラム、ＯＳ、及び前記ジョブログ管理プログラム等を実行する。更に、ＣＰＵ２００は、プログラムの実行に必要な情報や、ファイル等を、ＲＡＭ２０２に一時的に格納する制御を行う。

ＲＯＭ２０１は記憶手段であり、その内部には、基本Ｉ／Ｏプログラム等のプログラムが記憶されている。ＲＡＭ２０２は一時記憶手段であり、ＣＰＵ２００の主メモリやワークエリア等として機能する。
フロッピー（登録商標）ディスク（ＦＤ）ドライブ２０３は、記憶媒体読み込み手段である。後述する図６に示すように、ＦＤドライブ２０３を通じて、記憶媒体としてのフロッピー（登録商標）ディスク（ＦＤ）２０４に記憶されたプログラム等を本コンピュータシステムにロードすることができる。尚、記憶媒体は、ＦＤに限らず、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＰＣカード、ＤＶＤ、ＩＣメモリカード、ＭＯ、メモリスティック等、任意の記憶媒体でよい。

フロッピー（登録商標）ディスク（ＦＤ）２０４は、コンピュータが読み取り可能なプログラムが格納された記憶媒体である。
ハードディスク（ＨＤ）２０５は外部記憶手段の一つであり、大容量メモリとして機能する。ハードディスク（ＨＤ）２０５は、アプリケーションプログラム、ＯＳ、前記ジョブログ管理プログラム、及び関連プログラム等を格納している。
キーボード２０６は指示入力手段であり、クライアント端末装置１０１、１０２に対して、文書の印刷指示操作や、課金情報や集計先情報の変更操作等、各種指示をユーザが行う際に使用されるものである。

ディスプレイ２０７は表示手段であり、キーボード２０６から指示するための選択肢、設定画面、及び取得情報等を表示するものである。
システムバス２０８は、情報処理装置（クライアント端末装置１０１、１０２、データベースサーバ１０３、管理サーバ１０４）内のデータの流れを司るものである。
インターフェース２０９は、入出力手段である。情報処理装置は、このインターフェース２０９を介して外部装置とデータのやり取りを行う。

図３は、画像形成装置の一例であるＭＦＰ１０５及びネットワークプリンタ１０６の構成の一例を示すブロック図である。ＭＦＰ１０５は、ネットワークプリンタ１０６に比べ、スキャナ部とＦＡＸ部とが多いものの、本実施形態に要する構成は共通である。
図３において、ＣＰＵ３００は、画像形成装置の制御手段であり、ハードディスク（ＨＤ）３０３に格納されている印刷制御プログラム、アプリケーションプログラム、ＯＳ、及び前記ジョブログ管理プログラム等を実行する。更に、ＣＰＵ３００は、プログラムの実行に必要な情報や、ファイル等をＲＡＭ３０２に一時的に格納する制御を行う。

ＲＯＭ３０１は記憶手段であり、その内部には、機器制御プログラム、基本Ｉ／Ｏプログラム等のプログラムが記憶されている。ＲＡＭ３０２は一時記憶手段であり、ＣＰＵ３００の主メモリやワークエリア等として機能する。
ハードディスク（ＨＤ）３０３は外部記憶手段の一つであり、大容量メモリとして機能する。ハードディスク（ＨＤ）３０３は、アプリケーションプログラム、ＯＳ、前記ジョブログ管理プログラム、及び関連データ等を格納している。

画像形成部３０４は、ＨＤ３０３内にスプールデータとして保持されていたラスタデータがＲＡＭ３０２へ移されると起動する。画像形成部３０４は、ＲＡＭ３０２から読み出されたラスタデータに基づいて画像形成を行う。尚、ＲＡＭ３０２は図示を省略したバッテリにより電源がバックアップされ、各ユーザの印刷、スキャン、ＦＡＸ等のジョブログが必要に応じて、保存可能になっている。ただし、この保存メモリとして、ＲＡＭ３０２ではなく、例えばＥＥＰＲＯＭ等のほかの不揮発性メモリを使用してもよい.

クライアント端末装置１０１、１０２から送信されたジョブの一例である印刷ジョブは、インターフェース３０９及びシステムバス３０８を経由して伝送される。そして、ＣＰＵ３００の制御により、印刷要求が解析され、その内容に応じて、印刷ジョブがＲＡＭ３０２にラスタデータとして展開され、そのラスタデータがＨＤ３０３内にスプールデータとして格納される。

操作部３０６は指示入力手段であり、画像形成装置に対して、各種指示をユーザが行う際に使用されるものである。
表示部３０７は表示手段であり、操作部３０６に設定画面や取得情報等を表示するものである。
システムバス３０８は、画像形成装置内のデータの流れを司るものである。
インターフェース３０９は、入出力手段である。画像形成装置は、このインターフェース３０９を介して外部装置とデータのやり取りを行う。

スキャナ部３０５は、紙等のメディアの原稿に光をあて、その光の反射光をセンサーで読み取り、スキャンデータを生成し、生成したスキャンデータを、用途に応じて、ＨＤ３０３やＲＡＭ３０２に送る。
ＦＡＸ部３１０は、インターフェース３０９を介してＦＡＸデータの送受信を行う。スキャナ部３０５とＦＡＸ部３１０はＭＦＰ１０５に存在し、ネットワークプリンタ１０６には存在しない。よって、課金先や集計先といったジョブログの変更対象となるジョブの種類は、ネットワークプリンタ１０６ではプリントジョブのみである。これに対し、ＭＦＰ１０５では、プリントジョブに加え、スキャンジョブ、コピージョブ、及びＦＡＸジョブ等を、ジョブログの変更対象のジョブとすることが可能である。

図４は、情報処理装置及び画像形成装置におけるＲＡＭ２０２、３０２のメモリマップの一例を示す図である。ここでは、前記ジョブログ管理プログラムが、ＦＤ２０４からＲＡＭ２０２にロードされ実行可能となった状態のＲＡＭ２０２のメモリマップを例に挙げて示す。
図４において、装置の電源がＯＮされたときに、オペレーティングシステム（ＯＳ）４０２がＨＤ２０５からＲＡＭ２０２に読み出される。基本Ｉ／Ｏプログラム４０１はＯＳ４０２の動作を開始させるＩＰＬ（イニシャルプログラムローデイング）機能等を有しているプログラムが入っている領域である。
ジョブログ管理プログラム４０３と、ジョブログ管理プログラム４０３等の関連データ４０４は、ＲＡＭ２０２に確保される領域に記憶される。ワークエリア４０５には、ＣＰＵ２００がジョブログ管理プログラム４０３を実行するための領域が確保されている。

尚、本実施形態では、ジョブログ管理プログラム４０３及び関連データ４０４をＦＤ２０４からＲＡＭ２０２に直接ロードして実行させる場合を例に挙げて示す。しかしながら、これ以外の方法でジョブログ管理プログラム４０３及び関連データ４０４をロードするようにしてもよい。例えば、ジョブログ管理プログラム４０３を動作させる度に、ジョブログ管理プログラム４０３が既にインストールされているＨＤ２０５、３０３から、ジョブログ管理プログラム４０３をＲＡＭ２０２、３０２にロードするようにしてもよい。

また、ジョブログ管理プログラム４０３を記憶する記憶媒体は、ＦＤ２０４以外に、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＰＣカード、ＤＶＤ、ＩＣメモリカードであってもよい。更に、ジョブログ管理プログラム４０３をＲＯＭ２０１、３０１に記憶しておき、これをメモリマップの一部となすように構成し、ジョブログ管理プログラム４０３をＣＰＵ２００、３００で直接実行することも可能である。また、以上の各装置と同等の機能を実現するソフトウェアをもって、ハードウェア装置の代替とすることもできる。
更に、ジョブログ管理プログラム４０３において、サーバプログラムとクライアントプログラムとは別々に構成されるが、サーバプログラムを、クライアントＰＣであるクライアント端末装置１０１、１０２にインストールしても構わない。

図５は、図２に示したＦＤ２０４のメモリマップの一例を示す図である。
図５において、ＦＤ２０４に格納されているデータ５００の中には、データの情報を示すボリューム情報５０１と、ディレクトリ情報５０２と、ジョブログ管理プログラム５０３と、ジョブログ管理プログラム５０３の関連データ５０４とが含まれている。ジョブログ管理プログラム５０３は、本実施形態で説明するフローチャートに基づいてプログラム化したものである。

図６は、図２に示したＦＤドライブ２０３と、ＦＤドライブ２０３に対して挿入されるＦＤ２０４との関係の一例を示す図である。
図６において、ＦＤ２０４には、本実施形態で説明するジョブログ管理プログラム５０３及び関連データ５０４が格納されている。

図７は、本実施形態におけるジョブログ管理システムの機能構成の一例を示す図である。尚、課金と集計に関し、前者は金額についての、後者はページ数や枚数やポイント数についての（広義の）集計であることを指す。すなわち、課金と集計は、本質的には同等のものである。そこで、以下の説明では、課金（ジョブログの課金先を変更する場合）について説明するが、集計に関しても、以下に示す課金に関する処理と同じ処理が行われる。

印刷クライアントであるクライアント端末装置１０１、１０２では、ジョブログ管理プログラム４０３内のクライアントプログラムが作動している。ユーザは、変更ジョブ情報指定部７０１、変更結果表示部７０２、確認内容表示部７０３、及び確認内容選択部７０４等によりクライアント端末装置１０１、１０２に表示されたＵＩ（ユーザインターフェース）画面を見て、課金先の変更指示等の各種操作を行う。また、変更ジョブ情報指定部７０１によって指定された「課金先を変更する対象となるジョブ」と「変更データ」とに基づいて変更要求生成部７０６で課金先変更要求が生成される。生成された課金先変更要求は、変更要求送信部７０７によって、ネットワーク１０７を介して管理サーバ１０４に送信される。

この課金先変更要求に対する処理の結果は管理サーバ１０４から送信され、変更結果受信部７０９で受信される。また、課金先の変更が実行される前に、クライアントの実行確認を要する場合には、管理サーバ１０４からクライアント端末装置１０１、１０２に確認要求が送信される。この確認要求は、確認要求受信部７０８で受信される。管理サーバ１０４では、ジョブログ管理プログラム４０３、５０３内のサーバプログラムが作動している。クライアント端末装置１０１、１０２から送信された課金先変更要求が、変更要求受信部７１２で受信されると、ＤＢ検索部７１７は、その課金先変更要求を解析する。そして、ＤＢ検索部７１７は、解析した結果に基づいて、該当するジョブログ（課金先の変更する対象となるジョブのジョブログ）をデータベースサーバ１０３の中から検索する。検索した結果、該当するジョブログが見つからなかった場合、ＤＢ検索待機部７１６によって、所定の条件が満たされるまで処理が待機される。

一方、検索した結果、該当するジョブが見つかった場合は、ＤＢ変更部７１８により、該当するジョブログにおけるジョブの課金先を修正する。そして、以上のようにして行った課金先変更要求に対する処理の結果を、処理結果送信部７１４により、クライアント端末装置１０１、１０２に返信する。ジョブログを修正する前に、必要ならば確認要求送信部７１３で、クライアント端末装置１０１、１０２に確認要求を送信する。

また、ジョブログ保存部７１５は、クライアント端末装置１０１、１０２及びデバイス（ＭＦＰ１０５、ネットワークプリンタ１０６ｂ）のジョブログ収集部７１０、７２３、７２４から取得したジョブログを、データベースサーバ１０３に保存する。そして、取得したジョブログが、データベースサーバ１０３に保存されると、ＤＢ更新通知生成部７１９は、そのジョブログを収集したデバイスを特定するデバイス情報を、そのジョブログに付加して、ＤＢ更新通知を生成する。このＤＢ更新通知は、ＤＢ更新通知送信部７１１により、ＤＢ検索待機部７１６に送信される。ＤＢ検索待機部７１６は、ＤＢ更新通知を受信すると、ＤＢ更新通知に付加されているデバイス情報により示されるデバイスを、情報取得済デバイスとして取得情報保持部７２２に登録する。そして、例えば、管理サーバ１０４で管理する対象のデバイスの全てが情報取得済デバイスとして取得情報保持部７２２に登録されると、ＤＢ検索部７１７は、ＤＢ検索待機部７１６からの指示に基づき、該当するジョブの再検索を行う。

このように本実施形態では、管理サーバ１０４が、クライアント端末装置１０１、１０２及びデバイス（ＭＦＰ１０５、ネットワークプリンタ１０６ｂ）から取得したジョブログを、データベースサーバ１０３に保存し、ＤＢ更新通知を生成するようにしている。しかしながら、必ずしもこのようにする必要はない。例えば、クライアント端末装置１０１、１０２やデバイス（ＭＦＰ１０５、ネットワークプリンタ１０６ｂ）が、ジョブログをデータベースサーバ１０３に保存すると共に、ＤＢ更新通知を生成して管理サーバ１０４（ＤＢ検索待機部７１６）に送信してもよい。

また、管理サーバ１０４が、デバイスの次回のジョブログ取得時刻を管理している場合、待機時刻決定部７２０は、次の処理を行える。すなわち、待機時刻決定部７２０は、ジョブログ取得時刻取得部７２１を介して、管理サーバ１０４が管理している全てのデバイスの次回のジョブログ取得時刻を取得できる（第２の取得手段）。そして、待機時刻決定部７２０は、このデバイスの次回のジョブログ取得時刻を元に、ＤＢ検索待機部７１６で待機する時刻を決定する。具体的に、待機時刻決定部７２０は、デバイスの次回のジョブログ取得時刻に、データベースサーバ１０３に対するジョブログの更新処理に要する時間を加算した時刻を、ＤＢ検索待機部７１６で待機する時刻として決定する。

図７において、ジョブログ収集部７２３を有するデバイスであるＭＦＰ１０５は、管理サーバ１０４のジョブログ保存部７１５にジョブログを自発的に送信する。また、ジョブログ収集部７２４を有するが、ジョブログを管理サーバ１０４に自発的に送信する手段を持たないネットワークプリンタ１０６ｂは、ジョブログ保存部７１５から定期的に送信されるジョブログ送信要求の返信として、ジョブログを送信する。また、ジョブログ収集部を有さないネットワークプリンタ１０６ａのジョブログは、クライアント端末装置１０１、１０２側で生成される。具体的に、ネットワークプリンタ１０６ａからクライアント端末装置１０１、１０２の印刷部７０５に送信された情報をジョブログ収集部７１０が収集することにより、ジョブログが生成される。そして、ジョブログ収集部７１０は、生成したジョブログを、管理サーバ１０４のジョブログ保存部７１５に送信する。
以上がジョブログ管理システムにおける基本的な制御である。

図８は、ジョブログ管理プログラム４０３に含まれるクライアントプログラムにより実行される処理の一例を説明するフローチャートである。このクライアントプログラムは、クライアント端末装置１０１、１０２で動作する。尚、クライアント端末装置１０１、１０２の役割は同じであるので、ここでは、フローチャートに従い、クライアント端末装置１０１の処理を説明する。

まず、ジョブログ管理プログラム４０３の開始にあたって、クライアント端末装置１０１は、必要な初期化処理を行う（ステップＳ９０１）。この初期化処理には、変数の初期化や、各種要求を送受信するための通信設定の初期化等が含まれる。
次に、変更ジョブ情報指定部７０１は、ユーザによるメニュー押下等の操作に基づいて、課金先変更要求を検出したか否かを判定する（ステップＳ９０２）。この判定の結果、課金先変更要求を検出した（Ｙｅｓの）場合、変更ジョブ情報指定部７０１は、課金先変更依頼ＵＩを表示する（ステップＳ９０３）。

図９は、課金先変更依頼ＵＩの一例を示す図である。ユーザは、クライアント端末装置１０１を操作して、課金先変更依頼ＵＩ９０１に対して、課金先情報を変更したい元ジョブの情報を、分かる範囲で記入する。この課金先変更依頼ＵＩ９０１では、元ジョブを特定する情報として、以下の情報を表示している。
ジョブ種類（印刷／コピー／スキャン／ＦＡＸ等）
ドキュメント名
ジョブオーナー名
デバイス名
デバイスアドレス（ＩＰアドレス等）
ジョブ実行日時
課金対象（ユーザ／ユーザグループ（部門等）／ビリングコード）
課金データ（課金対象の値）

ここで、前記課金対象と前記課金データについて説明する。前記課金対象がユーザの場合には、ジョブ実行者（ジョブオーナー）の名前が課金データに指定されることが殆どである。前記課金対象がユーザグループの場合には、ジョブ実行者が属する部門等のグループの名前が課金データに指定される。また、図９に示すビリングコードとは、ジョブ実行者の顧客等、印刷代金の請求先に請求を行うための管理コードである。前記課金データは、図９に示す例のように、通常、何階層かの英数字の組み合わせとして表現される。また、図９に示す例では、元ジョブの特定情報を入力するのと同時に、変更データと動作設定の指定を可能にしている。ただし、変更データと動作設定を指定するタイミングはこのようなものに限定されない。例えば、ユーザへの実行確認を必ず実施する場合には、その実行確認を行うタイミングで変更データを指定してもよい。また、動作設定を行うタイミングについては、システムで固定でもよい。
以上のように本実施形態では、課金先変更依頼ＵＩ９０１における元ジョブを特定する情報（変更対象ジョブの情報）が、ジョブログを変更する対象のジョブの検索条件に対応し、変更データが、ジョブログの変更内容に対応する。更に、動作設定が、ジョブログの変更前確認の要否に対応する。また、デバイス名が、デバイス情報に対応し、ジョブ実行日時が、ジョブログを変更する対象のジョブの実行時刻に対応する。

ユーザは、この課金先変更依頼ＵＩ９０１で、課金先情報を変更したい元ジョブの情報の指定を行った後、ＯＫボタンを押下する。変更ジョブ情報指定部７０１は、この課金先変更依頼ＵＩ９０１のＯＫボタンがユーザによって押下されたか否かを判定する（ステップＳ９０４）。この判定の結果、課金先変更依頼ＵＩ９０１のＯＫボタンが押下された（Ｙｅｓの）場合には、変更要求生成部７０６は、課金先変更依頼を生成し（ステップＳ９０６）、生成した課金先変更依頼を管理サーバ１０４へ送信する（ステップＳ９０７）。そして、ステップＳ９０２に戻る。

一方、課金先変更依頼ＵＩ９０１のＯＫボタンが押下されていない（ステップＳ９０４でＮｏの）場合、変更ジョブ情報指定部７０１は、課金先変更依頼ＵＩ９０１のキャンセルボタンが押下されたか否かを判定する（ステップＳ９０５）。この判定の結果、課金先変更依頼ＵＩ９０１のキャンセルボタンが押下されていない（Ｎｏの）場合には、ステップＳ９０４に戻る。一方、キャンセルボタンが押下された（Ｙｅｓの）場合には、ステップＳ９０２に戻る。
以上のように本実施形態では、例えば、ステップＳ９０４の処理を行うことによって、第２の受付手段の一例が実現される。

ステップＳ９０２で、課金先変更要求を検出していないと判定された（Ｎｏの）場合、確認要求受信部７０８及び変更結果受信部７０９は、管理サーバ１０４からデータを受信したか否かを判定する（ステップＳ９０８）。この判定の結果、管理サーバ１０４からデータを受信した（Ｙｅｓの）場合、確認要求受信部７０８及び変更結果受信部７０９は、そのデータが、課金先の変更の確認要求であるか否かを判定する（ステップＳ９０９）。この確認要求は、ステップＳ９０７で送信した課金先変更依頼の応答として、必要ならば管理サーバ１０４から送信される。

この判定の結果、課金先の変更の確認要求を受信した（Ｙｅｓの）場合、確認内容表示部７０３は、課金先変更確認ＵＩを表示する（ステップＳ９１０）。図１０は、課金先変更確認ＵＩの一例を示す図である。課金先の変更を実行する前に確認を行う設定の場合、管理サーバ１０４は、データベースサーバ１０３の検索でヒットしたジョブを変更対象候補とする。そして、変更対象候補のジョブを示す情報を、課金先の変更の確認要求に含めて、クライアント端末装置１０１に送信する。図１０に示す課金先変更確認ＵＩ１００１には、データベースサーバ１０３の検索でヒットした２つジョブのドキュメント名、ジョブオーナー名、デバイス名、ジョブ開始時刻、課金対象、及び課金データ等が表示されている。
以上のように本実施形態では、例えば、ステップＳ９１０の処理を行うことによって、表示手段の一例が実現される。

そして、確認内容選択部７０４は、課金先変更確認ＵＩ１００１の変更実行ボタンがユーザによって押下されたか否かを判定する（ステップＳ９１１）。この判定の結果、課金先変更確認ＵＩ１００１の変更実行ボタンが押下された（Ｙｅｓの）場合、確認内容選択部７０４は、ユーザにより選択されたジョブの情報を取得する。そして、確認内容選択部７０４は、選択されたジョブのジョブログの変更を実行することを示す返信データを作成する（ステップＳ９１２）。
以上のように本実施形態では、例えば、ステップＳ９１１の処理を行うことによって、受付手段の一例が実現される。

一方、課金先変更確認ＵＩ１００１の変更実行ボタンが押下されていない（Ｎｏの）場合、確認内容選択部７０４は、課金先変更確認ＵＩ１００１の該当なしボタンがユーザによって押下されたか否かを判定する（ステップＳ９１４）。この判定の結果、課金先変更確認ＵＩ１００１の該当なしボタンが押下された（Ｙｅｓの）場合、確認内容選択部７０４は、変更対象がないことを示す返信データを作成する（ステップＳ９１５）。この場合、本実施形態では、後述するように、管理サーバ１０４は、データベースサーバ１０３の検索を再試行する。

一方、課金先変更確認ＵＩ１００１の該当なしボタンが押下されていない（Ｎｏの）場合、確認内容選択部７０４は、課金先変更確認ＵＩ１００１のキャンセルボタンがユーザによって押下されたか否かを判定する（ステップＳ９１６）。この判定の結果、課金先変更確認ＵＩ１００１のキャンセルボタンが押下されていない（Ｎｏの）場合には、ステップＳ９０２に戻る。一方、課金先変更確認ＵＩ１００１のキャンセルボタンが押下された（Ｙｅｓの）場合、確認内容選択部７０４は、変更依頼をキャンセルすることを示す返信データを作成する（ステップＳ９１７）。そして、変更要求送信部７０７は、ステップＳ９１２、Ｓ９１５、Ｓ９１７で生成された返信データを、管理サーバ１０４へ送信する（ステップＳ９１３）。そして、ステップＳ９０２に戻る。

ステップＳ９０９で、課金先の変更の確認要求を受信していない（Ｎｏの）場合、確認要求受信部７０８及び変更結果受信部７０９は、管理サーバ１０４から受信したデータが、課金先の変更結果であるか否かを判定する（ステップＳ９１８）。この判定の結果、課金先の変更結果である（Ｙｅｓの）場合には、変更結果表示部７０２は、課金先変更結果ＵＩを表示する（ステップＳ９１９）。

図１１は、課金先変更結果ＵＩの一例を示す図である。課金先変更結果ＵＩ１１０１は、課金先変更依頼に関する実行結果を表示したものである。図１１に示す課金先変更結果ＵＩ１１０１は、課金先の変更が正常に終了した場合の表示例であり、課金先の変更対象となるジョブの情報（変更対象ジョブ）と変更したデータ（変更データ）に関する情報とを表示している。

この他に、データベースサーバ１０３の検索の結果、該当するジョブが見つからなかった場合や、指定したデータの入力ミスがあった場合には、エラーの原因がエラー情報として管理サーバ１０４から送信される。よって、このような場合、変更結果表示部７０２は、そのエラー情報を含む課金先変更結果ＵＩを表示する。また、本実施形態では、クライアント側のネイティブＵＩとして、課金先変更結果ＵＩ１１０１を表示したが、必ずしもこのようにする必要はない。例えば、課金先の変更結果をメールで通知してもよい。メールで通知する場合には、課金先の変更依頼者のメールアドレスを管理サーバ１０４に予め登録しておくか、課金先変更依頼に返信先を指定することで、課金先の変更結果の通知先となるメールアドレスを管理サーバ１０４が特定できるようにしておく。
以上のように本実施形態では、例えば、課金先変更結果ＵＩ１１０１が、変更結果情報に対応し、ステップＳ９１９の処理を行うことによって、報知手段の一例が実現される。

変更結果表示部７０２は、課金先変更結果ＵＩ１１０１のＯＫボタンがユーザによって押下されたか否かを判定する（ステップＳ９２０）。この判定の結果、課金先変更結果ＵＩ１１０１のＯＫボタンが押下されていない（Ｎｏの）場合は、ＯＫボタンが押下されるまで待機する。一方、課金先変更結果ＵＩ１１０１のＯＫボタンが押下された（Ｙｅｓの）場合には、ステップＳ９０２に戻る。

次に、図１２を参照しながら、管理サーバ１０４の処理の一例を説明する。図１２は、ジョブログ管理プログラム４０３に含まれるサーバプログラムにより実行される処理の一例を説明するフローチャートである。このサーバプログラムは、管理サーバ１０４で動作される。
まず、管理サーバ１０４は、ジョブログ管理プログラム４０３の初期化に必要な初期化処理を行う（ステップＳ１００１）。そして、変更要求受信部７１２は、クライアント端末装置１０１から、課金先変更要求を検出したか否かを判定する（ステップＳ１００２）。この判定の結果、課金先変更要求を検出した場合には、要求クラスのインスタンスが作成され、シーケンシャルで一意な依頼ＩＤがインスタンス毎に採番される。依頼ＩＤとして、最後に採番された値（最新の依頼ＩＤ）Ｘが記憶される。依頼ＩＤは、新規に採番される度に１ずつインクリメントされる。

図１３は、要求クラスのインスタンスが持つメンバの一例を示す図である。
図１３において、依頼ＩＤメンバとrequestＩＤメンバは、課金先変更要求を一意に特定するのに使用される。statusメンバは、課金先変更要求の処理状態を管理するのに使用される。具体的にstatusメンバは、少なくとも、new（新規作成）と、waiting（データベースサーバ１０３の更新待ち）と、reply＿waiting（クライアント端末装置１０１からの返信待ち）との３種類の状態を管理するのに使用される。

replyCountメンバは、クライアント端末装置１０１から未返信の確認要求の数を管理するのに使用される。課金先の変更の確認要求をクライアント端末装置１０１に送信することで、replyCountメンバの値はインクリメントされる。一方、クライアント端末装置１０１から返信データを受信することで、replyCountメンバの値はデクリメントされる。
MaxWaitTimeメンバは、処理の最大待機時刻（ＤＢ検索待機部７１６における最大待機時間）を管理するのに使用される。本実施形態では、課金先の変更要求のタイムアウトチェックで、この最大待機時刻を利用している。しかしながら、データベースサーバ１０３の更新通知を管理サーバ１０４が取得できない環境では、データベースサーバ１０３を再検索する時刻として、この最大待機時刻を利用してもよい。

これらの他、クライアント端末装置１０１で指定された変更元のジョブを特定する（クライアント指定の変更元ジョブを特定する）ジョブ情報に関するメンバがある。更に、クライアント端末装置１０１で指定された課金先の変更データ（クライアント指定の課金先の変更データ）に関するメンバもある。
検索デバイスリストは、課金先の変更要求に基づく検索の対象となるデバイス毎に、デバイス検索情報DevSearchInfo（＝｛DeviceID（デバイスＩＤ），updateFlag（更新フラグ），result（検索結果）｝）を保持する。これにより、検索対象のデバイスと、検索の有無と、検索結果とを管理することができる。例えば、課金先の変更要求に基づく検索の対象となるデバイスの数が１個の場合は、検索デバイスリストに１個のDevSerchInfoが保持され、１０個の場合は、検索デバイスリストに１０個のDevSerchInfoが保持される。更新フラグupdateFlagは、ＯＦＦ（＝０）で初期化され、更新されるとＯＮ（＝１）となる。検索結果resultは、０で初期化され、検索に失敗したときにのみ値がFAILURE（＝−１）となる。
以降、以上のような要求クラスのインスタンスを、必要に応じて、単に「要求」と称する。

ステップＳ１００２で、課金先変更要求を検出した（Ｙｅｓの）場合は、ＤＢ検索部７１７は、依頼ＩＤを新規に採番する。すなわち、依頼ＩＤとして、最後に採番された値Ｘを１だけインクリメントする（ステップＳ１００３）。次に、ＤＢ検索部７１７は、課金先変更要求を解析し、値を抽出して新規の要求Ｒｘを作成する（ステップＳ１００４）。新規の要求Ｒｘの初期ステータスstatusはnew（新規作成）となる。また、クライアント端末装置１０１への確認要求のうち、返信のない確認要求の数を保持するreplyCountメンバの値を０とする。
次に、ＤＢ検索部７１７は、新規の要求Ｒｘを依頼リストに登録する（ステップＳ１００５）。この依頼リストは処理中の依頼を登録するリストであり、依頼の管理に利用される。図１４は、新規の要求Ｒｘを依頼リストに登録する方法の一例を説明するための図である。図１４に示すように、ステップＳ１００４で新規に生成された要求Ｒｘを、ステップＳ１００５で、依頼リスト１４０１に登録する。また、後述するように、課金先変更要求に対する処理結果をクライアント端末装置１０１に送信した後、処理した要求Ｒｘ´を依頼リスト１４０１から削除する。
次に、ＤＢ検索部７１７は、新規の要求Ｒｘに関し、ＤＢ検索処理を行う（ステップＳ１００６）。このＤＢ検索処理については、図１５を用いて後述する。尚、本実施形態では、例えば、ステップＳ１００６の処理を行うことによって、検索手段の一例が実現される。

ステップＳ１００２で、課金先変更要求を検出していない（Ｎｏの）場合、変更要求受信部７１２は、課金先の変更の確認要求に対する返信データを検出したか否かを判定する（ステップＳ１００７）。この判定の結果、課金先の変更の確認要求に対する返信データを検出した（Ｙｅｓの）場合、ＤＢ変更部７１８は、返信データを解析し、依頼ＩＤを特定する（ステップＳ１００８）。尚、特定した依頼ＩＤをＹとする。次に、ＤＢ変更部７１８は、依頼ＩＤがＹ（依頼ＩＤ＝Ｙ）である要求Ｒｙを依頼リスト１４０１から探す（ステップＳ１００９）。

次に、ＤＢ変更部７１８は、ステップＳ１００７で検出したと判定された返信データに、「変更実行」が指定されているか否かを判定する（ステップＳ１０１０）。この判定の結果、「変更実行」が指定されている（Ｙｅｓの場合）、ＤＢ変更部７１８は、データベースサーバ１０３の登録内容の変更を行うための変更式（例えばＳＱＬ文）を作成する（ステップＳ１０１１）。次に、ＤＢ変更部７１８は、作成したＳＱＬ文を用いて、データベースサーバ１０３への変更を実行する（ステップＳ１０１２）。このように本実施形態では、例えば、ステップＳ１０１２の処理を行うことによって、変更手段の一例が実現される。

次に、ＤＢ更新通知生成部７１９は、ステップＳ１０１２における実行結果から、クライアント端末であるクライアント端末装置１０１、１０２に通知するための結果情報（前述したＤＢ更新通知）を作成する（ステップＳ１０１３）。次に、処理結果送信部７１４は、該当するクライアント（クライアント端末装置１０１、１０２）に、ステップＳ１０１３で生成された結果情報（ＤＢ更新通知）を送信する（ステップＳ１０１６）。次に、ＤＢ変更部７１８は、要求Ｒｙを依頼リスト１４０１から削除する（ステップＳ１０１７）。そして、ステップＳ１００２に戻る。

ステップＳ１０１０で、「変更実行」が指定されていないと判定された（Ｎｏの）場合、ＤＢ変更部７１８は、ステップＳ１００７で検出したと判定された返信データに、「変更依頼のキャンセル」が指定されているか否かを判定する（ステップＳ１０１４）。この判定の結果、変更依頼のキャンセル」が指定されている（Ｙｅｓの）場合、ＤＢ更新通知生成部７１９は、実行結果をキャンセルとして、結果情報を生成（ステップＳ１０１５）する。次に、処理結果送信部７１４は、該当するクライアント（クライアント端末装置１０１、１０２）に、ステップＳ１０１５で生成された結果情報を送信する（ステップＳ１０１６）。次に、ＤＢ変更部７１８は、要求Ｒｙを依頼リスト１４０１から削除する（ステップＳ１０１７）。そして、ステップＳ１００２に戻る。

ステップＳ１０１４で、「変更依頼のキャンセル」が指定されていないと判定された（Ｎｏの）場合、ＤＢ変更部７１８は、ステップＳ１００７で検出したと判定された返信データに、「該当なし」が指定されているか否かを判定する。即ち、ＤＢ変更部７１８は、検索結果の中に、課金先の変更対象となるジョブが含まれないとユーザに確認されたか否かを判定する（ステップＳ１０１８）。この判定の結果、「該当なし」が指定されている（Ｙｅｓの）場合、ＤＢ変更部７１８は、replyCountを１だけデクリメントする（ステップＳ１０１９）。次に、ＤＢ変更部７１８は、replyCountが０であるか否かを判定する（ステップＳ１０２０）。この判定の結果、replyCountが０である（Ｙｅｓの）場合、ＤＢ変更部７１８は、次の処理を行う。すなわち、ＤＢ変更部７１８は、要求Ｒのstatus（属性）をreply＿waiting（クライアントからの返信待ち状態）から、waiting（ＤＢの更新による検索待ち状態）へ変更する（ステップＳ１０２１）。そして、ステップＳ１００２に戻る。一方、replyCountが０である（Ｙｅｓの）場合には、ステップＳ１０２１を省略してステップＳ１００２に戻る。

ステップＳ１００７で、課金先の変更の確認要求に対する返信データを検出していない（Ｎｏの）場合、ＤＢ更新通知生成部７１９は、依頼リスト１４０１を先頭から順次確認する。そして、ＤＢ変更部７１８は、時間切れ要求があるかを確認（タイムアウトをチェック）するために、変数Ｌを依頼リスト１４０１の登録要求数で初期化し、インデックス変数ｉを０で初期化（ｉ＝０）する（ステップＳ１０２２）。インデックス変数ｉは、依頼リスト１４０１を最後まで評価するためのインデックス変数であり、依頼リストの先頭の要素を０番目とする。

次に、ＤＢ更新通知生成部７１９は、インデックス変数ｉと変数Ｌとが等しくないか否かを判定する（ステップＳ１０２３）。この判定の結果、インデックス変数ｉと変数Ｌとが等しい（Ｎｏの）場合、即ち依頼リスト１４０１の最後まで評価した場合には、後述するステップＳ１０３１へ進む。一方、インデックス変数ｉと変数Ｌとが等しくない（Ｙｅｓの）場合、即ち依頼リスト１４０１の評価を終了していない場合、ＤＢ更新通知生成部７１９は、依頼リスト１４０１のｉ番目の要素である要求をＲｅとする（ステップＳ１０２４）。
次に、ＤＢ更新通知生成部７１９は、現在時刻を取得し、現在時刻と要求ＲｅのMaxWaitTimeメンバ（最大待機時刻）とを比較し、タイムアウトであるか否かを判定する（ステップＳ１０２５）。すなわち、現在時刻が、要求ＲｅのMaxWaitTimeメンバ（最大待機時刻）を経過しているか否かを判定する。この判定の結果、タイムアウトである（Ｙｅｓの）場合、ＤＢ更新通知生成部７１９は、要求Ｒｅのstatusメンバがwaitingであるか否かを判定する（ステップＳ１０２６）。

ステップＳ１０２５及びＳ１０２６でＮｏの場合、ＤＢ更新通知生成部７１９は、インデックス変数ｉを１だけインクリメントする（ステップＳ１０３０）。そして、ステップＳ１０２３へ戻る。
一方、ステップＳ１０２６でＹｅｓの（要求Ｒｅのstatusメンバがwaitingである）場合、ＤＢ更新通知生成部７１９は、タイムアウトとして処理するため、実行結果を「該当なし」として、結果情報を生成する（ステップＳ１０２７）。次に、処理結果送信部７１４は、該当するクライアント（クライアント端末装置１０１、１０２）に結果情報を送信する（ステップＳ１０２８）。次に、ＤＢ変更部７１８は、要求Ｒｅを依頼リスト１４０１から削除する（ステップＳ１０２９）。そして、ステップＳ１００２に戻る。

ステップＳ１０２３で、インデックス変数ｉと変数Ｌとが等しい場合には、ＤＢ検索部７１７は、デバイスＰに関するＤＢ更新通知を検出したか否かを判定する（ステップＳ１０３１）。この判定の結果、デバイスＰに関するＤＢ更新通知を検出していない（Ｎｏの）場合には、ステップＳ１００２に戻る。
一方、デバイスＰに関するＤＢ更新通知を検出した（Ｙｅｓの）場合、ＤＢ検索部７１７は、変数Ｌを依頼リスト１４０１の登録要求数で初期化すると共に、インデックス変数ｉを０で初期化（ｉ＝０）する。更に、ＤＢ検索部７１７は、デバイスＰのデバイスＩＤ（＝ＩＤｐ）を取得する（ステップＳ１０３２）。インデックス変数ｉは、ステップＳ１０２２で説明したのと同様に、依頼リスト１４０１を最後まで評価するためのインデックス変数であり、依頼リストの先頭の要素を０番目とする。

次に、ＤＢ検索部７１７は、インデックス変数ｉと変数Ｌとが等しくないか否かを判定する（ステップＳ１０３３）。この判定の結果、インデックス変数ｉと変数Ｌとが等しい（Ｎｏの）場合、即ち依頼リスト１４０１の最後まで評価した場合には、ステップＳ１００２に戻る。一方、インデックス変数ｉと変数Ｌとが等しくない（Ｙｅｓの）場合、即ち依頼リスト１４０１を最後まで評価していない場合、ＤＢ検索部７１７は、依頼リスト１４０１のｉ番目の要素である要求をＲｚとする（ステップＳ１０３４）。

次に、ＤＢ検索部７１７は、要求Ｒｚの検索デバイスリストに、DeviceID（デバイスＩＤ）がＩＤｐ（DeviceID＝ＩＤｐ）であるDevSearchInfoがあるか否かを判定する（ステップＳ１０３５）。この判定の結果、DevSearchInfoがない（Ｎｏの）場合には、ステップＳ１０３６〜Ｓ１０３８を省略して、後述するステップＳ１０３９に進む。一方、DevSearchInfoがある（Ｙｅｓの）場合、ＤＢ検索部７１７は、DeviceIDがＩＤｐであるDevSearchInfo（Infop）のupdateFlagメンバがＯＦＦであるか否かを判定する（ステップＳ１０３６）。この判定の結果、updateFlagメンバ（Infop->updateFlag）がＯＦＦでない（Ｎｏの）場合には、ステップＳ１０３７、Ｓ１０３８を省略して、後述するステップＳ１０３９に進む。

一方、updateFlagメンバ（Infop->updateFlag）がＯＦＦである（Ｙｅｓの）場合には、デバイスＰに関して、一度目の検索以降、データベースサーバ１０３に新しく格納された情報を検索していないと判断できる。よって、データベースサーバ１０３の検索が必要である。そこで、ＤＢ検索部７１７は、updateFlagメンバ（Infop->updateFlag）をＯＮにセットする（ステップＳ１０３７）。そして、ＤＢ検索部７１７は、要求Ｒｚ及びデバイスＰに関して、ＤＢ検索処理を行う（ステップＳ１０３８）。このＤＢ検索処理については、図１５を用いて後述する。尚、本実施形態では、例えば、ステップＳ１０３８の処理を行うことによって、再検索手段の一例が実現される。
そして、ＤＢ検索部７１７は、インデックス変数ｉを１インクリメントし（ステップＳ１０３９）、ステップＳ１０３３へ戻る。

次に、図１５のフローチャートを参照しながら、要求Ｒに対するＤＢ検索処理の一例を説明する。
まず、ＤＢ検索部７１７は、要求Ｒを解析し、ユーザが指定しているジョブの条件（ジョブの検索条件）を抽出する（ステップＳ１１０１）。ステップＳ１０３８のように、要求ＲにデバイスＰが特定されている場合がある、その場合、この処理の引数Ｄを、該当するデバイスのDeviceIDとする。一方、ステップＳ１００６のように、デバイスＰが特定されていない場合には、この引数Ｄは０（Ｄ＝０）となる。この引数Ｄが０でない場合は、検索ジョブ条件のデバイスに関する条件を、要求Ｒで指定されたデバイスに関係なく、Ｄと特定すればよい。ジョブの検索条件は、前述したように、例えば、ジョブ種類、オーナー名、実行日時、ドキュメント名、デバイス名、デバイスアドレス、課金ユーザ名、課金グループ名、及びビリングコード等のジョブ属性に対する、ユーザの指定値である。また、これらのジョブ属性は、データベースサーバ１０３の検索テーブル内の列名（ジョブログ）として保存されている。

次に、ＤＢ検索部７１７は、ステップＳ１１０１で抽出したデータから、データベースサーバ１０３に対する検索式（ＤＢ言語であるＳＱＬではSELECT文）を作成する（ステップＳ１１０２）。この検索式は、公知の一般的な技術であり、本発明の本質とは異なるため、詳細な説明を省略する。

次に、ＤＢ検索部７１７は、ステップＳ１１０２で作成した検索式により、データベースサーバ１０３から、検索条件に適合するジョブログを検索する（ステップＳ１１０３）。次に、ＤＢ検索部７１７は、検索条件を満たすジョブログがあるか否かを判定する（ステップＳ１１０４）。この判定の結果、検索条件を満たすジョブログがある（Ｙｅｓの）場合、ＤＢ検索部７１７は、検索時の動作設定を要求Ｒから取得する（ステップＳ１１０５）。本実施形態では、前述したように、ユーザ毎に動作設定を指定することが可能となるようにしているが、動作設定がシステムで固有の場合、要求Ｒがある度に動作設定を取得するのではなく、例えば、システムの初期化時に動作設定を取得することになる。

次に、ＤＢ検索部７１７は、ステップＳ１１０５で取得した動作設定に、変更前の確認を必ず実施する指定がなされているか否かを判定する（ステップＳ１１０６）。この判定の結果、変更前の確認が必ず必要でない（Ｎｏの）場合、ＤＢ検索部７１７は、変更前の確認を行うよう指定がなされているか否かを判定する（ステップＳ１１１１）。この判定の結果、変更前の確認が必要である（Ｙｅｓの）場合、ＤＢ検索部７１７は、候補が複数あるか否かを判定する（ステップＳ１１１２）。この判定の結果、候補が複数でない（Ｎｏの）場合には、後述するステップＳ１１１４に進む。

ステップＳ１１０６で、変更前の確認が必ず必要であると判定された（Ｙｅｓの）場合と、ステップＳ１１１２で、候補が複数であると判定された（Ｙｅｓの）場合、ＤＢ検索部７１７は、変更前の確認のための変更確認要求を生成する（ステップＳ１１０７）。次に、確認要求送信部７１３は、ステップＳ１１０７で生成された変更確認要求を、該当するクライアント端末（クライアント端末装置１０１、１０２）に送信する（ステップＳ１１０８）。

次に、ＤＢ検索部７１７は、replyCountをインクリメントする（ステップＳ１１０９）。次に、ＤＢ検索部７１７は、要求Ｒのstatusメンバをreply＿waitingに変更する（ステップＳ１１１０）。そして、ＤＢ検索処理を終了して、図１２のフローチャートに戻る。ステップＳ１１１１で、変更前の確認を行うよう必要がない（Ｎｏの）場合、ＤＢ検索部７１７は、変更前の確認をせずに変更する旨の指定がなされたか否かを判定する（ステップＳ１１１３）。この判定の結果、変更前の確認をせずに課金先を変更しない（Ｎｏの）場合には、後述するステップＳ１１１８に進む。

一方、変更前の確認をせずに課金先を変更する（Ｙｅｓの）場合、ＤＢ変更部７１８は、データベースサーバ１０３のデータを依頼通りに変更する（ステップＳ１１１４）。ＳＱＬではUPDATE文を生成し、ステップＳ１１１４の処理を実行する。これは一般的な技術であり、本発明の本質とは異なるため、詳細な説明を省略する。
次に、ＤＢ更新通知生成部７１９は、実行結果を成功として結果情報（前述したＤＢ更新通知）を生成する（ステップＳ１１１５）。次に、処理結果送信部７１４は、ステップＳ１１１５で生成された結果情報を、該当するクライアント端末（クライアント端末装置１０１、１０２）に送信する（ステップＳ１１１６）。そして、後述するステップＳ１１２０に進む。

ステップＳ１１０４で、検索条件を満たすジョブログがないと判定された（Ｎｏの）場合、ＤＢ検索部７１７は、要求Ｒが、データ指定等のエラーにより無効であるか否かを判定する（ステップＳ１１１７）。この判定の結果、要求Ｒがエラーにより無効である（Ｙｅｓの）場合、ＤＢ更新通知生成部７１９は、課金先変更依頼に対する返信として、適切なエラー情報を生成する（ステップＳ１１１８）。そして、処理結果送信部７１４は、ステップＳ１１１８で生成されたエラー情報を、該当するクライアント端末（クライアント端末装置１０１、１０２）に送信する（ステップＳ１１１９）。

次に、ＤＢ検索部７１７は、要求Ｒを依頼リスト１４０１から削除する（ステップＳ１１２０）。そして、ＤＢ検索処理を終了して、図１２のフローチャートに戻る。
ステップＳ１１１７で、要求Ｒが無効でないと判定された（Ｎｏの）場合、ＤＢ検索部７１７は、要求Ｒのstatusメンバがnewであるか否かを判定する（ステップＳ１１２１）。この判定の結果、要求Ｒのstatusメンバがnewである（Ｙｅｓの）場合、ＤＢ検索部７１７は、ユーザによる指定により、要求Ｒにデバイスが指定されているか否かを判定する（ステップＳ１１２２）。この判定の結果、要求Ｒにデバイスが指定されている（Ｙｅｓの）場合、待機時刻決定部７２０は、要求ＲのMaxWaitTimeメンバ（最大待機時刻）に、指定されたデバイスのジョブログ取得可能時刻を設定する（ステップＳ１１２３）。

このジョブログ取得可能時刻は、ジョブログ保存部７１５等、ジョブログの取得と受信に関わるモジュールで管理されている。待機時刻決定部７２０は、このモジュールに問い合わせることによりジョブログ取得可能時刻を取得する。ジョブログ取得可能時刻としては、例えば、要求Ｒに指定されているデバイスのジョブログが、データベースサーバ１０３で更新されたことを示すＤＢ更新通知が、ＤＢ検索待機部７１６で取得される時刻とすることができる。

次に、ＤＢ検索部７１７は、前述したDevSearchInfoを１つ生成する。このDevSearchInfoでは、DeviceIDを、指定されたデバイスのＩＤとし、updateFlagをＯＦＦとし、resultを０として初期化する。そして、ＤＢ検索部７１７は、生成したDevSearchInfoを、要求Ｒのメンバである検索デバイスリストに登録する（ステップＳ１１２４）。次に、ＤＢ検索部７１７は、要求Ｒのstatusメンバをwaitingに変更して、ＤＢ更新待ちとし（ステップＳ１１２５）、ＤＢ検索処理を終了して、図１２のフローチャートに戻る。

ステップＳ１１２２で、要求Ｒにデバイスが指定されていない（Ｎｏの）場合、待機時刻決定部７２０は、要求ＲのMaxWaitTimeメンバ（最大待機時刻）に、以下のようなジョブログ取得可能時刻を設定する（ステップＳ１１２６）。前述したように、ジョブログ取得可能時刻は、ジョブログ保存部７１５等、ジョブログの取得と受信に関わるモジュールで管理されている。待機時刻決定部７２０は、このモジュールに問い合わせることによりジョブログ取得可能時刻を取得する。そして、待機時刻決定部７２０は、管理サーバ１０４で管理される全デバイスのジョブログ取得可能時刻中で最も遅い時刻に、データベースサーバ１０３に対するジョブログの更新処理に要する時間を加算した時刻を、前記ジョブログ取得可能時刻として設定する。

尚、ステップＳ１１２６で設定されるジョブログ取得可能時刻は、このようなものに限定されない。例えば、デバイスのジョブログが、データベースサーバ１０３で更新されたことを示すＤＢ更新通知が取得され、そのＤＢ更新通知内のデバイス情報が、管理サーバ１０４で保持される場合には、以下の情報をジョブログ取得可能時刻にすることもできる。すなわち、全デバイスのデバイス情報が保持される時刻を、ジョブログ取得可能時刻にすることもできる。

次に、ＤＢ検索部７１７は、前述したDevSearchInfoを全デバイス数分生成する。これらのDevSearchInfoでは、DeviceIDを、指定されたデバイスのＩＤとし、updateFlagをＯＦＦとし、resultを０として初期化する。次に、ＤＢ検索部７１７は、生成したDevSearchInfoを、要求Ｒのメンバである検索デバイスリストに全て登録する（ステップＳ１１２７）。そして、前述したステップＳ１１２５に進み、要求Ｒのstatusメンバがwaitingに変更された後、図１２のフローチャートに戻る。

ステップＳ１１２１で、要求Ｒのstatusメンバがnewに等しくない（Ｎｏの）場合、ＤＢ検索部７１７は、要求Ｒのメンバである検索デバイスリストの中から、DeviceIDがＤであるDevSearchInfoを検索する。そして、ＤＢ検索部７１７は、その検索した結果resultをFAILURE（−１）として設定する（ステップＳ１１２８）。
次に、ＤＢ検索部７１７は、要求Ｒの依頼が失敗と確定されたか否かを判定する（ステップＳ１１２９）。具体的に説明すると、ＤＢ検索部７１７は、検索デバイスリストの全メンバを確認し、全てのDevSearchInfoのresultメンバがFAILUREならば失敗と確定できる。この判定の結果、要求Ｒの依頼が失敗と確定された（Ｙｅｓの）場合、ＤＢ更新通知生成部７１９は、実行結果を「該当なし」としてエラー情報を生成する（ステップＳ１１３０）。そして、前述したステップＳ１１１９に進み、該当するクライアント端末にエラー情報が送信される。一方、ステップＳ１１２９で、要求Ｒの依頼が失敗と確定されていない（Ｎｏの）場合は、他のデバイスに対するデータベースサーバ１０３の更新と再検索を待つ必要があるので、ＤＢ検索処理を終了して、図１２のフローチャートに戻る。

以上のように本実施形態では、課金先変更依頼ＵＩ９０１を用いて、課金先を変更するジョブの検索条件が指定されると、指定された検索条件に従って、課金先変更依頼が、クライアント端末装置１０１、１０２から管理サーバ１０４に送信される。課金先変更依頼を受信した管理サーバ１０４は、該当するジョブのジョブログを取得できるまで待機し、取得できたらジョブログの課金先の情報を変更し、変更した結果をユーザ（クライアント端末装置１０１、１０２）に送信するようにした。したがって、ジョブログがデータベース（データベースサーバ１０３）にない場合にも、ジョブログ（課金先情報や集計先情報）の変更依頼が可能になる。これにより、ジョブログを、出来るだけユーザが望むタイミングで変更することができ、ユーザの操作忘れ等を防止できるため、ユーザの利便性を向上させることができる。

尚、本実施形態では、課金先変更依頼ＵＩ９０１を用いて、ジョブログの変更データを設定するようにしたが、必ずしもこのようにする必要はない。例えば、課金先変更確認ＵＩ１００１において、課金先を変更するジョブログがユーザによって選択されると、そのジョブログの変更データを設定するＵＩを表示し、そのＵＩに対するユーザの入力操作に基づいて、ジョブログの変更データを設定してもよい。

また、管理サーバ１０４は、以下のような処理を行ってもよい。まず、管理サーバ１０４は、自身の管理対象の全てのデバイス（ジョブログ収集部７１０、７２３、７２４）から、最新のジョブログの取得時刻を取得する（第３の取得手段）。そして、課金先変更要求に、デバイス名やデバイスアドレス等のデバイスを特定するデバイス情報とジョブ実行日時とが含まれている場合、管理サーバ１０４は、次の処理を行う。すなわち、管理サーバ１０４は、前記デバイス情報により特定されるデバイスにおける最新のジョブログの取得時刻と、前記ジョブ実行日時とを比較し、比較した結果に基づいて、当該デバイスのジョブログが得られているか否かを判定する（第２の判定手段）。そして、当該デバイスのジョブログが得られていない場合には、最初の検索を行わないで、該当するジョブが見つからなかったこととして処理する。

また、本実施形態では、課金先変更確認ＵＩ１００１を表示させるか否かを、課金先変更依頼ＵＩ９０１を用いてユーザが設定するようにしたが、必ずしもこのようにする必要はない。例えば、課金先変更確認ＵＩ１００１を表示させるか否かを、システムで予め設定するようにしてもよい。尚、課金先変更確認ＵＩ１００１を表示させない場合に、複数のジョブログが検索された場合には、それら全てのジョブログを実行したり、それら全てのジョブログを実行せずに処理を終了したり、それら全てのジョブログの一部を実行したりすることを設定できる。

（第２の実施形態）
次に、本発明の第２の実施形態について説明する。前述した第１の実施形態では、管理サーバ１０４が、デバイス（ＭＦＰ１０５、ネットワークプリンタ１０６ｂ）又はクライアント端末装置１０１、１０２からジョブログを取得するタイミングまで、課金先変更要求（又は集計先変更要求）を待機するようにした。そして、管理サーバ１０４は、データベースサーバ１０３が更新されたタイミングでデータベースサーバ１０３の再検索を行うようにした。しかし、デバイスによっては、課金先変更要求（又は集計先変更要求）を受理したタイミングで、デバイスから最新のジョブログを取得しても課金・集計システム全体の動作に影響しない場合がある。また、課金先変更要求（又は集計先変更要求）の実行優先度が高いケースもあり得る。そこで、本実施形態では、課金先変更要求（又は集計先変更要求）を受理したタイミングでデバイスから最新のジョブログを強制的に取得する場合について説明を行い、前述した第１の実施形態と同一の部分についての詳細な説明を省略する。尚、本実施形態においても、第１の実施形態と同様に、課金に関する処理を説明し、集計に関する処理の説明を省略する。

図１６は、本実施形態における管理サーバ１０４の機能構成の一例を示す図である。本実施形態の管理サーバの機能構成は、図７に示した機能構成に、ジョブログ強制取得部８０１を加えたものとなる。ジョブログ強制取得部８０１は、管理サーバ１０４（変更要求受信部７１２）で課金先変更要求が受信された後に、クライアント端末装置１０１、１０２、ＭＦＰ１０５、及びネットワークプリンタ１０６ｂに、ジョブログ送信要求を送信する。
例えば、ＭＦＰ１０５のジョブログ収集部７２３は、管理サーバ１０４からジョブログ送信要求を受信すると、最新のジョブログを、管理サーバ１０４のジョブログ保存部７１５に対して送信する。ジョブログ保存部７１５は、取得した最新のジョブログを、データベースサーバ１０３に保存する。そして、この保存を検知したＤＢ検索部７１７が再検索を開始する。

図１７は、本実施形態におけるＤＢ検索処理の一例を説明するフローチャートである。尚、図１７では、図１５に示したＤＢ検索処理の一部分のみを示し、その他の部分を省略している。
ジョブログ強制取得部８０１が、クライアント端末装置１０１、１０２、ＭＦＰ１０５、ネットワークプリンタ１０６ｂのジョブログ収集部７１０、７２３、７２４に、ジョブログ送信要求を送信するタイミングは、図１７に示すようになる。すなわち、ステップＳ１１２２とステップＳ１１２３との間に行われるステップＳ１２０１と、ステップＳ１１２２とステップＳ１１２６との間に行われるステップＳ１２０２とで、ジョブログ送信要求が送信される。

クライアント端末装置１０１、１０２から送信された要求Ｒにデバイスが指定されている場合には、ステップＳ１２０１で、指定されたデバイスにジョブログ送信要求を送信する。一方、クライアント端末装置１０１、１０２から送信された要求Ｒにデバイスが指定されていない場合には、管理サーバ１０４が管理している（管理対象の）全てのデバイス／クライアント端末のジョブログ収集部にジョブログ送信要求を送信する。本実施形態では、クライアント端末装置１０１、１０２、ＭＦＰ１０５、ネットワークプリンタ１０６ｂのジョブログ収集部７１０、７２３、７２４に、ジョブログ送信要求を送信する。各デバイス／クライアント端末からのジョブログは、第１の実施形態と同様に、管理サーバ１０４のジョブログ保存部７１５に送信され、第１の実施形態と同様に処理される。
以上のように本実施形態では、例えば、ステップＳ１２０１、Ｓ１２０２の処理を行うことにより、取得手段の一例が実現される。

以上、本実施形態のように、課金先変更要求を受理したタイミングでデバイスやクライアント端末から最新のジョブログを取得する場合にも、第１の実施形態と同様の効果をあげることが可能となる。
尚、ステップＳ１２０１、Ｓ１２０２の処理を行うか否かを、デバイス又はシステム毎に設定できるようにしてもよい。

（第３の実施形態）
次に、本発明の第３の実施形態について説明する。本実施形態の説明においても、前述した第１及び第２の実施形態と同一の部分についての詳細な説明を省略する。
第１及び第２の実施形態では、セキュリティについて留意していない。このため、誰でも全ジョブの課金先変更操作ができてしまう。このため、本実施形態では、クライアント端末（クライアント端末装置１０１、１０２）から認証サーバで認証（ユーザのアクセス権の判定）を行い、その認証情報に基づいて、クライアント端末における課金先変更操作の可否を制御する。例えば、一般ユーザに対しては、ジョブオーナーが自分である場合や、課金先変更依頼における変更先が自分になっている場合にのみ操作を可能とする制御を行うことができる。管理者に対しては、全ての操作を可能にするといった制御を行うことができる。

（第４の実施形態）
次に、本発明の第４の実施形態について説明する。前述した第１の実施形態では、管理サーバ１０４は、デバイス（ＭＦＰ１０５、ネットワークプリンタ１０６ｂ）又はクライアント端末装置１０１、１０２からジョブログを取得するタイミングまで、課金先変更要求（又は集計先変更要求）を待機するようにした。そして、管理サーバ１０４は、データベースサーバ１０３が更新されたタイミングでデータベースサーバ１０３の再検索を行うようにした。そして、ユーザは、課金データを変更するジョブを、課金先変更依頼ＵＩ９０１を用いて入力及び指定するようにした。

しかしながら、このような第１の実施形態の構成では、ジョブの課金先（集計先）を変更する場合に、ユーザの手入力に頼る部分があるため、ユーザが入力ミスを行う可能性がある。そこで、第１の実施形態では、課金先変更確認ＵＩ１００１等を表示して変更するジョブを確認（修正）可能にしているが、必ずしも操作性が良いとはいえない。また、第１の実施形態では、管理サーバ１０４は、データベースサーバ１０３が更新されるまで待機してから再検索処理を行うため、管理サーバ１０４に負荷が集中する。

そこで、本実施形態では、クライアント端末装置１０１、１０２で実施した、スプーラのジョブからジョブ履歴のリスト（以下の説明では必要に応じてスプールジョブリストと称する）を作成して、ジョブ履歴ＵＩに表示する。そして、ユーザがそのスプールジョブリストによりジョブを指定できるようにする。更に、クライアント端末装置１０１、１０２側で課金先変更要求の待機及び再依頼を実施する。
以上のように本実施形態と前述した第１〜第３の実施形態とは、クライアント端末装置１０１、１０２が、スプーラのジョブの履歴を利用できることと、それに基づく処理等が主として異なる。したがって、本実施形態の説明においても、前述した第１から第３の実施形態と同一の部分についての詳細な説明を省略する。尚、本実施形態においても、第１の実施形態と同様に、課金に関する処理を説明し、集計に関する処理の説明を省略する。

図１８は、本実施形態におけるジョブログ管理システムの機能構成の一例を示す図である。
本実施形態のジョブログ管理システムの機能構成は、図７に示したものと比較して以下の点が異なる。
クライアント端末装置１０１、１０２の構成としては、図７に示したものから、確認内容表示部７０３、確認内容選択部７０４、及び確認要求受信部７０８が除かれる。一方、図７に示したものに対して、ＤＢジョブログ取得要求生成部１８０１、ＤＢジョブログ取得要求送信部１８０２、ＤＢジョブログ受信部１８０３、ジョブログ管理部１８０４、及びスプーラジョブログ管理部１８０６が加わる。
管理サーバ１０４の構成としては、図７に示したものから、ＤＢ更新通知送信部７１１、確認要求送信部７１３、ＤＢ検索待機部７１６、ＤＢ更新通知生成部７１９、待機時刻決定部７２０、ジョブログ取得時刻取得部７２１及び取得情報保持部７２２が除かれる。一方、ジョブログ取得要求受信部１８０７、及びジョブログ送信部１８０５が加わる。

本実施形態では、クライアント端末装置１０１、１０２側のプログラムの起動時に仕掛けたタイマ処理により、一定間隔でデータベースサーバ１０３に保存されたジョブログを管理サーバ１０４から取得する。尚、以下の説明では、データベースサーバ１０３に保存されたジョブログを必要に応じてＤＢジョブログと称する。ＤＢジョブログ取得要求生成部１８０１は、このタイマ処理に従って、データベースサーバ１０３に保存されたＤＢジョブログを取得するための要求（ＤＢジョブログ取得要求）を生成する。ＤＢジョブログ取得要求送信部１８０２は、この要求を管理サーバ１０４に送信する。この要求の結果として、ＤＢジョブログ受信部１８０３は、管理サーバ１０４からＤＢジョブログを受信する。受信したＤＢジョブログは、ジョブログ管理部１８０４に登録される。
尚、本実施形態では、前記タイマ処理に従ってＤＢジョブログを取得するようにしたが、ＤＢジョブログを取得するタイミングは任意でよい。

また、印刷部７０５は、クライアント端末装置１０１、１０２（スプーラ）で実施したジョブ情報を取得する。このジョブ情報は、スプーラジョブログとして、スプーラジョブログ管理部１８０６に登録される。更に、このジョブ情報は、ジョブログ管理部１８０４にもスプーラジョブログとして登録される。
このようにジョブログ管理部１８０４では、スプーラジョブログとＤＢジョブログとの双方をシームレスに管理する。
以上が本実施形態のジョブログ管理システムにおける基本的な制御である。

図１９は、本実施形態のジョブ履歴ＵＩの一例を示す図である。
図１９において、ジョブ履歴ＵＩ１９０１、１９０２では、ジョブオーナー（ユーザ）毎に、一定期間のジョブ履歴が表示される。ジョブ情報としては、ドキュメント名、クライアントＰＣ名、デバイス名、開始時刻、（ジョブ）ステータス、課金対象、及び課金データが表示される。また、ジョブ履歴ＵＩ１９０１、１９０２に表示するジョブオーナー名には、ＯＳ或いはジョブログ管理システムにログインしているユーザ名等が採用されて表示される。この場合、システム利用者に、自分の情報をジョブ履歴ＵＩ１９０１、１９０２で見せることが可能である。或いは、システム管理者には、第三者のジョブ履歴もジョブ履歴ＵＩ１９０１、１９０２で閲覧することが可能なように構成してもよい。

図２０は、本実施形態の課金データ変更ＵＩの一例を示す図である。第１の実施形態では、課金先情報を変更したい元ジョブの情報をユーザが分かる範囲で手入力する（図９を参照）。これに対し、本実施形態では、課金先を変更するジョブを、ジョブ履歴ＵＩ１９０１、１９０２からユーザが選択することで決定する。このため、本実施形態の課金データ変更ＵＩ２００１においてユーザが入力／選択するデータは、変更する部分の情報（変更する課金データの情報）だけとなる。

図２１は、本実施形態のジョブログ管理プログラム４０３に含まれるクライアントプログラムにより実行される処理の一例を説明するフローチャートである。このクライアントプログラムは、クライアント端末装置１０１、１０２で動作する。尚、クライアント端末装置１０１、１０２の役割は同じであるので、以下では、フローチャートに従い、クライアント端末装置１０１の処理を説明する。

まず、ジョブログ管理プログラム４０３の開始にあたって、クライアント端末装置１０１は、必要な初期化処理を行う（ステップＳ１９０１）。この初期化処理には、変数の初期化と、各種要求を送受信するための通信設定の初期化と、ジョブログ管理部１８０４及びスプーラジョブログ管理部１８０６の初期化等が含まれる。また、管理サーバ１０４からのＤＢジョブログの取得を定期的に実行するためのタイマ処理の初期化も実施する。

次に、印刷部７０５は、ネットワークプリンタ１０６ａで印刷が実行されたことを検出したか否かを判定する（ステップＳ１９０２）。この判定の結果、印刷が実行されたことが検出された（ＹＥＳの）場合、ステップＳ１９０３に進む。そして、印刷部７０５は、印刷を実行したジョブのジョブログのジョブ履歴ＵＩ１９０１、１９０２への表示と、データベースサーバ１０３から取得するジョブログとの一致判定とを行うのに十分な"ジョブの詳細情報"を、スプーラのジョブ情報として取得する。
ここで取得される主な情報は、図１９のジョブ履歴ＵＩ１９０１、１９０２に表示されているドキュメント名、クライアントＰＣ名、ジョブオーナー名、ジョブ開始時刻、課金対象、課金データ等である。また、ネットワークドメイン名等も必要に応じて取得される。
更に、以上のような表示用のデータだけではなく、次の情報等も取得される。すなわち、デバイス（ＭＦＰ１０５、ネットワークプリンタ１０６ｂ）から管理サーバ１０４を通じてデータベースサーバ１０３に格納されたＤＢジョブログと、スプーラジョブログとを一致させるためにジョブに設定されるジョブＩＤも取得される。更に、管理サーバ１０４への変更依頼結果を表す変更依頼結果コード等の内部データも取得される。
スプーラジョブログ管理部１８０６は、ステップＳ１９０３で取得されたスプーラのジョブ情報を、スプーラジョブログとして登録する（ステップＳ１９０４）。
次に、ジョブログ管理部１８０４は、スプーラジョブログを自身に登録するために、ジョブログ管理部１８０４におけるジョブ情報の初期化を行う（ステップＳ１９０５）。

ジョブログ管理部１８０４は、クライアント端末装置１０１で取得した"スプーラのジョブ情報（スプーラジョブログ）と、デバイスから管理サーバ１０４経由してデータベースサーバ１０３に登録されたＤＢジョブログとをシームレスに扱う。
本実施形態では、ジョブログ管理部１８０４は、管理しているジョブ情報に、ＤＢ登録ステータスとして、「ＤＢ登録待ち」及び「ＤＢ登録済」の何れが設定されているかを区別することにより、ユーザによる課金データの変更依頼時の処理を決定する。
更に、ジョブログ管理部１８０４は、管理しているジョブ情報に、変更依頼ステータスとして、「依頼なし」、「依頼待機中」、「変更中」、及び「変更完了」の何れが設定されているかを区別することにより、変更依頼処理の過程を管理する。その他、ジョブログ管理部１８０４は、ジョブ情報として、スプーラのジョブ情報のところで述べたような、スプーラジョブログとＤＢジョブログとの一致判定を行うのに十分なジョブの各種情報を管理する。また、ジョブログ管理部１８０４は、データベースサーバ１０３に登録済のジョブに対しては、データベースサーバ１０３でジョブを一意に特定することが可能なＤＢジョブＩＤも管理する。
ステップＳ１９０５では、ジョブログ管理部１８０４は、ＤＢ登録ステータスを「ＤＢ登録待ち」に設定すると共に、変更依頼ステータスを「依頼なし」に設定して、ジョブログ管理部１８０４におけるジョブ情報の初期化を行う。

そして、ジョブログ管理部１８０４は、ステップＳ１９０５で初期化したジョブ情報を登録する（ステップＳ１９０６）。
次に、クライアント端末装置１０１は、ジョブ履歴ＵＩ１９０１、１９０２の表示を実行するＵＩプロセスが起動中であるか否かを判定する（ステップＳ１９０７）。この判定の結果、ＵＩプロセスが起動中である（Ｙｅｓの）場合、クライアント端末装置１０１は、ＵＩプロセスを実行する処理部に、ジョブ情報の更新情報を通知する（ステップＳ１９０８）。ＵＩプロセスを実行する処理部は、例えば、変更ジョブ情報指定部７０１、変更結果表示部７０２、変更要求生成部７０６、変更要求送信部７０７、及びジョブログ管理部１８０４である。ＵＩプロセスを実行する処理部は、この更新情報の通知を受けて、ジョブ履歴ＵＩ１９０１、１９０２の表示を新しい情報に更新する。そして、前述したステップＳ１９０２に戻る。
一方、ステップＳ１９０７において、ＵＩプロセスが起動中でないと判定された（Ｎｏの）場合には、ステップＳ１９０８を省略して前述したステップＳ１９０２に戻る。

ステップＳ１９０２において、ネットワークプリンタ１０６ａで印刷が実行されたことを検出していないと判定された（Ｎｏの）場合には、ステップＳ１９０９に進む。そして、ジョブログ管理部１８０４は、ユーザによるジョブ履歴ＵＩ１９０１、１９０２の起動要求があるか否かを判定する（ステップＳ１９０９）。この判定の結果、ジョブ履歴ＵＩ１９０１、１９０２の起動要求がある（Ｙｅｓの）場合には、ジョブログ管理部１８０４は、ＵＩプロセスを実行する処理部を起動する（ステップＳ１９１０）。そして、ＵＩプロセス処理が実行される。このＵＩプロセス処理が実行されると、ステップＳ１９０２へ戻る。ＵＩプロセス処理の詳細については、図２２を参照しながら後述する。

一方、ステップＳ１９０９において、ジョブ履歴ＵＩ１９０１、１９０２の起動要求がないと判定された（Ｎｏの）場合には、ステップＳ１９１１に進む。そして、ＤＢジョブログ取得要求生成部１８０１は、ＤＢジョブログの取得を実行するタイマイベントが通知されたか否かを判定する（ステップＳ１９１１）。この判定の結果、ＤＢジョブログの取得を実行するタイマイベントが通知された（Ｙｅｓの）場合、ＤＢジョブログ取得要求生成部１８０１は、ジョブ履歴ＵＩ１９０１、１９０２に表示するユーザ名をジョブオーナー名として取得する。また、ＤＢジョブログ取得要求生成部１８０１は、ジョブログ管理部１８０４で既に取得されているＤＢジョブＩＤを取得する（ステップＳ１９１２）。

ＤＢジョブＩＤは、データベースサーバ１０３内で一意にインクリメンタルに採番されるＩＤであり、本実施形態では、既に取得したＤＢジョブログをデータベースサーバ１０３から重複して取得しないようにするために、このＤＢジョブＩＤが使用される。既に取得されたＤＢジョブログ中で最新のＤＢジョブＩＤ（即ち数の最も大きいＤＢジョブＩＤ）を記録しておく。そして、この最新のＤＢジョブＩＤの数に「１」を足したＤＢジョブＩＤ以降のＤＢジョブＩＤが付されているＤＢジョブログを取得すれば、ＤＢジョブログを重複して取得しないようにすることができる。
ＤＢジョブログ取得要求生成部１８０１は、この最新のＤＢジョブＩＤの数に「１」を足したＤＢジョブＩＤ以降のＤＢジョブＩＤが付されているＤＢジョブログと、ジョブオーナー名とを指定してＤＢジョブ履歴取得要求を生成する（ステップＳ１９１３）。ＤＢジョブログ取得要求送信部１８０２は、ステップＳ１９１３で生成されたＤＢジョブ履歴取得要求を管理サーバ１０４に送信する（ステップＳ１９１４）。そして、ステップＳ１９０２へ戻る。

ステップＳ１９１１において、ＤＢジョブログの取得を実行するタイマイベントが通知されていないと判定された（Ｎｏの）場合、受信部（変更結果受信部７０９、ＤＢジョブログ受信部１８０３）は、次の処理を行う。すなわち、受信部（変更結果受信部７０９、ＤＢジョブログ受信部１８０３）は、管理サーバ１０４から何らかのデータを受信したか否かを判定する（ステップＳ１９１５）。この判定の結果、管理サーバ１０４から何らかのデータを受信した（Ｙｅｓの）場合には、サーバデータ受信処理が行われる（ステップＳ１９１６）。このサーバデータ受信処理が終了すると、ステップＳ１９０２へ戻る。尚、このサーバデータ受信処理の詳細については、図２３を参照しながら後述する。一方、ステップＳ１９１５において、管理サーバ１０４から何もデータを受信していない（Ｎｏの）場合には、ステップＳ１９０２へ戻る。

次に、図２２のフローチャートを参照しながら、図２１のステップＳ１９１０のＵＩプロセス処理の一例を説明する。
本実施形態では、先に説明したクライアント端末装置１０１側メインフローのプロセス（図２１）と、ＵＩを起動するプロセスとを別のプロセスとして記載している。
まず、変更結果表示部７０２は、メインとなるジョブ履歴ＵＩ１９０１、１９０２の初期化を実施する（ステップＳ１９１７）。この初期化においては、変更ジョブ情報指定部７０１は、ジョブログ管理部１８０４から、ジョブ履歴ＵＩ１９０１、１９０２の初期化に必要な"スプールされているジョブのリスト"等のデータを取得する。また、本実施形態では、ジョブ履歴ＵＩ１９０１、１９０２の初期状態では、ジョブ選択なしになると共に、「課金データの変更」ボタンが無効化される。更に、ジョブログ管理部１８０４から取得した"スプールされているジョブのリスト"の各ジョブのうち、変更依頼ステータスが「依頼なし」となっているジョブ以外は、図１９（ｂ）に示すように情報マーク１９０３が表示されるようにしている。
尚、図１９（ａ）に示すジョブ履歴ＵＩ１９０１では、「ドキュメント取り扱い説明書・・・」が選択された例を示している。ここでは、課金データ変更依頼は実施されていないため、お知らせ情報には何も表示されていない。この状態で「課金データの変更」ボタンがユーザによって押下され、課金先変更依頼が実施されると、図１９（ｂ）に示すように、ジョブ履歴ＵＩ１９０２には情報マーク１９０３が表示される。また、管理サーバ１０４で課金先の変更処理が完了すると、その結果がクライアント端末装置１０１に通知される。そして、図１９（ｂ）に示すように、その通知に含まれる変更依頼結果コードに応じてお知らせ情報がジョブ履歴ＵＩ２１０１に表示される。

変更結果表示部７０２は、ステップＳ１９１７で初期化されたジョブ履歴ＵＩを表示する（ステップＳ１９１８）。次に、変更ジョブ情報指定部７０１は、ジョブ履歴ＵＩ上でジョブが選択されたか否かを判定する（ステップＳ１９１９）。この判定の結果、ジョブ履歴ＵＩ上でジョブが選択された（Ｙｅｓの）場合、変更ジョブ情報指定部７０１は、次の処理を行う。すなわち、変更ジョブ情報指定部７０１は、選択されたジョブに情報マーク１９０３が表示されているか（或いは選択されたジョブの変更依頼ステータスが「依頼なし」以外であるか）否かを判定する（ステップＳ１９２０）。
この判定の結果、選択されたジョブに情報マーク１９０３が表示されている（Ｙｅｓの）場合、即ち、情報マーク１９０３が表示されたジョブをユーザが選択した場合には、ステップＳ１９２１に進む。そして、変更結果表示部７０２は、ジョブ履歴ＵＩの下段の「お知らせ」情報に、変更依頼ステータス及び変更依頼結果コードに応じて、課金データ変更待機中や変更完了等を表すメッセージを表示する（ステップＳ１９２１）。また、ジョブが選択されたので、変更結果表示部７０２は、「課金データの変更」ボタンを有効化し（ステップＳ１９２２）、前述したステップＳ１９１９へ戻る。このように本実施形態では、例えば、ステップＳ１９２１の処理を行うことによって第２の表示手段の一例が実現される。
一方、ステップＳ１９２０において、選択されたジョブに情報マーク１９０３が表示されていない（Ｎｏの）場合には、ステップＳ１９２１を省略してステップＳ１９２２に進む。

ステップＳ１９１９において、ジョブ履歴ＵＩ上でジョブが選択されていないと判定された（Ｎｏの）場合、変更ジョブ情報指定部７０１は、ユーザによって「課金データの変更」ボタンが押下されたか否かを判定する（ステップＳ１９２３）。この判定の結果、「課金データの変更」ボタンが押下された（Ｙｅｓの）場合、変更結果表示部７０２は、課金データ変更ＵＩ２００１の初期化と表示を実施する（ステップＳ１９２４）。このように本実施形態では、例えば、ステップＳ１９２４の処理を行うことによって提示手段、第１の表示手段の一例が実現される。
この課金データ変更ＵＩ２００１の初期化に当たって、変更結果表示部７０２は、次の情報をジョブログ管理部１８０４から取得する。すなわち、変更結果表示部７０２は、ユーザが選択したジョブのドキュメント名、ジョブオーナー名、クライアントＰＣ名、デバイス名、ジョブ実行日時、（元の）課金対象、及び(元の)課金データ等をジョブログ管理部１８０４から取得する。この課金データ変更ＵＩ２００１の変更データの欄に表示される"課金対象と課金データ"の初期値は、其々元データとしたり、デフォルト値にしたりする等の構成が可能である。

次に、変更ジョブ情報指定部７０１は、ユーザの操作によって、課金データ変更ＵＩ２００１のＯＫボタンが押下されたか否かを判定する（ステップＳ１９２５）。この判定の結果、ＯＫボタンが押下された（Ｙｅｓの）場合、変更要求生成部７０６は、ユーザによって選択されたジョブのＤＢ登録ステータスをジョブログ管理部１８０４から取得する（ステップＳ１９２６）。次に、変更要求生成部７０６は、このＤＢ登録ステータスが「ＤＢ登録済」に等しいか否かを判定する（ステップＳ１９２７）。この判定の結果、ＤＢ登録ステータスが「ＤＢ登録済」に等しい（Ｙｅｓの）場合、変更要求生成部７０６は、課金先変更依頼を生成する（ステップＳ１９２８）。この課金先変更依頼には、ジョブログ管理部１８０４内で管理され、一意にジョブを決定可能なジョブＩＤが付加される。本実施形態では、この課金先変更依頼に対する返信時のデータに、このジョブログＩＤがＯＵＴＰＵＴデータとして含まれるようにすることで、返信されたデータが対象とするジョブを特定するための処理を簡易にする。次に、変更要求送信部７０７は、ステップＳ１９２８で生成された課金先変更依頼を管理サーバ１０４に送信する（ステップＳ１９２９）。次に、ジョブログ管理部１８０４は、該当するジョブの変更依頼ステータスを「変更中」に設定する（ステップＳ１９３０）。そして、ジョブログ管理部１８０４は、終了処理を行い、変更結果表示部７０２は、課金データ変更ＵＩ２００１をクローズする（ステップＳ１９３１）。これにより、ＵＩプロセス処理が終了する。

ステップＳ１９２５において、課金データ変更ＵＩ２００１のＯＫボタンが押下されていないと判定された（Ｎｏの）場合には、ステップＳ１９３２に進む。そして、変更ジョブ情報指定部７０１は、ユーザの操作によって、課金データ変更ＵＩ２００１のキャンセルボタンが押下されたか否かを判定する（ステップＳ１９３２）。この判定の結果、キャンセルボタンが押下された（Ｙｅｓの）場合には前述したステップＳ１９３１へ戻る。一方、キャンセルボタンが押下されていない（Ｎｏの）場合には前述したＳ１９２５へ戻る。
ステップＳ１９２７において、ＤＢ登録ステータスが「ＤＢ登録済」に等しくないと判定された（Ｎｏの）場合には、ステップＳ１９３３に進む。そして、ジョブログ管理部１８０４は、該当するジョブのジョブログの収集がクライアント端末装置１０１側で実施されており、且つそのジョブログが管理サーバ１０４に未送信であるか否かを判定する（ステップＳ１９３３）。このように本実施形態では、例えば、ステップＳ１９３３の処理を行うことによって判定手段の一例が実現される。この判定の結果、該当するジョブのジョブログの収集がクライアント端末装置１０１側で実施されており、且つそのジョブログが管理サーバ１０４に未送信である（Ｙｅｓの）場合には、ステップＳ１９３４に進む。この場合、クライアント端末装置１０１（ローカル）で管理しているジョブログの修正が可能であるため、ジョブログ管理部１８０４は、該当するジョブログの修正を実施する（ステップＳ１９３４）。次に、ジョブログ管理部１８０４は、該当するジョブの変更依頼ステータスを「変更完了」に設定する（ステップＳ１９３５）。そして、前述したステップＳ１９３１へ遷移する。
一方、ステップＳ１９３３において、該当するジョブのジョブログの収集がクライアント端末装置１０１側で実施されており、且つそのジョブログが管理サーバ１０４に未送信でない（Ｎｏの）場合には、ステップＳ１９３６に進む。そして、ジョブログ管理部１８０４は、該当するジョブの変更依頼ステータスを「依頼待機中」に設定し、課金データ変更ＵＩ２００１で指定された変更データをジョブ情報として保存する（ステップＳ１９３６）。そして、前述したステップＳ１９３１へ遷移する。

ステップＳ１９２３において、「課金データの変更」ボタンが押下されていないと判定された（Ｎｏの）場合、クライアント端末装置１０１のメインフローチャートから、ジョブ情報の更新情報が通知されたか否かを判定する（ステップＳ１９３７）。この更新情報の通知は、前述したステップＳ１９０８等により実施される。この判定の結果、更新情報が通知された場合、ジョブログ管理部１８０４は、この更新情報のデータを取得する（ステップＳ１９３８）。この更新情報のデータは、ジョブ履歴ＵＩ１９０１、１９０２、課金データ変更ＵＩ２００１に表示されているデータに対する変更分（差分）と、ジョブ履歴ＵＩ１９０１、１９０２、課金データ変更ＵＩ２００１の初期化に必要な全ての情報との何れでもよい。
次に、変更結果表示部７０２は、この更新情報のデータを用いて、ジョブ履歴ＵＩ１９０１、１９０２、課金データ変更ＵＩ２００１を更新する（ステップＳ１９３９）。そして、ステップＳ１９１９へ戻る。
ステップＳ１９３７において、更新情報が通知されていないと判定された（Ｎｏの）場合、変更ジョブ情報指定部７０１は、ユーザの操作によって、ジョブ履歴ＵＩ１９０１、１９０２の終了要求が検出されたか否かを判定する（ステップＳ１９４０）。この判定は、ジョブ履歴ＵＩ１９０１、１９０２に表示されているＯＫボタンが押下されたか否かによって実行される。この判定の結果、ジョブ履歴ＵＩ１９０１、１９０２に表示されているＯＫボタンが押下され、ジョブ履歴ＵＩ１９０１、１９０２の終了要求が検出された（Ｙｅｓの）場合には、前述したステップＳ１９３１へ遷移する。一方、ジョブ履歴ＵＩ１９０１、１９０２の終了要求が検出されていない（Ｎｏの）場合には、前述したステップＳ１９１９へ戻る。

次に、図２３のフローチャートを参照しながら、図２１のステップＳ１９１６のサーバデータ受信処理の一例を説明する。
変更結果受信部７０９は、管理サーバ１０４からデータを受信すると、そのデータが、課金先変更結果であるか否かを判定する（ステップＳ１９４１）。この判定の結果、課金先変更結果である（Ｙｅｓの）場合、ジョブログ管理部１８０４は、受信された課金先変更結果のデータを解析し、更新されたジョブのＩＤ（更新ジョブＩＤ＝Ｉｄｘ）を特定する（ステップＳ１９４２）。この更新ジョブＩＤは、前述のように課金先変更依頼時にＩＮ指定されていて（ステップＳ１９２８を参照）、返信データにも含まれているものとする。次に、ジョブログ管理部１８０４は、管理しているジョブＩＤがＩｄｘであるジョブを、管理サーバ１０４から送信されたデータで更新する（ステップＳ１９４３）。

更新データの内容は、課金先変更要求が正常に処理されたか否かを表すと共に、課金先変更要求が異常（エラー）の場合には、そのエラーの内容を表す変更依頼結果コードである。
次に、ジョブログ管理部１８０４は、ジョブ更新ジョブＩＤ（＝Ｉｄｘ）の変更依頼ステータスを「変更完了」に設定する（ステップＳ１９４４）。次に、クライアント端末装置１０１は、ＵＩプロセスが起動中であるか否かを判定する（ステップＳ１９４５）。この判定の結果、ＵＩプロセスが起動中である場合、クライアント端末装置１０１は、ＵＩプロセスを実行する処理部に、ジョブ情報の更新情報を通知する（ステップＳ１９４６）。前述したようにＵＩプロセスを実行する処理部は、例えば、変更ジョブ情報指定部７０１、変更結果表示部７０２、変更要求生成部７０６、変更要求送信部７０７、及びジョブログ管理部１８０４である。この更新情報を受けて、ジョブ履歴ＵＩ１９０１、１９０２上の「お知らせ」欄には、変更依頼結果のコードに従った"初期化したメッセージ"が表示される。例えば、課金先変更要求が正常に終了した場合は、変更依頼結果コードが０で表されることとし、その変更依頼結果コード（＝０）に対するお知らせ情報は、例えば、図１９（ｂ）に示すジョブ履歴ＵＩ１９０２に示すような情報とする。
尚、ステップＳ１９４５において、ＵＩプロセスが起動中でないと判定された（Ｎｏの）場合と、ステップＳ１９４６が終了した場合には、サーバデータ受信処理を終了する。

ステップＳ１９４１において、管理サーバ１０４から受信したデータが、課金先変更結果でない（Ｎｏの）場合、ＤＢジョブログ受信部１８０３は、管理サーバ１０４から、新規のＤＢジョブログを受信したか否かを判定する（ステップＳ１９４７）。この判定の結果、新規のＤＢジョブログを受信した場合、ジョブログ管理部１８０４は、受信されたＤＢジョブログのデータを解析し、新規のＤＢジョブログ数をＮとし、処理用変数ｎを０で初期化する（ステップＳ１９４８）。このように本実施形態では、例えば、ステップＳ１９４７でＤＢジョブログを受信する処理を実行することにより取得手段の一例が実現される。次に、ジョブログ管理部１８０４は、受信した"新規のＤＢジョブログＬｎ（ｎ＝０〜Ｎ）について、新規のジョブＩＤ（＝Ｉｄｙ）及びＤＢジョブＩＤを取得する（ステップＳ１９４９）。次に、ジョブログ管理部１８０４は、ジョブＩＤがＩｄｙであるジョブを既に登録しているか否かを判定する（ステップＳ１９５０）。この判定の結果、ジョブＩＤがＩｄｙであるジョブがジョブログ管理部１８０４に登録済みである場合には、図２１のステップＳ１９０２〜Ｓ１９０６で表したように、印刷部７０５でジョブが検知されている。一方、コピージョブのようにクライアント端末装置１０１ではなく、デバイス（例えばＭＦＰ１０５）で生成されたジョブは、ジョブログ管理部１８０４に登録されていない。

ステップＳ１９５０の判定の結果、ジョブＩＤがＩｄｙであるジョブを既に登録している（Ｙｅｓの）場合、ジョブログ管理部１８０４は、登録済みのジョブＩＤがＩｄｙのデータを、受信したジョブログのデータで更新する（ステップＳ１９５１）。更新するデータはＤＢジョブＩＤやステータス等である。一方、ステップＳ１９５０において、ジョブＩＤがＩｄｙであるジョブを登録していない（Ｎｏの）場合、ジョブログ管理部１８０４は、ジョブＩＤがＩｄｙのジョブの新規登録を行う（ステップＳ１９５２）。ステップＳ１９５１及びＳ１９５２が終了すると、ステップＳ１９５３に進む。そして、ジョブログ管理部１８０４は、処理中のＤＢジョブログＬｎのＤＢジョブＩＤが、最新のＤＢジョブＩＤより大きい場合、最新のＤＢジョブＩＤを、新規の（処理中の）ジョブログＬｎのＤＢジョブＩＤで更新する（ステップＳ１９５３）。

次に、ジョブログ管理部１８０４は、ジョブＩＤがＩｄｙのジョブのＤＢ登録ステータスを「ＤＢ登録済」に設定する（ステップＳ１９５４）。次に、ジョブログ管理部１８０４は、ジョブＩＤがＩｄｙのジョブの変更依頼ステータスが「依頼待機中」であるか否かを判定する（ステップＳ１９５５）。この判定の結果、ジョブＩＤがＩｄｙのジョブの変更依頼ステータスが「依頼待機中」である（Ｙｅｓの）場合、ステップＳ１９２８〜Ｓ１９３０と同様の処理を行う。すなわち、変更要求生成部７０６は、課金先変更依頼を生成し（ステップＳ１９５６）、変更要求送信部７０７は、課金先変更依頼を管理サーバ１０４へ送信する（ステップＳ１９５７）。このように本実施形態では、例えば、ステップＳ１９５７の処理を実行することにより依頼手段の一例が実現される。そして、ジョブログ管理部１８０４は、ジョブＩＤがＩｄｙの変更依頼ステータスを「変更中」に変更する（ステップＳ１９５８）。ここで、課金先変更依頼には、ジョブ情報として、ステップＳ１９３６で保存された変更データと、ステップＳ１９４９で取得したＤＢジョブＩＤとが含まれる。ここで、ＤＢジョブＩＤは、管理サーバ１０４及びデータベースサーバ１０３で変更データを特定するためのものである。次に、ジョブログ管理部１８０４は、処理用変数ｎをインクリメントし、インクリメントした処理用変数ｎが、新規のＤＢジョブログの数Ｎに等しいか否かを判定する。即ち、ジョブログ管理部１８０４は、全ての新規のジョブログの処理を終了したか否かを判定する（ステップＳ１９５９）。この判定の結果、全ての新規のジョブログの処理を終了した（Ｙｅｓの）場合には、前述したステップＳ１９４５へ遷移する。一方、全ての新規のジョブログの処理を終了していない（Ｎｏの）場合には、前述したステップＳ１９４９へ戻る。
尚、ステップＳ１９４７において、新規のＤＢジョブログを受信していないと判定された（Ｎｏの）場合には、その他の処理が適宜行われる（ステップＳ１９６０）。この処理は、本発明の本質とは無関係であるため、説明を省略する。ステップＳ１９６０の処理が終了した後、サーバデータ受信処理を終了する。

次に、図２４のフローチャートを参照しながら、管理サーバ１０４の処理の一例を説明する。
まず、管理サーバ１０４は、ジョブログ管理プログラム４０３の初期化に必要な初期化処理を行う（ステップＳ２００１）。そして、変更要求受信部７１２は、クライアント端末装置１０１から、課金先変更要求を検出したか否かを判定する（ステップＳ２００２）。この判定の結果、課金先変更要求を検出した（Ｙｅｓの）場合、ＤＢ変更部７１８は、検出された課金先変更要求を解析し、データベースサーバ１０３に格納されているジョブログを特定するＤＢジョブＩＤと、変更データとを取得する（ステップＳ２００３）。次に、ＤＢ変更部７１８は、この取得したデータを用いてＤＢ変更式を作成し（ステップＳ２００４）、作成したＤＢ変更式を用いて、データベースサーバ１０３への変更を実行する（ステップＳ２００５）。ＤＢ変更部７１８は、この実行結果に基づいて、クライアント端末装置１０１に返信する"課金先変更結果のデータ"を含む結果情報を作成する（ステップＳ２００６）。この課金先変更結果のデータには、前述した通り、ジョブログ管理部１８０４でジョブを特定するための更新ジョブＩＤと、変更依頼結果コードとを含む。変更依頼結果コードは、課金先変更要求が正常に処理されたか否かを表すと共に、課金先変更要求が異常（エラー）の場合には、そのエラーの内容を表すコードである。ステップＳ２００６の処理が終了すると、前述したステップＳ２００２へ戻る。

ステップＳ２００２において、課金先変更要求を検出していないと判定された（Ｎｏの）場合には、ステップＳ２００７に進む。そして、ジョブログ取得要求受信部１８０７は、データベースサーバ１０３に保存されたＤＢジョブログを取得するための要求（ＤＢジョブログ取得要求）を検出したかを判定する（ステップＳ２００７）。この判定の結果、ＤＢジョブログ取得要求を検出した（Ｙｅｓの）場合、ＤＢ検索部７１７は、検出されたＤＢジョブログ取得要求を解析し、ジョブオーナー名と、どのＤＢジョブＩＤ以降のジョブログを取得するかの指定とを取得する（ステップＳ２００８）。ＤＢ検索部７１７は、取得した情報に基づいて、"指定されたジョブオーナーの、指定されたＤＢジョブＩＤ以降のジョブ"を検索するためのＤＢ検索式を作成する（ステップＳ２００９）。ＤＢ検索部７１７は、作成したＤＢ検索式を用いて、データベースサーバ１０３への検索を実行する（ステップＳ２０１０）。次に、ＤＢ変更部７１８は、この実行結果に基づいて、ＤＢジョブログを含む結果情報を作成する（ステップＳ２０１１）。この結果情報にはジョブリストが含まれる。このジョブリストにおける各ＤＢジョブログの情報には、クライアント端末装置１０１側でジョブログ管理部１８０４に登録するに必要なジョブの詳細情報と、データベースサーバ１０３で管理されるＤＢジョブＩＤ等が含まれる。ステップＳ２０１１の処理が終了すると、前述したステップＳ２００２へ戻る。

以上のように本実施形態では、クライアント端末装置１０１は、データベースサーバ１０３に保存されているＤＢジョブログを管理サーバ１０４から取得する。そして、クライアント端末装置１０１は、取得したＤＢジョブログと、スプーラジョブログとをジョブ履歴ＵＩ１９０１、１９０２にシームレス（表示装置上の同じ画面）に表示する。ユーザは、このジョブ履歴ＵＩ１９０１、１９０２及び課金データ変更ＵＩ２００１を用いて、課金先を変更するジョブとそのジョブの変更内容とを指定する。クライアント端末装置１０１は、指定されたジョブを自身で管理している場合、指定された内容に従って、ジョブの変更を即時実行する。一方、クライアント端末装置１０１は、指定されたジョブを自身で管理していない場合、そのジョブのジョブログ（ＤＢジョブログ）の変更を管理サーバ１０４に依頼する。管理サーバ１０４は、この依頼に基づいて、データベースサーバ１０３に対して、指定されたジョブの課金先の変更を行い、その変更の結果をクライアント端末装置１０１に送信する。クライアント端末装置１０１は、その変更の結果を、ジョブ履歴ＵＩ１９０１、１９０２のお知らせ情報として表示する。
したがって、課金先を変更するためのユーザの操作を、前述した第１の実施形態よりも少なくすることができる。これにより、ユーザによる操作性を向上することができると共に、ユーザによる入力操作のミスを低減することができる。また、管理サーバ１０４への負荷を低減することができる。

（本発明の他の実施形態）
前述した本発明の実施形態におけるジョブログ管理システム、管理サーバ、クライアント端末装置を構成する各手段、並びにジョブログ管理方法の各ステップは、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。

また、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では、図８、図１２、図１５、図１７、図２１〜図２４に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接、あるいは遠隔から供給する。そして、そのシステムあるいは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

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

尚、前述した各実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

本発明の第１の実施形態を示し、ジョブログ管理システムの構成の一例を示すブロック図である。 本発明の第１の実施形態を示し、情報処理装置の構成を説明するブロック図である。 本発明の第１の実施形態を示し、画像形成装置の一例であるＭＦＰ及びネットワークプリンタの構成の一例を示すブロック図である。 本発明の第１の実施形態を示し、情報処理装置及び画像形成装置におけるＲＡＭのメモリマップの一例を示す図である。 本発明の第１の実施形態を示し、ＦＤのメモリマップの一例を示す図である。 本発明の第１の実施形態を示し、ＦＤドライブと、ＦＤドライブに対して挿入されるＦＤ２０４との関係の一例を示す図である。 本発明の第１の実施形態を示し、ジョブログ管理システムの機能構成の一例を示す図である。 本発明の第１の実施形態を示し、ジョブログ管理プログラムに含まれるクライアントプログラムにより実行される処理の一例を説明するフローチャートである。 本発明の第１の実施形態を示し、課金先変更依頼ＵＩの一例を示す図である。 本発明の第１の実施形態を示し、課金先変更確認ＵＩの一例を示す図である。 本発明の第１の実施形態を示し、課金先変更結果ＵＩの一例を示す図である。 本発明の第１の実施形態を示し、ジョブログ管理プログラムに含まれるサーバプログラムにより実行される処理の一例を説明するフローチャートである。 本発明の第１の実施形態を示し、図１２−１に続くフローチャートである。 本発明の第１の実施形態を示し、図１２−１に続くフローチャートである。 本発明の第１の実施形態を示し、要求クラスのインスタンスが持つメンバの一例を示す図である。 本発明の第１の実施形態を示し、新規の要求を依頼リストに登録する方法の一例を説明するための図である。 本発明の第１の実施形態を示し、要求に対するＤＢ検索処理の一例を説明するフローチャートである。 本発明の第１の実施形態を示し、図１５−１に続くフローチャートである。 本発明の第２の実施形態を示し、管理サーバ１０４の機能構成の一例を示す図である。 本発明の第２の実施形態を示し、ＤＢ検索処理の一例を説明するフローチャートである。 本発明の第４の実施形態を示し、ジョブログ管理システムの機能構成の一例を示す図である。 本発明の第４の実施形態を示し、ジョブ履歴ＵＩの一例を示す図である。 本発明の第４の実施形態を示し、課金先変更依頼ＵＩの一例を示す図である。 本発明の第４の実施形態を示し、ジョブログ管理プログラムに含まれるクライアントプログラムにより実行される処理の一例を説明するフローチャートである。 本発明の第４の実施形態を示し、ジョブログ管理プログラムに含まれるクライアントプログラムにより実行される処理の内、ＵＩプロセスの処理を説明するフローチャートである。 本発明の第４の実施形態を示し、ジョブログ管理プログラムに含まれるクライアントプログラムにより実行される処理の内、サーバデータ受信処理を説明するフローチャートである。 本発明の第４の実施形態を示し、ジョブログ管理プログラムに含まれるサーバプログラムにより実行される処理の一例を説明するフローチャートである。

符号の説明

１０１、１０２ クライアント端末装置
１０３ データベースサーバ
１０４ 管理サーバ
１０５ ＭＦＰ（複合機）
１０６ ネットワークプリンタ
２００、３００ ＣＰＵ
２０１、３０１ ＲＯＭ
２０２、３０２ ＲＡＭ
２０３ ＦＤドライブ（記憶媒体読み込み装置）
２０４ 記憶媒体（ＦＤ）
２０５、３０３ ＨＤ(ハードディスク)
２０６、３０６ 操作部
２０７、３０７ 表示部
２０８、３０８ システムバス
２０９、３０９ インターフェース
３０４ 画像形成部
３０５ スキャナ部
３１０ ＦＡＸ部

Claims (25)

1. デバイスで実施されたジョブに対するジョブログをデータベースで管理するジョブログ管理システムであって、
   前記ジョブログを変更する対象のジョブの検索条件がユーザによって指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索する検索手段と、
   前記検索手段により、前記検索条件に適合したジョブログが検索されなかった場合、前記ジョブログを管理するデータベースが更新されるまで待機した後、前記ユーザの再検索の指示を受けることなく前記検索条件に適合したジョブログを再検索する再検索手段と、
   前記検索条件に適合したジョブログが検索されると、ユーザによって指定された変更内容に従って、前記ジョブログを変更する変更手段と、
   前記変更手段により変更された結果に関わる変更結果情報をユーザに報知する報知手段とを有することを特徴とするジョブログ管理システム。
2. 前記変更する対象のジョブに対するユーザのアクセス権を判定する判定手段を有し、
   前記検索手段は、前記判定手段により、アクセス権があると判定された場合に、前記検索条件に適合したジョブログを検索することを特徴とする請求項１に記載のジョブログ管理システム。
3. 前記検索されたジョブログを表示装置に表示する表示手段と、
   前記表示手段によって表示されたジョブログの中から、変更を行うジョブログを、ユーザによる操作に基づいて受け付ける受付手段とを有し、
   前記変更手段は、前記受付手段によって受け付けられたジョブログを変更することを特徴とする請求項１又は２に記載のジョブログ管理システム。
4. 前記受付手段は、前記表示手段によって表示されたジョブログの中から、変更を行うジョブログを受け付けると共に、そのジョブログの変更内容を受け付け、
   前記変更手段は、前記受付手段によって受け付けられたジョブログを、前記受付手段によって受け付けられた変更内容で変更することを特徴とする請求項３に記載のジョブログ管理システム。
5. 前記ジョブログの変更依頼がなされる際に、前記ジョブログの変更前の確認の要否を、ユーザによる操作に基づいて受け付ける第２の受付手段を有し、
   前記表示手段は、前記第２の受付手段により、前記ジョブログの変更前確認が必要であることが受け付けられた場合に、前記検索されたジョブログを表示装置に表示することを特徴とする請求項３又は４に記載のジョブログ管理システム。
6. 前記検索条件に適合したジョブログが検索されなかった場合、前記デバイスからジョブログを取得する取得手段を有し、
   前記再検索手段は、前記取得手段により取得されたジョブログを含むジョブログの中から、前記検索条件に適合したジョブログを再検索することを特徴とする請求項１〜５の何れか１項に記載のジョブログ管理システム。
7. 前記検索手段は、前記ジョブログを変更する対象のジョブの検索条件と、そのジョブログの変更内容とがユーザによって指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索し、
   前記変更手段は、前記検索条件に適合したジョブログが検索されると、前記ジョブログの変更内容に従って、前記ジョブログを変更することを特徴とする請求項１〜６の何れか１項に記載のジョブログ管理システム。
8. 前記デバイスで実行されたジョブに関するジョブログを収集するジョブログ収集手段を有し、
   前記ジョブログの変更依頼には、前記ジョブログを変更する対象のジョブを実行したデバイスを特定するデバイス情報が含まれ、
   前記再検索手段は、前記ジョブログ収集手段により収集されたジョブログであって、前記デバイス情報により特定されるデバイスで実行されたジョブに基づくジョブログが、前記データベースに記憶され、前記データベースが更新されるまでは待機することを特徴とする請求項７に記載のジョブログ管理システム。
9. 前記ジョブログの次回の取得時刻を、管理対象の全てのデバイスについて取得する第２の取得手段を有し、
   前記ジョブログの変更依頼には、前記ジョブログを変更する対象のジョブを実行したデバイスを特定するデバイス情報が含まれ、
   前記再検索手段は、前記ジョブログの変更依頼に含まれるデバイス情報により特定されるデバイスについて前記第２の取得手段により取得された、前記ジョブログの次回の取得時刻が経過するまでは待機することを特徴とする請求項７に記載のジョブログ管理システム。
10. 前記ジョブログの次回の取得時刻を、管理対象の全てのデバイスについて取得する第２の取得手段を有し、
    前記再検索手段は、前記第２の取得手段により取得された時刻のうち、最も遅い時刻が経過するまでは待機することを特徴とする請求項７に記載のジョブログ管理システム。
11. 前記検索条件に適合したジョブログが検索されなかった場合に、所定の条件を満たすまで待機するか、デバイスからジョブログを取得するかの何れかの何れかを設定する設定手段を有し、
    前記再検索手段は、前記設定手段により設定された内容に従って、前記検索条件に適合したジョブログを再検索することを特徴とする請求項１〜１０の何れか１項に記載のジョブログ管理システム。
12. 前記ジョブログの最新の取得時刻を、管理対象の全てのデバイスについて取得する第３の取得手段と、
    前記デバイス情報により特定されるデバイスについて前記第３の取得手段により取得された時刻と、前記ジョブログを変更する対象のジョブの実行時刻とを比較した結果に基づいて、変更するジョブログが得られているか否かを判定する第２の判定手段とを有し、
    前記ジョブログの変更依頼には、前記ジョブログを変更する対象のジョブを実行したデバイスを特定するデバイス情報と、前記ジョブログを変更する対象のジョブの実行時刻を示す情報とが含まれ、
    前記検索手段は、前記第２の判定手段により、変更するジョブログが得られていないと判定された場合には、検索を実行せず、
    前記報知手段は、前記検索手段により検索が実行されなかった場合に、変更する対象のジョブが見つからなかったことをユーザに報知することを特徴とする請求項１〜１１の何れか１項に記載のジョブログ管理システム。
13. クライアント端末装置で実行が指示されたジョブに関するジョブログをクライアント端末装置が有する記憶媒体に記憶する記憶手段と、
    前記ジョブログの変更をユーザが指定する際に、前記記憶手段により記憶されたジョブログに関する情報を提示する提示手段とを有することを特徴とする請求項１〜１２の何れか１項に記載のジョブログ管理システム。
14. 前記提示手段は、前記検索されたジョブログと、クライアント端末装置で実行が指示されたジョブログとを表示装置上の同じ画面で表示することを特徴とする請求項１３に記載のジョブログ管理システム。
15. 前記提示手段により提示されたジョブログがユーザによって選択されると、ユーザに入力に応じて当該ジョブログの変更するための画面を表示装置に表示することを特徴とする請求項１４に記載のジョブログ管理システム。
16. デバイスで実施されたジョブに対するジョブログをデータベースで管理するジョブログ管理方法であって、
    前記ジョブログを変更する対象のジョブの検索条件が指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索する検索ステップと、
    前記検索ステップで前記検索条件に適合したジョブログが検索されなかった場合、前記ジョブログを管理するデータベースが更新されるまで待機した後、ユーザの再検索の指示を受けることなく前記検索条件に適合したジョブログを再検索する再検索ステップと、
    前記検索条件に適合したジョブログが検索されると、ユーザによって指定された変更内容に従って、前記ジョブログを変更する変更ステップと、
    前記変更ステップで変更された結果に関わる変更結果情報を報知する報知ステップとを有することを特徴とするジョブログ管理方法。
17. クライアント端末装置で実行が指示されたジョブに関するジョブログをクライアント端末装置が有する記憶媒体に記憶する記憶ステップと、
    前記ジョブログの変更をユーザが指定する際に、前記記憶ステップにより記憶されたジョブログに関する情報を提示する提示ステップとを有することを特徴とする請求項１６に記載のジョブログ管理方法。
18. 前記提示ステップは、前記検索されたジョブログと、クライアント端末装置で実行が指示されたジョブログとを表示装置上の同じ画面で表示することを特徴とする請求項１７に記載のジョブログ管理方法。
19. 前記提示ステップにおいて提示されたジョブログがユーザによって選択されると、ユーザに入力に応じて当該ジョブログの変更するための画面を表示装置に表示することを特徴とする請求項１８に記載のジョブログ管理方法。
20. ネットワークを介して接続されたデバイスで実施されたジョブに対するジョブログを管理する管理サーバであって、
    前記デバイスから取得したジョブログを格納するデータベースと、
    前記ジョブログを変更する対象のジョブの検索条件がユーザによって指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索する検索手段と、
    前記検索手段により、前記検索条件に適合したジョブログが検索されなかった場合、前記ジョブログを管理するデータベースが更新されるまで待機した後、前記ユーザの再検索の指示を受けることなく前記検索条件に適合したジョブログを再検索する再検索手段と、 前記検索条件に適合したジョブログが検索されると、ユーザによって指定された変更内容に従って、前記ジョブログを変更する変更手段と、
    前記変更手段により変更された結果に関わる変更結果情報をユーザに報知するためクライアント端末装置に対して送信する送信手段とを有することを特徴とする管理サーバ。
21. デバイスに対してジョブの実行を指示するクライアント端末装置であって、
    外部のデータベースに記憶されているジョブログを取得する取得手段と、
    前記データベースから取得されたジョブログと、前記実行を指示したジョブに対応するジョブログとを表示装置上の同じ画面で表示する第１の表示手段と、
    前記第１の表示手段により表示された画面で前記実行を指示したジョブに対応するジョブログがユーザにより選択され、かつ前記データベースに当該ジョブログが記憶されていない場合、ユーザによる操作の内容に基づき、当該ジョブログを変更する変更手段と、
    前記第１の表示手段により表示された画面で前記データベースから取得されたジョブログがユーザにより選択された場合、または前記第１の表示手段により表示された画面でユーザにより選択されたジョブログが前記データベースに記憶されている場合、ユーザによる操作の内容に基づくジョブログの変更を、前記データベースに記憶されているジョブログを管理する管理サーバに依頼する依頼手段と、
    前記依頼手段により依頼されたジョブログの変更の結果を前記管理サーバから受け付ける受け付け手段と、
    前記変更手段によりジョブログが変更された場合と、前記受け付け手段によりジョブログの変更が受け付けられた場合に、前記変更の内容に関する情報を表示装置に表示する第２の表示手段とを有することを特徴とするクライアント端末装置。
22. ネットワークを介して接続されたデバイスで実施されたジョブに対するジョブログを格納するためのデータベースを有する管理サーバにおけるジョブログ管理方法であって、
    前記ジョブログを変更する対象のジョブの検索条件がユーザによって指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索する検索ステップと、
    前記検索ステップで、前記検索条件に適合したジョブログが検索されなかった場合、前記ジョブログを管理するデータベースが更新されるまで待機した後、前記ユーザの再検索の指示を受けることなく前記検索条件に適合したジョブログを再検索する再検索ステップと、
    前記検索条件に適合したジョブログが検索されると、ユーザによって指定された変更内容に従って、前記ジョブログを変更する変更ステップと、
    前記変更ステップで変更された結果に関わる変更結果情報をユーザに報知するためクライアント端末装置に対して送信する送信ステップとを有することを特徴とするジョブログ管理方法。
23. デバイスに対してジョブの実行を指示するクライアント端末装置におけるジョブログ管理方法であって、
    外部のデータベースに記憶されているジョブログを取得する取得ステップと、
    前記データベースから取得されたジョブログと、前記実行を指示したジョブに対応するジョブログとを表示装置上の同じ画面で表示する第１の表示ステップと、
    前記第１の表示手段により表示された画面で前記実行を指示したジョブに対応するジョブログがユーザにより選択され、かつ前記データベースに当該ジョブログが記憶されていない場合、ユーザによる操作の内容に基づき、当該ジョブログを変更する変更ステップと、
    前記第１の表示ステップにおいて表示された画面で前記データベースから取得されたジョブログがユーザにより選択された場合、または前記第１の表示手段により表示された画面でユーザにより選択されたジョブログが前記データベースに記憶されている場合、ユーザによる操作の内容に基づくジョブログの変更を、前記データベースに記憶されているジョブログを管理する管理サーバに依頼する依頼ステップと、
    前記依頼ステップにより依頼されたジョブログの変更の結果を前記管理サーバから受け付ける受け付けステップと、
    前記変更ステップによりジョブログが変更された場合と、前記受け付けステップによりジョブログの変更が受け付けられた場合に、前記変更の内容に関する情報を表示装置に表示する第２の表示ステップとを有することを特徴とするジョブログ管理方法。
24. ネットワークを介して接続されたデバイスで実施されたジョブに対するジョブログを格納するためのデータベースを備える管理サーバにおけるジョブログ管理ステップをコンピュータに実行させるためのコンピュータプログラムであって、
    前記ジョブログを変更する対象のジョブの検索条件がユーザによって指定され、ジョブログの変更依頼がなされると、前記検索条件に適合したジョブログを前記データベースから検索する検索ステップと、
    前記検索ステップで、前記検索条件に適合したジョブログが検索されなかった場合、前記ジョブログを管理するデータベースが更新されるまで待機した後、前記ユーザの再検索の指示を受けることなく前記検索条件に適合したジョブログを再検索する再検索ステップと、
    前記検索条件に適合したジョブログが検索されると、ユーザによって指定された変更内容に従って、前記ジョブログを変更する変更ステップと、
    前記変更ステップで変更された結果に関わる変更結果情報をユーザに報知するためクライアント端末装置に対して送信する送信ステップとをコンピュータに実行させることを特徴とするコンピュータプログラム。
25. デバイスに対してジョブの実行を指示するクライアント端末装置におけるジョブログ管理ステップをコンピュータに実行させるためのコンピュータプログラムであって、
    外部のデータベースに記憶されているジョブログを取得する取得ステップと、
    前記データベースから取得されたジョブログと、前記実行を指示したジョブに対応するジョブログとを表示装置上の同じ画面で表示する第１の表示ステップと、
    前記第１の表示ステップにより表示された画面で前記実行を指示したジョブに対応するジョブログがユーザにより選択され、かつ前記データベースに当該ジョブログが記憶されていない場合、ユーザによる操作の内容に基づき、当該ジョブログを変更する変更ステップと、
    前記第１の表示ステップにより表示された画面で前記データベースから取得されたジョブログがユーザにより選択された場合、または前記第１の表示ステップにより表示された画面でユーザにより選択されたジョブログが前記データベースに記憶されている場合、ユーザによる操作の内容に基づくジョブログの変更を、前記データベースに記憶されているジョブログを管理する管理サーバに依頼する依頼ステップと、
    前記依頼ステップにより依頼されたジョブログの変更の結果を前記管理サーバから受け付ける受け付けステップと、
    前記変更ステップによりジョブログが変更された場合と、前記受け付けステップによりジョブログの変更が受け付けられた場合に、前記変更の内容に関する情報を表示装置に表示する第２の表示ステップとをコンピュータに実行させることを特徴とするコンピュータプログラム。

Images