保険の審査を支援するシステム及び方法
【課題】保険会社同士が互いのＤＢを自由に参照できなくても正確に審査できるようにする。
【解決手段】複数の保険会社用の複数のローカルシステムと中央システムとを専用ネットワークに接続する。或るローカルシステムが、審査対象者の個人情報を検索条件として含んだ検索依頼を受け、その検索依頼に応答して、その検索条件を含んだ検索要求を中央システムに送信する。中央システムが、対象ローカルシステムからの検索要求に応答して、或る保険会社以外の各保険会社のローカルシステムから、その検索要求が有する検索条件に適合する顧客情報に対応する顧客についてインシデントが有るか否かを調査し、その調査の結果に基づく検索結果情報を対象ローカルシステムに送信する。対象ローカルシステムが、中央システムからの検索結果情報を検索依頼の発行元に対して出力する。
【解決手段】複数の保険会社用の複数のローカルシステムと中央システムとを専用ネットワークに接続する。或るローカルシステムが、審査対象者の個人情報を検索条件として含んだ検索依頼を受け、その検索依頼に応答して、その検索条件を含んだ検索要求を中央システムに送信する。中央システムが、対象ローカルシステムからの検索要求に応答して、或る保険会社以外の各保険会社のローカルシステムから、その検索要求が有する検索条件に適合する顧客情報に対応する顧客についてインシデントが有るか否かを調査し、その調査の結果に基づく検索結果情報を対象ローカルシステムに送信する。対象ローカルシステムが、中央システムからの検索結果情報を検索依頼の発行元に対して出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、保険の審査、具体的には、例えば、保険契約をするか否か、および、保険金を支払うべきか否かの審査を支援するコンピュータ技術に関する。
【背景技術】
【０００２】
この種の技術として、例えば、特許文献１に開示されている技術がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−３４６３６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一般に、保険会社は、独自にデータベース（以下、ＤＢ）を管理している。そのＤＢは、その保険会社にとっての顧客の情報を有している。顧客の情報は、その顧客の個人情報（例えば、氏名、住所、電話番号、生年月日）を含んでいる。また、顧客の情報は、その顧客がインシデント（例えば重大な事件または事故）を起こしたことがある場合には、インシデント有りを表す情報を有する。
【０００５】
保険会社は、保険の契約を希望する者（以下、契約希望者）と契約するか否かを決定する際、及び、受取人（例えば、契約者又はその家族）に保険金を支払うか否かを決定する際には、自社のＤＢに基づいて十分審査を行う。もし、自社のＤＢに、契約希望者についてインシデント有りを表す情報が有る場合には、その契約希望者と契約しても再度何らかのインシデントが生じる可能性が考えられるため、保険会社は、その契約希望者との契約を断ることがある。或いは、もし、自社のＤＢに、受取人についてインシデント有りを表す情報が有る場合には、直ちに保険金を支払うのではなく、より詳細な調査を行うことがある。
【０００６】
近年、保険犯罪が問題となっている。保険犯罪を計画している者の手口として、或る保険会社で契約が断られた場合、別の保険会社に保険の契約を希望する手口がある。或る保険会社で契約を断られても、別の保険会社であれば契約を結べることがあるからである。これは、保険会社間で連携が取られていないことに起因する。具体的には、各保険会社は、他の保険会社が管理するＤＢ内の顧客情報を参照することができず、自社ＤＢのみに基づいて審査を行うことに起因する。
【０００７】
このため、保険会社は、契約希望者について、インシデント有りという情報が他社のＤＢに有っても自社のＤＢに無い場合には、その契約希望者と保険契約を結んでしまう可能性が高い。このケースでは、その契約希望者が保険犯罪を計画している者であるにも関わらず、危険な保険契約を結んでしまうことになり得る。
【０００８】
また、保険会社は、受取人について、インシデント有りという情報が他社のＤＢに有っても自社のＤＢに無い場合には、その受取人に直ちに保険金を支払う可能性が高い。このケースでは、受取人が保険犯罪を行った結果として保険金が請求されている可能性があるにも関わらず、保険金が支払われてしまうことになり得る。
【０００９】
これを解決するための方法として、保険会社同士が互いのＤＢを自由に参照できるようにする方法が考えられる。しかし、これは、或る保険会社にのみ開示された顧客の情報を他の保険会社が自由に取得できてしまうことになり、現実的ではないと考えられる。
【００１０】
従って、本発明の目的は、保険会社同士が互いのＤＢを自由に参照できなくても正確に審査できるようにすることにある。
【課題を解決するための手段】
【００１１】
複数の保険会社用の複数のコンピュータシステムである複数のローカルシステムと、別のコンピュータシステムである中央システムとを、専用ネットワークに接続する。各ローカルシステムは、そのローカルシステムに対応する保険会社にとっての顧客の個人情報を含んだ顧客情報を記憶しているが、そのローカルシステムに対応する保険会社以外の顧客の個人情報を含んだ顧客情報を記憶していない。各ローカルシステムが、そのローカルシステムに対応する保険会社にとってインシデントのあった顧客については、その顧客についてインシデントがあったことを表す情報を記憶している。各ローカルシステムと中央システムとの通信は可能であるが、ローカルシステム同士の通信は不可能とされる。各顧客情報は、顧客の個人情報を含んでいる。
【００１２】
複数の保険会社のうちの或る保険会社用のローカルシステムである対象ローカルシステムが、審査対象者（例えば、契約希望者又は受取人）の個人情報を検索条件として含んだ検索依頼を受け、その検索依頼に応答して、その検索条件を含んだ検索要求を、専用ネットワークを介して中央システムに送信する。中央システムが、対象ローカルシステムから専用ネットワークを介して検索要求を受信し、その検索要求に応答して、或る保険会社以外の各保険会社のローカルシステムから、その検索要求が有する検索条件に適合する顧客情報に対応する顧客についてインシデントが有るか否かを、専用ネットワークを介して調査し、その調査の結果に基づく検索結果情報を、専用ネットワークを介して対象ローカルシステムに送信する。対象ローカルシステムが、中央システムから専用ネットワークを介して検索結果情報を受信し、その検索結果情報を検索依頼の発行元に対して出力する。
【００１３】
なお、保険会社の「顧客」とは、その保険会社と保険の契約をしている者、及び、その保険会社の過去に保険の契約をしたことがある者の他に、保険を契約するにはいたらなかったがその保険会社とコンタクトした者が含まれていても良い。また、本発明は、様々な保険会社（生命保険会社、損害保険会社など）に適用可能である。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施形態に係る保険審査支援システムの構成を示す。
【図２】システム間の関係を示す。
【図３】共通サーバ及び中央サーバの機能の一例を示す。
【図４】基幹ＤＢ内の情報のフォーマットを保険会社に特有のフォーマットから共通のフォーマットに変換して共通ＤＢに格納する流れを示す。
【図５】インシデントの有無の調査の流れを示す。
【図６】検索要求画面の一例を示す。
【図７】検索結果画面の一例を示す。
【発明を実施するための形態】
【００１５】
本発明の一実施形態によれば、保険会社同士が互いのＤＢを自由に参照することはできないが、保険会社が、保険の審査（例えば、契約希望者又は受取人の審査）を行う際に、自社のＤＢ内の情報の他に、他の保険会社のＤＢ内の情報に基づいて審査できる。以下、本実施形態に係る保険審査支援システムを、図面を参照して説明する。
【００１６】
図１は、本実施形態に係る保険審査支援システムの構成を示す。
【００１７】
同図に示すように、本システムは、中央システム１０と、複数の保険会社にそれぞれ対応した複数のローカルシステム２０，３０，４０，…とを備える。中央システム１０、複数のローカルシステム２０，３０，４０，…のいずれも、コンピュータシステムである。中央システム１０と、複数のローカルシステム２０，３０，４０，…が、専用ネットワーク１００に接続されている。専用ネットワーク１００は、いわゆる閉じた通信ネットワークであり、インターネットのように不特定の者が繋がり得る通信ネットワークではない。
【００１８】
ローカルシステム２０，３０，４０，…は、それぞれ、基幹システム２１，３１，４１，…と、基幹ＤＢ２２，３２，４２，…と、共通システム２３，３３，４３，…とを有する。以下、ローカルシステム２０を例に採り、ローカルシステム２０，３０，４０，…が有する上記要素を説明する。なお、その説明において、ローカルシステム２０を有する保険会社を、図１に示すように、「Ａ社」とする。
【００１９】
基幹システム２１は、Ａ社に特有の機能及び／又は構造を有するコンピュータシステムである。基幹システム２１は、基幹ＤＢ２２を管理する。
【００２０】
基幹ＤＢ２２は、基幹システム２１に接続されている記憶装置に格納されている。基幹ＤＢ２２は、例えば、Ａ社の顧客の顧客情報を含み、他の保険会社の顧客の顧客情報を含まない。顧客情報は、例えば、顧客の個人情報（例えば、氏名、住所、電話番号、生年月日）を含んでいる。また、顧客情報は、その顧客情報に対応した顧客がインシデント（例えば重大な事故）を起こしたことがある場合には、インシデント有りを表す情報を有する。基幹ＤＢ２２は、インシデント有りの顧客に関する情報が集約された情報であるブラックリスト情報を含む。ブラックリスト情報は、インシデント有りの顧客に関する情報（例えば、顧客の識別情報、個人情報）を含む。また、基幹ＤＢ２２は、インシデントの詳細を表すインシデント情報や、顧客と結ばれた保険契約の詳細を表す保険契約情報を有する。インシデント情報及び保険契約情報の少なくとも一方が顧客情報に含まれる。
【００２１】
基幹ＤＢ２２に含まれている情報（例えば顧客情報）のフォーマットは、Ａ社（厳密には、Ａ社の基幹システム２１）に特有のフォーマットである。例えば、Ａ社の従業員が、基幹システム２１に接続されている情報処理端末（図示せず）を用いて、基幹システム２１に顧客情報を入力すると、Ａ社に特有のフォーマットの顧客情報が、基幹ＤＢ２２に格納される。
【００２２】
共通システム２３は、共通サーバ２４と、共通ＤＢ２５とを有する。
【００２３】
共通サーバ２４は、例えば、プロセッサ（例えばＣＰＵ（Central Processing Unit））と記憶資源（例えばメモリ）を有する計算機である。共通サーバ２４の機能は、例えば、共通サーバ２４内のプロセッサがコンピュータプログラムを実行することにより実現される。
【００２４】
共通ＤＢ２５は、共通サーバ２４に接続されている記憶装置に格納されている。共通ＤＢ２５は、基幹ＤＢ２２から読み出されフォーマット変換された情報（例えば、少なくとも顧客情報）を有する。共通ＤＢ内の情報のフォーマットは、全ての保険会社で共通のフォーマットである。共通システム２３は、中央システム１０に対するインタフェースとしての役割も担う。共通サーバ２４は、例えば、変換前のフォーマット（Ａ社に特有のフォーマット）と変換後のフォーマット（全ての保険会社で共通のフォーマット）との対応関係を表す情報（以下、変換規則情報）を有していて、その変換規則情報を用いて、フォーマット変換を行って良い。例えば、Ａ社に特有のフォーマットの顧客情報において、「１」という値がＮＧを意味していて、共通フォーマットの顧客情報では「３」という値がＮＧを意味している場合、Ａ社の共通サーバ２４が有する変換規則情報は、「１→３」の変換規則を表す情報が含まれていて、フォーマット変換では、その変換規則に従う変換が行われる。
【００２５】
共通システム２３，３３，４３，…は、実質的に同じ機能及び構成を有するが、その機能及び／又は構成は、保険会社毎にカスタマイズされて良い。例えば、前述した変換規則情報が、共通サーバ毎に異なっていて良い。
【００２６】
ローカルシステム２０は、共通システム２３（共通サーバ２４）が、専用ネットワーク１００を介して中央システム１０（中央サーバ１１）と接続されることにより、中央システム１０とのみ通信可能となる。
【００２７】
中央システム１０は、保険会社以外の機関によって管理されている。中央システム１０は、例えば、中央サーバ１１と、管理ＤＢ１２とを有する。
【００２８】
中央サーバ１１は、例えば、プロセッサ（例えばＣＰＵ）と記憶資源（例えばメモリ）を有する計算機である。中央サーバ１１の機能は、例えば、中央サーバ１１内のプロセッサがコンピュータプログラムを実行することにより実現される。
【００２９】
管理ＤＢ１２は、中央サーバ１１に接続されている記憶装置に格納されている。管理ＤＢ１２には、後述の検索結果情報が有する情報が格納される。管理ＤＢ１２内の情報は、種々の観点、例えば、統計及び課金の上で、有用である（詳細は後述する）。
【００３０】
図２は、システム間の関係を示す。
【００３１】
図２（ａ）に示すように、ローカルシステム２０，３０，４０，…同士は、通信可能に接続されておらず、それ故、互いに通信できない。一方、図２（ｂ）に示すように、中央システム１０と各ローカルシステム２０，３０，４０，…同士は、通信可能に接続されていて、それ故、互いに通信できる。つまり、各ローカルシステム２０，３０，４０，…は、中央システム１０とのみ通信可能であり、中央システム１０は、全てのローカルシステム２０，３０，４０，…と通信可能である。このような制御は、例えば、グループＶＰＮ（Virtual Private Network）で実現可能である。
【００３２】
図３（ａ）は、共通サーバ２４の機能の一例を示す。なお、共通サーバ２４，３４，４４，…の機能は実質的に同一であるため、図３（ａ）には、代表して、共通サーバ２４のみを示してある。
【００３３】
共通サーバ２４は、検索部２４１と変換部２４２とを備える。検索部２４１と変換部２４２は、例えば、プロセッサが所定のコンピュータプログラムを実行することにより実現される機能である。
【００３４】
検索部２４１は、共通サーバ２４に接続されている情報処理端末（図示せず）からの、審査対象者（例えば、契約希望者又は受取人）の個人情報を検索条件とした検索依頼を受け、その検索依頼に応答して、その検索条件を含んだ検索要求を中央システム１０に送信する。また、検索部２４１は、中央システム１０から検索要求を受け、その検索要求に応答して、その検索要求が有する検索条件（個人情報）に該当するインシデントの有無を判断し、その判断の結果を表す情報を中央システム１０に送信する。
【００３５】
変換部２４２は、基幹ＤＢ２２からの情報のフォーマットを、Ａ社に特有のフォーマットから全ての保険会社に共通のフォーマットに変換し、変換後の情報を共通ＤＢ２５に格納する。
【００３６】
図３（ｂ）は、中央サーバ２５の機能の一例を示す。
【００３７】
中央サーバ１１は、情報収集部１１１を備える。情報収集部１１１は、例えば、プロセッサが所定のコンピュータプログラムを実行することにより実現される機能である。
【００３８】
情報収集部１１１は、ローカルシステムから検索要求を受け、その検索要求に応答して、その検索要求が有する検索条件に適合する顧客情報を有するローカルシステムから、その顧客情報に対応した顧客についてのインシデントの有無を調査する。情報収集部１１１は、調査の結果を表す情報（検索結果情報）を、検索要求の送信元のローカルシステムに送信し、且つ、その検索結果情報が有する情報を管理ＤＢ１２に格納する。
【００３９】
以下、本実施形態で行われる処理を説明する。
【００４０】
図４は、基幹ＤＢ内の情報のフォーマットを保険会社に特有のフォーマットから共通のフォーマットに変換して共通ＤＢに格納する流れを示す。なお、この処理の流れは、全てのローカルシステム２０，３０，４０，…でほぼ同じであるため、ローカルシステム２０を代表的に例に採り、その処理を説明する。
【００４１】
基幹システム２１が、対象となる情報を基幹ＤＢ２２から読み出し、その情報を、共通サーバ２４に送る。ここで言う「対象となる情報」は、前もって指定されている種類の情報、或いは、基幹システム２１に接続されている情報処理端末（図示せず）から指定された情報である。読み出される情報は、例えば、顧客情報、インシデント情報及び保険契約情報である。
【００４２】
共通サーバ２４（変換部２４２）は、基幹システム２１から情報を受け、その情報のフォーマットを、例えば前述の変換規則情報を用いて、Ａ社に特有のフォーマットを共通のフォーマットに変換する（Ｓ２）。共通サーバ２４（変換部２４２）は、フォーマット変換後の情報を、共通ＤＢ２５に格納する（Ｓ３）。
【００４３】
図５は、インシデントの有無の調査の流れを示す。この図は、Ａ社が或る審査対象者についてインシデントの有無を調べることを例に採った流れを示す。なお、図５では、情報処理端末（以下、端末）５０１が共通サーバ２４を介して中央システム１０に接続されているが、端末５０１は、中央システム１０に直接されても良い。すなわち、ローカルシステム２０，３０及び４０の構成、及び、ローカルシステム内のどれが中央システム１０と接続されるかの構成は、任意の構成とすることができる。
【００４４】
共通サーバ２４に接続されている情報処理端末（以下、端末）５０１が、検索条件及び検索の実行を指定するための検索要求画面を表示する。検索要求画面の一例を図６に示す。この検索要求画面５０には、検索条件として、審査対象者の個人情報（氏名、生年月日等）を入力できる。また、この画面５０では、インシデントの有無の調査対象の保険会社を指定することができる。この画面５０上の「検索」ボタン５１が押された場合に、端末５０１が、検索依頼を共通サーバ２４に送信する（Ｓ１０）。その検索依頼は、入力された個人情報を検索条件として有し、且つ、指定された保険会社を表す情報（以下、指定保険会社情報）を有している。
【００４５】
共通サーバ２４が、検索依頼を受ける。共通サーバ２４（検索部２４１）が、その検索依頼に応答して、下記の（Ｓ１１）及び（Ｓ１２）の処理を行う。
（Ｓ１１）共通サーバ２４が、検索依頼が有する検索条件に適合する顧客情報が共通ＤＢ２５に有るか否かを判断する。その顧客情報が有れば、共通サーバ２４は、その顧客情報に対応する顧客についてインシデントが有るか否かを共通ＤＢ２５から調査する。例えば、その顧客情報がインシデント有りを表す情報を有していれば、或いは、その顧客情報内の情報がブラックリスト情報に含まれていれば、Ｓ１１での調査結果は、インシデント有りという結果になる。なお、検索依頼が有する指定保険会社情報に、Ａ社を表す情報が含まれていない場合には、このＳ１１は行われなくて良い。
（Ｓ１２）共通サーバ２４が、中央システム１０（中央サーバ１１）に、上記検索依頼が有する検索条件及び指定保険会社情報を有した検索要求を送信する。
【００４６】
中央サーバ１１は、検索要求を共通サーバ２４から受信する。中央サーバ１１（情報収集部１１１）は、その検索要求が有する指定保険会社情報が表す全ての保険会社（但しＡ社を除く）のローカルシステム内の共通サーバ、例えば、ローカルシステム３０及び４０内の共通サーバ３４及び４４に、調査要求を送信する（Ｓ１３、Ｓ１７）。調査要求は、検索要求が有する検索条件を有する。調査要求は、その検索条件に適合する顧客についてインシデントが有るか否かを調査することの要求である。
【００４７】
Ｂ社のローカルシステム３０では、共通サーバ３４が、調査要求を受ける。共通サーバ３４（検索部）は、その調査要求に応答して、その調査要求が有する検索条件に適合する顧客情報が共通ＤＢ３５に有るか否かを判断し、その顧客情報が有れば、その顧客情報に対応する顧客についてインシデントが有るか否かを共通ＤＢ３５から調査する（Ｓ１４）。例えば、その顧客情報がインシデント有りを表す情報を有していれば、或いは、その顧客情報内の情報がブラックリスト情報に含まれていれば、その調査結果は、インシデント有りという結果になる。共通サーバ３４は、その調査結果を表す情報（以下、調査結果情報）を、中央サーバ１１に送信する（Ｓ１５）。中央サーバ１１が、その調査結果情報が有する情報を、管理ＤＢに格納する（Ｓ１６）。
【００４８】
Ｃ社のローカルシステム４０でも、共通サーバ４４が上記調査要求を中央サーバ１１から受けたため、上記のＳ１４〜Ｓ１６と同じ処理が行われる（Ｓ１８〜Ｓ２０）。なお、Ｓ１６及びＳ２０を別々に行うことに代えて、中央サーバ１１によって作成された検索要求情報が有する情報が一度に管理ＤＢ１２に格納されて良い。
【００４９】
中央サーバ１１は、共通サーバ２４から受けた検索要求に応答した検索結果情報として、ローカルシステム３０及び４０から受けた全ての調査結果情報を含んだ情報を作成する。そして、中央サーバ１１は、検索結果情報を、検索要求の送信元である共通サーバ２４に送信する（Ｓ２１）。
【００５０】
共通サーバ２４は、Ｓ１１で取得された調査結果の情報と、中央サーバ１１からの検索結果情報とを含んだ検索結果情報を、検索依頼の送信元の端末５０１に送信する（Ｓ２２）。端末５０１において、その検索結果情報を表示した画面（以下、検索結果画面）が表示される。その検索結果画面の一例を図７に示す。
【００５１】
その検索結果画面６０には、審査対象者についての検索条件（個人情報）が表示される対象者情報エリア６１と、保険会社ごとの調査結果を示す検索結果エリア６２とが設けられている。検索結果エリア６２には、保険会社毎に、会社６２ａ，インシデントの有無６２ｂ及び詳細検索６２ｃが表示されている。会社６２ａは、調査対象となった保険会社を表す情報（例えば、保険会社の名称）である。インシデント有無６２ｂは、インシデントの有無を示す情報である。詳細検索６２ｃとは、審査対象者についての詳細な情報を得るためのボタンである。そのようなボタンとして、例えば、契約有無照会ボタン６２１ａ、インシデント照会ボタン６２２ａ及びバッチ検索依頼ボタン６２３ａがある。以下、各種ボタンを説明する。
【００５２】
＜契約有無照会ボタン６２１ａ＞。
【００５３】
審査対象者についてインシデントが無い場合、詳細検索６２ｃとして、契約有無照会ボタン６２１ａが表示される。そのボタン６２１ａが押されると、例えば、以下の処理が行われる。
（＊）端末５０１が、審査対象者の個人情報を検索条件とした契約有無照会依頼を共通サーバ２４に送信する。契約有無照会依頼は、審査対象者との間で結ばれた保険契約の情報が有るか否かを調べることの依頼である。その契約有無照会依頼は、例えば、保険会社情報を含み、その保険会社情報は、押されたボタン６２１ａに対応した保険会社（Ｂ社）を表す。
（＊）共通サーバ２４が、端末５０１からの契約有無照会依頼に応答して、契約有無照会要求を中央サーバ１１に送信する。契約有無照会要求は、端末５０１からの契約有無照会依頼が有する検索条件及び保険会社情報と同じ検索条件及び保険会社情報を有する。
（＊）中央サーバ１１は、契約有無照会要求を受けた場合、その要求が有する保険会社情報が表すＢ社の共通サーバ３４に、その要求が有する検索条件と同じ検索条件を有する契約有無照会要求を送信する。
（＊）契約有無照会要求を受けた共通サーバ３４は、共通ＤＢ３５内に、その要求が有する検索条件に適合する個人情報に対応した保険契約情報が有るか否かを調査する。その調査結果を表す調査結果情報が、共通サーバ３４から中央サーバ１１に返される。
（＊）中央サーバ１１は、共通サーバ３４からの調査結果情報を、共通サーバ２４に送信する。
（＊）共通サーバ２４は、中央サーバ１１からの調査結果情報を、契約有無照会依頼の送信元の端末５０１に送信する。その調査結果情報は、端末５０１に表示される。
【００５４】
この処理により、Ａ社のオペレータは、審査対象者がＢ社で契約を結べているか否かを知ることができる。なお、契約の有無だけでなく、契約情報それ自体が、中央サーバ１１によって他の共通サーバ３４から取得され、共通サーバ２４に送信され、端末５０１に提供されても良い。
【００５５】
＜インシデント照会ボタン６２２ａ＞。
【００５６】
審査対象者についてインシデントが有る場合、詳細検索６２ｃとして、インシデント照会ボタン６２２ａが表示される。そのボタン６２２ａが押されると、例えば以下の処理が行われる。
（＊）端末５０１が、審査対象者の個人情報を検索条件とした契約有無照会依頼を共通サーバ２４に送信する。インシデント情報取得依頼は、審査対象者についてのインシデント情報（インシデントの詳細を表す情報）を取得することの依頼である。そのインシデント情報取得依頼は、例えば、保険会社情報を含み、その保険会社情報は、押されたボタン６２２ａに対応した保険会社（Ｃ社）を表す。
（＊）共通サーバ２４が、端末５０１からのインシデント情報取得依頼に応答して、インシデント情報取得要求を中央サーバ１１に送信する。インシデント情報取得要求は、端末５０１からのインシデント情報取得要求が有する保険会社情報と同じ保険会社情報を有する。
（＊）中央サーバ１１は、インシデント情報取得要求を受けた場合、その要求が有する保険会社情報が表すＣ社の共通サーバ４４に、その要求が有する検索条件と同じ検索条件を有するインシデント情報取得要求を送信する。
（＊）インシデント情報取得要求を受けた共通サーバ４４は、共通ＤＢ４５から、その要求が有する検索条件に適合する顧客についてのインシデント情報を取得する。その取得されたインシデント情報が、共通サーバ４４から中央サーバ１１に返される。
（＊）中央サーバ１１は、共通サーバ４４からのインシデント情報を、共通サーバ２４に送信する。共通サーバ２４は、中央サーバ１１からのインシデント情報を、インシデント情報取得要求の送信元の情報処理端末に送信する。そのインシデント情報は、情報処理端末に表示される。
【００５７】
この処理により、Ａ社のオペレータは、Ｃ社で管理されている、審査対象者についてのインシデント情報を参照することができる。また、本実施形態のように、まず、インシデントの有無を表す情報（インシデント有無情報）というデータ量の少ない情報がやり取りされ、その後に、オペレータが所望する保険会社についてのみ、インシデント情報という、インシデント有無情報よりもデータ量の多い情報がやり取りされる。このため、始めからインシデント情報を取得することに比べて、オペレータに、審査対象者についてインシデントの有無を早くに知るせることができる。
【００５８】
＜バッチ検索依頼ボタン６２３ａ＞。
【００５９】
図５のＳ１２で共通サーバ２４から検索要求を受けた際に中央サーバ１１が、Ｚ社の共通サーバにアクセスできなかった場合、中央サーバ１１から共通サーバ２４に送られる検索結果情報には、Ｚ社に対応したインシデント有無６２ｂとして、「サービス時間外」を表す情報が含まれる。そして、詳細検索６２ｃとして、バッチ検索依頼ボタン６２３ａが含まれる。このボタン６２３ａが押された場合、バッチで（例えば夜間に）、再度、Ｓ１３、Ｓ１７のような調査要求発行が、Ｚ社の共通サーバに対して行われる。
【００６０】
以上が、本実施形態の説明である。本実施形態によれば、複数の保険会社のローカルシステムの各々と中央システムが通信可能であり、ローカルシステム同士が通信不可能であるので、ローカルシステム内の情報のセキュリティを維持しつつ、保険会社が、他の保険会社が管理する情報を基に、審査対象者についての審査を行うことができる。
【００６１】
また、本実施形態は、保険金を支払うか否かの審査にも適用できる。つまり、保険契約を締結するか否かという初期段階だけでなく、保険金を支払うか否かの段階についても、本実施形態を適用できる。このため、例えば、保険犯罪を実行した者が、契約時点ではその者についてのインシデント情報がどの保険会社にも無かったため例えばＡ社と契約できたとしても、その後、他社にその者についてインシデント情報が登録された場合には、保険犯罪によりＡ社に対して保険金の支払いが請求されても、Ａ社は、他社にインシデント情報があることを見つけて、その者に対して保険金を支払うことを回避することができる。
【００６２】
また、管理ＤＢ１２には、調査結果情報が含まれる。調査結果情報は、どの保険会社でインシデント情報があったかを有する情報である。このため、管理ＤＢ１２を基に、保険業界でのインシデント情報の有無に関する統計をとることができる。
【００６３】
また、管理ＤＢ１２には、保険会社毎に、その保険会社に提供された情報（例えば、調査結果情報、インシデント情報）の件数及び／又は量が格納されて良い。これにより、保険会社への課金額をリーズナブルな額とすることができる。
【００６４】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をその実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施できる。
【００６５】
例えば、本システムに接続を希望する全データ提供者（保険会社など）の同意を前提にして、頻繁に検索される情報について、あらかじめ中央システムのデータベースに蓄積管理されている形態であっても良い。
【００６６】
例えば、図５を参照して説明した流れにおいて、検索依頼を共通サーバ２４に送信する際に、保険会社が指定されなくても良い。この場合、中央サーバ１１は、全ての保険会社（Ａ社は含まれていなくても良い）のローカルシステムに、調査指示を発行して良い。
【００６７】
また、例えば、インシデント情報の有無（或いは、インシデント情報などのより詳細な情報）を応答する保険会社の実名に代えて、匿名が、検索依頼元の保険会社の端末に表示されても良い。
【００６８】
また、例えば、各保険会社のローカルシステム（例えば共通サーバ）は、照会により得た情報（例えば、インシデント情報）のフォーマットを、共通フォーマットから、その保険会社に特有のフォーマットに変換し、フォーマット変換後の情報を、基幹システムＤＢ４２に格納しても良い。これにより、各保険会社は、他社が持っているインシデント情報を、自社の基幹システムに取り込むことができ、以って、他社が有するインシデント情報を集約したものと等しい水準の広範囲なインシデント情報を保有することが可能となる。
【００６９】
また、例えば、中央システム１０には、保険会社のローカルシステムに加えて、審査対象社の審査の結果に影響を及ぼし得る情報（例えば、信頼性の高い個人信用機関が提供する情報）を提供する情報提供サーバが接続されていても良い。
【符号の説明】
【００７０】
１０ 中央システム
１１ 中央サーバ
１２ 管理ＤＢ
２０，３０，４０ ローカルシステム
２１，３１，４１ 基幹システム
２２，３２，４２ 基幹ＤＢ
２３，３３，４３ 共通システム
２４，３４，４４ 共通サーバ
２５，３５，３５ 共通ＤＢ
【技術分野】
【０００１】
本発明は、保険の審査、具体的には、例えば、保険契約をするか否か、および、保険金を支払うべきか否かの審査を支援するコンピュータ技術に関する。
【背景技術】
【０００２】
この種の技術として、例えば、特許文献１に開示されている技術がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−３４６３６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一般に、保険会社は、独自にデータベース（以下、ＤＢ）を管理している。そのＤＢは、その保険会社にとっての顧客の情報を有している。顧客の情報は、その顧客の個人情報（例えば、氏名、住所、電話番号、生年月日）を含んでいる。また、顧客の情報は、その顧客がインシデント（例えば重大な事件または事故）を起こしたことがある場合には、インシデント有りを表す情報を有する。
【０００５】
保険会社は、保険の契約を希望する者（以下、契約希望者）と契約するか否かを決定する際、及び、受取人（例えば、契約者又はその家族）に保険金を支払うか否かを決定する際には、自社のＤＢに基づいて十分審査を行う。もし、自社のＤＢに、契約希望者についてインシデント有りを表す情報が有る場合には、その契約希望者と契約しても再度何らかのインシデントが生じる可能性が考えられるため、保険会社は、その契約希望者との契約を断ることがある。或いは、もし、自社のＤＢに、受取人についてインシデント有りを表す情報が有る場合には、直ちに保険金を支払うのではなく、より詳細な調査を行うことがある。
【０００６】
近年、保険犯罪が問題となっている。保険犯罪を計画している者の手口として、或る保険会社で契約が断られた場合、別の保険会社に保険の契約を希望する手口がある。或る保険会社で契約を断られても、別の保険会社であれば契約を結べることがあるからである。これは、保険会社間で連携が取られていないことに起因する。具体的には、各保険会社は、他の保険会社が管理するＤＢ内の顧客情報を参照することができず、自社ＤＢのみに基づいて審査を行うことに起因する。
【０００７】
このため、保険会社は、契約希望者について、インシデント有りという情報が他社のＤＢに有っても自社のＤＢに無い場合には、その契約希望者と保険契約を結んでしまう可能性が高い。このケースでは、その契約希望者が保険犯罪を計画している者であるにも関わらず、危険な保険契約を結んでしまうことになり得る。
【０００８】
また、保険会社は、受取人について、インシデント有りという情報が他社のＤＢに有っても自社のＤＢに無い場合には、その受取人に直ちに保険金を支払う可能性が高い。このケースでは、受取人が保険犯罪を行った結果として保険金が請求されている可能性があるにも関わらず、保険金が支払われてしまうことになり得る。
【０００９】
これを解決するための方法として、保険会社同士が互いのＤＢを自由に参照できるようにする方法が考えられる。しかし、これは、或る保険会社にのみ開示された顧客の情報を他の保険会社が自由に取得できてしまうことになり、現実的ではないと考えられる。
【００１０】
従って、本発明の目的は、保険会社同士が互いのＤＢを自由に参照できなくても正確に審査できるようにすることにある。
【課題を解決するための手段】
【００１１】
複数の保険会社用の複数のコンピュータシステムである複数のローカルシステムと、別のコンピュータシステムである中央システムとを、専用ネットワークに接続する。各ローカルシステムは、そのローカルシステムに対応する保険会社にとっての顧客の個人情報を含んだ顧客情報を記憶しているが、そのローカルシステムに対応する保険会社以外の顧客の個人情報を含んだ顧客情報を記憶していない。各ローカルシステムが、そのローカルシステムに対応する保険会社にとってインシデントのあった顧客については、その顧客についてインシデントがあったことを表す情報を記憶している。各ローカルシステムと中央システムとの通信は可能であるが、ローカルシステム同士の通信は不可能とされる。各顧客情報は、顧客の個人情報を含んでいる。
【００１２】
複数の保険会社のうちの或る保険会社用のローカルシステムである対象ローカルシステムが、審査対象者（例えば、契約希望者又は受取人）の個人情報を検索条件として含んだ検索依頼を受け、その検索依頼に応答して、その検索条件を含んだ検索要求を、専用ネットワークを介して中央システムに送信する。中央システムが、対象ローカルシステムから専用ネットワークを介して検索要求を受信し、その検索要求に応答して、或る保険会社以外の各保険会社のローカルシステムから、その検索要求が有する検索条件に適合する顧客情報に対応する顧客についてインシデントが有るか否かを、専用ネットワークを介して調査し、その調査の結果に基づく検索結果情報を、専用ネットワークを介して対象ローカルシステムに送信する。対象ローカルシステムが、中央システムから専用ネットワークを介して検索結果情報を受信し、その検索結果情報を検索依頼の発行元に対して出力する。
【００１３】
なお、保険会社の「顧客」とは、その保険会社と保険の契約をしている者、及び、その保険会社の過去に保険の契約をしたことがある者の他に、保険を契約するにはいたらなかったがその保険会社とコンタクトした者が含まれていても良い。また、本発明は、様々な保険会社（生命保険会社、損害保険会社など）に適用可能である。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施形態に係る保険審査支援システムの構成を示す。
【図２】システム間の関係を示す。
【図３】共通サーバ及び中央サーバの機能の一例を示す。
【図４】基幹ＤＢ内の情報のフォーマットを保険会社に特有のフォーマットから共通のフォーマットに変換して共通ＤＢに格納する流れを示す。
【図５】インシデントの有無の調査の流れを示す。
【図６】検索要求画面の一例を示す。
【図７】検索結果画面の一例を示す。
【発明を実施するための形態】
【００１５】
本発明の一実施形態によれば、保険会社同士が互いのＤＢを自由に参照することはできないが、保険会社が、保険の審査（例えば、契約希望者又は受取人の審査）を行う際に、自社のＤＢ内の情報の他に、他の保険会社のＤＢ内の情報に基づいて審査できる。以下、本実施形態に係る保険審査支援システムを、図面を参照して説明する。
【００１６】
図１は、本実施形態に係る保険審査支援システムの構成を示す。
【００１７】
同図に示すように、本システムは、中央システム１０と、複数の保険会社にそれぞれ対応した複数のローカルシステム２０，３０，４０，…とを備える。中央システム１０、複数のローカルシステム２０，３０，４０，…のいずれも、コンピュータシステムである。中央システム１０と、複数のローカルシステム２０，３０，４０，…が、専用ネットワーク１００に接続されている。専用ネットワーク１００は、いわゆる閉じた通信ネットワークであり、インターネットのように不特定の者が繋がり得る通信ネットワークではない。
【００１８】
ローカルシステム２０，３０，４０，…は、それぞれ、基幹システム２１，３１，４１，…と、基幹ＤＢ２２，３２，４２，…と、共通システム２３，３３，４３，…とを有する。以下、ローカルシステム２０を例に採り、ローカルシステム２０，３０，４０，…が有する上記要素を説明する。なお、その説明において、ローカルシステム２０を有する保険会社を、図１に示すように、「Ａ社」とする。
【００１９】
基幹システム２１は、Ａ社に特有の機能及び／又は構造を有するコンピュータシステムである。基幹システム２１は、基幹ＤＢ２２を管理する。
【００２０】
基幹ＤＢ２２は、基幹システム２１に接続されている記憶装置に格納されている。基幹ＤＢ２２は、例えば、Ａ社の顧客の顧客情報を含み、他の保険会社の顧客の顧客情報を含まない。顧客情報は、例えば、顧客の個人情報（例えば、氏名、住所、電話番号、生年月日）を含んでいる。また、顧客情報は、その顧客情報に対応した顧客がインシデント（例えば重大な事故）を起こしたことがある場合には、インシデント有りを表す情報を有する。基幹ＤＢ２２は、インシデント有りの顧客に関する情報が集約された情報であるブラックリスト情報を含む。ブラックリスト情報は、インシデント有りの顧客に関する情報（例えば、顧客の識別情報、個人情報）を含む。また、基幹ＤＢ２２は、インシデントの詳細を表すインシデント情報や、顧客と結ばれた保険契約の詳細を表す保険契約情報を有する。インシデント情報及び保険契約情報の少なくとも一方が顧客情報に含まれる。
【００２１】
基幹ＤＢ２２に含まれている情報（例えば顧客情報）のフォーマットは、Ａ社（厳密には、Ａ社の基幹システム２１）に特有のフォーマットである。例えば、Ａ社の従業員が、基幹システム２１に接続されている情報処理端末（図示せず）を用いて、基幹システム２１に顧客情報を入力すると、Ａ社に特有のフォーマットの顧客情報が、基幹ＤＢ２２に格納される。
【００２２】
共通システム２３は、共通サーバ２４と、共通ＤＢ２５とを有する。
【００２３】
共通サーバ２４は、例えば、プロセッサ（例えばＣＰＵ（Central Processing Unit））と記憶資源（例えばメモリ）を有する計算機である。共通サーバ２４の機能は、例えば、共通サーバ２４内のプロセッサがコンピュータプログラムを実行することにより実現される。
【００２４】
共通ＤＢ２５は、共通サーバ２４に接続されている記憶装置に格納されている。共通ＤＢ２５は、基幹ＤＢ２２から読み出されフォーマット変換された情報（例えば、少なくとも顧客情報）を有する。共通ＤＢ内の情報のフォーマットは、全ての保険会社で共通のフォーマットである。共通システム２３は、中央システム１０に対するインタフェースとしての役割も担う。共通サーバ２４は、例えば、変換前のフォーマット（Ａ社に特有のフォーマット）と変換後のフォーマット（全ての保険会社で共通のフォーマット）との対応関係を表す情報（以下、変換規則情報）を有していて、その変換規則情報を用いて、フォーマット変換を行って良い。例えば、Ａ社に特有のフォーマットの顧客情報において、「１」という値がＮＧを意味していて、共通フォーマットの顧客情報では「３」という値がＮＧを意味している場合、Ａ社の共通サーバ２４が有する変換規則情報は、「１→３」の変換規則を表す情報が含まれていて、フォーマット変換では、その変換規則に従う変換が行われる。
【００２５】
共通システム２３，３３，４３，…は、実質的に同じ機能及び構成を有するが、その機能及び／又は構成は、保険会社毎にカスタマイズされて良い。例えば、前述した変換規則情報が、共通サーバ毎に異なっていて良い。
【００２６】
ローカルシステム２０は、共通システム２３（共通サーバ２４）が、専用ネットワーク１００を介して中央システム１０（中央サーバ１１）と接続されることにより、中央システム１０とのみ通信可能となる。
【００２７】
中央システム１０は、保険会社以外の機関によって管理されている。中央システム１０は、例えば、中央サーバ１１と、管理ＤＢ１２とを有する。
【００２８】
中央サーバ１１は、例えば、プロセッサ（例えばＣＰＵ）と記憶資源（例えばメモリ）を有する計算機である。中央サーバ１１の機能は、例えば、中央サーバ１１内のプロセッサがコンピュータプログラムを実行することにより実現される。
【００２９】
管理ＤＢ１２は、中央サーバ１１に接続されている記憶装置に格納されている。管理ＤＢ１２には、後述の検索結果情報が有する情報が格納される。管理ＤＢ１２内の情報は、種々の観点、例えば、統計及び課金の上で、有用である（詳細は後述する）。
【００３０】
図２は、システム間の関係を示す。
【００３１】
図２（ａ）に示すように、ローカルシステム２０，３０，４０，…同士は、通信可能に接続されておらず、それ故、互いに通信できない。一方、図２（ｂ）に示すように、中央システム１０と各ローカルシステム２０，３０，４０，…同士は、通信可能に接続されていて、それ故、互いに通信できる。つまり、各ローカルシステム２０，３０，４０，…は、中央システム１０とのみ通信可能であり、中央システム１０は、全てのローカルシステム２０，３０，４０，…と通信可能である。このような制御は、例えば、グループＶＰＮ（Virtual Private Network）で実現可能である。
【００３２】
図３（ａ）は、共通サーバ２４の機能の一例を示す。なお、共通サーバ２４，３４，４４，…の機能は実質的に同一であるため、図３（ａ）には、代表して、共通サーバ２４のみを示してある。
【００３３】
共通サーバ２４は、検索部２４１と変換部２４２とを備える。検索部２４１と変換部２４２は、例えば、プロセッサが所定のコンピュータプログラムを実行することにより実現される機能である。
【００３４】
検索部２４１は、共通サーバ２４に接続されている情報処理端末（図示せず）からの、審査対象者（例えば、契約希望者又は受取人）の個人情報を検索条件とした検索依頼を受け、その検索依頼に応答して、その検索条件を含んだ検索要求を中央システム１０に送信する。また、検索部２４１は、中央システム１０から検索要求を受け、その検索要求に応答して、その検索要求が有する検索条件（個人情報）に該当するインシデントの有無を判断し、その判断の結果を表す情報を中央システム１０に送信する。
【００３５】
変換部２４２は、基幹ＤＢ２２からの情報のフォーマットを、Ａ社に特有のフォーマットから全ての保険会社に共通のフォーマットに変換し、変換後の情報を共通ＤＢ２５に格納する。
【００３６】
図３（ｂ）は、中央サーバ２５の機能の一例を示す。
【００３７】
中央サーバ１１は、情報収集部１１１を備える。情報収集部１１１は、例えば、プロセッサが所定のコンピュータプログラムを実行することにより実現される機能である。
【００３８】
情報収集部１１１は、ローカルシステムから検索要求を受け、その検索要求に応答して、その検索要求が有する検索条件に適合する顧客情報を有するローカルシステムから、その顧客情報に対応した顧客についてのインシデントの有無を調査する。情報収集部１１１は、調査の結果を表す情報（検索結果情報）を、検索要求の送信元のローカルシステムに送信し、且つ、その検索結果情報が有する情報を管理ＤＢ１２に格納する。
【００３９】
以下、本実施形態で行われる処理を説明する。
【００４０】
図４は、基幹ＤＢ内の情報のフォーマットを保険会社に特有のフォーマットから共通のフォーマットに変換して共通ＤＢに格納する流れを示す。なお、この処理の流れは、全てのローカルシステム２０，３０，４０，…でほぼ同じであるため、ローカルシステム２０を代表的に例に採り、その処理を説明する。
【００４１】
基幹システム２１が、対象となる情報を基幹ＤＢ２２から読み出し、その情報を、共通サーバ２４に送る。ここで言う「対象となる情報」は、前もって指定されている種類の情報、或いは、基幹システム２１に接続されている情報処理端末（図示せず）から指定された情報である。読み出される情報は、例えば、顧客情報、インシデント情報及び保険契約情報である。
【００４２】
共通サーバ２４（変換部２４２）は、基幹システム２１から情報を受け、その情報のフォーマットを、例えば前述の変換規則情報を用いて、Ａ社に特有のフォーマットを共通のフォーマットに変換する（Ｓ２）。共通サーバ２４（変換部２４２）は、フォーマット変換後の情報を、共通ＤＢ２５に格納する（Ｓ３）。
【００４３】
図５は、インシデントの有無の調査の流れを示す。この図は、Ａ社が或る審査対象者についてインシデントの有無を調べることを例に採った流れを示す。なお、図５では、情報処理端末（以下、端末）５０１が共通サーバ２４を介して中央システム１０に接続されているが、端末５０１は、中央システム１０に直接されても良い。すなわち、ローカルシステム２０，３０及び４０の構成、及び、ローカルシステム内のどれが中央システム１０と接続されるかの構成は、任意の構成とすることができる。
【００４４】
共通サーバ２４に接続されている情報処理端末（以下、端末）５０１が、検索条件及び検索の実行を指定するための検索要求画面を表示する。検索要求画面の一例を図６に示す。この検索要求画面５０には、検索条件として、審査対象者の個人情報（氏名、生年月日等）を入力できる。また、この画面５０では、インシデントの有無の調査対象の保険会社を指定することができる。この画面５０上の「検索」ボタン５１が押された場合に、端末５０１が、検索依頼を共通サーバ２４に送信する（Ｓ１０）。その検索依頼は、入力された個人情報を検索条件として有し、且つ、指定された保険会社を表す情報（以下、指定保険会社情報）を有している。
【００４５】
共通サーバ２４が、検索依頼を受ける。共通サーバ２４（検索部２４１）が、その検索依頼に応答して、下記の（Ｓ１１）及び（Ｓ１２）の処理を行う。
（Ｓ１１）共通サーバ２４が、検索依頼が有する検索条件に適合する顧客情報が共通ＤＢ２５に有るか否かを判断する。その顧客情報が有れば、共通サーバ２４は、その顧客情報に対応する顧客についてインシデントが有るか否かを共通ＤＢ２５から調査する。例えば、その顧客情報がインシデント有りを表す情報を有していれば、或いは、その顧客情報内の情報がブラックリスト情報に含まれていれば、Ｓ１１での調査結果は、インシデント有りという結果になる。なお、検索依頼が有する指定保険会社情報に、Ａ社を表す情報が含まれていない場合には、このＳ１１は行われなくて良い。
（Ｓ１２）共通サーバ２４が、中央システム１０（中央サーバ１１）に、上記検索依頼が有する検索条件及び指定保険会社情報を有した検索要求を送信する。
【００４６】
中央サーバ１１は、検索要求を共通サーバ２４から受信する。中央サーバ１１（情報収集部１１１）は、その検索要求が有する指定保険会社情報が表す全ての保険会社（但しＡ社を除く）のローカルシステム内の共通サーバ、例えば、ローカルシステム３０及び４０内の共通サーバ３４及び４４に、調査要求を送信する（Ｓ１３、Ｓ１７）。調査要求は、検索要求が有する検索条件を有する。調査要求は、その検索条件に適合する顧客についてインシデントが有るか否かを調査することの要求である。
【００４７】
Ｂ社のローカルシステム３０では、共通サーバ３４が、調査要求を受ける。共通サーバ３４（検索部）は、その調査要求に応答して、その調査要求が有する検索条件に適合する顧客情報が共通ＤＢ３５に有るか否かを判断し、その顧客情報が有れば、その顧客情報に対応する顧客についてインシデントが有るか否かを共通ＤＢ３５から調査する（Ｓ１４）。例えば、その顧客情報がインシデント有りを表す情報を有していれば、或いは、その顧客情報内の情報がブラックリスト情報に含まれていれば、その調査結果は、インシデント有りという結果になる。共通サーバ３４は、その調査結果を表す情報（以下、調査結果情報）を、中央サーバ１１に送信する（Ｓ１５）。中央サーバ１１が、その調査結果情報が有する情報を、管理ＤＢに格納する（Ｓ１６）。
【００４８】
Ｃ社のローカルシステム４０でも、共通サーバ４４が上記調査要求を中央サーバ１１から受けたため、上記のＳ１４〜Ｓ１６と同じ処理が行われる（Ｓ１８〜Ｓ２０）。なお、Ｓ１６及びＳ２０を別々に行うことに代えて、中央サーバ１１によって作成された検索要求情報が有する情報が一度に管理ＤＢ１２に格納されて良い。
【００４９】
中央サーバ１１は、共通サーバ２４から受けた検索要求に応答した検索結果情報として、ローカルシステム３０及び４０から受けた全ての調査結果情報を含んだ情報を作成する。そして、中央サーバ１１は、検索結果情報を、検索要求の送信元である共通サーバ２４に送信する（Ｓ２１）。
【００５０】
共通サーバ２４は、Ｓ１１で取得された調査結果の情報と、中央サーバ１１からの検索結果情報とを含んだ検索結果情報を、検索依頼の送信元の端末５０１に送信する（Ｓ２２）。端末５０１において、その検索結果情報を表示した画面（以下、検索結果画面）が表示される。その検索結果画面の一例を図７に示す。
【００５１】
その検索結果画面６０には、審査対象者についての検索条件（個人情報）が表示される対象者情報エリア６１と、保険会社ごとの調査結果を示す検索結果エリア６２とが設けられている。検索結果エリア６２には、保険会社毎に、会社６２ａ，インシデントの有無６２ｂ及び詳細検索６２ｃが表示されている。会社６２ａは、調査対象となった保険会社を表す情報（例えば、保険会社の名称）である。インシデント有無６２ｂは、インシデントの有無を示す情報である。詳細検索６２ｃとは、審査対象者についての詳細な情報を得るためのボタンである。そのようなボタンとして、例えば、契約有無照会ボタン６２１ａ、インシデント照会ボタン６２２ａ及びバッチ検索依頼ボタン６２３ａがある。以下、各種ボタンを説明する。
【００５２】
＜契約有無照会ボタン６２１ａ＞。
【００５３】
審査対象者についてインシデントが無い場合、詳細検索６２ｃとして、契約有無照会ボタン６２１ａが表示される。そのボタン６２１ａが押されると、例えば、以下の処理が行われる。
（＊）端末５０１が、審査対象者の個人情報を検索条件とした契約有無照会依頼を共通サーバ２４に送信する。契約有無照会依頼は、審査対象者との間で結ばれた保険契約の情報が有るか否かを調べることの依頼である。その契約有無照会依頼は、例えば、保険会社情報を含み、その保険会社情報は、押されたボタン６２１ａに対応した保険会社（Ｂ社）を表す。
（＊）共通サーバ２４が、端末５０１からの契約有無照会依頼に応答して、契約有無照会要求を中央サーバ１１に送信する。契約有無照会要求は、端末５０１からの契約有無照会依頼が有する検索条件及び保険会社情報と同じ検索条件及び保険会社情報を有する。
（＊）中央サーバ１１は、契約有無照会要求を受けた場合、その要求が有する保険会社情報が表すＢ社の共通サーバ３４に、その要求が有する検索条件と同じ検索条件を有する契約有無照会要求を送信する。
（＊）契約有無照会要求を受けた共通サーバ３４は、共通ＤＢ３５内に、その要求が有する検索条件に適合する個人情報に対応した保険契約情報が有るか否かを調査する。その調査結果を表す調査結果情報が、共通サーバ３４から中央サーバ１１に返される。
（＊）中央サーバ１１は、共通サーバ３４からの調査結果情報を、共通サーバ２４に送信する。
（＊）共通サーバ２４は、中央サーバ１１からの調査結果情報を、契約有無照会依頼の送信元の端末５０１に送信する。その調査結果情報は、端末５０１に表示される。
【００５４】
この処理により、Ａ社のオペレータは、審査対象者がＢ社で契約を結べているか否かを知ることができる。なお、契約の有無だけでなく、契約情報それ自体が、中央サーバ１１によって他の共通サーバ３４から取得され、共通サーバ２４に送信され、端末５０１に提供されても良い。
【００５５】
＜インシデント照会ボタン６２２ａ＞。
【００５６】
審査対象者についてインシデントが有る場合、詳細検索６２ｃとして、インシデント照会ボタン６２２ａが表示される。そのボタン６２２ａが押されると、例えば以下の処理が行われる。
（＊）端末５０１が、審査対象者の個人情報を検索条件とした契約有無照会依頼を共通サーバ２４に送信する。インシデント情報取得依頼は、審査対象者についてのインシデント情報（インシデントの詳細を表す情報）を取得することの依頼である。そのインシデント情報取得依頼は、例えば、保険会社情報を含み、その保険会社情報は、押されたボタン６２２ａに対応した保険会社（Ｃ社）を表す。
（＊）共通サーバ２４が、端末５０１からのインシデント情報取得依頼に応答して、インシデント情報取得要求を中央サーバ１１に送信する。インシデント情報取得要求は、端末５０１からのインシデント情報取得要求が有する保険会社情報と同じ保険会社情報を有する。
（＊）中央サーバ１１は、インシデント情報取得要求を受けた場合、その要求が有する保険会社情報が表すＣ社の共通サーバ４４に、その要求が有する検索条件と同じ検索条件を有するインシデント情報取得要求を送信する。
（＊）インシデント情報取得要求を受けた共通サーバ４４は、共通ＤＢ４５から、その要求が有する検索条件に適合する顧客についてのインシデント情報を取得する。その取得されたインシデント情報が、共通サーバ４４から中央サーバ１１に返される。
（＊）中央サーバ１１は、共通サーバ４４からのインシデント情報を、共通サーバ２４に送信する。共通サーバ２４は、中央サーバ１１からのインシデント情報を、インシデント情報取得要求の送信元の情報処理端末に送信する。そのインシデント情報は、情報処理端末に表示される。
【００５７】
この処理により、Ａ社のオペレータは、Ｃ社で管理されている、審査対象者についてのインシデント情報を参照することができる。また、本実施形態のように、まず、インシデントの有無を表す情報（インシデント有無情報）というデータ量の少ない情報がやり取りされ、その後に、オペレータが所望する保険会社についてのみ、インシデント情報という、インシデント有無情報よりもデータ量の多い情報がやり取りされる。このため、始めからインシデント情報を取得することに比べて、オペレータに、審査対象者についてインシデントの有無を早くに知るせることができる。
【００５８】
＜バッチ検索依頼ボタン６２３ａ＞。
【００５９】
図５のＳ１２で共通サーバ２４から検索要求を受けた際に中央サーバ１１が、Ｚ社の共通サーバにアクセスできなかった場合、中央サーバ１１から共通サーバ２４に送られる検索結果情報には、Ｚ社に対応したインシデント有無６２ｂとして、「サービス時間外」を表す情報が含まれる。そして、詳細検索６２ｃとして、バッチ検索依頼ボタン６２３ａが含まれる。このボタン６２３ａが押された場合、バッチで（例えば夜間に）、再度、Ｓ１３、Ｓ１７のような調査要求発行が、Ｚ社の共通サーバに対して行われる。
【００６０】
以上が、本実施形態の説明である。本実施形態によれば、複数の保険会社のローカルシステムの各々と中央システムが通信可能であり、ローカルシステム同士が通信不可能であるので、ローカルシステム内の情報のセキュリティを維持しつつ、保険会社が、他の保険会社が管理する情報を基に、審査対象者についての審査を行うことができる。
【００６１】
また、本実施形態は、保険金を支払うか否かの審査にも適用できる。つまり、保険契約を締結するか否かという初期段階だけでなく、保険金を支払うか否かの段階についても、本実施形態を適用できる。このため、例えば、保険犯罪を実行した者が、契約時点ではその者についてのインシデント情報がどの保険会社にも無かったため例えばＡ社と契約できたとしても、その後、他社にその者についてインシデント情報が登録された場合には、保険犯罪によりＡ社に対して保険金の支払いが請求されても、Ａ社は、他社にインシデント情報があることを見つけて、その者に対して保険金を支払うことを回避することができる。
【００６２】
また、管理ＤＢ１２には、調査結果情報が含まれる。調査結果情報は、どの保険会社でインシデント情報があったかを有する情報である。このため、管理ＤＢ１２を基に、保険業界でのインシデント情報の有無に関する統計をとることができる。
【００６３】
また、管理ＤＢ１２には、保険会社毎に、その保険会社に提供された情報（例えば、調査結果情報、インシデント情報）の件数及び／又は量が格納されて良い。これにより、保険会社への課金額をリーズナブルな額とすることができる。
【００６４】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をその実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施できる。
【００６５】
例えば、本システムに接続を希望する全データ提供者（保険会社など）の同意を前提にして、頻繁に検索される情報について、あらかじめ中央システムのデータベースに蓄積管理されている形態であっても良い。
【００６６】
例えば、図５を参照して説明した流れにおいて、検索依頼を共通サーバ２４に送信する際に、保険会社が指定されなくても良い。この場合、中央サーバ１１は、全ての保険会社（Ａ社は含まれていなくても良い）のローカルシステムに、調査指示を発行して良い。
【００６７】
また、例えば、インシデント情報の有無（或いは、インシデント情報などのより詳細な情報）を応答する保険会社の実名に代えて、匿名が、検索依頼元の保険会社の端末に表示されても良い。
【００６８】
また、例えば、各保険会社のローカルシステム（例えば共通サーバ）は、照会により得た情報（例えば、インシデント情報）のフォーマットを、共通フォーマットから、その保険会社に特有のフォーマットに変換し、フォーマット変換後の情報を、基幹システムＤＢ４２に格納しても良い。これにより、各保険会社は、他社が持っているインシデント情報を、自社の基幹システムに取り込むことができ、以って、他社が有するインシデント情報を集約したものと等しい水準の広範囲なインシデント情報を保有することが可能となる。
【００６９】
また、例えば、中央システム１０には、保険会社のローカルシステムに加えて、審査対象社の審査の結果に影響を及ぼし得る情報（例えば、信頼性の高い個人信用機関が提供する情報）を提供する情報提供サーバが接続されていても良い。
【符号の説明】
【００７０】
１０ 中央システム
１１ 中央サーバ
１２ 管理ＤＢ
２０，３０，４０ ローカルシステム
２１，３１，４１ 基幹システム
２２，３２，４２ 基幹ＤＢ
２３，３３，４３ 共通システム
２４，３４，４４ 共通サーバ
２５，３５，３５ 共通ＤＢ
【特許請求の範囲】
【請求項１】
保険の審査を支援するシステムであって、
専用ネットワークに接続された、複数の保険会社用の複数のコンピュータシステムである複数のローカルシステムと、
前記専用ネットワークに接続されたコンピュータシステムである中央システムと
を有し、
各ローカルシステムが、そのローカルシステムに対応する保険会社にとっての顧客の個人情報を含んだ顧客情報を記憶しているが、そのローカルシステムに対応する保険会社以外の顧客の個人情報を含んだ顧客情報を記憶しておらず、
各ローカルシステムが、そのローカルシステムに対応する保険会社にとってインシデントのあった顧客については、その顧客についてインシデントがあったことを表す情報を記憶しており、
前記各ローカルシステムと前記中央システムとの通信は可能であるが、ローカルシステム同士の通信は不可能とされており、
前記複数の保険会社のうちの或る保険会社用のローカルシステムである対象ローカルシステムが、審査対象者の個人情報を検索条件として含んだ検索依頼を受け、その検索依頼に応答して、その検索条件を含んだ検索要求を、前記専用ネットワークを介して前記中央システムに送信し、
前記中央システムが、前記対象ローカルシステムから前記専用ネットワークを介して前記検索要求を受信し、その検索要求に応答して、前記或る保険会社以外の各保険会社のローカルシステムから、その検索要求が有する検索条件に適合する顧客情報に対応した顧客についてインシデントが有るか否かを、前記専用ネットワークを介して調査し、その調査の結果に基づく検索結果情報を、前記専用ネットワークを介して前記対象ローカルシステムに送信し、
前記対象ローカルシステムが、前記中央システムから前記専用ネットワークを介して前記検索結果情報を受信し、その検索結果情報を前記検索依頼元に対して出力する、
保険審査支援システム。
【請求項２】
請求項１記載のシステムであって、
前記中央システムが、前記検索結果情報が有する情報を記憶する、
保険審査支援システム。
【請求項３】
請求項１又は２記載のシステムであって、
各ローカルシステムは、そのローカルシステムに対応する保険会社にとってそのインシデントのあった顧客について、インシデントの詳細を表すインシデント情報を記憶しており、
前記検索結果情報は、インシデントの有無を表す情報を含み、インシデント情報それ自体を含んでおらず、
前記検索結果情報がインシデント有りを表す情報を含んでおり、且つ、インシデント情報の照会依頼を受けた場合、前記対象ローカルシステムが、インシデント情報の照会要求を、前記専用ネットワークを介して前記中央システムに送信し、
前記中央システムが、前記対象ローカルシステムから前記専用ネットワークを介して前記照会要求を受信し、前記照会要求に応答して、前記或る保険会社以外の保険会社のローカルシステムのうち、前記審査対象者のインシデント情報を記憶しているローカルシステムから、前記専用ネットワークを介して前記審査対象者のインシデント情報を取得し、取得したインシデント情報を、前記専用ネットワークを介して前記対象ローカルシステムに送信し、
前記対象ローカルシステムが、前記中央システムから前記専用ネットワークを介してインシデント情報を受信し、そのインシデント情報を、前記照会依頼の発行元に対して出力する、
保険審査支援システム。
【請求項４】
請求項１乃至３のうちのいずれか１項に記載のシステムであって、
各ローカルシステムは、そのローカルシステムに対応した保険会社に特有のフォーマットの情報を管理するコンピュータシステムであるオリジナルシステムと、その情報のフォーマットを前記特有のフォーマットから前記複数の保険会社に共通のフォーマットに変換しその共通のフォーマットの情報を管理する共通システムとを有し、
インシデントを有するか否かの調査対象は、前記共通のフォーマットの情報である、
保険審査支援システム。
【請求項５】
保険の審査を支援する方法であって、
複数の保険会社用の複数のコンピュータシステムである複数のローカルシステムのうちの或る保険会社用のローカルシステムである対象ローカルシステムが、審査対象者の個人情報を検索条件として含んだ検索依頼を受け、その検索依頼に応答して、その検索条件を含んだ検索要求を、専用ネットワークを介して、中央システムに送信するステップと、
前記中央システムが、前記対象ローカルシステムから前記専用ネットワークを介して前記検索要求を受信し、その検索要求に応答して、前記或る保険会社以外の各保険会社のローカルシステムから、その検索要求が有する検索条件に適合する顧客情報に対応した顧客についてインシデントが有るか否かを、前記専用ネットワークを介して調査し、その調査の結果に基づく検索結果情報を、前記専用ネットワークを介して前記対象ローカルシステムに送信するステップと、
前記対象ローカルシステムが、前記中央システムから前記専用ネットワークを介して前記検索結果情報を受信し、その検索結果情報を前記検索依頼の発行元に対して出力するステップと
を有し、
各ローカルシステムが、そのローカルシステムに対応する保険会社にとっての顧客の個人情報を含んだ顧客情報を記憶しているが、そのローカルシステムに対応する保険会社以外の顧客の個人情報を含んだ顧客情報を記憶しておらず、
各ローカルシステムが、そのローカルシステムに対応する保険会社にとってインシデントのあった顧客については、その顧客についてインシデントがあったことを表す情報を記憶しており、
前記各ローカルシステムと前記中央システムとの通信は可能であるが、ローカルシステム同士の通信は不可能とされている、
保険審査支援方法。
【請求項１】
保険の審査を支援するシステムであって、
専用ネットワークに接続された、複数の保険会社用の複数のコンピュータシステムである複数のローカルシステムと、
前記専用ネットワークに接続されたコンピュータシステムである中央システムと
を有し、
各ローカルシステムが、そのローカルシステムに対応する保険会社にとっての顧客の個人情報を含んだ顧客情報を記憶しているが、そのローカルシステムに対応する保険会社以外の顧客の個人情報を含んだ顧客情報を記憶しておらず、
各ローカルシステムが、そのローカルシステムに対応する保険会社にとってインシデントのあった顧客については、その顧客についてインシデントがあったことを表す情報を記憶しており、
前記各ローカルシステムと前記中央システムとの通信は可能であるが、ローカルシステム同士の通信は不可能とされており、
前記複数の保険会社のうちの或る保険会社用のローカルシステムである対象ローカルシステムが、審査対象者の個人情報を検索条件として含んだ検索依頼を受け、その検索依頼に応答して、その検索条件を含んだ検索要求を、前記専用ネットワークを介して前記中央システムに送信し、
前記中央システムが、前記対象ローカルシステムから前記専用ネットワークを介して前記検索要求を受信し、その検索要求に応答して、前記或る保険会社以外の各保険会社のローカルシステムから、その検索要求が有する検索条件に適合する顧客情報に対応した顧客についてインシデントが有るか否かを、前記専用ネットワークを介して調査し、その調査の結果に基づく検索結果情報を、前記専用ネットワークを介して前記対象ローカルシステムに送信し、
前記対象ローカルシステムが、前記中央システムから前記専用ネットワークを介して前記検索結果情報を受信し、その検索結果情報を前記検索依頼元に対して出力する、
保険審査支援システム。
【請求項２】
請求項１記載のシステムであって、
前記中央システムが、前記検索結果情報が有する情報を記憶する、
保険審査支援システム。
【請求項３】
請求項１又は２記載のシステムであって、
各ローカルシステムは、そのローカルシステムに対応する保険会社にとってそのインシデントのあった顧客について、インシデントの詳細を表すインシデント情報を記憶しており、
前記検索結果情報は、インシデントの有無を表す情報を含み、インシデント情報それ自体を含んでおらず、
前記検索結果情報がインシデント有りを表す情報を含んでおり、且つ、インシデント情報の照会依頼を受けた場合、前記対象ローカルシステムが、インシデント情報の照会要求を、前記専用ネットワークを介して前記中央システムに送信し、
前記中央システムが、前記対象ローカルシステムから前記専用ネットワークを介して前記照会要求を受信し、前記照会要求に応答して、前記或る保険会社以外の保険会社のローカルシステムのうち、前記審査対象者のインシデント情報を記憶しているローカルシステムから、前記専用ネットワークを介して前記審査対象者のインシデント情報を取得し、取得したインシデント情報を、前記専用ネットワークを介して前記対象ローカルシステムに送信し、
前記対象ローカルシステムが、前記中央システムから前記専用ネットワークを介してインシデント情報を受信し、そのインシデント情報を、前記照会依頼の発行元に対して出力する、
保険審査支援システム。
【請求項４】
請求項１乃至３のうちのいずれか１項に記載のシステムであって、
各ローカルシステムは、そのローカルシステムに対応した保険会社に特有のフォーマットの情報を管理するコンピュータシステムであるオリジナルシステムと、その情報のフォーマットを前記特有のフォーマットから前記複数の保険会社に共通のフォーマットに変換しその共通のフォーマットの情報を管理する共通システムとを有し、
インシデントを有するか否かの調査対象は、前記共通のフォーマットの情報である、
保険審査支援システム。
【請求項５】
保険の審査を支援する方法であって、
複数の保険会社用の複数のコンピュータシステムである複数のローカルシステムのうちの或る保険会社用のローカルシステムである対象ローカルシステムが、審査対象者の個人情報を検索条件として含んだ検索依頼を受け、その検索依頼に応答して、その検索条件を含んだ検索要求を、専用ネットワークを介して、中央システムに送信するステップと、
前記中央システムが、前記対象ローカルシステムから前記専用ネットワークを介して前記検索要求を受信し、その検索要求に応答して、前記或る保険会社以外の各保険会社のローカルシステムから、その検索要求が有する検索条件に適合する顧客情報に対応した顧客についてインシデントが有るか否かを、前記専用ネットワークを介して調査し、その調査の結果に基づく検索結果情報を、前記専用ネットワークを介して前記対象ローカルシステムに送信するステップと、
前記対象ローカルシステムが、前記中央システムから前記専用ネットワークを介して前記検索結果情報を受信し、その検索結果情報を前記検索依頼の発行元に対して出力するステップと
を有し、
各ローカルシステムが、そのローカルシステムに対応する保険会社にとっての顧客の個人情報を含んだ顧客情報を記憶しているが、そのローカルシステムに対応する保険会社以外の顧客の個人情報を含んだ顧客情報を記憶しておらず、
各ローカルシステムが、そのローカルシステムに対応する保険会社にとってインシデントのあった顧客については、その顧客についてインシデントがあったことを表す情報を記憶しており、
前記各ローカルシステムと前記中央システムとの通信は可能であるが、ローカルシステム同士の通信は不可能とされている、
保険審査支援方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１１−２０３９４５（Ｐ２０１１−２０３９４５Ａ）
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願番号】特願２０１０−６９８２７（Ｐ２０１０−６９８２７）
【出願日】平成２２年３月２５日（２０１０．３．２５）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願日】平成２２年３月２５日（２０１０．３．２５）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
[ Back to top ]