図面 (/)

技術 P2Pコンテンツ配信ネットワーク、方法、および管理システム

出願人 リークリー,グレゴリー,エイチ.サヴェノク,アレクサンダーサヴェノクパヴェル
発明者 リークリー,グレゴリー,エイチ.サヴェノク,アレクサンダーサヴェノクパヴェル
出願日 2014年12月8日 (5年11ヶ月経過) 出願番号 2016-557542
公開日 2017年2月2日 (3年9ヶ月経過) 公開番号 2017-504134
状態 特許登録済
技術分野 計算機間の情報転送
主要キーワード データ発信源 パーソナリティー 権利放棄 セグメント値 真贋確認 卸売り業者 プラグイン形式 両イベント
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年2月2日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

本発明は、選ばれたデータ・ファイルエンドユーザーに配信するP2Pコンテンツ配信ネットワークを提供することを目的とする。

構成

コンテンツ配信ネットワークは、コンピュータ密度の高いネットワーク内においてクライアント、P2Pゲートウェイサーバー、およびリソースネーム・サーバー(RSN)を有する。RNSが、コンピュータ密度の高いネットワーク内のデータ・リソース保存場所キャッシュに保存し、コンピュータ密度の高いネットワーク内の最適なデータ・リソース保存場所でリソースリクエストを解決する。ゲートウェイ・サーバーが、RNSによって最適なデータ・リソース保存場所についてリクエストを出し、これを受け取り;この最適なデータ・リソース保存場所によってコンピュータ密度の高いネットワークからデータ・ファイルをリクエストし、これを受け取り;そして受け取ったデータ・ファイルを処理して、データ・ファイルをクライアントに配信する。従って、このネットワークによって、オリジン・アグナースティックデータ配信方法で選ばれたデータ・ファイルをエンド・ユーザーに最適に配信できる。データ・ルーティング管理装置が、コンテンツ配信ネットワークおよびデータ・ファイル伝送の工業権管理、コンプライアンスモニタリングおよび/またはコンプライアンス・レポーティングを管理する。

概要

背景

概要

本発明は、選ばれたデータ・ファイルエンドユーザーに配信するP2Pコンテンツ配信ネットワークを提供することを目的とする。コンテンツ配信ネットワークは、コンピュータ密度の高いネットワーク内においてクライアント、P2Pゲートウェイサーバー、およびリソースネーム・サーバー(RSN)を有する。RNSが、コンピュータ密度の高いネットワーク内のデータ・リソース保存場所キャッシュに保存し、コンピュータ密度の高いネットワーク内の最適なデータ・リソース保存場所でリソースリクエストを解決する。ゲートウェイ・サーバーが、RNSによって最適なデータ・リソース保存場所についてリクエストを出し、これを受け取り;この最適なデータ・リソース保存場所によってコンピュータ密度の高いネットワークからデータ・ファイルをリクエストし、これを受け取り;そして受け取ったデータ・ファイルを処理して、データ・ファイルをクライアントに配信する。従って、このネットワークによって、オリジン・アグナースティックデータ配信方法で選ばれたデータ・ファイルをエンド・ユーザーに最適に配信できる。データ・ルーティング管理装置が、コンテンツ配信ネットワークおよびデータ・ファイル伝送の工業権管理、コンプライアンスモニタリングおよび/またはコンプライアンス・レポーティングを管理する。

目的

本発明は、後置ステムを変更することなく既存の標準コンテンツ配信ネットワーク、即ちサーバー環境(サーバーの構成)に付加できるP2Pコンテンツ配信ネットワーク(CDN)を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

選択されたデータ・ファイルユーザーに配信するP2Pコンテンツ配信ネットワークにおいて、クライアント、P2Pゲートウェイサーバー、およびコンピュータ密度の高いネットワーク通信するリソースネーム・サーバー(RNS)を有し、前記RNSが、(1)前記コンピュータ密度の高いネットワーク内のデータ・リソース保存場所にデータを保存し、そして(2)前記コンピュータ密度の高いネットワーク内の最適なデータ・リソース保存場所でリソースリクエストを解決し、前記ゲートウェイ・サーバーが、(1)前記RNSを介して最適なデータ・リソース保存場所をリクエストし、かつこれを受け取り、(2)前記最適なデータ・リソース保存場所を介して前記コンピュータ密度の高いネットワークからデータ・ファイルをリクエストし、かつこれを受け取り、そして(3)受け取ったデータ・ファイルを処理して、データ・ファイルを前記クライアントに配信することを特徴とするP2Pコンテンツ配信ネットワーク。

請求項2

クライアント真贋確認手段を有し、このクライアント真贋確認手段でクライアントの真贋を確認する請求項1に記載のP2Pコンテンツ配信ネットワーク。

請求項3

サーバー真贋確認手段を有し、このサーバー差真贋確認手段でサーバーの真贋を確認する請求項1に記載のP2Pコンテンツ配信ネットワーク。

請求項4

データ配信フラグメンテーション手段を有し、このデータ配信フラグメンテーション手段で非破損データストリーム配信機能を高度化する請求項1に記載のP2Pコンテンツ配信ネットワーク。

請求項5

リソース索引付け手段を有し、このリソース索引付け手段でリソース保存場所に索引を付け、これによって前記P2Pコンテンツ配信ネットワークを高効率化する請求項1に記載のP2Pコンテンツ配信ネットワーク。

請求項6

前記リソース索引付け手段がファイル・マッチング手段を有し、このファイル・マッチング手段でデータ・ファイル・メタデータから独立してデータ・ファイルをマッチングし、これによって前記P2Pコンテンツ配信ネットワークを高効率化する請求項1に記載のP2Pコンテンツ配信ネットワーク。

請求項7

(a)工業権管理手段、(b)コンプライアンスモニタリング手段および/または(c)コンプライアンス・レポーティング手段を有し、これら手段でデータ・ファイル伝送を管理、モニタリングおよび/またはレポーティングする請求項1に記載のP2Pコンテンツ配信ネットワーク。

請求項8

イベントマーカー対応手段を有し、このイベント・マーカー対応手段で前記データ・ファイルのフレームヘッダー内のイベント・マーカーを対応付け、そしてこのイベント・マーカー対応手段でデータ・ファイルの伝送機能を高度化する請求項1に記載のP2Pコンテンツ配信ネットワーク。

請求項9

広告組み込み手段を有し、この広告組み込み手段で、前記イベント・マーカー対応手段によって広告コンテンツをデータ・ファイルに組み込む請求項8に記載のP2Pコンテンツ配信ネットワーク。

請求項10

コンピュータ密度の高い環境でデータ源不可知のデータを配信する方法であって、選ばれたデータ・ファイルのエンド・ユーザーのへの最適な配信方法において、クライアント、P2Pゲートウェイ・サーバー、およびリソース・ネーム・サーバー(RNS)をコンピュータ密度の高いネットワークと交信させるステップ、前記RNSによって前記コンピュータ密度の高いネットワーク内にデータ・リソース保存場所をキャッシュに保存するステップ、RNSの保存場所に保存されたデータ・リソース保存場所から前記P2Pゲートウェイ・サーバーによって最適なデータ・リソース保存場所にリクエストを出すステップ、前記RNSを介して最適なリソース保存場所でリソースリクエストを解決するステップ、前記RNSを介して前記P2Pゲートウェイ・サーバーで最適なリソース保存場所を受け取るステップ、受信された最適なリソース保存場所を介して前記コンピュータ密度の高いネットワークから、選ばれたデータ・ファイルをリクエストするステップ、リクエストされた、選ばれたデータ・ファイルを伝送するステップ、および伝送された、選ばれたデータ・ファイルを処理して、前記クライアントに選ばれたデータ・ファイルを配信するステップを有することを特徴とするデータ源不可知のデータを配信する方法。

請求項11

クライアント真贋確認手段によってクライアントの真贋を確認するステップを有する請求項10に記載のデータ源不可知のデータを配信する方法。

請求項12

サーバー真贋確認手段によってサーバーの真贋を確認するステップを有する請求項10に記載のデータ源不可知のデータを配信する方法。

請求項13

データ配信フラグメンテーション手段によってデータ・ファイル配信時データ・ファイルを断片化し、このデータ配信フラグメンテーション手段で非破損データ・ストリームの配信機能を強化する請求項10に記載のデータ源不可知のデータを配信する方法。

請求項14

リソース索引付け手段によってリソース保存場所に索引を付けるステップ有し、このリソース索引付け手段によって方法を高効率化する請求項10に記載のデータ源不可知のデータを配信する方法。

請求項15

ファイル・マッチング手段によってデータ・ファイル・メタデータから独立してデータ・ファイルをマッチングするステップを有し、このファイル・マッチング手段で方法を高効率化する請求項14に記載のデータ源不可知のデータを配信する方法。

請求項16

データ・ファイル伝送を行うさいに(a)工業権の管理、(b)コンプライアンスのモニタリングおよび/または(c)コンプライアンスのレポーティングを行うステップを有する請求項10に記載のデータ源不可知のデータを配信する方法。

請求項17

イベント・マーカー対応手段によって前記データ・ファイルのフレーム・ヘッダー内のイベント・マーカーを対応付けるステップを有し、このイベント・マーカー対応手段でデータ・ファイル伝送を高度化する請求項10に記載のデータ源不可知のデータを配信する方法。

請求項18

前記イベント・マーカー対応手段によって広告コンテンツをデータ・ファイルに組み込むステップを有する請求項17に記載のデータ源不可知のデータを配信する方法。

請求項19

前記のデータ・ファイルをマッチングするステップが、対応するデータ抽出手段によって第1データ・ファイルから波形データを抽出するステップを有し、抽出された波形データが長さセグメント値を有し、この長さセグメント値はデータ抽出ベースラインに対して抽出され、かつトラフベースライン長さセグメント値およびピーク対ベースライン長さセグメント値を有し;そして前記のマッチングステップがさらに、前記の長さセグメント値から誘導され、かつトラフ対ベースライン長さセグメント値およびピーク対ベースライン長さセグメント値を有する要約統計量を前記の抽出された波形データから誘導するステップ;前記の誘導された要約統計量に基づいてカスタム・マーカーを生成するステップ;前記カスタム・マーカーを前記第1データ・ファイルに対応付け、これによってカスタム・マークド・データ・ファイルを構築するステップ;および第2データ・ファイルを前記カスタム・マークド・データ・ファイルと比較するさいに前記カスタム・マーカーにアクセスして、メディア・ファイルマッチングをポジティブにするステップを有する請求項15に記載のデータ源不可知のデータを配信する方法。

請求項20

データルティング・コンプライアンス・アプライアンスおよびコンテンツ配信ネットワークを有し、このデータルーティング・コンプライアンス・アプライアンスが前記コンテンツ配信ネットワークと交信し、前記コンテンツ配信ネットワークが複数のデータ・ソースを有し、このデータ・ソースがデータ・ファイルを有し、前記コンテンツ配信ネットワークが選ばれたデータ・ファイルを最適なデータ・ソース保存場所からエンド・ユーザーに配信し、この最適なデータ・ソース保存場所が前記データ・ソースからなる群から選択され、前記コンプライアンス・アプライアンスが(a)工業権管理、(b)コンプライアンス・モニタリングおよび/または(c)データ・ファイル伝送のコンプライアンス・レポーティングを行うことを特徴とするデータ・ルーティング調整システム

技術分野

0001

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

0002

US Patent No.8,589,171

0003

[発明の要約]
本発明は、後置ステムを変更することなく既存の標準コンテンツ配信ネットワーク、即ちサーバー環境(サーバーの構成)に付加できるP2Pコンテンツ配信ネットワーク(CDN)を提供する。本発明のP2PCDNの場合、エンドユーザークライアントマシン上にローカル・P2Pゲートウェイ・サーバーをインストールする時に構築する。ゲートウェイ・サーバーが暗号化された、あるいは暗号化されていない接続(例えばHTTP、HTTPS、セキュアソケット、および/またはソケット(Secure Socket, and/or Socket)など)を介してメディア消費クライアントからリクエストを受け取る。

0004

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

0005

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

0006

また、本発明はリソース・ネーム・サーバー(RNS)を提供し、このRNSはリソースURLのネームおよびリソース保存場所(即ちIPアドレス)をキャッシュに保存し、マシン・アドレスリソースリクエストを解決する。マッチしていないメディアタイプの場合の全体的なプロセス、即ち方法を以下に示す。
1.クライアントがリソースに対するリクエストをゲートウェイ・サーバーに送る。
2.次に、ゲートウェイ・サーバーがリクエストをRNSに送り、リソース・アドレスでリソースリクエストを解決する。
3.リソースリクエストが最適な(最小コストの)リソース保存場所にマッチした後は、リソース・ロケーション・データがゲートウェイ・サーバーに戻る。
4.次に、ゲートウェイがリソース・データリクエストを適正なマシンやサーバー・クラスターに送信する。
5.マシンまたはサービス・クラスターが、リクエストされたデータをローカル・マシン上のゲートウェイ・サーバーに提供することによってこれに応答する。
6.ゲートウェイ処理がデータを整理・確証し、つぎにリソースをローカル・マシン上のクライアントに配信する。

0007

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

0008

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

0009

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

0010

ゲートウェイ・サーバーがリクエストを受け取り、次に、リソース・ネーム・サーバー(即ちリソース索引付けサーバー)でリソースのリクエストを解決する。RNSは、リソース発信元あるいはピアであればよいリソース保存場所(IPアドレス)でこれに答える。ネットワークがデータ・オリジン・アグナースティック(data origin agnostic(データ源について何も知られていない))なため、ピアデータ中央データ・サーバーによって管理はされず、むしろリクエストが回され、ゲートウェイ・サーバーでキャッシュに保存されている間RNS上で索引が付けられる。

0011

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

先行技術

0012

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

図面の簡単な説明

0013

複数行サブストリームパケットおよび複数カラム検証パケットを有するデータ・ファイルの断片化された構成を示す概略図である。
本発明システム概観を示す概略図であり、サーバー・クラスターのクラウドとリソース・ネーム・サーバーの中間に位置するゲートウェイ・サーバーを示す図である。
本発明システムの概観を示す第2の概略図であり、サーバー・クラスターのクラウドとリソース・ネーム・サーバーの中間に位置するゲートウェイ・サーバーを示す図である。
ドメイン・ネーム・サーバーシステムの概観を示す概略図である。
リソース・ネーム・サーバーシステムの概観を示す概略図である。
プラグイン形式セキュリティ対策の概観を示す概略図である。
クライアントがデータをリクエストし、サーバーがデータを配信する従来のクライアント−サーバー関係を示す概略図である。
データ請求が、ファイルが見つけられるまでピア間において交換される場合に各ピアがサーバーおよびクライアントの両者を務めるP2Pアンマネージドネットワークの概観を示す概略図である。
統括サーバーがリソースに索引を付け、ピアがその利用可能性をレポートし、登録するP2Pマネージドネットワークの概観を示す概略図である。
P2Pネットワークを統括データソース/索引付けサーバーを併用して、ピア配信を低コスト化するが、統括データ・ソースのコンスタテンシー(consistency−バラツキのなさ)および速度を確保するP2P統括ハイブリット・ネットワークの概観を示す概略図である。
P2Pゲートウェイ・サーバー・ネットワークの概観を示す概略図である。
ローカル・サーバーおよびブラウザをビューするために接続構造セキュリティを確保する方法を示す概略図である。
プラグインによってローカル・ゲートウェイ・サーバーを検証する方法を示す概略図である。
第1回リクエストにおける、ファイル・マッチングを行わないリソース索引付け構成を示す概略図である。
第2回リクエストにおける、ファイル・マッチングを行わないリソース索引付け構成を示す概略図である。
第1回リクエストにおけるプログレッシブなクラウド索引付け構成を示す概略図である。
ローカル・リソース索引付け構成を示す概略図である。
第1の、索引を付けたリソースリクエスト処理構成を示す概略図である。
第2の、索引を付けたリソースリクエスト処理構成を示す概略図である。
第3の、索引を付けたリソースリクエスト処理構成を示す概略図である。
第4の、索引を付けたリソースリクエスト処理構成を示す概略図である。
ブライセンシング(再実施権許諾)、クラウド配信構成を示す概略図である。
サブライセンシング、P2P配信構成を示す概略図である。
本発明に従ってモバイル装置上での曲の再生をリクエストするストリーミング・プロバイダーを示す第1概略図である。
本発明に従ってモバイル装置上での曲の再生をリクエストするストリーミング・プロバイダーを示す第2概略図である。
本発明のゲートウェイ・サーバーの機能強化システムの概観を示す概略図である。
本発明の予め記録されたメディア待ち行列構成を示す概略図である。
本発明ストリーム分割構成を示す概略図である。
本発明のMP3ファイル構造を示す概略図であり、オーディオ・ストリームのフレームヘッダーおよびオーディオ・フレームを示す図である。
インターネット上にラジオをストリーミングする方法の状態を示す概略図である。
本発明の、オーディオ・ミキシングを行わない広告組み込みシステムの概観を示す概略図である。
本発明の広告マーカー構成を示す概略図である。
ブラウザおよび/またはその他のメディア消費クライアントからのHTTPリクエストをルーティングする方法を示す概略図である。

実施例

0014

[好適な実施態様/方法の詳細な説明]
添付図面を参照して具体的に説明すると、本発明はCDN(コンテンツ配信ネットワーク)および対応するクラウド・アグナースティックP2Pデータストリーミング方法(Methodology for Cloud Agnostic Peer−to−Peer Data Streaming)を提供するものである。上述したように、本発明は参照符号3で示すP2Pゲートウェイ・サーバーからなる。P2Pゲートウェイ・サーバー3は、ローカル・マシン10のクライアント2からの交信(例えば200で示す)を受信する。

0015

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

0016

メディア消費クライアント2には、P2Pリモート・サーバー4即ちリソース・ネーム・サーバー4に対して完全フォーマット化ドメイン・ネームが与えられる。説明を簡単にするために、このドメイン・ネームをwww.rns_server.com.とする。例えば144で示すP2Pコンテンツ配信ネットワーク(CDN)を介してメディア401にリクエストするために、クライアント2は、RNSパブリックドメインネーム有するURL(Uniform Recourse Locator)、およびリクエストされたメディアの保存場所に応じて変動するGET、即ちwww.rns_server.com?media=www.somemediasource.com/media.mp4&protocol=http.を有する。

0017

RNS4がリクエストを受信すると、2つの別個データベースクエリ404を行う。第1クエリはパブリックIP(Internet Protocol)が対処するリクエスト・デバイスを使用して、リクエスト・デバイス・ローカル・ネットワーク101内にネットワーク・ピア3が存在するかどうかを確認する。第2クエリはリソース・データーベースサーチして、P2PCDN144内においてストリーミング(例えば200、207、208、209、210など)に利用できるリクエストされたメディアを用いてピア3を確認する。

0018

クエリ404の結果に基づき、以下のことが生じる。第一にローカル・ネットワーク101内に登録されたピアが存在しない場合、リクエストが403などでメディアのリモート・ソース104に再送され、従ってP2Pネットワーク144は利用できない。ローカル・ネットワーク101内に登録されたピア3が存在する場合、リクエストが402などで、既に第2クエリ404で検索されたリソース保存場所および利用可能性データとともにローカル・ネットワーク・ピア3に再送される。次に、ローカル・ネットワーク・ピア3が(例えば200、207、208、209、210などで)メディア・ストリームを扱う。

0019

なお、例えば4で示すRNS(Resource Name Server)が、本発明を実施するさいに中心になる。RNS4が、リソースURLおよびリソース保存場所(IPアドレス)をキャッシュに保存し、マシン・アドレス(IPアドレス)でリソースリクエストを解決する。マッチングしていないメディアタイプの全体的なプロセスは、以下のようになる。クライアント2が、(200などの)リソースに対するリクエストをゲートウェイ・サーバー3に送信する。

0020

次に、ゲートウェイ・サーバー3が、リクエスト(201など)を区画化された(compartmented)RNS4に送信し、リソース・アドレス(例えば204など)で着信リソースID/URLリクエスト(例えば203など)を解決し、このリソースあるいはIPアドレスを次に、図5により具体的に示すように、ゲートウェイ・サーバー3に(例えば205など示すように)送り返す。換言すると、一旦リソースリクエスト203が202などで最適なリソース保存場所204(例えば、(a)ソースの価格効率が最も高いか、あるいは(b)ソースの音質が最も高いリソース保存場所)にマッチングした後は、リソース保存場所データまたはIPアドレス204が、例えば205など示すように、ゲートウェイ・サーバー3に戻る。

0021

次に、ゲートウェイ・サーバー3が、リソース・データに対するリクエストを、例えば104などで示すように、適切なマシン(102および/または103)またはサーバー・クラスターに(206、207、208などで示すように)送信する。次に、マシン101に設置されたゲートウェイ・サーバー3に、(例えば209などで示すように)リクエストされたデータを提供することによってマシン102/103またはサーバー・クラスターが応答する。マシン101上のゲートウェイ・サーバー3が、例えば209など提供されたデータを処理する(即ち整理かつ確証する)。次に、クライアント2へリソースを配信210する。

0022

ある特定のクライアント−サーバー−ピア関係の基本的な概略図を図7図8図9および図10に示す。即ち、図7に従来のクライアント−サーバー関係を示し、図8にアンマネージドP2Pネットワーク(unmanaged P2P Nnetwork)を示し、図9にマネージド(managed)P2Pネットワークを示し、そして図10に統括/ハイブリッドP2Pネットワークを示す。

0023

従来の一つのクライアント−サーバー関係では、クライアント105がサーバー106からデータをリクエストし211、そしてサーバー106が、図7に示すように巡回的にデータを配信212する。従来の一つのアンマネージドP2Pネットワークでは、各ピア(またはクライアント/サーバー)107がデータを配信するサーバー106を務め、またデータを受信するクライアント105を務める。全体として図8に示すアンマネージド環境では、ファイルが見つかるまでデータのリクエスト211がピア107からピア107に回される。

0024

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

0025

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

0026

図2および図3に全体構成を示すオリジン・アグナースティックP2Pコンテンツネットワーク配信(CDN)144の場合、クライアント2は孤立クライアントである。即ち、請求されたデータリクエスト発信元が孤立クライアント2(即ちブラウザ、デスクトップまたはモバイル・アプリケーション)によって消費される。他のネットワークとは異なり、データリクエスト発信元がピア107ではなく、全体構成を図7に示すような従来のクライアント・サーバー関係のように孤立クライアント2である。

0027

ゲートウェイ・サーバー3がクライアント2からのリクエストを受け取り、そしてリソース・ネーム・サーバー(Resource Name Server:RNS)またはリソース索引付きサーバー4でリソースに対するリクエストを解決する。RNS4がリソース保存場所(例えばIPアドレス)で応じ、これらリソース保存場所はリソース源またはピアである。このネットワークの場合、データ・オリジン・アグナースティック(data origin−agnostic)であるため、ピアデータは中央データ・サーバーによって管理されないが、リクエストが配信され、ゲートウェイ・サーバー3でキャッシュに保存されている間RNS4で索引が付けられる。

0028

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

0029

本発明はHTTPまたはWebソケットを使用することに限定されず、標準ファイル転送プロトコル(FTP、WebDAV、SMB、AFPなど)も使用可能である。この場合、クライアントは孤立FTP(または任意の標準ファイル転送プロトコル・クライアント)であればよい。OS(operating system)内のネットワーク・ドライブとしてFTPディレクトリー(またはWebDAV、SMB、AFPなど)を装備する場合には、OSがクライアントを務める。この場合、ゲートウェイ・サーバーがファイル・サーバーとして機能する。

0030

特に、このような構成ではセキュリティに懸念が生じる。本発明が提案する解決策または構成は潜在的に“中間者攻撃(man in the middle attacks)”および/または認可されていなクライアントアクセスに弱い。これら懸念については、ある特定のクライアントおよび/またはサーバー真贋確認手段によって対処できる。基本的に、クライアントおよび/またはサーバー真贋確認手段は、クライアントおよび/またはサーバーの真贋を確認する機能をもつ。

0031

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

0032

クライアント側スクリプトをプラグインと併用して、ある形態の確認検証(verification identification)をプラグインに埋め込むことによってクライアントおよびサーバーの両者の真贋を確認することも可能であり、この確認検証を次にAJAXを使用してこの確認検証が正しいことを確証するクライアント側スクリプトに回す。クライアント側スクリプトをブラウザ・プラグインと併用すると、一回のプロセスでクライアントおよびサーバーの両者を確認できるため好ましい。この方法を以下に説明する。

0033

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

0034

別なセキュリティ層を積み増すために、ローカル・サーバー110がメディア処理ブラウザ・プラグイン24(例えば、フラッシュスライバーライトなど)について多数のインスタンスを読み込む。ローカル・サーバー110の場合、メディア処理ブラウザ・プラグイン24について1,000ものインスタンスを簡単に読み込むことができる。各インスタンス内に、特別な暗号化キー27を埋め込む。多数のインスタンスを読み込む代わりに、プラグイン・ライブラリーによってカスタム・コード・インジェクションを行うことができる場合には、プラグイン・コンポーネント・ファイルにインジェクションすることができる。

0035

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

0036

暗号化キーまたはトークン27を呼び出すために、ローカル・サーバー110が提供するプラグイン・ファイル25をデコンパイル(decompile)してから、新しい“不正侵入(cracked)”プラグイン・インスタントを使用してサーバー110との接続を再度作り出すが、サーバー110の場合、セッション毎に異なる暗号化キー27を選択するため、新しいセキュリティのかかったソケット接続26ができた瞬間に、前の暗号化キー27はその役割を終える。このため、デコンパイリング(decompiling)により暗号化キー27を呼び出すことがその意味を失う。

0037

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

0038

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

0039

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

0040

図6を参照して、非プラグイン・セキュリティ対策について説明する。本発明のメディア・プラグインを使用する必要がない方法の場合、ゲートウェイ・サーバー3からクライアント2に登録されているセッションID(indification)113に対するリクエストを送信してもらい、その真贋を確証する。セッションID114については、ゲートウェイ・サーバーによって(例えば221で示すように)予め登録しておき、一回の真贋確認後は無効になる。

0041

このためには、ゲートウェイ・サーバー3が予定時間よりも早く多数のセッション114を登録する必要があり、各セッションID113は、確証回数は一回のみである。ゲートウェイ・サーバー3がセッションID113を(例えば222で示すように)クライアント2に提示する。次に、クライアント2は確認サーバー116で、受信されたセッションID115を(例えば223で示すように)確証する。確認サーバー116は、登録されたセッションID114をもつクライアント2が送信したセッションID115に(例えば224、225で示すように)マッチングする。マッチングがあった場合には、確認サーバー116がクライアント2に対してゲートウェイ・サーバー3の妥当性を(例えば224で示すように)確認する。

0042

上記以外にも、接続の妥当性を保証する他の方法もあり、例えば、OS(operating system)の統合方法があり、この方法の場合、ゲートウェイ・サーバーのために予約されたローカル・ドメイン・ネームを備えているため、他のアプリケーションが合法的なゲートウェイ・サーバーを装うことができず、あるいはこのローカル・ドメイン・ネームをこのような統合システムを介してデータ伝送を行う伝送プロトコルの作成を通じて備える。これらはいずれも可能なソリューションである。しかし、カスタムプロトコル・ソリューションの場合には、以下に例示するように、異なるリクエストのフォーマット化が必要である。即ち、
rstp://domain.com/resource_directory/resource_name?var=123(and not http.//vertigo/domain.com/resource_directory/resource_name?var=123)

0043

システムのセキュリティを確保するもう一つの方法では、このシステムを介してメディア(音楽映像ビデオなど)に配信されるコンテンツを制限するとともに、ウェブサイトやアプリケーションの構造体およびコードに関係しないコンテンツにファイル・ディストリビューション(file distribution)を限定する。この方法では、メディア・ファイルのみが許可されるため、マリシャス・コード(malicious code)をインポートすることがより難しくなる。この場合には、セキュリティに留意すればよい。換言すると、HTML、Javascript、CSS、PHPファイルなどはゲートウェイ・サーバーによっては配信できない。別な制限に関して述べると、ウェブサイト(構造体、コードおよびメディア)をhttpsによって読み込み、これが敏感な(変動しやすい)場合には、クライアント(ブラウザ)にこのようなゲートウェイまたはプロトコルの使用を控えてもらう。

0044

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

0045

これは、システムが高い信頼性を有し、また有効であるためには、データ・フラグメンテーション(data fragmentation)および確認方法を使用する必要があるからである。従って、一方のピアがデータを不適切な方法で破損し、あるいは意図的に変更する可能性を避けるためには、ある特定のデータ配信フラグメンテーション手段によって多数のピア間においてデータ配信をフラグメンテーションすることが好ましい。本発明のデータ配信フラグメンテーション手段は、多数の機構によって例示することができる。データ配信フラグメンテーションのためには、例えば、データ199を例えば117、118、119、120で示す列のようにパケットまたはサブストリームに分割すればよい。

0046

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

0047

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

0048

図4および図5を参照して、ドメイン・ネーム・サーバー(DNS)とリソース・ネーム・サーバー(RNS)との間のある特定の差異について比較を行う。DNS130とRNS4との主な差異は、リソースに対するリクエストをどのように扱うかにある。DNS130内では、リソースに対するリクエスト(例えば226で示す)は、SOA(Start of Authority)126のディレクトリー128内の特定されたリソース127を有するドメイン・ネーム129またはSOA126に対して(例えば227で示すように)解決する。クライアント2はDNSからSOAのIPアドレスを(例えば228で示すように)受け取り、次にSOA126からリソース127に対してリクエスト(例えば229で示すように)を出す。

0049

リソース・ネーム・サーバー、即ちRNS4内では、RNS4が特別なリソースが記憶されているか、あるいはキャッシュに保存されている多数のマシンに対するリソースのリクエスト(例えば201で示す)を解決する(例えば202で示す)。従って、リソースを備えたSOAのIPアドレスは妥当なリソース・ロケーションとして戻される(例えば205で示す)が、ピアがキャッシュに保存したリースのIPアドレスについても同様である。即ち、DNSシステム内では、URLは特定のリソースのアドレスにより似ているもので、RNS4内では、URL240は特別なリソースを多数の保存場所にリンクする特別なIDである。

0050

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

0051

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

0052

図16について説明すると、プログレッシブな索引付けのプロセス247は、第3者のクライアント・アプリケーションから来るリクエストから始まる。これは、例えば131で示す孤立デスクトップ・アプリケーションか、あるいは例えば132で示すブラウザを介して再生するウェブサイトであればよい。アプリケーション131またはブラウザ132は、適正にフォーマット化され、かつ有効なURL(例えば241、242で示す)にそってローカル・ゲートウェイ・サーバー(133)に進む。ローカル・ゲートウェイ・サーバー133は、URL(例えば241、242)を使用して、対応するクラウド245および246(あるいは対応するP2Pネットワーク、あるいは他の考えられるネットワーク系リソース)からのストリーミング配信(例えば243、244)のためにリクエストされたリソースを呼び出す。例えば243および244で示すストリーミング配信のためにリソースが一旦ダウンロードされた後は、ローカル・サーバー133が(サブルーチン(subroutines)248〜252を用いて)例えば247で示すように索引付けプロセスを開始する。(サブルーチン254〜258を用いて行う)ローカル・リソース索引付け253について、全体を図17に示す。

0053

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

0054

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

0055

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

0056

制限するものではないが、以下に伝送ソースを例示する。(1)クラウド系ストリーマー、(2)装置所有者利用可能なデータ購入を行う第3者クラウド系ストレージ・プロバイダー、(3)バーティゴ・クラウド系バーチャルロッカー(Vertigo‘s cloud−based virtual locker)(著作権法第512(c)条で保護される)、(4)ユーザー/サブサービス・マッチド・データによって駆動されるバーティゴのライセンスを受けている音楽、(5)リスナーの装置で利用可能な、ローカル所有かつローカル保存されている音楽ファイル、あるいはWi−Fiによって接続され、所有が別で制限装置で利用可能なローカル所有かつローカル保存されている音楽ファイル、(6)リンクされたPCからモバイル装置への伝送、(7)伝送に利用可能で、上記(1)、(3)および(4)からストリーミングされる前にファイルの代わりにルーティングされるP2Pが所有するファイルである。

0057

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

0058

特に、ローカルな場合も、そしてリモートの場合もすべてのリソースに索引を付けるため、素早いマッチングが可能になる。ストリーミング232後、ローカル・ファイルを使用したことをコンプライアンス・サーバー143に例えば233で示すようにレポーティングする。ラベルの場合、インターネット・ラジオ・サービス・プロバイダーは、ローカル・ファイル139をストリーミング232するさいには少額の料金を支払う必要がある。ラベルが剽窃されないという保証がないからである。サーバー141が効率的なリソース・アロケーションを行う結果、インターネット・ラジオ・サービス・プロバイダー140は、データ転送について支払う必要がなく、またフル・ライセンシング(full licensing)についても支払う必要がないため、節約したコストをインターネット・ラジオ・サービス・プロバイダーに回すことができる。

0059

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

0060

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

0061

商用ライセンシング・プロバイダー装置146の場合、10曲の曲すべてを放送する法的権利をもつが、10曲のリクエストされた再生リストのうち5曲のみがプロバイダーのローカル設置装置146上で利用可能であるとの前提で設置する。本発明システムの場合、メディア・ストリーミング・プロバイダーのメディア再生装置145内で作成された再生リストをシンクロし、欠けているファイルをバーティゴ・クラウド(vertigo cloud)内で利用できるファイルと(例えば231で示すように)マッチングし、曲をプロバイダーのライセンシング契約毎に商用ライセンシング・プロバイダーの装置146に送信234する。この転送は、データ転送コストに応じてバーティゴのP2Pネットワーク144から発生する。すべての伝送およびすべてのストリーミングは、(必要に応じて)サーバー141によってコンプライアンス・サーバー143にレポーティング233され、曲の再生数を追跡することができる。

0062

図24に示すシナリオの場合、ストリーミング・プロバイダー147が、曲151をモバイル装置148で再生すべきとリクエストできる。このリクエストは、モバイル装置148上のモバイル装置アプリケーション149から送られ、そして本発明のリモート・サーバー150に送信される。この曲をリクエスト237したモバイル装置148が、曲のリクエストをデータ発生サーバー147(即ちストリーミング・プロバイダーのサーバー)にルーティングする代わりに、ファイルがローカル記憶されたPC(personal computer)152に例えば235で示すようにリンクされた場合には、このリクエストはPC152へ送信され、PC152からモバイル装置148に例えば236で示されるようにストリーミングされる。このような状況では、付加的なストリーミング権利は必要なく、データ転送コストもかからない。リクエスト237が本発明のリモート・サーバー150に送られ、そしてファイルがリンクされたPC152上にもなく、またクラウド上にもない場合には、リクエスト237は例えば238で示すようにデータ発生源147に送られ、このデータ発生源147がファイルを装置148にストリーミング239できる。

0063

図25に示すシナリオの場合、ストリーミング・プロバイダー147が、曲をモバイル装置148で再生すべきとリクエストできる。このリクエストは、モバイル装置148上のモバイル・アプリケーション149から送られ、そして本発明のリモート・サーバー150に送られる。モバイル装置148が例えば235で示すようにリンクされたPC152からクラウド・サービス153に例えば240で示すようにアップロードされた曲をモバイル装置148がリクエストした場合、リモート・サーバー150がリクエスト237をクラウド・ロッカーまたはサービス153にルーティング236する。この場合、ライセンシングは必要ないが、データ転送費がかかることになる。本発明のリモート・サーバー150にリクエスト237が送られ、そしてリンクされたPC152にも、あるいはリンクされたクラウド153にもファイルが存在しない場合には、このリクエストはデータ発生源147に例えば238で示すように送られ、その後ファイルが例えば239で示すように装置148にストリーミングされる。

0064

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

0065

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

0066

図22に第1ケース・シナリオを示す。この場合、ストリーミング・サービス・プロバイダー155が、ローカル・サーバー150が最適価格でストリーミング241を行うことができる特定のパラメーターを設定する必要があるリクエストとともにリクエストをローカル・ゲートウェイ・サーバー150に回す。これは、サーバー150が例えば156で示すようにサブライセンスド・アカウント(sub−licensed account)からストリーミングを行うことができることを示す。図22には、3つのサブライセンスド・アカウント157、158、159を示す。

0067

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

0068

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

0069

上記のサブライセンシングケースが可能な理由は、ローカル・サーバー150がストリーム、即ち誰が何処(どのサブライセンサー)からストリーミングを行っているかを追跡でき、またレポートを作成でき、結果としてロイヤルティーの支払いのルーティングを適正化できるからである。本システムの特別な点は、このような追跡を可能にする点ではなく、P2Pネットワークへのアクセスが可能であり、しかもこのようなアクセスについてレポートを作成できる点にある。上記の第2ケースシナリオの場合、ローカル・ゲートウェイ・サーバー150でのみ可能であるが、第1シナリオは標準S2S(server to server)リクエスト、あるいはある形式リライトまたはリダイレクト(rewrite or redirect)の場合に可能である。

0070

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

0071

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

0072

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

0073

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

0074

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

0075

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

0076

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

0077

コンプライアンス・エンジンおよびレポーティング・ツールは、以下の情報を引き出すことができる。
1) すべてのPRO(Performing Rights Organizations)によって必要とされる特別なスペック(specifications)に基づく使用レポート。これらスペックには、以下のアイテムが含まれる。
a.プラットホーム毎に特別なレポートを提供する(ストリーム・プロバイダー)。
b. プラットホーム・タイプに基づき、かつストリーミング・プロバイダー毎に収益情報を安全に入力できる能力を提供する。
c. 特別なユーザー・セッション毎に使用レポートを作成し、平均リスニング時間合計、再生毎の合計、リスニングセッション毎の合計を出す。
d.使用情報および収益情報のすべてを個別の使用レポート/SP/PROに集積する能力を備える。

0078

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

0079

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

0080

4)権利モジュール“コンプライアンス・ダッシュボード”−各種の契約タイプに関してコンテンツ・コントローラによって認められた権利、印税率、クリアランスステータスおよび使用を(メディアアセット(media asset)毎に)統括変更または個別変更できる能力
a.レコード・レーベル・ライセンス契約
b.レジデンシャル・ライセンス契約
c. 商用ライセンス契約
d.マルチプルプラットフォームライセンス契約
e.バンドルド著作権契約(bundled Rights Agreement)
f.ロイヤルティー共有契約(発行管理)
g.権利放棄/無料

0081

5) 以下の“コンテンツ・ソース・タイプ”それぞれに対してすべてのプラットホームおよびサービス全体にわたるすべてのレポート必要条件の個別かつ集積化アカウントを提供できる能力
a.100%ストリーミング・プロバイダー(SP)コンテンツ
b.ローカル・サーバー・コンテンツ
c.コントロールド・P2P・コンテンツ
d. バーティゴ・ライセンスド・コンテンツ(Vertigo Licensed Content)

0082

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

0083

すべての著作権団体を正確に計算し、かつレポートを作成し、コントロールド・プロプライエタリ・コンテンツ(controlled and proprietary content)の利用状況を記憶し、ソースを明らかにし、計算し、そして配信コストの節約を合計総ロイヤルティーに繰り込む能力があるため、これをある種のコンプライアンス・サービスの一つにすることができる。

0084

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

0085

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

0086

インターネットによってラジオをストリーミングする既存の方法の全体を図30に示す。インターネットによってラジオ・ストリームを配信する方法の場合、一般に、例えば163で示すメディア・再生装置(例えば一般的にはPC)を使用する。この装置が、予め録音された音(ミュージック・トラック、CM(advertisements)など)を再生し、これをサウンドボード164に出力248する。次に、スタジオまたは録音システム170のサウンドボード164に入力164される249ディスクジョッキーの寸評および/またはコメントやその他のライブ音165と再生音とミキシングする。

0087

次に、サウンドボード・ミックスを単独オーディオ・ストリームとしてコンピュータ166に250で示すように出力する。次に、このコンピュータ166がオーディオ・ストリームを圧縮し、オーディオ・ストリームを圧縮されたオーディオ・ファイル167(通常はMP3ファイル)に出力する。このMP3ファイルは、ファイルがライブ・ストリーミングされ、そして新しいデータがファイルの末端に常に追加されているため、設定時間をもたない。このMP3ファイルは、例えば、コンテンツ配信ネットワーク168上に設けられ、オーディオ・ストリームを圧縮し、かつトランスコード(Trans−code)するコンピュータ166が、圧縮時にこのファイルに新しいデーを追加251する。次に、コンテンツ配信ネットワーク168がこのファイルをクライアント169に配分252する。この説明は、上記と同様に、簡単なシステムの概観であり、市場に出回っている多くの構成と同様である。

0088

図26図29に、本発明のゲートウェイ・サーバー機拡張システムの全体を示す。この機能拡張システムは、ラジオ・スタジオ170、および予め録音された音をサウンドボード164に出力する248コンピュータ163から始まる。本発明のコンピュータ163は、プロプライエタリ・ソフトウェアによって例示されるように、ある特定のイベント・マーカー対応手段を有し、この手段はインストールすると、以下のようになる。

0089

1.放送対象の曲をキューイングするディスクジョッキー;即ち、ソフトウェアが曲の待ち行列171を作成し、この待ち行列を次にクライアント172に配分し、クライアント172が放送をストリーミングする。待ち行列171は、ディスクジョッキーが放送時に再生する手はずの曲を含む。ローカル・サーバー184がこれらの曲をプリロード(pre−loads)253するため、ディスクジョッキーがある曲の再生を決定した時に、この曲がクライアント172における再生に利用できる。これら曲はリモート・コンテンツ配信ネットワーク・クライアント173、P2Pネットワーク・クライアント174を介して配信でき、またローカル・ファイル・システム175からマッチングあるいはストリーミングできる。

0090

2.また、ソフトウェアが、サウンドボード164から戻ってくるオーディオ出力176を例えば256で示すように圧縮し、そしてソフトウェアがオーディオ・ストリーム179のフレーム・ヘッダー177内にイベント・マーカーを埋め込む。各MP3オーディオ・ストリーム/ファイル179はオーディオ・フレーム178からなり、各オーディオ・フレーム178はヘッダー177を有する。新しいオーディオが加わると、新しいフレーム178がファイルに追加される。これらヘッダー177は32ビットの長さである。各ヘッダー177内には、プライベートなアプリケーションを使用するためのビットを残しておく。このビットは、イベント開始時には“1”に設定され、そして正規のストリーミング時には“0”に設定される。このデータは、サウンドボード164から来るストリーム176および/または256の両者に埋め込まれる。また、各ヘッダー177は案内情報を提供するだけで、オーディオ再生に影響しないビット(たとえば“著作権”、“オリジナル”など)を有する。各ヘッダー177は、オーディオ再生に影響しない少なくとも3ビット(プライベートなビットを含む)を有する。これらビットを使用して、イベントIDを作成することができる。このIDの場合、(イベント・インジケータビットに続いて)これらビットを使用して、“0”と“1”の組み合わせを作り出し、10秒間の再生を埋める十分なイベントに対処するのに十分特別なIDを作成することによって作成すればよい。このように、オリジナルな偶数インジケータビットをもつフレーム・ヘッダーを直後のフレーム・ヘッダーとともに使用する場合には、合計で少なくとも5ビットを使用して、少なくとも32の、あるいは25の特別なマーカーを作成することができる。これは、考えられる10秒の遅れの間十分なイベントをカバーするために十分以上特別なマーカーになる。これ以上のマーカーが必要な場合には、別なヘッダーを追加して合計を32から256に増やすことができる。各イベントが10秒間の時間フレーム内で特別なマーカーを有することになるため、これらマーカーを使用して、2つの別なストリーム(一つはライブ・オーディオのみを有し、もう一つはフル・ミックスを有する)をシンクロして、完全なリモート・ミクスド・ストリーム(fully remotely mixed stream)およびローカル・ミクスド・ストリーム(locally mixed stream)(このローカル・ミクスド・ストリームは、スタジオからストリーミングしてきたライブ・オーディオおよびイベント・マーカーにおいてローカル・サーバーによってストリームにミキシングした予め録音されたオーディオからなるストリームである)へハンドオフ(Hand−off)して遷移させることができる。これらイベント・マーカーはミキシング指示にリンクして、スタジオからのオーディオ・ミックスを模倣することもできる。

0091

3.また、アプリケーションはイベント待ち行列を作成するものでもある。これは、(上述したように)マーカーに続く特別なビットIDに基づくイベント・マーカーにマッチングするイベントの待ち行列であればよい。これらイベントはコンピュータ163に記録され、このコンピュータがオーディオを圧縮するため、イベントが生じた正確なフレーム178に各イベントが登録される。従って、イベントのタイミングが、オリジナル・スタジオ・ミックス176内でこれらが生じた正確な場所においてライブ・オーディオ・ストリーム256内に確実に埋め込まれることになる。これらイベントは、以下についての情報を含む。
a.イベント・マーカーにおいて再生する必要があるのは、どの予め録音されたオーディオか。
b. 予め録音されたオーディオについて、どのフレームが再生を開始するのか。 c. どの音量で再生が始まるのか。
d. そして音量がフェードイン(faded in)した場合、音量のフェードイン/フェードアウトの方向および傾きに最適な数式は何か。これを使用すると、スタジオのフェードイン/フェードアウトを模倣できる。この情報は、場合に応じて、周辺フェーダー180によって記録すればよく、このフェーダーによってディスクジョッキーが、サウンドボード164にオーディオが出力され、音量変化をコンピュータ163にレポートしている間にオーディオを制御することができる257。
e. イベントの終了(これについては、例えば、フェードイン/フェードアウトストップ時にマークする必要がある)。
f. さらに続くが、省略する。これは、最も見られるタイプのイベントの例である。

0092

4.また、アプリケーションが、リモート・サーバーまたはコンテンツ配信ネットワーク150上のライブ・オーディオ・ストリーム・ファイル181およびフル・ミックス・ファイル182を更新258する。

0093

2つのストリーム181/182がコンピュータ163上のスタジオ170内のアプリケーションによって記録され、記号化された後は、ファイル181/182の両者がコンテンツ配信ネットワークまたはリモート・サーバー185にアップロード258し、クライアント172に配信259する。クライアント側アプリケーション183(例えばブラウザなど)が、正しくフォーマット化されたURLを使用することによって、ラジオ・ストリームのリクエストを出す。URLは主ドメイン・ネームのサブドメインとして構築する。例えば、このフォーマットのURLは、場合に応じて、ラジオ・ステーション・ストリーム・ラジオ・ステーション(radio station stream radiostation).vertigomusic.com/[show id]を参照できるように使用することができる。バーティゴ・ゲートウェイ・サーバー184がインストールされていない場合、このURLがクライアントを完全ミクスド・スタジオ・ストリーム182に照会し、従来のインターネット・ラジオ・ストリームと同様な方法でファイルを再生することになる(上記説明および図30を参照)。

0094

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

0095

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

0096

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

0097

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

0098

ここで、第1イベントが予め記録されているオーディオ待ち行列171内の第1曲の再生であるとする。アプリケーションは、既にオーディオの少なくとも10〜20%をキャッシュに保存している。この場合、ゲートウェイ・サーバー184がライブ・オーディオ・ストリーム181および予め記録されているオーディオ・データ188を内部ミキシング・アプリケーション187(SoXなどのコマンド・ライン・アプリケーションや特注アプリケーションであればよい)に回す。

0099

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

0100

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

0101

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

0102

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

0103

リスナーがその装置193からクライアント・アプリケーション194(例えばブラウザやモバイル・アプリ)を介してラジオ・ストリームについてリクエストする場合、リクエストはゲートウェイ・サーバー195に送られる270。次に、ゲートウェイ・サーバー195がオーディオ・ストリームのリクエストをクラウド/サーバー192に送り271、これがオーディオに応答し、これをゲートウェイ・サーバー195に配信する272。

0104

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

0105

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

0106

本発明のいわゆるP2Pコンテンツ配信ネットワーク(CDN)、即ちP2PCDNの場合、例えば2で示すクライアント、例えば3で示すP2Pゲートウェイ・サーバー、例えば4で示すリソース・ネーム・サーバー(RNS)、およびコンピュータ密度の高いネットワークを有するのが好ましく、このコンピュータ密度の高いネットワークはローカル・サーバー、ピア・コネクテッド・サーバー(peer−connected servers)、クラウド・ロッカー、クラウド・ストレージ、クラウド・メディア、および/または商用(音楽)ストリーミング・サービス提供インフラストラクチャーなどで構成すればよい。

0107

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

0108

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

0109

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

0110

RNSとの接続のさいに機能する特定のリソース索引付け手段によってリソース保存場所に索引を付けて、ネットワーク効率または方法効率を高度化するのが好ましい。特に、リソース索引付け手段については、データ・ファイル・メガデータから独立してデータ・ファイルを素早くかつ効果的にマッチングする特定のファイル・マッチング手段を有するのが好ましい。本発明のファイル・マッチング手段については、既に許可を受けた米国特許出願No.13/065,254(US Patent No.8,589,171)により詳しく記載されている。なお、これら公報の記載についてはここに援用するものとする。

0111

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

0112

データ抽出手段は、第1データ・ファイルから波形データを抽出する。抽出された波形データは長さセグメント値を有する。これら長さセグメント値は、データ抽出ベースラインに対して抽出され、トラフ対ベースライン(trough−to−baseline)長さセグメント値およびピーク対ベースライン(peak−to−baseline)長さセグメント値を有する。要約統計量誘導手段は、抽出された波形データから要約統計量を誘導する。これら要約統計量は長さセグメント値から誘導され、トラフ対ベースライン長セグメント統計量およびピーク対ベースライン長さセグメント統計量を有する。

0113

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

0114

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

0115

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

0116

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

0117

本質的に、本発明は、(1)ローカル・サーバー(例えばPANDORA(登録商標)ラジオによって例示されるディジタルラジオ)から間接的なリクエスト・ストリームを配信する機能;間接リクエスト・ストリームをピア・コネクテッド・サーバーから配信する機能;間接リクエスト・ストリームを第2直接リクエスト・ソース(例えばiTunes MatchまたはSpotify、あるいはDropBoxなどのクラウド・ロッカー、あるいはクラウド内の任意のメディア)から配信する機能;再生またはストリーミングを行う第2直接リクエスト・ソースの権利に基づいて間接リクエスト・ストリームをピア・コネクテッド・サーバーから配信する機能;(a)プライス効率または(b)ソースの音質に基づいて直接リクエスト・ストリームを第2直接リクエスト・ソースから配信する機能;および(6)再生またはストリーミングを行う第2直接リクエスト・ソールの権利に基づいてピア・コネクテッド・ソースから直接リクエスト・ストリームを配信する機能を提供するものである。本発明システムのデータ・オリジン・アグナースティックな性質、あるいはクラウド・アグナースティックな性質を考えると、本発明システムは、コンテンツの配信元が上記実施例1〜6を含む元のリクエストされたソース・サービス以外の二次的なソースである場合には、(a)工業権管理、(b)コンプライアンス・モニタリングおよび/または(c)データ・ファイル伝送のコンプライアンス・レポーティングを提供するものである。

0118

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

0119

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

0120

2、105、169、172、183、194:クライアント
3、100、110、141、184、194、195:ゲートウェイ・サーバー
4:リソース・ネーム・サーバー(RNS)
101:ローカル・ネットワーク
104:モート・ソース
108、109、134:リソース索引付けサーバー
133、150:ローカル・ゲートウェイ・サーバー
138、144、161:P2Pネットワーク
177:;レーム・ヘッダー
150、168、173、185、192、252:コンテンツ配信ネットワーク
183、201、203、211、214、216、217、218、229、237、242:リクエスト

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ