JP2023177173A - 保険請求システム、保険請求方法、および保険請求プログラム - Google Patents

Abstract

【課題】被保険者がデジタル通貨のアカウント管理業務をカストディ業者に委託する場合において、保険査定のエビデンスに対する正当性を担保しつつ、デジタル通貨のサイバー保険に対する保険金請求を査定する。
【解決手段】端末装置が保険請求を提出すると、保険請求査定装置が保険請求を受け付けた後でアカウント所有証明の提出を要求し、端末装置はアカウント管理装置を介してアカウント所有証明トークンを発行し、そのトークンを被保険者のアカウントから保険会社のアカウントに移転し、保険請求査定装置は被保険者の保険対象アカウント所有証明を検証し、決済装置の取引履歴を元に保険金支払の可否を判断し、損害と保険金を算出する。
【選択図】図１３

Description

本発明は、電子的な決済を行う保険請求システム、保険請求方法、および保険請求プログラムに関する。

金融分野における技術革新やキャッシュレス化の進展により、世界各国の中央銀行や金融機関がデジタル通貨の研究開発に取り組んでいる。

デジタル通貨とは、コンピュータシステムでデジタル化された通貨であり、インターネット上で管理・保存・交換されるものである。デジタル通貨には、中央銀行の債務として発行された法定通貨である中央銀行デジタル通貨、民間企業が発行する電子マネー、ブロックチェーンのアルゴリズムを活用した暗号資産などが含まれる。

デジタル通貨は、経済活動のデジタル化を支える新たな決済インフラとして期待されている。モバイルデバイスやクラウドの普及により、様々な経済主体やモノ・サービスとの間に新しい接点や組合せが創出された。Eコマースやシェアリングエコノミーのようなバーチャル空間での経済活動が拡大している。また、カーボンフットプリントのように、リアル空間での経済活動との繋がりも生まれている。これらの経済圏で金流を担うのがデジタル通貨である。

デジタル通貨システムの運用形態として、様々なモデルが提唱されている。例えば、デジタル通貨の発行体がシステムを中央集権的に管理するモデル、デジタル通貨の発行と流通を行う複数の企業で構成されたコンソーシアムがシステムを分散管理するモデル、不特定多数の企業や個人がシステムを非中央集権的に管理するモデルが知られている。

消費者や一般企業のようなデジタル通貨の利用者は、ＰＣやモバイルデバイスに搭載されたアプリケーションを利用してデジタル通貨システムにアクセスする。デジタル通貨はブロックチェーン技術を活用しているため、決済を行う際は、利用者の秘密鍵でトランザクションに電子署名を行う。

デジタル通貨が新たな決済手段として社会に受容されるには、利便性だけでなく、安全性を確保することが求められる。まず、システムの品質向上やセキュリティ対策により、サイバー事故や不正取引を未然に防ぐ必要がある。ただし、システムである以上、全ての問題を事前に予測して対処することはできない。そのため、事後的な対策として、デジタル通貨システムのサイバー事故や不正取引に起因する損害を補償するサイバー保険も必要となる。

デジタル通貨向けのサイバー保険について、保険商品の料率を計算する技術として、例えば特許文献1が知られている。このシステムでは、デジタル通貨とユーザの関係をツリー構造で表現し、デジタル通貨がサイバー攻撃を受けた場合、その被害がどのように伝搬するか複数のシナリオでシミュレーションして、その損害の総和でリスクを評価し、保険料率を計算する。

ＵＳ２０２１０２５６６２３

上記特許文献１では、保険商品の料率について計算しているが、保険請求を査定して保険金を支払うことについての記載はない。被保険者は、自身が保有する様々な種類のデジタル通貨を保険対象とし、保証期間と保証金額を設定して保険契約を締結する。補償対象は、デジタル通貨システムのプログラムに対する脆弱性攻撃やハッキングである場合が多いが、被保険者がデジタル通貨の秘密鍵を紛失すると、保険金は支払われないこととなる。

デジタル通貨のサイバー事故で損失が発生した場合、被保険者は保険請求とエビデンスを提出する。エビデンスは、デジタル通貨の秘密鍵を現在も安全に管理していること、すなわち、アカウントの所有証明である。保険会社では、被保険者の請求情報とデジタル通貨システムから収集した取引履歴を分析し、サイバー事故が保険契約期間中に発生したこと、および、被保険者がデジタル通貨の秘密鍵を現在も所有していることを検証できた場合、支払事由に該当すると判断し、保険金を支払う。

保険請求を査定し、保険金を支払うシステムを構築する場合、不特定多数の企業や個人が参加するパブリック型ブロックチェーン上で動作させることも可能である。被保険者は、デジタル通貨の秘密鍵を管理しているため、被保険者自身がアカウント所有証明を提出で、また、被保険者はデジタル通貨システムの取引履歴も参照できるため、保険会社が査定に利用したエビデンスを直接参照し、査定結果の妥当性を確認できる。

しかしながら、不特定多数の企業や個人がパブリック型ブロックチェーン上でデジタル通貨システムを非中央集権的に運用する形態を対象としているため、承認された特定の組織グループがプライベート型ブロックチェーン上でデジタル通貨システムを分散管理する形態には対応できないという問題があった。

プライベートブロックチェーンでデジタル通貨システムを運用する場合、サイバー保険を利用する被保険者と保険会社の間に情報の非対称性が存在する。

このような運用形態の場合、利用者はカストディを経由してデジタル通貨システムにアクセスするため、デジタル通貨のアカウント所有証明や取引履歴といったエビデンスに直接アクセスできない。デジタル通貨の秘密鍵を安全に管理するには、高度な専門知識が求められる。その負荷を軽減するため、被保険者は秘密鍵およびアカウントの管理を銀行などのカストディに委託する。被保険者がデジタル通貨システムに直接アクセスできないため、被保険者自身がアカウント所有証明を保険会社に提出できない。また、保険会社が査定に利用した取引履歴を確認できないので、査定結果の妥当性を判断できない。

なお、カストディはデジタル通貨の決済を行う業務機能を備えているが、デジタル通貨の保険請求を行う業務機能は備えていない。

一方、保険会社はデジタル通貨システムの参加組織として取引履歴を収集できるが、カストディのシステムにはアクセスできない。そのため、被保険者の秘密鍵が安全に管理されているのか、すなわち、アカウントの所有証明を検証できない。

つまり、デジタル通貨向けサイバー保険の保険請求業務では、エビデンスを収集・検証するプロセスにおいて被保険者と保険会社が相互に信用できないという課題がある。その結果、保険査定のエビデンスに対する正当性を担保できない。

そこで本発明は、上記問題点に鑑みてなされたもので、被保険者がデジタル通貨のアカウント管理業務をカストディ業者に委託する場合において、保険査定のエビデンスに対する正当性を担保しつつ、デジタル通貨のサイバー保険に対する保険金請求を査定することが可能な技術を提供することを目的とする。

本発明にかかる保険請求システムは、端末装置と、アカウント管理装置と、決済装置と、保険請求査定装置と、を有する保険請求システムであって、それぞれの装置は、プロセッサとメモリとを有し、前記端末装置のプロセッサは、第１のプログラムを実行して、ユーザから入力されたデジタル通貨の保険請求手続きに関する保険請求情報を、前記保険請求査定装置に出力し、前記保険請求査定装置のプロセッサは、第２のプログラムを実行して、前記保険請求情報に含まれる、前記ユーザのアカウントを識別するためのアカウント識別情報により識別されるユーザが被保険者としてアカウントを所有していることを証明するためのアカウント所有証明の提出を、前記端末装置に要求し、前記端末装置のプロセッサは、前記第１のプログラムを実行して、前記アカウント所有証明の発行要求を、前記アカウント管理装置に出力し、前記アカウント管理装置のプロセッサは、第３のプログラムを実行して、前記保険請求情報に含まれる、前記デジタル通貨の保険契約を識別するための保険契約識別情報と前記アカウント識別情報と前記デジタル通貨を識別するためのデジタル通貨識別情報とを用いて生成した、前記被保険者を所有者とする前記アカウント所有証明のトークンの発行要求を前記決済装置に出力し、前記決済装置のプロセッサは、第４のプログラムを実行して、前記トークンを識別するためのトークン識別情報と前記トークンの値と前記トークンの所有者とを対応付けた第１のテーブルに、前記発行要求を受けた前記トークンを追加し、当該追加した結果をトークン発行取引結果として前記アカウント管理装置に出力し、前記アカウント管理装置のプロセッサは、前記第３のプログラムを実行して、前記トークン発行取引結果に対して、前記追加した前記トークンの所有者を保険会社とする移転要求を前記決済装置に出力し、前記決済装置のプロセッサは、前記第４のプログラムを実行して、前記第１のテーブルに追加された前記トークンの所有者を前記保険会社に更新し、当該更新した結果をトークン移転取引結果として前記アカウント管理装置に出力し、前記アカウント管理装置のプロセッサは、前記第３のプログラムを実行して、前記決済装置から前記トークン移転取引結果を受け取ると、前記アカウント所有証明の発行完了を前記端末装置に出力し、前記端末装置のプロセッサは、前記第１のプログラムを実行して、前記アカウント所有証明の発行完了に基づいて、前記アカウント所有証明の提出完了を前記保険請求査定装置に出力し、前記保険請求査定装置のプロセッサは、第５のプログラムを実行し、前記保険契約識別情報により識別される保険契約情報を管理する第２のテーブルと、前記通貨識別情報により識別されるデジタル通貨についての事故情報を管理する第３のテーブルとを用いて、前記保険請求情報に基づく保険請求に対する査定を行う、ことを特徴とする保険請求システムとして構成される。

本発明によれば、被保険者がデジタル通貨のアカウント管理業務をカストディ業者に委託する場合において、保険査定のエビデンスに対する正当性を担保しつつ、デジタル通貨のサイバー保険に対する保険金請求を査定することができる。

本明細書において開示される主題の、少なくとも一つの実施の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。

本実施例を示し、保険請求システムの装置構成の一例を示すブロック図である。 本実施例を示し、端末装置の一例を示すブロック図である。 本実施例を示し、アカウント管理装置の一例を示すブロック図である。 本実施例を示し、決済装置の一例を示すブロック図である。 本実施例を示し、保険請求査定装置の一例を示すブロック図である。 本実施例を示し、ウォレットテーブルの一例を示す図である。 本実施例を示し、デジタル通貨取引履歴テーブルの一例を示す図である。 本実施例を示し、アカウント所有証明トークン管理テーブルの一例を示す図である。 本実施例を示し、アカウント所有証明トークン取引履歴テーブルの一例を示す図である。 本実施例を示し、保険契約テーブルの一例を示す図である。 本実施例を示し、請求テーブルの一例を示す図である。 本実施例を示し、事故情報テーブルの一例を示す図である。 本実施例を示し、保険請求システムの装置間の処理フローの一例を示すシーケンス図である。 本実施例を示し、端末装置で実行される保険請求プログラムの一例を示すフローチャートである。 本実施例を示し、アカウント管理装置で実行される証明書発行プログラムの一例を示すフローチャートである。 本実施例を示し、決済装置で実行されるアカウント所有証明トークンプログラムの一例を示すフローチャートである。 本実施例を示し、保険請求査定装置で実行される請求管理プログラムの一例を示すフローチャートである。 本実施例を示し、保険請求査定装置で実行されるエビデンス収集プログラムの一例を示すフローチャートである。 本実施例を示し、保険請求査定装置で実行される損害査定プログラムの一例を示すフローチャートである。

以下、本発明の実施形態を添付図面に基づいて説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

すなわち、以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。

図面において示す各構成要素の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面に開示された位置、大きさ、形状、範囲などに限定されない。

以下の説明では、「データベース」、「テーブル」、「リスト」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いた場合、これらについてはお互いに置換が可能である。

同一あるいは同様な機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。

また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）および／またはインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であれば良く、特定の処理を行う専用回路（例えばＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）やＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ））を含んでいてもよい。

プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

図１は、本発明の実施例を示し、保険請求を受け付けて査定を行う査定システムである保険請求システムの装置構成の一例を示すブロック図である。本実施例の保険請求システムは、デジタル通貨向けサイバー保険の保険金請求業務において、端末装置が保険請求を提出すると、保険請求査定装置が保険請求を受け付けた後で、保険対象となる被保険者についてのアカウントの所有証明であるアカウント所有証明の提出を要求する。端末装置は、アカウント管理装置を介してアカウント所有証明トークンを発行し、そのトークンを被保険者のアカウントから保険会社のアカウントに移転する。保険請求査定装置は、上記アカウント所有証明を検証し、決済装置の取引履歴を元に保険金支払の可否を判断し、損害と保険金を算出する。

保険請求システム１００は、保険請求を行うユーザが用いる端末装置２００と、カストディが有するアカウント管理装置３００と、銀行などの金融機関や保険会社など、所定の審査を経て許可された企業や団体がアクセス可能な決済システム４０００と、保険請求査定装置５００と、を含む。決済システム４０００は、当該決済システムの構成員である企業や団体が有する１または複数台の決済装置４００を含む。

＜端末装置＞
図２は、端末装置２００の一例を示すブロック図である。端末装置２００は、メモリ２０１と、演算装置２０２と、入力装置２０３と、出力装置２０４と、通信装置２０５と、ストレージ装置２０６を含む計算機である。
ストレージ装置２０６には、保険請求処理を行う保険請求プログラム１４００が格納される。

入力装置２０３は、例えば、キーボードやマウスあるいはタッチパネルで構成される。出力装置２０４は、例えば、ディスプレイなどで構成される。通信装置２０５は、ネットワークに接続されて、他の計算機と通信を行う。

保険請求プログラム１４００は、メモリ２０１にロードされて演算装置２０２によって実行される。
演算装置２０２は、例えば、プロセッサであり、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、演算装置２０２は、保険請求プログラム１４００に従って処理を実行することで保険請求部として機能する。さらに、演算装置２０２は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

＜アカウント管理装置＞
図３は、アカウント管理装置３００の一例を示すブロック図である。アカウント管理装置３００は、メモリ３０１と、演算装置３０２と、入力装置３０３と、出力装置３０４と、通信装置３０５と、ストレージ装置３０６を含む計算機である。

ストレージ装置３０６には、被保険者の秘密鍵を管理するウォレットテーブル６００と、アカウント所有証明トークンの発行や移転を実行する証明書発行プログラム１５００が格納される。

入力装置３０３は、例えば、キーボードやマウスあるいはタッチパネルで構成される。出力装置３０４は、例えば、ディスプレイなどで構成される。通信装置３０５は、ネットワークに接続されて、他の計算機と通信を行う。

証明書発行プログラム１５００は、メモリ３０１にロードされて演算装置３０２によって実行される。
演算装置３０２は、例えば、プロセッサであり、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、演算装置３０２は、証明書発行プログラム１５００に従って処理を実行することで証明書発行部として機能する。さらに、演算装置３０２は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

＜決済装置＞
図４は、決済装置４００の一例を示すブロック図である。決済装置４００は、メモリ４０１と、演算装置４０２と、入力装置４０３と、出力装置４０４と、通信装置４０５と、ストレージ装置４０６を含む計算機である。

ストレージ装置４０６には、デジタル通貨の取引履歴を記録するデジタル通貨取引履歴テーブル７００、アカウント所有証明トークンの状態を管理するアカウント所有証明トークン管理テーブル８００、アカウント所有証明トークンの取引履歴を記録するアカウント所有証明トークン取引履歴テーブル９００、デジタル通貨の取引を行うデジタル通貨プログラム４０７、アカウント所有証明トークンの取引を行うアカウント所有証明トークンプログラム１６００が格納される。デジタル通貨プログラム４０７は多数の種類が存在し、それぞれが１つのプログラムとして格納されている。

入力装置４０３は、例えば、キーボードやマウスあるいはタッチパネルで構成される。出力装置４０４は、例えば、ディスプレイなどで構成される。通信装置４０５は、ネットワークに接続されて、他の計算機と通信を行う。

デジタル通貨プログラム４０７と、アカウント所有証明トークンプログラム１６００は、メモリ４０１にロードされて演算装置４０２によって実行される。
演算装置４０２は、例えば、プロセッサであり、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、演算装置４０２は、デジタル通貨プログラム４０７に従って処理を実行することでデジタル通貨部として機能する。他のプログラムについても同様である。さらに、演算装置４０２は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

＜保険請求査定装置＞
図５は、保険請求査定装置５００の一例を示すブロック図である。保険請求査定装置５００は、メモリ５０１と、演算装置５０２と、入力装置５０３と、出力装置５０４と、通信装置５０５と、ストレージ装置５０６を含む計算機である。

ストレージ装置５０６には、保険契約情報を管理する保険契約テーブル１０００、保険請求の状態を管理する請求テーブル１１００、サイバー事故の情報を記録する事故情報テーブル１２００、保険請求の査定処理を制御する請求管理プログラム１７００、請求査定のエビデンスを収集するエビデンス収集プログラム１８００、保険金支払い事由の該否判定と保険金計算を行う損害査定プログラム１９００が格納される。

入力装置５０３は、例えば、キーボードやマウスあるいはタッチパネルで構成される。出力装置５０４は、例えば、ディスプレイなどで構成される。通信装置５０５は、ネットワークに接続されて、他の計算機と通信を行う。

請求管理プログラム１７００と、エビデンス収集プログラム１８００と、損害査定プログラム１９００は、メモリ５０１にロードされて演算装置５０２によって実行される。
演算装置５０２は、例えば、プロセッサであり、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、演算装置５０２は、請求管理プログラム１７００に従って処理を実行することで請求管理部として機能する。他のプログラムについても同様である。さらに、演算装置５０２は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

＜データ＞
図６は、ウォレットテーブル６００の一例を示す図である。ウォレットテーブル６００は、アカウント管理装置３００で管理される。
ウォレットテーブル６００は、アカウントＩＤ６０１と、秘密鍵６０２と、有効状態６０３、タイムスタンプ６０４を一つのエントリに含む。

アカウントＩＤ６０１には、被保険者のデジタル通貨アカウントを示すユニークな識別子が格納される。秘密鍵６０２には、決済装置４００の取引に電子署名をするための秘密鍵が格納される。有効状態６０３には、アカウントＩＤ６０１が有効か無効かを示すフラグが格納される。タイムスタンプ６０４には、ウォレットレコードの更新時刻が格納される。

図７は、デジタル通貨取引履歴テーブル７００の一例を示す図である。デジタル通貨取引履歴テーブル７００は、決済装置４００で管理される。
デジタル通貨取引履歴テーブル７００は、取引ＩＤ７０１と、通貨ＩＤ７０２、送信元７０３、送信先７０４、取引額７０５、タイムスタンプ７０６を一つのエントリに含む。

取引ＩＤ７０１には、デジタル通貨の取引結果ごとにユニークな識別子が格納される。通貨ＩＤ７０２には、デジタル通貨の種別を示す識別子が格納される。送信元７０３には、デジタル通貨を送信したアカウントのＩＤが格納される。送信先７０４には、デジタル通貨を受け取ったアカウントのＩＤが格納される。取引額７０５には、この取引で移転されたデジタル通貨の金額が格納される。タイムスタンプ７０６には、取引実行時刻が格納される。

図８は、アカウント所有証明トークン管理テーブル８００の一例を示す図である。アカウント所有証明トークン管理テーブル８００は、決済装置４００によって管理される。
アカウント所有証明トークン管理テーブル８００は、トークンＩＤ８０１と、トークン値８０２と、所有者８０３を一つのエントリに含む。
トークンＩＤ８０１には、トークンのユニークな識別子が格納される。トークン値８０２には、トークンの値が格納される。所有者８０３には、トークン所有者のアカウントＩＤが格納される。

図９は、アカウント所有証明トークン取引履歴テーブル９００の一例を示す図である。アカウント所有証明トークン取引履歴テーブル９００は、決済装置４００で管理される。
アカウント所有証明トークン取引履歴テーブル９００は、取引ＩＤ９０１と、トークンＩＤ９０２と、トークン値９０３と、送信元９０４、送信先９０５、署名９０６と、タイムスタンプ９０７を一つのエントリに含む。

取引ＩＤ９０１には、アカウント所有証明トークンの取引結果ごとにユニークな識別子が格納される。トークンＩＤ９０２には、取引されたトークンのＩＤが格納される。トークン値９０３には、取引されたトークンの値が格納される。送信元９０４には、トークンを送信したアカウントのＩＤが格納される。送信先９０５には、トークンを受け取ったアカウントのＩＤが格納される。署名９０６には、この取引を実行したアカウントの電子署名が格納される。タイムスタンプ９０７には、取引実行時刻が格納される。

図１０は、保険契約テーブル１０００の一例を示す図である。保険契約テーブル１０００は、保険請求査定装置５００によって管理される。
保険契約テーブル１０００は、保険契約ＩＤ１００１と、アカウントＩＤ１００２と、通貨ＩＤ１００３と、保険開始日１００４と、保険終了日１００５と、カバー率１００６と、上限額１００７を一つのエントリに含む。

保険契約ＩＤ１００１には、保険契約のユニークな識別子が格納される。アカウントＩＤ１００２には、この保険契約を締結した被保険者のアカウントＩＤが格納される。通貨ＩＤ１００３には、保険対象のデジタル通貨の通貨ＩＤが格納される。保険開始日１００４には、この保険契約の適用開始日が格納される。保険終了日１００５には、この保険契約の適用終了日が格納される。カバー率１００６には、この保険契約により、損害が補償される割合が格納される。上限額１００７には、この保険契約で補償される損害の上限金額が格納される。

図１１は、請求テーブル１１００の一例を示す図である。請求テーブル１１００は、保険請求査定装置５００によって管理される。

請求テーブル１１００は、請求ＩＤ１１０１と、保険契約ＩＤ１１０２と、アカウントＩＤ１１０３と、通貨ＩＤ１１０４と、検証コード１１０５と、検証コードタイムスタンプ１１０６と、アカウント所有証明１１０７と、支払可否１１０８と、保険金１１０９と、ステータス１１１０を一つのエントリに含む。

請求ＩＤ１１０１には、保険請求のユニークな識別子が格納される。保険契約ＩＤ１１０２には、保険請求の対象となる保険契約ＩＤが格納される。アカウントＩＤ１１０３には、保険請求の対象となるアカウントＩＤが格納される。通貨ＩＤ１１０４には、保険請求の対象となる通貨ＩＤが格納される。検証コード１１０５には、保険査定の検証に利用される乱数が格納される。検証コードタイムスタンプ１１０６には、検証コードの発行時刻が格納される。アカウント所有証明１１０７には、アカウント所有証明の判定結果が格納される。支払可否１１０８には、保険金支払可否の査定結果が格納される。保険金１１０９には、支払われる保険金の金額が格納される。ステータス１１１０には、保険査定の進捗状況が格納される。

図１２は、事故情報テーブル１２００の一例を示す図である。事故情報テーブル１２００は、保険請求査定装置５００によって管理される。
事故情報テーブル１２００は、インシデントＩＤ１２０１と、通貨ＩＤ１２０２と、事故内容１２０３と、原因１２０４と、対策１２０５と、事故発生日１２０６と、対策完了日１２０７を一つのエントリに含む。

インシデントＩＤ１２０１には、デジタル通貨に関するサイバー事故のユニークな識別子が格納される。通貨ＩＤ１２０２には、サイバー事故が発生したデジタル通貨の通貨ＩＤが格納される。事故内容１２０３には、事故の概要情報が格納される。原因１２０４には、事故の原因が格納される。対策１２０５には、事故への対策内容が格納される。事故発生日１２０６には、事故が発生した日時が格納される。対策完了日１２０７には、事故の対策が完了した日時が格納される。

＜処理＞
以下の説明では、保険契約ＩＤ「Ｐ０１」に対する保険請求査定を行う場合を例として説明するが、これに限定されるものではない。

図１３は、保険請求システム１００が行う処理の一例を示すシーケンス図である。

端末装置２００は、保険請求を保険請求査定装置５００に送信する（Ｓ１３０１）。
保険請求査定装置５００は、保険請求を受け付け、アカウント所有証明の提出要求を端末装置２００に送信する（Ｓ１３０２）。
端末装置２００は、アカウント所有証明の発行要求をアカウント管理装置３００に送信する（Ｓ１３０３）。

アカウント管理装置３００は、アカウント所有証明のトークン発行要求を決済装置４００に送信する（Ｓ１３０４）。

決済装置４００は、トークン発行処理を実行し（Ｓ１３０５）、トークン取引結果をアカウント管理装置３００に送信する（Ｓ１３０６）。

アカウント管理装置３００は、アカウント所有証明のトークン移転要求を決済装置４００に送信する（Ｓ１３０７）。

決済装置４００は、トークン移転処理を実行し（Ｓ１３０８）、トークン取引結果をアカウント管理装置３００に送信する（Ｓ１３０９）。

アカウント管理装置３００は、アカウント所有証明の発行完了を端末装置２００に送信する（Ｓ１３１０）。

端末装置２００は、アカウント所有証明の提出完了を保険請求査定装置５００に送信する（Ｓ１３１１）。

保険請求査定装置５００は、保険金支払の可否を判断し、損害と保険金を算出し（Ｓ１３１２）、査定結果を端末装置２００に送信する（Ｓ１３１３）。

図１４は、保険請求プログラム１４００の一例を示すフローチャートである。
以下の説明では、保険請求プログラム１４００を処理の主体として説明するが、演算装置２０２を処理の主体としてもよい。

保険請求プログラム１４００は、出力装置に保険請求フォームを表示する（Ｓ１４０１）。
次に、保険請求プログラム１４００は、入力装置でユーザの入力を受け付け、保険請求情報を生成する（Ｓ１４０２）。保険請求情報には、保険請求手続きに関する情報として、保険契約ＩＤ、アカウントＩＤ、通貨ＩＤが含まれる。例えば、保険請求情報は｛保険契約ＩＤ：Ｐ０１、アカウントＩＤ：ｕｓｅｒ０１、通貨ＩＤ：ＰＵ０８５｝というメッセージである。
次に、保険請求プログラム１４００は、保険請求査定装置５００に保険請求を送信する（Ｓ１４０３）。
次に、保険請求プログラム１４００は、保険請求査定装置５００からアカウント所有証明の提出要求を受信する（Ｓ１４０４）。
次に、保険請求プログラム１４００は、アカウント管理装置３００にアカウント所有証明の発行要求を送信する（Ｓ１４０５）。
次に、保険請求プログラム１４００は、アカウント管理装置３００からアカウント所有証明の発行完了を受信する（Ｓ１４０６）。
次に、保険請求プログラム１４００は、保険請求査定装置５００にアカウント所有証明の提出完了を送信する（Ｓ１４０７）。
次に、保険請求プログラム１４００は、保険請求査定装置から査定結果を受信する（Ｓ１４０８）。

図１５は、証明書発行プログラム１５００の一例を示すフローチャートである。
以下の説明では、証明書発行プログラム１５００を処理の主体として説明するが、演算装置３０２を処理の主体としてもよい。

証明書発行プログラム１５００は、端末装置２００からアカウント所有証明の発行要求を受信する（Ｓ１５０１）。例えば、発行要求は、｛保険契約ＩＤ：Ｐ０１、通貨ＩＤ：ＰＵ０８５、被保険者アカウントＩＤ：ｕｓｅｒ０１、保険会社アカウントＩＤ：ｉｎｓｕｒａｎｃｅ０１、検証コード：ｈ８ｅｘ３ｈ｝というメッセージである。

証明書発行プログラム１５００は、発行要求メッセージから、保険契約ＩＤ、通貨ＩＤ、被保険者アカウントＩＤ、保険会社アカウントＩＤ、検証コードを抽出する（Ｓ１５０２）。

証明書発行プログラム１５００は、保険契約ＩＤ、被保険者アカウントＩＤ、通貨ＩＤ、検証コードをハッシュ関数に入力して、ハッシュ値を生成する（Ｓ１５０３）。

証明書発行プログラム１５００は、トークン発行取引を行うため、決済装置４００に対して、トークン取引要求を送信する（Ｓ１５０４）。トークン取引要求は、要求区分に発行、トークンＩＤに保険契約ＩＤ、トークン値に前ステップで生成したハッシュ値、送信元にカストディアカウントＩＤ、送信先に被保険者アカウントＩＤ、署名にカストディの秘密鍵による電子署名、という情報を持つ。例えば、トークン取引要求は、｛要求区分：発行、トークンＩＤ：Ｐ０１、トークン値：ｘｊｆｉ９ｊ３４２４ｌａ８９０ｄ、送信元：Ｂａｎｋ０２、送信先：ｕｓｅｒ０１、署名：ｓｉｇ－ｂａｎｋ０２｝というメッセージである。

証明書発行プログラム１５００は、決済装置４００からトークン取引結果を受信する（Ｓ１５０５）。

証明書発行プログラム１５００は、トークン移転取引を行うため、決済装置４００に対して、トークン取引要求を送信する（Ｓ１５０６）。トークン取引要求は、要求区分に移転、トークンＩＤに保険契約ＩＤ、送信元に被保険者アカウントＩＤ、送信先に保険会社アカウントＩＤ、署名に被保険者の秘密鍵による電子署名、という情報を持つ。例えば、トークン取引要求は、｛要求区分：移転、トークンＩＤ：Ｐ０１、送信元：ｕｓｅｒ０１、送信先：ｉｎｓｕｒａｎｃｅ０１、署名：ｓｉｇ－ｕｓｅｒ０１｝というメッセージである。
証明書発行プログラム１５００は、決済装置４００からトークン取引結果を受信する（Ｓ１５０７）。
証明書発行プログラム１５００は、端末装置２００にアカウント所有証明の発行完了を送信する（Ｓ１５０８）。

図１６は、アカウント所有証明トークンプログラム１６００の一例を示すフローチャートである。
以下の説明では、アカウント所有証明トークンプログラム１６００を処理の主体として説明するが、演算装置４０２を処理の主体としてもよい。

アカウント所有証明トークンプログラム１６００は、アカウント管理装置３００からトークン取引要求を受信する（Ｓ１６０１）。

アカウント所有証明トークンプログラム１６００は、トークン取引要求メッセージの要求区分を参照し、要求された取引内容を判定する（Ｓ１６０２）。発行の場合、Ｓ１６０３に進む。移転の場合、Ｓ１６１０に進む。

アカウント所有証明トークンプログラム１６００は、トークン取引要求から、トークンＩＤ、トークン値、送信元、送信先、署名、を抽出する（Ｓ１６０３）。例えば、トークン取引要求から、トークンＩＤ：Ｐ０１、トークン値：ｘｊｆｉ９ｊ３４２４ｌａ８９０ｄ、送信元：ｂａｎｋ０２、送信先：ｕｓｅｒ０１、署名：ｓｉｇ－ｂａｎｋ０２という値を抽出する。

アカウント所有証明トークンプログラム１６００は、トークンＩＤをキーにアカウント所有証明トークン管理テーブル８００を検索する（Ｓ１６０４）。

アカウント所有証明トークンプログラム１６００は、アカウント所有証明の二重請求を防止するために、同一のトークンＩＤを持つレコードが存在するかを判定する（Ｓ１６０５）。Ｙｅｓの場合、二重請求のため、発行取引を中断して、Ｓ１６１４に進む。Ｎｏの場合、新規請求のため、Ｓ１６０６に進む。

アカウント所有証明トークンプログラム１６００は、アカウント所有証明トークン管理テーブル８００にレコードを追加する（Ｓ１６０６）。レコードのデータ項目は、トークンＩＤ、トークン値、所有者である。トークンＩＤとトークン値には、トークン取引要求から抽出した値をセットする。所有者には、トークン取引要求の送信先の値をセットする。例えば、アカウント所有証明トークン管理レコードは、トークンＩＤ：Ｐ０１、トークン値：ｘｊｆｉ９ｊ３４２４ｌａ８９０ｄ、所有者：ｕｓｅｒ０１、という情報を持つ。

アカウント所有証明トークンプログラム１６００は、アカウント所有証明トークン取引履歴テーブル９００にレコードを追加する（Ｓ１６０７）。レコードのデータ項目は、取引ＩＤ、トークンＩＤ、トークン値、送信元、送信先、署名、タイムスタンプである。取引ＩＤには、取引をユニークに識別する値をセットする。トークンＩＤ、トークン値、送信元、送信先、署名には、トークン取引要求から抽出した値をセットする。タイムスタンプには取引を実行した時刻をセットする。例えば、アカウント所有証明トークン取引履歴レコードは、取引ＩＤ：ｘ２ｎｄ８ｈａｐｏ、トークンＩＤ：Ｐ０１、トークン値：ｘｊｆｉ９ｊ３４２４ｌａ８９０ｄ、送信元：Ｂａｎｋ０２、送信先：ｕｓｅｒ０１、署名：ｓｉｇ－ｂａｎｋ０２、タイムスタンプ：２０２２／０２／１１ １４：２３：０１という情報を持つ。

アカウント所有証明トークンプログラム１６００は、トークン取引結果のステータスを成功に設定する（Ｓ１６０８）。

アカウント所有証明トークンプログラム１６００は、アカウント管理装置３００にトークン取引結果を送信する（Ｓ１６０９）。

アカウント所有証明トークンプログラム１６００は、トークン取引要求から、トークンＩＤ、送信元、送信先、署名、を抽出する（Ｓ１６１０）。例えば、トークン取引要求から、トークンＩＤ：Ｐ０１、送信元：ｕｓｅｒ０１、送信先：ｉｎｓｕｒａｎｃｅ０１、署名：ｓｉｇ－ｕｓｅｒ０１という値を抽出する。

アカウント所有証明トークンプログラム１６００は、トークンＩＤをキーにアカウント所有証明トークン管理テーブル８００を検索する（Ｓ１６１１）。

アカウント所有証明トークンプログラム１６００は、存在しないアカウント所有証明を保険会社に提出することを防止するために、同一のトークンＩＤを持つレコードが存在するかを判定する（Ｓ１６１２）。Ｙｅｓの場合、アカウント所有証明が存在するため、Ｓ１６１３に進む。Ｎｏの場合、アカウント所有署名が存在しないため、移転取引を中断して、Ｓ１６１４に進む。

アカウント所有証明トークンプログラム１６００は、アカウント所有証明トークン管理テーブル８００の所有者を更新する（Ｓ１６１３）。所有者には、トークン取引要求の送信先の値をセットする。例えば、アカウント所有証明トークン管理レコードは、トークンＩＤ：Ｐ０１、トークン値：ｘｊｆｉ９ｊ３４２４ｌａ８９０ｄ、所有者：ｉｎｓｕｒａｎｃｅ０１、という情報を持つ。

アカウント所有証明トークンプログラム１６００は、発行取引や移転取引を中断した場合、トークン取引結果のステータスを失敗に設定する（Ｓ１６１４）。

図１７は、請求管理プログラム１７００の一例を示すフローチャートである。
以下の説明では、請求管理プログラム１７００を処理の主体として説明するが、演算装置５０２を処理の主体としてもよい。

請求管理プログラム１７００は、端末装置２００から保険請求を受信する（Ｓ１７０１）。保険請求情報には、保険請求手続きに関する情報として、保険契約ＩＤ、アカウントＩＤ、通貨ＩＤが含まれる。例えば、保険請求情報は｛保険契約ＩＤ：Ｐ０１、アカウントＩＤ：ｕｓｅｒ０１、通貨ＩＤ：ＰＵ０８５｝というメッセージである。

請求管理プログラム１７００は、保険請求情報を請求テーブル１１００に追記する（Ｓ１７０２）。請求ＩＤには、請求をユニークに識別する値をセットする。保険契約ＩＤ、アカウントＩＤ、通貨ＩＤには、保険請求から抽出した値をセットする。ステータスには、請求受付という値をセットする。その他のデータ項目については、この時点では空欄をセットする。例えば、請求レコードは、請求ＩＤ：Ｃ１０１、保険契約ＩＤ：Ｐ０１、アカウントＩＤ：ｕｓｅｒ０１、通貨ＩＤ：ＰＵ０８５、ステータス：請求受付という情報を持つ。

請求管理プログラム１７００は、エビデンス収集プログラム１８００を実行する（Ｓ１７０３）。
請求管理プログラム１７００は、損害査定プログラム１９００を実行する（Ｓ１７０４）。
請求管理プログラム１７００は、請求テーブル１１００から査定完了後のレコードを取得する（Ｓ１７０５）。
請求管理プログラム１７００は、端末装置２００に査定結果を通知する（Ｓ１７０６）。

図１８は、エビデンス収集プログラム１８００の一例を示すフローチャートである。
以下の説明では、エビデンス収集プログラム１８００を処理の主体として説明するが、演算装置５０２を処理の主体としてもよい。

エビデンス収集プログラム１８００は、請求管理プログラム１７００からエビデンス収集要求を受信する（Ｓ１８０１）。エビデンス収集要求には、請求ＩＤが含まれる。例えば、エビデンス収集要求は｛請求ＩＤ：Ｃ１０１｝というメッセージである。

エビデンス収集プログラム１８００は、エビデンス収集要求メッセージから請求ＩＤを抽出する（Ｓ１８０２）。例えば、請求ＩＤはＣ１０１である。

エビデンス収集プログラム１８００は、請求ＩＤで請求テーブルを検索し、請求レコードを取得する（Ｓ１８０３）。

エビデンス収集プログラム１８００は、当該請求に対する検証コードの乱数を生成する（Ｓ１８０４）。検証コードは、アカウント所有証明が、保険対象のデジタル通貨に対して発行されていることを検証するために利用される。デジタル通貨には様々な種類が存在するため、どのデジタル通貨がサイバー事故に合うかは状況による。また、１つのサイバー事故が複数のデジタル通貨に影響する場合もある。そのため、被保険者は、保険請求において、損害を受けたデジタル通貨を選択して保険請求を行う。もし、保険対象外のデジタル通貨に対するアカウント所有証明が提出された場合、請求査定装置は保険金支払いを拒絶する必要がある。以上のような理由により、検証コードが発行される。検証コードを用いた査定方法については、損害査定プログラム１９００のフローチャートで述べる。

エビデンス収集プログラム１８００は、請求テーブル１１００に検証コードと検証コードタイムスタンプを追記する（Ｓ１８０５）。検証コードには、前ステップで生成した乱数をセットする。検証コードタイムスタンプには、検証コードを生成した時刻をセットする。例えば、請求レコードは、請求ＩＤ：Ｃ１０１、保険契約ＩＤ：Ｐ０１、アカウントＩＤ：ｕｓｅｒ０１、通貨ＩＤ：ＰＵ０８５、検証コード：ｈ８ｅｘ３ｈ、検証コードタイムスタンプ：２０２２／０２／１１ １４：２１：５０、ステータス：請求受付、という情報を持つ。

エビデンス収集プログラム１８００は、アカウント所有証明の提出要求を端末装置２００に送信する（Ｓ１８０６）。アカウント所有証明の提出要求は、保険契約ＩＤ、通貨ＩＤ、被保険者アカウントＩＤ、保険会社アカウントＩＤ、検証コードを含む。例えば、アカウント所有証明の提出要求は、｛保険契約ＩＤ：Ｐ０１、通貨ＩＤ：ＰＵ０８５、被保険者アカウントＩＤ：ｕｓｅｒ０１、保険会社アカウントＩＤ：ｉｎｓｕｒａｎｃｅ０１、検証コード：ｈ８ｅｘ３ｈ｝というメッセージである。

エビデンス収集プログラム１８００は、端末装置２００からアカウント所有証明書の提出完了通知を受信する（Ｓ１８０７）。

エビデンス収集プログラム１８００は、請求テーブルのステータスを査定待ちに更新する（Ｓ１８０８）。

図１９は、損害査定プログラム１９００の一例を示すフローチャートである。
以下の説明では、損害査定プログラム１９００を処理の主体として説明するが、演算装置５０２を処理の主体としてもよい。

損害査定プログラム１９００は、請求管理プログラム１７００から損害査定要求を受信する（Ｓ１９０１）。損害査定要求には、請求ＩＤが含まれる。例えば、損害査定要求は｛請求ＩＤ：Ｃ１０１｝というメッセージである。

損害査定プログラム１９００は、損害査定要求メッセージから請求ＩＤを抽出する（Ｓ１９０２）。例えば、請求ＩＤはＣ１０１である。

損害査定プログラム１９００は、請求ＩＤで請求テーブル１１００を検索し、請求レコードを取得する（Ｓ１９０３）。

損害査定プログラム１９００は、当該請求レコードから、保険契約ＩＤ、アカウントＩＤ、通貨ＩＤ、検証コード、検証コードタイムスタンプを抽出する（Ｓ１９０４）。例えば、請求ＩＤ：Ｃ１０１、保険契約ＩＤ：Ｐ０１、アカウントＩＤ：ｕｓｅｒ０１、通貨ＩＤ：ＰＵ０８５、検証コード：ｈ８ｅｘ３ｈ、検証コードタイムスタンプ：２０２２／０２／１１ １４：２１：５０、という情報を抽出する。

損害査定プログラム１９００は、保険契約ＩＤで保険契約テーブル１０００を検索し、保険契約レコードを取得する（Ｓ１９０５）。

損害査定プログラム１９００は、当該保険契約レコードから、アカウントＩＤ、通貨ＩＤ、保険開始日、保険終了日を抽出する（Ｓ１９０６）。例えば、保険契約ＩＤ：Ｐ０１、アカウントＩＤ：ｕｓｅｒ０１、通貨ＩＤ：ＰＵ０８５、保険開始日：２０２２／０１／０１、保険終了日：２０２２／０３／３１、という情報を抽出する。
損害査定プログラム１９００は、保険請求されたアカウントＩＤが保険対象のアカウントＩＤかどうかを検証するため、請求レコードのアカウントＩＤと契約レコードのアカウントＩＤを比較する（Ｓ１９０７）。

損害査定プログラム１９００は、アカウントＩＤが一致するかを判断する（Ｓ１９０８）。Ｙｅｓの場合、Ｓ１９０９に進む。Ｎｏの場合、請求内容が保険契約と不一致のため、査定処理を中断して、Ｓ１９３７に進む。

損害査定プログラム１９００は、保険請求された通貨ＩＤが保険対象の通貨ＩＤかどうかを検証するため、請求レコードの通貨ＩＤと契約レコードの通貨ＩＤを比較する（Ｓ１９０９）。

損害査定プログラム１９００は、通貨ＩＤが一致するかを判断する（Ｓ１９１０）。Ｙｅｓの場合、Ｓ１９１１に進む。Ｎｏの場合、請求内容が保険契約と不一致のため、査定処理を中断して、Ｓ１９３７に進む。

損害査定プログラム１９００は、事故情報テーブル１２００から「通貨ＩＤ＝通貨ＩＤ ＡＮＤ 事故発生日＞＝保険開始日 ＡＮＤ 事故発生日＜＝保険終了日」という条件に合致するレコードを抽出する（Ｓ１９１１）。例えば、通貨ＩＤ＝ＰＵ０８５ ＡＮＤ 事故発生日＞＝２０２２／０１／０１ ＡＮＤ 事故発生日＜＝２０２２／０３／３１、という条件で検索する。

損害査定プログラム１９００は、保険対象のデジタル通貨について、保険期間中にサイバー事故の発生が報告されたかを検証するため、前記ステップの条件に合致する事故情報レコードが存在するかどうかを判断する（Ｓ１９１２）。Ｙｅｓの場合、サイバー事故が発生しているため、Ｓ１９１３に進んで査定処理を継続する。Ｎｏの場合、サイバー事故が発生していないため、査定処理を中断して、Ｓ１９３７に進む。

損害査定プログラム１９００は、アカウント所有署名トークンの発行履歴を確認するため、決済装置４００のアカウント所有証明トークン取引履歴テーブル９００から「トークンＩＤ＝保険契約ＩＤ ＡＮＤ 送信元＝カストディアカウントＩＤ ＡＮＤ 送信先＝被保険者アカウントＩＤ」という条件に合致するレコードを抽出する（Ｓ１９１３）。例えば、トークンＩＤ＝Ｐ０１ ＡＮＤ 送信元＝Ｂａｎｋ０２ ＡＮＤ 送信先＝ｕｓｅｒ０１、という条件で検索する。

損害査定プログラム１９００は、アカウント所有証明トークン取引履歴レコードが存在するかを判断する（Ｓ１９１４）。Ｙｅｓの場合、査定処理を継続するため、Ｓ１９１５に進む。Ｎｏの場合、査定処理を中断して、Ｓ１９２６に進む。

損害査定プログラム１９００は、当該アカウン所有証明トークン取引履歴レコードから、署名、タイムスタンプを抽出する（Ｓ１９１５）。例えば、署名：ｓｉｇ－ｂａｎｋ０２、タイムスタンプ：２０２２／０２／１１ １４：２３：０１、である。

損害査定プログラム１９００は、アカウント所有証明トークンがカストディに発行されたものであることを検証するため、前記ステップで抽出した署名がカストディの署名であるかを判断する（Ｓ１９１６）。Ｙｅｓの場合、査定処理を継続するため、Ｓ１９１７に進む。Ｎｏの場合、査定処理を中断して、Ｓ１９２６に進む。

損害査定プログラム１９００は、過去に発行されたアカウント所有証明の使い回しを防ぐため、請求レコードの検証コードタイムスタンプとアカウント所有証明トークン取引レコードのタイムスタンプを比較する（Ｓ１９１７）。保険金の支払条件の１つは、保険請求時点において、被保険者が保険対象のデジタル通貨のアカウント所有者であり、秘密鍵が安全に保管されていることである。過去に発行されたアカウント所有証明を再提出されると、現時点のアカウント管理状況を確認できない。従って、アカウント所有証明トークンが保険請求後に発行されたことを検証する必要がある。

損害査定プログラム１９００は、請求レコードの検証コードタイムスタンプがアカウント所有証明トークン取引レコードのタイムスタンプよりも早いかどうか判断する（Ｓ１９１８）。Ｙｅｓの場合、査定処理を継続するため、Ｓ１９１９に進む。Ｎｏの場合、査定処理を中断して、Ｓ１９２６に進む。

損害査定プログラム１９００は、アカウント所有署名トークンの移転履歴を確認するため、決済装置４００のアカウント所有証明トークン取引履歴テーブル９００から「トークンＩＤ＝保険契約ＩＤ ＡＮＤ 送信元＝被保険者アカウントＩＤ ＡＮＤ 送信先＝保険会社アカウントＩＤ」という条件に合致するレコードを抽出する（Ｓ１９１９）。例えば、トークンＩＤ＝Ｐ０１ ＡＮＤ 送信元＝ｕｓｅｒ０１ ＡＮＤ 送信先＝ｉｎｓｕｒａｎｃｅ０１、という条件で検索する。

損害査定プログラム１９００は、アカウント所有証明トークン取引履歴レコードが存在するかを判断する（Ｓ１９２０）。Ｙｅｓの場合、査定処理を継続するため、Ｓ１９１５に進む。Ｎｏの場合、査定処理を中断して、Ｓ１９２６に進む。

損害査定プログラム１９００は、当該アカウン所有証明トークン取引履歴レコードから、トークン値、署名、を抽出する（Ｓ１９２１）。例えば、トークン値：ｘｊｆｉ９ｊ３４２４ｌａ８９０ｄ、署名：ｓｉｇ－ｕｓｅｒ０１、である。

損害査定プログラム１９００は、被保険者の鍵が安全に管理されていて、デジタル通貨の取引を行える状態であることを検証するため、前記ステップで抽出した署名が被保険者の署名であるかどうかを判断する。（Ｓ１９２２）。Ｙｅｓの場合、査定処理を継続するため、Ｓ１９２３に進む。Ｎｏの場合、査定処理を中断して、Ｓ１９２６に進む。

損害査定プログラム１９００は、請求レコードから取得した、保険契約ＩＤ、被保険者アカウントＩＤ、通貨ＩＤ、検証コードをハッシュ関数に入力して、ハッシュ値を生成する（Ｓ１９２３）。

損害査定プログラム１９００は、アカウント所有証明が保険対象のデジタル通貨に対して発行されていることを検証するため、前記ステップで生成したハッシュ値がアカウン所有証明トークン取引履歴レコードから取得したトークン値と一致するかを判断する（Ｓ１９２４）。Ｙｅｓの場合、査定処理を継続するため、Ｓ１９２５に進む。Ｎｏの場合、査定処理を中断して、Ｓ１９２６に進む。本ステップで比較するハッシュ値は、アカウントＩＤとデジタル通貨ＩＤの組合せに対してユニークな値である。仮に、保険対象外のアカウントＩＤやデジタル通貨に対するアカウント所有証明だった場合、トークン値が異なるため、ハッシュ値と不一致になる。これにより、アカウント所有証明が保険対象のデジタル通貨に対して発行されていることを検証する。

損害査定プログラム１９００は、請求テーブルのアカウント所有証明をＯＫに更新する（Ｓ１９２５）。
損害査定プログラム１９００は、請求テーブルのアカウント所有証明をＮＧに更新する（Ｓ１９２６）。
損害査定プログラム１９００は、事故情報レコードから、事故発生日、対策完了日を抽出する（Ｓ１９２７）。例えば、事故発生日：２０２２／０２／０７、対策完了日：２０２２／０２／０９、という情報を抽出する。

損害査定プログラム１９００は、サイバー事故の発生から対策完了の間に、被保険者のアカウントに対して行われたデジタル通貨取引の情報を収集するために、決済装置４００のデジタル通貨取引履歴テーブル７００から「通貨ＩＤ＝通貨ＩＤ ＡＮＤ（送信元＝アカウントＩＤ ＯＲ 送信先＝アカウントＩＤ）ＡＮＤ タイムスタンプ＞＝事故発生日 タイムスタンプ＜＝対策完了日」という条件に合致するレコードを抽出する（Ｓ１９２８）。例えば、通貨ＩＤ＝ＰＵ０８５ ＡＮＤ（送信元＝ｕｓｅｒ０１ ＯＲ 送信先＝ｕｓｅｒ０１）ＡＮＤ タイムスタンプ＞＝２０２２／０２／０７ タイムスタンプ＜＝２０２２／０２／０９」という条件で検索する。

損害査定プログラム１９００は、前記ステップで取得した取引履歴レコード群に対して、取引額を抽出し、変動額を集計する（Ｓ１９２９）。変動額とは、被保険者のアカウントに対して行われたデジタル通貨に対するサイバー事故の発生から対策完了の間において変動したデジタル通貨の金額である。この集計値がマイナスの場合、その金額を被害額とし、当該被害額がサイバー事故により発生した損害とする。集計値がプラス、または、ゼロの場合、サイバー事故による損害は無かったと判断する。

損害査定プログラム１９００は、前記ステップで集計した変動額の正負を判断する（Ｓ１９３０）。マイナスの場合、Ｓ１９３１に進む。プラス、または、ゼロの場合、査定処理を中断して、Ｓ１９３７に進む。

損害査定プログラム１９００は、保険契約レコードから、カバー率、上限額を抽出する（Ｓ１９３１）。例えば、カバー率：８０、上限額：１０００、という情報である。

損害査定プログラム１９００は、デジタル通貨の取引履歴から集計した変動額にカバー率を乗算して、保険金を算出する（Ｓ１９３３）。例えば、変動額が１０００だった場合、カバー率の８０％を乗算して、保険金は８００となる。

損害査定プログラム１９００は、前記ステップで算出した保険金が上限額を超えるかどうか判断する（Ｓ１９３４）。Ｙｅｓの場合、保険金を補正するため、Ｓ１９３５に進む。Ｎｏの場合、保険金は確定のため、Ｓ１９３６に進む。

損害査定プログラム１９００は、保険金を上限額に変更する（Ｓ１９３５）。例えば、算出された保険金が１５００で、上限額が１０００の場合、保険金を上限額である１０００に変更する。

損害査定プログラム１９００は、請求テーブル１１００の保険金に算出した保険金を記録し、支払可否を可に更新する（Ｓ１９３６）。

損害査定プログラム１９００は、請求テーブル１１００の支払可否を否に更新する（Ｓ１９３７）。

損害査定プログラム１９００は、請求テーブルのステータスを完了に更新する（Ｓ１９３８）。

このように、本実施例では、図１３等を用いて説明したように、端末装置２００と、アカウント管理装置３００と、決済装置４００と、保険請求査定装置５００と、を有する保険請求システム１００において、それぞれの装置は、プロセッサとメモリとを有し、上記端末装置２００のプロセッサは、第１のプログラム（保険請求プログラム１４００）を実行して、ユーザから入力されたデジタル通貨の保険請求手続きに関する保険請求情報を、上記保険請求査定装置５００に出力し、上記保険請求査定装置５００のプロセッサは、第２のプログラム（請求管理プログラム１７００）を実行して、上記保険請求情報に含まれる、上記ユーザのアカウントを識別するためのアカウントＩＤにより識別されるユーザが被保険者としてアカウントを所有していることを証明するためのアカウント所有証明の提出を、上記端末装置２００に要求し、上記端末装置２００のプロセッサは、上記第１のプログラムを実行して、上記アカウント所有証明の発行要求を、上記アカウント管理装置３００に出力し、上記アカウント管理装置３００のプロセッサは、第３のプログラム（証明書発行プログラム１５００）を実行して、上記保険請求情報に含まれる、上記デジタル通貨の保険契約を識別するための保険契約ＩＤと上記アカウントＩＤと上記デジタル通貨を識別するための通貨ＩＤとを用いて生成した、上記被保険者を所有者とする上記アカウント所有証明のトークンの発行要求を上記決済装置４００に出力し、上記決済装置のプロセッサ４００は、第４のプログラム（アカウント所有証明トークンプログラム１６００）を実行して、上記トークンを識別するためのトークンＩＤと上記トークンの値と上記トークンの所有者とを対応付けた第１のテーブル（アカウント所有証明トークン管理テーブル９００）に、上記発行要求を受けた上記トークンを追加し、当該追加した結果をトークン発行取引結果として上記アカウント管理装置３００に出力し、上記アカウント管理装置３００のプロセッサは、上記第３のプログラムを実行して、上記トークン発行取引結果に対して、上記追加した上記トークンの所有者を保険会社とする移転要求を上記決済装置４００に出力し、上記決済装置４００のプロセッサは、上記第４のプログラムを実行して、上記第１のテーブルに追加された上記トークンの所有者を上記保険会社に更新し、当該更新した結果をトークン移転取引結果として上記アカウント管理装置３００に出力し、上記アカウント管理装置３００のプロセッサは、上記第３のプログラムを実行して、上記決済装置４００から上記トークン移転取引結果を受け取ると、上記アカウント所有証明の発行完了を上記端末装置２００に出力し、上記端末装置２００のプロセッサは、上記第１のプログラムを実行して、上記アカウント所有証明の発行完了に基づいて、上記アカウント所有証明の提出完了を上記保険請求査定装置５００に出力し、上記保険請求査定装置５００のプロセッサは、第５のプログラム（損害査定プログラム１９００）を実行し、上記保険契約ＩＤにより識別される保険契約情報を管理する第２のテーブル（保険契約テーブル１０００）と、上記通貨ＩＤにより識別されるデジタル通貨についての事故情報を管理する第３のテーブル（事故情報テーブル１２００）とを用いて、上記保険請求情報に基づく保険請求に対する査定を行う。

つまり、本実施例では、プロセッサとメモリを有する端末装置２００と、プロセッサとメモリを有するアカウント管理装置３００と、プロセッサとメモリを有する決済装置４００と、プロセッサとメモリを有する保険請求査定装置５００を有する保険請求システム１００において、上記端末装置２００が保険請求を提出すると、上記保険請求査定装置５００が保険請求を受け付けた後でアカウント所有証明の提出を要求し、上記端末装置２００は、上記アカウント管理装置３００を介してアカウント所有証明トークンを発行し、そのトークンを被保険者のアカウントから保険会社のアカウントに移転し、上記保険請求査定装置５００は、被保険者の保険対象アカウント所有証明を検証し、上記決済装置４００の取引履歴を元に保険金支払の可否を判断し、損害と保険金を算出する。

これにより、被保険者がデジタル通貨のアカウント管理業務をカストディ業者に委託する場合において、被保険者と保険会社が相互に信用できない状況、つまりサイバー保険を利用する被保険者と保険会社の間に情報の非対称性が存在する状況において、カストディのアカウント管理装置がエビデンス収集を仲介することで相互の信頼関係を補完し、デジタル通貨のサイバー保険に対する保険金請求を査定することが可能となる。さらに、デジタル通貨のサイバー保険を適用できる範囲が拡大し、デジタル通貨を利用する消費者の保護に貢献することができる。

また、図１６のＳ１６０５等を用いて説明したように、上記決済装置４００のプロセッサは、上記第４のプログラムを実行して、上記保険契約ＩＤと同じＩＤをもつ上記トークンを識別するためのトークンＩＤにより、上記対応付けを行って、上記第１のテーブルに上記トークンを追加する。これにより、アカウント所有証明トークンのトークンＩＤが保険契約ＩＤと同じＩＤとなり、トークン発行要求時にトークンＩＤと保険契約ＩＤとが重複する場合には、発行要求を拒絶することでトークンＩＤの重複を排除することができ、その結果、１つの保険契約に対するアカウント所有証明の二重請求を防止することができる。

また、図１５Ｓ１５０３、Ｓ１５０４、図１６Ｓ１６０７等を用いて説明したように、上記アカウント管理装置３００のプロセッサは、上記第３のプログラムを実行して、上記保険契約ＩＤ、上記アカウントＩＤ、上記通貨ＩＤに加え、さらに、上記保険請求査定装置５００において生成された上記保険請求に対する査定の検証を行うための検証コードを、ハッシュ関数に入力してハッシュ値を生成し、生成したハッシュ値を上記トークンの値とした上記アカウント所有証明のトークンを上記決済装置４００に出力し、上記決済装置４００のプロセッサは、上記第４のプログラムを実行して、上記トークンを、上記発行取引ごとに対応付けて、第４のテーブル（アカウント所有証明トークン取引履歴テーブル９００）に記録する。これにより、ハッシュ値をトークンの値としたアカウント所有証明トークンの取引履歴をシステム全体で一元管理することができる。

また、図１９のＳ１９２３等を用いて説明したように、上記保険請求査定装置５００のプロセッサは、上記第５のプログラムを実行し、上記端末装置２００から上記保険請求情報を受け取ったときの上記保険契約ＩＤ、上記アカウントＩＤ、上記通貨ＩＤ、上記検証コードをハッシュ関数に入力してハッシュ値を生成し、生成した当該ハッシュ値が、上記第４のテーブルに記録した上記トークン値と一致するか否かを判定する。これにより、上記アカウント所有証明トークンが保険対象のデジタル通貨に対して発行されていることを検証することができる。つまり、カストディは、保険契約情報と検証コード（乱数）から生成した保険対象ごとにユニークとなるハッシュ値をアカウント所有証明トークンに埋め込み、保険会社では、自身で生成したハッシュ値とトークンから抽出したハッシュ値とを比較する。アカウントＩＤや通貨ＩＤが異なる場合にハッシュ値が不一致となることを検証することで、保険対象外のデジタル通貨に対するアカウント所有証明を拒絶することができる。

また、図１９のＳ１９１５－１９１７等を用いて説明したように、上記アカウント管理装置３００のプロセッサは、上記第３のプログラムを実行して、上記保険請求の際に上記保険請求査定装置５００において生成された上記検証コードのタイムスタンプを出力し、上記アカウント管理装置３００のプロセッサは、上記第３のプログラムを実行して、上記トークンを識別するためのトークンＩＤと、上記トークンの値と、上記発行取引を実行した時刻のタイムスタンプとを、上記トークンの上記発行取引ごとに対応付けて、第４のテーブルと同様の第５のテーブル（アカウント所有証明トークン取引履歴テーブル９００）に記録し、上記決済装置４００のプロセッサは、上記第５のプログラムを実行して、上記検証コードのタイムスタンプが、上記発行取引を実行した時刻のタイムスタンプよりも早い場合に、上記保険請求情報に基づく保険請求に対する査定を行う。これにより、保険請求受付時に発行する検証コードのタイムスタンプがアカウント所有証明トークンのタイムスタンプよりも早いことを検証して、過去に発行されたアカウント所有証明トークンの使い回しを防止することができる。

従来、２層型デジタル通貨システムは、プライベートブロックチェーンを採用し、ユーザはデジタル通貨アカウントを管理する秘密鍵を、銀行などのカストディに預けるため、ユーザ（すなわち被保険者）自身がアカウント所有証明を保険会社に提出できないという課題があった。これまで説明したように、本実施例によれば、当該解決するため、被保険者から保険金請求を受け付けると、カストディがアカウント所有証明トークンを発行し、そのトークンを被保険者のアカウントから保険会社に移転することで、被保険者の保険対象アカウント所有権を検証し、デジタル通貨システムの取引履歴を元に保険金支払の可否を判断し、損害と保険金を算出する。これにより、被保険者がカストディを介して提出したアカウント所有証明書の正当性を確保することができるようになる。また、様々な種類のデジタルトークンを発行することができ、それらのトークンの取引履歴が台帳に記録され、ステークホルダ間で共有される。そのため、トークン所有者の変遷を追跡できるようになる。

以上のように、本実施例のデジタル通貨保険の保険請求システムでは、被保険者と保険会社の間に情報の非対称性がある場合でも、妥当性のあるエビデンスに基づいて保険査定を行うことができる。なお、上記実施例では、契約ＩＤがＰ１０１、アカウントＩＤが１０１、通貨ＩＤがＰＵ０８５の場合を請求査定の例として上げたが、これに限定されるものではない。契約ＩＤ、アカウントＩＤ、通貨ＩＤが異なる場合、など様々な請求査定が存在する。

また、本実施例でテーブルでの情報格納を例示したが、テーブルに限定されるものではなく、スキーマレスのデータとして格納されてもよい。

本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化したり、上記実施の形態に開示されている複数の構成要素を適宜組み合わせて実施することができる。

２００ 端末装置
３００ アカウント管理装置
４００ 決済装置
５００ 保険請求査定装置
６００ ウォレットテーブル
７００ デジタル通貨取引履歴テーブル
８００ アカウント所有証明トークン管理テーブル
９００ アカウント所有証明トークン取引履歴テーブル
１０００ 保険契約テーブル
１１００ 請求テーブル
１２００ 事故情報テーブル
１４００ 保険請求プログラム
１５００ 証明書発行プログラム
１６００ アカウント所有証明トークンプログラム
１７００ 請求管理プログラム
１８００ エビデンス収集プログラム
１９００ 損害査定プログラム

Claims (11)

1. 端末装置と、アカウント管理装置と、決済装置と、保険請求査定装置と、を有する保険請求システムであって、
   それぞれの装置は、プロセッサとメモリとを有し、
   前記端末装置のプロセッサは、第１のプログラムを実行して、ユーザから入力されたデジタル通貨の保険請求手続きに関する保険請求情報を、前記保険請求査定装置に出力し、
   前記保険請求査定装置のプロセッサは、第２のプログラムを実行して、前記保険請求情報に含まれる、前記ユーザのアカウントを識別するためのアカウント識別情報により識別されるユーザが被保険者としてアカウントを所有していることを証明するためのアカウント所有証明の提出を、前記端末装置に要求し、
   前記端末装置のプロセッサは、前記第１のプログラムを実行して、前記アカウント所有証明の発行要求を、前記アカウント管理装置に出力し、
   前記アカウント管理装置のプロセッサは、第３のプログラムを実行して、前記保険請求情報に含まれる、前記デジタル通貨の保険契約を識別するための保険契約識別情報と前記アカウント識別情報と前記デジタル通貨を識別するためのデジタル通貨識別情報とを用いて生成した、前記被保険者を所有者とする前記アカウント所有証明のトークンの発行要求を前記決済装置に出力し、
   前記決済装置のプロセッサは、第４のプログラムを実行して、前記トークンを識別するためのトークン識別情報と前記トークンの値と前記トークンの所有者とを対応付けた第１のテーブルに、前記発行要求を受けた前記トークンを追加し、当該追加した結果をトークン発行取引結果として前記アカウント管理装置に出力し、
   前記アカウント管理装置のプロセッサは、前記第３のプログラムを実行して、前記トークン発行取引結果に対して、前記追加した前記トークンの所有者を保険会社とする移転要求を前記決済装置に出力し、
   前記決済装置のプロセッサは、前記第４のプログラムを実行して、前記第１のテーブルに追加された前記トークンの所有者を前記保険会社に更新し、当該更新した結果をトークン移転取引結果として前記アカウント管理装置に出力し、
   前記アカウント管理装置のプロセッサは、前記第３のプログラムを実行して、前記決済装置から前記トークン移転取引結果を受け取ると、前記アカウント所有証明の発行完了を前記端末装置に出力し、
   前記端末装置のプロセッサは、前記第１のプログラムを実行して、前記アカウント所有証明の発行完了に基づいて、前記アカウント所有証明の提出完了を前記保険請求査定装置に出力し、
   前記保険請求査定装置のプロセッサは、第５のプログラムを実行し、前記保険契約識別情報により識別される保険契約情報を管理する第２のテーブルと、前記通貨識別情報により識別されるデジタル通貨についての事故情報を管理する第３のテーブルとを用いて、前記保険請求情報に基づく保険請求に対する査定を行う、
   ことを特徴とする保険請求システム。
2. 請求項１に記載の保険請求システムであって、
   前記決済装置のプロセッサは、前記第４のプログラムを実行して、前記保険契約識別情報と同じ識別情報をもつ前記トークンを識別するためのアカウント所有証明トークン識別情報により、前記対応付けを行って、前記第１のテーブルに前記トークンを追加する、
   ことを特徴とする保険請求システム。
3. 請求項１に記載の保険請求システムであって、
   前記アカウント管理装置のプロセッサは、前記第３のプログラムを実行して、前記保険契約識別情報、前記アカウント識別情報、前記デジタル通貨識別情報に加え、さらに、前記保険請求査定装置において生成された前記保険請求に対する査定の検証を行うための検証コードを、ハッシュ関数に入力してハッシュ値を生成し、生成したハッシュ値を前記トークンの値とした前記アカウント所有証明のトークンを前記決済装置に出力し、
   前記決済装置のプロセッサは、前記第４のプログラムを実行して、前記トークンを、前記発行取引ごとに対応付けて、第４のテーブルに記録する、
   ことを特徴とする保険請求システム。
4. 請求項３に記載の保険請求システムであって、
   前記保険請求査定装置のプロセッサは、前記第５のプログラムを実行し、前記端末装置から前記保険請求情報を受け取ったときの前記保険契約識別情報、前記アカウント識別情報、前記デジタル通貨識別情報、前記検証コードをハッシュ関数に入力してハッシュ値を生成し、生成した当該ハッシュ値が、前記第４のテーブルに記録した前記トークン値と一致するか否かを判定する、
   ことを特徴とする保険請求システム。
5. 請求項１に記載の保険請求システムであって、
   前記アカウント管理装置のプロセッサは、前記第３のプログラムを実行して、前記保険請求の際に前記保険請求査定装置において生成された前記検証コードのタイムスタンプを出力し、
   前記アカウント管理装置のプロセッサは、前記第３のプログラムを実行して、前記トークンを識別するためのトークン識別情報と、前記トークンの値と、前記発行取引を実行した時刻のタイムスタンプとを、前記トークンの前記発行取引ごとに対応付けて、第５のテーブルに記録し、
   前記決済装置のプロセッサは、前記第５のプログラムを実行して、前記検証コードのタイムスタンプが、前記発行取引を実行した時刻のタイムスタンプよりも早い場合に、前記保険請求情報に基づく保険請求に対する査定を行う、
   ことを特徴とする保険請求システム。
6. プロセッサとメモリとを有した、端末装置と、アカウント管理装置と、決済装置と、保険請求査定装置と、を有する保険請求システムで行われる保険請求方法であって、
   前記端末装置は、ユーザから入力されたデジタル通貨の保険請求手続きに関する保険請求情報を、前記保険請求査定装置に出力し、
   前記保険請求査定装置は、前記保険請求情報に含まれる、前記ユーザのアカウントを識別するためのアカウント識別情報により識別されるユーザが被保険者としてアカウントを所有していることを証明するためのアカウント所有証明の提出を、前記端末装置に要求し、
   前記端末装置は、前記アカウント所有証明の発行要求を、前記アカウント管理装置に出力し、
   前記アカウント管理装置は、前記保険請求情報に含まれる、前記デジタル通貨の保険契約を識別するための保険契約識別情報と前記アカウント識別情報と前記デジタル通貨を識別するためのデジタル通貨識別情報とを用いて生成した、前記被保険者を所有者とする前記アカウント所有証明のトークンの発行要求を前記決済装置に出力し、
   前記決済装置は、前記トークンを識別するためのトークン識別情報と前記トークンの値と前記トークンの所有者とを対応付けた第１のテーブルに、前記発行要求を受けた前記トークンを追加し、当該追加した結果をトークン発行取引結果として前記アカウント管理装置に出力し、
   前記アカウント管理装置は、前記トークン発行取引結果に対して、前記追加した前記トークンの所有者を保険会社とする移転要求を前記決済装置に出力し、
   前記決済装置は、前記第１のテーブルに追加された前記トークンの所有者を前記保険会社に更新し、当該更新した結果をトークン移転取引結果として前記アカウント管理装置に出力し、
   前記アカウント管理装置は、前記決済装置から前記トークン移転取引結果を受け取ると、前記アカウント所有証明の発行完了を前記端末装置に出力し、
   前記端末装置は、前記アカウント所有証明の発行完了に基づいて、前記アカウント所有証明の提出完了を前記保険請求査定装置に出力し、
   前記保険請求査定装置は、前記保険契約識別情報により識別される保険契約情報を管理する第２のテーブルと、前記通貨識別情報により識別されるデジタル通貨についての事故情報を管理する第３のテーブルとを用いて、前記保険請求情報に基づく保険請求に対する査定を行う、
   ことを特徴とする保険請求方法。
7. 請求項６に記載の保険請求方法であって、
   前記決済装置は、前記保険契約識別情報と同じ識別情報をもつ前記トークンを識別するためのアカウント所有証明トークン識別情報により、前記対応付けを行って、前記第１のテーブルに前記トークンを追加する、
   ことを特徴とする保険請求方法。
8. 請求項６に記載の保険請求方法であって、
   前記アカウント管理装置は、前記保険契約識別情報、前記アカウント識別情報、前記デジタル通貨識別情報に加え、さらに、前記保険請求査定装置において生成された前記保険請求に対する査定の検証を行うための検証コードを、ハッシュ関数に入力してハッシュ値を生成し、生成したハッシュ値を前記トークンの値とした前記アカウント所有証明のトークンを前記決済装置に出力し、
   前記決済装置は、前記トークンを、前記発行取引ごとに対応付けて、第４のテーブルに記録する、
   ことを特徴とする保険請求方法。
9. 請求項８に記載の保険請求方法であって、
   前記保険請求査定装置は、前記端末装置から前記保険請求情報を受け取ったときの前記保険契約識別情報、前記アカウント識別情報、前記デジタル通貨識別情報、前記検証コードをハッシュ関数に入力してハッシュ値を生成し、生成した当該ハッシュ値が、前記第４のテーブルに記録した前記トークン値と一致するか否かを判定する、
   ことを特徴とする保険請求方法。
10. 請求項６に記載の保険請求方法であって、
    前記アカウント管理装置は、前記保険請求の際に前記保険請求査定装置において生成された前記検証コードのタイムスタンプを出力し、
    前記アカウント管理装置は、前記トークンを識別するためのトークン識別情報と、前記トークンの値と、前記発行取引を実行した時刻のタイムスタンプとを、前記トークンの前記発行取引ごとに対応付けて、第５のテーブルに記録し、
    前記決済装置は、前記検証コードのタイムスタンプが、前記発行取引を実行した時刻のタイムスタンプよりも早い場合に、前記保険請求情報に基づく保険請求に対する査定を行う、
    ことを特徴とする保険請求方法。
11. プロセッサとメモリとを有したコンピュータに、
    ユーザから入力されたデジタル通貨の保険請求手続きに関する保険請求情報を出力する処理と、
    前記保険請求情報に含まれる、前記ユーザのアカウントを識別するためのアカウント識別情報により識別されるユーザが被保険者としてアカウントを所有していることを証明するためのアカウント所有証明の提出を要求する処理と、
    前記アカウント所有証明の発行要求を出力する処理と、
    前記保険請求情報に含まれる、前記デジタル通貨の保険契約を識別するための保険契約識別情報と前記アカウント識別情報と前記デジタル通貨を識別するためのデジタル通貨識別情報とを用いて生成した、前記被保険者を所有者とする前記アカウント所有証明のトークンの発行要求を出力する処理と、
    前記トークンを識別するためのトークン識別情報と前記トークンの値と前記トークンの所有者とを対応付けた第１のテーブルに、前記発行要求を受けた前記トークンを追加し、当該追加した結果をトークン発行取引結果として出力する処理と、
    前記トークン発行取引結果に対して、前記追加した前記トークンの所有者を保険会社とする移転要求を出力する処理と、
    前記第１のテーブルに追加された前記トークンの所有者を前記保険会社に更新し、当該更新した結果をトークン移転取引結果として出力する処理と、
    前記トークン移転取引結果を受け取ると、前記アカウント所有証明の発行完了を出力する処理と、
    前記アカウント所有証明の発行完了に基づいて、前記アカウント所有証明の提出完了を出力する処理と、
    前記保険契約識別情報により識別される保険契約情報を管理する第２のテーブルと、前記通貨識別情報により識別されるデジタル通貨についての事故情報を管理する第３のテーブルとを用いて、前記保険請求情報に基づく保険請求に対する査定を行う処理と、
    を実行させることを特徴とする保険請求プログラム。

Images