(57)【特許請求の範囲】
【請求項１】
複数のコンテンツの一覧であり、かつ、コンテンツタイプを含まないコンテンツリストと、該コンテンツのコンテンツタイプとをサーバから取得して、該コンテンツリスト内のインデックス毎にコンテンツタイプを登録するコンテンツタイプ登録装置であって、
該インデックスに対応付けて、コンテンツタイプを登録するためのコンテンツタイプ登録部と、
登録対象のインデックスに隣接するインデックスのコンテンツタイプが、該コンテンツタイプ登録部に登録されているか否かを判断する判断手段と、
隣接するインデックスのコンテンツタイプが該コンテンツタイプ登録部に登録されている場合に、登録対象のインデックスのコンテンツタイプをサーバから取得することなく、隣接するインデックスのコンテンツタイプを登録対象のインデックスのコンテンツタイプとして、該コンテンツタイプ登録部に登録し、隣接するインデックスのコンテンツタイプが該コンテンツタイプ登録部に登録されていない場合に、登録対象のインデックスのコンテンツタイプをサーバから取得して、該コンテンツタイプ登録部に登録する登録手段とを備える、コンテンツタイプ登録装置。
【請求項２】
コンテンツタイプが有効であるか否かの情報を管理する有効タイプ管理手段をさらに備え、
前記判断手段が、サーバから取得したコンテンツタイプが有効か否かを、前記有効タイプ管理手段において有効であると管理されているか否かを判断することによって、さらに判断し、サーバから取得したコンテンツタイプが有効でないと判断された場合、前記登録手段が、サーバから取得したコンテンツタイプを破棄して、コンテンツタイプの代わりに、無効である旨を示す情報を該コンテンツタイプ登録部に登録し、
前記判断手段が、隣接するインデックスに対して前記コンテンツタイプ登録部に無効である旨を示す情報が登録されているか否かをさらに判断し、無効である旨を示す情報が登録されている場合、該登録手段が、隣接するインデックスのコンテンツタイプを登録対象のインデックスのコンテンツタイプとして登録せずに、登録対象のインデックスのコンテンツタイプをサーバから取得して、該コンテンツタイプ登録部に登録する、請求項１に記載のコンテンツタイプ登録装置。
【請求項３】
選択されたインデックスのコンテンツを前記サーバに要求し、該サーバから該インデックスのコンテンツとそのコンテンツタイプとを取得するコンテンツ取得手段をさらに備え、
前記判断手段が、前記コンテンツタイプ登録部に登録されている該インデックスのコンテンツタイプが、該コンテンツ取得手段によって取得されたコンテンツタイプと同じであるか否かをさらに判断し、
該コンテンツタイプ登録部に登録されている該インデックスのコンテンツタイプが、該コンテンツ取得手段によって取得されたコンテンツタイプと同じでない場合に、前記登録手段が、該インデックスのコンテンツタイプとして該コンテンツ取得手段によって取得されたコンテンツタイプを再登録する、請求項１または２に記載のコンテンツタイプ登録装置。
【請求項４】
隣接するインデックスのコンテンツタイプを登録対象のインデックスのコンテンツタイプとして前記コンテンツタイプ登録部に登録したインデックスを選択し、該インデックスのコンテンツタイプを前記サーバから取得するコンテンツタイプ取得手段をさらに備え、
前記判断手段が、前記コンテンツタイプ登録部に登録されている該インデックスのコンテンツタイプが、該コンテンツタイプ取得手段によって取得されたコンテンツタイプと同じであるか否かをさらに判断し、
該コンテンツタイプ登録部に登録されている該インデックスのコンテンツタイプが、該コンテンツタイプ取得手段によって取得されたコンテンツタイプと同じでない場合に、前記登録手段が、該インデックスのコンテンツタイプとして該コンテンツタイプ取得手段によって取得されたコンテンツタイプを再登録する、請求項１〜３のいずれかに記載のコンテンツタイプ登録装置。
【請求項５】
前記コンテンツタイプを含むコンテンツリストを表示する表示手段をさらに備え、
前記登録手段によって該表示手段に表示されているコンテンツタイプが再登録された場合、該表示手段に表示されているコンテンツタイプを再登録されたコンテンツタイプに変更する、請求項３または４に記載のコンテンツタイプ登録装置。
【請求項６】
登録対象のインデックスに隣接するインデックスが、登録対象の１つ前のインデックスである、請求項１〜５のいずれかに記載のコンテンツタイプ登録装置。
【請求項７】
複数のコンテンツの一覧であり、かつ、コンテンツタイプを含まないコンテンツリストを取得するステップと、
登録対象のインデックスに隣接するインデックスのコンテンツタイプが、コンテンツタイプ登録部に登録されているか否かを判断する判断ステップと、
隣接するインデックスのコンテンツタイプが該コンテンツタイプ登録部に登録されている場合に、登録対象のインデックスのコンテンツタイプをサーバから取得することなく、隣接するインデックスのコンテンツタイプを登録対象のインデックスのコンテンツタイプとして、該コンテンツタイプ登録部に登録するステップと、
隣接するインデックスのコンテンツタイプが該コンテンツタイプ登録部に登録されていない場合に、登録対象のインデックスのコンテンツタイプをサーバから取得して、該コンテンツタイプ登録部に登録するステップとをコンピュータに実行させる、コンテンツタイプ登録プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツのコンテンツタイプをサーバから取得して登録するコンテンツタイプ登録装置に関する。
【背景技術】
【０００２】
インターネットラジオサーバ（以下、サーバという）にインターネット経由でアクセスして、サーバに保存されている音楽ファイルや映像ファイル等のコンテンツデータをストリーミング形式で取得して再生するインターネットラジオ端末が提供されている。また、このようなインターネットラジオ端末の機能を搭載したＡＶアンプ等の増幅装置が販売されている。ＡＶアンプは、ＦＬ管等の表示部を備えており、サーバから複数のコンテンツの一覧であるプレイリストを取得して、表示部にプレイリストを表示する。ＡＶアンプは、プレイリスト内の各コンテンツのタイトルを表示すると共に、コンテンツのタイプ（音楽ファイル、映像ファイル、又は、他のプレイリストへのリンク等の形式）を示すアイコンを表示する。アイコンを表示するために、ＡＶアンプは、サーバからコンテンツのタイプ（ＭＩＭＥタイプ）を取得する必要がある。しかし、ＰＬＳやＭ３Ｕのようなインターネットラジオで使用されているプレイリストファイルには、タイトルとコンテンツの所在を表すＵＲＬは含まれているものの、ＭＩＭＥタイプが含まれていない。そのため、ＭＩＭＥタイプを取得するために、ＡＶアンプは、プレイリスト内のコンテンツ毎に、そのＵＲＬにアクセスして、ＭＩＭＥタイプをサーバから送信してもらう必要があり、プレイリスト内の全コンテンツについてＭＩＭＥタイプを要求して取得していると、多大な時間がかかる。その結果、ＡＶアンプの表示部にコンテンツのタイプを示すアイコンを表示し終えるまでに多大な時間がかかるという問題がある。
【０００３】
【特許文献１】特表２００３−５３０６１６号
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明は上記従来の課題を解決するためになされたものであり、その目的は、プレイリストにＭＩＭＥタイプが含まれておらず、サーバからプレイリストとは別にＭＩＮＥタイプを取得して登録する際に、迅速にＭＩＭＥタイプを登録することができるコンテンツタイプ登録装置を提供することである。
【課題を解決するための手段】
【０００５】
本発明の好ましい実施形態によるコンテンツタイプ登録装置は、複数のコンテンツの一覧であり、かつ、コンテンツタイプを含まないコンテンツリストと、該コンテンツのコンテンツタイプとをサーバから取得して、該コンテンツリスト内のインデックス毎にコンテンツタイプを登録するコンテンツタイプ登録装置であって、該インデックスに対応付けて、コンテンツタイプを登録するためのコンテンツタイプ登録部と、登録対象のインデックスに隣接するインデックスのコンテンツタイプが、該コンテンツタイプ登録部に登録されているか否かを判断する判断手段と、隣接するインデックスのコンテンツタイプが該コンテンツタイプ登録部に登録されている場合に、登録対象のインデックスのコンテンツタイプをサーバから取得することなく、隣接するインデックスのコンテンツタイプを登録対象のインデックスのコンテンツタイプとして、該コンテンツタイプ登録部に登録し、隣接するインデックスのコンテンツタイプが該コンテンツタイプ登録部に登録されていない場合に、登録対象のインデックスのコンテンツタイプをサーバから取得して、該コンテンツタイプ登録部に登録する登録手段とを備える。
【０００６】
登録対象のインデックスに隣接するインデックスのコンテンツタイプがコンテンツタイプ登録部に登録されている場合、登録対象のインデックスのコンテンツタイプをサーバから取得することなく、登録対象のインデックスに隣接するインデックスのコンテンツタイプを登録対象のインデックスのコンテンツタイプとして、コンテンツタイプ登録部に登録する。従って、全てのインデックスについてサーバからコンテンツタイプを取得する場合に比べて、コンテンツタイプ登録部にコンテンツタイプを登録するまでの時間を短縮することができる。なお、このように処理するのは、コンテンツリスト内においては同じコンテンツタイプのコンテンツが連続するのが一般的であるので、隣接するインデックスのコンテンツタイプと同じコンテンツタイプを登録することにより、概略正確なコンテンツタイプを迅速に登録することができるからである。
【０００７】
好ましい実施形態においては、コンテンツタイプが有効であるか否かの情報を管理する有効タイプ管理手段をさらに備え、前記判断手段が、サーバから取得したコンテンツタイプが有効か否かを、前記有効タイプ管理手段において有効であると管理されているか否かを判断することによって、さらに判断し、サーバから取得したコンテンツタイプが有効でないと判断された場合、前記登録手段が、サーバから取得したコンテンツタイプを破棄して、コンテンツタイプの代わりに、無効である旨を示す情報を該コンテンツタイプ登録部に登録し、前記判断手段が、隣接するインデックスに対して前記コンテンツタイプ登録部に無効である旨を示す情報が登録されているか否かをさらに判断し、無効である旨を示す情報が登録されている場合、該登録手段が、隣接するインデックスのコンテンツタイプを登録対象のインデックスのコンテンツタイプとして登録せずに、登録対象のインデックスのコンテンツタイプをサーバから取得して、該コンテンツタイプ登録部に登録する。
【０００８】
隣接するインデックスのコンテンツタイプとして無効である旨の情報がコンテンツタイプ登録部に登録されている場合、隣接するインデックスのコンテンツタイプを登録対象のインデックスのコンテンツタイプとして登録すると、全インデックスのコンテンツタイプとして無効である旨の情報が登録されてしまうが、本例では、このような場合には、サーバから登録対象のインデックスのコンテンツタイプを取得して、コンテンツタイプ登録部に登録するので、このような問題を解決できる。なお、コンテンツタイプが無効であるとは、例えば、本発明のコンテンツタイプ登録装置を適用する機器において、当該コンテンツタイプのコンテンツに対応できないことを意味する。例えば、インターネットラジオ端末に適用する場合には、端末で当該コンテンツタイプのコンテンツを再生できないことを意味する。または、サーバに接続できない場合を示す。
【０００９】
好ましい実施形態においては、前記コンテンツタイプ登録装置は、選択されたインデックスのコンテンツを前記サーバに要求し、該サーバから該インデックスのコンテンツとそのコンテンツタイプとを取得するコンテンツ取得手段をさらに備える。前記判断手は、前記コンテンツタイプ登録部に登録されている該インデックスのコンテンツタイプが、該コンテンツ取得手段によって取得されたコンテンツタイプと同じであるか否かをさらに判断する。該コンテンツタイプ登録部に登録されている該インデックスのコンテンツタイプが、該コンテンツ取得手段によって取得されたコンテンツタイプと同じでない場合に、前記登録手段が、該インデックスのコンテンツタイプとして該コンテンツ取得手段によって取得されたコンテンツタイプを再登録する。
【００１０】
好ましい実施形態においては、前記コンテンツタイプ登録装置は、隣接するインデックスのコンテンツタイプを登録対象のインデックスのコンテンツタイプとして前記コンテンツタイプ登録部に登録したインデックスを選択し、該インデックスのコンテンツタイプを前記サーバから取得するコンテンツタイプ取得手段をさらに備える。前記判断手段は、前記コンテンツタイプ登録部に登録されている該インデックスのコンテンツタイプが、該コンテンツタイプ取得手段によって取得されたコンテンツタイプと同じであるか否かをさらに判断する。該コンテンツタイプ登録部に登録されている該インデックスのコンテンツタイプが、該コンテンツタイプ取得手段によって取得されたコンテンツタイプと同じでない場合に、前記登録手段が、該インデックスのコンテンツタイプとして該コンテンツタイプ取得手段によって取得されたコンテンツタイプを再登録する。
【００１１】
好ましい実施形態においては、前記コンテンツタイプ登録装置は、前記コンテンツタイプを含むコンテンツリストを表示する表示手段をさらに備え、前記登録手段によって該表示手段に表示されているコンテンツタイプが再登録された場合、該表示手段に表示されているコンテンツタイプを再登録されたコンテンツタイプに変更する。
【００１２】
好ましい実施形態においては、登録対象のインデックスに隣接するインデックスが、登録対象の１つ前のインデックスである。
【発明の効果】
【００１３】
本発明によると、隣接するインデックスのコンテンツタイプを、登録対象のインデックスのコンテンツタイプとして登録するので、コンテンタイプを迅速に登録することができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の好ましい実施形態について、図面を参照して具体的に説明するが、本発明はこれらの実施形態には限定されない。図１は、本発明の好ましい実施形態によるコンテンツタイプ登録装置が適用される増幅装置１００と、インターネットラジオサーバ（以下、単にサーバという）２００との接続構成を示すブロック図である。
【００１５】
サーバ２００は、インターネットラジオと呼ばれる複数のコンテンツを格納している。コンテンツは、音楽（音声）データ、映像データ、および画像データ等を含むが、代表的には、音楽データである。各コンテンツには、増幅装置１００がアクセスしてコンテンツを取得するために、インターネット上の所在を表すＵＲＬ（uniform resource locator）が付与されている。
【００１６】
また、サーバ２００は、格納している全コンテンツの中から選択された複数のコンテンツのコンテンツ情報の一覧であるプレイリスト（コンテンツリスト）を格納している。コンテンツ情報は、タイトル、アーティスト名、アルバム名、ジャンル名等のメタデータや、コンテンツの長さ、リリース年等である。本例では、コンテンツ情報は、タイトルである。図２は、プレイリストの一例を示す図である。図２のプレイリストにおいては、９つのコンテンツが列挙されており、各コンテンツについて、ＵＲＬとタイトルが記述されている。「File1=http://・・・・」と記述されている部分がＵＲＬであり、「Title=・・・・」と記述されている部分がタイトルである。プレイリストには、コンテンツタイプであるＭＩＭＥタイプが含まれていない。
【００１７】
また、サーバ２００は、格納している各コンテンツについてそのＭＩＭＥタイプが保存されている。ＭＩＭＥタイプの詳細については、後述する。
【００１８】
サーバ２００は、増幅装置１００からの要求に応じて、コンテンツ、プレイリスト、ＭＩＭＥタイプを増幅装置１００に返信する。
【００１９】
増幅装置１００は、インターネットラジオ端末としての機能を有しており、サーバ２００からインターネット経由でコンテンツをストリーム形式で取得して、取得したコンテンツを再生する。また、増幅装置１００は、サーバ２００からプレイリストを取得する。また、増幅装置１００は、プレイリストに記述されたＵＲＬにアクセスして、ＭＩＭＥタイプを取得して、各コンテンツについてＭＩＭＥタイプを登録する。そして、プレイリストを表示する際に、コンテンツに登録されたＭＩＭＥタイプに対応するアイコンを併せて表示する。
【００２０】
本例では、ＭＩＭＥタイプの登録を迅速化するために、プレイリスト内の登録対象のインデックスに隣接するインデックスのＭＩＭＥタイプが登録済であれば、サーバ２００から登録対象のインデックスのＭＩＭＥタイプを取得せずに、隣接するインデックスのＭＩＭＥタイプと同じＭＩＭＥタイプを登録する。このように処理するのは、インターネットラジオのプレイリストにおいては、同じＭＩＭＥタイプのコンテンツが連続することが一般的であるので、隣接するインデックスのＭＩＭＥタイプと同じＭＩＭＥタイプを登録することにより、概略正確なＭＩＭＥタイプを迅速に登録さることができるからである。隣接するインデックスとは、１つ前のインデックス又は１つ後のインデックスであるが、本例では１つ前のインデックスである。以下、詳細に説明する。
【００２１】
図３は、増幅装置１００の構成を示すブロック図である。増幅装置１００は、システム制御部２と、記憶部（ＲＯＭ、ＲＡＭ、フラッシュメモリ等を含む）３と、再生部４と、増幅部５と、操作部６と、表示部７と、通信部８とを概略備えている。なお、音声入力端子や電源回路等の増幅装置としての一般的な構成については割愛する。
【００２２】
システム制御部２は、記憶部３に格納されたプログラムに基づいて、増幅装置１００全体を制御するものであり、例えばマイコン等である。システム制御部２は、記憶部３に格納されたアプリケーションプログラムであるＵＩモジュール３Ａ及びリスト情報管理モジュール３Ｂを実行させることにより、後述する各処理を実行する。
【００２３】
ＵＩモジュール３Ａは、表示部７に各種ユーザーインターフェースを表示させるプログラムである。例えば、ＵＩモジュール３Ａは、サーバ２００から取得したプレイリストに含まれる各コンテンツのコンテンツ情報（本例ではタイトル）と、サーバ２００から取得したＭＩＭＥタイプに対応するアイコンを併せて表示する（図６参照）。
【００２４】
リスト情報管理モジュール３Ｂは、サーバ２００からプレイリストやＭＩＭＥタイプを取得して、各コンテンツのＭＩＭＥタイプを登録するプログラムである。リスト情報管理モジュール３Ｂは、ＵＩモジュール３Ａからインデックスを指定されてＭＩＮＥタイプを要求されると、指定されたインデックスの１つ前のインデックスについてＭＩＭＥタイプが登録済であるかを判断する。１つ前のインデックスのＭＩＭＥタイプが登録済であれば、そのＭＩＭＥタイプを指定されたインデックスのＭＩＭＥタイプとして登録する。１つ前のインデックスのＭＩＭＥタイプが登録済でなければ、サーバ２００からＭＩＭＥタイプを取得してＭＩＭＥタイプを登録する。
【００２５】
記憶部３には、リスト情報管理モジュール３Ｂによってサーバ２００から取得された図２に示すプレイリストファイルが保存される。
【００２６】
記憶部３には、図４に示すＭＩＭＥタイプリスト（コンテンツタイプ登録部）が格納されている。ＭＩＭＥタイプリストには最初は何も登録されておらず、ＵＩモジュール３Ａからの要求に応じて、リスト情報管理モジュール３Ｂがインデックス毎にＭＩＭＥタイプを登録する。ＭＩＭＥタイプリストは、記憶部３に格納されているプレイリストのインデックスに対応付けて、コンテンツのＭＩＭＥタイプを含む。インデックスは、目的の情報を探すために手がかりとなる文字または記号であって、本例では、プレイリストに含まれるコンテンツの通し番号（０から始まる整数）である。インデックスは、本例では、ＵＩモジュール３Ａ及びリス情報管理モジュール３Ｂが付与するものであるが、予めサーバ２００によって付与されていてもよい。ＭＩＭＥタイプは、ＷＥＢにおいて使用されているコンテンツデータのタイプ（形式）を示す情報であり、「タイプ名／サブタイプ名」の形式の文字列である。例えば、「audio/mp3」はMP3形式の音楽ファイルであることを、「image/jpeg」はJPEG形式の画像ファイルであることを示す。また、プレイリストには、コンテンツ自体ではなく、別のプレイリストへのリンク情報（すなわち、階層構造のプレイリストにおける上位フォルダ）が含まれている場合がある。このようなリンク情報にもＭＩＭＥタイプが付与されており、「text/xml」や「text/pls」等で表される。また、増幅装置１００で対応していない（すなわち、再生できない）形式のＭＩＭＥタイプの場合には、無効であることを示す「invalid」が登録される。また、特に限定されないが、ＭＩＭＥタイプリストの登録内容は、記憶部３からプレイリストが破棄された時に、クリアされる。
【００２７】
記憶部３には、図５に示すアイコンリストがさらに格納されている。アイコンリストは、ＵＩモジュール３Ａがリスト情報管理モジュール３Ｂから取得したＭＩＭＥタイプをアイコンリストと照らし合わせて、表示すべきアイコンを特定するためのリストである。アイコンリストには、ＭＩＭＥタイプに対応付けて表示すべきアイコンの情報が予め登録されている。例えば、「audio/mp3」には音楽ファイルであることを示すアイコン（音符のアイコン）が対応付けられており、図６（ｂ）に示すようなアイコンが表示される。また、「text/xml」にはリンク情報であることを示すアイコン（フォルダのアイコン）が対応付けられており、図６（ａ）に示すようなアイコンが表示される。なお、アイコンの画像データ自体は記憶部３に予め記録されている。
【００２８】
記憶部３には、図７に示す有効タイプリストがさらに格納されている。有効タイプリストは、サーバ２００から取得したＭＩＭＥタイプについて、リスト情報管理モジュール３Ｂが、増幅装置１００が対応している（有効）か、又は、対応していない（無効）かを判断するためのリストである。有効タイプリストには、有効なＭＩＭＥタイプが予め登録されており、有効タイプリストに登録されていないＭＩＭＥタイプは無効であると判断することができる。（又は、有効タイプリストには、無効なＭＩＭＥタイプも併せて登録されていてもよい。）
【００２９】
図３に戻って、再生部４は、プレイリストに記述されているＵＲＬにアクセスして、サーバ２００から例えばストリーミング形式で取得した音楽ファイルについて、再生処理（伸長処理や、Ｄ／Ａ変換処理等を含む）を実行する。増幅部５は、再生部４によって再生された音楽信号を増幅して、図示しないスピーカーに音楽信号を供給する。
【００３０】
操作部６は、ユーザからの指示を受け付けて、システム制御部２に送信するものであり、増幅装置１００のフロントパネルに設けられた操作ボタンや、リモコン送受信器である。表示部７は、図６に示すようにプレイリスト等を表示するものであり、ＦＬ管やＬＣＤ（液晶ディスプレイ）等である。また、表示部７は、外部に接続される液晶モニタやＴＶ受像機等の表示装置にＯＳＤ（オンスクリーンディスプレイ）表示するものであってもよい。
【００３１】
通信部８は、サーバ２００とインターネット経由で接続して、サーバ２００との間で各種コマンド、コンテンツ、プレイリスト、ＭＩＭＥデータ等を送信および／または受信するものであり、ネットワークインターフェース等である。
【００３２】
以上の構成を有する増幅装置１００について、その動作を説明する。図８は、増幅装置１００がサーバ２００からプレイリストを取得して表示する処理を示すフローチャートである。まず、ユーザ操作によって、増幅装置１００にサーバ２００のＵＲＬが入力されると、リスト情報管理モジュール３Ｂは、サーバ２００にアクセスして、プレイリストを要求する（Ｓ１）。サーバ２００は、要求に応答して、リスト情報管理モジュール３Ｂにプレイリストを返信する（Ｓ２）。リスト情報管理モジュール３Ｂは、プレイリストを受信して、記憶部３に保存する（Ｓ３）。
【００３３】
続いて、再生すべき音楽ファイルを選択するためにユーザ操作によってプレイリストを表示する指示が入力されると、ＵＩモジュール３Ａは、リスト情報管理モジュール３Ｂに、インデックスＮのコンテンツ情報（ここではタイトル）と、ＭＩＭＥタイプを送信するように要求する（Ｓ４）。なお、特に限定されないが、インデックＮは、表示部７に表示可能なコンテンツ数分含まれており、例えば表示部７に１０個のコンテンツを表示できる場合、インデックスＮは０〜９等の１０個のインデックスが指定される。
【００３４】
リスト情報管理モジュール３Ｂは、ＵＩモジュール３Ａからの要求に応答して、ＭＩＭタイプの取得・登録処理を実行する（Ｓ５）。Ｓ５のＭＩＭＥタイプの取得・登録処理の詳細を図９に示す。図９では、ＵＩモジュール３Ａから要求された各インデックスの小さい順番に（降順に）、Ｓ１８で全インデックスについてＭＩＭＥタイプを登録したと判断されるまで、各処理が繰り返し実行される。
【００３５】
まず、リスト情報管理モジュール３Ｂは、ＭＩＭＥタイプを登録する対象のインデックスＮをＵＩモジュール３Ａから要求のあった複数のインデックスのうち最初のインデックスＮに設定する（Ｓ１１）。この例では、Ｎ＝０に設定される。次に、リスト情報管理モジュール３Ｂは、インデックスＮのＭＩＭＥタイプがＭＩＭＥタイプリストに登録済であるか否かを判断する（Ｓ１２）。登録済であれば（Ｓ１２でＹＥＳ）、このインデックスＮのＭＩＭＥタイプを登録する必要はないので、Ｓ１８に進む。Ｓ１８では、インデックスＮは最後のインデックスであるか（つまり、要求のあった全インデックスについて、ＭＩＭＥタイプを登録したか）が判断される。最後のインデックスでなければ（Ｓ１８でＮＯ）、インデックスＮをインクリメントし（Ｓ１９）、Ｓ１２に戻る。
【００３６】
一方、インデックスＮのＭＩＭＥタイプがＭＩＭＥタイプリストに登録されていない場合（Ｓ１２でＮＯ）、リスト情報管理モジュール３Ｂは、インデックスＮ＝０であるか否かを判断する（Ｓ１３）。インデックスＮ＝０であれば、そのインデックスの１つ前のインデックスは存在しなので、１つ前のインデックスのＭＩＭＥタイプを登録対象のインデックスのＭＩＭＥタイプとして登録することができない。そのため、Ｓ１５に進み、リスト情報管理モジュール３Ｂは、記憶部３に保存されているプレイリストを参照して、インデックスＮのＵＲＬにアクセスし、ＭＩＭＥタイプをサーバ２００に要求して取得する。なお、リスト情報管理モジュール３Ｂは、インデックスＮのＵＲＬに「HTTP/HEAD・・」というコマンドを送信すると、サーバ２００はＵＲＬに対応するＭＩＭＥタイプをリスト情報管理モジュール３Ｂに返信する（図７のＳ６）。
【００３７】
ＭＩＭＥタイプの取得後に、リスト情報管理モジュール３Ｂは、取得したＭＩＭＥタイプが有効か否かを判断する（Ｓ１６）。すなわち、取得したＭＩＭＥタイプが有効タイプリストに登録されているＭＩＭＥタイプか否かを判断する。取得したＭＩＭＥタイプが有効タイプリストに登録されていれば（Ｓ１６でＹＥＳ）、リスト情報管理モジュール３Ｂは、インデックスＮに対応付けて、取得したＭＩＭＥタイプをＭＩＭＥタイプリストに登録する（Ｓ１７）。その後、Ｓ１８へと進む。
【００３８】
一方、取得したＭＩＭＥタイプが有効タイプリストに登録されていなければ（Ｓ１６でＮＯ）、取得したＭＩＭＥタイプを破棄して、ＭＩＭＥタイプリストに、インデックスＮに対応付けて、無効であることを示す「invalid」を登録する（Ｓ２２）。その後、Ｓ１８へと進む。なお、通信エラーやサーバに接続できないなどでサーバ２００からＭＩＭＥタイプを取得できなかった場合も、ＭＩＭＥタイプが無効であると判断し、同様の処理が実行される。
【００３９】
一方、Ｓ１３でＮ＝０でない場合（Ｓ１３でＮＯ）、リスト情報管理モジュール３Ｂは、インデックスＮ−１のＭＩＭＥタイプ（つまり、１つ前のインデックスのＭＩＭＥタイプ）がＭＩＭＥタイプリストに登録済であるか否かを判断する（Ｓ１４）。インデックスＮ−１のＭＩＭＥタイプがＭＩＭＥタイプリストに登録されていなければ（Ｓ１４でＮＯ）、Ｓ１５に進み、同様にインデックスＮのＵＲＬにアクセスして、サーバ２００からＭＩＭＥタイプを取得する（Ｓ１５）。以後の処理は同様である。
【００４０】
Ｓ１４でインデックスＮ−１のＭＩＭＥタイプがＭＩＭＥタイプリストに登録済であると判断されると（Ｓ１４でＹＥＳ）、リスト情報管理モジュール３Ｂは、インデックスＮ−１のＭＩＭＥタイプが有効なＭＩＭＥタイプであるか否かを判断する（Ｓ２０）。すなわち、ＭＩＭＥタイプリストにインデックスＮ−１に対応するＭＩＭＥタイプとして「invalid」ではなく、ＭＩＭＥタイプが登録されているかを判断する。
【００４１】
インデックスＮ−１のＭＩＭＥタイプとして「invalid」が登録されている場合（Ｓ２０でＮＯ）、Ｓ１５に進み、同様にインデックスＮのＵＲＬにアクセスして、サーバ２００からＭＩＭＥタイプを取得する。以後の処理は同様である。従って、１つ前のインデックスのＭＩＭＥタイプが無効であれば、登録対象のインデックスのＭＩＭＥタイプを「invalid」とするのではなく、サーバ２００から取得するので、全インデックスのＭＩＭＥタイプが「invalid」と登録されることはない。
【００４２】
一方、インデックスＮ−１のＭＩＭＥタイプとして「invalid」が登録されておらず、有効なＭＩＭＥタイプが登録されている場合（Ｓ２０でＹＥＳ）、リスト情報管理モジュール３Ｂは、サーバ２００からインデックスＮのＭＩＭＥタイプを要求取得することなく、インデックスＮ−１のＭＩＭＥタイプと同じＭＩＭＥタイプを、ＭＩＭＥタイプリストにインデックスＮに対応付けて登録する（Ｓ２１）。その後、Ｓ１８に進む。
【００４３】
Ｓ１８において、ＵＩモジュール３Ａから要求のあった全インデックスについて、ＭＩＭＥタイプリストにＭＩＭＥタイプを登録したと判断されると（Ｓ１８でＹＥＳ）、ＭＩＭＥタイプの取得・登録処理を終了する。
【００４４】
このように、１つ前のインデックスに有効なＭＩＭＥタイプが登録されていれば、同じＭＩＭＥタイプを登録することで、ＭＩＭＥタイプの登録処理を迅速化することができる。従って、連続する複数のインデックスについて、ＭＩＭＥタイプを登録する場合には、最初のインデックスのみサーバ２００からＭＩＭＥタイプを取得して登録しさえすれば、残りのインデックスについては、サーバ２００から取得せずに、最初のインデックスと同じＭＩＭＥタイプを登録すればよく、迅速に登録できる。また、例えば、最初のインデックスのＭＩＭＥタイプが無効で「invalid」が登録された場合には、次のインデックスについては「invalid」が登録されることなく、サーバ２００からＭＩＭＥタイプを取得するので、全インデックスのＭＩＭＥタイプに「invalid」が登録されることを防止できる。
【００４５】
図８に戻って、リスト情報管理モジュール３Ｂは、要求のあったインデックスについて、プレイリストに記述されているタイトルと、Ｓ５で登録したＭＩＭＥタイプをＵＩモジュール３Ａに返信する（Ｓ７）。
【００４６】
ＵＩモジュール３Ａは、タイトルとＭＩＭＥタイプを受信すると、例えば、図６に示すように、表示部７に、タイトルと、ＭＩＭＥタイプに対応するアイコンとを表示させる。つまり、ＵＩモジュール３Ａは、アイコンリストを参照して、ＭＩＭＥタイプに対応するアイコンを特定し、記憶部３からそのアイコンの画像データを読み出して、表示すべきプレイリストの画面を構築し、表示部７に表示させる。なお、ＭＩＭＥタイプが「invalid」である場合には、増幅装置１００で再生できないことを示すアイコン（例えば「×」のアイコン）を表示させるとよい。
【００４７】
以上のように、本発明によると表示部７に表示するコンテンツのＭＩＭＥタイプの登録が迅速化されるので、表示部７にプレイリストが表示されるまでの時間を短縮できる。例えば、サーバ２００からＭＩＭＥタイプを要求取得する時間が３秒であるとすれば、従来のように全インデックス（例えば１０個）についてサーバ２００からＭＩＭＥタイプを取得する場合、１０×３＝３０秒必要であるが、本例では最初のインデックスで有効なＭＩＭＥタイプを取得できた場合には、３×１＝３秒しかかからない。
【００４８】
［他の実施形態１］
本例では、上記実施形態（図９）に加えて、システム制御部２が実際にインデックスＮのコンテンツをサーバ２００から取得して再生する際に、インデックスＮのＭＩＭＥタイプをコンテンツと併せて取得することができるので、インデックスＮのＭＩＭＥタイプが誤っていれば、インデックスＮのＭＩＭＥタイプを修正して、正しいＭＩＭＥタイプをＭＩＭＥタイプリストに登録し、表示部７に表示するプレイリストのインデックスＮのＭＩＭＥタイプを変更するようにする。これにより、最初は、上記実施形態（図９）の通り、迅速にＭＩＭＥタイプを表示できると共に、後から、実際にコンテンツを再生する際に、確実に正しいＭＩＭＥタイプを表示できる。
【００４９】
詳細には、図１０に示すように、システム制御部２は、ユーザ操作に応じて、再生すべきコンテンツのインデックスＮをプレイリストから選択する（Ｓ５０）。リスト情報管理モジュール３Ｂは、インデックスＮのＵＲＬにＨＴＴＰのコンテンツ要求コマンドを送信し、サーバ２００からインデックスＮのコンテンツと、そのＭＩＭＥタイプとを含む応答コマンドを受信し（Ｓ５１）、その中からＭＩＭＥタイプを抽出する（Ｓ５２）。リスト情報管理モジュール３Ｂは、ＭＩＭＥタイプリストに登録されているインデックスＮのＭＩＭＥタイプが正しいか、すなわち、Ｓ５２で抽出したＭＩＭＥタイプと同じであるか否かを判断する（Ｓ５３）。正しければ処理を終了するが、正しくなければ（Ｓ５３でＮＯ）、リスト情報管理モジュール３Ｂは、ＭＩＭＥタイプリストのインデックスＮにＳ５２で抽出した正しいＭＩＭＥタイプを再登録（修正）する（Ｓ５４）。その後、リスト情報管理モジュール３Ｂは、ＵＩモジュール３ＡにプレイリストのインデックスＮのＭＩＭＥタイプが変更されたことを通知する（Ｓ５５）。ＵＩモジュール３Ａは、インデックスＮのＭＩＭＥタイプをリスト情報管理モジュール３Ｂに要求して取得して、プレイリストの表示を変更する。
【００５０】
［他の実施形態２］
本例では、上記実施形態に加えて、例えばシステム制御部２の負荷率が小さいときに、Ｓ２１で１つ前のインデックスＮ−１のＭＩＭＥタイプを登録したインデックスＮを選択して、選択したインデックスのＭＩＭＥタイプを実際にサーバ２００から取得して、ＭＩＭＥタイプリストに登録済のインデックスＮのＭＩＭＥタイプが誤っていれば、インデックスＮのＭＩＭＥタイプを修正して、正しいＭＩＭＥタイプをＭＩＭＥタイプリストに登録し、表示部７に表示するプレイリストのインデックスＮのＭＩＭＥタイプを変更するようにする。これにより、最初は、上記実施形態（図９）の通り、迅速にＭＩＭＥタイプを表示できると共に、後から、負荷率が小さいときに、確実に正しいＭＩＭＥタイプを表示できる。
【００５１】
詳細には、図１１に示すように、リスト情報管理モジュール３Ｂは、Ｓ２１で１つ前のインデックスＮ−１のＭＩＭＥタイプを登録したインデックスＮを選択する（Ｓ６１）。このようなインデックスＮは、Ｓ２１においてＭＩＭＥタイプリストにインデックスＮに対応付けてフラグをセットしておくことによって管理できる。選択したインデックスＮのＭＩＭＥタイプは誤って登録されている可能性がある。そこで、リスト情報管理モジュール３Ｂは、インデックスＮのＵＲＬにＨＴＴＰのコマンドを送信し、サーバ２００からインデックスＮのＭＩＭＥタイプを取得する（Ｓ６２）。以降の処理（Ｓ５３〜Ｓ５５）は、図１０のＳ５３〜Ｓ５５と同じであるので、説明を省略する。なお、本例において、プレイリスト内の１つのインデックスをランダムに選択して上記のようにＭＩＭＥタイプが正確でない場合に、全てのＭＩＭＥタイプが正しいかを確認するようにしてもよい。
【００５２】
以上、本発明の好ましい実施形態を説明したが、本発明はこれらの実施形態には限定されない。ＵＩモジュール３Ａからリスト情報管理モジュール３ＢへのＭＩＭＥタイプ送信要求は、１つのインデックス単位で行ってもよい。インデックスは数字に限定されず、アルファベットであってもよい。１つ前のインデックスのＭＩＭＥタイプをコピーするのではなく、プレイリストをインデックの大きいものから表示する際には、１つ後ろのインデックスのＭＩＭＥタイプをコピーするようにしてもよい。本発明は、上記のコンテンツタイプ登録装置を動作させるためのコンピュータプログラムまたはそのコンピュータプログラムを記録した記録媒体という形態で提供されてもよい。
【産業上の利用可能性】
【００５３】
本発明は、インターネットラジオ機能を有するＡＶアンプに特に好適に適用され得る。
【図面の簡単な説明】
【００５４】
【図１】増幅装置１００とサーバ２００との接続構成を示すブロック図である。
【図２】プレイリストを示す図である。
【図３】増幅装置１００の構成を示すブロック図である。
【図４】ＭＩＭＥタイプリストを示す図である。
【図５】アイコンリストを示す図である。
【図６】プレイリストの表示画面を示す図である。
【図７】有効リストの表示画面を示す図である。
【図８】増幅装置１００のプレイリスト表示処理を示すフローチャートである。
【図９】リスト情報管理モジュールのＭＩＭＥタイプ取得・登録処理を示すフローチャートである。
【図１０】第２実施形態によるＭＩＭＥタイプ取得・修正処理を示すフローチャートである。
【図１１】第３実施形態によるＭＩＭＥタイプ取得・修正処理を示すフローチャートである。
【符号の説明】
【００５５】
１００      増幅装置
２          システム制御部
３          記憶部
３Ａ        ＵＩモジュール
３Ｂ        リスト情報管理モジュール
４          再生部
５          増幅部
６          操作部
７          表示部
８          通信部
２００      サーバ
【要約】
【課題】  プレイリストにＭＩＭＥタイプが含まれておらず、サーバからプレイリストとは別にＭＩＮＥタイプを取得して登録する際に、迅速にＭＩＭＥタイプを登録すること。
【解決手段】  登録対象のインデックスの１つ前のインデックスのＭＩＭＥタイプがＭＩＭＥタイプリストに登録されている場合、登録対象のインデックスのＭＩＭＥタイプをサーバから取得することなく、１つ前のインデックスのＭＩＭＥタイプを登録対象のインデックスのＭＩＭＥタイプとして、ＭＩＭＥタイプリストに登録する。従って、ＭＩＭＥタイプリストにＭＩＭＥタイプを迅速に登録することができる。
【選択図】図９【図１】
0004169087.tif 000002
【図２】
0004169087.tif 000003
【図３】
0004169087.tif 000004
【図４】
0004169087.tif 000005
【図５】
0004169087.tif 000006
【図７】
0004169087.tif 000007
【図８】
0004169087.tif 000008
【図９】
0004169087.tif 000009
【図１０】
0004169087.tif 000010
【図１１】
0004169087.tif 000011
【図６】
0004169087.tif 000012