JP2013512487A - 記述ファイルに基づいた個別データ通信 - Google Patents

Abstract

少なくとも第１の受信者及び第２の受信者へのデータ・エンティティ（２００）の個別データ通信のために、プレイスホルダ種別の少なくとも１つの識別子により補足される記述ファイル（１００）が提供される。記述ファイル（１００）はまた、データ・エンティティ（２００）の対応するデータ・ピース（２１０）に関連している、ダイレクト種別の少なくとも１つの識別子を含む。プレイスホルダ種別の識別子は同様に、個別データ・ピース（２２０）の記述データ（１２０）に関連している。様々な受信者に対して様々な種別の記述データ（１２０）を提供することにより、プレイスホルダ種別の識別子は、個別データ・ピース（２２０）における様々な種別の個人向けコンテンツへの参照として用いられ得る。この個別化は、記述ファイル（１００）の識別子領域（１１０）を修正することなく得ることができる。

Description

本発明は、記述ファイルに基づいたデータの個別通信のための技術に関する。

データ、例えば、マルチメディア・コンテンツのデジタル配信は、近年ますます注目を集める様になっている。この点において、メタファイルとも呼ばれる記述ファイルに基づいてデータを配信することが知られている。その様な記述ファイルの例は、例えば、ビットトレント・プロトコルで使用されるトレント・ファイルや、ＨＴＴＰライブ・ストリーミング・プロトコルで使用されるプレイリスト・ファイルである。通常、データの受信者は、データを得るための基盤として記述ファイル内の情報を用いるであろう。その様な情報は、受信されるべきデータのピースと一意的に関連する識別子である場合がある。データの実際の受信は、例えば、ピア・ツー・ピア（Ｐ２Ｐ）プロトコルにより、様々な情報源から生じるかもしれない。Ｐ２Ｐプロトコルの一例は、上述したビットトレント・プロトコルである。

Ｐ２Ｐプロトコルにおいて、コンテンツは、Ｐ２Ｐネットワークの構成員である総てのユーザ間で共有される。この目的のために、記述ファイルは、ネットワーク内で利用できるあらゆるコンテンツ・アイテムに対して存在する。この点において、"利用できる"というのは、ピアとも呼ばれる、ネットワークの少なくとも一人のメンバが、このコンテンツ・アイテムを提供しているということを意味する。記述ファイルでは、コンテンツ・アイテムの小さなピースにアドレスが付与される。ユーザがあるコンテンツ・アイテムを要求する場合、これらのピースが、ネットワークの様々なメンバから供給される可能性がある。これは、コンテンツ・アイテムの受信者が、コンテンツ・アイテムが完全に受信されるまでずっとオンラインである様に、ピースを提供する幾人かのピアに頼る必要がないという長所を有する。あらゆるピースは、最も相応しい場所から、例えば、低遅延でビット速度の高いデータ・コネクションがある場所から供給され得る。

周知のＰ２Ｐ技術によると、コンテンツ・アイテムの記述ファイルは、様々なピースのハッシュ値を含む。様々なピースに関する個々のハッシュ値は、受信時にピースを識別するのに用いられる。さらに、記述ファイルには、これらの個々のハッシュ値に基づいて得られるハッシュ値がある。後者のハッシュ値は、コンテンツ・アイテムを一意的に識別するために、そして、記述ファイルの完全性を検証するために、シグネチャとして用いられる場合がある。それ故、コンテンツ・アイテムの１つのピースを修正する場合、対応する個別のハッシュ値と、個々のハッシュ値に基づいて計算されるハッシュ値も変わるであろう。したがって、コンテンツ・アイテムの１つのピースのみが修正されると、個々のハッシュ値から計算されるハッシュ値は、異なるコンテンツ・アイテムを参照すると解釈され得る。例えば、少年向けの広告を含む動画形式のコンテンツ・アイテムは、中年の婦人向けの広告のある同じ動画とは異なるシグネチャを有するであろう。結果、動画の各個別版は、別の記憶を必要とする完全に別のコンテンツと考えられる。換言すると、個別版の双方で同じであるコンテンツ・アイテムのピースでさえ、別々に提供しなければならない。

したがって、個別のデータを様々な受信者に効率よく伝えることを可能にする技術が必要である。

本発明の一実施形態によると、記述ファイルに基づいて少なくとも第１の受信者及び第２の受信者にデータ・エンティティを伝える方法が提供される。記述ファイルは、データ・エンティティの対応するデータ・ピースに関連するダイレクト種別の少なくとも１つの識別子を含む。本方法は、プレイスホルダ種別の識別子を記述ファイルに追加するステップを含む。プレイスホルダ種別の識別子は、個別データ・ピースの記述データに関連する。第１の種別の記述データは、第１の受信者に提供され、第２の種別の記述データは、第２の受信者に提供される。第１の種別の記述データは、第２の種別の記述データとは異なる。

本発明の更なる実施形態によると、記述ファイルに基づいて少なくとも第１の受信者及び第２の受信者にデータ・エンティティを伝える方法が提供される。記述ファイルは、データ・エンティティの対応するデータ・ピースに関連するダイレクト種別の少なくとも１つの識別子と、個別データ・ピースの記述データに関連するプレイスホルダ種別の識別子と、を含んでいる。本方法は、第１の種別の記述データを第１の受信者に提供するステップと、第２の種別の記述データを第２の受信者に提供するステップと、を含んでいる。第１の種別の記述データは、第２の種別の記述データとは異なる。

本発明の更なる実施形態によると、記述ファイルに基づいてデータ・エンティティを伝える方法が提供される。記述ファイルは、少なくとも１つの識別子を有する。識別子は、データ・エンティティの対応するデータ・ピースに関連するダイレクト種別か、個別データ・ピースの記述データに関連するプレイスホルダ種別のいずれかであり得る。本方法はさらに、識別子がプレイスホルダ種別のものであると、個別データ・ピースの関連する記述データを読み出すステップと、読み出した記述データに基づいて個別データ・ピースを読み出すステップと、を含んでいる。

本発明の更なる実施形態によると、デバイスが提供される。本デバイスは、プレイスホルダ種別の識別子を記述ファイルに追加する上記ステップを実行する様に構成され、及び／又は、第１の種別の記述データを第１の受信者に提供し、第２の種別の記述データを第２の受信者に提供する上記ステップを遂行する様に構成された個別ロジックを備えている。

本発明の更なる実施形態によると、デバイスが提供される。本デバイスは、データを受信する上述した方法のステップを実行する様に構成されたプレイスホルダ・ロジックを備えている。

本発明の実施形態で用いられる、個別のデータ・ピースと共に提供されるデータ・エンティティと、データ・エンティティの記述ファイルの構造を示す図。 本発明の実施形態によるデータの個別通信のためのシステムのブロック図。 本発明の実施形態によるデータの個別通信のための更なるシステムのブロック図。 本発明の実施形態による概念が適用され得るネットワーク環境を示す図。 本発明の実施形態によるネットワーク・デバイスを示す図。 本発明の実施形態による受信デバイスを示す図。 本発明の実施形態による方法を示すフロー図。 本発明の実施形態による更なる方法を示すフロー図。 記述ファイルの例を示す図。 記述ファイルの例を示す図。 本発明の実施形態による記述ファイルの例を示す図。 本発明の実施形態による処理を示すフロー図。 本発明の実施形態による更なる処理を示すフロー図。

以下では、例示的な実施形態及び添付図面を参照することにより、本発明についてより詳細に説明することとする。図に示す実施形態は、様々な受信者にデータ・エンティティを個別に伝えるための技術に関する。データ・エンティティは、様々な種別のコンテンツを含み得る。例えば、データ・エンティティは、広告又は番外のシーン、例えば、マルチメディア・コンテンツ拡張版の検閲されたシーン又はそのままのシーンにより、個別化されているマルチメディア・コンテンツを含み得る。別の例によると、データ・エンティティは、個別のモジュール、例えば様々な言語モジュールを含むソフトウェアを含み得る。本明細書で説明する技術は、様々な種別の通信ネットワークに、例えば３ＧＰＰ（第３世代パートナーシップ・プロジェクト）技術仕様書による移動通信ネットワークに適用される可能性がある。本技術はまた、有線ネットワークに、例えばインターネット・プロバイダにより適用される可能性がある。以下の記述は、データを伝えるためのＰ２Ｐプロトコルの一例として、ビットトレント・プロトコルを用いる例に、多かれ少なかれ焦点を当てるであろう。しかし、本明細書で説明する概念はまた、他の通信プロトコル、例えば記述ファイルに基づくストリーミング・プロトコルの一例として、ＨＴＴＰライブ・ストリーミング・プロトコルに適用される可能性がある。

図１は、本発明の実施形態による個別化されたデータ・エンティティ２００の構造を示している。さらに、図１はまた、本発明の実施形態で使用する記述ファイル１００の構造を示している。

図に示す様に、データ・エンティティ２００は、複数のデータ・ピース２１０に分割されている。データ・ピース２１０は、データ・エンティティ２００を形成するために、所与の順序で一緒に連結され得る。例えば、データ・エンティティ２００が、マルチメディア・コンテンツ、例えば、オーディオ・データ及び／又はビデオ・データを含むと、データ・ピース２１０は、マルチメディア・コンテンツが再生される順序で配置され得る。実施形態によると、データ・ピース２１０は、メディア・ファイルのピース、又は、個々のメディア・ファイルである場合がある。図１では、データ・ピース２１０の順序は、番号＃Ｘ、番号＃Ｘ＋１、番号＃Ｘ＋２により示されている。この所与の順序によると、データ・ピース２１０は、データ・エンティティ２００を形成するために、番号が＃Ｘのデータ・ピース２１０の後に番号が＃Ｘ＋１のデータ・ピース２１０を置くことにより、そして番号が＃Ｘ＋１のデータ・ピース２１０の後に番号が＃Ｘ＋２のデータ・ピース２１０のセグメントを置くことにより、一緒に連結されるであろう。

さらに図１に示す様に、データ・エンティティ２００は、様々な受信者により受信されるデータ・エンティティ２００に含まれる個別のデータ・ピース２２０を提供することにより個別化されている。第１の種別の個別データ・ピース２２０は、第１の受信者（受信者１）に提供され、第２の種別の個別データ・ピース２２０は、第２の受信者（受信者２）に提供される。この点において、第１の受信者及び第２の受信者は、例えば物理的に別の受信デバイスで、データを受信する異なるクライアントに対応するものと理解される。しかしながら、第１の受信者及び第２の受信者はまた、異なる時間に受信する、同一のクライアントに対応する可能性もある。第１の種別及び第２の種別の個別データ・ピース２２０では、コンテンツが異なる。したがって、第１の受信者及び第２の受信者により受信されるデータ・エンティティ２００は、それぞれの種別の個別データ・ピース２２０を含めることにより、個別化され得る。この点において、３人以上の受信者に関して個別化する様に、３つ以上の異なる種別の個別データ・ピース２２０を提供することもできることが理解される。さらに、データ・エンティティ２００は、２つ以上の個別データ・ピースを含み得る。また、当然のことながら、第１の受信者及び第２の受信者は各々、同じ種別の個別のコンテンツを受信しようとしている受信者のグループを代表する場合がある。その上、個別データ・ピース２２０は、データ・エンティティ２００のデータ・ピース２１０間の所定の位置に挿入されるか、データ・ピース２１０の所与の１つを取り替えられ得る。

記述ファイル１００は、クライアントがデータ・ピース２１０の受信を制御できる様にするために提供される。この目的のために、記述ファイル１００は、識別子セクション１１０を含む。識別子セクション１１０は、データ・エンティティ２００のデータ・ピース２１０の各々に対応する識別子を含む。図示する例では、番号が＃Ｘの識別子は、番号＃Ｘのデータ・ピース２１０に対応し、番号＃Ｘ＋１の識別子は、番号＃Ｘ＋１のデータ・ピース２１０に対応し、番号＃Ｘ＋２の識別子は、番号＃Ｘ＋２のデータ・ピース２１０に対応する。これらの識別子は、データ・ピース２１０を直接識別するのに用いられる場合がある。換言すると、データ・ピース２１０と対応する識別子との間には１対１の関係がある。これらの識別子はしたがって、またダイレクト種別の識別子と呼ばれる場合がある。

さらに図示する様に、記述ファイル１００の識別子セクション１１０は、プレイスホルダ種別（"ＰＬＡＣＥＨＯＬＤＥＲ"と表示）の更なる識別子を含んでいる。プレイスホルダ種別の識別子は、個別データ・ピース２２０の記述データ１２０に関連している。記述データ１２０は、第１の種別か、第２の種別である。第１の種別の記述データ１２０は、第１の受信者に対応し、第１の受信者に提供される第１の種別の個別データ・ピース２２０を参照する。第２の種別の記述データ１２０は、第２の受信者に対応し、第２の種別の個別データ・ピース２２０を参照する。ここでも、当然のことながら、更なる受信者に関して個別化するために、更なる種別の記述データ１２０が提供される可能性がある。データ・ピース２１０と１対１の関係がある、ダイレクト種別の識別子に比べて、プレイスホルダ種別の識別子は、様々な形式であり得る記述データ１２０を参照する。したがって、プレイスホルダ種別の識別子は、データ・エンティティ２００を受信する特定の受信者に依存する、様々な種別の個別データ・ピースを識別することを可能にする。しかしながら、記述ファイル１００の識別子セクション１１０は、この個別化により変更されない。

実施形態によると、ダイレクト種別の識別子は、対応するデータ・ピース２１０のシグネチャ、例えばハッシュ値であり得る。例えば、データ通信がビットトレント・プロトコルに基づくと、記述ファイル１００は、ビットトレント・プロトコルによるトレント・ファイルである場合があり、識別子セクション１１０は、トレント・ファイルの"情報"セクションであり得る。このシナリオでは、ダイレクト種別の識別子は、各々、対応するデータ・ピース２１０のハッシュ値、例えば、セキュア・ハッシュ・アルゴリズム１（ＳＨＡ１）により計算されるハッシュ値であり得る。別のシナリオでは、データ通信は、ファイル・ストリーミング・プロトコル、例えば、ＨＴＴＰライブ・ストリーミング・プロトコルに基づき得る。このシナリオでは、記述ファイル１００は、ＨＴＴＰライブ・ストリーミング・プロトコルによるプレイリスト・ファイルであり、識別子セクション１１０は、統一資源識別子（ＵＲＩｓ）のリストであり得る。

プレイスホルダ種別の識別子は、記述データ１２０を所定の場所に格納することにより、記述データ１２０に関連する場合がある。例えば、記述データ１２０は、記述ファイル１００内の所定の位置で、識別子セクション１１０以外に格納される場合がある。他の例によると、他の所定の位置、例えば、追加ファイル、統一資源位置指定子により識別される所定のネットワーク位置、受信デバイス内の所定の記憶位置等が用いられる場合がある。

プレイスホルダ種別の識別子は、ダイレクト種別の識別子と同じフォーマットである可能性がある。例えば、ダイレクト種別の識別子が所与の長さ、例えば２０バイトのハッシュ値であると、その場合、プレイスホルダ種別の識別子は、同じ長さの値である場合がある。例によると、プレイスホルダ種別の識別子は、ダミー・シグネチャ、例えば、語句"ｅｒｉｃｓｓｏｎ ａｄｓ Ｐ２Ｐ ｓｏｌｕｔｉｏｎ"のＳＨＡ１ハッシュ値、［４ｄ６２２ｃａｄ７ｂａ５３２ｅ８ｄｅｆｅ３ｄ６０ｅ２ｂｆ７５ａ２ｅ２ｆ３６９ｃ］として計算される場合がある。さらなる例によると、プレイスホルダ種別の識別子は、配信情報源のダミーの識別子、例えばダミーＵＲＩである場合があり、ダミーＵＲＩでは、ある部分、例えばスキーム部分が、例えば、表示子"ダミー"又は同様なものを含めることにより、識別子のダミー文字を示す。プレイスホルダ種別の識別子に関連する記述データ１２０は、対象とする受信者に対応する特定の種別の個別のデータ・ピース２２０と１対１の関係があるダイレクト種別の識別子を含む場合がある。例えば、記述データ１２０は、特定の種別の個別データ・ピース２２０のシグネチャを含む場合がある。別の例によると、記述データ１２０は、特定の種別の個別データ・ピース２２０のＵＲＩを含む場合がある。記述データ１２０は、また、特定の種別の個別データ・ピース２２０についての補足情報、例えば、特定の種別の個別データ・ピース２２０の大きさを提供する場合がある。実施形態によると、記述データ１２０に大きさを含めることは、そうでなければ均一サイズのデータ・ピース２１０を用いるプロトコル、例えばビットトレント・プロトコルにおいて、任意の大きさのデータ・ピースをサポートするのに用いられる場合がある。

上で説明した概念によると、追加される任意の個別部分、例えば個別データ・ピース２２０に拘らず、コンテンツ・アイテム、すなわちデータ・エンティティ２００を一意的に識別する問題に対する解決策が提供される。これは、記述ファイル、例えば記述ファイル１００を用いることにより達成され、記述ファイルは、データ・エンティティ２００のデータ・ピース２１０と１対１の関係があるダイレクト種別の識別子と、記述ファイル１００内で個別コンテンツに対応する位置に含まれ得るプレイスホルダ種別の少なくとも１つの識別子とを含んでいる。Ｐ２Ｐシナリオでは、例えば、ビットトレント・プロトコルに基づいて、ダイレクト種別の識別子は、主要なコンテンツの、すなわちデータ・エンティティ２００のデータ・ピース２１０のハッシュであるであろうし、プレイスホルダ種別の識別子は、個別部分が存在するべきであると思われる所に提供される。したがって、ダイレクト種別の識別子及びプレイスホルダ種別の１つ以上の識別子を含む記述ファイルの部分は、同じシグネチャを有するであろう。記述ファイルは、ビットトレント・プロトコルによるトレント・ファイルである場合があり、上述した方法で、すなわちプレイスホルダ種別の少なくとも１つの識別子を導入することにより個別化され、ユーザ又は受信者に送り出される。ユーザ又は受信者は、その場合、主要なコンテンツ、すなわちデータ・エンティティ２００を形成するデータ・ピース２１０と、この受信者に対応する特定の種別の少なくとも１つの個別データ・ピース２２０だけを取り込むことができる。例えば、主要なコンテンツがマルチメディア・コンテンツであり、少なくとも１つの個別データ・ピース２２０が１つ以上の広告に対応するシナリオでは、特定の種別の少なくとも１つの個別データ・ピース２２０に関する情報は、記述データ１２０に含まれている場合があり、記述データ１２０は、記述ファイル１００内に、例えば、ビットトレント・プロトコルによるトレント・ファイル内に置かれる場合がある。したがって、ユーザは、記述ファイル又はトレント・ファイルに記述されているそれらの広告だけを取り込むことができる。

一部の実施形態によると、プレイスホルダ種別の識別子は、様々な個別データ・ピース２２０に対する参照として、記述ファイル１００内の様々な位置で用いられることもまた可能である。取り込まれるべき特定の種別の個別データ・ピース２２０はその場合、記述ファイル１００のプレイスホルダ種別の識別子の位置に依存することがある。さらに、プレイスホルダ種別の識別子が、データ・エンティティの、すなわち主要なコンテンツの１つ以上のデータ・ピース２１０に対する参照として、このデータ・ピース２１０を参照するのにダイレクト種別の識別子を用いるよりも、むしろ用いられる場合がある。このデータ・ピース２１０は、ランダムに選択される可能性がある。主要なコンテンツが、１つ以上の広告により個別化されるマルチメディア・コンテンツであるシナリオでは、主要なコンテンツのピースに対する参照として、プレイスホルダ種別の識別子の随時の使用が、広告をスキップし易くするのを回避するために用いられ得る。

以上、本概念が、例えば、ビットトレント・プロトコル又はＨＴＴＰライブ・ストリーミング・プロトコルによるデータ通信に適用できるものとして説明されている。しかしながら、当然のことながら、本概念は、例えば他のプロトコル又は他のアプリケーションに関連して、他の種別のデータ通信に適用される場合があり、他のアプリケーションでは、主要コンテンツ内の他のピース又はコンテンツを一体化する目的のために、主要なコンテンツがより小さい極小のピースに分けられたり、ピースがお互いにどの様に関連するかを記述する記述ファイルを用いたり、コンテンツの受信又は検証が記述ファイルの一部に基づいたりする。主要なマルチメディア・コンテンツに一体化されることになる広告は、一例に過ぎない。

図２は、本発明の実施形態による個別データ通信のためのシステムを概略説明するためのブロック図である。本システムは、図１に関連して説明した概念により動作できる。本システムは、任意の種別のデータ・エンティティ、例えば、図１に関連して説明したデータ・エンティティ２００を伝えるのに使用でき、データ・エンティティは、記述ファイル、例えば、メタファイル、マニフェスト・ファイル、トレント・ファイル等に記述されているデータ・ピース又はチャンクに基づいている。各データ・ピース又はチャンクは、１つのファイル、複数のファイル、又は、ファイルの一部から形成されていることがある。本システムは、主要コンテンツを付加的な個人向けコンテンツと共に様々な受信者に送信するのに使用できる。この点において、個人向けコンテンツは、同じ主要コンテンツの、総ての受信者に共通ではない個別データ・ピースと表現され得る。例えば、個人向けコンテンツは、図１に関連して説明した、少なくとも１つの個別データ・ピース２２０により表される場合がある。記述ファイルは、個人向けコンテンツに対する一般参照に用いられる、プレイスホルダ種別の識別子を含む。換言すると、プレイスホルダ種別の同じ識別子が、様々な種別の個人向けコンテンツに対する参照として使用され得る。

図示する様に、本システムは、クライアント５１０と、コンテンツ・プロバイダ５２０と、記述ファイル生成部５３０と、セレクタ５４０と、メタデータ・リポジトリ５５０と、アイテム・リポジトリ５６０と、を備えている。これらの構成要素は、様々な種別のデバイスに実装され得る。例えば、これらの構成要素の各々は、対応するネットワーク・デバイスに実装され得る。さらに、これらの構成要素の一部は、同じネットワーク・デバイス内に一体化され得る。さらに、クライアント５１０は、エンドユーザのデバイス内に、例えば通信ネットワークに接続する端末内に実装され得る。一例によると、クライアント５１０は、例えば、３ＧＰＰ技術仕様書による移動通信ネットワークに接続する様に構成された移動端末内に実装され得る。

本発明の実施形態によると、図２に示すシステムの動作は、以下のようである。クライアント５１０は、メッセージ５１をコンテンツ・プロバイダ５２０に送ることにより、主要コンテンツをコンテンツ・プロバイダ５２０に要求する。コンテンツ・プロバイダ５２０は、それから、メッセージ５２を送ることで記述ファイルを生成するために、記述ファイル生成部５３０をトリガできる。メッセージ５３を送ることにより、記述ファイル生成部５３０は、個人向けコンテンツ、例えば、図１に関連して説明した個別データ・ピース２２０に関する情報を、セレクタ５４０に要求する。メッセージ５４を送ることにより、セレクタ５４０は、個人向けコンテンツとして用いられることになるコンテンツ・アイテムのリストを、メタデータ・リポジトリ５５０に要求することができる。メッセージ５５を送ることにより、メタデータ・リポジトリ５５０は、利用可能なコンテンツ・アイテムのリストを応答する。その後、セレクタ５４０は、利用可能なコンテンツ・アイテムを様々な受信者又はユーザに対応付ける。これは、ユーザの好み、ユーザ・プロファイル、ユーザの関心又は他の基準により遂行され得る。一部の実施形態によると、セレクタ５４０は、個人向けコンテンツの１つ以上の識別子、例えば、図１に関連して説明した特定の種別の個別データ・ピース２２０の識別子を選択する。識別子は、シグネチャ、例えば、ハッシュ値又はＵＲＩ等の配信情報源の識別子であり得る。他の種別の識別子、例えばＵＲＬも同様に用いられる場合がある。一部の実施形態によると、セレクタはまた、識別子、例えばＵＲＩ又はハッシュ値のリストを選択し、そして識別子のリストで応答する場合があり、識別子は、同じ受信者又は同じグループの受信者のための様々な種別の個人向けコンテンツに関連する。このリストに基づいて、受信者は、様々な種別の個人向けコンテンツから選択することが可能になる。メッセージ５６を記述ファイル生成部５３０に送ることにより、セレクタ５４０は、個人向けコンテンツの１つ以上の選択した識別子を記述ファイル生成部５３０に送信する。

記述ファイル生成部は、セレクタ５４０からの入力に基づいて記述ファイルを生成する。記述ファイルは、主要コンテンツに関するダイレクト種別の識別子と、個人向けコンテンツに関するプレイスホルダ種別の少なくとも１つの識別子と、を含める様に生成される。ダイレクト種別の識別子とプレイスホルダ種別の少なくとも１つの識別子は、図１に関連して説明されたものであり得る。記述ファイル生成部５３０は、メッセージ５７を送ることによりクライアント５１０に記述ファイルを提供する。

クライアント５１０は、その後、１つ以上のメッセージ５８をアイテム・リポジトリ５６０に送ることにより、記述ファイルに基づいて主要コンテンツ及び個人向けコンテンツを読み出す。一部の実施形態では、これは、また、プレイスホルダ種別の識別子を送ることも含み得る。アイテム・リポジトリ５６０は、１つ以上のメッセージ５９を送ることにより、アイテム及び個人向けコンテンツで応答する。ここでは、当然のことながら、図２に示すアイテム・リポジトリ５６０は、単一の場所に実装することも、様々な場所にわたって分散して実装することもできる。例えば、主要コンテンツの様々なデータ・ピースは、様々な場所から提供され得る。

さらに、個人向けコンテンツの１つ以上の個別データ・ピースは、主要コンテンツとは異なる場所から提供でき、様々な個別データ・ピースは、様々な場所から提供され得る。コンテンツを読み出す場合、クライアント５１０は、記述ファイル内のプレイスホルダ種別の第ｎ番目の識別子を見つけると、セレクタ５４０から受信される、第ｎ番目の識別子、例えば、第ｎ番目のＵＲＩ又はハッシュ値に対応する個人向けコンテンツを要求し、そしてマルチメディア・コンテンツの場合には再生する。セレクタ５４０が個人向けコンテンツの複数の代替識別子を提供していると、クライアント５１０は、これらの代替識別子のうちの少なくとも１つを選択でき、対応する個人向けコンテンツを要求できる。

したがって、上で説明したシステムは、個人向けコンテンツに対する少なくとも１つのポインタを含む個人向け記述ファイルを提供する。このポインタは、図１に関連して説明した記述データ１２０の形態をしている場合があり、個人向けコンテンツに関する識別子、例えば、ハッシュ値又はＵＲＩを含む場合がある。一部の実施形態によると、記述ファイルは、また、個人向けコンテンツに対するポインタのリストを含む場合があり、クライアント５１０は、このリストのアイテムから選択できる。

図３は、本発明の更なる実施形態による個別データ通信のためのシステムを概略説明するブロック図である。ここでも、システムは、データ・エンティティ、例えば、データ・エンティティ２００を様々な受信者に伝えるために、プレイスホルダ種別の少なくとも１つの識別子を含む記述ファイルを使用することで、図１に関連して説明した概念により動作できる。図３のシステムの構成要素は、図２のそれらと同様である。図に示している様に、本システムは、クライアント６１０と、コンテンツ・プロバイダ６２０と、記述ファイル生成部６３０と、セレクタ６４０と、メタデータ・リポジトリ６５０と、アイテム・リポジトリ６６０と、を備えている。記述ファイルが、個人向けコンテンツに対する１つ以上のポインタを含めることにより個人向けになっていた、図２のシステムに比べて、図３のシステムは、各受信者にとって同様である包括的な記述ファイルに基づいて動作する様に構成されている。これは、図１に関連して説明したシナリオに対応しており、図１では記述データ１２０は記述ファイル１００とは別に提供されている。

１つの例によると、この包括的な記述ファイルは、個人向けコンテンツを得るべき場所、例えばＵＲＬへの参照を記述ファイルに含めることにより、実装され得る。様々な種別の個人向けコンテンツは、その後、個人向けコンテンツが要求される場合、クライアント６１０により提供されるカテゴリ識別子に基づいて、クライアント６１０に提供され得る。更なる例によると、記述ファイルは、個人向けコンテンツを得るべき場所、例えばＵＲＬを含む場合があり、クライアントは、特定の種別の個人向けコンテンツが提供される様に、適切な認証情報、例えば、クライアントのＭＡＣアドレス（ＭＡＣ：メディア・アクセス制御）又はユーザ名により識別され得る。したがって、特定の受信者と個人向けコンテンツとの間の対応付けは、クライアント６１０内に、例えばカテゴリ表示子の形態で、又は記述ファイル内の場所参照が参照する場所に、例えばカテゴリ識別子、ＭＡＣアドレス、ユーザ名、又は、特定の種別の個人向けコンテンツに対する他の認証情報との間の対応付けの形態で格納された情報により、記述ファイルとは別で実現され得る。

図３に示した本システムの動作は次のとおりである。クライアント６１０は、メッセージ６１をコンテンツ・プロバイダ６２０に送ることにより、主要コンテンツをコンテンツ・プロバイダ６２０に要求する。コンテンツ・プロバイダ６２０は、メッセージ６２を送ることにより記述ファイル生成部６３０をトリガする。記述ファイル生成部６３０は、個人向けコンテンツに対するプレイスホルダ種別の少なくとも１つの識別子を含む記述ファイルを生成する。さらに、記述ファイルは、また、主要コンテンツを参照するダイレクト種別の１つ以上の識別子を含むことができる。記述ファイル生成部６３０は、メッセージ６３を送ることにより、クライアント６１０に記述ファイルを提供する。

記述ファイルに基づいて、クライアント６１０は、主要コンテンツ及び個人向けコンテンツを要求する。これは、例えば、プレイスホルダ種別の識別子の位置により特定されるある時間で、クライアント６１０が、メッセージ６４を送ることにより、個別データ・ピースをセレクタ６４０に要求することを伴う場合がある。メッセージ６５を送ることにより、セレクタ６４０は、コンテンツ・アイテムのリストをメタデータ・リポジトリ６５０に要求する。メッセージ６６を送ることにより、メタデータ・リポジトリは、利用可能なコンテンツ・アイテムのリストを応答する。セレクタ６５０は、利用可能なコンテンツ・アイテムのリストから選択し、個人向けコンテンツを読み出すべき場所を示す識別子、例えば、アイテム・リポジトリ６６０で個人向けコンテンツを指しているＵＲＬで、クライアント６１０に応答する。メッセージ６８を送ることにより、クライアント６１０は、例えば、特定の時間に個人向けコンテンツを要求する。上で説明した様に、これには、カテゴリ識別子又は他の認証情報、例えば、ＭＡＣアドレス、ユーザ名等を送ることを含む場合がある。一部の実施形態では、これにはまた、プレイスホルダ種別の識別子を送ることを含む場合がある。メッセージ６９を送ることにより、アイテム・リポジトリ６６０は、個人向けコンテンツで応答する。

注目すべきは、図２及び図３のシステムでは、個人向けコンテンツを提供する少なくともメタデータ・リポジトリ及び／又はアイテム・リポジトリの部分が、サーバにより実現され、例えば広告代理店又は広告仲介業者により運用される場合があることである。さらに、メタデータ・リポジトリ及び／又はアイテム・リポジトリはまた、Ｐ２Ｐプラットホームにより実装される場合がある。メタデータ・リポジトリ及び／又はアイテム・リポジトリの物理的な実装は、コンテンツ・プロバイダの要件に基づいて決定される場合がある。さらに、当然のことながら、個人向けコンテンツの識別子は、記述ファイルに含まれる場合があるが、しかしまた、様々な場所に、例えばクライアント、セレクタ、メタデータ・リポジトリ、及び／又はアイテム・リポジトリにより提供される対応付けデータ内に、又は記述ファイルを補完する付加ファイル内に格納される場合がある。また、当然のことながら、ユニキャスト通信、マルチキャスト通信、及びブロードキャスト通信を含む様々な種別の通信が、システムの様々な構成要素間で使用され得る。例えば、記述ファイル生成部は、記述ファイルを複数の受信者又はクライアントに同報できようし、主要コンテンツ及び／又は個人向けコンテンツは、ブロードキャスト伝送を用いるアイテム・リポジトリにより提供できよう。しかしながら、図２のシステムで用いられる個別の記述ファイルを持つような一部のケースでは、クライアントに対する記述ファイルのユニキャスト伝送がより適切である場合がある。さらに、当然のことながら、記述ファイルを生成するのに必要な処理の少なくとも一部はまた、クライアントが主要コンテンツをコンテンツ・プロバイダに要求する前に実行できる。

図４は、上記概念が適用され得る通信ネットワーク環境を概略説明している。より具体的には、図４は、主要コンテンツのデータ・ピース及び／又は個人向けコンテンツの個別データ・ピースが、様々な情報源から読み出され得る、上記態様に焦点を当てている。その様な状況は、Ｐ２Ｐプロトコル、例えばビットトレント・プロトコルなどを用いる場合が典型的であるが、他のプロトコル、すなわち、ストリームの様々なピースが様々な情報源から提供され得るストリーミング・プロトコルでも生じる可能性がある。

図４のネットワーク環境では、いくつかのデバイス３１０、３２０、３５０、３６０が示されている。例えば、デバイス３１０及び３２０は、主要コンテンツのデータ・ピース及び／又は個人向けのコンテンツの個別データ・ピースを保存するサーバであり得る。例えば、デバイス３１０及び３２０は、図２及び図３に関連して説明したアイテム・リポジトリを実装する場合がある。デバイス３５０及び３６０は、任意の種別の受信デバイス、例えば、端末等であり得る。例えば、デバイス３５０及び３６０は各々、図２及び３に示すクライアントを実装し得る。デバイス３５０及び３６０は、個人向けデータの様々な受信者に対応する場合がある。すなわち、デバイス３５０は、デバイス３６０とは異なる種別の個人向けデータを受信する場合がある。

デバイス３５０の観点から、主要コンテンツのデータ・ピースを取得する様々な可能性がある。例えば、データ・ピースは、デバイス３１０から読み出され得る。その上、同じデータ・ピースが、例えばＰ２Ｐデータ通信の過程でデバイス３１０からデバイス３２０に提供されている可能性があり、デバイス３５０は、このデータ・ピースをデバイス３２０から得る場合がある。さらに、データ・ピースは、例えば、Ｐ２Ｐデータ通信の過程でデバイス３１０からデバイス３６０に提供されている可能性があり、デバイス３５０は、このデータ・ピースをデバイス３６０から得る場合がある。したがって、デバイス３５０には、主要コンテンツのデータ・ピースを取得する様々な選択肢が提供される。これらの様々な選択肢からの選択は、例えば、デバイス３１０、３２０、３６０へのデータ接続の特性に基づいて、例えば、データ接続のレイテンシ及び／又はビット速度に基づいて実施され得る。この様にして、データ・ピースは、最も適切な場所から取得でき、ネットワーク・リソースを、非常に効率のよい方法で使用できる。個別のデータ・ピースを得ることに対しても、状況は同様である。しかしながら、デバイス３５０及び３６０が、異なる種別の個人向けデータを受信しようとしている異なる受信者に対応する仮定のシナリオでは、個別データ・ピースはデバイス３６０では利用できない場合がある。

図５は、本発明の実施形態によるネットワーク・デバイス４１０を概略説明している。例えば、ネットワーク・デバイス４１０は、図４のデバイス３１０又は３２０のうちの１つに対応する場合がある。図５の実例では、ネットワーク・デバイス４１０のうちの一部の構成要素のみが示されており、それらは、本明細書で説明する概念を理解するのに有用と考えられるものである。当然のことながら、ネットワーク・デバイス４１０の更なる構成要素は、ネットワーク・デバイス４１０の特定の実装に依存して、提供される場合がある。

図示する様に、ネットワーク・デバイス４１０はプロセッサ４１２を有している。プロセッサは、例えば適切に設計されたプログラム・コードを実行することにより、個別ロジック４１４を実装する。その上、ネットワーク・デバイス４１０は、プロセッサ４１２と、個別ロジック４１４に接続されるインタフェース４１６を有している。インタフェース４１６は、他のネットワーク・デバイス及び／又は端末と通信するのに適切な任意の周知の種別とすることができる。例えば、インタフェース４１６は、インターネット・プロトコルによる通信を可能にするインタフェースであり得る。さらに、当然のことながら、インタフェース４１６は、様々な物理的実装に基づく可能性があり、例えば有線通信チャネル及び／又は無線通信チャネルを用いる様に構成される場合がある。

個別ロジック４１４は、上述した概念による個別化を達成する様に構成される。したがって、一部の実施形態では、個別ロジック４１４は、記述ファイル生成部の一部である場合があり、プレイスホルダ種別の少なくとも１つの識別子を記述ファイルに挿入することを実行する場合がある。一部の実施形態では、プレイスホルダ種別の識別子を記述ファイルに挿入することは、記述ファイルの生成とは別に実行される場合がある。例えば、ネットワーク・デバイス４１０は、インタフェース４１６で記述ファイルを受信でき、個別ロジック４１４は、受信した記述ファイルにプレイスホルダ種別の少なくとも１つの識別子を追加できる。その上、個別ロジック４１４はまた、プレイスホルダ種別の識別子に関連する記述データ、例えば、図１に関連して説明した記述データ１２０を記述ファイルに挿入することができる。プレイスホルダ種別の少なくとも１つの識別子を有し、随意にまたプレイスホルダ種別の識別子に関連する記述データを有する記述ファイルは、その後、インタフェース４１６を用いて別のデバイスに送信され得る。

他の例によると、個別ロジック４１４は、プレイスホルダ種別の識別子と、プレイスホルダ種別の識別子に関連する特定種別の記述データとの間の対応付けを実行する様に構成され得る。これは、記述ファイルを修正することにより、例えば、記述データを記述ファイルに含めることにより、或いは、記述データを所与の場所に保存することにより実行され得る。例えば、個別ロジックは、記述ファイルにおいてプレイスホルダ種別の識別子に出会うと、ある種別の個別のデータ・ピースを常に読み出す様にクライアントを構成できる。さらに、個別ロジックは、幾人かの受信者を対応する種別の個人向けのコンテンツに関連付ける対応付けデータを構成できる。その様な対応付けデータは、例えば、図２及び３に関連して説明したアイテム・リポジトリ内に、或いは、任意の他の適切な場所に保存できる。その上、個別ロジック４１４はまた、図２及び３に関連して説明したセレクタの機能を実装できる。

図６は、本発明の実施形態による受信デバイス４５０を概略説明している。例えば、受信デバイス４５０は、図４のデバイス３５０又は３６０に対応する場合がある。明確さのために、受信デバイス４５０は、本明細書で説明する概念を理解するのに有用であると思われる構成要素を用いて示している。しかし、当然のことながら、受信デバイス４５０は、受信デバイス４５０の特定の実装に依存して、同様に更なる構成要素を備える可能性がある。

図示する様に、受信デバイス４５０は、プレイスホルダ・ロジック４５６と共にクライアント４５４を実装するプロセッサ４５２を有している。クライアント４５４及びプレイスホルダ・ロジック４５６は、プロセッサ４５２により実行される適切に設計されたプログラム・コードにより実装される場合がある。受信デバイス４５０は、さらに、インタフェース４５８を有し、インタフェース４５８は、プロセッサ４５２、クライアント４５４及びプレイスホルダ・ロジック４５６に接続される。インタフェース４５８を用いて、受信デバイス４５０は、他のデバイス、例えば、サーバ又は他の受信デバイスと通信できる。その様な通信の例は、図４に関連して概説している。インタフェース４５８は、他のデバイスとのデータ通信を許容する任意の種別が可能である。例えば、インタフェース４５８は、インターネット・プロトコルによるデータ通信を可能とする様に構成できる。さらに、当然のことながら、インタフェース４５８は、様々な物理的実装に基づく可能性があり、例えば、有線通信チャネル及び／又は無線通信チャネルを用いる様に構成される場合がある。

受信デバイス４５０のクライアント４５４は、図１から図３に関連して説明したクライアントの機能を実行する様に構成され得る。特に、クライアント４５４は、記述ファイルに基づいてデータの受信を実行する様に構成され得る。この目的のため、クライアント４５４は、記述ファイル内の識別子を解析する様に構成される。識別子がダイレクト種別であると、クライアントは、ダイレクト種別の識別子に基づいて主要コンテンツの対応するデータ・ピースを読み出すことができる。プレイスホルダ・ロジック４５６は、識別子がプレイスホルダ種別であるかどうかを決定する様に構成される。記述ファイル内の識別子がプレイスホルダ形式であると、プレイスホルダ・ロジック４５６は、プレイスホルダ種別の識別子に関連する記述データを読み出す。この記述データに基づいて、個人向けコンテンツが読み出される。例えば、図１に関連して説明した様に、受信者に対応する特定種別の個別データ・ピースを参照する、特定種別の記述データ１２０が、提供され得る。

プレイスホルダ・ロジック４５６は、受信デバイス４５０のクライアント４５４内に実装される様に上述したけれども、当然のことながら、一部の実施形態では、プレイスホルダロジック４５６の少なくとも一部は、ネットワーク・デバイス内に、例えば図２及び３に関連して説明したアイテム・リポジトリ内に実装される場合がある。その様な実装の一例では、アイテム・リポジトリ内のプレイスホルダ・ロジックは、例えば対応する識別子を要求に含めることにより、提供されるコンテンツがプレイスホルダ識別子に関連していることを示す要求を受信できる。アイテム・リポジトリ内のプレイスホルダ・ロジックは、その後、要求された個別コンテンツの記述データを読み出し、個別コンテンツを読み出し、読み出したコンテンツで応答できる。一部の実施形態では、アイテム・リポジトリ内のプレイスホルダ・ロジックはまた、それぞれのコンテンツに対する要求と共に、識別子を記述ファイルから受信できる。アイテム・リポジトリ内のプレイスホルダ・ロジックは、その後、識別子がプレイスホルダ種別であるかどうかを決定し、そうであると、要求された個別コンテンツの記述データを読み出し、個別コンテンツを読み出し、読み出したコンテンツで応答できる。

図７は、本発明の実施形態による個別データ通信の方法を概略説明するためのフロー図である。本方法は、上述した概念を実行し、上述したデバイス及び構成要素を用いて実行できる。上述した概念によると、本方法は、データ・エンティティを少なくとも第１の受信者及び第２の受信者に伝える目的を有する。これは、記述ファイルに基づいて遂行される。記述ファイルは、上述した記述ファイル、例えば、図１に示した記述ファイル１００であり得る。記述ファイルは、記述ファイル生成部により、例えば、図２及び３に示した記述ファイル生成部により生成され得る。記述ファイルは、データ・エンティティの対応するデータ・ピースに関連している、ダイレクト種別の少なくとも１つの識別子を有している。特に、ダイレクト種別の識別子と対応データ・ピースとの間に１対１の関係がある場合がある。ダイレクト種別の識別子は、シグネチャ、例えばハッシュ値である場合があり、或いは、配信情報源の識別子、例えばＵＲＩである場合がある。

ステップ７１０で、プレイスホルダ種別の識別子が記述ファイルに追加される。これは、記述ファイルの生成の間に、例えば、図２及び３に関連して説明した記述ファイル生成部により実行され得る。しかしながら、既に存在する記述ファイルにプレイスホルダ種別の識別子を補充することによっても可能であり、入力としてダイレクト種別の識別子を持つ記述ファイルを受信する専用の個別構成要素により実行できる。実施形態によると、プレイスホルダ種別の識別子は、ダイレクト種別の識別子と同じフォーマットを有する。例えば、ダイレクト種別の識別子がシグネチャであると、プレイスホルダ種別の識別子はダミーのシグネチャとできる。さらに、ダイレクト種別の識別子が、配信情報源の識別子、例えば、ＵＲＩであると、プレイスホルダ種別の識別子は、ダミーの配信情報源の識別子、例えば、ダミーのＵＲＩとできる。プレイスホルダ種別の識別子は、個別データ・ピースの記述データに関連している。記述データは、データ・エンティティが伝えられる受信者に依存して、様々な種別を有する可能性がある。したがって、通常、プレイスホルダ種別の識別子は、個別データ・ピースの特定のコンテンツ又は種別に対して１対１の関係にない。

ステップ７２０で、第１の種別の記述データは第１の受信者に提供される。ステップ７３０で、第２の種別の記述データは第２の受信者に提供される。第１の受信者及び第２の受信者に異なる種別の記述データを提供することにより、記述データは、想定する受信者に依存する個別のデータ・ピースの、異なる種別又はコンテンツを参照できる。

ステップ７１０、７２０、７３０は総て、記述ファイル生成部の個別ロジックにより実行され得る。しかしながら、ステップ７２０及び７３０は、記述ファイル生成部とは別に提供される個別ロジックにより行うことができ、或いは、例えばネットワーク運用者により手入力で行うことができる。これは、プレイスホルダ種別の識別子に関連する記述データを所定の場所に、すなわち記述ファイル内か、記述ファイルとは別に保存することにより実行される場合がある。さらに、これは、様々な形式の個別データ・ピースと受信者の対応付けを制御することにより実行される場合がある。

したがって、図７の方法の様々なステップは、様々なデバイスに実装される可能性がある。例えば、記述ファイル生成部内での本方法の実装には、ステップ７１０を含めるが、ステップ７２０及びステップ７３０は含めない場合がある。さらに、記述ファイル生成部とは別の本方法の実装には、ステップ７２０及び７３０を含めるが、ステップ７１０を含めない場合がある。

図８は、本発明の実施形態による更なる方法を概略説明するためのフロー図である。図８の方法は、記述ファイルに基づいてデータを受信することが目的である。ここでも、本方法は、上述した個別化の概念を実現する。本方法の少なくとも一部は、上述した受信デバイス、すなわち図６に関連して説明した受信デバイス４５０で実行され得る。

ステップ８１０で、データ・エンティティの記述ファイルが受信される。記述ファイルは、少なくとも１つの識別子を含んでいる。識別子は、データ・エンティティの対応するデータ・ピースに関連するダイレクト種別か、個別データ・ピースの記述データに関連するプレイスホルダ種別のいずれかであり得る。記述ファイル、ダイレクト種別の識別子、及び、プレイスホルダ種別の識別子は、上述したものに対応する場合があり、例えば、図１に関連して説明した記述ファイル１００及び識別子であり得る。ダイレクト種別の識別子は、シグネチャ、例えばハッシュ値や、配信情報源の識別子、例えばＵＲＩである場合がある。プレイスホルダ種別の識別子は、同じフォーマットを有する場合があり、例えばダミー・シグネチャ又は配信情報源のダミーの識別子である場合がある。記述ファイルは、記述ファイル生成部から直接に受信される場合や、中間要素を経由、例えばプレイスホルダ種別の識別子を記述ファイルに追加する、及び／又は、プレイスホルダ種別の識別子に関連する記述データを記述ファイルに追加する、個別ロジック経由で受信される場合がある。

ステップ８２０で、識別子がプレイスホルダ種別であるかどうかが決定される。記述ファイルに複数の識別子があると、識別子の各々に対して決定が行われる。

ステップ８３０で、識別子がプレイスホルダ種別であると、プレイスホルダ種別の識別子に関連する記述データが読み出される。図１に関連して説明した様に、記述データは、受信者に対応する特定種別の個別データ・ピースの識別子を含む場合がある。例えば、記述データは、特定の種別の個別データ・ピースのシグネチャ、又は、特定種別の個別データ・ピースの配信情報源の識別子を含むことができる。記述データは、記述ファイル内の所定の場所から読み出される場合がある。さらに、記述データは、記述ファイルとは別の場所から、例えば、記述ファイルを補完する付加ファイルから、或いは、任意の他の適切な保存場所から、例えばＵＲＬにより識別されるネットワークの場所から読み出される場合がある。

ステップ８４０で、個別データ・ピースが、記述データに基づいて読み出される。これには、個別のデータ・ピースを受信することと、記述データ内のシグネチャに基づいて個別データ・ピースを検証することを伴う場合がある。さらに、これには、記述データに含まれている配信情報源の識別子を用いて、個別データ・ピースを要求することを伴う場合がある。

図８の方法は、受信デバイス内のクライアント、例えば、図２、３又は５に関連して説明したクライアントのプレイスホルダ・ロジックにより行われる場合がある。しかし、当然のことながら、本方法の一部の部分は、ネットワーク・デバイス内の、例えば図２及び３に関連して説明したアイテム・リポジトリ内のプレイスホルダ・ロジックにより実行される可能性がある。例えば、一部の実施形態では、ステップ８２０、８３０及びステップ８４０の少なくとも一部が、その様なネットワークに基づくプレイスホルダ・ロジックにより実施される場合がある。

図９Ａ及び図９Ｂは、ビットトレント・プロトコルによるデータ通信で用いられる可能性のある記述ファイルの例、すなわちトレント・ファイルの例を示している。

ビットトレント・プロトコルによると、送信されるコンテンツの完全性を調べる２つの主要なレベルがある。

第１のレベルは、記述ファイルの完全性に徹している。第１のレベルは、記述ファイルの主要部を検証することを含み、主要部は、データ・ピースの正規の長さ、ピースのハッシュ値、ピース数、再構築するファイルの大きさ、ファイル名及びディレクトリ構造等を他の詳細と共に含んでいる。

記述ファイルの主要部は、何が受信されるべきかについての情報を含むが、記述ファイルの他の部分は、例えば、１つ以上のトラッカーＵＲＬ、トラッカー・プロトコルを提供することにより、どの様に受信又はダウンロードすべきかの情報、だれが記述ファイルを製作したか、いつ記述ファイルが生成されたか、人が読み取り可能な製作者の共同使用権に関する情報等を含み得る。

ビットトレント・プロトコルによると、記述ファイルの主要部のフットプリント、すなわちＳＨＡ１ハッシュ値が、記述ファイルのシグネチャを構成する。このシグネチャは、記述ファイルの完全性を検証するのに用いられる。

更なる完全性の調査は、データ・ピースを取得したときに生じる。受信データ・ピースのＳＨＡ１ハッシュ値が計算され、そして記述ファイルの主要部により受信されると思われていたものと比較される。

図１から図８までに関連して説明した個別の概念は、記述ファイルの主要部が変わらない様にしておくことを可能にする一方、それでも個別コンテンツを様々な受信者に伝えることができる。

注目すべきは、ビットトレント・プロトコルに基づく本概念の実装に関する以下の記述は、ビットトレント・プロトコルの単一ファイル・モードに基づいていることである。しかし、当然のことながら、本概念は、ビットトレント・プロトコルのマルチファイル・モードにも同様に適用され得る。

図９Ａ及び９Ｂでは、トレント・ファイルの主要部が概略説明されている。主要部は、ルート・ディレクトリの情報領域に位置しており、"長さ"、"名前"、"ピース長"、及び"ピース"と表されたフィールドを含んでいる。フィールド"長さ"は、通信されるべきファイルの長さをバイトで定義する。フィールド"名前"は、ファイルの推奨されている名前を定義する。フィールド"ピース長"は、ピースの長さをバイトで定義する。フィールド"ピース"は、２０バイトのＳＨＡ１ハッシュ値の連結で構成されているストリングを有する。１つのハッシュ値が、ファイルの各ピースに対して提供される。フィールド"ピース"は、したがってバイトのストリングを有する。

図９Ａ及び９Ｂの例は、ファイルは"ＸＸＸＸＸ"の長さ、例えば１１２６４バイトであり、ファイル名が"ＹＹＹＹＹ"であり、ピース長が"ＺＺＺＺ"、例えば１０２４であると仮定している。さらに、主要なコンテンツには、Ｐ１、Ｐ２、・・・、Ｐ１０と表された１０個のピースがあり、各ピースは、対応するハッシュ値ＳＨＡ１（Ｐ１）、ＳＨＡ１（Ｐ２）、・・・、ＳＨＡ１（Ｐ１０）を有すると仮定している。さらに、図９Ａ及び９Ｂの記述ファイルは、フィールド"ピース"内に、それぞれ、個別のピースＢ又はＧに関連するハッシュ値ＳＨＡ１（Ｂ）又はＳＨＡ１（Ｇ）を有している。例えば、ファイルが動画に対応していると、この個別ピースは広告に対応する場合がある。明確さのために、広告は１つのピースで提供されると仮定している。しかしながら、広告はまた２つ以上のピースで提供されることもできる。個別のピースのハッシュ値は、他のハッシュ値の間に挿入される。さらに、図９Ａ及び９Ｂの例では、個別のピース、例えば広告は、各対象グループによって異なると仮定している。例えば、ピースＢは、少年を対象とし、ピースＧは少女を対象にする場合がある。したがって、図９Ａに示すファイルは、対象グループの少年に適するが、図９Ｂの記述ファイルは対象グループの少女に適するであろう。

上述した様に、ビットトレント・プロトコルによると、記述ファイルの主要部、すなわち"情報"領域におけるエントリは、記述ファイルの、"情報ハッシュ"とも呼ばれるシグネチャの基礎を形成する。したがって、シグネチャは、図９Ａ及び９Ｂに示すフィールドのみに依存する。

しかしながら、図９Ａ及び９Ｂから分かる様に、情報ハッシュは、図９Ａ及び９Ｂの２つの記述ファイルで異なるであろう。したがって、ビットトレント・プロトコルでは、これらの記述ファイルは、完全に異なるコンテンツを参照していると見られるであろう。動画の"少年版"を提供するピアは、"少女版"には寄与できないであろう。

図１０は、ここで説明した概念による記述ファイルの例を示している。図から分かる様に、領域"情報"は、一般に、図９Ａ及び９Ｂの記述ファイルに類似している。しかしながら、フィールド"ピース"には、個別のデータ・ピースの、すなわちピース"Ｂ"又はピース"Ｇ"のハッシュ値はなく、ＰＨで表されるプレイスホルダだけがある。したがって、図９Ａ及び９Ｂとの間で変わる記述ファイルの部分は、動的部分とも呼ばれる場合があり、総ての対象グループに共通なシンボリック・リンクとして機能する可能性があるプレイスホルダに置き換えられる。

プレイスホルダＰＨは、プレイスホルダ種別の上述した識別子の一例であって、他のピースのシグネチャと同じ長さ、例えば、ビットトレント・プロトコルによると２０バイトを有する。プレイスホルダＰＨは、一度だけ処理され、例えば標準で定義される。例えば、可能性のあるプレイスホルダは、"ｅｒｉｃｓｓｏｎ ａｄｓ Ｐ２Ｐ ｓｏｌｕｔｉｏｎ"のＳＨＡ１ハッシュ値、［４ｄ６２２ｃａｄ７ｂａ５３２ｅ８ｄｅｆｅ３ｄ６０ｅ２ｂｆ７５ａ２ｅ２ｆ３６９ｃ］であることができよう。通常、プレイスホルダＰＨは、ピースのシグネチャとの混同が回避されるような方法で決定されるであろう。プレイスホルダＰＨは特定のデータ・コンテンツから計算されるハッシュ値ではないので、偽シグネチャ又はダミー・シグネチャとも呼ばれる場合がある。

したがって、クライアントがプレイスホルダＰＨに基づいてピースを取り込みたい場合、プレイスホルダＰＨはピースの完全性を検証するのに用いるべきではないこと、ピースは主要コンテンツの一部ではなく、このピースについてのいかなる情報も他の場所で、例えばトレント・ファイル自身又は特別なホスト若しくはピアからの拡張に基づいて検査すべきであること、そしてピースはより小さいグループ内で利用でき、そして普通必ずしも総てのピアから取り込むことはできないことを知っている。

クライアントにより実装される処理例が、図１１のフロー図により概略説明されている。

ステップ１０１０で、クライアントはピースＡが取り込まれるべきであることを決定する。

ステップ１０２０で、クライアントは、ＳＩＧ（Ａ）で表される、ピースＡのシグネチャを得る。

ステップ１０３０で、ピースＡのシグネチャがプレイスホルダであるかどうかが決定される。そうでないと、処理はステップ１０４０に移り、シグネチャに対応するピースが、ビットトレント・プロトコルによる伝統的な振る舞いに対応する従来の方法で読み出される。

ステップ１０３０で、ピースＡのシグネチャがプレイスホルダであると決定されると、処理はステップ１０５０に移る。ステップ１０５０で、クライアントは、記述ファイルに、例えば主要部以外の任意の拡張に含まれる得るピースの記述、すなわち記述データを得る。さらに、或いは、その代替として、動的ピースの記述がまた別のホストに格納され、そして遠隔でアクセスされることもある。

ステップ１０６０で、ピースが要求され、ステップ１０６０で受信される。ステップ１０８０で、ピースが有効であるかどうかが決定され、このことは、ステップ１０５０で取得したピース記述内のシグネチャに基づいて実行できる。ここで、注目すべきは、ステップ１０８０はオプションである。例えば、ピースを送るホストに全幅の信頼があると、完全性の制御は省略される可能性がある。例えば、その様な解決策は、ピースが、ピア間で何ら共有されずに、直接広告代理店により提供される広告に対応していると、採用できよう。

処理はステップ１０９０で終わる。

ピースが要求されるステップ１０６０は、様々な方法で実現できる。以下では３つの選択肢を論じる。しかし、当然のことながら、これらの選択肢は例に過ぎず、ピースを要求する総ての可能性を網羅してはいない。

第１の選択肢によると、ユーザは、ピースの完全性を検証し、ピースが有効でないと、ピースは別のピア又はユーザから取り込まれる。この解決策は、クライアント及びビットトレント・トラッカーでの実装の複雑さを軽減する。

第２の選択肢はグループ識別子（ＩＤ）交換に基づいている。例えば、各ユーザ又はピアは、従来のメッセージ又は新しい種別のメッセージでグループＩＤを送ることができる。このような方法で、ピアは同じ種別の個人向けコンテンツを受信しようとしている他のピアのグループを知ることができる。したがって、ユーザが個人向けコンテンツ、例えば広告を取り込む必要がある場合、このグループのピアのみが、個人向けコンテンツを読み出すのに情報源として用いられる場合がある。

第３の選択肢によると、トラッカーは、ピースが共有されるべきピアを提供するホストであり、ピアのグループＩＤを知っている。ユーザがピアの集合を要求する場合、トラッカーは、ユーザ自身のグループ内のある割合のピアをユーザに提供する。これらのピアは、特別のフラグを持つことができ、ユーザはピアを見出すためにこの特別のフラグを用いることができる。代案として、ユーザは、上述した第１の選択肢で説明したものに類似している、試行錯誤方策に基づいて自身のグループのピアを見出すことができよう。

図１２は、本発明の実施形態による、ピア及びピースの管理を達成するための処理を概略説明するためのフロー図である。

ステップ１１１０で、ピアのリストが得られる。ピアのリストは、個別ピースが要求され得るピアを含む。例えば、クライアントは、ビットトレント・プロトコルによるトラッカーからピアのリストを得ることができる。

ステップ１１２０で、リストが空であるかどうかが調べられる。リストが空でないと、処理はステップ１１３０に移る。リストが空であると、本方法はステップ１２１０に移る。

ステップ１１３０で、リストからピアが選択され、"ピアＸ"と表される。

ステップ１１４０で、ピースが選択されたピアから要求される。ピースが選択されたピアから受信されると、ステップ１１５０で、ピースが有効であるかどうかが調べられる。有効でないと、選択されたピアは、ステップ１１７０でリストから取り除かれる。ピースが、ステップ１１５０で有効であると決定されると、処理はステップ１１６０で終わる。

ステップ１１７０で選択されたピアをリストから取り除くと、処理は、リストが空であるかどうかを決定するために、ステップ１１２０を繰り返すことにより続けられる。

ステップ１１２０でリストが空であると決定すると、新しいピアの集合がステップ１２１０で要求される。

ステップ１２２０で、新しいピアの集合を持つリストが受信される。

ステップ１２３０で、ユーザがユーザ自身のグループ、すなわち同じ種別の個人向けコンテンツを受信しようとしているグループに属しているピアを知っているかどうかが調べられる。そうでないと、本方法はステップ１１２０に戻る。

ユーザがグループに属しているピアを知っていると決定されると、本方法は、グループに属していないピアがリストから取り除かれるステップ１２４０を続ける。グループに属していないピアをリストから取り除いて、本方法はステップ１１２０に戻る。

図１２に示す処理は、個別データ・ピースを読み出すために図１１の処理の一部として用いられる場合があり、個別データ・ピースを読み出そうと試みるときの対象となるピアのグループを効率よく管理できる。

様々な受信者に対して、例えば、共有され１つだけ保存される可能性がある主要コンテンツの分配に影響を与えずに、マルチメディア・コンテンツに様々な人々又はグループの人々向けの様々な広告を含め、或いは、様々な時点で様々な広告を含めてデータ・エンティティの個別の通信をできる様にする概念が上で説明されている。例えば、これは、ユーザが動画ごとに支払う必要がある"ビットトレント・エンタテイメント・ネットワーク"に対する代案を、ユーザからの支払よりもむしろ個別の広告を用いることにより、提供するために用いられる場合がある。さらに、本概念は、純粋なストリーミングよりはむしろＰ２Ｐ種別のデータ通信を用いることにより、配信サービス、例えばＨｕｌｕにより用いられているデータ通信の代替方法を提供するのに用いられる可能性がある。その上、本概念はまた、ストリーミングに基づくデータ通信を効率的に個別化できる様にする。特に、マルチキャスト・チャネル又はブロードキャスト・チャネルで記述ファイルを送信できる様にする個人への対応が、記述ファイルを変更せずに達成される場合がある。その上、一部のシナリオでは、上述した概念はまた、コンテンツの使用に対する、受信者による良好な制御を得るのに役立つ場合がある。例えば、ビットトレント・プロトコル又は別のＰ２Ｐプロトコルは、広告付きのマルチメディア・ファイルを１つの一体化したブロックで配信するのに用いられる場合があり、一体化したブロックは、このコンテンツを調節すること、例えば広告を抜かすことを、プレイリストがコンテンツ及び広告のピースに対してファイルを分離する様に促す解決策よりも難しくする。さらに、本概念は、対象とする広告を用いて、Ｐ２Ｐネットワークを商用化する可能性を提供する。

当然のことながら、上記の説明は、本概念のよりよい理解を提供することを意図しており、そして様々な修正を受け入れやすい。例えば、本概念は、ビットトレント・プロトコル及びＨＴＴＰライブ・ストリーミング・プロトコルの上述の例に加えて、様々な種別の通信プロトコルに関連して用いられる可能性がある。さらに、本概念は様々な目的に適用される可能性がある。例えば、マルチメディア・コンテンツを配信することに加えて、本概念は、個別の方法でソフトウェアを配信するのに適用される場合がある。

プレイスホルダ種別の識別子は、様々な種別の個別コンテンツへの一般的な参照として用いられる場合があり、そして時には主要なコンテンツのピースへの参照としてもまた用いられる場合もある。さらに、プレイスホルダ種別の識別子は、総ての対象とする受信者に対して同じであるが、しかしそうでなければ主要コンテンツのピースとは異なるコンテンツのピースへの参照として用いられる可能性がある。例えば、主要コンテンツのピースが同じ特性、例えば、大きさを有するビットトレント・シナリオでは、プレイホルダー種別の識別子は、異なる特性を持つピースを参照するのに用いられる場合がある。その様な使用法の一例は、プレイスホルダ種別の識別子を更なるトレント・ファイルへの参照として用いることであろう。プレイスホルダ種別の識別子を、総ての受信者に共通であるが、"伝統的な"ピースとは異なる１つ以上のピースへの参照として用いる、この例又は他の例では、これらのピースに関する記述データは、ロバスト性を改善する、トレント・ファイルの情報領域に置かれることができよう。

また、本概念は、移動通信ネットワーク、有線通信ネットワーク、インターネットに基づく通信ネットワーク、イントラネットに基づく通信ネットワークを含む様々な種別の通信ネットワークに適用される可能性がある。さらに、本明細書で説明したデバイス及び構成要素の機能を実装するための様々な可能性が存在する。例えば、これらの機能は、少なくとも部分的に、プロセッサにより実行されるソフトウェアにより、又は専用ハードウェアにより実装される可能性がある。

Claims (19)

1. 記述ファイル（１００）に基づく、少なくとも第１の受信者及び第２の受信者へのデータ・エンティティ（２００）の通信方法であって、
   前記記述ファイル（１００）は、前記データ・エンティティ（２００）の対応するデータ・ピース（２１０）に関連するダイレクト種別の少なくとも１つの識別子を含み、
   前記方法は、個別データ・ピース（２２０）の記述データ（１２０）に関連するプレイスホルダ種別の識別子を前記記述ファイル（１００）に追加するステップを含み、
   第１の種別の前記記述データ（１２０）は、前記第１の受信者に提供され、
   第２の種別の前記記述データ（１２０）は、前記第２の受信者に提供され、
   前記第１の種別の前記記述データ（１２０）は、前記第２の種別の前記記述データ（１２０）とは異なる、
   ことを特徴とする方法。
2. 記述ファイル（１００）に基づく、少なくとも第１の受信者及び第２の受信者へのデータ・エンティティ（２００）の通信方法であって、
   前記記述ファイル（１００）は、前記データ・エンティティ（２００）の対応するデータ・ピース（２１０）に関連するダイレクト種別の少なくとも１つの識別子と、個別データ・ピース（２２０）の記述データ（１２０）に関連するプレイスホルダ種別の識別子と、を含み、
   前記方法は、
   第１の種別の前記記述データ（１２０）を前記第１の受信者に提供するステップと、
   第２の種別の前記記述データ（１２０）を前記第２の受信者に提供するステップと、
   を含み、
   前記第１の種別の前記記述データ（１２０）は、前記第２の種別の前記記述データ（１２０）とは異なる、
   ことを特徴とする方法。
3. 前記記述ファイル（１００）の前記記述データ（１２０）の少なくとも１つの部分を提供するステップを含む、
   ことを特徴とする請求項１又は２に記載の方法。
4. 前記記述ファイル（１００）とは別に前記記述データ（１２０）の少なくとも１つの部分を提供するステップを含む、
   ことを特徴とする請求項１から３のいずれか１項に記載の方法。
5. 前記記述データ（１２０）は、予め定義した位置に前記記述データ（１２０）を保存することにより前記プレイスホルダ種別の前記識別子に関連付けられる、
   ことを特徴とする請求項１から４のいずれか１項に記載の方法。
6. 前記ダイレクト種別の前記少なくとも１つの識別子は、前記関連するデータ・ピース（２１０）のシグネチャを含み、
   前記プレイスホルダ種別の前記識別子は、ダミー・シグネチャを含み、
   前記個別データ・ピース（２２０）の前記記述データ（１２０）は、前記個別データ・ピース（２２０）のシグネチャを含む、
   ことを特徴とする請求項１から５のいずれか１項に記載の方法。
7. 前記記述ファイル（１００）は、ビットトレント・プロトコルによるトレント・ファイルである、
   ことを特徴とする請求項６に記載の方法。
8. 前記ダイレクト種別の前記少なくとも１つの識別子は、前記関連するデータ・ピース（２１０）の配信源識別子を含み、
   前記プレイスホルダ種別の前記識別子は、ダミー配信源識別子を含み、
   前記個別データ・ピース（２２０）の前記記述データ（１２０）は、前記個別データ・ピース（２２０）の配信源識別子を含む、
   ことを特徴とする請求項１から７のいずれか１項に記載の方法。
9. 前記記述ファイル（１００）は、ＨＴＴＰライブ・ストリーミング・プロトコルによるプレイリスト・ファイルである、
   ことを特徴とする請求項８に記載の方法。
10. 前記個別データ・ピース（２２０）の第１のコンテンツを前記第１の受信者に提供するステップと、
    前記個別データ・ピース（２２０）の第２のコンテンツを前記第２の受信者に提供するステップと、
    を含み、
    前記第１のコンテンツは、前記第２のコンテンツとは異なる、
    ことを特徴とする請求項１から９のいずれか１項に記載の方法。
11. 記述ファイル（１００）に基づくデータ・エンティティ（２００）の通信方法であって、
    前記記述ファイル（１００）は、前記データ・エンティティ（２００）の対応するデータ・ピース（２１０）に関連するダイレクト種別、又は、個別データ・ピース（２２０）の記述データ（１２０）に関連するプレイスホルダ種別である、少なくとも１つの識別子を有し、
    前記方法は、
    前記識別子が前記プレイスホルダ種別であると、前記個別データ・ピース（２２０）の前記関連する記述データ（１２０）を読み出すステップと、
    前記読み出した記述データ（１２０）に基づいて前記個別データ・ピース（２２０）を読み出すステップと、
    を含むことを特徴とする方法。
12. 前記識別子が前記ダイレクト種別であると、前記識別子に基づき前記関連するデータ・ピース（２１０）を読み出すステップを含む、
    ことを特徴とする請求項１１に記載の方法。
13. 前記ダイレクト種別の前記識別子は、前記関連するデータ・ピース（２１０）のシグネチャを含み、
    前記プレイスホルダ種別の前記識別子は、ダミー・シグネチャを含み、
    前記個別データ・ピース（２２０）の前記記述データ（１２０）は、前記個別データ・ピース（２２０）のシグネチャを含む、
    ことを特徴とする請求項１２に記載の方法。
14. 前記記述ファイル（１００）は、ビットトレント・プロトコルによるトレント・ファイルである、
    ことを特徴とする請求項１３に記載の方法。
15. 前記ダイレクト種別の前記識別子は、前記関連するデータ・ピース（２１０）の配信源識別子を含み、
    前記プレイスホルダ種別の前記識別子は、ダミー配信源識別子を含み、
    前記個別データ・ピース（２２０）の前記記述データ（１２０）は、前記個別データ・ピース（２２０）の配信源識別子を含む、
    ことを特徴とする請求項１２に記載の方法。
16. 前記記述ファイル（１００）は、ＨＴＴＰライブ・ストリーミング・プロトコルによるプレイリスト・ファイルである、
    ことを特徴とする請求項１１から１５のいずれか１項に記載の方法。
17. 請求項１から１０のいずれか１項に記載の方法に従い動作する様に構成された個別ロジック（４１４）を備えている、
    ことを特徴とするデバイス。
18. 前記デバイスは、前記記述ファイル（１００）を生成する様に構成された記述ファイル生成部（５３０；６３０）を備えている、
    ことを特徴とする請求項１７に記載のデバイス。
19. 請求項１１から１６のいずれか１項に記載の方法に従い動作する様に構成されたプレイスホルダ・ロジック（４５６）を備えている、
    ことを特徴とするデバイス。

Images