特許 7149323 リモートデータのアプリケーションによる消費を同期させるための方法と装置

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

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

(11)【特許番号】

(24)【登録日】2022-09-28

(45)【発行日】2022-10-06

(54)【発明の名称】リモートデータのアプリケーションによる消費を同期させるための方法と装置

(51)【国際特許分類】

   H04N 21/44 20110101AFI20220929BHJP

   G04G 5/00 20130101ALI20220929BHJP

   H04L 7/04 20060101ALI20220929BHJP

   H04L 7/00 20060101ALI20220929BHJP

【ＦＩ】

H04N21/44

G04G5/00 J

H04L7/04

H04L7/00 990

【請求項の数】 20

(21)【出願番号】P 2020507983

(86)(22)【出願日】2018-04-09

(65)【公表番号】

(43)【公表日】2020-07-02

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

(87)【国際公開番号】W WO2018200184

(87)【国際公開日】2018-11-01

【審査請求日】2021-03-26

(31)【優先権主張番号】62/489,264

(32)【優先日】2017-04-24

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】519379400

【氏名又は名称】フェニックス リアル タイム ソリューションズ， インコーポレイテッド

(74)【代理人】

【識別番号】110000062

【氏名又は名称】特許業務法人第一国際特許事務所

(72)【発明者】

【氏名】ビーラー， ステファン

(72)【発明者】

【氏名】ブスタマンテ， ファビアン

(72)【発明者】

【氏名】ウェイナー， アンドリュー ジョセフ

【審査官】川中 龍太

(56)【参考文献】

【文献】特開２０１５－２１６６７９（ＪＰ，Ａ）

【文献】特表２０１６－５２６３４９（ＪＰ，Ａ）

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

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

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

Ｈ０４Ｎ ２１／００ － ２１／８５８

Ｇ０４Ｇ ５／００

Ｈ０４Ｌ ７／０４

Ｈ０４Ｌ ７／００

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

【請求項1】

順序付けられたデータストリームの複数のコンシューマによって順序付けられたデータストリームを受信するステップであって、前記順序付けられたデータストリームが、データチャンクの順序付けられたシーケンスを含む、ステップと、
前記複数のコンシューマ間で前記順序付けられたデータストリーム内のデータチャンクの消費を、以下のサブステップ：
前記順序付けられたデータストリームの消費を開始する前に、ローカル時刻とグループ時刻の間のマッピングを取得するために、前記複数のコンシューマが前記データチャンクを消費すべき前記グループ時刻を示すグループクロックと、前記複数のコンシューマの前記ローカル時刻を示すローカルクロックとを同期させるサブステップ;
前記順序付けられたデータストリームの前記データチャンクと、前記順序付けられたデータストリームの前記データチャンクに関連付けられているグループ時刻の表示とを受信するサブステップ；
前記グループ時刻および前記ローカル時刻と前記グループ時刻の間の前記マッピングに基づいて、前記グループ時刻に対応する前記ローカル時刻、前記ローカルクロックに関連付けられている前記ローカル時刻を計算するサブステップ；
前記ローカル時刻を前記ローカルクロックに関連付けられている現在時刻と比較して、前記データチャンクに関連付けられている前記ローカル時刻が、前記現在時刻より前か、前記現在時刻と実質的に同一か、または前記現在時刻の後であるかを示す比較を生成するサブステップ；そして
前記比較に基づいて、前記データチャンクを削除する、前記データチャンクの持続時間を調整する、または前記データチャンクを消費することにより、前記複数のコンシューマが、前記データチャンクを同期の基に消費することを保証するサブステップ
により、同期させるステップとを
備える方法。

【請求項2】

前記現在時刻が、前記ローカル時刻より前であると決定するステップ、および
受信されたデータチャンクのシーケンス内の前記データチャンクを、前記データチャンクに関連付けられている前記ローカル時刻を示す場所に、配置するステップ、
を備える、請求項１に記載の方法。

【請求項3】

前記現在時刻が、前記ローカル時刻と前記データチャンクの前記持続時間で定義された時間範囲内にあると決定するステップ、
前記データチャンクの前記持続時間を短縮させるステップ、そして
前記データチャンクの短縮させた持続時間に対応する持続期間に対する、前記データチャンクを消費するステップ
を備える、請求項１に記載の方法。

【請求項4】

前記現在時刻が、前記ローカル時刻より後であると決定ステップ、そして
前記データチャンクを削除するステップ
を備える、請求項１に記載の方法。

【請求項5】

以前に消費されたデータチャンクに続く第２のデータチャンクが、利用可能ではないと決定するステップ、そして
前記以前に消費されたデータチャンクの前記持続時間を延長するステップ、
を備える、請求項１に記載の方法。

【請求項6】

前記データチャンクが、ビデオフレームまたはオーディオのセクションを備える、
請求項１に記載の方法。

【請求項7】

前記グループクロックと前記ローカルクロックを同期させる当該サブステップが、
前記グループクロックに関連付けられている複数のグループ時刻と、前記複数のグループ時刻に対応する複数のローカル時刻を取得することと、
前記複数のグループ時刻および前記対応する複数のローカル時刻に基づいて、グループクロックとローカルクロックとの間の線形対応を計算することと
を備える、請求項１に記載の方法。

【請求項8】

前記順序付けられたデータストリームの消費中に、前記グループクロックと前記ローカルクロックを同期させる当該サブステップを実行し、これにより前記ローカル時刻と前記グループ時刻間の前記マッピングを改善する、
請求項１に記載の方法。

【請求項9】

順序付けられたデータストリーム内のデータチャンクが、複数のコンシューマによって消費されるべき時を示すグループ時刻を測定するグループクロックを定義するステップ、
前記グループクロックを、前記順序付けられたデータストリームの消費を要求する前記複数のコンシューマに関連付けられている複数のローカルクロックに同期させるステップであって、当該同期させるステップが、複数のグループ時刻を前記複数のコンシューマに送信することを備えるステップ、
前記データチャンクに関連付けられている前記グループ時刻および前記データチャンクを前記複数のコンシューマに送信するステップ、
前記複数のコンシューマの内のコンシューマから前記データチャンクの到着時刻を受信するステップ、
前記データチャンクの到着時刻と前記データチャンクに関連付けられている前記グループ時刻に基づいて、前記コンシューマが、かなりの割合のデータチャンクを遅れて既に受信しているか否かを決定するステップ、
前記コンシューマが、かなりの割合のデータチャンクを遅れて既に受信していると決定されると、前記データチャンクの品質または順序付けられたデータストリームのレイテンシを調整することにより、前記複数のコンシューマが、前記順序付けられたデータストリームを同期の基に消費することを保証するステップ、そして
ローカル時刻を前記ローカルクロックに関連付けられている現在時刻と比較して、前記データチャンクに関連付けられている前記ローカル時刻が、前記現在時刻より前か、前記現在時刻と実質的に同一か、または前記現在時刻の後であるかを示す比較を生成するサブステップ、および
前記比較に基づいて、前記データチャンクを削除する、前記データチャンクの持続時間を調整する、または前記データチャンクを消費することにより、前記複数のコンシューマが、前記データチャンクを同期の基に消費することを保証するサブステップ
により、前記複数のコンシューマ間で前記順序付けられたデータストリーム内のデータチャンクの消費を、同期させるステップ、
を備える方法。

【請求項10】

前記複数のコンシューマの内の前記コンシューマに送信される前記データチャンクに関連付けられている最小品質閾値を指定する設定を取得するステップ、
前記データチャンクの品質を最小品質閾値まで下げることにより、前記コンシューマが、データチャンクのかなりの割合を遅く受信することが阻止されるか否かを決定するステップ、そして
前記データチャンクの品質を最小品質閾値まで下げることにより、前記コンシューマが、データチャンクのかなりの割合を遅く受信することが阻止されると決定されると、前記データチャンクの品質を最大でも前記最小品質閾値まで下げ、そして前記データチャンクを、前記かなりの割合のデータチャンクを遅れて既に受信している前記コンシューマに送信するステップ
を備える、請求項９に記載の方法。

【請求項11】

前記コンシューマが、前記かなりの割合のデータチャンクを遅れて既に受信していると決定されると、前記かなりの割合のデータチャンクが遅れて受信されなくなるまで、前記コンシューマに送信される前記データチャンクの品質を低下させる、
請求項９に記載の方法。

【請求項12】

前記複数のコンシューマの内の前記コンシューマに送信される前記データチャンクに関連付けられている最小品質閾値を指定する設定を取得するステップ、
前記データチャンクの品質を最小品質閾値まで下げると、前記コンシューマが前記データチャンクのかなりの割合を遅く受信することが阻止されるか否かを決定するステップ、そして
前記データチャンクの品質を最小品質閾値まで下げると、前記コンシューマが前記データチャンクのかなりの割合を遅く受信することが阻止されないと決定されると、前記データチャンクに関連付けられていてかつ前記複数のコンシューマに送信されるグループ時刻を、前記かなりの割合のデータチャンクを遅れて受信する前記コンシューマでの前記データチャンクの前記到着時刻に対応する後の時刻にまで増大させ、これにより複数のコンシューマ間の消費の同期を保証するステップ
を備える、請求項９に記載の方法。

【請求項13】

前記複数のコンシューマが、前記順序付けられたデータストリームを消費している間に、前記複数のコンシューマに加わる新しいコンシューマからの要求を受信するステップ、そして
第２のデータチャンクおよび前記第２のデータチャンクに関連する第２のグループ時刻を新しいコンシューマに送信するステップであって、前記第２のグループ時刻が、前記複数のコンシューマに現在送信されつつある前記グループ時刻より遅い、ステップ
を備える、請求項９に記載の方法。

【請求項14】

データチャンクの順序付けられたシーケンスを備える順序付けられたデータストリームの複数のコンシューマと、
前記複数のコンシューマに関連付けられている複数のローカルクロックであって、前記複数のローカルクロック内のローカルクロックが、前記複数のコンシューマ内のコンシューマのローカル時刻を示す、ローカルクロックと、
前記複数のコンシューマが、前記順序付けられたデータストリーム内のデータチャンクを消費すべきグループ時刻を示すグループクロックと、
前記複数のコンシューマの間で前記順序付けられたデータストリーム内の前記データチャンクの消費を同期させる以下の命令：
前記順序付けられたデータストリームの前記消費を開始する前に、前記ローカル時刻と前記グループ時刻の間のマッピングを取得するために前記グループクロックと前記ローカルクロックを同期させる命令；
前記データチャンクおよび前記順序付けられたデータストリーム内の前記データチャンクに関連付けられているグループ時刻の指示を受信するための命令；
前記グループ時刻と、前記ローカル時刻と前記グループ時刻の間の前記マッピングに基づいて、前記グループ時刻に対応する、前記ローカルクロックに関連付けられている前記ローカル時刻を計算するための命令；
前記ローカル時刻を前記ローカルクロックに関連付けられている現在時刻と比較して、前記データチャンクに関連付けられている前記ローカル時刻が、前記現在時刻より前か、前記現在時刻と実質的に同じか、または前記現在時刻の後かを示す比較を生成する命令；
そして
前記比較に基づいて、前記複数のコンシューマが、前記データチャンクを削除する、前記データチャンクの持続時間を調整する、または前記データチャンクを消費することにより、前記データチャンクを同期の基に消費することを保証する命令
を実行する、前記複数のコンシューマ内の前記コンシューマに関連付けられている1つまたは複数のプロセッサと、
を備える、システム。

【請求項15】

前記複数のコンシューマが、前記順序付けられたデータストリーム内の前記データチャンクを消費すべき前記グループ時刻を示す、前記グループクロックと同期する第２のグループクロック、および
前記第２のグループクロックに関連付けられている１つ以上のプロセッサであって、
前記グループクロックが動作していないと決定するための命令、および、
前記グループクロックが動作していないとの決定に基づいて、前記第２のグループクロックによって示される前記グループ時刻を前記複数のコンシューマに送信するための命令
を実行する、プロセッサ
を備える、請求項１４に記載のシステム。

【請求項16】

前記命令が、
複数の順序付けられたデータストリームを受信するための命令であって、前記複数の順序付けられたデータストリーム内の各順序付けられたデータストリームが、残りの複数の順序付けられたデータストリームと同期する、命令、
前記複数の順序付けられたデータストリーム内の複数のデータチャンクに関連付けられている複数のグループ時刻を取得するための命令、そして
同じ複数のグループ時刻を有する前記複数のデータチャンクを同期の基に消費するための命令、
を備える、
請求項１４に記載のシステム。

【請求項17】

前記データチャンクが、前記複数のコンシューマへ前記データチャンクを消費する時刻、フレーム指示および消費されるデータを示す、前記グループクロックに関連付けられている消費を備える、請求項１４に記載のシステム。

【請求項18】

複数の受信されたデータチャンクを格納するように動作可能なメモリ、
前記現在時刻が前記ローカル時刻より前であると決定するための命令、そして
前記データチャンクに関連付けられている前記ローカル時刻を示す位置内の複数の受信されたデータチャンクを格納するメモリにデータチャンクを配置するための命令
を備える、請求項１４に記載のシステム。

【請求項19】

前記命令が、
現在時刻が、前記ローカル時刻と前記データチャンクの前記持続時間によって定義された時間範囲内にあると決定するための命令、
前記データチャンクの持続時間を短縮するための命令、そして
前記短縮された持続時間に対応する持続期間に対して、前記データチャンクを消費するための命令
を備える、請求項１４に記載のシステム。

【請求項20】

前記命令が、
前記現在時刻が、前記ローカル時刻より後であると決定するための命令、そして
前記データチャンクを削除する命令
を備える、請求項１４に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、データの配信に、より具体的には、リモートデータのアプリケーションによる消費を同期させるための方法およびシステムに関する。

【背景技術】

【0002】

アプリケーションのストリーミングは、ネットワーク遅延および他の遅延の影響を受けやすい。そのため、通常、アプリケーションの特定のストリーミング（例、ビデオのストリーミング）の複数のユーザーは、同時に同じフレームを見ることは無い。これらのユーザーが、アプリケーションのストリーミング中にチャットセッションまたは他のリアルタイム通信にも参加している場合、これらの参加者は、しばしば同じことについて話し合っていないため、このような場合には意味のある会話を維持することは困難である。つまり、一方の参加者は、他方の参加者がまだ見たことのない何かについてコメントしている可能性がある。

【発明の概要】

【発明を解決するための手段】

【0003】

本出願では、複数のコンシューマが、順序付けられたデータストリームを同時に視聴することが出来るようにするための方法およびシステムが提示される。本発明の一実施形態は、データのソースである１つのサーバと、データのコンシューマである複数のクライアントが存在するクライアントサーバモデルに従う。さらに、本発明は、１）データソースとして機能する複数のサーバまたはサーバクラスタ、およびコンシューマとして機能する複数のクライアント、２）各ピアが、データのソースおよび／またはコンシューマの両方になり得る純粋なピアツーピア、３）ピアが、データのソースおよび／またはコンシューマのセットの両方になることができ、かつ1つまたは複数のサーバが、ソースとして機能し、そしてどのデータがどのピアから利用可能かという様なピアに関するメタ情報をバックアップしかつ提供する、サーバにより支援されるピアツーピアモデル、を含むがこれらに限定されない他の多くのモデルによっても実施させることが出来る。

【図面の簡単な説明】

【0004】

【図1】本発明による例示的な同期されているグループを示すブロック図である。

【図2】単一フレームのデータチャンクおよびマルチフレームのデータチャンクの例を示す。

【図3】本発明による２つのコンシューマのフレーム同期を示すタイミング図である。

【図4】本発明によるシステムアーキテクチャを示す。

【図5】本発明によるシステムアーキテクチャを示す。

【図6】本発明によるシステムアーキテクチャを示す。

【図7】同期ステップを実行するデータソースを示す。

【図8】セッションに参加し、クロック同期ステップを実行するコンシューマを示す。

【図9】パブリックインターネットを介してコンシューマにデータを送信するデータソースを示す。

【図10】データの一部がコンシューマに既に届いていることを示す。

【図11】３つのビデオフレームと１つのグループ消費タイムスタンプ（ＧＣＴＳ: Group Consumption Timestamps）を受信したコンシューマの詳細図を示している。

【図12】コンシューマが各ビデオフレームのローカル消費タイムスタンプ（ＬＣＴＳ: Local Consumption Timestamps）を計算したことを示している。

【図13】より多くのデータがコンシューマに届いたことを示す。

【図14】コンシューマがＬＣＴＳ３とＬＣＴＳ４を計算したことを示す。

【図15】ＬＣＴＳｋが計算されたことを示す。ＬＣＴＳｋは、データソースによって提供されたＧＣＴＳｋから直接計算することが出来る。

【図16】第２のデータコンシューマ２がセッションに参加したことを示す。

【図17】データコンシューマ２が、データコンシューマ１が受信しているのと同じデータの受信を開始することを示す。

【図18】コンシューマがクロック同期ステップを定期的に繰り返すことを示す。

【図19】各コンシューマがそれ自体のローカルクロックを有しているにもかかわらず、データが、同じグループ時刻に（例、同期した状態で）データコンシューマ１およびデータコンシューマ２によってどのように消費されるかを示す。

【図20】本発明によるキューおよび同期されたデータ消費を示すブロック概略図である。

【図21A】本発明によるデータの優先度に基づく順序付けを示す。

【図21B】本発明によるデータの優先度に基づく順序付けを示す。

【図21C】本発明によるデータの優先度に基づく順序付けを示す。

【図21D】本発明によるデータの優先度に基づく順序付けを示す。

【図21E】本発明によるデータの優先度に基づく順序付けを示す。

【図21F】本発明によるデータの優先度に基づく順序付けを示す。

【図21G】本発明によるデータの優先度に基づく順序付けを示す。

【図21H】本発明によるデータの優先度に基づく順序付けを示す。

【図22】本発明による複数のデータストリームの消費の同期を示す。

【図23】一実施形態による、複数のコンシューマの間でデータチャンクの消費を同期させる方法のフローチャートである。

【図24】別の実施形態による、複数のコンシューマの間でデータチャンクの消費を同期させる方法のフローチャートである。

【図25】本明細書で説明されている方法論の１つまたは複数をマシンに実行させるための命令のセットを実施させることが出来るコンピュータシステムの例示的な形態のマシンの構成図を示す。

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

【0005】

次に、様々な実施形態の例を記載する。以下の記載では、これらの例を完全に理解し、かつ説明を有効にするための特定の詳細が、提供される。しかし、関連技術の当業者は、開示された実施形態のいくつかが、これらの詳細の多く無しに実施することが出来ることを理解するであろう。

【0006】

同様に、関連技術の当業者は、実施形態のいくつかが、本明細書には詳細に記載されていない他の明らかな特徴を含むことが出来ることを理解するであろう。さらに、様々な例の関連する説明を不必要に曖昧にすることを避けるために、いくつかのよく知られている構造または機能は、以下では、詳細に示されないかまたは記載されない場合がある。

【0007】

以下で使用される用語は、実施形態の特定の例の詳細な説明と併せて使用されている場合でも、その最も合理的な方法で解釈されるものとする。実際、特定の用語が以下で強調されることさえある。しかしながら、制限された方法で解釈されることを意図した用語は、この発明の詳細な説明のセクションでそのように明確かつ具体的に定義されるであろう。

【0008】

定義
以下の段落には、本文書全体で使用される定義のセットが含まれる。

【0009】

データチャンクおよびフレーム
データチャンク（DataChunk）は、関連付けられている消費タイムスタンプを持つデータフレームのコレクション、おそらく1つのコレクションを意味するように使用される。本発明の例示的な実施形態では、各データフレームは、フレーム識別子、データタイムスタンプ、およびデータ自体から構成される。消費タイムスタンプ（ConsumptionTS）が、各データフレーム（DataFrame）とともにヘッダーフィールドとして送信されるような他の実施形態では、フレーム識別子（FrameID）とデータタイムスタンプ（DataTS）は、オプションである。タイムスタンプは、優先度を示すために使用されるが、これは、例えば、フレームタイプまたはソースに基づいて、簡単に一般化させることが出来る。
DataChunk ::=ConsumptionTS {DataFrame} 1-n
DataFrame ::=(FrameID)(DataTS)Data

【0010】

図２は、このことを、単一のおよびマルチフレームのデータチャンクにより示す。

【0011】

消費のバッファリング
データチャンクはクライアントに到着し、そしてバッファ（図２１Ａ～Ｈ）に配置され、そこからデータチャンクが消費される。一例としてビデオを使用すると、データチャンクは、複数のビデオフレームで構成されていて、かつこれらのフレームは、レンダリングのために着信バッファから消費される。このモデルの別のインスタンス化では、消費されるデータチャンクとフレームは、サードパーティのアプリケーションに渡すことが出来る。再び、一例としてビデオを使用すると、これは、ほとんどのＨＴＭＬ５対応ブラウザに組み込まれているMedia Service Extensionになり得る。

【0012】

バッファ消費と消費時刻
消費タイムスタンプＣＴ（consumption time）を有するデータチャンクを受信すると、ローカル時刻ＬＣｉを有するクライアントｉは、チャンクのフレームをバッファリングする、それらを即座に再生する、またはＬＣｉとＣＴの相違に応じて、それらのサブセット、すなわち、チャンクの一部を破棄する、の何れかを行う。

【0013】

同期されているグループ
同期されているグループという用語は、全てのコンシューマが、同時にデータを消費することを望む、データソースとコンシューマから構成されるデバイスのグループを指すために使用される。

【0014】

リモートデータのアプリケーションによる消費の同期
本発明の実施形態は、クライアントのグループ間でデジタルデータ（例、ビデオ）、を同期した状態で消費するためのアプローチを提供する。消費されるデータは、1つまたはソースのコレクションによって提供され、クライアントとデータソースは、インターネット経由で接続され、かつメモリともグループクロックとも共有されていないと仮定されている。本発明によってサポートされる同期された消費により、クライアントは、消費された共有コンテンツに関して、あたかもそれらが物理的に並置されているかのように、互いに同時に同期した状態で対話することが出来る。

【0015】

本発明の実施形態は、クライアントのアプリケーションがグループクロックを共有しない場合に、２つ以上のクライアントのアプリケーションによるリモートデータの消費を同期させる方法および装置を提供する。本発明の実施形態では、参加者は、以下で説明するクロック同期アルゴリズムを使用する。

【0016】

文脈を提供するために、最初に、本発明の実施形態の意図された使用の一例が記載される。異なる都市に、インターネットからストリーミングされたビデオを同時に見たい２人の人がいる。ビデオを見ている間、彼らは、電話、テキスト、チャット、または他のリアルタイム通信方法を使用して、ビデオのイベントについて議論することを望む。彼らは、一方の人が見ているビデオの再生が、他方の人が見ているビデオの再生と同期し、その結果、彼らの議論が明確になり、そして一方の人が、他方の人がまだ見ていないビデオ内のイベントに言及することが確実に起こらないことを望む。本発明の実施形態は、この例における二人のビデオの再生を同期させる。

【0017】

本発明の現在好ましい実施形態は、２つ以上のコンピュータプリケーションによって実行される一連のステップから構成される。データの発信元とコンピュータプリケーションを実行するデバイスの全てが、地理的に離れている場合であっても、これらのステップを実行すると、２つのコンピュータプリケーションは、同期した状態でデータを消費する。

【0018】

本発明の一実施形態は、データのソースである１つのサーバと、データのコンシューマである複数のクライアントが存在するクライアントサーバモデルに従う。従って、「サーバ」と「データソース」という用語は、同じ意味で使用される。同様に、「クライアント」と「コンシューマ」という用語も、同じ意味で使用される。しかしながら、本発明は、以下の例を含むがこれらに限定されない多くの他のモデルによって具体化することも出来る：
●データソースとして機能する複数のサーバまたはサーバクラスタ、およびコンシューマとして機能する複数のクライアント。
●各ピアが、データのソースまたはコンシューマ、あるいはその両方になることが出来る純粋なピアツーピア。
●ピアを、データのソースまたはコンシューマ、およびその両方とすることができ、かつ1つ以上のサーバのセットが、ソースとして機能し、かつどのピアからどのデータが利用可能という様なピアに関するメタ情報をバックアップしかつ提供する、サーバ支援ピアツーピアモデル。

【0019】

新しいメンバが、同期されているグループに参加するときは常に、それは、クロック同期アルゴリズムを実行しなければならない。初期化後、グループのメンバは、クロック同期アルゴリズム（後で詳しく説明する）を使用して、定期的にクロックを同期させることが出来る。同期時間の間、クライアントクロックは、ドリフトラットｄｒに基づいてドリフトする可能性がある（クロックＣのｄＣ／ｄｔ、ドリフトは正にも負にもなり得る）。

【0020】

このステップの結果として、新しいグループメンバは、任意のグループクロックタイムスタンプをローカルクロックタイムスタンプに、およびその逆に変換することが出来る。グループクロック同期の詳細は、以下で詳しく説明される。

【0021】

サーバによってそのクライアントに送信されるデータチャンクは、チャンクを構成するデータフレームがクライアントによって消費される（潜在的に）将来の時刻である、消費タイムスタンプ（ＣＳ: consumption timestamp）を含む。異なる実施形態では、消費タイムスタンプは、異なるチャネルで送信され、かつ後のマッチングのためにデータチャンクＩＤまたはデータフレームＩＤを含むことが出来るであろう。

【0022】

クライアントは、データのチャンクを受信すると、クライアントのクロックドリフト率に基づいて、サーバのタグ付き消費タイムスタンプをローカル消費タイムスタンプに変換する（以下の式 AAを参照）。ローカル消費タイムスタンプがクライアントのクロックに対して未来にある場合、クライアントは、そのクロックが、消費タイムスタンプに等しいまたはそれ以上の時間に達するまで、データチャンクを消費することを待機する。

【0023】

クライアントは、サーバからの全てのデータチャンクの受信を確認する。確認応答は、サーバに、チャンクの到着時刻または消費時刻と到着時刻との差を通知する。わずかな変更例では、クライアントは、データチャンクごとに応答を送信するのではなく、消費時刻後にデータチャンクが到着したときにのみ、到着時刻、または消費タイムスタンプと到着時刻との差を示す応答を送信する。

【0024】

消費時刻が経過した後にデータチャンクが到着する場合、クライアントは、含まれているデータフレームの一部または全てを破棄する、またはクライアントのローカル時刻が消費時刻のそれと一致するまで、それらのデータフレームの一部または全てをより高速で消費することが出来る。以下に簡単な説明例を示す。データチャンクが、関連付けられている持続時間が４０ミリ秒の単一のビデオフレームで構成されていて、かつデータが、消費時刻の１０ミリ秒後に到着する場合、クライアントは、それがフレーム持続時間を３０ミリ秒に短縮すると、依然としてデータを消費することが出来る。しかしながら、特定のアプリケーションでは、データの到着が遅れた場合、そのデータは破棄すると言う条件が適用される。

【0025】

グループ時刻をローカル時刻に変換する別の方法は、ドリフト(drift)を計算することである：
drift = (LCTS1 - LCTS0) / (GCTS1 - GCTS0) (式 AA)

【0026】

ドリフトを使用して、ＧＣＴＳをＬＣＴＳに変換する
LCTSk = drift x (GCTSk - GCTS1) + LCTS1 (式 BB)
ＬＣＴＳ：ローカルタイムスタンプ
ＧＣＴＳ：グループタイムスタンプ
ＧＣＴＳ1は、最後の同期時のグループタイムスタンプである。
ＬＣＴＳ1は、最後の同期時のローカルタイムスタンプである。

【0027】

取引データの品質、レイテンシ、同期
本発明の実施形態は、データが不完全であるまたは近似している場合でも、いくつかのタイプのデータは、依然として有用であるという事実を活用する。不完全データまたは近似データの意味を説明するために、いくつかの例を示す。
●ビデオまたはサウンドをより低いビットレートでエンコードして、元のビデオまたはサウンドの近似値を生成することが出来る。
●画像を低解像度でエンコードして、元の画像の近似値を作成することが出来る。
●データポイントのランダムサンプリングを削除する、または各データポイントを低い精度に丸めることにより、一連の測定値を近似することが出来る。

【0028】

同期を維持するためのデータ品質／完全性の犠牲
一部のコンシューマは、ネットワーク接続が遅いので、消費時刻の後に一貫してデータチャンクを受信する場合がある。本発明の実施形態は、上述したデータ近似および圧縮を使用して、ネットワーク条件が、他のグループメンバに対してよりも一部のグループメンバに対してはるかに悪い場合でも、全てのグループメンバに対して同期されたデータ消費を実行する能力を保持する。クライアントが、消費時刻後にデータチャンクを一貫して受信すると、クライアントは、サーバに通知し、かつより小さいチャンクを要求することが出来る。サーバは、他のクライアントに完全なデータを提供する一方、そのクライアントには小さなデータチャンクを提供することが出来る。この小さいデータチャンクは、他のクライアントに完全なデータを提供する一方、そのクライアントの元のデータの近似値を表す。

【0029】

サーバは、複数レベルのデータ近似またはデータ圧縮を提供することが出来る。消費時刻の前にフルサイズのチャンクを受信することが出来るクライアントもあれば、消費時刻の前に（元のデータの近似値に近い）わずかに小さいチャンクを受信することが出来るクライアントもあれば、消費時刻前のデータの非常に大まかな近似値しか受信できないクライアントもある。

【0030】

近似または圧縮の程度に関係なく、同期されているグループ内の全てのクライアントには、サーバによって同じ消費タイムスタンプが提供される。これにより、例え、一部のクライアントがデータの近似値のみを消費し、かつ他のクライアントが完全な元のデータを消費している場合であっても、全てのクライアントが、同時にデータを消費することが保証される。

【0031】

データの品質／完全性を維持するためのレイテンシの犠牲
いくつかの用途では、近似データを消費することは望ましくないまたは実用的ではない場合がある。これらの場合、データソースが、常に一定の品質閾値を超えるデータ（例、２．５Ｍビット／秒より大のビデオビットレート）を提供するように、同期されているグループを構成することが出来る。

【0032】

サーバは、クライアントから応答をデータチャンクの到着時刻に関する情報とともに受信するので、サーバは、どのクライアントが、到着時刻の後にデータチャンクを遅く受信しているかを把握している。グループが、データの品質／完全性を保持するように構成されている場合、サーバは、遅い消費タイムスタンプを将来の送信データに割り当てることが出来る。これにより、グループのデータ消費のレイテンシが高くなる。つまり、データチャンクは、より長い時間が経過した後に消費される。しかしながら、これは、グループが同期とデータ品質を保持することを可能にする。

【0033】

消費時刻が明示的に提供されていない場合の消費時刻の推測
データチャンクに関連付けられている消費タイムスタンプは、データチャンクの第一フレームの消費時刻であると見ることが出来る。後続の全てのデータフレームの消費時刻は、第一フレームの消費時刻と各フレームのタイムスタンプとに基づいて計算することが出来る。例えば、フレーム０からフレーム２までの一連の３つのビデオフレームを考えてみる。フレーム０のみが、１５０，０００の明示的なグループ消費タイムスタンプ（ＧＣＴＳ）を持つとする。明示的な消費タイムスタンプを持たないフレーム1のビデオタイムスタンプは、フレーム０のビデオタイムスタンプの後３，７５０ティックを持つ。

【0034】

従って、フレーム１のＧＣＴＳは、１５０，０００ ＋ ３，７５０ ＝ １５３，７５０であると推測される。このタイムスタンプは、グループクロックで表されているので、コンシューマのローカルクロックに変換する必要がある。グループクロックに対してクライアントのローカルクロックにドリフトがある場合、ローカルタイムでのフレーム1の消費タイムスタンプは、ローカルクロックの３７５０ティックよりも大きくなる（ドリフト＞1の場合）、または小さくなる（ドリフト＜1の場合）であろう。これは、同期を維持するために、クライアントの再生速度が、グループの再生速度と実際上異なることを意味する。

【0035】

クロック同期の詳細な説明
本発明の実施形態は、クロック同期フェーズに依存する。以下に、１クロック同期アルゴリズムが、Cristianの時刻同期アルゴリズム（https://en.wikipedia.org/wiki/Cristian%27s_algorithm）に基づいて説明される。このアルゴリズムは、本発明を満たすために使用することが出来るであろう。クライアントＣは、サーバの時刻を要求するためにタイムサーバＳにコンタクトする。要求を受信した後、サーバは、応答を準備し、そしてその時刻Ｔ（ＵＴＣのような外部ソースに基づいて設定される場合とそうでない場合がある）を追加する。応答を受信した後、クライアントはその時刻をＴ ＋ ＲＴＴ／２に設定する（ＲＴＴは通信の往復時間）。これに代えて、クライアントは、ローカルクロックをサーバ時刻に設定するのではなく、単にグループクロックとローカルクロックとの間のオフセットを記録することも出来る。より緊密な同期を実現するために、クライアントは。この要求を複数回実行し、そして最短のＲＴＴで応答を使用することが出来る。ここに記載されている方法は、ＲＴＴが、要求と応答の間で均等に分割されていることを前提としている。本発明の異なる実施形態では、任意の数の異なるクロック同期アルゴリズムを利用することが出来るであろう。唯一の要件は、アルゴリズムが完了した後、グループメンバが、グループタイムスタンプとローカルタイムスタンプの間で変換することが出来ることが必要であることである。この要件を満たす他の同期アルゴリズムには、BerkeleyとＮＴＰが含まれるが、これらに限定されることはない。本発明は、アプリケーションによっては、外部クロックとの同期を必要としないことがあるので、これらの代わりにいくつかの他のアルゴリズムを使用することも出来る。

【0036】

クロック同期アルゴリズムを２回実行することにより、クライアントは、ローカルクロックとグループクロックとの間のドリフト率を計算することが出来る。

【0037】

グループクロックの重要性を考えると、この同期グループは、プライマリグループクロックとの同期を維持する1つまたは複数のバックアップグループクロックを維持することにより、その障害許容力を高めることが出来る。プライマリグループクロックに障害が発生した場合、このグループは、バックアップグループクロックの1つを即座に昇格させて、リーダー選択アルゴリズムを使用して選択される新しいプライマリグループクロックとして機能させることが出来る。

【0038】

図の説明
図１は、本発明による例示的な同期グループを示すブロック図である。本発明の例示的な実施形態では、サーバは、１つ以上のフレームから構成することが出来るであろうデータチャンクを、追加の消費時刻（ＣＴ: consumption time）とともに、送信する。時刻ＣＴのデータチャンクを受信すると、ローカル時刻ＬＣｉのクライアントiは、ＬＣｉとＣＴの差に応じて、チャンクのフレームをバッファリングするか、すぐに再生するか、またはそれらのサブセット（つまり、チャンクの一部）を破棄する、の何れかを行う。

【0039】

図２は、単一フレームのデータチャンクおよびマルチフレームのデータチャンクの例を示す。本発明は、単一フレームのデータチャンクのみ、マルチフレームのデータチャンクのみ、または単一フレームのデータチャンクとマルチフレームのデータチャンクの組み合わせを使用して実施することが出来るであろう。

【0040】

図３は、本発明による２つのコンシューマのフレーム同期を示すタイミング図である。この図は、２つのコンシューマが、個別のローカルクロックを持っているが、特定のグループ時刻でデータを同期した状態で消費することが出来ることを示す。より詳細なタイミング図と説明は、図１９に示されている。

【0041】

図４～６は、本発明によるシステムアーキテクチャを示す。

【0042】

図４は、プライベートクラスタ内に２つのサーバを有するアーキテクチャの例を示す。サーバ1は、データソースとして機能し、そこからデータが様々なコンシューマに送信される。サーバ1は、この例のアーキテクチャでグループクロックとして機能するクロックも有する。サーバ２は、プライベートクラスタの一部でもあり、かつバックアップグループクロックを維持する。バックアップグループクロックは、サーバ1のグループクロックと同期して維持されるため、サーバ1のグループクロックに障害が発生した場合、サーバ２のクロックは、グループクロックとして機能するよう即座に昇格させることが出来る。データコンシューマ１～３は、パブリックインターネットを介してプライベートクラスタに接続されている。各コンシューマは、それ自体のローカルクロックを有する。各コンシューマは、グループクロックを使用して定期的に同期アルゴリズムを実行する。このようなアルゴリズムの結果、これらのコンシューマは、グループ時刻を自分のローカル時刻に、そしてローカル時刻をグループ時刻に変換させることが出来る。サーバ1は、パブリックインターネット経由で、各コンシューマに、データを、このデータに関連付けられている消費タイムスタンプとともに送信する。これらのコンシューマは、データを受信し、そして消費タイムスタンプを使用してこのデータを同期した状態で消費する。

【0043】

図５は、次の詳細が削除されている点を除いて、図４と同じである。
●どのサーバがデータソースとして機能するかは示されていない。これは、実際には、1台のサーバがデータソースとして機能する、または複数のサーバが共同でデータソースとして機能する可能性があるためである。
●どのサーバもグループクロックを保持することが出来るため、どのサーバがグループクロックを保持しているかは表示されていない。
●バックアップクロックは必要でないため、バックアップクロックは表示されていない。

【0044】

図６は、データソースとグループクロックが、完全に独立したボックスとして表示され、かつパブリックインターネット経由で接続されている点を除けば、図５と同じである。これは、グループクロックがデータソースに連結される必要がないことを示すためである。データソースは、グループクロックと同期するであろうそれ自体のローカルクロックを有することが出来るであろう。

【0045】

図７～１９は、本発明による、クライアントが参加し、それらのクロックと同期し、かつソースによって公開されたデータを消費する、複数のステップによるセッションを示す。

【0046】

図7は、同期ステップを実行するデータソースを示す。これは、グループクロックが、データソースのローカルクロックと異なる場合に、必要となる。これにより、データソースが、グループ時刻をローカル時刻に、またローカル時刻をグループ時刻に変換させることが可能になる。

【0047】

図８は、セッションに参加し、かつクロック同期ステップを実行するコンシューマを示している。これにより、コンシューマが、グループ時刻をローカル時刻に、またローカル時刻をグループ時刻に変換させることが可能になる。

【0048】

図９は、パブリックインターネットを介してコンシューマにデータを送信するデータソースを示す。この例では、送信されるデータは、（図ではＶＦとラベル付けされている）ビデオフレーム（Video Frame）により構成されているビデオデータである。データソースは、特定のビデオフレームに関連付けられている（図ではＧＣＴＳ(Group Consumption Timestamp)とラベル付けされている）グループ消費タイムスタンプも送信する。この例では、各ビデオフレームは、全てのビデオフレームがＧＣＴＳを必要としないように、ビデオタイムスタンプも有する。図９は、ＧＣＴＳ1を、それが関連するデータとは別に送信することが出来ることも示す。ＧＣＴＳは、グループクロックで表される。ＧＣＴＳは、ローカル消費タイムスタンプ（ＬＣＴＳ）に変換されるであろう。ＬＣＴＳは、コンシューマのローカル時計で表される。

【0049】

図１０は、データの一部がコンシューマに既に届いていることを示す。コンシューマは、各ビデオフレームのローカル消費タイムスタンプ（ＬＣＴＳ）を計算しなければならないであろう。続く図は、これを詳細に示す。

【0050】

図１１は、３つのビデオフレームと1つのＧＣＴＳを既に受信しているコンシューマの詳細図を示す。

【0051】

図１２は、コンシューマが、各ビデオフレームについてローカル消費タイムスタンプを既に計算していることを示している。ＬＣＴＳ０は、ＧＣＴＳ０から直接計算される。ＬＣＴＳ１とＬＣＴＳ２は、２つのステップで計算される。まず、各ビデオフレームに関連付けられている持続時間情報を使用して、そのフレームのＧＣＴＳが推測される。次に、ＧＣＴＳは、通常どおりＬＣＴＳに変換される。例えば、ビデオフレームレートが２４フレーム／秒の場合、クライアントは、ＧＣＴＳ１ ＝ ＧＣＴＳ０ ＋ １／２４秒であると推測することが出来る。その後、クライアントは、通常どおりＧＣＴＳ１をＬＣＴＳ1に変換することが出来る。

【0052】

図１３は、より多くのデータが、コンシューマに届いていることを示す。つまり、より多くのビデオフレームと別のＧＣＴＳとが、到着している。

【0053】

図１４は、コンシューマが、ＬＣＴＳ３とＬＣＴＳ４を計算したことを示す。これらのＬＣＴＳは、図１２に記載された２段階法を使用して計算される。この図は、また、「...」というラベルの付いたボックスで示されるように、任意の数の追加ＬＣＴＳが計算されたことを示す。

【0054】

図１５は、ＬＣＴＳｋが計算されたことを示す。ＬＣＴＳｋは、データソースによって提供されたＧＣＴＳｋから直接計算することが出来る。

【0055】

図１６は、第２のコンシューマである、データコンシューマ２が、セッションに参加したことを示す。データコンシューマ２は同期ステップを実行する。一方、データコンシューマ１は、データソースからデータを受信し続ける。

【0056】

図１７は、データコンシューマ２が、データコンシューマ１が受信しつつあるデータと同じものを受信することを開始することを示している。この図は、データが、それがデータコンシューマ１に到着するよりも遅くまたは早くデータコンシューマ２に到着することがあることを示す。データコンシューマ２が、グループ消費タイムスタンプとそれに対応するデータ（例、GCTS₇₅およびVF₇₅）を受信するや否や、それは、グループの他のメンバと同期した状態でデータの消費を開始することが出来る。ストリーミングビデオのコンテキストでは、このステップは、映画の途中で映画館に入る人に似ている。

【0057】

図１８は、コンシューマが、クロック同期ステップを定期的に繰り返すことを示している。クロック間のドリフトは、時間とともに変化する可能性があるため、消費のより緊密な同期は、ドリフトを定期的に再計算することにより、保証されるであろう。再同期は、全てのグループメンバに対して同時に実行する必要は無い。コンシューマは、再同期を実行している間にデータの消費を続けることが出来る。データソースがそれ自体のローカルクロックを有する場合、それは、同期ステップを定期的に繰り返す必要もある。

【0058】

図１９は、各コンシューマがそれ自体のローカルクロックを有しているにもかかわらず、データが、同じグループ時刻に（例、同期した状態で）データコンシューマ１およびデータコンシューマ２によってどのように消費されるかを示す。この図では、消費されるデータは、ビデオである。フレームレートは２４フレーム／秒で、かつビデオのタイムベースは９０ｋHzである。従って、ビデオフレーム当たりのクロックティック数は、９０，０００ ／ ２４ ＝ ３，７５０である。この例では、グループメンバが、同期グループに参加するために正確なクロックを必要としないことを示すために、コンシューマのローカルクロックは、意図的に非現実的なものにしている。グループクロックのティックごとに、データコンシューマ１のクロックは、約０．００９９回ティックする。グループ時刻＝４５０，０００で、データコンシューマ１のクロックとグループクロックとの間のオフセットは、４４９，８５１である。グループクロックのティックごとに、データコンシューマ２のクロックは、約０．００２４回ティックする。グループ時刻＝４５０，０００で、データコンシューマ２のクロックとグループクロックとの間のオフセットは、４４９，１３１である。

【0059】

フレーム７３は、グループ時刻＝４４２，５００で再生される。これは、データコンシューマ１のローカル時刻＝７５に相当する。データコンシューマ２は、まだ、参加していない。

【0060】

フレーム時刻７４は、グループ時刻＝４４６，２５０で再生される。これは、データコンシューマ１のローカル時刻＝１１２に相当する。データコンシューマ２は、まだ、参加していない。

【0061】

フレーム７５は、グループ時刻＝４５０，０００で再生される。これは、データコンシューマ１のローカル時刻＝１４９に相当し、かつ参加したばかりのデータコンシューマ２のローカル時刻＝８６９に相当する。

【0062】

フレーム７６は、グループ時刻＝４５３，７５０で再生される。これは、データコンシューマ１のローカル時刻＝１８６に相当し、かつデータコンシューマ２のローカル時刻＝８７８に相当する。

【0063】

フレーム７７は、グループ時刻＝４５７，５００で再生される。これは、データコンシューマ１のローカル時刻＝２２３に相当し、データコンシューマ２のローカル時刻＝８８７に相当する。

【0064】

図２０は、本発明による、キューおよび同期されたデータ消費を示すブロック概略図である。この図の部分Ａは、クライアントのアプリケーションによって直接消費されるデータを示す。この場合、クライアントのアプリケーションは、消費のタイミングと方法を完全に制御する。ビデオ再生のコンテキストでは、これは、所望の時刻にビデオフレームをレンダリングすることのみを必要とする。

【0065】

図２０の部分Ｂでは、データの最終的なコンシューマは、サードパーティのアプリケーションである。この場合、クライアントのアプリケーションは、依然として、次のようにサードパーティのアプリケーションの消費のタイミングに影響を与える可能性がある。

【0066】

１）クライアントのアプリケーションは、サードパーティのアプリケーションにデータを供給するタイミングを制御することが出来る。クライアントのアプリケーションは、また、データフレームを削除したり、重複したデータフレームを送信したりすることもできるが、これは、後続のフレームが、サードパーティのアプリケーションによって消費される時刻に影響を与える。

【0067】

２）サードパーティのアプリケーションは、その状態に関する情報を提供し、かつ制御入力を受け入れることができる。制御入力の例には、サードパーティのアプリケーションの消費率（例、ビデオの再生率）を調整する機能、およびデータをスキップする、またはデータストリームの特定のポイントをシークする機能がある。クライアントのアプリケーションは、サードパーティのアプリケーションによって提供される情報を使用して、適切な制御入力を計算することが出来る。これは、消費が所望の消費タイムスタンプで発生すると言う結果をもたらし、これによりデータ消費の同期が維持されるであろう。

【0068】

００９１
図２１Ａ～２１Ｈは、本発明によるデータの優先度に基づく順序付けを示す。

【0069】

図２1Ａは、コンシューマの優先度キューを示す。コンシューマは、ローカル消費タイムスタンプ（および提供されている場合には、シーケンス番号）に基づいて、データフレームの優先度キューを維持する。遅れて到着するフレームは、破棄される、またはより高速で消費されるので、コンシューマは、グループの残りの部分に追いつくことが出来る。早く到着したチャンクは、優先度キューに配置される。この図では、優先度キューは1つのデータフレームを有する。

【0070】

図２１Ｂは、ネットワークを介して到着する新しいデータ（ビデオフレーム８０）を示す。データには、グループ消費タイムスタンプ（ＧＣＴＳ）が関連付けられている。

【0071】

図２１Ｃは、コンシューマが、新しいデータフレーム（ビデオフレーム８０）のローカル消費タイムスタンプ（ＬＣＴＳ）を計算したことを示す。

【0072】

図２１Ｄは、ビデオフレーム８０がビデオフレーム７５よりも遅いＬＣＴＳを有するので、新しいデータフレーム（ビデオフレーム８０）が、既存のデータフレーム（ビデオフレーム７５）より低い優先度で優先度キューに置かれていることを示す。

【0073】

図２１Ｅは、新しいデータフレーム（ビデオフレーム７６）が、ネットワークから到着したことを示す。このデータフレームには、明示的なＧＣＴＳは無い。

【0074】

図２１Ｆは、コンシューマが、ビデオフレーム７６のＬＣＴＳを計算することを示す。これは、新しいフレームのビデオタイムスタンプを、ＬＣＴＳが既知であるフレームのビデオタイムスタンプと比較し、かつクロックドリフトを考慮することにより行うことが出来る。

【0075】

図２１Ｇは、ビデオフレーム７６が、優先度キューに置かれようとしている状態を示す。

【0076】

図２１Ｈは、ビデオフレーム７６が優先度キューに置かれていることを示す。これは、ＬＣＴＳが遅いビデオフレーム８０よりも優先度が高い。これは、 ＬＣＴＳが早いビデオフレーム７５よりも優先順位が低い。

【0077】

図２２は、本発明による複数のデータストリームの消費の同期を示す。本発明を使用して、グループ間で同期した状態で複数のデータストリームを消費し、そして個々のコンシューマごとに複数のストリームの同期を維持することが出来る。例えば、コンシューマが、ビデオデータのストリームとオーディオデータのストリームを受信しつつ、かつメディアプレーヤで両方のストリームをレンダリングしつつある場合がある。２つのデータストリームがデータソースで既に同期されている場合（例えば、オーディオとビデオが同期した状態にある場合）、データソースによって割り当てられた消費タイムスタンプは、ビデオとオーディオがコンシューマで同期したままであることを保証するであろう。従って、全てのビデオおよび全てのオーディオデータは、全てのグループメンバ間で同期した状態で消費されるであろう。

【0078】

図２２は、データソースが、複数のデータストリームの同期を支援する追加情報を含む制御パケットを送信することが出来ることを示す。複数のデータストリームは、各ストリームのデータに関連付けられている消費タイムスタンプを使用して、同期させることが出来るので、この情報は、厳密には必要ではない。しかしながら、データソースが、1つのストリーム（例、ビデオ）のみに対して消費タイムスタンプを送信する方が便利な場合がある。この場合、これらの制御パケットにより、コンシューマが、他のストリーム（オーディオなど）を前述のストリーム（ビデオ）に同期させることが可能となるであろう。特定のＧＣＴＳパケットが失われたり破損したりした場合、これらの制御パケットを使用して２つのストリームを同期させることも出来る。

【0079】

図２３は、一実施形態による、複数のコンシューマの間でデータチャンクの消費を同期させる方法のフローチャートである。ステップ２３００において、１つ以上のコンシューマは、データチャンクの順序付けられたシーケンスを備える順序付けられたデータストリームを受信することが出来る。このデータチャンクは、ビデオフレーム、ビデオフレームのセクション、および／またはオーディオのセクションとすることが出来、他方この順序付けられたデータストリームは、ビデオファイルまたはオーディオファイルとすることが出来る。ステップ２３１０では、以下のステップを使用することにより、この順序付けられたデータストリーム内のデータチャンクの消費を、コンシューマ間で同期させることが出来る。

【0080】

ステップ２３２０において、この順序付けられたデータストリームの消費を開始する前に、プロセッサは、これらのコンシューマがこのデータチャンクを消費すべきグループ時刻を示すグループクロックと、コンシューマのローカル時刻を示すローカルクロックとを、同期させることが出来る。このプロセッサは、このローカル時刻とこのグループ時刻の間のマッピングを取得する。このプロセッサは、図１～２２に示されるように、コンシューマに関連付けることが出来る。

【0081】

例えば、グループクロックとローカルクロックを同期させるために、プロセッサは、このグループクロックに関連付けられている複数のグループ時刻と、このグループ時刻に対応する複数のローカル時刻とを取得することが出来る。段落００３５の「クロック同期の詳細な説明」のセクションで説明されているように、ローカル時刻は、グループ時刻を受信する際のネットワークレイテンシを考慮することが出来る。例えば、ネットワークレイテンシがない場合、ローカル時刻は、このグループ時刻を受信した時刻になる。しかしながら、プロセッサは、（このグループクロックによって送信されたこのグループ時刻が、コンシューマのプロセッサに到達する移動時間を意味する）このネットワークレイテンシを測定することが出来る。この場合、ローカル時刻は、（グループ時刻を受信したローカル時刻－グループ時刻の移動時間）として表すことが出来る。このグループ時刻とこれに対応するローカル時刻とに基づいて、このプロセッサは、式AAおよびBBに示されるこのグループクロックとこのローカルクロックとの間の線形対応を計算することが出来る。

【0082】

ステップ２３３０において、このプロセッサは、順序付けられたデータストリーム内のデータチャンクと、この順序付けられたデータストリーム内のこのデータチャンクに関連付けられているグループ時刻の表示とを、受信することが出来る。このグループ時刻の表示は、（本出願に記載されているように）データチャンクに関連付けられている実際のグループ時刻ＧＣＴＳとすることが出来る。さらに、このグループ時刻の表示は、（本出願に記載されているように、それからＧＣＴＳを計算することが出来る）ビデオタイムスタンプとすることが出来る。ステップ２３４０では、このグループ時刻、およびローカル時刻とグループ時刻との間のこのマッピングに基づいて、このプロセッサは、このローカルクロックに関連付けられている、このグループ時刻に対応するローカル時刻を計算することが出来る。

【0083】

ステップ２３５０において、このプロセッサは、このローカル時刻とこのローカルクロックに関連付けられている現在時刻とを比較して、このデータチャンクに関連付けられているこのローカル時刻が、この現在時刻より前であるか、この現在時刻と実質的に同一であるか、またはこの現在時刻より後である否かを示す比較を得ることが出来る。ステップ２３６０では、この比較に基づいて、このプロセッサは、このデータチャンクを削除する、このデータチャンクの持続時間を調整する、またはこのデータチャンクを消費することにより、これらのコンシューマがこのデータチャンクを同期した状態で消費することを保証することが出来る。このデータチャンクの持続時間は、この順序付けられたデータストリームの消費率、または後続のフレームの消費時刻に基づいて、計算することが出来る。例えば、この順序付けられたデータストリームの消費率は、１秒当たりのフレーム数の様な、１秒当たりのデータチャンクの数として表すことが出来る。従って、単一のデータチャンクの持続期間は、１秒／（１秒当たりのデータチャンクの数）に対応する。別の例では、データチャンクの持続時間は、（データチャンクマイニングに関連付けられているグループ時刻が、後続のデータチャンクに関連付けられているグループ時刻である）として計算することが出来る。

【0084】

プロセッサは、現在時刻がローカル時刻より前である（これは、後でこのデータチャンクを表示する必要があることを意味する）と決定することが出来る。プロセッサは、このデータチャンクに関連付けられているローカル時刻を示す場所に、このデータチャンクをデータチャンクの受信されたシーケンスで配置することが出来る。

【0085】

プロセッサは、現在時刻が、このローカル時刻およびこのデータチャンクの持続時間によって定義される時間範囲内にある（これは、このデータチャンクが、消費されつつあるプロセス内にあるべきであることを意味する）と決定することが出来る。プロセッサは、このデータチャンクの持続時間が、このデータチャンクの予定持続時間を超えないようにこのデータチャンクの持続時間を短縮させることが出来る。最後に、このデータチャンクを受信したこのコンシューマは、この短縮された持続時間に対応する時間の範囲で、このデータチャンクを消費することが出来る。

【0086】

このプロセッサは、この現在時刻がこのローカル時刻より後である、すなわち、このデータチャンクを消費する時刻が既に過ぎていると決定することが出来る。このプロセッサは、このデータチャンクを削除することが出来る。

【0087】

このプロセッサは、例えば、ネットワーク遅延またはネットワークエラーのために、以前に消費されたデータチャンクに続く第２のデータチャンクが、利用可能でないと判断することが出来る。このプロセッサは、この以前に消費されたデータチャンクの持続時間を延長して、順序付けられたデータストリームの消費が中断されることを防ぐことが出来る。

【0088】

このプロセッサは、ラッシュ同期以降に発生する２つのクロック間のドリフトの原因を除くために、この順序付けられたデータストリームの消費中に、このグループクロックとこのローカルクロックを同期させることが出来る。データストリームの消費中に時々同期を取ることにより、このプロセッサは、ローカル時刻とグループ時刻の間のマッピングを改善する。

【0089】

図２４は、別の実施形態による、複数のコンシューマの間でデータチャンクの消費を同期させる方法のフローチャートである。ステップ２４００では、グループクロックを、ハードウェアおよび／またはソフトウェアで定義することが出来る。例えば、このグループクロックは、物理クロックにする、またはソフトウェアアプリケーションとして実装することも出来る。このグループクロックは、順序付けられたデータストリーム内のデータチャンクが、複数のコンシューマによって消費されるタイミングを示すグループ時刻を測定することが出来る。このグループクロックは、図４～６に記載した方法で実装させることが出来る。

【0090】

ステップ２４１０において、プロセッサは、このグループクロックを、順序付けられたデータストリームの消費を要求するコンシューマに関連付けられている複数のローカルクロックに同期させることが出来る。同期させるために、このプロセッサは、これらのコンシューマに複数のグループ時刻を送信することが出来る。このプロセッサは、グループクロックで実装されたソフトウェアアプリケーションの命令を実行することが出来、または、このプロセッサは、ハードウェアおよび／またはソフトウェアで実装されたグループクロックと通信させることが出来る。このプロセッサは、図１、４、５に示されるサーバに関連付けることが出来る。

【0091】

ステップ２４２０において、このプロセッサは、データチャンクおよびこのデータチャンクに関連付けられているグループ時刻を、これらのコンシューマに送信することが出来る。このプロセッサは、グループ時刻とデータチャンクを、全てのコンシューマに同期した状態で送信する、またはこのプロセッサは、データチャンクのグループ時刻を非同期に、つまり、本出願、例えば、図１７に記載されているように、異なった時刻に、２つの異なるコンシューマに送信することが出来る。

【0092】

ステップ２４３０において、このプロセッサは、コンシューマからこのデータチャンクの到着時刻を受信することが出来る。このデータチャンクの到着時刻は、コンシューマが、ローカル時刻とグループ時刻の間のマッピングを確立することが出来るので、グループ時刻で表すことが出来る。換言すれば、このコンシューマは、このデータチャンクが到着したローカル時刻（すなわち、到着時刻）を知っているので、この到着時刻に対応するグループ時刻を計算することが出来る。このコンシューマは、この到着時刻に対応するグループ時刻をプロセッサに送信することが出来る。

【0093】

ステップ２４４０において、このデータチャンクの到着時刻およびこのデータチャンクに関連付けられているグループ時刻に基づいて、このプロセッサは、コンシューマがかなりの割合のデータチャンクを遅れて既に受信しているか否かを決定することが出来る。実質的な割合は１０％以上とすることが出来る。このデータチャンクの到着時刻がこのグループ時刻より後の場合、このプロセッサは、コンシューマがこのデータチャンクを遅れて既に受信していると注記することが出来る。

【0094】

例えば、データチャンクの１０％以上が遅れて受信されている場合、ステップ２４５０において、このプロセッサは、本出願に記載されているように、順序付けられたデータストリームのデータチャンクの品質またはレイテンシを調整することにより、これらのコンシューマがこの順序付けられたデータストリームを同期した状態で消費することを保証することが出来る。

【0095】

このデータチャンクの品質を調整するために、このプロセッサは、このデータチャンクに関連付けられている最小品質閾値を指定する設定を取得することが出来る。例えば、この品質閾値は、ビデオのビットレートが、毎秒２．５メガビットより大でなければならないと指定することが出来る。

【0096】

このプロセッサは、データチャンクの品質を最小品質閾値まで低下させることにより、コンシューマが、実質的な割合のデータチャンクを遅れて受信することが、防止されるか否かを、決定することが出来る。例えば、このプロセッサは、ビデオのビットレートを最低品質に下げることが出来、そしてコンシューマから収集した到着時刻に基づいて、かなりの割合のデータチャンクをまだ受信していないコンシューマが、存在するか否かを決定することが出来る。別の例では、このプロセッサは、例えば、
ネットワークスループット＝Σ（コンシューマに配信されるデータ）／Σ（到着時刻－対応するグループ時刻）
を計算することにより、到着時刻に対応するグループ時刻に基づいて、最低のネットワークスループットを決定することが出来る。

【0097】

このネットワークスループットが、最小ビットレート以上である場合、このプロセッサは、入力の品質を低下させることが出来る。具体的には、このプロセッサは、入力の品質を、ネットワークスループット以下のビットレートに低下させ、そしてこのデータチャンクを、かなりの割合のデータチャンクを遅れて受信しているコンシューマに送信することが出来る。残りのコンシューマは、より高品質のデータチャンクを受信することが出来る。

【0098】

このネットワークスループットが、最小ビットレートよりも低い場合、このプロセッサは入力の品質を低下させることは出来ない。代わりに、このプロセッサは、このデータチャンクに関連付けられるレイテンシを増加させることが出来る。具体的には、このプロセッサは、このデータチャンクに関連付けられているグループ時刻を増大させることが出来るので、このグループ時刻は、このデータチャンクを最も遅くに受信するコンシューマにおけるこのデータチャンクの到着時刻と同じまたはそれよりわずか遅れる時刻となる。このようにして、このプロセッサは、各コンシューマがデータチャンクを消費すると同時に、このコンシューマが最新の時刻にこのデータチャンクを受信することを保障することが出来る。この結果、このプロセッサは、これらのコンシューマ間の消費の同期を保障することが出来る。

【0099】

このプロセッサは、これらのコンシューマがこのデータストリームを消費している間に、これらのコンシューマに加わる新しいコンシューマから要求を受信することが出来る。このプロセッサは、新しいコンシューマに、第２のデータチャンクと、この第２のデータチャンクに関連付けられている第２のグループ時刻を送信することが出来る。この第２のグループ時刻は、現在これらのコンシューマに送信されつつあるグループ時刻よりも遅くすることが出来る。

【0100】

コンピュータシステム
図２５は、いくつかの実施形態の特定の特徴を実装するために使用することができるコンピュータシステムのブロック図である。このコンピュータシステムは、サーバコンピュータ、クライアントコンピュータ、パーソナルコンピュータ（ＰＣ）、ユーザーデバイス、タブレットＰＣ、ラップトップコンピュータ、携帯情報端末（ＰＤＡ）、携帯電話、ｉＰｈｏｎｅ、ｉＰａｄ、Ｂｌａｃｋｂｅｒｒｙ、プロセッサ、電話、Ｗｅｂアプライアンス、ネットワークルーター、スイッチまたはブリッジ、コンソール、ハンドヘルドコンソール、（ハンドヘルド）ゲームデバイス、音楽プレーヤ、任意のポータブルでモバイルのハンド-ハンドヘルドデバイス、ウェアラブルデバイス、またはそのマシンが実行するアクションを指定するシーケンシャルまたはそれ以外の一連の命令を実行することが可能な任意のマシンとすることができる。

【0101】

このコンピューティングシステム２５００は、１つまたは複数の中央処理装置（「プロセッサ」）２５０５、メモリ２５１０、入／出力デバイス２５２５（例、キーボードおよびポインティングデバイス、タッチデバイス、ディスプレイデバイス）、ストレージデバイス２５２０（例、ディスクドライブ）およびネットワークアダプタ２５３０（例、相互接続２５１５に接続されるネットワークインターフェース）を含むことができる。この相互接続２５１５は、1つ以上の個別の物理バス、ポイントツーポイント接続、または適切なブリッジ、アダプタ、またはコントローラーによって接続された両方、を表す抽象概念として示されている。従って、相互接続２５１５は、例えば、システムバス、周辺機器相互接続（ＰＣＩ）バスまたはＰＣＩ－Ｅｘｐｒｅｓｓバス、ＨｙｐｅｒＴｒａｎｓｐｏｒｔまたは業界標準アーキテクチャ（ＩＳＡ）バス、小型コンピュータシステムインターフェース（ＳＣＳＩ）バスを含むことができる。ユニバーサルシリアルバス（ＵＳＢ）、ＩＩＣ（Ｉ２Ｃ）バス、または米国電気電子学会（ＩＥＥＥ）標準の１３９４バス（Ｆｉｒｅｗｉｒｅとも呼ばれる）を含むことができる。

【0102】

メモリ２５１０および記憶装置２５２０は、様々な実施形態の少なくとも一部を実施する命令を記憶することができるコンピュータ可読記憶媒体である。加えて、このデータ構造およびメッセージ構造は、データ送信媒体（例、通信リンク上の信号）を介して記憶させまたは転送させることができる。様々な通信リンク（例、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、またはポイントツーポイントダイヤルアップ接続）を使用することができる。従って、コンピュータ可読媒体は、コンピュータ可読記憶媒体、例えば、を含むことが出来る。非一時的なメディア、およびコンピュータで読み取り可能な伝送メディアを含むことが出来る。

【0103】

メモリ２５１０に記憶された命令は、ソフトウェアおよび／またはファームウェアとして実装させて、プロセッサ２５０５が上述の動作を実行するようにプログラムすることが出来る。いくつかの実施形態では、このようなソフトウェアまたはファームウェアは、コンピューティングシステム２５００を介して（例、ネットワークアダプタ２５３０経由で）リモートシステムからそれをダウンロードすることにより、先ず、コンピューティングシステム２５００に提供させることができる。

【0104】

本明細書で紹介された様々な実施形態は、例えば、プログラマブル回路、例えば、ソフトウェアおよび／またはファームウェアでプログラムされた1つ以上のマイクロプロセッサ、または完全専用ハードワイヤード（プログラム不可）回路で、またはそのような形式の組み合わせで実装させることができる。専用ハードワイヤード回路は、例えば、1つまたは複数のＡＳＩＣ、ＰＬＤ、ＦＰＧＡなどの形式とすることができる。

【0105】

備考
本明細書で使用される言語は、主に読み易さおよび説明目的のために選択されており、そして本発明の主題を描写または制限するために選択されていない場合がある。従って、本発明の範囲は、この詳細な説明によって限定されるのではなく、本明細書に基づく出願に基づいて発行される請求項によって限定されることが、意図されている。従って、様々な実施形態の開示は、添付の特許請求の範囲に記載されている実施形態の範囲を例示することを意図したものであり、限定することを意図したものではない。

【0106】

優先権の主張
本出願は、２０１７年４月２４日に出願された米国仮特許出願第６２ ／ ４８９，２６４号の優先権を主張し、その全体が参照により本明細書に組み込まれる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21A】

【図21B】

【図21C】

【図21D】

【図21E】

【図21F】

【図21G】

【図21H】

【図22】

【図23】

【図24】

【図25】