JP2009224958A - 業務手順推定システム及びプログラム - Google Patents

Abstract

【課題】画像処理装置を用いて行った処理の情報に基づき、業務手順を推定する。
【解決手段】プリンタ１２や複合機１４は文書を印刷すると、印刷を指示したユーザーのＩＤ及び印刷した文書の画像を示す画像ログを含んだログレコードをサーバー２０及び２２に登録する。解析サーバー２４は、登録されたログレコード群に含まれる画像ログ同士の比較から、同一の個別業務に属するログレコードの集合を求め、それらを処理時刻の順に並べ替える。並べ替え結果における各ログレコードの各属性項目の並びに基づき、その個別業務に対応する業務フローを推定する。
【選択図】図１

Description

本発明は、業務手順推定システム及びプログラムに関する。

近年、ネットワーク技術やＰＣ（パーソナルコンピュータ）やプリンタ、複写機などの情報機器が普及しオフィスでの文書作業効率は飛躍的に向上した。しかし、その反面、これらの情報機器を利用した情報漏洩が増えてきている。例えば、社内の機密文書を不正に印刷、複写して社外に持ち出す事件などである。

このような情報漏洩の抑止や漏洩元の特定などのために、近年、プリンタや複写機、複合機（ネットワークプリンタ、ネットワークスキャナ、複写機などの機能を兼ね備えた装置）、ＦＡＸ（ファクシミリ装置）、スキャナなどの画像処理装置にて印刷、複写、ファクシミリ送信、或いはスキャンした画像を、画像ログとして保存しておく仕組みが利用されつつある。

例えば特許文献１には、プリンタや複写機で出力される際のジョブの情報（印刷した日時、機器名、文書名、操作したユーザーＩＤ（識別情報）など）をジョブログとしてサーバーに蓄積すると共に、文書のページを画像として取得し、これを文書の画像ログとして、ジョブログと関連付けてサーバーなどに蓄積しておき、情報漏洩や不具合が発生した際に、この画像ログを見て漏洩した時間、場所、漏洩した文書を特定し、漏洩元を追跡するシステムが提案されている。

また、特許文献２では、社内のシステムを監視するために、予め重要キーワードを登録しておき、ジョブログや画像ログ中にそのキーワードが出現しないか否かを監視することで、情報漏洩を瞬時に検出するシステムが提案されている。

一方、近年、企業の基幹システムにおいて業務フロー（業務手順）の分析が必要となってきた。例えば、内部統制の業務フローを明確にするための文書化作業や、事務業務を海外で実施するためのアウトソーシング時の業務仕様の文書化、などが挙げられる。

しかし、基幹システムの中で行われる業務は、購買プロセス、売上原価請求プロセス、棚卸資産管理プロセスなどと多種多様である。従来は、これらの業務の流れを分析して業務フローとして明確にして文書化するには、既存の業務フローを改訂したり、改めて業務フローを書き記したり、と多大な工数がかかっていた。

特開２００６−２１１５８７号公報 特開２００１−１０９６４７号公報

本発明は、画像処理装置で行われた処理についての画像情報を含む履歴レコードを用いて業務手順を推定するシステムを提供する。

本発明の１つの側面では、画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、その処理を実行した時刻を示す時刻情報と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、前記履歴記録手段に記録された各履歴レコードに含まれる対象画像同士の比較に基づき、それら各履歴レコードを個別業務ごとの集合に分類する分類手段と、前記分類手段により分類された集合に含まれる各履歴レコードが示す処理の内容と指示者のペアの並びに基づき、業務手順を推定する推定手段と、を備える業務手順推定システムを提供する。

１つの態様では、業務手順推定システムは、各帳票のひな形を表す各帳票情報を記憶した記憶手段を更に備え、前記分類手段は、前記履歴記録手段に記録された各履歴レコードに含まれる対象画像と、前記記憶手段に記憶された各帳票情報との比較に基づき、前記各履歴レコードに対応する帳票情報を判定する判定手段と、前記判定手段により同一の帳票情報に対応すると判定された履歴レコード群ごとに、当該履歴レコード群に含まれる各履歴レコードの対象画像同士の比較に基づき、当該履歴レコード群に属する各履歴レコードを個別業務ごとの集合に分ける細分類手段と、を備える。

更なる態様では、業務手順推定システムは、前記帳票ごとに、当該帳票の画像のうち個別業務の全処理段階で共通する部分を示す共通部分情報を記憶する手段を更に備え、前記細分類手段は、同一の帳票に対応すると判定された各履歴レコードの対象画像のうち当該帳票についての前記共通部分情報が示す共通部分同士の類似度に基づき、それら各履歴レコードを個別業務ごとの集合に細分類する。

別の態様では、前記推定手段は、前記分類手段により分類された集合に含まれる各履歴レコードを、それら各履歴レコードに含まれる時刻情報に基づき順序づけられる順序づけ手段を備え、当該順序づけ手段により順序づけられた前記部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する。

以下、本発明の実施形態を、図面を参照して説明する。

以下の実施形態において、「業務フロー」とは、オフィスなどで行われる書類を用いた作業の手順のことを示す。例えばまずユーザーであるＡ課員が、決められたフォーマットに基づいて帳票書類などをクライアントＰＣで作成してプリンタで印刷する。次に、その紙書類をＢ課長が受け取り、内容を確認して確認印（デート印）を押印し、保存用にその書類をスキャナで読み込んでＰＣに保管する。更にその書類をＣ部長が受け取り、承認印を押印し、次の部門の業務担当者に送信するためにスキャナで読み込んで、帳票文書の画像データを次部門に送信する。このような業務フローは紙文書と電子文書が混在する現在のオフィスではよく見られる。この例は、ワークフローシステムなどのようなシステムで管理されていない業務フローであるが、システムで管理された業務フローの中でも、プリンタやスキャナ、複合機などの画像処理装置を用いた印刷や読取は往々にして行われる。

図１は、本実施形態のシステム構成の一例を示す図である。以下に業務フローの例に沿って、システムの動作を説明する。

ユーザーはクライアントＰＣ（パーソナルコンピュータ）１０にログインし、業務に必要な帳票を作成し、プリンタ１２へその帳票の印刷指示を出す。プリンタ１２は帳票印刷データと印刷指示を受け取り、内蔵する記憶装置に蓄積する。印刷指示にはクライアントＰＣ１０にログインしたユーザーのＩＤ番号等が含まれる。プリンタ１２にはＩＣカードリーダー１３が接続されており、ユーザーは自分の身分証明書であるＩＣカードをＩＣカードリーダー１３に読み込ませる。プリンタ１２は、記憶装置に蓄積した印刷指示のうち、ＩＣカードリーダー１３から読み込んだユーザーＩＤ番号と一致するＩＤ番号を持つ印刷指示を実行する。

プリンタ１２は印刷指示を実行する際に、ジョブログを生成し、ネットワーク３０で接続されたジョブログ蓄積サーバー２０にジョブログを蓄積する。ジョブログは、プリンタ１２等の画像処理装置が実行したジョブ（処理）の記録データであり、例えば以下に示す各項目の属性情報を含む。なお、以下に示すのは一例に過ぎない。ジョブログは例示した項目すべてを含んでいる必要はないし、また例示した以外の項目を含んでいてもよい。
処理内容 ： プリント、複写、スキャン、ＦＡＸ等の処理内容
処理時刻 ： 処理した時刻（タイムスタンプ）
場所 ： 当該機器（プリンタなど）の設置場所（例：部屋名、フロア名など）
機器名 ： 当該機器を一意に特定する名称
文書名 ： プリント時に印刷指示された文書名（複写、スキャン、ＦＡＸ時にはこの情報は取得出来ないので空欄となる）
文書ページ数 ： 文書を構成するページ数
部数 ： プリント、複写の部数
用紙サイズ ： 処理した紙のサイズ
ユーザー名 ： 処理を指示したユーザーのユーザーＩＤ番号
ユーザー権限 ： ユーザーの業務に対する権限情報（後述）

また、プリンタ１２は印刷指示を実行する際に、画像ログを生成し、ネットワーク３０で接続された画像ログ蓄積サーバー２２にその画像ログを蓄積する。画像ログは、画像処理装置が指示に応じて処理（例えば印刷又はスキャン）した文書の画像データである。処理した文書が複数ページで構成される場合に、ページごとの画像データを含んだ画像ログを生成してもよい。この場合、それら複数ページの画像データをマルチページ画像データ（ＴＩＦＦのような）として生成してもよい。画像ログの色空間はこの実施形態ではフルカラーとするが、これに限定されるわけではない。限定色化されたパレット画像、グレイスケール画像、白黒２値画像でも良い。画像ログのフォーマットは特に限定されないが、この実施形態ではＪＰＥＧとする。画像解像度は極端に高解像である必要は無いが、文書内容が読めないほど低解像度では効果がない。この実施形態では解像度は２００ｄｐｉとする。

ジョブログ蓄積サーバー２０は受信したジョブログを、内蔵するデータベースなどに格納する。画像ログ蓄積サーバー２２は受信した画像ログを、内蔵するデータベースなどに蓄積する。同じジョブについてのジョブログと画像ログとは、例えば同じジョブＩＤ（識別情報）を付すなどの方法で、互いに関連づけられて格納される。本実施形態では、この関連付けられたジョブログと画像ログとを合わせてログレコードと呼ぶ。

実施形態では説明の便宜上、ジョブログと画像ログを別々のサーバー２０及び２２で実装する例で説明を行うがこれはあくまで一例に過ぎない。ジョブログ蓄積サーバーと画像ログ蓄積サーバーは、別のサーバーとして実装してもよいし、同一のサーバー内の別のデータベースとして実装してもよい。また、ジョブログと画像ログを一つのデータベースで管理してもよいし、さらに言えば同一のスキーマで実装してもよい。

解析サーバー２４は、ジョブログ蓄積サーバー２０及び画像ログ蓄積サーバー２２に蓄積されているログ情報を合わせてログレコードとして取り扱い、それらログレコード群から業務フローを解析する機能を有する。この解析処理については後で詳しく説明する。図では解析サーバー２４を独立してネットワーク３０に接続しているが、解析サーバー２４の機能をジョブログ蓄積サーバー２０或いは画像ログ蓄積サーバー２２に搭載してもよい。

ジョブログの属性情報の一つであるユーザー権限は、そのユーザーの業務に対する権限に関する情報である。例えば、「業務を実行する権限がある」、「業務を承認する権限がある」、「業務に対してさらに上位の承認する権限がある」などである。ユーザー権限の情報はネットワーク３０で接続されたユーザー認証サーバー２８で管理される。プリンタ１２は、ジョブログを生成する際に、ユーザーＩＤに基づいてユーザー認証サーバー２８に問い合わせて、ユーザー認証サーバー２８からユーザー権限を取得して属性情報の一つとしてジョブログに組み込む。この代わりに、プリンタ１２ではユーザー権限情報は付与しないで、ジョブログ蓄積サーバー２０に格納される段階でジョブログ蓄積サーバー２０がユーザー認証サーバー２８からユーザー権限の情報を取得し、ジョブログに記録しても良い。更に別の例として、解析サーバー２４による後述のログレコード解析でユーザー権限情報が必要になった段階で、その都度ユーザー認証サーバー２８に問い合わせても良い。

以上ではプリンタ１２がジョブを実行した場合について説明したが、複合機１４で紙文書を複写する際も同様である。すなわち、複合機１４は、紙文書を複写すると同時に、ジョブログと画像ログを生成し、それぞれ、ジョブログ蓄積サーバー２０、画像ログ蓄積サーバー２２に蓄積する。複写を指示したユーザーのユーザーＩＤ番号は、ＩＣカードリーダー１５から得る。印刷と異なり複写の場合には文書名は取得できないので、ジョブログの属性情報の文書名は空欄となる。

スキャナ１６が紙文書をスキャンする場合も同様である。すなわちスキャナ１６は、紙文書をスキャンして画像データを生成すると共に、ジョブログと画像ログを生成してサーバー２０及び２２に登録する。ＦＡＸ装置１８によるファクシミリの送信及び受信も同様であり、ＦＡＸ装置１８は、それら本来の処理動作をすると共に、ジョブログと画像ログを生成してサーバー２０及び２２に登録する。
なお、プリントを指示したユーザーの識別情報はクライアントＰＣ１０から取得することが出来るが、複写、スキャン、ＦＡＸを指示したユーザーの識別情報はクライアントＰＣ１０から取得することが出来ない。そのため、複合機１４、スキャナ１６、ＦＡＸ装置１８にそれぞれＩＣカードリーダー１５，１７，１９を設け、これらによりユーザーのＩＤカードに格納されているユーザーＩＤ番号を読み取り、その情報をジョブログの属性情報のユーザー名とする。なお、ユーザーＩＤ番号の取得はＩＣカードリーダーに限定されるものではなく、例えば複合機のＵＩからユーザーが直接入力しても良いし、ＵＩの表示されたユーザー一覧リストから選択するようにしてもよい。

図ではプリンタ１２や複合機１４，スキャナ１６，ＦＡＸ装置１８などを１台ずつ示したが、これら機器がネットワーク３０上に複数台存在してもよい。

このシステムでは、ユーザーらがプリンタ１２，複合機１４などを用いて行った作業についての画像ログを含むログレコードがジョブログ蓄積サーバー２０及び画像ログ蓄積サーバー２２に蓄積される。この実施形態では、これらログレコード群を解析サーバー２４で解析することで、それらユーザーらが行った業務フローを推定するのである。

図２に、６人のユーザーが複合機ＭＦ１、ＭＦ２、ＭＦ３、及びスキャナＳＣ１という装置を利用して、プリントやスキャンなど、それぞれ操作を行った状況を示す。図２の例では、中村がクライアントＰＣ１でフォームＡ(例えば稟議書) を利用して作成した文書をＭＦ１でプリントし、それに追記(例えばデート印を押印) した紙を、鈴木に渡し、中村はＭＦ１でスキャンして自分用に保存しておく。鈴木は、中村が追記した紙に、更に追記し、田中に渡し、自分用にＭＦ２でコピーする。田中は、中村と鈴木が追記した紙に、更に追記し、部門として管理するために、ＳＣ１でスキャンして、文書管理サーバーに保存する。

このようにオフィス内で発生する業務に関して、プリンタ１２，複合機１４，スキャナ１６及びＦＡＸ装置１８のようにログ生成・登録機能を備えた装置を用いてユーザーが作業を行うと、ジョブログと画像ログからなるログレコードが生成され、それらジョブログと画像ログはジョブログ蓄積サーバー２０、画像ログ蓄積サーバー２２に格納されていく。

図２の６人の操作がどのようにログレコードとして記録されているかを図３に示す。例えば、伊藤がクライアントＰＣ１でフォームＡを利用して文書を作成してＭＦ１でプリントした場合、ジョブログとして、ＭＦ１でプリントした時刻(２００７．０８．０１／１２：３０)、人のＩＤ（伊藤）、装置名(ＭＦ１)、操作内容(プリント) 、画像ログとして”ＩＭ２−Ｌｏｇ”という識別子で表される画像データが、レコード３として保存される。他の操作についてのログレコードも同様である。なお、図３に示したログレコードの項目はあくまで一例に過ぎない。これら項目のすべてを含む必要はないし、これら以外の項目を含んでもよい。なお、この例において蓄積されたログレコード群の一覧を図４にまとめる。

本実施形態の解析サーバー２４は、これら蓄積されたログレコードを解析することで、ユーザーらが実施している業務フローを見出す。以下、この業務フローの検出／推定処理について、図５のフローチャートを参照して説明する。

解析サーバー２４は、まず、サーバー２０及び２２に蓄積されている大量のログレコードの画像ログに対してフォーム認識処理を行い、同一フォーマット（すなわち同じ帳票ひな形から作成された）と推定される画像ログを判定する（Ｓ１１）。

フォーム認識処理では、それら各画像ログを、解析サーバー２４はフォーム情報ＤＢ２５に登録された各帳票ひな形（フォーム）データと比較することにより、それら画像ログをフォーム単位に分類する。図６に示すように、帳票ひな形データ２００は、例えば記入欄が空欄である帳票ひな形の画像を示すデータである。なお、フォーム情報ＤＢ２５には、利用される可能性のある各帳票ひな形データ２００があらかじめ管理者等により登録されているものとする。このようなフォーム判定には既存の技術を用いることができる。例えば、画像ログと帳票ひな形データ２００の双方から、帳票の主な構成要素である表を構成する水平垂直の直線成分を画像処理で特徴量として抽出し、その抽出された直線成分の特徴量を比較することで、その画像ログがどの帳票を用いているのかを判定できる。なお、帳票ひな形データ２００としては、帳票ひな形の画像全体を登録しておく代わりに、この特徴量だけを登録しておいてもよい。このようなフォーム判定により、蓄積された多数の画像ログを、同一種類の帳票ひな形毎の集合（カテゴリー）に分類することが出来る。

例えば、図４に例示した各ログレコードの画像ログのうち、図７に画像ログ”ＩＭ１１−Ｌｏｇ”、”ＩＭ１２−Ｌｏｇ”、”ＩＭ１３−Ｌｏｇ”、及び”ＩＭ１４−Ｌｏｇ”を、図８に画像ログ”ＩＭ２−Ｌｏｇ”を例示する。これら５つの画像ログは、フォーム認識（Ｓ１１）により、図７に示したフォームＡの帳票ひな形データ２００を用いたものであると判定される。したがって、図４に示したログレコードのうち、レコード１，２，３，４，６がフォームＡのカテゴリーに分類されることになる。この他、ステップＳ１１により、レコード５がフォームＢのカテゴリーに、レコード７がフォームＣのカテゴリーに、それぞれ分類されたとする。図４に例示したログレコード群に、ステップＳ１１の処理を適用した結果を、図９に示す。
次に、ステップＳ１１の分類結果である集合（カテゴリー）ごとに、類似画像検索技術などを利用して画像ログの自動分類を行う。これにより、その集合に属する各ログレコードの中で同一文書、すなわち同一の個別業務に属するものを判定し（Ｓ１２）、その集合内の各ログレコードをこの判定結果に基づき同一文書ごとの部分集合に細分類する（Ｓ１３）。

ここでいう「同一文書」とは、個別業務において受け渡される個別の文書（例えば起票された後、確認を受け、更に承認を受ける帳票）のことである。当該個別業務の各処理段階で追記されたり修正されたりすることで記載内容が段階ごとに変化しても、同じ個別業務の文書であることに変わりがない。その意味での「同一文書」である。例えば備品の購入稟議という業務の業務フローに則って、個別業務としてある装置Ｘの購入のための稟議が行われる場合、その「装置Ｘの購入のための稟議書帳票」が、ここで言う「同一文書」に当たる。その「稟議書帳票」は、まず起票者が必要事項を書き込んで作成し、その後確認者がそれに確認印を押印するが、その作成段階の帳票と、押印段階の帳票とは「同一文書」の関係にある。

ユーザーらは、ある個別業務を行う際に、その業務に対応する帳票ひな形データ２００を用いて帳票を起票する。そして起票された帳票が関係者の間で回覧される。この中で、各関係者は受け取った帳票に対して追記（押印も含む）や修正を行った上で、次の関係者にその結果の帳票を渡す。このような枠組みの中では、１つの帳票ひな形データ２００をもとに、複数の個別業務のための帳票が作成され得る。ステップＳ１２及びＳ１３では、帳票ひな形（フォーム）ごとに分類したログデータを、そのような個別業務ごとの部分集合に分けるのである。同一の個別業務で用いられた帳票かどうかは、帳票の画像（画像ログ）同士の類似度に基づき判定する。

ここで、例えば、業務フローではプリント後に担当者がデート印を押印し、その後の手続きで確認印、承認印、あるいはコメント欄にコメントが記入されることが多い。ステップＳ１２及びＳ１３では、このような押印やコメント記入に影響されないで、同一の個別業務に係る帳票の画像ログを判定する必要がある。

押印やコメント記入は、概ね押印欄やコメント欄などといったあらかじめ決められた領域になされることが一般的なので、同一の個別業務に係る画像ログを判定するには、この押印欄やコメント欄のような「追記される領域」ではない、それ以外の「追記されない領域」を画像ログ間で比較すればよい。この「追記されない領域」の類似度が高い文書が同一文書であると判定できる。「追記されない領域」にはその文書のタイトルや、日付、作成者氏名、データなどが記載された箇所が含まれる。このような「追記されない領域」だけを参照して画像間の類似度を算出すれば、押印やコメント追記に影響されないで同一文書を判定することが可能となる。

図１０は、図７に例示した帳票ひな形データ２００での「追記される領域」２０２と「追記されない領域」２０４を示している。このような「追記される領域」２０２と「追記されない領域」２０４の判別情報は、ひな形作成者があらかじめ作成し、帳票ひな形データ２００と対応づけて登録しておけばよい。

ステップＳ１２及びＳ１３の詳細な手順の一例を図１１に示す。この手順は、Ｓ１１の自動分類で得られた帳票ひな形（業務種類）ごとの画像ログ（ログレコード）の集合に対して実行される。

この手順では、まず当該集合に対応する帳票ひな形データ２００（これはＳ１１で特定済み）から「追記されない領域」の領域情報を取得する（Ｓ１２１）。次にこの領域情報に基づいて、その集合に属する各画像ログの画像データから「追記されない領域」の画像を抽出し（Ｓ１２２）、抽出された領域から特徴量を抽出する（Ｓ１２３）。この特徴量は、例えばいわゆる画像特徴量でよい。具体例として、抽出領域をあるサイズのブロックに分割し、ブロックごとの平均輝度、平均色などを算出し、全ブロックの平均輝度、平均色を特徴ベクトルとして算出する。ただし、この特徴量はこのような画像特徴量に限定されない。別の具体例としては、抽出された領域に対してＯＣＲ処理により文字列を抽出し、分かち書き処理により文字列を単語に分解し、出現単語とその出現頻度の組合せを特徴量ベクトルとしてもよい。このように全ての画像ログから特徴量をベクトルとして抽出し（Ｓ１２４）、それら全ての画像ログ間で特徴量ベクトルを比較して類似度を算出する（Ｓ１２５）。特徴量ベクトルの類似度は特徴量空間でのユークリッド距離でも良いし、他の方法で算出した距離値でも良い。この特徴量空間での距離値が近いほど類似度が高いという判定となる。この考え方は画像検索における類似度の考え方と同様である。このように求めた画像間の類似度が高い組合せを同一文書として判定していく（Ｓ１２６）。この判定には予めユーザーがしきい値を設定し、そのしきい値と類似度を比較して同一か否かを判定すればよい。

この細分類処理により、例えば図９の例においてフォームＡのカテゴリーに分類されたレコード１〜４及び６のうち、レコード１，２，４，６（図７のＩＭ１１−Ｌｏｇ、ＩＭ１２−Ｌｏｇ、ＩＭ１３−Ｌｏｇ、ＩＭ１４−Ｌｏｇに対応）が同一の個別業務の部分集合に、レコード３（図８のＩＭ２−Ｌｏｇに対応）がそれとは別の個別業務の部分集合に、分類される。フォームＡのカテゴリーについてのこの細分類結果を図１２に示す。

次に、細分類結果の部分集合内の各ログレコードのジョブログを解析することで、業務フローを推定する（Ｓ１４）。ステップＳ１４の詳細な手順を図１３に示す。

この手順では、部分集合中のログレコードを処理時刻（タイムスタンプ）の順に並べ替え（Ｓ２１）、それら各ログレコードの内容の並びに基づき、業務フローを推定する（Ｓ２２）。

図１４に、図１２の分類１の部分集合の各ログレコードを、ステップＳ２１の処理により、処理時刻の順に並べ替えた結果を示す。

ステップＳ２２では、並べ替えたログレコード群の情報、例えば各ジョブログ内の属性値の並び順から、業務フローを解析する。例えば、ジョブログ内のユーザーＩＤが、それら並べ替えたログレコード群の中で並んでいる順番から、業務フローを推定できる。図１４の例の場合、このフォームＡに関しては、「フォームＡの帳票は、中村→鈴木→田中の順番で回覧される」という業務フローが推定できる。

ここで、ユーザーＩＤに対して、ユーザー権限や役職などを紐付けておけば、個人のユーザーＩＤで表現した業務フローのみならず、帳票の回覧順をユーザー権限や役職の並び順で示した汎用的な業務フローが推定できる。例えば、中村、鈴木、田中、に対して、それぞれ課員、課長、部長、という役職を紐付けておけば、先ほどのフローは、「フォームＡの帳票は、課員→課長→部長の順番で回覧される」という業務フローが推定できる。ユーザーＩＤとユーザー権限又は役職との対応関係は、例えばユーザー認証サーバー２８に登録しておけばよい。

また、ジョブログ内のユーザーＩＤと処理内容のペアに着目すれば、「フォームＡの帳票は、中村が印刷してスキャンし、次に鈴木がコピーし、最後に田中がスキャンする」という業務フローが推定できる。ユーザー権限又は役職の情報を用いれば、更に「フォームＡの帳票は、課員が印刷してスキャンし、次に課長がコピーし、最後に部長がスキャンする」という業務フローが推定できる。

また、更にジョブログ中の機器名属性を利用すれば、例えば、「フォームＡの帳票は、課員が複合機ＭＦ１で印刷及びスキャンし、次に課長が複合機ＭＦ２でコピーし、最後に部長がスキャナＳＣ１でスキャンする」という業務フローが推定できる。また、各機器名に対応づけてその機器が設置された場所を解析サーバー２４に登録しておけば、機器の代わりにユーザーが各処理段階を行う場所を示した業務フローを推定できる。

以上の各例は、１つの個別業務についてのログレコード群から業務フローを推定する例であった。この実施形態の解析サーバー２４は、同一の帳票ひな形に対応する複数の個別業務のログレコード群を総合して業務フローを推定することもできる。

例えば、フォームＡを用いた個別業務に対応するログレコードの部分集合として、既に説明した図１４の分類１の他に、図１５に示す分類１２が求められたとする。この場合、解析サーバー２４は、それら複数の部分集合のログレコードの並びの比較に基づき、１つの個別業務の情報だけから求めるよりも汎用性の高い業務フローを推定する。例えば、図１５の例で、レコード１１の処理を行った山田が課員であったとする。この場合、図１４の分類１と図１５の分類１２の最初のレコード同士（レコード１とレコード１１）の比較では、ユーザーＩＤ以外の処理内容や機器名の属性項目の値は一致しており、ユーザーＩＤに関しても役職の観点では一致していることが分かる。このことから、「フォームＡの帳票は、最初に課員が印刷する」というフロー要素が推定できる。

次に、分類１と分類１２の各々の２番目レコード２と１２を比較する。しかし、これら両者は、レコード内の属性項目の組合せが整合しない。すなわち、レコード２と１２の各属性項目の値を、順次それに紐付けて登録された値（例えばユーザーに対しては役職、機器名に対しては設置場所）に入れ替えて両者の比較をした場合に、どの項目を入れ替えても両者は一致しない。したがって、レコード２と１２のうちのどちらかは、必須の処理段階ではない可能性がある。レコード２と分類１２のレコード１５とを比べた場合も、同様に属性項目値の入れ替えを行っても両者の一致が見られないので、結局レコード２に対応するログレコードが分類１２の中にないことが分かる。一方、レコード１２については、分類１の中のレコード６と、ユーザーＩＤ、機器名、処理内容の各項目が一致する。このことから、レコード２が表す処理段階は、必須でない（すなわち実行するもしないも任意）と推定できる。そして、レコード６と１２のペア、レコード４と１５のペアは、それぞれユーザーＩＤ、機器名、処理内容の各項目値が一致しているので、それらペアはそれぞれ同一の処理段階を表しているものと推定できる。これらを総合すると、「フォームＡの帳票は、最初に課員が印刷し、その後その課員はその帳票をスキャンしてもよく、更にその次に課長がその帳票をコピーし、最後に部長がその帳票をスキャンする」という業務フローが推定できる。もちろんこの場合も、各処理段階で用いる機器名やそれに対応する設置場所を業務フローに記述することもできる。

また、部分集合に含まれる時刻順の各ログレコードの画像ログについて、隣り合う画像ログ同士の差分画像を求めることで、各処理段階での追記や押印の要否を求め、その情報を業務フローに記述してもよい。

例えば図１６の例において、ＩＭ１１は図３の例で中村が最初にプリントした際の画像ログである。ＩＭ１２は中村が押印してスキャンした際の画像ログである。ＩＭ１３は鈴木が中村から受け取った書類に押印してコピーした際の画像ログである。ＩＭ１４は田中が鈴木から受け取った書類に押印してスキャンした際の画像ログである。

ＩＭ１１とＩＭ１２の差分画像を作成すると、中村が押印したデート印が差分として抽出される。同様に、ＩＭ１２とＩＭ１３の差分画像として鈴木のデート印が、ＩＭ１３とＩＭ１４の差分画像として田中のデート印が抽出される。このことから「フォームＡの帳票は、中村（課員）が印刷して押印した後スキャンし、次に鈴木（課長）が押印の後コピーし、最後に田中（部長）が押印の後スキャンする」という業務フローが推定できる。ユーザーのデート印の印影をユーザーＩＤと紐付けてユーザー認証サーバー２８などに登録しておけば、誰が押印したかも判定できるので、上述のようなフローが推定できる。

以上では、差分画像を用いて押印の有無を判定する例を示したが、差分画像を用いた判定の対象は押印に限らない。この他にも例えば、帳票の中にユーザーごとに記入欄が設けられている場合は、各処理段階で誰がどの記入欄に記入するかを求め、その情報を業務フローに記述することができる。

以上に説明した業務フローの推定法はあくまで一例に過ぎない。

上述の例から分かるように、１つの帳票ひな形に対応するログレコードの部分集合が１以上求められた場合、それら１以上の部分集合から推定される業務フローは１つに限らない。例えば、処理段階を実行する人をユーザーＩＤで特定した業務フローと役職で特定した業務フローの両方が同時に推定される場合がある。そこで、これら複数の業務フローを解析サーバー２４の操作者に提示し、操作者がその中で採用するものを選択する仕組みとしてもよい。

また、解析サーバー２４が推定する業務フローは必ずしも正確とはいえないので、推定した業務フローを解析サーバー２４の操作者に提示し、操作者から修正を受けてから正式の業務フローとして採用するようにしてもよい。

以上、実施形態を説明した。次に、実施形態の変形例を説明する。上述の実施形態では、業務フローの推定処理の際に、同一文書ごとについての細分類の結果であるログレコード群（部分集合）を処理時刻（タイムスタンプ）で並べ替えることで、業務の流れを求めた。これに対して、この変形例では、処理時刻ではなく、処理内容属性の値で分類することで、業務の流れに関する情報を求める。

この変形例の処理の説明のための題材として用いる作業の流れを図１７に示す。この例は図２の例に似ている。相違点は、鈴木がコピーではなくスキャンを行う点と、中村、鈴木、及び田中がそれぞれスキャンした画像を共通の格納場所（図ではデータベースＤＢ１）に登録している点である。格納場所は、例えばユーザーがスキャン時にＵＲＬなどで指定すればよい。

この例では、処理内容がスキャンの場合、ジョブログの機器名属性に、スキャンした機器の名前の代わりに、スキャンした画像の登録先の機器（この場合はＤＢ１）の名前を登録するものとする（この代わりに、画像の登録先の機器名の属性項目を追加し、これとスキャンした機器名の両方を記録してもよい）。

解析サーバー２４が行う処理の大略的な流れは図５に示したものと同様である。ステップＳ１３間での処理を行うことで、図１７の例からは、フォームＡに対応するログレコード群に関して、図１８に示すような同一文書ごとの細分類結果の部分集合が得られる。ここまでの流れは上記実施形態と変わらないが、この次に行われる業務フローの推定処理は上記実施形態と異なる。この変形例における業務フローの推定処理の手順の例を図１９に示す。この例では、細分類で求められた部分集合を、処理内容属性の値で更に分類する（Ｓ３１）。例えば、「スキャン」という処理内容に該当するものを抽出した場合、図２０に示すようにレコード２，４，６が得られる。

解析サーバー２４は、この分類結果において１つの処理内容に複数のログレコードが該当することが分かった場合、それら複数のログレコードの属性の共通点を求め、その共通点から業務フローに関する条件を求める（Ｓ３２）。例えば、図２０の例では、分類結果の１分類に属するすべてのログレコードが、スキャン画像を同一のデータベースＤＢ１に登録していることが分かる。これにより「中村（課員）、鈴木（課長）、田中（部長）の各人がスキャンを行い、スキャン結果の画像をいずれもデータベースＤＢ１に格納する」という業務フローについての条件が求められる。

また、ステップＳ３１の分類結果の１分類に属する各ログレコードを、各ユーザーＩＤに対応する役職或いはユーザー権限について並べ替えてもよい。並べ替えの順序は、例えば、役職或いはユーザー権限の昇順でよい。役職或いはユーザー権限は、ユーザー認証サーバー２８から求めればよい。この並べ替えの結果に対してステップＳ３２の解析を行うことで、「中村（課員）、鈴木（課長）、田中（部長）の各人がスキャンを行い、スキャン結果の画像をその順にバージョン管理しながらデータベースＤＢ１に格納する。」という業務フローが解析できる。

以上で説明した各例では、ログレコード中の画像ログを各帳票ひな形データ２００と比較することで、そのログレコードがどの帳票ひな形データ２００を用いる業務フローに対応するものかを判定し、その後で更にそのログレコードがどの個別業務の文書に対応するものかを判定した。しかし、これは一例に過ぎない。別の例を以下に説明する。

この例では、ログレコードの画像ログ同士の比較のみに基づき、「同一文書」に該当するログレコードの集合を求める。画像ログと帳票ひな形データ２００との比較に基づく分類は行わない。

この場合、解析サーバー２４は、例えば図２１に示す手順で、「同一文書」に該当するログレコードの集合を求める。この手順では、２つの画像ログ間の類似度を算出して、類似度の高い（例えば類似度が予め設定されたしきい値以上となる）画像ログ同士を同一文書と判定する。その二つの画像ログ間の類似度の算出方法には、例えば、特開２００４−０２１４３０号公報に記載された方法を用いることができる。図２１は、この方法を用いた場合の手順の例を示している。

この手順では、まず、各画像ログを所定サイズのブロックに分割し（Ｓ４１）、ブロック毎に特徴量を抽出する（Ｓ４２）。この特徴量はブロックの平均輝度、平均色、エッジ量などである。このブロック毎の特徴量抽出を全ての画像データに対して実施する（Ｓ４３）。

次に全ての画像ログから２つの画像ログの組合せを選択し（Ｓ４４）、この２つの画像のブロック毎の特徴量を参照して、ブロック毎の特徴量の類似度を算出する（Ｓ４５）。類似度の算出は、画像上で同じ位置にあるブロック同士の特徴量の比較に基づき行う。例えば画像ログを１０×１０の合計１００個のブロックに分割した場合、２つの画像はそれぞれ１００個のブロックに分割される。これら各ブロックについて、まずブロック番号１番同士の類似度を算出し、次にブロック番号２番同士の類似度を算出するといった具合に、対応ブロック同士の類似度を順番に算出していく。これを繰り返すと、２つの画像間で１００個の類似度が算出される。

この１００個の類似度を類似度が高い順番に並べ替える（Ｓ４６）。そして類似度の高い方からＮ個までの類似度の合計値を、この２つの「画像ログ間の類似度」として算出する（Ｓ４７）。ここでＮはあらかじめ管理者等が決めたしきい値である。例えば１０×１０で１００個のブロックだった場合、Ｎは８０という値でも良い。

このようにして、全ての画像ログの組合せ（ペア）で類似度を算出する（Ｓ４８）。そして、そのようにして求めた類似度が高い（例えば所定のしきい値以上）画像ログ同士を同一文書として判定する（Ｓ４９）。

図２２は２つの画像ログ間の類似度の算出を模式的に示したものである。まず画像ログ４００と画像ログ４０２の画像間の類似度を算出する。このために画像ログ４００と画像ログ４０２をブロックに分割する。ここでは説明の便宜上３×４の１２ブロックに分割している。そして、ブロック毎に特徴量を算出する。２つの画像の同一位置にあるブロックの特徴量を比較する。この２つの画像は鈴木の押印の有無だけが違うので、鈴木の押印があるブロックは類似度が低く、それ以外は類似度が高い。図の比較結果４１０では、類似度が閾値以上のブロックは白色ブロック４１４で、類似度がしきい値未満のブロックは斜線ハッチングのブロック４１２で示している。画像ログ４００と画像ログ４０２の比較では類似度が低いブロックは１箇所である。ここで類似度が高い方から１０個のブロックの類似度の合計値を、画像ログ４００と４０２との間の類似度とすると、類似度が低いブロック（鈴木の押印があるブロック）は類似度算出に採用されないので、全体としてそれら両画像ログの類似度は高いという結果となり、それら両画像ログは同一文書であると判定出来る。

次に、画像ログ４０２と画像ログ４０４の画像間の類似度を算出する。同様に画像ログ４０２と画像ログ４０４をブロックに分割し、ブロック毎に特徴量を算出する。そしてブロック毎に特徴量を比較する。この２つの画像は全く別の画像であるので、類似するブロックは前の例ほど多くない。押印欄と右上の余白部分だけの類似度が高いので、比較結果４２０のような結果となる。類似度が高い方から１０個のブロックの類似度の合計値を、画像ログ４００と４０２との間の類似度とすると、類似度が低いブロックがその中に多数含まれることになるので、前の例よりも類似度が低いという結果になる。したがって、画像ログ４０２と画像ログ４０４は同一文書ではないという判定ができる。

以上に例示した各例における解析サーバー２４は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、図２３に示すように、ＣＰＵ１０００等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）１００２およびリードオンリメモリ（ＲＯＭ）１００４等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）１００６を制御するＨＤＤコントローラ１００８、各種Ｉ／Ｏ（入出力）インタフェース１０１０、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース１０１２等が、たとえばバス１０１４を介して接続された回路構成を有する。また、そのバス１０１４に対し、例えばＩ／Ｏインタフェース１０１０経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ１０１６、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ１０１８、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭ１００２に読み出されＣＰＵ１０００等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。なお、それら機能モジュール群のうちの一部又は全部を、専用ＬＳＩ(Large Scale Integration)、ＡＳＩＣ（Application Specific Integrated Circuit、特定用途向け集積回路）又はＦＰＧＡ（Field Programmable Gate Array）等のハードウエア回路として構成してもよい。

実施形態のシステム構成の一例を示す図である。 あるオフィスで行われた作業の流れの例を示す図である。 図２に示された作業の各段階で生成されるログレコードの例を示す図である。 図３に示したログレコードを識別番号順に並べて示した図である。 解析サーバーによる業務フローの推定処理の手順を示す図である。 帳票ひな形の一例を示す図である。 業務フローの各段階で生成される画像ログの例を示す図である。 画像ログとして保存される画像の例を示す図である。 図４のログレコード群をフォーム（帳票ひな形）ごとに分類した結果を示す図である。 帳票における追記される領域と追記されない領域の例を示す図である。 同一文書判定処理の手順の一例を示すフローチャートである。 １つのフォームに対応するログレコード群を同一文書ごと（すなわち個別業務ごと）に細分類した結果を示す図である。 細分類されたログレコード群に対する解析処理の一例を示すフローチャートである。 図１３の解析処理の対象となるログレコード群の例を示す図である。 図１３のログレコード群と同じフォームに対応する別のログレコード群の例を示す図である。 差分画像を用いた判定処理を説明するための図である。 変形例の処理において事例として取り扱う作業の流れの例を示す図である。 図１７の作業の流れの例から求められた、同一文書ごとのログレコードの部分集合の例を示す図である。 同一文書判定の手順の別の例を示すフローチャートである。 変形例におけるログレコードの部分集合に対する解析処理の一例を示すフローチャートである。 同一文書判定処理の別の例を示すフローチャートである。 図２０の例における同一文書判定の方法を説明するための図である。 コンピュータのハードウエア構成の一例を示す図である。

符号の説明

１０ クライアントＰＣ、１２ プリンタ、１３，１５ ＩＣカードリーダー、１４ 複合機、２０ ジョブログ蓄積サーバー、２２ 画像ログ蓄積サーバー、２４ 解析サーバー、２５ フォーム情報ＤＢ。

Claims (5)

1. 画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、その処理を実行した時刻を示す時刻情報と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、
   前記履歴記録手段に記録された各履歴レコードに含まれる対象画像同士の比較に基づき、それら各履歴レコードを個別業務ごとの集合に分類する分類手段と、
   前記分類手段により分類された集合に含まれる各履歴レコードが示す処理の内容と指示者のペアの並びに基づき、業務手順を推定する推定手段と、
   を備える業務手順推定システム。
2. 各帳票のひな形を表す各帳票情報を記憶した記憶手段を更に備え、
   前記分類手段は、
   前記履歴記録手段に記録された各履歴レコードに含まれる対象画像と、前記記憶手段に記憶された各帳票情報との比較に基づき、前記各履歴レコードに対応する帳票情報を判定する判定手段と、
   前記判定手段により同一の帳票情報に対応すると判定された履歴レコード群ごとに、当該履歴レコード群に含まれる各履歴レコードの対象画像同士の比較に基づき、当該履歴レコード群に属する各履歴レコードを個別業務ごとの集合に分ける細分類手段と、
   を備える請求項１記載の業務手順推定システム。
3. 前記帳票ごとに、当該帳票の画像のうち個別業務の全処理段階で共通する部分を示す共通部分情報を記憶する手段を更に備え、
   前記細分類手段は、同一の帳票に対応すると判定された各履歴レコードの対象画像のうち当該帳票についての前記共通部分情報が示す共通部分同士の類似度に基づき、それら各履歴レコードを個別業務ごとの集合に細分類する、
   ことを特徴とする請求項２記載の業務手順推定システム。
4. 前記推定手段は、前記分類手段により分類された集合に含まれる各履歴レコードを、それら各履歴レコードに含まれる時刻情報に基づき順序づけられる順序づけ手段を備え、当該順序づけ手段により順序づけられた前記部分集合内の各履歴レコードが示す処理の内容と指示者のペアの並びが、当該部分集合に対応する業務手順の業務定義情報が示す各処理段階の実行順序と各処理段階の実行者についての条件とを満たすか否かを判定する、
   ことを特徴とする請求項１記載の業務手順推定システム。
5. コンピュータを、
   画像処理装置に対して指示された処理について、その処理の実行を指示した指示者と、その処理を実行した時刻を示す時刻情報と、その処理の内容と、その処理の対象である対象画像と、を含む履歴レコードを記録する履歴記録手段と、
   前記履歴記録手段に記録された各履歴レコードに含まれる対象画像同士の比較に基づき、それら各履歴レコードを個別業務ごとの集合に分類する分類手段と、
   前記分類手段により分類された集合に含まれる各履歴レコードを、それら各履歴レコードに含まれる時刻情報に基づき順序づける順序づけ手段と、
   前記順序づけ手段により順序づけられた前記集合内の各履歴レコードが示す処理の内容と指示者のペアの並びに基づき、業務手順を推定する推定手段と、
   して機能させるためのプログラム。

Images