JP5169756B2 - ジョブログ処理装置およびプログラム - Google Patents

Description

この発明は、ジョブログ処理装置およびプログラムに関する。

複写機、プリンタ等について、ジョブログを集計して課金単位の総量をユーザ単位、部門単位で管理することが行われている。例えば、図１に示すように、管理者等の計算機環境で実行される集計サービスＳ１が通信ネットワークを介して各デバイス（複写機、プリンタ等）からジョブログファイルＦを収集し、利用者情報Ｔを表引きして部門別の管理レポートＲを生成するようになっている。この例では集計対象は複写機等の面数である。ところで、このような集計作業では、機密情報の管理等の観点から、異動情報を正確に含む人事データベース等を直接に参照するのではなく、ユーザと部門との間の固定された対応関係を参照して行っていた。この対応関係は、月、四半期、年単位で更新される。このため、組織変更が頻繁に行われる環境においては部門集計が正確には行われない。すなわち、図１の例では、集計期間内に組織変更があった場合などでも、あるユーザが属する部門は１つに限られるため、当該部門は変更前の部門または変更後の部門のいずれか一方である（複数回の異動があった場合に中間的な部門の場合もある）。利用者情報ファイル内の情報が最新情報（変更後の情報）であると、集計期間内のそのユーザに部門異動が合った場合でも、異動前の部門に集計されず、常に最新の部門に計上される。あるいは、集計作業時点で、利用者情報ファイル内の情報が古いと、本来、異動後の部門に集計すべきものが異動前の部門に集計される。

特許文献１は、部門コードは変更されず、部門名のみが変更された場合でも、部門名別のログ情報を認識でき、データサイズの低減化が図ることを提案している。この提案では、新規登録された部門情報を格納する部門テーブルと変更された部門情報を格納する部門変更テーブルがあり、これらのテーブル情報を用いて、ジョブログ出力時に、ジョブログ内の部門コードを部門名に置き換えて、出力させている。

特許文献２は、利用者ＩＤと部門ＩＤの対応付けのテーブルは用意して、利用者ＩＤを部門ＩＤに変換して、部門毎のコピー枚数を管理することを提案している。
特開２００４−３１８７０１号公報 特開２００５−２７１３１７号公報

ジョブを依頼したユーザとジョブの実行時における当該ユーザの所属部門との対応関係を求める場合、ジョブの実行の度にユーザの所属部門の情報を取得する方法では、ジョブの実行回数分、ユーザの所属部門の情報を取得する必要がある。
一方、ある期間に蓄積されたジョブログにもとづき、複数のジョブについてまとめて、当該ジョブを依頼したユーザとジョブの実行時における当該ユーザの所属部門との対応関係を求めようとする場合、当該期間後にユーザの所属部門を取得するだけでは、当該期間内に当該ユーザの所属部門が変化していると、ジョブの実行時におけるユーザの所属部門は把握できない。
この発明は、ジョブの実行の度に当該ジョブを依頼したユーザの所属部門の情報を取得しなくても、ジョブを依頼したユーザと当該ユーザのジョブ実行時における所属部門との対応関係を得ることのできるジョブログ処理技術を提供することを目的としている。

［請求項１］
請求項１の発明によれば、ログジョブ処理装置に：ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段と；収集した上記ジョブログを記憶するジョブログ記憶手段と；ユーザの所属部門の情報を記憶する所属情報記憶手段と；異動情報に基づいて上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段と；チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む時期、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段と；上記ユーザ異動履歴レコードを記憶する異動履歴レコード記憶手段と；上記ジョブログの各々について、上記ユーザ異動履歴レコードに基づいて、当該ジョブログの集計対象情報を上記ユーザの属する所属部門に対応づける対応づけ手段と；上記ユーザ異動履歴レコードを生成するまえに、当該ユーザ異動履歴レコードのそれぞれの元になるジョブログが示すジョブの実行時刻を含む日付より遅い日付の部門異動に関する異動情報を上記所属情報記憶手段に反映させないように上記更新手段を制御する制御手段とを設けるようにしている。
［請求項２］
請求項２の発明によれば、ジョブログ処理装置に：ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段と；収集した上記ジョブログを記憶するジョブログ記憶手段と；ユーザの所属部門の情報を記憶する所属情報記憶手段と；異動情報に基づいて上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段と；チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む時期、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段と；上記ユーザ異動履歴レコードを記憶する異動履歴レコード記憶手段と；上記ジョブログの各々について、上記ユーザ異動履歴レコードに基づいて、当該ジョブログの集計処理対象情報を上記ユーザの属する所属部門に対応づける対応づけ手段と；上記ユーザ異動履歴レコードを生成した後に、当該ユーザ異動履歴レコードのそれぞれの元になるジョブログが示すジョブの実行時刻を含む日付より遅い日付の部門異動に関する異動情報を上記所属情報記憶手段に反映させることを許可するように上記更新手段を制御する制御手段とを設けるようにしている。
［請求項３］
請求項３の発明によれば、請求項１または２記載のジョブログ処理装置において、上記レコード生成手段は、前日に実行されたジョブログについて上記異動履歴レコードを生成し、上記制御手段は、異動情報の異動日付が到達し、さらに上記レコード生成手段が前日に実行されたジョブログについて上記異動履歴レコードを生成終了している場合に、上記更新手段が上記異動情報に基づいてユーザの所属部門の情報を更新するように上記更新手段を制御するようにしている。
［請求項４］
請求項４の発明によれば、請求項１〜３のいずれかに記載のジョブログ処理装置において、上記レコード生成手段は、上記ジョブログに含まれるユーザの識別子が示すユーザが当該ジョブの実行時刻において所属している所属部門が前回参照したときと異なる場合に、上記ユーザ異動履歴レコードを生成するようにしている。
［請求項５］
請求項５の発明によれば、請求項１〜４のジョブログ処理装置において、上記所属情報記憶手段は、下位の部門が直接的に属する上位の部門の情報をさらに記憶し、上記対応づけ手段は、日単位で、部門ごとに上記ジョブログの集計対象情報の集計を行い、日付、当該部門の識別情報、および集計値を含む日単位部門集計レコードを生成し、当該日単位部門集計レコードの各々について、当該部門の識別子、当該日付、および、当該部門の上位所属部門の情報を含む部門異動履歴レコードを生成し、さらに、上記日単位部門集計レコードの各々について、上記部門異動履歴レコードに基づいて、当該日単位部門集計レコードの集計値を上記部門の属する所属部門に累積して当該所属部門の集計値を生成するようにしている。
［請求項６］
請求項６の発明によれば、コンピュータを、ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段；収集した上記ジョブログを記憶するジョブログ記憶手段；ユーザの所属部門の情報を記憶する所属情報記憶手段；異動情報に基づいて上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段；チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む時期、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段；上記ユーザ異動履歴レコードを記憶する異動履歴レコード記憶手段；上記ジョブログの各々について、上記ユーザ異動履歴レコードに基づいて、当該ジョブログの集計対象情報を上記ユーザの属する所属部門に対応付ける対応付け手段；および、上記ユーザ異動履歴レコードを生成するまえに、当該ユーザ異動履歴レコードのそれぞれの元になるジョブログが示すジョブの実行時刻を含む日付より遅い日付の部門異動に関する異動情報を上記所属情報記憶手段に反映させないように上記更新手段を制御する制御手段として機能させるためのジョブログ処理用プログラムを実現する。
［請求項７］
請求項７の発明によれば、コンピュータを、ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段；収集した上記ジョブログを記憶するジョブログ記憶手段；ユーザの所属部門の情報を記憶する所属情報記憶手段；異動情報に基づいて上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段；チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む時期、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段；上記ユーザ異動履歴レコードを記憶する異動履歴レコード記憶手段；上記ジョブログの各々について、上記ユーザ異動履歴レコードに基づいて、当該ジョブログの集計対象情報を上記ユーザの属する所属部門に対応付ける対応付け手段；および、上記ユーザ異動履歴レコードを生成した後に、当該ユーザ異動履歴レコードのそれぞれの元になるジョブログが示すジョブの実行時刻を含む日付より遅い日付の部門異動に関する異動情報を上記所属情報記憶手段に反映させることを許可するように上記更新手段を制御する制御手段として機能させるためのジョブログ処理用プログラムを実現する。

請求項１、２、６、または７の発明によれば、ジョブの実行の度に当該ジョブを依頼したユーザの所属部門の情報を取得しなくても、ジョブを依頼したユーザと当該ユーザのジョブ実行時における所属部門との対応関係を得ることができる。
請求項３の発明によれば、本構成を有さないものに比較して、所属情報記憶手段に記憶されているユーザの所属部門の更新が保留された状態の期間を短くできる。
請求項４の発明によれば、本構成を有さないものに比較して、ユーザ異動履歴レコードの生成回数を少なくすることができる。
請求項５の発明によれば、さらに上位部門ごとにジョブログを集計できる。

以下、この発明の実施例について説明する。

図２は、この発明の実施例のジョブログ集計システム１００の計算機環境を全体として示しており、この例では、ジョブログ集計システム１００がサーバコンピュータ３０に実現されている。ジョブログ集計システム１００は複数のコンピュータを組み合わせて実現してもよい。ジョブログ集計システム１００は、サーバコンピュータ３０にジョブログ集計用のプログラム（他の補助的な機能を実現するプログラムモジュールを含んでもよい）を記録媒体２１（ＣＤ−ＲＯＭなど）や通信回線を用いてインストールして実現される。サーバコンピュータ２０は周知のＣＰＵ、主メモリ、バス、各種の入出力装置等を含んで構成され、サーバコンピュータ２０のハードウェア資源および記録媒体２１のプログラム等のソフトウェア資源が協働して以下に具体的に説明するジョブログ集計システム１００の各種機能ユニットを実現する。

図２において、任意個数の複写機１０Ａ〜１０Ｎ（単に「１０」と表す場合もある）、サーバコンピュータ２０、ホスト端末３０等が通信ネットワーク４０に接続されている。この例では複写機１０を示しているけれども、ファクシミリ装置、プリンタ、これらの装置の機能を併せ持つ複合機であってもよい。この例では、ジョブログ集計の対象は、画像形成の面数であるけれども、ジョブ要求に応じて消費される通信時間、使用時間、使用プログラム等の任意の資源を集計してもよい。なお、ジョブは、ユーザがデータ処理システムに対して要求する一まとまりの処理単位をいい、この例では、典型的には、１回のユーザ指示で実行される複写処理をいうが、これに限定されない。ジョブログは、ジョブの実行履歴をいい、典型的には、いつ、だれの要求に基づいて、どのような処理を要求したかを示すものであり、この例では、後に例示するように、ユーザ名、印刷時刻、集計対象の印刷面数等を含むがこれに限定されない。ここでは、１つのジョブログ、すなわち一まとまりの処理履歴に記録される処理単位がジョブとして扱われる。

複写機１０は、ユーザの要求したジョブを実行してそのジョブログを内部の記憶部に記憶保持している。ジョブログは、ユーザ識別情報、ジョブ実行時刻、ジョブ量（面数）等を保持するが、これはジョブの内容に応じて変化する。複写機１０はジョブログ管理サービスを実行して、このジョブログ管理サービスが、後に説明するジョブログ集計システム１００のジョブログ収集部１０１と通信ネットワーク４０を介してやりとりを行い、ジョブログをジョブログ収集部１０１に供給する。

ジョブログ集計システム１００は、ジョブログ収集部１０１、ユーザ異動履歴作成部１０２、ジョブログ集計部１０３、ジョブログ記憶部１０４、ユーザ異動履歴記憶部１０５、データベース管理部１０６、人事データベース１０７等を含んで構成される。ジョブログ収集部１０１は、複写機１０のジョブログ管理プログラムと協働して複写機１０に保持されているジョブログを収集してジョブログ記憶部１０４に記憶する。ジョブログの収集は典型的には定期的に行われる。ユーザ異動履歴作成部１０２は、新たに収集したジョブログの範囲でユーザの所属部門が変更したかどうかを人事データベース１０７を参照して判断し、変更があったユーザについて、ユーザ識別情報、追加日（ジョブ実行日）、異動後の部門情報（部門名、識別情報）を含むユーザ異動履歴（図４参照）を生成し、ユーザ異動履歴記憶部１０５に記憶する。ユーザ異動履歴作成部１０２の詳細な例は図５を参照して後に説明する。ジョブログ集計部１０３はジョブログ記憶部１０４のジョブログを、ユーザ異動履歴記憶部１０５のユーザ異動履歴を参照してユーザの所属部門に分類して所属部門ごとにジョブログを集計する。ジョブログの集計動作例については図６を参照して説明する。なお、直接または間接的に上位の部門の集計の動作については図１７〜図２０を参照して後に説明する。

管理部１０６は人事データベース１０７の更新を制御するように動作する。人事データベース１０７は、人事管理用の情報を保持するものであるけれども、この実施例との関係では、ユーザの所属する部門の情報、下位の部門が所属する上位の情報を保持する。通信ネットワーク４０を介してサーバコンピュータ２０（ジョブログ集計システム１００）に接続されたホスト端末３０を利用して人事データベース１０７の内容を異動情報に基づいて更新するよう指示できる。管理部１０６は、ユーザ異動履歴作成部１０２が更新対象の異動情報の異動日付よりジョブ実行日が前の日付のジョブログに対する処理を終了するまで、異動情報を人事データベース１０７に反映させないように更新動作を制御する。例えば、異動情報の異動日付が４月１日の場合、３月３１日の実行日付のジョブログがユーザ異動履歴作成部１０２によってまだ処理されていない場合に、異動情報を反映させないようにし、当該ジョブログに関連して３月３１日に異動があったという内容を示すユーザ異動履歴が生成されないようにする。

この実施例では、ジョブログは、ユーザを識別できる識別子（例：ユーザ名）と、印刷時刻、及び、集計に必要な面数情報などが記録される。印刷開始日（開始時刻）、印刷終了日（終了時刻）がある場合には、一方を印刷時刻、あるいは印刷日とする。典型的には、印刷終了日（終了時刻）を印刷日（時刻）として扱う。

人事データベース１０７の内容は、変更日のいずれかのタイミングで現状の人事情報を反映しているものとする。ただし、これに限定されず、異動日のまえに人事データベース１０７の内容が変更されてもよい。

ユーザ異動履歴作成部１０２は人事データベース１０７を参照してユーザ異動履歴ファイルを作成し、これに基づいて部門別レポートを作成にする。ユーザ異動履歴は、ユーザを識別できる識別子（例：ユーザ名）、追加日（この実施例では、ユーザ異動履歴ファイルを作成する日の前日が実行日であるジョブのジョブログに基づいて、ユーザ異動履歴ファイルを作成［更新］するので、当該追加日はユーザ異動履歴ファイルの作成日［更新日］の前日の日付となる）、異動部門名（異動先部門名）を持つ。典型的には、ユーザ異動履歴は日付変更時に毎日作成される（ユーザ異動履歴ファイルは毎日更新される）が、ユーザ異動履歴の作成を開始するタイミング（チェックポイントとも呼ぶ）は、その他種々採用可能である。例えば、ジョブが企業等の労働日またはシステムの稼働日しか生成されない場合には、労働日または稼働日の各々の次の日に変更された時を、ユーザ異動ファイルの作成開始のチェックポイントとして採用できる。また、日より短い単位または長い単位でチェックポイントの間隔を設定してもよい。以下では、チェックポイントとして、日付変更時を採用した場合について説明する。

人事データベース１０７の更新処理は異動履歴ファイル作成処理後に行い、ユーザ異動履歴作成部１０２が更新対象の異動情報の異動日付よりジョブ実行日が前の日付のジョブログに対する処理を終了するまで、異動情報を人事データベース１０７に反映させないようにする。

つぎに実施例の動作例を図３および図４をも参照して説明する。

この例では、ユーザを識別できる識別子（例：ユーザ名）と「印刷日」の情報を持つジョブログファイルと、ユーザの異動情報を持ったユーザ異動履歴ファイル（１以上のユーザ異動履歴を含むファイル）を用いることにより、集計期間内のユーザの部門異動に対応した部門別集計レポートを作成する。異動履歴ファイルは、人事データベース１０７から異動履歴ファイルを作成する。

図３に示すように、ジョブログ収集サービス（ジョブログ収集部１０１）がジョブログを収集してジョブログファイル（ジョブログ記憶部１０４）に保持する。ユーザ異動履歴作成サービス（ユーザ異動履歴作成部１０２）が作成日（当日）の前日のジョブログを参照して所属部門が前回参照時の部門と異なっているユーザについてユーザ識別情報、追加日（ユーザ異動履歴ファイル作成日の前日）、新しい所属部門の識別情報を含むユーザ異動履歴を作成してユーザ異動履歴ファイル（ユーザ異動履歴記憶部１０５）に保持する。集計サービス（集計部１０３）はユーザ異動履歴ファイル１０５が示す異動情報に基づいてジョブログを部門ごとに集計する。

図４はジョブログの集計例を示している。この例では、ユーザ「ｓｕｚｕｋｉ」が２００８／０２／０２および２００８／０２／１８（「２００８年２月２日」および「２００８年２月１８日」を意味する。以下同様。）にそれぞれ１０面および２０面印刷を行っている。２００８／０２／０２の時点ではユーザ「ｓｕｚｕｋｉ」は部門Ｂに所属していたので、「ｓｕｚｕｋｉ：２００８／０２／０２：Ｂ部門」の異動履歴が生成され、２００８／０２／１８の時点ではユーザ「ｓｕｚｕｋｉ」は部門Ｃに所属していたので、「ｓｕｚｕｋｉ：２００８／０２／１８：Ｃ部門」の異動履歴が生成される。異動履歴とジョブログに基づいて「Ｂ部門：１０面」、「Ｃ部門：２０面」の部門別レポートが作成される。この例では簡略化して説明されているけれども、例えば、２００８／０２／１５の時点でユーザ「ｓｕｚｕｋｉ」が依然としてＢ部門であり、３０面の印刷を行ったとすると、部門の変更がないのでユーザ異動履歴が作成されず、その時点の最新のユーザ異動履歴である「ｓｕｚｕｋｉ：２００８／０２／０２：Ｂ部門」を参照して、２００８／０２／１５の３０面を「Ｂ部門」に累積する。

つぎに、ユーザ異動履歴作成処理について図５を参照して説明する。

図５に示すようにユーザ異動履歴作成は以下のように行われる。
［ステップＳ１０］：前日分のジョブログに記録されている情報から前日にジョブを依頼したユーザのリスト（ユーザリスト）を作成する。
［ステップＳ１１］：ユーザリストに含まれるユーザの各々について以下の処理を行う。
（Ｓ１１ａ）ユーザ異動履歴ファイル内で、ユーザに対応する最新の部門名（Ｂ１)を取得する。
（Ｓ１１ｂ）人事データベース１０７からユーザの現在の所属部門名(Ｂ２)を取得し（Ｂ１）と比較する。
（Ｓ１１ｃ）ユーザ異動履歴ファイルに対象ユーザのレコードがない場合、あるいは、Ｂ１とＢ２が異なる場合は、ユーザ識別情報、前日の日付（追加日）、部門名の識別情報（Ｂ２）のレコードをユーザ異動履歴ファイルに追加する。
［ステップＳ１２］：処理結果（前日の更新処理［ユーザ異動履歴ファイルに必要な情報を追加する処理］が完了しているか否かを示すフラグ）を更新（未処理から処理済みに変更する）する。

なお、処理結果は任意の記憶部（例えばユーザ異動履歴記憶部１０５等）に保持しておく。この処理結果は人事データベース１０７の更新操作の際に管理部１０６によって参照される。

ユーザ異動履歴ファイルは以下に説明するジョブログの部門別集計に用いられる。

つぎにジョブログの部門別集計について図６を参照して説明する。

図６に示すようにジョブログの部門別集計は以下のように行われる。
［ステップＳ２０］：まず集計期間を指定する。これは任意のホスト端末またはサーバコンピュータ２０において指定できる。
［ステップＳ２１］：指定された範囲のジョブログから１ジョブ分の情報を読み込む。ジョブが残っている間、処理を繰り返す。指定期間内のジョブログがなければ、あるいは残っていなければ、この処理を抜けてステップＳ２３へ進む。そうでなければ、ステップＳ２２へ進む。
［ステップＳ２２］：ジョブログ内のユーザの情報および印刷日の情報と、ユーザ異動履歴ファイルの情報と、からユーザの所属部門を判定する。具体的には、ユーザ異動履歴ファイルから対象ユーザのレコードを検索し、ジョブログにおける印刷日とユーザ異動履歴ファイルにおける追加日とを比較する。ここで、比較は検索されたレコードのうち追加日の古いものから順に行う。そして、印刷日が追加日以降の日付である限り、順次、当該ユーザの（印刷日における）所属部門を（ユーザ異動履歴ファイルの当該追加日に対応するレコードの）異動情報に基づき設定（更新）していく。そして、検索されたレコードすべてについて印刷日と比較し終える、あるいは、追加日が印刷日より後のレコードが見つかると、ステップＳ２１に戻り、ジョブログから次の１ジョブ分の情報を読み込む。
［ステップＳ２３］：判定した部門別でジョブログを集計して部門別集計レポートを作成する。

つぎに人事データベース１０７の更新操作について説明する。

図７に示すようにこの更新操作は以下のように行われる。なお、以下のステップ３０〜Ｓ３４は管理部１０６により実行される。
［ステップＳ３０］：人事データベース１０７の更新操作を開始する。典型的にはホスト端末３０からの指示による。
［ステップＳ３１］：異動情報の各々について、処理日が組織変更日より前であるかどうかを判別し、前である場合には元に戻ってつぎの異動情報を処理する。
［ステップＳ３２］：処理結果（前日の更新処理済みフラグ）が未処理かどうかを判別し、未処理の場合には処理を行わず元に戻る。
［ステップＳ３３］：人事データベース１０７を異動情報に基づいて更新する。
［ステップＳ３４］：処理日を本日に設定し、処理結果（更新処理済みフラグ）を未処理に設定する。

つぎに具体的な異動を例に挙げて実施例の動作をさらに説明する。

図８は二人のユーザＡおよびＢの異動の履歴を示す。図９はこのような異動履歴のユーザＡおよびＢのジョブの履歴を示す。図８の異動履歴をテーブルで表すと図１０および図１１に示すようになる。

この例では、ユーザ異動履歴ファイルは図１２に示すようになる。ユーザＡについて検討すると、まず、システム運用開始後、初めて印刷を行った３／１５（３月１５日）を追加日、Ｏ部門というユーザ異動履歴が生成される。３／２０の印刷では同じくＯ部門であるのでユーザ異動履歴は追加されない。４／１０の印刷では、Ｏ部門からＰ部門に変更されているので、４／１０を追加日、Ｐ部門というユーザ異動履歴が生成される。４／２０および５／１０の印刷では同じくＰ部門であるのでユーザ異動履歴は追加されない。７／１０の印刷では、Ｐ部門からＲ部門に変更されているので、７／１０を追加日、Ｒ部門というユーザ異動履歴が生成される。こうして図１２の上から１番目、２番目、５番目に示すようにユーザＡについてユーザ異動履歴が生成される。同様にユーザＢについても図１２に示すようにユーザ異動履歴が生成される。異動履歴ファイルは、ジョブを印刷した日の部門で集計できることを目的で作成されたもので、完全に人事異動情報を作成するものではない。ユーザ異動履歴は、異動を反映する範囲で作成されていればよく、ジョブログすべてについて必要とされない。なお、上記例において、３／２０，４／２０および５／１０の印刷でも（すなわち、前回から部門が変更していなくても）ユーザ異動履歴を追加するなどしてもよい。

なお、上述の例では、人事データベース１０７、変更日のいずれかのタイミングで現状の人事情報を反映していることを前提としたけれども、これに限定されない。人事データベース１０７のデータベースへの更新指示が、実際の組織変更よりも前に行われてもよい（例えば、４月１日付けの組織変更を３月３１日中に行う）。ただし、人事データベース１０７への最終的な更新処理は、関連する異動履歴を作成するまで待機される。そのために、例えば、処理結果のデータに異動履歴ファイルを作成した日付を持たせる。３月３１日に人事データベース１０７の更新処理を行う場合、処理結果は３月３０日までしか処理済みになっていないので、人事データベース１０７の更新処理は待機されることになる。４月１日０時過ぎに、異動履歴作成サービスが動作し、処理結果が３月３１日処理済みに変更後に４月１日分の組織情報を反映する。この後、処理結果を４月１日未処理に設定する。

つぎに上位階層の部門別集計レポートの作成について説明する。なお、企業、学校等の組織における木構造の階層において１のエンティティ（ノード）に対して他のエンティティが木構造をリーフ方向にたどれる場合に、１のエンティティを上位のエンティティと呼ぶ、他のエンティティを下位のエンティティと呼ぶ。上位または下位のエンティティは１つのリンク（エッジ）のみを介在させてもよく（直接的な上位または下位）、複数のリンクを介在させてもよい（間接的な上位または下位）。下位のエンティティから見て上位のエンティティを所属部門と呼ぶ。１のリンクを介する上位のエンティティを直接的な上位部門と呼び、複数のリンクを介する上位のエンティティを間接的な上位部門と呼ぶ。

組織階層が幾階層にもなっている場合でも、下位部門の集計結果を元データとして、組織変更履歴ファイルを用いて、再帰的に上位階層の部門レポートを作成し、最終的にある階層部門における月別の部門レポートを作成する。

すなわち、図１３に示すようにユーザのジョブログからユーザが直接に所属する部門別の集計レポートを生成し、この集計レポートを図１４に示すように元データとして再帰的に上位の部門の集計レポートを生成する。この場合、例えば、人事データベースは、部門が所属する上位の部門の異動情報（異動日、上位の部門の識別情報）を提供する。

図１５は、組織変更履歴（先の説明のユーザ異動履歴に対応する）を作成する処理を示しており、その詳細は以下のとおりである。
［ステップＳ４０］：異動履歴ファイルに新規追加されたユーザの部門のリストを作成する（典型的には、ユーザ異動履歴作成処理の後に実行する）。
［ステップＳ４１］：リストに含まれる部門ごとに以下の処理を行う。
（Ｓ４１ａ）組織変更履歴ファイル内で、下位部門に対応する最新の上位部門名（Ｂ１)を取得する。
（Ｓ４１ｂ）人事データベース１０７から下位部門の現在の上位部門名(Ｂ２)を取得し（Ｂ１）と比較する。
（Ｓ４１ｃ）組織変更履歴ファイルに対象部門のレコードがない場合、あるいは、Ｂ１とＢ２が異なる場合は、下位部門の識別情報、前日の日付（追加日）、上位部門の識別情報(Ｂ２)のレコードを組織変更履歴ファイルに追加する。
［ステップＳ１２］：処理結果（前日の更新処理済みフラグ）を更新（未処理から処理済みに変更する）する。

図１６は、上位の部門別にジョブログを集計する処理を示しており、その詳細は以下のとおりである。
［ステップＳ５０］：まず集計期間を指定する。これは任意のホスト端末またはサーバコンピュータ２０において指定できる。
［ステップＳ５１］：部門別、日別で集計レポートを作成する。
［ステップＳ５２］：指定された範囲の部門別、日別の集計レポートを１レコード読み込む。レコードが残っている間、処理を繰り返す。指定期間内のレコードがなければ、あるいは残っていなければ、この処理を抜けてステップＳ５４へ進む。そうでなければ、ステップＳ５３へ進む。
［ステップＳ５３］：レポート内の部門と集計日から上位の部門を判定する。具体的には、組織変更履歴ファイルで、対象部門を検索し、集計レポートにおける集計日と組織変更履歴ファイルにおける追加日とを比較する。ただし、比較は追加日の古い順に行う。集計日が追加日以降であれば、部門の上位の部門を設定（更新）し、印刷日が追加日より後のレコードが見つかると、この後ステップＳ５２に戻り処理を繰り返す。
［ステップＳ５４］：判定した上位部門別で、下位部門の集計レポートを集計して上位部門別集計レポートを作成する。

なお、人事データベースに直接に接続できないケースでは、図２の人事データベース１０７をバックアップの人事データベースに置き換える。メインの人事データベースからバックアップの人事データベースに更新するタイミングは、組織変更日の前日の処理結果（更新処理済みフラグ）が成功後（処理済みに変更後）とする。

図１７は、このような人事データベースのバックアップデータベース（ユーザ情報データベースともいう）を用いる変形例を示している。

図１７において図２と対応する箇所には対応する符号を付した。図１７の例では、サーバコンピュータ５０を追加してこれに人事データベース１０７を実装している。サーバコンピュータ２０のジョブログ集計システム１００およびサーバコンピュータ５０の人事データベースは記録媒体２１、５１や通信ネットワークを用いてプログラムをインストールすることにより実現される。

図１７の変形例は図１８に示すように動作する。この例では、人事データベース１０７からバックアップのユーザ情報データベース１０８に更新を反映させるタイミングは、組織変更日の前日の処理結果（更新処理済みフラグ）が成功した後（処理済みに変更後）とする。

図１９は、バックアップのユーザ情報データベース１０８を更新する動作例を示し、この動作は以下のとおりである。
［ステップＳ６０］：人事データベース１０７の更新操作を開始する。典型的にはホスト端末３０からの指示による。
［ステップＳ６１］：バックアップのユーザ情報データベース１０８への反映処理を開始する。
［ステップＳ６２］：異動情報の各々について、処理日が組織変更日より前であるかどうかを判別し、前である場合には元に戻ってつぎの異動情報を処理する。
［ステップＳ６３］：処理結果（前日の更新処理済みフラグ）が未処理かどうかを判別し、未処理の場合には処理を行わず基に戻る。
［ステップＳ６４］：バックアップのユーザ情報データベース１０８を異動情報に基づいて更新する。
［ステップＳ６５］：処理日を本日に設定し、処理結果（更新処理済みフラグ）を未処理に設定する。

以上で実施例および変形例の説明を終了する。

なお、この発明は特許請求の範囲の記載に基づいて決定されるものであり、実施例の具体的な構成、課題、および効果には限定されない。この発明は上述の実施例に限定されるものではなくその趣旨を逸脱しない範囲で種々変更が可能である。例えば、上述の例は、複写機を例に挙げたが広くリソースの提供に適用可能である。また部門は企業内の部門に限定されず、広く組織のセクション、例えば大学の学部、学科等に適用できる。

従来例を説明する図である。 この発明の実施例のジョブログ集計システムおよびその利用環境を説明する図である。 上述実施例の動作例を全体として説明する図である。 上述の動作例をジョブログの例を挙げて説明する図である。 上述実施例のユーザ異動履歴作成処理の動作例を説明するフローチャートである。 上述実施例の部門別レポート作成処理の動作例を説明するフローチャートである。 上述実施例の人事データベースの更新処理の動作例を説明するフローチャートである。 上述実施例を具体例を用いて説明するための部門異動の例を示す図である。 上述実施例を具体例を用いて説明するための部門異動ならびに印刷履歴の例を示す図である。 上述実施例を具体例を用いて説明するためのユーザＡの部門異動の例を示す図である。 上述実施例を具体例を用いて説明するためのユーザＢの部門異動の例を示す図である。 上述実施例を具体例を用いて説明するための異動履歴ファイルの例を示す図である。 上位の部門別集計動作を説明するための下位の部門別日別レポート作成例を説明する図である。 下位の部門別日別レポートから上位の部門別日別レポートを作成する動作例を説明する図である。 上位の部門別日別レポートを作成するための組織変更履歴を作成する動作例を説明するフローチャートである。 上位の部門別日別レポートを作成する動作例を説明するフローチャートである。 上述実施例の変形例を説明する図である。 上述変形例の動作例を全体として説明する図である。 上述変形例の異動情報の更新動作例を説明するフローチャートである。

符号の説明

１０Ａ-１０Ｎ 複写機
２０ サーバコンピュータ
２１ 記録媒体
３０ サーバコンピュータ
３０ ホスト端末
４０ 通信ネットワーク
５０ サーバコンピュータ
１００ ジョブログ集計システム
１０１ ジョブログ収集部
１０２ ユーザ異動履歴作成部
１０３ ジョブログ集計部
１０４ ジョブログ記憶部
１０５ ユーザ異動履歴記憶部
１０６ データベース管理部
１０７ 人事データベース
１０８ ユーザ情報データベース

Claims (7)

1. ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段と、
   収集した上記ジョブログを記憶するジョブログ記憶手段と、
   ユーザの所属部門の情報を記憶する所属情報記憶手段と、
   異動情報に基づいて上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段と、
   チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む時期、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段と、
   上記ユーザ異動履歴レコードを記憶する異動履歴レコード記憶手段と、
   上記ジョブログの各々について、上記ユーザ異動履歴レコードに基づいて、当該ジョブログの集計対象情報を上記ユーザの属する所属部門に対応づける対応づけ手段と、
   上記ユーザ異動履歴レコードを生成するまえに、当該ユーザ異動履歴レコードのそれぞれの元になるジョブログが示すジョブの実行時刻を含む時期より遅い時期の部門異動に関する異動情報を上記所属情報記憶手段に反映させないように上記更新手段を制御する制御手段とを有するジョブログ処理装置。
2. ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段と、
   収集した上記ジョブログを記憶するジョブログ記憶手段と、
   ユーザの所属部門の情報を記憶する所属情報記憶手段と、
   異動情報に基づいて上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段と、
   チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む時期、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段と、
   上記ユーザ異動履歴レコードを記憶する異動履歴レコード記憶手段と、
   上記ジョブログの各々について、上記ユーザ異動履歴レコードに基づいて、当該ジョブログの集計処理対象情報を上記ユーザの属する所属部門に対応づける対応づけ手段と、
   上記ユーザ異動履歴レコードを生成した後に、当該ユーザ異動履歴レコードのそれぞれの元になるジョブログが示すジョブの実行時刻を含む時期より遅い時期の部門異動に関する異動情報を上記所属情報記憶手段に反映させることを許可するように上記更新手段を制御する制御手段とを有するジョブログ処理装置。
3. 上記レコード生成手段は、前日に実行されたジョブログについて上記異動履歴レコードを生成し、
   上記制御手段は、異動情報の異動日付が到達し、さらに上記レコード生成手段が前日に実行されたジョブログについて上記異動履歴レコードを生成終了している場合に、上記更新手段が上記異動情報に基づいてユーザの所属部門の情報を更新するように上記更新手段を制御する請求項１または２記載のジョブログ処理装置。
4. 上記レコード生成手段は、上記ジョブログに含まれるユーザの識別子が示すユーザが当該ジョブの実行時刻において所属している所属部門が前回参照したときと異なる場合に、上記ユーザ異動履歴レコードを生成する請求項１〜３のいずれかに記載のジョブログ処理装置。
5. 上記所属情報記憶手段は、下位の部門が直接的に属する上位の部門の情報をさらに記憶し、
   上記対応づけ手段は、日単位で、部門ごとに上記ジョブログの集計対象情報の集計を行い、日付、当該部門の識別情報、および集計値を含む日単位部門集計レコードを生成し、当該日単位部門集計レコードの各々について、当該部門の識別子、当該日付、および、当該部門の上位所属部門の情報を含む部門異動履歴レコードを生成し、さらに、上記日単位部門集計レコードの各々について、上記部門異動履歴レコードに基づいて、当該日単位部門集計レコードの集計値を上記部門の属する所属部門に累積して当該所属部門の集計値を生成する請求項１〜４のいずれかに記載のジョブログ処理装置。
6. コンピュータを、
   ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段、
   収集した上記ジョブログを記憶するジョブログ記憶手段、
   ユーザの所属部門の情報を記憶する所属情報記憶手段、
   異動情報に基づいて上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段、
   チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む時期、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段、
   上記ユーザ異動履歴レコードを記憶する異動履歴レコード記憶手段、
   上記ジョブログの各々について、上記ユーザ異動履歴レコードに基づいて、当該ジョブログの集計対象情報を上記ユーザの属する所属部門に対応付ける対応付け手段
   上記ユーザ異動履歴レコードを生成するまえに、当該ユーザ異動履歴レコードのそれぞれの元になるジョブログが示すジョブの実行時刻を含む時期より遅い時期の部門異動に関する異動情報を上記所属情報記憶手段に反映させないように上記更新手段を制御する制御手段
   として機能させるためのジョブログ処理用プログラム。
7. コンピュータを、
   ジョブを要求したユーザの識別情報、ジョブの実行時刻、および集計対象情報を含むジョブログを、上記ジョブを実行した実行装置から収集する収集手段、
   収集した上記ジョブログを記憶するジョブログ記憶手段、
   ユーザの所属部門の情報を記憶する所属情報記憶手段、
   異動情報に基づいて上記所属情報記憶手段に記憶されているユーザの所属部門の情報を更新する更新手段、
   チェックポイントごとに、上記ジョブログ記憶手段に記憶されている、前回のチェックポイントの後に新たに生成されたジョブログの各々からユーザの識別子を抽出し、抽出したユーザの識別子に基づき上記所属情報記憶手段から当該ユーザの所属部門の情報を取得して、当該ジョブログが示すユーザの識別子、当該ジョブログが示すジョブの実行時刻を含む時期、および、当該ジョブログが示す所属部門の情報を含むユーザ異動履歴レコードを生成するレコード生成手段、
   上記ユーザ異動履歴レコードを記憶する異動履歴レコード記憶手段、
   上記ジョブログの各々について、上記ユーザ異動履歴レコードに基づいて、当該ジョブログの集計対象情報を上記ユーザの属する所属部門に対応付ける対応付け手段
   上記ユーザ異動履歴レコードを生成した後に、当該ユーザ異動履歴レコードのそれぞれの元になるジョブログが示すジョブの実行時刻を含む時期より遅い時期の部門異動に関する異動情報を上記所属情報記憶手段に反映させることを許可するように上記更新手段を制御する制御手段
   として機能させるためのジョブログ処理用プログラム。