JP2008546065A - ファイル分配用グリッドネットワーク - Google Patents

Abstract

一実施形態で、システムが提供される。システムは、ネットワークに接続された確認機能を有する第１サーバノード(3130)を含む。システムは、同じくネットワークに接続されたコンプリートファイルのリポジトリを有する第２サーバノード(3120)を含む。クライアントノードは、ネットワークを介してピアツーピア基準上でコンプリートファイルのセグメントをシェアするよう構成される。他実施形態において、方法が提供される。方法は、ピアツーピア接続を介して第１クライアントからメディアファイルのセグメントを要求することを含む。方法は、要求における第１確認ジョブチケットを提供することをさらに含む。方法は、第１確認ジョブチケットが正しいまま残っている限り、ピアツーピア接続を介して第１クライアントからメディアファイルのセグメントを受信することも含む。
【選択図】 図３１

Description

本発明は、ファイル分配用グリッドネットワークに関する。

ムービー、テレビジョン、ソフトウェア、書籍、音楽といったメディアコンテンツにおける所有権を有するものとして定義されるメディア所有者は、安心、低いコスト、高い品質、有効な貨幣ルールで彼らのメディアを広めるための、インターネットの全ポテンシャルを用いることができる技術システムをまだ見つけていない。幾千ものメディア所有者及び何兆ものユーザのネットワークを低いコストで管理し、デリバリネットワークを有効な貨幣ルール及び高い安全性で管理するために、“エンドツーエンドシステム”（即ち、消費者への配布）への必要がある。

現在のところ、多くのメディア所有者は、インターネットを介するウェブサイトやストリーミングサーバからエンドユーザへの“ダイレクトストリーミング（direct streaming）”なムービーファイルやオーディオファイルである。これらファイル、とりわけビデオファイルは、それらのデータの複雑さゆえに非常に大きい。この種のダイレクトストリーミングは、ハードウェア及び帯域幅コストの両方で比較的高価である。さらには、大量ストリーミング、例えば１００万のユーザへの迅速なダイレクトストリーミングは、エンタープライズハードウェアの強力なクラスタを大々的に要求するのみならず、シングルムービーのストリーミングのバンド幅コストを１００万倍にして要求する。

加えて、メディアコンテンツをエンドユーザに提供するために他の“アウトレット”（例えば、ウェブポータル、オンラインマーチャント）と提携するメディア所有者は、収益力があるシンジケーションへの障害を引き起こす各シンジケーションディール上の交渉努力及び資金をしばしば消費する。もし、シンジケーションを構成し、コントロールし、管理するのに簡単なアクセスをアクセスメディア所有者が有しており、アウトレットパートナーがそのシンジケーションをより簡単に消費し且つ構成していたならば、メディアはもっと早く分配され、メディア所有者は貨幣をコントロールしていたかもしれない。

他の挑戦がメディアエンコーディング及びエンドユーザプレイングに関連する。オリジナルソースやコピーからのメディアのエンコーディングは、労力がかかり、高いコストがかかる装備である。加えて、ムービーやオーディオのプレーヤ技術は、例えばそれらプレーヤ技術と一緒になるオペレーティングシステムといった他のソフトウェアを売ることに興味を持つビジネスによってしばしば発展され、コントロールされている。従って、オペレーティングシステムプラットフォームと独立し、どんなオペレーティングシステムとも動作するように設計される（あるいは、オペレーティングシステムを必要としない）メディアプレーヤの必要性があり、そのため、それは、パーソナルコンピュータ、セットトップボックス、ゲームコンソール、組み込みシステム及びセルフォンの中に用いられ得る。

ファイル分配用グリッドネットワークのためのシステム、方法及び装置が提供される。本文書において記載される具体的な実施形態は、本発明の例を示し、制限的なものとしてではなく、むしろ特性の図解用としてである。各種の実施形態として、エンドツーエンドプロダクション、使用権、デジタル権、エンコーディング、コンプレッション、コンテンツ管理、貨幣シンジケーション、グリッドネットワークデリバリ、ポータブルプレーヤ技術のシステムを提供する。他実施形態として、これらの機能のサブセットを提供し、同様に他の機能を提供する。デジタルメディアデリバリは、デジタルメディアのセグメントを受信し且つ再信することができる各分配プレーヤアプリケーション（実質的には各クライアント）からのノードを形成することによって、手頃な値段となる。シンジケートされたコンテンツフィードは、コンテンツプロバイダがデジタルデータのライブラリを分配パートナーに簡単に売るのを許す。いくつかの実施形態として、デジタルムービーのエンコーディング及びコンプレッションを提供し、暗号化されたメディアファイルのダウンローディング及びシェアリングを管理するためのクライアント技術もまた提供する。デジタル権管理は、エンドツーエンドプラットフォームといった全てのレイヤに組み込まれる。

一実施形態において、システムが提供される。システムは、ネットワークに繋がれた認証機能を有する第１サーバノードを含む。システムは、同じくネットワークに繋がれたコンプリートファイルのリポジトリを有する第２サーバノードを含む。システムは、ネットワークに繋がれたファイルのローカルリポジトリを有する一組のクライアントノードを含む。クライアントノードは、ネットワークを介したピアツーピア（peer-to-peer）基礎上のコンプリートファイルのセグメントをシェアするために構成される。

他実施形態において、方法が提供される。方法は、ピアツーピア接続を介して第１クライアントからメディアファイルのセグメントを要求することを含む。方法は、要求における第１認証ジョブチケットを提供することをさらに含む。方法は、第１認証ジョブチケットが正しい状態のままである限り、ピアツーピア接続を介して第１クライアントからメディアファイルのセグメントを受信することを含む。

さらなる他実施形態において、システムが提供される。システムは、ローカルクライアントを含む。ローカルクライアントは、ネットワークインターフェイス、リポジトリインターフェイス、レンダリングインターフェイス、暗号化エンジン、ユーザインターフェイス及びコントロールモジュールを含む。システムは、ローカルリポジトリも含む。ローカルクライアントは、ファイルアクセスの認証を受信するために、ネットワークインターフェイスを介したネットワーク上でサーバと相互に作用しようとする。ローカルクライアントは、認証ピアツーピア接続を用いて、ローカルリポジトリから及びローカルリポジトリにファイルのセグメントを動かしたり、他のシステム上の他のローカルクライアントから及び該ローカルクライアントにファイルのセグメントを動かしたりもする。

他実施形態において、方法が提供される。方法は、グリッドネットワークにおける第１クライアントからセグメントを要求すべく、インビテーションを受信することを含む。第１クライアントは、ファイアウォールを介してグリッドネットワークに繋がれる。方法は、セグメントの要求を伴うセグメントを要求すべく、インビテーションに応答することも含む。方法は、セグメントの要求に応答して第１クライアントからセグメントを受信することをさらに含む。

さらなる他実施形態において、方法が提供される。方法は、グリッドネットワークにおけるサーバから第２クライアントで第１クライアントについての情報を受信することを含む。第２クライアントは、ファイアウォールを介してグリッドネットワークに繋がれる。方法は、第１クライアントにセグメントを要求すべく、インビテーションを送信することをさらに含む。方法は、第１クライアントからセグメントの要求を受信することも含む。

さらなる実施形態において、システムが提供される。システムは、サーバを含む。サーバは、ネットワークインターフェイス、ローカルリポジトリインターフェイス及びコントロールモジュールを有する。サーバは、ローカルリポジトリをさらに含む。サーバは、グリッドネットワークの各クライアントと相互に作用しようとする。

他実施形態において、方法が提供される。方法は、データファイルを取り除く要求を受信することを含む。また、方法は、ネットワーク接続性に基づくデータファイルを受信すべく、グリッドネットワークのクライアントを選択することを含む。さらに、方法は、データファイルを取り除く要求に応じて、選択されたグリッドネットワークのクライアントにデータファイルのセグメントを送信することを含む。

まだ他の実施形態において、方法が提供される。方法は、データファイルを受信することを含む。方法は、データファイルのハッシュ値を決定することをさらに含む。方法は、データファイルのセグメンテーションを決定することも含む。方法は、データファイルのセグメントを暗号化することも追加的に含む。

他実施形態において、方法が提供される。方法は、データファイルのセグメントを受信することを含む。方法は、データファイルのセグメントを復号化することも含む。方法は、データファイルの復号化されたセグメントをレンダリングすることをさらに含む。

以下の記述において、説明を目的として、本発明を理解するために多くの具体的な内容が述べられる。しかしながら、本発明がこれら具体的な内容無くして実施され得ることは当業者にとって明らかである。本発明が不明確になるのを避けるべく、他の例において、構造及び装置がブロック図形式にて示される。

明細書を参照して、“一実施形態”は、実施形態との関係で記述される特別な特徴、構造あるいは特長が本発明の少なくとも一つの実施形態に含まれることを意味する。明細書に各所における“一実施形態において”なるフレーズを見て、必ずしも同じ実施形態を全て参照する必要はなく、他実施形態の互いに矛盾する実施形態を分離したり選択する必要もない。各種の実施形態の特徴及び目的は、他の実施形態に統合され、本文章において図解される実施形態は、図示されたり記述される特徴や目的の全てを伴わずに実施される。

実施形態は、以上にて確認された多くの問題を解決し、確認された必要性を全てでなくても多くの要求を満たすシステム、コンポーネントを提供する。さらに、システムは、どんなメディア所有者も使用し且つどんなアウトレットパートナーが消費し得て且つどんなエンドユーザも除くどんな場所でも見ることができる、統一プラットフォームにおけるこれら全てのコンポーネントを提供する。このように、各種実施形態は、エンコーディング、暗号化、使用権及びデジタル権の確立、コンテンツ管理、貨幣シンジケーション、高速“オンデマンド”、グリッドネットワークデリバリ及びポータブルメディアプレーヤ技術のためのエンドツーエンドプラットフォームを提供する。本文書の目的のため、デジタルビデオが発明方法の図解例として用いられるが、本発明がこの例に限定されないことは理解されるべきである。各種の実施形態において、デジタル音楽、書籍、ソフトウェア、コンピュータゲーム、そして、他のメディアが用いられ、あるいは提供される。

ビデオエンコーディングのため、いくつかの実施形態のシステムは、ＤＶＤメディア、フィルムメディア及び（ＶＨＳテープといった）アナログメディアを用いて技術者がストレージシステム内にメディアを“ロードする”ことを許容する自動化“ハーネス”を用いる。自動化エンコーディングコンピュータは、それの休止中、エンコーディングを必要とし且つ始めるために新たなメディアを検索しつつストレージシステム上のディレクトリを読む。エンコーディングコンピュータが新たなメディアファイルのフルコピーを有するならば、望ましいビデオ及びオーディオコーデック内にエンコードし、ツーパスエンコーディングシステム（two pass encoding system）における様々なビットレートで新たな一組のメディアファイルを作成するよう、続けられる。メディアがエンコードされた後、顧客に届けられるよう、外部“シッピング（shipping）”ストレージアレイ上に保存される。

いくつかの実施形態のデジタルメディアヴォールト（vault ）システムは、エンコーディングシステムからエンコードされたメディアを受け取り、何百テラバイトもの能力を有するストレージアレイ内にそれをインポートする。それはデジタルメディアファイルをインポートするので、それはメディアファイルをより小さなセグメント（例えば、一実施形態において、３２ＫＢ〜１ＭＢ“チャンク”、他実施形態において少なくとも１２８ＫＢのチャンク）に寸断する。各セグメントは、現在のところ、軍用レベルの暗号化プロトコル（１２８ビット同期キー暗号化）である最良の暗号化を用いて暗号化する。暗号化の各種フォーム及びチャンクの各種サイズは、セグメントを提供すべく用いられる。各種の実施形態のメディアヴォールトは、“使用可能なウェブ”であり、従って、認証されたユーザが体制、許可、そして、各種メディアフィルム上のデジタル権を構成するのを許容する。メディアヴォールトは、信頼されているアウトレットパートナーに対するカタログの一部あるいは全ての供給をシンジケートするために用いられ得る。メディアヴォールトは、以下に述べられるグリッドネットワーク（一般的にはピアツーピアネットワーク）の“スーパーノード”へ接続される。

いくつかの実施形態において、スーパーノードは、メディアのいくつか小さなセグメントをローカルストレージユニットに保存する他のクライアントをクライアントが確認するのを許容するクライアントアプリケーションのための“ディレクトリ”である。このように、いくつかの実施形態において、スーパーノードは、関連する小さなセグメントをコンピューティングデバイス上に集めると共に、シーケンス、連続ムービー、書籍、オーディオ、ソフトウェアあるいはゲームアプリケーションファイルのフォーム内に適切に集めることを許容する情報を備えたクライアントを供給する。スーパーノードは、クライアントアプリケーションがメディアを見る許可を有するならば、メディアをアンロックする暗号化キーをユーザに許可する。

各種の実施形態のメディアプレーヤアプリケーションは、パートナーアウトレット（ウェブサイト、セットトップボックス、セルフォンあるいはアプリケーションに基づくパーソナルコンピュータ）を通じて始めるための組み込みプロトコルを有する。プレーヤアプリケーションは、それら自身、多くのどんなコンピューティングデバイスに対してもポータブルである。

一実施形態に基づき、シンジケーションフィードは、多くの異なるアウトレットパートナー（ウェブポータルやオンラインマーチャントといったもの）が、大いにコントロールされた貨幣化安全メディアデリバリネットワーク上のメディアヴォールトコンテンツにアクセスするのを許容するアウトレットパートナーに対し、メディアヴォールトによって構成される。シンジケーションは、二つの方法で流れる。一つは、アウトレットパートナーへのメディアカタログのデリバリであり、二つ目は、メディアヴォールト上のメディアに対してアウトレットパートナーからアクセスする認証されたユーザのリストのデリバリである。

一実施形態に基づき、グリッドデリバリネットワークは、有効にコントロールされ、十分に暗号化され、そして、加速されるメディアファイルのデリバリのパイプラインを通じてメディアデータのセグメントを分配し、保存し、そして、消費する幾千あるいは何兆ものクライアントアプリケーションの集合である。このグリッドは、メディアにアクセスする上でのハイスピード、ローコストを消費者（エンドユーザ）に保証するキーの役割を担う。

図１は、グリッドネットワークの一実施形態を提供する。スタジオ１１０は、エンコーディングスタジオの一実施形態を提供する。エンコーディングスタジオにおいて、デジタルメディアは、ネットワークにデジタルマスタリングするために顧客（メディア供給者あるいはメディア所有者）によって運ばれる。デジタルビデオは、メーカ独自のコーデックといったようなものを介して圧縮され、デジタルアプリケーションは、テストラボにて、テストされ、チェックされ、そして、不要な部分が削除され、デジタルスタジオは、ＭＰ３フォーマットにマスターされ、デジタルテキストあるいはデジタルデータは、メディアヴォールトに運ばれる前に、メディア不要な部分が削除されると共に、品質チェックされる。スタジオは、他実施形態におけるのと同様に他の方法で実施される。

メディアヴォールト１３０は、メディアヴォールトの一実施形態を提供する。各顧客は、メディアファイルを構成し、アップロードし、そして、管理するために、安全に暗号化されたＷＷＷインターフェイスを通じて自身の安全メディアにアクセスする。メディアは、使用、デジタル権、値付け及びコストコントロール、分類の各種レベルに構成され、緻密な記録を通じて詳細に述べられ、イメージは、メディアのためにビジュアルイメージを提供すべくアップロードされる。全ての（あるいは部分的な）メディアカタログは、一つから数百ものまでに、信頼されたアウトレットパートナーにシンジケートするために構成され得る。メディアヴォールトは、パスワード保護され且つＳＳＬ暗号化された“ＳＯＡＰウェブサービス”であって、ユーザがアウトレットパートナーのアカウント上にメディアをダウンロードすることを許可するか否かを信頼されたアウトレットパートナーが行う“ＳＯＡＰウェブサービス”を用いて、高く保証された特別な“アウトレットパートナー”ゲートウェイを有する。メディアヴォールトは、次に述べられるシステムの実施形態上のスーパーノードによってワールドワイドにアクセス可能である。デジタルメディアをインポートするとき、メディアヴォールトは、グリッドデリバリネットワークを横断した分配のためにデータを小さな暗号化チャンクに分割する。メディアヴォールトは、保証されたユーザ、保証されたアウトレットパートナー、そして、保証されたスーパーノードによる以外は、外部にアクセルされにくい。

スーパーノード１４０は、ジオロケート（geo-located ）なスーパーノードの一実施形態を図解する。図解されるスーパーノードは、グリッドデリバリネットワークを横断した分配のためにメディアヴォールトからデジタルメディアを安全にダウンロードすべく、メディアヴォールトと相互に作用する。スーパーノードは、関連する技術を用いてユーザが自動的にナビゲートするシステムにおいて、以下に説明するように、地理的にユーザに最も近いスーパーノードに対し、あちらこちらに置かれる。これは、より速いインターネット応答時間、より少ない待ち時間を潜在的に許す。スーパーノードは、メタデータ（meta-data ）を含め、メディアヴォールトからユーザへのデータの通過を管理する。スーパーノードは、短くコントロールされる期間でネットワークを横断してユーザを許可する“ジョブチケット”を管理する。ヴォールト“ジョブチケット”を有しないクライアントは、ネットワークへのアクセスが認められない。スーパーノードは、グリッドネットワーク上のムービーの第１セグメントである“シード”の通過を管理し、ローコストでネットワークにムービーを流すことを幾千あるいは何兆ものクライアントのネットワークが有効に相互作用することを許容するために、理知的にシードの広がりを管理する。スーパーノードは、ムービー、オーディオの視聴や、ソフトウェアアプリケーションのダウンロードを目的として、デジタルメディアのセグメントをアンロックするために、デジタルキーの承認及び通過をしっかりと処理する。スーパーノードは、目的を報告するためにネットワークの使用についてのクライアントアプリケーションからのデータの報告もまた処理する。スーパーノードのそのような記述は、他実施形態において異なる。

ヴォールトインターフェイス１２０は、しっかりコントロールされるグリッドキャストヴォールトインターフェイスであって、正式に変更されたパスワード、ＩＰ（インターネットプロトコル）に基づくクライアント認証、そして、その他の複雑な認証技術を備える信頼されたユーザによってのみアクセス可能な“内部ネットワーク”をしっかり保証するグリッドキャストヴォールトインターフェイスの一実施形態を示す。全ての内部ネットワークは、スーパーノード間やスーパーノード及びメディアヴォールト間の認証、グリッド使用の報告、そして、全ての重要システム間のシステム健康状態を管理する一実施形態において、ワンマスター“グリッドコントロール”ネットワークによってコントロールされる。

フィード１５０は、データを分配するために信頼された仲間と共に同意に入り込む顧客の構成で生成される、シンジケーションフィードの一実施形態を示す。信頼された仲間は、“アウトレットパートナー”と呼ばれる。シンジケートされたフィードは、メディアヴォールト所有者によってメディアヴォールト上に生成され、ＦＴＰ（ファイルトランスファープロトコル）を介してアウトレットパートナーに押し付けられる。アウトレットパートナーは、例えば、ウェブサイトや、セットトップボックスや、デジタルファイルのための分配をしっかりとなすためのコンピュータアプリケーションを形成するのに必要な情報の全てを含むシンジケートされたフィードを受信する。シンジケートされたフィードは、ＸＭＬを介して消費され、その結果、ウェブサイトにて顧客に商品を展示するために必要なイメージと共に、ＸＭＬをデコードするために必要なＸＭＬスキームも含む。一人のエンドユーザがアウトレットパートナーウェブサイトにて（例えば視聴すべきムービーを）消費するためにデジタルファイルを選択するとき、アウトレットパートナーは、おそらく、メディアヴォールトでユーザがデータを消費することをまずは許すだろう。メディアヴォールト所有者は、各内蔵ファイルを許可し且つ値付けする。その結果、アウトレットパートナーは、各ユーザに同意し、メディアファイルをダウンロードすることを許可し、コンテンツ所有者によって後にインボイスするためのコストを被る。

ランチ１６０は、‘セットトップボックスランチ’や‘ランチに基づくＰＣアプリケーション’であり得るメディアファイルの‘ウェブランチ’の一実施形態を示し、アウトレットパートナーでマテリアルのカタログをざっと目を通した後、ダウンロードするためのムービーを選択する。本発明のクライアントアプリケーションは、ユーザが見るべきデジタルファイルを選択するとき、‘ランチ’や‘ラン’自身に対して目を通す装置を構成する。クライアントアプリケーションは、ランチデータをデコードし、ムービーのダウンロードを開始するためにネットワークと接触することを始める。

ネットワーク１７０は、以下により詳細に説明するように、等しく複雑なプロトコルに基づく非常に複雑なデータ交換において、インターネット上に層となるネットワークと相互接続し且つ通信する幾千あるいは何兆ものクライアントコンピュータの収集である、“グリッドキャスト”あるいはグリッドデリバリネットワークの一実施形態を示す。シングルクライアントアプリケーションは、暗号化されたデジタルファイルをダウンロードし、一方、同時に、バックグラウンドにおいて、暗号化されたデジタルファイルを他のコンピュータと分ける。必要なファイルを分配する他のクライアントを知るためのクライアントアプリケーションのために、クライアントアプリケーションは、デジタルファイルの重要な部分を保存するクライアントのリストである“ノードリスト”に関するスーパーノードサーバであって、接続するのに望ましいスピードを有するスーパーノードサーバと接触する。リストを受信した後、クライアントアプリケーションは、データ交換を開始するために、ＴＣＰ／ＩＰ（メジャーなインターネットデータ伝送プロトコル）を用いて他のクライアントとの接触を開始する。クライアント、積極的にデジタルファイルをダウンロードしないものでさえ、他のクライアントをクロックの周りに共有するために構成される。

図２は、一実施形態におけるメディアヴォールトの詳細図である。ヴォールト２２０は、図解された実施形態において機能を実行するために接続される外部“グループ”の三つの大きなグループを有するメディアヴォールトを示す。第１グループは、アイテム２４０，２５０，２６０で示される。アイテム２４０，２５０，２６０は、洗練されたＳＳＬ及びＨＴＴＰ ＤＩＧＥＳＴパスワード認証手順を通じてメディアヴォールトに接続するヒューマンユーザを図解する。認証された後、ユーザは、メディアヴォールト２２０にアクセスすることが許される。エンドユーザは、実行すべきあるタスクを実行することを許される許可レベルの種類をプリセットする。各ユーザは、他人がしないいくつかのタスクを実行するよう構成される。その結果、メディアヴォールトにおける各機能が構成される。三つの主たるユーザグループは、会計担当者、カタログ管理者、デジタル権管理者である。会計ユーザは、メディア使用についてアウトレットパートナーに請求し、ネットワークのコストを管理し、そして、ネットワークについての重要な統計情報を得るために用いられる使用報告を作成するために、メディアヴォールトを使用する。カタログ管理者は、メディアヴォールトにおけるメディアを構成し、デジタルメディアの詳細な各特徴を記載したデータを入力し、デジタルメディアをインポートし、メディアヴォールト内にイメージをスキャン及びアップロードし、メディアにシリアルナンバーを割り当て、そして、他のユーザのためのワークフローを管理する。デジタル権管理者は、各メディアファイルの値付け及びコストを貨幣化し、ユーザによる使用権を管理し、構成されるユーザグループによってダウンロードされるメディアの質及び量を分類する。

エンコーダ２１０は、デジタルメディアと共にメディアヴォールトをロードするためにエンコーディングスタジオの“インポート”機能を提供する。データストレージ２３０は、一実施形態において重大なディスク失敗を保留するために重複して連結されたハードディスクのラージストレージエリアネットワークアレイにおけるデータが存在する場所を図解する。他のストレージオプションは、例えば、分配された方法で類似する目的のために用いられる。

スーパーノード２８０は、一実施形態においてシングルスーパーノードを備えるメディアヴォールトの相互作用を図解する。メディアヴォールトは、グリッドコントロールネットワークデバイスや他の供給物を介して構成される、何ダース、何百ものスーパーノードに接続する。スーパーノードは、デジタルメディア概要記録をダウンロードし、ネットワークを“シードする”ためにメディアの暗号化されたセグメントをダウンロードし、そして、デジタルメディアファイルを用いる必要にある復号化キーをクライアントアプリケーションに安全に渡すためにユーザによって認証を確認すべく、メディアヴォールトと相互に作用するよう構成される。インターフェイス２７０は、一実施形態においてメディアヴォールトを備えた相互作用サービスを図解する。インターフェイス２７０は、出ていくシンジケーションフィードと相互に作用することを許容し、メディアアウトレットパートナーのための入ってくるクライアント認証ゲートウェイを提供する。

図３は、各種実施形態においてサポートされる多くの種類のファイルの一つである、デジタルムービーをエンコードするためのコーデック“コード／デコード”モジュールを図解する。ビデオメディアは、メディアがかなり大きいそのままの状態で変換され、“圧縮”されなければならない。洗練されたアルゴリズムは、ブロードバンドインターネットや他のネットワークを横断する速いトランスミッションを提供するために十分小さいファイルにデータを“圧縮”するために用いられる。一つの特定なコーデックにとって、コンセプトは、八つのピクチャーフレームの連続するバッチにムービーを分割し、その全体における各バッチの第１フレームを圧縮することである。各バッチにとって、第１フレームから“変更される”第２フレームのデータのみがエンコードされる。先のフレームから変更されるデータのみを圧縮するこのプロセスは、第８フレームまで繰り返される。結果のファイルは、そのままのメディアデータよりも輸送しやすいフォームでのオーディオ・ビデオ混合データである。連続するフレームのための変更及びデルタ情報は、例えば、ＭＰＥＧエンコーディングにおける変更情報に近似する。

データをエンコードするため、メディアファイル３１０が提供され、ビデオストリーム３２０とオーディオストリーム３３０とに分けられる。ビデオエンコーダ３５０は、エンコードされた（圧縮された）ビデオデータを提供し、オーディオエンコーダ３４０は、エンコードされた（圧縮された）オーディオデータを提供する。フィニッシュモジュール３７０は、エンコードされたオーディオデータとビデオデータとを単一のエンコードされたファイルに結合する。クライアントアプリケーション３８０で、ビデオは、モニタ、テレビジョン、ハンドヘルドデバイス、あるいは一実施形態において一秒当たりおおよそ２４ピクチャーフレームでユーザ３９０によって見られる他のディスプレイ技術上に表示される実際のムービーファイルに“デコード”される。この全ては、離れた場所でユーザ３９０によって見るための提供されたメディアファイル３６０を運んだり、楽しんだりすることを許容する。

図４は、メディアヴォールトで構成され、完成され得るシンジケートフィードの詳細、あるいは、いくらかの実施形態においてスーパーノード４１０を介してアクセスされるメディアヴォールト上に含まれる部分的なカタログの詳細を示す。全カタログは、許可レベル、レンタルタイプ、メディアタイプ、カテゴリ（再帰的にサブカテゴリ化されるか否か）、そして、各種の顧客プログラムフィルタリングに基づく“フィルタを通され”ている。ＸＭＬフィード４２０において、ファイルトランスファープロトコル（ＦＴＰ）を用いてアウトレットパートナーウェブサイトに送信されるＸＭＬフィードを見ることができる。アウトレットパートナーウェブサイト４３０は、規則的なスケジュールでＦＴＰサーバ上にファイルを受信し、ＸＭＬデータ、ＸＭＬスキーム、そして、視聴のためにシンジケートされたフィードにおけるメディアに顧客ユーザがさっと目を通すことを許すウェブサイト、セットトップボックス、ハンドヘルドデバイス、あるいはＰＣアプリケーションを形成するための内蔵イメージを用いる。フィードにおけるいくつかのメディアは、通常はアウトレットパートナーによって貨幣フィー交換において、ユーザが任意にアクセスされる必要がある許可レベルのためにセットされる。例えば、ユーザがアウトレットパートナーウェブサイト４３０にフィーを支払った（４５０）後、必要ならば、しかる後、アウトレットウェブサイトは、それらファイルを見るためにアウトレットパートナーがユーザに許可を与えることを許す、保証された“ＳＯＡＰウェブサービス”（４６０）を介してメディアヴォールトと通信する。通常、メディアヴォールト４１０の所有者は、かれらのコンテンツを使用するためにアウトレットパートナー４３０に支払う。もちろん、他の支払協定も同様に可能であり、例えば、ユーザは、フィーを控除することによってメディアサービスにアクセスする各時間を短縮する払い込み会計であり、あるいはメディアにアクセスする各時間でフィーが変更される信用取引を有し得る。各種の協定が代わりの実施形態において可能である。

トランスファー４４０は、グリッドデリバリネットワークへのアクセスからメディアファイルをダウンロードすることを開始するためのクライアントアプリケーション“ラン”を備えて、ウェブランチを図解する。アプリケーション４７０は、メディアヴォールトへのスーパーノード４１０を介して自身の認証４８０のチェックがこのコンテンツにおいて示される、クライアントアプリケーションである。もし認証が（許可レベル、予約状況、あるいは視聴権による支払に基づいて）与えられるならば、ユーザは、グリッドデリバリネットワーク（ピアツーピア接続４５５，４６５，４７５）からダウンロードされる暗号化されたセグメントをアンロックするための認証キーが渡され（４９０）、ムービーを視聴することが許される（４９５）。

図５は、スーパーノードが一実施形態におけるクライアントアプリケーションと相互に作用するメカニズムを示す。“ウェブランチ”、あるいは類似するイベントの後、ユーザ（クライアント）は、スーパーノードネットワークの“ドメインネームを決定する”（５２０）ことが要求される。非常に確立された“ドメインネームシステム”を通じて、ユーザは、ユーザに最も近いスーパーノードのＩＰアドレスが運ばれ（５４０）、より速く、より高いスピードで、より応答性のよいサーバにユーザが接続することが許される。用いられるＤＮＳサーバ（５３０）は、このまれな“地理上の”ロックアップを実行するためにカスタムプログラムされる。スーパーノード５５０において、図解を目的として、このユーザは、日本東京スーパーノードの範囲において最も近いものが決定される。しかる後、クライアント５１０は、メタデータをダウンロードするプロセスを通過し、“ジョブチケット”を獲得し、必要ならばシードをダウンロードし、復号化キーを確認して得て、そして、スーパーノードに使用データを返信する（処理モジュール５７０）。ネットワーク５０において、ユーザ（クライアント）は、ジョブリクエストが回答された時点で発見されたグリッドネットワーククライアントであって、メディアファイルを正しく分ける全クライアントの全ノードリストも含むグリッドネットワーククライアントからムービー５６０をダウンロードする。

ネットワークを横断する全てのファイルが、一実施形態において１６０ビットＳＨＡ１ダイジェストアルゴリズムを用いて生成される“マスターハッシュ”によって記述されることに気付くべきである。デジタルメディアファイルの各“セグメント”は、類似する１６０ビット形式で記述される。従って、各セグメント及び全マスターハッシュは、これらの実施形態においてダウンロードのためのネットワーク上に固有な“ネーム”である。これはまた、ハッシュを生成するダイジェストアルゴリズムが、セグメントが正しい“ベリファイ”に用いられ得ることも意味する。

図６は、機械装置と、そして、ビデオ、オーディオ、ソフトウェア及びデータメディアファイルをデジタル化し、しかる後、グリッドネットワーク上に使用のためにそれらファイルをエンコードする集約的なタスクで変更されるソフトウェアプログラムとの複合配列であるエンコーディングスタジオを示す。インターフェイス６２０，６３０，６４０で、ムービーを最初に点検し、しかる後、デジタル化ワークステーション６５０にそれらをロードする者である、エンコーディングスタジオ管理者によって受信される。可能なビデオフォーマットは、ＤＶＤ、ＶＨＳ及び３５ｍｍフィルムストックである。メディアをデジタル化するためのコマーシャルソフトウェアを用い、“そのままのメディアファイル”は、エンコーディングセッションを終えるようになるために、エンコーディングコンピュータを待つデータを抱える“ストレージサーバ”（６６０）内に入れられる。エンコーダ（６７０）がジョブを終えると、それは早速、エンコードされるよう待っているファイルを探すストレージサーバに接触する。しかる後、エンコーダは、全デジタルメディアファイルをそのシステム内に引っ張り込み、ネットワークを介して伝送するのに適切なフォーマット（図３）にムービーをエンコードする複雑なプロセスを開始する。エンコーダが終わると、結果エンコードされたメディアは、デジタル的にストレージサーバ（６６０）にコピーされる。ストレージサーバがメディアヴォールトに伝送されるのを待つデジタルメディアファイルで満たされるので、技術者６８０は、エンコードされたファイルを、足、自動車、あるいは、理論上世界のどこにでも設置され得る顧客メディアヴォールトへのデリバリサービス、による搬送のための冗長ディスクの外部配列である“スニーカーネット”ドライブ６９０にコピーする。

図７は、いくつかの実施形態においてビデオプレイバックのためのグリッドネットワーククライアント技術に統合するインターフェイスの典型的な実施である、プレーヤの一実施形態の例を提供する。これら描写は、エンドユーザの視点からのビデオプレーヤを示す。プレーヤアプリケーションそれ自体は、そのプレゼンテーションが見て感じれるよう、ダイナミック“スキン”アプローチを採用する。“スキン”の選択（及びその結果のプレーヤの状況）は、供給元、メディアライブラリ、そして、ムービー（以下の“ＶＳＩファイル”を参照）を開始したときにプレーヤによって与えられるメディアメタデータに含まれるターゲット言語情報から引き出される。これは、供給元ごと及び場所ごとのカスタマイゼーションを認める。一つのメディアアウトレットからクライアントが発信されるとき、ウェブサイトから発信されるムービーが完全に表示される。アウトレットパートナーは、顧客スキンを要求する。もし、スキンがクライアントコンピュータ上に局所的に存在しないならば、クライアントは、このスキンをダウンロードし且つインストールして“取ってくる”。図示されるインターフェイス７００は、ブランド７１０、ウィンドコントロール７２０、タイトル７３０、メディアディスプレイ７４０、ステータスバー７５０及びプレーヤコントロール７６０を含む。

図示されるビデオプレーヤは、フルスクリーントグル、ボリューム及びミュート選択、プレイ機能性、ポーズ、ビデオプレイバックのポジションを含みつつ、コモンビデオプレイバック操作及び特徴を提供する。これら特徴の大半は、ホスティングビデオシステム技術によって処理される。しかしながら、プレイバック、ポーズ、ポジションに関する特徴は、プレイバックに同期されたメディアのデリバリを維持するために、プレーヤとグリッドネットワークエンジン（クライアント）との間の通信を要求するので、基礎をなすグリッドネットワーク実施との関係で実施される。

ダイヤグラムに表される実施がビデオプレイバックの関係にフォーカスされるが、グリッドネットワークプラットフォームに固有なコンポーネントは、メディア及び／又はコンテンツプレゼンテーションの他の種類と主として同じである。これは、オーディオフォーマットや、書籍、ブループリント、フォトコレクションといったラージフォーマットドキュメントといったのに限定されず、ハードコピーメディアを生成するためのＩＳＯ ＣＤ／ＤＶＤイメージ、実行可能及び／又はインストール可能なソフトウェアアプリケーション、そして、デジタルコンテンツ及びプレゼンテーションのどんな他のフォームやフォーマットを含む。必要不可欠なメディアコンテンツを得る、有効にする、運ぶためのプロセスは、全てのメディアタイプと同じである。ピアツーピア伝送のセキュリティ、会計、有効性の利益は、メディアタイプに関わらずに持続する。メディアプレゼンテーションの異なるフォームを容易にするため、サブシステムを提供する最終結果は、適切にインターフェイスされることのみを必要とする（以下のプレゼンテーションインターフェイスコンポーネントを参照）。時間ベースのメディア、例えばオーディオ及びビデオといったものは、同期化、時間に敏感なデリバリのための追加的なサービスを要求する。これらのサービスは、グリッドネットワーク技術によって提供される。

図８は、いくつかの実施形態においてビデオストリームプレーヤインターフェイスに関して実施されるグリッドネットワーククライアントの概念図を示す。概念図がそのようなシステムに見出されるコンポーネントの図解である一方、これは、そのようなシステムを実施するためのオプションではなく、他実施形態は、類似した又は異なる実施を用いる。グリッドネットワーククライアントの主要なコンポーネントは、以下に示すとおりで、ダイヤグラム内に同じようにラベルされる。

ＶＳＩファイル８０５：各メディアコンテンツタイプのために、対応するメタデータファイルがある。これらファイルは、本実施形態の名称集にて、“ＶＳＩ”ファイルとして知られている。これらファイルは、例えばムービーといったメディアの特定部分の情報を含み、メディアタイプ、供給元コード、そして、許可及びレンタルタイプに関する情報を含む。これらファイルは、メディアが利用可能な各種フォーマットも含む。これは、異なるダウンロードビットレート及び異なる言語での可能な複数の選択を含む。

ローカルストア８７５：“ローカルストア”は、メディアセグメントを保持する目的で取っておかれるユーザのハードディスクストレージ（クライアントローカルストレージ）の一部である。メディアセグメントは、ＳＨＡ１ハッシュの名の下にエンコートされ且つセーブされる。メディアの特定部分を構成するセグメントは、メディア名のＳＨＡ１ハッシュ（全メディアファイルのハッシュ）下に記録される。このローカルストアエリアは、予定された（また、構成可能な）最大ストアサイズ（一般的には、本実施形態において２ＧＢ）に対し、“余分なものが取り除かれた”全メディアセグメントのトータルサイズを保つべく、常に維持される。

メムキュー（MemQueue）８７０：メムキュー８７０として知られる共有メモリセクションは、二つの分離された主要特徴を提供する。一つは、高効率メカニズムのように、ローカルストアディスク上よりもむしろメモリ内に一つ以上のセグメントを保持するためのキャッシングメカニズムとして用いられる。メムキュー８７０共有メモリの他の特徴は、プレーヤとグリッドネットワーククライアントの分離したプロセスが伝えられ得ることによって、ＩＰＣ（内部プロセス通信）メカニズムのように動作することである。

プレゼンテーションインターフェイスコンポーネント（VSISource.ax）８１０：プレゼンテーションインターフェイスコンポーネント８１０は、グリッドネットワークによって運ばれるメディアをメディアレンダリングエンジンにとってふさわしい利用可能なフォーマットに変換する中間コンポーネントである。ダイヤグラムに詳述される実施形態において、これは、マイクロソフトダイレクトショーフィルタコンポーネント（VSISource.ax）のラッピング内で行われる。他のオペレーティングシステム及び／又は他のビデオレンダリングサブシステムの実施は、同じ必要なグリッドネットワーク仕様の機能性を実施するために、ホストに適切な同じラッパーを用いる。

プレーヤは、ファイルからデータを受信するためにオペレーティングシステムにリクエストがなされるのと同じようにして、メディアをストリームし、プレゼントするためのデータを要求する。それは、プレゼンテーションインターフェイスコンポーネント８１０がその主要なレンダリングエンジンとのインターフェイスをなすこのレイヤで、である。データの要求は、ローカルストアにおけるメディアセグメントが要求されたデータ範囲をどのようにして含むかを決定するために、グリッドネットワーククライアントに対するメムキュー８７０を介する通信を通じて実行される。グリッドネットワーククライアントによって提供されるデジタル権管理（ＤＲＭ）エンコーディングキーを用い、コンポーネントは、これらセグメントを復号化し、要求されたデータを返信する。ダウンストリームレンダリングプロセスのリメインダーは、あたかもローカルファイルから取り出されたデータを有するかのように継続し、メディアがエンドユーザのために提供される。そのような実施形態において直接的に提供されあるいはコピーされ得るファイルはクライアントシステム上に一切存在せず、従って、潜在的に強化されたセキュリティは提供されない。さらには、異なるラッパーやコードが用いられるように、ディスプレイや使用やストレージのための異なるフォーマットに対するレンダリング（例えば、メディアのＤＶＤタイプへのレンダリング）は、利用可能なプレゼンテーションインターフェイスコンポーネント８１０に単に基づくオプションである。

ジョブ８２５：グリッドネットワーク"ジョブ"は、確認されたメディアの要求です。グリッドネットワークは、提供されたＶＳＩファイル８０５から得られた情報を用い、ドメインネーム上のＤＮＳ決定を実行することにより、適切なサーバのインターネットＩＰアドレスを得る。ジオロケーティングネームサービスは、クライアントに最も近いサーバを提供する。しかる後、グリッドネットワーククライアントは、"ジョブチケット"８３０、クライアントに共通なローカルであるピアノードの"ノードリスト"を要求しつつこのサーバに接触する。ジョブチケット８３０は、接続ピアが要求するデータを受信するために許可されるのを確認するためにピアが使用する時間限定な確認及びキーである。サーバは、このメディアファイルを作成するために、全セグメントハッシュのリストをクライアントに提供する。このセグメントハッシュのリストは、ピア間で伝送されるデータを要求することと確認することの両方で用いられる。

アクティブジョブ８４５：ジョブは、キュー８４０にキューされ、順番に処理され、あるいは迅速なダウンロードのためにプロモートされる。ジョブは、セグメントが受信されたオーダが重要でないことを意味する"非同期モード"と、セグメントが受信されたオーダがプレイバックにとって重要であることを意味する"同期モード"のどちらにおいてもダウンロードするようセットされ、レンダリングプレーヤとグリッドネットワークダウンロードエンジンとの間で追加的な同期化を要求する。デフォルトによって、ジョブは、非同期モードでキューされる。典型的なビデオオンデマンド要求の関係において、最も直近に要求されたジョブは、どんな目下のアクティブジョブをも一時停止して、直ちに始動され、プレイバックのための同期モードに直ちに置かれる。しかしながら、この動作は、ユーザ及びデリバリコンテキストの必要性及び望みによって調整可能である。

セグメントマネージャ８５０、ピア伝送８６５、アップロードマネージャ８６０、ダウンロードマネージャ８５５：ダイヤグラムでラベルされるコンポーネントは、必要ならシーディングサーバを転送するのと同様、コアピアツーピア伝送機能性を提供するために一緒に動作する。プロセスは、他のピアとの接触を最初になすことによって動作する。これは、サーバ供給ノードリストにおけるピアを見つけ、接続を開始することによって生じ、あるいは、他のピアがクライアントとの接続を開始する。なされる接続の総数は、構成可能な値であるが、（例えばクライアントやユーザプロフィールに）記録されるようなインターネット接続の最大バンド帯によっても限定される。

ひとたび通信が確立され、ジョブ確認が認められると、ピアは、もはや接続が維持されることに双方のアドバンテージがないというまで、セグメントをスワップする目的のために加えられる。セグメントスワッピングプロセスは、クライアントが利用可能なセグメント（"オファーリスト"として知られる）と通信しつつ、ピアに特定の望ましいセグメントを尋ねるクライアントを含む。応じて、リモートピアは、提供されるオファーリストからの自信の要求と共に、（利用可能ならば）要求されたセグメントのヘッダー情報を送信する。それはまた、自身の目下のオファーリストと通信する。これら交換は、一つ又は両方がもはや互いにオファーしないというそのときまでピア間で継続する。

一つのピアがこれらセグメントを有しない他のピアに先立ってムービーをダウンロードしているときに起こる片側交換において、主たるピアは、接続から目下のところ利益を得ていないが、気持ちよくそのようなスタンスを取り入れるべく自身のプレイバックポジションに十分に先立っている限り、接続を終了しないよう選択する。もし、両方のピアがそれらのプレイバックポジションに気持ちよく先立っているならば、セグメントのオーダは、もはや連続的であることを必要とせず、ピア間の交換がより寛大な基準で起こり得る。それらセグメントを要求するアルゴリズムを用い、リモートピアは、全ての接続されたピア間で"最もめずらしい"セグメントであるものを有し、接続されたピア間でより均等なセグメントの分配がプロモートされる。これは、グリッドを横断してセグメントの同種の分配を保証する手助けとなり、特定のセグメントのためにピアが欠けている結果、ピアがシードサーバと強制的に接触する環境をさらに小さくするよう働く。

セグメントがクライアントに到達するとき、ＳＨＡ１ハッシュが所定のセグメントネームと同じであることを確認するよう処理される。この確認は、データが不正行為をも体験しないことを保証する。プレゼンテーションインターフェイスコンポーネント８１０とセグメントマネージャ８５０との間の内部関係は特に重要である。プレイバックの間、プレーヤは、その目下のプレイバックポジションを頻繁に知らせる。これから、グリッドネットワークは、セグメントをダウンロードするオーダ及びパフォーマンスに関し、"緊急"の判断を決定することができる。もし、プレイバックポジションにそれほど先立って空のセグメントがないならば、できるだけ早くこれらセグメントを受信することが強調される。もし、この距離がより短くなるようになれば、及び／又は、接続されたピア間で利用可能なバンド帯をダウンロードする会計が限られているならば、シードサーバへの接続は、ムービープレイバックを邪魔することなくターゲットダウンロードレートを維持するために開始される。

もし、プレイバックポジションが空のセグメントに逆らって上昇することから離れてモーメントであれば、グリッドネットワーククライアントは、ポーズし且つ継続の前に十分なバッファリングを待つためにメッセージを指示するプレーヤに対してそれを送信する。もし、プレイバックポジションに先立って近接するセグメントの十分なストレッチがあるならば、グリッドネットワーククライアントは、それ自身に先立って他のピアの必要性に対し、自由により応答性を良くすることができ、現在ダウンロードに従事していないローカルストアからのセグメントの要求に対する応答を含む。これは、異なるムービーを見るピアが、同時に同じムービーを見る必要が無いクライアントのローカルストアから利益を得ることを許容する。

このように、セグメントマネージャ８５０は、セグメントプレイングに関係してバッファとなるセグメントのステータスを決定するために、クライアント上に局所的に保存されたセグメントを管理し、プレーヤと相互に作用する。アップロードマネージャ８６０は、必要なように他のピアへのデータのアップロードを管理する。同様に、ダウンロードマネージャ８５５は、必要なように他のピアからのデータのダウンロードを管理する。このように、これら四つのコンポーネントのそれぞれは、クライアントのために緊急レベルをセッティングし、該緊急レベルと相互に作用するようになっている。

ローカルストア８７５インベントリ及びメンテナンス。ローカルストア８７５は、定期的に棚卸しされ、満杯になりそうならば、サイズを小さくするために余分なものが取り除かれる。インベントリは、ストアにおける利用可能なメディアのサーバに対する相対率を報告するのに用いられるので、利用可能なメディアファイルの一部を有するそれらクライアントは、理にかなった方法で他のピアに分配されたノードリストを生成するために追跡され、命令される。このインベントリタスクは、しばしばアップデートされたインベントリ会計及びメンテナンスを維持しつつ、しかしながら、全てのアプリケーションのパフォーマンスを遅延させることなく、グリッドネットワークの他の機能と平行して実行される。インベントリ量は、規則的にスケジュールされたレポートサブミッションの間と、新しいジョブを要求する間の両方で報告される。

報告８９０：規則的なインターバル、いくつかの実施形態において構成可能な期間であるが、一般的には１２時間以上で、クライアントは、各種のサマリ及びトランザクション統計を報告８９０する。この統計データは、ノードパフォーマンスを決定し、グリッドにおける弱点を解析し、そして、他の追随を許さないクライアントパフォーマンスを保存しているそれらノードを確認するために主として用いられる。これは、最良ノードをピアに提供する手助けとなる。データは、スケジュールタイマ８８５を用いてスレーブサーバ８９５に報告される。

自動アップデート：グリッドネットワーククライアントは、ソフトウェアの新しいバージョンが自動的に届けられ得ると共に、クライアントがアップデートされることによって、使いやすさを提供することもできる。目下の動きがなく、アプリケーションが休止中である期間において、目下のバージョン及びホストプラットフォームに与えられた新しく利用可能なバージョンがあるならば、要求が見られるようになる。そうならば、この新しいバージョンあるいはパッチのインストーラがダウンロードされ、黙ってインストールされ、プログラムが再開される。代わりに、ユーザは、ユーザが実際のインストレーションを始めるのを許しつつ、新しいアップデートの到着が通知される。そのような自動メカニズムは、製品の特性を発展させるのに重要であり、ユーザが同様に洗練された製品にあてにするようになる特徴である。

グリッドネットワークを用いたビデオオンデマンドプレイバックを含む一般的なシナリオは、以下のように生じる。このプロセスの記述の間は図８を参照する。プレーヤは、プロセスにＶＳＩファイル８０５が与えられる。これは、一般的には、ウェブブラウザ（図示されない）からハンドオフを通じてなされるが、ダイレクトファイルアクセスや他の手段を通じても可能である。しかる後、ＶＳＩファイル８０５は、最も近いサーバからジョブを要求するために要求された情報で構文解析される。返信されたノードリスト及びジョブチケットは、ムービーのいくつかの部分を有すると考えられるネットワーク上の他のピアと接触するよう用いられる。ムービーは、プレイバックモードに直ちに置かれ、その結果、プレイバックを始める必要があるデータのストリーミングを始める。

可能ならどこででも、セグメントは、多くの利用可能なピアの一つから受信される。このように、メディアコンテンツは、バンド帯コスト無しに主たるサーバに分配される。利用可能なピアが必要なセグメントを有しないイベントにおいて、あるいは、クライアントにとって最小ビットレートを維持するために数ピアが存在するならば、サーバは、接触されるが、必要な限りの間のみである。そのようなイベントにおいて、サーバ上の従属から自由になるのに十分なピアを見つける見込みで、新たなノードリストが定期的に要求される。

最上のコンテキストにおいて、スーパーノード又はシードサーバから直接取り出されるコンテンツは少ないか無い。しかしながら、用いられることが少ないメディア、あるいは新しくリリースされたメディアへの最初の顧客にとって、サーバは、他の時よりももっと当てにされる。セグメントを交換するためにピアが続くので、ダウンロードされたセグメントは、クライアントのローカルストアに書き込まれる。ここで、プレーヤは、プレゼンテーションインターフェイスコンポーネント（ＶＳＩ Ｓｏｕｒｃｅ．ａｘ）を通じ、プレイバックのための最終フォームに復号化され且つ与えられるストアからデータを読み出す。ユーザは、ムービーを楽しみ、おそらくムービーの異なる部分を見るためにプレイバックポジションを動かし、そして、上述したように、"緊急"を変更し、グリッドネットワークによってセグメント要求を処理する。ムービーが終ると、グリッドネットワーククライアントは、バックグランドでのランを続け、求められるような他のピアへの要求を供給することを続けることが可能である。定期的なインベントリ及び報告タスクは、目下のメンテナンスタスク及び報告タスクを維持する。

図９は、実施形態においてスレーブサーバ、クライアント及びピア間でのオペレーションを図解する。このように、図８のスレーブサーバ８９５は、クライアント８１５に多くの機能を提供し、一方、クライアントは、ファイルセグメントを交換するためにピア８８０と相互に作用する。システム９００のスレーブサーバ９１０は、ＶＳＩファイル９１５（ファイル識別子）のダウンロード、ジョブチケット９２０の取得、シード９２５（シードされたセグメント）のダウンロード、認証要求９３０への応答、そして、定期的な報告９３５といった機能を提供する。クライアントプログラム９４０は、各種の方法に拡張ないし適用されるＨＴＴＰ又はＳＯＡＰプロトコルを用い、各種の機能及びスレーブサーバ９１０の関連するモジュールと調和する。同様に、クライアントプログラムは、交換のためのジョブチケットを用い、そして、いくつかの交換のためのシードされたファイルセグメントを用いて、メディアファイルセグメントを交換するためにピア９４５と相互に作用する。クライアント９４０は、その状態を定期的に報告し、ＶＳＩファイルをダウンロードするか、新たなファイルダウンロードを始めるか他のピアのジョブチケットを確認するかを要求されるように認証を要求する。

図１０は、グリッドネットワークからムービーファイルをプレーするためのプロセスの一実施形態の図解を提供する。プロセス１０００は、ムービーあるいはウェブサイトからの類似するメディアファイルを要求すること、ファイルのために識別子を受信すること、ファイルのためにチケットを要求すること、支払情報を提供すること、ファイルのためにチケットを受信すること、ファイルのセグメントを検索すること、そして、ファイルを用いること、を含む。プロセス１０００は、特にムービーファイルを参照して述べられるが、メディアファイルやデータファイルの他のタイプものが他実施形態においてプロセス１０００で用いられる。プロセス１０００及び本文章の他のプロセスは、一組のモジュールとして実施される。プロセス１０００のモジュール及びここで記述される他のプロセスは、パラレル又はシリアル形式といったように再整理され、記録され、結合され、あるいは各種の実施形態に再分割される。

再びムービーファイルの特定の例を参照して、ムービーファイルの要求は、例えば、ＨＴＴＰサブミッションといったものを通じて、モジュール１０１０でウェブサイトに提出される。応じて、ムービー識別子は、モジュール１０２０でウェブサイトによって提供される。一実施形態において、ムービー識別子は、完全なハッシュに近づく、あるいは完全なハッシュである、ムービーファイルのためのハッシュ値である。ムービー識別子を受信して、ムービーチケット（あるいはジョブチケット）は、モジュール１０３０で要求される。プロバイダ又はウェブサイトは、ジョブチケットを生成するために支払いを要求し、支払情報は、ユーザインターフェイス、ユーザプロフィールといったものを介して、モジュール１４０で提供される。ユーザが予約を進める例において、ユーザプロフィールは、例えば、この状態を指示する。あるいは、クレジットカード情報は、プロフィールのいくつかのフォームに保存されるか購入の時点で提供されるかのどちらかである。

受信された支払いと選択されたタイトルを伴い、ムービーチケットは、モジュール１０５０で受信される。ムービーチケットは、例えば、それがいつ確かであるか、それが何のためのムービーであるか、関連するムービーファイルがどこで得られるか、についての情報を含む。例のムービーチケットの実施形態は、以下でさらに検討される。モジュール１０６０で、ムービーセグメントを検索するプロセスが開始される。チケットに関連するムービーファイルのセグメントは、各種のマシーン上で見つかって、さらに、規制されない形式で受信されたマシーンのグリッドネットワーク内で検索される。ムービーはモジュール１０７０でプレイされる。これは、ムービーのセグメントがモジュール１０６０の一部として受信されるのに十分早い応答性を生じ、しかも、ムービーがモジュール１０７０の一部としてプレイしつつ、追加的なセグメントを受け取ることを許容する。このように、モジュール１０６０，１０７０は、やがてセグメントが利用可能となる場所や、やがてセグメントが必要とされることを決定することへの相互作用を備え、パラレル形式で動作する。

各種のシステムがムービーチケット、ムービーやジョブチケットの類似する結合、メディアファイルと関連して用いられる。図１１は、グリッドシステムの一実施形態の図解を提供する。システム１１００は、ウェブサイト、スーパーノード、クライアントＡ、クライアントＢ及びネットワークを含む。追加的なクライアント及びスーパーノードといった追加的なコンポーネントは図示されない。

システム１１００は、ムービーや他のメディアについての情報が得られるところで、ウェブサイト１１１０を含む。クライアントＡ（１１３０）は、（例えば、ワールドワイドウェブである）ネットワーク１１５０を通じてウェブサイト１１１０にアクセスする。ウェブサイト１１１０でタイトルを見つけた後、クライアントＡは、関連するムービーを要求し、ムービーのための識別子をウェブサイト１１１０から受信する。クライアントＡ（１１３０）は、ムービーのためのジョブチケットを要求し、例えば、クライアントＡ（１１３０）でムービーの視聴を許す。これは、ウェブサイト１１１０に支払ったり、支払を証明することを含む。

一般的に、ジョブチケットは、いくつかの実施形態においてクライアントＡ（１１３０）に相対的に接近する位置に地理的に位置するスーパーノード１１２０によって発行される。スーパーノード１１２０は、例えば、図１２に図解されるようなパケットの一部としてジョブチケットを発行する。図１２は、データファイルの要求に応じて用いられるパケットの一実施形態の図解を提供する。パケット１２００は、セグメントリスト、ノードリスト及び実際のジョブチケットを含む。このように、セグメントリスト１２１０は、例えば、セグメントの総数値と共にセグメントのハッシュとして表される、セグメントのリストを提供する。

そのような構造は、例えば、セグメントが受信されたかを追跡することを許す。さらには、そのような構造は、セグメントの要求を実行することの一部としてチェックする確認を許す−セグメントの要求を受信するクライアントは、要求が適切なハッシュ値を含むかを決定することができる。同様に、ハッシュ値は、受信された正しいセグメントを確認するために、関連する受信したセグメントから計算される。ハッシュ値は、いくつかの実施形態においてＳＨＡ１ハッシュ値のように１６０ビットハッシュ値である。このようなシチュエーションにおけるハッシュ値の総数は、完全に近いハッシュを許す−各ハッシュ値は、当該セグメントを独自に確認する。さらには、セグメントのハッシュ値は、いくつかの実施形態において（ムービーファイルといった）サラウンドムービーのためのハッシュ値と対にされるときに固有であろうとする。このように、セグメントのハッシュ値は、各セグメントをエンコーディングする３２０ビットハッシュを表すムービーファイルのハッシュ値を効果的に含む。

同様に、ノードリスト１２２０が含まれ、例えば、サブジェクトムービーメディアファイルのセグメントを有するノードのリストを提供する。さらには、ノードリストは、セグメントが所定のノードに存在することに関連するエンコードされたデータを備えてさらなるフィールドを含む。このデータは、スーパーノード１１２０によって維持され、クライアントによって提出されたデータに対して応答性良くアップデートされる。

ジョブチケット１２３０は、複数の異なるフィールドを含む。スーパーノードによって発行されるジョブトランザクションの固有な識別子、有効なタイムフレーム、これら二つの情報を認証するスーパーノードによって生成されるデジタル署名、そして、証明書にサインするコモンパブリックキーのコピーは、一つの実施形態において新たなジョブの要求上でクライアントに与えられる。図１３は、ジョブチケットの一実施形態の図解を提供する。識別子１３１０は、ジョブ要求を独自に確認する始まりのスーパーノードに知られている固有な識別子である。タイムフレーム１３２０は、このジョブのセグメントがピア間の又はシードサーバからの取引のために認証される時間'に'及び'から'正しく含む。スーパーノードによって知られるデジタル証明書１３５０は、識別子１３１０及びタイムフレーム１３２０において見つけられた情報のデジタル署名を生成するのに用いられる。デジタル署名（１３３０）は、スーパーノードがジョブチケットを発行したことを認証するために証明書（１３４０）のコモンパブリックキーと共に用いられ得る。（ファイルを要求しながら）ピアに接続すると、識別子１３１０及びタイムフレーム１３２０は、デジタル署名１３３０と共に送信される。リモートピア又はシードサーバは、スーパーノードから始められ且つクライアントの要求と共にセグメント情報を扱うために認証されるジョブチケット情報を確認することができる。

確認されたジョブチケット１２３０を備え、クライアントＡ（１１３０）は、関連したムービーファイルのセグメントを検索する。ジョブチケット１２３０は、ノード１２２０のリスト上で聞いているクライアントＢ（１１４０）に基づくセグメントを要求するためにクライアントＢ（１１４０）に与えられる。クライアントＢ（１１４０）は、スーパーノード１１２０を備えたチケットを確認することができ、しかる後、適切なセグメントをクライアントＡ（１１３０）に送信する。このように、クライアントＡ（１１３０）及びクライアントＢ（１１４０）間のピアツーピア（ほとんど直接的）結合が確立される。この結合は、ネットワーク１１５０を横切る実際のトラフィックをまだ含むようであるが、より直接的な接続として図解される。さらには、セグメントは、一般的に、クライアントＡ（１１３０）がもはやセグメントを必要としないと信号を送るまで、現在の基準上で送信される。

図１４は、メディアファイルを暗号化するプロセスの一実施形態の図解を提供する。プロセスは、ファイルをハッシュすること（ハッシュ値を計算すること）及びファイルのセグメントを暗号化することを大ざっぱに含む。プロセス１４００は、データファイルを受信すること、データファイルのハッシュ値を計算すること、データファイルのセグメントを確認すること、セグメントを暗号化すること、そして、暗号化されたセグメントを保存することを含む。暗号化されるファイルの種類は、ムービー、サウンド、アニメーション、テキスト及び他のファイルといったメディアファイルの各種タイプを含む。

プロセス１４００は、モジュール１４１０で暗号化のためにデータファイルの受信を開始する。モジュール１４２０で、ファイルのハッシュ値が計算される。ハッシュ値は、完全なハッシュプロセスを用いるか、完全なハッシュをほぼシミュレートしようとしたプロセスを用いて計算される。例えば、１６０ビットハッシュ値が一つの実施形態において計算される。完全なハッシュが必要ない間、２の１６０乗が固有な識別子の巨大な数を提供するので、十分に近づけられる。このように、全ての実践的な目的のため、ハッシュ値は、ファイルの識別子として用いられる。

計算された識別子を備え、ファイルのセグメントは、モジュール１４３０で確認される。これは、あらかじめ定められたブロックサイズによってファイルのサイズができるだけ簡単に分割し、あらかじめ定められたブロックサイズに基づくファイルをできるだけ簡単に分割する。代わりに、望ましいブロックサイズを決定することと、ファイルを分割することを含む。モジュール１４４０で、セグメントが暗号化される。一つの実施形態において、セグメントは、以前のブロックの暗号化されたバージョンに基づいてある程度暗号化される各ブロックを備え、チェーンブロックブローフィッシュシンメトリカル暗号化に基づくプロセスを用いて暗号化される。暗号化されたセグメントを備え、セグメントは、後の分配のために、モジュール１４５０で保存される。

保存されたセグメントを有し、ファイル内の暗号化されたフォームにそれらを再アッセンブリするためにセグメントを要求する。図１５は、暗号化されたメディアファイルを用いるプロセスの一実施形態の図解を提供する。プロセスは、ファイルを要求すること、セグメントを受信すること、最初及びそれに続くセグメントを暗号化すること、そして、セグメントの受信及び暗号化を続けることを含む。

プロセス１５００は、モジュール１５１０で識別子としてのハッシュ値を用いてファイルの要求を開始する。モジュール１５２０内で受信された最初のセグメントを備え、モジュール１５２０でファイルのセグメントが受信される。モジュール１５３０で、ファイル内で連続して、最初のセグメントが復号化される。これは、ファイルのハッシュ値を含み、例えば、デジタル署名のいくつかのフォームもまた含む。

モジュール１５４０で、ファイルの次のセグメントが復号化される。もし、これが最初のセグメントの復号化後にすぐに起こるならば、次のセグメントは第２のセグメントである。しかしながら、次のセグメントは、最後のセグメントが復号化された後のファイルにおいて次のセグメントに連続して求められる。モジュール１５５０で、復号化すべきセグメントがさらにあるかに関しての決定がなされる。もし是ならは、プロセスは、（必要ならば）より多くのセグメントが受信され且つ次のセグメントの復号化のためにモジュール１５４０に戻るモジュール１５６０に移動する。これは、セグメントが復号化される必要がもはやないとモジュール１５５０で決定されるまで繰り返される。例えば、ファイルのエンドが到達し、ファイルが（おそらくアクセスされず）クローズされ、あるいは、セグメントが受信されないかエラーが発生すると、プロセスが終了することに気付きなさい。

図１４及び図１５のプロセスと関係して各種の構造が用いられる。図１６は、メディアファイルの一実施形態の図解を提供する。メディアファイル１６００は、分割され且つハッシュ値が計算されるファイルである。このように、ハッシュ値１６１０が図解され、全ファイルに基づく。ハッシュ値１６１０は、図１７Ｂの値１７５０のような値−識別子として保存され且つ伝送されるスカラー値−である。セグメント１６２０は、ファイル１６００における連続したセグメントとして図解される。このように、セグメント１６２０ａが最初に来て、セグメント１６２０ｂ，１６２０ｃ，１６２０ｄ，１６２０ｅが続き、最後にセグメント１６２０ｍ及び１６２０ｎが来る。ファイル１６００のセグメントを暗号化するとき、セグメント１６２０ａは最初に暗号化され、セグメント１６２０ｂはセグメント１６２０ａ上の一部に基づいて暗号化され、以下同様である。

暗号化後、セグメントは保存される。図１７Ａは、メディアファイルのセグメントの一実施形態の図解を提供する。セグメント１７００は、ヘッダ１７１０、データペイロード１７２０及びチェックサム１７３０を含む。セグメント１７００の各位置は、プロセスの暗号化を備えて始められる。このように、ヘッダ１７１０は、例えば、メディアファイル識別子及びセグメントナンバーといった情報を確認することを含む。データペイロード１７２０は、（プロセスの暗号化の間、セグメントの他の部分や外部データと相互に作用するデータを潜在的に備えて）実際の暗号化されたデータを含む。チェックサム１７３０は、セグメント１７００がそれ自体無傷であるかのパリティーチェック及び入念なインジケーションのいくつかのフォーマットを提供する。それにひきかえ、図１７Ｂは、例えば、できるだけ簡単なスカラー数の値である、メディアファイルのハッシュ値の一実施形態の図解を提供する。

グリッドネットワーク内で、いくつかのクライアントは、公に利用可能であり、いくつかのクライアントは、ファイアウォールの背後に隠される。図１８は、グリッドネットワークの一実施形態の図解を提供する。システム１８００は、第１クライアントサイト１８１０、第２クライアントサイト１８２０及びそれらの間のネットワーク１８３０を（図示されるように）含む。これは、多数のクライアントが各種タイプのサーバと共に与えられる全グリッドネットワークを簡素化する。クライアントサイト１８１０，１８２０は、ローカルサイトである−それらは単一物理的なロケーションを表さない。

クライアントサイト１８１０は、パブリッククライアントである−他のクライアントによって比較的簡単にアクセスされ得るために指定されるよう−ファイアウォールがない。クライアントサイト１８１０は、ネットワーク１８３０に接続される、クライアント１８４０及びルータ１８５０を含む。他方、クライアントサイト１８２０は、プライベートクライアントである−それは、認証されない又は引き起こされないアクセスを阻害するよう差しはさむファイアウォールを有する。クライアントサイト１８２０は、全てがネットワーク１８３０に接続される、クライアント１８６０、ファイアウォール１８７０及びルータ１８８０を含む。ファイアウォール１８７０は、クライアント１８６０への認証されないアクセスを妨害する。

認証されない又は引き起こされないアクセスの妨害は、先に出て行った要求に応答して入ってくる全ての要求を妨害することを含む。このように、もし、クライアント１８４０がクライアント１８６０からファイルセグメントを要求し、クライアント１８６０から先に出て行った要求がファイアウォール１８７０を通るパスが確立されたならば、ファイアウォール１８７０は、クライアント１８４０からの通信を妨害する。これがマルウェアに逆らって防衛されることの有利性を提供する一方、それは勧誘しない通信を開始する。潜在的に望ましいものは、ピアツーピアや類似する構造のフォームにおける、クライアント１８４０，１８６０間の通信チャンネルである。

クライアント１８４０は、ネットワーク１８３０を通じてメディアファイルを最初に要求する。図１９は、メディアファイルを要求するプロセスの一実施形態の図解を提供する。プロセス１９００は、ファイルを要求すること、セグメントを受信すること、アップデートされた要求を送信すること、そして、プライベートクライアントから要求を受信することを含む。

モジュール１９１０で、プロセス１９００は、ファイルのための要求を備えて開始する。各種のピアへの要求送信を備えて、セグメントはモジュール１９２０に到達する−要求者はファイルの部分を受信することを始める。受信される部分に基づき、要求者は、モジュール１９３０でファイルの部分を損なうために、修正された要求やアップデートされた要求を送信し、要求されてきたことについてサーバをアップデートする。さらには、要求者は、モジュール１９４０でプライベートクライアントからの通信を開始するために要求を受信する。これら要求は、プライベートクライアントが、要求者がファイルを必要とし且つプライベートクライアントのファイアウォールを通じて通信を招くことに気付いたことを示す。

パブリッククライアントがファイルを要求する一方、プライベートクライアントは、パブリッククライアントから戻るファイルを要求するパスを提供すべく、順番にパブリッククライアントとの通信を要求する。図２０Ａは、メディアファイルの要求を手伝うプロセスの一実施形態の図解を提供する。プロセス２０００は、サーバでの状態をアップデートすること、指示を受信すること、パブリッククライアントと接触すること、要求を受信すること、そして、セグメントを送信することを含む。

プロセス２０００は、モジュール２０１０で状態アップデートを開始する。プライベートクライアントは、サーバに状態を通信し、セグメントを供給するために利用可能であることを指示する。おそらく、サーバは、プライベートクライアントが有するセグメントが何であるかについての情報にアクセスし、プライベートクライアントがセグメントを供給すべきかを決定することができる。この情報に基づき、プライベートクライアントは、モジュール２０２０でセグメントを供給することを申し出るために接触する他のクライアントが何であるかについてサーバから指示を受信する。

これらの指示を備え、プライベートクライアントは、パブリッククライアントによって要求されるファイルに関する通信を要求する、といったようなことによって、モジュール２０３０でパブリッククライアントと通信を開始する。モジュール２０３０の通信に応答して、プライベートクライアントは、指定されたファイルのセグメントのためのパブリッククライアントからの要求をモジュール２０４０で受信する。モジュール２０５０で、プライベートクライアントは、パブリッククライアントにセグメントを送信し、プロセスは、できる限り適切に繰り返される。このプロセスが、セグメントの通信が単向性方法で起こることを提案することに気付きなさい。しかしながら、パブリッククライアントからプライベートクライアントへのセグメントの返送もまた起こる。これは、例えば、同じファイルのセグメントや両方向におけるムービーを含み、あるいは、一方向又は両方向における複数のファイルのセグメントを含む。本質的に、パブリッククライアントと初期に接触するプライベートクライアントを有するプロセスは、別な方法で通信が起こらない場所での通信を確立することをアシストする。

このアシストプロセスは、グリッドネットワーク機能を構成する有用な部分であり得る。グリッドネットワークにおいて、複数のクライアントは、セグメントを検索するシングルクライアントに従事し得る。このように、シングルクライアントは、１から１６あるいはそれ以上のどんなクライアントからもセグメントを受信する。しかしながら、多くのクライアントは、ファイアウォールの背後に位置される。このように、プライベートクライアントとして参照される、それらクライアントは、最上のパブリッククライアントにアクセスすることができ、従って、利用可能なグリッドリソースの重要な部分を切除する。

ファイアウォールの背後にいるクライアントシステム−プライベートクライアントと呼ばれる−は、セグメントを検索するリモートピアによって直接的に接触され得ない。もし、要求に先立って認証されないならば、ピアツーピア接続は拒絶される。従って、スーパーノードは、接続機会を探しているクライアントに広告されるピアのリストにおけるこれらクライアントをリストに載せない。スーパーノードによって与えられるノードリストは、一般的にパブリッククライアントノードのみを含む。しかしながら、これは、グリッドのトータルノードスペースのこのサブセット上に分ける発見可能なリソースのフルバーテンを置き、決して最適ではない構造となる。

これに対抗すべく、アシストプロトコルは、それらリソースに興味を持つよう思われるアクセス可能なクライアントとの接続をプライベートクライアントが開始することを許可するように用いられる。接続がひとたび確立されれば、接続されたクライアントは、新たなプライベートクライアントを優先するパブリック接続の一つを開放するよう選択する。このようにして、"アシストする"ことを望むプライベートクライアントへの接続をオフロードすることは、ネットワークを横断してパブリックノード上のバーテンを引き下げるよう動作し、全ネットワークがより効果的に機能するのを潜在的に許可する。

図２０Ｂは、グリッドネットワークにおけるアシストプロセスの一実施形態を図解する。クライアント２０１５は、ファイアウォールの背後におり、その結果、外部ピア（プライベートクライアント）によって公然とアドレス可能ではない。クライアント２０１５は、他のジョブで現在は忙しくないということ、分けるのに有用なローカルストア内にリソースを有するということを決定するべきであり、それは、アシストサービスを提供する目的でスーパーノード２０４５と接触することを開始する。

アシスト告示（２０３５）は、プライベートクライアントが効果的に分けることができるそれらアセットの短いインベントリを含む。これは、パケットのフォームや、ネットワークを通じてスーパーノードへ伝送される類似のデータ構造のフォームにおいてである。しかる後、スーパーノード２０４５は、このメディア上のセグメントを積極的に交換するように知られるパブリックノードを確認し、レスポンス２０２５を介してプライベートクライアント２０１５にこれらクライアントのリストを返信する。

しかる後、プライベートクライアント２０１５は、接続要求２０５５を介して、リストにおける一つ以上のパブリックノードとの接触を開始する。受信するパブリッククライアント２０６５は、接続ピア２０１５がプライベートクライアントであることを認識し、このピア２０１５が目下必要とされるリソースを確かに申し出て接続を受け入れることを決定する。それで、現在接続されたパブリックピアを解放することを選択する。

現在接続されたパブリックピアを解放することの決定は、接続されたピアの全ての利用可能性と、セグメントを受信することを必要とする現在の緊急とに基づく。もし、新しく接続されたプライベートピアに優先してパブリックピアを解放することをクライアントが"余裕がある"というのであれば、そうするであろう。そのような場合において、プライベートピアの接続２０７５は、以前のパブリック接続２０８５を交換し、停止されるパブリック接続２０８５と通信する。受信するクライアント２０６５は、（現在接続されているピアが少ないとした場合であるように）現在接続されたパブリックノードを交換する余裕はないということを決定すべきであり、新しいプライベートクライアント２０１５との接続２０７５は、現在接続されたピアのリストに単に加えられる。

ファイルは、グリッドネットワーク上の異なるクライアントの能力と一致した各種の異なるフォーマットで提供される。図２１は、一実施形態において一組のファイルの図解を提供する。一組のファイルは、それぞれ異なるフォーマットを有し、グリッド内で使用される多くのファイルに共通な他の特徴を分ける。このように、各ファイルは、セグメント（実際のデータ）と共に、タイトル、フォーマット、ハッシュ及びセグメントのリストを含む。

例えば、第１ファイル２１１０は、ウィンドウズメディアフォーマット（マイクロソフトから入手可能）におけるムービー"これは、脊椎穿刺"をエンコーディングするファイルである。このように、タイトルフィールド２１４０ａは、例えば、キャラクタストリングにおけるように、あるいはタイトルのテーブル内のインデックスであるように、タイトル"これは、脊椎穿刺"をエンコードする。フォーマットフィールド２１５０ａは、例えば、ネーム（ウィンドウズメディア）、タイプ（ｗｍｖ）あるいはファイルフォーマットのテーブルへのインデックスといったいくつかの他の識別子を通じて、ウィンドウズメディア（あるいは特定のコーデック）のためのフォーマットをエンコードする。ハッシュフィールド２１６０ａは、例えば、ファイルの実際のデータのハッシュを含む。リストフィールド２１７０ａは、例えば、セグメントのパックされたビットワイズ表現によって理解されるセグメントのスカラー数といった、ファイルのセグメントのリストを含む。ファイルの図解されたヘッダを理解する、実際のセグメントは示されない。

第２ファイル２１２０は、ムービー、潜在的にファイル２１１０のような同じムービーを同様にエンコードする。しかしながら、第２ファイル２１２０は、例えば、アップルから入手可能なクイックタイムのためのムービーをエンコードする。このように、タイトル２１４０ｂは、タイトル２１４０ａに（潜在的に同様に）類似するタイトル"これは、脊椎穿刺"をエンコードする。フォーマット２１５０ｂは、クイックタイム、"ｍｏｖ"又はインデックスといったフォーマットをエンコードする。ハッシュ２１６０ｂは、エンコーディングの違いにより、ファイル２１１０のハッシュとは異なるように見える、ファイル２１２０のハッシュを含む。リスト２１７０ｂは、リスト２１７０ａに類似するが、ファイル２１２０のセグメントに対応するリストを提供する。同様に、実際のセグメント（図示しない）が次の通りである。

要求されるように、第３ファイル２１３０もエンコードされる。ファイル２１３０は、全く異なるファイル（例えば、"ケアベアアドベンチャー"）であり、また、それは、同じムービーの異なるフォーマットである。この記述は、例えば、リアルメディアプレーヤのためのフォーマットといった、第３フォーマットだと仮定する。タイトル２１４０ｃは、タイトル２１４０ａ，２１４０ｂと類似しているか同一である。フォーマット２１５０ｃは、例えば、リアルメディア、"ｒａｍ"又はインデックスをエンコーディングする。ハッシュ２１６０ｃは、実際のファイルのハッシュであり、ハッシュ２１６０ａ，２１６０ｂとは異なるようなものである。同様に、リスト２１７０ｃは、実際のセグメントによって続かれる、リスト２１７０ａ，２１７０ｂと類似するリストである。

異なるファイルフォーマットの必要を満足させるために利用可能な各種の異なるファイルを備え、それらファイルを提供するプロセスは、有用である。図２２は、一実施形態において望ましいフォーマットのファイルを提供するプロセスの図解を提供する。プロセス２２００は、ファイルを要求すること、利用可能なフォーマットリストを受信すること、フォーマットを選択すること、チケットを受信すること、セグメントを要求すること、そして、ファイルのセグメントを受信することを含む。このように、プロセス２２００は、望ましいフォーマットのファイルを要求し受信するためのクライアント側プロセスを提供する。

プロセス２２００は、クライアントがタイトル−特定のフォーマットを示さないムービーのための識別子−を要求するときにモジュール２２１０で開始する。当該タイトルのためのフォーマットリストは、モジュール２２２０でクライアントによって受信される。モジュール２２３０で、クライアントは、望ましい又は必要なフォーマットを選択する。フォーマットの選択は、例えば、クライアント及び（能力に基づくフォーマットを自動的に選択する）サーバ間の交渉に基づき、ユーザ選択に基づき、あるいは、以前になされた初期選択に基づく。

フォーマットの選択に応じて、ムービーのためのチケットは、モジュール２２４０で受信される。チケットは、例えば、図１２を参照して上述されたようなチケットである。このように、チケットは、例えば、ハッシュ値、チケットが正しいときの指示、セグメントのリスト、デジタル証明や証明書を含むよう要求される。チケットを備え、クライアントは、モジュール２２５０でファイルのセグメントを要求する。応じて、クライアントは、モジュール２２６０でセグメントを受信する。要求するものがいるので、プロセスは、ムービーが完全に受信されるまで、潜在的に動作するか同時に実行するモジュールを備えて、モジュール２２５０と２２６０との間でシフトする。

同様に有用なファイルを分けるシステム例を参照する。図２３は、ファイルが分けられるシステムの一実施形態の図解を提供する。システム２３００は、スーパーノード、シードサーバ、クライアントＡ〜Ｄ及び関連するリポジトリを含む。図解されるように、シングルムービーファイルは、分けられる−そして、例を通じて、クライアントＡ２３３０は、セグメントを探し且つムービーファイルをプレイするクライアントである。このように、クライアント２３３０は、認証と、スーパーノード２３１０からのジョブチケットを受信する。クライアント２３３０は、定期的であるが、相対的にまれな規則上のその状態をスーパーノード２３１０に（一つの実施形態において４５分おきといったように）報告もする。図解されるスナップショットにおいて、クライアント２３３０は、ローカルリポジトリ２３３５に保存された当該ムービーファイルの２０パーセントを有する。

このように、クライアントＡ２３３５は、クライアントＢ２３４０、クライアントＣ２３５０及びクライアントＤ２３６０からセグメントを要求する。クライアントＢ２３４０は、ローカルリポジトリ２３４５における当該ファイルの９パーセントを有する。クライアントＣ２３５０は、ローカルリポジトリ２３５５における当該ファイルの８１パーセントを有する。クライアントＤ２３６０は、ローカルリポジトリ２３６５における当該ファイルの２７パーセントを有する。セグメントの全ての通信、ジョブチケット又は他の通信が各種のモードでネットワーク２３７０に従って生じる。このように、ピアツーピア接続は、ネットワーク２３７０に従って確立され、また、ブロードキャストメッセージは、ネットワーク２３７０に従って発される。特に、クライアントＡ２３３０は、（例えば）クライアントＣ２３５０とのピアツーピア接続を確立し、セグメントを分けること又は少なくともセグメントの受信を開始する。

もし、セグメントがどんなアクセス可能なクライアントをも与えられないならば、セグメントは、そのローカルリポジトリ２３２５内の当該ファイルの１００パーセントを保持するシードサーバ２３２０から要求される。これは、望ましいネットワーク上のピア間を分けるように、好ましくは最後の報告である。この要求は、ネットワーク２３７０に従って渡される。

ムービーのプレイがしばしば望まれる一方、ユーザにとって重要ではないムービーがいかにプレイされることか。しかしながら、コンテンツの所有者は、ムービー又は他の長いコンテンツファイルが完全なファイルとして伝送されるよりもむしろストリームされることを好む。加えて、メモリ制限が全ファイルのストレージを困難にする。図２４は、一実施形態においてファイルストリームを受信するプロセスの一実施形態の図解を提供する。プロセス２４００は、ファイルを要求すること、対応するジョブチケットを受信すること、ファイルのセグメントを要求すること、バッファセグメントを受信すること、ファイルをプレイすること、バッファが低いセグメントであるかを決定すること、低いセグメント状態のための緊急を増やすこと、セグメントを受信することを継続すること、プレイが終了したかを決定すること、そして、セグメントを処分することを含む。

プロセス２４００は、モジュール２４１０でムービーファイルのためといったように、クライアントがファイルストリームの要求を提出するときに始まる。ジョブチケットは、例えば、モジュール２４２０で、図１２に関して記述されたように、受信される。ジョブチケットを備え、モジュール２４３０で、クライアント又はユーザは、グリッドネットワークを通じたファイルストリームのセグメントを要求する。始めに、バッファセグメントは、モジュール２４４０で受信される。これらバッファセグメントは、連続したファイルの始まりを取り決めるセグメントを含むが、必要にされるまで保持される後のセグメントを含みもする。

十分なバッファセグメントが与えられるとき、モジュール２４５０で、ムービーファイルは、プレイされる（あるいは、連続したファイルの異なる種類が処理される）。このように、所定位置に十分なイニシャルバッファを有して、ファイルは、通常のストリーミングを備えるようにプレイを開始する。しかしながら、ファイルのセグメントは、例えば、簡単に暗号化されないパケットよりもむしろ上述したファイルのセグメントに関して記述されるように、暗号化され、組織化される。プレイされるセグメントは、復号化のプロセスのジャストインタイムタイプに近いもので復号化される−セグメントは、プレイする時間が来たときにプレイのために復号化される。このように、暗号化されたセグメントは、復号化及び（ファイルフォーマットのための）通常のレンダリングのプロセスを通じて本質的に（ムービーのための）スクリーンのために提供される。

モジュール２４５５で、バッファに関してなされる決定は低く行われる−ファイルをすぐにプレイするのを継続するのに十分なセグメントはない。是ならば、緊急レベルは、モジュール２４６０で増す。緊急レベルは、単純なファイル要求又はファイルのシードといった、各種のセッティングで用いられる。緊急レベルは、セグメント又は他の目的の要求の一部として通信される。緊急レベルに関係なく、モジュール２４６５で、プロセスはセグメントの受信を続ける。望むものがいるので、プロセスの所定のストリーム特性は、モジュール２４７０で、ファイルのプレイを続ける。モジュール２４８０で、ファイルのエンドが到達したかに関する決定がなされる。否ならば、プロセスは、セグメント状態を決定するためにモジュール２４５５に戻り、モジュール２４６５，２４７０を続ける。もし、ファイルのエンドが到達したならば、ファイルはストリームされたので、プロセスは、モジュール２４９０で終了する。提出されたセグメントが近い連続的な規則上で用いられた後に処分されることが特に図解はされない。このように、暗号化されたセグメントは残るが、暗号化されないセグメントは、当該セグメントを表示（あるいは別の使用）するために十分長く持続するのみである。

緊急は、一般的にセグメントを要求し且つ特にストリーミングするための強力なツールを提供する。図２５は、緊急の表現の一実施形態の図解を提供する。緊急レベルは、緊急レベル２５００のスペクトラム又は範囲に従っておく。図解されるように、低い緊急２５１０は、範囲２５００の一端を提供する。中間の緊急２５２０は、範囲２５００の中間部を提供する。高い緊急２５３０は、範囲２５００の他端を提供する。

一実施形態において、緊急レベルは、要求を受信するクライアントによってサービスする原因となるが、低い緊急は、プロセシングのノーマルコースでサービスされる要求に一般的に対応する。そのような一実施形態において、中間の緊急要求は、低い緊急要求に先立ってサービスされ、例えば、キューにおける気に入られたポジションで挿入される。さらには、中間の緊急要求は、例えば、追加的に特別なハンドリングを受信し且つグリッドネットワーク内で監視される範囲の高いエンド近傍を要求する。高い緊急要求は、独特で変わった態度を引き起こす。例えば、グリッドネットワークにおけるシードサービスは、例えば、バッファアンダーラン状態を回避すべく、高い緊急要求をサービスすることを始める。さらには、高い緊急レベルは、例えば、より高い緊急レベルでクライアントに案内されるアシストトランザクションをより多く引き起こすためにサービスを引き起こす。
緊急及びファイルのストリーミングは、例えば、グリッドネットワークの実施形態を参照して理解される。図２６は、グリッドネットワークの一実施形態の図解を提供する。ネットワーク２６００は、全ネットワーク、シードサーバ、スーパーノード、及びクライアントＡ，Ｂ，Ｃを含む。ネットワーク２６００は、各種のグリッドネットワークの代表であるが、そのようなネットワークの全詳細を提供しない。

全ネットワーク２６１０は、例えば、インターネットやイントラネットといったネットワークである。ネットワーク２６１０への接続は、グリッドネットワーク２６００のためのノードをコントロールする、スーパーノード２６２０である。ネットワーク２６１０への接続もまた、各種のファイルのセグメントを提供し、そして、ネットワーク２６００上のセグメントのためのリポジトリとして有効に供給するシードサーバ２６３０である。さらには、クライアントＡ２６４０、クライアントＢ２６６０及びクライアントＣ２６８０は、ネットワーク２６１０に接続される。クライアントＡ２６４０は、ローカルストレージ上のクライアントＡ２６４０によってアクセス可能なセグメントのローカルコピーである、セグメント２６５０に結果的に接続される。同様に、クライアントＢ２６６０は、ローカルストレージ上のクライアントＢ２６６０によってアクセス可能なセグメント２６７０に結果的に接続される。さらに、クライアントＣ２６８０は、クライアントＣ２６８０によってアクセス可能なローカルストレージに保存される、セグメント２６９０に結果的に接続される。

このように、クライアントＡ２６４０は、ストリーミング目的のためにファイルを要求する。ファイルのセグメントは、他のロケーション間、クライアントＢ２６６０及びクライアントＣ２６８０で置かれる。最初は、クライアントＡ２６４０は、低いレベルの緊急を備えるセグメントを要求し、クライアントＢ２６６０、クライアントＣ２６８０からセグメントの返信を受ける。クライアントＡ２６４０は，ファイルのプレイ中、セグメント上で低く動くべきであり、それは、その緊急レベルを増やし、セグメントを要求することを続ける。高い緊急レベルを備え、クライアントＢ２６６０及びクライアント２６８０は、クライアントＡ２６４０からの要求をより高く優先付ける。クライアントＡ２６４０は、潜在的なバッファアンダーラン問題を有し続けるべきであり、クライアントＡ２６４０は、その緊急レベルをさらに増やす。これは、シードサーバ２６３０がクライアントＡ２６４０に直接セグメントを供給する結果となる。さらには、スーパーノード２６２０は、クライアントＡ２６２０への潜在的なアクセスの試みを方向付け、応答するためにシードサーバ２６３０に潜在的に方向付けもし、例えば、プロセスが開始するときに利用可能なセグメントの全風景によって決まる。

グリッドネットワークがストリームされるかコピーされるファイルが用いられる一方、ファイルの暗号化は、どちらのシチュエーションにとっても重要である。図２７は、暗号化プロテクションの一実施形態の図解を提供する。トランスポート、セグメント、ローカル及びプレーヤ暗号化を含み、プロテクションの四つのレベルが利用可能である。暗号化スタック２７００は、各種のレベルや暗号化のレイヤ、所定のファイルのために用いられたいくつか又は全てを示す。

暗号化の各レイヤを順番に参照して、トランスポート暗号化２７１０は、一つのフォーム又は他のデジタル証明書又はデジタル署名を通じてといったようにして、セグメント又はパケットのトランスポートでの暗号化を表す。このように、どんなフォームにおいても、各セグメントは、ネットワークを通って送信されるときに暗号化される。セグメント暗号化２７２０は、例えば、図１４，１５に関して上述したような、ファイルにおける各種セグメントの暗号化を参照する。このように、セグメントは、全ファイルの部分として暗号化され得て、セグメントが全ファイルを用いないことを困難にする。

ローカル暗号化レイヤ２７３０は、ローカルリポジトリ内の暗号化を参照する。このように、セグメントは、図２８において参照されるように、ローカルリポジトリに保存され、リポジトリにおけるストレージは、どんな他の暗号化をも超える暗号化ステップを含む。プレーヤ暗号化レイヤ２７４０は、各種のメディアフォーマット又はプレーヤから利用可能な暗号化オプションを参照する。このように、メディアプレーヤは、例えば、フォーマットを復号化することができるプレーヤを備えて、あるフォーマットのいくつかのファイル又は全てのファイルを自動的に暗号化する。メディアプレーヤの確認なしで、そのようなファイルを復号化するのは困難である。メディアプレーヤによって実施される、ＤＲＭ又はデジタル権マネージャは、例えば、このレイヤを提供する。

セグメントは、暗号化されようが否であろうが、使用中、いくらかの場所にて保存されるべきでない。いくつかの判断で、クライアントのグリッドネットワークは、大きなストレージネットワークとして機能し、分配された方法でネットワークを介するパスにファイルを保存する。図２８は、グリッドネットワークの一実施形態においてクライアントの一実施形態の図解を提供する。各クライアント２８００は、実行可能部及びセグメントリポジトリ部を含むよう要求され、ローカルストレージを使用するよう要求される。実行可能部２８１０は、プロセッサやマシーンによって実行されるときにそのプロセスを実施し且つその機能を実行するクライアントに含まれるコードの実行可能な部分である。

セグメントリポジトリ２８２０は、ファイルのプレイに用いるためと、他のクライアントと交換するためのセグメントを保存するローカルストレージにおけるクライアントによって実施されるリポジトリである。一つの実施形態において、セグメントリポジトリ２８２０は、重要な方法でクライアント２８００によってのみアクセス可能であるような、暗号化されたデータストアである。このように、セグメントは、セグメントリポジトリ２８２８０に保存されるが、重要な方法で実行可能部２８１０によってのみ取り出される。セグメントリポジトリ２８２０に保存された最上のセグメントを備え、全リポジトリの暗号化のために、誰かがセグメントへの認証されないアクセスを得ることは困難である。さらには、セグメントリポジトリ２８２０は別として、ローカルストレージ２８３０に保存されるセグメントは少ない。これは、メモリキャッシングとして参照され、異なるメモリ（特別速いメモリを必要とはしない）にいくつかのセグメントを維持する。リポジトリの外部に少ないセグメントを維持することによって、これは、簡単なリポジトリのコピーが、全ファイルがコピーされることを意味しないことを意味する−ギャップが存在する。さらには、リポジトリと個々のセグメントの両方の暗号化のために、シチュエーションは、ピースの形状がはっきりせず、その結果、パズルピースが利用可能な決定が著しく変化するパズルと共通する。しかしながら、メモリキャッシングがシステムで実施されないことに気付きなさい。

実際のグリッドネットワークの実施形態を考慮することは、ネットワーク及びそのクライアントのいくつかの関連する姿をさらに図解する。図２９は、グリッドネットワークの他実施形態の図解を提供する。グリッドネットワーク２９００は、スーパーノードの収集で示され、サーバ及びクライアントにシードされる。ネットワーク２９９０は、各種のクライアント及びサーバを結び付けるインターネット又は他のネットワークといったネットワークである。

スーパーノード２９１０は、ネットワーク２９９０に接続されたネットワーク２９００内のスーパーノードである。スーパーノード２９１０は、グリッドネットワーク２９００のいくつかのオペレーションを監視し、グリッドネットワーク２９００の他の部分のいくつかのプロフィール情報を維持する。このように、スーパーノード２９１０は、グリッドネットワーク上の各種クライアントについてのプロフィール情報を維持し、グリッドネットワーク上のファイルについてのプロフィール情報についても維持する。クライアントのプロフィール情報は、クライアントが保存しているデータが何であるのか、クライアントがネットワーク２９９０に対して有する接続のタイプが何であるのか、クライアントがネットワーク上の（おおよそ）どこに置かれるのか、を指示する。ファイルに関連するプロフィール情報は、例えば、ファイルのセグメント、ファイルタイプ及びファイルのセグメントの数をノードが有することについての情報を含む。スーパーノード２９１０は、これらプロフィール及び他の管理データが保存されているローカルストレージ２９１３で図解される。ネットワーク２９９０への接続もまた、スーパーノード２９３０及びスーパーノード２９５０であり、それぞれが類似するサービスを提供する。

シードサーバ２９２０は、スーパーノードと共に、ネットワーク２９９０にも接続される。シードサーバ２９２０は、ローカルストレージ２９２３におけるファイルのセグメントを維持する。さらには、シードサーバ２９２０は、各クライアントにそれらセグメントを送信することによってファイルからのセグメントでネットワークをシードする。このシーディングは、ネットワークにおける分配方法でファイルのコピーを生成するために積極的にファイルセグメントを送信することによって取り扱われる。さらには、ファイルからのセグメントは、いくつかの出来事においてクライアントからの要求に対するシードサーバ応答性によって供給される。しかしながら、シードサーバによる供給は、セグメント及びクライアント間のセグメントの交換をやりとりするネットワークマネージャを有することの試みが原因で、気に入らないオプションである。ネットワーク２９９０への接続もまた、ローカルストレージ２９４３，２９６３を備えたシードサーバ２９４０，２９６０である。

ネットワーク２９９０へのさらなる接続は、クライアント２９１５，２９２５，２９６５，２９７５である。クライアントＡ（２９２５）は、ローカルストレージ２９２８を有するよう図解され、クライアントＢ（２９１５）は、ローカルストレージ２９１８を有し、クライアントＣ（２９６５）は、ローカルストレージ２９６８を有し、クライアントＤ（２９７５）は、ローカルストレージ２９７８を有する。各クライアントは、ローカルストレージに保存される多くのファイルからいくつかのセグメントを有するよう要求される。一つのクライアントがファイルのセグメントを探しているとき、スーパーノードは、関連したセグメントを保存するクライアントのリストを提供し、クライアントは、そのようなセグメントを要求し得る。

ネットワークトポロジが図解され、クライアントは、セグメントのピアツーピア伝送に従事する。ネットワークを監視するため、スーパーノード２９１０は、クライアント２９１５，２９２５，２９６５，２９７５から定期的なアップデートを要求する。これは、各種クライアントの定期的なピンギングを要求することなしにネットワーク状態を維持することを許容する。加えて、サーバ２９２０といったシードサーバは、ピアツーピア方法にてネットワークをシードする。同様に、シードサーバ２９２０は、必要ならば、クライアントからのセグメントの緊急要求を提供する。さらに、要求のサービスは、公知のサービスを用いて公知の方法でなされた最も近いノードの決定に基づき、それによって、ネットワークがあまりに混雑になるのを回避する。このように、スーパーノードは、クライアントがセグメントを有するリストのみでなく、各クライアントがどのようにして特定のクライアントに基づくかの指示もまた、クライアントに提供する。もし、クライアントＡ（２９２５）がネットワーク上でクライアントＢ（２９１５）に接近し、クライアントＣ（２９６５）及びクライアントＤ（２９７５）から離れるならば、クライアントＢ（２９１５）に対する要求は、好まれる。もし、クライアントＡ（２９１５）がネットワーク上でシードサーバ２９２０に接近し、シードサーバ２９６０から離れるならば、クライアントＡは、例えば、シードサーバ２９６０よりもむしろシードサーバ２９２０によってシードされる。

シードサーバは、どんなところでも潜在的に提供され得る。シードサーバは、それが局所的にネットワークに接近する限り（ネットワークホップで測定されるように）、マシーンに物理的に接近する必要が無い。このように、シードサーバは、多くのクライアントへの接近を達成するために有利的に置かれ得る。さらに、最も重要なネットワークは、ネットワーク（ネットワーク上の一つのロケーションから同じネットワーク上の他のロケーションに）内のバンド帯は比較的安いが、（他のネットワークのロケーションへの又は該ロケーションからの接続を許可する）ネットワークの外部のバンド帯は高価な方式で動作する。この結果、ネットワークインターチェンジが重要なネットワーク間でいかに取り扱われ且ついかに値付けされるかの結果となる。

このように、多くの異なるネットワークにシードサーバを提供することが有利になり得る。これは、同じ所定のネットワーク上でクライアントから要求をサービスするために所定のネットワーク上にシードサーバを許す。さらに、各ネットワーク上に多くのシードサーバを備え、負荷平衡及び失敗許容は、各ネットワークのシードサーバ内で実施され得る。このように、グリッドネットワークオペレータは、各種のネットワーク上にシードサーバを置き、グリッドネットワークバンド帯が各種ネットワークへの主とした又は独占的なローカルであることをネットワークオペレータに通知する。これは、グリッドネットワークオペレータ及び潜在的なネットワークオペレータを保存するコストを潜在的に許す。面白いことに、いくつかの物理的なロケーションは、例えば、ネットワークがサンホセ、カリフォルニア、シアトル、ワシントンに集中するといった、小さい物理的な空間内で多くの異なるネットワーク上にサーバの設置を許す。

グリッドネットワークをシードすることは、ファイルが最初に分けられたときに優秀な結果を提供し得る。例えば、グリッドネットワークに解放するムービーは、シードすることなく、ファイルセグメントへのアクセスを可能とするシードサーバのみを備え、ムービーの要求における潜在的な迅速のスパイクを含む。図３０は、グリッドネットワークをシードする方法の一実施形態の図解を提供する。要求されたスパイク（ファイルを視聴するための最初の認証といったもの）に先んじてファイルのコピーを備えるネットワークをシードする。プロセス３０００は、ファイルを受信すること、分配を予測すること、選択されたシードサーバにファイルを広げること、選択されたクライアントにファイルを広げること、そして、ネットワーク内に関連するプロフィールをアップデートすることを含む。

ファイルがモジュール３０１０で受信されるとき、ファイルは、解放されるよう要求されるか、その後まもなくの解放が認証される。しかしながら、モジュール３０２０で、ファイルの分配についての予測がなされる。この予測は、いかに分配が頻繁に起こるかのテンプレートに基づく（例えば、サイエンスフィクションムービーは、一つの公知の方法で、他の公知の方法で歴史的なドキュメンタリを分配する）。代わりに、この予測は、メディア所有者が生じることを望む（、そして、支払う意思がある）ものに基づく。このように、予測は、ファイルがシーディングのため又は事前解放目的のために広められるべきであるところの指示を含む。

モジュール３０３０で、ファイルはサーバをシードするためにシードされ、それは、モジュール３０２０の予測された分配との関係で確認されるサーバにコピーされる。これは、地理的な（実際又は論理的な）ロケーション、サーバのバンド帯、及び他の考慮に基づく。同様に、モジュール３０４０で、ファイルは、選択されたクライアントの全て又は一部で広められる。これは、例えば、ネットワーク内のロケーションに同様に基づく。さらには、これは、関連するムービーを視聴する見込み、バンド帯及び接続プロパティ、シードクライアントとして動作する意欲、現在保存されているファイルの混合、そして、他の考慮といった、クライアントの観察された活動に基づく。シードサーバ及びクライアントの両方でシードされるファイルを備え、ネットワーク内のプロフィール（スーパーノードといったもの）がアップデートされる。これは、シーディングが完全であるように観察される後に起こるファイルの実際の解放又は認証を許す。そのようなプロフィールをアップデートすることのために、シーディングは、スーパーノードでプロフィールを単に検討することによって監視され、例えば、各クライアントの状態をピンギングすることなしに、（連続的なプロフィールのアップデートのために）比較的新しいシーディングプロセスのスナップショットを許す。

さらにシーディングを理解するため、ネットワークの他実施形態が援用される。図３１は、シードされたグリッドネットワークの一実施形態を提供する。システム３１００は、クライアント、シードサーバ、及び二つの異なるムービーを備えてシードされるスーパーノードのネットワークである。例えば、この実施形態において、"これは、脊椎穿刺"のコピー及び"バーニーズビッグアドベンチャー"のコピーを備えてシードされる。

ネットワーク３１１０は、インターネットといったネットワークである。ネットワーク３１１０への接続は、機能の監視及び管理を提供する、スーパーノード３１２０である。ネットワーク３１１０への接続は、シードサーバ３１３０、及びその関連するリポジトリ３１３５である。図解されるように、シードサーバ３１３０は、そのリポジトリ３１３５内に各ムービーのコピー（それぞれの１００パーセントのセグメント）を有する。

クライアント１（３１４０）は、ネットワーク３１１０に接続され、リポジトリ３１４５を有する。リポジトリ３１４５は、第１ムービーの６パーセントのセグメントと、第２のムービーの２０パーセントのセグメントとを有する。クライアント２（３１５０）は、ネットワーク３１１０に接続されるようであり、第１ムービーの３０パーセント及び第２ムービーの１０パーセントを備えるリポジトリ３１５５を有する。クライアント３（３１６０）は、ネットワーク３１１０に接続され、第１ムービーの７０パーセント及び第２ムービーの１５パーセントを備えるリポジトリ３１６５を有する。最後のクライアント４（３１７０）は、リポジトリ３１７５を有し、ネットワーク３１１０に接続される。リポジトリ３１７５は、第１ムービーの９パーセント及び第２ムービーの４５パーセントを含む。

スーパーノード３１２０のリポジトリ３１２５は、セグメントが各クライアント（１〜４）であることについての情報を追跡する。一つの実施形態において、全てのクライアントは、かれらの暗号化されたセグメントデータストアのコンテンツ上の情報を含んで、かれらの状態を定期的に報告する。一つの実施形態において、これは、４５分ごとに起こるが、他のタイマ間隔が用いられる。各ムービーのパーセンテージが各クライアントに示される一方、与えられるセグメントは図示されない。各クライアントでのファイルのパーセンテージは、リポジトリ３１２５において各クライアントのために保存される。さらには、図解された目的のために、各ムービーファイルは、各クライアントリポジトリ（３１４５，３１５５，３１６５，３１７５）において同じオーダで保存される、という前提である。これは、ランダムアクセスストレージが実施される（、そして、好ましいものとなる）ので、必要なケースではない。二つのファイルのセグメントの共有が起こるとき、クライアント３は、"これは、脊椎穿刺"のための優秀なソースであって、お粗末な"バーニーズビッグアドベンチャー"ソースではない。この正反対は、クライアント４で真実となる。

"これは、脊椎穿刺"のいくつかの重複が各ムービーのパーセンテージに基づいて必要なため、"バーニーズビッグアドベンチャー"のフルコピーが現在必要ではない、と気付きなさい。しかしながら、セグメントは、ネットワークの選択及び使用をシードすることを当てにしつつ、ネットワークを介して重複され、又はシードサーバで現れるのみである。図はネットワークのスナップショットの図解を提供し、セグメント伝送は、そのようなスナップショット後に起こり、実質的なスナップショット後に異なるネットワーク状態という結果になる。

図３２は、グリッドネットワークを実施するために用いられるネットワークの一実施形態の図解を提供する。図３３は、グリッドネットワークで用いられるマシーンの一実施形態の図解を提供する。図３２，３３についての以下の記述は、デバイスハードウェアの概要と、今まで及び後に記述した本発明の方法を実行するのにふさわしい他のオペレーティングコンポーネントの概要を提供しようとするものである。同様に、ハードウェア及び他のオペレーティングコンポーネントは、上記のデバイスの一部としてふさわしい。本発明は、パーソナルコンピュータ、マルチプロセッサシステム、マイクロプロセッサベース又はプログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータといった、他のシステム構造を備えて実践され得る。本発明は、通信ネットワークを介して連結されるリモートプロセシングデバイスによってタスクが実行される分配コンピューティング環境において実践され得る。

図３２は、セルラーネットワーク及び関連するセルラーデバイスと共に、インターネットといったネットワーク３２０５を通じて互いに接続される数個のコンピュータシステムを示す。ここで用いられる"インターネット"なる用語は、ＴＣＰ／ＩＰプロトコルや、ワールドワイドウェブ（ｗｅｂ）を構成するハイパーテキストメークアップ言語（ＨＴＭＬ）ドキュメントのためのハイパーテキストトランスファープロトコル（ＨＴＴＰ）といった可能な他のプロトコルのような、所定のプロトコルを用いるネットワークを参照する。インターネットとプロトコルの物理的な接続及び通信手順は、当業者によく知られている。

インターネット３２０５へのアクセスは、ＩＳＰｓ３２１０，３２１５といった、サービスプロバイダ（ＩＳＰ）によって一般的に提供される。クライアントコンピュータシステム３２３０，３２５０，３２６０といった、クライアントシステム上のユーザは、ＩＳＰｓ３２１０，３２１５といった、インターネットサービスプロバイダを通じてインターネットへのアクセスを得る。インターネットへのアクセスは、クライアントコンピュータシステムのユーザが、情報、Ｅメールの送受信、そして、ＨＴＭＬフォーマットで準備されたドキュメントといった、ドキュメントの閲覧を交換することを許す。これらドキュメントは、インターネット"上"であるとみなされるウェブサーバ３２２０といった、ウェブサーバによってしばしば提供される。コンピュータシステムは、ＩＳＰでもあるシステムなしにインターネットにセットアップされ且つ接続され得るが、これらウェブサーバは、ＩＳＰ３２１０といった、ＩＳＰｓによってしばしば提供される。

ウェブサーバ３２２０は、サーバコンピュータシステムとして動作する少なくとも一つのコンピュータシステムであり、ワールドワイドウェブのプロトコルで動作するよう構成され、インターネットに接続される。追加的に、ウェブサーバ３２２０は、クライアントシステムのためのインターネットへのアクセスを提供するＩＳＰの一部であり得る。ウェブサーバ３２２０は、メディアデータベースのフォームとみなされ得るウェブコンテンツ３２９５に接続されるサーバコンピュータシステム３２２５に接続されて示される。二つのコンピュータシステム３２２０，３２２５が図３２に示される一方、ウェブサーバシステム３２２０及びサーバコンピュータシステム３２２５は、さらに以下に記述されるサーバコンピュータシステム３２２５によって提供されるウェブサーバ機能性及びサーバ機能性を提供する異なるソフトウェアコンポーネントを有する一つのコンピュータシステムであり得る。

セルラーネットワークインターフェイス３２４３は、セルラーネットワーク及び対応する一方側のセルラーデバイス３２４４，３２４６，３２４８、他方側のネットワーク３２０５間のインターフェイスを提供する。セルラー電話、ツーウェイ携帯電話、パーソナルデジタルアシスタント又は他の類似するデバイスを含むパーソナルデバイスである、セルラーデバイス３２４４，３２４６，３２４８は、ネットワーク３２０５と接続し、例えば、イーメール、コンテンツ又はＨＴＴＰフォーマットデータといった情報を交換する。セルラーネットワークインターフェイス３２４３は、モデムインターフェイス３２４５を介してネットワーク３２０５と通信するコンピュータ３２４０に接続される。コンピュータ３２４０は、パーソナルコンピュータ、サーバコンピュータといったものであり、ゲートウェイとして働く。このように、コンピュータ３２４０は、例えば、クライアントコンピュータ３２５０，３２６０と類似しており、あるいはゲートウェイコンピュータ３２７５と類似している。ソフトウェア又はコンテンツは、インターフェイス３２４３、コンピュータ３２４０及びモデム３２４５によって提供される接続を介してアップロード又はダウンロードされる。

クライアントコンピュータシステム３２３０，３２５０，３２６０はそれぞれ、適切なウェブブローシングソフトウェアを備え、ウェブサーバ３２２０によって提供されるＨＴＭＬページを見ることができる。ＩＳＰ３２１０は、クライアントコンピュータシステム３２３０の一部とみなされ得るモデムインターフェイス３２３５を介してクライアントコンピュータシステム３２３０へのインターネット接続性を提供する。クライアントコンピュータシステムは、パーソナルコンピュータシステム、ネットワークコンピュータ、ウェブｔｖシステム、又は他のそのようなコンピュータシステムであり得る。

同様に、図３２で示されるが、ＩＳＰ３２１５は、クライアントシステム３２５０，３２６０のためのインターネット接続性を提供し、接続は、より直接接続されたコンピュータシステムと同じではない。クライアントコンピュータシステム３２５０，３２６０は、ゲートウェイコンピュータ３２７５を介して接続されるＬＡＮの一部である。図３２が"モデム"と一般的なインターフェイス３２３５，３２４５を示す一方、これらインターフェイスのそれぞれは、アナログモデム、ＩＳＤＮモデム、ケーブルモデム、サテライトトランザクションインターフェイス（例えば、"ダイレクトＰＣ"）、又は、他のコンピュータシステムにコンピュータシステムを繋げるための他のインターフェイスであり得る。

クライアントコンピュータシステム３２５０，３２６０は、イーサネット又は他のネットワークインターフェイスであり得るネットワークインターフェイス３２５５，３２６５を通じて、ＬＡＮ３２７０に接続される。ＬＡＮ３２７０は、ファイアウォールと、ローカルエリアネットワークのための他のインターネット関連サービスとを提供し得るゲートウェイコンピュータシステム３２７５にも接続される。このゲートウェイコンピュータシステム３２７５は、クライアントコンピュータシステム３２５０，３２６０へのインターネット接続性を提供するためにＩＳＰ３２１５に接続される。ゲートウェイコンピュータシステム３２７５は、従来型のサーバコンピュータシステムであり得る。また、ウェブサーバシステム３２２０は、従来型のサーバコンピュータシステムであり得る。

代わりに、サーバコンピュータシステム３２８０は、ゲートウェイシステム３２７５を介してインターネットに接続する必要なしに、ファイル３２９０及びクライアント３２５０，３２６０への他のサービスを提供するためにネットワークインターフェイス３２８５を介してＬＡＮ３２７０に直接的に接続され得る。図３３は、セルラー電話（３２４４，３２４６又は３２４８）又は類似するパーソナルデバイスとして用いられ得るパーソナルデバイスの一つの例を示す。そのようなデバイスは、電話通信、ツーウェイ携帯電話通信、パーソナル組織化、又は類似する機能といった、実施に基づく多くの機能を実行するよう使用され得る。図３３のシステム３３００は、パーソナルコンピュータ、ネットワークコンピュータ、又は他の類似するシステムといった他のデバイスを実施するためにも用いられる。コンピュータシステム３３００は、通信インターフェイス３３２０を介して外部システムに調和する。セルラー電話において、このインターフェイスは、セルラーネットワークと通信するラジオインターフェイスであり、迅速に利用可能なパーソナルコンピュータを用いるためのケーブルインターフェイスのいくつかのフォームを含みもする。ツーウェイ携帯電話において、通信インターフェイス３３２０は、データトランザクションネットワークと通信するラジオインターフェイスであるが、同様にケーブル又はクレードルインターフェイスを含む。パーソナルデジタルアシスタントにおいて、通信インターフェイス３３２０は、クレードル又はケーブルインターフェイスを一般的に含み、例えば、ブルートゥースや８０２．１１インターフェイス、セルラーラジオインターフェイスといったラジオインターフェイスのいくつかのフォームも含む。

コンピュータシステム３３００は、インテルペンティアムマイクロプロセッサやモトローラパワーＰＣマイクロプロセッサ、テキサスインスツルメンツデジタルシグナルプロセッサ、又はツータイプのいくつかの組み合わせといった従来型のマイクロプロセッサであり得る、プロセッサ３３１０を含む。メモリ３３４０は、バス３３７０によってプロセッサ３３１０に接続される。メモリ３３４０は、ダイナミックランダムアクセスメモリ（ｄｒａｍ）であり得て、スタティックラム（ｓｒａｍ）や、ＦＬＡＳＨ ＥＥＰＲＯＭも含み得る。バス３３７０は、プロセッサ３３１０を、メモリ３３４０、ボラタイルストレージ３３５０、ディスプレイコントローラ３３３０、そして、インプット／アウトプット８Ｉ／Ｏ）コントローラ３３６０に接続する。ディスプレイコントローラ３３３０及びＩ／Ｏコントローラ３３６０は、統合され、ディスプレイもまた、入力を提供するということに気付きなさい。

ディスプレイコントローラ３３３０は、リキッドクリスタルディスプレイ（ＬＣＤ）や同種のフラットパネルで、スモールフォームファクターディスプレイであるディスプレイデバイス３３３５上の表示を従来方法でコントロールする。Ｉ／Ｏデバイス３３５５は、キーボードやスタイラス及びタッチスクリーンを含み得るし、ディスクドライバ、プリンタ、スキャナ、そして、マウスや他のポインティングデバイスを含む他の入出力デバイスを時として含ませようとする。ディスプレイコントローラ３３３０及びＩ／Ｏコントローラ３３６０は、従来からよく知られた技術で実施され得る。デジタルイメージ入力デバイス３３６５は、デジタルカメラからのイメージがデバイス３３００に入力されるのを許容するためのＩ／Ｏコントローラ３３６０に接続されるデジタルカメラであり得る。

非ボラタイルストレージ３３５０は、しばしば、フラッシュメモリ、リードオンリーメモリ、又は二つのいくつかの結合である。磁気ハードディスク、光学ディスク、又は、大量のデータのための他のストレージフォームは、いくつかの実施形態において用いられるが、そのようなデバイスのフォームファクタは、デバイス３３００の不変コンポーネントとして組み込まれるのを一般的に除外する。むしろ、他のコンピュータ上の大量ストレージデバイスは、デバイス３３００のより限定的なストレージと関連して一般的に用いられる。ダイレクトメモリアクセスプロセスによって、このデータのいくつかは、しばしば、デバイス３３００においてソフトウェアを実行する期間中にメモリ３３４０に書き込まれる。当業者は、用語"マシーン読み取り可能な媒体"や"コンピュータ読み取り可能な媒体"が、プロセッサ３３１０によってアクセス可能であり且つデータ信号をエンコードするキャリアウェーブを包含もするどんなタイプのストレージデバイスをも含むということをすぐに認識するであろう。

デバイス３３００は、異なるアーキテクチャを有するたくさん可能なデバイスの一つの例である。例えば、インテルマイクロプロセッサに基づくデバイスは、一つが周辺機器のための入力／出力（Ｉ／Ｏ）バスであり且つ一つがプロセッサ３３１０及びメモリ３３４０（しばしばメモリバスとして参照される）を直接的に接続し得る多数のバスをしばしば有する。バスは、バスプロトコルが異なることによるどんな必要なトランザクションをも実行するブリッジコンポーネントを介して互いに接続される。

加えて、デバイス３３００は、オペレーティングシステムソフトウェアの一部であるディスクオペレーティングシステムといった、ファイル管理システムを含むオペレーティングシステムソフトウェアによってコントロールされる。ファイル管理システムソフトウェアと関連するオペレーティングシステムソフトウェアの一つの例は、レッドモンド、ワシントンのマイクロソフト社から入手できるウィンドウズＣＥ（登録商標）及びウィンドウズ（登録商標）として知られるオペレーティングシステム、及びそれらに関連するファイル管理システムのファミリである。関連するファイル管理システムソフトウェアを備えるオペレーティングシステムソフトウェアの他の例は、パルム（登録商標）オペレーティングシステム及びそれに関連するファイル管理システムである。ファイル管理システムは、一般的に非ボラタイルストレージ３３５０に保存され、非ボラタイルストレージ３３５０上の保存されたファイルを含みつつ、データを入出力し且つデータをメモリに保存するオペレーティングシステムによって要求される各種の動きをプロセッサ３３１０が実行するようにする。他のオペレーティングシステムは、デバイスのメーカによって提供され、それらオペレーティングシステムは、類似するデバイス上の類似するオペレーティングシステムの一部でないデバイス仕様の特徴を一般的に有する。同様に、ウィンＣＥ（登録商標）やパルム（登録商標）のオペレーティングシステムは、特定デバイス能力のために特定デバイスに適合される。

デバイス３３００は、いくつかの実施形態においてシングルチップ又は一組のチップに統合され、パーソナルデバイスとして用いるための小さいフォームファクタに一般的に適合される。このように、プロセッサ、バス、オンボードメモリ、ディスプレイコントローラ及びＩ／Ｏコントローラが、全てシングルチップに統合されるのはまれではない。あるいは、機能は、ポイントツーポイント内部接続で数個のチップに分割され、実際のデバイス又は関連する概要のどちらかの検査からバスが論理的に明白であるが物理的に明らかではないようにする。

詳細な記述のいくつかの部分は、アルゴリズム及びコンピュータメモリ内のデータビット上のオペレーションのアルゴリズム及びシンボリックな表示という点において与えられる。これらアルゴリズム的な記述及び表現は、データ処理の業界における当業者によって、かれらのワークの実質を他の当業者に最も有効に運ぶために用いられる手段である。アルゴリズムは、ここにあり、一般的に、望ましい結果に導くオペレーションの首尾一貫したシーケンスとなるように思われる。オペレーションは、物理量の物理的なマニピュレーションを要求するものである。通常、必要ではないが、これら量は、保存、伝送、結合、比較及び別の操作が可能である電気又は磁気信号のフォームを取る。それは、ビット、値、エレメント、シンボル、キャラクタ、ターム、ナンバーといったこれら信号を参照するために、主として共有の理由のため、原始的に同時に便利であることを証明する。

しかしながら、これら全て及び類似するタームが、適切な物理量と関連付けられるようになり、これら量に適用される便利なラベルはめったに無い、ということを心に留めておくべきである。続くディスカッションから明らかなように別の方法ではっきりと述べられないならば、 "処理"、"演算"、"計算"、"決定"、"表示"といった用語を記述の間中で利用することの議論が理解される。

いくつかの実施形態において、本発明は、ここでオペレーションを実行する装置に関する。この装置は、要求された目的のために特に構成され、又は、コンピュータに保存されるコンピュータプログラムによって選択的に動作され又は変更される一般的な目的のコンピュータを含む。そのようなコンピュータプログラムは、フロッピーディスク、光学ディスク、ＣＤ−ＲＯＭ、磁気光学ディスク、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、又は電気的命令を保存するために適したどんなタイプのメディアをも含むどんなタイプのディスク（限定はされない）といった、コンピュータ読み取り可能なストレージ媒体に保存され、それぞれコンピュータシステムバスに接続される。

ここで提供されるアルゴリズム及びディスプレイは、本質的にどんな特定のコンピュータや他の装置とも関連しない。各種の一般的な目的のシステムは、ここでの教示に基づいてプログラムと共に用いられ、あるいは、要求された方法のステップを実行するためにより専門化された装置を構成するのが便利であるのを証明する。各種のシステムの要求される構造は、以下の記述によって明らかとなる。加えて、本発明は、どんな特定のプログラミング言語をも参照して記述されず、各種の実施形態が各種のプログラミング言語を用いて実施される。

ネットワークのコンポーネント及び関連するマシーンの各種異なる実施が用いられ得る一方、一例となる実施が有用であるとわかる。図３４は、ネットワークの一実施形態におけるクライアントの一実施形態の図解を提供する。システム３４００は、ユーザＩ／Ｏ、ビデオ及びオーディオコントロール、ローカルストレージ、ネットワークインターフェイスと共に、クライアント３４０５を含む。

クライアント３４０５は、コントロールモジュール３４４０、ネットワークインターフェイス３４１０、ローカルストレージインターフェイス３４１５、レンダリングインターフェイス３４２０、暗号化エンジン３４２５、そして、ユーザインターフェイス３４３０を含む。ネットワークインターフェイス３４１０は、グリッドネットワークを接続するためにネットワークポート３４９０と動作する。ローカルストレージインターフェイス３４１５は、ローカルストレージ（リポジトリ）３４５０のデータを保存し、取り出す。

レンダリングインターフェイス３４２０は、表示され、（サウンドが）プレイされ、又は保存されるといった便利なフォーマットにファイルのセグメントを与える。レンダリングインターフェイス３４２０は、例えば、ディスプレイ３４６５、スピーカ３４７５を駆動するためにビデオコントロール３４６０及びオーディオコントロール３４７０と相互に作用する。さらには、レンダリングインターフェイス３４２０は、与えられたセグメントがローカルストレージインターフェイス３４１５を介して局所的に書き込まれるようにする。暗号化エンジン３４２５は、セグメント及び関連するデータを復号化（必要ならば、暗号化も）する。ユーザ識別子３４３０は、ユーザＩ／Ｏコントローラ３４８０と相互に作用する。ユーザＩ／Ｏコントローラ３４８０は、例えば、入力デバイス３４８５、ビデオ（３４６０）及びオーディオ（３４７０）コントローラと相互に作用する。コントロールモジュール３４４０は、クライアント３４０５の他のコンポーネントをコントロールする。

同様に、各種のサーバ実施が用いられ、一例の実施が役に立つ。図３５は、ネットワークの一実施形態におけるサーバの一実施形態の図解を提供する。サーバ３５００は、ネットワークインターフェイス、ネットワークコントロールモジュール、ストレージインターフェイス、暗号化エンジン、ユーザインターフェイス及びコントロールモジュールを含む。ネットワークインターフェイス３５１０は、グリッドネットワーク及びどんな潜在的なネットワークとも相互に作用する。ネットワークコントロールモジュール３５２０は、コントロール機能を提供し、グリッドネットワークのためのコントロール信号を提供する。そのようなコントロール信号及び機能は、例えば、ジョブチケットを発行し、悪意のある又は非機能的なクライアントへのアクセスを切断し、又は、他のクライアントをアシストするためにクライアントを方向付ける。

ストレージインターフェイス３５４０は、ローカルストレージ３５６０と相互に作用し、ネットワーク及びクライアントについての情報を保存し且つ取り出す。暗号化エンジン３５６０は、例えば、クライアントからのパケットの確認を確認するときといったように、データを暗号化及び復号化する。ユーザインターフェイス３５５０は、例えば、構造のスタティックス及びオーバーライドの点検を許すためといったように、サーバ３５００と相互に作用するユーザを許す。コントロールモジュール３５３０は、サーバ３５００の他のコンポーネントをコントロールし、そこでの通信を容易にする。

当業者は、システム及び方法の特定の例及び実施形態が図解のために記述され、各種の修正が本発明から逸脱しないようにして可能であることを理解できる。例えば、本発明の実施形態は、データベース、システム及びアプリケーションプログラムの多くの異なる適用される。さらには、一つの実施形態の特徴は、他の実施形態に組み込まれ、それらの特徴は、本文章内の一つの実施形態において共に記述されない。

本発明は、添付された図面の例によって図解される。図面は、限定的なものとしてではなく、むしろ図解用のものとして理解されるべきである。

グリッドネットワークの一実施形態の図を示す。 メディアヴォールトの一実施形態の図を示す。 コーデックの一実施形態の図を示す。 シンジケートフィードの一実施形態の図を示す。 ジオロケートスーパーノードの一実施形態の図を示す。 エンコーディングスタジオの一実施形態の図を示す。 メディアプレーヤの一実施形態の図を示す。 クライアントの一実施形態の図を示す。 スーパーノードプロトコルの一実施形態の図を示す。 グリッドネットワークからムービーファイルをプレイするためのプロセスの一実施形態の図を示す。 グリッドシステムの一実施形態の図を示す。 データファイルの要求に応じて用いられるパケットの一実施形態の図を示す。 ジョブチケットの一実施形態の図を示す。 メディアファイルを暗号化するプロセスの一実施形態の図を示す。 暗号化されたメディアファイルを用いるプロセスの一実施形態の図を示す。 メディアファイルの一実施形態の図を示す。 メディアファイルのセグメントの一実施形態の図を示す。 メディアファイルのハッシュ値の一実施形態の図を示す。 グリッドネットワークの一実施形態の図を示す。 メディアファイルを要求するプロセスの一実施形態の図を示す。 メディアファイルの要求を援助するプロセスの一実施形態の図を示す。 プライベートクライアントがパブリッククライアントを援助するグリッドネットワークの一実施形態の図を示す。 一実施形態における一組のファイルの図を示す。 一実施形態における望ましいフォーマットのファイルを提供するプロセスの図を示す。 ファイルが分けられたシステムの一実施形態の図を示す。 一実施形態におけるファイルストリームを受信するプロセスの一実施形態の図を示す。 緊急表示の一実施形態の図を示す。 グリッドネットワークの一実施形態の図を示す。 暗号化保護の一実施形態の図を示す。 グリッドネットワークの一実施形態におけるクライアントの一実施形態の図を示す。 グリッドネットワークの一実施形態の図を示す。 グリッドネットワークをシードする方法の一実施形態の図を示す。 シードされたグリッドネットワークの一実施形態の図を示す。 グリッドネットワークを実施するために用いられるネットワークの一実施形態の図を示す。 グリッドネットワークにおいて用いられるマシーンの一実施形態の図を示す。 ネットワークの一実施形態におけるクライアントの一実施形態の図を示す。 ネットワークの一実施形態におけるサーバの一実施形態の図を示す。

Claims (22)

1. ネットワークに接続された確認機能を有する第１サーバノードと、
   同じくネットワークに接続されたコンプリートファイルのリポジトリを有する第２サーバノードと、
   ネットワークに接続されたファイルのローカルリポジトリを有する一組のクライアントノードであって、ネットワークを介してピアツーピア基準上のコンプリートファイルのセグメントをシェアするように構成されたクライアントノードと
   を含むシステム。
2. 一組のクライアントノードのうちの一つのクライアントノードは、そのクライアントノードが一組のクライアントノードのうちの他のクライアントノードから有効に取り出されていないセグメントを決定するときに、第２サーバノードのみからセグメントを要求する請求項１に記載のシステム。
3. コンプリートファイルは、デジタルムービーのデータをエンコードする請求項２に記載のシステム。
4. コンプリートファイルは、デジタル電子書籍のデータをエンコードする請求項２に記載のシステム。
5. コンプリートファイルは、データベースのデータをエンコードする請求項２に記載のシステム。
6. 一組のクライアントノードのうちの複数のクライアントノードは、ネットワークを横断してセグメントを交換するのに先立って第１サーバノードから確認を要求し且つ受信する請求項２に記載のシステム。
7. ネットワークインターフェイス、
   リポジトリインターフェイス、
   レンダリングインターフェイス、
   暗号化エンジン、
   ユーザインターフェイス
   を含むローカルクライアントと、
   コントロールモジュールと、
   ローカルリポジトリと
   を含み、
   ローカルクライアントは、ファイルアクセスの確認を受信するためにネットワークインターフェイスを介してネットワーク上でサーバと相互に作用するようになっており、
   且つ、確認されたピアツーピア接続を用い、他のシステム上の他のローカルクライアントから及び該ローカルクライアントに、そして、ローカルリポジトリから及び該ローカルリポジトリに、ファイルのセグメントを伝送するようになっている
   システム。
8. ローカルクライアントは、ディスプレイを介してユーザと相互に作用するのに有用なフォーマット内にセグメントを与えるようになっている請求項７に記載のシステム。
9. ローカルクライアントは、ローカルリポジトリからセグメントを暗号化するようになっている請求項７に記載のシステム。
10. ディスプレイをさらに含む請求項７に記載のシステム。
11. ディスプレイ及びローカルリポジトリに接続されたプロセッサをさらに含み、
    プロセッサは、ローカルクライアントを実行するようになっている請求項７に記載のシステム。
12. ローカルリポジトリは、ファイルセグメントの暗号化されたストアを含む請求項７に記載のシステム。
13. ファイルセグメントは、複数のメディアファイルからのセグメントである請求項１２に記載のシステム。
14. メディアファイルは、ムービーファイルである請求項１３に記載のシステム。
15. ビデオデータを表示する手段をさらに含む請求項７に記載のシステム。
16. ピアツーピア接続を介して第１クライアントからメディアファイルのセグメントを要求すること、
    要求において確認されたジョブチケットを提供すること、
    第１確認ジョブチケットが正しいまま残っている限り、ピアツーピア接続を介して第１クライアントからメディアファイルのセグメントを受信すること
    を含む方法。
17. ピアツーピア接続を介して第２確認ジョブチケットを備えた第２クライアントからのムービーファイルのセグメントの要求を受信することをさらに含む請求項１６に記載の方法。
18. サーバで第２確認ジョブチケットの真偽を確認することによってムービーファイルのセグメントの要求に応答すること、
    ピアツーピア接続を介して第２クライアントにセグメントを伝送することによってムービーファイルのセグメントの要求にさらに応答すること
    をさらに含む請求項１７に記載の方法。
19. ピアツーピア接続のための第３クライアントであって、ファイアウォールを介してネットワークに接続された第３クライアントから特定の要求を受信すること、
    第３クライアントからの特定の要求に応答し、ピアツーピア接続を確立すること、
    第３クライアントでセグメントを交換すること
    をさらに含む請求項１６に記載の方法。
20. ムービーファイルのセグメントを復号化すること、
    ユーザへのディスプレイのために復号化されたムービーファイルのセグメントをレンダリングすること
    をさらに含む請求項１６に記載の方法。
21. ムービーファイルのセグメントを復号化すること、
    ローカルリポジトリのローカルファイルにおける復号化されたムービーファイルのセグメントを保存すること
    ユーザへのディスプレイのために復号化されたローカルファイルのセグメントをレンダリングすること
    をさらに含む請求項１６に記載の方法。
22. 方法は、マシーン読み取り可能なメディアに組み込まれた一組の指示に組み込まれ、プロセッサによって実行される指示は、方法を実行するためにプロセッサを引き起こす請求項１６に記載の方法。

Images