特開2022-129452保険金請求代行装置、保険金請求代行システム、保険金請求代行方法、保険金請求代行プログラム及び記録媒体
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022129452
(43)【公開日】2022-09-06
(54)【発明の名称】保険金請求代行装置、保険金請求代行システム、保険金請求代行方法、保険金請求代行プログラム及び記録媒体
(51)【国際特許分類】
G06Q 40/08 20120101AFI20220830BHJP
【ＦＩ】
G06Q40/08
【審査請求】未請求
【請求項の数】15
【出願形態】ＯＬ
(21)【出願番号】P 2021028116
(22)【出願日】2021-02-25
(71)【出願人】
【識別番号】000000295
【氏名又は名称】沖電気工業株式会社
(74)【代理人】
【識別番号】110001025
【氏名又は名称】弁理士法人レクスト国際特許事務所
(72)【発明者】
【氏名】安田 弘法
【テーマコード（参考）】
5L055
【Ｆターム（参考）】
5L055BB61
(57)【要約】 （修正有）
【課題】保険金請求手続を効率化し、円滑な保険金請求を実現可能にする保険金請求代行装置、保険金請求代行システム、保険金請求代行方法、プログラム及び記録媒体を提供する。
【解決手段】保険金請求代行システムにおいて、保険金請求代行サーバは、保険金請求代行サービスの利用者の利用者端末から特定の保険会社への保険金請求を受け付けて請求必要事項を取得する受付部、請求必要事項に基づき請求先の保険会社の保険会社システムと通信を行い請求に係る契約内容を取得する契約内容取得部と、請求必要事項及び契約内容に基き請求に当たり保険会社に提出する必要のある書類を特定する必要書類特定部、必要書類特定部が特定した１以上の必要書類の各々の送信を求める要求を外部に送信する書類要求送信部と、外部から必要書類を受信する書類受信部及び必要書類と請求必要事項とを含む請求情報を保険会社システムに送信し請求処理を行う請求処理部を有する。
【選択図】図１
【解決手段】保険金請求代行システムにおいて、保険金請求代行サーバは、保険金請求代行サービスの利用者の利用者端末から特定の保険会社への保険金請求を受け付けて請求必要事項を取得する受付部、請求必要事項に基づき請求先の保険会社の保険会社システムと通信を行い請求に係る契約内容を取得する契約内容取得部と、請求必要事項及び契約内容に基き請求に当たり保険会社に提出する必要のある書類を特定する必要書類特定部、必要書類特定部が特定した１以上の必要書類の各々の送信を求める要求を外部に送信する書類要求送信部と、外部から必要書類を受信する書類受信部及び必要書類と請求必要事項とを含む請求情報を保険会社システムに送信し請求処理を行う請求処理部を有する。
【選択図】図１
【特許請求の範囲】
【請求項1】
保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付部と、
前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得部と、
前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定部と、
前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信部と、
前記外部から前記必要書類を受信する書類受信部と、
前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理部と、
を有することを特徴とする保険金請求代行装置。
前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得部と、
前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定部と、
前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信部と、
前記外部から前記必要書類を受信する書類受信部と、
前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理部と、
を有することを特徴とする保険金請求代行装置。
【請求項2】
前記必要書類特定部は、前記請求必要事項及び前記契約内容に基づいて、前記請求に係る保険金の支払金額を算出し、当該算出した前記支払金額に基づいて、医療機関によって発行される書類である診断書を必要書類として特定することを特徴とする請求項１に記載の保険金請求代行装置。
【請求項3】
前記必要書類特定部は、前記請求に係る保険会社によって提供された判定基準に基づいて、前記必要書類を特定することを特徴とする請求項１又は２に記載の保険金請求代行装置。
【請求項4】
前記必要書類特定部は、前記請求必要事項の所定の項目と、前記契約内容の前記所定の項目に対応する部分との比較に基づいて、必要書類を特定することを特徴とする請求項１乃至３のいずれか１項に記載の保険金請求代行装置。
【請求項5】
前記書類要求送信部は、前記必要書類に医療機関によって発行されるべき診断書が含まれる場合に、前記診断書の送信を求める要求を前記医療機関が保有する端末に送信することを特徴とする請求項１乃至４のいずれか１項に記載の保険金請求代行装置。
【請求項6】
前記書類要求送信部は、前記必要書類に前記利用者が準備すべき書類が含まれる場合に、前記利用者が準備すべき書類の送信を求める要求を前記利用者端末に送信することを特徴とする請求項１乃至５のいずれか１項に記載の保険金請求代行装置。
【請求項7】
前記請求処理部は、前記請求必要事項に基づいて保険金請求書を作成して前記必要書類とともに送信することを特徴とする請求項１乃至６のいずれか１項に記載の保険金請求代行装置。
【請求項8】
前記書類要求送信部は、前記利用者の複数の前記請求処理のための複数の処理が同時並行で進行している場合において、前記複数の処理において特定された複数の必要書類について、前記送信を求める要求を集約して送信することを特徴とする請求項１乃至７のいずれか１項に記載の保険金請求代行装置。
【請求項9】
保険金請求代行装置は、前記契約内容取得部、前記必要書類特定部、及び前記請求処理部を各々が含む互いに独立した処理領域である複数のサービス提供領域を複数の保険会社の各々について有していることを特徴とする請求項１乃至７のいずれか１項に記載の保険金請求代行装置。
【請求項10】
前記サービス提供領域の各々は、前記書類要求送信部及び前記書類受信部を有することを特徴とする請求項８に記載の保険金請求代行装置。
【請求項11】
前記書類要求送信部は、前記利用者の複数の前記請求処理のための複数の処理が同時並行で進行している場合において、前記複数のサービス提供領域によって特定された複数の必要書類のうち、前記送信を求める要求の送信先が共通する複数の必要書類について、前記送信を求める要求を集約して送信することを特徴とする請求項９又は１０に記載の保険金請求代行装置。
【請求項12】
保険金請求代行サービスの利用者が使用する利用者端末と、保険会社が保有する保険会社システムと、医療機関が保有する医療機関端末と、前記利用者端末、前記保険会社システム及び前記医療機関端末との間で通信を行って保険金請求代行サービスを行う保険金請求代行装置と、を含む保険金請求代行システムであって、
前記保険金請求代行装置は、
保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付部と、
前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得部と、
前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定部と、
前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信部と、
前記外部から前記必要書類を受信する書類受信部と、
前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理部と、
を有することを特徴とする保険金請求代行システム。
前記保険金請求代行装置は、
保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付部と、
前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得部と、
前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定部と、
前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信部と、
前記外部から前記必要書類を受信する書類受信部と、
前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理部と、
を有することを特徴とする保険金請求代行システム。
【請求項13】
保険金請求代行装置によって行われる保険金請求代行方法であって、
受付部が、保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付ステップと、
契約内容取得部が、前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得ステップと、
必要書類特定部が、前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定ステップと、
書類要求送信部が、前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信ステップと、
書類受信部が、前記外部から前記必要書類を受信する書類受信ステップと、
請求処理部が、前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理ステップと、
を含むことを特徴とする保険金請求代行方法。
受付部が、保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付ステップと、
契約内容取得部が、前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得ステップと、
必要書類特定部が、前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定ステップと、
書類要求送信部が、前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信ステップと、
書類受信部が、前記外部から前記必要書類を受信する書類受信ステップと、
請求処理部が、前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理ステップと、
を含むことを特徴とする保険金請求代行方法。
【請求項14】
コンピュータを備える保険金請求代行装置によって実行される保険金請求代行プログラムであって、前記コンピュータに、
保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付ステップと、
前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得ステップと、
前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定ステップと、
前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信ステップと、
前記外部から前記必要書類を受信する書類受信ステップと、
前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理ステップと、
を実行させることを特徴とする保険金請求代行プログラム。
保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付ステップと、
前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得ステップと、
前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定ステップと、
前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信ステップと、
前記外部から前記必要書類を受信する書類受信ステップと、
前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理ステップと、
を実行させることを特徴とする保険金請求代行プログラム。
【請求項15】
請求項１４に記載の保険金請求代行プログラムを格納したことを特徴とする、コンピュータが読取可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、保険金請求代行装置、保険金請求代行システム、保険金請求代行方法、保険金請求代行プログラム及び記録媒体に関する。
【背景技術】
【0002】
被保険者に代わって、保険会社に対する保険金の請求に関する手続きを行うサービスを提供するための技術が知られている。
【0003】
例えば、引用文献１には、診断書の要否にかかわらず、病院に対して診断書の発行を要求するとともに診断書を送付するように指示する生命保険の処理システムが開示されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２００２－５６１８８
【発明の概要】
【発明が解決しようとする課題】
【0005】
実際の保険金の請求においては、契約内容や請求内容によって必要な書類が異なり、どの書類が必要であるかがユーザにとってわかり難いことも多い。そのため、書類の不足によって、ユーザが何度も書類を準備又は送付しなければならない場合もあり、保険金の請求に係る手続きが煩雑であることが課題となっていた。また、ユーザや医療機関が不要な書類を準備しなければならなくなる可能性もあり、保険金の請求に係る手続きの効率がよくないこと等が課題となっていた。
【0006】
本発明は、上述の点に鑑みてなされたものであり、保険金の請求に係るユーザや医療機関等が負担する労力を軽減して保険金請求手続を効率化し、円滑な保険金請求を実現可能にする保険金請求代行装置、保険金請求代行システム、保険金請求代行方法、保険金請求代行プログラム及び記録媒体を提供することを目的とする。
【課題を解決するための手段】
【0007】
本発明の保険金請求代行装置は、保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付部と、前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得部と、前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定部と、前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信部と、前記外部から前記必要書類を受信する書類受信部と、前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理部と、を有することを特徴とする。
【0008】
本発明の保険金請求代行システムは、保険金請求代行サービスの利用者が使用する利用者端末と、保険会社が保有する保険会社システムと、医療機関が保有する医療機関端末と、前記利用者端末、前記保険会社システム及び前記医療機関端末との間で通信を行って保険金請求代行サービスを行う保険金請求代行装置と、を含む保険金請求代行システムであって、前記保険金請求代行装置は、保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付部と、前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得部と、前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定部と、前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信部と、前記外部から前記必要書類を受信する書類受信部と、前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理部と、を有することを特徴とする。
【0009】
本発明の保険金請求代行方法は、保険金請求代行装置によって行われる保険金請求代行方法であって、受付部が、保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付ステップと、契約内容取得部が、前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得ステップと、必要書類特定部が、前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定ステップと、書類要求送信部が、前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信ステップと、書類受信部が、前記外部から前記必要書類を受信する書類受信ステップと、請求処理部が、前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理ステップと、を含むことを特徴とする。
【0010】
本発明の保険金請求代行プログラムは、コンピュータを備える保険金請求代行装置によって実行される保険金請求代行プログラムであって、前記コンピュータに、保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて前記請求に必要な事項を示す請求必要事項を取得する受付ステップと、前記請求必要事項に基づいて、前記請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って前記請求に係る契約内容を取得する契約内容取得ステップと、前記請求必要事項及び前記契約内容に基づいて、前記請求に当たり前記保険会社に提出する必要のある書類を必要書類として特定する必要書類特定ステップと、前記必要書類特定部によって１以上の必要書類が特定された際に、前記１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信ステップと、前記外部から前記必要書類を受信する書類受信ステップと、前記必要書類とともに前記請求必要事項を含む請求情報を前記保険会社システムに送信して請求処理を行う請求処理ステップと、を実行させることを特徴とする。
【図面の簡単な説明】
【0011】
【図1】実施例に係る保険金請求代行システム１０の構成を示す図である。
【図2】実施例に係る保険金請求代行装置の構成を示す機能ブロック図である。
【図3】実施例に係る利用者情報を示すテーブルの一例を示す図である。
【図4】実施例に係る請求必要事項の一例を示す図である。
【図5】実施例に係る取引管理情報を示すテーブルの一例を示す図である。
【図6】実施例に係る保険会社システムの構成を示す機能ブロック図である。
【図7】実施例に係る顧客契約情報を示すテーブルの一例を示す図である。
【図8】実施例に係る保険金請求代行サーバ装置によって実行されるルーチンの一例を示すフローチャートである。
【図9】実施例に係る保険金請求代行サーバ装置によって実行されるルーチンの一例を示すフローチャートである。
【図10】実施例に係る保険金請求代行サーバ装置によって実行されるサブルーチンの一例を示すフローチャートである。
【図11】実施例に係る保険金請求代行サーバ装置によって実行されるルーチンの一例を示すフローチャートである。
【図12】実施例に係る保険金請求代行サーバ装置によって実行されるルーチンの一例を示すフローチャートである。
【図13】実施例に係る保険金請求代行サーバ装置によって実行されるルーチンの一例を示すフローチャートである。
【図14】実施例に係る保険金請求代行装置の構成を示す機能ブロック図である。
【発明を実施するための形態】
【0012】
以下に本発明の実施例について添付の図面を参照しつつ詳細に説明する。なお、以下の説明及び添付図面においては、実質的に同一又は等価な部分には同一の参照符号を付している。
【実施例0013】
図１は、本発明の実施例に係る保険金請求代行システム１０の構成を示す図である。図１に示すように、保険金請求代行システム１０は、保険金請求代行装置としての保険金請求代行サーバ１１、利用者端末１３（１）～（ｍ）（ｍは正の整数）、保険会社システム１５（１）～（ｎ）（ｎは正の整数）、及び医療機関端末１７（１）～（ｐ）（ｐは正の整数）がネットワークＮＷを介して通信可能に接続されて構築されているシステムである。
【0014】
保険金請求代行システム１０は、保険金請求代行サーバ１１が、保険会社や医療機関と連携して、被保険者である保険金請求代行サービスの利用者に代わって、当該利用者が加入している特定の保険会社に対する保険金の請求を実施する。
【0015】
ネットワークＮＷは、Ｗｉ－Ｆｉ（登録商標）等の無線通信及び有線通信を含むインターネット通信により構築され得る。また、保険金請求代行システム１０における各装置間の通信には、ＴＣＰ／ＩＰ等の通信プロトコルが用いられる。
【0016】
保険金請求代行サーバ１１は、利用者端末１３（１）～（ｍ）、保険会社システム１５（１）～（ｎ）、及び医療機関端末１７（１）～（ｐ）との間で通信を行って、利用者による保険金の請求を代行するための処理を行うサーバ装置である。
【0017】
本実施例において、例えば、保険金請求代行サーバ１１は、ネットワークＮＷ上のＷＥＢクラウドサービスとして、保険金の請求を代行する。
【0018】
利用者端末１３（１）～（ｍ）は、保険金請求代行サービスの利用者が使用する１又は複数の端末装置である。図１中、利用者端末１３（１）～（ｍ）に含まれるｍ個の端末装置の各々が、ネットワークＮＷに接続されている様子を示している。利用者端末１３（１）～（ｍ）に含まれる端末の数ｍは、例えば利用者の人数である。
【0019】
利用者端末１３（１）～（ｍ）の各々は、利用者による入力操作を受付可能な入力部と、各種入力画面又は利用者に向けたメッセージを含む画面等の画像を表示可能な表示部と、保険金請求代行サーバ１１との間で通信を行う通信部と、を備えた端末装置である。
【0020】
本実施例において、例えば、利用者端末１３（１）～（ｍ）の各々は、利用者が所持するスマートフォンである。利用者端末１３（１）～（ｍ）の各々は、スマートフォンに限られず、パーソナルコンピュータ、タブレット、ウェアラブル装置等の他のスマートデバイスを含む端末装置であってもよい。
【0021】
なお、例えば、利用者端末１３（１）～（ｍ）に含まれる端末装置は、利用者の本人確認のための生体認証情報の入力が可能に構成されていてもよい。
【0022】
例えば、利用者は、利用者端末１３（ｘ）（ｘは任意の正の整数）（以下、「単に利用者端末１３」とも称する）を介して保険金請求代行システム１０に氏名等の情報を予め登録しておく。そして、保険金の請求が必要になった際に、保険金請求代行システム１０によるサービスの利用申し込みを行うことで、保険金の請求を保険金請求代行システム１０に依頼し、保険会社に対して保険金請求代行システム１０を介して間接的に保険金の請求を行う。
【0023】
例えば、当該利用者は、保険金の請求を行う際に、利用者端末１３（ｘ）の操作画面からＩＤ、パスワード等の入力によって認証を行い、認証が正しい場合は、サービスメニューにアクセス可能となり、表示画面にサービスメニューが表示される。例えば、利用者が保険金請求メニューを選択すると、保険金請求画面が表示され、保険金の請求に必要な事項を入力可能となる。利用者が請求に必要な事項を入力後、請求ボタンを押下すると、当該請求に必要な事項を示す請求必要事項が保険金請求代行サーバ１１に送信されて、保険金請求代行システム１０における保険金の請求の代行するための処理が開始される。
【0024】
保険会社システム１５（１）～（ｎ）は、保険金請求代行システム１０において契約を結んでいる１又は複数の保険会社が保有し、保険金請求代行システム１０に関する情報処理の実行のために提供するシステムである。保険会社システム１５（１）～（ｎ）の各々は、保険金請求代行サーバ１１が保険会社システム１５（１）～（ｎ）にアクセスして、保険契約内容の照会や利用者に代わって保険金の請求を行うためのＡＰＩ（Application Programming Interface）を提供可能に構成されている。
【0025】
例えば、保険会社システム１５（１）～（ｎ）に含まれるシステムの数ｎは、保険金請求代行システム１０についての契約を結んでいる保険会社（以下、契約保険会社とも称する）の数に対応している。図１では、保険会社システム１５（１）から保険会社システム１５（ｎ）までのｎ個の保険会社システムの各々が、ネットワークＮＷに接続されている様子を示している。
【0026】
保険会社システム１５（１）～（ｎ）の各々は、保険金請求代行サーバ１１からの契約内容の照会要求に応じて、指定された契約の内容を示す情報を保険金請求代行サーバ１１に送信する。また、保険会社システム１５（１）～（ｎ）の各々は、保険金請求代行サーバ１１から保険金の請求に必要な情報及び添付書類を含む保険金の請求を受け付ける。
【0027】
医療機関端末１７（１）～（ｐ）は、保険金請求代行システム１０が提携している医療機関（以下、提携医療機関とも称する）に配備されている１または複数の端末装置である。医療機関端末１７（１）～（ｐ）は、ネットワークＮＷに接続されている。
【0028】
医療機関端末１７（１）～（ｐ）の各々は、医療機関によって発行される書類である診断書兼入院証明書、診断書兼入院・通院証明書、入院証明書、入院・通院証明書、等の診断書類（以下、単に「診断書」とも称する）の作成や送信のために用いられる。
【0029】
本実施例において、例えば、医療機関端末１７（１）～（ｐ）に含まれる端末装置の数ｐは、提携医療機関の数に対応している。図１中、医療機関端末１７（１）から医療機関端末１７（ｐ）までのｐ個の端末装置の各々が、ネットワークＮＷに接続されている様子を示している。なお、１つの提携医療機関に１つの端末があっても良いし、例えば診療科毎または医師毎に複数の医療機関端末１７が存在してもよい。
【0030】
医療機関端末１７（１）～（ｐ）の各々は、操作入力を受付可能な入力部と、診断書の作成依頼があったことを示す画面、診断書の作成及び送信に必要な画面等の画像を表示する表示部と、ネットワークＮＷを介して保険金請求代行サーバ１１との間で通信を行う通信部と、を備えた端末装置である。
【0031】
本実施例において、例えば、医療機関端末１７（１）～（ｐ）の各々は、タブレット型端末である。医療機関端末１７（１）～（ｐ）に含まれる端末装置は、タブレット型端末に限られず、パーソナルコンピュータ、スマートフォン等の他の端末装置であってもよい。
【0032】
医療機関端末１７（１）～（ｐ）の各々は、保険金請求代行サーバ１１からの診断書の作成要求を受信し、当該要求の送信元に、医療機関において作成された診断書を送信する。例えば、医療機関端末１７（１）～（ｐ）の各々が診断書の作成要求を受信すると、診断書作成依頼がある旨を示す画面が表示される。その後、例えば、医療機関端末１７が診断書作成依頼の１つを指定する操作を受け付けると、医療機関端末１７の表示画面に診断書データ入力画面が表示される。当該入力画面において担当の医師が診断書データを入力し、送信ボタンを押下すると、作成された診断書が医療機関端末１７から保険金請求代行サーバ１１に送信される。
【0033】
保険金請求代行サーバ１１は、特定の保険会社に対する保険金の請求に必要な事項を示す情報を利用者端末１３（ｘ）から受信すると、当該請求に当たり当該特定の保険会社に提出する必要がある書類を必要書類として特定する。
【0034】
保険金請求代行サーバ１１は、１以上の必要書類を特定した場合に、当該１以上の必要書類の各々についての送信を求める要求を外部に送信する。
【0035】
例えば、保険金請求代行サーバ１１は、診断書を必要書類として特定した場合には、診断書を発行する医療機関の医療機関端末１７（ｘ）（ｘは任意の正の整数）に診断書の作成及び送信を要求する旨の情報を送信する。
【0036】
例えば、保険金請求代行サーバ１１は、利用者が準備すべき書類を必要書類として特定した場合には、当該利用者が準備すべき書類の送信を要求する旨の情報を利用者端末１３（ｘ）に向けて送信する。保険金請求代行サーバ１１は、医療機関端末１７（ｘ）又は利用者端末１３（ｘ）から要求した必要書類を受信すると、保険金の請求に必要な請求情報とともに必要書類を特定の保険会社の保険会社システム１５（ｘ）に送信することによって、利用者に代わって、当該特定の保険会社に対する保険金の請求を行う。
【0037】
【0038】
保険金請求代行サーバ１１は、制御部（図示せず）によって制御がなされる。制御部は、ＣＰＵ（Central Processing Unit）（図示せず）、ＲＯＭ（Read Only Memory）（図示せず）、ＲＡＭ（Random Access Memory）（図示せず）等により構成され、コンピュータとして機能する。そして、ＣＰＵが、ＲＯＭに記憶されるかまたは外部にある各種プログラムを読み出し実行することにより、各種機能を実現する。
【0039】
また、保険金請求代行サーバ１１は、記憶部（図示せず）を備えている。記憶部は、制御部の処理に必要なデータ及び処理において発生するデータを適宜記憶するハードディスク、フラッシュメモリ、ＳＳＤ（Solid State Drive）、ＲＡＭ（Random Access Memory）等の記憶装置である。記憶部は、保険金請求代行サーバ１１が保険金の請求を受け付けたり、保険金の請求に必要な情報を送受信したりするためのソフトウェア等の制御部が実行する各種プログラムを記憶する。また、記憶部は、保険金の請求のための各種プログラムの実行に必要な各種データベース（ＤＢ）を記憶する。
【0040】
通信部２１は、制御部の指示に従って外部とのデータの送受信等の通信を行うためのＮＩＣ（Network Interface Card）等のネットワークアダプタである。通信部２１は、例えば、保険金請求代行システム１０のサービスにおいて必要となる、保険金請求代行サーバ１１と、外部機器である利用者端末１３（１）～（ｍ）、保険会社システム１５（１）～（ｎ）、及び医療機関端末１７（１）～（ｐ）との間の通信を行う。
【0041】
例えば、通信部２１は、利用者端末１３（ｘ）から送信された、保険金請求に関する情報を受信する。また、通信部２１は、保険会社システム１５（ｘ）（ｘは任意の正の整数）から利用者の契約内容を示す情報を受信し、保険会社システム１５（ｘ）に保険金の請求に必要な情報を送信する。また、通信部２１は、医療機関端末１７（ｘ）に診断書の作成依頼を示す情報を送信し、医療機関端末１７（ｘ）から診断書を受信する。
【0042】
利用者情報データベース（以下、利用者情報ＤＢとも称する）２３は、保険金請求代行システム１０を利用する利用者に関する情報を記憶するデータベースである。利用者情報ＤＢ２３は、利用者を特定するための氏名や連絡先等の個人情報及びパスワード等の認証情報を記憶している。
【0043】
図３は、利用者情報ＤＢ２３に記憶されている利用者情報の一例をテーブルＴＢ１として示す図である。図３に示すように、利用者情報ＤＢ２３には、利用者毎に付された利用者ＩＤに、保険金請求代行システム１０にアクセスする際の認証のためのパスワード、利用者を特定する氏名、性別、生年月日、住所及び電話番号が対応付けられて記憶されている。
【0044】
また、図３に示すように、保険金請求代行システム１０によるサービスの利用料を利用者が支払う際のクレジットカード情報等の情報が、当該利用者の利用者ＩＤにさらに対応付けられていてもよい。
【0045】
例えば、利用者は、保険金請求代行システム１０を初めて利用する際に、テーブルＴＢ１に例示したような、氏名等の利用者の個人情報及び認証に必要なパスワード等の情報を利用者端末１３に表示された入力画面に入力する。例えば、その後利用者が送信ボタンを押下すると、入力された情報が保険金請求代行サーバ１１に送信される。
【0046】
保険金請求代行サーバ１１では、当該利用者端末１３から送信された情報が通信部２１を介して受信され、制御部によってユーザＩＤが付されて利用者情報ＤＢ２３に記憶されることでユーザ登録がなされる。
【0047】
なお、利用者情報ＤＢ２３は、パスワードに加えて、又はパスワードの代わりに、指紋や静脈等の生体情報を認証のための情報として記憶していてもよい。
【0048】
認証部２５は、利用者が保険金請求代行システム１０を利用して保険金の請求を行う際に、当該利用者の本人確認のための認証を行う機能部である。認証部２５は、予め登録されて利用者情報ＤＢ２３に記憶されている利用者情報に基づいて、利用者の認証を行う。
【0049】
例えば、認証部２５は、利用者端末１３（ｘ）を介して利用者のユーザＩＤ及びパスワードが入力された場合に、利用者情報ＤＢ２３に記憶されているＩＤ及びパスワードと照合して、一致した場合に認証が正しくなされたと判定し、一致しない場合には、認証不可と判定する。例えば認証部２５は、通信部２１を介して利用者端末１３（ｘ）に認証結果を通知する。
【0050】
例えば、認証部２５は、利用者本人の顔画像と、運転免許証やパスポートなどの顔写真入りの身分証明書類を用いたｅＫＹＣ（electric Know Your Customer）サービスと連携してより厳格な本人確認を行ってもよい。また、認証部２５は、指紋や静脈等の生体情報を用いた認証を行ってもよい。
【0051】
共通処理部２７は、利用者からの保険金の請求を受け付ける受付処理を行う受付部として機能する機能部である。当該受付処理において、共通処理部２７は、利用者が利用者端末１３（ｘ）を介して入力及び送信した保険金の請求に必要な事項を示す請求必要事項を、通信部２１を介して受信する。
【0052】
図４は、利用者端末１３（ｘ）から保険金請求代行サーバ１１に送信される請求必要事項の一例を示す図である。図４に示すように、請求必要事項には、利用者ＩＤ、氏名、住所、電話番号等の個人情報に加えて、保険会社名、保険証券番号、請求事由、医療機関情報及び保険金支払先等の保険金の請求に関する情報が含まれている。また、請求必要事項には、交通事故に関連する場合に必要となる運転免許情報等の、請求事由によって要否が異なる項目が含まれていてもよい。
【0053】
請求必要事項は、図４に示した以外にも、例えば、治療内容、入院日数等の項目が含まれていてもよい。例えば、保険金請求代行システム１０が契約している複数の保険会社が規定する保険金請求書に設けられている項目の全てが請求必要事項に含まれていてもよい。
【0054】
共通処理部２７は、受付処理において、請求必要事項を受信すると、保険金の請求の代行の処理を行うにあたって必要な情報が全て揃っているか否かを判定する。当該必要な情報は、例えば、氏名、保険会社名及び保険証券番号であり、保険金請求代行サーバ１１が保険会社と連携して保険金の請求の代行をするために必須の項目である。
【0055】
また、共通処理部２７は、上記の受付処理に加えて、同じ送信先への複数の送信又は同じ送信先への重複する内容の送信等の通信をまとめて行う機能を有する。ここで、保険金請求代行サーバ１１では、保険金の請求を代行するにあたり、個人情報の保護及び保険会社の各々の顧客情報の取扱の観点から、所定の処理については保険会社毎に別々の処理領域によって行われる。当該保険会社毎の処理領域の各々は、互いにアクセスできないように設計されている。
【0056】
共通処理部２７は、当該保険会社毎の処理のため、請求必要事項に含まれる保険会社を特定する情報に基づいて、保険会社毎の処理領域に請求必要事項を送信する。共通処理部２７は、当該保険会社毎の処理において、例えば利用者に通知される内容が重複する場合には、重複する内容の通知をまとめて１回で行う。
【0057】
これによって、例えば、同じ書類を要求する旨の情報が同じ利用者に対して何度も送信されて、当該利用者が何度も書類を送信することを回避できる。従って利用者の負担を軽減できる
サービス提供領域２９（１）～２９（ｎ）（ｎは正の整数）は、複数の保険会社の各々について設けられた複数の処理領域である。すなわち、サービス提供領域２９（ｘ）（ｘは任意の正の整数）（以下、単に「サービス提供領域２９」とも称する）は、契約保険会社の数ｎだけ設けられている。サービス提供領域２９（１）～２９（ｎ）の各々は、保険会社システム１５（１）～１５（ｎ）の各々に対応する。
サービス提供領域２９（１）～２９（ｎ）（ｎは正の整数）は、複数の保険会社の各々について設けられた複数の処理領域である。すなわち、サービス提供領域２９（ｘ）（ｘは任意の正の整数）（以下、単に「サービス提供領域２９」とも称する）は、契約保険会社の数ｎだけ設けられている。サービス提供領域２９（１）～２９（ｎ）の各々は、保険会社システム１５（１）～１５（ｎ）の各々に対応する。
【0058】
サービス提供領域２９（１）～２９（ｎ）の各々は、個人情報の保護及び保険会社の各々の顧客情報の取扱の観点から、互いに独立して、すなわち互いにアクセスできないように完全に分離されている。例えば、サービス提供領域２９（１）～２９（ｎ）は、１のサービス提供領域２９における処理に用いられる情報及び当該処理によって作成された情報に対して他のサービス提供領域２９がアクセスすることは不可能であるように設計されている。従って、保険会社間で個人情報の授受や企業内の機密情報等の情報の授受が不可能となり、高いセキュリティが実現される。
【0059】
例えば、保険金請求代行システム１０において、保険の請求に関わる処理に用いる情報及び当該処理によって作成された情報は、金融情報システムセンター(FISC：The Center for Financial Industry Information Systems)によるガイドラインに従って取り扱われる。また、保険金請求代行システム１０においては、例えば、サービス提供領域２９の設計はFISCによるガイドラインに従って設計されている。
【0060】
サービス提供領域２９（１）～２９（ｎ）の各々は、契約内容取得部３１、精査処理部３３、必要書類特定部３５、必要書類要求部３７、請求処理部３９、取引管理データベース（以下、取引管理ＤＢと称する）４１、及び判定基準データベース（以下、判定基準ＤＢと称する）４３を備えている。
【0061】
例えば共通処理部２７は、請求必要事項に記載された保険会社名に対応する保険会社、すなわち当該請求必要事項を入力した利用者の請求に係る請求先となる保険会社に対応するサービス提供領域２９（ｘ）に、当該請求必要事項を送信する。
【0062】
契約内容取得部３１は、請求必要事項を共通処理部２７から受信すると、当該請求必要事項に基づいて、当該請求に係る請求先の保険会社が保有する保険会社システム１５（ｘ）との間で通信を行って、当該請求に係る契約内容、すなわち当該請求の根拠となる契約内容を取得する。例えば、契約内容取得部３１は、契約内容の送信を求める要求を示す情報を当該保険会社システム１５（ｘ）に送信し、当該要求に対する回答として、要求した契約内容を示す情報を保険会社システム１５（ｘ）から受信する。
【0063】
例えば、当該契約内容の要求を示す情報には、当該請求必要事項に含まれる保険証券番号が含まれる。例えば、保険会社システム１５（ｘ）は、当該保険証券番号に対応する契約内容を示す情報を当該保険会社システム１５（ｘ）に宛てて送信する。
【0064】
精査処理部３３は、契約内容に基づいて、請求必要事項の正当性を判定する。例えば、精査処理部３３は、請求必要事項に含まれる保険証券番号に基づいて、請求必要事項と契約内容とを比較して、一致すべき項目の一致度を判定することで、請求必要事項に記載されている契約の存在を確認する。例えば、精査処理部３３は、請求必要事項における氏名と、契約内容における契約者名との比較によって、一致度を判定する。
【0065】
必要書類特定部３５は、精査処理部３３による請求必要事項の精査後、請求必要事項及び契約内容に基づいて、当該保険金の請求に当たり、特定の保険会社に提出する必要のある書類を必要書類として特定する。
【0066】
例えば、必要書類特定部３５は、請求必要事項及び契約内容に基づいて、当該請求に係る保険金の支払金額を算出し、当該算出した支払金額に基づいて、診断書の要否を判定する。例えば、必要書類特定部３５は、保険金の支払金額が所定の金額以上である場合に、診断書を必要書類として特定する。また、例えば、必要書類特定部３５は、保険金の支払金額が所定の金額以下である場合には、診断書は不要と判定する。例えば必要書類特定部３５は、診断書は不要と判定した場合に医療機関の領収書のコピーを必要書類として特定する。
【0067】
例えば、必要書類の送信を求める要求の送信先（以下、「要求先とも称する」）は、必要書類の属性に応じて必要書類毎に予め定められている。例えば、必要書類の各々に対して要求先が予め対応付けられて、例えば判定基準ＤＢ４３に記憶されていてもよい。
【0068】
例えば、診断書については利用者が治療を受けた医療機関の医療機関端末１７が要求先として定められる。当該医療機関端末１７は、請求毎の請求必要事項に基づいて特定される。
【0069】
例えば、利用者が準備すべき書類の各々については、利用者端末１３が要求先として定められる。なお、例えば、利用者が準備すべき書類の一部について、その書類を発行する機関が要求先となってもよい。例えば、必要書類が戸籍関係の書類である場合、必要書類を発行する発行機関である国又は地方公共団体が保有する端末装置が要求先として定められていてもよい。例えば、請求事由が事故であって事故に関連する書類が必要書類である場合、警察署又は自動車安全運転センターが保有する端末装置が必要書類の要求先として定められてもよい。特に、必要書類が交通事故証明書である場合には、自動車安全運転センターが保有する端末装置が要求先として定められてもよい。
【0070】
例えば、必要書類特定部３５は、請求必要事項のうち契約内容に係る部分と、契約内容における当該部分に対応する項目との比較に基づいて、必要書類を特定する。
【0071】
例えば、利用者が保険契約後に改姓した場合、契約内容における契約者名と、請求必要事項における氏名とを比較すると、姓のみが異なる。この場合、戸籍抄本等の書類が必要書類として特定される。
【0072】
また、例えば、必要書類特定部３５は、契約内容における保障内容と、請求必要事項における請求事由との比較に基づいて、利用者が準備すべき書類を判定してもよい。例えば、請求事由が交通事故に関する理由であり、保障内容に交通事故に関する保障が含まれていれば、保障の対象であるため、交通事故証明書を必要書類として特定する。
【0073】
このように、必要書類は必要書類特定部３５によって特定されるので、必要書類が何であるかについて利用者が判断する必要は無く、必要書類が何であるかがわかり難く、不足した書類を何度も追加して提出するような状況を回避できる。よって、利用者の負担が軽減される。
【0074】
必要書類要求部３７は、必要書類特定部３５によって特定された必要書類の各々についての送信を求める要求を外部に送信する書類要求送信ステップを実行する書類要求送信部として機能する。例えば、必要書類要求部３７は、診断書が必要書類として特定されると、診断書の送信を求める要求を医療機関端末１７に送信する。
【0075】
例えば、医療機関端末１７（ｘ）が、診断書の送信を求める要求を受信すると、医療機関の医師が、保険会社毎の診断書を作成して当該要求の送信元であるサービス提供領域２９（ｘ）を宛先として診断書を送信する。
【0076】
上記したように、必要書類要求部３７は、保険会社毎に別々に設けられているので、例えばファイル形式等の当該診断書の形式が、保険会社毎に異なる場合にも対応可能である。例えば、保険会社が規定する形式に適合した診断書の形式を示す情報を、要求と共に送信し、当該形式の診断書を作成する要求を行う。例えば、サービス提供領域２９（１）～（ｎ）の各々に、保険会社毎の診断書の形式が予め記憶されていてもよい。
【0077】
また、必要書類要求部３７は、必要書類に利用者が準備すべき書類が含まれる場合には、必要書類の送信を求める要求を利用者端末１３に送信する。
【0078】
また、例えば、必要書類要求部３７は、必要書類の送信を求める要求を共通処理部２７に送信してもよい。
【0079】
なお、共通処理部２７は、１のユーザから複数の請求が同時並行でなされている場合に、異なる請求処理において要求先が同じ必要書類を集約して必要書類の要求を一度にまとめて行うことができる。
【0080】
例えば、利用者が複数の保険会社に保険金を請求する場合において、複数の保険会社間で必要書類が重複する場合、すなわち複数のサービス提供領域２９（ｘ）が同じ書類を必要書類として特定する場合が考えられる。このような場合、共通処理部２７は、請求処理毎に必要書類の要求を送信することはせず、サービス提供領域２９からの必要書類の要求を示す情報を集約して、当該必要書類の要求先、例えば利用者端末１３に当該集約された情報を１回送信することによって複数回の要求を要求先に送信することを防止することができる。また、同じ書類の場合に限られず、複数の保険会社間で必要書類が異なる場合であっても、複数の必要書類の要求を示す情報を集約して１回の送信で利用者端末１３に送信することができる。従って、請求毎に必要書類の要求が複数回利用者に送信されることがなく、利用者の負担を軽減することが可能となる。
【0081】
また、必要書類要求部３７は、要求した必要書類を当該必要書類の要求先から受信する書類受信ステップを実行する書類受信部として機能する。
【0082】
例えば、上記したように、複数の保険会社の各々に対する請求において提出する必要がある書類について、共通処理部２７から複数請求分の要求をまとめて送信した場合、要求先からの必要書類を共通処理部２７がまとめて受信し、要求された必要書類をサービス提供領域（ｘ）の各々に供給してもよい。
【0083】
請求処理部３９は、請求必要事項を含む請求情報を必要書類要求部３７の要求の結果受信した必要書類とともに、保険会社システム１５（ｘ）に送信することで、保険金の請求処理を行う。
【0084】
例えば、請求処理部３９は、保険金の請求に必要な請求情報を、請求必要事項及び契約内容に基づいて生成する。例えば、請求処理部３９は、保険会社毎に定められた形式の情報又は共通の形式の情報を請求情報として生成する。例えば、請求処理部３９は、保険会社毎に定められた形式の保険金請求書を作成して請求情報とし、必要書類とともに当該請求情報を、保険会社システム１５（ｘ）に送信してもよい。
【0085】
このように、保険会社毎のサービス提供領域２９（ｘ）の請求処理部３９において、保険会社毎に定められた形式の請求情報を生成することができる。例えば、利用者が、保険会社毎の書式に対応した保険金請求書を作成することが不要となり、利用者の負担が軽減される。
【0086】
また、請求処理部３９は、保険会社による審査の結果を受信する。また、請求処理部３９は、保険金の支払い完了の通知を保険会社から受信してもよい。
【0087】
取引管理ＤＢ４１は、保険会社毎に取引状態を管理するためのデータベースである。保険金請求代行サーバ１１において、特定保険会社に対する保険金の請求が受け付けられると、当該特定の保険会社に対応するサービス提供領域２９（ｘ）の取引管理ＤＢに記録され、手続の進行に伴って、進捗状況を示す情報が対応付けられて更新される。
【0088】
図５は、取引管理ＤＢ４１に記憶されている取引管理情報の一例をテーブルＴＢ２として示す図である。図５に示すように、請求毎に「取引Ｎｏ．」が付され、「利用者ＩＤ」、「保険証券Ｎｏ．」、「請求事由」等の請求に必要な情報が記載されている。また、進行状況を示す「診断書作成依頼中」、「請求審査依頼中」等の請求状況が取引Ｎｏ．毎に対応付けられて記載されている。
【0089】
例えば、請求状況を示す情報は、利用者端末１３（ｘ）の表示画面に表示可能であってもよい。例えば、利用者は、自身が行った保険金の請求について、手続きの進行状況を利用者端末１３（ｘ）を介して確認することができる。
【0090】
例えば、当該「請求状況」は、保険会社による審査の結果、支払いの対象と判断され、保険会社から利用者への保険金の支払いが完了すると「支払い完了」の請求状況に更新されて、例えば一定期間保管される。
【0091】
判定基準ＤＢ４３は、保険会社毎の必要書類の判断基準が記憶されているデータベースである。例えば、判定基準ＤＢ４３には、保険種別や治療内容等の条件毎に、必要書類を特定するための判定基準が記憶されている。
【0092】
例えば、診断書の要否については、保険種別に加えて、保険金の支払額による判定基準が、判定基準ＤＢ４３に記憶されている。例えば、利用者が準備すべき書類の要否の判定基準について、保険会社が定める条件が、判定基準ＤＢ４３に記憶されている。
【0093】
図６～図７を参照しつつ、契約保険会社の各々が保有する保険会社システム１５（ｘ）の各部の構成及び機能並びにデータベースの内容の一例を以下に説明する。図６は、保険会社システム１５（ｘ）の構成を示す機能ブロック図である。
【0094】
保険会社システム１５（ｘ）は、制御部（図示せず）によって制御がなされる。制御部は、ＣＰＵ（Central Processing Unit）（図示せず）、ＲＯＭ（Read Only Memory）（図示せず）、ＲＡＭ（Random Access Memory）（図示せず）等により構成され、コンピュータとして機能する。そして、ＣＰＵが、ＲＯＭに記憶されるかまたは外部にある各種プログラムを読み出し実行することにより、各種機能を実現する。
【0095】
また、保険会社システム１５（ｘ）は、記憶部（図示せず）を備えている。記憶部は、制御部の処理に必要なデータ及び処理において発生するデータを適宜記憶するハードディスク、フラッシュメモリ、ＳＳＤ（Solid State Drive）、ＲＡＭ（Random Access Memory）等の記憶装置である。記憶部は、保険会社システム１５が保険金の請求を受け付けたり、審査結果を送信したりするためのソフトウェア等の制御部が実行する各種プログラムを記憶する。また、記憶部は、顧客との契約内容を記録したデータベース（ＤＢ）を記憶する。
【0096】
通信部５１は、制御部の指示に従って外部とのデータの送受信等の通信を行うためのＮＩＣ（Network Interface Card）等のネットワークアダプタである。通信部５１は、例えば、保険金請求代行サーバ１１と間で契約情報の送信や保険金を請求する旨の情報の受信等の通信を行う。
【0097】
顧客契約情報データベース（顧客契約情報ＤＢ）５３は、保険会社システム１５（ｘ）が保有する保険会社が保険契約を行っている顧客の個人情報と、当該顧客の保険契約の内容とを関連付けて記憶するデータベースである。
【0098】
図７は、顧客契約情報ＤＢ５３に記憶された顧客契約情報の一例をテーブルＴＢ３として示す図である。図７に示すように、テーブルＴＢ３において、顧客ＩＤ毎に、保険種別、保険証券番号（保険証券Ｎｏ．）、契約日、契約期間、保障内容等の項目が対応付けられている。例えば、図７に示す他に、顧客契約情報には、契約者の氏名、受取人等の情報が含まれていてもよい。
【0099】
認証部５５は、保険会社システム１５（ｘ）の外部からのアクセス可否について認証を行うための機能部である。例えば、認証部５５は、認証が正しく行われた場合には、保険金請求代行サーバ１１からのアクセスを許可するように設定されている。
【0100】
契約内容照会受付部５７は、保険金請求代行サーバ１１からの保険契約内容の要求を受け付けて回答する機能部である。例えば、契約内容照会受付部５７は、保険金請求代行サーバ１１のサービス提供領域２９（ｘ）の契約内容取得部３１から契約内容の要求を示す情報を受信すると、当該契約内容の要求に対する回答を、当該要求の送信元であるサービス提供領域２９（ｘ）に宛てて送信する。
【0101】
例えば、契約内容照会受付部５７は、契約内容の要求に含まれる保険証券番号に対応する契約内容を含む情報を、当該契約内容の要求の送信元に宛てて送信することで、当該契約内容の要求に対する回答を行う。
【0102】
保険金請求受付／回答部５９は、保険金請求代行サーバ１１からの保険金の請求を受け付けて、審査結果を回答する機能部である。例えば、保険金請求受付／回答部５９は、保険金請求代行サーバ１１のサービス提供領域２９（ｘ）の請求処理部３９から必要書類とともに送信された請求情報を受信すると、保険金の請求を受け付ける。
【0103】
また、例えば、保険金請求受付／回答部５９は、当該保険金の請求に係る請求先である保険会社における審査の結果をサービス提供領域２９（ｘ）の請求処理部３９に宛てて送信する。
【0104】
以上、説明したように、保険金請求代行システム１０における保険金請求代行サーバ１１は、保険金請求代行サービスの利用者が使用する利用者端末からの特定の保険会社に対する保険金の請求を受け付けて当該請求に必要な事項を示す請求必要事項を取得する受付部と、当該請求必要事項に基づいて、当該請求に係る請求先の保険会社が保有する保険会社システムとの間で通信を行って当該請求に係る契約内容を取得する契約内容取得部と、を有する。
【0105】
さらに、保険金請求代行サーバ１１は、当該請求必要事項及び当該契約内容に基づいて、当該請求に当たり保険会社に提出する必要のある書類を必要書類として特定する必要書類特定部と、当該要求書類の送信を求めるに要求を外部に送信する書類要求送信部と、外部から必要書類を受信する書類受信部と、必要書類とともに請求必要事項を含む請求情報を保険会社システムに送信して請求処理を行う請求処理部と、を有する。
【0106】
このような構成により、保険金請求代行サーバ１１を含む保険金請求代行システム１０によれば、請求必要事項及び契約内容に基づいて、特定の保険会社に対する保険金の請求の際の必要書類を予め特定し、必要書類の各々の送信を求める要求を外部に送信して、当該特定された必要書類を受信することができる。そして、必要書類とともに請求に必要な請求情報を、利用者に代わって保険会社システムに送信することで、保険金の請求を代行することができる。
【0107】
保険金請求代行サーバ１１によれば、保険金の請求に当たり必要な書類は必要書類特定部が特定し、必要書類要求部が医療機関や利用者に要求する。従って、必要書類が何であるかについて利用者が判断する必要は無い。また、上述のように必要な書類の要求が当該書類を用意すべきところに通知されるので、書類が不足することを防止し、利用者が不足した書類を何度も追加して提出することや医療機関や利用者が不要な書類を準備することを防止できる。よって、利用者や医療機関の負担が軽減される。
【0108】
また、保険金請求代行サーバ１１を含む保険金請求代行システム１０によれば、保険金の請求に係る処理をすべて電子データの送受信によって進行することができ、ペーパレス化を実現可能である。従って、書類をプリントアウトして、記入、署名又は捺印を行うこと等による利用者の労力が低減され、効率良く保険金の請求の手続きを進行することができる。
【0109】
従って、本実施例の保険金請求代行サーバ１１を含む保険金請求代行システム１０によれば、保険金の請求に係るユーザや医療機関等が負担する労力を軽減して保険金請求手続を効率化し、円滑な保険金請求を実現可能にする保険金請求代行装置、保険金請求代行システム、保険金請求代行方法、保険金請求代行プログラム及び記録媒体を提供することができる。
【0110】
さらに、本実施例によれば、保険会社毎に個別に対応する処理領域として、複数のサービス提供領域が互いに独立して設けられているので、複数の保険会社を請求先として保険金の請求をする場合であっても、高いセキュリティを保つことができる。また、複数のサービス提供領域の各々が保険会社毎に異なる規定に対応することができ、効率良く保険金の請求の手続きを進行することができる。
【0111】
また、本実施例においては、利用者が複数の保険会社に保険金を請求する場合において、複数の保険会社に提出すべき必要書類の要求を示す情報を同じ要求先毎に集約して送信することができる。従って、複数の保険会社に保険金を請求する場合であっても、ユーザや医療機関等が負担する労力を軽減することができる。同じ保険会社に複数の異なる保険の請求をする場合にも同じことが言える。
【0112】
図８～１３を参照しつつ、保険金請求代行システム１０による保険金請求代行の際に保険金請求代行サーバ１１によって実行される保険金請求代行方法について説明する。保険金請求代行方法は、保険金請求代行サーバ１１が保険金請求代行プログラムを実行することによって実現される。
【0113】
図８は、保険金請求代行サーバ１１の共通処理部２７によって実行されるルーチンの一例である共通処理ルーチンＲＴ１を示すフローチャートである。例えば、共通処理部２７は、保険金請求代行サーバ１１に電源が投入されると、共通処理ルーチンＲＴ１を開始する。
【0114】
共通処理部２７は、共通処理ルーチンＲＴ１を開始すると、利用者端末１３（ｘ）からの請求必要事項の受信を待機する（ステップＳ１０１）。
【0115】
共通処理部２７は、ステップＳ１０１の実行後、請求必要事項を受信したか否かを判定する（Ｓ１０２）。ステップＳ１０２において、共通処理部２７は、通信部２１を介して、例えば図４に示したような請求必要事項を取得した場合に、請求必要事項を受信したと判定する。
【0116】
ステップＳ１０２において、共通処理部２７は、利用者端末からの特定の保険会社に対する保険金の請求を受け付けて当該請求に必要な事項を示す請求必要事項を取得する受付ステップを実行する受付部として機能する。
【0117】
上述したように、例えば、利用者が利用者端末１３（ｘ）を介して認証を行った後に保険金請求メニューの入力画面に請求に必要な事項を入力して請求ボタンを押下すると、必要な事項を示す請求必要事項が保険金請求代行サーバ１１に送信される。
【0118】
例えば、利用者は、請求必要事項を入力する際に、医療機関の領収書等の画像をアップロードしてもよい。すなわち、請求必要事項には、医療機関の領収書等の画像が添付されていてもよい。これによって、例えば、必要書類が医療機関の領収書のコピーのみである場合には、利用者による請求必要事項を送信後の書類の提出が不要となる。
【0119】
共通処理部２７は、ステップＳ１０２において請求必要事項を受信したと判定する（ステップＳ１０２：ＹＥＳ）と、必要な情報が揃っているか否かを判定する（ステップＳ１０３）。ステップＳ１０３において、例えば、請求必要事項に含まれる所定の項目について、情報が入力されているか否かが判定される。例えば、契約内容の照会に必要な保険証券番号等の、保険金請求の代行の処理において必要となる項目が、所定の項目として予め設定される。
【0120】
共通処理部２７は、ステップＳ１０３において、必要な情報が揃っていないと判定する（ステップＳ１０３：ＮＯ）と、利用者端末１３（ｘ）に、利用者に向けて再入力の要求を示す情報を送信する（ステップＳ１０４）。
【0121】
共通処理部２７は、ステップＳ１０３において、必要な情報が揃っていると判定する（ステップＳ１０３：ＹＥＳ）と、請求必要事項をサービス提供領域２９（ｘ）に送信する（ステップＳ１０５）。ステップＳ１０５において、例えば、共通処理部２７は、請求必要事項に含まれる請求先の保険会社に対応するサービス提供領域２９（ｘ）に対して、請求必要事項を送信する。
【0122】
また、ステップＳ１０５において、例えば、請求必要事項に含まれる請求先の保険会社が複数ある場合には、当該複数の保険会社の各々に対応するサービス提供領域２９（ｘ）に対して、請求必要事項を送信する。
【0123】
共通処理部２７は、ステップＳ１０５の実行後、共通処理ルーチンＲＴ１を終了し、次の共通処理ルーチンＲＴ１を新たに開始する。
【0124】
図９は、保険金請求代行サーバ１１のサービス提供領域２９（１）～２９（ｎ）の各々によって実行されるルーチンの一例であるサービス提供ルーチンＲＴ２を示すフローチャートである。例えば、サービス提供領域２９（ｘ）（ｘは任意の正の整数）は、保険金請求代行サーバ１１に電源が投入されると、サービス提供ルーチンＲＴ２を開始する。
【0125】
サービス提供領域２９（ｘ）は、サービス提供ルーチンＲＴ２を開始すると、共通処理部２７から請求必要事項を受信したか否かを判定する（ステップＳ２０１）。ステップＳ２０１において、例えば、サービス提供領域２９（ｘ）は、共通処理ルーチンＲＴ１のステップＳ１０５（図８参照）において当該サービス提供領域２９（ｘ）に宛てて送信された請求必要事項を受信した場合に、請求必要事項を受信したと判定する。
【0126】
サービス提供領域２９（ｘ）は、ステップＳ２０１において、請求必要事項を受信していないと判定する（ステップＳ２０１：ＮＯ）と、ステップＳ２０１を繰り返し、請求必要事項を受信したか否かを再び判定する。
【0127】
サービス提供領域２９（ｘ）の契約内容取得部３１は、ステップＳ２０１において、請求必要事項を受信したと判定する（ステップＳ２０１：ＹＥＳ）と、当該請求必要事項に基づいて、対応する保険会社の保険会社システム１５（ｘ）と通信を行って、当該請求必要事項による請求（以下、「本請求」とも称する）に係る契約内容を取得する（契約内容取得ステップ）（ステップＳ２０２）。
【0128】
ステップＳ２０２において、例えば、本請求の請求先の保険会社が「保険会社Ａ」である場合、保険会社Ａについてのサービス提供領域（Ａ）の契約内容取得部３１が、契約内容の送信を求める要求を保険会社Ａの保険会社システム（Ａ）に送信する。例えば、当該契約内容を要求する旨の情報には、保険証券番号を示す情報が含まれる。
【0129】
当該要求に対する回答として、当該契約内容を示す情報が、保険会社システム（Ａ）から保険金請求代行サーバ１１のサービス提供領域（Ａ）に宛てて送信される。例えば、ステップＳ２０２において、契約内容取得部３１が送信した要求によって特定された保険証券番号に対応する契約内容が送信される。
【0130】
サービス提供領域２９（ｘ）の精査処理部３３は、ステップＳ２０２が実行された後、請求必要事項と契約内容との一致度が所定以上か否かを判定する（ステップＳ２０３）。ステップＳ２０３において、例えば、精査処理部３３は、請求必要事項と契約内容との保険証券番号が一致していることを前提として、保険証券番号以外の所定の項目が一致している場合に、一致度が所定以上であると判定される。また、例えば、ステップＳ２０３において、保険証券番号以外の項目が所定の個数以上一致している場合に、一致度が所定以上であると判定される。
【0131】
精査処理部３３は、ステップＳ２０３において、請求必要事項と契約内容との一致度が所定以上ではないと判定する（ステップＳ２０３：ＮＯ）と、請求必要事項の再入力を要求する旨の情報を利用者端末１３（ｘ）に送信後（ステップＳ２０４）、ステップＳ２０１に戻り、請求必要事項を受信したか否かを再び判定する。
【0132】
精査処理部３３は、ステップＳ２０３において、請求必要事項と契約内容との一致度が所定以上であると判定する（ステップＳ２０３：ＹＥＳ）と、請求必要事項と契約内容との共通する項目の内容が完全に一致するか否かを判定する（ステップＳ２０５）。例えば、ステップＳ２０５において、精査処理部３３は、請求必要事項に含まれる氏名等の共通する項目が、完全に一致するか否を判定する。
【0133】
精査処理部３３は、ステップＳ２０５において、完全に一致しないと判定する（ステップＳ２０５：ＮＯ）と、利用者端末１３（ｘ）に確認要求を送信する（ステップＳ２０６）。例えば、ステップＳ２０６において、精査処理部３３は、契約者の氏名のうち姓だけが異なっている場合に、氏名の訂正が不要か否かの確認を要求する旨のメッセージを送信して利用者端末１３（ｘ）の表示画面に表示させる。
【0134】
精査処理部３３は、ステップＳ２０６の実行後、訂正無しで手続きを進めて良いか否かを判定する（ステップＳ２０７）。ステップＳ２０７において、例えば、ステップＳ２０６において、訂正が不要であることを示す入力が利用者端末１３（ｘ）を介して受け付けられたか否かが判定される。
【0135】
サービス提供領域２９（ｘ）は、ステップＳ２０７において、訂正無しで手続きを進められないと判定される（ステップＳ２０７：ＮＯ）と、再入力要求を利用者端末１３（ｘ）に送信後（ステップＳ２０８）、ステップＳ２０１に戻り、請求必要事項を受信したか否かを再び判定する。
【0136】
サービス提供領域２９（ｘ）の必要書類特定部３５は、ステップＳ２０５において、完全に一致すると判定された場合（ステップＳ２０５：ＹＥＳ）、又はステップＳ２０７において訂正無しで手続きを進めて良いと判定された場合（ステップＳ２０７：ＹＥＳ）、請求必要事項及び契約内容に基づいて、本請求による保険金の支払金額を算出する（ステップＳ２０９）。ステップＳ２０９において、例えば、必要書類特定部３５は、入院日数に基づいて、保険金の支払い金額を算出する。
【0137】
必要書類特定部３５は、ステップＳ２０９の実行後、請求必要事項及び契約内容に基づいて、本請求を行うに当たり保険会社に提出する必要のある必要書類を特定する（必要書類特定ステップ）（ステップＳ２１０）。
【0138】
ステップＳ２１０において、例えば、必要書類特定部３５は、請求必要事項及び契約内容に加えて、ステップＳ２０９において算出した保険金の支払金額に基づいて、必要書類を特定する。ステップＳ２１０において、例えば、必要書類特定部３５は、当該保険金の支払金額に基づいて診断書の要否を判定し、診断書が必要であると判定した場合に、診断書を必要書類として特定する。
【0139】
ステップＳ２１０において、例えば、必要書類特定部３５は、請求必要事項の所定の項目と、契約内容の当該所定の項目に対応する部分との比較に基づいて、必要書類を特定する。例えば、必要書類特定部３５は、請求必要事項に含まれる請求事由に基づいて、利用者が準備すべき書類を必要書類として特定する。ステップＳ２１０において、例えば、請求事由が交通事故である場合に、交通事故証明書が必要書類として特定される。ステップＳ２１０において、例えば、保険の契約後、本請求までに改姓があった場合に、戸籍抄本等の書類が必要書類として特定される。
【0140】
また、ステップＳ２１０において、必要書類特定部３５は、判定基準ＤＢ４３を参照して、対応する保険会社における必要書類の判断基準に従って、必要書類を特定してもよい。
【0141】
サービス提供領域２９（ｘ）は、ステップＳ２１０の実行後、必要書類取得サブルーチンを実行する（ステップＳ２１１）。ステップＳ２１１において、必要書類要求部３７は、必要書類に診断書が含まれる場合は医療機関に診断書を要求する。また、必要書類要求部３７は、必要書類に利用者が準備すべき書類が含まれる場合は、利用者に書類を要求する処理を行う。
【0142】
例えば、保険会社Ａのサービス提供領域２９（Ａ）の必要書類要求部３７は、保険会社Ａの規定の形式の診断書の作成を医療機関に依頼する。
【0143】
ステップＳ２１１の実行後、サービス提供領域２９（ｘ）の請求処理部３９は、保険金請求情報を作成する（ステップＳ２１２）。ステップＳ２１２において、例えば、請求処理部３９は、請求必要事項を含む請求情報と、必要書類とを合わせた情報を保険金請求情報として作成する。
【0144】
請求処理部３９は、ステップＳ２１２の実行後、保険金請求情報を対応する保険会社システム１５（ｘ）に宛てて送信する（ステップＳ２１３）。ステップＳ２１３の実行によって保険金請求情報が送信されることで、必要書類とともに請求に必要な情報が請求先の保険会社の保険会社システムに送信され（請求処理ステップ）、請求処理部３９による保険会社に対する保険金の請求が行われる。
【0145】
例えば、ステップＳ２１３が実行されると、サービス提供領域２９（ｘ）の取引管理ＤＢ４１の本請求の請求状況が「審査依頼中」として更新されて記憶される。
【0146】
サービス提供領域２９（ｘ）は、ステップＳ２１３の実行後、サービス提供ルーチンＲＴ２を終了し、次のサービス提供ルーチンＲＴ２を新たに開始する。
【0147】
なお、例えば、サービス提供ルーチンＲＴ２のステップＳ２０５において、医療機関端末１７（ｘ）と通信を行って、請求必要事項に含まれる医療機関に関する情報と、医療機関端末１７（ｘ）から受信した情報とが一致しているか否かを判定することで、請求必要事項の内容の正当性を判定してもよい。例えば、請求必要事項と医療機関からの情報とが一致しない場合には、医療機関からの情報を優先してもよく、利用者端末１３（ｘ）に問い合わせのメッセージを送信してもよい。
【0148】
なお、ステップＳ２０４及びステップＳ２０６～ステップＳ２０８におけるサービス提供領域２９（ｘ）と利用者端末１３（ｘ）との間の通信は、共通処理部２７を介して行われてもよい。
【0149】
サービス提供領域２９（ｘ）は、ステップＳ２１３の実行後、審査結果を保険会社システム１５（ｘ）から受信し、利用者端末１３（ｘ）に送信することで、審査結果を利用者に通知してもよい。例えば、審査によって支払いの対象と判断された場合には、保険会社から利用者に保険金が支払われる。当該保険金の支払いが完了した場合、サービス提供領域２９（ｘ）は、保険会社システム１５（ｘ）から支払い完了の通知を受信し、利用者端末１３（ｘ）に送信してもよい。また、サービス提供領域２９（ｘ）は、支払い完了の通知を受信した場合に、取引管理ＤＢの「請求状況」を更新して「支払い完了」としてもよい。
【0150】
なお、１つの請求についてのサービス提供ルーチンＲＴ２の終了後、保険金の支払いが完了した際に、サービス提供領域２９（ｘ）又は共通処理部２７は、サービス利用料の支払いの要求を利用者端末１３（ｘ）に通知してもよい。例えば、保険金の請求において診断書を提出する場合、保険金請求代行サーバ１１が診断書作成費用を医療機関に支払う処理を行い、診断書作成費用を含めたサービス利用料の金額を利用者端末１３（ｘ）に通知してもよい。例えば、保険金請求代行サーバ１１は、サービス利用料の支払いが完了した場合にも、サービス利用料の支払いが完了した旨及び当該支払の金額を取引管理ＤＢに記憶することとしてもよい。
【0151】
図１０は、サービス提供ルーチンＲＴ２のステップＳ２１１において実行されるサブルーチンの一例である必要書類取得サブルーチンＲＴ３を示すフローチャートである。
【0152】
サービス提供領域２９（ｘ）の必要書類要求部３７は、必要書類取得サブルーチンＲＴ３を開始すると、ステップＳ２１０において判定した必要書類に医療機関が発行する診断書が含まれるか否かを判定する（ステップＳ３０１）。
【0153】
必要書類要求部３７は、ステップＳ３０１において、診断書が含まれると判定すると、要求先として指定された医療機関端末１７（ｘ）に診断書の作成を要求する旨の情報を送信する（ステップＳ３０２）。
【0154】
ステップＳ３０２において、必要書類要求部３７は、診断書の送信を求める要求を医療機関の端末に送信する書類要求送信部として機能する。
【0155】
必要書類要求部３７は、ステップＳ３０２の実行後、又はステップＳ３０１において診断書が含まれないと判定した場合（ステップＳ３０１：ＮＯ）、必要書類に利用者が準備すべき書類が含まれるか否かを判定する（ステップＳ３０３）。
【0156】
必要書類要求部３７は、ステップＳ３０３において、必要書類に利用者が準備すべき書類が含まれると判定する（ステップＳ３０３：ＹＥＳ）と、利用者が準備すべき書類の送信を求める要求を利用者端末１３（ｘ）に送信する（ステップＳ３０４）。
【0157】
ステップＳ３０４において、サービス提供領域２９（ｘ）の必要書類要求部３７は、利用者が準備すべき書類の送信を求める要求を利用者の端末に送信する書類要求送信部として機能する。
【0158】
必要書類要求部３７は、ステップＳ３０３において、必要書類に利用者が準備すべき書類が含まれないと判定する（ステップＳ３０３：ＮＯ）と、受信すべき書類があるか否かを判定する（ステップＳ３０５）。例えば、必要書類要求部３７は、ステップＳ３０２において医療機関に診断書を要求していた場合、ステップＳ３０５において受信すべき書類があると判定する。例えば、必要書類要求部３７は、ステップＳ３０１において診断書が含まれないと判定していた場合、ステップＳ３０５において受信すべき書類がないと判定する。
【0159】
必要書類要求部３７は、ステップＳ３０４の実行後、又はステップＳ３０５において受信すべき書類があると判定した場合（ステップＳ３０５：ＹＥＳ）、要求した書類の受信を待機し（ステップＳ３０６）、その後要求した書類を要求先から受信したか否かを判定する（ステップＳ３０７）。
【0160】
ステップＳ３０６及びステップＳ３０７において、必要書類要求部３７は、外部から必要書類を受信する書類受信部として機能する。
【0161】
ステップＳ３０７において、例えば、ステップＳ３０２又はステップＳ３０４において要求した書類が複数ある場合は、要求した書類の全てを受信した場合に、要求した書類を受信したと判定される。
【0162】
必要書類要求部３７は、ステップＳ３０７において、要求した書類を受信していないと判定する（ステップＳ３０７：ＮＯ）と、ステップＳ３０６に戻り、要求した書類の受信を再び待機する。
【0163】
必要書類要求部３７は、ステップＳ３０７において、要求した書類を受信したと判定した場合（ステップＳ３０７：ＹＥＳ）、又はステップＳ３０５において受信すべき書類がないと判定した場合（ステップＳ３０５：ＮＯ）、必要書類取得サブルーチンＲＴ３を終了する。
【0164】
なお、書類の要求先が医療機関となるステップＳ３０１及びステップＳ３０２と、書類の要求先が利用者となるステップＳ３０３及びステップＳ３０４とは並行して実行されてもよく、別々のルーチンとして実行されてもよい。
【0165】
【0166】
共通処理ルーチンＲＴ４において、ステップＳ１０１～ステップＳ１０５までは共通処理ルーチンＲＴ１と同様に進行するため、説明を省略する。
【0167】
共通処理部２７は、ステップＳ１０５を実行して、請求先の保険会社に対応する１又は複数のサービス提供領域２９（ｘ）の各々に請求必要事項を送信後、当該サービス提供領域２９（ｘ）の各々から送信された必要書類の特定結果を示す情報を受信したか否かを判定する（ステップＳ４０１）。ステップＳ４０１において、例えば、請求先の保険会社が複数ある場合には、当該複数の保険会社の各々に対応する全てのサービス提供領域２９（ｘ）から必要書類の特定結果を示す情報を受信した場合に、特定結果を受信したと判定する。
【0168】
共通処理部２７は、ステップＳ４０１において、必要書類の特定結果を受信していないと判定する（ステップＳ４０１：ＮＯ）と、ステップＳ４０１を繰り返し、必要書類の特定結果を受信したか否かを再び判定する。
【0169】
共通処理部２７は、ステップＳ４０１において、必要書類の特定結果を受信したと判定する（ステップＳ４０１：ＹＥＳ）と、必要書類取得サブルーチンを実行し、必要書類を外部の要求先から受信する（ステップＳ４０２）。
【0170】
ステップＳ４０２において、共通処理部２７は、図１０において説明した必要書類取得サブルーチンＲＴ３と同様のサブルーチンを実行する。
【0171】
ステップＳ４０２において、例えば、共通処理部２７は、請求必要事項によって特定された１又は複数の医療機関端末１７（ｘ）の各々に診断書を要求し、その後、当該１又は複数の医療機関端末１７（ｘ）の各々から診断書を受信する。
【0172】
また、ステップＳ４０２において、例えば、共通処理部２７は、利用者端末１３（ｘ）に利用者が準備すべき１又は複数の書類を要求し、その後、当該利用者端末１３（ｘ）から送信された１又は複数の必要書類を受信する。
【0173】
共通処理部２７は、ステップＳ４０２の実行後、受信した必要書類を対応するサービス提供領域２９（ｘ）の各々に送信する（ステップＳ４０３）。
【0174】
ステップＳ４０３において、例えば、複数の保険会社に対する必要書類がある場合、該当する複数の保険会社のサービス提供領域２９（ｘ）の各々に、対応する必要書類が送信される。
【0175】
共通処理部２７は、ステップＳ４０３の実行後、又はステップＳ１０２において請求必要事項を受信していないと判定した場合（ステップＳ１０２：ＮＯ）、共通処理ルーチンＲＴ４を終了し、次の共通処理ルーチンＲＴ４を新たに開始する。
【0176】
以上のように、共通処理ルーチンＲＴ４によれば、複数の保険会社に対する複数の請求処理のために、複数のサービス提供領域によって複数の処理が同時並行で進行している場合、当該複数の処理において特定された複数の必要書類について、必要書類の送信を求める要求を集約して送信することができる。
【0177】
従って、例えば、利用者が準備すべき書類を複数の保険会社に提出する場合でも、利用者への書類の要求を共通処理部２７が集約して実行することができる。例えば、保険会社Ａ及び保険会社Ｂに提出すべき書類を要求する旨の情報が１回で利用者に要求される。従って、利用者は複数回にわたって書類の準備及び送信を行う必要がない。従って、保険金の請求における利用者の負担が軽減される。
【0178】
また、複数の保険会社についての請求処理が同時並行で進行している場合に限られず、１の保険会社に対する複数の請求が同時並行で進行している場合でも、同様に、共通処理部２７が集約して必要書類の要求を送信することができる。
【0179】
また、複数のサービス提供領域によらなくとも、１つのサービス提供領域で所定の期間内に複数の請求処理が行われる場合に、複数の必要書類が特定された場合にも共通処理部２７が集約して必要書類の要求を送信してもよい。
【0180】
なお、ステップＳ４０２において、共通処理部２７は、利用者に要求すべき必要書類のみを取得することとしてもよい。その場合、医療機関が要求先となる必要書類については、各々のサービス提供領域２９（ｘ）が取得することとしてもよい。
【0181】
図１２及び図１３は、図９において説明した保険金請求代行サーバ１１のサービス提供領域２９（１）～２９（ｎ）の各々によって実行されるサービス提供ルーチンＲＴ２の変形例であるサービス提供ルーチンＲＴ５を示すフローチャートである。
【0182】
サービス提供ルーチンＲＴ５は、必要書類を共通処理部２７が取得する点において、必要書類をサービス提供領域２９（１）～２９（ｎ）の各々が取得するサービス提供ルーチンＲＴ２と異なる。
【0183】
サービス提供ルーチンＲＴ５のうち、ステップＳ２０１からステップＳ２１０についてはサービス提供ルーチンＲＴ２と同様に進行するため、説明を省略する。
【0184】
サービス提供領域２９（ｘ）は、ステップＳ２１０を実行して必要書類を特定すると、必要書類の特定結果を共通処理部２７に送信する（ステップＳ５０１）。ステップＳ５０１において、例えば、サービス提供領域２９（ｘ）の必要書類要求部３７は、必要書類を示す情報を共通処理部２７に送信する。共通処理部２７は、必要書類を要求する旨の情報を各々の必要書類の要求先に送信する。ステップＳ５０１において、共通処理部２７は、１以上の必要書類の各々についての送信を求める要求を外部に送信する書類要求送信部として機能する。
【0185】
サービス提供領域２９（ｘ）は、ステップＳ５０１の実行後、必要書類を待機し（ステップＳ５０２）、その後、共通処理部２７から必要書類を受信したか否かを判定する（ステップＳ５０３）。
【0186】
ステップＳ５０３において、例えば、必要書類要求部３７は、共通処理ルーチンＲＴ４（図１１）のステップＳ４０３において、共通処理部２７からサービス提供領域２９（ｘ）に向けて送信された必要書類を受信した場合に、必要書類を受信したと判定する。
【0187】
必要書類要求部３７は、ステップＳ５０３において、必要書類を受信していないと判定する（ステップＳ５０３：ＮＯ）と、ステップＳ５０２に戻り、必要書類を再び待機する。
【0188】
必要書類要求部３７は、ステップＳ５０３において、必要書類を受信したと判定する（ステップＳ５０３：ＹＥＳ）と、サービス提供領域２９（ｘ）の請求処理部３９は、サービス提供ルーチンＲＴ２のステップＳ２１２と同様に保険金請求情報を作成する（ステップＳ５０４）。
【0189】
その後、請求処理部３９は、サービス提供ルーチンＲＴ２のステップＳ２１３と同様に保険金請求情報を対応する保険会社システム１５（ｘ）に宛てて送信する（ステップＳ５０５）。
【0190】
サービス提供領域２９（ｘ）は、ステップＳ５０５の実行後、サービス提供ルーチンＲＴ５を終了し、次のサービス提供ルーチンＲＴ５を繰り返し実行する。
【0191】
なお、例えば、サービス提供ルーチンＲＴ５において、利用者が準備すべき書類については共通処理部２７が利用者端末１３（ｘ）から取得し、診断書についてはサービス提供領域２９（ｘ）が医療機関から取得することとしてもよい。例えば、ステップＳ５０１において、利用者が準備すべき書類が含まれる場合にのみ、必要書類の特定結果を共通処理部２７に送信する。これによって、例えば、保険会社が規定する形式で診断書を作成する必要がある場合に、効率良く書類の準備を行うことができる。
【0192】
［変形例］
図１４を参照し、本実施例の保険金請求代行サーバ１１の変形例である保険金請求代行サーバ６１の構成について説明する。図１４に示すように、保険金請求代行サーバ６１は、保険金請求代行サーバ１１と同様の構成に加えて、サービス提供領域２９（１）～２９（ｎ）の各々に、契約内容ＤＢ６３を有している。
図１４を参照し、本実施例の保険金請求代行サーバ１１の変形例である保険金請求代行サーバ６１の構成について説明する。図１４に示すように、保険金請求代行サーバ６１は、保険金請求代行サーバ１１と同様の構成に加えて、サービス提供領域２９（１）～２９（ｎ）の各々に、契約内容ＤＢ６３を有している。
【0193】
契約内容ＤＢ６３は、各々のサービス提供領域２９（ｘ）に対応する保険会社の顧客契約情報が記憶されているデータベースである。契約内容ＤＢ６３には、例えば図７に示したような顧客毎の保険契約の内容が記憶されている。
【0194】
例えば、契約内容ＤＢ６３には、保険金請求代行サーバ６１の利用者についての契約情報がサービス提供領域２９（ｘ）によって予め取得されて記憶されている。例えば、保険金請求代行サーバ６１における利用者の登録の際に保険会社名についても入力させ、対応する保険会社の保険会社システム１５（ｘ）から、当該利用者の契約内容を取得してもよい。
【0195】
また、例えば、契約内容ＤＢ６３は、保険会社システム１５（ｘ）内において顧客の契約情報を記憶するデータベースと同期していてもよい。これによって、例えば、契約内容の更新があった場合にも最新の情報を保険金請求代行サーバ６１内に保持しておくことができる。
【0196】
保険金請求代行サーバ６１によれば、サービス提供ルーチンＲＴ２のステップＳ２０２（図９参照）において、サービス提供領域２９（ｘ）の契約内容取得部３１が契約内容を取得する際に、保険会社システム１５（ｘ）との間で通信を行う必要が無い。契約内容取得部３１は、サービス提供領域２９（ｘ）内の契約内容ＤＢ６３を参照することで、契約内容を取得することができる。よって、保険金請求代行のための処理を効率良く進行することができる。
【0197】
以上、詳細に説明したように、本実施例の保険金請求代行装置を含む保険金請求代行システムによれば、請求必要事項に基づいて契約内容を取得し、請求必要事項及び契約内容に基づいて必要書類を特定し、外部にある利用者の端末又は保険会社のシステムに必要書類の送信を求める要求を送信して各々の要求先から必要書類を受信し、請求必要事項を含む請求情報を必要書類とともに保険会社システムに送信することで、利用者に代わって保険金の請求の処理を行うことができる。
【0198】
従って、保険金の請求に係るユーザや医療機関等が負担する労力を軽減して保険金請求手続を効率化し、円滑な保険金請求を実現可能にする保険金請求代行装置、保険金請求代行システム、保険金請求代行方法、保険金請求代行プログラム及び記録媒体を提供することができる。
【0199】
なお、上記の実施例において、複数の保険会社が契約している例について説明したが、これに限られず、１社の保険会社のみが契約していてもよい。
【0200】
また、上記の実施例において、複数の保険会社に対して保険金の請求を行う場合の例について説明したが、これに限られず、１社の保険会社のみに対して保険金の請求を行うこともできる。本願の保険金請求代行装置、保険金請求代行システム、保険金請求代行方法、保険金請求代行プログラム及び記録媒体は、一度に１つの保険会社に対して保険金の請求を行う場合にも、一度に複数の保険会社に対して保険金の請求を行う場合にも、いずれの場合にも適用可能である。
【0201】
上述した実施例及び変形例における構成及びルーチンは例示に過ぎず、用途等に応じて適宜変更可能である。
【符号の説明】
【0202】
１０ 保険金請求代行システム
１１ 保険金請求代行サーバ
１３ 利用者端末
１５ 保険会社システム
１７ 医療機関端末
２１ 通信部
２３ 利用者情報ＤＢ
２５ 認証部
２７ 共通処理部
２９ サービス提供領域
３１ 契約内容取得部
３３ 精査処理部
３５ 必要書類特定部
３７ 必要書類要求部
３９ 請求処理部
４１ 取引管理ＤＢ
４３ 判定基準ＤＢ
１１ 保険金請求代行サーバ
１３ 利用者端末
１５ 保険会社システム
１７ 医療機関端末
２１ 通信部
２３ 利用者情報ＤＢ
２５ 認証部
２７ 共通処理部
２９ サービス提供領域
３１ 契約内容取得部
３３ 精査処理部
３５ 必要書類特定部
３７ 必要書類要求部
３９ 請求処理部
４１ 取引管理ＤＢ
４３ 判定基準ＤＢ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】