特許 5721539 サーバ、情報処理方法および情報処理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5721539

(24)【登録日】2015年4月3日

(45)【発行日】2015年5月20日

(54)【発明の名称】サーバ、情報処理方法および情報処理システム

(51)【国際特許分類】

   G06Q 40/02 20120101AFI20150430BHJP

   G06F 17/30 20060101ALI20150430BHJP

【ＦＩ】

   G06Q40/02 170

   G06F17/30 210D

   G06F17/30 310C

   G06F17/30 350A

【請求項の数】11

【全頁数】19

(21)【出願番号】特願2011-120193(P2011-120193)

(22)【出願日】2011年5月30日

(65)【公開番号】特開2012-248053(P2012-248053A)

(43)【公開日】2012年12月13日

【審査請求日】2014年2月17日

(73)【特許権者】

【識別番号】000000295

【氏名又は名称】沖電気工業株式会社

(73)【特許権者】

【識別番号】591051645

【氏名又は名称】株式会社ＯＫＩソフトウェア

(74)【代理人】

【識別番号】100095957

【弁理士】

【氏名又は名称】亀谷 美明

(74)【代理人】

【識別番号】100096389

【弁理士】

【氏名又は名称】金本 哲男

(74)【代理人】

【識別番号】100101557

【弁理士】

【氏名又は名称】萩原 康司

(72)【発明者】

【氏名】上地 裕詞

【審査官】 宮地 匡人

(56)【参考文献】

【文献】 特開２００９−２１１２０５（ＪＰ，Ａ）

【文献】 特開２００６−０７２７８３（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００６／０１９０４８９（ＵＳ，Ａ１）

【文献】 能塒善美，金融機関事務における帳票イメージ処理技術の応用，ＯＫＩテクニカルレビュー，沖電気工業株式会社，２００９年 ４月 １日，Vol.76 No.1，pp.26-29

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ ４０／０２

Ｇ０６Ｆ １７／３０

(57)【特許請求の範囲】

【請求項1】

複数の文字データの各々が属する分類区分を判定する判定部と、
分類区分を特定する特定部と、
前記複数の文字データのうち、前記特定部により特定された前記分類区分に属する文字データを端末に通知する通知部と、
を備え、
前記特定部は、
前記複数の文字データの分類区分ごとの件数に基づいて、分類区分を特定する、
ことを特徴とする、サーバ。

【請求項2】

前記特定部は、
前記件数が最大である分類区分を特定する、
ことを特徴とする、請求項１に記載のサーバ。

【請求項3】

複数の文字データの各々が属する分類区分を判定する判定部と、
分類区分を特定する特定部と、
前記複数の文字データのうち、前記特定部により特定された前記分類区分に属する文字データを端末に通知する通知部と、
を備え、
前記特定部は、
所定条件を満たす日時が関連付けられている文字データが前記複数の文字データに存在する場合には、当該文字データが属する分類区分を特定し、当該文字データが存在しない場合には、前記複数の文字データの分類区分ごとの件数に基づいて分類区分を特定する、
ことを特徴とする、サーバ。

【請求項4】

複数の文字データの各々が属する分類区分を判定するステップと、
分類区分を特定するステップと、
前記複数の文字データのうち、特定された前記分類区分に属する文字データを端末に通知するステップと、
を含み、
前記複数の文字データの分類区分ごとの件数に基づいて、分類区分を特定するステップを含む、
ことを特徴とする、情報処理方法。

【請求項5】

複数の文字データの各々が属する分類区分を判定するステップと、
分類区分を特定するステップと、
前記複数の文字データのうち、特定された前記分類区分に属する文字データを端末に通知するステップと、
を含み、
所定条件を満たす日時が関連付けられている文字データが前記複数の文字データに存在する場合には、当該文字データが属する分類区分を特定し、当該文字データが存在しない場合には、前記複数の文字データの分類区分ごとの件数に基づいて分類区分を特定するステップを含む、
ことを特徴とする、情報処理方法。

【請求項6】

複数の画像データに対して文字認識を行うことにより前記複数の画像データの各々に対応する文字データを複数の文字データとして取得する認識装置と、
前記複数の文字データの各々が属する分類区分を判定する判定部と、
分類区分を特定する特定部と、
前記複数の文字データのうち、前記特定部により特定された前記分類区分に属する文字データを端末に通知する通知部と、
を備え、
前記特定部は、
前記複数の文字データの分類区分ごとの件数に基づいて、分類区分を特定する、
サーバと、
を有することを特徴とする、情報処理システム。

【請求項7】

複数の画像データに対して文字認識を行い、文字認識対象の単語辞書に含まれる単語と一致する文字列を、前記複数の画像データの各々に対応する文字データとして前記複数の画像データごとに出力する認識装置と、
前記複数の文字データの各々が属する分類区分を前記一致した単語の区分により判定する判定部と、
分類区分を特定する特定部と、
前記複数の文字データのうち、前記特定部により特定された前記分類区分に属する文字データを端末に通知する通知部と、
を備え、
前記特定部は、
前記複数の文字データの分類区分ごとの件数に基づいて、分類区分を特定する、
サーバと、
を有することを特徴とする、情報処理システム。

【請求項8】

前記文字認識対象は住所であり、前記単語辞書は住所辞書であり、前記単語は住所単語であることを特徴とする、請求項７に記載の情報処理システム。

【請求項9】

前記認識装置は、
前記複数の文字データの各々に日時を関連付ける、
ことを特徴とする、請求項６または７に記載の情報処理システム。

【請求項10】

前記情報処理システムは、
複数の記入用紙を読み取ることにより前記複数の記入用紙の各々に対応する画像データを前記複数の画像データとして取得する読取装置、
を有することを特徴とする、請求項６または７に記載の情報処理システム。

【請求項11】

前記情報処理システムは、
前記サーバから前記文字データを取得する取得部と、
前記取得部により取得された前記文字データを表示するよう制御する表示制御部と、
を備える、端末、
を有することを特徴とする、請求項６または７に記載の情報処理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバ、情報処理方法および情報処理システムに関するものである。より詳細には、例えば、銀行業務等を支援する情報処理システムにおいて帳票に関する作業をオペレータに割り振る技術に関するものである。

【背景技術】

【0002】

近年、銀行業務等においては、帳票等の記入用紙に記載された情報をコンピュータで利用できるデータ形式（例えば、テキストコード等の形式）に変換する作業が行われている。さらに、イメージスキャナにより記入用紙をスキャンして得られた読取データに対してＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）認識が行われた上で、ＯＣＲ認識により得られた文字データに対して、オペレータが訂正や、入力、確認などの作業が行われている。

【0003】

このような作業において、例えば、文字データをフィールド（例えば、住所、名前等）ごとに分割して、文字データに対する作業をフィールドごとにオペレータに行わせる技術や、文字データをランダムに並べることによりセキュリティを向上させる技術が存在する。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００６−１９５７８１号公報

【特許文献2】特開２００１−００５８８８号公報

【特許文献3】特開２００６−０７２７８３号公報

【特許文献4】特開２００６−１０７３１９号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、従来技術においては、フィールドごとにオペレータに作業を割り当てることは可能であるが、記入用紙に記載された内容が考慮された作業の割り当てはなされていない。例えば、内容が類似している複数の文字データに対する作業を同一のオペレータに割り当てれば、オペレータは、類似の文字データに対する作業を連続して行うことができるようになり、作業が効率化されることが期待できる。

【0006】

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、内容が類似している複数の文字データに対する作業を同一のオペレータに割り当てることが可能な技術を提供することにある。また、例えば、類似の文字データが他に存在しない文字データは、長期間オペレータにより作業が行われずに残ってしまう可能性があるため、スキャンされた日時が所定期間より古い文字データについては、優先してオペレータによる処理対象とすることもできる。

【課題を解決するための手段】

【0007】

上記問題を解決するために、本発明のある観点によれば、複数の文字データの各々が属する分類区分を判定する判定部と、分類区分を特定する特定部と、前記複数の文字データのうち、前記特定部により特定された前記分類区分に属する文字データを端末に通知する通知部と、を備えることを特徴とする、サーバが提供される。

【0008】

前記判定部は、前記複数の文字データの中に、一部または全部が一致する複数の文字データが存在する場合、当該一部または全部が一致する複数の文字データが同一の分類区分に属すると判定することとしてもよい。

【0009】

前記特定部は、前記複数の文字データの分類区分ごとの件数に基づいて、分類区分を特定することとしてもよい。

【0010】

前記特定部は、前記件数が最大である分類区分を特定することとしてもよい。

【0011】

前記特定部は、所定条件を満たす日時が関連付けられている文字データが前記複数の文字データに存在する場合には、当該文字データが属する分類区分を特定し、当該文字データが存在しない場合には、前記複数の文字データの分類区分ごとの件数に基づいて分類区分を特定することとしてもよい。

【0012】

また、本発明の別の観点によれば、複数の文字データの各々が属する分類区分を判定するステップと、分類区分を特定するステップと、前記複数の文字データのうち、特定された前記分類区分に属する文字データを端末に通知するステップと、を含むことを特徴とする、情報処理方法が提供される。

【0013】

また、本発明の別の観点によれば、複数の画像データに対して文字認識を行うことにより前記複数の画像データの各々に対応する文字データを複数の文字データとして取得する認識装置と、前記複数の文字データの各々が属する分類区分を判定する判定部と、分類区分を特定する特定部と、前記複数の文字データのうち、前記特定部により特定された前記分類区分に属する文字データを端末に通知する通知部と、を備える、サーバと、を有することを特徴とする、情報処理システムが提供される。

【0014】

前記認識装置は、前記複数の文字データの各々に日時を関連付けることとしてもよい。

【0015】

前記情報処理システムは、複数の記入用紙を読み取ることにより前記複数の記入用紙の各々に対応する画像データを前記複数の画像データとして取得する読取装置、を有することとしてもよい。

【0016】

前記情報処理システムは、前記サーバから前記文字データを取得する取得部と、前記取得部により取得された前記文字データを表示するよう制御する表示制御部と、を備える、端末、を有することとしてもよい。

【発明の効果】

【0017】

以上説明したように本発明によれば、内容が類似している複数の文字データに対する作業を同一のオペレータに割り当てることが可能となる。

【図面の簡単な説明】

【0018】

【図1】本発明の実施形態に係る情報処理システムの構成を示すブロック図である。

【図2】記入用紙の一例としての帳票を示す図である。

【図3】本発明の実施形態に係るサーバの機能構成を示すブロック図である。

【図4】帳票データテーブルの構成例を示す図である。

【図5】帳票グルーピングテーブルの構成例を示す図である。

【図6】本発明の実施形態に係るサーバによる分類を説明するための図である。

【図7】本発明の実施形態に係るサーバの機能を説明するための図である。

【図8】本発明の実施形態に係るサーバの機能を説明するための図である。

【図9】本発明の実施形態に係るサーバの機能を説明するための図である。

【図10】本発明の実施形態に係るサーバの機能を説明するための図である。

【図11】本発明の実施形態に係るサーバの機能を説明するための図である。

【図12】本発明の実施形態に係る端末の機能構成を示すブロック図である。

【図13】本発明の実施形態に係る情報処理システムにより実行される登録処理の流れの一例を示すフローチャートである。

【図14】本発明の実施形態に係る情報処理システムにより実行される登録処理の流れの他の一例を示すフローチャートである。

【図15】本発明の実施形態に係る情報処理システムにより実行される割り当て処理の流れの一例を示すフローチャートである。

【発明を実施するための形態】

【0019】

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

【0020】

［構成の説明］
図１は、本発明の実施形態に係る情報処理システムの構成を示すブロック図である。図１を参照しながら、本発明の実施形態に係る情報処理システムの構成について説明する。

【0021】

図１に示すように、本発明の実施形態に係る情報処理システム１は、読取装置１０と、認識装置２０と、サーバ３０と、複数の端末４０とを備える。なお、複数の端末４０の各々を区別するときには、複数の端末４０の各々を、端末４０Ａ、端末４０Ｂ、端末４０Ｃのように記載し、複数の端末４０の各々を区別しない場合には、単に、端末４０と記載する。

【0022】

サーバ３０と端末４０とは、ネットワークに接続されており、図１に示した例では、サーバ３０と端末４０とが直接的に集線装置５０に接続されている。また、図１に示した例では、認識装置２０は、集線装置５０に接続されているが、サーバ３０に直接接続されていてもよい。また、認識装置２０は、サーバ３０と別体であってもよく、サーバ３０と一体化されていてもよい。

【0023】

読取装置１０は、帳票を読み取る機能を有しており、帳票を読み取ることにより得られた画像データを認識装置２０に出力する。なお、以下では、記入用紙の一例として帳票を使用する場合を説明するが、読取装置１０により読み取られる記入用紙は、帳票に限定されない。図２は、記入用紙の一例としての帳票を示す図である。図２に示した例では、帳票は、「氏名」「生年月日」「住所」「電話番号」「口座番号」「その他」の各々のフィールドを含んでいる。

【0024】

帳票は、例えば、銀行の店舗に訪れた顧客により記載される。図２に示した例では、顧客により「氏名」「生年月日」「住所」「電話番号」「口座番号」「その他」の各々のフィールドに所望の内容が手書きで記載される。顧客により記載された帳票は、例えば、銀行の店舗の窓口に配属されている銀行員等により受け取られ、読取装置１０により読み取られる。読取装置１０は、複数の帳票を読み取った場合には、複数の帳票を読み取ることにより得られた複数の画像データを認識装置２０に出力する。

【0025】

認識装置２０は、画像データに対して文字認識を行うことにより文字データを取得する機能を有している。例えば、認識装置２０は、読取装置１０から複数の画像データが入力された場合、複数の画像データに対して文字認識を行うことにより複数の画像データの各々に対応する文字データを複数の文字データとして取得する。

【0026】

例えば、１枚目の帳票に「札幌市中央区北１条３丁目」と記載されており、２枚目の帳票に「札幌市中央区南１２条８丁目１−１８」と記載されていた場合、認識装置２０は、１枚目の帳票から取得された画像データから文字データ「札幌市中央区北１条３丁目」を取得し、２枚目の帳票から取得された画像データから文字データ「札幌市中央区南１２条８丁目１−１８」を取得することができる。

【0027】

なお、図２に示した例では、帳票が複数のフィールドを有している。かかる場合には、認識装置２０により文字データがフィールドごとに取得され得る。

【0028】

認識装置２０は、文字データに日時を関連付けて、文字データと日時とが関連付けられた状態のデータをサーバ３０に通知してもよい。日時としては、例えば、認識装置２０により認識装置２０の内部または外部に存在する時計から取得された現在時刻を使用し得る。また、認識装置２０は、文字データに画像データを関連付けて、文字データと画像データとが関連付けられた状態のデータをサーバ３０に通知してもよい。

【0029】

サーバ３０は、認識装置２０から入力された複数の文字データの各々が属する分類区分を判定する機能を有している。サーバ３０は、例えば、類似している文字データが存在すれば、類似している文字データが同一の分類区分に属すると判定する。サーバ３０は、この判定結果に基づいて適切な分類区分を特定し、特定した分類区分に属する１または複数の文字データを端末４０に通知する。サーバ３０は、例えば、端末４０から送信要求があった場合、その送信要求に対する応答として、特定した分類区分に属する１または複数の文字データを返信することができる。サーバ３０が有する機能については、後に詳細に説明する。

【0030】

端末４０は、サーバ３０から受信した１または複数の文字データを表示することができる。端末４０を操作するオペレータは、端末４０を操作することにより、サーバ３０から受信した１または複数の文字データに対する処理（例えば、文字データに対する訂正等）を行うことができる。サーバ３０から受信した１または複数の文字データは、同一の分類区分に属しており、類似していることが想定されるため、オペレータは作業を効率良く進めることができる。端末４０が有する機能については、後に詳細に説明する。

【0031】

図３は、本発明の実施形態に係るサーバ３０の機能構成を示すブロック図である。図３に示すように、サーバ３０は、制御部３１０、通信部３３０、記憶部３４０を備えている。制御部３１０は、サーバ３０の動作全体を制御する機能を有しており、判定部３１１、計測部３１２、特定部３１３、通知部３１４を有している。通信部３３０は、認識装置２０および端末４０の各々と通信を行う機能を有している。記憶部３４０は、サーバ３０の動作に使用される各種プログラムや各種データを記憶する機能を有している。

【0032】

判定部３１１は、複数の文字データの各々が属する分類区分を判定する。上記したように、複数の文字データは、認識装置２０から取得され得る。例えば、認識装置２０から送信された複数の文字データが通信部３３０により受信され、通信部３３０により受信された複数の文字データが判定部３１１により取得される。

【0033】

複数の文字データは認識装置２０から通信部３３０によって受信された後、制御部３１０による制御に従って、記憶部３４０により記憶されてもよい。例えば、文字データに、日時および画像データが関連付けられている場合には、文字データに、日時（以下、「登録日時」とも言う。）、状態（０：未処理）および画像データが関連付けられた帳票データという形式で帳票データテーブルに追加され得る。図４は、帳票データテーブルの構成例を示す図である。帳票データテーブルは、記憶部３４０により記憶される。帳票データテーブルの更新結果は、認識装置２０に通知されてもよい。

【0034】

例えば、認識装置２０により、１枚目の帳票から取得された画像データから文字データ「札幌市中央区北１条３丁目」が取得され、２枚目の帳票から取得された画像データから文字データ「札幌市中央区南１２条８丁目１−１８」が取得された場合を想定する。この場合、判定部３１１は、認識装置２０からこれらの文字データを取得するが、これらの文字データは、それぞれの一部である「札幌市中央区」が共通しているため、それぞれの文字データが同一の分類区分「札幌市中央区」に属すると判定する。

【0035】

この例のように、判定部３１１は、複数の文字データの中に、一部が一致する複数の文字データが存在する場合、この一部が一致する複数の文字データが同一の分類区分に属すると判定することができる。また、判定部３１１は、複数の文字データの中に、全部が一致する複数の文字データが存在する場合、全部が一致する複数の文字データが同一の分類区分に属すると判定してもよい。

【0036】

あるいは、分類区分の判定を後から行うのではなく、認識装置２０での文字認識の過程で行うこともできる。

【0037】

例えば、住所フィールドの文字認識の過程では、一文字ごとの認識結果は複数候補が出力され、住所辞書データベースに含まれる住所単語とのマッチングにより、複数候補のうち実際の住所にマッチする文字が選択される。「札幌市中央区北１条３丁目」の場合は、まず先頭から３文字について、住所辞書の「札幌市」という単語とマッチングを行い、候補中に含まれていれば、それぞれ「札」「幌」「市」が正しい文字として選択される。以下、「中央区」「北１条」「３丁目」も同様にマッチングを行い、正しい文字を候補から選択する。その結果、認識結果として「札幌市中央区北１条３丁目」という文字列が得られる。この過程で、住所辞書のどの単語と一致したかは把握可能であるので、当該文字列が、どの地域に分類されるかのフラグを文字認識結果とともに記憶管理することで、同一の地域を同一の分類区分に属すると判定することができる。

【0038】

また、例えば「札幌市中央区」までを同一の分類区分としたときにその数が所定数を超過する場合は、さらに下の地域（「北１一条」等）で分類しなおせば、ひとつの分類区分に含まれる文字データの数、すなわちオペレータに確認させるデータの数を適正に保つことができる。

【0039】

計測部３１２は、複数の文字データの分類区分ごとの件数を計数する機能を有する。図６は、本発明の実施形態に係るサーバによる分類を説明するための図である。図６に示した例では、帳票の「住所」フィールドの認識結果を文字データの一例として使用する場合の分類の様子を示している。図６に示すように、判定部３１１は、例えば、複数の文字データのうち、その一部または全部に「札幌市中央区」を含んでいるものを「札幌市中央区」に分類することができる。

【0040】

このように、判定部３１１は、例えば、複数の文字データを「札幌市中央区」「札幌市白石区」「札幌市清田区」「札幌市厚別区」「札幌市手稲区」「札幌市東区」「札幌市南区」のいずれかに分類することができる。図６に示した例では、計測部３１２は、「札幌市中央区」「札幌市白石区」「札幌市清田区」「札幌市厚別区」「札幌市手稲区」「札幌市東区」「札幌市南区」の各々に、１２件、４件、３件、１件、１件、１件、１件が属すると計測することができる。分類区分とその分類区分に属する文字データの件数とオペレータＩＤとが関連付けられたデータは、帳票グルーピングテーブルとして記憶部３４０により記憶され得る。

【0041】

特定部３１３は、分類区分を特定する機能を有する。図６に示した例では、特定部３１３は、分類区分「札幌市中央区」「札幌市白石区」「札幌市清田区」「札幌市厚別区」「札幌市手稲区」「札幌市東区」「札幌市南区」の中から分類区分を少なくとも１つ特定する。特定部３１３は、例えば、端末４０から送信要求を取得したタイミングで分類区分を特定すればよい。特定部３１３は、複数の文字データの分類区分ごとの件数に基づいて、分類区分を特定することができる。特定された分類区分に属する文字データは、端末４０を操作するオペレータにより処理される。複数の文字データの分類区分ごとの件数は、上記したように、例えば、計測部３１２により計数され得る。

【0042】

特定部３１３による分類区分の特定の手法は、特に限定されない。特定部３１３は、例えば、件数が最大である分類区分を特定することができる。また、特定部３１３は、所定条件を満たす登録日時が関連付けられている文字データが複数の文字データに存在する場合には、その文字データが属する分類区分を特定し、所定条件を満たす登録日時が関連付けられている文字データが存在しない場合には、複数の文字データの分類区分ごとの件数に基づいて分類区分を特定してもよい。

【0043】

所定条件は、例えば、現在よりも所定期間古いという条件である。このように、特定部３１３は、例えば、現在よりも所定期間古いという条件を満たす登録日時が関連付けられている文字データが複数の文字データに存在する場合には、その文字データが属する分類区分を特定することができる。これにより、古いデータが未処理のまま長期間放置されてしまうことを防止することができる。

【0044】

通知部３１４は、複数の文字データのうち、特定部３１３により特定された分類区分に属する１または複数の文字データを端末４０に通知する機能を有する。通知部３１４は、例えば、複数の文字データのうち、特定部３１３により特定された分類区分に属する１または複数の文字データの全部を端末４０に通知してもよい。あるいは、通知部３１４は、例えば、複数の文字データのうち、特定部３１３により特定された分類区分に属する１または複数の文字データの一部を端末４０に通知してもよい。

【0045】

図７〜図１１は、本発明の実施形態に係るサーバ３０の機能を説明するための図である。図７に示すような帳票データテーブルと帳票グルーピングテーブルとが記憶部３４０により記憶されているとする。特定部３１３は、例えば、第１オペレータが操作する端末４０から送信要求を取得すると、帳票データテーブルを参照して、登録日時が所定期間より古いデータがあるか否かを判定する。

【0046】

図７に示した例では、特定部３１３は、登録日時「２０１０／１０／０１／０９：００」が現在よりも所定期間古いデータであると判定し、このデータが属する分類区分「札幌市厚別区」を特定する。特定部３１３は、帳票グルーピングテーブルの分類（分類区分）「札幌市厚別区」に関連付けられている「オペレータＩＤ」に第１オペレータのＩＤを設定する。オペレータのＩＤは、例えば、送信要求に設定されている。

【0047】

通知部３１４は、特定部３１３により特定された分類区分に属する帳票データを第１オペレータの操作する端末４０に返信する。その際、通知部３１４は、通知した帳票データに相当する帳票データテーブル内の帳票データの「状態」に「１：処理中」を設定する。通知部３１４は、端末４０からこの帳票データに対する処理が完了した旨が通知された場合には、この「状態」に「２：処理済み」を設定し、この帳票データが属する分類区分に相当する帳票グルーピングテーブルの「件数」から１を減算する。通知部３１４は、同一の分類区分に属する次の帳票データを第１オペレータの操作する端末４０に送信することができる。

【0048】

続いて、特定部３１３は、例えば、第２オペレータが操作する端末４０から送信要求を取得すると、帳票データテーブルを参照して、「状態」が「０：未処理」であり、かつ、「登録日時」が所定期間より古いデータがあるか否かを判定する。

【0049】

図８に示した例では、特定部３１３は、「登録日時」が現在よりも所定期間古いデータがないと判定し、帳票グルーピングテーブルを参照する。特定部３１３は、帳票グルーピングテーブルの中に、「オペレータＩＤ」にオペレータＩＤが設定されておらず、かつ、「件数」が最大である分類（分類区分）が存在するか否かを判定する。図８に示した例では、特定部３１３は、「札幌市中央区」が該当する分類（分類区分）であると判定し、「札幌市中央区」に関連付けられている「オペレータＩＤ」に第２オペレータのＩＤを設定する。

【0050】

通知部３１４は、特定部３１３により特定された分類区分に属する帳票データを第２オペレータの操作する端末４０に返信する。その際、通知部３１４は、通知した帳票データに相当する帳票データテーブル内の帳票データの「状態」に「１：処理中」を設定する。通知部３１４は、端末４０からこの帳票データに対する処理が完了した旨が通知された場合には、この「状態」に「２：処理済み」を設定し、この帳票データが属する分類区分に相当する帳票グルーピングテーブルの「件数」から１を減算する。通知部３１４は、同一の分類区分に属する次の帳票データを第２オペレータの操作する端末４０に送信することができる。

【0051】

続いて、特定部３１３は、例えば、第３オペレータが操作する端末４０から送信要求を取得すると、帳票データテーブルを参照して、「状態」が「０：未処理」であり、かつ、「登録日時」が所定期間より古いデータがあるか否かを判定する。

【0052】

図９に示した例では、特定部３１３は、「登録日時」が現在よりも所定期間古いデータがないと判定し、帳票グルーピングテーブルを参照する。特定部３１３は、帳票グルーピングテーブルの中に、「オペレータＩＤ」にオペレータＩＤが設定されておらず、かつ、「件数」が最大である分類（分類区分）が存在するか否かを判定する。図９に示した例では、特定部３１３は、「札幌市白石区」が該当する分類（分類区分）であると判定し、「札幌市白石区」に関連付けられている「オペレータＩＤ」に第３オペレータのＩＤを設定する。

【0053】

通知部３１４は、特定部３１３により特定された分類区分に属する帳票データを第３オペレータの操作する端末４０に返信する。その際、通知部３１４は、通知した帳票データに相当する帳票データテーブル内の帳票データの「状態」に「１：処理中」を設定する。通知部３１４は、端末４０からこの帳票データに対する処理が完了した旨が通知された場合には、この「状態」に「２：処理済み」を設定し、この帳票データが属する分類区分に相当する帳票グルーピングテーブルの「件数」から１を減算する。通知部３１４は、同一の分類区分に属する次の帳票データを第３オペレータの操作する端末４０に送信することができる。

【0054】

続いて、特定部３１３は、例えば、第４オペレータが操作する端末４０から送信要求を取得すると、帳票データテーブルを参照して、「状態」が「０：未処理」であり、かつ、「登録日時」が所定期間より古いデータがあるか否かを判定する。

【0055】

図１０に示した例では、特定部３１３は、「登録日時」が現在よりも所定期間古いデータがないと判定し、帳票グルーピングテーブルを参照する。特定部３１３は、帳票グルーピングテーブルの中に、「オペレータＩＤ」にオペレータＩＤが設定されておらず、かつ、「件数」が最大である分類（分類区分）が存在するか否かを判定する。図１０に示した例では、特定部３１３は、「札幌市清田区」が該当する分類（分類区分）であると判定し、「札幌市清田区」に関連付けられている「オペレータＩＤ」に第４オペレータのＩＤを設定する。

【0056】

通知部３１４は、特定部３１３により特定された分類区分に属する帳票データを第４オペレータの操作する端末４０に返信する。その際、通知部３１４は、通知した帳票データに相当する帳票データテーブル内の帳票データの「状態」に「１：処理中」を設定する。通知部３１４は、端末４０からこの帳票データに対する処理が完了した旨が通知された場合には、この「状態」に「２：処理済み」を設定し、この帳票データが属する分類区分に相当する帳票グルーピングテーブルの「件数」から１を減算する。通知部３１４は、同一の分類区分に属する次の帳票データを第４オペレータの操作する端末４０に送信することができる。

【0057】

続いて、特定部３１３は、例えば、第５オペレータが操作する端末４０から送信要求を取得すると、帳票データテーブルを参照して、「状態」が「０：未処理」であり、かつ、「登録日時」が所定期間より古いデータがあるか否かを判定する。

【0058】

図１１に示した例では、特定部３１３は、「登録日時」が現在よりも所定期間古いデータがないと判定し、帳票グルーピングテーブルを参照する。特定部３１３は、帳票グルーピングテーブルの中に、「オペレータＩＤ」にオペレータＩＤが設定されておらず、かつ、「件数」が最大である分類（分類区分）が存在するか否かを判定する。図１１に示した例では、特定部３１３は、「札幌市手稲区」「札幌市東区」「札幌市南区」が該当する分類（分類区分）であると判定する。

【0059】

このように、特定部３１３は、帳票グルーピングテーブルの中に、「オペレータＩＤ」にオペレータＩＤが設定されておらず、かつ、「件数」が最大である分類（分類区分）が複数存在すると判定した場合には、登録日時が最も古い帳票データを判定し、このデータが属する分類区分「札幌市手稲区」を特定する。特定部３１３は、帳票グルーピングテーブルの分類（分類区分）「札幌市手稲区」に関連付けられている「オペレータＩＤ」に第５オペレータのＩＤを設定する。

【0060】

通知部３１４は、特定部３１３により特定された分類区分に属する帳票データを第５オペレータの操作する端末４０に返信する。その際、通知部３１４は、通知した帳票データに相当する帳票データテーブル内の帳票データの「状態」に「１：処理中」を設定する。通知部３１４は、端末４０からこの帳票データに対する処理が完了した旨が通知された場合には、この「状態」に「２：処理済み」を設定し、この帳票データが属する分類区分に相当する帳票グルーピングテーブルの「件数」から１を減算する。減算すると「件数」が「０」になるため、通知部３１４は、その分類区分を帳票グルーピングテーブルから削除してもよい。

【0061】

図１２は、本発明の実施形態に係る端末４０の機能構成を示すブロック図である。図１２に示すように、端末４０は、制御部４１０、入力部４２０、通信部４３０、記憶部４４０、出力部４５０を備えている。制御部４１０は、端末４０の動作全体を制御する機能を有しており、操作取得部４１１、送信制御部４１２、取得部４１３、表示制御部４１４を有している。入力部４２０は、端末４０を操作するオペレータからの操作の入力を受け付ける機能を有している。通信部４３０は、サーバ３０と通信を行う機能を有している。記憶部４４０は、端末４０の動作に使用される各種プログラムや各種データを記憶する機能を有している。出力部４５０は、例えば表示装置により構成され、制御部４１０による制御に従って、各種データを出力する機能を有している。

【0062】

操作取得部４１１は、入力部４２０により入力が受け付けられた操作を取得する機能を有する。例えば、操作取得部４１１は、帳票に関する処理を開始する旨を示す処理開始操作を取得した場合には、オペレータＩＤを含んだ送信要求を生成する。オペレータＩＤは、どのように取得されてもよいが、例えば、端末４０の起動時にオペレータから入力されるオペレータＩＤを取得してもよい。

【0063】

送信制御部４１２は、操作取得部４１１により生成された送信要求をサーバ３０に送信するよう通信部４３０を制御する機能を有する。送信制御部４１２による制御にしたがって、通信部４３０により送信要求がサーバ３０に送信される。例えば、送信制御部４１２は、文字データに対する処理が完了した場合には、この文字データに対する処理が完了した旨をサーバ３０に通知してもよい。

【0064】

取得部４１３は、サーバ３０から送信要求に対する応答として文字データを取得する機能を有している。取得部４１３は、例えば、通信部４３０によりサーバ３０から受信された文字データを取得することができる。文字データには、登録日時、画像データなどが関連付けられていてもよい。サーバ３０から取得される複数の文字データは、サーバ３０により特定された同一の分類区分に属している。

【0065】

表示制御部４１４は、取得部４１３により取得された文字データを出力するように表示制御部４１４を制御する機能を有している。オペレータは、出力された文字データに基づいて、文字データに関する処理を行うことができる。例えば、文字データが上記したような「氏名」「生年月日」「住所」「電話番号」「口座番号」「その他」を含んでいる場合に、入力部４２０を介して正しい住所を入力することにより、「住所」を訂正する作業を行うことができる。

【0066】

［動作の説明］
図１３は、本発明の実施形態に係る情報処理システム１により実行される登録処理の流れの一例を示すフローチャートである。図１３を参照しながら、本発明の実施形態に係る情報処理システム１により実行される登録処理の説明を行う。

【0067】

まず、読取装置１０は、顧客等により記入された帳票を読み取る（ステップＳ１１）。認識装置２０は、読取装置１０により読み取られて得られた読取データ（画像データ）からＯＣＲにより文字認識を行う（ステップＳ１２）。文字認識の結果、例えば、認識装置２０は、帳票に含まれる「氏名」「生年月日」「住所」「電話番号」「口座番号」「その他」の各々のフィールドから文字データを認識することができる。

【0068】

認識装置２０は、文字データを含む帳票データをサーバ３０に通知すると、サーバ３０は、認識装置２０から取得した帳票データを帳票データテーブルに登録することができる（ステップＳ１３）。サーバ３０は、取得した帳票データに基づいて帳票データグルーピングテーブルを更新する（ステップＳ１４）。

【0069】

具体的には、サーバ３０は、取得した帳票データの分類区分を判定し、帳票グルーピングテーブルにおいてこの分類区分に一致する「分類区分」が存在する場合には、その「分類区分」に関連付けられている「件数」を１加算し、帳票グルーピングテーブルにおいてこの分類区分に一致する「分類区分」が存在しない場合には、その「分類区分」を追加してその「分類区分」に関連付けられる「件数」に１を設定する。

【0070】

サーバ３０は、帳票グルーピングテーブルを参照して、帳票データが所定数に達したグループ（あるいは分類区分）が存在するか否かを判定する（ステップＳ１５）。サーバ３０は、帳票データが所定数に達したグループが存在しないと判定した場合には（ステップＳ１５で「Ｎｏ」）、ステップＳ１７に進む。サーバ３０は、帳票データが所定数に達したグループが存在すると判定した場合には（ステップＳ１５で「Ｙｅｓ」）、そのグループを閉じて、ステップＳ１７に進む。グループを閉じた場合には、そのグループに属する帳票データは、それ以降増加しない。

【0071】

サーバ３０は、所定時間以上前の帳票データを含むグループが存在するか否かを判定する（ステップＳ１７）。サーバ３０は、所定時間以上前の帳票データを含むグループが存在しないと判定した場合には（ステップＳ１７で「Ｎｏ」）、登録処理を終了する。サーバ３０は、所定時間以上前の帳票データを含むグループが存在すると判定した場合には（ステップＳ１７で「Ｙｅｓ」）、そのグループを閉じて、登録処理を終了する。

【0072】

図１４は、本発明の実施形態に係る情報処理システム１により実行される登録処理の流れの他の一例を示すフローチャートである。図１４を参照しながら、本発明の実施形態に係る情報処理システム１により実行される登録処理の他の一例の説明を行う。

【0073】

図１４に示したステップＳ１１〜ステップＳ１４については、図１３に示したステップＳ１１〜ステップＳ１４と同様に実行され得る。

【0074】

サーバ３０は、帳票グルーピングテーブルを参照して、所定時間が経過した帳票データが属するグループ（あるいは分類区分）が存在するか否かを判定する（ステップＳ２１）。サーバ３０は、所定時間が経過した帳票データが属するグループが存在しないと判定した場合には（ステップＳ２１で「Ｎｏ」）、登録処理を終了する。サーバ３０は、所定時間が経過した帳票データが属するグループが存在すると判定した場合には（ステップＳ２１で「Ｙｅｓ」）、そのグループを閉じて、登録処理を終了する。

【0075】

図１５は、本発明の実施形態に係る情報処理システム１により実行される割り当て処理の流れの一例を示すフローチャートである。図１５を参照しながら、本発明の実施形態に係る情報処理システム１により実行される割り当て処理の一例の説明を行う。

【0076】

まず、サーバ３０は、端末４０から送信要求を取得すると、「状態」が「０：未処理」であり、かつ、「登録日時」が所定時間以上前の帳票データを帳票データテーブルから検索する（ステップＳ３１）。サーバ３０は、該当するデータが存在した場合には（ステップＳ３２で「Ｙｅｓ」）、サーバ３０は、該当データが存在した場合には、該当データをオペレータによる処理対象とし、複数の該当データが存在する場合には、最も古い帳票データをオペレータによる処理対象とする。サーバ３０は、処理対象としたデータが属する分類区分を特定して、ステップＳ３４に進む。

【0077】

サーバ３０は、該当するデータが存在しなかった場合には（ステップＳ３２で「Ｎｏ」）、オペレータが割り当てられておらず、かつ、件数が最も多い分類区分に属するデータを処理対象データとして検索する（ステップＳ３３）。サーバ３０は、帳票データの件数が最も多い分類区分を特定して、ステップＳ３４に進む。なお、件数が最も多い分類区分が複数存在する場合には、登録日時がより古い帳票データが含まれる分類区分を特定する。

【0078】

サーバ３０は、特定した分類区分に関連付けられて帳票グルーピングテーブルに登録されているオペレータＩＤに、送信要求に含まれるオペレータＩＤを設定することにより、帳票グルーピングテーブルを更新する（ステップＳ３４）。サーバ３０は、帳票データテーブルにおいて処理対象データの「状態」に「１：処理中」を設定して、処理対象データを端末４０に通知すると、端末４０は、通知された処理対象データを入力処理の対象とする帳票として表示する（ステップＳ３５）。

【0079】

端末４０は、オペレータによる操作に基づいて、表示した帳票に関する入力処理を行う（ステップＳ３６）。この入力処理が完了すると、この帳票に関する入力処理が完了した旨がサーバ３０に通知され、サーバ３０は、帳票データテーブルにおいてこの帳票データに関連する「状態」に「２：処理済み」を設定し、帳票グルーピングテーブルにおいてこの帳票データが属する分類区分の「件数」から１減算することにより、帳票グルーピングテーブルを更新する（ステップＳ３７）。

【0080】

サーバ３０は、特定した分類区分に属し、かつ、オペレータによる入力処理が完了していない帳票データを処理対象データとして検索する（ステップＳ３８）。サーバ３０は、処理対象データが存在すると判定した場合は（ステップＳ３９で「Ｙｅｓ」）、ステップＳ３５に戻り、その処理対象データに関する入力処理を継続する。サーバ３０は、処理対象データが存在しないと判定した場合は（ステップＳ３９で「Ｎｏ」）、割り当て処理を終了する。

【0081】

以上説明したように、本発明の実施形態によれば、内容が類似している複数の文字データに対する作業を同一のオペレータに割り当てることが可能となる。したがって、オペレータは、類似の文字データに関する処理（入力処理等）を連続して行うことができるため、処理効率を向上させることができる。

【0082】

［変形例の説明］
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

【0083】

例えば、本実施形態においては、通信部３３０および通信部４３０における通信は、どのような通信手段により行われてもよい。例えば、通信部３３０および通信部４３０における通信は、Ｂｌｕｅｔｏｏｔｈ、ＺｉｇＢｅｅ、無線ＬＡＮなどの無線通信により行われてもよく、ケーブル接続による有線通信により行われてもよい。

【0084】

記憶部３４０および記憶部４４０などは、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの不揮発性メモリなどにより構成され得る。制御部３１０および制御部４１０などは、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などから構成され、記憶部３４０および記憶部４４０により記憶されているプログラムがＣＰＵによりＲＡＭに展開されて実行されることにより、その機能が実現され得る。

【0085】

尚、本明細書において、フローチャートに記述されたステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的に又は個別的に実行される処理をも含む。また時系列的に処理されるステップでも、場合によっては適宜順序を変更することが可能であることは言うまでもない。

【符号の説明】

【0086】

１ 情報処理システム
１０ 読取装置
２０ 認識装置
３０ サーバ
４０ 端末
５０ 集線装置
３１０ 制御部
３１１ 判定部
３１２ 計測部
３１３ 特定部
３１４ 通知部
３３０ 通信部
３４０ 記憶部
４１０ 制御部
４１１ 操作取得部
４１２ 送信制御部
４１３ 取得部
４１４ 表示制御部
４２０ 入力部
４３０ 通信部
４４０ 記憶部
４５０ 出力部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】