(58)【調査した分野】(Int.Cl.,DB名)
前記第2実行部は、前記メッセージを受信すると、前記車両が運転されているか否かを示す運転情報を、前記第1アプリケーションの動作を管理する第1情報処理装置および前記第2アプリケーションの動作を制御する第2情報処理装置を介して前記第1実行部から取得し、取得した前記運転情報が、前記車両が運転されていることを示す場合、前記メッセージに対する返信を自動的に行う
請求項1または2記載の端末装置。
前記第2実行部は、前記メッセージを受信すると、前記車両が運転されているか否かを示す運転情報を、前記第1情報処理装置を介して前記第1実行部から取得し、取得した前記運転情報が、前記車両が運転されていることを示す場合、前記メッセージに対する返信を自動的に行う
請求項1または2記載の端末装置。
前記第2実行部は、前記メッセージを受信すると、前記車両が運転されているか否かを示す運転情報を、前記第2アプリケーションの動作を制御する第2情報処理装置を介して前記第1実行部から取得し、取得した前記運転情報が、前記車両が運転されていることを示す場合、前記メッセージに対する返信を自動的に行う
請求項1または2記載の端末装置。
前記第2実行部は、前記メッセージを受信すると、前記車両が運転されているか否かを示す運転情報を前記第1実行部から取得し、取得した前記運転情報が、前記車両が運転されていることを示す場合、前記第2アプリケーションから前記メッセージに対する返信を自動的に行う
請求項1または2記載の端末装置。
前記第2実行部は、前記車両が目的地に到着する到着予想時刻、または前記車両が前記目的地に到着するまでの所要時間を、前記メッセージに対する返信として、前記第2アプリケーションから返信する
請求項2記載の端末装置。
前記第2実行部は、前記到着予想時刻または前記所要時間が所定以上変動した場合、前記到着予想時刻または前記所要時間が変動したことを、前記メッセージの送信元に通知する
請求項7記載の端末装置。
車両に乗車した利用者に対するナビゲーション機能を有する第1アプリケーションと、メッセージの送信機能および受信機能を有する第2アプリケーションとを実行する端末装置から、前記車両が運転されている間に前記第2アプリケーションへのメッセージを受信した場合、前記第1アプリケーションと連携して、前記車両が目的地に到着する到着予想時刻を前記第2アプリケーションから自動的に返信する自動返信機能が設定されているか否かを示す設定情報を取得する設定情報取得部と、
前記設定情報取得部によって取得された前記設定情報に基づいて、前記車両または前記利用者に対する保険条件を決定する保険条件決定部と、
を備える保険条件決定装置。
【発明を実施するための形態】
【0009】
以下、図面を参照し、本発明の端末装置、プログラム、および保険条件決定装置の実施形態について説明する。
【0010】
<1.第1実施形態>
<1−1.構成>
図1は、第1実施形態に係る保険条件決定装置を含むシステムの構成図である。実施形態の保険条件決定装置は、一以上のプロセッサにより実現される。実施形態の保険条件決定装置は、保険会社サーバ300を少なくとも含み、ナビゲーションサーバ100を含んでもよい。また、保険会社サーバ300は、ナビゲーションサーバ100に統合されてもよく、ナビゲーションサーバ100および保険会社サーバ300が統合されて保険条件決定装置を構成してもよい。
図1においては、1台の車両Vhおよび端末装置200のみを示しているが、複数の端末装置200がネットワークNWに接続されてよい。
【0011】
端末装置200、ナビゲーションサーバ100、および保険会社サーバ300は、ネットワークNWを介して通信する。ネットワークNWは、例えば、WAN(Wide Area Network)やLAN(Local Area Network)、インターネット、プロバイダ装置、無線基地局、専用回線などのうち一部または全部を含む。
【0012】
端末装置200は、車両Vhに乗車する利用者によって使用される。端末装置200は、スマートフォンなどの携帯電話やタブレット端末などである。端末装置200は、ナビゲーションサーバ100と連携するナビアプリが起動されることで、ナビゲーションシステムの一部を構成するナビゲーション装置として機能する。なお、車両Vhには、ナビゲーション装置(据え置き型の車載装置)が搭載されてもよい。また、据え置き型の車載装置が、端末装置200として扱われてもよい。
【0013】
端末装置200は、GPS(Global Positioning System)受信機などの位置測位装置、ネットワークNWに接続するための通信装置、三軸式の加速度センサ、タッチパネルなどの入出力装置、スピーカ、CPU(Central Processing Unit)などのプロセッサを有する。位置測位装置は、衛星から受信した電波に基づく測位を行って、端末装置200の位置(すなわち車両Vhの位置)を特定する。また、端末装置200は、通信装置が接続された無線基地局の位置から端末装置200の位置を推定してもよい。
【0014】
端末装置200は、位置測位装置などによって特定された端末装置200の位置を定期的に(例えば数[sec]おきに)ナビゲーションサーバ100に送信する。また、端末装置200は、利用者により設定された目的地をナビゲーションサーバ100に送信して経路を取得する。
【0015】
ナビゲーションサーバ100は、経路探索部110を備える。経路探索部110は、例えば、ナビゲーションサーバ100のプロセッサがプログラムを実行することで実現されてもよいし、LSI(Large Scale Integration)やASIC(Application Specific Integrated Circuit)、FPGA(Field-Programmable Gate Array)などのハードウェア(コントローラ)によって実現されてもよい。経路探索部110は、端末装置200からのリクエストに応じて経路探索を行い、経路情報を端末装置200に送信する。また、ナビゲーションサーバ100の記憶部には、地図情報120が記憶される。地図情報120は、例えば、リンクの集合で道路を表現した情報である。
【0016】
図2は、地図情報120の内容の一例を示す図である。地図情報120は、リンクの両端座標、接続リンク、車線数などの情報が、リンクの識別情報であるリンクIDに対応付けられた情報である。
【0017】
ナビゲーションサーバ100は、地図情報120から、端末装置200から受信した端末装置200の位置を中心とした領域の地図情報(部分地図情報)を抽出し、抽出した地図情報を端末装置200に送信する。
【0018】
端末装置200は、ナビゲーションサーバ100から受信した情報に対してマップマッチング処理を行う。マップマッチング処理とは、地図情報(部分地図情報である場合も含む)に含まれる要素(例えばリンク)のうち、どの要素に沿って端末200が移動しているか(すなわち車両Vhがどのリンクを走行しているか)を判定する処理であり、地図情報に含まれるリンク以外の要素(例えばポリゴンなど)をマッチング対象に含めてもよいし、地図情報がマッチング対象以外の要素を含んでもよい。典型的に、リンクを対象とする場合、端末装置200の位置(車両Vhの位置)が、いずれかのリンクに対応付けられる。マップマッチング処理は、例えば、端末装置200の位置に最も近い位置にあるリンクを選択することを基本として、種々の要素を加味して行われる。端末装置200は、ナビゲーションサーバ100から受信した部分地図情報と、マップマッチング処理の結果とに基づいて、ナビゲーション画面を生成し、音声案内と共に表示する。
【0019】
保険会社サーバ300は、例えば保険会社によって運営される。保険会社サーバ300は、保険条件決定部310および判定部320を備える。保険条件決定部310および判定部320は、例えば、保険会社サーバ300のプロセッサがプログラムを実行することで実現されてもよいし、LSIやASIC、FPGAなどのハードウェアによって実現されてもよい。
【0020】
保険条件決定部310は、車両Vhに対し、或いは車両Vhを運転する利用者ごとに保険条件を決定する。本実施形態において保険会社サーバ300を運営する保険会社の提供する保険は、走行した経路の長さ(走行距離)に応じて保険条件が決定される保険であり、走行距離100[km]ごとに100円といったように保険料が決定される。そして、この保険の保険条件は、(A)車両Vhが走行した経路に応じて、事後的に保険条件が決定される、或いは(B)一定期間において車両Vhが走行した経路に応じて、次の期間における保険条件が決定される。保険条件には、保険料の他、免責額、保険金の支払いに伴う保険料の変動量(等級の変動量)、その他の種々の条件が含まれる。走行した経路の情報は、ナビアプリとナビゲーションサーバ100を介して取得されてもよいし、端末装置200において保険会社の提供するアプリが実行されることで、端末装置200の位置測位装置が特定した位置が保険会社サーバ300に送信されることで取得されてもよい。また、走行した経路の情報は、車載装置である端末装置200から取得されてもよい。
【0021】
判定部320は、詳細は後述するが、車両Vhに乗車した利用者が保持する端末装置200において所定のアプリ(アプリケーションプログラム)が実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する。また、保険条件決定部310は、詳細は後述するが、判定部320の判定結果に基づいて、車両Vhまたは利用者に対する保険条件を決定する。
【0022】
ナビゲーションサーバ100および保険会社サーバ300(以下、「各サーバ」)の記憶部は、例えば、RAM(Random Access Memory)やROM(Read Only Memory)、HDD(Hard Disk Drive)、フラッシュメモリなどにより実現される。また、記憶部は、各サーバが保有する記憶装置に限らず、NAS(Network Attached Storage)などの外部記憶装置により実現されてもよい。
【0023】
<1−2.処理の例>
図3は、第1実施形態に係る保険条件決定装置を含むシステムにおいて実行される処理の流れを示すシーケンス図である。
【0024】
<1−3.ナビゲーションの処理>
まず、端末装置200においてナビアプリが起動し、利用者による目的地の設定を受け付ける(S1)。端末装置200は、位置測位装置によって特定された端末装置200の位置(以下、「自装置の位置」)および目的地をナビゲーションサーバ100に送信する(S2)。ナビゲーションサーバ100では、位置および目的地と、地図情報120とを用いて経路探索を行う(S3)。ナビゲーションサーバ100は、探索結果としての経路と、端末装置200の位置を中心とした領域の部分地図情報とを端末装置200に送信する(S4)。
【0025】
端末装置200は、位置測位装置が特定した位置に基づき、車両Vhの運転が開始されたことを判断する。端末装置200は、車両Vhの運転が開始されたと判断した場合、運転開始通知を保険会社サーバ300に送信する(S5)。なお、端末装置200は、利用者からの入力に基づいて車両Vhの運転が開始されたことを判断してもよい。
【0026】
端末装置200は、自装置の位置と部分地図情報に含まれるリンクとに対してマップマッチング処理を行い、マップマッチング処理の結果(以下、「マップマッチング結果」)と、部分地図情報とに基づいてナビゲーション画面を生成し、音声情報と共に表示する(S6)。
【0027】
端末装置200は、定期的に、自装置の位置およびマップマッチング結果をナビゲーションサーバ100に送信する(S7)。ナビゲーションサーバ100は、自装置の位置およびマップマッチング結果を、保険会社サーバ300に送信する(S8)。保険会社サーバ300は、受信した自装置の位置およびマップマッチング結果を記憶部に記憶させる(S9)。前述したように、ナビゲーションサーバ100と保険会社サーバ300は統合されて「ナビゲーション/保険会社サーバ」として機能してよく、この場合、ナビゲーション/保険会社サーバが、端末装置200から受信したマップマッチング結果を記憶部に記憶させる。ナビゲーションサーバ100は、位置に対応する部分地図情報を端末装置200に送信する(S10)。
【0028】
<1−4.アプリ操作の検出と判定>
端末装置200は、利用者によるアプリ操作を検出すると、アプリに対する操作内容を示すアプリ操作情報をナビゲーションサーバ100に送信する(S11)。また、ナビゲーションサーバ100は、端末装置200から受信したアプリ操作情報を、保険会社サーバ300に送信する(S12)。
【0029】
保険会社サーバ300は、ナビゲーションサーバ100からアプリ操作情報を受信すると、アプリに対する操作が不適切であるか否かを判定する判定処理を実行する(S13)。例えば、保険会社サーバ300の判定部320は、車両が運転されているか否かに基づいて、アプリに対する操作が不適切であるか否かを判定する。車両Vhが運転されていない場合は、利用者がアプリを操作しても安全性は損なわれないため、判定部320はアプリに対する操作が不適切でない(適切である)と判定する。
【0030】
図4は、車両Vhが運転されている期間の一例を示す図である。
図4に示されるように、判定部320は、車両Vhが出発地点を出発してから目的地に到着するまでの間、車両Vhが運転されていると判定する。具体的に、判定部320は、S5において運転開始通知を受信してから、S15において目的地到着通知を受信するまでの間、車両Vhが運転されていると判定する。なお、車両Vhの運転中の期間において、車両Vhは走行と停車を繰り返すが、この停車中の間も、「運転中の期間」とみなされる。なお、停車中の期間が基準時間を超えたような場合には、「運転中の期間」でないと判定してもよい。
【0031】
また、判定部320は、判定部320は、車両Vhの位置と、地図情報における道路のリンクデータとのマッチングの成立状態に基づいて、アプリに対する操作が不適切であるか否かを判定する。マッチングが成立していない場合は、車両Vhは道路上に存在しないと推定されるため、判定部320はアプリに対する操作は不適切でない(適切である)と判定する。
【0032】
なお、判定部320は、マッチングの信頼度に基づいて、アプリに対する操作が不適切であるか否かを判定してもよい。例えば、判定部320は、車両Vhの位置と、地図情報に含まれるリンクデータにおける車両Vhに最も近い道路の位置との距離に基づき、信頼度を算出してもよい。この場合、車両Vhの位置と、車両Vhに最も近い道路の位置との距離が短いほど、マッチングの信頼度は高くなる。なお、端末装置200が信頼度を算出し、算出した信頼度をマップマッチング結果に付加して送信してもよい。この場合、判定部320は、端末装置200から受信したマップマッチング結果に付加された信頼度に基づいて、アプリに対する操作が不適切であるか否かを判定してもよい。また、ナビゲーションサーバ100が信頼度を算出し、保険会社サーバ300の判定部320がナビゲーションサーバ100から信頼度を受信するようにしてもよい。
【0033】
なお、判定部320は、車両Vhの位置と、地図情報に含まれるリンクデータにおける車両Vhに最も近い道路の位置との距離が所定距離を超える場合、たとえマッチングが成立していても、判定部320はマッチングが成立していないと判定してもよい。
【0034】
また、判定部320は、車両Vhが安全な位置に停車している場合に、アプリに対する操作は不適切でない(適切である)と判定する。
図5は、安全な位置に停車している車両Vh1と、安全でない位置に停車している車両Vh2の一例を示す図である。
図5に示されるように、車両Vh1は路面店Sの駐車場Pに停車しているため、判定部320は、車両Vh1は安全な位置に停車していると判定する。一方、車両Vh2は交差点で右折するために停車しているため、判定部320は、車両Vh2は安全な位置に停車していないと判定する。
【0035】
例えば、判定部320は、各車両から収集されたプローブ情報に基づいて、車両Vhが安全な位置に停車しているか否かを判定してよい。プローブ情報には、各車両の速度情報が含まれる。ナビゲーションサーバ100は、各車両の端末装置からプローブ情報を収集し、保険会社サーバ300の判定部320は、ナビゲーションサーバ100にプローブ情報を要求する。例えば、判定部320は、ナビゲーションサーバ100から受信したプローブ情報に基づき、車両Vhの近くに存在する複数の車両の速度の平均値が所定値未満である場合、車両Vhは安全な位置に停車していると判定する。判定部320は、判定結果を記憶部に格納する。記憶部は、判定結果を履歴データとして蓄積する。
【0036】
このようにして、S6〜S13の処理が繰り返し実行される。端末装置200は、位置測位装置が特定した位置に基づき、車両Vhが目的地に到着したか否かを判断する。端末装置200は、車両Vhが目的地に到着したと判断した場合、目的地到着通知をナビゲーションサーバ100に送信する(S14)。ナビゲーションサーバ100は、端末装置200から受信した目的地到着通知を、保険会社サーバ300に送信する(S15)。なお、端末装置200は、利用者からの入力に基づいて車両Vhが目的地に到着したことを判断してもよい。
【0037】
<1−5.保険条件の決定>
その後、保険会社サーバ300は、S13の判定処理における判定結果に基づいて、車両Vhまたは利用者に対する保険条件を決定する(S16)。アプリに対する操作が不適切であると判断された場合、事故が発生する可能性が高まると考えられる。このため、保険会社サーバ300の保険条件決定部310は、判定部320によって判定された不適切な操作の割合が高いほど、保険料が高くなるように保険条件を決定する。例えば、保険条件決定部310は、1回の運転ごとに、不適切な操作の割合に応じて保険条件を変更する。
【0038】
<1−6.保険会社サーバによる処理>
図6は、第1実施形態における、保険会社サーバ300により実行される処理の流れの一例を示すフローチャートである。保険会社サーバ300は、運転開始通知を端末装置200から受信すると、
図6に示されるフローチャートの処理を実行する。
【0039】
まず、保険会社サーバ300の判定部320は、端末装置200からアプリ操作情報を受信したか否かを判定する(S20)。判定部320は、端末装置200からアプリ操作情報を受信していないと判定した場合、後述するS26の処理に進む。一方、判定部320は、端末装置200からアプリ操作情報を受信したと判定した場合、利用者が車両Vhを運転しているか否かを判定する(S21)。
【0040】
判定部320は、利用者が車両Vhを運転していないと判定した場合、後述するS25の処理に進む。一方、判定部320は、利用者が車両Vhを運転していると判定した場合、車両Vhの位置と、地図情報における道路のリンクデータとのマッチングが成立しているか否かを判定する(S22)。
【0041】
判定部320は、マッチングが成立していないと判定した場合、後述するS25の処理に進む。一方、判定部320は、マッチングが成立していると判定した場合、車両Vhが安全な位置に停車しているか否かを判定する(S23)。
【0042】
判定部320は、車両Vhが安全な位置に停車していると判定した場合、後述するS25の処理に進む。一方、判定部320は、車両Vhが安全な位置に停車していないと判定した場合、アプリに対する操作は不適切な操作であると判定し、判定結果を記憶部に記憶する(S24)。
【0043】
一方、判定部320は、S21において利用者が車両Vhを運転していないと判定した場合、S22においてマッチングが成立していないと判定した場合、またはS23において車両Vhが安全な位置に停車していると判定した場合、アプリに対する操作は適切な操作であると判定し、判定結果を記憶部に記憶する(S25)。
【0044】
その後、判定部320は、目的地到着通知を受信したか否かを判定する(S26)。判定部320は、目的地到着通知を受信していないと判定した場合、前述のS20の処理に戻る。一方、判定部320が目的地到着通知を受信したと判定した場合、保険条件決定部310は、記憶部に記憶された判定結果の履歴に基づき、保険条件を決定し(S27)、本フローチャートによる処理を終了する。
【0045】
<1−7.効果>
以上説明したように、第1実施形態の保険条件決定装置は、車両Vhに乗車した利用者が保持する端末装置200において所定のアプリが実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する判定部320と、判定部320の判定結果に基づいて、車両Vhまたは利用者に対する保険条件を決定する保険条件決定部310とを有する。これによって、第1実施形態の保険条件決定装置は、車両または利用者に対する保険条件を適切に決定することができる。
【0046】
<2.第2実施形態>
第1実施形態においては、保険会社サーバ300が、アプリに対する操作が不適切であるか否かを判定し、車両Vhまたは利用者に対する保険条件を決定することとした。これに対し、第2実施形態においては、端末装置200が、アプリに対する操作が不適切であるか否かを判定し、操作が不適切である場合にアプリに対する操作を抑制する。以下、第2実施形態について説明する。
【0047】
図7は、第2実施形態に係る保険条件決定装置を含むシステムの構成図である。
図7において、
図1の各部に対応する部分には同一の符号を付し、説明を省略する。第2実施形態において、端末装置200は、判定部210および抑制部220を有する。
【0048】
判定部210は、端末装置200が車両Vhに乗車した利用者によって保持されている状態で所定のアプリ(アプリケーションプログラム)が実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する。所定のアプリに対する操作が不適切であるか否かの判定処理は、第1実施形態と同様であるので説明を省略する。
【0049】
抑制部220は、判定部210によりアプリに対する操作が不適切であると判定された場合に、アプリに対する操作を抑制する。これによって、利用者がアプリを操作することによって安全性が損なわれるのを予め防止することができる。なお、抑制部220は、アプリに対する操作を完全に禁止してもよいし、一部のアプリに対する操作のみを禁止するようにしてもよい。
【0050】
図8は、第2実施形態における、端末装置200により実行される処理の流れの一例を示すフローチャートである。端末装置200は、位置測位装置が特定した位置(車両Vhの位置)に基づき、車両Vhの運転が開始されたことを判断する。端末装置200は、車両Vhの運転が開始されると、
図8に示されるフローチャートの処理を実行する。端末装置200は、利用者からの入力に基づいて車両Vhの運転が開始されたことを判断してもよい。
【0051】
まず、端末装置200の判定部210は、アプリが操作されたか否かを判定する(S30)。判定部210は、アプリが操作されていないと判定した場合、後述するS35の処理に進む。一方、判定部210は、アプリが操作されたと判定した場合、利用者が車両Vhを運転しているか否かを判定する(S31)。利用者が車両Vhを運転しているか否かの判定方法は、第1実施形態と同様である。
【0052】
判定部210は、利用者が車両Vhを運転していないと判定した場合、後述するS35の処理に進む。一方、判定部210は、利用者が車両Vhを運転していると判定した場合、車両Vhの位置と、地図情報における道路のリンクデータとのマッチングが成立しているか否かを判定する(S32)。マッチングが成立しているか否かの判定方法は、第1実施形態と同様である。
【0053】
判定部210は、マッチングが成立していないと判定した場合、後述するS35の処理に進む。一方、判定部210は、マッチングが成立していると判定した場合、車両Vhが安全な位置に停車しているか否かを判定する(S33)。車両Vhが安全な位置に停車しているか否かの判定方法は、第1実施形態と同様である。
【0054】
判定部210は、車両Vhが安全な位置に停車していると判定した場合、後述するS35の処理に進む。一方、判定部210は、車両Vhが安全な位置に停車していないと判定した場合、アプリに対する操作は不適切な操作であると判定する。この場合、抑制部220は、アプリに対する操作を抑制する(S34)。
【0055】
一方、判定部210は、S31において利用者が車両Vhを運転していないと判定した場合、S32においてマッチングが成立していないと判定した場合、またはS33において車両Vhが安全な位置に停車していると判定した場合、アプリに対する操作は適切な操作であると判定する。したがって、抑制部220は、アプリに対する操作を抑制しない。
【0056】
その後、判定部210は、目的地到着通知を受信したか否かを判定する(S35)。判定部210は、目的地到着通知を受信していないと判定した場合、前述のS30の処理に戻る。一方、判定部210は、目的地到着通知を受信したと判定した場合、本フローチャートによる処理を終了する。
【0057】
以上説明したように、第2実施形態の端末装置200は、車両Vhに乗車した利用者によって保持されている状態で所定のアプリが実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する判定部210と、判定部210により操作が不適切であると判定された場合に、所定のアプリに対する操作を抑制する抑制部220とを有する。これによって、第2実施形態の端末装置200は、利用者がアプリを操作することによって安全性が損なわれるのを回避することができる。
【0058】
<3.第3実施形態>
第2実施形態においては、端末装置200が、アプリに対する操作が不適切であるか否かを判定し、操作が不適切である場合にアプリに対する操作を抑制することとした。これに対し、第3実施形態においては、情報処理装置としての保険会社サーバ300が、アプリに対する操作が不適切であるか否かを判定し、操作が不適切である場合にアプリの実行を端末装置200に抑制させる。以下、第3実施形態について説明する。
【0059】
図9は、第3実施形態に係る保険条件決定装置を含むシステムの構成図である。
図9において、
図1の各部に対応する部分には同一の符号を付し、説明を省略する。第3実施形態において、保険会社サーバ300は、抑制部330を更に有する。
【0060】
判定部320は、車両Vhに乗車した利用者が保持する端末装置200において所定のアプリ(アプリケーションプログラム)が実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する。所定のアプリに対する操作が不適切であるか否かの判定処理は、第1実施形態と同様であるので説明を省略する。
【0061】
抑制部330は、判定部320によりアプリに対する操作が不適切であると判定された場合に、アプリの実行を端末装置200に抑制させる。これによって、利用者がアプリを操作することによって安全性が損なわれるのを回避することができる。なお、抑制部330は、アプリに対する操作を完全に禁止してもよいし、一部のアプリに対する操作のみを禁止するようにしてもよい。
【0062】
図10は、第3実施形態における、保険会社サーバ300により実行される処理の流れの一例を示すフローチャートである。保険会社サーバ300は、運転開始通知を端末装置200から受信すると、
図10に示されるフローチャートの処理を実行する。
【0063】
まず、保険会社サーバ300の判定部320は、端末装置200からアプリ操作情報を受信したか否かを判定する(S40)。判定部320は、端末装置200からアプリ操作情報を受信していないと判定した場合、後述するS45の処理に進む。一方、判定部320は、端末装置200からアプリ操作情報を受信したと判定した場合、利用者が車両Vhを運転しているか否かを判定する(S41)。利用者が車両Vhを運転しているか否かの判定方法は、第1実施形態と同様である。
【0064】
判定部320は、利用者が車両Vhを運転していないと判定した場合、後述するS45の処理に進む。一方、判定部320は、利用者が車両Vhを運転していると判定した場合、車両Vhの位置と、地図情報における道路のリンクデータとのマッチングが成立しているか否かを判定する(S42)。マッチングが成立しているか否かの判定方法は、第1実施形態と同様である。
【0065】
判定部320は、マッチングが成立していないと判定した場合、後述するS45の処理に進む。一方、判定部320は、マッチングが成立していると判定した場合、車両Vhが安全な位置に停車しているか否かを判定する(S43)。車両Vhが安全な位置に停車しているか否かの判定方法は、第1実施形態と同様である。
【0066】
判定部320は、車両Vhが安全な位置に停車していると判定した場合、後述するS45の処理に進む。一方、判定部320は、車両Vhが安全な位置に停車していないと判定した場合、アプリに対する操作は不適切な操作であると判定する。この場合、抑制部330は、操作抑制通知を端末装置200に送信する(S44)。端末装置200は、操作抑制通知を保険会社サーバ300から受信すると、アプリに対する操作を抑制する。
【0067】
一方、判定部320は、S41において利用者が車両Vhを運転していないと判定した場合、S42においてマッチングが成立していないと判定した場合、またはS43において車両Vhが安全な位置に停車していると判定した場合、アプリに対する操作は適切な操作であると判定する。したがって、抑制部330は、操作抑制通知を端末装置200に送信しない。
【0068】
その後、判定部320は、目的地到着通知を受信したか否かを判定する(S45)。判定部320は、目的地到着通知を受信していないと判定した場合、前述のS40の処理に戻る。一方、判定部320が目的地到着通知を受信したと判定した場合、本フローチャートによる処理を終了する。
【0069】
以上説明したように、第3実施形態の情報処理装置は、車両Vhに乗車した利用者が保持する端末装置200において所定のアプリ(アプリケーションプログラム)が実行されている場合に、所定のアプリに対する操作が不適切であるか否かを判定する判定部320と、判定部320により操作が不適切であると判定された場合、端末装置200にアプリの実行を抑制させる抑制部330とを有する。これによって、第3実施形態の情報処理装置は、利用者がアプリを操作することによって安全性が損なわれるのを回避することができる。
【0070】
<4.第4実施形態>
第1実施形態から第3実施形態においては、端末装置200はナビアプリを実行することとした。これに対し、第4実施形態においては、端末装置200はナビアプリのみならず、メッセージの送信機能および受信機能を有する通信アプリ(通信ツール)をも実行する。以下、第4実施形態について説明する。
【0071】
<4−1.構成>
図11は、第4実施形態に係るシステムの構成図である。
図11において、
図1の各部に対応する部分には同一の符号を付し、説明を省略する。第4実施形態において、ネットワークNWに通信アプリサーバ400が接続される。端末装置500は、スマートフォンなどの携帯電話やタブレット端末などである。
【0072】
通信アプリサーバ400は、中継部410を備える。中継部410は、例えば、通信アプリサーバ400のプロセッサがプログラムを実行することで実現されてもよいし、LSIやASIC、FPGAなどのハードウェアによって実現されてもよい。また、通信アプリサーバ400の記憶部は、ユーザデータ420を記憶している。ユーザデータ420は、通信アプリサーバ400に接続可能な端末装置の識別情報と、端末装置のアドレスとが関連付けられたデータである。
【0073】
例えば、中継部410は、端末装置200または端末装置500からメッセージを受信すると、メッセージの宛先の端末装置の識別情報に対応するアドレスを、ユーザデータ420を参照して取得する。その後、中継部410は、取得したアドレスに対応する端末装置に、受信したメッセージを送信する。これによって、端末装置500は、通信アプリサーバ400を介して端末装置200にメッセージを送信できるとともに、通信アプリサーバ400を介して端末装置200からメッセージを受信できる。
【0074】
また、保険会社サーバ300は、端末装置200から設定情報を取得する設定情報取得部340を備える。詳細は後述するが、設定情報は、受信されたメッセージに対する返信を自動的に行う自動返信機能が設定されているか否かを示す情報である。設定情報取得部340は、例えば、通信アプリサーバ400のプロセッサがプログラムを実行することで実現されてもよいし、LSIやASIC、FPGAなどのハードウェアによって実現されてもよい。
【0075】
図12は、第4実施形態に係る端末装置200のブロック図である。端末装置200は、ナビアプリ実行部230と、通信アプリ実行部240と、表示部250と、音声出力部260と、無線通信部270とを備える。
【0076】
ナビアプリ実行部230は、車両Vhに乗車した利用者に対するナビゲーション機能を有するナビアプリを実行する。通信アプリ実行部240は、メッセージの送信機能および受信機能を有する通信アプリを実行する。表示部250は、液晶表示装置などの表示装置である。音声出力部260は、通信アプリのメッセージを受信した場合、受信したメッセージを音声で出力する。無線通信部270は、ネットワークNWを介した無線通信を行う。これらの機能部230から270は、端末装置200のプロセッサがプログラムを実行することで実現されてもよいし、LSIやASIC、FPGAなどのハードウェアによって実現されてもよい。
【0077】
<4−2.処理のシーケンス>
図13は、第4実施形態に係るシステムにおいて実行される処理の流れを示すシーケンス図である。
図13においては、便宜上、端末装置200を「第1端末装置」として示し、端末装置500を「第2端末装置」として示す。
【0078】
まず、端末装置200においてナビアプリが起動し、利用者による目的地の設定を受け付ける(S51)。端末装置200は、位置測位装置によって特定された端末装置200の位置(以下、「自装置の位置」)および目的地をナビゲーションサーバ100に送信する(S52)。ナビゲーションサーバ100では、位置および目的地と、地図情報120とを用いて経路探索を行う(S53)。ナビゲーションサーバ100は、探索結果としての経路と、端末装置200の位置を中心とした領域の部分地図情報とを端末装置200に送信する(S54)。
【0079】
端末装置200は、位置測位装置が特定した位置に基づき、車両Vhの運転が開始されたことを判断する。なお、端末装置200は、利用者からの入力に基づいて車両Vhの運転が開始されたことを判断してもよい。
【0080】
端末装置200は、自装置の位置と部分地図情報に含まれるリンクとに対してマップマッチング処理を行い、マップマッチング処理の結果(以下、「マップマッチング結果」)と、部分地図情報とに基づいてナビゲーション画面を生成し、音声情報と共に表示する(S55)。
【0081】
端末装置200は、定期的に、自装置の位置およびマップマッチング結果をナビゲーションサーバ100に送信する(S56)。前述したように、ナビゲーションサーバ100と保険会社サーバ300は統合されて「ナビゲーション/保険会社サーバ」として機能してよく、この場合、ナビゲーション/保険会社サーバが、端末装置200から受信したマップマッチング結果を記憶部に記憶させる。ナビゲーションサーバ100は、位置に対応する部分地図情報を端末装置200に送信する(S57)。
【0082】
一方、端末装置500は、端末装置200の通信アプリ宛のメッセージを通信アプリサーバ400に送信する(S58)。通信アプリサーバ400は、端末装置500から受信したメッセージを、端末装置200に送信する(S59)。
【0083】
車両Vhが運転されている間に通信アプリへのメッセージが受信された場合、音声出力部260は、受信されたメッセージを音声で出力する。これによって、車両Vhの運転者は、車両Vhを運転中であっても受信したメッセージの内容を知ることができる。
【0084】
なお、音声出力部260は、車両Vhの助手席に同乗者が存在する場合、受信したメッセージを音声で出力しないようにしてもよい。これによって、メッセージの内容が同乗者に知られるのを防止でき、運転者のプライバシーを保護することができる。同乗者が存在するか否かは、端末装置200に内蔵されたカメラを用いて検出してもよいし、座席に設けられたセンサを用いて検出してもよい。また、同乗者が存在するか否かを予め通信アプリに入力することで、同乗者が存在することを判別してもよい。
【0085】
端末装置200は、車両Vhが運転されている場合には、通信アプリサーバ400から受信したメッセージに対する返信メッセージを生成し(S60)、生成したメッセージを通信アプリサーバ400に自動的に返信する(S61)。その後、通信アプリサーバ400は、端末装置200から受信したメッセージを端末装置500に送信する(S62)。
【0086】
図14は、第4実施形態におけるS60の返信メッセージの生成処理を具体的に示す図である。例えば、ナビアプリ実行部230は、車両Vhが運転されているか否かを示す運転情報を、ナビアプリから通信アプリに出力する(S60−1)。次に、ナビアプリ実行部230は、車両Vhが目的地に到着する時刻である到着予想時刻を示す情報をナビアプリから通信アプリに出力する(S60−2)。通信アプリ実行部240は、ナビアプリから入力された運転情報が、車両Vhが運転されていることを示す場合、ナビアプリから入力された到着予想時刻を示す情報を用いて、通信アプリサーバ400から受信したメッセージに対する返信メッセージを生成する(S60−3)。
【0087】
図15は、第4実施形態に係る通信アプリの表示画面の一例を示す図である。
図15に示されるように、端末装置200の表示部250には、「運転中のため、返信できません。○○時○○分に到着予定です。」の返信メッセージが表示される。この返信メッセージは、端末装置500の表示部にも表示される。返信メッセージに到着予想時刻を含めることで、返信メッセージを受信した端末装置500の利用者は、端末装置200の利用者からメッセージが返信される時刻を、ある程度予測することができる。
【0088】
このように、通信アプリ実行部240は、車両Vhが目的地に到着する到着予想時刻を、端末装置200から受信したメッセージに対する返信として、通信アプリから送信する。なお、通信アプリ実行部240は、車両Vhが目的地に到着するまでの所要時間を、端末装置200から受信したメッセージに対する返信として、通信アプリから送信してもよい。
【0089】
また、返信メッセージは、
図15に示される例に限られない。また、通信アプリ実行部240は、受信したメッセージの送信元に応じて、自動返信するメッセージの内容を変更してもよい。これによって、利用者に対する通信アプリの利便性を向上することができる。
【0090】
このようにして、S55〜S62の処理が繰り返し実行される。端末装置200は、位置測位装置が特定した位置に基づき、車両Vhが目的地に到着したか否かを判断する。端末装置200は、車両Vhが目的地に到着したと判断した場合、目的地到着通知をナビゲーションサーバ100に送信する(S63)。なお、端末装置200は、利用者からの入力に基づいて車両Vhが目的地に到着したことを判断してもよい。
【0091】
車両Vhが目的地に到着すると、利用者は通信アプリを用いてメッセージを入力する。端末装置200は、入力されたメッセージを通信アプリサーバ400に送信する(S64)。通信アプリサーバ400は、端末装置200から受信したメッセージを、端末装置500に送信する(S65)。このように、端末装置200は、S59において受信したメッセージに対する返信を行うことができる。
【0092】
なお、通信アプリ実行部240は、到着予想時刻または所要時間が、所定以上変動した場合、到着予想時刻または所要時間が変動したことを、通信アプリサーバ400を介して端末装置500に通知してもよい。これによって、端末装置500の利用者は、端末装置200の利用者からメッセージが返信される時刻を、より正確に予測することができる。
【0093】
また、通信アプリ実行部240は、車両Vhが自動的に運転されている場合、利用者が通信アプリを操作しても安全性は損なわれないため、端末装置200から受信したメッセージに対する返信を自動的に行わない。これによって、利用者に対する通信アプリの利便性を向上することができる。自動的に運転とは、加速や減速、旋回などの制御を車載コンピュータの制御によって行うことをいう。
【0094】
<4−3.端末での処理>
図16は、第4実施形態における、端末装置200により実行される処理の流れの一例を示すフローチャートである。端末装置200は、車両Vhの運転が開始されたと判断すると、
図16に示されるフローチャートの処理を実行する。
【0095】
まず、端末装置200の通信アプリ実行部240は、メッセージを受信したか否かを判定する(S70)。通信アプリ実行部240は、メッセージを受信していないと判定した場合、後述するS74の処理に進む。一方、通信アプリ実行部240がメッセージを受信したと判定した場合、音声出力部260は、受信したメッセージを音声で出力する(S71)。
【0096】
次に、通信アプリ実行部240は、ナビアプリ実行部230によって実行されるナビアプリから、車両Vhが目的地に到着する到着予想時刻を取得する(S72)。通信アプリ実行部240は、取得した到着予想時刻を用いて返信メッセージを生成する。その後、通信アプリ実行部240は、生成したメッセージを通信アプリサーバ400に自動返信する(S73)。
【0097】
次に、ナビアプリ実行部230は、車両Vhが目的地に到着したか否かを判定する(S74)。ナビアプリ実行部230は、車両Vhが目的地に到着していないと判定した場合、前述のS70の処理に戻る。一方、ナビアプリ実行部230は、車両Vhが目的地に到着したと判定した場合、ナビゲーションサーバ100に目的地到着通知を送信し、本フローチャートによる処理を終了する。
【0098】
通信アプリ実行部240は、利用者からの入力に基づき、
図16に示される自動返信機能のオン/オフを設定してもよい。この場合、保険会社サーバ300の設定情報取得部340は、通信アプリに自動返信機能が設定されているか否かを示す設定情報を、端末装置200から取得する。また、保険条件決定部310は、設定情報取得部340によって取得された設定情報に基づいて、車両Vhまたは利用者に対する保険条件を決定してもよい。具体的には、保険条件決定部310は、通信アプリに自動返信機能が設定されている場合には保険料を安くする。これによって、利用者に対して自動返信機能の設定を促すことができ、車両Vhの運転中にアプリケーションを操作することによって安全性が損なわれるのを回避することができる。
【0099】
<4−4.効果>
以上説明したように、第4実施形態の端末装置は、車両Vhに乗車した利用者に対するナビゲーション機能を有するナビアプリを実行するナビアプリ実行部230と、メッセージの送信機能および受信機能を有する通信アプリを実行する通信アプリ実行部240と、を備える。通信アプリ実行部240は、車両Vhが運転されている間に通信アプリへのメッセージを受信した場合、ナビアプリと連携して、受信したメッセージに対する返信を自動的に行う。これによって、車両Vhの運転中にアプリケーションを操作することによって安全性が損なわれるのを回避することができる。
【0100】
<5.第5実施形態>
第4実施形態において、通信アプリ実行部240は、車両Vhが運転されているか否かを示す運転情報および車両Vhが目的地に到着する到着予想時刻を、ナビアプリから直接取得することとした。これに対し、第5実施形態の通信アプリ実行部240は、セキュリティ面を改善するために、運転情報および到着予想時刻を、ナビゲーションサーバ100を介してナビアプリ実行部230から取得する。その他の点については、第4実施形態と同様である。以下、第5実施形態と第4実施形態との相違点を説明する。
【0101】
図17は、第5実施形態におけるS60の返信メッセージの生成処理を具体的に示す図である。例えば、ナビアプリ実行部230は、運転情報をナビゲーションサーバ100に送信する(S60−4)。次に、ナビアプリ実行部230は、到着予想時刻を示す情報をナビゲーションサーバ100に送信する(S60−5)。通信アプリ実行部240は、通信アプリサーバ400からメッセージを受信すると、運転情報および到着予想時刻を示す情報を取得するための情報取得要求を、ナビゲーションサーバ100に送信する(S60−6)。
【0102】
ナビゲーションサーバ100は、通信アプリ実行部240から送信された情報取得要求を受信すると、運転情報および到着予想時刻を示す情報を、通信アプリ実行部240に送信する(S60−7、S60−8)。通信アプリ実行部240は、ナビゲーションサーバ100から受信した運転情報が、車両Vhが運転されていることを示す場合、ナビゲーションサーバ100から受信した到着予想時刻を示す情報を用いて、通信アプリサーバ400から受信したメッセージに対する返信メッセージを生成する(S60−9)。その後、通信アプリ実行部240は、生成したメッセージを通信アプリサーバ400に自動的に返信する(
図13のS61)。
【0103】
これによって、第5実施形態の通信アプリは、ナビアプリから直接情報を取得するのではなく、ナビゲーションサーバ100を介して情報を取得するので、セキュリティ面を改善することができる。
【0104】
<6.第6実施形態>
第6実施形態の通信アプリ実行部240は、セキュリティ面を改善するために、運転情報および到着予想時刻を、通信アプリサーバ400を介してナビアプリ実行部230から取得する。その他の点については、第4実施形態と同様である。以下、第6実施形態と第4実施形態との相違点を説明する。
【0105】
図18は、第6実施形態におけるS60の返信メッセージの生成処理を具体的に示す図である。例えば、通信アプリ実行部240は、通信アプリサーバ400からメッセージを受信すると、運転情報および到着予想時刻を示す情報を取得するための情報取得要求を、通信アプリサーバ400に送信する(S60−10)。通信アプリサーバ400は、通信アプリ実行部240から受信した情報取得要求を、ナビアプリ実行部230に送信する(S60−11)。
【0106】
ナビアプリ実行部230は、通信アプリサーバ400から情報取得要求を受信すると、運転情報を通信アプリサーバ400に送信する(S60−12)。次に、ナビアプリ実行部230は、到着予想時刻を示す情報を通信アプリサーバ400に送信する(S60−13)。その後、通信アプリサーバ400は、運転情報および到着予想時刻を示す情報を、通信アプリ実行部240に送信する(S60−14、S60−15)。
【0107】
通信アプリ実行部240は、通信アプリサーバ400から受信した運転情報が、車両Vhが運転されていることを示す場合、通信アプリサーバ400から受信した到着予想時刻を示す情報を用いて、通信アプリサーバ400から受信したメッセージに対する返信メッセージを生成する(S60−16)。その後、通信アプリ実行部240は、生成したメッセージを通信アプリサーバ400に自動的に返信する(
図13のS61)。
【0108】
これによって、第6実施形態の通信アプリは、ナビアプリから直接情報を取得するのではなく、通信アプリサーバ400を介して情報を取得するので、セキュリティ面を改善することができる。
【0109】
<7.第7実施形態>
第7実施形態の通信アプリ実行部240は、セキュリティ面を改善するために、運転情報および到着予想時刻を、ナビゲーションサーバ100および通信アプリサーバ400を介してナビアプリ実行部230から取得する。その他の点については、第4実施形態と同様である。以下、第7実施形態と第4実施形態との相違点を説明する。
【0110】
図19は、第7実施形態におけるS60の返信メッセージの生成処理を具体的に示す図である。例えば、ナビアプリ実行部230は、運転情報をナビゲーションサーバ100に送信する(S60−17)。次に、ナビアプリ実行部230は、到着予想時刻を示す情報をナビゲーションサーバ100に送信する(S60−18)。通信アプリ実行部240は、通信アプリサーバ400からメッセージを受信すると、運転情報および到着予想時刻を示す情報を取得するための情報取得要求を、通信アプリサーバ400に送信する(S60−19)。通信アプリサーバ400は、通信アプリ実行部240から受信した情報取得要求を、ナビゲーションサーバ100に送信する(S60−20)。
【0111】
ナビゲーションサーバ100は、通信アプリサーバ400から情報取得要求を受信すると、運転情報を通信アプリサーバ400に送信する(S60−21)。次に、ナビゲーションサーバ100は、到着予想時刻を示す情報を通信アプリサーバ400に送信する(S60−22)。その後、通信アプリサーバ400は、運転情報および到着予想時刻を示す情報を、通信アプリ実行部240に送信する(S60−23、S60−24)。
【0112】
通信アプリ実行部240は、通信アプリサーバ400から受信した運転情報が、車両Vhが運転されていることを示す場合、通信アプリサーバ400から受信した到着予想時刻を示す情報を用いて、通信アプリサーバ400から受信したメッセージに対する返信メッセージを生成する(S60−25)。その後、通信アプリ実行部240は、生成したメッセージを通信アプリサーバ400に自動的に返信する(
図13のS61)。
【0113】
これによって、第7実施形態の通信アプリは、ナビアプリから直接情報を取得するのではなく、ナビゲーションサーバ100および通信アプリサーバ400を介して情報を取得するので、セキュリティ面を改善することができる。
【0114】
上述した複数の実施形態は、各々の実施形態に限定されるものではなく、複数の実施形態を組み合わせて実施することができる。また、本発明の思想を逸脱しない範囲において、構成要素の置換や削除、追加など、適宜の変更を加えることができる。
【0115】
<8.ハードウェア構成>
図20は、ナビゲーションサーバ100、端末装置200、保険会社サーバ300、通信アプリサーバ400、および端末装置500のハードウェア構成の一例を示す図である。
図20は、端末装置200および端末装置500がスマートフォンなどの携帯電話である例を示している。端末装置200および端末装置500は、例えば、CPU601、RAM602、ROM603、並びにフラッシュメモリなどの二次記憶装置604、タッチパネル605、および無線通信モジュール606が、内部バスあるいは専用通信線によって相互に接続された構成となっている。ナビアプリは、ネットワークNWを介してダウンロードされ、二次記憶装置604に格納される。
【0116】
各サーバ100、300および400は、例えば、NIC(Network Interface Card)701、CPU702、RAM703、ROM704、フラッシュメモリやHDDなどの二次記憶装置705、およびドライブ装置706が、内部バスあるいは専用通信線によって相互に接続された構成となっている。ドライブ装置706には、光ディスクなどの可搬型記憶媒体が装着される。二次記憶装置705、またはドライブ装置706に装着された可搬型記憶媒体に記憶されたプログラムがDMAコントローラ(不図示)などによってRAM703に展開され、CPU702によって実行されることで、各サーバの機能部が実現される。
【0117】
以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【解決手段】車両に乗車した利用者に対するナビゲーション機能を有する第1アプリケーションを実行する第1実行部と、メッセージの送信機能および受信機能を有する第2アプリケーションを実行する第2実行部と、を備え、前記第2実行部は、前記車両が運転されている間に前記第2アプリケーションへのメッセージを受信した場合、前記第1アプリケーションと連携して、前記メッセージに対する返信を自動的に行う端末装置。