特許第6856877号(P6856877)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ キヤノンマーケティングジャパン株式会社の特許一覧

特許6856877情報処理装置、情報処理方法及びそのプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6856877
(24)【登録日】2021年3月23日
(45)【発行日】2021年4月14日
(54)【発明の名称】情報処理装置、情報処理方法及びそのプログラム
(51)【国際特許分類】
   H04N 1/00 20060101AFI20210405BHJP
   H04N 1/21 20060101ALI20210405BHJP
【FI】
   H04N1/00 C
   H04N1/00 L
   H04N1/21
【請求項の数】9
【全頁数】40
(21)【出願番号】特願2019-59551(P2019-59551)
(22)【出願日】2019年3月27日
(62)【分割の表示】特願2014-259683(P2014-259683)の分割
【原出願日】2014年12月24日
(65)【公開番号】特開2019-135864(P2019-135864A)
(43)【公開日】2019年8月15日
【審査請求日】2019年4月26日
(31)【優先権主張番号】特願2013-270628(P2013-270628)
(32)【優先日】2013年12月27日
(33)【優先権主張国】JP
【前置審査】
(73)【特許権者】
【識別番号】390002761
【氏名又は名称】キヤノンマーケティングジャパン株式会社
(74)【代理人】
【識別番号】100189751
【弁理士】
【氏名又は名称】木村 友輔
(72)【発明者】
【氏名】奥村 友幾
(72)【発明者】
【氏名】小島 直樹
(72)【発明者】
【氏名】増田 博紀
(72)【発明者】
【氏名】川口 容
【審査官】 野口 俊明
(56)【参考文献】
【文献】 特開2013−051679(JP,A)
【文献】 特開2003−189043(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04N 1/00
H04N 1/21
(57)【特許請求の範囲】
【請求項1】
個別文書の種類である第一の種類の文書の複数の第一画像データ、前記個別文書と結合する共通文書の種類である第二の種類の文書の第二画像データ、前記第一の種類の文書の第三画像データの順に複数の画像データを取得する取得手段と、
前記取得手段により続けて取得した複数の前記第一画像データのそれぞれと、当該第一画像データの直後に取得した前記第二画像データとを個別に結合して、当該第一画像データを取得した数分の第一の個別のファイル生成し、また、前記第二画像データの後に取得した前記第三画像データを、前記第一の個別のファイルとは結合せずに、第二の個別のファイルとして生成する生成手段と、
を備えることを特徴とする情報処理装置。
【請求項2】
前記生成手段は、前記取得手段により前記第三画像データを取得した後に取得される、前記第二の種類の文書の第四画像データと前記第三画像データとを結合して前記第二の個別ファイルを生成することを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記第一の種類の文書は、前記第一の種類の文書であることを識別するための識別情報を含む文書であり、
前記第二の種類の文書は、前記識別情報を含まない、前記第一の種類の文書と関連付けるべき文書であり、
前記取得手段で取得した画像データが、いずれの種類の文書であるかを前記識別情報を用いて判定する判定手段、
を更に備え、
前記判定手段は、前記取得手段で取得した画像データから、前記識別情報を取得した場合に、当該画像データを前記第一画像データまたは前記第三画像データであると判定し、当該識別情報を取得できなかった場合に、当該画像データを前記第二画像データと判定することを特徴とする請求項1または2に記載の情報処理装置。
【請求項4】
前記取得手段で取得する画像データの種類の入力を受け付ける種類入力受付手段、
を更に備え、
前記生成手段は、前記種類入力受付手段で入力を受け付けた前記画像データの種類に応じて、前記識別情報を用いて個別のファイルの生成を行うかを決定することを特徴とする請求項3に記載の情報処理装置。
【請求項5】
前記生成手段は、前記取得手段で前記第三画像データを取得した際に、前記取得手段で取得した前記第三画像データの直前に取得された前記第二画像データと、当該第二画像データの直前に続けて取得された複数の前記第一画像データとをそれぞれ1つのファイルとして結合することで、第一の個別のファイルを生成することを特徴とする請求項1乃至のいずれか1項に記載の情報処理装置。
【請求項6】
前記第一画像データと前記第二画像データとを結合して生成される個別のファイルの数であるセット件数の入力を受け付けるセット件数入力受付手段と、
前記セット件数入力受付手段で受け付けた数と前記生成手段で生成した個別のファイルの数とが一致しない場合に通知を行う通知手段と、をさらに備えることを特徴とする請求項1乃至のいずれか1項に記載の情報処理装置。
【請求項7】
前記第一画像データと前記第二画像データとを結合するための画面を表示するように制御する結合画面表示制御手段と、
前記結合画面表示制御手段で表示するよう制御された画面を介して、前記第一画像データと前記第二画像データとを結合する指示を受け付ける結合指示受付手段と
を更に備え、
前記生成手段は、前記結合指示受付手段により指示を受け付けた前記第一画像データと前記第二画像データとを更に結合することを特徴とする請求項1乃至のいずれか1項に記載の情報処理装置。
【請求項8】
情報処理装置の制御方法であって、
個別文書の種類である第一の種類の文書の複数の第一画像データ、前記個別文書と結合する共通文書の種類である第二の種類の文書の第二画像データ、前記第一の種類の文書の第三画像データの順に複数の画像データを取得する取得ステップと、
前記取得ステップにより続けて取得した複数の前記第一画像データのそれぞれと、当該第一画像データの直後に取得した前記第二画像データとを個別に結合して、当該第一画像データを取得した数分の第一の個別のファイル生成し、また、前記第二画像データの後に取得した前記第三画像データを、前記第一の個別のファイルとは結合せずに、第二の個別のファイルとして生成する生成ステップと、
を含むことを特徴とする情報処理装置の制御方法。
【請求項9】
コンピュータを、請求項1乃至のいずれか1項に記載の情報処理装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数の第一の種類の文書の画像データと第二の種類の文書の画像データを容易に関連付けることが可能な情報処理装置、情報処理方法及びそのプログラムに関する。
【背景技術】
【0002】
従来、保険の申込手続において、被保険者は、申込書に名前などの必要事項を記入して、申込を行っている。このとき、申込書に、保険の内容が記載されている場合もあるが、別紙に保険の内容が記載されている場合もある。また、保険の申込をするために申込書に添付しなければならない添付書類なども必要となる場合がある。
【0003】
また、例えば、同一の申込者が保険の一括申込を行う場合、複数の申込書(以下、個別文書)に対し、身分証明書等の共通の添付書類(以下、共通文書)を添付する場合がある。
【0004】
保険会社の社員(ユーザ)は、共通文書と複数の個別文書をスキャナでまとめてスキャンして、1つのファイルとして登録し、そのファイルを検索し、閲覧して、その内容を確認する業務を行っている。
【0005】
特許文献1には、スキャナでスキャンする文書の先頭に、生成されるファイルのファイル名の付け方、生成されるファイルのファイル形式の種類、生成されるファイルの格納先が指示されている指示シートを挿入して、その指示シートの内容に従って、指示シートの後にスキャンされる文書に対する処理内容を決定することが記載されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2005−210563号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかしながら、特許文献1の技術では、1回のスキャンで複数の個別文書のデータと共通文書のデータとを1つのファイルとして登録し、ユーザに確認させるためには、生成したいファイルの数だけ、上記指示シート及び当該個別文書と共通文書を用意してスキャン処理をさせる必要があり、非常に手間である。
【0008】
本発明は、複数の第一の種類の文書の画像データと第二の種類の文書の画像データを容易に関連付けることが可能な仕組みを提供することである。
【課題を解決するための手段】
【0009】
本発明の情報処理装置は、個別文書の種類である第一の種類の文書の複数の第一画像データ、前記個別文書と結合する共通文書の種類である第二の種類の文書の第二画像データ、前記第一の種類の文書の第三画像データの順に複数の画像データを取得する取得手段と、前記取得手段により続けて取得した複数の前記第一画像データのそれぞれと、当該第一画像データの直後に取得した前記第二画像データとを個別に結合して、当該第一画像データを取得した数分の第一の個別のファイル生成し、また、前記第二画像データの後に取得した前記第三画像データを、前記第一の個別のファイルとは結合せずに、第二の個別のファイルとして生成する生成手段と、を備えることを特徴とする。
【0010】
また、本発明は、情報処理装置の制御方法であって、個別文書の種類である第一の種類の文書の複数の第一画像データ、前記個別文書と結合する共通文書の種類である第二の種類の文書の第二画像データ、前記第一の種類の文書の第三画像データの順に複数の画像データを取得する取得ステップと、前記取得ステップにより続けて取得した複数の前記第一画像データのそれぞれと、当該第一画像データの直後に取得した前記第二画像データとを個別に結合して、当該第一画像データを取得した数分の第一の個別のファイル生成し、また、前記第二画像データの後に取得した前記第三画像データを、前記第一の個別のファイルとは結合せずに、第二の個別のファイルとして生成する生成ステップと、を含むことを特徴とする。
また、本発明は、コンピュータを、上記の情報処理装置として機能させるためのプログラムであることを特徴とする。
【発明の効果】
【0011】
本発明によれば、複数の第一の種類の文書の画像データと第二の種類の文書の画像データを容易に関連付けることが可能な仕組みを提供することができる。
【図面の簡単な説明】
【0012】
図1】本発明の第1の実施形態に係る情報処理システムの構成を示す図である。
図2図1に示したクライアント端末104の基本構成を示すブロック図である。
図3】被保険者の保険申込書(個別文書)の印刷処理を示すフローチャートである。
図4】被保険者の保険申込書(個別文書)、添付書類(共通文書)などの文書の電子データをファイリングサーバ102に登録する処理の一例を示すフローチャートである。
図5図4に示すステップS407(個別文書の識別情報を用いた結合処理)の詳細処理の一例を示すフローチャートである。
図5A】個別文書と共通文書の結合処理の詳細を示すフローチャートである。
図6図4に示すステップS408(通常の結合処理)の詳細処理の一例を示すフローチャートである。
図7図4に示すステップS412(イメージ登録処理)の詳細処理の一例を示すフローチャートである。
図8】登録保留されたファイルの登録・削除処理の一例を示すフローチャートである。
図9】ファイリングサーバ102の登録文書テーブル(図13)に登録されているファイルの検索、閲覧処理の一例を示すフローチャートである。
図10図3で被保険者の保険申込書に印刷された申込番号の、属性情報連携ファイル(図11)のレコードの情報を、ファイリングサーバ102の記憶部に記憶されている属性情報テーブルに登録する処理の一例を示すフローチャートである。
図11】属性情報連携ファイルの一例を示す図である。
図12】属性情報テーブルの一例を示す図である。
図13】登録文書テーブルの一例を示す図である。
図14】スキャン取込指示受付画面の一例を示す図である。
図15】スキャン取込結果画面の一例を示す図である。
図16】ステップS413で表示されるエラーメッセージ画面の一例である。
図17】登録保留のデータ一覧画面の一例を示す図である。
図18】登録・削除画面の一例を示す図である。
図19】ステップS812で表示されるエラーメッセージ画面の一例を示す図である。
図20】検索条件入力画面の一例を示す図である。
図21】検索結果表示画面の一例を示す図である。
図22】複数の個別文書、共通文書から、複数のファイル(共通文書と個別文書とが結合されたファイル)をそれぞれ生成することを説明するための図である。
図23】第2の実施の形態における登録文書テーブルの一例を示す図である。
図24】第2の実施の形態における図4に示すステップS412(イメージ登録処理)の詳細処理の一例を示すフローチャートである。
図25】第2の実施の形態における、登録保留されたファイルの登録・削除処理の一例を示すフローチャートである。
図26図25に示すステップS2520(登録保留データ削除処理)の詳細処理の一例を示すフローチャートである。
図27】第2の実施の形態における、ファイリングサーバ102の登録文書テーブルに登録されているファイルの検索・閲覧処理の一例を示すフローチャートである。
図28】第3の実施の形態における、図4に示すステップS407(個別文書の識別情報を用いた結合処理)の詳細処理の一例を示すフローチャートである。
図29図28のステップS2821の個別文書データ登録処理の詳細を示すフローチャートである。
図30】スキャン取込結果画面の一例を示す図である。
図31】未結合の個別文書のファイルと共通文書のファイルを結合するための画面の一例を示す図である。
図32】複数の個別文書、共通文書から、複数のファイル(共通文書と個別文書とが結合されたファイルと、個別文書だけのファイル)をそれぞれ生成することを説明するための図である。
【発明を実施するための形態】
【0013】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
【0014】
[第1の実施の形態]
【0015】
図1は、本発明の第1の実施形態に係る情報処理システムの構成を示す図である。ホストコンピュータ101、ファイリングサーバ102、プリンタ103、クライアント端末104、クライアント端末106は、それぞれネットワーク107を介して、相互に通信可能に接続されている。また、クライアント端末104は、スキャナ105と通信可能に接続されている。スキャナ105は、文書を読み取り該文書の画像データを生成する読取装置の適用例である。
【0016】
ホストコンピュータ101は、属性情報連携ファイル(図11)を記憶しており、属性情報連携ファイルに記憶されている情報に従って、後述する被保険者の保険申込書(被保険者名簿とも言う)のデータをプリンタ103に印刷出力する機能を備えている。被保険者の保険申込書(被保険者名簿)は、後述する個別文書(用紙)である。ここで印刷される個別文書には、属性情報連携ファイル(図11)に記憶されている申込番号が印字される。個別文書毎に、異なる申込番号が印字されるため、申込番号から個別文書を特定することが可能となる。このように、申込番号は、個別文書を識別する識別情報として用いられる。
【0017】
個別文書は、例えば、被保険者の保険申込書であって、被保険者が保険の申込を行うために、被保険者の署名、捺印等を行う用紙である。本実施の形態では、1枚の個別文書を、1人の被保険者の保険の申込を行う用紙として説明する。また、当該個別文書には、当該個別文書の識別情報である申込み番号が埋め込まれたQRコード(QRコードは登録商標)等の二次元コードが印刷されているものとする。
【0018】
また、ホストコンピュータ101は、記憶部に記憶している申込書(個別文書)2201、及び添付書類(共通文書)2202のデータをプリンタ103に印刷出力する機能を備えている。申込書(個別文書)は、保険の契約を締結するための各申込者の個別の文書である。添付書類は、複数の申込書に共通して添付される共通文書であって、1枚又は複数枚の用紙で構成される。
【0019】
また、ホストコンピュータ101は、プリンタ103から印刷出力された個別文書に印刷されたQRコード(申込番号、及びその申込番号に関連した情報(証券番号))の情報を、属性情報連携ファイル(図11)から取得して、ファイリングサーバ102の記憶部に記憶されている属性情報テーブル(図12)に対して登録する要求を、夜間バッチ処理などで、送信する機能を備えている。
【0020】
図12は、属性情報テーブルの一例を示す図である。属性情報テーブル(図12)には、個別申込書に印刷された申込番号と、当該申込番号が印刷された個別申込書に印刷された証券番号とが記憶されている。
【0021】
クライアント端末104は、ユーザの操作に従って読み取り指示を受け付けると、スキャナ105に読取要求を送信する機能を備えている。読取要求を受信したスキャナ105は、スキャナ105のオートドキュメントフィーダ(ADF)にセットされた用紙を読み込み、用紙を電子化して得られたデータを、クライアント端末104に送信する機能を備えている。(ここでは、用紙1枚につき、1つのファイル(データ)を生成して、クライアント端末104に送信する。)
【0022】
そして、クライアント端末104は、スキャナ105から送信されてきたデータ(複数のファイル)を受信すると、当該データを解析して、個別文書毎に、共通文書を結合して、個別文書と共通文書のペア(組み合わせ)とする1つのファイルを生成する機能を備えている。
【0023】
また、クライアント端末104は、個別文書毎に、共通文書を結合して生成された、個別文書毎の当該ファイルをファイリングサーバ102に送信して、当該ファイルの登録要求を行う機能を備えている。
【0024】
ファイリングサーバ102は、クライアント端末104から登録要求を受信すると、当該登録要求に含まれているファイルを、ファイリングサーバ102の記憶部に記憶する機能を備えている。クライアント端末106は、ファイリングサーバ102の記憶部に記憶されているファイルを取得して表示部に表示する機能を備えている。
【0025】
次に、図22を用いて、後述する、複数の個別文書、共通文書から、複数のファイル(共通文書と個別文書とが結合されたファイル)をそれぞれ生成することを説明する。
【0026】
図22は、複数の個別文書、共通文書から、複数のファイル(共通文書と個別文書とが結合されたファイル)をそれぞれ生成することを説明するための図である。
【0027】
個別文書2201、個別文書2202、共通文書2203、個別文書2204、共通文書2205の順番で、スキャナでスキャンされ、スキャンされたそれぞれの文書の画像データのファイル(1ページ1ファイルの画像データ)を、スキャナ105から順番に、クライアント端末104は取得する。
【0028】
後述するステップS407では、個別文書2201と、共通文書2203を含むファイルA、個別文書2202と、共通文書2203を含むファイルB、個別文書2204と、共通文書2205を含むファイルC、をそれぞれ生成する。
【0029】
すなわち、クライアント端末104は、ある個別文書が読み込まれた後、次の個別文書が読み込まれるまで、又は全ての画像ファイルの読込みが終了するまでに読み込まれた、QRコード(申込番号が埋め込まれた二次元コード)を含まない文書を共通文書として特定する。そして、当該共通文書が読み込まれる前に連続して読み込まれた個別文書(例えば、個別文書2201、2202)の数だけ、当該共通文書をコピーして、それぞれの個別文書と結合したファイルA、ファイルBを生成する。
【0030】
図2は、図1に示したクライアント端末104の基本構成を示すブロック図である。図2において、201はCPUであり、RAM202やROM203に格納されているプログラムやデータを用いてクライアント端末104全体の制御を行うと共に、クライアント端末104が行う後述の各処理を実行する。
【0031】
202はRAMであり、HDD204や記録媒体ドライブ206からロードされたプログラムやデータ、ネットワークI/F(インターフェース)205を介して受信したデータを一時的に記憶するためのエリアを備えると共に、CPU201が各種の処理を実行する際に使用するワークエリアを備える。
【0032】
203はROMであり、クライアント端末104の設定データやブートプログラムなどを格納する。
【0033】
204はHDDであり、ここにOS(オペレーティングシステム)や、クライアント端末104が行う後述の各処理をCPU201に実行させるためのプログラムやデータが保存されている。これらのプログラムやデータの一部もしくは全部はCPU201による制御に従ってRAM202にロードされ、これを用いてCPU201が処理を行うことで、クライアント端末104は以下説明する各処理を実行することになる。
【0034】
205はネットワークI/Fで、クライアント端末104をネットワーク107に接続するためのものであり、このネットワークI/F205を介してクライアント端末104は外部機器とデータ通信を行うことができる。
【0035】
206は記録媒体ドライブであり、CD−ROM、CD−R/RW、DVD―ROM、DVD−R/RW、DVD−RAM等の記憶媒体に記録されたプログラムやデータを読み出し、RAM202に出力する。この読み出し動作はCPU201によって制御される。
【0036】
207はキーボードであり、各種の指示をCPU201に対して入力することができる。208はマウス等のポインティングデバイスであり、各種の指示をCPU201に対して入力することができる。
【0037】
209はビデオI/F(インターフェース)であり、ディスプレイ装置210に表示すべき画像を信号としてディスプレイ装置210に供給するためのI/Fとして機能するものである。
【0038】
210はディスプレイ装置であり、CRTや液晶画面等により構成されており、CPU201による処理結果を画像や文字等でもって表示することができる。
【0039】
211は周辺機器I/Fであり、USBポートやIEEE1394ポート等によって構成されており、この周辺機器I/F211を介して周辺機器との接続することが可能である。周辺機器との接続形態は有線/無線を問わない。212は上述の各部を繋ぐバスである。
【0040】
また、図2に示す構成は、ホストコンピュータ101、ファイリングサーバ102、クライアント端末106についても同様の構成であるため、ホストコンピュータ101、ファイリングサーバ102、クライアント端末106のブロック図の説明は省略する。
【0041】
次に、図3を用いて、被保険者の保険申込書(個別文書)の印刷処理について説明する。図3は、被保険者の保険申込書(個別文書)の印刷処理を示すフローチャートである。図3に示す各ステップの処理は、ホストコンピュータ101のCPU201により実行される。
【0042】
ホストコンピュータ101は、記憶部に記憶されている属性情報連携ファイル(図11)を取得して、属性情報連携ファイル(図11)のレコード毎の申込番号を取得する(ステップS301)。
【0043】
図11は、属性情報連携ファイルの一例を示す図である。属性情報連携ファイルは、「証券番号」、「申込番号」とから構成されており、「証券番号」は、契約内容を一意に識別するための番号であり、「申込番号」は申込手続(申込の案件)を一意に識別するための番号である。
【0044】
次に、ホストコンピュータ101は、ステップS301で取得した申込番号を埋め込んだQRコードを生成して、当該QRコードを記憶部に記憶されている被保険者の保険申込書(個別文書)のテンプレートの所定の位置にオーバーレイして、ステップS301で取得したレコードの申込番号ごとに、該申込番号を含む個別文書の印刷データをそれぞれ生成し(ステップS302)、プリンタ103に送信(出力)して印刷要求を行う(ステップS303)。例えば、図11に示す属性情報連携ファイルの各レコードには、申込番号として「001」と、「002」とが記憶されている。
【0045】
ステップS301では、「001」と「002」とを取得して、ステップS302で、被保険者の保険申込書(個別文書)のテンプレートの所定の位置に「001」の情報を含めたQRコードを付加して1つの個別文書の印刷データを生成する。また、ステップS302では、被保険者の保険申込書(個別文書)のテンプレートの所定の位置に「002」の情報を含めたQRコードを付加して1つの個別文書の印刷データを生成する。
【0046】
このようにして生成された2つの個別文書の印刷データを、ステップS303でプリンタ103に送信して、2つの個別文書の印刷を行う。プリンタ103は、ホストコンピュータ101から受信した印刷要求に含まれる2つの個別文書の印刷データに従って、2枚の個別文書の印刷を行う。このようにして印刷された個別文書には、被保険者の署名欄、捺印欄などが含まれており、被保険者により署名、捺印がなされることとなる。
【0047】
次に、図10を用いて、図3で被保険者の保険申込書に印刷されたQRコードの示す申込番号の、属性情報連携ファイル(図11)のレコードの情報を、ファイリングサーバ102の記憶部に記憶されている属性情報テーブルに登録する処理について説明する。
【0048】
図10は、図3で被保険者の保険申込書に印刷された申込番号の、属性情報連携ファイル(図11)のレコードの情報を、ファイリングサーバ102の記憶部に記憶されている属性情報テーブルに登録する処理の一例を示すフローチャートである。図10に示すS1001、S1002のステップの処理は、ホストコンピュータ101のCPU201により実行される。また、図10に示すS1003、S1004のステップの処理は、ファイリングサーバ102のCPU201により実行される。
【0049】
ホストコンピュータ101は、現在の日時が所定の日時であるか否かを判定し(ステップS1001)、所定の日時であると判定された場合は(S1001:YES)、図3で被保険者の保険申込書に印刷済みのQRコードの示す申込番号の、属性情報連携ファイル(図11)のレコードの情報を、ファイリングサーバ102に送信する(ステップS1002)。
【0050】
そして、ファイリングサーバ102は、ホストコンピュータ101から、該レコードの情報を受信すると(ステップS1003)、当該情報を、ファイリングサーバ102の記憶部に記憶されている属性情報テーブルに登録する(ステップS1004)。
【0051】
次に、図4を用いて、被保険者の保険申込書(個別文書)、契約一括申込書(共通文書)など文書をスキャナ105が読み取ることで得られる文書の電子データを、ファイリングサーバ102に登録する処理について説明する。
【0052】
図4は、被保険者の保険申込書(個別文書)、添付書類(共通文書)などの文書の電子データをファイリングサーバ102に登録する処理の一例を示すフローチャートである。図4に示す各ステップの処理は、クライアント端末104のCPU201により実行される。
【0053】
クライアント端末104は、まず、図14に示すスキャン取込指示受付画面を表示する。
【0054】
図14は、スキャン取込指示受付画面の一例を示す図である。図中、1401は、ユーザの操作によるセット件数の入力を受け付ける入力欄である。1402は、ユーザの操作による文書種類(文書種別)の選択入力を受け付けるプルダウンである。1403は、スキャン開始をスキャナ105に指示するためのスキャン開始ボタンである。ここで、セット件数とは、共通文書と個別文書とから構成されるファイルの数(個別文書の数)のことを示している。
【0055】
ユーザは、スキャナ105のADFにセットした個別文書の数を確認して、スキャン取込指示受付画面(図14)のセット件数1401に入力する。また、1402で選択可能な文書種類は、例えば、「申込書」と「明細書」とがあるものとして説明する。
【0056】
「申込書」は、後述するステップS407で個別文書の識別情報(個別文書と共通文書の結合に用いる情報であるQRコードの示す申込番号)を用いて個別文書と共通文書の結合処理を行う文書種類であり、「明細書」は、後述するステップS407でセパレータを用いることなく、通常の結合処理を行う文書種類である。すなわち、図14の1402で文書種類を選択することで、ステップS407で個別文書の識別情報(個別文書と共通文書の結合に用いる情報であるQRコードの示す申込番号)を用いて結合処理を行うか、ステップS407でセパレータを用いることなく通常の結合処理を行うかの設定を入力することを意味している。
【0057】
クライアント端末104は、スキャン取込指示受付画面(図14)を介して、ユーザの操作により、セット件数の入力、及び、文書種類の入力を受け付け(ステップS402/セット件数入力受付手段、種別入力受付手段)、スキャン開始ボタン1403が押下されると(ステップS403:YES)、処理をステップS404に移行する。また、クライアント端末104は、スキャン開始ボタン1403が押下されるまで(ステップS403:NO)、スキャン取込指示受付画面(図14)を表示して、セット件数の入力、及び、文書種類の入力を受け付ける。このように、ステップS402では、ユーザの操作による個別文書のデータ数の入力を受け付ける(入力受付手段)。
【0058】
そして、クライアント端末104は、スキャン開始ボタン1403が押下されると、スキャナ105に、スキャナ105のADFにセットされた文書の読取要求を送信する(ステップS404)。
【0059】
スキャナ105は、読取要求をクライアント端末104から受信すると、スキャナ105のADFにセットされた文書の読取処理を実行し、読み取られたデータを読取結果としてクライアント端末104に送信する。ここで送信されるデータは、1文書の1ページごとの1つのファイル(本実施形態では、当該ファイルのことを画像データともいう)である。すなわち、複数ページを読み取った場合は、複数のファイル(画像データ)が送信されることとなる。
【0060】
そして、クライアント端末104は、スキャナ105から、読取結果としてスキャナ105で読み取られたデータを受信(取得)する(ステップS405)。ステップS405では、複数ページを読み取った場合は、複数のファイル(画像データ)を取得する。
【0061】
ここでは、例えば、図22に説明したように、個別文書2201、2202、共通文書2203、個別文書2204、共通文書2205の順番で、スキャナ105から、それぞれのファイルを取得するものとする。
【0062】
クライアント端末104は、ステップS405で入力を受け付けた文書種類(文書種別)が「申込書」であるか、それとも「明細書」であるかを判定する。すなわち、ステップS407で、個別文書の識別情報を用いた結合処理を行うか、ステップS408で、個別文書の識別情報を用いることなく通常の結合処理を行うかを判定する(ステップS406)。
【0063】
そして、ステップS405で入力を受け付けた文書種類(文書種別)が「申込書」である(ステップS406で個別文書の識別情報を用いて結合処理を行う)と判定された場合は(ステップS406:YES)、処理をステップS407に移行する。一方、ステップS405で入力を受け付けた文書種類(文書種別)が「明細書」である(ステップS408で個別文書の識別情報を用いることなく通常の結合処理を行う)と判定された場合は(ステップS406:NO)、処理をステップS408に移行する。
【0064】
ステップS407では、個別文書の識別情報を用いて、個別文書のファイルと共通文書のファイルとを結合して1つのファイルを生成する処理を行い、一方、ステップS408では、スキャナ105から取得した全てのファイルを結合して1つのファイルを生成する処理を行う。ステップS407の詳細処理を図5に示し、ステップS408の詳細処理を図6に示す。
【0065】
次に、図5を用いて、図4に示すステップS407(個別文書の識別情報を用いた結合処理)の詳細処理について説明する。図5は、図4に示すステップS407(個別文書の識別情報を用いた結合処理)の詳細処理の一例を示すフローチャートである。図5に示す各ステップの処理は、クライアント端末104のCPU201により実行される。
【0066】
クライアント端末104のメモリ(RAM202)に記憶されている読込中フラグを初期値である「OFF」に設定して、図5に示す処理を開始する。また、クライアント端末104のメモリに記憶されている登録予定件数を初期値である「0(ゼロ)」に設定して、図5に示す処理を開始する。ここでいう登録予定件数とは、例えば、後述する図15の1502に挿入される件数の値である。つまり、図5の処理を行うことで生成されるファイル数であって、個別文書の数と等しい数となる。
【0067】
ステップS501からステップS515の処理を、ステップS502で読み込む、ステップS405で取得した全ての読取結果のファイルに対して繰り返し実行する。
【0068】
まず、クライアント端末104は、ステップS405で取得した、スキャナ105の読取結果のファイルのうち、未処理の先頭のファイルを読み込む(ステップS502)。ここで読み込んだファイルを処理対象のファイルとして以降の処理を行う。ステップS501以降の処理は、スキャナ105から受信されるファイルの順番で処理対象のファイルにして処理する。
【0069】
そして、クライアント端末104は、ステップS502で読み込んだファイルの所定の位置から、QRコード、を読み取る処理を行う(ステップS503)。すなわち、ステップS503では、ステップS502で読み込んだファイル(画像データ)から、該画像データの文書が共通文書のデータか、個別文書のデータかを特定するための情報(個別文書の申込番号)をQRコードから読み取る。
【0070】
次に、クライアント端末104は、当該QRコードから読み取った情報が、申込番号であるか否かを判定する。当該申込番号か否かの判定は、属性情報連携ファイルの申込番号の項に、一致する申込番号が存在するか否かを以って判定する。
【0071】
属性情報連携ファイルの申込番号の項に、一致する申込番号が存在する場合(ステップS504:YES)、処理をステップS505に移行し、属性情報連携ファイルの申込番号の項に、一致する申込番号が存在しない場合(ステップS504:NO)、処理をステップS508に移行する。
【0072】
クライアント端末104は、ステップS505で、クライアント端末104のメモリに記憶されている読込中フラグが「ON」に設定されているか否かを判定する(ステップS505)。また、読込中フラグが「ON」の場合、処理中のファイルがステップS502で最初に読み取ったファイルか(先頭の用紙としてスキャンされた原稿か)判定する(ステップS522)。
【0073】
すなわち、ステップS505及びS522では、現在処理中のファイルの直前までに読み取られた共通文書のファイル(QRコード(申込番号)のないファイル)を、当該共通文書のファイルの前に読み取られた個別文書のファイルと結合する処理(ステップS506)を行うか否かを決定する。ステップSステップS506の処理の詳細については、図5Aの説明で後述する。
【0074】
また、読込中フラグが「ON」である=直前に読み込んだファイルが個別文書であることを示す。つまり、ステップS505は、個別文書が連続しているか判定している(連続判定手段)。
【0075】
すなわち、読込中フラグが「OFF」であって、且つ、処理中のファイルが2枚目以降のファイルであると判定された場合の現在処理対象のファイルを、共通文書の後に読み取られた個別文書のデータとして特定する。また、読込中フラグが「ON」であって、且つ、処理中のファイルが2枚目以降のファイルであると判定された場合の現在処理対象のファイルを、個別文書の後に読み取られた個別文書(図22でいう個別文書2202)のデータとして特定する。
【0076】
また、読込中フラグが「OFF」であって、且つ、処理中のファイルが1枚目のファイルであると判定された場合の現在処理対象のファイルを、最初に読み取られた個別文書のデータとして特定する。
【0077】
次に、クライアント端末104は、読込中フラグが「ON」に設定されていると判定された場合(ステップS505:NO)、又は、当該込中フラグが「OFF」であって且つ当該処理中のファイルが最初のファイルであると判定した場合(ステップS522:YES)、ステップS503で読み取ったQRコードから取得した申込番号を外部メモリに記憶する(ステップS507)。
【0078】
そして、当該処理中のファイルを、後に共通文書と結合する個別ファイルとして外部メモリに記憶し(ステップS510)、登録予定件数の値を1つカウントアップする(ステップS511)。また、連続して読み込んだ個別文書の数を示すQRコード件数を1つカウントアップして(ステップS512)、読込中フラグを「ON」に設定する(ステップS513)。
【0079】
また、クライアント端末104は、ステップS508で、読み込んだファイルが先頭のファイル(先頭の原稿としてスキャンされた画像ファイル)か判定する。先頭のファイルである場合(ステップS508:YES)、申込番号=「NULL」の値を、外部メモリに記憶する(ステップS509)。
【0080】
読み込んだファイルが先頭のファイルである場合(ステップS508:NO)、当該処理中のファイルを共通文書として特定し、処理中のファイルの直前に処理したファイルが共通文書であるか判定する(ステップS514)。つまり、当該処理中のファイル(共通文書)の直前に別の共通文書が存在するか判定する。
【0081】
直前に共通文書が存在しない場合(ステップS514:NO)、現在処理対象のファイルを共通文書の画像ファイルとしてメモリに記憶する(ステップS515)。
【0082】
一方、処理中の共通文書のファイルの直前に共通文書が存在する場合(ステップS514:YES)、メモリに既に記憶されている直前の共通文書のファイルと、現在、処理対象のファイルを結合して1つの画像ファイルとして生成し、当該生成されたファイルを、共通文書のファイルとしてメモリに記憶する(ステップS516)。
【0083】
すなわち、ステップS515、ステップS516では、処理中の共通文書よりも前の画像データを共通文書のデータとして特定する処理である。クライアント端末104は、ステップS513、ステップS514の処理を実行すると、処理をステップS517に移行し、読込中フラグを「OFF」に設定する。つまり、処理した文書が共通文書であったことを示す情報を記憶する。
【0084】
ここで図5Aを参照して、本発明の実施形態における、個別文書と共通文書の結合処理の詳細について説明する。図5Aは、本発明の実施形態における、個別文書と共通文書の結合処理の詳細を示すフローチャートである。当該図5Aの処理は、図5のステップS506及び後述するステップS519の詳細を示す処理である。
【0085】
クライアント端末104は、ステップS512でカウントアップしたQRコード件数分、ステップS532〜S535の処理を繰り返す。クライアント端末104は、ステップS510で外部メモリに記憶した個別文書のファイルであって、ステップS502で未取得(共通文書と未結合)の個別文書のファイルを1つ取得する(ステップS532)。そして、当該図5Aの処理(図5のステップS506の処理)の開始時点で処理中のファイルの直前に記憶された、共通文書のファイル(ステップS515で記憶されたファイル、又はステップS516で結合されて生成されたファイル)を取得する(ステップS533)。
【0086】
クライアント端末104は、ステップS532で取得した個別文書のファイルと、ステップS533で取得した共通文書のファイルを結合して1つの保険申し込み案件のファイルとして生成し(ステップS534)、クライアント端末104の外部メモリに、ステップS507でメモリに記憶された申込番号と対応付けて記憶する(ステップS535)。
【0087】
そして、当該ステップS532〜S535の処理をQRコード件数分繰り返した後、当該QRコード件数の値を「0」に更新し、処理を終了する。以上が図5Aの説明である。
【0088】
ステップS518では、メモリに記憶されている読込中フラグが「ON」に設定されているか否かを判定する。そして、クライアント端末104は、読込中フラグが「ON」に設定されていないと判定された場合は(ステップS518:NO)、図5Aに示す個別文書と共通文書のファイルの結合処理を行う(ステップS519)。つまり、ステップS502で全てのファイルを読み込んだ場合に、最後に生成した(ステップS515又はステップS516)共通文書のファイルと、当該共通文書の前に記憶された(ステップS510)、共通文書と未結合の個別文書のファイルと、の結合処理を行う。そして、スキャンしたデータの認識に成功したことを示す情報をメモリに記憶して(ステップS520)、処理を終了する。
【0089】
また、クライアント端末104は、読込中が「ON」に設定されていると判定された場合は(ステップS518:YES)、スキャンしたデータを認識できなかったことを示す情報をメモリに記憶して(ステップS521)、処理を図4のステップS409に移行する。以上の処理を行うことにより、個別文書ごとに、該個別文書と共通文書とが結合されたファイルをそれぞれ生成することが可能となる。つまり、複数の個別文書と、共通文書をまとめて取得することで、当該個別文書と共通文書の組み合わせのデータを複数生成することができる仕組みを提供することができる。
【0090】
次に、図6を用いて、図4に示すステップS408(通常の結合処理)の詳細処理について説明する。図6は、図4に示すステップS408(通常の結合処理)の詳細処理の一例を示すフローチャートである。図6に示す各ステップの処理は、クライアント端末104のCPU201により実行される。
【0091】
クライアント端末104のメモリに記憶されている登録予定件数を初期値である「0(ゼロ)」に設定して、図6に示す処理を開始する。
【0092】
ステップS601からステップS610の処理を、ステップS405で取得した全ての読取結果のファイルをステップS602で全て読込むまで、繰り返し実行する。尚、ステップS601以降の処理は、スキャナ105から受信されるファイルの順番で処理対象のファイルにして処理する。
【0093】
まず、クライアント端末104は、ステップS405で取得した、スキャナ105の読取結果のファイルのうち、未処理の先頭のファイルを読み込む(ステップS602)。ここで読み込んだファイルを処理対象のファイルとして以降の処理を行う。そして、クライアント端末104は、ステップS602で読み込んだファイルの所定の位置のQRコードから、申込番号を読み取る処理を行う(ステップS603)。
【0094】
次に、クライアント端末104は、ステップS603で申込番号を読み取ることが出来たか否かを判定する(ステップS604)。すなわち、ステップS604では、申込番号を読み取ることが出来たか否かを判定することにより、現在、処理対象のファイルが共通文書であるか、個別文書であるかを判定している。
【0095】
ステップS604で、申込番号を読み取ることが出来なかったと判定された場合は(NO)、ステップS604で読み込んだ現在処理対象のファイルが先頭のファイルであるか否かを判定する(ステップS606)。
【0096】
そして、ステップS606で、現在処理対象のファイルが先頭のファイルであると判定された場合は(YES)、処理をステップS607に移行し、一方、現在処理対象のファイルが先頭のファイルではないと判定された場合は(NO)、処理をステップS609に移行する。
【0097】
ステップS604において、申込番号を読み取ることが出来たと判定された場合は(YES)、ステップS603で読み取られた申込番号をメモリに記憶する(ステップS605)。
【0098】
そして、ステップS605において、クライアント端末104は、メモリに記憶されている登録予定件数に1を加算する。なお、メモリに記憶されている登録予定件数の初期値は0である。
【0099】
次に、クライアント端末104は、現在、処理対象のファイルを先頭のファイルとしてメモリに登録する(ステップS608)。すなわち、ステップS608では、ステップS604で、申込番号を読み取ることが出来たと判定された場合、ステップS603で読み取られた申込番号と、現在処理対象のファイルとを紐付けて(関連付けて)メモリに登録する。
【0100】
ステップS609では、現在、処理対象のファイルと、既に、メモリに先頭のファイルとして登録されているファイルとを結合して、1つのファイルを生成する。そして、当該生成されたファイルを先頭のファイルとして、メモリに記憶する。ステップS609の処理を実行すると、処理をステップS610に移行する。
【0101】
ステップS604において、申込番号の読取ができたと判定され、現在処理対象のファイルが個別文書であると判定された場合は(YES)、処理をステップS605に移行している。この場合、ステップS608では、既にメモリに先頭のファイルとして記憶されているファイルと、現在処理対象のファイルとを結合して、1つのファイルを生成し、メモリに先頭のファイルのとして記憶(登録)する。
【0102】
ステップ610では、ステップS405で取得した全ての読取結果のファイルをステップS602で全て読込んだか否かを判定して、読込んでいないと判定された場合は、ステップS602に処理を戻して、次の読取結果のファイルを読込む。
【0103】
クライアント端末104は、ステップ610で、ステップS405で取得した全ての読取結果のファイルをステップS602で全て読込んだと判定された場合は、処理をステップS408に移行する。以上が図6の説明である。
【0104】
図4の説明に戻る。クライアント端末104は、ステップS407、又はステップS408でファイルの結合処理を実行すると、図15に示すスキャン取込結果画面を表示する(ステップ409)。
【0105】
図15は、スキャン取込結果画面の一例を示す図である。スキャン取込結果画面は、セット件数の表示欄1501、及びスキャン件数の表示欄1502が表示されている。図15に示しているセット件数の表示欄1501には、図14のスキャン取込指示受付画面の1401に、ユーザにより入力されたセット件数を表示している。
【0106】
また、図15に示しているスキャン件数の表示欄1502には、図5のステップS506、又はステップS607で加算され記憶された登録予定件数が表示されている。すなわち、スキャン件数とは、登録予定件数のことを示している。登録予定件数とは、登録しなければならない保険の申込の件数である。すなわち、個別文書の枚数と同一の値となる。
【0107】
そして、クライアント端末104は、ステップS410において、メモリに、スキャンしたデータ(スキャンデータ/スキャンした原稿の画像ファイル)を認識できたことを示す情報が記憶されているか否かを判定する。すなわち、ステップS518で読込中フラグが「ON」に設定されていると判定されたか否かを判定することにより、スキャンしたデータの認識に失敗したか否かを判定する(ステップS410)。
【0108】
ステップS410で、読込中フラグが「ON」に設定されておらず、スキャンしたデータの認識に失敗したと判定された場合は(YES)、図16に示すエラーメッセージを表示する(ステップS413)。
【0109】
一方、ステップS410で、読込中フラグが「ON」に設定されており、スキャンしたデータの認識に成功したと判定された場合は(NO)、処理をステップS411に移行して、1501のセット件数と、1502のスキャン件数(登録予定件数)とが一致するか否かを判定する(ステップS411)。すなわち、ステップS411では、入力を受け付けた個別文書のデータ数と、特定される個別文書のデータの数とが異なるかを判定する。
【0110】
そして、1501のセット件数と、スキャン件数(登録予定件数)1502とが一致しないと判定された場合は(NO)、その旨のメッセージを含む図16に示すエラーメッセージ画面を表示する(ステップS413)。
【0111】
図16は、ステップS413で表示されるエラーメッセージ画面の一例である。図16に示す1601は、OKボタンであり、ユーザによりOKボタン1601が押下されると、エラーメッセージ画面を消して、処理を終了する。このエラーメッセージを表示することにより、ユーザが確認した案件の件数(1501のセット件数)と、ステップS407、又はステップS408でクライアント端末104がカウントした案件の件数(スキャン件数(登録予定件数)1502)とが異なっていることを、ユーザに把握させること可能となる。
【0112】
次に、クライアント端末104は、ステップS411において、1501のセット件数と、スキャン件数(登録予定件数)1502とが一致すると判定された場合は(YES)、ステップS407、又はステップS408で生成されメモリに記憶された複数のファイルを登録する処理(登録手段)を実行して(ステップS412)、処理を終了する。ステップS412の詳細処理を図7に示す。以上が図4の説明である。
【0113】
次に、図7を用いて、図4に示すステップS412(イメージ登録処理)の詳細処理について説明する。図7は、図4に示すステップS412(イメージ登録処理)の詳細処理の一例を示すフローチャートである。図7に示す各ステップの処理は、クライアント端末104のCPU201により実行される。
【0114】
まず、クライアント端末104は、ファイリングサーバ102に、属性情報テーブル(図12)の取得要求を送信する。当該取得要求を受信したファイリングサーバ102は、クライアント端末104に、ファイリングサーバ102のメモリ(RAM202)に記憶されている属性情報テーブルを送信する。そして、クライアント端末104は、ファイリングサーバ102から、属性情報テーブルを取得する。
【0115】
そして、クライアント端末104は、ステップS509、ステップS508、ステップS608でメモリに記憶されたファイルに紐付け(関連付け/対応付け)られて記憶された申込番号を全て取得する。クライアント端末104は、ここで取得した全ての申込番号について、ステップS702の処理を実行するまで、未処理の申込番号ごとに繰り返しステップS701からステップS705の処理を実行する。
【0116】
クライアント端末104は、メモリから取得した現在処理対象の申込番号が、ファイリングサーバ102から取得した属性情報テーブルに含まれているか否かを判定する(ステップS702)。
【0117】
そして、クライアント端末104は、現在処理対象の申込番号が、属性情報テーブルに含まれていると判定された場合は(YES)、現在処理対象の申込番号のファイルの登録要求をファイリングサーバ102に送信する(ステップS703)。ここで送信される登録要求には、現在処理対象の申込番号と、該申込番号に紐付け(関連付け/対応付け)られてメモリに記憶されたファイルと、現在処理対象の申込番号に紐付け(関連付け/対応付け)られて属性情報テーブルに記憶されている証券番号(属性情報)と、が含まれている。
【0118】
そして、ファイリングサーバ102は、クライアント端末104から当該登録要求を受信すると、証券番号と、申込番号と、ファイルとを関連付けて(紐付けて/対応付けて)、ファイリングサーバ102の登録文書テーブル(図13)に記憶する。図13は、登録文書テーブルの一例を示す図である。
【0119】
クライアント端末104は、ステップS702で、現在処理対象の申込番号が、属性情報テーブルに含まれていないと判定された場合は(NO)、現在処理対象の申込番号と、現在処理対象の申込番号に紐付け(関連付け)られて属性情報テーブルに記憶されている証券番号(属性情報)と、該申込番号に紐付け(関連付け)られてメモリに記憶されたファイルと、を含む登録保留のデータを、ファイリングサーバ102のメモリの登録保留フォルダに送信する(ステップS704)。
【0120】
そして、ファイリングサーバ102は、クライアント端末104から該データを受信すると、該データに含まれる、証券番号と、申込番号と、ファイルとを関連付けて(紐付けて/対応付けて)、ファイリングサーバ102の登録保留フォルダに記憶する。クライアント端末104は、ステップS703、ステップS704の処理を実行すると、処理をステップS705に移行する。
【0121】
ステップS705では、処理対象の全ての申込番号のうち、ステップS702の処理を実行していない申込番号があるか否かを判定して、ステップS702の処理を実行していない未処理の申込番号があると判定された場合は、その申込番号を処理対象としてステップS702の処理を実行する。また、ステップS702の処理を実行していない未処理の申込番号がないと判定された場合は、処理を終了する。
【0122】
次に、図8を用いて、登録保留されたファイルの登録・削除処理について説明する。図8は、登録保留されたファイルの登録・削除処理の一例を示すフローチャートである。図8に示す各ステップの処理は、クライアント端末104のCPU201により実行される。
【0123】
クライアント端末104は、ユーザの操作により、登録保留されたファイルのデータ一覧の取得要求を受け付けると、ファイリングサーバ102に、登録保留されたファイルのデータ一覧の取得要求を送信する(ステップS801)。
【0124】
ファイリングサーバ102は、クライアント端末104から、当該取得要求を受け付けると、登録保留フォルダを参照して、「登録保留」として登録されたファイルを全て特定する。そして、ファイリングサーバ102は、特定された全てのファイルに関連付けられた証券番号と申込番号とをクライアント端末104に送信する。
【0125】
クライアント端末104は、ファイリングサーバ102から、登録保留のデータの一覧のデータとして、当該特定された全てのファイルに関連付けられた証券番号と申込番号とを受信すると(ステップS802)、当該受信した全ての証券番号と申込番号とを登録保留のデータ一覧画面(図17)に表示する(ステップS803)。図17は、登録保留のデータ一覧画面の一例を示す図である。
【0126】
そして、クライアント端末104は、登録保留のデータ一覧画面に表示されたリストの中から、ユーザの操作により、ユーザが確認したい文書(レコード)の選択を受け付けると(ステップS804)、選択された登録保留のデータの取得要求をファイリングサーバ102に送信する(ステップS805)。
【0127】
そして、ファイリングサーバ102は、クライアント端末104から、登録保留のデータの取得要求を受信すると、当該ユーザにより選択された文書のファイル、証券番号、申込番号を含むデータをクライアント端末104に送信する。
【0128】
クライアント端末104は、ファイリングサーバ102から、該データを受信すると(ステップS806)、該データに含まれているファイルと、申込番号と、証券番号とを、登録・削除画面(図18)に表示する(ステップS807)。
【0129】
図18は、登録・削除画面の一例を示す図である。図中、1801は、申込番号を表示する表示欄であり、ユーザの操作によって、入力・編集することが可能な表示欄である。
【0130】
また、1802は、証券番号を表示する表示欄であり、ユーザの操作によって、入力・編集することが可能な表示欄である。1803は削除ボタンであり、1804は登録ボタンである。
【0131】
次に、クライアント端末104は、登録・削除画面(図18)の削除ボタン1803をユーザに押下されたか否かを判定し(ステップS808)、削除ボタン1803が押下されたと判定された場合には(YES)、現在、登録・削除画面(図18)に表示されているファイルに係る情報の削除要求を、ファイリングサーバ102に送信する(ステップS811)。
【0132】
ファイリングサーバ102は、クライアント端末104から、ユーザにより選択されたファイルに係る情報の削除要求を受け付けると、登録保留フォルダに記憶されている、該当ファイル、証券番号、申込番号を削除する。
【0133】
また、削除ボタン1803が押下されずに、ユーザにより1801に申込番号が入力され、登録ボタン1804が押下されたか否かを判定し、ユーザにより1801に申込番号が入力され、登録ボタン1804が押下されたと判定された場合、さらに、入力された申込番号が、ファイリングサーバ102の属性情報テーブルに登録されているか否かを確認するために、ファイリングサーバ102に属性情報テーブルの取得要求を送信して、ファイリングサーバ102から、属性情報テーブルを取得し、入力された申込番号が、当該取得した属性情報テーブルに含まれているか否かを判定する。
【0134】
そして、入力された申込番号が、属性情報テーブルに含まれていると判定された場合は(ステップS809:YES)、クライアント端末104は、現在、登録・削除画面(図18)に表示している処理対象の申込番号のファイルの登録要求をファイリングサーバ102に送信する(ステップS810)。ここで送信される登録要求には、該ファイルの申込番号(入力された申込番号)と、該ファイルと、該ファイルの証券番号とを含んでいる。
【0135】
そして、ファイリングサーバ102は、クライアント端末104から当該登録要求を受信すると、証券番号と、申込番号と、ファイルとを関連付けて(紐付けて)、ファイリングサーバ102の登録文書テーブル(図13)に記憶する。
【0136】
クライアント端末104は、ステップS809で、入力された申込番号が、属性情報テーブルに含まれていないと判定された場合は(ステップS809:NO)、図19に示すエラーメッセージの画面を表示する(ステップS812)。
【0137】
図19は、ステップS812で表示されるエラーメッセージ画面の一例を示す図である。図19には、入力された申込番号が属性情報テーブルに登録されていないため、登録文書テーブルに登録することが出来ない旨のメッセージを表示している。そして、ユーザは、図19の画面を確認して、OKボタン1901を押下すると、クライアント端末104は、図19の画面を消して、処理をステップS813に戻す。
【0138】
ステップS811、ステップS810の処理を実行すると、クライアント端末104は、処理をステップS813に移行する。
【0139】
クライアント端末104は、ユーザの操作により終了指示を受け付けたか否かを判定して(ステップS813)、終了指示を受け付けた場合は、処理を終了し、終了指示を受け付けていない場合は、処理をステップS803に移行する。以上が図8の説明である。
【0140】
次に、図9を用いて、ファイリングサーバ102の登録文書テーブル(図13)に登録されているファイルの検索、閲覧処理について説明する。図9は、ファイリングサーバ102の登録文書テーブル(図13)に登録されているファイルの検索、閲覧処理の一例を示すフローチャートである。図9に示す各ステップの処理は、クライアント端末106のCPU201により実行される。
【0141】
クライアント端末106は、ユーザにより検索画面の表示指示を受け付けると、図20に示す検索条件入力画面を表示する(ステップS901)。
【0142】
図20は、検索条件入力画面の一例を示す図である。2001は、申込番号を入力する入力欄である。また、2002は、証券番号を入力する入力欄である。また、2003は、検索ボタンである。
【0143】
クライアント端末106は、ユーザにより、検索条件入力画面(図20)を介して、申込番号(検索条件)、及び/又は、証券番号(検索条件)の入力を受け付け、検索ボタン2003が押下されると(ステップS902)、ファイリングサーバ102に、入力された検索条件を送信する(ステップS903)。
【0144】
そして、ファイリングサーバ102は、当該検索条件を受信すると、当該検索条件に従って、メモリに記憶されている登録文書テーブルを検索して、該当するレコードを特定する。そして、ファイリングサーバ102は、特定されたレコードの全ての情報をクライアント端末106に送信する。
【0145】
クライアント端末106は、ファイリングサーバ102から、当該特定されたレコードの全ての情報を検索結果として受信すると(ステップS904)、受信した情報を検索結果表示画面(図21)に表示する。
【0146】
図21は、検索結果表示画面の一例を示す図である。2101は、ファイルを表示する領域であり、2102は、検索条件となる申込番号や証券番号を表示する領域である。2103は、前のページに遷移するボタンであり、2104は、次のページに遷移するボタンである。2105は、戻るボタンである。
【0147】
以上、本発明の第1の実施の形態に係る発明によれば、ユーザによる共通文書のデータと個別文書のデータを1つのファイルとして登録する煩雑な作業を軽減する共に、個別文書のデータを特定する作業を効率化させることができる。
【0148】
また、複数の個別文書と、共通文書をまとめて取得することで、当該個別文書と共通文書の組み合わせのデータを複数生成することができる仕組みを提供することができる。
【0149】
[第2の実施の形態]
【0150】
以下、本発明の第2の実施の形態について説明する。第1の実施の形態では、共通文書と個別文書とをスキャナで読み込んだ後に、共通文書と、個々の個別文書からなる
【0151】
複数のファイルを作成し、検索データとして登録する例について説明した。この例では、同一の共通文書が複数登録されることにより、データの記憶量が増大してしまう。そこで、第2の実施の形態では、個別文書を検索データとして登録する際に、共通文書と関連付けて登録し、閲覧(確認)する際に、閲覧(確認)したい個別文書とその個別文書に関連付いた共通文書とを合わせて表示可能にする例について説明する。つまり、個別文書と共通文書を結合したファイルを生成することなく、当該個別文書と共通文書の組み合わせを示すデータを複数生成する実施例について説明する。尚、第2の実施の形態の説明では、第1の実施の形態と異なる処理についてのみ説明することにする。
【0152】
当該第2の実施形態において、クライアント端末104は、図5のステップS506及びステップS519(つまり図5Aの処理)に代えて、個別文書のファイルと、共通文書のファイルとを関連付けるための関連付け情報を生成し、メモリに記憶する関連付け情報生成処理を行う。この関連付け情報は、共通文書のファイル名と、個別文書のファイル名とを関連付けるための情報である。
【0153】
以下、関連付け情報生成処理について説明する。具体的には、クライアント端末104がステップS510で外部メモリに記憶した個別文書のファイルであって、ステップS502で未取得の個別文書のファイルを1つ取得し、当該図5Aの処理(図5のステップS506の処理)の開始時点で処理中のファイルの直前に記憶された、共通文書のファイル(ステップS515で記憶されたファイル、又はステップS516で結合されて生成されたファイル)を取得する。
そして、クライアント端末104は、取得した個別文書のファイルと共通文書のファイルと、当該個別文書から取得した申込番号とを含む、当該それぞれのファイルを関連付ける関連付け情報を生成して、クライアント端末104の外部メモリに記憶する。上述した、個別文書のファイルの取得処理、共通文書のファイルの取得処理、当該取得した個別文書のファイルと共通文書のファイルとを関連付ける関連付け情報の生成処理を、QRコード件数分繰り返した後、当該QRコード件数の値を「0」に更新し、処理を終了する。以上が、関連付け情報生成処理の説明である。
【0154】
このように、第2の実施の形態における生成手段は、共通文書のデータと個別文書データとを含む1つのファイルを生成するのではなく、それらを関連付ける関連付け情報を生成する。ここでは、複数の個別文書のファイルそれぞれについて、共通文書のファイルとの関連付けのための関連付け情報を生成する。
【0155】
これにより、個別文書と共通文書を結合したファイルを生成することなく、当該個別文書と共通文書の組み合わせを示すデータを複数生成することができる。
【0156】
次に、図24を用いて、第2の実施の形態における図4に示すステップS412(イメージ登録処理)の詳細処理について説明する。図24は第2の実施の形態における図4のステップS412(イメージ登録処理)の詳細処理の一例を示すフローチャートである。図24に示す各ステップの処理は、クライアント端末104のCPU201により実行される。
【0157】
まず、クライアント端末104は、ファイリングサーバ102に、属性情報テーブル(図12)の取得要求を送信する。当該取得要求を受信したファイリングサーバ102は、クライアント端末に、ファイリングサーバ102のメモリ(RAM202)に記憶されている属性情報テーブルを送信する。そして、クライアント端末104は、ファイリングサーバ102から、属性情報テーブルを取得する。
【0158】
そして、クライアント端末104は、外部メモリに記憶された関連付け情報、及び、図5の各記憶処理で記憶された個別文書のファイル、共通文書のファイルを取得する。
【0159】
クライアント端末104は、個々で取得した全ての共通文書、個別文書に対してステップS2402の処理を実行するまで、未処理の共通文書、個別文書に対して繰返しステップS2401からステップ2408の処理を実行する。
【0160】
クライアント端末104は、取得した共通文書または個別文書のうち、未処理の文書データを取得する(ステップS2402)。そして、取得した文書データが共通文書であるか否かを判定する(ステップS2403)。
【0161】
そして、クライアント端末104は、現在処理対象の文書データが、共通文書であると判定した場合は(YES)、共通文書を検索データとして登録させるべく、ファイリングサーバ102に対して、共通文書の登録要求を送信する(ステップS2404)、ここで送信される登録要求には、共通文書ファイル及びそのファイル名が含まれている。
【0162】
そして、ファイリングサーバ102は、クライアント端末104から当該要求を受け付けると、これら情報をファイリングサーバ102の登録文書テーブル(図23)に記憶する。尚、第2の実施の形態における登録文書テーブルのデータ構成の詳細については、図23を参照して後述する。
【0163】
一方、ステップS2403で、現在処理対象の文書データが、共通文書ではない(つまり、個別文書である)と判定された場合は(NO)、処理をステップS2405に進め、現在処理対象の個別文書の申込番号が、ファイリングサーバ102から取得した属性情報テーブルに含まれているか否かを判定する。
【0164】
そして、クライアント端末104は、現在処理対象の個別文書の申込番号が、属性テーブルに含まれていると判定された場合は(ステップS2405:YES)、現在処理対象の個別文書を検索対象データとして登録する登録要求をファイリングサーバ102に対して送信する(ステップS2406)。ここで送信される登録要求には、現在処理対象の個別文書の画像ファイル、該画像ファイルに紐付け(関連付け)られている申込番号、また申込番号に紐付け(関連付け)られて属性情報テーブルに記憶されている証券番号(属性情報)と、が含まれている。また、当該個別文書と共通文書の関連付け情報がメモリに記憶されている場合には、当該個別文書に関連付けられている共通文書のファイル名もこの登録要求に含まれることになる。
【0165】
そして、ファイリングサーバ102は、クライアント端末104から当該登録要求を受信すると、これら情報を図23に示す登録文書テーブルに登録する。
【0166】
クライアント端末104は、ステップS2405で、現在処理対象の個別文書に関連付けられた申込番号が属性情報テーブルに含まれていないと判定された場合は(NO)、現在処理対象の個別文書を登録保留のデータとして登録する登録要求をファイリングサーバ102に対して送信する(ステップS2407)。ここで送信される登録要求には、現在処理対象の個別文書の画像ファイル、該画像ファイルに紐付け(関連付け)られている申込番号、また申込番号に紐付け(関連付け)られて属性情報テーブルに記憶されている証券番号(属性情報)と、が含まれている。また、当該個別文書と共通文書の関連付け情報がメモリに記憶されている場合には、当該個別文書に関連付けられている共通文書のファイル名もこの登録要求に含まれることになる。
【0167】
そして、ファイリングサーバ102は、クライアント端末104から当該登録要求を受信すると、これら情報を図23に示す登録文書テーブルに登録する。
【0168】
ステップS2408では、処理対象のすべての文書データに対してステップS2402以降の処理を実行したか否かを判定して、ステップS2402以降の処理を実行していない未処理の文書データがあると判定された場合は、未処理の文書データに対して上記処理を実行するために、処理をステップS2402に移行する。また、全ての文書データに対してステップS2402以降の処理を実行したと判定された場合は、処理を終了する。以上が図24の説明である。
【0169】
ここで、図23を用いて、第2の実施の形態における登録文書テーブルのデータ構成の一例について説明する。図23に示すように、登録文書テーブルは、証券番号、申込番号、ファイル、共通文書ファイル、登録保留フラグ等のデータ項目を備えて構成されている。
【0170】
共通文書データと関連付けられている個別文書データの共通文書ファイルには、関連付けられている共通文書のファイル名が登録される。そして、個別文書を閲覧(確認)する際には、ファイリングサーバ102は、個別文書だけではなく、当該個別文書に関連付けられている共通文書も用いて閲覧時に表示する表示データを作成することになる。
【0171】
クライアント端末104から、登録保留のデータとしての登録要求がなされた個別文書の登録保留フラグには、登録が保留されていることを示す情報(図中では「○」)が設定されることになる。
【0172】
尚、証券番号、申込番号、ファイルについては、図13に示す第1の実施の形態における登録文書テーブルと同様であるので、ここでの説明は割愛する。以上が、本発明の第2の実施の形態における登録文書テーブルのデータ構成の一例の説明である。
【0173】
次に、図25を参照して、第2の実施の形態における、登録保留されたファイルの登録・削除処理について説明する。図25は、登録保留されたファイル(個別文書)の登録・削除処理の一例を示すフローチャートである。図25に示すステップの処理は、クライアント端末104のCPU201、またはファイリングサーバ102のCPU201により実行される。尚、この処理は図8を用いて既に説明した、登録保留されたファイルの登録・削除処理に相当する処理である。
【0174】
クライアント端末104は、ユーザの操作により、登録保留されたデータ(個別文書)のデータ一覧の取得要求を受け付けると、ファイリングサーバ102に、登録保留された
データのデータ一覧の取得要求を送信する(ステップS2501)。
【0175】
ファイリングサーバ102は、クライアント端末104からの登録保留のデータ一覧の取得要求を受信すると(ステップS2502)、登録文書テーブルを参照し、登録保留フラグに「○」が設定されている登録保留のデータ(個別文書)を取得する。そして取得したデータを用いてデータ一覧を作成し、取得要求を行ったクライアント端末104に対して送信する(ステップS2503)。ここでは、登録保留のデータの証券番号と申込番号を少なくとも含む一覧データをクライアント端末104に対して送信する。
【0176】
クライアント端末104は、ファイリングサーバ102から、登録保留のデータの一覧のデータとして、当該特定された全てのファイルに関連付けられた証券番号と申込番号とを受信すると(ステップS2504)、当該受信した全ての証券番号と申込番号とを登録保留のデータ一覧画面(図17)に表示する(ステップS2505)。
【0177】
そして、クライアント端末104は、登録保留のデータ一覧画面に表示されたリストの中から、ユーザの操作により、ユーザが確認したい登録保留のデータの選択を受け付けると(ステップS2506)、選択された登録保留のデータの取得要求をファイリングサーバ102に送信する(ステップS2507)。
【0178】
そして、ファイリングサーバ102は、クライアント端末104から、登録保留のデータの取得要求を受信すると(ステップS2508)、当該指定された登録保留のデータ(個別文書)を取得する(ステップS2509)。その後、当該登録保留のデータに関連付けられている共通文書データがあるかを、登録文書テーブルを用いて判定する(ステップS2510)。具体的には、当該登録保留のデータを記憶管理する登録文書テーブル中のレコードの共通文書ファイルに共通文書のファイル名が登録されているか否かにより、ファイリングサーバ102はこの判定を行う。
【0179】
選択された登録保留データに関連する共通文書があると判定された場合は(ステップS2510:YES)、ファイリングサーバ102は、登録保留データに関連付けられた共通文書データを取得し(ステップS2512)、取得した登録保留データと共通文書データを用いて表示用データを作成する(ステップS2513)。
【0180】
一方、選択された登録保留データに関連する共通文書がないと判定された場合は(ステップS2510:NO)、ファイリングサーバ102は、ステップS2509で取得した登録保留されている個別文書データを用いて、表示用データを作成する(ステップS2511)。
【0181】
そして、ファイリングサーバ102は、ステップS2511、または、ステップS2513で作成した表示用データをクライアント端末104に対して送信する(ステップS2514)。
【0182】
クライアント端末104は、ファイリングサーバ102から、選択された登録保留データの表示用データを受信すると(ステップS2515)、当該登録保留データの申込番号、証券番号と表示用データ(画像データ)を登録・削除画面(図18)に表示する(ステップS2516)。
【0183】
登録・削除画面を表示後、登録・削除画面に設定されている削除ボタン1803が押されたか否かを判定し(ステップS2517)、削除ボタン1803が押されたと判定された場合は(YES)、現在、登録・削除画面(図18)に表示されている登録保留データに係る情報の削除要求をファイリングサーバ102に送信する(ステップS2518)。
【0184】
ファイリングサーバ102は、クライアント端末104から登録保留のデータ(個別文書)の削除指示を受け付けると(ステップS2519)、選択された登録保留のデータの削除処理を行う(ステップS2520)。この処理の詳細については、図26を参照して後述する。そして、ステップS2520の登録保留データの削除処理が終了後、処理をステップS2525に移す。
【0185】
クライアント端末104は、ステップS2517の判定処理で、削除ボタン1803が押されていないと判定された場合は(NO)、登録・削除画面に設定されている登録ボタン1804が押されたか否かを判定する(ステップS2521)。この判定処理で登録ボタンが押されたと判定された場合は(YES)、現在、登録・削除画面(図18)に表示されている登録保留データに係る登録要求をファイリングサーバ102に送信する(ステップS2522)。
【0186】
ファイリングサーバ102は、クライアント端末104から登録保留のデータの登録要求を受信すると(ステップS2523)、指定を受け付けた登録保留のデータを検索データとして登録する(ステップS2524)。具体的には、登録文書テーブルに記憶されている登録要求を受け付けた登録保留のデータ(個別文書)を管理するレコードの登録保留フラグに登録されている登録が保留されていることを示す情報(図中では「○」)を消去する、その後、処理をステップS2525に移す。
【0187】
ファイリングサーバ102は、ステップS2520またはステップS2524が終了後、処理をステップS2525に移し、処理結果を登録保留のデータの削除、または登録の要求を行ったクライアント端末104に対して送信する。クライアント端末104は、ファイリングサーバ102からの処理結果を受信する。その後、処理をステップS2526。尚、ファイリングサーバ102より受信した処理結果が、処理失敗を示すものである場合には、ユーザに対して処理が失敗した旨を報知すべく、エラー表示を行う。
【0188】
クライアント端末104は、その後、ユーザの操作指示に基づいて終了指示を受け付けたかを判定する(ステップS2527)。終了指示を受け付けていないと判定された場合は(NO)、処理をステップS2505に移し、それ以降の処理を繰り返し実行する。また、終了指示を受け付けたと判定した場合は(YES)、本図に示す処理を終了する。以上が図25の説明である。
【0189】
次に、図26を用いて、図25のステップS2520の登録保留データ削除処理の詳細について説明する。図25に示す各ステップの処理は、ファイリングサーバ102のCPU201によって実行される。
【0190】
ファイリングサーバ102は、クライアント端末104より削除指示を受け付けた登録保留のデータを取得しRAM202に記憶した後に、登録文書テーブルから、当該登録保留のデータを記憶管理しているレコードを削除する(ステップS2601)。そして、削除指示された登録保留のデータ(個別文書)に共通文書が関連付けられていたかを判定する(ステップS2602)。
【0191】
ファイリングサーバ102は、ステップS2602の判定処理で共通文書が関連付けられていると判定された場合は(YES)、処理をステップS2603に移す。一方、共通文書が関連付けられていないと判定された場合は(NO)、本図に示す処理を終了する。
【0192】
ファイリングサーバ102は、ステップS2603において、削除指示を受け付けた登録保留のデータ(個別文書)に関連付けられている共通文書を特定し、その後、特定した共通文書に関連付けられている他の検索データ、他の登録保留データがあるかを、登録文書テーブルを用いて判定する(ステップS2604)。
【0193】
ファイリングサーバ102は、ステップS2604の判定処理で、ステップS2603で特定した共通文書に関連付けられている他の検索データ、他の登録保留のデータがないと判定した場合は(NO)、処理をステップS2605に移し、ステップS2603で特定した共通文書を記憶管理するレコードを登録文書テーブルから削除する。また、記憶装置に記憶されている共通文書のイメージファイルも削除することになる。そして、本図に示す処理を終了する。一方、ステップS2604の判定処理で、ステップS2603で特定した共通文書に関連付けられている他の検索データ、登録保留のデータがあると判定した場合は(YES)、ステップS2605の処理を行うことなく、本図に示す処理を終了する。以上が図26の説明である。
【0194】
次に、図27を用いて、第2の実施の形態における、ファイリングサーバ102の登録文書テーブル(図23)に登録されているファイルの検索・閲覧処理について説明する。図27は、ファイリングサーバ102の登録文書テーブル(図23)に登録されているファイルの検索、閲覧処理の一例を示すフローチャートである。図23に示す各ステップの処理は、クライアント端末106のCPU201またはファイリングサーバ102のCPU201により実行される。尚、この処理は、図9を用いて説明したファイル検索・閲覧処理に相当する処理である。
【0195】
クライアント端末106は、ユーザにより検索画面の表示指示を受け付けると、図20に示す検索条件入力画面を表示する(ステップS2701)。そして、クライアント端末106は、ユーザからの操作指示により、検索条件入力画面(図20)を介して申込番号(検索条件)、及び/又は、証券番号(検索条件)の入力を受け付けた後に、検索ボタン2003が押下されると(ステップS2702)、ファイリングサーバ102に入力された検索条件を含む検索要求を送信する(ステップS2703)。
【0196】
ファイリングサーバ102は、クライアント端末106から送信された検索要求を受信すると(ステップS2704)、受信した検索要求に合致する、登録文書テーブル2300(図23)に登録されている検索データ(登録保留フラグに「○」が登録されていないデータ)を検索する(ステップS2705)。そして、ステップS2705の検索処理の結果、受信した検索条件に合致する検索データがないと判定される場合は(ステップS2706:NO)、処理をステップS2707に移し、検索エラー通知を、検索要求を行ったクライアント端末106に対して送信する。
【0197】
クライアント端末106は、ファイリングサーバ102から送信された検索エラー通知を受信すると(ステップS2708)、ユーザに検索エラーを報知すべく、検索エラー表示を行う(ステップS2709)。そして、処理をステップS2718に移す。
【0198】
ファイリングサーバ102は、ステップS2706の判定処理で、検索条件に合致する検索データがあると判定される場合に(YES)、処理をステップS2710に移し、検索条件に合致した検索データ(個別文書)を取得する。そして、取得した検索データに共通文書が関連付けられているかを判定する(ステップS2711)。
【0199】
ステップS2711の判定処理で、共通文書が関連付けられていると判定される場合は(YES)、ファイリングサーバ102は処理をステップS2713に進め、ステップS2710で取得した検索データ(個別文書)に関連付けられている共通文書を取得し、共通文書と検索データを用いて表示用データを作成する(ステップS2714)。一方、ステップS2711の判定処理で、共通文書が関連付けられていないと判定される場合は(NO)、処理をステップS2712に進め、ステップS2710で取得した検索データを用いて表示用データを作成する。
【0200】
ファイリングサーバ102はその後、ステップS2712、または、ステップS2714で生成した表示用データを、検索要求を行ったクライアント端末106に対して送信する。
【0201】
クライアント端末106は、ファイリングサーバ102から送信された表示用データを受信すると(ステップS2716)、表示用データの表示を行う(ステップS2717)。その後、処理をステップS2718に移す。
【0202】
クライアント端末106は、その後、ユーザからの操作指示により、終了指示を受け付けたかを判定し(ステップS2718)、受け付けていないと判定される場合は(NO)、処理をステップS2702に移し、それ以降の処理を繰り返し実行する。一方、終了指示を受け付けたと判定される場合は(YES)、本図に示す処理を終了する。以上が、第2の実施の形態における、検索・閲覧処理の詳細である。
【0203】
以上説明したとおり、第2の実施の形態では、文書の登録を行う際に共通文書と個別文書を関連付けた形でそれぞれ独立した形で登録し、文書の内容を表示する際に、それら文書から表示用データを作成し、表示させるようにしている。これにより、それぞれの個別文書の確認を行う際に、その個別文書に関連する共通文書も合わせて表示することが可能となるとともに、共通文書を複数登録する必要がなくなり、記憶容量を削減可能になる。
[第3の実施の形態]
【0204】
次に図28図32を用いて、本発明の第3の実施の形態について説明する。本実施例では、先の第1、第2の実施の形態で、最後の共通文書よりも後に取り込んだ個別文書をエラーとしていた処理(具体的には図5のステップS521)をエラーとすることなく、それぞれ共通文書のない個別文書として登録する。これにより、共通文書がない個別文書についても、共通文書がある個別文書と一緒にファイリングサーバ102に登録することが可能となる。
【0205】
まず、図28を用いて、本発明の第3の実施の形態における、図4に示すステップS407(個別文書の識別情報を用いた結合処理)の詳細処理について説明する。図28は、図4に示すステップS407(個別文書の識別情報を用いた結合処理)の詳細処理の一例を示すフローチャートである。図28に示す各ステップの処理は、クライアント端末104のCPU201により実行される。なお、図5と同様の処理については、詳細な説明は省略する。
【0206】
ステップS2801〜ステップS2820までの各ステップは、図5のステップS501〜ステップS520までの各ステップと同様であり、ステップS2822の処理は、ステップS522と同様であるため説明は省略する。
【0207】
ステップS2821において、クライアント端末104は、最後に生成した(ステップS2815又はステップS2816)共通文書のファイルより後に認識した個別文書のファイル(つまり、共通文書のファイルを読み取ることによって、ステップS2817でセパレータフラグがOFFになった後に認識した個別文書のファイルであって、当該個別文書のファイルの後に共通文書のファイルを認識しなかった個別文書のファイル)を結合する共通文書のファイルがない個別文書のファイルとして登録する処理を実行する。ステップS2821の処理の詳細については、図29を用いて説明する。
【0208】
ステップS2821の処理が終了すると、図4のステップS411に進む。
以上で、図28の説明を終了する。次に、図29について説明する。
【0209】
図29は、図28のステップS2821の個別文書ファイル登録処理の詳細を示すフローチャートである。図29に示す各ステップの処理は、クライアント端末104のCPU201により実行される。
【0210】
ステップS2901において、クライアント端末104は、ステップS502で全てのファイルを読み込んだ場合に、最後に生成した(ステップS2815又はステップS2816)共通文書のファイルと、当該共通文書のファイルの前に記憶された(ステップS510)、共通文書のファイルと未結合の個別文書のファイルと、の結合処理を行う。ステップS2901の結合処理は図5Aと同様であるため説明は省略する。
【0211】
ただし、ステップS2901の結合処理から図5Aの処理に移行する場合、図5AのステップS532〜S535の処理は、最後に生成した共通文書のファイルの前に記憶された、共通文書と未結合の個別文書のファイルに対してのみ実行する。つまり、最後に生成した(ステップS2815又はステップS2816)共通文書のファイルより後に記憶された共通文書と未結合の個別文書のファイルに対しては、図5Aの処理は行わない。また、ステップS2901の結合処理の場合、図5AのステップS536の処理は行わない。
【0212】
なお、本実施例では、共通文書のファイルについては、ステップS2902の結合処理で個別文書のファイルと結合する前に、個別文書のファイルと結合する前の共通文書のファイルを複製し、クライアント端末104の外部メモリに記憶しておき、後述するステップS2907では、この複製した共通文書のファイルを個別文書のファイルとの結合に使用するものとする(複数の個別文書のファイルと結合する場合には、複数複製するものとする)。
【0213】
複製した共通文書のファイルは、図4のステップS412のイメージ登録処理が終了したときに削除する。
【0214】
ステップS2902において、クライアント端末104は、最後に生成した(ステップS2815又はステップS2816)共通文書のファイルより後に記憶された共通文書と未結合の個別文書のファイルそれぞれを、クライアント端末104の外部メモリに、ステップS507でメモリに記憶された申込番号と対応付けて記憶する。
【0215】
ステップS2903において、クライアント端末104は、後述する図30に示すスキャン取込結果画面を表示する。
【0216】
図30は、スキャン取込結果画面の一例を示す図である。スキャン取込結果画面は、セット件数の表示欄3001、及びスキャン件数の表示欄3002、結合候補確認ボタン3003が表示されている。図15に示しているセット件数の表示欄3001には、図14のスキャン取込指示受付画面の1401に、ユーザにより入力されたセット件数を表示している。
【0217】
また、図30に示しているスキャン件数の表示欄3002には、図5のステップS511、又はステップS607で加算され記憶された登録予定件数が表示されている。すなわち、スキャン件数とは、登録予定件数のことを示している。登録予定件数とは、登録しなければならない保険の申込の件数である。すなわち、個別文書の枚数と同一の値となる。
【0218】
また、図30に示している結合候補確認ボタン3003が押下されると、後述する図31の画面を表示する。
【0219】
ステップS2904において、クライアント端末104は、ステップS2903でスキャン取込結果画面(図30)を介して、結合候補確認ボタン(3003)がユーザにより押下されたかを判断する。結合候補確認ボタンがユーザにより押下されたならば、ステップS2905に進み、結合候補確認ボタンがユーザにより押下されなければ(図30の画面右上の「×」がユーザにより押下されたならば)、ステップS2909に進む。
【0220】
ステップS2905において、クライアント端末104は、ステップS2815又はステップS2816で生成した共通文書のファイルをファイリングサーバ102から受信し、結合候補確認画面(後述する図31)を表示する。
【0221】
ステップS2906において、クライアント端末104は、結合候補確認画面(後述する図31)を介して、最後に生成した(ステップS2815又はステップS2816)共通文書のファイルより後に記憶された、共通文書と未結合の個別文書のファイルと、共通文書とを結合する指示をユーザから受け付けたか否かを判定する。最後に生成した(ステップS2815又はステップS2816)共通文書のファイルより後に記憶された、共通文書と未結合の個別文書のファイルと、共通文書とを結合する指示(具体的には後述する図31の3104がユーザにより押下された)を受け付けたならば、ステップS2907に進み、最後に生成した(ステップS2815又はステップS2816)共通文書のファイルより後に記憶された、共通文書と未結合の個別文書のファイルと、共通文書とを結合する指示を受け付けなければ(具体的には後述する図31の3106がユーザにより押下されたならば)、ステップS2909に進む。
【0222】
ステップS2907において、クライアント端末104は、結合候補確認画面(後述する図31)を介して、結合する指示を受け付けた個別文書のファイルと共通文書のファイルを結合し、1つのファイルとする。
【0223】
ステップS2908において、クライアント端末104は、ステップS2907で結合した個別文書のファイルと共通文書のファイルを含むファイルを、1つの保険申し込み案件のファイルとして、クライアント端末104の外部メモリに、ステップS507でメモリに記憶された申込番号と対応付けて記憶する。
【0224】
ステップS2909において、クライアント端末104は、クライアント端末104は、二次元コード件数の値を「0」に更新し、処理を終了する。
以上で、図29の説明を終了する。
【0225】
図29の処理を行うことにより、例えば、ユーザが共通文書と紐付けて記憶すべき個別文書を、誤って紐付けて記憶すべき共通文書よりあとにスキャナで取り込んでしまった場合に、共通文書と紐付けられることなくファイリングサーバ102に登録されることを防ぐことが出来る。
【0226】
次に図31を用いて、図30のステップS2905でクライアント端末104に表示される画面について説明する。
【0227】
図31は、図30のステップS2905でクライアント端末104に表示される画面の一例であり、未結合の個別文書のファイルと共通文書のファイルを結合するための画面の一例を示す図である。
【0228】
3101には、最後に生成した(ステップS2815又はステップS2816)共通文書のファイルより後に記憶された、共通文書と未結合の個別文書のファイルが表示される。最後に生成した(ステップS2815又はステップS2816)共通文書のファイルより後に記憶された、共通文書と未結合の個別文書のファイルが複数ある場合には、不図示の切替ボタンで、共通文書のファイルと結合するファイルを選択することが出来る。
【0229】
3102には、ステップS2815又はステップS2816で共通文書のファイルとして記憶されたファイルのイメージが表示される。図31の場合、A1〜A3、B1〜B2がそれぞれひとつの共通文書のファイルのまとまりである。
【0230】
3103は、チェックボックスであり、ユーザはマウス等の操作により、3101に表示された個別文書のファイルと紐付けたい共通文書のファイルのチェックボックスにチェックを入れる。
【0231】
3104は、結合ボタンである。ユーザによりチェックボックス3103にチェックが入れられた後に、結合ボタン3104がユーザ操作により押下されると、チェックボックス3103にチェックが入れられた共通文書のファイルと、3101に表示された個別文書のファイルとが結合され、1つのファイルとなる。
【0232】
3105は、登録ボタンであり、登録ボタン3105がユーザ操作により押下されると、3104のボタンがユーザ操作により押下されることにより結合され、ひとつとなった共通文書と個別文書を含むファイルが、1つの保険申し込み案件のファイルとして、クライアント端末104の外部メモリに、ステップS507でメモリに記憶された申込番号と対応付けて記憶される。
【0233】
3106は、キャンセルボタンであり、キャンセルボタン3106が押下されると、図31の画面を閉じる。
以上で図31の説明を終了する。
【0234】
次に、図32を用いて、第3の実施の形態において、複数の個別文書、共通文書から、複数のファイル(共通文書と個別文書とが結合されたファイルと、個別文書だけのファイル)をそれぞれ生成することを説明する。
【0235】
図32は、複数の個別文書、共通文書から、複数のファイル(共通文書と個別文書とが結合されたファイルと、個別文書だけのファイル)をそれぞれ生成することを説明するための図である。
【0236】
個別文書3201、個別文書3202、共通文書3203、個別文書3204の順番で、スキャナでスキャンされ、スキャンされたそれぞれの文書の画像データのファイル(1ページ1ファイルの画像データ)を、スキャナ105から順番に、クライアント端末104は取得する。
【0237】
先述の図4のステップS407では、個別文書3201と、共通文書3203を含むファイルA、個別文書3202と、共通文書3203を含むファイルB、個別文書3204を含むファイルC、をそれぞれ生成する。
【0238】
すなわち、クライアント端末104は、ある個別文書が読み込まれた後、次の個別文書が読み込まれるまで、又は全ての画像ファイルの読込みが終了するまでに読み込まれた、二次元コード(申込番号が埋め込まれた二次元コード)を含まない文書を共通文書として特定する。そして、当該共通文書が読み込まれる前に連続して読み込まれた個別文書(例えば、個別文書3201、3202)の数だけ、当該共通文書をコピーして、それぞれの個別文書と結合したファイルA、ファイルBを生成する。
【0239】
また、クライアント端末104は、ある個別文書が読み込まれた後に、二次元コード(申込番号が埋め込まれた二次元コード)を含まない文書を読み込むことなく、画像ファイルの読込みが終了した場合、その個別文書は、共通文書がない個別文書としてファイルCを生成する。なお、複数の個別文書が連続して読み込まれた後に、二次元コード(申込番号が埋め込まれた二次元コード)を含まない文書を読み込むことなく、画像ファイルの読込みが終了した場合、それぞれの個別文書を共通文書がない個別文書とし、それぞれ別ファイルで生成する。
【0240】
なお、本実施例では、図32で、ファイルA、ファイルB、ファイルCを生成するとしたが、他の実施例として、個別文書と共通文書の関連付け情報を記憶するだけでも良い。例えば、図32の場合、共通文書3203が、個別文書3201と個別文書3202それぞれと関連付いているという情報を記憶するのみでも良い。その場合、図29のステップS2907で、例えば個別文書3204と共通文書3203を結合する場合、個別文書3204と共通文書3203が関連付いているという情報を記憶することになる。
以上で図32の説明を終了する。
【0241】
尚、例えば、クライアント端末104が、図4のステップS406後に、ステップS402で入力を受け付けたセット件数が所定数以上か否かを判定し(セット件数判定手段)、所定数以上であった場合に、処理をステップS407に移行し、所定数より少なかった場合に、処理をステップS408に移行するようにしてもよい。当該所定数の値は、クライアント端末104の外部メモリに予め記憶されているものとする。
【0242】
例えばセット件数が1であった場合、上述した第1の実施形態における図5、及び図5Aの処理や、第2の実施形態における関連付け情報の生成処理等、スキャンしたデータが個別文書か共通文書かに応じていずれのファイルと結合するか、又は関連付けるかを決定する複雑な処理を行う必要はなく、単純に1つの結合ファイルを作成する通常の結合処理(ステップS408)で足りるためである。
【0243】
上述した、ステップS402で入力を受け付けたセット件数が所定数以上か否かの判定を行い、当該判定結果に応じて処理を切り替えることで、セット件数が所定数より少ない場合に、上述した第1の実施形態における図5、及び図5Aの処理や、第2の実施形態における関連付け情報の生成処理を回避し、処理負荷を軽減しつつ、文書の組み合わせの情報を生成することができる。
【0244】
尚、当該所定数の値は1に限るものではなく、ユーザ操作に応じて任意に設定、変更可能であるものとする。
【0245】
本発明では、上記のような処理を行うことで、共通文書と複数の個別文書をスキャンし、それぞれの個別文書を共通文書と関連付けて登録する際に、ユーザよって行われる煩雑な作業を軽減する共に、個別文書を確認する際に、関連する共通文書を容易に確認可能とすることで、個別文書のデータを確認する作業を効率化させることができる。
【0246】
以上、本発明の実施形態を詳述したが、本発明は、例えば、システム、装置、方法、装置で読み取り実行可能なプログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【0247】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
【0248】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【0249】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、磁気テープ、不揮発性のカード、ROM等を用いることができる。
【0250】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOS(基本システム或いはオペレーティングシステム)などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【0251】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【符号の説明】
【0252】
101 ホストコンピュータ
102 ファイリングサーバ
103 プリンタ
104 クライアント端末
105 スキャナ
106 クライアント端末
107 ネットワーク
図1
図2
図3
図4
図5
図5A
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31
図32