(57)【特許請求の範囲】
【請求項１】
複数のコンテンツと当該複数のコンテンツの各々に関連付けられた属性情報とを記憶する携帯端末と接続可能な接続手段と、
前記携帯端末が接続されたとき、前記携帯端末から各コンテンツの属性情報を取得する取得手段と、
前記取得手段により取得した属性情報を記憶する記憶手段と、
前記記憶手段により記憶された属性情報に基づきコンテンツの検索を可能にする検索手段と、
前記記憶手段を制御する制御手段とを有し、
前記制御手段は、前記記憶手段の空き容量が不足するか否かを判定し、不足すると判定した場合には、前記記憶手段から前記コンテンツに関連付けされた少なくとも１つの属性情報を削除する、電子装置。
【請求項２】
前記制御手段は、前記記憶手段の空き容量が一定以下になったことを検出したとき、空き容量が不足すると判定する、請求項１に記載の電子装置。
【請求項３】
前記制御手段は、前記属性情報の取得の割合を表す進捗率に基づき空き容量が不足するか否かを判定する、請求項１に記載の電子装置。
【請求項４】
前記制御手段は、前記進捗率と前記記憶手段の使用量との関係から空き容量が不足するか否かを判定する、請求項３に記載の電子装置。
【請求項５】
前記進捗率は、携帯端末から通知される、請求項３または４に記載の電子装置。
【請求項６】
前記記憶手段に複数の携帯端末から取得した属性情報が記憶されるとき、前記制御手段は、各携帯端末の属性情報の前記記憶手段の使用量に応じて各携帯端末の少なくとも１つの属性情報を削除する、請求項１に記載の電子装置。
【請求項７】
１つのコンテンツに対して複数の属性情報が関連付けされている場合に、前記制御手段は、前記複数の属性情報の中から予め決められた属性情報を削除する、請求項１に記載の電子装置。
【請求項８】
１つのコンテンツに対して複数種類の属性情報が関連付けされている場合に、前記制御手段は、前記複数種類の属性情報の中から優先度の低い種類の属性情報を削除する、請求項１に記載の電子装置。
【請求項９】
前記優先度は、複数種類の属性情報の各々に対して予め設定される、請求項８に記載の電子装置。
【請求項１０】
前記優先度は、複数種類の属性情報の使用頻度に基づき設定される、請求項８に記載の電子装置。
【請求項１１】
前記属性情報は、曲名、アーティスト名、アルバム名、ジャンル、作曲者名およびプレイリストの少なくとも１つを含み、前記制御手段は、アーティスト名、アルバム名、ジャンル、作曲者名、プレイリストを含む特定種別情報の中からいずれか１つの情報を削除する、請求項１ないし１０いずれか１つに記載の電子装置。
【請求項１２】
前記検索手段は、前記属性情報に基づき検索データベースを作成する、請求項１に記載の電子装置。
【請求項１３】
前記検索手段は、前記検索データベースに基づきコンテンツを検索するための検索画面を表示し、ユーザーは、当該検索画面を介してコンテンツの検索が可能である、請求項１２に記載の電子装置。
【請求項１４】
前記検索手段は、コンテンツの検索が行われたとき、当該コンテンツを識別する識別情報を前記携帯端末に出力する、請求項１ないし１３いずれか１つに記載の電子装置。
【請求項１５】
電子装置はさらに、前記検索手段の検索結果に応答して携帯端末から送信されたコンテンツを出力する出力手段を含む、請求項１ないし１４いずれか１つに記載の電子装置。
【請求項１６】
記憶手段、接続手段および制御手段を含む電子装置におけるデータベースの構築方法であって、
前記接続手段が複数のコンテンツと当該複数のコンテンツの各々に関連付けられた属性情報とを記憶する携帯端末を接続するステップと、
前記制御手段が前記接続手段を介して前記携帯端末から各コンテンツの属性情報を取得するステップと、
取得した属性情報を前記記憶手段の記憶スペースに記憶するとき、前記制御手段が当該記憶スペースの空き容量が不足するか否かを判定し、不足すると判定した場合には、各コンテンツについての少なくとも１つの属性情報を前記記憶スペースから削除するステップと、
前記制御手段が前記記憶スペースに記憶された属性情報に基づきコンテンツの検索用のデータベースを構築するステップと、
を有するデータベースの構築方法。
【請求項１７】
前記削除するステップは、前記記憶スペースの空き容量が一定以下になったことを検出したとき、空き容量が不足すると判定する、請求項１６に記載の構築方法。
【請求項１８】
前記削除するステップは、前記属性情報の取得の割合を表す進捗率に基づき空き容量が不足するか否かを判定する、請求項１６に記載の構築方法。
【請求項１９】
請求項１ないし１５いずれか１つに記載の電子装置と、
前記電子装置と接続可能な少なくとも１つの携帯端末とを有するシステムであって、
前記携帯端末は、複数のコンテンツと、当該複数のコンテンツの各々に関連付けされた属性情報とを記憶する記憶手段と、
前記電子装置を接続可能な接続手段と、
前記接続手段を介して前記電子装置に前記属性情報を提供する提供手段とを有する、システム。
【請求項２０】
前記携帯端末は、電子装置においてコンテンツが検索されたとき、電子装置から出力された前記識別情報に基づきコンテンツを電子装置に送信する送信手段を含む、請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のコンテンツと当該複数のコンテンツの各々に関連付けされた属性情報とを記憶した携帯端末と接続可能な電子装置に関し、特に、携帯端末の複数のコンテンツを検索するためのデータベースの構築に関する。
【背景技術】
【０００２】
スマートフォンに代表されるような多機能型携帯端末の普及に伴い、スマートフォンとナビゲーション等の車載装置とを連携させたシステムが実用化されている。例えば、スマートフォンの通信機能を利用して外部のネットワークに接続されたサーバー等から有用な道路交通情報を取得したり、スマートフォンに包含される機能を車載装置において利用可能にしている。
【０００３】
例えば、特許文献１は、外部メディアから検索情報を抽出し、検索情報に基づいて仮データベースを作成する車載装置を開示している。特許文献２は、コンテンツ記憶装置の空き容量が不足している場合は、コンテンツ記憶装置の容量が一杯になるまで可能な限りコンテンツを転送するか否かをユーザーに選択可能にさせる装置を開示している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−８３９１４号公報
【特許文献２】特開２００９−１７５８０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
スマートフォンは、例えば楽曲と、それに関連付けされた楽曲情報（例えば、曲名、アーティスト名、アルバム名、ジャンル、作曲者名など）を内蔵ストレージに記憶しており、車載装置側において、接続されたスマートフォンの楽曲の検索や再生を行う場合には、スマートフォンとの間のプロトコルに従わなければならないことがある。
【０００６】
図１（Ａ）は、従来の車載装置においてスマートフォンに格納された楽曲の検索を行うときの車載システムの一例を示す図である。車載装置１０にスマートフォン２０が接続されると、車載装置１０においてスマートフォン２０の楽曲検索機能が有効となる（Ｓ１０）。例えば、ユーザーからトラックリストの選択が入力されると、車載装置１０は、スマートフォン２０に対して、全トラック一覧の楽曲情報要求を行う。この楽曲情報は、コンテンツである楽曲に関連付けされた属性情報またはメタデータである。スマートフォン２０は、この要求に応じて、内蔵ストレージ２２のデータベース領域内で楽曲情報を検索し、検索した全トラック一覧の楽曲情報を車載装置１０へ通知する。車載装置１０は、通知された楽曲情報に基づき全トラック一覧のリストを表示する（Ｓ２０）。
【０００７】
図１（Ａ）に示す車載システムでは、スマートフォン２０が車載装置１０からの要求に応答して内蔵ストレージ２２の楽曲を検索する機能を有しているが、図１（Ｂ）に示す車載システムは、車載装置１０が楽曲検索機能を有している。図１（Ｂ）に示す車載システムでは、スマートフォン２０のプロトコルの要求事項として、全ての楽曲情報が車載装置１０に格納することができた場合に楽曲検索機能が有効化され、全ての楽曲情報が車載装置１０に格納することができない場合には楽曲検索機能が無効化されることが求められる。車載装置１０にスマートフォン２０が接続されると、スマートフォン２０から車載装置１０に対して全楽曲情報が通知される。車載装置１０は、送信された全楽曲情報を内蔵ストレージ１２に格納したとき、楽曲検索機能を有効にする（Ｓ３０）。楽曲検索機能が有効にされると、楽曲情報に基づき楽曲検索用のデータベースが作成され、当該データベースに基づき検索画面が表示される。ユーザーが検索画面からトラックリストの選択を入力すると、車載装置１０は、楽曲検索用のデータベースを参照して、全トラック一覧のリストを表示する（Ｓ４０）。
【０００８】
図１（Ｂ）に示す車載システムでは、車載装置１０に楽曲検索用のデータベースを作成することができれば、その後、スマートフォン２０と通信することなく、楽曲検索用のデータベースを参照して迅速な楽曲の検索を行うことができる。しかしながら、車載装置１０の内蔵ストレージ１２の容量は有限であるため、接続されるスマートフォン２０に保存されている楽曲数によっては、それに関連付けされた全ての楽曲情報を格納することができず、楽曲検索機能を有効化することができないという事態が生じ得る。その結果、ユーザーの利便性が損なわれてしまう。
【０００９】
本発明は、このような従来の課題を解決するものであり、ユーザーの利便性を改善する電子装置、データベースの構築方法およびシステムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係る電子装置は、複数のコンテンツと当該複数のコンテンツの各々に関連付けられた属性情報とを記憶する携帯端末と接続可能な接続手段と、前記携帯端末が接続されたとき、前記携帯端末から各コンテンツの属性情報を取得する取得手段と、前記取得手段により取得した属性情報を記憶する記憶手段と、前記記憶手段により記憶された属性情報に基づきコンテンツの検索を可能にする検索手段と、前記記憶手段を制御する制御手段とを有し、前記制御手段は、前記記憶手段の空き容量が不足するか否かを判定し、不足すると判定した場合には、前記記憶手段から前記コンテンツに関連付けされた少なくとも１つの属性情報を削除する。
【００１１】
好ましくは前記制御手段は、前記記憶手段の空き容量が一定以下になったことを検出したとき、空き容量が不足すると判定する。好ましくは前記制御手段は、前記属性情報の取得の割合を表す進捗率に基づき空き容量が不足するか否かを判定する。好ましくは前記制御手段は、前記進捗率と前記記憶手段の使用量との関係から空き容量が不足するか否かを判定する。好ましくは前記進捗率は、携帯端末から通知される。好ましくは前記記憶手段に複数の携帯端末から取得した属性情報が記憶されるとき、前記制御手段は、各携帯端末の属性情報の前記記憶手段の使用量に応じて各携帯端末の少なくとも１つの属性情報を削除する。好ましくは１つのコンテンツに対して複数の属性情報が関連付けされている場合に、前記制御手段は、前記複数の属性情報の中から予め決められた属性情報を削除する。好ましくは１つのコンテンツに対して複数種類の属性情報が関連付けされている場合に、前記制御手段は、前記複数種類の属性情報の中から優先度の低い種類の属性情報を削除する。好ましくは前記優先度は、複数種類の属性情報の各々に対して予め設定される。好ましくは前記優先度は、複数種類の属性情報の使用頻度に基づき設定される。好ましくは前記属性情報は、曲名、アーティスト名、アルバム名、ジャンル、作曲者名およびプレイリストの少なくとも１つを含み、前記制御手段は、アーティスト名、アルバム名、ジャンル、作曲者名、プレイリストを含む特定種別情報の中からいずれか１つの情報を削除する。好ましくは前記検索手段は、前記属性情報に基づき検索データベースを作成する。好ましくは前記検索手段は、前記検索データベースに基づきコンテンツを検索するための検索画面を表示し、ユーザーは、当該検索画面を介してコンテンツの検索が可能である。好ましくは前記検索手段は、コンテンツの検索が行われたとき、当該コンテンツを識別する識別情報を前記携帯端末に出力する。好ましくは電子装置はさらに、前記検索手段の検索結果に応答して携帯端末から送信されたコンテンツを出力する出力手段を含む。
【００１２】
本発明に係る電子装置におけるデータベースの構築方法は、複数のコンテンツと当該複数のコンテンツの各々に関連付けられた属性情報とを記憶する携帯端末を接続するステップと、前記携帯端末から各コンテンツの属性情報を取得するステップと、取得した属性情報を記憶スペースに記憶するとき、当該記憶スペースの空き容量が不足するか否かを判定し、不足すると判定した場合には、各コンテンツについての少なくとも１つの属性情報を前記記憶スペースから削除するステップと、前記記憶スペースに記憶された属性情報に基づきコンテンツの検索用のデータベースを構築するステップと、を有する。
【００１３】
本発明に係るシステムは、上記構成の電子装置と、前記電子装置と接続可能な少なくとも１つの携帯端末とを有するものであって、前記携帯端末は、複数のコンテンツと、当該複数のコンテンツの各々に関連付けされた属性情報とを記憶する記憶手段と、前記電子装置を接続可能な接続手段と、前記接続手段を介して前記電子装置に前記属性情報を提供する提供手段とを有する。好ましくは前記携帯端末は、電子装置においてコンテンツが検索されたとき、電子装置から出力された前記識別情報に基づきコンテンツを電子装置に送信する送信手段を含む。
【発明の効果】
【００１４】
本発明によれば、携帯端末から取得した属性情報を記憶する記憶手段の空き容量が不足するか否かを判定し、不足する場合には記憶手段から属性情報の一部を削除するようにしたので、電子装置が有する記憶容量に対して携帯端末が保持する属性情報が多い場合であっても、出来る限りのコンテンツの属性情報を記憶手段に記憶することが可能になる。その結果、電子装置において、携帯端末のコンテンツを検索するための機能を有効化することができる。
【図面の簡単な説明】
【００１５】
【図１】従来の車載システムの一例を示す図であり、図１（Ａ）は、スマートフォンが楽曲検索機能を備える例、図１（Ｂ）は、車載装置が楽曲検索機能を備える例を示す図である。
【図２】本発明の実施例に係る車載システムに一例を示す図である。
【図３】本発明の実施例に係る車載装置の構成例を示す図である。
【図４】本発明の実施例に係る携帯端末の典型的な構成例を示す図である。
【図５】携帯端末における楽曲データの構成例を説明する図である。
【図６】本発明の実施例に係る携帯端末の連携プログラムの機能的な構成を示すブロック図である。
【図７】本発明の実施例に携帯端末の楽曲情報の送信動作を説明するフローチャートである。
【図８】本発明の実施例に係る車載装置の連携プログラムの機能的な構成を示すブロック図である。
【図９】本発明の実施例に係る車載装置の楽曲情報の格納動作を説明するフローチャートである。
【図１０】本発明の実施例に係る車載システムの動作を説明する図である。
【図１１】本発明の実施例による楽曲情報の削除例を説明する図である。
【図１２】本発明の実施例による楽曲情報の削除例を説明する図である。
【図１３】本発明の実施例による楽曲の検索画面の例を示す図である。
【図１４】本発明の実施例による楽曲情報のデータ構成を示す図である。
【図１５】本発明の第２の実施例に係る車載システムを説明する図である。
【図１６】ストレージ使用量とＤＢ構築進捗率との関係を説明するグラフである。
【図１７】本発明の第３の実施例に係る車載システムを説明する図である。
【図１８】第３の実施例による楽曲情報削除部の削除例を示す図である。
【発明を実施するための形態】
【００１６】
次に、本発明の実施の形態について説明する。本発明に係るシステムは、電子装置と、当該電子装置に接続可能な少なくとも１つの携帯端末とを含む。本発明に係る電子装置は、好ましい形態では、車両等の移動体に搭載された車載装置、または移動体に持ち込むことができる車載装置であることができる。また、本発明に係る電子装置は、特に限定的なものではなく、汎用のコンピュータ装置、あるいは特定の用途（例えば、ナビゲーション機能、オーディオ・ビデオ再生機能、通信機能など）を包含するコンピュータ装置であることができる。本発明に係る携帯端末は、特に限定的なものではなく、スマートフォン、携帯電話、ウェアラブル端末、タブレット型端末、ポータブル端末、ラップトップ型端末等であることができる。本発明に係る携帯端末は、好ましい形態では、楽曲等のコンテンツを記憶し、記憶したコンテンツを再生する機能を包含する。
【実施例】
【００１７】
図２は、本発明の実施例に係る車載システムの一例を示す図である。本実施例の車載システム１００は、車載装置２００と、当該車載装置２００に接続手段３００を介して接続された携帯端末４００とを含む。接続手段３００は、車載装置２００と携帯端末４００との間で双方向のデータ通信を可能にし、その形態は、有線接続または無線接続のいずれであってもよい。無線接続は、例えば、Bluetooth（登録商標）、ＷｉＦｉ（登録商標）、無線ＬＡＮ、その他の通信手段であることができる。有線接続は、例えば、ＵＳＢ、Firewire、Thunderbolt、その他の通信手段であることができる。
【００１８】
図３は、本実施例に係る車載装置２００の典型的な構成を示すブロック図である。入力部２１０は、ユーザーからの入力を受け取り、これを制御部２８０へ提供する。入力部１００は、例えば、タッチパネル、入力キーデバイス、音声入力モジュール等を含む。ナビゲーション部２２０は、ＧＰＳ衛星から送信される位置情報や、車両に搭載されたジャイロセンサや加速度センサからの情報に基づき自車位置を検出し、自車位置周辺の道路地図を表示部２６０に表示した、目的地までの経路の探索や案内を行う。マルチメディア再生部２３０は、ＤＶＤ、ＣＤ、ブルーレイディスク等の記録媒体に記録されたビデオデータ、オーディオデータを再生する。再生されたビデオデータは、表示部２６０に表示され、オーディオデータは音声出力部２５０から出力される。
【００１９】
接続部２４０は、図２に示す接続手段３００を構成し、車載装置２００と携帯端末４００との間のデータの送受を可能にする。なお、図２には１つの携帯端末４００が接続される例を示しているが、複数の携帯端末４００を同時に接続することも可能であり、その場合、接続部２４０は、複数のチャンネルを介して各携帯端末４００と接続する。
【００２０】
音声出力部２５０は、マルチメディア再生部２３０により再生された音声データ、または携帯端末４００から接続部２４０を介して受信された音声データを出力する。表示部２６０は、マルチメディア再生部２３０により再生された画像データ、または携帯端末４００から接続部２４０を介して受信された画像データを出力する。記憶部２７０は、制御部２８０が実行するソフトウエア、携帯端末４００が接続されたときに携帯端末４００から送信される楽曲情報、ナビゲーション部２２０が必要とする地図データ、マルチメディア再生部２３０が再生するためのマルチメディアデータ等を記憶する。
【００２１】
制御部２８０は、マイクロプロセッサやマイクロコントローラを含み、ＲＯＭ／ＲＡＭあるいは記憶部２７０に記憶されたプログラム等を実行することにより各部を制御する。本実施例では、制御部２８０は、携帯端末４００が接続されたとき、携帯端末４００の格納されたコンテンツデータを検索するためのデータベースを構築するプログラムを実行する。このプログラムの詳細は、後述する。
【００２２】
図４は、携帯端末４００の典型的な構成を示すブロック図である。携帯端末４００は、ユーザーからの入力を受け取る入力部４１０、車載装置２００との接続を可能にする接続部４２０、公衆無線回線網等を通じて音声通話を可能にする通話部４３０、記憶部４７０に格納されたコンテンツデータまたは外部から取得したコンテンツデータの再生を行う再生部４４０、音声データを出力する音声出力部４５０、画像データを出力する表示部４６０、種々のデータやアプリケーションソフトウエア等を格納する記憶部４７０、および各部を制御する制御部４８０を含む。
【００２３】
携帯端末４００は、ユーザーからの入力等に応じて、記憶部４７０に格納されたコンテンツデータを再生し、これを音声出力部４５０や表示部４６０から出力させる機能を有する。コンテンツは、例えば、楽曲や映画などである。以下の説明は、コンテンツの一例として楽曲について説明する。図５に、楽曲データの構成例を示す。記憶部４７０に、複数の楽曲Ａ、Ｂ、…ｎ（ｎは、自然数）が格納されるとき、１つの楽曲は、当該楽曲を構成する音声データと、それに関連付けされた楽曲情報（属性情報またはメタ情報）とが記憶される。図５の例は、楽曲Ｂに関連付けされた楽曲情報を例示しており、楽曲情報は、楽曲Ｂの曲名等を含むトラック情報と、アーティスト名、アルバム名、ジャンル、作曲者名などを含む特定種別情報とを含む。さらに楽曲情報は、楽曲の再生順を規定したプレイリストを含むことができる。これらの楽曲情報は、楽曲Ａ、Ｂ、…ｎの検索をするときの検索子または検索条件として参照され得る。
【００２４】
携帯端末４００が単独で使用されるとき、再生部４４０は、記憶部４７０から読み出された楽曲の音声データを再生するが、携帯端末４００が接続手段３００を介して車載装置２００に接続されたとき、携帯端末４００は、車載装置２００における楽曲の検索に応じて音声データや画像データを車載装置２００へ送信し、車載装置２００は、受信した音声データや画像データを音声出力部２５０や表示部２６０から出力させる。
【００２５】
携帯端末４００の制御部４８０は、車載装置２００が接続されたとき、車載装置２００との連携を図るための連携プログラムを実行する。図６は、連携プログラム５００の機能的な構成を示すブロック図である。連携プログラム５００は、携帯端末４００が車載装置２００に接続されたことを検出する接続検出部５１０、接続検出部５１０により接続が検出されたとき、図５に示す全ての楽曲Ａ、Ｂ、…ｎの楽曲情報を接続部４２０を介して車載装置２００へ送信する楽曲情報送信部５２０、車載装置２００において楽曲の検索が行われたとき、車載装置２００から楽曲の検索結果（楽曲の識別情報を含む）を受け取る検索結果受取部５３０、検索結果受取部５３０で受け取られた検索結果に基づき楽曲を選択し、選択した楽曲の音声データを車載装置２００へ送信する音声データ送信部５４０を含む。
【００２６】
図７は、携帯端末４００における楽曲情報の送信動作を示すフローチャートである。接続検出部５１０により、携帯端末４００が車載装置２００に接続されたか否かが検出され（Ｓ１００）。この検出は、車載装置２００の認証等を包含するものであってもよい。例えば、車載装置２００に携帯端末４００が初めて接続される場合に、両機器のペアリングを行ったり、あるいは、携帯端末４００に登録されている認証情報と車載装置２００の識別情報が一致するか否かのような判定動作を含むものであってもよい。
【００２７】
接続検出部５１０により接続が検出されると、楽曲情報送信部５２０は、記憶部４７０に格納されている全楽曲Ａ、Ｂ、…ｎに関連付けされた楽曲情報を車載装置２００へ送信する。車載装置２００へ送信された楽曲情報は、車載装置２００において携帯端末４００の全楽曲Ａ、Ｂ、…ｎを検索するときに参照される。
【００２８】
次に、車載装置２００側の携帯端末４００との連携について説明する。図８は、車載装置２００の制御部２８０が実行する連携プログラム６００の機能的な構成を示すブロック図である。連携プログラム６００は、車載装置２００が携帯端末４００に接続されたことを検出する接続検出部６１０、接続検出部６１０により接続が検出されたとき、楽曲情報送信部５２０から送信された楽曲情報を受信する楽曲情報受信部６２０、楽曲情報受信部６２０で受信した楽曲情報を記憶部２７０に記憶する楽曲情報記憶部６３０、楽曲情報を記憶する記憶スペースの空き容量が不足するか否かを判定する空き容量判定部６４０、空き容量判定部６４０の判定結果に基づき記憶部２７０に記憶された楽曲情報の一部を削除する楽曲情報削除部６５０、記憶された楽曲情報に基づき楽曲検索用のデータベース（ＤＢ）を作成する検索ＤＢ作成部６６０、検索データベースに基づき検索画面を表示する検索画面表示部６７０、楽曲の検索結果（楽曲の識別情報を含む）を携帯端末４００に送信する検索結果送信部６８０、携帯端末４００から送信された音声データを受け取り、音声データを音声出力部２５０から出力させる音声データ出力部６９０を含んで構成される。
【００２９】
図９は、車載装置２００の連携プログラム６００の動作フローを示し、図１０は、車載システムにおいて、車載装置２００と携帯端末４００との間のデータの流れを示している。
【００３０】
先ず、接続検出部６１０により車載装置２００が携帯端末４００に接続されたか否かが検出される（Ｓ２００）。この検出は、携帯端末４００の認証を包含するものであってもよい。例えば、携帯端末４００に車載装置２００が初めて接続される場合に、両機器のペアリングを行ったり、あるいは、車載装置２００に登録されている認証情報と携帯端末４００の識別情報が一致するか否かのような判定を含むようにしてもよい。
【００３１】
車載装置２００と携帯端末４００とが接続されると、上記したように携帯端末４００は、保存されている全楽曲に関連付けされた楽曲情報の送信を開始し、楽曲情報受信部６２０は、接続部２４０を介して楽曲情報を受信する（Ｓ２１０）。図５の例で言えば、楽曲Ａ、Ｂ、…ｎに関連付けされた楽曲情報が受信される。１つの例では、楽曲情報受信部６２０は、バッファメモリを含み、携帯端末４００から送信される楽曲情報をバッファメモリに逐次保持する。楽曲情報記憶部６３０は、楽曲情報受信部６２０で受信され楽曲情報を順次記憶部２７０に格納する（Ｓ２２０）。楽曲情報受信部６２０がバッファメモリを備えている場合には、バッファメモリから楽曲情報が順次読み出され、これが記憶部２７０に書込まれる。記憶部２７０には、楽曲情報を格納するための記憶スペースが予め設定されるが、この記憶スペースは、記憶部２７０の一部の記憶スペースが割り当てられたものであってもよい。例えば、記憶部２７０の記憶スペースが複数のパーティションに区分され、その１つのパーティションの記憶スペースに楽曲情報が記憶されるようにしても良い。
【００３２】
楽曲情報の格納の開始に伴い、空き容量判定部６４０は、楽曲情報を格納する記憶スペースを監視し、空きスペースが不足するか否かを判定する（Ｓ２３０）。空きスペースが十分であるとの判定を継続している間は、受信された楽曲情報は、逐次、記憶部２７０内に格納される。一方、空きスペースが不足すると判定されると、楽曲情報削除部６５０は、記憶部２７０から特定の楽曲情報を削除し（Ｓ２４０）、空きスペースの容量を回復させる。空きスペースが不足するか否かを常時監視しながら、可能なかぎり、全楽曲の楽曲情報が格納できるようにする。全楽曲についての楽曲情報が格納されると（Ｓ２５０）、検索ＤＢ作成部６６０は、携帯端末４００が保持する楽曲の検索が有効であると判定する（Ｓ２６０）。検索ＤＢ作成部６６０は、格納した全ての楽曲情報に基づき検索データベースを作成し（Ｓ２７０）、検索画面表示部６７０は、検索データベースに基づき検索画面を表示部２６０に表示する（Ｓ２８０）。ユーザーは、この検索画面を利用して、携帯端末４００に保持されている楽曲の検索を行うことができる。この検索は、車載装置側において行われ、携帯端末４００との通信を要しない。
【００３３】
次に、特定の楽曲情報の削除について説明する。図１１（Ａ）は、車載装置の記憶スペースに格納された楽曲情報の構成例を示している。各々の楽曲情報は、識別ＩＤ＃１、ＩＤ＃２、・・・ＩＤ＃ｎによって識別され、１つの楽曲情報は、トラック情報（曲名等）と特定種別情報（アーティスト名、アルバム名、ジャンル、作曲者名、プレイリストなど）とを含む。
【００３４】
楽曲情報削除部６５０は、空きスペースが不足すると判定された場合、楽曲情報に含まれる少なくとも１つの情報を削除する。どの情報を削除するかは、任意に設定可能であるが、１つの好ましい例では、特定種別情報の少なくとも１つの種類の情報が削除される。トラック情報(曲名)は、検索結果である楽曲を識別するために必要な情報を含むため、楽曲情報削除部６５０は、曲名は削除しない。例えば、図１１（Ｂ）に示すように、特定種別情報の一部である「作曲者名」が削除される。楽曲情報は、楽曲を検索するための検索子または検索条件として利用されるが、この中から、楽曲検索にあまり利用されないであろう情報が削除されるように予め設定される。楽曲情報削除部６５０により楽曲情報の一部が削除された場合、それ以後に格納される残りの楽曲情報からも同一の情報が取り除かれた状態で格納される。例えば、記憶スペースから、「作曲者名」が削除された場合、残りの楽曲情報を格納する際に「作曲者名」は格納されない。
【００３５】
また、楽曲情報削除部６５０は、特定種別情報の中から複数種類の情報を削除することも可能である。例えば、空き容量判定部６４０により空き容量が不足すると判定され、楽曲情報削除部６５０が１種類の情報を削除した後、残りの楽曲情報を格納する過程で、再び空き容量判定部６４０により空き容量が不足すると判定されることがある。この場合、楽曲情報削除部６５０は、次の種類の情報を削除し、空きスペースの残容量を増加させる。特定種別情報の中から複数種類の情報を削除する場合、どの種類の情報から削除するのかを表す優先度を予め設定しておくことが望ましい。図１１（Ｃ）の例では、「作曲者名」と「アルバム名」が削除される例を示しており、この場合、例えば、「作曲者名」が先に削除され、その次に「アルバム名」が削除されるような優先度が設定される。
【００３６】
上記は、各楽曲情報において共通の情報を削除する例を示したが、これに限らず、楽曲情報の使用頻度が少ない種類の情報を削除するようにしてもよい。この場合、連携プログラム６００は、ユーザーが楽曲の検索を行うときに使用した楽曲情報の履歴を保持するための履歴保持部を備える。履歴保持部は、楽曲情報の各種の情報の使用履歴を保持し、楽曲情報削除部６５０は、空き容量が不足すると判定されたとき、使用頻度の少ない種類の情報、または全く使用されていない情報から削除する。図１２（Ａ）は、楽曲情報の使用履歴の一例であり、ＩＤ＃１、ＩＤ＃４の楽曲情報のジャンルの「Ｐｏｐ」が検索に使用され、ＩＤ＃２、ＩＤ＃３の楽曲情報では、作曲者名の「Ｂ」、「Ｃ」が検索に使用されたことを表している（ハッチング表示）。この場合、楽曲情報削除部６５０は、図１２（Ｂ）に示すように、ＩＤ＃１、ＩＤ＃４の楽曲情報の中から、使用されていない作曲者名「Ａ」、「Ｄ」を削除し、ＩＤ＃２、ＩＤ＃３の楽曲情報の中から、使用されていないジャンルの「Ｒｏｃｋ」を削除する。このような削除を実施することで、ユーザーが使用するであろう種類の情報を残し、検索の利便性が低下するのを防止することができる。
【００３７】
次に、楽曲の検索方法について説明する。検索ＤＢ作成部６６０は、楽曲情報記憶部６３０により全楽曲の楽曲情報が格納されると、携帯端末４００の保持された楽曲を検索するための検索ＤＢを作成する。検索画面表示部６７０は、作成された検索ＤＢに基づき検索画面を作成し、これを表示部２６０に表示する。図１３に検索画面の表示例を示す。図１３（Ａ）は、楽曲情報の全てが格納されたときの例であり、検索画面には、楽曲情報として、アーティスト名、アルバム名、曲名、ジャンル、作曲者名、ポッドキャストおよびプレイリストのすべての情報が検索項目として表示される。ユーザーは、これらの検索項目を利用して楽曲を検索することができる。一方、図１３（Ｂ）は、楽曲情報削除部６５０により「ジャンル」と「作曲者名」の種類が削除されたときの検索画面であり、検索画面には、「ジャンル」、「作曲者名」が非表示になるか、あるいは検索子として機能しない。
【００３８】
検索画面を通じて楽曲の検索が行われると、その検索結果（例えば、楽曲を識別するためのトラック情報など）が携帯端末４００に送信される。携帯端末４００は、検索結果に基づき楽曲を選択し、選択された楽曲の音声データを車載装置２００に送信し、音声データ出力部６９０は、音声データを音声出力部２５０から出力させる。
【００３９】
次に、本実施例の効果について説明する。図１４は、楽曲情報の詳細な構成とそのデータサイズ（バイト）を示す。楽曲情報の曲名は、トラック情報を含み、トラック情報は、トラックＩＤ、トラックタイトル、属性、トラック番号、アルバム識別、アーティスト識別、作曲者識別、ジャンル識別、タイムスタンプ等を含み、１つのトラック情報のサイズは、３０７バイトである。また、楽曲情報に含まれるアーティスト名、アルバム名、ジャンル、作曲者名の各々は、特定種別情報であり、これは、識別情報（ＩＤ）、名前、属性等を含み、１つの特定種別情報のサイズは、２６９バイトであり、１つの楽曲情報に含まれる特定種別情報のサイズは、１，０７６バイトである。
【００４０】
例えば、携帯端末４００に、総曲数が３２，０００の楽曲が保持され、それらのアルバム名が重複しないと仮定したとき、楽曲情報は、１，３８３バイト／曲×３２，０００曲＝約４２ＭＢ／デバイスとなる。本実施例により、１つの特定種別情報（例えば、ジャンル）を削除した場合、１，１１４バイト／曲×３２，０００曲＝役３３ＭＢ／デバイスとなる。この結果、約９ＭＢ／デバイスの記憶スペースの削減効果を得ることができる。仮に、車載装置２００が６つの携帯端末分の楽曲情報を保持する仕様であれば、約５４ＭＢの記憶スペースの削減が可能となる。
【００４１】
次に、本発明の第２の実施例について説明する。上記実施例では、記憶スペースの空き容量が不足したときに、楽曲情報の一部を削除したが、第２の実施例では、進捗率と記憶スペースのストレージ使用量の推移からＤＢ構築完了までにストレージ残容量が不足することを予測した時点で、楽曲情報の一部を削除し、出来る限り多くの楽曲情報を車載装置に保持させることで、ユーザーの利便性の低下を最小限に抑える。
【００４２】
図１５は、第２の実施例を説明する図である。空き容量判定部６４０は、携帯端末４００から送信された楽曲情報が車載装置２００の記憶スペースに格納されると、そのＤＢ構築の進捗率とストレージ使用量に基づき、空き容量が不足するか否かを予測する。進捗率は、携帯端末４００が楽曲情報を送信するときに、携帯端末４００から車載装置２００に通知される。図１６は、進捗率とストレージ使用量との関係を示すグラフである。空き容量判定部６４０は、進捗率が２０％、４０％のときのストレージ使用量が２５％、５０％と推移するとき、その推移から進捗率が１００％になるときのストレージ使用量を予測する。図１６の例は、進捗率１００％に到達したとき、実績値からストレージ使用量が１２５％になることが示されている。それ故、空き容量判定部６４０は、進捗率１００％のとき、２５％の記憶スペースが不足すると予測する。楽曲情報削除部６５０は、この予測に基づき全楽曲の楽曲情報を格納するために、２５％の残容量を増加させるべく楽曲情報の削除を行う。これにより、必要最低限の楽曲情報が削除され、楽曲検索時の利便性の低下を最小限に抑えることができる。
【００４３】
第２の実施例において、楽曲情報削除部６５０は、必要最低限の楽曲情報を削減するように、楽曲情報において削除される情報の最適化を行う。つまり、各楽曲情報において、削除される情報は、均等である必要はない。例えば、ある楽曲情報の「作曲者名」が削除され、ある楽曲情報の「ジャンル」と「作曲者名」とが削除されるようにしてもよい。
【００４４】
次に、本発明の第３の実施例について説明する。車載装置２００には、複数の異なる携帯端末が接続されることがあり、車載装置２００は、複数の携帯端末の楽曲情報を格納する。第３の実施例は、複数の携帯端末の楽曲情報が格納されるとき、各携帯端末のストレージ使用量に応じた量の楽曲情報を削除し、可能な限り多くの携帯端末の楽曲情報が格納されるようにする。
【００４５】
図１７は、第３の実施例の動作を説明する図である。例えば、携帯端末Ａが車載装置２００に接続されると、車載装置２００の記憶スペースに携帯端末Ａの楽曲情報が格納され、別の携帯端末Ｂが接続されると、携帯端末Ｂの楽曲情報が同じ記憶スペースに格納される。空き容量判定部６４０は、例えば、２台目以降の携帯端末が接続されると、別の携帯端末Ｃの楽曲情報を格納するための空きスペースが不足するか否かを判定する。空き容量があると判定された場合には、楽曲情報削除部６５０は、特定種別の楽曲情報の削除を行わず、携帯端末Ｃが接続されると、車載装置の同じ記憶スペースに携帯端末Ｃの楽曲情報が格納される。空き容量判定部６４０は、さらなる携帯端末が接続されたとき、楽曲情報を格納するための空きスペースが不足するか否かを判定する。ここで、空き容量判定部６４０により空きスペースが不足すると判定された場合、楽曲情報削除部６５０は、携帯端末Ａ、Ｂ、Ｃの楽曲情報をそれらのストレージ使用量に応じて削除する。例えば、図１８（Ａ）に示すように、携帯端末Ａ、Ｂ、Ｃの各楽曲情報のサイズが１０ＭＢ、１５ＭＢ、２０ＭＢであると仮定したとき、楽曲情報削除部６５０は、使用量に応じて、例えば、１０％、１５％、２０％の割合で楽曲情報を削除する。あるいは、他の方法として、楽曲情報削除部６５０は、携帯端末Ａの１つの特定種別を削除し、携帯端末Ｂの２つの特定種別を削除し、携帯端末Ｃの３つの特定種別を削除するようにしてもよい。これにより、図１８（Ｂ）に示すように、記憶スペースの残容量が増加し、図１８（Ｃ）に示すように、携帯端末Ｄの楽曲情報の格納が可能になる。
【００４６】
上記実施例では、コンテンツとして楽曲とその楽曲情報を例示したが、本発明は、楽曲以外の情報（例えば、画像情報とそれに関連付けされた属性情報）にも同様に適用することができる。
【００４７】
以上、本発明の好ましい実施の形態について詳述したが、本発明は、特定の実施形態に限定されるものではなく、特許請求の範囲に記載された発明の要旨の範囲において、種々の変形、変更が可能である。
【符号の説明】
【００４８】
１００：車載システム                      ２００：車載装置
３００：接続手段                          ４００：携帯端末
５００：連携プログラム                    ６００：連携プログラム
【図１】
0006631996.tif 000002
【図２】
0006631996.tif 000003
【図３】
0006631996.tif 000004
【図４】
0006631996.tif 000005
【図５】
0006631996.tif 000006
【図６】
0006631996.tif 000007
【図７】
0006631996.tif 000008
【図８】
0006631996.tif 000009
【図９】
0006631996.tif 000010
【図１０】
0006631996.tif 000011
【図１１】
0006631996.tif 000012
【図１２】
0006631996.tif 000013
【図１３】
0006631996.tif 000014
【図１４】
0006631996.tif 000015
【図１５】
0006631996.tif 000016
【図１６】
0006631996.tif 000017
【図１７】
0006631996.tif 000018
【図１８】
0006631996.tif 000019