画像処理監視システム及びプログラム
【課題】業務手順に逸脱するような文書の出力や読取を監視できるシステムを提供する。
【解決手段】プリンタ１２や複写機１４は文書を印刷すると、印刷を指示したユーザーのＩＤ及び印刷した文書の画像を示す画像ログを含んだログレコードをサーバー２０及び２２に登録する。解析サーバー２４は、登録されたログレコード群に含まれる画像ログ同士の比較から、同一の個別業務に属するログレコードの集合を求め、それらを処理時刻の順に並べることで、プリンタ１２や複写機１４を用いて同一個別業務について行われた作業の手順を求める。その手順が、フロー情報ＤＢ２５に登録されたフロー定義に合致するか否かを判定し、合致しなければ管理者に警告を発する等の対策処理を実行する。
【解決手段】プリンタ１２や複写機１４は文書を印刷すると、印刷を指示したユーザーのＩＤ及び印刷した文書の画像を示す画像ログを含んだログレコードをサーバー２０及び２２に登録する。解析サーバー２４は、登録されたログレコード群に含まれる画像ログ同士の比較から、同一の個別業務に属するログレコードの集合を求め、それらを処理時刻の順に並べることで、プリンタ１２や複写機１４を用いて同一個別業務について行われた作業の手順を求める。その手順が、フロー情報ＤＢ２５に登録されたフロー定義に合致するか否かを判定し、合致しなければ管理者に警告を発する等の対策処理を実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理監視システムに関する。
【背景技術】
【０００２】
近年、ネットワーク技術やＰＣ（パーソナルコンピュータ）やプリンタ、複写機などの情報機器が普及しオフィスでの文書作業効率は飛躍的に向上した。しかし、その反面、これらの情報機器を利用した情報漏洩が増えてきている。例えば、社内の機密文書を不正に印刷、複写して社外に持ち出す事件などである。
【０００３】
このような情報漏洩の抑止や漏洩元の特定などのために、近年、プリンタや複写機、複合機（ネットワークプリンタ、ネットワークスキャナ、複写機などの機能を兼ね備えた装置）、ＦＡＸ（ファクシミリ装置）、スキャナなどの画像処理装置にて印刷、複写、ファクシミリ送信、或いはスキャンした画像を、画像ログとして保存しておく仕組みが利用されつつある。
【０００４】
例えば特許文献１には、プリンタや複写機で出力される際のジョブの情報（印刷した日時、機器名、文書名、操作したユーザーＩＤ（識別情報）など）をジョブログとしてサーバーに蓄積すると共に、文書のページを画像として取得し、これを文書の画像ログとして、ジョブログと関連付けてサーバーなどに蓄積しておき、情報漏洩や不具合が発生した際に、この画像ログを見て漏洩した時間、場所、漏洩した文書を特定し、漏洩元を追跡するシステムが提案されている。
【０００５】
また、特許文献２では、社内のシステムを監視するために、予め重要キーワードを登録しておき、ジョブログや画像ログ中にそのキーワードが出現しないか否かを監視することで、情報漏洩を瞬時に検出するシステムが提案されている。
【０００６】
これらの技術を用いれば、例えば社内の機密文書を示す重要キーワードを予め登録しておき、ジョブログや画像ログ中に、重要キーワードの有無を判定することで、情報漏洩を瞬時に判定することが可能となる（画像ログからの文字列取得はＯＣＲ等の技術を持ちいれば可能）。登録された重要キーワードが検出された場合に、システム側から管理者などに警告を発することが可能となる。
【０００７】
また「複写禁止」「重要文書」などのハンコの押印画像を登録しておき、画像ログの画像データに対して画像パターン認識を行えば、「複写禁止」「重要文書」などのハンコが押印された文書が複写されたことを監視することが可能となる。
【０００８】
一方、企業組織内の業務フロー（業務手順或いはワークフロートも呼ばれる）では、スタッフが作成した文書に対して各レベルの管理者が順に修正を加えたり、決済を行ったりするなどの流れがよくある。このような業務フローで用いられる文書は、通常、印刷や複写、あるいはスキャンされることが前提であるので、画像処理装置で上述のキーワードや押印画像などの監視を行うと、その業務が行われるたびに警告が出てしまうことになり煩雑きわまりない。このため、業務フローで用いられる文書の印刷や複写をキーワードや押印画像などを用いて監視することは現実的には不可能に近い。このため、この業務フローで用いられる文書を漏洩させない運用は、その業務に従事する作業者（のモラルなど）に依存している。
【０００９】
【特許文献１】特開２００６−２１１５８７号公報
【特許文献２】特開２００１−１０９６４７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
キーワードや押印画像の監視を行わない場合、業務フローの作業手順(ルール)に反した作業が行われ、その結果、情報漏洩が発生しても、漏洩した瞬間に管理者は気付く手だてが無い。そして、このような情報漏洩が発覚した後に、その漏洩元を探るべく大量のジョブログと画像ログから手作業で探さねばならず、漏洩対応が後手となり迅速に情報漏洩に対応できない。
【００１１】
本発明は、業務手順に逸脱するような文書の出力や読取を監視できるシステムを提供する。
【課題を解決するための手段】
【００１２】
本発明の１つの側面では、１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、前記履歴記録手段に記録された各履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順についての帳票情報との比較に基づき、前記各履歴レコードに対応する業務手順を判定する業務判定手段と、前記業務判定手段により同一の業務手順に対応すると判定された履歴レコードの集合ごとに、当該集合に含まれる各履歴レコードの対象画像同士の比較に基づき、当該集合に属する各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、を備える画像処理監視システムを提供する。
【００１３】
１つの態様では、画像処理監視システムは、前記業務手順ごとに、当該業務手順で用いられる帳票の画像のうち個別業務の全処理段階で共通する部分を示す共通部分情報を記憶する手段を更に備え、前記分類手段は、同一の業務手順に対応すると判定された各履歴レコードの対象画像のうち当該業務手順に対応する帳票についての前記共通手順情報が示す共通部分同士の類似度に基づき、それら各履歴レコードを個別業務ごとの部分集合に分類する。
【００１４】
また、本発明の別の側面では、１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、前記履歴記録手段に記録された各履歴レコードに含まれる対象画像同士の比較に基づき、それら各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、前記特定手段が特定した同一の個別業務に属する１以上の履歴レコードについて、前記履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順の帳票情報とに基づき、前記個別業務に対応する業務手順を判定する判定手段と、前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、前記判定手段が判定した業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、を備える画像処理監視システムを提供する。
【００１５】
１つの態様では、前記判定手段は、部分集合に含まれる各履歴レコードを、それら各履歴レコードに含まれる時刻情報に基づき順序づける順序づけ手段を含み、当該順序づけ手段により順序づけられた前記部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施形態を、図面を参照して説明する。
【００１７】
以下の実施形態において、「業務フロー」とは、オフィスなどで行われる書類を用いた作業の手順のことを示す。例えば図１に示す業務フローの例では、まずユーザーであるＡ課員が、決められたフォーマットに基づいて帳票書類などをクライアントＰＣで作成してプリンタで印刷する。次に、その紙書類をＢ課長が受け取り、内容を確認して確認印（デート印）を押印し、保存用にその書類をスキャナで読み込んでＰＣに保管する。更にその書類をＣ部長が受け取り、承認印を押印し、次の部門の業務担当者に送信するためにスキャナで読み込んで、帳票文書の画像データを次部門に送信する。このような業務フローは紙文書と電子文書が混在する現在のオフィスではよく見られる。この例は、ワークフローシステムなどのようなシステムで管理されていない業務フローであるが、システムで管理された業務フローの中でも、プリンタやスキャナ、複合機などの画像処理装置を用いた印刷や読取は往々にして行われる。
【００１８】
図２は、本実施形態のシステム構成の一例を示す図である。以下に業務フローの例に沿って、システムの動作を説明する。
【００１９】
ユーザーはクライアントＰＣ（パーソナルコンピュータ）１０にログインし、業務に必要な帳票を作成し、プリンタ１２へその帳票の印刷指示を出す。プリンタ１２は帳票印刷データと印刷指示を受け取り、内蔵する記憶装置に蓄積する。印刷指示にはクライアントＰＣ１０にログインしたユーザーのＩＤ番号等が含まれる。プリンタ１２にはＩＣカードリーダー１３が接続されており、ユーザーは自分の身分証明書であるＩＣカードをＩＣカードリーダー１３に読み込ませる。プリンタ１２は、記憶装置に蓄積した印刷指示のうち、ＩＣカードリーダー１３から読み込んだユーザーＩＤ番号と一致するＩＤ番号を持つ印刷指示を実行する。
【００２０】
プリンタ１２は印刷指示を実行する際に、ジョブログを生成し、ネットワーク３０で接続されたジョブログ蓄積サーバー２０にジョブログを蓄積する。ジョブログは、プリンタ１２等の画像処理装置が実行したジョブ（処理）の記録データであり、例えば以下に示す各項目の属性情報を含む。なお、以下に示すのは一例に過ぎない。ジョブログは例示した項目すべてを含んでいる必要はないし、また例示した以外の項目を含んでいてもよい。
処理内容 ： プリント、複写、スキャン、FAX等の処理内容
時刻 ： 処理した時刻
場所 ： 当該機器（プリンタなど）の設置場所（例：部屋名、フロア名など）
機器名 ： 当該機器を一意に特定する名称
文書名 ： プリント時に印刷指示された文書名（複写、スキャン、FAX時にはこの情報は取得出来ないので空欄となる）
文書ページ数 ： 文書を構成するページ数
部数 ： プリント、複写の部数
用紙サイズ ： 処理した紙のサイズ
ユーザー名 ： 処理を指示したユーザーのユーザーＩＤ番号
ユーザー権限 ： ユーザーの業務に対する権限情報（後述）
【００２１】
また、プリンタ１２は印刷指示を実行する際に、画像ログを生成し、ネットワーク３０で接続された画像ログ蓄積サーバー２２にその画像ログを蓄積する。画像ログは、画像処理装置が指示に応じて処理（例えば印刷又はスキャン）した文書の画像データである。処理した文書が複数ページで構成される場合に、ページごとの画像データを含んだ画像ログを生成してもよい。この場合、それら複数ページの画像データをマルチページ画像データ（TIFFのような）として生成してもよい。画像ログの色空間はこの実施形態ではフルカラーとするが、これに限定されるわけではない。限定色化されたパレット画像、グレイスケール画像、白黒２値画像でも良い。画像ログのフォーマットは特に限定されないが、この実施形態ではJPEGとする。画像解像度は極端に高解像である必要は無いが、文書内容が読めないほど低解像度では効果がない。この実施形態では解像度は200dpiとする。
【００２２】
ジョブログ蓄積サーバー２０は受信したジョブログを、内蔵するデータベースなどに格納する。画像ログ蓄積サーバー２２は受信した画像ログを、内蔵するデータベースなどに蓄積する。同じジョブについてのジョブログと画像ログとは、例えば同じジョブＩＤ（識別情報）を付すなどの方法で、互いに関連づけられて格納される。本実施形態では、この関連付けられたジョブログと画像ログとを合わせてログレコードと呼ぶ。
【００２３】
実施形態では説明の便宜上、ジョブログと画像ログを別々のサーバー２０及び２２で実装する例で説明を行うがこれはあくまで一例に過ぎない。ジョブログ蓄積サーバーと画像ログ蓄積サーバーは、別のサーバーとして実装してもよいし、同一のサーバー内の別のデータベースとして実装してもよい。また、ジョブログと画像ログを一つのデータベースで管理してもよいし、さらに言えば同一のスキーマで実装してもよい。
【００２４】
解析サーバー２４は、ジョブログ蓄積サーバー２０及び画像ログ蓄積サーバー２２に蓄積されているログ情報を合わせてログレコードとして取り扱い、業務フローを解析する機能を有する。この解析処理については後で詳しく説明する。図では解析サーバー２４を独立してネットワーク３０に接続しているが、解析サーバー２４の機能をジョブログ蓄積サーバー２０或いは画像ログ蓄積サーバー２２に搭載してもよい。
【００２５】
ジョブログの属性情報の一つであるユーザー権限は、そのユーザーの業務に対する権限に関する情報である。例えば、「業務を実行する権限がある」、「業務を承認する権限がある」、「業務に対してさらに上位の承認する権限がある」などである。ユーザー権限の情報はネットワーク３０で接続されたユーザー認証サーバー２８で管理される。プリンタ１２は、ジョブログを生成する際に、ユーザーＩＤに基づいてユーザー認証サーバー２８に問い合わせて、ユーザー認証サーバー２８からユーザー権限を取得して属性情報の一つとしてジョブログに組み込む。この代わりに、プリンタ１２ではユーザー権限情報は付与しないで、ジョブログ蓄積サーバー２０に格納される段階でジョブログ蓄積サーバー２０がユーザー認証サーバー２８からユーザー権限の情報を取得し、ジョブログに記録しても良い。更に別の例として、解析サーバー２４による後述のログレコード解析でユーザー権限情報が必要になった段階で、その都度ユーザー認証サーバー２８に問い合わせても良い。
【００２６】
以上ではプリンタ１２がジョブを実行した場合について説明したが、複写機１４で紙文書を複写する際も同様である。すなわち、複写機１４は、紙文書を複写すると同時に、ジョブログと画像ログを生成し、それぞれ、ジョブログ蓄積サーバー２０、画像ログ蓄積サーバー２２に蓄積する。複写を指示したユーザーのユーザーＩＤ番号は、ＩＣカードリーダー１５から得る。印刷と異なり複写の場合には文書名は取得できないので、ジョブログの属性情報の文書名は空欄となる。
【００２７】
なお、プリントを指示したユーザーの識別情報はクライアントＰＣ１０から取得することが出来るが、複写、スキャン、ＦＡＸを指示したユーザーの識別情報はクライアントＰＣ１０から取得することが出来ない。そのため、複写機１４、スキャナ１６、ＦＡＸ装置１８にそれぞれＩＣカードリーダー１５，１７，１９を設け、これらによりユーザーのＩＤカードに格納されているユーザーＩＤ番号を読み取り、その情報をジョブログの属性情報のユーザー名とする。なお、ユーザーＩＤ番号の取得はＩＣカードリーダーに限定されるものではなく、例えば複写機のＵＩからユーザーが直接入力しても良いし、ＵＩの表示されたユーザー一覧リストから選択するようにしてもよい。
【００２８】
次に、図３Ａ〜図３Ｃを参照して、サーバー２０及び２２に蓄積されるログレコードの例を説明する。
【００２９】
図３Ａはユーザー：伊藤がプリント作業を行った時のログレコード１０２の一例を示している。すなわち、このログレコード１０２は、ユーザー:伊藤がフォームＡという帳票様式を用いてクライアントＰＣ１０で帳票を作成し多機能複写機ＭＦ１を用いて帳票を印刷した場合のものである。ジョブログの属性情報として時刻、ユーザー名、機器名、処理内容が記されており、画像ログのデータ名としてＩＭ２が記されている。この画像ログの画像データの例を図５Ｂに画像ログＩＭ２として示す。
【００３０】
同様に図３Ｂはユーザー：小川がプリント作業を行った時のログレコード１０４を示している。すなわちこのログレコード１０４は、ユーザー：小川がフォームＢという帳票様式を用いて帳票をクライアントＰＣ１０で作成し、多機能複写機ＭＦ２を用いて帳票を印刷した場合のものである。また図３Ｃはユーザー：佐藤がスキャン作業を行ったときのログレコード１０６を示している。これは、フォームＣという帳票様式の用紙を多機能複写機ＭＦ３を用いて複写した場合のものである。
【００３１】
次に、業務フローの一例に沿って、フローの各段階で生成されるジョブログ及び画像ログの例を説明する。例として用いる業務フローは、備品の購入稟議という業務についてのものであり、その概要は以下の通りである。もちろん、これはあくまで一例に過ぎない。
(a) 起票者は、自らが作成した稟議のための帳票を印刷した上で、その印刷結果に対しデート印（日付印）を押す。そして、業務の記録のために、その紙帳票をスキャンし、スキャン結果の画像データを所定の保管場所（例えばファイルサーバ）に保管する。起票者は紙帳票を確認者に回す。
(b) 確認者は、起票者から受け取った紙帳票に起票者のデート印が押されている事をチェックして確認印を押印し、その帳票のコピーを作成して保管する。オリジナルの紙帳票は承認者に回される。
(c) 承認者は、確認者から受け取った紙帳票の起票者印、確認印をチェックして承認印を押印し、その紙帳票をスキャンし、スキャン結果の画像を規則に従い所定のデータベースに保存する。
【００３２】
図４はこの業務フローに沿って行われた実際の作業の例と、それら各作業の際に生成され蓄積されたログレコードを示している。
【００３３】
まず、起票者であるユーザー：中村が、フォームＡという帳票様式に沿った帳票をクライアントＰＣで作成する。帳票様式（フォーム）は、帳票の雛形（テンプレート）のことであり、電子文書の形で用意されている。フォームは、業務フローに対応づけられている。ユーザーは、例えば、複数用意されたフォームの中から、自分が実行しようとする業務に対応するものを選べばよい。ここではフォームＡを選択するものとする。ユーザー：中村は、クライアントＰＣ１で帳票を作成し、多機能複写機ＭＦ１を用いてプリント作業を行う。このプリントの際にジョブログ１１２と、図５に示す画像ログＩＭ１１が生成される。ジョブログ１１２には、属性情報として時刻、ユーザー名、機器名、処理内容が記されており、画像ログのデータ名としてＩＭ１１が記されている。ユーザー：中村はプリントされた帳票用紙の所定の位置にデート印を押印し、自分の作業内容の記録の為にその帳票用紙を多機能複写機ＭＦ１を用いてスキャンする。このスキャンの際にもジョブログ１１４と、図５に示す画像ログＩＭ１２が生成される。
【００３４】
次に、確認者であるユーザー：鈴木が、起票者：中村から受け取った帳票を確認する。ユーザー：鈴木は、起票者が作成した帳票用紙の記載内容と起票者印があることをチェックして、確認者が確認印を押印する。この確認印が押された帳票を保存のために多機能複写機ＭＦ２で複写しておく。この複写の際にジョブログ１１６と図５の画像ログＩＭ１３が生成される。
【００３５】
次に、承認者であるユーザー：田中が、確認者：鈴木から受け取った帳票を承認する。すなわち、その帳票の記載内容と起票者印、確認者印をチェックして、承認印を捺印する。そして、この承認印が押された帳票を保存のために、スキャナＳＣ１でスキャンする。このスキャンの際にジョブログ１１８と図５に示す画像ログＩＭ１４が生成される。
【００３６】
このようにオフィス内で発生する業務に関して、プリンタ１２，複写機１４，スキャナ１６及びＦＡＸ装置１８のようにログ生成・登録機能を備えた装置を用いてユーザーが作業を行うと、ジョブログと画像ログが発生し、発生したジョブログと画像ログはジョブログ蓄積サーバー２０、画像ログ蓄積サーバー２２に格納されていく。
【００３７】
解析サーバー２４は、これら蓄積されたログレコード（ジョブログ及び画像ログのペア）を解析することで、業務フロー違反の監視を行う。以下、この監視処理について説明する。図６はフロー監視の処理手順を示したフローチャートである。
【００３８】
大略的に言えば、この監視処理では、サーバー２０及び２２に蓄積されたログレコード群を解析して、同一文書に関わるログレコードを抽出する。ここでいう「同一文書」とは、業務フローに即した個別の業務において受け渡される個別の文書（例えば起票された後、確認を受け、更に承認を受ける帳票）のことである。各処理段階で追記されたり、修正されたりすることで、記載内容が段階ごとに変化しても、同じ個別業務の文書であることに変わりがない。その意味での「同一文書」である。例えば備品の購入稟議という業務の業務フローに則って、個別業務としてある装置Ｘの購入のための稟議が行われる場合、その「装置Ｘの購入のための稟議書帳票」が、ここで言う「同一文書」に当たる。その「稟議書帳票」は、まず起票者が必要事項を書き込んで作成し、その後確認者がそれに確認印を押印するが、その作成段階の帳票と、押印段階の帳票とは「同一文書」の関係にある。
【００３９】
同一文書に関わるログレコードが抽出できると、それらを処理時刻に従って並べ替えることで、その同一文書に対して行われた各処理の順序系列を明らかにし、その処理の順序系列が、その同一文書に対応する業務フローに合致するか否かを判定する。合致していれば業務フローに沿った正しい作業が行われていると判断できる。合致しなかった場合には、通常とは異なる処理がなされているということであり、情報漏洩の可能性があるので、例えば管理者に警告を発する等の対処を行う。
【００４０】
この手順のために、解析サーバー２４はフロー情報ＤＢ（データベース）２５を備える。フロー情報ＤＢ２５には、システムが管理している個々の業務フローについて、図７に示すようにフロー定義データ２００と帳票ひな形データ２１０が登録されている。フロー定義データ２００は、当該業務フローにおける処理の流れを示す情報である。例えば、フロー定義データ２００は、その業務フローを構成する処理段階ごとに、その処理段階の処理内容を示す処理内容情報と、その処理段階を行ってよいユーザーを特定する実行者情報と、を含む。処理内容情報は、例えばプリント、スキャンなどといった処理種別を示す情報である。実行者情報は、処理段階を行ってよいユーザーのＩＤを特定したものでもよいし、ユーザーの属性が満足すべき条件を記述した情報でも良い。図７には、フロー定義の一つの例として、まず第１段階として「課員」に該当するユーザーが印刷を行い、第２段階として「課長」に該当するユーザーがスキャン又はコピーを行い、第３段階として「部長」に該当するユーザーがスキャンをする、というフローを示している。フロー定義には、必ず行われるべき処理段階だけでなく、行わなくてもよい処理段階を記述できるようにしても良い。図７の例では、第１段階を行うユーザー（課員）は、プリントを行うことは必須であるが、その後にスキャンを行ってもよい（行わなくてもよい）ことが示されている。これから分かるように、フロー定義データ２００に規定される処理段階と、画像処理装置で行われた処理を示すログレコードとは、必ずしも一対一に対応しなくてよい。図７の第１段階については、印刷だけが行われる場合もあれば、印刷とスキャンが行われる場合もあり、前者ではログレコードが１つ、後者では２つ生成されることになる。また、図に例示は指定いないが、フロー定義データ２００には、実行することが任意の（すなわち、実行してもしなくてもよい）処理段階が含まれていてもよい。
【００４１】
また、帳票ひな形データ２１０は、例えば記入欄が空欄である帳票ひな形の画像を示すデータである。
【００４２】
図６の手順を詳細に説明する。
【００４３】
この手順では、解析サーバー２４は、まず、サーバー２０に蓄積された画像ログの画像データの自動画像分類を行う（Ｓ１０）。自動分類は例えば次の手順で行う。
【００４４】
すなわち、画像ログとして蓄積されている画像データが、フロー情報ＤＢ２５に登録された帳票ひな形データ２１０のどれに合致するか否かを、フォーム判定技術を用いて判定する。フォーム判定技術は既存の技術を用いる。例えば、画像ログと帳票ひな形データ２１０の双方から、帳票の主な構成要素である表を構成する水平垂直の直線成分を画像処理で特徴量として抽出し、その抽出された直線成分の特徴量を比較することで、その画像ログがどの帳票を用いているのかを判定できる。なお、帳票ひな形データ２１０としては、帳票ひな形の画像全体を登録しておく代わりに、この特徴量だけを登録しておいてもよい。このようなフォーム判定により、蓄積された多数の画像ログを、同一種類の帳票ひな形毎の集合に分類することが出来る。すなわち、この分類は、個々のログレコードを、業務フローの種類ごとに分類することに相当する。
【００４５】
分類結果である同一種類の業務フローに該当する画像ログの集合は、その業務フローに沿って実行される個別業務で用いられる「同一文書」の画像ログからなる部分集合に更に分けることができる。そこで、この後の処理では、フォーム認識結果により分類された画像データ群の中から、同一文書を判定していく（Ｓ１２）。
【００４６】
例えば、業務フローではプリント後に担当者がデート印を押印し、その後の手続きで確認印、承認印、あるいはコメント欄にコメントが記入されることが多い。このような押印やコメント記入に影響されないで、「同一文書」を判定する必要がある。
【００４７】
押印やコメント記入は、概ね押印欄やコメント欄などといったあらかじめ決められた領域になされることが一般的なので、同一種類の帳票文書の中から同一文書を判定するには、この押印欄やコメント欄のような「追記される領域」ではない、それ以外の「追記されない領域」を画像間で比較すればよい。この「追記されない領域」の類似度が高い文書が同一文書であると判定できる。「追記されない領域」にはその文書のタイトルや、日付、作成者氏名、データなどが記載された箇所が含まれる。このような「追記されない領域」だけを参照して画像間の類似度を算出すれば、押印やコメント追記に影響されないで同一文書を判定することが可能となる。
【００４８】
図８は、図７に例示した帳票ひな形データ２１０での「追記される領域」２１２と「追記されない領域」２１４を示している。このような「追記される領域」２１２と「追記されない領域」２１４の判別情報は、ひな形作成者があらかじめ作成し、帳票ひな形データ２１０と対応づけて登録しておけばよい。
【００４９】
この同一文書判定処理（Ｓ１２）の詳細な手順の一例を図９に示す。この手順は、Ｓ１０の自動分類で得られた帳票ひな形（業務種類）ごとの画像ログ（ログレコード）の集合に対して実行される。
【００５０】
この手順では、まず当該集合に対応する帳票ひな形データ２１０から「追記されない領域」の領域情報を取得する（Ｓ３０）。次にこの領域情報に基づいて、その集合に属する各画像ログの画像データから「追記されない領域」の画像を抽出し（Ｓ３２）、抽出された領域から特徴量を抽出する（Ｓ３４）。この特徴量は、例えば画像の特徴量でもよい。具体例として、抽出領域をあるサイズのブロックに分割し、ブロックごとの平均輝度、平均色などを算出し、全ブロックの平均輝度、平均色を特徴ベクトルとして算出する。この特徴量はこのような画像特徴量に限定されない。別の具体例としては、抽出された領域に対してＯＣＲ処理により文字列を抽出し、分かち書き処理により文字列を単語に分解し、出現単語とその出現頻度の組合せを特徴量ベクトルとしてもよい。このように全ての画像から特徴量をベクトルとして抽出し（Ｓ３６）、それら全ての画像間で特徴量ベクトルを比較して類似度を算出する（Ｓ３８）。特徴量ベクトルの類似度は特徴量空間でのユークリッド距離でも良いし、他の方法で算出した距離値でも良い。この特徴量空間での距離値が近いほど類似度が高いという判定となる。この考え方は画像検索における類似度の考え方と同様である。このように求めた画像間の類似度が高い組合せを同一文書として判定していく（Ｓ４０）。この判定には予めユーザーがしきい値を設定し、そのしきい値と類似度を比較して同一か否かを判定すればよい。
【００５１】
再び図６の説明に戻る。以上に説明した同一文書の判定処理のあと、解析サーバー２４は、その判定結果に基づき、同一の業務フロー（別言すれば同一帳票種類）に該当する画像ログの集合を、同一文書ごとの部分集合に分類する（Ｓ１４）。ここで、前述のように、画像ログはジョブログと対応づけられ、両者のペアで１つのログレコードを構成している。また、「同一文書」は、１つの個別業務に該当する。したがって、この分類処理では、同じ個別業務に属するログレコードの部分集合を求めていることになる。
【００５２】
図１０はジョブログ蓄積サーバー２０と画像ログ蓄積サーバー２２に収集されたログレコードの一覧から、同一文書のログレコードを抽出した例を示している。ここでは図３の業務フローと図４の業務フローのログレコードがサーバー２０及び２２に蓄積されており、これらを解析する場合を例に説明する。
【００５３】
図１０のログレコード群３００は、ジョブログ蓄積サーバー２０と画像ログ蓄積サーバー２２に蓄積されたログレコード群の最初の状態を示している。このレコード群に対してステップＳ１０（業務＝帳票種類別に自動分類）が行われると、それらログレコード群３００が図１０に示す集合３１０（フォームＡを用いたもの）、集合３２０（フォームＢを用いたもの）及び集合３３０（フォームＣを用いたもの）に分類される。
【００５４】
これら集合３１０〜３３０の各々に対し、ステップＳ１２（同一文書の判定＝個別業務別の細分類）の処理が行われる。集合３１０の細分類結果を図１１に示す。この例では、フォームＡを用いたログレコードの中から文書＃１に対応する部分集合３１２と文書＃２に対応する部分集合３１４が抽出されている。
【００５５】
次に解析サーバー２４は、ステップＳ１４の細分類処理により求められた個別業務に対応する部分集合ごとに、当該部分集合内のログレコードを、ジョブの属性情報の１つである処理時刻の順番で並べ替える（Ｓ１６）。この並べ替えにより、部分集合内の各ログレコードの処理順序が判明する。並べ替え後の各ログレコード中のジョブログの属性情報を参照すると、その同一文書に対して行われた、処理の順番、処理を行ったユーザーの順番が判明する。更に、処理に利用された機器の場所から、その文書が移動した経路も判明する。
【００５６】
つまり、同一文書のログレコードを解析すれば、その文書に対して、いつ、誰が、どこで、何をした、という実際の作業のフローが判明する。そして、そのように判明したフローを、フロー情報ＤＢ２５に登録された当該文書に対応する業務フローのフロー定義データ２００（図７参照）と比較する（Ｓ１８）ことで、あらかじめ定められた正しい業務フローに沿って作業が行われているかどうかを判定できる。
【００５７】
図１２は、レコード解析（Ｓ１６及びＳ１８）の詳細な手順の一例を示したフローチャートである。同一文書と判定されたログレコードを、ジョブログ中の処理時刻属性の値の順に並べ替える（Ｓ５０）ことで、個々のログレコードに対応する処理を指示したユーザーの順番やそのユーザーの権限の順番、処理内容などの順番を取得することが出来る。また、その処理が行われた場所（あるいは機器）の順番を取得することもできる。また、各ログレコードの属性から、各処理が行われた時刻や、印刷又はスキャンされたページ数や部数などの情報を得ることもできる。
【００５８】
また、解析サーバー２４は、その並べ替えたログレコードにおける隣り合うログレコード同士の画像ログの画像データ間の差分画像を生成してもよい（Ｓ５２）。例えばある処理で押印されていれば、差分画像に追加された押印だけが残る。コメントを追記でも同様に、差分画像にコメント追記だけが残る。業務フローで必ず押印されることが定められている場合、差分画像における押印の有無は、業務フローが遵守されているかの判断材料となる。なお、差分画像作成時には二つの画像の位置ズレの補正、傾きの補正、濃度の正規化などを行う必要があるが、これらは既存の技術を利用すればよい。
【００５９】
解析サーバー２４は、これら得られた情報が、それら並べ替えたログレコード群で用いている帳票ひな形に対応する業務フローのフロー定義データ２００に規定される条件を満足するか否かをチェックする（Ｓ５４）。例えば、時刻順に並べ替えられたログレコードが示す各処理段階の実行者のユーザーＩＤが、フロー定義データ２００に示される各処理段階の実行者の満たすべき条件を満たしているかどうかを判定する。例えば、第１段階の処理を実行者が「課員」であるとフロー定義データ２００に定められていれば、ログレコード群から求めた第１段階の処理を指示したユーザーのＩＤに対応する職階（権限）をユーザー認証サーバー２８から求めるか、或いはログレコード中のユーザー権限属性の値から求め、求めた職階が「課員」に該当するかどうかを判定すればよい。この判定の際に、各処理段階のログレコードの処理内容属性の値がフロー定義データ２００における当該処理段階の処理内容に合致するかも判定する。以上のような判定を、同一文書についての時刻順に並べ替えたログレコードのすべてについて行えばよい。
【００６０】
例えば図１１に示した部分集合３１２は、図４に例示した個別業務のフローに対応しているが、このフローではまず中村がフォームＡに準拠した帳票の印刷を行い、更にスキャンを行い、次に鈴木がその帳票のコピーを行い、更にその次に田中がその帳票のスキャンを行っていることがわかる。ここで、中村、鈴木、田中のそれぞれの職階が課員、課長、部長であることがユーザー権限属性等から分かれば、その実際のフローが、その部分集合３１２が表すフローは、図７に示されるフォームＡに対応するフロー定義データ２００の条件を満足していることが分かる。
【００６１】
また、フロー定義データ２００の中に、個々の処理段階の処理が行われるべき場所（或いはその処理を行うべき機器）についての条件が規定されている場合には、各ログレコード中の利用場所属性の値がその条件を満たしているかを判定する。同様に、フロー定義データ２００の中に、個々の処理段階の処理が行われるべき時間帯についての条件が規定されている場合は、各ログレコード中の処理時刻属性の値がその時間帯の条件を満たしているかを判定する。また、フロー定義データ２００の中に、個々の処理段階で印刷してよいページ数又は部数（又はその両方）についての条件が規定されている場合は、各ログレコード中のページ数属性又は部数属性（又はその両方）の値がその条件を満たしているかを判定する。
【００６２】
また、フロー定義データ２００の中に、各処理を行うユーザーがそれぞれ押印をなすべきことが規定されている場合には、ステップＳ５２で求めた各段階の差分画像をチェックする。この場合、差分画像に押印が出てくるはずなので、押印画像の有無で業務フローの成否が判定できる。出るはずの差分画像が無い場合、フロー定義から逸脱した処理が行われたと判定できる。更に、各ユーザーのデート印の画像を予めユーザーＩＤと関連付けて解析サーバー２４に登録しておき、差分画像の元になった２つの画像の内の前の画像に対応するログレコードのユーザーＩＤ属性に対応するデート印の画像を検索し、その画像と差分画像とを比較することで、正しいデート印が押されているかどうかを検査することもできる。
【００６３】
この差分画像を利用した検査処理の例を、図１３を参照して説明する。図１３の差分画像は、図４の業務フローに対応しており、更に図１１の文書＃１の処理のログレコードに対応している。
【００６４】
図１３において、ＩＭ１１は図４のユーザー：中村が最初にプリントした際の画像ログである。ＩＭ１２は図４のユーザー：中村が押印してスキャンした際の画像ログである。ＩＭ１３は図４のユーザー：鈴木が中村から受け取った書類に押印してコピーした際の画像ログである。ＩＭ１４は図４のユーザー：田中が鈴木から受け取った書類に押印してスキャンした際の画像ログである。
【００６５】
ＩＭ１１とＩＭ１２の差分画像を作成すると、中村が押印したデート印が差分として抽出される。同様に、ＩＭ１２とＩＭ１３の差分画像として鈴木のデート印が、ＩＭ１３とＩＭ１４の差分画像として田中のデート印が抽出される。
【００６６】
この業務フローを使うユーザーのデート印をユーザーＩＤとひも付けてユーザー認証サーバーなどに登録しておき、差分画像で抽出されたデート印とのパターンマッチングを行い、抽出されたデート印が誰のデート印かを判定することができる。デート印と関連付けられたユーザーＩＤからユーザー認証サーバー２８に問い合わせて、ユーザー権限を取得する。例えば、中村は部員なので承認権限は無く、鈴木と田中は部課長なので承認権限をもっている、といったユーザー権限の情報を取得することが出来る。これにより、そのフォームの承認印の箇所にあるデート印に承認権限の有無を判定することが出来る。
【００６７】
以上では、差分画像を用いて押印を検査する例を示したが、差分画像を用いた検査の対象は押印に限らない。この他にも例えば、各処理段階のユーザーごとに記入欄が定められ、その記入欄に記入することが求められている場合は、差分画像に基づき各ユーザーが自分の処理段階に対応する正しい記入欄に記入を行っているかを判定できる。このためには、処理段階ごとに記入されるべき記入欄を示す情報をフロー定義データ２００に組み込んでおけばよい。
【００６８】
再び図６に戻り、以上のような判定（Ｓ１８）の結果、個別業務（同一文書）に属するログレコードの部分集合が、対応する業務フローのフロー定義データ２００に示される条件を満たしていないと判定された場合は、解析サーバー２４は、あらかじめ定められた管理者に警告を発するなどの対策処理を実行する（Ｓ２０）。警告の方法は電子メールや、管理者用コンソール画面への表示、或いはアラーム音や赤色ランプの点灯でも良い。また、ステップＳ２０で実行する対策処理は、管理者の警告に限らない。
【００６９】
この代わりに、例えば、ユーザーが画像処理装置（プリンタ１２等）に対して処理を指示した段階で、画像処理装置がその処理を実行する前に解析サーバー２４が上述のフロー逸脱の有無の判定処理を行い、逸脱していると判定された場合には、画像処理装置がその処理を実行することを禁止することもできる。この場合、画像処理装置は、指示された処理に係る文書（帳票）の画像を取得した段階で、いったんその処理の実行を保留し、ログレコードを生成して各サーバー２０及び２２に送る。解析サーバー２４は、新たなログレコードが各サーバー２０及び２２に追加されたことを検知すると、上述の図６の処理と同様の処理を実行することで、その新たに追加されたログレコードが、当該ログレコードに対応する業務フローのフロー定義データ２００の条件を満足するかどうかを判定すればよい。満足すれば、解析サーバー２４はその画像処理装置に対して保留中の処理の実行を許可し、満足しなければその画像処理装置にその処理の中止を指示すればよい。
【００７０】
なお、このように画像処理装置に対して処理が指示されるたびにリアルタイムでフロー準拠性の検査を行う場合は、サーバー２０及び２２に含まれるすべてのログレコードを解析する必要はない。この場合、例えばその処理についてのログレコードの画像ログがどの帳票ひな形に該当するかを判定し、更にどの個別業務の帳票に該当するかを判定すればよい。これらの処理は、当該ログレコードにのみ注目する点を除けば、実質的な処理内容は前述の図６の手順のステップＳ１０及びＳ１２と同様でよい。そして、求められた個別業務の過去のログレコードと当該ログレコードが、その個別業務に対応する業務フローのフロー定義データ２００に合致するかを判定すればよい。
【００７１】
また、このリアルタイム検査では、過去に行った分類の結果（例えば同一文書ごとの部分集合（処理時刻順に並んだログレコード）の情報と、それら各部分集合がそれぞれどの業務フローに対応するのかを示す情報）をデータベース（分類結果データベースと呼ぶ）に蓄積しておき、再利用してもよい。すなわち、例えば、新たにログレコードが画像処理装置から到来した場合に、そのログレコードに対応する業務フローをそのログレコード中の画像ログと各業務フローの帳票ひな形データ２１０との比較により特定する。そして、特定した業務フローに属する各「同一文書」の部分集合の中でそのログレコードに対応するものを、当該ログレコードの画像ログと、各部分集合中のログレコードの画像ログとの比較により求める（帳票ひな形データ２１０との比較はスキップし、当該ログレコードの画像ログと直接各部分集合の画像ログとを比較して、当該ログレコードに対応する「同一文書」を直接特定してもよい）。そして、求めた「同一文書」のログレコード群の後ろに当該ログレコードを付加した系列が、その「同一文書」に対応する業務フローのフロー定義データ２００に合致するかを判定すればよい。合致すると判定した場合は、当該ログレコードを分類結果データベースにおけるその「同一文書」のログレコードの部分集合の末尾に追加すればよい。
【００７２】
なお、図６の手順は、サーバー２０及び２２に蓄積されたログレコード全体に対する一括処理の例なので、この手順では、ステップＳ１２で求められた個々の個別業務（「同一文書」）ごとに、ステップＳ１４〜Ｓ２０の処理を繰り返す（Ｓ２２）。
【００７３】
以上、本発明の実施形態を説明した。以上の実施形態では、ログレコード中の画像ログを各帳票ひな形データ２１０と比較することで、そのログレコードがどの帳票ひな形データ２１０を用いる業務フローに対応するものかを判定し、その後で更にそのログレコードがどの個別業務の文書に対応するものかを判定した。しかし、これは一例に過ぎない。別の例を以下に説明する。
【００７４】
この例では、ログレコードの画像ログ同士の比較のみに基づき、「同一文書」に該当するログレコードの集合を求める。画像ログと帳票ひな形データ２１０との比較に基づく分類は行わない。
【００７５】
図１４は、この例の業務フロー監視の手順を示すフローチャートである。この手順は、図６とは異なり、帳票ひな形データ２１０に基づく業務フロー種類についての自動分類（Ｓ１２）は経ず、画像ログ同士の比較のみで同一文書判定を行う（Ｓ６０）。その他のステップは図６と同様である。ただし、ステップＳ１６では、同一文書に属すると判定したログレコードの集合がどの業務フローに対応するかを判定するために、それらログレコード中のいずれかの画像ログをフロー情報ＤＢ２５中の各帳票ひな形データ２１０と比較する。
【００７６】
ステップＳ６０の詳細な処理手順を図１５に示す。この手順で行う処理は基本的には上記実施形態の同一文書判定処理（Ｓ１２）と同様の考え方に基づく。すなわち、２つの画像間の類似度を算出して、類似度の高い（例えば類似度が予め設定されたしきい値以上となる）文書を同一文書として判定する。その二つの画像間の類似度の算出方法には、例えば、特開２００４−０２１４３０号公報に記載された方法を用いることができる。図１５は、この方法を用いた場合の手順の例を示している。
【００７７】
この手順では、まず、各画像ログを所定サイズのブロックに分割し（Ｓ８０）、ブロック毎に特徴量を抽出する（Ｓ８２）。この特徴量はブロックの平均輝度、平均色、エッジ量などである。このブロック毎の特徴量抽出を全ての画像データに対して実施する（Ｓ８４）。
【００７８】
次に全ての画像ログから２つの画像ログの組合せを選択し（Ｓ８６）、この２つの画像のブロック毎の特徴量を参照して、ブロック毎の特徴量の類似度を算出する（Ｓ８８）。類似度の算出は、画像上で同じ位置にあるブロック同士の特徴量の比較に基づき行う。例えば画像ログを１０×１０の合計１００個のブロックに分割した場合、２つの画像はそれぞれ１００個のブロックに分割される。これら各ブロックについて、まずブロック番号１番同士の類似度を算出し、次にブロック番号２番同士の類似度を算出するといった具合に、対応ブロック同士の類似度を順番に算出していく。これを繰り返すと、２つの画像間で１００個の類似度が算出される。
【００７９】
この１００個の類似度を類似度が高い順番に並べ替える（Ｓ９０）。そして類似度の高い方からＮ個までの類似度の合計値を、この２つの「画像ログ間の類似度」として算出する（Ｓ９２）。ここでＮはあらかじめ管理者等が決めたしきい値である。例えば１０×１０で１００個のブロックだった場合、Ｎは８０という値でも良い。
【００８０】
このようにして、全ての画像ログの組合せ（ペア）で類似度を算出する（Ｓ９４）。そして、そのようにして求めた類似度が高い（例えば所定のしきい値以上）画像ログ同士を同一文書として判定する（Ｓ９６）。
【００８１】
図１６は２つの画像ログ間の類似度の算出を模式的に示したものである。まず画像ログ４００と画像ログ４０２の画像間の類似度を算出する。このために画像４００と画像４０２をブロックに分割する。ここでは説明の便宜上３×４の１２ブロックに分割している。そして、ブロック毎に特徴量を算出する。２つの画像の同一位置にあるブロックの特徴量を比較する。この２つの画像は鈴木の押印の有無だけが違うので、鈴木の押印があるブロックは類似度が低く、それ以外は類似度が高い。図の比較結果４１０では、類似度が閾値以上のブロックは白色ブロック４１４で、類似度がしきい値未満のブロックは斜線ハッチングのブロック４１６で示している。画像４００と画像４０２の比較では類似度が低いブロックは１箇所である。ここで類似度が高い方から１０個のブロックの類似度の合計値を、画像ログ４００と４０２との間の類似度とすると、類似度が低いブロック（鈴木の押印があるブロック）は類似度算出に採用されないので、全体としてそれら両画像ログの類似度は高いという結果となり、それら両画像ログは同一文書であると判定出来る。
【００８２】
次に、画像４０２と画像４０４の画像間の類似度を算出する。同様に画像４０２と画像４０４をブロックに分割し、ブロック毎に特徴量を算出する。そしてブロック毎に特徴量を比較する。この２つの画像は全く別の画像であるので、類似するブロックは前の例ほど多くない。押印欄と右上の余白部分だけの類似度が高いので、比較結果４２０のような結果となる。類似度が高い方から１０個のブロックの類似度の合計値を、画像ログ４０２と４０４との間の類似度とすると、類似度が低いブロックがその中に多数含まれることになるので、前の例よりも類似度が低いという結果になる。したがって、画像ログ４０２と画像ログ４０４は同一文書ではないという判定ができる。
【００８３】
以上に例示した実施形態及び変形例における解析サーバー２４は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、図１７に示すように、ＣＰＵ１０００等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）１００２およびリードオンリメモリ（ＲＯＭ）１００４等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）１００６を制御するＨＤＤコントローラ１００８、各種Ｉ／Ｏ（入出力）インタフェース１０１０、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース１０１２等が、たとえばバス１０１４を介して接続された回路構成を有する。また、そのバス１０１４に対し、例えばＩ／Ｏインタフェース１０１０経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ１０１６、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ１０１８、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭ１００２に読み出されＣＰＵ１０００等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。なお、それら機能モジュール群のうちの一部又は全部を、専用ＬＳＩ(Large Scale Integration)、ＡＳＩＣ（Application Specific Integrated Circuit、特定用途向け集積回路）又はＦＰＧＡ（Field Programmable Gate Array）等のハードウエア回路として構成してもよい。
【図面の簡単な説明】
【００８４】
【図１】業務フローを説明するための図である。
【図２】実施形態のシステム構成の一例を示す図である。
【図３Ａ】画像処理装置による処理により生成されるログの例を示す図である。
【図３Ｂ】画像処理装置による処理により生成されるログの例を示す図である。
【図３Ｃ】画像処理装置による処理により生成されるログの例を示す図である。
【図４】実際の業務フローの例と、その各段階で生成されるログの例を示す図である。
【図５Ａ】業務フローの各段階で生成される画像ログの例を示す図である。
【図５Ｂ】画像ログとして保存される画像の例を示す図である。
【図６】解析サーバーによる監視処理の手順を示す図である。
【図７】フロー情報ＤＢに記憶される個々の業務フローの情報を模式的に説明する図である。
【図８】帳票における追記される領域と追記されない領域の例を示す図である。
【図９】同一文書判定処理の手順の一例を示すフローチャートである。
【図１０】ログレコード群の帳票種類（業務種類）ごとの分類の例を説明するための図である。
【図１１】同一の帳票種類に該当するログレコード群を同一文書ごと（すなわち個別業務ごと）の細分類を説明するための図である。
【図１２】処理時刻順にソートされたログレコード群に対する解析処理の一例を示すフローチャートである。
【図１３】差分画像を用いた検査処理を説明するための図である。
【図１４】第２の例における解析サーバーによる監視処理の手順の一例を示すフローチャートである。
【図１５】第２の例における同一文書判定の手順の一例を示すフローチャートである。
【図１６】第２の例における同一文書判定の方法を説明するための図である。
【図１７】コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【００８５】
１０ クライアントＰＣ、１２ プリンタ、１３，１５ ＩＣカードリーダー、１４ 複写機、２０ ジョブログ蓄積サーバー、２２ 画像ログ蓄積サーバー、２４ 解析サーバー、２５ フロー情報ＤＢ。
【技術分野】
【０００１】
本発明は、画像処理監視システムに関する。
【背景技術】
【０００２】
近年、ネットワーク技術やＰＣ（パーソナルコンピュータ）やプリンタ、複写機などの情報機器が普及しオフィスでの文書作業効率は飛躍的に向上した。しかし、その反面、これらの情報機器を利用した情報漏洩が増えてきている。例えば、社内の機密文書を不正に印刷、複写して社外に持ち出す事件などである。
【０００３】
このような情報漏洩の抑止や漏洩元の特定などのために、近年、プリンタや複写機、複合機（ネットワークプリンタ、ネットワークスキャナ、複写機などの機能を兼ね備えた装置）、ＦＡＸ（ファクシミリ装置）、スキャナなどの画像処理装置にて印刷、複写、ファクシミリ送信、或いはスキャンした画像を、画像ログとして保存しておく仕組みが利用されつつある。
【０００４】
例えば特許文献１には、プリンタや複写機で出力される際のジョブの情報（印刷した日時、機器名、文書名、操作したユーザーＩＤ（識別情報）など）をジョブログとしてサーバーに蓄積すると共に、文書のページを画像として取得し、これを文書の画像ログとして、ジョブログと関連付けてサーバーなどに蓄積しておき、情報漏洩や不具合が発生した際に、この画像ログを見て漏洩した時間、場所、漏洩した文書を特定し、漏洩元を追跡するシステムが提案されている。
【０００５】
また、特許文献２では、社内のシステムを監視するために、予め重要キーワードを登録しておき、ジョブログや画像ログ中にそのキーワードが出現しないか否かを監視することで、情報漏洩を瞬時に検出するシステムが提案されている。
【０００６】
これらの技術を用いれば、例えば社内の機密文書を示す重要キーワードを予め登録しておき、ジョブログや画像ログ中に、重要キーワードの有無を判定することで、情報漏洩を瞬時に判定することが可能となる（画像ログからの文字列取得はＯＣＲ等の技術を持ちいれば可能）。登録された重要キーワードが検出された場合に、システム側から管理者などに警告を発することが可能となる。
【０００７】
また「複写禁止」「重要文書」などのハンコの押印画像を登録しておき、画像ログの画像データに対して画像パターン認識を行えば、「複写禁止」「重要文書」などのハンコが押印された文書が複写されたことを監視することが可能となる。
【０００８】
一方、企業組織内の業務フロー（業務手順或いはワークフロートも呼ばれる）では、スタッフが作成した文書に対して各レベルの管理者が順に修正を加えたり、決済を行ったりするなどの流れがよくある。このような業務フローで用いられる文書は、通常、印刷や複写、あるいはスキャンされることが前提であるので、画像処理装置で上述のキーワードや押印画像などの監視を行うと、その業務が行われるたびに警告が出てしまうことになり煩雑きわまりない。このため、業務フローで用いられる文書の印刷や複写をキーワードや押印画像などを用いて監視することは現実的には不可能に近い。このため、この業務フローで用いられる文書を漏洩させない運用は、その業務に従事する作業者（のモラルなど）に依存している。
【０００９】
【特許文献１】特開２００６−２１１５８７号公報
【特許文献２】特開２００１−１０９６４７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
キーワードや押印画像の監視を行わない場合、業務フローの作業手順(ルール)に反した作業が行われ、その結果、情報漏洩が発生しても、漏洩した瞬間に管理者は気付く手だてが無い。そして、このような情報漏洩が発覚した後に、その漏洩元を探るべく大量のジョブログと画像ログから手作業で探さねばならず、漏洩対応が後手となり迅速に情報漏洩に対応できない。
【００１１】
本発明は、業務手順に逸脱するような文書の出力や読取を監視できるシステムを提供する。
【課題を解決するための手段】
【００１２】
本発明の１つの側面では、１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、前記履歴記録手段に記録された各履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順についての帳票情報との比較に基づき、前記各履歴レコードに対応する業務手順を判定する業務判定手段と、前記業務判定手段により同一の業務手順に対応すると判定された履歴レコードの集合ごとに、当該集合に含まれる各履歴レコードの対象画像同士の比較に基づき、当該集合に属する各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、を備える画像処理監視システムを提供する。
【００１３】
１つの態様では、画像処理監視システムは、前記業務手順ごとに、当該業務手順で用いられる帳票の画像のうち個別業務の全処理段階で共通する部分を示す共通部分情報を記憶する手段を更に備え、前記分類手段は、同一の業務手順に対応すると判定された各履歴レコードの対象画像のうち当該業務手順に対応する帳票についての前記共通手順情報が示す共通部分同士の類似度に基づき、それら各履歴レコードを個別業務ごとの部分集合に分類する。
【００１４】
また、本発明の別の側面では、１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、前記履歴記録手段に記録された各履歴レコードに含まれる対象画像同士の比較に基づき、それら各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、前記特定手段が特定した同一の個別業務に属する１以上の履歴レコードについて、前記履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順の帳票情報とに基づき、前記個別業務に対応する業務手順を判定する判定手段と、前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、前記判定手段が判定した業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、を備える画像処理監視システムを提供する。
【００１５】
１つの態様では、前記判定手段は、部分集合に含まれる各履歴レコードを、それら各履歴レコードに含まれる時刻情報に基づき順序づける順序づけ手段を含み、当該順序づけ手段により順序づけられた前記部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施形態を、図面を参照して説明する。
【００１７】
以下の実施形態において、「業務フロー」とは、オフィスなどで行われる書類を用いた作業の手順のことを示す。例えば図１に示す業務フローの例では、まずユーザーであるＡ課員が、決められたフォーマットに基づいて帳票書類などをクライアントＰＣで作成してプリンタで印刷する。次に、その紙書類をＢ課長が受け取り、内容を確認して確認印（デート印）を押印し、保存用にその書類をスキャナで読み込んでＰＣに保管する。更にその書類をＣ部長が受け取り、承認印を押印し、次の部門の業務担当者に送信するためにスキャナで読み込んで、帳票文書の画像データを次部門に送信する。このような業務フローは紙文書と電子文書が混在する現在のオフィスではよく見られる。この例は、ワークフローシステムなどのようなシステムで管理されていない業務フローであるが、システムで管理された業務フローの中でも、プリンタやスキャナ、複合機などの画像処理装置を用いた印刷や読取は往々にして行われる。
【００１８】
図２は、本実施形態のシステム構成の一例を示す図である。以下に業務フローの例に沿って、システムの動作を説明する。
【００１９】
ユーザーはクライアントＰＣ（パーソナルコンピュータ）１０にログインし、業務に必要な帳票を作成し、プリンタ１２へその帳票の印刷指示を出す。プリンタ１２は帳票印刷データと印刷指示を受け取り、内蔵する記憶装置に蓄積する。印刷指示にはクライアントＰＣ１０にログインしたユーザーのＩＤ番号等が含まれる。プリンタ１２にはＩＣカードリーダー１３が接続されており、ユーザーは自分の身分証明書であるＩＣカードをＩＣカードリーダー１３に読み込ませる。プリンタ１２は、記憶装置に蓄積した印刷指示のうち、ＩＣカードリーダー１３から読み込んだユーザーＩＤ番号と一致するＩＤ番号を持つ印刷指示を実行する。
【００２０】
プリンタ１２は印刷指示を実行する際に、ジョブログを生成し、ネットワーク３０で接続されたジョブログ蓄積サーバー２０にジョブログを蓄積する。ジョブログは、プリンタ１２等の画像処理装置が実行したジョブ（処理）の記録データであり、例えば以下に示す各項目の属性情報を含む。なお、以下に示すのは一例に過ぎない。ジョブログは例示した項目すべてを含んでいる必要はないし、また例示した以外の項目を含んでいてもよい。
処理内容 ： プリント、複写、スキャン、FAX等の処理内容
時刻 ： 処理した時刻
場所 ： 当該機器（プリンタなど）の設置場所（例：部屋名、フロア名など）
機器名 ： 当該機器を一意に特定する名称
文書名 ： プリント時に印刷指示された文書名（複写、スキャン、FAX時にはこの情報は取得出来ないので空欄となる）
文書ページ数 ： 文書を構成するページ数
部数 ： プリント、複写の部数
用紙サイズ ： 処理した紙のサイズ
ユーザー名 ： 処理を指示したユーザーのユーザーＩＤ番号
ユーザー権限 ： ユーザーの業務に対する権限情報（後述）
【００２１】
また、プリンタ１２は印刷指示を実行する際に、画像ログを生成し、ネットワーク３０で接続された画像ログ蓄積サーバー２２にその画像ログを蓄積する。画像ログは、画像処理装置が指示に応じて処理（例えば印刷又はスキャン）した文書の画像データである。処理した文書が複数ページで構成される場合に、ページごとの画像データを含んだ画像ログを生成してもよい。この場合、それら複数ページの画像データをマルチページ画像データ（TIFFのような）として生成してもよい。画像ログの色空間はこの実施形態ではフルカラーとするが、これに限定されるわけではない。限定色化されたパレット画像、グレイスケール画像、白黒２値画像でも良い。画像ログのフォーマットは特に限定されないが、この実施形態ではJPEGとする。画像解像度は極端に高解像である必要は無いが、文書内容が読めないほど低解像度では効果がない。この実施形態では解像度は200dpiとする。
【００２２】
ジョブログ蓄積サーバー２０は受信したジョブログを、内蔵するデータベースなどに格納する。画像ログ蓄積サーバー２２は受信した画像ログを、内蔵するデータベースなどに蓄積する。同じジョブについてのジョブログと画像ログとは、例えば同じジョブＩＤ（識別情報）を付すなどの方法で、互いに関連づけられて格納される。本実施形態では、この関連付けられたジョブログと画像ログとを合わせてログレコードと呼ぶ。
【００２３】
実施形態では説明の便宜上、ジョブログと画像ログを別々のサーバー２０及び２２で実装する例で説明を行うがこれはあくまで一例に過ぎない。ジョブログ蓄積サーバーと画像ログ蓄積サーバーは、別のサーバーとして実装してもよいし、同一のサーバー内の別のデータベースとして実装してもよい。また、ジョブログと画像ログを一つのデータベースで管理してもよいし、さらに言えば同一のスキーマで実装してもよい。
【００２４】
解析サーバー２４は、ジョブログ蓄積サーバー２０及び画像ログ蓄積サーバー２２に蓄積されているログ情報を合わせてログレコードとして取り扱い、業務フローを解析する機能を有する。この解析処理については後で詳しく説明する。図では解析サーバー２４を独立してネットワーク３０に接続しているが、解析サーバー２４の機能をジョブログ蓄積サーバー２０或いは画像ログ蓄積サーバー２２に搭載してもよい。
【００２５】
ジョブログの属性情報の一つであるユーザー権限は、そのユーザーの業務に対する権限に関する情報である。例えば、「業務を実行する権限がある」、「業務を承認する権限がある」、「業務に対してさらに上位の承認する権限がある」などである。ユーザー権限の情報はネットワーク３０で接続されたユーザー認証サーバー２８で管理される。プリンタ１２は、ジョブログを生成する際に、ユーザーＩＤに基づいてユーザー認証サーバー２８に問い合わせて、ユーザー認証サーバー２８からユーザー権限を取得して属性情報の一つとしてジョブログに組み込む。この代わりに、プリンタ１２ではユーザー権限情報は付与しないで、ジョブログ蓄積サーバー２０に格納される段階でジョブログ蓄積サーバー２０がユーザー認証サーバー２８からユーザー権限の情報を取得し、ジョブログに記録しても良い。更に別の例として、解析サーバー２４による後述のログレコード解析でユーザー権限情報が必要になった段階で、その都度ユーザー認証サーバー２８に問い合わせても良い。
【００２６】
以上ではプリンタ１２がジョブを実行した場合について説明したが、複写機１４で紙文書を複写する際も同様である。すなわち、複写機１４は、紙文書を複写すると同時に、ジョブログと画像ログを生成し、それぞれ、ジョブログ蓄積サーバー２０、画像ログ蓄積サーバー２２に蓄積する。複写を指示したユーザーのユーザーＩＤ番号は、ＩＣカードリーダー１５から得る。印刷と異なり複写の場合には文書名は取得できないので、ジョブログの属性情報の文書名は空欄となる。
【００２７】
なお、プリントを指示したユーザーの識別情報はクライアントＰＣ１０から取得することが出来るが、複写、スキャン、ＦＡＸを指示したユーザーの識別情報はクライアントＰＣ１０から取得することが出来ない。そのため、複写機１４、スキャナ１６、ＦＡＸ装置１８にそれぞれＩＣカードリーダー１５，１７，１９を設け、これらによりユーザーのＩＤカードに格納されているユーザーＩＤ番号を読み取り、その情報をジョブログの属性情報のユーザー名とする。なお、ユーザーＩＤ番号の取得はＩＣカードリーダーに限定されるものではなく、例えば複写機のＵＩからユーザーが直接入力しても良いし、ＵＩの表示されたユーザー一覧リストから選択するようにしてもよい。
【００２８】
次に、図３Ａ〜図３Ｃを参照して、サーバー２０及び２２に蓄積されるログレコードの例を説明する。
【００２９】
図３Ａはユーザー：伊藤がプリント作業を行った時のログレコード１０２の一例を示している。すなわち、このログレコード１０２は、ユーザー:伊藤がフォームＡという帳票様式を用いてクライアントＰＣ１０で帳票を作成し多機能複写機ＭＦ１を用いて帳票を印刷した場合のものである。ジョブログの属性情報として時刻、ユーザー名、機器名、処理内容が記されており、画像ログのデータ名としてＩＭ２が記されている。この画像ログの画像データの例を図５Ｂに画像ログＩＭ２として示す。
【００３０】
同様に図３Ｂはユーザー：小川がプリント作業を行った時のログレコード１０４を示している。すなわちこのログレコード１０４は、ユーザー：小川がフォームＢという帳票様式を用いて帳票をクライアントＰＣ１０で作成し、多機能複写機ＭＦ２を用いて帳票を印刷した場合のものである。また図３Ｃはユーザー：佐藤がスキャン作業を行ったときのログレコード１０６を示している。これは、フォームＣという帳票様式の用紙を多機能複写機ＭＦ３を用いて複写した場合のものである。
【００３１】
次に、業務フローの一例に沿って、フローの各段階で生成されるジョブログ及び画像ログの例を説明する。例として用いる業務フローは、備品の購入稟議という業務についてのものであり、その概要は以下の通りである。もちろん、これはあくまで一例に過ぎない。
(a) 起票者は、自らが作成した稟議のための帳票を印刷した上で、その印刷結果に対しデート印（日付印）を押す。そして、業務の記録のために、その紙帳票をスキャンし、スキャン結果の画像データを所定の保管場所（例えばファイルサーバ）に保管する。起票者は紙帳票を確認者に回す。
(b) 確認者は、起票者から受け取った紙帳票に起票者のデート印が押されている事をチェックして確認印を押印し、その帳票のコピーを作成して保管する。オリジナルの紙帳票は承認者に回される。
(c) 承認者は、確認者から受け取った紙帳票の起票者印、確認印をチェックして承認印を押印し、その紙帳票をスキャンし、スキャン結果の画像を規則に従い所定のデータベースに保存する。
【００３２】
図４はこの業務フローに沿って行われた実際の作業の例と、それら各作業の際に生成され蓄積されたログレコードを示している。
【００３３】
まず、起票者であるユーザー：中村が、フォームＡという帳票様式に沿った帳票をクライアントＰＣで作成する。帳票様式（フォーム）は、帳票の雛形（テンプレート）のことであり、電子文書の形で用意されている。フォームは、業務フローに対応づけられている。ユーザーは、例えば、複数用意されたフォームの中から、自分が実行しようとする業務に対応するものを選べばよい。ここではフォームＡを選択するものとする。ユーザー：中村は、クライアントＰＣ１で帳票を作成し、多機能複写機ＭＦ１を用いてプリント作業を行う。このプリントの際にジョブログ１１２と、図５に示す画像ログＩＭ１１が生成される。ジョブログ１１２には、属性情報として時刻、ユーザー名、機器名、処理内容が記されており、画像ログのデータ名としてＩＭ１１が記されている。ユーザー：中村はプリントされた帳票用紙の所定の位置にデート印を押印し、自分の作業内容の記録の為にその帳票用紙を多機能複写機ＭＦ１を用いてスキャンする。このスキャンの際にもジョブログ１１４と、図５に示す画像ログＩＭ１２が生成される。
【００３４】
次に、確認者であるユーザー：鈴木が、起票者：中村から受け取った帳票を確認する。ユーザー：鈴木は、起票者が作成した帳票用紙の記載内容と起票者印があることをチェックして、確認者が確認印を押印する。この確認印が押された帳票を保存のために多機能複写機ＭＦ２で複写しておく。この複写の際にジョブログ１１６と図５の画像ログＩＭ１３が生成される。
【００３５】
次に、承認者であるユーザー：田中が、確認者：鈴木から受け取った帳票を承認する。すなわち、その帳票の記載内容と起票者印、確認者印をチェックして、承認印を捺印する。そして、この承認印が押された帳票を保存のために、スキャナＳＣ１でスキャンする。このスキャンの際にジョブログ１１８と図５に示す画像ログＩＭ１４が生成される。
【００３６】
このようにオフィス内で発生する業務に関して、プリンタ１２，複写機１４，スキャナ１６及びＦＡＸ装置１８のようにログ生成・登録機能を備えた装置を用いてユーザーが作業を行うと、ジョブログと画像ログが発生し、発生したジョブログと画像ログはジョブログ蓄積サーバー２０、画像ログ蓄積サーバー２２に格納されていく。
【００３７】
解析サーバー２４は、これら蓄積されたログレコード（ジョブログ及び画像ログのペア）を解析することで、業務フロー違反の監視を行う。以下、この監視処理について説明する。図６はフロー監視の処理手順を示したフローチャートである。
【００３８】
大略的に言えば、この監視処理では、サーバー２０及び２２に蓄積されたログレコード群を解析して、同一文書に関わるログレコードを抽出する。ここでいう「同一文書」とは、業務フローに即した個別の業務において受け渡される個別の文書（例えば起票された後、確認を受け、更に承認を受ける帳票）のことである。各処理段階で追記されたり、修正されたりすることで、記載内容が段階ごとに変化しても、同じ個別業務の文書であることに変わりがない。その意味での「同一文書」である。例えば備品の購入稟議という業務の業務フローに則って、個別業務としてある装置Ｘの購入のための稟議が行われる場合、その「装置Ｘの購入のための稟議書帳票」が、ここで言う「同一文書」に当たる。その「稟議書帳票」は、まず起票者が必要事項を書き込んで作成し、その後確認者がそれに確認印を押印するが、その作成段階の帳票と、押印段階の帳票とは「同一文書」の関係にある。
【００３９】
同一文書に関わるログレコードが抽出できると、それらを処理時刻に従って並べ替えることで、その同一文書に対して行われた各処理の順序系列を明らかにし、その処理の順序系列が、その同一文書に対応する業務フローに合致するか否かを判定する。合致していれば業務フローに沿った正しい作業が行われていると判断できる。合致しなかった場合には、通常とは異なる処理がなされているということであり、情報漏洩の可能性があるので、例えば管理者に警告を発する等の対処を行う。
【００４０】
この手順のために、解析サーバー２４はフロー情報ＤＢ（データベース）２５を備える。フロー情報ＤＢ２５には、システムが管理している個々の業務フローについて、図７に示すようにフロー定義データ２００と帳票ひな形データ２１０が登録されている。フロー定義データ２００は、当該業務フローにおける処理の流れを示す情報である。例えば、フロー定義データ２００は、その業務フローを構成する処理段階ごとに、その処理段階の処理内容を示す処理内容情報と、その処理段階を行ってよいユーザーを特定する実行者情報と、を含む。処理内容情報は、例えばプリント、スキャンなどといった処理種別を示す情報である。実行者情報は、処理段階を行ってよいユーザーのＩＤを特定したものでもよいし、ユーザーの属性が満足すべき条件を記述した情報でも良い。図７には、フロー定義の一つの例として、まず第１段階として「課員」に該当するユーザーが印刷を行い、第２段階として「課長」に該当するユーザーがスキャン又はコピーを行い、第３段階として「部長」に該当するユーザーがスキャンをする、というフローを示している。フロー定義には、必ず行われるべき処理段階だけでなく、行わなくてもよい処理段階を記述できるようにしても良い。図７の例では、第１段階を行うユーザー（課員）は、プリントを行うことは必須であるが、その後にスキャンを行ってもよい（行わなくてもよい）ことが示されている。これから分かるように、フロー定義データ２００に規定される処理段階と、画像処理装置で行われた処理を示すログレコードとは、必ずしも一対一に対応しなくてよい。図７の第１段階については、印刷だけが行われる場合もあれば、印刷とスキャンが行われる場合もあり、前者ではログレコードが１つ、後者では２つ生成されることになる。また、図に例示は指定いないが、フロー定義データ２００には、実行することが任意の（すなわち、実行してもしなくてもよい）処理段階が含まれていてもよい。
【００４１】
また、帳票ひな形データ２１０は、例えば記入欄が空欄である帳票ひな形の画像を示すデータである。
【００４２】
図６の手順を詳細に説明する。
【００４３】
この手順では、解析サーバー２４は、まず、サーバー２０に蓄積された画像ログの画像データの自動画像分類を行う（Ｓ１０）。自動分類は例えば次の手順で行う。
【００４４】
すなわち、画像ログとして蓄積されている画像データが、フロー情報ＤＢ２５に登録された帳票ひな形データ２１０のどれに合致するか否かを、フォーム判定技術を用いて判定する。フォーム判定技術は既存の技術を用いる。例えば、画像ログと帳票ひな形データ２１０の双方から、帳票の主な構成要素である表を構成する水平垂直の直線成分を画像処理で特徴量として抽出し、その抽出された直線成分の特徴量を比較することで、その画像ログがどの帳票を用いているのかを判定できる。なお、帳票ひな形データ２１０としては、帳票ひな形の画像全体を登録しておく代わりに、この特徴量だけを登録しておいてもよい。このようなフォーム判定により、蓄積された多数の画像ログを、同一種類の帳票ひな形毎の集合に分類することが出来る。すなわち、この分類は、個々のログレコードを、業務フローの種類ごとに分類することに相当する。
【００４５】
分類結果である同一種類の業務フローに該当する画像ログの集合は、その業務フローに沿って実行される個別業務で用いられる「同一文書」の画像ログからなる部分集合に更に分けることができる。そこで、この後の処理では、フォーム認識結果により分類された画像データ群の中から、同一文書を判定していく（Ｓ１２）。
【００４６】
例えば、業務フローではプリント後に担当者がデート印を押印し、その後の手続きで確認印、承認印、あるいはコメント欄にコメントが記入されることが多い。このような押印やコメント記入に影響されないで、「同一文書」を判定する必要がある。
【００４７】
押印やコメント記入は、概ね押印欄やコメント欄などといったあらかじめ決められた領域になされることが一般的なので、同一種類の帳票文書の中から同一文書を判定するには、この押印欄やコメント欄のような「追記される領域」ではない、それ以外の「追記されない領域」を画像間で比較すればよい。この「追記されない領域」の類似度が高い文書が同一文書であると判定できる。「追記されない領域」にはその文書のタイトルや、日付、作成者氏名、データなどが記載された箇所が含まれる。このような「追記されない領域」だけを参照して画像間の類似度を算出すれば、押印やコメント追記に影響されないで同一文書を判定することが可能となる。
【００４８】
図８は、図７に例示した帳票ひな形データ２１０での「追記される領域」２１２と「追記されない領域」２１４を示している。このような「追記される領域」２１２と「追記されない領域」２１４の判別情報は、ひな形作成者があらかじめ作成し、帳票ひな形データ２１０と対応づけて登録しておけばよい。
【００４９】
この同一文書判定処理（Ｓ１２）の詳細な手順の一例を図９に示す。この手順は、Ｓ１０の自動分類で得られた帳票ひな形（業務種類）ごとの画像ログ（ログレコード）の集合に対して実行される。
【００５０】
この手順では、まず当該集合に対応する帳票ひな形データ２１０から「追記されない領域」の領域情報を取得する（Ｓ３０）。次にこの領域情報に基づいて、その集合に属する各画像ログの画像データから「追記されない領域」の画像を抽出し（Ｓ３２）、抽出された領域から特徴量を抽出する（Ｓ３４）。この特徴量は、例えば画像の特徴量でもよい。具体例として、抽出領域をあるサイズのブロックに分割し、ブロックごとの平均輝度、平均色などを算出し、全ブロックの平均輝度、平均色を特徴ベクトルとして算出する。この特徴量はこのような画像特徴量に限定されない。別の具体例としては、抽出された領域に対してＯＣＲ処理により文字列を抽出し、分かち書き処理により文字列を単語に分解し、出現単語とその出現頻度の組合せを特徴量ベクトルとしてもよい。このように全ての画像から特徴量をベクトルとして抽出し（Ｓ３６）、それら全ての画像間で特徴量ベクトルを比較して類似度を算出する（Ｓ３８）。特徴量ベクトルの類似度は特徴量空間でのユークリッド距離でも良いし、他の方法で算出した距離値でも良い。この特徴量空間での距離値が近いほど類似度が高いという判定となる。この考え方は画像検索における類似度の考え方と同様である。このように求めた画像間の類似度が高い組合せを同一文書として判定していく（Ｓ４０）。この判定には予めユーザーがしきい値を設定し、そのしきい値と類似度を比較して同一か否かを判定すればよい。
【００５１】
再び図６の説明に戻る。以上に説明した同一文書の判定処理のあと、解析サーバー２４は、その判定結果に基づき、同一の業務フロー（別言すれば同一帳票種類）に該当する画像ログの集合を、同一文書ごとの部分集合に分類する（Ｓ１４）。ここで、前述のように、画像ログはジョブログと対応づけられ、両者のペアで１つのログレコードを構成している。また、「同一文書」は、１つの個別業務に該当する。したがって、この分類処理では、同じ個別業務に属するログレコードの部分集合を求めていることになる。
【００５２】
図１０はジョブログ蓄積サーバー２０と画像ログ蓄積サーバー２２に収集されたログレコードの一覧から、同一文書のログレコードを抽出した例を示している。ここでは図３の業務フローと図４の業務フローのログレコードがサーバー２０及び２２に蓄積されており、これらを解析する場合を例に説明する。
【００５３】
図１０のログレコード群３００は、ジョブログ蓄積サーバー２０と画像ログ蓄積サーバー２２に蓄積されたログレコード群の最初の状態を示している。このレコード群に対してステップＳ１０（業務＝帳票種類別に自動分類）が行われると、それらログレコード群３００が図１０に示す集合３１０（フォームＡを用いたもの）、集合３２０（フォームＢを用いたもの）及び集合３３０（フォームＣを用いたもの）に分類される。
【００５４】
これら集合３１０〜３３０の各々に対し、ステップＳ１２（同一文書の判定＝個別業務別の細分類）の処理が行われる。集合３１０の細分類結果を図１１に示す。この例では、フォームＡを用いたログレコードの中から文書＃１に対応する部分集合３１２と文書＃２に対応する部分集合３１４が抽出されている。
【００５５】
次に解析サーバー２４は、ステップＳ１４の細分類処理により求められた個別業務に対応する部分集合ごとに、当該部分集合内のログレコードを、ジョブの属性情報の１つである処理時刻の順番で並べ替える（Ｓ１６）。この並べ替えにより、部分集合内の各ログレコードの処理順序が判明する。並べ替え後の各ログレコード中のジョブログの属性情報を参照すると、その同一文書に対して行われた、処理の順番、処理を行ったユーザーの順番が判明する。更に、処理に利用された機器の場所から、その文書が移動した経路も判明する。
【００５６】
つまり、同一文書のログレコードを解析すれば、その文書に対して、いつ、誰が、どこで、何をした、という実際の作業のフローが判明する。そして、そのように判明したフローを、フロー情報ＤＢ２５に登録された当該文書に対応する業務フローのフロー定義データ２００（図７参照）と比較する（Ｓ１８）ことで、あらかじめ定められた正しい業務フローに沿って作業が行われているかどうかを判定できる。
【００５７】
図１２は、レコード解析（Ｓ１６及びＳ１８）の詳細な手順の一例を示したフローチャートである。同一文書と判定されたログレコードを、ジョブログ中の処理時刻属性の値の順に並べ替える（Ｓ５０）ことで、個々のログレコードに対応する処理を指示したユーザーの順番やそのユーザーの権限の順番、処理内容などの順番を取得することが出来る。また、その処理が行われた場所（あるいは機器）の順番を取得することもできる。また、各ログレコードの属性から、各処理が行われた時刻や、印刷又はスキャンされたページ数や部数などの情報を得ることもできる。
【００５８】
また、解析サーバー２４は、その並べ替えたログレコードにおける隣り合うログレコード同士の画像ログの画像データ間の差分画像を生成してもよい（Ｓ５２）。例えばある処理で押印されていれば、差分画像に追加された押印だけが残る。コメントを追記でも同様に、差分画像にコメント追記だけが残る。業務フローで必ず押印されることが定められている場合、差分画像における押印の有無は、業務フローが遵守されているかの判断材料となる。なお、差分画像作成時には二つの画像の位置ズレの補正、傾きの補正、濃度の正規化などを行う必要があるが、これらは既存の技術を利用すればよい。
【００５９】
解析サーバー２４は、これら得られた情報が、それら並べ替えたログレコード群で用いている帳票ひな形に対応する業務フローのフロー定義データ２００に規定される条件を満足するか否かをチェックする（Ｓ５４）。例えば、時刻順に並べ替えられたログレコードが示す各処理段階の実行者のユーザーＩＤが、フロー定義データ２００に示される各処理段階の実行者の満たすべき条件を満たしているかどうかを判定する。例えば、第１段階の処理を実行者が「課員」であるとフロー定義データ２００に定められていれば、ログレコード群から求めた第１段階の処理を指示したユーザーのＩＤに対応する職階（権限）をユーザー認証サーバー２８から求めるか、或いはログレコード中のユーザー権限属性の値から求め、求めた職階が「課員」に該当するかどうかを判定すればよい。この判定の際に、各処理段階のログレコードの処理内容属性の値がフロー定義データ２００における当該処理段階の処理内容に合致するかも判定する。以上のような判定を、同一文書についての時刻順に並べ替えたログレコードのすべてについて行えばよい。
【００６０】
例えば図１１に示した部分集合３１２は、図４に例示した個別業務のフローに対応しているが、このフローではまず中村がフォームＡに準拠した帳票の印刷を行い、更にスキャンを行い、次に鈴木がその帳票のコピーを行い、更にその次に田中がその帳票のスキャンを行っていることがわかる。ここで、中村、鈴木、田中のそれぞれの職階が課員、課長、部長であることがユーザー権限属性等から分かれば、その実際のフローが、その部分集合３１２が表すフローは、図７に示されるフォームＡに対応するフロー定義データ２００の条件を満足していることが分かる。
【００６１】
また、フロー定義データ２００の中に、個々の処理段階の処理が行われるべき場所（或いはその処理を行うべき機器）についての条件が規定されている場合には、各ログレコード中の利用場所属性の値がその条件を満たしているかを判定する。同様に、フロー定義データ２００の中に、個々の処理段階の処理が行われるべき時間帯についての条件が規定されている場合は、各ログレコード中の処理時刻属性の値がその時間帯の条件を満たしているかを判定する。また、フロー定義データ２００の中に、個々の処理段階で印刷してよいページ数又は部数（又はその両方）についての条件が規定されている場合は、各ログレコード中のページ数属性又は部数属性（又はその両方）の値がその条件を満たしているかを判定する。
【００６２】
また、フロー定義データ２００の中に、各処理を行うユーザーがそれぞれ押印をなすべきことが規定されている場合には、ステップＳ５２で求めた各段階の差分画像をチェックする。この場合、差分画像に押印が出てくるはずなので、押印画像の有無で業務フローの成否が判定できる。出るはずの差分画像が無い場合、フロー定義から逸脱した処理が行われたと判定できる。更に、各ユーザーのデート印の画像を予めユーザーＩＤと関連付けて解析サーバー２４に登録しておき、差分画像の元になった２つの画像の内の前の画像に対応するログレコードのユーザーＩＤ属性に対応するデート印の画像を検索し、その画像と差分画像とを比較することで、正しいデート印が押されているかどうかを検査することもできる。
【００６３】
この差分画像を利用した検査処理の例を、図１３を参照して説明する。図１３の差分画像は、図４の業務フローに対応しており、更に図１１の文書＃１の処理のログレコードに対応している。
【００６４】
図１３において、ＩＭ１１は図４のユーザー：中村が最初にプリントした際の画像ログである。ＩＭ１２は図４のユーザー：中村が押印してスキャンした際の画像ログである。ＩＭ１３は図４のユーザー：鈴木が中村から受け取った書類に押印してコピーした際の画像ログである。ＩＭ１４は図４のユーザー：田中が鈴木から受け取った書類に押印してスキャンした際の画像ログである。
【００６５】
ＩＭ１１とＩＭ１２の差分画像を作成すると、中村が押印したデート印が差分として抽出される。同様に、ＩＭ１２とＩＭ１３の差分画像として鈴木のデート印が、ＩＭ１３とＩＭ１４の差分画像として田中のデート印が抽出される。
【００６６】
この業務フローを使うユーザーのデート印をユーザーＩＤとひも付けてユーザー認証サーバーなどに登録しておき、差分画像で抽出されたデート印とのパターンマッチングを行い、抽出されたデート印が誰のデート印かを判定することができる。デート印と関連付けられたユーザーＩＤからユーザー認証サーバー２８に問い合わせて、ユーザー権限を取得する。例えば、中村は部員なので承認権限は無く、鈴木と田中は部課長なので承認権限をもっている、といったユーザー権限の情報を取得することが出来る。これにより、そのフォームの承認印の箇所にあるデート印に承認権限の有無を判定することが出来る。
【００６７】
以上では、差分画像を用いて押印を検査する例を示したが、差分画像を用いた検査の対象は押印に限らない。この他にも例えば、各処理段階のユーザーごとに記入欄が定められ、その記入欄に記入することが求められている場合は、差分画像に基づき各ユーザーが自分の処理段階に対応する正しい記入欄に記入を行っているかを判定できる。このためには、処理段階ごとに記入されるべき記入欄を示す情報をフロー定義データ２００に組み込んでおけばよい。
【００６８】
再び図６に戻り、以上のような判定（Ｓ１８）の結果、個別業務（同一文書）に属するログレコードの部分集合が、対応する業務フローのフロー定義データ２００に示される条件を満たしていないと判定された場合は、解析サーバー２４は、あらかじめ定められた管理者に警告を発するなどの対策処理を実行する（Ｓ２０）。警告の方法は電子メールや、管理者用コンソール画面への表示、或いはアラーム音や赤色ランプの点灯でも良い。また、ステップＳ２０で実行する対策処理は、管理者の警告に限らない。
【００６９】
この代わりに、例えば、ユーザーが画像処理装置（プリンタ１２等）に対して処理を指示した段階で、画像処理装置がその処理を実行する前に解析サーバー２４が上述のフロー逸脱の有無の判定処理を行い、逸脱していると判定された場合には、画像処理装置がその処理を実行することを禁止することもできる。この場合、画像処理装置は、指示された処理に係る文書（帳票）の画像を取得した段階で、いったんその処理の実行を保留し、ログレコードを生成して各サーバー２０及び２２に送る。解析サーバー２４は、新たなログレコードが各サーバー２０及び２２に追加されたことを検知すると、上述の図６の処理と同様の処理を実行することで、その新たに追加されたログレコードが、当該ログレコードに対応する業務フローのフロー定義データ２００の条件を満足するかどうかを判定すればよい。満足すれば、解析サーバー２４はその画像処理装置に対して保留中の処理の実行を許可し、満足しなければその画像処理装置にその処理の中止を指示すればよい。
【００７０】
なお、このように画像処理装置に対して処理が指示されるたびにリアルタイムでフロー準拠性の検査を行う場合は、サーバー２０及び２２に含まれるすべてのログレコードを解析する必要はない。この場合、例えばその処理についてのログレコードの画像ログがどの帳票ひな形に該当するかを判定し、更にどの個別業務の帳票に該当するかを判定すればよい。これらの処理は、当該ログレコードにのみ注目する点を除けば、実質的な処理内容は前述の図６の手順のステップＳ１０及びＳ１２と同様でよい。そして、求められた個別業務の過去のログレコードと当該ログレコードが、その個別業務に対応する業務フローのフロー定義データ２００に合致するかを判定すればよい。
【００７１】
また、このリアルタイム検査では、過去に行った分類の結果（例えば同一文書ごとの部分集合（処理時刻順に並んだログレコード）の情報と、それら各部分集合がそれぞれどの業務フローに対応するのかを示す情報）をデータベース（分類結果データベースと呼ぶ）に蓄積しておき、再利用してもよい。すなわち、例えば、新たにログレコードが画像処理装置から到来した場合に、そのログレコードに対応する業務フローをそのログレコード中の画像ログと各業務フローの帳票ひな形データ２１０との比較により特定する。そして、特定した業務フローに属する各「同一文書」の部分集合の中でそのログレコードに対応するものを、当該ログレコードの画像ログと、各部分集合中のログレコードの画像ログとの比較により求める（帳票ひな形データ２１０との比較はスキップし、当該ログレコードの画像ログと直接各部分集合の画像ログとを比較して、当該ログレコードに対応する「同一文書」を直接特定してもよい）。そして、求めた「同一文書」のログレコード群の後ろに当該ログレコードを付加した系列が、その「同一文書」に対応する業務フローのフロー定義データ２００に合致するかを判定すればよい。合致すると判定した場合は、当該ログレコードを分類結果データベースにおけるその「同一文書」のログレコードの部分集合の末尾に追加すればよい。
【００７２】
なお、図６の手順は、サーバー２０及び２２に蓄積されたログレコード全体に対する一括処理の例なので、この手順では、ステップＳ１２で求められた個々の個別業務（「同一文書」）ごとに、ステップＳ１４〜Ｓ２０の処理を繰り返す（Ｓ２２）。
【００７３】
以上、本発明の実施形態を説明した。以上の実施形態では、ログレコード中の画像ログを各帳票ひな形データ２１０と比較することで、そのログレコードがどの帳票ひな形データ２１０を用いる業務フローに対応するものかを判定し、その後で更にそのログレコードがどの個別業務の文書に対応するものかを判定した。しかし、これは一例に過ぎない。別の例を以下に説明する。
【００７４】
この例では、ログレコードの画像ログ同士の比較のみに基づき、「同一文書」に該当するログレコードの集合を求める。画像ログと帳票ひな形データ２１０との比較に基づく分類は行わない。
【００７５】
図１４は、この例の業務フロー監視の手順を示すフローチャートである。この手順は、図６とは異なり、帳票ひな形データ２１０に基づく業務フロー種類についての自動分類（Ｓ１２）は経ず、画像ログ同士の比較のみで同一文書判定を行う（Ｓ６０）。その他のステップは図６と同様である。ただし、ステップＳ１６では、同一文書に属すると判定したログレコードの集合がどの業務フローに対応するかを判定するために、それらログレコード中のいずれかの画像ログをフロー情報ＤＢ２５中の各帳票ひな形データ２１０と比較する。
【００７６】
ステップＳ６０の詳細な処理手順を図１５に示す。この手順で行う処理は基本的には上記実施形態の同一文書判定処理（Ｓ１２）と同様の考え方に基づく。すなわち、２つの画像間の類似度を算出して、類似度の高い（例えば類似度が予め設定されたしきい値以上となる）文書を同一文書として判定する。その二つの画像間の類似度の算出方法には、例えば、特開２００４−０２１４３０号公報に記載された方法を用いることができる。図１５は、この方法を用いた場合の手順の例を示している。
【００７７】
この手順では、まず、各画像ログを所定サイズのブロックに分割し（Ｓ８０）、ブロック毎に特徴量を抽出する（Ｓ８２）。この特徴量はブロックの平均輝度、平均色、エッジ量などである。このブロック毎の特徴量抽出を全ての画像データに対して実施する（Ｓ８４）。
【００７８】
次に全ての画像ログから２つの画像ログの組合せを選択し（Ｓ８６）、この２つの画像のブロック毎の特徴量を参照して、ブロック毎の特徴量の類似度を算出する（Ｓ８８）。類似度の算出は、画像上で同じ位置にあるブロック同士の特徴量の比較に基づき行う。例えば画像ログを１０×１０の合計１００個のブロックに分割した場合、２つの画像はそれぞれ１００個のブロックに分割される。これら各ブロックについて、まずブロック番号１番同士の類似度を算出し、次にブロック番号２番同士の類似度を算出するといった具合に、対応ブロック同士の類似度を順番に算出していく。これを繰り返すと、２つの画像間で１００個の類似度が算出される。
【００７９】
この１００個の類似度を類似度が高い順番に並べ替える（Ｓ９０）。そして類似度の高い方からＮ個までの類似度の合計値を、この２つの「画像ログ間の類似度」として算出する（Ｓ９２）。ここでＮはあらかじめ管理者等が決めたしきい値である。例えば１０×１０で１００個のブロックだった場合、Ｎは８０という値でも良い。
【００８０】
このようにして、全ての画像ログの組合せ（ペア）で類似度を算出する（Ｓ９４）。そして、そのようにして求めた類似度が高い（例えば所定のしきい値以上）画像ログ同士を同一文書として判定する（Ｓ９６）。
【００８１】
図１６は２つの画像ログ間の類似度の算出を模式的に示したものである。まず画像ログ４００と画像ログ４０２の画像間の類似度を算出する。このために画像４００と画像４０２をブロックに分割する。ここでは説明の便宜上３×４の１２ブロックに分割している。そして、ブロック毎に特徴量を算出する。２つの画像の同一位置にあるブロックの特徴量を比較する。この２つの画像は鈴木の押印の有無だけが違うので、鈴木の押印があるブロックは類似度が低く、それ以外は類似度が高い。図の比較結果４１０では、類似度が閾値以上のブロックは白色ブロック４１４で、類似度がしきい値未満のブロックは斜線ハッチングのブロック４１６で示している。画像４００と画像４０２の比較では類似度が低いブロックは１箇所である。ここで類似度が高い方から１０個のブロックの類似度の合計値を、画像ログ４００と４０２との間の類似度とすると、類似度が低いブロック（鈴木の押印があるブロック）は類似度算出に採用されないので、全体としてそれら両画像ログの類似度は高いという結果となり、それら両画像ログは同一文書であると判定出来る。
【００８２】
次に、画像４０２と画像４０４の画像間の類似度を算出する。同様に画像４０２と画像４０４をブロックに分割し、ブロック毎に特徴量を算出する。そしてブロック毎に特徴量を比較する。この２つの画像は全く別の画像であるので、類似するブロックは前の例ほど多くない。押印欄と右上の余白部分だけの類似度が高いので、比較結果４２０のような結果となる。類似度が高い方から１０個のブロックの類似度の合計値を、画像ログ４０２と４０４との間の類似度とすると、類似度が低いブロックがその中に多数含まれることになるので、前の例よりも類似度が低いという結果になる。したがって、画像ログ４０２と画像ログ４０４は同一文書ではないという判定ができる。
【００８３】
以上に例示した実施形態及び変形例における解析サーバー２４は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、図１７に示すように、ＣＰＵ１０００等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）１００２およびリードオンリメモリ（ＲＯＭ）１００４等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）１００６を制御するＨＤＤコントローラ１００８、各種Ｉ／Ｏ（入出力）インタフェース１０１０、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース１０１２等が、たとえばバス１０１４を介して接続された回路構成を有する。また、そのバス１０１４に対し、例えばＩ／Ｏインタフェース１０１０経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ１０１６、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ１０１８、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭ１００２に読み出されＣＰＵ１０００等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。なお、それら機能モジュール群のうちの一部又は全部を、専用ＬＳＩ(Large Scale Integration)、ＡＳＩＣ（Application Specific Integrated Circuit、特定用途向け集積回路）又はＦＰＧＡ（Field Programmable Gate Array）等のハードウエア回路として構成してもよい。
【図面の簡単な説明】
【００８４】
【図１】業務フローを説明するための図である。
【図２】実施形態のシステム構成の一例を示す図である。
【図３Ａ】画像処理装置による処理により生成されるログの例を示す図である。
【図３Ｂ】画像処理装置による処理により生成されるログの例を示す図である。
【図３Ｃ】画像処理装置による処理により生成されるログの例を示す図である。
【図４】実際の業務フローの例と、その各段階で生成されるログの例を示す図である。
【図５Ａ】業務フローの各段階で生成される画像ログの例を示す図である。
【図５Ｂ】画像ログとして保存される画像の例を示す図である。
【図６】解析サーバーによる監視処理の手順を示す図である。
【図７】フロー情報ＤＢに記憶される個々の業務フローの情報を模式的に説明する図である。
【図８】帳票における追記される領域と追記されない領域の例を示す図である。
【図９】同一文書判定処理の手順の一例を示すフローチャートである。
【図１０】ログレコード群の帳票種類（業務種類）ごとの分類の例を説明するための図である。
【図１１】同一の帳票種類に該当するログレコード群を同一文書ごと（すなわち個別業務ごと）の細分類を説明するための図である。
【図１２】処理時刻順にソートされたログレコード群に対する解析処理の一例を示すフローチャートである。
【図１３】差分画像を用いた検査処理を説明するための図である。
【図１４】第２の例における解析サーバーによる監視処理の手順の一例を示すフローチャートである。
【図１５】第２の例における同一文書判定の手順の一例を示すフローチャートである。
【図１６】第２の例における同一文書判定の方法を説明するための図である。
【図１７】コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【００８５】
１０ クライアントＰＣ、１２ プリンタ、１３，１５ ＩＣカードリーダー、１４ 複写機、２０ ジョブログ蓄積サーバー、２２ 画像ログ蓄積サーバー、２４ 解析サーバー、２５ フロー情報ＤＢ。
【特許請求の範囲】
【請求項１】
１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、
画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、
前記履歴記録手段に記録された各履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順についての帳票情報との比較に基づき、前記各履歴レコードに対応する業務手順を判定する業務判定手段と、
前記業務判定手段により同一の業務手順に対応すると判定された履歴レコードの集合ごとに、当該集合に含まれる各履歴レコードの対象画像同士の比較に基づき、当該集合に属する各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、
前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、
満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、
を備える画像処理監視システム。
【請求項２】
前記判定手段は、部分集合に含まれる各履歴レコードを、それら各履歴レコードに含まれる時刻情報に基づき順序づける順序づけ手段を含み、当該順序づけ手段により順序づけられた前記部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する、
ことを特徴とする請求項１記載の画像処理監視システム。
【請求項３】
前記業務手順ごとに、当該業務手順で用いられる帳票の画像のうち個別業務の全処理段階で共通する部分を示す共通部分情報を記憶する手段を更に備え、
前記分類手段は、同一の業務手順に対応すると判定された各履歴レコードの対象画像のうち当該業務手順に対応する帳票についての前記共通手順情報が示す共通部分同士の類似度に基づき、それら各履歴レコードを個別業務ごとの部分集合に分類する、
ことを特徴とする請求項１記載の画像処理監視システム。
【請求項４】
１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、
画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、
前記履歴記録手段に記録された各履歴レコードに含まれる対象画像同士の比較に基づき、それら各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、
前記特定手段が特定した同一の個別業務に属する１以上の履歴レコードについて、前記履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順の帳票情報とに基づき、前記個別業務に対応する業務手順を判定する判定手段と、
前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、前記判定手段が判定した業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、
満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、
を備える画像処理監視システム。
【請求項５】
前記判定手段は、部分集合に含まれる各履歴レコードを、それら各履歴レコードに含まれる時刻情報に基づき順序づける順序づけ手段を含み、当該順序づけ手段により順序づけられた前記部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する、
ことを特徴とする請求項４記載の画像処理監視システム。
【請求項６】
コンピュータを、
１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、
画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、
前記履歴記録手段に記録された各履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順についての帳票情報との比較に基づき、前記各履歴レコードに対応する業務手順を判定する業務判定手段と、
前記業務判定手段により同一の業務手順に対応すると判定された履歴レコードの集合ごとに、当該集合に含まれる各履歴レコードの対象画像同士の比較に基づき、当該集合に属する各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、
前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、
満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、
して機能させるためのプログラム。
【請求項７】
コンピュータを、
１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、
画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、
前記履歴記録手段に記録された各履歴レコードに含まれる対象画像同士の比較に基づき、それら各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、
前記特定手段が特定した同一の個別業務に属する１以上の履歴レコードについて、前記履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順の帳票情報とに基づき、前記個別業務に対応する業務手順を判定する判定手段と、
前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、前記判定手段が判定した業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、
満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、
して機能させるためのプログラム。
【請求項１】
１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、
画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、
前記履歴記録手段に記録された各履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順についての帳票情報との比較に基づき、前記各履歴レコードに対応する業務手順を判定する業務判定手段と、
前記業務判定手段により同一の業務手順に対応すると判定された履歴レコードの集合ごとに、当該集合に含まれる各履歴レコードの対象画像同士の比較に基づき、当該集合に属する各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、
前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、
満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、
を備える画像処理監視システム。
【請求項２】
前記判定手段は、部分集合に含まれる各履歴レコードを、それら各履歴レコードに含まれる時刻情報に基づき順序づける順序づけ手段を含み、当該順序づけ手段により順序づけられた前記部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する、
ことを特徴とする請求項１記載の画像処理監視システム。
【請求項３】
前記業務手順ごとに、当該業務手順で用いられる帳票の画像のうち個別業務の全処理段階で共通する部分を示す共通部分情報を記憶する手段を更に備え、
前記分類手段は、同一の業務手順に対応すると判定された各履歴レコードの対象画像のうち当該業務手順に対応する帳票についての前記共通手順情報が示す共通部分同士の類似度に基づき、それら各履歴レコードを個別業務ごとの部分集合に分類する、
ことを特徴とする請求項１記載の画像処理監視システム。
【請求項４】
１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、
画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、
前記履歴記録手段に記録された各履歴レコードに含まれる対象画像同士の比較に基づき、それら各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、
前記特定手段が特定した同一の個別業務に属する１以上の履歴レコードについて、前記履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順の帳票情報とに基づき、前記個別業務に対応する業務手順を判定する判定手段と、
前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、前記判定手段が判定した業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、
満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、
を備える画像処理監視システム。
【請求項５】
前記判定手段は、部分集合に含まれる各履歴レコードを、それら各履歴レコードに含まれる時刻情報に基づき順序づける順序づけ手段を含み、当該順序づけ手段により順序づけられた前記部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する、
ことを特徴とする請求項４記載の画像処理監視システム。
【請求項６】
コンピュータを、
１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、
画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、
前記履歴記録手段に記録された各履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順についての帳票情報との比較に基づき、前記各履歴レコードに対応する業務手順を判定する業務判定手段と、
前記業務判定手段により同一の業務手順に対応すると判定された履歴レコードの集合ごとに、当該集合に含まれる各履歴レコードの対象画像同士の比較に基づき、当該集合に属する各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、
前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、
満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、
して機能させるためのプログラム。
【請求項７】
コンピュータを、
１以上の業務手順の各々について、当該業務手順を構成する各処理段階の実行順序とそれら各処理段階の実行者についての条件とを含む業務定義情報と、当該業務手順で用いられる帳票を表す帳票情報と、を記憶した業務手順記憶手段と、
画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、当該指示の時刻と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、
前記履歴記録手段に記録された各履歴レコードに含まれる対象画像同士の比較に基づき、それら各履歴レコードを個別業務ごとの部分集合に分類する分類手段と、
前記特定手段が特定した同一の個別業務に属する１以上の履歴レコードについて、前記履歴レコードに含まれる対象画像と、前記業務手順記憶手段に記憶された各業務手順の帳票情報とに基づき、前記個別業務に対応する業務手順を判定する判定手段と、
前記分類手段により分類された部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、前記判定手段が判定した業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する判定手段と、
満たさないと前記判定手段が判定した場合に、所定の処理を実行する実行手段と、
して機能させるためのプログラム。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２００９−２２３３９０（Ｐ２００９−２２３３９０Ａ）
【公開日】平成２１年１０月１日（２００９．１０．１）
【国際特許分類】
【出願番号】特願２００８−６４３０７（Ｐ２００８−６４３０７）
【出願日】平成２０年３月１３日（２００８．３．１３）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
【公開日】平成２１年１０月１日（２００９．１０．１）
【国際特許分類】
【出願日】平成２０年３月１３日（２００８．３．１３）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
[ Back to top ]