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

Description

本発明は、情報処理装置、情報処理方法及びそのプログラムに関し、特に、複数の個別文書の画像データと、共通文書の画像データとをまとめて取得した際に、各個別文書に共通文書を容易に関連付けることが可能な仕組みに関する。

従来、保険の申込手続において、被保険者は、申込書に名前などの必要事項を記入して、申込を行っている。このとき、申込書に、保険の内容が記載されている場合もあるが、別紙に保険の内容が記載されている場合もある。また、保険の申込をするために申込書に添付しなければならない添付書類なども必要となる場合がある。

また、例えば、同一の申込者が保険の一括申込を行う場合、複数の申込書（以下、個別文書）に対し、身分証明書等の共通の添付書類（以下、共通文書）を添付する場合がある。

保険会社の社員（ユーザ）は、共通文書と複数の個別文書をスキャナでまとめてスキャンして、１つのファイルとして登録し、そのファイルを検索し、閲覧して、その内容を確認する業務を行っている。

特許文献１には、スキャナでスキャンする文書の先頭に、生成されるファイルのファイル名の付け方、生成されるファイルのファイル形式の種類、生成されるファイルの格納先が指示されている指示シートを挿入して、その指示シートの内容に従って、指示シートの後にスキャンされる文書に対する処理内容を決定することが記載されている。

特開２００５−２１０５６３号公報

しかしながら、特許文献１の技術では、１回のスキャンで複数の個別文書のデータと共通文書のデータとを１つのファイルとして登録し、ユーザに確認させるためには、生成したいファイルの数だけ、上記指示シート及び当該個別文書と共通文書を用意してスキャン処理をさせる必要があり、非常に手間である。

本発明は、複数の個別文書の画像データと、共通文書の画像データとをまとめて取得した際に、各個別文書に共通文書を容易に関連付けることが可能な仕組みを提供することである。

本発明は、個別のファイルとして生成すべき個別文書であって、当該個別文書を識別するための識別情報を含む１つ又は複数の個別文書の画像データ、前記個別文書と関連付けるべき共通文書であって、前記識別情報を含まない共通文書の画像データの順に、複数の画像データを取得する取得手段と、前記取得手段で取得した画像データが、前記個別文書であるか、前記共通文書かを、前記識別情報を用いて判定する判定手段と、前記判定手段で、前記取得した画像データが前記個別文書であると判定した場合に、当該取得した個別文書である第１の個別文書の直前の、前記判定手段で前記共通文書と判定された前記共通文書の画像データと、当該共通文書の前に前記取得手段で取得され、前記判定手段で個別文書であると判定された第２の個別文書の画像データとを関連付ける第１の関連付け手段と、前記第２の個別文書が連続しているかを判定する連続判定手段と、を備え、前記第１の関連付け手段は、前記第２の個別文書が連続していると判定された場合、当該連続している第２の個別文書の画像データのそれぞれに、前記第１の個別文書の直前の前記共通文書の画像データを関連付けることを特徴とする。

また、本発明は、個別のファイルとして生成すべき個別文書であって、当該個別文書を識別するための識別情報を含む１つ又は複数の個別文書の画像データ、前記個別文書と関連付けるべき共通文書であって、前記識別情報を含まない共通文書の画像データの順に、複数の画像データを取得する取得工程と、前記取得工程で取得した画像データが、前記個別文書であるか、前記共通文書かを、前記識別情報を用いて判定する判定工程と、前記判定工程で、前記取得した画像データが前記個別文書であると判定した場合に、当該取得した個別文書である第１の個別文書の直前の、前記判定工程で前記共通文書と判定された前記共通文書の画像データと、当該共通文書の前に前記取得工程で取得され、前記判定工程で個別文書であると判定された第２の個別文書の画像データとを関連付ける第１の関連付け工程と、前記第２の個別文書が連続しているかを判定する連続判定工程と、を含み、前記第１の関連付け工程は、前記第２の個別文書が連続していると判定された場合、当該連続している第２の個別文書の画像データのそれぞれに、前記第１の個別文書の直前の前記共通文書の画像データを関連付けることを特徴とする。また、本発明は、情報処理装置を、個別のファイルとして生成すべき個別文書であって、当該個別文書を識別するための識別情報を含む１つ又は複数の個別文書の画像データ、前記個別文書と関連付けるべき共通文書であって、前記識別情報を含まない共通文書の画像データの順に、複数の画像データを取得する取得手段と、前記取得手段で取得した画像データが、前記個別文書であるか、前記共通文書かを、前記識別情報を用いて判定する判定手段と、前記判定手段で、前記取得した画像データが前記個別文書であると判定した場合に、当該取得した個別文書である第１の個別文書の直前の、前記判定手段で前記共通文書と判定された前記共通文書の画像データと、当該共通文書の前に前記取得手段で取得され、前記判定手段で個別文書であると判定された第２の個別文書の画像データとを関連付ける第１の関連付け手段と、前記第２の個別文書が連続しているかを判定する連続判定手段として機能させ、前記第１の関連付け手段は、前記第２の個別文書が連続していると判定された場合、当該連続している第２の個別文書の画像データのそれぞれに、前記第１の個別文書の直前の前記共通文書の画像データを関連付けることを特徴とする。

本発明によれば、複数の個別文書の画像データと、共通文書の画像データとをまとめて取得した際に、各個別文書に共通文書を容易に関連付けることができる。

本発明の第１の実施形態に係る情報処理システムの構成を示す図である。 図１に示したクライアント端末１０４の基本構成を示すブロック図である。 被保険者の保険申込書（個別文書）の印刷処理を示すフローチャートである。 被保険者の保険申込書（個別文書）、添付書類（共通文書）などの文書の電子データをファイリングサーバ１０２に登録する処理の一例を示すフローチャートである。 図４に示すステップＳ４０７（個別文書の識別情報を用いた結合処理）の詳細処理の一例を示すフローチャートである。 個別文書と共通文書の結合処理の詳細を示すフローチャートである。 図４に示すステップＳ４０８（通常の結合処理）の詳細処理の一例を示すフローチャートである。 図４に示すステップＳ４１２（イメージ登録処理）の詳細処理の一例を示すフローチャートである。 登録保留されたファイルの登録・削除処理の一例を示すフローチャートである。 ファイリングサーバ１０２の登録文書テーブル（図１３）に登録されているファイルの検索、閲覧処理の一例を示すフローチャートである。 図３で被保険者の保険申込書に印刷された申込番号の、属性情報連携ファイル（図１１）のレコードの情報を、ファイリングサーバ１０２の記憶部に記憶されている属性情報テーブルに登録する処理の一例を示すフローチャートである。 属性情報連携ファイルの一例を示す図である。 属性情報テーブルの一例を示す図である。 登録文書テーブルの一例を示す図である。 スキャン取込指示受付画面の一例を示す図である。 スキャン取込結果画面の一例を示す図である。 ステップＳ４１３で表示されるエラーメッセージ画面の一例である。 登録保留のデータ一覧画面の一例を示す図である。 登録・削除画面の一例を示す図である。 ステップＳ８１２で表示されるエラーメッセージ画面の一例を示す図である。 検索条件入力画面の一例を示す図である。 検索結果表示画面の一例を示す図である。 複数の個別文書、共通文書から、複数のファイル（共通文書と個別文書とが結合されたファイル）をそれぞれ生成することを説明するための図である。 第２の実施の形態における登録文書テーブルの一例を示す図である。 第２の実施の形態における図４に示すステップＳ４１２（イメージ登録処理）の詳細処理の一例を示すフローチャートである。 第２の実施の形態における、登録保留されたファイルの登録・削除処理の一例を示すフローチャートである。 図２５に示すステップＳ２５２０（登録保留データ削除処理）の詳細処理の一例を示すフローチャートである。 第２の実施の形態における、ファイリングサーバ１０２の登録文書テーブルに登録されているファイルの検索・閲覧処理の一例を示すフローチャートである。 第３の実施の形態における、図４に示すステップＳ４０７（個別文書の識別情報を用いた結合処理）の詳細処理の一例を示すフローチャートである。 図２８のステップＳ２８２１の個別文書データ登録処理の詳細を示すフローチャートである。 スキャン取込結果画面の一例を示す図である。 未結合の個別文書のファイルと共通文書のファイルを結合するための画面の一例を示す図である。 複数の個別文書、共通文書から、複数のファイル（共通文書と個別文書とが結合されたファイルと、個別文書だけのファイル）をそれぞれ生成することを説明するための図である。

以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。

［第１の実施の形態］

図１は、本発明の第１の実施形態に係る情報処理システムの構成を示す図である。ホストコンピュータ１０１、ファイリングサーバ１０２、プリンタ１０３、クライアント端末１０４、クライアント端末１０６は、それぞれネットワーク１０７を介して、相互に通信可能に接続されている。また、クライアント端末１０４は、スキャナ１０５と通信可能に接続されている。スキャナ１０５は、文書を読み取り該文書の画像データを生成する読取装置の適用例である。

ホストコンピュータ１０１は、属性情報連携ファイル（図１１）を記憶しており、属性情報連携ファイルに記憶されている情報に従って、後述する被保険者の保険申込書（被保険者名簿とも言う）のデータをプリンタ１０３に印刷出力する機能を備えている。被保険者の保険申込書（被保険者名簿）は、後述する個別文書（用紙）である。ここで印刷される個別文書には、属性情報連携ファイル（図１１）に記憶されている申込番号が印字される。個別文書毎に、異なる申込番号が印字されるため、申込番号から個別文書を特定することが可能となる。このように、申込番号は、個別文書を識別する識別情報として用いられる。

個別文書は、例えば、被保険者の保険申込書であって、被保険者が保険の申込を行うために、被保険者の署名、捺印等を行う用紙である。本実施の形態では、１枚の個別文書を、１人の被保険者の保険の申込を行う用紙として説明する。また、当該個別文書には、当該個別文書の識別情報である申込み番号が埋め込まれたＱＲコード（「ＱＲコード」は、登録商標）等の二次元コードが印刷されているものとする。

また、ホストコンピュータ１０１は、記憶部に記憶している申込書（個別文書）２２０１、及び添付書類（共通文書）２２０２のデータをプリンタ１０３に印刷出力する機能を備えている。申込書（個別文書）は、保険の契約を締結するための各申込者の個別の文書である。添付書類は、複数の申込書に共通して添付される共通文書であって、１枚又は複数枚の用紙で構成される。

また、ホストコンピュータ１０１は、プリンタ１０３から印刷出力された個別文書に印刷されたＱＲコード（申込番号、及びその申込番号に関連した情報（証券番号））の情報を、属性情報連携ファイル（図１１）から取得して、ファイリングサーバ１０２の記憶部に記憶されている属性情報テーブル（図１２）に対して登録する要求を、夜間バッチ処理などで、送信する機能を備えている。

図１２は、属性情報テーブルの一例を示す図である。属性情報テーブル（図１２）には、個別申込書に印刷された申込番号と、当該申込番号が印刷された個別申込書に印刷された証券番号とが記憶されている。

クライアント端末１０４は、ユーザの操作に従って読み取り指示を受け付けると、スキャナ１０５に読取要求を送信する機能を備えている。読取要求を受信したスキャナ１０５は、スキャナ１０５のオートドキュメントフィーダ（ＡＤＦ）にセットされた用紙を読み込み、用紙を電子化して得られたデータを、クライアント端末１０４に送信する機能を備えている。（ここでは、用紙１枚につき、１つのファイル（データ）を生成して、クライアント端末１０４に送信する。）

そして、クライアント端末１０４は、スキャナ１０５から送信されてきたデータ（複数のファイル）を受信すると、当該データを解析して、個別文書毎に、共通文書を結合して、個別文書と共通文書のペア（組み合わせ）とする１つのファイルを生成する機能を備えている。

また、クライアント端末１０４は、個別文書毎に、共通文書を結合して生成された、個別文書毎の当該ファイルをファイリングサーバ１０２に送信して、当該ファイルの登録要求を行う機能を備えている。

ファイリングサーバ１０２は、クライアント端末１０４から登録要求を受信すると、当該登録要求に含まれているファイルを、ファイリングサーバ１０２の記憶部に記憶する機能を備えている。クライアント端末１０６は、ファイリングサーバ１０２の記憶部に記憶されているファイルを取得して表示部に表示する機能を備えている。

次に、図２２を用いて、後述する、複数の個別文書、共通文書から、複数のファイル（共通文書と個別文書とが結合されたファイル）をそれぞれ生成することを説明する。

図２２は、複数の個別文書、共通文書から、複数のファイル（共通文書と個別文書とが結合されたファイル）をそれぞれ生成することを説明するための図である。

個別文書２２０１、個別文書２２０２、共通文書２２０３、個別文書２２０４、共通文書２２０５の順番で、スキャナでスキャンされ、スキャンされたそれぞれの文書の画像データのファイル（１ページ１ファイルの画像データ）を、スキャナ１０５から順番に、クライアント端末１０４は取得する。

後述するステップＳ４０７では、個別文書２２０１と、共通文書２２０３を含むファイルＡ、個別文書２２０２と、共通文書２２０３を含むファイルＢ、個別文書２２０４と、共通文書２２０５を含むファイルＣ、をそれぞれ生成する。

すなわち、クライアント端末１０４は、ある個別文書が読み込まれた後、次の個別文書が読み込まれるまで、又は全ての画像ファイルの読込みが終了するまでに読み込まれた、ＱＲコード（申込番号が埋め込まれた二次元コード）を含まない文書を共通文書として特定する。そして、当該共通文書が読み込まれる前に連続して読み込まれた個別文書（例えば、個別文書２２０１、２２０２）の数だけ、当該共通文書をコピーして、それぞれの個別文書と結合したファイルＡ、ファイルＢを生成する。

図２は、図１に示したクライアント端末１０４の基本構成を示すブロック図である。図２において、２０１はＣＰＵであり、ＲＡＭ２０２やＲＯＭ２０３に格納されているプログラムやデータを用いてクライアント端末１０４全体の制御を行うと共に、クライアント端末１０４が行う後述の各処理を実行する。

２０２はＲＡＭであり、ＨＤＤ２０４や記録媒体ドライブ２０６からロードされたプログラムやデータ、ネットワークＩ／Ｆ（インターフェース）２０５を介して受信したデータを一時的に記憶するためのエリアを備えると共に、ＣＰＵ２０１が各種の処理を実行する際に使用するワークエリアを備える。

２０３はＲＯＭであり、クライアント端末１０４の設定データやブートプログラムなどを格納する。

２０４はＨＤＤであり、ここにＯＳ（オペレーティングシステム）や、クライアント端末１０４が行う後述の各処理をＣＰＵ２０１に実行させるためのプログラムやデータが保存されている。これらのプログラムやデータの一部もしくは全部はＣＰＵ２０１による制御に従ってＲＡＭ２０２にロードされ、これを用いてＣＰＵ２０１が処理を行うことで、クライアント端末１０４は以下説明する各処理を実行することになる。

２０５はネットワークＩ／Ｆで、クライアント端末１０４をネットワーク１０７に接続するためのものであり、このネットワークＩ／Ｆ２０５を介してクライアント端末１０４は外部機器とデータ通信を行うことができる。

２０６は記録媒体ドライブであり、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／ＲＷ、ＤＶＤ―ＲＯＭ、ＤＶＤ−Ｒ／ＲＷ、ＤＶＤ−ＲＡＭ等の記憶媒体に記録されたプログラムやデータを読み出し、ＲＡＭ２０２に出力する。この読み出し動作はＣＰＵ２０１によって制御される。

２０７はキーボードであり、各種の指示をＣＰＵ２０１に対して入力することができる。２０８はマウス等のポインティングデバイスであり、各種の指示をＣＰＵ２０１に対して入力することができる。

２０９はビデオＩ／Ｆ（インターフェース）であり、ディスプレイ装置２１０に表示すべき画像を信号としてディスプレイ装置２１０に供給するためのＩ／Ｆとして機能するものである。

２１０はディスプレイ装置であり、ＣＲＴや液晶画面等により構成されており、ＣＰＵ２０１による処理結果を画像や文字等でもって表示することができる。

２１１は周辺機器Ｉ／Ｆであり、ＵＳＢポートやＩＥＥＥ１３９４ポート等によって構成されており、この周辺機器Ｉ／Ｆ２１１を介して周辺機器との接続することが可能である。周辺機器との接続形態は有線／無線を問わない。２１２は上述の各部を繋ぐバスである。

また、図２に示す構成は、ホストコンピュータ１０１、ファイリングサーバ１０２、クライアント端末１０６についても同様の構成であるため、ホストコンピュータ１０１、ファイリングサーバ１０２、クライアント端末１０６のブロック図の説明は省略する。

次に、図３を用いて、被保険者の保険申込書（個別文書）の印刷処理について説明する。図３は、被保険者の保険申込書（個別文書）の印刷処理を示すフローチャートである。図３に示す各ステップの処理は、ホストコンピュータ１０１のＣＰＵ２０１により実行される。

ホストコンピュータ１０１は、記憶部に記憶されている属性情報連携ファイル（図１１）を取得して、属性情報連携ファイル（図１１）のレコード毎の申込番号を取得する（ステップＳ３０１）。

図１１は、属性情報連携ファイルの一例を示す図である。属性情報連携ファイルは、「証券番号」、「申込番号」とから構成されており、「証券番号」は、契約内容を一意に識別するための番号であり、「申込番号」は申込手続（申込の案件）を一意に識別するための番号である。

次に、ホストコンピュータ１０１は、ステップＳ３０１で取得した申込番号を埋め込んだＱＲコードを生成して、当該ＱＲコードを記憶部に記憶されている被保険者の保険申込書（個別文書）のテンプレートの所定の位置にオーバーレイして、ステップＳ３０１で取得したレコードの申込番号ごとに、該申込番号を含む個別文書の印刷データをそれぞれ生成し（ステップＳ３０２）、プリンタ１０３に送信（出力）して印刷要求を行う（ステップＳ３０３）。例えば、図１１に示す属性情報連携ファイルの各レコードには、申込番号として「００１」と、「００２」とが記憶されている。

ステップＳ３０１では、「００１」と「００２」とを取得して、ステップＳ３０２で、被保険者の保険申込書（個別文書）のテンプレートの所定の位置に「００１」の情報を含めたＱＲコードを付加して１つの個別文書の印刷データを生成する。また、ステップＳ３０２では、被保険者の保険申込書（個別文書）のテンプレートの所定の位置に「００２」の情報を含めたＱＲコードを付加して１つの個別文書の印刷データを生成する。

このようにして生成された２つの個別文書の印刷データを、ステップＳ３０３でプリンタ１０３に送信して、２つの個別文書の印刷を行う。プリンタ１０３は、ホストコンピュータ１０１から受信した印刷要求に含まれる２つの個別文書の印刷データに従って、２枚の個別文書の印刷を行う。このようにして印刷された個別文書には、被保険者の署名欄、捺印欄などが含まれており、被保険者により署名、捺印がなされることとなる。

次に、図１０を用いて、図３で被保険者の保険申込書に印刷されたＱＲコードの示す申込番号の、属性情報連携ファイル（図１１）のレコードの情報を、ファイリングサーバ１０２の記憶部に記憶されている属性情報テーブルに登録する処理について説明する。

図１０は、図３で被保険者の保険申込書に印刷された申込番号の、属性情報連携ファイル（図１１）のレコードの情報を、ファイリングサーバ１０２の記憶部に記憶されている属性情報テーブルに登録する処理の一例を示すフローチャートである。図１０に示すＳ１００１、Ｓ１００２のステップの処理は、ホストコンピュータ１０１のＣＰＵ２０１により実行される。また、図１０に示すＳ１００３、Ｓ１００４のステップの処理は、ファイリングサーバ１０２のＣＰＵ２０１により実行される。

ホストコンピュータ１０１は、現在の日時が所定の日時であるか否かを判定し（ステップＳ１００１）、所定の日時であると判定された場合は（Ｓ１００１：ＹＥＳ）、図３で被保険者の保険申込書に印刷済みのＱＲコードの示す申込番号の、属性情報連携ファイル（図１１）のレコードの情報を、ファイリングサーバ１０２に送信する（ステップＳ１００２）。

そして、ファイリングサーバ１０２は、ホストコンピュータ１０１から、該レコードの情報を受信すると（ステップＳ１００３）、当該情報を、ファイリングサーバ１０２の記憶部に記憶されている属性情報テーブルに登録する（ステップＳ１００４）。

次に、図４を用いて、被保険者の保険申込書（個別文書）、契約一括申込書（共通文書）など文書をスキャナ１０５が読み取ることで得られる文書の電子データを、ファイリングサーバ１０２に登録する処理について説明する。

図４は、被保険者の保険申込書（個別文書）、添付書類（共通文書）などの文書の電子データをファイリングサーバ１０２に登録する処理の一例を示すフローチャートである。図４に示す各ステップの処理は、クライアント端末１０４のＣＰＵ２０１により実行される。

クライアント端末１０４は、まず、図１４に示すスキャン取込指示受付画面を表示する。

図１４は、スキャン取込指示受付画面の一例を示す図である。図中、１４０１は、ユーザの操作によるセット件数の入力を受け付ける入力欄である。１４０２は、ユーザの操作による文書種類（文書種別）の選択入力を受け付けるプルダウンである。１４０３は、スキャン開始をスキャナ１０５に指示するためのスキャン開始ボタンである。ここで、セット件数とは、共通文書と個別文書とから構成されるファイルの数（個別文書の数）のことを示している。

ユーザは、スキャナ１０５のＡＤＦにセットした個別文書の数を確認して、スキャン取込指示受付画面（図１４）のセット件数１４０１に入力する。また、１４０２で選択可能な文書種類は、例えば、「申込書」と「明細書」とがあるものとして説明する。

「申込書」は、後述するステップＳ４０７で個別文書の識別情報（個別文書と共通文書の結合に用いる情報であるＱＲコードの示す申込番号）を用いて個別文書と共通文書の結合処理を行う文書種類であり、「明細書」は、後述するステップＳ４０７でセパレータを用いることなく、通常の結合処理を行う文書種類である。すなわち、図１４の１４０２で文書種類を選択することで、ステップＳ４０７で個別文書の識別情報（個別文書と共通文書の結合に用いる情報であるＱＲコードの示す申込番号）を用いて結合処理を行うか、ステップＳ４０７でセパレータを用いることなく通常の結合処理を行うかの設定を入力することを意味している。

クライアント端末１０４は、スキャン取込指示受付画面（図１４）を介して、ユーザの操作により、セット件数の入力、及び、文書種類の入力を受け付け（ステップＳ４０２／セット件数入力受付手段、種別入力受付手段）、スキャン開始ボタン１４０３が押下されると（ステップＳ４０３：ＹＥＳ）、処理をステップＳ４０４に移行する。また、クライアント端末１０４は、スキャン開始ボタン１４０３が押下されるまで（ステップＳ４０３：ＮＯ）、スキャン取込指示受付画面（図１４）を表示して、セット件数の入力、及び、文書種類の入力を受け付ける。このように、ステップＳ４０２では、ユーザの操作による個別文書のデータ数の入力を受け付ける（入力受付手段）。

そして、クライアント端末１０４は、スキャン開始ボタン１４０３が押下されると、スキャナ１０５に、スキャナ１０５のＡＤＦにセットされた文書の読取要求を送信する（ステップＳ４０４）。

スキャナ１０５は、読取要求をクライアント端末１０４から受信すると、スキャナ１０５のＡＤＦにセットされた文書の読取処理を実行し、読み取られたデータを読取結果としてクライアント端末１０４に送信する。ここで送信されるデータは、１文書の１ページごとの１つのファイル（本実施形態では、当該ファイルのことを画像データともいう）である。すなわち、複数ページを読み取った場合は、複数のファイル（画像データ）が送信されることとなる。

そして、クライアント端末１０４は、スキャナ１０５から、読取結果としてスキャナ１０５で読み取られたデータを受信（取得）する（ステップＳ４０５）。ステップＳ４０５では、複数ページを読み取った場合は、複数のファイル（画像データ）を取得する。

ここでは、例えば、図２２に説明したように、個別文書２２０１、２２０２、共通文書２２０３、個別文書２２０４、共通文書２２０５の順番で、スキャナ１０５から、それぞれのファイルを取得するものとする。

クライアント端末１０４は、ステップＳ４０５で入力を受け付けた文書種類（文書種別）が「申込書」であるか、それとも「明細書」であるかを判定する。すなわち、ステップＳ４０７で、個別文書の識別情報を用いた結合処理を行うか、ステップＳ４０８で、個別文書の識別情報を用いることなく通常の結合処理を行うかを判定する（ステップＳ４０６）。

そして、ステップＳ４０５で入力を受け付けた文書種類（文書種別）が「申込書」である（ステップＳ４０６で個別文書の識別情報を用いて結合処理を行う）と判定された場合は（ステップＳ４０６：ＹＥＳ）、処理をステップＳ４０７に移行する。一方、ステップＳ４０５で入力を受け付けた文書種類（文書種別）が「明細書」である（ステップＳ４０８で個別文書の識別情報を用いることなく通常の結合処理を行う）と判定された場合は（ステップＳ４０６：ＮＯ）、処理をステップＳ４０８に移行する。

ステップＳ４０７では、個別文書の識別情報を用いて、個別文書のファイルと共通文書のファイルとを結合して１つのファイルを生成する処理を行い、一方、ステップＳ４０８では、スキャナ１０５から取得した全てのファイルを結合して１つのファイルを生成する処理を行う。ステップＳ４０７の詳細処理を図５に示し、ステップＳ４０８の詳細処理を図６に示す。

次に、図５を用いて、図４に示すステップＳ４０７（個別文書の識別情報を用いた結合処理）の詳細処理について説明する。図５は、図４に示すステップＳ４０７（個別文書の識別情報を用いた結合処理）の詳細処理の一例を示すフローチャートである。図５に示す各ステップの処理は、クライアント端末１０４のＣＰＵ２０１により実行される。

クライアント端末１０４のメモリ（ＲＡＭ２０２）に記憶されている読込中フラグを初期値である「ＯＦＦ」に設定して、図５に示す処理を開始する。また、クライアント端末１０４のメモリに記憶されている登録予定件数を初期値である「０（ゼロ）」に設定して、図５に示す処理を開始する。ここでいう登録予定件数とは、例えば、後述する図１５の１５０２に挿入される件数の値である。つまり、図５の処理を行うことで生成されるファイル数であって、個別文書の数と等しい数となる。

ステップＳ５０１からステップＳ５１５の処理を、ステップＳ５０２で読み込む、ステップＳ４０５で取得した全ての読取結果のファイルに対して繰り返し実行する。

まず、クライアント端末１０４は、ステップＳ４０５で取得した、スキャナ１０５の読取結果のファイルのうち、未処理の先頭のファイルを読み込む（ステップＳ５０２）。ここで読み込んだファイルを処理対象のファイルとして以降の処理を行う。ステップＳ５０１以降の処理は、スキャナ１０５から受信されるファイルの順番で処理対象のファイルにして処理する。

そして、クライアント端末１０４は、ステップＳ５０２で読み込んだファイルの所定の位置から、ＱＲコード、を読み取る処理を行う（ステップＳ５０３）。すなわち、ステップＳ５０３では、ステップＳ５０２で読み込んだファイル（画像データ）から、該画像データの文書が共通文書のデータか、個別文書のデータかを特定するための情報（個別文書の申込番号）をＱＲコードから読み取る。

次に、クライアント端末１０４は、当該ＱＲコードから読み取った情報が、申込番号であるか否かを判定する。当該申込番号か否かの判定は、属性情報連携ファイルの申込番号の項に、一致する申込番号が存在するか否かを以って判定する。

属性情報連携ファイルの申込番号の項に、一致する申込番号が存在する場合（ステップＳ５０４：ＹＥＳ）、処理をステップＳ５０５に移行し、属性情報連携ファイルの申込番号の項に、一致する申込番号が存在しない場合（ステップＳ５０４：ＮＯ）、処理をステップＳ５０８に移行する。

クライアント端末１０４は、ステップＳ５０５で、クライアント端末１０４のメモリに記憶されている読込中フラグが「ＯＮ」に設定されているか否かを判定する（ステップＳ５０５）。また、読込中フラグが「ＯＮ」の場合、処理中のファイルがステップＳ５０２で最初に読み取ったファイルか（先頭の用紙としてスキャンされた原稿か）判定する（ステップＳ５２２）。

すなわち、ステップＳ５０５及びＳ５２２では、現在処理中のファイルの直前までに読み取られた共通文書のファイル（ＱＲコード（申込番号）のないファイル）を、当該共通文書のファイルの前に読み取られた個別文書のファイルと結合する処理（ステップＳ５０６）を行うか否かを決定する。ステップＳステップＳ５０６の処理の詳細については、図５Ａの説明で後述する。

また、読込中フラグが「ＯＮ」である＝直前に読み込んだファイルが個別文書であることを示す。つまり、ステップＳ５０５は、個別文書が連続しているか判定している（連続判定手段）。

すなわち、読込中フラグが「ＯＦＦ」であって、且つ、処理中のファイルが２枚目以降のファイルであると判定された場合の現在処理対象のファイルを、共通文書の後に読み取られた個別文書のデータとして特定する。また、読込中フラグが「ＯＮ」であって、且つ、処理中のファイルが２枚目以降のファイルであると判定された場合の現在処理対象のファイルを、個別文書の後に読み取られた個別文書（図２２でいう個別文書２２０２）のデータとして特定する。

また、読込中フラグが「ＯＦＦ」であって、且つ、処理中のファイルが１枚目のファイルであると判定された場合の現在処理対象のファイルを、最初に読み取られた個別文書のデータとして特定する。

次に、クライアント端末１０４は、読込中フラグが「ＯＮ」に設定されていると判定された場合（ステップＳ５０５：ＮＯ）、又は、当該込中フラグが「ＯＦＦ」であって且つ当該処理中のファイルが最初のファイルであると判定した場合（ステップＳ５２２：ＹＥＳ）、ステップＳ５０３で読み取ったＱＲコードから取得した申込番号を外部メモリに記憶する（ステップＳ５０７）。

そして、当該処理中のファイルを、後に共通文書と結合する個別ファイルとして外部メモリに記憶し（ステップＳ５１０）、登録予定件数の値を１つカウントアップする（ステップＳ５１１）。また、連続して読み込んだ個別文書の数を示すＱＲコード件数を１つカウントアップして（ステップＳ５１２）、読込中フラグを「ＯＮ」に設定する（ステップＳ５１３）。

また、クライアント端末１０４は、ステップＳ５０８で、読み込んだファイルが先頭のファイル（先頭の原稿としてスキャンされた画像ファイル）か判定する。先頭のファイルである場合（ステップＳ５０８：ＹＥＳ）、申込番号＝「ＮＵＬＬ」の値を、外部メモリに記憶する（ステップＳ５０９）。

読み込んだファイルが先頭のファイルである場合（ステップＳ５０８：ＮＯ）、当該処理中のファイルを共通文書として特定し、処理中のファイルの直前に処理したファイルが共通文書であるか判定する（ステップＳ５１４）。つまり、当該処理中のファイル（共通文書）の直前に別の共通文書が存在するか判定する。

直前に共通文書が存在しない場合（ステップＳ５１４：ＮＯ）、現在処理対象のファイルを共通文書の画像ファイルとしてメモリに記憶する（ステップＳ５１５）。

一方、処理中の共通文書のファイルの直前に共通文書が存在する場合（ステップＳ５１４：ＹＥＳ）、メモリに既に記憶されている直前の共通文書のファイルと、現在、処理対象のファイルを結合して１つの画像ファイルとして生成し、当該生成されたファイルを、共通文書のファイルとしてメモリに記憶する（ステップＳ５１６）。

すなわち、ステップＳ５１５、ステップＳ５１６では、処理中の共通文書よりも前の画像データを共通文書のデータとして特定する処理である。クライアント端末１０４は、ステップＳ５１３、ステップＳ５１４の処理を実行すると、処理をステップＳ５１７に移行し、読込中フラグを「ＯＦＦ」に設定する。つまり、処理した文書が共通文書であったことを示す情報を記憶する。

ここで図５Ａを参照して、本発明の実施形態における、個別文書と共通文書の結合処理の詳細について説明する。図５Ａは、本発明の実施形態における、個別文書と共通文書の結合処理の詳細を示すフローチャートである。当該図５Ａの処理は、図５のステップＳ５０６及び後述するステップＳ５１９の詳細を示す処理である。

クライアント端末１０４は、ステップＳ５１２でカウントアップしたＱＲコード件数分、ステップＳ５３２〜Ｓ５３５の処理を繰り返す。クライアント端末１０４は、ステップＳ５１０で外部メモリに記憶した個別文書のファイルであって、ステップＳ５０２で未取得（共通文書と未結合）の個別文書のファイルを１つ取得する（ステップＳ５３２）。そして、当該図５Ａの処理（図５のステップＳ５０６の処理）の開始時点で処理中のファイルの直前に記憶された、共通文書のファイル（ステップＳ５１５で記憶されたファイル、又はステップＳ５１６で結合されて生成されたファイル）を取得する（ステップＳ５３３）。

クライアント端末１０４は、ステップＳ５３２で取得した個別文書のファイルと、ステップＳ５３３で取得した共通文書のファイルを結合して１つの保険申し込み案件のファイルとして生成し（ステップＳ５３４）、クライアント端末１０４の外部メモリに、ステップＳ５０７でメモリに記憶された申込番号と対応付けて記憶する（ステップＳ５３５）。

そして、当該ステップＳ５３２〜Ｓ５３５の処理をＱＲコード件数分繰り返した後、当該ＱＲコード件数の値を「０」に更新し、処理を終了する。以上が図５Ａの説明である。

ステップＳ５１８では、メモリに記憶されている読込中フラグが「ＯＮ」に設定されているか否かを判定する。そして、クライアント端末１０４は、読込中フラグが「ＯＮ」に設定されていないと判定された場合は（ステップＳ５１８：ＮＯ）、図５Ａに示す個別文書と共通文書のファイルの結合処理を行う（ステップＳ５１９）。つまり、ステップＳ５０２で全てのファイルを読み込んだ場合に、最後に生成した（ステップＳ５１５又はステップＳ５１６）共通文書のファイルと、当該共通文書の前に記憶された（ステップＳ５１０）、共通文書と未結合の個別文書のファイルと、の結合処理を行う。そして、スキャンしたデータの認識に成功したことを示す情報をメモリに記憶して（ステップＳ５２０）、処理を終了する。

また、クライアント端末１０４は、読込中が「ＯＮ」に設定されていると判定された場合は（ステップＳ５１８：ＹＥＳ）、スキャンしたデータを認識できなかったことを示す情報をメモリに記憶して（ステップＳ５２１）、処理を図４のステップＳ４０９に移行する。以上の処理を行うことにより、個別文書ごとに、該個別文書と共通文書とが結合されたファイルをそれぞれ生成することが可能となる。つまり、複数の個別文書と、共通文書をまとめて取得することで、当該個別文書と共通文書の組み合わせのデータを複数生成することができる仕組みを提供することができる。

次に、図６を用いて、図４に示すステップＳ４０８（通常の結合処理）の詳細処理について説明する。図６は、図４に示すステップＳ４０８（通常の結合処理）の詳細処理の一例を示すフローチャートである。図６に示す各ステップの処理は、クライアント端末１０４のＣＰＵ２０１により実行される。

クライアント端末１０４のメモリに記憶されている登録予定件数を初期値である「０（ゼロ）」に設定して、図６に示す処理を開始する。

ステップＳ６０１からステップＳ６１０の処理を、ステップＳ４０５で取得した全ての読取結果のファイルをステップＳ６０２で全て読込むまで、繰り返し実行する。尚、ステップＳ６０１以降の処理は、スキャナ１０５から受信されるファイルの順番で処理対象のファイルにして処理する。

まず、クライアント端末１０４は、ステップＳ４０５で取得した、スキャナ１０５の読取結果のファイルのうち、未処理の先頭のファイルを読み込む（ステップＳ６０２）。ここで読み込んだファイルを処理対象のファイルとして以降の処理を行う。そして、クライアント端末１０４は、ステップＳ６０２で読み込んだファイルの所定の位置のＱＲコードから、申込番号を読み取る処理を行う（ステップＳ６０３）。

次に、クライアント端末１０４は、ステップＳ６０３で申込番号を読み取ることが出来たか否かを判定する（ステップＳ６０４）。すなわち、ステップＳ６０４では、申込番号を読み取ることが出来たか否かを判定することにより、現在、処理対象のファイルが共通文書であるか、個別文書であるかを判定している。

ステップＳ６０４で、申込番号を読み取ることが出来なかったと判定された場合は（ＮＯ）、ステップＳ６０４で読み込んだ現在処理対象のファイルが先頭のファイルであるか否かを判定する（ステップＳ６０６）。

そして、ステップＳ６０６で、現在処理対象のファイルが先頭のファイルであると判定された場合は（ＹＥＳ）、処理をステップＳ６０７に移行し、一方、現在処理対象のファイルが先頭のファイルではないと判定された場合は（ＮＯ）、処理をステップＳ６０９に移行する。

ステップＳ６０４において、申込番号を読み取ることが出来たと判定された場合は（ＹＥＳ）、ステップＳ６０３で読み取られた申込番号をメモリに記憶する（ステップＳ６０５）。

そして、ステップＳ６０５において、クライアント端末１０４は、メモリに記憶されている登録予定件数に１を加算する。なお、メモリに記憶されている登録予定件数の初期値は０である。

次に、クライアント端末１０４は、現在、処理対象のファイルを先頭のファイルとしてメモリに登録する（ステップＳ６０８）。すなわち、ステップＳ６０８では、ステップＳ６０４で、申込番号を読み取ることが出来たと判定された場合、ステップＳ６０３で読み取られた申込番号と、現在処理対象のファイルとを紐付けて（関連付けて）メモリに登録する。

ステップＳ６０９では、現在、処理対象のファイルと、既に、メモリに先頭のファイルとして登録されているファイルとを結合して、１つのファイルを生成する。そして、当該生成されたファイルを先頭のファイルとして、メモリに記憶する。ステップＳ６０９の処理を実行すると、処理をステップＳ６１０に移行する。

ステップＳ６０４において、申込番号の読取ができたと判定され、現在処理対象のファイルが個別文書であると判定された場合は（ＹＥＳ）、処理をステップＳ６０５に移行している。この場合、ステップＳ６０８では、既にメモリに先頭のファイルとして記憶されているファイルと、現在処理対象のファイルとを結合して、１つのファイルを生成し、メモリに先頭のファイルのとして記憶（登録）する。

ステップ６１０では、ステップＳ４０５で取得した全ての読取結果のファイルをステップＳ６０２で全て読込んだか否かを判定して、読込んでいないと判定された場合は、ステップＳ６０２に処理を戻して、次の読取結果のファイルを読込む。

クライアント端末１０４は、ステップ６１０で、ステップＳ４０５で取得した全ての読取結果のファイルをステップＳ６０２で全て読込んだと判定された場合は、処理をステップＳ４０８に移行する。以上が図６の説明である。

図４の説明に戻る。クライアント端末１０４は、ステップＳ４０７、又はステップＳ４０８でファイルの結合処理を実行すると、図１５に示すスキャン取込結果画面を表示する（ステップ４０９）。

図１５は、スキャン取込結果画面の一例を示す図である。スキャン取込結果画面は、セット件数の表示欄１５０１、及びスキャン件数の表示欄１５０２が表示されている。図１５に示しているセット件数の表示欄１５０１には、図１４のスキャン取込指示受付画面の１４０１に、ユーザにより入力されたセット件数を表示している。

また、図１５に示しているスキャン件数の表示欄１５０２には、図５のステップＳ５０６、又はステップＳ６０７で加算され記憶された登録予定件数が表示されている。すなわち、スキャン件数とは、登録予定件数のことを示している。登録予定件数とは、登録しなければならない保険の申込の件数である。すなわち、個別文書の枚数と同一の値となる。

そして、クライアント端末１０４は、ステップＳ４１０において、メモリに、スキャンしたデータ（スキャンデータ／スキャンした原稿の画像ファイル）を認識できたことを示す情報が記憶されているか否かを判定する。すなわち、ステップＳ５１８で読込中フラグが「ＯＮ」に設定されていると判定されたか否かを判定することにより、スキャンしたデータの認識に失敗したか否かを判定する（ステップＳ４１０）。

ステップＳ４１０で、読込中フラグが「ＯＮ」に設定されておらず、スキャンしたデータの認識に失敗したと判定された場合は（ＹＥＳ）、図１６に示すエラーメッセージを表示する（ステップＳ４１３）。

一方、ステップＳ４１０で、読込中フラグが「ＯＮ」に設定されており、スキャンしたデータの認識に成功したと判定された場合は（ＮＯ）、処理をステップＳ４１１に移行して、１５０１のセット件数と、１５０２のスキャン件数（登録予定件数）とが一致するか否かを判定する（ステップＳ４１１）。すなわち、ステップＳ４１１では、入力を受け付けた個別文書のデータ数と、特定される個別文書のデータの数とが異なるかを判定する。

そして、１５０１のセット件数と、スキャン件数（登録予定件数）１５０２とが一致しないと判定された場合は（ＮＯ）、その旨のメッセージを含む図１６に示すエラーメッセージ画面を表示する（ステップＳ４１３）。

図１６は、ステップＳ４１３で表示されるエラーメッセージ画面の一例である。図１６に示す１６０１は、ＯＫボタンであり、ユーザによりＯＫボタン１６０１が押下されると、エラーメッセージ画面を消して、処理を終了する。このエラーメッセージを表示することにより、ユーザが確認した案件の件数（１５０１のセット件数）と、ステップＳ４０７、又はステップＳ４０８でクライアント端末１０４がカウントした案件の件数（スキャン件数（登録予定件数）１５０２）とが異なっていることを、ユーザに把握させること可能となる。

次に、クライアント端末１０４は、ステップＳ４１１において、１５０１のセット件数と、スキャン件数（登録予定件数）１５０２とが一致すると判定された場合は（ＹＥＳ）、ステップＳ４０７、又はステップＳ４０８で生成されメモリに記憶された複数のファイルを登録する処理（登録手段）を実行して（ステップＳ４１２）、処理を終了する。ステップＳ４１２の詳細処理を図７に示す。以上が図４の説明である。

次に、図７を用いて、図４に示すステップＳ４１２（イメージ登録処理）の詳細処理について説明する。図７は、図４に示すステップＳ４１２（イメージ登録処理）の詳細処理の一例を示すフローチャートである。図７に示す各ステップの処理は、クライアント端末１０４のＣＰＵ２０１により実行される。

まず、クライアント端末１０４は、ファイリングサーバ１０２に、属性情報テーブル（図１２）の取得要求を送信する。当該取得要求を受信したファイリングサーバ１０２は、クライアント端末１０４に、ファイリングサーバ１０２のメモリ（ＲＡＭ２０２）に記憶されている属性情報テーブルを送信する。そして、クライアント端末１０４は、ファイリングサーバ１０２から、属性情報テーブルを取得する。

そして、クライアント端末１０４は、ステップＳ５０９、ステップＳ５０８、ステップＳ６０８でメモリに記憶されたファイルに紐付け（関連付け／対応付け）られて記憶された申込番号を全て取得する。クライアント端末１０４は、ここで取得した全ての申込番号について、ステップＳ７０２の処理を実行するまで、未処理の申込番号ごとに繰り返しステップＳ７０１からステップＳ７０５の処理を実行する。

クライアント端末１０４は、メモリから取得した現在処理対象の申込番号が、ファイリングサーバ１０２から取得した属性情報テーブルに含まれているか否かを判定する（ステップＳ７０２）。

そして、クライアント端末１０４は、現在処理対象の申込番号が、属性情報テーブルに含まれていると判定された場合は（ＹＥＳ）、現在処理対象の申込番号のファイルの登録要求をファイリングサーバ１０２に送信する（ステップＳ７０３）。ここで送信される登録要求には、現在処理対象の申込番号と、該申込番号に紐付け（関連付け／対応付け）られてメモリに記憶されたファイルと、現在処理対象の申込番号に紐付け（関連付け／対応付け）られて属性情報テーブルに記憶されている証券番号（属性情報）と、が含まれている。

そして、ファイリングサーバ１０２は、クライアント端末１０４から当該登録要求を受信すると、証券番号と、申込番号と、ファイルとを関連付けて（紐付けて／対応付けて）、ファイリングサーバ１０２の登録文書テーブル（図１３）に記憶する。図１３は、登録文書テーブルの一例を示す図である。

クライアント端末１０４は、ステップＳ７０２で、現在処理対象の申込番号が、属性情報テーブルに含まれていないと判定された場合は（ＮＯ）、現在処理対象の申込番号と、現在処理対象の申込番号に紐付け（関連付け）られて属性情報テーブルに記憶されている証券番号（属性情報）と、該申込番号に紐付け（関連付け）られてメモリに記憶されたファイルと、を含む登録保留のデータを、ファイリングサーバ１０２のメモリの登録保留フォルダに送信する（ステップＳ７０４）。

そして、ファイリングサーバ１０２は、クライアント端末１０４から該データを受信すると、該データに含まれる、証券番号と、申込番号と、ファイルとを関連付けて（紐付けて／対応付けて）、ファイリングサーバ１０２の登録保留フォルダに記憶する。クライアント端末１０４は、ステップＳ７０３、ステップＳ７０４の処理を実行すると、処理をステップＳ７０５に移行する。

ステップＳ７０５では、処理対象の全ての申込番号のうち、ステップＳ７０２の処理を実行していない申込番号があるか否かを判定して、ステップＳ７０２の処理を実行していない未処理の申込番号があると判定された場合は、その申込番号を処理対象としてステップＳ７０２の処理を実行する。また、ステップＳ７０２の処理を実行していない未処理の申込番号がないと判定された場合は、処理を終了する。

次に、図８を用いて、登録保留されたファイルの登録・削除処理について説明する。図８は、登録保留されたファイルの登録・削除処理の一例を示すフローチャートである。図８に示す各ステップの処理は、クライアント端末１０４のＣＰＵ２０１により実行される。

クライアント端末１０４は、ユーザの操作により、登録保留されたファイルのデータ一覧の取得要求を受け付けると、ファイリングサーバ１０２に、登録保留されたファイルのデータ一覧の取得要求を送信する（ステップＳ８０１）。

ファイリングサーバ１０２は、クライアント端末１０４から、当該取得要求を受け付けると、登録保留フォルダを参照して、「登録保留」として登録されたファイルを全て特定する。そして、ファイリングサーバ１０２は、特定された全てのファイルに関連付けられた証券番号と申込番号とをクライアント端末１０４に送信する。

クライアント端末１０４は、ファイリングサーバ１０２から、登録保留のデータの一覧のデータとして、当該特定された全てのファイルに関連付けられた証券番号と申込番号とを受信すると（ステップＳ８０２）、当該受信した全ての証券番号と申込番号とを登録保留のデータ一覧画面（図１７）に表示する（ステップＳ８０３）。図１７は、登録保留のデータ一覧画面の一例を示す図である。

そして、クライアント端末１０４は、登録保留のデータ一覧画面に表示されたリストの中から、ユーザの操作により、ユーザが確認したい文書（レコード）の選択を受け付けると（ステップＳ８０４）、選択された登録保留のデータの取得要求をファイリングサーバ１０２に送信する（ステップＳ８０５）。

そして、ファイリングサーバ１０２は、クライアント端末１０４から、登録保留のデータの取得要求を受信すると、当該ユーザにより選択された文書のファイル、証券番号、申込番号を含むデータをクライアント端末１０４に送信する。

クライアント端末１０４は、ファイリングサーバ１０２から、該データを受信すると（ステップＳ８０６）、該データに含まれているファイルと、申込番号と、証券番号とを、登録・削除画面（図１８）に表示する（ステップＳ８０７）。

図１８は、登録・削除画面の一例を示す図である。図中、１８０１は、申込番号を表示する表示欄であり、ユーザの操作によって、入力・編集することが可能な表示欄である。

また、１８０２は、証券番号を表示する表示欄であり、ユーザの操作によって、入力・編集することが可能な表示欄である。１８０３は削除ボタンであり、１８０４は登録ボタンである。

次に、クライアント端末１０４は、登録・削除画面（図１８）の削除ボタン１８０３をユーザに押下されたか否かを判定し（ステップＳ８０８）、削除ボタン１８０３が押下されたと判定された場合には（ＹＥＳ）、現在、登録・削除画面（図１８）に表示されているファイルに係る情報の削除要求を、ファイリングサーバ１０２に送信する（ステップＳ８１１）。

ファイリングサーバ１０２は、クライアント端末１０４から、ユーザにより選択されたファイルに係る情報の削除要求を受け付けると、登録保留フォルダに記憶されている、該当ファイル、証券番号、申込番号を削除する。

また、削除ボタン１８０３が押下されずに、ユーザにより１８０１に申込番号が入力され、登録ボタン１８０４が押下されたか否かを判定し、ユーザにより１８０１に申込番号が入力され、登録ボタン１８０４が押下されたと判定された場合、さらに、入力された申込番号が、ファイリングサーバ１０２の属性情報テーブルに登録されているか否かを確認するために、ファイリングサーバ１０２に属性情報テーブルの取得要求を送信して、ファイリングサーバ１０２から、属性情報テーブルを取得し、入力された申込番号が、当該取得した属性情報テーブルに含まれているか否かを判定する。

そして、入力された申込番号が、属性情報テーブルに含まれていると判定された場合は（ステップＳ８０９：ＹＥＳ）、クライアント端末１０４は、現在、登録・削除画面（図１８）に表示している処理対象の申込番号のファイルの登録要求をファイリングサーバ１０２に送信する（ステップＳ８１０）。ここで送信される登録要求には、該ファイルの申込番号（入力された申込番号）と、該ファイルと、該ファイルの証券番号とを含んでいる。

そして、ファイリングサーバ１０２は、クライアント端末１０４から当該登録要求を受信すると、証券番号と、申込番号と、ファイルとを関連付けて（紐付けて）、ファイリングサーバ１０２の登録文書テーブル（図１３）に記憶する。

クライアント端末１０４は、ステップＳ８０９で、入力された申込番号が、属性情報テーブルに含まれていないと判定された場合は（ステップＳ８０９：ＮＯ）、図１９に示すエラーメッセージの画面を表示する（ステップＳ８１２）。

図１９は、ステップＳ８１２で表示されるエラーメッセージ画面の一例を示す図である。図１９には、入力された申込番号が属性情報テーブルに登録されていないため、登録文書テーブルに登録することが出来ない旨のメッセージを表示している。そして、ユーザは、図１９の画面を確認して、ＯＫボタン１９０１を押下すると、クライアント端末１０４は、図１９の画面を消して、処理をステップＳ８１３に戻す。

ステップＳ８１１、ステップＳ８１０の処理を実行すると、クライアント端末１０４は、処理をステップＳ８１３に移行する。

クライアント端末１０４は、ユーザの操作により終了指示を受け付けたか否かを判定して（ステップＳ８１３）、終了指示を受け付けた場合は、処理を終了し、終了指示を受け付けていない場合は、処理をステップＳ８０３に移行する。以上が図８の説明である。

次に、図９を用いて、ファイリングサーバ１０２の登録文書テーブル（図１３）に登録されているファイルの検索、閲覧処理について説明する。図９は、ファイリングサーバ１０２の登録文書テーブル（図１３）に登録されているファイルの検索、閲覧処理の一例を示すフローチャートである。図９に示す各ステップの処理は、クライアント端末１０６のＣＰＵ２０１により実行される。

クライアント端末１０６は、ユーザにより検索画面の表示指示を受け付けると、図２０に示す検索条件入力画面を表示する（ステップＳ９０１）。

図２０は、検索条件入力画面の一例を示す図である。２００１は、申込番号を入力する入力欄である。また、２００２は、証券番号を入力する入力欄である。また、２００３は、検索ボタンである。

クライアント端末１０６は、ユーザにより、検索条件入力画面（図２０）を介して、申込番号（検索条件）、及び／又は、証券番号（検索条件）の入力を受け付け、検索ボタン２００３が押下されると（ステップＳ９０２）、ファイリングサーバ１０２に、入力された検索条件を送信する（ステップＳ９０３）。

そして、ファイリングサーバ１０２は、当該検索条件を受信すると、当該検索条件に従って、メモリに記憶されている登録文書テーブルを検索して、該当するレコードを特定する。そして、ファイリングサーバ１０２は、特定されたレコードの全ての情報をクライアント端末１０６に送信する。

クライアント端末１０６は、ファイリングサーバ１０２から、当該特定されたレコードの全ての情報を検索結果として受信すると（ステップＳ９０４）、受信した情報を検索結果表示画面（図２１）に表示する。

図２１は、検索結果表示画面の一例を示す図である。２１０１は、ファイルを表示する領域であり、２１０２は、検索条件となる申込番号や証券番号を表示する領域である。２１０３は、前のページに遷移するボタンであり、２１０４は、次のページに遷移するボタンである。２１０５は、戻るボタンである。

以上、本発明の第１の実施の形態に係る発明によれば、ユーザによる共通文書のデータと個別文書のデータを１つのファイルとして登録する煩雑な作業を軽減する共に、個別文書のデータを特定する作業を効率化させることができる。

また、複数の個別文書と、共通文書をまとめて取得することで、当該個別文書と共通文書の組み合わせのデータを複数生成することができる仕組みを提供することができる。

［第２の実施の形態］

以下、本発明の第２の実施の形態について説明する。第１の実施の形態では、共通文書と個別文書とをスキャナで読み込んだ後に、共通文書と、個々の個別文書からなる

複数のファイルを作成し、検索データとして登録する例について説明した。この例では、同一の共通文書が複数登録されることにより、データの記憶量が増大してしまう。そこで、第２の実施の形態では、個別文書を検索データとして登録する際に、共通文書と関連付けて登録し、閲覧（確認）する際に、閲覧（確認）したい個別文書とその個別文書に関連付いた共通文書とを合わせて表示可能にする例について説明する。つまり、個別文書と共通文書を結合したファイルを生成することなく、当該個別文書と共通文書の組み合わせを示すデータを複数生成する実施例について説明する。尚、第２の実施の形態の説明では、第１の実施の形態と異なる処理についてのみ説明することにする。

当該第２の実施形態において、クライアント端末１０４は、図５のステップＳ５０６及びステップＳ５１９（つまり図５Ａの処理）に代えて、個別文書のファイルと、共通文書のファイルとを関連付けるための関連付け情報を生成し、メモリに記憶する関連付け情報生成処理を行う。この関連付け情報は、共通文書のファイル名と、個別文書のファイル名とを関連付けるための情報である。

以下、関連付け情報生成処理について説明する。具体的には、クライアント端末１０４がステップＳ５１０で外部メモリに記憶した個別文書のファイルであって、ステップＳ５０２で未取得の個別文書のファイルを１つ取得し、当該図５Ａの処理（図５のステップＳ５０６の処理）の開始時点で処理中のファイルの直前に記憶された、共通文書のファイル（ステップＳ５１５で記憶されたファイル、又はステップＳ５１６で結合されて生成されたファイル）を取得する。
そして、クライアント端末１０４は、取得した個別文書のファイルと共通文書のファイルと、当該個別文書から取得した申込番号とを含む、当該それぞれのファイルを関連付ける関連付け情報を生成して、クライアント端末１０４の外部メモリに記憶する。上述した、個別文書のファイルの取得処理、共通文書のファイルの取得処理、当該取得した個別文書のファイルと共通文書のファイルとを関連付ける関連付け情報の生成処理を、ＱＲコード件数分繰り返した後、当該ＱＲコード件数の値を「０」に更新し、処理を終了する。以上が、関連付け情報生成処理の説明である。

このように、第２の実施の形態における生成手段は、共通文書のデータと個別文書データとを含む１つのファイルを生成するのではなく、それらを関連付ける関連付け情報を生成する。ここでは、複数の個別文書のファイルそれぞれについて、共通文書のファイルとの関連付けのための関連付け情報を生成する。

これにより、個別文書と共通文書を結合したファイルを生成することなく、当該個別文書と共通文書の組み合わせを示すデータを複数生成することができる。

次に、図２４を用いて、第２の実施の形態における図４に示すステップＳ４１２（イメージ登録処理）の詳細処理について説明する。図２４は第２の実施の形態における図４のステップＳ４１２（イメージ登録処理）の詳細処理の一例を示すフローチャートである。図２４に示す各ステップの処理は、クライアント端末１０４のＣＰＵ２０１により実行される。

まず、クライアント端末１０４は、ファイリングサーバ１０２に、属性情報テーブル（図１２）の取得要求を送信する。当該取得要求を受信したファイリングサーバ１０２は、クライアント端末に、ファイリングサーバ１０２のメモリ（ＲＡＭ２０２）に記憶されている属性情報テーブルを送信する。そして、クライアント端末１０４は、ファイリングサーバ１０２から、属性情報テーブルを取得する。

そして、クライアント端末１０４は、外部メモリに記憶された関連付け情報、及び、図５の各記憶処理で記憶された個別文書のファイル、共通文書のファイルを取得する。

クライアント端末１０４は、個々で取得した全ての共通文書、個別文書に対してステップＳ２４０２の処理を実行するまで、未処理の共通文書、個別文書に対して繰返しステップＳ２４０１からステップ２４０８の処理を実行する。

クライアント端末１０４は、取得した共通文書または個別文書のうち、未処理の文書データを取得する（ステップＳ２４０２）。そして、取得した文書データが共通文書であるか否かを判定する（ステップＳ２４０３）。

そして、クライアント端末１０４は、現在処理対象の文書データが、共通文書であると判定した場合は（ＹＥＳ）、共通文書を検索データとして登録させるべく、ファイリングサーバ１０２に対して、共通文書の登録要求を送信する（ステップＳ２４０４）、ここで送信される登録要求には、共通文書ファイル及びそのファイル名が含まれている。

そして、ファイリングサーバ１０２は、クライアント端末１０４から当該要求を受け付けると、これら情報をファイリングサーバ１０２の登録文書テーブル（図２３）に記憶する。尚、第２の実施の形態における登録文書テーブルのデータ構成の詳細については、図２３を参照して後述する。

一方、ステップＳ２４０３で、現在処理対象の文書データが、共通文書ではない（つまり、個別文書である）と判定された場合は（ＮＯ）、処理をステップＳ２４０５に進め、現在処理対象の個別文書の申込番号が、ファイリングサーバ１０２から取得した属性情報テーブルに含まれているか否かを判定する。

そして、クライアント端末１０４は、現在処理対象の個別文書の申込番号が、属性テーブルに含まれていると判定された場合は（ステップＳ２４０５：ＹＥＳ）、現在処理対象の個別文書を検索対象データとして登録する登録要求をファイリングサーバ１０２に対して送信する（ステップＳ２４０６）。ここで送信される登録要求には、現在処理対象の個別文書の画像ファイル、該画像ファイルに紐付け（関連付け）られている申込番号、また申込番号に紐付け（関連付け）られて属性情報テーブルに記憶されている証券番号（属性情報）と、が含まれている。また、当該個別文書と共通文書の関連付け情報がメモリに記憶されている場合には、当該個別文書に関連付けられている共通文書のファイル名もこの登録要求に含まれることになる。

そして、ファイリングサーバ１０２は、クライアント端末１０４から当該登録要求を受信すると、これら情報を図２３に示す登録文書テーブルに登録する。

クライアント端末１０４は、ステップＳ２４０５で、現在処理対象の個別文書に関連付けられた申込番号が属性情報テーブルに含まれていないと判定された場合は（ＮＯ）、現在処理対象の個別文書を登録保留のデータとして登録する登録要求をファイリングサーバ１０２に対して送信する（ステップＳ２４０７）。ここで送信される登録要求には、現在処理対象の個別文書の画像ファイル、該画像ファイルに紐付け（関連付け）られている申込番号、また申込番号に紐付け（関連付け）られて属性情報テーブルに記憶されている証券番号（属性情報）と、が含まれている。また、当該個別文書と共通文書の関連付け情報がメモリに記憶されている場合には、当該個別文書に関連付けられている共通文書のファイル名もこの登録要求に含まれることになる。

そして、ファイリングサーバ１０２は、クライアント端末１０４から当該登録要求を受信すると、これら情報を図２３に示す登録文書テーブルに登録する。

ステップＳ２４０８では、処理対象のすべての文書データに対してステップＳ２４０２以降の処理を実行したか否かを判定して、ステップＳ２４０２以降の処理を実行していない未処理の文書データがあると判定された場合は、未処理の文書データに対して上記処理を実行するために、処理をステップＳ２４０２に移行する。また、全ての文書データに対してステップＳ２４０２以降の処理を実行したと判定された場合は、処理を終了する。以上が図２４の説明である。

ここで、図２３を用いて、第２の実施の形態における登録文書テーブルのデータ構成の一例について説明する。図２３に示すように、登録文書テーブルは、証券番号、申込番号、ファイル、共通文書ファイル、登録保留フラグ等のデータ項目を備えて構成されている。

共通文書データと関連付けられている個別文書データの共通文書ファイルには、関連付けられている共通文書のファイル名が登録される。そして、個別文書を閲覧（確認）する際には、ファイリングサーバ１０２は、個別文書だけではなく、当該個別文書に関連付けられている共通文書も用いて閲覧時に表示する表示データを作成することになる。

クライアント端末１０４から、登録保留のデータとしての登録要求がなされた個別文書の登録保留フラグには、登録が保留されていることを示す情報（図中では「○」）が設定されることになる。

尚、証券番号、申込番号、ファイルについては、図１３に示す第１の実施の形態における登録文書テーブルと同様であるので、ここでの説明は割愛する。以上が、本発明の第２の実施の形態における登録文書テーブルのデータ構成の一例の説明である。

次に、図２５を参照して、第２の実施の形態における、登録保留されたファイルの登録・削除処理について説明する。図２５は、登録保留されたファイル（個別文書）の登録・削除処理の一例を示すフローチャートである。図２５に示すステップの処理は、クライアント端末１０４のＣＰＵ２０１、またはファイリングサーバ１０２のＣＰＵ２０１により実行される。尚、この処理は図８を用いて既に説明した、登録保留されたファイルの登録・削除処理に相当する処理である。

クライアント端末１０４は、ユーザの操作により、登録保留されたデータ（個別文書）のデータ一覧の取得要求を受け付けると、ファイリングサーバ１０２に、登録保留された
データのデータ一覧の取得要求を送信する（ステップＳ２５０１）。

ファイリングサーバ１０２は、クライアント端末１０４からの登録保留のデータ一覧の取得要求を受信すると（ステップＳ２５０２）、登録文書テーブルを参照し、登録保留フラグに「○」が設定されている登録保留のデータ（個別文書）を取得する。そして取得したデータを用いてデータ一覧を作成し、取得要求を行ったクライアント端末１０４に対して送信する（ステップＳ２５０３）。ここでは、登録保留のデータの証券番号と申込番号を少なくとも含む一覧データをクライアント端末１０４に対して送信する。

クライアント端末１０４は、ファイリングサーバ１０２から、登録保留のデータの一覧のデータとして、当該特定された全てのファイルに関連付けられた証券番号と申込番号とを受信すると（ステップＳ２５０４）、当該受信した全ての証券番号と申込番号とを登録保留のデータ一覧画面（図１７）に表示する（ステップＳ２５０５）。

そして、クライアント端末１０４は、登録保留のデータ一覧画面に表示されたリストの中から、ユーザの操作により、ユーザが確認したい登録保留のデータの選択を受け付けると（ステップＳ２５０６）、選択された登録保留のデータの取得要求をファイリングサーバ１０２に送信する（ステップＳ２５０７）。

そして、ファイリングサーバ１０２は、クライアント端末１０４から、登録保留のデータの取得要求を受信すると（ステップＳ２５０８）、当該指定された登録保留のデータ（個別文書）を取得する（ステップＳ２５０９）。その後、当該登録保留のデータに関連付けられている共通文書データがあるかを、登録文書テーブルを用いて判定する（ステップＳ２５１０）。具体的には、当該登録保留のデータを記憶管理する登録文書テーブル中のレコードの共通文書ファイルに共通文書のファイル名が登録されているか否かにより、ファイリングサーバ１０２はこの判定を行う。

選択された登録保留データに関連する共通文書があると判定された場合は（ステップＳ２５１０：ＹＥＳ）、ファイリングサーバ１０２は、登録保留データに関連付けられた共通文書データを取得し（ステップＳ２５１２）、取得した登録保留データと共通文書データを用いて表示用データを作成する（ステップＳ２５１３）。

一方、選択された登録保留データに関連する共通文書がないと判定された場合は（ステップＳ２５１０：ＮＯ）、ファイリングサーバ１０２は、ステップＳ２５０９で取得した登録保留されている個別文書データを用いて、表示用データを作成する（ステップＳ２５１１）。

そして、ファイリングサーバ１０２は、ステップＳ２５１１、または、ステップＳ２５１３で作成した表示用データをクライアント端末１０４に対して送信する（ステップＳ２５１４）。

クライアント端末１０４は、ファイリングサーバ１０２から、選択された登録保留データの表示用データを受信すると（ステップＳ２５１５）、当該登録保留データの申込番号、証券番号と表示用データ（画像データ）を登録・削除画面（図１８）に表示する（ステップＳ２５１６）。

登録・削除画面を表示後、登録・削除画面に設定されている削除ボタン１８０３が押されたか否かを判定し（ステップＳ２５１７）、削除ボタン１８０３が押されたと判定された場合は（ＹＥＳ）、現在、登録・削除画面（図１８）に表示されている登録保留データに係る情報の削除要求をファイリングサーバ１０２に送信する（ステップＳ２５１８）。

ファイリングサーバ１０２は、クライアント端末１０４から登録保留のデータ（個別文書）の削除指示を受け付けると（ステップＳ２５１９）、選択された登録保留のデータの削除処理を行う（ステップＳ２５２０）。この処理の詳細については、図２６を参照して後述する。そして、ステップＳ２５２０の登録保留データの削除処理が終了後、処理をステップＳ２５２５に移す。

クライアント端末１０４は、ステップＳ２５１７の判定処理で、削除ボタン１８０３が押されていないと判定された場合は（ＮＯ）、登録・削除画面に設定されている登録ボタン１８０４が押されたか否かを判定する（ステップＳ２５２１）。この判定処理で登録ボタンが押されたと判定された場合は（ＹＥＳ）、現在、登録・削除画面（図１８）に表示されている登録保留データに係る登録要求をファイリングサーバ１０２に送信する（ステップＳ２５２２）。

ファイリングサーバ１０２は、クライアント端末１０４から登録保留のデータの登録要求を受信すると（ステップＳ２５２３）、指定を受け付けた登録保留のデータを検索データとして登録する（ステップＳ２５２４）。具体的には、登録文書テーブルに記憶されている登録要求を受け付けた登録保留のデータ（個別文書）を管理するレコードの登録保留フラグに登録されている登録が保留されていることを示す情報（図中では「○」）を消去する、その後、処理をステップＳ２５２５に移す。

ファイリングサーバ１０２は、ステップＳ２５２０またはステップＳ２５２４が終了後、処理をステップＳ２５２５に移し、処理結果を登録保留のデータの削除、または登録の要求を行ったクライアント端末１０４に対して送信する。クライアント端末１０４は、ファイリングサーバ１０２からの処理結果を受信する。その後、処理をステップＳ２５２６。尚、ファイリングサーバ１０２より受信した処理結果が、処理失敗を示すものである場合には、ユーザに対して処理が失敗した旨を報知すべく、エラー表示を行う。

クライアント端末１０４は、その後、ユーザの操作指示に基づいて終了指示を受け付けたかを判定する（ステップＳ２５２７）。終了指示を受け付けていないと判定された場合は（ＮＯ）、処理をステップＳ２５０５に移し、それ以降の処理を繰り返し実行する。また、終了指示を受け付けたと判定した場合は（ＹＥＳ）、本図に示す処理を終了する。以上が図２５の説明である。

次に、図２６を用いて、図２５のステップＳ２５２０の登録保留データ削除処理の詳細について説明する。図２５に示す各ステップの処理は、ファイリングサーバ１０２のＣＰＵ２０１によって実行される。

ファイリングサーバ１０２は、クライアント端末１０４より削除指示を受け付けた登録保留のデータを取得しＲＡＭ２０２に記憶した後に、登録文書テーブルから、当該登録保留のデータを記憶管理しているレコードを削除する（ステップＳ２６０１）。そして、削除指示された登録保留のデータ（個別文書）に共通文書が関連付けられていたかを判定する（ステップＳ２６０２）。

ファイリングサーバ１０２は、ステップＳ２６０２の判定処理で共通文書が関連付けられていると判定された場合は（ＹＥＳ）、処理をステップＳ２６０３に移す。一方、共通文書が関連付けられていないと判定された場合は（ＮＯ）、本図に示す処理を終了する。

ファイリングサーバ１０２は、ステップＳ２６０３において、削除指示を受け付けた登録保留のデータ（個別文書）に関連付けられている共通文書を特定し、その後、特定した共通文書に関連付けられている他の検索データ、他の登録保留データがあるかを、登録文書テーブルを用いて判定する（ステップＳ２６０４）。

ファイリングサーバ１０２は、ステップＳ２６０４の判定処理で、ステップＳ２６０３で特定した共通文書に関連付けられている他の検索データ、他の登録保留のデータがないと判定した場合は（ＮＯ）、処理をステップＳ２６０５に移し、ステップＳ２６０３で特定した共通文書を記憶管理するレコードを登録文書テーブルから削除する。また、記憶装置に記憶されている共通文書のイメージファイルも削除することになる。そして、本図に示す処理を終了する。一方、ステップＳ２６０４の判定処理で、ステップＳ２６０３で特定した共通文書に関連付けられている他の検索データ、登録保留のデータがあると判定した場合は（ＹＥＳ）、ステップＳ２６０５の処理を行うことなく、本図に示す処理を終了する。以上が図２６の説明である。

次に、図２７を用いて、第２の実施の形態における、ファイリングサーバ１０２の登録文書テーブル（図２３）に登録されているファイルの検索・閲覧処理について説明する。図２７は、ファイリングサーバ１０２の登録文書テーブル（図２３）に登録されているファイルの検索、閲覧処理の一例を示すフローチャートである。図２３に示す各ステップの処理は、クライアント端末１０６のＣＰＵ２０１またはファイリングサーバ１０２のＣＰＵ２０１により実行される。尚、この処理は、図９を用いて説明したファイル検索・閲覧処理に相当する処理である。

クライアント端末１０６は、ユーザにより検索画面の表示指示を受け付けると、図２０に示す検索条件入力画面を表示する（ステップＳ２７０１）。そして、クライアント端末１０６は、ユーザからの操作指示により、検索条件入力画面（図２０）を介して申込番号（検索条件）、及び／又は、証券番号（検索条件）の入力を受け付けた後に、検索ボタン２００３が押下されると（ステップＳ２７０２）、ファイリングサーバ１０２に入力された検索条件を含む検索要求を送信する（ステップＳ２７０３）。

ファイリングサーバ１０２は、クライアント端末１０６から送信された検索要求を受信すると（ステップＳ２７０４）、受信した検索要求に合致する、登録文書テーブル２３００（図２３）に登録されている検索データ（登録保留フラグに「○」が登録されていないデータ）を検索する（ステップＳ２７０５）。そして、ステップＳ２７０５の検索処理の結果、受信した検索条件に合致する検索データがないと判定される場合は（ステップＳ２７０６：ＮＯ）、処理をステップＳ２７０７に移し、検索エラー通知を、検索要求を行ったクライアント端末１０６に対して送信する。

クライアント端末１０６は、ファイリングサーバ１０２から送信された検索エラー通知を受信すると（ステップＳ２７０８）、ユーザに検索エラーを報知すべく、検索エラー表示を行う（ステップＳ２７０９）。そして、処理をステップＳ２７１８に移す。

ファイリングサーバ１０２は、ステップＳ２７０６の判定処理で、検索条件に合致する検索データがあると判定される場合に（ＹＥＳ）、処理をステップＳ２７１０に移し、検索条件に合致した検索データ（個別文書）を取得する。そして、取得した検索データに共通文書が関連付けられているかを判定する（ステップＳ２７１１）。

ステップＳ２７１１の判定処理で、共通文書が関連付けられていると判定される場合は（ＹＥＳ）、ファイリングサーバ１０２は処理をステップＳ２７１３に進め、ステップＳ２７１０で取得した検索データ（個別文書）に関連付けられている共通文書を取得し、共通文書と検索データを用いて表示用データを作成する（ステップＳ２７１４）。一方、ステップＳ２７１１の判定処理で、共通文書が関連付けられていないと判定される場合は（ＮＯ）、処理をステップＳ２７１２に進め、ステップＳ２７１０で取得した検索データを用いて表示用データを作成する。

ファイリングサーバ１０２はその後、ステップＳ２７１２、または、ステップＳ２７１４で生成した表示用データを、検索要求を行ったクライアント端末１０６に対して送信する。

クライアント端末１０６は、ファイリングサーバ１０２から送信された表示用データを受信すると（ステップＳ２７１６）、表示用データの表示を行う（ステップＳ２７１７）。その後、処理をステップＳ２７１８に移す。

クライアント端末１０６は、その後、ユーザからの操作指示により、終了指示を受け付けたかを判定し（ステップＳ２７１８）、受け付けていないと判定される場合は（ＮＯ）、処理をステップＳ２７０２に移し、それ以降の処理を繰り返し実行する。一方、終了指示を受け付けたと判定される場合は（ＹＥＳ）、本図に示す処理を終了する。以上が、第２の実施の形態における、検索・閲覧処理の詳細である。

以上説明したとおり、第２の実施の形態では、文書の登録を行う際に共通文書と個別文書を関連付けた形でそれぞれ独立した形で登録し、文書の内容を表示する際に、それら文書から表示用データを作成し、表示させるようにしている。これにより、それぞれの個別文書の確認を行う際に、その個別文書に関連する共通文書も合わせて表示することが可能となるとともに、共通文書を複数登録する必要がなくなり、記憶容量を削減可能になる。
［第３の実施の形態］

次に図２８〜図３２を用いて、本発明の第３の実施の形態について説明する。本実施例では、先の第１、第２の実施の形態で、最後の共通文書よりも後に取り込んだ個別文書をエラーとしていた処理（具体的には図５のステップＳ５２１）をエラーとすることなく、それぞれ共通文書のない個別文書として登録する。これにより、共通文書がない個別文書についても、共通文書がある個別文書と一緒にファイリングサーバ１０２に登録することが可能となる。

まず、図２８を用いて、本発明の第３の実施の形態における、図４に示すステップＳ４０７（個別文書の識別情報を用いた結合処理）の詳細処理について説明する。図２８は、図４に示すステップＳ４０７（個別文書の識別情報を用いた結合処理）の詳細処理の一例を示すフローチャートである。図２８に示す各ステップの処理は、クライアント端末１０４のＣＰＵ２０１により実行される。なお、図５と同様の処理については、詳細な説明は省略する。

ステップＳ２８０１〜ステップＳ２８２０までの各ステップは、図５のステップＳ５０１〜ステップＳ５２０までの各ステップと同様であり、ステップＳ２８２２の処理は、ステップＳ５２２と同様であるため説明は省略する。

ステップＳ２８２１において、クライアント端末１０４は、最後に生成した（ステップＳ２８１５又はステップＳ２８１６）共通文書のファイルより後に認識した個別文書のファイル（つまり、共通文書のファイルを読み取ることによって、ステップＳ２８１７でセパレータフラグがＯＦＦになった後に認識した個別文書のファイルであって、当該個別文書のファイルの後に共通文書のファイルを認識しなかった個別文書のファイル）を結合する共通文書のファイルがない個別文書のファイルとして登録する処理を実行する。ステップＳ２８２１の処理の詳細については、図２９を用いて説明する。

ステップＳ２８２１の処理が終了すると、図４のステップＳ４１１に進む。
以上で、図２８の説明を終了する。次に、図２９について説明する。

図２９は、図２８のステップＳ２８２１の個別文書ファイル登録処理の詳細を示すフローチャートである。図２９に示す各ステップの処理は、クライアント端末１０４のＣＰＵ２０１により実行される。

ステップＳ２９０１において、クライアント端末１０４は、ステップＳ５０２で全てのファイルを読み込んだ場合に、最後に生成した（ステップＳ２８１５又はステップＳ２８１６）共通文書のファイルと、当該共通文書のファイルの前に記憶された（ステップＳ５１０）、共通文書のファイルと未結合の個別文書のファイルと、の結合処理を行う。ステップＳ２９０１の結合処理は図５Ａと同様であるため説明は省略する。

ただし、ステップＳ２９０１の結合処理から図５Ａの処理に移行する場合、図５ＡのステップＳ５３２〜Ｓ５３５の処理は、最後に生成した共通文書のファイルの前に記憶された、共通文書と未結合の個別文書のファイルに対してのみ実行する。つまり、最後に生成した（ステップＳ２８１５又はステップＳ２８１６）共通文書のファイルより後に記憶された共通文書と未結合の個別文書のファイルに対しては、図５Ａの処理は行わない。また、ステップＳ２９０１の結合処理の場合、図５ＡのステップＳ５３６の処理は行わない。

なお、本実施例では、共通文書のファイルについては、ステップＳ２９０２の結合処理で個別文書のファイルと結合する前に、個別文書のファイルと結合する前の共通文書のファイルを複製し、クライアント端末１０４の外部メモリに記憶しておき、後述するステップＳ２９０７では、この複製した共通文書のファイルを個別文書のファイルとの結合に使用するものとする（複数の個別文書のファイルと結合する場合には、複数複製するものとする）。

複製した共通文書のファイルは、図４のステップＳ４１２のイメージ登録処理が終了したときに削除する。

ステップＳ２９０２において、クライアント端末１０４は、最後に生成した（ステップＳ２８１５又はステップＳ２８１６）共通文書のファイルより後に記憶された共通文書と未結合の個別文書のファイルそれぞれを、クライアント端末１０４の外部メモリに、ステップＳ５０７でメモリに記憶された申込番号と対応付けて記憶する。

ステップＳ２９０３において、クライアント端末１０４は、後述する図３０に示すスキャン取込結果画面を表示する。

図３０は、スキャン取込結果画面の一例を示す図である。スキャン取込結果画面は、セット件数の表示欄３００１、及びスキャン件数の表示欄３００２、結合候補確認ボタン３００３が表示されている。図１５に示しているセット件数の表示欄３００１には、図１４のスキャン取込指示受付画面の１４０１に、ユーザにより入力されたセット件数を表示している。

また、図３０に示しているスキャン件数の表示欄３００２には、図５のステップＳ５１１、又はステップＳ６０７で加算され記憶された登録予定件数が表示されている。すなわち、スキャン件数とは、登録予定件数のことを示している。登録予定件数とは、登録しなければならない保険の申込の件数である。すなわち、個別文書の枚数と同一の値となる。

また、図３０に示している結合候補確認ボタン３００３が押下されると、後述する図３１の画面を表示する。

ステップＳ２９０４において、クライアント端末１０４は、ステップＳ２９０３でスキャン取込結果画面（図３０）を介して、結合候補確認ボタン（３００３）がユーザにより押下されたかを判断する。結合候補確認ボタンがユーザにより押下されたならば、ステップＳ２９０５に進み、結合候補確認ボタンがユーザにより押下されなければ（図３０の画面右上の「×」がユーザにより押下されたならば）、ステップＳ２９０９に進む。

ステップＳ２９０５において、クライアント端末１０４は、ステップＳ２８１５又はステップＳ２８１６で生成した共通文書のファイルをファイリングサーバ１０２から受信し、結合候補確認画面（後述する図３１）を表示する。

ステップＳ２９０６において、クライアント端末１０４は、結合候補確認画面（後述する図３１）を介して、最後に生成した（ステップＳ２８１５又はステップＳ２８１６）共通文書のファイルより後に記憶された、共通文書と未結合の個別文書のファイルと、共通文書とを結合する指示をユーザから受け付けたか否かを判定する。最後に生成した（ステップＳ２８１５又はステップＳ２８１６）共通文書のファイルより後に記憶された、共通文書と未結合の個別文書のファイルと、共通文書とを結合する指示（具体的には後述する図３１の３１０４がユーザにより押下された）を受け付けたならば、ステップＳ２９０７に進み、最後に生成した（ステップＳ２８１５又はステップＳ２８１６）共通文書のファイルより後に記憶された、共通文書と未結合の個別文書のファイルと、共通文書とを結合する指示を受け付けなければ（具体的には後述する図３１の３１０６がユーザにより押下されたならば）、ステップＳ２９０９に進む。

ステップＳ２９０７において、クライアント端末１０４は、結合候補確認画面（後述する図３１）を介して、結合する指示を受け付けた個別文書のファイルと共通文書のファイルを結合し、１つのファイルとする。

ステップＳ２９０８において、クライアント端末１０４は、ステップＳ２９０７で結合した個別文書のファイルと共通文書のファイルを含むファイルを、１つの保険申し込み案件のファイルとして、クライアント端末１０４の外部メモリに、ステップＳ５０７でメモリに記憶された申込番号と対応付けて記憶する。

ステップＳ２９０９において、クライアント端末１０４は、クライアント端末１０４は、二次元コード件数の値を「０」に更新し、処理を終了する。
以上で、図２９の説明を終了する。

図２９の処理を行うことにより、例えば、ユーザが共通文書と紐付けて記憶すべき個別文書を、誤って紐付けて記憶すべき共通文書よりあとにスキャナで取り込んでしまった場合に、共通文書と紐付けられることなくファイリングサーバ１０２に登録されることを防ぐことが出来る。

次に図３１を用いて、図３０のステップＳ２９０５でクライアント端末１０４に表示される画面について説明する。

図３１は、図３０のステップＳ２９０５でクライアント端末１０４に表示される画面の一例であり、未結合の個別文書のファイルと共通文書のファイルを結合するための画面の一例を示す図である。

３１０１には、最後に生成した（ステップＳ２８１５又はステップＳ２８１６）共通文書のファイルより後に記憶された、共通文書と未結合の個別文書のファイルが表示される。最後に生成した（ステップＳ２８１５又はステップＳ２８１６）共通文書のファイルより後に記憶された、共通文書と未結合の個別文書のファイルが複数ある場合には、不図示の切替ボタンで、共通文書のファイルと結合するファイルを選択することが出来る。

３１０２には、ステップＳ２８１５又はステップＳ２８１６で共通文書のファイルとして記憶されたファイルのイメージが表示される。図３１の場合、Ａ１〜Ａ３、Ｂ１〜Ｂ２がそれぞれひとつの共通文書のファイルのまとまりである。

３１０３は、チェックボックスであり、ユーザはマウス等の操作により、３１０１に表示された個別文書のファイルと紐付けたい共通文書のファイルのチェックボックスにチェックを入れる。

３１０４は、結合ボタンである。ユーザによりチェックボックス３１０３にチェックが入れられた後に、結合ボタン３１０４がユーザ操作により押下されると、チェックボックス３１０３にチェックが入れられた共通文書のファイルと、３１０１に表示された個別文書のファイルとが結合され、１つのファイルとなる。

３１０５は、登録ボタンであり、登録ボタン３１０５がユーザ操作により押下されると、３１０４のボタンがユーザ操作により押下されることにより結合され、ひとつとなった共通文書と個別文書を含むファイルが、１つの保険申し込み案件のファイルとして、クライアント端末１０４の外部メモリに、ステップＳ５０７でメモリに記憶された申込番号と対応付けて記憶される。

３１０６は、キャンセルボタンであり、キャンセルボタン３１０６が押下されると、図３１の画面を閉じる。
以上で図３１の説明を終了する。

次に、図３２を用いて、第３の実施の形態において、複数の個別文書、共通文書から、複数のファイル（共通文書と個別文書とが結合されたファイルと、個別文書だけのファイル）をそれぞれ生成することを説明する。

図３２は、複数の個別文書、共通文書から、複数のファイル（共通文書と個別文書とが結合されたファイルと、個別文書だけのファイル）をそれぞれ生成することを説明するための図である。

個別文書３２０１、個別文書３２０２、共通文書３２０３、個別文書３２０４の順番で、スキャナでスキャンされ、スキャンされたそれぞれの文書の画像データのファイル（１ページ１ファイルの画像データ）を、スキャナ１０５から順番に、クライアント端末１０４は取得する。

先述の図４のステップＳ４０７では、個別文書３２０１と、共通文書３２０３を含むファイルＡ、個別文書３２０２と、共通文書３２０３を含むファイルＢ、個別文書３２０４を含むファイルＣ、をそれぞれ生成する。

すなわち、クライアント端末１０４は、ある個別文書が読み込まれた後、次の個別文書が読み込まれるまで、又は全ての画像ファイルの読込みが終了するまでに読み込まれた、二次元コード（申込番号が埋め込まれた二次元コード）を含まない文書を共通文書として特定する。そして、当該共通文書が読み込まれる前に連続して読み込まれた個別文書（例えば、個別文書３２０１、３２０２）の数だけ、当該共通文書をコピーして、それぞれの個別文書と結合したファイルＡ、ファイルＢを生成する。

また、クライアント端末１０４は、ある個別文書が読み込まれた後に、二次元コード（申込番号が埋め込まれた二次元コード）を含まない文書を読み込むことなく、画像ファイルの読込みが終了した場合、その個別文書は、共通文書がない個別文書としてファイルＣを生成する。なお、複数の個別文書が連続して読み込まれた後に、二次元コード（申込番号が埋め込まれた二次元コード）を含まない文書を読み込むことなく、画像ファイルの読込みが終了した場合、それぞれの個別文書を共通文書がない個別文書とし、それぞれ別ファイルで生成する。

なお、本実施例では、図３２で、ファイルＡ、ファイルＢ、ファイルＣを生成するとしたが、他の実施例として、個別文書と共通文書の関連付け情報を記憶するだけでも良い。例えば、図３２の場合、共通文書３２０３が、個別文書３２０１と個別文書３２０２それぞれと関連付いているという情報を記憶するのみでも良い。その場合、図２９のステップＳ２９０７で、例えば個別文書３２０４と共通文書３２０３を結合する場合、個別文書３２０４と共通文書３２０３が関連付いているという情報を記憶することになる。
以上で図３２の説明を終了する。

尚、例えば、クライアント端末１０４が、図４のステップＳ４０６後に、ステップＳ４０２で入力を受け付けたセット件数が所定数以上か否かを判定し（セット件数判定手段）、所定数以上であった場合に、処理をステップＳ４０７に移行し、所定数より少なかった場合に、処理をステップＳ４０８に移行するようにしてもよい。当該所定数の値は、クライアント端末１０４の外部メモリに予め記憶されているものとする。

例えばセット件数が１であった場合、上述した第１の実施形態における図５、及び図５Ａの処理や、第２の実施形態における関連付け情報の生成処理等、スキャンしたデータが個別文書か共通文書かに応じていずれのファイルと結合するか、又は関連付けるかを決定する複雑な処理を行う必要はなく、単純に１つの結合ファイルを作成する通常の結合処理（ステップＳ４０８）で足りるためである。

上述した、ステップＳ４０２で入力を受け付けたセット件数が所定数以上か否かの判定を行い、当該判定結果に応じて処理を切り替えることで、セット件数が所定数より少ない場合に、上述した第１の実施形態における図５、及び図５Ａの処理や、第２の実施形態における関連付け情報の生成処理を回避し、処理負荷を軽減しつつ、文書の組み合わせの情報を生成することができる。

尚、当該所定数の値は１に限るものではなく、ユーザ操作に応じて任意に設定、変更可能であるものとする。

本発明では、上記のような処理を行うことで、共通文書と複数の個別文書をスキャンし、それぞれの個別文書を共通文書と関連付けて登録する際に、ユーザよって行われる煩雑な作業を軽減する共に、個別文書を確認する際に、関連する共通文書を容易に確認可能とすることで、個別文書のデータを確認する作業を効率化させることができる。

以上、本発明の実施形態を詳述したが、本発明は、例えば、システム、装置、方法、装置で読み取り実行可能なプログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のカード、ＲＯＭ等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（基本システム或いはオペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

１０１ ホストコンピュータ
１０２ ファイリングサーバ
１０３ プリンタ
１０４ クライアント端末
１０５ スキャナ
１０６ クライアント端末
１０７ ネットワーク

Claims (10)

1. 個別のファイルとして生成すべき個別文書であって、当該個別文書を識別するための識別情報を含む１つ又は複数の個別文書の画像データ、前記個別文書と関連付けるべき共通文書であって、前記識別情報を含まない共通文書の画像データの順に、複数の画像データを取得する取得手段と、
   前記取得手段で取得した画像データが、前記個別文書であるか、前記共通文書かを、前記識別情報を用いて判定する判定手段と、
   前記判定手段で、前記取得した画像データが前記個別文書であると判定した場合に、当該取得した個別文書である第１の個別文書の直前の、前記判定手段で前記共通文書と判定された前記共通文書の画像データと、当該共通文書の前に前記取得手段で取得され、前記判定手段で個別文書であると判定された第２の個別文書の画像データとを関連付ける第１の関連付け手段と、
   前記第２の個別文書が連続しているかを判定する連続判定手段と、
   を備え、
   前記第１の関連付け手段は、前記第２の個別文書が連続していると判定された場合、当該連続している第２の個別文書の画像データのそれぞれに、前記第１の個別文書の直前の前記共通文書の画像データを関連付けることを特徴とする情報処理装置。
2. 前記第１の関連付け手段は、前記第１の個別文書の直前の前記共通文書の画像データと、前記第２の個別文書の画像データとを１つのファイルとして結合することで、前記関連付けを行うことを特徴とする請求項１に記載の情報処理装置。
3. 前記第１の関連付け手段は、前記第１の個別文書の直前の前記共通文書の画像データと、前記第２の個別文書の画像データとを関連付ける関連付けファイルを生成することで、前記関連付けを行うことを特徴とする請求項１に記載の情報処理装置。
4. 前記個別文書は申込書の文書であって、
   前記判定手段は、前記取得手段で取得した画像データから、前記申込書であることを識別する識別情報を取得した場合に、当該画像データを個別文書と判定し、当該識別情報を取得できなかった場合に、当該画像データを共通文書と判定することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記第１の関連付け手段において、前記第１の個別文書の直前の前記共通文書の画像データと、前記第２の個別文書の画像データとの関連付けを行う数であるセット件数の入力を受け付けるセット件数入力受付手段と、
   前記セット件数入力受付手段で入力を受け付けた前記セット件数が所定数に達しているか判定するセット件数判定手段と、
   前記セット件数判定手段で、前記セット件数が所定数に達していないと判定した場合に、前記取得手段で取得した全ての画像データを１つの組み合わせとして関連付ける第２の関連付け手段と、
   を備え、
   前記第１の関連付け手段は、前記セット件数判定手段で、前記セット件数が所定数に達していると判定した場合に、前記第１の個別文書の直前の前記共通文書の画像データと、前記第２の個別文書の画像データとを関連付けることを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記取得手段で取得する画像データの種別の入力を受け付ける種別入力受付手段と、
   前記種別入力受付手段で入力を受け付けた前記画像データの種別が、前記第１の関連付け手段による関連付けを行うべき画像データの種別か、前記第２の関連付け手段による関連付けを行うべき画像データの種別かを判定する関連付け方法判定手段と、
   前記第１の関連付け手段は、前記関連付け方法判定手段で、前記画像データの種別が、前記第１の関連付け手段による関連付けを行うべき画像データであると判定した場合に、前記関連付けを行い、
   前記第２の関連付け手段は、前記画像データの種別が、前記第２の関連付け手段による関連付けを行うべき画像データであると判定した場合に、前記全ての画像データを１つの組み合わせとして関連付けを行うことを特徴とする請求項５に記載の情報処理装置。
7. 前記判定手段は、前記取得手段により取得したすべての画像データに対して、当該判定手段により、個別文書であるか共通文書かの判定を行い、
   前記判定手段により、前記取得手段で取得した画像データが個別文書であると判定された後に、前記取得手段により取得した画像データを共通文書であると当該判定手段で判定することなく当該判定手段による判定を終了した場合に、当該判定手段により個別文書と判定された画像データであって、当該判定手段により、最後に共通文書として判定された画像データの後に、個別文書と判定された画像データを、共通文書の画像データと関連づけない個別文書として特定する特定手段と
   を更に備えることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記特定手段により共通文書の画像データと関連づけない個別文書として特定された画像データと、前記判定手段で前記共通文書と判定された前記共通文書の画像データとを関連付ける要求を受け付ける受付手段と、
   前記受付手段により関連付ける要求を受け付けた前記個別文書の画像データと、前記共通文書の画像データとを関連付けるための画面を表示するように制御する関連付け画面表示制御手段と、
   前記関連付け画面表示制御手段で表示するよう制御された画面を介して、前記受付手段により関連付ける要求を受け付けた前記個別文書の画像データと、前記共通文書の画像データとを関連付ける指示を受け付ける関連付け指示受付手段と
   を更に備え、
   前記第１の関連付け手段は、前記関連付け指示受付手段により関連付ける指示を受け付けた前記個別文書の画像データと、前記共通文書の画像データとを更に関連付けることを特徴とする請求項７に記載の情報処理装置。
9. 個別のファイルとして生成すべき個別文書であって、当該個別文書を識別するための識別情報を含む１つ又は複数の個別文書の画像データ、前記個別文書と関連付けるべき共通文書であって、前記識別情報を含まない共通文書の画像データの順に、複数の画像データを取得する取得工程と、
   前記取得工程で取得した画像データが、前記個別文書であるか、前記共通文書かを、前記識別情報を用いて判定する判定工程と、
   前記判定工程で、前記取得した画像データが前記個別文書であると判定した場合に、当該取得した個別文書である第１の個別文書の直前の、前記判定工程で前記共通文書と判定された前記共通文書の画像データと、当該共通文書の前に前記取得工程で取得され、前記判定工程で個別文書であると判定された第２の個別文書の画像データとを関連付ける第１の関連付け工程と、
   前記第２の個別文書が連続しているかを判定する連続判定工程と、
   を含み、
   前記第１の関連付け工程は、前記第２の個別文書が連続していると判定された場合、当該連続している第２の個別文書の画像データのそれぞれに、前記第１の個別文書の直前の前記共通文書の画像データを関連付けることを特徴とする情報処理装置の制御方法。
10. 情報処理装置を、
    個別のファイルとして生成すべき個別文書であって、当該個別文書を識別するための識別情報を含む１つ又は複数の個別文書の画像データ、前記個別文書と関連付けるべき共通文書であって、前記識別情報を含まない共通文書の画像データの順に、複数の画像データを取得する取得手段と、
    前記取得手段で取得した画像データが、前記個別文書であるか、前記共通文書かを、前記識別情報を用いて判定する判定手段と、
    前記判定手段で、前記取得した画像データが前記個別文書であると判定した場合に、当該取得した個別文書である第１の個別文書の直前の、前記判定手段で前記共通文書と判定された前記共通文書の画像データと、当該共通文書の前に前記取得手段で取得され、前記判定手段で個別文書であると判定された第２の個別文書の画像データとを関連付ける第１の関連付け手段と、
    前記第２の個別文書が連続しているかを判定する連続判定手段として機能させ、
    前記第１の関連付け手段は、前記第２の個別文書が連続していると判定された場合、当該連続している第２の個別文書の画像データのそれぞれに、前記第１の個別文書の直前の前記共通文書の画像データを関連付けることを特徴とするプログラム。

Images