(57)【要約】【課題】バンド幅上効率的にインターネットラジオ局からメタデータを得る。【解決手段】クライアント１０４はインターネットラジオ局に対応するデータストリームを受信するために、インターネットラジオサーバ１０２に接続する。インターネットラジオ局のデータストリームでメタデータが受信される。一部のケースではインターネットラジオ局のデータストリームでメディアデータも受信される。一旦メタデータが受信されると、クライアント１０４はインターネットラジオサーバ１０２から切り離され、クライアントはいつ次のメタデータがインターネットラジオ局のデータストリームで送られるかを決定し、次のメタデータがインターネットラジオ局のデータストリームで送られる前に、インターネットラジオサーバに再接続する。【選択図】図１
2006228211.tif 000002
【特許請求の範囲】
【請求項１】
クライアントコンピュータデバイスにおいて、
インターネットラジオサーバに接続し、インターネットラジオ局に対応するデータストリームを受信するステップと、
前記インターネットラジオ局のデータストリーム上のメタデータを受信するステップと、
前記インターネットラジオサーバから切断するステップと、
前記インターネットラジオ局のデータストリーム上で、いつ次のメタデータを送るかを決定するステップと、
前記インターネットラジオ局のデータストリーム上で、次のメタデータを送る前に、前記インターネットラジオサーバに再接続するステップとを備えたことを特徴とする、バンド幅上効率的な態様で前記インターネットラジオ局からメタデータを得るための方法。
【請求項２】
前記メタデータを受信するステップと、前記インターネットラジオサーバから切断するステップと、次のメタデータをいつ送るかを決定するステップと、前記インターネットラジオサーバに再接続するステップとを繰り返し実行することを特徴とする、請求項１記載の方法。
【請求項３】
次のメタデータをいつ送るかを決定するステップが、前記インターネットラジオ局で演奏中のその時点でのオーディオセグメントの残留時間を決定するステップを含むことを特徴とする、請求項１記載の方法。
【請求項４】
前記その時点でのオーディオセグメントの残留時間を決定するステップが、その時点でのオーディオセグメントのために受信したメタデータ内のその時点でのオーディオセグメントの残留時間を識別するステップを含むことを特徴とする、請求項３記載の方法。
【請求項５】
前記その時点でのオーディオセグメントの残留時間を決定するステップが、
その時点でのオーディオセグメントのために受信したメタデータ内のその時点でのオーディオセグメントの総時間を識別するステップと、
その時点でのオーディオセグメントのためのメディアペイロードデータを受信するステップと、
前記メディアペイロードデータ内のその時点でのオーディオセグメントに対する経過時間情報または残留時間情報を識別するステップと、
その時点でのオーディオセグメントの総時間および経過時間情報を使って現在のオーディオセグメントの残留時間を決定するステップとを備えたことを特徴とする、請求項３記載の方法。
【請求項６】
次のメタデータをいつ送るかを決定するステップが、前記インターネットラジオ局上で演奏中の、または演奏しようとしているオーディオセグメントの総時間を決定するステップを含むことを特徴とする、請求項１記載の方法。
【請求項７】
最初にクライアントが前記インターネットラジオサーバに接続するときに演奏中の最初のオーディオセグメントのためのメディアペイロードデータを受信するステップを更に備えたことを特徴とする、請求項１記載の方法。
【請求項８】
前記インターネットラジオ局のデータストリームの前記メタデータおよびメディアペイロードデータが、前記インターネットラジオサーバから同じ接続を通して前記クライアントに送られることを特徴とする、請求項１記載の方法。
【請求項９】
前記接続がＨＴＴＰ接続であることを特徴とする、請求項８記載の方法。
【請求項１０】
前記メタデータが前記メディアペイロードデータにより多重化されていることを特徴とする、請求項８記載の方法。
【請求項１１】
前記メタデータが前記メディアペイロードデータの一部として含まれることを特徴とする、請求項８記載の方法。
【請求項１２】
前記インターネットラジオ局のデータストリームの前記メタデータおよび前記メディアペイロードデータが、前記インターネットラジオサーバから前記クライアントにストリーミングされることを特徴とする、請求項１記載の方法。
【請求項１３】
プロセッサと、
前記プロセッサと電子通信するメモリと、
インターネットラジオサーバに接続し、インターネットラジオ局に対応するデータストリームを受信するステップと、
前記インターネットラジオ局のデータストリーム上のメタデータを受信するステップと、
前記インターネットラジオサーバから切断するステップと、
前記インターネットラジオ局のデータストリーム上で、いつ次のメタデータを送るかを決定するステップと、
前記インターネットラジオ局のデータストリーム上で、次のメタデータを送る前に、前記インターネットラジオサーバに再接続するステップとを備えた方法を実施するように実行可能な、前記メモリに記憶された命令とを備えたことを特徴とする、バンド幅上効率的な態様でインターネットラジオ局からメタデータを得るようになっているクライアントコンピュータデバイス。
【請求項１４】
前記メタデータを受信するステップと、前記インターネットラジオサーバから切断するステップと、次のメタデータをいつ送るかを決定するステップと、前記インターネットラジオサーバに再接続するステップとを繰り返し実行することを特徴とする、請求項１３記載のクライアントコンピュータデバイス。
【請求項１５】
次のメタデータをいつ送るかを決定するステップが、前記インターネットラジオ局で演奏中のその時点でのオーディオセグメントの残留時間を決定するステップを含むことを特徴とする、請求項１３記載のクライアントコンピュータデバイス。
【請求項１６】
次のメタデータをいつ送るかを決定するステップが、前記インターネットラジオ局で演奏中の、または演奏しようとしているオーディオセグメントの総時間を決定するステップを含むことを特徴とする、請求項１３記載のクライアントコンピュータデバイス。
【請求項１７】
バンド幅上効率的な態様でインターネットラジオ局からメタデータを得るためのクライアントコンピュータデバイスにおいて、
インターネットラジオサーバに接続し、インターネットラジオ局に対応するデータストリームを受信するステップと、
前記インターネットラジオ局のデータストリーム上のメタデータを受信するステップと、
前記インターネットラジオサーバから切断するステップと、
前記インターネットラジオ局のデータストリーム上で、いつ次のメタデータを送るかを決定するステップと、
前記インターネットラジオ局のデータストリーム上で、次のメタデータを送る前に、前記インターネットラジオサーバに再接続するステップとを備えた方法を実施するための実行可能な命令を含むことを特徴とする、コンピュータで読み取り可能な媒体。
【請求項１８】
前記メタデータを受信するステップと、前記インターネットラジオサーバから切断するステップと、次のメタデータをいつ送るかを決定するステップと、前記インターネットラジオサーバに再接続するステップとを繰り返し実行することを特徴とする、請求項１７記載のコンピュータで読み取り可能な媒体。
【請求項１９】
次のメタデータをいつ送るかを決定するステップが、前記インターネットラジオ局で演奏中のその時点でのオーディオセグメントの残留時間を決定するステップを含むことを特徴とする、請求項１７記載のコンピュータで読み取り可能な媒体。
【請求項２０】
次のメタデータをいつ送るかを決定するステップが、前記インターネットラジオ局で演奏中の、または演奏しようとしているオーディオセグメントの総時間を決定するステップを含むことを特徴とする、請求項１７記載のコンピュータで読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にはコンピュータおよびコンピュータに関連した技術に関する。より詳細には、本発明は、バンド幅上効率的にインターネットラジオ局のためのメタデータを得るためのシステムおよび方法に関する。
【背景技術】
【０００２】
インターネットラジオは、インターネットを介し、一人以上の受信者へオーディオプログラムを送信するものである。現在運用中のインターネットラジオ局は異なる多くのタイプがある。従来のラジオ局の単なるサイマルキャストに過ぎないインターネットラジオ局もあれば、従来のラジオ局と完全に独立しており、インターネットだけで放送を行っているインターネットラジオ局もある。インターネット接続速度が速くなり、接続コストが低下したために、インターネットラジオ局の普及が継続して拡大する傾向がある。
【０００３】
インターネットラジオ局の設立に関係するコンポーネントは多数ある。まずインターネットラジオ局用のプログラム信号が発生される。このプログラム信号はインターネットラジオ局のコンテントを含む。一旦プログラム信号が発生されると、符号化ツールを使ってプログラム信号をデータストリームに符号化する。サーバがデータストリームをクライアントに提示し、クライアントはサーバに接続し、データストリームを受信できる。
【０００４】
インターネットラジオ局用のデータストリームはメディアペイロードデータとメタデータの双方を含むことができる。メディアペイロードデータとは、インターネットラジオ局のコンテントを含むデータのことであり、例えばインターネットラジオ局が音楽を転送する場合、メディアペイロードデータは音楽データを含む。これと対照的に、メタデータとはメディアペイロードデータに関する記述データである。例えば特定の歌に対応するメタデータとして、歌の題名、アルバム名、歌のアルバムからのイメージなどを挙げることができる。
【０００５】
これまでクライアントがインターネットラジオ局用のデータストリームにアクセスする際、クライアントはメタデータとメディアペイロードデータの双方を受信する。しかしながら、ある状況下では、クライアントはメタデータしか使用しないことがある。例えばいくつかの異なるインターネットラジオ局からの現在のメタデータをユーザーにディスプレイし、ユーザーが異なる局で現在何が演奏されているかを即座に知ることができるようにクライアントを構成できる。別の例として、データマイニング操作のために１つ以上のインターネットラジオ局からのメタデータを使用することもできる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
インターネットラジオ局のためのメタデータを得るための１つの方法として、メタデータとメディアペイロードデータの双方を受信し、次にメディアペイロードデータを廃棄する方法がある。しかしながら、かかる方法は非効率である。その理由は、クライアントが利用しないメディアペイロードデータを送受信するのにネットワークリソースを使用するからである。従って、インターネットラジオ局のためのメタデータを得るための改良されたシステムおよび方法により利点が得られる。
【０００７】
添付図面を参照し、次の説明および請求の範囲を読めば、本発明の実施例がより完全に明らかとなろう。しかしながら、これら図は単に実施例を示すに過ぎず、従って、発明の範囲を限定するものでないと理解した後に、添付図面を使用することにより、本発明の実施例について更に詳細に説明する。
【課題を解決するための手段】
【０００８】
バンド幅上効率的な態様でインターネットラジオ局からメタデータを得るための方法が開示されている。この方法はクライアントコンピュータデバイスによって実行できる。この方法によれば、クライアントデバイスはインターネットラジオサーバに接続し、インターネットラジオ局に対応するデータストリームを受信する。インターネットラジオ局のデータストリーム上のメタデータも受信する。クライアントデバイスはインターネットラジオサーバから切り離され、次のメタデータがインターネットラジオ局のデータストリーム上でいつ送るかを決定する。クライアントデバイスは次のメタデータがインターネットラジオ局のデータストリーム上で送られる前にインターネットラジオサーバに再接続する。一部の実施例では、前記メタデータを受信するステップと、前記インターネットラジオサーバから切断するステップと、次のメタデータをいつ送るかを決定するステップと、前記インターネットラジオサーバに再接続するステップとを繰り返し実行する。
【０００９】
次のメタデータをいつ送るかを決定するステップは、前記インターネットラジオ局で演奏中のその時点でのオーディオセグメントの残留時間を決定することに関与する。一部の実施例では、前記オーディオセグメントの残留時間を決定するステップは、その時点でのオーディオセグメントのために受信したメタデータ内のその時点でのオーディオセグメントの残留時間を識別するステップに関与する。
【００１０】
別の実施例では、その時点でのオーディオセグメントの残留時間を決定するステップは、その時点でのオーディオセグメントのために受信したメタデータ内のその時点でのオーディオセグメントの総時間を識別することに関与する。クライアントデバイスはその時点でのオーディオセグメントのためのメディアペイロードデータを受信し、メディアペイロードデータ内のその時点でのオーディオセグメントに関する経過時間情報または残留時間情報を識別する。次に、その時点でのオーディオセグメントの総時間および経過時間情報を使ってその時点でのオーディオセグメントの残留時間が決定される。
【００１１】
一部の実施例では、次のメタデータをいつ送るかを決定するステップは、インターネットラジオ局で演奏中の、または演奏されようとしているオーディオセグメントの総時間を決定することに関与する。更に、一部の実施例では、クライアントデバイスは、クライアントが最初にインターネットラジオサーバに接続するときに、演奏中の最初のオーディオセグメントのためのメディアペイロードデータを受信する。
【００１２】
インターネットラジオ局のデータストリームのメタデータおよびメディアペイロードデータは、同じ接続を通して、インターネットラジオサーバからクライアントへ送ることができる。この接続はＨＴＴＰ接続でよい。インターネットラジオ局のデータストリームのうちのメタデータおよびメディアペイロードデータは、インターネットラジオサーバからクライアントへストリーミングできる。メタデータはメディアペイロードデータと多重化できる。また、メタデータはメディアペイロードデータの一部として含まれてもよい。
【００１３】
バンド幅上効率的な態様で、インターネットラジオ局からメタデータを得るための上記方法を実現するようになっているクライアントコンピュータデバイスも開示される。このクライアントはプロセッサと、このプロセッサと電子通信するメモリとを含む。メモリには命令が記憶され、これら命令は上記方法を実施するように実行可能である。更にバンド幅上効率的な態様でインターネットラジオ局からメタデータを得るための上記方法を実施するための実行可能な命令を含む、コンピュータで読み取り可能な媒体も開示されている。
【００１４】
以下、図面を参照し、本発明の種々の実施例について説明する。図中、同様な参照番号は同一または機能的に類似する要素を示す。本明細書に一般的に説明し、図面に示す本発明の実施例を広範な種々の異なる形態で配置し、設計できることは容易に理解できよう。従って、図面に示す本発明のいくつかの実施例の次のより詳細な説明は、特許請求の範囲に記載のような発明の範囲を限定するものでなく、単に発明の実施例を示すにすぎない。
【発明を実施するための最良の形態】
【００１５】
本明細書では、「例」なる用語は「一例として、一事例として、又は一例解として働く」ことを意味するように専ら使用されるものである。本明細書で「例」として記載される実施例は必ずしも他の実施例よりも有利であるか、または好ましいものであると見るべきではない。図面には実施例の種々の特徴について示したが、これらの図は特に表示しない限り、実際の寸法どおりに描かれてはいない。
【００１６】
本明細書に開示した実施例の多くの特徴は、当業者には、コンピュータソフトウェア、電子ハードウェアまたはそれらの組み合わせとして実現できることが理解できよう。ハードウェアとソフトウェアとの相互交換可能性を明瞭に示すために、それらの機能の点で種々のコンポーネントについて一般的に説明することにする。かかる機能をハードウェアで実現するか、またはソフトウェアで実現するかは、特定の用途およびシステム全体にかかる設計上の制限に応じて決まる。当業者であれば、特定の各用途に対し、種々の態様で記載した機能を実現できるが、かかる実現の判断は本発明の範囲から逸脱させるものと解釈すべきではない。
【００１７】
説明する機能をコンピュータソフトウェアとして実現する場合、当業者であれば、かかるソフトウェアはメモリデバイスに位置し、および／またはシステムバスまたはネットワークを通して電子信号として送信される任意のタイプのコンピュータ命令またはコンピュータで実行可能なコードを含むことができると認識できよう。本明細書で説明するコンポーネントに関連する機能を実現するソフトウェアは、単一命令または多数の命令を含むことができ、異なるプログラムの間のいくつかの異なるコードセグメントにわたって分散させ、いくつかのメモリデバイスにわたって分散させることができる。
【００１８】
図１は、一部の実施例を実施できるシステム例１００を示す機能ブロック図である。このシステム１００はインターネットラジオサーバ１０２と、クライアント１０４とを含む。サーバ１０２とクライアント１０４とは互いにインターネット１０６を介して通信できる。
【００１９】
サーバ１０２は多数の異なるデータストリーム１０８をクライアント１０４に提示する。各データストリーム１０８は異なるインターネットラジオ局に対応し、各データストリーム１０８はメタデータ１１０と、メディアペイロードデータ１１２の双方を含む。
【００２０】
メタデータ１１０は、各オーディオセグメント（例えば歌、トークショーセグメント、音声オーバー、コマーシャルなど）ごとに送られる。前のオーディオセグメントが演奏を終了したとき、特定のオーディオセグメントのためのメタデータ１１０が送られる。例えばインターネットラジオ局で歌Ａと歌Ｂとが順次演奏される場合、歌Ａが演奏を終了したとき、または演奏をまさに終了しようとしているときに、歌Ｂのためのメタデータ１１０が送られる。
【００２１】
メタデータ１１０はメディアペイロードデータ１１２とは別個に、または、これと一緒に送ってもよい。一部の実施例では、サーバ１０２は多重化されたアーキテクチャを利用できる。多重化されたアーキテクチャの場合、特定のオーディオセグメントのためのメタデータ１１０がメディアペイロードデータと同じ接続（例えば同じＨＴＴＰ接続）で多重化された状態で送られる。メタデータは一般に新しいオーディオセグメントのためのメディアペイロードデータ１１２が送られる直前に送られる。あるいは、サーバ１０２は埋め込み型アーキテクチャを利用できる。埋め込み型アーキテクチャの場合、特定のオーディオセグメントのためのメタデータ１１０はメディアペイロードデータ１１２一部としてこのデータと共に送られる。例えばメディアペイロードデータ１１２はＭＰ３データでよく、メタデータ１１０はＭＰ３データに含まれるＩＤ３タグとすることができる。
【００２２】
図示した実施例では、特定のオーディオセグメントのためのメタデータ１１０は、オーディオセグメントの残りの時間１１４の表示を含む。特定のオーディオセグメントのためのメタデータ１１０はオーディオセグメントの全体の長さ１１６の表示も含む。
【００２３】
クライアント１０４は接続設定コンポーネント１１８を含み、この接続設定コンポーネント１１８はインターネットラジオサーバ１０２との接続を設定するように構成されている。この接続はＨＴＴＰ接続でよい。
【００２４】
クライアント１０４はデータストリーム受信コンポーネント１２０も含み、このデータストリーム受信コンポーネント１２０はサーバ１０２からのインターネットラジオ局に対応するデータストリーム１０８を受信するように構成されている。
【００２５】
クライアント１０４はメタデータタイミングコンポーネント１２２も含み、このメタデータタイミングコンポーネント１２２はメタデータ１１０がラジオ局ストリーム１０８上で次にいつ送るかを決定するようになっている。
【００２６】
図示した実施例では、メタデータタイミングコンポーネント１２２は残留時間識別コンポーネント１２４と、総時間識別コンポーネント１２６とを含み、残留時間識別コンポーネント１２４はオーディオセグメントの残留時間１１４を識別するようになっており、同様に、総時間識別コンポーネント１２６はオーディオセグメントの総時間１１６を識別するようになっている。
【００２７】
メディアクライアント１０４は接続終了コンポーネント１２８も含み、この接続終了コンポーネント１２８は以前設定されたインターネットラジオサーバ１０２との接続を終了するようになっている。
【００２８】
図２は、バンド幅上効率的な態様でインターネットラジオ局からメタデータ１１０を入手するための方法２００を実施するのに、図１のシステム１００内のコンポーネントがどのように作動できるかを示すフローチャートである。この方法２００は接続設定コンポーネント１１８がインターネットラジオサーバ１０２に接続したときからスタートする（２０２）。これに応答し、データストリーム受信コンポーネント１２０はサーバ１０２からのインターネットラジオ局に対応するデータストリーム１０８を受信する。最初に、その時点でのオーディオセグメントのためのメタデータ１１０が受信される（２０４）。（例えばサーバ１０２が多重化アーキテクチャを利用している場合）メディアペイロードデータ１１２とは別個にメタデータ１１０を受信してもよいし、または（例えばサーバ１０２が埋め込み型アーキテクチャを利用している場合）メディアペイロードデータ１１２と共にメタデータ１１０を受信してもよい。
【００２９】
メタデータ１１０が一旦受信されると、接続終了コンポーネント１２８はサーバ１０２への接続を終了させる（２０６）。この結果、その時点でのオーディオセグメントのためのメディアペイロードデータ１１２の少なくとも一部は、サーバ１０２からクライアント１０４へストリーミングされない。この結果、クライアント１０４によって使用されなくなるデータを送信信するのにネットワークリソースが使用されないので、ネットワークリソースがより効率的に使用される。有利なことに、サーバ１０２を変更することなく、更なる効率が得られる。
【００３０】
メタデータタイミングコンポーネント１２２はラジオ局ストリーム１０８でいつ次のメタデータ１１０が送られようとしているかを決定する。クライアント１０４がサーバ１０２に接続する最初のときに、残留時間識別コンポーネント１２４によってこのステップが実行される。より詳細には、残留時間識別コンポーネント１２４は現在のオーディオセグメントのためのメタデータ１１０内のその時点でのオーディオセグメントの残留時間１１４を識別する（２０８）。現在のオーディオセグメントの残留時間１１４が一旦わかると、この時間は（その時点でのオーディオセグメントが演奏を中止したときに、次のメタデータ１１０が送られるので）次のメタデータ１１０がいつ送られるかをクライアント１０４に伝える。
【００３１】
その時点でのオーディオセグメントが完了する直前に接続設定コンポーネント１１８はサーバ１０２に再接続する（２１０）。より正確に説明すれば、クライアント１０４がどれだけ早い時間にサーバ１０２に再接続するかは、種々の要因、例えばインターネットラジオサーバ１０２の必要条件、ネットワークの混み具合、一般的な接続設定時間などに応じて決まり得る。
【００３２】
その時点でのオーディオセグメントが完了すると、ラジオ局ストリーム１０８上で次のオーディオセグメントのためのメタデータ１１０が送られる。このメタデータ１１０は（サーバ１０２が多重化されたアーキテクチャを使用している場合）メディアペイロードデータ１１２とは別個に送ってもよいし、または（サーバ１０２が埋め込み型アーキテクチャを使用している場合）メディアペイロードデータ１１２と共に送ってもよい。データストリーム受信コンポーネント１２０は次のオーディオセグメント（このセグメントは次にその時点でのオーディオセグメントとなる）のためのメタデータ１１０を受信する（２１２）。一旦メタデータ１１０が受信されると、接続終了コンポーネント１２８がサーバ１０２への接続を終了させる（２１４）。
【００３３】
前述のように、メタデータタイミングコンポーネント１２２はラジオ局ストリーム１０８上で次のメタデータ１１０がいつ送られるかも決定する。クライアント１０４がサーバ１０２に接続すると、そのつど、まず始めに、このステップが総時間識別コンポーネント１２６によって実行される。より詳細に説明すれば、総時間識別コンポーネント１２６はその時点でのオーディオセグメントに対して、受信されたメタデータ１１０内のその時点でのオーディオセグメントの総時間１１６を識別する（２１６）。一旦その時点でのオーディオセグメントの総時間１１６がわかると、この総時間は次のメタデータ１１０がいつ送るかをクライアント１０４に伝える（その理由は、この方法２００におけるこの時点で、その時点でのオーディオセグメントは再生を開始しており、その時点でのオーディオセグメントが演奏を停止したときに、次のメタデータ１１０が送られるからである）。
【００３４】
次に、方法２００のステップ２１０〜２１６を繰り返す。特にその時点でのオーディオセグメントが完了する直前に、接続設定コンポーネント１１８がサーバ１０２に再接続する（２１０）。データストリーム受信コンポーネント１２０は次のオーディオセグメント（このセグメントは次のオーディオセグメントとなる）のためのメタデータ１１０を受信する（２１０）。接続終了コンポーネント１２８はサーバ１０２への接続を終了させる（２１４）。総時間識別コンポーネント１２６はその時点でのオーディオセグメントのためのメタデータ１１０内の、その時点でのオーディオセグメントの総時間１１６を識別する（２１６）。このサイクルは、クライアント１０４がインターネットラジオ局のためのメタデータ１１０の入手を続けない旨の命令を受信するまで続く。一部の実施例では、ステップ２０８の後、またはステップ２０８と並行に、ステップ２０６を実行してもよい。同様に、ステップ２１６の後、またはステップ２１６と並行に、ステップ２１４を実行してもよい。
【００３５】
図３は、いくつかの実施例を実現できる別のシステム例３００を示す機能ブロック図である。前述のように、システム３００はインターネットラジオサーバ３０２とクライアント３０４とを含み、サーバ３０２とクライアント３０４はインターネット３０６を介して互いに通信できる。サーバ３０２は異なるインターネットラジオ局に対応する異なるデータストリーム３０８をクライアント３０４に提示する。各データストリーム３０８はメタデータ３１０と、メディアペイロードデータ３１２の双方を含む。
【００３６】
図示されている実施例では、特定のオーディオセグメントのためのメタデータ３１０はオーディオセグメントの総時間３１６の表示を含む。しかしながら、特定のオーディオセグメントのためのメタデータ３１０はオーディオセグメントの残留時間の表示を含まない。
【００３７】
メディアペイロードデータ３１２は経過時間情報および／または残留時間情報３３０を含む。経過時間情報３３０とは、オーディオセグメントが演奏を開始してから経過した時間の長さの表示のことである。例えば経過時間情報３３０はタイムスタンプ、フレーム数などとすることができる。あるいは、またはこれに加えて、メディアペイロードデータ３１２はその時点でのオーディオセグメント内に残っている時間の長さを示す残留時間情報３３０を含むことができる。
【００３８】
前と同じように、クライアント３０４は接続設定コンポーネント３１８と、データストリーム受信コンポーネント３２０と、接続終了コンポーネント３２８と、メタデータタイミングコンポーネント３２２とを含む。メタデータタイミングコンポーネント３２２は総時間識別コンポーネント３２６を含む。これらコンポーネントの各々によって実行される機能の説明については既に説明したとおりであり、本明細書では説明を繰り返すことはしない。
【００３９】
図示された実施例では、メタデータタイミングコンポーネント３２２は経過時間識別コンポーネント３３２と、残留時間計算コンポーネント３３４も含む。経過時間識別コンポーネント３３２はメディアペイロードデータ３１２内の経過時間情報３３０を識別するようになっており、残留時間計算コンポーネント３３４はその時点でのオーディオセグメントの総時間３１６を使って、その時点でのオーディオセグメントの残留時間と、その時点でのオーディオセグメントに対する経過時間情報３３０を計算するようになっている。その時点でのオーディオセグメントの残留時間は、その時点でのオーディオセグメントの総時間３１６からその時点でのオーディオセグメントの経過時間３３２を減算した値として計算できる。
【００４０】
図４は、図３のシステム３００内のコンポーネントがバンド幅上効率的な態様でインターネットラジオ局からのメタデータ３１０を得るための方法４００を実現できるようにどのように作動するかを示すフローチャートである。方法４００は接続設定コンポーネント３１８がインターネットラジオサーバ３０２に接続してスタートする（４０２）。これに応答し、データストリーム受信コンポーネント３２０はサーバ３０２からのインターネットラジオ局に対応するデータストリーム３０８を受信する。最初にその時点でのオーディオセグメントのためのメタデータ３１０が受信される（４０４）。更に（例えばフレーム数またはタイムスタンプから）メディアペイロードデータに基づき、クライアントがその時点でのオーディオセグメントの経過時間および／または残留時間を解決できるまで、そのときに演奏中のオーディオセグメントのための一部のメディアペイロードデータも受信される。メタデータ３１０が一旦受信されると、サーバ３０２からクライアント３０４にメディアペイロードデータ３１２の少なくとも一部がストリーミングされないよう、接続終了コンポーネント３２８はサーバ３０２への接続を終了させる（４０６）。
【００４１】
メタデータタイミングコンポーネント３２２は次のメタデータ３１０をラジオ局ストリーム３０８でいつ送るかを決定する。クライアント３０４がサーバ３０２に接続する最初のときに、このステップは総時間識別コンポーネント３２６、経過時間識別コンポーネント３３２および残留時間計算コンポーネント３３４により実行される。より詳細には、総時間識別コンポーネント３２６はその時点でのオーディオセグメントに対して受信されたメタデータ３１０内のその時点でのオーディオセグメントの総時間３１６を識別する（４０８）。経過時間識別コンポーネント３３２はメディアペイロードデータ３１２内のその時点でのオーディオセグメントに対する経過時間情報３３０を識別する（４１０）。残留時間計算コンポーネント３３４はその時点でのオーディオセグメントの総時間３１６および経過時間情報３３０を使って、その時点でのオーディオセグメントの残留時間を計算する（４１２）。その時点でのオーディオセグメントの残留時間が一旦判れば、このことによって次のメタデータ３１０がいつ送られるかクライアント３０４に伝えられる（上に示したように、その時点でのオーディオセグメントが演奏を中止したときに次のメタデータ３１０が送られるからである）。
【００４２】
接続設定コンポーネント３１８はその時点でのオーディオセグメントが完了する直前にサーバ３０２に再接続する（４１４）。その時点でのオーディオセグメントが完了すると、ラジオ局ストリーム３０８にて次のオーディオセグメントのためのメタデータ３１０が送られ、クライアント３０４のデータストリーム受信コンポーネント３２０により受信される（４１６）。次のオーディオセグメント（このセグメントは次のオーディオセグメントとなる）のためのメタデータ３１０が一旦受信されると、接続終了コンポーネント３２８はサーバ３０２への接続を終了させる（４１８）。
【００４３】
メタデータタイミングコンポーネント３２２は再びラジオ局ストリーム３０８上で次のメタデータ３１０をいつ送るかを決定する。サーバ３０２への最初に接続した後の時間ごとに、総時間識別コンポーネント３２６によりこのステップが実行される。より詳細には、総時間識別コンポーネント３２６はその時点でのオーディオセグメントに対して受信されたメタデータ３１０内のその時点でのオーディオセグメントの総時間３１６を識別する（４２０）。総時間オーディオセグメントの総時間３１６が一旦判ると、これにより、次のメタデータ３１０がいつ送られるかクライアント３０４に伝えられる（方法４００内のこの時点では、その時点でのオーディオセグメントは、再生の開始時にあるその時点でのオーディオセグメントが演奏を中止したときに、次のメタデータ３１０が送られるからである）。
【００４４】
次にこの方法４００のうちのステップ４１４〜４２０が繰り返される。特に接続設定コンポーネント３１８はその時点でのオーディオセグメントが完了する直前にサーバ３０２へ再接続する（４１４）。データストリーム接続コンポーネント３２０は次のオーディオセグメント（このセグメントは次のセグメントとなる）のためのメタデータ３１０を受信する（４１６）。接続終了コンポーネント３２８はサーバ３０２への接続を終了させる（４１８）。総時間識別コンポーネント３２６はその時点でのオーディオセグメントのためのメタデータ３１０内のその時点でのオーディオセグメントの総時間３１６を識別する（４２０）。このサイクルはクライアント３０４がインターネットラジオ局のためのメタデータ３１０を入手することを中止するための命令を受信するまで続く。一部の実施例では、ステップ４０６をステップ４１２の後、またはこのステップと並列に実行してもよい。同様に、ステップ４１８をステップ４２０の後で、またはこのステップと並列に実行してもよい。
【００４５】
図５は、一部の実施例を実施できる別のシステム例５００を示す機能ブロック図である。前と同じように、システム５００はインターネットラジオサーバ５０２とクライアント５０４とを含み、サーバ５０２とクライアント５０４は、インターネット５０６を介して互いに通信できる。サーバ５０２は、異なるインターネットラジオ局に対応する異なる多くのデータストリーム５０８をクライアント５０４に露出する。各データストリーム５０８はメタデータ５１０と、メディアペイロードデータ５１２の双方を含む。
【００４６】
図示されている実施例では、特定のオーディオセグメントのためのメタデータ５１０は、オーディオセグメントの総時間５１６の表示を含む。しかしながら、メタデータ５１０はオーディオセグメントの残留時間の表示を含まない。また、メディアペイロードデータ５１２はその時点でのオーディオセグメントに対する経過時間情報および／または残留時間情報の表示を含まない。
【００４７】
前述のように、クライアント５０４は接続設定コンポーネント５１８と、データストリーム受信コンポーネント５２０と、接続終了コンポーネント５２８と、メタデータタイミングコンポーネント５２２とを含む。メタデータタイミングコンポーネント５２２は、総時間表識別コンポーネント５２６を含む。これらコンポーネントの各々によって実行される機能の説明については既に説明したとおりであり、本明細書では説明を繰り返さない。図示された実施例では、メタデータタイミングコンポーネント５２２は上記のようないくつかのコンポーネント、例えば残留時間識別コンポーネント、経過時間識別コンポーネントまたは残留時間計算コンポーネントを含まない。
【００４８】
図６は、図５のシステム５００内のコンポーネントがバンド幅上効率的な態様でインターネットラジオ局からのメタデータ５１０を得るための方法６００を実現できるようにどのように作動するかを示すフローチャートである。方法６００は、接続設定コンポーネント５１８がインターネットラジオサーバ５０２に接続してスタートする（６０２）。これに応答し、データストリーム受信コンポーネント５２０はサーバ５０２からのインターネットラジオ局に対応するデータストリーム５０８を受信する。前と同じように、その時点でのオーディオセグメントのためのメタデータ５１０が受信される（６０４）。更にクライアント５０４がサーバ５０２に接続した最初のときに、クライアント５０４はその時点でのオーディオセグメントのためのメディアペイロードデータ５１２も受信されるよう（６０４）、サーバ５０２に接続された状態のままである。その理由は、インターネットラジオ局で次のメタデータ５１０をいつ送るかを決定するときに十分な情報をメタデータタイミングコンポーネント５２２が有していないからである。
【００４９】
その時点でのオーディオセグメントが終了すると、データストリーム受信コンポーネント５２０は次のオーディオセグメント（このセグメントが次のオーディオセグメントとなる）のためのメタデータ５１０を受信する（６０６）。メタデータ５１０が一旦受信されると、接続終了コンポーネント５２８がサーバ５０２への接続を終了させる（６０８）。
【００５０】
メタデータタイミングコンポーネント５２２は次のメタデータ５１０がラジオ局ストリーム５０８でいつ送られるかを決定する。図示された実施例では、このステップは、総時間識別コンポーネント５２６により実行され、その時点でのオーディオセグメントに対して受信されたメタデータ５１０内のその時点でのオーディオセグメントの総時間５１６を識別する（６１０）。その時点でのオーディオセグメントの総時間が一旦判ると、これによって次のメタデータ５１０がいつ送られるかクライアント５０４に伝えられる（その時点でのオーディオセグメントは再生の開始時にあり、その時点でのオーディオセグメントが演奏を中止したときに次のメタデータ５１０が送られるからである）。接続設定コンポーネント５１８はその時点でのオーディオセグメントが完了する直前にサーバ５０２へ再接続する（６１２）。
【００５１】
次に、この方法６００のうちのステップ６０６〜６１２が繰り返される。特に、データストリーム受信コンポーネント５２０は次のオーディオセグメント（このセグメントは次のセグメントとなる）のためのメタデータ５１０を受信する（６０６）。接続終了コンポーネント５２８はサーバ５０２への接続を終了させる（６０８）。総時間識別コンポーネント５２６は、その時点でのオーディオセグメントのために受信されたメタデータ５１０内のその時点でのオーディオセグメントの総時間５１６を識別する（６１０）。接続設定コンポーネント５１８はその時点でのオーディオセグメントが完了する直前にサーバ５０２へ再接続する（６１２）。このサイクルはクライアント５０４がインターネットラジオ局のためのメタデータ５１０を入手することを中止するための命令を受信するまで続く。一部の実施例では、ステップ６０８をステップ６１０の後、またはこのステップと並列に実行してもよい。
【００５２】
上記に鑑み、本明細書に説明した実施例は従来の方法では得られないいくつかの利点を提供できる。クライアントはメディアペイロードデータの少なくとも一部を受信しなくても、インターネットラジオ局のためのメタデータを得ることができる。クライアントによって使用されないデータを送受信するのに、ネットワークリソースが使用されないので、ネットワークリソースをより効率的に使用できる。有利なことに、インターネットラジオサーバを変更しなくても、更に効率が得られる。
【００５３】
更に、クライアントが繰り返してサーバに再接続したり、サーバから切断するために使用される余分なバンド幅は、メディアペイロードデータの少なくとも一部をクライアントが受信しないことにより節約されるバンド幅量と比較して無視できるものとなる。より詳細には、クライアントがＨＴＴＰプロトコルを使ってサーバへの接続を設定するには、一般に３×（４０）＋Ｈ＋Ｘ＋Ｒ＋４×（４０）バイト（アップストリーム＋ダウンストリーム）が必要である。この式では、変数ＸはＨＴＴＰリクエストのサイズに等しく、このサイズは一般にＵＲＬの長さに近い。変数ＨはＨＴＴＰリクエストヘッダーのサイズに等しく、変数ＲはＨＴＴＰレスポンスヘッダーのサイズに等しい。３および４のファクターはそれぞれ３方向ＴＣＰ接続設定および切断に対応し、この場合、余分なＴＣＰオプションはない。平均的歌の長さが３分間であり、Ｈ＝Ｒ＝Ｘ＝１００バイトであると見なすと、推奨される方法は、約（５８０×８）／（３×６０）＝毎秒２５.７７ビットのエクストラオーバーヘッドしか必要でない。この値は推奨される方法の結果、クライアントがメディアペイロードデータを受信しないでバンド幅を無駄にしない結果と比較して無視できる値である。
【００５４】
図７は、サーバ７０２および／またはクライアント７０４内で一般に利用されるハードウェアコンポーネントの主要部を示すブロック図である。同じ物理構造または別個のハウジングまたは構造体内に図示されたコンポーネントが位置できる。
【００５５】
サーバ７０２／クライアント７０４はプロセッサ７０１とメモリ７０３とを含む。プロセッサ７０１はサーバ７０２／クライアント７０４の作動を制御し、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ）または当技術分野で公知の他のデバイスとして具現化できる。プロセッサ７０１は一般にメモリ７０３内に記憶されたプログラム命令に基づき、論理代数演算を実行する。
【００５６】
本明細書で使用されるように、「メモリ」７０３なる用語は、電子情報を記憶できる任意の電子部品として広義に定義され、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶メディア、光記憶メディア、ＲＡＭ内のフラッシュメモリデバイス、プロセッサ７０１内に設けられるオンボードメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタなどとして具現化できる。メモリ７０３は一般にプログラム命令または他のタイプのデータを記憶する。これらプログラム命令は本明細書に開示した方法の一部またはすべてを実施するように、プロセッサ７０１によって実行できる。
【００５７】
サーバ７０２／クライアント７０４は他の電子デバイスと通信するために一般に１つ以上の通信インタフェース７０５も含む。これら通信インタフェース７０５は有線通信技術、無線通信技術またはその双方に基づくことができる。異なるタイプの通信インタフェース７０５の例として、シリアルポート、パラレルポート、ユニバーサルシリアルバス（ＵＳＢ）、イーサネット（登録商標）アダプタ、ＩＥＥＥ１３９４バスインタフェース、スモールコンピュータシステムインタフェース（ＳＣＳＩ）バスインタフェース、赤外線（ＩＲ）通信ポート、ブルートゥース無線通信アダプタ等々を挙げることができる。
【００５８】
サーバ７０２／クライアント７０４は一般に１つ以上の入力デバイス７０７および１つ以上の出力デバイス７０９も含む。異なる種類の入力デバイス７０７の例として、キーボード、マウス、マイクロフォン、リモコンデバイス、ボタン、ジョイスティック、トラックボール、タッチパッド、ライトペンなどを挙げることができる。異なる種類の出力デバイス７０９の例として、スピーカー、プリンタなどを挙げることができる。コンピュータシステムに一般に含まれる出力デバイスの特別なタイプとして、ディスプレイデバイス７１１がある。本明細書に開示した実施例と共に使用されるディスプレイデバイス７１１は、任意の適当な画像投影技術、例えば陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）、ガスプラズマ、エレクトロルミネッセンス等を利用できる。メモリ７０３に記憶されているデータを、ディスプレイデバイス７１１に示される（適当な）テキスト、グラフィックおよび／または動画に変換するためのディスプレイコントローラ７１３を設けてもよい。
【００５９】
当然ながら、図７はサーバ７０２／クライアント７０４の１つの可能なコンフィギュレーションしか示していない。当業者であれば、その他の種々のアーキテクチャおよびコンポーネントも利用できることが認識できよう。更に本発明の特徴を不明瞭にしないように、種々の標準的なコンポーネントは図示していない。
【００６０】
以上で、本発明の特定の実施例およびアプリケーションについて図示し、説明したいが、本発明は本明細書に開示したものと同じコンフィギュレーションおよびコンポーネントだけに限定されるものでないと理解すべきである。当業者であれば、本発明の範囲から逸脱することなく、本明細書に開示した本発明の方法およびシステムの配置、動作および細部について種々の変形、変更および置換が明らかであろう。
【図面の簡単な説明】
【００６１】
【図１】一部の実施例を実施できるシステムの一例を示す機能ブロック図である。
【図２】バンド幅上効率的な態様でインターネットラジオ局からメタデータを得るための方法を実現するのに、図１のシステム内のコンポーネントはどのように作動できるかを示すフローチャートである。
【図３】一部の実施例を実現できる別のシステムの例を示す機能ブロック図である。
【図４】バンド幅上効率的な態様でインターネットラジオ局からメタデータを得るための方法を実現するのに、図３のシステム内のコンポーネントはどのように作動できるかを示すフローチャートである。
【図５】一部の実施例を実現できる別のシステムの例を示す機能ブロック図である。
【図６】バンド幅上効率的な態様でインターネットラジオ局からメタデータを得るための方法を実現するのに、図５のシステム内のコンポーネントはどのように作動できるかを示すフローチャートである。
【図７】サーバおよび／またはクライアント内で一般に利用される主なハードウェアコンポーネントを示すブロック図である。
【符号の説明】
【００６２】
１０２…インターネットラジオサーバ、１０４…クライアント、１０６…インターネット、１０８…ラジオ局ストリーム、１１０…メタデータ、１１２…メディアペイロードデータ、１１４…残留時間、１１６…総時間、１１８…接続設定、１２０…データストリーム受信、１２２…メタデータタイミング、１２４…残留時間識別、１２６…総時間識別、１２８…接続終了。
【図１】
2006228211.tif 000003
【図２】
2006228211.tif 000004
【図３】
2006228211.tif 000005
【図４】
2006228211.tif 000006
【図５】
2006228211.tif 000007
【図６】
2006228211.tif 000008
【図７】
2006228211.tif 000009