JP2018124656A - 画像処理装置とその制御方法、及びプログラム - Google Patents

Abstract

【課題】複雑なファイル命名ルールを設定することにより、誤認識による影響を大きく軽減できるが、このような複雑な命名ルールを登録するのはユーザにとって大きな負担となっていた。【解決手段】画像データのファイル名を作成する命名ルールに従って、取得した画像データのファイル名を作成するとともに、ユーザの指示に応じて命名ルールを変更し、その変更された命名ルールを、対応する画像データの識別情報とともにメモリに記憶する。そして、取得した画像データに類似する画像データの命名ルールが、そのメモリに記憶されているかどうか判定し、記憶されているときは当該類似する画像データの命名に使用した命名ルールを使用し、その取得した前記画像データのファイル名をユーザに提示する。【選択図】 図３

Description

本発明は、画像処理装置とその制御方法、及びプログラムに関する。

帳票等の紙文章（原稿）を読取装置で読み取り、その原稿の画像をデジタル化した画像データを得る業務フローが存在する。その際、そのデジタル化した画像データに、その原稿の種類や内容に応じたファイル名を付与して所定のフォルダに格納することが行われる。このときファイル名の付与をユーザが手入力で行うと、原稿の種類や枚数が多くなるとユーザにとって大きな負担となる。特に、ユーザインターフェース（ＵＩ）の制約により、ユーザがソフトウェアキーボードを使用してファイル名を入力する場合は、ユーザの負担はより大きくなる。また、こうして作成したファイルの格納先を指定する場合、新たなフォルダを作成することが必要となることもあり、これもユーザにとって負荷が大きくなる。

このような問題を解決する手法として、特許文献１には以下の方法が記載されている。まず原稿の種類と、ファイル命名ルールや格納先ルール等とを関連付けて登録しておき、読み取った原稿の種類を認識して、それに対応する命名ルールや格納先ルールを用いて、自動的にファイル名や格納先をユーザに推奨する。これによりユーザは、一度、原稿の種類ごとにファイル命名ルールや格納先ルールを設定するだけで、それ以降のファイルの命名や格納先を指定する必要が無くなるため、ユーザの負荷を大きく軽減できる。

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

上述の先行技術は、推奨設定をユーザが予め登録する必要があり、複雑なファイル命名ルールを登録しようとするユーザにとって大きな負担となる。この複雑な命名ルールを登録することによるユーザの負担は、複雑な命名ルールを規定するための多くのユーザ操作が必要となることに起因している。例えば、単にファイルに名称を付すだけであれば、読み取った原稿の特定の箇所の文字認識（ＯＣＲ）の結果を利用し、その認識した文字列を用いてファイル名に使用するように指示すればよい。しかしながら、より精度の高いファイルの命名を可能にするためには、複雑なファイル命名ルールを登録する必要がある。例えば、「請求書番号２２０３５」という文字認識の結果を利用して、「請求書番号２２０３５．ＰＤＦ」というファイル名を付したいときは、ユーザは、文字認識の結果の選択と、拡張子の選択とを行えばよい。

しかしながら、ファイル命名ルールを登録する際、その文字認識を行う原稿の箇所と、それ以外の箇所とを分けて登録する必要があり、また文字認識の種類を指定するのが好ましい。上述の例において、例えば「請求書番号」が同じ種類の原稿の画像データのファイル名に共通する固定的な文字列であり、「２２０３５」の部分が各原稿に応じて変更する部分で、この変更する部分は数字のみで構成されているとする。この場合、固定的な文字列「請求書番号」と、「２２０３５」が記述されている部分とを数字限定で文字認識し、その結果と拡張子とを組み合わせてファイル名とするルールを登録する。こうすることにより、同じ種類で、その内容が異なる原稿の画像データで、例えば「請求書番号」が「言青書番号」と誤認識されたとしても固定文字列を利用するように指定しているため、誤認識によるファイル名への影響はない。また文字認識の結果を利用する部分でも、文字認識の対象となる文字列を数字に限定すると、例えば数字の０（ゼロ）をアルファベットのｏ（オー）と誤って認識されることもなくなる。このように複雑なファイル命名ルールを設定することにより、誤認識による影響を大きく軽減できるようになるが、このような命名ルールを登録するのはユーザにとって大きな負担となっていた。

本発明の目的は、上記従来技術の課題を解決することにある。

本発明の目的は、ユーザの負担を軽減して、複雑な命名ルールを登録でき、その命名ルールを用いてユーザが意図するファイル名を提示できる可能性を高める技術を提供できる技術を提供することにある。

上記目的を達成するために本発明の一態様に係る画像処理装置は以下のような構成を備える。即ち、
原稿の画像データを取得する取得手段と、
前記画像データのファイル名を作成する命名ルールに従って、前記取得手段により取得した画像データのファイル名を作成する作成手段と、
ユーザの指示に応じて前記命名ルールを変更する変更手段と、
前記変更手段により変更された前記命名ルールを、対応する画像データの識別情報とともに記憶する記憶手段と、
前記取得手段により取得した前記画像データに類似する画像データの命名ルールが前記記憶手段に記憶されているかどうか判定し、記憶されているときは当該類似する画像データの命名に使用した命名ルールを使用して、前記取得手段により取得した前記画像データのファイル名をユーザに提示する提示手段と、を有することを特徴とする。

本発明によれば、ユーザの負担を軽減して、複雑な命名ルールを登録でき、その命名ルールを用いてユーザが意図するファイル名を提示できる可能性を高めることができる。

本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。尚、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。

添付図面は明細書に含まれ、その一部を構成し、本発明の実施形態を示し、その記述と共に本発明の原理を説明するために用いられる。
本発明の実施形態１に係る情報処理システムの構成例を示すブロック図。 実施形態１に係る画像処理装置が原稿を読み取り、その画像データにファイル名を付与し、そのファイル名をファイル命名装置に送信する処理を説明するフローチャート。 実施形態１に係るファイル命名装置による画像データのファイルの命名のための情報を生成する処理を説明するフローチャート。 図２のＳ２０１で読み取られる原稿の一例を示す図。 実施形態１に係る画像処理装置の表示部に表示されるファイルの命名用のＵＩの一例を示す図。 実施形態１に係る画像処理装置の表示部に表示されるファイルの命名用のＵＩの一例を示す図。 実施形態１に係る画像処理装置の表示部に表示されるファイルに命名用のＵＩの他の例を示す図。 実施形態１に係るファイル命名ルールを説明する図。 実施形態１に係る別のファイル命名ルールの詳細を説明する図。 実施形態１に係る図９の＜ＯＣＲ領域１＞のルールの更新の一例を説明する図。 実施形態１に係るファイル命名ルールのＯＣＲ設定の一例を説明する図。 実施形態２に係るファイル命名装置による画像データのファイルの命名のための情報を生成する処理を説明するフローチャート。

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

［実施形態１］
図１は、本発明の実施形態１に係る情報処理システムの構成例を示すブロック図である。実施形態１に係るシステムは、スキャナ等で原稿を光学的に読み取ってその原稿の画像データを取得し、その画像データのファイルにファイル名を付与するシステムとして説明する。図１に示すように、このシステムは、画像処理装置１００、ファイル命名装置１２０とを備えている。ここで画像処理装置１００とファイル命名装置１２０とは、ネットワーク１５０を介して相互にデータ通信可能に接続されている。

画像処理装置１００は、ユーザインターフェース（ＵＩ）１０４、ＣＰＵ１０５、ＲＡＭ１０６、記憶部１０７、画像読取部１０８、画像出力部１０９、表示部１１０を備え、これらは制御部１０１を介して相互に通信可能に接続されている。制御部１０１は、画像処理装置１００全体を制御する装置制御部１０２と、画像データを処理する画像処理部１０３とを有する。

ＣＰＵ１０５は、画像処理装置１００の電源がオンされると記憶部１０７の初期プログラムを実行して、メインプログラムを記憶部１０７より読出してＲＡＭ１０６に展開する。ＲＡＭ１０６はプログラムの格納用や、ワーク用のメインメモリとして使用される。そしてＣＰＵ１０５は、そのＲＡＭ１０６に展開したプログラムを実行することにより、この画像処理装置１００の動作を制御する。よって制御部１０１の装置制御部１０２、画像処理部１０３等の機能は、ＣＰＵ１０５が上述のプログラムを実行することにより達成される。

画像読取部１０８は、例えばスキャナ等であり、紙文書（原稿）を読取って、その原稿の画像をデジタル化した画像データを取得する。制御部１０１は、画像読取部１０８で得られた画像データを受取ると、それを記憶部１０７に記憶する。そして制御部１０１は、後述する命名処理を実行する際に、その記憶部１０７に記憶された画像データを、ネットワーク１５０を介してファイル命名装置１２０に送信する。また制御部１０１は、ファイルに命名するための情報を、ネットワーク１５０を介して、ファイル命名装置１２０から受信する。このファイルの命名のための情報については、詳しく後述する。

制御部１０１は、記憶部１０７に記憶されている原稿の画像データと、ファイル命名装置１２０から受信したファイルに命名するための情報とを用いて、ファイルに命名するためのＵＩ画面を生成して表示部１１０に表示する。また制御部１０１は、記憶部１０７に記憶された原稿の画像データを画像出力部１０９に供給すると、画像出力部１０９は、種々の形式でその画像データを出力する処理を実行する。例えば、画像出力部１０９は、その原稿に係る画像データを記憶媒体に記憶する処理を実行する。或いは、画像出力部１０９は、紙媒体等の媒体に、その画像データに基づく画像を印刷する処理を実行する。

ユーザインターフェース１０４は、例えばキーボード、マウス（登録商標）、その他入出力装置を含み、各種の設定値又は指定値を入力して設定できる。実施形態１に係るユーザインターフェース１０４は、ユーザがファイルの命名を行うのに利用される。命名したファイル名は、制御部１０１がネットワーク１５０を介して、ファイル命名装置１２０に送信する。

以上説明した画像処理装置１００はあくまでも一例であり、画像読取部１０８及び画像出力部１０９のうち、画像出力部１０９を有さない構成の画像処理装置１００であってもよい。

ファイル命名装置１２０は、ＣＰＵ１２７、ＲＡＭ１２８、記憶部１２９、表示部１３０、ユーザインターフェース（ＵＩ）１３１を備え、これらは制御部１２１を介して相互に通信可能に接続されている。制御部１２１はさらにファイル命名装置１２０全体を制御する装置制御部１２２と、ファイル命名のための情報を生成するファイル命名部１２３とを有する。実施形態１に係るファイル命名部１２３は、画像データの文字認識処理（ＯＣＲ）を行うＯＣＲ部１２４と、画像データ同士のマッチングを行うマッチング部１２５と、画像データのファイル名の推定を行うファイル名推定部１２６とを有する。

ユーザインターフェース１３１は、例えばキーボード、マウス（登録商標）、その他入出力装置を含み、各種の設定値または指定値を入力することができる。ＣＰＵ１２７は、ファイル命名装置１２０の電源オン時に記憶部１２９の初期プログラムを実行し、メインプログラムを記憶部１２９より読み出してＲＡＭ１２８に展開する。ＲＡＭ１２８はプログラムの格納用や、ワーク用のメインメモリとして使用される。そしてＣＰＵ１２７は、そのＲＡＭ１２８に展開したプログラムを実行することにより、このファイル命名装置１２０の動作を制御する。よって後述する制御部１２１の機能は、ＣＰＵ１２７が上述のプログラムを実行することにより達成される。また制御部１２１は、記憶部１２９に記憶された原稿の画像データを表示部１３０に表示する処理を実行する。また制御部１２１は、画像処理装置１００から送信され、ファイル命名装置１２０の記憶部１２９に保存された画像データをファイル命名部１２３に提供する。

ファイル命名部１２３は、その画像データを解析し、ファイルに命名するための情報を生成する。そして制御部１２１は、生成された情報を、ネットワーク１５０を介して画像処理装置１００に送信する。また制御部１２１は、画像処理装置１００から受信したファイルの命名の結果をファイル命名部１２３に供給する。ファイル命名部１２３は、最終的に命名されたファイルの命名の結果を利用して、ファイル命名ルールを更新する。ＯＣＲ部１２４は、その画像データに対して文字認識処理を行い、その画像データに含まれる文字情報を抽出する。マッチング部１２５は、画像データ同士の類似度を算出する。ファイル名推定部１２６は、過去のファイルの命名の結果の履歴からファイル命名ルールを推定し、入力された画像データに適したファイル名を生成する。

以上説明したファイル命名装置１２０の構成はあくまでも一例であり、本発明はこれに限らない。例えば、ファイル命名装置１２０は、サーバ等のコンピュータ装置で実現できるが、記憶部１２９やファイル命名部１２３の機能は、クラウドと呼ばれるネットワーク１５０でつながるリモートの計算資源で実装する構成も考えられる。更に、画像処理装置１００がファイル命名装置１２０の機能を包含する態様で、画像処理装置１００を実装してもよい。

次に、本実施形態１に係るシステムにより実行される処理を説明する。

図２は、実施形態１に係る画像処理装置１００が原稿を読み取り、その画像データにファイル名を付与し、そのファイル名をファイル命名装置１２０に送信する処理を説明するフローチャートである。この処理は、ユーザインターフェース１０４が、ユーザからの原稿の読取指示を受取ることにより開始される。尚、このフローチャートで示す処理は、ＣＰＵ１０５が記憶部１０７からＲＡＭ１０６に展開したプログラムを実行することにより達成される。

まずＳ２０１でＣＰＵ１０５は装置制御部１０２として機能し、画像読取部１０８を制御して原稿を読み取り、その原稿の画像データを取得する。そしてＣＰＵ１０５は、その画像データに対して画像処理部１０３により色変換処理、階調補正等の補正処理を行ってＲＡＭ１０６に格納する。そしてＲＡＭ１０６に格納された画像データを記憶部１０７に保存する。

次にＳ２０２に進みＣＰＵ１０５は装置制御部１０２として機能し、記憶部１０７に保存されている画像データをネットワーク１５０を介してファイル命名装置１２０に送信する。次にＳ２０３に進みＣＰＵ１０５は装置制御部１０２として機能し、ファイルの命名用のＵＩ画面の生成に必要な情報をファイル命名装置１２０から受信する。ここで受信する情報は、画像データのＯＣＲの結果、及び推奨ファイル名に関する情報を含んでいる。ＯＣＲ結果の情報は、ＯＣＲ処理により得られた画像データに含まれる文字列に関する情報を含んでいる。具体的には、その画像データに含まれる全ての文字列ブロックの文字列ブロックＩＤ、文字列ブロック位置、文字列ブロックサイズ、文字列ブロックの文字列を含む。推奨ファイル名情報は、画像データの内容から推奨される、その画像データのファイル名に関する情報である。推奨ファイル名情報は、具体的なファイル名の情報でも良いし、ファイル命名用のＵＩ画面に合わせた情報でもよい。後者は、例えば、文字列ブロックＩＤ「２」と、文字列ブロックＩＤ「５」に含まれる文字列を組み合わせてファイル名とするといった、間接的にファイル名を推奨する情報である。

次にＳ２０４に進みＣＰＵ１０５は装置制御部１０２として機能し、Ｓ２０３でファイル命名装置１２０から得た情報を利用して、ファイルの命名用のＵＩ画面を生成する。そして、その生成したＵＩ画面を表示部１１０に表示する。そしてユーザインターフェース１０４を通じて、ファイルの命名指示を受け付ける。ここでＣＰＵ１０５は、ユーザインターフェース１０４からの指示に基づき、適宜、ファイルの命名用のＵＩ画面を更新する。またＣＰＵ１０５は、ユーザインターフェース１０４から、ファイル名を確定した旨の通知を受けるとＳ２０５に処理を進める。

ここで、ファイルに命名するためのＵＩ画面の例を図４〜図７を参照して説明する。

図４は、図２のＳ２０１で読み取られる原稿の一例を示す図である。ここでは注文書の例で示している。

図５及び図６は、実施形態１に係る画像処理装置１００の表示部１１０に表示されるファイルの命名用のＵＩの一例を示す図である。ここでは図４に示す原稿を読み取った場合で示している。

図５（Ａ）は、推奨されるファイル名が存在しない場合に、最初に、ＵＩ画面として表示される画面例を示している。ここでは、ＯＣＲ処理された文字列のブロックがグレーの背景色で表示されている。この画像で、文字列部分であるにも拘らず背景色がグレーとなっていない領域があるが、これはＯＣＲで認識されなかった文字列ブロックを示している。この背景色がグレーとなっている文字列ブロックをユーザが選択することにより、その文字列をファイルの命名に利用する文字列ブロックとして指定できる。

図５（Ｂ）は、ユーザが「注文書」と書かれている文字列ブロック５０１を選択した例を示す。文字列ブロック５０１が選択されると、このＵＩ画面を更新し、文字列ブロック５０１が選択されたことを示す丸数字「１」を文字列ブロック５０１の左上に表示する。この丸数字「１」は、１番目に選択された文字列ブロックであることを示している。また文字列ブロック５０１に含まれるＯＣＲで認識された文字列「注文書」を、ファイル名付け（ファイル名称）のテキストボックス５０２に表示する。

図６（Ａ）は、更に、ユーザが追加して、「株式会社西取手白山商会 御中」と書かれている文字列ブロック５０３を選択した状態を示す。この文字列ブロック５０３が選択されるとＵＩ画面を更新し、文字列ブロック５０３が選択されたことを示す丸数字「２」を文字列ブロック５０３の左上に表示する。この丸数字「２」は２番目に選択された文字列ブロックであることを示している。また文字列ブロック５０３に含まれるＯＣＲで認識された文字列「株式会社西取手白山商会 御中」を、ファイル名付けのテキストボックス５０２に、既に表示されている文字列「注文書」に「＿」で連結して表示する。このとき一般的なファイル名にスペースが含まれるのは好ましくないため、「株式会社西取手白山商会 御中」を「株式会社西取手白山商会御中」とする。この結果、テキストボックス５０２には、「注文書＿株式会社西取手白山商会御中」という文字列が表示される。

このときユーザは、文字列ブロック５０３を指定して会社名を追加したかっただけであったとしても、「株式会社西取手白山商会」という文字列ブロックと、「御中」という文字列ブロックとが結合して、１つの文字列ブロックとしてＯＣＲで認識されている。このため「御中」という文字列もテキストボックス５０２に表示される。

図６（Ｂ）は、更にユーザが、テキストボックス５０２を選択して、その内容を編集して「御中」を消去した結果を示している。

図６（Ｂ）において、テキストボックス５０２に含まれる文字列は「注文書＿株式会社西取手白山商会」となる。そしてこの状態で、ユーザがファイル名付けボタン５０４を押下すると、この画像データのファイル名が、テキストボックス５０２に含まれる文字列「注文書＿株式会社西取手白山商会」となる。このようにしてユーザは、ファイル名を手動で入力しなくても、原稿を読み取って得られた画像データの文字認識結果を活用して、ファイルに名称を付与することができる。しかしながら、まだ多少の手間をかける必要がある。ここでのユーザ操作に関する情報を含んだファイルの命名に関する情報は、後述するフローに従って画像処理装置１００からファイル命名装置１２０に送信され、推奨されるファイル名を生成するために活用される。

ここで、例えばファイル命名装置１２０で作成された推奨されるファイル名が存在する場合、例えば、図６（Ｂ）の画面が最初から表示される。この場合は、ユーザは、図６（Ｂ）の画面でファイル名付けボタン５０４を押下するだけでファイルに名称を付与することができるため、ファイルの命名操作の手間が大きく軽減される。

ここで、推奨されるファイル名に関する情報は、ファイルの命名に利用する文字列ブロックに関する情報である。具体的には、文字列ブロック５０１が１番目の文字列、文字列ブロック５０３が２番目の文字列として、ファイルの命名に利用されるという情報を含む。更に、文字列ブロック５０３に含まれる文字列は、実際のＯＣＲ結果である「株式会社西取手白山商会御中」から「株式会社西取手白山商会」に修正されている。これは、過去のユーザのファイルの命名結果を利用して推定されたファイル命名ルールに従って、「御中」を削除したものである。一方、ファイル命名装置１２０では、推定したファイル命名ルールが簡易である場合、「御中」がそのまま含まれる可能性があり、推奨されるファイル名の品質は、推定したファイル命名ルールに左右される。このファイル命名ルールの推定については後述する。

別のＵＩ例について、図７を参照して説明する。

図７は、実施形態１に係る画像処理装置１００の表示部１１０に表示されるファイルに命名するためのＵＩ画面の他の例を示す図である。ここでも図４に示す原稿を読み取った場合で示している。

図７では、ファイルの命名に、ＯＣＲの結果だけではなく、他の情報も利用することが可能である。まず図７のＵＩの各機能部品について説明する。７０１〜７０３は文字の表示、編集が可能なフィールドであり、これらフィールドの文字列を組み合わせてファイルの名称を作成できる。このフィールドを選択してアクティブにして、利用するテキスト部分（文字列ブロック５０１，５０３）を選択することにより、そのテキスト部品が保持する文字列を入力でき、また、その入力された文字列を編集することもできる。フィールド７０１〜７０３は、それぞれ消去ボタン７０４〜７０６を用いて、その内容を消去することができる。またファイルの名称を作成する際、各フィールドの文字列の間に区切り文字を指定できる。その区切り文字の指定を行うのが、区切り文字指定７０７，７０８である。図７の例では、「区切り文字なし」「＿」「（」「）」「−」「＃」の中から任意の１つを選ぶことができる。尚、消去ボタン７０４〜７０６でフィールドの内容が消去された場合には、その消去されたフィールドに対応する区切り文字指定７０７，７０８も消去される。フィールド追加ボタン７０９が押されると、ファイルの名称を作成する新たなフィールドを追加できる。例えば、フィル―ド７０１、フィールド７０２、区切り文字指定７０７しか存在しない状況で、フィールド追加ボタン７０９が押下されると、新たにフィールド及びそれに対応する区切り文字指定が追加される。

各フィル―ドへの文字列の入力は、ＯＣＲで認識された文字列ブロック、メタ情報ボタン、任意文字列ボタンにより行われる。ＯＣＲで認識された文字列ブロックは、図５、図６と同様に、ユーザが、認識された文字列ブロックを選択することにより利用できる。例えば、フィールド７０１をアクティブにした後、図５の文字列ブロック５０１を押下すると、文字列ブロック５０１に含まれる文字列「注文書」がフィールド７０１に入力される。同様の操作で、フィールド７０２に、文字列ブロック５０３に含まれる文字列「株式会社西取手白山商会 御中」を入力することができる。

更に図７の例では、メタ情報ボタンとして、日付ボタン７１０とユーザ名ボタン７１１を用意している。例えば、フィールド７０３をアクティブにした後、日付ボタン７１０を押下すると、その日付ボタン７１０を押下した当日の日付がフィールド７０３に入力される。同様に、ユーザがフィールド７０３をアクティブにした後、ユーザ名ボタン７１１を押すと、フィールド７０３にその操作しているユーザの名称が入力される。この場合は、ユーザは予め画像処理装置１００で認証処理を行っているものとする。任意文字列ボタン７１２は、ユーザが任意の文字列を入力することに利用する。例えば、フィールド７０３をアクティブにした後、ユーザが任意文字列ボタン７１２を押下すると、ユーザはフィールド７０３に、任意の文字列を入力できる。この文字列の入力は、ユーザインターフェース１０４を用いて行う。

こうして入力された各フィールドの文字列は、ユーザインターフェース１０４を用いてユーザが編集することができる。図７のＵＩの特徴は、ユーザはファイル名を効率的に入力できるとともに、システム側はファイル命名ルールを推定するための有効な情報を取得できることである。即ち、システムは、ユーザが、どのような情報を組み合わせて、ファイル名を作成しているかを示す情報を取得できるためである。ユーザが全て手動でファイル名を入力した場合は、どのような情報を組み合わせてファイル名を作成したかという情報を得ることができない。またＯＣＲの結果の文字列ブロックと、任意の文字列だけを利用できる場合は、ユーザ名などのメタ情報を任意の文字列として入力する必要があるため、ルール推定の際に「メタ情報」であると認識するのが難しくなる。つまり、図７のように、ファイル名の構成要素をユーザが選択することにより、ファイル命名ルールの推定精度を向上させることが可能となる。図７は、あくまでも一例であり、他のファイル名の構成要素をユーザが選択できるようにしてもよい。本実施形態１では、以上説明したようなＵＩ画面を用いて、ユーザはファイルの命名を行う。

再び図２に戻ってＳ２０５に進みＣＰＵ１０５は装置制御部１０２として機能し、Ｓ２０４で決定されたファイル名をその画像データに付与する。そしてネットワーク１５０を介して、ユーザインターフェース１０４を通じたユーザからの指示に基づく適切な格納先に、その画像データをそのファイル名で格納する。そしてＳ２０６に進みＣＰＵ１０５は、ファイルの命名の結果をファイル命名装置１２０に送信する。ここで送信する情報は、最終的に決定されたファイル名、ファイル名に利用したＯＣＲの文字列ブロックの情報、ＯＣＲの文字列ブロックの文字列を、画像処理装置１００ユーザが修正した情報等を含む。またファイル名に利用した日付などのメタ情報に関する情報、ユーザが入力した任意の文字列の情報等も含まれる。また推奨されたファイル名が存在した場合には、その名前が、そのままファイル名として利用されたかどうかの情報も含まれる。これに関しては詳しく後述する。

次に実施形態１に係るファイル命名装置１２０における処理を説明する。

図３は、実施形態１に係るファイル命名装置１２０による画像データのファイルの命名のための情報を生成する処理を説明するフローチャートである。このフローチャートで示す処理は、画像処理装置１００から画像データを受信することにより開始される。尚、このフローチャートで示す処理は、ＣＰＵ１２７が記憶部１２９からＲＡＭ１２８に展開したプログラムを実行することにより達成される。

まずＳ３０１でＣＰＵ１２７は装置制御部１２２として機能し、ネットワーク１５０を介して画像処理装置１００から画像データを受信する。受信した画像データは記憶部１２９に格納する。次にＳ３０２に進みＣＰＵ１２７はＯＣＲ部１２４として機能し、その画像データを記憶部１２９から読み出してＲＡＭ１２８に展開し、その展開した画像データにＯＣＲ処理を行い、認識された文字列ブロックの情報を出力する。ここでの文字列ブロックの情報は、文字列ブロックの位置、文字列ブロックのサイズ、文字列ブロックに含まれる文字列を含んでいる。次にＳ３０３に進みＣＰＵ１２７はマッチング部１２５として機能し、その画像データの特徴量を抽出する。ここで抽出する特徴量は、公知の画像特徴量でも良いし、ＯＣＲで得られた文字列ブロックの情報でもよい。こうして得られた画像データの特徴量を文字列ブロックの情報とセットにして記憶部１２９に保存する。

次にＳ３０４に進みＣＰＵ１２７はマッチング部１２５として機能し、Ｓ２０４で得られた特徴量と、過去の画像データの特徴量とのマッチング処理を行う。ここでのマッチング処理は、特徴量に合わせたマッチング処理を行えばよい。例えば、ＳＩＦＴ等の局所特徴量を利用している場合は、２つ画像データに含まれる局所特徴量群同士のマッチングを行い、その一致した個数を、その２つの画像データの一致度とすればよい。また文字列ブロックの情報を特徴量とする場合は、２つの画像データに含まれる文字列ブロックの重なり具合を一致度とすればよい。この重なり具合は、例えばJaccard index等が利用可能である。尚、ここでのマッチング方法は、これらに限定されず、適切な公知の手法が利用可能である。

次にＳ３０５進みＣＰＵ１２７はマッチング部１２５として機能し、Ｓ３０４で算出した過去の画像データとのマッチング度を評価し、過去に類似した画像データがあったかどうかを判定する。ここで類似した画像データがあったと判定すると、類似した過去の画像データと同じ画像クラスタＩＤを割り当ててＳ３０６に処理を進める。ここで、画像クラスタＩＤとは、類似した画像データをグループ化して管理するためのＩＤ（識別情報）である。グループ化するのは、類似した画像データは、同一のファイル命名ルールを採用している可能性が高いためである。ここでのファイル命名ルールの管理は、この画像クラスタＩＤの単位で行う。一方、Ｓ３０５で類似した画像データがないと判定した場合は、その画像データに新規の画像クラスタＩＤを割り当ててＳ３１０に遷移する。

Ｓ３０６でＣＰＵ１２７はファイル名推定部１２６として機能し、その画像データに割り当てられた画像クラスタＩＤに紐づいたファイル命名ルールを選択する。次にＳ３０７に進みＣＰＵ１２７はファイル名推定部１２６として機能し、Ｓ３０６で選択したファイル命名ルールに基づいて、その画像データに対する推奨ファイル名を生成する。

図８は、実施形態１に係るファイル命名ルールを説明する図である。

ここで、ファイル命名ルールは、例えば、図８（１）のようなものとなる。図８の（１）は、ファイル名のテンプレートとなっている。このテンプレートは、図７のＵＩで表示されている内容（区切り文字指定７０７，７０８で「＿」を選択したとする）で、ユーザがファイル名を決定した際に生成されるテンプレートとなる。そして、＜＞で囲まれた項目が、画像データごとにルールに従って置き換わる部分となり、図７のＵＩ画面のフィールドに対応している。即ち、図７のフィールド７０１が、テンプレートの＜ＯＣＲ領域１＞８０１に対応している。ここで、置き換え対象となっているＯＣＲ領域１は、ユーザがフィールド７０１と関連付けている文字列ブロック５０１である。また図７のフィールド７０２は、テンプレートの＜ＯＣＲ領域２＞８０２に対応している。ここで、置き換え対象となっているＯＣＲ領域２は、ユーザがフィールド７０２と関連付けている文字列ブロック５０３である。更に、図７のフィールド７０３がテンプレートの＜日付＞８０３に対応している。ここで、置き換え対象が「日付」となっているのは、図７でユーザが、フィールド７０３と「日付」のメタ情報を示す日付ボタン７１０とを関連付けたためである。それ以外の部分である「＿」は、区切り文字指定に対応している。図７の区切り文字指定７０７は、テンプレートの「＿」８０４に対応し、図７の区切り文字指定７０８は、テンプレートの「＿」８０５に対応している。また「．ｐｄｆ」は、図７では図示されていないファイルの拡張子となる。続いて、それぞれの＜＞部分の置き換えルールについて説明する。

＜ＯＣＲ領域１＞は、画像データの特定の文字列ブロック内の文字列で置き換えることを意味する。そのルールの例を図８（２）に示している。

図８（２）の８１０は、ＯＣＲ領域１のサブルールＩＤを示している。サブルールＩＤは、ルールが更新されるたびにインクリメントされ、サブルールの履歴の管理に利用される。８１１は、類似画像データにおける文字列ブロックＩＤである。ここでは、過去の類似画像データのＯＣＲ領域１が、文字列ブロックＩＤ「０００１」であることを意味している。この情報を利用するために、まず処理対象の画像データの文字列ブロックについて、過去の画像データの文字列ブロックＩＤとの対応付けを行い、処理対象の画像データの文字列ブロックに文字列ブロックＩＤを割り当てる。この対応する領域の決定は、文字列ブロックの位置の類似性、ＯＣＲ結果の文字列の類似性等を利用して行う。

処理対象の画像データにおけるＯＣＲ領域１（文字ブロックＩＤ「０００１」）が決定されると、処理対象の画像データのＯＣＲ領域１に含まれるＯＣＲ結果の文字列に対して、ルールで定められた所定の処理を加えてファイル名に含まれる文字列とする。そのルールの例を、図８（２）のＯＣＲ設定８１２で示す。この場合、ＯＣＲ設定８１２で、文字列が固定文字列「注文書」であると定義されている。このため、ＯＣＲ結果の文字列に依存せず、固定的に「注文書」という文字列を出力する。これは、過去の類似した画像データのファイルの命名結果から、この部分は可変的な文字列が入らず、固定文字列「注文書」であるとルールを推定したためである。そのため、ＯＣＲ領域１はＯＣＲの精度に依存しないことになる。

図８（３）は、＜ＯＣＲ領域２＞のサブルールを示している。ＯＣＲ領域１のサブルールとの相違点は、文字列ブロックＩＤ８２０とＯＣＲ設定８２１である。ＯＣＲ領域２は、文字列ブロックＩＤ８２０で示すように文字列ＩＤ「０００３」と対応しているため、処理対象の画像データにおける文字ブロックＩＤ「０００３」の文字列ブロックの文字列が、置き換え対象の文字列となる。そして、更にその処理対象の文字列に対して、ＯＣＲ設定８２１を適用する。ここで適用するＯＣＲ設定８２１は、末尾の文字列「 御中」を除去することである。つまり「株式会社西取手白山商会 御中」を「株式会社西取手白山商会」に変更するように設定している。

図８（４）は、＜日付＞のサブルールを示す。＜日付＞は、詳細ルールで定義される日付でファイル名に使用されることを意味する。例えば、図８（３）では、８３０で定義されているように、画像データがスキャンされたときの日付を「ＹＹＹＹＭＭＤＤ」の形式に変換して、ファイル名で使用するように設定されている。従って、この例では、２０１６年０７月２５日が「２０１６０７２５」に変換される。

図８（５）は、以上説明したルールを、図７で表示されている画像データに適用した際に生成されるファイル名を示している。ここでは、単純にユーザが適用したファイル名が再生成されるだけであるが、他の同一の画像クラスタＩＤを持つ類似画像データが入力された場合であっても、同じルールが適用され、生成されたファイル名が推奨されることとなる。

図９は、実施形態１に係る別のファイル命名ルールの詳細を説明する図である。ここでは別のファイル命名ルールの例を、図９を参照して図８と異なる部分について説明する。

図９（１）は、図８（１）と同様に、ファイル名のテンプレートであり、ＯＣＲ領域、日付、任意の文字列、及びユーザ名の４つからなる。ここでは、図９（１）に対応するＵＩは図示しないが、図７に比べて区切り文字指定を１つ、フィールドを１つ増やし、各フィールドの対応を変更したものとなる。それぞれの領域のサブルールを図９（２）〜（５）で示している。

図９（２）は、＜ＯＣＲ領域１＞の詳細ルールを示す。ＯＣＲ領域１のＯＣＲ結果である文字列は、ＯＣＲ設定９０１において、末尾の「 日付」という文字列を削除した９文字の文字列に修正するように定義されている。ここではＯＣＲにおける文字種の指定はない。そして、過去の類似した画像データのＯＣＲの誤変換履歴から、文字毎の誤変換の訂正ルールが９０２に定められており、ここでは「Ｅ」が「３」に修正される。この訂正ルールについては、ユーザの文字列の修正履歴から生成できる。

実際に、図９（２）のルールを適用した例を図９（６）で示す。ここでは元々のＯＣＲの結果として、ＯＣＲ領域１に含まれる文字列が「注文番号Ｒ２３Ｅ２ 日付」であり、正しい文字列が「注文番号Ｒ２３３２」であったとする。この場合、ＯＣＲ設定９０１を適用して固定文字列「 日付」を削除する。これにより元々のＯＣＲ結果に含まれる文字列９０５が、文字列「注文番号Ｒ２３Ｅ２」９０６に修正される。ここではＯＣＲの文字種の指定がないため、再びＯＣＲ処理を行ったり、ＯＣＲ結果を修正することはしない。次に、個別文字の誤変換の訂正ルール９０２が適用されて、文字列「注文番号Ｒ２３３２」９０７に修正される。

このようにして、単純なＯＣＲ結果に対して、詳細なルールを適用することにより、ＯＣＲの結果に間違いがあった場合であっても、正しい文字列に修正できる。このためには、適切な詳細なルールを推定することが重要となる。ルール推定の詳細については後述する。

＜日付＞は、図９（３）の詳細ルールで定義される日付で、ファイル名に追加されることを意味する。これは、図８（３）と同様である。

＜任意文字列＞は、図９（４）の詳細ルール９０３で定義される文字列でファイル名に追加されることを意味する。この文字列は、ユーザが過去の類似した画像データにおいて定義した文字列である。図９（４）の例では、詳細ルール９０３で定義されるように「担当者」という文字列で置き換える。尚、類似した画像データで、ユーザが定義する文字列が固定化されていない場合には、ここでのルールが不明となる。この場合には、ファイル名の他の部分をユーザに推奨し、この部分については、ＵＩ上で画像データごとにユーザが入力するようにしても良い。

＜ユーザ名＞は、図９（５）の詳細ルール９０４で定義されるユーザ名でファイル名に追加されることを意味する。図９（５）の例では、詳細ルール９０４で定義されるように、ＬＤＡＰ（Lightweight Directory Access Protocol）サーバにログイン名で問い合わせ、実際の人名を取得して利用する。尚、ＬＤＡＰサーバに問い合わせを行わずに、ログイン名そのままを利用して良い。

以上で説明したような変換を行うことにより、例えば、図９（１）のファイル名のテンプレートに基づいて、図９（７）に示すように、画像データのファイル名に変換される。そして、こうして作成されたファイル名が、推奨されるファイル名となる。この推奨されるファイル名は、ルールの曖昧性があって複数の可能性がある場合や、複数のルールがある場合は、複数のファイル名となる場合がある。

再び図３に戻ってＳ３０８に進みＣＰＵ１２７は、ファイル命名部１２３で生成された推奨ファイル名及び、それに関連するＵＩ画面に必要な情報を、ネットワーク１５０を介して画像処理装置１００に送信する。ここで送信する情報は、前述したように、画像データのＯＣＲ結果及び推奨ファイル名に関する情報である。図７の例であれば、ファイル名のテンプレートに関する情報と、実際に置き換えられて生成されたファイル名、過去の画像データのＯＣＲ領域と関連付けられた文字列ブロックに関する情報である。ここでいう関連付けは、文字列ブロックＩＤを過去の類似した画像データと共通にすることを意味する。

次にＳ３０９に進みＣＰＵ１２７は装置制御部１２２として機能し、画像処理装置１００より、ネットワーク１５０を介して、ファイルの命名結果に関する情報を受信して記憶部１２９に保存する。ここで受信する情報は、推奨されたファイル名が実際のファイル名に利用されたかどうかの情報、最終的に決定されたファイル名、ファイル名に利用したＯＣＲの文字列ブロックの情報、ＯＣＲの文字列ブロックの文字列をユーザが修正した情報等を含む。また、ファイル名に利用した日付などのメタ情報に関する情報、ユーザが入力した任意文字列の情報等も含まれる。

次にＳ３０５からＳ３１０に遷移した際の処理を説明する。

まずＳ３１０でＣＰＵ１２７は装置制御部１２２として機能し、ＵＩ表示に必要な情報を、ネットワーク１５０を介して画像処理装置１００に送信する。この処理では、推奨するファイル名が存在しないため、それ以外の情報を送信する。ＯＣＲの文字列ブロックの情報である文字列ブロックＩＤについては、対応付けする過去の類似画像データがないため、新規にＩＤを割り振っておく。尚、ユーザの操作から推定された推奨ファイル名は存在しないが、デフォルトのファイル名のテンプレートに基づく推奨ファイル名を送信するようにしてもかまわない。

次にＳ３１１に進みＣＰＵ１２７は装置制御部１２２として機能し、画像処理装置１００より、ネットワーク１５０を介して、ファイルの命名結果に関する情報を受信して、記憶部１２９に保存する。ここで受信する情報は、推奨されたファイル名を利用したかの情報を除いてＳ３０９と同様である。

こうしてＳ３０９或いはＳ３１１を実行するとＳ３１２に進みＣＰＵ１２７はファイル名推定部１２６として機能し、ファイル命名ルールを更新する。処理対象の画像データと同一の画像クラスタＩＤを持つ画像データが十分にあり、ファイル名推定部１２６が推奨したファイル名が、ユーザにそのまま利用された場合には、十分な精度のファイル命名ルールがあることになる。そのような場合は、Ｓ３１２でファイル命名ルールを更新しなくても良い。

それ以外の場合はＳ３０９或いはＳ３１１で新しく得られたデータを利用して、記憶部１２９から既存のファイル命名ルールを読み込み、そのファイル命名ルールを更新する。このとき既存のファイル命名ルールがない場合は、新規にファイル命名ルールを作成する。このファイル命名ルールの更新は、ファイル名推定部１２６において、同一の画像クラスタＩＤを持つ画像データ群の最終的なファイル名を共通して推定可能なルールを探索することにより行う。こうしてＣＰＵ１２７は、新規作成、或いは更新されたファイル命名ルールを記憶部１２９に保存する。

図８で説明したようなテンプレートの概念を持ち、新規の画像クラスタＩＤである場合は、ファイル名のテンプレートを推定する。これは前述した図７のようなＵＩを用意しておけば、ユーザが設定した内容が、そのままファイル名のテンプレートとなる。そして、それぞれのテンプレートの要素ごとの詳細なルールの推定を行う。その場合は、１つの画像データしかないので、共通したルールの推定が難しいため、ユーザが設定した内容そのまま用いても良い。

尚、ＵＩの制約上、ファイル名のテンプレートを構成するための情報が欠落している場合には、ファイル名のテンプレート自体の推定が必要であり、画像データの枚数がないとより精度の高い推定ができない。そのような場合には、画像データが増加する度に、ファイル名のテンプレートを推定する。これは、ファイル名が、どのような構成要素から構成されているかという推定である。

一方、新規でない場合には、ファイル名のテンプレートの、それぞれのテンプレートの詳細なルールを更新する。

図９（１）のファイル名のテンプレートの＜ＯＣＲ領域１＞の詳細なルールの更新の例を図１０を参照して説明する。

図１０は、実施形態１に係る図９の＜ＯＣＲ領域１＞のルールの更新の一例を説明する図である。

まず、図１０（１）は、ＯＣＲ領域１の現在の詳細ルールを示す。このルールは、図９（２）のルールと同様である。このルールを適用した結果を図１０（２）に示す。

ここで、画像クラスタＩＤ１００１は、類似した画像データを表現するためのＩＤであり、類似した画像データには同一のＩＤが割り振られる。画像ＩＤ１００２は、画像データ固有のＩＤである。画像ＩＤ１００３が示す「５３」は、最終的な詳細ルール１００４を適用した後の文字列「注又番号丁２０２０」と、ユーザ修正結果１００５で示すユーザが最終的に修正した文字列「注又番号丁２０２０」とが異なっている。

ここで、３つの画像データの共通したルールを推定する。まず３つの画像は、１００５〜１００７で示されているように、全て「注文番号」という文字列を持つ。そして、画像ＩＤ「５３」については、ユーザ修正結果１００５で示すように、ユーザが修正処理を行って「注文番号Ｔ２０２０」にしているため、「注文番号」が固定文字列である可能性が高い。そこで「注文番号」が固定文字列であるというルールを追加する。また画像ＩＤ「５３」の例で、ユーザ修正結果１００４と１００５の文字列を比較すると、ユーザが「丁」の文字列を「Ｔ」に修正しているため、その変換ルールも追加する。その結果生成されたルールが、図１０（３）である。

図１０（３）では、図１０（１）のＯＣＲ設定ルールに、１００８で示すように、固定文字列「注文番号」が追加されている。また個別誤変換訂正ルール１００９で示すように、「丁」を「Ｔ」に修正するルールが追加されている。このルールを適用した場合に想定される結果を図１０（４）に示す。これにより画像ＩＤ「５３」においても、ユーザ想定修正結果１０１０で示すように、ユーザによる修正が不要になっている。

このルールは、画像データの増加に伴い、より信頼性のあるルールへ継続して更新していくことが可能である。例えば、画像クラスタＩＤが「３」である画像データがさらに増加し、図１１（１）のようなＯＣＲ領域３についての情報を持つ画像データが追加された場合を考える。

この時点では、図１０（３）のルールが適用されており、ユーザ修正結果１１０１及び１１０２を見ると、画像ＩＤ「６５」「７０」はユーザによる修正がない。一方、ユーザ修正結果１１０３を見ると、画像ＩＤ「８１」にはユーザによる修正が行われている。ユーザ修正結果１１０３と、個別変換訂正ルール適用の文字列１１０４を比較すると、ユーザによる修正は「ｑ」の「９」への変更、及び「Ｉ」から「１」への変更である。そこで、この変換ルールを新しくルールに追加することも考えられる。しかしながら、過去の画像クラスタＩＤが同一の「３」である画像データの全てにおいて、この部分が４桁の数字列であることを考慮して、この部分は４桁の数字列であるというルールを追加する。これが、図１１（２）のＯＣＲ設定ルール１１０６である。その際に、過去に追加したルールである「Ｅ」を「３」に変換するというルールは、追加した数字限定に含まれるため除去する。これが図１１（２）の個別誤変換訂正ルール１１０７である。このような複雑なルールを、ユーザが手動で最初から指定すると、ユーザ負荷は非常に大きくなる。またＵＩも複雑なものとなり、操作性も低下する。しかしながら、ユーザの修正した操作内容の履歴に従って、このようにルールを変更、追加することにより、ユーザの負担を少なくして命令ルールを、より最適なものに更新することができる。

その結果、更新されたルールである図１１（２）を、図１１（１）の画像データに適用した場合に想定される結果を図１１（３）に示す。図１１（３）の画像ＩＤ「８１」のユーザ想定修正結果１１０９において、ユーザによる修正が想定されず、より良いルールとなっていることが分かる。

このような形で、ルールの更新を続けていき、最終的に、図１１（４）に示すようなルールとなることが想定される。図１１（２）の１１０８で示すサブルールＩＤ「３」が、図１１（４）の１１１０で示すサブルールＩＤ「４」に更新され、更に、１１１１で示すサブルールＩＤ「５」に更新されている。サブルールＩＤ５のルールであるＯＣＲ設定１１１２は、ＯＣＲ結果に対する多くの限定により、ＯＣＲ結果が間違っていたとしても、高い確率で、自動的に文字認識結果を修正できるルールとなっている。またＯＣＲ設定１１１２で具体的に行う処理は、先頭文字列の固定文字列「注文番号」への変換、２種類（ＴもしくはＲ）の文字種に限定した１文字の文字認識、数字だけに限定した４文字の文字認識、固定文字列「 日付」の除去である。

これは図９（２）に示す初期のＯＣＲ設定９０１に比べて、はるかに複雑で、文字認識の誤りに対する耐性が向上していることが分かる。このようなルールを推定するために必要な画像データの数は、ＯＣＲ設定９０１を推定したときに比べて多くなる。

どのルールが適用可能かどうかは、予め可能性のある基本ルールを保持しておき、それらを対象の画像クラスタＩＤ用にカスタマイズして適用して、各ルールの有用性を判断すればよい。複数のルールが有用である場合には、同一の画像クラスタＩＤの画像データの数に応じて、どのルールを選択するかを判断する。画像データの数が少ない場合に、汎用性のあるルールを選択すると、間違いが多く生じる可能性がある。そこで、画像データの数が少ない場合には、限定的なルールを選択する。そして、段階的に汎用的なルールを適用することにより対処できる。図９〜図１１の例においても、そのような方針でルールを選択している。

このような形で、複数の同一の画像クラスタＩＤをもつ画像データのルールを利用することにより、より複雑なファイル名を推定できる命名ルールに更新でき、そのルールを使用することにより、より、ユーザが所望するファイル名を提示できるようになる。尚、ここで、説明したルールの更新方法はあくまでも一例であり、例えば、確率モデルを導入し、文字列の生起確率に基づくルールを導入する等の方法を利用しても構わない。

以上説明したように実施形態１によれば、ユーザが通常のファイルの命名操作を繰り返して行うだけで、ファイル命名ルールを自動的に学習し、ユーザにとって、より適切なファイル名の推奨することができる。これにより、ファイル名を決定するルールを設定するユーザの負荷を大きく軽減できる。

［実施形態２］
以下、本発明の実施形態２について、前述の実施形態１と異なる部分について説明する。実施形態１との差分は、図３のフローチャートであるため、図１２フローチャートを参照して説明する。よって、実施形態２に係る画像処理装置１００及びファイル命名装置１２０の構成及びこれらを含むシステムは前述の実施形態１と同じであるため、その説明を省略する。

図１２は、実施形態２に係るファイル命名装置１２０による画像データのファイルの命名のための情報を生成する処理を説明するフローチャートである。このフローチャートで示す処理は、画像処理装置１００から画像データを受信することにより開始される。尚、このフローチャートで示す処理は、ＣＰＵ１２７が記憶部１２９からＲＡＭ１２８に展開したプログラムを実行することにより達成される。尚、図１２において、前述の図３と共通する処理は同じ符号で示し、それらの説明を省略する。但し、実施形態２では、Ｓ３０５において、複数のマッチング度が高い類似した画像データがあった場合には、複数の画像クラスタＩＤを処理対象の画像データに割り当ててもよいとする。複数の画像クラスタＩＤが割り当てられた場合には、Ｓ３０６〜Ｓ３０９の処理は、それぞれの画像クラスタＩＤに対して行われる。

こうしてＳ３０９からＳ１２０１に進むとＣＰＵ１２７は装置制御部１２２として機能し、記憶部１２９に保存されたファイルの命名結果に関する情報を読み出す。そして、推奨されたファイル名が、実際のファイル名に利用されたかどうかを判定する。ここで推奨されたファイル名が実際のファイル名に利用されなかったと判定すると、画像クラスタＩＤが誤って割り振られた可能性があるためＳ１２０３に遷移する。また複数の推奨されたファイル名が存在する場合で、全ての推奨されたファイル名のいずれも実際のファイル名に利用されなかった場合にはＳ１２０３に遷移する。また１つでも、推奨されたファイル名が実際のファイル名に利用された場合はＳ１２０４に遷移する。

またＳ３１１からＳ１２０２に遷移した場合、ＣＰＵ１２７は装置制御部１２２として機能し、記憶部１２９に保存されたファイルの命名結果、及び既存のファイル命名ルールに関する情報を読み出す。そして、既存のファイル命名ルールを処理対象の画像データに適用し、ユーザによって決定されたファイル名が生成することが可能な命名ルールが存在するか探索する。この探索の結果、ユーザによって決定されたファイル名が生成できる命名ルールが存在した場合には、画像クラスタＩＤが誤って割り振られた可能性があるためＳ１２０３に遷移する。ユーザによって決定されたファイル名を生成できる命名ルールが存在しなかった場合はＳ１２０４に遷移する。Ｓ１２０３でＣＰＵ１２７はファイル名推定部１２６として機能し、誤った画像クラスタＩＤが割り振られた可能性を検証し、必要であれば、画像クラスタＩＤの再割り当てを行う。ここでＳ１２０１からＳ１２０３に遷移した場合には、既存のファイル命名ルールが適切でない可能性と、画像データに割り当てられた既存の画像クラスタＩＤが適切ではない可能性がある。両者のどちらかであるかを切り分けるために、図３のＳ３１２と同等の処理を行い、処理対象の画像データのファイル名を適切につけることができるファイル命名ルールに更新できるかどうか検証する。複数の推奨されたファイル名が存在する場合には、全ての画像クラスタＩＤごとに検証を行う。この検証の結果、ファイル命名ルールの更新ができた場合には、既存のファイル命名ルールが適切でないだけであり、画像クラスタＩＤに問題はなかったことになる。ここで、ファイル命名ルールの更新が出来なかった画像クラスタＩＤについては、処理対象の画像データとの紐づけを削除する。こうすることにより、次回以降は、処理対象の画像データに類似した画像は、今回の処理対象の画像とマッチングし、削除されなかった画像ＩＤのみが紐づくため、ユーザが求めるファイル名を推奨する可能性を向上させることが可能となる。

逆に、全てのファイル命名ルールを更新できなかった場合には、既存のファイル命名ルールの問題ではなく、画像クラスタＩＤに問題があったことになる。これは、例えば、類似しているが、異なるルールを持つ画像データが新規に入力されたときに生じる。その場合には、処理対象の画像データに紐づいている既存の画像クラスタＩＤを全て削除し、新規の画像クラスタＩＤを処理対象の画像データに割り当てる。

またＳ１２０２からＳ１２０３に遷移した場合には、Ｓ１２０２で探索されたユーザによって決定されたファイル名が生成することが可能な命名ルールに紐づいた画像クラスタＩＤを、処理対象の画像データに割り当てる。

このＳ１２０３の画像クラスＩＤの再割り当てにより、誤った画像クラスタＩＤが処理対象の画像データに割り当てられた場合でも、それを修正することができる。このように画像クラスタＩＤの修正が可能であるため、Ｓ３０５における類似の画像データがあったかどうかの閾値が適切でなかった場合でも、正常な動作を保つことが可能となる。また、類似した画像データが多い状況であっても、正常な動作を保つことが可能となる。

そしてＳ１２０３からＳ１２０４に進みＣＰＵ１２７はファイル名推定部１２６として機能し、ファイル命名ルールを更新する。ここでの処理は基本的に図３のＳ３１２と同様であるため、差異がある部分についてのみ説明を行う。

Ｓ１２０１からＳ１２０４に遷移した場合には、複数の推奨ファイル名があった場合でも、実際のファイル名に利用された推奨ファイル名に紐づいた画像データのみが処理対象となる。ここで、処理対象とならなかった画像ＩＤについては、処理対象の画像データとの紐づけを削除する。こうすることにより、Ｓ１２０３における処理と同様に、ユーザが求めるファイル名を推奨する可能性を向上させることが可能となる。一方、Ｓ１２０３からＳ１２０４に遷移した場合には、新しく割り当てられた画像ＩＤ及び、Ｓ１２０３において、ファイル命名ルールを更新することができ画像ＩＤが処理対象となる。またＳ１２０２からＳ１２０４に遷移した場合には、処理対象の画像ＩＤは１つしか存在しないため、そのＩＤの画像データが処理対象となる。このように、特定の画像クラスタＩＤだけを処理対象とすることにより、複数の画像データとのマッチングを許容しても、適切なファイル名の推定ルールを更新することができる。次にＳ１２０５に進みＣＰＵ１２７は装置制御部１２２として機能し、過去の画像データのうち、所定の年月を経過した原稿の画像データに対して、ファイル命名ルールを推定する際の対象からの除去や重み付けの低下を行う。または、マッチング対象から除去する。こうすることにより、ファイル命名ルールが切り替わり、既に利用されていないファイル命名ルールが推奨されることを防ぐことが可能となる。

以上説明したように実施形態２によれば、処理対象の画像データと過去の画像データとのマッチングが誤った際にも、適切にファイル名の命名ルールを更新することができる。それにより、それ以降に誤ってマッチングされる可能性を低下させることが可能となる。また、複数のファイル名を推奨する際にも、適切にファイル名の命名ルールを更新することが可能になる。更に、ファイル命名ルールが切り替わった場合にも、適切なファイル名を推奨することが可能となる。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

本発明は上記実施形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。

１００…画像処理装置、１０５…ＣＰＵ、１１０…表示部、１２０…ファイル命名装置、１２４…ＯＣＲ部、１２５…マッチング部、１２６…ファイル名推定部、１２７…ＣＰＵ、１３０…表示部

Claims (13)

1. 原稿の画像データを取得する取得手段と、
   前記画像データのファイル名を作成する命名ルールに従って、前記取得手段により取得した画像データのファイル名を作成する作成手段と、
   ユーザの指示に応じて前記命名ルールを変更する変更手段と、
   前記変更手段により変更された前記命名ルールを、対応する画像データの識別情報とともに記憶する記憶手段と、
   前記取得手段により取得した前記画像データに類似する画像データの命名ルールが前記記憶手段に記憶されているかどうか判定し、記憶されているときは当該類似する画像データの命名に使用した命名ルールを使用して、前記取得手段により取得した前記画像データのファイル名をユーザに提示する提示手段と、
   を有することを特徴とする画像処理装置。
2. 前記取得手段により取得した前記画像データに含まれる文字を認識する文字認識手段を更に有し、
   前記作成手段は、前記文字認識手段により認識された文字を含むファイル名を作成することを特徴とする請求項１に記載の画像処理装置。
3. 前記命名ルールは、前記文字認識手段が文字認識を行う前記画像データの位置、文字の種類の情報を含むことを特徴とする請求項２に記載の画像処理装置。
4. 前記変更手段は、ファイル名のテンプレートの項目に対して、前記文字認識手段により認識された文字、固定文字列、ユーザの名称、日付、任意の文字列の少なくともいずれかを割り当てた命名ルールを生成するための画面を表示し、当該画面を介したユーザの操作を受け付けることにより前記命名ルールを変更することを特徴とする請求項２又は３に記載の画像処理装置。
5. 前記変更手段による前記命名ルールの変更は、固定文字列の除去を含むことを特徴とする請求項２又は３に記載の画像処理装置。
6. 前記画面は更に、前記テンプレートの項目の追加、前記項目の区切り文字を指定及び変更するユーザの操作を受け付けることを特徴とする請求項４に記載の画像処理装置。
7. 前記ファイル名は、前記取得手段により前記画像データを取得した日付、ユーザの名称の少なくともいずれかを含むことを特徴とする請求項１乃至６のいずれか１項に記載の画像処理装置。
8. 前記変更手段は、前記提示手段により提示したファイル名と、ユーザが最終的に決定したファイル名との差分に応じて前記命名ルールを変更することを特徴とする請求項１に記載の画像処理装置。
9. 前記取得手段により取得した前記画像データに類似する画像データは、前記文字認識手段により認識された前記画像データと前記類似する画像データに含まれる文字列の重なり具合に基づいて決定されることを特徴とする請求項２に記載の画像処理装置。
10. 前記提示手段は、前記類似する画像データをグループ化し、同じグループに対して同一の命名ルールを採用することを特徴とする請求項１乃至９のいずれか１項に記載の画像処理装置。
11. 前記取得手段は、前記原稿を光学的に読み取って前記原稿の画像データを取得することを特徴とする請求項１乃至１０のいずれか１項に記載の画像処理装置。
12. 画像処理装置を制御する制御方法であって、
    原稿の画像データを取得する取得工程と、
    前記画像データのファイル名を作成する命名ルールに従って、前記取得工程で取得された画像データのファイル名を作成する作成工程と、
    ユーザの指示に応じて前記命名ルールを変更する変更工程と、
    前記変更工程で変更された前記命名ルールを、対応する画像データの識別情報とともにメモリに記憶する記憶工程と、
    前記取得工程で取得した前記画像データに類似する画像データの命名ルールが前記メモリに記憶されているかどうか判定し、記憶されているときは当該類似する画像データの命名に使用した命名ルールを使用して、前記取得工程で取得した前記画像データのファイル名をユーザに提示する提示工程と、
    を有することを特徴とする画像処理装置の制御方法。
13. コンピュータを、請求項１乃至１１のいずれか１項に記載の画像処理装置の各手段として機能させるためのプログラム。