JP7234024B2 - 情報処理装置、情報処理方法及びプログラム - Google Patents

Description

本発明は、スキャン画像のマルチクロップ処理に関する。

従来、スキャナ装置の原稿台上に領収書や、名刺、各種証明書などの原稿を複数枚並べてスキャンし、そのスキャン画像に対して原稿認識処理を行い、認識した原稿の画像をスキャン画像から切り出すマルチクロップ処理がある。特許文献１には、原稿のエッジが上手く抽出できない場合でも、原稿内容に対応するオブジェクトを特定して原稿領域を判断することで、原稿領域を適切に決定する手法が開示されている。

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

上記特許文献１の手法では、オブジェクト間の距離を元に原稿領域を判断する。そのため、原稿台に置かれた原稿同士が十分に離間しておらず、オブジェクト間の距離が小さい場合には、複数の原稿それぞれについて原稿領域を正確に認識することが困難な場合がある。そして、検知された１つの原稿領域の中に複数の原稿分の画像領域が含まれていると、ユーザは、原稿台上の原稿を配置し直すなどして、複数の原稿それぞれについて原稿単位の原稿領域が得られるようにスキャンをやり直す必要があった。

本発明は、上記課題に対応するべく、マルチクロップ処理時の原稿認識処理における原稿の認識状態をユーザが容易に修正できるようにすることを目的とする。

本開示に係る装置は、ユーザに対して情報を提示し、ユーザによる入力操作を受け付けるユーザインタフェースを備える装置であって、複数の原稿をまとめてスキャンして得られたスキャン画像に対する原稿認識処理の結果を取得する取得手段と、前記取得手段で取得した前記結果を前記スキャン画像に重ねて表示したプレビュー画面を前記ユーザインタフェースに表示する表示制御手段と、を有し、前記表示制御手段は、前記結果に含まれる１又は複数の原稿に対応する原稿領域のうち一定の条件を満たす原稿領域について、分割することをユーザが指示するための分割ボタンを前記プレビュー画面に表示する、ことを特徴とする。

本開示の技術によれば、マルチクロップ処理時の原稿認識処理における原稿の認識状態を、ユーザは容易に修正することができる。これにより、ユーザは再スキャンを行う手間を省くことができる。

画像処理システムの全体構成を示す図 ＭＦＰのハードウェア構成を示すブロック図 ＭＦＰ連携サーバ及び経費精算サーバのハードウェア構成を示すブロック図 画像処理システムのソフトウェア構成を示すブロック図 クラウドサービスによって経費精算を行う際の装置間の処理の流れを示すシーケンス図 メイン画面の一例を示す図 ログイン画面の一例を示す図 代理申請対象者リストの一例を示す図 申請者設定画面の一例を示す図 スキャン設定画面の一例を示す図 複数の領収書をスキャンする様子を示す図であり、（ａ）は原稿台に領収書を裏返して載置した状態を示す図、（ｂ）はそれを原稿台の内部から見た図 （ａ）はリクエストＩＤの一例を示す図、（ｂ）は処理中を表すレスポンスの一例を示す図、（ｃ）は処理完了を表すレスポンスの一例を示す図 （ａ）～（ｃ）は、実施形態１に係るプレビュー画面の一例を示す図 （ａ）は分割リクエストの一例を示す図、（ｂ）は分割リクエストに対するレスポンスの一例を示す図、（ｃ）及び（ｄ）は登録リクエストの一例を示す図 原稿認識処理の詳細を示すフローチャート （ａ）はスキャン画像の一例を示す図、（ｂ）はスキャン画像に対してエッジ抽出処理を行った結果を示す図、（ｃ）はエッジ抽出画像において特定された原稿領域を示す図 （ａ）～（ｅ）は、オブジェクト検出処理に基づく原稿領域の検知を説明する図 ＭＦＰでの経費精算処理の流れを示すフローチャート （ａ）～（ｃ）は、実施形態２に係るプレビュー画面の一例を示す図 （ａ）は分割判定リクエストの一例を示す図、（ｂ）は分割判定リクエストに対するレスポンスの一例を示す図 実施形態３に係るプレビュー画面の一例を示す図

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

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

ＭＦＰ１１０は、スキャン機能を有する情報処理装置の一例である。ＭＦＰ１１０は、スキャン機能に加え印刷機能やＢＯＸ保存機能といった複数の機能を有する複合機である。サーバ装置１２０及び１３０は、共にクラウドサービスを提供する情報処理装置の一例である。本実施形態のサーバ装置１２０は、ＭＦＰ１１０から受け取ったスキャン画像データに対しマルチクロップ処理を含む画像解析を行ったり、別のサービスを提供するサーバ装置１３０に対しＭＦＰ１１０からのリクエストを転送したりするクラウドサービスを提供する。以下、サーバ装置１２０が提供するクラウドサービスを「ＭＦＰ連携サービス」と呼ぶこととする。サーバ装置１３０は、経費精算を効率的に行うためのクラウドサービス（以下、「経費精算サービス」と呼ぶ。）を提供する。経費精算サービスでは、領収書の画像と当該領収書の日付等の付加情報（メタデータ）を関連付けて保存・管理したり、領収書を受領した本人以外がその電子化作業を行う場合に、当該作業を行う者（代理申請者）を設定したりすることができる。以下、ＭＦＰ連携サービスを提供するサーバ装置１２０を「ＭＦＰ連携サーバ」と呼び、経費精算サービスを提供するサーバ装置１３０を「経費精算サーバ」と呼ぶこととする。

図１に示す画像処理システム１００の構成は一例であって、これに限定されない。例えば、ＭＦＰ連携サーバ１２０の機能をＭＦＰ１１０が兼ね備えていてもよい。また、ＭＦＰ連携サーバ１２０はインターネット上ではなくＬＡＮ（Local Area Network）経由でＭＦＰ１１０と接続されていてもよい。また、本実施形態では、電子化作業の対象文書として領収書を例に説明を行うが、対象文書は領収書に限定されるものではない。

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

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

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

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

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

表示制御部４２１は、操作部２２０のタッチパネル機能を有する液晶表示部に、ユーザに対し必要な情報を提示し、ユーザによる各種操作を受け付けるユーザインタフェース用画面（ＵＩ画面）を表示する。ユーザによる各種操作には、例えば、外部装置であるＭＦＰ連携サーバ１２０へアクセスするためのログイン認証情報の入力、代理申請者が領収書の電子化作業を行う場合の代理申請対象者の選択、スキャン設定、スキャンの開始指示、メタデータの入力などがある。本実施形態における代表的なＵＩ画面としては、ＭＦＰ連携サーバ１２０から受け取った原稿認識処理結果に基づくプレビュー画面がある。ユーザは、操作部２２０に表示されたプレビュー画面にて、原稿認識処理によって検知された１又は複数の原稿に対応する原稿領域について、分割や結合といった修正指示を行うことができる。

スキャン制御部４２２は、ＵＩ画面でなされたユーザ操作（例えば「スキャン開始」ボタンの押下）に応じて、スキャン設定の情報と共にスキャン実行部４１１に対しスキャン処理の実行を指示する。スキャン実行部４１１は、スキャン制御部４２２からのスキャン処理の実行指示に従い、スキャナＩ／Ｆ２１７を介してスキャナ部２４０に原稿の読み取り動作を実行させ、スキャン画像データを生成する。生成したスキャン画像データは、スキャン画像管理部４１２によってＨＤＤ２１４に保存される。この際、保存されたスキャン画像データを一意に示すスキャン画像識別子の情報が、スキャン制御部４２２へ通知される。

連携サービスリクエスト部４２３は、ＭＦＰ連携サーバ１２０に対して各種処理のリクエストを行ったり、そのレスポンスを受け取ったりする。各種処理には、例えば、ログイン認証、代理で経費精算できる代理申請対象者リストの取得、複数の領収書をスキャンして得られたスキャン画像データに対するマルチクロップ処理の実行、メタデータ項目情報の取得、メタデータの設定などが含まれる。ＭＦＰ連携サーバ１２０とのやり取りには例えばＲＥＳＴやＳＯＡＰなどの通信プロトコルが用いられる。

画像処理部４２４は、複数の領収書をスキャンして得られたスキャン画像データに対し所定の画像処理を行って、表示制御部４２１が表示するＵＩ画面で用いられる画像を生成する。

≪サーバ装置のソフトウェア構成≫
まず、ＭＦＰ連携サーバ１２０のソフトウェア構成について説明する。ＭＦＰ連携サーバ１２０は、リクエスト制御部４３１、画像処理部４３２、経費精算リクエスト部４３３、データ管理部４３４、表示制御部４３５を有する。リクエスト制御部４３１は、外部装置からのリクエストを受信できる状態で待機しており、受信したリクエスト内容に応じて、画像処理部４３２、経費精算リクエスト部４３３、データ管理部４３４に対し所定の処理の実行を指示する。画像処理部４３２は、ＭＦＰ１１０から送られてくるスキャン画像データに対して、マルチクロップ処理やＯＣＲ処理といった画像解析処理を行う。経費精算リクエスト部４３３は、経費精算サーバ１３０に対して経費精算サービスに関する各種処理のリクエストを行ったり、そのレスポンスを受け取ったりする。各種処理には例えば、代理申請対象者や経費タイプの一覧取得、マルチクロップ処理によって得られる個々の領収書に対応する画像の登録や各画像に対応するメタデータの設定などが含まれる。データ管理部４３４は、サーバ装置１２０で管理するユーザ情報や各種設定データ等を保持・管理する。表示制御部４３５は、インターネット経由で接続されたＰＣやモバイル端末（いずれも不図示）上で動作しているウェブブラウザからのリクエストを受けて、画面表示に必要な画面構成情報（ＨＴＭＬ、ＣＳＳ等）を返す。ユーザは、ウェブブラウザで表示される画面経由で、登録されているユーザ情報を確認したり、スキャン設定を変更したりできる。

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

＜画像処理システム全体の処理の流れ＞
図５は、ＭＦＰ１１０で領収書をスキャンし、クラウドサービスによって経費精算を行う際の装置間の処理の流れを示すシーケンス図である。図６はＭＦＰ１１０の起動時に表示されるメインメニューのＵＩ画面（以下、「メイン画面」と表記）の一例を示す図である。経費精算サービスの利用に必要な専用のアプリケーションをＭＦＰ１１０にインストールすることで、メイン画面６００上に「経費精算」ボタン６０１が表示されるようになる。そして、ユーザがメイン画面６００内に表示されたメニューボタンの中から「経費精算」ボタン６０１を押下すると、図５のシーケンス図で示される一連の処理が開始する。以下、図５のシーケンス図に沿って、装置間のやり取りを時系列に説明する。なお、以下の説明において記号「Ｓ」はステップを表す。

ＭＦＰ１１０は、ＭＦＰ連携サーバ１２０にアクセスするためのログイン認証の情報を入力するＵＩ画面（以下、「ログイン画面」と表記）を操作部２２０に表示する（Ｓ５０１）。図７にログイン画面の一例を示す。ユーザが、予め登録されているユーザＩＤとパスワードを、ログイン画面７００上の入力欄７０２及び７０３にそれぞれ入力し「ログイン」ボタン７０１を押下すると、ログイン認証のリクエストがＭＦＰ連携サーバ１２０に送信される（Ｓ５０２）。

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

ログインが完了すると、ＭＦＰ１１０は、代理申請対象者リストの取得リクエストをログインユーザのアクセストークンと共にＭＦＰ連携サーバ１２０に送信する（Ｓ５０４）。代理申請対象者リストとは、経費精算サービスにおいて本人以外の者が領収書の電子化作業を行う場合（代理申請）における、ログインユーザが代理申請者となり得る対象者を規定した名簿情報である。代理申請対象者リストには、例えばログインユーザが所属する部署の同僚など、同一のＭＦＰ１１０を使用する環境にある、自身と一定の関係にある他のユーザが含まれ、例えば管理者等によって予め作成される。代理申請対象者リストの取得リクエストを受信したＭＦＰ連携サーバ１２０は、アクセストークンで特定されるログインユーザの代理申請対象者リストの取得リクエストを、経費精算サーバ１３０に送信する（Ｓ５０５）。代理申請対象者リストの取得リクエストを受けた経費精算サーバ１３０は、ログインユーザについての代理申請対象者リストを読み出してＭＦＰ連携サーバ１２０に返す。そして、ＭＦＰ連携サーバ１２０は、経費精算サーバ１３０から受け取った代理申請者リストをＭＦＰ１１０に送信する。これにより、図８に示すような、ログインユーザが代理申請者となり得る対象者の“UserID”と“UserName”の一覧情報が、ＭＦＰ１１０で取得される。なお、経費精算サーバ１３０で保持している代理申請対象者リストをそのままＭＦＰ１１０に送信してもよいし、フォーマットの全部又は一部を変更して送信してもよい。

代理申請対象者リストを受信したＭＦＰ１１０は、申請者を設定するためのＵＩ画面（以下、「申請者設定画面」と表記）を操作部２２０に表示する（Ｓ５０６）。図９に、申請者設定画面の一例を示す。申請者設定画面９００の選択欄９０２には、代理申請対象者リストに含まれていたユーザ名に、ログインユーザ自身のユーザ名を加えた一覧が選択候補としてプルダウン表示される。ログインユーザは、本人として領収書の電子化作業を行う場合は自身のユーザ名を、代理申請者として第三者の領収書の電子化作業を行う場合は代理申請対象者のユーザ名を選択して、「次へ」ボタン９０１を押下する。

「次へ」ボタン９０１が押下されると、スキャン設定用のＵＩ画面（以下、「スキャン設定画面」と表記）が操作部２２０に表示される（Ｓ５０７）。図１０にスキャン設定画面の一例を示す。スキャン設定画面１０００には、「スキャン開始」ボタン１００１、カラー設定欄１００２、解像度設定欄１００３が存在する。「スキャン開始」ボタン１００１は、原稿台にセットした原稿（本実施形態では、複数の領収書）に対するスキャン処理の開始を指示するためのボタンである。カラー設定欄１００２では、スキャン時のカラーモードを設定する。例えばフルカラーやモノクロといった選択肢の中から指定できるようになっている。解像度設定欄１００３では、スキャン時の解像度を設定する。例えば６００ｄｐｉや１２００ｄｐｉといった選択肢の中から指定できるようになっている。なお、カラーモードと解像度は設定項目の一例であって、これらすべてが存在しなくてもよいし、これら以外の設定項目が存在してもよい。また、カラーモードや解像度に関する選択肢を、経費精算サービスの要求する設定値のみに限定したりしてもよい。ログインユーザは、このようなスキャン設定画面１０００を介してスキャン処理についての詳細な条件設定を行なう。スキャン設定を終えたログインユーザが、ＭＦＰ１１０の原稿台にスキャン対象の領収書をセットし、「スキャン開始」ボタン１００１を押下するとスキャンが実行される（Ｓ５０８）。図１１は、３枚の領有書をスキャンする様子を示す図であり（ａ）は読み取り対象となる表面を下（フェイスダウン）にして原稿台上に各領収書が置かれている状態を示し、同（ｂ）はそれを原稿台の内側から見た状態を示している。このようにして複数の領収書が同時にスキャンされる。スキャンの完了後、ＭＦＰ１１０は、スキャンによって得られた画像データを、その解析リクエストと共にＭＦＰ連携サーバ１２０に送信する（Ｓ５０９）。

スキャン画像の解析リクエストを受けたＭＦＰ連携サーバ１２０では、リクエスト制御部４３１が画像処理部４３２に対し、解析処理の実行を指示する（Ｓ５１０）。その際、リクエスト制御部４３１は、受信した解析リクエストを一意に特定可能なリクエストＩＤをＭＦＰ１１０に返す。図１２（ａ）にリクエストＩＤの一例を示す。そして、解析処理の実行指示を受けた画像処理部４３２は、スキャン画像に対する解析処理として、マルチクロップ処理の一部である原稿認識処理を実行する（Ｓ５１１）。本実施形態の原稿認識処理では、２種類の手法をそれぞれ用いて、原稿台に置かれた原稿を検知する。２種類の手法とは、エッジ抽出処理に基づく手法とオブジェクト検出処理に基づく手法であり、本実施形態の場合、エッジ抽出処理に基づく手法にて検知される原稿領域とオブジェクト検出処理に基づく手法にて検知される原稿領域とは、排他的な関係にある。以下、詳しく説明する。

本実施形態の原稿認識処理では、最初にエッジ抽出処理に基づく手法による原稿検知を行って、次にオブジェクト検出処理に基づく手法による原稿検知を行う。エッジ抽出処理は、隣り合う画素同士の輝度差を用いて、原稿の端に相当する画素部分を特定する処理である。一般的に、原稿台カバー（圧板）のスキャンされる側の面は白色であることから、紙の厚さ等によっては、原稿台カバーを被せてスキャンを行うと、領収書等の端がスキャン画像に表れないことがある。これに対しては、スキャン時に黒い紙を領収書等のスキャン対象の原稿の上に被せてスキャンしたり、原稿台カバーを開けてスキャンを実行したりすることで原稿の端がスキャン画像上で認識されるようにする対策もある。しかしながら、黒い紙を被せる場合は、ユーザが黒い紙を用意した上でスキャンする度に毎回黒い紙を乗せる必要があり手間である。また、原稿台カバーを開けてスキャンする場合は、領収書が折れ曲がっていたり、湾曲していたりするとその内容自体が鮮明に見えなくなったりする虞がある。そこで、本実施形態では、エッジ抽出処理でその端が特定できなかった原稿を、オブジェクト検出処理によって検知する。つまり、エッジ抽出処理にて検知された原稿領域についてはそのまま維持し、エッジ抽出処理では原稿領域が検知されなかった残りの領域の中から、オブジェクト検出処理によって原稿領域を検知する。こうすることで、トータルでの検知精度が向上する。オブジェクト検出処理では、まず、スキャン画像を一定の閾値で二値化し、得られた二値画像において隣接する黒画素の集合（黒画素塊）を囲む矩形のサイズが一定以上の領域をオブジェクトとして特定する。そして、各オブジェクトの並びやオブジェクト間の距離に基づき、略同等の傾きを持ち、かつ、一定の距離以内にあるオブジェクトのまとまり（オブジェクト群）を包含する矩形領域を、一つの原稿領域と判断する。さらに本実施形態の原稿認識処理では、オブジェクト検出処理によって検知した原稿領域が複数の原稿に対応する画像領域を含んでいる可能性（＝分割の可能性）を判断し、分割する場合の予測位置の決定も行い、決定された分割予測位置の情報をユーザに提示する。本実施形態の原稿認識処理の詳細については後述する。原稿認識処理の結果は、その処理対象となったスキャン画像と共に、リクエスト制御部４３１で管理される。この際、原稿認識処理によって検知された原稿領域に対し、それぞれを一意に識別可能な文字列であるImageIDを紐付けて保存する。このImageIDは、例えば文字列の一部に通し番号を付けるなどして同じ文字列が重複して使用されないようにする必要がある。これに関しては、既に生成済みのImageIDを検索し存在しない文字列を割り当てる方法や、ＵＵＩＤを生成して付与する方法などがある。

上記解析処理が行われている間、ＭＦＰ１１０は、上述のリクエストＩＤを使用して、ＭＦＰ連携サーバ１２０に対して定期的（例えば３秒毎など）に処理状況の問合せを行う（Ｓ５１２～Ｓ５１２’）。この問合せは、ＭＦＰ連携サーバ１２０からの解析処理の完了レスポンス（Ｓ５１３）が取得できるまで繰り返し実行される。ＭＦＰ連携サーバ１２０は、処理状況の問合せを受けると、リクエストＩＤに対応する解析処理の進行状況を確認する。そして、完了していない場合は処理中を表す“processing”のレスポンス（図１２（ｂ）を参照）を返し、完了していた場合は完了を表す“completed”のレスポンス（図１２（ｃ）を参照）を返す。なお、処理が失敗した場合には“failed”など、処理中と完了以外を表すステータス情報のレスポンスが返ることもある。図１２（ｃ）に示すとおり、解析処理完了時のレスポンスには、ステータス情報に加えて、スキャン画像の解析結果としての原稿認識処理の結果情報を含む。図１２（ｃ）には、前述の図１１で示した例とは異なる４枚の領収書をスキャンして得られたスキャン画像に対する原稿認識処理の結果情報が示されている。まず、“Status”には、完了を表す内容の文字列（completed）が入る。“Images”には、検知された原稿領域に対応する数分の、“ImageID”、“Accuracy”、“Points”の３つの情報が格納される。“ImageID”は、検知された各原稿領域を識別するＩＤ情報である。このImageIDを指定して取得リクエストをＭＦＰ連携サーバ１２０に送信することで、所望の原稿領域の画像を取得できる。“Accuracy”は、原稿を正しく検知できているかの度合いを、0.0～1.0の少数値で表す精度情報である。本実施形態の精度情報は、その値が大きいほど正確に検知できていることを示し、エッジ抽出処理によって検知した場合は1.0、オブジェクト検出処理によって検知した場合は0.5とする。“Points”は、スキャン画像のどの位置に原稿領域があったかを示す座標情報である。座標情報は、スキャン画像の左上隅を原点（ｘ，y）＝（0，0）として、先頭から順に、各原稿領域の左上隅、右上隅、右下隅、左下隅の各位置を示している。“DivideCandidate”は、検知した１つの原稿領域内に複数の原稿に対応する画像領域が含まれる可能性がある場合に、当該原稿領域を、原稿単位の画像領域に分割するための情報である。“DivideCandidate”には、“DivideID”、“Point1”、“Point2”の３つの情報が含まれる。まず、“DivideID”は、分割が見込まれる原稿領域を識別するＩＤ情報である。“Point1”と“Point2”は、その予測される分割位置を示す始点と終点をそれぞれ示す座標情報である。

解析処理の完了レスポンスを受信した後、ＭＦＰ１１０は、原稿認識処理による原稿の認識結果を示すプレビュー画面を表示する（Ｓ５１４）。図１３（ａ）及び（ｂ）に、複数の領収書に相当する画像領域が１つの原稿領域として検知された場合に表示されるプレビュー画面の一例を示す。図１３（ａ）は縦に並べて置いた２枚の領収書に相当する画像領域を１つの原稿領域として検知した場合、図１３（ｂ）は横に並べて置いた２枚の領収書に相当する画像領域を１つの原稿領域として検知した場合である。ユーザは、原稿台に置いた各原稿が正しく認識されているかを、このようなプレビュー画面にて確認する。１つの原稿領域に複数の原稿（ここでは領収書）の画像領域が含まれていて、原稿領域を分割する修正が必要な場合は、ユーザは、プレビュー画面にて分割を指示する。ユーザの分割指示に応じて、プレビュー画面は更新される。ユーザ指示に基づくプレビュー画面の更新などの詳細については後述する。更新後のプレビュー画面にて原稿の認識状況を確認したユーザが、図１３（ａ）及び（ｂ）に示すプレビュー画面内の「送信」ボタン１３０５を押下すると、ＭＦＰ１１０は、各原稿に対応した画像の登録リクエストをＭＦＰ連携サーバ１２０に送信する。この際、上述の分割指示がなされていた場合は、登録リクエストに先立って、１つの原稿領域を複数の原稿領域に分割するための分割リクエストが送信される（Ｓ５１５）。図１４（ａ）は、分割リクエストの一例、同（ｂ）は分割リクエストに対するレスポンスの一例を示す。図１４（ａ）に示すとおり、分割リクエストには、上述の完了レスポンスに含まれていた“DivideID”の情報が入っている。

分割リクエストを受け取ったＭＦＰ連携サーバ１２０では、リクエスト制御部４３１が、分割リクエスト内のDivideIDと紐付いた分割位置情報から分割後の原稿単位の画像領域の座標を計算する。そして、リクエスト制御部４３１は、分割後の原稿領域それぞれに対して新たにImageIDを付与し、当該ImageIDの情報を含んだレスポンスをＭＦＰ１１０に返す。例えば、原稿認識処理の結果として前述の図１２（ｃ）に示す完了レスポンスが返されていた場合の分割リクエストに対しては、以下のような処理がなされる。

まず、ImageID＝image0003の原稿領域の座標情報とDivideID＝image0003-Divide0001の分割位置を示す座標情報を用いて、image0003で特定される原稿領域が、２つの原稿領域に分割される。いま、座標が“3011,621,3893,623,3890,1542,3010,1537”の原稿領域と、座標が“3010,1537,3890,1542,3887,2543,3009,2539”の原稿領域とに分割されることになる。そして、分割後の２つの新たな原稿領域それぞれに対し、新たに“image0004”と“image0005”のImageIDを生成して、それぞれのImageIDに対応付けて分割後の座標情報を保存する。そして、生成した分割後の各原稿領域に対応するImageID（ここではimage0004とimage0005）の情報が格納されたレスポンスが、ＭＦＰ１１０に返される。なお、ユーザが分割指示を行っていない場合は、分割リクエストに基づくこれらの処理は実行されない。

分割後の新たなImageIDの情報を含むレスポンスを受け取ったＭＦＰ１１０は、続けて、原稿画像の登録リクエストをＭＦＰ連携サーバ１２０に送信する（Ｓ５１６）。図１４（ｃ）に、登録リクエストの一例を示す。この登録リクエストには、登録対象の各原稿領域に対応するimageIDの情報が格納される。図１４（ｃ）の例では、分割後の４つの原稿領域に対応した４つのImageID（image0001、image0002、image0004、image0005）が含まれている。仮に、ユーザが分割指示を行うことなく「送信」ボタン１３０５を押下していた場合は、３つのImageID（image0001、image0002、image0003）を含む登録リクエストが送信されることになる。

登録リクエストを受信したＭＦＰ連携サーバ１２０では、リクエスト制御部４３１が、当該登録リクエストに含まれているImageIDに対応する、スキャン画像と原稿領域の情報を取得して、画像処理部４３２に対し、原稿領域の切り出しを指示する（Ｓ５１７）。そして、当該指示を受けた画像処理部４３２は、スキャン画像と原稿領域の情報に基づいて、原稿毎の画像の切り出し処理を実行する（Ｓ５１８）。これにより、原稿台に載置された複数の原稿それぞれに対応する原稿単位の画像（以下、「クロップ画像」と呼ぶ。）が生成される。切り出し処理の際、画像処理部４３２では、座標情報を元にスキャン画像から原稿単位の画像領域を切り出した後、各原稿の辺が水平または垂直状態になるように傾きを補正する処理も併せて行なわれる。さらに、ＯＣＲ処理を実行して、原稿内容の方向を検知して原稿の文字が正しい向きになるように方向を修正する回転処理も必要に応じて行われる。そして、リクエスト制御部４３１は、上述のようにして得られたクロップ画像のデータと共に登録リクエストを経費精算サーバ１３０に送信する（Ｓ５１９）。こうして、スキャン画像から切り出された領収書単位の画像が、経費精算サーバ１３０に登録される。そして、登録完了のレスポンスがＭＦＰ１１０に返されて処理が終了する。

なお、上述の説明では、Ｓ５１５の分割リクエストに対しては分割後の各原稿領域に対応するImageIDの情報が格納されたレスポンスを返すのみで、実際の切り出し処理は登録リクエスト後に行っている。これは、各原稿に対応する画像が必要になるのは登録段階であるためであるが、分割リクエストの時点で切り出し処理まで行っても構わない。この場合は、切り出し処理によって得られたクロップ画像をＭＦＰ連携サーバ１２０にて保持しておき、登録リクエストを受け取った段階で保持しておいたクロップ画像を読み出して、その登録処理を経費精算サーバ１３０に依頼するようにすればよい。

＜原稿認識処理＞
続いて、ＭＦＰ連携サーバ１２０の画像処理部４３２が実行する、マルチクロップ処理の一部としての原稿認識処理について詳しく説明する。図１５は、本実施形態に係る、原稿認識処理の詳細を示すフローチャートである。図１５のフローに示す一連の処理は、ＭＦＰ連携サーバ１２０の制御部３１０において、ＣＰＵ３１１がＨＤＤ３１４に記憶された制御プログラムを実行することにより実現され、前述の解析リクエスト（Ｓ５０９）を受信することで開始される。なお、各処理の冒頭における記号「Ｓ」はステップを意味する。

Ｓ１５０１では、入力スキャン画像に対してエッジ抽出処理が実行される。エッジ抽出処理には、例えばCanny法などの公知の方法を用いればよい。ここで、具体例を用いて説明する。図１６（ａ）は、処理対象として入力されたスキャン画像を示す。スキャン画像１６００は、前述の図１３（ａ）のプレビュー画面１３００のプレビューエリア１３０１に示されている例と同じであり、原稿台に載置された４枚の領収書をスキャンして得られた画像である。いま、スキャン画像１６００において、左側の２枚の領収書については原稿の端が鮮明に見えているが、右側の２枚の領収書については原稿の端がほとんど現れていない状態である。図１６（ｂ）は、スキャン画像１６００に対してエッジ抽出処理を行った結果を示している。図１６（ｂ）のエッジ抽出処理後の画像（エッジ抽出画像）１６０１では、左側の２枚の領収書の端が特定できているが、右側の２枚の領収書についてはその端が認識されていないのが分かる。

Ｓ１５０２では、エッジ抽出画像に基づき原稿領域が特定される。具体的には、Hough変換等を行って、抽出されたエッジのうち直線成分を判断し、その直線が作る角度が直角に近い矩形領域を見つけ出し、その縦及び横の長さが一定量以上の矩形領域を原稿領域と特定する。この場合において、“一定量”に関しては、例えば、縦横両方とも４ｃｍ以上など、スキャン対象の原稿のサイズを考慮して決定すればよい。図１６（ｃ）は、図１６（ｂ）のエッジ抽出画像１６０１において特定された原稿領域を示している。この例では、スキャン画像１６００における左側の２枚の領収書に対応する２つの原稿領域が特定される。

Ｓ１５０３では、入力スキャン画像に対してオブジェクト検出処理が実行される。図１７（ａ）は、前述の図１６（ａ）のスキャン画像１６００に対してオブジェクト検出処理を行った結果を示している。４枚の領収書のそれぞれに記載された文字列部分がオブジェクトとして検出されているのが分かる。

Ｓ１５０４では、Ｓ１５０３で検出したオブジェクトのうち、Ｓ１５０２で特定した原稿領域と一部でも重なる領域を持つオブジェクトを除外する処理が実行される。図１７（ｂ）は、Ｓ１５０２で特定した原稿領域とＳ１５０３で検出したオブジェクトの両方を重ねて示した図である。本ステップの除外処理によって、既に原稿領域として特定された左側の２枚の領収書の文字列に相当するオブジェクトが削除され、右側の２枚の領収書の文字列に相当するオブジェクトだけが残っているのが分かる。

Ｓ１５０５では、除外後に残っているオブジェクト（以下、「残存オブジェクト」と呼ぶ。）を対象としてグループ化を行って、１つのまとまりのあるオブジェクト群を包含する矩形が設定される。例えば、残存オブジェクトそれぞれが持つ角度の最頻値を求め、求めた最頻値の角度に基づき、まとまりのあるオブジェクト群に外接する矩形を設定する。或いは、オブジェクト群を包含する外接矩形の上下左右に所定のマージンを持たせた一回り大きな矩形を設定する。領収書や名刺など一般的な原稿には余白領域が存在している。そのため、オブジェクト群の外縁ぎりぎりの外接矩形で切り出してしまうと、原稿の端部が切れてしまう虞があるため、矩形を設定する際にはマージンを持たせるのが望ましい。図１７（ｄ）は、図１７（ｃ）に示した残存オブジェクトを包含するように設定された矩形を示している。なお、残存オブジェクトの中に、それぞれ異なる角度を持つオブジェクト群が存在した場合には、同程度の角度を持つオブジェクトをグループ化し、得られたグループ毎に矩形を設定すればよい。また、矩形を設定する際の条件として、オブジェクトの数に閾値を設け、オブジェクト数が閾値未満の場合には矩形を設定しない（原稿領域として扱わない）ようにしてもよい。さらには、矩形の面積についても閾値を設け、閾値未満のサイズとなる場合には矩形を設定しないようにしてもよい。

Ｓ１５０６では、Ｓ１５０５で設定した矩形について（複数の矩形を設定した場合はそれぞれの矩形毎に）、その中に存在する隣接するオブジェクト同士の間隔が、一定以上あるかどうかが判定される。この判定処理によって、オブジェクト検出処理によって検知された１つの原稿領域の中に、複数の原稿に対応する画像領域が含まれているかどうかが判断される。具体的には、まず、設定された矩形の横の辺に平行で同じ長さの直線を原稿領域の縦方向について、縦の辺に平行で同じ長さの直線を原稿領域の横方向についてそれぞれ確認し、「オブジェクトが存在しないライン」を見つける。この際、矩形の端から最初のオブジェクトが存在するまでの間は原稿の余白に相当する領域なので、「オブジェクトが存在しないライン」として扱わない。そして、「オブジェクトが存在しないライン」が見つかった場合、それが何画素分連続するかを調べ、所定の画素数以上連続していれば、隣り合うオブジェクト同士の間隔が一定以上あると判定する。このとき、一定以上の間隔に相当する所定の画素数は、例えば３ｃｍなど固定値に相当する画素数としてもよいし、オブジェクトのサイズの平均値等を元に決定してもよい。前述の図１７（ｄ）の例では、縦の辺に平行なラインを横方向に確認した場合は、「オブジェクトが存在しないライン」は存在しない。横の辺に平行なラインを縦方向に確認した場合は、「オブジェクトが存在しないライン」が１７か所存在する。なお、オブジェクトの角度が斜めであった場合は、その角度に合わせた方向で「オブジェクトの存在しないライン」を確認する。このように、設定された矩形領域内のオブジェクトが存在しないラインと直交する方向におけるオブジェクト同士の間隔が一定以上あるかどうかが判定される。判定の結果、隣り合うオブジェクト同士の間隔が一定以上ある場合（すなわち、検知された１つの原稿領域の中に、複数の原稿に対応する画像領域が含まれていると判断される場合）は、Ｓ１５０７に進む。一方、間隔が一定以上ない場合は、本処理を終える。

Ｓ１５０７では、Ｓ１５０５で設定された矩形によって特定される原稿領域についての分割予測位置が決定される。具体的には、所定画素数以上の連続する「オブジェクトが存在しないライン」で構成されるライン群の中間の位置が、分割予測位置として決定される。図１７（ｅ）は、図１７（ｄ）の場合の分割予測位置を矢印と破線で示している。このようにして決定された分割予測位置を示す座標データは、解析完了時のレスポンスにおける“DivideCandidate”として、ＭＦＰ連携サーバ１２０からＭＦＰ１１０へ返される。この例では、１つの分割予測位置しか決定していないが、所定画素数以上の連続する「オブジェクトが存在しないライン」で構成されるライン群が複数見つかった場合は、複数の分割予測位置が決定されることになる。なお、Ｓ１５０１でのエッジ抽出処理やＳ１５０３でのオブジェクト検出処理の手法については特に限定されず、公知の手法を適用すればよい。

以上が、本実施形態に係る原稿認識処理の内容である。なお、本フローにおいては、スキャン画像の全体に対してオブジェクト検出処理を行っていたが、エッジ抽出処理によって原稿領域が検知されなかった残りの領域に対してオブジェクト検出処理を行うようにしてもよい。その際には、スキャン対象の原稿サイズを考慮し、残りの領域のサイズが一定以上の場合にのみオブジェクト検出処理を行うようにしてもよい。このようにオブジェクト検出処理の対象領域をスキャン画像の一部に限定する場合、前述のＳ１５０４のオブジェクト除外処理を省略することができる。

＜ＭＦＰの処理詳細＞
続いて、ＭＦＰ１１０における動作に着目して、上述の画像処理システムで経費精算を行う場合の処理について詳しく説明する。図１８は、ＭＦＰ１１０での経費精算処理の流れを示すフローチャートである。この一連の処理は、制御部２１０において、ＣＰＵ２１１がＨＤＤ２１４に記憶された制御プログラムを実行することにより実現され、前述のメイン画面６００での「経費精算」ボタン６０１の押下に応答して開始される。以下、図１６に示すフローチャートに沿って詳しく説明する。なお、各処理の冒頭における記号「Ｓ」はステップを意味する。

Ｓ１８０１において、表示制御部４２１は、前述のログイン画面７００を表示する。ログイン画面７００上でユーザ名とパスワードが入力欄７０２及び７０３にそれぞれ入力され、「ログイン」ボタン７０１の押下が検知されると、Ｓ１８０２に進む。

Ｓ１８０２において、連携サービスリクエスト部４２３は、ログイン認証リクエストをＭＦＰ連携サーバ１２０に送信する。ＭＦＰ連携サーバ１２０でのログイン認証によって正規のユーザであることが確認されると、連携サービスリクエスト部４２３は、アクセストークンをＭＦＰ連携サーバ１２０から受信する。

アクセストークンを受信した連携サービスリクエスト部４２３は、Ｓ１８０３において、代理申請対象者リストの取得リクエストをアクセストークンと共にＭＦＰ連携サーバ１２０に送信する。そして、代理申請対象者リストをＭＦＰ連携サーバ１２０経由で経費精算サーバ１３０から受信すると、それを表示制御部４２１に渡す。

Ｓ１８０４において、表示制御部４２１は、受け取った代理申請対象者リストに基づいて前述の申請者設定画面９００を操作部２２０に表示する。このとき、申請者設定画面９００の選択欄９０２には、ログイン中の本人のユーザ名が初期値として表示され、代理申請対象者が選択されることなく「次へ」ボタン９０１が押下された場合は、本人申請として経費精算サービスに領収書画像の登録等を行うことになる。ログインユーザによって、いずれかのユーザ名が選択され、「次へ」ボタン９０１の押下が検知されると、Ｓ１８０５へ進む。なお、代理申請対象者リストにユーザ名が存在しない（リストの中身が空）であれば、本ステップ自体がスキップされる。

Ｓ１８０５において、表示制御部４２１は、前述のスキャン設定画面１０００を操作部２２０に表示する。ログインユーザによって原稿台に領収書がセットされ、「スキャン開始」ボタン１００１の押下が検知されると、表示制御部４２１は、スキャン制御部４２２に対してその旨を通知する。

通知を受けたスキャン制御部４２２は、Ｓ１８０６において、スキャン実行部４１１に対してスキャン処理の実行を指示する。当該指示を受けてスキャン実行部４１１は、原稿台に置かれた領収書をスキャンする。スキャンによって生成されたスキャン画像データは、画像データ保存部４１２に保存され、当該スキャン画像を特定可能な識別子がスキャン制御部４２１に通知される。この際、スキャンの実行中である旨を示すメッセージ画面（不図示）が操作部２２０上に表示されるようにしてもよい。

次に、Ｓ１８０７において、連携サービスリクエスト部４２３は、スキャン制御部４２１を介してスキャン画像データを取得し、ＭＦＰ連携サーバ１２０にその解析リクエストと共に送信する。当該解析リクエストに基づき、ＭＦＰ連携サーバ１２０では、受信したスキャン画像データに対して、前述のマルチクロップ処理が実行される。その際、ＭＦＰ連携サーバ１２０のリクエスト制御部４３１からリクエストＩＤが返される。

リクエストＩＤを取得した連携サービスリクエスト部４２３は、Ｓ１８０８において、処理ステータスの取得リクエストをリクエストＩＤと共にＭＦＰ連携サーバ１２０に送信する。当該取得リクエストに基づき、ＭＦＰ連携サーバ１２０は、リクエストＩＤで特定されるマルチクロップ処理の進行状況に応じたレスポンスをＭＦＰ１１０に返す。

Ｓ１８０９において、連携サービスリクエスト部４２３は、ＭＦＰ連携サーバ１２０から受け取ったレスポンスが処理中を示す内容（図１２（ｂ）を参照）であった場合はＳ１８０８に戻る。そして、所定時間（例えば数秒程度）の経過を待って、再び処理ステータスの取得リクエストをＭＦＰ連携サーバ１２０に送信する。受け取ったレスポンスが完了を示す内容（図１２（ｃ）を参照）であった場合は、Ｓ１８１０に進む。

Ｓ１８１０において、表示制御部４２１は、前述のプレビュー画面１３００を操作部２２０に表示する。ここで、前述の図１３（ａ）を参照して、プレビュー画面について詳しく説明する。いま、プレビュー画面１３００におけるプレビューエリア１３０１には、実線で示す第１検知枠１３０２と、破線で示す第２検知枠１３０３が表示されている。第１検知枠１３０２は、エッジ抽出処理に基づき特定された原稿領域に対応しており、当該検知枠が原稿の外縁を表している精度が高い。一方、第２検知枠は、オブジェクト検出処理に基づき特定された原稿領域に対応しており、当該検知枠が原稿の外縁を表している精度は、第１検知枠よりも低い。これら第１検知枠１３０２及び第２検知枠１３０３は、図１２（ｃ）の完了レスポンスに含まれる解析情報（原稿認識処理の結果情報）に基づき画像処理部４２４にて生成され、スキャン画像に重ねて表示される。第１検知枠１３０２は、各ImageIDで特定される原稿領域のうち、Accuracyが1.0のものについて、Pointsで示す座標情報を用いて生成される。また、第２検知枠１３０３は、Accuracyが0.5の画像領域のPointsで示す座標情報を用いて生成される。そして、ユーザが両者の違いを見た目で識別できるように、異なる表示態様（例えば、枠の線幅や色等を異ならせる）にて、双方の検知枠を表示する。そして、第２検知枠１３０３が重畳表示された原稿領域について分割することが見込まれる場合、当該原稿領域を複数の原稿領域に分割する指示をユーザが行うためのボタン（以下、「分割ボタン」と呼ぶ。）が表示される。この分割ボタンは、原稿領域のどこで分割したらよいかを直感的に認識できるように上述の分割予測位置を示すように配置される。また、分割ボタンには、分割方向を示す情報を付加してもよい。本実施形態では、分割方向を示す両方向矢印を分割ボタン内に表示するようにしている。図１３（ａ）の例では、第２検知枠１３０３の辺上であって、かつ、完了レスポンス内のDivideCandidateに含まれるPoint1の座標位置とPoint2の座標位置とを結んだ線上に分割ボタン１３０４が表示されている。そして、本実施例では、分割ボタン１３０４を、分割予測位置の始点を表すPoint1の座標位置がその中心にくるように配置している。しかし、分割ボタン１３０４の位置はこれに限定されず、Point1の座標位置とPoint2の座標位置とを結んだ線上やその近傍など、どこで分割することになるかをユーザが認識可能な任意の位置に配置すればよい。また、図１３（ａ）のプレビュー画面１３００で示すように、Point1の座標位置とPoint2の座標位置とを結ぶ線が横方向に延びる場合は縦方向に分割するように、分割後の境界を表す線を表示する。また、図１３（ｂ）のプレビュー画面１３００’で示すように、Point1の座標位置とPoint2の座標位置とを結ぶ線が縦方向に延びる場合は横方向に分割するように、分割後の境界を表す線が表示されることになる。また、分割ボタン１３０４は、第２検知枠１３０３を表す矩形の傾き（角度）に合わせて表示するようにしてもよい。

ユーザによって分割ボタン１３０４（又は１３０４’）が押下されると、Ｓ１８１１において、表示制御部４２１は、完了レスポンスに含まれるDivideCandidateの情報に基づき、プレビュー画面を更新する。図１３（ｃ）のプレビュー画面１３１０は、図１３（ａ）のプレビュー画面１３００の更新後の状態を示している。更新後のプレビュー画面１３１０では、第２検知枠１３０３が上下２つに分割され、上の原稿に対応する枠１３１２と下の原稿に対応する枠１３１３に分離している。さらに、分割ボタン１３０４が表示されていた位置に結合ボタン１３１１が表示されている。ユーザは、この結合ボタン１３１１を押下することで、更新後のプレビュー画面１３１０に表示された２つの枠１３１２及び１３１３を、元の第２検知枠１３０３に戻すことができる。つまり、結合ボタン１３１１を使用することによりユーザは、誤って分割ボタン１３０４を押下してしまっても当該操作をキャンセルすることができる。ユーザは、このような更新後のプレビュー画面１３１０にて各原稿の認識状態を確認し、問題がなければ、「送信」ボタン１３０５を押下する。

ユーザが「送信」ボタン１３０５を押下すると、Ｓ１８１２では、分割指示がなされているか（その時点で分割ボタン１３０４が押下されているか）によって、処理の切り分けが行われる。分割指示がなされていればＳ１８１３に進む。一方、分割指示がなされていなければ、Ｓ１８１３をスキップしてＳ１８１４に進む。

Ｓ１８１３において、連携サービスリクエスト部４２３は、前述の分割リクエストをＭＦＰ連携サーバ１２０に送信する。分割リクエストを受けたＭＦＰ連携サーバ１２０では、リクエスト制御部４３１が、分割リクエスト内のDivideIDに基づき、分割位置を示す座標情報に従って分割対象の原稿領域に対し分割を実行した時の分割後の原稿領域を決定する。そして、分割後の各原稿領域に対し、それぞれを一意に示すImageIDを付与する。そして、分割後の各原稿領域に付与されたImageIDの情報を含むレスポンスが、ＭＦＰ１１０に返される。

Ｓ１８１４において、連携サービスリクエスト部４２３は、登録リクエストをＭＦＰ連携サーバ１２０に送信する。前述のとおり、登録リクエストには、登録対象の原稿単位の画像（ここでは領収書画像）の、スキャン画像における原稿領域を示すImageIDが含まれる。登録リクエストを受けたＭＦＰ連携サーバ１２０では、領収書画像を経費精算サーバ１３０に登録するための処理が行われる。具体的には、まず、リクエスト制御部４３１が、登録リクエスト内のImageIDに基づきスキャン画像から原稿領域を切り出すための座標情報を取得し、画像処理部４３２に対して領収書画像の切り出し処理を指示する。当該指示を受けた画像処理部４３２は、経費精算サーバ１３０に登録するための領収書画像を生成する。そして、経費精算リクエスト部４３３が、アクセストークンに紐づいた経費精算サーバ１３０のユーザ情報を取得し、登録リクエストを当該ユーザ情報と紐付けて経費精算サーバ１３０に送信する。この登録リクエストを受けた経費精算サーバ１３０では、リクエスト制御部４４１の指示に基づき、経費情報管理部４４２が領収書画像の登録処理を行う。そして、リクエスト制御部４４１は、Stautusに登録完了を表す“completed”の文字列が格納されたレスポンスをＭＦＰ連携サーバ１２０に返す。この登録完了のレスポンスは、ＭＦＰ連携サーバ１２０のリクエスト制御部４３１を介して、ＭＦＰ１１０に返される。

以上が、本実施形態に係る、ＭＦＰ１１０を中心とした経費精算処理の内容である。

＜変形例＞
上述の実施形態において、分割を実行した際には、その分割位置に隣接するオブジェク同士の間隔などの情報を、当該分割を指示したユーザと紐付けて保持しておくようにしてもよい。この場合、同一ユーザが次回以降ログインした際に、保持しておいた履歴情報を参照して、自動的に分割ボタン１３０４を押下した後の状態を表示させることができる。これにより、ユーザの手間を省くことができ利便性が向上する。

また、プレビュー画面の初期表示状態を、図１３（ａ）の状態ではなく、図１３（ｃ）の状態としてもよい。すなわち、プレビュー画面を最初に表示する段階で、第２検知枠１３０３を分割予測位置に基づき２つの枠１３１２及び１３１３に分割して表示し、さらに当該分割を行った位置に結合ボタン１３１１を表示するようにしてもよい。

［実施形態２］
実施形態１では、プレビュー画面上に分割ボタンを表示する際の分割予測位置を、原稿認識処理の中で、隣接するオブジェクト同士の間隔を元に決定していた（図１５のフローチャートのＳ１５０７を参照）。そのため、並べて置いた２枚の原稿の間隔が一定以上ないと（Ｓ１５０６でＮｏの場合）、プレビュー画面に分割ボタンが表示されないことになる。図１９（ａ）に、分割ボタンの表示がないプレビュー画面の一例を示す。図１９（ａ）のプレビュー画面１９００においては、縦に並べて置いた２枚の領収書の間隔が狭かったために、第２検知枠１９０１に分割ボタンが表示されていない。

そこで、図１９（ａ）の状態のプレビュー画面が表示されるケースであっても、ユーザが任意の位置で原稿領域の分割が行えるようにする態様を、実施形態２として説明する。なお、システム構成といった基本的な構成は実施形態１と共通であり特に異なるところはないので、以下では、本実施形態の特徴的構成、すなわち、ユーザが所望の位置に分割ボタンを表示させるための操作・処理を中心に説明を行うこととする。

いま、実施形態１で説明した図１８のフローチャートのＳ１８１０において、ＭＦＰ１１０の操作部２２０上に表示されたプレビュー画面の初期表示状態が、前述の図１９（ａ）の状態であったとする。このような状態下で、本実施形態においては、原稿領域を分割したい位置（すなわち、分割ボタンを表示させたい位置）をユーザが指定できるようにする。指定方法としては、例えば、操作部２２０がタッチパネル機能を有していれば、プレビュー画面１９００上の第２検知枠１９０１内の任意の位置をユーザにタッチ操作させる。図１９（ｂ）は、プレビュー画面１９００上にてユーザが自身の指１９０２を使ったタッチ操作の様子を示す図である。この場合のユーザの意図としては、上下に並べて置いた２枚の領収書それぞれに対応する画像が得られるように、第２検知枠１９０１に対応する原稿領域を上下に２分割するような分割位置を指定していることになる。このタッチ操作を契機としてプレビュー画面の更新がなされ得るという意味で、ここでのタッチ操作が実施形態１における分割ボタンの押下に相当することになる。なお、ユーザによる分割位置の指定をマウス等で行っても構わない。このようなユーザによるタッチ操作を表示制御部４２１が検知すると、連携サービスリクエスト部４２３が、ユーザが指定した位置で原稿領域が分割できるかどうかを確認するためのリクエスト（以下、「分割判定リクエスト」と呼ぶ。）を、ＭＦＰ連携サーバ１２０に送信する。図２０（ａ）に分割判定リクエストの一例を示す。分割判定リクエストに含まれる“DividePoint”は、ユーザが指定した位置の座標情報である。

分割判定リクエストを受け取ったＭＦＰ連携サーバ１２０では、リクエスト制御部４３１が、DividePointの座標情報を取得し、当該座標情報によって特定される位置によって原稿領域の分割が可能かどうかを判定する。具体的には、まず、ユーザが指定した位置を含んでいる第２検知枠内の各オブジェクトの角度について最頻値を求める。そして、最頻値となった角度に合わせて、ユーザが指定した位置から垂直方向及び水平方向に直線を延ばし、それぞれの直線上にオブジェクトが存在するかどうかを確認する。そして、いずれかの方向の直線上にオブジェクトが存在しない場合は、その方向に分割可能と判断し、オブジェクトが存在しなかった直線と第２検知枠の両端との交点の座標情報を含むレスポンスを、ＭＦＰ１１０に返す。いずれの方向の直線上にもオブジェクトが存在しない場合は、垂直方向と水平方向のどちらがよりオブジェクト同士の間隔が大きいかを判断する。そして、垂直方向の方がオブジェクト同士の間隔が大きい場合は、水平方向に分割可能と判断し、ユーザが指定した位置から水平方向に延びる直線と第２検知枠の両端との交点の座標情報を含むレスポンスをＭＦＰ１１０に返す。一方、水平方向の方がオブジェクト同士の間隔が大きい場合は、垂直方向に分割可能と判断し、ユーザが指定した位置から垂直方向に延びる直線と第２検知枠の両端との交点の座標情報を含むレスポンスをＭＦＰ１１０に返す。そして、いずれの方向の直線上にもオブジェクトが存在する場合は、ユーザが指定した位置では原稿領域を分割できないと判断し、“Status”に分割不可能を表す文字列（error）を格納したレスポンスを返す。図２０（ｂ）は、分割判定リクエストに対するレスポンスの一例であり、図１９（ｂ）の例におけるユーザが指定した位置にて分割可能と判断された場合のレスポンスを示している。“Status”に分割可能を表す文字列（succeeded）が格納されている点を除き、“Images”に格納されている内容は、図１２（ｃ）で示した解析処理完了時のレスポンスと同様である。もちろん、この場合のPoint1とPoint2の座標情報で特定される位置は、分割可能と判断したときの上述の座標位置である。

分割判定リクエストに対する上記いずれかのレスポンスを受け取ったＭＦＰ１１０では、表示制御部４２１が、受け取ったレスポンスに含まれる情報に基づき、プレビュー画面１９００を更新する（Ｓ１８１１）。図１９（ｃ）のプレビュー画面１９１０は、図１９（ａ）のプレビュー画面１３００の更新後の状態を示している。更新後のプレビュー画面１９１０では、第２検知枠１９０１に対応する原稿領域を上下２つに分割する際の分割線１９１１が表示されている。さらに、当該分割をキャンセルするための結合ボタン１９１２が表示されている。これ以降の処理は、実施形態１と同じであるので説明を省く。

以上が、本実施形態に係る、分割ボタンがプレビュー画面に表示されないケースに対応したＭＦＰ１１０における経費精算処理の流れである。

＜変形例＞
なお、本実施形態において、ユーザのタッチ操作等に従って分割を実行した場合、その分割位置に隣接するオブジェク同士の間隔の情報を、当該分割を指示したユーザと紐付けて保持しておくこともできる。そして、同一ユーザが次回以降ログインした際に、保持しておいた履歴情報を参照して、オブジェクト同士の間隔が前回のタッチ操作で分割したときの間隔以上の時に、分割ボタンを自動で表示させるようにする。これにより、ユーザの手間を省くことができ利便性が向上する。

［実施形態３］
実施形態１の図１５のフローチャートの説明で述べたとおり、オブジェクト検出処理によって原稿領域を特定する際の矩形の設定においては、原稿の余白を考慮してマージンを取ることが望ましい。しかし、マージンを取っていても、原稿によっては用意したマージン以上の余白が存在し、設定した矩形（＝第２検知枠）の中に原稿が収まりきらない可能性がある。そこで、プレビュー画面に表示された第２検知枠の各辺をユーザが調整できるようにする態様を、実施形態３として説明する。

図２１は、実施形態２の図１９（ｃ）に示した更新後のプレビュー画面１９１０をベースとした、本実施形態に係るプレビュー画面の一例を示す図である。第２検知枠１９０１の各辺の近く（この例では、辺の中央付近）に、辺の位置を変更するための調整ボタン２１０１が表示されている。この調整ボタン２１０１は、例えば第２検知枠１９０１に対するタッチ操作や不図示の専用ボタンの押下等に応じて表示される。ユーザは、各辺に対応した調整ボタン２１０１を操作（例えば、ドラッグアンドドロップ）して、原稿のサイズに合うように辺の位置を調整する。なお、図２１（ｃ）のプレビュー画面２１００では、第２検知枠１９０１の辺だけでなく、分割線１９１１に対しても調整ボタン２１０１を設け、分割位置も微調整できるようにしている。調整ボタン２１０１によって分割位置が変更された場合は、それに伴って分割ボタン１９１２の位置も変化する。調整ボタン２１０１を用いて第２検知枠の辺の位置や分割位置の調整を行った場合、前述の登録リクエストには、ImageIDの情報に加えて、調整後の各原稿領域の外縁を表す枠の４点座標の情報も格納される。図１４（ｄ）に、本実施形態に係る登録リクエストの一例を示す。

上記登録リクエストを受け取ったＭＦＰ連携サーバ１２０では、リクエスト制御部４３１が、当該登録リクエストに含まれる座標情報を使用して、スキャン画像から各原稿に対応する画像領域の切り出し処理を行って、原稿単位の画像を得る。

本実施形態によれば、予め決めたマージンでは原稿の余白が切れてしまうような場合でも、ユーザが原稿のサイズに合わせて、スキャン画像から切り出す際の原稿領域を調整することができる。

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

Claims (19)

1. ユーザに対して情報を提示し、ユーザによる入力操作を受け付けるユーザインタフェースを備える装置であって、
   複数の原稿をまとめてスキャンして得られたスキャン画像に対する原稿認識処理の結果として、当該スキャン画像から検知された原稿領域の位置に関する情報と、前記検知された原稿領域のうちの１つを分割するための分割予測位置に関する情報とを取得する取得手段と、
   前記取得手段で取得した前記原稿領域の位置に関する情報と前記分割予測位置に関する情報とに基づいて、前記検知された原稿領域の位置に対応する枠を前記スキャン画像に重ねて表示し更に前記検知された原稿領域のうちの１つを前記分割予測位置で分割するための指示をユーザが行うための分割ボタンを表示したプレビュー画面を、前記ユーザインタフェースに表示する表示制御手段と、
   を有することを特徴とする装置。
2. 前記原稿認識処理では、前記スキャン画像に対するオブジェクト検出処理により検出されたオブジェクトに基づいて第１の原稿領域を検知し、
   前記分割予測位置は、前記オブジェクト検出処理により検出されたオブジェクトに基づき検知された前記第１の原稿領域において、前記検出されたオブジェクト同士の間隔が一定以上ある位置に基づいて決定される、
   ことを特徴とする請求項１に記載の装置。
3. 前記原稿認識処理では、前記スキャン画像に対するエッジ抽出処理により抽出された原稿の端の直線成分に基づいて第２の原稿領域を特定し、
   前記第１の原稿領域は、前記スキャン画像に対するオブジェクト検出処理により検出されたオブジェクトのうち、前記第２の原稿領域に係るオブジェクトを除くオブジェクトに基づいて検出され、
   前記取得手段により取得される前記原稿領域の位置に関する情報は、前記第１の原稿領域の位置に関する情報と前記第２の原稿領域の位置に関する情報とを含む、
   ことを特徴とする請求項２に記載の装置。
4. 前記表示制御手段は、前記第１の原稿領域の位置に対応する枠と、前記第２の原稿領域の位置に対応する枠とを、異なる表示態様で、前記スキャン画像に重ねて表示する、ことを特徴とする請求項３に記載の装置。
5. 前記表示制御手段は、前記分割ボタンを、前記分割予測位置に配置することを特徴とする請求項１乃至４のいずれか１項に記載の装置。
6. 前記表示制御手段は、前記分割予測位置が決定されなかった原稿領域について、前記分割ボタンを、ユーザ指示に基づいて表示することを特徴とする請求項２に記載の装置。
7. 前記ユーザ指示に伴って指定された位置にて前記分割が可能かどうかを判定する判定手段をさらに備え、
   前記表示制御手段は、前記判定手段にて前記分割が可能と判定された場合に、前記分割ボタンを表示する
   ことを特徴とする請求項６に記載の装置。
8. 前記判定手段は、前記指定された位置から垂直方向及び水平方向に直線を延ばし、それぞれの直線上にオブジェクトが存在するかどうかによって前記分割が可能かどうかを判定することを特徴とする請求項７に記載の装置。
9. 前記表示制御手段は、前記分割ボタンを、前記枠に沿って配置することを特徴とする請求項１に記載の装置。
10. 前記表示制御手段は、前記分割ボタンを、前記枠内の分割後の境界を示す線上に配置することを特徴とする請求項１に記載の装置。
11. 前記分割ボタンには、前記分割の方向を示す情報が付加されて表示されることを特徴とする請求項１乃至１０のいずれか１項に記載の装置。
12. 前記表示制御手段は、前記分割ボタンの操作に応答して、分割後の状態を示す内容に前記プレビュー画面を更新することを特徴とする請求項１乃至１１のいずれか１項に記載の装置。
13. 前記表示制御手段は、前記分割ボタンの操作に応答して為された分割をキャンセルするためのボタンを、更新後のプレビュー画面に表示することを特徴とする請求項１２に記載の装置。
14. 前記表示制御手段は、ユーザ指示に基づいて、前記分割ボタンが表示された原稿領域の外縁を調整するための調整ボタンを表示することを特徴とする請求項１乃至１３のいずれか１項に記載の装置。
15. 前記表示制御手段は、ユーザ指示に基づいて、前記分割ボタンの操作に応答して為される分割の位置を調整するためのボタンをさらに表示することを特徴とする請求項１乃至１４のいずれか１項に記載の装置。
16. 前記原稿認識処理を実行する外部装置と接続され、
    ユーザにより前記分割ボタンの操作が為された場合、当該操作が為された前記分割ボタンに係る前記原稿領域の１つについての分割のリクエストを、前記外部装置に送信する通信手段をさらに備える、
    ことを特徴とする請求項１乃至１５のいずれか１項に記載の装置。
17. 前記原稿認識処理を実行する処理手段をさらに備え、
    前記処理手段は、ユーザにより前記分割ボタンの操作が為された場合、当該操作が為された前記分割ボタンに係る前記原稿領域の１つを分割する処理を行う、
    ことを特徴とする請求項１乃至１５のいずれか１項に記載の装置。
18. ユーザに対して情報を提示し、ユーザによる入力操作を受け付けるユーザインタフェースを備える装置の制御方法であって、
    複数の原稿をまとめてスキャンして得られたスキャン画像に対する原稿認識処理の結果として、当該スキャン画像から検知された原稿領域の位置に関する情報と、前記検知された原稿領域のうちの１つを分割するための分割予測位置に関する情報とを取得する取得ステップと、
    前記取得ステップにて取得した前記原稿領域の位置に関する情報と前記分割予測位置に関する情報とに基づいて、前記検知された原稿領域の位置に対応する枠を前記スキャン画像に重ねて表示し更に前記検知された原稿領域のうちの１つを前記分割予測位置で分割するための指示をユーザが行うための分割ボタンを表示したプレビュー画面を、前記ユーザインタフェースに表示する表示制御ステップと、
    を含むことを特徴とする制御方法。
19. コンピュータを、請求項１乃至１７のいずれか１項に記載の装置の各手段として機能させるためのプログラム。

Images