(57)【特許請求の範囲】
【請求項１】
オーディオデータを通信回線により送信する外部のオーディオ配信センターと接続する通信部と、
受信を希望する曲を選択するリクエスト選択部と、受信したオーディオデータを再生し出力するオーディオ再生部と、
受信したデータを記録するメモリと、該メモリを管理するメモリ管理部と、受信の中断及び受信が可能になったことを検出する受信状況検出部とを備え、
前記リクエスト選択部は、受信状況検出部で検出した受信中断期間が所定時間以内の時には中断時点の最終受信データ部分から送信要求を行い、所定時間を超えるときには他の指定したデータ部分の送信要求を行うことを特徴とする車載オーディオ装置。
【請求項２】
前記他の指定したデータ部分は、中断した曲の曲頭部分である請求項１記載の車載オーディオ装置。
【請求項３】
前記他の指定したデータ部分は、中断した曲とは異なる他の曲である請求項１記載の車載オーディオ装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、携帯電話等の通信手段を用い、多数のオーディオデータを蓄積したオーディオ配信センターに対して必要な曲をリクエストし、配信されたオーディオデータを聴きながらこれをダウンロードすることができる手段を備えた車載オーディオ装置に関する。
【０００２】
【従来の技術】
従来、車両で音楽を聴く場合には、カセットテープ、ＣＤ、ＭＤ等の音楽ソーースを用い、またラジオ等を用いて聴くのが一般的である。その際、ユーザが好みの音楽を聴くためには、前記のような音楽ソースを車両に持ち込み、車両搭載のオーディオ装置でこれを再生して聴くか、あるいはラジオによって放送された音楽を聴くこととなる。
【０００３】
また、最近では、音楽データ、即ちオーディオデータを有線や無線で配信することも行われ、一部では電話回線を用いたインターネットを通じてパソコンにより双方向通信を行い、また双方向通信式放送を通して送受信機により、ユーザがリクエストした所望のオーディオデータを受け取ることが既に行われている。この場合には、ユーザは所望の音楽データをオーディオ配信センターや放送局にリクエストし、配信、あるいは放送されたオーディオデータをＭＤ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ、メモリカード等にダウンロードし、これを車両に持ち込み、車載オーディオ装置によって再生することとなる。
【０００４】
このように、オーディオデータをインターネットや双方向通信式放送によりデータ記録媒体にダウンロードして聴くことは、今後の通信技術の発達、通信環境の整備、データ圧縮技術の進歩等によって、全世界規模で急速に拡大することが予測される。特に、パソコンの普及とインターネットの普及により、既に静止画、動画等の映像をインターネットから有料でダウンロードすることは通常行われており、ＣＤレベルの高音質のオーディオデータのダウンロードも容易に行われる環境となっている。
【０００５】
近年、安価なパソコンのハードディスクでも１０Ｇバイト程度のものを備えるようになっており、ＩＳＤＮ、光ケーブル利用等、高速大容量の通信環境も整いつつあるので、インターネットを介してオーディオデータをダウンロードすることはきわめて容易に行うことができる環境となっている。これらは通常、各家庭用の普通電話回線を用いて行われるものであるが、近年は携帯電話にもインターネット機能を備えるようになっており、携帯電話によりインターネットのデータをダウンロードする環境も整いつつあり、したがって、車載用オーディオ装置においても、携帯電話等を接続し、リクエストしたオーディオを聴き、また記憶媒体にオーディオデータを記録する音楽視聴方式が普及すると予想される。
【０００６】
【発明が解決しようとする課題】
車両におけるオーディオ装置においては、ユーザは車両に搭載しているオーディオ機器に応じて、カセットテープやＣＤ、ＭＤなどのオーディオ記録媒体を車両に持ち込んで、記録媒体に対応するプレーヤにかけて聴かなければならない。その場合、多くの曲の中から自分の所望するもののみを抽出して聴くときには、ユーザは事前に所望の音楽のＣＤやＭＤを購入し、あるいはＣＤやＭＤをレンタルしてそのまま利用するか、その中から所望の曲を選択しダビングして編集しておかなければならず面倒である。
【０００７】
それに対して、上記のように携帯電話等の通信手段を用い、聴きたい曲をリクエストして配信してもらいこれを聴くと共に、メモリ等にダウンロードすることが、安価に、且つ容易に行われるようになると非常に便利である。その点、上記のように、各種通信装置を用いて、利用者がリクエストしたオーディオデータをオーディオ配信センターから有料で配信するシステムの環境が整いつつあるので、車載オーディオ機器においても、これに対応する機能を備えることが望まれている。
【０００８】
その場合に考慮するべきことは、車両は広範囲に高速で移動するため、トンネルの中や、ビル群の中を走行しているときに、通信がたびたびとぎれるという点である。即ち、車載機器からユーザがオーディオ配信センターに所定の曲をリクエストし、これが携帯電話等により配信され、その音楽を聴いている途中で、またはこれをメモリにダウンロードしている途中で、トンネルの中やビル群の中等、電波の届きにくい領域に入ったときには、配信されているオーディオデータを受信できない状態が続くこととなる。
【０００９】
そのようなときには、ユーザ側が途中で受信できなくなったデータ部分を記憶しておき、受信できる環境になったときには再びオーディオ配信センターに受信できなくなった部分を指定してリクエスト信号を出力し、センター側ではその部分からの配信を開始することが考えられる。なお、ユーザとの通信が途中でとぎれれたことをオーディオ配信センター側が検出しこれをメモリするとともに、その時点でデータの送信を停止し、再度ユーザからのオーディオデータ配信要求を受信した際には、先にとぎれた部分から配信を再開することもできる。
【００１０】
上記の場合は、オーディオデータの配信中に電波がとぎれた後に再度配信を行う際に、通信がとぎれた部分から開始するようにしているが、電波がとぎれてから短時間で受信可能の状態になったときはそれでも充分の場合が多い。しかしながら、例えば１０分程度の長い時間受信不能状態が続いたときには、曲の途中から配信が再開された場合、単にダウンロードするだけの場合は良いが、これを実際に聴いている場合には適切ではないことが多い。このような場合は、曲の最初から聴くことが望まれ、あるいは別の曲を聴くことを望むことの方が多い。
【００１１】
一方、オーディオ配信センターには数万曲の大量のオーディオデータが保管されており、ユーザが特定の曲をリクエストするには、その中から曲名と演奏者あるいは歌手名を指定して、所望の特定の曲を選択する必要がある。しかしながら、曲名がわかっても演奏者や歌手名がわからないこと、また、演奏者や歌手名はわかっても曲名がわからないことも多い。このようなとき、曲名がわかっている場合においては、同一曲名であっても演奏者や歌手が異なる複数の曲が存在する場合には、いずれを選択すればよいのかわからないことがあり、また、演奏者や歌手名がわかっている場合においては、同一の演奏者や歌手で多数の曲が存在することが多いので特定の曲の選択が困難である場合が多い。したがって、このようなときには、間違った曲をリクエストしてしまうことも多く、曲が配信されてきて初めて間違いに気づくこととなり、そのときには既に使用料金等の面で手遅れとなっている。
【００１２】
更に、ユーザがメモリに配信されたオーディオデータをダウンロードしている場合には、上記のようにリクエストする曲が既にユーザのメモリ内に存在している場合も考えられる。その際には、無用なリクエストを行うこととなり、これも使用料金等の面で無駄である。更に、メモリの容量には限りがあるので、新たにリクエストしてこれをダウンロードしようとしたとき、空きメモリ容量が無いときにはこれをダウンロードすることができず、単にそのときに聴くだけとなってしまう。その際には、予め不要と思われる曲を削除してメモリ領域を確保してからダウンロードすることが望まれるが、このときユーザが消しては困る曲までも消してしまうこともありうる。更にこのとき、消される曲名等を表示して確認操作を行うことも考えられるが、曲名等だけではどのような曲であったかわからないこともあり、誤った曲を選択して消去してしまうこともあり得る。
【００１３】
したがって、本発明は、オーディオ配信センターに対して必要な曲をリクエストし、通信手段により配信されたオーディオデータを利用する際、オーディオデータの配信中に通信がとぎれたとき、任意の部分からオーディオデータの配信が可能な車載オーディオ装置を提供することを目的とし、また、多くの曲から特定の曲を容易に選択することができるようにし、また、配信されたオーディデータのメモリへのダウンロードを確実に行うことができるようにすることを目的とする。
【００１４】
【課題を解決するための手段】
本発明は、上記課題を解決するため、オーディオデータを通信回線により送信する外部のオーディオ配信センターと接続する通信部と、受信を希望する曲を選択するリクエスト選択部と、受信したオーディオデータを再生し出力するオーディオ再生部と、受信したデータを記録するメモリと、該メモリを管理するメモリ管理部と、受信の中断及び受信が可能になったことを検出する受信状況検出部とを備え、前記リクエスト選択部は、受信状況検出部で検出した受信中断期間が所定時間以内の時には中断時点の最終受信データ部分から送信要求を行い、所定時間を超えるときには他の指定したデータ部分の送信要求を行うことを特徴とする車載オーディオ装置としたものである。
【００１５】
また、前記他の指定したデータ部分は、中断した曲の曲頭部分としたものである。
【００１６】
また、前記他の指定したデータ部分は、中断した曲とは異なる他の曲としたものである。
【００２２】
【発明の実施の形態】
本発明の実施の形態を図面に沿って説明する。図１は本発明の車載オーディオ装置とオーディオ配信センター間のデータ通信構成、及びこれらの装置における機能のブロック構成を示す機能ブロック図であり、図２以降にはその作動フローを示している。図１に示すように、車載オーディオ装置１には携帯電話との接続部、あるいは車両搭載電話等からなる通信部５を備え、その中の受信部３と送信部４は、オーディオ配信センター２の送信部６と受信部７との間で移動電話回線による通信を行うようにしている。
【００２３】
最初に、本発明の車載オーディオ装置がオーディオデータ等の送信を受けるオーディオ配信センター２の機能、構成について説明する。オーディオ配信センター２のオーディオ全曲データ部８には、クラシック系、ポップス系、演歌系等各種ジャンルの多数のオーディオデータを保有し、各曲の全曲分のデータ及び曲名、歌手名、演奏に関する情報等のデータを保有している。また、図示実施例では前記オーディオ全曲データ部８とは別に選曲用データ部１０を備えており、後述するように外部から選曲のためのイントロデータの要求を受信したときに対応するデータを送信するため、各曲の最初のイントロ部分のデータを、各曲の曲名、演奏者・歌手名等と共に集約したものをここに記録している。
【００２４】
この選曲用データ部１０は、前記のようなイントロ部分のデータ以外に、その曲がイントロ部分では選曲時に特定しにくいことがある場合を考慮して、例えばクラシック系では主テーマ部分、ポップス系や演歌系の曲では「さび」の部分等、その曲の最も特徴的な部分を抽出してここに保有することもできる。なお、以下説明の便宜のため、これらの部分を含めて「イントロ部分」と、またそのデータを「イントロデータ」と略称する。
【００２５】
図示実施例では、選曲用データ部１０をオーディオ全曲データ部８とは別個に設けた例を示したが、オーディオ全曲データ部８のアクセススピードが充分に速い場合は、そのオーディオデータ中に、前記イントロ部分、特徴的な部分等にフラグ等のマークデータを付与し、外部から選曲のためのイントロデータの要求を受信したときには、そのマークデータを付与したその曲の特徴的なイントロ部分を、曲名、演奏者・歌手名等と共に送信するように構成することもできる。また、オーディオ全曲データ部８の情報管理部分に前記選曲用データ部１０と同様のデータ記録部を配置することもできる。
【００２６】
オーディオ配信センター２では、後に詳述する車載オーディオ装置１から選曲用のデータ要求があったときには、受信部７でこれを受信し、データ検索処理部１１で選曲用データ部１０にアクセスして検索し、検索結果を選曲用データ出力部１２でこれを新しい曲順等に並べてリスト化し、要求があったイントロデータを付与して送信部６から送信するようになっている。また、特定の曲を明示したオーディオデータのリクエストを受信したときには、通常行われているオーディオデータ配信と同様に、データ検索処理部１１が各曲の全てのオーディオデータを記録しているオーディオ全曲データ部８にアクセスして検索し、所定の全曲データ（前記の選曲用のオーディオデータである「イントロデータ」と区別するため「全曲データ」と称する。以下同様。）を全曲データ配信部１３に出力し、送信部６からリクエストしユーザに送信する。
【００２７】
なお、ユーザから曲名と演奏者・歌手名の指定による全曲データのリクエストがあった場合でも、例えばベートーベン作曲交響曲第９番、ベルリンフィル演奏等のように、多くのレコード会社のものが存在する場合等、必ずしも１つのものに特定できない場合は、選曲用データ出力部１２からユーザに対してこれらの選択を行うためのデータを出力し、特定のものに選択をさせることもできる。
【００２８】
上記のような機能を備えたオーディオ配信センターの装置は、現在一部行われている選曲用リストの送信にイントロデータの配信機能を付加するのみで容易に対応することができる。本発明の車載オーディオ装置１は、上記のような機能を備えたオーディオ配信センターと相互通信を行って、以下に述べるような選曲用データ要求、全曲データ要求、受信再開用リクエスト選択等の送信、及び選曲用データ、全曲用データの受信等、種々の機能を行う。
【００２９】
車載オーディオ装置１には、オーディオ装置に従来から用いられるオーディオ再生部１５を備え、ここで再生されたオーディオはスピーカ１４からユーザに対して出力される。また、表示部１６を備え、この実施例においては、全曲データ入力部２０からの受信曲の曲名、演奏者・歌手名、録音会場等の各種データを表示し、また、選曲用データ入力部２１からの選曲のためのリストを表示し、更に受信状況検出部２２からの受信が可能になったこと、また必要に応じて受信が中断したこと、受信が中断したときの受信データの状況等を表示する。更に、リクエスト選択部２３からのリクエストの選択を行った曲の表示、リクエストを行うことの確認の表示等を行う。また、メモリ管理部３０から消去するデータの確認の表示を行う等、種々の表示がなされる。
【００３０】
操作部１７はリモコン、表示部のタッチパネル、キーボード等からなり、受信状況検出部２２で受信中断から受信が可能となった状態の信号がリクエスト選択部２３に入力されたとき、その曲のどの部分から、あるいは何の曲から再送信してもらうかのを選択信号を受信再開用リクエスト選択部２４に出力する。また、全曲データ要求部２５からオーディオ配信センター２へリクエストを行う前に、確認の表示がなされた際、それに対する応答の操作を行う。更に、操作部１７では選曲のための操作や選曲用データを要求するための各種操作を行うと共に、メモリ管理部３０におけるメモリ消去部３６でデータを消去する際に、消去確認部３５からの確認の表示に対する応答操作等を行う。
【００３１】
全曲データ入力部２０においては、受信部３が受信したオーディオ配信センター２からの全曲データを入力し、オーディオ再生部１５に出力してスピーカ１４からリアルタイムで再生を行うとともに、前記表示部１６の機能において述べたように、その曲の曲名、演奏者・歌手名、録音会場等の各種データを表示部１６に表示させる。更に、メモリ管理部３０にも出力し、受信したオーディオデータをメモリ書込・読出部３２によりメモリ３１の空き容量部分にダウンロードする。なお、オーディオ配信センター２との通信速度が遅く、または各曲の単位時間当たりのデータ量が多い等のため、リアルタイムにスピーカ１４から聞くことができない時には、全てのオーディオデータをメモリ３１に一度ダウンロードし、その後操作部１７の指示等によりメモリ書込・読出部３２からそのダウンロードしたオーディオデータを読み出し、これをオーディオ再生部１５で再生する。
【００３２】
選曲用データ入力部２１においては、後述する選曲用データ要求部２６からの出力に応じて、オーディオ配信センター２が送信した選曲用リストやイントロデータを入力し、イントロデータ部分はオーディオ再生部１５で再生し、選曲用リストは表示部１６に表示する。このとき、ユーザが表示部１６に表示された選曲用リストに基づき、指定した曲についてのみ、イントロデータをオーディオ再生部１５から出力し、これを受信するように構成することもできる。これらのデータに基づいて、ユーザは容易に選曲を行うことができる。
【００３３】
受信状況検出部２２においては、受信部３の受信状態を常時検出しており、オーディオ配信センター２からのデータの受信中にその受信が中断したことを検出し、また携帯電話等が用いられる通信部５の電波受信可能状態を検出することにより、前記受信中断後の受信可能状態への復帰を検出することができる。この受信中断の検出時には、同時に受信中のオーディオデータがとぎれたデータ位置も検出し、これをリクエスト選択部２３に出力して記憶させておく。また、受信が中断した曲についての情報を表示部１６に表示して、その後のユーザの再送信データの選択時に利用する。更に、受信が可能な状態に復帰したときには、その信号をリクエスト選択部２３に出力し、リクエスト選択部２３では中断位置からのオーディオデータの配信、あるいはその曲の最初からの配信、または操作部１７からの指示による他の曲の配信等の選択を行い、送信部４に出力する。
【００３４】
リクエスト選択部２３の受信再開用リクエスト選択部２４においては、前記のように、オーディオ配信センター２からの全曲データの受信中に、トンネルの中に入ることにより、あるいはビル群の中に入る等によって受信電波が中断した後、再び受信が可能になったことを受信状況検出部２２で検出したとき、その信号によって、中断した時間が例えば１０分間等の所定時間以内の時には、中断した時点のデータ記憶に基づいて、その部分からのデータ送信再開を送信部４に自動的に出力する。また、中断した時間が所定時間を超えているときには、その曲の最初の部分からのデータ送信再開を要求することができ、そのほか、操作部から他の曲の送信依頼が入力されたときに、自動的に次のリクエスト曲から送信要求を行うように設定することもできる。更に、表示部１６にリクエストしている曲のリストを表示して、ユーザが希望する任意の曲から送信を再開するように要求することも可能である。
【００３５】
全曲データ要求部２５においては、操作部１７からの全曲データ送信指示に基づいて、リクエストのために指示された曲がメモリ３１内に既に存在するか否かを、メモリ管理部３０のメモリ検索部３３でチェックし、存在するときには自動的にリクエストデータから削除して送信部４に出力するか。また、このときメモリ内にリクエストしようとしている曲が既に存在することを表示部１６に表示し、ユーザに本当にリクエストするかの確認を促した後、その操作出力に応じてリクエストを削除する。
【００３６】
この全曲データ要求部２５において、上記のようにリクエストする曲が確定すると、リクエストした曲がオーディオ配信センター２から送信され受信したとき、これをメモリ３１にダウンロードする空き容量が存在するか否かの確認を行い、空き容量が存在しないときには後述するようにその分の容量を確保するための各種作動をメモリ管理部３０に行わせる。
【００３７】
このように全曲データをリクエストする曲が確定した後は、全曲データ要求部２５は送信部４にリクエストデータを出力し、これをオーディオ配信センター２に送信し、オーディオ配信センター２では前記のような機能部によりその曲を検索し、リクエストした車載オーディオ装置１にその全曲データを送信する、という一連の作動が行われる。
【００３８】
選曲用データ要求部２６においては、ユーザが曲をリクエストするに際して、特に曲名がわからず、また曲名がわかっても演奏者・歌手名がわからないため複数の曲が存在しうる等、リクエストする曲が特定されないときに、オーディオ配信センター２に選曲用のデータを要求する際に作動する。上記のようなときには、例えば演奏者や歌手名のみを送信し、その際にイントロデータを要求するか否かの選択信号も送信する。このようなイントロデータはユーザの選曲に際してきわめて有用なものであるが、データリストと異なり多くのデータ量の送受信を行う必要があるので、受信にかかる時間等を考慮して判断する必要がある。例えば美空ひばりのデータリスト要求時のように対応する曲が多数となり、イントロだけで全曲の数曲分にもなりそうなときには要求しないように、任意に選択を行うことができるようにしても良い。
【００３９】
その後、オーディオ配信センター２でこれを受信したときには、前記のように、データ検索処理部１１において選曲用データ部１０のデータを検索し、適合する曲のリストと、要求されたイントロデータを選曲用データ出力部１２から出力する。車載オーディオ装置１においては選曲用データ入力部２１において前記のような各種作動を行い、それに基づいてユーザは希望の曲を決定し、全曲データの要求操作を行う、という一連の作動、操作が行われる。
【００４０】
メモリ管理部３０においては、多数のオーディオデータを記録しているメモリ３１を備え、メモリ書込・読出部３２によりオーディオ配信センター２から送信された各曲のオーディオデータ以外に、曲名、演奏者・歌手名、録音場所、更にはデータ量も書き込む。このメモリ３１内のオーディオデータは、操作部１７によって読み出し指示されたデータをオーディオ再生部１５に出力することにより、ユーザはメモリ３１にダウンロードした曲を自由に聴くことができる。更に、このメモリ３１には、前記のように操作部１７によって選曲され、メモリ３１からオーディオデータを読み出し、その曲を再生して聴いた日時を記録しておく。また、必要に応じて利用者が再生した回数を記録しておき、利用頻度をメモリしておくこともできる。
【００４１】
また、全曲データ要求部２５の前記のような機能により、メモリ３１内の空き容量が、送信されてくるオーディオデータ量よりも多いか否かをチェックするため、書き込みデータ量予測部２７を備え、送信されてくるオーディオデータ量を予測する。ここで予測されたデータ量分の空き容量がメモリ３１にある時には、そのまま全曲データ要求の出力を行わせる。
【００４２】
しかしながら、前記のように予測されたデータ量、あるいはそれに対して余裕分を加えたデータ量が、メモリ３１に存在する空き容量より大きいときには、メモリ３１内のデータに付与した前記のような再生日時データに基づいて、メモリ３１内のデータを再生した日時の古い順に並べ、予測されたデータ量より幾分多めのデータとなる曲までをチェックする。このようにしてチェックされた曲のデータを、消去確認部３５から表示部１６に出力し、その曲の曲名、演奏者・歌手名、最終再生日時等を表示するとともに、更には必要に応じてその曲のイントロデータに関する情報をオーディオ再生部１５に出力し、間違って大事な曲を消去することがないように種々のデータをユーザに提供する。
【００４３】
ユーザがその表示部１６のデータを見ることにより、またイントロデータを聴くことにより消去用メモリの選択を行い、新しいオーディオデータをダウンロードするのに必要な空き容量を確保する。このようにして消去用メモリが確定された後、メモリ消去部３６はメモリ３１の対応する部分のメモリを消去する。一方、メモリ検索部３３では、前記のように全曲データ要求部２５から出力されようとしているリクエストについて、それがメモリ３１内に既に存在するものをリクエストすることがないように、チェックを行う。
【００４４】
上記のように作動する各機能部からなる車載オーディオ装置１について、その作動を時系列で表す作動フローに基づいて、前記図１に示す機能ブロック図を参照しつつ説明する。図２はオーディオ配信処理の全体の作動フロー図であり、最初に、後に詳述する図３に示すような選曲処理を行う（ステップＳ１）。その処理により、１つの曲の最初から最後までのオーディオデータを含み、また、曲名、演奏者・歌手名、録音会場等の録音関連データを全て含む全曲データを要求するリクエスト曲を確定する（ステップＳ２）。この作動は主として、図１のリクエスト選択部２３における選曲用データ要求部２６と、全曲データ要求部２５において処理される。
【００４５】
次いで、後に詳述する図４に示すような、図１のメモリ３１中に、ダウンロード用メモリを確保するための処理を行う（ステップＳ３）。この処理は主として、図１の書き込みデータ量予測部２７と、メモリ管理部３０におけるメモリ容量・消去用メモリ検索部３４と、消去確認部３５と、メモリ消去部３６によって行われる。
【００４６】
このようにして受信データのダウンロード領域を確保した後、前記のように選曲された全曲データ要求出力を行う（ステップＳ４）。この処理は主として、全曲データ要求部２５と送信部４において行われる。この全曲データ要求に対して、オーディオ配信センター２から対応するデータが送信されてきたときには、受信部３がこの全曲データを受信し（ステップＳ５）、全曲データ入力部２０に出力する。ここからオーディオ再生部１５に出力され、アナログ信号となり、スピーカ１４から出力される（ステップＳ６）。同時に、この全曲データはメモリ管理部３０のメモリ書込・読出部３２に入り、メモリ３１にこのオーディオデータを蓄積する（ステップＳ７）。
【００４７】
このような全曲データの受信中に、車両がトンネルの中に入り、あるいはビル群の中に入ることにより受信が中断したことを図１の受信状況検出部２２で検出したときには（ステップＳ８）、中断した時点の最終データ位置を記憶し（ステップＳ９）、その後受信が可能となるのを待つ。受信が可能となったことを、前記受信状況検出部２２が検出したときには（ステップＳ１０）、後に詳述する図５に示すような受信再開時処理を行う（ステップＳ１１）。
【００４８】
このようにしてリクエスト曲の全てが受信終了したときには（ステップＳ１２）、このオーディオ配信処理は終了する（ステップＳ１３）。前記ステップＳ８において、全曲データの受信中に受信が中断しなかったときには、ステップＳ１２に進み、リクエスト曲が全て受信終了したか否かを判別し、以降は前記と同様の処理を行う。また、ステップＳ１０において、受信中断後に受信可能とならなかったときにはステップＳ１３に進み、オーディ配信処理を終了する。この受信可能となったか否かの判別は、例えば受信中断後１時間等、長時間受信不能状態が続いたことを検出することによって判別するようにしても良い。また、ステップＳ１２において、リクエスト曲が全て受信終了していないと判別されたときには、再びステップＳ５に戻り、全曲データの受信を継続する。
【００４９】
前記ステップＳ１の選曲処理は図３に示されるように、最初はユーザが曲名を入力したか否かを判別する（ステップＳ２１）。ユーザが希望する曲の曲名を忘れてしまったときには、演奏者あるいは歌手名を入力したか否かを判別する（ステップＳ２２）。このとき演奏者あるいは歌手名がわかっているときには、演奏者等に対応する選曲リストの送信要求を行うこととなる（ステップＳ２３）。ここで演奏者や歌手名もわからないときには、この実施例においては希望の曲を絞り込む手段を備えていないので再びステップＳ２１に戻り、いずれかがわかる曲の入力を待つ。但し、曲名や演奏者等が不明でも、例えばレコード会社、演奏会場等により選曲する余地がある場合には、それに対応した選曲リストの要求を行うことも可能である。
【００５０】
また、曲名がわかっているが演奏者や歌手名がわからないときには（ステップＳ２９）、特にクラシック系統において同じ曲名で複数の演奏者が存在することも多く、演歌等においても同じ曲名で複数の歌手が歌っているものも多いので、曲名に対応する選曲リストの送信要求を行うか否かの選択を行う（ステップＳ３０）。このとき、リクエストする曲がポップス系の場合は同一曲名が少ないので、このステップＳ３０において選曲リストの送信要求を行うことなく、前記ステップＳ２９において演奏者や歌手名もわかっている場合と同様に、直ちにステップＳ２７に進み、この曲が既にメモリに存在する曲ではないか否かをチェックする。
【００５１】
前記ステップＳ２３及びステップＳ３０において、演奏者等に対応する選曲リストの送信要求を行うか、あるいは曲名に対応する選曲リストの送信要求を行うときには、それらの選曲リストと共にイントロデータの送信を要求するか否かの判別を行う。なお、このイントロデータとは前記のように、その曲の最初の部分のほか、クラシック曲の場合は主テーマとなっている楽曲部分を、またポップスや演歌の場合には「さび」となっている部分のデータの場合も存在する。このようなイントロデータは自動的に全曲に対して要求することもできるが、選曲リストのデータと異なり多くのデータを含んでいるので、あまり多くのイントロデータを要求することは好ましくない場合もあり、ここでは適宜の量の選択を行うものとして作動フローを形成している。
【００５２】
このようなイントロデータを要求しないときには、オーディオ配信センターから選曲用リストのみが送信され、これを受信する（ステップＳ２５）。また、イントロデータを要求したときには、選曲リストと共にイントロデータの受信がなされる（ステップＳ３１）。オーディオセンターから送信される検索結果の選曲用リストは、例えば特定の歌手に対するものの場合は、最新の曲からリストアップする等、使用のし易い形態で送信される。受信した選曲リストは図１の表示部１６に表示され、またイントロデータはオーディオ再生部１５で音声化され、スピーカ１４から出力される。ユーザはこれにより容易に選曲を行うことができる（ステップＳ２６）。
【００５３】
しかしながらこのステップＳ２６において、希望する曲とは異なる等により、これらのデータでは選曲することができなかった場合には、再びステップＳ２１に戻り同様の手順によって他の選曲を行う。また、上記のように選曲が行われた場合も、メモリ内に選曲した曲が既に存在するか否かをチェックし、存在する場合はこれをリクエスト曲とせず、このことを適宜表示部１６に表示し、再びステップＳ２１に戻って他の曲の選択を行う。このようなメモリ３１内のチェックは、メモリ検索部３３において行われる。その後、ユーザが複数の曲をリクエストする場合のために、全リクエスト曲の選曲が終了したか否かの判別を行い（ステップＳ２８）、選曲が終了した旨の指示があったときにはこの選曲処理を終了する。また、未だ他の曲の選曲を行う必要があるときには、再びステップＳ２１に戻り、同様のフローを繰り返す。
【００５４】
図２のステップＳ３におけるダウンロード用メモリの確保を行う処理は、図４に詳細に示されており、前記のように全曲データを要求する曲の選曲が確定した後、最初にそれらの曲をメモリにダウンロードするのに要するデータ量の予測を行う（ステップＳ４１）。このデータ量は、例えばクラシックの交響曲や協奏曲の場合は１時間、ポップスや演歌の場合は６分等、平均的な所用時間よりも幾分多めの時間を予測し、これを合算した値を予測データ量とする。この作動は図１の書込データ量予測部２７において行われる。
【００５５】
次いで、メモリ３１に現在存在する空きメモリの量を、図１のメモリ容量・消去用メモリ検索部３４で調べ、現在の空きメモリでリクエストする曲の全データがダウンロードできるか否かを判別する（ステップＳ４２）。ここで充分ダウンロードできると判別されたときには、以降の処理を行う必要がなく、ステップＳ５１に進み処理を終了する。
【００５６】
空きメモリではダウンロードすることができないと判別されたときには、不足容量を計算し（ステップＳ４３）、この不足容量を確保するため、以降既存のメモリデータを消去する操作を行う。最初はメモリされている曲を、以前再生した最も新しい時点を基準に再生の古い順に並べ、そのテーブルを作る（ステップＳ４４）。このような並べ替えは、前記のようにメモリ３１に再生時点の記憶部を備えているので、このデータに基づいて容易に行うことができ、メモリ３１に利用頻度もメモリしている場合には、これを加味したメモリ消去候補テーブルを作成する事もできる。
【００５７】
このようにして順に並べられたメモリ消去候補テーブルを元に、表示部１６に１つずつ候補の曲を表示する（ステップＳ４５）。なお、このとき、表示部に前記メモリ消去候補テーブル自体を表示し、これをユーザが順に一つずつチェックを行うようにすることもできる。更に、表示された曲がどのような曲であったのかわからないことも多いので、ユーザが特定の操作を行うことによりイントロデータの再生の要求を行い（ステップＳ４６）、イントロの再生を行わせることもできる（ステップＳ４７）。また、イントロデータの再生が必要ないときはこのステップＳ４７を飛ばしてステップＳ４８に進む。
【００５８】
上記イントロデータは、その曲の最初の３０秒等、その曲の真にイントロ部分に設定することができ、また、オーディオデータにその曲の特徴となる部分にフラグをたて、これを検索してその部分をイントロデータとして再生するようにしても良い。このイントロデータのフラグは、オーディオ配信センターにおいて、イントロデータの要求に備えて所有するオーディオデータに予め付与しておき、これをユーザがダウンロードしたときに自動的にそのデータを取り込むようにしても良い。
【００５９】
このようにして１曲ずつメモリの消去が可能であるか否かのチェックを行い（ステップＳ４８）、消去が可能な場合は図１のメモリ消去部３６においてその部分のメモリの消去を行う（ステップＳ４９）。このメモリ消去の結果、前記不足容量分のメモリ消去が行われ、ダウンロード用メモリが確保されたか否かを判別し（ステップＳ５０）、未だ空きメモリが不足している場合には、再びステップＳ４５に戻り、更に他の曲を消去するため前記と同様のフローを繰り返す。なお、前記ステップＳ４８において、表示されたメモリ消去候補の曲が、消去したくない曲である場合にもステップＳ４５に戻り、他の曲を消去するため同様のフローを繰り返す。このようにしてダウンロード用メモリが確保されたときには、この処理を終了する（ステップＳ５１）。
【００６０】
前記図２のステップＳ１１における全曲データ受信中にその受信が中断し、再び受信可能となったときの受信再開時処理は、図５に詳細に示される。即ち、最初受信中断から受信可能となった時間を計測し、受信中断期間が例えば１０分間等の所定時間以内であるか否かを判別する（ステップＳ６１）。その所定時間以内である場合には、図２のステップＳ９において記憶した、受信が中断した時点の最終データ部分から受信を再開することを、オーディオ配信センター２に対して自動的に要求する（ステップＳ６６）。
【００６１】
しかしながら、ステップＳ６１において受信不能期間が所定時間を超えていると判別されたときには、受信不能期間があまりにも長いので、先に受信していた曲のイメージがつかめなくなっており、受信が中断した時点の部分から再生されてもほとんど意味がないことが多いため、その曲の曲頭からデータ送信することを要求するか否かを判別する（ステップＳ６２）。この判別時に、車載オーディオ装置のシステム設定により、前記のように受信中断期間が所定時間を超えるときに、その曲の曲頭からのデータ送信要求を自動的に行うように設定している場合においては、この判別部では自動的にその曲の曲頭からの要求を行うように処理がなされる。また、別個のユーザの操作によって曲頭からのデータ送信を希望する指示が行われたときには、この指示信号をオーディオ配信センターに対して要求する（ステップＳ６７）。
【００６２】
また、ステップＳ６２において、曲頭からのデータ送信は要求しないことをユーザが指示したときには、ユーザが更に他の曲を選択して要求することとなる（ステップＳ６３）。このとき、予め複数の曲をリクエストしていた場合においては、受信が中断した曲の後に未だ受信していない曲があるときには、これを自動的に指定することもできる。なお、前記曲頭部分、及び選択した他の曲は、本発明における受信中断時の最終受信位置以外の、「他の指定したデータ部分」に相当する。
【００６３】
このようにして受信再開後に要求する曲、あるいは曲の部分等が決まったときには、オーディオ配信センターに対してデータ要求の送信出力を行う（ステップＳ６４）。これに対応してオーディオ配信センターから全曲データが送信され、オーディオデータの受信が再開し（ステップＳ６５）、この処理を終了する（ステップＳ６８）。
【００６４】
上記実施例に示した車載オーディオ装置の構成は各種の態様の一例を示したものであり、上記のほか種々の態様で実施することができる。
【００６５】
【発明の効果】
本発明は、上記のように構成したので、オーディオ配信センターに対して必要な曲をリクエストし、通信手段により配信されたオーディオデータを利用する際、オーディオデータの受信中に通信が中断したとき、受信中断期間が所定時間以内の時には中断時点の最終受信データ部分から送信要求を行うので、短時間の中断後に受信が可能になったときには自動的に先の受信データを継続して受信することができる一方、所定時間を超えるときには他の指定したデータ部分の送信要求を行うことができるので、長時間受信が中断したときに先の受信データを継続して受信する無意味な状態を解消し、適切なオーディオデータを受信することが可能となる。
【００６６】
また、前記他の指定したデータ部分が、中断した曲の曲頭部分としたものにおいては、上記効果に加えて中断期間が所定時間以上の時に、自動的に中断した曲の曲頭部分から受信することができ、長時間受信が中断したときに適切なオーディオの配信を受けることができる。
【００６７】
また、前記他の指定したデータ部分が、中断した曲とは異なる他の曲としたものにおいては、中断期間が所定時間以上の時に、他の曲の送信を要求することができ、長時間受信が中断したときに適切なオーディオの配信を受けることができる。
【００６８】
また、オーディオデータを通信回線により送信する外部のオーディ配信センターと接続する通信部と、受信を希望する曲を選択するリクエスト選択部と、受信したオーディオデータを再生し出力するオーディオ再生部と、受信したデータを記録するメモリと、該メモリを管理するメモリ管理部とを備え、前記リクエスト選択部は、メモリ内にリクエストする曲が存在するか否かを検索し、存在しない曲のみをリクエストすることようにしたものにおいては、既にメモリに存在する曲をリクエストすることがなくなり、無用なリクエストを行うことにより無駄な料金を支払うことがなくなる。
【００６９】
また、オーディオデータを通信回線により送信する外部のオーディ配信センターと接続する通信部と、受信を希望する曲を選択するリクエスト選択部と、受信したオーディオデータを再生し出力するオーディオ再生部と、受信したデータを記録するメモリと、該メモリを管理するメモリ管理部とを備え、前記リクエスト選択部は、曲を特定できないときに選曲用のデータの送信をオーディオ配信センターに要求する選曲用データ要求部を備え、前記選曲用データ要求部は、選曲用リストのほか曲の一部のオーディオデータの要求を行い、前記リクエスト選択部においてオーディオ配信センターから受信した応答データによりリクエスト曲を選択するものにおいては、選曲時にその曲の一部のオーディオデータを聴きながら選曲することができ、容易に、かつ確実に適切な選曲を行うことができる。
【００７０】
また、オーディオデータを通信回線により送信する外部のオーディ配信センターと接続する通信部と、受信を希望する曲を選択するリクエスト選択部と、受信したオーディオデータを再生し出力するオーディオ再生部と、受信したデータを記録するメモリと、該メモリを管理するメモリ管理部とを備え、前記メモリ管理部は、リクエストする曲のオーディオデータを記録する空き容量を確保するためのダウンロード用メモリ確保処理を行うようにしたものにおいては、受信したオーディオデータをメモリにダウンロードする際、予め記録する部分を確保しているので、確実にダウンロードを行うことができる。
【００７１】
また、前記ダウンロード用メモリ確保処理で、消去候補曲の一部のオーディオデータを出力し、オーディオ再生部で再生するようにしたものにおいては、容易に且つ間違いなく不要な曲を消去することができ、誤って大事な曲を消去する危険性が少なくなる。
【００７２】
また、前記ダウンロード用メモリ確保処理で、再生の古い曲順に消去用候補曲として提示するようにしたものにおいては、消去する曲の選択が容易となり、且つ最近使用することが少ない曲の順に消去の操作を行うことができるので、最近使用している大事な曲を誤って消去する危険性が減少する。
【図面の簡単な説明】
【図１】本発明の実施例の機能ブロックの関連を示す機能ブロック図である。
【図２】本発明の実施例の基本的な作動を示す作動フロー図である。
【図３】本発明の実施例の選曲処理部分の作動を示す作動フロー図である。
【図４】本発明の実施例のダウンロード用メモリ確保処理部分の作動を示す作動フロー図である。
【図５】本発明の実施例の受信再開時処理部分の作動を示す作動フロー図である。
【符号の説明】
１  車載オーディオ装置
２  オーディオ配信センター
５  通信部
８  オーディオ全曲データ
１０  選曲用データ
１５  オーディオ再生部
１６  表示部
１７  操作部
２２  受信状況検出部
２３  リクエスト選択部
２４  受信再開用リクエスト選択部
２５  全曲データ要求部
２６  選曲用データ要求部
３０  メモリ管理部
３１  メモリ
３２  メモリか書込・読出部
３３  メモリ検索部
３４  メモリ容量・消去用メモリ検索部
３５  消去確認部
３６  メモリ消去部
【図１】
0004024984.tif 000002
【図２】
0004024984.tif 000003
【図３】
0004024984.tif 000004
【図４】
0004024984.tif 000005
【図５】
0004024984.tif 000006