(57)【要約】【課題】保険業務のアウトソーシングを可能にする。【解決手段】保険会社の人員の持つ、請求に対する処理を判断するための専門知識を基に体系化を行い、体系化された情報を基に、保険に関する業務の一部を自動的に処理する。具体的には、顧客側からの請求情報を参照し、請求情報の内容に応じて、請求情報に処理パターン識別子を割り当てる。また、複数の処理パターン識別子の各々と、請求手続きに係る複数の処理項目のうち少なくとも１つと、が紐付けられた処理パターンテーブルを参照し、請求手続きに係る複数の処理項目のうち、割り当てられた処理パターン識別子に紐付けられた処理項目を特定する。また、特定された処理項目に基づいて、請求手続きに関する処理を自動的に実行する。【選択図】図１
2015032111.tif 000002
【特許請求の範囲】
【請求項１】
締結された契約に基づく顧客側からの請求申出に応じた請求手続きに関する処理を実行する事務処理システムであって、
請求手続きに係る複数の処理項目を有し、複数の処理パターン識別子の各々と、前記請求手続きに係る複数の処理項目のうち少なくとも１つと、が紐付けられた処理パターンテーブルを記憶するパターン記憶部と、
顧客側からの請求情報を参照し、前記請求情報の内容に応じて、前記請求情報に処理パターン識別子を割り当てるパターン判定部と、
前記処理パターンテーブルを参照し、前記請求手続きに係る複数の処理項目のうち、前記割り当てられた処理パターン識別子に紐付けられた処理項目を特定する処理項目特定部と、
前記特定された処理項目に基づいて、前記請求手続きに関する処理を自動的に実行する処理実行部と
を備えることを特徴とする
事務処理システム。
【請求項２】
前記特定された処理項目は、前記顧客側に提出を要求する書類であり、
前記処理実行部は、
前記顧客側に提出を要求する書類として、前記請求情報の内容に応じた記入欄を設けた帳票のレイアウトデータを自動的に作成して、前記帳票を印刷する帳票作成部と、
前記顧客側に提出を要求する書類に関する案内のレイアウトデータを自動的に作成して、前記案内を印刷する案内作成部と
を備えることを特徴とする
請求項１に記載の事務処理システム。
【請求項３】
前記処理実行部は、
前記顧客側から受領した書類をスキャンして画像データを作成し、前記請求情報単位で前記画像データを管理するための独自のヘッダを作成して前記画像データに付与し、前記ヘッダに含まれる作業順位に基づいて、前記請求情報単位で前記画像データを自動的に並べ替える書類画像制御部と、
前記画像データを参照し、前記顧客側から受領した書類の種別を特定する提出書類判定部と、
前記請求手続きにおける書類の過不足を判定する書類過不足判定部と、
前記画像データを参照し、自動査定により書類点検を行い、記載内容、押印、原本の有無、有効性を確認する書類点検部と、
前記画像データを参照し、自動査定により情報照合を行い、情報の正誤性を確認する情報照合部と、
前記書類過不足判定部、前記書類点検部、及び前記情報照合部の各々の処理結果に対する総合評価を行い、前記顧客側から受領した書類に関して何らかの不備が発生している場合、前記顧客側に対し、不備通知書を自動的に作成する不備通知書自動作成部と
を更に備えることを特徴とする
請求項２に記載の事務処理システム。
【請求項４】
前記顧客側から受領した書類のうち、前記帳票にはコード化情報が印字されており、前記帳票以外の書類にはコード化情報が印字されたシールが貼り付けられ、
前記書類画像制御部は、前記顧客側から受領した書類と共にコード化情報を画像データ化し、
前記提出書類判定部は、前記画像データに含まれるコード化情報を読み取り、前記顧客側から受領した書類の種別を特定する
ことを特徴とする
請求項３に記載の事務処理システム。
【請求項５】
計算機が、締結された契約に基づく顧客側からの請求申出に応じた請求手続きに関する処理を実行する事務処理方法であって、
顧客側からの請求情報を参照し、前記請求情報の内容に応じて、前記請求情報に処理パターン識別子を割り当てるステップと、
複数の処理パターン識別子の各々と、請求手続きに係る複数の処理項目のうち少なくとも１つと、が紐付けられた処理パターンテーブルを参照し、前記請求手続きに係る複数の処理項目のうち、前記割り当てられた処理パターン識別子に紐付けられた処理項目を特定するステップと、
前記特定された処理項目に基づいて、前記請求手続きに関する処理を自動的に実行するステップと
を備えることを特徴とする
事務処理方法。
【請求項６】
締結された契約に基づく顧客側からの請求申出に応じた請求手続きに関する処理を計算機に実行させるためのプログラムであって、
顧客側からの請求情報を参照し、前記請求情報の内容に応じて、前記請求情報に処理パターン識別子を割り当てるステップと、
複数の処理パターン識別子の各々と、請求手続きに係る複数の処理項目のうち少なくとも１つと、が紐付けられた処理パターンテーブルを参照し、前記請求手続きに係る複数の処理項目のうち、前記割り当てられた処理パターン識別子に紐付けられた処理項目を特定するステップと、
前記特定された処理項目に基づいて、前記請求手続きに関する処理を自動的に実行するステップと
を計算機に実行させるための
事務処理用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、事務処理システムに関し、特に生命保険会社の業務を支援する事務処理システムに関する。
【背景技術】
【０００２】
生命保険会社においては、顧客側（契約者又は受取人）からの請求に応じた様々な作業に関して、「人」を介して人的な判断及び処理を行っている。例えば、「マニュアル、知識、経験」等を基に、人手で、顧客側の属性と保険契約締結内容に応じた必要帳票の選定を行っている。また、顧客側から受け付けた請求に応じた「業務処理フロー」を定める処理や、顧客側から受理した提出書類の確認を行っている。
【０００３】
生命保険会社の業務は多岐にわたり、日々の請求の件数も膨大であるため、人手によらず計算機等により自動的に処理できれば好ましいが、保険業務に関する法律等の問題もあり、現状では完全な自動化は実施できない状況にある。
【０００４】
保険金や給付金等の請求案内に関する業務の一部を自動化した技術の例として、特許文献１（特開２０１１−１２３６４６号公報）に保険金・給付金等請求案内システムが開示されている。この保険金・給付金等請求案内システムでは、お客様の申出に対してお客様番号をキーに、申出契約以外のその他加入契約を抽出し、複数の契約情報を束ねて申出受付情報を生成し、当該申出受付情報を基に、関連する請求書、手続案内書、申出内容確認書、請求案内ガイダンス兼内勤点検票等の書類を生成し、それらの書類を束ねて印刷する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１１−１２３６４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
「人」を介して人的な判断及び処理を行う場合、担当者による判断に頼るため、判断ミス等により「顧客側に誤った案内、間違った処理」を行ってしまうことがある。このような誤処理や、それに伴う再案内等による遅延等が原因で「クレーム、苦情」が発生することもあり、顧客満足（ＣＳ：Ｃｕｓｔｏｍｅｒ  Ｓａｔｉｓｆａｃｔｉｏｎ）の悪化に繋がる懸念がある。
【０００７】
また、上記の判断及び処理を行う担当者は、一般的に保険に関する専門知識を有する必要があるため、「専門知識を有している人（熟練者、経験者）」の配置体制から人件費がかさみ、収益性を圧迫する問題もある。加えて、保険商品の複雑さ、法律・ガイドライン等の外的環境の変化への対応から、担当者に専門知識を習得させるための育成時間及び費用がかかる。また、我が国においては、生命保険会社の年齢比率も「総人口」に比例することが多く、「高齢者の増加」や「若年者の減少」に伴い、保険請求件数は「増加傾向」にあるが、事務手続の担当者は「減少傾向」にある。このため、専門知識を有している人の確保が難しいという問題もある。
【０００８】
例えば、保険業務においては、以下のような専門知識が必要とされている。
・請求手続きにおいて、必要書類の判定に関する諸手続きのノウハウ
・「請求手続きのご案内、不備通知」の作成時の関係ルールに基づいた解説
・民法、商法、所得税法、会社法、消費者契約法、個人情報保護法、本人確認法等の周辺法規
・社内の取扱ルール、マニュアル、決裁基準、他
【０００９】
また、生命保険会社においては、経営の効率化が課題となっており、これまで以上に広範に事務の外部委託が行われることが想定される。このような場合、委託会社において、上記のような専門知識を有している人の確保の問題が発生する。
【００１０】
本発明の目的は、保険業務のアウトソーシングを可能にするために、保険会社の人員の持つ、請求に対する処理を判断するための専門知識を基に体系化を行い、体系化された情報を基に、保険業務における全工程のうち、外部委託可能な一部の工程を自動的に処理する事務処理システムを提供することである。
【課題を解決するための手段】
【００１１】
本発明に係る事務処理システムは、締結された契約に基づく顧客側からの請求申出に応じた請求手続きに関する処理を実行する事務処理システムである。上記の事務処理システムは、パターン記憶部と、パターン判定部と、処理項目特定部と、処理実行部を備える。パターン記憶部は、請求手続きに係る複数の処理項目を有し、複数の処理パターン識別子の各々と、請求手続きに係る複数の処理項目のうち少なくとも１つと、が紐付けられた処理パターンテーブルを記憶する。パターン判定部は、顧客側からの請求情報を参照し、請求情報の内容に応じて、請求情報に処理パターン識別子を割り当てる。処理項目特定部は、処理パターンテーブルを参照し、請求手続きに係る複数の処理項目のうち、割り当てられた処理パターン識別子に紐付けられた処理項目を特定する。処理実行部は、特定された処理項目に基づいて、請求手続きに関する処理を自動的に実行する。
【００１２】
なお、上記の事務処理システムは、本発明に係る事務処理用プログラムを、計算機に実行させることにより実現することもできる。この事務処理用プログラムは、記憶装置や記憶媒体に格納することが可能である。
【発明の効果】
【００１３】
生命保険会社における顧客側（契約者又は受取人）からの請求申出により発生する書類査定業務に際して、顧客側の請求内容に応じて変化する業務処理フロー等に基づき、人手を介さずに自動的に不備を確認することが可能になる。これにより、生命保険会社ではない委託会社等が、専門知識を有している人（熟練者、経験者）を確保せずとも、保険に関する業務の一部を代行することが可能になる。
【図面の簡単な説明】
【００１４】
【図１】本発明に係る事務処理システムの構成例を示す図である。
【図２】請求情報のデータ構造の一例を示す図である。
【図３】処理パターン情報のデータ構造の一例を示す図である。
【図４】事務処理システムにおけるパターン判定部の構成例を示す図である。
【図５】ヘッダのデータ構造の一例を示す図である。
【図６】事務処理の手順について説明するための図である。
【図７】帳票書類一覧テーブルのデータ構造の一例を示す図である。
【図８】公的書類一覧テーブルのデータ構造の一例を示す図である。
【図９】書類判定結果である提出書類一覧の一例を示す図である。
【図１０】書類過不足判定結果の一例を示す図である。
【図１１】書類過不足判定テーブルのデータ構造の一例を示す図である。
【図１２】帳票書類点検テーブルのデータ構造の一例を示す図である。
【図１３】公的書類点検テーブルのデータ構造の一例を示す図である。
【図１４】帳票点検結果の一例を示す図である。
【図１５】公的書類点検結果の一例を示す図である。
【図１６】情報照合テーブルのデータ構造の一例を示す図である。
【図１７】情報照合結果の一例を示す図である。
【発明を実施するための形態】
【００１５】
＜実施形態＞
以下に、本発明の実施形態について添付図面を参照して説明する。
【００１６】
［システム構成］
図１を参照して、本発明に係る事務処理システムの構成例について説明する。
【００１７】
本発明に係る事務処理システムは、生命保険会社サーバ１と、委託会社サーバ２を備える。
【００１８】
［生命保険会社サーバ］
生命保険会社サーバ１は、生命保険会社が管理するサーバである。なお、生命保険会社は一例に過ぎない。実際には、生命保険会社に限らず、その他の契約業務を営む団体でも良い。
【００１９】
生命保険会社サーバ１は、契約情報記憶部１１と、請求情報記憶部１２を備える。
【００２０】
契約情報記憶部１１は、生命保険会社と締結している保険契約の契約情報を記憶する。契約情報の内訳の例として、証券番号、保険契約者名、被保険者名、受取人名、住所、契約日、保障内容等が考えられる。ここでは、契約情報記憶部１１は、生命保険会社により管理され、予め（事前に）契約情報が登録されているものとする。なお、契約情報記憶部１１は、生命保険会社が委託会社に契約情報を利用させるために用意したものであり、委託会社側からアクセス可能な記憶装置である。
【００２１】
請求情報記憶部１２は、顧客側（契約者又は受取人）からの請求の内容を請求情報として記憶する。請求情報の内訳の例として、受付番号、業務内容、請求内容、契約形態、対象者、契約者の状態、顧客側等に関する情報、及び処理パターンを示す識別情報（処理パターンＩＤ）等が考えられる。ここでは、請求情報記憶部１２は、生命保険会社により管理され、生命保険会社が顧客側からの請求を受け付けた際に請求情報が設定（登録、更新等）されるものとする。受付番号、業務内容、請求内容、契約形態、対象者、契約者の状態、及び顧客側等に関する情報については、請求受付時に、生命保険会社サーバ１側の処理により、新規作成される請求情報の項目として新たに設定される。処理パターンＩＤについては、上記の各情報の設定後、後述する委託会社サーバ２側の処理により、上記の各情報に紐付け（対応付け）られる。なお、請求情報記憶部１２は、生命保険会社が委託会社に請求情報を利用させるために用意したものであり、委託会社側からアクセス可能な記憶装置である。
【００２２】
［委託会社サーバ］
委託会社サーバ２は、生命保険会社から業務を委託された委託会社が管理するサーバである。
【００２３】
委託会社サーバ２は、パターン記憶部２１と、パターン判定部２２と、処理項目特定部２３と、処理実行部２４を備える。
【００２４】
パターン記憶部２１は、請求手続きに係る複数の処理項目を有し、複数の処理パターンＩＤの各々と、請求手続きに係る複数の処理項目のうち少なくとも１つと、が紐付けられた処理パターン情報（処理パターンテーブル）を記憶する。ここでは、パターン記憶部２１は、予め（事前に）処理パターン情報を記憶しているものとする。例えば、パターン記憶部２１は、処理パターン情報として、「業務内容、請求内容、及び顧客側の属性情報」等に応じて変化する処理フロー等を体系化し、マトリクス状（格子状、行列）に配置した処理パターンデータベースの形式で記憶する。具体的には、請求に対する処理を判断するための専門知識を基に体系化した処理パターンに関する情報をテーブル形式で記憶する。また、パターン記憶部２１は、パターン判定部２２での処理により発生したデータ（中間データ、結果データ）を一次的に記憶する。
【００２５】
パターン判定部２２は、契約情報記憶部１１、請求情報記憶部１２、パターン記憶部２１をそれぞれ参照し、請求情報記憶部１２に記憶された請求情報に対し、処理パターンの割り当て処理を行う。ここでは、パターン判定部２２は、生命保険会社により請求情報記憶部１２に請求情報が記憶されたとき、請求情報記憶部１２にアクセスし、当該請求情報を参照する。また、契約情報記憶部１１にアクセスし、契約情報を参照する。また、パターン記憶部２１にアクセスし、当該契約情報と、請求情報に含まれる各属性情報をキーとして、処理パターン情報と照合して、請求情報記憶部１２に記憶されている請求情報に処理パターンＩＤを割り当てる。このとき、割り当てた処理パターンＩＤを、請求情報記憶部１２に記憶されている請求情報に紐付けて（対応付けて）記憶する。すなわち、請求情報記憶部１２に記憶されている請求情報を更新する。或いは、パターン記憶部２１に記憶しても良い。なお、パターン判定部２２は、パターン記憶部２１に登録されていない処理パターンの請求が生じた場合は、アラート（警告）をあげてシステム管理者等に通知し、パターン記憶部２１に処理パターンを追加登録させるようにしても良い。
【００２６】
処理項目特定部２３は、請求情報に割り当てられた処理パターンＩＤを基に、パターン記憶部２１にアクセスし、処理パターン情報を参照し、請求手続きに係る複数の処理項目のうち、割り当てられた処理パターンＩＤに紐付けられた処理項目を特定する。
【００２７】
処理実行部２４は、特定された処理項目に基づいて、請求手続きに関する処理を自動的に実行する。詳細については後述する。
【００２８】
なお、パターン記憶部２１、パターン判定部２２、処理項目特定部２３、及び処理実行部２４は、相互に連携しているものとする。実際には、物理的に同一の装置であっても良い。
【００２９】
［請求情報のデータ構造］
図２を参照して、請求情報のデータ構造の一例について説明する。
【００３０】
請求情報は、「受付番号」と、「業務内容」と、「請求内容」と、「契約形態」と、「対象者」と、「契約者の状態」と、「請求人」と、「処理パターンＩＤ」を格納するための領域（フィールド）を有する。
【００３１】
「受付番号」は、受け付けた請求毎に割り当てられる番号であり、当該請求情報を特定するための識別情報である。
【００３２】
「業務内容」は、該当する業務の種類を示す情報である。業務内容の例として、新規契約業務（保険契約の引受）、収納業務（保険料の収納）、保全業務（住所変更・名義変更・内容変更）、保険金支払業務（入院・死亡・満期・年金等支払）等が考えられる。
【００３３】
「請求内容」は、顧客側から受け付けた請求の内容を示す情報である。請求内容の例として、改姓請求、特約解約請求、解約請求等が考えられる。
【００３４】
「契約形態」は、締結している保険契約の形態を示す情報である。契約形態の例として、個人契約、法人契約等が考えられる。
【００３５】
「対象者」は、請求内容に応じた業務の対象となる者を示す情報である。対象者の例として、契約者、被保険者、受取人等が考えられる。
【００３６】
「契約者の状態」は、現時点での契約者の状態を示す情報である。契約者の状態の例として、成人、未成年者、成年被後見人、外国人等が考えられる。
【００３７】
「請求人」は、顧客側の者のうち、実際に請求申出を行った者を示す情報である。請求人の例として、契約者本人、親権者、成年被後見人、法定代理人、委任代理人、或いは、法人契約における代表取締役等が考えられる。
【００３８】
「処理パターンＩＤ」は、処理パターンを示す識別情報である。処理パターンＩＤは、上記の各情報が設定された際に、上記の各情報を基に、パターン判定部２２により特定され、上記の各情報に紐付け（対応付け）される。
【００３９】
［処理パターン情報のデータ構造］
図３を参照して、処理パターン情報のデータ構造の一例について説明する。
【００４０】
処理パターン情報は、「処理パターンＩＤ」と、「対象者」と、「契約者の状態」と、「請求人」と、「処理フロー」等を格納するための領域（フィールド）を有する。
【００４１】
「処理パターンＩＤ」、「対象者」、「契約者の状態」、及び「請求人」については、上記のとおりである。すなわち、これらは、請求情報の構成において説明したものと同様である。
【００４２】
「処理フロー」は、業務内容、請求内容、顧客側の属性情報（対象者、契約者の状態。請求人等）等に応じて変化する処理フローを示す情報である。業務内容、請求内容、及び顧客側の属性情報については、請求情報と共通する上記の処理パターンＩＤにより示される。ここでは、処理フローの例として、業務内容、請求内容、顧客側の属性情報等に応じて顧客側に要求される提出書類等を示している。
【００４３】
［処理実行部の構成］
図４を参照して、処理実行部２４の構成例について説明する。なお、処理実行部２４以外の構成については、図１と同じであるため、説明及び図示を省略する。
【００４４】
処理実行部２４は、請求書類自動作成部２４１と、書類画像制御部２４２と、提出書類判定部２４３と、書類過不足判定部２４４と、書類点検部２４５と、情報照合部２４６と、不備通知書自動作成部２４７を備える。
【００４５】
請求書類自動作成部２４１は、各種請求手続きについて、請求に関する案内や帳票等の請求書類を自動的に作成する。また、これらの印刷に関する処理を行う。このとき、顧客側からの返送を要する帳票には、帳票を特定するためのバーコード等（二次元コード等でも可）のコード化された情報（以下、コード化情報）を印字して印刷するものとする。印刷された請求に関する案内や請求書類等は、顧客側に発送（送付）される。また、顧客側から受領した書類は、最終的に委託会社が受け付ける。例えば、処理項目特定部２３により特定された処理項目が、顧客側に提出を要求する書類である場合、請求書類自動作成部２４１は、帳票作成部２４１１と、案内作成部２４１２を備える。帳票作成部２４１１は、顧客側に提出を要求する書類として、請求情報の内容に応じた記入欄を設けた帳票のレイアウトデータを自動的に作成して、帳票を印刷する。案内作成部２４１２は、顧客側に提出を要求する書類に関する案内のレイアウトデータを自動的に作成して、案内を印刷する。このとき、請求書類自動作成部２４１は、雛形となる帳票及び案内のレイアウトデータを記憶しておき、この雛形となる帳票及び案内のレイアウトデータを基に、必要に応じて帳票及び案内のレイアウトデータを編集するようにしても良い。帳票及び案内のレイアウトデータに含まれる事項の例として、請求人に発送する書類（案内、帳票等）に関する事項、請求単位に発生する書類（提出書類）に関する事項、書面に印字されるメッセージ、顧客側の記入事項・提出時の注意喚起等の個別対応等が考えられる。請求書類自動作成部２４１は、請求内容に応じて不要となった記入欄や書類名を帳票及び案内のレイアウトデータから省き、適度に帳票及び案内タイトルやメッセージの内容を変更する。これにより、印刷コスト削減と、契約者に対する帳票記入のユーザビリティ（使いやすさ）の向上の効果が見込まれる。また、顧客側からの返送を要する帳票には、帳票を特定するためのコード化情報（バーコード等）を帳票のレイアウトデータに挿入・付与する。そして、出力として、帳票及び案内のレイアウトデータに基づく印刷データをオンデマンドプリンタ等の印刷装置に送信し、帳票及び案内のバリアブル印刷を行う。
【００４６】
書類画像制御部２４２は、スキャナ（Ｓｃａｎｎｅｒ）又はこれに相当する装置／機能を用いて、顧客側から受領した提出書類（記入済の請求書類や公的書類等）をスキャン（Ｓｃａｎ）し、提出書類の画像データを作成する。また、請求毎に（請求情報単位で）、提出書類を管理するための独自の「ヘッダ」（ｈｅａｄｅｒ）を作成し、スキャン時に、提出書類の画像データにヘッダを付与する。例えば、ＯＣＲ機能（文字・画像認識機能）を利用して、提出書類に付与されているコード化情報（バーコード等）を解析し、その情報を基に、自動的にヘッダを作成するようにしても良い。なお、委託会社が作成する書類には、コード化情報（バーコード等）による印字表示が行われているものとする。また、顧客側から提出される書類（公的書類等）には、提出が予想される書類単位でコード化情報（バーコード等）を印字したシール（ラベル等）を予め（事前に）準備し、提出された書類（公的書類等）に対して、スキャン前に当該シールを貼り付けるものとする。これにより、スキャン時に、提出書類と共にコード化情報（バーコード等）を画像データ化することができる。
【００４７】
提出書類判定部２４３は、画像データを参照し、ＯＣＲ機能（文字・画像認識機能）を利用して、書類の種別の特定を行う。例えば、提出書類に付与されているコード化情報（バーコード等）や、ヘッダに含まれる情報を解析し、その情報を基に、提出書類の種別（帳票、公的書類）を特定する。
【００４８】
書類過不足判定部２４４は、「請求内容に応じた必要書類」と、「提出書類」間の書類の過不足を判定する。また、顧客側から受け付けた全ての提出書類を対象に、「仮置」、「受付」、「確定」の情報を突合し、その結果、請求手続きにおける各段階での書類の過不足を判定する。なお、「仮置」は、顧客側から受け付けた時点の書類である。「受付」は、スキャンされた時点の書類である。「確定」は、種別が特定された時点の書類である。過不足を判定した結果、過不足があれば、その書類の書類コードと共に、その書類が「追加書類」、「未提出」、「返却書類」、「提出不要」のいずれに該当するのかチェックする。
【００４９】
書類点検部２４５は、画像データを参照し、自動査定により、提出書類に対する書類点検を行い、記載内容、押印（有無、状態、位置）、原本の有無（原本、コピー）、有効性（正当性、有効期限）を確認する。なお、記入済みの帳票については、記載状態を登録することで、書類状態を点検する。公的書類については、必要項目を登録することによって、有効性等を点検する。
【００５０】
情報照合部２４６は、画像データを参照し、自動査定により、提出書類に対する情報照合を行い、情報の正誤性を確認する。照合する項目の例として、氏名、生年月日、性別、死亡年月日等が考えられる。また、照合する対象の例として、公的書類、帳票、保険契約内容等が考えられる。例えば、氏名等、各書類に共通の「キー」で、公的書類、帳票、保険契約内容等の照合を行う。更に、契約情報記憶部１１にアクセスし、契約情報と提出書類の内容を照合しても良い。
【００５１】
不備通知書自動作成部２４７は、書類過不足判定部２４４、書類点検部２４５、及び情報照合部２４６の各々の処理結果に対する総合評価を行い、いずれかの処理において不備（エラー）が発生している場合、自動的に不備通知書を作成する。また、これらの印刷に関する処理を行う。なお、実際には、請求書類自動作成部２４１が不備通知書自動作成部２４７を兼用していても良い。すなわち、請求書類自動作成部２４１と不備通知書自動作成部２４７は、共通化・一体化していても良い。例えば、不備通知書と共に、又は不備通知書として、記載を一部変更した請求書類等を再発行（印刷）する場合、請求書類自動作成部２４１が当該処理を行うと好適である。
【００５２】
［ヘッダのデータ構造］
図５を参照して、本発明に係るヘッダのデータ構造の一例について説明する。
【００５３】
ヘッダは、「引受会社区分」と、「業務区分」と、「提携先区分」と、「委託業務区分」と、「請求内容」と、「作業順位」と、「他部署との連携」と、「進捗状況」等を格納するための領域（フィールド）を有する。
【００５４】
「引受会社区分」は、生命保険会社の名称又は識別コードを示す情報である。
【００５５】
「業務区分」は、該当する業務の名称又は識別コードを示す情報である。業務の例として、新規契約業務（保険契約の引受）、収納業務（保険料の収納）、保全業務（住所変更・名義変更・内容変更）、保険金支払業務（入院・死亡・満期・年金等支払）等が考えられる。
【００５６】
「提携先区分」は、営業店の名称又は識別コードを示す情報である。なお、営業店を介さず顧客と直接やり取りする場合には、その旨（顧客直送等の表示又は識別コード）を示す。
【００５７】
「委託業務区分」は、生命保険会社から委託された業務の範囲内か否か（業務範囲内、業務の範囲外）を示す情報である。
【００５８】
「請求内容」は、当該請求の内容に対応する請求名又は請求コードを示す情報である。
【００５９】
「作業順位」は、業務区分や請求内容に応じて決定される作業順位を示す情報である。書類画像制御部２４２は、この作業順位に基づいて、画像データを自動的に並べ替えるようにしても良い。
【００６０】
「他部署との連携」は、提出書類について、他部署との連携業務が発生した場合に即座に連携するための情報である。例えば、他部署の名称又は識別コードを示す情報等が考えられる。
【００６１】
「進捗状況」は、当該ヘッダが付与された提出書類の処理状況を示す情報である。進捗状況の例として、「未処理」、「処理中」、「不備発生」、「完了」等が考えられる。「未処理」は、未着手の状況を示す。「処理中」は、処理に着手した状況を示す。「不備発生」は、何らかの不備があり、その解決を図っている状況を示す。「完了」は、処理が完了している状況を示す。
【００６２】
［事務処理の手順］
図６を参照して、生命保険会社における業務を例に、事務処理の手順について説明する。
【００６３】
（１）請求申出（ステップＳ１０１）
顧客側（契約者又は受取人）は、生命保険会社に対して、「保全・保険金支払」等の請求申出を行う。
【００６４】
（２）請求受付（ステップＳ２０１）
生命保険会社は、顧客側からの請求申出に応じて、請求受付を行う。このとき、生命保険会社サーバ１は、顧客側から生命保険会社に対して口頭（電話、窓口対応）や書面（書類の郵送等）により請求申出が行われた場合には、受付担当者（コールセンターオペレータや窓口担当者等）からの請求情報の入力操作を受け付ける。また、顧客側から生命保険会社に対してデータ送信により請求申出が行われた場合には、データ受信により請求受付を行い、受信データから請求情報を抽出する。そして、請求情報記憶部１２に当該請求情報を記憶する。すなわち、生命保険会社サーバ１は、請求受付時に、請求情報記憶部１２に請求情報を記憶する。
【００６５】
（３）請求情報連携（ステップＳ３０１）
パターン判定部２２は、請求情報記憶部１２に対する請求情報の登録処理をトリガーにして、請求情報記憶部１２にアクセスし、当該請求情報を参照する。また、契約情報記憶部１１にアクセスし、証券番号等に対応する契約情報を参照する。また、パターン記憶部２１にアクセスし、当該契約情報と、請求情報に含まれる各属性情報をキーとして、処理パターン情報と照合して、パターン判定処理を行い、当該請求情報にパターン判定結果情報（処理パターンＩＤ等）を紐付ける。なお、パターン判定部２２は、請求情報記憶部１２に対する請求情報の登録処理を常時監視していても良い。また、請求情報記憶部１２に対する請求情報の登録処理が行われた際に、その旨の通知又は当該請求情報を受信するようにしても良い。処理項目特定部２３は、請求情報に割り当てられた処理パターンＩＤを基に、パターン記憶部２１にアクセスし、処理パターン情報を参照し、請求手続きに係る複数の処理項目のうち、割り当てられた処理パターンＩＤに紐付けられた処理項目を特定する。処理実行部２４は、特定された処理項目に基づいて、請求手続きに関する処理を自動的に実行する。ここでは、処理項目特定部２３により特定された処理項目が、顧客側に提出を要求する書類であるため、請求書類自動作成部２４１を起動する。
【００６６】
（４）帳票出力（ステップＳ３０２）
請求書類自動作成部２４１は、請求情報の内容に応じて、出力する帳票の種類、レイアウト、印字内容・メッセージ等を変更する。そして、契約者宛てに発送する帳票を、「ご請求手続きご案内」と共に、オンデマンドプリンタ等の印刷装置に出力してバリアブル印刷を行う。例えば、帳票作成部２４１１は、イメージ帳票に契約情報等を印字し、当該帳票をＰＤＦ化し、オンデマンドプリンタ等で印刷する。イメージ帳票とは、請求名単位にパターン化した請求書を指す。帳票をＰＤＦ化することにより、顧客からの再作成依頼に対応できる（再作成機能）。既存のシステムでは、再作成機能がないため毎回新規に帳票を作成する必要があり、そのための作業量及び作業時間が発生していたが、本システムでは、毎回新規に帳票を作成する必要がなく、そのための作業量及び作業時間が発生しない。更に、帳票がＰＤＦ化しているため、顧客からの照会に対して、発送した帳票の内容が確認できる（照会対応機能）。このとき、印刷される帳票に対し、帳票毎に、請求情報と紐付けたキーをコード化情報（バーコード等）の形式で印字する。委託会社は、印刷された帳票を、「ご請求手続きご案内」と共に、封筒に封入封緘して、顧客側に発送する。
【００６７】
（５）書類記入・提出（ステップＳ１０２）
顧客側は、委託会社より郵送された「ご請求手続きご案内」に基づいて、郵送された帳票に必要事項を記入し、必要書類（公的書類等）を取寄せのうえ、記入済の帳票と必要書類を委託会社に提出する。
【００６８】
（６）スキャン（ステップＳ３０３）
書類画像制御部２４２は、顧客側から提出された帳票や添付書類等をスキャンして画像データ化する。また、スキャン時に、帳票に印字されたコード化情報（バーコード等）を解析することにより、請求単位でヘッダを作成し、画像データにヘッダを付与する。このとき、ヘッダに含まれる作業順位に基づいて「画像データの並べ替え」等を自動的に行うようにしても良い。なお、コード化情報（バーコード等）が印字されていない本人確認書類のコピー等の添付書類については、帳票のコード化情報（ユニークキー）を基に、これと連携する副次的なコード化情報（サブキー）を作成し、この副次的なコード化情報を印字したシール（ラベル等）を添付書類に貼り付けるようにする。
【００６９】
（７）データ入力（ステップＳ３０４）
書類画像制御部２４２は、スキャンにて取得した画像データをＰＣ（パソコン）等のディスプレイ上に表示し、入力オペレータの入力操作に応じて、契約者が記入した情報や添付書類の情報等のデータ入力を行う。このとき、入力オペレータが入力するデータの順番（入力オペレーションの順番）等については、スキャンの結果（ヘッダ、コード化情報等）に基づいて、自動的に決定する。なお、入力オペレータの入力操作ではなく、ＯＣＲ機能（文字・画像認識機能）を利用して自動的にデータ入力を行うようにしても良い。入力データについては、請求情報記憶部１２の請求情報に紐付けて管理する。
【００７０】
（８）書類特定（ステップＳ３０５）
提出書類判定部２４３は、画像データを参照し、ＯＣＲ機能（文字・画像認識機能）を利用して、コード化情報（バーコード等）や、ヘッダに含まれる情報を解析し、書類の種別を特定する。ここでは、「帳票書類一覧テーブル」（図７参照）や、「公的書類一覧テーブル」（図８参照）に基づいて、コード化情報（バーコード等）に対応する書類名を特定する。その結果、提出書類一覧（図９参照）が得られる。このとき、提出書類一覧（図９参照）を、ＰＣ（パソコン）等のディスプレイ上に表示しても良い。なお、実際には、「帳票書類一覧テーブル」と「公的書類一覧テーブル」は、一体化していても良い。
【００７１】
（９）書類過不足判定（ステップＳ３０６）
書類過不足判定部２４４は、処理パターン情報を参照し、特定された書類について、各段階での「書類の過不足」の有無を確認し、確認の結果、書類過不足判定結果（図１０参照）が得られる。この書類過不足判定結果（図１０参照）を基に、「書類過不足判定テーブル」（図１１参照）を参照し、不備内容とその解決方法を特定する。このとき、書類過不足判定結果（図１０参照）を、不備内容とその解決方法と共に、ＰＣ（パソコン）等のディスプレイ上に表示しても良い。
【００７２】
（１０）書類点検（ステップＳ３０７）
書類点検部２４５は、書類点検を行い、「請求書等記載事項の不備」の有無を確認し、「帳票書類点検テーブル」（図１２参照）や、「公的書類点検テーブル」（図１３参照）に基づいて、不備内容とその解決方法を特定する。その結果、個別の書類について、帳票点検結果（図１４参照）や公的書類点検結果（図１５参照）が得られる。このとき、帳票点検結果（図１４参照）や公的書類点検結果（図１５参照）を、ＰＣ（パソコン）等のディスプレイ上に表示しても良い。
【００７３】
（１１）情報照合（ステップＳ３０８）
情報照合部２４６は、情報照合を行い、「情報の不一致」の有無を確認し、「情報照合テーブル」（図１６参照）に基づいて、不備内容とその解決方法を特定する。その結果、情報照合結果（図１７参照）が得られる。このとき、情報照合結果（図１７参照）を、ＰＣ（パソコン）等のディスプレイ上に表示しても良い。
【００７４】
（１２）不備確認（ステップＳ３０９）
不備通知書自動作成部２４７は、上記の各処理（ステップＳ３０６〜Ｓ３０８）を経て総合評価を行い、「書類の過不足」、「請求書等記載事項の不備」、「情報の不一致」のいずれかの不備が発生していないか確認する。
【００７５】
（１３）不備通知書作成（ステップＳ３１０）
不備通知書自動作成部２４７は、「書類の過不足」、「請求書等記載事項の不備」、「情報の不一致」のうち、少なくとも１つの不備が発生している時（不備がある場合）、「不備通知書」を自動的に作成し、オンデマンドプリンタ等の印刷装置を使用して、不備通知書のバリアブル印刷を行う。委託会社は、印刷された不備通知書を、封筒に封入封緘して、顧客側に発送する。
【００７６】
（１４）不備解決・提出（ステップＳ１０３）
顧客側は、ご請求手続きに対する「不備通知書」のご案内に基づいて、不備解決（書類の補充・訂正）を行った後、補充・訂正した書類を委託会社に提出する。書類画像制御部２４２は、改めて、補充・訂正した書類等をスキャンして画像データ化する（ステップＳ３３に移行する）。
【００７７】
（１５）決裁依頼（ステップＳ３１１）
不備通知書自動作成部２４７は、「書類の過不足」、「請求書等記載事項の不備」、「情報の不一致」のいずれの不備も発生していない時（不備がない場合）、生命保険会社に対して、提出書類の画像データを送信し、決裁処理を依頼する。例えば、請求内容が改姓請求等である場合、提出書類に基づく名義変更等の実施を依頼する。
【００７８】
（１６）処理内容確認（ステップＳ２０２）
生命保険会社は、提出書類の画像データをＰＣ（パソコン）等のディスプレイ上に表示して、登録情報を照合し、変更内容等を確認する。
【００７９】
（１７）決裁処理（ステップＳ２０３）
生命保険会社は、処理内容確認の結果、問題がなければ、決裁処理を行う。例えば、契約情報記憶部１１に記憶された契約情報を更新する。
【００８０】
（１８）完了通知書発送（ステップＳ３１２）
委託会社は、生命保険会社が決裁処理を完了すると、「完了通知書」を印刷し、当該完了通知書を顧客側に発送する。「完了通知書」は、「郵送・作業」等のコストの観点から、「圧着ハガキ」であると好ましい。委託会社は当該完了通知書（ハガキ）をメールシーラーで圧着した後、顧客側に発送する。
【００８１】
（１９）書類一時保管（ステップＳ３１３）
委託会社は、提出書類の原本を一時的に保管する。
【００８２】
［補足］
なお、「帳票書類一覧テーブル」（図７参照）、「公的書類一覧テーブル」（図８参照）、「書類過不足判定テーブル」（図１１参照）、「帳票書類点検テーブル」（図１２参照）、「公的書類点検テーブル」（図１３参照）、及び「情報照合テーブル」（図１６参照）については、パターン記憶部２１に記憶されていても良い。この場合、提出書類判定部２４３、書類過不足判定部２４４、書類点検部２４５、及び情報照合部２４６は、
パターン判定部２２と連携していても良いし、パターン判定部２２により実現されていても良い。
【００８３】
［進捗確認］
生命保険会社は、本発明に係る事務処理システムにアクセスし、請求処理の進捗状況（請求書類の処理状況）の照会・確認を行うことができる。例えば、事務処理システムにおいて、各工程の処理終了のタイミングで、請求情報に工程毎の処理終了を示すフラグを付与（紐付け）することにより、「処理済」の工程や「未処理」の工程等、進捗状況の照会・確認が可能である。
【００８４】
［処理パターン情報の変更］
生命保険会社は、法やガイドライン、約款、商品、ルール等の変更に応じ、「帳票の新規・改定（レイアウト含む）、処理フロー・優先度の判定基準」が変更になった場合、委託会社に対して、処理パターン情報の変更依頼をする。このとき、処理パターン情報の変更に関する情報を、処理パターンの記録状態に合わせた体裁に整えた上で、データで提供する。委託会社は、生命保険会社から処理パターン情報の変更依頼と変更内容のデータを受領し、パターン記憶部２１を参照し、変更内容のデータに基づいて、対象となる処理パターンの変更箇所への上書き・追加等の処理を行う。なお、パターン記憶部２１が、膨大な数の処理パターン数情報を格納したＤＢ（データベース）である場合、メンテナンスを容易にするために、処理パターン情報の変更時にキーワードを入力すると、関連する処理パターンを抽出し、変更内容を入力すると、関連するパターンを一括で変更するようにしても良い。なお、実際には、パターン記憶部２１は、生命保険会社サーバ１側に搭載することが可能である。例えば、生命保険会社がパターン記憶部２１を管理することで、法やガイドライン、約款、商品、ルール等の変更が発生した際、処理パターン情報の変更を迅速かつ容易に行うことが可能となる。
【００８５】
［同期処理］
契約情報記憶部１１、請求情報記憶部１２、及びパターン記憶部２１は、生命保険会社サーバ１と委託会社サーバ２の両方に個別に搭載していても良い。生命保険会社サーバ１と委託会社サーバ２の間で、随時、それぞれの契約情報記憶部１１、請求情報記憶部１２、及びパターン記憶部２１の同期処理を行うことにより、強固な連携を図ることができると共に、いずれか一方の側で情報の変更が発生した時にも他方に反映することができる。
【００８６】
＜ハードウェアの例示＞
以下に、本発明に係る事務処理システムを実現するための具体的なハードウェアの例について説明する。
【００８７】
生命保険会社サーバ１や委託会社サーバ２の例として、ＰＣ（パソコン）、アプライアンス（Ａｐｐｌｉａｎｃｅ）、シンクライアント用サーバ、ワークステーション、メインフレーム、スーパーコンピュータ等の計算機を想定している。なお、事務処理システムは、複数の計算機や、クラウドコンピューティングにより実現されていても良い。また、端末やサーバに限らず、中継機器や周辺機器、或いは、物理マシン上に構築された仮想マシン（ＶＭ：Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）でも良い。
【００８８】
図示しないが、上記のような計算機等は、プログラムに基づいて駆動して所定の処理を実行するプロセッサと、当該プログラムや各種データを記憶するメモリと、ネットワークとの通信に用いられるインターフェースによって実現される。
【００８９】
上記のプロセッサの例として、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、ネットワークプロセッサ（ＮＰ：Ｎｅｔｗｏｒｋ  Ｐｒｏｃｅｓｓｏｒ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコントローラ（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ）、或いは、専用の機能を有する半導体集積回路（ＬＳＩ：Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ）等が考えられる。
【００９０】
上記のメモリの例として、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やフラッシュメモリ等の半導体記憶装置、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の補助記憶装置、又は、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等のリムーバブルディスクや、ＳＤメモリカード（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  ｍｅｍｏｒｙ  ｃａｒｄ）等の記憶媒体（メディア）等が考えられる。また、バッファ（ｂｕｆｆｅｒ）やレジスタ（ｒｅｇｉｓｔｅｒ）等でも良い。或いは、ＤＡＳ（Ｄｉｒｅｃｔ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）、ＦＣ−ＳＡＮ（Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ  −  Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＮＡＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）、ＩＰ−ＳＡＮ（ＩＰ  −  Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等を用いたストレージ装置でも良い。
【００９１】
なお、上記のプロセッサ及び上記のメモリは、一体化していても良い。例えば、近年では、マイコン等の１チップ化が進んでいる。したがって、電子機器等に搭載される１チップマイコンが、上記のプロセッサ及び上記のメモリを備えている事例も考えられる。
【００９２】
上記のインターフェースの例として、ネットワーク通信に対応した基板（マザーボード、Ｉ／Ｏボード）やチップ等の半導体集積回路、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）等のネットワークアダプタや同様の拡張カード、アンテナ等の通信装置、接続口（コネクタ）等の通信ポート等が考えられる。
【００９３】
また、ネットワークの例として、インターネット、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ  ＬＡＮ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、バックボーン（Ｂａｃｋｂｏｎｅ）、ケーブルテレビ（ＣＡＴＶ）回線、固定電話網、携帯電話網、ＷｉＭＡＸ（ＩＥＥＥ  ８０２１６ａ）、３Ｇ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ）、専用線（ｌｅａｓｅ  ｌｉｎｅ）、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ  Ｄａｔａ  Ａｓｓｏｃｉａｔｉｏｎ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、シリアル通信回線、データバス等が考えられる。
【００９４】
なお、生命保険会社サーバ１や委託会社サーバ２の内部の構成要素は、モジュール（ｍｏｄｕｌｅ）、コンポーネント（ｃｏｍｐｏｎｅｎｔ）、或いは専用デバイス、又はこれらの起動（呼出）プログラムでも良い。
【００９５】
但し、実際には、これらの例に限定されない。
【００９６】
＜まとめ＞
本発明では、例えば生命保険会社と締結している保険契約において、顧客側（契約者又は受取人）から「保険金、保全」等の請求申出により発生する書類査定業務に際して、顧客側の「状態、事象内容、保険契約締結内容や請求内容」に応じて変化する「必要書類の判定」や「請求書類のレイアウト判定」を行う。これにより、帳票に基づいて、「業務処理フローの自動化」や「後続処理の簡素化」等が実現可能である。
【００９７】
本発明に係る事務処理システムでは、保険会社の人員の持つ、請求に対する処理を判定するための専門知識を基に、処理の体系化を行っている。ここで、「パターン記憶部」は、処理パターンをデータベース形式で保持する。「契約情報記憶部」は、契約内容を記憶する。「請求情報記憶部」は、請求内容を記憶する。「処理パターン判定部」は、上記の「パターン記憶部」、「契約情報記憶部」、「請求情報記憶部」を参照し、請求内容と、請求に紐付けられた顧客側の属性に応じて処理パターンを判定し、請求情報記憶部に処理パターン情報を紐付ける。これにより、請求に対する処理パターンの判定を自動化し、各種データベースと、事務処理において使用するスキャナやプリンタ、ＰＣ等を連携することができ、請求の受付から帳票の印刷までの一連の処理を自動化することができる。
【００９８】
また、本発明に係る事務処理システムは、「パターン判定部」において、請求情報が既存の処理パターンに該当しない事例が発生した場合、「その他」に分類し、例外処理を行う仕組みや、「人」を介して人的に判断を行う仕組み（入力・参照操作が可能な機構）にすることもできる。人的に判断を行う場合、「その他」に分類された請求については、システム管理者等に通知して、入力・参照操作を許可し、人的に書類の判断を行う処理に移行する。このように、自動的に処理できない予期せぬ請求を受け付けた場合でも、処理漏れやエラーとすることなく対応することができる。
【００９９】
また、本発明に係る事務処理システムは、「帳票レイアウト作成部」において、請求内容に応じて顧客側に発送する書類を作成する際に、「帳票のレイアウトを組み替え、請求内容に合わせたメッセージの印字を行い、お客様の記入箇所の最少化を図る」等を目的しているため、紙面を最小限の枚数に抑えるとともに、ユーザビリティ（利便性）を高めることができる。
【０１００】
また、本発明に係る事務処理システムは、「書類画像制御部」において、ヘッダに「作業順位」の項目を設けることで、早急に作業処理が必要とされる請求については、他の請求に対し、優先的に処理を行うように処理順番を組み替え、レスポンスを早めることもできる。
【０１０１】
また、本発明に係る事務処理システムは、法やガイドラインの改定に応じて、処理パターンを一括変換することが可能であり、パターン管理のユーザビリティを向上させることも期待できる。
【０１０２】
以上、説明したように、本発明によって、生命保険会社における顧客側（契約者又は受取人）から「保険金、保全」等の請求申出により発生する書類査定業務に際して、顧客側の「状態、事象内容、保険契約締結内容」に応じて変化する「必要書類、業務処理フロー、処理の優先度」等を、人手を介さずに自動的に判定し、自動的に不備を確認することが可能になる。
【０１０３】
＜備考＞
以上、本発明の実施形態を詳述してきたが、実際には、上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。
【符号の説明】
【０１０４】
１…  生命保険会社サーバ
１１…  契約情報記憶部
１２…  請求情報記憶部
２…  委託会社サーバ
２１…  パターン記憶部
２２…  パターン判定部
２３…  処理項目特定部
２４…  処理実行部
２４１…  請求書類自動作成部
２４１１…  帳票作成部
２４１２…  案内作成部
２４２…  書類画像制御部
２４３…  提出書類判定部
２４４…  書類過不足判定部
２４５…  書類点検部
２４６…  情報照合部
２４７…  不備通知書自動作成部
【図１】
2015032111.tif 000003
【図２】
2015032111.tif 000004
【図３】
2015032111.tif 000005
【図４】
2015032111.tif 000006
【図５】
2015032111.tif 000007
【図６】
2015032111.tif 000008
【図７】
2015032111.tif 000009
【図８】
2015032111.tif 000010
【図９】
2015032111.tif 000011
【図１０】
2015032111.tif 000012
【図１１】
2015032111.tif 000013
【図１２】
2015032111.tif 000014
【図１３】
2015032111.tif 000015
【図１４】
2015032111.tif 000016
【図１５】
2015032111.tif 000017
【図１６】
2015032111.tif 000018
【図１７】
2015032111.tif 000019