(57)【要約】【課題】申請書入力作業における不正入力、データ改竄を抑止し、照会問合せに迅速に対応可能な申請書追跡管理システムを提供する。【解決手段】顧客情報管理ＤＢ2を備えた申請業務サーバ1と、申請書を印刷しかつ申請書番号を読み取り申請業務サーバへ返却するプリンタ7と、処理指示を入力する端末とを有する申請書追跡管理システムであって、申請業務サーバは、申請書印刷の処理指示及び顧客識別情報に応じて、顧客情報管理ＤＢの顧客情報を読み出してプリンタに申請書を印刷させ、プリンタからの申請書番号と顧客識別情報および申請書の種類とを紐付けて申請書管理ＤＢ3に格納する手段と、複数の処理経過において、申請書番号と、申請書ステータス情報、実行時点情報および担当者識別情報とを紐付けて申請書追跡管理ＤＢ4に格納する手段と、申請書管理ＤＢまたは申請書追跡管理ＤＢを検索する手段とを有する。【選択図】図１
2010073081.tif 000002
【特許請求の範囲】
【請求項１】
顧客識別情報と顧客基本情報および顧客契約情報とを紐付けて予め格納する顧客情報管理ＤＢを備えた申請業務サーバと、該申請業務サーバからの制御により申請書を印刷するとともに該印刷した申請書から固有の申請書番号を読み取り該申請業務サーバへ返却するプリンタと、この申請業務サーバに対する処理指示を入力し処理結果を表示するための端末とを有する申請書追跡管理システムであって、前記申請業務サーバは、
前記端末からの申請書印刷の処理指示及び該端末に入力された顧客識別情報に応じて、該顧客識別情報に基づいて前記顧客情報管理ＤＢに格納された顧客基本情報および顧客契約情報を読み出して前記プリンタに申請書を印刷させるとともに、該プリンタから返却された該申請書番号と該顧客識別情報および該申請書の種類とを紐付けて申請書管理ＤＢに格納する手段と、
前記申請書印刷の処理経過を含め、印刷後の該申請書に関する複数の処理経過の各々において、前記申請書番号と、該処理の実行後の申請書ステータス情報、該処理の実行時点情報および該処理を行った担当者の担当者識別情報とを紐付けて申請書追跡管理ＤＢに格納する手段と、
前記顧客識別情報または前記担当者識別情報に基づいて前記申請書管理ＤＢまたは前記申請書追跡管理ＤＢを検索する手段とを有することを特徴とする申請書追跡管理システム。
【請求項２】
前記申請業務サーバが、前記申請書追跡管理ＤＢに対するアクセス権限の制御として、一般ユーザにはデータの選択、挿入および読み取りの権限のみを可能とし、システム管理者にはさらにデータの更新および削除を可能とするセキュリティ手段をさらに有することを特徴とする請求項１に記載の申請書追跡管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、非接触型ＩＣタグによる申請書類の管理技術に対して、申請書類の処理経路を証跡として管理し追跡可能とする申請書追跡管理システムに関するものである。
【背景技術】
【０００２】
申請手続きのオンライン化（電子申請）の環境整備拡大に伴い、インターネットを使い申請者自身で手軽に申請手続きが可能になってきている。しかし、インターネットに不慣れな、あるいはインターネット環境にない申請者などの場合、紙媒体の申請書の利用による手続きも依然として不可欠なものである。
【０００３】
最近、非接触型ＩＣタグを用いて人や物を自動認識するＲＦＩＤ（Radio Frequency Identification：無線自動認識）技術を利用した書類管理のシステム化が普及しつつある。
図１０は、従来の申請書類管理システムの一実施例の概要を示す図であり、各種指示を入力し処理結果を表示する端末１００１、端末１００１に接続されたＲＦＩＤリーダ１００２、顧客情報を管理する顧客情報管理データベース(ＤＢ)１００３、申請者に郵送する申請書類を管理する申請書類管理データベース(ＤＢ)１００４、ＲＦＩＤリーダが搭載されたプリンタ１００５、システム全体を制御する申請業務サーバ１００６とから構成されている。
【０００４】
このような構成の申請書類管理システムにおいては、事前に登録された顧客基本情報（氏名や住所など）および顧客契約情報を基に、申請希望者からの申し出によって必要とする申請書を作成して郵送する。作成においては、申し出の内容に応じてシステムオペレータが端末１００１から顧客氏名を入力し、顧客情報管理ＤＢ１００３から顧客の基本情報と契約情報を読み出し、プリンタ１００５に送信して申請書を印刷する。その際、プリンタ１００５は、申請書に埋設されたＲＦＩＤタグの固有番号（申請書番号）を読み取り、その値を申請業務サーバ１００６に返却する。申請書番号を受け取った申請業務サーバ１００６は、申請書番号と顧客氏名を紐付けて申請書類管理ＤＢ１００４で管理し、どの顧客に対してどの申請書を郵送したか記録する。印刷された申請書は申請希望者に郵送される。
【０００５】
一方、申請書を受け取った申請者は、新たに申請する内容（基本情報や契約情報の訂正、変更）を申請書に記載して申請書発送元に返送する。返送された申請書を受理すると、システムオペレータは申請書のＲＦＩＤタグの固有番号（申請書番号）をＲＦＩＤリーダ１００２で読み取り、申請書番号に紐付く顧客氏名を申請書類管理ＤＢ１００４から読み出し、この顧客氏名を基に顧客情報管理ＤＢ１００３から基本情報と契約情報を読み出し端末１００１に表示させ、新たに申請された内容（変更、訂正情報）のみを端末１００１から入力して顧客情報管理ＤＢ１００３を更新する。
この背景技術により顧客単位で申請書の送達管理が可能となるほか、受理した申請書の入力作業の削減も可能としている。
なお、本発明に関連する公知技術文献としては下記の特許文献１がある。
【特許文献１】特開平１０−３３４１４１
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、必要最小限の申請書入力作業であってもシステムオペレータの手作業が介在するため、入力ミスを完全に防ぐことは困難である。また、申請書の意図的な不正入力や申請情報の改竄などの可能性も完全には否定できない。
このような申請書入力作業における何らかの人為的データ入力誤りによって顧客情報管理ＤＢにデータ不備が発生し、この結果、顧客情報の真正性の低下や顧客の要求していないサービス（契約内容）を提供してしまうといった不都合が生じ、業務・システムに対する信頼性を損なわせる要因となっている。
【０００７】
また、サービス内容に関する顧客からの照会問合せに対して、顧客情報管理ＤＢで管理する顧客情報のデータ項目に不備が含まれる場合、背景技術における送達記録の管理だけでは、データ不備がいつ誰によって作り込まれたものか特定できないため、再発防止策の導入やデータ不備の被害拡大防止を図る事ができない。
【０００８】
この不都合を根本的に解決する手段の一つとして、申請書入力作業を確実なものとするために申請書をＯＣＲ（Optical Character Reader：光学式文字読取装置）に対応させ、申請書の内容を機械的に読み取る技術を採用する方法がある。
しかし、ＯＣＲ技術における文字読み取りの認識率にはまだ改善の余地があり、現状の技術レベルではシステムオペレータによる認識文字の確認や文字補正作業が必要となっている。
【０００９】
本発明の目的は、申請書入力作業における不正入力、データ改竄を抑止し、データ不備の可能性に対して申請者からの照会問い合わせに迅速に対応することができる申請書追跡管理システムを提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明の申請書追跡管理システムは、顧客識別情報と顧客基本情報および顧客契約情報とを紐付けて予め格納する顧客情報管理ＤＢを備えた申請業務サーバと、該申請業務サーバからの制御により申請書を印刷するとともに該印刷した申請書から固有の申請書番号を読み取り該申請業務サーバへ返却するプリンタと、この申請業務サーバに対する処理指示を入力し処理結果を表示するための端末とを有する申請書追跡管理システムであって、前記申請業務サーバは、前記端末からの申請書印刷の処理指示及び該端末に入力された顧客識別情報に応じて、該顧客識別情報に基づいて前記顧客情報管理ＤＢに格納された顧客基本情報および顧客契約情報を読み出して前記プリンタに申請書を印刷させるとともに、該プリンタから返却された該申請書番号と該顧客識別情報および該申請書の種類とを紐付けて申請書管理ＤＢに格納する手段と、前記申請書印刷の処理経過を含め、印刷後の該申請書に関する複数の処理経過の各々において、前記申請書番号と、該処理の実行後の申請書ステータス情報、該処理の実行時点情報および該処理を行った担当者の担当者識別情報とを紐付けて申請書追跡管理ＤＢに格納する手段と、前記顧客識別情報または前記担当者識別情報に基づいて前記申請書管理ＤＢまたは前記申請書追跡管理ＤＢを検索する手段とを有することを特徴とする。
さらに、前記申請業務サーバが、前記申請書追跡管理ＤＢに対するアクセス権限の制御として、一般ユーザにはデータの選択、挿入および読み取りの権限のみを可能とし、システム管理者にはさらにデータの更新および削除を可能とするセキュリティ手段を有することを特徴とする。
【発明の効果】
【００１１】
本発明の申請書追跡管理システムによれば、次のような効果がある。
（１）申請書処理業務におけるすべての処理経過情報すなわちチェックポイント情報（いつ、誰が、どのような処理を実行したかに関する情報）を処理の証跡として取得し、不正業務を抑止することができる。
（２）証跡を管理するＤＢへの不正アクセスを防止できる。
（３）申請書の処理状況の問合せに迅速に対応することができる。
（４）データ不備の可能性に対してその影響範囲を網羅的に調査し、確実なデータ補正範囲を特定することができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明を適用した申請書追跡管理システムの一実施の形態について説明する。
図１は、本発明の一実施例を示すシステム構成図である。この実施例の申請書追跡管理システムは、顧客情報管理データベース(ＤＢ)２を備えた申請業務サーバ１と、申請業務サーバ１に対する処理指示を入力し処理結果を表示する端末５と、端末５からの指示に基づく申請業務サーバ１の制御により申請書を印刷するプリンタ７とから構成され、端末５とプリンタ７は申請業務サーバ１に接続されている。申請業務サーバ１は、本システムの機能を実現するためのソフトウェアを導入されたコンピュータにより実施される。
【００１３】
顧客情報管理ＤＢ２には、予め顧客の氏名や住所などの顧客の基本情報および顧客との既存の契約情報からなる顧客情報が登録されている。例えば、顧客Ａ氏から電話で契約変更申請書の郵送依頼があった場合、端末５から顧客氏名と申請書の種類を入力して、顧客情報管理ＤＢ２に登録されている変更前契約情報や顧客住所を取得し、これらの顧客氏名、顧客住所および変更前契約情報などの情報をプリンタ７へ送り、プリンタ７から契約変更申請書を印刷し、顧客へ郵送するシステム利用形態となる。プリンタ７には、ＲＦＩＤリーダが搭載されており、また、顧客へ郵送する申請書には小型のＲＦＩＤタグが埋設されている。申請書が印刷される際、申請書に埋設されたＲＦＩＤタグの申請書番号（ＲＦＩＤタグの固有番号であり申請書を一意に特定する番号）をプリンタ７のＲＦＩＤリーダが読み取り、読み取った申請書番号を申請業務サーバ１に返却する。
【００１４】
申請業務サーバ１には、顧客情報管理ＤＢ２の他に、プリンタ７から返却された申請書番号を格納する申請書管理データベース(ＤＢ)３と、申請書の処理経過情報を格納する申請書追跡管理データベース(ＤＢ)４とが設けられている。
【００１５】
申請書管理ＤＢ３には、申請書とその郵送先である顧客との関連性、例えば印刷した契約変更申請書は顧客Ａ氏に関するものであるという紐付け情報が登録されている。
【００１６】
また、申請書追跡管理ＤＢ４には、顧客Ａ氏に関する契約変更申請書に対して、"いつ"、"誰"が、"どのような処理（印刷、郵送、Ａ氏からの返送申請書の受理、受理した申請書の審査、審査済み申請書の入力、入力結果を確認する決裁）"を実施したか、という処理経路の情報が、処理実施の証跡として管理されている。このとき各処理経路では都度、申請書に埋設されたＲＦＩＤタグの申請書番号を端末５に接続されたＲＦＩＤリーダ６で読み取り、端末５を経由して申請業務サーバ１が申請書番号に基づいて顧客情報管理ＤＢ２と申請書管理ＤＢ３と申請書追跡管理ＤＢ４とからそれぞれ情報を読み出して端末５に表示し、申請書に対する各処理を実施する。
【００１７】
以上のデータ処理を実現する機能として申請業務サーバ１には、端末５との通信制御を行う端末入出力処理部１１、申請書を印刷するプリンタ７との通信制御を行うプリンタ通信制御部１２、プリンタ７から返却された申請書番号と顧客情報との紐付け情報を申請書管理ＤＢ３に格納する申請書追跡管理情報更新処理部８、顧客から返送され端末５から入力された申請書の内容をもとに顧客情報管理ＤＢ２を更新する申請書入力処理部９、申請書管理ＤＢ３と申請書追跡管理ＤＢ４の情報を条件指定で検索する申請書追跡管理情報検索処理部１０を備えている。
【００１８】
また、申請書追跡管理ＤＢ４に格納される各処理経路の証跡情報には、申請書処理の処理済を示す申請書ステータス情報（印刷済や郵送済などの経過状態）が保持され、申請書追跡管理情報更新処理部８は、申請書に対する最新の処理経過情報を申請書追跡管理ＤＢ４に登録することができるようにも構成されている。
なお、申請業務サーバ１におけるすべてのデータ処理は、申請業務サーバ１内に備えられている一時記憶領域１３上で実行され、処理が終了するまでデータは保持される。
【００１９】
図２は、顧客情報管理ＤＢ２に格納される顧客基本情報および顧客契約情報の一例を示す図である。図に示すように、顧客氏名２１、住所２２、生年月日２３、契約プラン２４の各データから構成されており、顧客氏名２１、住所２２および生年月日２３が顧客基本情報であり、契約プラン２４が顧客契約情報である。これらをまとめて顧客情報と称する。例えば、新規顧客との契約を結んだ際に新たなデータレコードが登録され、契約変更申請書や住所変更申請書などの処理によって該当データが更新され、契約解除申請書によってデータレコードが削除される。本実施例では、顧客氏名２１がこのデータレコードの主キーとなる。
なお、本実施例では、顧客氏名２１は、顧客識別情報であって顧客を一意に特定できるものとする。
【００２０】
図３は、申請書管理ＤＢ３に格納される申請書番号と顧客情報の紐付け情報の一例を示す図である。図に示すように、顧客氏名３１、申請書番号３２、申請書類名３３の各データから構成され、申請書を印刷する際にプリンタ７に搭載されたＲＦＩＤリーダで読み取った申請書番号３２に対して、申請書に印刷した顧客氏名３２（顧客情報管理ＤＢ２のデータレコードの主キー）と、端末５から入力した申請書の種類を紐付けて管理する形態となっている。
【００２１】
図４は、申請書追跡管理ＤＢ４に格納される申請書に対する処理経過の履歴情報の一例を示す図であり、図に示すように、申請書番号４１、申請書ステータス４２、申請書処理年月日４３、申請書処理担当者名４４の各データから構成される。申請書ステータス４２は、処理後の申請書ステータスを示す申請書ステータス情報が格納され、申請書処理年月日４３は、いつ処理を実行したかを示す実行時点情報が格納される。ここで、申請書が印刷された時点（申請書管理ＤＢ３のデータレコードが生成された時点）で申請書ステータス４２には初期値「０１：印刷済」が設定され、その後の申請書に対する処理経過を経て、新たな申請書ステータス４２を持つデータレコードが履歴として格納されていく。
なお、本実施例では、申請書処理担当者名４４は、担当者識別情報であって、申請書処理担当者を一意に特定できるものとする。
【００２２】
図５は、その申請書ステータス４２の状態遷移を示す図であり、印刷した申請書を顧客に郵送した時点で直近の申請書ステータス４２は「０１：印刷済」５１から「０２：郵送済」５２へ変わり、その後、顧客へ郵送した申請書が返送されてきて受理した時点で「０３：受理済み」５３へ、受理した申請書に記載漏れなどがないか審査した時点で「０４：審査済」５４へ、審査済の申請書を端末５から入力し顧客基本情報や契約情報を更新した時点で「０５：入力済」５５へ、申請書の入力結果の確認が完了した時点で「０６：決裁完了」へと順を追って遷移していく。なお、印刷した申請書を破棄する場合、郵送した申請書が一定期間経過しても返送されてこない場合、審査の結果として記載漏れなどが見つかり申請書を却下する場合には、申請書ステータス４２は「９９：取消・却下」５７へと遷移する。
【００２３】
以下、以上のように構成された申請書追跡管理システムの動作を説明する。
図６は、申請業務サーバ１の申請書処理業務の概要を示すフローチャートである。申請業務サーバ１は、申請書追跡管理システムの端末５から入力された処理指示が「申請書印刷」か「申請書処理経過更新」かを判定する（ステップ６０１）。このとき、端末入出力処理部１１が、申請業務サーバ１と端末５間の通信を制御する。
【００２４】
端末５からの処理指示が「申請書印刷」の場合、印刷対象の顧客氏名の入力と申請書種類の指定を促し、端末５から各項目が入力されると（ステップ６０２）、この入力された氏名を検索キーとして顧客情報管理ＤＢ２を検索し、印刷対象の顧客基本情報と契約情報を読み出す（ステップ６０３）。
【００２５】
次に、ステップ６０３で読み出した情報を、端末５から指定された申請書の種類に応じて編集し、プリンタ７にデータ送信して申請書を印刷する（ステップ６０４）。
給紙トレイにセットされた印刷前の申請書用紙をプリンタ７内部に引き込んで編集情報を印刷する際、申請書に埋設されたＲＦＩＤタグの固有番号をプリンタ７内部のＲＦＩＤリーダで読み取り、申請業務サーバ１に印刷結果（正常印刷、印刷エラー）とともに返却する（ステップ６０５）。申請業務サーバ１とプリンタ７との間での印刷データと印刷結果情報のやり取りは、プリンタ通信制御部１２によって制御されている。
【００２６】
申請業務サーバ１の申請書追跡管理情報更新処理部８は、プリンタ７から受け取ったＲＦＩＤタグの固有番号と、端末５から入力された顧客氏名と、端末５から指定された申請書の種類をそれぞれ、申請書管理ＤＢ３の申請書番号３２、顧客氏名３１、申請書類名３３のデータ項目値として編集し、申請書管理ＤＢ３に格納する（ステップ６０６）。
さらに、申請書追跡管理情報更新処理部８は、ＲＦＩＤタグの固有番号と印刷処理年月日をそれぞれ申請書追跡管理ＤＢ４の申請書番号４１、申請書処理年月日４３にレコードキーとして設定し、申請書ステータス４２に「０１：印刷済」を設定する。申請書処理担当者名４４には、申請書追跡管理システムへのログイン情報をもとに印刷処理を実施した担当者名を設定する（ステップ６０７）。
【００２７】
一方、ステップ６０１で、端末５からの処理指示が「申請書処理経過更新」であった場合、すでに申請書は印刷済であり、担当者の手元にある申請書を図５の申請書ステータスの遷移に沿って、処理を進めていく事となる。各ステータスにおいて基本的な処理の流れは同じであり、端末５に接続されたＲＦＩＤリーダで申請書のＲＦＩＤタグの固有番号を読み取り（ステップ６０８）、読み取った固有番号と等しい申請書番号３２を申請書管理ＤＢ３から検出し、当該申請書に紐付いた顧客氏名３１を基に顧客基本情報と顧客契約情報を顧客情報管理ＤＢ２から読み出す。また同時に、特定した申請書番号３２を検索キーとして申請書追跡管理ＤＢ４から現在年月日に最も近い申請書処理年月日４３を特定して、直近の申請書ステータス４２を読み出す（ステップ６０９）。
【００２８】
読み出した顧客基本情報と顧客契約情報はステップ６１０で端末５に表示される。このとき、直近の申請書ステータス４２の表示と合わせて、図５の状態遷移に基づく次段階の申請書ステータスも同時に表示し、処理指示「申請書処理経過更新」の目的と相違ないか、ステップ６１１で確認を促す。確認の結果、問題なければステップ６０７に戻り、新たな申請書追跡管理情報を申請書追跡管理ＤＢ４に格納する。
【００２９】
ここで例えば、受理した申請書の内容について、記載漏れや記載ミスがないか審査が終了した時点で、端末５から「申請書処理経過更新」の処理指示を入力し、申請書ステータス４２が「０３：受理済」であるデータレコードに対して、次段階の申請書ステータス「０４：審査済」に遷移した新たなデータレコードが申請書追跡管理ＤＢ４に格納される、といった具合に実行される。
【００３０】
一方、ステップ６０９で読み出した直近の申請書ステータス４２が「０４：審査済」であった場合、これは申請書の内容を入力できる状態にあり、端末５からの「申請書処理経過更新」の処理指示は申請書の内容を入力する事を目的としたものとなる。ステップ６１２は、この申請書入力処理の実行可能条件を判定するステップであり、条件を満たす場合、申請業務サーバ１は申請書入力処理部８を呼び出し、端末５からの申請書内容入力情報の処理結果を、ステップ６０９で読み出し一時記憶領域１３上に展開されている顧客基本情報と顧客契約情報に対して更新する（ステップ６１３）。次のステップ６１０で、一時記憶領域１３上にある申請書入力処理部８の処理結果を端末５に表示させ、処理結果に問題がなければ当該申請書における新たな処理経過更新情報を申請書追跡管理ＤＢ４に格納し、直近の申請書ステータス４２が「０４：審査済」から「０５：入力済」に変わる（ステップ６０７）。ステップ６１４は、顧客情報管理ＤＢ２の更新可否を判定するステップであり、申請書ステータス４２が「０５：入力済」のとき、一時記憶領域１３上にある申請書入力処理部８の処理結果が顧客情報管理ＤＢ２に反映される（ステップ６１５）。
【００３１】
ステップ６１０で表示された処理結果に問題がある場合、ステップ６１１の判定の次にステップ６１６で再審査が必要かどうか判断を促す。再審査を行う場合には、図５の状態遷移に基づき申請書追跡管理情報更新処理部８は、申請書の未審査状態を示す「０３：受理済」の値を持つ処理経過更新情報を新たに生成し、申請書追跡管理ＤＢ４に格納する（ステップ６０７）。再審査を行わない場合には、ステップ６１７で申請書を取消・却下するかどうかの判断を促し、取消・却下する場合は、図５の状態遷移に基づき申請書追跡管理情報更新処理部８は、申請書ステータス４２が「９９：取消・却下」の値を持つ処理経過更新情報を新たに生成し、申請書追跡管理ＤＢ４に格納する（ステップ６０７）。ステップ６１７で申請書を取消・却下しない場合、端末５からの「申請書処理経過更新」の処理指示はキャンセルされたものとみなし、一時記憶領域１３上にある処理結果をＤＢに格納または更新しないまま、処理を終了させる。
【００３２】
以上のように、顧客情報管理ＤＢ２と申請書追跡管理ＤＢ４に対する更新処理のポイントをフローチャート上で局所化させ、さらにその更新処理ポイントまでの過程に複数のチェックポイント（処理経路）を設け、処理経路通過の実績情報を処理の証跡として保持することで、人為的なデータ入力誤りを抑止することができる。
【００３３】
また、この証跡情報を管理する申請書追跡管理ＤＢ４に対するセキュリティについて、一般ユーザには申請書追跡管理ＤＢ４へのアクセス権限をＳＥＬＥＣＴ権限（データの選択）、ＩＮＳＥＲＴ権限（データの挿入）、ＲＥＦＥＲＥＮＣＥＳ権限（データの読み取り）の３つのみとし、ＵＰＤＡＴＥ権限（データの更新）、ＤＥＬＥＴＥ権限（データの削除）は限られたシステム管理者だけに付与する権限制約をＤＢＭＳ（Database Management System）に定義することによって、一般ユーザでは証跡情報の改竄や消去といった不正行為ができない制約を実現することができる。
【００３４】
図７は、申請業務サーバ１の申請書処理経過追跡業務の概要を示すフローチャートである。申請業務サーバ１は、申請書追跡管理システムの端末５から入力された処理指示が、これまでの申請書処理経過を検索し処理の証跡を追跡するものであるかどうかを判定し、追跡する場合、申請書追跡管理情報検索処理部１０を呼び出す（ステップ７０１）。
この発明の実施例における申請書処理経過追跡業務は、２種類の検索方法による処理経過の追跡が可能となるように構成されている。
【００３５】
第１の検索方法は、ステップ７０２で顧客氏名が入力された場合の申請書追跡管理ＤＢ４の検索方法であり、端末５から入力された顧客氏名を検索キーとして申請書管理ＤＢ３から検索キーと一致する顧客氏名３１を持つデータレコードを特定し、その申請書番号３２を取得する。次に、取得した申請書番号３２を検索キーとして申請書追跡管理ＤＢ４から検索キーと一致する申請書番号４１を持つデータレコードをすべて抽出する（ステップ７０３）。ステップ７０３で取得した情報はすべて一時記憶領域１３に展開され、ステップ７０４で情報を編集し端末５に検索結果を表示する。
【００３６】
図８は、この顧客氏名による申請書追跡管理情報の検索結果画面を示す一具体例である。顧客氏名での検索を指定するラジオボタン８１を選択し、入力エリア８２に検索キーとする顧客氏名を入力して、検索実行ボタン８３をクリックすると、申請書管理ＤＢ３、申請書追跡管理ＤＢ４の順に該当するデータを抽出し、検索結果８４を端末５に表示する。
この方法による検索は、例えば顧客「晴種  熱子」から契約解除申請書の処理状況に関する問合せがあった場合に使用され、図８の具体例で言うと、問合せのあった契約解除申請書は「２００８年６月８日」に処理担当者「郵  敏太」が受理処理を実施したが、申請書に対する審査がまだ完了していない状態を示している。
【００３７】
一方、第２の検索方法は、ステップ７０２で申請書処理担当者名が入力された場合の申請書追跡管理ＤＢ４の検索方法であり、端末５から入力された申請書処理担当者名を検索キーとして申請書追跡管理ＤＢ４から検索キーと一致する申請書処理担当者名４４を持つデータレコードを特定し、その申請書番号４１を取得する。次に、取得した申請書番号４１を検索キーとして申請書管理ＤＢ３から検索キーと一致する申請書番号３２を持つデータレコードを特定し、その申請書に該当する顧客氏名３１を取得する。また、申請書番号４１を検索キーとして申請書追跡管理ＤＢ４から検索キーと一致するすべてのデータレコードを抽出し、その申請書の処理経路に関する情報をすべて取得することができる（ステップ７０３）。
【００３８】
図９は、この申請書処理担当者名による申請書追跡管理情報の検索結果画面を示す一具体例である。申請書処理担当者名での検索を指定するラジオボタン９１を選択し、入力エリア９２に検索キーとする申請書処理担当者名を入力して、検索実行ボタン９３をクリックすると、申請書追跡管理ＤＢ４と申請書管理ＤＢ３から検索キーとして入力した申請書処理担当者が関与した申請書処理業務のすべての処理経路情報を抽出し、検索結果９４として端末５に表示する。
この方法による検索は、例えば申請書審査担当者「木城点  検」が審査した申請書の入力結果に不備が見つかり、この審査担当者が審査した申請書処理業務のすべての結果を再点検する場合に使用される。さらに、この検索結果の内容を基にして、例えば顧客「山名井  飴雄」からの申請書が他にないか、１つめの検索方法を使って申請書を特定することができ、「山名井  飴雄」の顧客情報にもデータ不備が見つかった場合には、このデータ不備が「山名井  飴雄」からの申請書のひとつひとつの処理結果に影響していないか再点検することで、申請書の再入力の必要性を調査することも可能である。
【００３９】
以上のように、本実施の形態の申請書追跡管理システムによれば、次のような効果がある。
（１）申請書処理業務におけるすべての処理経過情報を処理の証跡として取得し、不正業務を抑止することができる。
（２）証跡を管理するＤＢへの不正アクセスを防止できる。
（３）申請書の処理状況の問合せに迅速に対応することができる。
（４）データ不備の可能性に対してその影響範囲を網羅的に調査し、確実なデータ補正範囲を特定することができる。
【図面の簡単な説明】
【００４０】
【図１】本発明の一実施の形態例を示すシステム構成図である。
【図２】顧客情報管理ＤＢに格納されているデータの構成図である。
【図３】申請書管理ＤＢに格納されているデータの構成図である。
【図４】申請書追跡管理ＤＢに格納されているデータの構成図である。
【図５】申請書の処理ステータスの遷移を示す説明図である。
【図６】申請書処理業務の概要を示すフローチャートである。
【図７】申請書処理経過追跡業務の概要を示すフローチャートである。
【図８】申請書処理経過をフォワードトレースで追跡する処理の具体例を示す図である。
【図９】申請書処理経過をバックトレースで追跡する処理の具体例を示す図である。
【図１０】従来の申請書類管理システムの概略構成図である。
【符号の説明】
【００４１】
１…申請業務サーバ、２…顧客情報管理ＤＢ、３…申請書管理ＤＢ、４…申請書追跡管理ＤＢ、５…端末、６…ＲＦＩＤリーダ、７…プリンタ、８…申請書追跡管理情報更新処理部、９…申請書入力処理部、１０…申請書追跡管理情報検索処理部、１１…端末入出力処理部、１２…プリンタ通信制御部、１３…一時記憶領域。
【図１】
2010073081.tif 000003
【図２】
2010073081.tif 000004
【図３】
2010073081.tif 000005
【図４】
2010073081.tif 000006
【図５】
2010073081.tif 000007
【図６】
2010073081.tif 000008
【図７】
2010073081.tif 000009
【図８】
2010073081.tif 000010
【図９】
2010073081.tif 000011
【図１０】
2010073081.tif 000012