JP2020061135A - 企業ネットワーク内の動的コンテンツ配信 - Google Patents

Abstract

【課題】企業環境における動的コンテンツ配信を促進するためのシステムを提供する。【解決手段】コンテンツ配信システムは、企業環境のトポグラフィ情報を判定する。該システムは、トポグラフィ情報に基づいて論理グループのセットを判定する。それぞれの論理グループは、コントローラによって管理される１つ以上のデバイス及び１つ以上のデバイス間の接続を提供するネットワークを含む。該システムはまた、第１の配信ツリーを介してコンテンツの配信計画を生成する。第１の配信ツリーのそれぞれのノードは、論理グループのセットの論理グループに対応する。コンテンツをホストする論理グループは、第１の配信ツリーのルートノードに対応する。次いで、該システムは、配信計画を含む通知メッセージを、論理グループのセットのそれぞれの論理グループに送信する。【選択図】図１Ａ

Description

本開示は、一般に、コンテンツ配信の分野に関連する。より具体的には、本開示は、企業ネットワーク内にコンテンツを効率的に配信するためのシステム及び方法に関する。

インターネット及び電子商取引の急増により、膨大な量のデジタルコンテンツが作成され続けている。企業又は大企業は、複数のサイトにわたって配信されたクラウドストレージデバイス及びプリンタなどの被管理デバイスのネットワークを含み得る。そのようなデバイスのネットワークでは、デバイスマネージャは、そのサイトのうちの１つのローカルネットワーク内のデバイスを管理（例えば、構成及び制御）してもよい。このデバイスマネージャは、ファームウェア更新、ポリシーファイル配信、又はデータ転送に関与することができる。これらの動作は、通常、企業ネットワーク内の多数の被管理デバイスへの大きなファイル転送を伴う。

従来のデバイスマネージャは、通常、被管理デバイスのインターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、ＩＰ）アドレスに基づく簡易ネットワーク管理プロトコル（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ、ＳＮＭＰ）クエリに基づいてデバイスを管理する。しかしながら、各デバイスは、ローカルアドレスプールに基づいて（例えば、プライベートＩＰアドレスのセットから）、動的ホスト構成プロトコル（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＤＨＣＰ）サーバによってＩＰアドレスを割り当てられ得る。プライベートネットワーク内のデバイスへのアクセスを促進するために、デバイスマネージャは、従来、同じプライベートＩＰサブネットワーク及びローカルエリアネットワーク（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ、ＬＡＮ）などの同じネットワーク内に常駐する。しかしながら、大企業では、デバイスマネージャは、複数のサブネットにわたって大きなファイルを配信する必要があり得る。

デバイスマネージャは、典型的には、既存のネットワーキングフレームワーク及びプロトコルを使用して、企業ネットワーク内の大規模なファイル配信を可能にする。しかしながら、このような解決策は、位相認識ピアツーピアコンテンツ配信ソリューションに向けられている。これらの解決策は、特定のファイルのための好適な候補を見出すために参加者間のネットワーク条件を推定する。しかしながら、これらの解決策は、通常、ファイルの配信を計画しない。結果として、ファイルは、需要に基づいてネットワーク内に配信され得る。具体的には、これらの解決策はインターネットのためのものであるため、それらは、最小位相相関を有する広範に配信された参加者用に設計される。場合によっては、特定のファイルは、瞬間的な需要を有し、時間関心相関を作成する可能性があるが、位相相関は分散したままである。したがって、これらの解決策は、ファームウェア更新又はオペレーティングシステムパッチなどの、計画された使用のための高度な位相相関及び時間相関を有し得る企業環境を提供しない場合がある。

本明細書に記載される実施形態は、企業環境における動的コンテンツ配信を促進するためのシステムを提供する。動作中、システムは、企業環境のトポグラフィ情報を判定する。システムは、トポグラフィ情報に基づいて論理グループのセットを判定する。それぞれの論理グループは、コントローラによって管理される１つ以上のデバイスと、それらの１つ以上のデバイス間の接続を提供するネットワークとを含むことができる。システムは、ネットワーク内の第１の配信ツリーを介してコンテンツの配信計画を生成する。第１の配信ツリーのそれぞれのノードは、論理グループのセットの論理グループに対応する。コンテンツをホストする論理グループは、第１の配信ツリーのルートノードに対応することができる。次いで、システムは、配信計画を含む通知メッセージを、論理グループのセットのそれぞれの論理グループに送信する。

この実施形態の変形例では、配信計画は、受信デバイスがいつコンテンツを要求できるかを示すタイムラインを更に含む。

この実施形態の変形例では、コンテンツは、コントローラによって管理される１つ以上のデバイスのファームウェア更新である。

この実施形態の変形例では、システムは、論理グループのセットのそれぞれの論理グループのための１つ以上のグループヘッドを選択する。第１の論理グループと第２の論理グループとの間のグループ間接続は、第１及び第２の論理グループのそれぞれのグループヘッド間に形成される。

更なる変形例では、第１の論理グループは、第１のグループヘッド及び第２のグループヘッドを含む。コンテンツは、固有のブロックのセットに分割される。第１のグループヘッドは、第１の配信ツリーの上流ノードから固有ブロックのセットの第１のサブセットと、第２のグループヘッドから固有ブロックのセットの第２のサブセットとを取得することができる。

更なる変形例では、システムは、第１の論理グループ内の第２の配信ツリーを判定する。第２の配信ツリーは、コンテンツのそれぞれの受信ノードにわたり得る。第１及び第２のグループヘッドは、第２の配信ツリーの最上位にあってもよい。

この実施形態の変形例では、システムは、企業環境の１つ以上のデバイスのデバイス情報、及び企業環境内のそれぞれのリンクの帯域幅のうちの１つ以上を判定することによって、メッセージキュー（ｍｅｓｓａｇｅ ｑｕｅｕｅ、ＭＱ）ベースのメッセージ交換を使用してトポグラフィ情報を判定することができる。

本明細書に記載される実施形態は、企業環境における動的コンテンツ配信を促進するためのシステムを提供する。動作中、システムは、企業環境のソースデバイスの記憶デバイス内にコンテンツを記憶する。続いて、システムは、第１の受信デバイスからコンテンツに対する要求を受信する。次いで、システムは、ソースデバイスの現在及び割り当てられたタスクを示すスコアボードに基づいて、ソースデバイスの作業負荷を判定する。ソースデバイスの作業負荷に基づいて、システムは、第１の受信デバイスに対して、即時受入、保留受入、委譲、及び拒絶を含むオプションのセットから応答オプションを選択する。

この実施形態の変形例では、システムが応答オプションとして保留受入を選択する場合、システムは、ソースデバイスの鍵によって認証され、第１の受信デバイスのための時間窓で発行された第１のトークンを発行する。第１のトークンを受信すると、システムは、第１の受信デバイスがそれを介してソースデバイスからコンテンツを取得することができるチャネルを識別するチャネル識別子を割り当てる。

この実施形態の変形例では、システムが応答オプションとして委譲を選択する場合、システムは、第２の受信デバイスがコンテンツを取得したと判定し、第２のトークンを発行し、第２のトークンは、第１の受信ノードのための時間窓で発行された第２の受信ノードの鍵によって認証される。システムは、第１の受信デバイスがそれを介して第２の受信デバイスからコンテンツを取得することができるチャネルを識別するチャネル識別子を割り当てることができる。

本出願の一実施形態に係る、効率的なコンテンツ配信をサポートする例示的な企業環境を示す。 本出願の一実施形態に係る、企業環境におけるコンテンツの例示的なグループ間配信及びグループ内配信を示す。 本出願の一実施形態に係る、企業環境におけるコンテンツの効率的な配信を促進する例示的なシステムアーキテクチャを示す。 本出願の一実施形態に係る、企業環境のトポグラフィ情報を判定するコンテンツ配信システムの方法を示すフロー図を提示する。 本出願の一実施形態に係る、企業環境のトポグラフィ情報に基づいて、コンテンツの配信を計画するコンテンツ配信システムの方法を示すフロー図を提示する。 本出願の一実施形態に係る、企業環境におけるグループ間配信ツリーを判定するコンテンツ配信システムの方法を示すフロー図を提示する。 本出願の一実施形態に係る、企業環境におけるグループ間配信ツリーを介してファイルを取得するグループヘッドの方法を示すフロー図を提示する。 本出願の一実施形態に係る、論理グループ内のグループ内負荷共有配信ツリーを判定するコンテンツ配信システムの方法を示すフロー図を提示する。 本出願の一実施形態に係る、論理グループ内のグループ内負荷共有配信ツリーを介してファイルを取得する受信デバイスの方法を示すフロー図を提示する。 本出願の一実施形態に係る、企業環境における例示的な保留可能なコンテンツ配信を示す。 本出願の一実施形態に係る、企業環境における例示的な委譲可能なコンテンツ配信を示す。 本出願の一実施形態に係る、コンテンツを受信ノードに提供するソースノードの方法を示すフロー図を提示する。 本出願の一実施形態に係る、ソースノードからコンテンツを取得する受信ノードの方法を示すフロー図を提示する。 本出願の一実施形態に係る、受信ノードにコンテンツを提供する、委譲ノードの方法を示すフロー図を提示する。 本出願の一実施形態に係る、企業環境における効率的なコンテンツ配信を促進する例示的なコンピュータシステムを示す。 本出願の一実施形態に係る、企業環境における効率的なコンテンツ配信を促進する例示的な装置を示す。

本明細書に記載される実施形態は、（ｉ）企業環境のトポグラフィ情報に基づいて、大量のコンテンツの配信を計画すること、及び（ｉｉ）企業環境における保留可能及び委譲可能なコンテンツ配信を促進することによって、企業環境における大量のコンテンツを効率的に配信する問題を解決する。

既存の技術では、ソースデバイス（例えば、デバイスマネージャ）は、ポイントツーポイント通信を介して、受信デバイス（例えば、被管理デバイス）に大量のコンテンツを配信する。ファームウェア更新などのコンテンツが多数の受信デバイスに送信される場合、このプロセスは、各受信デバイスに対して繰り返される。そのような配信モードは、企業環境のネットワーキングインフラストラクチャ内の大量のトラフィックを引き起こし得る。加えて、各転送はデバイスペア間の個別の転送であり得るため、各転送は破損しやすい場合がある。その結果、企業環境は、些細でない破損率に直面する場合がある。

本明細書に記載される実施形態は、企業環境のトポグラフィを発見することができるコンテンツ配信システムを提供すること、コンテンツのための配信オーバーレイを計画し、オーバーレイを介して転送を実行するためにピアツーピア技術を使用することによって、これらの問題を解決する。システムは、セキュリティフレームワーク、制御フレームワーク、及びデータ転送フレームワークを促進することができる。セキュリティフレームワークは、制御チャネル及びデータチャネルの両方に対するセキュリティを提供することができる。区別されたノードは、システムを制御することに関与することができ、したがってコントローラと呼ばれる。コントローラの役割は、複数のデバイス上に（例えば、冗長性を有するように）配信させることができる。コントローラは、メッセージを（例えば、公開鍵システム（ＲＳＡ）及び／又は対称鍵交換を使用して）認証することができる。

制御フレームワークは、コマンド、要求、応答、及び通知であり得るメッセージのセットを使用することができる。コマンドは、コントローラから発行することができ、要求及び通知は、デバイスから発行することができ、応答はコマンド又は要求に従う。各メッセージは、送信者によって署名され、制御チャネルを介して伝送され得る。いくつかの実施形態では、制御チャネルは、メッセージキュー又は伝送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、ＴＣＰ）接続に基づいて実装され得る。それらは、他のデバイスを監視、編成、及び制御するために制御チャネルを使用することができる。例えば、コントローラは、デバイス構成及びネットワーク条件などの測定を行うようにデバイスに命令し、測定値をコントローラに提供することができる。コントローラは、測定値に基づいて、企業環境のトポグラフィ情報を判定することができる。次いで、コントローラは、ソースデバイス（例えば、ストレージサーバ）から特定のコンテンツのための効率的な配信経路を計画することができる。

データ転送フレームワークは、企業環境におけるファイル転送プロトコルを提供することができる。コントローラは、そのコンテンツを要求する企業環境において、各被管理デバイスに通知することができる。コントローラはまた、コンテンツに関する時間枠の対応する被管理デバイスに（例えば、いつ要求し、どこから要求するか）を通知することができる。被管理デバイスは、要求に対する優先度を示す優先度値で構成することができる。例えば、優先度は、被管理デバイスが最初にコンテンツを要求すべきソースデバイスを示すことができる。いくつかの実施形態では、コントローラは、被管理デバイスのセットを論理グループに（例えば、インターネットプロトコル（ＩＰ）サブネットに基づいて）編成する。コンテンツを配信するために、コントローラは、ツリーのノードとして論理グループを含む配信ツリーを生成することができる。各グループは、上流ノード（すなわち、ツリーの親ノード）からコンテンツを取得するために関与する１つ以上のグループヘッドを含むことができる。ツリーのルートは、コンテンツのソースを含むサブネットであり得る。

グループヘッドは、複数のグループヘッドがコンテンツの固有ブロックを同時にダウンロードすることを可能にするブロックベースのプロトコルを配備することができる。例えば、グループヘッドは、ランダムブロックのダウンロードを開始し、互いに協調して重複排除を回避することができる。あるいは、１つのグループヘッドは、奇数個目のブロックをダウンロードすることができ、他方は偶数個目のブロックをダウンロードすることができる。各ブロックは、１つ以上のデータチャンク（例えば、コンテンツを分割することができるデータの単位）を含むことができる。グループヘッドはまた、パイプラインを組み込むことができる。上流ノードが閾値量のデータをダウンロードすると、下流ノードは、コンテンツ全体が上流ノードによってダウンロードされていない場合であっても、そのデータを取り出すことを開始することができる。１００メガバイト（ＭＢ）ファイルが、配信ツリー内の４つのホップのために、１メガバイト／秒（Ｍｂｐｓ）リンクを介して転送されると仮定する。ホップバイホップ転送のために、最後のノードは、３００秒後にファイルを受信し始め、４００秒後にそれを受信することを終了する。ブロックベースのプロトコルで、最後のホップは、３秒後にデータ受信データを開始し、１０３秒後にファイル全体を受信する。

いくつかの実施形態では、配信技術を更に改善するために、システムは、企業環境内の保留可能及び委譲可能なコンテンツ配信技術を含み得る。コンテンツのソースの数は、制限することができる。そのコンテンツは、受信ノードとして動作する、多数の被管理デバイスによって要求され得る。コンテンツを効率的に配信するために、ソースノードは、ソースがコンテンツを受信ノードに送達することができるときにタイムラインを示すことによって、送達を保留することができる。受信ノードは、保留によって示される時間にコンテンツを要求することができる。更に、コンテンツが受信ノードに送達されると、そのノードはソースノードとして動作を開始することができる。元のソースノードは、そのコンテンツに対する要求をその新たなソースノードに委譲することができる。これにより、受信デバイスは、コンテンツを効率的に送達することができるソースノードを選択することを可能にする（例えば、最も早いものを送達することができる）。

図１Ａは、本出願の一実施形態に係る、効率的なコンテンツ配信をサポートする例示的な企業環境を示す。企業環境１００は、多数のサイト１１２、１１４、１１６、１１８、１２０、及び１２２にわたって配信され得る。これらのサイトは、ローカル又は広域ネットワークなどのネットワーク１１０を介して互いに結合することができる。広域ネットワークは、インターネットであり得る。サイトはまた、（例えば、ポイントツーポイント光ファイバを用いて）互いに直接接続することもできる。サイト１１２などのサイトは、複数のサブネット１１１（例えば、１０．１．０．０／１６）及び１１３（例えば、１０．２．０．０／１６）を含むことができる。一方、サイト１１４などのいくつかの他のサイトは、サブサイト１２４（例えば、同じ管理下の近傍のより小さなサイト）にわたり得る１つのサブネット（例えば、１０．３．３．０／２４）を有することができる。同様に、サイト１２０は、サブサイト１２６にわたり得る１つのサブネット（例えば、１０．７．０．０／１６）を有することができる。サブサイト１２４及び１２６はまた、それら自体のサブネットを維持することができることに留意されたい。

既存の技術では、環境１００において、ソースデバイス１０２は、ポイントツーポイント通信を介して、受信デバイスに大量のコンテンツを配信する。ファームウェア更新などのコンテンツが、企業環境１００のサイトにわたって多数の受信デバイスに送信される場合、このプロセスは、各サイト内の各受信デバイスに対して繰り返される。そのような配信モードは、企業環境１００のネットワーク１１０内の大量のトラフィックを引き起こし得る。加えて、各転送はデバイスペア間の個別の転送であり得るため、各転送は脆弱で破損する場合がある。結果として、企業環境１００は、些細でない破損率に直面する場合がある。

この問題を解決するために、本明細書に記載される実施形態は、企業環境１００のトポグラフィを発見し、コンテンツのための配信オーバーレイを計画し、オーバーレイを介して転送を実行するためにピアツーピア技術を使用することができるコンテンツ配信システム１５０を提供する。システム１５０は、セキュリティフレームワーク、制御フレームワーク、及びデータ転送フレームワークを促進することができる。セキュリティフレームワークは、制御チャネル及びデータチャネルの両方に対するセキュリティを提供することができる。区別されたノード１４０は、システムを制御することに関与することができ、したがってコントローラ１４０と呼ばれる。いくつかの実施形態では、システム１５０は、コントローラ１４０上でホストされ得る。企業環境１００は、互いに高い可用性を促進することができる複数のコントローラ１４０及び１４２を含むことができる。コントローラ１４０は、メッセージを（例えば、公開鍵システム及び／又は対称鍵交換を使用して）認証することができる。

システム１５０によって提供される制御フレームワークは、コマンド、要求、応答、及び通知であり得るメッセージのセットを使用することができる。コマンドは、コントローラ１４０から発行することができ、デバイス１０６及び１０８などの被管理デバイスからコマンドを発行することができ、応答はコマンド又は要求に従う。各メッセージは、送信者によって署名され、制御チャネルを介して伝送され得る。例えば、コントローラ１４０がデバイス１０６にメッセージを送信する場合、コントローラ１４０は、コントローラ１４０の秘密鍵でメッセージに署名することができる。いくつかの実施形態では、制御チャネルは、メッセージキュー接続又はＴＣＰ接続に基づいて実装され得る。制御チャネルは、他のデバイスを監視、編成、及び制御するために使用することができる。例えば、コントローラ１４０は、デバイス構成及びネットワーク条件などの測定を行うように被管理デバイスに命令し、測定値をコントローラ１４０に提供することができる。コントローラ１４０は、測定値に基づいて、企業環境１００のトポグラフィ情報を判定することができる。次いで、コントローラ１４０は、ソースデバイス１０２から特定のコンテンツ１６０のための効率的な配信経路を計画することができる。コントローラ１４０及びソースデバイス１０２は、同じデバイス又は異なるデバイスであり得る。

データ転送フレームワークは、企業環境１００内にファイル転送プロトコルを提供することができる。コントローラ１４０は、どのコンテンツを要求するかについて、企業環境１００内の各被管理デバイスに通知することができる。コントローラ１４０はまた、コンテンツ１６０のための時間枠のそれぞれの被管理デバイスに（例えば、いつ要求し、どこから要求するか）を通知することができる。被管理デバイスは、要求に対する優先度を示す優先度値で構成することができる。例えば、優先度は、被管理デバイスが最初にコンテンツを要求すべきソースデバイスを示すことができる。いくつかの実施形態では、コントローラ１６０は、１つ以上のグループ化基準に基づいて、被管理デバイスのセットを論理グループに編成する。グループ化基準の例としては、ＩＰサブネット、ローカルエリアネットワーク、及び層−２ネットワーク内のスパニングツリーが挙げられるが、これらに限定されない。

コンテンツ１６０、コントローラ１４０を配信するために、ツリーのノードとして論理グループを含む配信ツリーを生成することができる。この例では、それぞれのサイト又はサブサイトは論理グループとして表され、強調された矢印は、ツリーの各ブランチを描写する。サイト１１２は２つのサブネット１１１及び１１３を有するので、それらは、ツリー上の２つの異なるノードであり得る。企業環境１００のサブサイト１２８などのサイト又はサブサイトが、サブサイトがコンテンツ１６０の受信者を含まない場合、そのサブサイトはツリーに含まれていない。各グループは、上流ノード（すなわち、ツリーの親ノード）からコンテンツを取得することに関与する１つ以上のグループヘッド（破線円で示される）を含むことができる。サブネット１１１に対応するグループは、ソースデバイス１０２及び被管理デバイス１０４をグループヘッドとして含むことができる。同様に、サイト１１４に対応する論理グループは、グループヘッドとしてデバイス１０６及び１０８を含むことができ、サイト１１６に対応する論理グループは、グループヘッドとしてデバイス１３２及び１３４を含むことができる。したがって、デバイス１０２、１０４、１０６、１０８、１３２、及び１３４は、グループヘッドとも称され得る。この例のツリーのルートは、ソースデバイス１０２がコンテンツ１６０をホストすることを含むサブネット１１１である。コントローラ１４０は、（例えば、ソースデバイス及び受信デバイスに基づいて）変化し得る各コンテンツの配信ツリーを計画することができることに留意されたい。

いくつかの実施形態では、コントローラ１４０は、シュタイナー木（例えば、最小コストツリー）を計算して、グループ間配信ツリーを生成することができる。企業環境１００では、いくつかのデバイスは、受信デバイス（例えば、コンテンツ１６０の受信者）とすることができ、他のデバイスは、中継デバイス又は休止デバイスとして動作することができる。シュタイナー木は、必要に応じて、いくつかの中継デバイスを使用して、最小コストツリーを見出すために、全ての受信デバイスにわたることができる。コントローラ１４０は、最短経路の組み合わせを使用して、最小コストのツリーを計算することができる。コントローラ１４０は、企業環境１００のトポグラフィ情報を使用して、各受信デバイスから企業環境１００内のソースデバイスへの最短経路を判定することができる。次いで、コントローラ１４０は、全ての受信デバイスからソースデバイス１０２への、最小コストの単一ソース指向スパニングツリーを判定する。

コントローラ１４０は、測定を使用して、ユーザ入力及びネットワーク発見のうちの１つ以上に基づいて、企業環境１００のトポグラフィ情報を判定することができる。コントローラ１４０は、２つのサブネット間の帯域幅及び往復時間を測定することによって、ネットワーク発見を実行することができる。そうするために、ソースノード１０２は、異なる長さの一連のパケットを各グループヘッドに何度も送信する。コントローラ１４０は、各パケットサイズに対する最小応答時間を判定し、それらの値に対する線形回帰を計算する。コントローラ１４０はまた、毎秒ビットの帯域幅を判定し、往復時間は秒単位である。コントローラ１４０は、指数関数的移動平均を介して複数の測定値を集約して、リンクの帯域幅を判定することができる。

グループヘッドは、グループ間データ転送に関与する。グループヘッド１０６及び１０８は、上流グループヘッド１０２及び１０４に論理的に結合することができる。同様に、グループヘッド１３２及び１３４は、上流グループヘッド１０６及び１０８に論理的に結合することができる。論理グループがコンテンツのための十分な数の受信デバイスを有さない場合、その論理グループは、複数のグループヘッドを有しない場合がある。例えば、サブサイト１２４に対応する論理グループは、１つのグループヘッド１３６を含むことができる。効率的な配信のために、コントローラ１４０は、コンテンツ１６０をいくつかのブロックに分割することができる（例えば、それぞれが所定の数の固定サイズのデータチャンクを有する）。グループヘッド１０４は、ソース１０２と同じ論理グループにあるため、グループヘッド１０４は、最初にソース１０２からコンテンツ１６０を取得する。

いくつかの実施形態では、グループヘッド１０６及び１０８は、両方のグループヘッドがコンテンツ１６０の固有のブロック及び非重複ブロックを同時にダウンロードすることを可能にするブロックベースのプロトコルを配備することができる。グループヘッド１０６及び１０８は、ランダムブロックのダウンロードを開始し、互いに協調して重複排除を回避することができる。転送中にグループヘッド１０８などの１つのグループヘッドが破損した場合、グループヘッド１０６は、残りのブロックをダウンロードし続けることができる。あるいは、グループヘッド１０６は、上流グループヘッド１０２及び１０４からコンテンツ１６０の奇数個目のブロックをダウンロードすることができる。負荷分散を促進するために、グループヘッド１０６は、グループヘッド１０２からのコンテンツ１６０の奇数個目のブロックのサブセットをダウンロードする一方で、グループヘッド１０４から残りをダウンロードすることができる。同様に、グループヘッド１０８は、上流グループヘッド１０２及び１０４から偶数個目のブロックをダウンロードすることができる。グループヘッド１０６及び１０８は、それらのピアリンクを介して固有ブロックを交換して、各ブロックを取得し、コンテンツ１６０の完全なコピーを再構築することができる。グループヘッド１０６はまた、上流グループヘッド１０２からコンテンツ１６０の奇数個目のブロックをダウンロードすることができ、次いで、グループヘッド１０８は、上流グループヘッド１０４からコンテンツ１６０の偶数個目のブロックをダウンロードすることができる。グループヘッドはまた、パイプラインを組み込むことができる。グループヘッド１０６及び１０８が閾値数のブロックをダウンロードしたとき、下流グループヘッド１３２及び１３４は、コンテンツ１６０がその全体で上流グループヘッド１０６及び１０８によってダウンロードされていない場合であっても、それらのブロックを取り出すことを開始することができる。

図１Ｂは、本出願の一実施形態に係る、企業環境におけるコンテンツの例示的なグループ間配信及びグループ内配信を示す。この例では、コントローラ１４０は、コンテンツ１６０を配信するための配信ツリー１７０を生成することができる。配信ツリー１７０は、ツリー１７０のノードとして論理グループ１６２、１６４、１６６、１６８、１７２、１７４、及び１７６を含むことができる。論理グループ１６２、１６４、１６６、１６８、１７２、１７４、及び１７６は、それぞれサブネット１１１、サイト１１４、サブサイト１２４、サイト１１６、サブネット１１３、サイト１２２、及びサイト１２０に対応することができる。コントローラ１４０は、グループヘッドとして受信デバイス又は中継デバイスであってもよく、少なくとも２つの被管理デバイスを判定することができる。ソース１０２及びデバイス１０４は、グループ１６２のためのグループヘッドとすることができ、デバイス１０６及び１０８はグループ１６４のためのグループヘッドとすることができ、デバイス１３６はグループ１６６のためのグループヘッドであってもよく、デバイス１３２及び１３４はグループ１６８のためのグループヘッドであってもよい。

グループ間リンクは、グループヘッド間に形成され得る。例えば、グループ１６２とグループ１６４との間のリンクは、グループ１６２のグループヘッド１０２と１０４との間、並びにグループ１６４のグループヘッド１０６と１０８との間にある。グループ１６６は１つのグループヘッド１３６を含むので、グループ１６４と１６６との間のリンクは、グループ１６４のグループヘッド１０６及び１０８と、グループ１６６のグループヘッド１３６との間にある。図１Ａに示されるように、グループは、サイト１２２に対応するグループ１７４などの中間グループであってもよい。グループヘッドは、中継又は受信デバイスとして動作する中間物であってもよい。例えば、グループ１７４のグループヘッド１４４及び１４６は、グループ１７２からグループ１７６へのデータ転送の確立を促進する中間グループヘッドであり得る。各グループヘッドは、各上流グループヘッド（例えば、各親グループヘッド）とのリンクを維持することができる。例えば、グループヘッド１３６は、グループヘッド１０６及び１０８のそれぞれにリンクを有することができる。

グループ内のグループヘッドは、対応するピアリンクと相互に完全なピア関係を有することができ、これにより、ピアツーピア転送プロトコルを使用してデータを転送してデータブロックを協調することが可能になる。例えば、グループヘッド１０６及び１０８は、完全なペアの関係を維持することができる。グループヘッド１０６及び１０８は、グループ間リンク上で１回を超えて同じブロックをダウンロードするのを回避するために、それら自体の間で協調することができる。コンテンツ１６０は、ブロック１８１、１８２、１８３、及び１８４に分割され、グループヘッド１０６は、ブロック１８１及び１８３をダウンロードすることができ、グループヘッド１０８は、ブロック１８２及び１８４を上流グループヘッド１０２及び１０４からダウンロードすることができる。次いで、グループヘッド１０６は、ピアリンクを介してグループヘッド１０８からブロック１８２及び１８４を取得し、グループヘッド１０８は、ピアリンクを介してグループヘッド１０６からブロック１８１及び１８３を取得することができる。これを促進するために、グループヘッド１０６及び１０８は、ピアリンクからブロックを取得するためにより高い優先度を有するように構成することができる。次いで、グループヘッド１０６及び１０８のそれぞれは、ブロック１８１、１８２、１８３、及び１８４を組み合わせて、コンテンツ１６０を生成する。

グループ１６８内で、いくつかの被管理デバイスが、グループヘッド１３２及び１３４からコンテンツ１６０を取得することができる。グループ内配信に関して、コントローラ１４０は、グループヘッド１３２及び１３４でルートされる配信階層を作成する。階層は、ｎ分木として表すことができ、各被管理デバイスは、ｎ分木内のｐの上流の親ノードに結合される。ｐリンクの中で、１つのリンクはアクティブリンクとすることができ、他のリンクは冗長性を促進するために待機リンクとして動作することができる。各被管理デバイスは、アクティブな親ノードからブロック１８１、１８２、１８３、及び１８４をダウンロードすることができる。いくつかの実施形態では、論理グループ内のネットワークは、高速ローカルエリアネットワーク（ＬＡＮ）であり得る。その結果、コンテンツ１６０は、ＬＡＮを介して論理グループ１６８内に効率的に配信され得る。あるいは、グループヘッド１３２及び１３４は、転送ブロック１８１、１８２、１８３、及び１８４に放送されたＬＡＮをグループ１６８内の全ての被管理デバイスに使用することができる。

いくつかの実施形態では、コントローラ１４０は、コンテンツ１６０の配信の時間及びスケジュールに関して各被管理デバイスに通知することができる。コントローラ１４０は、ピアツーピアプロトコルが上流デバイスに接続してコンテンツ１６０を加入することを期待し、その上流デバイスが少なくとも閾値数のブロックを取得するまで待機することができる。上流デバイスが閾値数のブロックをダウンロードした場合、下流側デバイスは、それらのブロックを上流デバイスからダウンロードすることを開始することができる。

図２は、本出願の一実施形態に係る、企業環境におけるコンテンツの効率的な配信を促進する例示的なシステムアーキテクチャを示す。この例では、コントローラ１４０、及び被管理デバイス１０６などのそれぞれの被管理デバイスは、それぞれ、主動作モジュールコントローラモジュール２００及び被管理デバイスモジュール２５０を含む。コントローラモジュール２００は、登録モジュール２０２、鍵モジュール２０４、グラフ化モジュール２０６、スケジューラモジュール２１４、及びプランナーモジュール２０８に基づいて動作する。一方、被管理デバイスモジュール２５０は、登録モジュール２５２、鍵モジュール２５４、測定モジュール２５６、及び転送モジュール２５８に基づいて動作することができる。

コントローラ１４０、登録モジュール２０２は、登録要求をリッスンし、被管理デバイスから要求メッセージを登録解除することができる。要求に基づいて、登録モジュール２０２は、ノードデータベース２１２内の企業環境１００内の現在のデバイス及びサブネットのセットの情報を維持する。鍵モジュール２０４は、被管理デバイスからの鍵要求メッセージをリッスンし、メッセージキューイングを使用して、一時的な楕円曲線ディフィーヘルマンなどの鍵交換を実行することができる。鍵モジュール２０４はまた、ハッシュベースメッセージ認証符号（ｈａｓｈ−ｂａｓｅｄ ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｏｄｅ、ＨＭＡＣ）などの対称鍵でコントローラ１４０のキーリングを更新する。グラフ化モジュール２０６は、測定応答メッセージをリッスンすることができ、これらのメッセージに基づいて、企業環境１００の加重サブネット対サブネットグラフを維持することができる。

スケジューラモジュール２１４は、ネットワーク性能及び特性を測定するために、サブネット間の測定値を定期的にスケジュールする。スケジューラモジュール２１４はまた、ノードデータベース２１２内のサブネット間のエッジを示すテーブルを維持する。プランナーモジュール２０８は、コンテンツに関して、現在登録されているデバイスに基づいて、受信デバイスを含むソースデバイス及びターゲットサブネットを判定し、配信ツリーを判定するための実験をスケジュールする。プランナーモジュール２０８は、配信計画を生成し、それを計画データベース２１６に記憶することによって、コンテンツの配信を開始する。プランナーモジュール２０８は、配信に関する被管理デバイスからの通知を受信することができる。

被管理デバイス１０６において、登録モジュール２５２は、定期的登録要求メッセージをコントローラ１４０に送信し、応答をリッスンする。鍵モジュール２５４は、鍵交換要求メッセージを送信し、対応する応答をリッスンすることによって、新しい鍵を定期的に生成する。鍵モジュール２５４はまた、ＨＭＡＣキーを用いて被管理デバイス１０６のキーリングを更新することができる。測定モジュール２５６は、ネットワーク測定の初期化をリッスンすることができる。これに基づいて、測定モジュール２５６は、ネットワーク測定をスケジュールし、測定値をグラフ化モジュール２０６に送信することができる。転送モジュール２５８は、コントローラ１４０からのメッセージをリッスンし、コンテンツの配信を初期化し、ピアツーピアプロトコル２６０を介してピアツーピア転送をスケジュールする。転送モジュール２５８は、応答を送信して転送初期化メッセージを確認し、重要なイベント（例えば、開始、終了、エラーの検出など）に関してコントローラ１４０に通知することができる。プロトコル２６０は、プランナーモジュール２０８の制御下でピアツーピアファイルの転送を実行する。

図３Ａは、本出願の一実施形態に係る、企業環境のトポグラフィ情報を判定するコンテンツ配信システムの方法を示すフロー図３００を提示する。動作中、システムは、企業環境内のＩＰサブネットを判定し（動作３０２）、サブネット内の被管理デバイスを判定する（動作３０４）。次いで、システムは、それぞれの被管理デバイスに関する測定コマンドを発行し（動作３０６）、それぞれの被管理デバイスから測定値を受信する（動作３０８）。測定コマンドは、被管理デバイスにネットワーク及びデバイス条件（例えば、帯域幅、レイテンシ、利用率など）を測定し、システムに報告するように命令する。このシステムは、ＩＰサブネットの加重サブグラフを生成し、受信した測定値に基づいてエッジ情報を更新する（動作３１０）。システムは、全てのサブネットがチェックされたかどうかをチェックする（動作３１２）。チェックされた場合、システムは、企業ネットワークの加重オーバーレイグラフを生成する（動作３１４）。そうでなければ、システムは、企業環境内の次のＩＰサブネットを判定し続ける（動作３０２）。

図３Ｂは、本出願の一実施形態に係る、企業環境のトポグラフィ情報に基づいて、コンテンツの配信を計画するコンテンツ配信システムの方法を示すフロー図３５０を提示する。動作中、システムは、企業環境内の論理グループを（例えば、サブネット又はサイトに基づいて）識別し（動作３５２）、コンテンツのソースデバイスが論理グループ内にあるかどうかを判定する（動作３５４）。ソースデバイスが論理グループ内にある場合、システムは、論理グループのためのグループヘッドとしてソースデバイスを判定する（動作３５６）。次いで、システムは、グループヘッド選択が完了したかどうか（例えば、２つなどの所定の数のグループヘッドが選択されているか、又はデバイスがこれ以上選択されないか）を判定する（動作３５８）。グループヘッド選択が完了していない場合、システムは、コンテンツのための任意の受信デバイスが論理グループ内で利用可能かどうかをチェックする（動作３６０）。

少なくとも１つの受信デバイスが利用可能である場合、システムは、論理グループのグループヘッドとして受信デバイスをランダムに選択する（動作３６２）。そうでなければ、システムは、論理グループのグループヘッドとして中継デバイスをランダムに選択する（動作３６４）。グループヘッドを選択すると（動作３６２又は３６４）、システムは、グループヘッドの選択が完了したかどうかを判定する（動作３５８）。グループヘッドの選択が完了した場合、システムは、グループ間配信ツリー及びグループ内配信ツリーを生成し（動作３６６）、グループ内配信及びグループ間配信のためのグループヘッドを構成する（動作３６８）。この構成は、ブロックベースのプロトコルを構成することを含み得る。

図４Ａは、本出願の一実施形態に係る、企業環境におけるグループ間配信ツリーを判定するコンテンツ配信システムの方法を示すフロー図４００を提示する。動作中、システムは論理ノードとして論理グループを表し（動作４０２）、それぞれの論理ノードとソース論理ノードとの間の最短経路（すなわち、ソースデバイスに関連付けられた論理ノード）を計算する（動作４０４）。システムは、計算された最短経路に基づいて補助グラフを生成し（動作４０６）、ソース論理ノードでルートされる最小コスト単一ソーススパニングツリーを計算する（動作４０８）。次いで、システムは、対応するグループヘッドに基づいて、スパニングツリー上のそれぞれの論理ノードペア間の物理的経路を判定する（動作４１０）。

図４Ｂは、本出願の一実施形態に係る、企業環境におけるグループ間配信ツリーを介してファイルを取得するグループヘッドの方法を示すフロー図４３０を提示する。動作中、グループヘッドは、転送コマンド、ファイル記述子、及びコントローラからのコンテンツに関連付けられたスケジュールを受信する（動作４３２）。受信した情報に基づいて、グループヘッドは、上流グループヘッドから取り出されるコンテンツの固有のブロックのサブセットを判定し、（例えば、上流グループヘッドから）サブセット内の対応するブロックのソースグループヘッドを割り当てる（動作４３４）。次いで、グループヘッドは、閾値数のブロックが上流グループヘッドで利用可能かどうかを判定する（動作４３６）。これにより、コンテンツのパイプラインダウンロードが可能になる。

閾値数のブロックが利用可能でない場合（動作４３８）、グループヘッドは、閾値数のブロックが上流グループヘッド内で利用可能かどうかを判定し続ける（動作４３６）。一方、閾値数のブロックが利用可能である場合（動作４３８）、グループヘッドは、対応するソースグループヘッドからサブセット内のそれぞれのブロックを取得する（動作４４０）。グループヘッドは、ピアグループヘッドから、もしあれば、ブロックの残りを取得する（動作４４２）。いくつかの論理グループは、単一のグループヘッドを有することができ、これは、上流グループヘッドから各ブロックを取り出すことに留意されたい。次いで、グループヘッドは、取得されたブロックを組み合わせて、コンテンツを再構成し（動作４４４）、コンテンツ上の転送コマンド（例えば、ファームウェア更新）に示される動作を実行する（動作４４６）。

図４Ｃは、本出願の一実施形態に係る、論理グループ内のグループ内負荷共有配信ツリーを判定するコンテンツ配信システムの方法を示すフロー図４５０を提示する。動作中、システムは、グループヘッドが初期レベルにあり、各レベルが指定された数のデバイスを有するように、論理グループ内のそれぞれの受信デバイスのレベルを判定する（動作４５２）。レベル内の全てのデバイスは、受信デバイスでなくてもよく、いくつかのデバイスは中継デバイスであってもよいことに留意されたい。次いで、システムは、接続を確立するために次のレベルを選択する（動作４５４）。選択されたレベルの各レベルについて、システムは、デバイスを、対応するエッジを有する以前のレベル（例えば、上流デバイス）内の所定の数のデバイスに結合する（動作４５６）。より多くのレベルがある場合（動作４５８）、システムは、接続を確立するために次のレベルを選択し続ける（動作４５４）。そうでなければ、システムは、確立された接続に基づいて、負荷共有配信ツリー（例えば、ｎ分木）を形成する（動作４６０）。

図４Ｄは、本出願の一実施形態に係る、論理グループ内のグループ内負荷共有配信ツリーを介してファイルを取得する受信デバイスの方法を示すフロー図４７０を提示する。動作中、受信デバイスは、負荷共有配信ツリー内の上流デバイスからコンテンツに関連付けられた転送コマンド及びファイル記述子を受信する（動作４７２）。受信デバイスは、アクティブな上流デバイスからコンテンツのそれぞれのブロックを取得し（動作４７４）、取得されたブロックを組み合わせて、コンテンツを再構成する（動作４７６）。次いで、受信デバイスは、コンテンツ上の転送コマンド（例えば、ファームウェア更新）に示される動作を実行する（動作４７８）。

図１Ａの実施例では、多数の受信デバイスが、制限された数のソースからコンテンツを取得する。コンテンツ（例えば、ファームウェア又はメディアファイル）の配信効率を向上させるために、ソースデバイスは、コンテンツの要求を、コンテンツを既に受信している受信デバイスに委譲することができる。コンテンツ１６０のソースデバイス１０２などのソースデバイスは、要求をローカルに（例えば、コントローラ１４０からの介入なしに）委譲することができる。ソースデバイス１０２はまた、後の時間の要求を保留することができる。受信デバイスは、保留時間で要求を再送信することができる。このようにして、ネットワーク環境１００は、要求を保留及び委譲することができる非一元的システムを促進することができる。

図５Ａは、本出願の一実施形態に係る、企業環境における例示的な保留可能なコンテンツ配信を示す。受信ノード５０８及び５１０を含む多数の受信ノード５５０は、コンテンツ５７０がソースノード５０２、５０４、及び５０６を含む多数のソースノード５００内にホストされることを発見することができる。受信ノード５５０は、コンテンツ５７０の存在を示すソースノード５００からの広告、及び（例えば、ユーザからの）外部入力のうちの１つ以上によって、コンテンツ５７０を発見することができる。ソースノード５００の各ソースノードは、それぞれのリソース限界を有することができ、したがって、制限された数の受信ノードを提供することができる。

動作中、受信ノード５０８は、ソースノード５０２、５０４、及び５０６からコンテンツ５７０を要求することができる（動作５１２）。要求を受信すると、ソースノードは、（ａ）直ちに要求を提供し、（ｂ）後のサービスの要求を受け入れ、（ｃ）ジョブを別のノードに委譲し、又は（ｄ）要求を拒絶することができる。それぞれのソースノードは、現在のスコアボード及び予約されたタイムスロットに基づいて、統計的にソースノードが過剰に加入していないことを確実にするために、応答オプションのうちの１つを判定する。例えば、ソースノード５０２、５０４、及び５０６は、スコアボード５０３、５０５、及び５０７をそれぞれ維持し、応答オプションを判定することができる（動作５１４）。例えば、ソースノード５０２は、要求を拒絶し、受信ノード５０８に通知することができる（動作５１６）。ソースノード５０２は、後で要求をサービスすることができるかどうかの指示を含むことができる。

ソースノードがオプション（ａ）、（ｂ）、及び（ｃ）から選択する場合、そのソースノードは、要求に関連付けられたスコアボード上の「留保中」状態を示すことができ、受信ノード５０８からの応答を待機することができる。例えば、ソースノード５０４は、受信ノード５０８が特定の時間窓にわたってコンテンツ５７０にアクセスすることを許可し、スコアボード５０５内の留保状態をマークするトークンを発行することができる（動作５１８）。同様に、ソースノード５０６は、受信ノード５０８が特定の時間窓にわたってコンテンツ５７０にアクセスすることを許可し、スコアボード５０７内の留保状態をマークするトークンを発行することができる（動作５２０）。トークンは、発行ソースノードによって認証された暗号データ構造であり得る。トークンは、特定のソースノードによる特定の受信ノードのための提供（例えば、時間窓）で発行される。例えば、ソースノード５０４によって発行されたトークンは、受信ノード５０８のＩＰアドレスに基づく受信ノード５０８及びトークンを認証するソースノード５０４の鍵に基づく発行ソースノード５０４を識別することができる。

受信ノード５０８は、ソースノード５０４及び５０６からのトークンを比較して、ソースノード５０８の効率的なオプションを判定する（動作５２２）。効率的な選択肢の例としては、最小遅延及び最小コストが挙げられるが、これらに限定されない。受信ノード５０８は、提供を受け入れるか、又は拒絶するかのいずれかであり得る。受信ノード５０８がソースノード５０６からの提供を受け入れると仮定する（動作５２４）。次いで、ソースノード５０６は、保留インジケータを、提供された時間窓に対して留保インジケータに変更することによって、スコアボード５０７を更新することができる（動作５２８）。一方、受信ノード５０８は、ソースノード５０４からの提供を拒絶する（動作５２６）。次いで、ソースノード５０４は、留保インジケータを除去することによって、スコアボード５０５を更新することができる（動作５３０）。

提供は時間制限を有することができ、受信ノード５０８は、その時間制限内の提供を確認する必要があることに留意されたい。ソースノード５０４は、スコアボード５０７を管理するために確認を使用することができる。受信ノード５０８は、時間制限までの提供の受け入れを保留することができる。受信ノード５０８はまた、提供を受け入れ、受信ノード５０８がより良好な提供を受信した場合に、その後提供を取り消すことができる。トークンの時間窓によって示される時間を待機すると（動作５３２）、受信ノード５０８はトークンを使用する準備ができ得る。次に、受信ノード５０８は、トークンをソースノード５０６に提出する（動作５３４）。ソースノード５０６が要求を提供する準備ができている場合、ソースノード５０６は、受信ノード５０８のためのデータチャネルを割り当てることができる（動作５３６）。

データチャネルを割り当てるために、ソースノード５０６は、データチャネル識別子を受信ノード５０８に発行することができる。データチャネル識別子は、コンテンツ５７０にトークンをどのようにアクセスするかを表す。データチャネル識別子の例としては、統一資源識別子（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ、ＵＲＩ）、ＩＰアドレス及びポート番号ペア、又はメディアアクセス制御（ｍｅｄｉａ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ、ＭＡＣ）アドレスを挙げることができるが、これらに限定されない。ソースノード５０６はまた、データチャネル識別子を有する新しいトークンを発行することができる。新しいトークンは、データチャネル識別子に結び付けることができる。受信ノード５０８は、割り当てられたデータチャネルを介してコンテンツ５７０を取得することができる（動作５３８）。そうするために、受信ノード５０８は、検証のために、データチャネルを介してソースノード５０６に元のトークン又は新しいトークンであり得るトークンを提出することができる。検証の際、ソースノード５０６は、ソースノード５０６がそのように準備され、容量を有する場合に、転送を開始することができる。データチャネルは、要求チャネルを促進する同じネットワーク接続であり得ることに留意されたい。

ここで、受信ノード５０８は、少なくとも２回、すなわちチャネルを要求するために１回、及びデータチャネル上に１回、トークンを提出することができる。第２のトークンを生成することを回避するために、ソースノード５０６は、受信ノード５０８に対して一意にデータチャネル識別子を構築することができ、データチャネル識別子のみを検証する第１のトークン内の情報を含むことができる。換言すれば、ソースノード５０６は、生成プロセス中に第１のトークンをデータチャネル識別子にバインドすることができるが、トークンが提出されるまでデータチャネル識別子を受信ノード５０８に提供しなくてもよい。

いくつかの実施形態では、ソースノード５００は、ブロンズ、シルバー、及びゴールドレベルサービスなどの優先レベルを有するトークンを提供することができる。例えば、ソースノード５０６は、ソースノード５０６がそのトークンをサービスすることができる場合、ゴールドレベルトークンのみを提供する。しかしながら、ソースノード５０６は、シルバー又はブロンズレベルトークンに過剰に加入してもよい。より高い優先度の提供は、データチャネル上の受け入れられたトークンの数のために、スコアボード５０７上に人工天井を作成することができる。例えば、ソースノード５０６が１０の要求にサービスすることができる場合、ソースノード５０６は、３つのゴールドレベル、５つのシルバーレベル、及び２つのブロンズレベルトークンを提供し得る。ソースノード５０６がジョブプリエンプションをサポートする場合、ソースノード５０６は、より低い優先度のトークンがプリエンプトされることを受け入れて、より低い優先度のトークンを大幅に過剰に加入させることができる。

要求チャネル及びデータチャネルは、短期接続ではない場合がある。要求ノード５０８は、例えば、閾値時間までの間、ソースノード５０６の要求チャネルに接続されたままであってもよい。同様に、データチャネルに関しても、要求ノード５０８は、ソースノード５０６のデータチャネルに閾値時間まで接続されたままであってもよいが、トークンによって許可された速度で要求を提出するだけでよい。到達要求のために、ソースノード５０６はトークン及びデータチャネル識別子を提示することができる。

図５Ｂは、本出願の一実施形態に係る、企業環境における例示的な委譲可能なコンテンツ配信を示す。ソースノード５０６は、新しい要求を受信すると、又はトークンが提出されたときに、コンテンツ５７０の配信を委譲することができる。例えば、ソースノード５０６は、受信ノード５１０がコンテンツ５７０を取得し、受信ノード５０８が受信ノード５１０からより効率的にコンテンツ５７０を取得できると判定することができる。加えて、ソースノード５０６は、委譲のために２つの機構を使用することができる。第１の方法では、ソースノード５０６は、別のソースノードとして受信ノード５１０を提供することができ、受信ノード５０８は、それをソースノードとみなして受信ノード５１０からコンテンツ５７０を要求する。

第２の方法では、ソースノード５０６は、既にダウンロードされたコンテンツ５７０を有する各受信ノードのために、スコアボードを維持することができる。例えば、ソースノード５０６は、受信ノード５１０のためのスコアボード５１１を維持することができる。ソースノード５０６は、受信ノード５０８を受信ノード５１０のデータチャネルにリダイレクトするトークン及びデータチャネル識別子を発行することができる。その場合、ソースノード５０６及び受信ノード５０８は、暗号鍵を共有して、リダイレクションを認証することができる。ソースノード５０６は、ＯＡｕｔｈ２．０などの既存のプロトコルを使用してもよく、又はソースノード５０６及び受信ノード５０８は、鍵について合意してもよい。

動作中、受信ノード５１０は、コンテンツ５７０の転送の完了に関してソースノード５０６に通知することができる（動作５５２）。これにより、ソースノード５０６は、受信ノード５１０のためのスコアボード５１１を作成することができる（動作５５４）。受信ノード５０８がトークンを提出すると（動作５３４）、ソースノード５０６は、新しいトークンを有する受信ノード５１０へのコンテンツ５７０の配信の委譲に関して受信ノード５０８に通知することができる（動作５５６）。受信ノード５０８は、新しいトークンを受信デバイス５１０に提出することができる（動作５５８）。トークンを検証すると、受信デバイス５１０は、そのデータチャネルを受信デバイス５０８に割り当てることができる（動作５６０）。受信ノード５０８は、受信ノード５１０から割り当てられたデータチャネルを介してコンテンツ５７０を取得することができる（動作５６２）。

これらの動作を促進するために、ソースノード５０６は、全ての要求が現在のプロデューサー時間を有するように、タイムサービスを実行することができる。あるいは、受信ノード５０８は、ソースノード５０６の時間を要求することができる。これにより、受信ノード５０８は、ソースノード５０６及び受信ノード５０８が同期クロックを有さない場合であっても、トークンをソースノード５０６のクロックに同期させることが可能になる。受信ノード５０８は、発振器間のクロックスキューを判定するために、特定の時間間隔でソースノード５０６の時間を要求するなどの、より高度なクロック同期機構を使用することができる。これは、これらのノードが将来の時間を正確に導出することを可能にする。これらの機構は、各ソースノードの仮想時間（又は発振器）を使用し、実際のオペレーティングシステム時間又はハードウェアクロックをリセットする必要はない。要求が受信ノード５１０に委譲された場合、受信ノード５１０は、ソースノード５０６に対応する仮想クロックを保持することができる。これにより、受信ノード５１０は、ソースノード５０６のクロックでトークンを認可することを可能にする。

図６Ａは、本出願の一実施形態に係る、コンテンツを受信ノードに提供するソースノードの方法を示すフロー図６００を提示する。動作中、ソースノードは、コンテンツに対するチャネル要求を受信し、スコアボードをチェックしてオプションを判定する（動作６０２）。ソースノードは、要求を受け入れるかどうかを判定する（動作６０４）。受け入れられた場合、ソースノードは受入型を判定する（動作６０６）。受入が即時である場合、ソースノードは、即時配信のためにトークンを発行することができる（動作６０８）。受入が保留である場合、ソースノードは、保留したタイムラインのための保留した配信のトークンを発行することができる（動作６１０）。

トークンを発行すると（動作６０８又は６１０）、ソースノードはトークン提出を受信することができる（動作６１２）。ソースデバイスは、要求を委譲するかどうかを決定することができる（動作６１４）。受入型が委譲（動作６０６）であるか、又はソースデバイスがトークン提出を委譲した場合（動作６１４）、ソースノードは、委譲ノードの新しいトークンを発行することができる（動作６１６）。ソースデバイスがトークン提出を委譲していない場合（動作６１４）、ソースノードは、チャネル（及び新しいトークン）を受信ノードに割り当て、（例えば、新しいトークンに基づいて）コンテンツに対する要求を受信し、配信を開始する（動作６１８）。要求が受け入れられていない場合（動作６０４）、ソースノードは、受信ノードへの拒絶を発行する（動作６２０）。

図６Ｂは、本出願の一実施形態に係る、ソースノードからコンテンツを取得する受信ノードの方法を示すフロー図６３０を提示する。動作中、受信ノードは、コンテンツの要求をソースノードのセットに送信し（動作６３２）、受信したトークンに基づいて要求を受け入れたソースノードのサブセットを判定する（動作６３４）。受信ノードはトークンを分析して、効率的な提供を有するソースノードを選択し（動作６３６）、選択されたソースノードに受入を通知し、サブセット内の他の全てのノードを拒絶で通知する（動作６３８）。次に、受信ノードは、トークン型を判定する（動作６４０）。

トークン型が保留である場合、受信ノードは、トークンに基づいて保留期間だけ待機する（動作６４２）。トークン型が即時である場合（動作６４０）、又はその期間だけ待機すると（動作６４２）、受信ノードは、トークンに基づいてチャネル要求を選択されたソースノードに送信し（動作６４４）、それが新しい委譲トークンを受信したかどうかをチェックする（動作６４６）。受信ノードがチャネル識別子を受信し、対応するチャネル上のコンテンツ検索を開始する（動作６４８）。トークン型が委譲である（動作６４０）か、又は受信ノードが新しい委譲トークンを受信した場合（動作６４６）、受信ノードは、委譲ノードのチャネル識別子を受信し、トークン及びチャネル識別子に基づいてチャネル要求を委譲ノードに送信する（動作６５０）。

図６Ｃは、本出願の一実施形態に係る、コンテンツを受信ノードに提供する、委譲ノードの方法を示すフロー図６６０を提示する。動作中、別の受信ノードとし得る委譲ノードは、トークン及びチャネル識別子に基づいてチャネル要求を受信し（動作６６２）、トークンを検証して妥当性を判定する（動作６６４）。次いで、委譲ノードは、チャネル識別子に対応するチャネルを割り当てる（動作６６６）。次いで、委譲ノードは、コンテンツに対する要求を受信し、配信を開始する（動作６６８）。

図７は、本出願の一実施形態に係る、企業環境における効率的なコンテンツ配信を促進する例示的なコンピュータシステムを示す。コンピュータシステム７００は、プロセッサ７０２、メモリデバイス７０４、及び記憶デバイス７０８を含む。メモリデバイス７０４は、揮発性メモリデバイス（例えば、デュアルインラインメモリモジュール（ｄｕａｌ ｉｎ−ｌｉｎｅ ｍｅｍｏｒｙ ｍｏｄｕｌｅ、ＤＩＭＭ））を含むことができる。更に、コンピュータシステム７００は、ディスプレイデバイス７１０、キーボード７１２、及びポインティングデバイス７１４に結合することができる。記憶デバイス７０８は、オペレーティングシステム７１６、コンテンツ配信システム７１８、及びデータ７３６を記憶することができる。コンテンツ配信システム７１８は、コントローラ１４０、ソースデバイス１０２、グループヘッド１０４、１０６、１０８、１４４、及び１４６、ソースデバイス５０６、並びに受信デバイス５０８及び５１０のうちの１つ以上の動作を促進することができる。

コンテンツ配信システム７１８は、コンピュータシステム７００によって実行されると、コンピュータシステム７００に、本開示で説明される方法及び／又はプロセスを実行させることができる命令を含むことができる。具体的には、コンテンツ配信システム７１８は、ノードデータベース（登録モジュール７２０）内の企業環境内の現在のデバイス及びサブネットのセットの情報を維持するための命令を含むことができる。コンテンツ配信システム７１８はまた、測定値に基づいて、企業環境のトポグラフィ情報を発見するための命令を含むことができる（測定モジュール７２２）。更に、コンテンツ配信システム７１８はまた、グループ間配信ツリー及びグループ内配信ツリー（プランナー及び転送モジュール７２４）に基づいて、企業環境内のコンテンツの配信を計画するための命令を含むことができる。

更に、コンテンツ配信システム７１８はまた、これらのツリーを介してコンテンツを配信するための命令（プランナー及び転送モジュール７２４）を含むことができる。コンテンツ配信システム７１８は、コンテンツ（トークンモジュール７２６）を配信するための即時、保留、又は委譲されたトークンを生成するための命令を含むことができる。コンテンツ配信システム７１８は、トークンに基づいてチャネルを割り当てるための命令を更に含むことができる（チャネルモジュール７２８）。コンテンツ配信システム７１８は、メッセージを送信及び受信するための命令（通信モジュール７３０）を更に含んでもよい。データ７３６は、コンテンツ配信システム７１８の動作を促進することができる任意のデータを含み得る。

図８は、本出願の一実施形態に係る、企業環境における効率的なコンテンツ配信を促進する例示的な装置を示す。コンテンツ配信装置８００は、有線、無線、量子光、又は電気通信チャネルを介して互いに通信し得る複数のユニット又は装置を含むことができる。装置８００は、１つ以上の集積回路を使用して実現することができ、図８に示されるものよりも少ない又はより多くのユニット又は装置を含んでもよい。更に、装置８００は、コンピュータシステムに統合されてもよく、又は他のコンピュータシステム及び／又はデバイスと通信することができる別個のデバイスとして実現されてもよい。具体的には、装置８００は、図７のコンピュータシステム７００のモジュール７２０〜７３０と同様の機能又は動作を実行するユニット８０２〜８１２を含むことができ、登録ユニット８０２、測定ユニット８０４、プランナー及び転送ユニット８０６、トークンユニット８０８、チャネルユニット８１０、及び通信ユニット８１２を含む。

本発明を実施するための形態で説明されるデータ構造及びコードは、通常、コンピュータ可読記憶媒体に記憶され、コンピュータシステムによって使用されるコード及び／又はデータを記憶することができる任意のデバイス又は媒体であってもよい。コンピュータ可読記憶媒体としては、揮発性メモリ、不揮発性メモリ、ディスク、磁気テープ、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル多用途ディスク若しくはデジタルビデオディスク）などの磁気及び光学記憶デバイス、又は現在知られている又は今後開発されるコンピュータ可読媒体を記憶することができる他の媒体が挙げられるが、これらに限定されない。

詳細な説明セクションに記載される方法及びプロセスは、上記のようにコンピュータ可読記憶媒体に記憶され得るコード及び／又はデータとして具現化することができる。コンピュータシステムが、コンピュータ可読記憶媒体上に記憶されたコード及び／又はデータを読み取り、実行するとき、コンピュータシステムは、データ構造及びコードとして具現化され、コンピュータ可読記憶媒体内に記憶された方法及びプロセスを実行する。

更に、上述の方法及びプロセスは、ハードウェアモジュールに含めることができる。例えば、ハードウェアモジュールとしては、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、ＡＳＩＣ）チップ、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ−ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、ＦＰＧＡ）、及び現在知られている又は今後開発される他のプログラム可能論理デバイスを含むことができるが、これらに限定されない。ハードウェアモジュールが起動されると、ハードウェアモジュールは、ハードウェアモジュール内に含まれる方法及びプロセスを実行する。

Claims (20)

1. 企業環境における動的コンテンツ配信を促進するための方法であって、
   前記企業環境のコントローラによって、前記企業環境のトポグラフィ情報を判定することと、
   前記トポグラフィ情報に基づいて論理グループのセットを判定することであって、それぞれの論理グループが、前記コントローラによって管理される１つ以上のデバイスと、前記１つ以上のデバイスを結合するネットワークと、を含む、判定することと、
   第１の配信ツリーを介してコンテンツの配信計画を生成することであって、前記第１の配信ツリーのそれぞれのノードが、前記論理グループのセットの論理グループに対応し、前記コンテンツをホストする論理グループが、前記第１の配信ツリーのルートノードに対応する、生成することと、
   前記配信計画を含む通知メッセージを、前記論理グループのセットのそれぞれの論理グループに送信することと、を含む、方法。
2. 前記配信計画は、受信デバイスが前記コンテンツをいつ要求できるかを示すタイムラインを更に含む、請求項１に記載の方法。
3. 前記コンテンツが、前記コントローラによって管理される前記１つ以上のデバイスのファームウェア更新である、請求項１に記載の方法。
4. 前記論理グループのセットのそれぞれの論理グループのための１つ以上のグループヘッドを選択することを更に含み、第１の論理グループと第２の論理グループとの間のグループ間接続が、前記第１及び第２の論理グループの前記それぞれのグループヘッド間に形成されている、請求項１に記載の方法。
5. 前記第１の論理グループが、第１のグループヘッド及び第２のグループヘッドを含み、前記コンテンツが、固有のブロックのセットに分割され、前記第１のグループヘッドが、前記第１の配信ツリーの上流ノードから前記固有ブロックのセットの第１のサブセットと、前記第２のグループヘッドから前記固有ブロックのセットの第２のサブセットとを取得する、請求項４に記載の方法。
6. 前記第１の論理グループ内の第２の配信ツリーを判定することを更に含み、前記第２の配信ツリーが、前記コンテンツのそれぞれの受信ノードにわたっており、前記第１及び第２のグループヘッドが、前記第２の配信ツリーの最上位にある、請求項４に記載の方法。
7. 前記トポグラフィ情報を判定することが、メッセージキュー（ＭＱ）ベースのメッセージ交換を使用することによって、
   前記企業環境の１つ以上のデバイスのデバイス情報と、
   前記企業環境におけるそれぞれのリンクの帯域幅と、のうちの１つ以上を判定することを含む、請求項１に記載の方法。
8. 企業環境における動的コンテンツ配信を促進するための方法であって、
   前記企業環境のソースデバイスによって、ローカル記憶デバイス内にコンテンツを記憶することと、
   第１の受信デバイスから前記コンテンツに対する要求を受信することと、
   前記ソースデバイスの現在及び割り当てられたタスクを示すスコアボードに基づいて、前記ソースデバイスの作業負荷を判定することと、
   前記ソースデバイスの前記作業負荷に基づいて、前記第１の受信デバイスに対して、即時受入、保留受入、委譲、及び拒絶を含むオプションのセットから応答オプションを選択することと、を含む、方法。
9. 前記応答オプションとして前記保留受入を選択することに応答して、前記方法が、
   前記ソースデバイスの鍵によって認証され、前記第１の受信デバイスのための時間窓で発行された第１のトークンを発行することと、
   前記第１のトークンを受信することに応答して、チャネルを識別するチャネル識別子を割り当てることであって、前記チャネルを介して、前記第１の受信デバイスが前記ソースデバイスから前記コンテンツを取得することができる、割り当てることと、を更に含む、請求項８に記載の方法。
10. 前記応答オプションとして前記委譲を選択することに応答して、前記方法が、
    第２の受信デバイスが前記コンテンツを取得したことを判定することと、
    前記第１の受信ノードのための時間窓で発行された前記第２の受信ノードの鍵によって認証される第２のトークンを発行することと、
    チャネルを識別するチャネル識別子を割り当てることであって、前記チャネルを介して、前記第１の受信デバイスが前記第２の受信デバイスから前記コンテンツを取得することができる、割り当てることと、を更に含む、請求項８に記載の方法。
11. 命令を記憶する非一時的コンピュータ可読記憶媒体であって、前記命令が、コンピュータによって実行されると、前記コンピュータに、企業環境における動的コンテンツ配信を促進するための方法を実行させ、前記方法が、
    前記企業環境のコントローラによって、前記企業環境のトポグラフィ情報を判定することと、
    前記トポグラフィ情報に基づいて論理グループのセットを判定することであって、それぞれの論理グループが、前記コントローラによって管理される１つ以上のデバイスと、前記１つ以上のデバイスを結合するネットワークと、を含む、判定することと、
    第１の配信ツリーを介してコンテンツの配信計画を生成することであって、前記第１の配信ツリーのそれぞれのノードが、前記論理グループのセットの論理グループに対応し、前記コンテンツをホストする論理グループが、前記第１の配信ツリーのルートノードに対応する、生成することと、
    前記配信計画を含む通知メッセージを、前記論理グループのセットのそれぞれの論理グループに送信することと、を含む、コンピュータ可読記憶媒体。
12. 前記配信計画は、受信デバイスが前記コンテンツをいつ要求できるかを示すタイムラインを更に含む、請求項１１に記載のコンピュータ可読記憶媒体。
13. 前記コンテンツが、前記コントローラによって管理される前記１つ以上のデバイスのファームウェア更新である、請求項１１に記載のコンピュータ可読記憶媒体。
14. 前記方法が、前記論理グループのセットのそれぞれの論理グループのための１つ以上のグループヘッドを選択することを更に含み、第１の論理グループと第２の論理グループとの間のグループ間接続が、前記第１及び第２の論理グループの前記それぞれのグループヘッド間に形成されている、請求項１１に記載のコンピュータ可読記憶媒体。
15. 前記第１の論理グループが、第１のグループヘッド及び第２のグループヘッドを含み、前記コンテンツが、固有のブロックのセットに分割され、前記第１のグループヘッドが、前記第１の配信ツリーの上流ノードから前記固有のブロックのセットの第１のサブセットと、前記第２のグループヘッドから前記固有のブロックのセットの第２のサブセットとを取得する、請求項１４に記載のコンピュータ可読記憶媒体。
16. 前記方法が、前記第１の論理グループ内の第２の配信ツリーを判定することを更に含み、前記第２の配信ツリーが、前記コンテンツのそれぞれの受信ノードにわたっており、前記第１及び第２のグループヘッドが、前記第２の配信ツリーの最上位にある、請求項１４に記載のコンピュータ可読記憶媒体。
17. 前記トポグラフィ情報を判定することが、メッセージキュー（ＭＱ）ベースのメッセージ交換を使用することによって、
    前記企業環境の１つ以上のデバイスのデバイス情報と、
    前記企業環境におけるそれぞれのリンクの帯域幅と、のうちの１つ以上を判定することを含む、請求項１１に記載のコンピュータ可読記憶媒体。
18. 命令を記憶する非一時的コンピュータ可読記憶媒体であって、前記命令が、コンピュータによって実行されると、前記コンピュータに、企業環境における動的コンテンツ配信を促進するための方法を実行させ、前記方法が、
    前記企業環境のソースデバイスによって、ローカル記憶デバイス内にコンテンツを記憶することと、
    第１の受信デバイスから前記コンテンツに対する要求を受信することと、
    前記ソースデバイスの現在及び割り当てられたタスクを示すスコアボードに基づいて、前記ソースデバイスの作業負荷を判定することと、
    前記ソースデバイスの前記作業負荷に基づいて、前記第１の受信デバイスに対して、即時受入、保留受入、委譲、及び拒絶を含むオプションのセットから応答オプションを選択することと、を含む、コンピュータ可読記憶媒体。
19. 前記応答オプションとして前記保留受入を選択することに応答して、前記方法が、
    前記ソースデバイスの鍵によって認証され、前記第１の受信デバイスのための時間窓で発行された第１のトークンを発行することと、
    前記トークンを受信することに応答して、チャネルを識別するチャネル識別子を割り当てることであって、前記チャネルを介して、前記第１の受信デバイスが前記ソースデバイスから前記コンテンツを取得することができる、割り当てることと、を更に含む、請求項１８に記載のコンピュータ可読記憶媒体。
20. 前記応答オプションとして前記委譲を選択することに応答して、前記方法が、
    第２の受信デバイスが前記コンテンツを取得したことを判定することと、
    前記第１の受信ノードのための時間窓で発行された前記第２の受信ノードの鍵によって認証される第２のトークンを発行することと、
    チャネルを識別するチャネル識別子を割り当てることであって、前記チャネルを介して、前記第１の受信デバイスが前記第２の受信デバイスから前記コンテンツを取得することができる、割り当てることと、を更に含む、請求項１８に記載のコンピュータ可読記憶媒体。

Images