JP2019036007A

JP2019036007A - 保険請求支援システム、および、保険請求支援方法

Info

Publication number: JP2019036007A
Application number: JP2017155257A
Authority: JP
Inventors: 絵里子岩佐; Eriko Iwasa; 四七　秀貴; Hideki Shina; 秀貴四七; 智広岡田; Tomohiro Okada
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2017-08-10
Filing date: 2017-08-10
Publication date: 2019-03-07

Abstract

【課題】サービス事業者が提供するサービスのＳＬＡに配慮しつつ、サービス事業者の収益性を向上させること。【解決手段】保険請求支援システムは、事前に設定されたＳＬＡに従ってサービスＶＭ１２を計算機環境２２上で動作させ、その動作内容を監視した結果のログデータが格納されるロギング部４５と、ロギング部４５から読み込んだログデータが示す計算機環境２２の動作内容が外部要因によりＳＬＡの水準を下回ったときに、保険金を求めるための計算式を計算することで、その計算結果である保険金の請求額を含む保険金請求データを保険金監査部３３に送信する保険金算出部４６と、受信した保険金請求データを監査することで、保険金の請求額を支払うか否かを決定する保険金監査部３３と、を有する。【選択図】図４

Description

本発明は、保険請求支援システム、および、保険請求支援方法の技術に関する。

特定のハードウェアを前提としたアプリケーション開発によるコスト増大が問題となっている。コストとは、設備投資コスト（ＣＡＰＥＸ：capital expenditure）だけでなく、運用コスト（ＯＰＥＸ：operating expenditure）も含まれる。それらのコストを削減するためのコア技術として、ハードウェアの仮想化技術が注目されている。

例えば、ＫＶＭ（Kernel-based Virtual Machine）のようなサーバ仮想化技術は、ＯＳ（Operating System）の標準機能として組み込まれるなど、広く普及している。このサーバ仮想化技術は、ハードウェアとＯＳとの間に位置するハイパーバイザがハードウェアの物理構成を隠蔽することで、ゲストＯＳが仮想マシンを物理マシンと同等に扱うことを可能とする。即ち、ゲストＯＳで特別な対応をすることなく、計算資源を各仮想マシンに対して柔軟に割り当てることが可能となる。

また、仮想化されたサーバをリモートから利用するクラウド化されたＷｅｂサービスが一般的になっている。このようにプール化された汎用サーバを需要に応じて払い出すＩａａＳ（Infrastructure as a Service）により資源利用効率の最適化が可能である。近年ではＩａａＳの基盤となるオープンソフトウェアが登場しており、プール化された資源を利用するためのＩａａＳのＡＰＩ（Application Programming Interface）についてもデファクトスタンダード化が進んでいる。

一方、ネットワークシステムにおいては、５Ｇ（第５世代）ネットワークに向け、ネットワークシステムに高い柔軟性や迅速性が求められている。また、ネットワークサービスの多様化に伴い、キャリア網を構成するハードウェアの多種多様化が進んでいる。そのため、ネットワークシステムにおける仮想化技術として、ＮＦＶ（Network Function Virtualization）リファレンスアーキテクチャが提案されている。
非特許文献１，２は、欧州電気通信標準化機構（ＥＴＳＩ：European Telecommunications Standards Institute）のＮＦＶＩＳＧ（Industry Specification Group）が作成した、ＮＦＶリファレンスアーキテクチャに関する基本勧告書である。

ＮＦＶのアーキテクチャでは、Ｗｅｂ市場やエンタープライズ市場を中心として利用されてきた仮想化技術やＩａａＳをキャリアネットワークに適用し、物理的なリソースを論理的に統合したリソースプールとして抽象化することを特徴とする。具体的には、ＮＦＶのアーキテクチャでは、以下の３つの構成要素が定義される。
（１）ＶＮＦ（Virtualized Network Function）は、共通的な汎用ハードウェア上で動作する、仮想化されたネットワーク機能である。
（２）ＮＦＶＩ（Network Functions Virtualization Infrastructure）は、ＶＮＦを配備する計算機環境を構築するためのハードウェアデバイスと、そのハードウェアデバイス上で動作するハイパーバイザなどの仮想化を実現するソフトウェアである。
（３）ＭＡＮＯ（NFV Management and Orchestration）は、ＶＮＦおよびＮＦＶＩを管理する仮想化管理機能である。

ＭＡＮＯでは、求められるサービス内容の水準を示すＳＬＡ（Service Level Agreement）を満たす仮想環境の運用をすることが求められる。ＳＡＬ（Service availability level）は、ＳＬＡを規定するための要素である。ＶＮＦＤ（ＶＮＦ Descriptor）は、サービス事業者が複数のＶＮＦを接続してサービスを構成するための構成情報・要件や、ＶＮＦを構成するためのインフラの情報・要件の集合体を記述するためのデータ形式である。

ところで、多くの企業にとってＩＴ（information technology）を活用した業務は不可欠であり、データの消失・破壊、システムの中断、情報漏えい、ＩＴシステムを構成するプログラムの著作権侵害などにより、多額の損害賠償を求められるケースが増えている。
そこで、非特許文献３のように、このようなITを活用した業務で生じ得る賠償事故に対し、被害者への賠償金や訴訟費用を補填する保険サービスが存在する。

ETSI、「ETSI GS NFV-MAN 001 v1.1.1」、［online］、2014年12月、［2017年8月1日検索］、インターネット〈URL：http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf〉 ETSI、「ETSI GS NFV-IFA 011 V2.1.1」、［online］、2016年10月、［2017年8月1日検索］、インターネット〈URL：http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_NFV-IFA011v020101p.pdf〉損保ジャパン日本興和、「商賠繁盛（IT事業）」、［online］、2015年3月5日、［2017年8月1日検索］、インターネット〈URL：http://www.sjnk.co.jp/hinsurance/risk/liability/sh_it/〉

ネットワーク事業者が保持する通信サービスや計算機環境の利用権をサービス事業者に貸し出し、サービス事業者が前記通信サービスや計算機環境に付加価値をつけて企業や一般ユーザにサービスを提供する形態が普及している。このようなサービス形態は、Ｂ２Ｂ２Ｘ（Business to Business to X）モデルと呼ばれる。Ｂ２Ｂ２Ｘの最初の「Ｂ」がネットワーク事業者を示し、次の「Ｂ」がサービス事業者を示し、最後の「Ｘ」が企業や一般ユーザを示す。
このＢ２Ｂ２Ｘモデルにより、ネットワーク事業者は利用権のレンタル代金をサービス事業者から得ることができ、計算機環境を有効活用できる。また、サービス事業者は自身で環境を準備することなく、レンタルした計算機環境を活用したサービスをすることができる。

なお、Ｂ２Ｂ２Ｘモデルだけでなく、Ｂ２Ｃ（Business to Consumer）モデルなどでも、サービス事業者は自身の顧客である一般ユーザに対して、サービス内容に応じたＳＬＡ（Service Level Agreement）を遵守する必要がある。
そのため、サービス事業者は、多量な予備リソースの事前確保や、最大トラフィックを考慮した余剰なリソースの割り当てなどで、レンタルした計算機環境への障害に備えることとなる。しかし、これらの障害対策は、障害が発生しなかったときには過剰投資となってしまい、サービス事業者の収益性を低下させてしまう。

そこで、本発明は、サービス事業者が提供するサービスのＳＬＡに配慮しつつ、サービス事業者の収益性を向上させることを、主な課題とする。

前記課題を解決するために、本発明の保険請求支援システムは、以下の特徴を有する。
本発明は、事前に設定されたＳＬＡ（Service Level Agreement）に従ってサービスＶＭ（Virtual Machine）を計算機環境上で動作させ、その動作内容を監視した結果のログデータが格納されるログ記憶部と、
前記ログ記憶部から読み込んだ前記ログデータが示す前記計算機環境の動作内容が外部要因により前記ＳＬＡの水準を下回ったときに、保険金を求めるための計算式を計算することで、その計算結果である保険金の請求額を含む保険金請求データを送信する保険金算出部と、
受信した前記保険金請求データを監査することで、保険金の請求額を支払うか否かを決定する保険金監査部と、を有することを特徴とする。

これにより、障害発生などにより計算機環境の動作内容が外部要因により前記ＳＬＡの水準を下回ったときには、保険金が自動的に請求されることで、その保険金を得る計算機環境の利用者に配慮する。
そして、サービス事業者は、ＳＬＡを絶対に遵守できるように過剰に予備リソースを確保する必要がなくなり、適切な収益性を確保できる。

本発明は、前記保険金算出部が、計算結果である保険金の請求額に加えて、その請求額の計算に使用した計算用データも含めた前記保険金請求データを前記保険金監査部に送信し、
前記保険金監査部が、受信した前記保険金請求データを監査する処理として、前記保険金請求データに含まれる前記計算用データをもとに、前記ＳＬＡを遵守していないときの保険金を求めるための計算式を再計算し、前記保険金算出部の計算結果である保険金の請求額と、前記保険金監査部の再計算結果である保険金の請求額とが一致するときに、保険金の請求額を支払うと決定することを特徴とする。

これにより、保険金監査部が誤った保険金の請求額を含む保険金請求データを受信してしまった場合でも、保険金の請求額を再計算することで、適切に保険金の請求を却下できる。

本発明は、前記保険金算出部が、前記保険金請求データに含めた前記計算用データに対して電子署名を付してから前記保険金監査部に送信し、
前記保険金監査部が、前記保険金請求データに含まれる前記計算用データに前記電子署名が付されていないときには、保険金の請求額を支払わないと決定することを特徴とする。

これにより、動作内容を監視した結果のログデータが、電子署名が付された客観的な証拠データであることがわかるので、保険金監査部は、偽造されるなどの信頼性の低い保険金請求データを受信してしまった場合でも、適切に保険金の請求を却下できる。

本発明は、保険請求支援システムが、さらに、第１監視部と第２監視部とを有しており、
前記第１監視部が、前記サービスＶＭの動作内容を監視して、その監視結果を第１ログデータとして前記ログ記憶部に格納し、
前記第２監視部が、前記計算機環境の稼働内容を監視して、その監視結果を第２ログデータとして前記ログ記憶部に格納することを特徴とする。

これにより、Ｂ２Ｂ２Ｘサービスについて、計算機環境を利用するサービス事業者への損害額を第２ログデータから求めることができ、サービス事業者からサービスを受ける一般ユーザへの損害額を第１ログデータから求めることができる。よって、保険金の計算式として、サービス事業者への損害額と一般ユーザへの損害額とを組み合わせた計算式を用いることで、保険会社との複雑な約款にも即した保険金の請求額を求めることができる。

本発明によれば、サービス事業者が提供するサービスのＳＬＡに配慮しつつ、サービス事業者の収益性を向上させることができる。

本実施形態に係わるＢ２Ｂ２Ｘのサービス形態を示す説明図である。本実施形態に係わる図１のサービス形態における保険請求手続を示す説明図である。本実施形態に係わる保険請求までの各処理の概要を示すフローチャートである。本実施形態に係わる図２のＢ２Ｂ２Ｘサービスを実現する保険請求支援システムの構成図である。本実施形態に係わるサービスＶＭおよび計算機環境の具体例を示す構成図である。本実施形態に係わるライフサイクル管理部および仮想リソース管理部の詳細を示す構成図である。本実施形態に係わる保険金算出部および保険金監査部の詳細を示す構成図である。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１は、ネットワーク事業者２０、サービス事業者１０、一般ユーザ９０によるＢ２Ｂ２Ｘのサービス形態を示す説明図である。
ネットワーク事業者２０は、自身の管理する計算機環境２２のレンタル権をサービス事業者１０に提供することで、そのレンタル料金を得る事業者である。なお、計算機環境２２として通信回線をレンタルするネットワーク事業者２０を例示するが、その他にも計算機環境２２としてクラウドサーバをレンタルするクラウド事業者や、計算機環境２２としてＮＦＶ環境のハードウェアリソースをレンタルするＮＦＶ事業者にも適用可能である。ネットワーク事業者２０は、収益として得たレンタル料金をもとに計算機環境２２を増強することで、事業の拡大を狙う。

サービス事業者１０は、レンタルした計算機環境２２上でサービスを実行することで、一般ユーザ９０にサービスの利用権を与えるとともに、その一般ユーザ９０から利用料金を受け取る事業者である。そのため、サービス事業者１０は、実行するサービス内容についての開発運用費を負担する。
なお、ネットワーク事業者２０と同様に、計算機環境２２として通信回線のレンタルを受けるＭＶＮＯ（Mobile Virtual Network Operator）事業者をサービス事業者１０として例示するが、計算機環境２２としてクラウドサーバや、ＮＦＶ環境のレンタルを受けてもよい。

これにより、ＭＶＮＯ加入者などの一般ユーザ９０は、ネットワーク事業者２０や計算機環境２２のことに詳しくなくても、サービス事業者１０を窓口としてサービスを受けられる。なお、一般ユーザ９０が適切な水準のサービスが受けられるように、事前にサービス内容についてＳＬＡの契約がなされる。このＳＬＡは、例えば以下の２者間で契約がなされる。
・ネットワーク事業者２０からサービス事業者１０に対する契約
・サービス事業者１０から一般ユーザ９０に対する契約
・ネットワーク事業者２０から一般ユーザ９０に対する契約
なお、計算機環境２２の利用料金は、計算機環境２２のハードウェアリソースの使用状況や、ＳＬＡで保証するサービスレベルの高さなどにより異なる金額が設定される。一般的にはサービスの要求水準が高いほど、高額の利用料金が設定される。

図２は、図１のサービス形態における保険請求手続を示す説明図である。
保険会社３０は、サービス事業者１０との間で保険の契約（約款）を結ぶ。この約款は、もし計算機環境２２に突発的な障害やバーストトラフィックなどの外部要因が発生したことで、計算機環境２２の動作内容がＳＬＡの水準を下回ったときには、その損害を賠償するために保険金を支払う損害保険である。
つまり、ＳＬＡの契約内容が守られていないときに、保険会社３０は、サービス事業者１０に違反の度合いに応じて保険金を支払う。この保険金をもとに、サービス事業者１０は、一般ユーザ９０に対してＳＬＡの違約金を返金する。
この保険金請求権と引き替えに、保険会社３０は、サービス事業者１０から１回または定期的に（月額、年額など）保険料を得る。

なお、前記の例では、保険会社３０とサービス事業者１０との間の約款を例示したが、ネットワーク事業者２０、サービス事業者１０、一般ユーザ９０の３者間でＳＬＡが契約されることに伴い、保険会社３０との間の約款は、サービス事業者１０に代えて、ネットワーク事業者２０が結んでもよいし、一般ユーザ９０が結んでもよい。
例えば、サービス事業者１０とネットワーク事業者２０との間のＳＬＡが遵守できないときに、ネットワーク事業者２０が保険会社３０から保険金を受け取るようにしてもよい。そのときには、サービス事業者１０は、ネットワーク事業者２０から保険金をもとにした違約金を受け取ることができる。

サービス事業者１０が保険会社３０に対して保険金を円滑に請求できるように、かつ、保険会社３０が請求された保険金を正しく監査できるように、保険連携装置４０が用意される。
保険連携装置４０は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。

保険連携装置４０は、計算機環境２２の正常動作時には、その動作内容がＳＬＡを遵守しているか否かを監視する。そして、保険連携装置４０は、計算機環境２２に障害が発生したことでレンタルが中断したとき（広義には、ＳＬＡ違反時）には、その障害内容を示す障害データ（ログデータ）を測定する。保険連携装置４０は、収集した障害データに加え、その障害データから約款で定義される保険金の算出式によって求められる保険金の請求データを保険会社３０に送信する。

保険会社３０は、保険連携装置４０から自動的に送信された保険金の請求データを監査し、監査に通過したときにはサービス事業者１０に対して保険金を支払う。これにより、サービス事業者１０は障害発生によりサービス中断の迷惑をかけた一般ユーザ９０に対して、利用料金の返金を実施できる。
なお、サービス事業者１０が保険会社３０に保険金を直接請求する場合に比べ、ネットワーク事業者２０が運営管理する保険連携装置４０から、ログデータという客観的な証拠データを送信する方式により、保険会社３０は監査業務において証拠データを検証する手間を削減できる。

このように、サービス事業者１０にとっては、突発的な障害によりＳＬＡを下回った際には保険金を使ってユーザへ違約金を補償すればよい。よって、サービス事業者１０は、ＳＬＡの内容を絶対に遵守することを前提とした、過剰な計算機環境２２のレンタルを行わなくて済む。
また、一般ユーザ９０にとっては、一時的にＳＬＡを満たすことができなかった場合に違約金という形で損害が補填されるので、安心してサービスの利用券を買うことができる。

図３は、保険請求までの各処理の概要を示すフローチャートである。このフローチャートは、図４以降で後記する保険連携装置４０の詳細な説明において、適宜参照される。
Ｓ１１として、Ｂ２Ｂ２Ｘサービスのユーザ（ネットワーク事業者２０、サービス事業者１０、または、一般ユーザ９０）と、保険会社３０との間での保険契約に伴い、保険会社３０に保険料の支払いが行われる。
Ｓ１２として、ネットワーク事業者２０は、レンタルした計算機環境２２上でサービスを実行するための各種準備を行う。
Ｓ１３として、ネットワーク事業者２０は、Ｓ１２で準備したサービスを実行する。このサービス実行中に、保険連携装置４０はサービス内容がＳＬＡを遵守しているか否かを監視する。
Ｓ１４として、保険連携装置４０は、Ｓ１３の監視中に障害が発生したときに、保険会社３０に保険金を請求する。

図４は、図２のＢ２Ｂ２Ｘサービスを実現する保険請求支援システムの構成図である。
サービス事業者１０は、被保険者として保険料を支払うとともに保険金を受け取るための保険用口座１１をもち、計算機環境２２上でサービスを実行するためのサービスＶＭ（Virtual Machine）１２を用意する。なお、説明をわかりやすくするために、図示ではサービス事業者１０を示す枠の内部に保険用口座１１とサービスＶＭ１２とを配置したが、実際には、保険用口座１１は銀行口座として銀行内のサーバに用意され、サービスＶＭ１２は後記するＶＭ／ＶＮＦイメージ用リポジトリ４２内のイメージファイルとして用意される。

ネットワーク事業者２０は、被保険者として保険料を支払うとともに保険金を受け取るための保険用口座２１をもち、サービスＶＭ１２を動作させる計算機環境２２を用意する。なお、サービス事業者１０と同様に、保険用口座２１は銀行口座であり、計算機環境２２のハードウェアリソースは、ネットワーク事業者２０の会社内に配備しなくてもよい。
保険用口座１１、２１は、Ｓ１１で保険料を支払い、Ｓ１４で請求した保険金を受け取るための口座である。

保険連携装置４０は、運用定義ファイル用リポジトリ４１と、ＶＭ／ＶＮＦイメージ用リポジトリ４２と、ライフサイクル管理部４３と、仮想リソース管理部４４と、ロギング部４５と、保険金算出部４６とを有する。以下では、Ｓ１２のサービス準備段階、Ｓ１３のサービス実行段階、Ｓ１４の保険金請求段階に分けて、各段階で動作する処理部を説明する。

まず、Ｓ１２（図３）のサービス準備段階についての保険連携装置４０の詳細を説明する。
Ｓ１２では、サービス事業者１０は、以下の２つのリポジトリに対して、自身がこれから提供するサービスの内容を登録しておく。
ＶＭ／ＶＮＦイメージ用リポジトリ４２には、サービス事業者１０から提供されるサービスＶＭ１２のイメージファイルが格納される。このイメージファイルとは、計算機環境２２上で実行されるサービス内容を記載したプログラムファイル（実行用ファイル）が計算機環境２２上でそのまま実行できるようにイメージ化されたＩＳＯ（International Organization for Standardization）イメージなどである。
運用定義ファイル用リポジトリ４１は、ＶＭ／ＶＮＦイメージ用リポジトリ４２のイメージファイルを運用するときの（計算機環境２２上で実行するときの）運用定義ファイルが格納される。この運用定義ファイルには、図１で説明したＳＬＡの内容やその内容に従った設定ファイルが含まれる。

図５は、サービスＶＭ１２および計算機環境２２の具体例を示す構成図である。
サービスＶＭ１２として、１つの管理用ＶＭ１２０ａと、２つのサービス用ＶＭ１２０ｂとを例示する。管理用ＶＭ１２０ａは、管理用モジュール１２１ａと、管理用ＯＳ１２２ａと、仮想リソース１２３とを有する。サービス用ＶＭ１２０ｂは、サービスのアプリケーションモジュールであるＡｐｐ１２１ｂと、ゲストＯＳ１２２ｂと、仮想リソース１２３とを有する。

管理用モジュール１２１ａは、例えば、管理用ＯＳ１２２ａ上でゲストＯＳ１２２ｂのリソース情報を提供するコマンドを提供するモジュール、および、ゲストＯＳ１２２ｂのリソース情報をグラフ表示するためのモジュールなどである。
管理用ＯＳ１２２ａは、各ゲストＯＳ１２２ｂを管理するためのＯＳである。計算機環境２２（仮想化層２２０ａ）は、管理用ＯＳ１２２ａにアクセスすることで、ゲストＯＳ１２２ｂに仮想リソース１２３を割り当て、ゲストＯＳ１２２ｂをサービス用ＶＭ１２０ｂにインストールする。
仮想リソース１２３は、計算機環境２２のハードウェアリソース２２０ｂが仮想化されたものであり、例えば、仮想ＣＰＵ、仮想メモリ、仮想ディスク、仮想ネットワークインタフェースなどである。

計算機環境２２は、ハードウェアリソース２２０ｂが仮想化層２２０ａにより仮想化された実行環境をサービスＶＭ１２に提供する。
ハードウェアリソース２２０ｂは、例えば、ＣＰＵ（Central Processing Unit）などの演算部２２１ｂ、メモリやハードディスクなどの記憶部２２２ｂ、および、ネットワークインタフェースなどの通信部２２３ｂである。
仮想化層２２０ａは、Hypervisorの仮想化機構や、コンテナ型の仮想化機構などの仮想化機構である。仮想化層２２０ａは、ハードウェアリソース２２０ｂを仮想演算部２２１ａ、仮想記憶部２２２ａ、仮想通信部２２３ａなどの仮想化デバイスとして管理するとともに、それらの仮想化デバイスを仮想リソース１２３としてサービスＶＭ１２に提供する。

図４に戻って、Ｓ１３（図３）のサービス実行段階についての保険連携装置４０の詳細を説明する。なお、図４のシステムを非特許文献１のＮＦＶリファレンスアーキテクチャに適用すると、サービスＶＭ１２がＶＮＦであり、そのＶＮＦを動作させる計算機環境２２がＮＦＶＩであり、ＶＮＦおよびＮＦＶＩを管理する保険連携装置４０がＭＡＮＯである。
そして、ライフサイクル管理部４３はＶＮＦ（サービスＶＭ１２）を管理する「VNF Manager」であり、仮想リソース管理部４４はＮＦＶＩ（計算機環境２２）を管理する「Virtualized Infrastructure Manager」である。

ライフサイクル管理部４３は、運用定義ファイル用リポジトリ４１から取得した運用定義ファイルを解析し実行することで、サービスＶＭ１２のライフサイクルを管理する。そのために、ライフサイクル管理部４３は、instantiate/scale/update,upgrade/terminateなどの各種のリソース操作指示コマンドを仮想リソース管理部４４に通知する。

仮想リソース管理部４４は、ライフサイクル管理部４３からの指示に従い、リソース割り当てなどの各種のリソース操作（リソース起動操作、リソーススケジューリング、リソース終了操作）を計算機環境２２に対して実行する。例えば、仮想リソース管理部４４は、新たなサービスＶＭ１２を起動するときには、そのサービスＶＭ１２のイメージファイルをＶＭ／ＶＮＦイメージ用リポジトリ４２から取得する。

次に、Ｓ１４（図３）の保険金請求段階についての保険連携装置４０および保険会社３０の詳細を説明する。
ライフサイクル管理部４３は、サービスＶＭ１２のリソース利用状況を監視する。仮想リソース管理部４４は、計算機環境２２のリソース提供状況を監視する。
ロギング部４５（ログ記憶部）には、ライフサイクル管理部４３および仮想リソース管理部４４それぞれから通知された、監視結果としてのログデータが格納される。
格納されるログデータは、計算機環境２２の動作内容を示すデータである。ログデータは、例えば、クラウドサーバの内部処理を記録したデータや、通信回線を介する通信処理（パケット送信時刻など）を記録したデータである。
また、ロギング部４５は、ログデータに加えて、メトリクス（ログデータの統計データ）も格納してもよい。このメトリクスは、例えば、ライフサイクル管理部４３および仮想リソース管理部４４がログデータを読み込んで生成したものである。

保険金算出部４６は、ロギング部４５の保持するログデータおよびメトリクスを解析し、保険会社３０の保険契約（約款）の内容で規定される保険金の計算式に従い、保険金を算出する。そして、保険金算出部４６は、計算結果である保険金の請求データに対して、計算に使用したログデータやメトリクスを添付して、保険金監査部３３に送信する。

保険会社３０は、保険会社口座３１と、保険金支払部３２と、保険金監査部３３とを管理する。なお、保険金支払部３２と保険金監査部３３とは計算機の処理部として構成され、同じ計算機内に収容してもよいし、別々の計算機に分散させてもよい。
保険金監査部３３は、保険金算出部４６から受信した保険金の請求データを監査する。この監査処理は、例えば、保険金の請求データに添付されたログデータやメトリクスを用いて保険金を再計算し、その再計算された保険金の請求額が、受信した請求データで指定された請求額と一致するか否かを照合する処理である。保険金監査部３３は、請求額が一致したことにより監査に通過したときには、請求された保険金を支払うように、保険金支払部３２に指示する。
保険金支払部３２は、保険金監査部３３から指示された保険用口座１１、２１に対して、保険会社口座３１からの振り込み処理を実行する。

図６は、ライフサイクル管理部４３および仮想リソース管理部４４の詳細を示す構成図である。
ライフサイクル管理部４３は、運用ファイル取得部４３１と、運用ファイル実行部４３２と、データ記憶部４３３と、リソース操作指示部４３４と、ＶＮＦ監視部４３５と、通知部４３６とを有する。
仮想リソース管理部４４は、イメージファイル取得部４４１と、仮想リソース操作設定部４４２と、仮想リソース選択部４４３と、記憶部４４４と、ＮＦＶ監視部４４５と、通知部４４６とを有する。

以下、ライフサイクル管理部４３の詳細を説明する。
運用ファイル取得部４３１は、運用定義ファイル用リポジトリ４１から運用定義ファイルを取得する。
運用ファイル実行部４３２は、運用ファイル取得部４３１が取得した運用定義ファイルを解析し、その解析結果をもとにリソース操作指示部４３４に新規リソース割り当てなどのリソース操作を通知する。解析結果は、例えば、必要とするリソース情報（ＣＰＵ数やメモリ数、ＳＬＡなどで規定されたAffinityルール等のポリシなど）、および、操作内容（サービスＶＭ１２を追加するなど）である。
リソース操作指示部４３４では、運用ファイル実行部４３２からの通知を受け、具体的なリソース操作を仮想リソース操作設定部４４２に指示する。データ記憶部４３３には、リソース操作指示部４３４などで必要とするデータが一時的に保持される。

ＶＮＦ監視部４３５（第１監視部）は、運用ファイル実行部４３２で解析したＳＬＡ（必要とするリソース情報）に基づき、監視対象のサービスＶＭ１２とその監視方法を設定し、その設定に沿って監視を行う。具体例としては、起動したサービスＶＭ１２に対して、ＩＣＭＰ（Internet Control Message Protocol）−ＰＩＮＧを20秒間隔で実施する。通知部４３６は、ＶＮＦ監視部４３５の監視結果（第１ログデータ）を定期的にロギング部４５に通知する。

以下、仮想リソース管理部４４の詳細を説明する。
仮想リソース操作設定部４４２はリソース操作指示部４３４からの通知に従い、仮想リソース１２３（図５）の追加や削除などのリソース操作を行う。
仮想リソース選択部４４３は、リソース操作指示部４３４から通知されたリソース情報を満たす仮想リソース１２３を選択する。イメージファイル取得部４４１は、仮想リソース１２３の追加が必要な場合に仮想リソース選択部４４３からの指示を受け、関連するイメージファイルをＶＭ／ＶＮＦイメージ用リポジトリ４２から取得する。
記憶部４４４には、仮想リソース１２３の管理情報などの仮想リソース管理部４４で必要とするデータが格納される。

ＮＦＶ監視部４４５（第２監視部）は、ＶＮＦ監視部４３５と同様に、運用ファイル実行部４３２で解析したＳＬＡに基づき、監視対象の計算機環境２２とその監視方法を設定し、その設定に沿ってパケットロス数、ＣＰＵ使用率などの監視を行う。なお、ＮＦＶ監視部４４５とＶＮＦ監視部４３５との相違点について、ＶＮＦ監視部４３５はサービスＶＭ１２をアプリケーションレベルで監視し、ＮＦＶ監視部４４５は計算機環境２２をアプリケーションレベルで監視する。
通知部４４６は、ＮＦＶ監視部４４５の監視結果（第２ログデータ）を定期的にロギング部４５に通知する。

図７は、保険金算出部４６および保険金監査部３３の詳細を示す構成図である。
保険金算出部４６は、ログ解析部４６１と、ログ取得部４６２と、ログ作成部４６３と、通知部４６４とを有する。
保険金監査部３３は、監査部３３１と、データ取得部３３２と、通知部３３３とを有する。

以下、保険金算出部４６の詳細を説明する。
ログ取得部４６２は、ログデータおよびメトリクスをロギング部４５から取得する。
ログ解析部４６１は、ログ取得部４６２が取得したログデータおよびメトリクスを解析し、例えば以下の計算式に従い、保険金を算出する。
保険金の請求額＝floor((連続失敗カウント数)/(定数α))×(単位あたりの保険金)
「連続失敗カウント数」とは、ライフサイクル管理部４３で取得したPINGの疎通が連続で失敗した回数である。
floorは、実数値から小数を切り捨てて整数化する床関数である。
「単位あたりの保険金」は、ＳＬＡのレベルに応じて事前に設定する。

ログ作成部４６３は、ログ取得部４６２が取得したデータから、ログ解析部４６１の保険金算出の根拠となるデータを計算用データとして抽出する。通知部４６４は、ログ解析部４６１が算出した保険金の請求額と、ログ作成部４６３が抽出した計算用データとを、保険金の請求データとして保険金監査部３３に送信する。

以下、保険金監査部３３の詳細を説明する。
データ取得部３３２は、通知部４６４から保険金の請求データを受け取る。
監査部３３１は、データ取得部３３２が取得した保険金の請求データを監査する。この監査処理は、例えば、保険金の請求額の計算結果が正しいか否かを再計算する処理である。監査部３３１は、保険金の請求データに含まれる計算用データをもとに、ログ解析部４６１が保険金を算出するときに用いた計算式に従い、保険金の請求額を再計算する。なお、この再計算に使用する計算式は、約款で規定されたものであるため、基本的にはログ解析部４６１の計算式と、監査部３３１の計算式とは同一である。よって、同じ入力パラメータ（計算用データ）で、同じ計算式を用いて求めた保険金の請求額は、初回計算時も再計算時も一致するはずである。

監査部３３１は、再計算した保険金の請求額と通知部４６４から通知された保険金の請求額とを比較し、金額が一致するときには、監査を合格とする。一方、古い約款に基づく計算式をログ解析部４６１が用いていたなどの理由により金額が不一致の場合には、監査部３３１は、監査を不合格とする。
通知部３３３は、監査に合格した保険金の請求データを監査部３３１から受け取り、保険金支払部３２に対して保険金の支払いを指示する。保険金支払部３２は、オンラインバンキングなどの仕組みを利用して保険金の振込処理を行う。

なお、監査部３３１による監査処理は、金銭のやりとりに直結する重要な処理なので、とくに高い信頼性が要求される。そのため、前記した再計算処理だけでなく、約款で規定された損害が実際に発生した証拠を確認することが望ましい。そのため、例えば、保険連携装置４０（保険金算出部４６）は、ロギング部４５に格納するログデータおよびメトリクスに対して、保険連携装置４０の管理者であるネットワーク事業者２０の電子署名を付してもよい。この電子署名は、保険連携装置４０が自身の作成したデータであることを証明するためのものである。
そして、監査部３３１は、保険金の請求データに含まれる計算用データに対して、前記の電子署名が付されていないときには、監査に不合格としてもよい。

以上説明した本実施形態では、Ｂ２Ｂ２ＸモデルにおけるＩＴ事業者保険サービスと、その保険サービスを実現するためのシステムを説明した。具体的には、ネットワーク事業者２０がサービス事業者１０や一般ユーザ９０と事前に契約したＳＬＡに基づき、保険連携装置４０がサービスＶＭ１２、計算機環境２２を監視する。監視中に発生した障害によりＳＬＡが担保できない場合は、保険連携装置４０は、保険会社３０に対して保険金を請求する。
これにより、サービス事業者１０は、ＳＬＡを絶対に遵守できるように過剰に予備リソースを確保しなくても済む。よって、ネットワーク事業者２０は、障害が発生せずに実際に利用される可能性の高い計算機環境２２を用意するだけで済むので、計算機環境２２の設備投資を効率的に行うことができる。

また、計算機環境２２の利用権を得るサービス事業者１０や一般ユーザ９０は、事前に契約したＳＬＡが担保できない場合は、保険金を受け取ることができるため、予期せぬ障害発生のリスクを自身で負うことがなくなる。よって、安心して計算機環境２２の利用権を購入できる。
さらに、保険会社３０は、計算機環境２２そのものの物的損害とは別に、計算機環境２２の利用権を新たに損害保険の被保険対象に追加できるので、保険市場拡大の恩恵を受ける。

以下では、ネットワーク事業者２０の代わりに、ストリーミングサーバを計算機環境２２として提供するクラウド事業者の事例を説明することで、図４の保険請求支援システムを利用者の立場で明らかにする。以下、図３のフローチャートに沿って説明する。
以下の事例は、サービス事業者１０が、ストリーミングサーバ10台分の計算機環境２２を、8/1(火)の午後7:00-9:00にクラウド事業者からレンタルして、多数の一般ユーザ９０にライブ配信サービスを提供するものである。

Ｓ１１（図３）の保険契約段階では、サービス事業者１０と保険会社３０との間の契約（約款）として、以下が設定される。なお、保険料と保険金の最高金額とは、ライブ配信サービスの規模（チケット代、想定するユーザ数）に依存して決定される。
（契約１）サービス事業者１０の保険用口座１１から保険会社３０の保険会社口座３１に支払われる、今回の２時間分の保険料は10万円である。
（契約２）保険会社３０からサービス事業者１０に支払われる保険金は、サービス事業者１０から一般ユーザ９０に返金するチケット代金のユーザ数分の総額を上限とする。返金するチケット代金は、損害の大きさによって返金額が大きくなる。例えば、配信停止時間が5分以上〜10分未満の場合は、チケット代金の半額が返金され、配信停止時間が10分以上の場合は、チケット代金の全額が返金される。
（契約３）計算機環境２２の稼働率に応じて、稼働停止時間が長くなるほど、サービス事業者１０に支払われる保険金も大きくなる。例えば、稼働率99％以上100%未満で、レンタル料の5％に相当する保険金が支払われ、稼働率99％未満で、稼働していない中断時間の長さに応じて、レンタル料の50％を上限とする保険金が支払われる。なお、99％以上の稼働率とは、午後7:00-9:00の間に稼働しなかった時間が72秒以下であることを示す。

Ｓ１２（図３）のサービス準備段階として、クラウド事業者は、サービス事業者１０との間で交わしたＳＬＡ「ストリーミングサーバ10台分の計算機環境２２を、8/1(火)の午後7:00-9:00にレンタルする」を示す運用定義ファイルを、運用定義ファイル用リポジトリ４１に登録する。また、保険用口座１１から保険用口座２１に対して、計算機環境２２のレンタル料として100万円が振り込まれる。
そして、ＶＭ／ＶＮＦイメージ用リポジトリ４２には、サービス事業者１０が用意したライブ配信用プログラムのイメージファイルが事前に登録される。

Ｓ１３（図３）のサービス実行段階では、ＶＮＦ監視部４３５は、（契約２）の配信停止時間を求めるために、ライブ配信用プログラムのイメージファイルが実行されたサービスＶＭ１２に対して、8/1(火)の午後7:00-9:00に5秒間隔でICMP-Pingを送信し、その結果（疎通成功または疎通失敗）をロギング部４５にログデータとして記憶する。また、ＶＮＦ監視部４３５は、疎通が失敗した回数×5秒の合計値である配信停止時間を算出し、その配信停止時間をロギング部４５にメトリクスとして記憶する。
一方、ＮＦＶ監視部４４５は、（契約３）の稼働停止時間を求めるために、サービスＶＭ１２が稼働する計算機環境２２のＣＰＵ使用率を5秒間隔で監視する。ＮＦＶ監視部４４５は、その監視結果のログデータと、そのログデータから求めた稼働停止時間（メトリクス）とをロギング部４５に記憶する。

Ｓ１４（図３）の保険金請求段階では、保険金算出部４６は、以下の計算式から計算した保険金を保険会社３０に請求する。
・（契約２）に従い、ロギング部４５から取得した配信停止時間が5分以上〜10分未満の場合はユーザ数×チケット代金の半額、10分以上の場合はユーザ数×チケット代金の全額を、一般ユーザ９０の損害額とする。
・（契約３）に従い、ロギング部４５から取得した稼働停止時間の長さに応じた損害額を、サービス事業者１０の損害額とする。
・一般ユーザ９０の損害額と、サービス事業者１０の損害額とのうちの小さいほうの損害額を、保険会社３０に請求する保険金の請求額とする。

以上説明したように、（契約２）、（契約３）の内容が、保険金算出部４６の計算式、保険金監査部３３の再計算式、ライフサイクル管理部４３の監視パラメータ（配信停止時間）、仮想リソース管理部４４の監視パラメータ（稼働停止時間）に反映される。
これにより、ライブ配信中の配信停止事象の立証処理や、保険金請求額の計算処理などを含めた保険金請求の流れが自動化される。よって、多数の一般ユーザ９０はチケットの返金を早期に受けることができ、サービス事業者１０は配信停止事象の立証負担を減らして円滑に保険金を請求することができる。

なお、本実施形態においては、本発明に係る保険請求支援システムを、図２，４に示す保険連携装置４０を中心に説明したが、これに限定されない。例えば、本発明では、一般的なコンピュータのハードウェア資源を、保険請求支援システムの各手段として動作させるプログラムによって実現することができる。また、このプログラムは、通信回線を介して配布したり、ＣＤ−ＲＯＭ等の記録媒体に記録して配布したりすることも可能である。

１０サービス事業者
１１保険用口座
１２サービスＶＭ
２０ネットワーク事業者
２１保険用口座
２２計算機環境
３０保険会社
３１保険会社口座
３２保険金支払部
３３保険金監査部
４０保険連携装置
４１運用定義ファイル用リポジトリ
４２ＶＭ／ＶＮＦイメージ用リポジトリ
４３ライフサイクル管理部
４４仮想リソース管理部
４５ロギング部（ログ記憶部）
４６保険金算出部
９０一般ユーザ

Claims

事前に設定されたＳＬＡ（Service Level Agreement）に従ってサービスＶＭ（Virtual Machine）を計算機環境上で動作させ、その動作内容を監視した結果のログデータが格納されるログ記憶部と、
前記ログ記憶部から読み込んだ前記ログデータが示す前記計算機環境の動作内容が、外部要因により前記ＳＬＡの水準を下回ったときに、保険金を求めるための計算式を計算することで、その計算結果である保険金の請求額を含む保険金請求データを送信する保険金算出部と、
受信した前記保険金請求データを監査することで、保険金の請求額を支払うか否かを決定する保険金監査部と、を有することを特徴とする
保険請求支援システム。
前記保険金算出部は、計算結果である保険金の請求額に加えて、その請求額の計算に使用した計算用データも含めた前記保険金請求データを前記保険金監査部に送信し、
前記保険金監査部は、受信した前記保険金請求データを監査する処理として、前記保険金請求データに含まれる前記計算用データをもとに、前記ＳＬＡを遵守していないときの保険金を求めるための計算式を再計算し、前記保険金算出部の計算結果である保険金の請求額と、前記保険金監査部の再計算結果である保険金の請求額とが一致するときに、保険金の請求額を支払うと決定することを特徴とする
請求項１に記載の保険請求支援システム。
前記保険金算出部は、前記保険金請求データに含めた前記計算用データに対して電子署名を付してから前記保険金監査部に送信し、
前記保険金監査部は、前記保険金請求データに含まれる前記計算用データに前記電子署名が付されていないときには、保険金の請求額を支払わないと決定することを特徴とする
請求項２に記載の保険請求支援システム。
保険請求支援システムは、さらに、第１監視部と第２監視部とを有しており、
前記第１監視部は、前記サービスＶＭの動作内容を監視して、その監視結果を第１ログデータとして前記ログ記憶部に格納し、
前記第２監視部は、前記計算機環境の稼働内容を監視して、その監視結果を第２ログデータとして前記ログ記憶部に格納することを特徴とする
請求項１ないし請求項３のいずれか１項に記載の保険請求支援システム。
保険請求支援システムは、ログ記憶部と、保険金算出部と、保険金監査部とを有しており、
前記ログ記憶部には、事前に設定されたＳＬＡ（Service Level Agreement）に従ってサービスＶＭ（Virtual Machine）を計算機環境上で動作させ、その動作内容を監視した結果のログデータが格納され、
前記保険金算出部は、前記ログ記憶部から読み込んだ前記ログデータが示す前記計算機環境の動作内容が外部要因により前記ＳＬＡの水準を下回ったときに、保険金を求めるための計算式を計算することで、その計算結果である保険金の請求額を含む保険金請求データを前記保険金監査部に送信し、
前記保険金監査部は、受信した前記保険金請求データを監査することで、保険金の請求額を支払うか否かを決定することを特徴とする
保険請求支援方法。