JP2021114224A - ファイル検索システム、ファイル検索方法及びプログラム - Google Patents

Abstract

【課題】請求書の内容を確認するために、請求書と同一取引で使用された対応文書を検索するシステムが提案されている。しかし、従来のシステムにおいては、対応文書が複数存在する場合、対応文書を過不足なく抽出することができず、また、検索条件を入力するためのユーザの負担も大きかった。【解決手段】本発明によれば、検索処理で抽出された文書数に応じて、再度検索クエリを生成して、検索処理を実行していく。これにより、検索元文書と同一取引で使用された一連の対応文書を過不足なくユーザに提示することができる。また、スキャン画像から検索条件を自動的に生成することにより、検索条件を指示するユーザの負担を軽減することができる。【選択図】図９

Description

本発明は、ファイル検索システム、ファイル検索方法及びプログラムに関するものである。特に、スキャンされた証憑文書と同一取引で使用された対応文書をデータベースから検索する、ファイル検索システムに関するものである。

従来から、請求書などの証憑文書については、記載された金額などについて誤りが発生していないかを確認する業務が存在する。多くの場合、例えば請求書が発行されるまでは、同一取引に関連して、見積書、注文書、納品書などの証憑文書が順次発行される。
そこで、請求書と同一取引で使用された見積書、注文書、納品書などの証憑文書を収集して、金額などについて、これらの証憑文書に記載されている内容と合致しているかを確認することにより、請求書に誤りがないことを確認することが行われている。

このような業務を支援するために、証憑文書についてメタデータを付与してストレージに格納し、同一取引で使用された一連の対応文書を自動検索するファイル検索システムが提案されている。このような支援システムを利用することにより、請求書の確認作業などを行うユーザは、確認作業を行うために必要な一連の対応文書を収集することが容易となる。
また、このようなファイル検索システムにおいては、ＯＣＲ（Optical Character Recognition）処理などの画像処理を行うことにより、アナログ文書であってもスキャンして得られた画像データからメタデータを自動付与することができるものがある。また、文書に記載された内容から、検索条件を自動的に設定したりすることができるものもある。

例えば、特許文献１には、会計処理において発生した、契約書や領収書などの証憑文書の中から関連する文書を検索する手法が開示されている。特許文献１の手法では、特定の文書イメージを選択した際、着目して検索する要素をそのイメージから指定して、関連する証憑文書の検索を行う。その際、キーワードを用いて日付や金額の範囲を検索条件として設定可能とすることで、会計処理特有の検索が可能となる。また、該当する証憑文書がヒットしない場合は、検索条件を切り替えることにより、再検索を行うことができる。

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

ところで、請求書などの証憑文書については、同一取引で使用された証憑文書は、１枚である場合に限られず、複数枚存在する場合もある。例えば、２つの商品について行われた取引において、請求書はまとめて１枚が発行されているが、見積書、注文書、納品書などについては、それぞれ２枚ずつ、２つの商品ごとに発行されている場合がある。
この場合、１枚の請求書と同一取引で使用された対応文書として、証憑文書の種別（見積書、注文書、納品書など）ごとに、複数枚抽出することが必要となる。

このような場合にキーワードを用いて検索を行うと、検索条件によっては、制約が厳しくなりすぎるために、複数の対応文書のうち、一部は抽出されるが、他の対応文書は抽出されないおそれがある。
例えば特許文献１の手法によれば、検索条件を切り替えることはできるが、検索条件に該当する証憑文書が１件でもヒットすれば、検索処理は終了する。そのため、上記のように同一取引で使用された証憑文書が複数枚存在する場合、所望の文書の一部が抽出されないという問題がある。
また、特許文献１の手法のように、ユーザが文書画像中のどの要素に着目して検索するかをユーザが指定する方法では、ユーザが検索条件を入力する必要があるため、ユーザの負担が大きいという課題がある。

本発明は、上記のような事情に鑑みてなされたものであり、ユーザの負担を軽減するとともに、関連するすべてのファイルを過不足なくユーザに提供するシステムを提供することを目的とする。

本発明は、入力された画像から第１の検索クエリを生成する生成手段と、前記第１の検索クエリを用いて、前記入力された画像に関連するファイルの検索を行う検索手段と、前記検索手段が抽出したファイルに関する情報を提供する提供手段と、を有するファイル検索システムであって、前記第１の検索クエリを用いた検索の結果に基づいて、前記第１の検索クエリを更新するか否かを判断する判断手段を有し、前記判断手段が前記第１の検索クエリを更新すると判断した場合、前記生成手段は、第２の検索クエリを生成し、前記検索手段は、前記第２の検索クエリを用いて、再度、ファイルの検索を行い、前記提供手段は、前記検索手段が前記第２の検索クエリを用いて抽出したファイルに関する情報を提供することを特徴とする。

本発明によれば、関連するファイルを過不足なく提供することができる。これにより、確認作業を行うユーザの負担を軽減することができる。

ファイル検索システムの全体構成を示す図である。 画像形成装置のハードウェア構成を示すブロック図である。 情報処理端末のハードウェア構成を示すブロック図である。 クラウドサービスサーバとクラウドサービスサーバのハードウェア構成を示すブロック図である。 各装置において実行される処理のシーケンスを示す図である。 スキャン対象の文書の例である。 スキャン対象の文書と同一取引で使用された文書の例である。 ファイル検索システムにおいて実行される処理の全体を示すフローチャートである。 ＯＣＲ関連処理の詳細を示すフローチャートである。 実施例１における検索処理の詳細を示すフローチャートである。 検索クエリパターンの例である。 実施例２における検索処理の詳細を示すフローチャートである。 登録文書群データベースの例である（その１）。 登録文書群データベースの例である（その２）。 実施例３における検索処理の詳細を示すフローチャートである。 ブロックセレクション処理の例を示す図である。

以下に、図面を参照して、本発明を実施するための各実施例について説明する。ただし、以下に説明する実施例はあくまで例示であり、本発明の範囲をそれらに限定する趣旨のものではない。また、以下の各実施例で説明されている特徴の組み合わせのすべてが本発明の解決手段に必須のものとは限らない。

以下、本発明を実施例について図面を用いて説明する。
＜実施例１＞
＜システムの全体構成＞
図１は、本実施例において用いられるファイル検索システム１０の全体構成を示す図である。
図１に示すように、ファイル検索システム１０は、画像形成装置１００、ＰＣなどの情報処理端末１０１、クラウドサービスサーバ１０２、クラウドストレージサーバ１０３などの装置を備える。

画像形成装置１００は、イーサネット（登録商標）や無線ＬＡＮなどからなるＬＡＮ１０４に接続され、さらに、インターネット１０５に接続されている。また、クラウドサービスサーバ１０２及びクラウドストレージサーバ１０３も、イーサネット（登録商標）や無線ＬＡＮなどからなるＬＡＮ１０４に接続され、さらに、インターネット１０５に接続されている。すなわち、画像形成装置１００、情報処理端末１０１、クラウドサービスサーバ１０２、クラウドストレージサーバ１０３は、ぞれぞれ、ＬＡＮ１０４からインターネット１０５に接続され、相互に通信可能となっている。

画像形成装置１００は、操作部、スキャナ部、プリンタ部を有する複合機（Multifunction Peripheral：ＭＦＰ）である。本実施例のファイル検索システム１０では、画像形成装置１００は紙文書をスキャンするための端末として利用される。
ＰＣ（Personal Computer）などの情報処理端末１０１は、操作部、表示部を有するパーソナルコンピュータである。本実施例のファイル検索システム１０では、情報処理端末１０１は、文書ファイルの検索の結果や、ユーザからの操作指示を受ける表示・操作端末として利用される。

クラウドサービスサーバ１０２は、演算部を有する処理サーバである。本実施例のファイル検索システム１０では、クラウドサービスサーバ１０２は文書ファイルの検索処理を実行する処理端末として利用される。ただし、文書ファイルの検索処理を実行する情報処理端末は、演算実行機能を有すればよく、クラウド上のサーバでなくてもよい。
クラウドストレージサーバ１０３は、記憶部を有するストレージサーバである。本実施例のファイル検索システム１０では、クラウドストレージサーバ１０３は、文書ファイルを保持するストレージ端末として利用される。ただし、文書ファイルを保持する情報処理端末は、記憶機能を有すればよく、クラウド上のサーバでなくてもよい。

なお、本発明を実施するにあたって、ＰＣなどの情報処理端末１０１、クラウドサービスサーバ１０２、クラウドストレージサーバ１０３などの装置は、必ずしも必要ではない。例えば、クラウドストレージサーバ１０３の機能を、クラウドサービスサーバ１０２が備えるようにしてもよい。また、クラウドサービスサーバ１０２とクラウドストレージサーバ１０３機能を、ＰＣなどの情報処理端末１０１が備えるようにしてもよい。
また、入力画像としては、画像形成装置１００でスキャンされた画像を用いことに限られず、ＰＣなどの情報処理端末１０１が事前に保持している画像を用いてもよい。また、クラウドストレージサーバ１０３は、汎用的なストレージのクラウドサービスであってもよいし、ファイルストレージオンプレミスサーバであってもよい。

＜画像形成装置のハードウェア構成＞
図２は、画像形成装置１００のハードウェア構成例を示すブロック図である。
画像形成装置１００は、制御部２００、表示・操作部２０６、プリンタ部２０８、スキャナ部２１０を備える。
制御部２００は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４、表示・操作Ｉ／Ｆ部２０５、プリンタＩ／Ｆ部２０７、スキャナＩ／Ｆ部２０９、ネットワークＩ／Ｆ部２１１の各ハードウェアを備える。制御部２００内の各ハードウェアは、システムバス２１２を介して、互いに通信可能に接続されている。制御部２００は、画像形成装置１００全体の動作を制御する。

ＣＰＵ２０１は、記憶装置（ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４）に記憶された制御プログラムを読み出し実行することにより、画像形成装置１００の各処理（読取制御や画像処理など）を実行する手段として機能する。

記憶装置は、制御プログラム、画像データなどを格納し保持する。
記憶装置は、不揮発性メモリであるＲＯＭ２０２、揮発性メモリであるＲＡＭ２０３、大容量記憶領域であるＨＤＤ２０４などを備える。
ＲＯＭ２０２は、制御プログラムなどを保持する不揮発性メモリである。制御プログラムは、ＣＰＵ２０１により読み出され実行される。
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等の一時記憶領域として用いられる揮発性メモリである。
ＨＤＤ２０４は、ＣＰＵ２０１が処理を行う画像データなどを保存する大容量記憶領域として用いられる不揮発性メモリである。

表示・操作部Ｉ／Ｆ部２０５は、表示・操作部２０６と制御部２００とを、システムバス２１２を介して接続する。表示・操作部２０６は、タッチパネル機能を有する液晶表示部やハードボタンなどを備える。
プリンタＩ／Ｆ部２０７は、プリンタ部２０８と制御部２００とを、システムバス２１２を介して接続する。プリンタ部２０８は、ＣＰＵ２０１で生成された画像データをプリンタＩ／Ｆ部２０７を介して受信し、受信した画像データを用いて記録紙へのプリント処理を行う。
スキャナＩ／Ｆ部２０９は、スキャナ部２１０と制御部２００とを、システムバス２１２を介して接続する。スキャナ部２１０は、証憑文書などの文書を読み取って画像データを生成し、スキャナＩ／Ｆ部２０９を介して画像データを制御部２００に入力する。

ネットワークＩ／Ｆ部２１１は、制御部２００（画像形成装置１００）を、ＬＡＮ１０４に接続し、ＬＡＮ１０４上の外部装置に画像データを送信したり、ＬＡＮ１０４上の外部装置から各種情報を受信したりする。
以上のように、本実施例の画像形成装置１００は、上記のハードウェア構成によって、各種の画像処理機能を提供することが可能である。

＜情報処理端末のハードウェア構成＞
図３は、ＰＣなどの情報処理端末１０１のハードウェア構成例を示すブロック図である。
情報処理端末１０１は、制御部３００、操作部３０７、表示部３０９を備える。
制御部３００は、ＰＣなどの情報処理端末１０１全体の動作を制御する。
制御部３００は、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、ＨＤＤ３０４、ネットワークＩ／Ｆ３０５、操作部Ｉ／Ｆ３０６、表示部Ｉ／Ｆ３０８を備える。

ＣＰＵ３０１は、ＲＯＭ３０２に記憶された制御プログラムを読み出して各種制御処理を実行する。
ＲＡＭ３０３は、ＣＰＵ３０１の主メモリ、ワークエリア等の一時記憶領域として用いられる。
ＨＤＤ３０４は、画像データや各種プログラムを記憶する。
ネットワークＩ／Ｆ３０５は、制御部３００（ＰＣなどの端末１０１）をＬＡＮ１０４に接続する。そして、ネットワークＩ／Ｆ３０５は、ＬＡＮ１０４上の他の装置と制御部３００との間で各種情報を送受信する。

操作部Ｉ／Ｆ部３０６は、操作部３０７と制御部３００とを、システムバス３１０を介して接続する。操作部３０７は、入力および操作の機能を有するマウスやキーボードなどを備える。
表示部Ｉ／Ｆ部３０８は、表示部３０９と制御部３００とを、システムバス３１０を介して接続する。表示部３０９は、表示機能を有するディスプレイなどを備える。

＜クラウドサービスサーバ及びクラウドストレージサーバのハードウェア構成＞
図４は、クラウドサービスサーバ１０２及びクラウドストレージサーバ１０３のハードウェア構成例を示すブロック図である。クラウドサービスサーバ１０２とクラウドストレージサーバ１０３は、ＨＤＤ４０４の記憶可能容量等が異なる以外は、基本的に同じ構成であるため、クラウドサービスサーバ１０２について説明する。

クラウドサービスサーバ１０２は、制御部４００を有する。
制御部４００は、クラウドサービスサーバ１０２全体の動作を制御する。制御部４００は、ＣＰＵ４０１、ＲＯＭ４０２、ＲＡＭ４０３、ＨＤＤ４０４、ネットワークＩ／Ｆ部４０５を備える。

ＣＰＵ４０１は、ＲＯＭ４０２に記憶された制御プログラムを読み出して各種制御処理を実行する。
ＲＡＭ４０３は、ＣＰＵ４０１の主メモリ、ワークエリア等の一時記憶領域として用いられる。
ＨＤＤ４０４は、文書ファイル、画像データや各種プログラムを記憶する。
ネットワークＩ／Ｆ４０５は、制御部４００（クラウドサービスサーバ１０２）をＬＡＮ１０４に接続する。そして、ネットワークＩ／Ｆ４０５は、ＬＡＮ１０４上の他の装置と制御部４００との間で各種情報を送受信する。
なお、同一取引で使用された文書ファイルを検索する検索エンジンについては、クラウドストレージサーバ１０３内のＣＰＵ４１１によって実行される。

なお、前述のとおり、クラウドストレージサーバ１０３も、クラウドサービスサーバ１０２の同様のハードウェア構成を備える。すなわち、クラウドストレージサーバ１０３は、制御部４１０（ＣＰＵ４１１、ＲＯＭ４１２、ＲＡＭ４１３、ＨＤＤ４１４、ネットワークＩ／Ｆ部４１５）を備える。これらのハードウェアの機能は、クラウドサービスサーバ１０２のハードウェアと同様である。

＜ファイル検索システムにおける処理全体のシーケンス＞
次に、本実施例のファイル検索システム１０において実行される処理例の概略について説明する。
まず、画像形成装置１００が、請求書などの証憑文書をスキャンして、画像データ（スキャン画像）を生成する（画像データ取得処理）。
次に、クラウドサービスサーバ１０２が、画像形成装置１００から送信されたスキャン画像を受信し、ＯＣＲ処理を実行することによりスキャン画像から文字列を抽出し、ＯＣＲ結果に基づいて検索クエリを生成する（検索の前処理）。

次に、クラウドストレージサーバ１０３が、保存されている証憑文書の中から、検索クエリを用いて検索を実行し、検索結果として、検索元の証憑文書と同一取引で使用された１又は複数の一連の対応文書を抽出する。ここでは、検索結果として抽出された文書数に応じて、検索クエリを切り替えて検索を実行する（動的検索処理）。
次に、クラウドサービスサーバ１０２が、検索元の証憑文書と、抽出された各対応文書との関連度を算出し、算出した関連度に基づいて検索結果を更新する、検索の後処理を実行する。

以上のシーケンスにより、スキャン対象の証憑文書と同一取引で使用された一連の対応文書を過不足なく抽出することが可能となる。これにより、本実施例のファイル検索システム１０によれば、ユーザによる証憑文書の確認作業の支援を行うことができる。

次に、図５を用いて、本実施例のファイル検索システム１０において実行される各処理について説明する。図５は、ファイル検索システム１０を構成する各装置において実行される文書ファイルの検索処理全体のシーケンスを示す図である。
まず、画像形成装置１００が実行する画像データの取得処理について説明する。
ここで、図６Ａ（１）に、検索元であるスキャン対象の文書（検索元文書）の例を示す。ここでは、検索元文書は、証憑文書の一種である「請求書」であるものとして説明する。

まず、ステップＳ５００において、ユーザは、画像形成装置１００の操作部２０６を操作して、請求書をスキャンさせる。
ステップＳ５０１において、画像形成装置１００のＣＰＵ２０１は、スキャナ部２１０を駆動し、検索元文書の画像データ（スキャン画像）を生成し、ＲＡＭ２０３に保存する。
ステップＳ５０２において、ＣＰＵ２０１は、Ｓ５０１で生成したスキャン画像に対し、フィルタリング処理や色補正処理などの画像処理を実行する。
次に、ステップＳ５０３において、ＣＰＵ２０１は、画像処理を実行したスキャン画像をクラウドサービスサーバ１０２に送信する。

次に、クラウドサービスサーバ１０２が実行する検索の前処理について説明する。
まず、ステップＳ５０４において、クラウドサービスサーバ１０２のＣＰＵ４０１は、画像形成装置１００から送信されたスキャン画像を受信し、ＨＤＤ４０４へ保存する。
ステップＳ５０５において、ＣＰＵ４０１は、受信したスキャン画像に対してＯＣＲ処理を実行して、文字列を取得する。

ステップＳ５０６において、ＣＰＵ４０１は、Ｓ５０５で取得した文字列から、検索を行うための１又は複数のキーワード（検索クエリ）を生成する。検索クエリは、例えば、検索元文書と同一取引で使用された証憑文書（対応文書）を検索するための一つ以上のキーワードから構成される検索条件であるが、詳細については図１０などにおいて説明する。
ステップＳ５０７において、ＣＰＵ４０１は、Ｓ５０６で生成した検索クエリを用いて、クラウドストレージサーバ１０３の検索ＡＰＩ（Application Programming Interface）等を使用し、クラウドストレージサーバ１０３に対して検索の指示をする。

次に、クラウドストレージサーバ１０３が実行する検索処理について説明する。
まず、ステップＳ５０８において、クラウドストレージサーバ１０３のＣＰＵ４１１は、クラウドサービスサーバ１０２から検索クエリを受信し、クラウドストレージサーバ１０３内の検索エンジンで解釈するための変換処理を行う。

ステップＳ５０９において、ＣＰＵ４１１は、検索エンジンで解釈された検索クエリに基づいて、クラウドストレージサーバ１０３内のＨＤＤ４１４から、検索元であるスキャン対象の文書と同一取引で使用された対応文書を検索する。そして、抽出された文書をランキング付けした情報を含む検索結果を生成する。その際、図６Ａ（１）のように、Ｓ５００においてスキャンされた文書が「請求書」である場合、同一取引で使用された証憑文書として、「納品書」、「発注書」、「見積書」、などの種別類の文書がそれぞれ０枚から複数枚抽出される。ここで、図６Ｂ（１）、（２）、（３）に、それぞれ、図６Ａ（１）の「請求書」と同一取引で使用された「納品書」、「発注書」、「見積書」の例を示す。

ステップＳ５１０において、ＣＰＵ４１１は、Ｓ５０９で生成した検索結果をクラウドサービスサーバ１０２に通知する。通知する形式としては、検索処理により抽出された証憑文書のデータ自体でもよいし、格納されている証憑文書のファイルパスでもよいし、文書ファイル名や作成者などの証憑文書の特徴が記載されたインデックス情報（プロパティ情報）だけであってもよい。

次に、クラウドサービスサーバ１０２が実行する検索の後処理について説明する。
まず、ステップＳ５１１において、クラウドサービスサーバ１０２のＣＰＵ４０１は、クラウドストレージサーバ１０３から検索結果を受信し、クラウドサービスサーバ１０２内のＨＤＤ４０４へ保存する。

ステップＳ５１２において、ＣＰＵ４０１は、Ｓ５０９で抽出された抽出文書に対してＯＣＲ処理を行い、文書内の文字列を取得する。検索結果として画像データを受信した場合は、画像データに対しＯＣＲ処理を行う。ＰＤＦファイル等のファイルを受信した場合は、ファイル内の画像データを抜き出してＯＣＲ処理を行う。また、文書内の文字列がテキストデータとして格納されている場合は、テキストデータを抽出するだけであってもよい。

ステップＳ５１３において、ＣＰＵ４０１は、Ｓ５１２で取得した抽出文書内の文字列と、Ｓ５０５でスキャン画像から取得した検索元文書内の文字列と、の比較を行い、文書間の関連度スコアを算出する。関連度スコアを算出する手法については、公知の手法を採用することができる。例えば、各文書内の各文字列同士の距離を、レーベンシュタインによる算出手法で算出し、累積距離が少ない文書ほど関連度スコアが高いとすることができる。なお、関連度スコアは、検索処理により抽出された証憑文書の種別（納品書、発注書、見積書など）ごとに算出される。

ステップＳ５１４において、ＣＰＵ４０１は、Ｓ５１３で算出された関連度スコアに基づいて、Ｓ５１１で受信した検索結果のランキングを更新する。
ステップＳ５１５において、ＣＰＵ４０１は、更新した検索結果をＰＣ等の情報処理端末１０１でユーザが表示確認できるように、表示用の画面を生成する。例えば、クラウドサービスサーバ１０２内のＷＥＢサーバ上にＨＴＭＬ形式のデータを用意し、ＰＣ等の情報処理端末１０１のブラウザアプリケーション等で閲覧が可能な形式の画面を生成する。

次に、ステップＳ５１６において、ＣＰＵ４０１は、更新した検索結果をＰＣ等の情報処理端末１０１に対して通知し、情報処理端末１０１の表示部３０９に表示するように指示する。
ステップＳ５１７において、ＰＣ等の情報処理端末１０１のＣＰＵ３０１は、クラウドサービスサーバ１０２からの指示に基づいて、ディスプレイ等の表示部３０９に検索結果を表示する。その際、ＣＰＵ３０１は、検索処理により抽出された証憑文書の種別（納品書、発注書、見積書など）ごとに分けてランキング付けをして、表示を行う。

図７は、本実施例のファイル検索システム１０において実行される処理の全体を説明するフローチャートである。なお、本フローチャートに示す処理は、クラウドサービスサーバ１０２のＣＰＵ４０１が、ＲＯＭ４０２に格納されている処理プログラムをＲＡＭ４０３にロードすることにより実行される。
ステップＳ７０１において、クラウドサービスサーバ１０２のＣＰＵ４０１は、ＬＡＮ１０４を通じて画像形成装置１００においてスキャンされた検索元である証憑文書の画像データ（スキャン画像）を取得する。
ステップＳ７０２において、ＣＰＵ４０１は、ステップＳ７０１で取得したスキャン画像に対して、ＯＣＲ関連処理を実行し、ＯＣＲ結果を取得する。なお、ＯＣＲ関連処理の詳細については後述する。

ステップＳ７０３において、ＣＰＵ４０１は、ステップＳ７０２で取得したＯＣＲ結果から項目名と項目値を抽出して、メタデータを取得する。なお、項目名と項目値の抽出処理の詳細については後述する。また、メタデータとは、項目名と、その項目名に対応した項目値が対になったデータのこという。
ステップＳ７０４において、ＣＰＵ４０１は、ステップＳ７０３で取得したメタデータを用いて、クラウドストレージサーバ１０３に対して検索処理の実行を指示する。そして、クラウドストレージサーバ１０３から通知される検索結果をＨＤＤ４０４へ保存する。なお、検索処理の詳細については後述する。

ステップＳ７０５において、ＣＰＵ４０１は、ステップＳ７０４で保存した検索結果に含まれる、検索処理により抽出されたすべての抽出文書に関する情報を取得する。検索結果がファイルのデータ自体から構成される場合は、その文書の画像データを取得する。また、検索結果がクラウドストレージサーバ１０３に格納されている文書ファイルのファイルパスである場合は、ファイルパスを用いてクラウドストレージサーバ１０３に対して画像データの送信指示を行う。そして、クラウドストレージサーバ１０３から送信された画像データを受信することで、画像データを取得する。文書に関する情報を取得する手法にはその他にも様々なものがあるが、検索処理により抽出された文書を取得できるものであれば手法は問わない。

ステップＳ７０６において、ＣＰＵ４０１は、ステップＳ７０５で取得した抽出文書に対してＯＣＲ関連処理を実行し、ＯＣＲ結果を取得する。Ｓ７０６におけるＯＣＲ関連処理は、Ｓ７０２におけるＯＣＲ関連処理と同様である。なお、取得した文書の画像データに対してＯＣＲ関連処理が実行済みである場合は、ステップＳ７０６を省略してもよい。例えば、Ｓ７０２のＯＣＲ関連処理がされた状態で画像データがストレージサーバ１０３に保存されている場合は、ステップＳ７０６を省略してもよい。

ステップＳ７０７において、ＣＰＵ４０１は、ステップＳ７０２で取得した検索元文書のＯＣＲ結果と、ステップＳ７０６で取得した抽出文書のＯＣＲ結果と、の関連度スコアを算出する。関連度スコアとは、スキャン対象である検索元の証憑文書と、検索処理により抽出された抽出文書と、が同一取引で使用された文書同士であることを示す度合いである。
関連度スコアは、ステップＳ７０３で取得した検索元文書内のメタデータの文字列と、ステップＳ７０６で取得した抽出文書のＯＣＲ結果による文字列と、の一致度などから算出する。具体的には、検索元文書の画像データと検索処理により抽出された抽出文書の画像データとに含まれる、会社名の文字列の一致度や、商品名の文字列の一致度などから算出する。例として、各文書内の各文字列同士の距離を、レーベンシュタインによる算出手法で算出し、累積距離が少ない文書ほど関連度スコアが高いものとすることができる。例えば、関連度スコアを０〜１の数値として、関連度が高いほど大きな数値で表現する。

具体例として、検索元文書である請求書に商品名という項目名として「ＡＢＣＤＥ」という項目値が記載されており、検索処理により抽出された見積書に商品名として「ＦＢＣＤＥ」が記載されている場合を考える。この場合、５文字からなる文字列のうち４文字が一致していることから、関連度スコアは「０．８」と算出される。また、文字列の一致度だけでなく、検索元文書から取得したメタデータと抽出文書から取得したメタデータに含まれている合計金額の数値の近さや、文書同士の発行日の日付の近さによって関連度を算出してもよい。

関連度スコアの算出には、ステップＳ７０２で取得したＯＣＲ結果を用いてもよいし、画像データから取得されるメタデータに限られず、それ以外のメタデータを用いてもよい。例えば、検索元である証憑文書がスキャンされた日時と、検索処理により抽出された文書がスキャンされた日時と、の差を用いて関連度スコアを算出してもよい。その他にもさまざまな手法はあるが、検索元の証憑文書と検索処理により抽出された証憑文書とが同一取引で使用された文書同士であることを示す度合いを算出できるものであればよい。

ステップＳ７０８において、ＣＰＵ４０１は、ステップＳ７０７で算出した関連度スコアに基づいて、Ｓ７０４でＨＤＤ４０４へ保存した検索結果を更新する。
ステップＳ７０９において、ＣＰＵ４０１は、ステップＳ７０８で更新した検索結果を、ＬＡＮ１０４を通じてＰＣなどの情報処理端末１０１に送信する。
これにより、ユーザは、情報処理端末１０１上で、スキャン対象である検索元の証憑文書と同一取引で使用された可能性の高い証憑文書を容易に見つけ出すことができる。

＜ＯＣＲ関連処理＞
次に、図８を用いて、Ｓ７０２及びＳ７０６において実行されるＯＣＲ関連処理の詳細について説明する。図８は、１枚の画像データ（スキャン画像）に対して、ＯＣＲ処理とその前処理とを含めたＯＣＲ関連処理を実行する処理手順を示すフローチャートである。

まず、ステップＳ８０１において、クラウドサービスサーバ１０２のＣＰＵ４０１は、傾き補正処理を行う。傾き補正処理では、画像データから傾き角度を検出し、検出した傾き角度だけ逆方向に画像データを回転することにより、傾き補正をした画像データを生成する。傾き補正の対象となる傾きは、画像形成装置１００のスキャナ部２１０による読み取り時に、原稿フィーダ内のローラの摩耗などが原因でまっすぐに原稿が読み取られなかったり、原稿の印刷時にまっすぐに印字できなかったりすることにより発生する。
傾き角度の検出では、画像データ内に含まれるオブジェクトを検出し、水平方向あるいは鉛直方向に隣り合うオブジェクト群を連結する。そして、連結されたオブジェクトの中心位置を結んだ角度が、水平方向あるいは鉛直方向からどれだけ傾いているかを取得することで傾き角度を求める。

なお、傾き角度の検出は、上記の手法に限られるものではない。例えば、画像データ内に含まれるオブジェクトの中心座標を取得し、０．１度単位で中心座標群を回転させながら、中心座標群が水平方向あるいは垂直方向に並ぶ割合がもっとも高い角度を傾きとして求めてもよい。Ｓ８０１の傾き補正により画像データの傾きを補正することで、後述する回転補正（Ｓ８０２）、ブロックセレクション処理（Ｓ８０３）、ＯＣＲ処理（Ｓ８０４）のそれぞれの精度を上げることが可能となる。

ステップＳ８０２において、ＣＰＵ４０１は、ステップＳ８０１で生成した傾き補正処理後の画像データに対して、回転補正処理を行う。回転補正処理では、原稿内の文字が正立する向きになるように、９０度単位で回転補正した画像データを生成する。
この際、ステップＳ８０１で取得した傾き補正処理後の画像を基準画像として、基準画像、９０回転した画像、１８０度回転した画像、２７０度回転した画像、の４枚の画像データを用意する。そして、４枚の画像にデータ対して、高速処理可能な簡易的なＯＣＲ処理を実行して、一定値以上の確信度を持って認識された文字の数が最も多い画像データを回転補正後の画像データとして取得する。なお、回転補正処理の方法は上記に限られるものではない。

ステップＳ８０３において、ＣＰＵ４０１は、ステップＳ８０２で生成した回転補正処理後の画像データに対し、ブロックセレクション処理を行う。ブロックセレクション処理とは、画像を前景領域と背景領域に分類した上で、前景領域をテキストブロックとそれ以外のブロックに分割する処理である。そして、テキストブロック毎に、白黒に二値化された画像データに基づいて、ＴＥＸＴ（文字領域）、ＬＩＮＥ（線領域）、ＴＡＢＬＥ（表領域）、ＰＨＯＴＯ（写真領域）、ＰＩＣＴＵＲＥ（図面領域）などのブロック情報を取得する。ブロックセレクション処理で取得されたテキストブロック毎のブロック情報は、次のＯＣＲ処理で用いられる。

ステップＳ８０４において、ＣＰＵ４０１は、ステップＳ８０３で取得した各テキストブロックに対してＯＣＲ処理を実行する。ＯＣＲ処理により、ＯＣＲ結果として、各テキストブロックに対応する文字列が抽出される。

＜項目値と項目値の取得処理＞
次に、Ｓ７０３で実行されるメタデータ（項目名と項目値）の抽出処理の詳細について説明する。
メタデータの抽出処理において、クラウドサービスサーバ１０２のＣＰＵ４０１は、Ｓ７０２のＯＣＲ関連処理で取得したＯＣＲ結果を用いて、スキャン画像内に記載されている項目名と項目値を取得する。ここで、項目名は、データの意味を指す「キー項目」を指す。また、項目値は、項目名に対応する具体的な内容を示す「バリュー値」を指す。また、項目名と、その項目名に対応した項目値が対になったデータを、メタデータと呼ぶ。

ここで、図６Ａを用いて、項目名及び項目値について具体的に説明する。
図６Ａ（１）は、証憑文書の一種である請求書の例である。また、図６Ａ（２）は、図６Ａ（１）に示した請求書において、各テキストブロックから項目名や項目値を構成する文字列が抽出される例を説明したものである。
図６Ａ（２）の例では、例えば、テキストブロック６０２に示される「請求先会社名」という項目名について、その項目名の内容として会社名である「ＡＢＣ（株）」という項目値が抽出される。その他、図６Ａ（２）の例では、テキストブロック６０３に示される「請求元会社名」という項目名について「株式会社あいう」という項目値、テキストブロック６０５に示される「案件番号」という項目名について「１２３４」という項目値、などが抽出される。

項目名及び項目値を抽出する手法は様々ある。例えば、抽出したい項目値を保持しておき、その項目値と一致している文字列がＯＣＲ結果において抽出された場合、その文字列が記載されたテキストブロックの座標値をブロックセレクション処理の結果から取得することも可能である。また、文字列を取得したテキストブロックに最も近い右側、下側、右下側などのテキストブロックのＯＣＲ結果から項目名や項目値を抽出することも可能である。

また、スキャン画像に項目名が記載されていない場合には、文字列のパターンから項目値を判定することもできる。例えば、図６Ａ（２）の例では、テキストブロック６０４に示すように、日付を示す「２０１９年４月２５日」の文字列が「ＹＹＹＹ年Ｍ月ＤＤ日」の並びパターンになっていることを正規表現などの手法で推定する。その結果、テキストブロック６０４は、「（請求）日付」という項目名について、「２０１９年４月２５日」という項目値であると判定することもできる。

その他、文字列の位置やフォントサイズの情報に基づいて、項目名と項目値を判定できるものもある。例えば、位置情報でスキャン画像の上部にあり、フォントサイズ情報で周囲の文字よりも大きい文字列は、「書類名」と推定することができる。図６Ａ（２）の例では、テキストブロック６０１に示される、「請求書」という文字列は「書類名」という項目名についての項目値であると判定することができる。

具体的に抽出する情報としては、書類名に関する情報、会社の名称・電話番号・住所などの会社に関する情報、担当者や作成者などの個人に関する情報、請求日や納品日などの日付に関する情報、請求書番号などの情報、などがある。他にも、案件名に関する情報、合計金額などの金額に関する情報、その他内訳などの詳細情報、などもある。項目名及び項目値を抽出する手法は他にも様々あるが、ＯＣＲ結果から項目名及び項目値を抽出できるものであればよい。

＜検索処理＞
次に、図９を用いて、Ｓ７０４において実行される検索処理の詳細について説明する。図９は、Ｓ７０３で抽出したメタデータ（項目名と項目値）を用いてクラウドストレージサーバ１０３に対して検索処理を指示し、検索結果を取得する処理手順を示すフローチャートである。図９のフローチャートに示した検索処理は、検索結果に応じて、再度、検索クエリを生成し、検索結果を取得するため、動的検索処理ともいう。なお、この処理はクラウドサービスサーバ１０２のＣＰＵ４０１により実行される。

ステップＳ９０１において、クラウドサービスサーバ１０２のＣＰＵ４０１は、ＨＤＤ４０４から検索対象とする文書の種別を取得する。文書の種別とは、見積書、発注書、納品書などの証憑文書の種別のことである。なお、検索対象とする文書の種別は、事前に表示・操作部２０６や操作部３０７においてユーザにより設定されたものであってもよいし、予め所定の固定値として設定されたものであってもよい。他にも、スキャン画像の文字レイアウトと検索対象とする文書の種別の組み合わせをＨＤＤ４０４に保存しておき、スキャン画像の文字レイアウト情報に基づいて自動的に検索対象とする文書の種別を取得してもよい。また、検索対象とする文書の種別は一種類に限定されるものではない。例えば、見積書と発注書の２つの種別の文書を検索対象としてもよい。

ステップＳ９０２において、ＣＰＵ４０１は、ＨＤＤ４０４から１又は複数の検索クエリパターンを取得する。検索クエリパターンとは、検索クエリとなるメタデータの組み合わせを規定したものである。検索クエリパターンは、事前に表示・操作部２０６や操作部３０７においてユーザにより設定されたものであってもよいし、予め所定の固定値として設定されたものであってもよい。

ここで、図１０に、予め決められた固定の検索クエリパターンの例を示す。図１０には、５つの検索クエリパターンが設定されている例を示している。予め決められた固定の検索クエリパターンは、パターン１からパターン５になるにしたがって、検索条件が緩く、すなわち、検索処理により抽出される文書の数が多くなるように設定される。そして、最初に、検索条件が最も厳しいパターン１を取得する。その後、パターン２、パターン３、パターン４、パターン５のように順に検索条件が緩くなるように取得していく。ただし、検索クエリパターンの数は、ここに示した例には限られない。

図９のフローチャートでは、ステップＳ９０７からステップＳ９０２に戻るごとに、取得する検索クエリパターンをパターン１、パターン２、…の順に切り替えていく。そして、パターンｎ（ただし、ｎは１以上の整数）を用いた検索の結果により後述のステップＳ９０７においてＮｏと判断された場合、パターンｎ＋１を用いた検索に切り替え、ステップＳ９０７においてＹｅｓと判断されるまで、これを繰り返す。
なお、検索クエリパターンは、検索対象とする文書の種別ごとに異なって設定される。図９のフローチャートでは、ステップＳ９０１で取得した検索対象とする文書の種別ごとに、取得する検索クエリパターンを自動的に切り替えていく。

図１０の例では、検索対象とする文書の種別が見積書である場合、最初の検索クエリパターンとして、パターン１の「会社名ａｎｄ案件番号ａｎｄ発行日」を取得する。その後は、パターン２の「会社名ａｎｄ案件名ａｎｄ発行日」、パターン３の「会社名ａｎｄ発行日ａｎｄ合計金額」、パターン４の「会社名ａｎｄ発行日」、パターン５の「会社名」の順に取得していく。

図９のフローチャートの説明に戻り、ステップＳ９０３において、ＣＰＵ４０１は、ステップＳ９０２で取得した１又は複数の検索クエリパターンのうち、まだＳ９０５の検索指示に用いていない未実施の検索クエリパターンがあるか否かを判断する。
未実施の検索クエリパターンがある場合は、処理をステップＳ９０４に進める。すべての検索クエリパターンについて実施済みである場合は、本フローチャートは終了する。

ステップＳ９０４において、ＣＰＵ４０１は、ステップＳ７０３で取得したメタデータ（項目名と項目値）とステップＳ９０２で取得した検索クエリパターンとに基づいて、検索クエリを生成する。
例えば、取得したメタデータが「会社名：ＡＢＣ（株）」、「案件番号：１２３４」、「発行日：２０１９年４月２５日」であり、検索クエリパターンが「会社名ａｎｄ案件番号ａｎｄ発行日」である場合について説明する。この場合、検索クエリとして、「ＡＢＣ（株）ａｎｄ１２３４ａｎｄ２０１９年４月２５日」が生成される。

なお、検索クエリのうち、金額や発行日などの数値や日付からなるものは、数値や日付の範囲検索ができるように生成してもよい。また、検索クエリは、項目値からそのまま生成するだけでなく、項目値の文字列の正規化を行ってから生成してもよい。例えば、項目名が会社名である項目値「ＡＢＣ（株）」から「（株）」を消去して、「ＡＢＣａｎｄ１２３４ａｎｄ２０１９年４月２５日」のように検索クエリを生成してもよい。

なお、検索クエリパターンに対応するメタデータがスキャン画像に存在しない場合は、Ｓ９０５に進むことなく、ステップＳ９０２に処理を戻してもよい。例えば、検索クエリパターンが「会社名ａｎｄ案件番号ａｎｄ発行日」であり、スキャン画像から取得したメタデータに案件番号が含まれていない場合について考える。この場合、Ｓ９０５の検索指示を行うことなく、ステップＳ９０２に処理を戻し、Ｓ９０４で次の検索クエリを生成してからＳ９０５の検索指示を行うようにしてもよい。

ステップＳ９０５において、ＣＰＵ４０１は、ステップＳ９０４で生成した検索クエリに基づいて、クラウドストレージサーバ１０３に対して検索指示を行う。
例えば、メタデータとして、会社名が「ＡＢＣ（株）」、案件番号が「１２３４」、発行日が「２０１９年３月１日から２０１９年４月２５日」までの範囲である証憑文書を抽出するように検索処理の指示を行う。なお、検索指示はクラウドストレージサーバ１０３に保存されている証憑文書のメタデータに対して行ってもよいし、ファイル名に対して行ってもよいし、ＯＣＲ結果に対して行ってもよい。

ステップＳ９０６において、ＣＰＵ４０１は、ステップＳ９０５で行った検索指示に基づいて実行された検索処理により抽出された文書を検索結果としてクラウドストレージサーバ１０３から取得する。なお、取得する文書は、文書ファイルのデータ自体でもよいし、格納されているファイルのファイルパスでもよいし、ファイル名や作成者などのファイルの特徴が記載されたインデックス情報（プロパティ情報）だけであってもよい。

ステップＳ９０７において、ＣＰＵ４０１は、設定された検索結果数の閾値をＨＤＤ４０４から取得する。なお、検索結果数の閾値は、事前に表示・操作部２０６や操作部３０７においてユーザにより設定されたものであってもよいし、予め所定の固定値として設定されたものであってもよい。そして、ＣＰＵ４０１は、ステップＳ９０６で取得した、検索処理により抽出された文書数が設定された検索結果数の閾値の数以上であるか否かを判断する。

検索処理において抽出された文書数が設定された検索結果数の閾値以上であった場合は、本フローチャートは終了する。一方、検索処理において抽出された文書数が設定された検索結果数の未満であった場合は、ステップＳ９０２に戻る。そして、未実施の検索クエリパターンがある場合、再度、検索クエリを生成して（Ｓ９０４）、検索指示を行い（Ｓ９０５）、検索結果を取得する（Ｓ９０６）。

なお、Ｓ９０７において検索処理を終了するかステップＳ９０２に戻るかを判断する手法は、これに限定されるものではない。例えば、本フローチャートとは逆に、検索処理において抽出された文書数が設定された検索結果数の閾値以上の場合に処理をステップＳ９０２に戻し、設定された検索結果数の閾値未満の場合に処理を終了するようにしてもよい。また、検索結果数として複数の閾値を設定するようにしてもよい。

以上、実施例１によれば、検索処理で抽出された文書数に応じて、検索処理を終了するか、再度検索クエリを生成して、検索処理を実行するかを判断する。これにより、検索元の証憑文書と同一取引で使用された１又は複数存在する一連の対応文書を過不足なくユーザに提示することができる。また、検索元の証憑文書の記載内容から検索クエリを自動的に生成することにより、検索条件を指示するユーザの負担を軽減することができる。

＜実施例２＞
実施例１では、検索処理において、検索対象である文書の種別に基づいて検索クエリパターンを取得し、検索処理により抽出された文書数に応じて、段階的に検索クエリパターンを変更して再検索を行うか、検索を終了するかを判断した。

しかし、再検索を行うか否かを判断するための検索結果数の閾値を予め決められた固定の設定値とした場合、検索元の証憑文書と同一取引で使用された証憑文書の枚数によっては、すべての対応文書が抽出されないおそれがある。
そこで、実施例２では、検索処理において、検索元文書のスキャン画像を用いた文書マッチングの結果に基づいて、検索結果数の閾値を動的に変更していく。なお、以下では、主として実施例１と相違がある箇所について説明する。

図７は、実施例２におけるファイル検索システム１０において実行される処理の全体を説明するフローチャートである。図７に示した処理の全体は、基本的に実施例１と同様である。ただし、実施例２においては、Ｓ７０４において実行される検索処理が、実施例１で示した図９のフローチャートとは異なり、図１１のフローチャートに示すようになる。
以下では、図１１のフローチャートについて、図９に示した実施例１のフローチャートとの相違について説明する。

図１１において、ステップＳ９０１からステップＳ９０７の各処理については、実施例１の図９と同様である。ただし、実施例２では、実施例１の処理に加えて、ステップＳ９０８からステップＳ９１１の処理が付加されている。

ステップＳ９０８において、クラウドサービスサーバ１０２のＣＰＵ４０１は、文書マッチングを実行する。文書マッチングとは、文書の画像データが登録されたデータベースの中から、ブロック情報などを用いて、検索元文書と同一の文書を検索するために行われる処理である。図１２を用いて、スキャンされた証憑文書を登録した登録文書群データベースについて説明する

図１２Ａは、登録文書群データベースに、登録文書として、文書ＩＤ「０００１」という文書が登録されている例を示している。また、図１２Ｂは、登録文書として、文書ＩＤ「０００１」の証憑文書に加え、文書ＩＤ「０００２」という証憑文書が登録されている例を示している。
登録文書群データベースは、登録文書ごとに、文書ＩＤ、文書識別情報、対応文書数情報が登録されている。文書ＩＤは、スキャン対象の証憑文書を一意に特定するユニークなＩＤである。文書識別情報は、文書マッチングを行うために必要な、登録文書についてのブロック情報である。文書識別情報は、ステップＳ７０２（図７）のＯＣＲ関連処理を実行して得られるテキストブロック群から生成される。対応文書数情報は、検索対象とする文書の種別ごとに存在する、同一取引で使用された対応文書の枚数を示している。

例えば、図１２Ａの例では、文書ＩＤ「０００１」の証憑文書に対しては、同一取引で使用された対応文書として、２枚の見積書、２枚の発注書、１枚の納品書があることを示している。なお、対応文書の枚数は、すべての種別について同じであってもよいし、異なっていてもよい。また、図１２に示したように、登録文書群データベースには、スキャン画像のサムネイルを保持してもよい。

本実施例では、まず、検索元文書のスキャン画像と各登録文書の画像との間で、それぞれ、ＯＣＲ関連処理で得られるテキストブロックの形状や配置がどれだけ類似しているかを表す類似度を算出する。類似度を算出する際には、まず、スキャン画像のテキストブロック全体と、登録文書のテキストブロック全体との、位置合わせを行う。
次に、検索元文書内の各テキストブロックと登録文書内のテキストブロックとが重なる面積の総和の二乗を、検索元文書内のテキストブロック面積の総和と登録文書内のテキストブロック面積の総和の積で割った値を算出し、この値を類似度とする。

そして、登録文書群データベースに登録されているすべての登録文書について、検索元文書との類似度を算出する。そして、最も高い類似度が一定値以上であれば、その文書が検索元文書と同一の文書であると判定する。また、最も高い類似度が一定値より小さければ、検索元文書は登録文書群データベースに登録されていないと判定する。

なお、文書マッチングは、上記の手法に限られるものではない。例えば、文書識別情報として、ＯＣＲ関連処理の結果として取得した文字列群を保持し、それらの類似度に基づいて文書マッチングを行ってもよい。また、文書識別情報として画像データから得られる画像特徴量を保持しておき、画像特徴量の類似度に基づいて文書マッチングを行ってもよい。

図１１のフローチャートの説明に戻り、ステップＳ９０９において、ＣＰＵ４０１は、ステップＳ９０８で実行した文書マッチングの結果、検索元文書が登録文書群データベースに登録されているか否かを判断する。
検索元文書が登録されている場合、処理をＳ９１０に進める。検索元文書が登録されていない場合は、処理をＳ９０２に進める。

ステップＳ９１０において、ＣＰＵ４０１は、ステップＳ９０８の文書マッチングにより特定された登録文書と、ステップＳ９０１で取得した検索対象とする文書の種別と、に基づいて、登録文書群データベースから対応文書数を取得する。
例えば、ステップＳ９０８の文書マッチングの結果として文書ＩＤ「０００１」（図１２Ｂを参照）が特定され、ステップＳ９０１で取得した検索対象とする文書の種別が見積書である場合、対応文書数として「２」を取得する。なお、検索対象とする文書の種別が複数存在する場合には、取得する対応文書数も種別ごとに異なっていてもよい。

ステップＳ９１１において、ステップＳ９１０で取得した対応文書数に基づいて、検索結果数の閾値を再設定してＨＤＤ４０４に保存する。
例えば、ステップＳ９１０で対応文書数として「２」を取得した場合、検索結果数の閾値を「２」に設定する。なお、検索結果数の閾値は、取得した対応文書数と同じ数値に設定することに限られるものではなく、取得した対応文書数より大きな数値に設定してもよい。ここで再設定された閾値は、Ｓ９０７の処理を行う際に用いられる。

以上、実施例２によれば、登録文書群データベースに記載されている検索元文書についての対応文書数情報に応じて、検索結果数の閾値を動的に変更していく。これにより、所望の証憑文書を過不足なく抽出することが可能になる。

＜実施例３＞
実施例２では、検索処理において、検索元文書が登録文書群データベースに登録されている場合、登録文書群データベースに記載されている対応文書数情報に応じて検索結果数の閾値を動的に変更した。

これに対して、実施例３では、検索元文書のスキャン画像内のレイアウト構造に基づいて、検索結果数の閾値を動的に決定していく。
本実施例では、レイアウト構造として、請求書などの証憑文書における明細項目欄の表構造を用いる。例えば、図６Ａ（２）の例では、請求書の明細項目欄に、６０７から６０９で示されるように、商品名が３つ記載されている。このように、明細項目欄に商品名が３つ記載されている場合、対応文書数が３つである可能性が高い。そこで、実施例３では、スキャン画像内の表構造を解析することにより、検索結果数の閾値を動的に変更して検索処理を行う。なお、以下では、主として実施例２と相違がある箇所についてのみ説明する。

図７は、実施例３におけるファイル検索システム１０において実行される処理の全体を説明するフローチャートである。図７に示した処理の全体は、基本的に実施例１や実施例２と同様である。ただし、実施例３においては、Ｓ７０４において実行される検索処理が、実施例１で示した図９のフローチャートや実施例２で示した図１１のフローチャートとは異なり、図１３のフローチャートに示すようになる。
以下では、図１３のフローチャートについて、図１１に示した実施例２のフローチャートとの相違について説明する。

図１３において、ステップＳ９０１からステップＳ９０７、及びステップＳ９１１の各処理については、実施例２の図１１と同様である。ただし、実施例３では、実施例２のステップＳ９０８からステップＳ９１１の処理は存在しない。代わりに、実施例３では、ステップＳ９１２の処理が付加されている。

ステップＳ９１２において、クラウドサービスサーバ１０２のＣＰＵ４０１は、スキャン画像の表構造解析を行い、対応文書数を取得する。表構造解析とは、スキャン画像の表構造を解析することにより、スキャンされた文書の対応文書数を推定する処理である。以下に、図１４を用いて、表構造解析について説明する。

表構造解析では、まず、ステップＳ８０３（図８）で実行したブロックセレクション処理の結果から、各文字領域と各線領域のブロック情報を取得する。
図１４に、ブロックセレクション処理の結果の一例を示す。図１４（１）は、図６Ａ（１）で示した証憑文書について、ステップＳ８０２の回転補正処理後の画像の例を示している。また、図１４（２）は、図１４（１）の画像についてのＳ８０３のブロックセレクション処理の結果を示している。なお、図１４（２）において、「ＴＥＸＴ」は文字領域を示している。また、「ＬＩＮＥ」は線領域を示している。

次に、連続する２つの線領域を選択し、これらのブロック情報から、２つの線領域に挟まれている文字領域のブロック数をカウントする。この際、同じ行内にある文字領域は、列方向の位置が異なっていても、１つの文字領域としてカウントする。
図１４（２）の例では、ＬＩＮＥ（１）とＬＩＮＥ（２）の２つの線領域に挟まれている領域の文字領域のブロック数は「１」とカウントする。

以下、連続する２つの線領域の選択を繰り返し、すべての線領域の組み合わせにおいて、２つの線領域に挟まれている文字領域のブロック数をカウントする。すべての線領域の組み合わせにおいて文字領域のブロック数のカウントが終了したら、カウントしたブロック数の最大値をスキャンされた文書の対応文書数として取得する。
図１４（２）の例では、文字領域のブロック数の最大値は、ＬＩＮＥ（２）とＬＩＮＥ（３）の２つの線領域に挟まれている領域の「３」となる。そのため、対応文書数は「３」となる。
なお、表構造解析の手法は、上記のものに限られるものではない。

そして、図１３のフローチャートに戻り、Ｓ９１２の表構造解析において取得した対応文書数に基づいて、Ｓ９１１において検索結果数の閾値の再設定を行う。それ以降の処理は、実施例２の図１１のフローチャートと同様である。

以上、実施例３によれば、スキャン画像の表構造を解析して検索結果数の閾値を動的に変更していくことにより、所望の文書を過不足なく抽出することが可能になる。

＜その他の実施例＞
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上述の実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形が可能であり、それらを本発明の範囲から除外するものではない。すなわち、上述した実施例及びその変形例を組み合わせた構成もすべて本発明に含まれるものである。

１０ ファイル検索システム
１００ 画像形成装置
１０２ クラウドサービスサーバ

Claims (17)

1. 入力された画像から第１の検索クエリを生成する生成手段と、
   前記第１の検索クエリを用いて、前記入力された画像に関連するファイルの検索を行う検索手段と、
   前記検索手段が抽出したファイルに関する情報を提供する提供手段と、
   を有するファイル検索システムであって、
   前記第１の検索クエリを用いた検索の結果に基づいて、前記第１の検索クエリを更新するか否かを判断する判断手段を有し、
   前記判断手段が前記第１の検索クエリを更新すると判断した場合、
   前記生成手段は、第２の検索クエリを生成し、
   前記検索手段は、前記第２の検索クエリを用いて、再度、ファイルの検索を行い、
   前記提供手段は、前記検索手段が前記第２の検索クエリを用いて抽出したファイルに関する情報を提供する
   ことを特徴とするファイル検索システム。
2. 前記判断手段は、前記第１の検索クエリを用いた検索により抽出されたファイルの数に基づいて、前記第１の検索クエリを更新するか否かを判断する
   ことを特徴とする請求項１に記載のファイル検索システム。
3. 前記判断手段は、前記第１の検索クエリを用いた検索により抽出されたファイルの数と、所定の数と、に基づいて、前記第１の検索クエリを更新するか否かを判断する
   ことを特徴とする請求項２に記載のファイル検索システム。
4. 前記判断手段は、
   前記第１の検索クエリを用いた検索により抽出されたファイルの数が前記所定の数より少ない場合、前記第１の検索クエリを更新すると判断し、
   前記第１の検索クエリを用いた検索により抽出されたファイルの数が前記所定の数以上の場合、前記第１の検索クエリを更新しないと判断する
   ことを特徴とする請求項３に記載のファイル検索システム。
5. 前記所定の数を格納した記憶手段をさらに有し、
   前記記憶手段は、入力された画像ごとに前記所定の数を格納する
   ことを特徴とする請求項３又は４に記載のファイル検索システム。
6. 前記所定の数は、前記入力された画像のレイアウト構造に基づいて決定される
   ことを特徴とする請求項３又は４に記載のファイル検索システム。
7. 前記生成手段は、前記入力された画像内の文字列から前記第１の検索クエリ及び前記第２の検索クエリを生成する
   ことを特徴とする請求項１乃至６のいずれか１項に記載のファイル検索システム。
8. 前記生成手段は、前記入力された画像内の文字列の組み合わせから前記第１の検索クエリ及び前記第２の検索クエリを生成する
   ことを特徴とする請求項７に記載のファイル検索システム。
9. 前記組み合わせを規定した複数のパターンが用意され、
   前記生成手段は、前記入力された画像内の前記文字列を前記複数のパターンのうちの１のパターンに設定する
   ことを特徴とする請求項８に記載のファイル検索システム。
10. 前記判断手段が前記第１の検索クエリを更新すると判断した場合、前記生成手段は、前記１のパターンを切り替えることにより、前記第１の検索クエリを更新する
    ことを特徴とする請求項９に記載のファイル検索システム。
11. 前記生成手段は、前記第２の検索クエリを用いた検索により抽出されるファイルの数が前記第１の検索クエリを用いた検索により抽出されたファイルの数より多くなるように、前記１のパターンを切り替える
    ことを特徴とする請求項１０に記載のファイル検索システム。
12. 前記入力された画像に関連するファイルは、複数の異なるファイルの種別ごとに、それぞれ、１又は複数存在する
    ことを特徴とする請求項１乃至１１のいずれか１項に記載のファイル検索システム。
13. 前記判断手段は、前記ファイルの種別ごとに、前記第１の検索クエリを用いた検索により抽出されたファイルの数に基づいて、前記第１の検索クエリを更新するか否かを判断する
    ことを特徴とする請求項１２に記載のファイル検索システム。
14. 前記入力された画像は、文書をスキャンすることにより生成された画像である
    ことを特徴とする請求項１乃至１３のいずれか１項に記載のファイル検索システム。
15. 前記文書に画像に関連するファイルは、前記文書と同一取引で使用された一連の証憑文書である
    ことを特徴とする請求項１４に記載のファイル検索システム。
16. 入力された画像から第１の検索クエリを生成する生成手段と、
    前記第１の検索クエリを用いて、前記入力された画像に関連するファイルの検索を行う検索手段と、
    前記検索手段が抽出したファイルに関する情報を提供する提供手段と、
    を有するファイル検索システムにおけるファイル検索方法であって、
    前記第１の検索クエリを用いた検索の結果に基づいて、前記第１の検索クエリを更新するか否かを判断する判断ステップを有し、
    前記判断ステップにおいて前記第１の検索クエリを更新すると判断した場合、
    前記生成手段は、第２の検索クエリを生成し、
    前記検索手段は、前記第２の検索クエリを用いて、再度、ファイルの検索を行い、
    前記提供手段は、前記検索手段が前記第２の検索クエリを用いて抽出したファイルに関する情報を提供する
    ことを特徴とするファイル検索方法。
17. 請求項１６のファイル検索方法をコンピュータにより実行させるためのプログラム。

Images