JP2017531972A - グラフモデリングを用いて放送システムおよびマルチメディアシステムを管理し、モニタし、制御するためのシステムおよび方法 - Google Patents

Abstract

本開示では、放送環境の動的なグラフベースのモデリングおよび解析システムのためのシステムならびに方法について説明する。グラフモデルは、リレーショナルデータベースと異なり、ノード間の関係についてインデックスフリーの隣接性を提供し、大量の、変動性の高い、半構造化された、高密度のデータに理想的である。特に、他のグラフベースのモデリングシステムと異なり、本願で論じるシステムおよび方法は、配信元から処理および経路指定を経て配信先に至る、構成要素間のグラフモデルを通る信号フローを認識するモデリングシステムを提供する。同時に、本システムは、信号種別および信号フォーマットを認識し、相互接続規則を実施することができる。また本システムは、放送環境全体にわたる複数のルータの動的でフレームアキュレートな制御を提供するようにリアルタイムで動作することもできる。

Description

関連出願
本出願は、参照によりその全体が本明細書に組み入れられる、2014年8月22日付で出願された、「Systems and Methods for Using Graph Modeling to Manage, Monitor, and Control Broadcast and Multimedia Systems」という名称の米国仮特許出願第62/040,786号の恩典および優先権を主張するものである。

分野
本出願は放送環境管理のためのシステムおよび方法に関する。一局面において、本出願は、放送環境のための動的なグラフベースのモデリング、解析、モニタリング、および制御のシステムを対象とする。

背景
テレビやラジオのスタジオ、関連制作環境といった典型的な放送環境は、何百もの個別メディアの配信元および配信先ならびに何千もの潜在的信号経路を含む場合がある。例えば、小規模なテレビ・ニュース・スタジオは、各々がカメラオペレータのヘッドセットとの間で高品位および標準品位のビデオ出力フィード、リターン・ビデオ・モニタ・フィード、ならびにオーディオフィードを送る3台のカメラ;スタジオ内のモニタおよびテレプロンプタ;数台のラペルマイクおよび/またはブームマイク;キューを出すための、またはプロデューサからアンカへの通信のためのインイヤー式オーディオモニタ;事前記録部分のためのオーディオビデオ再生システム;ロケーション中またはライブのリモートフィードのためのリモート通信システム;オーディオ・ミキシング・コンソール;ビデオスイッチャおよびルータ;衛星上りリンク送信機;地上波送信機;あるいは他の多くのそうしたデバイス、および文字通り何マイルにも及ぶ配線を含む場合がある。スタジオの規模が拡大するに従って、デバイスおよび相互接続の数は指数関数的に増加することになりうる。

放送環境を設計し、維持するには、各デバイス間の信号経路を綿密に理解することが必要である。その結果、技術者らは通常、各物理相互接続;配信元別、配信先別、種別、長さ別などでシステム内の各配線を識別する配線リスト;および典型的なセットアップ（例えば、ライブスタジオ内放送;1箇所のリモートサイトを伴う放送;2箇所のリモートサイトを伴う放送;事前に記録されたインタビューなど）を示す複数の信号フロー図を示すために大規模な系統図を作成することになる。これらの系統図は複雑で非直感的であり、特に構成要素をアップグレードまたは交換する際に作成、維持することが難しく、高くつき、トラブルシューティングや新しいシステム構成の作成には使えない場合もある。

概要
本開示では、放送環境の動的なグラフベースのモデリング解析システムのためのシステムおよび方法について説明する。グラフモデルは、リレーショナルデータベースと異なり、ノード間の関係についてインデックスフリーの隣接性を提供し、大量の、変動性の高い、半構造化された、高密度のデータに理想的である。特に、他のグラフベースのモデリングシステムと異なり、本明細書で論じるシステムおよび方法は、配信元（例えば、カメラ、マイクロフォン、デジタル再生システム、衛星受信機など）から処理および経路指定を経て配信先（例えば、記録デバイス、送信機、ネットワーク接続など）に至る、構成要素間のグラフモデルを通る信号フローを認識するモデリングシステムを提供する。さらに、本システムは信号種別および信号フォーマットを認識し、相互接続規則（例えば、HDビデオ出力はHDビデオ入力に接続する、ステレオオーディオ出力はステレオオーディオ入力に接続する、フィードバックループ除去など）を実施することができる。また本システムは、リアルタイムで動作して、放送環境全体にわたる複数のルータの動的でフレームアキュレートな制御を提供することもできる。

一局面において、本開示はグラフベースのモデルによって放送リソースを管理する方法を対象とする。本方法は、放送環境の管理システムが複数の放送リソースの各々の特性を特定する工程を含み、特性は少なくとも1つの入力または出力を含む。本方法は、管理システムが、特定された特性に基づいて複数の放送リソースのグラフベースのモデルを生成する工程も含む。本方法は、管理システムが、複数の放送リソースの第1の放送リソースから複数のリソースの第2の放送リソースまで信号を経路指定するよう求める要求を受信する工程をさらに含む。本方法は、管理システムが、複数の放送リソースの各々の特定された特性に基づいて、少なくとも1つのさらに別の放送リソースを経由する第1の放送リソースから第2の放送リソースまでの経路を選択する工程;ならびに管理システムが、第1の放送リソース、第2の放送リソース、および少なくとも1つのさらに別の放送リソースに、選択された経路に沿って信号を送受信するよう命じる工程も含む。

いくつかの実施態様において、特性は少なくとも1つの入力信号種別および少なくとも1つの出力信号種別をさらに含む。別の実施態様において、第1の放送リソースは第1の信号種別を有し、第2の放送リソースは第2の信号種別を有し、第1の放送リソースから第2の放送リソースまでの経路を選択する工程は、第1の信号種別の入力信号種別および第2の信号種別の出力信号種別を有する第3の放送リソースを経由する経路を選択する工程をさらに含む。

別の実施態様において、第1の放送リソースから第2の放送リソースまでの経路を選択する工程は、グラフベースのモデルによって最短経路を特定する工程をさらに含む。別の実施態様において、本方法は、各ノードが放送リソースを表すグラフの最も少数の仲介ノードを経由する第1の放送リソースから第2の放送リソースまでの経路を特定する工程を含む。さらに別の実施態様において、本方法は、最低合計待ち時間を有する第1の放送リソースから第2の放送リソースまでの経路を特定する工程であって、グラフの各放送リソースは関連付けられた処理待ち時間を有する、工程を含む。

さらに別の実施態様において、第1の放送リソースから第2の放送リソースまでの選択された経路は第3の放送リソースを経由するものであり、本方法は、管理システムが、第4の放送リソースから第5の放送リソースまで信号を経路指定するよう求める要求を受信する工程;管理システムが、第3の放送リソースを経由する第4の放送リソースから第5の放送リソースまでの経路を選択する工程;管理システムが、第3の放送リソースは第1の放送リソースと第2の放送リソースとの間の経路と第4の放送リソースと第5の放送リソースとの間の経路とを同時に搬送することができないと決定する工程;管理システムが、第6の放送リソースを経由する第1の放送リソースから第2の放送リソースまでの第2の経路を選択する工程、ならびに第1の放送リソース、第2の放送リソース、および第6の放送リソースに、第2の経路に沿って信号を送受信するよう命じる工程を含む。別の実施態様において、本方法は、第3の放送リソースを経由する第1の放送リソースから第2の放送リソースまでの経路の第1のコストを特定する工程;第3の放送リソースを経由する第4の放送リソースから第5の放送リソースまでの経路の第2のコストを特定する工程;第1のコストは第2のコストを超えると決定する工程;および第1のコストは第2のコストを超えるという決定に応じて第2の経路を選択する工程を含む。さらに別の実施態様において、本方法は、第6の放送リソースを経由する第1の放送リソースから第2の放送リソースまでの経路の第3のコストを特定する工程;第7の放送リソースを経由する第4の放送リソースから第5の放送リソースまでの経路の第4のコストを特定する工程;第3のコストは第4のコストより小さいと決定する工程、および第3のコストは第4のコストより小さいという決定に応じて第2の経路を選択する工程を含む。さらに別の実施態様において、本方法は、第3のコストと第1のコストとの差が第4のコストと第2のコストとの差より小さいと決定する工程、および第3のコストと第1のコストとの差は第4のコストと第2のコストとの差より小さいという決定に応じて第2の経路を選択する工程を含む。さらに別の実施態様において、第3の放送リソースを経由する第1の放送リソースから第2の放送リソースまでの経路の第1のコストを特定する工程は、経路の全長、経路の合計待ち時間、経路がトラバースするリソースの数、経路がトラバースする重複しないリソースの数、または利用可能な代替経路の数を特定する工程をさらに含む。

別の局面において、本開示はグラフベースのモデルによって放送リソースを管理するためのシステムを対象とする。本システムは、本システムのネットワークインターフェースを介して複数の放送リソースのうちの少なくとも1つと通信する管理エージェントを実行するプロセッサを含む。管理エージェントは、少なくとも1つの入力または出力を含む、複数の放送リソースの各々の特性を特定し、特定された特性に基づいて複数の放送リソースのグラフベースのモデルを生成するように構成されている。管理エージェントはさらに、複数の放送リソースの第1の放送リソースから複数のリソースの第2の放送リソースまで信号を経路指定するよう求める要求を受信するように構成されている。管理エージェントはさらに、複数の放送リソースの各々の特定された特性に基づいて、少なくとも1つのさらに別の放送リソースを経由する第1の放送リソースから第2の放送リソースまでの経路を選択し、第1の放送リソース、第2の放送リソース、および少なくとも1つのさらに別の放送リソースに、選択された経路に沿って信号を送受信するよう命じるように構成されている。

いくつかの実施態様において、特性は入力信号種別および出力信号種別を識別し、第1の放送リソースは第1の信号種別を有し、第2の放送リソースは第2の信号種別を有し、管理エージェントは、第1の信号種別の入力信号種別および第2の信号種別の出力信号種別を有する第3の放送リソースを経由する経路を選択するようにさらに構成されている。別の実施態様において、管理エージェントは、グラフベースのモデルによって最短経路を特定し、最短経路を第1の放送リソースから第2の放送リソースまでの経路として選択するようにさらに構成されている。別の実施態様において、管理エージェントは、各ノードが放送リソースを表すグラフの最も少数の仲介ノードを経由する、または最低待ち時間を有する第1の放送リソースから第2の放送リソースまでの経路を特定するようにさらに構成されている。

いくつかの実施態様において、第1の放送リソースから第2の放送リソースまでの選択された経路は第3の放送リソースを経由するものであり、管理エージェントは、第3の放送リソースをさらに別の放送リソース間の第3の経路に用いるという決定に応じて第4の放送リソースを経由する第1の放送リソースから第2の放送リソースまでの第2の経路を選択し、第1の放送リソース、第2の放送リソース、および第4の放送リソースに、第2の経路に沿って信号を送受信するよう命じるようにさらに構成されている。別の実施態様において、管理エージェントは、第3の放送リソースを経由する第1の放送リソースから第2の放送リソースまでの経路の第1のコストを特定し、第1のコストが第3の経路のコストを超えることに応じて第2の経路を選択するようにさらに構成されている。さらに別の実施態様において、管理エージェントは、第1の放送リソースおよび第2の放送リソースが第3の放送リソースのすべての機能に満たないことに応じて第1のコストを増やすようにさらに構成されている。さらに別の実施態様において、管理エージェントは、経路の全長または経路の合計待ち時間に基づいて第1のコストを特定するようにさらに構成されている。さらに別の実施態様において、管理エージェントは、経路がトラバースするリソースの数、経路がトラバースする重複しないリソースの数、または利用可能な代替経路の数に基づいて第1のコストを特定するようにさらに構成されている。

放送環境のためのテンプレートの例示的態様のグラフである。 前記テンプレートを用いた環境の例示的態様のグラフである。 放送環境のためのテンプレートの例示的態様の別のグラフである。 放送環境のためのグラフベースのモデルの例示的態様のスキーマ図である。 放送環境のためのグラフベースのモデルを生成し、解析し、維持するための例示的システムのブロック図である。 グラフ編集インターフェースの例示的スクリーンショットの左半分である。 グラフ編集インターフェースの例示的スクリーンショットの右半分である。 リアルタイムビューのグラフ編集インターフェースの別の例示的スクリーンショットの左半分である。 リアルタイムビューのグラフ編集インターフェースの別の例示的スクリーンショットの右半分である。 グラフモデリングを用いて放送環境を管理し、モニタし、制御する方法の実施態様の流れ図である。 グラフモデリングを用いて放送環境を管理し、モニタし、制御する方法の実施態様の流れ図である。 本明細書に記載される方法およびシステムを実施するのに有用な例示的コンピューティングデバイスのブロック図である。

図面において、類似した符番は一般に、同一要素、機能的に類似した要素、および/または構造的に類似した要素を示す。

詳細な説明
以下の説明では上記の図面と併せて、例示を目的とした様々な態様について説明するが、これらの態様はいかなる点においても記載の方法またはシステムの範囲を限定するためのものではない。当業者は、記載の方法またはシステムの最も広い範囲を超えずに、様々なやり方で記載の方法およびシステムを変更することができる。よって、本明細書に記載される方法またはシステムの範囲は例示的態様のいずれによっても限定されるべきものでなく、添付の特許請求の範囲およびその均等物に従って定義されるべきものである。

本開示では、放送環境の動的なグラフベースのモデリング解析システムのためのシステムおよび方法について説明し、配信元（例えば、カメラ、マイクロフォン、デジタル再生システム、衛星受信機など）から処理および経路指定を経て配信先（例えば、記録デバイス、送信機、ネットワーク接続など）に至る、構成要素間のグラフモデルを通る信号フローを認識するモデリングシステムについて説明する。同時に、本システムは信号種別および信号フォーマットを認識し、相互接続規則（例えば、HDビデオ出力はHDビデオ入力に接続する、ステレオオーディオ出力はステレオオーディオ入力に接続する、フィードバックループ除去など）を実施することができる。また本システムは、放送環境全体にわたる複数のルータの動的でフレームアキュレートな制御を提供するように、リアルタイムで動作することもできる。

グラフモデルは柔軟性を提供する。というのは、頂点およびエッジが複数のキー・値対およびドキュメントを持つことができるからである。頂点およびエッジは、オブジェクトモデリングを用いて、オブジェクト指向モデリングの継承、制約条件、再利用可能性、サブクラス化、利便性その他の利点をサポートすることもできるいくつかの実施態様において、グラフモデルは、NoSQLデータベースシステム、リレーショナルデータベース管理システム、グラフ・データベース・システム、または任意の他の種類もしくは形態のデータベースシステムによって生成することができる。データベースシステムはオブジェクト、クラス、ならびにクラスおよび/またはオブジェクトのクラスタを識別することができる。

グラフはシステムによってリアルタイムの柔軟な問合せを用いて分析され、問合せには以下が含まれる。
・配信元Aと配信先Bとの間の最短の最も安価な経路はどれか？
・720p60フォーマットの配信元信号を1080i30配信先に切り替えるにはどんな経路を用いるべきか？
・ハイブリッドルータを用いて複数のビデオ信号にわたって16トラックのオーディオの再編成を行うにはリソースをどのように用いるか？
・1秒未満で5台のルータを伴うマルチホップタイライン取得をどのように行うか？
・最も多用され、混んでいる経路はどれか？
・信号経路において自動予測可能制御を行うための複雑なビジネスルールを作成することができるか？
・この故障の根本原因は何か？
・システムにおける関連した警報はどれであり、解決に際してどの警告に注目すべきか？
・システムにおいてこのデバイスを除いた場合に何が起こるか？
・新しいHDチャネルの追加をサポートするために何をする必要があるか？
・2週間前に広告の放送に失敗したときの信号経路および全デバイスの状況はどうであったか？
したがって、グラフモデルの実施態様により、高度なグラフ解析を行い、履歴データに関する詳細な報告およびメトリックを作成する他の多くの可能性が切り開かれる。

いくつかの実施態様において、グラフモデルは、1つまたは複数のエッジEによって接続された1つまたは複数の頂点Vを含むことができる。各頂点VおよびエッジEは、拡張可能に定義される1つまたは複数のキープロパティまたはパラメータ・値対を含むことができる。以下でより詳細に論じるように、グラフモデルは、専用アプリケーション、ウェブブラウザ、または他のそうしたアプリケーションによって提供されるインターフェースと共にアプリケーションレベルでモデル化され、用いられる。したがって、グラフモデルは、リレーショナルデータを関係と共にオブジェクトにマップするための複雑な追加層を必要とせず、非常に迅速に策定し、維持管理を減らすことが可能になる。

モデルは拡張することもでき、コードを変更せずにモデルに新しいオブジェクトを含めることができる。例えば、オブジェクトごとの詳細なレコードを作成しなくても、ポートおよび信号種別を識別する既存のテンプレートを用いて容易にモデルに新しい製品およびデバイスを追加することができる。いくつかの実施態様において、グラフモデルは必要に応じて動的にロードされてよく、限られたシステム上でさえも、メモリ効率のよい迅速なアクセスが提供され、あるいは大規模なデータベースを用いる場合でさえも、効率のよい問合せのための粒度が提供される。

多くの実施態様において、グラフモデルは、システムの静的状態を表し、ユーザまたは技術者によって単一の頂点から複数の頂点およびエッジ相互接続を含むデバイス全体まで様々なサイズのテンプレートを用いて生成されてよい。いくつかの実施態様において、テンプレートは、典型的な信号経路（例えば、マイクロフォンから前置増幅器、信号プロセッサを経てアナログ/デジタル変換器まで、各々が少なくとも入力および出力のための頂点を含み、各デバイス内およびデバイス間のエッジ相互接続を伴う）ではさらに大きい場合がある。グラフの各インスタンスは経時的な、または信号が放送環境を流れる際の変化を示すこともでき、したがってモデルは多次元を有していてよい。

まず図1Aを見ると、典型的な小規模放送環境の例示的テンプレートのグラフが示されている。自由形態フォーマットで示されているが、いくつかの実施態様において、アプリケーションまたはビューアは直交フォーマットまたは放射型フォーマットでグラフを表示することができる。各ノード102およびエッジ104のカスタムプロパティは、明確にするためにグラフには示されていないが、各ノード102およびエッジ104にリンクされていてよく、そうしたカスタムプロパティは、単なる値、キー・値対もしくはパラメータ・値対、英数字文字列、所定の種別もしくは範囲、ドキュメントもしくは埋め込みドキュメント、または任意の他の型およびフォーマットのデータ、およびリスト、マップ、コレクションなどといった複雑なデータ型を含む多種のレコードを含んでいてよい。ノード102はサブクラスにグループ化されてもよい。例えば、カメラ、プロセッサ、ルータ、およびサーバはすべてクラス「デバイス」の一部として識別され、すべての「デバイス」に共通したプロパティ（例えば、少なくとも1つのポート頂点を含むなど）を継承する。別の例では、スタジオ頂点102dはクラス「エリア」の一部として識別され、したがって、少なくとも1つのデバイス頂点（例えば、「カメラテンプレート」、「コントローラテンプレート」、「プロセッサテンプレート」102bなど）を含む。同様に、エッジ104も、信号種別やフォーマット104d（標準品位ビデオ、720p60ビデオ、1080i50ビデオなど）のためのクラス、相互接続種別（例えば、銅線によるアナログオーディオ、オーディオ技術学会（Audio Engineering Society（AES））フォーマットのオーディオといった銅線によるデジタルオーディオ、ファイバによるデジタルビデオ、シリアル・デジタル・インターフェース（Serial Digital Interface（SDI））相互接続、インターネットプロトコル（IP）もしくは他のパケット化接続、または後述するような、任意の他の種別および形態の相互接続）のためのクラス、または任意の他のそうしたクラスのようなクラスへグループ化されてよい。いくつかの態様において、クラスおよびプロパティの継承は複数レベルを有する階層型とすることができる。

さらに図1Aをより詳細に見ると、ノードはグラフ100全体において再利用されてよく、ノードには一意の識別子を割り当てることができる。例えば、各デバイス（例えば、カメラ、プロセッサ、ルータ、サーバなど）はエッジ（例えば「接続」エッジ104b）を経由してポートテンプレート102cに接続する。したがって図示のように、グラフ100は複数のポートテンプレート102cおよび対応する接続エッジ102cを含むことができる。前述のように、デバイスはグループ102aに属することができる。いくつかの実施態様においては、グループはグラフ内のエリアとして描かれ、別の実施態様においては、図示のように、グループは、「属する」エッジ104aを介して接続されることによってデバイスが属する先のノード（例えばグループテンプレート102a）を含む。同様に、デバイスは所有権エッジ104cを介して接続されることによってエリア（例えばスタジオノード102d）に属することもできる。エリアはリソースのためのコンテナを含み、多くの場合は物理的位置のためであるが、機能性、所有権または論理編成のためにも、密接に関連しているものをまとめてグループ化することができる。エリアはコントローラグループによって管理されてよく、これは、エリア内のすべてのリソースが密接に協調するコントローラの単一のクラスタによって管理されることを意味する。

リソースはエリアによって管理されるエンティティを含むことができる。リソースはデバイス、ユーザ、およびデバイスグラフを含むことができる。例えば、図1Cを簡単に見ると、グループによるエンティティの管理を例示するグラフ100''の別の例が示されている。図示の例では、エリアBはユーザと、デバイスグラフB1およびデバイスグラフB2と、すべてのデバイスグループおよびそれらのグラフが参照するデバイスとを所有している。デバイスグラフB1およびB2やデバイスグラフA1〜A3といったデバイス・グラフ・オブジェクト120は、システムによって定義された構成を表し、デバイスグループ122およびデバイスグループ122の相互接続を含み、デバイスグループ122は、図1A〜図1Bに示すように、デバイスインスタンス124、デバイスインスタンス124の入力物理ポートおよび出力物理ポート、ならびにデバイスインスタンス124の相互接続を含む。デバイスはデバイスグループ122としてグループ化されていてよく、デバイスグループ122は1つまたは複数のデバイス124を含むことができる。同様に、コントローラグループ126も1つまたは複数のコントローラ（例えば、物理サーバまたは仮想サーバ、システムコントローラ、自動化システムなど）のグループを含むことができる。いくつかの実施態様において、デバイスグループ内のデバイスおよび/またはコントローラグループ内のコントローラは負荷分散され、または冗長性を提供できなかった場合のホットバックアップとして用いられてよい。

共用デバイス128は信号を下流側エリアに供与するのに用いられる擬似デバイスまたは仮想デバイスを含むことができる。共用テンプレートは、単一の共用「デバイス」128を含むデバイスグループ122を作成するのに用いることができるデバイステンプレートとすることができる。共用デバイスグループにはデバイスグラフ内のデバイスグループ122からの出力を接続することができ、共用デバイスグループはデバイスグラフ内の入力を含むことができる。そうした各接続は他のエリアで利用可能になるインポートテンプレートをもたす。

同様に、インポータ130は上流側エリアから信号を受信するのに用いられる擬似デバイスまたは仮想デバイスである。インポータ130はインポートテンプレートによって作成されてよく、2つの基本情報要素、すなわち、インポータ130がインポートする上流側デバイスグループ、およびインポータ130が上流側デバイスグループをインポートするための共用体128を保持することができる。あるエリア内のインポートテンプレートは他のエリアにおいて共用されたことのあるデバイスグループ122を示す。インポートテンプレートはインポータインスタンス130を作成するためにデバイスグラフにドロップすることができる。インポートテンプレートは2つの基本情報要素、すなわち、共用オブジェクト128および共用されたデバイスグループを含んでいてよい（というのは複数のデバイスグループを1つの共用体に接続することができ、結果として複数のインポートテンプレートが生じるからである）。図1Cに示す例示的態様においては、共用デバイス128は2つのインポートテンプレートを生じる。というのは、共用デバイス128は2つの上流側デバイスグループ122、「ルータ」デバイスグループおよび「プロセッサ」デバイスグループにリンクしているからである。

図1Cに示すように、多くの実施態様において、各エリアは「ライブ」グラフ132として定義された1つのデバイスグラフを有していてよい。ライブグラフは、そのエリアのコントローラグループが現在実施している、または様々なスイッチャおよびルータを制御することによって実現している構成を含むことができる。デバイスは、それらが現在ライブであるデバイスグラフによって参照されている場合にライブであるとみなされる。

ワーキングセット134は、現在のライブ構成、オフライン構成、作業コピー、バージョン管理コピー、またはそれらの組み合わせとすることのできる可能なシステム構成を表す。ワーキングセット134は1つまたは複数のデバイスグラフを含み、現在のエリアグラフ内のエリアごとに1つのデバイスグラフを含む。ワーキングセット134は、1つまたは複数のデバイスグラフへの明示的な直接リンクと、指定されていないデバイスグラフについての現在ライブ132のデバイスグラフとの組み合わせを含むリストまたはデータテーブルを含むことができる。ワーキングセット134は、ワーキングセット134が定義する可能なシステム構成の妥当性および整合性を評価するためのコンテキストを提供する。いくつかの実施態様において、ワーキングセット134は、グラフ配置の仮想経路指定変更および解析を可能にすることによって、ある特定のレベルの「もし〜だったらどうなるか」シナリオの評価を可能にすることができる。いくつかの実施態様において、ワーキングセット134は、後で呼び戻すために記憶ライブラリに名前で保存されてよく、番組136と呼ぶことができる。番組136は、典型的なワーキングセット134とは異なり、特定のユーザと関連付けられておらず、呼び戻しに応じてどんなユーザからもアクセスすることができる。呼び戻し時には、まだライブ132ではない明示的デバイス・グラフ・リンクがあればそれらはライブ132になり、指定されていないデバイスグラフを有する残りのエリアはそのままにしてよい。番組136構成は、番組がライブになるときに適用され、またはトリガされる必要のある様々な設定および動作も含むことができる（例えば、「このプロセッサ上でユーザプロファイル＃2を呼び戻す」、「ルータサルボ＃1をアクティブ化する」、「マルチビューア上でレイアウトAをロードする」など）。番組136自体がワーキングセット134であるため、切り替えまたはコマンドを実際にトリガする直前に番組をライブセットとして実施する影響を解析することを含めて、番組の構成の整合性をいつでも評価することが可能である。

いくつかの実施態様において、管理者は、コントローラグループ、1つまたは複数のエリア、およびユーザを含むエリアグラフを選択することによって、図1Cに示すグラフのようなグラフを作成することができる。管理者は次いで、いくつかの相互接続されたデバイスグループ（例えば、図示のように、2台のカメラ、1台のルータ、3台のプロセッサ）を追加することによって、デバイスグラフ（例えばエリアAのデバイスグラフA1）を編集することができる。管理者は共用デバイスグループを追加してよく、共用デバイスグループは共用デバイス128を自動的に作成する。管理者は共用グループをルータ・デバイス・グループおよびプロセッサ・デバイス・グループに接続することができる。これによりシステムは、エリアAからのルータとエリアB内のエリアAからのプロセッサとの2つの対応するインポートテンプレートを自動的に作成する。管理者はエリアBに切り替え、スイッチャ・デバイス・グループを追加するようにデバイスグラフ（例えば、デバイスグラフB2）を編集することができる。管理者は次いで、インポートテンプレートを用いてエリアAからエリアBにプロセッサを追加し、システムに、インポータ・デバイス・インスタンス130を作成させることができる。エリアBからのスイッチャは次いで、エリアAデバイスグループからのプロセッサに接続することができる。

いくつかの実施態様において、信号を共用する異なるエリアは異なるコントローラによって管理される。したがって、他のエリアからのインポートテンプレートの使用を可能にするために、インポータ・デバイス・インスタンス130からのリンクは、トポロジ内の局所エッジではなくリモートリンクとして扱われる。

図1Aに戻って、図示のように、グラフ100は、配信元から配信先までの信号フローの潜在的経路を示すことができる。配信元と配信先とはどちらもデバイスであってよく、したがってノードであってよい（例えば、「である（is）」エッジによって配信元テンプレート102eノードに接続された「カメラテンプレート」ノード102gや、「である（is）」エッジによって配信先テンプレート102fに接続された「サーバテンプレート」ノード102h）。ユーザは、配信元ノードから配信先ノードまでの信号フローを直感的にたどることができ、システムは最短経路を動的に特定し、故障したデバイスを迂回し、所有権、フォーマット種別、接続種別などといったデバイス間の共通プロパティを特定し、または任意の他のそうした機能を果たすことができる。

グラフ内の各テンプレートノードは、デバイス、ポート、配信元、配信先、信号プロセッサ、メディア配信元、ユーザまたはオペレータ、物理エリアまたは仮想エリア、あるいは任意の他の種類および形態のデバイスといったエンティティ種別を表すことができる。これらのテンプレートは、放送環境の論理インフラストラクチャまたは物理インフラストラクチャを表すエンド・ツー・エンド経路テンプレートを作成するために組み合わせることができる。論理構造内のエンティティをグループ化し、タグ付けし、編成するためにグラフに他のデータ構造、テンプレート、およびプロパティが追加されてよい。例えば、タグオブジェクトは、グラフを容易に探索できるようにユーザまたは管理者によって作成されたメタデータを含み、エンティティオブジェクトにリンクされる。

ノードからノードまでの信号フローは様々な種類の相互接続を介したものであってよく、それらの相互接続には、米国映画テレビ技術者協会（Society of Motion Picture and Television Engineers（SMPTE））が発行した259M規格やSMPTE 372Mデュアルリンク相互接続フォーマット、あるいは任意の他の種類のシリアルフォーマットまたはパラレルフォーマットといった、SDI相互接続が含まれる。そうしたフォーマットは、オーディオおよび/またはビデオに加えて、補助データを含んでいてよい。別の実施態様においては、信号フローは、ツイストペアケーブル（例えば1000BASETイーサネット）、光ファイバ、あるいは任意の他の種類および形態の物理相互接続を介したIPデータといった、パケット化プロトコルによるものであってよい。いくつかのそうした実施態様において、スイッチまたはルータはグラフ内のノードとして含まれており、別の実施態様において、スイッチまたはルータは信号フローベースのグラフモデルとは別個の物理層の一部とみなされる。そうした種類の相互接続はシステムに動的な経路指定変更機能を提供することができ、広域ネットワーク上の仮想私設網を介してリモート相互接続を提供するといったこともできる。

図1Bは、特定のデバイスおよびノードが識別されている、図1Aのシステムの一例を表す例示的グラフ100'の図である。図示のように、カメラ102gは「ニュースHD」クラス102eのメンバとすることができ（「である（is）」エッジ接続によって示されている）、したがって、カメラ（CAM）デバイスクラスに属すること、ユーザまたは「オペレータ」によって操作されること、ならびに様々なオーディオおよびビデオのフォーマットおよびレベル102f、102f'を継承することを含めて、クラス102eのすべてのプロパティを継承することができる。同様に、カメラ102gは「スタジオカメラ」グループ102aに属することもできる（「属する」エッジ接続104aによって示されている）。カメラ102gは内部ポート102cに接続し、より多くは内部ポート102c備えることができ、内部ポート102cはスタジオ・プロセッサ・グループに属するプロセッサに接続されていてよい。プロセッサの出力ポート102cはコアルータに接続されていてよく、コアルータ自体はニュースサーバ102hのポート102cに接続することができ、ニュースサーバ102hのポート102cは高品位（HD）5.1配信先102fと標準品位（SD）ステレオ配信先の両方であってよい。図示されていない他の配信元および配信先には、サーバ、ワークステーション、デスクトップ機、またはブレードサーバのようなモジュラシステムや、カード上のシャーシもしくはフレーム取り付け式システム、カードベースのプレイアウトデバイス、または任意の他の種類および形態の配信元もしくは配信先が含まれうる。多くの実施態様において、グラフ100、100'の各インスタンスは単一の配信元（例えば、配信元テンプレート102eに接続されたカメラ1 102g）を有し、1つまたは複数の配信先を有する。信号フローは配信元から配信先までグラフを横切る流れとして迅速に可視化されうる。

したがって、グラフ100'によれば、グラフをトラバースすることによって、「CAM1のオペレータは誰か」、「HD5.1をサポートしており、ファイバ接続を有する、スタジオに属するすべてのカメラはどれか」などといった、複雑な解析を迅速に行うことができる。問合せはネストされてよく、ある問合せの結果が次の問合せへの入力として用いられる。

図2は、グラフベースのモデル内のノードおよびエッジ接続を示すスキーマ図200である。図示のように、第1の頂点202は論理的配信元または配信先（例えば、カメラまたはプレイアウトサーバや、記録サーバ、送信機、上りリンクなど）を含むことができる。配信元または配信先頂点202は、一意の識別子、名前、記述、またはエイリアスのうちの1つまたは複数の値を含み、またはそれらの値と関連付けることができる。頂点202は、頂点が配信元かそれとも配信先を指示するためのフラグ、ストリング、または他の所定の値を含むことができる。

図示のように、頂点202は対応する1つまたは複数のエッジ204a〜204nを介して1つまたは複数の他の頂点206a〜206nに接続することができる。多くの実施態様においては、エッジ204a〜204n（ならびにエッジ208a〜208b、エッジ210a〜210b、およびエッジ216a〜216b）は、頂点間の関係の種類を識別するためのラベルを含むことができるが、他のどんなプロパティも含むことができない。別の実施態様においては、エッジは、一意の識別子、フォーマット、種別、方向性制約条件、または任意の他の種類および形態のプロパティといったさらに別のプロパティを有していてよい。

図示の例では、配信元または配信先ノード202は対応するエッジ204a〜204nによって1つまたは複数の仮想レベルマッピング206a〜206nにマップされている。仮想レベルマッピングは、オーディオチャネルやビデオチャネルといった指定された入力チャネルまたは出力チャネルを表すことができる。図示のように、各仮想レベルマッピング206a〜206nは、一意の識別子、名前、記述、または任意の他のそうした情報を含み、またはそれらと関連付けることができる。配信元または配信先ノード202は複数の仮想レベルマッピング206にマップすることができ、ユーザが1回のボタン操作で複数のレベル（したがってポートおよび/または信号）を切り替えることが可能になる。

各仮想レベルマッピング206a〜206nはポート割り当てエッジ208a〜208bによって物理ポート212a〜212bに割り当てることができる。他の頂点と同様に、物理ポート212a〜212bも、一意の識別子、名前、記述、または任意の他のそうした情報と関連付けることができる。多くの実施態様において、物理ポート212a〜212bは方向（例えば入力や出力）によっても、物理フォーマット（例えば、ファイバコネクタ、XLRアナログ・オーディオ・コネクタ、BNCビデオコネクタなど）を表す物理レベル識別子によっても識別することができる。同様に、各仮想レベルマッピング206a〜206nは割り当てエッジ210a〜210bによって仮想レベル頂点214a〜214bに割り当てることができる。一意の識別子、名前、および/または記述に加えて、各仮想レベル頂点214a〜214bは、信号種別、フォーマット、利得制御、ならびに/または任意の他の種類および形態のチャネル関連パラメータもしくはフォーマット関連パラメータといった、マップされたチャネルに関する情報を含み、またはそうした情報と関連付けることもできる。さらに、図示のように、各物理ポート212a〜212bは、親デバイスエッジ216a〜216bを介してデバイス218a〜218bと関連付けることもできる。デバイス頂点218a〜218bは、一意の識別子、名前、および/または記述、ならびに、いくつかの実施態様においては、デバイス種別を含み、またはそれらと関連付けることができる。

したがって、デバイスはポートと関連付けることができ、ポートはチャネルマッピングおよびパラメータと関連付けることができ、特定の信号フローの配信元または配信先として識別することができる。各ノードは接続されたノードのプロパティを継承することができ、したがって任意の信号フローに適用可能なプロパティセットが作成される。

図1Aおよび図1Bに示されているようなグラフは、基礎をなすデータベースモデルを解釈するための任意の適切なシステムまたはアプリケーションを用いてシステムによって生成されうる。例えば、一実施態様においては、グラフはGraphMLフォーマットで生成され、任意の種類または形態のグラフ可視化ツールを用いて可視化される。

次に図3Aを見ると、管理システム、管理エージェント、リソースマネージャ、または任意の他の類似した用語で呼ばれることもある、放送環境のためのグラフベースのモデルを生成し、解析し、維持するための例示的システム300のブロック図が示されている。図示のシステムは、ごくわずかな変更だけでクライアントまたはサーバが用いることも、様々なプロパティでシステムをインスタンス化することによって用いることもできる。共通のコア・データ・モデルがサーバ側動作とクライアント側動作の両方に用いられる。簡単な概要として、本システムは共通モデルスタック302と分散サービスモジュール304とを含む。本システムは分散データサービス306も含み、分散データサービス306はデータベース・アプリケーション・プログラミング・インターフェース（API）308とグラフ提示API310とを提供する。本システムは、フレームインターフェース312と、ドメイン・モデル・エンジン314と、ビュー・モデル・エンジン316とをさらに含む。専用グラフビューアおよびインタラクションアプリケーション318やウェブ・ブラウザ・アプリケーション320といったアプリケーションが、グラフベースのモデルと対話し、グラフベースのモデルを表示するのに用いられる。多くの実施態様において、システム300は、ユーザインターフェースをモデル論理から分離するためのモデル・ビュー・ビューモデル（MVVM）アーキテクチャを含むことができる。

ドメイン・モデル・エンジン314は、データベースにアクセスし、アプリケーション318、320が使用すべきデータオブジェクトを作成するためのアプリケーション、サービス、サーバ、ルーチン、デーモン、または他の実行可能論理である。ドメイン・モデル・エンジン314はビュー・モデル・エンジン316に可観測パターンを提供し、ビュー・モデル・エンジン316はユーザインターフェースを更新し、ユーザインターフェース事象を処理し、かつ/またはそれ以外にアプリケーション318、320に可視化グラフモデルを更新するよう指図することができる。同様に、ビュー・モデル・エンジン316もアプリケーション、サーバ、サービス、ルーチン、デーモン、またはユーザインターフェースをレンダリングするための他の実行可能論理を含むことができる。ビュー・モデル・エンジン316によって生成されたレンダリング・ユーザ・インターフェースは、JavaFXフォーマットのビューやハイパーテキストマークアップ言語第5版（HTML5）フォーマットのビューといった任意の種類およびフォーマットのものであってよい。

いくつかの実施態様において、ドメイン・モデル・エンジン314はデータの構成および制御のためのインターフェースを実施することができる。例えば、1つのそうした実施態様では、基本切り替えインターフェースがスイッチをサポートする任意のデバイスに利用される。ルータのような任意のそうしたデバイスを制御するために制御パネルが設けられてよい。共通デバイス制御APIが、信号のラベル付け、デバイスの命名、スイッチャのロックなどといった機能のための複数のインターフェースを実施できるように、切り替えインターフェースの上にさらに他のインターフェースを構築することができる。いくつかの実施態様においては、制御されるデバイスのパラメータを探索するために汎用インターフェースまたは汎用デバイス制御インターフェースを用いることができる。ドメイン・モデル・エンジン314はユーザインターフェースを介した動的モニタリングも提供することができる。

ビュー・モデル・エンジン316およびドメイン・モデル・エンジン314は、グラフを相互に関連したドメインオブジェクトの集合体として表示するためのフレームインターフェース312またはAPIを含むことができる。フレームインターフェース312は、グラフモデルの各局面をより直感的な制御および解析のためにオブジェクトおよび関係として表すデータスキーマを提供することができる。

本システムは、ウェブサーバを含む1つまたは複数のサーバ、リモート・デスクトップ・サービスもしくは仮想化サービス、またはアプリケーション318、320にモデルへのアクセスを提供するための任意の他の種類および形態の分散サービスといった分散サービス304を含むことができる。同様に、分散データサービス306は、グラフモデルの基礎をなすデータベースを含む、データを提供するための1つまたは複数のデータサーバを提供することができる。アプリケーション318、320ならびに/またはビュー・モデル・エンジン316およびドメイン・モデル・エンジン314によるデータベースのアクセスおよび編集のためにデータベースAPI308および/またはグラフ提示API310を提供することができる。そうしたAPIは、RESTful（representational state transfer）インターフェースや任意の他のそうしたインターフェースといった任意の種類および形態のものであってよい。

前述のように、本システム内のグラフモデルは、グラフ、頂点、およびエッジの集合体を有し、単純なキー・値対から、埋め込みドキュメント、マップ、テーブル、または他のそうしたデータを含むより複雑な構造へ拡張可能なプロパティを有する、非常に単純なものとすることができる。デバイス、リンク、経路、配信元、配信先、エリアを含む他のすべてのドメインモデルは、グラフモデル内の頂点およびエッジから導出することができる。

グラフは履歴を保持することができ、配信元から配信先までの信号経路内で何らかの変更が生じる都度コピーが生成される。いくつかの実施態様において、グラフは数週間、数ヶ月、または任意の他のそうした期間にわたって保持されてよい。一実施態様においては、時間インスタンスまたは構成ごとに事象頂点が用いられ、前記構成内の頂点へのエッジ接続を伴う。これによりユーザが信号経路の完全な状態を確認し、任意の指定された過去におけるユーザインターフェース内の状態を再現することが可能になる。また事象頂点は、ユーザが、必要に応じて呼び戻し、迅速に実施することができる仮想再構成または「もし〜だったらどうなるか」シナリオの作成を可能にするのに用いることもできる。

共通モデルスタック302はドメイン・モデル・エンジン314およびビュー・モデル・エンジン316の特定のエンティティおよびインターフェースをサポートするための基礎をなすアーキテクチャモデルを含むことができる。共通モデルスタック302は、データベース、データファイル、データ・アクセス・オブジェクト、または他のそうしたデータを含むことができ、システム内の頂点、エッジ、およびグラフを表す基本的なクラスを定義することができる。

前述のように、ドメイン・モデル・エンジン314はグラフモデルに対して問合せおよび解析を行うための機能を提供することができる。例えば、ドメイン・モデル・エンジン314は、利用可能な信号経路、フォーマット、トランスコーダ（必要とされる場合）などに応じて、信号をデバイスAの指定されたポートからデバイスBの指定されたポートに切り替えることができるかどうかといった、放送環境内の制約条件の問合せを可能にする。いくつかの実施態様において、データベースの問合せは、例えば、「・・・であるデバイスを取得せよ」や「・・・であるルータを取得せよ」など、多様型とすることができる。多くの実施態様においては、ログのような履歴データを探索するときなど、複雑な探索時には結果の一部が返される場合がある。より新しい情報が最初に表示され、問合せ側ユーザは、所望の結果が見つかったときにそれ以上の探索を取り消すことができる。

いくつかの実施態様において、問合せでは経路探索決定アルゴリズムを用いることができ、そうしたアルゴリズムには、ブロン・ケルボッシュアルゴリズム、次数中心性に基づくアルゴリズム、A*探索アルゴリズム、幅優先探索アルゴリズム、深さ優先探索アルゴリズム、最短経路アルゴリズム、ベルマン・フォードアルゴリズム、ダイクストラアルゴリズム、任意の他のそうしたアルゴリズムといった、単一トランザクションアルゴリズム、または頂点主体ページ・ランク・アルゴリズムといった分散頂点主体アルゴリズム、あるいは任意の他の種類および形態のアルゴリズムが含まれる。そうした経路探索問合せは、警報を特定し、故障に対処し、信号経路指定のための最低待ち時間経路を探索し、潜在的ループを特定し、または任意の他のそうしたタスクを行うのに用いることができる。例えば、1つのそうした実施態様において、ユーザは720pビデオ信号配信元を1080i信号配信先に切り替えるよう要求する。本システムは、経路探索問合せを用いて、720p入力および1080i出力を有するアップスケーリング・ビデオ・プロセッサを経由する配信元と配信先との間の最短経路を決定することができる。いくつかの別の実施態様において、本システムは、要求されたタスクを行うために信号経路またはプロセッサを解放するように必要に応じて信号を動的に切り替え、経路指定変更することができる。例えば、第1の信号が、単にプロセッサが最低待ち時間経路の一部であるためにプロセッサを経由して配信先へ流れているが、プロセッサのリソースを必要としない場合、システムは、第2の信号をアップスケールするためにプロセッサを解放するように、第1の信号の経路を指定変更してわずかに長い経路を経由させることができる。

グラフモデルの複数のバージョンおよびモデルエンジンが、1つまたは複数の仮想機械またはエンジンの別々のインスタンスによってサーバ上で同時に走ることができる。これにより、システムをリブートせずに放送環境の再構成を可能にする動的モジュールシステムが提供される。例えば、サーバは、特定の機能（例えば、SD/HD変換器、混合器、ルータなど）を果たす複数のメディア・プレイアウト・カードを含む。管理者がインターフェースソフトウェアの新しい互換性のないバージョンをインストールしたい場合には、異なるバージョンのモデルエンジンの複数のインスタンスを同時に走らせることができ、システム全体のリブートも旧来の構成要素のアップグレードもなしで各カードまたはデバイスとの通信が可能になる。

図3Bおよび図3Cは、それぞれ、グラフ編集インターフェース330A〜330Bの例示的スクリーンショットの左半分および右半分である。図3Bに示すように、ユーザインターフェースの第1の部分330Aは、トポロジコンフィギュレータとも呼ばれ、システムトポロジおよび相互接続をモデル化するためのグラフベースの図式化ツールを含むことができる。いくつかの態様において、ユーザは、ライブラリまたはスクロール可能なリストからグラフへ、カテゴリごとに編成されたデバイスグループをドラッグ・アンド・ドロップしてもよく、あるいは手動入力され、または自動探索されたデバイスグループのリストの中から選択してもよい。デバイスグループは入力ポートおよび出力ポートを含むことができ、入力ポートおよび出力ポートは単方向でも双方向でもよい。例えば、シリアル・デジタル・インターフェースは単方向であり、イーサネットまたはインターネット・プロトコル・ベースのインターフェースは双方向である。新しいデバイス種別はユーザによってモデル化されてよく、ユーザは既存のデバイス種別から様々なプロパティをコピーすることができる。いくつかの実施態様においては、デバイス種別を組み合わせ、または分割することができる。

接続モードでは、グラフ内のどのデバイスが相互接続されうるかを示す互換性のあるポートが表示される。ユーザインターフェース330Aはデバイスグループを相互接続する複数のやり方を提供することができる。第1の方法では、ユーザはポートをクリックする（または、タッチベースのインターフェースによってタップする）ことができる。第2の方法では、ユーザは2つのポートを接続するためにクリックまたはタッチし、ドラッグすることができる。第3の方法では、「接続」モードに入った後で、ユーザは接続を作成するためにノードをまとめてドラッグ・アンド・タッチすることができる。この方法は、多くのデバイスをSDIルータやIPスイッチといった別のデバイスに接続するときに特に有用となりうる。

またユーザは、図3Cに示すように、プロパティエディタ330Bを用いて、デバイスグループをバルクで、または個別に構成することもできる。デバイスの台数は、スプリングコントロールやスライダコントロールによって、図において直接指定することができる。別の実施態様においては、ユーザはマウス/キーボードまたはタッチ/仮想キーボードによってコントロールと対話することができる。

図3Dおよび図3Eは、それぞれ、グラフ編集インターフェースの別の例示的スクリーンショットの左半分および右半分である。デバイスを構成し、相互接続を指定した後で、ユーザは、図3Dおよび図3Eに示すように物理接続ユーザインターフェース340A〜340Bを用いて個々のポート接続を指定することができる。ユーザインターフェース340A〜340Bは、デバイスのユーザ選択に応じて各デバイスの入力ポートおよび出力ポートを示すことができる。ポート種別フィルタ（例えばSDIもしくやIP）、ポートの状況（例えば、接続されている、接続されていない、すべて）、ライブ信号の状況（例えば、フォーマット、有無、誤り）、または任意の他の種類および形態の情報といったフィルタを用いて表示されるポートを探索し、かつ/または制限することができる。またユーザはパニングおよびズーミングによって、またはグリッドコントロールを用いて特定のカードおよび/またはポートの表示を選択することによってナビゲートしてもよい。いくつかの実施態様においては、ユーザがID番号、デバイス名、または任意の他のそうした情報によって探索できるように探索ボックスが提供される。

いくつかの実施態様において、ユーザは、コントロールクリックもしくはシフトクリック、マルチタッチインターフェース、または他のそうしたインターフェースによって相互接続のための複数のポートを選択することができる。またユーザは任意のポートについてより多い、またはより少ない情報を表示するようにズームインまたはズームアウトすることもできる。いくつかの実施態様においては、ユーザは、デバイスをクリックすることによって（図3Dの左側に見える）グラフまたは図内のデバイス間をナビゲートすることができ、別の実施態様においては、ユーザは、インターフェース340A〜340B内の別のデバイスから各デバイスまでの物理接続を選択することによってデバイスを選択することができる。いくつかの実施態様において、ユーザは、デバイスを右クリックし、タッチ・アンド・ホールドし、またはそれ以外のやり方で選択することによりデバイスに焦点を合わせることができ、デバイスを指定しなくてもさらなる対話が可能になる。いくつかの実施態様において、ユーザインターフェース330A〜330Bまたはユーザインターフェース340A〜340Bは、ポートが接続されていない、デバイス台数が少なすぎる、接続ループ、カードなしのフレーム、または他のそうした問題といった誤りまたは規則違反を特定することができる。

ライブモードで、ユーザインターフェース330A〜330Bまたはユーザインターフェース340A〜340Bは、信号がトポロジに沿って切り替えられる際にリアルタイムで、システム内の切り替えネットワークの状況に基づいて操作ビューを表示することができる。例えば、ノード間の経路が、信号フローを表すように強調表示され、着色され、アニメーション表示され、かつ/またはシェーディングされる。前述のように、別の実施態様において、ユーザインターフェース330A〜330Bまたはユーザインターフェース340A〜340Bは、履歴システム構成を表示するのに用いることができ、例えば、誤りを生じる結果となった過去の条件の可視化が可能になる。

図4Aは、グラフモデリングを用いて放送環境を管理し、モニタし、制御する方法400の一実施態様の流れ図である。簡単な概要として、工程402で、いくつかの実施態様において、管理サーバまたは管理エージェントは探索信号を送信し、またはそれ以外のやり方で環境内の放送リソースを探索することができる。応答が受信された場合、工程404で、管理エージェントはリソースの特性を記録することができる。これは、すべてのリソースが特定されるまで繰り返されてよい。工程406で、管理エージェントは、放送環境および放送環境の相互接続を表すグラフモデルを生成することができる。

工程408で、管理エージェントは、経路指定要求または信号を第1の放送デバイスまたはリソースから第2の放送デバイスまたはリソースまで接続し、または経路指定するよう求める要求を受信することができる。工程410で、管理エージェントは、信号を第1のリソースから第2のリソースまで経路指定するための必要な特性を特定することができる。

工程412で、管理エージェントは、第1の放送リソースから第2の放送リソースまでの経路を選択することができる。工程414で、いくつかの実施態様において、管理エージェントは、選択された経路のコストを特定し、かつ/または調整することができる。いくつかの実施態様において、管理エージェントは、経路が最低または最小コスト経路であるかどうか判定することができる。そうでない場合には、工程412〜工程414が繰り返されてよい。経路が最小コスト経路である場合には、管理エージェントは、経路が現在使用中であるかどうか判定することができる。そうである場合、いくつかの実施態様において、管理エージェントは、選択された経路が、第1の放送リソースおよび第2の放送リソースについて、現在その経路を使用しているリソースの経路のコストより低いコストを有するかどうか判定することができる。そうでない場合には、次に低いコストの経路について工程412〜工程414が繰り返されてよい。ステップ416で、使用するための経路を指定することができ、管理エージェントは、第1の放送リソースから第2の放送リソースまで信号を経路指定するための経路の使用を開始するために放送リソースへ1つまたは複数の経路指定要求または構成要求を送信することができる。

さらに図4Aをより詳細に見ると、ステップ402で、いくつかの実施態様において、管理サーバまたは管理エージェントは、探索信号を送信し、またはそれ以外のやり方で環境内の放送リソースを探索することができる。リソースがIPネットワークを介して接続されているいくつかの実施態様においては、リソースを探索することは、ネットワークを介して探索パケットまたは類似した要求を送信し、またはブロードキャストすることを含む。別の実施態様においては、IPスイッチやルータや、各スイッチまたはルータに接続された配信元および/または配信先に関する情報を有しうるオーディオルータやビデオルータといった、システム内のリソースの一部に問合せすることができる。例えば、ルータは接続されたリソースの識別で事前にプログラムされ、これらの識別を取得するために問合せされる。類似した一実施態様において、ルータは、接続された信号配信元および配信先を、種別（例えば、HDMI、平衡アナログオーディオ、AES/EBUデジタルオーディオなどによって識別することができる。さらに別の実施態様において、自動探索プロセスは、管理エージェントの制御下のスイッチリソースに様々な接続を行うよう命じ、有効な信号がスイッチによって受け渡されるかどうか判定することによって行うことができる。例えば、スイッチは第1の出力を第1の入力に接続し、有効なオーディオまたはビデオ信号が接続を介して提供されるかどうか報告するように命じられる。各リソースの能力をプローブするために各入力が各出力に連続して接続されてよく、逆もまた同様である。さらに別の実施態様において、管理者または技術者は、各放送リソースの識別および/または放送リソースの特性を手動入力することができる。いくつかの実施態様において、管理エージェントは、前述のように、管理者がリソースを追加し、リソースの特性を構成することを可能にするためのユーザインターフェースを提供することができる。

探索パケット、信号、または手順を用いる実施態様においては、応答を受信することができ、応答は、デバイスの識別子もしくは名前、デバイス種別、入力の数および種別（例えば、デジタルビデオ、デジタルオーディオ、アナログオーディオ、HDMI、H.264、IEEE1394など）、出力の数および種別、処理能力（例えば、フレーム再同期、オーディオもしくはビデオの符号化もしくは復号、多重化もしくは逆多重化、混合、等化、サラウンドサウンド符号化、トランスコーディングもしくは変換、アップスケーリングもしくはダウンスケーリングなど）、入力から出力までの待ち時間（適用される処理ありおよび/もしくはなしでの）、または任意の他のそうした特性といった、リソースおよび/またはリソースの特性に関する情報を含む。別の実施態様において、特性は、ルータまたはスイッチまたは他のデバイスから取得されてもよく、管理者または技術者によって手動入力されてもよい。工程404で、管理エージェントはリソースの特性を記録することができる。特性は、データベース、データテーブル、インデックス、単層ファイル、または、図2に関連して前述したデータ構造のような任意の他の種類もしくは形態のデータ構造に記録されてよい。工程402〜工程404は、すべてのリソースが特定されるまで繰り返されてよい。工程406で、管理エージェントは、放送環境および放送環境の相互接続を表すグラフモデルを生成することができる。グラフモデルは前述のようにグラフ化APIによって生成されてよく、前述のように、ユーザインターフェースを介してユーザまたは管理者に提示されてよい。グラフモデルのノードまたは頂点は放送リソース（例えば、配信元、配信先、ルータ、プロセッサなど）を表すことができ、エッジは、リソース間の物理的相互接続を表すことができる。いくつかの実施態様において、各エッジは、エッジによって搬送されることが可能な信号の種別（例えば、平衡アナログオーディオ、デジタルビデオなど）といった1つまたは複数の特性、ならびに長さ、待ち時間、または任意の他のそうした情報を有していてよい。

前述のように、グラフは、可能な信号経路指定を特定し、経路ベースの経路指定および管理を提供するのに用いることができる。工程408で、いくつかの実施態様において、管理エージェントは、経路指定要求または信号を第1の放送デバイスまたはリソースから第2の放送デバイスまたはリソースまで接続し、または経路指定するよう求める要求を受信することができる。例えば、要求は、信号をカメラから記録デバイスまで、または衛星受信機からマルチビューアまで経路指定することである。要求は、ユーザまたはオペレータによって、管理者によって、自動化システムによって、または任意の他のそうしたエンティティによって提供されてよい。いくつかの実施態様においては、要求は管理エージェントのユーザインターフェースを介して出され、別の実施態様においては、要求は、ネットワークインターフェースを介して、または別のアプリケーションからAPI呼び出しによって受信される。

工程410で、管理エージェントは、信号を第1のリソースから第2のリソースまで経路指定するための必要な特性を特定することができる。前述のように、第1の放送リソースおよび第2の放送リソースは様々な特性を有し、それらの特性は相補的である場合もあり、そうでない場合もある。例えば、第1のリソースが不平衡アナログ出力を有し、第2のリソースが不平衡アナログ入力を有する場合、（十分なルータまたは相互接続が存在するならば）工程412で特定された経路を経由して第1のリソースから第2のリソースまで信号を容易に経路指定することができる。しかし、第1のリソースが8チャネルの不平衡オーディオ出力を有し、第2のリソースが光ファイバを介したマルチチャネルAES10を有する場合、2つの特性は相補的ではない。代わりに、管理エージェントは、信号が必要な信号変換を行うその他のリソースを経由して第1のリソースから第2のリソースへ提供されるように、別のリソースまたは相補的な入力および出力を有するリソースを特定することができる。例えば、管理エージェントは、アナログ・デジタル・オーディオ変換を有するリソースを特定する。同様に、別の実施態様は、第1のリソースは720p60フォーマットのビデオを出力することができ、第2のリソースは入力として1080i30ビデオを受信することができる。管理エージェントはフレーム率をアップスケールし、低減することのできるビデオ変換器をしかるべく特定することができる。

いくつかの実施態様においては、第1のリソースおよび第2のリソースに対応する入力特性および出力特性を有する単一のリソースを特定することができない場合、工程412で、管理エージェントは、共に第1のリソースおよび第2のリソースに対応する入力特性および出力特性、ならびにそれらの間で相補的特性を有するリソース対を求めてグラフを繰り返し探索することができる。第1のリソースが第1のフォーマットの信号を出力し、第2のリソースが第2のフォーマットの信号を入力する1つのそうした実施態様においては、管理エージェントは第1のフォーマットの信号を受信できる入力を有するリソースセットを特定することができる。特定されたセットから、管理エージェントは、リソースのうちのいずれかが第2のフォーマットの信号を提供できる出力を有するかどうか判定することができる。そうである場合、そうしたリソースを第1のリソースおよび第2のリソースへの仲介として用いることができる。そうでない場合、一実施態様において、管理エージェントは、第2のフォーマットの信号を提供できる出力を有する第2のリソースセットを特定することができる。管理エージェントは第1のリソースセットと第2のリソースセットとを比較して、第3のフォーマットによって信号をやり取りできるリソース対を見つけることができる。この対はその場合、第1のリソースおよび第2のリソースへの仲介として用いることができる。必要な場合にはこのプロセスを反復して、特定されたリソースの第1のセットおよび第2のセットの中からリソース対が選択され、あたかも選択された対が第1のリソースおよび第2のリソースであったかのように別の仲介リソースセットが特定される。例えば、配信元Aおよび配信先Zが与えられた場合に、管理エージェントは、配信元Aからの信号を受信できる仲介Bと、配信先Zに信号を提供できる仲介Yとを特定する。仲介Bおよび仲介Yが共通の信号特性を共有していない場合には、管理エージェントは、Bからの信号を受信できる仲介Cと、Yに信号を提供できる仲介Xとを特定する。これを、第1のリソースから第2のリソースまでの完全な信号経路が特定されるまで、リソースBとリソースYの異なる対について、または仲介対の異なる反復について繰り返すことができる。経路は工程412で、第1のリソースから第2のリソースまでの潜在的信号フロー経路として選択することができる。

多くの実施態様において、異なる仲介リソース、スイッチャなどを経由する多くの潜在的信号フロー経路が放送環境に存在する。例えば、第1の経路は直接第1のリソースから第2のリソースまで至る。第2の経路はスイッチャといった第3のリソースを経由する。第3の経路は符号器といった第4のリソースおよび復号器といった第5のリソースを経由する。信号は、潜在的には、環境内のリソースの任意の組み合わせを経由して経路指定することができる。しかし、各経路は異なるコストと関連付けられている場合があり、したがって各経路は最も望ましく、または効率が高いものからあまり望ましくなく、または効率が低いものまでランク付けすることができる。1つのそうした実施態様においては、経路がトラバースする頂点およびエッジ（またはリソースおよび相互接続）といった経路長に基づいて経路ごとにコストを決定することができる。そうした実施態様においては、潜在的な経路を選択するのに、ダイクストラアルゴリズムといった最短経路優先アルゴリズムを用いることができ、各経路は他のリソースによって利用された後で除かれる。別のそうした実施態様においては、コストは、経路の合計待ち時間に基づいて経路ごとに決定することができる。経路に沿ってトラバースされる各リソースおよび相互接続によって多くの放送環境において多くの場合はおおよそミリ秒単位の少量の待ち時間が追加される。より多くのリソースをトラバースすると、待ち時間はビデオの全フレーム数に接近し、またはそれを超過する可能性があり、ともすればリップ・シンク・エラーをもたらし、または別個の遅延および他の信号の再同期が必要になる。さらに別の実施態様において、経路コストは、同じ能力を有する代替リソースが利用できるかどうか、または仲介デバイスの能力が経路によって十分に活用されないかどうかに基づいて決定することができる。例えば、前述のように、いくつかの実施態様において、仲介デバイスまたはリソースは、第1の信号フォーマットから第2の信号フォーマットへの変換に利用される。そうした仲介デバイスは通常、利用できる他の追加的な機能または処理能力を有し、したがって、経路がそれらの機能を利用しない場合は経路のコスト計算を増やすことができる。例えば、多くのデジタルオーディオ記録デバイスはアナログ入力を受け取り、デジタル出力を提供することができる。これらのデバイスが単純なアナログ・デジタル変換器として通過モードで用いられうるが、このモードではデバイスのオーディオ記録再生能力が利用されない。したがって、そうしたリソースを経由する経路は、他の機能を持たない単純なアナログ・デジタル変換器を経由する経路よりも高くつくとみなすことができる。これにより、管理エージェントが、他に利用できるオプションがなくなるまで追加機能を供与し続けるように仲介リソースを自動選択することが可能になる。同様に、いくつかの実施態様においては、指定された種別の最後のリソースを経由する経路のコストをより高価とすることができる。例えば、他の処理機能に加えて、ある信号種別から別の信号種別に変換する能力を有する3つの潜在的仲介リソースがあり、リソースのうちの2つは同じ種別のもの（例えば、レコーダ、等化器など）である場合、管理エージェントは、後続の経路指定要求の柔軟性を維持するために、第3のリソースを用いるコストを増やし、あるいは2つの同一のリソースのうちの1つを選択する。

したがって、工程414で、いくつかの実施態様において、管理エージェントは、選択された経路のコストを特定し、かつ/または調整することができる。図4Bを簡単に見ると、工程414で経路のコストを調整するための方法450の一実施態様が示されている。工程412で経路が選択されると、システムは、同じ機能を有する代替リソースが利用できるかどうか判定することができる。そうでない場合、工程452で、経路または経路内のリソースのコストを所定の量だけ増やすことができる。また管理エージェントは、リソースが十分に利用されているかどうか、またはリソースの機能（例えば、符号化機能または復号機能、記録機能など）が経路に沿った信号フローの間に利用されることになるかどうか判定することもできる。そうである場合、ステップ454で、経路またはリソースのコストを所定の量だけ減らすことができる。別の実施態様においては、使用法、冗長性、負荷分散、または他の特徴に基づいて他の類似したコスト操作を適用することができる。

図4Aに戻って、いくつかの実施態様において、管理エージェントは、経路が最低または最小コスト経路であるかどうか判定することができる。ダイクストラアルゴリズム、ベルマン・フォードアルゴリズム、バックトラッキングアルゴリズム、または頂点およびエッジの重みもしくはコストによるグラフトラバースのための任意の他の類似したアルゴリズムを含む、様々な最短経路アルゴリズムまたはグラフ探索アルゴリズムが様々な実施態様において使用されうる。いくつかの実施態様においては、最低コスト経路を決定するために、最小コスト経路が特定されるまで複数の経路を特定し、必要な場合には工程414で調整し、比較することができる。前述のように、コストは、トラバースされるリソースまたはノードの数、合計待ち時間、経路ノードの機能もしくは不使用機能の固有性、または任意の他のそうした特性に基づくものとすることができる。

経路が最小コスト経路である場合には、いくつかの実施態様において、管理エージェントは、経路または経路の一部分が現在別の信号フローまたは経路指定に使用されているかどうか判定することができる。そうである場合、いくつかの実施態様において、管理エージェントは、選択された経路が、第1の放送リソースおよび第2の放送リソースについて、現在その経路を使用しているリソースの経路のコストより低いコストを有するかどうか判定することができる。例えば、選択された経路が、別のリソース対間で信号を経路指定するためにすでに使用中であるが、それらのリソースについて、経路がより高いコストを有する（例えば、他方のリソース対が仲介リソースのすべての機能を使用しない、第1および第2の放送リソースの場合よりも他方のリソース対の場合の方が経路が長いなど）場合には、いくつかの実施態様において、管理エージェントは、経路の使用を第1および第2の放送リソースに切り替え、他方のリソース対のための新しい経路を選択することができる。これにより管理エージェントが変化する条件に合わせて動的に調整し、最適な経路指定構成を見つけることが可能になる。別の実施態様において、管理エージェントは、第1および第2の放送リソースについての選択された経路と代替経路とのコスト差が他方のリソース対についての選択された経路と代替経路とのコスト差より大きいかどうか判定し、判定に応じて経路の使用を切り替えることができる。逆に、いくつかの実施態様においては、第1および第2の放送リソースにより効率の低い、またはより長い経路を使用する追加コストが、他方のリソース対に代替経路を使用する追加コストより低い場合には、管理エージェントは第1および第2の放送リソースは代替経路を使用すべきであると決定することができる。

ステップ416で、経路を選択し、利用可能であると確認した後で、管理エージェントは、第1の放送リソースから第2の放送リソースまで信号を経路指定するための経路の使用を開始するために放送リソースへ1つまたは複数の経路指定要求または構成要求を送信することができる。経路指定要求または構成要求を送信することは、1つもしく複数のスイッチャ、IPスイッチ、もしくは他の切り替えエンティティへコマンドを送信すること、および/または1つまたは複数のリソースへ（例えば、入力または出力フォーマットを選択する、トランスコーディングを行うなどのために）構成コマンドを送信することを含むことができる。

したがって、本明細書で論じるシステムおよび方法によれば、放送環境を、グラフモデルによってマップし、重み付きエッジ頂点探索アルゴリズムに基づいて動的に決定される経路指定機能を用いて管理することができる。本システムは、故障の場合の自動経路指定変更、最適化および負荷分散を提供し、複数レベルの仲介トランスコーディングを用いて複雑な経路指定要件を満たすことができる。

前述のように、本システムは、サーバ、ワークステーション、デスクトップコンピュータもしくはラップトップコンピュータ、仮想サーバもしくはクラウドサーバ、または任意の他の種類および形態のコンピューティングデバイスを含む様々なコンピューティングデバイス上で維持し、実行することができる。図5は、本明細書に記載される方法およびシステムを実施するのに有用な例示的コンピューティングデバイスのブロック図である。コンピューティングデバイス500は、ラップトップコンピュータ、デスクトップコンピュータ、物理コンピュータによって実行された仮想機械、Apple Inc.が製造するiPadタブレットコンピュータ、Samsung, Inc.やMotorola, Inc.が製造するようなAndroidベースのタブレットといったタブレットコンピュータ、Apple Inc.が製造するiPhoneブランド/iOSベースのスマートフォン、Samsung GalaxyやHTC DroidのスマートフォンのようなAndroidベースのスマートフォンといったスマートフォンもしくはPDA、または任意の他の種類および形態のコンピューティングデバイスを含んでいてよい。コンピューティングデバイス500は、中央処理装置501と、メイン・メモリ・ユニット502と、視覚表示装置524と、仮想キーボードもしくは物理キーボードとすることのできるキーボード526、および/または、マウス、タッチパッド、静電容量方式もしくは抵抗膜方式のシングルタッチもしくはマルチタッチ入力デバイスとすることのできるポインティングデバイス527といった、（符番530を用いて全体として指し示す）1つまたは複数の出力/出力デバイス530a〜430bと、中央処理装置501と通信するキャッシュメモリ540とを含むことができる。

中央処理装置501は、メイン・メモリ・ユニット502および/または記憶528からフェッチされた命令に応答し、命令を処理する任意の論理回路である。中央処理装置は、Intel Corporation of Santa Clara, Californiaが製造するマイクロプロセッサユニットや、Motorola Corporation of Schaumburg, Illinoisが製造するマイクロプロセッサユニットや、Apple Inc. of Cupertino Californiaが製造するマイクロプロセッサユニットといったマイクロプロセッサユニット、または任意の他のシングルコアプロセッサもしくはマルチコアプロセッサ、または本明細書に記載されるように動作することのできる任意の他のプロセッサ、または2つ以上のシングルコアプロセッサもしくはマルチコアプロセッサの組み合わせによって提供されてよい。メイン・メモリ・ユニット502は、データを記憶し、任意の記憶場所がマイクロプロセッサ501によって直接アクセスされることを可能にすることのできる1つまたは複数のメモリチップ、例えば任意の種類のランダム・アクセス・メモリ（RAM）とすることができる。いくつかの態様において、メイン・メモリ・ユニット502はキャッシュメモリまたは他の種類のメモリを含むことができる。

コンピューティングデバイス500は、フロッピー・ディスク・ドライブ、CD-ROMドライブ、CD-R/RWドライブ、DVD-ROMドライブ、様々なフォーマットのテープドライブ、USB/フラッシュデバイス、ハードドライブまたは任意のクライアントアプリケーション555といったソフトウェアおよびプログラムをインストールするのに適した任意の他のデバイス、またはその部分といった任意の適切なインストールデバイス516をサポートすることができる。コンピューティングデバイス500は、オペレーティングシステムおよび他の関連ソフトウェアを記憶し、クライアントアプリケーション555に関連した任意のプログラムといったアプリケーション・ソフトウェア・プログラムを記憶するための、1つまたは複数のハード・ディスク・ドライブや独立ディスクの冗長アレイといった記憶装置528をさらに含んでいてよい。クライアントアプリケーション555は、ウェブブラウザ、アプリケーション、または前述のようなメディア配信管理システムによって提供されるユーザインターフェースにアクセスするための他のインターフェースを含んでいてよい。

さらに、コンピューティングデバイス500は、それだけに限らないが、標準電話回線、LANまたはWANリンク（例えば、イーサネット、T1、T3、56kb、X.25）、広帯域接続（例えば、ISDN、フレームリレー、ATM）、無線接続（802.11a/b/g/n/ac、BlueTooth）、セルラ接続、またはこれらのいずれかもしくは全部の何らかの組み合わせを含む様々な接続を介してローカル・エリア・ネットワーク（LAN）、広域ネットワーク（WAN）またはインターネットにインターフェースするためにネットワークインターフェース518を含むことができる。ネットワークインターフェース518は、内蔵ネットワークアダプタ、ネットワーク・インターフェース・カード、PCMCIAネットワークカード、カード・バス・ネットワーク・アダプタ、無線ネットワークアダプタ、USBネットワークアダプタ、セルモデム、または通信および本明細書に記載される動作を行うことができる任意の種類のネットワークにコンピューティングデバイス500をインターフェースさせるのに適した任意の他のデバイスを含むことができる。

コンピューティングデバイス500には多種多様な入出力デバイス530a〜430nがあってよい。入力デバイスは、キーボード、マウス、トラックパッド、トラックボール、マイクロフォン、ドローイングタブレット、およびシングルタッチまたはマルチタッチスクリーンを含む。出力デバイスは、ビデオディスプレイ、スピーカ、ヘッドフォン、インクジェットプリンタ、レーザプリンタ、および昇華型プリンタを含む。入出力デバイス530は、図5に示すように入出力コントローラ523によって制御されてよい。入出力コントローラは、キーボード526やポインティングデバイス527、例えば、マウス、光学ペン、マルチタッチスクリーンといった1台または複数の入出力デバイスを制御することができる。さらに、入出力デバイスは、コンピューティングデバイス500のための記憶528および/またはインストール媒体516を提供することもできる。コンピューティングデバイス500は、Twintech Industry, Inc. of Los Alamitos, Californiaが製造するデバイスのUSBフラッシュ・ドライブ・ラインといったハンドヘルド型USB記憶デバイスを受け入れるUSB接続を提供することができる。

コンピューティングデバイス500は、複数の表示装置524a〜424nを含み、または複数の表示装置524a〜424nに接続されていてよく、各表示装置は同じ種類および/または形態のものであっても、異なる種類および/または形態のものであってもよい。よって、入出力デバイス530a〜430nおよび/または入出力コントローラ523のいずれも、コンピューティングデバイス500が複数の表示装置524a〜424nの接続および使用をサポートし、可能にし、または提供するように、任意の種類および/または形態の適切なハードウェア、有形の媒体上で具現化されたソフトウェア、またはハードウェアとソフトウェアの組み合わせを含んでいてよい。例えば、コンピューティングデバイス500は、表示装置524a〜424nとインターフェースし、通信し、接続し、または表示装置524a〜424nをそれ以外に使用するために任意の種類および/または形態のビデオアダプタ、ビデオカード、ドライバ、および/またはライブラリを含む。ビデオアダプタは複数の表示装置524a〜424nにインターフェースするために複数のコネクタを含んでいてよい。コンピューティングデバイス500は複数のビデオアダプタを含んでいてよく、各ビデオアダプタは表示装置524a〜424nのうちの1台または複数に接続されている。コンピューティングデバイス500のオペレーティングシステムの任意の部分を、複数のディスプレイ524a〜424nを使用するために構成することができる。さらに、表示装置524a〜424nのうちの1台または複数が、例えば、ネットワークを介してコンピューティングデバイス500に接続されたコンピューティングデバイス500aやコンピューティングデバイス500bといった、1台または複数の他のコンピューティングデバイスによって提供されてもよい。これらの態様は、別のコンピュータの表示装置をコンピューティングデバイス500のための第2の表示装置524aとして使用するように設計され、構築された有形の媒体上で具現化された任意の種類のソフトウェアを含んでいてよい。当業者は、コンピューティングデバイス500が複数の表示装置524a〜424nを有するように構成される様々なやり方および態様を認め、理解するであろう。様々な構成要素はローカル通信バス540を介して接続されていてよく、ローカル通信バス540は、USB、PCIe、または任意の他のそうしたバスを含む任意の種類および形態のモジュール間バスまたは構成要素間バスを含んでいてよい。

図5に示す種類のコンピューティングデバイス500は通常、Microsoft（登録商標）Windowsオペレーティングシステムのバージョンのいずれか、UnixおよびLinuxオペレーティングシステムの様々なリリース、Macintoshコンピュータ用Mac OS（登録商標）のいずれかのバージョン、いずれかの組み込みオペレーティングシステム、いずれかのリアルタイム・オペレーティング・システム、いずれかのオープン・ソース・オペレーティング・システム、いずれかのプロプライエタリ・オペレーティング・システム、モバイル・コンピューティング・デバイス用のいずれかのオペレーティングシステム、またはコンピューティングデバイス上で走り、本明細書に記載される動作を行うことのできる任意の他のオペレーティングシステムといったオペレーティングシステムの制御下で動作する。

コンピューティングデバイス500は、コンピューティングデバイス500に適合した様々なプロセッサ、オペレーティングシステム、および入力デバイスを備えていてよい。例えば、一態様において、コンピュータ500はApple iPhoneやMotorola Droidのスマートフォンであり、あるいはApple iPadやSamsung Galaxy Tabのタブレットコンピュータであり、マルチ入力タッチスクリーンを組み込んでいる。さらに、コンピューティングデバイス500は、任意のワークステーション、デスクトップコンピュータ、ラップトップもしくはノートブックコンピュータ、サーバ、ハンドヘルドコンピュータ、携帯電話機、任意の他のコンピュータ、または通信を行うことができ、本明細書に記載される動作を行うのに十分なプロセッサ処理能力およびメモリ容量を有する他の形態のコンピューティングデバイスもしくは通信機器とすることができる。

前述のシステムは複数のそれらの構成要素のいずれかまたは各々を提供してよく、それらの構成要素は、独立型機械上で提供されてもよく、態様によっては、分散システムにおいて複数の機械上で提供されてもよい。前述のシステムおよび方法は、有形の媒体、ファームウェア、ハードウェア、またはそれらの任意の組み合わせ上で具現化されたソフトウェアを製造するプログラミング技術および/または設計技術を用いる方法、装置、または製品として実施されてよい。加えて、前述のシステムおよび方法は、1つまたは複数の製品において具現化された1つまたは複数のコンピュータ可読プログラムとして提供されてもよい。本明細書で用いる「製品」という用語は、1つまたは複数のコンピュータ可読デバイス、ファームウェア、プログラマブル論理、メモリデバイス（例えば、EEPROM、ROM、PROM、RAM、SRAMなど）、ハードウェア（例えば、集積回路チップ、フィールド・プログラマブル・ゲート・アレイ（FPGA）、特定用途向け集積回路（ASIC）など）、電子デバイス、コンピュータ可読不揮発性記憶装置（例えば、CD-ROM、フロッピーディスク、ハード・ディスク・ドライブなど）からアクセス可能な、それらに組み込まれたコードまたは論理を包含することを意図したものである。製品は、ネットワーク伝送路、無線伝送媒体、空間を伝搬する信号、電波、赤外線信号などを介してコンピュータ可読プログラムへのアクセスを提供するファイルサーバからアクセス可能であってよい。製品はフラッシュ・メモリ・カードや磁気テープであってもよい。製品は、ハードウェア論理およびプロセッサによって実行されるコンピュータ可読媒体において具現化されたソフトウェアまたはプログラマブルコードを含む。一般に、コンピュータ可読プログラムは、LISP、PERL、C、C++、C#、PROLOGといった任意のプログラミング言語や、JAVAといった任意のバイトコード言語で実施することができる。ソフトウェアプログラムは、1つまたは複数の製品においてオブジェクトコードとして記憶されていてよい。

また本システムは、クラウドベースのサービスもしくはネットワークベースのサービスとして、またはホストされたアプリケーションとして、またはSaaS（Software-as-a-Service）もしくはPaaS（Platform-as-a-Service）配信モデルの下で配信されてよく、したがって、1台または複数のコンピューティングデバイス上で、かつ/または1台もしくは複数のコンピューティングデバイスによって実行された1つもしくは複数の仮想サーバもしくは仮想機械上で実行されてよい。いくつかのそうした実施態様において、本システムは、1台または複数のロードバランサ、アクセス制御サーバ、またはリモートデバイスにサービスを配置し、提供するための他のそうしたデバイスを含むことができる。

Claims (20)

1. 放送環境の管理システムが複数の放送リソースの各々の特性を特定する工程であって、該特性は少なくとも1つの入力または出力を含む、工程;
   前記管理システムが、前記特定された特性に基づいて前記複数の放送リソースのグラフベースのモデルを生成する工程;
   前記管理システムが、前記複数の放送リソースの第1の放送リソースから前記複数のリソースの第2の放送リソースまで信号を経路指定するよう求める要求を受信する工程;
   前記管理システムが、前記複数の放送リソースの各々の前記特定された特性に基づいて、少なくとも1つのさらに別の放送リソースを経由する前記第1の放送リソースから前記第2の放送リソースまでの経路を選択する工程;ならびに
   前記管理システムが、前記第1の放送リソース、前記第2の放送リソース、および前記少なくとも1つのさらに別の放送リソースに、前記選択された経路に沿って信号を送受信するよう命じる工程、
   を含む、グラフベースのモデルによって放送リソースを管理する方法。
2. 前記特性が、少なくとも1つの入力信号種別および少なくとも1つの出力信号種別をさらに含む、請求項1に記載の方法。
3. 前記第1の放送リソースが第1の信号種別を有し、前記第2の放送リソースが第2の信号種別を有し、かつ、前記第1の放送リソースから前記第2の放送リソースまでの前記経路を選択する工程が、前記第1の信号種別の入力信号種別および前記第2の信号種別の出力信号種別を有する第3の放送リソースを経由する経路を選択する工程をさらに含む、請求項2に記載の方法。
4. 前記第1の放送リソースから前記第2の放送リソースまでの前記経路を選択する工程が、前記グラフベースのモデルによって最短経路を特定する工程をさらに含む、請求項1に記載の方法。
5. 前記グラフベースのモデルによって前記最短経路を特定する工程が、各ノードが放送リソースを表す前記グラフの最も少数の仲介ノードを経由する前記第1の放送リソースから前記第2の放送リソースまでの経路を特定する工程をさらに含む、請求項4に記載の方法。
6. 前記グラフベースのモデルによって前記最短経路を特定する工程が、最低合計待ち時間を有する前記第1の放送リソースから前記第2の放送リソースまでの経路を特定する工程であって、前記グラフの各放送リソースが、関連付けられた処理待ち時間を有する、前記工程をさらに含む、請求項4に記載の方法。
7. 前記第1の放送リソースから前記第2の放送リソースまでの前記選択された経路が、第3の放送リソースを経由するものであり、
   前記管理システムが、第4の放送リソースから第5の放送リソースまで信号を経路指定するよう求める要求を受信する工程、
   前記管理システムが、前記第3の放送リソースを経由する前記第4の放送リソースから前記第5の放送リソースまでの経路を選択する工程、
   前記管理システムが、前記第3の放送リソースは前記第1の放送リソースと前記第2の放送リソースとの間の前記経路と前記第4の放送リソースと前記第5の放送リソースとの間の前記経路とを同時に搬送することができないと決定する工程、
   前記管理システムが、第6の放送リソースを経由する前記第1の放送リソースから前記第2の放送リソースまでの第2の経路を選択する工程、ならびに
   前記第1の放送リソース、前記第2の放送リソース、および前記第6の放送リソースに、前記第2の経路に沿って信号を送受信するよう命じる工程、
   をさらに含む、請求項1に記載の方法。
8. 前記第6の放送リソースを経由する前記第1の放送リソースから前記第2の放送リソースまでの前記第2の経路を選択する工程が、
   前記第3の放送リソースを経由する前記第1の放送リソースから前記第2の放送リソースまでの前記経路の第1のコストを特定する工程、
   前記第3の放送リソースを経由する前記第4の放送リソースから前記第5の放送リソースまでの前記経路の第2のコストを特定する工程、
   前記第1のコストが前記第2のコストを超えると決定する工程、および
   前記第1のコストが前記第2のコストを超えるという前記決定に応じて前記第2の経路を選択する工程、
   をさらに含む、請求項7に記載の方法。
9. 前記第6の放送リソースを経由する前記第1の放送リソースから前記第2の放送リソースまでの前記経路の第3のコストを特定する工程、
   第7の放送リソースを経由する前記第4の放送リソースから前記第5の放送リソースまでの経路の第4のコストを特定する工程、
   前記第3のコストが前記第4のコストより小さいと決定する工程、
   をさらに含み、かつ、
   前記第3のコストが前記第4のコストより小さいという前記決定に応じて、前記第2の経路を選択する工程がさらに行われる、請求項8に記載の方法。
10. 前記第3のコストと前記第1のコストとの差が前記第4のコストと前記第2のコストとの差より小さいと決定する工程、
    をさらに含み、かつ、
    前記第3のコストと前記第1のコストとの前記差が前記第4のコストと前記第2のコストとの前記差より小さいという前記決定に応じて、前記第2の経路を選択する工程がさらに行われる、請求項9に記載の方法。
11. 前記第3の放送リソースを経由する前記第1の放送リソースから前記第2の放送リソースまでの前記経路の第1のコストを特定する工程が、前記経路の全長、前記経路の合計待ち時間、前記経路がトラバースするリソースの数、前記経路がトラバースする重複しないリソースの数、または利用可能な代替経路の数を特定する工程をさらに含む、請求項8に記載の方法。
12. グラフベースのモデルによって放送リソースを管理するためのシステムであって、該システムのネットワークインターフェースを介して複数の放送リソースのうちの少なくとも1つと通信する管理エージェントを実行するプロセッサを含み、前記管理エージェントが、
    少なくとも1つの入力または出力を含む、複数の放送リソースの各々の特性を特定し、
    前記特定された特性に基づいて前記複数の放送リソースのグラフベースのモデルを生成し、
    前記複数の放送リソースの第1の放送リソースから前記複数のリソースの第2の放送リソースまで信号を経路指定するよう求める要求を受信し、
    前記複数の放送リソースの各々の前記特定された特性に基づいて、少なくとも1つのさらに別の放送リソースを経由する前記第1の放送リソースから前記第2の放送リソースまでの経路を選択し、かつ、
    前記第1の放送リソース、前記第2の放送リソース、および前記少なくとも1つのさらに別の放送リソースに、前記選択された経路に沿って信号を送受信するよう命じる、
    ように構成されている、前記システム。
13. 前記特性が入力信号種別および出力信号種別を識別し、前記第1の放送リソースが第1の信号種別を有し、前記第2の放送リソースが第2の信号種別を有し、かつ、前記管理エージェントが、前記第1の信号種別の入力信号種別および前記第2の信号種別の出力信号種別を有する第3の放送リソースを経由する経路を選択するようにさらに構成されている、請求項12に記載のシステム。
14. 前記管理エージェントが、前記グラフベースのモデルによって最短経路を特定し、前記最短経路を前記第1の放送リソースから前記第2の放送リソースまでの前記経路として選択するようにさらに構成されている、請求項12に記載のシステム。
15. 前記管理エージェントが、各ノードが放送リソースを表す前記グラフの最も少数の仲介ノードを経由するかまたは最低待ち時間を有する前記第1の放送リソースから前記第2の放送リソースまでの経路を特定するようにさらに構成されている、請求項14に記載のシステム。
16. 前記第1の放送リソースから前記第2の放送リソースまでの前記選択された経路が第3の放送リソースを経由するものであり、
    前記管理エージェントが、
    前記第3の放送リソースをさらに別の放送リソース間の第3の経路に用いるという決定に応じて、第4の放送リソースを経由する前記第1の放送リソースから前記第2の放送リソースまでの第2の経路を選択し、かつ、
    前記第1の放送リソース、前記第2の放送リソース、および前記第4の放送リソースに、前記第2の経路に沿って信号を送受信するよう命じる、
    ようにさらに構成されている、請求項12に記載のシステム。
17. 前記管理エージェントが、前記第3の放送リソースを経由する前記第1の放送リソースから前記第2の放送リソースまでの前記経路の第1のコストを特定し、前記第1のコストが前記第3の経路のコストを超えることに応じて前記第2の経路を選択するようにさらに構成されている、請求項16に記載のシステム。
18. 前記管理エージェントが、前記第1の放送リソースおよび前記第2の放送リソースが前記第3の放送リソースのすべての機能に満たないことに応じて前記第1のコストを増やすようにさらに構成されている、請求項17に記載のシステム。
19. 前記管理エージェントが、前記経路の全長または前記経路の合計待ち時間に基づいて前記第1のコストを特定するようにさらに構成されている、請求項17に記載のシステム。
20. 前記管理エージェントが、前記経路がトラバースするリソースの数、前記経路がトラバースする重複しないリソースの数、または利用可能な代替経路の数に基づいて前記第1のコストを特定するようにさらに構成されている、請求項17に記載のシステム。

Images