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

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

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

(11)【公開番号】P2024029996

(43)【公開日】2024-03-07

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

(51)【国際特許分類】

   G06Q 40/08 20120101AFI20240229BHJP

【ＦＩ】

G06Q40/08

【審査請求】有

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2022132511

(22)【出願日】2022-08-23

(11)【特許番号】

(45)【特許公報発行日】2023-04-07

【公序良俗違反の表示】

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

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

(71)【出願人】

【識別番号】595140170

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

(74)【代理人】

【識別番号】100079108

【弁理士】

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

(74)【代理人】

【識別番号】100109346

【弁理士】

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

(74)【代理人】

【識別番号】100117189

【弁理士】

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

(74)【代理人】

【識別番号】100134120

【弁理士】

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

(72)【発明者】

【氏名】高野 勝匡

(72)【発明者】

【氏名】小野川 和秀

(72)【発明者】

【氏名】小林 佑

(72)【発明者】

【氏名】田中 優太

(72)【発明者】

【氏名】川上 希帆

(72)【発明者】

【氏名】渡辺 雅代

(72)【発明者】

【氏名】戸所 あゆみ

(72)【発明者】

【氏名】山端 浩之

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055BB61

(57)【要約】

【課題】損害の種別に応じたプロセスを構成する支援装置及び支援方法を提供する。
【解決手段】本発明の一実施形態に係る支援装置１は、保険請求の対象であるイベントに関するイベント情報を取得する取得部１００ａと、イベントの補償を決定するために必要な複数のプロセスと、イベントがプロセスの対象となるためにイベント情報を含む所定情報が満たすべき対象条件と、プロセスを進行させるために所定情報が満たすべき進行条件とを含むプロセス情報を記憶する記憶部１０２と、複数のプロセスのそれぞれに対して、対象条件に基づいてイベントが当該プロセスの対象であるか否かを判定する対象判定部１００ｄと、複数のプロセスのそれぞれに対して、対象判定部１００ｄによってイベントが当該プロセスの対象であると判定されたことに応じて、進行条件に基づいて当該プロセスを進行又は停止させるかを判定する進行判定部１００ｅと、を備える。
【選択図】図２

【特許請求の範囲】

【請求項1】

保険請求の対象であるイベントに関するイベント情報を取得する取得部と、
前記イベントの補償を決定するために必要な複数のプロセスと、前記イベントが前記プロセスの対象となるために前記イベント情報を含む所定情報が満たすべき対象条件と、前記プロセスを進行させるために前記所定情報が満たすべき進行条件とを含むプロセス情報を記憶する記憶部と、
前記複数のプロセスのそれぞれに対して、前記対象条件に基づいて前記イベントが当該プロセスの対象であるか否かを判定する対象判定部と、
前記複数のプロセスのそれぞれに対して、前記対象判定部によって前記イベントが当該プロセスの対象であると判定されたことに応じて、前記進行条件に基づいて当該プロセスを進行又は停止させるかを判定する進行判定部と、
を備える、支援装置。

【請求項2】

前記イベント情報は、前記イベントの損害の種別に関する情報を含み、
前記対象条件及び前記進行条件は、前記イベントの損害の種別毎に前記記憶部に記憶され、
前記対象判定部及び前記進行判定部のそれぞれは、前記損害の種別に対応する前記対象条件及び前記進行条件に基づいて判定する、請求項１に記載の支援装置。

【請求項3】

前記損害の種別が第１種別に対応する前記対象条件は、前記第１種別とは異なる第２種別に対応する前記対象条件と少なくとも一部において共通し、
前記第１種別に対応する前記進行条件は、前記第２種別に対応する前記進行条件と少なくとも一部において共通する、請求項２に記載の支援装置。

【請求項4】

前記複数のプロセスは、第１プロセス及び第２プロセスを含み、
前記第１プロセスに関する対象条件は、前記第２プロセスに関する対象条件と少なくとも一部において共通し、
前記第１プロセスに関する進行条件は、前記第２プロセスに関する進行条件と少なくとも一部において共通する、請求項１に記載の支援装置。

【請求項5】

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

【請求項6】

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

【請求項7】

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

【請求項8】

前記取得部は、第１端末装置から前記イベント情報を取得するものであり、
前記支援装置は、
前記進行判定部による前記プロセスの停止に応答して、前記第１端末装置とは異なる第２端末装置に通知する通知部、
をさらに備え、
前記取得部は、前記通知を受けた前記第２端末装置から前記プロセスを進行させるための追加情報を取得し、
前記進行判定部は、前記追加情報に基づいて、前記プロセスを進行させる、請求項１に記載の支援装置。

【請求項9】

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

【請求項10】

コンピュータに、
保険請求の対象であるイベントに関するイベント情報を取得する取得ステップと、
前記イベントの補償を決定するために必要な複数のプロセスのそれぞれに対して、前記イベントが前記プロセスの対象となるために前記イベント情報を含む所定情報が満たすべき対象条件に基づいて、前記イベントが当該プロセスの対象であるか否かを判定する対象判定ステップと、
前記複数のプロセスのそれぞれに対して、前記対象判定ステップによって前記イベントが当該プロセスの対象であると判定されたことに応じて、前記プロセスを進行させるために前記所定情報が満たすべき進行条件に基づいて当該プロセスを進行又は停止させるかを判定する進行判定ステップと、
を実行させる、支援方法。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

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

【0005】

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

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

【0006】

本発明の一態様に係る支援装置は、保険請求の対象であるイベントに関するイベント情報を取得する取得部と、イベントの補償を決定するために必要な複数のプロセスと、イベントがプロセスの対象となるためにイベント情報を含む所定情報が満たすべき対象条件と、プロセスを進行させるために所定情報が満たすべき進行条件とを含むプロセス情報を記憶する記憶部と、複数のプロセスのそれぞれに対して、対象条件に基づいてイベントが当該プロセスの対象であるか否かを判定する対象判定部と、複数のプロセスのそれぞれに対して、対象判定部によってイベントが当該プロセスの対象であると判定されたことに応じて、進行条件に基づいて当該プロセスを進行又は停止させるかを判定する進行判定部と、を備える。

【0007】

本発明の他の一態様に係る支援方法は、コンピュータに、保険請求の対象であるイベントに関するイベント情報を取得する取得ステップと、イベントの補償を決定するために必要な複数のプロセスのそれぞれに対して、イベントがプロセスの対象となるためにイベント情報を含む所定情報が満たすべき対象条件に基づいて、イベントが当該プロセスの対象であるか否かを判定する対象判定ステップと、複数のプロセスのそれぞれに対して、対象判定ステップによってイベントが当該プロセスの対象であると判定されたことに応じて、プロセスを進行させるために所定情報が満たすべき進行条件に基づいて当該プロセスを進行又は停止させるかを判定する進行判定ステップと、を実行させる。

【発明の効果】

【0008】

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

【図面の簡単な説明】

【0009】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【手続補正書】

【提出日】2022-12-20

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

損害保険請求の対象であるイベントに関するイベント情報を、前記損害保険請求を行うユーザの端末装置から取得する取得部と、
前記取得部により前記イベント情報を取得する初期対応、前記ユーザが損害保険による補償の対象であるか否かを判定する有無責判定及び前記補償の内容を決定する損害査定を含む複数のプロセスと、前記イベントが前記プロセスの対象となるために前記イベント情報を含む所定情報が満たすべき対象条件と、前記プロセスを進行させるにあたって前記損害保険請求に係る担当者による介入が必要ではないと判定するために前記所定情報が満たすべき進行条件とを含むプロセス情報を記憶する記憶部と、
前記複数のプロセスのそれぞれに対して、前記対象条件に基づいて前記イベントが当該プロセスの対象であるか否かを判定する対象判定部と、
前記複数のプロセスのそれぞれに対して、前記対象判定部によって前記イベントが当該プロセスの対象であると判定されたことに応じて、前記進行条件に基づいて当該プロセスを進行又は停止させるかを判定する進行判定部と、
を備える、支援装置。

【請求項2】

前記イベント情報は、前記イベントの損害の種別に関する情報を含み、
前記対象条件及び前記進行条件は、前記イベントの損害の種別毎に前記記憶部に記憶され、
前記対象判定部及び前記進行判定部のそれぞれは、前記損害の種別に対応する前記対象条件及び前記進行条件に基づいて判定する、請求項１に記載の支援装置。

【請求項3】

前記損害の種別が第１種別に対応する前記対象条件は、前記第１種別とは異なる第２種別に対応する前記対象条件と少なくとも一部において共通し、
前記第１種別に対応する前記進行条件は、前記第２種別に対応する前記進行条件と少なくとも一部において共通する、請求項２に記載の支援装置。

【請求項4】

前記複数のプロセスは、第１プロセス及び第２プロセスを含み、
前記第１プロセスに関する対象条件は、前記第２プロセスに関する対象条件と少なくとも一部において共通し、
前記第１プロセスに関する進行条件は、前記第２プロセスに関する進行条件と少なくとも一部において共通する、請求項１に記載の支援装置。

【請求項5】

前記複数のプロセスのそれぞれにおいて、前記イベント情報と、前記イベントの実際の状況とが整合するか否かに基づいて、前記イベント情報に不正が存在する旨を検知する不正検知部、をさらに備え、
前記進行条件は、前記不正検知部によって不正が存在する旨が検知されないという条件を含む、請求項１に記載の支援装置。

【請求項6】

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

【請求項7】

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

【請求項8】

前記支援装置は、
前記進行判定部による前記プロセスの停止に応答して、前記担当者の端末装置に通知する通知部、をさらに備え、
前記取得部は、前記通知を受けた前記担当者の端末装置から前記プロセスを進行させるための追加情報を取得し、
前記進行判定部は、前記追加情報に基づいて、前記プロセスを進行させる、請求項１に記載の支援装置。

【請求項9】

コンピュータに、
損害保険請求の対象であるイベントに関するイベント情報を、前記損害保険請求を行うユーザの端末装置から取得する取得ステップと、
前記取得ステップにより前記イベント情報を取得する初期対応、前記ユーザが損害保険による補償の対象であるか否かを判定する有無責判定及び前記補償の内容を決定する損害査定を含む複数のプロセスのそれぞれに対して、前記イベントが前記プロセスの対象となるために前記イベント情報を含む所定情報が満たすべき対象条件に基づいて、前記イベントが当該プロセスの対象であるか否かを判定する対象判定ステップと、
前記複数のプロセスのそれぞれに対して、前記対象判定ステップによって前記イベントが当該プロセスの対象であると判定されたことに応じて、前記プロセスを進行させるにあたって前記損害保険請求に係る担当者による介入が必要ではないと判定するために前記所定情報が満たすべき進行条件に基づいて当該プロセスを進行又は停止させるかを判定する進行判定ステップと、
を実行させる、支援方法。