特開 2019-68422 ミラーリングのためのコンピュータ・プログラム及び方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】特開2019-68422(P2019-68422A)

(43)【公開日】2019年4月25日

(54)【発明の名称】ミラーリングのためのコンピュータ・プログラム及び方法

(51)【国際特許分類】

   H04N 21/443 20110101AFI20190329BHJP

   G06F 13/00 20060101ALI20190329BHJP

【ＦＩ】

   H04N21/443

   G06F13/00 547V

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

【全頁数】19

(21)【出願番号】特願2018-186888(P2018-186888)

(22)【出願日】2018年10月1日

(31)【優先権主張番号】62/565,891

(32)【優先日】2017年9月29日

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

(31)【優先権主張番号】15/859,329

(32)【優先日】2017年12月30日

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

(71)【出願人】

【識別番号】391002340

【氏名又は名称】テクトロニクス・インコーポレイテッド

【氏名又は名称原語表記】ＴＥＫＴＲＯＮＩＸ，ＩＮＣ．

(74)【代理人】

【識別番号】110001209

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

(72)【発明者】

【氏名】ダンカン・ジー・ミラード

【テーマコード（参考）】

5B084

5C164

【Ｆターム（参考）】

5B084AA05

5B084AA12

5B084AB07

5B084AB37

5B084AB38

5B084BA03

5B084BB01

5B084CD02

5B084DB02

5B084DC02

5B084DC12

5B084DC13

5C164FA29

5C164TA08S

5C164UA03S

5C164UB41S

5C164UB51P

5C164UD01S

5C164YA14

(57)【要約】

【課題】ネットワーク・メディア・オープン仕様（ＮＭＯＳ）において、機能を改善又は追加する。
【解決手段】ミラーリング・ノードは、レシーバ・ノードとのミラーリング関係を維持するよう動作する。このために、ミラーリング・ノードは、ポーリング・メッセージ４１５をレジストリへ送信すると、レジストリは、レシーバのフロー状態に関する応答メッセージ（フロー・メッセージ）４１７を送信する。次にミラーリング・ノードは、遠隔ノードのターゲット・レシーバのフロー状態をミラーリングするようローカルのレシーバを設定してレシーバ・ノードのフロー状態をコピーし、センダー１からフロー４１９を受ける。レシーバ・ノードが、センダー２からのフロー４２７の受信を開始すると、フロー状態が変化したことを示す通知メッセージ４２９がレジストリへ送信される。
【選択図】図４

【特許請求の範囲】

【請求項1】

コンピュータ・プログラムであって、ノードのプロセッサで実行されると、上記ノードが、
ネットワーク・メディア・オープン仕様（ＮＭＯＳ）のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させ、
遠隔ノードにおけるターゲット・レシーバのフロー状態に関するフロー・メッセージを上記ＮＭＯＳのＡＰＩを介して受け、
上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態をミラーリングするように、ローカル・デバイスにおけるローカル・レシーバを設定し、
上記ＮＭＯＳのＡＰＩを介して、上記ローカル・デバイスの上記ローカル・レシーバのアップデートされたフロー状態に関してレジストリに通知するコンピュータ・プログラム。

【請求項2】

上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態をミラーリングする処理が、上記ターゲット・レシーバと共用するセンダー・ノードから受けた共用のフローを上記ローカル・レシーバで取得する処理を含む請求項１のコンピュータ・プログラム。

【請求項3】

上記フロー・メッセージを上記レジストリ、上記遠隔ノード又は接続マネージャから受ける請求項１又は２のコンピュータ・プログラム。

【請求項4】

ローカル・レシーバを含むローカル・デバイスを制御するノードにおいてネットワーク・メディア・オープン仕様（ＮＭＯＳ）のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させる処理と、
遠隔ノードにおけるターゲット・レシーバのフロー状態に関するフロー・メッセージを上記ＮＭＯＳのＡＰＩを介して受ける処理と、
上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態をミラーリングするように、上記ローカル・デバイスにおける上記ローカル・レシーバを設定する処理と、
上記ＮＭＯＳのＡＰＩを介して、上記ローカル・デバイスの上記ローカル・レシーバのアップデートされたフロー状態に関してレジストリに通知する処理と
を具えるミラーリング方法。

【請求項5】

上記フロー・メッセージを上記レジストリ、上記遠隔ノード又は接続マネージャから受ける請求項４のミラーリング方法。

【請求項6】

コンピュータ・プログラムであって、接続マネージャのプロセッサで実行されると、上記接続マネージャが、
レシーバ・ノード及びミラーリング・ノード間のミラーリング・フロー関係を示すデータを受け、
上記レシーバ・ノードのネットワーク・メディア・オープン仕様（ＮＭＯＳ）のアプリケーション・プログラミング・インターフェース（ＡＰＩ）へ上記レシーバ・ノードのターゲット・レシーバにフロー状態の変更を指示するフロー変更メッセージを送信し、
上記フロー変更メッセージを送信するのに応じて上記ミラーリング・ノードのＮＭＯＳのＡＰＩへ上記レシーバ・ノードの上記ターゲット・レシーバの上記フロー状態に関するフロー・アップデート・メッセージを送信するコンピュータ・プログラム。

【請求項7】

上記プロセッサは、更に、上記接続マネージャに、上記ミラーリング・フロー関係を示す上記データを受けるのに応じて、上記ミラーリング・ノードへミラーリング・セットアップ・メッセージを送信させる請求項６のコンピュータ・プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、メディア制作環境における試験測定システムに関連するシステム及び方法に関し、特に、メディア制作環境において、あるレシーバ・ノードが別のレシーバ・ノードをミラーリングできるようにするためのシステムとそれを実現するコンピュータ・プログラム及び方法に関する。

【背景技術】

【0002】

ビデオ制作を含むメディア制作技術は、ＳＤＩ（シリアル・デジタル・インタフェース）ベースの伝送技術から、ＩＰ（インターネット・プロトコル）ベースの伝送技術へと移行しつつある。こうしたネットワーク化されたメディア制作環境を提供する仕様として、アドバンストメディアワークフロー協会（AMWA:アムワ、Advanced Media Workflow Association, Inc.）が推進するＮＭＯＳ（Networked Media Open Specifications:ネットワーク・メディア・オープン仕様）がある。これは、完全にネットワーク化されたメディア制作環境の提供を目指したオープンな仕様であり、インターネット上で公開されている（非特許文献１及び２参照）。

【0003】

なお、２０１８年９月２７日現在、ＡＭＷＡには、日本からは、プリンシパル・メンバーとしてソニー株式会社が参加し、アソシエイト・メンバーとして、日本放送協会（ＮＨＫ）、パナソニック株式会社等が参加している（非特許文献３参照）。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開平１１−３９２７０号公報

【特許文献2】特開２００２−１９９３６０号公報

【非特許文献】

【0005】

【非特許文献1】「NMOS Technical Overview」、Advanced Media Workflow Association, Inc.、［online］、［２０１８年９月２７日検索］、インターネット<https://amwa-tv.github.io/nmos/branches/master/NMOS_Technical_Overview.html>

【非特許文献2】「Networked Media Open Specifications」、Advanced Media Workflow Association, Inc.、［online］、［２０１８年９月２７日検索］、インターネット<https://nmos.tv/index.html>

【非特許文献3】Advanced Media Workflow Association, Inc. のウェブサイト、［online］、［２０１８年９月２７日検索］、インターネット<https://www.amwa.tv/>

【発明の概要】

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

【0006】

メディア制作環境では、ビデオ録画装置、ビデオ処理装置、データ記憶装置、データ通信装置、オーディオ記録装置、オーディオ処理装置など、多様な物理的インフラ装置（infrastructure）を利用する。こうした多種多様な装置間のアプリケーション・レベルの通信を標準化するために、多くの努力がなされている。こうした標準化によれば、こうした装置の相互作用が容易に可能となる。これは、結果として、、既存の装置と相互作用する問題を緩和しつつ、個々の装置ベースでアップグレードすることが可能になる。こうした標準化は、また、メディア制作環境において、メンテナンス、試験及び自動化をサポートする。こうした標準化は、標準化された通信プロトコルによって生じるコンポーネント間の自動化された相互作用により、追加機能の追加さえもサポートする。

【0007】

本発明は、こうした環境において、機能を追加又は改善しようとするものである。

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

【0008】

以下では、本願で開示される技術の説明に有益な実施例が提示される。この技術の実施形態は、以下で記述する実施例の１つ以上及び任意の組み合わせを含んでいても良い。

【0009】

実施例１としては、コンピュータ・プログラムがあり、これは、ノードのプロセッサで実行されると、上記ノードが、ネットワーク・メディア・オープン仕様（ＮＭＯＳ）のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させ、遠隔ノードにおけるターゲット・レシーバのフロー状態に関するフロー・メッセージをＮＭＯＳのＡＰＩを介して受け、上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態をミラーリングするようにローカル・デバイスにおけるローカル・レシーバを設定し、上記ＮＭＯＳのＡＰＩを介して、上記ローカル・デバイスの上記ローカル・レシーバのアップデートされたフロー状態に関してレジストリに通知する。

【0010】

実施例２としては、実施例１のコンピュータ・プログラムがあり、このとき、上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態をミラーリングする処理には、上記ターゲット・レシーバと共用するセンダー・ノードから受けた共用のフローを上記ローカル・レシーバで取得する処理がある。

【0011】

実施例３としては、実施例１又は２のコンピュータ・プログラムがあり、このとき、上記プロセッサは、更に、上記ノードに、上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態の情報を要求するポーリング・メッセージをレジストリへ周期的に送信させる。

【0012】

実施例４としては、実施例１〜３のいずれかのコンピュータ・プログラムがあり、このとき、上記フロー・メッセージは、上記レジストリから受ける。

【0013】

実施例５としては、実施例１又は２のコンピュータ・プログラムがあり、このとき、上記プロセッサは、更に、上記ノードに、上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態の情報を要求するポーリング・メッセージを上記遠隔ノードへ周期的に送信させる。

【0014】

実施例６としては、実施例１、２又は５のコンピュータ・プログラムがあり、このとき、上記フロー・メッセージは、上記遠隔ノードから受ける。

【0015】

実施例７としては、実施例１〜６のいずれかのコンピュータ・プログラムがあり、このとき、上記プロセッサは、更に、上記ノードに、接続マネージャへミラーリング・セットアップ・メッセージを送信させる。

【0016】

実施例８としては、実施例１〜６のいずれかのコンピュータ・プログラムがあり、このとき、上記フロー・メッセージは、接続マネージャから受ける。

【0017】

実施例９としては、方法があり、ローカル・レシーバを含むローカル・デバイスを制御するノードにおいてネットワーク・メディア・オープン仕様（ＮＭＯＳ）のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させる処理と、遠隔ノードにおけるターゲット・レシーバのフロー状態に関するフロー・メッセージをＮＭＯＳのＡＰＩを介して受ける処理と、上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態をミラーリングするように、上記ローカル・デバイスにおける上記ローカル・レシーバを設定する処理と、上記ＮＭＯＳのＡＰＩを介して、上記ローカル・デバイスの上記ローカル・レシーバのアップデートされたフロー状態に関してレジストリに通知する処理とを具えている。

【0018】

実施例１０としては、実施例９の方法があり、このとき、上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態をミラーリングする処理には、上記ターゲット・レシーバと共用するセンダー・ノードから受けた共用のフローを上記ローカル・レシーバで取得する処理がある。

【0019】

実施例１１としては、実施例９又は１０の方法があり、上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態の情報を要求するポーリング・メッセージをレジストリへ周期的に送信する処理を更に具えている。

【0020】

実施例１２としては、実施例９〜１１のいずれかの方法があり、このとき、上記フロー・メッセージは、上記レジストリから受ける。

【0021】

実施例１３としては、実施例９又は１０の方法があり、上記遠隔ノードの上記ターゲット・レシーバの上記フロー状態の情報を要求するポーリング・メッセージを上記遠隔ノードへ周期的に送信する処理を更に具えている。

【0022】

実施例１４としては、実施例９、１０又は１３の方法があり、このとき、上記フロー・メッセージは、上記遠隔ノードから受ける。

【0023】

実施例１５としては、実施例９〜１１のいずれかの方法があり、接続マネージャへミラーリング・セットアップ・メッセージを送信する処理を更に具えている。

【0024】

実施例１６としては、実施例９〜１１のいずれかの方法があり、このとき、上記フロー・メッセージは、接続マネージャから受ける。

【0025】

実施例１７としては、コンピュータ・プログラムがあり、これは、接続マネージャのプロセッサで実行されると、上記接続マネージャが、レシーバ・ノード及びミラーリング・ノード間のミラーリング・フロー関係を示すデータを受け、上記レシーバ・ノードのネットワーク・メディア・オープン仕様（ＮＭＯＳ）のアプリケーション・プログラミング・インターフェース（ＡＰＩ）へ上記レシーバ・ノードのターゲット・レシーバにフロー状態の変更を指示するフロー変更メッセージを送信し、上記フロー変更メッセージを送信するのに応じて上記ミラーリング・ノードのＮＭＯＳのＡＰＩへ上記レシーバ・ノードの上記ターゲット・レシーバの上記フロー状態に関するフロー・アップデート・メッセージを送信する。

【0026】

実施例１８としては、実施例１７のコンピュータ・プログラムがあり、このとき、上記プロセッサは、更に、上記接続マネージャに、上記ミラーリング・フロー関係を示す上記データを受けるのに応じて、上記ミラーリング・ノードへミラーリング・セットアップ・メッセージを送信させる。

【0027】

実施例１９としては、実施例１７又は１８のコンピュータ・プログラムがあり、このとき、上記プロセッサは、更に、上記接続マネージャに、ミラーリング・セットアップ・メッセージの一部として、上記ミラーリング・ノードから上記ミラーリング・フロー関係を示す上記データを受信させる。

【0028】

実施例２０としては、実施例１７〜１９のいずれかのコンピュータ・プログラムがあり、このとき、上記プロセッサは、更に、上記接続マネージャに、ユーザの入力として、上記ミラーリング・フロー関係を示す上記データを受けさせる。

【0029】

本発明の実施形態の態様、特徴及び効果は、添付の図面を参照し、以下の実施形態の説明を読むことで明らかとなろう。

【図面の簡単な説明】

【0030】

【図1A】図１Ａは、ネットワーク・メディア・オープン仕様（ＮＭＯＳ）ベースの通信プロトコルに基づいて、相互通信するよう構成される例示的なメディア制作システムのブロック図である。

【図1B】図１Ｂは、例示的なメディア制作システムにおける例示的な登録及び発見インスタンスのブロック図である。

【図1C】図１Ｃは、例示的なメディア制作システムにおける例示的なノードのブロック図である。

【図2】図２は、例示的なセンダー・ノードのブロック図である。

【図3】図３は、例示的なレシーバ・ノードのブロック図である。

【図4】図４は、ポーリングによってレシーバ・ノードをミラーリングする例示的なメカニズムのプロトコルの処理フロー図である。

【図5】図５は、ポーリングによってレシーバ・ノードをミラーリングする別の例示的なメカニズムのプロトコルの処理フロー図である。

【図6】図６は、接続マネージャを利用してレシーバ・ノードをミラーリングする例示的なメカニズムのプロトコルの処理フロー図である。

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

【0031】

ＮＭＯＳは、メディア制作環境をコントロールする例示的な標準化された機構である。ＮＭＯＳは、種々のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を利用しており、これによって、ビデオ制作のインフラ装置（基盤となる装置）を用いたネットワーク・ベースのアプリケーション・レベルの通信を可能にしている。例えば、ＮＭＯＳは、ビデオ・カメラ、オーディオ・レコーダ、撮影後編集（post production）装置、モニタなどの間の通信を可能にしている。ＮＭＯＳのＡＰＩは、インターネット・プロトコル（ＩＰ）ベースの通信を利用し、これによって、種々のコンポーネントがパケット・ベースのメッセージを通信可能となっている。特定の実施例では、ビデオ制作モニタが、複数のビデオ・カメラで生成されて送信された複数のビデオ・ストリーム（「フロー」として知られる）間で、切り替えられても良い。試験を行うためには、ユーザは、このビデオ制作モニタに表示されるコンテンツと同じものを表示する（mirror：ミラーリングする、そっくりに再現する）第２のモニタを利用したいと考えることがあるかもしれない。

【0032】

本願では、モニタのような「ノード」が他のノードをミラーリング（そっくり再現、複製）するのを可能にする例示的なメカニズムを開示する。ノードとしては、例えば、複数のデバイス（device：装置）があって良く、これらとしては、センダー（sender：送信装置等）、レシーバ（receiver：受信装置等）、又は、これらの両方がある。ノードは、レジストリ（種々の設定のデータベース）に、そのノードの種々の設定が登録される。次いで、接続管理ノードは、複数ノード間の接続を制御する。ミラーリング・ノードは、ポーリング（polling：定期的な問い合わせ又は照会）を利用して、センダー（受信装置）ノードをミラーリングできる。ポーリングの例では、ミラーリング・ノードは、レシーバ・ノードとのミラーリング関係を認識するように設定される。ミラーリング・ノードは、周期的にレシーバ・ノード又はそのレジストリをポーリングする。これに応答して、ミラーリング・ノードは、レシーバ・ノードの現在のフロー状態を受ける。レシーバ・ノードが、新しいセンダー・ノードに切り替わると、ミラーリング・ノードは、次のポーリング・メッセージが送信された後に、新しいセンダーを示すアップデートされたフロー状態を受ける。ミラーリング・ノードは、次いで、レシーバ・ノードのフロー状態とマッチングするように再構成され、これによって、レシーバ・ノードが受信したフローを得る。接続マネージャに制御される例では、接続マネージャは、ミラーリング・ノードとレシーバ・ノード間のミラーリング関係の認識を維持する。また、接続マネージャは、レシーバ・ノードのフロー状態も制御する。これにより、接続マネージャが、レシーバ・ノードが新しいセンダーに切り替わるように設定変更すると、その接続ノードもミラーリング・ノードをレシーバ・ノードと同じセンダーに切り替わるように設定変更する。

【0033】

図１Ａ〜１Ｃは、ＮＭＯＳベースの通信プロトコルに従って、相互通信するように構成された例示的なメディア制作システム１００の構成要素間の関係を示す図である。最初に図１Ａを参照すると、システム１００には、１つ以上のデータ・センタ・ネットワーク１１０中のサーバ１１２上で動作する登録及び発見システム１１４がある。システム１００には、登録及び発見システム１１４に登録されるよう構成されるノード１３１、１３２及び１３３もある。また、システム１００には、ノード１３１〜１３３間の接続を管理できる接続マネージャ１３４もある。

【0034】

データ・センタ・ネットワーク１１０は、通信ネットワークを介して相互接続された演算リソースの任意のプールである。このデータ・センタ・ネットワーク１１０は、単一のビルディング内に収容されていても良いし、電気的又は光学的ケーブルによる基幹ネットワークを通じて接続できる、複数の場所に地理的に分散されたネットワークでも良い。一例としては、データ・センタ・ネットワーク１１０が、複数のサーバ１１２を含んでいても良い。これらサーバ１１２は、ラック中に並べて、電気的又は光学的ケーブルによって相互接続されていても良い。また、データ・センタ・ネットワーク１１０は、ネットワークのセキュリティを維持すると共に、異なるドメインに跨がってアドレス指定を行えるよう、異なるネットワークへ接続するためのゲートウェイを有していても良い。サーバ１１２は、演算リソースを提供できる任意のコンピュータ装置で良い。例えば、サーバ１１２としては、プロセッサ、メモリ、ネットワーク接続用リソースなどを有していても良い。これらサーバ１１２は、夫々が１つの特定データ・センタ・テナント専用であっても良いし、柔軟なリソースのプロビジョニング（必要に応じたリソースの割当）を用いて、クラウド・モデルで構成されても良い。サーバ１１２は、メディア・アクセス（ＭＡＣ）レイヤ・ブロードキャスト・プロトコル（例えば、ブロードキャスト）、インターネット・プロトコル（ＩＰ）レイヤ・プロトコル（例えば、ユニキャスト）又はこれらの組み合わせによって通信を行って良い。

【0035】

登録及び発見システム１１４は、サーバ１１２のハードウェアを用いて動作する。例えば、登録及び発見システム１１４を動かす命令は、サーバ１１２上のキャッシュ、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）などに記憶されている。次いで、これら命令は、サーバ１１２上のプロセッサによって実行される。サーバ１１２のネットワーク・リソースは、ノード１３１〜１３３及び接続マネージャ１３４が、登録及び発見システム１１４と通信可能にするために利用される。データ・センタ・ネットワーク１１０は、クラウド・ネットワークとして動作する地理的に分散されたサーバ１１２を含むことがあるので、登録及び発見システム１１４も、複数のマシーンについての物理的に広いエリアに渡って同時に動作するように、分散されていても良い。登録及び発見システム１１４は、複数のローカル・ネットワークの複数のノードが、機能及び現在の状態を登録可能となるように構成される。こうしたノードは、他のノードの機能と状態を判断するために、登録及び発見システム１１４に照会（query：質問、問い合わせ）することができる。

【0036】

登録及び発見システム１１４は、複数の登録及び発見インスタンス１２０として動作するよう構成される。図１Ｂを参照すると、登録及び発見インスタンス１２０には、レジストリ１２１、登録サービス１２５及び照会サービス１２３がある。レジストリ１２１は、データベースとして実現されても良い。例えば、レジストリ１２１は、ノードの機能及び現在の状態を記憶し、アップデート（更新）し、検索できる任意のメモリ構造であっても良い。登録サービス１２５は、ノードの機能又はノード状態を受けるための、例えば、ＡＰＩを介してノードと通信できる任意のプロセスである。次いで登録サービス１２５は、こうしたノード機能やノード状態を記憶するために、レジストリ１２１へ伝送する。照会サービス１２３は、ノードの機能／状態に関する照会（query：問い合わせ）を受けて、こうした照会に対する応答を提供するために、例えば、ＡＰＩを介してノードと通信できる任意のプロセスである。例えば、照会サービス１２３は、ノードからの照会を受けて、この照会に応答してレジストリ１２１からデータを取得し、要求されたデータを含む応答を提供する。登録サービス１２５や照会サービス１２３は、ＲＥＳＴｆｕｌ（Representational state transfer）、ＨＴＴＰ（Hypertext transfer protocol）やＪＳＯＮ（JavaScript（登録商標）object notation）のようなＩＰベースのプロトコルによってノードと通信する。ある特定の実施例では、登録サービス１２５や照会サービス１２３は、ＨＴＴＰのＧＥＴやＰＯＳＴコマンドによって、複数ノード及びその関連する登録及び発見インスタンス１２０間のＩＰネットワーク（例えば、インターネット）を通じて、複数のノードと通信しても良い。これら登録及び発見インスタンス１２０は、異なるメディア制作環境をサポートするように分離されても良く、また、通信するために、異なるネットワーク・アドレスを用いても良い。従って、これら登録及び発見インスタンス１２０は、複数プロセスの分散されたグループと考えることもできる。しかし、レジストリ１２１は、レジストリ・エントリの複製を可能とするために、レジストリ・エントリを通知するように構成されても良い。このように、レジストリ１２１は、ノード、ノードの機能及びノード状態の完全な又は部分的なリストを含むように構成されても良い。

【0037】

図１Ａを再度参照すると、複数のノードは、登録及び発見インスタンス１２０と相互に通信しても良い。簡単かつ明確に説明するため、４つのノードだけを示しているが、任意のもっと多数のノードが登録及び発見インスタンス１２０と相互に通信しても良いことに注意されたい。ＮＭＯＳベースのメディア制作システム１００では、１つのノードは、関連する機能ブロックを提供する１つ以上のデバイスに関するホストである。こうしたデバイスとしては、ビデオ・レコーダ、オーディオ・レコーダなどのようなデータを生成するデバイスや、モニタ、スピーカ、ビデオ／オーディオ処理装置などのようなデータを受ける装置が含まれていても良い。説明の都合上、データを生成するノードは、本願では、センダー・ノードと呼び、そうしたデータを受けるノードは、レシーバ・ノードと呼ぶことにする。図示するように、ノード１３１は、センダー・ノードとして機能し、これは、データ（例えば、ビデオやオーディオのストリーム）を生成し、こうしたデータをフロー１４０として伝送する。フロー１４０は、データの関連する任意のストリームである。ノード１３２及び１３３は、センダー・ノード１３１から送信されたフロー１４０を受けるので、レシーバ・ノード（例えば、モニタ）である。ノード１３２と１３３には、ミラーリング関係１４２がある。ミラーリング関係１４２は、一方のミラーリング・レシーバ・ノードが、もう１つのレシーバ・ノードと共通のフロー状態を維持するのに必要な処理を行うことを示している。本願で用いているように、フロー状態とは、対応するノードが、ある特定の時間に、フローを送信しているか、又は、受信していることを示す。明快な説明とするため、本願では、ノード１３２をレシーバ・ノードと呼び、ノード１３２のフロー状態をミラーリングするノード１３３をミラーリング・ノードと呼ぶことにする。言い換えると、レシーバ・ノード１３２が新しいセンダーから新しいフロー１４０を受け始めるたびに、ミラーリング・ノード１３３が、レシーバ・ノード１３２のフロー状態をコピーしてローカルのフロー状態をアップデートし、これによって、共通のセンダー・ノード１３１から共通のフローを受けることになる。ノード１３１〜１３３は、対応するデバイス、デバイスの機能や、フロー状態のような現在の状態を登録するために、登録及び発見インスタンス１２０の登録サービス１２５や照会サービス１２３と通信できる。

【0038】

接続マネージャ１３４は、制御ノードとして動作し、ノード１３１〜１３３のようなノードのグループに関する接続（例えば、フロー／フロー状態）を管理するよう構成される。例えば、接続マネージャ１３４は、表示装置とユーザの入力部を有していても良い。接続マネージャ１３４は、更に、照会サービス１２３とコンタクトして（連絡を取って）、ノード１３１〜１３３に関する登録された情報を決定する。接続マネージャ１３４は、また、登録サービス１２５とコンタクトしたり、ノード１３１〜１３３と直接コンタクトすることによって、フロー状態を変更しても良い。こうした変更は、ユーザ表示装置を介してユーザに表示され、また、こうした変更がユーザの入力（例えば、キーボード、マウス、トラックボール、タッチスクリーンなどからの入力）に基づいて行われても良い。

【0039】

ここで図１Ｃを参照すると、ノード１３１〜１３３には、ノードＡＰＩ１３７と、１つ以上のデバイス１３８があり、そして、デバイス１３８には、レシーバ１３５やセンダー１３６がある。接続マネージャ１３４は、詳細には示していないが、ノード１３１〜１３３と実質的には類似している。デバイス１３８は、１つ以上のハードウェア・コンポーネントとして供給される任意の関連する機能ブロックである。よって、デバイス１３８は、１つ以上のビデオ・レコーダ、オーディオ・レコーダ、モニタ、スピーカ、オーディオ／ビデオ処理システムなどを含んでいても良い。ノード１３１〜１３３は、対応する複数のデバイス１３８の通信をホストし、結果として、これら通信を管理する。デバイス１３８は、レシーバ１３５やセンダー１３６を介して通信を行う。デバイス１３８は、特定の実施形態での必要に応じて、任意の個数のセンダー１３６及びレシーバ１３５を有することができる。センダー１３６は、データ・フローを送るのに利用される複数のリソースから構成されるグループである。例えば、センダー１３６は、ネットワーク・カード、ネットワーク・ポート、ワイヤレス・ネットワーク・アダプタ、ネットワーク・アドレスなどを有していても良い。レシーバ１３５は、データ・フローを受けるのに利用される複数のリソースから構成されるグループである。例えば、レシーバ１３５は、ネットワーク・カード、ネットワーク・ポート、ワイヤレス・ネットワーク・アダプタ、ネットワーク・アドレスなどを有していても良い。ノードＡＰＩ１３７は、遠隔のノードからの命令を、対応するデバイス１３８、レシーバ１３５又はセンダー１３６で解釈して、実行できる形式へと変換するプログラミング・インタフェースである。よって、接続マネージャ１３４は、ノードＡＰＩ１３７を介してノード１３１〜１３３に命令を伝えても良いし、その逆も同様である。更に、ノード１３１〜１３３は、ノードＡＰＩ１３７を介して、登録サービス１２５や照会サービス１２３と通信しても良い。こうしたノードＡＰＩ１３７を介した通信は、例えば、ＬＡＮ（ローカル・エリア・ネットワーク）、ＶＬＡＮ（仮想ローカル・エリア・ネットワーク）、ＶＸＬＡＮ（virtual extensible local area network）などを通じて、ブロードキャストを用いて、センダー１３６によってフロー１４０を送信したり、レシーバ１３５によってフロー１４０を受信することを可能にする。こうしたノードＡＰＩ１３７を介した通信は、また、ミラーリング・ノード１３３が、対応するレシーバ１３５において共通のセンダー１３６から共通のフロー１４０を受けることによって、レシーバ・ノード１３２とミラーリング関係１４２を維持することも可能にする。

【0040】

図２は、例示的なセンダー・ノード２００のブロック図であり、これは、システム１００において、センダー・ノード１３１を実現するものでも良い。具体的には、センダー・ノード２００は、デバイスとしては、ビデオ・カメラとして動作する。センダー・ノード２００のデバイスには、レンズ２０１がある。レンズ２０１は、屈折を利用して光線を収束させる透過性光学デバイスである。レンズ２０１で屈折された光は、画像センサのようなセンサ２０３によって捕捉される。センサ２０３は、レンズ２０１からの光を、画像を表すデータに対応する電気信号に変換／捕捉できる回路である。電気信号は、ビデオ・プロセッサ２０７へ送られる。ビデオ・プロセッサ２０７は、画像を表す捕捉されたデータに対して、種々のフィルタを適用できる処理回路である。これらフィルタは、視覚的なアーティファクトを除去したり、色の補正をしたり、その他のプリ処理技術を実行できる。例えば、ビデオ・プロセッサ２０７は、コーダ・デコーダ（codec：コーデック）２０５を利用して、画像データを圧縮された標準形式へエンコードしても良い。この圧縮によって、記憶空間を小さくでき、記憶及び伝送が容易になる。コーデック２０５は、標準化されたやり方で画像データをエンコードするので、レシーバ・ノードは、画像データを伸張して、センサ２０３／ビデオ・プロセッサ２０７で元々捕捉されたような画像を得ることができる。また、ビデオ・プロセッサ２０７は、メモリ２１１に記憶された命令を実行して、ノード２００を動作させても良い。画像データは、メモリ２１１に記憶されても良い。メモリ２１１は、画像データや、ビデオ・プロセッサ２０７を動作させる実行可能な命令を記憶できる任意の形式のメモリ・コンポーネント（例えば、キャッシュ・メモリ、ＲＡＭ、ＲＯＭなど）で良い。センダー・ノード２００のビデオ・カメラ・デバイスは、ネットワーク・インタフェース２０９も有していて良く、これは、１つ以上のセンダーやレシーバとして機能する。ネットワーク・インタフェース２０９は、有線又は無線のインタフェースでも良く、対応するトランシーバ及びネットワーク通信装置を有している。センダー１３６のようなセンダーとして機能する場合は、ネットワーク・インタフェース２０９は、圧縮画像データを、ネットワークを通じたユニキャスト、ブロードキャスト又はマルチキャスト伝送用のパケットのフローに変換しても良い。レシーバ１３５のようなレシーバとして機能する場合は、ネットワーク・インタフェース２０９は、センダー・ノード２００を動作させる命令を受けるのに加えて、他の関連するデータを受けても良い。センダー・ノード２００は、また、必要に応じて、ネットワーク・インタフェース２０９を介してネットワークを通じて、音を記録したり、エンコードしたり、送信したりするコンポーネントも有していても良い。センダー・ノード２００は、説明を明快にする都合上、記載したが、実施例は、これに限定されるものでないことに注意されたい。メディア制作環境における目的に合わせて、多くの異なるセンダー・ノード２００の形式を利用できるが、そうした種々のものを全て説明するのは、本願の要旨を超えるものなので、割愛する。

【0041】

図３は、例示的なレシーバ・ノード３００のブロック図であり、これは、システム１００において、レシーバ・ノード１３２やミラーリング・ノード１３３を実現するのに利用できる。また、実施形態によっては、ノード３００が、接続マネージャ１３４やサーバ１１４を実現するのに利用されても良い。ノード３００は、ネットワーク・インタフェース３０７を用いても良く、これは、センダー・ノード２００のネットワーク・インタフェース２０９とほぼ同様であっても良い。例えば、レシーバ・ノード３００として機能する場合、ネットワーク・インタフェース３０７は、レシーバ１３５として機能し、よって、センダー・ノードからのフローを受けても良い。実施形態によっては、ネットワーク・インタフェース３０７が、他のノードとの通信、データの転送などをサポートするセンダー１３６としても機能しても良い。ネットワーク・インタフェース３０７からのデータは、プロセッサ３０５で処理される。実施形態によっては、プロセッサ３０５が、ＡＳＩＣ（application specific integrated circuit）、ＤＳＰ（digital signal processor）、ＦＰＧＡ（field programmable gate array）などのような任意の処理回路を含んでいても良い。プロセッサ３０５は、画像データをデコードしてスクリーン３０１上で表示するために、コーデックを用いても良い。プロセッサ３０５は、例えば、ビデオ編集処理を用いて、画像データを変更しても良い。プロセッサ３０５は、ユーザ入力部３０９からのユーザによる入力に基づいて動作しても良い。ユーザ入力部３０９は、マウス、キーボード、タッチスクリーンなど、ユーザによるデータに対する操作をサポートする任意のデバイスを有していても良い。また、プロセッサ３０５は、メモリ３０３に記憶された命令を実行することによって、ノード３００を動作させても良い。ユーザ入力部３０９は、ノード３００に直接結合されていても良いし、ネットワーク・インタフェース３０７を介してノード３００と通信するようにしても良い。スクリーン３０１は、画像データを表示できる任意のデバイスである。スクリーン３０１は、ノード３００に直接結合されていても良いし、ネットワーク・インタフェース３０７を介してノード３００と通信するようにしても良い。スクリーン３０１は、命令に対するフィードバックをユーザに提供すると共に、タッチスクリーンである場合には、ユーザ入力部３０９の一部としても機能できる。ノード３００にもメモリ３０３があり、これは、センダー・ノード２００のメモリ２１１と同様のものである。よって、メモリ３０３は、更なる処理、長期間の記憶、スクリーン３０１での表示中だけの一時的な記憶などのために、メディア（ビデオやオーディオ、関連データなど）を記憶できるよう構成されても良い。また、レシーバ・ノード３００は、スピーカ３１１を含んでいても良く、これは、例えば、センダー・ノードで捕捉され、ネットワーク・インタフェース３０７を介して受けた音を再生できる任意の変換器であっても良い。実施形態によっては、開示したコンポーネントの一部だけを利用して必ずしも全部は利用しないこともあるし、別の実施形態では、更に追加のコンポーネントを利用することもあることに注意されたい。レシーバ・ノード３００は、明快な説明をサポートするため、レシーバ・ノード、ミラーリング・ノード、接続マネージャやサーバで利用できる種々の汎用のコンポーネントを開示すために示している。よって、ノード３００が含むコンポーネントは、あくまで例示であって、これらに限定されるものではない。

【0042】

図４は、例えば、ノード２００や３００を利用してポーリングによってレシーバ・ノードをミラーリングすることでシステム１００を実現する例示的なメカニズム４００のプロトコルの処理フロー図である。メカニズム４００は、プロセッサが、対応するノードにおいてメモリ中に記憶された命令を実行することによって実現されても良い。メカニズム４００は、対応するノードを動作させる方法としても機能する。メカニズム４００が、接続マネージャ、レジストリ（例えば、レジストリ１２１）、登録サービス１２５、照会サービス１２３、レシーバ・ノード、第１センダー・ノード（センダー１）、第２センダー・ノード（センダー２）、そして、ミラーリング・ノードを利用するのは、説明を明確にするのが目的であることに注意されたい。従って、特定の実施形態／用途によっては、追加のノードを利用しても良い。

【0043】

メカニズム４００は、センダー１がレジスタ・メッセージ４０１をレジストリへ送ったときに始まるとしても良い。レジスタ・メッセージ４０１は、開始時に送信されても良く、センダー１の機能、アドレス、利用可能なフローなどを示す。次いで、センダー１は、動作を開始しても良い。例えば、センダー１がビデオ・カメラである場合では、センダー１がビデオの捕捉を開始し、そのフローをネットワークを通じて送信する。レシーバ・ノードも、例えば、開始時に、レジスタ・メッセージ４０３をレジストリへ送信しても良い。レジスタ・メッセージ４０３は、レシーバ・ノードの機能、ネットワーク・アドレス、現在のフロー状態などを含んでいる。

【0044】

次いで、接続マネージャは、レシーバ４０５がセンダー１からのフローを利用し始めるようにレシーバ４０５を設定する。例えば、接続マネージャは、レジストリの照会された情報に基づいて、ネットワーク中の利用可能なセンダー・ノード及びレシーバ・ノードを示すデータをスクリーンに追加しても良い。ユーザは、どのレシーバ・ノードが、対応するセンダー・ノードからのフローを受けるべきかを示しても良い。接続マネージャは、次いで、ユーザの入力に基づいて、レシーバ４０５を設定しても良い。設定後、レシーバは、センダー１からのフロー４０７の受信を開始する。フロー４０７を受けることによって、レシーバにおけるフロー状態が変化する。そこで、レシーバは、新しいフロー状態（例えば、センダー１からフローを受けている状態）を示す通知メッセージ４０９をレジストリへ送信する。

【0045】

しばらくして、ミラーリング・ノードが、レシーバ・ノードのミラーリングを開始しても良い。例えば、レシーバ・ノードには、ユーザの入力に基づいて、時間経過に応じて表示がシフトする、１つ以上のカメラからのフローを表示するモニタがあっても良い。ミラーリング・ノードは、例えば、レシーバ・ノード上で何が実際に表示されているのかを示すなど、試験のために利用されても良い。また、ミラーリング・ノードは、複数のユーザがライブのストリームを追いかけることができるように、レシーバをミラーリングするのに利用されても良い。例えば、レシーバは、複数カメラに基づいて、視聴者に届けるために放送される、送信される制作したビデオを表示するプライマリ（又はメイン）モニタであっても良く、そして、ミラーリング・ノードは、視聴者に放送されるコンテンツを表示するのに利用されても良い。いずれの場合でも、開始時に、ミラーリング・ノードは、レジスタ・メッセージ４１１をレジストリへ送信しても良い。レジスタ・メッセージ４１１は、ミラーリング・ノードの機能、ネットワーク・アドレス、現在のフロー状態などを含んでいても良い。ミラーリング・ノードは、レシーバ・ノードをミラーリングするように、ローカルで設定できても良いし、遠隔から設定できてもよい。例えば、ミラーリング・ノードが遠隔から（例えば、遠隔にある設定（configuration）マネージャにおいて）設定される場合なら、この設定マネージャは、ミラーリング・ノードがレシーバをミラーリングすべきことを示す、オプションのセットアップ・メッセージ４１２をミラーリング・ノードへ送信する。しかし、場合によっては、ユーザが、物理的にミラーリング・ノードを操作して、レシーバをミラーリングするようにミラーリング・ノードを設定しても良い。更に別の場合では、ミラーリング・ノードが、ローカルのユーザの入力に基づいて、セットアップ・メッセージ４１２を接続マネージャに送信しても良い。上述のいずれの場合も、ミラーリング・ノードは、レシーバをミラーリングするように設定され（ミラーリング・セットアップ４１３）、これによって、レシーバがフローを受けるたびに、ミラーリング・ノードもフローを受ける。こうした設定は、ミラーリング・ノードで動作しているＮＭＯＳのＡＰＩによって実行されても良い。

【0046】

メカニズム４００では、ミラーリング・ノードが、レシーバ・ノードとのミラーリング関係を維持する責任を持っている。このため、ミラーリング・ノードは、ポーリング・メッセージ４１５をレジストリへ送信する。ポーリング・メッセージ４１５は、レジストリがレシーバ・ノードの現在のフロー状態を示すことを要求するものである。言い換えると、ミラーリング・ノードの観点からすれば、ポーリング・メッセージ４１５は、遠隔のレシーバ・ノードにあるターゲット（対象とする）のレシーバのフロー状態（の情報）を要求するものである。すると、レジストリは、ターゲット（対象の装置）の状態（即ち、ここでは、レシーバのフロー状態）に関する応答メッセージ４１７を送信する。次いで、ミラーリング・ノードは、ＮＭＯＳのＡＰＩを介して、フロー・メッセージとして応答メッセージ４１７を受ける。メカニズム４００では、フロー・メッセージは、レジストリから受ける。フロー・メッセージは、ミラーリング・ノードに対して、遠隔のレシーバ・ノードにおけるターゲットのレシーバのフロー状態を示す。次いで、ミラーリング・ノードは、遠隔のノードにおけるターゲット・レシーバのフロー状態をミラーリングするように、ミラーリング・ノードによってホストされているローカルのデバイスにおけるローカルのレシーバを設定する。もっとシンプルに言えば、ミラーリング・ノードは、レシーバ・ノードのフロー状態をコピー（複製）する。次いで、ミラーリング・ノードは、フロー４１９を受ける。言い換えると、遠隔のレシーバ・ノードにおけるターゲット・レシーバのフロー状態をミラーリングすることによって、ミラーリング・ノードは、ローカルのレシーバにおいて、ターゲット・レシーバが受けたフローをシェア（share：共用、共有）して受ける。シェアされたフローは、シェアされたセンダー・ノード（この場合では、センダー１）から受ける。次いで、ミラーリング・ノードは、例えば、ＮＭＯＳのＡＰＩを介して、通知メッセージ４２１をレジストリへ送信する。この通知メッセージ４２１は、ミラーリング・ノードでホストされているローカルのデバイスのローカルのレシーバのアップデートされたフロー状態を示す。ミラーリング・ノードは、次いで、周期的に（図４中「・・・」で示す）ポーリング・メッセージ４２３をレジストリへ送信し、レシーバがいつフロー状態を変更したかを判断（決定）する。こうして、ポーリング・メッセージは、遠隔のレシーバ・ノードにおけるターゲット・レシーバのフロー状態（の情報）を要求する。

【0047】

しばらく時間が経過（破線で示す）すると、接続マネージャは、アップデート・レシーバ・メッセージ４２５をレシーバへ送信する。このアップデート・レシーバ・メッセージ４２５は、レシーバにフロー状態を変更するように指示するものであり、この場合では、センダー１に代えて、センダー２からのフローの受信を開始するように指示するメッセージである。レシーバ・ノードは、設定が変更され、次いで、センダー２からのフロー４２７の受信を開始する。レシーバ・ノードは、レシーバ・ノードのフロー状態が変化したことを示す通知メッセージ４２９をレジストリへ送信する。

【0048】

一方で、ミラーリング・ノードは、周期的なポーリング・メッセージの送信を続ける。レジストリへの次のポーリング・メッセージ４３１を送信した後に、レジストリは、ターゲット・レシーバのアップデートされたフロー状態に関する応答メッセージ４３３を送信する。次いで、ミラーリング・ノードは、レシーバ・ノードにおけるターゲット・レシーバのアップデートされたフロー状態とマッチング（整合）するようにローカルのフロー状態をアップデート（更新）する（アップデート４３５）。次いで、ミラーリング・ノードは、センダー１に代えて、センダー２からのフロー４３７を受けるように設定される。このように、ミラーリング・ノードは、周期的なポーリング・メッセージを利用することによって、レシーバの変化に自動的に追従できる。アップデート４３５が完了すると、ミラーリング・ノードは、フロー状態の変化を示す通知メッセージ４３９をレジストリへ送信する。次いで、ミラーリング・ノードは、レシーバのフローの受信元が新たな別のセンダーに変化するまで、レジストリに対してポーリングする処理に戻っても良く、このときには、メッセージ４３１〜４３９が繰り返される。

【0049】

図５は、ポーリングによってレシーバ・ノードをミラーリングする別の例示的なメカニズム５００のプロトコルの処理フロー図である。メカニズム５００は、メカニズム４００とほぼ類似しているが、ミラーリング・ノードが、レジストリにポーリングする代わりに、レシーバ・ノードに直接ポーリングする点が異なっている。簡潔に説明するため、メカニズム４００と重複するメッセージや工程については、参照番号を付けず、詳細な説明は省略する。ミラーリング関係がセットアップされた後、ミラーリング・ノードは、ポーリング・メッセージ５１５を送信する。このポーリング・メッセージ５１５は、ポーリング・メッセージ４１５と類似しているが、レシーバ・ノードへ直接送信され、現在のフロー状態に関する情報を要求するポーリング・メッセージとなる。レシーバ・ノードは、このレシーバ・ノードによってホストされているターゲット・レシーバのフロー状態（の情報）を含む応答メッセージ５１７を送信する。ミラーリング・ノードは、次いで、そのフロー状態をコピー（複製）し、フロー４１９及び通知メッセージ４２１の夫々と同様のやり方で、フロー５１９を受けて、レジストリへ通知メッセージ５２１を送信する。次いで、ミラーリング・ノードは、ポーリング・メッセージ４２３と同様のやり方で、遠隔のレシーバ・ノードへのポーリング・メッセージ５２３の周期的な送信を開始するが、このポーリング・メッセージ５２３は、レジストリへではなく、レシーバ・ノードへ送信される点が異なっている。ポーリング・メッセージ（１つ以上）は、遠隔のレシーバ・ノードにおけるターゲット・レシーバのフロー状態（の情報）の要求を継続的に行う。

【0050】

しばらく時間が経過（破線で示す）すると、接続マネージャは、アップデート・レシーバ・メッセージ５２５をレシーバへ送信する。このアップデート・レシーバ・メッセージ５２５は、レシーバにフロー状態を変更するように指示するものであり、この場合も、センダー１に代えて、センダー２からのフローの受信を開始するように指示するメッセージである。レシーバ・ノードは、設定が変更され、次いで、センダー２からのフロー５２７の受信を開始する。レシーバ・ノードは、レシーバ・ノードのフロー状態が変化したことを示す通知メッセージ５２９をレジストリへ送信する。これら処理の流れは、図４のフロー４２７及び通知メッセージ４２９と同様である。次いで、ミラーリング・ノードは、フロー状態がアップデートされた後、ポーリング・メッセージ５３１を（レジストリへではなく）レシーバへ送信する。次いで、（レジストリではなく）レシーバが、遠隔のレシーバ・ノードにおけるターゲット・レシーバのアップデートされたフロー状態に関する応答メッセージ５３３を送信する。即ち、メカニズム５００では、ミラーリング・ノードは、フロー状態の情報を含むフロー・メッセージを、レジストリからではなく、遠隔のレシーバ・ノードから受ける。次いで、ミラーリング・ノードは、図４のアップデート４３５、フロー４３７の受信及び通知メッセージ４３９の夫々と同様に、ローカルのフロー状態をアップデートし（アップデート５３５）、センダー２からフロー５３７を受け、そして、フロー状態の変化を示す通知メッセージ５３９をレジストリへ送信しても良い。

【0051】

図６は、接続マネージャを利用してレシーバ・ノードをミラーリングする例示的なメカニズム６００のプロトコルの処理フロー図である。メカニズム４００及び５００のように、メカニズム６００は、システム１００におけるノード２００や３００を利用して実現されても良い。しかし、メカニズム４００及び５００とは異なり、メカニズム６００は、ポーリングを利用しない。その代わりに、メカニズム６００では、接続マネージャが、ミラーリング関係の認識を維持する。このように、接続マネージャは、ミラーリングする対象であるレシーバ・ノードにアップデートが指示されるたびに、ミラーリング・ノードにフロー状態（の情報）を送信する。簡潔に説明するため、メカニズム４００及び５００と重複するメッセージや工程については、参照番号を付けず、詳細な説明は省略する。ミラーリング・ノードが始動し、レジストリに登録されると、ミラーリング・ノードは、ミラーリング・ノード関係となるように設定される。ミラーリング・ノードがローカルにセットアップされる場合（例えば、接続マネージャによってではなく）では、ミラーリング・ノードが、レシーバとのミラーリング関係を示す、オプションのセットアップ・メッセージ６１３を接続マネージャへ送信しても良い。このメッセージは、接続マネージャが、ミラーリング・ノードとレシーバとの間のミラーリング・フロー関係の情報に関して設定されていない場合に、接続マネージャに、こうした関係を知らせるものである。こうして、レシーバ・ノードとミラーリング・ノードとの間のミラーリング・フロー関係を示すミラーリング・ノード・セットアップ・メッセージ６１３は、接続マネージャが受けることになる。上述のように、ミラーリング・フロー関係を示すデータは、接続マネージャがユーザからの入力として受けることもできる。よって、場合によっては、逆に、接続マネージャが、ミラーリング・フロー関係を示すデータを受けるのに応答して、オプションのミラーリング・セットアップ・メッセージ６１３をミラーリング・ノードに送信しても良い。

【0052】

次いで、接続マネージャは、ターゲット・レシーバ・ノードのフロー状態（の情報）を含む応答メッセージ６１７をミラーリング・ノードへ送信する。場合によっては、接続マネージャは、フロー状態の情報を判断するのに、レジストリへ照会（問い合わせ）しても良い（図示せず）。こうして、接続マネージャからのフロー・メッセージを、ミラーリング・ノードが受けることになる。ミラーリング・ノードは、ローカルの設定をアップデートし、レシーバ・ノードのフロー状態をコピーする。フロー状態をアップデートすると、ミラーリング・ノードは、センダー１からフロー６１９を受け、次いで、フロー状態の変化を示す通知メッセージ６２１をレジストリへ送信する。

【0053】

しばらく時間が経過（破線で示す）して、例えば、ユーザからの入力を受けて、センダー１に代えて、センダー２からフローを受けるというように、レシーバのフロー状態を変更すると接続マネージャが決定すると、接続マネージャは、アップデート・レシーバ・メッセージ６２５をレシーバへ送信し、これは、フロー変更メッセージとして機能する。アップデート・レシーバ・メッセージ６２５は、レシーバ・ノードのターゲット・レシーバにフロー状態の変更を指示するために、レシーバ・ノードのＮＭＯＳのＡＰＩへ送信される。次いで、レシーバ・ノードは、メカニズム４００及び５００のように、センダー２からフロー６２７を受け、通知メッセージ６２９をレジストリへ送信する。更に、アップデート・レシーバ・メッセージ６２５を送信するのに応答して、接続マネージャは、フロー・アップデート・メッセージ６３３もミラーリング・ノードへ送信する。このフロー・アップデート・メッセージ６３３は、レシーバ・ノードのターゲット・レシーバのフロー状態（の情報）を含んでいる。ミラーリング・ノードは、アップデートされたセンダー（ここでは、センダー２）からアップデートされたフロー６３７を受けて、そして、アップデートされたフロー情報に関する通知メッセージ６３９をレジストリへ送信する。なお、レシーバが新しいフローに切り替わるときはいつも、フロー関係を維持するために、接続マネージャもミラーリング・ノードをアップデートすることに注意されたい。また、例えば、ミラーリング関係が接続マネージャにセットアップされる場合では、ミラーリング・ノードがミラーリング関係を認識している必要はないことにも注意されたい。このような場合、ミラーリング・ノードが知っているのは、新しいフロー状態の情報が、接続マネージャから適時送信されてくることだけである。

【0054】

本発明の実施例は、特別に作成されたハードウェア、ファームウェア、デジタル・シグナル・プロセッサ又はプログラムされた命令に従って動作するプロセッサを含む特別にプログラムされた汎用コンピュータ上で動作できる。本願における「コントローラ」又は「プロセッサ」という用語は、マイクロプロセッサ、マイクロコンピュータ、ＡＳＩＣ及び専用ハードウェア・コントローラ等を意図する。本発明の態様は、１つ又は複数のコンピュータ（モニタリング・モジュールを含む）その他のデバイスによって実行される、１つ又は複数のプログラム・モジュールなどのコンピュータ利用可能なデータ及びコンピュータ実行可能な命令で実現できる。一般に、プログラム・モジュールとしては、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含み、これらは、コンピュータその他のデバイス内のプロセッサによって実行されると、特定のタスクを実行するか、又は、特定の抽象データ形式を実現する。コンピュータ実行可能命令は、ハードディスク、光ディスク、リムーバブル記憶媒体、ソリッド・ステート・メモリ、ＲＡＭなどのコンピュータ可読記憶媒体に記憶しても良い。当業者には理解されるように、プログラム・モジュールの機能は、様々な実施例において必要に応じて組み合わせられるか又は分散されても良い。更に、こうした機能は、集積回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）などのようなファームウェア又はハードウェア同等物において全体又は一部を具体化できる。特定のデータ構造を使用して、本発明の１つ以上の態様をより効果的に実施することができ、そのようなデータ構造は、本願に記載されたコンピュータ実行可能命令及びコンピュータ使用可能データの範囲内と考えられる。

【0055】

本願発明の態様は、様々な変更及び代替形態で動作する。特定の態様は、図面に例として示されており、詳細に説明した。しかしながら、本願に開示された実施例は、説明を明確にする目的で提示されており、明示的に限定されない限り、開示される一般的概念の範囲を本願に記載の具体例に限定することを意図していない。このように、本開示は、添付の図面及び特許請求の範囲に照らして、記載された態様のすべての変更、均等物及び代替物をカバーすることを意図している。

【0056】

明細書における実施形態、態様、実施例などへの言及は、記載された項目が特定の特徴、構造又は特性を含み得ることを示す。しかしながら、開示される各態様は、そうした特定の特徴、構造又は特性を含んでいても良いし、必ずしも含んでいなくても良い。更に、このような言い回しは、特に明記しない限り、必ずしも同じ態様を指しているとは限らない。更に、特定の態様に関連して特定の特徴、構造又は特性が記載されている場合、そのような特徴、構造又は特性は、そのような特徴が他の開示された態様と明示的に関連して記載されているか否かに関わらず、そうした他の開示された態様と関連して使用しても良い。

【0057】

開示された態様は、場合によっては、ハードウェア、ファームウェア、ソフトウェア又はそれらの任意の組み合わせで実現されても良い。開示された態様は、１つ以上のプロセッサによって読み取られ、実行され得る１つ又は複数のコンピュータ可読媒体によって運搬されるか又は記憶される命令として実現されても良い。そのような命令は、コンピュータ・プログラム・プロダクトと呼ぶことができる。本願で説明するコンピュータ可読媒体は、コンピューティング装置によってアクセス可能な任意の媒体を意味する。限定するものではないが、一例としては、コンピュータ可読媒体は、コンピュータ記憶媒体及び通信媒体を含むことができる。

【0058】

コンピュータ記憶媒体は、コンピュータ読み取り可能な情報を記憶するために使用することができる任意の媒体を意味する。限定するものではないが、例としては、コンピュータ記憶媒体としては、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電気消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリやその他のメモリ技術、コンパクト・ディスク読み出し専用メモリ（ＣＤ-ＲＯＭ）、ＤＶＤ（Digital Versatile Disc）やその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置やその他の磁気記憶装置、及び任意の技術で実装された任意の他の揮発性又は不揮発性の取り外し可能又は取り外し不能の媒体を含んでいても良い。コンピュータ記憶媒体としては、信号そのもの及び信号伝送の一時的な形態は排除される。

【0059】

通信媒体は、コンピュータ可読情報の通信に利用できる任意の媒体を意味する。限定するものではないが、例としては、通信媒体には、電気、光、無線周波数（ＲＦ）、赤外線、音又はその他の形式の信号の通信に適した同軸ケーブル、光ファイバ・ケーブル、空気又は任意の他の媒体を含むことができる。

【0060】

開示された主題の上述のバージョンは、記述したか又は当業者には明らかであろう多くの効果を有する。それでも、開示された装置、システム又は方法のすべてのバージョンにおいて、これらの効果又は特徴のすべてが要求されるわけではない。

【0061】

加えて、本願の記述は、特定の特徴に言及している。本明細書における開示には、これらの特定の特徴の全ての可能な組み合わせが含まれると理解すべきである。ある特定の特徴が特定の態様又は実施例の状況において開示される場合、その特徴は、可能である限り、他の態様及び実施例の状況においても利用できる。

【0062】

また、本願において、２つ以上の定義されたステップ又は工程を有する方法に言及する場合、これら定義されたステップ又は工程は、状況的にそれらの可能性を排除しない限り、任意の順序で又は同時に実行しても良い。

【0063】

説明の都合上、本発明の具体的な実施例を図示し、説明してきたが、本発明の要旨と範囲から離れることなく、種々の変更が可能なことが理解できよう。従って、本発明は、添付の特許請求の範囲を除いて限定されるべきではない。

【符号の説明】

【0064】

１００ メディア制作システム
１１０ データ・センタ・ネットワーク
１１２ サーバ
１１４ 登録及び発見システム
１２０ 登録及び発見インスタンス
１２３ 照会サービス
１２５ 登録サービス
１３１ ノード
１３２ ノード
１３３ ノード
１３５ レシーバ
１３６ センダー
１３７ ノードＡＰＩ
１３８ デバイス
１４０ フロー
１４２ ミラーリング関係

【図1A】

【図1B】

【図1C】

【図2】

【図3】

【図4】

【図5】

【図6】