JP5025902B2 - ネットワークとサーバの帯域幅最小化および拡張されたパーソナル化のためのマルチキャストネットワーク上でのストリーミングメディア配信 - Google Patents

Description

本発明はネットワーク通信に関し、特にネットワークにおいてストリーミングサーバにより必要とされる帯域幅を劇的に最小化しつつ、ネットワークユーザにパーソナル化されたメディア配信を提供する方法とシステムに関する。

ブロードキャスト技術は、しばしばすべての視聴者に単一のブロードキャストフォーマットを提供する。例えば、ラジオステーションは同じ時刻にすべてのリスナーに同じ音楽またはプログラムを提供する。このフォーマットの問題の１つは、ほとんどの人は自分が好きな音楽だけを聞きたいということである。ラジオステーションは様々なプレイリストにより音楽をブロードキャストすることにより多くのリスナーを満足させるよう試みている。しかし、そのリスナーたちは、自分の好みではない曲が流されているとき、変化を求めて１つの音楽ステーションから他の音楽ステーションへスイッチしてしまう。従来の無線放送によるステーションは１つのトランスミッタから多数のレシーバにブロードキャストしているため、例えばポップス、クラシック、ジャズなどの音楽の種類等による包括的なカテゴリー以外でのパーソナル化は不可能であった。インターネットラジオでは、１対１のパーソナル化がより達成しやすくなった。しかし、ソースからデスティネーションへの専用チャンネルを要する。このことにより、パーソナル化されたインターネットラジオのコストは非常に高くなる。

Ｎ通りのラジオステーションをＭ人のユーザにブロードキャストすることにより（Ｎ／Ｍ＜１とする）、Ｎ通りのプレイリストをブロードキャストするための帯域幅を費やすことで、一定のパーソナル化は達成できる。必要となる帯域幅はＮ＊ＢＷ＊Ｍである。ここで、Ｎはラジオステーションの数、ＢＷはユーザ１人あたり必要な帯域幅、Ｍはユーザ数である。

将来のシステムでマルチキャストを利用すれば、パーソナル化に必要な帯域幅要求（Ｎ＊ＢＷ）に近づくかもしれない。マルチキャストでは、ラジオステーションは世界に向かって単一のストリームを送信し、個々のレシーバはそのストリームから個人的な嗜好または選択されたデータを取り出す。この方法によっても、Ｎ通りのラジオステーションしか入手可能ではないという制限がある。本来のパーソナル化の目標は、ＮをＭ（ユーザ数）に近づけることである。

今日利用されているコンテント配信のモデルの１つは、（ＭＰ３やリアルオーディオ等の）メディアファイルのストリーミングによるものである。コンテントのリアルタイム配信を可能とするために、ストリーミングサーバがグローバルネットワーク中に配置されている。同一のストリームが多数の人々に配信されるので、一般的にこのモデルでは本来のパーソナル化は可能ではない。第２のモデルは、キャッシュサーバからファイルをダウンロードすることである。音楽をキャッシュしておけば、全体的な待ち時間とネットワーク輻輳を最小化することができるが、結局ユーザは個別にダウンロードしなければならない。また、このモデルでは大きな帯域幅が使用される。

それゆえ、先行技術に関連する高帯域幅とサーバコスト無しにパーソナル化を実現する方法とシステムが必要である。

受信したトランスミッションをパーソナル化するシステムは、トランスミッションメディアを介して複数のトランスミッションを提供するコンテントソースを含む。複数のレシーバが含まれ、各レシーバは各ユーザのプレイリストにより１以上のトランスミッションストリームの一部を選択する。レシーバはスケジュールに従って受信したそのトランスミッションの一部を再生する。

パーソナルプレイリストに基づき複数のユーザにコンテントを送信する方法は、複数のユーザの各々のプレイリストを生成するステップと、同時にトランスミッションメディアを介して複数のコンテントストリームを送信するステップとを含む。コンテントストリームには、異なるときに送信された選択されたファイルが含まれる。各ユーザにより、プレイリスト中のファイルが識別され、１以上のコンテントストリームからダウンロードされる。ダウンロードされたファイルはスケジュールにしたがって連続的に再生される。

本発明の有利性、本質、様々な付加的特徴は、添付した図面を参照して詳しく説明される例示的実施形態を検討すればよく分かるであろう。

図面は本発明のコンセプトを例示するためのものであり、本発明を例示するために唯一可能な構成を示すものでは必ずしもないことを理解すべきである。

本発明は、従来のシステムに関連する高帯域幅とサーバコストを要さずしてプレイリストまたはビデオクリップのパーソナル化を達成する方法とシステムを含む。本発明は、複数の同時視聴者の要求とプレイリストを満足するため、同時にブロードキャストされたオーディオまたはビデオの複数のデータストリームを利用する。本発明により、帯域幅制限とパーソナル化されたオーディオ／ビデオ選択の両方の問題が解決される。本発明の一実施例において、２００，０００人のリスナー人口に対して、１０００倍の帯域幅の節約ができる。

オーディオ配信システムについて、本発明を説明することを理解すべきである。本発明を具体的に説明するためにオーディオシステムを例として説明するが、ビデオシステムに本発明を用いてもよい。例えば、ユーザが見たいプログラミング選択を特定する電子的プログラミングガイド（すなわちテレビガイド）を介してユーザのプレイリストが事前に選択されていてもよい。本発明の範囲はオーディオシステムよりも非常に広く、ネットワークを介して配信することができるデジタルマルチメディアドキュメントを含んでもよい。また、本発明は、電話、セットトップボックス、コンピュータ、衛星リンク等により取ったプレイリストオーダーを含むいかなるオーダーリングシステム（オーディオまたはビデオオンデマンドのオーダー等）または方法にも適用可能である。図面に示した要素はハードウェア、ソフトウェア、またはこれらの組み合わせの様々な形式で実施してもよいことも理解すべきである。好ましくは、これらの要素は１以上の適当にプログラムされた汎用デバイス上のソフトウェアとハードウェアの組み合わせで実施され、プロセッサ、メモリ、入出力インターフェイスを含んでもよい。

いくつかの図面を通じて類似した参照数字は類似または同一の要素を識別している図面の具体的な詳細を参照する。最初に、本発明による複数のユーザにプレイリストを配信するシステム１０を例示するブロック図である図１を参照する。システム１０はいかなるデジタルドキュメント配信システムで利用してもよいが、説明を簡単にするため、オーディオドキュメント配信システムについて説明する。ネットワーク上で利用可能な帯域幅、ハードディスクドライブのサイズ、「イベント」がその性質として比較的短いことが現在の技術でより容易に取り扱うことができるので、オーディオは本発明の適用に向いている。また、人々は（ビデオと異なり）ブロードキャストされたオーディオの料金を支払うことに慣れていない。それゆえ、低いマージンの広告収益によりサポートされなければならず、すべてのユーザに対して帯域幅を配信することはより困難となる。帯域幅を共有することができれば、そのサービスをサポートするために必要な広告収益の総額を削減することができる。

もう１つの仮定として、本来のパーソナル化のために厳密に同時に同じ曲を要求するユーザはネットワーク上にはいないものとする。それゆえ、Ｍ人のユーザが曲Ｘの一部を同じ部分ではないが再生していることはありえ、Ｍ人のユーザがＭの局をフェッチしていることもありえる。従来のシステムでは、すべてのユーザが同時に同じ曲を聴く必要があった。

図１において、音楽、ビデオ、クリップ、その他のタイトルのデータコンテントのプレイリストを生成するために、複数のユーザ１−Ｎが各々パーソナル化プレイリストジェネレータ１２とインターフェイスしている。データベース１４はコンテントを格納し、そのコンテントは以下の方法によりユーザに配信される。プレイリストジェネレータ１２はユーザに選択されたコンテントに基づき、または前にユーザが選択したコンテントに基づき、個々のプレイリストを生成する。パターン格納１６は個々の使用パターンをトラッキングし、ユーザの以前の使用に基づきスケジュール中に入れる、またはユーザが無視または選択をしないことを選択したスケジュール中のスペースを埋めるために曲を選択してもよい。パターン格納１６には、ユーザの人口統計またはパーソナル情報も格納されてもよい。このように、特定の広告が格納されたデータに基づき特定の個人または集団に向けられてもよい。人口統計には、他にもあるが、年齢、性別、音楽／ビデオの嗜好、視聴時間等が含まれる。

各ユーザ１−Ｎは、サーバまたはステーション２０からのデータストリームまたはトランスミッションを読むために好適なプレーヤ／レシーバ１８を有する。サーバ／ステーション２０は、ネットワークを介して、放送電波で、インターネットを介して、またはこれらの組み合わせで同時にデータの複数のストリームを送信する。プレーヤ１８は、データストリーム２２を介して送信されるデータコンテントを受信し使用することができるコンピュータデバイス、電話、テレビ、ラジオ、その他のいかなるデバイスを含んでもよい。特に便利な実施形態においては、プレーヤ１８は１以上のデータストリーム２２からのユーザプレイリストに対応したファイルまたはクリップを見つけることができる。

プレーヤ１８は、ＴＣＰ／ＩＰ等の適当なプロトコルを用いてネットワーク２４とサーバ２０と通信する。ネットワーク２４は、ワイヤレスネットワーク、ブロードキャストネットワーク、衛星ネットワーク、デジタルサブスクライバラインネットワーク、有線電話、ケーブルネットワーク、またはその他のいかなるタイプのネットワークを含んでもよい。プレイヤ１８は、好ましくは、スケジュール中の次または将来の時間スロットで再生されるべきコンテントを一時的に格納するメモリまたはバッファ２６を含む。プレイヤー１８は、どのデータストリームが個々のユーザのプレイリストに従って必要などのファイルまたはコンテントを含んでいるかを識別することができるソフトウェアプログラム２８を含む。データストリーム２２はパケット内にヘッダ情報を有し、この識別をするためにそのヘッダー情報はプレーヤ１８により取り出し、識別することができる。

図２を参照して、プレイリスト生成がブロック１００で実行される。本発明は、観察された視聴の癖に基づき、ユーザのプレイリストを生成可能とするプロファイリング等の、既知のコンセプトを使用してもよい。ユーザと音楽のタイプおよび／または曲の嗜好の間を関連づける多数のアルゴリズムがある。ブロック１０２において、パーソナル化されたプレイリストがスケジュールされる。パーソナル化されたプレイリストを生成するには、既知の方法を利用してもよい。しかし、本発明は、マルチキャストブロードキャストスケジュールと同期したプレイリストを構築する方法を含む。

本発明により、ブロードキャストされたステーションは１からＮのマルチキャストチャンネルよりなる。ブロック１０４において、各チャンネルはデータストリームを同時に送信する。各データストリームには、複数の曲、ビデオ、クリップ、広告、その他のコンテントが含まれている。ブロック１０２においてユーザのプレイリストには、ユーザによりどのマルチキャストチャンネルがアタッチされるべきで、アタッチすべき時に関する指示が含まれている。現在の曲が終了したとき、次の曲へスムーズに移り変わるように、ユーザが曲を聞いている間に、そのユーザは次の曲をプリバッファするための異なるマルチキャストチャンネルにアタッチする。この説明において、「曲」は音楽、ビデオ、広告、他のデジタルドキュメント、クリップを表す。

ブロック１０４の任意的実施形態において、本発明では、曲はユーザが合法的にアクセスできる曲に限定される。本実施形態の一実施例において、ＲＣＡ音楽レーベルで入手可能な曲にアクセス可能なサービスに加入することもできる。これにより、そのユーザはその加入により入手可能な（ＲＣＡからの）プレイリスト上の曲のみを選択できる。同様に、このアイデアは、ペイテレビ等の視覚的なベースのプログラミングに変換することもできる。ここで、ユーザがＣＩＮＥＭＡＸプログラミングに加入していなければ、ＣＩＮＥＭＡＸではなくＨＢＯからプレイリストの選択肢を選ぶことができるであろう。この著作権情報は、ユーザがそのメディアファイルにアクセスできるか判断するために、（例えば、１はアクセス可能、０はアクセス制限）メディアファイルに対応する、データファイル中に埋め込まれた制御フラグとして、または（図１の）データベース１４と比較できる他の手段（例えば、メディアファイルに対応するＭＰ３タグ等のファイルＩＤ）により識別されてもよい。

スケジューリングプロセスは、コンテントを時間スケジュールまたはスロットにフィットさせ、視聴者が正しくスケジュールされているか（ブロック１０６）または不正にスケジュールされているか（ブロック１０８）を判断する。正しくおよび不正にスケジュールされたユーザは、プレイリスト、広告、およびフィルが与えられた時間期間内に入るかどうかに基づく。ユーザのプロファイルにマッチする曲のマルチキャストチャンネルが探索され、適当な時間フレームにおいてスケジュールにアタッチされる。これらの基準に合う曲がない場合、そのユーザのスターティングポイントとして異なるマルチキャストチャンネルが選択され、アルゴリズムが繰り返される。そのユーザの解が見つからない場合、そのユーザはブロック１０８においてまだスケジュールされていないとしてマークされ、次のユーザが処理される。

ブロック１１０において、正しくスケジュールされたコンテントの量のパーセンテージが閾値と比較される。その量が閾値を超えた場合、不正にスケジュールされたリスナーの時間スケジュールのコンテントの残りは、ブロック１１２において、時間期間で必要なコンテントを完成するために強制的にフィットされる。スケジュールされていないユーザのパーセンテージが分析され、その数字がステーションオペレータにより設定された閾値を超える場合、最も拒絶される回数が多い曲はプレイリストの選択肢から除外され、新しい選択肢と置き換えられてもよい。スケジューリングステップは必要に応じて繰り返される。

もし繰り返し試みても解に到達しない場合、スケジュールされていないユーザは、ブロック１１２において、プレイリストへの適合性が最も低くない結果となるスケジュールに強制的にフィットされる。この時点において、そのステーションのインベントリーはユーザコミュニティにマッチしないことが分かり、そのステーションがインベントリーの調整をできるように、管理レポートがスケジューリングデータから導かれる。

さもなければ、ブロック１１４において、時間スケジュールを正しくフィットしても連続的に失敗したことがレポートされる。その後、ブロック１００に戻り、繰り返される。

図３を参照して、本発明によるプレイリストの生成を、より詳しく説明する。ブロック２００において、ユーザシステムにより、ユーザベースへのサービスに割り当てられるべきマルチキャストチャンネルの数が決定される。その決定のため、そのステーションに割当て可能な帯域幅、ユーザ数、ユーザが共通して興味を持っている曲のインベントリー中のパーセンテージ等が入力される。ブロック２０２において、人気があると分かっている曲／ファイルの選択を保証するため、ユーザ選択を用いて、またはユーザの利用可能なプロファイリング情報を用いることによって、データベースから曲やファイルが選択される。そのプロファイリング情報は、ユーザが選択した曲や情報を含んでもよく、そのユーザに関して知られた情報によりシステムにより選択されてもよい。最も人気のある曲は、それよりは人気がない新しい曲で補ってもよい。

ブロック２０４において、曲／ファイルが複数のマルチキャストチャンネルのスケジュールに挿入される。人気のある曲は、スケジュール時間にわたって配信され、ユーザのスケジュールが満たされる確率をより高めることを可能とする。その曲の演奏時間が分析され、リスト中の演奏時間の合計がスケジュール期間を超えないようにする。ブロック２０６において、広告コンテントとオーディオフィルタがマルチキャストチャンネルに挿入される。プログラムコンテントより広告コンテントの方が（思うに）少ないので、広告はスケジュール中繰り返される。広告を繰り返すことにより、ユーザのバーチャルブロードキャストの異なる段階において、スケジューラはよりフレキシブルに利用可能な時間にフィットする広告を選択することが可能となる。

ブロック２０７において、放送電波でまたはネットワークを介して複数のデータストリームが送信される（例えば図３参照）。ブロック２０８において、チャンネル中の次の曲がユーザのプロファイルにフィットしなくなるまで、ユーザをマルチキャストチャンネルにポインティングすることにより、各ユーザの選択リストを構築する。ユーザのプロファイルにマッチし、適当な時間フレームにアタッチできる曲のために、他のマルチキャストチャンネルが探索される。もしこの基準に合う曲がない場合、異なるマルチキャストチャンネルがそのユーザのスターティングポイントとして選択され、アルゴリズムが繰り返される。そのユーザの解が見つからないとき、そのユーザはスケジュールされていないとしてマークされ、次のユーザが処理される（図２参照）。

ブロック２１０において、正しくスケジュールされたユーザがすべて、マルチキャストデータストリームチャンネルから自分のファイルをダウンロードする。ブロック２１２において、ユーザが個別に選択したファイルにより、または視聴者人口の習慣や各自の習慣により、プレイリストを再生または再現する。

図４を参照して、アイテム３０１、３０２、３０３、３０４は、異なるマルチキャストチャンネル上でブロードキャストされたメディアのシーケンスを表す。各マルチキャストチャンネルにロードされたインベントリは、合計が所望のスケジュール時間よりも少し短くなる演奏時間となるように予定されている。図示したチャンネルの数は４だが、実際には、チャンネル数はこれよりも非常に大きい。

ユーザの全再生時間がスケジュール時間３１０と等しくなるように、マルチキャストチャンネル（ＣＨ）１、２、３から曲を、マルチキャストチャンネル４から広告コンテントおよび／またはフィルコンテントを選択することにより、本スケジューリング方法によりユーザのプレイリストが構築される。この例において、スケジュール時間３１０の終わりですべてのユーザの同期イベント（ニュースキャスト）が再生される。

アイテム３０５はシステムのユーザ１のダウンロードスケジュールを説明している。ユーザがステーションに接続するとき、アイテム３０５のスケジュールがダウンロードされ、ユーザのプレーヤはそのスケジュールによりそのステーションと協働する。アイテム３０６と３０７は、本システムの２人のユニークなユーザ（例えばユーザ１とユーザ２）のプレイバックシーケンスを示している。アイテム３０５に図示されているようなダウンロードスケジュールは、ユーザ２には示されていないが、ユーザ１と同様な仕方で導くことができる。ユーザ２のスケジュールは、他のユーザのスケジュールとは独立に作られ、個別のユーザ嗜好、または自分の都合のよいように選ばれたプレイリストに基づき生成される。このように、本発明により、個別のユーザにより受信され再生されたプレイリストの本来のパーソナル化が可能となる。

ユーザがステーションに最初に接続されたとき、スケジュール時間期間の初めではスタートできないかもしれない。スケジューラは、ユーザの第２のスケジュールをスケジュール時間期間に同期可能とする、第１のスケジュールに対し最もよくフィットするスケジュールを立てる。必ずしもユーザの第１の曲がその曲の始めからスタートするとは限らない。これは、ＦＭ／ＡＭアナログ放送のスイッチを入れ、進行中の放送を選択したユーザの現在の経験とマッチしている。他の実施の仕方として、メモリが十分あれば、１つの曲をハードウェアにロードしておくこともできる。この曲を格納しておくことにより、瞬時に再生をスタートしたり同期したりすることができる。

本発明の以下の説明においては、ユーザは最初のスタートアップスケジュールを経過して、スケジュール時間期間全体の新しいスケジュールを処理する準備をしていると仮定する。本発明では、スケジュール期間の概念は必要ないということに注意すべきである。ステーションは、すべてのユーザはスケジュール同期させないことを選択してもよい（すなわち、スケジューリング期間を用いない）。例えば、一人のユーザが定時ニュース放送を午前８時に聞き、他のユーザが同じ放送を午前８時３分に聴いてもよい。

図４を再度参照して、ユーザのプレイバックモデルについて説明する。時刻ｔ１において、ユーザ１はマルチキャストチャンネル１からビートルズの曲をダウンロードする。そのビートルズの曲は、アイテム３０６のスケジュール時間３１０の初めで再生される。マルチキャストチャンネルからのマテリアルのダウンロードは、そのチャンネルへの接続を確立する時間を確保し、プレイバックのためにデータを適当にバッファできるように、そのスケジュール時間期間が始まる前にスタートするようにスケジュールされている。本発明の一態様によると、音楽、データ、その他の送信されたコンテントは圧縮され、再生レートより高いビットレートで送信される。例えば、ユーザのラジオの再生レートが６０００ビット／秒であるとき、送信レートは例えば６０００００ビット／秒以上であることも可能である。再生すべき実際のコンテントが受信されバッファされるので、多数の曲をより短い時間で送信することができる。ユーザ１のプロファイルには、そのユーザがマルチキャストチャンネル１のイーグルスの曲をスキップしたことが示され、マルチキャストチャンネル２のハートのセレクションが選択されたことを示す。時刻ｔ２において、ユーザのプレーヤはマルチキャストチャンネル２にアタッチし、ビートルズのセレクションがまだ再生されている間に、ハートのセレクションのダウンロードを開始する。

ユーザ１のプレーヤがイーグルスのセレクションに先行するストリーム情報マーカを検出したとき、そのプレーヤはハートのセレクションをキャッシュから再生する。ユーザ１のプレーヤはそのスケジュールを評価し、時刻ｔ３までにマルチキャストチャンネル４にアタッチして、ハートのセレクションが完了したときに再生する広告２のダウンロードを開始しなければならないと判断する。そのスケジュールによると、時刻ｔ４においてユーザは広告３のダウンロードを開始すべきである。この時点において、そのプレーヤはハートのセレクションを再生しており、広告２をキャッシュしており、そのキャッシュの終わりに広告３を追加していることを注意する。

時刻ｔ５において、そのスケジュールの次のダウンロードとしてフィルを読み出す。フィルクリップは、ある固定された長さのオーディオを有する、特別に作られたオーディオブロックであり、このフィルの後にはオーディオブロックが続く。フィルは必要に応じて時間のギャップを埋めるために繰り返される。フィルの例は、例えば「こちらＫＬＰＸ、インディアナポリス」というステーションアナウンスメントと、それに続く音楽ブロックである。フィルに先行するストリーム情報パケットには、後続のオーディオのバイト数に関する情報、プレフィックス、そのプレフィックスのプレイバック時間、そのプレフィックスに続くオーディオの繰り返しのプレイバック時間が含まれる。

プレーヤは、フィルブロックがどれだけの時間を占有するか判断するため、そのスケジュールを評価し、適宜オーディオを再生する。繰り返されるオーディオブロックのプレイバック時間には、時間アライメントを適当に制御するために１秒以下の精度を要求してもよく、本発明の実施においては、プレーヤをよりよく制御するため複数の繰り返されるオーディオブロックを符号化することを選択してもよい。このタイプのフィルクリップデータのレイアウトを図５に例示した。

時刻ｔ６とｔ７において、ユーザ１のプレーヤは、最後の２つのセレクション（ジェームスギャングとニュース）をダウンロードし、フィルオーディオの再生を完了した後、それらを順次再生する。これにより、スケジュール時間のプレイリストが完成し、ユーザ１のプレーヤは次のプレイリストスケジュールの処理の開始を要求する。

ユーザは標準のＴＣＰ／ＩＰ接続を介してステーションと接続してもよい。本発明については、他の接続を検討してもよい。例えば、ラジオ周波数トランスミッション、ケーブルトランスミッション、衛星トランスミッションも用いてもよい。ユーザはプレイバックスケジュール（例えばアイテム３０５）を読み出す。そのスケジュールには、例えば、マルチキャストチャンネルの各々のＩＰアドレスがスケジュール中に示されて含まれていてもよい。そして、ユーザはそのスケジュールに示された時刻に、適当なＩＰアドレスにマルチキャスト接続要求を発行する。そのスケジュールされた時刻の前に、マルチキャスト接続がネットワークを伝播し、確立される時間を十分に確保する。

図４に示したマルチキャストチャンネル１、２、３、４の各々は、ステーションのサーバから同時にブロードキャストされる。ユーザは接続がされた時間にスタートして、追加的同期無しに、マルチキャストチャンネルからデータを受信する。プレーヤは、ストリーム情報マーカ３１５を探すことにより、そのマルチキャストチャンネルブロードキャストに同期する。スケジュール中に示された時間までにそのマーカが読み出されなかった場合は、プレーヤはそのマーカを単に見失ったと仮定して、受信したバッファを再生し始める。そのプレーヤがスケジュールされたセレクションのバッファを受信したとき（オーディオデータのセレクションとともに送信されるバッファヘッダ中に示される）、見失ったデータブロックを要求するため、プレーヤはサーバとＴＣＰ接続を確立することを選択してもよい。もし現在のセレクションの再生が停止する時間までに、バッファが正しいものであることが確認できない場合、「デッドエアー」を防止するため、プレーヤは新しいセレクションの中から再生できるものを任意的に再生して、そのセレクションの終わりではフィラーブロックを使用することができる。または再同期できるように、サーバからの新しいスケジュールを要求することもできる。

多数のユーザに対してスケジューリングアルゴリズムを実装するための処理コストに関して、マルチキャストを用いることによる帯域幅の節約が大きいとき、本発明は特に便利である。一実施形態において、帯域幅コストにおける期待される減少は、プレイリストがどのくらい共通であるかに依存する。以下の例は、ある与えられた環境における帯域幅の減少を例示的に示す。
Ｍ＝音楽の分／時間＝４０
Ａ＝広告の分／時間＝２０
Ｌ＝曲の平均的長さ＝３
Ｎ＝マルチキャストチャンネルの数
Ｓ＝ストリーミングレート
Ｕ＝ユーザ

この例において、２００個のマルチキャストチャンネルがブロードキャストに割り当てられている。スケジュール時間ホライズンが１時間のとき、（Ｍ／Ｌ＊Ｎ）または（４０／３＊２００＝２６６６）通りの曲のセレクションがあるであろう。ユーザがそのステーションのジャンルの曲の５０％を好きな場合、１つの曲のセレクションにつきそのユーザが拒否する可能性が１％［（Ｍ／Ｌ）＊Ｎ＊．５０］ある。１時間あたり１３３３の可能性の中から１３のうまくいく選択をする必要があるとき、スケジューリング解が成功する可能性は１００％に近づくべきである。

成功したスケジューリング解を与えられたとして、そのステーションをサポートする帯域幅要求はＮ＊Ｓである。マルチキャストでないステーションについて、パーソナル化されていないステーション（皆が同じプログラムを聴く）の帯域要求はＵ＊Ｓである。２００，０００リスナーのユーザベースに対して、本発明による帯域幅の節約は（２００，０００／２００＝１０００％）である。

現在のネットワーキングの用語では、本発明は、この実施例においては、２００，０００ユーザへのマルチキャストをサポートする２つのＴ１チャンネルを使用してもよい。マルチキャストでないステーションは１０００個のＴ１チャンネルを必要とし、大きなルータ会社がこれをサポートする必要もある。このシナリオではコストの節約はかなり大きい。

ビデオストリームの帯域幅要求はより高く、プレイバックデバイスでバッファようのメモリが余計に必要である。上で説明したように、本発明は帯域幅要求がより高いビデオにも適用可能である。上で説明した実施例でビデオアプリケーションをサポートするために、２００個のマルチキャストチャンネルをサポートするために、４００個のＴ１チャンネルが必要である。ネットワークと交換の技術が進歩し成熟するにつれ、大規模なビデオマルチキャスティングをサービスするために本発明を容易に利用することができる。

ダウンロードした曲が損なわれているとき、プレーヤデバイス中のソフトウェアにより、その曲を再要求したり、スマートパッチプログラムを実装し消失した部分をＦＴＰしてもよい。他の解決策として、ユーザはその曲が次にかかることを、例えば表示されたプレイリスト上で、すでに見ているかもしれないが、その曲を単にスキップすることもできる。

任意的に、本発明の一実施形態において、プログラミングが時間的および／または主観的嗜好に対応するユーザランキングプレイリストセレクションをサポートする。例えば、朝のニュースと晩の音楽の嗜好を選択する。本発明によると、プログラミングセレクションを配信するためにそのユーザのプレイリストを他のプレイリストと調整するとき、時間的、主観的な特定のプログラミング、またはその組み合わせが検討される。

ネットワークとサーバの帯域幅を最小化し、パーソナル化を改良するためにマルチキャストネットワーク上でストリーミングメディアを配信する好ましい実施形態を説明したが（これは例示を意図したものであり、限定を意図したものではない）、上記の教示に照らして当業者は変更とバリエーションをすることができることに注意すべきである。添付したクレームにより特定された、本発明の範囲と精神内において、開示した本発明の特定の実施形態に変更を加えることができることを理解すべきである。特許法により要求された詳細と具体性のもと本発明を説明したが、請求され特許により保護を望むものは、添付したクレームに述べられている。

本発明の一実施形態による、受信したトランスミッションをパーソナル化するシステムを示すブロック図である。 本発明の一実施形態による、パーソナル化されたプレイリストをスケジューリングする方法を示すフローチャートである。 本発明の一実施形態による、パーソナルプレイリストに基づき複数のユーザにコンテントを送信する方法を示すフローチャートである。 本発明の一実施形態による、コンテントのスケジューリングと複数のユーザに対する送信を示すタイミング図である。 本発明による、コンテントのデータレイアウトを示す図である。

Claims (4)

1. ユーザプロファイル情報に基づき複数のユーザにコンテンツを送信する方法であって、
   前記ユーザプロファイル情報を用いて、複数のマルチキャストチャネルを介して送信する少なくとも１つのオーディオ及びビデオファイルを含むコンテンツを選択する、用いるステップと、
   前記複数のマルチキャストチャネルから少なくとも２つのマルチキャストチャネルを選択して、前記少なくとも１つのオーディオ及びビデオファイルを送信する、選択するステップであって、マルチキャストチャネルをいくつ選択するか決定するために、利用できる帯域幅と、前記少なくとも１つのオーディオ及びビデオファイルを送信するユーザ数とを考慮し、前記ユーザ数は２以上である、選択するステップと、
   前記少なくとも１つのオーディオ及びビデオファイルを送信するステップであって、前記複数のユーザのそれぞれのユーザに関連するプレイリストを満たすようにあるスケジュールにしたがってファイルが利用可能となり、前記プレイリストがそれぞれのユーザのユーザプロファイル情報を用いて生成されたコンテンツを含むように、各ファイルを同一または異なるコンテンツストリームを介してある頻度で送信する、送信するステップとを含む方法。
2. 前記プレイリストのコンテンツは前記ユーザにより選択されたものである、請求項１に記載の方法。
3. 人口統計情報に基づき前記ユーザに送る広告を選択するステップをさらに含む、請求項１に記載の方法。
4. 前記複数のユーザの各ユーザに関連するプレイリストに基づき前記複数のユーザのスケジュールを算出するステップをさらに含む、請求項１に記載の方法。

Images