以下、図面を参照しつつ本発明の実施の形態について説明する。
<1.第1の実施の形態>
<1−1.システムの概要>
図1は、第1の実施の形態の車両用装置を含む車内通信システム10の概要を示す図である。車内通信システム10は、自動車などの車両9に搭載される車載装置2と、車載装置2とは別個に構成される携帯機器3とを備えている。
車載装置2と携帯機器3との双方は、共通の通信方式に準拠した無線通信機能を有している。したがって、車載装置2と携帯機器3とは、無線通信によって相互にデータを送受信することが可能である。なお、車載装置2と携帯機器3とを通信ケーブルで物理的に接続し、車載装置2と携帯機器3とが有線通信によって相互にデータを送受信可能となっていてもよい。
車載装置2は、車両9において主にドライバに用いられる車両用装置である。車載装置2は、例えば、ルート案内などのナビゲーション機能を実行するナビゲーション装置である。車載装置2は、ディスプレイ25を有しており、このディスプレイ25にはナビゲーション機能のための地図が表示される。
また、携帯機器3は、車両9に乗車したドライバ以外の同乗者に用いられる可搬性装置である。携帯機器3は、例えば、携帯電話、スマートフォン、PDA又はゲーム機などであり、アプリケーションの機能(以下、「アプリ機能」という。)を実行することが可能である。携帯機器3も、ディスプレイ34を有している。地図を利用するアプリ機能が実行される場合、このアプリ機能のための地図が携帯機器3のディスプレイ34に表示される。
車内通信システム10においては、車載装置2と携帯機器3とは連携して動作することが可能となっている。具体的には、車載装置2から携帯機器3に、携帯機器3のアプリ機能に向けた地図が送信される。そして、このような連携によって送信された地図が、携帯機器3において表示される。このため、携帯機器3が地図の生成に必要な地図基礎データなどを予め記憶していなくても、携帯機器3はアプリ機能に向けた地図を表示できるようになっている。
また、携帯機器3で実行されるアプリ機能は、観光案内、ゲームなどのナビゲーション機能以外の機能であってよい。このため、車内通信システム10においては、車両用装置のユーザと携帯機器のユーザとがそれぞれ、互いに異なる機能のために地図を同時に利用できるようになっている。以下、このような車内通信システム10の構成及び処理について詳細に説明する。
<1−2.車載装置の構成>
まず、ナビゲーション機能を実行する車載装置2の構成について説明する。図2は、車載装置2の構成を示す図である。車載装置2は、前述したディスプレイ25の他、車両情報センサ22、操作部23、記憶部24、無線通信部26、及び、制御部21を備えている。
ディスプレイ25は、例えば、液晶パネルなどを備えた薄型の表示装置である。ディスプレイ25は、その画面がユーザ(主にドライバ)から視認可能なように、車両9の車室内のインストルメントパネルなどに配置される。ディスプレイ25には、ナビゲーション機能に向けた地図が表示される。
車両情報センサ22は、車両9の位置を示す信号、及び、車両9の進行方向を示す信号を取得する。車両情報センサ22は、GPS受信部を含み、複数のGPS衛星から車両9の位置を示す信号を受信し、受信した信号を制御部21に入力する。また、車両情報センサ22は、方位を検知する電子コンパスを含み、車両9の前方が向く方位(すなわち、車両9の進行方向)を示す信号を取得し、取得した信号を制御部21に入力する。
操作部23は、ユーザが操作可能な操作部材である。操作部23は、複数の操作ボタンと、ディスプレイ25の画面に重ねて設けられたタッチパネルとを含む。ユーザが操作部23を操作した場合は、その操作内容を示す信号が制御部21に入力される。
記憶部24は、例えばフラッシュメモリなど、各種のデータを記憶可能な不揮発性のメモリである。記憶部24は、地図データベース241と、ファームウェアとしてのプログラム242とを記憶している。
地図データベース241は、表示に用いる地図の生成に必要な地図基礎データを含んでいる。車載装置2で実行されるナビゲーション機能に向けた地図(以下、「ナビ地図」という。)は、この地図データベース241の地図基礎データに基づいて生成される。また同様に、携帯機器3で実行されるアプリ機能に向けた地図(以下、「アプリ地図」という。)も、同一の地図データベース241の地図基礎データに基づいて生成される。これらの表示に用いるナビ地図、及び、アプリ地図はラスタデータ(画像)である。
これに対して、地図基礎データは、主にベクタデータで構成される。地図基礎データは、道路データ、スポットデータ、及び、背景データを含んでいる。道路データは、交差点等の情報を示すノード、及び、ノードとノードとの間の区間の情報を示すリンク等を含んだベクタデータである。スポットデータは、地図上の様々なスポットの種別、位置、名称、及び、アイコン等を含んでいる。また、背景データは、地形、鉄道路線、行政境界、及び、地名等を含んでいる。
地図データベース241では、このような地図基礎データが、複数の縮尺別に用意されている。本実施の形態では、例えば、「1/5000」、「1/1万」、「1/2万」、「1/4万」、「1/8万」、「1/16万」、「1/32万」、「1/64万」「1/128万」、及び、「1/256万」の10種類の縮尺の地図基礎データが地図データベース241に含まれている。
無線通信部26は、外部の通信装置と通信する。無線通信部26は、Bluetooth(登録商標)などの所定の通信方式に準拠した無線通信によって外部の通信装置と通信する。これにより、無線通信部26は、携帯機器3との間でデータの送受信を行う。
また、制御部21は、車載装置2の全体を統括的に制御するマイクロコンピュータである。制御部21は、CPU、RAM及びROMなどを備えており、記憶部24に記憶されたプログラム242に従ってCPUが演算を行うことで、各種の処理部が実現される。
車載装置2は、プログラムが記憶されたコンピュータ読み取り可能なメモリカードなどの記憶媒体8からリーダ(図示せず)を介して読み出すことで、このようなプログラム242を取得する。また、車載装置2は、ネットワーク通信部(図示せず)を介してネットワーク上の所定のサーバなどからダウンロードすることで、プログラム242を取得することもできる。
図2中に示す、車両情報取得部51、ナビ地図取得部52、ナビ地図調整部53、及び、ナビゲーション部54は、プログラム242に従ってCPUが演算を行うことで実現される処理部である。
車両情報取得部51は、車両情報センサ22から入力される信号に基づいて車両9の位置、及び、車両9の進行方向を取得する。車両情報取得部51は、車両9の位置を示す信号に基づいて車両9の位置を導出し、車両9の進行方向を示す信号に基づいて車両9の進行方向を導出する。
ナビ地図取得部52は、地図データベース241に基づいてナビ地図を取得する。ナビ地図取得部52は、地図データベース241から必要となる一の縮尺の地図基礎データを読み出す。そして、ナビ地図取得部52は、この地図基礎データに基づいて地形及び道路を含む地図画像を生成し、この地図画像に対して、地名、スポットの名称、及び、アイコン等を重畳する。これにより、ナビ地図取得部52は、ナビゲーション機能に適したナビ地図を生成する。
ナビ地図調整部53は、ナビ地図に関するパラメータを変更して、ナビ地図取得部52が生成するナビ地図の内容を調整する。より具体的には、ナビ地図調整部53は、操作部23を介したユーザの指示やナビゲーション部54の指示に従って、ナビ地図の位置、縮尺、及び、向きなどを変更する。例えば、ナビ地図調整部53は、ユーザの指示に従って、前述した10種類の縮尺の候補のいずれかに、ナビ地図の縮尺を変更する。これにより、ユーザが所望する縮尺のナビ地図が生成される。
ナビゲーション部54は、目的地までのルート案内などのナビゲーション機能を実行する。ナビゲーション部54は、ナビ地図取得部52で取得されたナビ地図に対して、自車位置マークやルートなどの情報を重畳する。自車位置マークは、車両9の現在の位置及び進行方向を示すマークであり、車両情報取得部51で得られた車両9の位置及び進行方向に基づいて重畳される。そして、ナビゲーション部54は、このナビ地図をディスプレイ25に出力して表示させる。
また、図2中に示す、車両情報送信部55、要求受信部56、アプリ地図取得部57、アプリ地図調整部58、及び、アプリ地図送信部59も、プログラム242に従ってCPUが演算を行うことで実現される処理部である。これらの処理部は、携帯機器3との連携に係る処理を行う。
車両情報送信部55は、車両情報取得部51で得られた車両9の位置、及び、車両9の進行方向を、無線通信部26を介して携帯機器3に送信する。車両情報送信部55は、車両9の位置及び進行方向を、所定の周期で繰り返し携帯機器3に送信する。
要求受信部56は、携帯機器3から送信される要求信号を無線通信部26を介して受信する。要求信号には、携帯機器3がアプリ地図を車載装置2に要求する場合に送信する地図要求信号が含まれる。この地図要求信号には、アプリ地図の位置、及び、縮尺などを指定する指定情報が含まれている。
アプリ地図取得部57は、地図要求信号に応答して、地図データベース241に基づいてアプリ地図を取得する。アプリ地図取得部57は、地図データベース241から必要となる一の縮尺の地図基礎データを読み出す。そして、アプリ地図取得部57は、この地図基礎データに基づいて地形及び道路を含む地図画像を生成し、この地図画像に対して、地名、スポットの名称、及び、アイコン等を重畳する。これにより、アプリ地図取得部57は、携帯機器3のアプリ機能に適したアプリ地図を生成する。このアプリ地図の生成手法は、ナビ地図の生成手法とは異なっており、アプリ地図とナビ地図とはその内容が異なることとなるが、詳細は後述する。
アプリ地図調整部58は、アプリ地図に関するパラメータを変更して、アプリ地図取得部57が生成するアプリ地図の内容を調整する。より具体的には、アプリ地図調整部58は、携帯機器3からの地図要求信号に含まれる指定情報に従って、アプリ地図の縮尺、及び、位置などを変更する。アプリ地図の縮尺の候補数は、ナビ地図の縮尺の候補数の「10種類」よりも少ない例えば「2種類」となっている。このため、アプリ地図調整部58は、2種類の縮尺の候補(例えば、「1/5000」及び「1/128万」)のいずれかに、アプリ地図の縮尺を変更する。
アプリ地図送信部59は、地図要求信号に応答してアプリ地図取得部57で取得されたアプリ地図を、無線通信部26を介して携帯機器3に送信する。これにより、アプリ機能に適したアプリ地図が携帯機器3に送信される。
<1−3.携帯機器の構成>
次に、アプリ機能を実行する携帯機器3の構成について説明する。図3は、携帯機器3の構成を示す図である。携帯機器3は、前述したディスプレイ34の他、操作部32、無線通信部35、記憶部33、及び、制御部31を一の筐体内に備えている。
ディスプレイ34は、例えば、液晶パネルなどを備えた薄型の表示装置である。ディスプレイ34には、アプリ機能に向けた地図などが表示される。
操作部32は、ユーザが操作可能な操作部材である。操作部32は、複数の操作ボタンと、ディスプレイ34の画面に重ねて設けられたタッチパネルとを含む。ユーザは、自分の指やタッチペンなどでタッチパネルに触れることで各種の操作(タップ、ドラッグ等)を行うことができる。ユーザが操作部23を操作した場合は、その操作内容を示す信号が制御部31に入力される。
無線通信部35は、外部の通信装置と通信する。無線通信部35は、Bluetooth(登録商標)などの所定の通信方式に準拠した無線通信によって外部の通信装置と通信する。これにより、無線通信部35は、車載装置2との間でデータの送受信を行う。無線通信部35は、車両9の位置、車両9の進行方向、及び、アプリ地図などを車載装置2から受信する。
記憶部33は、例えばフラッシュメモリなど、各種のデータを記憶可能な不揮発性のメモリである。記憶部33は、アプリケーションのプログラム331を記憶している。なお、記憶部33をメモリカードなどの可搬性の記憶媒体として構成し、記憶部33が携帯機器3に対して着脱可能となっていてもよい。
また、制御部31は、携帯機器3の全体を統括的に制御するマイクロコンピュータである。制御部31は、CPU、RAM及びROMなどを備えている。記憶部33に記憶されたアプリケーションのプログラム331に従ってCPUが演算を行うことで、各種の処理部が実現される。図中に示すアプリケーション部37は、プログラム331に従ってCPUが演算を行うことで実現される処理部である。
アプリケーション部37は、地図を利用するアプリ機能を実行する。このような地図を利用するアプリ機能は、例えば、観光案内、クイズゲーム、及び、宝探しゲームなどである。観光案内は、地図上に存在する観光地や施設などの各種スポットについての情報をユーザに提供するものである。クイズゲームは、地図上に存在する観光地や施設などの各種スポットに関するクイズをユーザに出題するものである。また、宝探しゲームは、地図上のランダムな位置に仮想的に宝箱スポットを設定し、ユーザにその宝箱スポットを探し出させるものである。
アプリケーション部37は、このようなアプリ機能を実行する場合に、携帯機器3から提供されたアプリ地図をディスプレイ25に表示させる。アプリケーション部37は、このアプリ地図を携帯機器3に要求する地図要求部371を備えている。地図要求部371は、アプリ地図の要求の要否を判断してアプリ地図の要求が必要な場合は、無線通信部35を介して地図要求信号を車載装置2に送信する。この地図要求信号には、アプリ機能において必要なアプリ地図の位置、及び、縮尺などを指定する指定情報が含まれている。
<1−4.地図>
次に、表示に用いられる地図(ナビ地図、及び、アプリ地図)についてより詳細に説明する。図4は、車載装置2に表示されたナビ地図M1の一例を示す図である。また、図5は、携帯機器3に表示されたアプリ地図M2の一例を示す図である。
図4のナビ地図M1と図5のアプリ地図M2とは、同一の位置を示している。図4と図5とを比較して分かるように、アプリ地図M2は、ナビ地図M1よりも情報量が少なくなっており内容が簡略化されている。
ナビ地図M1は、ナビゲーション機能に向けたものであるため、ドライバが運転中に必要な道路や地名等の各種の情報を含む詳細な地図となっている。これに対して、アプリ地図M2は、例えば、観光案内やゲームなどのエンターテイメント用のアプリ機能に向けたものである。このため、アプリ地図M2は、主要道路を強調しつつ、細い道路やスポット名などの一部の情報が省略され適宜にイラストを含むアイコンなどを利用した親しみやすい地図となっている。
前述したように、ナビ地図M1とアプリ地図M2とは、同一の地図データベース241の地図基礎データに基づいて生成される。ナビ地図取得部52は、地図基礎データに含まれる各種データの大部分を用いて詳細なナビ地図M1を生成する。これに対して、アプリ地図取得部57は、地図基礎データに含まれる各種データの一部のみを用いるとともに、文字情報等に変えて専用のアイコンなどを利用してアプリ地図M2を生成する。これにより、ナビ地図M1とアプリ地図M2とはその内容が異なることとなる。
前述のように、ナビ地図取得部52は、ユーザの指示に従って、10種類の候補のいずれかの縮尺のナビ地図M1を生成する。これに対して、アプリ地図取得部57は、地図要求信号に従って、2種類のみの候補のいずれかの縮尺のアプリ地図M2を生成することになる。
また、ナビ地図取得部52は、表示に用いるナビ地図M1として向きが異なる地図を生成することが可能となっている。図6は、ナビ地図M1の向きを説明するための図である。図6の上部は、地表上の一方位である「北」を上にする向き(ノースアップ)のナビ地図M1であるノースアップ地図M1aを示している。一方、図6の下部は、車両9の進行方向を上にする向き(ヘディングアップ)のナビ地図M1であるヘディングアップ地図M1bを示している。このようなナビ地図M1の向きは、ユーザの指示に従ってナビ地図調整部53が変更する。
図7は、ノースアップ地図M1aを生成する手法を説明する図である。また、図8は、ヘディングアップ地図M1bを生成する手法を説明する図である。これらの図において、車両9の位置Pvに付された矢印は、車両9の進行方向を示している。
ナビ地図取得部52は、まず、車両9の位置Pvを含む、ディスプレイ25の表示サイズよりも広いナビ地図M1である広域地図M11を生成する。より具体的には、ディスプレイ25の表示サイズに相当する領域を一つのブロックとした場合、ナビ地図取得部52は、横3ブロック×縦3ブロックの合計9ブロックに相当する広域地図M11を生成する。これら9ブロックの中心の1ブロックに車両9の位置Pvが含まれている。例えば、ディスプレイ25の表示サイズ(解像度)がVGA(横640×縦480画素)である場合、横1920画素×縦1440画素の広域地図M11が生成される。この広域地図M11の向きは、「北」が上となる向き(ノースアップ)となっている。生成された広域地図M11は、制御部21のRAMに記憶される。
そして、ナビ地図取得部52は、ノースアップ地図M1aを生成する場合は、図7に示すように、広域地図M11から、そのままの向きで車両9の位置Pvを中心とした表示サイズ分の表示領域VA1を切り出す。これにより、ノースアップ地図M1aが生成される。
一方、ナビ地図取得部52は、ヘディングアップ地図M1bを生成する場合は、図8に示すように、広域地図M11から、車両9の進行方向が上となる向きで車両9の位置Pvを中心とした表示サイズ分の表示領域VA1を切り出す。これにより、ヘディングアップ地図M1bが生成される。
これに対して、アプリ地図取得部57は、アプリ地図M2として、「北」を上にする向き(ノースアップ)の地図のみを生成する。すなわち、携帯機器3に表示されるアプリ地図M2の向きはノースアップに固定される。図9は、アプリ地図取得部57が生成するアプリ地図M2を示す図である。
アプリ地図取得部57は、携帯機器3のディスプレイ34の表示サイズよりも広いアプリ地図M2を生成する。生成されるアプリ地図M2の中心位置Pcは、指定情報が指定する位置とされる。
このアプリ地図M2のサイズは、携帯機器3のディスプレイ34の表示サイズに対して、縦横それぞれ2倍となっている。例えば、ディスプレイ25の表示サイズ(解像度)がQVGA(横320×縦240画素)である場合、アプリ地図M2のサイズは横640画素×縦480画素となる。このアプリ地図M2の向きは、ノースアップとなっている。
アプリ地図取得部57に生成されたアプリ地図M2は携帯機器3に送信され、制御部31のRAMに記憶される。携帯機器3のアプリケーション部37は、このアプリ地図M2から、そのままの向きで表示サイズ分の表示領域VA2を切り出す。そして、このようにして切り出された部分のアプリ地図M2が、ディスプレイ34に表示される。
表示領域VA2は、通常は、車両9の位置を中心とする範囲とされる。したがって、車両9の位置の変化に応じて、アプリケーション部37は、表示領域VA2の範囲を変更する。
図10は、車両9の位置Pvに応じた表示領域VA2の範囲の遷移を示す図である。状態ST1においては、アプリ地図M2の中心位置Pcと、車両9の位置Pvとが一致している。したがって、この場合は、表示領域VA2は、アプリ地図M2の中心位置Pc(すなわち、車両9の位置Pv)を中心とした範囲となっている。
そして、状態ST2のように、車両9が移動して車両9の位置Pvが変化すると、この車両9の位置Pvに合わせて表示領域VA2の範囲が変更される。すなわち、移動後の車両9の位置Pvを中心とした範囲に表示領域VA2が変更されることになる。
アプリ地図M2のサイズはディスプレイ34の表示サイズよりも大きいため、アプリ地図M2の範囲内では表示領域VA2の範囲を容易に変更できる。このため、このように車両9の移動に合わせて表示領域VA2の範囲を変更する場合であっても、車両9の移動のたびに新たなアプリ地図M2を車載装置2から携帯機器3に送信する必要がない。したがって、表示領域VA2を変更する場合に、変更後の表示領域VA2の範囲のアプリ地図M2を速やかに表示できる。
また、状態ST3のように、車両9がさらに移動して表示領域VA2の端部が、RAMに記憶されたアプリ地図M2の端部に近接した場合は、携帯機器3の地図要求部371が、新たなアプリ地図M2を要求する地図要求信号を車載装置2に送信する。この地図要求信号には、アプリ地図M2の位置として、その時点の車両9の位置Pvを指定する指定情報が含まれる。
これにより、状態ST4のように、その時点の車両9の位置Pvを中心位置Pcとする新たなアプリ地図M2が、車載装置2から携帯機器3に送信される。なお、この場合、携帯機器3のRAMに記憶された古いアプリ地図M2Lと新たなアプリ地図M2との差分の領域(図中、ハッチングで示す領域)のみを、車載装置2から携帯機器3へ送信するようにしてもよい。
なお、図10では、表示領域VA2の範囲が車両9の位置Pvに合わせて変更される場合について説明したが、携帯機器3においては、ユーザがタッチパネルにスクロール指示の操作を行った場合にも表示領域VA2の範囲が変更される。この場合、車両9の位置Pvとは無関係に、アプリ地図M2がスクロールされる。
このようなスクロール指示の操作がなされた場合において、スクロール後の表示領域VA2とすべき範囲が、RAMに記憶されたアプリ地図M2から外れる場合においても、地図要求部371が新たなアプリ地図M2を要求する地図要求信号を車載装置2に送信する。この地図要求信号には、アプリ地図M2の位置としてスクロール後の表示領域VA2とすべき範囲の中心を指定する指定情報が含まれる。これにより、指定情報が指定した位置を中心位置Pcとする新たなアプリ地図M2が、車載装置2から携帯機器3に送信されることになる。なお、指定情報が指定するアプリ地図M2の位置は、その時点の車両9の位置Pvのような位置情報に限るものではなく、アプリ地図M2の外縁などであってもよい。
<1−5.処理の流れ>
次に、車内通信システム10の処理の流れについて説明する。図11は、車内通信システム10の処理の流れを示す図である。図中の左側は車載装置2の処理の流れを示しており、図中の右側は携帯機器3の処理の流れを示している。これらの処理は、車載装置2と携帯機器3との間で通信が確立した以降に、それぞれの装置において所定の周期(例えば、1/10秒)で繰り返し実行される。また、車載装置2と携帯機器3との間で通信を確立した際(図11の処理の開始前)には、その時点の車両9の位置を中心とするアプリ地図M2が車載装置2から携帯機器3に送信され、携帯機器3のRAMに記憶されているものとする。
車載装置2においては、まず、車両情報取得部51が、車両情報センサ22から入力される信号に基づいて車両9の位置及び進行方向を取得する(ステップS11)。車両情報取得部51は、取得した車両9の位置及び進行方向を、ナビゲーション部54、ナビ地図調整部53、及び、車両情報送信部55に出力する。
次に、車両情報送信部55が、車両9の位置及び進行方向を無線通信部26を介して携帯機器3に送信する(ステップS12)。
また、ディスプレイ25が、ナビゲーション機能に向けたナビ地図M1を表示する(ステップS13)。具体的には、まず、ナビ地図調整部53が、ナビ地図取得部52が生成するナビ地図M1のパラメータを調整する。ナビ地図調整部53は、車両9の位置に応じてナビ地図M1の位置を調整するとともに、表示するナビ地図M1の向きがヘディングアップの場合は車両9の進行方向に応じてナビ地図M1の向きを調整する。また、ナビ地図調整部53は、操作部23を介してユーザからナビ地図M1の縮尺や向きの変更の指示がなされた場合は、ユーザの指示に従ってナビ地図M1の縮尺や向きを変更する。
そして、ナビ地図取得部52が、ナビ地図調整部53で調整されたパラメータに従って、表示すべきナビ地図M1を生成する。さらに、ナビゲーション部54が、生成されたナビ地図M1に自車位置マークなどを重畳した後、ナビ地図M1をディスプレイ25に出力する。これにより、ディスプレイ25に、ナビゲーション機能に向けたナビ地図M1が表示される。
また、ナビゲーション部54は、ナビゲーション機能を実行する(ステップS14)。例えば、ナビゲーション部54は、車両9の位置に応じて曲がるべき交差点などをユーザに案内する。
車載装置2は、携帯機器3から地図要求信号を受信しない場合は(ステップS16にてNo)、このようなステップS11〜S14の処理を所定の周期で繰り返す。したがって、ステップS12が繰り返され、車両情報送信部55は、車両9の位置及び進行方向を所定の周期で繰り返し携帯機器3に送信することになる。これにより、携帯機器3には、その時点の車両9の位置及び進行方向がほぼリアルタイムに伝達される。
一方、携帯機器3においては、まず、無線通信部35が、車載装置2から送信された車両9の位置及び進行方向を受信する(ステップS21)。
次に、ディスプレイ34が、アプリ機能に向けたアプリ地図M2を表示する(ステップS22)。具体的には、アプリケーション部37が、RAMに記憶されたアプリ地図M2から表示すべき範囲の表示領域VA2を切り出し、表示用のアプリ地図M2を生成する。そして、アプリケーション部37は、このアプリ地図M2の車両9の位置に車両9の進行方向へ向けて自車位置を示す自車位置マークを重畳する。この自車位置マークは、ナビ地図M1に重畳されるものとは異なる自動車のイラストのようなマークとされる。さらに、アプリケーション部37は、このアプリ地図M2にアプリ機能に必要なアイコンや文字情報等を重畳した後、アプリ地図M2をディスプレイ34に出力する。これにより、ディスプレイ34にアプリ機能に向けたアプリ地図M2が表示される。
また、アプリケーション部37は、例えば、観光案内、クイズゲーム、宝探しゲームなどの地図を利用するアプリ機能を実行する(ステップS23)。
携帯機器3には、その時点の車両9の位置がほぼリアルタイムに伝達されていることから、アプリケーション部37は、このようなアプリ機能として、その時点の車両9の位置に応じた機能を提供することができる。例えば、アプリ機能がクイズゲームの場合においては、車両9の位置の周囲の一定範囲に存在するスポットに関するクイズをユーザに出題することができる。この場合は、例えば、クイズを出題可能なスポットの地図上の位置にアイコンが配置され、このアイコンにユーザが触れた場合に、当該スポットのクイズが出題される。
また、このようなアプリ機能を実行している状態において、地図要求部371が、新たなアプリ地図M2の要求の要否を判断する(ステップS24)。地図要求部371は、以下の(a)〜(c)の場合などにおいて、新たなアプリ地図M2の要求が必要と判断する。
(a)車両9の移動により、表示領域VA2の端部がRAMに記憶されたアプリ地図M2の端部に近接した場合。
(b)スクロール指示の操作により、表示領域VA2とすべき範囲がRAMに記憶されたアプリ地図M2から外れる場合。
(c)アプリ機能において縮尺の変更が必要となった場合。
地図要求部371が、新たなアプリ地図M2の要求が不要と判断した場合は(ステップS25にてNo)、処理は終了する。一方、地図要求部371が、新たなアプリ地図M2の要求が必要と判断した場合は(ステップS25にてYes)、無線通信部35を介して地図要求信号を車載装置2に送信する。この地図要求信号には、必要なアプリ地図M2の位置、及び、縮尺などを指定する指定情報が含まれる(ステップS26)。
このようにして携帯機器3から送信された地図要求信号は、車載装置2の要求受信部56により受信される(ステップS15)。
このように要求受信部56が携帯機器3から地図要求信号を受信した場合は(ステップS16にてYes)、要求受信部56は、この地図要求信号に含まれる指定情報をアプリ地図調整部58に入力する。これとともに、要求受信部56は、地図要求信号をアプリ地図取得部57に入力する。
次に、この地図要求信号に応答して、新たなアプリ地図M2が生成される(ステップS17)。具体的には、まず、アプリ地図調整部58が、アプリ地図取得部57が生成するアプリ地図M2のパラメータを調整する。アプリ地図調整部58は、指定情報が指定する位置及び縮尺に従ってアプリ地図M2の位置及び縮尺を変更する。そして、アプリ地図取得部57が、このようなアプリ地図調整部58で調整されたパラメータに従って、新たなアプリ地図M2を生成する。
次に、アプリ地図送信部59が、生成された新たなアプリ地図M2を、無線通信部26を介して携帯機器3に送信する(ステップS18)。これにより、ディスプレイ25においてナビ地図M1の表示中に、携帯機器3から指定された位置のアプリ地図M2が携帯機器3に送信される。このアプリ地図M2の位置は、その時点でディスプレイ25に表示中のナビ地図M1の位置とは無関係な位置とすることができる。
送信された新たなアプリ地図M2は、携帯機器3の無線通信部35により受信される(ステップS27)。受信された新たなアプリ地図M2は、制御部31のRAMに記憶され、以降の処理に利用されることになる。
以上のように、第1の実施の形態の車載装置2では、ディスプレイ25が、車載装置2で実行されるナビゲーション機能に向けたナビ地図M1を表示する。また、このようにディスプレイ25がナビ地図M1を表示中に、アプリ地図送信部59が、携帯機器3で実行されるアプリ機能に向けたアプリ地図M2を携帯機器3に送信する。このため、車載装置2のユーザはナビゲーション機能のためにナビ地図M1を利用でき、同時に、携帯機器3のユーザはアプリ機能のためにアプリ地図M2を利用できる。すなわち、車載装置2のユーザと携帯機器3のユーザとがそれぞれ、互いに異なる機能のために地図を同時に利用することができる。
また、車両情報送信部55が、車両9の位置を所定の周期で携帯機器3に送信する。このため、その時点の車両9の位置がほぼリアルタイムに携帯機器3に伝達され、携帯機器においてその時点の車両9の位置に応じたアプリ機能を提供できる。
また、アプリ地図送信部59は、携帯機器3から送信された地図要求信号に含まれる指定情報が指定する位置のアプリ地図M2を携帯機器3に送信する。このため、その時点で車載装置2において表示されているナビ地図M1の位置とは無関係に、携帯機器3において必要とする位置のアプリ地図M2を携帯機器3において利用することができる。
また、アプリ地図送信部59は、携帯機器3が有するディスプレイ34の表示サイズよりも大きなサイズのアプリ地図M2を携帯機器3に送信する。このため、表示領域VA2を変更する場合であっても、新たなアプリ地図M2を車載装置2から携帯機器3に送信する必要がない。このため、変更後の表示領域VA2の範囲のアプリ地図M2を速やかに表示できる。
また、ナビ地図M1とアプリ地図M2とは、共通の地図データベース241に基づいて取得される。このため、ナビ地図M1のための地図データベースと、アプリ地図M2のための地図データベースとをそれぞれ個別に準備する必要がなく、地図データベースを記憶する記憶部24に必要な記憶容量を低減できる。
また、ナビ地図M1の向きはヘディングアップとノースアップとのいずれかに変更可能である一方で、アプリ地図M2の向きはノースアップに固定される。このように、アプリ地図M2の向きをノースアップに固定することで、車両9の進行方向が変わるたびに、新たなアプリ地図M2を車載装置2から携帯機器3に送信する必要がない。このため、車載装置2から携帯機器3に送信するデータ量を低減できる。また、携帯機器3を扱うユーザが子供である場合には、アプリ地図M2の向きが一般的なノースアップとなるため、ユーザはアプリ地図M2が示す情報を理解しやすくなる。
<2.第2の実施の形態>
次に、第2の実施の形態について説明する。第1の実施の形態では、ナビ地図M1とアプリ地図M2とは、共通の地図データベース241に基づいて取得されていた。これに対して、第2の実施の形態では、ナビ地図M1とアプリ地図M2とは、それぞれ専用の地図データベースに基づいて取得されるようになっている。第2の実施の形態の車内通信システム10の構成及び処理は第1の実施の形態とほぼ同様であるため、以下、第1の実施の形態との相違点を中心に説明する。
図12は、第2の実施の形態の車載装置2の構成を示す図である。第2の実施の形態の車載装置2は、第1の実施の形態の記憶部24に変えて、2つの記憶部24a、24bを備えている。これら2つの記憶部24a,24bは、例えばフラッシュメモリなど、各種のデータを記憶可能な不揮発性のメモリである。
第1記憶部24aは、ナビ地図データベース243と、プログラム242とを記憶している。一方、第2記憶部24bは、アプリ地図データベース244を記憶している。ナビ地図データベース243は、ナビ地図M1専用の地図データベースであり、ナビ地図M1の生成に必要な地図基礎データを含んでいる。一方、アプリ地図データベース244は、アプリ地図M2専用の地図データベースであり、アプリ地図M2の生成に必要な地図基礎データを含んでいる。
このため、ナビ地図取得部52は、ナビ地図データベース243に基づいてナビ地図M1を取得することになる。一方、アプリ地図取得部57は、アプリ地図データベース244に基づいてアプリ地図M2を取得する。このように、本実施の形態においては、ナビ地図M1とアプリ地図M2とが異なる地図データベースに基づいて取得されるため、ナビゲーション機能とは無関係に、携帯機器3のアプリ機能に最適化したアプリ地図M2を容易に取得することができる。
また、第1の実施の形態と同様に、ナビ地図調整部53は、10種類の縮尺の候補のいずれかにナビ地図M1の縮尺を変更する。一方で、アプリ地図調整部58は、10種類のよりも少ない2種類の縮尺の候補のいずれかにアプリ地図M2の縮尺を変更する。
地図データベース243,244では、地図基礎データが縮尺別に用意される。したがって、図13に示すように、ナビ地図データベース243では、10種類の縮尺に対応する地図基礎データBd1が含まれている。これに対して、アプリ地図データベース244では、2種類の縮尺のみに対応する地図基礎データBd2が含まれている。このように、アプリ地図のM2の縮尺の候補が10種類より少ない2種類であるため、アプリ地図データベース244のデータ量を少なくすることができる。したがって、記憶部24bとして必要となる記憶容量を低減することができる。
なお、本実施の形態では、ナビ地図データベース243を記憶する記憶部とアプリ地図データベース244を記憶する記憶部とは異なっていたが、同一の記憶部がこれら2つの地図データベース243,244の双方を記憶するようにしてもよい。
また、本実施の形態においても、アプリ地図M2の向きはノースアップに固定される。このため、主にベクタデータである地図基礎データではなく、そのまま地図として利用可能なラスタデータを、アプリ地図データベース244が含むようにしてもよい。このようにすれば、アプリ地図M2を生成する処理を、省略あるいは簡略化することができる。
<3.第3の実施の形態>
次に、第3の実施の形態について説明する。上記実施の形態では、音の出力についての説明を行わなかったが、音の出力に関しても車載装置2と携帯機器3とで連携することが可能である。本実施の形態では、車載装置2と携帯機器3との連携による音の出力について説明する。なお、以下の説明では、車載装置2と携帯機器3との連携による地図の表示については詳細には言及しないが、地図の表示については第1あるいは第2の実施の形態のいずれかと同様の構成を採用し同様の処理を実行すればよい。
<3−1.車載装置の構成>
まず、第3の実施の形態の車載装置2の構成について説明する。図14は、第3の実施の形態の車載装置2の構成を示す図である。図14においては、車載装置2の構成のうち、音の出力に関連する構成を主に示している。
車載装置2は、第1の実施の形態と同様のディスプレイ25、操作部23、記憶部24、無線通信部26、及び、制御部21の他に、放送受信部27、ディスク読取部28及び複数のスピーカ29を備えている。
放送受信部27は、放送信号に基づく音の音声信号を取得する。放送受信部27は、アンテナを備えており、アンテナで受信したラジオ放送などの放送信号をデコードし、放送内容となる音の音声信号を取得して制御部21に入力する。
ディスク読取部28は、音声ディスクに基づく音の音声信号を取得する。ディスク読取部28は、CDなどの音声ディスクを読み取り、音声ディスクの記録内容となる音の音声信号を取得して制御部21に入力する。
複数のスピーカ29は、制御部21からの信号に基づいて車室内に音を出力する。車両9においては、例えば、前席の左右、及び、後席の左右にそれぞれスピーカ29が配置され、車室内に合計4つのスピーカ29が設けられている。
車載装置2は、複数のスピーカ29を介して、様々なソースの音を車室内に出力することが可能となっている。車載装置2は、出力する音のソースが互いに異なる複数の音声モードを備えている。複数の音声モードには、「放送モード」、「ディスクモード」及び「連携モード」が含まれている。
「放送モード」は、放送信号に基づく音を出力するための音声モードである。「ディスクモード」は、音声ディスクに基づく音を出力するための音声モードである。また、「連携モード」は、携帯機器3で実行されるアプリ機能に関係する音を出力するための音声モードである。したがって、放送モード及びディスクモードでは、アプリ機能に関係する音はスピーカ29から出力されない。連携モードでは、例えば、アプリ機能に係る音として、効果音、操作音、及び、BGMなどが出力される。連携モードでは、アプリ機能に係る音が車室内のスピーカから出力されるため、アプリ機能を実行する場合において臨場感のある音響効果を得ることができる。
このようなアプリ機能に関係する音に必要な音声データは、予め記憶部24に記憶される。本実施の形態の記憶部24は、音声データベース245を記憶している。この音声データベース245は、アプリ機能に係る音に必要な音声データを含んでいる。
また、制御部21は、プログラム242に従ってCPUが演算を行うことで実現される処理部として、ナビゲーション部54及び要求受信部56の他に、音声出力部61、音声取得部62、モード変更部63、モード送信部64、無効化受付部65及び無効状態送信部66を備えている。
音声出力部61は、複数のスピーカ29を介して、その時点の音声モードに応じた音を出力する。放送モードにおいては、音声出力部61は、放送受信部27から入力される音声信号に基づいて放送信号に基づく音を出力する。ディスクモードにおいては、音声出力部61は、ディスク読取部28から入力される音声信号に基づいて音声ディスクに基づく音を出力する。また、連携モードにおいては、音声取得部62から入力される音声信号に基づいて、携帯機器3で実行されるアプリ機能に関係する音を出力する。
また、音声出力部61は、音像を車室内の任意の位置に定位させることができる。音声出力部61は、複数のスピーカ29のそれぞれから出力する音の音量及び位相などを調整することで、車室内の任意の位置に音像を定位させる。このように音像を車室内のある位置に定位させた場合は、車両9の乗員は音像が定位した位置から音が聞こえてくると認識することになる。
音声取得部62は、音声データベース245に基づいて、アプリ機能に関係する音の音声信号を取得する。アプリ機能に関係する音の出力が必要な場合には、携帯機器3から音出力要求信号が送信され、この音出力要求信号は車載装置2の要求受信部56によって受信される。音出力要求信号には、車載装置2で出力すべき音、音量、及び、音像を定位させる位置などを指定する指定情報が含まれている。音声取得部62は、この指定情報に基づいて、出力すべき音の音声データを音声データベースDB245から読み出す。そして、音声取得部62は、読み出した音声データをデコードして音声信号を取得し、制御部21に入力する。
モード変更部63は、音声モードを、放送モード、ディスクモード及び連携モードの3つの候補のいずれかに変更する。モード変更部63は、操作部23を介したユーザの指示に応じて音声モードを変更する。モード変更部63は、変更後の音声モードを音声出力部61に出力する。これにより、音声出力部61は、その時点の音声モードに応じた音をスピーカ29を介して出力することになる。
モード送信部64は、モード変更部63により音声モードが変更された場合に、変更後の音声モードを示すモード信号を、無線通信部26を介して携帯機器3に送信する。
無効化受付部65は、音声出力部61の音の出力機能を無効化、あるいは、有効化する。車載装置2は、いわゆるミュート機能を備えており、ユーザの所望により音を無音とする(音の出力機能を無効化する)ことが可能である。音の出力機能が無効化されると、スピーカ29から音が出力されなくなる。無効化受付部65は、操作部23を介したユーザの指示に応じて、音の出力機能の無効/有効を切り替える。
無効化受付部65は、音声モードが放送モード、ディスクモード及び連携モードのいずれの場合においても、音の出力機能の無効化、あるいは、有効化が可能である。音声モードが連携モードの場合に音の出力機能の無効化されると、アプリ機能に関係する音がスピーカ29から出力されなくなる。
無効状態送信部66は、音声出力部61の音の出力機能の無効/有効が変更された場合に、有効無効信号を無線通信部26を介して携帯機器3に送信する。この有効無効信号は、音声出力部61の音の出力機能の無効/有効を示す。例えば、音声出力部61の音の出力機能が無効化された場合は、有効無効信号は音の出力機能が無効化されたことを示すことになる。
<3−2.携帯機器の構成>
次に、第3の実施の形態の携帯機器3の構成について説明する。図15は、第3の実施の形態の携帯機器3の構成を示す図である。図15においては、携帯機器3の構成のうち、音の出力に関連する構成を主に示している。
携帯機器3は、第1の実施の形態と同様のディスプレイ34、操作部32、無線通信部35、記憶部33、及び、制御部31の他に、内蔵スピーカ36を備えている。
内蔵スピーカ36は、携帯機器3の筐体内に設けられたスピーカである。内蔵スピーカ36は、制御部31からの信号に基づいて音を出力する。携帯機器3は、この内蔵スピーカ36を介してアプリ機能に関係する音を自装置から出力することが可能である。
また、アプリ機能を実行するアプリケーション部37は、音出力変更部372を備えている。音出力変更部372は、アプリ機能に関係する音を、車載装置2のスピーカ29から出力するか、内蔵スピーカ36から出力するかを変更する。
車載装置2の音声モードが連携モードの場合は、音出力変更部372は、原則として、アプリ機能に関係する音を車載装置2のスピーカ29から出力させる。この場合は、音出力変更部372は、無線通信部35を介して音出力要求信号を車載装置2に送信する。この音出力要求信号には、車載装置2で出力すべき音などを指定する指定情報が含まれている。
また、このように車載装置2のスピーカ29からアプリ機能に関係する音を出力させる場合は、内蔵スピーカ36から同一の音の出力は停止される。すなわちこの場合、アプリ機能に関係する音は、車載装置2のスピーカ29のみから出力されることになる。このため、携帯機器3の内蔵スピーカ36と車載装置2のスピーカ29とから同一の音が出力されて、適切な音響効果が得られなくなる現象(音像が定位する位置がずれるなど)が防止される。
また、車載装置2の音声モードが連携モードの以外の場合は、アプリ機能に関係する音が車載装置2のスピーカ29から出力されない。このため、この場合は、音出力変更部372は、アプリ機能に関係する音を内蔵スピーカ36から出力させるなどの対応をとる。
また、車載装置2の音声モードが連携モードの場合であっても、音声出力部61の音の出力機能が無効化された場合は、アプリ機能に関係する音が車載装置2のスピーカ29から出力されない。このため、この場合においても、音出力変更部372は、アプリ機能に関係する音を内蔵スピーカ36から出力させる。
このように携帯機器3は、車載装置2におけるアプリ機能に関係する音の出力状態に応じて、音の出力に関する動作を変更することが可能となっている。
<3−3.処理の流れ>
次に、第3の実施の形態の車内通信システム10の処理の流れを説明する。
まず、車載装置2の処理について説明する。図16は、車載装置2の音の出力に関する処理の流れを示す図である。この処理は、図11に示す地図の表示に関する処理とは独立して実行される。また、図16に示す処理は、所定の周期(例えば、1/10秒)で繰り返される。図16の処理の前には、車載装置2と携帯機器3との間で通信が確立しているものとする。
図16に示す処理が繰り返される間に、携帯機器3から音出力要求信号が送信された場合は、ステップS31において、要求受信部56がこの音出力要求信号を受信する。携帯機器3から音出力要求信号が送信されなかった場合は、このような受信処理はなされない。
ステップS32においては、音声出力部61は、音声出力部61の音の出力機能の無効/有効を判断する。音声出力部61の音の出力機能が無効化されている場合は(ステップS32にてNo)、音声出力部61が音を出力せずに、処理はそのままステップS37へ進む。これに対し、音声出力部61の音の出力機能が有効化されている場合は(ステップS32にてYes)、音声出力部61が音声モードに応じた処理を行ってから、処理はステップS37へ進む。
音声出力部61の音の出力機能が有効化されている場合は、まず、音声出力部61が音声モードがいずれであるかを判断する(ステップS33)。音声モードが連携モードではない場合(ステップS33にてNo)は、音声出力部61は、その時点の音声モードに応じた音を車両9の車室内に出力する。すなわち、音声出力部61は、放送モードの場合は放送信号に基づく音を出力し、ディスクモードの場合は音声ディスクに基づく音を出力する(ステップS36)。
一方、音声モードが連携モードの場合(ステップS33にてYes)は、音声出力部61は、ステップS31において音出力要求信号を受信したか否かを判断する(ステップS34)。音出力要求信号を受信していた場合は、音声出力部61は、その音出力要求信号に応じたアプリ機能に関係する音を車両9の車室内に出力する(ステップS35)。
具体的には、まず、音声取得部62が、音出力要求信号に含まれる指定情報に基づいて、出力すべきアプリ機能に関係する音の音声データを音声データベースDB245から読み出し、その音声データをデコードして音声信号を取得する。次に、音声出力部61が、音声取得部62が取得した音声信号に基づいて、アプリ機能に関係する音(効果音、操作音、及び、BGMなど)をスピーカ29を介して出力する。
前述のように、車載装置2においては、携帯機器3のアプリ機能に関係する音の音声データが予め記憶部24に記憶されている。このため、アプリ機能に関係する音を車載装置2から出力する場合であっても、携帯機器3から車載装置2に比較的データ量の多い音声データを送信する必要はない。このため、携帯機器3から車載装置2に送信するデータ量を低減することができる。
また、ステップS37においては、モード変更部63が、音声モードを変更するユーザの指示が操作部23を介してなされたか否かを判定する。音声モードの変更の指示がない場合は(ステップS37にてNo)、処理はそのままステップS39へ進む。
一方、音声モードの変更の指示がある場合は(ステップS37にてYes)、モード変更部63が、この指示に応じて音声モードを変更する。これとともに、モード送信部64が、変更後の音声モードを示すモード信号を、無線通信部26を介して携帯機器3に送信する(ステップS38)。その後、処理はステップS39へ進む。
また、ステップS39においては、無効化受付部65が、音の出力機能の無効/有効を切り替えるユーザの指示が操作部23を介してなされたか否かを判定する。音の出力機能の有効/無効の切替の指示がない場合は(ステップS39にてNo)、処理はそのまま終了する。
一方、音の出力機能の有効/無効の切替の指示がある場合は(ステップS39にてYes)、無効化受付部65が、この指示に応じて音声出力部61の音の出力機能を有効化、あるいは、無効化する。これとともに、無効状態送信部66が、音声出力部61の音の出力機能の無効/有効を示す有効無効信号を、無線通信部26を介して携帯機器3に送信する(ステップS40)。その後、処理は終了する。
次に、携帯機器3の処理について説明する。図17は、携帯機器3の音の出力に関する処理の流れを示す図である。この処理は、図11に示す地図の表示に関する処理とは独立して実行される。また、図17に示す処理は、所定の周期(例えば、1/10秒)で繰り返される。また、車載装置2と携帯機器3との間で通信を確立した際(図17の処理の開始前)には、その時点の音声モードを示すモード信号、及び、その時点の音の出力機能の無効/有効を示す有効無効信号が車載装置2から携帯機器3に送信されるものとする。
図17に示す処理が繰り返される間に、車載装置2からモード信号が送信された場合は、ステップS51において、無線通信部35がこのモード信号を受信する。また、車載装置2から有効無効信号が送信された場合は、ステップS52において、無線通信部35がこの有効無効信号を受信する。車載装置2からいずれの信号も送信されなかった場合は、このような受信処理はなされない。
ステップS53においては、アプリケーション部37が、実行中のアプリ機能において、効果音、操作音、及び、BGMなどのアプリ機能に関係する音の出力が必要か否かを判定する。アプリ機能に関係する音の出力が不要な場合は、そのまま処理は終了する(ステップS53にてNo)。
一方、アプリ機能に関係する音の出力が必要な場合は(ステップS53にてYes)、次に、音出力変更部372が、直近に受信したモード信号に基づいて、車載装置2の音声モードがいずれであるかを判定する(ステップS54)。
車載装置2の音声モードが連携モードの場合は(ステップS54にてYes)、さらに、音出力変更部372が、直近に受信した有効無効信号に基づいて、車載装置2の音の出力機能の無効/有効を判定する(ステップS55)。
そして、車載装置2の音声モードが連携モードであり、かつ、車載装置2の音の出力機能の有効の場合は(ステップS55にてYes)、音出力変更部372は、音出力要求信号を無線通信部35を介して車載装置2に送信する(ステップS56)。この音出力要求信号には、出力すべき音などを指定する指定情報が含まれる。車載装置2は、この音出力要求信号に応答して、アプリ機能に関係する音を車両9の車室内に出力することになる。
これに対して、車載装置2の音声モードが連携モードでない場合は(ステップS54にてNo)、音出力変更部372は、アプリ機能に関係する音を内蔵スピーカ36から出力させる(ステップS57)。また、車載装置2の音声モードが連携モードの場合であっても、車載装置2の音の出力機能が無効の場合は(ステップS55にてNo)、音出力変更部372は、アプリ機能に関係する音を内蔵スピーカ36から出力させることになる(ステップS57)。
このように第3の実施の形態の携帯機器3は、車載装置2の音の出力状態に応じて音の出力に係る動作を変更するようになっている。すなわち、携帯機器3は、車載装置2がアプリ機能に関係する音を車室内のスピーカ29から出力しない動作状態となった場合には、アプリ機能に関係する音を内蔵スピーカ36から出力するようになっている。
また、第3の実施の形態の車載装置2は、アプリ機能に関係する音を車室内のスピーカ29から出力する連携モードと、アプリ機能に関係する音を車室内のスピーカ29から出力しない他の音声モード(放送モード,ディスクモード)とを含む複数の候補のいずれかに音声モードを変更可能となっている。そして、車載装置2のモード送信部64は、音声モードが変更された場合に、変更後の音声モードを示すモード信号を携帯機器3に送信する。したがって、携帯機器3は、車載装置2における音声モードに応じて、アプリ機能に関係する音の出力方法を変更することができる。
また、車載装置2は、音声出力部61の音の出力機能を無効化することが可能となっている。そして、車載装置2の無効状態送信部66は、音の出力機能が無効化された場合に、その出力機能が無効化されたことを示す有効無効信号を携帯機器3に送信する。従って、携帯機器3は、車載装置2における音の出力機能が無効化されたことに応じて、アプリ機能に関係する音の出力方法を変更することができる。
<3−4.音像の定位>
前述のように、車載装置2の音声出力部61は、音像を車室内の任意の位置に定位させることができる。車内通信システム10においては、この機能を利用して、アプリ機能の効果音の音像を携帯機器3が指定する位置に定位させるようになっている。
以下、アプリケーション部37が実行するアプリ機能が宝探しゲームの場合を例に説明する。この宝探しゲームは、地図上のランダムな位置に設定された宝箱スポットを、定期的に出力されるアプリ機能の効果音に基づいて、ユーザに探し出させるものである。
図18〜図20は、このアプリ機能の効果音を説明する図である。これら図18〜図20の図中の右側は、車両9の車室内VSにおいて、効果音の音像が定位する位置(以下、「音像位置」という。)Psを示している。音像位置Psの矩形領域の大きさは、効果音の音量を示している。
また、図18〜図20の図中の左側は、宝探しゲームに利用する地図であるゲーム地図MSを示している。ゲーム地図MSは、車両9の位置Pvの周辺の地図である。図中、車両9の位置Pvに付された矢印は、車両9の進行方向を示している。このゲーム地図MSには、目的となる宝物スポットの位置Paがランダムに設定される。
このようなゲーム地図MSのうち車両9の位置Pvの近傍となる一部のみが、表示領域VA2(アプリ地図M2)として携帯機器3のディスプレイ25に表示される。したがって、宝物スポットの位置Paは通常はディスプレイ25の表示範囲外になり、ユーザはゲーム地図MSをスクロールさせて宝物スポットの位置Paを探し出す。この際、ユーザは、アプリ機能の効果音を手がかりに、宝物スポットの位置Paを探し出すことになる。
この効果音の音量は、車両9の位置Pvと宝箱スポットの位置Paとの距離に基づいて定められる。また、効果音の音像位置Psは、車両9の進行方向を考慮して定められる。このような効果音の音量や音像位置Psを指定する指定情報は、アプリケーション部37が送信する音出力要求信号に含まれている。
まず、ゲーム地図MS上の車両9の位置Pvと宝箱スポットの位置Paとが、図18の左側に示す関係にある場合を想定する。この場合は、車両9の位置Pvと宝箱スポットの位置Paとが比較的離れているため、図18の右側に示すように、効果音の音量は比較的小さくなる。また、車両9の位置Pvからみた宝箱スポットの位置Paが、車両9の進行方向を基準にして左側にある。このため、図18の右側に示すように、効果音の音像位置Psは、車室内VSの前方の左側とされる。
次に、ゲーム地図MS上の車両9の位置Pvと宝箱スポットの位置Paとが、図19の左側に示す関係にある場合を想定する。この場合は、車両9の位置Pvと宝箱スポットの位置Paとが比較的近いため、図19の右側に示すように、効果音の音量は比較的大きくなる。また、この場合も、車両9の位置Pvからみた宝箱スポットの位置Paが、車両9の進行方向を基準にして左側にある。このため、図19の右側に示すように、効果音の音像位置Psは、車室内VSの前方の左側とされる。
また、ゲーム地図MS上の車両9の位置Pvと宝箱スポットの位置Paとが、図20の左側に示す関係にある場合を想定する。この場合は、図19の場合と比較して、ゲーム地図MS上の車両9の位置Pvと宝箱スポットの位置Paとの関係は同一であるが、車両9の進行方向が異なっている。このため、車室内VSにおける効果音の音像位置Psも、図19の場合と異なっている。すなわち、図20の場合では、車両9の位置Pvからみた宝箱スポットの位置Paが、車両9の進行方向を基準にして若干右側となる。このため、効果音の音像位置Psは、車室内VSの前方の若干右側とされる。
ユーザは、このような効果音が聞こえてくる位置や音量を手がかりに宝物スポットの位置Paを探し出すことができる。手がかりとなる効果音の音量や音像位置Psは、実際の車両9の位置や進行方向に基づいて定められるため、実際の車両9の走行とゲーム内容とが連動することになり、エンターテイメント性を高めることができる。
ただし、前述のように、携帯機器3のディスプレイ25に表示されるアプリ地図M2の向きはノースアップに固定される。このため、上記のように効果音の車室内VSにおける音像位置Psを車両9の進行方向に基づいて定めた場合、表示されたアプリ地図M2の上方向と車両9の進行方向とが異なることから、ユーザが方向に関して混乱する可能性がある。
このため、図21に示すように、表示されたアプリ地図M2の上方向と車両9の進行方向とが異なる場合は、車両9の進行方向が上になるように携帯機器3自体を傾けるように案内するダイアログメッセージDmをディスプレイ25に表示するようにしてもよい。このようにすれば、図21の下部に示すように、車両9の進行方向が上になるようにユーザが携帯機器3自体を傾けることができる。この場合、表示されたアプリ地図M2の上方向と車両9の進行方向とが一致するため、ユーザが方向に関して混乱することを防止することができる。
<4.変形例>
以上、本発明の実施の形態について説明してきたが、この発明は上記実施の形態に限定されるものではなく様々な変形が可能である。以下では、このような変形例について説明する。上記実施の形態及び以下で説明する形態を含む全ての形態は、適宜に組み合わせ可能である。
上記実施の形態では、車両9で用いられる車両用装置として車載装置2を例に説明を行ったが、車両用装置が、ナビゲーション機能等を実行する携帯電話やスマートフォンなどの可搬性の通信装置であってもよい。
また、上記実施の形態では、プログラム242に従ってCPUが演算を行うことで、携帯機器3との連携に関係する処理部と、連携に関係しない処理部との双方が実現されていた。これに対して、連携に関係する処理部を実現するプログラムと、連携に関係しない処理部を実現するプログラムとが個別に存在していてもよい。また、上記実施の形態においてプログラムに従ってCPUが演算を行うことで実現されるとした処理部の一部または全部は、電気的なハードウェア回路により実現されてもよい。
また、上記実施の形態では、アプリ地図はナビ地図と比較して情報量が少なく内容が簡略化されていたが、アプリ地図をナビ地図と同一の情報量の地図としてもよい。
また、上記実施の形態では、ナビ地図の縮尺の候補数は10種類であり、アプリ地図の縮尺の候補数は2種類であったが、これらの候補数は例示である。ナビ地図の縮尺の候補数(N種類)に対して、アプリ地図の縮尺の候補数(M種類)が少なければ(N>M)どのような数であってもよい。例えば、アプリ地図の縮尺の候補数は1種類であってもよい。
また、上記実施の形態では、車載装置2において携帯機器3のアプリ機能に関係する音の音声データが予め記憶されていた。これに対して、車載装置2においてアプリ機能に関係する音の音声データを記憶させずに、携帯機器3から車載装置2に出力すべき音の音声データを送信するようにしてもよい。また、アプリ機能に関係する音のうち、一部の音のみの音声データを車載装置2に予め記憶させ、他の音の音声データは携帯機器3から車載装置2に送信するようにしてもよい。
また、上記実施の形態では、携帯機器3の地図要求部371が、アプリ地図の要求の要否を判断していた。これに対して、車載装置2の制御部21が、携帯機器3へのアプリ地図の送信の要否を判断するようにしてもよい。
また、上記実施の形態では、アプリ地図の向きはノースアップに固定されていたが、携帯機器3のディスプレイ34に表示するアプリ地図の向きをノースアップとヘディングアップとで変更できるようになっていてもよい。携帯機器3で実行されるアプリ機能に応じて、ノースアップとヘディングアップとが選択されるようになっていてもよい。また、携帯機器3がディスプレイの画面を2以上備えている場合は、一の画面でノースアップのアプリ地図を表示させ、他の画面でヘディングアップのアプリ地図を表示させるようにしてもよい。