(57)【特許請求の範囲】
【請求項１】
放送マルチメディア・プログラム・コンテンツおよび広告を処理して、マルチメディア・データ・コンテンツとユーザをターゲットとした広告とを有する複合プログラム・データストリームを、前記放送マルチメディア・プログラム・コンテンツおよび広告のターゲットとされる放送受信エリア外の複数の個々のユーザに提供するシステムであって、
複数の放送ソースを検証する条件アクセス・プロセッサであって、前記複数の放送ソースは放送マルチメディア・プログラム・コンテンツを前記システムに並行して提供し、前記放送マルチメディア・プログラム・コンテンツは、（ａ）ストリーム化されたオーディオ・データ、（ｂ）ストリーム化されたビデオ・データ、（ｃ）音声表現データ、（ｄ）ボイスメール・データ、（ｅ）ラジオ放送またはビデオ放送、のうちの少なくとも一つを含む、条件アクセス・プロセッサと、
指定された広告を選択された放送マルチメディア・プログラム・コンテンツの中に挿入する時刻を、前記放送ソースによって前記放送マルチメディア・プログラム・コンテンツの中に挿入された広告に対応する前記放送ソースからのスケジュール・データに基づいてスケジュールするスケジューラであって、複数のソースから広告を受信して、事前にキャッシュし、スケジュールされた挿入時刻で、前記選択されたマルチメディア・プログラム・コンテンツ内への挿入用の前記指定される広告の選択用の候補広告を提供するスケジューラと、
前記放送ソースによって前記放送マルチメディア・プログラム・コンテンツの中に挿入された前記広告を置き換えるスケジュールされた挿入時刻で、指定された広告を選択されたマルチメディア・プログラム・コンテンツの中に挿入して、複合プログラム・データストリームを形成すること、および前記複合プログラム・データストリームを前記複数のユーザのうちの対応するユーザに結合すること、を複数のユーザについて並列で実施することにより、複数のユーザに、個々のユーザに合わせた複合プログラム・データストリームを提供するマルチプレクサと
を備えることを特徴とするシステム。
【請求項２】
前記スケジューラは、（ａ）前記選択された放送マルチメディア・プログラムの放送ソースによって提供されたスケジューリング情報、（ｂ）前記指定された広告のソースによって提供されたスケジューリング情報、のうちの少なくとも１つに基づいて、前記指定された広告の前記マルチメディア・プログラム・コンテンツへの挿入をスケジュールすることを特徴とする請求項１に記載のシステム。
【請求項３】
前記スケジューリング情報は、複数の放送マルチメディア・プログラムを包括する広告スケジューリング情報を含むことを特徴とする請求項２に記載のシステム。
【請求項４】
放送ソースによって提供された前記スケジューリング情報は、（ａ）前記放送マルチメディア・プログラムへの広告挿入に使用可能なタイム・スロットを指示する情報と、（ｂ）広告挿入タイム・スロットを指示するマーカであって、前記選択された放送マルチメディア・プログラム内のマーカと、（ｃ）広告挿入タイム・スロットを識別するための、タイム・スタンプ表示からの情報、のうちの少なくとも１つを含むことを特徴とする請求項２に記載のシステム。
【請求項５】
前記マルチプレクサは、前記複合プログラム・データストリームからなる格納されたデータをマッピングすることによって、前記複合プログラム・データストリームをリピートし、複数のユーザへの結合用の前記複合プログラム・データストリームの複数の格納されたコピーを提供し、前記複合プログラム・データストリームの放送についてスケーラブルな拡張を可能にすることを特徴とする請求項１に記載のシステム。
【請求項６】
前記マルチプレクサは、ユーザ接続を追跡し、（ａ）ユーザの好むプログラム・ソース、（ｂ）広告放送の数、（ｃ）前記複合プログラム・データストリームを受信しているユーザの数、（ｄ）特定の複合プログラム・データストリームへのユーザ接続の長さ、のうちの少なくとも１つを含むユーザ接続に関連する統計のデータベースを維持することを特徴とする請求項１に記載のシステム。
【請求項７】
前記マルチプレクサは、前記スケジュールされた挿入時刻で、タイム・スロットに適切な持続時間の複数の使用可能な広告から一つの広告を選択することにより、コマンドに応答して、前記複合プログラム・データストリームの放送中にユーザをターゲットとした広告を動的に再割り当てすることを特徴とする請求項１に記載のシステム。
【請求項８】
非ローカル・ソースの広告に優先して、ローカル・ソースの広告が前記タイム・スロット用に選択されることを特徴とする請求項７に記載のシステム。
【請求項９】
前記複合プログラム・データストリームを解析して、誤りを検出する誤りプロセッサであって、検出した誤りにより生じる結果を軽減する誤り隠蔽機能を有する、誤りプロセッサをさらに備えることを特徴とする請求項８に記載のシステム。
【請求項１０】
ユーザ・プロファイル・データベース内の以前にコンパイルしたユーザ・プリファレンス・データに基づいて個々のユーザに配信するため、複数の使用可能な異なる広告の１つを割り当てるユーザ・プロファイル・データベースと、
前のユーザ・プログラム選択履歴に基づいて前記ユーザ・プロファイル・データベース内で使用されるユーザ・プリファレンス情報をコンパイルするデータ取得プロセッサとをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項１１】
前記条件付きアクセス・プロセッサは、前記放送ソースによって送信された放送者ＩＤの受信に応答して、放送ソースを認証して放送マルチメディア・プログラム・コンテンツを提供することを特徴とする請求項１に記載のシステム。
【請求項１２】
前記条件付きアクセス・プロセッサは、（ａ）暗号化した放送マルチメディア・プログラム・コンテンツ、および（ｂ）暗号化した認証コードまたはパスワード、のうちの少なくとも１つを解読する解読機能を含むことを特徴とする請求項１に記載のシステム。
【請求項１３】
前記条件付きアクセス・プロセッサは、現在の放送時刻を検証する検証ルーチンに基づいて、プログラム・データストリームを解読することによって前記放送ソースが前記マルチメディア・データ・コンテンツを前記複数のユーザに放送することを可能にすること、および、前記プログラム・データストリームが前記複数のユーザに放送されること防止すること、の１つを処理することを特徴とする請求項１１に記載のシステム。
【発明の詳細な説明】
【０００１】
本出願は、２０００年５月２６日出願の米国仮特許出願第６０／２０７，３８５号、「Ｉｎｔｅｒｎｅｔ  Ｒａｄｉｏ  Ａｄ  Ｉｎｓｅｒｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ」の特典を主張するものである。
【０００２】
（発明の分野）
本発明は、インターネットを介する放送コンテンツの送信に関し、より詳細には、聴取者をターゲットとした広告（advertisement）の挿入を含むインターネットを介した放送コンテンツの送信のためのアーキテクチャに関する。
【０００３】
（発明の背景）
ＡＭ／ＦＭ周波数を介する標準的なラジオ放送の場合、ターゲットとなる聴取者は、本質的にプログラム（program）形式とラジオ局の地理的カバレージ（coverage  視聴圏）によって決定される。ラジオ放送者は、通常、サード・パーティ組織によって集められた統計的サンプリング技術を使用することによって、聴取者ベースの数とデモグラフィクス（demographics）を決定する。これらの統計は、アービトロン格付け（Arbitron rating）と呼ばれている。これらの格付けは、ラジオ局が広告料金を設定する際に極めて重要であり、また広告主がどこでどのように広告を出すかを決定するための主要な意思決定ツールである。
【０００４】
しかし、広告主は、聴取者が広告メッセージに動かされて行動を起こす機会を増加させるために、高い達成目標のターゲット聴取者に向けて自社のメッセージを発信することを好む。アービトロン格付けシステムを使用しても、広告主が、自社のキャンペーンの効果を判断することが非常に困難である。これは、広告主および／またはラジオ局が、単に何人の、そしてどのような人々が広告メッセージを聴くのかを極めて正確に決定することができないためである。
【０００５】
現在、いくつかのラジオ局は、自局のウェブ・サイトから直接、またはヤフー（Yahoo）（商標）その他のサード・パーティのプロバイダなどの媒介者を通じて、インターネット（すなわち、インターネット・ラジオ）を介して、その局のプログラミング（programinng  番組編成）を同時放送している。インターネット媒体は、聴取者に関する情報を放送者に返す固有の機能を有しているが、現在までのところ、インターネット媒体をこの方式で利用した実施態様はない。
【０００６】
放送者とその広告クライアントが、インターネットを放送媒体として使用する場合の利点は、仕事中の人々で、そうでなければラジオを聴いていない人々のような、ラジオではなくコンピュータの前にいる人々、にプログラミングを届けることができることである。またインターネット媒体は、特定の従来の電波放送信号の範囲外にいる人々が、放送プログラミングを聴くことができるようにする。
【０００７】
インターネットを配信手段として使用する場合の現時点の欠点は、広告コンテンツが聴取者にとって状況を全く無視している可能性があることである。このことは、聴取者が電波（すなわち、ＡＭ／ＦＭ）放送信号の範囲外にいるときに起きる。たとえば、ヒューストンのラジオ局のプログラムのインターネット放送を聴いているニューヨークにいる人は、恐らく、放送者のヒューストンの地域に的を絞った広告には関心を示さないであろう。したがって、インターネットを介して聴取者層を増加させることの価値（value）は、ＡＭ／ＦＭ放送の範囲内で聴取者層を増加させるのと同じ経済的な利点を、有さない。
【０００８】
上述の論議は、インターネットを介して、同時に、あるいはそうでなく、提供される、あらゆるタイプの元々の放送マルチメディアのプログラムにも適用可能である。
【０００９】
したがって、特定の聴取者に対する広告を含むインターネット・マルチメディア・コンテンツを提供することが必要とされている。
【００１０】
ならびに、複数の聴取者にインターネット・マルチメディア・コンテンツを同時に提供することが必要とされている。
【００１１】
さらに、複数の聴取者に、インターネットを介してマルチメディア・コンテンツを複数の局に同時に提案し提供することが必要とされている。
【００１２】
（発明の概要）
本発明は、放送マルチメディア・コンテンツおよびターゲット広告を処理し、かつ／または、複数の異なるユーザにネットワークを介して提供するためのシステムである。
【００１３】
本発明は、同じ放送プログラムを聴いているかつ／または見ている個々の人々が、他と異なる広告を聞くことができるように、選ばれた聴取者に広告を接続する機能を提供する。また本発明により、何人の聴取者が自局のチャネルに合わせているかを正確に決定することができ、入手可能な情報に基づいて聴取者のデモグラフィクスを確認することもできる。この情報は広告主およびラジオ放送者に、これに基づいて、彼等の事業や製品の提供に対する手がかりがあると意志決定する、非常に多くの情報ベースを提供することができる。
【００１４】
本発明は、内部ディスク記憶装置を備えていない再生装置（ラジオ、携帯電話など）に、特によく適している。しかし、本発明は、パーソナル・コンピュータ（コンピュータ）やディスク操作可能な再生システムを有する装置とともに機能することもできる。
【００１５】
以下の本発明の説明については、添付図面と合わせて参照されたい。
【００１６】
これらの図を通じ、対応する参照符号は、対応する部分を示す。
【００１７】
（発明の詳細な説明）
図１を参照すると、ラジオ放送局網の実施態様、より詳細には、本明細書に記述した原理によるラジオ放送局のインターネット・ラジオの実施態様を、全体を１０で表したブロック図が示してある。したがって、図に示し本明細書に記述したラジオ放送局網の実施態様は、放送マルチメディア・システムまたは設備の代表例にすぎないことをまず最初に理解されたい。したがって、放送ラジオ（オーディオ・コンテンツ、データ、またはプログラミング）について本明細書に記述した原理は、他の放送マルチメディアにも適用される。他の放送マルチメディアには、ストリーム化オーディオ・データ、ストリーム化ビデオ・データ、音声表現データ、ボイスメール・データ、ビデオ放送が含まれるが、これらに限定されるものではない。
【００１８】
ラジオ局１２が、アナログ・プログラミングまたはコンテンツ１４を制作または生成する。アナログ・コンテンツ１４は、オーディオ・アナログ・フォーマットであり、当技術分野で周知のＡＭまたはＦＭフォーマットで、電波（すなわち、地上波放送）を介して放送または送信される。ラジオ局１２は、そのコンテンツをディジタル・フォームで放送できるが、通常はアナログ・フォームである。ラジオ局のアナログ・コンテンツ１４の地上波放送は、当技術分野で周知のように、放送受信エリア内の標準的なラジオ受信者によって受信される。ラジオ局のアナログ・オーディオ・コンテンツ（以後、「ラジオ・コンテンツ」と呼ぶ）１４には、広告を割り込ませたプログラミング（すなわち、音楽と語り）が含まれる。広告のコンテンツは、放送受信エリア内にいる聴取者をターゲットとしている。
【００１９】
ラジオ放送を実施しているラジオ局と同様に、テレビジョン局も、ビデオおよびオーディオのプログラミングまたはコンテンツ（すなわち、テレビジョン・コンテンツ）を制作または生成する。コンテンツは、アナログおよび／またはディジタル・フォーマットであり、当技術分野で周知のフォーマットで、電波（すなわち、地上波放送）を介して放送される。テレビジョン・コンテンツのこのような地上波放送は、当技術分野で周知のように、放送受信エリア内にいるテレビ受信者によって受信される。テレビジョン局のテレビジョン・コンテンツには、広告を割り込ませたプログラミング（すなわち、ビデオとオーディオ）が含まれる。広告のコンテンツは、放送受信エリア内にいる聴取者をターゲットとしている。他のフォームのマルチメディア・コンテンツを、同じ方式で放送することもできる。
【００２０】
ラジオ局のアナログ・コンテンツ１４の電波放送に加えて、ラジオ局１２は、ネットワーク２２を介してラジオ・コンテンツ１４を提供することができる。ネットワーク２２は、通常、電子ネットワークであり、より詳細には、通常、インターネットである。しかし、本発明は、どのようなタイプのネットワークまたはネットワーク・システムにも適用可能であることを理解されたい。ネットワーク２２を介して伝播するためにラジオ・コンテンツ１４を作成する際に、ラジオ・コンテンツ１４は、モジュール１６で示すように、適切にフォーマットされている。これは、ウェブキャスト（WebCast）（商標）ソフトウェアなどのソフトウェアを介して遂行される。ラジオ・コンテンツ１４のフォーマッティング１６には、ネットワーク２２にまたネットワーク２２を介して送信するため、アナログ信号をディジタル信号に変換することが含まれる。
【００２１】
ラジオ局１２はまた、ラジオ・コンテンツ用の、広告のスケジュールであるモジュール２０を提供しなければならない。これは、スケジューリング・ソフトウェアを広告することによって遂行される。広告スケジューリング・ソフトウェアは、ネットワーク２２を介しての更なる伝播（dissemination）に備えて広告タイミング・スケジュール（広告マッピング・データ）を提供するのに加え、アナログ信号をフォーマッティングするスケジューリング情報またはデータを提供する。スケジューリング情報は、いつ広告を挿入すべきかを示すためフォーマットされたアナログ信号内に含まれるかまたはフォーマットされたアナログ信号内にフォーマットされるマーカまたはデータに変換される。広告マッピング・データは、広告のための時間長（継続時間）、タイミング・スケジューリングなどに関する情報を提供する。生放送と、ネットワーク２２を介する伝播期間のアナログ信号のフォーマッティング／送信との間に遅延が起きるため、リアル・タイムの調整１８も、必要ならば、アナログ信号のフォーマッティング１６に提供される。
【００２２】
ラジオ・コンテンツ１４のフォーマッティング１６後に、現在のディジタル・ラジオ・コンテンツが、ネットワーク２２に提供される。ラジオ局１２は、自局の電波放送ラジオ・コンテンツをネットワーク２２に提供する複数のラジオ局の１つの典型であることをさらに理解されたい。関連するすべてのラジオ局１２からのディジタル・ラジオ・コンテンツと広告スケジューリング・データが、ネットワーク２２と通信しているネットワーク・サーバ２４によって収集される。ネットワーク・サーバ２４は、多くの聴取者にネットワーク２２を介しての伝播に備えて、ラジオ・コンテンツと広告スケジューリング・データを集約する（aggregate）。したがって、ネットワーク・サーバ２４は、ネットワーク２２にアクセスでき、そして適切なソフトウェアを有するどの人に対しても、あらゆる場所に位置するさまざまなラジオ局のラジオ・コンテンツのプロバイダとなる。
【００２３】
ユーザすなわち聴取者２６が、（モデム付きのパーソナル・コンピュータのブラウザを介するなど）適切な手段を介してネットワーク２２にアクセスし、ネットワーク・サーバ２４と交信し、接続する。聴取者２６は、サーバ２４によって提示された複数のラジオ局から、ラジオ局／オーディオ放送を選択する。次いで、ネットワーク・サーバ２４は、聴取者２６に、選択されたラジオ局のオーディオ放送をリアル・タイムでネットワーク２２を介して提供する。聴取者２６のネットワーク使用可能な装置はまた、ネットワーク・サーバ２４からオーディオ放送のオーディオ・フォーマットを再生する（復号する）ための適切なソフトウェアを備える。
【００２４】
本発明の一態様によれば、ネットワーク・サーバ２４からのオーディオ放送には、特定の聴取者をターゲットとした広告が含まれる。そのターゲット広告は、ラジオ局のオリジナルの放送中のその広告の代りにまたはその広告がある場所に、挿入される。したがって、ラジオ局のオリジナルの場所の、聴取者をターゲットとした広告を聞く代りに、聴取者２６は、特定の聴取者に特定した、またはそれをターゲットとした、広告を聞くこととなる。ラジオ局１２の広告スケジューリング・ソフトウェア２０からの広告タイミング・スケジュールと、フォーマットされたラジオ・コンテンツ中にコード化されたタイミング情報は、ネットワーク・サーバ２４が、ターゲット広告をネットワーク・サーバ２４のオーディオ放送内に正確に配置することを可能にする。ターゲット広告は、サーバ２４に基づいて得られる。ターゲット広告を提供できるようにするために、聴取者に関するデモグラフィクス情報を取得して、そのデモグラフィクス情報をオーディオ送信の適切な時間中に参照することが必要となる。同様に、本発明の一態様によれば、ネットワーク・サーバ２４は、複数の聴取者の各人にネットワーク・サーバ２４によって伝えられる複数のラジオ局のいずれかを提供し、それぞれの聴取者に対して放送されるそれぞれのラジオ局内のターゲット広告も提供するように動作可能である。これらのラジオ・プログラム・ストリームは、それぞれのユーザに途切れなく提供される。
【００２５】
次に図２を参照すると、本発明のより詳細な実施形態が、全体を３０で表して示してある。システム３０は、複数のマルチメディア・フィード（feeds）、コンテンツ、プログラミング、ビットストリームなどのいずれかを、複数の聴取者またはユーザ３２のいずれかに提供するように動作可能である。しかし、システム３０は、特に別段の記載をしない限り、ただ１人のユーザ３２に関してのみ記述する。具体的に表示しなくとも、ユーザ３２は、インターネット３４に接続し通信することを可能にするように動作可能な、インターネット（ネットワーク）使用可能装置を有し使用することを理解されたい。上記に関連し、用語インターネットは、どのようなネットワーク・システムも包含することを理解されたい。したがって、インターネット使用可能装置は、システム３０がそこで使用されるタイプのネットワークに適合した装置である。以下、この用語インターネットは、特に別段の記載をしない限り、このようなあらゆるネットワークを指すものとする。インターネット使用可能装置は、インターネットにアクセスまたは接続し、そしてインターネットと通信するさまざまなサーバと交信しインターフェイスする、適切な処理、メモリ、記憶装置、論理あるいは回路などを有する、パーソナル・コンピュータ、ＤＳＳシステムなどの代表的なコンピュータ（以下、総称して「コンピュータ」と呼ぶ）であってよい。インターネット使用可能装置にはさらに、ブラウザ・プログラムなどの適切なソフトウェアが含まれる。ブラウザ・プログラムに加えて、インターネット使用可能装置には、当技術分野で周知のオーディオ（ラジオ局）放送を受信し、復号し、再生するための、適切なソフトウェアまたは他の手段が含まれる。
【００２６】
ユーザ３２は、インターネット３４にアクセスし、その後、ラジオ局プロバイダのウェブ・サーバ３６（以下「ウェブ・サーバ３６」と呼ぶ）に接続する。ユーザ３２は、ウェブ・サーバ３６と情報をやり取りし、好ましくは、ユーザ３２に関するデモグラフィクスの収集を含む加入アカウントをセットアップする。したがって、ウェブ・サーバ３６は、ユーザ３２からデモグラフィクス情報／データを得るための適切なソフトウェアを有する。好ましくは、次いで、このようなユーザ・デモグラフィクスが、永久格納するために、ユーザのインターネット使用可能装置に格納され、次いで、ユーザ３２がウェブ・サーバ３６に接続している時、ウェブ・サーバ３６に関連付けられたデモグラフィクス・データベース（記憶装置）３８内にキャッシュされる。しかし、加入アカウントは、本発明の運用に必要なものではないが、ユーザ３２に、これにより、さらなる利点が与えることができる。
【００２７】
本発明の一態様によれば、ウェブ（インターネット）エージェント・プログラムが、ユーザ３２のインターネット使用可能装置にインストールされる。ウェブ・エージェント・プログラムは、ウェブ・サーバ３６または他のサーバからダウンロードするか、またはユーザ３２にインターネット使用可能装置にインストールするディスクを提供することができる。ウェブ・エージェント・プログラムは、ユーザ３２がウェブ・サーバ３６からのラジオ放送を聴いていない時に、ユーザ３６がアクセスするウェブ・サイトを追跡するようにさせることも可能である。ウェブ・サイト情報は、ユーザのデモグラフィクスを補足またはユーザのデモグラフィクスに取り込むために使用される。ウェブ・エージェントを受け入れることができないインターネット使用可能装置または格納機能を有さないインターネット使用可能装置でも、ウェブ・サーバ３６に接続してラジオ放送を聴くことができる。このような場合、ユーザ・デモグラフィクスは、ウェブ・サーバ３６において、デモグラフィクス・データベース３８などに格納される。
【００２８】
ユーザ３２がウェブ・サーバ３６に接続して、特定のラジオ局／放送を選択しチャネルを合わせると、次いで、ユーザ３２は、ＩＰソケット接続を介しインターネット３４を通じてマルチプレクサ４０に、あるいはマルチプレクサ４０からのパイプラインに接続される。マルチプレクサ４０は、ウェブ・サーバ３６または他のウェブ・サーバに関連付けられ、ラジオ・プログラム・コンテンツを、選択されたラジオ局からユーザ３２に転送する。ラジオ・プログラム・コンテンツ内の広告データ・マーカが、広告を挿入すべき時間が来ていることを示すと、マルチプレクサ４０は、広告チャネルを選択するか、またはユーザ３２のデモグラフィクス・プロファイルに基づいて広告ステージング（演出  staging）モジュール４８から複数の広告送り（ad feed）５４を取り出す。そしてマルチプレクサ４０は、入力ソース（すなわち、ラジオ・プログラム・コンテンツ）を適切な広告チャネルに接続する。
【００２９】
概ね、広告データ・マーカは、ラジオ局１２（すなわち、放送ソース）または広告ソースのいずれかによって挿入され、図１を参照して上述したように、広告データ・マーカは、ある広告がプログラム・コンテンツの中に何時挿入されるようにスケジュールされているかを示す。これは、通常、放送プログラム・コンテンツのための広告スケジュールと一致する。図１を参照して上述したように、広告データは、ローダ４６によって別個に受信され、プログラム・アグリゲータ（集積器  aggregator）４２によってプログラム・コンテンツに添えられる。
【００３０】
マルチプレクサ４０は、ユーザ接続を追跡し、それに関連付けられている広告追跡データベース内に統計を保存するように動作可能である。この統計には、何人のユーザが特定の広告を聞くか、などのさまざまな情報を含むことができる。この統計情報は、ウェブ・ポータルを通じて、動的に放送業者に使用可能にされ、放送者とそのクライアントが広告のパフォーマンスを対話式に分析するための助けとなる。聴取者ベースの対話式および時間分類した分析は、放送者および広告主の両方にとって非常に貴重なものである。たとえば、聴取者のタイプに関するプログラミング・スケジュールの想定があまり最適とは言えないような場合に、システムは、スケジュールおよび広告コンテンツの再構成を動的にサポートする。聴取者の傾向の継続的な分析は、放送者が自局のプログラミング・コンテンツを自局の聴取者に合わせるよう微調整することを可能にし、同様に広告主が自社のメッセージを調整することを可能にする。したがって、システム３０は、取得した統計に応じてユーザ３２をターゲットとした広告の動的な再割り当てを実施することが可能である。
【００３１】
このように広告が特定のユーザ３２にカストマイズされることが、本発明の一利点である。本発明が、ユーザ３２に対するデータ（ラジオ・プログラム・コンテンツおよび広告）のストリームの連続性を低下することなく、多数の接続したユーザをサポートすることが重要であることを理解されたい。そうでなければ、音（sound）は、途切れ途切れになり、壊れたものになる。このような場合には、聴取者の注意がそがれたり、あるいは完全に聴取者が関心をなくすことにもなりかねない。したがって、マルチプレクサ４０との効率的な相互接続をサポートするために、プログラム・データをステージ（stage）すること、聴取者のデモグラフィクスをキャッシュする（caching）こと、広告ストリームを準備することが、本発明の重要な特徴である。広告は、ローカル的または非ローカル的にソース（source 提供）することができる。非ローカル的にソースされる広告より、ローカル的にソースされる広告の方が好ましい。さらに、デモグラフィクス３８用のユーザ・プロファイル・データベースは、好ましくは、マルチプレクサ４０によって取得された統計とともに、あらかじめコンパイルしたユーザ・プリファレンス・データ（ユーザの好みのデータ）に基づいて、ユーザ３２への配信に対して個々の広告を割り当てることに、使用可能である。同様に、ユーザ・プログラム選択履歴に基づく前のプリファレンス・データも使用することができる。
【００３２】
図２において局１、局２、局３で示したさまざまなラジオ局（プログラム・コンテンツ）は、プログラム・アグリゲータ４２によって受信される。局１−３は、インターネット３４を介して伝播する自局のプログラミング・コンテンツを転送する複数のラジオ局を表わしている。プログラム・アグリゲータ４２は、ウェブ・サーバ３６、マルチプレクサ４０に関連付けられた別のウェブ・サーバ、またはさらに別のウェブ・サーバに関連付けられている。さらに、図１を参照して上述したように、さまざまなラジオ局からのプログラミング・コンテンツは、局１−３で表した線で示すように、通常、インターネット３４を介してプログラム・アグリゲータ４２に提供される。プログラミング・コンテンツは他の手段によってもプログラム・アグリゲータに提供できるため、このことは、簡単化した図２には明確に示していない。
【００３３】
プログラミング・コンテンツを提供するそれぞれの局からのプログラミング・コンテンツ用の、広告スケジューリングに関しての、データが、局１−３で表した線で示すように、ローダ４６に提供される。広告スケジュール・データは、ラジオ・コンテンツの放送ソース（たとえば、ラジオ局１２）から、または指定された広告のソース（すなわち、ラジオ・コンテンツ・ビットストリームの中に挿入するため選択されたターゲット広告）を経由して受信される。スケジューリング・データは、多くのラジオ局コンテンツとマルチメディア・タイプとをカバーできる。さらに、スケジューリング・データには、好ましくは、少なくとも以下の情報が含まれる。すなわち、放送プログラムの中への広告挿入用に使用可能なタイム・スロットを示す情報、広告挿入タイム・スロットを指示する選択された放送プログラムの中のマーカ、広告挿入タイム・スロットを識別する情報でタイム・スタンプ指標に基づく情報、である。他のスケジューリング・データも提供することができる。このような広告スケジュール・データには、いつ広告がプログラム・コンテンツ（タイミング）内にスケジュールされるか、広告のための時間の長さ、およびその他の関連広告データ、に関する情報が含まれる。広告データは、プログラム・アグリゲータ４２と通信するスケジュール・データベース４４（スケジューラ）に転送される。次いで、プログラム・アグリゲータ４２は、マルチプレクサ４０に転送される、マークを付けたプログラム・コンテンツを生成する。マークを付けたプログラム・コンテンツには、広告データとともにラジオ局からのプログラム・コンテンツが含まれ、これは、マルチプレクサ４０が、いつ広告を挿入する必要があるかを決定することを可能にする。
【００３４】
ユーザ３２に提供されるプログラム・コンテンツ／データストリームの中に広告を挿入すべきであると判断すると、マルチプレクサ４０は、デモグラフィクス・データベース３８、ユーザ３２のコンピュータ、またはそれらの組合せの中のデモグラフィクス情報に従って複数の広告送り５４の１つを介して広告コンテンツを選択する。それぞれの広告送り５４は、広告ステージング・モジュール４８にその源を発している。広告ステージング・モジュール４８は、広告を収集し、広告送りライン５４を介してマルチプレクサ４０に送信する。広告の収集は、インターネット３４を介して得ることができ、インターネット３４において、広告は、インターネット３４と通信している広告サーバ５０に格納することができるる。テープを介するなどの、広告を広告ステージング・モジュール４８に提供する他の手段が、使用可能である。したがって、広告ステージング・モジュール４８は、インターネット３４を介して、または広告サーバ５０からリアル・タイムでなどの、あらゆる方式で得られるさまざまな広告を格納することができる。したがって、広告ステージング・モジュール４８は、複数の広告をマルチプレクサ４０に提供して、適切なプログラム・コンテンツへのターゲット広告の配置をサポートするように動作可能である。
【００３５】
したがって、マルチプレクサ４０は、適切なラジオ局／プログラム・コンテンツをユーザに転送し、そして、マークを付けたプログラム・ライン５６の１つを介してプログラム・アグリゲータ４２から受信されたプログラム・コンテンツの中のデータ・マーカが広告を挿入する時間であることを示すと、マルチプレクサ４０は、ユーザ３２のデモグラフィクス・プロファイルに基づいて広告送り５４を選択し、ユーザの入力ソースを適切な広告送りに接続する。本発明は、パイプラインが同じプログラム・コンテンツを含むかどうかにかかわらず、ターゲット広告の挿入を可能とするプログラム・コンテンツのそれぞれのパイプラインを備えたマルチプレクサ４０に専ら接続する複数のユーザをサポートするので、マルチプレクサ４０が、プログラム・コンテンツの複数のパイプラインと、それぞれのパイプラインの中へターゲット広告を挿入することをサポートすることが必要である。本発明の一態様によれば、プログラム・アグリゲータ４２、スケジュール・ローダ４６、広告ステージャ４８、マルチプレクサ４０が、すべて連携して、それぞれのユーザ３２に個別の聴取経験を提供する。これらのセクションまたはモジュールのそれぞれについて、以下にさらに記述する。
【００３６】
プログラム・アグリゲータ４２は、好ましくは、それぞれのラジオ放送者システムとの接続を提供する、要するに、それぞれのラジオ放送システムから各ラジオ放送プログラムを受信する、マルチスレッド・ソフトウェア・プログラムである。それぞれのラジオ放送プログラムは、ほぼリアル・タイムでプログラム・アグリゲータ４２に提供されることを理解されたい。
【００３７】
プログラム・アグリゲータ４２は、ログイン・スレッド、制御スレッド、読取りスレッドとして実施され、条件アクセス・プロセッサと考えることができる。ログイン・スレッドは、ラジオ放送者からプログラム・アグリゲータ４２への接続を提供する。好ましくは、安全ななＩＰリンク（secure IP link）を介して接続がなされる。ログイン・スレッドは、放送者からの要求を聴く。接続がなされると、ログイン・スレッドは、ログイン要求レコードを受信すること予想する。ログイン要求レコードは、実際にクライアント接続要求が許可を得たラジオ局であることを確認するため分析される。ラジオ放送者からプログラム・アグリゲータ４２へのＩＰリンクが確実なものであり、無線侵害（radio piracy）を回避するため暗号化されていることが好ましい。ログインが成功すると、ログイン・スレッドは、読取りスレッド、書込みスレッド、制御スレッドを開始し、それらに、接続されている放送者の識別（ＩＤ）を知らせる。
【００３８】
図４は、プログラム・コンテンツに関して、ラジオ放送者によってプログラム・アグリゲータ４２に送信されるログイン・コマンドの一実施形態を示す、全体を６０で表したテーブルである。テーブル６０の列６２には、ログイン・コマンド項目が列挙されている。テーブル６０の列６４には、ログイン・コマンド項目列６２からの対応するログイン・コマンド項目のためのログイン・コマンド・ビット長が列挙されている。テーブル６０の列６６には、ログイン・コマンド項目列６２からの対応するログイン項目のためのログイン値を列挙されている。テーブル６０の列６８が、ログイン・コマンド項目列６２からの対応する項目のための注記を表している。テーブル６０の行７０が、ラジオ放送者によって送信され、ビット長４および値ＬＯＧＮの、プログラム・アグリゲータ４２によって受信される項目「マーカ」を示し、この項目「マーカ」は、ログイン要求の開始をマーク付ける。テーブル６０の行７２は、ラジオ放送者によって送信され、ビット長５の、プログラム・アグリゲータ４２によって受信された項目「放送者ＩＤ」を示し、この項目「放送者ＩＤ」は、特定のラジオ局の呼出し符号識別を呈示する。テーブル６０の行７４は、ラジオ局によって送信され、ビット長３２の、暗号化ルーチンに従って暗号化され、プログラム・アグリゲータ４２によって受信される項目「バリデーション（validation）」を示し、この項目「バリデーション」は、現在の日時、放送者ＩＤ、放送者のパスワードに対して有効となるよう復号しなければならないプログラム・アグリゲータ４２に対して暗号化した値を呈示する。最後に、テーブル６０の行７６は、ラジオ放送者によって送信され、ビット長４で、ＥＬＯＧの値を有し、プログラム・アグリゲータ４２によって受信される項目「マーカ」を示し、この項目「マーカ」は、ラジオ放送の受信を停止する。
【００３９】
プログラム・アグリゲータ４２の制御スレッド部またはモジュールは、スケジュール・データベース４４を読取り、広告挿入が放送プログラムの中に行われるべきである時刻を決定する。次の広告サイクル用の広告をステージするための要求が、広告ステージング・モジュールまたはプログラム４８に送信される。この要求は、必要とされるスケジュールからそれぞれの広告を識別するレコードからなる。広告ステージング・プログラム／モジュール４８は、広告コンテンツを読み取るために使用可能な１組の接続ポート（広告送り）に応答する。次いで、ポートは、広告を開始する時刻になった時に、ユーザ３２を広告タイプに関連付けるコア・インテリジェンスが確立されるように、制御スレッドによってデモグラフィクス・タイプに関連を持たせられる。
【００４０】
制御スレッドの特徴は、制御スレッドにより、すべてのリソースが分類されて、広告を流すことが想定／スケジュールされている時刻に使用できるよう準備されることである。広告を見つけること、広告をメモリ内へステージすること、接続リソースを割り当てることについてのタイミング待ち時間は、ユーザ３２への音楽データ（すなわち、プログラム・コンテンツ）の安定した流れを中断することなく、必要となる時間に遅れることはできない。制御スレッドは、特定のユーザ３２用の広告コンテンツを選択するためマルチプレクサ４０によって使用される広告ステージャ・ポート（広告送り）へのデモグラフィクス・広告のマッピングを含むバッファを準備する。このバッファは、読み取りスレッドに送信されて、開始時間に達した時に、この読み取りスレッドはバッファ・ストリームに向けられたマルチプレクサの中に配置される。
【００４１】
読取りスレッドは、データストリームをラジオ放送者から受信し、有効な符号化（ＭＰ３などの）フレームをデータから選択し、有効なフレームをメモリ待ち行列の中に入れ、次いで、マルチプレクサ４０にルーティングする。符号化フレームのそれぞれのバッファは、タイム・スタンプされて、放送者からの受信をマーク付けする。読取りスレッドは、メモリ内で受信したデータをステージし、ユーザ３２に対するデータのスムーズな流れを確実にする。同様に、符号化フレームは、整合性を確認するため分析される。どの不良フレームも、音の劣化、これは通常破損したデータが原因である、を回避するため除去される。読取りスレッドはまた、デモグラフィクス広告／ポート・マッピングを含むメッセージ・バッファを読取り、マルチプレクサ拘束メモリ待ち行列の中にこのメッセージ・バッファを挿入するのに適切な時間を決定する。マルチプレクサ４０によるメッセージ・バッファの受信は、放送データの代りに広告コンテンツに切り換えるための信号である。
【００４２】
プログラム・スケジュール・ローダ４６は、プログラム・スケジュール・データを、ラジオ放送者から安全なＩＰリンク接続を介して、受信する。スケジュール・ローダ・プログラムは、特定の放送者用に指定されている特定のポートｉｄ上のソケット／パイプライン（ＴＣＰ／ＩＰソケットのような）を開放する。スケジュール・ローダ・プログラムは連続して動作し、要求が到着すると、その要求をサービスする。ラジオ放送者から接続要求を受信すると、ローダ４６は、ラジオ放送者を検証する（validate）ための暗号化されたログイン・プロトコルを使用し、次いで、そのバリデーションが成功した場合、ラジオ放送者からの要求を処理する。その要求は、プログラム・ストリームの中への広告挿入を制御するため使用されるスケジューリング・レコードの、挿入、更新および削除の要求から構成される。要求は処理され、次いで、コマンド・レコードは、運用のステータスと、（コマンドが挿入要求である場合は）レコードの識別子とでマーク付けされる。その後、コマンド・レコードは、ラジオ放送者に戻し送信される。
【００４３】
図５は、広告マッピング・データに関して、ラジオ放送者によってローダ４６に送信されるログイン・コマンドの一実施形態を示す、全体を８０で表したテーブルである。テーブル８０の列８２には、ログイン・コマンド項目が列挙されている。テーブル８０の列８４には、ログイン・コマンド項目列８２からの対応するログイン・コマンド項目のためのログイン・コマンド・ビット長が列挙されている。テーブル８０の列８６には、ログイン・コマンド項目列８２からの対応するログイン項目のためのログイン値が列挙されている。テーブル８０の列８８が、ログイン・コマンド項目列８２からの対応する項目のための注記を表している。テーブル８０の行９０が、ラジオ放送者によって送信され、ビット長４および値ＬＯＧＮの、ローダ４６によって受信された項目「マーカ」を示し、この項目「マーカ」は、ログイン要求の開始をマーク付けする。
【００４４】
テーブル８０の行９２は、ラジオ放送者によって送信され、ビット長５の、ローダ４６によって受信された項目放送者ＩＤを示し、この項目放送者ＩＤは、特定のラジオ局の呼出し符号識別を呈示する。テーブル８０の行９４は、ラジオ局によって送信され、ビット長３２の、暗号化ルーチンに従って暗号化され、ローダ４６によって受信された項目「バリデーション」を示し、この項目「バリデーション」は、現在の日時、放送者ＩＤ、放送者パスワードに対して有効となるよう復号しなければならないローダ４６に暗号化した値を呈示する。最後に、テーブル８０の行９６は、ラジオ放送者によって送信され、ビット長さ４およびＥＬＯＧの値の、ローダ４６によって受信される項目「マーカ」を示し、この項目「マーカ」は、広告マッピング・データの受信を停止する。
【００４５】
図６は、レコード・データに関して、ラジオ放送者によってローダ４６に送信されるレコード維持コマンドの一実施形態を示す、全体を１００で表した、テーブルである。テーブル１００の列１０２には、ログイン・コマンド項目が列挙されている。テーブル１００の列１０４には、ログイン・コマンド項目列１０２からの対応するログイン・コマンド項目のためのログイン・コマンド・ビット長が列挙されている。テーブル１００の列１０６には、ログイン・コマンド項目列１０２からの対応するログイン項目のためのログイン値が列挙されている。テーブル１００の列１０８は、ログイン・コマンド項目列１０２からの対応する項目のための注記を表している。テーブル１００の行１１０は、ラジオ放送者によって送信され、ビット長４およびＤＡＴＡの値の、ローダ４６によって受信された項目「マーカ」を示し、この項目「マーカ」は、新しいコマンドの開始をマーク付けする。テーブル１００の行１１２は、ラジオ放送者によって送信され、ビット長５の、ローダ４６によって受信された項目「放送者ＩＤ」を示し、この項目「放送者ＩＤ」は、特定のラジオ局の呼出し符号識別を呈示する。テーブル１００の行１１４は、ビット長１、値が１、２、または３の、ローダ４６によって受信された項目「コマンド・タイプ」を示し、この項目「コマンド・タイプ」は、レコードを挿入、更新、または削除すべきかどうか示す。テーブル１００の行１１６は、ビット長１０の、ラジオ放送者によって送信され、ローダ４６によって受信された項目「レコードＩＤ」を示し、この項目「レコードＩＤ」は、スケジュール・ローダ・プログラムによって設定されるレコード識別子を示し、挿入コマンド要求の場合に戻される。テーブル１００の行１１８は、ビット長１０の、ＤＡＴＡの値（すなわち、ＭＭ／ＤＤ／ＹＹＹＹ）を有し、ラジオ放送者によって送信され、ローダ４６によって受信された項目「開始日」を示し、この項目「開始日」は、広告挿入の日を提供する。テーブル１００の行１２０は、バイト長さ１１の、ＴＩＭＥの値（すなわち、ＨＨ：ＭＭ：ＳＳ：ＳＳ）を有し、ラジオ放送者によって送信され、ローダ４６によって受信された項目「時間」を示し、この項目「時間」は、広告挿入の時間を提供する。テーブル１００の行１２２は、ビット長２０の、ラジオ放送者によって送信され、ローダ４６によって受信された項目「広告識別子」を示し、この項目「広告識別子」は、広告サーバに配置された広告媒体のためのレコード識別子を提供する。テーブル１００の行１２４は、ビット長１の、１または０の値を有する、ラジオ放送者によって送信され、ローダ４６によって受信された項目「結果」を示し、この項目「結果」は、レコードが合格か不合格かを示す。テーブル１００の行１２６は、ビット長３の、ＤＥＮＤの値を有する、放送者によって送信され、ローダ４６によって受信された項目「マーカ」を示し、この項目「マーカ」は、コマンドの終了を示す。
【００４６】
広告ステージングは、適切なソフトウェア、ハードウェア、またはその両方の組合せを通じて広告ステージング・モジュール４８によって達成される。広告ステージング４８は、後にプログラム・コンテンツの中に挿入するための広告を取得するため、広告サーバ５０に接続する。広告は、広告ステージング４８に関連付けられたメモリの中にキャッシュされる。広告のステージングは、制御スレッドからの要求によって駆動される。制御スレッドは、スケジュール要件を分析し、必要な時間にはその広告が準備されているように、広告ステージング４８に、どの広告が次の放送サイクルに要求されているのかを知らせる。したがって、広告は、予測してステージされる。リアル・タイムで、特にインターネット・サーバから広告の取り出し試みる場合に、著しい遅延が起きる可能性があるため、広告はキャッシュされることが、好ましい。
【００４７】
システム３０には、誤りを検出するため、ユーザ３２に提供される複合データストリーム（すなわち、ラジオ局および広告）を解析するエラー（誤り）プロセッサが含まれる。エラー隠蔽機能（error concealment function）が、検出した誤りから生じる結果を軽減するために使用可能である。
【００４８】
本発明の一態様によれば、マルチプレクサ４０は、ユーザ３２との接続、それぞれのパイプラインまたはＩＰソケット５２に対する放送プログラムと広告のプレゼンテーションとの間の切り換えを管理する（図２参照）。マルチプレクサ４０は、現在のマルチプレクサ・プログラムが動作しているネットワーク内の他のノードに放送をトランスポートするよう構成することができる。すなわち、スケーラビリティを有する。このことは、図３内に表してある。
【００４９】
次に図３を参照すると、本発明のスケーラビリティを例示したブロック図が示してある。マルチプレクサ４０は、適切なソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組合せの中で実施できることを理解されたい。一般に、図３内のそれぞれのボックスが、マルチプレクサ・プログラム内で管理される処理スレッドを示す。以下に記述するように、多くのマルチプレクサ・プログラムは、同じウェブ・サーバ上で走ることができ、また多くのサーバ全体に分配できる。これをどのように構成するかについては、マルチプレクサ・プログラムが走っているウェブ・サーバとオペレーティング・システムの能力に基づいて、最適な判断がなされる。図３では、マルチプレクサ４０は主要マルチプレクサであると考えられ、マルチプレクサ１４０は予備または補足マルチプレクサであると考えられる。主要マルチプレクサ４０は、放送のラベルを付けた線で表したラジオ放送、およびＡｄ１、Ａｄ２、Ａｄ３のラベルを付けた線で表した広告（広告ステージング・モジュール４３の広告送りを介したターゲット広告、図２参照）を受信するコンテンツ（ラジオ放送および広告）マルチプレクサ１５０をサポートするよう構成される。図２の４０のラベルを付けたマルチプレクサは、図３に示し、また以下に記述するマルチプレクサ・アーキテクチャをサポートすることを理解されたい。さらに、図３には、このような予備または補足マルチプレクサ１４０をただ１つしか示していないが、本発明は、多くの予備または補足マルチプレクサ１４０をサポートすることを理解されたい。
【００５０】
接続要求はウェブ・サーバ３６にその源を発するが、これは、放送へのアクセスを望むユーザ３２のための交信ポイント（contact point）である。ウェブ・サーバ３６は、複数の接続マネージャ・ボックスによって表される複数の接続マネージャのアクティブ接続マネージャ１５２に接続することを試みる。アクティブ接続マネージャは、システム負荷に基づいて変化する。アクティブ接続マネージャがいつ変化したかが、ウェブ・サーバ３６に通知される。接続マネージャ１５２は、そのサーバが、別のユーザ３２をサポートするための十分なリソースを有しているかどうかを判断する。接続マネージャ１５２が別のユーザ３２をサポートするための十分なリソースを有している場合は、接続マネージャ１５２は、ＩＰアドレスとポートｉｄをウェブ・サーバに戻し、聴取者放送スレッド１５４（ＬＢＴ）が開始される。ＬＢＴは、ＩＰアドレスとポートｉｄ上で接続が起きるのを待つ。接続が起きると、ＬＢＴは、指定した入力チャネル上で見つけた放送／追加データを流す。入力チャネルは、コンテンツ・マルチプレクサ１５０またはリピータ１５６によって作成されるメモリ待ち行列として実施される。
【００５１】
ローカル・マシンがＬＢＴを開始するための十分なリソースを有さない場合は、次いで、接続マネージャ１５２は、構成内の次のマルチプレクサ（予備または補足マルチプレクサ１４０）に接続要求を渡す。マルチプレクサが要求をサポートできない場合は、ユーザは、アクセスを拒否される。ＬＢＴが開始されると、ウェブ・サーバ３６は、動的Ｊａｖａ（登録商標）アプレット（または同等なコマンド命令）をウェブ・クライアントにダウンロードし、次いで、これが、接続要求から受信されたＩＰアドレスとポートへの接続が利用できるようにする。次いで、Ｊａｖａ（登録商標）アプレットは、ユーザのコンピュータにインストールされているＭＰ３（または他の音楽復号器）プレーヤを開始する。
【００５２】
コンテンツ・マルチプレクサ１５０は、ＭＰ３データソースを選択するためＬＢＴによって使用される待ち行列ポインタを管理する。プログラムの放送中、すべてのＬＢＴが、そのラジオ・プログラムを含む同じ待ち行列を指している。マルチプレクサ４０が広告開始バッファを受信すると、マルチプレクサ４０は、適切な広告ソースからデータを受信するＬＢＴのための入力ポインタをリセットする。次いで、コンテンツ・マルチプレクサ１５０は、１次放送待ち行列ポインタを、（スケジュール毎の）広告開始時間プラス広告の長さに最も近いバッファ上のタイム・スタンプを捜すことにより、ソース放送の中の適切なバッファにセットし直す（リセット）する。このことにより、ユーザ３２が再同期されて、放送内の適切な開始ポイントに戻される。
【００５３】
ストリームを聴取者に送信する代りに、ストリームが、別のマシン（マルチプレクサ１４０）のリピータ２５６に送信される以外は、主要マルチプレクサ４０のリピータ１５６は、聴取者放送スレッドの如く動作する。マルチプレクサ１４０のリピータ２５６は、ＬＢＴに透過的にマップされるメモリ待ち行列を作成する。ネットワーク内のすべてのデモグラフィクス・タイプおよびすべてのマシン・ノードのためのリピータ・スレッド・インスタンスが、主要マルチプレクサ４０インスタンス上に構成される。接続要求が必要とした時、ネットワーク内のサポートしているノードにあるすべてのアクティブ・デモグラフィクス・タイプに対して、リピータ・スレッドが開始される。
【００５４】
上述したような本接続マネージャ・アーキテクチャは、放送への接続を要求するそれぞれのユーザに、使用可能なリソースのあるネットワーク内のマシンの計算リソース（computing-resources）を割り当てることができるため、システム・スループットのスケーラビリティを提供する。サーバ（プロセッサなど）を構成に追加すると、追加したハードウェア数に正比例して、サポートすることができるユーザの数が増大する。
【００５５】
本リピータ・アーキテクチャは、ネットワークの需要を直線的に増加させることなく、ネットワーク内に、さらなるユーザをサポートするサーバの数を追加することができる。これは、特定のデモグラフィクス・タイプについての集約したプログラム・コンテンツをサーバに送信し、そしてサーバが、そのデモグラフィクス・タイプの全ての聴取者に対してその放送を送信することによって、遂行される。
【００５６】
それぞれのデモグラフィクス的に集約されたプログラムは、放送品質を維持するため約１３０ｋｂｓのネットワーク帯域幅を必要とする。約７５０の特有のプログラム・ストリームが、１００ｂａｓｅＴネットワークでサポート可能である。実際、これは、タイムスライス毎の、同様の数の特有な広告よりもはるかに多い数である。したがって、（ＬＢＴに対する処理パワーを基準として）多くのマシンを接続しても、ネットワークの最大ロードに影響を及ぼさない。
【００５７】
重大なボトルネックは、ＬＢＴと、サーバをインターネットに関連付ける、ネットワーク・スイッチ／ルータ・スイッチの間に生じる可能性がある。ネットワーク内の所与のマシンが４０００人の聴取者の接続をサポートしている場合、出力データストリーム帯域幅は、５００Ｍｂｓのスループットを必要とする。しかし、この帯域幅の問題は、現在入手可能なルータと切り換え技術で容易に解決できる。
【００５８】
ユーザ３２に対するそれぞれの接続のポイント・ツー・ポイントおよび安定したストリームは、所与のサーバとネットワーク・ルータ間に多くのネットワーク接続を含むサーバ構成を可能とする。ルータに対するそれぞれのネットワーク接続は、専用物理リンク上にあり、その結果、リンク上のすべてのネットワーク・キャパシティが、複数のＬＢＴの集合に割当てられるのが好ましい。
【００５９】
ルータ／スイッチは、多くの接続をサポートして、物理リンク全体の負荷のスケーリングが可能とする。現行ネットワーク・ルータ技術は、１Ｇｐｂｓのスループット率で動作することができるため、ルータは、最大１０（ten）の１００ｂａｓｅＴリンクまで対処する。ルータは、好ましくは、負荷を、光学（たとえば、同期光通信網（ＳＯＮＥＴ））、ＤＳ４などを介してインターネットまたは他のインターフェイスに切り換える。チャネル毎の２．４Ｇｂｓで動作する光学ネットワーク切換と、そして２５４Ｍｂｓで動作するＤＳ４を使用すると、ルータが意図された数の同時聴取者接続をサポートするに十分な適切な数のＤＳ４／光チャネルを構成するだけで、容易に解決する。
【００６０】
このように、スケーラビリティは、本発明の一態様であり、その理由は、ビジネス・モデルとしての個人用放送の実行可能性には、多数の人々に見聞きされることが必要となるためである。これを達成するには、多くのコンピュータ／サーバ全体に処理量を分配することのできるシステム・アーキテクチャに負託することである。
【００６１】
本アーキテクチャは、本発明の１つの重要な態様を示す。本設計により、高品質のサービスを維持しながら数千人のユーザを同時にサポートする、スケーラビリティの高いアーキテクチャが可能となる。同様に、本アーキテクチャは、インターネットの種類のポイント・ツー・ポイント・ネットワークにおける放送の特有なストリームをサポートできる、という特徴を持つ個別放送の抱える主要な問題点に対応する。
【００６２】
好ましい設計および／または構成を有した形で、本発明を記述してきたが、本発明は、本開示の趣旨および範囲内で、さらに修正することができる。したがって、本出願は、その一般的な原理を使用した本発明の、あらゆる変形形態、使用形態、適用形態を包含するものとする。さらに、本出願はまた、本発明に関連する当技術分野で周知のまたは慣例による手法、および添付した特許請求の範囲内に含まれる、本開示からの逸脱も包含するものとする。
【図面の簡単な説明】
【図１】  マルチメディア放送の一形態を例示したインターネット・ラジオの適用形態を示すブロック図である。
【図２】  本発明の原理に従って構成した、図１のインターネット・ラジオの適用形態を示すブロック図である。
【図３】  本発明の原理に従った、図２のマルチプレクサの機能を示すブロック図である。
【図４】  本発明に従ってインターネットを介して放送用のプログラム・コンテンツを転送するため、放送者がアグリゲータ・プログラムに送信するログイン・コマンドを示すテーブルである。
【図５】  本発明に従って広告マッピング・データを転送するため、放送者がアグリゲータ・プログラムに送信するログイン・コマンドを示すテーブルである。
【図６】  本発明に従ってマッピング・データのレコードの転送に関して、放送者がローダ・プログラムに送信するレコード維持コマンドを示すテーブルである。
【図１】
0004647879.tif 000002
【図２】
0004647879.tif 000003
【図３】
0004647879.tif 000004
【図４】
0004647879.tif 000005
【図５】
0004647879.tif 000006
【図６】
0004647879.tif 000007