JP2016103275A - 通信装置及び通信装置を含むシステム - Google Patents

Abstract

【課題】保険料を適切に管理する通信装置及びシステムを提供する。
【解決手段】通信装置は、第１保険（例えば生命保険）の第１保険料と、第１保険と異なる第２保険（例えば自動車保険）の第２保険料であって、第１保険料が上がると第２保険料が上昇し、第１保険料が下がると、第２保険料が下がるように各保険料を算出し、各保険料を表示する表示部を備える。
【選択図】図２１Ａ

Description

ここに述べる実施形態は、一般に、通信装置及び通信装置を含むシステムに関する。

近年では、身体に装着するウェアラブルデバイスが開発されている。

保険料を適切に管理する。

通信端末は、第1保険の第1保険料と、前記第1保険と異なる第2保険の第2保険料であって、第1保険料が上がると上昇する第2保険料とを表示できる表示部を備える。

図１は、保険の分類を示す概念図。 図２は、第１実施形態に係るシステムの全体構成を示す概念図。 図３は、第１実施形態に係るウェアラブルデバイスの構成例。 図４は、第１実施形態に係る車載センサ及び車両の構成例。 図５は、第１実施形態に係る車載センサの概念例。 図６は、第１実施形態に係る車載センサのうち、センサ１２０−１〜１２０−３の動作を示すフローチャートの例。 図７は、第１実施形態に係る通信端末の構成例。 図８Ａは、第１実施形態において、保険料の算出をするための元データの計測の開始する場合に、ユーザの通信端末に係る表示部に表示される画面の例。 図８Ｂは、第１実施形態において、選択された保険の保険料の算出を要求する場合に、ユーザの通信端末に係る表示部に表示される画面の例。 図９は、第１実施形態に係る第１サーバの構成例。 図１０は、第１実施形態に係る第２サーバの構成例。 図１１は、第１実施形態に係る生保端末及び自動車保険端末の構成例。 図１２Ａは、第１実施形態において、生命保険会社の従業員がアプリケーションでユーザのランクや保険料を取得する要求をした場合に、生命保険会社の生保端末に表示される画面の例。 図１２Ｂは、第１実施形態において、生命保険会社がユーザに保険金を支払った場合に、生命保険会社の生保端末に表示される画面の例。 図１３は、第１実施形態に係る生体情報の収集するセットアップのフローチャート。 図１４は、第１実施形態に係る生命保険の保険料を算出するステップのフローチャート。 図１５は、図１４のステップＳ７のフローチャート。 図１６は、第１実施形態に係るランクと年齢に基づく増減分を算出するテーブルの概念図。 図１７Ａは、ある期間ΔＴ１中における選択された保険の加入者全員の点数分布。 図１７Ｂは、ある期間ΔＴ２中における選択された保険の加入者全員の点数分布。 図１８Ａは、第１実施形態にかかる自動車保険の保険料を算出するにあたり必要なセットアップのフローチャート。 図１８Ｂは、第１実施形態にかかる自動車保険の保険料を算出するにあたり必要なセットアップのフローチャート。 図１９は、第１実施形態に係る自動車保険の保険料を算出する際のフローチャート。 図２０は、第１実施形態に係るあるユーザのＩＤと対応付けされた第１情報及び第２情報のテーブル。 図２１Ａは、第１実施形態に係る通信端末のディスプレイに第２保険の保険料を表示する表示例。 図２１Ｂは、第１実施形態に係る通信端末のディスプレイに第２保険の保険料を表示する表示例。 図２１Ｃは、第１実施形態に係る通信端末のディスプレイに第２保険の保険料を表示する表示例。 図２２Ａは、ユーザＨ１の通信端末のディスプレイに第２保険の保険料を表示する表示例。 図２２Ｂは、ユーザＨ２の通信端末のディスプレイに第２保険の保険料を表示する表示例。 図２３Ａは、ユーザＩ１の通信端末のディスプレイに第２保険の保険料を表示する表示例。 図２３Ｂは、ユーザＩ２の通信端末のディスプレイに第２保険の保険料を表示する表示例。 図２３Ｃは、ユーザＩ２の通信端末のディスプレイに第２保険の保険料を表示する表示例。 図２４は、例１〜例４のディスプレイの表示方法と本実施形態の概念との関係性を示す概念図。 図２５は、第２実施形態において、ユーザに保険金を支払った旨の通知を第１サーバが第３システムや第４システムから受信した場合のフローチャート。 図２６は、第３実施形態に係る生命保険の保険料を算出するステップのフローチャート。 図２７は、第４実施形態に係る保険金を支払う事象の検知方法を示すフローチャート図。 図２８は、第５実施形態に係るユーザの死亡率ごとにカテゴリー分けされ、各カテゴリーに属するユーザの“第１情報及び第２情報”の条件をカテゴリーごとに対応づけされたテーブルの概念図。 図２９Ａは、第６実施形態に係る広告主がアプリケーション上で広告したいユーザを抽出し、広告をするためのステップを示す画面例。 図２９Ｂは、第６実施形態に係る広告主がアプリケーション上で広告したいユーザを抽出し、広告をするためのステップを示す画面例。 図２９Ｃは、第６実施形態に係る広告主がアプリケーション上で広告したいユーザを抽出し、広告をするためのステップを示す画面例。 図２９Ｄは、第６実施形態に係る広告主がアプリケーション上で広告したいユーザを抽出し、広告をするためのステップを示す画面例。 図３０は、第６実施形態に係る第１サーバの動作を示すフローチャート。 図３１Ａは、第６実施形態に係るユーザの通信端末のディスプレイに表示される広告の表示例。 図３１Ｂは、第６実施形態に係るユーザの通信端末のディスプレイに表示される広告の表示例。 図３２は、ユーザＯ１乃至Ｏ２の通信端末のディスプレイに表示される広告の表示例。 図３３は、第７実施形態に係るワーキングメモリの構成例。 図３４は、第７実施形態に係るメモリ群の構成例。 図３５は、第７実施形態に係るメモリポートの構成例。 図３６は、第７実施形態に係るコントローラ２０１−１の動作を示すフローチャート。 図３７は、第８実施形態に係る認証方法を示すフローチャート。

本実施形態は、種々の実施形態が述べられる添付図面を参照して後に十分に述べられる。図面においては、レイヤーの深さ及び領域は明確化のために誇張されることが可能である。同じ数字は同じエレメントで参照される。ここで使用される”及び／又は”は、１つ以上の関連するリストされたアイテムのいくつかの及び全ての組み合わせを含み、”／”として省略されることが可能である。

各実施形態で使用する文言を以下のように定義する。
（１）”保険”：保険とは、将来起こるかもしれない危険に対し、予測される事故発生の確率に見合った一定の保険料を加入者が公平に分担し、万一の事故に対して備える相互扶助の精神から生まれた助け合いの制度である。保険は、リスクの対象を基準として分類すると、ヒトに関する保険（例えば人の死亡やけが、病気に対する保険）、モノに関する保険（例えば物の損傷に対する保険）、カネに関する保険（例えば収入の減少に対する保険）、コトに関する保険（例えば賠償責任の負担に対する保険）に分類できる。図１に示すように、ヒト−カネに関する保険として、例えば生命保険や傷害保険がある。保険の例示として、火災保険、地震保険、自動車保険、自賠責保険、交通事故傷害保険、普通傷害保険、海外旅行傷害保険、医療保障保険、介護保険、年金保険等も挙げられる。本実施形態で使用する「同種の保険」は、図１に示すリスクの対象を基準とした分類において、同じカテゴリーに含まれる保険を指す。例えば「生命保険」と「傷害保険」はいずれもヒト−カネに関する保険であり、同カテゴリーに含まれる保険となるが、他方で、自動車保険は、モノ−カネに関する保険であり、「生命保険」や「傷害保険」とは同種の保険ではない。

なお、本実施形態で使用する「同種の保険」を以下のように解釈してもよい。上記に示す保険の例示ごとにカテゴリーに分けて、同じカテゴリーに含まれる保険を同種の保険としてもよい。すわなち、ある企業Ａ１により販売されている生命保険と、ある企業Ａ２により販売されている生命保険は商品が異なるものの同じ生命保険であるため、同種の保険として扱うが、例えば生命保険と傷害保険は同種の保険として扱わない。

生命保険を販売している企業ごとカテゴリー分けてして、同じ企業が販売している生命保険を同種の保険としてもよい。例えばある企業Ａ１により販売されている生命保険は、ある企業Ａ２により販売されている生命保険と同種の保険として取り扱わない。

保険Ｂ１と保険Ｂ２が同種の保険でない場合、保険Ｂ１は保険Ｂ２に対して「異種の保険」であると呼ぶ。
（２）”生体情報”：生体情報は、動物の身体に関する情報を指す。情報の形式を問わず、離散的にあってもよいし、連続した波形であってもよい。生体情報の例として、心拍数のデータ、心拍の波形のデータ、脈拍数のデータ、脈拍の波形のデータ、心電図の波形のデータ、体温波形のデータ、血圧値や波形のデータ、加速度のデータ、脳波のデータが挙げられる。例えば心拍に関する生体情報であれば、回数だけでなく、心拍変動率も含む。

各実施形態について図面を用いて説明する。この説明に際し、全図にわたり、共通する部分には共通する参照符号を付す。

説明の便宜上、各実施形態では、２つの異なる保険（異種の保険）として、生命保険及び自動車保険を例に説明する。各実施形態は、複数の異種の保険に対して適用できる。
［１］第１実施形態
［１−１］システムの全体構成例
図２を用いて、本実施形態のシステムの全体構成について説明する。
図２に示すように、システムは、大まかに、第１システム１、第２システム２、第３システム３及び第４システム４を備える。

第１システム１は、ウェアラブルデバイス１０−１、車両１０Ａに搭載されたセンサ（以下、車載センサとも呼ぶ）１０−２及び通信端末１０−３を備える。第２システム２は、第１サーバ２０及び第２サーバ２１を備える。第３システム３は、生命保険（生保）端末３０−１及び第３サーバ３０−２を備え、第４システム４は自動車保険端末４０−１及び第４サーバ４０−２を備える。

ウェアラブルデバイス１０−１は、電源をオンした状態でユーザ（動物であればよく、例えば人）に接触すると、ユーザの生体情報（第１情報）を取得する。ウェアラブルデバイス１０−１は、例えば、人の手首に巻くことのできるバンド形状（腕時計）や指輪の形状をしたデバイスである。

車載センサ１０−２は、車両１０Ａの移動状況／運転状況を示す情報や、車両１０Ａを運転している者または車両１０Ａに乗車している者の生体情報や車両１０Ａに関する情報（第２情報）を取得する。これらの情報の例としては、車両１０Ａを運転している者の“重量”や車両１０Ａを運転している者の呼気に含まれる“アルコール濃度”、車両１０Ａの“角速度”である。

通信端末１０−３は、ウェアラブルデバイス１０−１及び車載センサ１０−２と通信可能な状態のときに、ウェアラブルデバイス１０−１から第１情報を受信し、車載センサ１０−２から第２情報を受信する。通信可能な状態を設定する方法として、例えば、ユーザを特定する情報（例えば、ＩＤ）とパスワードを用いる。かかる認証により通信が許可されると、ウェアラブルデバイス１０−１及び車載センサ１０−２は、通信端末１０−３に第１情報、第２情報を送信する。

本実施形態では、ウェアラブルデバイス１０−１の電源がオンし、通信が許可されていれば、ウェアラブルデバイス１０−１がユーザの生体情報を計測しているとき、ウェアラブルデバイス１０−１は常に第１情報を通信端末１０−３に送信することを前提とする。

同様に、車載センサ１０−２の電源がオンし、通信が許可されていれば、車載センサ１０−２が生体情報等を計測しているとき、車載センサ１０−２は常に第２情報を通信端末１０−３に送信することを前提とする。
通信端末１０−３は、第１情報及び第２情報を受信すると、これらの情報とユーザのＩＤと対応付けされる。通信端末１０−３は、第１情報や第２情報を、ユーザのＩＤと対応付けて第２システム２に送信する。

通信端末１０−３は、例えば、スマートフォン、タブレット等の携帯端末であり、アクセスポイントとして機能すればいかなるデバイスであってもよい。

尚、本実施形態ではウェアラブルデバイス１０−１と通信端末１０−３とは、物理的に別々のデバイスでなくとも、１つの装置であってもよい。

第１サーバ２０は、第１システム１の例えば通信端末１０−３からユーザのＩＤと対応付けられた第１情報と第２情報を受信する。第１サーバ２０は、これらの第１情報と第２情報を、ユーザのＩＤと対応付けて一時的に保持する。

第１サーバ２０は、第１システム１、第３システム３または第４システム４から、あるユーザの保険料の算出を要求されたとき、すなわち、保険料の算出対象となるユーザのＩＤと保険料の算出を要求するコマンド等を第１サーバ２０が受けたときに、第１サーバ２０はユーザの保険料を算出する。

なお、第１サーバ２０は、１つに限定されず、例えば複数のサーバ２０−１〜２０−ｎ（ｎ：自然数）で構成されていてもよい。

第１サーバ２０は、鍵情報を保持する。この鍵情報は、第１サーバ２０が一時的に保持する第１情報と第２情報を暗号化するために用いられる符号や規則（ルール）である。第１サーバ２０は、鍵情報を用いて、暗号化された情報から第１情報と第２情報を復元する。なお、鍵情報は１つに限定されず、複数の鍵情報を用いて第１情報及び第２情報を暗号化し、複数の鍵情報を用いて暗号化された情報から第１情報と第２情報を復元してもよい。

第１サーバ２０は、ユーザのＩＤと対応付けされた第１情報と第２情報を鍵情報により暗号化し、暗号化された情報を第２サーバ２１へ送信する。

第１サーバ２０は、暗号化された情報を第２サーバ２１に送信したのち、鍵情報のみを保持し続け、ユーザのＩＤと対応付けられた第１情報と第２情報を第１サーバ２０内のメモリ２２−３から削除してもよい。

第１サーバ２０が保険料の算出を要求するコマンドを受けた場合に、ユーザのＩＤと対応付けられた第１情報と第２情報を保持していないときには、第１サーバ２０は、暗号化された情報を送信するようコマンドを第２サーバ２１に送信する。

第１サーバ２０は、暗号化された情報を受信して、鍵情報を用いて、ユーザのＩＤと対応付けされた第１情報と第２情報を復元し、保険料の算出を行う。

第２サーバ２１は、暗号化された情報を保持する。第２サーバ２１は、１つに限定されず、例えば複数のサーバ２１−１〜２１−ｎ（ｎ：自然数）で構成されていてもよい。

第２サーバ２１は、第１サーバ２０から暗号化された情報を送信するようコマンドを受けると、暗号化された情報を第１サーバ２０に送信する。

尚、第１サーバ２０及び第２サーバ２１のいずれに保持されるデータも、同一企業が所有する場合に限られず、例えば第１サーバ２０に保持されるデータは企業Ｃ１に属し、第２サーバ２１に保持されるデータは企業Ｃ２に属してもよい。同一企業が所有する場合には、第１サーバ２０と第２サーバ２１は物理的に同じサーバで構成されていてもよい。

生保端末３０−１は、第３サーバ３０−２とネットワークを介して接続される。例えば生命保険会社の従業員は、生保端末３０−１に入力して、ユーザの保険料の算出を第１サーバ２０に要求できる。具体的には、第３システム３から、ユーザのＩＤと保険料の算出を要求するコマンド等を第１サーバ２０に送信する。

なお、第３システム３から、ユーザのＩＤと保険料の算出を要求するコマンド等を第１サーバ２０に送信する代わりに、第３システム３が、ユーザのＩＤと、ユーザの属するランクに関する情報の算出を要求するコマンド等を第１サーバ２０に送信してもよい。第３システム３の第３サーバ３０−２は、ランクに応じた保険料の算出方法に関するプログラムを保持する。第３サーバ３０−２はユーザの属するランクに関する情報を第２システム２から受信して、上記プログラムを用いてユーザの保険料を算出し、生保端末３０−１に出力する。生保端末３０−１は第３サーバ３０−２から受信した保険料を表示部３１−５（ディスプレイ）に表示する。

自動車保険端末４０−１は、第４サーバ４０−２とネットワークを介して接続される。例えば自動車保険会社の従業員は、自動車保険端末４０−１に入力して、ユーザの保険料の算出を第１サーバ２０に要求できる。具体的には、第４システム４から、ユーザのＩＤと保険料の算出を要求するコマンド等を第１サーバ２０に送信する。

なお、第４システム４から、ユーザのＩＤと保険料の算出を要求するコマンド等を第１サーバ２０に送信する代わりに、第４システム４が、ユーザのＩＤと、ユーザの属するランクに関する情報の算出を要求するコマンド等を第１サーバ２０に送信してもよい。第４システム４の第４サーバ４０−２は、ランクに応じた保険料の算出方法に関するプログラムを保持する。第４サーバ４０−２はユーザの属するランクに関する情報を第２システム２から受信して、上記プログラムを用いてユーザの保険料を算出し、自動車保険端末４０−１に出力する。自動車保険端末４０−１は第４サーバ４０−２から受信した保険料を表示部３１−５（ディスプレイ）に表示する。

生命保険会社が例えば第３システム３を所有し、自動車保険会社は例えば第４システム４を所有する。生命保険会社や自動車保険会社は、例えば生保端末３０−１や自動車保険端末４０−１に表示されたユーザの保険料をユーザに請求する。かかる請求に基づいて、ユーザは保険料を生命保険会社や自動車保険会社に支払う。
また、生命保険会社や自動車保険会社が、ユーザに対して保険金を支払った場合に、第３システム３や第４システム４が、ネットワークを介して、ユーザに保険金を支払った旨の通知を第１サーバ２０にしてもよい。第１サーバ２０は、かかる通知を受信すると、この通知前後のある時間の範囲内における生体情報を取得する。具体的には、第１サーバ２０が第１情報及び第２情報を保持している場合、第１サーバ２０は、通知前後のある時間の範囲内における生体情報を抽出する。第１情報及び第２情報を保持していない場合には、第１サーバ２０は、第２サーバ２１から暗号化された情報を読み出し、第１情報及び第２情報を復元し、通知前後のある時間の範囲内における生体情報を抽出する。

そして、第１サーバ２０は、通知前後のある時間の範囲内における生体情報の相違を検出し、この相違に基づいた条件を算出する。具体的に説明すると、通知前の一定期間における平均の脈拍数はα回／秒であったが、通知後の一定期間における平均の脈拍数がβ回／秒であったとき、第１サーバ２０は、条件を「α回／秒からβ回／秒への変化」と設定する。なお、母数の平均で評価する場合には限定されず、例えば母数の平均と分散に基づいて評価してもよい。

第１サーバ２０は、設定した条件に変更がある度に、条件に関するデータをコマンド等とともに第１システム１の通信端末１０−３に送信する。通信端末１０−３は、受信した条件に関するデータに基づき条件を設定する。

なお、第１サーバ２０が、病気の種類に関するフラグ等と対応付けられて、この通知を受信した場合には、設定した条件とフラグを対応付けて保持する。この場合には、第１サーバ２０は、設定した条件に変更がある度に、条件とフラグを対応付けて、コマンド等とともに第１システム１の通信端末１０−３に送信する。通信端末１０−３は、受信した条件に基づき、フラグとともに条件を設定する。
［１−１−１］ウェアラブルデバイス１０−１
図３を用いて、ウェアラブルデバイス１０−１の構成について説明する。

図３に示すように、ウェアラブルデバイス１０−１は、ＣＰＵ（演算部）１１−１、センサ部１１−２、送受信部１１−３、メモリ（記憶部）１１−４及びＡ／Ｄ変換器１１−５を具備する。

ＣＰＵ１１−１は、センサ部１１−２から取得された生体情報に対して所望の処理を行う。

センサ部１１−２はユーザから生体情報を取得する。センサ部１１−２はユーザから生体情報を得ることができれば、ユーザのいずれに接触させてもよく、手首の他、例えば胸部及び頭部等でもよい。
送受信部１１−３は、ＣＰＵ１１−１が処理したデータを、通信端末１０−３に例えば無線送信する。なお、通信端末１０−３に送信するときに、ユーザのＩＤもセットで送信してもよい。

メモリ１１−４は、ＣＰＵ１１−１で処理されたデータ及びセンサ部１１−２から取得された生体情報等を一時的に保持する。

Ａ／Ｄ変換器１１−５は、センサ部１１−２で取得したアナログデータをデジタル変換する。

尚、ウェアラブルデバイス１０−１は、ＣＰＵ１１−１が処理したデータを、通信端末１０−３を介さずに、第２システム２に直接送信してもよい。

ウェアラブルデバイス１０−１は、他のウェアラブルデバイス１０−１と無線通信可能である。すなわち、複数のウェアラブルデバイス１０−１それぞれの送受信部１１−３同士は無線通信で通信が可能である。

１ユーザの身体に付された複数のウェアラブルデバイス１０−１間で、人体通信を可能とする。例えば、１ユーザの身体において２カ所以上にウェアラブルデバイス１０−１を付す場合には、ウェアラブルデバイス１０−１間の通信は人体通信を用い、それぞれのウェアラブルデバイス１０−１と通信端末１０−３との通信は無線通信を用いてもよい。ここで人体通信とは、誘電体である人体を通信媒体として利用する通信の形態であり、有線通信や無線通信には該当しない通信方式である。かかる人体通信については、例えば“HUMAN BODY COMMUNICATION APPARATUS AND AUTHENTICATION METHOD OF THE SAME”という２０１１年３月１８日に出願された米国特許出願１３／０５１，１９０号に記載されている。また、“COMMUNICATION APPARATUS AND COMMUNICATION SYSTEM”という２０１１年３月１８日に出願された米国特許出願１２／０５１，１９４号に記載されている。これらの特許出願は、その全体が本願明細書において参照により援用されている。
［１−１−２］車載センサ１０−２
図４及び図５を用いて、車載センサ１０−２の構成について説明する。図４に示すように、車載センサ１０−２は複数のセンサ１２０−１〜１２０−３を含む。車載センサ１０−２は、例えば重量センサ１２０−１と、吸気センサ１２０−２と、ジャイロセンサ１２０−３を含む。各センサ１２０−１〜１２０−３の大まかな構成は共通しており、センサの構成を図５に示す。

図５に示すように、車載センサ１０−２は、ＣＰＵ（演算部）１２−１、センサ部１２−２、送受信部１２−３、メモリ（記憶部）１２−４及びＡ／Ｄ変換器１２−５を具備する。

ＣＰＵ１２−１は、センサ部１２−２が取得したデータに対して所望の処理を行う。
センサ部１２−２は第２情報を取得する。
送受信部１２−３は、センサ部１２−２が取得した第２情報を通信端末１０−３の送受信部１３−３に送信する。なお、通信端末１０−３に送信するときに、ユーザのＩＤもセットで送信してもよい。

メモリ１２−４は、ＣＰＵ１２−１で処理されたデータ及びセンサ部１２−２が取得した第２情報を保持する。

Ａ／Ｄ変換器１２−５は、センサ部１２−２で取得したアナログデータをデジタル変換する。

以下、個々のセンサ１２０−１〜１２０−３について、図６を用いて説明する。

重量センサ１２０−１は、車両１０Ａを運転している者（ユーザ）が車両１０Ａに乗車したか否かを判断するセンサである。重量センサ１２０−１は、例えば運転座席に設けられる。重量センサ１２０−１がオン状態であり、センサ部１２−２が重量を検知したとき、ＣＰＵ１２−１は送受信部１２−３を制御して、ユーザが車両１０Ａに乗車したことを通信端末１０−３に通知する（Ｓ１）。通信端末１０−３はこの通知を受けて、ユーザが車両１０Ａに乗車したフラグ、ユーザのＩＤ、時刻を対応付けて保持する（Ｓ２）。

吸気センサ１２０−２は、ユーザが飲酒をしているか否かを判断するセンサである。呼気センサ１２０−２は、例えば、ハンドル部分に設けられる。吸気センサ１２０−２のセンサ部１２−２で取得した呼気に含まれるアルコール濃度が、呼気センサ１２０−２のメモリ１２−４に保持された閾値を超える場合には、ＣＰＵ１２−１は送受信部１２−３を制御して、飲酒運転であることを通信端末１０−３に通知する（Ｓ３）。通信端末１０−３はこの通知を受けて、飲酒運転のフラグ、ユーザのＩＤ、時刻を対応付けて保持する（Ｓ４）。

ジャイロセンサ１２０−３は、車両１０Ａが蛇行運転しているか否かを判断するセンサである。ジャイロセンサ１２０−３は、例えば、バックミラー部分に設けられるが、蛇行を検知できれば、車両１０Ａのいずれの部分に設けられてもよい。ジャイロセンサ１２０−３のセンサ部１２−２で検知された角速度が、ジャイロセンサ１２０−３のメモリ１２−４に保持された閾値を超える場合には、ＣＰＵ１２−１は送受信部１２−３を制御して、飲酒運転であることを通信端末１０−３に通知する（Ｓ５）。通信端末１０−３はこの通知を受けて、蛇行運転のフラグ、ユーザのＩＤ、時刻を対応付けて保持する（Ｓ６）。

なお、車両１０Ａには、ハンドル部分に生体情報を取得可能なセンサが搭載されていてもよい。

なお、本実施形態の図４及び図５では、センサ１２０−１〜１２０−３それぞれは、図５に示す、ＣＰＵ１２−１、センサ部１２−２、送受信部１２−３、メモリ１２−４、Ａ／Ｄ変換器１２−５を含んでいるが、これに限定されることなく、例えば、ＣＰＵ１２−１、送受信部１２−３、メモリ１２−４、Ａ／Ｄ変換器１２−５を、センサ１２０−１〜１２０−３で共有してもよい。
［１−１−３］通信端末１０−３
図７を用いて、通信端末１０−３の構成について説明する。

図７に示すように、通信端末１０−３は、ＣＰＵ（演算部）１３−１、メモリ（記憶部）１３−２、送受信部１３−３、表示部１３−４及びカウンタ（レジスタ）１３−５を具備する。

メモリ１３−２は、通信端末１０−３で保険料を表示するためのアプリケーションを保持する。このアプリケーションは、例えばインターネットを介して通信端末１０−３にダウンロードされる。そして通信端末１０−３にアプリケーションをインストールする。

また、メモリ１３−２は、ウェアラブルデバイス１０−１や車載センサ１０−２の製品情報及び種類と、検知できる第１情報及び第２情報とを対応付けたテーブルを保持する。さらに第１情報及び第２情報と、保険料の算出できる保険の種類とを対応付けたテーブルを保持する。

ＣＰＵ１３−１は、通信端末１０−３全体を制御する。ユーザが、通信端末１０−３に既にダウンロードしたアプリケーションを起動し、保険料の算出をするための元データの計測の開始を通信端末１０−３に入力をしたとき（図８Ａ参照）、ＣＰＵ１３−１は、ウェアラブルデバイス１０−１や車載センサ１０−２との通信を行う。例えばウェアラブルデバイス１０−１や車載センサ１０−２に電源を充電しつつ、通信端末１０−３はウェアラブルデバイス１０−１や車載センサ１０−２とＢｌｕｅｔｏｏｔｈ（登録商標）で通信を行い、通信端末１０−３はウェアラブルデバイス１０−１や車載センサ１０−２を検知する。

ユーザが後述する第２保険の加入者でなくとも、ユーザはこのアプリケーションをダウンロードして起動できる。例えば第２保険への加入を検討している人も、このアプリケーションをダウンロードしてＩＤを取得すれば本アプリケーションを使用することができる。第２保険への加入を検討している人は、通信端末１０−３を介して、所望の期間の第１情報と第２情報を第１サーバ２０へ送信すれば、第２保険の仮保険料を取得できる。この仮保険料により、第２保険への加入を検討している人は第２保険への加入するか否かを判断できる。

ＣＰＵ１３−１は、検知したウェアラブルデバイス１０−１や車載センサ１０−２の製品情報や種類から、保険料の算出できる保険の種類を表示部１３−４に表示する。図８Ａに示すように、通信端末１０−３には、検知したウェアラブルデバイス１０−１や車載センサ１０−２は表示部１３−４に表示される。

ユーザが、保険料の算出を希望する保険の種類を選択し、保険料の算出をするための基礎となる生体情報の収集開始を指示すると、通信端末１０−３のＣＰＵ１３−１は、送受信部１３−３を介して、第１サーバ２０に生体情報の収集開始を通知する。すなわち、図８Ａにおいて、ユーザが加入したい保険を選択し、計測開始ボタンを押すと、通信端末１０−３のＣＰＵ１３−１は、送受信部１３−３を介して、第１サーバ２０に生体情報の収集開始を通知する。

また、通信端末１０−３のＣＰＵ１３−１は、送受信部１３−３を介して、ウェアラブルデバイス１０−１や車載センサ１０−２から第１情報及び第２情報の受信を開始する。

ユーザが、アプリケーションを起動して、画面上で保険料の算出したい保険の種類を選択し、選択された保険の保険料の算出を要求すると（図８Ｂ参照）、通信端末１０−３のＣＰＵ１３−１は、送受信部１３−３を介して、第１サーバ２０に保険料の算出指示を通知する。すなわち、図８Ｂにおいて、ユーザが保険料を算出したい保険を選択して、計算開始ボタンを押すと、通信端末１０−３のＣＰＵ１３−１は、送受信部１３−３を介して、第１サーバ２０に保険料の算出指示を通知する。
通信端末１０−３がかかる通知をする場合に、カウンタ１３−５に保持された情報も第１サーバ２０に送信する。カウンタ１３−５に保持された情報の詳細については後述する。
また、通信端末１０−３は、第１サーバ２０から受信した条件を設定する。ＣＰＵ１３−１は、ウェアラブルデバイス１０−１、車載センサ１０−２から受信した第１情報と第２情報が、条件を満たすか否か判定する。かかる条件は例えば病気ごとに設定されている。例えば受信した第１情報と第２情報がある病気の条件を満たす場合には、ＣＰＵ１３−１は、この病気に対応する回数をインクリメントする。この回数は、例えば通信端末１０−３のカウンタ１３−５に保持される。本実施形態では、カウンタ１３−５は回数を保持するが、回数に限定されず、病気の内容と発症の程度が判別できればいかなる形式であってもよい。

送受信部１３−３は、ウェアラブルデバイス１０−１、車載センサ１０−２及び第１サーバ２０とのデータの授受を行う。送受信部１３−３は、ＣＰＵ１３−１によって制御される。送受信部１３−３は、例えば第１情報及び第２情報のデータの授受を行う。

なお、通信端末１０−３がＧＰＳ機能を有し、電子決済を実行できる場合を検討する。かかる場合に、通信端末１０−３が例えば病院や薬局で電子決済を行う場合、病気の内容を通信端末１０−３のメモリ１３−２に保持する。例えば、薬局で薬Ｄ１と薬Ｄ２が処方され、通信端末１０−３で電子決済する場合、通信端末１０−３のＣＰＵ１３−１は、薬Ｄ１と薬Ｄ２を同時に処方される病気を推定する。通信端末１０−３のメモリ１３−２が薬と病気の対応付けされたテーブルを保持する場合には、ＣＰＵ１３−１はテーブルを参照して病気を推定する。上記のテーブルが第１サーバ２０に保持されている場合には、ＣＰＵ１３−１は、送受信部１３−３を介して、薬Ｄ１と薬Ｄ２を同時に使用する病気を推定するように指示を第１サーバ２０に通知する。送受信部１３−３は、対応する病気に関する情報を第１サーバ２０から受けて、ＣＰＵ１３−１は病気を推定する。そののち、ＣＰＵ１３−１はユーザが推定された病気を１回発症したとカウントし、病気とカウントを対応づけてメモリ１３−２に保持する。送受信部１３−３は、ＣＰＵ１３−１の制御に基づき、かかる病気の内容を第１サーバ２０に送信する。

ここで、本実施形態では、送受信部１３−３は、第１サーバ２０に第１情報などを送信しているが、かかる場合に限定されることなく、例えば第１サーバ２０を介さずに、第２サーバ２１に直接送信してもよい。

本実施形態では、通信端末１０−３で病院や薬局で電子決済を行う場合を説明したが、かかる電子決済を行うと、ユーザの第２保険の保険料は上昇する可能性がある。このため、ユーザは病院や薬局で電子決済を行わないことが考えられる。そこで、ユーザが積極的に電子決済を行えるよう、ユーザにインセンティブを与えてもよい。例えばユーザが病院や薬局で電子決済を行う場合に第２保険の保険料から一定の金額を控除する。電子決済を行うホスト（例えばＰＯＳ端末等）から電子決済の内容を通信端末１０−３が受信して、通信端末１０−３は電子決済を行ったことを示すフラグをメモリ１３−２に保持する。通信端末１０−３が第２保険の保険料を表示するときに、ＣＰＵ１３−１は、第２保険の保険料から一定の金額を控除した金額を演算して、表示部１３−４に通知する。表示部１３−４は第２保険の保険料から一定の金額を控除した金額を第２保険の新たな保険料として表示する。

表示部１３−４は、例えば、通信端末１０−３のディスプレイである。表示部１３−４は、ユーザが選択された保険の保険料の算出を要求するとき、選択された保険の保険料（生命保険料、自動車保険料）を表示する。選択された保険の商品や種類に応じて、保険料の算出をするための基礎となる生体情報が異なる。ある保険では、ユーザの１月分の生体情報を基礎として保険料を算出するが、別の保険では、ユーザの１年分の生体情報を基礎として保険料を算出してもよい。いずれの生体情報を基礎として保険料を算出するかも、選択された保険の商品や種類に応じて異なる。表示部１３−４は、要求前の所望期間（例えば１月）のユーザの生体情報に基づいて算出された保険料を表示するとともに、所望期間よりも前のユーザの生体情報に基づいて算出された保険料（例えば先月の保険料）も表示してもよい。これに限定されることなく、例えば先月の保険料との変化率や差分を表示してもよい。さらに、表示部１３−４は、保険料の他、広告を表示してもよい。詳細は後述する。
［１−１−４］第１サーバ２０
第１サーバ２０は、（１）第１システム１のウェアラブルデバイス１０−１及び車載センサ１０−２から第１情報及び第２情報等を受信し、一時的に保持する機能を有する。また、第１サーバ２０は、（２）第１サーバ２０が受信したデータに基づき、ユーザの属するランクやユーザの保険料を算出する機能を有する。

図９を用いて、第１サーバ２０の構成について説明する。

図９に示すように、第１サーバ２０は、ＣＰＵ（演算部）２２−１、第１メモリ２２−２、第２メモリ２２−３、送受信部２２−４及びカウンタ２２−５を具備する。

ＣＰＵ２２−１は、ワーキングメモリ２２−６（ＲＡＭと表記）を含む。第１サーバ２０が通信端末１０−３から生体情報の収集開始の通知を受けると、第１サーバ２０は、ユーザのＩＤと収集開始した時刻を対応付けて第２メモリ２２−３に保持する。収集開始の通知を受けたのちに、通信端末１０−３から第１サーバ２０が第１情報と第２情報などを受信すると、第１サーバ２０はＩＤと対応付けて第１情報と第２情報などを第２メモリ２２−３に一時的に保持する。

ＣＰＵ２２−１は、複数の通信端末１０−３から複数のユーザに関する第１情報と第２情報を受信し、第２サーバ２１へかかる情報を転送するとき、複数のユーザの第１情報と第２情報等を、鍵情報を用いて暗号化処理を行う。暗号化処理の手法としては、例えば以下の４つが検討できる。暗号化処理前には、ユーザの第１情報と第２情報がユーザのＩＤと対応付けされていることを仮定する。
（１）一定の期間ごとに、各ユーザの第１情報及び第２情報を分割する。分割された同一期間における第１情報と第２情報を、ユーザを横断するようにシャッフルして暗号化する。例えば、ユーザＥ１の第１情報と第２情報を第１期間のものと第２の期間のものに分割する。同様に、ユーザＥ２，Ｅ３の第１情報と第２情報を第１期間のものと第２の期間のものに分割する。そのうえで、第１期間のもの同士シャッフルし、第２期間のもの同士シャッフルしてユーザのＩＤと対応しないようにすることで暗号化を行う。
（２）上記（１）のシャッフルしたのちに、時系列を横断するようにシャッフルして暗号化する。上記の例であれば、（１）のシャッフルしたのちに、同一行にある第１期間のものと第２期間のものを取り換えて暗号化を行う。
（３）第１情報及び第２情報を情報の種類ごと（例えば、脈拍、体温ごと）に各ユーザの第１情報及び第２情報を分割する。情報の種類のカラムの範囲内でデータをシャッフルして暗号化を行う。

第１サーバ２０が通信端末１０−３から保険料の算出指示を受けると、第１サーバ２０のＣＰＵ２２−１は、送受信部２２−４を介して、暗号化された情報を送信するようコマンドを第２サーバ２１に送信する。ＣＰＵ２２−１は、暗号化された情報を受けて、第１メモリ２２−２に保持された鍵情報をワーキングメモリ２２−６に読み出し、鍵情報を用いて、ユーザのＩＤと対応付けされた第１情報と第２情報を復元する。ＣＰＵ２２−１は、通信端末１０−３から受信した、ユーザが選択した保険の商品や種類に関する情報と、復元された第１情報及び第２情報と、通信端末１０−３から受信した病気の内容に関する情報等に基づいて、保険料を算出する。

詳細な保険料の算出方法については後述するが、ＣＰＵ２２−１は、ユーザが選択した保険の商品や種類に関する情報に基づいて、復元された第１情報及び第２情報のうち必要な情報を読み出し、選択した保険の商品や種類で考慮される病気に関する条件を満たすか判定する。保険の商品や種類ごとにいずれの病気が考慮されるか対応付けされたテーブルは、第１メモリ２２−２に保持されている。なお、選択した保険の商品や種類で考慮される病気のうち、通信端末１０−３で既に判定された病気（通信端末１０−３から受信した病気の内容に関する情報）は、第１サーバ２０で再度判定は行われない。

ＣＰＵ２２−１は、病気の内容に関する情報、病気に関する条件を満たすか否かの結果から、ユーザの特性を評価する。ＣＰＵ２２−１は、選択された保険に加入する他者のデータ（第１情報や第２情報など）をワーキングメモリ２２−６に読み出し、ユーザが選択された保険に加入する他者との相対関係を評価して、ユーザのランクを評価する。このランクを１つの変数として、ＣＰＵ２２−１は、ユーザの保険料を算出する。

第１メモリ２２−２は、例えば、演算プログラム、“鍵情報”、第１テーブル、第２テーブル、第３テーブル及び生保標準生命表等を含む。

演算プログラムは、選択された保険の商品や種類に考慮される病気に関する条件を第１情報及び第２情報が満たすか判定するプログラム、病気の内容に関する情報及び病気に関する条件を満たすか否かの結果から、ユーザのランクを評価するプログラム、ユーザのランクを１つの変数として、ユーザの第２保険の保険料を算出するプログラム、及び算出された第１保険の保険料と第２保険の保険料とを比較するプログラムを含む。

ここで、第１保険とは、保険業界に係る全企業の支出と収入とが均衡を保てるよう、保険商品・年齢・性別毎に予め保険料が設定されている保険である。すなわち、第１保険の保険料は、ユーザの第１情報や第２情報、ユーザのランク等に依存して変更されない。第２保険は、ユーザの第１情報や第２情報、ユーザのランクに基づいて保険料が設定される保険である。つまり第２保険の保険料は、ユーザの第１情報や第２情報、ユーザのランク等に依存する。

第１テーブルは、第１保険の保険料に関する情報である。第１保険の製品や種類・年齢・性別毎に設定された保険料が対応付けされたテーブルである。

第２テーブルは、ある病気と判定する条件をその病気と対応付けたテーブルである。第２テーブルには、複数の病気とそれぞれに対応する条件が保持されている。第１情報及び第２情報の全てについて条件が設定されているという場合に限らず、第１情報及び第２情報のうち、ある病気に関連する情報のみについて条件が設定されていてもよい。

条件の例としては、心電図を用いて、急性心疾患症候群（ＡＣＳ）か否かを判定する条件が挙げられる。具体的な方法は、例えば“Method and apparatus to detect acute cardiac syndromes in specified groups of patients using ECG”という２０００年８月９日に出願された米国特許出願０９／６３４３５５号に記載されている。この特許出願は、その全体が本願明細書において参照により援用されている。

本実施形態では、条件が既に第１サーバ２０に保持されていることを仮定して説明する。

第３テーブルは、ユーザのランクと平準純保険料に対する増減分を対応付けしたテーブルである。ＣＰＵ２２−１が、ユーザが選択された保険に加入する他者との相対関係からユーザのランクを評価するときに、かかる第３テーブルを用いる。

生保標準生命表は、生命保険の保険料を算定するための基礎数値を示す。かかる生保標準生命表を用いて、平準純保険料（net premium valuation）を算出する。

平準純保険料は、生保標準生命表を用いて、保険金の総額と保険料の総額が均衡するように設定された保険料を指す。具体的には、保険期間をｉ年、生命保険の平準純保険料をＰとし、期間中に死亡した場合に保険金ＩＰが支払われると仮定すると、生命保険の平準純保険料Ｐは、以下の式（１）を満たす。

ここで、ａ_ｉは、ｉ年間の各生存数を示し、ｂ_ｉは、ｉ年間の各年始現価率を示し、ｃ_ｉは、ｉ年間の各死亡数を示し、ｄ_ｉは、ｉ年間の各年央現価率を示し、平準純保険料Ｐは、保険の商品や種類ごとに相違する。生存数や死亡数は、生保標準生命表に基づいて算出する。上記の式（１）では、平準純保険料Ｐを一定であることを仮定したが、これに限定されることなく、例えば平準純保険料Ｐが、上記式の各変数（例えば死亡数）の変動に伴い変更されてもよい。平準純保険料が常に変更されるようにしてもよいが、これに限定されず、例えば一年単位、一ヶ月単位で変更してもよい。また、各変数（死亡率）が変化するイベント（震災、その二次被害など）の発生に伴い、変更してもよい。

第２メモリ２２−３は、ウェアラブルデバイス１０−１及び車載センサ１０−２から受信した第１情報及び第２情報等を一時的に保持する。

送受信部２２−４は、通信端末１０−３の送受信部１３−３からユーザのＩＤとともに第１情報及び第２情報を受信する。ＣＰＵ２２−１は、送受信部２２−４を制御して、これらの情報を第２メモリ２２−３に保持する。

送受信部２２−４は、ＣＰＵ２２−１が算出したユーザのランクや第１保険の保険料を、通信端末１０−３、後述する第３システム３及び第４システム４へ送信する。

カウンタ２２−５は、現在の時刻をカウントする。
［１−１−５］第２サーバ２１
図１０を用いて、第２サーバ２１の構成について説明する。

図１０に示すように、第２サーバ２１は、ＣＰＵ（演算部）２３−１、メモリ（記憶部）２３−２及び送受信部２３−３を具備する。

ＣＰＵ２３−１は、第１サーバ２０から暗号化された情報を送信するようコマンドを受けると、暗号化された情報を、送受信部２３−３を介して、第１サーバ２０に送信する。

メモリ２３−２は、暗号化された情報を保持可能とする。

送受信部２３−３は、第１サーバ２０の送受信部２２−４から受信した暗号化された情報を受信する。ＣＰＵ２３−１は、送受信部２３−３を制御して、暗号化された情報をメモリ２３−２に転送する。

尚、第２サーバ２１は１つに限定されることなく、例えば複数の第２サーバ２１−１〜２１−ｎを用いてもよい。これらの複数の第２サーバ２１−１〜２１−ｎが一体して上記の機能を有すればよい。
［１−１−６］生保端末３０−１及び自動車保険端末４０−１
図１１を用いて、生保端末３０−１及び自動車保険端末４０−１の構成について説明する。生保端末３０−１と自動車保険端末４０−１はいずれも同一構成であるため、説明の便宜上、生保端末３０−１のみを説明する。

図１１に示すように、生保端末３０−１は、ＣＰＵ（演算部）３１−１、メモリ（記憶部）３１−２、送受信部３１−３、入力部３１−４、表示部３１−５及び出力部３１−６を具備する。

ＣＰＵ３１−１は、生保端末３０−１全体を制御する。生命保険会社がユーザから第１保険の申し込みを受けた場合で、図１２Ａに示すように、例えば生命保険会社の従業員がメモリ３１−２に保持されたアプリケーションを起動し、アプリケーションでユーザのランクや保険料を取得する要求をしたとき（図１２Ａ参照）、ＣＰＵ３１−１は、上記の要求があった旨の通知を第１サーバ２０へ送信する。すなわち、図１２Ａに示すように、保険料の算出を行いたいユーザを選択して、取得ボタンを押すと、ＣＰＵ３１−１は、上記の要求があった旨の通知を第１サーバ２０へ送信する。
生命保険会社がユーザに保険金を支払った場合に、ＣＰＵ３１−１は、保険金の支払いがあった旨の通知を第１サーバ２０へ送信する（図１２Ｂ参照）。すなわち、図１２Ｂに示すように、保険金の支払いをしたユーザを選択して、登録ボタンを押すと、ＣＰＵ３１−１は、保険金の支払いがあった旨の通知を第１サーバ２０へ送信する。

保険金の支払いがあった旨のみを第１サーバ２０に送信する場合に限定されず、例えば保険金の支払い事由をフラグにして、かかるフラグとともに通知を送信してもよい（図１２Ｂ参照）。

第１サーバ２０が上記の要求があった旨の通知を受けると、保険に加入しているユーザの生体情報に基づいて検出された相違から条件を再計算する。詳細は第２実施形態で説明する。

メモリ３１−２は、第１サーバ２０が算出したユーザのランクやユーザの保険料を一時的に保持する。また、メモリ３１−２は、第１サーバ２０から受信したユーザのランクやユーザの保険料を読み込むためのプログラムも含む。

送受信部３１−３は、第１サーバ２０から、ユーザのランクやユーザの保険料の受信を行う。また、保険会社がユーザに保険金を支払うと、送受信部３１−３は、保険金の支払いをした旨を第１サーバ２０に送信する。

入力部３１−４は、キーボードを具備する。

表示部３１−５は、第１サーバ２０が算出したユーザの保険料を表示できる。

出力部３１−６は、メモリ３１−２に格納された保険料を出力する。この出力（印刷）は、例えば、生保端末３０−１に接続されたプリンター（図示せず）が行う。

尚、生保端末３０−１及び自動車保険端末４０−１は、筐体とディスプレイとを備えた端末に限定されず、例えばサーバであってもよい。

本実施形態では、第１サーバ２０がユーザの保険料を算出する例で説明したが、かかる場合に限定されず、例えばＣＰＵ３１−１がユーザの保険料を算出してもよい。具体的に説明すると、生命保険会社がユーザから第１保険の申し込みを受けた場合で、生命保険会社の従業員がメモリ３１−２に保持されたアプリケーションを起動し、アプリケーションでユーザのランクを要求したとき、ＣＰＵ３１−１は、上記の要求があった旨の通知をユーザのＩＤとともに第１サーバ２０へ送信する。この通知に対して、第１サーバ２０は、第３サーバ３０−２にユーザのＩＤに対応するランクを返信する。ＣＰＵ３１−１は、送受信部３１−３を介して受信したユーザのＩＤに対応するランクに基づいて、保険料を算出する。この場合には、メモリ３１−２に、第１テーブル、第２テーブル、第３テーブル等を保持する。第１サーバ２０が保険料を算出する方法と同様の方法で、ＣＰＵ３１−１がユーザの保険料を算出する。表示部３１−５に算出されたユーザの保険料を表示する。
［１−１−７］第３サーバ３０−２及び第４サーバ４０−２
第３サーバ３０−２は、生保端末３０−１とネットワークで接続される。第４サーバ４０−２は、生保端末４０−１とネットワークで接続される。上記で説明したように、ＣＰＵ３１−１がユーザの保険料を算出する場合には、第３サーバ３０−２及び第４サーバ４０−２は、受信したユーザのランクから保険料を算出するプログラムを有する。さらに、第３サーバ３０−２及び第４サーバ４０−２は、第１テーブルから第３テーブル等も含む。
［１−２］生命保険料
［１−２−１］セットアップについて
本実施形態の生命保険の保険料を算出するために、まずユーザの生体情報を収集する必要がある。生体情報の収集するセットアップについて、図１３を用いて説明する。

本実施形態では、ユーザが２つの第１ウェアラブルデバイス１０−１ａ、第２ウェアラブルデバイス１０−１ｂを装着する例を用いて説明する。第１ウェアラブルデバイス１０−１ａが取得する第１情報と、第２ウェアラブルデバイス１０−１ｂが取得する第１情報は異なる種類の生体情報であるとする。第１ウェアラブルデバイス１０−１ａ及び第２ウェアラブルデバイス１０−１ｂを区別しない場合は、単にウェアラブルデバイス１０−１と呼ぶ。

ユーザが、通信端末１０−３に既にダウンロードしたアプリケーションを起動し、保険料の算出をするための元データの計測の開始を通信端末１０−３に入力をしたとき（図８Ｂ参照）、通信端末１０−３は、ウェアラブルデバイス１０−１ａ、１０−１ｂとの通信の認証を行う（Ｓ１１）。

通信の認証ができたら、通信端末１０−３は第１サーバ２０に計測開始のコマンド等を送信する（Ｓ１２）。第１サーバ２０は、かかるコマンド等を受けて、ユーザのＩＤと計測開始した時刻を対応付けて第２メモリ２２−３に保持する。

ウェアラブルデバイス１０−１ａの電源がオンし、通信が許可されていれば、ウェアラブルデバイス１０−１ａがユーザの生体情報を計測しているとき、ウェアラブルデバイス１０−１ａは、第１情報を、通信端末１０−３に送信する（Ｓ１３）。例えば、ウェアラブルデバイス１０−１ａでは、例えばユーザから体温波形のデータ、脈拍回数／秒、脈拍波形のデータを取得する（Ｓ１３）。同様に、ウェアラブルデバイス１０−１ｂの電源がオンし、通信が許可されていれば、ウェアラブルデバイス１０−１ｂがユーザの生体情報を計測しているとき、第１ウェアラブルデバイス１０−１ｂは、第１情報を、通信端末１０−３に送信する（Ｓ１３）。例えば、ウェアラブルデバイス１０−１ｂでは、例えばユーザから心電図のデータ、心拍回数／秒、心拍波形のデータ、加速度を取得する。

通信端末１０−３は、ウェアラブルデバイス１０−１ａ、１０−１ｂから受信した第１情報が条件を満たすか判定する（Ｓ１４）。ある条件を満たす場合には（Ｓ１４、Ｙｅｓ）、第１サーバ２０は、この条件に対応する病気のカウンタ１３−５をインクリメントする（Ｓ１５）。条件を満たさない場合には（Ｓ１４，Ｎｏ）、通信端末１０−３は次のステップに移る。

通信端末１０−３は、受信した第１情報に、ユーザのＩＤを対応付けて第１サーバ２０に送信する（Ｓ１６）。このとき、通信端末１０−３のカウンタ１３−５に保持されたデータを第１サーバ２０に送信してもよい。この場合に限定されることなく、ユーザに選択された保険の保険料の算出を要求されたときに、かかるデータを第１サーバ２０に送信してもよい。

また、通信端末１０−３がＧＰＳ機能を有し、電子決済を実行できる場合、通信端末１０−３のＣＰＵ１３−１は、電子決済の内容に基づいて、病気を推定する。ＣＰＵ１３−１はユーザが推定された病気を１回発症したとカウントし、病気とカウントを対応づけてカウンタ１３−５に保持する。

本実施形態では、通信端末１０−３にＧＰＳ機能を有する場合を例に説明したが、これに限定されることなく、例えばウェアラブルデバイス１０−１ａ、１０−１ｂにＧＰＳ機能を持たせ、ＧＰＳと地図情報からユーザがいずれの病院に通院しているかをＣＰＵ１３−１が判定し、病院に関連する病気を１回発症したとカウントし、かかる病気とカウントを対応づけてカウンタ１３−５に保持してもよい。
［１−２−２］生命保険の保険料を算出するステップについて
図１４を用いて、本実施形態の生命保険の保険料を算出するステップについて説明する。

ユーザが、アプリケーションを起動して、画面上で保険料の算出したい保険の種類を選択し、選択された保険の保険料の算出を要求すると（図８Ｂ参照）、通信端末１０−３のＣＰＵ１３−１は、送受信部１３−３を介して、第１サーバ２０に保険料の算出指示を通知する（Ｓ２１）。

かかる場合に、通信端末１０−３の送受信部１３−３は、ＣＰＵ１３−１の制御に基づき、選択された保険の製品や種類に関する情報、ユーザのＩＤ、かかる病気の内容に関する情報、保険料の算出を要求するコマンド等を第１サーバ２０に送信する。保険料の算出指示の通知を受けて、第１サーバ２０のＣＰＵ２２−１は、保険料の算定に必要な期間の第１情報を保持しているか判定する（Ｓ２２）。選択された保険の種類に応じて必要な第１情報が異なるだけでなく、第１情報の必要な期間も異なるため、第１メモリ２２−２に保持された第１テーブルから、必要な期間を読み出して、ＣＰＵ２２−１は保険料の算定に必要な期間の第１情報を保持しているか判定する（Ｓ２２）。必要な期間の第１情報を保持していない場合には、第１サーバ２０は、通信端末１０−３に選択された第２保険の保険料を算定できない旨、通知する（Ｓ２２，Ｎｏ）。

選択された第２保険の保険料を算定できる場合には（Ｓ２２，Ｙｅｓ）、第１サーバ２０は、選択した保険の商品や種類で考慮される病気について、通信端末１０−３から受信した病気の内容に関する情報でランク付けが可能かを判定する（Ｓ２３）。判定が可能である場合には（Ｓ２３，Ｙｅｓ）、ステップＳ２７へ進む。判定ができない場合には（Ｓ２３，Ｎｏ）、第１サーバ２０は、必要な第１情報が第２メモリ２２−３に保持されているか判定する（Ｓ２４）。

必要な期間の第１情報を保持している場合には（Ｓ２４，Ｙｅｓ）、ＣＰＵ２２−１はワーキングメモリ２２−６に必要な期間の第１情報を読み出す（Ｓ２６）。第１サーバ２０が必要な期間の第１情報を保持していない場合には（Ｓ２４，Ｎｏ）、第２サーバ２１から暗号化された情報を取得して、復元することでワーキングメモリ２２−６に必要な期間の第１情報を読み出す（Ｓ２５、Ｓ２６）。

第１サーバ２０は、通信端末１０−３から受信した病気の内容に関する情報、第１情報、ユーザのＩＤを用いて、ユーザの第２保険の保険料を算出する（Ｓ２７）。具体的な保険料の算出方法については、後述する。

次に、第１サーバ２０は、算出された第２保険の保険料と、第１サーバ２０の第１メモリ２２−２に保持された第１保険の保険料を比較して、いずれの保険の保険料が安いか判定する（Ｓ２８）。この判定結果及び第２保険の保険料を、第１サーバ２０は、通信端末１０−３に送信する。

通信端末１０−３は、この判定結果と第２保険の保険料を外部に出力する（Ｓ２９）。例えば、通信端末１０−３のディスプレイに表示する。これに限定されることなく、例えば判定結果を音声で出力できるようにしてもよい。

通信端末１０−３は、ユーザが第２保険に加入している場合に第１保険の保険料の方が第２保険の保険料よりも安いとき、第１保険の加入をお勧めする旨をディスプレイに表示し、具体的に減額できる差額をも表示する。ユーザが第２保険に加入している場合に第１保険の保険料の方が第２保険の保険料よりも高いとき、第２保険の加入の維持をお勧めする旨の表示をし、具体的に第１保険の保険料との差額を減額できた金額として表示する。ユーザが第２保険に加入しておらず、このユーザが所望の期間の間に測定した第１情報及び第２情報等に基づいて第２保険の仮保険料を算出する場合に、第１保険の保険料の方が第２保険の仮保険料よりも安いとき、第２保険の加入をしないことをお勧めする旨をディスプレイに表示する。他方で、第１保険の保険料の方が第２保険の仮保険料よりも高いとき、第２保険の加入の維持をお勧めする旨の表示をし、具体的に第１保険の保険料との差額を減額できた金額として表示する。
［１−２−３］ステップＳ２７について
本実施形態のステップＳ２７について、図１５を用いて説明する。本実施形態では、第１サーバ２０がユーザのランクを算出し、このランクに基づいて保険料を算出する例を説明する。

ステップ２６ののちに、ＣＰＵ２２−１は、第２テーブルから各病気と判定する条件をワーキングメモリ２２−６に読み出し、読み出した第１情報が病気と判定する条件を満たしているか判定する（Ｓ３１）。ユーザの第１情報が、例えば病気Ａと判定する条件を２回、病気Ｂと判定する条件を３回満たしている場合には、ＣＰＵ２２−１は、このユーザのＩＤと、病気Ａ２回、病気３回を対応付ける（Ｓ３２）。
さらに、ＣＰＵ２２−１は通信端末１０−３から受信した病気の内容に関する情報をユーザのＩＤと対応付ける（Ｓ３２）。
ＣＰＵ２２−１は、選択された保険で考慮される病気に対応する条件全ての判定を終了したか判定し（Ｓ３３）、全ての判定が終了した場合には（Ｓ３３、Ｙｅｓ）、ステップＳ３４に進む。他方で、全ての判定が終了していない場合には（Ｓ３３、Ｎｏ）、ステップＳ３１に戻り、ＣＰＵ２２−１は、他の病気に対応する条件を第１情報が満たすか判定する。
ＣＰＵ２２−１は、ユーザのランク付けを行う（Ｓ３４）。ステップＳ２３、Ｙｅｓの場合には、ステップＳ３１乃至Ｓ３３を経ずに、ステップＳ３４を行う。

ステップＳ３４では、ＣＰＵ２２−１は、ユーザのＩＤと対応付けられた各病気の回数とカウンタの情報を点数に変換する。

同様のアルゴリズムで、ＣＰＵ２２−１は、ユーザが選択した保険に加入している全加入者の病気情報を点数に変換する。そして、ＣＰＵ２２−１は、ユーザの全加入者に対する位置づけをランク付けする（Ｓ３４）。保険商品ごとに重視する病気が異なる。例えば生命保険であれば、病気により死亡率が異なる。したがって死亡率が高い病気は、他の病気（相対的に死亡率が低い病気）よりも重視される。病気情報を点数に変換する際に、病気の軽重を重みづけして点数に変換する。かかる重みづけは例えば第２メモリ２２−３に保持される。ＣＰＵ２２−１は、重みづけに関する情報をワーキングメモリ２２−６に読み出して点数への変換を行う。

そして、ＣＰＵ２２−１は、生保標準生命表を用いて、選択された保険の平準純保険料を算出する（Ｓ３５）。ＣＰＵ２２−１は、第３テーブルから、ユーザのランクに対応する増減分を算出する（Ｓ３６）。具体的に、ユーザが選択した保険は、ユーザが所望の期間ｉに１回以上病気Ｆを発症したことがあるか否かで判断するものとする。所望の期間の加入者の人数は増減せず、加入者全体をＭとし、そのうち所望の期間（ｉ年の１年間）に１回以上病気Ｆを発症した人数をＮｉとする。このとき、所望の期間に１回以上病気Ｆを発症した人の保険料は以下の式を満たすＰ＋αである。他方で、所望の期間に１回以上病気Ｆを発症していない人の保険料は以下の式（２）を満たすＰ−αである。

ここで、Ｐは、平準純保険料を示し、α_ｉは、ｉ年間の各生存数を示し、ｂ_ｉは、ｉ年間の各年始現価率を示す。

なお、本実施形態では、ＣＰＵ２２−１は、第３テーブルから、ユーザのランクに対応する増減分を算出しているが、この場合に限られず、例えばランクと他の観点（ユーザの年齢・自動車運転の有無・喫煙／飲酒の有無・喫煙／飲酒の程度）を加味して増減分を算出してもよい。図１６にランクと年齢に基づく増減分を算出するテーブルを示す。増減分α_１は、ユーザが病気Ｆをしておらずかつ年齢が３０歳未満の集合に適用する増減分である。増減分α_２は、ユーザが病気Ｆを所望の期間に発症しているがかつ年齢が３０歳未満の集合に適用する増減分である。増減分α_３は、ユーザが病気Ｆをしておらずかつ年齢が３０歳以上の集合に適用する増減分である。増減分α_４は、ユーザが病気Ｆを所望の期間に発症しているがかつ年齢が３０歳以上の集合に適用する増減分である。増減分α_１〜α_４は正の値に限定されず負の値をとる場合がある。増減分α_１〜α_４は以下の式（３）を満たす。

ここで、_Ｐは、平準純保険料を示し、α_ｉは、ｉ年間の各生存数を示し、ｂ_ｉは、ｉ年間の各年始現価率を示す。所望の期間の加入者の人数は増減せず、加入者全体をＭとし、そのうち所望の期間に１回以上病気Ｆを発症していない３０歳未満の人数をＮ_１と、所望の期間に１回以上病気Ｆを発症している３０歳未満の人数をＮ_２と、所望の期間に１回以上病気Ｆを発症していない３０歳以上の人数をＮ_３とする。人数Ｎ_１〜Ｎ_３は、ｉ年の１年間ごとに相違するが、記号は人数Ｎ_１〜Ｎ_３とする。
このように、平準純保険料を基礎として、ランクと他の観点に基づいてユーザの保険料の配分を変更している。
［１−２−４］ユーザのランクを付与するフローについて
ユーザのランクを付与するプロセスは、ユーザに選択された保険の加入者全体に対するユーザの位置を決めるプロセスである。かかるランクは、選択された保険の加入者全体の増減や、かかる保険において重視される病気の種類、加入者それぞれの健康状態、保険料の算定に使用する期間に依存して異なる。先にも説明したとおり、平準純保険料を基礎として、保険業界に係る全企業の収入を保ちつつ、ユーザの健康状態と他の観点に基づいてユーザの保険料に差異をつけている。以下、ユーザのランクの増減について、簡単な例を用いて説明する。ランクが下がると保険料は低下する方向になり、ランクが上がると保険料は上昇する方向になる。
（例１）
ある保険において、期間ΔＴ１の加入者数に対して、期間ΔＴ２の加入者数がＸ人増加したものと仮定する。ユーザの健康状態（例えば期間中における病気の回数等）が期間ΔＴ１と期間ΔＴ２で同一であるとしても、新規に加入したＸ人の健康状態がユーザの健康状態と比較して良好な場合（例えば、ユーザの期間中におけるある病気の回数よりも新規に加入したＸ人全員の期間中におけるある病気の回数が小さい場合）には、期間ΔＴ２のユーザのランクは、期間ΔＴ１のユーザのランクよりも上がる。新規に加入したＸ人の健康状態がユーザの健康状態と比較して不良な場合には、期間ΔＴ２のユーザのランクは、期間ΔＴ１のユーザのランクよりも下がる。つまり、新規に加入したＸ人のうちユーザよりも健康状態が良好な人が多いか／不良な人が多いかに依存して、ユーザのランクは変更される。
（例２）
ユーザが選択した保険の種類に応じて、重視する病気が異なる。第２テーブルには、保険の種類と、各病気の重視する順番、点数に変換する際の重みづけが対応付けて保持される。期間ΔＴに、他の加入者は重みづけの低い病気を複数回発症しているとしても、ユーザは重みづけが高い病気を１回発症している場合には、ユーザのランクは上がる場合がある。
（例３）
ランクは、選択された保険の加入者全体の増減や、かかる保険において重視される病気の種類、加入者それぞれの健康状態、保険料の算定に使用する期間に依存して異なる。例１や例２で説明したものは１つの変数を変更しているにすぎないが、現実では複数の変数が同時に変更している。

図１７Ａは、ある期間ΔＴ１中における選択された保険の加入者全員の点数分布を示し、図１７Ｂは、ある期間ΔＴ２中における選択された保険の加入者全員の点数分布を示す。図示の便宜上、点数が低ければ低いほどユーザの健康状態が良好であることを示すものとする。

期間ΔＴ１における加入者全員の点数の平均を３０であったとする。期間ΔＴ２における加入者全員の点数の平均を５０とする。平均の点数の変動は、加入者全体の増減だけでなく、加入者それぞれの健康状態の変化に起因する。

期間ΔＴ１におけるユーザの点数が４０であり、期間ΔＴ２におけるユーザの点数が４０であるとすると、ユーザの健康状態は変更されていないが、期間ΔＴ２のランクが低下する。
［１−３−１］自動車保険料の算出方法
自動車保険の保険を算出する際の各システムの動作を説明する。大まかには生命保険の保険料を算出する方法と同一であるが、以下の２点において異なる。
（１）通信端末１０−３は、ウェアラブルデバイス１０−１から第１情報を取得するだけでなく、車載センサ１０−２から第２情報を取得する点が相違する。通信端末１０−３は、第２情報もユーザのＩＤとともに第１サーバ２０に送信する。
（２）第１サーバ２０は、ユーザの第１情報と選択された保険の加入者全体の第１情報を比較して、ユーザの位置を算出するだけでなく、車両に乗車中のユーザの第１情報と車両に乗車している期間以外のユーザの第１情報とを比較して、ユーザの位置を算出し、２つのユーザの位置に基づいて、ユーザのランク付けを行う。
［１−３−１−１］セットアップについて
以下、自動車保険の保険料を算出するにあたり、車載センサ１０−２が通信端末１０−３に第２情報を送信するセットアップについて図１８Ａ及び図１８Ｂを用いて説明する。図１３と共通する部分の詳細な説明は省略する。

図１８Ａ及び図１８Ｂに示すように、ユーザが、通信端末１０−３に既にダウンロードしたアプリケーションを起動し、保険料の算出をするための元データの計測の開始を通信端末１０−３に入力をしたとき（図８Ａ参照）、通信端末１０−３は、車載センサ１０−２との通信の認証を行う（Ｓ４１）。通信の認証ができたら、通信端末１０−３は第１サーバ２０に計測開始のコマンドを送信する（Ｓ４２）。第１サーバ２０は、かかるコマンド等を受けて、ユーザのＩＤと計測開始した時刻を対応付けて第２メモリ２２−３に保持する。
車載センサ１０−２の電源がオンし、通信が許可されていれば、車載センサ１０−２がユーザの生体情報や車両の運行状況を計測しているとき、車載センサ１０−２は、第２情報を通信端末１０−３に送信する（Ｓ４３）。
通信端末１０−３は、メモリ１３−２に保持されている車載センサ１０−２それぞれの異常や変化を検出するための条件をＣＰＵ１３−１のワーキングメモリに読み出し、ＣＰＵ１３−１は第２情報がこの条件を満たしているか判定する（Ｓ４４）。ここで、異常や変化を検出するための条件とは、自動車事故を誘発する可能性の高い事情を検出するための条件である。自動車事故を誘発する主要因として、例えば蛇行運転や運転中の居眠り、飲酒運転が挙げられる。メモリ１３−２には、過度な蛇行運転をしていると判定するための条件を保持して、ＣＰＵ１３−１は、車載センサ１０−２から取得した第２情報がかかる条件を超えているか判定する（Ｓ４４）。条件を満たしている場合には（Ｓ４４，Ｙｅｓ）、ＣＰＵ１３−１は蛇行運転に対応するカウンタをインクリメントする（Ｓ４５）。条件を満たしていない場合には（Ｓ４４，Ｎｏ）、通信端末１０−３は、受信した第２情報に、ユーザのＩＤを対応付けて第１サーバ２０に送信する（Ｓ４６）。
［１−３−１−２］自動車保険の保険料を算出する際のフローチャートについて
自動車保険の保険料を算出する際のフローチャートは、生命保険の保険料を算出する際のフローチャートと同様であるため、異なる部分のみを図１９に用いて説明する。本実施形態では、図１４のステップＳ２２〜Ｓ２６において、第１情報だけでなく、第２情報及び第２情報に関するカウンタの情報等も送受信する。
ステップＳ２７では、第１サーバ２０は、通信端末１０−３から受信した病気の内容に関する情報、第１情報、第２情報、第２情報に関するカウンタの情報、ユーザのＩＤを用いて、ユーザの第２保険の自動車保険の保険料を算出する（Ｓ２７）。
かかるステップＳ２７について、図１９を用いて詳述する。

ＣＰＵ２２−１は、ユーザにより選択された自動車保険の加入者全体の第１情報及び第２情報と、ユーザの第１情報及び第２情報を比較して、加入者全体に対してユーザの睡眠の良否を判定する（Ｓ５１）。具体的には、加入者全体の睡眠の程度を数値に変換し、かかる数値の分布からユーザの睡眠の良否を判定する（Ｓ５１）。ここで睡眠の程度を数値に変換する方法は、例えば“APPARATUS AND METHOD FOR MEASURING AUTONOMIC NERVE INDEX AND BIOLOGICAL INFORMATION DETECTING APPARATUS”という２００８年２月２５日に出願された米国特許出願１２／０３６７４０号に記載されている。この特許出願は、その全体が本願明細書において参照により援用されている。

そして、ＣＰＵ２２−１は、ユーザの第１情報及び第２情報全体と、ユーザが車両１０Ａに乗車している間の第１情報及び第２情報とを比較して、車両１０Ａに乗車している間の睡眠の程度を判定する（Ｓ５２）。第１サーバ２０は、上記の２つの判定を用いて、ユーザのランク付けを決定する（Ｓ５３）。

図２０の具体例を用いて詳しく説明する。図２０は、あるユーザのＩＤと対応付けされた第１情報及び第２情報である。このテーブルは、第１サーバ２０または第２サーバ２１に保持される。図２０の縦軸は、時間ｔを示し、図２０の横軸は、第１情報及び第２情報とこれらによって演算された情報を示す。ウェアラブルデバイス１０−１は、心拍、脈拍、心電、体温、加速度ｘ、ｙ、ｚ、脳波に関するデータを取得し、車載センサ１０−２は、重量センサ、呼気センサ、ジャイロセンサに関するデータを取得する。第１サーバ２０のＣＰＵ２２−１は、図２０に示す居眠りの状態（睡眠の状態）や蛇行運転の状態に関するデータを第１情報及び第２情報に基づき演算する。この演算の結果を図２０では、図示の便宜上、演算結果として表示している。
第１サーバ２０または第２サーバ２１には、このユーザ以外にも保険加入者全員の第１情報及び第２情報が保持されているものと仮定する。睡眠の程度の数値は、心拍に関するデータ、脈拍に関するデータ、心電図、体温等に関するデータに基づいて算出できるものとする。

この場合、ＣＰＵ２２−１は、図２０のデータ列のうち領域Ｇ１のデータを用いて、ユーザの運転していない間における睡眠の程度の数値Ｘ_ｊ（ｊは自然数であり、ｊ＝ｋのとき、Ｘ_ｋは、運転してない間のうち期間ΔＴ_ｋの睡眠の程度の数値）を算出する。同様に、ＣＰＵ２２−１は、図２０のデータ列のうち領域Ｇ２のデータを用いてユーザの運転している間における睡眠の程度の数値Ｙ_ｊ（ｊは自然数であり、ｊ＝ｋのとき、Ｙ_ｋは、運転している間のうち期間ΔＴ_ｋの睡眠の程度の数値）を算出する。同様に、加入者全員それぞれについて、運転していない間における睡眠の程度の数値Ｗ_ｉｊ（ｉは加入者全員の人数−１）を算出する。

そして、ＣＰＵ２２−１は、ユーザの睡眠に関する位置づけを、例えば、Ｗ_ｉｊで形成される分布に対する

上記方法で、ＣＰＵ２２−１はユーザの睡眠に関する位置づけを把握したうえで、運転中の眠りが深い場合には自動車事故の発生確率が高いものとしてランクを高くする要因として使用する。他方で、運転中の眠りが浅い場合には自動車事故の発生確率が低いものとしてランクを低くする要因として使用する。

すなわち、生命保険の保険料を算定するときには、ユーザの第１情報と保険加入者全体の第１情報の比較を行って、ユーザのランク付けを行っているが、自動車保険の保険料を算定するとき、ユーザの第１情報及び第２情報と保険加入者全体の第１情報及び第２情報の比較を行うだけでなく、ユーザが車両１０Ａに乗車している間の第１情報と乗車していない間の第１情報を比較することで、ユーザのランク付けを行う。

保険商品ごとに重視する第２情報が異なる。ＣＰＵ２２−１は、重みづけに関する情報をワーキングメモリ２２−６に読み出して点数への変換を行う。

ＣＰＵ２２−１は、第３テーブルから、ユーザのランクに対応する増減分を算出する。ランクに対応する増減分の算出方法は、生命保険の保険料を算出する方法と同様であるため省略する。
［１−４］ディスプレイへの表示方法
図２１Ａ、図２１Ｂ、図２１Ｃ、図２２Ａ、図２２Ｂ、図２３Ａ、及び図２３Ｂを用いて、通信端末１０−３のディスプレイに第２保険の保険料を表示する方法について説明する。

ユーザが、アプリケーションを起動して、画面上で保険料の算出したい保険の種類を選択し、選択された保険の保険料の算出を要求すると、生命保険の保険料及び自動車保険の保険料がディスプレイに表示される。

（例１）
図２１Ａに示すように、ディスプレイは、ある期間ΔＴ２における生命保険の保険料及び自動車保険の保険料を表示する。期間ΔＴ１における生命保険の保険料及び自動車保険の保険料に対する変化率を表示する。本実施形態では、生命保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はα％上昇している（図２１Ａ参照）。本実施形態では、ディスプレイ上の変動率を矢印の長さで示してもよい。この矢印の長さは、保険料の増減の大きさに応じて伸び縮みしてもよい。自動車保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はβ％（原則として、α≠β）上昇している（図２１Ａ参照）。αとβが異なるのは、生命保険の保険料を算出するときのユーザのランク付けの方法と、自動車保険の保険料を算出するときのユーザのランク付けの方法が異なることに起因する。生命保険の保険料は自動車保険の保険料と相関関係があるため、α、βいずれも正の値である。

例１では、αとβは異なるものとして説明したが、一致する場合もある。

生命保険や自動車保険の製品名や種類と保険料が対応付けて表示される（機能１：図２１Ａ）。例えばΔＴ１が１月であれば、前月・前々月等の過去の保険料を参照することができる（機能２：図２１Ｂ）。生命保険の保険料及び自動車保険の保険料を時系列のデータとして表示することもできる（機能３）。さらに、縦軸を保険料として横軸を期間として、それぞれの保険料の推移をグラフにすることもできる（機能４：図２１Ｃ）。生命保険及び自動車保険それぞれの平準純保険料に対する変動率を明示してもよい（機能５：図２１Ａ）。上記に記載した機能１〜５は、以下の例２以降にも適用できる。

（例２）
複数のユーザが存在するケースについて説明する。説明を簡単にするために、ユーザＨ１とユーザＨ２が存在する場合を検討する。図２２Ａには、ユーザＨ１の通信端末１０−３のディスプレイを表示し、図２２Ｂには、ユーザＨ２の通信端末１０−３のディスプレイを表示する。

本実施形態では、ユーザＨ１のディスプレイでは、生命保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はα１％上昇している。自動車保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はβ１％（原則として、α１≠β１）上昇している。ユーザＨ２のディスプレイでは、生命保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はα２％上昇している。自動車保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はβ２（原則として、α２≠β２）上昇している。

例１と異なる点は、α１とα２が異なり、β１とβ２が異なる点である。これは、ユーザＨ１、Ｈ２それぞれの健康状態を保険料に反映させているためである。仮にある保険の加入者がユーザＨ１、Ｈ２の２名のみである場合には、α１が正の値であるときにはα２は負の値であり、α１が負の値であるときにはα２は正の値である。β１とβ２との間についても同様に、正負が逆になる。生命保険の保険料は自動車保険の保険料と相関関係があるため、α１、β１はいずれも正負の符号が共通しており、α２、β２はいずれも正負の符号が共通している。

例１と同様に、α１とβ１は異なりα２とβ２も異なるものとして説明したが、それぞれが一致する場合もある。
（例３）
例２と同様に、複数のユーザが存在するケースについて説明する。説明を簡単にするために、ユーザＩ１、ユーザＩ２及びユーザＩ３が存在する場合を検討する。図２３Ａには、ユーザＩ１の通信端末１０−３のディスプレイを表示し、図２３Ｂには、ユーザＩ２の通信端末１０−３のディスプレイを表示し、図２３Ｃには、ユーザＩ３の通信端末１０−３のディスプレイを表示する。ユーザＩ１は急性心疾患症候群（ＡＣＳ）を既に発症している人であるとし、ユーザＩ２は、急性心疾患症候群を発症してはいないもの、将来発症する可能性が極めて高い人であるとし、ユーザＩ３は、風邪を発症している人であるとする。

本実施形態では、ユーザＩ１のディスプレイでは、生命保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はα３％上昇している。自動車保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はβ３％（原則として、α３≠β３）上昇している。ユーザＩ２のディスプレイでは、生命保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はα４％上昇している。自動車保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はβ４（原則として、α４≠β４）上昇している。ユーザＩ３のディスプレイでは、生命保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はα５％下落している。自動車保険について、期間ΔＴ１の保険料に対して期間ΔＴ２の保険料はβ５（原則として、α５≠β５）下落している。例２と異なる点は、α３＞α４、β３＞β４を満たす点である。ユーザＩ１の方がユーザＩ２よりも死亡率が高いためである。さらにα３とα４の差は、α３とα５の差及びα４とα５の差に対して小さい。これは、ユーザＩ１とユーザＩ２の関係はユーザＩ３との関係よりも近接しているため、変動率の相関も近接している。すなわち、ユーザＩ１とユーザＩ２のランクがユーザＩ３のランクと比較して近接しているためである。

例１と同様に、α３とβ４は異なりα５とβ５も異なり、さらにα６とβ６も異なるものとして説明したが、それぞれが一致する場合もある。
（例４）
例３と同じ前提とする。急性心疾患症候群で死亡するケースが多い場合には、α３とα４を他の病気を発症しているユーザの上昇率よりも大きく設定することもできる。ディスプレイの表示は例３と同様である。

次に、例１〜例４のディスプレイの表示方法と本実施形態の概念との関係性について概説する。

図２４に示すように、期間ΔＴ１のユーザの第１情報及び第２情報に基づいて、期間ΔＴ１における生命保険の保険料及び自動車保険の保険料が算出される。期間ΔＴ２（ΔＴ１期間と異なる）のユーザの第１情報及び第２情報に基づいて、期間ΔＴ２における生命保険の保険料及び自動車保険の保険料が算出される。第１変動率（Δｘｘ％）は、期間ΔＴ１における生命保険の保険料に対する期間ΔＴ２における生命保険の保険料の変動率である。第２変動率（Δｙｙ％）は、期間ΔＴ１における自動車保険の保険料に対する期間ΔＴ２における自動車保険の保険料の変動率である。第３変動率（ΔＸ％）は、期間ΔＴ１における平準純保険料（生保）に対する期間ΔＴ２における平準純保険料（生保）の変動率である。第４の変動率（ΔＹ％）は、期間ΔＴ１における平準純保険料（自動車）に対する期間ΔＴ２における平準純保険料（自動車）の変動率である。第１変動率は第３変動率と異なる。これは、第１変動率がユーザの生体情報等を加味しているためである。同様に、第２変動率は第４変動率と異なる。第２変動率がユーザの生体情報等を加味しているためである。さらに、第１変動率と第２変動率は原則として異なる。生命保険の保険料を算定するときには、ユーザの第１情報と保険加入者全体の第１情報の比較を行って、ユーザのランク付けを行っているが、自動車保険の保険料を算定するとき、ユーザの第１情報及び第２情報と保険加入者全体の第１情報及び第２情報の比較を行うだけでなく、ユーザが車両１０Ａに乗車している間の第１情報と乗車していない間の第１情報を比較することで、ユーザのランク付けを行うためである。
［１−５］第１実施形態の効果
第１実施形態によれば、以下の（１）乃至（３）の効果を得ることができる。
（１）ユーザは、保険会社に支払う保険料をまとめて管理でき、いずれの保険料もまとめて低減できる。
本実施形態では、生命保険の保険料と自動車保険の保険料が相関関係をもち、それぞれの保険料は、ユーザの生体情報に基づいて算出される。

生命保険と自動車保険が相関関係を持たない比較例と本願実施形態を比較して本実施形態の効果について説明する。この比較例の場合、ユーザは、生命保険の保険料と自動車保険の保険料の総額を低減しようとする場合、それぞれの保険の特性を把握する必要がある。しかし、本実施形態のように、生命保険の保険料と自動車保険の保険料が相関関係を持つため、それぞれの保険の特性を把握せずとも、生命保険の保険料と自動車保険の保険料の総額を簡便に低減できる。また、１期前の保険料との変動率を認識できるため、ユーザは変動率に起因する要因／原因を分析しやすい。したがって、本実施形態は、比較例と比較して、保険会社に支払う保険料をまとめて管理でき、いずれの保険料もまとめて低減でき、ユーザフレンドリーである。

（２）健康状態を維持及び改善するように、ユーザを誘導させることができる。
通信端末１０−３のディスプレイは、ユーザの求めに応じて、ユーザの健康状態を加味した生命保険の保険料と自動車の保険料を表示する。ユーザは自分の健康状態を知ることができる。そして、本実施形態に係る保険料の算出方法を適用すると、健康状態が以前より良好、又は他のユーザよりも健康状態が良好、であれば保険料が下がることから、よりユーザに健康状態を改善及び維持させようと誘導させることができる。

（３）保険会社は、ユーザへの保険金支払いのリスクを低減させることができる。
本実施形態では、生命保険の保険料と自動車保険の保険料が相関関係をもち、それぞれの保険料は、ユーザの生体情報に基づいて算出される。上記の比較例の場合には、生命保険と自動車保険ごとにリスクの分析が強いられ、リスク管理が困難となる場合がある。
しかし、本実施形態を適用すれば、保険会社は、生命保険の保険料と自動車保険の保険料をまとめて管理できるため、リスク管理も簡便に行うことができる。

また、（２）のようにユーザ１人１人の健康状態が良好に向かうと、死亡率が低減する。その結果、保険会社の保険金の支払い金額を低減させることもできる。
[２］第２実施形態
第１実施形態では、ユーザのランクを判定するために使用される条件（第１情報の条件／第２情報の条件を含む）は、設定された条件であり、一度設定された条件は第１サーバ２０の管理者が第１サーバ２０に新しい条件を設定するまで変更はされない。しかし、第２実施形態では、第１サーバ２０の管理者が設定された条件を新しい条件に変更することなく、ユーザの第１情報及び第２情報、加入者全員それぞれの第１情報及び第２情報に基づいて条件が演算され、管理者が変更することなく自動的に更新される。
図２５に示すように、ユーザに保険金を支払った旨の通知を第１サーバ２０が第３システム３や第４システム４から受信したときに、第１サーバ２０は再計算し（Ｓ６１）、ユーザに保険金を支払った旨の通知を第１サーバ２０が第３システム３や第４システム４から延べｎ回（ｎは自然数；ｎ≧２）受信したときに、第１サーバ２０はユーザそれぞれの相違に基づいて、条件を自動的に更新する（Ｓ６２）。なお、第３システム３や第４システム４から通知を受信した場合に限定されず、加入者が病気を発症したときに、すなわち通信端末１０−３のカウンタがインクリメントされたとき、通信端末１０−３は第１サーバ２０にその旨の通知を送信し、第１サーバ２０がかかる通知を受けて条件の更新を行ってもよい。

［２−１］再計算にかかるフロー（Ｓ６１）
図２５に示すように、ユーザに保険金を支払った旨の通知を第１サーバ２０が第３システム３や第４システム４から受信したときに、第１サーバ２０は再計算する（Ｓ７１）。具体的に説明すると、かかる通知を第１サーバ２０が受信すると、再計算に必要な第１情報及び第２情報をワーキングメモリ２２−６に読み出す。第１サーバ２０が必要な第１情報及び第２情報を保持していないときには、第２サーバ２１から暗号化された情報を読み出して復元する。
例示で説明すると、あるユーザの通知前の一定期間における平均の脈拍数はα６回／秒であったが、通知後の一定期間における平均の脈拍数がα７回／秒であったとき、第１サーバ２０は、ユーザの条件として平均の脈拍数がα６回／秒からα７回／秒への変化を設定する。なお、母数の平均で評価する場合には限定されず、例えば母数の平均と分散に基づいて評価してもよい。

第１サーバ２０は、ユーザそれぞれに関する通知を受けるたびに再計算を行う（Ｓ７１）。ＣＰＵ２２−１は、再計算により得られたユーザの条件を第１メモリ２２−２に保持する。かかる条件はユーザのＩＤ、病気の種類と対応付けされて第１メモリ２２−２に保持される。例えば、急性心疾患症候群（ＡＣＳ）、ユーザＪ１、平均の脈拍数がα６回／秒からα７回／秒への変化することが対応付けされて、第１メモリ２２−２に保持される。これらのデータを個人の条件と呼ぶ。

［２−２］条件の更新にかかるフロー（Ｓ６２）
図２５を用いて、条件の更新にかかるフローについて説明する。

以下、ある病気Ｋを原因として保険金を支払った旨の通知を第１サーバ２０が第３システム３や第４システム４から延べｎ回受信するごとに、第１サーバ２０は再計算する例を用いて説明する。説明を簡単にすべくｎ人に保険金を支払ったものと仮定する。各通知に対するステップ１は既に完了しているものとする。

第１サーバ２０が上記の通知を延べｎ回受信したとき（Ｓ７２、Ｙｅｓ）、第１サーバ２０は条件の更新を行う（Ｓ７３）。このステップＳ７３について詳細を説明する。まず、第１サーバ２０は、ステップ１で算出した個人の条件を第１メモリ２２−２からワーキングメモリ２２−６に読み出す。

ＣＰＵ２２−１は、個人の条件から、ｎ人の生体情報に基づいて検出された相違それぞれの共通点を条件として判定する。具体例は後述する。なお、ｎ人の生体情報に基づいて検出された相違全てに共通点が存在しない場合には、相違それぞれをグルーピングし、ユーザが最も多いグループの相違を条件として判定する。すなわち、多数決で相違を条件として判定する。

第１サーバ２０は、この条件と病気Ｋを対応付けて、コマンドとともに保険の加入者全員の通信端末１０−３に送信する（Ｓ７４）。通信端末１０−３それぞれは、かかる条件と病気Ｋに関するデータを受けて、メモリ１３−２に保持された病気Ｋに関する条件を更新する（Ｓ７５）。なお、条件と病気Ｋに関するデータを受ける前に、通信端末１０−３に病気Ｋに関する条件が設定されていない場合には、メモリ１３−２に病気Ｋに関する条件を追加して保持する。

通信端末１０−３は、ウェアラブルデバイス１０−１や車載センサ１０−２から第１情報及び第２情報を受信して、かかる第１情報及び第２情報が通信端末１０−３に設定された条件を満たす場合には、ＣＰＵ１３−１はカウンタ１３−５のうち病気Ｋにかかる回数をインクリメントする。

なお、本実施形態では、通信端末１０−３それぞれはメモリ１３−２に保持された病気Ｋに関する条件を更新するが、これに限定されることなく、例えばあるユーザの生体情報の特徴が加入者全体の生体情報の特徴と大きく乖離している場合、第１サーバ２０は、ユーザの通信端末１０−３に、ステップ６２で算出した条件でなくステップ６１で算出した個人の条件を送信してもよい。この場合には、ユーザの通信端末１０−３のメモリ１３−２にはユーザの個人の条件が設定される。例えば、ユーザは過去に病気Ｋを発症したことがあり、ユーザの個人の条件がステップ６２で算出された条件と異なる場合が考えられる。
［２−３］条件の判定方法
条件の判定方法について具体例を用いて説明する。
ｎ人のうちａ１人は通知前の一定期間における平均の脈拍数に対して通知後の一定期間における平均の脈拍数の変動率がα８〜α９であったとする。ｎ人のうちａ２人は通知前の一定期間における平均の脈拍数に対して通知後の一定期間における平均の脈拍数の変動率がβ１〜β２（α８＜β１＜β２＜α９）であったとする。残りの人は、通知前の一定期間における平均の脈拍数に対して通知後の一定期間における平均の脈拍数の変動率がγ１〜γ２（β１＜γ１＜γ２＜β２）であったとする。

この場合、第１サーバ２０は、ｎ人の全てに共通している変動率γ１〜γ２を生体情報の相違として算出する。ある期間ΔＴ１から次の期間ΔＴ２の平均脈拍数の変動率がγ１〜γ２であることを病気Ｋの条件として判定する。
なお、ｎ人の生体情報に基づいて検出された相違全てに共通点が存在しない場合には、相違それぞれをグルーピングし、ユーザが最も多いグループの相違を条件として判定する。すなわち、多数決で相違を条件として判定する。

具体例を用いて以下、説明する。ｎ人のうちａ１人は通知前の一定期間における平均の脈拍数に対して通知後の一定期間における平均の脈拍数の変動率がα８〜α９であったとする。ｎ人のうちａ２人は通知前の一定期間における平均の脈拍数に対して通知後の一定期間における平均の脈拍数の変動率がβ１〜β２（α８＜β１＜β２＜α９）であったとする。ｎ人のうちａ３人は通知前の一定期間における平均の心拍数に対して通知後の一定期間における平均の心拍数の変動率がγ１〜γ２であったとする。残りの人は、相違が検出できなかったものとする。なお、ａ１＋ａ２＞ａ３であるものとする。

この場合に、第１サーバ２０は、相違をグルーピングする。相違の少なくとも一部に共通点がある場合には、第１サーバ２０は、同じグループとして取り扱う。上記の例であれば、ａ１人の平均脈拍数とａ２人の平均脈拍数の変動率の範囲は相違するものの、（ａ１＋ａ２）人の変動率はβ１〜β２で共通する。したがって、第１サーバ２０は、条件の候補として（１）通知前の一定期間における平均の脈拍数に対して通知後の一定期間における平均の脈拍数の変動率がβ１〜β２（２）通知前の一定期間における平均の心拍数に対して通知後の一定期間における平均の心拍数の変動率がγ１〜γ２の２つを抽出する。

そして、第１サーバ２０は、条件の候補のうち条件に該当するユーザ数が多い候補と条件として判定する。上記の例であれば、ａ１＋ａ２＞ａ３であるため、条件の候補（１）を条件として判定する。

条件は、保険の加入者の第１情報及び第２情報を統計処理することにより算出している。平均値のみで統計処理する場合に限定されることなく、例えば平均と分散を用いて、分布の重なる部分で共通点を判定してもよい。
［２−４］第２実施形態の効果
第２実施形態によれば、上記第１実施形態と同様の効果を得るだけでなく、次の効果（４）及び（５）も得ることができる。
（４）ユーザの健康状態を予測でき、保険会社はリスク管理を容易にできる。

第１実施形態では、通信端末１０−３は、病気と相関関係のある条件を検知し、保険会社はリスク管理をする。つまり、第１実施形態の条件は病気との直接的な因果関係があるため、通信端末１０−３がユーザの第１情報及び第２情報から条件を満たすものを検知したときには、ユーザが既に病気にかかっている可能性または近い将来に病気にかかる可能性が高くリスクを低減するための時間が短い。

しかし、本実施形態では、ユーザのランクを判定するために使用される条件（第１情報の条件／第２情報の条件を含む）は、ユーザの第１情報及び第２情報、加入者全員それぞれの第１情報及び第２情報に基づいて演算される。

つまり、本実施形態の条件は病気との直接的な因果関係が必ずしもあるわけではなく、通信端末１０−３はユーザが病気になる可能性を第１実施形態の場合よりも早く検知できる。その結果、保険会社は第１実施形態と比較してリスク管理が容易となる。
（５）ユーザそれぞれの特徴に応じて、より正確なリスク管理が可能となる。

第２実施形態では、ユーザが過去にある病気を発症しているかに応じて、ユーザごとに異なる条件を通信端末１０−３に設定している。したがって、あるユーザの生体情報の特徴が加入者全体の生体情報の特徴と大きく乖離している場合にも、保険会社は正確なリスク管理が可能となる。
[３］第３実施形態
第１実施形態及び第２実施形態は、生命保険と自動車保険において、第１保険と第２保険が存在することを前提として説明したが、本実施形態では、第２保険のみ存在することを前提として説明する。

この場合には、図２６に示すように、第１実施形態及び第２実施形態と比較して、「ＣＰＵ２２−１は、第１保険の保険料と第２保険の保険料を比較する」ステップが省略される。したがって、ＣＰＵ２２−１は、第２保険の保険料を通信端末１０−３に送信する。

第３実施形態では、第１及び第２実施形態と同様の効果を奏することができる。
[４］第４実施形態
第１実施形態では、生命保険会社が、ユーザに対して保険金を支払った場合に、第３システム３や第４システム４が第１サーバ２０に、ネットワークを介して、ユーザに保険金を支払った旨の通知をしているが、本実施形態では、保険金を支払う事象（生命保険の場合にはユーザの死亡）をウェアラブルデバイス１０−１ａと１０−１ｂで検知する。保険金を支払う事象は、ユーザの死亡のみを示すものではなく、例えば傷害保険であれば入院費等を保険会社が支払った場合には、かかる入院も保険金を支払う事象に該当する。
[４−１］保険金を支払う事象の検知方法
図２７を用いて、以下具体的に説明する。
ウェアラブルデバイス１０−１ａとウェアラブルデバイス１０−１ｂはいずれもユーザの体温を検知できるものと仮定する。ウェアラブルデバイス１０−１ａがユーザの体温として正の温度を検知しているにもかからず、他の生体情報（例えば脈拍数）が検知できなくなったとき（Ｓ８１、Ｙｅｓ）、ウェアラブルデバイス１０−１ａは、ウェアラブルデバイス１０−１ｂに第１フラグを出力する（Ｓ８２）。人体通信の方法を用いて通信する。

ウェアラブルデバイス１０−１ｂは、ユーザの体温として正の温度を検知しているにもかからず、他の生体情報（例えば脈拍数）が検知できなくなり、かつウェアラブルデバイス１０−１ａから第１フラグを受信したとき（Ｓ８３，Ｙｅｓ）、ウェアラブルデバイス１０−１ｂは通信端末１０−３にユーザに保険金を支払う事象が生じた旨の通知を送信する（Ｓ８４）。他方で、ユーザの体温として正の温度を検知し、他の生体情報（例えば脈拍数）が検知できるときには（Ｓ８３，Ｎｏ）、ウェアラブルデバイス１０−１ｂは、再度ウェアラブルデバイス１０−１ａから第１フラグを受信するまで待機する。

通信端末１０−３が通知を受信したとき、通信端末１０−３は、ユーザに保険金を支払った旨の通知とユーザのＩＤを第１サーバ２０に送信する（Ｓ８５）。第１サーバ２０は、この通知を受信して、通知前後のある時間の範囲内における生体情報を取得する。その後のステップは第１実施形態と同様である。第１サーバ２０は再計算を行い、条件を判定する（Ｓ８６）。
［４−２］第４実施形態の効果
第４実施形態によれば、上記第１実施形態と同様の効果を得るだけでなく、次の効果（６）も得ることができる。
（６）ユーザに保険金を支払う事象が生じているか早急に検知でき、保険会社はリスク管理を容易にできる。

本実施形態では、ウェアラブルデバイス１０−１ａとウェアラブルデバイス１０−１ｂが人体通信で通信を行うため、通信ができるということはいずれのウェアラブルデバイス１０−１ａ、１０−１ｂもユーザに接触した状態であることがわかる。そのうえで、ウェアラブルデバイス１０−１がユーザの体温として正の温度を検知しているにもかからず、他の生体情報（例えば脈拍数）が検知できなくなったときには、ユーザに保険金を支払う事象が生じていることがわかる。

第１実施形態では、第１サーバ２０は、第３システム３や第４システム４からのユーザに保険金を支払った旨の通知を取得しなければユーザに保険金を支払う事象が生じているかわからない。一般的に、ユーザに保険金を支払う事象が生じる時期とかかる通知には時間差が大きく、正確な条件の算出が難しい場合がある。

しかし、本実施形態では、第３システム３や第４システム４からの通知を得えずとも、通信端末１０−３からの通知をタイムリーに受信することにより、ユーザに保険金を支払う事象が生じる時期とかかる通知には時間差を小さくでき、正確な条件の算出が可能となる。したがって、第１実施形態と比較して、保険会社はリスク管理を容易にできる。
[５］第５実施形態
第１乃至第３実施形態では、ユーザの第１情報及び第２情報が病気に対応する条件を満たしているかを判定し、この判定結果を１つの変数としてユーザのランクを算出するが、本実施形態では、病気に関する条件を判定せずに、ユーザから受信した第１情報及び第２情報のうち、ユーザの死亡率と相関性をもつ条件を１つの変数として、ユーザのランクを算出する。例えば、第１メモリ２２−２は、図２８に示すテーブルを保持する。このテーブルは、ユーザの死亡率ごとにカテゴリー分けされ、各カテゴリーに属するユーザの“第１情報及び第２情報”の条件をカテゴリーごとに対応づけされたテーブルである。

図２８であれば、ａ年後の死亡率３％のカテゴリーをＬ１とし、ａ年後の死亡率５％のカテゴリーをＬ２とし、ａ年後の死亡率７％のカテゴリーをＬ３とし、ａ年後の死亡率１０％のカテゴリーをＬ４とし、ａ年後の死亡率１２％のカテゴリーをＬ５とする。カテゴリーごとに検出する条件が異なる。本実施形態の第１サーバ２０は、このテーブルを用いて、ユーザのランクを算出する。
［５−１］条件の設定方法
本実施形態の条件の判定方法について、まず［２−３］条件の判定方法と同様に、第１サーバ２０は、ユーザぞれぞれの第１情報及び第２情報に基づいて相違を検出する。ある病気Ｌ１を原因として保険金を支払った旨の通知を第１サーバ２０が第３システム３や第４システム４からｎ回受信した場合を例に説明する。この場合に、保険の加入者をＸとし、保険会社は加入者のうちｎ人に保険金を支払ったものとする。

第１サーバ２０は、［２−３］条件の判定方法と同様に、相違の共通点を抽出して、複数のカテゴリーにグルーピングする。

［２−３］の例を用いて具体的に説明すると、ｎ人のうち、（ａ１＋ａ２）人は（１）の条件を満たし、ａ３人は（２）の条件を満たす。
（１）通知前の一定期間における平均の脈拍数に対して通知後の一定期間における平均の脈拍数の変動率がβ１〜β２
（２）通知前の一定期間における平均の心拍数に対して通知後の一定期間における平均の心拍数の変動率がγ１〜γ２
したがって、第１サーバ２０は、（１）をカテゴリーＬ１，（２）をカテゴリーＬ２としてグルーピングをし、カテゴリーＬ１に属するユーザの死亡率を

とし、カテゴリーＬ２に属するユーザの死亡率を

とする。

これにより、第１サーバ２０は、この条件（１）（２）と死亡率を対応付けてテーブルを生成する。
［５−２］ランクの算出方法
第１サーバ２０は、通信端末１０−３からユーザの第１情報及び第２情報を受信したとき、このユーザがいずれかのカテゴリーに属するか否かを判定する。いずれかのカテゴリーに属すると判定された場合には、死亡率を１つの変数として、第１サーバ２０はユーザのランクを算出する。なお、ランクの算出をせずとも、以下の式（４）を満たす増減分を平準純保険料に付加してカテゴリーに属するユーザの保険料を算出してもよい。

２つのカテゴリーが存在し、カテゴリーＬ１は死亡率３％で、カテゴリーＬ２は死亡率５％とし、カテゴリーＬ１に属するユーザの増減分をα_１とする。

ここで、Ｐは、平準純保険料を示し、α_ｉは、ｉ年間の各生存数を示し、ｂ_ｉは、ｉ年間の各年始現価率を示す。カテゴリーＡに属するユーザ数をＮ_１とし、カテゴリーＢに属するユーザ数をＮ_２とする。ユーザ数Ｎ_１〜Ｎ_２は、ｉ年の１年間ごとに相違するが、記号は人数Ｎ_１〜Ｎ_２とする。

このとき、カテゴリーＬ１に属するユーザの保険料は、Ｐ＋α_ｉであり、カテゴリーＬ２に属するユーザの保険料は、

である。
［５−３］第５実施形態の効果
第５実施形態によれば、上記第１実施形態と同様の効果を得るだけでなく、次の効果（７）も得ることができる。
（７）第１実施形態乃至第３実施形態と比較して、病気に関する条件を算出する必要がなく、早期に保険料を算出することができる
[６］第６実施形態
第６実施形態では、飲料メーカ等の広告をしたい企業または個人（以下、広告主ともよぶ）は、広告したい健康状態のユーザに対して広告できる。ユーザのディスプレイには、広告主の広告が表示される。なお、広告だけに限定されず、例えばユーザの健康状態に対するアドバイスを表示してもよい。広告とアドバイスをともに表示してもよい。以下、具体的に説明する。
［６−１］第１サーバ２０の動作について
第１サーバ２０の動作を、図３０を用いて説明する。広告主は、広告主の通信端末１０−３にアプリケーションをインストールし、アプリケーションを起動する（図２９Ａ参照）。図３０のステップＳ９１に示すように、広告主がアプリケーション上で広告したいユーザの抽出条件を入力する（図２９Ｂ参照）。例えば飲料メーカが、血圧の上下差が３０未満であるユーザに広告をしたいときには、血圧の上下差が３０未満という抽出条件を入力する。そののち、広告主の通信端末１０−３は、抽出条件を第１サーバ２０に通知する。図３０のステップＳ９２に示すように、第１サーバ２０はこの通知を受けて、保険の加入者の第１条件及び第２条件から抽出条件に合致するユーザ数を算出する。

第１サーバ２０は、合致するユーザ数を広告主の通信端末１０−３に通知する。

広告主が、通信端末１０−３に広告したい内容の画像／動画をアプリケーション上でアップロードすると（図２９Ｃ参照）、図３０のステップＳ９３に示すように通信端末１０−３のディスプレイにかかる画像／動画と、合致するユーザ数、費用が表示される（図２９Ｄ参照）。

広告主が表示を確認して発注をアプリケーション上で行うと、広告主の通信端末１０−３から第１サーバ２０に発注の通知が送信される。第１サーバ２０は抽出条件に合致するユーザの通信端末１０−３に画像／動画の広告を送信する。その結果、図３１Ａ乃至図３１Ｂに示すように、ユーザの通信端末１０−３のディスプレイに広告３００が表示される。
［６−２］ディスプレイの表示について
図３２に示すように、複数の広告主が広告をするときには、個々の抽出条件は異なる。したがって、２人のユーザの通信端末１０−３に表示される広告は異なる場合がある。

ユーザＯ１及びユーザＯ２における通信端末１０−３のディスプレイに、保険料（生命保険、自動車保険）が表示され、更に画面下に広告３００が表示される。

ユーザＯ１の場合、広告３００として、「健康なあなたにオススメ！美肌効果が得られるサプリメントが２０％オフ！」と表示される。

ユーザＯ２の場合、広告３００として、「血圧の高い貴方にオススメ！ サプリメントＡを一ヶ月飲んだｚｚ％の方が基準値に戻りました。今購入すれば保険料ｗｗ円減少します。」と表示される。
［６−３］第６実施形態の効果
第６実施形態によれば、上記第１実施形態と同様の効果を得るだけでなく、次の効果（８）も得ることができる。
（８）広告主にとっては、購買意欲のあるユーザのみに広告をすることができ、広告の効率を向上させることができる。
（９）ユーザにとっては、ユーザの健康状態に対するアドバイスにより、健康状態の維持や改善を促進する効果があり、保険料を低減しやすい。
（１０）保険会社にとっては、ユーザに健康状態の維持や改善を促進させることができ、ユーザに対する保険金の支払いリスクが低減する。
[７］第７実施形態
第７実施形態では、図３３乃至図３５を用いて、ワーキングメモリ２２−６について説明する。尚、上記各実施形態のサービスを実現するワーキングメモリ２２−６を構成する一例として、メモリポートを用いる。具体的な構成は、例えば“STORAGE DEVICE AND STORAGE METHOD”という２０１３年９月１１日に出願された米国特許出願１４／０２３９０１号に記載されている。“METHOD OF PROCESSING DATABASE, DATABASE PROCESSING APPARATUS, COMPUTER PROGRAM PRODUCT
” という２０１２年１２月２８日に出願された米国特許出願１３／７２９６３３号に記載されている。これらの特許出願は、その全体が本願明細書において参照により援用されている。
［７−１］ワーキングメモリ２２−６
図３３に示すように、ワーキングメモリ２２−６は、複数のメモリ群２００−１〜２００−４（区別しない場合には、単にメモリ群２００と呼ぶ）、及びメモリ群２００を制御するコントローラ２０１−１及び２０１−２（区別しない場合には、単にコントローラ２０１と呼ぶ）を備える。
［７−１−１］メモリ群２００
図３４に示すように、メモリ群２００は、複数のメモリポート２０００を保持する。

メモリポート２０００は、列及び行に沿って、マトリクス状に配置される。メモリポート２０００は、互いにデータの送受信を可能とするデータバスで電気的に接続される。

図３５に示すように、メモリポート２０００は、記憶部２０００ａ及びＭＰＵ２０００ｂを保持する。

記憶部２０００ａは、データを保持可能とする。記憶部２０００ａとして、例えばＮＡＮＤ型フラッシュメモリが挙げられる。メモリセルアレイの構成については、例えば、“三次元積層不揮発性半導体メモリ”という２００９年３月１９日に出願された米国特許出願１２／４０７，４０３号に記載されている。また、“三次元積層不揮発性半導体メモリ”という２００９年３月１８日に出願された米国特許出願１２／４０６，５２４号、“不揮発性半導体記憶装置及びその製造方法”という２０１０年３月２５日に出願された米国特許出願１２／６７９，９９１号、“半導体メモリ及びその製造方法”という２００９年３月２３日に出願された米国特許出願１２／５３２，０３０号に記載されている。これらの特許出願は、その全体が本願明細書において参照により援用されている。

ＭＰＵ２０００ｂは、記憶部２０００ａを制御する。あるＭＰＵ２０００ｂは、転送コマンドＣＭＤ、データの種類ＦＬＧ１及び転送先アドレスＡＤＤ１を受けて、記憶部２０００ａが保持するデータの種類と受信したデータの種類ＦＬＧ１が合致する場合に、このＭＰＵ２０００ｂは、転送先アドレスＡＤＤ１に記憶部２０００ａのデータを転送する。
［７−１−２］コントローラ２０１
コントローラ２０１−１の動作について説明する。

例えば第１実施形態乃至第６実施形態の条件の演算をするために、コントローラ２０１−１が、第１情報及び第２情報のうち必要な生体情報を抽出し、抽出された生体情報を相互に演算する場合がある。この場合、扱われる生体情報を複数回演算する。演算の回数や演算に使用する生体情報が増えれば増えるほど演算処理の高速化ができない可能性がある。

演算するたびに扱われる生体情報を読み出す作業が増えることを防ぐために、本実施形態では、コントローラ２０１−１は演算に使用する生体情報を一度抽出して、これらの生体情報を一度ある領域に移動させる。その後にコントローラ２０１−１は抽出された生体情報を用いて演算を行う。
具体的な方法については、図３６を用いて説明する。

例えば、条件の演算のために、コントローラ２０１−１は、ある保険の加入者全員の心拍に関する生体情報を領域Ｒに移動させることを考える。この場合には、コントローラ２０１−１は、メモリ群２００−１、２００−３のメモリポートに対して、転送コマンドＣＭＤ、データの種類ＦＬＧ１及び転送先アドレスＡＤＤ１を送信する（Ｓ１０１）。ここで転送先アドレスＡＤＤ１は、領域Ｒのメモリポートのうち先頭のアドレスと、かかる先頭のアドレスを管理しているコントローラのアドレスを含む。

かかる転送コマンドＣＭＤ、データの種類ＦＬＧ１及び転送先アドレスＡＤＤ１をメモリポートが受信したとき、ＭＰＵ２０００ｂは、記憶部２０００ａが保持するデータの種類と受信したデータの種類ＦＬＧ１が合致するか判定する（Ｓ１０２）。合致する場合には、このＭＰＵ２０００ｂは、転送先アドレスＡＤＤ１に記憶部２０００ａのデータを転送する（Ｓ１０３）。具体的には、転送アドレスＡＤＤ１に含まれるコントローラ２０１−２へ記憶部２０００ａのデータを他のメモリポート２０００を介して転送する。次のメモリポート２０００へ転送コマンドＣＭＤ、データの種類ＦＬＧ１及び転送先アドレスＡＤＤ１を転送する（Ｓ１０４）。合致しない場合には、次のメモリポート２０００へ転送コマンドＣＭＤ、データの種類ＦＬＧ１及び転送先アドレスＡＤＤ１を転送する（Ｓ１０４）。転送先は、領域Ｒのメモリポートを管理しているコントローラ２０１−２である。

コントローラ２０１−２は、心拍に関する生体情報を受信するたびに領域Ｒのアドレスを順に再指定して、この生体情報を領域Ｒのメモリポートに転送する（Ｓ１０５）。

コントローラ２０１−１、２０１−２は、領域Ｒに生体情報が保持されたのちに、条件の演算を行う。
［７−２］第７実施形態の効果
第７実施形態によれば、演算の回数や演算に使用する生体情報が増えても、演算に使用される生体情報を一度領域Ｒに収集している。このため、領域Ｒに保持されたデータ同士を演算することができ、演算するたびに扱われる生体情報を読み出す必要はない。

その結果、演算するたびに扱われる生体情報を読み出す作業が増えることを防ぐことができる。
[８］第８実施形態
第１実施形態乃至第７実施形態では、例えばあるユーザＶ１が保険に加入しており、通信端末１０−３から第１情報及び第２情報を第１サーバ２０に送信している。この場合に、ユーザＶ１が悪意で、ウェアラブルデバイス１０−１を保険に加入していないユーザＶ２に取り付けて保険料の算定を行おうと考える可能性がある。このとき、ウェアラブルデバイス１０−１から受信した第１情報はユーザＶ２の第１情報であるため、ユーザＶ１のＩＤとユーザＶ２の第１情報と第２情報が対応されてしまう。
［８−１］認証方法
いわゆる成りすましを防止すべく、第８実施形態では、以下の認証方法を使用する。具体的に、図３７を用いて説明する。
ユーザＶ１の通信端末１０−３とユーザＶ１のウェアラブルデバイス１０−１が通信して、通信端末１０−３から第１情報及び第２情報を受信している場合に、認証装置が通信端末１０−３に第１コマンドを発行する（Ｓ１１１）。
第１コマンドを受信してから、通信端末１０−３が第１情報及び第２情報の受信が途絶えるまでの期間を認証期間と呼ぶ。この認証期間に通信端末１０−３が受信した第１情報及び第２情報は、適正なユーザＶ１の第１情報及び第２情報である。通信端末１０−３は、かかる適正なユーザＶ１の第１情報及び第２情報であることを示すフラグを保持する（Ｓ１１２）。認証期間が経過したときに、ＣＰＵ１１−１は、認証期間中の第１情報及び第２情報に基づき、パスワードを生成する（Ｓ１１３）。このパスワードとして、例えば第１情報及び第２情報のユーザ固有の特性・特徴部分を使用する。パスワードは数字である必要はなく例えば脈拍や心電等の波形の一部である。パスワードに使用する生体情報は１つに限定されることなく例えば複数の生体情報の一部を使用してもよい。
認証期間後に、通信端末１０−３がウェアラブルデバイス１０−１、車載センサ１０−２から第１情報及び第２情報を受信するとき、ＣＰＵ１１−１は、認証期間後に受信した第１情報及び第２情報がパスワードを用いてユーザＶ１の第１情報及び第２情報であるか否かを判定する（Ｓ１１４）。すなわち、ＣＰＵ１１−１は、認証期間後に受信した第１情報及び第２情報をワーキングメモリに読み出し、受信した第１情報及び第２情報がユーザ固有の特性・特徴部分を有するか否かを判定する（Ｓ１１４）。受信した第１情報及び第２情報がユーザ固有の特性・特徴部分を有する場合には（Ｓ１１４，Ｙｅｓ）、ＣＰＵ１１−１はユーザＶ１であると判定する。受信した第１情報及び第２情報がユーザ固有の特性・特徴部分を有しない場合には（Ｓ１１４，Ｎｏ）、ＣＰＵ１１−１はユーザＶ１でないと判定する。
ＣＰＵ１１−１が受信した第１情報及び第２情報がユーザＶ１のものである判定したとき（Ｓ１１４、Ｙｅｓ）、第１乃至第７実施形態のように、各システムが動作する。ＣＰＵ１１−１が受信した第１情報及び第２情報がユーザＶ１のものでない判定したとき（Ｓ１１４，Ｎｏ）、第１乃至第７実施形態のように、各システムは動作せず、再認証をするまで計測が開始されない。
［８−２］第８実施形態の効果
第８実施形態によれば、ユーザＶ１の通信端末１０−３とユーザＶ１のウェアラブルデバイス１０−１が通信して、通信端末１０−３から第１情報及び第２情報を受信している場合に、認証装置が通信端末１０−３に第１コマンドを発行する。このため、いわゆる成りすましを防止することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

Claims (24)

1. 第1保険の第1保険料と、前記第1保険と異なる第2保険の第2保険料であって、前記第1保険料が上がると上昇する前記第2保険料とを表示できる表示部を備えた通信端末。
2. 前記表示部は、第1保険の第1平準純保険料と、前記第1平準純保険料と異なる第2保険の第2平準純保険料を表示できる請求項１記載の通信端末。
3. 前記第1保険は生命保険であり、前記第2保険は自動車保険である請求項１記載の通信端末。
4. 前記第1保険料が下がると、前記第2保険料が下がる請求項１記載の通信端末。
5. 第1期間における第1保険料から第2期間における第1保険料の変動率は、第1期間における第1平準純保険料から第2期間における第1平準純保険料の変動率と異なる請求項２記載の通信端末。
6. 第1期間における第2保険料から第2期間における第2保険料の変動率は、第1期間における第2平準純保険料から第2期間における第2平準純保険料の変動率と異なる請求項５記載の通信端末。
7. 前記第1保険は生命保険であり、前記第2保険は自動車保険である請求項６記載の通信端末。
8. 前記第1保険料が下がると、前記第2保険料が下がる請求項６記載の通信端末。
9. 第1保険の第1保険料と、前記第1保険と異なる第2保険の第2保険料であって、前記第1保険料が上がると上昇する前記第2保険料とを表示できる表示部を備えた通信端末と、
   生体情報に関連する第1情報を検知するセンサーを有し、前記通信端末と通信可能なウエアブル装置と、
   前記通信端末と通信可能なサーバー装置と、
   備えた装置。
10. 前記表示部は、第1保険の第1平準純保険料と、前記第1平準純保険料と異なる第2保険の第2平準純保険料を表示できる請求項９記載の装置。
11. 前記第1保険は生命保険であり、前記第2保険は自動車保険である請求項９記載の装置。
12. 前記第1保険料が下がると、前記第2保険料が下がる請求項９記載の装置。
13. 第1期間における第1保険料から第2期間における第1保険料の変動率は、第1期間における第1平準純保険料から第2期間における第1平準純保険料の変動率と異なる請求項１０記載の装置。
14. 第1期間における第2保険料から第2期間における第2保険料の変動率は、第1期間における第2平準純保険料から第2期間における第2平準純保険料の変動率と異なる請求項１３記載の装置。
15. 前記第1保険は生命保険であり、前記第2保険は自動車保険である請求項１４記載の装置。
16. 前記第1保険料が下がると、前記第2保険料が下がる請求項１４記載の装置。
17. 第1保険の第1保険料と、前記第1保険と異なる第2保険の第2保険料であって、前記第1保険料が上がると上昇する前記第2保険料とを表示部に表示させることのできるアプリケーションを備えた端末装置。
18. 前記表示部は、第1保険の第1平準純保険料と、前記第1平準純保険料と異なる第2保険の第2平準純保険料を表示できる請求項１７記載の端末装置。
19. 前記第1保険は生命保険であり、前記第2保険は自動車保険である請求項１７記載の端末装置。
20. 前記第1保険料が下がると、前記第2保険料が下がる請求項１７記載の端末装置。
21. 第1期間における第1保険料から第2期間における第1保険料の変動率は、第1期間における第1平準純保険料から第2期間における第1平準純保険料の変動率と異なる請求項１８記載の端末装置。
22. 第1期間における第2保険料から第2期間における第2保険料の変動率は、第1期間における第2平準純保険料から第2期間における第2平準純保険料の変動率と異なる請求項２１記載の端末装置。
23. 前記第1保険は生命保険であり、前記第2保険は自動車保険である請求項２２記載の端末装置。
24. 前記第1保険料が下がると、前記第2保険料が下がる請求項２２記載の端末装置。