JP2019120670A - 行先情報検索装置、プログラム及び行先情報検索システム - Google Patents

Abstract

【課題】ＳＮＳの投稿情報を利用して車両の乗員にお勧めの走行ルートを提供する。【解決手段】センターサーバ２０は、ＳＮＳサーバ４０からユーザの投稿情報を、カーナビゲーション装置３０から車両の現在の位置情報をそれぞれ取得し、取得した投稿情報及び位置情報に基づいて車両の行先を決定し、カーナビゲーション装置３０に対して行先情報として出力する。【選択図】図７

Description

本発明は、行先情報検索装置、プログラム及び行先情報検索システムに関する。

近年、スマートフォンやタブレット端末等の携帯端末の普及に伴い、ＬＩＮＥ（登録商標）、Ｔｗｉｔｔｅｒ（登録商標）、Ｆａｃｅｂｏｏｋ（登録商標）、及びＩｎｓｔａｇｒａｍ（登録商標）等のソーシャル・ネットワーキング・サービス（以下、これらを総称してＳＮＳという。）が頻繁に利用されている。

上記ＳＮＳの投稿情報は、カーナビゲーション装置等の車載装置でも利用される場合がある。例えば、特許文献１には、位置情報に関するＳＮＳの投稿情報を取得し、取得した情報を地図情報と共に表示する技術が開示されている。上記車載装置によれば、車両の乗員は移動しながら有益な情報を得ることができる。

特許第５９４３２２２号公報

ここで、特許文献１の車載装置は、位置情報と、これに対応するＳＮＳの投稿情報を地図上に反映させるものであり、車両の乗員に対してＳＮＳの投稿情報を提供することに変わりはない。他方、ＳＮＳの投稿情報から乗員の嗜好や世の中のトレンドを把握することができれば、乗員にお勧めの走行ルートを提供することができる。

以上の点を踏まえ、本発明は、ＳＮＳの投稿情報を利用して車両の乗員にお勧めの走行ルートを提供することを目的とする。

請求項１に記載の行先情報検索装置は、ソーシャル・ネットワーキング・サービス（ＳＮＳ）を管理する管理サーバから投稿情報を取得する取得部と、前記取得した投稿情報、及び車両の現在の位置情報に基づいて前記車両の行先を決定する決定部と、前記決定部が決定した前記行先を行先情報として出力する出力部と、備えている。

請求項１に記載の行先情報検索装置は、ユーザのＳＮＳにおける投稿情報を取得し、取得した投稿情報及び車両の現在の位置情報を基に走行ルートを作成するための行先情報を生成して出力するものである。この行先情報検索装置によれば、ＳＮＳの投稿情報を利用して車両の乗員にお勧めの走行ルートを提供することができる。

また、請求項２に記載の行先情報検索装置では、前記取得部は、前記車両に乗車する特定ユーザの投稿情報を取得し、取得した前記特定ユーザの投稿情報を基に前記特定ユーザの嗜好を分析する分析部をさらに備え、前記決定部は、前記車両の現在の位置情報、及び前記特定ユーザの嗜好に基づいて前記行先を決定する。

請求項２に記載の行先情報検索装置によれば、ＳＮＳにおける特定ユーザの投稿を分析することにより、特定ユーザの嗜好を走行ルートに反映させることができる。

請求項３に記載の行先情報検索装置では、前記決定部は、複数の前記行先に対し前記車両の立ち寄り順を決定し、前記出力部は、前記立ち寄り順が付加された前記行先情報を出力する。

請求項３に記載の行先情報検索装置によれば、複数の行先に対してお勧めの立ち寄り順を設定することができる。

請求項４に記載の行先情報検索装置は、前記車両に乗車する特定ユーザにより前記特定ユーザの嗜好を設定可能な設定部をさらに備えている。

請求項４に記載の行先情報検索装置によれば、特定ユーザの嗜好を予め走行ルートに反映させることができる。

請求項５に記載のプログラムは、コンピュータを、請求項１〜４の何れか１項に記載の行先情報検索装置が備える各部として機能させるものである。

請求項５に記載のプログラムによれば、ＳＮＳの投稿情報を利用して車両の乗員にお勧めの走行ルートを提供することができる。

請求項６に記載の行先情報検索システムは、請求項１〜４の何れか１項に記載の行先情報検索装置と、前記行先情報検索装置に前記車両の現在の位置情報を送信可能な位置情報提供装置と、を備え、前記位置情報提供装置は、前記行先情報検索装置から受信した前記行先情報に基づき前記車両の走行ルートを最適化する最適化部と、最適化された前記走行ルートを報知する報知部と、を備えている。

請求項６に記載の行先情報検索システムによれば、ＳＮＳの投稿情報を利用して車両の乗員にお勧めの走行ルートを提供することができる。

請求項７に記載の行先情報検索システムは、請求項１〜４の何れか１項に記載の行先情報検索装置と、前記行先情報検索装置に登録された携帯端末と、前記行先情報検索装置に前記車両の現在の位置情報を送信可能な位置情報提供装置と、を備え、前記位置情報提供装置は、前記行先情報検索装置から受信した前記行先情報に基づき前記車両の走行ルートを最適化する最適化部と、最適化された前記走行ルートを報知する報知部と、を備え、前記行先情報検索装置は、前記携帯端末が前記車両の車室内に存在する場合に前記行先情報を前記位置情報提供装置に向けて送信する。

請求項７に記載の行先情報検索システムによれば、携帯端末を持った特定ユーザが車両に乗車するタイミングで乗員にお勧めの走行ルートを提供することができる。

本発明によれば、ＳＮＳの投稿情報を利用して車両の乗員にお勧めの走行ルートを提供することができる。

第１及び第２の実施形態に係る行先情報検索システムの構成を示すブロック図である。 第１及び第２の実施形態に係るセンターサーバの構成を示すブロック図である。 実施形態に係る嗜好テーブルの一例を示す図である。 実施形態に係る行先データの一例を示す図である。 第１及び第２の実施形態に係るカーナビゲーション装置の構成を示すブロック図である。 第１の実施形態に係る行先情報検索システムにおけるユーザ登録に係る処理の流れを示すシーケンス図である。 第１の実施形態に係る行先情報検索システムにおけるルート最適化に係る処理の流れを示すシーケンス図である。 第１の実施形態に係るカーナビゲーション装置の表示部における表示の例である。 第１の実施形態に係る嗜好分析処理の流れを示すフローチャートである。 第１の実施形態に係る行先決定処理の流れを示すフローチャートである。 第１の実施形態に係るルート最適化処理の流れを示すフローチャートである。 第２の実施形態に係る行先情報検索システムにおけるルート最適化に係る処理の流れを示すシーケンス図である。 第２の実施形態に係るトレンド分析処理の流れを示すフローチャートである。 第３の実施形態に係る行先情報検索システムの構成を示すブロック図である。 第３の実施形態に係るカーナビゲーション装置の構成を示すブロック図である。

［第１の実施形態］
以下、本発明の一実施形態である行先情報検索装置及び行先情報検索システムについて図面を用いて説明する。図１は、本実施形態に係る行先情報検索システム１０の概略構成を示すブロック図である。

（構成）
図１に示されるように、本実施形態に係る行先情報検索システム１０は、センターサーバ２０と、カーナビゲーション装置３０と、ＳＮＳサーバ４０と、携帯端末５０と、を含んで構成されている。ここで、本実施形態のカーナビゲーション装置３０は、ＳＮＳを利用するユーザが乗車する車両１２に搭載されている。このＳＮＳはＳＮＳサーバ４０により管理されている。なお、以降の説明において、ＳＮＳを利用するユーザのうち車両１２に乗車するユーザを「特定ユーザ」とし、ＳＮＳを利用する他のユーザと区別する。センターサーバ２０、カーナビゲーション装置３０、ＳＮＳサーバ４０及び携帯端末５０は、ネットワークＮ１を介して相互に接続されている。

図２に示されるように、センターサーバ２０は、制御部２１と、記憶部２７と、通信部２８と、を備えている。本実施形態のセンターサーバ２０は、ＳＮＳサーバ４０からＳＮＳを利用するユーザの投稿情報を、カーナビゲーション装置３０から車両１２の位置情報をそれぞれ取得し、取得した情報に基づいて、車両１２の行先を決定する機能を有している。また、センターサーバ２０は、決定した行先を行先情報としてカーナビゲーション装置３０（図１参照）に向けて出力する機能を有している。本実施形態では、センターサーバ２０が行先情報検索装置に相当する。

制御部２１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、及びＲＡＭ（Random Access Memory）等で構成されている。制御部２１は、ＣＰＵが後述する実行プログラム２７Ａを実行することで、取得部２２、分析部２３、決定部２４、設定部２５及び出力部２６として機能する。

取得部２２は、通信部２８を介してＳＮＳサーバ４０からＳＮＳを利用するユーザの投稿に係る投稿情報を、カーナビゲーション装置３０から車両１２の位置情報をそれぞれ取得する機能を有している。ここで「投稿情報」には、文字データであるテキスト情報、静止画及び動画のデータである画像情報、サウンドデータである音声情報などが含まれる。また、「投稿情報」に特定ユーザの投稿に対するコメントや、評価を含めてもよい。取得部２２では、特定ユーザを含むＳＮＳを利用するユーザの投稿に係る投稿情報を取得することができる。

分析部２３は、取得部２２が取得した特定ユーザの投稿情報を基に特定ユーザの嗜好を分析する機能を有している。ここで「嗜好」には、好み、趣味、関心事項が含まれる。この分析部２３では、特定ユーザの投稿情報からジャンル別の出現頻度を解析し、スコアに換算する。例えば、特定ユーザの投稿にケーキやコーヒーの写真が多く含まれる場合は、カフェのジャンルの比率が上がるようにスコアを更新する。また、特定ユーザの投稿に絵画の論説が多く含まれる場合は、美術館のジャンルの比率が上がるようにスコアを更新する。また、スコアの更新はジャンルと直結する投稿に限らず、特定のジャンルを示唆する投稿に対して行ってもよい。例えば、「疲れた」、「ゆっくりしたい」等の投稿が多い場合には、温泉のジャンルの比率が上がるようにスコアを更新してもよい。また、子供の写真が多い場合には、テーマパークのジャンルの比率が上がるようにスコアを更新してもよい。

また、分析部２３は、特定ユーザ以外のユーザの投稿情報を分析することができる。例えば、ＳＮＳを利用する全てのユーザ、特定ユーザと繋がりがあるユーザ、特定ユーザが属するグループのユーザなどを分析対象に含めることができる。これにより、分析部２３は分析対象に含まれるユーザ全体の嗜好、つまりトレンドをスコアに換算することができる。そして、ジャンル毎のスコアは、後述する嗜好テーブル２７Ｃに記憶される。

決定部２４は、取得部２２が取得した投稿情報、及び車両１２の現在の位置情報に基づいて車両１２の行先を決定する、すなわち検索する機能を有している。まず、決定部２４は、予め記憶部２７の地点リストデータ２７Ｄに記憶されている、又はネットワークＮ１経由で取得した地点リストから、所定エリア内に存在する地点を行先候補として決定する。ここで、所定エリアは、車両１２の現在位置を中心とする一定距離内のエリア、車両１２の現在位置と予め設定された目的地との間のエリアを含むものである。

そして、決定部２４は、所定エリア内の行先候補に対して、嗜好テーブル２７Ｃに記憶されている嗜好のスコアを加味して行先を決定する。

なお、決定部２４は行先を一つに限らず複数決定してもよい。この場合、決定部２４は、各行先に対する立ち寄り順を決定する。この立ち寄り順は、必ずしも車両１２の現在位置からの距離が近い順である必要はない。例えば、スポーツ施設、温泉施設の順や、ショッピングモール、レストランの順など、ＳＮＳの投稿内容やユーザの行動に合わせて立ち寄り順を決定することができる。そして、決定部２４は行先に対して立ち寄り順を付与した位置情報を生成する。

設定部２５は、特定ユーザの嗜好を設定する機能を有している。この設定部２５は、分析部２３による嗜好の各ジャンルに対する重み付けとは別に、特定ユーザの設定に基づいて各ジャンルに対する重み付けを設定することができる。つまり、設定部２５は、分析部２３とは独立して嗜好のスコアを変更することを可能としている。これにより、ＳＮＳには投稿されないジャンルに係る特定ユーザの嗜好を行先に反映させることができる。

また、設定部２５は、行先として優先的に決定されるジャンルを設定することができる。これにより、例えば、食事を目的とする移動に際し、決定部２４は食のジャンルに含まれる行先を決定する。また例えば、災害時の避難に際し、決定部２４は災害のジャンルに含まれる行先を決定する。

出力部２６は、決定部２４において決定された行先を行先情報として出力する機能を有している。ここで、行先が複数ある場合、出力部２６は立ち寄り順が付加された行先情報を出力する。この出力部２６から出力された行先情報は、通信部２８からカーナビゲーション装置３０に向けて送信される。また、行先情報は、通信部２８からＳＮＳサーバ４０及び携帯端末５０に向けて送信することも可能である。

記憶部２７としては、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等が用いられる。本実施形態の記憶部２７には、センターサーバ２０における各種処理を実行するための実行プログラム２７Ａが記憶されている。また、記憶部２７には、ＩＤ情報テーブル２７Ｂ、嗜好テーブル２７Ｃ、地点リストデータ２７Ｄ、行先データ２７Ｅが記憶されている。ＩＤ情報テーブル２７Ｂには、ＳＮＳサーバ４０における特定ユーザの投稿を閲覧するのに必要なアカウントやパスワード、カーナビゲーション装置３０を特定するための端末固有ＩＤ、携帯端末５０を特定するための端末固有ＩＤ等が記憶されている。

嗜好テーブル２７Ｃには、カテゴリ別に、各ジャンルの嗜好のスコアが規定されている。図３は嗜好テーブル２７Ｃの一例である。図３（Ａ）に示されるように、食をカテゴリとする嗜好テーブル２７Ｃには、食のジャンルである「和食」、「洋食」、「中華」、「カフェ」等のスコアが規定されている。また、図３（Ｂ）に示されるように、アクティビティをカテゴリとする嗜好テーブル２７Ｃには、アクティビティのジャンルである「スポーツ」、「テーマパーク」、「美術館・博物館」、「ショッピング」等のスコアが規定されている。また、図３（Ｃ）に示されるように、ドライブ・旅行をカテゴリとする嗜好テーブル２７Ｃには、ドライブ・旅行のジャンルである「海・山」、「温泉」、「グルメ」、「名所」等のスコアが規定されている。さらに、図３（Ｄ）に示されるように、災害をカテゴリとする嗜好テーブル２７Ｃには、災害時の避難所のジャンルである「食料」、「入浴」、「電源」、「おむつ」等のスコアが規定されている。

地点リストデータ２７Ｄには、検索対象となる地図上の地点がその地点の属性と共に地点リストとして記憶されている。属性とは、レストラン、遊園地、観光名所等、その地点の概要を示す情報である。地点リストは予め記憶部２７にインスールされていても、ネットワークＮ１経由で取得されても、いずれの形態でもよい。また、地点リストが予め記憶部２７にインスールされている場合、地点リストはネットワークＮ１経由で更新することができる。

行先データ２７Ｅには、立ち寄り順とその行先が記憶されている。この行先データ２７Ｅは、決定部２４により新たに決定された行先だけでなく、過去に決定されたデータを記憶することができる。例えば、図４（Ａ）はドライブを目的として検索した結果の一例である。図４（Ａ）に示されるように、行先データ２７Ｅには、「Ａ山ロープウェイ」、「レストランＢ」、「Ｃ海岸」、「日帰り温泉Ｄ」の順に行先が規定されている。図４（Ｂ）は食事を目的として検索した結果の一例である。図４（Ｂ）に示されるように、行先データ２７Ｅには、「イタリアンレストランＥ」、「カフェＦ」、「Ｇケーキ店」の順に行先が規定されている。

図２に示されるように、通信部２８は、ネットワークＮ１に接続されている（図１参照）。この通信部２８は、ＳＮＳサーバ４０、カーナビゲーション装置３０、及び携帯端末５０の各々と通信を行う機能を有している。ここで、ネットワークＮ１としては、例えば、インターネットや、ＷＡＮ（Wide Area Network）等が適用される。

図５に示されるように、位置情報提供装置としてのカーナビゲーション装置３０は、制御部３１と、記憶部３４と、通信部３６と、ＧＰＳユニット３８と、表示部３９と、を備えている。このカーナビゲーション装置３０は、当該カーナビゲーション装置３０が搭載された車両１２の位置を提供する機能を有している。またカーナビゲーション装置３０は、センターサーバ２０から受信した行先情報を基に車両１２の走行ルートを決定し、決定された走行ルートを報知する機能を有している。

制御部３１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、及びＲＡＭ（Random Access Memory）等で構成されている。制御部３１は、ＣＰＵが後述する制御プログラム３４Ａを実行することで、取得部３２、最適化部３３として機能する。

取得部３２は、通信部３６を介してセンターサーバ２０から行先情報を取得する機能を有している。

最適化部３３は、取得部３２が取得した行先情報を基に車両１２の走行ルートを最適化する機能を有している。走行ルートの最適化に関しては、単に行先情報に含まれる行先への走行ルートを設定するのみならず、予め設定された目的地に対して行先情報に含まれる行先を立ち寄り先として設定することができる。また、最適化部３３は、公知の道路交通情報通信システム（ＶＩＣＳ（登録商標））から渋滞情報を取得し、これを走行ルートの設定に反映させることができる。

記憶部３４としては、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等が用いられる。本実施形態の記憶部３４には、カーナビゲーション装置３０における各種処理を実行するための制御プログラム３４Ａが記憶されている。また、記憶部３４には、履歴データ３４Ｂが記憶されている。履歴データ３４Ｂには、センターサーバ２０から提供された行先情報に基づいて車両１２が走行した際の行先の履歴が記憶されている。

通信部３６は、ネットワークＮ１に接続されている（図１参照）。この通信部３６は、センターサーバ２０と通信を行う機能を有している。すなわち、センターサーバ２０の通信部２８から送信された行先情報は、通信部３６において受信される。

ＧＰＳユニット３８は、ＧＰＳ（Global Positioning System）衛星からの電波に基づいてカーナビゲーション装置３０が搭載された車両１２の現在の位置座標を測定する機能を有している。すなわち、カーナビゲーション装置３０によれば、ＧＰＳユニット３８が測定した位置座標が位置情報となる。

表示部３９は、車両１２のセンターコンソールやダッシュボード上に設けられたタッチパネル式の液晶ディスプレイである。表示部３９は、カーナビゲーション装置３０の本体部と一体でも別体でもどちらでもよい。この表示部３９は、車両１２の現在位置及び走行ルートを表示する機能を有している。本実施形態の表示部３９は報知部に相当する。

本実施形態のＳＮＳサーバ４０は、ＳＮＳを管理する管理サーバとしての機能を有している。図１に示されるように、ＳＮＳサーバ４０は、ネットワークＮ１を介してセンターサーバ２０及び携帯端末５０に接続されている。ＳＮＳサーバ４０では、携帯端末５０等から送信された特定ユーザの投稿情報を送信可能化状態とする（つまり、アップロード）ことにより、ＳＮＳサーバ４０に接続した他の端末が当該投稿情報を受信する（つまり、ダウンロード）ことを可能としている。このＳＮＳサーバ４０では、特定ユーザの投稿について、当該特定ユーザが指定したユーザしか閲覧できないように、閲覧制限を掛けることができる。

携帯端末５０は、ＳＮＳを利用する特定ユーザが所持するスマートフォンやタブレット端末である。この携帯端末５０は、ネットワークＮ１を介してセンターサーバ２０及びＳＮＳサーバ４０に接続されている。本実施形態の行先情報検索システム１０を利用する特定ユーザは、携帯端末５０からＳＮＳに投稿することができる。

（処理の流れ）
次に、図６のシーケンス図を参照しつつ、本実施形態の行先情報検索システム１０における処理の流れについて説明する。

まず、センターサーバ２０において、ＳＮＳを利用するユーザであって、ＳＮＳの投稿情報を基に行先の検索を行う特定ユーザが事前に行うユーザ登録に係る処理について説明する。

図６のステップＳ１において、携帯端末５０は、センターサーバ２０に向けて携帯端末５０に入力されたユーザ登録情報を送信する。ここで、ユーザ登録情報は、携帯端末５０の入力装置から入力される情報であって、携帯端末５０に予めインストールされたアプリケーションや、専用のインターネットサイトを通じてセンターサーバ２０に送信される。このユーザ登録情報には、ＳＮＳサーバ４０における特定ユーザの投稿の閲覧に必要なアカウントやパスワード、カーナビゲーション装置３０を特定するための情報（例えば、端末固有ＩＤ）、携帯端末５０を特定するための情報（例えば、端末固有ＩＤ）等が含まれる。

また、ユーザ登録情報として、特定ユーザの嗜好及び行先として優先的に決定されるジャンルやカテゴリに係る情報を登録することができる。なお、嗜好のジャンルやカテゴリに係る情報の登録及び変更は、ユーザ登録後においても行うことができる。

ステップＳ２において、センターサーバ２０は、携帯端末５０から取得したユーザ登録情報に基づいてユーザ登録処理を実行する。具体的には、設定部２５が固有のユーザＩＤを生成すると共に、ＩＤ情報テーブル２７Ｂの新たな領域に対してこの生成されたユーザＩＤと、取得したユーザ登録情報を書き込む。

ステップＳ３において、センターサーバ２０は、ユーザ登録情報に含まれる端末固有ＩＤのカーナビゲーション装置３０に向けてテスト信号を送信する。

ステップＳ４において、カーナビゲーション装置３０は、テスト信号を正常に受信した場合に、センターサーバ２０に向けて応答信号を送信する。

ステップＳ５において、センターサーバ２０は、応答信号を正常に受信した場合に、ＩＤ発行処理を実行する。具体的には、ＩＤ情報テーブル２７Ｂからユーザ通知用のユーザＩＤ及び当該ＩＤと同時に生成したパスワードを取得する。

ステップＳ６において、センターサーバ２０は、ユーザ登録処理において生成したユーザＩＤ及び同時に生成したパスワードを携帯端末５０に送信する。

次に、図７のシーケンス図を参照しつつ、ＳＮＳにおける特定ユーザの投稿を基に行先を検索する際のルート最適化に係る処理について説明する。

図７のステップＳ１１において、特定ユーザによる所定の操作に基づいて、カーナビゲーション装置３０はセンターサーバ２０に対して検索開始指示を送信する。なお、この検索開始指示は携帯端末５０から送信してもよい。

ステップＳ１２において、検索開始指示を受けたセンターサーバ２０が起動処理を実行する。具体的に、センターサーバ２０の制御部２１は、ＩＤ情報テーブル２７Ｂを参照して、ユーザＩＤに対応するＳＮＳサーバ４０のアカウント及びパスワードを取得する。

ステップＳ１３において、センターサーバ２０は、通信部２８からＳＮＳサーバ４０に向けてアカウント及びパスワードを送信する。

ステップＳ１４において、ＳＮＳサーバ４０は、センターサーバ２０から受信したアカウント及びパスワードを用いてログイン処理を実行する。ＳＮＳサーバ４０では、アカウントとパスワードとが一致することにより、センターサーバ２０は、特定ユーザの投稿を閲覧する（つまり、ダウンロード）ことが可能となる。

ステップＳ１５において、ＳＮＳサーバ４０は、センターサーバ２０に向けて投稿情報を送信する。つまり、ＳＮＳの投稿がダウンロードされる。

ステップＳ１６において、センターサーバ２０の分析部２３が嗜好分析処理を実行する。詳細は後述する。嗜好分析処理が実行されることで、特定ユーザの嗜好がスコアに換算される。そして、分析部２３は、新たに換算されたスコアに基づいて嗜好テーブル２７Ｃを更新する。なお、設定部２５により、特定ユーザの嗜好が設定されている場合は、当該設定に基づいた嗜好のスコアも嗜好テーブル２７Ｃに反映させる。

ステップＳ１７において、センターサーバ２０は、通信部２８からカーナビゲーション装置３０に向けて位置情報要求を送信する。つまり、センターサーバ２０は、カーナビゲーション装置３０の現在位置を要求する。

ステップＳ１８において、位置情報要求を受信したカーナビゲーション装置３０は、通信部３６からセンターサーバ２０に向けて車両１２の現在位置を位置情報として送信する。

ステップＳ１９において、センターサーバ２０の決定部２４が嗜好テーブル２７Ｃ及び取得した位置情報に基づいて一又は複数の行先を決定する（図４（Ａ）及び（Ｂ）参照）。詳細は後述する。

ステップＳ２０において、センターサーバ２０は、通信部２８からカーナビゲーション装置３０に向けて決定された一又は複数の行先を行先情報として送信する。なお、行先情報は、ＳＮＳサーバ４０に送信してもよい（ステップＳ２１）。この場合、センターサーバ２０は、決定された行先をＳＮＳ上に投稿することができる。また、行先情報は、携帯端末５０に送信してもよい（ステップＳ２２）。この場合、センターサーバ２０は、決定された行先を携帯端末５０を通じて特定ユーザに直接通知することができる。

ステップＳ２３において、行先情報を受信したカーナビゲーション装置３０では、最適化部３３が当該行先情報に基づいてルート最適化処理を実行する。詳細は後述する。ルート最適化処理により、センターサーバ２０が決定した行先情報がカーナビゲーション装置３０の表示部３９に表示される。

図８は、図４（Ａ）の行先データに基づいてルート最適化処理を行った場合における表示部３９の表示例である。図８に示されるように、地図Ｍｐには、車両１２の位置Ｐｃと、複数の行先Ｐ１〜Ｐ４が表示されている。行先Ｐ１〜Ｐ４は、立ち寄り順１〜４にそれぞれ対応する。図４（Ａ）はドライブを目的とする行先の一例であるが、本実施形態では、ＳＮＳの投稿内容を車両１２の走行ルートに反映させることができる。

次に、図９においてセンターサーバ２０が実行する嗜好分析処理について説明する。

まず、ステップＳ１００において、取得部２２は通信部２８を介してＳＮＳサーバ４０から特定ユーザの投稿、すなわち投稿情報を取得する。取得の対象となる投稿としては、一定期間内（例えば、２４時間以内、一週間以内）の投稿、一定数（例えば、過去５件分など）の投稿、特定のコンテンツやユーザに対する投稿など、いずれの場合も可能である。

次のステップＳ１０１において、分析部２３は取得情報のジャンルを選択する。例えば、「昼食にパスタを食べた」という投稿があれば、図３（Ａ）に示される「洋食」のジャンルが選択される。この際、選択される投稿は一つに限らない。例えば、山々に囲まれた露天風呂の写真があれば、図３（Ｃ）に示される「海・山」及び「温泉」のジャンルが選択される。

次のステップＳ１０２において、分析部２３は嗜好テーブル２７Ｃのスコアを更新する。例えば、分析部２３は、「洋食」のジャンルが選択されている場合、嗜好テーブル２７Ｃ中の「洋食」のスコアに対して一定数のポイントを付加したり、投稿に占める「洋食」の記事の割合を加味してポイントを付加する（図３（Ａ）参照）。また例えば分析部２３は、「海・山」及び「温泉」のジャンルが選択されている場合、カテゴリ「ドライブ・旅行」の嗜好テーブル２７Ｃに対して、「海・山」及び「温泉」のスコアが高くなるように、スコアの重み付けを変更する（図３（Ｃ）参照）。スコアが更新されると嗜好分析処理は終了する。

次に、図１０においてセンターサーバ２０が実行する行先決定処理について説明する。

まず、ステップＳ２００において、取得部２２は通信部２８を介してカーナビゲーション装置３０から車両１２の現在位置に係る位置情報を取得する。

次のステップＳ２０１において、決定部２４は、地点リストデータ２７Ｄに記憶されている地点リストから、車両１２の位置情報を基に定められた所定エリア内に存在する地点を行先候補として決定する。なお、上述のように、所定エリアは、車両１２の現在位置を中心とする一定距離内のエリア、及び車両１２の現在位置と予め設定された目的地との間のエリアとすることができる。ただし、所定エリアを車両１２の現在位置と予め設定された目的地との間のエリアとする場合、ステップＳ２００において取得部２２は車両１２の現在の位置情報と共に、目的地に係る位置情報を取得する。

次のステップＳ２０２において、決定部２４は、嗜好テーブル２７Ｃのスコアを加味して行先候補から行先を決定する。例えば、行先候補に、「スポーツ施設」、「遊園地」、「美術館」、「ショッピングモール」が含まれる場合、決定部２４は、図３（Ｂ）に示されるアクティビティの嗜好テーブル２７Ｃのスコアを加味してジャンル「テーマパーク」に対応する「遊園地」を行先に決定する。

次のステップＳ２０３において、決定部２４は、ステップＳ２０２において決定した行先が複数であるか否かを判定する。行先が複数である場合は次のステップＳ２０４に進む。一方、行先が複数ではない場合、すなわち一つしかない場合、ステップＳ２０５に進む。

ステップＳ２０４において、決定部２４は、各行先に対して立ち寄り順を決定する。上述のように、この立ち寄り順は、必ずしも車両１２の現在位置からの距離が近い順である必要はなく、ユーザの行動に合わせて決定することができる。なお、行先が一つの場合でも立ち寄り順を決定してもよい。この場合、立ち寄り順は「１」しかないが、ステップＳ２０３は省略される。

ステップＳ２０５において、決定部２４は行先に対して立ち寄り順を付与した位置情報を生成する。そして行先決定処理は終了する。

次に、図１１においてカーナビゲーション装置３０が実行するルート最適化処理について説明する。

まず、ステップＳ３００において、取得部３２は通信部３６を介してセンターサーバ２０から位置情報を取得する。

ステップＳ３０１において、最適化部３３は行先選択処理を実行する。具体的には、タッチパネルとしての表示部３９において、乗員は取得された行先を走行ルートに反映させるか否かの選択を行う。そして、当該選択に基づく行先に基づいて最適化部３３は、以降の処理を行う。

ステップＳ３０２において、最適化部３３がルート案内を開始するか否かを判定する。ここで、ルート案内を開始するか否かの指示は、タッチパネルとしての表示部３９に対する乗員の操作に基づいて行われる。最適化部３３がルート案内を開始すると判定した場合は次のステップＳ３０３に進む。一方、最適化部３３がルート案内を開始しないと判定した場合はステップＳ３０９に進む。

ステップＳ３０３において、最適化部３３はステップＳ３０１において選択された行先が複数であるか否かを判定する。最適化部３３が行先は複数であると判定した場合は次のステップＳ３０４に進む。一方、最適化部３３が行先は複数ではない、すなわち行先は一つであると判定した場合はステップＳ３０５に進む。

ステップＳ３０４において、最適化部３３は、複数の行先に対して立ち寄り順でルートを検索する。なお、立ち寄り順は行先情報から行先と共に取得されている。そして、ステップＳ３０６に進む。

一方、ステップＳ３０５において、最適化部３３は、一つの行先に対して最短経路の走行ルートを検索する。そして、ステップＳ３０６に進む。

ステップＳ３０６において、制御部３１がルート案内を実行する。すなわち、報知部としての表示部３９や図示しないスピーカを通じて乗員に対して車両１２の現在位置や走行ルートが報知される。

次のステップＳ３０７において、制御部３１は、ルート案内が終了されたか否かを判定する。ここで、ルート案内が終了する場合には、最終目的地に到着した場合、又はタッチパネルとしての表示部３９を通じて案内終了指示を受けた場合がある。制御部３１がルート案内は終了されたと判定した場合、ステップＳ３０９に進む。一方、制御部３１がルート案内は終了されていないと判定した場合、次のステップＳ３０８に進む。

ステップＳ３０８において、制御部３１は、車両１２の現在位置が走行ルートから逸脱しているか否かを判定する。制御部３１が走行ルートから逸脱していると判定した場合、ステップＳ３０３に戻る。これにより、最適化部３３が未到達の行先を対象に再度ルート検索を行う。一方、制御部３１が走行ルートから逸脱していないと判定した場合、ステップＳ３０６に戻る。すなわち、制御部３１がルート案内を続行する。

ステップＳ３０９は、ルート案内を行わなかった場合及びルート案内を終了した場合のステップである。ステップＳ３０９において、制御部３１は、行先を登録するか否かを判定する。ここで、行先を登録するための指示は、タッチパネルとしての表示部３９に対する乗員の操作に基づいて行われる。制御部３１が行先を登録すると判定した場合、ステップＳ３１０に進む。一方、制御部３１が行先を登録しないと判定した場合、ルート最適化処理は終了する。

ステップＳ３１０において、制御部３１は行先登録処理を実行する。すなわち、制御部３１は、登録対象とされる行先を履歴データ３４Ｂに保存する。そして、ルート最適化処理は終了する。

（まとめ）
以上、本実施形態の行先情報検索システム１０及びセンターサーバ２０によれば、ＳＮＳの投稿情報及び車両１２の現在の位置情報を利用して車両１２の乗員に対してお勧めの走行ルートを提供することができる。また、本実施形態では、分析部２３が特定ユーザの投稿から嗜好をスコア化することで特定ユーザが車両１２に乗車した際に、特定ユーザの嗜好を走行ルートに反映させることができる。本実施形態は、災害時において車両で避難する場合にも好適である。すなわち、ＳＮＳの投稿から現在必要とされる物資、サービス、ボランティア情報等を分析し、これを避難ルートに反映させることができる。例えば、図３（Ｄ）に示されるように、災害をカテゴリとする嗜好テーブル２７Ｃを設けておけば、特定ユーザがＳＮＳに乳児の写真を投稿した際、救援物資に「おむつ」が含まれている避難所を走行ルートとして設定することができる。

ここで、センターサーバ２０が行先を複数決定した場合は、立ち寄り順を付加することで複数の行先に対してお勧めの立ち寄り順を設定することができる。上述のように、この立ち寄り順は、必ずしも車両１２の現在位置からの距離が近い順である必要はなく、スポーツ施設、温泉施設の順や、ショッピングモール、レストランの順など、ＳＮＳの投稿内容やユーザの行動に合わせて決定することができる。

そして、本実施形態では、設定部２５により特定ユーザの嗜好を予め走行ルートに反映させることができる。これにより、ＳＮＳには投稿されないジャンルに係る特定ユーザの嗜好を行先に反映させることができる。

［第２の実施形態］
第１の実施形態の行先情報検索システム１０は、ＳＮＳサーバ４０にすでに記憶されている特定ユーザの投稿情報を基に行先を決定し、これを走行ルートに反映させるものであった。これに対して第２の実施形態の行先情報検索システム１０は、ＳＮＳサーバ４０に記憶されている特定ユーザ以外のユーザの投稿情報を基にお勧めの行先を決定するものである。

図１２のシーケンス図を参照しつつ、本実施形態の行先情報検索システム１０におけるルート最適化に係る処理の流れについて説明する。なお、第２の実施形態の行先情報検索システム１０の構成は、第１の実施形態と同じであり、説明は割愛する。

図１２のステップＳ３１において、特定ユーザによる所定の操作に基づいて、カーナビゲーション装置３０は、通信部３６からセンターサーバ２０に向けて車両１２の現在位置を位置情報として送信する。これにより、センターサーバ２０の取得部２２において位置情報が取得される

ステップＳ３２において、センターサーバ２０は、通信部２８からＳＮＳサーバ４０に向けて閲覧指示を送信する。すなわち、センターサーバ２０は、ＳＮＳ上の所定のページにアクセスする。なお、特定ユーザと繋がりがあるユーザ、特定ユーザが属するグループのユーザなどを基に行先を決定する場合、センターサーバ２０は、通信部２８からＳＮＳサーバ４０に向けて特定ユーザのアカウント及びパスワードを送信する。

ステップＳ３３において、ＳＮＳサーバ４０は、センターサーバ２０に向けて投稿情報を送信する。これにより、センターサーバ２０の取得部２２において投稿情報が取得される、すなわち、ＳＮＳの投稿がダウンロードされる。なお、特定ユーザと繋がりがあるユーザ、特定ユーザが属するグループのユーザなどを基に行先を決定する場合、センターサーバ２０から受信したアカウント及びパスワードを用いてログイン処理を実行した上で投稿のダウンロードが可能となる。

ステップＳ３２及びＳ３３を繰り返すことにより、より多くのユーザの嗜好を走行ルートに反映させることができる。

ステップＳ３４において、センターサーバ２０の分析部２３は取得部２２が取得した投稿情報に基づいてトレンド分析処理を実行する。詳細は後述する。

以降、図１２のステップＳ３５からステップＳ３９の処理は、図７のステップＳ１９からステップＳ２３の処理と同様であり、説明は割愛する。

次に、図１３においてセンターサーバ２０が実行するトレンド分析処理について説明する。

まず、ステップＳ４００において、取得部２２は通信部２８を介してＳＮＳサーバ４０からＳＮＳの投稿情報を取得する。

次のステップＳ４０１において、分析部２３は、投稿情報におけるジャンル毎の出現頻度に基づいて、嗜好テーブル２７Ｃのスコアを更新する。例えば、パンダを話題にした投稿が多い場合、「動物園」スコアが高くなるように重み付けが変更される。スコアが更新されるとトレンド分析処理は終了する。

以上、本実施形態の行先情報検索システム１０及びセンターサーバ２０によれば、第１の実施形態と同様の効果を得ることができる。特に、本実施形態では、分析部２３がＳＮＳの投稿におけるトレンドをスコア化することで特定ユーザが車両１２に乗車した際に、世間の流行を走行ルートに反映させることができる。

［第３の実施形態］
第１及び第２の実施形態の行先情報検索システム１０では、センターサーバ２０がＳＮＳの投稿を取得して行先を決定し、カーナビゲーション装置３０が決定された行先に基づいてルート案内を実行していた。これに対して第３の実施形態の行先情報検索システム１００では、カーナビゲーション装置１３０がＳＮＳの投稿を取得して嗜好分析処理、行先決定処理及びルート最適化処理のいずれも実行する。本実施形態ではカーナビゲーション装置１３０が行先情報検索装置、かつ位置情報提供装置に相当する。

図１４に示されるように、本実施形態に係る行先情報検索システム１００は、ＳＮＳサーバ４０と、携帯端末５０と、カーナビゲーション装置１３０と、を含んで構成されている。ここで、本実施形態のカーナビゲーション装置１３０は、ＳＮＳを利用するユーザが乗車する車両１２に搭載されている。このＳＮＳはＳＮＳサーバ４０により管理されている。カーナビゲーション装置１３０、ＳＮＳサーバ４０及び携帯端末５０は、ネットワークＮ１を介して相互に接続されている。以下、第１及び第２の実施形態との相違点について説明する。また、第１及び第２の実施形態と同一の構成には同一の符号を付しており、繰り返しの説明は割愛する。

図１５に示されるように、カーナビゲーション装置１３０は、制御部１３１と、記憶部１３４と、通信部３６と、ＧＰＳユニット３８と、表示部３９と、を備えている。

本実施形態の制御部１３１は、ＣＰＵが実行プログラム２７Ａを実行することで、取得部２２、分析部２３、決定部２４、設定部２５及び出力部２６として機能する。また、制御部１３１は、ＣＰＵが制御プログラム３４Ａを実行することで、最適化部３３としても機能するように形成されている。なお、各部の機能は第１の実施形態と同じである。

本実施形態の記憶部１３４には、嗜好分析処理及び行先決定処理等を実行するための実行プログラム２７Ａ、ＩＤ情報テーブル２７Ｂ、嗜好テーブル２７Ｃ、地点リストデータ２７Ｄ、行先データ２７Ｅが記憶されている。また、記憶部１３４には、ルート最適化処理等を実行するための制御プログラム３４Ａ及び履歴データ３４Ｂが記憶されている。各部の機能は第１の実施形態と同じである。

以上のように構成されるカーナビゲーション装置１３０では、嗜好分析処理、行先決定処理及びルート最適化処理のいずれもが車両１２内で完結する。そして、本実施形態によれば、上述した各実施形態と同様の作用効果を得ることができる。

［他の実施形態］
第１及び第２の実施形態では、カーナビゲーション装置３０から送信された検索開始指示又は位置情報の送信が、ルート最適化処理の実行契機とされているが（図７、図１２参照）、実行契機はこの限りではない。例えば他の形態として、センターサーバ２０に登録された携帯端末５０が車両１２の車室内に存在する場合をルート最適化処理の実行契機としてもよい。ここで、携帯端末５０が車両１２の車室内に存在するか否かの検知方法としては、Bluetooth（登録商標）等の近距離無線通信、及びＧＰＳ（Global Positioning System）等を利用することができる。

例えば、近距離無線通信を利用する場合、携帯端末５０及びカーナビゲーション装置３０はそれぞれ近距離無線通信装置を備えており、車両１２の車室内において携帯端末５０とカーナビゲーション装置３０との通信が成立した場合に、携帯端末５０が車室内に存在すると判定可能である。ここで、携帯端末５０が携帯端末５０の車室内への存在を判定した場合、検索開始指示は携帯端末５０からセンターサーバ２０に送信される。また、カーナビゲーション装置３０が携帯端末５０の車室内への存在を判定した場合、検索開始指示はカーナビゲーション装置３０からセンターサーバ２０に送信される。

また例えば、ＧＰＳを利用する場合、カーナビゲーション装置３０が備えるＧＰＳユニット３８に加えて、携帯端末５０もＧＰＳ装置を備えている。そして、車両１２を中心とする一定領域内に携帯端末５０が存在する場合に、携帯端末５０が車室内に存在すると判定可能である。ここで、携帯端末５０がカーナビゲーション装置３０の位置情報を受信し、携帯端末５０の車室内への存在を判定した場合、検索開始指示は、携帯端末５０からセンターサーバ２０に送信される。また、カーナビゲーション装置３０が携帯端末５０の位置情報を受信し、携帯端末５０の車室内への存在を判定した場合、検索開始指示は、カーナビゲーション装置３０からセンターサーバ２０に送信される。さらに、センターサーバ２０がカーナビゲーション装置３０及び携帯端末５０からそれぞれ位置情報を受信し、携帯端末５０の車室内への存在を判定した場合は、検索開始指示を要することなく、嗜好分析処理等の各処理が実行される。

このように、他の実施形態によれば、センターサーバ２０は、携帯端末５０が車両１２の車室内に存在する場合に検索開始指示をカーナビゲーション装置３０に向けて送信する。これにより、携帯端末５０を持った特定ユーザが車両１２に乗車したタイミングでルート最適化処理を実行することができる。

［その他］
第１及び第２の実施形態では行先情報検索装置としてセンターサーバ２０を、第３の実施形態では行先情報検索装置としてカーナビゲーション装置１３０を、それぞれ例示して説明した。各実施形態は、センターサーバ及びカーナビゲーション装置の各々が備える各部の機能をコンピュータに実行させるためのプログラムの形態としてもよい。実施形態は、このプログラムを記憶したコンピュータが読み取り可能な記憶媒体の形態としてもよい。

また、上記実施形態では、プログラムを実行することにより、実施形態に係る処理がコンピュータを利用してソフトウェア構成により実現される場合について説明したが、これに限らない。実施形態は、例えば、ハードウェア構成や、ハードウェア構成とソフトウェア構成との組み合わせによって実現してもよい。

また、上記実施形態で説明した処理の流れも、一例であり、主旨を逸脱しない範囲内において不要なステップを削除したり、新たなステップを追加したり、処理順序を入れ替えたりしてもよい。

その他、上記実施形態で説明した管理サーバ及び端末装置の各々の構成は、一例であり、主旨を逸脱しない範囲内において状況に応じて変更してもよい。

１０ 行先情報検索システム
１２ 車両
２０ センターサーバ（行先情報検索装置）
２２ 取得部
２３ 分析部
２４ 決定部
２５ 設定部
２６ 出力部
２７Ａ 実行プログラム（プログラム）
３０ カーナビゲーション装置（位置情報提供装置）
３３ 最適化部
３９ 表示部（報知部）
４０ ＳＮＳサーバ（管理サーバ）
５０ 携帯端末
１００ 行先情報検索システム
１３０ カーナビゲーション装置（行先情報検索装置、位置情報提供装置）

Claims (7)

1. ソーシャル・ネットワーキング・サービス（ＳＮＳ）を管理する管理サーバから投稿情報を取得する取得部と、
   前記取得した投稿情報、及び車両の現在の位置情報に基づいて前記車両の行先を決定する決定部と、
   前記決定部が決定した前記行先を行先情報として出力する出力部と、
   を備えた行先情報検索装置。
2. 前記取得部は、前記車両に乗車する特定ユーザの投稿情報を取得し、
   取得した前記特定ユーザの投稿情報を基に前記特定ユーザの嗜好を分析する分析部をさらに備え、
   前記決定部は、前記車両の現在の位置情報、及び前記特定ユーザの嗜好に基づいて前記行先を決定する請求項１に記載の行先情報検索装置。
3. 前記決定部は、
   複数の前記行先に対し前記車両の立ち寄り順を決定し、
   前記出力部は、
   前記立ち寄り順が付加された前記行先情報を出力する請求項１又は２に記載の行先情報検索装置。
4. 前記車両に乗車する特定ユーザにより前記特定ユーザの嗜好を設定可能な設定部をさらに備えた請求項１〜３の何れか１項に記載の行先情報検索装置。
5. コンピュータを、請求項１〜４の何れか１項に記載の行先情報検索装置が備える各部として機能させるためのプログラム。
6. 請求項１〜４の何れか１項に記載の行先情報検索装置と、
   前記行先情報検索装置に前記車両の現在の位置情報を送信可能な位置情報提供装置と、を備え、
   前記位置情報提供装置は、
   前記行先情報検索装置から受信した前記行先情報に基づき前記車両の走行ルートを最適化する最適化部と、
   最適化された前記走行ルートを報知する報知部と、
   を備える行先情報検索システム。
7. 請求項１〜４の何れか１項に記載の行先情報検索装置と、
   前記行先情報検索装置に登録された携帯端末と、
   前記行先情報検索装置に前記車両の現在の位置情報を送信可能な位置情報提供装置と、を備え、
   前記位置情報提供装置は、
   前記行先情報検索装置から受信した前記行先情報に基づき前記車両の走行ルートを最適化する最適化部と、
   最適化された前記走行ルートを報知する報知部と、
   を備え、
   前記行先情報検索装置は、
   前記携帯端末が前記車両の車室内に存在する場合に前記行先情報を前記位置情報提供装置に向けて送信する行先情報検索システム。