JP2010541484A

JP2010541484A - サーバ制御型のメディア・コンテンツ配信

Info

Publication number: JP2010541484A
Application number: JP2010528047A
Authority: JP
Inventors: チャンゲチャン; スードヴィシャル; ジー．ノウルトンクリストファー; ジェイ．ステープルズウィリアム
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2007-10-01
Filing date: 2008-09-29
Publication date: 2010-12-24
Also published as: CN101809614A; TWI459214B; TW200919211A; EP2206083A4; EP2206083A2; WO2009045942A3; US20090089401A1; WO2009045942A2

Abstract

メディア・コンテンツが部分的な断片でクライアントに送信され、その結果、クライアントがメディア・コンテンツを視聴する仕方を制御できる技術が説明されている。クライアントは部分的なコンテンツを要求し、サーバは、そのクライアントに対して（例えば、プレイリスト・プロバイダによって）提供されたプレイリストに対して評価した後、１つまたは複数の様々な条件に基づいてその要求を許可または拒否する。例えば、プレイリストにより、クライアントがコンテンツをスキップすることができないことを規定できる。これにより、サーバは、他のコンテンツをスキップするような、コンテンツの部分に対する要求を拒否する。クライアントに送信されたコンテンツを追跡するために、セッション関連データを保持することができる。メディア・コンテンツを動的な条件に基づいて送信することができ、および／またはプレイリストを動的に適合させることができる。メディア・コンテンツの部分は広告を含んでもよい。広告は、例えばユーザ・プロフィール・データおよび／またはクライアントの位置情報に基づいて、そのクライアントに対して特別に選択されたものであってもよい。

Description

人々がメディア・コンテンツをインターネットからダウンロードすることが益々一般的となってきている。係るコンテンツには、様々なタイプの予め録画されたビデオおよびオーディオ・ファイル、ならびにライブの番組が含まれ、無料のコンテンツ、または加入契約によるもののような何らかの形で有料であるコンテンツの両方が含まれる。

１つの問題は、ウェブ・サーバを介してコンテンツを送信する場合に、ユーザがコンテンツを視聴する仕方を殆ど制御できないか、または全く制御できないことである。例えば、視聴者は或る特定のコンテンツをスキップするか、またはそのコンテンツ内を探索するかもしれない。その１つの結果として、これは本質的には、視聴者が広告をスキップしないという保証がない場合には広告主は全くまたは比較的少ししか料金を支払わないので、妥当な収入を広告から得るコンテンツを提供するのは容易でないことを意味する。提供されたコンテンツとユーザが対話するための標準および／または解決策は現在のところ知られていない。

本要約は、選択した代表的な概念を簡潔な形で導入するために与えられる。その概念は、後に「発明を実施するための形態」でさらに説明する。本要約はクレーム主題の主要な特徴または本質的な特徴を特定しようとするものではなく、決してクレーム主題の範囲を限定するために使用しようとするものでもない。

簡潔に述べると、本明細書で説明する主題の様々な態様は、クライアントの要求に応じて、サーバが制御可能にメディア・コンテンツの断片をクライアントへ送信する技術に関する。クライアントの要求について（または要求の一部について）、サーバは、クライアントがその要求に対応するメディア・コンテンツの特定部分を受け取ることができるかどうかを判定する。受け取ることができる場合は、サーバはそのメディア・コンテンツの特定部分を送信する。

１つの実装形態例では、サーバはクライアントに対してセッションを作成し、そのセッションに対応するセッション関連のデータを維持する。例えば、セッション関連のデータにより、以前にクライアントへ送信されたコンテンツを追跡することができる。クライアントがメディア・コンテンツの特定部分を受け取ることができるかどうかの判定は、セッション関連のデータについてクライアントに関連付けられたプレイリストを評価することによって行うことができる。プレイリスト・プロバイダがプレイリストを提供することができる。メディア・コンテンツを求めるクライアントの要求に応答してメディア・コンテンツをコンテンツ項目として提供するために、プレイリスト・プロバイダをサーバに結合し、メディア・コンテンツのソースに結合させることもできる。

一態様では、メディア・コンテンツを動的な条件に基づいてクライアントに送信することができ、および／またはプレイリストを動的に適合させることができる。さらに、メディア・コンテンツの特定部分を広告とすることができる。広告は、例えばクライアントに関連付けられたユーザのプロフィール情報に基づいて、および／またはクライアントに関連付けられた位置情報に基づいて、複数の予定される広告から（例えば、サーバまたはプレイリスト・プロバイダによって）選択してもよい。

他の利点は、図面と関連して読むと、以下の詳細な説明から明らかになろう。

本発明は添付の図面に例示されているが、添付の図面に限定されるものではない。添付の図では、同じ参照番号は同じ要素を指す。

メディア・コンテンツの制御された送信を提供するための通信のフローの例を表す図である。メディア・コンテンツの制御された送信を提供するための代替的な通信のフローの例を表す図である。ＩＩＳ（ｉｎｔｅｒｎｅｔｉｎｆｏｒｍａｔｉｏｎｓｅｒｖｉｃｅ＝インターネット・インフォメーション・サービス）サーバのモジュールを含む、メディア・コンテンツの制御された送信に関与するコンポーネントを表すブロック図である。メディア・コンテンツの制御された送信を提供するための、インターネット・インフォメーション・サービス・サーバのコンポーネントを含むデータのフローの例を示す図である。インターネット・インフォメーション・サービス・サーバを介した送信を含めて、メディア・コンテンツの制御された送達を提供するための通信のフローの例を示す図である。メディア・コンテンツの制御された送信を要求しているクライアントに提供するための、サーバが実施するステップの例を一般的に表すフロー図である。適合的な方式を含めて、メディア・コンテンツの制御された送信を要求しているクライアントへ提供するためにプロバイダと関連して動作するサーバが実施する、ステップの例を一般的に表す流れ図である。本発明の様々な態様を組み込むことができるコンピューティング環境の例を示す図である。

本明細書で説明する技術の様々な態様は、一般に、ウェブ・サーバからの段階的なダウンロード（progressive download）によるものを含めて、ウェブ・メディア・コンテンツの制御された送信を容易にすることに関する。理解されるように、これにより、メディアの送信をサーバ側で制御する機能がもたらされる。他の態様の中でも、この機能により、探索、早送り（skip forward）、巻戻し（skip backward）、等のようなクライアントに公開された機能の実行を、サーバ側で制御することができる。

サーバ制御を用いると、様々な顧客のニーズに関して柔軟であるが様々なビジネス・モデル等に対して拡張可能なように、コンテンツを送信することができる。例えば、広告の対象を或る特定の位置および／または或る特定のタイプのユーザに絞るといったように、ユーザに関わることおよび／または位置に関わることを考慮して、コンテンツを様々に提供することができる。さらに、係る制御により、スキップまたは探索を防ぐことができ、または、これまでコンテンツ全体のうちどのくらいの割合が、クライアントに送信されたかのような条件に基づいて何らかの対話を或る程度可能にすることができる。例えば、クライアントは、そのコンテンツの部分の８０パーセントが先に送信された後に、プレイリスト内の次のコンテンツに早送りすることができる。一部の動作を或る特定のクライアントに対して許可し、その他のクライアントには許可しなくてもよい。例えば、料金を支払った加入契約者はコンテンツを飛ばすことができるが、料金を支払わないクライアントは同じ機能を行うことができないとしてもよい。

本明細書では、主として、単一のクライアントと、コンテンツをコンテンツ・ソースから選択的且つ制御可能に取り出す中間装置として動作する、単一のウェブ・サーバとの間の対話に関連して様々な例を説明する。この対話においては、サーバ制御がクライアントのセッションまたはユーザのセッションを介して強制されるが、これらは単に例にすぎないことは理解されよう。例えば、予定される多数のサーバに結合された多数のクライアントを含み、その多数のサーバが様々なコンテンツ・プロバイダによって供給されるコンテンツを受け取ることができるネットワーキング環境（例えば、インターネット）において、本明細書で説明する技術が使用されるとしていることは理解されよう。さらに、サーバがコンテンツを含むことも可能であり、実際、コンテンツ（例えば、人気のあるコンテンツ）をキャッシュし、および／またはローカルな仮想的なコンテンツ・プロバイダを使用してリモート・コンテンツ・プロバイダとの不要な通信を回避することができる。

従って、本発明は、本明細書で説明するどの特定の実施形態、態様、概念、構造、機能または例にも限定されない。そうではなく、本明細書で説明する実施形態、態様、概念、構造、機能、または例の何れも非限定的であり、本発明を、コンピューティング、ネットワーキング、および一般にコンテンツ送信において利益と利点をもたらす様々な方法で使用することができる。

図１を参照すると、ウェブ・プレイリストを取得および使用してメディア・コンテンツの送信を制御するための、経時的な通信の一般的な動作のフローが概念的に表されている。このフローにおいて、動作の順序は一般に上から下に進む（図１においては、時間を直線的に表そうとはしておらず、他のどのようなパターンに従って表そうともしていないことに留意されたい）。一般に、エンド・ユーザ１０３に関連付けられるようなクライアント１０２が、サーバ１０４が提供したウェブ・プレイリストのサイトにユーザであるクライアントを導くリンク等をクリックする。本例では、サーバ１０４がクライアント１０２に対してセッションを作成する、ここで証明書、支払い、等を要求してもよい。

図１の実装形態例では、サーバ１０４はプレイリスト・プロバイダ１０６に結合され、そのプレイリスト・プロバイダ１０６は、プレイリストに対応するコンテンツを含むデータ・ストア１１０を有するコンフィギュレーション・サービス１０８に関連付けられている。サーバは現在のプレイリスト（current playlist）をプレイリスト・プロバイダ１０６に要求し、プレイリスト・プロバイダ１０６は順次、コンフィギュレーション・サービス１０８に要求（例えば、ＧｅｔＰＩａｙｌｉｓｔＣｏｎｆｉｇｕｒａｔｉｏｎ）を送信する。それに応答して、コンフィギュレーション・サービス１０８が現在のプレイリストに対応するデータ（例えば、ＲｅｔｕｒｎＰｌａｙｌｉｓｔＥｌｅｍｅｎｔｓ）を返す。そのデータを、プレイリスト・プロバイダ１０６が所望に応じて処理（例えば、フォーマット）して、サーバ１０４にプレイリストを返すことができる。これらの要素および／またはプレイリストが、サーバ１０４および／またはプレイリスト・プロバイダ１０６によって必要とされる（例えば、未だキャッシュされていない）任意の対応するコンテンツを含んでもよいことに留意されたい。

次いで、サーバ１０４は、メディア・コンテンツの一部または全部に対するエントリを有するクライアント側のプレイリストを（例えば、１つまたは複数のコンテンツ・ファイル等を参照する「．ａｓｘ」ファイルの形式で）クライアント１０２に提供する。クライアントは、この時点でプレイリスト中の１つまたは複数のエントリのうちから選択して、対応するコンテンツを再生することができる。図１に一般的に表すように、その後クライアントは、部分的なコンテンツを断片的に（例えば、Ｃｏｎｔｅｎｔ１、Ｃｏｎｔｅｎｔ２、等）要求し、サーバがクライアント・セッションと作成された要求とを認証（validate）した後に、対応するコンテンツを受け取る。

例として、クライアントが、クライアントにまだ送信されていないコンテンツの別部分に対して順序が狂っているコンテンツの特定部分を要求することによって、早送りを要求していることがある。その要求（スキップ動作）が許されるかどうかは、プレイリストがコンテンツをスキップすることに関して（もしあれば）どのように記述しているかに基づいて、制御ロジック１１４により評価される。プレイリストは、以前にどのくらいのビットがユーザに送信されたかに基づく条件のような、スキップが許される条件を規定するデータを含んでもよい。

図１の例では、第１のクライアント要求に関してサーバが作成したユーザ・セッションを介して、サーバ制御が実行される。サーバ１０４は、セッション関連データ１１２を維持する。このセッション関連データ１１２は、例えば１組の条件を含む。その１組の条件を制御ロジック１１４が使用して、例えばユーザまたはクライアント１０２によってダウンロードされたコンテンツの部分（例えば、ビットまたはビット群）を追跡することといった、クライアントを認証しおよび／またはそのクライアントに関連付けられた他の条件を評価することができる。時刻（または、最後にコンテンツ送信動作を行った時刻）および／またはクライアント固有のデータ（例えば、ユーザ・プロフィールおよび／または現在位置であり、これらはモバイル・ユーザの場合は動的でありうる）のような他のデータ１１６を制御ロジック１１４によってプレイリスト１１８中の情報に対して評価して、クライアントがどの動作を実行できるかを判定することができる。

図１に表したように、コンテンツを求める後続のユーザ要求ごとに、サーバ１０４はその要求をセッション・データに対して再度認証して、（例えば、プレイリスト１１８に記述されているな）コンフィギュレーションが許す場合に限り許可される、探索またはスキップのような何らかの要求されたエンド・ユーザの動作を許すかどうかを判定する。上述のように、このセッションにおいて制御ロジックは、どのコンテンツをユーザが受け取ったかを追跡し続け、それによりサーバ１０４は、閾値割合が送信された後に、次のコンテンツへのスキップが可能となるような動作を制御することができる。また、この特性（capability）により、例えば送信されている以前の部分の割合に基づいて、コンテンツの次の部分をキャッシュすることが容易になる。

また、図１はプレイリスト・プロバイダ１０６を例示している。プロバイダ１０６（サーバ１０４のようなサーバ・サービスの一部であるか、または独立した実体（entity）であってもよい）は、どのコンテンツがプレイリスト１１８の一部として送信可能かを判定し、また、その判定において、どの動作が特定のコンテンツ部分に対して許可（または拒否）されるかに関する情報をサーバ１０４に提供する。動作例には、探索、早送り、または巻戻しが含まれる。また、プレイリスト・プロバイダ１０６は、サーバ１０４からユーザのプロフィールおよび／または位置データを受け取って、それらを使用して情報を提供することができる。すなわち、プレイリスト・プロバイダ１０６がコンテンツおよびクライアントのために最も適切なプレイリストを構築することを可能にする。これにより、ユーザ固有のコンテンツおよび／または位置固有のコンテンツを提供するための柔軟性が、要求に基づいてプレイリストを動的に変更できる能力とともにもたらされる。

例として、或る特定のユーザにダウンロードされたコンテンツが、視聴者の位置に一般に近い地域の車販売店の広告のような、ユーザのプロフィールおよび／または位置の状況に対応した広告を含むことを考える。広告をその視聴者または位置に対して選択的に選ぶことができるだけでなく、プレイリストは無料の（例えば、プレミアム料金の支払いのない）視聴者が広告をスキップすることを拒否することができる。しかし、他のタイプのユーザ向けのような別のプレイリストでは、プレミアム加入契約者のような或る特定のユーザが自由に探索およびスキップができるようにしてもよい。ユーザの各々は所望のコンテンツを見るが、タイプの異なるユーザは、サーバに維持されているユーザの夫々のプレイリストに従って、コンテンツ（例えば、スキップか、否か）との異なる対話をすることができる。

さらに、コンテンツは部分的なコンテンツでダウンロードされるので、サーバは依然として制御する状態にあり、それにより、例えば、典型的な視聴プロセスを任意の時点でサーバ（または場合によってはプロバイダ１０６）により動的に変更することができる。これにより、通常のコンテンツの視聴に割り込んで、例えば、予想できない中断（例えば、スポーツ・イベント中のタイムアウト）の最中にコマーシャル広告を再生するか、または緊急気象警報を流す、等を行うことができる。サーバ制御を介して、コンテンツの再生を制御することもできる。例えば、同じ曲を１時間に４回以上再生することを防ぐといったように、ユーザが同じコンテンツを何度も何度も受け取ることを防ぐことができる。

複数のフォーマットを同じプレイリストにおいて指定してもよい。そして、クライアント１０２がコンテンツのためにフォーマットのタイプを（例えば、ユーザにより手動で、または自動化されたプロセスにより）選んでもよい。例えば、或るクライアントは「．ａｓｘ」でフォーマットされたプレイリストを求めるが、一方で別のクライアントは別のフォーマットのプレイリストを求めるかもしれない。そのプレイリストのフォーマットは拡張可能であることに留意されたい。例えば、特定の実装形態では「．ａｓｘ」をそのフォーマットとして使用してもよく、一方で、他の実装形態では独自のカスタム・クライアント側のプレイリスト・フォーマットを使用してもよい。さらに、プレイリストは異なるフォーマット・タイプである項目を含んでもよい。例えば、１つのプレイリストが「．ｗｍａ」、「．ｗｍｖ」、「．ｍｐ３」、等を有することもでき、ユーザまたはプロセスはそれらの中から選ぶことができる。

要約すると、このように、様々な態様および／または代替物の一部には、単一のプレイリストを介してコンテンツを複数のフォーマットで送信すること、および／または既存のクライアント側のプレイリスト・フォーマットを用いてコンテンツを送信することが含まれる。コンテンツはユーザ固有および位置固有であってもよく、さらに、コンテンツを動的なイベントに基づいて送信してもよい。例えば、竜巻警報を或る特定の位置にいるユーザ向けの他のコンテンツに重ねるか、または竜巻警報でそのコンテンツを置き換えてもよく、スポーツ・イベントの不測の途絶（例えば、雨天順延）を広告および／または予め録画したコンテンツ、等で補うことができ、状況に対応した制御および／または動的な制御を多数の異なるイベントおよび状況に適用してもよい。さらに他の態様には、サーバ側で制御されるメディア・コンテンツの送信を提供するための、拡張可能な解決策（solution）を構築する能力が含まれ、この拡張可能な解決策により、種々の解決策を、基本の解決策で公開された汎用なインタフェースを介して容易にカスタマイズすることができる。

図２は、部分的なコンテンツ項目を要求することを含む別の代替的な変形を示し、ここではサーバ２０４が、すべての要求をプレイリスト・プロバイダ２０６に問い合わせる。理解できるように、図２は適応性のあるプレイリストのための通信（呼出し）のフローを促進し、そのフローにおいて、プレイリスト・プロバイダ２０６および／またはサーバ２０４はクライアントへのコンテンツのフローを計算および／または制御するための機会を有する。図１に示すものと同様な制御ロジックと関連データ（例えば、プレイリストとセッション・データ）をサーバ２０４もしくはプロバイダ２０６で実装してもよく、または部分的にサーバ２０４でおよび部分的にプロバイダ２０６で実装してもよいことに留意されたい。図１と同様、サーバ２０４とプレイリスト２０６を結合されたサービスと考えてもよく、クライアントから見て両方ともサービスとして動作するように見える別々の実体であってもよい。従って、プレイリスト中の任意のエントリについて送信される実際のコンテンツ項目をプレイリスト・プロバイダ２０６によって変更し、著しい柔軟性を提供してもよい。この柔軟性は、適応性のあるシステムを構築することおよび／またはユーザの動作でコンテンツを変更することにおいて極めて有用である。例えば、広告を夫々の特定のクライアントの人口統計学的なプロフィールおよび／または現在位置だけではなくゲーム環境に基づいて選択することができ、あるいは他のコンテンツをユーザの動作に応じて変更することができ、ユーザはテレビまたは映画の最中にコンテンツと対話して購入（例えば、食べ物の配達の注文）等を行うことができる。

１つの実装形態の例、即ち、図３から図５に一般的に表すＩＩＳ（ＩｎｔｅｒｎｅｔＩｎｆｏｒｍａｔｉｏｎＳｅｒｖｅｒ＝インターネット・インフォメーション・サーバ）の実装形態においては、上の態様は、ＩＩＳウェブ・サーバ・プラットフォームに対するウェブ・プレイリストの解決策で提供されている。具体的な実装形態の例では、この特徴はＩＩＳ７の統合型パイプライン３２８を用いて実装されているが、これは、同様または同一の結果をもたらすために使用できたかもしれない幾つかの代替的な実装形態の１つにすぎないことは理解されよう。図５のブロック５０２と５０３は図１のクライアントおよびエンド・ユーザに対応することに留意されたい。しかし、このサーバの態様は後述するウェブ・プレイリスト・ハンドラ（モジュール）３３０で実装されている。このプレイリスト・ハンドラ３３０は（例えば、図４のウェブ・プレイリスト・プロバイダ４４０に対応する）デフォルト・プロバイダ５０６およびインターネット・インフォメーション・サービス・サーバ５０８とともに動作して、プレイリストおよび任意の必要なコンテンツを取得する。

図３および図４は、係るＩＩＳ７パイプライン３２８の例を一般に示す。このＩＩＳ７パイプライン３２８はウェブ・プレイリスト・ハンドラ３３０に結合され、ウェブ・プレイリスト・ハンドラ３３０はＷｅｂＰｌａｙｌｉｓｔプロバイダ４４０（図４）に結合される。ウェブ・プレイリストはＩＩＳ統合型パイプラインにおける要求ハンドラとして実装される。ＩＩＳ７はウェブ・プレイリストに対するハンドラ実行３３２（ＥｘｅｃｕｔｅＨａｎｄｌｅｒ）を呼び出し、ハンドラ実行３３２に要求データ（例えば、ＵＲＬにＵｓｅｒＳｅｓｓｉｏｎＤａｔａを加えたもの）を渡す。ハンドラ実行３３２をＩＩＳのネイティブ・コード・モジュールで書いてもよい。

図４は、一般に、ＷｅｂＰｌａｙｌｉｓｔをＩＩＳ７の機構の例と統合する態様に関する。サーバのコアでサポートされるように、非マネージ型のハンドラを使用してもよいことに留意されたい。図４では、ハンドラ実行３３２がパイプライン３２８内のブロックとして表されている。そのブロックにおいて、ＷｅｂＰｌａｙｌｉｓｔハンドラ・マッピングが、ＥｘｅｃｕｔｅＲｅｑｕｅｓｔＨａｎｄｌｅｒのパイプライン段階（pipeline stage）の間に要求処理サービスを提供するモジュールを指定する。このシステムでは、ウェブ・プレイリスト・ハンドラ３３０は、（他のＩＩＳモジュールが行うように）通知の登録を行い、それによって、ＩＩＳサーバはハンドラ・マッピングに基づいて通知をハンドラに送信する。１つの実装形態例では、ウェブ・プレイリスト・ハンドラ３３０は、要求を処理することを選択する場合は、ＥｘｅｃｕｔｅＲｅｑｕｅｓｔＨａｎｄｌｅｒの通知中にＨＡＮＤＬＥＤを返す。ウェブ・プレイリスト・ハンドラ３３０が要求を処理することを選択しない場合は、列に並んだ次のモジュールがそれを処理するために、ウェブ・プレイリスト・ハンドラ３３０がＣＯＮＴＩＮＵＥを返すことが期待される。

ユーザ・セッションに関して、ハンドラ３３０がクライアント要求に対してユーザ・セッションを開始し維持する。上述のように、ユーザ・セッションを使用して、ダウンロードしたバイトのようなデータを追跡し続け、プレイリストの属性を強制する。１つの特徴例では、クライアント側のプレイリストを介してサーバ側のプレイリストが実装されることに留意されたい。この実装形態では、プレイヤがプレイリストの属性を遵守できないか、またはクライアント側のプレイリストが編集されうる、といった可能性がある。

１つの実装形態例では、ハンドラ３３０は、要求を取得したらすぐにＧＵＩＤ等をセッション識別子として生成する。ユーザ・セッションはこのＧＵＩＤを介して識別され、ＧＵＩＤは通信中に渡される。要求への応答は、例えばビット・ストリームとして渡される、クライアント側のプレイリストを含む。クライアント側のプレイリストは、これらのＧＵＩＤを各メディア・エントリのＵＲＬの一部として有する、わかりにくくしたエントリを含むことができる。不正なソースにリンクされることに対してコンテンツを保護するような、ユーザ・セッションに対する保護機構を提供できることに留意されたい。例えば、ユーザが広告や映画のクリップを含むプレイリストを視る場合は、ユーザは別の方法でその映画のクリップのＵＲＬを傍受（intercept）して、そのＵＲＬをブログまたはフォーラムに投稿する（post）ことができる。係る不正なリンクからコンテンツを保護するために、サーバは、必ず１つのユーザ・セッションに対して限られた数の並列接続（例えば、２つの並列な接続であって、１つは現在の再生用、１つは次のエントリのプレローリング（ｐｒｅ−ｒｏｌｌｉｎｇ）用）のみが存在するようにすることができ、および／またはユーザ・セッションが幾分かの時間だけ使用されなかった後に終了するようにタイムアウト機構を有することができる。さらに、（ＵＲＬ内のＧＵＩＤのような）ユーザ・セッションのデータが何らかの方法で改竄された場合は、サーバはコンテンツを保護するために要求を破棄してもよい。

メディア・コンテンツの所有者により望ましい保護を与えることに関する他の態様には、プレイリストによって参照される１つまたは複数のメディア・コンテンツを、公開されたウェブ・サーバのＵＲＬ名前空間に配置する必要がないということが含まれる。係る状況では、クライアントが（ｈｔｔｐ：／／ｓｅｒｖｅｒ／ａｂｃ１２３．ｗｍｖのような）静的なファイルＵＲＬによってメディア・コンテンツに直接アクセスすることは不可能であり、コンテンツに到達するための唯一の方法はプレイリスト・ハンドラを介することであり、それにはプレイリストによって定義される規則に従うことが含まれる。サーバ側においては、特殊なユーザの証明書が必要な位置にコンテンツを置くことができ、それによって、サーバの管理者は、ウェブ・プレイリスト等のみがその位置にアクセスできるようにアクセス・オプションを構成することができる。

サーバ制御型のプレイリストは、また、プレイリスト中のコンテンツに対する不正なリンクを防止する。サーバ制御型のプレイリストにより、（複数のユーザがプレイリストのコンテンツの一部に対するリンクを直接に共有し他の制御を無視できる、従来式のプレイリストと対照的に）、上述の並列クライアント接続の制限およびセッション・タイムアウトのような強制機構のため、プレイリストのコンテンツのＵＲＬをクライアント間で直接に共有することは不可能である。

さらに、通常のクライアントが同じコンテンツをローカル・キャッシュから再生できないように、コンテンツをプレイリストから提供する場合はクライアント側でのキャッシュを無効にしてもよい。係る機構では、クライアントは所望のコンテンツを毎回サーバから要求しなければならない。コンテンツをキャッシュするようにクライアントを修正することは可能であるので、これは通常のユーザに部分的な保護を提供するにすぎないことに留意されたい。しかし、より包括的にコンテンツを保護するために、ＤＲＭ（ｄｉｇｉｔａｌｒｉｇｈｔｓｍａｎａｇｅｍｅｎｔ＝デジタル著作権管理）技術をウェブ・プレイリストと関連して使用することができる。

上述のように、図５はＩＩＳ実装形態またはウェブ・プレイリスト・プロバイダの例に対する通信呼出しの流れの例を示す。非マネージ型のプロバイダ・サポートとマネージ型のプロバイダ・サポートの両方に対するサポートが存在しうることに留意されたい。例えば、デフォルト・プロバイダ５０６は、ＸＭＬプレイリストの構文に対するサポートを提供し、またＷｉｎｄｏｗｓ（登録商標）のユーザおよびグループと統合することができる「そのまま使える形態の製品(shipped out of the box)」を含む。デフォルト・プロバイダ５０６は、ＳｅｒｖｅｒＣｏｒｅインストール上で動作させるために、非マネージ型であってもよい。デフォルト・ウェブ・プレイリスト・プロバイダ５０６は、プレイリストを適切な（例えば、ＸＭＬベースの）形式でバックエンドに記憶することができる。

プレイリスト・ストア４４４（図４）に関して、デフォルト・プロバイダ５０６に対する１つの適切なデータベースが「．ｃｏｎｆｉｇ」ファイルを含む。プレイリストに対するサイズの例は、現在は、１００ＫＢから２５０ＫＢのオーダである。

デフォルト・プロバイダ５０６は上述のシナリオの幾つかを、宣言的な構文（declarative syntax）を用いて実現できることに留意されたい。例えば、パターンを可能とする構成部を書くことができる。次いで、これらのパターンをメディア・コンテンツ上のタグと合致させ、ユーザまたは位置の属性に基づいて正確なメディア・コンテンツを取り出すことができる。

拡張可能性に関して、カスタム・プロバイダによりプレイリストのサポートを拡張できることは容易に理解されよう。これは、クッキー、ＵＲＬ修正子、ＩＰアドレス、ユーザ・プロフィール属性、グループ属性、ロール、等を使用してユーザ固有および／または位置固有のコンテンツを提供する場合のように、非常に価値があるものでありうる。カスタム・プロバイダをマネージ・コードまたは非マネージ・コードで書いてもよい。しかし、マネージ・コードで書いた方が、典型的により速くて簡単であり、それによって、マネージ型のカスタム・プロバイダをもつことによってコミュニティが関与する機会が増える。

要約として、図６は、例えばサーバがコンテンツに対するクライアントの要求を認証して返すような、図１および図５の例に対応する例示的なサーバの視点から見たフロー図である。図７は、例えばプロバイダが要求された（またはその他の）コンテンツの返すことに関与するような、図２の例に対応する例示的なサーバおよびプロバイダの視点から見た流れ図である。

図６では、ステップ６０２から開始して、サーバがウェブ・プレイリストを求めるクライアント要求を受け取る。次いで、サーバはユーザのセッションを作成し（ステップ６０４）、プレイリストをプロバイダに要求し（ステップ６０６）、その応答でプレイリストを受け取り（ステップ６０８）、プレイリストをクライアントに返す（ステップ６１０）。ステップ６１２で表すように、サーバは次いでさらなるクライアント要求を待つ。ステップ６１２から分岐する点線で示すように、サーバは、クライアントが所定の時間内に適切な要求を返さない場合は、タイムアウトを発行してセッションを終了させることができることに留意されたい。

ステップ６１２で判るように、クライアント要求を受け取ると、さらに処理が継続する。この例では、ステップ６１４で、サーバは、最初にクライアント要求と無関係に返される緊急警報のような、クライアントのコンテンツ要求に優先する、サーバが（少なくともこの特定のクライアントに関して）認識する特殊な状況があるかどうかを考慮する。そのような状況があれば、ステップ６１６は対応する特殊なコンテンツを返す。１つの代替手段では、ステップ６１４は、緊急警報のような特殊なコンテンツをクライアント要求と独立なクライアントに送信するために（例えば、ステップ６１２の前に）待機ループ内にあってもよいが、クライアントを係る送信されたコンテンツを受け入れるように構成する必要があろうことに留意されたい。別の代替手段では、サーバは（例えば、ステップ６２６で返すべき）隣接するビデオ・コンテンツの別の部分にグラフィック等を重ねる（superimpose）かまたは挿入することができ、従ってメインまたは他のビデオ・コンテンツを中段することなく特殊なコンテンツを提供することができる。

特殊な状況がない場合は、ステップ６１８で、クライアントの要求がセッションの終了に対応するかどうかを評価する。例えば、クライアントは、プレイリストをレビューした後に、コンテンツを求めないような場合は明示的にログアウトしてもよく、または、無料プレビューに続き購入しないことに決定した場合のように、これ以上コンテンツはいらないと示してもよい。ステップ６１８はセッションの終了を例示するが、追加の代替手段は、クライアントが異なるコンテンツをプレイリストから選択するための機構、またはセッションを終了せずに新しいプレイリストを要求するための機構を提供することであることに留意されたい。

クライアントがコンテンツを要求し、ステップ６１８の「いいえ」分岐を辿る場合は、ステップ６２０は、クライアントが要求を行う権限を有することを示すＧＵＩＤまたは他の証明書のようなクライアント要求を認証することを表し、ステップ６１８の「いいえ」分岐を辿らない場合は、要求は拒否される（ステップ６２４）。認証された場合は、ステップ６２２は要求されたコンテンツとプレイリストとを比較する。例えば、プレイリストが、広告を視ることを条件に無料で番組を視聴しているクライアントのような特定のクライアントは（例えば、プレミアム・レベルのクライアントと反対に）コンテンツを早送りできずコンテンツを完全に且つ順番通りに受け取ることが要求されることを示してもよい。係る例において、クライアントの要求が、正しい順序より先んじているプレイリスト上のコンテンツを受け取ることに関する場合は、その要求は拒否される（ステップ６２４）。クライアントが前方にスキップすることが許されない場合でも、プレイリストは単一プログラム内のコンテンツの様々な部分に対するエントリを含むことができ、その結果、クライアントは、例えば前の部分に巻き戻すか、または既に受け取ったコンテンツ内で早送りすることができる。

図７は幾分図６と類似しているが、これらのステップの例では、プロバイダは（図２と同様に）コンテンツの項目の提供に関与していることが分かる。本例では、ステップ７０２からステップ７１２は図６のステップ６０２からステップ６１２に対応し、ステップ７１４はステップ６１８に対応し、従って簡単のためこれらのステップは再度説明しないことに留意されたい。さらに、図７には示していないが、サーバは、図６のステップ６１４と同様な特殊な場合のように、必要ならば自身のコンテンツを置き換えることができるが、この例では、プロバイダもまた係る能力を有する。

ステップ７１６でクライアントを認証し、ステップ７１８でプレイリストに従ってクライアントの要求を許可した場合、ステップ７２２でサーバは対応するコンテンツに対する要求を計算し、その要求をプロバイダに送信する。クライアントの要求が許可されない場合は、サーバは要求を拒否することができる（ステップ７２０）。サーバはプロバイダが返すコンテンツの項目であればどのようなものでも受け取り、その項目をクライアントに転送する。容易に理解できるように、ステップ７２２での計算、および／またはコンテンツの項目を選択的に返すプロバイダの能力により、適応性のあるシステムが可能となる。

理解できるように、本明細書では様々且つ柔軟な方法で、メディア・コンテンツをウェブから制御された形で送信することが説明されている。本明細書で説明されるように、メディア・コンテンツの制御された送信を使用することで、金銭的価値化（monetization）および／または遵守（compliance）を含むシナリオが可能となる。

例示的な動作環境
図８は、図１から図７の例を実装するのに適したコンピューティング環境およびネットワーキング環境８００の例を示す（例えば、サーバおよび／またはプロバイダをコンピュータ８１０に実装することができ、クライアントをリモート・コンピュータ８８０とすること、あるいはその逆とすることができる）。コンピューティング・システム環境８００は適切なコンピューティング環境の１例にすぎず、本発明の使用範囲または機能範囲に関する限定を示唆しようとするものではない。また、コンピューティング環境８００が、例示的な動作環境８００に示す構成要素のどのような１つまたはどのような組合せに関してどのような依存性または要件を有するとも解釈すべきでない。

本発明は、他の多数の汎用または特殊用途のコンピューティング・システムの環境または構成で動作する。本発明で使用するのに適しうる良く知られたコンピューティング・システム、環境、および／または構成の例には、パーソナル・コンピュータ、サーバ・コンピュータ、ハンドヘルドまたはラップトップ装置、タブレット装置、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラム可能消費家電、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ、上記のシステムまたは装置の何れかを含む分散コンピューティング環境、等が含まれるがこれらに限らない。

本発明を、プログラム・モジュールのような、コンピュータによって実行されているコンピュータ実行可能命令の一般的なコンテキストで説明することができる。一般に、プログラム・モジュールには、特定のタスクを実行するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等が含まれる。本発明を、通信ネットワークを通して接続されたリモート処理装置によりタスクが実行される分散コンピューティング環境で実施してもよい。分散コンピューティング環境では、プログラム・モジュールを、メモリ記憶装置を含む、ローカルおよび／またはリモートのコンピュータ記憶媒体に配置してもよい。

図８を参照すると、本発明の様々な態様を実装するための例示的なシステムは、汎用コンピューティング装置をコンピュータ８１０の形で含むことができる。コンピュータ８１０のコンポーネントは、これらには限定されないが、演算装置８２０、システム・メモリ８３０、およびシステム・バス８２１を含む。システム・バス８２１は、システム・メモリを含む様々なシステム・コンポーネントを演算装置８２０に結合させる。システム・バス８２１は、メモリ・バスまたはメモリ・コントローラ、周辺バス、および様々なバス・アーキテクチャの何れかを用いたローカル・バスを含む、数種のバス構造のうちの何れかで可能である。限定ではなく例として、係るアーキテクチャには、ＩＳＡ（ＩｎｄｕｓｔｒｙＳｔａｎｄａｒｄＡｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（ＭｉｃｒｏＣｈａｎｎｅｌＡｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（ＥｎｈａｎｃｅｄＩＳＡ）バス、ＶＥＳＡ（ＶｉｄｅｏＥｌｅｃｔｒｏｎｉｃｓＳｔａｎｄａｒｄｓＡｓｓｏｃｉａｔｉｏｎ）ローカル・バス、およびメザニン・バスとしても知られるＰＣＩ（ＰｅｒｉｐｈｅｒａｌＣｏｍｐｏｎｅｎｔＩｎｔｅｒｃｏｎｎｅｃｔ）バス、等が含まれる。

コンピュータ８１０は、典型的には、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ８１０がアクセスできる任意の利用可能な媒体でよく、揮発性および不揮発性媒体、取外し可能および取外し不能媒体の両方を含む。限定ではなく例として、コンピュータ可読媒体はコンピュータ記憶媒体と通信媒体を備えることができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラム・モジュールまたは他のデータのような情報を記憶するための任意の方法または技術で実装した揮発性および不揮発性媒体、取外し可能および取外し不能媒体の両方が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌｖｅｒｓａｔｉｌｅｄｉｓｋ）もしくは他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶もしくは他の磁気記憶装置、または所望の情報の記憶に使用できコンピュータ８１０がアクセスできる他の任意の媒体が含まれるがこれらに限らない。通信媒体は、典型的には、コンピュータ可読命令、データ構造、プログラム・モジュールまたは他のデータを搬送波または他の伝送機構のような変調データ信号に具現化し、任意の情報伝達媒体を含む。「変調データ信号」という用語は、１つまたは複数のその特性集合を有するか、信号内の情報をエンコードするよう変化した信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークまたは直接配線接続のような有線媒体、ならびに音響、ＲＦ、赤外線および他の無線媒体のような無線媒体が含まれる。上の何れかの組合せもコンピュータ可読媒体の範囲内に含むことができる。

システム・メモリ８３０は、コンピュータ記憶媒体をＲＯＭ（ｒｅａｄｏｎｌｙｍｅｍｏｒｙ）８３１およびＲＡＭ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ）８３２のような揮発性メモリおよび／または不揮発性メモリの形で備える。ＢＩＯＳ（ｂａｓｉｃｉｎｐｕｔ／ｏｕｔｐｕｔｓｙｓｔｅｍ）８３３は、例えば起動中に、コンピュータ８１０内部の要素間での情報伝送を支援する基本ルーチンを含み、典型的にはＲＯＭ８３１に記憶される。ＲＡＭ８３２は、典型的には演算装置８２０が即座にアクセス可能であるデータおよび／または現在演算装置８２０上で動作しているプログラム・モジュールを含む。限定ではなく例として、図８はオペレーティング・システム８３４、アプリケーション・プログラム８３５、他のプログラム・モジュール８３６およびプログラム・データ８３７を示す。

コンピュータ８１０は、また他の取外し可能または取外し不能のコンピュータ記憶媒体、揮発性または不揮発性のコンピュータ記憶媒体を含むことができる。例としてのみ、図８は取外し不能で不揮発性の磁気媒体を読み書きするハード・ディスク・ドライブ８４１、取外し可能で不揮発性の磁気ディスク８５２を読み書きする磁気ディスク・ドライブ８５１、およびＣＤＲＯＭまたは他の光媒体のような取外し可能で不揮発性の光ディスク８５６を読み書きする光ディスク・ドライブ８５５を示す。例示的な動作環境で使用できる他の取外し可能または取外し不能のコンピュータ記憶媒体、揮発性または不揮発性のコンピュータ記憶媒体には、磁気テープ・カセット、フラッシュ・メモリ・カード、デジタル多用途ディスク、デジタル・ビデオ・テープ、固体ＲＡＭ、固体ＲＯＭ、等が含まれるがこれらに限らない。ハード・ディスク・ドライブ８４１は、典型的には、インタフェース８４０のような取外し不能なメモリ・インタフェースを介してシステム・バス８２１に接続され、磁気ディスク・ドライブ８５１および光ディスク・ドライブ８５５は、典型的には、インタフェース８５０のような取外し可能メモリ・インタフェースによってシステム・バス８２１に接続される。

上で論じ、図８で示したドライブおよびその関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラム・モジュール、および他のデータをコンピュータ８１０のために記憶する。図８では、例えば、ハード・ディスク・ドライブ８４１がオペレーティング・システム８４４、アプリケーション・プログラム８４５、他のプログラム・モジュール８４６、およびプログラム・データ８４７を記憶するとして示してある。これらの構成要素はオペレーティング・システム８３４、アプリケーション・プログラム８３５、他のプログラム・モジュール８３６、およびプログラム・データ８３７と同一であるかまたは異なることができることに留意されたい。オペレーティング・システム８４４、アプリケーション・プログラム８４５、他のプログラム・モジュール８４６、およびプログラム・データ８４７には本明細書では異なる番号を与え、最低限それらが異なるものであることを示す。ユーザは、タブレット、または電子デジタイザ（ｅｌｅｃｔｒｏｎｉｃｄｉｇｉｔｉｚｅｒ）８６４、マイクロフォン８６３、キーボード８６２および通例的には、マウス、トラックボールまたはタッチ・パッドと呼ばれるポインティング・デバイス８６１のような入力装置を介して、コンピュータ８１０にコマンドおよび情報を入力することができる。図８に示していない他の入力装置にはジョイスティック、ゲーム・パッド、パラボラ・アンテナ、スキャナ、等を含めることができる。これらおよび他の入力装置は、しばしば、システム・バスに結合されたユーザ入力インタフェース８６０を介して演算装置８２０に接続されるが、パラレル・ポート、ゲーム・ポートまたはＵＳＢ（ｕｎｉｖｅｒｓａｌｓｅｒｉａｌｂｕｓ）のような他のインタフェースおよびバス構造によって接続してもよい。モニタ８９１または他のタイプの表示装置も、ビデオ・インタフェース８９０のようなインタフェースを介してシステム・バス８２１に接続される。また、モニタ８９１はタッチ・スクリーン・パネル等と統合できる。モニタおよび／またはタッチ・スクリーン・パネルを、タブレット・タイプのパーソナル・コンピュータのような、コンピューティング装置８１０が組み込まれる筐体に物理的に結合できることに留意されたい。さらに、コンピューティング装置８１０のようなコンピュータは、スピーカ８９５およびプリンタ８９６のような他の周辺出力装置も含むことができ、これらは出力周辺インタフェース８９４等を介して接続することができる。

コンピュータ８１０は、リモート・コンピュータ８８０のような１つまたは複数のリモート・コンピュータへの論理接続を用いてネットワーク環境で動作することができる。リモート・コンピュータ８８０はパーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイスまたは他の共通ネットワーク・ノードが可能で、典型的には、コンピュータ８１０に関して上述した要素の多くまたは全てを含むが、図８ではメモリ記憶装置８８１のみを示した。図８に示した論理接続には１つまたは複数のＬＡＮ（ｌｏｃａｌａｒｅａｎｅｔｏｗｏｒｋ）８７１および１つまたは複数のＷＡＮ（ｗｉｄｅａｒｅａｎｅｔｗｏｒｋ）８７３が含まれるが、他のネットワークを含んでもよい。係るネットワーキング環境は、職場、企業規模のコンピュータ・ネットワーク、イントラネットおよびインターネットにおいて珍しいものではない。

ＬＡＮネットワーキング環境で使用する場合は、コンピュータ８１０はネットワーク・インタフェースまたはアダプタ８７０を通してＬＡＮ８７１に接続される。ＷＡＮネットワーキング環境で使用する場合は、コンピュータ８１０は、典型的には、モデム８７２、またはインターネットのようなＷＡＮ８７３上で通信を確立するのに適した他の技術を含む。モデム８７２は、内部または外部で可能であり、ユーザ入力インタフェース８６０または他の適切な機構を介してシステム・バス８２１に接続することができる。インタフェースおよびアンテナを備えるような無線ネットワーキング・コンポーネント８７４を、アクセス・ポイントまたはピア・コンピュータのような適切な装置を通してＷＡＮまたはＬＡＮに結合することができる。ネットワーク環境では、コンピュータ８１０に関して図示したプログラム・モジュールまたはその一部を、リモート・メモリ記憶装置に記憶することができる。限定ではなく例として、図８はリモート・アプリケーション・プログラム８８５がメモリ装置８８１に常駐するとして示してある。示したネットワーク接続は例であって、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは理解されよう。

（例えば、コンテンツを補助的に表示するための）補助サブシステム８９９をユーザ・インタフェース８６０を介して接続して、プログラム・コンテンツ、システムの状況、およびイベントの通知を、コンピュータ・システムの主要部分が低電力状態にある場合でも、ユーザに提供することができる。補助サブシステム８９９をモデム８７２および／またはネットワーク・インタフェース８７０に接続して、メインの演算装置８２０が低電力状態にある間に、これらのシステム間の通信を可能にできる。

むすび
本発明に様々な修正を加え代替的に構築することが可能であるが、その幾つかの例示的な実施形態が図面で示されており、上で詳細に説明されている。しかし、本発明を開示した特定の形態に限定しようとする意図はなく、本発明は、本発明の趣旨および範囲内にある全ての修正物、代替的な構築物、および均等物を含むことは理解されよう。

Claims

ネットワーキング環境において実施される方法であって、
メディア・コンテンツの部分を求める要求をネットワーク・クライアントから受け取るステップ（６１２、７１２）と、
前記要求に応答して、メディア・コンテンツの部分を前記クライアントに制御可能に送信するステップ（６２６、７２４）であって、前記要求の少なくとも１つに対して、前記クライアントがその要求に対応するメディア・コンテンツの特定部分を受け取ることができるかどうかを判定するステップ（６２２、７１８）および、受け取ることができる場合にメディア・コンテンツのその特定部分を送信するステップ（６２６、７２４）と
を含むことを特徴とする方法。
前記ネットワーク・クライアントに対してセッションを作成するステップ（６０４、７０４）と、そのセッションに対応するセッション関連データを維持するステップとをさらに含むことを特徴とする請求項１に記載の方法。
前記クライアントがメディア・コンテンツの特定部分を受け取ることができるかどうかを判定する前記ステップは、前記特定のメディア・コンテンツを求める前記クライアント要求を認証するステップ（６２０、７１６）を含むことを特徴とする請求項１に記載の方法。
前記クライアントがメディア・コンテンツの特定部分を受け取ることができるかどうかを判定する前記ステップは、前記クライアントに送信されたメディア・コンテンツの他の少なくとも１つの部分を追跡するステップ（６２２、７１８）を含むことを特徴とする請求項１に記載の方法。
前記クライアントがメディア・コンテンツの特定部分を受け取ることができるかどうかを判定する前記ステップは、前記クライアントに関連付けられたプレイリストを評価するステップ（６２２、７１８）を含むことを特徴とする請求項１に記載の方法。
メディア・コンテンツを動的な条件に基づいて前記クライアントに送信するステップ（６１６）をさらに含むことを特徴とする請求項１に記載の方法。
前記クライアントがメディア・コンテンツの特定部分を受け取ることができると判定され、メディア・コンテンツの前記特定部分は複数の広告のうち１つの広告を含み、
前記方法は、前記クライアントに関連付けられたユーザ・プロフィール情報（１１６）に基づいて、または前記クライアントに関連付けられた位置情報（１１６）に基づいて、または前記クライアントに関連付けられたユーザ・プロフィール情報と位置情報の組合せ（１１６）に基づいて、前記広告を前記複数の広告の中から選択するステップをさらに含むことを特徴とする請求項１に記載の方法。
コンピュータ・ネットワーキング環境において実施される方法であって、
クライアントによるメディア・コンテンツの送信を制御するステップであり、メディア・コンテンツを求めるクライアント要求に応答して部分的なメディア・コンテンツを前記クライアントに選択的に送信すること（６２６、７２４）を含む、ステップと、
他のメディア・コンテンツを求める追加のクライアント要求を処理するステップであり、前記クライアントに前に通信してあるメディア・コンテンツ（１１２）の追跡に基づいて処理するステップと
を含むことを特徴とする方法。
他のメディア・コンテンツを求める前記追加のクライアント要求を処理する前記ステップは、
どのメディア・コンテンツが前にセッション中に前記クライアントへ送信されているかを示すセッション・データ（１１２）を維持するステップと、
前記クライアントに関連付けられたプレイリスト内の情報を評価して、メディア・コンテンツを求める前記追加の要求の１つに対応する他の部分的なメディア・コンテンツをその要求に応答して送信できるかどうかを判定するステップ（６２２、７１８）と
を含むことを特徴とする請求項８に記載の方法。
前記プレイリストを動的に適合させるステップ（６１４、６１６、７２４）をさらに含むことを特徴とする請求項９に記載の方法。
前記クライアント要求に応答して前記部分的なメディア・コンテンツを前記クライアントに選択的に送信する前記ステップは、動的な条件に基づいてコンテンツを選択するステップ（６１４、６１６、７２４）を含むことを特徴とする請求項８に記載の方法。
前記部分的なメディア・コンテンツを前記クライアントに選択的に送信する前記ステップは、メディア・コンテンツ・プロバイダと通信してメディア・コンテンツ項目を受け取るステップ（７２２）と、メディア・コンテンツを求める前記クライアント要求に応答して受け取ったメディア・コンテンツ項目を返すステップ（７２４）を含むことを特徴とする請求項８に記載の方法。
メディア・コンテンツの送信を制御する前記ステップは、クライアントの位置データ（１１６）またはクライアントのプロフィール・データ（１１６）に少なくとも部分的に基づいて、またはクライアントの位置データとクライアントのプロフィール・データの両方に少なくとも部分的に基づいて、メディア・コンテンツを提供するステップを含むことを特徴とする請求項８に記載の方法。
コンピューティング環境におけるシステムであって、
メディア・コンテンツをクライアント（１０２）に送信することに関してセッションを確立するサーバ（１０４）を備え、前記サーバは、前記要求が許可されるか拒否されるかを判定するために、部分的なメディア・コンテンツを求めるクライアント要求を、前記クライアントに関連付けられたデータ（１１２、１１６）に対して評価する制御ロジック（１１４）に結合されていることを特徴とするシステム。
前記制御ロジックは、前記サーバ（１０４）を構成するサービス、またはプレイリスト・プロバイダ（１０６）を構成するサービス、または前記サーバ（１０４）と前記プレイリスト・プロバイダ（１０６）を構成するサービスに組み込まれていることを特徴とする請求項１４に記載のシステム。
前記サーバに結合されたプレイリスト・プロバイダ（１０６）をさらに備え、前記クライアントに関連付けられた前記データは前記プレイリスト・プロバイダによって提供されたプレイリスト（１１８）を含むことを特徴とする請求項１４に記載のシステム。
前記プレイリスト・プロバイダに結合されたメディア・コンテンツのソース（１０８）をさらに備えることを特徴とする請求項１６に記載のシステム。
前記クライアントに関連付けられた前記データは、前記セッションに関する情報を追跡するセッション・データ（１１２）を含み、前記制御ロジック（１１４）は、追加の要求が許可されるかどうかの判定において前記セッション・データの少なくとも一部をプレイリスト（１１８）に対して評価することを特徴とする請求項１４に記載のシステム。
コンテンツの追加部分のうち少なくとも１つは広告であることを特徴とする請求項１４に記載のシステム。
前記クライアントに関連付けられたユーザ・プロフィール情報（１１６）に基づいて、または前記クライアントに関連付けられた位置情報（１１６）に基づいて、または前記クライアントに関連付けられたユーザ・プロフィール情報と位置情報の組合せ（１１６）に基づいて、前記広告を前記複数の広告の中から選択するための手段をさらに備えることを特徴とする請求項１９に記載のシステム。