JP7461238B2 - 保険運用支援装置及び保険運用支援方法 - Google Patents

Description

本発明は、保険運用支援装置及び保険運用支援方法に関する。

人口構成や種々の社会規範、労働環境など、これまで長らく安定していたものが大きな変革期を迎えている。こうした環境下では、疾病や事故、火災といった、これまで豊富な過去データが蓄積されてきた事象だけでなく、他の様々な事象が保険対象として求められることとなった。
このような新たな事象を対象とした保険商品に関する従来技術としては、例えば、離婚届を市町村役場に提出して受理され、離婚成立となった後、支援金を支払うことにより、離婚成立後における生活を経済面から支援する離婚共済への加入を希望する加入希望者の個人情報及び状況に関する加入希望者情報を記録する加入希望者情報ファイルと、該加入希望者の支払う掛金を決定する際に必要となる情報を記録する掛金算出情報ファイルと、決定した掛金の支払に関する掛金支払情報を記録する掛金支払情報ファイルと、該支援金の金額を決定するために必要な情報を記録する支援金額決定必要情報ファイルを含むデータベース部を有し、取得した前記加入希望者情報を、加入希望者毎に関連づけて、前記加入希望者情報ファイルに記録する加入希望者情報処理部と、前記加入希望者情報ファイル及び前記掛金算出情報ファイルから必要な情報を抽出して、前記加入希望者に対し、前記離婚共済への加入を許可するか決定すると共に、前記離婚共済への加入を許可した加入希望者に対する掛金を確定する掛金確定処理部と、前記離婚共済に加入し、掛金を支払った加入者の離婚成立後、取得した離婚理由に関する加入者情報に基づき、前記掛金支払状況情報ファイル、前記支援金額決定必要情報ファイル及び前記加入希望者情報ファイルから必要な情報を抽出し、分析して、該加入者に支払う支援金の金額を決定する支援金額決定処理部を備えていることを特徴とする離婚共済運用システム（特許文献１参照）などが提案されている。

このような従来技術においては、偶発的ではなく、双方の意思の一致と合意の上で成り立つ離婚という出来事に対し、従来の保険業法の定義とは全く異なる新規な離婚成立後における支援制度を効率的に運用することが可能、とされている。

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

上述のように、一般的な保険商品では引受が難しい事象に関して、共済という相互扶助の概念に根ざした仕掛けは提案されている。この従来技術では、対象とする事象発生の有無（上記従来技術では、離婚したか否か）は既に確定し、かつ当該事象に関して公的機関等に確認すれば容易に証明できるため、保険金支払の可否判断はシステムで容易に実行できる。
ところが、そうした事象だけでなく、発生有無等を単純に検証しにくい事象も保険対象とする場合、問題が生じる。

例えば、公共交通機関を利用している通勤、通学の乗客が遭遇する、当該公共交通機関の遅延という事象が該当しうる。当該事象が発生し、乗客らは確かに遅延に巻き込まれたとしても、その事実を公共交通機関側が乗客ごとに把握、管理している訳では無い。

そのため、保険金の支払申請を行う者に関して、当該事象の発生事実が本当にあったのか検証し、保険金の支払可否を的確に判定することは、容易ではない。

このことは、共済という相互扶助の仕組みの中で、保険金支払事由の詐称を容易にし、当該共済の破綻にもつながりかねない。また、当該共済の管理者等が、一般的な保険と同様に保険金支払可否の判断を逐一行うとしても、その負担は大きく、共済規模が大きくなるほど現実的な解とはなりえない。

そこで本発明の目的は、幅広い保険対象に関して、合理的な保険金支払の管理を可能とする技術を提供することにある。

上記課題を解決する本発明の保険運用支援装置は、保険のステークホルダの端末と通信する通信装置と、前記保険の各加入者から集められた掛金の情報である掛金情報を保持した記憶装置と、前記各加入者のうちいずれかである保険金請求者の端末から、前記通信装置を介して保険金請求の通知と当該保険金請求の根拠情報を受信した場合、前記保険金請求の通知及び前記根拠情報を、前記保険金請求者以外の前記加入者である査定者の端末それぞれに配信する処理と、前記査定者の端末から所定期間内に受信した、前記保険金請求に対する賛否情報を集計し、前記査定者のうち所定の割合以上の者が賛意を示している場合、前記記憶装置で保持する前記掛金情報が示す掛金を原資とした、前記保険金請求者に宛てた所定額の保険金支払処理を行う処理と、前記査定者の端末から前記賛否情報を受信したことに応じて、当該査定者に関して所定のインセンティブ値を付与し、当該インセンティブ値の情報を前記記憶装置で保持する処理と、前記保険の契約期間満了に伴い、前記掛金情報が示す掛金残を原資とした、前記各加入者への返戻金の額を、当該加入者に関して蓄積された前記インセンティブ値の大きさに応じて重み付けして算定する処理と、前記各加入者に宛てた前記算定した前記返戻金の支払処理を行う処理と、を実行する演算装置と、を含むことを特徴とする。
また、本発明の保険運用支援方法は、情報処理装置が、保険のステークホルダの端末と通信する通信装置と、前記保険の各加入者から集められた掛金の情報である掛金情報を保持した記憶装置を備えて、前記各加入者のうちいずれかである保険金請求者の端末から、前記通信装置を介して保険金請求の通知と当該保険金請求の根拠情報を受信した場合、前記保険金請求の通知及び前記根拠情報を、前記保険金請求者以外の前記加入者である査定者の端末それぞれに配信する処理と、前記査定者の端末から所定期間内に受信した、前記保険金請求に対する賛否情報を集計し、前記査定者のうち所定の割合以上の者が賛意を示している場合、前記記憶装置で保持する前記掛金情報が示す掛金を原資とした、前記保険金請求者に宛てた所定額の保険金支払処理を行う処理と、前記査定者の端末から前記賛否情報を受信したことに応じて、当該査定者に関して所定のインセンティブ値を付与し、当該インセンティブ値の情報を前記記憶装置で保持する処理と、前記保険の契約期間満了に伴い、前記掛金情報が示す掛金残を原資とした、前記各加入者への返戻金の額を、当該加入者に関して蓄積された前記インセンティブ値の大きさに応じて重み付けして算定する処理と、前記各加入者に宛てた前記算定した前記返戻金の支払処理を行う処理と、を実行することを特徴とする。

本発明によれば、幅広い事象を保険対象として、合理的な保険金支払の管理が可能となる。

本実施形態の保険運用支援装置を含むネットワーク構成図である。 本実施形態の保険運用支援装置のハードウェア構成例を示す図である。 本実施形態のユーザ端末のハードウェア構成例を示す図である。 本実施形態の情報提供システムのハードウェア構成例を示す図である。 本実施形態のユーザＤＢのデータ構成例を示す図である。 本実施形態の保険管理ＤＢのデータ構成例を示す図である。 本実施形態の掛金ＤＢのデータ構成例を示す図である。 本実施形態の運行状況ＤＢのデータ構成例を示す図である。 本実施形態の施設情報ＤＢのデータ構成例を示す図である。 本実施形態の位置履歴情報のデータ構成例を示す図である。 本実施形態における保険運用支援方法のフロー例を示す図である。 本実施形態における画面例を示す図である。 本実施形態における画面例を示す図である。 本実施形態における画面例を示す図である。 本実施形態における保険運用支援方法のフロー例を示す図である。 本実施形態における画面例を示す図である。 本実施形態における画面例を示す図である。 本実施形態における画面例を示す図である。 本実施形態における画面例を示す図である。 本実施形態における画面例を示す図である。 本実施形態における画面例を示す図である。 本実施形態における画面例を示す図である。

＜ネットワーク構成＞
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の保険運用支援装置１００を含むネットワーク構成図である。図１に示す保険運用支援装置１００は、幅広い保険対象に関して、合理的な保険金支払の管理を可能とするコンピュータである。

図１で示すように、本人認証の保険運用支援装置１００は、インターネットなどの適宜なネットワーク１を介して、ユーザ端末２００、及び情報提供システム３００と通信可能に接続されている。

このうちユーザ端末２００は、保険加入者（加入希望者も含みうる）が利用する端末である。また、情報提供システム３００は、保険運用支援装置１００に対し、適宜な情報（根拠情報検証に必要な情報）を提供するサーバ装置である。この情報提供システム３００は、例えば、公共交通機関の運営組織が運用する運行管理システムや、気象予報サービスの提供組織が運用する気象情報提供サーバ、などを想定できる。

こうして、ネットワーク１で接続されて互いに協働しうる、保険運用支援装置１００、ユーザ端末２００、及び情報提供システム３００をもって、保険運用支援システム１０と称するとしてもよい。

一方、保険運用支援装置１００は、従来とは異なる新たな少額短期保険の運用管理を行う情報処理装置である。具体的には、当該少額短期保険を開発、組成し、加入者を集めて運用する、保険会社が運用するサーバ装置を想定する。

ただし、保険運用支援装置１００の運用形態、実装形態は、上記のものに限定はしない。例えば、ユーザ端末２００が保険運用支援装置１００の保持する情報及び機能を適宜に備えた分散台帳ノードとして機能するものである場合、複数のユーザ端末２００と情報提供システム３００がネットワーク１で接続され構成された分散台帳システムが、保険運用支援システム１０と同義となりうる。

この場合、ユーザ端末２００は、保険運用支援装置１００に該当し、処理に必要な情報を、自身の記憶装置の分散台帳で保持、管理する。この場合、それぞれのユーザ端末２００は、自身および他ユーザ端末が発行したトランザクションについて、分散台帳ネットワーク内の各ユーザ端末２００の合意形成を経て、分散台帳に格納することとなる。こうした分散台帳技術に基づく処理については、既存の分散台帳技術を適宜に採用すればよい。
なお、上述のトランザクションは、ユーザ端末２００の各間、及び情報提供システム３００との間で情報を送信する際、当該送信対象の情報に関して発行されるものとなる。

本実施形態では、保険金請求者のユーザ端末２００が発行する、保険金請求者とそれに伴う根拠情報、を含むトランザクションを一例として後に取り上げる。
＜ハードウェア構成：保険運用支援装置＞
また、本実施形態の保険運用支援装置１００のハードウェア構成は、図２に示す如くとなる。すなわち保険運用支援装置１００は、記憶装置１０１、メモリ１０３、演算装置１０４、および通信装置１０５を少なくとも備えている。

このうち記憶装置１０１は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される。

また、メモリ１０３は、ＲＡＭなど揮発性記憶素子で構成される。

また、演算装置１０４は、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵである。なお、プログラム１０２には、ハッシュ関数１０２１が含まれるものとする。

また、通信装置１０５は、ネットワーク１と接続して他装置との通信処理を担うネットワークインターフェイスカードである。

なお、記憶装置１０１内には、本実施形態の保険運用支援装置１００として必要な機能を実装する為のプログラム１０２のほか、ユーザＤＢ１２５、保険管理ＤＢ１２６、及び掛金ＤＢ１２７が少なくとも記憶されている。これら各データベースの詳細については後述する。

また、保険運用支援装置１００は、ユーザからのキー入力や音声入力を受け付ける、キーボードやマウス、マイクなどの入力装置や、演算装置１０４での処理データの表示を行うディスプレイ、スピーカー等の出力装置をさらに備えるとしてもよい。
＜ハードウェア構成：ユーザ端末＞
また、本実施形態のユーザ端末２００のハードウェア構成は、図３に示す如くとなる。すなわちユーザ端末２００は、記憶装置２０１、メモリ２０３、演算装置２０４、入力装置２０５、出力装置２０６、通信装置２０７、撮影ユニット２０８、及びＧＰＳユニット２０９を備えている。

このうち記憶装置２０１は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される。

また、メモリ２０３は、ＲＡＭなど揮発性記憶素子で構成される。

また、演算装置２０４は、記憶装置２０１に保持されるプログラム２０２をメモリ２０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵである。プログラム２０２は、ハッシュ関数２０２１を含むとすれば好適である。

また、入力装置２０５は、ユーザからのキー入力や音声入力を受け付ける、キーボードやマウス、マイクなどの適宜な装置である。

また、出力装置２０６は、演算装置２０４での処理データの表示を行うディスプレイ、スピーカー等の適宜な装置である。

また、通信装置２０７は、ネットワーク１と接続して他装置との通信処理を担うネットワークインターフェイスカードである。

また、撮影ユニット２０８は、スマートフォン等の携帯型端末が一般的に備えるデジタルカメラユニットである。

また、ＧＰＳユニット２０９は、上空のＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）衛星からの測位信号を受信し、本ユーザ端末２００の自機位置を計算する装置である。ＧＰＳユニット２０９で算定した位置情報は、記憶装置２０１の位置履歴情報２２５に蓄積される。

なお、記憶装置２０１内には、本実施形態のユーザ端末２００として必要な機能を実装する為のプログラム２０２に加えて、上述の位置履歴情報２２５が少なくとも記憶されている。この位置履歴情報２２５の詳細については後述する。
＜ハードウェア構成：情報提供システム＞
また、本実施形態の情報提供システム３００のハードウェア構成は、図４に示す如くとなる。すなわち情報提供システム３００は、記憶装置３０１、メモリ３０３、演算装置３０４、および通信装置３０５を備えている。

このうち記憶装置３０１は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される。

また、メモリ３０３は、ＲＡＭなど揮発性記憶素子で構成される。

また、演算装置３０４は、記憶装置３０１に保持されるプログラム３０２をメモリ３０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵである。プログラム３０２は、ハッシュ関数３０２１を含むとすれば好適である。

また、通信装置３０５は、ネットワーク１と接続して他装置との通信処理を担うネットワークインターフェイスカードである。

なお、記憶装置３０１内には、本実施形態の情報提供システム３００として必要な機能を実装する為のプログラム３０２に加えて、運行状況ＤＢ３２５、及び施設情報ＤＢ２６が少なくとも記憶されている。これらデータベースの詳細については後述する。

また、情報提供システム３００は、ユーザからのキー入力や音声入力を受け付ける、キーボードやマウス、マイクなどの入力装置や、演算装置３０４での処理データの表示を行うディスプレイ、スピーカー等の出力装置をさらに備えるとしてもよい。
＜データ構造例＞
続いて、本実施形態の保険運用支援装置１００が用いる情報について説明する。図５に、本実施形態におけるユーザＤＢ１２５の一例を示す。ユーザＤＢ１２５は、本実施形態で想定する少額短期保険の加入者に関する各種情報を蓄積したデータベースである。

そのデータ構造は、加入者を一意に特定する加入者ＩＤをキーとして、当該加入者の氏名、年齢、自宅住所、自宅最寄り駅、勤務地、職場最寄り駅、加入保険の保険ＩＤ、保有端末のＩＤ、及びインセンティブ値といったデータから成るレコードの集合体である。

このユーザＤＢ１２５における各レコードは、当該加入者が当該保険に加入する際にユーザ端末２００から入力し、当該少額短期保険を運用する保険会社で管理している情報を
含むものとなる。なお、上述のインセンティブ値は、当該加入者が、他の加入者からの保険金請求に対して賛否判断を行ったことで得られたインセンティブの値となる。

また、図６に本実施形態における保険管理ＤＢ１２６の一例を示す。保険管理ＤＢ１２６は、上述の少額短期保険に関する各種情報を蓄積したデータベースである。

そのデータ構造は、少額短期保険を一意に特定する保険ＩＤをキーとして、当該保険の名称、種類、契約期間満了日、及び加入者の加入者ＩＤといったデータから成るレコードの集合体である。

また、図７に本実施形態における掛金ＤＢ１２７の一例を示す。掛金ＤＢ１２７は、保険管理ＤＢ１２６で管理する各保険において、各加入者から集めた掛金に関する各種情報を格納したデータベースである。

そのデータ構造は、保険ＩＤをキーとして、現在の掛金残、保険金請求の履歴、及び保険金支払履歴といったデータから成るレコードの集合体である。

また、図８に本実施形態における運行状況ＤＢ３２５の一例を示す。運行状況ＤＢ３２５は、例えば、公共交通機関の運行状況に関する情報を蓄積したデータベースである。

この運行状況ＤＢ３２５は、情報提供システム３００が管理するデータベースである。情報提供システム３００は、保険運用支援装置１００からの要求に応じて、或いは一定期間ごとに、この運行状況ＤＢ３２５の格納情報を保険運用支援装置１００に配信し提供するものとする。

そのデータ構造は、日時情報をキーとして、当該日時において観測された公共交通機関の各路線における運行状況の情報といったデータから成るレコードの集合体である。この運行状況の情報は、遅延発生の有無、遅延の程度、原因、及び公共交通機関の施設を撮影した監視カメラの画像、映像、などを含みうるものとする。

また、図９に本実施形態における施設情報ＤＢ３２６の一例を示す。施設情報ＤＢ３２６は、上述の公共交通機関の施設に関する情報を蓄積したデータベースである。

そのデータ構造は、施設を一意に特定する施設ＩＤをキーとして、当該施設の名称、種類、所在地、路線名、といったデータから成るレコードの集合体である。

また、図１０に本実施形態における位置履歴情報２２５の一例を示す。位置履歴情報２２５は、ユーザ端末２００のＧＰＳユニット２０９が観測した自機位置の座標値を蓄積したデータベースである。

この位置履歴情報２２５は、ユーザ端末２００が管理するデータベースである。ユーザ端末２００は、保険運用支援装置１００からの要求に応じて、或いは一定期間ごとに、この位置履歴情報２２５の格納情報を保険運用支援装置１００に配信し提供するものとする。

そのデータ構造は、日時情報をキーとして、当該日時においてＧＰＳユニット２０９で観測したユーザ端末２００の位置情報から成るレコードの集合体である。
＜フロー例：加入時＞
以下、本実施形態における保険運用支援方法の実際手順について図に基づき説明する。以下で説明する保険運用支援方法に対応する各種動作は、保険運用支援装置１００がメモ
リ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図１１は、本実施形態における保険運用支援方法のフロー例を示す図である。ここでは、少額短期保険の一例として、遅刻補償保険を想定する。

この遅刻補償保険は、公共交通機関により通勤する者すなわち保険加入者が、当該公共交通機関の遅延による遅刻に伴い発生した損害、を補償する就業補償保険である。

ここでの損害とは、例えば、非正規雇用の保険加入者が、上述のような遅延に遭遇した場合、就業時間が短くなることで生じる、収入減を意味する。

なお、遅刻の事由、すなわち保険運用請求事由としては、上述のような公共交通機関の遅延の他、悪天候による外出不可状況の発生、当該保険加入者の体調不良、など様々に想定しうる。

上述の遅刻補償保険への加入を希望する加入希望者は、自身のユーザ端末２００を操作し、保険運用支援装置１００が提供するＷＥＢサイトにアクセスし、保険加入の手続を行う。

この時、ユーザ端末２００は、上述の加入希望者が入力した、当該加入希望者の氏名、自宅住所、自宅最寄り駅、勤務地、職場最寄り駅、の各値を取得（図１２の画面１２００参照）し、これら値とともに、自身のＭＡＣアドレスといった端末ＩＤ（保有端末のＩＤ）を、上述の遅刻補償保険の加入要求として保険運用支援装置１００に送信する。

一方、保険運用支援装置１００は、ユーザ端末２００から、上述の保険加入要求、すなわち加入希望者の各種値と端末ＩＤを受信する（ｓ１０）。保険運用支援装置１００は、このような保険加入要求を、例えば、ある一定期間に複数のユーザ端末２００から受け付けるものとする。

保険運用支援装置１００は、上述のように一定期間に受け付けた保険加入要求から、加入希望者それぞれの属性情報を抽出する（ｓ１１）。属性情報とは、例えば、当該加入希望者の年齢、自宅住所、自宅最寄り駅、職業、勤務地、職場最寄り駅、といったものになる。

また、保険運用支援装置１００は、ｓ１１で抽出した属性情報に基づき、当該遅刻補償保険における保険対象事象、すなわち公共交通機関の遅延の発生リスクを、加入希望者それぞれについて判定する（ｓ１２）。

なお、この発生リスクの判定に際し、保険運用支援装置１００は、例えば、情報提供システム３００から、加入希望者それぞれが利用する路線（自宅最寄り駅から職場最寄り駅を結ぶ路線）における遅延発生事例の情報（運行状況ＤＢ３２５が持つ情報）を取得するものとする。

保険運用支援装置１００は、遅延発生事例の情報から、例えば、直近１年間など所定の期間における遅延発生率を算定し、当該遅延発生率を、当該路線での遅延の発生リスクとする。遅延発生率の値の例としては、０以上１以下の値を想定する。その値が「０」であるとは、当該期間に遅延の発生なし、を意味する。その値が「０．５」であるとは、該当期間の全日数のうち半分の日数で遅延発生、という状態を意味する。また、その値が「１」であるとは、該当期間の全日数のうち全ての日に遅延発生、という状態を意味する。

また、保険運用支援装置１００は、ｓ１２で判定した発生リスクが一定以上の高さの加入希望者と、それ以外の加入希望者とを分類し、それぞれの総数をカウントする（ｓ１３）。例えば、発生リスクが閾値の「０．４」以上の者の数が「２０人」、それ以外の者の数が「１４０人」、などとカウントする。

保険運用支援装置１００は、ｓ１３でカウントした結果に基づき、発生リスクが上述の閾値以上の者の割合が、基準以下となるよう、加入希望者をグルーピングする（ｓ１４）。

例えば、１グループあたり４０人の保険加入者で保険を組成するとの規定が存在し、また、この４０人のうち、上述の発生リスクが高い者の割合上限が「１５％」であると規定されていたとする（当該規定の情報は、保険運用支援装置１００が、記憶装置１０１で予め保持し、利用可能であるものとする）。

この場合、保険運用支援装置１００は、２０＋１４０＝１６０人を、４０人ずつの４グループに分割する場合に、各グループに上述の「２０人」を５人ずつ配分するとした際の、当該発生リスクの高い者の割合を算定する。この例では、５／４０＝０．１２５、つまり１２．５％となり、上限の「１５％」以下である。

こうした算定の結果、各グループでの発生リスクの高い者の割合が上限を超えた場合、保険運用支援装置１００は、例えば、発生リスクが高くない保険加入者の到来を待って、上述の算定を実行することを、発生リスクの高い者の割合が上述の上限以下となるまで繰り返す。勿論、こうした手法は一例であり、発生リスクの高い加入希望者のうち、上述の上限を超える分の人数については、加入待機状態とするなど、他の手法を適宜採用してよい。

上述のグルーピングによるグループ生成を経て、保険運用支援装置１００は、ｓ１４でグループ分けした加入希望者らの保険加入要求について、保険会社で予め規定した加入手続処理を実行し、当該加入希望者の情報を含むレコードを生成し、これをユーザＤＢ１２５において、各グループすなわち各保険の加入者の情報として登録する（ｓ１５）。

この時、保険運用支援装置１００は、上述の遅刻補償保険の保険ＩＤを、当該レコードに設定する。なお、上述のように、同じ遅刻補償保険であっても、加入希望者をグループ分けして組成したため、保険運用支援装置１００は、グループそれぞれで異なる保険ＩＤを生成し設定するものとする。

また、保険運用支援装置１００は、上述の保険ＩＤをキーとして、当該保険の名称、種類、契約期間満了日、及び加入者の加入者ＩＤといったデータから成るレコードを生成して、これを保険管理ＤＢ１２６に格納し（ｓ１６）、処理を終了する（図１３の画面１３００参照）。

なお、この時、保険運用支援装置１００は、上述の加入希望者ごとに加入者ＩＤを生成、付与し、保険管理ＤＢ１２６の該当レコードに設定するものとする。

こうして、遅刻補償保険に関して、それぞれの保険が組成され、当該保険やその保険加入者の各情報が、ユーザＤＢ１２５及び保険管理ＤＢ１２６で対応するレコードとして登録された。

以後、保険加入者は、そのユーザ端末２００を操作し、保険会社指定の手順にて、上述
の保険の掛金の払い込み処理を実行する（図１４の画面１４００参照）。この掛金は、法定通貨であってもよいが、仮想通貨や電子マネー、いわゆるトークンなどであってもよい。後の保険金請求に際し、それが賛否投票により承認された場合、掛金のプールから当該保険金が支払われるが、法定通貨以外で掛金が積み立てされているならば、所定の手続で法定通貨に換金するなどすればよい。

また、保険運用支援装置１００は、上述のように加入者それぞれから集められた、各保険の掛金の情報を、掛金ＤＢ１２７に格納する。掛金の情報としては、当該掛金を支払った保険加入者の加入者ＩＤ、金額、支払日、といった値を含むものとする。
＜フロー例：保険金請求時＞
上述のように、各保険の加入者を登録し、掛金を集めるまでの手順については、従来のように、保険会社が運用する保険運用支援装置１００が中央集権的に実行することが想定できる。

一方、実際に当該保険の運用が開始され、加入者からの保険金請求がなされる段階については、分散台帳システムとして動作しうる、各加入者のユーザ端末２００のネットワークで処理が行われるとして以後の説明を行う。ただし、こうした形態は一例であって、中央集権型の処理を、保険会社のサーバ装置すなわち保険運用支援装置１００が主体となって実行するとしても勿論問題無い。

また、分散台帳システムを構成するユーザ端末２００は、分散台帳ノードとして機能可能なものとする。よって、それぞれのユーザ端末２００は、記憶装置２０１において、分散台帳やスマートコントラクトを保持し、トランザクションの発行、他分散台帳ノードのトランザクションに対する合意形成、当該合意形成を経たトランザクションをブロックに含め、これを分散台帳のブロックチェーンに結合、格納する、といった分散台帳ノードとして一般的な機能を当然に有する。なお、上述のスマートコントラクトは、保険ごとの保険契約で定めた規定の手順を遂行するためのスマートコントラクトとなる。

図１５は、本実施形態における保険運用支援方法のフロー例を示す図である。ここではまず、各加入者のうちいずれかである保険金請求者のユーザ端末２００から、保険金請求の通知と当該保険金請求の根拠情報を受信（図１６の画面１６００参照）したとする（ｓ２０）。

この保険金請求の通知には、対象となる保険の保険ＩＤ、保険金請求者の加入者ＩＤが少なくとも含まれている。また、根拠情報は、保険金請求者が自身のユーザ端末２００で撮影した公共交通機関やその施設の様子の画像データなどを想定する。

この時、ユーザ端末２００は、掛金ＤＢ１２７における当該保険のレコードの、保険金請求履歴の値として、当該保険金請求の通知に関する情報を格納するものとする。

また、ユーザ端末２００は、例えば、掛金ＤＢ１２７のレコードを参照し、上述のｓ２０で受信した保険金請求の通知の対象となる保険と、保険金請求事由が同じ保険（すなわち別の遅刻補償保険）に関するレコードのうち、直近１日や１時間などの一定期間内に行われたものから、加入者ＩＤを抽出する（ｓ２１）。

ユーザ端末２００は、ｓ２１で複数の加入者ＩＤを抽出した場合、それらを照合して、一致するものがあるか判定する（ｓ２２）。この判定の結果、一致する加入者ＩＤが存在しなかった場合（ｓ２３：Ｎ）、処理をｓ２５に進める。

なお、保険運用支援装置１００が中央集権的に処理を主導する形態であれば、上述の判
定の結果の場合、保険運用支援装置１００は、当該保険金請求の通知及び根拠情報を、保険金請求者以外の加入者である査定者のユーザ端末２００それぞれに配信するものとする。

他方、判定の結果、一致する加入者ＩＤが存在した場合（ｓ２３：Ｙ）、ユーザ端末２００は、当該保険金請求者のユーザ端末２００への保険金支払拒否の通知（図１７の画面１７００参照）を実行し（ｓ２４）、処理を終了する。なお、こうしたユーザ端末２００での各処理に際しては、当該処理のトランザクションを分散台帳ネットワークに発行し、各ユーザ端末２００での合意形成を経て、それぞれの分散台帳に格納するものとする（以下同様）。

ｓ２５におけるユーザ端末２００は、上述の保険金請求者のユーザ端末２００から得た根拠情報の検証処理を行う。

ここでユーザ端末２００は、例えば、上述の保険金請求者のユーザ端末２００に対し、当該端末で所定期間に観測した位置情報を要求し取得する。この位置情報は、位置履歴情報２２５で保持していたものである。

続いて、ユーザ端末２００は、上述の根拠情報が示す保険金請求事由の発生場所（例：施設名やその座標値、或いは住所）及び発生時期の各情報に基づき、その保険金請求事由の発生時期に、保険金請求者のユーザ端末２００で観測された位置情報が、保険金請求事由の発生場所と一致するか判定する（ｓ２６）。

この判定の結果、保険金請求者のユーザ端末２００における位置情報が、根拠情報の示す発生場所と一致する場合（ｓ２６：Ｙ）、ユーザ端末２００は、当該トランザクションを分散台帳ネットワークに発行し、合意形成を経た上で、分散台帳に格納する。この時、各ユーザ端末２００は、保険金請求者のユーザ端末２００における位置情報が、根拠情報の示す発生場所と一致する旨の情報を、出力装置で表示（ｓ２７）し、査定者の閲覧に供する。

なお、保険運用支援装置１００が処理を主導する場合、保険運用支援装置１００は、当該根拠情報が信頼性を有する旨の通知（図１８の画面１８００参照）を、査定者のユーザ端末２００それぞれに行う。

一方、上述の判定の結果、上述の位置情報が発生場所と一致しない場合（ｓ２６：Ｎ）、ユーザ端末２００は、当該トランザクションを分散台帳ネットワークに発行し、合意形成を経た上で、分散台帳に格納し、処理を終了する。この時、各ユーザ端末２００は、保険金請求者のユーザ端末２００における位置情報が、根拠情報の示す発生場所と一致しない旨の情報を、出力装置で表示し（ｓ２８）、査定者の閲覧に供する。

なお、保険運用支援装置１００が処理を主導する場合、保険運用支援装置１００は、保険金請求に伴う根拠情報が信頼性を有しない旨の通知（図１９の画面１９００参照）を、査定者のユーザ端末２００それぞれに配信する。

なお、根拠情報の検証処理として別の形態も想定しうる。その場合、保険金請求の通知及び根拠情報を受信したユーザ端末２００は、その根拠情報をハッシュ関数１０２１に入力してハッシュ値を算定する。また、ユーザ端末２００は、当該ハッシュ値を当該保険金請求の保険ＩＤと紐付け、記憶装置２０１の分散台帳に格納する。

ユーザ端末２００は、こうした処理を保険金請求ごとに行うとともに、これ以降、新た
な保険金請求に関して受信した根拠情報について同様にハッシュ値を算定し、分散台帳で過去の保険金請求に関して保持しているハッシュ値と照合する。

上述の照合の結果、過去の保険金請求に関するハッシュ値に同じものが特定されなかった場合、ユーザ端末２００は、当該トランザクションを分散台帳ネットワークに発行し、合意形成を経た上で、分散台帳に格納する。

この時、各ユーザ端末２００は、当該新たな保険金請求に関する根拠情報が信頼性を有する旨の情報を出力装置で表示し、査定者の閲覧に供する。

なお、保険運用支援装置１００が処理を主導する場合、保険運用支援装置１００は、当該新たな保険金請求に関する根拠情報が信頼性を有する旨の通知を、査定者のユーザ端末２００それぞれに配信する。

一方、上述の照合の結果、過去の保険金請求に関するハッシュ値に同じものが特定された場合、ユーザ端末２００は、当該トランザクションを分散台帳ネットワークに発行し、合意形成を経た上で、分散台帳に格納する。

この時、各ユーザ端末２００は、当該新たな保険金請求に関する根拠情報が信頼性を有しない旨の情報を出力装置で表示し、査定者の閲覧に供する。

なお、保険運用支援装置１００が処理を主導する場合、保険運用支援装置１００は、当該新たな保険金請求に関する根拠情報が信頼性を有しない旨の通知を、査定者のユーザ端末２００それぞれに配信する。

続いて、ユーザ端末２００は、例えば、保険金請求を受信した日から２日、など所定期間内において、査定者のユーザ端末２００から、上述の保険金請求に対する賛否情報を受信する（ｓ２９）。

このように、各加入者のユーザ端末２００は、査定者のユーザ端末２００から賛否情報を受信したことに応じて、当該査定者に関して所定のインセンティブ値を付与し、当該インセンティブ値の情報を、記憶装置２０１のユーザＤＢ１２５で保持するものとする。

なお、査定者のうちいずれかの者のユーザ端末２００から、上述の保険金請求者に宛てた、根拠情報の追加要求を受けた場合、ユーザ端末２００は、当該追加要求を保険金請求者のユーザ端末２００に通知（図２０の画面２０００参照）する。

この場合、ユーザ端末２００は、上述の追加要求に応じて、保険金請求者のユーザ端末２００から追加の根拠情報を受信して、当該追加の根拠情報を、査定者のユーザ端末２００それぞれに配信する。

また、ユーザ端末２００は、査定者のユーザ端末２００から所定期間内に受信した、上述の保険金請求に対する賛否情報を集計し、査定者のうち所定の割合以上の者が賛意を示しているか判定する（ｓ３０）。こうした賛否情報の集計および判定は、スマートコントラクトにより実行する。

上述の判定の結果、査定者のうち所定の割合より少ないものしか賛意を示す者がいない場合（ｓ３１：Ｎ）、ユーザ端末２００は、保険金支は拒否するとの決定を行い、当該トランザクションを分散台帳ネットワークに発行し、合意形成を経た上で、分散台帳に格納する。この時、各ユーザ端末２００は、当該拒否の決定の旨の情報を出力装置で表示（図
２１の画面２１００）し（ｓ３２）、少なくとも保険金請求者の閲覧に供する。

なお、保険運用支援装置１００が処理を主導する場合、保険運用支援装置１００は、当該拒否の決定の通知を、保険金請求者のユーザ端末２００に配信する。

他方、上述の判定の結果、査定者のうち所定の割合以上の者が賛意を示している場合（ｓ３１：Ｙ）、ユーザ端末２００は、当該保険金請求が承認されたと認定し、当該トランザクションを分散台帳ネットワークに発行し、合意形成を経た上で、分散台帳に格納する。この時、各ユーザ端末２００は、当該承認の決定の旨の情報を出力装置で表示（図２２の画面２２００）し（ｓ３３）、少なくとも保険金請求者の閲覧に供する。

なお、保険運用支援装置１００が処理を主導する場合、保険運用支援装置１００は、当該承認の決定の通知を、保険金請求者のユーザ端末２００に配信する。

また、これにあわせて、ユーザ端末２００は、記憶装置２０１の掛金ＤＢ１２７で保持する当該保険の掛金情報が示す掛金を原資として、当該保険金請求者に宛てた所定額の保険金支払処理を行う。この保険金支払処理は、一般的な保険金支払処理を、金融機関が提供するネットバンキングサービスを利用して行うといった、既知の技術を適宜に採用すればよい。また、支払原資となる掛金が法定通貨以外のもので、保険会社や分散台帳基盤で運用されている電子通貨であれば、単純に掛金のプールから保険金請求者への該当額の資産移動が処理されることになる。

なお、ユーザ端末２００（ないし保険運用支援装置１００）は、上述の保険の契約期間満了を、保険管理ＤＢ１２６の値で監視し、契約期間満了が到来した場合、掛金ＤＢ１２７の掛金情報が示す掛金残を原資とした、各加入者への返戻金の額を、当該加入者に関して蓄積されたインセンティブ値（ユーザＤＢ１２５で参照）の大きさに応じて重み付けして算定する。そしてユーザ端末２００は、各加入者に宛てた当該返戻金の額の支払処理を行うものとする。このように、賛否判断の行為に応じ、返戻金の額が変わってくるのであれば、査定者におけるモチベーションにつながる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、幅広い保険対象に関して、合理的な保険金支払の管理が可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の保険運用支援装置において、前記演算装置は、前記査定者の端末から前記賛否情報を受信したことに応じて、当該査定者に関して所定のインセンティブ値を付与し、当該インセンティブ値の情報を前記記憶装置で保持する処理と、前記保険の契約期間満了に伴い、前記掛金情報が示す掛金残を原資とした、前記各加入者への返戻金の額を、当該加入者に関して蓄積された前記インセンティブ値の大きさに応じて重み付けして算定する処理と、前記各加入者に宛てた前記算定した前記返戻金の支払処理を行う処理と、をさらに実行するものである、としてもよい。

これによれば、保険の各加入者が、保険金請求に対する賛否投票を行う上でモチベーションを持ちやすくなり、賛否情報の収集が迅速、容易となる効果が期待できる。ひいては、幅広い保険対象に関して、より合理的な保険金支払の管理が可能となる。

また、本実施形態の保険運用支援装置において、前記演算装置は、前記査定者のうちい
ずれかの者の端末から、前記保険金請求者に宛てた、根拠情報の追加要求を受けて、当該追加要求を前記保険金請求者の端末に通知する処理と、前記追加要求に応じて前記保険金請求者の端末から追加の根拠情報を受信した場合、当該追加の根拠情報を前記査定者の端末それぞれに配信する処理と、をさらに実行するものである、としてもよい。

これによれば、保険金請求者が提示した根拠情報が不完全であったり、或いは別の観点やリソースからの情報が必要であるといった事態に対応し、査定者にとって賛否の判断に必要な情報を確実に取得、提供しやすくなる効果を期待できる。ひいては、幅広い保険対象に関して、より合理的な保険金支払の管理が可能となる。

また、本実施形態の保険運用支援装置において、前記演算装置は、前記保険金請求者の端末から、当該端末で所定期間に観測した位置情報を取得する処理と、前記根拠情報が示す保険金請求事由の発生場所及び発生時期の各情報に基づき、前記保険金請求事由の発生時期に前記端末で観測された前記位置情報が、前記保険金請求事由の発生場所と一致するか判定する処理と、前記判定の結果、前記位置情報が前記発生場所と一致する場合、前記根拠情報が信頼性を有する旨の通知を前記査定者の端末それぞれに行う処理と、をさらに実行するものである、としてもよい。

これによれば、根拠情報の確からしさについて検証して、その結果を査定者に知らしめることができる。こうした検証に成功した、すなわち当該根拠情報の信頼性が担保されたことは、査定者それぞれにおける賛否判断の大きな助けとなる。ひいては、幅広い保険対象に関して、より合理的な保険金支払の管理が可能となる。

また、本実施形態の保険運用支援装置において、前記演算装置は、前記判定の結果、前記位置情報が前記発生場所と一致しない場合、前記配信の回避、及び前記保険金請求に伴う前記根拠情報が信頼性を有しない旨の通知を前記査定者の端末それぞれに配信する処理、の少なくともいずれかの処理をさらに実行するものである、としてもよい。

これによれば、根拠情報の確からしさについて検証して、その結果を査定者に知らしめることができる。こうした検証に失敗した、すなわち当該根拠情報の信頼性が否定されたことは、査定者それぞれにおける賛否判断の大きな助けとなる。ひいては、幅広い保険対象に関して、より合理的な保険金支払の管理が可能となる。

また、本実施形態の保険運用支援装置において、前記演算装置は、前記根拠情報のハッシュ値を算定し、当該ハッシュ値を前記保険金請求と紐付けて前記記憶装置に格納する処理と、当該処理の以降、新たな保険金請求に関して受信した根拠情報についてハッシュ値を算定し、前記記憶装置で過去の保険金請求に関して保持しているハッシュ値と照合する処理と、前記照合の結果、過去の保険金請求に関するハッシュ値に同じものが特定されなかった場合、前記新たな保険金請求に関する前記根拠情報が信頼性を有する旨の通知を、前記査定者の端末それぞれに行う処理と、をさらに実行するものである、としてもよい。

これによれば、加入者自身が撮影した画像を、当該加入者のみが、１つの保険に関してのみ、保険金請求の根拠情報として使用している正しい状況を確認し、これを査定者に知らしめることができる。

こうして査定者が、根拠情報の信頼性が担保されたことを認識することは、査定者それぞれにおける賛否判断の大きな助けとなる。ひいては、幅広い保険対象に関して、より合理的な保険金支払の管理が可能となる。

また、本実施形態の保険運用支援装置において、前記演算装置は、前記照合の結果、過
去の保険金請求に関するハッシュ値に同じものが特定された場合、前記配信の回避、及び前記根拠情報が信頼性を有しない旨の通知を前記査定者の端末それぞれに行う処理、の少なくともいずれかの処理をさらに実行するものである、としてもよい。

これによれば、同じ根拠情報（例：ネット上で掲載されている報道画像であって、加入者自身で撮影していないもの等）が複数の加入者により使い回しされている事態や、同一加入者が、異なる保険それぞれに同じ根拠情報を使って保険金請求を行っている事態（例：同一の保険対象に関する複数の保険に、同一人物がそれぞれ加入し、１つの保険金請求事由を使い回して多くの保険金を多重に詐取しようとしている事態）、を的確に検知し、これを査定者に知らしめることができる。こうして査定者が、根拠情報の信頼性が否定されたことを認識することは、査定者それぞれにおける賛否判断の大きな助けとなる。

また、不適切な根拠情報を伴う保険金請求については、そもそも当該情報を査定者の端末に配信せず、すなわち賛否判断の対象とすることなく処理を終了してしまうとすれば、査定者の負担を効果的に抑制することにつながる。

ひいては、幅広い保険対象に関して、より合理的な保険金支払の管理が可能となる。

また、本実施形態の保険運用支援装置において、前記記憶装置は、複数の保険それぞれについて、当該各加入者から集められた掛金の情報である掛金情報を保持し、前記演算装置は、所定の保険金請求者の端末から、一定期間内に、複数の保険に関して、同じ保険金請求事由に基づく保険金請求の通知を受信した場合、前記配信の回避、及び当該保険金請求者の端末への前記保険金支払処理の拒否通知、の少なくともいずれかの処理をさらに実行するものである、としてもよい。

これによれば、同一加入者が、異なる保険それぞれに保険金請求を行っている事態（例：同一の保険対象に関する複数の保険に、同一人物がそれぞれ加入し、一度の保険請求事由の発生に伴い、多くの保険金を多重に詐取しようとしている事態）、を的確に検知し、不適切な保険金請求であるとして、当該保険金請求に関する情報を査定者の端末に配信せず、すなわち賛否判断の対象とすることなく処理を終了してしまうとすれば、査定者の負担を効果的に抑制することにつながる。また、そうした不適切な保険金請求を行った者に対し、手続自体を拒絶する意向を明示することで、以後の不適切行為の牽制効果も期待できる。

ひいては、幅広い保険対象に関して、より合理的な保険金支払の管理が可能となる。

また、本実施形態の保険運用支援装置において、前記演算装置は、保険の加入希望者それぞれの端末から、前記通信装置を介して保険加入要求を受信し、当該保険加入要求が示す、前記加入希望者それぞれの属性情報に基づき、当該保険の保険対象事象の発生リスクを前記加入希望者それぞれについて判定する処理と、前記判定した発生リスクが一定以上の高さの者の割合が基準以下となるよう、加入希望者をグルーピングする処理と、前記グルーピングされた加入希望者を加入者とした保険を組成し、当該加入者それぞれから集められた掛金の情報を前記掛金情報に格納する処理と、をさらに実行するものである、としてもよい。

これによれば、保険対象となる事象の発生リスクが同じように高い者を集めて保険を組成し、当該事象が発生した場合に、一斉に保険金請求が行われて当該保険が破綻する、といった事態を回避しやすくなる。このことは、保険運用を安定的に継続できることにつながり、かつ、各加入者からの保険金請求に的確に応じることも可能となる。

ひいては、幅広い保険対象に関して、より合理的な保険金支払の管理が可能となる。

１ ネットワーク
１０ 保険運用支援システム
１００ 保険運用支援装置
１０１ 記憶装置
１０２ プログラム
１０２１ ハッシュ関数
１０３ メモリ
１０４ 演算装置
１０５ 通信装置
１２５ ユーザＤＢ
１２６ 保険管理ＤＢ
１２７ 掛金ＤＢ
２００ ユーザ端末
２０１ 記憶装置
２０２ プログラム
２０２１ ハッシュ関数
２０３ メモリ
２０４ 演算装置
２０５ 入力装置
２０６ 出力装置
２０７ 通信装置
２０８ 撮影ユニット
２０９ ＧＰＳユニット
２２５ 位置履歴情報
３００ 情報提供システム
３０１ 記憶装置
３０２ プログラム
３０２１ ハッシュ関数
３０３ メモリ
３０４ 演算装置
３０５ 通信装置
３２５ 運行状況ＤＢ
３２６ 施設情報ＤＢ

Claims (9)

1. 保険のステークホルダの端末と通信する通信装置と、
   前記保険の各加入者から集められた掛金の情報である掛金情報を保持した記憶装置と、
   前記各加入者のうちいずれかである保険金請求者の端末から、前記通信装置を介して保険金請求の通知と当該保険金請求の根拠情報を受信した場合、前記保険金請求の通知及び前記根拠情報を、前記保険金請求者以外の前記加入者である査定者の端末それぞれに配信する処理と、前記査定者の端末から所定期間内に受信した、前記保険金請求に対する賛否情報を集計し、前記査定者のうち所定の割合以上の者が賛意を示している場合、前記記憶装置で保持する前記掛金情報が示す掛金を原資とした、前記保険金請求者に宛てた所定額の保険金支払処理を行う処理と、前記査定者の端末から前記賛否情報を受信したことに応じて、当該査定者に関して所定のインセンティブ値を付与し、当該インセンティブ値の情報を前記記憶装置で保持する処理と、前記保険の契約期間満了に伴い、前記掛金情報が示す掛金残を原資とした、前記各加入者への返戻金の額を、当該加入者に関して蓄積された前記インセンティブ値の大きさに応じて重み付けして算定する処理と、前記各加入者に宛てた前記算定した前記返戻金の支払処理を行う処理と、を実行する演算装置と、
   を含むことを特徴とする保険運用支援装置。
2. 前記演算装置は、
   前記査定者のうちいずれかの者の端末から、前記保険金請求者に宛てた、根拠情報の追加要求を受けて、当該追加要求を前記保険金請求者の端末に通知する処理と、前記追加要求に応じて前記保険金請求者の端末から追加の根拠情報を受信した場合、当該追加の根拠情報を前記査定者の端末それぞれに配信する処理と、をさらに実行するものである、
   ことを特徴とする請求項１に記載の保険運用支援装置。
3. 前記演算装置は、
   前記保険金請求者の端末から、当該端末で所定期間に観測した位置情報を取得する処理と、前記根拠情報が示す保険金請求事由の発生場所及び発生時期の各情報に基づき、前記保険金請求事由の発生時期に前記端末で観測された前記位置情報が、前記保険金請求事由の発生場所と一致するか判定する処理と、前記判定の結果、前記位置情報が前記発生場所と一致する場合、前記根拠情報が信頼性を有する旨の通知を前記査定者の端末それぞれに行う処理と、をさらに実行するものである、
   ことを特徴とする請求項１に記載の保険運用支援装置。
4. 前記演算装置は、
   前記判定の結果、前記位置情報が前記発生場所と一致しない場合、前記配信の回避、及び前記保険金請求に伴う前記根拠情報が信頼性を有しない旨の通知を前記査定者の端末それぞれに配信する処理、の少なくともいずれかの処理をさらに実行するものである、
   ことを特徴とする請求項３に記載の保険運用支援装置。
5. 前記演算装置は、
   前記根拠情報のハッシュ値を算定し、当該ハッシュ値を前記保険金請求と紐付けて前記記憶装置に格納する処理と、当該処理の以降、新たな保険金請求に関して受信した根拠情報についてハッシュ値を算定し、前記記憶装置で過去の保険金請求に関して保持しているハッシュ値と照合する処理と、前記照合の結果、過去の保険金請求に関するハッシュ値に同じものが特定されなかった場合、前記新たな保険金請求に関する前記根拠情報が信頼性
   を有する旨の通知を、前記査定者の端末それぞれに行う処理と、をさらに実行するものである、
   ことを特徴とする請求項１に記載の保険運用支援装置。
6. 前記演算装置は、
   前記照合の結果、過去の保険金請求に関するハッシュ値に同じものが特定された場合、前記配信の回避、及び前記根拠情報が信頼性を有しない旨の通知を前記査定者の端末それぞれに行う処理、の少なくともいずれかの処理をさらに実行するものである、
   ことを特徴とする請求項５に記載の保険運用支援装置。
7. 前記記憶装置は、
   複数の保険それぞれについて、当該各加入者から集められた掛金の情報である掛金情報を保持し、
   前記演算装置は、
   所定の保険金請求者の端末から、一定期間内に、複数の保険に関して、同じ保険金請求事由に基づく保険金請求の通知を受信した場合、前記配信の回避、及び当該保険金請求者の端末への前記保険金支払処理の拒否通知、の少なくともいずれかの処理をさらに実行するものである、
   ことを特徴とする請求項１に記載の保険運用支援装置。
8. 前記演算装置は、
   保険の加入希望者それぞれの端末から、前記通信装置を介して保険加入要求を受信し、当該保険加入要求が示す、前記加入希望者それぞれの属性情報に基づき、当該保険の保険対象事象の発生リスクを前記加入希望者それぞれについて判定する処理と、前記判定した発生リスクが一定以上の高さの者の割合が基準以下となるよう、加入希望者をグルーピングする処理と、前記グルーピングされた加入希望者を加入者とした保険を組成し、当該加入者それぞれから集められた掛金の情報を前記掛金情報に格納する処理と、をさらに実行するものである、
   ことを特徴とする請求項１に記載の保険運用支援装置。
9. 情報処理装置が、
   保険のステークホルダの端末と通信する通信装置と、前記保険の各加入者から集められた掛金の情報である掛金情報を保持した記憶装置を備えて、
   前記各加入者のうちいずれかである保険金請求者の端末から、前記通信装置を介して保険金請求の通知と当該保険金請求の根拠情報を受信した場合、前記保険金請求の通知及び前記根拠情報を、前記保険金請求者以外の前記加入者である査定者の端末それぞれに配信する処理と、
   前記査定者の端末から所定期間内に受信した、前記保険金請求に対する賛否情報を集計し、前記査定者のうち所定の割合以上の者が賛意を示している場合、前記記憶装置で保持する前記掛金情報が示す掛金を原資とした、前記保険金請求者に宛てた所定額の保険金支払処理を行う処理と、
   前記査定者の端末から前記賛否情報を受信したことに応じて、当該査定者に関して所定のインセンティブ値を付与し、当該インセンティブ値の情報を前記記憶装置で保持する処理と、前記保険の契約期間満了に伴い、前記掛金情報が示す掛金残を原資とした、前記各加入者への返戻金の額を、当該加入者に関して蓄積された前記インセンティブ値の大きさに応じて重み付けして算定する処理と、前記各加入者に宛てた前記算定した前記返戻金の支払処理を行う処理と、
   を実行することを特徴とする保険運用支援方法。

Images