(57)【特許請求の範囲】
【請求項１】
車両で用いられ、携帯機器と通信可能な車両用装置であって、
前記車両用装置で実行される目的地までルート案内するナビゲーション機能に向けた第１地図を表示する表示手段と、
前記ナビゲーション機能とは異なる目的で地図を利用する、前記携帯機器で実行されるアプリケーションの機能に向けた第２地図を、前記表示手段が前記第１地図を表示中に、前記携帯機器に送信する第１送信手段と、
を備えることを特徴とする車両用装置。
【請求項２】
請求項１に記載の車両用装置において、
前記車両の位置を取得する取得手段と、
前記車両の位置を所定の周期で前記携帯機器に送信する第２送信手段と、
を備えることを特徴とする車両用装置。
【請求項３】
請求項１または２に記載の車両用装置において、
前記携帯機器から前記第２地図の位置を指定する指定情報を受信する受信手段、
をさらに備え、
前記第１送信手段は、前記指定情報が指定する位置の前記第２地図を前記携帯機器に送信することを特徴とする車両用装置。
【請求項４】
請求項１ないし３のいずれかに記載の車両用装置において、
前記第１送信手段は、前記携帯機器が有する表示装置の表示サイズよりも大きなサイズの前記第２地図を前記携帯機器に送信することを特徴とする車両用装置。
【請求項５】
請求項１ないし４のいずれかに記載の車両用装置において、
前記第１地図を、地図データベースに基づいて取得する第１取得手段と、
前記第２地図を、前記地図データベースと同じ地図データベースに基づいて取得する第２取得手段と、
を備えることを特徴とする車両用装置。
【請求項６】
請求項１ないし４のいずれかに記載の車両用装置において、
前記第１地図を、第１地図データベースに基づいて取得する第１取得手段と、
前記第２地図を、前記第１地図データベースとは異なる第２地図データベースに基づいて取得する第２取得手段と、
を備えることを特徴とする車両用装置。
【請求項７】
請求項６に記載の車両用装置において、
前記第１地図の縮尺を、Ｎ種類の候補のいずれかに変更する第１変更手段と、
前記第２地図の縮尺を、前記Ｎ種類より少ないＭ種類の候補のいずれかに変更する第２変更手段と、
を備えることを特徴とする車両用装置。
【請求項８】
請求項１ないし７のいずれかに記載の車両用装置において、
前記第１地図の向きを、前記車両の進行方向を上にする向きと、地表上の一方位を上にする向きとのいずれかに変更する第３変更手段、
を備え、
前記第２地図の向きは、前記地表上の一方位を上にする向きに固定されることを特徴とする車両用装置。
【請求項９】
請求項１ないし８のいずれかに記載の車両用装置において、
前記車両の車室内にスピーカを介して音を出力する出力手段と、
前記出力手段が前記アプリケーションの機能に関係する音を出力する第１モードと、前記出力手段が前記アプリケーションの機能に関係する音を出力しない第２モードとを含む複数の候補のいずれかに、音声モードを変更する第４変更手段と、
前記音声モードが変更された場合に、前記車両用装置の前記音の出力状態に応じて動作を変更する前記携帯機器に、変更後の前記音声モードを示す信号を送信する第３送信手段と、
を備えることを特徴とする車両用装置。
【請求項１０】
車両で用いられる車両用装置から携帯機器にデータを送信するデータ送信方法であって、
（ａ）前記車両用装置で実行される目的地までルート案内するナビゲーション機能に向けた第１地図を表示する工程と、
（ｂ）前記ナビゲーション機能とは異なる目的で地図を利用する、前記携帯機器で実行されるアプリケーションの機能に向けた第２地図を、前記工程（ａ）で前記第１地図を表示中に、前記携帯機器に送信する工程と、
を備えることを特徴とするデータ送信方法。
【請求項１１】
車両で用いられ、携帯機器と通信可能な車両用装置に含まれるコンピュータによって実行可能なプログラムであって、
前記コンピュータによる前記プログラムの実行は、前記コンピュータに、
（ａ）前記車両用装置で実行される目的地までルート案内するナビゲーション機能に向けた第１地図を表示する工程と、
（ｂ）前記ナビゲーション機能とは異なる目的で地図を利用する、前記携帯機器で実行されるアプリケーションの機能に向けた第２地図を、前記工程（ａ）で前記第１地図を表示中に、前記携帯機器に送信する工程と、
を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両で用いられる車両用装置と携帯機器とを通信させる技術に関する。
【背景技術】
【０００２】
従来より、車両で用いられる車両用装置として、例えば、目的地までのルート案内を行うナビゲーション装置などが知られている。このような車両用装置は、ナビゲーション機能のための地図を表示する。車両用装置のユーザ（主にドライバ）は、適宜、車両用装置に表示された地図を利用することで、車両の位置やルートを把握することができる。
【０００３】
また、車両用装置から他の携帯機器に地図を送信し、この地図を携帯機器に表示させる技術も提案されている（例えば、特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−２５１６９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
この特許文献１の技術を利用して、車両用装置からドライバ以外の同乗者が扱う携帯機器に地図を送信し、この同乗者が携帯機器に表示された地図を利用することが考えられる。
【０００６】
しかしながら、特許文献１の技術では、車両用装置に表示された地図と同一の地図が携帯機器に送信され、車両用装置と携帯機器とで同一の地図が表示される。したがって、車両用装置が地図を表示している場合には、携帯機器のユーザは、車両用装置に表示された地図と同一の地図のみしか利用できない。
【０００７】
このため、携帯機器のユーザは、車両用装置で実行中の機能（例えば、ナビゲーション機能）とは異なる機能（例えば、観光案内、ゲーム等）のために地図を利用することができない。
【０００８】
また、ところで、携帯機器と車両用装置とを通信させる場合においては、携帯機器で実行される機能の音を、携帯機器が直接出力せずに、車両用装置が代わりに出力することも考えられる。しかしながら、この場合、車両用装置が音を出力しない動作状態となった場合には、携帯機器と車両用装置とのいずれからも音が出力されないこととなる。
【０００９】
本発明は、上記課題に鑑みてなされたものであり、車両用装置のユーザと携帯機器のユーザとがそれぞれ、互いに異なる機能のために地図を同時に利用することができる技術を提供することを第１の目的とする。
【００１０】
また、本発明は、携帯機器が車両用装置の音の出力状態に応じて音の出力方法を変更することができる技術を提供することを第２の目的とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するため、請求項１の発明は、車両で用いられ、携帯機器と通信可能な車両用装置であって、前記車両用装置で実行される目的地までルート案内するナビゲーション機能に向けた第１地図を表示する表示手段と、前記ナビゲーション機能とは異なる目的で地図を利用する、前記携帯機器で実行されるアプリケーションの機能に向けた第２地図を、前記表示手段が前記第１地図を表示中に、前記携帯機器に送信する第１送信手段と、を備えている。
【００１２】
また、請求項２の発明は、請求項１に記載の車両用装置において、前記車両の位置を取得する取得手段と、前記車両の位置を所定の周期で前記携帯機器に送信する第２送信手段と、を備えている。
【００１３】
また、請求項３の発明は、請求項１または２に記載の車両用装置において、前記携帯機器から前記第２地図の位置を指定する指定情報を受信する受信手段、をさらに備え、前記第１送信手段は、前記指定情報が指定する位置の前記第２地図を前記携帯機器に送信する。
【００１４】
また、請求項４の発明は、請求項１ないし３のいずれかに記載の車両用装置において、前記第１送信手段は、前記携帯機器が有する表示装置の表示サイズよりも大きなサイズの前記第２地図を前記携帯機器に送信する。
【００１５】
また、請求項５の発明は、請求項１ないし４のいずれかに記載の車両用装置において、前記第１地図を、地図データベースに基づいて取得する第１取得手段と、前記第２地図を、前記地図データベースと同じ地図データベースに基づいて取得する第２取得手段と、を備えている。
【００１６】
また、請求項６の発明は、請求項１ないし４のいずれかに記載の車両用装置において、前記第１地図を、第１地図データベースに基づいて取得する第１取得手段と、前記第２地図を、前記第１地図データベースとは異なる第２地図データベースに基づいて取得する第２取得手段と、を備えている。
【００１７】
また、請求項７の発明は、請求項６に記載の車両用装置において、前記第１地図の縮尺を、Ｎ種類の候補のいずれかに変更する第１変更手段と、前記第２地図の縮尺を、前記Ｎ種類より少ないＭ種類の候補のいずれかに変更する第２変更手段と、を備えている。
【００１８】
また、請求項８の発明は、請求項１ないし７のいずれかに記載の車両用装置において、前記第１地図の向きを、前記車両の進行方向を上にする向きと、地表上の一方位を上にする向きとのいずれかに変更する第３変更手段、を備え、前記第２地図の向きは、前記地表上の一方位を上にする向きに固定される。
【００１９】
また、請求項９の発明は、請求項１ないし８のいずれかに記載の車両用装置において、前記車両の車室内にスピーカを介して音を出力する出力手段と、前記出力手段が前記アプリケーションの機能に関係する音を出力する第１モードと、前記出力手段が前記アプリケーションの機能に関係する音を出力しない第２モードとを含む複数の候補のいずれかに、音声モードを変更する第４変更手段と、前記音声モードが変更された場合に、前記車両用装置の前記音の出力状態に応じて動作を変更する前記携帯機器に、変更後の前記音声モードを示す信号を送信する第３送信手段と、を備えている。
【００２２】
また、請求項１０の発明は、車両で用いられる車両用装置から携帯機器にデータを送信するデータ送信方法であって、（ａ）前記車両用装置で実行される目的地までルート案内するナビゲーション機能に向けた第１地図を表示する工程と、（ｂ）前記ナビゲーション機能とは異なる目的で地図を利用する、前記携帯機器で実行されるアプリケーションの機能に向けた第２地図を、前記工程（ａ）で前記第１地図を表示中に、前記携帯機器に送信する工程と、を備えている。
【００２４】
また、請求項１１の発明は、車両で用いられ、携帯機器と通信可能な車両用装置に含まれるコンピュータによって実行可能なプログラムであって、前記コンピュータによる前記プログラムの実行は、前記コンピュータに、（ａ）前記車両用装置で実行される目的地までルート案内するナビゲーション機能に向けた第１地図を表示する工程と、（ｂ）前記ナビゲーション機能とは異なる目的で地図を利用する、前記携帯機器で実行されるアプリケーションの機能に向けた第２地図を、前記工程（ａ）で前記第１地図を表示中に、前記携帯機器に送信する工程と、を実行させる。
【発明の効果】
【００２６】
請求項１ないし１１の発明によれば、車両用装置のユーザと携帯機器のユーザとがそれぞれ、互いに異なる機能のために地図を同時に利用することができる。
【００２７】
また、特に請求項２の発明によれば、携帯機器において、車両の位置に応じた機能を提供できる。
【００２８】
また、特に請求項３の発明によれば、携帯機器が指定する位置の第２地図を携帯機器において利用することができる。
【００２９】
また、特に請求項４の発明によれば、携帯機器において表示する第２地図の範囲を変更する際に、変更後の範囲の第２地図を速やかに表示できる。
【００３０】
また、特に請求項５の発明によれば、第１地図と第２地図とが共通の地図データベースに基づいて取得されるため、地図データベースを記憶する記憶手段に必要な記憶容量を低減できる。
【００３１】
また、特に請求項６の発明によれば、第１地図と第２地図とが異なる地図データベースに基づいて取得されるため、携帯機器のアプリケーションの機能に適した第２地図を容易に取得することができる。
【００３２】
また、特に請求項７の発明によれば、第２地図の縮尺の候補はＮ種類より少ないＭ種類であるため、第２地図データベースのデータ量を少なくできる。
【００３３】
また、特に請求項８の発明によれば、第２地図の向きが地表上の一方位を上にする向きに固定されるため、車両用装置から携帯機器に送信するデータ量を低減できる。
【００３４】
また、特に請求項９の発明によれば、音声モードが変更された場合に変更後の音声モードを示す信号を携帯機器に送信するため、携帯機器はその時点の音声モードに応じて音の出力方法を変更することができる。
【図面の簡単な説明】
【００３７】
【図１】図１は、車内通信システムの概要を示す図である。
【図２】図２は、第１の実施の形態の車載装置の構成を示す図である。
【図３】図３は、第１の実施の形態の携帯機器の構成を示す図である。
【図４】図４は、ナビ地図の一例を示す図である。
【図５】図５は、アプリ地図の一例を示す図である。
【図６】図６は、ナビ地図の向きを説明するための図である。
【図７】図７は、ノースアップ地図を生成する手法を説明する図である。
【図８】図８は、ヘディングアップ地図を生成する手法を説明する図である。
【図９】図９は、アプリ地図を説明するための図である。
【図１０】図１０は、表示領域の範囲の遷移を示す図である。
【図１１】図１１は、車内通信システムの処理の流れを示す図である。
【図１２】図１２は、第２の実施の形態の車載装置の構成を示す図である。
【図１３】図１３は、地図データベースを示す図である。
【図１４】図１４は、第３の実施の形態の車載装置の構成を示す図である。
【図１５】図１５は、第３の実施の形態の携帯機器の構成を示す図である。
【図１６】図１６は、車載装置の音の出力に関する処理の流れを示す図である。
【図１７】図１７は、携帯機器の音の出力に関する処理の流れを示す図である。
【図１８】図１８は、アプリ機能の効果音を説明する図である。
【図１９】図１９は、アプリ機能の効果音を説明する図である。
【図２０】図２０は、アプリ機能の効果音を説明する図である。
【図２１】図２１は、メッセージが表示された携帯機器の例を示す図である。
【発明を実施するための形態】
【００３８】
以下、図面を参照しつつ本発明の実施の形態について説明する。
【００３９】
＜１．第１の実施の形態＞
＜１−１．システムの概要＞
図１は、第１の実施の形態の車両用装置を含む車内通信システム１０の概要を示す図である。車内通信システム１０は、自動車などの車両９に搭載される車載装置２と、車載装置２とは別個に構成される携帯機器３とを備えている。
【００４０】
車載装置２と携帯機器３との双方は、共通の通信方式に準拠した無線通信機能を有している。したがって、車載装置２と携帯機器３とは、無線通信によって相互にデータを送受信することが可能である。なお、車載装置２と携帯機器３とを通信ケーブルで物理的に接続し、車載装置２と携帯機器３とが有線通信によって相互にデータを送受信可能となっていてもよい。
【００４１】
車載装置２は、車両９において主にドライバに用いられる車両用装置である。車載装置２は、例えば、ルート案内などのナビゲーション機能を実行するナビゲーション装置である。車載装置２は、ディスプレイ２５を有しており、このディスプレイ２５にはナビゲーション機能のための地図が表示される。
【００４２】
また、携帯機器３は、車両９に乗車したドライバ以外の同乗者に用いられる可搬性装置である。携帯機器３は、例えば、携帯電話、スマートフォン、ＰＤＡ又はゲーム機などであり、アプリケーションの機能（以下、「アプリ機能」という。）を実行することが可能である。携帯機器３も、ディスプレイ３４を有している。地図を利用するアプリ機能が実行される場合、このアプリ機能のための地図が携帯機器３のディスプレイ３４に表示される。
【００４３】
車内通信システム１０においては、車載装置２と携帯機器３とは連携して動作することが可能となっている。具体的には、車載装置２から携帯機器３に、携帯機器３のアプリ機能に向けた地図が送信される。そして、このような連携によって送信された地図が、携帯機器３において表示される。このため、携帯機器３が地図の生成に必要な地図基礎データなどを予め記憶していなくても、携帯機器３はアプリ機能に向けた地図を表示できるようになっている。
【００４４】
また、携帯機器３で実行されるアプリ機能は、観光案内、ゲームなどのナビゲーション機能以外の機能であってよい。このため、車内通信システム１０においては、車両用装置のユーザと携帯機器のユーザとがそれぞれ、互いに異なる機能のために地図を同時に利用できるようになっている。以下、このような車内通信システム１０の構成及び処理について詳細に説明する。
【００４５】
＜１−２．車載装置の構成＞
まず、ナビゲーション機能を実行する車載装置２の構成について説明する。図２は、車載装置２の構成を示す図である。車載装置２は、前述したディスプレイ２５の他、車両情報センサ２２、操作部２３、記憶部２４、無線通信部２６、及び、制御部２１を備えている。
【００４６】
ディスプレイ２５は、例えば、液晶パネルなどを備えた薄型の表示装置である。ディスプレイ２５は、その画面がユーザ（主にドライバ）から視認可能なように、車両９の車室内のインストルメントパネルなどに配置される。ディスプレイ２５には、ナビゲーション機能に向けた地図が表示される。
【００４７】
車両情報センサ２２は、車両９の位置を示す信号、及び、車両９の進行方向を示す信号を取得する。車両情報センサ２２は、ＧＰＳ受信部を含み、複数のＧＰＳ衛星から車両９の位置を示す信号を受信し、受信した信号を制御部２１に入力する。また、車両情報センサ２２は、方位を検知する電子コンパスを含み、車両９の前方が向く方位（すなわち、車両９の進行方向）を示す信号を取得し、取得した信号を制御部２１に入力する。
【００４８】
操作部２３は、ユーザが操作可能な操作部材である。操作部２３は、複数の操作ボタンと、ディスプレイ２５の画面に重ねて設けられたタッチパネルとを含む。ユーザが操作部２３を操作した場合は、その操作内容を示す信号が制御部２１に入力される。
【００４９】
記憶部２４は、例えばフラッシュメモリなど、各種のデータを記憶可能な不揮発性のメモリである。記憶部２４は、地図データベース２４１と、ファームウェアとしてのプログラム２４２とを記憶している。
【００５０】
地図データベース２４１は、表示に用いる地図の生成に必要な地図基礎データを含んでいる。車載装置２で実行されるナビゲーション機能に向けた地図（以下、「ナビ地図」という。）は、この地図データベース２４１の地図基礎データに基づいて生成される。また同様に、携帯機器３で実行されるアプリ機能に向けた地図（以下、「アプリ地図」という。）も、同一の地図データベース２４１の地図基礎データに基づいて生成される。これらの表示に用いるナビ地図、及び、アプリ地図はラスタデータ（画像）である。
【００５１】
これに対して、地図基礎データは、主にベクタデータで構成される。地図基礎データは、道路データ、スポットデータ、及び、背景データを含んでいる。道路データは、交差点等の情報を示すノード、及び、ノードとノードとの間の区間の情報を示すリンク等を含んだベクタデータである。スポットデータは、地図上の様々なスポットの種別、位置、名称、及び、アイコン等を含んでいる。また、背景データは、地形、鉄道路線、行政境界、及び、地名等を含んでいる。
【００５２】
地図データベース２４１では、このような地図基礎データが、複数の縮尺別に用意されている。本実施の形態では、例えば、「１／５０００」、「１／１万」、「１／２万」、「１／４万」、「１／８万」、「１／１６万」、「１／３２万」、「１／６４万」「１／１２８万」、及び、「１／２５６万」の１０種類の縮尺の地図基礎データが地図データベース２４１に含まれている。
【００５３】
無線通信部２６は、外部の通信装置と通信する。無線通信部２６は、Bluetooth（登録商標）などの所定の通信方式に準拠した無線通信によって外部の通信装置と通信する。これにより、無線通信部２６は、携帯機器３との間でデータの送受信を行う。
【００５４】
また、制御部２１は、車載装置２の全体を統括的に制御するマイクロコンピュータである。制御部２１は、ＣＰＵ、ＲＡＭ及びＲＯＭなどを備えており、記憶部２４に記憶されたプログラム２４２に従ってＣＰＵが演算を行うことで、各種の処理部が実現される。
【００５５】
車載装置２は、プログラムが記憶されたコンピュータ読み取り可能なメモリカードなどの記憶媒体８からリーダ（図示せず）を介して読み出すことで、このようなプログラム２４２を取得する。また、車載装置２は、ネットワーク通信部（図示せず）を介してネットワーク上の所定のサーバなどからダウンロードすることで、プログラム２４２を取得することもできる。
【００５６】
図２中に示す、車両情報取得部５１、ナビ地図取得部５２、ナビ地図調整部５３、及び、ナビゲーション部５４は、プログラム２４２に従ってＣＰＵが演算を行うことで実現される処理部である。
【００５７】
車両情報取得部５１は、車両情報センサ２２から入力される信号に基づいて車両９の位置、及び、車両９の進行方向を取得する。車両情報取得部５１は、車両９の位置を示す信号に基づいて車両９の位置を導出し、車両９の進行方向を示す信号に基づいて車両９の進行方向を導出する。
【００５８】
ナビ地図取得部５２は、地図データベース２４１に基づいてナビ地図を取得する。ナビ地図取得部５２は、地図データベース２４１から必要となる一の縮尺の地図基礎データを読み出す。そして、ナビ地図取得部５２は、この地図基礎データに基づいて地形及び道路を含む地図画像を生成し、この地図画像に対して、地名、スポットの名称、及び、アイコン等を重畳する。これにより、ナビ地図取得部５２は、ナビゲーション機能に適したナビ地図を生成する。
【００５９】
ナビ地図調整部５３は、ナビ地図に関するパラメータを変更して、ナビ地図取得部５２が生成するナビ地図の内容を調整する。より具体的には、ナビ地図調整部５３は、操作部２３を介したユーザの指示やナビゲーション部５４の指示に従って、ナビ地図の位置、縮尺、及び、向きなどを変更する。例えば、ナビ地図調整部５３は、ユーザの指示に従って、前述した１０種類の縮尺の候補のいずれかに、ナビ地図の縮尺を変更する。これにより、ユーザが所望する縮尺のナビ地図が生成される。
【００６０】
ナビゲーション部５４は、目的地までのルート案内などのナビゲーション機能を実行する。ナビゲーション部５４は、ナビ地図取得部５２で取得されたナビ地図に対して、自車位置マークやルートなどの情報を重畳する。自車位置マークは、車両９の現在の位置及び進行方向を示すマークであり、車両情報取得部５１で得られた車両９の位置及び進行方向に基づいて重畳される。そして、ナビゲーション部５４は、このナビ地図をディスプレイ２５に出力して表示させる。
【００６１】
また、図２中に示す、車両情報送信部５５、要求受信部５６、アプリ地図取得部５７、アプリ地図調整部５８、及び、アプリ地図送信部５９も、プログラム２４２に従ってＣＰＵが演算を行うことで実現される処理部である。これらの処理部は、携帯機器３との連携に係る処理を行う。
【００６２】
車両情報送信部５５は、車両情報取得部５１で得られた車両９の位置、及び、車両９の進行方向を、無線通信部２６を介して携帯機器３に送信する。車両情報送信部５５は、車両９の位置及び進行方向を、所定の周期で繰り返し携帯機器３に送信する。
【００６３】
要求受信部５６は、携帯機器３から送信される要求信号を無線通信部２６を介して受信する。要求信号には、携帯機器３がアプリ地図を車載装置２に要求する場合に送信する地図要求信号が含まれる。この地図要求信号には、アプリ地図の位置、及び、縮尺などを指定する指定情報が含まれている。
【００６４】
アプリ地図取得部５７は、地図要求信号に応答して、地図データベース２４１に基づいてアプリ地図を取得する。アプリ地図取得部５７は、地図データベース２４１から必要となる一の縮尺の地図基礎データを読み出す。そして、アプリ地図取得部５７は、この地図基礎データに基づいて地形及び道路を含む地図画像を生成し、この地図画像に対して、地名、スポットの名称、及び、アイコン等を重畳する。これにより、アプリ地図取得部５７は、携帯機器３のアプリ機能に適したアプリ地図を生成する。このアプリ地図の生成手法は、ナビ地図の生成手法とは異なっており、アプリ地図とナビ地図とはその内容が異なることとなるが、詳細は後述する。
【００６５】
アプリ地図調整部５８は、アプリ地図に関するパラメータを変更して、アプリ地図取得部５７が生成するアプリ地図の内容を調整する。より具体的には、アプリ地図調整部５８は、携帯機器３からの地図要求信号に含まれる指定情報に従って、アプリ地図の縮尺、及び、位置などを変更する。アプリ地図の縮尺の候補数は、ナビ地図の縮尺の候補数の「１０種類」よりも少ない例えば「２種類」となっている。このため、アプリ地図調整部５８は、２種類の縮尺の候補（例えば、「１／５０００」及び「１／１２８万」）のいずれかに、アプリ地図の縮尺を変更する。
【００６６】
アプリ地図送信部５９は、地図要求信号に応答してアプリ地図取得部５７で取得されたアプリ地図を、無線通信部２６を介して携帯機器３に送信する。これにより、アプリ機能に適したアプリ地図が携帯機器３に送信される。
【００６７】
＜１−３．携帯機器の構成＞
次に、アプリ機能を実行する携帯機器３の構成について説明する。図３は、携帯機器３の構成を示す図である。携帯機器３は、前述したディスプレイ３４の他、操作部３２、無線通信部３５、記憶部３３、及び、制御部３１を一の筐体内に備えている。
【００６８】
ディスプレイ３４は、例えば、液晶パネルなどを備えた薄型の表示装置である。ディスプレイ３４には、アプリ機能に向けた地図などが表示される。
【００６９】
操作部３２は、ユーザが操作可能な操作部材である。操作部３２は、複数の操作ボタンと、ディスプレイ３４の画面に重ねて設けられたタッチパネルとを含む。ユーザは、自分の指やタッチペンなどでタッチパネルに触れることで各種の操作（タップ、ドラッグ等）を行うことができる。ユーザが操作部２３を操作した場合は、その操作内容を示す信号が制御部３１に入力される。
【００７０】
無線通信部３５は、外部の通信装置と通信する。無線通信部３５は、Bluetooth（登録商標）などの所定の通信方式に準拠した無線通信によって外部の通信装置と通信する。これにより、無線通信部３５は、車載装置２との間でデータの送受信を行う。無線通信部３５は、車両９の位置、車両９の進行方向、及び、アプリ地図などを車載装置２から受信する。
【００７１】
記憶部３３は、例えばフラッシュメモリなど、各種のデータを記憶可能な不揮発性のメモリである。記憶部３３は、アプリケーションのプログラム３３１を記憶している。なお、記憶部３３をメモリカードなどの可搬性の記憶媒体として構成し、記憶部３３が携帯機器３に対して着脱可能となっていてもよい。
【００７２】
また、制御部３１は、携帯機器３の全体を統括的に制御するマイクロコンピュータである。制御部３１は、ＣＰＵ、ＲＡＭ及びＲＯＭなどを備えている。記憶部３３に記憶されたアプリケーションのプログラム３３１に従ってＣＰＵが演算を行うことで、各種の処理部が実現される。図中に示すアプリケーション部３７は、プログラム３３１に従ってＣＰＵが演算を行うことで実現される処理部である。
【００７３】
アプリケーション部３７は、地図を利用するアプリ機能を実行する。このような地図を利用するアプリ機能は、例えば、観光案内、クイズゲーム、及び、宝探しゲームなどである。観光案内は、地図上に存在する観光地や施設などの各種スポットについての情報をユーザに提供するものである。クイズゲームは、地図上に存在する観光地や施設などの各種スポットに関するクイズをユーザに出題するものである。また、宝探しゲームは、地図上のランダムな位置に仮想的に宝箱スポットを設定し、ユーザにその宝箱スポットを探し出させるものである。
【００７４】
アプリケーション部３７は、このようなアプリ機能を実行する場合に、携帯機器３から提供されたアプリ地図をディスプレイ２５に表示させる。アプリケーション部３７は、このアプリ地図を携帯機器３に要求する地図要求部３７１を備えている。地図要求部３７１は、アプリ地図の要求の要否を判断してアプリ地図の要求が必要な場合は、無線通信部３５を介して地図要求信号を車載装置２に送信する。この地図要求信号には、アプリ機能において必要なアプリ地図の位置、及び、縮尺などを指定する指定情報が含まれている。
【００７５】
＜１−４．地図＞
次に、表示に用いられる地図（ナビ地図、及び、アプリ地図）についてより詳細に説明する。図４は、車載装置２に表示されたナビ地図Ｍ１の一例を示す図である。また、図５は、携帯機器３に表示されたアプリ地図Ｍ２の一例を示す図である。
【００７６】
図４のナビ地図Ｍ１と図５のアプリ地図Ｍ２とは、同一の位置を示している。図４と図５とを比較して分かるように、アプリ地図Ｍ２は、ナビ地図Ｍ１よりも情報量が少なくなっており内容が簡略化されている。
【００７７】
ナビ地図Ｍ１は、ナビゲーション機能に向けたものであるため、ドライバが運転中に必要な道路や地名等の各種の情報を含む詳細な地図となっている。これに対して、アプリ地図Ｍ２は、例えば、観光案内やゲームなどのエンターテイメント用のアプリ機能に向けたものである。このため、アプリ地図Ｍ２は、主要道路を強調しつつ、細い道路やスポット名などの一部の情報が省略され適宜にイラストを含むアイコンなどを利用した親しみやすい地図となっている。
【００７８】
前述したように、ナビ地図Ｍ１とアプリ地図Ｍ２とは、同一の地図データベース２４１の地図基礎データに基づいて生成される。ナビ地図取得部５２は、地図基礎データに含まれる各種データの大部分を用いて詳細なナビ地図Ｍ１を生成する。これに対して、アプリ地図取得部５７は、地図基礎データに含まれる各種データの一部のみを用いるとともに、文字情報等に変えて専用のアイコンなどを利用してアプリ地図Ｍ２を生成する。これにより、ナビ地図Ｍ１とアプリ地図Ｍ２とはその内容が異なることとなる。
【００７９】
前述のように、ナビ地図取得部５２は、ユーザの指示に従って、１０種類の候補のいずれかの縮尺のナビ地図Ｍ１を生成する。これに対して、アプリ地図取得部５７は、地図要求信号に従って、２種類のみの候補のいずれかの縮尺のアプリ地図Ｍ２を生成することになる。
【００８０】
また、ナビ地図取得部５２は、表示に用いるナビ地図Ｍ１として向きが異なる地図を生成することが可能となっている。図６は、ナビ地図Ｍ１の向きを説明するための図である。図６の上部は、地表上の一方位である「北」を上にする向き（ノースアップ）のナビ地図Ｍ１であるノースアップ地図Ｍ１ａを示している。一方、図６の下部は、車両９の進行方向を上にする向き（ヘディングアップ）のナビ地図Ｍ１であるヘディングアップ地図Ｍ１ｂを示している。このようなナビ地図Ｍ１の向きは、ユーザの指示に従ってナビ地図調整部５３が変更する。
【００８１】
図７は、ノースアップ地図Ｍ１ａを生成する手法を説明する図である。また、図８は、ヘディングアップ地図Ｍ１ｂを生成する手法を説明する図である。これらの図において、車両９の位置Ｐｖに付された矢印は、車両９の進行方向を示している。
【００８２】
ナビ地図取得部５２は、まず、車両９の位置Ｐｖを含む、ディスプレイ２５の表示サイズよりも広いナビ地図Ｍ１である広域地図Ｍ１１を生成する。より具体的には、ディスプレイ２５の表示サイズに相当する領域を一つのブロックとした場合、ナビ地図取得部５２は、横３ブロック×縦３ブロックの合計９ブロックに相当する広域地図Ｍ１１を生成する。これら９ブロックの中心の１ブロックに車両９の位置Ｐｖが含まれている。例えば、ディスプレイ２５の表示サイズ（解像度）がＶＧＡ（横６４０×縦４８０画素）である場合、横１９２０画素×縦１４４０画素の広域地図Ｍ１１が生成される。この広域地図Ｍ１１の向きは、「北」が上となる向き（ノースアップ）となっている。生成された広域地図Ｍ１１は、制御部２１のＲＡＭに記憶される。
【００８３】
そして、ナビ地図取得部５２は、ノースアップ地図Ｍ１ａを生成する場合は、図７に示すように、広域地図Ｍ１１から、そのままの向きで車両９の位置Ｐｖを中心とした表示サイズ分の表示領域ＶＡ１を切り出す。これにより、ノースアップ地図Ｍ１ａが生成される。
【００８４】
一方、ナビ地図取得部５２は、ヘディングアップ地図Ｍ１ｂを生成する場合は、図８に示すように、広域地図Ｍ１１から、車両９の進行方向が上となる向きで車両９の位置Ｐｖを中心とした表示サイズ分の表示領域ＶＡ１を切り出す。これにより、ヘディングアップ地図Ｍ１ｂが生成される。
【００８５】
これに対して、アプリ地図取得部５７は、アプリ地図Ｍ２として、「北」を上にする向き（ノースアップ）の地図のみを生成する。すなわち、携帯機器３に表示されるアプリ地図Ｍ２の向きはノースアップに固定される。図９は、アプリ地図取得部５７が生成するアプリ地図Ｍ２を示す図である。
【００８６】
アプリ地図取得部５７は、携帯機器３のディスプレイ３４の表示サイズよりも広いアプリ地図Ｍ２を生成する。生成されるアプリ地図Ｍ２の中心位置Ｐｃは、指定情報が指定する位置とされる。
【００８７】
このアプリ地図Ｍ２のサイズは、携帯機器３のディスプレイ３４の表示サイズに対して、縦横それぞれ２倍となっている。例えば、ディスプレイ２５の表示サイズ（解像度）がＱＶＧＡ（横３２０×縦２４０画素）である場合、アプリ地図Ｍ２のサイズは横６４０画素×縦４８０画素となる。このアプリ地図Ｍ２の向きは、ノースアップとなっている。
【００８８】
アプリ地図取得部５７に生成されたアプリ地図Ｍ２は携帯機器３に送信され、制御部３１のＲＡＭに記憶される。携帯機器３のアプリケーション部３７は、このアプリ地図Ｍ２から、そのままの向きで表示サイズ分の表示領域ＶＡ２を切り出す。そして、このようにして切り出された部分のアプリ地図Ｍ２が、ディスプレイ３４に表示される。
【００８９】
表示領域ＶＡ２は、通常は、車両９の位置を中心とする範囲とされる。したがって、車両９の位置の変化に応じて、アプリケーション部３７は、表示領域ＶＡ２の範囲を変更する。
【００９０】
図１０は、車両９の位置Ｐｖに応じた表示領域ＶＡ２の範囲の遷移を示す図である。状態ＳＴ１においては、アプリ地図Ｍ２の中心位置Ｐｃと、車両９の位置Ｐｖとが一致している。したがって、この場合は、表示領域ＶＡ２は、アプリ地図Ｍ２の中心位置Ｐｃ（すなわち、車両９の位置Ｐｖ）を中心とした範囲となっている。
【００９１】
そして、状態ＳＴ２のように、車両９が移動して車両９の位置Ｐｖが変化すると、この車両９の位置Ｐｖに合わせて表示領域ＶＡ２の範囲が変更される。すなわち、移動後の車両９の位置Ｐｖを中心とした範囲に表示領域ＶＡ２が変更されることになる。
【００９２】
アプリ地図Ｍ２のサイズはディスプレイ３４の表示サイズよりも大きいため、アプリ地図Ｍ２の範囲内では表示領域ＶＡ２の範囲を容易に変更できる。このため、このように車両９の移動に合わせて表示領域ＶＡ２の範囲を変更する場合であっても、車両９の移動のたびに新たなアプリ地図Ｍ２を車載装置２から携帯機器３に送信する必要がない。したがって、表示領域ＶＡ２を変更する場合に、変更後の表示領域ＶＡ２の範囲のアプリ地図Ｍ２を速やかに表示できる。
【００９３】
また、状態ＳＴ３のように、車両９がさらに移動して表示領域ＶＡ２の端部が、ＲＡＭに記憶されたアプリ地図Ｍ２の端部に近接した場合は、携帯機器３の地図要求部３７１が、新たなアプリ地図Ｍ２を要求する地図要求信号を車載装置２に送信する。この地図要求信号には、アプリ地図Ｍ２の位置として、その時点の車両９の位置Ｐｖを指定する指定情報が含まれる。
【００９４】
これにより、状態ＳＴ４のように、その時点の車両９の位置Ｐｖを中心位置Ｐｃとする新たなアプリ地図Ｍ２が、車載装置２から携帯機器３に送信される。なお、この場合、携帯機器３のＲＡＭに記憶された古いアプリ地図Ｍ２Ｌと新たなアプリ地図Ｍ２との差分の領域（図中、ハッチングで示す領域）のみを、車載装置２から携帯機器３へ送信するようにしてもよい。
【００９５】
なお、図１０では、表示領域ＶＡ２の範囲が車両９の位置Ｐｖに合わせて変更される場合について説明したが、携帯機器３においては、ユーザがタッチパネルにスクロール指示の操作を行った場合にも表示領域ＶＡ２の範囲が変更される。この場合、車両９の位置Ｐｖとは無関係に、アプリ地図Ｍ２がスクロールされる。
【００９６】
このようなスクロール指示の操作がなされた場合において、スクロール後の表示領域ＶＡ２とすべき範囲が、ＲＡＭに記憶されたアプリ地図Ｍ２から外れる場合においても、地図要求部３７１が新たなアプリ地図Ｍ２を要求する地図要求信号を車載装置２に送信する。この地図要求信号には、アプリ地図Ｍ２の位置としてスクロール後の表示領域ＶＡ２とすべき範囲の中心を指定する指定情報が含まれる。これにより、指定情報が指定した位置を中心位置Ｐｃとする新たなアプリ地図Ｍ２が、車載装置２から携帯機器３に送信されることになる。なお、指定情報が指定するアプリ地図Ｍ２の位置は、その時点の車両９の位置Ｐｖのような位置情報に限るものではなく、アプリ地図Ｍ２の外縁などであってもよい。
【００９７】
＜１−５．処理の流れ＞
次に、車内通信システム１０の処理の流れについて説明する。図１１は、車内通信システム１０の処理の流れを示す図である。図中の左側は車載装置２の処理の流れを示しており、図中の右側は携帯機器３の処理の流れを示している。これらの処理は、車載装置２と携帯機器３との間で通信が確立した以降に、それぞれの装置において所定の周期（例えば、１／１０秒）で繰り返し実行される。また、車載装置２と携帯機器３との間で通信を確立した際（図１１の処理の開始前）には、その時点の車両９の位置を中心とするアプリ地図Ｍ２が車載装置２から携帯機器３に送信され、携帯機器３のＲＡＭに記憶されているものとする。
【００９８】
車載装置２においては、まず、車両情報取得部５１が、車両情報センサ２２から入力される信号に基づいて車両９の位置及び進行方向を取得する（ステップＳ１１）。車両情報取得部５１は、取得した車両９の位置及び進行方向を、ナビゲーション部５４、ナビ地図調整部５３、及び、車両情報送信部５５に出力する。
【００９９】
次に、車両情報送信部５５が、車両９の位置及び進行方向を無線通信部２６を介して携帯機器３に送信する（ステップＳ１２）。
【０１００】
また、ディスプレイ２５が、ナビゲーション機能に向けたナビ地図Ｍ１を表示する（ステップＳ１３）。具体的には、まず、ナビ地図調整部５３が、ナビ地図取得部５２が生成するナビ地図Ｍ１のパラメータを調整する。ナビ地図調整部５３は、車両９の位置に応じてナビ地図Ｍ１の位置を調整するとともに、表示するナビ地図Ｍ１の向きがヘディングアップの場合は車両９の進行方向に応じてナビ地図Ｍ１の向きを調整する。また、ナビ地図調整部５３は、操作部２３を介してユーザからナビ地図Ｍ１の縮尺や向きの変更の指示がなされた場合は、ユーザの指示に従ってナビ地図Ｍ１の縮尺や向きを変更する。
【０１０１】
そして、ナビ地図取得部５２が、ナビ地図調整部５３で調整されたパラメータに従って、表示すべきナビ地図Ｍ１を生成する。さらに、ナビゲーション部５４が、生成されたナビ地図Ｍ１に自車位置マークなどを重畳した後、ナビ地図Ｍ１をディスプレイ２５に出力する。これにより、ディスプレイ２５に、ナビゲーション機能に向けたナビ地図Ｍ１が表示される。
【０１０２】
また、ナビゲーション部５４は、ナビゲーション機能を実行する（ステップＳ１４）。例えば、ナビゲーション部５４は、車両９の位置に応じて曲がるべき交差点などをユーザに案内する。
【０１０３】
車載装置２は、携帯機器３から地図要求信号を受信しない場合は（ステップＳ１６にてＮｏ）、このようなステップＳ１１〜Ｓ１４の処理を所定の周期で繰り返す。したがって、ステップＳ１２が繰り返され、車両情報送信部５５は、車両９の位置及び進行方向を所定の周期で繰り返し携帯機器３に送信することになる。これにより、携帯機器３には、その時点の車両９の位置及び進行方向がほぼリアルタイムに伝達される。
【０１０４】
一方、携帯機器３においては、まず、無線通信部３５が、車載装置２から送信された車両９の位置及び進行方向を受信する（ステップＳ２１）。
【０１０５】
次に、ディスプレイ３４が、アプリ機能に向けたアプリ地図Ｍ２を表示する（ステップＳ２２）。具体的には、アプリケーション部３７が、ＲＡＭに記憶されたアプリ地図Ｍ２から表示すべき範囲の表示領域ＶＡ２を切り出し、表示用のアプリ地図Ｍ２を生成する。そして、アプリケーション部３７は、このアプリ地図Ｍ２の車両９の位置に車両９の進行方向へ向けて自車位置を示す自車位置マークを重畳する。この自車位置マークは、ナビ地図Ｍ１に重畳されるものとは異なる自動車のイラストのようなマークとされる。さらに、アプリケーション部３７は、このアプリ地図Ｍ２にアプリ機能に必要なアイコンや文字情報等を重畳した後、アプリ地図Ｍ２をディスプレイ３４に出力する。これにより、ディスプレイ３４にアプリ機能に向けたアプリ地図Ｍ２が表示される。
【０１０６】
また、アプリケーション部３７は、例えば、観光案内、クイズゲーム、宝探しゲームなどの地図を利用するアプリ機能を実行する（ステップＳ２３）。
【０１０７】
携帯機器３には、その時点の車両９の位置がほぼリアルタイムに伝達されていることから、アプリケーション部３７は、このようなアプリ機能として、その時点の車両９の位置に応じた機能を提供することができる。例えば、アプリ機能がクイズゲームの場合においては、車両９の位置の周囲の一定範囲に存在するスポットに関するクイズをユーザに出題することができる。この場合は、例えば、クイズを出題可能なスポットの地図上の位置にアイコンが配置され、このアイコンにユーザが触れた場合に、当該スポットのクイズが出題される。
【０１０８】
また、このようなアプリ機能を実行している状態において、地図要求部３７１が、新たなアプリ地図Ｍ２の要求の要否を判断する（ステップＳ２４）。地図要求部３７１は、以下の（ａ）〜（ｃ）の場合などにおいて、新たなアプリ地図Ｍ２の要求が必要と判断する。
【０１０９】
（ａ）車両９の移動により、表示領域ＶＡ２の端部がＲＡＭに記憶されたアプリ地図Ｍ２の端部に近接した場合。
【０１１０】
（ｂ）スクロール指示の操作により、表示領域ＶＡ２とすべき範囲がＲＡＭに記憶されたアプリ地図Ｍ２から外れる場合。
【０１１１】
（ｃ）アプリ機能において縮尺の変更が必要となった場合。
【０１１２】
地図要求部３７１が、新たなアプリ地図Ｍ２の要求が不要と判断した場合は（ステップＳ２５にてＮｏ）、処理は終了する。一方、地図要求部３７１が、新たなアプリ地図Ｍ２の要求が必要と判断した場合は（ステップＳ２５にてＹｅｓ）、無線通信部３５を介して地図要求信号を車載装置２に送信する。この地図要求信号には、必要なアプリ地図Ｍ２の位置、及び、縮尺などを指定する指定情報が含まれる（ステップＳ２６）。
【０１１３】
このようにして携帯機器３から送信された地図要求信号は、車載装置２の要求受信部５６により受信される（ステップＳ１５）。
【０１１４】
このように要求受信部５６が携帯機器３から地図要求信号を受信した場合は（ステップＳ１６にてＹｅｓ）、要求受信部５６は、この地図要求信号に含まれる指定情報をアプリ地図調整部５８に入力する。これとともに、要求受信部５６は、地図要求信号をアプリ地図取得部５７に入力する。
【０１１５】
次に、この地図要求信号に応答して、新たなアプリ地図Ｍ２が生成される（ステップＳ１７）。具体的には、まず、アプリ地図調整部５８が、アプリ地図取得部５７が生成するアプリ地図Ｍ２のパラメータを調整する。アプリ地図調整部５８は、指定情報が指定する位置及び縮尺に従ってアプリ地図Ｍ２の位置及び縮尺を変更する。そして、アプリ地図取得部５７が、このようなアプリ地図調整部５８で調整されたパラメータに従って、新たなアプリ地図Ｍ２を生成する。
【０１１６】
次に、アプリ地図送信部５９が、生成された新たなアプリ地図Ｍ２を、無線通信部２６を介して携帯機器３に送信する（ステップＳ１８）。これにより、ディスプレイ２５においてナビ地図Ｍ１の表示中に、携帯機器３から指定された位置のアプリ地図Ｍ２が携帯機器３に送信される。このアプリ地図Ｍ２の位置は、その時点でディスプレイ２５に表示中のナビ地図Ｍ１の位置とは無関係な位置とすることができる。
【０１１７】
送信された新たなアプリ地図Ｍ２は、携帯機器３の無線通信部３５により受信される（ステップＳ２７）。受信された新たなアプリ地図Ｍ２は、制御部３１のＲＡＭに記憶され、以降の処理に利用されることになる。
【０１１８】
以上のように、第１の実施の形態の車載装置２では、ディスプレイ２５が、車載装置２で実行されるナビゲーション機能に向けたナビ地図Ｍ１を表示する。また、このようにディスプレイ２５がナビ地図Ｍ１を表示中に、アプリ地図送信部５９が、携帯機器３で実行されるアプリ機能に向けたアプリ地図Ｍ２を携帯機器３に送信する。このため、車載装置２のユーザはナビゲーション機能のためにナビ地図Ｍ１を利用でき、同時に、携帯機器３のユーザはアプリ機能のためにアプリ地図Ｍ２を利用できる。すなわち、車載装置２のユーザと携帯機器３のユーザとがそれぞれ、互いに異なる機能のために地図を同時に利用することができる。
【０１１９】
また、車両情報送信部５５が、車両９の位置を所定の周期で携帯機器３に送信する。このため、その時点の車両９の位置がほぼリアルタイムに携帯機器３に伝達され、携帯機器においてその時点の車両９の位置に応じたアプリ機能を提供できる。
【０１２０】
また、アプリ地図送信部５９は、携帯機器３から送信された地図要求信号に含まれる指定情報が指定する位置のアプリ地図Ｍ２を携帯機器３に送信する。このため、その時点で車載装置２において表示されているナビ地図Ｍ１の位置とは無関係に、携帯機器３において必要とする位置のアプリ地図Ｍ２を携帯機器３において利用することができる。
【０１２１】
また、アプリ地図送信部５９は、携帯機器３が有するディスプレイ３４の表示サイズよりも大きなサイズのアプリ地図Ｍ２を携帯機器３に送信する。このため、表示領域ＶＡ２を変更する場合であっても、新たなアプリ地図Ｍ２を車載装置２から携帯機器３に送信する必要がない。このため、変更後の表示領域ＶＡ２の範囲のアプリ地図Ｍ２を速やかに表示できる。
【０１２２】
また、ナビ地図Ｍ１とアプリ地図Ｍ２とは、共通の地図データベース２４１に基づいて取得される。このため、ナビ地図Ｍ１のための地図データベースと、アプリ地図Ｍ２のための地図データベースとをそれぞれ個別に準備する必要がなく、地図データベースを記憶する記憶部２４に必要な記憶容量を低減できる。
【０１２３】
また、ナビ地図Ｍ１の向きはヘディングアップとノースアップとのいずれかに変更可能である一方で、アプリ地図Ｍ２の向きはノースアップに固定される。このように、アプリ地図Ｍ２の向きをノースアップに固定することで、車両９の進行方向が変わるたびに、新たなアプリ地図Ｍ２を車載装置２から携帯機器３に送信する必要がない。このため、車載装置２から携帯機器３に送信するデータ量を低減できる。また、携帯機器３を扱うユーザが子供である場合には、アプリ地図Ｍ２の向きが一般的なノースアップとなるため、ユーザはアプリ地図Ｍ２が示す情報を理解しやすくなる。
【０１２４】
＜２．第２の実施の形態＞
次に、第２の実施の形態について説明する。第１の実施の形態では、ナビ地図Ｍ１とアプリ地図Ｍ２とは、共通の地図データベース２４１に基づいて取得されていた。これに対して、第２の実施の形態では、ナビ地図Ｍ１とアプリ地図Ｍ２とは、それぞれ専用の地図データベースに基づいて取得されるようになっている。第２の実施の形態の車内通信システム１０の構成及び処理は第１の実施の形態とほぼ同様であるため、以下、第１の実施の形態との相違点を中心に説明する。
【０１２５】
図１２は、第２の実施の形態の車載装置２の構成を示す図である。第２の実施の形態の車載装置２は、第１の実施の形態の記憶部２４に変えて、２つの記憶部２４ａ、２４ｂを備えている。これら２つの記憶部２４ａ，２４ｂは、例えばフラッシュメモリなど、各種のデータを記憶可能な不揮発性のメモリである。
【０１２６】
第１記憶部２４ａは、ナビ地図データベース２４３と、プログラム２４２とを記憶している。一方、第２記憶部２４ｂは、アプリ地図データベース２４４を記憶している。ナビ地図データベース２４３は、ナビ地図Ｍ１専用の地図データベースであり、ナビ地図Ｍ１の生成に必要な地図基礎データを含んでいる。一方、アプリ地図データベース２４４は、アプリ地図Ｍ２専用の地図データベースであり、アプリ地図Ｍ２の生成に必要な地図基礎データを含んでいる。
【０１２７】
このため、ナビ地図取得部５２は、ナビ地図データベース２４３に基づいてナビ地図Ｍ１を取得することになる。一方、アプリ地図取得部５７は、アプリ地図データベース２４４に基づいてアプリ地図Ｍ２を取得する。このように、本実施の形態においては、ナビ地図Ｍ１とアプリ地図Ｍ２とが異なる地図データベースに基づいて取得されるため、ナビゲーション機能とは無関係に、携帯機器３のアプリ機能に最適化したアプリ地図Ｍ２を容易に取得することができる。
【０１２８】
また、第１の実施の形態と同様に、ナビ地図調整部５３は、１０種類の縮尺の候補のいずれかにナビ地図Ｍ１の縮尺を変更する。一方で、アプリ地図調整部５８は、１０種類のよりも少ない２種類の縮尺の候補のいずれかにアプリ地図Ｍ２の縮尺を変更する。
【０１２９】
地図データベース２４３，２４４では、地図基礎データが縮尺別に用意される。したがって、図１３に示すように、ナビ地図データベース２４３では、１０種類の縮尺に対応する地図基礎データＢｄ１が含まれている。これに対して、アプリ地図データベース２４４では、２種類の縮尺のみに対応する地図基礎データＢｄ２が含まれている。このように、アプリ地図のＭ２の縮尺の候補が１０種類より少ない２種類であるため、アプリ地図データベース２４４のデータ量を少なくすることができる。したがって、記憶部２４ｂとして必要となる記憶容量を低減することができる。
【０１３０】
なお、本実施の形態では、ナビ地図データベース２４３を記憶する記憶部とアプリ地図データベース２４４を記憶する記憶部とは異なっていたが、同一の記憶部がこれら２つの地図データベース２４３，２４４の双方を記憶するようにしてもよい。
【０１３１】
また、本実施の形態においても、アプリ地図Ｍ２の向きはノースアップに固定される。このため、主にベクタデータである地図基礎データではなく、そのまま地図として利用可能なラスタデータを、アプリ地図データベース２４４が含むようにしてもよい。このようにすれば、アプリ地図Ｍ２を生成する処理を、省略あるいは簡略化することができる。
【０１３２】
＜３．第３の実施の形態＞
次に、第３の実施の形態について説明する。上記実施の形態では、音の出力についての説明を行わなかったが、音の出力に関しても車載装置２と携帯機器３とで連携することが可能である。本実施の形態では、車載装置２と携帯機器３との連携による音の出力について説明する。なお、以下の説明では、車載装置２と携帯機器３との連携による地図の表示については詳細には言及しないが、地図の表示については第１あるいは第２の実施の形態のいずれかと同様の構成を採用し同様の処理を実行すればよい。
【０１３３】
＜３−１．車載装置の構成＞
まず、第３の実施の形態の車載装置２の構成について説明する。図１４は、第３の実施の形態の車載装置２の構成を示す図である。図１４においては、車載装置２の構成のうち、音の出力に関連する構成を主に示している。
【０１３４】
車載装置２は、第１の実施の形態と同様のディスプレイ２５、操作部２３、記憶部２４、無線通信部２６、及び、制御部２１の他に、放送受信部２７、ディスク読取部２８及び複数のスピーカ２９を備えている。
【０１３５】
放送受信部２７は、放送信号に基づく音の音声信号を取得する。放送受信部２７は、アンテナを備えており、アンテナで受信したラジオ放送などの放送信号をデコードし、放送内容となる音の音声信号を取得して制御部２１に入力する。
【０１３６】
ディスク読取部２８は、音声ディスクに基づく音の音声信号を取得する。ディスク読取部２８は、ＣＤなどの音声ディスクを読み取り、音声ディスクの記録内容となる音の音声信号を取得して制御部２１に入力する。
【０１３７】
複数のスピーカ２９は、制御部２１からの信号に基づいて車室内に音を出力する。車両９においては、例えば、前席の左右、及び、後席の左右にそれぞれスピーカ２９が配置され、車室内に合計４つのスピーカ２９が設けられている。
【０１３８】
車載装置２は、複数のスピーカ２９を介して、様々なソースの音を車室内に出力することが可能となっている。車載装置２は、出力する音のソースが互いに異なる複数の音声モードを備えている。複数の音声モードには、「放送モード」、「ディスクモード」及び「連携モード」が含まれている。
【０１３９】
「放送モード」は、放送信号に基づく音を出力するための音声モードである。「ディスクモード」は、音声ディスクに基づく音を出力するための音声モードである。また、「連携モード」は、携帯機器３で実行されるアプリ機能に関係する音を出力するための音声モードである。したがって、放送モード及びディスクモードでは、アプリ機能に関係する音はスピーカ２９から出力されない。連携モードでは、例えば、アプリ機能に係る音として、効果音、操作音、及び、ＢＧＭなどが出力される。連携モードでは、アプリ機能に係る音が車室内のスピーカから出力されるため、アプリ機能を実行する場合において臨場感のある音響効果を得ることができる。
【０１４０】
このようなアプリ機能に関係する音に必要な音声データは、予め記憶部２４に記憶される。本実施の形態の記憶部２４は、音声データベース２４５を記憶している。この音声データベース２４５は、アプリ機能に係る音に必要な音声データを含んでいる。
【０１４１】
また、制御部２１は、プログラム２４２に従ってＣＰＵが演算を行うことで実現される処理部として、ナビゲーション部５４及び要求受信部５６の他に、音声出力部６１、音声取得部６２、モード変更部６３、モード送信部６４、無効化受付部６５及び無効状態送信部６６を備えている。
【０１４２】
音声出力部６１は、複数のスピーカ２９を介して、その時点の音声モードに応じた音を出力する。放送モードにおいては、音声出力部６１は、放送受信部２７から入力される音声信号に基づいて放送信号に基づく音を出力する。ディスクモードにおいては、音声出力部６１は、ディスク読取部２８から入力される音声信号に基づいて音声ディスクに基づく音を出力する。また、連携モードにおいては、音声取得部６２から入力される音声信号に基づいて、携帯機器３で実行されるアプリ機能に関係する音を出力する。
【０１４３】
また、音声出力部６１は、音像を車室内の任意の位置に定位させることができる。音声出力部６１は、複数のスピーカ２９のそれぞれから出力する音の音量及び位相などを調整することで、車室内の任意の位置に音像を定位させる。このように音像を車室内のある位置に定位させた場合は、車両９の乗員は音像が定位した位置から音が聞こえてくると認識することになる。
【０１４４】
音声取得部６２は、音声データベース２４５に基づいて、アプリ機能に関係する音の音声信号を取得する。アプリ機能に関係する音の出力が必要な場合には、携帯機器３から音出力要求信号が送信され、この音出力要求信号は車載装置２の要求受信部５６によって受信される。音出力要求信号には、車載装置２で出力すべき音、音量、及び、音像を定位させる位置などを指定する指定情報が含まれている。音声取得部６２は、この指定情報に基づいて、出力すべき音の音声データを音声データベースＤＢ２４５から読み出す。そして、音声取得部６２は、読み出した音声データをデコードして音声信号を取得し、制御部２１に入力する。
【０１４５】
モード変更部６３は、音声モードを、放送モード、ディスクモード及び連携モードの３つの候補のいずれかに変更する。モード変更部６３は、操作部２３を介したユーザの指示に応じて音声モードを変更する。モード変更部６３は、変更後の音声モードを音声出力部６１に出力する。これにより、音声出力部６１は、その時点の音声モードに応じた音をスピーカ２９を介して出力することになる。
【０１４６】
モード送信部６４は、モード変更部６３により音声モードが変更された場合に、変更後の音声モードを示すモード信号を、無線通信部２６を介して携帯機器３に送信する。
【０１４７】
無効化受付部６５は、音声出力部６１の音の出力機能を無効化、あるいは、有効化する。車載装置２は、いわゆるミュート機能を備えており、ユーザの所望により音を無音とする（音の出力機能を無効化する）ことが可能である。音の出力機能が無効化されると、スピーカ２９から音が出力されなくなる。無効化受付部６５は、操作部２３を介したユーザの指示に応じて、音の出力機能の無効／有効を切り替える。
【０１４８】
無効化受付部６５は、音声モードが放送モード、ディスクモード及び連携モードのいずれの場合においても、音の出力機能の無効化、あるいは、有効化が可能である。音声モードが連携モードの場合に音の出力機能の無効化されると、アプリ機能に関係する音がスピーカ２９から出力されなくなる。
【０１４９】
無効状態送信部６６は、音声出力部６１の音の出力機能の無効／有効が変更された場合に、有効無効信号を無線通信部２６を介して携帯機器３に送信する。この有効無効信号は、音声出力部６１の音の出力機能の無効／有効を示す。例えば、音声出力部６１の音の出力機能が無効化された場合は、有効無効信号は音の出力機能が無効化されたことを示すことになる。
【０１５０】
＜３−２．携帯機器の構成＞
次に、第３の実施の形態の携帯機器３の構成について説明する。図１５は、第３の実施の形態の携帯機器３の構成を示す図である。図１５においては、携帯機器３の構成のうち、音の出力に関連する構成を主に示している。
【０１５１】
携帯機器３は、第１の実施の形態と同様のディスプレイ３４、操作部３２、無線通信部３５、記憶部３３、及び、制御部３１の他に、内蔵スピーカ３６を備えている。
【０１５２】
内蔵スピーカ３６は、携帯機器３の筐体内に設けられたスピーカである。内蔵スピーカ３６は、制御部３１からの信号に基づいて音を出力する。携帯機器３は、この内蔵スピーカ３６を介してアプリ機能に関係する音を自装置から出力することが可能である。
【０１５３】
また、アプリ機能を実行するアプリケーション部３７は、音出力変更部３７２を備えている。音出力変更部３７２は、アプリ機能に関係する音を、車載装置２のスピーカ２９から出力するか、内蔵スピーカ３６から出力するかを変更する。
【０１５４】
車載装置２の音声モードが連携モードの場合は、音出力変更部３７２は、原則として、アプリ機能に関係する音を車載装置２のスピーカ２９から出力させる。この場合は、音出力変更部３７２は、無線通信部３５を介して音出力要求信号を車載装置２に送信する。この音出力要求信号には、車載装置２で出力すべき音などを指定する指定情報が含まれている。
【０１５５】
また、このように車載装置２のスピーカ２９からアプリ機能に関係する音を出力させる場合は、内蔵スピーカ３６から同一の音の出力は停止される。すなわちこの場合、アプリ機能に関係する音は、車載装置２のスピーカ２９のみから出力されることになる。このため、携帯機器３の内蔵スピーカ３６と車載装置２のスピーカ２９とから同一の音が出力されて、適切な音響効果が得られなくなる現象（音像が定位する位置がずれるなど）が防止される。
【０１５６】
また、車載装置２の音声モードが連携モードの以外の場合は、アプリ機能に関係する音が車載装置２のスピーカ２９から出力されない。このため、この場合は、音出力変更部３７２は、アプリ機能に関係する音を内蔵スピーカ３６から出力させるなどの対応をとる。
【０１５７】
また、車載装置２の音声モードが連携モードの場合であっても、音声出力部６１の音の出力機能が無効化された場合は、アプリ機能に関係する音が車載装置２のスピーカ２９から出力されない。このため、この場合においても、音出力変更部３７２は、アプリ機能に関係する音を内蔵スピーカ３６から出力させる。
【０１５８】
このように携帯機器３は、車載装置２におけるアプリ機能に関係する音の出力状態に応じて、音の出力に関する動作を変更することが可能となっている。
【０１５９】
＜３−３．処理の流れ＞
次に、第３の実施の形態の車内通信システム１０の処理の流れを説明する。
【０１６０】
まず、車載装置２の処理について説明する。図１６は、車載装置２の音の出力に関する処理の流れを示す図である。この処理は、図１１に示す地図の表示に関する処理とは独立して実行される。また、図１６に示す処理は、所定の周期（例えば、１／１０秒）で繰り返される。図１６の処理の前には、車載装置２と携帯機器３との間で通信が確立しているものとする。
【０１６１】
図１６に示す処理が繰り返される間に、携帯機器３から音出力要求信号が送信された場合は、ステップＳ３１において、要求受信部５６がこの音出力要求信号を受信する。携帯機器３から音出力要求信号が送信されなかった場合は、このような受信処理はなされない。
【０１６２】
ステップＳ３２においては、音声出力部６１は、音声出力部６１の音の出力機能の無効／有効を判断する。音声出力部６１の音の出力機能が無効化されている場合は（ステップＳ３２にてＮｏ）、音声出力部６１が音を出力せずに、処理はそのままステップＳ３７へ進む。これに対し、音声出力部６１の音の出力機能が有効化されている場合は（ステップＳ３２にてＹｅｓ）、音声出力部６１が音声モードに応じた処理を行ってから、処理はステップＳ３７へ進む。
【０１６３】
音声出力部６１の音の出力機能が有効化されている場合は、まず、音声出力部６１が音声モードがいずれであるかを判断する（ステップＳ３３）。音声モードが連携モードではない場合（ステップＳ３３にてＮｏ）は、音声出力部６１は、その時点の音声モードに応じた音を車両９の車室内に出力する。すなわち、音声出力部６１は、放送モードの場合は放送信号に基づく音を出力し、ディスクモードの場合は音声ディスクに基づく音を出力する（ステップＳ３６）。
【０１６４】
一方、音声モードが連携モードの場合（ステップＳ３３にてＹｅｓ）は、音声出力部６１は、ステップＳ３１において音出力要求信号を受信したか否かを判断する（ステップＳ３４）。音出力要求信号を受信していた場合は、音声出力部６１は、その音出力要求信号に応じたアプリ機能に関係する音を車両９の車室内に出力する（ステップＳ３５）。
【０１６５】
具体的には、まず、音声取得部６２が、音出力要求信号に含まれる指定情報に基づいて、出力すべきアプリ機能に関係する音の音声データを音声データベースＤＢ２４５から読み出し、その音声データをデコードして音声信号を取得する。次に、音声出力部６１が、音声取得部６２が取得した音声信号に基づいて、アプリ機能に関係する音（効果音、操作音、及び、ＢＧＭなど）をスピーカ２９を介して出力する。
【０１６６】
前述のように、車載装置２においては、携帯機器３のアプリ機能に関係する音の音声データが予め記憶部２４に記憶されている。このため、アプリ機能に関係する音を車載装置２から出力する場合であっても、携帯機器３から車載装置２に比較的データ量の多い音声データを送信する必要はない。このため、携帯機器３から車載装置２に送信するデータ量を低減することができる。
【０１６７】
また、ステップＳ３７においては、モード変更部６３が、音声モードを変更するユーザの指示が操作部２３を介してなされたか否かを判定する。音声モードの変更の指示がない場合は（ステップＳ３７にてＮｏ）、処理はそのままステップＳ３９へ進む。
【０１６８】
一方、音声モードの変更の指示がある場合は（ステップＳ３７にてＹｅｓ）、モード変更部６３が、この指示に応じて音声モードを変更する。これとともに、モード送信部６４が、変更後の音声モードを示すモード信号を、無線通信部２６を介して携帯機器３に送信する（ステップＳ３８）。その後、処理はステップＳ３９へ進む。
【０１６９】
また、ステップＳ３９においては、無効化受付部６５が、音の出力機能の無効／有効を切り替えるユーザの指示が操作部２３を介してなされたか否かを判定する。音の出力機能の有効／無効の切替の指示がない場合は（ステップＳ３９にてＮｏ）、処理はそのまま終了する。
【０１７０】
一方、音の出力機能の有効／無効の切替の指示がある場合は（ステップＳ３９にてＹｅｓ）、無効化受付部６５が、この指示に応じて音声出力部６１の音の出力機能を有効化、あるいは、無効化する。これとともに、無効状態送信部６６が、音声出力部６１の音の出力機能の無効／有効を示す有効無効信号を、無線通信部２６を介して携帯機器３に送信する（ステップＳ４０）。その後、処理は終了する。
【０１７１】
次に、携帯機器３の処理について説明する。図１７は、携帯機器３の音の出力に関する処理の流れを示す図である。この処理は、図１１に示す地図の表示に関する処理とは独立して実行される。また、図１７に示す処理は、所定の周期（例えば、１／１０秒）で繰り返される。また、車載装置２と携帯機器３との間で通信を確立した際（図１７の処理の開始前）には、その時点の音声モードを示すモード信号、及び、その時点の音の出力機能の無効／有効を示す有効無効信号が車載装置２から携帯機器３に送信されるものとする。
【０１７２】
図１７に示す処理が繰り返される間に、車載装置２からモード信号が送信された場合は、ステップＳ５１において、無線通信部３５がこのモード信号を受信する。また、車載装置２から有効無効信号が送信された場合は、ステップＳ５２において、無線通信部３５がこの有効無効信号を受信する。車載装置２からいずれの信号も送信されなかった場合は、このような受信処理はなされない。
【０１７３】
ステップＳ５３においては、アプリケーション部３７が、実行中のアプリ機能において、効果音、操作音、及び、ＢＧＭなどのアプリ機能に関係する音の出力が必要か否かを判定する。アプリ機能に関係する音の出力が不要な場合は、そのまま処理は終了する（ステップＳ５３にてＮｏ）。
【０１７４】
一方、アプリ機能に関係する音の出力が必要な場合は（ステップＳ５３にてＹｅｓ）、次に、音出力変更部３７２が、直近に受信したモード信号に基づいて、車載装置２の音声モードがいずれであるかを判定する（ステップＳ５４）。
【０１７５】
車載装置２の音声モードが連携モードの場合は（ステップＳ５４にてＹｅｓ）、さらに、音出力変更部３７２が、直近に受信した有効無効信号に基づいて、車載装置２の音の出力機能の無効／有効を判定する（ステップＳ５５）。
【０１７６】
そして、車載装置２の音声モードが連携モードであり、かつ、車載装置２の音の出力機能の有効の場合は（ステップＳ５５にてＹｅｓ）、音出力変更部３７２は、音出力要求信号を無線通信部３５を介して車載装置２に送信する（ステップＳ５６）。この音出力要求信号には、出力すべき音などを指定する指定情報が含まれる。車載装置２は、この音出力要求信号に応答して、アプリ機能に関係する音を車両９の車室内に出力することになる。
【０１７７】
これに対して、車載装置２の音声モードが連携モードでない場合は（ステップＳ５４にてＮｏ）、音出力変更部３７２は、アプリ機能に関係する音を内蔵スピーカ３６から出力させる（ステップＳ５７）。また、車載装置２の音声モードが連携モードの場合であっても、車載装置２の音の出力機能が無効の場合は（ステップＳ５５にてＮｏ）、音出力変更部３７２は、アプリ機能に関係する音を内蔵スピーカ３６から出力させることになる（ステップＳ５７）。
【０１７８】
このように第３の実施の形態の携帯機器３は、車載装置２の音の出力状態に応じて音の出力に係る動作を変更するようになっている。すなわち、携帯機器３は、車載装置２がアプリ機能に関係する音を車室内のスピーカ２９から出力しない動作状態となった場合には、アプリ機能に関係する音を内蔵スピーカ３６から出力するようになっている。
【０１７９】
また、第３の実施の形態の車載装置２は、アプリ機能に関係する音を車室内のスピーカ２９から出力する連携モードと、アプリ機能に関係する音を車室内のスピーカ２９から出力しない他の音声モード（放送モード，ディスクモード）とを含む複数の候補のいずれかに音声モードを変更可能となっている。そして、車載装置２のモード送信部６４は、音声モードが変更された場合に、変更後の音声モードを示すモード信号を携帯機器３に送信する。したがって、携帯機器３は、車載装置２における音声モードに応じて、アプリ機能に関係する音の出力方法を変更することができる。
【０１８０】
また、車載装置２は、音声出力部６１の音の出力機能を無効化することが可能となっている。そして、車載装置２の無効状態送信部６６は、音の出力機能が無効化された場合に、その出力機能が無効化されたことを示す有効無効信号を携帯機器３に送信する。従って、携帯機器３は、車載装置２における音の出力機能が無効化されたことに応じて、アプリ機能に関係する音の出力方法を変更することができる。
【０１８１】
＜３−４．音像の定位＞
前述のように、車載装置２の音声出力部６１は、音像を車室内の任意の位置に定位させることができる。車内通信システム１０においては、この機能を利用して、アプリ機能の効果音の音像を携帯機器３が指定する位置に定位させるようになっている。
【０１８２】
以下、アプリケーション部３７が実行するアプリ機能が宝探しゲームの場合を例に説明する。この宝探しゲームは、地図上のランダムな位置に設定された宝箱スポットを、定期的に出力されるアプリ機能の効果音に基づいて、ユーザに探し出させるものである。
【０１８３】
図１８〜図２０は、このアプリ機能の効果音を説明する図である。これら図１８〜図２０の図中の右側は、車両９の車室内ＶＳにおいて、効果音の音像が定位する位置（以下、「音像位置」という。）Ｐｓを示している。音像位置Ｐｓの矩形領域の大きさは、効果音の音量を示している。
【０１８４】
また、図１８〜図２０の図中の左側は、宝探しゲームに利用する地図であるゲーム地図ＭＳを示している。ゲーム地図ＭＳは、車両９の位置Ｐｖの周辺の地図である。図中、車両９の位置Ｐｖに付された矢印は、車両９の進行方向を示している。このゲーム地図ＭＳには、目的となる宝物スポットの位置Ｐａがランダムに設定される。
【０１８５】
このようなゲーム地図ＭＳのうち車両９の位置Ｐｖの近傍となる一部のみが、表示領域ＶＡ２（アプリ地図Ｍ２）として携帯機器３のディスプレイ２５に表示される。したがって、宝物スポットの位置Ｐａは通常はディスプレイ２５の表示範囲外になり、ユーザはゲーム地図ＭＳをスクロールさせて宝物スポットの位置Ｐａを探し出す。この際、ユーザは、アプリ機能の効果音を手がかりに、宝物スポットの位置Ｐａを探し出すことになる。
【０１８６】
この効果音の音量は、車両９の位置Ｐｖと宝箱スポットの位置Ｐａとの距離に基づいて定められる。また、効果音の音像位置Ｐｓは、車両９の進行方向を考慮して定められる。このような効果音の音量や音像位置Ｐｓを指定する指定情報は、アプリケーション部３７が送信する音出力要求信号に含まれている。
【０１８７】
まず、ゲーム地図ＭＳ上の車両９の位置Ｐｖと宝箱スポットの位置Ｐａとが、図１８の左側に示す関係にある場合を想定する。この場合は、車両９の位置Ｐｖと宝箱スポットの位置Ｐａとが比較的離れているため、図１８の右側に示すように、効果音の音量は比較的小さくなる。また、車両９の位置Ｐｖからみた宝箱スポットの位置Ｐａが、車両９の進行方向を基準にして左側にある。このため、図１８の右側に示すように、効果音の音像位置Ｐｓは、車室内ＶＳの前方の左側とされる。
【０１８８】
次に、ゲーム地図ＭＳ上の車両９の位置Ｐｖと宝箱スポットの位置Ｐａとが、図１９の左側に示す関係にある場合を想定する。この場合は、車両９の位置Ｐｖと宝箱スポットの位置Ｐａとが比較的近いため、図１９の右側に示すように、効果音の音量は比較的大きくなる。また、この場合も、車両９の位置Ｐｖからみた宝箱スポットの位置Ｐａが、車両９の進行方向を基準にして左側にある。このため、図１９の右側に示すように、効果音の音像位置Ｐｓは、車室内ＶＳの前方の左側とされる。
【０１８９】
また、ゲーム地図ＭＳ上の車両９の位置Ｐｖと宝箱スポットの位置Ｐａとが、図２０の左側に示す関係にある場合を想定する。この場合は、図１９の場合と比較して、ゲーム地図ＭＳ上の車両９の位置Ｐｖと宝箱スポットの位置Ｐａとの関係は同一であるが、車両９の進行方向が異なっている。このため、車室内ＶＳにおける効果音の音像位置Ｐｓも、図１９の場合と異なっている。すなわち、図２０の場合では、車両９の位置Ｐｖからみた宝箱スポットの位置Ｐａが、車両９の進行方向を基準にして若干右側となる。このため、効果音の音像位置Ｐｓは、車室内ＶＳの前方の若干右側とされる。
【０１９０】
ユーザは、このような効果音が聞こえてくる位置や音量を手がかりに宝物スポットの位置Ｐａを探し出すことができる。手がかりとなる効果音の音量や音像位置Ｐｓは、実際の車両９の位置や進行方向に基づいて定められるため、実際の車両９の走行とゲーム内容とが連動することになり、エンターテイメント性を高めることができる。
【０１９１】
ただし、前述のように、携帯機器３のディスプレイ２５に表示されるアプリ地図Ｍ２の向きはノースアップに固定される。このため、上記のように効果音の車室内ＶＳにおける音像位置Ｐｓを車両９の進行方向に基づいて定めた場合、表示されたアプリ地図Ｍ２の上方向と車両９の進行方向とが異なることから、ユーザが方向に関して混乱する可能性がある。
【０１９２】
このため、図２１に示すように、表示されたアプリ地図Ｍ２の上方向と車両９の進行方向とが異なる場合は、車両９の進行方向が上になるように携帯機器３自体を傾けるように案内するダイアログメッセージＤｍをディスプレイ２５に表示するようにしてもよい。このようにすれば、図２１の下部に示すように、車両９の進行方向が上になるようにユーザが携帯機器３自体を傾けることができる。この場合、表示されたアプリ地図Ｍ２の上方向と車両９の進行方向とが一致するため、ユーザが方向に関して混乱することを防止することができる。
【０１９３】
＜４．変形例＞
以上、本発明の実施の形態について説明してきたが、この発明は上記実施の形態に限定されるものではなく様々な変形が可能である。以下では、このような変形例について説明する。上記実施の形態及び以下で説明する形態を含む全ての形態は、適宜に組み合わせ可能である。
【０１９４】
上記実施の形態では、車両９で用いられる車両用装置として車載装置２を例に説明を行ったが、車両用装置が、ナビゲーション機能等を実行する携帯電話やスマートフォンなどの可搬性の通信装置であってもよい。
【０１９５】
また、上記実施の形態では、プログラム２４２に従ってＣＰＵが演算を行うことで、携帯機器３との連携に関係する処理部と、連携に関係しない処理部との双方が実現されていた。これに対して、連携に関係する処理部を実現するプログラムと、連携に関係しない処理部を実現するプログラムとが個別に存在していてもよい。また、上記実施の形態においてプログラムに従ってＣＰＵが演算を行うことで実現されるとした処理部の一部または全部は、電気的なハードウェア回路により実現されてもよい。
【０１９６】
また、上記実施の形態では、アプリ地図はナビ地図と比較して情報量が少なく内容が簡略化されていたが、アプリ地図をナビ地図と同一の情報量の地図としてもよい。
【０１９７】
また、上記実施の形態では、ナビ地図の縮尺の候補数は１０種類であり、アプリ地図の縮尺の候補数は２種類であったが、これらの候補数は例示である。ナビ地図の縮尺の候補数（Ｎ種類）に対して、アプリ地図の縮尺の候補数（Ｍ種類）が少なければ（Ｎ＞Ｍ）どのような数であってもよい。例えば、アプリ地図の縮尺の候補数は１種類であってもよい。
【０１９８】
また、上記実施の形態では、車載装置２において携帯機器３のアプリ機能に関係する音の音声データが予め記憶されていた。これに対して、車載装置２においてアプリ機能に関係する音の音声データを記憶させずに、携帯機器３から車載装置２に出力すべき音の音声データを送信するようにしてもよい。また、アプリ機能に関係する音のうち、一部の音のみの音声データを車載装置２に予め記憶させ、他の音の音声データは携帯機器３から車載装置２に送信するようにしてもよい。
【０１９９】
また、上記実施の形態では、携帯機器３の地図要求部３７１が、アプリ地図の要求の要否を判断していた。これに対して、車載装置２の制御部２１が、携帯機器３へのアプリ地図の送信の要否を判断するようにしてもよい。
【０２００】
また、上記実施の形態では、アプリ地図の向きはノースアップに固定されていたが、携帯機器３のディスプレイ３４に表示するアプリ地図の向きをノースアップとヘディングアップとで変更できるようになっていてもよい。携帯機器３で実行されるアプリ機能に応じて、ノースアップとヘディングアップとが選択されるようになっていてもよい。また、携帯機器３がディスプレイの画面を２以上備えている場合は、一の画面でノースアップのアプリ地図を表示させ、他の画面でヘディングアップのアプリ地図を表示させるようにしてもよい。
【符号の説明】
【０２０１】
２    車載装置
３    携帯機器
９    車両
１０    車内通信システム
５２    ナビ地図取得部
５３    ナビ地図調整部
５７    アプリ地図取得部
５８    アプリ地図調整部
５９    アプリ地図送信部
Ｍ１    ナビ地図
Ｍ２    アプリ地図
【図１】
0005989979.tif 000002
【図２】
0005989979.tif 000003
【図３】
0005989979.tif 000004
【図４】
0005989979.tif 000005
【図５】
0005989979.tif 000006
【図６】
0005989979.tif 000007
【図７】
0005989979.tif 000008
【図８】
0005989979.tif 000009
【図９】
0005989979.tif 000010
【図１０】
0005989979.tif 000011
【図１１】
0005989979.tif 000012
【図１２】
0005989979.tif 000013
【図１３】
0005989979.tif 000014
【図１４】
0005989979.tif 000015
【図１５】
0005989979.tif 000016
【図１６】
0005989979.tif 000017
【図１７】
0005989979.tif 000018
【図１８】
0005989979.tif 000019
【図１９】
0005989979.tif 000020
【図２０】
0005989979.tif 000021
【図２１】
0005989979.tif 000022