特開 2024-25830 支援装置および支援方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024025830

(43)【公開日】2024-02-26

(54)【発明の名称】支援装置および支援方法

(51)【国際特許分類】

   G06Q 40/08 20120101AFI20240216BHJP

【ＦＩ】

G06Q40/08

【審査請求】未請求

【請求項の数】13

【出願形態】ＯＬ

(21)【出願番号】P 2023218781

(22)【出願日】2023-12-26

(62)【分割の表示】P 2022128867の分割

【原出願日】2022-08-12

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】595140170

【氏名又は名称】東京海上日動火災保険株式会社

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】高野 勝匡

(72)【発明者】

【氏名】小野川 和秀

(72)【発明者】

【氏名】小林 佑

(72)【発明者】

【氏名】田中 優太

(72)【発明者】

【氏名】川上 希帆

(72)【発明者】

【氏名】渡辺 雅代

(72)【発明者】

【氏名】戸所 あゆみ

(72)【発明者】

【氏名】山端 浩之

(57)【要約】

【課題】補償の付与を効率化することができる支援装置及び支援方法を提供する。
【解決手段】支援装置１は、第１端末装置から保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得部１００ａと、イベントに対する補償内容を決定するために必要な一以上のプロセスと、プロセスを進行させるためにイベント情報を含む所定情報が満たすべきプロセス進行条件と、を含むプロセス情報を記憶する記憶部１０２と、プロセス進行条件に基づいて、プロセスを進行又は停止させる進行制御部１００ｃと、進行制御部によるプロセスの停止に応答して、第１端末装置とは異なる第２端末装置に通知する通知部１００ｄと、通知を受けた第２端末装置からプロセスを進行させるための追加情報を取得する追加情報取得部１００ａと、を備え、進行制御部１００ｃは、追加情報に基づいて、プロセスを進行させる。
【選択図】図１

【特許請求の範囲】

【請求項1】

第１端末装置から保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得部と、
前記イベントに対する補償内容を決定するために必要な一以上のプロセスと、前記プロセスを進行させるために前記イベント情報を含む所定情報が満たすべきプロセス進行条件と、を含むプロセス情報を記憶する記憶部と、
前記プロセス進行条件に基づいて、前記プロセスを進行又は停止させる進行制御部と、
前記進行制御部による前記プロセスの停止に応答して、前記第１端末装置とは異なる第２端末装置に通知する通知部と、
前記通知を受けた前記第２端末装置から前記プロセスを進行させるための追加情報を取得する追加情報取得部と、
を備え、
前記進行制御部は、前記追加情報に基づいて、前記プロセスを進行させる、支援装置。

【請求項2】

前記プロセス進行条件は、前記プロセスに属する複数の項目に対応する複数の条件を含み、
前記進行制御部は、前記所定情報が前記複数の条件を満たしているか否かに基づいて、前記プロセスを進行又は停止させる、請求項１に記載の支援装置。

【請求項3】

前記進行制御部は、前記所定情報が前記複数の条件のすべてを満たしている場合に前記プロセスを進行させ、前記複数の条件のいずれか一つ以上を満たしていない場合に前記プロセスを停止させる、請求項２に記載の支援装置。

【請求項4】

前記追加情報は、前記複数の条件のうち、前記所定情報が満たしていない条件に関する情報である、請求項２に記載の支援装置。

【請求項5】

前記追加情報は、前記進行制御部が前記追加情報に基づいて進行するプロセスを指定するプロセス指定情報を含む、請求項１に記載の支援装置。

【請求項6】

前記プロセス指定情報は、前記進行制御部が停止させたプロセスと同一のプロセスを指定する情報である、請求項５に記載の支援装置。

【請求項7】

前記プロセス指定情報は、前記進行制御部が停止させたプロセスとは異なるプロセスを指定する情報である、請求項５に記載の支援装置。

【請求項8】

前記所定情報に基づいて、前記イベント情報に不正が存在する旨を検知する不正検知部、をさらに備え、
前記プロセス進行条件は、前記不正検知部によって不正が存在する旨が検知されないという条件を含む、請求項１に記載の支援装置。

【請求項9】

前記不正検知部は、前記イベント情報に不正が存在するリスクの数値が所定閾値以上の大きさを示す場合に不正が存在する旨を検知する、請求項８に記載の支援装置。

【請求項10】

前記一以上のプロセスは、第１プロセスと、前記第１プロセス以降の第２プロセスとを含み、
前記不正検知部は、前記第１プロセスの段階で行われる第１不正検知部と、前記第２プロセスの段階で行われ、かつ、前記第１不正検知部よりも不正検知の信頼性が高い第２不正検知部とを含む、請求項８に記載の支援装置。

【請求項11】

前記イベントは自動車に関する事故である、請求項１から請求項１０のいずれか一項に記載の支援装置。

【請求項12】

前記一以上のプロセスは、前記第１端末装置のユーザが補償の付与対象であるか否かを判定する有無責判定と、前記イベント情報を取得する初期対応と、前記補償を決定する損害査定と、前記補償を前記第１端末装置のユーザに付与する補償付与との少なくともいずれかを含む、請求項１から請求項１０のいずれか一項に記載の支援装置。

【請求項13】

コンピュータに、
第１端末装置から保険請求の対象であるイベントに関するイベント情報を取得する取得ステップと、
前記イベントに対する補償内容を決定するために必要な一以上のプロセスを進行させるために前記イベント情報を含む所定情報が満たすべきプロセス進行条件に基づいて、前記プロセスを進行又は停止させる進行制御ステップと、
前記進行制御ステップによる前記プロセスの停止に応答して、前記第１端末装置とは異なる第２端末装置に通知する通知ステップと、
前記通知を受けた前記第２端末装置から前記プロセスを進行させるための追加情報を取得する追加情報取得ステップと、
を実行させ、
前記進行制御ステップは、前記追加情報に基づいて、前記プロセスを進行させる、支援方法。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００３－０３０４４１号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

保険金請求などに関わる補償内容によっては、受付から支払までの手順の少なくとも一部はコンピュータによる定型的な処理を実行できず、人による介入が必要な場合がある。しかしながら、特許文献１に記載されたシステムでは、人による介入が必要な場合、補償の付与を効率良く処理することができない。

【0005】

そこで、本発明は、上記課題に鑑み、補償の付与を効率化することを目的とする。

【課題を解決するための手段】

【0006】

本発明の一態様に係る支援装置は、第１端末装置から保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得部、イベントに対する補償内容を決定するために必要な一以上のプロセスと、プロセスを進行させるためにイベント情報を含む所定情報が満たすべきプロセス進行条件と、を含むプロセス情報を記憶する記憶部と、プロセス進行条件に基づいて、プロセスを進行又は停止させる進行制御部と、進行制御部によるプロセスの停止に応答して、第１端末装置とは異なる第２端末装置に通知する通知部と、通知を受けた第２端末装置からプロセスを進行させるための追加情報を取得する追加情報取得部と、を備え、進行制御部は、追加情報に基づいて、プロセスを進行させる。

【0007】

本発明の他の一態様に係る支援方法は、コンピュータに、第１端末装置から保険請求の対象であるイベントに関するイベント情報を取得する取得ステップと、イベントに対する補償内容を決定するために必要な一以上のプロセスを進行させるためにイベント情報を含む所定情報が満たすべきプロセス進行条件に基づいて、プロセスを進行又は停止させる進行制御ステップと、進行制御ステップによるプロセスの停止に応答して、第１端末装置とは異なる第２端末装置に通知する通知ステップと、通知を受けた第２端末装置からプロセスを進行させるための追加情報を取得する追加情報取得部と、を実行させ、進行制御ステップは、追加情報に基づいて、プロセスを進行させる。

【発明の効果】

【0008】

本発明によれば、補償の付与を効率化することができる。

【図面の簡単な説明】

【0009】

【図1】本実施形態に係るシステムの機能構成の一例を説明するための図である。

【図2】本実施形態に係るシステムの動作の一例を説明するための図である。

【図3】本実施形態に係るシステムの動作の一例を説明するための図である。

【図4】本実施形態に係るシステムの動作の一例を説明するための図である。

【図5】本実施形態に係るシステムの動作の一例を説明するための図である。

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

【発明を実施するための形態】

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

また、取得部１００ａ（追加情報取得部）は、第２端末装置１２から追加情報を取得し、追加情報ＤＢ１０２ｃに記憶する。追加情報は、典型的には、第２ユーザが入力した情報である。

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

不正検知部１００ｅは、イベント情報及び外部情報を含む情報に基づいて、イベント情報に不正が存在する旨を検知する。不正が存在する場合とは、例えば、実際には補償を受ける対象であるイベントが発生していないにも関わらず補償が請求される場合等である。

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【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】

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

【0095】

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

【0096】

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

【0097】

第１ユーザから回答を得た支援装置１は、保険金の支払を実行する（Ｓ３３４）。この際、支援装置１は支援システムとは異なるシステム（例えば、決裁システム）に支払を実行させてもよい。

【0098】

以上をまとめると、本実施形態における支援装置１は、第１端末装置から保険請求の対象であるイベントに関するイベント情報を取得するイベント情報取得部１００ａと、イベントに対する補償内容を決定するために必要な一以上のプロセスと、プロセスを進行させるためにイベント情報を含む所定情報が満たすべきプロセス進行条件と、を含むプロセス情報を記憶する記憶部１０２と、プロセス進行条件に基づいて、プロセスを進行又は停止させる進行制御部１００ｃと、進行制御部によるプロセスの停止に応答して、第１端末装置とは異なる第２端末装置に通知する通知部１００ｄと、通知を受けた第２端末装置からプロセスを進行させるための追加情報を取得する追加情報取得部１００ａと、を備え、進行制御部１００ｃは、追加情報に基づいて、プロセスを進行させる。

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【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】

１ 支援装置
１０ 第１端末装置
１２ 第２端末装置
１００ 制御部
１００ａ 取得部
１００ｃ 進行制御部
１００ｄ 通知部
１００ｅ 不正検知部
１０２ 記憶部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】