JP2022096218A - 情報処理装置、情報処理システム、その制御方法及びプログラム - Google Patents

Abstract

【課題】文書ファイルのプロパティに用いる文字列としてより間違いの少ない文字列を、ユーザがより簡便に設定できるようにすることを目的とする。【解決手段】文書のスキャン画像に対する文字認識処理の結果を用いて文書ファイルのプロパティを設定するための画像処理装置であって、取得手段と、設定手段と、を備える。取得手段は、今回生成する文書ファイルに係るスキャン画像に対して文字認識処理を行って文字列を取得する。設定手段は、取得手段が取得した文字列が、過去に生成された文書ファイルに係るスキャン画像に対する文字認識処理において得られた文字列であってユーザが一定回数以上承認した文字列である場合、取得手段が取得した文字列を、今回生成する文書ファイルのプロパティに使用する文字列として自動で設定する。【選択図】 図１２

Description

本発明は、文書ファイルにプロパティを設定するための技術に関するものである。

従来、紙帳票等の文書をスキャンしてファイル化して、ネットワーク上のストレージサーバにて保存・管理する手法が広く利用されている。ネットワーク上のストレージサーバに文書ファイルとして保存・管理するには、ファイル名等のプロパティの設定が必要になる。例えばファイル名を設定する方法として、文書のスキャン画像を文字認識処理して文字情報を抽出し、得られた文字情報の中からファイル名として用いる文字列を選択する方法がある。

また、ユーザがファイル名の設定で使用した文字列の文字領域情報を文書の種別毎に保存・蓄積しておくことも行われている。そして、文書フォームの特徴が過去に保存された文書と一致する場合に、当該過去の文書で使用された文字列を、ファイル名に使用するための文字列として自動で提案することも行われている。この場合において、過去にファイル名の設定に使用された文字列が誤っていると、誤った文字列が提案されてしまう。

この点、特許文献１には、文字認識処理した文字列の確からしさを表す指標として確信度を用いる技術であって、文字認識処理された文字列の確信度が高くても、ユーザに確認や訂正を促す技術が開示されている。

特開２０２０－４６８１９号公報

上記特許文献１の技術では、ユーザに確認や訂正を行わせることで文字列の確からしいことを担保しようとしているが、ユーザ自身が修正ミスや確認ミスをすることも考えられる。そうなると、ユーザ自身の修正ミス等により誤った文字列がファイル名等に設定されることになる。

本開示の技術は、上記問題点に鑑みてなされたものであり、文書ファイルのプロパティに用いる文字列としてより間違いの少ない文字列を、ユーザがより簡便に設定できるようにすることを目的とする。

本開示に係る画像処理装置は、文書のスキャン画像に対する文字認識処理の結果を用いて文書ファイルのプロパティを設定するための画像処理装置であって、今回生成する文書ファイルに係るスキャン画像に対して文字認識処理を行って文字列を取得する取得手段と、前記取得手段が取得した文字列が、過去に生成された文書ファイルに係るスキャン画像に対する文字認識処理において得られた文字列であってユーザが一定回数以上承認した文字列である場合、前記取得手段が取得した文字列を、前記今回生成する文書ファイルのプロパティに使用する文字列として自動で設定する設定手段とを備えたことを特徴とする。

本開示の技術によれば、文書ファイルのプロパティに用いる文字列としてより間違いの少ない文字列を、ユーザがより簡便に設定することができる。

本システムの全体構成を示す図。 ＭＦＰのハードウェア構成図。 ＭＦＰ連携サーバ及びストレージサーバのハードウェア構成図。 本システムのソフトウェア構成図。 各機器間の処理の流れを示すシーケンス図。 メインメニューのＵＩ画面の一例を示す図。 ログイン画面の一例を示す図。 スキャン設定画面の一例を示す図。 本システムにおける解析処理の結果を示すデータ構造の一例を示す図。 ファイル名設定画面の一例を示す図。 送信確認画面の一例を示す図。 本システムにおける画像処理部が行う文字認識処理の詳細を示すフローチャート。 本システムにおける画像処理部が行う自動送信判定処理の詳細を示すフローチャート。 本システムにおける画像処理部が行うファイル名設定情報保存処理の詳細を示すフローチャート。 実施形態２における画像処理部が行う自動送信判定処理の詳細を示すフローチャート。 実施形態３における画像処理部が行うファイル名設定情報保存処理の詳細を示すフローチャート。

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

［実施形態１］
＜システム構成＞
図１は、本実施形態に係る、画像処理システムの全体構成を示す図である。画像処理システムは、ＭＦＰ（Multifunction Peripheral）１１０と、インターネット上でクラウドサービスを提供するサーバ装置１２０及び１３０とを含む。ＭＦＰ１１０は、インターネットを介してサーバ装置１２０及び１３０と通信可能に接続されている。

ＭＦＰ１１０は、スキャン機能を有する情報処理装置の一例である。ＭＦＰ１１０は、スキャン機能に加え印刷機能やＢＯＸ保存機能といった複数の機能を有する複合機である。サーバ装置１２０及び１３０は、共にクラウドサービスを提供する情報処理装置の一例である。本実施形態のサーバ装置１２０は、ＭＦＰ１１０から受け取ったスキャン画像に対し画像解析を行ったり、別のサービスを提供するサーバ装置１３０に対しＭＦＰ１１０からのリクエストを転送したりするクラウドサービスを提供する。以下、サーバ装置１２０が提供するクラウドサービスを「ＭＦＰ連携サービス」と呼ぶこととする。サーバ装置１３０は、インターネットを介して送られてきたファイルを保存したり、クライアントＰＣ（不示図）などのウェブブラウザからの要求に応じて保存ファイルを提供したりするクラウドサービス（以下、「ストレージサービス」と呼ぶ。）を提供する。本実施形態では、ＭＦＰ連携サービスを提供するサーバ装置１２０を「ＭＦＰ連携サーバ」と呼び、ストレージサービスを提供するサーバ装置１３０を「ストレージサーバ」と呼ぶこととする。

図１に示す画像処理システムの構成は一例であって、これに限定されない。例えば、ＭＦＰ連携サーバ１２０の機能をＭＦＰ１１０が兼ね備えていてもよい。また、ＭＦＰ連携サーバ１２０はインターネット上ではなくＬＡＮ（Local Area Network）経由でＭＦＰ１１０と接続されていてもよい。また、ストレージサーバ１３０を、メール配信サービスを行うメールサーバに置き換えて、文書のスキャン画像をメールに添付し送信する場面に適用してもよい。

＜ＭＦＰのハードウェア構成＞
図２は、ＭＦＰ１１０のハードウェア構成を示すブロック図である。ＭＦＰ１１０は、制御部２１０、操作部２２０、プリンタ部２２１、スキャナ部２２２、モデム２２３で構成される。制御部２１０は、以下の各部２１１～２１９で構成され、ＭＦＰ１１０全体の動作を制御する。ＣＰＵ２１１は、ＲＯＭ２１２に記憶された様々な制御プログラム（後述のソフトウェア構成図で示す各種機能に対応するプログラム）を読み出して実行する。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。なお、本実施例では１つのＣＰＵ２１１が１つのメモリ（ＲＡＭ２１３又はＨＤＤ２１４）を用いて後述のフローチャートに示す各処理を実行するものとするが、これに限定されない。例えば、複数のＣＰＵや複数のＲＡＭ又はＨＤＤを協働させて各処理を実行してもよい。ＨＤＤ２１４は、画像データや各種プログラムを記憶する大容量記憶部である。操作部Ｉ／Ｆ２１５は、操作部２２０と制御部２１０とを接続するインタフェースである。操作部２２０には、タッチパネルやキーボードなどが備えられており、ユーザによる操作／入力／指示を受け付ける。なお、タッチパネルへのタッチ操作には、人の指による操作やタッチペンによる操作が含まれる。プリンタＩ／Ｆ２１６は、プリンタ部２２１と制御部２１０とを接続するインタフェースである。印刷用の画像データはプリンタＩ／Ｆ２１６を介して制御部２１０からプリンタ部２２１へ転送され、紙等の記録媒体上に印刷される。スキャナＩ／Ｆ２１７は、スキャナ部２２２と制御部２１０とを接続するインタフェースである。スキャナ部２２２は、不図示の原稿台やＡＤＦ（Auto Document Feeder）にセットされた原稿を光学的に読み取ってスキャン画像データを生成し、スキャナＩ／Ｆ２１７を介して制御部２１０に入力する。スキャナ部２２２で生成されたスキャン画像データは、プリンタ部２２１にて印刷したり（コピー出力）、ＨＤＤ２１４に保存したり、ＬＡＮを介してＭＦＰ連携サーバ１２０等の外部装置にファイル送信したりすることができる。モデムＩ／Ｆ２１８は、モデム２２３と制御部２１０とを接続するインタフェースである。モデム２２３は、ＰＳＴＮ上のファクシミリ装置（不図示）との間で画像データをファクシミリ通信する。ネットワークＩ／Ｆ２１９は、制御部２１０（ＭＦＰ１１０）をＬＡＮに接続するインタフェースである。ＭＦＰ１１０は、ネットワークＩ／Ｆ２１９を用いて、スキャン画像データをＭＦＰ連携サーバ１２０に送信したり、ＭＦＰ連携サーバ１２０から各種データを受信したりする。以上説明したＭＦＰ１１０のハードウェア構成は一例であり、必要に応じてその他の構成を備えるものであってもよいし、一部の構成を有していなくてもよい。

＜サーバ装置のハードウェア構成＞
図３は、ＭＦＰ連携サーバ１２０及びストレージサーバ１３０のハードウェア構成を示すブロック図である。ＭＦＰ連携サーバ１２０とストレージサーバ１３０は共通のハードウェア構成を有し、ＣＰＵ３１１、ＲＯＭ３１２、ＲＡＭ３１３、ＨＤＤ３１４及びネットワークＩ／Ｆ３１５で構成される。ＣＰＵ３１１は、ＲＯＭ３１２に記憶された制御プログラムを読み出して各種処理を実行することで、全体の動作を制御する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３１４は、画像データや各種プログラムを記憶する大容量記憶部である。ネットワークＩ／Ｆ３１５は、制御部３１０をインターネットに接続するインタフェースである。ＭＦＰ連携サーバ１２０及びストレージサーバ１３０は、ネットワークＩ／Ｆ３１５を介して他の装置（ＭＦＰ１１０など）から様々な処理のリクエストを受け、当該リクエストに応じた処理結果を返す。

＜画像処理システムのソフトウェア構成＞
図４は、本実施形態に係る、画像処理システムのソフトウェア構成を示すブロック図である。以下、画像処理システムを構成するＭＦＰ１１０及び、ＭＦＰ連携サーバ１２０及びストレージサーバ１３０それぞれの役割に対応したソフトウェア構成を、順に説明する。なお、以下では、各装置が有する諸機能のうち、文書をスキャンして電子化（ファイル化）し、ストレージサーバ１３０に保存を行うまでの処理に関わる機能に絞って説明を行うものとする。

≪ＭＦＰのソフトウェア構成≫
ＭＦＰ１１０の機能モジュールは、ネイティブ機能モジュール４１０とアディショナル機能モジュール４２０の２つに大別される。ネイティブ機能モジュール４１０はＭＦＰ１１０に標準的に備えられたアプリケーションであるのに対し、アディショナル機能モジュール４２０はＭＦＰ１１０に追加的にインストールされたアプリケーションである。アディショナル機能モジュール４２０は、Ｊａｖａ（登録商標）をベースとしたアプリケーションであり、ＭＦＰ１１０への機能追加を容易に実現できる。なお、ＭＦＰ１１０には図示しない他の追加アプリケーションがインストールされていてもよい。

ネイティブ機能モジュール４１０は、スキャン実行部４１１及びスキャン画像管理部４１２を有する。また、アディショナル機能モジュール４２０は、表示制御部４２１、スキャン制御部４２２、連携サービスリクエスト部４２３、画像処理部（不示図）を有する。

表示制御部４２１は、操作部２２０のタッチパネルに、各種のユーザ操作を受け付けるためのＵＩ（User Interface）画面を表示する。各種のユーザ操作には、例えば、ＭＦＰ連携サーバ１２０へアクセスするためのログイン認証情報の入力、スキャン設定、スキャンの開始指示、ファイル名設定、ファイルの保存指示などがある。

スキャン制御部４２２は、ＵＩ画面でなされたユーザ操作（例えば、後述の「スキャン開始」ボタン７０１の押下）に応じて、スキャン設定の情報と共にスキャン実行部４１１に対しスキャン処理の実行を指示する。スキャン実行部４１１は、スキャン制御部４２２からのスキャン処理の実行指示に従い、スキャナＩ／Ｆ２１７を介してスキャナ２２２に文書の読み取り動作を実行させ、スキャン画像データを生成する。生成したスキャン画像データは、スキャン画像管理部４１２によってＨＤＤ２１４に保存される。この際、保存されたスキャン画像データを一意に示すスキャン画像識別子の情報が、スキャン制御部４２２へ通知される。スキャン画像識別子は、ＭＦＰ１１０においてスキャンした画像をユニークに識別するための番号や記号、アルファベットなどである。スキャン制御部４２２は、例えばファイル化する対象のスキャン画像データを上記のスキャン画像識別子を使ってスキャン画像管理部４１２から取得する。そして、ファイル化のために必要な処理のリクエストをＭＦＰ連携サーバ１２０に対して行うよう、連携サービスリクエスト部４２３に対して指示する。

連携サービスリクエスト部４２３は、ＭＦＰ連携サーバ１２０に対して各種処理のリクエストを行ったり、そのレスポンスを受け取ったりする。各種処理には、例えば、ログイン認証、スキャン画像の解析、スキャン画像データの送信などが含まれる。ＭＦＰ連携サーバ１２０とのやり取りにはＲＥＳＴやＳＯＡＰなどの通信プロトコルが使用される。

画像処理部（不示図）は、スキャン画像データに対し所定の画像処理を行って、表示制御部４２１が表示するＵＩ画面で用いられる画像を生成する。所定の画像処理の詳細については後述する。

なお、ＭＦＰ１１０とは異なる装置（不図示のクライアントＰＣなど）が、上述のアディショナル機能モジュール４２０を備えていてもよい。すなわち、ＭＦＰ１１０にて得たスキャン画像の解析リクエストや解析結果に基づくファイル名の設定等を、クライアントＰＣで行うようなシステム構成でも構わない。

≪サーバ装置のソフトウェア構成≫
まず、ＭＦＰ連携サーバ１２０のソフトウェア構成について説明する。ＭＦＰ連携サーバ１２０は、リクエスト制御部４３１、画像処理部４３２、クラウドストレージアクセス部４３３、ファイル生成部４３４、表示制御部４３５を有する。リクエスト制御部４３１は、外部装置からのリクエストを受信できる状態で待機しており、受信したリクエスト内容に応じて、画像処理部４３２、クラウドストレージアクセス部４３３、ファイル生成部４３４に対し所定の処理の実行を指示する。

画像処理部４３２は、ＭＦＰ１１０から送られてくるスキャン画像データに対して、文字領域の検出処理、文字認識処理（ＯＣＲ処理）、類似文書の判定処理、自動送信判定の処理といった解析処理の他、回転や傾き補正といった画像加工処理を行う。

なお、以下では、スキャン画像から検出される文字領域を「文字領域」と呼ぶ。また、対象となる文書として、見積書や請求書といった帳票を例に説明を行うこととし、そのスキャン画像を「帳票画像」と呼ぶ。クラウドストレージアクセス部４３３は、ストレージサーバ１３０に対する処理のリクエストを行う。クラウドサービスでは、ＲＥＳＴやＳＯＡＰなどのプロトコルを用いてストレージサーバにファイルを保存したり、保存したファイルを取得したりするための様々なインタフェースを公開している。クラウドストレージアクセス部４３３は、公開されたインタフェースを使用して、ストレージサーバ１３０に対するリクエストを行う。ファイル生成部４３４は、リクエスト制御部４３１からの指示を受けて、スキャン画像を含む文書ファイルを生成する。その際、当該スキャン画像に含まれる文字列について文字認識処理した結果に基づくファイル名を設定する。表示制御部４３５は、インターネット経由で接続されたＰＣやモバイル端末（いずれも不図示）上で動作しているウェブブラウザからのリクエストを受けて、画面表示に必要な画面構成情報（ＨＴＭＬ、ＣＳＳ等）を返す。ユーザは、ウェブブラウザで表示される画面経由で、登録されているユーザ情報を確認したり、スキャン設定を変更したりできる。

次に、ストレージサーバ１３０のソフトウェア構成について説明する。ストレージサーバ１３０は、リクエスト制御部（不示図）、ファイル管理部（不示図）、表示制御部（不示図）を有する。リクエスト制御部（不示図）は、外部装置からのリクエストを受信できる状態で待機しており、本実施形態においてはＭＦＰ連携サーバ１２０からのリクエストに応じて、受信したファイルの保存や保存ファイルの読み出しをファイル管理部（不示図）に指示する。そして、リクエストに応じたレスポンスをＭＦＰ連携サーバ１２０に返す。表示制御部（不示図）は、インターネット経由で接続されたＰＣやモバイル端末（いずれも不図示）上で動作しているウェブブラウザからのリクエストを受けて、画面表示に必要な画面構成情報（ＨＴＭＬ、ＣＳＳ等）を返す。ユーザは、ウェブブラウザで表示される画面経由で、保存ファイルを確認したり取得したりすることができる。

＜全体の処理の流れ＞
図５は、ＭＦＰ１１０で文書（例えば、見積書等の帳票）をスキャンし、得られたスキャン画像（例えば、帳票画像）をファイル化してストレージサーバに保存する際の、装置間の処理の流れを示すシーケンス図である。なお、図５のシーケンス図は、スキャン画像をファイル化する際に付与されるファイル名を設定する場合の説明となっているが、ファイル名の他、フォルダパスやメタデータといったプロパティ全般に適用可能である。

図６Ａは、ＭＦＰ１１０の起動時に表示されるメインメニューのＵＩ画面（以下、「メイン画面」と呼ぶ。）の一例を示す図である。文書をスキャンしてファイル化し、クラウドストレージサービスの利用に必要な専用のアプリケーションをＭＦＰ１１０にインストールすることで、メイン画面６００上に「スキャンしてクラウドストレージに保存」ボタン６０１が表示されるようになる。そして、ユーザがメイン画面６００内に表示されたメニューボタンの中から「スキャンしてクラウドストレージに保存」ボタン６０１を押下すると、図５のシーケンス図で示される一連の処理が開始する。

以下、図５のシーケンス図に沿って、装置間のやり取りを時系列に説明する。なお、以下の説明において記号「Ｓ」はステップを表す。

Ｓ５０１において、ＭＦＰ１１０は、ＭＦＰ連携サーバ１２０にアクセスするためのログイン認証の情報を入力するＵＩ画面（以下、「ログイン画面」と呼ぶ。）を操作部２２０に表示する。操作部２２０に表示されるログイン画面６１０の一例を図６Ｂに示す。図６Ｂに示したように、ログイン画面６１０には、「ログイン」ボタン６１１、ＩＤ入力欄６１２及びパスワード入力欄６１３が含まれる。

Ｓ５０２において、ユーザが、予め登録されているユーザＩＤとパスワードとを、ログイン画面６１０上のＩＤ入力欄６１２及びパスワード入力欄６１３にそれぞれ入力し「ログイン」ボタン６１１を押下すると、ログイン認証のリクエストがＭＦＰ連携サーバ１２０に送信される。

Ｓ５０３において、ログイン認証のリクエストを受けたＭＦＰ連携サーバ１２０は、当該リクエストに含まれるユーザＩＤとパスワードを用いて認証処理を行う。認証処理の結果、正規のユーザであることが確認されれば、ＭＦＰ連携サーバ１２０は、アクセストークンをＭＦＰ１１０に返す。以後、ＭＦＰ１１０からＭＦＰ連携サーバ１２０に対して行う各種リクエストの際にこのアクセストークンを一緒に送ることで、ログイン中のユーザが特定される。本実施形態では、ＭＦＰ連携サーバ１２０へのログインの完了によって、ストレージサーバ１３０へのログインも同時に完了するものとする。このためにユーザは、インターネット上のＰＣ（不図示）のウェブブラウザ等を介して、ＭＦＰ連携サービスを利用するためのユーザＩＤとストレージサービスを利用するためのユーザＩＤとの紐付けを予め行っておく。これにより、ＭＦＰ連携サーバ１２０へのログイン認証に成功すれば同時にストレージサーバ１３０へのログイン認証も完了し、ストレージサーバ１３０にログインするための操作を省略できる。そして、ＭＦＰ連携サーバ１２０においては、自装置にログインしたユーザからのストレージサービスに関するリクエストにも対応可能となる。なお、ログイン認証の方法は一般的に公知な手法（Ｂａｓｉｃ認証、Ｄｉｇｅｓｔ認証、ＯＡｕｔｈを用いた認可等）を用いて行えばよい。

Ｓ５０４において、ログインが完了すると、ＭＦＰ１１０では、スキャン設定用のＵＩ画面（以下、「スキャン設定画面」と呼ぶ。）が操作部２２０に表示される。図７にスキャン設定画面の一例を示す。スキャン設定画面７００には、「スキャン開始」ボタン７０１、カラー設定欄７０２、解像度設定欄７０３が存在する。「スキャン開始」ボタン７０１は、原稿台にセットした文書（本実施形態では見積書や請求書といった帳票を想定）に対するスキャン処理の開始を指示するためのボタンである。カラー設定欄７０２では、スキャン時のカラーモードを設定する。例えばフルカラーやモノクロといった選択肢の中から指定できるようになっている。解像度設定欄７０３では、スキャン時の解像度を設定する。例えば６００ｄｐｉや１２００ｄｐｉといった選択肢の中から指定できるようになっている。なお、カラーモードと解像度は設定項目の一例であって、これらすべてが存在しなくてもよいし、これら以外の設定項目が存在してもよい。また、カラーモードや解像度に関する選択肢を、ストレージサービスの要求する設定値のみに限定したりしてもよい。ログイン中のユーザは、このようなスキャン設定画面７００を介してスキャン処理についての詳細な条件設定を行なう。

Ｓ５０５において、スキャン設定を終えたログイン中のユーザが、ＭＦＰ１１０の原稿台にスキャン対象の文書をセットし、「スキャン開始」ボタン７０１を押下するとスキャンが実行される。これにより、紙文書を電子化したスキャン画像データが生成される。

Ｓ５０６において、スキャンの完了後、ＭＦＰ１１０は、当該スキャンをすることによって得られた画像を含むデータであるスキャン画像データを、そのスキャン画像データを解析するためのリクエストである解析リクエストと共にＭＦＰ連携サーバ１２０に送信する。

Ｓ５０７において、スキャン画像の解析リクエストを受けたＭＦＰ連携サーバ１２０では、リクエスト制御部４３１が画像処理部４３２に対し、解析処理（Ｓ５０８～Ｓ５１１）の実行を指示する。その際、リクエスト制御部４３１は、受信した解析リクエストを一意に特定可能なリクエストＩＤ（“ｐｒｏｃｅｓｓＩｄ”）をＭＦＰ１１０に返す。

Ｓ５０８において、解析処理の実行指示を受けた画像処理部４３２は、解析リクエストに係るスキャン画像に対する解析処理を実行する。この解析処理では、まず、解析処理の対象となるスキャン画像（以下、「対象画像」と呼ぶ。）内に存在する文字領域を検出する処理（文字領域検出処理）を行う。文字領域の検出は、例えば、ある閾値で２値化を行った画像から文字と推測される矩形領域を抽出する方法等、既知の方法を適用すればよい。

Ｓ５０９において、画像処理部４３２は、画像解析の対象となる紙文書の画像データが以前に電子化された紙文書の画像と類似しているかどうかを学習データと照合して判定する処理を行う。例えば、画像解析の対象となる紙文書の例として、見積書等の帳票が挙げられる。また、画像解析の対象となる帳票の画像データが以前に電子化された帳票の画像と類似しているかどうかを学習データと照合して判定する処理のことを、以下、適宜、「類似帳票判定」と呼ぶ。この類似帳票判定では、対象画像内に存在する領域であり且つ、後述の文字認識処理の対象となる文字列が含まれる領域である文字領域（以下、適宜、「文字領域」と呼ぶ。）が当該対象画像内のどこにそれぞれ位置するかを示す情報である配置情報が用いられる。具体的には、今回生成する対象帳票画像の配置情報と、学習データに蓄積された過去の帳票画像の配置情報とを比較し、文字領域の配置が同一又は類似であるかどうかを判定する。これは、文字領域の配置が同一又は類似の関係にあれば、それらは同一の文書フォーム（帳票フォーム）を用いて作成された同種の帳票であると推測できることに基づいている。この類似帳票判定で使用する過去の帳票画像の配置情報は、後述の「学習処理」によって学習データとして蓄積される。なお、本実施形態では、文字領域の配置の一致度合いのみに基づき帳票の類否判定を行っているが、例えば、後述するＯＣＲ処理の結果から帳票の種別（見積書、請求書等）を特定し、得られた種別の情報を加味して類否判定を行ってもよい。

Ｓ５１０において、画像処理部４３２は、文字領域検出処理によって見つかった各文字領域に対して、文字認識処理を実行する。Ｓ５１０における画像処理部４３２の文字認識処理については、図１１を用いて後述する。

Ｓ５１１において、画像処理部４３２は、今回生成する対象画像の文書ファイルを自動送信の対象にしてもよいか否かの判定処理（以下、「自動送信判定処理」と呼ぶ。）を実行する。自動送信判定処理については、図１２を用いて後述する。

Ｓ５１２において、ＭＦＰ１１０は、上記解析処理が行われている間、上述のリクエストＩＤを使用して、ＭＦＰ連携サーバ１２０に対して定期的（例えば数百ミリ秒から数ミリ秒程度毎）に解析処理状況の確認を行う（Ｓ５１２～Ｓ５１３）。この確認は、ＭＦＰ連携サーバ１２０から解析処理が完了したことを表す情報を含むレスポンスが取得できるまで繰り返し実行される。ＭＦＰ連携サーバ１２０のリクエスト制御部４３１は、解析処理状況の確認をするためのリクエストを受けるとリクエストＩＤに対応する解析処理の進行状況を確認し、解析処理が完了していない場合は解析処理中であるステータスを表す処理中レスポンスを返す。他方、解析処理が完了していた場合は、完了レスポンスを返す。これらレスポンスの“ｓｔａｔｕｓ”には現在の処理状況を示す文字列が入る。具体的には、ＭＦＰ連携サーバ１２０で処理が行われている最中である場合（処理中レスポンス）には“ｐｒｏｃｅｓｓｉｎｇ”が入り、処理が完了している場合（完了レスポンス）には“ｃｏｍｐｌｅｔｅｄ”が入る。なお、処理が失敗した場合の“ｆａｉｌｅｄ”など、他のステータスを表す文字列が入ることもある。また、完了レスポンスには、画像解析結果の格納先を示すＵＲＬなどの情報も含まれる。そして、ＭＦＰ１１０は、上記解析処理の完了レスポンスを取得すると、当該完了レスポンスに含まれる、画像解析結果の格納先を示すＵＲＬを用いて、解析処理の結果を取得するためのリクエストを、ＭＦＰ連携サーバ１２０に対して送信する。ＭＦＰ連携サーバ１２０のリクエスト制御部４３１は、当該リクエストを受信すると、解析処理の結果を含む情報（結果情報）をＭＦＰ１１０に返信する。この際の結果情報には、対象画像について文字領域判定の結果、類似帳票判定の結果、文字認識処理の結果、自動送信判定処理の結果が含まれる。

図８は、解析処理の結果を示すデータ構造の一例を示す図である。“ｅｎａｂｌｅｄＡｕｔｏＴｒａｎｓｍｉｓｓｉｏｎ”には、対象画像がＳ５１１の自動送信判定処理により、ユーザの確認や学習を行わずにストレージサーバ１３０への送信の可否を示す値（「true」や「false」）が格納される。クライアントＰＣ（不示図）は、この値を参照することに基づいて、対象帳票を自動でストレージサーバ１３０に送信するか否かを決定する。“ｍａｔｃｈｅｄ”には、Ｓ５０９において、対象画像に係る帳票と類似する種別である帳票をスキャンして得られたスキャン画像である類似帳票が見つかったかどうかを示す値が格納される。“ｆｏｒｍＩｄ”には、類似する帳票があった場合はその帳票を一意に示す値が格納される。他方、類似する帳票がなかった場合には新たな値が発行され、当該新たな値が格納される。“ｍａｔｃｈｉｎｇＳｃｏｒｅ”には、類似する帳票があった場合にどの程度類似していたかを示す値が格納される。“ｍａｔｃｈｉｎｇＳｃｏｒｅ”は過去にスキャンした画像の配置情報と今回スキャンした画像の配置情報とが一致する度合いを０～１までの実数値で表す。そして、当該実数値が大きいほど、今回スキャンした画像は、過去にスキャンした画像に類似しているということになる。“ｒｅｃｔＩｎｆｏＡｒｒａｙ”には、類似する帳票に対して以前にユーザがファイル名を設定したときに使用した文字領域に対応する、今回の解析対象の画像の文字領域を示す情報が格納される。例えば、画像を以前にスキャンして「見積書」と「下丸子株式会社」を使用してファイル名を設定し入力結果学習したとする。その後、新規の画像をスキャンして前記スキャン画像と類似帳票判定を行った結果、類似帳票だと判定された場合、“ｒｅｃｔＩｎｆｏＡｒｒａｙ”以下には、入力した情報が自動入力対象の情報として格納される。まず、入力結果学習でＭＦＰ連携サーバ１２０のＨＤＤ３１４に保存された情報から以前に設定した「見積書」と「下丸子株式会社」の文字領域の座標情報と一部が重なる文字領域を特定する。すると、一部が重なる文字領域の座標情報と文字とが“ｒｅｃｔＩｎｆｏＡｒｒａｙ”の後述する“ｔｅｘｔ”に格納される。“ｋｅｙ”には、自動入力に使用する文字領域を一意に示す値が格納される。“ｓｃｏｒｅ”には、文字認識処理に対する結果の確からしさを表す指標である確信度を表す値が格納される。確信度は０～１までの実数値で表される。当該実数値が大きいほど、文字認識処理の結果が確からしいという意味になる。“ｒｅｇｉｏｎ”には、文字領域の座標情報とその文字認識した結果抽出した文字が格納される。“ｒｅｃｔ”は抽出した文字領域一つの座標を示す。“ｘ”は領域の左上のＸ座標、“ｙ”は領域の左上のＹ座標、“ｗｉｄｔｈ”は領域のＸ方向のピクセル数、“ｈｅｉｇｈｔ”は領域のＹ方向のピクセル数を示す。“ｔｅｘｔ”は“ｒｅｃｔ”の文字領域を文字認識処理して文字認識を行った結果、抽出された文字を示す。“ｍｅｔａｄａｔａＡｒｒａｙ”には、ファイル名を自動入力するためのファイル名に使用する文字領域の順番と区切り文字がどこに入るかを示す情報が格納される。ファイル名以外にもメタデータなどのプロパティを含む情報が設定されている場合は“ｒｅｃｔＩｎｆｏＡｒｒａｙ”や“ｍｅｔａｄａｔａＡｒｒａｙ”に必要な情報が追加される。“ｋｅｙ”には、スキャン文書に設定する設定値を一意に示す値が格納される。“ｋｅｙＴｙｐｅ”には、“ｋｅｙ”の設定値の種別を示す値が格納される。ファイル名に使用する場合は、“ｋｅｙ”が“ｆｉｌｅｎａｍｅ”で“ｋｅｙＴｙｐｅ”が“ｆｉｌｅｎａｍｅ”となる。“ｖａｌｕｅ”には、“ｋｅｙ”の値に使用する文字領域と区切り文字の情報が格納される。図８の例では“ｒｅｃｔＩｎｆｏＡｒｒａｙ”の中の“ｆｉｌｅＲｅｇｉｏｎ０”の“ｋｅｙ”を持つ領域、区切り文字、“ｆｉｌｅＲｅｇｉｏｎ１”の“ｋｅｙ”を持つ領域の順番でファイル名を自動入力されることになる。

そして、自動送信判定処理の結果が「自動送信不可」であった場合、ユーザに確認や修正等を促すため、後述するＳ５１５～Ｓ５１８の処理を実行する。他方、自動送信判定処理の結果が「自動送信可能」であった場合には、後述するＳ５１５～Ｓ５１８の処理を実行することなくＳ５２０に進み、対象画像の文書ファイルが自動生成されてストレージサーバ１３０に対して自動送信される（Ｓ５２１）。文書ファイルの自動生成の際には、文字認識処理で得られた文字列がそのファイル名に使用される。

自動送信判定処理の結果が「自動送信不可」であった場合、Ｓ５１５において、ＭＦＰ１１０は、Ｓ５１４で取得した結果情報を使用してファイル名を設定するためのファイル名設定画面９００（図９参照）を表示する。ファイル名設定画面９００のファイル名入力欄９０１には、予め最も確からしいと判定された文字列（初期文字列）が入力されている。つまり、累積承認回数を満たさず自動送信されないことになった場合は、そのときの確定文字列を使用した暫定的なファイル名がユーザに提示されることになる。ここで、ファイル名入力欄９０１に表示された文字列について誤りがない場合、ユーザは、その文字列をファイル名として承認するために「ＯＫ」ボタン９０２を押下する。他方、その文字列について誤りがある場合、ユーザは、誤りを手入力で適宜修正した上で「ＯＫ」ボタン９０２を押下することになる。

上記「ＯＫ」ボタン９０２が押下されたことを検知すると、Ｓ５１６において、ＭＦＰ１１０は、送信確認画面１０００（図１０参照）を操作部２２０に表示する。そして、ＭＦＰ１１０は、ユーザによって「送信」ボタン１００１が押下されたことを検知すると、ファイル名設定情報を保存するためのリクエストをＭＦＰ連携サーバ１２０に対して送信する。ここで、確定文字列の修正が行われなかった場合のファイル名設定情報には、文字認識処理された結果、最も確からしい文字列としてファイル名入力欄９０１に表示された文字列が含まれる。また、確定文字列の修正が行われた場合のファイル名設定情報には、その文字列の文字領域情報、その文字列が記載されていた帳票の種別に関する情報が含まれる。そして、確定文字列の修正が行われた場合のファイル名設定情報には、その修正前後の文字列の情報をさらに含むことになる。

Ｓ５１７において、ＭＦＰ連携サーバ１２０のリクエスト制御部４３１は、ファイル名設定情報をＭＦＰ１１０から受信した場合、画像処理部４３２に対して当該ファイル名設定情報の保存を指示する。

Ｓ５１８において、画像処理部４３２は、リクエスト制御部４３１からの上記保存指示を受けて、ファイル名設定情報を保存するための処理を実行する。なお、ファイル名設定情報を保存するための処理の詳細は後述する。

Ｓ５１８aにおいて、画像処理部４３２は、ファイル名設定情報保存処理が完了したことを表すステータス情報を含む情報をリクエスト制御部４３１に渡す。Ｓ５１８ｂにおいて、リクエスト制御部４３１は、画像処理部４３２からファイル名設定情報の保存が完了したことを表すステータス情報を含む情報を取得すると、その事実を表すステータス情報を含むレスポンスをＭＦＰ１１０に対して送信する。

Ｓ５１９において、ＭＦＰ１１０は、Ｓ５１８におけるリクエスト制御部４３１からのレスポンスを取得すると、当該レスポンスに含まれる情報に基づいて、ファイルを生成するためのリクエスト（ファイル生成リクエスト）をＭＦＰ連携サーバ１２０に送信する。ＭＦＰ連携サーバ１２０のリクエスト制御部４３１は、ファイル生成リクエストを受信すると、ファイル生成処理を開始するとともに、ファイル生成リクエストを正常に受けたことを表す情報を含むレスポンスをＭＦＰ１１０に返す。ＭＦＰ１１０は、リクエスト制御部４３１からの当該レスポンスを受けると処理を終了し、Ｓ５０４のスキャン設定画面表示に戻る。

Ｓ５２０において、ＭＦＰ連携サーバ１２０では、事前に登録されたスキャン設定からファイルフォーマットの情報を取得し、当該ファイルフォーマットに従って対象画像がファイル化（生成）される。この場合において、自動送信される文書ファイルには、過去のファイル化処理において使用された（すなわち、ユーザによって承認された）文字列であって累積承認回数を満たした文字列がファイル名として自動で設定されることになる。一方、ユーザによる明示の指示に従って送信される場合の文書ファイルには、当該ユーザがファイル名設定画面に提示された文字列に対して適宜修正を行い、最終確認を行ったファイル名が設定されることになる。

Ｓ５２１において、リクエスト制御部４３１は、生成されたファイルをストレージサーバ１３０に送信する。そして、Ｓ５２２において、ストレージサーバ１３０は、ＭＦＰ連携サーバ１２０から送信されたファイルを受信すると、当該ファイルの受信が完了したステータスを表すレスポンスをＭＦＰ連携サーバ１２０に返す。

以上が、画像処理システム全体の処理の大まかな流れである。なお、図５のシーケンス図では、ＭＦＰ１１０がＭＦＰ連携サーバ１２０とやり取りを行う内容となっているが、画像解析の結果取得、ＵＩ画面（例えば、メイン画面６００等）の表示、学習指示等は、クライアントＰＣ（不図示）等で行なう構成でもよい。

＜文字認識処理＞
Ｓ５１０の文字認識処理について、図１１を用いて説明する。図１１は、ＭＦＰ連携サーバ１２０が画像処理部４３２で行う文字認識処理の流れを示すフローチャートである。本フローチャートによる処理は、ＭＦＰ連携サーバ１２０が有するＲＯＭ３１２やＨＤＤ３１４に記憶されたプログラムコードがＲＡＭ３１３に展開され、ＣＰＵ３１１によって実行される。

Ｓ１１０１において、画像処理部４３２は、Ｓ５０８の文字領域解析処理で取得された文字領域に対して文字認識処理を実行する。

続くＳ１１０２、Ｓ１１０３は、文字認識処理の対象になった文字領域から認識された文字毎に行われる処理である。

Ｓ１１０２において、画像処理部４３２は、Ｓ１１０１の文字認識処理の結果として得られた文字の確からしさを表す指標である確信度が、予め設定された閾値より低いか否かを判定する。文字認識処理では、予め様々な文字についての特徴量（パターン）が登録された辞書データを用いて、入力文字と特徴量が一致する文字を辞書データの中から見つけることにより特定の文字を認識する。したがって、特徴量が一致する割合が高いほど、文字認識結果が正しい（特定された文字が正解である可能性が高い）ことになる。そして、文字に掠れや潰れがあるほど、この一致率は低下する傾向にある。そこで、文字認識結果における特徴量の一致率を確信度とし、当該確信度の値が低ければ文字の置き換え候補を作成すべき文字であると判断する。一方、当該確信度の値が高ければ文字の置き換え候補を作成する必要がない文字であると判断する。なお、この確信度は、使用するＯＣＲエンジンに依存する。このため、使用するＯＣＲエンジンから実験的に求めた基準となる確信度の値（例えば、９５％以上といった所定の閾値）を予め設定しておき、Ｓ１１０１で得られた文字認識結果の信頼度と閾値との比較処理によって、信頼度が高いかどうかの判定を行う。例えば、画像処理部４３２は、９５％以上といった閾値を予め設定しておく。そして、Ｓ１１０１で得られた文字列「見積書」における「見」に対する文字認識結果の信頼度（例えば、図８の“ｓｃｏｒｅ”１．０，）と閾値（９５％以上）との比較処理によって、確信度が高いかどうかの判定を行う。この場合、「見」に対する文字認識結果の信頼度は、“ｓｃｏｒｅ”１．０，（すなわち、１００％）であり、閾値（９５％以上）を超えているので、文字認識結果に対する信頼度（すなわち、確信度）が高いと判定される。文字認識結果の確信度が閾値未満の場合、Ｓ１１０３に進む。他方、文字認識結果の確信度が閾値以上の場合、Ｓ１１０４に進む。

Ｓ１１０３において、画像処理部４３２は、文字認識結果の確信度が低いと判定された文字について、置き換え候補文字を作成する。例えば、認識された文字が、数字の「１」であった場合において、文字認識結果の確信度が低い場合は、アルファベットの小文字の「ｌ」や大文字の「Ｉ」などの形状が類似する他の文字を、置き換え候補文字とする。この場合、文字認識処理にて認識されている文字と、その字形が類似する文字については、予め、公知の機械学習機能を用いて学習してあるものとする。

Ｓ１１０４以降の処理は、文字認識処理の対象になった文字領域毎に行われる処理である。

Ｓ１１０４において、画像処理部４３２は、Ｓ１１０３で作成した置き換え候補文字を利用して、文字領域から得られた文字列の修正候補文字列を作成する。例えば、当初に得られた文字列が数字の「１」が混ざった「Ｓａｌｅｓ １ｎｖоｉｃｅ」であった場合、アルファベット大文字の「Ｉ」に変更した「Ｓａｌｅｓ Ｉｎｖоｉｃｅ」のような修正候補文字列が作成されることになる。また、当該数字部分を、アルファベット小文字の「ｌ」に変更した「Ｓａｌｅｓ ｌｎｖоｉｃｅ」のような修正候補文字列が作成されることもある。

Ｓ１１０５において、画像処理部４３２は、Ｓ１１０４にて作成した修正候補文字列ごとにスコアを算出する。その際には、予め保持している単語辞書を利用し、文字の並びが辞書の中に存在する単語と一致する場合に、高いスコアを与える。例えば、「Ｓａｌｅｓ １ｎｖоｉｃｅ」という文字列については、「Ｓａｌｅｓ」は単語辞書に存在する単語と一致するが、「１ｎｖоｉｃｅ」は一致しない。このとき、２単語中１単語のみ、単語辞書に存在する単語と一致するので、スコアは１００×１／２＝５０となる。また、「Ｓａｌｅｓ Ｉｎｖоｉｃｅ」については、「Ｓａｌｅｓ」も「Ｉｎｖоｉｃｅ」も、単語辞書に存在する単語と一致するため、スコアは１００×２／２＝１００となる。

画像処理部４３２が修正候補文字列ごとにスコアを算出する例として、「Ｓａｌｅｓ Ｉｎｖоｉｃｅ」の文字列についてスコアを算出する例を示したが、画像処理部４３２が修正候補文字列ごとにスコアを算出する例はこの例に限られない。例えば、「下丸子 株式会社」の文字列について、「下丸子」の文字列のみが文字認識処理され、「株式会社」の文字列については、全く認識されていない場合、「下丸子」は単語辞書に存在する単語と一致するため、スコアは１００×１／１＝１００となる。そして、後述するＳ１１０６において、「下丸子」の文字列が、文字列認識結果として確定される。しかしながら、このような場合であっても、後述するＳ１２０３又はＳ１２０４の判定で否定的な判定結果となる可能性が高く、更にはユーザが目視で確認するため、「下丸子」の文字列が、自動送信の対象となる可能性は低い。

Ｓ１１０６において、画像処理部４３２は、Ｓ１１０５で算出されたスコアが最も高い修正候補文字列を、最終的な文字列認識結果として確定する。以下、このようにして確定した文字列を「確定文字列」と呼ぶ。

以上が、文字認識処理の内容である。

＜自動送信判定処理＞
Ｓ５１０の文字認識処理に続いて実行される、Ｓ５１１の自動送信判定処理について、図１２を用いて説明する。図１２は、自動送信判定処理の流れを示すフローチャートである。本フローチャートによる処理は、ＭＦＰ連携サーバ１２０が有する記憶手段であるＲＯＭ３１２やＨＤＤ３１４に記憶されたプログラムコードがＲＡＭ３１３に展開され、ＣＰＵ３１１によって実行される。自動送信判定処理の前提として、ストレージ保存済みの文書ファイルのファイル名に使用された上記確定文字列に関する情報（以下、「過去データ」と呼ぶ。）が、後述のファイル名設定情報の保存処理によって、ＭＦＰ連携サーバ１２０のＨＤＤ３１４に保持されているものとする。例えば、ストレージ保存の対象となった文書ファイルのファイル名に確定文字列として抽出された「見積書」が含まれていたとする。この場合、「見積書」の文字列をファイル名として使用することが、ユーザが承認したものと見做して当該確定文字列を「承認文字列」として決定する。そして、確定文字列を承認文字列として決定する度にその回数をカウントし、当該カウント数を累積承認回数として、その承認文字列と紐付けて更新・保持しておく。

Ｓ１２０１において、画像処理部４３２は、当該文字認識処理によって得られた確定文字列のうち、注目する確定文字列（以下、注目確定文字列と呼ぶ。）の情報を取得する。例えば、画像処理部４３２は、ＭＦＰ連携サーバ１２０のＨＤＤ３１４に保存された後述する図８の“ｔｅｘｔ”を参照し、「見積書」と「下丸子株式会社」のうち「見積書」を注目する確定文字列として取得する。

Ｓ１２０２において、画像処理部４３２は、上述の過去データを参照して、注目確定文字列に最も類似する承認文字列の情報を取得する。例えば保存された過去データに、承認文字列として「見積書」の文字列が存在すれば当該「見積書」の文字列が取得されることになる。

Ｓ１２０３において、画像処理部４３２は、Ｓ１２０１で取得した注目確定文字列とＳ１２０２で取得した承認文字列が一致するかどうかのマッチング判定を行う。ここで説明される「一致」とは、一部一致を含まない概念である。判定の結果、注目確定文字列と承認文字列が一致する場合、Ｓ１２０４に進む。他方、注目確定文字列と承認文字列が一致しない場合、Ｓ１２０６に進む。

Ｓ１２０４において、画像処理部４３２は、上述の過去データを参照して、注目確定文字列に一致する承認文字列の累積承認回数が所定の回数以上（一定回数以上）であるか否かを判定する。ここで、所定の回数については、ユーザが、ファイルの誤送信を抑制したい程度に応じて適宜設定すればよい。例えば、ユーザがファイルの自動送信をすることについて誤送信の抑制よりも利便性を重要視している場合は、所定回数をより少ない回数（例えば３回など）設定することが考えられる。一方、ユーザが誤送信を極力抑制したいと考えている場合は、所定回数をより多い回数（例えば１０回など）と設定することが考えられる。判定の結果、承認文字列の累積承認回数が所定回数以上の場合、Ｓ１２０５に進む。他方、累積承認回数が所定回数未満の場合、Ｓ１２０６に進む。

Ｓ１２０５において、画像処理部４３２は、注目確定文字列に関し、自動送信可能であることを示す暫定情報を設定する。この暫定情報としては、例えば自動送信可能であることを２値で表すフラグ（例えば「自動送信可」の場合に“１”を「自動送信不可」の場合に“０”を付与）などが考えられる。

Ｓ１２０６において、画像処理部４３２は、注目確定文字列に関し、自動送信不可能であることを示す暫定情報として、例えば上述のフラグを設定する。

Ｓ１２０７において、画像処理部４３２は、未処理の確定文字列があるかどうかを確認する。未処理の確定文字列が残っている場合には、Ｓ１２０１の処理に戻って次の注目する確定文字列を決定して同様の処理を繰り返す。すべての確定文字列についての処理が完了していれば、Ｓ１２０８に進む。

Ｓ１２０８において、画像処理部４３２は、対象画像に含まれるすべての確定文字列に対し付与された上述の暫定情報に基づいて、解析処理の対象画像について自動送信可能であるかを決定する。例えば、すべての確定文字列に対し「自動送信可」の暫定情報が設定されていれば、当該対象画像を自動送信可能と決定するといった具合である。或いは、「自動送信可」の暫定情報が付与された確定文字列の割合が一定以上であれば自動送信可能と決定してもよい。この決定を行うと、画像処理部４３２は処理を終了する。

以上が、自動送信判定処理の内容である。

＜ファイル名設定情報の保存処理＞
続いて、自動送信不可と判定された場合に実行される、ファイル名設定情報の保存処理（Ｓ５１８）について説明する。図１３は、ＭＦＰ連携サーバ１２０の画像処理部４３２が、ファイル名設定情報の保存処理の流れを示すフローチャートである。本フローチャートによる処理は、ＲＯＭ３１２やＨＤＤ３１４に記憶されたプログラムコードがＲＡＭ３１３に展開され、ＣＰＵ３１１によって実行される。また、本フローチャートによる処理は、ＭＦＰ連携サーバ１２０の画像処理部４３２がリクエスト制御部４３１からファイル名設定情報保存の指示を受けた後に実行される処理である。

Ｓ１３０１において、画像処理部４３２は、リクエスト制御部４３１からファイル名設定情報を取得する。ファイル名設定情報には、Ｓ５１６で述べた通り、ファイル名に使用された確定文字列に加え、対象画像における文字領域や帳票種別等の情報が含まれる。ここで、文字領域と帳票種別の情報はそれぞれ、図８に示したデータ構造における“ｒｅｃｔ”と“ｆｏｒｍＩｄ”に対応する情報である。例えば、文字列が「見積書」である場合、画像処理部４３２は、「見積書」についての文字領域を表す“ｘ：６０，ｙ：２９０，ｗｉｄｔｈ：４８，ｈｅｉｇｈｔ：１５”の情報と、その帳票種別を表す“ａａａａａａａａ－ｆｆｆｆ－４９ａｂ－ａｃｆ８－５５５５８８８８ｅｅｅｅ”の情報が取得される。なお、Ｓ１３０２以降の各ステップは、確定文字列の単位で実行される。

Ｓ１３０２において、画像処理部４３２は、Ｓ１３０１で取得したファイル名設定情報に含まれる確定文字列に対する修正の有無を示す情報に基づいて、確定文字列に対してユーザが修正を行ったか否かを判定する。ユーザがＵＩ画面（例えば、操作部２２０に表示されるソフトキーボード）を操作して、誤認識された確定文字列を正しい文字列に修正することが想定される。また、当該修正には、例えば今回生成されるファイル名に使用する文字領域を、初期ファイル名で使用されている文字領域と異なるものにしたり、区切り文字を追加したり或いは削除したりすることが含まれる。

そして、上記判定は、結果情報に含まれる“ｍｅｔａｄａｔａＡｒｒａｙ”の“ｖａｌｕｅ”の値と、今回のスキャン画像に対するファイル名設定を行った後のファイル名入力欄９０１への入力情報との比較により行う。比較の結果、差異があれば初期ファイル名に対して修正がなされたと判断してＳ１３０３へ進み、一致していれば初期ファイル名に対して変更がなされていないと判断してＳ１３０４に進む。例えば、本来“Ｉｎｖｏｉｃｅ”と文字認識処理されるべき文字列についてアルファベットの大文字の“Ｉ”ではなく、小文字の“ｌ”と誤認識され“ｌｎｖｏｉｃｅ”とファイル名入力欄９０１に表示されていたため、ユーザが修正を行っていたとする。この場合、確定文字列である“Ｉｎｖｏｉｃｅ”の“Ｉ”について修正が行われたことを示す情報がファイル名設定情報には含まれていることから、これに基づいて、確定文字列についての修正があったと判定されることになる。ユーザが文字列を修正していればＳ１３０３へ進み、修正していなければＳ１３０４へ進む。

Ｓ１３０３において、画像処理部４３２は、修正前の文字列（すなわち、文字認識処理において誤認識された文字列）及び修正後の確定文字列を、その文字領域の情報と紐付けて保存する。例えば、修正前の文字列が、アルファベットの小文字の“ｌ”が含まれる“ｌｎｖｏｉｃｅ”であり、修正後の確定文字列が、正しくアルファベットの大文字の“Ｉ”が含まれる“Ｉｎｖｏｉｃｅ”であったとする。この場合、画像処理部４３２は、修正前の“ｌｎｖｏｉｃｅ”と修正後の“Ｉｎｖｏｉｃｅ”とが関連付けられ、その文字領域の情報と共に「過去データ」として記憶部に保存する。

Ｓ１３０４において、画像処理部４３２は、確定文字列をその文字領域の情報と紐付けて保存する。さらに、画像処理部４３２は、当該確定文字列について、承認文字列として登録されているかどうかをチェックし、未登録であれば累積承認回数「１」をカウントし、既登録であれば現在のカウント値をインクリメント（＋１）する。

以上が、ファイル名設定情報の保存処理の内容である。

以上説明したように本実施形態によれば、ファイル化対象画像のＯＣＲ処理の結果が、過去にファイル名等に一定回数以上使用された実績がある場合に、そのファイル名の候補として自動的に設定される。

具体的には、累積承認回数を満たして自動送信されることになった場合は、そのときの確定文字列がファイル名に使用される。

また、累積承認回数を満たさず自動送信されないことになった場合は、そのときの確定文字列を使用した暫定的なファイル名がユーザに提示されることとなる。

＜変形例＞
自動送信の可否を決定するにあたり、類似帳票判定の結果を利用してもよい。例えば、確定文字列と承認文字列とが一致し、且つ確定文字列に係る帳票種別と承認文字列に係る帳票種別とが同一であれば、確定文字列は、より確からしい可能性が高いといえる。そこで、ユーザによって承認された確定文字列を保存する際に、その文字列が記載された帳票の種別を表す情報についても併せて保存するようにする。そして、確定文字列と承認文字列とを比較する場合は、確定文字列の帳票種別と承認文字列の帳票種別とについても比較し、両者が一致する場合にのみ累積承認回数に基づく自動送信可否の判定を行うようにしてもよい。

［実施形態２］
実施形態１においては、過去に承認されたことがない文字列又は承認されたことはあっても、その承認回数が所定の回数より少ない文字列は、自動送信の対象としないことで、誤ったファイル名が設定されたファイルが自動送信されることを抑制した。この場合、仮に文字列を構成する文字の全てについて、文字認識処理された結果の確信度が「１」に近い値（例えば「０．９」以上）であり、且つユーザが修正しなかった文字列についても、所定の回数以上承認されない場合は、自動送信の対象にならない。それにより、文字列の確信度が高いにも関わらず、ユーザに承認の手間を煩わせてしまうという問題があるため、本実施形態２ではその問題を解決する。

ここで、本実施形態２における、自動送信判定処理の詳細について、図１４を用いて説明する。本フローチャートによる処理は、ＲＯＭ３１２やＨＤＤ３１４に記憶されたプログラムコードがＲＡＭ３１３に展開され、ＣＰＵ３１１によって実行される。なお、本実施形態２のシステム構成、及び処理手順は、実施形態１で説明したものと同一であるため、その説明を省略し、異なる箇所のみを説明する。

Ｓ１４０１及びＳ１４０２は、実施形態１の図１２のフローにおけるＳ１２０１及びＳ１２０３と同一であるため、説明を省略する。

Ｓ１４０３では、Ｓ１２０３と同様に、画像処理部４３２は、注目確定文字列と承認文字列が一致するかどうかのマッチング判定を行う。注目確定文字列と承認文字列が一致する場合、Ｓ１４０４に進む。一方、目確定文字列と承認文字列が一致しない場合、Ｓ１４０６に進む。

Ｓ１４０４では、Ｓ１２０４と同様に、画像処理部４３２は、注目確定文字列に一致する承認文字列の累積承認回数が所定の回数以上であるか否かを判定する。累積承認回数が所定の回数以上である場合、Ｓ１４０６に進む。一方、累積承認回数が所定の回数未満である場合、Ｓ１４０５に進む。

Ｓ１４０５において、画像処理部４３２は、注目確定文字列を構成する全ての文字に関して、確信度が予め設定された閾値以上であるか否か判定する。なお、ここでの確信度については、実行済みの図１１のフローにおいて算出済みの確信度を用いればよい。例えば、注目確定文字列が「見積書」であった場合、「見」、「積」、「書」の３つそれぞれの文字に関して、その確信度が予め設定された閾値以上であるか否か判定する。この場合の確信度の閾値については、ユーザが、ファイルの誤送信を抑制したい程度に応じて適宜設定すればよい。例えば、ユーザがファイルの自動送信をすることについて誤送信の抑制よりも利便性を重要視している場合は、確信度の閾値をより小さい値（例えば０．６など）設定することが考えられる。一方、ユーザが誤送信を極力抑制したいと考えている場合は、確信度の閾値をより大きい値（例えば０．９など）と設定することが考えられる。そして、注目確定文字列を構成する全ての文字について確信度が閾値以上であれば、当該注目確定文字列について自動送信可能と判断する。或いは、注目確定文字列を構成する文字のうち確信度が閾値以上と判定された文字の割合が一定以上であれば自動送信可と判断するようにしてもよい。判定の結果、注目確定文字列について自動送信可能と判定された場合はＳ１４０６に進む。他方、注目確定文字列について自動送信不可と判定された場合はＳ１４０７に進む。

Ｓ１４０６では、Ｓ１２０５と同様に、画像処理部４３２は、注目確定文字列に関し、自動送信可能であることを示す暫定情報を設定する。また、確信度が閾値以上である場合、確信度が閾値以上であることを表す情報を別途設定してもよい。確信度が閾値以上であることを表す情報の例として、「∞」が挙げられるが、確信度が閾値以上であることを表す情報の例はこれに限られない。

確信度が閾値以上であることを表す情報を別途設定する場合、累積承認回数に関する情報に代えて、当該情報を設定してもよいし、累積承認回数に関する情報と併せて、当該情報を設定してもよい。

Ｓ１４０７は、図１２のフローにおけるＳ１２０６に対応し、特に異なるところはないので説明を省略する。

Ｓ１４０８及びＳ１４０９についても、図１２のフローにおけるＳ１２０７及びＳ１２０８にそれぞれ対応し、特に異なるところはないので説明を省略する。

以上が、本実施形態２に係る自動送信判定処理の内容である。

以上説明したように本実施形態２によれば、確定文字列の承認回数が所定回数未満の場合であっても、確信度の閾値が所定値以上であれば、自動送信可能であることを示す暫定情報が設定される。これにより、実施形態1と比較して、自動送信の対象となる文書ファイルが増えることになりユーザが承認を行う手間を省くことができる。

［実施形態３］
実施形態１及び実施形態２においては、ある文字列の累積承認回数が所定の回数以上である場合に文書ファイルを自動送信可能と判定していた。ところで、ユーザの中には、図９のファイル名入力欄９０１に表示された文字列を頻繁に修正するユーザもいれば、殆ど修正しないユーザもいる。文字列を頻繁に修正するユーザは、文字列を殆ど修正しないユーザに比べると修正ミスをしてしまうリスクが高く、その結果、誤った文字列が承認されてしまう可能性も高いといえる。そうなると、誤った文字列をファイル名等に使用して自動送信されてしまうことに繋がる。そこで、本実施形態では、ユーザ毎の修正頻度に応じて、ファイルを自動送信するための基準である累積承認回数を変更する。具体的には、文字列を頻繁に修正するユーザについては、当該ユーザによって承認された文字列をファイル名に用いて自動送信するために必要な累積承認回数を増やすようにする。

なお、本実施形態２のシステム構成、及び処理手順は、実施形態１で説明したものと同一であるため、その説明を省略し、異なる箇所のみを説明する。

＜ファイル名設定情報保存処理＞
ここで、本実施形態における、ＭＦＰ連携サーバ１２０が画像処理部４３２で行うファイル名設定情報保存処理の詳細について、図１５を用いて説明する。本フローチャートによる処理は、ＲＯＭ３１２やＨＤＤ３１４に記憶されたプログラムコードがＲＡＭ３１３に展開され、ＣＰＵ３１１によって実行される。以下の説明では、確定文字列の累積修正回数をカウントしたり、確定文字列の修正頻度を算出したりする処理の対象となるユーザを「対象ユーザ」と呼ぶこととする。また、「過去データ」は、当該文書ファイルを作成した対象ユーザ毎に集計されて、記憶手段に保持されているものとする。具体的には、どの文字列を何回修正したかを示す回数の情報、どの文字列を何回修正しなかったかを示す回数の情報、文書ファイルを保存するに際しての確定文字列を修正する頻度の情報が、ユーザ毎に保持されている。

Ｓ１５０１において、画像処理部４３２は、リクエスト制御部４３１からファイル名設定情報を取得する。本実施形態で取得するファイル名設定情報には、ファイル名に使用された文字列やその文字領域といった情報に加え、対象ユーザを特定するユーザＩＤの情報、及び当該対象ユーザによる確定文字列に対する修正の有無に関する情報が含まれる。

Ｓ１５０２において、画像処理部４３２は、対象ユーザについての「過去データ」を取得する。なお、Ｓ１５０３以降の各ステップは、確定文字列の単位で実行される。

Ｓ１５０３において、画像処理部４３２は、確定文字列に対して対象ユーザが修正を行ったか否かを判定する。なお、ここでの判定の詳細については、実施形態１の図１３のフローにおけるＳ１３０２と同一であるため、説明を省略する。対象ユーザが確定文字列を修正した場合、Ｓ１５０４に進む。一方、対象ユーザが確定文字列を修正していない場合、Ｓ１５０８に進む。

対象ユーザが確定文字列を修正した場合、Ｓ１５０４において、画像処理部４３２は、対象ユーザが確定文字列を修正したことを表す情報を取得することに基づいて、当該対象ユーザが確定文字列を修正した回数の累積値（累積修正回数）を更新する。さらに、画像処理部４３２は、当該確定文字列の修正履歴について、登録されているかどうかをチェックし、未登録であれば累積修正回数「１」をカウントし、既登録であれば現在の累積修正回数をインクリメント（＋１）する。Ｓ１５０５において、画像処理部４３２は、確定文字列についての累積修正回数に基づいて、当該確定文字列が対象ユーザによって修正される頻度（以下、「修正頻度」と呼ぶ。）を算出する。Ｓ１５０６において、画像処理部４３２は、算出された修正頻度に基づいて、当該対象ユーザによって修正された確定文字列をファイル名に用いて自動送信するために必要な累積承認回数を算出する。Ｓ１５０７は、図１３のフローにおけるＳ１３０３に対応し、特に異なるところはないので説明を省略する。

対象ユーザが確定文字列を修正していない場合、Ｓ１５０８において、画像処理部４３２は、Ｓ１５０５と同様に、修正頻度を算出する。そして、Ｓ１５０９において、画像処理部４３２は、Ｓ１５０６と同様に、閾値としての累積承認回数を算出する。

Ｓ１５１０において、画像処理部４３２は、対象ユーザ毎に累積承認回数等の情報を保存する。すなわち、ファイル名設定情報として、各確定文字列について新たに算出・設定された累積承認回数と対象ユーザを識別する情報（ユーザＩＤ）とを紐付けて保存する。

以上が、本実施形態に係るファイル名設定情報保存処理の流れである。

＜適用例＞
ここで、対象ユーザが確定文字列を修正した場合におけるＳ１５０４以下の処理について、具体例を用いて説明する。

例えば、過去に実行されたファイル名設定情報保存処理において、ユーザＡが、文字列“Ｉｎｖｏｉｃｅ”を１９回使用し、そのうちの９回修正を行っていたとする。そして、２０回目のファイル名設定情報保存処理において、当該ユーザＡが文字列“Ｉｎｖｏｉｃｅ”を修正したとする。そうすると、ユーザＡに関し、文字列“Ｉｎｖｏｉｃｅ”についての累積修正回数がインクリメントされて、１０回に更新される（Ｓ１５０４）。この場合におけるユーザＡの修正頻度は、例えば以下の式（１）で求めることができる（Ｓ１５０５）。

「累積修正回数／（累積修正回数＋修正しなかった回数）＝修正頻度」 ・・・式（１）
いま、上記式（１）からユーザＡの修正頻度は、（１０回）／（１０回）＋（１０回））＝０．５となる。

そして、上記式（１）によって算出された修正頻度に基づいて、確定文字列“Ｉｎｖｏｉｃｅ”をファイル名に用いて自動送信するために必要な累積承認回数が算出される（Ｓ１５０６）。この場合の算出には、例えば以下の式（２）を用いればよい。

「（修正頻度）×１０＋（予め設定した累積承認回数）＝新たな累積承認回数」・・・式（２）
ここで、上記式（２）における“×１０”は、小数で表される修正頻度を整数にするための定数である。なお、修正頻度が小数点第二位以下まで続いてしまう場合は、小数点第二位以下を切り捨てればよい。

いま、予め設定した累積承認回数が５回であったとする。そうすると、修正頻度が０．５の場合の新たな累積承認回数は、（０．５）×１０＋（５回）＝１０回となる。ここで、上記式（２）に基づいて算出された承認回数が整数とならなかった場合、小数点以下については、切り捨ててよい。なお、上記式（２）から明らかなように、「新たな累積承認回数」は「予め設定した累積承認回数」を下回ることはない。つまり、「予め設定した累積承認回数」は、確定文字列をファイル名に用いて自動送信するために必要となる承認回数の下限値として機能する。なお、ここでは、累積承認回数を増やす場合の変更について説明したが、これに限定されない。例えば、下限値よりも大きな値を「予め設定した累積承認回数」の初期値として設定しておき、文字列を殆ど修正しないユーザについては、当該ユーザによって承認された文字列についての累積承認回数を減らすような変更を行ってもよい。

以上のとおり本実施形態によれば、ユーザの修正頻度に応じた適切な閾値としての累積承認回数を設定することが可能になる。

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

１１０ ＭＦＰ
１２０ ＭＦＰ連携サーバ
１３０ ストレージサーバ
２２０ 操作部
４３１ リクエスト制御部
４３２ 画像処理部
４３３ クラウドストレージアクセス部
４３４ ファイル生成部
４３５ 表示制御部

Claims (11)

1. 文書のスキャン画像に対する文字認識処理の結果を用いて文書ファイルのプロパティを設定するための画像処理装置であって、
   今回生成する文書ファイルに係るスキャン画像に対して文字認識処理を行って文字列を取得する取得手段と、
   前記取得手段が取得した文字列が、過去に生成された文書ファイルに係るスキャン画像に対する文字認識処理において得られた文字列であってユーザが一定回数以上承認した文字列である場合、前記取得手段が取得した文字列を、前記今回生成する文書ファイルのプロパティに使用する文字列として自動で設定する設定手段と、
   を備えたことを特徴とする画像処理装置。
2. 前記設定手段は、今回生成する文書ファイルのためにスキャンされた文書のフォーマットが、過去に生成された文書ファイルのためにスキャンされた文書のフォーマットと同じ場合、前記取得手段が取得した文字列を、前記今回生成する文書ファイルのプロパティに使用する文字列として自動で設定することを特徴とする請求項１に記載の画像処理装置。
3. 前記設定手段は、前記取得手段が取得した文字列が、過去に生成された文書ファイルに係るスキャン画像に対する文字認識処理において得られた文字列であってユーザが一定回数以上承認した文字列でない場合に、前記文字認識処理の確からしさを表す指標である確信度が所定の閾値以上であれば、前記取得手段が取得した文字列を、前記今回生成する文書ファイルのプロパティに使用する文字列として自動で設定することを特徴とする請求項１又は２に記載の画像処理装置。
4. 前記設定手段が自動で設定した文字列をプロパティに使用した文書ファイルを生成する生成手段をさらに備えたことを特徴とする請求項１乃至３のいずれか１項に記載の画像処理装置。
5. 前記生成手段が生成した前記文書ファイルを外部装置に自動送信するための送信手段をさらに備えたことを特徴とする請求項４に記載の画像処理装置。
6. 前記ユーザが前記プロパティを設定するためのＵＩ画面を表示するための表示手段を備えた装置と接続され、
   前記取得手段が取得した文字列がユーザによって一定回数以上承認された文字列でない場合、前記取得手段が取得した前記文字列が前記プロパティの初期文字列として、前記ＵＩ画面において表示される、
   ことを特徴とする請求項１乃至５のいずれか１項に記載の画像処理装置。
7. 前記文書ファイルのプロパティに使用する文字列として前記ユーザに提示された前記取得手段が取得した文字列についての前記ユーザによる修正頻度に基づいて、当該文字列についての前記一定回数を変更する変更手段をさらに備えたことを特徴とする請求項１乃至６のいずれか１項に記載の画像処理装置。
8. 前記プロパティは、前記文書ファイルのファイル名である
   ことを特徴とする請求項１乃至７のいずれか１項に記載の画像処理装置。
9. 請求項１乃至８のいずれか１項に記載の画像処理装置と、
   前記文書ファイルのプロパティに使用する文字列を表示する表示手段を備える装置と、
   前記文書ファイルを受信する受信手段を備えるサーバ装置と、を備えた
   ことを特徴とする画像処理システム。
10. 文書のスキャン画像に対する文字認識処理の結果を用いて文書ファイルのプロパティを設定するための画像処理方法であって、
    今回生成する文書ファイルに係るスキャン画像に対して文字認識処理を行って文字列を取得する取得ステップと、
    前記取得ステップで取得した文字列が、過去に生成された文書ファイルに係るスキャン画像に対する文字認識処理において得られた文字列であってユーザが一定回数以上承認した文字列である場合、前記取得ステップで取得した文字列を、前記今回生成する文書ファイルの
    プロパティに使用する文字列として自動で設定する設定ステップと、
    を備えたことを特徴とする画像処理方法。
11. コンピュータを、請求項１乃至８の何れか一項に記載の画像処理装置として機能させるためのプログラム。

Images