特許 6742912 Ｐ２Ｐコンテンツ配信ネットワーク、方法、および管理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6742912

(24)【登録日】2020年7月31日

(45)【発行日】2020年8月19日

(54)【発明の名称】Ｐ２Ｐコンテンツ配信ネットワーク、方法、および管理システム

(51)【国際特許分類】

   G06F 13/00 20060101AFI20200806BHJP

【ＦＩ】

   G06F13/00 520C

【請求項の数】6

【全頁数】35

(21)【出願番号】特願2016-557542(P2016-557542)

(86)(22)【出願日】2014年12月8日

(65)【公表番号】特表2017-504134(P2017-504134A)

(43)【公表日】2017年2月2日

(86)【国際出願番号】US2014069067

(87)【国際公開番号】WO2015085296

(87)【国際公開日】20150611

【審査請求日】2017年12月7日

(31)【優先権主張番号】14/099,348

(32)【優先日】2013年12月6日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】516166122

【氏名又は名称】リークリー，グレゴリー，エイチ．

【氏名又は名称原語表記】ＬＥＥＫＬＥＹ，Ｇｒｅｇｏｒｙ，Ｈ．

(73)【特許権者】

【識別番号】516166133

【氏名又は名称】サヴェノク，アレクサンダー

【氏名又は名称原語表記】ＳＡＶＥＮＯＫ，Ａｌｅｘａｎｄｅｒ

(73)【特許権者】

【識別番号】516166144

【氏名又は名称】サヴェノク パヴェル

【氏名又は名称原語表記】ＳＡＶＥＮＯＫ，Ｐａｖｅｌ

(74)【代理人】

【識別番号】100079980

【弁理士】

【氏名又は名称】飯田 伸行

(74)【代理人】

【識別番号】100167139

【弁理士】

【氏名又は名称】飯田 和彦

(72)【発明者】

【氏名】リークリー，グレゴリー，エイチ．

(72)【発明者】

【氏名】サヴェノク，アレクサンダー

(72)【発明者】

【氏名】サヴェノク パヴェル

【審査官】 今川 悟

(56)【参考文献】

【文献】 特開２００９−１６３６９８（ＪＰ，Ａ）

【文献】 特開２００４−１８５２６３（ＪＰ，Ａ）

【文献】 特開２００９−２４６８１７（ＪＰ，Ａ）

【文献】 特開２００７−２９３７０４（ＪＰ，Ａ）

【文献】 特開２００２−３７３１３３（ＪＰ，Ａ）

【文献】 特表２００７−５０２５６０（ＪＰ，Ａ）

【文献】 特表２０１１−５０２４１２（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００４／００３１０３８（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１２／０１５０９４５（ＵＳ，Ａ１）

【文献】 モバイル向けＰ２Ｐネットワークのアーキテクチャとプロトコルの提案，マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ）シンポジウム論文集 １９９７年〜２００６年版，日本，社団法人情報処理学会，２００２年 ７月 ３日，第2002巻 第9号，41〜44

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

初めにデータを発信したデータ発信源が特定されていないピアデータの中の選ばれた選択データファイルをエンド・ユーザーに最適に配信する動作環境を備えたコンピュータを有するコンピュータ群の中で、データを配信する方法において、
イベント待ち行列でリモート・イベント・データベース（１８６）を連続してアップデートさせるソフトウエアであるイベント・マーカー対応ソフトウエアを備え且つ実行させる第１コンピュータ（１６３）および前記イベント・マーカー対応ソフトウエアを利用して、選択データファイルのフレーム・ヘッダー内でイベント・マーカーを対応付けるステップと、
クライアントコンピュータ（１７２、１９３）と、ピア・ツー・ピア・ゲートウェイ・サーバー（１５０、１８４、１９５）と、リモート・イベント・データベース（１８６）と、前記コンピュータ群のネットワークに備えたコンテンツ配信ネットワークのリモート・サーバー（１８５）とがあって、これらが前記ピア・ツー・ピア・ゲートウェイ・サーバー（１５０、１８４、１９５）に前記リモート・イベント・データベース（１８６）から前記イベント待ち行列をロードするために交信するステップと、
前記コンテンツ配信ネットワークのリモート・サーバー（１８５）を介して、前記コンピュータ群のネットワークの中でデータ・リソース保存場所をキャッシュするステップと、
前記コンテンツ配信ネットワークのリモート・サーバー（１８５）によってキャッシュされた前記データ・リソース保存場所に対して、前記ピア・ツー・ピア・ゲートウェイ・サーバー（１５０、１８４、１９５）が最適なデータ・リソース保存場所をリクエストするステップと、
前記コンテンツ配信ネットワークのリモート・サーバー（１８５）を介して、前記最適なデータ・リソース保存場所についてのリソースリクエストを解決するステップと、
前記コンテンツ配信ネットワークのリモート・サーバー（１８５）を介して、前記ピア・ツー・ピア・ゲートウェイ・サーバー（１８４）が前記最適なデータ・リソース保存場所を受け取るステップと、
を有しており、さらに、
前記選択データファイルを転送する機能を拡張するための前記イベント・マーカー対応ソフトウエアを利用したうえで、前記受け取った前記最適なデータ・リソース保存場所を介して、前記コンピュータ群のネットワークに対して前記選択データファイルをリクエストするステップを有し、そして、
前記受け取った前記最適なデータ・リソース保存場所を介して、前記コンピュータ群のネットワークから、前記リクエストされた前記選択データファイルを伝送するステップと、
この伝送された前記選択データファイルを、前記クライアントコンピュータ（１７２、１９３）向けに配信する選択データファイルとして特定するステップと、
を有することを特徴とする方法。

【請求項2】

請求項１に記載の方法において、下記(a)〜(d)を提供するステップを含む方法。
(ａ)使用レポート、(ｂ)複数の契約タイプについて、コンテンツ・コントローラで認めた権利、印税率、クリアランス・ステータス及び使用を、メディア・アセット毎に変更する権利モジュールのコンプライアンス・ダッシュボード、(ｃ)すべてのレポート必要条件のアカウント、(ｄ)前記権利モジュールのコンプライアンス・ダッシュボードに入力された率に基づいて日付範囲、コンテンツ・ソース・タイプおよびコンテンツ・プロバイダー毎の利用状況データを総合して、所有されているロイヤルティーを計算するためのロイヤルティー計算エンジン。

【請求項3】

請求項１あるいは請求項２に記載の方法において、
前記イベント・マーカー対応ソフトウエアによって広告コンテンツをデータファイルに組み込むステップを有する方法。

【請求項4】

選択されたデータファイルをユーザーに配信するコンテンツ配信ネットワークにおいて、
このコンテンツ配信ネットワークは、第１コンピュータ（１６３）によって実行されるイベント・マーカー対応ソフトウエアと、クライアントコンピュータ（１７２、１９３）と、ピア・ツー・ピア・ゲートウェイ・サーバー（１５０、１８４、１９５）と、コンピュータネットワークを構成するコンピュータ群の中で交信するコンテンツ配信ネットワークのリモート・サーバー（１８５）とを備え、
そして、前記コンテンツ配信ネットワークのリモート・サーバー（１８５）は、
（１）前記コンピュータ群のコンピュータネットワークの中でデータ・リソース保存場所をキャッシュする機能と、（２）前記コンピュータ群のコンピュータネットワークの中で最適なデータ・リソース保存場所でリソースリクエストを解決する機能と、
を有しており、さらに、
前記ピア・ツー・ピア・ゲートウェイ・サーバー（１５０、１８４、１９５）は、
（１）コンテンツ配信ネットワークのリモート・サーバー（１８５）を介して、最適なデータ・リソース保存場所をリクエストし、かつこれを受け取る機能と、（２）前記最適なデータ・リソース保存場所を介して、前記コンピュータ群のコンピュータネットワークに対してデータファイルをリクエストし、かつこれを受け取る機能と、（３）データファイルの転送機能を拡張するために、このデータファイルのフレーム・ヘッダー内にイベント・マーカーを対応付けるように、前記第１コンピュータ（１６３）によって実行される前記イベント・マーカー対応ソフトウエアを用いて、この受け取ったデータファイルを前記クライアントコンピュータ（１７２、１９３）向けに配信するデータファイルとして特定する機能と、
を有することを特徴とするコンテンツ配信ネットワーク。

【請求項5】

クライアントコンピュータ（１７２、１９３）を少なくとも一つ有し、さらに、ピア・ツー・ピア・ゲートウェイ・サーバー（１５０、１８４、１９５）と、コンテンツ配信ネットワークのリモート・サーバー（１８５）、および、コンピュータネットワークを構成するコンピュータ群を有したコンテンツ配信ネットワークにおいて、
前記クライアントコンピュータ（１７２、１９３）と、前記ピア・ツー・ピア・ゲートウェイ・サーバー（１５０、１８４、１９５）と、前記コンテンツ配信ネットワークのリモート・サーバー（１８５）と、コンピュータネットワークを構成するコンピュータ群とは一体に協働して下記（Ａ）および（Ｂ）の機能を備えたことを特徴とするコンテンツ配信ネットワーク。
（Ａ）として、（Ａ１）ローカル・サーバー、（Ａ２）ピア・コネクテッド・サーバー及び（Ａ３）第２のクライアントコンピュータ（１７２、１９３）から間接的に受けるリクエストによって要求されるストリーミング・サービス・プロバイダー（１３２）、があり、（Ａ１）〜（Ａ３）の内のいずれかから第１のクライアントコンピュータ（１７２、１９３）にストリームを配信する機能、
（Ｂ）として、（Ｂ１）ストリーミング・サービス・プロバイダー（１３２）あるいは、（Ｂ２）第１のクライアントコンピュータ（１７２、１９３）から直接的に受けるリクエストによって要求されるピア・コネクテッド・サーバー、があり、（Ｂ１）あるいは（Ｂ２）から前記第１のクライアントコンピュータ（１７２、１９３）にストリームを配信する機能。

【請求項6】

請求項５に記載のコンテンツ配信ネットワークにおいて、コンテンツの配信が前記（Ａ）および（Ｂ）を含む配信の機能に従い、元のリクエストされたソース・サービス以外の二次的なソースを元にする場合、(ａ)使用レポート、(ｂ)複数の契約タイプについて、コンテンツ・コントローラで認めた権利、印税率、クリアランス・ステータス及び使用を、メディア・アセット毎に変更する権利モジュールのコンプライアンス・ダッシュボード、(ｃ)すべてのレポート必要条件のアカウント、および、(ｄ)前記権利モジュールのコンプライアンス・ダッシュボードに入力された率に基づいて日付範囲、コンテンツ・ソース・タイプおよびコンテンツ・プロバイダー毎の利用状況データを総合して、所有されているロイヤルティーを計算するためのロイヤルティー計算エンジン、を提供するコンプライアンス・サーバー（１４３）を含むコンテンツ配信ネットワーク。

【発明の詳細な説明】

【技術分野】

【0001】

[発明の背景]
本発明は、全体としてはメディア・コンプライアンス・エンジン（ｍｅｄｉａ ｃｏｍｐｌｉａｎｃｅ ｅｎｇｉｎｅ）を与えるコンテンツ配信ネットワーク、および方法に関する。本発明のメディア・コンプライアンス・エンジンはローカル・ゲートウェイ・サーバーを介して作動し、このゲートウェイ・サーバーではＰ２Ｐ（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）ネットワークおよび複数のデータ発信源（クラウド）を利用して、メディア配信を最適化し、レポーティング・プロセスを合理化する。本発明のメディア・コンプライアンス・エンジンは、ストリーミング・プロバイダーからのリクエストを最適化されたデータ・ソースおよびネットワークにマッチングさせ、これによって本発明のメディア・コンプライアンス・エンジンはデータ伝送量、使用許可、レポーティングコストを最小に抑制で
きる。

【先行技術文献】

【特許文献】

【0002】

【特許文献1】ＵＳ Ｐａｔｅｎｔ Ｎｏ．８，５８９，１７１

【0003】

[発明の要約]
本発明は、後置システムを変更することなく既存の標準コンテンツ配信ネットワーク、即ちサーバー環境（サーバーの構成）に付加できるＰ２Ｐコンテンツ配信ネットワーク（ＣＤＮ）を提供する。本発明のＰ２ＰＣＤＮの場合、エンド・ユーザーがクライアント・マシン上にローカル・Ｐ２Ｐゲートウェイ・サーバーをインストールする時に構築する。ゲートウェイ・サーバーが暗号化された、あるいは暗号化されていない接続（例えばＨＴＴＰ、ＨＴＴＰＳ、セキュア・ソケット、および/またはソケット（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ， ａｎｄ／ｏｒ Ｓｏｃｋｅｔ）など）を介してメディア消費クライアントからリクエストを受け取る。

【0004】

ローカル・ゲートウェイ・サーバーはＰ２Ｐネットワーク上でピアを務め、他のピアへ配信するデータやデータ消費クライアントへローカル配信するデータを保存する暗号化されたキャッシュを有する。また、ローカル・ゲートウェイ・サーバーは、関連するリモート・データ・ソース（例えばサーバーや他のＣＤＮなど）からリソースを引き出す。消費クライアントはゲートウェイ・サーバーに単一のリクエストを出すだけでよく、そしてゲートウェイ・サーバーがクライアントから独立してリソースおよびネットワーク接続を管理する。このタイプの構成の場合、孤立デスクトップ・アプリケーションだけではなく、ブラウザやメディアプレイヤーおよび標準的なウェブ・ブラウザ能力を備えたモバイル・アプリケーション（例えばＨＴＴＰ、ＨＴＴＰＳおよび/またはソケットなど）にもメディアを配信できる。

【0005】

また、本発明はローカル・マシン上のクライアントからの交信を受信するＰ２Ｐゲートウェイ・サーバーを提供する。交信、即ちリクエストはローカル・ゲートウェイ・サーバーに向けられる標準ＨＴＴＰリクエストとしてフォーマット化され、このサーバーはローカル・ドメイン・ネームで登録されることになる。ゲートウェイ・サーバーが存在する予約されたポートを参照先とする新しい転送プロトコルが作成された場合には、リクエスト（複数の場合もある）は別な形でフォーマット化することが考えられる。この場合、リクエストはわずかに異なる形（即ちＨＴＴＰプレフィックスのない形）でフォーマット化されることになる。

【0006】

また、本発明はリソース・ネーム・サーバー（ＲＮＳ）を提供し、このＲＮＳはリソースＵＲＬのネームおよびリソース保存場所（即ちＩＰアドレス）をキャッシュに保存し、マシン・アドレスでリソースリクエストを解決する。マッチしていないメディアタイプの場合の全体的なプロセス、即ち方法を以下に示す。
１．クライアントがリソースに対するリクエストをゲートウェイ・サーバーに送る。
２．次に、ゲートウェイ・サーバーがリクエストをＲＮＳに送り、リソース・アドレスでリソースリクエストを解決する。
３．リソースリクエストが最適な（最小コストの）リソース保存場所にマッチした後は、リソース・ロケーション・データがゲートウェイ・サーバーに戻る。
４．次に、ゲートウェイがリソース・データリクエストを適正なマシンやサーバー・クラスターに送信する。
５．マシンまたはサービス・クラスターが、リクエストされたデータをローカル・マシン上のゲートウェイ・サーバーに提供することによってこれに応答する。
６．ゲートウェイ処理がデータを整理・確証し、つぎにリソースをローカル・マシン上のクライアントに配信する。

【0007】

なお、従来のクライアント-サーバー関係の場合、クライアントがサーバーからデータをリクエストし、このサーバーがクライアントのリクエストに従ってデータを配信する。また、従来のアンマネージド（ｕｎｍａｎａｇｅｄ）Ｐ２Ｐネットワークでは、各ピアがサーバー（即ちデータの配信者）とクライアント（即ちデータの受信者）の両方を務める。このアンマネージド環境の場合、データのリクエストは、ファイルが見つかるまで、ピア間を循環する。

【0008】

マネージド（ｍａｎａｇｅｄ）Ｐ２Ｐネットワークの場合、統括サーバーがリソースに索引を付ける。このようなネットワーク内のピアが利用可能性についてレポートを作成し、これを登録するため、リソースの発見がより簡単になり、また速くなる。ハイブリッドなシステムの場合、Ｐ２Ｐネットワークを統括データ・ソース/索引付けサーバーと併用するため、ピア配信コストを下げることができ、しかも統括データ・ソースの統括性および速度を守ることができるため、マネージドＰ２Ｐネットワークの場合と同様にリソース配信を迅速に進めることができる。この場合、データ・オリジン・サーバーとピアとをミックスしてデータを配信する。

【0009】

本発明の場合、クライアントが孤立クライアントであり、データリクエストは、孤立したクライアント（ブラウザ、デスクトップまたはモバイル・アプリケーション）が発信し、このクライアントが消費する。明細書冒頭で述べたネットワークの場合と異なり、データのリクエストはピアが発信元ではなく、従来のクライアント-サーバー関係のように、孤立クライアントが発信元である。

【0010】

ゲートウェイ・サーバーがリクエストを受け取り、次に、リソース・ネーム・サーバー（即ちリソース索引付けサーバー）でリソースのリクエストを解決する。ＲＮＳは、リソース発信元あるいはピアであればよいリソース保存場所（ＩＰアドレス）でこれに答える。ネットワークがデータ・オリジン・アグナースティック（ｄａｔａ ｏｒｉｇｉｎ ａｇｎｏｓｔｉｃ（データ源について何も知られていない））なため、ピアデータは中央データ・サーバーによって管理はされず、むしろリクエストが回され、ゲートウェイ・サーバーでキャッシュに保存されている間ＲＮＳ上で索引が付けられる。

【0011】

従って、このようなネットワークでは、データ・ソースがリソース索引付けサーバーから分離しているため、孤立クライアントがデータのリクエストを出した場合に、データ発信元またはＰ２Ｐネットワークによって解決できる。Ｐ２Ｐネットワーク内のデータが、リクエストが孤立クライアントから送信されたときにキャッシュに保存されるからである。

【0012】

本発明の上記以外の特徴などは、添付図面を参照した以下の説明から明らかになるはずである。

【図面の簡単な説明】

【0013】

【図1】複数行のサブストリーム・パケットおよび複数カラムの検証パケットを有するデータ・ファイルの断片化された構成を示す概略図である。

【図2】本発明システムの概観を示す概略図であり、サーバー・クラスターのクラウドとリソース・ネーム・サーバーの中間に位置するゲートウェイ・サーバーを示す図である。

【図3】本発明システムの概観を示す第２の概略図であり、サーバー・クラスターのクラウドとリソース・ネーム・サーバーの中間に位置するゲートウェイ・サーバーを示す図である。

【図4】ドメイン・ネーム・サーバーシステムの概観を示す概略図である。

【図5】リソース・ネーム・サーバーシステムの概観を示す概略図である。

【図6】非プラグイン形式のセキュリティ対策の概観を示す概略図である。

【図7】クライアントがデータをリクエストし、サーバーがデータを配信する従来のクライアント−サーバー関係を示す概略図である。

【図8】データ請求が、ファイルが見つけられるまでピア間において交換される場合に各ピアがサーバーおよびクライアントの両者を務めるＰ２Ｐアンマネージドネットワークの概観を示す概略図である。

【図9】統括サーバーがリソースに索引を付け、ピアがその利用可能性をレポートし、登録するＰ２Ｐマネージドネットワークの概観を示す概略図である。

【図10】Ｐ２Ｐネットワークを統括データソース/索引付けサーバーを併用して、ピア配信を低コスト化するが、統括データ・ソースのコンシスタテンシー（ｃｏｎｓｉｓｔｅｎｃｙ−バラツキのなさ）および速度を確保するＰ２Ｐ統括ハイブリット・ネットワークの概観を示す概略図である。

【図11】Ｐ２Ｐゲートウェイ・サーバー・ネットワークの概観を示す概略図である。

【図12】ローカル・サーバーおよびブラウザをビューするために接続構造のセキュリティを確保する方法を示す概略図である。

【図13】プラグインによってローカル・ゲートウェイ・サーバーを検証する方法を示す概略図である。

【図14】第１回リクエストにおける、ファイル・マッチングを行わないリソース索引付け構成を示す概略図である。

【図15】第２回リクエストにおける、ファイル・マッチングを行わないリソース索引付け構成を示す概略図である。

【図16】第１回リクエストにおけるプログレッシブなクラウド索引付け構成を示す概略図である。

【図17】ローカル・リソース索引付け構成を示す概略図である。

【図18】第１の、索引を付けたリソースリクエスト処理構成を示す概略図である。

【図19】第２の、索引を付けたリソースリクエスト処理構成を示す概略図である。

【図20】第３の、索引を付けたリソースリクエスト処理構成を示す概略図である。

【図21】第４の、索引を付けたリソースリクエスト処理構成を示す概略図である。

【図22】サブライセンシング（再実施権許諾）、クラウド配信構成を示す概略図である。

【図23】サブライセンシング、Ｐ２Ｐ配信構成を示す概略図である。

【図24】本発明に従ってモバイル装置上での曲の再生をリクエストするストリーミング・プロバイダーを示す第１概略図である。

【図25】本発明に従ってモバイル装置上での曲の再生をリクエストするストリーミング・プロバイダーを示す第２概略図である。

【図26】本発明のゲートウェイ・サーバーの機能強化システムの概観を示す概略図である。

【図27】本発明の予め記録されたメディア待ち行列構成を示す概略図である。

【図28】本発明ストリーム分割構成を示す概略図である。

【図29】本発明のＭＰ３ファイル構造を示す概略図であり、オーディオ・ストリームのフレーム・ヘッダーおよびオーディオ・フレームを示す図である。

【図30】インターネット上にラジオをストリーミングする方法の状態を示す概略図である。

【図31】本発明の、オーディオ・ミキシングを行わない広告組み込みシステムの概観を示す概略図である。

【図32】本発明の広告マーカー構成を示す概略図である。

【図33】ブラウザおよび/またはその他のメディア消費クライアントからのＨＴＴＰリクエストをルーティングする方法を示す概略図である。

【発明を実施するための形態】

【0014】

[好適な実施態様/方法の詳細な説明]
添付図面を参照して具体的に説明すると、本発明はＣＤＮ（コンテンツ配信ネットワーク）および対応するクラウド・アグナースティックＰ２Ｐデータ・ストリーミング方法（Ｍｅｔｈｏｄｏｌｏｇｙ ｆｏｒ Ｃｌｏｕｄ Ａｇｎｏｓｔｉｃ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｄａｔａ Ｓｔｒｅａｍｉｎｇ）を提供するものである。上述したように、本発明は参照符号３で示すＰ２Ｐゲートウェイ・サーバーからなる。Ｐ２Ｐゲートウェイ・サーバー３は、ローカル・マシン１０のクライアント２からの交信（例えば２００で示す）を受信する。

【0015】

これらリクエストは、ローカル・ゲートウェイ・サーバー３に向けられる標準ＨＴＴＰリクエストとしてフォーマット化され、ローカル・ドメイン・ネームで登録されることになる。ウェブ・ブラウザや他の装置からのＨＴＴＰリクエストはローカル登録されたドメイン・ネームを使用してルーティングするさいにプロトコルが実行可能な方法であるが、ブラウザおよび他のメディア消費クライアントからのＨＴＴＰリクエストをルーティングするさいには、以下の方法が好適である。

【0016】

メディア消費クライアント２には、Ｐ２Ｐリモート・サーバー４即ちリソース・ネーム・サーバー４に対して完全フォーマット化ドメイン・ネームが与えられる。説明を簡単にするために、このドメイン・ネームをｗｗｗ.ｒｎｓ_ｓｅｒｖｅｒ．ｃｏｍ．とする。例えば１４４で示すＰ２Ｐコンテンツ配信ネットワーク(ＣＤＮ)を介してメディア４０１にリクエストするために、クライアント２は、ＲＮＳパブリック・ドメインネーム有するＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｃｏｕｒｓｅ Ｌｏｃａｔｏｒ）、およびリクエストされたメディアの保存場所に応じて変動するＧＥＴ、即ちｗｗｗ.ｒｎｓ_ｓｅｒｖｅｒ．ｃｏｍ？ｍｅｄｉａ＝ｗｗｗ.ｓｏｍｅｍｅｄｉａｓｏｕｒｃｅ．ｃｏｍ／ｍｅｄｉａ．ｍｐ４＆ｐｒｏｔｏｃｏｌ＝ｈｔｔｐ．を有する。

【0017】

ＲＮＳ４がリクエストを受信すると、２つの別個のデータベースにクエリ４０４を行う。第１クエリはパブリックＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）が対処するリクエスト・デバイスを使用して、リクエスト・デバイス・ローカル・ネットワーク１０１内にネットワーク・ピア３が存在するかどうかを確認する。第２クエリはリソース・データーベースをサーチして、Ｐ２ＰＣＤＮ１４４内においてストリーミング（例えば２００、２０７、２０８、２０９、２１０など）に利用できるリクエストされたメディアを用いてピア３を確認する。

【0018】

クエリ４０４の結果に基づき、以下のことが生じる。第一にローカル・ネットワーク１０１内に登録されたピアが存在しない場合、リクエストが４０３などでメディアのリモート・ソース１０４に再送され、従ってＰ２Ｐネットワーク１４４は利用できない。ローカル・ネットワーク１０１内に登録されたピア３が存在する場合、リクエストが４０２などで、既に第２クエリ４０４で検索されたリソース保存場所および利用可能性データとともにローカル・ネットワーク・ピア３に再送される。次に、ローカル・ネットワーク・ピア３が（例えば２００、２０７、２０８、２０９、２１０などで）メディア・ストリームを扱う。

【0019】

なお、例えば４で示すＲＮＳ（Ｒｅｓｏｕｒｃｅ Ｎａｍｅ Ｓｅｒｖｅｒ）が、本発明を実施するさいに中心になる。ＲＮＳ４が、リソースＵＲＬおよびリソース保存場所（ＩＰアドレス）をキャッシュに保存し、マシン・アドレス（ＩＰアドレス）でリソースリクエストを解決する。マッチングしていないメディアタイプの全体的なプロセスは、以下のようになる。クライアント２が、（２００などの）リソースに対するリクエストをゲートウェイ・サーバー３に送信する。

【0020】

次に、ゲートウェイ・サーバー３が、リクエスト（２０１など）を区画化された（ｃｏｍｐａｒｔｍｅｎｔｅｄ）ＲＮＳ４に送信し、リソース・アドレス（例えば２０４など）で着信リソースＩＤ/ＵＲＬリクエスト（例えば２０３など）を解決し、このリソースあるいはＩＰアドレスを次に、図５により具体的に示すように、ゲートウェイ・サーバー３に（例えば２０５など示すように）送り返す。換言すると、一旦リソースリクエスト２０３が２０２などで最適なリソース保存場所２０４（例えば、（ａ）ソースの価格効率が最も高いか、あるいは（ｂ）ソースの音質が最も高いリソース保存場所）にマッチングした後は、リソース保存場所データまたはＩＰアドレス２０４が、例えば２０５など示すように、ゲートウェイ・サーバー３に戻る。

【0021】

次に、ゲートウェイ・サーバー３が、リソース・データに対するリクエストを、例えば１０４などで示すように、適切なマシン（１０２および/または１０３）またはサーバー・クラスターに（２０６、２０７、２０８などで示すように）送信する。次に、マシン１０１に設置されたゲートウェイ・サーバー３に、（例えば２０９などで示すように）リクエストされたデータを提供することによってマシン１０２/１０３またはサーバー・クラスターが応答する。マシン１０１上のゲートウェイ・サーバー３が、例えば２０９など提供されたデータを処理する（即ち整理かつ確証する）。次に、クライアント２へリソースを配信２１０する。

【0022】

ある特定のクライアント−サーバー−ピア関係の基本的な概略図を図７、図８、図９および図１０に示す。即ち、図７に従来のクライアント−サーバー関係を示し、図８にアンマネージドＰ２Ｐネットワーク（ｕｎｍａｎａｇｅｄ Ｐ２Ｐ Ｎｎｅｔｗｏｒｋ）を示し、図９にマネージド（ｍａｎａｇｅｄ）Ｐ２Ｐネットワークを示し、そして図１０に統括/ハイブリッドＰ２Ｐネットワークを示す。

【0023】

従来の一つのクライアント−サーバー関係では、クライアント１０５がサーバー１０６からデータをリクエストし２１１、そしてサーバー１０６が、図７に示すように巡回的にデータを配信２１２する。従来の一つのアンマネージドＰ２Ｐネットワークでは、各ピア（またはクライアント/サーバー）１０７がデータを配信するサーバー１０６を務め、またデータを受信するクライアント１０５を務める。全体として図８に示すアンマネージド環境では、ファイルが見つかるまでデータのリクエスト２１１がピア１０７からピア１０７に回される。

【0024】

全体構成を図９に示すマネージドＰ２Ｐネットワークは、リソースに索引を付ける機能の統括リソース索引付けサーバー１０８を有する。インデックスが付けられたリソースは、リクエスト２１４に従ってピア１０７に配信２１３する。索引付けリソースの利用可能性をピア１０７によって次にレポーティングし、登録する。このタイプの構成によれば、リソースを見つけるのが簡単であり、見つける速度も速い。

【0025】

図１０に全体構成を示すハイブリッドシステムの場合、Ｐ２Ｐネットワークを統括データ・ソース／索引付けサーバー１０９と併用する。ピア１０７によるリソースおよびデータリクエスト２１６に続いて、サーバー１０９からピア１０７に索引付きリソースおよびデータの両者を配信２１５する。このタイプの構成の場合、ピア配信コストが低く、マネージドＰ２Ｐネットワークの場合と同様に、リソース配信を促進するため、統括データ・ソースにバラツキがなく、また速度も速い。この状況では、データミックスがサーバー１０９から発生し、ピア１０７がデータを配信する。

【0026】

図２および図３に全体構成を示すオリジン・アグナースティック（ｏｒｉｇｉｎ‐ａｇｎｏｓｔｉｃ:由来不詳のデータ源不可知）Ｐ２Ｐ（ｐｅｅｒ‐ｔｏ‐ｐｅｅｒ：ピア・ツー・ピア）コンテンツネットワーク配信（ＣＤＮ）１４４の場合、クライアント２は孤立クライアント（ｓｔａｎｄ‐ａｌｏｎｅ ｃｌｉｅｎｔ：スタンドアロン・クライアント）である。即ち、請求されたデータリクエスト発信元が孤立クライアント２（即ちブラウザ、デスクトップまたはモバイル・アプリケーション）によって消費される。他のネットワークとは異なり、データリクエスト発信元がピア１０７ではなく、全体構成を図７に示すような従来のクライアント・サーバー関係のように孤立クライアント２である。

【0027】

ゲートウェイ・サーバー３がクライアント２からのリクエストを受け取り、そしてリソース・ネーム・サーバー（Ｒｅｓｏｕｒｃｅ Ｎａｍｅ Ｓｅｒｖｅｒ：ＲＮＳ）またはリソース索引付きサーバー４でリソースに対するリクエストを解決する。ＲＮＳ４がリソース保存場所（例えばＩＰアドレス）で応じ、これらリソース保存場所はリソース源またはピアである。このネットワークの場合、データ・オリジン・アグナースティック（ｄａｔａ ｏｒｉｇｉｎ−ａｇｎｏｓｔｉｃ）であるため、ピアデータは中央データ・サーバーによって管理されないが、リクエストが配信され、ゲートウェイ・サーバー３でキャッシュに保存されている間ＲＮＳ４で索引が付けられる。

【0028】

このようなネットワークの場合、データ・ソースはリソース索引付けサーバーまたはＲＮＳ４から分離している。孤立クライアント２によるデータリクエストがあった場合、データ源またはＰ２Ｐネットワークがこれに応じる。孤立クライアント２からのリクエスト送信時、Ｐ２Ｐネットワーク内のデータがキャッシュに保存されるからである。

【0029】

本発明はＨＴＴＰまたはＷｅｂソケットを使用することに限定されず、標準ファイル転送プロトコル（ＦＴＰ、ＷｅｂＤＡＶ、ＳＭＢ、ＡＦＰなど）も使用可能である。この場合、クライアントは孤立ＦＴＰ（または任意の標準ファイル転送プロトコル・クライアント）であればよい。ＯＳ（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）内のネットワーク・ドライブとしてＦＴＰディレクトリー（またはＷｅｂＤＡＶ、ＳＭＢ、ＡＦＰなど）を装備する場合には、ＯＳがクライアントを務める。この場合、ゲートウェイ・サーバーがファイル・サーバーとして機能する。

【0030】

特に、このような構成ではセキュリティに懸念が生じる。本発明が提案する解決策または構成は潜在的に“中間者攻撃（ｍａｎ ｉｎ ｔｈｅ ｍｉｄｄｌｅ ａｔｔａｃｋｓ）”および／または認可されていなクライアントアクセスに弱い。これら懸念については、ある特定のクライアントおよび／またはサーバー真贋確認手段によって対処できる。基本的に、クライアントおよび／またはサーバー真贋確認手段は、クライアントおよび／またはサーバーの真贋を確認する機能をもつ。

【0031】

クライアントおよび／またはサーバー真贋確認手段については、後で詳しく説明するように、多数の異なる機構を例示することができる。例えば、これら真贋確認手段は、メディア・プラグイン真贋確認（クライアント真贋確認）、および不正サーバーでないことを担保するためにローカル・サーバーが正しいサーバーであることを確証するブラウザ・拡張子（この場合、ある種の特別なＩＤ、セッション・トークン、あるいはキーペアリングが必要になる）によって確保できる。

【0032】

クライアント側スクリプトをプラグインと併用して、ある形態の確認検証（ｖｅｒｉｆｉｃａｔｉｏｎ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）をプラグインに埋め込むことによってクライアントおよびサーバーの両者の真贋を確認することも可能であり、この確認検証を次にＡＪＡＸを使用してこの確認検証が正しいことを確証するクライアント側スクリプトに回す。クライアント側スクリプトをブラウザ・プラグインと併用すると、一回のプロセスでクライアントおよびサーバーの両者を確認できるため好ましい。この方法を以下に説明する。

【0033】

図１２および図１３に示すように、クライアント側認証をブラウザ・プラグインおよびクライアント側スクリプトによって行う。セキュリティ接続を作るプロセスは、最初にローカル・サーバーを設置する。ローカル・サーバー設置時、サーバーが自署証明書を作成し、この自署証明書をルート証明書ツリーに追加する。これによって、サーバーがブラウザからセキュリティ接続を作ることができる。

【0034】

別なセキュリティ層を積み増すために、ローカル・サーバー１１０がメディア処理ブラウザ・プラグイン２４（例えば、フラッシュ（Ｆｌａｓｈ）、スライバー・ライト（Ｓｉｌｖｅｒｌｉｇｈｔ：シルバーライト）など）について多数のインスタンスを読み込む。ローカル・サーバー１１０の場合、メディア処理ブラウザ・プラグイン２４について１，０００ものインスタンスを簡単に読み込むことができる。各インスタンス内に、特別な暗号化キー２７を埋め込む。多数のインスタンスを読み込む代わりに、プラグイン・ライブラリーによってカスタム・コード・インジェクションを行うことができる場合には、プラグイン・コンポーネント・ファイルにインジェクションすることができる。

【0035】

ブラウザがセキュリティ接続２６を作り出すと、サーバー１１０が開始された接続の特別なセッションを作り、このセッションをメディア・プラグイン・インスタンス２４およびその埋め込まれた暗号化キー２７とペアリングするか、あるいは暗号化キー２７を作り、これをプラグイン・コンポーネント・ファイルにインジェクションする。次に、プラグイン・コンポーネント・ファイル２５をブラウザ１１１に読み込む。プラグイン・ファイル２５がクライアント側スクリプトを介してブラウザ１１１から来るリクエストすべてを暗号化し、暗号化接続２６を介してサーバー１１０に送信する。この特別な暗号化キー２７の場合、リクエストに署名してこれらを確証するために使用する特別なトークンとしても使用できる。

【0036】

暗号化キーまたはトークン２７を呼び出すために、ローカル・サーバー１１０が提供するプラグイン・ファイル２５をデコンパイル（ｄｅｃｏｍｐｉｌｅ）してから、新しい“不正侵入（ｃｒａｃｋｅｄ）”プラグイン・インスタントを使用してサーバー１１０との接続を再度作り出すが、サーバー１１０の場合、セッション毎に異なる暗号化キー２７を選択するため、新しいセキュリティのかかったソケット接続２６ができた瞬間に、前の暗号化キー２７はその役割を終える。このため、デコンパイリング（ｄｅｃｏｍｐｉｌｉｎｇ）により暗号化キー２７を呼び出すことがその意味を失う。

【0037】

ローカル・サーバーを使用するネットワーク配信に関する大きな懸念の一つは、“中間者攻撃”の可能性であり、このシナリオでは悪意のあるソフトウェアが有効なゲートウェイを装い、ユーザー・データをインターセプトする可能性がある。この形態の攻撃を避けるために、本発明のシステムでは、ブラウザ・プラグイン・コンポーネント２５によって有効なサーバーに確認検証３１を与えることによってローカル・サーバー１１０が有効なゲートウェイの真贋を確認する必要がある方法を使用する。このプロセスについて、以下詳しく説明する。

【0038】

あらゆるローカル・ゲートウェイ・サーバー１１０について、ローカル・マシンのパブリックインターネット・プロトコルにリンクした確認検証３１を創設することによってそれ自体にリモート・ホスト１１２を登録（例えば１９で示す）する。この確認検証３１およびその関連するパブリックインターネット・プロトコルは、リモート・ホスト１１２のデータベース２９に記憶する。いずれローカル・ゲートウェイ・サーバー１１０を使用することになるウェブ・ページ３０をロードすると、ブラウザ１１１がリクエスト（例えば２１７で示す）をローカル・サーバー１１０に送信する。サーバー１１０がこれに応じて、その確認検証３１を提示する。

【0039】

次に、ブラウザ１１１がリクエスト（例えば２１８で示す）を確認検証３１とともにリモート・ホスト１１２に送信する。確認検証３１がインターネット・プロトコル アドレスおよびリモート・データベース２９に記憶されている確認検証にマッチングした場合、リモート・サーバー１１２が、ローカル・ゲートウェイ・サーバー１１０を確証する経路２１８にそってレスポンスを送信する。確認後、ブラウザ１１１が次に進み、ローカル・サーバー１１０からメディア・プラグイン２４を（例えば２６で示すように）ロードする。次に、メディア・プラグイン２４は、ローカル・ゲートウェイ・サーバー１１０に対するセキュア接続２１９を形成し、この接続を介してデータ（例えば音楽系データ）を配信する。

【0040】

図６を参照して、非プラグイン・セキュリティ対策について説明する。本発明のメディア・プラグインを使用する必要がない方法の場合、ゲートウェイ・サーバー３からクライアント２に登録されているセッションＩＤ（ｉｎｄｉｆｉｃａｔｉｏｎ）１１３に対するリクエストを送信してもらい、その真贋を確証する。セッションＩＤ１１４については、ゲートウェイ・サーバーによって（例えば２２１で示すように）予め登録しておき、一回の真贋確認後は無効になる。

【0041】

このためには、ゲートウェイ・サーバー３が予定時間よりも早く多数のセッション１１４を登録する必要があり、各セッションＩＤ１１３は、確証回数は一回のみである。ゲートウェイ・サーバー３がセッションＩＤ１１３を（例えば２２２で示すように）クライアント２に提示する。次に、クライアント２は確認サーバー１１６で、受信されたセッションＩＤ１１５を（例えば２２３で示すように）確証する。確認サーバー１１６は、登録されたセッションＩＤ１１４をもつクライアント２が送信したセッションＩＤ１１５に（例えば２２４、２２５で示すように）マッチングする。マッチングがあった場合には、確認サーバー１１６がクライアント２に対してゲートウェイ・サーバー３の妥当性を（例えば２２４で示すように）確認する。

【0042】

上記以外にも、接続の妥当性を保証する他の方法もあり、例えば、ＯＳ（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）の統合方法があり、この方法の場合、ゲートウェイ・サーバーのために予約されたローカル・ドメイン・ネームを備えているため、他のアプリケーションが合法的なゲートウェイ・サーバーを装うことができず、あるいはこのローカル・ドメイン・ネームをこのような統合システムを介してデータ伝送を行う伝送プロトコルの作成を通じて備える。これらはいずれも可能なソリューションである。しかし、カスタムプロトコル・ソリューションの場合には、以下に例示するように、異なるリクエストのフォーマット化が必要である。即ち、
ｒｓｔｐ：//ｄｏｍａｉｎ．ｃｏｍ/ｒｅｓｏｕｒｃｅ_ｄｉｒｅｃｔｏｒｙ/ｒｅｓｏｕｒｃｅ_ｎａｍｅ？ｖａｒ＝１２３（ａｎｄ ｎｏｔ ｈｔｔｐ.//ｖｅｒｔｉｇｏ/ｄｏｍａｉｎ．ｃｏｍ/ｒｅｓｏｕｒｃｅ_ｄｉｒｅｃｔｏｒｙ/ｒｅｓｏｕｒｃｅ_ｎａｍｅ？ｖａｒ＝１２３）

【0043】

システムのセキュリティを確保するもう一つの方法では、このシステムを介してメディア（音楽、映像、ビデオなど）に配信されるコンテンツを制限するとともに、ウェブサイトやアプリケーションの構造体およびコードに関係しないコンテンツにファイル・ディストリビューション（ｆｉｌｅ ｄｉｓｔｒｉｂｕｔｉｏｎ）を限定する。この方法では、メディア・ファイルのみが許可されるため、マリシャス・コード（ｍａｌｉｃｉｏｕｓ ｃｏｄｅ）をインポートすることがより難しくなる。この場合には、セキュリティに留意すればよい。換言すると、ＨＴＭＬ、Ｊａｖａｓｃｒｉｐｔ、ＣＳＳ、ＰＨＰファイルなどはゲートウェイ・サーバーによっては配信できない。別な制限に関して述べると、ウェブサイト（構造体、コードおよびメディア）をｈｔｔｐｓによって読み込み、これが敏感な（変動しやすい）場合には、クライアント（ブラウザ）にこのようなゲートウェイまたはプロトコルの使用を控えてもらう。

【0044】

図１に、本発明のある特定のデータの妥当性およびセキュリティの態様を示す。データ・オリジン・アグナースティックなＣＤＮ１４４における懸念の一つは、データの妥当性である。例えば、一方のピアのデータが破損している場合、あるいはオリジナル・データに関係ないファイルを登録するマリシャス・ピアをオリジナル・ファイルのピアのキャッシュに保存したバージョンとして誰かが作成した場合、システムの信頼性および有効性が犠牲になる。

【0045】

これは、システムが高い信頼性を有し、また有効であるためには、データ・フラグメンテーション（ｄａｔａ ｆｒａｇｍｅｎｔａｔｉｏｎ）および確認方法を使用する必要があるからである。従って、一方のピアがデータを不適切な方法で破損し、あるいは意図的に変更する可能性を避けるためには、ある特定のデータ配信フラグメンテーション手段によって多数のピア間においてデータ配信をフラグメンテーションすることが好ましい。本発明のデータ配信フラグメンテーション手段は、多数の機構によって例示することができる。データ配信フラグメンテーションのためには、例えば、データ１９９を例えば１１７、１１８、１１９、１２０で示す列のようにパケットまたはサブストリームに分割すればよい。

【0046】

また、フラグメンテーションのためには、各ピアの配信をある特別なファイルの最大で３分の１あるいは４分の１に制限するだけでもよい。これは、以下により詳細に説明するように、リソース・ネーム・サーバー、すなわちＲＮＳ４を使用して管理する。データ配信フラグメンテーションとともに、各データ・ファイルは、例えば縦列１２１、１２２、１２３、１２４で示すように、データの特定のセクタに対して妥当性パッケージを有する。データを提供するあらゆるピアは、これを再提供する前に、メディアを最初にキャッシュに保存する必要があるからである。従って、一例として、ピアがデータ・サブストリーム１１７を配信する場合、このデータとともにファイルのセクタ１２１に対する妥当性パッケージを配信することになる。この妥当性パッケージが、所定のアルゴリズムによって作成するチェック・サム（ｃｈｅｃｋｓｕｍ）である。

【0047】

従って、サブストリーム１１８を送信するピアが破損データやマリシャス・データを配信した場合、レーシービング・ピアはピア送信サブストリーム１１７からの妥当性チェック・サムを使用して、ピア送信サブストリーム１１８によって配信されたコンテンツを確証することによってこれを検出できる。コンテンツを確証できない場合には、ピアがデータリクエストをオリジナル・ソースまたはデータ源ソースに送信する。本発明ではさらに、リクエストに関して最小閾値/日を設定し、このようなＰ２Ｐデータ確証を実行可能にする。さもなければ、確証サーバーがチェック・サムを提供し、これらチェック・サムが、リソースのためにゲートウェイ・サーバーに回される最初のリクエストにおいて作成されることになる。

【0048】

図４および図５を参照して、ドメイン・ネーム・サーバー（ＤＮＳ）とリソース・ネーム・サーバー（ＲＮＳ）との間のある特定の差異について比較を行う。ＤＮＳ１３０とＲＮＳ４との主な差異は、リソースに対するリクエストをどのように扱うかにある。ＤＮＳ１３０内では、リソースに対するリクエスト（例えば２２６で示す）は、ＳＯＡ（Ｓｔａｒｔ ｏｆ Ａｕｔｈｏｒｉｔｙ）１２６のディレクトリー１２８内の特定されたリソース１２７を有するドメイン・ネーム１２９またはＳＯＡ１２６に対して（例えば２２７で示すように）解決する。クライアント２はＤＮＳからＳＯＡのＩＰアドレスを（例えば２２８で示すように）受け取り、次にＳＯＡ１２６からリソース１２７に対してリクエスト（例えば２２９で示すように）を出す。

【0049】

リソース・ネーム・サーバー、即ちＲＮＳ４内では、ＲＮＳ４が特別なリソースが記憶されているか、あるいはキャッシュに保存されている多数のマシンに対するリソースのリクエスト（例えば２０１で示す）を解決する（例えば２０２で示す）。従って、リソースを備えたＳＯＡのＩＰアドレスは妥当なリソース・ロケーションとして戻される（例えば２０５で示す）が、ピアがキャッシュに保存したリースのＩＰアドレスについても同様である。即ち、ＤＮＳシステム内では、ＵＲＬは特定のリソースのアドレスにより似ているもので、ＲＮＳ４内では、ＵＲＬ２４０は特別なリソースを多数の保存場所にリンクする特別なＩＤである。

【0050】

図１４および図１５に、ファイル・マッチングを行わないリソース索引付け手段を示し、そして図１６および図１７に、ファイル・マッチングを行うリソース索引付け手段を示す。コンプライアンスを扱うさいに発生する最大の問題の一つは、再生対象を確認する方法である。メタデータの場合、ユーザーによって破損、あるいは変更されていることが多い。従って、ローカル・メディアをより効率良くダウンロードして再生するために、ローカル・ドライブのメディア・ファイルまたは曲がクラウド内に記憶されている確実性がきわめて高い程度で確認を行う方法を確立する必要がある。

【0051】

これを実現するためには、メタデータから独立したファイル・マッチングシステムまたは手段によって実現でき、またすべてのローカル・ファイルに索引を付け、そしてこれらをクラウド・ファイルとマッチングすると実現できる。本発明のライブラリーに対してマッチングする必要がある２つのファイルのソースがある。即ち（１）他のストリーミング・プロバイダーを発生源とするソース、あるいは外部クラウドから来るファイルのソース、および（２）ローカル・マシン上のファイルのソースである。

【0052】

図１６について説明すると、プログレッシブな索引付けのプロセス２４７は、第３者のクライアント・アプリケーションから来るリクエストから始まる。これは、例えば１３１で示す孤立デスクトップ・アプリケーション（ｓｔａｎｄ‐ａｌｏｎｅ ｄｅｓｋｔｏｐ ａｐｐｌｉｃａｔｉｏｎ：スタンドアロン・デスクトップ・アプリケーション）か、あるいは例えば１３２で示すブラウザを介して再生するウェブサイトであればよい。アプリケーション１３１またはブラウザ１３２は、適正にフォーマット化され、かつ有効なＵＲＬ（例えば２４１、２４２で示す）にそってローカル・ゲートウェイ・サーバー（１３３）に進む。ローカル・ゲートウェイ・サーバー１３３は、ＵＲＬ（例えば２４１、２４２）を使用して、対応するクラウド２４５および２４６（あるいは対応するＰ２Ｐネットワーク、あるいは他の考えられるネットワーク系リソース）からのストリーミング配信（例えば２４３、２４４）のためにリクエストされたリソースを呼び出す。例えば２４３および２４４で示すストリーミング配信のためにリソースが一旦ダウンロードされた後は、ローカル・サーバー１３３が（サブルーチン（ｓｕｂｒｏｕｔｉｎｅｓ）２４８〜２５２を用いて）例えば２４７で示すように索引付けプロセスを開始する。（サブルーチン２５４〜２５８を用いて行う）ローカル・リソース索引付け２５３について、全体を図１７に示す。

【0053】

また、図１８に索引付きリソースリクエスト処理２５９の全体を示す。リソースに索引付けした後、第３者のクライアントから次のリクエストが出されるさいに以下のプロセスが生じる。メディア・ストリーミング・サービス・プロバイダー（例えば１３２で示す）が、その標準ＵＲＬを使用してリクエスト２４２をローカル・サーバー１３３に入力するとする。リクエスト２４２が入力され、ローカル・サーバー１３３がローカル・ファイル・システム・データベース１３５および索引付けサーバー１３４に対して検索を要求し、リソースに予め索引が付けられているかどうかを決定する。（ＵＲＬが、索引付けサーバー１３４に存在するか、あるいはローカル・ファイル・システム１３７に存在するかを決定する）。この場合、ローカル・サーバー１３３がリソースに既に索引が付けられ、Ｐ２Ｐネットワーク１３８上で利用できることを決定する。次に、メディアがＰ２Ｐネットワーク１３８から読み出され、メディア・ストリーミング・サービス・プロバイダー（例えば１３２で示す）に提供し、再生を行う。

【0054】

別な場合、メディア・ストリーミング・サービス・プロバイダー（例えば１３１で示す）が、そのＵＲＬを使用して同様なリクエストを出す。今度は、リソースに索引が付けられ、ローカル・ファイル１３７に対応していることを示すかについてローカル・データベースへ検索要求することによってサーバー１３３が決定する。次に、サーバー１３３がこのファイルを例えば第３者のクラウド系音楽ストリーマー（例えば１３１で示すＳｐｏｔｉｆｙ）に提供する。ローカル・ゲートウェイ・サーバー（１３３）にアクセスするシステムまたはアプリケーションが、セッション開始し、セッションが続いている間必要になるすべてのリソースを回すことになる。次に、サーバー１３３がリソース索引付けサーバー（１３４）から対応するフィールドを引き出す。このようにして、すべての索引付きデータがローカル記憶でき、アクセスおよびルーティングが迅速になる。

【0055】

本発明のゲートウェイ・サーバーは、スマート・ルーティングおよびロイヤルティー・レポーティングの手段になり、（例えば音楽などの）データ伝送を行うことができる。多数のソースから音楽を伝送できるため、本発明のローカル・ゲートウェイ・サーバーの場合、クライアント・アプリケーションに出されるインタラクティブな音楽リクエストおよび非インタラクティブな音楽リクエストの両者を配信でき、また最適な保存場所（例えば（ａ）プライス効率が最も高い保存場所または（ｂ）ソースの音源品質が最も高い保存場所）から実際の伝送をルーティングでき、データ転送コストおよびロイヤルティー義務の両者に資する。このようなシステムにより、特別なコンプライアンス・エンジンまたはコンプライアンス・アプリアンス（Ｃｏｍｐｌｉａｎｃｅ Ｅｎｇｉｎｅ ｏｒ Ｃｏｍｐｌｉａｎｃｅ Ａｐｐｌｉａｎｃｅ）を実現でき、使用レポートおよびロイヤルティー義務を多くのタイプのサービス・プラットホーム全体から作成でき、すべての権利者の要件および基準を満たすことができる。

【0056】

制限するものではないが、以下に伝送ソースを例示する。（１）クラウド系ストリーマー、（２）装置所有者に利用可能なデータ購入を行う第３者クラウド系ストレージ・プロバイダー、（３）バーティゴ・クラウド系バーチャル・ロッカー（Ｖｅｒｔｉｇｏ‘ｓ ｃｌｏｕｄ−ｂａｓｅｄ ｖｉｒｔｕａｌ ｌｏｃｋｅｒ）（著作権法第５１２（ｃ）条で保護される）、（４）ユーザー/サブサービス・マッチド・データによって駆動されるバーティゴのライセンスを受けている音楽、（５）リスナーの装置で利用可能な、ローカル所有かつローカル保存されている音楽ファイル、あるいはＷｉ−Ｆｉによって接続され、所有が別で制限装置で利用可能なローカル所有かつローカル保存されている音楽ファイル、（６）リンクされたＰＣからモバイル装置への伝送、（７）伝送に利用可能で、上記（１）、（３）および（４）からストリーミングされる前にファイルの代わりにルーティングされるＰ２Ｐが所有するファイルである。

【0057】

音楽ルーティングおよびルート結果レポーティングのいくつかの例を以下に示す。図１９について説明する。リスナーが対応するストリーミング・クライアント（例えば１４０で示す）を介して非インタラクティブなインターネット・ラジオ・チャネル（例えばウェブサイトまたは孤立デスクトップ・アプリケーション）を聞き、そしてインターネット・ラジオ・サービス・プロバイダーが既にリスナーの装置に記憶され、かつ利用できるファイル１３９をストリーミングできる（例えば２３０で示す）状態にある場合、本発明のゲートウェイ・サーバー１４１が索引付きローカル・ファイル１３９とインターネット・ラジオ・サービス・プロバイダーの着信リクエストとをマッチング（例えば２３１で示す）し、例えば１４２で示すインターネット・ラジオ・サービス・プロバイダーのクラウドから再生する代わりに、ファイル１３９をストリーミング（例えば２３２で示す）する。

【0058】

特に、ローカルな場合も、そしてリモートの場合もすべてのリソースに索引を付けるため、素早いマッチングが可能になる。ストリーミング２３２後、ローカル・ファイルを使用したことをコンプライアンス・サーバー１４３に例えば２３３で示すようにレポーティングする。ラベル（ｌａｂｅｌ：レーベル）の場合、インターネット・ラジオ・サービス・プロバイダーは、ローカル・ファイル１３９をストリーミング２３２するさいには少額の料金を支払う必要がある。ラベルが剽窃されないという保証がないからである。サーバー１４１が効率的なリソース・アロケーションを行う結果、インターネット・ラジオ・サービス・プロバイダー１４０は、データ転送について支払う必要がなく、またフル・ライセンシング（ｆｕｌｌ ｌｉｃｅｎｓｉｎｇ）についても支払う必要がないため、節約したコストをインターネット・ラジオ・サービス・プロバイダーに回すことができる。

【0059】

図２０に、リスナーが非インタラクティブなインターネット・ラジオ・サービス・プロバイダー・チャネルを聞き、そしてインターネット・ラジオ・サービス・プロバイダー・クライアント１４０がリスナーの装置で利用できないが、本発明のＰ２Ｐネットワーク１４４内のピア１４１上で利用できるファイルを（例えば２３０で示すように）ストリーミングする準備ができているシナリオを示す。この場合、インターネット・ラジオ・サービス・プロバイダーに対してロイヤルティーを節約できないが、本発明のＰ２Ｐネットワーク１４４がインターネット・ラジオ・サービス・プロバイダーのファイルの代わりにファイル１３９を例えば２３３で示すように伝送するため、インターネット・ラジオ・サービス・プロバイダーに対してデータ転送コストを節約できる。次に、サーバー１４１がどの曲を再生するかを必要に応じてコンプライアンス・サーバー１４３に例えば２３３で示すようにレポートする。

【0060】

図２１に、リスナーが特別なイベントに備えて、例えば１４５で示すメディア・ストリーミング・サービス・プロバイダー・アカウントに１０曲の再生リストを作成する場合のシナリオを示す。リスナーがレストランのオーナーまたはマネージャーであってもよく、イベントが商用地区における公共イベントでもよい。メディア・ストリーミング・サービス・プロバイダー・アカウント１４５は商用地区では許されず、曲のうち三曲がリスナーのクラウド・ストレージ・ロッカーを介してローカル装置にダウンロードするために現実に利用できる状態では、購入されたメディア・ライセンス契約は商用地区では送信できない。

【0061】

商用ライセンシング・プロバイダー装置１４６の場合、１０曲の曲すべてを放送する法的権利をもつが、１０曲のリクエストされた再生リストのうち５曲のみがプロバイダーのローカル設置装置１４６上で利用可能であるとの前提で設置する。本発明システムの場合、メディア・ストリーミング・プロバイダーのメディア再生装置１４５内で作成された再生リストをシンクロし、欠けているファイルをバーティゴ・クラウド（ｖｅｒｔｉｇｏ ｃｌｏｕｄ）内で利用できるファイルと（例えば２３１で示すように）マッチングし、曲をプロバイダーのライセンシング契約毎に商用ライセンシング・プロバイダーの装置１４６に送信２３４する。この転送は、データ転送コストに応じてバーティゴのＰ２Ｐネットワーク１４４から発生する。すべての伝送およびすべてのストリーミングは、（必要に応じて）サーバー１４１によってコンプライアンス・サーバー１４３にレポーティング２３３され、曲の再生数を追跡することができる。

【0062】

図２４に示すシナリオの場合、ストリーミング・プロバイダー１４７が、曲１５１をモバイル装置１４８で再生すべきとリクエストできる。このリクエストは、モバイル装置１４８上のモバイル装置アプリケーション１４９から送られ、そして本発明のリモート・サーバー１５０に送信される。この曲をリクエスト２３７したモバイル装置１４８が、曲のリクエストをデータ発生サーバー１４７（即ちストリーミング・プロバイダーのサーバー）にルーティングする代わりに、ファイルがローカル記憶されたＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）１５２に例えば２３５で示すようにリンクされた場合には、このリクエストはＰＣ１５２へ送信され、ＰＣ１５２からモバイル装置１４８に例えば２３６で示されるようにストリーミングされる。このような状況では、付加的なストリーミング権利は必要なく、データ転送コストもかからない。リクエスト２３７が本発明のリモート・サーバー１５０に送られ、そしてファイルがリンクされたＰＣ１５２上にもなく、またクラウド上にもない場合には、リクエスト２３７は例えば２３８で示すようにデータ発生源１４７に送られ、このデータ発生源１４７がファイルを装置１４８にストリーミング２３９できる。

【0063】

図２５に示すシナリオの場合、ストリーミング・プロバイダー１４７が、曲をモバイル装置１４８で再生すべきとリクエストできる。このリクエストは、モバイル装置１４８上のモバイル・アプリケーション１４９から送られ、そして本発明のリモート・サーバー１５０に送られる。モバイル装置１４８が例えば２３５で示すようにリンクされたＰＣ１５２からクラウド・サービス１５３に例えば２４０で示すようにアップロードされた曲をモバイル装置１４８がリクエストした場合、リモート・サーバー１５０がリクエスト２３７をクラウド・ロッカーまたはサービス１５３にルーティング２３６する。この場合、ライセンシングは必要ないが、データ転送費がかかることになる。本発明のリモート・サーバー１５０にリクエスト２３７が送られ、そしてリンクされたＰＣ１５２にも、あるいはリンクされたクラウド１５３にもファイルが存在しない場合には、このリクエストはデータ発生源１４７に例えば２３８で示すように送られ、その後ファイルが例えば２３９で示すように装置１４８にストリーミングされる。

【0064】

本発明のサーバー１５０、および上記実施例で説明したそのスマート・ミュージック・ルーティング・エンジンの場合、データ転送コストおよびロイヤルティーコストに関して最小の伝送費（例えば、上記の実施例１〜６などのリソースを始めとする）で曲を選択できるだけでなく、このような伝送およびロイヤルティーのアクティビティなどのレポートのコンプライアンス態様を評価するものである。

【0065】

図２２および図２３に、本発明の特定のサブライセンシング構成を示す。ストリーミング化されたコンテンツの自動化サブライセンシングにローカル・ゲートウェイ・サーバーを使用するかどうかは、権利保有者とコンテンツ配信者（即ちストリーミング・サービス・プロバイダー）との契約条項に応じるものである。ストリーミング・プロバイダーが、ストリーミング・ライセンスド・メディアから引き出される収益の一部を共有しなければならない契約を交わしている前提で可能な状況を以下に説明する。このようなライセンスによってストリーミング・プロバイダーが卸売り業者として振る舞えることが必要条件である。

【0066】

図２２に第１ケース・シナリオを示す。この場合、ストリーミング・サービス・プロバイダー１５５が、ローカル・サーバー１５０が最適価格でストリーミング２４１を行うことができる特定のパラメーターを設定する必要があるリクエストとともにリクエストをローカル・ゲートウェイ・サーバー１５０に回す。これは、サーバー１５０が例えば１５６で示すようにサブライセンスド・アカウント（ｓｕｂ−ｌｉｃｅｎｓｅｄ ａｃｃｏｕｎｔ）からストリーミングを行うことができることを示す。図２２には、３つのサブライセンスド・アカウント１５７、１５８、１５９を示す。

【0067】

リクエストがクライアント・アプリケーション１５５から来る場合には、ローカル・サーバー１５０が、どの（例えばアカウント１５７〜１５９から選択される）サブライセンシング・アカウントが所定のリクエスト２４１に対して最適なライセンシングコストを有しているかを、例えば２４２で示すように決定する。次に、サブライセンサー・クラウド（例えばアカウント１５７）から曲をストリーミング２４３する。次に、ストリーミング・プロバイダーが、サブライセンサー１５７の利益のために例えば２４４で示すように請求書を出す。請求書には、サブライセンサー・ライセンシング契約に基づいてライセンシングコストおよびストリーミングコストが含まれることになる。次に、サブライセンサーが権利保有者１６０にロイヤルティーを支払い２４５、ストリーミングコストおよび取引から生じた利益を賄うために必要な金銭を取って置く。

【0068】

図２３に示す第２ケースの場合、最も重要な違いは、ストリーミングコストを如何に賄うかにある。本発明のＰ２Ｐネットワーク１６１からデータをストリーミング２４６するため、Ｐ２Ｐネットワーク１６１の使用料は、このネットワーク１６１の所有しているサービス・プロバイダー１６２に支払い２４７、次に、２４４を経由してライセンシングコストをサブライセンサー１５７に回し、このサブライセンサー１５７が権利所有者１６０にロイヤルティーを支払い２４５、取引から生じる利益を確保する。

【0069】

上記のサブライセンシングケースが可能な理由は、ローカル・サーバー１５０がストリーム、即ち誰が何処（どのサブライセンサー）からストリーミングを行っているかを追跡でき、またレポートを作成でき、結果としてロイヤルティーの支払いのルーティングを適正化できるからである。本システムの特別な点は、このような追跡を可能にする点ではなく、Ｐ２Ｐネットワークへのアクセスが可能であり、しかもこのようなアクセスについてレポートを作成できる点にある。上記の第２ケースシナリオの場合、ローカル・ゲートウェイ・サーバー１５０でのみ可能であるが、第１シナリオは標準Ｓ２Ｓ（ｓｅｒｖｅｒ ｔｏ ｓｅｒｖｅｒ）リクエスト、あるいはある形式のリライトまたはリダイレクト（ｒｅｗｒｉｔｅ ｏｒ ｒｅｄｉｒｅｃｔ）の場合に可能である。

【0070】

本発明によるローカル・サーバー・コンテンツの使用によって実現できるライセンシングの作用効果は説明するまでなく明白である。この点に関して、ローカル・メディアは、曲が、サービスのエンド・ユーザーが制御、あるいは所有するローカル・サーバーに存在する時に使用できる。これは、ユーザーのパーソナル・メディア・ライブラリー・アカウント内に、あるいはユーザーのローカル・コンピュータのいずれかの部分内に既に存在しているタイトルあるいはアルバムであればよい。このコンテンツについては、購入によって、あるいはダウンロードまたはギフトによって装填するものである。エンド・ユーザーのコンピュータ上のローカル・ファイルの法的な調達先を確認することは、サービス・プロバイダー、あるいは本システム/方法の所有者の責任ではない。

【0071】

ストリーミング・プロバイダーの場合、ローカル制御のサウンド・レコーディングや音楽作品の複製、頒布や演奏については行わない。従って、計算やレポーティングに権利は使用されず、また追加的なラインセンス料も必要ない。重要なことは、エンド・ユーザーの経験を妨害しないようにこれらトラックを迅速かつ正確に確認できることである。

【0072】

本発明サーバーからメディアを使用する時は、本システム/方法の所有者の曲からより有利な率でライセンスを受けた曲をストリーミング・プロバイダーから曲の代わりに使用できる時である。これは、コンテンツ・コントローラと直接交わされるライセンスによって可能になる。これら新しい直接契約は、アーティストに対して透明性の高いロイヤルティー構造体およびレポーティング・プロセスを与えるものである。

【0073】

直接ライセンスの場合、オンライン使用に対してむしろ“一度で済む”関係を作り出すインタラクティブな使用および非インタラクティブな使用の両者を考慮するものでもある。契約は、配信効率から得られる節約によって計算される特別なロイヤルティー支払いを提供する。現在のところ、共有されたファイルによって作り出された節約の一部を業界に戻す契約はない。

【0074】

これらファイルをストリーミング・プロバイダーに使用すると、インタラクティブな使用および非インタラクティブな使用の全体を通して印税率が下がる作用効果がある。これらタイトルの使用から計算されるすべての演奏およびリスニング時間は、標準的な“フル・レート（ｆｕｌｌ−ｒａｔｅ）”ロイヤルティー計算から削減され、より有利な印税率に基づくものになる。

【0075】

制御されたＰ２Ｐメディアを使用する時は、ファイルが制御されたユーザー・サーバーのセキュア・キャッシュに装填され、ストリーミング・プロバイダー・データ供給毎に再生される予定のファイルと交換可能な時である。ロイヤルティー料からはコストを節約できないが、本発明システムおよび本発明方法従って交わした直接ライセンス下にあるアーティストに有利に働く配信節約がある。従って、このセキュア・キャッシュから来るタイトルが多くなる程、ストリーミング・プロバイダーおよび音楽産業の両者にとって利益が増すことになる。

【0076】

以下に、架空のストリーミング・プロバイダーからの、一か月間のサンプルのプログラミングの要約を示す。この要約は、マルチソースド・コンテンツを使用した場合に得られる節約を示すだけでなく、節約プロセス全体に対して本発明のコンプライアンス計算プロセスが如何に決定的に重要であるかを示すものである。

【0077】

コンプライアンス・エンジンおよびレポーティング・ツールは、以下の情報を引き出すことができる。
１） すべてのＰＲＯ（Ｐｅｒｆｏｒｍｉｎｇ Ｒｉｇｈｔｓ Ｏｒｇａｎｉｚａｔｉｏｎｓ）によって必要とされる特別なスペック（ｓｐｅｃｉｆｉｃａｔｉｏｎｓ）に基づく使用レポート。これらスペックには、以下のアイテムが含まれる。
ａ. プラットホーム毎に特別なレポートを提供する（ストリーム・プロバイダー）。
ｂ. プラットホーム・タイプに基づき、かつストリーミング・プロバイダー毎に収益情報を安全に入力できる能力を提供する。
ｃ. 特別なユーザー・セッション毎に使用レポートを作成し、平均リスニング時間合計、再生毎の合計、リスニングセッション毎の合計を出す。
ｄ. 使用情報および収益情報のすべてを個別の使用レポート/ＳＰ/ＰＲＯに集積する能力を備える。

【0078】

２） サウンド・イクスチェンジレポーティングおよび支払いの使用スペック
ａ. プラットホーム毎に特別なレポートを提供する（ストリーム・プロバイダー）。
ｂ. プラットホーム・タイプに基づき、かつストリーミング・プロバイダー毎に収益情報を安全に入力できる能力を提供する。
ｃ. 特別なユーザー・セッション毎に使用レポートを作成し、平均リスニング時間合計、再生毎の合計、リスニングセッション毎の合計を出す。
ｄ. 使用情報および収益情報のすべてを個別の使用レポート/ＳＰに集積する能力を備える。

【0079】

３） インタラクティブな使用のために使用する−レコード・レーベルおよび発行元全体の使用スペック

【0080】

４） 権利モジュール“コンプライアンス・ダッシュボード”−各種の契約タイプに関してコンテンツ・コントローラによって認められた権利、印税率、クリアランス・ステータスおよび使用を（メディア アセット（ｍｅｄｉａ ａｓｓｅｔ）毎に）統括変更または個別変更できる能力
ａ．レコード・レーベル・ライセンス契約
ｂ. レジデンシャル・ライセンス契約
ｃ. 商用ライセンス契約
ｄ. マルチプル・プラットフォームライセンス契約
ｅ．バンドルド著作権契約（ｂｕｎｄｌｅｄ Ｒｉｇｈｔｓ Ａｇｒｅｅｍｅｎｔ）
ｆ. ロイヤルティー共有契約（発行管理）
ｇ. 権利放棄/無料

【0081】

５） 以下の“コンテンツ・ソース・タイプ”それぞれに対してすべてのプラットホームおよびサービス全体にわたるすべてのレポート必要条件の個別かつ集積化アカウントを提供できる能力
ａ．１００％ストリーミング・プロバイダー（ＳＰ）コンテンツ
ｂ. ローカル・サーバー・コンテンツ
ｃ. コントロールド・Ｐ２Ｐ・コンテンツ
ｄ. バーティゴ・ライセンスド・コンテンツ（Ｖｅｒｔｉｇｏ Ｌｉｃｅｎｓｅｄ Ｃｏｎｔｅｎｔ）

【0082】

６） ロイヤルティー計算エンジン−このシステムは、コンプライアンス・ダッシュボードに入力された率に基づいて日付範囲、コンテンツ・ソース・タイプおよびストリーミング・プロバイダー毎の利用状況データ総合することによって所有されているロイヤルティーを計算できる能力を備えている。ローカル・サーバー・コンテンツ分割会社については、以下の計算式を使用することになる。
Ｘ/Ｘ＋Ｙ_Ｘ（/再生あるいはストリーミング時間率）＝合計ロイヤルティー
但し、Ｘ＝ローカル・サーバー・コンテンツ、Ｙ＝ストリーミング・プロバイダー・コンテンツである。

【0083】

すべての著作権団体を正確に計算し、かつレポートを作成し、コントロールド・プロプライエタリ・コンテンツ（ｃｏｎｔｒｏｌｌｅｄ ａｎｄ ｐｒｏｐｒｉｅｔａｒｙ ｃｏｎｔｅｎｔ：管理された所有権の有るコンテンツ）の利用状況を記憶し、ソースを明らかにし、計算し、そして配信コストの節約を合計総ロイヤルティーに繰り込む能力があるため、これをある種のコンプライアンス・サービスの一つにすることができる。

【0084】

以下、ローカル・ゲートウェイ・サーバーを使用して、従来のラジオ・ステーション・インターネット・ストリームをより効率的にし、そして流されている音質を高くする方法について説明する。以下の説明は、トーク・ショー、スポーツ実況放送などではなく、主に音楽再生のラジオ放送に焦点をあてる。音楽系ラジオ放送はライブ音と予め録音された音のミックスであるため、かなりの節約を引き出すことができ、音質をかなり改善できる。

【0085】

予め録音された音をライブ音またはスタジオ・ミックスから分離でき、これをＰ２Ｐネットワークやローカル・ファイル・システム（確実に曲を再生するためには、メタデータ・ファイル・マッチング・システムを使用すればよい）を介してローカル・コンピュータに配信できる場合には、かなりの節約および音質のかなりの改善を実現できる。次に、予め録音された音およびスタジオ・ミックスをローカル・コンピュータでミキシングすると、バラツキのない放送コンテンツおよび品質を確保できる。本開示においてこれがどのように成し遂げられるかが説明される。

【0086】

インターネットによってラジオをストリーミングする既存の方法の全体を図３０に示す。インターネットによってラジオ・ストリームを配信する方法の場合、一般に、例えば１６３で示すメディア・再生装置（例えば一般的にはＰＣ）を使用する。この装置が、予め録音された音（ミュージック・トラック、ＣＭ（ａｄｖｅｒｔｉｓｅｍｅｎｔｓ）など）を再生し、これをサウンドボード１６４に出力２４８する。次に、スタジオまたは録音システム１７０のサウンドボード１６４に入力１６４される２４９ディスクジョッキーの寸評および／またはコメントやその他のライブ音１６５と再生音とミキシングする。

【0087】

次に、サウンドボード・ミックスを単独オーディオ・ストリームとしてコンピュータ１６６に２５０で示すように出力する。次に、このコンピュータ１６６がオーディオ・ストリームを圧縮し、オーディオ・ストリームを圧縮されたオーディオ・ファイル１６７（通常はＭＰ３ファイル）に出力する。このＭＰ３ファイルは、ファイルがライブ・ストリーミングされ、そして新しいデータがファイルの末端に常に追加されているため、設定時間をもたない。このＭＰ３ファイルは、例えば、コンテンツ配信ネットワーク１６８上に設けられ、オーディオ・ストリームを圧縮し、かつトランスコード（Ｔｒａｎｓ−ｃｏｄｅ）するコンピュータ１６６が、圧縮時にこのファイルに新しいデーを追加２５１する。次に、コンテンツ配信ネットワーク１６８がこのファイルをクライアント１６９に配分２５２する。この説明は、上記と同様に、簡単なシステムの概観であり、市場に出回っている多くの構成と同様である。

【0088】

図２６〜図２９に、本発明のゲートウェイ・サーバー機能拡張システムの全体を示す。この機能拡張システム（ｅｎｈａｎｃｅｄ ｓｙｓｔｅｍ：高度化システム）は、ラジオ・スタジオ１７０、および予め録音された音をサウンドボード１６４に出力する２４８コンピュータ１６３から始まる。本発明のコンピュータ１６３は、プロプライエタリ・ソフトウェア（ｐｒｏｐｒｉｅｔａｒｙ ｓｏｆｔｗａｒｅ：所有権の有るソフトウエア）によって例示されるように、ある特定のイベント・マーカー対応手段を有し、この手段はインストールすると、以下のようになる。

【0089】

１．放送対象の曲をキューイングするディスクジョッキー；即ち、ソフトウェアが曲の待ち行列１７１を作成し、この待ち行列を次にクライアント１７２に配分し、クライアント１７２が放送をストリーミングする。待ち行列１７１は、ディスクジョッキーが放送時に再生する手はずの曲を含む。ローカル・サーバー１８４がこれらの曲をプリロード（ｐｒｅ−ｌｏａｄｓ）２５３するため、ディスクジョッキーがある曲の再生を決定した時に、この曲がクライアント１７２における再生に利用できる。これら曲はリモート・コンテンツ配信ネットワーク・クライアント１７３、Ｐ２Ｐネットワーク・クライアント１７４を介して配信でき、またローカル・ファイル・システム１７５からマッチングあるいはストリーミングできる。

【0090】

２．また、ソフトウェアが、サウンドボード１６４から戻ってくるオーディオ出力１７６を例えば２５６で示すように圧縮し、そしてソフトウェアがオーディオ・ストリーム１７９のフレーム・ヘッダー１７７内にイベント・マーカーを埋め込む。各ＭＰ３オーディオ・ストリーム/ファイル１７９はオーディオ・フレーム１７８からなり、各オーディオ・フレーム１７８はヘッダー１７７を有する。新しいオーディオが加わると、新しいフレーム１７８がファイルに追加される。これらヘッダー１７７は３２ビットの長さである。各ヘッダー１７７内には、プライベートなアプリケーションを使用するためのビットを残しておく。このビットは、イベント開始時には“１”に設定され、そして正規のストリーミング時には“０”に設定される。このデータは、サウンドボード１６４から来るストリーム１７６および/または２５６の両者に埋め込まれる。また、各ヘッダー１７７は案内情報を提供するだけで、オーディオ再生に影響しないビット（たとえば“著作権”、“オリジナル”など）を有する。各ヘッダー１７７は、オーディオ再生に影響しない少なくとも３ビット（プライベートなビットを含む）を有する。これらビットを使用して、イベントＩＤを作成することができる。このＩＤの場合、（イベント・インジケータビットに続いて）これらビットを使用して、“０”と“１”の組み合わせを作り出し、１０秒間の再生を埋める十分なイベントに対処するのに十分特別なＩＤを作成することによって作成すればよい。このように、オリジナルな偶数インジケータビットをもつフレーム・ヘッダーを直後のフレーム・ヘッダーとともに使用する場合には、合計で少なくとも５ビットを使用して、少なくとも３２の、あるいは２^５の特別なマーカーを作成することができる。これは、考えられる１０秒の遅れの間十分なイベントをカバーするために十分以上特別なマーカーになる。これ以上のマーカーが必要な場合には、別なヘッダーを追加して合計を３２から２５６に増やすことができる。各イベントが１０秒間の時間フレーム内で特別なマーカーを有することになるため、これらマーカーを使用して、２つの別なストリーム（一つはライブ・オーディオのみを有し、もう一つはフル・ミックスを有する）をシンクロして、完全なリモート・ミクスド・ストリーム（ｆｕｌｌｙ ｒｅｍｏｔｅｌｙ ｍｉｘｅｄ ｓｔｒｅａｍ）およびローカル・ミクスド・ストリーム（ｌｏｃａｌｌｙ ｍｉｘｅｄ ｓｔｒｅａｍ）（このローカル・ミクスド・ストリームは、スタジオからストリーミングしてきたライブ・オーディオおよびイベント・マーカーにおいてローカル・サーバーによってストリームにミキシングした予め録音されたオーディオからなるストリームである）へハンドオフ（Ｈａｎｄ−ｏｆｆ）して遷移させることができる。これらイベント・マーカーはミキシング指示にリンクして、スタジオからのオーディオ・ミックスを模倣することもできる。

【0091】

３．また、アプリケーションはイベント待ち行列を作成するものでもある。これは、（上述したように）マーカーに続く特別なビットＩＤに基づくイベント・マーカーにマッチングするイベントの待ち行列であればよい。これらイベントはコンピュータ１６３に記録され、このコンピュータがオーディオを圧縮するため、イベントが生じた正確なフレーム１７８に各イベントが登録される。従って、イベントのタイミングが、オリジナル・スタジオ・ミックス１７６内でこれらが生じた正確な場所においてライブ・オーディオ・ストリーム２５６内に確実に埋め込まれることになる。これらイベントは、以下についての情報を含む。
ａ．イベント・マーカーにおいて再生する必要があるのは、どの予め録音されたオーディオか。
ｂ. 予め録音されたオーディオについて、どのフレームが再生を開始するのか。 ｃ. どの音量で再生が始まるのか。
ｄ. そして音量がフェードイン（ｆａｄｅｄ ｉｎ）した場合、音量のフェードイン/フェードアウトの方向および傾きに最適な数式は何か。これを使用すると、スタジオのフェードイン/フェードアウトを模倣できる。この情報は、場合に応じて、周辺フェーダー１８０によって記録すればよく、このフェーダーによってディスクジョッキーが、サウンドボード１６４にオーディオが出力され、音量変化をコンピュータ１６３にレポートしている間にオーディオを制御することができる２５７。
ｅ. イベントの終了（これについては、例えば、フェードイン/フェードアウトストップ時にマークする必要がある）。
ｆ. さらに続くが、省略する。これは、最も見られるタイプのイベントの例である。

【0092】

４．また、アプリケーションが、リモート・サーバーまたはコンテンツ配信ネットワーク１５０上のライブ・オーディオ・ストリーム・ファイル１８１およびフル・ミックス・ファイル１８２を更新２５８する。

【0093】

２つのストリーム１８１/１８２がコンピュータ１６３上のスタジオ１７０内のアプリケーションによって記録され、記号化された後は、ファイル１８１/１８２の両者がコンテンツ配信ネットワークまたはリモート・サーバー１８５にアップロード２５８し、クライアント１７２に配信２５９する。クライアント側アプリケーション１８３（例えばブラウザなど）が、正しくフォーマット化されたＵＲＬを使用することによって、ラジオ・ストリームのリクエストを出す。ＵＲＬは主ドメイン・ネームのサブドメインとして構築する。例えば、このフォーマットのＵＲＬは、場合に応じて、ラジオ・ステーション・ストリーム・ラジオ・ステーション（ｒａｄｉｏ ｓｔａｔｉｏｎ ｓｔｒｅａｍ ｒａｄｉｏｓｔａｔｉｏｎ）．ｖｅｒｔｉｇｏｍｕｓｉｃ．ｃｏｍ／［ｓｈｏｗ ｉｄ］を参照できるように使用することができる。バーティゴ・ゲートウェイ・サーバー１８４がインストールされていない場合、このＵＲＬがクライアントを完全ミクスド・スタジオ・ストリーム１８２に照会し、従来のインターネット・ラジオ・ストリームと同様な方法でファイルを再生することになる（上記説明および図３０を参照）。

【0094】

バーティゴ・ゲートウェイ・サーバー１８４がインストールされている場合、サーバー１８４がこのサブドメイン・ネームをそれ自体に登録し、次にローカル・クライアント・アプリケーション１８３からのこのサブドメイン・ネームに対するすべてのリクエストに対処する。この場合、ストリームのリクエストをクライアント・アプリケーション１８３が出すと、このリクエストはゲートウェイ・サーバー１８４によって受け付けられる２６０。リモート・コンテンツ配信ネットワーク１８５から完全ミクスド・ストリーム１８２を提供することによってゲートウェイ・サーバー１８４が処理を開始する。ストリームの開始後は、ゲートウェイ・サーバー１８４が予め記録されたオーディオ待ち行列１７１にリクエストを出し、Ｐ２Ｐ１７４、リモート・コンテンツ配信ネットワーク１７３、またはローカル・ソース１７５からの予め記録されたオーディオをキャッシュに保存する２５３。また、ゲートウェイ・サーバー１８４はスタジオ・コンピュータ１６３によって常に更新されているリモート・データベース１８６からイベント待ち行列をロード２６１する。ゲートウェイ１８４は、ストリーム１８１が生きている間、イベント２６１について最新情報を常に受け取ることになる。

【0095】

フル・スタジオ・ミックス１８２からライブ・オーディオ・オンリー・ストリーム１８１への遷移を行うために、ゲートウェイ・サーバー１８４はストリーム１８１、１８２の両者をロードし、フル・ミックス１８２にのみ対応する。ゲートウェイ・サーバー１８４およびミキシング・アプリケーション１８７がすべてのタスクを完了する十分な時間をもつとことを担保するため、サーバー１８４はライブ・データの受け取りから１０〜２０秒間にストリームを開始し、カスタム・ラグを作り出し、このラグを使用してシステムがミキシングおよび遷移を実行する時間を作り出す。ゲートウェイ・サーバー１８４は、ライブ・オーディオ・ストリーム１８１に遷移するためにフル・スタジオ・ミックス１８２フレーム・ヘッダー１７７においてイベントビット分待機する。

【0096】

ゲートウェイ・サーバー１８４が、イベントビットにおいて２つのストリーム１８２/１８１を調整する。この調整については、イベントビット後にビット・コードをマッチングすればよい。ビット・コードが両イベントについてマッチした場合には、探索時間がストリームの最後１０〜１５秒のみなので、これらイベントがマッチしたと判断する。３２の特別なビット・コードが十分ユニークなため、マッチしたイベントが実際に同一であることを保証する。イベントビットがマッチした後は、ゲートウェイ・サーバー１８４が、イベントビットが生じたフレーム１７８でフル・スタジオ・ミックス１８２からライブ・オーディオ・ミックス１８１に遷移する。この方法を使用すると、ストリームからストリームへの遷移を継ぎ目なく行え、フレーム対フレームの精度も高い。

【0097】

ゲートウェイ・サーバー１８４がライブ・オーディオ・オンリー・ストリーム１８１に遷移した後は、イベントビットが出現した時にイベント・データベース１８６に保存されているミキシング指示に追従することを開始する。イベントビットについてはライブ・ストリームの最後の１０〜１５秒のみを追跡するため、ビット・コードを使用して、イベントビット・コードにマッチするデータベース１８６内のイベントデータを突き止める。

【0098】

ここで、第１イベントが予め記録されているオーディオ待ち行列１７１内の第１曲の再生であるとする。アプリケーションは、既にオーディオの少なくとも１０〜２０％をキャッシュに保存している。この場合、ゲートウェイ・サーバー１８４がライブ・オーディオ・ストリーム１８１および予め記録されているオーディオ・データ１８８を内部ミキシング・アプリケーション１８７（ＳｏＸなどのコマンド・ライン・アプリケーションや特注アプリケーションであればよい）に回す。

【0099】

また、ゲートウェイ・サーバー１８４は、ミキシングデータをアプリケーションに送信２６１し、ライブ・オーディオ・ストリーム１８１と予め記録されているオーディオをミキシングし、フル・スタジオ・ミックス１８２を模倣する。このためには、スタジオ１７０で記録される、ディスクジョッキーのフェーデングおよびタイミングを模倣するイベントに対応するデータを使用すればよい。次に、アプリケーション１８７が新しいローカル・ミクスド・ファイル１８９を出力し、リクエストを出すクライアント１８３にこれを提供する。これはすべて継ぎ目なしに行うことができる。サーバーが、ライブ・データ伝送とデータのクライアント・アプリケーションへの提供との間にかなりのラグを作ることができるからである。このラグがオーディオ提供の開始時に存在している限り、このラグ・タイムフレームを使用してオーディオをミキシングし、作成できる。

【0100】

ラジオ・ステーションまたはラジオ・ショーが広告のみを組み込み、ライブ・ストリームを予め記録されているオーディオ（例えば音楽）をミキシングしない場合には、ある種の広告組み込み手段をシステムに装備する。この手段は以下のように、また全体を図３１および図３２に示すように、機能する。

【0101】

ソフトウェア１９１を介してラジオ・ショーをコンピュータ１９０に記録し、このソフトウェアが、広告やその他の予め記録されているファイルを再生する必要がある時に、オーディオを符号化し、マークする。広告マーカーについては、所定の無音時間の経過後にマークする。これを実現するためには、符号化アプリケーション１９１が所定の広告を示す無音３０１よりも数秒間長いラグ３００を作り出す。従って、ラジオ・パーソナリティーが広告時間を記録し、これを挟む必要がある場合、ラジオ・パーソナリティーは例えば３０１で示すように５秒間マイクをミュートするか封じるだけでよい。例えば３０１で示す無音が５秒間経過すると、符号化アプリケーションが５秒間の無音の最後３０２ではなく、最初３０３においてオーディオ・ストリームにマークする。このように、エンド・リスナーは広告以外の無音を聞くことはない。

【0102】

所定の無音タイムフレームが経過した後は、アプリケーション１９１が、ラジオ・パーソナリティーを促して、どの位の長さ広告を再生すべきかを示し、選択したタイムフレームに従って広告を組み込む。このオーディオ・ストリームをアプリケーション１９１によって符号化し、マークし、ラジオ・パーソナリティーが選択したサーバーまたはコンテンツ配信ネットワーク１９２にアップロードする。

【0103】

リスナーがその装置１９３からクライアント・アプリケーション１９４（例えばブラウザやモバイル・アプリ）を介してラジオ・ストリームについてリクエストする場合、リクエストはゲートウェイ・サーバー１９５に送られる２７０。次に、ゲートウェイ・サーバー１９５がオーディオ・ストリームのリクエストをクラウド/サーバー１９２に送り２７１、これがオーディオに応答し、これをゲートウェイ・サーバー１９５に配信する２７２。

【0104】

次に、ゲートウェイ・サーバー１９５がオーディオ・ストリームをクライアント１９４に配信する２７３。ゲートウェイ・サーバー１９５が、小型のバッファ（２〜５秒分のデータ）を作成するため、オーディオ・ストリーム内で広告マーカーが確認されると、ゲートウェイ・サーバー１９５が広告サーバー１９６から適正な広告を引き出し２７４、これを特定の時間で組み込みことができる。モバイル・アプリケーションの場合、ゲートウェイ・サーバー１９４を使用せずにアプリケーションは、広告を組み込み必要がある。モバイル・アプリケーションは、これをアプリケーションのソース・コードに組み込む必要がある。従って、モバイル・アプリケーションの場合、広告マーカーを検出するコードをもつ必要があり、広告マーカーの開始時に広告を組み込む必要がある。

【0105】

以上の本発明の説明は、多くの限定性を有しているが、これらの限定性は本発明の範囲を限定するものではなく、本発明の例示に過ぎない。例えば、本発明は、本質的に、選ばれたデータ・ファイルをエンド・ユーザーに配信（例えばストリーミング）するＰ２Ｐコンテンツ配信ネットワークを提供することをその範囲に包含するものである。

【0106】

本発明のいわゆるＰ２Ｐコンテンツ配信ネットワーク（ＣＤＮ）、即ちＰ２ＰＣＤＮの場合、例えば２で示すクライアント、例えば３で示すＰ２Ｐゲートウェイ・サーバー、例えば４で示すリソース・ネーム・サーバー（ＲＮＳ）、およびコンピュータ密度の高いネットワークを有するのが好ましく、このコンピュータ密度の高いネットワーク（ｃｏｍｐｕｔｅｒ-ｐｏｐｕｌａｔｅｄ ｎｅｔｗｏｒｋ：多くのコンピュータを備えたコンピュータネットワーク）はローカル・サーバー、ピア・コネクテッド・サーバー（ｐｅｅｒ−ｃｏｎｎｅｃｔｅｄ ｓｅｒｖｅｒｓ）、クラウド・ロッカー、クラウド・ストレージ、クラウド・メディア、および/または商用（音楽）ストリーミング・サービス提供インフラストラクチャーなどで構成すればよい。

【0107】

クライアントがＰ２Ｐゲートウェイ・サーバーと交信し、Ｐ２Ｐゲートウェイ・サーバーがＲＮＳおよびコンピュータ密度の高いネットワークと交信する。ＲＮＳは、基本的にはコンピュータ密度の高いネットワーク内のデータ・リソース保存場所をキャッシュに保存し、コンピュータ密度の高いネットワーク内の最適な（例えば（ａ）プライス効率が最も高い、あるいは（ｂ）ソースの音質が最も高いなど）データ・リソース保存場所でリソースリクエストを解決する機能をもつ。

【0108】

Ｐ２Ｐゲートウェイ・サーバーがＲＮＳを介して最適なデータ・リソース保存場所についてリクエストを出し、そしてこれを受け取り、また最適なデータ・リソース保存場所を介してコンピュータ密度の高いネットワークからデータ・ファイルについてリクエストを出し、そしてこれを受け取り、そして受け取られたデータ・ファイルを処理し、クライアントおよびエンド・ユーザーにデータ・ファイルを配信する。

【0109】

本発明のコンテンツ配信ネットワーク、即ちＣＤＮの場合、既に詳しく説明したクライアントおよび/またはサーバーの真贋を確認する特定のクライアントおよび/またはサーバー真贋確認手段などの構成要素からなる基本システムに多数のオプション有するが、既に詳しく説明するように好適な増設装置を組み込む。さらに、非破損データ・ストリームの配信機能を高度化するため、本発明では、既に詳しく説明した特定のデータ配信フラグメンテーション手段を使用する。

【0110】

ＲＮＳとの接続のさいに機能する特定のリソース索引付け手段によってリソース保存場所に索引を付けて、ネットワーク効率または方法効率を高度化するのが好ましい。特に、リソース索引付け手段については、データ・ファイル・メガデータから独立してデータ・ファイルを素早くかつ効果的にマッチングする特定のファイル・マッチング手段を有するのが好ましい。本発明のファイル・マッチング手段については、既に許可を受けた米国特許出願Ｎｏ．１３/０６５，２５４（ＵＳ Ｐａｔｅｎｔ Ｎｏ．８，５８９，１７１）により詳しく記載されている。なお、これら公報の記載についてはここに援用するものとする。

【0111】

即ち、本発明のファイル・マッチング手段の場合、特定のデータ抽出手段、特定の要約統計量誘導手段、特定のカスタム・マーカー発生手段、特定のカスタム・マーカー対応手段、および特定のカスタム・マーカーアクセス手段を有するのが好ましい。

【0112】

データ抽出手段は、第１データ・ファイルから波形データを抽出する。抽出された波形データは長さセグメント値を有する。これら長さセグメント値は、データ抽出ベースラインに対して抽出され、トラフ対ベースライン（ｔｒｏｕｇｈ−ｔｏ−ｂａｓｅｌｉｎｅ）長さセグメント値およびピーク対ベースライン（ｐｅａｋ−ｔｏ−ｂａｓｅｌｉｎｅ）長さセグメント値を有する。要約統計量誘導手段は、抽出された波形データから要約統計量を誘導する。これら要約統計量は長さセグメント値から誘導され、トラフ対ベースライン長さセグメント統計量およびピーク対ベースライン長さセグメント統計量を有する。

【0113】

カスタム・マーカー発生手段が、誘導された要約統計量に基づいてカスタム・マーカーを発生し、そしてカスタム・マーカー対応手段がカスタム・マーカーを第１データ・ファイルに対応付け、これによってカスタム・マークド・データ・ファイルを構築する。カスタム・マーカーアクセス手段が、第２データ・ファイルをこのマークド・データ・ファイルと比較する際にカスタム・マーカーにアクセスし、データ・ファイルマッチがポジティブであることを示す。

【0114】

Ｐ２Ｐコンテンツ配信ネットワークは、さらに、既に詳しく説明したように、データファイル伝送を高度化するためにイベント・マーカーをデータ・ファイルのフレーム・ヘッダー内で対応付ける特定のイベント・マーカー対応付け手段を有することができる。この点に関して、本発明では、さらに特定の広告組み込み手段を有していてもよく、この手段を使用して、上記特定のイベント・マーカー対応付け手段によって広告コンテンツをデータ・ファイルに組み込むことができる。

【0115】

本発明は、データ・オリジン・アグナースティックであるため、データ・ルーティング管理システムを提供するものでもある。本発明のデータ・ルーティング管理システムの場合、データ・ルーティング・コンプライアンス・アプライアンスまたはエンジンと、以上説明してきたコンテンツ配信ネットワークを組み合わせて構成するのが好ましい。従って、このデータ・ルーティング・コンプライアンス・アプライアンスが、データ・ファイルからなるか、あるいは保存している複数のデータ・ソースを有するコンテンツ配信ネットワークと交信する。

【0116】

コンテンツ配信ネットワークが、選ばれたデータ・ファイルを最適なデータ・ソース保存場所からエンド・ユーザーに配信する。この最適なデータ・ソース保存場所はデータ・ソースからなる群から選択する。このように、本発明のコンプライアンス・アプライアンスまたはエンジンは、（ａ）工業権管理、（ｂ）コンプライアンス・モニタリングおよび/または（ｃ）データ・ファイル伝送のコンプライアンス・レポーティングを提供するものである。

【0117】

本質的に、本発明は、（１）ローカル・サーバー（例えばＰ_{ＡＮＤＯＲＡ}（登録商標）ラジオによって例示されるディジタルラジオ）から間接的なリクエスト・ストリームを配信する機能；間接リクエスト・ストリームをピア・コネクテッド・サーバーから配信する機能；間接リクエスト・ストリームを第２直接リクエスト・ソース（例えばｉＴｕｎｅｓ ＭａｔｃｈまたはＳｐｏｔｉｆｙ、あるいはＤｒｏｐＢｏｘなどのクラウド・ロッカー、あるいはクラウド内の任意のメディア）から配信する機能；再生またはストリーミングを行う第２直接リクエスト・ソースの権利に基づいて間接リクエスト・ストリームをピア・コネクテッド・サーバーから配信する機能；（ａ）プライス効率または（ｂ）ソースの音質に基づいて直接リクエスト・ストリームを第２直接リクエスト・ソースから配信する機能；および（６）再生またはストリーミングを行う第２直接リクエスト・ソースの権利に基づいてピア・コネクテッド・ソースから直接リクエスト・ストリームを配信する機能を提供するものである。本発明システムのデータ・オリジン・アグナースティックな性質、あるいはクラウド・アグナースティックな性質を考えると、本発明システムは、コンテンツの配信元が上記実施例１〜６を含む元のリクエストされたソース・サービス以外の二次的なソースである場合には、（ａ）工業権管理、（ｂ）コンプライアンス・モニタリングおよび/または（ｃ）データ・ファイル伝送のコンプライアンス・レポーティングを提供するものである。

【0118】

本開示は、選ばれたデータをコンピュータ密度の高い環境においてエンド・ユーザーに最適に（例えば効率的に）転送する、特定のオリジン・アグナースティックな（出所不可知の、データ源不可知の）データ配信方法にも含まれる。本発明の、オリジン・アグナースティックなデータ配信方法の場合、クライアント、Ｐ２Ｐゲートウェイ・サーバー、およびリソース・ネーム・サーバー（ＲＮＳ）がコンピュータ密度の高いネットワークと交信するステップ、およびＲＮＳによってコンピュータ密度の高いネットワーク内のデータ・リソース保存場所をキャッシュに保存するステップを有することが好ましい。

【0119】

最適なデータ・リソース保存場所については、ＲＮＳのキャッシュに保存したデータ・リソース保存場所からクライアントを介してＰ２Ｐゲートウェイ・サーバーによってリクエストすることができる。これらリソースリクエストについては、ＲＮＳによって最適なリソース保存場所で解決する。ＲＮＳを介してＰ２Ｐゲートウェイ・サーバーによって最適なリソース保存場所を受け取った後、コンピュータ密度の高いネットワークからのデータ・ファイルを、受け取られた最適なリソース保存場所を介してリクエストするか、あるいは実行可能にする。次に、リクエストされたデータ・ファイルを伝送（即ち送信および受信）し、処理してからデータ・ファイルをクライアントに配信する。

【符号の説明】

【0120】

２、１０５、１６９、１７２、１８３、１９４：クライアント
３、１００、１１０、１４１、１８４、１９４、１９５：ゲートウェイ・サーバー
４：リソース・ネーム・サーバー（ＲＮＳ）
１０１：ローカル・ネットワーク
１０４：モート・ソース
１０８、１０９、１３４：リソース索引付けサーバー
１３３、１５０：ローカル・ゲートウェイ・サーバー
１３８、１４４、１６１：Ｐ２Ｐネットワーク
１７７：；レーム・ヘッダー
１５０、１６８、１７３、１８５、１９２、２５２：コンテンツ配信ネットワーク
１８３、２０１、２０３、２１１、２１４、２１６、２１７、２１８、２２９、２３７、２４２：リクエスト

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】