JP6186467B1 - 端末装置、プログラム、および保険条件決定装置 - Google Patents

Abstract

【課題】車両の運転中にアプリケーションを操作する必要をなくすことにより安全性を高めること。【解決手段】車両に乗車した利用者に対するナビゲーション機能を有する第１アプリケーションを実行する第１実行部と、メッセージの送信機能および受信機能を有する第２アプリケーションを実行する第２実行部と、を備え、前記第２実行部は、前記車両が運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記第１アプリケーションと連携して、前記メッセージに対する返信を自動的に行う端末装置。【選択図】図１２

Description

本発明は、端末装置、プログラム、および保険条件決定装置に関する。

従来、運転手が車両を運転しながら端末を操作することにより安全性が損なわれるのを回避するため、車両の運転に関連するアプリケーションの実行を許可するとともに、他のアプリケーションの実行を禁止する技術が開示されている（特許文献１参照）。

特開２０１４−２３３９９８号公報

しかしながら、特許文献１に開示された技術では、禁止されたアプリケーションを使用できないため不便である。一方、車両の運転中におけるアプリケーションの使用を許可すると、例えば、メッセージの送信機能および受信機能を有するアプリケーションにメッセージが届いた場合、運転手が車両を運転しながらメッセージを返信することは安全上好ましくない。

本発明は、このような事情を考慮してなされたものであり、車両の運転中にアプリケーションを操作する必要をなくすことにより安全性を高める端末装置、プログラム、および保険条件決定装置を提供することを目的の一つとする。

本発明の一態様は、車両に乗車した利用者に対するナビゲーション機能を有する第１アプリケーションを実行する第１実行部と、メッセージの送信機能および受信機能を有する第２アプリケーションを実行する第２実行部と、を備え、前記第２実行部は、前記車両が運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記第１アプリケーションと連携して、前記メッセージに対する返信を自動的に行う端末装置である。

本発明の一態様によれば、車両の運転中にアプリケーションを操作する必要をなくすことにより安全性を高めることができる。

第１実施形態に係る保険条件決定装置を含むシステムの構成図である。 地図情報１２０の内容の一例を示す図である。 第１実施形態に係る保険条件決定装置を含むシステムにおいて実行される処理の流れを示すシーケンス図である。 車両Ｖｈが運転されている期間の一例を示す図である。 安全な位置に停車している車両Ｖｈ１と、安全でない位置に停車している車両Ｖｈ２の一例を示す図である。 第１実施形態における、保険会社サーバ３００により実行される処理の流れの一例を示すフローチャートである。 第２実施形態に係る保険条件決定装置を含むシステムの構成図である。 第２実施形態における、端末装置２００により実行される処理の流れの一例を示すフローチャートである。 第３実施形態に係る保険条件決定装置を含むシステムの構成図である。 第３実施形態における、保険会社サーバ３００により実行される処理の流れの一例を示すフローチャートである。 第４実施形態に係るシステムの構成図である。 第４実施形態に係る端末装置２００のブロック図である。 第４実施形態に係るシステムにおいて実行される処理の流れを示すシーケンス図である。 第４実施形態におけるＳ６０の返信メッセージの生成処理を具体的に示す図である。 第４実施形態に係る通信アプリの表示画面の一例を示す図である。 第４実施形態における、端末装置２００により実行される処理の流れの一例を示すフローチャートである。 第５実施形態におけるＳ６０の返信メッセージの生成処理を具体的に示す図である。 第６実施形態におけるＳ６０の返信メッセージの生成処理を具体的に示す図である。 第７実施形態におけるＳ６０の返信メッセージの生成処理を具体的に示す図である。 ナビゲーションサーバ１００、端末装置２００、保険会社サーバ３００、通信アプリサーバ４００、および端末装置５００のハードウェア構成の一例を示す図である。

以下、図面を参照し、本発明の端末装置、プログラム、および保険条件決定装置の実施形態について説明する。

＜１．第１実施形態＞
＜１−１．構成＞
図１は、第１実施形態に係る保険条件決定装置を含むシステムの構成図である。実施形態の保険条件決定装置は、一以上のプロセッサにより実現される。実施形態の保険条件決定装置は、保険会社サーバ３００を少なくとも含み、ナビゲーションサーバ１００を含んでもよい。また、保険会社サーバ３００は、ナビゲーションサーバ１００に統合されてもよく、ナビゲーションサーバ１００および保険会社サーバ３００が統合されて保険条件決定装置を構成してもよい。図１においては、１台の車両Ｖｈおよび端末装置２００のみを示しているが、複数の端末装置２００がネットワークＮＷに接続されてよい。

端末装置２００、ナビゲーションサーバ１００、および保険会社サーバ３００は、ネットワークＮＷを介して通信する。ネットワークＮＷは、例えば、ＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）、インターネット、プロバイダ装置、無線基地局、専用回線などのうち一部または全部を含む。

端末装置２００は、車両Ｖｈに乗車する利用者によって使用される。端末装置２００は、スマートフォンなどの携帯電話やタブレット端末などである。端末装置２００は、ナビゲーションサーバ１００と連携するナビアプリが起動されることで、ナビゲーションシステムの一部を構成するナビゲーション装置として機能する。なお、車両Ｖｈには、ナビゲーション装置（据え置き型の車載装置）が搭載されてもよい。また、据え置き型の車載装置が、端末装置２００として扱われてもよい。

端末装置２００は、ＧＰＳ（Global Positioning System）受信機などの位置測位装置、ネットワークＮＷに接続するための通信装置、三軸式の加速度センサ、タッチパネルなどの入出力装置、スピーカ、ＣＰＵ（Central Processing Unit）などのプロセッサを有する。位置測位装置は、衛星から受信した電波に基づく測位を行って、端末装置２００の位置（すなわち車両Ｖｈの位置）を特定する。また、端末装置２００は、通信装置が接続された無線基地局の位置から端末装置２００の位置を推定してもよい。

端末装置２００は、位置測位装置などによって特定された端末装置２００の位置を定期的に（例えば数［ｓｅｃ］おきに）ナビゲーションサーバ１００に送信する。また、端末装置２００は、利用者により設定された目的地をナビゲーションサーバ１００に送信して経路を取得する。

ナビゲーションサーバ１００は、経路探索部１１０を備える。経路探索部１１０は、例えば、ナビゲーションサーバ１００のプロセッサがプログラムを実行することで実現されてもよいし、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードウェア（コントローラ）によって実現されてもよい。経路探索部１１０は、端末装置２００からのリクエストに応じて経路探索を行い、経路情報を端末装置２００に送信する。また、ナビゲーションサーバ１００の記憶部には、地図情報１２０が記憶される。地図情報１２０は、例えば、リンクの集合で道路を表現した情報である。

図２は、地図情報１２０の内容の一例を示す図である。地図情報１２０は、リンクの両端座標、接続リンク、車線数などの情報が、リンクの識別情報であるリンクＩＤに対応付けられた情報である。

ナビゲーションサーバ１００は、地図情報１２０から、端末装置２００から受信した端末装置２００の位置を中心とした領域の地図情報（部分地図情報）を抽出し、抽出した地図情報を端末装置２００に送信する。

端末装置２００は、ナビゲーションサーバ１００から受信した情報に対してマップマッチング処理を行う。マップマッチング処理とは、地図情報（部分地図情報である場合も含む）に含まれる要素（例えばリンク）のうち、どの要素に沿って端末２００が移動しているか（すなわち車両Ｖｈがどのリンクを走行しているか）を判定する処理であり、地図情報に含まれるリンク以外の要素（例えばポリゴンなど）をマッチング対象に含めてもよいし、地図情報がマッチング対象以外の要素を含んでもよい。典型的に、リンクを対象とする場合、端末装置２００の位置（車両Ｖｈの位置）が、いずれかのリンクに対応付けられる。マップマッチング処理は、例えば、端末装置２００の位置に最も近い位置にあるリンクを選択することを基本として、種々の要素を加味して行われる。端末装置２００は、ナビゲーションサーバ１００から受信した部分地図情報と、マップマッチング処理の結果とに基づいて、ナビゲーション画面を生成し、音声案内と共に表示する。

保険会社サーバ３００は、例えば保険会社によって運営される。保険会社サーバ３００は、保険条件決定部３１０および判定部３２０を備える。保険条件決定部３１０および判定部３２０は、例えば、保険会社サーバ３００のプロセッサがプログラムを実行することで実現されてもよいし、ＬＳＩやＡＳＩＣ、ＦＰＧＡなどのハードウェアによって実現されてもよい。

保険条件決定部３１０は、車両Ｖｈに対し、或いは車両Ｖｈを運転する利用者ごとに保険条件を決定する。本実施形態において保険会社サーバ３００を運営する保険会社の提供する保険は、走行した経路の長さ（走行距離）に応じて保険条件が決定される保険であり、走行距離１００［ｋｍ］ごとに１００円といったように保険料が決定される。そして、この保険の保険条件は、（Ａ）車両Ｖｈが走行した経路に応じて、事後的に保険条件が決定される、或いは（Ｂ）一定期間において車両Ｖｈが走行した経路に応じて、次の期間における保険条件が決定される。保険条件には、保険料の他、免責額、保険金の支払いに伴う保険料の変動量（等級の変動量）、その他の種々の条件が含まれる。走行した経路の情報は、ナビアプリとナビゲーションサーバ１００を介して取得されてもよいし、端末装置２００において保険会社の提供するアプリが実行されることで、端末装置２００の位置測位装置が特定した位置が保険会社サーバ３００に送信されることで取得されてもよい。また、走行した経路の情報は、車載装置である端末装置２００から取得されてもよい。

判定部３２０は、詳細は後述するが、車両Ｖｈに乗車した利用者が保持する端末装置２００において所定のアプリ（アプリケーションプログラム）が実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する。また、保険条件決定部３１０は、詳細は後述するが、判定部３２０の判定結果に基づいて、車両Ｖｈまたは利用者に対する保険条件を決定する。

ナビゲーションサーバ１００および保険会社サーバ３００（以下、「各サーバ」）の記憶部は、例えば、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリなどにより実現される。また、記憶部は、各サーバが保有する記憶装置に限らず、ＮＡＳ（Network Attached Storage）などの外部記憶装置により実現されてもよい。

＜１−２．処理の例＞
図３は、第１実施形態に係る保険条件決定装置を含むシステムにおいて実行される処理の流れを示すシーケンス図である。

＜１−３．ナビゲーションの処理＞
まず、端末装置２００においてナビアプリが起動し、利用者による目的地の設定を受け付ける（Ｓ１）。端末装置２００は、位置測位装置によって特定された端末装置２００の位置（以下、「自装置の位置」）および目的地をナビゲーションサーバ１００に送信する（Ｓ２）。ナビゲーションサーバ１００では、位置および目的地と、地図情報１２０とを用いて経路探索を行う（Ｓ３）。ナビゲーションサーバ１００は、探索結果としての経路と、端末装置２００の位置を中心とした領域の部分地図情報とを端末装置２００に送信する（Ｓ４）。

端末装置２００は、位置測位装置が特定した位置に基づき、車両Ｖｈの運転が開始されたことを判断する。端末装置２００は、車両Ｖｈの運転が開始されたと判断した場合、運転開始通知を保険会社サーバ３００に送信する（Ｓ５）。なお、端末装置２００は、利用者からの入力に基づいて車両Ｖｈの運転が開始されたことを判断してもよい。

端末装置２００は、自装置の位置と部分地図情報に含まれるリンクとに対してマップマッチング処理を行い、マップマッチング処理の結果（以下、「マップマッチング結果」）と、部分地図情報とに基づいてナビゲーション画面を生成し、音声情報と共に表示する（Ｓ６）。

端末装置２００は、定期的に、自装置の位置およびマップマッチング結果をナビゲーションサーバ１００に送信する（Ｓ７）。ナビゲーションサーバ１００は、自装置の位置およびマップマッチング結果を、保険会社サーバ３００に送信する（Ｓ８）。保険会社サーバ３００は、受信した自装置の位置およびマップマッチング結果を記憶部に記憶させる（Ｓ９）。前述したように、ナビゲーションサーバ１００と保険会社サーバ３００は統合されて「ナビゲーション／保険会社サーバ」として機能してよく、この場合、ナビゲーション／保険会社サーバが、端末装置２００から受信したマップマッチング結果を記憶部に記憶させる。ナビゲーションサーバ１００は、位置に対応する部分地図情報を端末装置２００に送信する（Ｓ１０）。

＜１−４．アプリ操作の検出と判定＞
端末装置２００は、利用者によるアプリ操作を検出すると、アプリに対する操作内容を示すアプリ操作情報をナビゲーションサーバ１００に送信する（Ｓ１１）。また、ナビゲーションサーバ１００は、端末装置２００から受信したアプリ操作情報を、保険会社サーバ３００に送信する（Ｓ１２）。

保険会社サーバ３００は、ナビゲーションサーバ１００からアプリ操作情報を受信すると、アプリに対する操作が不適切であるか否かを判定する判定処理を実行する（Ｓ１３）。例えば、保険会社サーバ３００の判定部３２０は、車両が運転されているか否かに基づいて、アプリに対する操作が不適切であるか否かを判定する。車両Ｖｈが運転されていない場合は、利用者がアプリを操作しても安全性は損なわれないため、判定部３２０はアプリに対する操作が不適切でない（適切である）と判定する。

図４は、車両Ｖｈが運転されている期間の一例を示す図である。図４に示されるように、判定部３２０は、車両Ｖｈが出発地点を出発してから目的地に到着するまでの間、車両Ｖｈが運転されていると判定する。具体的に、判定部３２０は、Ｓ５において運転開始通知を受信してから、Ｓ１５において目的地到着通知を受信するまでの間、車両Ｖｈが運転されていると判定する。なお、車両Ｖｈの運転中の期間において、車両Ｖｈは走行と停車を繰り返すが、この停車中の間も、「運転中の期間」とみなされる。なお、停車中の期間が基準時間を超えたような場合には、「運転中の期間」でないと判定してもよい。

また、判定部３２０は、判定部３２０は、車両Ｖｈの位置と、地図情報における道路のリンクデータとのマッチングの成立状態に基づいて、アプリに対する操作が不適切であるか否かを判定する。マッチングが成立していない場合は、車両Ｖｈは道路上に存在しないと推定されるため、判定部３２０はアプリに対する操作は不適切でない（適切である）と判定する。

なお、判定部３２０は、マッチングの信頼度に基づいて、アプリに対する操作が不適切であるか否かを判定してもよい。例えば、判定部３２０は、車両Ｖｈの位置と、地図情報に含まれるリンクデータにおける車両Ｖｈに最も近い道路の位置との距離に基づき、信頼度を算出してもよい。この場合、車両Ｖｈの位置と、車両Ｖｈに最も近い道路の位置との距離が短いほど、マッチングの信頼度は高くなる。なお、端末装置２００が信頼度を算出し、算出した信頼度をマップマッチング結果に付加して送信してもよい。この場合、判定部３２０は、端末装置２００から受信したマップマッチング結果に付加された信頼度に基づいて、アプリに対する操作が不適切であるか否かを判定してもよい。また、ナビゲーションサーバ１００が信頼度を算出し、保険会社サーバ３００の判定部３２０がナビゲーションサーバ１００から信頼度を受信するようにしてもよい。

なお、判定部３２０は、車両Ｖｈの位置と、地図情報に含まれるリンクデータにおける車両Ｖｈに最も近い道路の位置との距離が所定距離を超える場合、たとえマッチングが成立していても、判定部３２０はマッチングが成立していないと判定してもよい。

また、判定部３２０は、車両Ｖｈが安全な位置に停車している場合に、アプリに対する操作は不適切でない（適切である）と判定する。図５は、安全な位置に停車している車両Ｖｈ１と、安全でない位置に停車している車両Ｖｈ２の一例を示す図である。図５に示されるように、車両Ｖｈ１は路面店Ｓの駐車場Ｐに停車しているため、判定部３２０は、車両Ｖｈ１は安全な位置に停車していると判定する。一方、車両Ｖｈ２は交差点で右折するために停車しているため、判定部３２０は、車両Ｖｈ２は安全な位置に停車していないと判定する。

例えば、判定部３２０は、各車両から収集されたプローブ情報に基づいて、車両Ｖｈが安全な位置に停車しているか否かを判定してよい。プローブ情報には、各車両の速度情報が含まれる。ナビゲーションサーバ１００は、各車両の端末装置からプローブ情報を収集し、保険会社サーバ３００の判定部３２０は、ナビゲーションサーバ１００にプローブ情報を要求する。例えば、判定部３２０は、ナビゲーションサーバ１００から受信したプローブ情報に基づき、車両Ｖｈの近くに存在する複数の車両の速度の平均値が所定値未満である場合、車両Ｖｈは安全な位置に停車していると判定する。判定部３２０は、判定結果を記憶部に格納する。記憶部は、判定結果を履歴データとして蓄積する。

このようにして、Ｓ６〜Ｓ１３の処理が繰り返し実行される。端末装置２００は、位置測位装置が特定した位置に基づき、車両Ｖｈが目的地に到着したか否かを判断する。端末装置２００は、車両Ｖｈが目的地に到着したと判断した場合、目的地到着通知をナビゲーションサーバ１００に送信する（Ｓ１４）。ナビゲーションサーバ１００は、端末装置２００から受信した目的地到着通知を、保険会社サーバ３００に送信する（Ｓ１５）。なお、端末装置２００は、利用者からの入力に基づいて車両Ｖｈが目的地に到着したことを判断してもよい。

＜１−５．保険条件の決定＞
その後、保険会社サーバ３００は、Ｓ１３の判定処理における判定結果に基づいて、車両Ｖｈまたは利用者に対する保険条件を決定する（Ｓ１６）。アプリに対する操作が不適切であると判断された場合、事故が発生する可能性が高まると考えられる。このため、保険会社サーバ３００の保険条件決定部３１０は、判定部３２０によって判定された不適切な操作の割合が高いほど、保険料が高くなるように保険条件を決定する。例えば、保険条件決定部３１０は、１回の運転ごとに、不適切な操作の割合に応じて保険条件を変更する。

＜１−６．保険会社サーバによる処理＞
図６は、第１実施形態における、保険会社サーバ３００により実行される処理の流れの一例を示すフローチャートである。保険会社サーバ３００は、運転開始通知を端末装置２００から受信すると、図６に示されるフローチャートの処理を実行する。

まず、保険会社サーバ３００の判定部３２０は、端末装置２００からアプリ操作情報を受信したか否かを判定する（Ｓ２０）。判定部３２０は、端末装置２００からアプリ操作情報を受信していないと判定した場合、後述するＳ２６の処理に進む。一方、判定部３２０は、端末装置２００からアプリ操作情報を受信したと判定した場合、利用者が車両Ｖｈを運転しているか否かを判定する（Ｓ２１）。

判定部３２０は、利用者が車両Ｖｈを運転していないと判定した場合、後述するＳ２５の処理に進む。一方、判定部３２０は、利用者が車両Ｖｈを運転していると判定した場合、車両Ｖｈの位置と、地図情報における道路のリンクデータとのマッチングが成立しているか否かを判定する（Ｓ２２）。

判定部３２０は、マッチングが成立していないと判定した場合、後述するＳ２５の処理に進む。一方、判定部３２０は、マッチングが成立していると判定した場合、車両Ｖｈが安全な位置に停車しているか否かを判定する（Ｓ２３）。

判定部３２０は、車両Ｖｈが安全な位置に停車していると判定した場合、後述するＳ２５の処理に進む。一方、判定部３２０は、車両Ｖｈが安全な位置に停車していないと判定した場合、アプリに対する操作は不適切な操作であると判定し、判定結果を記憶部に記憶する（Ｓ２４）。

一方、判定部３２０は、Ｓ２１において利用者が車両Ｖｈを運転していないと判定した場合、Ｓ２２においてマッチングが成立していないと判定した場合、またはＳ２３において車両Ｖｈが安全な位置に停車していると判定した場合、アプリに対する操作は適切な操作であると判定し、判定結果を記憶部に記憶する（Ｓ２５）。

その後、判定部３２０は、目的地到着通知を受信したか否かを判定する（Ｓ２６）。判定部３２０は、目的地到着通知を受信していないと判定した場合、前述のＳ２０の処理に戻る。一方、判定部３２０が目的地到着通知を受信したと判定した場合、保険条件決定部３１０は、記憶部に記憶された判定結果の履歴に基づき、保険条件を決定し（Ｓ２７）、本フローチャートによる処理を終了する。

＜１−７．効果＞
以上説明したように、第１実施形態の保険条件決定装置は、車両Ｖｈに乗車した利用者が保持する端末装置２００において所定のアプリが実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する判定部３２０と、判定部３２０の判定結果に基づいて、車両Ｖｈまたは利用者に対する保険条件を決定する保険条件決定部３１０とを有する。これによって、第１実施形態の保険条件決定装置は、車両または利用者に対する保険条件を適切に決定することができる。

＜２．第２実施形態＞
第１実施形態においては、保険会社サーバ３００が、アプリに対する操作が不適切であるか否かを判定し、車両Ｖｈまたは利用者に対する保険条件を決定することとした。これに対し、第２実施形態においては、端末装置２００が、アプリに対する操作が不適切であるか否かを判定し、操作が不適切である場合にアプリに対する操作を抑制する。以下、第２実施形態について説明する。

図７は、第２実施形態に係る保険条件決定装置を含むシステムの構成図である。図７において、図１の各部に対応する部分には同一の符号を付し、説明を省略する。第２実施形態において、端末装置２００は、判定部２１０および抑制部２２０を有する。

判定部２１０は、端末装置２００が車両Ｖｈに乗車した利用者によって保持されている状態で所定のアプリ（アプリケーションプログラム）が実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する。所定のアプリに対する操作が不適切であるか否かの判定処理は、第１実施形態と同様であるので説明を省略する。

抑制部２２０は、判定部２１０によりアプリに対する操作が不適切であると判定された場合に、アプリに対する操作を抑制する。これによって、利用者がアプリを操作することによって安全性が損なわれるのを予め防止することができる。なお、抑制部２２０は、アプリに対する操作を完全に禁止してもよいし、一部のアプリに対する操作のみを禁止するようにしてもよい。

図８は、第２実施形態における、端末装置２００により実行される処理の流れの一例を示すフローチャートである。端末装置２００は、位置測位装置が特定した位置（車両Ｖｈの位置）に基づき、車両Ｖｈの運転が開始されたことを判断する。端末装置２００は、車両Ｖｈの運転が開始されると、図８に示されるフローチャートの処理を実行する。端末装置２００は、利用者からの入力に基づいて車両Ｖｈの運転が開始されたことを判断してもよい。

まず、端末装置２００の判定部２１０は、アプリが操作されたか否かを判定する（Ｓ３０）。判定部２１０は、アプリが操作されていないと判定した場合、後述するＳ３５の処理に進む。一方、判定部２１０は、アプリが操作されたと判定した場合、利用者が車両Ｖｈを運転しているか否かを判定する（Ｓ３１）。利用者が車両Ｖｈを運転しているか否かの判定方法は、第１実施形態と同様である。

判定部２１０は、利用者が車両Ｖｈを運転していないと判定した場合、後述するＳ３５の処理に進む。一方、判定部２１０は、利用者が車両Ｖｈを運転していると判定した場合、車両Ｖｈの位置と、地図情報における道路のリンクデータとのマッチングが成立しているか否かを判定する（Ｓ３２）。マッチングが成立しているか否かの判定方法は、第１実施形態と同様である。

判定部２１０は、マッチングが成立していないと判定した場合、後述するＳ３５の処理に進む。一方、判定部２１０は、マッチングが成立していると判定した場合、車両Ｖｈが安全な位置に停車しているか否かを判定する（Ｓ３３）。車両Ｖｈが安全な位置に停車しているか否かの判定方法は、第１実施形態と同様である。

判定部２１０は、車両Ｖｈが安全な位置に停車していると判定した場合、後述するＳ３５の処理に進む。一方、判定部２１０は、車両Ｖｈが安全な位置に停車していないと判定した場合、アプリに対する操作は不適切な操作であると判定する。この場合、抑制部２２０は、アプリに対する操作を抑制する（Ｓ３４）。

一方、判定部２１０は、Ｓ３１において利用者が車両Ｖｈを運転していないと判定した場合、Ｓ３２においてマッチングが成立していないと判定した場合、またはＳ３３において車両Ｖｈが安全な位置に停車していると判定した場合、アプリに対する操作は適切な操作であると判定する。したがって、抑制部２２０は、アプリに対する操作を抑制しない。

その後、判定部２１０は、目的地到着通知を受信したか否かを判定する（Ｓ３５）。判定部２１０は、目的地到着通知を受信していないと判定した場合、前述のＳ３０の処理に戻る。一方、判定部２１０は、目的地到着通知を受信したと判定した場合、本フローチャートによる処理を終了する。

以上説明したように、第２実施形態の端末装置２００は、車両Ｖｈに乗車した利用者によって保持されている状態で所定のアプリが実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する判定部２１０と、判定部２１０により操作が不適切であると判定された場合に、所定のアプリに対する操作を抑制する抑制部２２０とを有する。これによって、第２実施形態の端末装置２００は、利用者がアプリを操作することによって安全性が損なわれるのを回避することができる。

＜３．第３実施形態＞
第２実施形態においては、端末装置２００が、アプリに対する操作が不適切であるか否かを判定し、操作が不適切である場合にアプリに対する操作を抑制することとした。これに対し、第３実施形態においては、情報処理装置としての保険会社サーバ３００が、アプリに対する操作が不適切であるか否かを判定し、操作が不適切である場合にアプリの実行を端末装置２００に抑制させる。以下、第３実施形態について説明する。

図９は、第３実施形態に係る保険条件決定装置を含むシステムの構成図である。図９において、図１の各部に対応する部分には同一の符号を付し、説明を省略する。第３実施形態において、保険会社サーバ３００は、抑制部３３０を更に有する。

判定部３２０は、車両Ｖｈに乗車した利用者が保持する端末装置２００において所定のアプリ（アプリケーションプログラム）が実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する。所定のアプリに対する操作が不適切であるか否かの判定処理は、第１実施形態と同様であるので説明を省略する。

抑制部３３０は、判定部３２０によりアプリに対する操作が不適切であると判定された場合に、アプリの実行を端末装置２００に抑制させる。これによって、利用者がアプリを操作することによって安全性が損なわれるのを回避することができる。なお、抑制部３３０は、アプリに対する操作を完全に禁止してもよいし、一部のアプリに対する操作のみを禁止するようにしてもよい。

図１０は、第３実施形態における、保険会社サーバ３００により実行される処理の流れの一例を示すフローチャートである。保険会社サーバ３００は、運転開始通知を端末装置２００から受信すると、図１０に示されるフローチャートの処理を実行する。

まず、保険会社サーバ３００の判定部３２０は、端末装置２００からアプリ操作情報を受信したか否かを判定する（Ｓ４０）。判定部３２０は、端末装置２００からアプリ操作情報を受信していないと判定した場合、後述するＳ４５の処理に進む。一方、判定部３２０は、端末装置２００からアプリ操作情報を受信したと判定した場合、利用者が車両Ｖｈを運転しているか否かを判定する（Ｓ４１）。利用者が車両Ｖｈを運転しているか否かの判定方法は、第１実施形態と同様である。

判定部３２０は、利用者が車両Ｖｈを運転していないと判定した場合、後述するＳ４５の処理に進む。一方、判定部３２０は、利用者が車両Ｖｈを運転していると判定した場合、車両Ｖｈの位置と、地図情報における道路のリンクデータとのマッチングが成立しているか否かを判定する（Ｓ４２）。マッチングが成立しているか否かの判定方法は、第１実施形態と同様である。

判定部３２０は、マッチングが成立していないと判定した場合、後述するＳ４５の処理に進む。一方、判定部３２０は、マッチングが成立していると判定した場合、車両Ｖｈが安全な位置に停車しているか否かを判定する（Ｓ４３）。車両Ｖｈが安全な位置に停車しているか否かの判定方法は、第１実施形態と同様である。

判定部３２０は、車両Ｖｈが安全な位置に停車していると判定した場合、後述するＳ４５の処理に進む。一方、判定部３２０は、車両Ｖｈが安全な位置に停車していないと判定した場合、アプリに対する操作は不適切な操作であると判定する。この場合、抑制部３３０は、操作抑制通知を端末装置２００に送信する（Ｓ４４）。端末装置２００は、操作抑制通知を保険会社サーバ３００から受信すると、アプリに対する操作を抑制する。

一方、判定部３２０は、Ｓ４１において利用者が車両Ｖｈを運転していないと判定した場合、Ｓ４２においてマッチングが成立していないと判定した場合、またはＳ４３において車両Ｖｈが安全な位置に停車していると判定した場合、アプリに対する操作は適切な操作であると判定する。したがって、抑制部３３０は、操作抑制通知を端末装置２００に送信しない。

その後、判定部３２０は、目的地到着通知を受信したか否かを判定する（Ｓ４５）。判定部３２０は、目的地到着通知を受信していないと判定した場合、前述のＳ４０の処理に戻る。一方、判定部３２０が目的地到着通知を受信したと判定した場合、本フローチャートによる処理を終了する。

以上説明したように、第３実施形態の情報処理装置は、車両Ｖｈに乗車した利用者が保持する端末装置２００において所定のアプリ（アプリケーションプログラム）が実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する判定部３２０と、判定部３２０により操作が不適切であると判定された場合、端末装置２００にアプリの実行を抑制させる抑制部３３０とを有する。これによって、第３実施形態の情報処理装置は、利用者がアプリを操作することによって安全性が損なわれるのを回避することができる。

＜４．第４実施形態＞
第１実施形態から第３実施形態においては、端末装置２００はナビアプリを実行することとした。これに対し、第４実施形態においては、端末装置２００はナビアプリのみならず、メッセージの送信機能および受信機能を有する通信アプリ（通信ツール）をも実行する。以下、第４実施形態について説明する。

＜４−１．構成＞
図１１は、第４実施形態に係るシステムの構成図である。図１１において、図１の各部に対応する部分には同一の符号を付し、説明を省略する。第４実施形態において、ネットワークＮＷに通信アプリサーバ４００が接続される。端末装置５００は、スマートフォンなどの携帯電話やタブレット端末などである。

通信アプリサーバ４００は、中継部４１０を備える。中継部４１０は、例えば、通信アプリサーバ４００のプロセッサがプログラムを実行することで実現されてもよいし、ＬＳＩやＡＳＩＣ、ＦＰＧＡなどのハードウェアによって実現されてもよい。また、通信アプリサーバ４００の記憶部は、ユーザデータ４２０を記憶している。ユーザデータ４２０は、通信アプリサーバ４００に接続可能な端末装置の識別情報と、端末装置のアドレスとが関連付けられたデータである。

例えば、中継部４１０は、端末装置２００または端末装置５００からメッセージを受信すると、メッセージの宛先の端末装置の識別情報に対応するアドレスを、ユーザデータ４２０を参照して取得する。その後、中継部４１０は、取得したアドレスに対応する端末装置に、受信したメッセージを送信する。これによって、端末装置５００は、通信アプリサーバ４００を介して端末装置２００にメッセージを送信できるとともに、通信アプリサーバ４００を介して端末装置２００からメッセージを受信できる。

また、保険会社サーバ３００は、端末装置２００から設定情報を取得する設定情報取得部３４０を備える。詳細は後述するが、設定情報は、受信されたメッセージに対する返信を自動的に行う自動返信機能が設定されているか否かを示す情報である。設定情報取得部３４０は、例えば、通信アプリサーバ４００のプロセッサがプログラムを実行することで実現されてもよいし、ＬＳＩやＡＳＩＣ、ＦＰＧＡなどのハードウェアによって実現されてもよい。

図１２は、第４実施形態に係る端末装置２００のブロック図である。端末装置２００は、ナビアプリ実行部２３０と、通信アプリ実行部２４０と、表示部２５０と、音声出力部２６０と、無線通信部２７０とを備える。

ナビアプリ実行部２３０は、車両Ｖｈに乗車した利用者に対するナビゲーション機能を有するナビアプリを実行する。通信アプリ実行部２４０は、メッセージの送信機能および受信機能を有する通信アプリを実行する。表示部２５０は、液晶表示装置などの表示装置である。音声出力部２６０は、通信アプリのメッセージを受信した場合、受信したメッセージを音声で出力する。無線通信部２７０は、ネットワークＮＷを介した無線通信を行う。これらの機能部２３０から２７０は、端末装置２００のプロセッサがプログラムを実行することで実現されてもよいし、ＬＳＩやＡＳＩＣ、ＦＰＧＡなどのハードウェアによって実現されてもよい。

＜４−２．処理のシーケンス＞
図１３は、第４実施形態に係るシステムにおいて実行される処理の流れを示すシーケンス図である。図１３においては、便宜上、端末装置２００を「第１端末装置」として示し、端末装置５００を「第２端末装置」として示す。

まず、端末装置２００においてナビアプリが起動し、利用者による目的地の設定を受け付ける（Ｓ５１）。端末装置２００は、位置測位装置によって特定された端末装置２００の位置（以下、「自装置の位置」）および目的地をナビゲーションサーバ１００に送信する（Ｓ５２）。ナビゲーションサーバ１００では、位置および目的地と、地図情報１２０とを用いて経路探索を行う（Ｓ５３）。ナビゲーションサーバ１００は、探索結果としての経路と、端末装置２００の位置を中心とした領域の部分地図情報とを端末装置２００に送信する（Ｓ５４）。

端末装置２００は、位置測位装置が特定した位置に基づき、車両Ｖｈの運転が開始されたことを判断する。なお、端末装置２００は、利用者からの入力に基づいて車両Ｖｈの運転が開始されたことを判断してもよい。

端末装置２００は、自装置の位置と部分地図情報に含まれるリンクとに対してマップマッチング処理を行い、マップマッチング処理の結果（以下、「マップマッチング結果」）と、部分地図情報とに基づいてナビゲーション画面を生成し、音声情報と共に表示する（Ｓ５５）。

端末装置２００は、定期的に、自装置の位置およびマップマッチング結果をナビゲーションサーバ１００に送信する（Ｓ５６）。前述したように、ナビゲーションサーバ１００と保険会社サーバ３００は統合されて「ナビゲーション／保険会社サーバ」として機能してよく、この場合、ナビゲーション／保険会社サーバが、端末装置２００から受信したマップマッチング結果を記憶部に記憶させる。ナビゲーションサーバ１００は、位置に対応する部分地図情報を端末装置２００に送信する（Ｓ５７）。

一方、端末装置５００は、端末装置２００の通信アプリ宛のメッセージを通信アプリサーバ４００に送信する（Ｓ５８）。通信アプリサーバ４００は、端末装置５００から受信したメッセージを、端末装置２００に送信する（Ｓ５９）。

車両Ｖｈが運転されている間に通信アプリへのメッセージが受信された場合、音声出力部２６０は、受信されたメッセージを音声で出力する。これによって、車両Ｖｈの運転者は、車両Ｖｈを運転中であっても受信したメッセージの内容を知ることができる。

なお、音声出力部２６０は、車両Ｖｈの助手席に同乗者が存在する場合、受信したメッセージを音声で出力しないようにしてもよい。これによって、メッセージの内容が同乗者に知られるのを防止でき、運転者のプライバシーを保護することができる。同乗者が存在するか否かは、端末装置２００に内蔵されたカメラを用いて検出してもよいし、座席に設けられたセンサを用いて検出してもよい。また、同乗者が存在するか否かを予め通信アプリに入力することで、同乗者が存在することを判別してもよい。

端末装置２００は、車両Ｖｈが運転されている場合には、通信アプリサーバ４００から受信したメッセージに対する返信メッセージを生成し（Ｓ６０）、生成したメッセージを通信アプリサーバ４００に自動的に返信する（Ｓ６１）。その後、通信アプリサーバ４００は、端末装置２００から受信したメッセージを端末装置５００に送信する（Ｓ６２）。

図１４は、第４実施形態におけるＳ６０の返信メッセージの生成処理を具体的に示す図である。例えば、ナビアプリ実行部２３０は、車両Ｖｈが運転されているか否かを示す運転情報を、ナビアプリから通信アプリに出力する（Ｓ６０−１）。次に、ナビアプリ実行部２３０は、車両Ｖｈが目的地に到着する時刻である到着予想時刻を示す情報をナビアプリから通信アプリに出力する（Ｓ６０−２）。通信アプリ実行部２４０は、ナビアプリから入力された運転情報が、車両Ｖｈが運転されていることを示す場合、ナビアプリから入力された到着予想時刻を示す情報を用いて、通信アプリサーバ４００から受信したメッセージに対する返信メッセージを生成する（Ｓ６０−３）。

図１５は、第４実施形態に係る通信アプリの表示画面の一例を示す図である。図１５に示されるように、端末装置２００の表示部２５０には、「運転中のため、返信できません。○○時○○分に到着予定です。」の返信メッセージが表示される。この返信メッセージは、端末装置５００の表示部にも表示される。返信メッセージに到着予想時刻を含めることで、返信メッセージを受信した端末装置５００の利用者は、端末装置２００の利用者からメッセージが返信される時刻を、ある程度予測することができる。

このように、通信アプリ実行部２４０は、車両Ｖｈが目的地に到着する到着予想時刻を、端末装置２００から受信したメッセージに対する返信として、通信アプリから送信する。なお、通信アプリ実行部２４０は、車両Ｖｈが目的地に到着するまでの所要時間を、端末装置２００から受信したメッセージに対する返信として、通信アプリから送信してもよい。

また、返信メッセージは、図１５に示される例に限られない。また、通信アプリ実行部２４０は、受信したメッセージの送信元に応じて、自動返信するメッセージの内容を変更してもよい。これによって、利用者に対する通信アプリの利便性を向上することができる。

このようにして、Ｓ５５〜Ｓ６２の処理が繰り返し実行される。端末装置２００は、位置測位装置が特定した位置に基づき、車両Ｖｈが目的地に到着したか否かを判断する。端末装置２００は、車両Ｖｈが目的地に到着したと判断した場合、目的地到着通知をナビゲーションサーバ１００に送信する（Ｓ６３）。なお、端末装置２００は、利用者からの入力に基づいて車両Ｖｈが目的地に到着したことを判断してもよい。

車両Ｖｈが目的地に到着すると、利用者は通信アプリを用いてメッセージを入力する。端末装置２００は、入力されたメッセージを通信アプリサーバ４００に送信する（Ｓ６４）。通信アプリサーバ４００は、端末装置２００から受信したメッセージを、端末装置５００に送信する（Ｓ６５）。このように、端末装置２００は、Ｓ５９において受信したメッセージに対する返信を行うことができる。

なお、通信アプリ実行部２４０は、到着予想時刻または所要時間が、所定以上変動した場合、到着予想時刻または所要時間が変動したことを、通信アプリサーバ４００を介して端末装置５００に通知してもよい。これによって、端末装置５００の利用者は、端末装置２００の利用者からメッセージが返信される時刻を、より正確に予測することができる。

また、通信アプリ実行部２４０は、車両Ｖｈが自動的に運転されている場合、利用者が通信アプリを操作しても安全性は損なわれないため、端末装置２００から受信したメッセージに対する返信を自動的に行わない。これによって、利用者に対する通信アプリの利便性を向上することができる。自動的に運転とは、加速や減速、旋回などの制御を車載コンピュータの制御によって行うことをいう。

＜４−３．端末での処理＞
図１６は、第４実施形態における、端末装置２００により実行される処理の流れの一例を示すフローチャートである。端末装置２００は、車両Ｖｈの運転が開始されたと判断すると、図１６に示されるフローチャートの処理を実行する。

まず、端末装置２００の通信アプリ実行部２４０は、メッセージを受信したか否かを判定する（Ｓ７０）。通信アプリ実行部２４０は、メッセージを受信していないと判定した場合、後述するＳ７４の処理に進む。一方、通信アプリ実行部２４０がメッセージを受信したと判定した場合、音声出力部２６０は、受信したメッセージを音声で出力する（Ｓ７１）。

次に、通信アプリ実行部２４０は、ナビアプリ実行部２３０によって実行されるナビアプリから、車両Ｖｈが目的地に到着する到着予想時刻を取得する（Ｓ７２）。通信アプリ実行部２４０は、取得した到着予想時刻を用いて返信メッセージを生成する。その後、通信アプリ実行部２４０は、生成したメッセージを通信アプリサーバ４００に自動返信する（Ｓ７３）。

次に、ナビアプリ実行部２３０は、車両Ｖｈが目的地に到着したか否かを判定する（Ｓ７４）。ナビアプリ実行部２３０は、車両Ｖｈが目的地に到着していないと判定した場合、前述のＳ７０の処理に戻る。一方、ナビアプリ実行部２３０は、車両Ｖｈが目的地に到着したと判定した場合、ナビゲーションサーバ１００に目的地到着通知を送信し、本フローチャートによる処理を終了する。

通信アプリ実行部２４０は、利用者からの入力に基づき、図１６に示される自動返信機能のオン／オフを設定してもよい。この場合、保険会社サーバ３００の設定情報取得部３４０は、通信アプリに自動返信機能が設定されているか否かを示す設定情報を、端末装置２００から取得する。また、保険条件決定部３１０は、設定情報取得部３４０によって取得された設定情報に基づいて、車両Ｖｈまたは利用者に対する保険条件を決定してもよい。具体的には、保険条件決定部３１０は、通信アプリに自動返信機能が設定されている場合には保険料を安くする。これによって、利用者に対して自動返信機能の設定を促すことができ、車両Ｖｈの運転中にアプリケーションを操作することによって安全性が損なわれるのを回避することができる。

＜４−４．効果＞
以上説明したように、第４実施形態の端末装置は、車両Ｖｈに乗車した利用者に対するナビゲーション機能を有するナビアプリを実行するナビアプリ実行部２３０と、メッセージの送信機能および受信機能を有する通信アプリを実行する通信アプリ実行部２４０と、を備える。通信アプリ実行部２４０は、車両Ｖｈが運転されている間に通信アプリへのメッセージを受信した場合、ナビアプリと連携して、受信したメッセージに対する返信を自動的に行う。これによって、車両Ｖｈの運転中にアプリケーションを操作することによって安全性が損なわれるのを回避することができる。

＜５．第５実施形態＞
第４実施形態において、通信アプリ実行部２４０は、車両Ｖｈが運転されているか否かを示す運転情報および車両Ｖｈが目的地に到着する到着予想時刻を、ナビアプリから直接取得することとした。これに対し、第５実施形態の通信アプリ実行部２４０は、セキュリティ面を改善するために、運転情報および到着予想時刻を、ナビゲーションサーバ１００を介してナビアプリ実行部２３０から取得する。その他の点については、第４実施形態と同様である。以下、第５実施形態と第４実施形態との相違点を説明する。

図１７は、第５実施形態におけるＳ６０の返信メッセージの生成処理を具体的に示す図である。例えば、ナビアプリ実行部２３０は、運転情報をナビゲーションサーバ１００に送信する（Ｓ６０−４）。次に、ナビアプリ実行部２３０は、到着予想時刻を示す情報をナビゲーションサーバ１００に送信する（Ｓ６０−５）。通信アプリ実行部２４０は、通信アプリサーバ４００からメッセージを受信すると、運転情報および到着予想時刻を示す情報を取得するための情報取得要求を、ナビゲーションサーバ１００に送信する（Ｓ６０−６）。

ナビゲーションサーバ１００は、通信アプリ実行部２４０から送信された情報取得要求を受信すると、運転情報および到着予想時刻を示す情報を、通信アプリ実行部２４０に送信する（Ｓ６０−７、Ｓ６０−８）。通信アプリ実行部２４０は、ナビゲーションサーバ１００から受信した運転情報が、車両Ｖｈが運転されていることを示す場合、ナビゲーションサーバ１００から受信した到着予想時刻を示す情報を用いて、通信アプリサーバ４００から受信したメッセージに対する返信メッセージを生成する（Ｓ６０−９）。その後、通信アプリ実行部２４０は、生成したメッセージを通信アプリサーバ４００に自動的に返信する（図１３のＳ６１）。

これによって、第５実施形態の通信アプリは、ナビアプリから直接情報を取得するのではなく、ナビゲーションサーバ１００を介して情報を取得するので、セキュリティ面を改善することができる。

＜６．第６実施形態＞
第６実施形態の通信アプリ実行部２４０は、セキュリティ面を改善するために、運転情報および到着予想時刻を、通信アプリサーバ４００を介してナビアプリ実行部２３０から取得する。その他の点については、第４実施形態と同様である。以下、第６実施形態と第４実施形態との相違点を説明する。

図１８は、第６実施形態におけるＳ６０の返信メッセージの生成処理を具体的に示す図である。例えば、通信アプリ実行部２４０は、通信アプリサーバ４００からメッセージを受信すると、運転情報および到着予想時刻を示す情報を取得するための情報取得要求を、通信アプリサーバ４００に送信する（Ｓ６０−１０）。通信アプリサーバ４００は、通信アプリ実行部２４０から受信した情報取得要求を、ナビアプリ実行部２３０に送信する（Ｓ６０−１１）。

ナビアプリ実行部２３０は、通信アプリサーバ４００から情報取得要求を受信すると、運転情報を通信アプリサーバ４００に送信する（Ｓ６０−１２）。次に、ナビアプリ実行部２３０は、到着予想時刻を示す情報を通信アプリサーバ４００に送信する（Ｓ６０−１３）。その後、通信アプリサーバ４００は、運転情報および到着予想時刻を示す情報を、通信アプリ実行部２４０に送信する（Ｓ６０−１４、Ｓ６０−１５）。

通信アプリ実行部２４０は、通信アプリサーバ４００から受信した運転情報が、車両Ｖｈが運転されていることを示す場合、通信アプリサーバ４００から受信した到着予想時刻を示す情報を用いて、通信アプリサーバ４００から受信したメッセージに対する返信メッセージを生成する（Ｓ６０−１６）。その後、通信アプリ実行部２４０は、生成したメッセージを通信アプリサーバ４００に自動的に返信する（図１３のＳ６１）。

これによって、第６実施形態の通信アプリは、ナビアプリから直接情報を取得するのではなく、通信アプリサーバ４００を介して情報を取得するので、セキュリティ面を改善することができる。

＜７．第７実施形態＞
第７実施形態の通信アプリ実行部２４０は、セキュリティ面を改善するために、運転情報および到着予想時刻を、ナビゲーションサーバ１００および通信アプリサーバ４００を介してナビアプリ実行部２３０から取得する。その他の点については、第４実施形態と同様である。以下、第７実施形態と第４実施形態との相違点を説明する。

図１９は、第７実施形態におけるＳ６０の返信メッセージの生成処理を具体的に示す図である。例えば、ナビアプリ実行部２３０は、運転情報をナビゲーションサーバ１００に送信する（Ｓ６０−１７）。次に、ナビアプリ実行部２３０は、到着予想時刻を示す情報をナビゲーションサーバ１００に送信する（Ｓ６０−１８）。通信アプリ実行部２４０は、通信アプリサーバ４００からメッセージを受信すると、運転情報および到着予想時刻を示す情報を取得するための情報取得要求を、通信アプリサーバ４００に送信する（Ｓ６０−１９）。通信アプリサーバ４００は、通信アプリ実行部２４０から受信した情報取得要求を、ナビゲーションサーバ１００に送信する（Ｓ６０−２０）。

ナビゲーションサーバ１００は、通信アプリサーバ４００から情報取得要求を受信すると、運転情報を通信アプリサーバ４００に送信する（Ｓ６０−２１）。次に、ナビゲーションサーバ１００は、到着予想時刻を示す情報を通信アプリサーバ４００に送信する（Ｓ６０−２２）。その後、通信アプリサーバ４００は、運転情報および到着予想時刻を示す情報を、通信アプリ実行部２４０に送信する（Ｓ６０−２３、Ｓ６０−２４）。

通信アプリ実行部２４０は、通信アプリサーバ４００から受信した運転情報が、車両Ｖｈが運転されていることを示す場合、通信アプリサーバ４００から受信した到着予想時刻を示す情報を用いて、通信アプリサーバ４００から受信したメッセージに対する返信メッセージを生成する（Ｓ６０−２５）。その後、通信アプリ実行部２４０は、生成したメッセージを通信アプリサーバ４００に自動的に返信する（図１３のＳ６１）。

これによって、第７実施形態の通信アプリは、ナビアプリから直接情報を取得するのではなく、ナビゲーションサーバ１００および通信アプリサーバ４００を介して情報を取得するので、セキュリティ面を改善することができる。

上述した複数の実施形態は、各々の実施形態に限定されるものではなく、複数の実施形態を組み合わせて実施することができる。また、本発明の思想を逸脱しない範囲において、構成要素の置換や削除、追加など、適宜の変更を加えることができる。

＜８．ハードウェア構成＞
図２０は、ナビゲーションサーバ１００、端末装置２００、保険会社サーバ３００、通信アプリサーバ４００、および端末装置５００のハードウェア構成の一例を示す図である。図２０は、端末装置２００および端末装置５００がスマートフォンなどの携帯電話である例を示している。端末装置２００および端末装置５００は、例えば、ＣＰＵ６０１、ＲＡＭ６０２、ＲＯＭ６０３、並びにフラッシュメモリなどの二次記憶装置６０４、タッチパネル６０５、および無線通信モジュール６０６が、内部バスあるいは専用通信線によって相互に接続された構成となっている。ナビアプリは、ネットワークＮＷを介してダウンロードされ、二次記憶装置６０４に格納される。

各サーバ１００、３００および４００は、例えば、ＮＩＣ（Network Interface Card）７０１、ＣＰＵ７０２、ＲＡＭ７０３、ＲＯＭ７０４、フラッシュメモリやＨＤＤなどの二次記憶装置７０５、およびドライブ装置７０６が、内部バスあるいは専用通信線によって相互に接続された構成となっている。ドライブ装置７０６には、光ディスクなどの可搬型記憶媒体が装着される。二次記憶装置７０５、またはドライブ装置７０６に装着された可搬型記憶媒体に記憶されたプログラムがＤＭＡコントローラ（不図示）などによってＲＡＭ７０３に展開され、ＣＰＵ７０２によって実行されることで、各サーバの機能部が実現される。

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

１００…ナビゲーションサーバ
１１０…経路探索部
１２０…地図情報
２００…端末装置
２１０…判定部
２２０…抑制部
２３０…ナビアプリ実行部
２４０…通信アプリ実行部
２５０…表示部
２６０…音声出力部
２７０…無線通信部
３００…保険会社サーバ
３１０…保険条件決定部
３２０…判定部
３３０…抑制部
３４０…設定情報取得部
４００…通信アプリサーバ
４１０…中継部
４２０…ユーザデータ
５００…端末装置

Claims (16)

1. 車両に乗車した利用者に対するナビゲーション機能を有する第１アプリケーションを実行する第１実行部と、
   メッセージの送信機能および受信機能を有する第２アプリケーションを実行する第２実行部と、を備え、
   前記第２実行部は、前記車両が運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記第１実行部および／または前記第１アプリケーションの動作を管理する第１情報処理装置と連携して、前記車両が目的地に到着する到着予想時刻を前記第２アプリケーションから自動的に返信する
   端末装置。
2. 車両に乗車した利用者に対するナビゲーション機能を有する第１アプリケーションを実行する第１実行部と、
   メッセージの送信機能および受信機能を有する第２アプリケーションを実行する第２実行部と、を備え、
   前記第２実行部は、前記車両が前記利用者によって運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記第１実行部および／または前記第１アプリケーションの動作を管理する第１情報処理装置と連携して、前記メッセージに対する返信を自動的に行い、前記車両が自動的に運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記メッセージに対する返信を自動的に行わない
   端末装置。
3. 前記第２実行部は、前記メッセージを受信すると、前記車両が運転されているか否かを示す運転情報を、前記第１アプリケーションの動作を管理する第１情報処理装置および前記第２アプリケーションの動作を制御する第２情報処理装置を介して前記第１実行部から取得し、取得した前記運転情報が、前記車両が運転されていることを示す場合、前記メッセージに対する返信を自動的に行う
   請求項１または２記載の端末装置。
4. 前記第２実行部は、前記メッセージを受信すると、前記車両が運転されているか否かを示す運転情報を、前記第１情報処理装置を介して前記第１実行部から取得し、取得した前記運転情報が、前記車両が運転されていることを示す場合、前記メッセージに対する返信を自動的に行う
   請求項１または２記載の端末装置。
5. 前記第２実行部は、前記メッセージを受信すると、前記車両が運転されているか否かを示す運転情報を、前記第２アプリケーションの動作を制御する第２情報処理装置を介して前記第１実行部から取得し、取得した前記運転情報が、前記車両が運転されていることを示す場合、前記メッセージに対する返信を自動的に行う
   請求項１または２記載の端末装置。
6. 前記第２実行部は、前記メッセージを受信すると、前記車両が運転されているか否かを示す運転情報を前記第１実行部から取得し、取得した前記運転情報が、前記車両が運転されていることを示す場合、前記第２アプリケーションから前記メッセージに対する返信を自動的に行う
   請求項１または２記載の端末装置。
7. 前記第２実行部は、前記車両が目的地に到着する到着予想時刻、または前記車両が前記目的地に到着するまでの所要時間を、前記メッセージに対する返信として、前記第２アプリケーションから返信する
   請求項２記載の端末装置。
8. 前記第２実行部は、前記到着予想時刻または前記所要時間が所定以上変動した場合、前記到着予想時刻または前記所要時間が変動したことを、前記メッセージの送信元に通知する
   請求項７記載の端末装置。
9. 前記第２実行部は、前記車両が自動的に運転されている場合、前記メッセージに対する返信を自動的に行わない
   請求項１記載の端末装置。
10. 前記車両が運転されている間に前記第２アプリケーションへのメッセージを受信した場合、受信した前記メッセージを音声で出力する音声出力部を更に備える
    請求項１から９のいずれか一項に記載の端末装置。
11. 前記音声出力部は、前記車両の助手席に同乗者が存在する場合、受信した前記メッセージを音声で出力しない
    請求項１０記載の端末装置。
12. 前記第２実行部は、受信した前記メッセージの送信元に応じて、自動返信するメッセージの内容を変更する
    請求項１から１１のいずれか一項に記載の端末装置。
13. コンピュータによって実行されるプログラムであって、
    前記コンピュータに、音声出力部または表示部を制御することで、車両に乗車した利用者に対するナビゲーションを行わせる第１アプリケーションと、
    前記コンピュータに、通信部を制御することで、メッセージの送信および受信を行わせる第２アプリケーションと、を含み、
    前記コンピュータに、前記車両が運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記第１アプリケーションと前記第２アプリケーションが連携して、前記通信部を制御することで、前記車両が目的地に到着する到着予想時刻を自動的に返信させる
    プログラム。
14. コンピュータによって実行されるプログラムであって、
    前記コンピュータに、音声出力部または表示部を制御することで、車両に乗車した利用者に対するナビゲーションを行わせる第１アプリケーションと、
    前記コンピュータに、通信部を制御することで、メッセージの送信および受信を行わせる第２アプリケーションと、を含み、
    前記コンピュータに、前記車両が前記利用者によって運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記第１アプリケーションと前記第２アプリケーションが連携して、前記通信部を制御することで、前記メッセージに対する返信を自動的に行わせ、前記車両が自動的に運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記メッセージに対する返信を自動的に行わせない
    プログラム。
15. 車両に乗車した利用者に対するナビゲーション機能を有する第１アプリケーションと、メッセージの送信機能および受信機能を有する第２アプリケーションとを実行する端末装置から、前記車両が運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記第１アプリケーションと連携して、前記車両が目的地に到着する到着予想時刻を前記第２アプリケーションから自動的に返信する自動返信機能が設定されているか否かを示す設定情報を取得する設定情報取得部と、
    前記設定情報取得部によって取得された前記設定情報に基づいて、前記車両または前記利用者に対する保険条件を決定する保険条件決定部と、
    を備える保険条件決定装置。
16. 車両に乗車した利用者に対するナビゲーション機能を有する第１アプリケーションと、メッセージの送信機能および受信機能を有する第２アプリケーションとを実行する端末装置から、前記車両が前記利用者によって運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記第１アプリケーションと連携して、前記メッセージに対する返信を自動的に行い、前記車両が自動的に運転されている間に前記第２アプリケーションへのメッセージを受信した場合、前記メッセージに対する返信を自動的に行わない自動返信機能が設定されているか否かを示す設定情報を取得する設定情報取得部と、
    前記設定情報取得部によって取得された前記設定情報に基づいて、前記車両または前記利用者に対する保険条件を決定する保険条件決定部と、
    を備える保険条件決定装置。

Images