特許 6290915 共通イベントベースのマルチデバイスメディア再生

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

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

(11)【特許番号】6290915

(24)【登録日】2018年2月16日

(45)【発行日】2018年3月7日

(54)【発明の名称】共通イベントベースのマルチデバイスメディア再生

(51)【国際特許分類】

   H04N 21/43 20110101AFI20180226BHJP

   H04N 21/65 20110101ALI20180226BHJP

   H04L 7/00 20060101ALI20180226BHJP

   H04L 7/04 20060101ALI20180226BHJP

【ＦＩ】

   H04N21/43

   H04N21/65

   H04L7/00 930

   H04L7/04

【請求項の数】15

【全頁数】28

(21)【出願番号】特願2015-543100(P2015-543100)

(86)(22)【出願日】2013年11月18日

(65)【公表番号】特表2016-503623(P2016-503623A)

(43)【公表日】2016年2月4日

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

(87)【国際公開番号】WO2014078818

(87)【国際公開日】20140522

【審査請求日】2016年10月31日

(31)【優先権主張番号】61/727,624

(32)【優先日】2012年11月16日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】515132869

【氏名又は名称】ブラックファイヤー リサーチ コーポレイション

【氏名又は名称原語表記】ＢＬＡＣＫＦＩＲＥ ＲＥＳＥＡＲＣＨ ＣＯＲＰＯＲＡＴＩＯＮ

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(74)【代理人】

【識別番号】100142907

【弁理士】

【氏名又は名称】本田 淳

(72)【発明者】

【氏名】ラヴィ、ラージャパクセ

【審査官】 久保 光宏

(56)【参考文献】

【文献】 国際公開第２００７／０８７６４４（ＷＯ，Ａ２）

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

【文献】 特開２００１−７５５５３（ＪＰ，Ａ）

【文献】 特開平８−３０５６４５（ＪＰ，Ａ）

【文献】 特表２００４−５３６５３８（ＪＰ，Ａ）

【文献】 国際公開第２０１１／０７７５５８（ＷＯ，Ａ１）

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

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

Ｈ０４Ｌ７／００−７／１０

ＣＳＤＢ（日本国特許庁）

ＩＥＥＥＸｐｌｏｒｅ（ＩＥＥＥ）

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

【請求項1】

イベントベース同期型マルチメディア再生システムであって、
各々ローカルクロックを備えるとともにネットワークに接続され、前記ネットワークを介して受信したメディアをレンダリングするように構成された複数の宛先デバイスと、
前記ネットワークに接続されたデバイス上で動作するとともに前記複数の宛先デバイスと通信するように構成された同期モジュールであって、一意のイベント識別子ｎを有する共通イベントＥｎを、前記複数の宛先デバイスの各々に定期的に送信する前記同期モジュールと、
を備え、
各宛先デバイスは、イベントＥｎが受信される時刻Ｄｘｎを記録し、少なくとも前記時刻Ｄｘｎ及び前記一意のイベント識別子ｎを含む肯定応答メッセージを送信し、
前記同期モジュールは更に、前記複数の宛先デバイスの各々について、
（ａ）各宛先デバイスのローカルクロックと第１の宛先デバイスのローカルクロックとの周波数差を特定するステップと、
（ｂ）前記第１の宛先デバイスと各宛先デバイスとの間における（ａ）で特定された差を補償する周波数調整値を計算するステップと、
（ｃ）（ｂ）で求められた周波数調整値に関連する量だけクロック周波数を調整する処理、及び（ｂ）で求められた周波数調整値に関連する周波数調整を実行するべくメディアソースデバイスから受信したメディアのサンプルレート変換を行う処理のうちの少なくとも一方を行うように各宛先デバイスに指示するステップと
を実行するものであり、
各宛先デバイスは、前記同期モジュールが前記各ステップを実行することにより、オーディオメディア又はビデオメディアをストリーミングするように構成されたメディアソースデバイスから前記ネットワークを介して受信したメディアを同期してレンダリングする、システム。

【請求項2】

前記宛先デバイスは、前記周波数調整値を使用して、前記メディアのレンダリングに使用されるローカルクロックを調整する、請求項１に記載のシステム。

【請求項3】

前記宛先デバイスは、クロック周波数を調整する代わりに、前記周波数調整値を使用して、前記メディアのレンダリング前に前記メディアのサンプルレート変換を実行する、請求項１に記載のシステム。

【請求項4】

共通イベントベース同期型マルチメディア再生方法であって、
（ａ）ネットワークに接続されたデバイスで動作する同期モジュールから一意のイベント識別子ｎを有する共通イベントＥｎを定期的に送信するステップと、
（ｂ）前記ネットワークを介して、ローカルクロックを備える複数の宛先デバイスの各々で前記イベントＥｎを受信するステップと、
（ｃ）各宛先デバイスで、イベントＥｎが受信される時刻Ｄｘｎを記録するステップと、
（ｄ）各宛先デバイスから前記同期モジュールに、少なくとも前記時刻Ｄｘｎ及び前記一意のイベント識別子ｎを含む肯定応答メッセージを送信するステップと、
（ｅ）各宛先デバイスの前記ローカルクロック間の周波数差を前記同期モジュールにより特定するステップと、
（ｆ）ステップ（ｅ）において特定された差を補償する周波数調整値を計算するステップと、
（ｇ）ステップ（ｆ）において求められた周波数調整値に関連する量だけクロック周波数を調整する処理、及びステップ（ｆ）で求められた周波数調整値に関連する周波数調整を実行するべくメディアソースデバイスから受信したメディアのサンプルレート変換を行う処理のうちの少なくとも一方を行うように各宛先デバイスに指示するステップと、
（ｈ）各宛先デバイスが、この周波数調整値を使用して、オーディオメディア又はビデオメディアをストリーミングするメディアソースデバイスから前記ネットワークを介して受信したメディアを同期してレンダリングするステップと、
を備える方法。

【請求項5】

前記宛先デバイスは、前記周波数調整値を使用して、前記メディアのレンダリングに使用されるローカルクロックを調整する、請求項４に記載の方法。

【請求項6】

前記宛先デバイスは、クロック周波数を調整する代わりに、前記周波数調整値を使用して、前記メディアのレンダリング前に前記メディアのサンプルレート変換を実行する、請求項４に記載の方法。

【請求項7】

イベントベース同期型マルチメディア再生システムであって、
各々ローカルクロックを備えるとともにネットワークに接続され、前記ネットワークを介して受信したメディアをレンダリングするように構成された複数の宛先デバイスと、
前記ネットワークに接続されたデバイス上で動作するとともに前記複数の宛先デバイスと通信するように構成された同期モジュールと、
を備え、
前記同期モジュールは、複数の肯定応答メッセージをイベントＥｎ毎の収集情報として収集し、受信したイベント識別子ｎを有する肯定応答メッセージの収集情報を取得して、イベントＥｎについての肯定応答メッセージのサブセットを作成し、イベントＥｎについての前記肯定応答メッセージのサブセットを使用することにより第１の宛先デバイス用の周波数調整値を計算し、前記第１の宛先デバイスに対し、
前記計算された周波数調整値に関連する量だけクロック周波数を調整する処理、または、
前記計算された周波数調整値に関連する周波数調整を実行するべくメディアソースデバイスから受信したメディアのサンプルレート変換を行う処理
を実行するように指示する、システム。

【請求項8】

各宛先デバイスによって受信されるイベントメッセージが前記同期モジュールから発せられる、請求項７に記載のシステム。

【請求項9】

各宛先デバイスによって受信されるイベントメッセージが、前記複数の宛先デバイス、前記メディアソースデバイス、及び前記同期モジュール以外の外部ソースから発せられる、請求項７に記載のシステム。

【請求項10】

前記同期モジュールは更に、前記複数の宛先デバイスの各々について、
（ａ）各宛先デバイスのローカルクロックと第１の宛先デバイスのローカルクロックとのクロックオフセットを特定するステップと、
（ｂ）前記クロックオフセットだけクロックカウント又は位相を調整するように各宛先デバイスに指示するステップと
を実行する、請求項１に記載のシステム。

【請求項11】

前記同期モジュールは更に、前記複数の宛先デバイスの各々について、
（ａ）各宛先デバイスのローカルクロックと第１の宛先デバイスのローカルクロックとのクロックオフセットを特定するステップと、
（ｂ）前記クロックオフセットだけクロックカウント又は位相を調整するように各宛先デバイスに指示するステップと
を実行する、請求項４に記載の方法。

【請求項12】

前記同期モジュールは更に、前記複数の宛先デバイスの各々について、
（ａ）各宛先デバイスのローカルクロックと第１の宛先デバイスのローカルクロックとのクロックオフセットを特定するステップと、
（ｂ）前記クロックオフセットだけクロックカウント又は位相を調整するように各宛先デバイスに指示するステップと
を実行する、請求項７に記載のシステム。

【請求項13】

イベントベース同期型マルチメディア再生システムであって、
各々ローカルクロックを備えるとともにネットワークに接続され、前記ネットワークを介して受信したメディアをレンダリングするように構成された複数の宛先デバイスと、
前記複数の宛先デバイスのうちの１つで動作する同期モジュールと、
を備え、
前記同期モジュールは、一意のイベント識別子ｎを有する共通イベントＥｎを、前記複数の宛先デバイスの各々に定期的に送信し、
各宛先デバイスは、イベントＥｎを受信した時刻Ｄｘｎを記録し、少なくとも前記時刻Ｄｘｎ及び前記一意のイベント識別子ｎを含む肯定応答メッセージを前記同期モジュールに返信し、
前記同期モジュールは、前記複数の宛先デバイスの各々について、
（ａ）各宛先デバイスのローカルクロックと第１の宛先デバイスのローカルクロックとの周波数差を特定するステップと、
（ｂ）前記第１の宛先デバイスと各宛先デバイスとの間における（ａ）で特定された差を補償する周波数調整値を計算するステップと、
（ｃ）（ｂ）で求められた周波数調整値に関連する量だけクロック周波数を調整する処理、及び（ｂ）で求められた周波数調整値に関連する周波数調整を実行するべくメディアソースデバイスから受信したメディアのサンプルレート変換を行う処理のうちの少なくとも一方を行うように各宛先デバイスに指示するステップと
を実行するように構成されている、システム。

【請求項14】

イベントベース同期型マルチメディア再生システムであって、
少なくともメモリとプロセッサとを備えるデバイス上で動作し、ネットワークに接続された同期モジュールを備え、
前記同期モジュールは、前記ネットワークを介して、一意のイベント識別子ｎを有する共通イベントＥｎを複数の宛先デバイスの各々に定期的に送信し、
前記同期モジュールは、前記ネットワークを介して複数の肯定応答メッセージを受信し、各肯定応答メッセージは、対応するイベントＥｎが特定の宛先デバイスで受信された時刻Ｄｘｎ及び前記一意のイベント識別子ｎを少なくとも含むものであり、
前記同期モジュールは、前記複数の宛先デバイスの各々について、
（ａ）各宛先デバイスのローカルクロックと第１の宛先デバイスのローカルクロックとの周波数差を特定するステップと、
（ｂ）前記第１の宛先デバイスと各宛先デバイスとの間における（ａ）で特定された差を補償する周波数調整値を計算するステップと、
（ｃ）（ｂ）で求められた周波数調整値に関連する量だけクロック周波数を調整する処理、及び（ｂ）で求められた周波数調整値に関連する周波数調整を実行するべくメディアソースデバイスから受信したメディアのサンプルレート変換を行う処理のうちの少なくとも一方を行うように各宛先デバイスに指示する指示メッセージを各宛先デバイスに送信するステップと
を実行する、システム。

【請求項15】

共通イベントベース同期型マルチメディア再生方法であって、
（ａ）少なくともメモリとプロセッサとを備えるとともにネットワークに接続された同期デバイスから、各々一意のイベント識別子ｎを有する複数の共通イベントＥｎを送信するステップと、
（ｂ）前記同期デバイスで複数の宛先デバイスからの複数の肯定応答メッセージを受信するステップであって、共通イベントＥｎが特定の宛先デバイスで受信された時刻Ｄｘｎ及び前記一意のイベント識別子ｎを各々少なくとも含む複数の肯定応答メッセージを受信するステップと、
（ｃ）前記複数の肯定応答メッセージに基づいて、各宛先デバイスのクロック間の周波数差を前記同期デバイスで特定するステップと、
（ｄ）ステップ（ｃ）において特定された差を補償する周波数調整値を前記同期デバイスで計算するステップと、
（ｅ）ステップ（ｄ）において求められた周波数調整値に関連する量だけクロック周波数を調整する処理、及びステップ（ｄ）で求められた周波数調整値に関連する周波数調整を実行するべくメディアソースデバイスから受信したメディアのサンプルレート変換を行う処理のうちの少なくとも一方を行うように各宛先デバイスに指示メッセージを送信するステップと、
を備える方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、デジタルメディアの分野に関し、特に、デジタルマルチメディア同期再生の分野に関する。

【背景技術】

【0002】

今日、多くの形態のデジタルメディア、多くのタイプのデジタルメディアソース、多くのタイプのデジタルメディア再生（レンダリング）システム、及びメディアソースをメディア再生システムに接続する多くの方法がある。

【0003】

以下、メディアと呼ぶデジタルメディアは、デジタルビデオディスク、メディアファイル、及びメディアストリームを含む多くの形態、フォーマット、及びコンテナで提供される。メディアコンテンツは、オーディオ、ビデオ、イメージ、又はメタデータメディアコンポーネント、及びそれぞれの様々な組み合わせであることができる。例えば、普及しているオーディオフォーマットはＭＰ３として知られており、普及しているビデオフォーマットはＨ２６４である。ＭＰ３は、動画専門家集団（ＭＰＥＧ）によりＭＰＥＧ−１規格の一環として設計され、後にＭＰＥＧ−２規格で拡張されたオーディオ固有のメディアフォーマットである。Ｈ２６４は、国際標準化機構（ＩＳＯ）／国際電気標準会議（ＩＥＣ）共同作業部会である動画専門家集団（ＭＰＥＧ）によって開発された規格である。動画は通常、ビデオチャネル及び複数のオーディオチャネルを内部に有するマルチメディアフォーマットである。例えば、５．１動画は、１つのビデオチャネル（メディアコンポーネント）と、６つのオーディオチャネル（オーディオコンポーネント）とを含む。５．１は、６チャネルサラウンド音響マルチチャネルオーディオシステムの一般名称である。

【0004】

デジタルメディアソースは、デジタルビデオディスクプレーヤ、ブルーレイプレーヤ、コンピュータ及びモバイルデバイス等のメディアデバイス並びにインターネットベースの「クラウド」メディアサービスを含む。ブルーレイディスク（ＢＤ）は、ブルーレイディスクアソシエーションによって開発された光ディスク記憶媒体である。インターネットベースのメディアサービスは、ネットフリックス（Netflix）（登録商標）及びスポティファイ（Spotify）（登録商標）等のサービスを含む。ネットフリックスは、ネットフリックス社（Netflix Inc.）のメディアサービスであり、商標である。スポティファイは、スポティファイ有限会社（Spotify Ltd.）のメディアサービスであり、商標である。デジタルメディア再生（メディアレンダリング宛先）システムは、コンピュータベースのデバイス、ラップトップ、及びスマートフォン、並びにネットワークオーディオ及びビデオデバイスを含む。スマートＴＶ（SmartTV）は、ネットフリック等のインターネット（クラウド）ベースのメディアサービスからメディアを再生することができるデジタルメディアレンダリングデバイスの一例である。スマートＴＶは、「コネクトＴＶ（Connected TV）」又は「ハイブリッドＴＶ（Hybrid TV）」と呼ばれることもあり、近代のテレビセット及びセットトップボックスへのインターネット及びウェブの特徴の統合と、コンピュータとこれらのテレビセット／セットトップボックスとの間の技術的収束とを記述するために使用される。インターネットラジオデバイスは、デジタルメディアレンダリングデバイスの別の例である。

【0005】

これらのメディアソースとデバイスとの接続は様々であるが、インターネットプロトコル（ＩＰ）プロトコルを使用するネットワークベースの接続に向かって経時進化している。これは、ＩＰ接続が便利であり、普遍的であり、安価であるためである。

【0006】

ＩＰネットワークは多くの形態で提供される。最も普及しているのは、イーサネット（登録商標）ベースの有線ＩＰネットワーキングである。イーサネットは、ＩＥＥＥ（米電気電子技術者協会）規格８０２．３として標準化されたローカルエリアネットワーク（ＬＡＮ）のコンピュータネットワーキング技術のファミリである。近年、モバイル計算デバイスの普及に伴い、Ｗｉ−Ｆｉ（登録商標）（ＩＰネットワークの一種）が、ネットワークデバイスを無線接続する最も普及した手段になった。Ｗｉ−ＦｉはＷｉ−Ｆｉアライアンス（Wi-Fi Alliance）の商標であり、標準のＩＥＥＥ８０２．１１ファミリを使用する製品のブランド名である。ＩＰネットワークは、ユニキャスト、マルチキャスト、及びブロードキャストメッセージングを含む幾つかの異なるタイプのメッセージングを使用することができ、そのようなメッセージングは、ＩＰパケットの送信である。

【0007】

「ユニキャスト」という用語は、情報が１つのみの送信者から１つのみの受信者に送信されるタイプのインターネットプロトコル伝送を指すために使用し得る。換言すれば、ユニキャスト伝送は、２つのみのノード間での１対１ノード伝送である。ユニキャストでは、各出力パケットはユニキャスト宛先アドレスを有し、これは、パケットがそのアドレスを有する特定の宛先に向けられることを意味する。そのパケットをリッスンし得る全ての他の宛先は、パケットの宛先アドレスがその宛先のアドレスと同じではない場合、パケットを無視する。

【0008】

多くのＩＰプロトコルは、ソケットアプリケーションプログラミングインタフェースを介してソフトウェアプログラムからアクセスされる。このソケットインタフェースは、ＰＯＳＩＸ規格の一環として定義されている。ＰＯＳＩＸは、オペレーティングシステムの互換性を維持するためにＩＥＥＥによって指定される規格のファミリである「ポータブルオペレーティングシステムインタフェース」の頭字語である。

【0009】

ＩＰネットワーキングの利便性及び利点は、これらのメディアソース及び再生システムの全てが、まだネットワーク対応ではない場合、ネットワーク対応になりつつあることを意味する。多くのブルーレイプレーヤが現在では、イーサネット及びＷｉ−Ｆｉネットワーク接続を有する。今日、大半のよりハイエンドのＴＶは、ネットワーク機能を有するスマートＴＶである。同様に、オーディオ再生デバイス及びラジオであっても、ネットワーク及びインターネット対応である。

【0010】

携帯電話、タブレット、ドキュメントリーダ、又はノートブック等のモバイルデバイスは、メディアを受信して記憶することができ、強力なマルチメディア（オーディオ及びビデオ）機能を有し、高帯域幅であり、広く深いコンテンツを有するオンラインメディアサービスにアクセスすることができるセル電話データサービス又はブロードバンドリンク（Ｗｉ−Ｆｉ等）を介してインターネットに接続し得る。

【0011】

これらの様々な形態のデジタルメディア、メディアサービス及びメディアソース、並びに再生システムの使用事例又は用途は進化してきた。当初、ＩＰネットワークを介してメディア宛先にメディアソースを接続するだけで十分であった。これは今日、ネットフリックス等のインターネットベースのメディアソースサービス及びメディア宛先等のコンピュータと広く併用されている。ユーザは、有線ＩＰネットワーク（インターネット）を介してコンピュータにストリーミングされるネットフリックス動画を見る。これは、有線ＩＰネットワークを介するシングルポイント（１つのＩＰソース）−シングルポイント（１つのＩＰ宛先）接続の場合である。ネットフリックスメディアサービスは同じメディアを複数の仮定に送信し得るが、これらの各々はシングルポイント−シングルポイントＴＣＰ／ＩＰ接続である。この更なる進化は、有線イーサネット接続の代わりに、無線Ｗｉ−Ｆｉ接続を使用することである。それでもこれはなお、シングルポイント−シングルポイント接続である。

【0012】

メディアソースが単一の宛先ではなく複数の宛先に接続する、上記使用事例の更なる拡張が存在する。これらはシングルポイント（１つのＩＰソース）−マルチポイント（複数のＩＰ宛先）用途である。一例は、ユーザが、無線ビデオ再生デバイスに対して５．１動画メディアファイルを再生しており、６つの独立無線オーディオ宛先が完全な５．１サラウンド音響システムを構成する場合である。この場合、メディアは、１つのメディアソースから７つのメディア宛先に同時に送信されている。別の例では、ユーザは、１つのメディアソースから、家の６つの異なる部屋のあちこちに配置された６つの再生システムに向けて音楽を再生している。

【0013】

これらの両事例において、全ての宛先でメディアを時間同期して再生（レンダリング）する必要がある。さらに、メモリの使用を最小に維持するなど、メディアソースでのリソースの使用を制限する必要がある。加えて、メディアを受信する複数のデバイスがネットワーク帯域幅を効率的に管理する必要がある。

【0014】

現在、同じメディアデータを複数のネットワーク宛先に送信する必要がある場合、そうする一般的な技法は、データを受信する必要がある複数の宛先へのデータマルチキャストを使用することである。そのようなシステムでは、メディアは全ての宛先にマルチキャストされ、メディアを適宜レンダリングしようとすることは、各宛先次第である。レンダリング中、レンダラーが新しいメディアデータを受信しないか、又は正しく受信しないエラーがある場合、レンダラーは、誤ったデータをレンダリングし、次に、正確なデータを受信したとき、エラー後のポイントから正確なメディアを復元して正確なメディアレンダリングを継続し得る。

【発明の概要】

【発明が解決しようとする課題】

【0015】

ここで考えられる用途では、メディアをソースから、同じ聴取及び閲覧空間内のＴＶ及びスピーカ等の複数のメディアデバイスに送信する必要がある。さらに、このメディアをＷｉ−Ｆｉ等の無線ネットワークを介して送信する必要がある。

【0016】

これらの用途では、これは聴き手及び／又は閲覧者がいかなる非意図的なメディア経験にも気付かないように、同じ聴取又は閲覧ゾーン内にあるスピーカ等の全てのメディアレンダリングデバイスを互いに精密に同期する必要があることを意味する。

【0017】

第二に、メディアは無線を介してトランスポートされるため、メディアが各宛先で確実に受信されないか、又は均一に受信されないメディアエラーの可能性が非情に高い。パケットの送信にブロードキャスト又はマルチキャストを使用する場合、同じブロードキャスト又はマルチキャストパケットは、ある宛先では受信されるが、別の宛先で受信／リッスンされないことがある。

【課題を解決するための手段】

【0018】

複数のメディア受信デバイスに送信される場合、メディアエラー及び同期損失という上記問題を解決するイベントベース同期型マルチメディア再生の方法が開示される。
好ましい実施形態によれば、結晶クロックサイクルに基づく同期を通して、各々オーディオ位相及びタイミングを維持する複数のメディア再生デバイスを備えるイベントベース同期型マルチメディア再生システムが開示される。この実施形態によれば、複数のメディア再生デバイスは、インターネット又はＩＰプロトコルを利用する任意の他のデータネットワーク等のＩＰ対応ネットワークにより、複数のメディアソースデバイスに接続し得る。メディアは、そのようなネットワークを介して再生デバイスにブロードキャストし得、各再生デバイスは、再生中に望ましいであろう同様又は別個のメディア要素を再生し得る（例えば、当技術分野の音響システムで一般的なように、１つのスピーカが左オーディオチャネルを再生し得、一方、第２のスピーカが右オーディオチャネルを再生し得る）。

【0019】

好ましい実施形態によれば、メディアソースデバイスと、各々ローカルクロックを備える複数の宛先デバイスとを備えるイベントベース同期型マルチメディア再生システムが開示される。メディアソースデバイス内の同期モジュールは、メディアソースにおいて一意のイベント番号ｎを含む共通イベントＥ_ｎを複数の宛先デバイスの各々に送信する。各宛先デバイスは、イベントＥ_ｎを受信した時刻Ｄｘ_ｎを記録して、その時刻Ｄｘ_ｎ及び一意のイベント番号ｎを含む肯定応答メッセージを同期モジュールに返信する。同期モジュールは、複数の受信デバイスの各々について、各受信デバイスのクロック信号間の位相差及び周波数差を特定し、差を補償する位相調整値及び周波数調整値を計算し、それに従ってクロック位相及び周波数を調整するように各宛先デバイスに指示する。各受信デバイスは、所望値にローカルクロックを調整し、サンプルレート変換を実行して、メディア再生を同期させる。

【0020】

別の好ましい実施形態によれば、イベントベース同期型マルチメディア再生方法が開示され、本方法は、（ａ）同期モジュールを含み、ネットワークに接続され、ネットワークを介してメディアをストリーミングするように構成されたメディアソースデバイスから、一意のイベント番号ｎを含む共通イベントＥ_ｎを定期的に送信するステップと、（ｂ）ローカルクロックを備える複数の受信デバイスの各々でネットワークを介してイベントＥ_ｎを受信するステップと、（ｃ）イベントＥ_ｎを受信した時刻Ｄｘ_ｎを各受信デバイスで記録するステップと、（ｄ）少なくとも時刻Ｄｘ_ｎ及び一意のイベント番号ｎを含む肯定応答メッセージを各受信デバイスからメディアソースに返信するステップと、（ｅ）メディアソースデバイス及び複数の宛先デバイスのうちの１つに記憶され、そこで動作する同期モジュールを使用して、各宛先デバイスのクロック信号の位相差及び周波数差を特定するステップと、（ｆ）ステップ（ｅ）で特定された位相差及び周波数差を補償する周波数調整値を計算するステップと、（ｇ）ステップ（ｆ）で計算された周波数調整値に等しい量だけクロックの位相及び周波数を調整するように各受信デバイスに指示するステップと、（ｈ）ステップ（ｃ）で指示されたように各受信デバイスのローカルクロックを調整してメディア再生を同期させるステップとを含む。

【0021】

添付図面は、開示される構成の幾つかの実施形態を示し、説明と一緒に、実施形態による本発明の原理を説明する役割を果たす。図面に示される特定の実施形態は単なる例示であり、開示される実施形態の範囲を限定することを意図しないことを当業者は認識し得る。

【図面の簡単な説明】

【0022】

【図1】本発明の一実施形態による、２つのオーディオサブシステムを備える例示的なマルチメディアシステムの図である。

【図2】本発明の一実施形態による、例示的なオーディオ再生システムの詳細図である。

【図3】本発明の一実施形態による、時間参照のための例示的なクロックベースシステムの図である。

【図4】本発明の一実施形態による例示的なメッセージ時系列の図である。

【図5】本発明の一実施形態による例示的な共通イベントベースのシステムの図である。

【図6】本発明の一実施形態による例示的なイベント時系列の図である。

【図7】共通クロック方法と本発明の一実施形態による共通イベント方法との違いを詳述する図である。

【図8】本発明の一実施形態による共通イベントベースのシステムの全体的な効果の図である。

【図9】本発明の一実施形態による共通イベントベースのアルゴリズムを使用する全体的な効果の図である。

【図10】本発明の一実施形態で使用される計算デバイスの例示的なハードウェアアーキテクチャを示すブロック図である。

【図11】本発明の一実施形態による、クライアントデバイスの例示的な論理アーキテクチャを示すブロック図である。

【図12】本発明の一実施形態による、クライアント、サーバ、及び外部サービスの例示的な構造構成を示すブロック図である。

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

【0023】

「ユニキャスト」という用語は、情報が１つのみの送信者から１つのみの受信者に送信されるインターネットプロトコル伝送の一種を指すために使用し得る。換言すれば、ユニキャスト伝送は、２つのみのノード間の１対１ノード伝送である。ユニキャストでは、各出力パケットはユニキャスト宛先アドレスを有し、これは、パケットがそのアドレスを有する特定の宛先に向けられることを意味する。そのパケットをリッスンし得る全ての他の宛先は、パケットの宛先アドレスがその宛先のアドレスと同じではない場合、パケットを無視する。

【0024】

本明細書で使用される場合、「ブロードキャストメッセージング」又は「ブロードキャスト」は、情報が１つのみのコンピュータから送信されるが、ネットワークに接続された全てのコンピュータによって受信されるインターネットプロトコル伝送の一種を指す。これは、コンピュータ又はノードが「ブロードキャスト」パケットを送信する都度、その他の全てのコンピュータがその情報パケットを受信することを意味する。

【0025】

本明細書で使用される場合、「マルチキャストメッセージング」又は「マルチキャスト」は、２つ以上の送信者が存在し得、送信された情報が、マルチキャストグループとしてまとまった１組の受信者に向けられ、１組の受信者が全受信者のサブセットであり得るインターネットプロトコル伝送又は通信の一種を指す。マルチキャストでは、各マルチキャストパケットはマルチキャストアドレスにアドレス指定される。このアドレスはグループアドレスである。任意の宛先が、アドレスに加入することができ、したがって、加入しているマルチキャストアドレスに送信されたパケットをリッスンし受信することができる。マルチキャストの利点は、送信された単一のマルチキャストパケットを複数の宛先が受信可能なことである。これは、同じパケットを複数の宛先に送信する必要がある場合、ネットワークトラフィックを節減する。一般に、同じデータを複数のＩＰ宛先に送信する必要がある場合、ユニキャストではなくブロードキャスト又はマルチキャストが、ネットワークの最も効率的な使用を提供する。

【0026】

この説明では、ブロードキャスト及びマルチキャストという用語を使用し得る。ブロードキャスト及びマルチキャストの両方において、メッセージが送信される場合、メッセージは複数の宛先によって受信される。したがって、本明細書で使用される場合、ブロードキャスト及びマルチキャストという用語は同義で使用されて、１つのパケットが複数の宛先によって受信されることを指し得る。場合によっては、この説明では、ブロードキャストされるか、マルチキャストされるか、それともユニキャストされるかを指定せずに送信又は伝送されるメディアのみに言及する。そのような場合、これらの方法の任意の１つをメディアの送信又は伝送に使用し得ることが意味される。

【0027】

本明細書で使用される場合、「メッセージ」及び「パケット」という用語が使用されることが多く、これらは同義で使用し得る。パケットは、インターネットプロトコル（「ＩＰ」）ネットワーク上で送信又は受信されるように設定されるデータである。パケットは、「ＩＰパケット」と同じであってもよく、又は同じでなくてもよい。「メッセージ」という用語は、本明細書で使用される場合、そのようなパケットに含まれる論理情報を指す。

【0028】

本明細書で使用される場合、「セグメント」は、データセットを指すためにも使用し得る。データセットはデータバイトセットである。データは、メディアデータ、制御データ、又は情報データを含め、任意のタイプのデータであり得る。この説明では、データ及びパケットという用語は、文脈に応じて同義で使用することもできる。「パケット」はデータセットを指し得、データはデータ全般を指す。

【0029】

多くの代替の実施形態が本明細書に開示され、これらの実施形態が単なる例示として提示されることを理解されたい。記載される実施形態は、決して限定を意図しない。一般に、実施形態は、当業者が本発明のうちの１つ又は複数を実施できるようにするのに十分に詳細に説明され、他の実施形態も利用し得、開示される範囲から逸脱せずに、構造的、論理的、ソフトウェア、電気的、及び他の変更を行い得ることを理解されたい。

【0030】

本発明の一実施形態によれば、Ｗｉ−Ｆｉネットワークを介してメディアをブロードキャストするために、まず、ブロードキャスト又はマルチキャストメディアが全ての宛先で均一に受信されるわけではないことを認識する必要がある。宛先によっては、マルチキャスト「パケット」（インターネットプロトコル（「ＩＰ」）ネットワーク上で送信又は受信されるデータセットを指す。パケットは、「ＩＰパケット」と同じであっても又は同じでなくてもよい。「メッセージ」という用語は、本明細書で使用される場合、そのようなパケットに含まれる論理情報を指し、同義で「メッセージ」又は「セグメント」と呼ばれることもある）を受信するものもあれば、受信しないものもある。

【0031】

ＩＰネットワークは当初、有線ネットワークを介して動作するように設計されていた。設計により、これらのネットワーク上のパケット通信は「ベストエフォート型」であった。これは、ネットワークで送信される任意のパケットが、意図される宛先によって受信されないことがあることを意味する。これは最も多くの場合、衝突に起因し、別のデバイスが対象となるデバイスと同じ瞬間に通信を開始し、それにより、衝突が生じる。別の損失理由は、ルータとのネットワークパス中のデバイスが単に、例えばバッファ空間がないことに起因して、パケットを落とすことである。損失の他の理由は、単に有線回線にノイズが多く、パケット伝送が破損することであり得るが、これは、無線の場合と比較して有線の場合では希である。

【0032】

これらの全ての有線状況では、送信（例えば、マルチキャストメッセージ）がサブネット又はワイヤ上の１つのデバイスによって受信された場合、同じワイヤ又はサブセット上のその他の全てのデバイスも送信を正確に受信することが一般に事実である。これは、有線の場合、ワイヤの一部分上のデバイスのノイズ又は干渉状況が、ワイヤの別の部分でのノイズ状況とあまり変わらないためである。有線デバイスが、ハブではなくスイッチを介して接続される場合、同じ事柄が当てはまり、ノイズ又は干渉の量は最小である。

【0033】

Ｗｉ−Ｆｉでは、サブセット内の各Ｗｉ−ＦｉデバイスでのＷｉ−Ｆｉトラフィックの受信での差は大きい。したがって、これを説明する必要がある。
本発明の一実施形態によれば、全てのデバイス（すなわち、ソースデバイス１０４並びに様々な宛先デバイス１０６及び１０６’）（図１及び図３参照）は、ローカルネットワーク１２０上で一緒にネットワーク接続し得る。これは通常、ＩＰネットワークであり、有線又は無線（例えば、Ｗｉ−Ｆｉ）ネットワークであり得る。このローカルネットワークは、インターネットに更に接続し得る。

【0034】

多くのメディアシステムでは、メディアを複数の再生デバイスに送信し、各再生デバイスにメディアを同相でレンダリングさせることが望ましい。例えば、ステレオオーディオメディアの左チャネルを左オーディオ再生デバイスに送信し、ステレオメディアの右チャネルを右オーディオ再生デバイスに送信し、これらの両デバイスにメディアを同相で正確に再生させることが望ましい。

【0035】

図１は、２つのデジタルオーディオサブシステムである、第１のサブシステム１０６及び第２のサブシステム１０６’を有するそのようなシステムを示す。第１のサブシステム１０６及び第２のサブシステム１０６’は各々、同じ又は関連するオーディオデータをレンダリングする。例えば、各オーディオサブシステムは、ネットワーク上のメディアファイル２２２からメディアを受信中であり得る。各システム（すなわち、オーディオシステム１０６及び１０６’）は、中央演算処理装置（ＣＰＵ）及びデジタル／アナログ変換器を備える。各システム１０６、１０６’は、ＤＡＣを介してオーディオ出力１１２及び１１２’をレンダリングする。この場合、レンダリングされる出力波２２０及び２２０’は、図１に示されるように、オーディオ同相である必要がある。オーディオ同相であるために、レンダリング波２２０及び２２０’は、正確な時間に（位相オフセットで）再生される正確な音響（周波数スペクトル）を有する必要がある。例えば、メディアが、そのメディアでベルを１分鳴らす左チャネルを含み、右チャネルが同時にドラムビートを再生し、デバイス１０６が左チャネルを再生し、デバイス１０６’が右チャネルを再生する場合、そのメディア再生の１分で、デバイス１０６がベル音をレンダリングし、デバイス１０６’がドラムビートをレンダリングすれば、デバイスは同相である。

【0036】

レンダリング波２２０及び２２０’が同相ではない場合、ユーザは、２つの波２２０と２２０’との周波数差に関連するうなり周波数を聞くおそれがある。さらに、時間の経過に伴い、２つのオーディオ出力の差が増大し続け得る。例えば、前に用いた例では、第２のサブシステム１０６’が＋５０ｐｐｍだけずれ、３分の歌がドラムビートで終わる場合、第２のサブシステム１０６’は、最後のドラムビートを第１のサブシステム１０６よりも９ミリ秒後に再生することになる。そのような１０の歌の後、差は９０ミリ秒になり、これは非常に顕著である。

【0037】

したがって、複数のオーディオデバイス１０６及び１０６’が同じメディアを再生している場合、各システムのレンダリングクロックを調整し、同じ位相オフセット及び周波数を有することを保証する必要がある。

【0038】

図２は、オーディオを再生する典型的なデジタルシステム１０６をより詳細に示す。ＣＰＵ１１４はオーディオサンプルをＤＡＣ１０８に送信し、オーディオサンプルは、ＤＡＣ１０８がデジタルサンプルをアナログ信号１１２に変換することによってレンダリングされる。ＤＡＣがデジタルサンプルをアナログ信号レベルに変換するレートは、出力サンプルレートと呼ばれ、出力サンプルレートは通常、ＣＰＵ１１４から送信されているオーディオサンプルがサンプリングされたレートに一致する。厳密な出力サンプルレートは、ＤＡＣを駆動しているＤＡＣクロックサブシステムによって決まる。このクロックサブシステムの精度は、出力サンプルレートの精度、ひいてはこのシステムによるオーディオレンダリングの精度に影響を及ぼす。このクロックサブシステムは、ＣＰＵ１１４から、又は外部ソース１０５から発せられるクロックを使用し得る。

【0039】

典型的なＣＰＵ１１４のＣＰＵクロック結晶１０２は、ＣＰＵ１１４によって内部生成されるＣＰＵクロックのベースとなる。そして、このＣＰＵクロックは全てのＣＰＵタイミング活動に使用されることになる。ＣＰＵによっては、このＣＰＵクロックに基づいて、ＣＰＵ１１４内部で多くの異なるクロック信号を生成するものがある。ＣＰＵ１１４は、様々なタイミング関連活動に使用することができるＣＰＵクロックに基づいて、多くのクロック周辺機器及びクロックレジスタ１３６を有することもある。例えば、クロック周辺機器は、ＣＰＵに１００ミリ秒毎に定期的に割り込むように構成し得る。このクロックは元々、ＣＰＵ結晶１０２に基づくため、この周期の精度はＣＰＵ結晶１０２の精度に依存する。通常、ＣＰＵ１１４で実行されるプログラムは、ＣＰＵ１１４に電源投入され、リセットされてからＣＰＵ１１４がカウントしたクロックカウント数を示すクロックレジスタ１３６を読み取ることもできる。これらのクロックカウントは、ＣＰＵ結晶１０２に関連するレートで増分される。このクロックは、ＤＡＣ出力サンプルレート及びオーディオサンプルがＤＡＣに提供されるレートを駆動するのに使用し得る。

【0040】

幾つかの実施形態では、システム１０６は、オーディオクロック信号１１６をＣＰＵ１１４及びＤＡＣ１０８に送信して、ＣＰＵ１１４からＤＡＣ１０８に送信されるオーディオ信号の再生のタイミングを管理するとともに、ＤＡＣ１０８を介してそのようなオーディオ信号からオーディオ出力１１２を生成するために、各自の独立した結晶１０３を有する別個のオーディオクロック１０５を更に備え得る。

【0041】

代替の実施形態は、ＤＡＣサンプルレートの駆動に、外部クロックソース及び内部クロックソースの様々な組み合わせを使用し得る。
メディアを複数の再生デバイスに送信し、各再生デバイスに同相でメディアをレンダリングさせる必要がある、図１に示されるようなメディアシステムでは、メディアに何らかの時間参照情報をマークする必要があり、各デバイスは、この時間情報に従ってこのメディアを再生する必要がある。これは、レンダリング活動の時間を合わせているために、各デバイスが同じ時間参照を使用する必要があることを意味する。

【0042】

図３は、上述したように時間参照する共通クロックベースの手法を示す。図示されているように、ソースデバイス１０４及び１つ又は複数の宛先デバイス１０６、１０６’は、ネットワーク１２０によって接続し得る。ソースデバイス１０６は、「共通」ソースクロックでありローカルクロックＣ１３５を有し、各宛先デバイス１０６、１０６’も、第１のデバイス１０６についてはＤ１_１３６として示され、ｘ番目のデバイス１０６’についてはＤｘ１３６’として示されるローカルクロックを含む。ソースクロック１３５は、そのクロック値が全ての宛先に送信され、全てのデバイスで共通する標準クロックとして使用されるため、共通ソースクロックと呼ばれる。ソースデバイス１０４は周期的に、メッセージ送信前に読み取られた最新の共通ソースクロック値Ｃを含む「クロック」メッセージを各宛先デバイス１０６、１０６’に送信する。クロック値を有する周期ｎで第１のデバイスに送信されるクロックメッセージは、Ｃ１_ｎ２５０として記され、クロック値を有する周期ｎで第ｘのデバイスに送信されるクロックメッセージは、Ｃｘ_ｎ２５２として記される。各宛先デバイス１０６、１０６’は、クロックメッセージを受信すると、受信した最新のクロック値Ｃ１_ｎ又はＣｘ_ｎを２５４及び２５４’として記録する。各宛先１０６、１０６’は、クロックメッセージを受信すると、受信したＣ１_ｎ又はＣｘ_ｎ共通クロック値と共に、対応するローカルクロック値Ｄ１_ｎ又はＤｘ_ｎも記録する。クロックメッセージを受信する瞬間から、それに関連付けられたローカルクロックが記録される時間までには遅延がある。この「記録」遅延は、クロックメッセージ毎に異なり得、記録ジッタＲとして定義される。記録遅延のこの変化は、メッセージングに使用されるネットワークアダプタと、パケット受信までの宛先でのソフトウェアの応答時間の変化とに起因し得る。

【0043】

図４は、メッセージトランザクションの時系列を示す。ソースデバイス１０４は、第１のデバイス１０６にはクロック値Ｃ１_ｎ２５０を有し、ｘ番目のデバイス１０６’にはクロック値Ｃｘ_ｎ２５２を有するｎ番目のクロックメッセージを送信する。ｎ＋１番目以降のメッセージも同様である。各クロックメッセージは、ソース１０４から各宛先１０６〜１０６’に届くまでに特定量の時間（トランスポート時間）がかかる。

【0044】

ｎ番目のメッセージが第ｘのデバイスに届くまでの時間はＴｘ_ｎである。各宛先までのトランスポート時間は、ネットワークパケット伝送問題に起因して異なり得る。この差は、時間の経過に伴い、デバイス毎に変化する。Ｔｘのこれらの変化は、デバイスｘでのトランスポートジッタＪｘと呼ばれる。

【0045】

各メッセージＣｘ_ｎ内の情報と、記録された対応するローカルクロック値Ｄｘ_ｎとに基づいて、各宛先ｘ１０６、１０６’は、共通ソースクロックＣ１３５に一致するように、ローカルクロックＤｘ１３６、１３６’を調整するための情報を計算し得る。宛先１０６、１０６’は、ソースクロックＣ１３５の現在の位相（カウント）Ｐｃの最良推定値に一致するように、ローカルクロックＤ１_１３６、Ｄｘ１３６’位相（カウント）Ｐｘを調整し得る。同様に、宛先１０６、１０６’は、共通ソースクロックＣ１３５の現在の周波数Ｆｃの最良推定値に一致するように、ローカルクロックＤ１_１３６、Ｄｘ１３６’周波数Ｆｘを調整し得る。

【0046】

これらのステップを実行する例示的な計算は以下であり得る。
・Ｃｘ_ｎ：デバイスＸに送信されるｎ番目の共通ソースクロック値
・ＴＡ_ｘ：デバイスＸへの平均推定トランジット時間
・ＲＡ_ｘ：デバイスＸでの平均推定記録時間
・Ｊｘ：平均ＴＡ_ｘからの最大トランジット時間ずれ
・Ｒｘ：平均からの最大記録時間ずれ
・Ｔｘ_ｎ：デバイスＸに送信されるｎ番目のメッセージのトランスポート時間
・Ｄｘ_ｎ：ｎ番目のクロックメッセージでのデバイスｘのクロック値
・Ｆｘ_ｎ：デバイスｘの新しいローカルクロック周波数
・Ｐｘ_ｎ：デバイスｘの新しいローカルクロック位相／カウント
・Ｃｘ’_ｎ＝Ｃｘ_ｎ＋Ｔｘ_ｎ＋Ｒｘ_ｎ：推定共通クロックｎ
・Ｃｘ’_ｎ＋１＝Ｃｘ_ｎ＋１＋Ｔｘ_ｎ＋１＋Ｒｘ_ｎ＋１：推定共通クロックｎ＋１
・Ｔｘ_ｎ＝Ｔａ_ｘ＋／−Ｊｘ：トランスポート時間ｎ
・Ｔｘ_ｎ＋１＝Ｔａ_ｘ＋／−Ｊｘ：トランスポート時間ｎ＋１
・Ｒｘ_ｎ＝Ｒａ_ｘ＋／−Ｒｘ：記録時間ｎ
・Ｒｘ_ｎ＋１＝Ｒａ_ｘ＋／−Ｒｘ：記録時間ｎ＋１
・Ａｘ_ｎ＝（Ｄｘ_ｎ＋１−Ｄｘ_ｎ）−（Ｃｘ’_ｎ＋１−Ｃｘ’_ｎ）：周波数調整値
・Ａｘ_ｎ＝（Ｄｘ_ｎ＋１−Ｄｘ_ｎ）−（Ｃｘ_ｎ＋１−Ｃｘ_ｎ）＋／−２＊Ｊｘ＋／−２＊Ｒｘ
・Ｆｘ_ｎ＝Ｆｘ_ｎ−１−Ａｘ_ｎ：新しい周波数
・Ｆｘ_ｎ＝Ｆｘ_ｎ−１＋（Ｃｘ_ｎ＋１−Ｃｘ_ｎ）−（Ｄｘ_ｎ＋１−Ｄｘ_ｎ）＋／−２＊Ｊｘ＋／−２＊Ｒｘ
・Ｐｘ_ｎ＝Ｃｘ’_ｎ＝Ｃｘ_ｎ＋Ｔａ_ｘ＋／−Ｊｘ＋／−Ｒｘ：位相オフセット。

【0047】

トランスポート時間Ｔｘの推定は、このシステムにとって極めて重要である。これを行う一般的な一方法は、メッセージをソース１０４から宛先Ｄｘ１０６、１０６’にメッセージを送信し、宛先Ｄｘ１０６、１０６’にこのメッセージへの肯定応答を送信させることにより、ソースから宛先への往復時間を測定することである。出力メッセージを送信してから、入力肯定応答メッセージを受信するまでの合計時間が、往復時間である。この時間を半分にすることで、出力トランジット時間の推定値が提供される。これが多数回行われ、フィルタリングされる場合、フィルタリング結果Ｔａ_ｘを、ソースから宛先Ｄｘへの平均トランジット時間として使用することができる。ｎ番目のメッセージの実際のトランジット時間Ｔｘ_ｎは、＝Ｔａ_ｘ＋／−Ｊｘ_ｎであり、但し、Ｊｘ_ｎはジッタであり、このｎ番目のメッセージの平均からずれである。Ｊｘ_ｎは、測定されたＴｘ時間の標準偏差を使用して推定することができる。

【0048】

この方式では、各宛先デバイス１０６、１０６’は、共通ソースクロック１３５情報を使用して、共通ソースクロック１３５のクロック値及びクロックレートに一致するように、ローカルクロック１３６、１３６’値及びクロックレートを調整する。すなわち、共通ソースクロック１３５は、システムで使用される「グローバル」クロックであり、全ての宛先クロックはこれに合わせられる。次に、メディアは、ローカルクロック１３６、１３６’を使用して各デバイスでレンダリングされる。

【0049】

このシステムの精度は、トランスポートジッタが周波数及び位相両方の計算に影響し得るため、限られ得る。これは、上述したように、ある時間期間にわたり、計算に使用されるパラメータをフィルタリングすることによっていくらか軽減し得る。メディアのレンダリングは、宛先デバイス１０６、１０６’によって行われ、これらのデバイスに関連付けられたクロックは、メディアレンダリングのベースとして使用されるため、これは、メディアレンダリングの位相精度がトランスポート時間ジッタによって影響を受けることを意味する。トランスポート時間ジッタＪｘが、Ｗｉ−Ｆｉネットワークであり得るように、＋／−１〜２ミリ秒である場合、達成することができる最高位相精度はこの範囲に制限される。

【0050】

このシステムに伴う更なる問題は、仮想クロック時間が、受信メッセージの間隔でのみ増分することである。これは、ローカルクロックを使用して、これらのメッセージ間隔中の時間を補間することによって対処することができる。問題は、各デバイスのローカルクロックがその他のローカルクロックとわずかに異なり得、したがって、補間された仮想クロックが、受信メッセージの結果として行われる各調整で前方にジャンプするか、又は後方に動くことがあることである。これは、メディアレンダリングを時折、小量だけ前方又は後方にジャンプさせ得る。

【0051】

更なる問題は、多くのシステムで、共通グローバルクロックが利用可能ではないか、又は利用可能な場合であっても、同期目的では十分に正確ではないことである。例えば、ソースデバイスのローカルクロックには、プログラミングＡＰＩを通してアクセスし得るが、呼び出し側プログラムは通常、ＡＰＩ呼び出し中に遅延を有し得るか、タスクスワップを有し得るマルチタスクオペレーティングシステムで実行中であるため、ローカルクロック時間は、その時間だけ不正確になる。例えば、呼び出し側プログラムは、ローカルクロックＡＰＩを呼び出し得、ハードウェアクロック値を呼び出し得、次に、関数が返す前に、現在のプログラムスレッドがスワップを課され、次のプログラムスレッドでタイムスライスのみを返す。これは、返されるハードウェアクロック値がここで、タイムスライス期間だけ遅れていることを意味する。最も一般的なオペレーティングシステムは、最長で２５ミリ秒〜１００ミリ秒のタイムスライス期間を有することができ、したがって、ハードウェアクロック値は、ミリ秒単位で大きく遅れ得る。これは、スマートフォン又はノートブック等の多くの汎用ソースデバイスに当てはまる。逆に、本発明で使用される宛先デバイスは、専用デバイスであり、したがって、ソフトウェアは、はるかに良好なローカルクロック読み出し精度で、より下位レベルで動作する。

【0052】

したがって、本発明の様々な実施形態は、ソースデバイスのローカルクロックを正確に読み取る能力を使用しないか、又は必要としないという目標で設計し得る。
開示される構成は、各デバイスのローカルレンダリングクロックのみを使用してメディアをレンダリングする。ここで参照される宛先デバイスローカルクロックは、メディアサンプルがＤＡＣ（デジタル／アナログ変換器）に供給されて、デジタルメディアサンプルをオーディオ信号又はビデオ信号に変換（レンダリング）するレート（サンプルレート）のベースとして使用されるクロックである。このローカルクロックは、ハードウェアクロックであることもあれば、又はオーディオ信号若しくはビデオ信号への変換のためにサンプルをＤＡＣに供給する、ハードウェアクロックによって支援し得る仮想クロック、割り込みサービスルーチン等のソフトウェアオブジェクトであることもある。

【0053】

これらの宛先クロックは、増分の仕方が連続し平滑しており、したがって、メディアをレンダリングする仕方が平滑している。しかし、デバイスクロックでの潜在的な差について調整する必要があり得る。一実施形態は、２つの問題に分けることによってこの調整に対処する。第１の問題は、周波数差を検出することである。第２の問題は、差について調整することである。差を検出するために、一実施形態は、共通クロックではなく共通イベントベースの手法を使用する。

【0054】

図５は、共通イベントベースのシステムの一例の基本要素の図である。システムは、ネットワーク１２０によって接続されるソースデバイス１０４及び１つ又は複数の宛先デバイス１０６、１０６’からなる。ソースデバイスは、２つの要素：共通イベントソースＥ３５０及び同期計算マネージャ（同期マネージャ）Ｓ３５２を有する。共通イベントソースＥ３５０は、全ての宛先デバイスで同時に、共通時刻に受信されるイベントメッセージをネットワーク上で生成する。共通イベントメッセージＥ_ｎ３５８の一例は、全ての宛先デバイス１０６、１０６’によって同時に受信されるマルチキャスト又はブロードキャストメッセージである。なお、マルチキャスト又はブロードキャストメッセージは、１つのデバイスであるソースデバイスによって通信チャネルに出され、全ての宛先デバイスによって受信される。メッセージは実際に、通常、電気信号又はＲＦ信号が光速に近い速度で搬送される電気手段によって通信チャネル上で通信される。したがって、例えば、メッセージの最後のビットは、距離に光速を掛けたものだけの差である時刻で全ての宛先デバイスで受信され、これは略即時である。共通イベントメッセージの別の例は、例えば、８０２．１１（Ｗｉ−Ｆｉ）ネットワークプロトコルを使用するネットワークでのビーコンメッセージである。

【0055】

一実施形態では、全ての宛先デバイスによって受信され、それぞれが一意に識別可能であり、それぞれが全ての宛先デバイスで同時に受信される任意のイベントシーケンスを、本明細書に記載される共通イベントとして使用し得る。一実施形態では、同期マネージャＳ３５２は、そのような共通イベントのソースである。

【0056】

同期計算マネージャＳ３５２は、宛先デバイス１０６、１０６’を含め、ネットワーク１２０上の任意の計算デバイスに存在し得る。
各宛先デバイスｘ（１０６、１０６’）は、デバイスによるメディアレンダリングのベースとして使用されるローカルクロックＤｘ（１３６、１３６’）を有する。

【0057】

図６は、システムでの活動及びメッセージの時系列を示す。イベントソースＥ３５０はイベントメッセージを生成し、時間Ｔ_ｎにおいて生成されるｎ番目のイベントは、Ｅ_ｎ３５８として記される。イベントＥ_ｎ３５８は、イベント番号ｎによって識別され、これは各イベントに一意である。イベント番号ｎは、単に、システムがオンになったときから同期マネージャＳ３５２によって生成される順次増分される番号であってもよく、又はタイムスタンプ値であってもよい。後者の場合、これは一意の番号としてのみ使用され、時間値は時間のインジケータとして使用されない。一意のイベント番号を生成する任意の他の形態であってもよい。各イベントメッセージＥ_ｎを受信すると、各宛先ｘは、ローカルクロックＤｘ１３６の現在値をＤｘ_ｎとして記録する。共通クロックの場合と同様に、イベントメッセージの受信の瞬間から、それに関連付けられたローカルクロックが記録されるまでに遅延がある。この「記録」遅延は、イベントメッセージ毎に異なり得、記録ジッタＲとして定義される。

【0058】

各宛先デバイスｘは、イベントメッセージｎを受信すると、ｎ番目のイベントに対して、イベントｎの受信時に記憶された値Ｄｘ_ｎを有するイベント肯定応答メッセージＡＫ（Ｄｘ_ｎ）３５４、３５４’と、一意のイベント番号ｎを同期計算マネージャＳ３５２に送信する。同期計算マネージャは、Ｄｘ_ｎ値を有する全てのイベント肯定応答メッセージＡＫ（Ｄｘ_ｎ）３５４、３５４’を受信し、計算を実行し、次に、調整情報Ａｘ_ｎを有するクロック調整メッセージＡＪ（Ａｘ_ｎ）３５６、３５６’を各デバイスｘに返信する。

【0059】

実行される計算を以下に示す。
・Ｅｘ_ｎ：デバイスＸに送信されるｎ番目の共通イベントメッセージ
・Ｔｘ_ｎ：デバイスＸに送信されるｎ番目のイベントのトランスポート時間
・Ｄｘ_ｎ：ｎ番目のイベントメッセージでのデバイスｘのクロック値
・Ｆｘ_ｎ：デバイスｘの新しいローカルクロック周波数
・Ｐｘ_ｎ：デバイスｘの新しいローカルクロック位相／カウント
・Ｑｘ０＝Ｄｘ_０−Ｄ１_０＋／−２＊Ｒｘ：デバイス１に対する参照（初期）クロック位相
・Ｑｘ_ｎ＝Ｄｘ_ｎ−Ｄ１_ｎ＋／−２＊Ｒｘ：ｎ番目のクロック位相
・Ｑｆ_ｎ＝Ｆ（Ｑｘ_ｎ）：ｎ番目のクロック位相のフィルタリング関数
・ｅｘ_ｎ＝（Ｑｆ_ｎ−Ｑｆ_０）＋／−４＊Ｒｘ：位相エラー（変化）
・ｋｘ_ｎ＝Ｔ＊ｅｘ_ｎ：エラー＊伝達関数
・Ｆｘ_ｎ＝Ｆｘ_０＋ｋｘ_ｎ＋／−Ｔ＊４＊Ｒｘ：新しい周波数
・ＰＦｘ_ｎ＝（（Ｆｘ_ｎ／Ｆｘ_ｎ−１）−１）＊１００：新しい周波数パーセント
・Ｐｘ_ｎ＝Ｄｘ_ｎ−Ｄ１_ｎ＋／−２＊Ｒｘ：位相オフセット
・Ａｘ_ｎ＝（ＰＦｘ_ｎ，Ｐｘ_ｎ）：調整情報。

【0060】

この共通イベントシステムでは、１つのデバイス、つまり、第１の宛先デバイスであるデバイス１のクロックが、位相参照クロックとして使用される。これらの計算を用いて、同期モジュールは、各宛先デバイスｘの位相オフセット（ローカルクロック値）及び周波数割合（ローカルクロックレート）調整を計算し、この調整情報を宛先ｘに送信し、各宛先デバイスｘでのローカルクロックが宛先デバイス１のローカルクロックに一致するように調整を行うように求める。

【0061】

例えば、ジッタを無視して、共通イベント１であるＥ１とイベント２であるＥ２との間で、第１の宛先デバイスのローカルクロックが１００カウント増分し、宛先デバイスｘが１０１カウント増分する場合、デバイスｘは、宛先デバイス１よりも高速で実行されており、そのクロックレートを１０１から１カウントだけ減分する必要がある。さらに、第１の宛先デバイスのローカルクロックが、イベント１であるＥ１で２５００であり、宛先ｘのローカルクロックが、イベント１であるＥ１で３０００であった場合、宛先ｘのローカルクロックを２５００に調整して、第１の宛先デバイスの位相に合わせる必要がある。

【0062】

この実施形態は、周波数の割合として周波数調整を定義するが、他の実施形態は、絶対的な新しい周波数又は追加若しくは低減すべきサンプル数を含む他の形態で周波数調整を定義し得る。これらの全ての形態は、本明細書の目的のために周波数調整と呼ばれる。また、周波数という言葉の使用は、クロックレートを指し、オーディオサンプル結晶レート及びサンプル出力レートの両方に関連し、これら両方を指し得る。一般に、サンプル出力レートは、オーディオサンプル結晶レートの倍数である。

【0063】

位相調整はクロック値の調整を指し、クロック値は、オーディオ結晶レート、サンプル出力クロック出力レート、又はサンプル出力クロックに関連する何らかの他のカウンタ値で増分するクロックについてのクロック値であり得る。

【0064】

この共通イベントシステムでの主要な事柄は、肯定応答メッセージ３５４、３５４’及び調整メッセージ３５６、３５６’が、ＩＰネットワークを介して送信されるため、受信側に予測可能な時刻に到着しないことがあることである。各肯定応答メッセージは、宛先デバイス番号を含む。

【0065】

したがって、同期モジュール３５２は、到着時までに、同じイベントへの肯定応答メッセージ３５４、３５４’をグループ化することができない。例えば、イベント１への幾つかの肯定応答メッセージは、イベント２の肯定応答メッセージが到着した後、同期モジュール３５２に到着し得る。したがって、肯定応答メッセージは、一意のイベント番号に基づいてイベント肯定応答メッセージセットにグループ化される。

【0066】

このために、同期モジュール３５２は、一意の各イベントについて１組の宛先デバイスから送信された全ての肯定応答メッセージを関連付けることができる。したがって、同期モジュールは、システムの寿命にわたり一意である番号ｎで各イベントメッセージをマークする。これは単に、各イベントに伴って増分するイベント番号であり得る。全ての宛先デバイスは、この一意のイベント番号を肯定応答メッセージＡＫ３５４、３５４’に含める。肯定応答メッセージＡＫ３５４、３５４’が同期モジュール３５２で受信されると常に、肯定応答メッセージは、肯定応答メッセージの集合｛ＡＫ（Ｄａｂ），・・・，ＡＫ（Ｄ１ｎ），・・・，ＡＫ（Ｄｘｎ），ＡＫ（Ｄ１ｎ＋１），・・・等｝に配置される。次に、この集合が探索されて、特定のイベント番号ｎに対する全ての肯定応答メッセージの部分集合｛ＡＫ（Ｄ１ｎ），・・・，ＡＫ（Ｄｘｎ）｝を見つける。次に、デバイス１に関する位相変化Ｑｘｎが、上記計算に示されるように、この部分集合からの値を使用して計算される。この部分集合内の値は、使用前に更にフィルタリングし得る。

【0067】

代替の実施形態では、イベントメッセージは、Ｗｉ−Ｆｉシステムのビーコンメッセージを使用するなど、外部ソースから提供し得る。この場合、ビーコンメッセージ内の時刻値は、一意のイベント番号として使用し得る。なお、時刻値は時刻値として使用されず、一意のイベント番号としてのみ使用される。

【0068】

図７は、共通クロック方法と、本明細書に記載される共通イベント方法との幾つかの重要で重大な違いを識別する。上部プロット４５０は、共通クロック方法の正味の影響を示す。この方法では、ソース１０４のクロックである共通クロックは、システムによって使用される「グローバル」クロック４５４である。このクロックは、ローカルクロックを調整するために共通ソースクロック時間を推定する各宛先Ｄ１_１０６〜Ｄｘ１０６’によって使用される。上述したように、この設定の精度はトランスポート待ち時間Ｌ１_４５８及びＬｘ４６０による影響を受ける。各宛先デバイスＤ１_１０６及びＤｘ１０６’は独立して、共通クロック時間を推定するため、これらのクロックの位相差Ｐ４６２はこれらの待ち時間にかなり依存することになる。トランスポート待ち時間は、トランスポートジッタと呼ばれるメッセージ毎の差を有するため、これは、宛先デバイスクロック（Ｄ１_１３６及びＤｘ１３６’）のクロック設定が、トランスポートジッタを受ける精度を有することを意味する。特に、これは、クロックの差である位相差が最大メッセージトランスポートジッタＪｘを受けることを意味する。デバイスＤ１_１０６及びＤｘ１０６’の両方でのメディアレンダリングの位相精度を維持することが望ましい。最良の提案は、トランスポートジッタが位相精度に影響しないようにすることである。

【0069】

全体的に、共通クロック方法は、全てのクロックをソースの共通クロックに合わせ、調整の計算は各宛先で独立して行われ、精度は、記録精度Ｒｘ及びトランスポートジッタＪｘに依存する。

【0070】

下部プロット４５２は、本発明の様々な実施形態で使用される共通イベント手法を示す。この手法では、第１の宛先デバイス１０６のクロックＤ１は、システムで使用される参照「グローバル」クロック４５６になる。追加の宛先デバイス１０６’は、それ自体のクロックＤｘをＤ１_１０６のグローバルクロックに調整する。これらのクロックの位相差Ｐ４６６は、トランスポート待ち時間による影響を受けず、共通イベントを受信時にいかに正確に記録するかによってのみ関連する。トランスポート待ち時間Ｌ１_４６４は、グローバルクロック４５６を元のソース１０４に射影する際のファクタにすぎない。本発明の一実施形態では、ソース１０４は、必要であれば、宛先クロックＤ１_１０６に一致するようにクロックを調整する。この実施形態では、ソースクロック又はそのような調整は必要ない。

【0071】

全体的に、共通イベント手法は、全てのクロックを宛先クロックの１つに合わせ、精度は記録精度Ｒｘのみに既存する。トランスポートジッタＪｘは、メッセージのトランスポートに関わる全てのデバイス及びプロセスによる影響を受けるため、記録精度Ｒｘの何倍も大きい傾向を有する（一方、記録精度は宛先ハードウェア及びソフトウェアのみに依存し、宛先ハードウェア及びソフトウェアにローカルである）。トランスポートジッタは数ミリ秒にもなり得るが、一方、記録ジッタは通常、数百マイクロ秒未満である。したがって、共通イベント手法は、記録精度のみに依存し、より少ない労力で複雑なかつ高レベルの位相同期精度を提供するよりよい手法である。

【0072】

図８は、共通イベント手法の全体的な効果を誇張した図を示す。上部波形２２０はデバイスＤ１_１０６からのＤＡＣの出力であり、下部波形２２０’はデバイスＤｘ１０６’からのＤＡＣの出力である。両プロットの垂直線は、各レンダリングクロックのクロックの刻み（ＤＡＣサンプルレート出力クロック）を示す。垂直線には、各クロックの刻みでレンダリングされるサンプルデータもプロットされる。図８中、下部波形Ｄｘは上部波形よりもはるかに遅いクロックの刻みを有し、したがって、オーディオサンプルは、デバイスＤ１においてより長い時間期間にわたってレンダリングされる。この図は２つの共通イベントＥ_ｎ及びＥ_ｎ＋１も示す。見て分かるように、Ｄ１からの下部波形が増分されたクロックの刻み量が、上部波形２２０で増分されたクロックの刻みの量未満である。時間Ｅ_ｎでの位相は、時間Ｅ_ｎでの２つのデバイス間のクロックカウント差である。時間Ｅ_ｎ＋１での位相もこの差である。クロックレートは異なるため、イベントＥ_ｎでの位相がイベントＥ_ｎ＋１での位相とは異なることになることが分かる。上述した共通イベント計算及び調整は、これを補正しクロックレートが上部波形２２０のクロックレートに一致するまで、下部波形２２０’のクロックレートを増大させる。クロックレートが一致する時点で、２つの波形は同様にレンダリングされ、同相でレンダリングされる。

【0073】

ローカルクロックレートの調整は、幾つかの方法で行うことができる。共通手法は文字通り、レンダリングクロックのクロックレートを調整することである。通常、これは、調整可能なクロックを生成することができる何らかの種類のハードウェアサブシステムを必要とする。代替の手法は、レンダリングクロックをそのままにし、メディアデータを代わりに調整するというものである。この手法は、サンプルレートを変換し、サンプルレート変換を行い、クロックレート差を補償するというものである。１ｋＨｚオーディオ信号が４４．１ｋＨｚでサンプリングされ、次に、４４．１ｋＨｚクロックでレンダリングされる場合、レンダリングされるオーディオ信号は、元のオーディオ信号の正確な表現になる。代わりに、レンダリングクロックが４４ｋＨｚである場合、１ｋＨｚオーディオ信号は、わずかに低いトーンでレンダリングされ、元のオーディオ信号の正確な表現にはならない。オーディオデータがここで、４４．１ｋＨｚから４４ｋＨｚにサンプリングレート変換され、４４ｋＨｚレンダリングクロックを使用してレンダリングされる場合、ここでレンダリングされる１ｋＨｚオーディオ信号は再び、元のオーディオ信号の正確な表現になる。

【0074】

本発明の好ましい実施形態は、後者のサンプルレート変換手法を使用する。周波数調整メッセージが各宛先で受信されると、レンダリングクロックを調整する代わりに、各宛先はサンプルレート変換をデータストリームに対して実行し、データのサンプルレートを増減する。これは、レンダリングクロックの調整と同じ正味効果を有する。

【0075】

通常、周波数差は、ＰＰＭパーツパーミリオン単位で指定されるクロック結晶の精度に関連する。１００ＰＰＭ結晶は、＜０．０１％、すなわち１０，０００個のうち１個の精度である。したがって、ここで必要とされるサンプルレート変換は通常、１０，０００個のサンプルのうち１個のサンプルという小さな調整である。したがって、調整は、時折１個のサンプルを追加又は落とすことによって達成することができる。

【0076】

図９は、制御システムの形態の上述したアルゴリズムを示す。これは、Ｄ１_１０６〜Ｄｘ１０６’として記される幾つかのデバイスを示す。各宛先デバイスは、第１のデバイスＤ１_１０６を除き、ソフトウェア位相ロックループアルゴリズムを実施して、位相をデバイスＤ１_１０６のクロック位相にロックする。各宛先デバイスＤｘ１０６’には、出力クロックＤｘ_ｎ６５４’の位相を参照クロックＤ１_６５２と比較する位相補償器６５０’が関連付けられる。次に、参照クロックｅ_ｘ−１６５６からの位相差は、クロック周波数調整Ａｘ７００’を生成するようにスケーリングされる。次に、この調整は、宛先１０６’でのクロック生成器７０２’にクロック周波数を調整させる。システムのこの実施形態では、位相検出器６５０’及び利得／スケーリング６５８’は、同期計算マネージャ３５２に存在する。クロック生成器７０２’は宛先デバイス１０６’に存在する。

【0077】

［追加の考慮事項］
本特許出願で提供されるセクションの見出し及び本特許出願の名称は、単なる便宜上のものであり、本開示を限定するものとして決して解釈されるべきではない。

【0078】

互いに通信するデバイスは、その他のことが明示される場合を除き、互いに連続して通信する必要はない。さらに、互いに通信するデバイスは、直接、又は１つ若しくは複数の論理的若しくは物理的な中間物を通して間接的に通信し得る。

【0079】

互いに通信する幾つかの構成要素を有する一実施形態の説明は、全てのそのような構成要素が必要とされることを暗に示すものではない。逆に、本発明の１つ又は複数の多種多様な可能な実施形態を説明するため、且つ本発明の１つ又は複数の態様をより十分に説明するために、様々な任意選択的構成要素を記載し得る。同様に、プロセスステップ、方法ステップ、アルゴリズム等は逐次順で説明されることがあるが、そのようなプロセス、方法、及びアルゴリズムは一般に、逆のことが特記される場合を除き、代替の順序で機能するように構成することもできる。換言すれば、本特許出願に記載され得る任意の順序又は順番のステップはそれ自体として、ステップがその順序で実行されるという要件を示さない。記載されるプロセスのステップは実際に任意の順序で実行し得る。さらに、ステップによっては、同時に発生するものとして説明又は暗示されていない（例えば、一方のステップが別のステップの後に説明されているため）にもかかわらず、同時に実行してもよいものがある。さらに、図面での図示によるプロセスの説明は、示されるプロセスが他の変形及び変更を除外することを暗示するものではなく、示されるプロセス又はその任意のステップが本発明の１つ又は複数に必要であることを暗示するものではなく、示されるプロセスが好ましいことを暗示するものでもない。また、ステップは一般に、実施形態毎に１回説明されるが、これは、１回のみ行われなければならないこと、又はプロセス、方法、若しくはアルゴリズムが実施又は実行される都度、１回のみ行い得ることを意味するものではない。ステップによっては、幾つかの実施形態若しくは幾つかの場合で省いてもよいものもあり、又はステップによっては、所与の実施形態若しくは場合で２回以上実行し得るものもある。

【0080】

単一のデバイス又は物品が記載される場合、２つ以上のデバイス又は物品を単一のデバイス又は物品の代わりに使用し得ることが容易に理解し得る。同様に、２つ以上のデバイス又は物品が記載される場合、単一のデバイス又は物品を２つ以上のデバイス又は物品の代わりに使用し得ることが容易に理解し得る。

【0081】

デバイスの機能又は特徴は代替として、そのような機能又は特徴を有するものとして明示的に説明されていない１つ又は複数の他のデバイスによって実施してもよい。したがって、本発明の１つ又は複数の他の実施形態はデバイス自体を含む必要がない。

【0082】

本明細書で記載又は参照される技法及びメカニズムは、明確にするために、単数形で説明されることがある。しかし、特定の実施形態が、特に断りのない限り、技法の複数の反復又はメカニズムの複数の反復を含むことに留意されたい。図中のプロセスの説明又はブロックは、プロセスでの特定の論理機能又はステップを実施する１つ又は複数の実行可能命令を含むモジュール、セグメント、又はコードの部分を表すものとして理解されたい。当業者には理解されるように、関わる機能に応じて、略同時又は逆順を含め、例えば、示される順又は考察される順以外で機能を実行し得る代替の実施態様は、本発明の実施形態の範囲内に含まれる。

【0083】

一般に、本明細書に開示される技法は、ハードウェア又はソフトウェアとハードウェアとの組み合わせで実施し得る。例えば、オペレーティングシステムカーネル、別個のユーザプロセス、ネットワークアプリケーションにバインドされたライブラリパッケージ、特に構築されたマシン、特定用途向け集積回路（ＡＳＩＣ）、又はネットワークインタフェースカードで実施し得る。

【0084】

本明細書に開示される実施形態のうちの少なくとも幾つかのソフトウェア／ハードウェアハイブリッド実施態様は、メモリに記憶されたコンピュータプログラムによって選択的にアクティブ化又は再構成されるプログラマブルネットワーク常駐マシン（断続的に接続されるネットワークアウェアマシンを含むものとして理解され得る）で実施し得る。そのようなネットワークデバイスは、異なるタイプのネットワーク通信プロトコルを利用するように構成又は設計し得る複数のネットワークインタフェースを有し得る。これらのマシンの幾つかの一般構造は、所与の機能ユニットを実施し得る１つ又は複数の例示的な手段を示すために、本明細書において開示し得る。特定の実施形態によれば、本明細書に開示される様々な実施形態の特徴又は機能の少なくとも幾つかは、例えば、エンドユーザコンピュータシステム、クライアントコンピュータ、ネットワークサーバ又は他のサーバシステム、モバイル計算デバイス（例えば、タブレット計算デバイス、携帯電話、スマートフォン、ラップトップ等）、消費者電子デバイス、音楽プレーヤ、任意の他の適する電子デバイス、ルータ、スイッチ等、又はそれらの任意の組み合わせ等の１つ又は複数のネットワークに関連付けられた１つ又は複数の汎用コンピュータで実施し得る。少なくとも幾つかの実施形態では、本明細書に開示される様々な実施形態の特徴又は機能の少なくとも幾つかは、１つ又は複数の仮想化計算環境（例えば、ネットワーク計算クラウド、１つ又は複数の物理的計算マシンでホストされる仮想マシン等）で実施し得る。さらに、幾つかの実施形態では、本発明の１つ若しくは複数の態様又は全ての態様は、任意選択的に、特にプログラムされたチップ（例えば、特定用途向け集積回路、すなわちＡＳＩＣ、又は消去可能プログラマブル読み取り専用メモリ、すなわちＥＰＲＯＭ）又は当技術分野で既知の何らかの他のハードウェアのみの手法を介して実施し得る。

【0085】

［例示的なハードウェア実施形態の説明］
これより図１０を参照して、本明細書に開示される特徴又は機能の少なくとも一部の実施に適する例示的な計算デバイス１２００を示すブロック図を示す。計算デバイス１２００は、例えば、前段落で列挙した計算マシンのうちの任意の１つであり得るか、又は実際に、メモリに記憶された１つ又は複数のプログラムに従ってソフトウェア又はハードウェアベースの命令を実行可能な任意の他の電子デバイスであり得る。計算デバイス１２００は、広域ネットワーク、大都市圏ネットワーク、ローカルエリアネットワーク、無線ネットワーク、インターネット、又は任意の他のネットワーク等の通信ネットワークを介して、有線であれ無線であれ関係なく、そのような通信に既知のプロトコルを使用して、クライアント又はサーバ等の複数の他の計算デバイスと通信するように構成し得る。

【0086】

一実施形態では、計算デバイス１２００は、１つ又は複数の中央演算処理装置（ＣＰＵ）１２０２、１つ又は複数のインタフェース１２１０、及び１つ又は複数のバス１２０６（周辺機器相互接続（ＰＣＩ）バス等）を含む。適切なソフトウェア又はファームウェアの制御下で動作する場合、ＣＰＵ１２０２は、特に構成された計算デバイス又はマシンの機能に関連付けられた特定の機能の実施を担当し得る。例えば、少なくとも１つの実施形態では、計算デバイス１２００は、ＣＰＵ１２０２と、ローカルメモリ１２０１及び／又はリモートメモリ１２２０と、インタフェース１２１０とを利用するサーバシステムとして機能するように構成又は設計し得る。少なくとも１つの実施形態では、ＣＰＵ１２０２は、例えば、オペレーティングシステム及び任意の適切なアプリケーションソフトウェア、ドライバ等を含み得るソフトウェアモジュール又は構成要素の制御下で、異なるタイプの機能及び／又は動作のうちの１つ又は複数を実行させ得る。

【0087】

ＣＰＵ１２０２は、例えば、インテル（Intel）、ＡＲＭ、クゥアルコム（Qualcomm）、及びＡＭＤファミリのマイクロプロセッサのうちの１つからのプロセッサ等の１つ又は複数のプロセッサ１２０３を含み得る。幾つかの実施形態では、プロセッサ１２０３は、計算デバイス１２００の動作を制御する、特定用途向け集積回路（ＡＳＩＣ）、電気的に消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等の特に設計されたハードウェアを含み得る。特定の実施形態では、ローカルメモリ１２０１（例えば、１つ又は複数のレベルのキャッシュメモリを含む不揮発性ランダムアクセスメモリ（ＲＡＭ）及び／又は読み取り専用メモリ（ＲＯＭ）等）は、ＣＰＵ１２０２の一部をなしてもよい。しかし、メモリをシステム１２００に結合し得る多くの異なる方法がある。メモリ１２０１は、例えば、データ、プログラミング命令等のキャッシュ及び／又は記憶等の様々な目的で使用し得る。

【0088】

本明細書で使用される場合、「プロセッサ」という用語は、単に当技術分野でプロセッサ、モバイルプロセッサ、又はマイクロプロセッサと呼ばれる集積回路に限定されず、マイクロコントローラ、マイクロコンピュータ、プログラマブル論理コントローラ、特定用途向け集積回路、及び任意の他のプログラマブル回路を広く指す。

【0089】

一実施形態では、インタフェース１２１０はネットワークインタフェースカード（ＮＩＣ）として提供される。一般に、ＮＩＣは、コンピュータネットワークを介するデータパケットの送受信を制御し、他のタイプのインタフェース１２１０は、例えば、計算デバイス１２００と併用される他の周辺機器をサポートし得る。提供し得るインタフェースの中でも、イーサネットインタフェース、フレーム中継インタフェース、ケーブルインタフェース、ＤＳＬインタフェース、トークンリングインタフェース、グラフィックスインタフェース等である。さらに、例えば、ユニバーサルシリアルバス（ＵＳＢ）、シリアル、イーサネット、ファイアワイヤ（Fire wire）（登録商標）、ＰＣＩ、パラレル、無線周波（ＲＦ），ブルートゥース（Bluetooth）（登録商標）、近距離通信（例えば、近距離磁場を使用する）、８０２．１１（ＷｉＦｉ）、フレーム中継、ＴＣＰ／ＩＰ、ＩＳＤＮ、高速イーサネットインタフェース、ギガビットイーサネットインタフェース、非同期転送モード（ＡＴＭ）インタフェース、高速シリアルインタフェース（ＨＳＳＩ）インタフェース、ＰＯＳインタフェース、ファイバデータ分散インタフェース（ＦＤＤＩ）等の様々なタイプのインタフェースを提供し得る。一般に、そのようなインタフェース１２１０は、適切なメディアと通信するのに適切なポートを含み得る。場合によっては、独立したプロセッサと、幾つかの場合では、揮発性メモリ及び／又は不揮発性メモリ（例えば、ＲＡＭ）とを含むこともできる。

【0090】

図１０に示されるシステムは、本明細書に記載される本発明の１つ又は複数を実施する計算デバイス１２００の特定の１つのアーキテクチャを示すが、決して、本明細書で記載される特徴及び技法の少なくとも一部を実施し得る唯一のデバイスアーキテクチャではない。例えば、１つ又は任意の数のプロセッサ１２０３を有するアーキテクチャを使用し得、そのようなプロセッサ１２０３は、単一のデバイスに存在してもよく、又は任意の数のデバイスに分散してもよい。一実施形態では、単一のプロセッサ１２０３が、通信及び計算ルーティングを処理するが、他の実施形態では、別個の専用通信プロセッサを提供し得る。様々な実施形態では、クライアントデバイス（クライアントソフトウェアを実行するタブレットデバイス又はスマートフォン等）と、サーバシステム（より詳細に後述するサーバシステム等）とを含む本発明によるシステムで異なるタイプの特徴又は機能を実施し得る。

【0091】

ネットワークデバイスの構成に関係なく、本発明のシステムは、汎用ネットワーク動作用のデータ、プログラム命令、又は本明細書で記載される実施形態の機能に関連する他の情報（又は上記の任意の組み合わせ）を記憶するように構成される１つ若しくは複数のメモリ又はメモリモジュール（例えば、リモートメモリブロック１２２０及びローカルメモリ１２０１等）を利用し得る。プログラム命令は、例えば、オペレーティングシステム及び／又は１つ又は複数のアプリケーションの実行を制御し得るか、又はそれ（ら）を含み得る。メモリ１２２０又はメモリ１２０１、１２２０は、データ構造、構成データ、暗号化データ、過去のシステム動作情報、又は本明細書に記載される任意の他の特定若しくは汎用非プログラム情報を記憶するように構成することもできる。

【0092】

そのような情報及びプログラム命令を利用して、本明細書に記載される１つ又は複数のシステム又は方法を実施し得るため、少なくとも幾つかのネットワークデバイス実施形態は、例えば、本明細書に記載される様々な動作を実行するためのプログラム命令、状態情報を記憶する構成又は設計し得る非一時的機械可読記憶媒体を含み得る。そのような非一時的機械可読記憶媒体の例としては、ハードディスク、フロッピーディスク（登録商標）、及び磁気テープ等の磁気媒体、ＣＤ−ＲＯＭディスク等の光学媒体、光ディスク等の磁気光学媒体、及び読み取り専用メモリデバイス（ＲＯＭ）、フラッシュメモリ、固体状態ドライブ、メモリスタメモリ、ランダムアクセスメモリ（ＲＡＭ）等のプログラム命令を記憶し実行するように特に構成されるハードウェアデバイスが挙げられるが、これらに限定されない。プログラム命令の例としては、コンパイラによって生成し得るようなオブジェクトコード、アセンブラ若しくはリンカによって生成し得るような機械コード、例えば、Ｊａｖａ（登録商標）コンパイラによって生成し、Ｊａｖａ仮想マシン等を使用して実行し得るようなバイトコード、又はインタプリタ（例えば、パイソン（Python）、パール（Perl）、ルビー（Ruby）、グルービィ（Groovy）、又は任意の他のスクリプト言語で書かれたスクリプト）を使用してコンピュータによって実行し得るより高水準のコードを含むファイルが挙げられる。

【0093】

幾つかの実施形態では、本発明によるシステムは、スタンドアロン計算システムで実施し得る。これより図１１を参照して、スタンドアロン計算システムでの１つ若しくは複数の実施形態又はその構成要素の典型的で例示的なアーキテクチャを示すブロック図を示す。計算デバイス１３００はプロセッサ１３１０を含み、プロセッサ１３１０は、例えば、クライアントアプリケーション１３３０等の本発明の実施形態の１つ又は複数の機能又はアプリケーションを実施するソフトウェアを実行し得る。プロセッサ１３１０は、例えば、あるバージョンのマイクロソフトウィンドウズ（Windows）（登録商標）オペレーティングシステム、アップル（Apple）のＭａｃＯＳ（登録商標）／Ｘ又はｉＯＳオペレーティングシステム、リナックス（Linux）（登録商標）オペレーティングシステムの幾つかのバラエティ、グーグル（Google）のアンドロイド（Android）（商標）オペレーティングシステム等のオペレーティングシステム１３２０の制御下で計算命令を実行し得る。多くの場合、１つ又は複数の共有サービス１３２５がシステム１３００で動作可能であり得、クライアントアプリケーション１３３０に共通サービスを提供するのに有用であり得る。サービス１３２５は、例えば、ウィンドウズ（Windows）（登録商標）サービス、リナックス（Linux）環境でのユーザ空間共通サービス、又はオペレーティングシステム１３１０と併用される任意の他のタイプの共通サービスアーキテクチャであり得る。入力デバイス１３７０は、例えば、キーボード、タッチスクリーン、マイクロホン（例えば、音声入力用）、マウス、タッチパッド、トラックボール、又はそれらの任意の組み合わせを含め、ユーザ入力の受信に適する任意のタイプのものであり得る。出力デバイス１３６０は、システム１３００からリモートであるか、それともローカルであるかに関係なく、出力を１人又は複数のユーザに提供するのに適する任意のタイプのものであり得、例えば、視覚的出力用の１つ又は複数の画面、スピーカ、プリンタ、又はそれらの任意の組み合わせを含み得る。メモリ１３４０は、プロセッサ１３１０によって使用されて、例えば、ソフトウェアを実行する当技術分野で既知の任意の構造及びアーキテクチャを有するランダムアクセスメモリであり得る。記憶デバイス１３５０は、デジタル形態でデータを記憶する任意の磁気、光学、機械的、メモリスタ、又は電気的記憶デバイスであり得る。記憶デバイス１３５０の例としては、フラッシュメモリ、磁気ハードディスク、ＣＤ−ＲＯＭ等を含む。

【0094】

幾つかの実施形態では、本発明のシステムは、任意の数のクライアント及び／又はサーバを有するような分散計算ネットワークで実施し得る。これより図１２を参照し分散計算ネットワークで本発明の一実施形態によるシステムの少なくとも一部を実施する例示的なアーキテクチャを示すブロック図を示す。本実施形態によれば、任意の数のクライアント１４３０を提供し得る。各クライアント１４３０は、本発明のクライアント側部分を実施するソフトウェアを実行し得、クライアントは、図１１に示されるようなシステム１３００を備え得る。加えて、任意の数のサーバ１４２０を提供して、１つ又は複数のクライアント１４３０から受信される要求を処理し得る。クライアント１４３０及びサーバ１４２０は、１つ又は複数の電子ネットワーク１４１０を介して互いに通信し得、電子ネットワーク１４１０は、様々な実施形態では、インターネット、広域ネットワーク、モバイル電話回線網、無線ネットワーク（ＷｉＦｉ（登録商標）、ＷｉＭａｘ（登録商標）等）、又はローカルエリアネットワーク（又は実際には、当技術分野で既知の任意のネットワークトポロジー、本発明は、いかなるネットワークトポロジーも任意の他のネットワークトポロジーよりも好むということがない）のうちの任意であり得る。ネットワーク１４１０は、例えば、有線プロトコル及び／又は無線プロトコルを含む任意の既知のネットワークプロトコルを使用して実施し得る。

【0095】

加えて、幾つかの実施形態では、サーバ１４２０は、必要な場合に外部サービス１４７０を呼び出して、追加情報を得るか、又は特定の呼び出しに関する追加データを参照し得る。外部サービス１４７０との通信は、例えば、１つ又は複数のネットワーク１４１０を介して行い得る。様々な実施形態では、外部サービス１４７０は、ハードウェアデバイス自体に関連するか、又はインストールされたウェブ対応サービス又は機能を含み得る。例えば、クライアントアプリケーション１３３０がスマートフォン又は他の電子デバイスで実施される実施形態では、クライアントアプリケーション１３３０は、クラウド内のサーバシステム１４２０又は特定の企業若しくはユーザの構内のうちの１つ若しくは複数に展開される外部サービス１４７０に記憶される情報を取得し得る。

【0096】

本発明の幾つかの実施形態では、クライアント１４３０又はサーバ１４２０（又は両方）は、１つ又は複数のネットワーク１４１０を介してローカル又はリモートに展開し得る１つ又は複数の専用サーバ又はアプリケーションを利用し得る。例えば、１つ又は複数のデータベース１４４０を本発明の１つ又は複数の実施形態により使用し得るか、又は参照し得る。データベース１４４０を多種多様なアーキテクチャで、多種多様なデータアクセス及び処理手段を使用して構成し得ることを当業者は理解されたい。例えば、様々な実施形態では、１つ又は複数のデータベース１４４０は、構造化クエリ言語（ＳＱＬ）を使用する関係データベースシステムを含み得、一方、他のデータベース１４４０は、当技術分野で「ＮｏＳＱＬ」（例えば、ハドゥープ（Hadoop）（登録商標）、カサンドラ（Cassandra）（登録商標）、グーグルビッグテーブル（Google BigTable）（登録商標）等）と呼ばれるような代替のデータ記憶技術を含み得る。幾つかの実施形態では、カラム指向データベース、インメモリデータベース、クラスタデータベース、分散データベース、又はフラットファイルデータリポジトリ等の変形データベースアーキテクチャを本発明により使用し得る。本明細書において特定の実施形態に対して特定のデータベース技術又は特定の構成の構成要素が指定されない限り、既知又は将来のデータベース技術の任意の組み合わせを適宜使用し得ることを当業者は理解し得る。さらに、本明細書で使用される「データベース」という用語が、物理的なデータベースマシン、単一のデータベースシステムとして機能するマシンのクラスタ、又は全体データベース管理システム内の論理データベースを指し得ることを理解されたい。「データベース」という用語の所与の使用に対して特定の意味が指定されない限り、この用語のこれらの意味のうちの任意の意味を意味するものと解釈されたく、これらの意味の全てが、当業者による「データベース」という用語の通常の意味として理解される。

【0097】

同様に、本発明の大半の実施形態は、１つ又は複数のセキュリティシステム１４６０及び構成システム１４５０を利用し得る。セキュリティ及び構成の管理は、一般的な情報技術（ＩＴ）及びウェブ機能であり、それぞれの幾らかの量は一般に任意のＩＴ又はウェブシステムに関連付けられる。特定のセキュリティ１４６０又は構成システム１４５０若しくは手法が任意の特定の実施形態の説明によって特に要求されない限り、限定ではなく、現在当技術分野で既知であるか、又は将来知られる任意の構成又はセキュリティサブシステムを、本発明の実施形態と併せて使用し得ることを当業者は理解し得る。

【0098】

様々な実施形態では、本発明のシステム又は方法を実施する機能は、任意の数のクライアント及び／又はサーバ構成要素に分散し得る。例えば、本発明に関連して様々な機能を実行する様々なソフトウェアモジュールを実施し得、そのようなモジュールは、様々に実施して、サーバ及び／又はクライアント構成要素で実行することができる。

【0099】

したがって、本明細書に開示される様々な実施形態は、ソースから、同じ視聴覚空間内のＴＶ及びスピーカ等の複数のメディアデバイスへのメディアの送信を可能にする。実施形態によれば、これは、Ｗｉ−Ｆｉ等の無線ネットワークを介して行い得る。様々な実施形態は、同じリスニングゾーン又は閲覧ゾーン内にあるスピーカ等の全てのメディアレンダリングデバイスが、互いに精密に同期できるようにし、それにより、聴き手及び／又は閲覧者はいかなる非意図的なメディア経験も認識しない。

【0100】

上述した様々な実施形態の可能な様々な変更を当業者は認識し得る。したがって、本発明は特許請求の範囲及びその均等物によって規定される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】