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

Abstract

【課題】補償の請求に関して確認すべき項目を選別して表示することができる支援装置及び支援方法を提供する。【解決手段】支援装置１は、保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得部１００ａと、イベント情報を取得してからイベントに対する補償内容を決定するまでの間の一以上のプロセスと、一以上のプロセスのそれぞれについて異常が存在するかどうかを判定するための異常条件と、を記憶する記憶部１０２と、イベント情報を含む所定情報と、異常条件とに基づいて、一以上のプロセスのそれぞれについて異常が存在するか否かを判定する判定部１００ｄと、異常が存在すると判定されたプロセスの進行が完了した場合において、判定部によって、異常が存在すると判定された少なくとも一つのプロセスに関する異常情報を表示する表示部１０４と、を備える。【選択図】図１

Description

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

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

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

保険金請求の受付から支払の過程には、担当者が保険金請求の内容や支払額に関する承認を要する場合が多い。しかしながら、保険金請求に関して確認すべき項目は多岐に渡り、全ての項目を目視により確認することは困難である。

そこで、本発明は、上記課題に鑑み、補償の請求に関して確認すべき項目を選別して表示することができる支援装置及び支援方法を提供することを目的とする。

本発明の一態様に係る支援装置は、保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得部と、イベント情報を取得してからイベントに対する補償内容を決定するまでの間の一以上のプロセスと、一以上のプロセスのそれぞれについて異常が存在するかどうかを判定するための異常条件と、を記憶する記憶部と、イベント情報を含む所定情報と、異常条件とに基づいて、一以上のプロセスのそれぞれについて異常が存在するか否かを判定する判定部と、異常が存在すると判定されたプロセスの進行が完了した場合において、判定部によって、異常が存在すると判定された少なくとも一つのプロセスに関する異常情報を表示する表示部と、を備える。

本発明の他の一態様に係る支援方法は、コンピュータに、保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得ステップと、イベント情報を含む所定情報と、イベント情報を取得してからイベントに対する補償内容を決定するまでの間の一以上のプロセスのそれぞれについて異常が存在するか否かを判定するための異常条件に基づいて、一以上のプロセスのそれぞれについて異常が存在するか否かを判定する判定ステップと、異常が存在すると判定されたプロセスの進行が完了した場合において、判定ステップによって、異常が存在すると判定された少なくとも一つのプロセスに関する異常情報を表示する表示ステップと、を実行させる。

本発明によれば、補償の請求に関して確認すべき項目を選別して表示することができる。

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

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

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

図１に本実施形態における支援システムの概略図を示す。支援システムは、第１端末装置１０からの補償の請求を受け付け、支援装置１及び第２端末装置１２により補償を付与するための各種の処理を実行するものである。

＜１．システム構成＞
図１を参照して、支援システムのシステム構成例を説明する。

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

支援装置１は、第１端末装置１０のユーザ（以下、「第１ユーザ」又は「被保険者」という）が保険の補償を受けるためのプロセスを進行させるとともに補償の請求に関して確認すべき項目を選別して表示する情報処理装置であって、第１端末装置１０、第２端末装置１２及び外部記憶装置１４との通信が可能な情報処理装置である。支援装置１は、所定のプログラムを実行することにより、プロセスを進行させるための各種処理を実行することができる。

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

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

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

ここで、イベント情報を取得してからイベントに対する補償内容を決定するまでの間の一以上のプロセスには、有無責判定、初期対応、損害査定及び補償の付与等が含まれる。

有無責判定とは、支援装置１を管理する者（以下、「保険者」という）が第１ユーザに対して補償を付与することに関して責任を有するか否かを判定するプロセスである。保険者が補償を付与する責任がない（すなわち、無責である）場合とは、例えば、第１ユーザが無免許運転をして事故を起こした場合や、第１ユーザが保険契約の契約期間外に事故を起こした場合等である。

初期対応とは、保険者が損害査定を行うにあたって必要となる情報を第１ユーザから取得するプロセスである。初期対応において取得する情報は、例えば、事故形態、事故の発生場所、入庫先、損害箇所の画像、負傷者の有無等が含まれる。入庫先とは、損害を受けた箇所の修理を依頼する業者等を意味する。

損害査定とは、保険者が第１ユーザに付与する補償の内容（例えば、保険金の支払額）を決定するプロセスである。損害査定においては、例えば、損害箇所の画像に基づいて修理費を推定し、保険金の金額を算出する。

補償の付与とは、損害査定において算出された補償の内容を、保険者が第１ユーザに直接的又は間接的に付与するプロセスである。補償の付与は、例えば、第１ユーザへの保険金の振込、第１ユーザが立て替えた修理費の精算、修理工場への代金の支払及び修理の手配等を含む。

なお、補償内容を決定することとは、第１ユーザへ補償を付与することを決定することのほか、例えば、有無責判定において保険者が無責であると判定すること等、第１ユーザへ補償を付与しないことを決定することも含む。

また、イベント情報とは、第１ユーザが補償を受ける対象であるイベントに関する情報である。例えば、第１ユーザが自動車事故を起こした場合には、第１ユーザが補償を受ける対象は当該自動車事故であるから、イベント情報とは当該自動車事故に関する情報である。イベント情報の具体例については、図３を用いて後述する。

イベントとは、保険請求の対象であり、補償の対象となり得る各種事象である。イベントには、例えば、自動車事故、広域災害（例えば、火災、風災及び水災）、盗難、紛失及び破損等が含まれる。

また、追加情報とは、プロセスを進行させるために支援装置１が第２端末装置１２から取得した情報である。追加情報は、例えば、第１ユーザのイベント情報の修正に関する情報及び第１ユーザの第２ユーザに対するメッセージの応答に関する情報を含む。追加情報の具体例については、図５を用いて後述する。

また、支援装置１がプロセスを進行させることとは、プロセスを完了させるための処理の少なくとも一部を支援装置１により実行することを含む。例えば、プロセスが「情報の取得」、「情報の処理」及び「情報の出力」の３つの未実行のステップを含む場合、プロセスを進行させることとは、これらのステップのうち「情報の取得」を実行することを含む。

また、支援装置１がプロセスを停止させることとは、支援装置１がプロセスを完了させるための処理の少なくとも一部を一時的に停止させることを含む。例えば、プロセスが既に実行した「情報の取得」のステップと、未実行の「情報の処理」及び「情報の出力」のステップとを含む場合、プロセスを停止させることとは、「情報の処理」及び「情報の出力」のステップを実行せずに第２ユーザに通知することを含む。

停止させたプロセスは、第２ユーザの入力（すなわち、追加情報）に応じて復帰させることができる。プロセスを復帰させることとは、停止させたプロセスを再び支援装置１により進行させることである。例えば、「情報の取得」のステップの実行後にプロセスを停止させた場合において、プロセスを復帰させることとは、残りの「情報の処理」及び「情報の出力」のステップを実行することである。プロセスを進行、停止及び復帰させることの具体例については、図２から図５用いて後述する。

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

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

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

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

プロセス情報ＤＢ１０２ａは、プロセス情報を記憶する。プロセス情報は、イベントの補償を決定するために必要な一以上のプロセスと、当該プロセスを進行させるためにイベント情報を含む所定情報が満たすべきプロセス進行条件とに関する情報を含む。プロセス進行条件は、複数の項目と、当該複数の項目のそれぞれに関連付けられた条件を含む。プロセスの具体例については図２を用いて、プロセス進行条件の具体例については図４を用いて後述する。

イベント情報ＤＢ１０２ｂは、支援装置１が取得部１００ａにより第１端末装置１０から取得したイベント情報を記憶する。記憶されたイベント情報は、支援装置１の進行制御部１００ｃにおいてプロセスを進行させるために用いられる。イベント情報の具体例については、図３を用いて後述する。

異常条件ＤＢ１０２ｃは、プロセスを進行させる場合に異常が存在するかを判定する条件である異常条件を記憶する。ここで、本実施形態において「異常」とは、プロセスを正常に進行させるものとは異なる状態を示すことを指し、プロセスの進行が再開可能であることを前提にプロセスの進行が停止となるものを含む。また、異常条件は、複数の項目と、当該複数の項目のそれぞれに関連付けられた条件を含む。異常条件の具体例については、図４を用いて後述する。

異常情報ＤＢ１０２ｄは、プロセスを進行させる場合の異常の有無に関する情報（以下、「異常情報」）を記憶する。異常情報は、異常が存在すると判定されたプロセスにおける異常の内容及び異常への対応に関する情報を含んでもよい。異常情報の具体例については、図６を用いて後述する。

追加情報ＤＢ１０２ｅは、支援装置１が取得部１００ａにより第２端末装置１２から取得した追加情報を記憶する。記憶された追加情報は、支援装置１の進行制御部１００ｃにおいてプロセスを復帰させるために用いられる。追加情報の具体例については、図５を用いて後述する。

外部情報ＤＢ１０２ｆは、支援装置１が取得部１００ａにより外部記憶装置１４から取得した情報（以下、「外部情報」という）を記憶する。記憶された外部情報は、イベント情報とともに支援装置１の進行制御部１００ｃにおいてプロセスを進行又は停止させるために用いられる。外部情報の具体例については、図３を用いて後述する。

制御部１００は、取得部１００ａ、実行判定部１００ｂ、進行制御部１００ｃ、異常判定部１００ｄ、通知部１００ｅ及び通信部１００ｆを含む。

取得部１００ａ（イベント情報取得部）は、第１端末装置１０からイベント情報を取得し、イベント情報ＤＢ１０２ｂに記憶する。イベント情報には、例えば、イベントの発生に関する情報、イベントによる損害の状況に関する情報、補償である保険金の振込先に関する情報、補償の請求意思に関する情報、自動車等の入庫先に関する情報、第１端末装置１０の位置情報等が含まれる。

また、取得部１００ａは、第２端末装置１２から追加情報を取得し、追加情報ＤＢ１０２ｅに記憶する。追加情報は、典型的には、第２ユーザが入力した情報である。すなわち、取得部１００ａは追加情報の入力をユーザから受け付ける受付部としても機能する。

また、取得部１００ａは、外部記憶装置１４から情報を取得し、外部情報ＤＢ１０２ｆに記憶する。外部記憶装置１４は、外部のシステム（例えば、契約システム、応対システム、決裁システム等）の情報を記憶する装置である。外部記憶装置１４から取得される情報とは、例えば、第１ユーザの補償を受ける資格（例えば、契約の状況、免許の有効性等）に関する情報、第１ユーザと第２ユーザとの間で送受信されたメッセージに関する情報及び第１ユーザに対する補償の内容に関する情報等である。

実行判定部１００ｂは、取得されたイベント情報に基づいて、進行制御部１００ｃによるプロセスの進行を開始させるか否かを判定する。典型的には、イベントが定型的なものであり、主にコンピュータで処理できる場合には、「可」と判定する。一方で、イベントが非定型的で複雑な場合には、「否」と判定する。

進行制御部１００ｃは、プロセス情報ＤＢ１０２ａに記憶されたプロセス進行条件に基づいて、プロセスを進行又は停止させる。プロセスの進行及び停止の方法の具体例については、図２から図５を用いて後述する。

異常判定部１００ｄ（判定部）は、異常条件ＤＢ１０２ｃに記憶された異常条件に基づいて、プロセスを進行させる場合に異常が存在するかどうかを判定し、異常が存在する場合にはその結果を異常情報として異常情報ＤＢ１０２ｄに記憶する。

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

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

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

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

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

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

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

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

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

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

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

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

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

＜３．動作例＞
図２から図６を参照して、支援システムの動作の一例を説明する。この例においては、第１ユーザに補償を付与するためのプロセスは有無責判定、初期対応、損害査定及び補償の付与であり、それぞれを第１プロセスから第４プロセスと称する。

この例においては、イベントは自動車事故であり、補償の付与とは保険金の支払であるとする。また、支援装置１及び第２ユーザは保険会社に属し、第１ユーザは当該保険会社が提供する保険の契約をしている者であるとする。

第１ユーザは、事故発生（Ｓ３００）後に保険会社に事故連絡を行い、支援装置１は取得部１００ａによりイベント情報を取得する（Ｓ３０２）。事故連絡は、第１ユーザが保険会社に対して直接（例えば、ｗｅｂフォームの提出及び電話等）連絡を行ってもよく、保険契約の代理店が第１ユーザと保険会社を仲介してもよい。

図３を参照して、支援装置１が取得したイベント情報の一例を示す。イベント情報には「事故形態」、「発生場所」、「入庫先」及び「損害箇所の画像」の項目があり、それぞれ「自動車事故、衝突（単独・対物）」、「国内」、「不明」及び「登録なし」という値が含まれる。

なお、値が「不明」及び「登録なし」である「入庫先」及び「損害箇所の画像」に関しては、事故連絡においては送信されなかったものとする。すなわち、第１ユーザは、事故連絡においては「事故形態」及び「発生場所」に関する情報のみを送信したものとする。

イベント情報を取得した支援装置１は、実行判定部１００ｂにより自動処理実行判定を行う（Ｓ３０４）。自動処理実行判定とは、プロセスの処理を支援装置１により実行するか否かを判定することである。典型的には、定型的な事故であれば自動処理「可」であると判定し、非定型的な事故であれば自動処理「否」であると判定する。

定型的な事故とは、例えば、負傷者がおらず、かつ、第１ユーザによる単独の対物事故等である。非定型的な事故とは、例えば、利害関係人が多い事故、負傷者がいる事故、対人事故及び損害の規模が大きい事故等である。

この例においては、第１ユーザは定型的な事故についての事故連絡を行ったものとする。すなわち、Ｓ３０４では「可」と判定され、支援装置１は第１プロセスの有無責判定を開始する（Ｐ１）。第１プロセスにおいて、支援装置１は、取得部１００ａにより外部記憶装置１４から外部情報を取得する（Ｓ３０６）。

図３を参照して、外部情報の一例を示す。外部情報には「契約の状況」、「免許の有効性」及び「支払額」の項目があり、それぞれ「有効」、「有効」及び「未定」という値が設定されている。以下では、イベント情報及び外部情報を含む情報を「所定情報」という。

「支払額」の項目に関しては、損害査定が第１プロセスにおいては実施されていないため、この時点においては「未定」という値が得られている。

外部記憶装置１４から情報を取得した支援装置１は、進行制御部１００ｃにより進行条件判定を行う（Ｓ３０８）。すなわち、プロセス進行条件に基づいて、プロセスを進行させるか停止させるかの判定を行う。

図３及び図４を参照して、進行条件判定の方法の一例を説明する。図４は、プロセス進行条件及び異常条件の一例を示す図である。プロセス進行条件及び異常条件は、プロセスに属する複数の項目に対応する複数の条件を含む。

プロセスに属する複数の項目とは、典型的には、当該プロセスにおいて判定対象となる項目である。例えば、第１プロセスに属する複数の項目は「事故形態」、「発生場所」、「契約の状況」及び「免許の有効性」の４つの項目であるということができ、第１プロセスから第４プロセスまでのプロセス全体に属する複数の項目は「事故形態」、「発生場所」、「契約の状況」、「免許の有効性」、「入庫先」、「損害箇所の画像」及び「支払額」の７つの項目であるということができる。

また、プロセスに属する複数の項目に対応する複数の条件とは、典型的には、各項目に関連付けられた条件である。例えば、プロセス進行条件においては「事故形態」、「発生場所」、「契約の状況」、「免許の有効性」、「入庫先」、「損害箇所の画像」及び「支払額」の７つの項目のそれぞれに対して、「自動車の対物事故である」、「事故の発生場所が国内である」、「契約が有効である」、「免許が有効である」、「入庫先が判明している」、「応答すべきメッセージが無い」及び「保険金の支払額が３０万円未満である」という条件が関連付けられている。同様に、異常条件においては上記の７つの項目のそれぞれに対して「自動車の対物事故ではない」、「事故の発生場所が国内ではない」、「契約が有効ではない」、「免許が有効ではない」、「回答により入庫先が判明した」、「イベント情報に損害箇所の画像が登録されていない」及び「保険金の支払額が２５万円以上である」という条件が関連づけられている。

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

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

図４によると、第１プロセスの進行条件判定においては「事故形態」、「発生場所」、「契約の状況」及び「免許の有効性」の４つの項目に対応するプロセス進行条件が判定対象となる。図３によると、「事故形態」について取得されたイベント情報は「自動車事故、衝突（単独・対物）」であり、「事故形態」に対応する「自動車の対物事故である」というプロセス進行条件を満たす。また、「発生場所」について取得されたイベント情報は「国内」であり、「発生場所」に対応する「事故の発生場所が国内である」というプロセス進行条件を満たす。また、「契約の状況」について取得された外部情報は「有効」であり、「契約の状況」に対応する「契約が有効である」というプロセス進行条件を満たす。また、「免許の有効性」について取得された外部情報は「有効」であり、「免許の有効性」に対応する「免許が有効である」というプロセス進行条件を満たす。以上をまとめると、所定情報は第１プロセスの複数の項目のそれぞれに関連付けられたプロセス進行条件のすべてを満たしている。

この例においては、進行制御部１００ｃは、所定情報があるプロセスにおける複数の条件のすべてを満たしている場合に当該プロセスを進行させ、複数の条件のいずれか一つ以上を満たしていない場合にプロセスを停止させるものとする。上述した通り、図３に例示した所定情報は第１プロセスにおける複数の項目に関連付けられた条件のすべてを満たすため、進行条件判定（Ｓ３０８）において、支援装置１はプロセスを進行させると判定する。

進行条件判定（Ｓ３０８）の後、支援装置１は、異常判定部１００ｄにより異常条件判定を行う（Ｓ３１０）。すなわち、プロセスを進行させる場合において異常が存在するかどうかを判定する。

図４及び図５を参照して、異常の有無の判定方法の一例を説明する。本実施形態においては、各プロセスにおける異常条件判定は、進行条件判定の判定対象である項目について行うものとする。すなわち、図４によると、第１プロセスの異常条件判定においては、進行条件判定と同様に「事故形態」、「発生場所」、「契約の状況」及び「免許の有効性」の４つの項目に対応する異常条件が判定対象となる。図３によると、「事故形態」について取得されたイベント情報は「自動車事故、衝突（単独・対物）」であり、「事故形態」に対応する「自動車の対物事故ではない」という異常条件を満たさない。また、「発生場所」について取得されたイベント情報は「国内」であり、「発生場所」に対応する「事故の発生場所が国内ではない」という異常条件を満たさない。また、「契約の状況」について取得された外部情報は「有効」であり、「契約の状況」に対応する「契約が有効ではない」という異常条件を満たさない。また、「免許の有効性」について取得された外部情報は「有効」であり、「免許の有効性」に対応する「免許が有効ではない」という異常条件を満たさない。以上をまとめると、所定情報は第１プロセスで判定対象となる複数の項目のそれぞれに関連付けられた異常条件のいずれも満たさない。よって、異常条件判定（Ｓ３１０）の結果、第１プロセスにおいては異常が存在しないと判定する。

このように、異常条件はプロセス進行条件の逆に相当する条件（すなわち、プロセスを停止させる条件）であってもよい。例えば、「自動車の対物事故ではない」という異常条件は、「自動車の対物事故である」というプロセス進行条件の逆に相当する。

進行条件判定（Ｓ３０８）の結果にしたがってプロセスを進行させ、第１プロセスの有無責判定を完了させた後は、第２プロセスである初期対応を開始する（Ｐ２）。第２プロセスにおいて、支援装置１は、第１ユーザに対して事故に関する情報の送信を要求する（Ｓ３１２）。当該要求は、第１端末装置１０にインストールされた専用のアプリケーションソフトウェアを介するものであってもよい。また、当該要求は、事故連絡（Ｓ３０２）で送信されなかった情報に関するものであってもよい。この例においては、要求の内容は、事故連絡（Ｓ３０２）において送信されなかった自動車の入庫先に関する情報を送信させることであるとする。

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

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

回答に関する情報を取得した支援装置１は、進行条件判定を行う（Ｓ３１６）。

図４によると、第２プロセスにおいては「事故形態」及び「入庫先」の項目に対応するプロセス進行条件が判定対象となる。図５によると、「事故形態」について取得されたイベント情報は「自動車事故、衝突（単独・対物）」であり、「事故形態」に対応する「自動車の対物事故である」というプロセス進行条件を満たす。また、「入庫先」について取得されたイベント情報は「○○工場」であり、「入庫先」に対応する「入庫先が判明している」というプロセス進行条件を満たす。よって、所定情報は第２プロセスにおける項目に関連付けられたプロセス進行条件のすべてを満たすため、進行条件判定（Ｓ３１６）において、支援装置１はプロセスを進行させると判定する。

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

進行条件判定（Ｓ３１６）の後、追加情報を受信した支援装置１は、異常判定部１００ｄにより異常条件判定を行う（Ｓ３１８）。図４によると、第２プロセスにおいては、進行条件判定と同様に「事故形態」及び「入庫先」の項目に対応する異常条件が判定対象となる。図５によると、「事故形態」について取得されたイベント情報は「自動車事故、衝突（単独・対物）」であり、「事故形態」に対応する「自動車の対物事故ではない」という異常条件を満たさない。一方で、「入庫先」について取得されたイベント情報は第１ユーザの回答により「○○工場」であると判明している。すなわち、「入庫先」に対応する「回答により入庫先が判明した」という異常条件を満たす。よって、異常条件判定（Ｓ３１８）の結果、第２プロセスにおいては「入庫先」の項目に関して異常が存在すると判定する。異常判定部１００ｄは、当該判定に関する異常情報を異常情報ＤＢ１０２ｄに記憶する。

なお、この場合においても支援装置１は進行条件判定（Ｓ３１６）の結果にしたがってプロセスを進行させる。すなわち、異常はプロセスを停止せざるを得ないものに限らず、プロセスの進行を妨げないものを含む。例えば、異常は、第２ユーザが即座に対応しなくても問題ないが、第１ユーザに補償を付与する前には念のために確認することが推奨される項目に関するものであってもよい。

進行条件判定（Ｓ３１６）の結果にしたがってプロセスを進行させ、第２プロセスである初期対応を完了させた後は、第３プロセスである損害査定を開始する（Ｐ３）。第３プロセスにおいて、支援装置１は、進行条件判定を行う（Ｓ３２０）。

図４によると、第３プロセスにおいては「事故形態」及び「損害箇所の画像」の項目に対応するプロセス進行条件が判定対象となる。図５によると、「事故形態」について取得されたイベント情報は「自動車事故、衝突（単独・対物）」であり、「事故形態」に対応する「自動車の対物事故である」というプロセス進行条件を満たす。一方で、「損害箇所の画像」について取得されたイベント情報は「登録なし」であり、「損害箇所の画像」に対応する「損害箇所の画像が登録されている」というプロセス進行条件を満たさない。よって、所定情報は第３プロセスにおける項目に関連付けられたプロセス進行条件の少なくとも一部を満たさないため、進行条件判定（Ｓ３２０）において、支援装置１はプロセスを停止させると判定する。

プロセスを停止させた支援装置１は、通知部１００ｅにより第２ユーザに対して通知を行う（Ｓ３２２）。通知は、例えば、第２端末装置１２にインストールされた専用アプリケーションソフトウェア、電子メール及び第２端末装置１２表示画面上のポップアップ等により行われる。通知の内容は、典型的には、プロセスを進行させるための所定の対応を指示するものである。

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

通知を受けた第２ユーザは、第１ユーザに対して追加情報の送信を要求する（Ｓ３２４）。この例においては、要求の内容は、損害箇所の画像の送信に関するものである。なお、要求は第１端末装置１０にインストールされた専用のアプリケーションソフトウェアによるもののほか、電子メール及び電話等により行ってもよい。

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

追加情報を取得した第２ユーザは、当該追加情報を支援装置１に送信する（Ｓ３２８）。図５を参照して、追加情報の一例を示す。「損害箇所の画像」の項目について、イベント情報では「登録なし」となっていたところ、追加情報では「損害箇所の画像ファイルの登録あり」となっている。

追加情報を受信した支援装置１は、進行制御部１００ｃにより再度進行条件判定を行う（Ｓ３３０）。「事故形態」に対応するプロセス進行条件については上述したとおり満たしており、さらに、「損害箇所の画像」についての追加情報は「損害箇所の画像ファイルの登録あり」であり、「損害箇所の画像」に対応する「損害箇所の画像が登録されている」というプロセス進行条件を満たしている。よって、図５の所定情報及び追加情報は第３プロセスにおける複数の項目に関連付けられたプロセス進行条件のすべてを満たすため、支援装置１はプロセスを進行させると判定する。

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

この例においては、保険金の支払額は「２５万円」と算出されるものとする。算出された保険金の支払額は、外部情報ＤＢ１０２ｆ及び外部記憶装置１４に記憶する。すなわち、回答に関する情報を取得したあとの外部情報は、「支払額」の項目に対して「２５万円」が含まれる（図５参照）。

支払額の算出（Ｓ３２２）の後、支援装置１は、異常判定部１００ｄにより異常条件判定を行う（Ｓ３３４）。図４によると、第３プロセスにおいては、進行条件判定と同様に「事故形態」及び「損害箇所」の項目に対応する異常条件が判定対象となる。図５によると、「事故形態」について取得されたイベント情報は「自動車事故、衝突（単独・対物）」であり、「事故形態」に対応する「自動車の対物事故ではない」という異常条件を満たさない。一方で、「損害箇所の画像」については追加情報により画像が登録されているが、イベント情報では「登録なし」となっている。すなわち、「損害箇所の画像」に対応する「イベント情報に損害箇所の画像が登録されていない」という異常条件を満たす。よって、異常条件判定（Ｓ３３４）の結果、第３プロセスにおいては「損害箇所の画像」の項目に関して異常が存在すると判定する。異常判定部１００ｄは、当該判定に関する異常情報を異常情報ＤＢ１０２ｄに記憶する。

異常条件判定（Ｓ３３６）の後は、第４プロセスである補償の付与を開始する（Ｐ４）。第４プロセスにおいて、支援装置１は進行条件判定を行う（Ｓ３３６）。

図４によると、第４プロセスにおいては「支払額」の項目に対応する条件が判定対象となる。図５によると、「支払額」について取得された外部情報は「２５万円」であり、「支払額」に対応する「保険金支払額が３０万円未満である」というプロセス進行条件を満たす。よって、所定情報は第４プロセスにおける項目に関連付けられた条件のすべてを満たすため、進行条件判定（Ｓ３３６）において、支援装置１はプロセスを進行させると判定する。

進行条件判定（Ｓ３３６）の後、支援装置１は、異常判定部１００ｄにより異常条件判定を行う（Ｓ３３８）。図４によると、第４プロセスにおいては、進行条件判定と同様に「支払額」の項目に対応する異常条件が判定対象となる。図５によると、「支払額」については取得された外部情報は「２５万円」であり、「支払額」に対応する「保険金支払額が２５万円以上である」という異常条件を満たす。よって、異常条件判定（Ｓ３３８）の結果、第４プロセスにおいては「支払額」の項目に関して異常が存在すると判定する。異常判定部１００ｄは、当該判定に関する異常情報を異常情報ＤＢ１０２ｄに記憶する。

プロセスを進行させる判定がされた後、支援装置１は、第１ユーザに対して請求意思の確認を行う（Ｓ３４０）。

請求意思の確認がされた第１ユーザは、請求意思がある旨の回答を支援装置１に対して行う（Ｓ３４２）。

回答を受信した支援装置１は、第２端末装置１２により承認画面を表示する（Ｓ３４４）。図６を参照して、承認画面の具体例を説明する。承認画面８００には、支払内容表示領域８０２、支払承認ボタン８０４、フィルタリング設定領域８０６、スクロールバー８０８及び異常情報テーブル８１０が含まれる。

支払内容表示領域８０２は、支払額と支払先に関する情報を表示する領域である。この例においては、支払額として第３プロセスで算出（Ｓ３３２）された「２５万円」及び支払先として入庫先である「○○工場」が設定されている。

支払承認ボタン８０４は、押下することにより支払を承認することができるボタンである。

異常情報テーブル８１０は、異常条件判定（Ｓ３１０、Ｓ３１８、Ｓ３３４及びＳ３３８）において異常情報ＤＢ１０２ｄに記憶した異常情報を表示する領域である。この例においては、異常情報テーブル８１０は３つのレコードを有する。各レコードは、異常が存在すると判定されたプロセスに対して、当該プロセスにおける異常の内容が関連付けられている。さらに、当該異常への第２ユーザの対応に関する情報を含んでもよい。なお、第２ユーザの対応とは、例えば、進行制御部１００ｃによるプロセスの停止に対して、第２ユーザが、当該プロセスを進行させるために追加情報を入力することである。

例えば、１行目のレコードは、第２プロセスにおける異常条件判定（Ｓ３１８）において判定された異常情報であり、異常の内容として「『入庫先』に異常が検出されました。ユーザの回答により入庫先が『○○工場』であると判明しました。」と表示し、第２ユーザが行った当該異常への対応として「○○工場に入庫の状況を確認しました。」と表示している。

他にも、例えば、２行目のレコードは、第３プロセスにおける異常条件判定（Ｓ３３４）において判定された異常情報であり、異常の内容として「『損害箇所の画像』に異常が検出されました。イベント情報に損害箇所の画像が登録されていません。」と表示し、第２ユーザが行った当該異常への対応として「担当者が追加情報として画像ファイルを登録しました。」と表示している。このように、異常への対応はプロセスを進行させるための対応であってもよい。

他にも、例えば、３行目のレコードは、第４プロセスにおける異常条件判定（Ｓ３３８）において判定された異常情報であり、異常の内容として「『支払額』に異常が検出されました。支払額が高額（２５万円以上）です。」と表示し、第２ユーザが行った当該異常への対応として「支払額の算出過程に誤りがないことを確認しました。」と表示している。

典型的には、異常情報は、補償内容の付与を実行する画面において表示される。これにより、プロセスを支援装置１に進行させた場合に当該プロセスに異常が存在したかをまとめて確認することができる。

フィルタリング設定領域８０６は、異常情報テーブル８１０に表示されるレコードのフィルタリングの設定が表示される。フィルタリングは、プロセス毎及び項目毎に設定することができる。

プロセス毎のフィルタリングとは、指定したプロセスにおける全ての異常情報を表示することを含む。例えば、プロセスとして「第３プロセス」を指定した場合、第３プロセスにおける異常情報である２行目のレコードのみが表示される。

項目毎のフィルタリングとは、例えば、指定した項目に関する全ての異常情報を表示することを含む。例えば、項目として「入庫先」を指定した場合、「入庫先」の項目に関する異常情報である１行目のレコードのみが表示される。

補償付与に関するプロセスの少なくとも一部が支援装置１により進行される場合であっても、通常は、責任の所在の明確化の観点から、人が目視により補償内容に関する項目を点検した上で補償の付与が実行される。しかしながら、点検すべき項目は多岐に渡る場合も多く、すべての項目を目視により点検することはコストがかかる。そこで、上記実施形態のように異常条件を満たす項目を選別して表示することにより、補償の付与に関する点検を効率化することができる。

承認画面８００により異常情報を確認し、支払を承認することにした第２ユーザは、支払承認ボタン８０４を押下することにより支払を承認する（Ｓ３４６）。

第２ユーザの承認が入力された支援装置１は、保険金の支払を実行する（Ｓ３４８）。この際、支援装置１は支援システムとは異なるシステム（例えば、決裁システム）に支払を実行させてもよい。

以上をまとめると、本実施形態における支援装置１は、保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得部１００ａと、イベント情報を取得してからイベントに対する補償内容を決定するまでの間の一以上のプロセスと、一以上のプロセスのそれぞれについて異常が存在するかどうかを判定するための異常条件と、を記憶する記憶部１０２と、イベント情報を含む所定情報と、異常条件とに基づいて、一以上のプロセスのそれぞれについて異常が存在するか否かを判定する判定部１００ｄと、異常が存在すると判定されたプロセスの進行が完了した場合において、判定部によって、異常が存在すると判定された少なくとも一つのプロセスに関する異常情報を表示する表示部１０４と、を備える。

支援装置１によれば、補償の請求に関して確認すべき項目を選別して表示することができる。例えば、上記の動作例においては、補償の請求に関して取得される情報は「事故形態」、「発生場所」、「契約の状況」、「免許の有効性」、「入庫先」、「損害箇所の画像」及び「支払額」の７つであるところ、補償の付与の段階では異常情報ＤＢ１０２ｄに記憶された「入庫先」、「損害箇所の画像」及び「支払額」に関する項目のみが確認すべき項目として選別して表示される（図６参照）。

また、各項目に対して、異常が発生したプロセス、異常の内容及び異常への対応に関する情報が併せて表示されることにより、第２ユーザが確認すべき内容を容易に把握することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上記実施形態においては、異常情報は補償内容の付与を実行する画面において表示されるものとして説明したが、これに限られない。具体的には、二以上のプロセスを含むグループのすべてのプロセスの進行が完了した場合に、当該グループに含まれるすべてのプロセスに関する異常情報を表示してもよい。例えば、上記実施形態における第１プロセスと第２プロセスを含むグループがあった場合に、グループに含まれる第１プロセスと第２プロセスが完了した時点でこれらのプロセスにおける異常情報を表示してもよい。

これにより、複数のプロセスに関する異常情報をグループ単位でまとめて確認しつつ、補償内容の付与を実行する段階より前にそれまでに検出された異常情報を確認することができる。

上記実施形態においては、異常情報が検出される場合について説明したが、表示部１０４は、異常判定部１００ｄにおいていずれのプロセスにも異常が存在しないと判定された場合、異常が存在しない旨を表示してもよい。

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

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

本発明の一実施形態に係る支援装置１は、保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得部１００ａと、イベント情報を取得してからイベントに対する補償内容を決定するまでの間の一以上のプロセスと、一以上のプロセスのそれぞれについて異常が存在するかどうかを判定するための異常条件と、を記憶する記憶部１０２と、イベント情報を含む所定情報と、異常条件とに基づいて、一以上のプロセスのそれぞれについて異常が存在するか否かを判定する判定部１００ｄと、異常が存在すると判定されたプロセスの進行が完了した場合において、判定部１００ｄによって、異常が存在すると判定された少なくとも一つのプロセスに関する異常情報を表示する表示部１０４と、を備える。

上記態様において、一以上のプロセスは、二以上のプロセスを含むグループを含み、表示部は、グループに含まれるすべてのプロセスの進行が完了した場合に、グループに含まれるすべてのプロセスに関する異常情報を表示してもよい。

上記態様において、表示部１０４は、補償内容の付与を実行する画面において異常情報を表示してもよい。

上記態様において、異常条件は、プロセスに属する複数の項目に対応する複数の条件を含み、判定部１００ｄは、所定情報が複数の条件を満たしているか否かに基づいて、異常が存在するか否かを判定してもよい。

上記態様において、異常情報は、異常が存在すると判定されたプロセスにおける異常の内容を含んでもよい。

上記態様において、表示部は、判定部１００ｄにおいて、一以上のプロセスのいずれにも異常が存在しないと判定された場合、異常が存在しない旨を表示してもよい。

上記態様において、プロセスを進行させるために所定情報が満たすべきプロセス進行条件に基づいて、プロセスを進行又は停止させる進行制御部１００ｃ、をさらに備え、異常条件は、プロセスを停止させる条件を含んでもよい。

上記態様において、進行制御部１００ｃによるプロセスの停止に対して、プロセスを進行させるための追加情報の入力をユーザから受け付ける受付部、をさらに備え、進行制御部１００ｃは、追加情報の入力に基づいてプロセスを進行させてもよい。

上記態様において、異常情報は、追加情報に関する情報を含んでもよい。

本発明の他の一実施形態に係る支援方法は、コンピュータに、保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得ステップと、イベント情報を含む所定情報と、イベント情報を取得してからイベントに対する補償内容を決定するまでの間の一以上のプロセスのそれぞれについて異常が存在するか否かを判定するための異常条件に基づいて、一以上のプロセスのそれぞれについて異常が存在するか否かを判定する判定ステップと、異常が存在すると判定されたプロセスの進行が完了した場合において、判定ステップによって、異常が存在すると判定された少なくとも一つのプロセスに関する異常情報を表示する表示ステップと、を実行させる。

１ 支援装置
１０ 第１端末装置
１２ 第２端末装置
１００ 制御部
１００ａ 取得部
１００ｃ 進行制御部
１００ｄ 異常判定部
１０２ 記憶部
１０４ 表示部

Claims (10)

1. 保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得部と、
   前記イベント情報を取得してから前記イベントに対する補償内容を決定するまでの間の一以上のプロセスと、前記一以上のプロセスのそれぞれについて異常が存在するか否かを判定するための異常条件と、を記憶する記憶部と、
   前記イベント情報を含む所定情報と、前記異常条件とに基づいて、前記一以上のプロセスのそれぞれについて異常が存在するか否かを判定する判定部と、
   前記異常が存在すると判定されたプロセスの進行が完了した場合において、前記判定部によって、前記異常が存在すると判定された少なくとも一つのプロセスに関する異常情報を表示する表示部と、を備える、支援装置。
2. 前記一以上のプロセスは、二以上のプロセスを含むグループを含み、
   前記表示部は、前記グループに含まれるすべてのプロセスの進行が完了した場合に、前記グループに含まれるすべてのプロセスに関する前記異常情報を表示する、請求項１に記載の支援装置。
3. 前記表示部は、補償内容の付与を実行する画面において前記異常情報を表示する、請求項１に記載の支援装置。
4. 前記異常条件は、前記プロセスに属する複数の項目に対応する複数の条件を含み、
   前記判定部は、前記所定情報が前記複数の条件を満たしているか否かに基づいて、異常が存在するか否かを判定する、請求項１に記載の支援装置。
5. 前記異常情報は、前記異常が存在すると判定されたプロセスにおける異常の内容を含む、請求項１に記載の支援装置。
6. 前記表示部は、前記判定部において、前記一以上のプロセスのいずれにも異常が存在しないと判定された場合、前記異常が存在しない旨を表示する、請求項１に記載の支援装置。
7. 前記プロセスを進行させるために前記所定情報が満たすべきプロセス進行条件に基づいて、前記プロセスを進行又は停止させる進行制御部、をさらに備え、
   前記異常条件は、前記プロセスを停止させる条件を含む、請求項１に記載の支援装置。
8. 前記進行制御部による前記プロセスの停止に対して、前記プロセスを進行させるための追加情報の入力をユーザから受け付ける受付部、をさらに備え、
   前記進行制御部は、前記追加情報の入力に基づいて前記プロセスを進行させる、請求項７に記載の支援装置。
9. 前記異常情報は、前記追加情報に関する情報を含む、請求項８に記載の支援装置。
10. コンピュータに、
    保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得ステップと、
    前記イベント情報を含む所定情報と、前記イベント情報を取得してから前記イベントに対する補償内容を決定するまでの間の一以上のプロセスのそれぞれについて異常が存在するか否かを判定するための異常条件に基づいて、前記一以上のプロセスのそれぞれについて異常が存在するか否かを判定する判定ステップと、
    前記異常が存在すると判定されたプロセスの進行が完了した場合において、前記判定ステップによって、前記異常が存在すると判定された少なくとも一つのプロセスに関する異常情報を表示する表示ステップと、を実行させる、支援方法。
    

Images