JP6716150B1 - 情報処理装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】商業的利用又は私的利用を含むステータスが変化する乗り物を運転するドライバー又は乗り物に対し、適切な保険を提供する。【解決手段】保険管理システムにおいて、情報処理端末は、乗り物の商業的利用及び私的利用のいずれかの利用時における、ドライバーの運転状況を示すイベントを含むイベント情報と、ドライバーに関するドライバー情報とを受信する受信部と、イベント情報に基づくリスクを用いて、ドライバー情報により特定される前記ドライバー又は乗り物の保険料を決定する決定部と、決定された保険料を示す保険料情報を、ドライバーが使用する処理端末に送信する送信部と、を備える。【選択図】図１７

Description

開示技術は、情報処理装置、情報処理方法、及びプログラムに関する。

近年、ライドシェアが一般的に利用されるようになり、ドライバーが車両を運転する際に、商業的利用や私的利用などの様々な運転のステータスがある。この場合、従来の保険を適用するとすれば、商業的利用と、私的利用とでそれぞれ異なる保険が適用されることが考えられる。

例えば特許文献１には、ライドシェアを利用するドライバーに対し、商業的利用時の保険が適用されるのか、私的利用時の保険が適用されるのかを決定するために、ライドシェア中であることを示す特定情報を表示することが開示されている。つまり、特定情報が表示されている場合は、商業的利用時であるとして、この間の事故等には商業的利用時の保険が適用される。

米国特許明細書９５０５４９４号公報

しかしながら、特許文献１に記載の技術では、同じドライバーであっても商業的利用と私的利用とで保険がそもそも別であり、保険会社は、ドライバーがどちらの利用をしていたかを特定する必要がある。また、ドライバーにとっても、自身が加入する保険が複雑化し、保険の管理が煩雑になってしまう。別の観点では、保険会社のサーバは、商業的利用時と私的利用時との両方の保険を管理する必要があり、その結果、サーバ資源を有効に活用することができず、また、管理コストが増大してしまう。そこで、商業的利用又は私的利用を含むステータスが変化する乗り物を運転するドライバー又は乗り物に対して、適切な保険の提供が求められている。

開示技術は、以上説明した事情に鑑みてなされたものであり、商業的利用又は私的利用を含むステータスが変化する乗り物を運転するドライバー又は乗り物に対し、適切な保険を提供することを目的とする。

開示技術の一態様である情報処理装置は、乗り物の商業的利用及び私的利用のいずれかの利用時における、ドライバーの運転状況を示すイベントを含むイベント情報と、前記ドライバーに関するドライバー情報とを受信する受信部と、前記イベント情報に基づくリスクを用いて、前記ドライバー情報により特定される前記ドライバー又は前記乗り物の保険料を決定する決定部と、決定された前記保険料を示す保険料情報を、前記ドライバーが使用する処理端末に送信する送信部と、を備える。

開示技術によれば、商業的利用又は私的利用を含むステータスが変化する乗り物を運転するドライバー又は乗り物に対し、適切な保険を提供することができる。

本開示の保険管理システム概要を説明するための図である。 第１実施形態に係るサーバ１０のハードウェア構成の一例を示す図である。 第１実施形態に係る処理端末２０のハードウェア構成の一例を示す図である。 第１実施形態に係る第１サーバ１０Ａの機能構成の一例を示すブロック図である。 第１実施形態に係るドライバー情報の一例を示す図である。 第１実施形態に係る位置関連情報の一例を示す図である。 第１実施形態に係るイベント関連情報の一例を示す図である。 第１実施形態に係る第２サーバ１０Ｂの機能構成の一例を示すブロック図である。 第１実施形態に係る加速度関連情報の一例を示す情報である。 第１実施形態に係るステータス関連情報の一例を示す情報である。 第１実施形態に係る走行実績情報の一例を示す図である。 第１実施形態に係る走行距離リスクの係数の一例を示す図である。 第１実施形態に係る走行時間リスクの係数の一例を示す図である。 第１実施形態に係るスコア係数の一例を示す図である。 第１実施形態に係る処理端末２０の機能構成の一例を示す図である。 第１実施形態に係る処理端末２０の画面例を示す図である。 第１実施形態に係る保険管理システム１の処理に関するシーケンス図である。 第１実施形態に係る保険料決定処理の一例を示すフローチャートである。

以下、開示の実施形態について、図面を参照しつつ詳細に説明する。なお、以下の実施形態は、本発明を説明するための例示であり、開示技術をその実施形態のみに限定する趣旨ではない。また、開示技術は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均等なものに置換した実施の形態を採用することが可能であり、かかる実施形態も開示技術の範囲に含まれる。またさらに、必要に応じて示す上下左右等の位置関係は、特に断らない限り、図示の表示に基づくものとする。さらにまた、図面における各種の寸法比率は、その図示の比率に限定されるものではない。また、同一の要素には同一の符号を付し、重複する説明を省略する。

以下、添付図面を参照しながら本開示の実施形態について詳細に説明する。

＜システム概要＞
図１は、本開示の保険管理システム概要を説明するための図である。図１に示す例では、運転手（ドライバー）ＵＡが情報処理装置２０Ａを利用して車両３０Ａを運転し、ライドシェアサービス（例えば、Ｕｂｅｒ，Ｌｉｆｔなど）を提供する。また、運転手（ドライバー）が情報処理装置２０Ｂを利用し、自転車３０Ｂを操作し、配達サービス（例えば、ＵｂｅｒＥａｔｓやメッセンジャーなど）を提供する。

なお、Ａ符号及びＢ符号を区別せず共通して使用する場合は、Ａ及びＢが省略されて表示される。例えば、情報処理装置２０Ａ及び２０Ｂを区別せず、まとめて表現する場合は、情報処理装置２０とし、車両３０Ａ及び自転車２０Ｂを区別せず、まとめて表現する場合は、乗り物３０とし、ドライバーＵＡ及びＵＢを区別せず、まとめて表現する場合は、ドライバーＵとする。乗り物３０の数は２つに限定されず、多くの乗り物３０がこのシステムを利用可能である。

情報処理装置２０は、例えば、スマートフォンなどの携帯電話や、タブレット端末、パーソナルコンピュータ、車載器などのプロセッサとメモリと通信インターフェースと、必要に応じてＧＰＳ（Global Positioning System）、加速度センサ及び／又は角速度センサとを有する装置である。

保険管理システム１では、乗り物３０に付帯する情報処理装置２０からドライバーＵを特定するドライバー情報や、乗り物３０の位置や速さを含む位置関連情報や、ドライバーＵの運転状況を示すイベントを含むイベント情報が、第１情報処理装置１０Ａに送信される。第１情報処理装置１０Ａは、乗り物３０に商業的利用サービスを提供する会社が管理するサーバ等であり、取得したドライバー情報、位置関連情報、イベント情報を、第２情報処理装置１０Ｂに送信する。第２情報処理装置１０Ｂは、保険会社が管理するサーバ等であり、取得したドライバー情報、位置関連情報、イベント情報等に基づいて、商業的利用又は私的利用のステータスに応じたリスクを特定し、このリスクに基づいて保険料を決定する。

これにより、乗り物３０を運転するドライバーＵ又は乗り物３０に対し、商業的利用又は私的利用のステータスに応じたリスクを特定することで、商業的利用なのか、私的利用なのかをドライバーに意識させずに共通の保険料を決定し、提示することが可能になる。また、保険会社では、商業的利用又は私的利用がなされる１つの車両に対して共通して保険を適用することでき、保険を複雑化させずに、自身が管理運営するサーバの資源を有効活用することができ、管理コストの増大を軽減する。また、商業的利用又は私的利用の各ステータスに応じたリスクを用いることで、ドライバーＵ又は乗り物３０に対して、適切なリスクを推定することが可能になる。

［第１実施形態］
次に、第１実施形態における保険管理システムを実現するためのシステム構成について、図１を用いて説明する。図１に示すように、ドライバーＵが利用する情報処理装置（以下、「処理端末」とも称する。）２０と、乗り物３０に商業的利用サービスを提供する会社が管理する第１情報処理装置（以下、「第１サーバ」とも称する。）１０Ａと、保険会社が管理する第２情報処理装置（以下、「第２サーバ」とも称する。）１０Ｂとが、ネットワークを介して相互に通信可能に接続されることにより、保険管理システム１が構成される。

なお、乗り物３０自身がセンサ等で取得されたデータを第１情報処理装置１０Ａに通信可能にしてもよい。第１実施形態では、乗り物３０は、ライドシェアサービスをドライバー側で利用する車両３０Ａを例にして説明する。車両３０Ａは、自動車、二輪車、飛行機、ヘリコプターなど人を乗せて移動することができる乗り物を意味する。第１サーバ１０Ａと第２サーバ１０Ｂとを区別しない場合は、単にサーバ１０と表記する。

処理端末２０Ａは、ドライバーＵＡの操作に応じて、車両３０Ａを運転するドライバーＵＡの運転状況を示すイベントを含むイベント情報を第１サーバ１０Ａに送信する。例えば、車両３０Ａの場合、イベントは、ライドシェアサービスを実行するアプリケーション（以下、「ライドシェア管理アプリ」とも称する。）がＯＮになったことを示すイベントや、乗客をピックアップしに行くことを示すイベントや、乗客を乗せたことを示すイベントや、乗客を降ろしたことを示すイベントなどを含む。処理端末２０Ａでは、ライドアプリによって、乗り物３０の位置や速さを含む位置関連情報が第１サーバ１０Ａに送信される。このとき、ドライバーＵＡを特定するためのドライバー情報もライドシェア管理アプリにより送信される。

第１サーバ１０Ａは、ライドシェア管理アプリを介して、ドライバー情報、位置関連情報、イベント関連情報を取得して管理し、必要に応じて、第２サーバ１０Ｂにこれらの情報を送信する。第１サーバ１０Ａは、イベント情報に応じてドライバーの報酬を決定したり、位置関連情報を用いて走行経路を管理したりする。なお、ドライバー情報は、ハッシュ化されたり、別の情報に変換されたりして送信されてもよい。

第２サーバ１０Ｂは、第１サーバ１０Ａから送信される情報を用いて、車両３０Ａのイベントの変化に応じて、商業的利用又は私的利用を含む現在のステータスを特定し、そのステータスに応じたリスク（「ステータス別リスク」とも称する。）を求め、そのリスクに応じた保険料を決定する。保険料は所定期間、例えば１か月や半年、１年などの単位であり、或る所定期間（例えば１月）内の平均リスクなどを用いて次の所定期間の保険料が決定される。また、第２サーバ１０Ｂは、位置関連情報を用いて、所定期間（例えば１日）の走行距離や走行時間とステータス別リスクとを用いて走行実績リスクを算出したり、車両３０Ａの速さや車両３０Ａの走行している道路の危険度合などから走行スコアを算出したりしてもよい。第２サーバ１０Ｂは、走行実績リスク及び運転スコアに基づいて保険料を決定してもよい。

第２サーバ１０Ｂは、決定した保険料をドライバーＵＡが使用する処理端末２０Ａに通知し、処理端末２０Ａは、通知された保険料を画面に表示することで、ドライバーＵＡは、自身の保険料を知ることができる。また、第２サーバ１０Ｂは、運転スコアを分析することにより、ドライバーＵＡに対して運転アドバイスを提供してもよい。例えば、第２サーバ１０Ｂは、各ステータスに応じた運転スコア等を分析することにより、ドライバーＵＡに対して、各ステータスに応じた運転のアドバイスを行うことが可能になる。

図１に示す各装置が接続するネットワークは、複数種の通信回線や通信網及び種々のネットワーク機器を含んで構成され得る。例えば、ネットワークは、第１サーバ１０Ａ及び第２サーバ１０Ｂに無線接続される基地局や、無線ＬＡＮのアクセスポイント（ＷｉＦｉルータ等）、基地局に接続された移動体通信網、アクセスポイントからルータやモデムを介して接続された電話回線、ケーブルテレビ回線又は光通信回線などの公衆回線、サーバ１０に接続されたインターネット、移動体通信網や、公衆回線とインターネットを接続するゲートウェイ装置などを含む。

＜ハードウェア構成＞
次に、保険管理システム１に係る各装置のハードウェア構成について説明する。図２は、第１実施形態に係るサーバ１０のハードウェア構成の一例を示す図である。図２に示すように、サーバ１０は、制御部１０２と、通信インターフェース１０４と、記憶部１０６と、を有し、各部はバスライン１１２を介して接続される。

制御部１０２は、１又は複数のプロセッサ（ＣＰＵ（Central Processing Unit））、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等を含む。また、制御部１０２は、記憶部１０６に記憶されるアプリケーション等を実行することにより、各機能を実現するように構成される。アプリケーションは、サーバ１０が第１サーバ１０Ａの場合、ライドシェア管理アプリであり、サーバ１０が第２サーバ１０Ｂの場合、保険料を決定するためのアプリケーション（「保険料決定アプリ」とも称する。）である。

通信インターフェース１０４は、ネットワークを介して処理端末２０との通信を制御する。

記憶部１０６は、例えば大容量の複数のＨＤＤ等からなり、サーバ機能を実現するためのアプリケーション及びデータ（図示省略）を記憶することに加え、制御プログラム１０８を記憶する。また、記憶部１０６は、情報記憶部１１０を有する。

制御プログラム１０８は、ライドシェア管理アプリ及び／又は保険料決定アプリを実行するプログラムである。例えば、制御プログラム１０８が保険料決定アプリの場合、制御プログラム２０は、第１サーバ１０Ａから取得した情報に基づいてドライバーの運転状況のステータスを認識したり、ステータス別リスクに基づいて走行実績のリスクを評価したりする。

情報記憶部１１０は、各アプリの処理に用いられる情報などを記憶する。例えば、情報記憶部１１０は、保険料決定アプリに対して、ステータス別スコアや、保険料の算出式、運転スコアの算出式などを記憶してもよい。

次に、処理端末２０のハードウェア構成について説明する。図３は、第１実施形態に係る処理端末２０のハードウェア構成の一例を示す図である。図３に示すように、処理端末２０は、制御部２０２と、通信インターフェース２０６と、記憶部２０８と、表示部２１４と、入力部２１６と、マイク２２０と、スピーカ２２２と、センサ２２４とを有し、各部はバスライン２１８を介して接続される。

制御部２０２は、１又は複数のプロセッサ（ＣＰＵ）、ＲＯＭ、ＲＡＭ２０４等を含む。制御部２０２は、記憶部２０８に記憶されるアプリケーション等を実行することにより、一般的な情報処理装置としての機能に加え、ライドシェアのドライバー側の機能を実現するように構成される。

また、ＲＡＭ２０４は、各種情報を一時的に保持したり、ＣＰＵが各種処理を実行する際のワークエリアとして使用されたりする。

通信インターフェース２０６は、ネットワークを介してサーバ１０との通信を制御する。

記憶部２０８は、例えばＨＤＤ等を含み、一般的な情報処理装置としての機能を実現するためのアプリケーション及びデータ（図示省略）を記憶することに加え、アプリプログラム２１０を記憶する。また、記憶部２０８は、情報記憶部２１２を有している。

アプリプログラム２１０は、ドライバー側のライドシェア管理アプリを実行するためのプログラムである。例えば、アプリプログラム２１０は、経路表示機能や、乗客決定機能や、イベント通知機能などを有する。また、アプリプログラム２１０は、各種データやリクエストをサーバ１０に送信したり、サーバ１０から各種データを受信したりするプログラムである。

情報記憶部２１２は、システムへのログイン情報や、ライドシェアに用いるデータなどを記憶する。

表示部２１４は、例えばタッチパネルや液晶モニターなどのディスプレイであり、ドライバーに情報を表示する。例えば、表示部２１４は、アプリケーションの実行画面を表示し、具体的には、経路を含むマップ画面や保険料表示画面などを表示する。

入力部２１６は、ユーザからの入力を受け付けたり、ユーザからの指示を受け付けたりする。なお、表示部２１４と入力部２１６とは、タッチパネルとして構成されてもよい。

マイク２２０は、音声などの音を集音するデバイスであり、ノイズキャンセル機能などを有してもよい。スピーカ２２２は、音声データを物理振動に変えて、音声などの音を出力するデバイスである。

センサ２２４は、各種センサを有し、例えば、ＧＰＳや、加速度センサ、角速度センサなどのうち少なくとも１つを有する。センサ２２４によりセンシングされた位置情報や、速さ情報、加速度情報の少なくとも１つの情報は、第１サーバ１０Ａに送信される。なお、センサ２２４は、車両３０Ａに車載器として設けれ、センシングされたデータは、車両３０Ａから送信されてもよい。

＜機能構成＞
次に、図４〜図７を用いて、第１実施形態に係る第１サーバ１０Ａの機能について、図８〜１４を用いて、第２サーバ１０Ｂの機能について、図１５〜１６を用いて、処理端末２０の機能について説明する。図４は、第１実施形態に係る第１サーバ１０Ａの機能構成の一例を示すブロック図である。図４に示す第１サーバ１０Ａは、第１通信部４０２Ａ、第１記憶部４０８Ａ、及び第１アプリ制御部４１０Ａを有する。

第１通信部４０２Ａは、例えば、制御部１０２や通信インターフェース１０４などにより実現されうる。第１記憶部４０８Ａは、例えば記憶部１０６により実現されうる。第１アプリ制御部４１０Ａは、例えば制御プログラム１０８が制御部１０２により実行されることにより実現されうる。

第１通信部４０２Ａは、処理端末２０や第２サーバ１０Ｂと、ネットワークを介して通信を行うものである。例えば、第１受信部４０６Ａは、処理端末２０等から受信したドライバー情報、位置関連情報、イベント関連情報を、第１アプリ制御部４１０Ａに供給する。また、第１送信部４０４Ａは、第１アプリ制御部４１０Ａから供給されたデータを、第２サーバ１０Ｂへ送信する機能を有する。

第１記憶部４０８Ａは、各種プログラムや各種データを記憶するためのものである。ここで、第１記憶部４０８Ａに記憶されるプログラムは、ライドシェアに関するプログラムである。また、第１記憶部４０８Ａには、ライドシェアに関するデータや表示データや各種演算結果のデータなども記録される。

例えば、第１記憶部４０８Ａには、ドライバー情報、位置関連情報、イベント関連情報などが記憶される。これらの情報は、物理的に別の記憶部に記憶されてもよいし、１つの記憶部が論理的に分割されて記憶されてもよい。第１記憶部４０８Ａに記憶される各情報の詳細は、図５〜７を用いて後述する。なお、第１記憶部４０８Ａは、第１サーバ１０Ａとは別体のデータベースでもよい。

第１アプリ制御部４１０Ａは、第１実施形態におけるライドシェアを例にして説明すれば、ドライバー側の機能モジュールと、乗客側の機能モジュールとを有する。また、第１アプリ制御部４１０Ａは、ライドシェアサービスを実現し、第１取得部４１２Ａ、転送部４１４Ａを有する。機能モジュールは、制御部１０２で実行される上記各種プログラムにより実現され、或いは、ファームウェアとして制御部１０２に実装されてもよい。

第１取得部４１２Ａは、第１記憶部４０８Ａから所定の情報を取得する。取得された情報は、第１アプリ制御部４１０Ａによりライドシェアに関する処理に用いられる。

転送部４１４Ａは、第１取得部４１２Ａにより取得された所定の情報を、第１送信部４０４Ａを介して第２サーバ１０Ｂに送信するように、転送制御を行う。このとき、ドライバー情報について、転送部４１４Ａは、セキュリティの観点により、ハッシュ化したり、第２サーバ１０Ｂとで共通の規則に従い、別の情報に変換して送信したりしてもよい。所定の情報は、例えばドライバー情報及びイベント関連情報であり、位置関連情報を含んでもよい。

図５は、第１実施形態に係るドライバー情報の一例を示す図である。図５に示す例では、ドライバー情報は、ドライバーの個人ＩＤ、氏名、年齢、住所などを含む情報である。また、このドライバーが使用する車両の車両特定情報を示す１又は複数のＶＩＮ（Vehicle Identification Number）情報がドライバー情報に含まれてもよい。

個人ＩＤは、ライドシェアを利用する際にライドシェア管理アプリにログインするためのＩＤなどであり、このサービスに加入するときにドライバーに対して設定されるＩＤである。ＶＩＮ情報は、車両を特定するための情報であり、氏名は、ドライバーの氏名を表し、住所は、ドライバーが住んでいる住所を示す。住所は、ドライバーが住んでいる地域などでもよい。

図６は、第１実施形態に係る位置関連情報の一例を示す図である。図６に示す例では、位置関連情報は、個人ＩＤ、時刻情報、速さ、緯度、及び経度の各情報を含む。また、位置関連情報は、地図情報提供アプリケーションなどから取得した、緯度及び経度情報に関連付けられる道路種別（高速道路や一般道路）や交通状況（渋滞等）などの情報を含んでもよい。

個人ＩＤは、上述した個人ＩＤと同様であり、ライドシェアを利用する際にライドシェア管理アプリにログインするためのＩＤである。時刻情報は、所定時点の時刻を示す時刻情報であり、速さ情報は、例えば所定時点の速さであり、緯度及び経度情報は、所定時点の位置を示す位置情報である。位置情報は、ＧＰＳなどにより取得される情報である。所定時点は、例えば、一秒ごと、数秒ごとの単位で計測されてもよい。

図７は、第１実施形態に係るイベント関連情報の一例を示す図である。図７に示す例では、イベント関連情報は、個人ＩＤ、時刻、イベントの各情報を含む。

個人ＩＤは、上述した個人ＩＤと同様であり、ライドシェアを利用する際にライドシェア管理アプリにログインするためのＩＤである。時刻情報は、イベントが発生した時点の時刻を示す時刻情報であり、イベント情報は、商業的利用及び私的利用のいずれかの利用時における、ドライバーの運転状況を示すイベントを示す情報である。イベントは、例えば、ライドシェア管理アプリの起動時を示すイベントである「app on」、乗客が決まったことを示すイベントである「booking」、乗客を乗せたことを示すイベントである「boarding」、乗客が降りたことを示すイベントである「dropping」を含む。

図５〜７に記載された情報の少なくとも１部は、第２サーバ１０Ｂに送信され、ライドシェアを利用する車両を運転するドライバーに対する保険料の決定に用いられる。

図８は、第１実施形態に係る第２サーバ１０Ｂの機能構成の一例を示すブロック図である。図８に示す第２サーバ１０Ｂは、第２通信部４０２Ｂ、第２記憶部４０８Ｂ、第２アプリ制御部４１０Ｂを有する。

第２通信部４０２Ｂは、例えば、制御部１０２や通信インターフェース１０４などにより実現されうる。第２記憶部４０８Ｂは、例えば記憶部１０６により実現されうる。第２アプリ制御部４１０Ｂは、例えば制御プログラム１０８が制御部１０２により実行されることにより実現されうる。

第２通信部４０２Ｂは、処理端末２０や第１サーバ１０Ａと、ネットワークを介して通信を行うものである。例えば、第２受信部４０６Ｂは、乗り物３０の商業的利用及び私的利用のいずれかの利用時における、ドライバーの運転状況を示すイベントを含むイベント情報と、ドライバーに関するドライバー情報とを受信する。また、第２受信部４０６Ｂは、第１サーバ１０Ａから、ドライバー情報、位置関連情報、イベント関連情報を受信してもよい。この場合、第２受信部４０６Ｂは、第１サーバ１０Ａ等から受信したドライバー情報、位置関連情報、イベント関連情報を、第１アプリ制御部４１０Ａに供給する。

第２送信部４０４Ｂは、第２アプリ制御部４１０Ｂから供給されたデータを、処理端末２０へ送信する。例えば、第２送信部４０４Ｂは、後述する決定部４１６により決定された保険料を示す保険料情報を、ドライバーが使用する処理端末２０に送信する。

第２記憶部４０８Ｂは、各種プログラムや各種データを記憶するためのものである。ここで、第２記憶部４０８Ｂに記憶されるプログラムは、保険料の決定に関するプログラムである。また、第２記憶部４０８Ｂには、ライドシェアに関するデータや、保険料の決定に関するデータや、表示データや、各種演算結果のデータなども記録される。

例えば、第２記憶部４０８Ｂには、ドライバー情報、加速度関連情報、ステータス関連情報などが記憶される。これらの情報は、物理的に別の記憶部に記憶されてもよいし、１つの記憶部が論理的に分割されて記憶されてもよい。第２記憶部４０８Ｂに記憶される各情報の詳細は、図９〜１４を用いて説明する。ドライバー情報は、ドライバーの情報を記憶しており、図５に示す情報と同様であるが、保険会社が必要とする情報を追加して格納しておいてもよい。なお、第２記憶部４０８Ｂは、第２サーバ１０Ｂとは別体のデータベースでもよい。

図９は、第１実施形態に係る加速度関連情報の一例を示す情報である。図９に示す例では、加速度関連情報は、図６に示す位置関連情報に、加速度の情報が追加されている。加速度は、速さを微分することで算出される。なお、処理端末２０が加速度センサを有している場合は、第２サーバ１０Ｂは、処理端末２０の加速度センサが計測した加速度を、第１サーバ１０Ａ経由で取得してもよい。

図１０は、第１実施形態に係るステータス関連情報の一例を示す情報である。図１０に示す例では、ステータス関連情報は、図７に示すイベント関連情報に、スタータスの情報が追加されている。スタータスは、イベントの遷移に応じて決定される。例えば、ステータスは、以下のように決定される。
「app on」イベント以前：private（私的利用）ステータス
「app on」イベントから「booking」イベントまで：waiting（待ち）ステータス
「booking」イベントから「boarding」イベントまで：pick up(ピックアップ)ステータス
「boarding」イベントから「dropping」イベントまで：on board（搭乗中）ステータス
「dropping」イベントから「booking」又は「app off」イベントまで：waiting（待ち）ステータス
「app off」イベント以降：private（私的利用）ステータス

図１１は、第１実施形態に係る走行実績情報の一例を示す図である。走行実績情報は、例えば第２記憶部４０８Ｂに記憶される。図１１に示す例では、走行実績情報は、ステータスごとに、走行距離、走行時間、ステータス別リスク、走行距離リスク、走行時間リスクが関連付けられる。

ステータスは、決定部４１６によりイベント遷移に基づいて決定される。走行距離は、ステータスごとに、そのステータスの時に走行した距離が合算された値である。走行時間は、ステータスごとに、そのステータスの時に走行した時間が合算された値である。ステータス別リスクは、ステータスごとに予め設定された値であり、基本的には異なる値であるが、一部同じ値であってもよい。走行距離リスクは、ステータスごとに、走行距離×ステータス別リスクで求められる値である。走行時間リスクは、ステータスごとに、走行時間×ステータス別リスクで求められる値である。

図１２は、第１実施形態に係る走行距離リスクの係数の一例を示す図である。図１２に示す例では、走行距離リスクを所定の範囲ごと区切って分類し、分類された範囲ごとに係数が対応付けられる。図１２に示す例では、距離リスクが小さくなるにつれ、係数の値も小さくなる。

図１３は、第１実施形態に係る走行時間リスクの係数の一例を示す図である。図１３に示す例では、走行時間リスクを所定の範囲ごと区切って分類し、分類された範囲ごとに係数が対応付けられる。図１３に示す例では、時間リスクが小さくなるにつれ、係数の値も小さくなる。

図１４は、第１実施形態に係るスコア係数の一例を示す図である。図１４に示す例では、運転スコアを所定の範囲ごとに区切って分類し、分類された範囲ごと係数が対応付けられる。図１４に示す例では、運転スコアが小さくなるにつれ（運転技術が悪くなるにつれ）、係数の値は大きくなる。なお、運転スコアは公知の技術を用いて算出されればよい。

図８に戻り、第２アプリ制御部４１０Ｂは、第１実施形態における保険料を決定する機能モジュールを有し、例えば、第２取得部４１２Ｂ、決定部４１６を有する。機能モジュールは、制御部１０２で実行される上記各種プログラムにより実現され、或いは、ファームウェアとして制御部１０２に実装されてもよい。

第２取得部４１２Ｂは、第２記憶部４０８Ｂから所定の情報を取得する。取得された情報は、第２アプリ制御部４１０Ｂにより保険料の決定に関する処理に用いられる。

決定部４１６は、イベント情報に基づくリスクを用いて、ドライバー情報により特定されるドライバーの保険料を決定する。例えば、決定部４１６は、運転状況を示すイベントに応じたリスクを予め決定しておき、イベントの発生頻度等に応じて、そのドライバーの平均リスクを算出し、この平均リスクを用いて保険料を決定してもよい。具体的には、決定部４１６は、基本の保険料に、平均リスクから特定される係数を乗算して次の保険料を決定してもよい。保険料を更新するタイミングは、１か月単位でもよいし、数か月単位、年単位、所定日単位でもよい。決定された保険料を示す保険料情報は、ドライバーが使用する処理端末２０に送信される。また、決定部４１６は、私的利用を示すイベントと、商業的利用を示すイベントとにそれぞれのリスクを対応付けておくことで、私的利用時の走行実績及びリスク、並びに、商業的利用時の走行実績及びリスクにより保険料を決定してもよい。

これにより、乗り物３０を運転するドライバーＵに対し、商業的利用又は私的利用のステータスに応じたリスクを特定することで、商業的利用なのか、私的利用なのかをドライバーに意識させずに共通の保険料を決定することが可能になる。また、保険会社では、商業的利用及び私的利用がなされる１つの車両に対して共通して保険を適用することでき、保険を複雑化させずに、自身が管理運営するサーバの資源を有効活用することができ、管理コストの増大を軽減することができる。

また、商業的利用は、複数の異なるイベントを含んでもよい。例えば、商業的利用時のイベントは、上述したとおり、bookingやboardingやdroppingなどのイベントを含む。この場合、決定部４１６は、各イベント間のステータスに対し、異なるリスクを適用可能である。例えば、イベント遷移に応じて特定されるステータスごとに、所定のリスクが設定され、決定部４１６は、ステータスに応じて特定されるリスクに基づいて、保険料を決定してもよい。また、商業的利用時のステータスは、例えば、私的利用時のステータス以外のステータス（例えば、待ち、ピックアップ、搭乗中のステータス）を含んでもよい。このとき、決定部４１６は、私的利用時と商業的利用時とでリスクを分けて、さらに商業的利用時の各ステータスに応じてリスクを特定してもよい。

これにより、商業的利用時に取り得るステータスに応じてリスクを設定することができるので、より適切な保険料を算出することが可能になる。また、商業的利用時に用いる複数のイベントのみを用いて、商業的利用時における適切な保険料の決定を行ってもよい。このとき、私的利用時には一般的な保険が適用され、商業的利用時には、ステータス別リスクを用いる保険が適用されてもよい。

また、第２受信部４０６Ｂは、ドライバー情報に関連付けられた位置関連情報であって、所定時点の時刻を示す時刻情報、所定時点の乗り物の速さを示す速さ情報と、及び所定時点の位置を示す位置情報のうち、少なくとも１つを含む位置関連情報を受信してもよい。この場合、決定部４１６は、位置関連情報にさらに基づいてリスクを決定してもよい。例えば、決定部４１６は、位置関連情報の速さから求められる加速度などを用いて運転リスクを算出してもよい。また、決定部４１６は、位置関連情報に関連付けられる道路種別（高速道路や一般道路）や交通状況（渋滞等）などを用いて運転リスクを算出してもよい。決定部４１６は、運転リスクを用いて最終的なリスクを決定してもよい。

これにより、位置関連情報に含まれる速さや位置などに基づいてリスクを決定することができ、実際の走行及びステータスに応じてリスクを決定することができるので、より適切な保険料の決定が可能になる。

また、ドライバー情報は、ドライバーの年齢、性別、及び住所の少なくとも１つを含む属性情報を含む。また、決定部４１６は、属性情報にさらに基づいてリスクを決定してもよい。例えば、決定部４１６は、住所に応じてリスクを変動させたり、年齢に応じてリスクを変動させたりすることができる。例えば、決定部４１６は、都市部に住んでいるドライバーのリスクは、田舎に住んでいるドライバーのリスクよりも高いとしたり、年齢が低いほど、リスクを小さくしたりする。

これにより、ドライバー情報を用いて、ユーザの属性に応じたリスクを決定することができ、より適切な保険料を決定することができる。

ドライバー情報は、乗り物を特定する第１特定情報を含む。この場合、決定部４１６は、第１特定情報を用いてドライバーを特定してもよい。例えば、第１特定情報は、車両を特定するＶＩＮ情報であり、このＶＩＮ情報を用いて、ドライバーが特定されてもよい。

これにより、ドライバーを、車両のＶＩＮ情報から特定することができ、一般的な保険に準拠することができる。一般的に自動車保険では、車両のＶＩＮ情報が用いられる。

また、決定部４１６は、位置関連情報に含まれる時刻情報及び速さ情報に基づいて算出されたドライバーの運転スコアを用いて、保険料を決定してもよい。例えば、決定部４１６は、時刻情報及び速さ情報を用いて加速度を算出し、この加速度から運転スコアを求めてもよい。

これにより、加速度を用いて運転スコアを求め、運転スコアを用いてドライバーの保険料が算出されることで、より適切に保険料を算出することができる。

また、運転スコアは、イベント情報にさらに基づいて算出されうる。例えば、決定部４１６は、イベント間のステータスごとに、運転スコアを算出し、ステータスごとの運転スコアに、スタータス別リスクを乗算することで、最終的な運転スコアを算出してもよい。

これにより、運転スコアについても、ステータスに応じて算出され、この運転スコアに基づく運転スコア係数を用いて保険料を算出することで、より適切な保険料を算出することができる。

また、決定部４１６は、以下の式（１）に基づいて、保険料を算出して決定してもよい。
次回の保険料＝現在の保険料×走行距離リスク係数×走行時間リスク係数×運転スコア係数
・・・式（１）
また、走行距離リスク係数、走行時間リスク係数、及び運転スコア係数については、少なくとも一つが現在の保険料に乗算されてもよい。これにより、走行実績に対してもステータス別のリスクを総合的に加味して次回の保険料を算出することができ、より適切な保険料を決定することができる。

図１５は、第１実施形態に係る処理端末２０の機能構成の一例を示す図である。図１５に示す処理端末２０は、ドライバーが利用する情報処理装置である。処理端末２０は、ドライバーＵＡがライドシェア管理アプリにログイン等することに応じて、ライドシェアサービスを実行し、そのための機能として、少なくとも第３通信部６０２、第３記憶部６０８、アプリ実行部６１０、及びセンサ部６１６を備える。

第３通信部６０２は、第１サーバ１０Ａや第２サーバ１０Ｂとネットワークとの間で通信を行う。例えば、第３受信部６０６は、第１サーバ１０Ａや第２サーバ１０Ｂから受信したデータを、アプリ実行部６１０に供給する。第３送信部６０４は、アプリ実行部６１０から供給されたデータを、第１サーバ１０Ａへ送信する。第３通信部６０２は、具体的には、少なくとも上述した図３に示す通信インターフェース２０６等から構成され得る。

第３記憶部６０８は、各種プログラムや各種データを記憶するためのものであり、具体的には、上述した図３に示す記憶部２０８等から構成され得る。ここで、第３記憶部６０８に記憶されるプログラムは、ドライバー用のライドシェア管理アプリである。また、第３記憶部６０８には、かかるライドシェアに関するデータや表示データや各種演算結果のデータなども記録される。

アプリ実行部６１０は、例えば制御部２０２等から構成され得る。アプリ実行部６１０は、ライドシェアサービスを実行する各機能を有する。アプリ実行部６１０は、このライドシェアサービスを実行する各機能として、少なくとも操作受付部６１２、表示制御部６１４を備える。

操作受付部６１２、ドライバーの操作を受け付ける。操作受付部６１２は、入力部２１６やマイク２２０を介して、ドライバーが入力した操作内容や情報を受け付ける。例えば、操作受付部５１２は、ドライバーによるライドシェア管理アプリの起動操作などの各イベントが発生する操作を受け付ける。なお、イベントによっては、ライドシェア管理アプリが自動で検出してもよい。例えば、「booking」イベントは、ＧＰＳにより所定位置に到着し、所定時間停車していることを検知した場合に、ライドシェア管理アプリは、「booking」イベントが発生したと認識する。

表示制御部６１４は、第１サーバ１０Ａからが提供されるライドシェアに関する画面や、第２サーバ１０Ｂから提供される保険に関する画面等を表示部２１４に表示するよう制御する。表示部２１４により表示されるデータは、ライドシェア管理アプリが第１サーバ１０Ａから取得したデータであってもよいし、保険料決定アプリが第２サーバ１０Ｂから取得したデータであってもよい。

なお、アプリ実行部６１０は、ドライバーがライドシェア管理アプリを起動しなくても、制御部２０２等に常駐してバックエンドで起動しており、「app on」イベント前でも、位置関連情報やドライバー情報を第１サーバ１０Ａに送信する。

センサ部６１６は、加速度センサや角速度センサを含み、車両に関する各データをセンシングする。センサ部６１６は、車載器として、車両に搭載されてもよく、その場合は、センシングされたデータを第１サーバ１０Ａに送信するようにする。

図１６は、第１実施形態に係る処理端末２０の画面例を示す図である。図１６に示す例では、処理端末２０の表示制御部６１４は、第２サーバ１０Ｂから送信された保険料情報が翌月の保険料として画面に表示制御する。この際、第２サーバ１０Ｂから走行距離リスクや、走行時間リスク、運転スコアの情報が取得された場合には、表示制御部６１４は、これらの情報も画面に表示制御する。なお、走行距離やリスク、走行時間リスク、運転スコアは、１日単位の情報であり、保険料は、月単位の情報であってもよい。

＜動作処理＞
次に、保険管理システム１の処理について説明する。図１７は、第１実施形態に係る保険管理システム１の処理に関するシーケンス図である。図１７に示す例では、ステップＳ１０２で、処理端末２０の操作受付部６１２は、ドライバーのログイン操作を受け付け、ライドシェア管理アプリが起動する。

ステップＳ１０４で、処理端末２０の第３送信部６０４は、ドライバー情報を第１サーバ１０Ａに送信する。なお、ドライバー情報は、上述したとおり、ライドシェア管理アプリがバックエンドで起動していることで、ログイン操作を受ける前から第１サーバ１０Ａに送信されてもよい。

ステップＳ１０６で、処理端末２０の第３送信部６０４は、センサ部６１６や、アプリ実行部６１０の実行によるライドシェア管理アプリが取得した情報を含む位置関連情報を第１サーバ１０Ａに送信する。なお、位置関連情報は、上述したとおり、ライドシェア管理アプリがバックエンドで起動していることで、ログイン操作を受ける前から第１サーバ１０Ａに送信されてもよい。

ステップＳ１０８で、処理端末２０の操作受付部６１２は、イベントが発生する起因となるドライバーからの操作を受け付ける。

ステップＳ１１０で、処理端末２０の第３送信部６１４は、イベント発生時に取得された情報を含むイベント関連情報を第１サーバ１０Ａに送信する。

ステップＳ１０８及びステップＳ１１０は、イベントが発生する度に実行され、ステップＳ１０６は、所定のタイミングで定期的に実行される。

ステップＳ１１２で、第１サーバ１０Ａの転送部４１４は、ドライバー情報やイベント関連情報や、位置関連情報を、所定のタイミングで定期的に第２サーバ１０Ｂに転送するよう制御する。

ステップＳ１１４で、第２サーバ１０Ｂの決定部４１６は、第１サーバ１０Ａから取得された情報を用いて、保険料を決定する。保険料の決定の仕方は様々あるが、いずれか一つが設定されていればよい。

ステップＳ１１６で、第２サーバ１０Ｂの第２送信部４０４Ｂは、保険料情報を処理端末２０に送信する。このとき、走行距離リスク係数や走行時間リスク係数や運転スコアが算出されていれば、これらの値が送信されてもよい。これにより、ドライバーは、本日の走行実績を把握したり、今の走行実績に基づく次回の保険料について把握したりすることができる。第２サーバ１０Ｂに関する処理については、図１８を用いて詳述する。

図１８は、第１実施形態に係る保険料決定処理の一例を示すフローチャートである。図１８に示す例では、ステップＳ２０２で、第２サーバ１０Ｂの第２受信部４０６Ｂは、各種情報を受信する。各種情報は、ドライバー情報やイベント関連情報を含み、必要に応じて位置関連情報などを含む。

ステップＳ２０４で、第２取得部４１２Ｂにより各種データが取得され、決定部４１６は、イベントの遷移に基づいて、ドライバーの運転状況のステータスを特定する。

ステップＳ２０６で、決定部４１６は、ステータスごとに設定されたステータス別リスクを特定する（図１１参照）。

ステップＳ２０８で、決定部４１６は、ステータスごとに、走行距離リスクを算出する（図１１参照）。

ステップＳ２１０で、決定部４１６は、ステータスごとに、走行時間リスクを算出する（図１１参照）。

ステップＳ２１２で、決定部４１６は、独自又は公知の算出式を用いて運転スコアを算出する。運転スコアは、加速度などに応じて決定されるパラメータである。なお、決定部４１６は、運転スコアもステータスごとに、運転スコアを算出し、ステータス別リスクの係数を乗算して総合の運転スコアを算出してもよい。

ステップＳ２１４で、決定部４１６は、ドライバー情報やイベント情報に基づいて、ドライバーの保険料を決定する。決定部４１６は、位置関連情報などにさらに基づいて保険料を決定してもよい。

ステップＳ２１６で、第２送信部４０４Ｂは、保険料情報を処理端末２０に送信する。また、走行実績のリスクや運転スコアも合わせて送信されてもよい。

以上の処理によれば、乗り物３０を運転するドライバーＵ又は乗り物３０に対し、商業的利用又は私的利用のステータスに応じたリスクを特定することで、商業的利用なのか、私的利用なのかをドライバーに意識させずに共通の保険料を決定することが可能になる。また、保険会社では、商業的利用又は私的利用がなされる１つの車両に対して共通して保険を適用することでき、保険を複雑化させずに、自身が管理運営するサーバの資源を有効活用することができ、管理コストの増大を軽減することができる。

［第２実施形態］
次に、第２実施形態について説明する。第２実施形態は、保険管理システムを、Uber Eatsやメッセンジャーなどの配達システムに適用する場合の例である。ドライバーは、第１実施形態と同様に、乗り物（自動車、モーターサイクルなど）を私的に又は商業的に利用する。そのため、私的利用及び商業的利用のいずれかの場合のドライバー又は乗り物に対する保険料を決定するために、上述した決定方法が用いられる。

＜第２実施形態の構成＞
第２実施形態に係るシステム構成、情報処理装置のハードウェア構成、並びに、サーバ及び端末の機能構成は、基本的に上述した第１実施形態と同様である。

第２実施形態では、イベントの内容が配達システム用のイベントに代わる。例えば、イベントには、アプリ起動、配達物及び配達先決定、配達物取得、配達完了、アプリ終了などを含む。この場合のイベント間のステータスは、例えば、以下が考えられる。
「アプリ起動」イベント以前：private（私的利用）ステータス
「アプリ起動」イベントから「配達先及び配達物決定」イベントまで：waiting（待ち）ステータス
「配達先及び配達物決定」イベントから「配達物取得」イベントまで：pick up(ピックアップ)ステータス
「配達物取得」イベントから「配達完了」イベントまで：delivering（配達中）ステータス
「配達完了」イベントから「配達先及び配達物決定」又は「アプリ終了」イベントまで：waiting（待ち）ステータス
「アプリ終了」イベント以降：private（私的利用）ステータス

決定部４１６は、上記ステータスごとのリスクを特定し、ドライバー又は乗り物についての保険料を決定する。

＜第２実施形態の動作処理＞
第２実施形態に係る処理は、基本的に図１７及び図１８に示す処理と同様である。なお、第２実施形態では、イベントの内容が異なるが、イベント遷移に基づくステータスは同様であるため、第１実施形態の保険料決定方法を適用することが可能である。

第２実施形態によれば、私的利用及び商業的利用のいずれかの利用に切り替え可能な乗り物を利用する配達システムに対しても、第１実施形態と同様の効果を奏することができる。

［第３実施形態］
次に、第３実施形態について説明する。第３実施形態は、保険管理システムを、タクシーなどの配車システムに適用する場合の例である。第３実施形態では、図１に示す例において、第１情報処理装置（第１サーバ）１０Ａと第２情報処理装置（第２サーバ）１０Ｂとの間に、タクシー等の運搬乗り物の配車を管理する第３情報処理装置（第３サーバ）１０Ｃ（図示しない）が保険管理システム１に追加される。第３サーバ１０Ｃは、ネットワークにデータ通信可能に接続されている。

この場合、第３サーバ１０Ｃを管理する配車管理会社に配車の依頼があると、依頼者に近い位置にいる乗り物（例えばタクシー）が決定される。乗り物は、自身を所有する会社（乗り物管理会社）が管理する第１サーバ１０Ａに各種データを送信する。各種データ（位置関連情報等）は、デジタルレコーダー（デジレコ）、デジタルタコグラフ（デジタコ）により取得される。

イベントは、ドライバーがデジレコやデジタコを操作することで認識されたイベントであってもよいし、配車管理会社や乗り物管理会社のオペレータ等の操作により認識されたイベントであってもよい。これらのイベントの情報が、第２サーバ１０Ｂに送信される。イベントの情報は、ドライバー情報と対応付けられて送信されるとよい。

これにより、第２サーバ１０Ｂは、ドライバー情報、イベント情報、必要に応じて一関連情報を取得することで、ドライバー又は乗り物３０の保険料を決定する。なお、乗り物３０がタクシー等である場合、その所有権は、ドライバーではなく乗り物管理会社にあるため、乗り物３０の保険料が決定される。イベントの内容は、基本的に第１実施形態と同様であるため、第３実施形態における保険料決定方法は、第１実施形態と同様の方法を用いることができる。

＜第３実施形態の構成＞
第３実施形態に係るシステム構成、情報処理装置のハードウェア構成、並びに、サーバ及び端末の機能構成は、基本的に上述した第１実施形態と同様である。

第３実施形態では、イベント情報を送信する主体について、第３サーバ１０Ｃが追加されるが、第３サーバ１０Ｃの処理は基本的には第１実施形態と同様である。例えば、決定部４１６は、配車システムに利用される乗り物３０のステータスごとのリスクを特定し、ドライバー又は乗り物についての保険料を決定する。

＜第３実施形態の動作処理＞
第３実施形態に係る処理は、基本的に図１７及び図１８に示す処理と同様である。なお、第３実施形態では、上述したとおり、イベント情報を送信する主体について、第３サーバ１０Ｃが追加されるが、イベント遷移に基づくステータスは同様であるため、第１実施形態の保険料決定方法を適用することが可能である。

第３実施形態によれば、私的利用及び商業的利用のいずれかの利用に切り替え可能な乗り物を利用する配車システムに対しても、第１実施形態と同様の効果を奏することができる。

［変形例］
上述した私的利用及び商業的利用のいずれかの利用に切り替え可能な乗り物を利用する各実施形態に対し、保険料について例えば年払いであっても、月単位で保険料を決定して見直してもよい。この場合、次の期間の保険料が決定したとき、支払われた月換算の保険料よりも低額になっていれば、第２サーバ１０Ｂは、月換算の保険料と決定された保険料との差額をドライバーに返金してもよい。なお、保険料の見直しの単位は、月単位に限らず、数日単位や数週間単位や、数か月単位でもよい。

また、イベントについて、ユーザ操作に応じて各イベントが発生する以外にも、アプリ実行部６１０は、自動でイベントの発生を検知してもよい。例えば、アプリ実行部６１０は、ＧＰＳ等により取得された位置情報が乗車位置や目的位置に到着したことを示し、一定時間そこに停車していた場合にイベントの発生を検知する。

また、一人のドライバーが複数台の乗り物を所有、もしくは使用する場合、あるいは、一台の乗り物を複数のドライバーが使用する場合（レンタルする場合）があるため、ドライバー情報に、ＶＩＮ情報などの乗り物を特定する情報を含めてもよい。このとき、決定部４１６は、ドライバーを特定する情報と、乗り物を特定する情報との組み合わせに応じて、ベースとなるリスク（以下、「ベースリスク」ともいう。）を決定してもよい。また、決定部４１６は、イベント情報に基づいて遷移するステータスによって特定されるステータス別リスクを用いて、ベースリスクを調整してもよい。

また、上述した各処理は、コンピュータにより実行されるプログラムとして実装されてもよい。このプログラムは、コンピュータにインストールされたり、コンピュータに読み取り可能な記憶媒体（例えば非一時的な記憶媒体）に記憶されたりし、コンピュータの制御部（例えばプロセッサなど）により実行されることで、上記処理が実現されてもよい。

＜変形例１＞
変形例１では、第１実施形態及び第３実施形態に係るドライバーが、複数の乗客を乗せる場合に、乗客数に応じたステータス別リスクに基づく保険料の適用を受けることができるようにするための例である。例えば、第１実施形態及び第３実施形態で上述したステータスについて、ライドシェア管理アプリが、複数の乗客を乗せるCar Poolingを利用可能な場合、「on board（搭乗中）」のステータスを乗客の人数に応じて分けてもよい。例えば、ある乗客が搭乗し、ステータスが「搭乗中」であるときに「boarding」イベントが発生した場合、二人の乗客が搭乗していることになる。この場合、乗客の人数が増えるほど、ステータス別リスクが大きくなるように設定されるとよい。

決定部４１６は、最初に「on board（搭乗中）」のステータスに遷移してから、「boarding」イベント（乗車を示すイベント）の発生回数、及び「dropping」イベント（降車を示すイベント）の発生回数、さらに必要に応じてこれらのイベントの順番に基づいて、現在何名の乗客が搭乗しているかを判定する。次に、決定部４１６は、判定した乗客数に応じてステータス別リスクを決定してもよい。例えば、「on board（搭乗中）」のステータスについて、決定部４１６は、「on board（搭乗中）」のステータスに遷移すると、以下のようにして乗客人数を把握する。
Ｐ（乗客数）＝「boarding」イベントの発生回数＋１−「dropping」イベントの発生回数
ただし、Ｐが一旦０になると、「waiting（待ち）」ステータスになり、決定部４１６は、次に、「on board（搭乗中）」のステータスになるまで、上記式の使用を停止してもよい。

決定部４１６は、上記式により特定された乗客数に応じてリスクを決定する。なお、リスクは、乗客数ごとに予め設定されているとよい。これにより、決定部４１６は、乗客数に応じたステータス別リスクを用いて、複数の乗客を乗せる可能性があるドライバー又は車両に適切な保険料を決定することができる。

＜変形例２＞
変形例２では、ドライバーが複数のライドシェア管理アプリに登録している場合に、第２サーバ１０Ｂは、各ライドシェアサービスを管理する各第１サーバ１０Ａから、各種データ（例えば、ドライバー関連情報や位置関連情報）を取得して保険料を決定する。

例えば、ドライバーが、Ｕｂｅｒ又はＬｙｆｔ等の複数のライドシェアサービスに登録し、複数のライドシェア管理アプリを自身の処理端末２０にインストールした場合、第２サーバ１０Ｂは、どのライドシュアサービスを提供する会社からの情報であるのかを特定する。例えば、第２サーバ１０Ｂは、各種データの送信元を、第１サーバ１０Ａの識別情報で特定したり、各種データに付与される会社ＩＤなどで特定したりする。次に、第２サーバ１０Ｂは、特定したライドシェアサービスに応じてステータスを管理し、保険料を決定する。

このとき、決定部４１６は、ステータスが遷移する方のライドシェアサービスを優先し、例えば、商業的利用に関するイベント情報を私的利用に関するイベント情報よりも優先する。決定部４１６は、優先して利用する商業的利用時のイベント情報に基づいて遷移するステータスに応じて保険料を決定する。例えば、第２サーバ１０Ｂ側でライドシェアサービスＡとライドシェアサービスＢとが特定でき、ライドシェアサービスＢにおいてステータスが遷移している場合、決定部４１６は、ライドシェアサービスＢをドライバーが利用している（商業的利用をしている）と判断し、このステータスの遷移に基づいて、このドライバー又は車両の保険料を決定してもよい。これにより、第２サーバ１０Ｂ側では、ドライバーの実際のステータスを特定することができ、適切な保険料を決定することが可能になる。

１…保険管理システム、１０…情報処理装置（サーバ）、２０…情報処理装置（処理端末）、３０…乗り物、１０２…制御部、１０４…通信インターフェース、１０６…記憶部、２０２…制御部、２０６…通信インターフェース、２０８…記憶部、２１４…表示部、２１６…入力部、２２０…マイク、２２２…スピーカ、２２４…センサ、４０２Ａ…第１通信部、４０８Ａ…第１記憶部、４１０Ａ…第１アプリ制御部、４１２Ａ…第１取得部、４１４Ａ…転送部、４０２Ｂ…第２通信部、４０８Ｂ…第２記憶部、４１０Ｂ…第２アプリ制御部、４１２Ｂ…第２取得部、４１６…決定部、６０２…第３通信部、６０８…第３記憶部、６１０…アプリ実行部、６１６…センサ部

Claims (12)

1. 乗り物の商業的利用及び私的利用のいずれかの利用時における、ドライバーの運転状況を示すイベントを含むイベント情報と、前記ドライバーに関するドライバー情報とを受信する受信部と、
   前記イベント情報に含まれる、前記ドライバーが使用する処理端末から送信される前記商業的利用を管理するアプリケーションの起動を示すイベント及び終了を示すイベントに基づいて、前記商業的利用か前記私的利用かを決定し、前記商業的利用に基づくリスク及び前記私的利用に基づくリスクを用いて、前記ドライバー情報により特定される前記ドライバー又は前記乗り物の保険料を決定する決定部と、
   を備える情報処理装置。
2. 決定された前記保険料を示す保険料情報を、前記処理端末に送信する送信部をさらに備え、
   前記商業的利用は、複数の異なるイベントを含み、
   前記決定部は、
   各イベント間のステータスに対し、異なるリスクを適用可能である、請求項１に記載の情報処理装置。
3. 前記受信部は、
   前記ドライバー情報に関連付けられた位置関連情報であって、所定時点の時刻を示す時刻情報、前記所定時点の前記乗り物の速さを示す速さ情報と、及び前記所定時点の位置を示す位置情報のうち、少なくとも１つを含む前記位置関連情報を受信し、
   前記決定部は、
   前記位置関連情報にさらに基づいてリスクを決定する、請求項１又は２に記載の情報処理装置。
4. 前記ドライバー情報は、前記ドライバーの年齢、性別、及び住所の少なくとも１つを含む属性情報を含み、
   前記決定部は、
   前記属性情報にさらに基づいてリスクを決定する、請求項１乃至３いずれかに記載の情報処理装置。
5. 前記乗り物は、前記ドライバーが所有する又は使用する乗り物、又はライドシェアに使用される乗り物であり、
   前記保険料は、前記ドライバーが支払う保険料である、請求項１乃至４いずれか一項に記載の情報処理装置。
6. 前記決定部は、
   前記位置関連情報に含まれる前記時刻情報及び前記速さ情報に基づいて算出された前記ドライバーの運転スコアを用いて、前記保険料を決定する、請求項３に記載の情報処理装置。
7. 前記運転スコアは、前記イベント情報にさらに基づいて算出される、請求項６に記載の情報処理装置。
8. 前記決定部は、
   前記イベント情報に含まれる、乗車を示すイベントの発生回数と、降車を示すイベントの発生回数とに応じて乗客数を特定し、当該乗客数に基づいてリスクを決定する、請求項１乃至７いずれか一項に記載の情報処理装置。
9. 前記決定部は、
   所定のドライバーに対して、異なる送信元からそれぞれのイベント情報が受信される場合、前記商業的利用に関するイベント情報を優先して用いて、前記保険料を決定する、請求項１乃至８いずれか一項に記載の情報処理装置。
10. 情報処理装置が、
    乗り物の商業的利用及び私的利用のいずれかの利用時における、ドライバーの運転状況を示すイベントを含むイベント情報と、前記ドライバーに関するドライバー情報とを受信し、
    前記イベント情報に含まれる、前記ドライバーが使用する処理端末から送信される前記商業的利用を管理するアプリケーションの起動を示すイベント及び終了を示すイベントに基づいて、前記商業的利用か前記私的利用かを決定し、前記商業的利用に基づくリスク及び前記私的利用に基づくリスクを用いて、前記ドライバー情報により特定される前記ドライバー又は前記乗り物の保険料を決定する、処理を実行する情報処理方法。
11. 情報処理装置に、
    乗り物の商業的利用及び私的利用のいずれかの利用時における、ドライバーの運転状況を示すイベントを含むイベント情報と、前記ドライバーに関するドライバー情報とを受信し、
    前記イベント情報に含まれる、前記ドライバーが使用する処理端末から送信される前記商業的利用を管理するアプリケーションの起動を示すイベント及び終了を示すイベントに基づいて、前記商業的利用か前記私的利用かを決定し、前記商業的利用に基づくリスク及び前記私的利用に基づくリスクを用いて、前記ドライバー情報により特定される前記ドライバー又は前記乗り物の保険料を決定する、処理を実行させるプログラム。
12. 情報処理装置に、
    乗り物の商業的利用及び私的利用のいずれかの利用時における、ドライバーの運転状況を示すイベントを含むイベント情報と、前記ドライバーに関するドライバー情報とを取得し、
    取得された前記イベント情報と前記ドライバー情報とを、前記商業的利用を管理する第１サーバに送信し、
    前記第１サーバから送信された前記イベント情報に含まれる、前記商業的利用を管理するアプリケーションの起動を示すイベント及び終了を示すイベントに基づいて、前記商業的利用か前記私的利用かを決定し、前記商業的利用に基づくリスク及び前記私的利用に基づくリスクを用いて、前記ドライバー情報により特定される前記ドライバー又は前記乗り物の保険料を決定する第２サーバから、前記保険料を示す保険料情報を受信し、
    受信された前記保険料情報を画面に表示制御する、処理を実行させるプログラム。

Images