JP7250201B1 - 支援装置および支援方法 - Google Patents

Abstract

【課題】損害の種別に応じたプロセスにより補償を付与する支援装置及び支援方法を提供する。【解決手段】本発明の一実施形態に係る支援装置１は、保険請求の対象であるイベントの損害の種別に関する情報を含むイベント情報を取得する取得部１００ａと、イベントの補償を決定するために必要な一以上のプロセスと、プロセスを進行させるためにイベント情報を含む所定情報が満たすべき進行条件とが関連付けられたプロセス情報を損害の種別毎に記憶する記憶部１０２と、イベント情報に基づいて、損害の種別に対応するプロセス情報を選択する選択部１００ｂと、選択部１００ｂによって選択されたプロセス情報に基づいて、プロセスを進行又は停止させる進行制御部１００ｃと、を備える。【選択図】図２

Description

本発明は、支援装置および支援方法に関する。

従来から、保険金支払処理のための損害査定を行うシステムが知られている。例えば、特許文献１には、損害データと、基準データベースに格納された基準データとを比較し、その比較結果に基づいて、保険金の支払の可否を判断するシステムが開示されている。これによれば、査定の判断を一律的、一元的に行うことができる。

特開２００３－０３０４４１号公報

保険金請求に係る損害の種別が複数存在する場合には、損害に関する報告を受けてから保険金を支払うまでのプロセスを当該損害の種別に応じて使い分ける必要がある。しかしながら、特許文献１に記載されたシステムでは、損害の種別に応じたプロセスにより補償を付与することはできない。

そこで、本発明は、上記課題に鑑み、損害の種別に応じたプロセスにより補償を付与することを目的とする。

本発明の一態様に係る支援装置は、保険請求の対象であるイベントの損害の種別に関する情報を含むイベント情報を取得する取得部と、イベントの補償を決定するために必要な一以上のプロセスと、プロセスを進行させるためにイベント情報を含む所定情報が満たすべき進行条件とが関連付けられたプロセス情報を損害の種別毎に記憶する記憶部と、イベント情報に基づいて、損害の種別に対応するプロセス情報を選択する選択部と、選択部によって選択されたプロセス情報に基づいて、プロセスを進行させる進行制御部と、を備える。

本発明の他の一態様に係る支援方法は、コンピュータに、保険請求の対象であるイベントの損害の種別に関する情報を含むイベント情報を取得する取得ステップと、イベント情報に基づいて、イベントの補償を決定するために必要な一以上のプロセスと、プロセスを進行させるためにイベント情報を含む所定情報が満たすべき進行条件とが関連付けられるとともに損害の種別毎に記憶されたプロセス情報を損害の種別に応じて選択する選択ステップと、選択ステップによって選択されたプロセス情報に基づいて、プロセスを進行させる進行制御ステップと、を実行させる。

本発明によれば、損害の種別に応じたプロセスにより補償を付与することができる。

本実施形態に係るシステムの機能構成の一例を説明するための図である。 本実施形態に係るシステムの動作の一例を説明するための図である。 本実施形態に係るシステムの動作の一例を説明するための図である。 本実施形態に係るシステムの動作の一例を説明するための図である。 本実施形態に係るシステムの動作の一例を説明するための図である。 本実施形態に係るシステムの動作の一例を説明するための図である。 本実施形態に係るシステムのハードウェア構成の一例を説明するための図である。 本実施形態に係るシステムの変形例を説明するための図である。 本実施形態に係るシステムの変形例を説明するための図である。 本実施形態に係るシステムの変形例を説明するための図である。

添付図面を参照して、本発明の好適な実施形態（以下、「本実施形態」という）について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

本発明において、「部」や「手段」、「装置」、「システム」とは、単に物理的手段を意味するものではなく、その「部」や「手段」、「装置」、「システム」が有する機能をソフトウェアによって実現する場合も含む。また、１つの「部」や「手段」、「装置」、「システム」が有する機能が２つ以上の物理的手段や装置、ソフトウェアにより実現されても、２つ以上の「部」や「手段」、「装置」、「システム」の機能が１つの物理的手段や装置、ソフトウェアにより実現されてもよい。

＜１．システム構成＞
図１を参照して、本実施形態に係る支援システムのシステム構成例を説明する。

図１に示すように、支援システムは、支援装置１、第１端末装置１０、第２端末装置１２、外部記憶装置１４及び通信ネットワーク１６を含む。端末装置の数は、例えば、２つに限定されず、３つ以上であってよい。支援装置１、第１端末装置１０、第２端末装置１２及び外部記憶装置１４は、通信ネットワーク１６を介して互いに接続されている。なお、支援システムは、他のシステムの一部であってもよい。

支援装置１は、第１端末装置１０のユーザ（以下、「第１ユーザ」又は「被保険者」という）が、保険請求の対象であるイベントに関する補償を受けるためのプロセスを進行又は停止させる情報処理装置であって、第１端末装置１０、第２端末装置１２及び外部記憶装置１４との通信が可能な情報処理装置である。支援装置１は、所定のプログラムを実行することにより、損害の種別に応じたプロセスを進行又は停止させるための各種処理を実行することができる。

第１端末装置１０は、補償を受けようとするユーザの端末装置であって、支援装置１及び第２端末装置１２との通信が可能な端末装置である。第１端末装置１０は、ユーザ端末装置又は被保険者端末装置ということもできる。第１端末装置１０は、所定のプログラムを実行することにより、イベントに関するイベント情報を支援装置１に送信することができる。

第２端末装置１２は、第１端末装置１０のユーザに補償を付与するユーザ（以下、「第２ユーザ」という）の端末装置であって、支援装置１、第１端末装置１０及び外部記憶装置１４との通信が可能な端末装置である。第２端末装置１２は、担当者端末装置又はオペレータ端末装置ということもできる。第２端末装置１２は、所定のプログラムを実行することにより、追加情報を支援装置１に送信することができる。

外部記憶装置１４は、各種情報が記憶された情報処理装置であって、支援装置１、第２端末装置１２との通信が可能な情報処理装置である。各種情報には、第１ユーザの契約に関する情報、第１ユーザと第２ユーザとの間で送受信されたメッセージに関する情報及び第１ユーザの損害に関する情報及び第１ユーザに付与された補償に関する情報等が含まれる。

＜２．各装置の機能構成＞
図１の機能ブロック図を参照して、支援システムに含まれる各装置の機能の一例を説明する。

図１に示すように、支援システムは、支援装置１、第１端末装置１０、第２端末装置１２、外部記憶装置１４及び通信ネットワーク１６を含む。

―支援装置１―
支援装置１は、制御部１００、記憶部１０２及びネットワークインタフェース部１０４を含み、それぞれがバス１０６を介して電気的に接続されている。

記憶部１０２は、イベント情報ＤＢ（ＤａｔａＢａｓｅ）１０２ａ、追加情報ＤＢ１０２ｂ、外部情報ＤＢ１０２ｃ及びプロセス情報ＤＢ１０２ｄを含む。

イベント情報ＤＢ１０２ａは、取得部１００ａが第１端末装置１０から取得した、保険請求の対象であるイベントの損害の種別に関する情報を含むイベント情報を記憶する。イベント情報は、典型的には、第１ユーザが第１端末装置１０に入力した情報である。

イベントとは、保険請求の対象であり、補償の対象となり得る各種事象である。イベントの損害の種別は、例えば、自動車事故、広域災害（例えば、火災、風災及び水災等）、盗難、紛失及び破損等を含む。また、保険請求とは、補償の付与の請求であり、典型的には、保険金の支払の請求である。

追加情報ＤＢ１０２ｂは、取得部１００ａが第２端末装置１２から取得した、プロセスを進行させるための追加情報を記憶する。追加情報は、典型的には、第２ユーザが第２端末装置１２に入力した情報である。

外部情報ＤＢ１０２ｃは、取得部１００ａが外部記憶装置１４から取得した情報（以下、「外部情報」という）を記憶する。外部情報は、契約情報、メッセージ情報、損害情報、補償情報及び災害情報を含む。外部情報は、典型的には、外部のシステム（例えば、契約システム、応対システム、案件管理システム、決裁システム及び災害検知システム等）にも記憶された情報である。

なお、以下では、イベント情報、追加情報及び外部情報を含む情報を所定情報という。所定情報の一例は、図５を用いて後述する。

プロセス情報ＤＢ１０２ｄは、プロセス情報を損害の種別毎に記憶する。プロセス情報は、イベントの補償を決定するために必要な一以上のプロセスと、プロセスを進行させるために所定情報が満たすべき進行条件とが関連付けられた情報を含む。

一以上のプロセスは、有無責判定、初期対応、損害査定及び補償の付与の少なくともいずれかを含む。

有無責判定とは、ユーザが補償の付与対象であるか否かを判定するプロセスである。補償の付与対象でない場合とは、例えば、保険者が補償を付与する責任がない（すなわち、無責である）場合である。保険者が補償を付与する責任がない場合とは、例えば、第１ユーザが無免許運転をして事故を起こした場合や、第１ユーザに対する損害が保険契約の契約期間外に発生した場合等を含む。

初期対応とは、イベント情報を取得するプロセスである。初期対応において取得するイベント情報は、例えば、事故形態、事故の発生場所、入庫先、損害箇所の画像、負傷者の有無等を含む。入庫先とは、損害を受けた箇所の修理を依頼する業者等を意味する。なお、イベント情報は初期対応以外においても取得される。

損害査定とは、補償を決定するプロセスである。補償を決定することとは、例えば、損害箇所の画像に基づいて修理費を推定し、支払う保険金の金額を算出することを含む。なお、補償を決定することは、補償の具体的な内容を決定すること及び第１ユーザへ補償を付与することを決定することのほか、例えば、有無責判定において保険者が無責であると判定すること等、第１ユーザへ補償を付与しないことを決定することも含む。

補償の付与とは、補償をユーザに付与するプロセスである。補償を付与することは、保険者が第１ユーザに直接的又は間接的に補償を付与することを含む。補償を直接的に付与することとは、例えば、第１ユーザの銀行口座に保険金を振り込むこと及び第１ユーザが立て替えた修理費を精算すること等を含む。補償を間接的に付与することとは、例えば、修理工場に対して修理の代金を支払うこと及び修理期間中の代車を手配すること等を含む。

進行条件は、プロセスに属する複数の項目に対応する複数の条件を含む。進行条件の一例は、図６を用いて後述する。

制御部１００は、取得部１００ａ、選択部１００ｂ、進行制御部１００ｃ、通知部１００ｆ及び通信部１００ｇを含む。

取得部１００ａは、保険請求の対象であるイベントの損害の種別に関する情報を含むイベント情報を第１端末装置１０から取得する。すなわち、取得部１００ａは、イベント情報を取得するイベント情報取得部を含む。取得されたイベント情報は、イベント情報ＤＢ１０２ａに記憶される。

他にも、取得部１００ａは、プロセスを進行させるための追加情報を第２端末装置１２から取得する。すなわち、取得部１００ａは、追加情報を取得する追加情報取得部を含む。取得された追加情報は、追加情報ＤＢ１０２ｂに記憶される。

他にも、取得部１００ａは、外部情報を外部記憶装置１４から取得する。すなわち、取得部１００ａは、外部情報を取得する外部情報取得部を含む。取得された外部情報は、外部情報ＤＢ１０２ｃに記憶される。

選択部１００ｂは、イベント情報に基づいて、損害の種別に対応するプロセス情報を選択する。選択部１００ｂは、損害の種別毎にプロセス情報が関連付けられたプロセス情報選択リストに基づいて損害の種別に対応するプロセス情報を選択してもよい。選択部１００ｂによりプロセス情報を選択する方法の一例を、図２―図３を用いて後述する。

進行制御部１００ｃは、対象判定部１００ｄ及び進行判定部１００ｅを含んでもよい。

進行制御部１００ｃは、対象判定部１００ｄによってイベントがプロセスの対象であるか否かを判定する。対象判定部において否定的な判定がされる場合（すなわち、イベントがプロセスの対象でないと判定される場合）とは、例えば、イベントが複数台の自動車が巻き込まれる人身事故である場合等、補償の付与を定型的なプロセスにより実行できない場合が含まれる。このような場合には、典型的には、第２ユーザが支援装置１に代わってプロセスを進行させ、補償の付与を実行する。

また、進行制御部１００ｃは、選択部１００ｂによって選択されたプロセス情報に基づいて、プロセスを進行又は停止させる。すなわち、進行制御部１００ｃは、所定情報が進行条件に含まれる複数の条件を満たしているか否かを進行判定部１００ｅにより判定し、その結果に基づいて、プロセスを進行又は停止させる。この際、進行制御部１００ｃは、所定情報が進行条件に含まれる複数の条件のすべてを満たしている場合にプロセスを進行させ、進行条件に含まれる複数の条件のいずれか一つ以上を満たしていない場合にプロセスを停止させてもよい。プロセスを進行又は停止させる方法の一例を、図４―図６を用いて後述する。

通知部１００ｆは、進行制御部１００ｃによるプロセスの停止に応答して、プロセスが停止した旨を第２端末装置１２に通知する。通知の内容は、典型的には、プロセスを進行させるための追加情報を入力することを第２ユーザに対して要求するものである。

なお、第２端末装置１２に通知することとは、第２ユーザが当該通知の内容を認識できるようにすることである。すなわち、通知することとは、例えば、プッシュ通知のようにサーバ装置側から積極的に通知を行うことに加え、第２端末装置１２から通知に関する情報をサーバ装置側に要求し、取得することを含む。

通信部１００ｇは、ネットワークインタフェース部１０４を介して第１端末装置１０、第２端末装置１２及び外部記憶装置１４との通信を行う。送受信される情報の具体例は、図４等を用いて後述する。

ネットワークインタフェース部１０４は、通信ネットワーク１６を介して、第１端末装置１０、第２端末装置１２及び外部記憶装置１４との通信を行う。

―第１端末装置１０―
第１端末装置１０は、補償を受けようとするユーザが使用する端末装置である。第１端末装置１０は、例えば、パーソナルコンピュータ、スマートデバイス及びコネクテッドカー等である。

第１端末装置は、制御部、記憶部、入力部、出力部及び通信部を備える（図示しない）。制御部は、記憶部に記憶された各種プログラムを実行することによりイベント情報の送信等の所定の処理を実行する。入力部は、マイク、キーボード、タッチパネル及びカメラ等を機能させる。出力部は、液晶画面等の表示機器及びスピーカー等を機能させる。通信部は、支援装置１及び第２端末装置１２と通信を行う。

―第２端末装置１２―
第２端末装置１２は、補償を付与するユーザが使用する端末装置である。第２端末装置１２は、例えば、パーソナルコンピュータ等である。

第２端末装置は、制御部、記憶部、入力部、出力部及び通信部を備える（図示しない）。制御部は、記憶部に記憶された各種プログラムを実行することにより追加情報の送信等の所定の処理を実行する。入力部は、マイク、キーボード、タッチパネル及びカメラ等を機能させる。出力部は、液晶画面等の表示機器及びスピーカー等を機能させる。通信部は、支援装置１、第１端末装置１０及び外部記憶装置１４と通信を行う。

―外部記憶装置１４―
外部記憶装置１４は、上述したとおり、外部のシステムに記憶された情報を記憶する装置である。外部記憶装置１４には、契約情報ＤＢ１４ａ、メッセージ情報ＤＢ１４ｂ、損害情報ＤＢ１４ｃ、補償情報ＤＢ１４ｄ及び災害情報ＤＢ１４ｅが含まれる。

契約情報ＤＢ１４ａは、第１ユーザの契約に関する情報を記憶する。契約に関する情報には、契約の状況、免許の有効性、契約期間、等級、第１ユーザの年齢、保険料の金額及び保険料の支払履歴等の情報が含まれる。

メッセージ情報ＤＢ１４ｂは、第１ユーザと第２ユーザとの間で送受信されたメッセージに関する情報を記憶する。メッセージに関する情報には、第１ユーザが第２ユーザに対して送信したメッセージと、当該メッセージに対する第２ユーザの応答状況に関する情報が含まれる。例えば、第１ユーザが第２ユーザ（又は第２ユーザの所属する保険会社）に対して送信したメッセージに対して、第２ユーザが応答していない場合には、「未応答」という情報を記憶する。

損害情報ＤＢ１４ｃは、イベントの損害に関する情報を記憶する。損害に関する情報には、損害の規模、具体的な損害の箇所、損害を受けた物品等の使用可否、損害状況に関する画像データ及び損害査定に関する見積もりデータ等が含まれる。

補償情報ＤＢ１４ｄは、第１ユーザに対する補償に関する情報を記憶する。補償に関する情報には、第１ユーザに対する補償の内容（例えば、保険金の支払額）が含まれる。

災害情報ＤＢ１４ｅは、広域災害に関する情報が記憶される。広域災害に関する情報には、風災に関する情報（例えば、台風の番号、進路、被災地域、被害規模、発生日時及び最大風速等）、水災に関する情報（例えば、津波や高潮の発生場所、被害規模及び関連する震災や風災等）及び火災に関する情報（例えば、火災の発生場所、被害規模及び出火原因等）等が含まれる。

＜３．支援装置１の動作例＞
図２－図６を用いて、支援装置１がプロセス情報を選択し、当該プロセス情報に基づいてプロセスを進行又は停止させる際の動作の一例を示す。

―選択部１００ｂの動作例―
図２―図３を参照して、選択部１００ｂの動作の一例を説明する。

図２は、支援装置１の動作の概要を示す。支援装置１は、取得部１００ａにより、第１端末装置１０からイベント情報を取得する（Ｓ１２）。イベント情報は、損害の種別に関する情報を含み、本実施形態においては損害の種別は「自動車事故」であるとする。イベント情報の取得とは、例えば、第１ユーザから自動車事故の報告に関する連絡を受信することである。この例においては、イベント情報として損害の種別に関する情報に加えて、事故日、事故形態及び発生場所に関する情報を取得するものとする。

支援装置１は、選択部１００ｂにより、損害の種別に対応するプロセス情報を選択する（Ｓ１４）。本実施形態においては、図３に示されるプロセス情報選択リストに基づいて、損害の種別に対応するプロセス情報を選択するものとする。プロセス情報選択リストは、損害の種別毎にプロセス情報が関連付けられている。具体的には、「自動車事故」、「風災」、「水災」及び「火災」の損害の種別に対して、それぞれプロセス情報Ｐ１０、プロセス情報Ｐ２０、プロセス情報Ｐ３０及びプロセス情報Ｐ４０が関連付けられている。

本実施形態においては、Ｓ１２で取得したイベント情報に含まれる損害の種別は「自動車事故」であるとする。この場合、選択部１００ｂは、「自動車事故」に関連付けられているプロセス情報Ｐ１０を選択する。

進行制御部１００ｃは、選択部１００ｂによって選択されたプロセス情報Ｐ１０に基づいて、プロセスを進行又は停止させる。図３によると、プロセス情報Ｐ１０は、プロセスＰ１１、プロセスＰ１２、プロセスＰ１３及びプロセスＰ１４のそれぞれに対して、進行条件である条件群Ｃ１１、条件群Ｃ１２、条件群Ｃ１３及び条件群Ｃ１４が関連付けられた情報である。すなわち、進行制御部１００ｃはプロセスＰ１１－プロセスＰ１４を進行させ、それぞれのプロセスにおいて条件群Ｃ１１－条件群Ｃ１４に基づく進行判定の結果に応じてプロセスを停止させる。

進行制御部１００ｃは、例えば、図２のとおり、プロセスＰ１１においてステップＡ（Ｓ１８）を行った後にプロセスＰ１１に関連付けられた条件群Ｃ１１に基づいて進行判定（Ｓ２０）を行う。他にも、例えば、プロセスＰ１４では、プロセスＰ１４に関連付けられた条件群Ｃ１４に基づいて進行判定（Ｓ３０）を行った後にステップＤ（Ｓ３２）を行う。なお、ステップとは、プロセスの少なくとも一部である。例えば、有無責判定のプロセスには、第１ユーザの契約情報の確認というステップが含まれてもよい。

上記では、Ｓ１２で取得したイベント情報に含まれる損害の種別が「自動車事故」である場合について説明したが、イベント情報に含まれる損害の種別が「風災」である場合には、選択部１００ｂによりプロセス情報Ｐ２０が選択され（図３参照）、進行制御部１００ｃはプロセス情報Ｐ２０（すなわち、プロセスＰ２１－プロセスＰ２４及び条件群Ｃ２１－条件群Ｃ２４）に基づいてプロセスを進行又は停止させる。このように、支援装置１は、損害の種別に応じた一以上のプロセスにより補償の付与を行うことができる。

―進行制御部１００ｃの動作例―
図４―図６を参照して、進行制御部１００ｃの動作の一例を説明する。この例においては、上記のとおりＳ１２によりイベント情報が取得され、Ｓ１４によりプロセス情報Ｐ１０が選択されたものとする。また、プロセス情報Ｐ１０に属するプロセスＰ１１、プロセスＰ１２、プロセスＰ１３及びプロセスＰ１４は、それぞれ有無責判定、初期対応、損害査定及び補償の付与であるとする。なお、支援装置１及び第２ユーザは保険会社に属し、第１ユーザは当該保険会社が提供する保険の契約をしている者であるとする。

まず、支援装置１は、プロセスＰ１１を実行する。プロセスＰ１１は、有無責判定である（図４参照）。

プロセスＰ１１において、支援装置１は、取得部１００ａにより、外部記憶装置１４に記憶された各種ＤＢから、外部情報を取得する（Ｓ３００）。外部情報は、契約情報（例えば、契約の状況及び免許の有効性に関する情報）、損害情報（例えば、入庫先、損害箇所の画像に関する情報）及び補償情報（例えば、支払項目及び支払額に関する情報）を含む。取得された外部情報は、外部情報ＤＢ１０２ｃに記憶される。

図５に、Ｓ３００後の時点における所定情報の一例を示す。Ｓ３００後の時点における所定情報は、Ｓ１２において取得したイベント情報、すなわち「損害の種別」、「事故日」、「事故形態」及び「発生場所」の項目のそれぞれに関連付けられた「自動車事故」、「２０２２年７月１日」、「衝突（単独・対物）」及び「国内」という情報を含む。所定情報は、さらに、Ｓ３００で取得した外部情報、すなわち「契約の状況」、「免許の有効性」、「入庫先」、「損害箇所の画像」、「支払項目」及び「支払額」の項目のそれぞれに関連付けられた「有効」、「有効」、「不明」、「登録なし」、「未定」及び「未定」という情報を含む。

なお、いずれかの項目に関連付けられた情報が「不明」である場合とは、取得部１００ａにより当該情報が取得されなかった場合を含む。この例においては、「入庫先」に関する情報が外部記憶装置１４には記憶されていなかったものとする。そのため、取得部１００ａは当該情報を取得することができず、「入庫先」の項目には「不明」という情報が関連付けられている。

その後、進行制御部１００ｃは、プロセスＰ１１に関連付けられた進行条件である条件群Ｃ１１に基づく進行判定を行う（Ｓ３０２）。

図６に、進行条件の一例を示す。進行条件は、プロセスに属する複数の項目に対応する複数の条件を含む。プロセスに属する複数の項目とは、典型的には、当該プロセスにおいて判定対象となる項目である。例えば、図６によると、プロセスＰ１１において判定対象となる項目は「事故形態」、「発生場所」、「契約の状況」及び「免許の有効性」であるため、これらがプロセスＰ１１に属する複数の項目である。他にも、例えば、プロセスＰ１１－プロセスＰ１４のいずれかにおいて判定対象となる項目は「事故形態」、「発生場所」、「契約の状況」、「免許の有効性」、「入庫先」、「損害箇所の画像」及び「支払額」であるため、これらがプロセス全体に属する複数の項目である。

また、プロセスに属する複数の項目に対応する複数の条件とは、典型的には、各項目に関連付けられた条件である。例えば、プロセスＰ１１に属する複数の項目に対応する複数の条件とは、「事故形態」、「発生場所」、「契約の状況」、「免許の有効性」の項目のそれぞれに対応する「自動車の対物事故である」、「事故の発生場所が国内である」、「契約が有効である」及び「免許が有効である」という条件である。

判定対象となる項目は、プロセスの段階により異なってもよい。例えば、図６のとおり、プロセスＰ１１の進行判定においては「事故形態」、「発生場所」、「契約状況」及び「免許の有効性」の項目が判定対象となり、プロセスＰ１２の進行判定においては「事故形態」及び「入庫先」の項目が判定対象となってもよい。

また、所定情報はプロセスを進行させる過程で変化する場合があるため、特定の項目に関連付けられた条件が複数のプロセスにおいて判定対象となってもよい。例えば、「事故形態」の項目はプロセスＰ１１―プロセスＰ１３のそれぞれにおいて判定対象となってもよい。

進行制御部１００ｃは、所定情報がプロセスに対応する複数の条件を満たしているか否かに基づいて、プロセスを進行又は停止させる。本実施形態においては、所定情報が当該複数の条件のすべてを満たしている場合にプロセスを進行させ、当該複数の条件のいずれか一つ以上を満たしていない場合にプロセスを停止させるものとする。

図６によると、プロセスＰ１１においては「事故形態」、「発生場所」、「契約の状況」及び「免許の有効性」の４つの項目に対応する条件（すなわち、条件群Ｃ１１）が判定対象となる。図５のＳ３００後の時点における所定情報によると、「事故形態」について取得された所定情報は「自動車事故、衝突（単独・対物）」であり、「事故形態」に対応する「自動車の対物事故である」という条件を満たす。また、「発生場所」について取得された所定情報は「国内」であり、「発生場所」に対応する「事故の発生場所が国内である」という条件を満たす。また、「契約の状況」について取得された所定情報は「有効」であり、「契約の状況」に対応する「契約が有効である」という条件を満たす。また、「免許の有効性」について取得された所定情報は「有効」であり、「免許の有効性」に対応する「免許が有効である」という条件を満たす。以上をまとめると、所定情報は条件群Ｃ１１のすべてを満たし、進行制御部１００ｃはプロセスを進行させる。

次に、支援装置１は、プロセスＰ１２を実行する。プロセスＰ１２は、初期対応である（図４参照）。

プロセスＰ１２において、支援装置１は、第１ユーザに対して事故に関する情報の送信を要求する（Ｓ３０４）。当該要求は、第１端末装置１０にインストールされた専用のアプリケーションソフトウェアを介するものであってもよい。また、当該要求は、その時点において所定情報において「不明」となっている情報に関するものであってもよい。この例においては、要求の内容は、Ｓ３００後の時点の所定情報において情報が「不明」となっている「入庫先」に関する情報を送信させることであるとする。

要求を送信した支援装置１は、取得部１００ａにより第１ユーザからの回答に関する情報を取得する（Ｓ３０６）。この例においては、支援装置１の要求に対して第１ユーザから得られた回答は「○○工場」であったとする。すなわち、Ｓ３０６後の所定情報は、「入庫先」の項目に対して「○○工場」という情報が含まれる。

なお、事故情報の要求（Ｓ３０４）から第１ユーザの回答の取得（Ｓ３０６）までの間は、支援装置１は待機状態となってもよい。この際、待機状態であっても、プロセスは進行しているという。

その後、支援装置１は、プロセスＰ１２に関連付けられた進行条件である条件群Ｃ１２に基づく進行判定を行う（Ｓ３０８）。

図６によると、プロセスＰ１２においては「事故形態」及び「入庫先」の２つの項目に対応する条件（すなわち、条件群Ｃ１２）が判定対象となる。図５のＳ３０６後の所定情報によると、「事故形態」について取得された所定情報は「自動車事故、衝突（単独・対物）」であり、「事故形態」に対応する「自動車の対物事故である」という条件を満たす。また、「入庫先」について取得された所定情報は「○○工場」であり、「入庫先」に対応する「入庫先が判明している」という条件を満たす。よって、所定情報は条件群Ｃ１２のすべてを満たし、進行制御部１００ｃはプロセスを進行させる。

仮に第１ユーザから回答を取得した後の所定情報が進行条件を満たさない場合には、支援装置１は再度事故情報の要求（Ｓ３０４に相当）を実行してもよい。例えば、回答により得られた入庫先に関する情報が「××工場」であり、当該入庫先が実際には存在しない場合には、現実に存在する入庫先を回答するよう再度入庫先に関する情報の送信を求めてもよい。

次に、支援装置１は、プロセスＰ１３を実行する。プロセスＰ１３は、損害査定である（図４参照）。

プロセスＰ１３において、支援装置１は、プロセスＰ１３に関連付けられた進行条件である条件群Ｃ１３に基づく進行判定を行う（Ｓ３１０）。

図６によると、プロセスＰ１３においては「事故形態」及び「損害箇所の画像」の２つの項目に対応する条件（すなわち、条件群Ｃ１３）が判定対象となる。Ｓ３１０の時点における所定情報はＳ３０６後の時点における所定情報から変化していないため、図５のＳ３０６後の時点における所定情報によると、「事故形態」について取得された所定情報は「自動車事故、衝突（単独・対物）」であり、「事故形態」に対応する「自動車の対物事故である」という条件を満たす。一方で、「損害箇所の画像」について取得された所定情報は「登録なし」であり、「損害箇所の画像」に対応する「損害箇所の画像が登録されている」という条件を満たさない。よって、所定情報は条件群Ｃ１３の少なくとも一部を満たさないため、進行制御部１００ｃはプロセスを停止させる。

その後、支援装置１は、通知部１００ｆにより第２ユーザに対して通知を行う（Ｓ３１２）。通知は、例えば、第２端末装置１２にインストールされた専用アプリケーションソフトウェア、電子メール及び第２端末装置１２の表示画面上のポップアップ等を介して行われる。

通知の内容は、典型的には、プロセスを停止させたことを通知するとともにプロセスを進行させるための所定の対応を指示するものである。この例においては、満たされなかった条件は「損害箇所の画像」の項目に関するものであるため、通知は、第１ユーザから損害箇所の画像を取得し、支援装置１に当該画像を追加情報として登録することを指示するものであるとする。

その後、第２ユーザは、第１ユーザに対して回答の送信を要求する（Ｓ３１４）。この例においては、要求の内容は、損害箇所の画像の送信に関するものである。なお、第２ユーザは、専用のアプリケーションソフトウェアを使用する方法のほか、電子メール又は電話等により第１ユーザに対して要求を行ってもよい。

その後、第１ユーザは、回答を含む情報を第２ユーザに送信する（Ｓ３１６）。この例においては、回答を含む情報は、損害箇所の画像ファイルである。情報を第２ユーザに送信することは、第２端末装置１２に情報を直接送信することに加えて、所定のサーバ装置にファイルを登録又はアップロードし、第２端末装置１２が当該ファイルにアクセス可能にすることを含む。

その後、第２ユーザは、第１ユーザから受信した情報に基づいて、追加情報を支援装置１に送信する（Ｓ３１８）。支援装置１は、取得部１００ａにより追加情報を取得し、追加情報ＤＢ１０２ｂに記憶する。この例においては、第２ユーザは損害箇所の画像ファイルを登録された旨の情報を追加情報として送信するものとする。

その後、支援装置１は、進行制御部１００ｃにより再度進行判定を行う（Ｓ３２０）。図５のＳ３１８後の所定情報によると、「事故形態」に対応する条件については上述したとおり満たしており、さらに、「損害箇所の画像」についての所定情報は「損害箇所の画像ファイルの登録あり」であり、「損害箇所の画像」に対応する「損害箇所の画像が登録されている」という条件を満たしている。よって、所定情報は条件群Ｃ１３のすべてを満たし、進行制御部１００ｃはプロセスを進行させる。

その後、支援装置１は保険金の支払額の算出を行う（Ｓ３２２）。支払額は、例えば、Ｓ３１６において登録された損害箇所の画像ファイルに基づいて、ＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）により算出する。この場合のＡＩは、典型的には、多数の事故における損害箇所の画像ファイルと、それぞれの当該事故において実際に支払われた保険金の支払額との関係を学習させることにより作成した機械学習モデルを用いる。このようなＡＩを用いることにより、追加情報として登録された損害箇所の画像ファイルを入力することで、過去事例により妥当と推測される保険金の支払額を算出することができる。

この例においては、保険金の支払額は「２５万円」と算出されるものとする。すなわち、図５のとおり、Ｓ３２２後の時点における所定情報は、「支払額」の項目に対して関連付けられた「２５万円」という情報を含む。

また、支援装置１は、支払額の算出を行う際に支払項目を決定する。支払項目とは、支払額の内容である。この例においては、支払項目は「車両修理費」であるとする。すなわち、図５のとおり、Ｓ３２２後の時点における所定情報は、「支払項目」の項目に関連付けられた「車両修理費」という情報を含む。

次に、支援装置１は、プロセスＰ１４を実行する。プロセスＰ１４は、補償の付与である（図４参照）。

プロセスＰ１４において、支援装置１は、プロセスＰ１４に関連付けられた進行条件である条件群Ｃ１４に基づく進行判定を行う（Ｓ３２４）。

図６によると、プロセスＰ１４においては「支払額」の項目に対応する条件（すなわち、条件群Ｃ１４）が判定対象となる。図５のＳ３２２後の時点における所定情報によると、「支払額」の項目に関連付けられた情報は「２５万円」であり、「支払額」に対応する「保険金の支払額が３０万円未満である」という条件を満たす。よって、所定情報は条件群Ｃ１４を満たすため、進行制御部１００ｃはプロセスを進行させる。

その後、支援装置１は、第１ユーザに対して請求意思の確認を行う（Ｓ３２６）。

その後、第１ユーザは、請求意思がある旨の回答を支援装置１に対して行う（Ｓ３２８）。

その後、支援装置１は、保険金の支払を実行する（Ｓ３３０）。この際、支援装置１は支援システムとは異なるシステム（例えば、決裁システム）に支払を実行させてもよい。

以上をまとめると、支援装置１は、保険請求の対象であるイベントの損害の種別に関する情報を含むイベント情報を取得する取得部１００ａと、イベントの補償を決定するために必要な一以上のプロセスと、プロセスを進行させるためにイベント情報を含む所定情報が満たすべき進行条件とが関連付けられたプロセス情報を損害の種別毎に記憶する記憶部１０２と、イベント情報に基づいて、損害の種別に対応するプロセス情報を選択する選択部１００ｂと、選択部１００ｂによって選択されたプロセス情報に基づいて、プロセスを進行又は停止させる進行制御部１００ｃと、を備える。

支援装置１によれば、損害の種別に応じたプロセスにより補償を付与することができる。具体的には、イベント情報に含まれる損害の種別に関する情報に基づいて選択部１００ｂがプロセス情報を選択し、進行制御部１００ｃが当該プロセス情報に基づいてプロセスを進行又は停止させることにより、様々な損害の種別に対する補償の付与を支援装置１により実行することができる。例えば、上記の動作例においては、損害の種別は「自動車事故」であるとして説明したが、損害の種別が「風災」である場合にはプロセス情報Ｐ２０が選択され（図３参照）、支援装置１はプロセスＰ１１－プロセスＰ１４とは少なくとも一部が異なるプロセスＰ２１－プロセスＰ２４を実行し、それぞれのプロセスにおいて条件群Ｃ２１－条件群Ｃ２４に基づいて進行判定を行う。

各プロセス及び進行条件は、損害の種別に応じた内容であってもよい。例えば、上記の動作例においては「自動車事故」に対する補償を付与するために第１ユーザに対して事故情報の要求（Ｓ３０４）において「入庫先」に関する情報を取得したが、損害の種別が「風災」である場合には「被害を受けた建築物の種類」、「建築物の被害状況」及び「台風の規模」等の情報を取得してもよい。他にも、例えば、上記の例においては進行条件に「免許の有効性」に関する条件が含まれていたが、損害の種別が「風災」である場合には進行条件に「台風の規模」に関する条件が含まれていてもよい。

また、支援装置１によれば、補償の付与を効率化することができる。具体的には、補償の付与に要する工程のうち、コンピュータにより定型的に処理できるものについては支援装置１が実行し、その他の非定型的な工程については第２ユーザに実行させることで、第２ユーザの負担を軽減するとともに、事故連絡を受け付けてから補償を付与するまでに要する時間を短縮することができる。

例えば、上記の動作例においては、最初の進行判定においてプロセスを進行させると判定されたプロセスＰ１１、プロセスＰ１２及びプロセスＰ１４については、支援装置１がプロセスを進行させており、第２ユーザは第２端末装置１２の操作を行っていない。すなわち、第２ユーザにとってはプロセスを進行させるための労力が削減されており、第１ユーザにとっては補償を受け取るまでのリードタイムが短縮される。

一方で、例えば、最初の進行判定においてプロセスを停止させると判定されたプロセスＰ１３については、第２ユーザがプロセスを進行させるために必要な追加情報を収集し、支援装置１に入力している（Ｓ３１２―Ｓ３１８）。事故の形態やイベント情報の内容によってはコンピュータによる定型的な処理が実行できない場合があり、このような場合には第２ユーザがプロセスに部分的に介入することにより柔軟な事故対応が可能になる。

＜４．ハードウェア構成＞
図７を参照して、上述してきた支援装置１をコンピュータ２０により実現する場合のハードウェア構成の一例を説明する。なお、それぞれの装置の機能は、複数台の装置に分けて実現することもできる。

図７に示すように、コンピュータ２０は、プロセッサ２００と、記憶装置２０２と、入力Ｉ／Ｆ２０４と、データＩ／Ｆ２０６と、通信Ｉ／Ｆ２０８、及び表示装置２１０を含む。

プロセッサ２００は、記憶装置２０２に記憶されているプログラムを実行することによりコンピュータ２０における様々な処理を制御する。例えば、支援装置１の制御部１００が備える各機能部等は、記憶装置２０２に記憶されたプログラムを、プロセッサ２００が実行することにより実現可能である。

記憶装置２０２は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ ＭｅｍｏｒＹ）などの記憶媒体である。ＲＡＭは、プロセッサ２００によって実行されるプログラムのプログラムコードや、プログラムの実行時に必要となるデータを一時的に記憶する。

記憶装置２０２は、他にも、例えばハードディスクドライブ（ＨＤＤ）やフラッシュメモリなどの不揮発性の記憶媒体である。記憶装置２０２は、オペレーティングシステムや、上記各構成を実現するための各種プログラムを記憶する。当該各種プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体（Ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）であってもよい。この他、記憶装置２０２は、事業者情報等の各種情報を登録するテーブルと、当該テーブルを管理するＤＢを記憶することも可能である。このようなプログラムやデータは、必要に応じて記憶装置２０２にロードされることにより、プロセッサ２００から参照される。

入力Ｉ／Ｆ２０４は、ユーザからの入力を受け付けるためのデバイスである。入力Ｉ／Ｆ２０４の具体例としては、キーボードやマウス、タッチパネル、各種センサ、ウェアラブル・デバイスなどが挙げられる。入力Ｉ／Ｆ２０４は、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）などのインタフェースを介してコンピュータ２０に接続されてもよい。

データＩ／Ｆ２０６は、コンピュータ２０の外部からデータを入力するためのデバイスである。データＩ／Ｆ２０６の具体例としては、各種記憶媒体に記憶されているデータを読み取るためのドライブ装置などがある。データＩ／Ｆ２０６は、コンピュータ２０の外部に設けられることも考えられる。その場合、データＩ／Ｆ２０６は、例えばＵＳＢなどのインタフェースを介してコンピュータ２０へと接続される。

通信Ｉ／Ｆ２０８は、コンピュータ２０の外部の装置と有線または無線により、通信ネットワーク１６を介したデータ通信を行うためのデバイスである。通信Ｉ／Ｆ２０８は、コンピュータ２０の外部に設けられることも考えられる。その場合、通信Ｉ／Ｆ２０８は、例えばＵＳＢなどのインタフェースを介してコンピュータ２０に接続される。

表示装置２１０は、各種情報を表示するためのデバイスである。表示装置２１０の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ウェアラブル・デバイスのディスプレイなどが挙げられる。表示装置２１０は、コンピュータ２０の外部に設けられてもよい。その場合、表示装置２１０は、例えばディスプレイケーブルなどを介してコンピュータ２０に接続される。また、入力Ｉ／Ｆ２０４としてタッチパネルが採用される場合には、表示装置２１０は、入力Ｉ／Ｆ２０４と一体化して構成することが可能である。

なお、本実施形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。また、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均等なものに置換した実施の形態を採用することが可能であり、かかる実施の形態も本発明の範囲に含まれる。

また、上記実施の形態で記載された支援装置１が備える構成要素は、記憶装置２０２に格納されたプログラムがプロセッサ２００によって実行されることで、定められた処理が他のハードウェアと協働して実現されるものとする。また、言い換えれば、これらの構成要素は、ソフトウェアまたはファームウェアとしても、それと対応するハードウェアとしても想定され、その双方の概念において、「機能」、「手段」、「部」、「処理回路」、「ユニット」、または「モジュール」などとも記載され、またそれぞれに読み替えることができる。

＜５．変形例＞
なお、本発明を上記実施形態に基づいて説明してきたが、以下のような場合も本発明に含まれる。

上記実施形態においては、支援装置１、第１端末装置１０、第２端末装置１２及び外部記憶装置１４のそれぞれが一つの機器であるとして説明したが、これに限られない。例えば、支援装置１及び第２端末装置１２が一つの機器であってもよく、支援装置１の機能が複数の機器により実現されてもよい。

進行条件は、損害の種別が広域災害である場合には、保険請求をする者の過失の有無に関する条件を含まず、損害の種別が広域災害以外である場合には、保険請求をする者の過失の有無に関する条件を含んでもよい。

図８に、損害の種別が「風災」である場合の進行条件の一例を示す。図８における進行条件は、「台風番号」、「台風の規模」、「被災形態」、「発生場所」、「契約の状況」、「損害箇所の画像」及び「支払額」の項目のそれぞれに対して、「台風番号が登録されている」、「最大瞬間風速が５０ｍ／ｓ以上である」、「被災したのは一般住宅又は共同集宅の建物である」、「災害の発生場所が国内である」、「契約が有効である」、「損害箇所の画像が登録されている」及び「保険金の支払額が２００万円未満である」という条件が関連付けられている。このように、損害の種別が「風災」等の広域災害である場合には、第１ユーザの過失の有無に関する条件が含まれなくてもよい。

一方で、損害の種別が「自動車事故」等の広域災害以外のものである場合には、第１ユーザの過失の有無に関する条件を含んでもよい。例えば、図６における進行条件に含まれる「免許が有効である」という条件が満たされないのは、第１ユーザが無免許運転をしていた場合等、典型的には第１ユーザに過失が存在する場合である。

広域災害に関する保険請求は当該広域災害の発生直後に急増する場合が多く、さらに損害が天災等の広域災害により発生している場合には第１ユーザに過失がある場合が少ないため、保険請求に係る損害の種別が広域災害である場合の進行条件には第１ユーザの過失の有無に関する条件を含まないようにすることで、効率的な補償の付与を実行することができる。

また、取得部１００ａは、イベント情報を第１装置から取得し、損害の種別が広域災害である場合に当該広域災害に関する災害情報を第１装置とは異なる第２装置から取得してもよい。第１装置は典型的には第１端末装置１０であり、第２装置は典型的には外部記憶装置１４である。

損害の種別が広域災害である場合には、当該広域災害に関する情報は必ずしも第１ユーザから取得する必要はなく、災害情報が記憶されたサーバ装置から取得してもよい。例えば、損害の種別が「風災」である場合には、取得部１００ａは第１ユーザから台風番号に関する情報を取得し、さらに当該台風番号に基づいて天気予報システムから台風に関する情報（例えば、発生日時、進路及び規模等）を取得してもよい。

このように、広域災害に関する情報を外部システムから取得することで、第１ユーザの災害情報を入力する労力を削減するとともに、客観的な情報に基づいて効率的な補償の付与を実行することができる。

また、イベント情報がイベントの複数の損害の種別に関する情報を含む場合、選択部１００ｂは、当該複数の損害の種別に対応するプロセス情報を複数選択し、進行制御部１００ｃは、選択部１００ｂによって選択された複数のプロセス情報に基づいて、プロセスを進行させてもよい。

図９を用いて、イベント情報がイベントの複数の損害の種別に関する情報を含む場合におけるプロセスの実行方法の一例を説明する。

まず、支援装置１は、取得部１００ａにより第１ユーザからイベント情報を取得する（Ｓ４００）。図１０を用いて、イベント情報がイベントの複数の損害の種別に関する情報を含む場合における所定情報の一例を示す。この例においては、風災により建物と自動車の両方が損害を受けたものとする。所定情報は、「損害の種別」、「台風番号」、「被災形態」、「事故日」、「事故形態」、「発生場所」、「契約の状況」、「免許の有効性」、「入庫先」、「損害箇所の画像」、「支払項目」及び「支払額」の項目のそれぞれに関連付けられた情報を含む。

この例において、所定情報は、「風災」という損害の種別に対応する情報と、「自動車事故」という損害の種別に対応する情報とを含む。具体的には、「風災」という損害の種別に対応する情報には、「台風番号」、「被災形態」、「発生場所」、「契約の状況」、「損害箇所の画像」及び「支払額」の項目のそれぞれに対する「台風Ｎ号」、「建物（一般住宅）」、「国内」、「有効」、「損害箇所の画像ファイルの登録あり」及び「未定」という情報を含む。さらに、「自動車事故」という損害の種別に対応する情報には、「事故日」、「事故形態」、「発生場所」、「契約の状況」、「免許の有効性」、「入庫先」、「損害箇所の画像」、「支払項目」及び「支払額」の項目のそれぞれに対する「ＹＹＹＹ年ＭＭ月ＤＤ日」、「飛来物」、「国内」、「有効」、「有効」、「○○工場」、「損害箇所の画像ファイルの登録あり」、「車両修理費」及び「未定」という情報を含む。

その後、支援装置１は、選択部１００ｂにより損害の種別に応じたプロセス情報を選択する。具体的には、選択部１００ｂは、複数の損害の種別に対応するプロセス情報を複数選択する。すなわち、選択部１００ｂは、「風災」という損害の種類に対応するプロセス情報Ｐ２０を選択し（Ｓ４０２）、さらに「自動車事故」という損害の種別に対応するプロセス情報Ｐ１０を選択する（Ｓ４０４）。なお、損害の種別と、プロセス情報、プロセス及び進行条件との対応関係については図３に示したとおりである。

その後、支援装置１は、プロセス情報Ｐ２０に基づいて、「風災」についてのプロセスを実行する（Ｓ４０６）。具体的には、プロセスＰ２１－プロセスＰ２４のそれぞれを実行し、各プロセスにおける進行判定は条件群Ｃ２１－条件群Ｃ２４に基づいて行う。プロセス情報Ｐ２０に基づいてプロセスを進行させる方法については、図４－図６を用いて説明した方法に準ずる。

その後、支援装置１は、プロセス情報Ｐ１０に基づいて、「自動車事故」についてのプロセスを実行する（Ｓ４０８）。具体的には、プロセスＰ１１－プロセスＰ１４のそれぞれを実行し、各プロセスにおける進行判定は条件群Ｃ１１－条件群Ｃ１４に基づいて行う。プロセス情報Ｐ１０に基づいてプロセスを進行させる方法については、図４－図６を用いて説明したとおりである。

保険請求に係る情報には、複数の損害の種別に関する情報が含まれる場合があり、このような場合には必ずしも単一の種類のプロセスによっては補償の付与を実行できない。例えば、保険請求に「風災」に関する情報と「自動車事故」に関する情報とが含まれる場合、それぞれの損害の種別に対応するプロセスによって補償を付与する必要がある。

このような場合に、選択部１００ｂが当該複数の損害の種別に対応するプロセス情報を複数選択し、進行制御部１００ｃが選択部１００ｂによって選択された複数のプロセス情報に基づいてプロセスを進行させることで、複数の損害の種別に関する補償の付与を連続的又は並列的に実行することができる。例えば、上記の例では一つの保険請求に対してＳ４０６では「風災」による損害に対する保険金が支払われ、Ｓ４０８では「自動車」の損害に対する保険金が支払われる。

また、上記実施形態においては、「自動車事故」の損害の種別に対応する進行条件は図６のとおりであるとしたが、これに限られない。進行条件の項目は、例えば、「口座情報」、「対象保険商品」、「用途車種」、「ロードアシストの実施有無」、「代理店種別」、及び「被保険者の年齢」等であり、それぞれの項目に応じた条件が設定されていてもよい。

進行条件は、典型的には、人による介入が必要でないと判定する条件であるため、システムの有する機能に応じて異なってもよい。具体的には、システムが多機能である場合には第２ユーザによる介入が必要でない場合が多いため、広いプロセス進行条件（すなわち、第２ユーザに通知がされにくい条件）を用いたほうが効率に補償を付与することができる。

また、上記実施形態においては、所定情報及び進行条件はいずれもテーブル形式で表現するものとしたが、これに限られない。すなわち、情報及び条件の表現形式は任意のものでよい。各情報及び条件は、例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式及びＸＭＬ形式等のファイル形式や、木構造、リスト及び構造体等のデータ構造により表現されるものであってもよい。また、進行条件は機械学習により生成したものであってもよい。

また、上記実施形態においては、所定情報はいずれもテキストに基づくデータであるとして説明したが、これに限られない。すなわち、各種データは真偽値、数値、日時、画像データ、３Ｄモデルデータ及び動画データを含んでもよい。

また、上記実施形態においては、プロセスＰ１３の進行判定（Ｓ３１０）でプロセスを停止させた後、再度プロセスＰ１３からプロセスを復帰させたが、これに限られない。すなわち、支援装置１は、停止させたプロセスから復帰させてもよく、停止させたプロセスとは異なるプロセスから復帰させてもよい。この場合、追加情報は、進行制御部１００ｃが進行させるプロセスを指定するプロセス指定情報を含んでもよい。

復帰させるプロセスとして停止させたプロセスと同一のプロセスを指定することによって、追加情報が当該プロセスの進行条件を満たすか否かを支援装置１に判定させることができる。これにより、第２ユーザの追加情報の入力ミスがあった場合に、後段のプロセスに影響を及ぼすことを未然に防止できる。

一方で、復帰させるプロセスとして停止させたプロセスとは異なるプロセスを指定することによって、迅速な補償の付与を実現することができる場合がある。例えば、追加情報がごく軽微な修正に留まる場合、プロセスを復帰させる際の再度の進行判定は不要な場合もある。このような場合には、停止させたプロセスの次のプロセスから復帰させることによって、迅速な補償の付与を実現することができる。

また、上記実施形態においては、プロセスＰ１４において第２ユーザは操作を行わないとして説明したが、これに限られない。例えば、第１ユーザからの回答を受け取った（Ｓ３１６）支援装置１は、進行判定（Ｓ３２４）の結果にかかわらず第２ユーザに対して保険金の支払に関する承認を求める通知を行ってもよい。

この場合、第２端末装置１２は承認画面を表示してもよい。承認画面には、典型的には、承認を行うための根拠に関する情報が表示される。例えば、各プロセスの進行判定において判定対象であった項目と、当該項目に対する判定結果等の情報が含まれる。承認画面を確認した第２ユーザは、支払の承認を行う。支払の承認は、例えば、承認画面において表示された承認ボタンの押下等によって行う。

また、上記実施形態においては、保険金の支払額は、損害箇所の画像ファイルに基づいて、ＡＩにより算出するとして説明したが、これに限られない。例えば、支援装置１は、自装置で支払額を算出する代わりに、損害査定を行う者（アジャスターともいう）に対して支払額を算出させるための発注を行ってもよい。

また、上記実施形態においては、外部記憶装置１４は支援システムの内部にあるものとしたが、これに限られない。例えば、支援装置１は、外部のシステムが提供するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を利用して外部情報を取得してもよい。

＜６．本発明の実施の態様＞
本発明の一実施形態に係る支援装置１は、保険請求の対象であるイベントの損害の種別に関する情報を含むイベント情報を取得する取得部１００ａと、イベントの補償を決定するために必要な一以上のプロセスと、プロセスを進行させるためにイベント情報を含む所定情報が満たすべき進行条件とが関連付けられたプロセス情報を損害の種別毎に記憶する記憶部１０２と、イベント情報に基づいて、損害の種別に対応するプロセス情報を選択する選択部１００ｂと、選択部１００ｂによって選択されたプロセス情報に基づいて、プロセスを進行又は停止させる進行制御部１００ｃと、を備える。

上記態様において、損害の種別は、自動車事故と、火災、風災及び水災を含む広域災害との少なくともいずれか一つを含んでもよい。

上記態様において、記憶部１０２は、損害の種別毎にプロセス情報が関連付けられたプロセス情報選択リストをさらに記憶しており、選択部１００ｂは、プロセス情報選択リストに基づいて、損害の種別に対応するプロセス情報を選択してもよい。

上記態様において、進行条件は、プロセスに属する複数の項目に対応する複数の条件を含み、進行制御部１００ｃは、所定情報が複数の条件を満たしているか否かに基づいて、プロセスを進行又は停止させてもよい。

上記態様において、進行制御部１００ｃは、所定情報が複数の条件のすべてを満たしている場合にプロセスを進行させ、複数の条件のいずれか一つ以上を満たしていない場合にプロセスを停止させてもよい。

上記態様において、進行条件は、損害の種別が広域災害である場合には、保険請求をする者の過失の有無に関する条件を含まず、損害の種別が広域災害以外である場合には、保険請求をする者の過失の有無に関する条件を含んでもよい。

上記態様において、取得部１００ａは、イベント情報を第１装置から取得し、損害の種別が広域災害である場合に広域災害に関する災害情報を第１装置とは異なる第２装置から取得してもよい。

上記態様において、イベント情報がイベントの複数の損害の種別に関する情報を含む場合、選択部１００ｂは、複数の損害の種別に対応するプロセス情報を複数選択し、進行制御部１００ｃは、選択部１００ｂによって選択された複数のプロセス情報に基づいて、プロセスを進行させてもよい。

上記態様において、一以上のプロセスは、ユーザが補償の付与対象であるか否かを判定する有無責判定と、イベント情報を取得する初期対応と、補償を決定する損害査定と、補償をユーザに付与する補償付与との少なくともいずれかを含んでもよい。

本発明の他の一実施形態に係る支援方法は、コンピュータに、保険請求の対象であるイベントの損害の種別に関する情報を含むイベント情報を取得する取得ステップと、イベント情報に基づいて、イベントの補償を決定するために必要な一以上のプロセスと、プロセスを進行させるためにイベント情報を含む所定情報が満たすべき進行条件とが関連付けられるとともに損害の種別毎に記憶されたプロセス情報を損害の種別に応じて選択する選択ステップと、選択ステップによって選択されたプロセス情報に基づいて、プロセスを進行させる進行制御ステップと、を実行させる。

１ 支援装置
１０ 第１端末装置
１２ 第２端末装置
１００ 制御部
１００ａ 取得部
１００ｂ 選択部
１００ｃ 進行制御部
１００ｄ 対象判定部
１００ｅ 進行判定部
１００ｆ 通知部
１０２ 記憶部

Claims (10)

1. 保険請求の対象であるイベントの損害の種別に関する情報を含むイベント情報を、前記保険請求を行うユーザの端末装置から取得する第１取得部と、
   前記イベント情報における前記損害の種別が広域災害であることに基づいて、前記広域災害に関する災害情報をサーバ装置から取得する第２取得部と、
   前記イベントの補償を決定するために必要な一以上のプロセスと、前記プロセスを進行させるにあたって前記保険請求に係る担当者による介入が必要ではないと判定するために前記イベント情報及び前記災害情報を含む所定情報が満たすべき進行条件とが関連付けられたプロセス情報を前記損害の種別毎に記憶する記憶部と、
   前記イベント情報に基づいて、前記損害の種別に対応する前記プロセス情報を選択する選択部と、
   前記選択部によって選択された前記プロセス情報に基づいて、前記プロセスを進行又は停止させる進行制御部と、
   を備える、支援装置。
2. 前記損害の種別は、自動車事故と、火災、風災及び水災を含む広域災害との少なくともいずれか一つを含む、請求項１に記載の支援装置。
3. 前記記憶部は、前記損害の種別毎に前記プロセス情報が関連付けられたプロセス情報選択リストをさらに記憶しており、
   前記選択部は、前記プロセス情報選択リストに基づいて、前記損害の種別に対応する前記プロセス情報を選択する、請求項１に記載の支援装置。
4. 前記進行条件は、前記プロセスに属する複数の項目に対応する複数の条件を含み、
   前記進行制御部は、前記所定情報が前記複数の条件を満たしているか否かに基づいて、前記プロセスを進行又は停止させる、請求項１に記載の支援装置。
5. 前記進行制御部は、前記所定情報が前記複数の条件のすべてを満たしている場合に前記プロセスを進行させ、前記複数の条件のいずれか一つ以上を満たしていない場合に前記プロセスを停止させる、請求項４に記載の支援装置。
6. 前記進行条件は、前記損害の種別が広域災害である場合には、保険請求をする者の過失の有無に関する条件を含まず、前記損害の種別が広域災害以外である場合には、保険請求をする者の過失の有無に関する条件を含む、請求項１に記載の支援装置。
7. 前記進行制御部による前記プロセスの停止に応答して、前記担当者の端末装置に通知する通知部と、
   前記通知を受けた前記担当者の端末装置から前記プロセスを進行させるための追加情報を取得する追加情報取得部と、
   を備え、
   前記進行制御部は、前記追加情報に基づいて、前記プロセスを進行させる、請求項１に記載の支援装置。
8. 前記イベント情報が前記イベントの複数の損害の種別に関する情報を含む場合、前記選択部は、前記複数の損害の種別に対応する前記プロセス情報を複数選択し、
   前記進行制御部は、前記選択部によって選択された前記複数のプロセス情報に基づいて、前記プロセスを並列的に進行させる、請求項１に記載の支援装置。
9. 前記一以上のプロセスは、ユーザが補償の付与対象であるか否かを判定する有無責判定と、前記イベント情報を取得する初期対応と、前記補償を決定する損害査定と、前記補償をユーザに付与する補償付与との少なくともいずれかを含む、請求項１から請求項８のいずれか一項に記載の支援装置。
10. コンピュータに、
    保険請求の対象であるイベントの損害の種別に関する情報を含むイベント情報を、前記保険請求を行うユーザの端末装置から取得する第１取得ステップと、
    前記イベント情報における前記損害の種別が広域災害であることに基づいて、前記広域災害に関する災害情報をサーバ装置から取得する第２取得ステップと、
    前記イベント情報に基づいて、前記イベントの補償を決定するために必要な一以上のプロセスと、前記プロセスを進行させるにあたって前記保険請求に係る担当者による介入が必要ではないと判定するために前記イベント情報及び前記災害情報を含む所定情報が満たすべき進行条件とが関連付けられるとともに前記損害の種別毎に記憶されたプロセス情報を前記損害の種別に応じて選択する選択ステップと、
    前記選択ステップによって選択された前記プロセス情報に基づいて、前記プロセスを進行させる進行制御ステップと、を実行させる、支援方法。

Images