JP2014526763A - 災害復旧システム及び方法 - Google Patents

Abstract

災害復旧システムは、クラウドコンピューティング環境に配置された複数の資源を含んでいてもよい。資源のそれぞれは、クラウドコンピューティング環境内で１つ又は複数のメディアシステムの部分として機能するように割当て可能でもよい。コンテンツ・インテーク・サービスは、クラウドコンピューティング環境への受信メディア資産の配信を制御するようにプログラムされてもよい。監視及び復旧プロセスは、受信メディア資産が供給されている一次メディアシステムを監視するようにプログラムされてもよく、また、災害復旧状態を感知することに応答して、監視及び復旧プロセスは、一次メディアシステムへ配信されている受信メディア資産に基づいて、複数の資源のうちの選択された資源をインテリジェントに管理することができる。

Description

本発明は、一般に事業の継続性に関し、特に災害復旧システム及び方法に関する。

災害復旧は、例えば天災や人災の後のように、組織にとって重大な技術的基盤の復旧や継続性に備えることに関連するプロセス、方針及び手続を含む。事業の継続性が重要である放送及び他の産業では、所定の構成要素に対するバックアップを提供するべく、Ｎ＋１個の冗長性が時として利用されている。バックアップ構成要素は、スタンバイモードで動作することができ、所定の構成要素が障害を生ずるまでアクティブ状態でもパッシブ状態でもよい。このような冗長性は、個々の資源の単独障害に対して満足に機能し得るものの、例えばもしワークフロー（例えばディジタル・メディア・サプライ・チェーン）プロセスに属する複数の資源が障害を生ずれば、かかる冗長性は、災害状況において複雑になることがある。

本開示は、一般に、例えば放送メディア資産などのための、災害復旧システム及び方法に関する。

一例では、災害復旧システムは、クラウドコンピューティング環境に配置された複数の資源を含むことができる。資源のそれぞれは、クラウドコンピューティング環境内で１つ又は複数のメディアシステムの一部分として機能するように割当て可能であってもよい。コンテンツ・インテーク・サービスは、クラウドコンピューティング環境への受信メディア資産の配信を制御するようにプログラムされていてもよい。監視及び復旧プロセスは、受信メディア資産が提供されている一次メディアシステムを監視するようにプログラムされていてもよく、また、災害復旧状態を感知することに応答して、監視及び復旧プロセスは、一次メディアシステムに配信されている受信メディア資産に基づいて、複数の資源のうち選択された資源をインテリジェントに管理することができる。

別の例として、放送メディアプロバイダに災害復旧サービスを提供する方法が提供されてもよい。この方法は、それぞれのメディアプロバイダのメディア・サプライ・チェーン内の災害復旧状態を感知することを含んでいてもよい。クラウドコンピューティング環境における資源（例えばメディア・サプライ・チェーンのための仮想資源）は、それぞれのメディアプロバイダに対する受信リアルタイムメディア資産の定義に基づいて、メディア・サプライ・チェーンにおける該当のオペレーションへの切替えのために提供されてもよい。トリガーを受信することに応答して、それぞれのメディアプロバイダのメディア・サプライ・チェーンにおけるオペレーションは、それぞれのメディアプロバイダに災害復旧メディアオペレーションを提供するべく、クラウドコンピューティング環境における割当て資源に切り替えられてもよい。

図１は、実施形態による災害復旧システムの一例を示す。 図２は、実施形態による災害復旧システムにおいて実行され得る監視及び復旧プロセスの一例を示す。 図３は、実施形態による災害復旧システムのために利用され得るコンテンツ・インテーク・プロセスの一例を示す。 図４は、実施形態による災害復旧システムの別の例を示す。 図５は、実施形態によって実行され得る災害復旧の例示的方法を示すフロー図である。

本発明は、一般に災害復旧システム及び方法に関する。本システムは、本明細書においてメディア資源と呼ばれる、メディア資産を記憶するためのクラウドストレージ資源と非ストレージ資源とを含む、複数のクラウド資源を利用するクラウドコンピューティングシステムにおけるサービスとして実行されてもよい。メディア資源は、ディジタル・メディア・サプライ・チェーンにおいて動作することがある任意のクラウドコンピューティング資源（例えば、ハードウェア及び／又はソフトウェア）を含んでいてもよい。クラウドコンピューティング環境において、メディア資源は、シン・プロビジョニングされ、災害復旧状態に該当する１つ又は複数の障害発生資源を感知することに応答して、クライアントのメディアシステムにインテリジェントに割り当てられてもよい。地理的に分散した複数の同時災害は極めて起こりそうにないので、クラウド内のメディア資源のシン・プロビジョニングは、同一の又は異なる地理的位置に所在する複数のクライアントに単一の物理資源が売却されることを可能とする。

メディア資源は、例えば資産のメタデータから判定されるように、メディア資産を把握することに基づいて、インテリジェントに割り当てられてもよい。例えば、所定のメディア資産に対するルールは、その所定のメディア資産について関連のメタデータから確定され得るメディア資産のタイプを把握することに基づいて選択されてもよい。更に、受信メディア資産は、データ復旧のために、例えば低下したデータレートへトランスコードされるように、修正されてもよい。修正された資産は、備えられたメモリ資源への記憶のために、又は、リアルタイム・プレイアウトのために、クラウドに配信されてもよい。クラウドストレージ資源は、各加入者のサービスレベルにしたがって加入者のためにメディア資産を記憶するように十分供給されてもよい。

当該技術における当業者によって理解されるように、本発明の部分は、方法、データ処理システム、又はコンピュータプログラム製品として実施されてもよい。したがって、本発明のこれら部分は、全てハードウェアの実施形態、全てソフトウェアの実施形態、又はソフトウェアとハードウェアとを組み合わせた実施形態の形を取ってもよい。更に、本発明の部分は、媒体上にコンピュータで読取り可能なプログラムコードを有する、コンピュータで使用可能なストレージ媒体に記憶されたコンピュータプログラム製品でもよい。任意の適切なコンピュータで読取り可能な媒体は、静的及び動的ストレージデバイス、ハードディスク、光学ストレージデバイス、並びに磁気ストレージデバイスを含んで利用されてもよい。

本発明の特定の実施形態は、本明細書において、方法、システム、及びコンピュータプログラム製品のフローチャート図を参照しつつ記述されている。図のブロック及び図中のブロックの組合せは、コンピュータで実行可能な命令によって実行されてもよいことが理解される。これらのコンピュータで実行可能な命令は、機械を生産するために、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能なデータ処理装置（つまり、デバイスと回路との組合せ）に属する１つ又は複数のプロセッサに与えられて、プロセッサを介して実行する命令が、ブロック又はブロック群において特定された機能を実行するようにしてもよい。

また、コンピュータ又は他のプログラム可能なデータ処理装置を固有の方法で機能するように指図することができるこれらのコンピュータで実行可能な命令は、コンピュータで読取り可能なメモリに記憶されて、コンピュータで読取り可能なメモリに記憶された命令が、フローチャートブロック又はブロック群において特定された機能を実行する命令を含む製品をもたらすようにしてもよい。また、コンピュータプログラム命令は、コンピュータ又は他のプログラム可能なデータ処理装置にロードされて、コンピュータ又は他のプログラム可能な装置上で実行されるべき一連の動作ステップをもたらし、コンピュータで実行されるプロセスを生成して、コンピュータ又は他のプログラム可能な装置上で実行する命令が、フローチャートブロック又はブロック群において特定された機能を実行するためのステップを提供するようにしてもよい。

図１に移ると、例示的な災害復旧システム１０は、本明細書においてグラウド１２とも呼ばれるクラウドコンピューティング環境において実装されている。複数のメディア資源１４は、クラウド１２内で実装され、資源１ないし資源Ｎとして示される。ここでＮは正の整数である。資源１４は、例えば一次メディアシステム１６に属するディジタル・メディア・サプライ・チェーンの部分として実行される任意の又は全てのオペレーションのように、リアルタイム放送オペレーションを実行するように構成されたソフトウェア、ハードウェア、又はハードウェアとソフトウェアとの組合せを含んでいてもよい。本明細書で使用されるように、用語「一次メディアシステム」は、所定のメディアプロバイダのためのディジタル・メディア・サプライ・チェーン（例えば、制作から伝送まで）の１つ又は複数の部分として動作するように構成された一連のアクティブな（及び場合により何らかのバックアップ）資源を言う。したがって、例として、メディア資源１４は、アップリンク、ダウンリンク、トラフィック及び課金システム、広告挿入、ディジタル資産管理システム、メディア配信、プレイアウト・オートメーション、コンティンジェンシー（例えばバックアップ）メディア資産などを含むことができる。また、クラウド１２は、任意の数の１つ又は複数のこのようなメディアシステム１６のためのメディアを保持するべく、Ｓ＿１ないしＳ＿Ｍとして示されるクラウドストレージ資源１７を含む。ここでＭは資源の数量を指す正の整数である。

更なる例として、メディア資源１４の幾つかは、災害復旧状態の際にクラウド資源１４への切替えを容易にするべく、一次メディアシステム１６の正常オペレーションの間、アクティブであるように設定されてもよい。あるいは、資源は、スタンバイモードで動作するように設定され、監視及び復旧プロセス２２が災害復旧状態を感知することに応答して作動されてもよい。

正常（例えば非災害）オペレーション状態の間、１つ又は複数のコンテンツソース１８は、例えば地上リンク（例えば光ファイバ）や無線リンク（例えば衛星）を介して、メディア資産を一次メディアシステム１６に供給することができる。所定のメディア資産のソース及び場所は、例えばディジタル資産管理システムやオートメーションシステム（図示せず）のような、一次メディアシステム１６の部分として実行される資源によって識別されてもよい。一次メディアシステム１６は、そのような資産のためのスケジューリング及びオートメーションに応じて、メディア資産の対応するメディア・プレイアウトを提供することができる。メディア資産の固有の経路及び処理は、一次メディアシステム１６によって実行されるワークフロー及びディジタル・メディア・サプライ・チェーンに応じて変わる。

また、メディア資産は、コンテンツ・インテーク・モジュール２０に供給されてもよい。かかる供給は、一次メディアシステム１６に資産を提供するために用いられるのと同様でもよいし、あるいは、異なる供給が利用されてもよい。コンテンツ・インテーク・モジュール２０は、例えばディジタル資産管理システムへのアプリケーション・インターフェイスを介して、一次メディアシステム１６の該当する資源から供給場所データを取得してもよい。コンテンツ・インテーク・モジュール２０は、メディア資産をクラウド１２にリアルタイムで配信し、メディア資産は、資産のタイプに応じて、タイムシフト再生のためにクラウドストレージ資源１７に記憶されてもよいし、リアルタイム・プレイアウトのために利用可能とされてもよい。したがって、コンテンツ・インテーク・モジュール２０は、クラウドストレージ資源１７をリアルタイムで連続的に供給する。利用可能なストレージ資源１７の全プールは、（例えば加入レベルによって規定された）ストレージ要件に応じて、それぞれのメディアプロバイダ１６に供給されてもよい。例えば、インテーク・モジュール２０は、コンティンジェンシーオペレーションのためのメディア資産の記憶のために、各プロバイダ１６に対するストレージ資源１７の割当てを制御することができる。また、インテーク・モジュール２０は、記憶されたコンテンツの期間満了後に（例えばプレイアウトの後に、又は記憶時間に基づいて）、割り当てられた資源をプールに解放することができる。

また、コンテンツ・インテーク・モジュール２０は、データ資産を別の状態に修正するとともに、修正されたデータを割り当てられたストレージ資源１７に記録することができる。例えば、コンテンツ・インテーク・モジュール２０は、資産のメディアコンテンツを低下した災害復旧データレートへトランスコードするように構成されていてもよい。低下した災害復旧データレートは、クラウドストレージ資源要件を緩和するとともに、クラウド１２における資源１４のシン・プロビジョニングを容易にする。

更なる例として、メディア資源１４のシン・プロビジョニングは、適切な資源が加入メディアプロバイダにとって利用可能であり続けることを、統計的に十分なレベル（例えば、予測される利用レベルの２標準偏差）に確保するように実行されてもよい。このことは、加入メディアプロバイダのそれぞれに対して、クラウド１２における一連の資源を仮想化することによって行われてもよい（すなわち、複数の異なる一次メディアシステム１６があり得る）。このように、それぞれの加入メディアプロバイダは、そのメディア・サプライ・チェーンの各側面に対する災害復旧を可能にするのに十分なクラウド１２中の仮想資源を提供されるものの、災害復旧状態における実際の物理資源のオンデマンド割当ては、複数の加入プロバイダの間で共有されることがある。

監視及び復旧プロセス２２は、一次メディアシステム１６の動作を監視するとともに、災害復旧状態の発生を感知するようにプログラムされてもよい。災害復旧状態は、例えば天災又は人災による、一次メディアシステム１６内の１つ又は複数の資源の障害に対応してもよい。かかる障害は、メディア・プレイアウトを含むリアルタイム放送オペレーションの即時停止をもたらしかねない。あるいは、かかる障害は、一次メディアシステムからのタイムシフトされた後続のメディア・プレイアウトを妨げるものとして、ワークフローにおける上流で発生するかもしれない。複数の資源が災害復旧状態において障害を生ずる例では、それら資源は、そのサプライチェーンのワークフローにおいて、隣接する又は隔てられた資源に該当し得る。

また、災害復旧状態を感知することに応答して、監視及び復旧プロセス２２は、一次メディアシステム１６へ配信されている受信メディア資産に基づいて、選択されたクラウドコンピューティング資源１４をインテリジェントに管理することができる。インテリジェントな管理は、一次メディアシステム１６についてリアルタイム放送オペレーションを維持するために十分な相応のメディア資源１４を準備することと、このようなメディア資源を割り当てることと、を含んでいてもよい。このことは、物理資源のマッピングを含んでもよく、例えばクラウド１２内のノードとして実行されてもよい。また、このことは、クラウド１２内の資源１４を利用するべく、ソフトウェアアプリケーションをインスタンス化することと、ワークフローをリダイレクトすることと、を含んでいてもよい。所定の災害復旧状態のために利用される資源１４は、全メディア・サプライ・チェーンのための資源に相当してもよいし、その一部分に相当してもよい。一例として、監視及び復旧プロセス２２は、メディア・サプライ・チェーンのオートメーション機能と資産管理機能とを割り当てることができる。所定のメディアシステムに対してクラウドコンピューティング資源１４が割り当てられているとき、割り当てられた資源は、決定的性能を発揮するために、その所定のメディアシステムのための災害復旧プロセスにのみ用いられる。

また、システム１０は、切替えコントロール２４を含んでいてもよく、切替えコントロールは、割り当てられた資源１４を、一次メディアシステム１６のメディア・サプライ・チェーンにおけるリアルタイムオペレーションに接続する（例えば起動する）ようにプログラムされている。一例では、切替えコントロールは、トリガーに応答して切替えを実行することができる。トリガーは、切替えが進行すべきことを手動で確認する、例えば許可されたユーザー（例えばスーパーバイザ）による、ユーザー入力に応答して供給されてもよい。代替的な例として、確認のルール及び／又は他の自動化された方法は、実際の災害復旧状態の存在を確認するために実行されてもよい。

したがって、トリガーに応答して、切替えコントロール２４は、監視及び復旧プロセス２２を介して割り当てられている資源１４への切替えを実行することができる。切替えコントロール２４は、一次メディアシステム１６のうち障害を生じた部分を取り替えるために、割り当てられた資源１４を利用することができる。例えば、割り当てられた資源１４は、（例えばユニフォーム・リソース・ロケータ（ＵＲＬ）を介して）クラウド内のノードとしてマッピングされてもよく、また、その関連する方法及び機能は、相応のＡＰＩを介してアクセスされてもよい。一次メディアシステム内の機能的資源は、クラウド内の選択された資源を利用するように命令されてもよく、クラウド資源は、障害の生じていない一次メディアシステムにおけるオペレーションと連絡するように、同様に命令されてもよい。メディア・サプライ・チェーンがクラウド資源の使用によって回復されれば、リアルタイム・メディア・ワークフロー・オペレーションは再開できる。一次メディアシステム１６への適切な修復が行われた後、切替えコントロール２０は、資源１４をクラウド１２に解放して、その資源が他の災害復旧オペレーションのために利用可能であるようにしてもよい。

図２は、災害復旧システム（例えば、図１のシステム１０）において実行され得る監視及び復旧プロセス５０の一例を示す。監視及び復旧プロセス５０は、一次メディアシステムのオペレーションを監視するとともに災害復旧状態を感知するようにプログラムされたモニタ機能５２を含んでいてもよい。監視及び復旧プロセス５０は、ローカルエリアネットワークやワイドエリアネットワーク（例えば、インターネット）などのネットワークを通じて、及び／又は直接接続によって直接的に、一次メディアシステムと連絡してもよい。

モニタ機能５２は、一次メディアシステムを形成するメディア・サプライ・チェーンに属する様々な箇所で情報にアクセスして取得するべく、１つ又は複数のインターフェイス５４を含んでいてもよい。例えば、インターフェイス５４は、障害と同時にメディア資産のプレイアウトを危うくし得る、一次メディアシステムにおいて動いている各アプリケーションプログラムのオペレーション・パラメータ（例えば診断情報）を取得するようにプログラムされたＡＰＩを含んでいてもよい。オペレーション・パラメータは、継続的に又は周期的に取得され、ローカルメモリに記憶されてもよい。災害状態に対応する特定タイプの障害では、インターフェイスは、メディア・サプライ・チェーンにおける１つ又は複数の箇所からオペレーション・パラメータを全く取得できないことがある。また、インターフェイス５４がメディア・サプライ・チェーンにおけるオペレーション情報を受信できないことや、そうでない場合でも（例えば、そのようなオペレーションによる応答がないことによって）オペレーションにアクセスできないことは、監視及び復旧プロセス５０による評価のためにローカルメモリに記憶されてもよい。

また、監視及び復旧プロセス５０は、モニタ５２によって取得されたオペレーション・パラメータに基づいて災害復旧状態の発生を感知するようにプログラムされた災害ディテクタ５６を含む。災害ディテクタ５６は、例えば、一次メディアシステムオペレーションのために取得されたオペレーション・パラメータ情報を集約し、災害復旧状態が存在するかどうかを判定するようにプログラムされた災害メトリクスを利用することができる。

一例として、災害ディテクタ５６は、取得されたオペレーション・パラメータを、予めプログラムされた予測（例えば正常）オペレーション・パラメータと比較することができる。災害ディテクタ５６は、感知された障害が災害復旧を要するほど十分に重大であることを確保するべく、所定のメトリクスを利用して取得済みパラメータを評価することができる。このことは、少なくとも所定の期間、メディア・サプライ・チェーンにおけるミッションクリティカルな箇所からオペレーション・パラメータを取得しないことを含んでいてもよい。例えば、もしインターフェイスが、事業オペレーションのためのオペレーション・パラメータ、及び／又は過去に利用可能であったメディアを取得できなくなれば、災害ディテクタ５６は、そのような事業オペレーションに対する障害を推測することができる。代替的に又は追加的に、メディア・サプライ・チェーンにおける所定のオペレーションは、それ自体、機能的であってもよいが、その予測される命令もメディア資産もサプライチェーンの別部分から受信することはない。サプライチェーンにおける１つ又は複数のオペレーションの断続的な障害は、好ましくは、災害状況に該当しない。したがって、災害メトリクスもまた、取得されたオペレーション・パラメータが、少なくとも所定の期間、予測オペレーション・パラメータの外であったかどうかを分析することができる。したがって、災害ディテクタ５６は、オペレーション・パラメータを経時的に評価して、災害復旧状態が存在するかどうかを確かめることができる。

アラートジェネレータ５８は、災害復旧状態の発生を（例えば、災害ディテクタ５６によって）判定することに応答して、１つ又は複数のアラートを供給するようにプログラムされてもよい。一例では、アラートは、メッセージングシステム（例えば、電子メール、テキストメッセージ、電話呼出しなど）を使用する、１人又は複数の予め特定された個人に送信されてもよい。別の例では、アラート通知は、災害復旧サービスが該当のクラウド資源への切替えを実行できるように、例えばユーザー入力の形で、１人又は複数の許可された者から応答を要求することができる。応答は多くの方法で実行されてもよい。一例として、アラートジェネレータ５８は、電子メール又は他のメッセージング技術によって、許可されたユーザー（群）にアラートメッセージを送信することができる。（例えば、モニタ５２によって取得されたオペレーション情報から得られた）１つ又は複数の障害の記述を与えることに加えて、メッセージは、災害復旧クラウドへの切替えが起こるべきかを確認するべく、許可フォームへのリンクを含んでいてもよい。また、幾つかの例では、許可されたユーザーは、災害復旧オペレーションの一部分として実行されることがある１つ又は複数のクラウドベース資源を制御するためのパラメータを設定したり確認したりすることができる場合がある。また、ユーザーは、災害復旧が実行されないようにすることを選ぶことができる。（例えば、災害復旧を許可したり阻止したりするための）応答は、災害復旧記録の一部分としてメモリに記憶されてもよい。

また、監視及び復旧プロセス５０は、選択されたメタデータを受信メディア資産から取得するようにプログラムされたメタデータ・エクストラクタ６０を含んでいてもよい。選択されたメタデータは、資産のタイプを記述する１つ又は複数の選択されたメタデータフィールドに対応してもよい。メタデータは、受信メディア資産から直接取得されてもよいし、あるいは、例えばディジタル資産管理、トラフィック、オートメーション、及びコンテンツ配信システムからのように、メディア・サプライ・チェーンにおける別オペレーションから取得されてもよい。

一例では、インターフェイス５４は、メタデータ・エクストラクタ６０がメディア資産のための十分なメタデータを取得することを可能にするようにプログラムされ、資産定義がそれぞれの受信資産について生成されるようにしてもよい。メディア資産の可能な資産定義の数は、所定のメディア資産について得られているメタデータの範囲のほかに、メタデータ・エクストラクタ６０によって取得されたメタデータの数及びタイプにもよって、変わってもよい。メタデータを取得するために利用される方法は、メタデータのフォーマットに応じて変わってもよく、標準プロトコルか独自仕様のプロトコルかに関わる場合がある。一例として、放送メディア資産について、メタデータは、ブロードキャスト・エクスチェンジ・フォーマット（ＢＸＦ）にしたがって供給されてもよいが、他の標準又は独自仕様のメタデータフォーマットが利用されてもよい。所定の資産（例えば、メディアコンテンツ又はマテリアルの要素）に関連付けられたメタデータのより豊富なセットは、より豊富でより簡便な資産定義の機会を提供することができ、このことは更に、追加のより専門的なサービス（例えば、広告挿入、コンティンジェンシー資産選択）が災害復旧クラウドサービス内の資源によって実現されるようにしてもよいことが理解されるべきである。

監視及び復旧プロセスは、ルールエンジン６２を利用して、災害復旧プロセスをインテリジェントに制御することができる。例えば、ルールエンジン６２は、受信メディア資産のタイプに応じて、異なるルール６４を利用して、災害復旧オペレーションを管理することができる。資産のタイプは、例えば抽出されたメタデータから生成され得る、資産定義として実行されてもよい。所定の資産に対する資産定義を生成するべく問い合わせされてもよいメタデータフィールドの幾つかの例は、幾つか挙げれば、TYPE、SUB-TYPE、及びPROGRAM CATEGORYを含む。資産定義は、メタデータフィールドからの１つの記述を含んでもよいし、あるいは、記述群が統合されて対応の資産定義値がそれぞれの受信資産に対して与えられてもよい。

一例として、資産定義は、ライブイベントかタイムシフトイベントか、日常のプログラムかどうか、シンジケート化されているかどうか、販売促進イベントかどうかに応じて、メディア資産を区別してもよい。メディア資産を広告として識別することに加え、定義は、地方、地域又は全国の広告であるかを、更に特定することができる。したがって、抽出されたメタデータのより豊富なセットは、定義資産のより包括的なセットを許容することができ、このことによって、災害復旧オペレーションに対してより精緻な精度の制御を与えることができる。資産定義の数及びタイプは、例えば、ユーザーインターフェイス７４を介してユーザーにプログラム可能であってもよい。

ルールセレクタ６６は、資産定義に基づいて一連の適切なルール６４を選択するようにプログラムされてもよい。ルールセットは、災害復旧オペレーションのための資源の準備及び割当てを制御するために使用されてもよい。例えば、ルールセレクタ６６は、異なるタイプの資産を異なるように調整するべく、異なるルールを選択することができる。例えば、リアルタイムメディア資産を把握することに基づいてルールを選択することによって、ルールは、エンドユーザー及び広告主に対する災害復旧の影響を緩和するように実行されてもよい。更なる例として、もし受信ライブイベントの供給が災害復旧状態の間に障害を生じれば、ルールは、そのイベントに固有の臨時バックアップコンテンツを選択するように実行されてもよい。同様に、もしシンジケート化された受信シチューエーションコメディ・プログラムの供給が喪失されたとすると、ルールエンジンは、ルールを利用して、例えば、利用可能性に応じて、同じプログラムの別エピソードや、類似ジャンルの別プログラムを選択することができる。ルールエンジンは受信メディア資産のタイプに応じてルールを異なるように適用するので、クラウドにおける資源のシン・プロビジョニングはよりインテリジェントになり得る。

また、資産定義及び障害の程度に応じて、ルールエンジン６２は、臨時メディア資産の場所を特定することができる。このことは、クラウドストレージへロード済みの資産や、利用可能なフィードを介して取得されてリアルタイムでクラウドへ配信され得る資産の場所を含むことがある。本明細書において開示されるように、割り当てられたクラウド資源への実際のオペレーション切替えは個別のトリガー（例えば、ユーザー入力や自動トリガー）を要することがある。

また、監視及び復旧プロセス５０は、資源マネージャ７０を利用して、災害復旧状態のための資源を管理することができる。資源マネージャ７０は、適用されているルールに基づいて資源を管理することができ、ルールは、本明細書において開示されるような受信リアルタイムメディア資産の資産定義に応じて変わってもよい。一例として、資源マネージャ７０は、（例えば災害ディテクタ５６によって）災害復旧状態を感知することに応答してクラウドにおける資源の準備及び割当てを開始するようにプログラムされた、割当て／マッピング機能７２を含んでもよい。このことは、クラウドからのメディア資源を割り当てること及び／又はインスタンス化することや、そのような資源を各メディアプロバイダのための切迫した災害復旧プロセスに投じることを含んでもよい。また、準備及び割当ては、クラウド内の物理資源（例えばノード）への供給済み仮想資源の物理的マッピングを含んでもよく、また、メディア・サプライ・チェーンにおける障害の生じているオペレーションを再開するための対応のソフトウェア資源に、対応のＡＰＩを介してプログラムでアクセスすることを含んでもよい。例えば、資源マネージャ７０は、それぞれの加入メディアシステムについて、マッピングテーブルを利用して、クラウドにおける仮想資源の供給を制御することができる。資源マネージャが、所定のメディアプロバイダについて、感知された災害復旧状態に対して資源を割り当ててインスタンス化すると、以前に仮想的に供給された資源は、その所定のメディアプロバイダのために固有のオペレーションを行うことについて確定的になる。すなわち、資源の将来的な状態が幾分ランダムと考えられるように、このような割当ての前に、メディア資源は、任意の加入メディアプロバイダに利用可能である。

また、資源マネージャ７０は、クラウド中の資源に関連付けられた他のオペレーションを制御するようにプログラムされてもよい。例えば、ユーザーインターフェイス７４は、災害復旧制御パラメータ７６をプログラムするための設定機能にアクセスすることができる。パラメータは、クライアントメディアシステムによって購入された災害復旧サービスのレベルにしたがってそのクライアントメディアシステムに利用可能なサービスを設定することを許容してもよい。パラメータ７６は、各チャネルについてクラウドサービスに記憶され得るメディア資産の期間及びデータレートを制御することができる。また、サービスのレベルは、異なるクライアントメディアシステムに対する資源の優先度を判定するために利用されてもよく、このことは、クラウドにおける資源のシン・プロビジョニングを更に容易にすることができる。資源マネージャ７０は監視及び復旧プロセス５０内に図示されているものの、資源マネージャは、監視及び復旧プロセスによって対応のＡＰＩを介してアクセスされ得る、１つ又は複数の別個の方法として実行されてもよいことが理解される。

説明の簡略化のため、監視及び復旧プロセス５０に属する別個の構成要素は、異なる機能を実行するものとして図示され記述されている。しかし、当該技術において通常の知識を有する者は、上述した構成要素の機能が異なる構成要素によって実行されてもよいこと、また、幾つかの構成要素の機能性が結合されて単一の構成要素上で実行されてもよいことを理解し認識するであろう。構成要素は、例えば、ソフトウェア（例えばコンピュータで実行可能な命令)やハードウェア（例えば特定用途集積回路又はデバイス）として、又は両者の組合せとして実現されてもよい。他の例では、構成要素は、（例えば、災害復旧サービスの対応する機能として）クラウドにわたってリモートデバイス間に分散されてもよい。

図３は、クラウド１０４中の選択されたメディア資源１０２及びストレージ資源１０３にリアルタイムメディア資産を配信するために利用され得るコンテンツ・インテーク・サービス１００の一例を示す。コンテンツ・インテーク・サービス１００は、１つ又は複数のコンテンツ資源１０８から、概略的に１０６で示される、対応する一次メディアシステムに供給されている受信リアルタイムメディア資産のミラーを持つようにプログラムされてもよい。例えば、コンテンツ資源１０８は、地上又は無線通信リンクを介してコンテンツを提供することができる。コンテンツ資源１０８は一般に、利用可能な最高のデータレートで、資産中のメディアコンテンツを提供する。

コンテンツ・インテーク・サービス１００は、インテークプロセスを制御するためにルール１１２を利用するルールエンジン１１０を含んでいてもよい。ルール１１２は、それぞれの加入メディアシステム１０６に対して加入サービスの条件に応じて変わり得る一連の事業ルールを含んでいてもよい。ルール１１２は、加入メディアシステム１０６に割り当てられた所定のストレージ資源１０３に記憶されているコンテンツの有効期間（例えば、合計時間）を含む、コンテンツ・インテークのためのパラメータを制御するように（例えば、図示しないユーザーインターフェイスを介して）プログラムされてもよい。また、ルール１１２は、あるタイプの資産（例えば、ライブメディア）を、例えば所定のメディアプロバイダのための災害復旧プロセスの間に、その所定のメディアプロバイダに対して割り当てられたメディア資源１０２へ直接的に配信することを制御する場合がある。

ルールエンジン１１０は、クラウド１０４からのコンテンツの自動削除を制御するべく、ルール１１２を利用することができる。例えば、ルールエンジン１１０は、コンテンツの期間満了後に、クラウド１０４のクラウドストレージ１０３からコンテンツを自動的に削除することができる。コンテンツが期間満了を迎えたかどうか（例えば、コンテンツが一次メディアシステムでプレイアウトされたか）を判定するために、ルールエンジン１１０は、例えばディジタル資産管理システム１１４及びオートメーションシステム１１６からのように、加入メディアシステム１０６のサプライチェーンにおける１つ又は複数の箇所から（例えば、１つ又は複数のＡＰＩを介して）情報を取得することができる。また、ルールエンジン１１０は、コンテンツが記録されている合計時間を確立するルールに基づいて、クラウドストレージ１０３からコンテンツを自動的に削除することができる。また、ルールエンジン１１０は、クライアントの加入レベルに紐付いたルールに基づいてインテークのための相応のメディア資産を検索するべく、加入メディアシステム１０６から取得されたオペレーション情報を利用することがある。また、ルール１１２は、異なるコンテンツ資源１０８の間の優先度を特定するようにプログラムされ、もし所定のメディア資産があるソースから利用可能でなければ、ルールエンジン１１０が、代わりのソースからそのような資産を取得するようにインテーク・サービスに命令できるようにされてもよい。

また、コンテンツ・インテーク・サービス１００は、クラウドストレージ資源１０３における効率的な記憶を容易にするべく、資産を別のフォームに修正することができる。一例として、コンテンツ・インテーク・サービス１００は、受信メディア資産を、例えばコンテンツソース１０８から受信された元の資産に対して低下したビットレートを有するような、相応の災害復旧資産へトランスコードするためのトランスコーダ１２０を含むことができる。更に、所定の資産に対する災害復旧ビットレートは、ルール１１２によって規定されてもよく、例えば加入プロバイダの加入サービスレベルに応じて変わることがある。このことは、バックアップコンテンツが加入メディアシステム１０６に供給されたものと同一になりがちである他のアプローチと対照的である。

図４は、本明細書で開示されたシステム及び方法（例えば、図１−図３及び図５を含む）が複数のメディアシステムをサポートすることを意図していることを示す、災害復旧システム１５０の一例を示す。この例において、システムは、一次サイト１ないし一次サイトＰとして図示される、複数の一次サイト１５２を示す。ここでＰはサイトの数を表す正の整数である。各サイト１５２は、メディアをプレイアウトするように構成された様々なハードウェア及びソフトウェアコンポーネントを実装する相応のメディア・サプライ・チェーンを含んでもよく、例えば、物理的及び／又は無線技術によるビデオ、オーディオ、電子看板などのリアルタイム放送を含んでもよい。ハードウェア及びソフトウェアコンポーネントのうちの幾つかは、もし共通の事業システムの一部分であれば、異なるサイト間で共有されてもよいことが理解される。この例において、各サイトは、災害復旧サービス１ないし災害復旧サービスＰとして図示された該当の災害復旧サービス１５４に加入し、このサービスを実行する。

災害復旧サービス１５４のそれぞれは、本明細書において開示されるように、資源１ないし資源Ｎ（Ｎは正の整数である）として図示された一連のメディア資源１５６と、クラウド１６０において実装されているストレージ資源１５８と、を利用するようにプログラムされている。災害復旧サービス１５４はクラウド１６０の外部にあるものとして図示されているものの、このようなサービスはクラウドの一部分と考えられてもよいことが理解される。本明細書において開示されるように、災害復旧サービス１５４は、それぞれのメディアサイト１５２に対する災害復旧状態とともに、メディア資源１５６及びストレージ資源１５８を利用するための切替えオペレーションのプロセスを感知することができる。更なる例として、加入サービスに対する請求モデルは、メディアオペレーションのための災害復旧を提供するべく、加入サービスに対する継続チャージに、資源の利用に応じた利用料を加えたものを含んでいてもよい。他の請求手配が可能である。

上述した構造上及び機能上の特徴を考慮すると、ある方法は、図５に示された例示的方法２００を参照することでより良く理解される。図示された動作は、他の実施形態では、異なる順序で生じたり、他の動作と同時に生じたりする場合があることが理解され認識されるべきである。更に、図５に示された全ての特徴が方法を実施するために要求されるわけではない。

図５は、クラウドベースの資源を使用する自動災害復旧を実行するための方法の一例を示す。方法２００は、本明細書において開示されるように、任意の数の一次メディアシステムに対して災害復旧保護を提供するように実行されてもよい。方法２００は２０２で始まり、２０２においてルール及び他の災害復旧パラメータが設定される。このルール及びパラメータは、例えばそれぞれの一次メディアシステムに対する加入サービスレベルに基づいて、災害復旧サービスのレベルを確立することができる。例えば、クラウドストレージは、それぞれの加入メディアシステムについてメディアコンテンツを記憶するために割り当てられてもよく、また、シン・プロビジョニングされたメディア資源が仮想的に割り当てられてもよい。

ルール及び災害復旧パラメータが決まると、方法は２０４に進む。２０４で、オペレーション及びデータが監視されてもよい。オペレーションは、加入メディアシステムのためのメディア・サプライ・チェーン内の任意のオペレーション情報及びデータに対応してもよい。例えば、１つ又は複数のインターフェイス（例えば、図１のインターフェイス５４）が、オペレーション情報及びデータを取得するために利用されてもよい。

２０６で、災害復旧が求められているかどうかについて判定が行われる。この判定は、経時的に収集され記憶され得る、監視されたオペレーション及びデータに基づいて（例えば、図１の災害ディテクタ５６によって）行われてもよい。もし災害復旧が必要とされなければ、方法は２０４に戻って、監視プロセスを再開してもよい。もし災害復旧が適切と判定されれば、方法は２０８に進むことができる。２０８で、メディア資源が（例えば、図１の資源マネージャ７０によって）割り当てられて、切替えのために準備されてもよい。このことは、クラウド資源をメディア・サプライ・チェーンにおける対応箇所とともにマッピングすることのほか、災害復旧状態のためにメディア資産のフローを制御するべくルールにアクセスすることをも含んでもよい。また、資源の割当て及び切替えの準備は、受信メディア資産のタイプを記述するメタデータに基づいて制御されてもよい。２１０で、アラートは、（例えば、図１のアラートジェネレータ５８を介して）１人又は複数の所定の受取人へ送信されてもよく、受取人は、ユーザー及び／又はアプリケーションを含んでもよい。アラートは、情報通知を提供するとともに、受取人による応答又は他の動作を要求することができる。

２１２で、災害復旧オペレーションへの切替えを始動させるかどうかについて判定が行われてもよい。この判定は、例えば許可されたユーザー又は自動化された方法によって受信され得る、トリガーに基づいて行われてもよい。切替えが始動されない場合、方法は、２１４へ進み、例えば感知されたパラメータ、計算の結果、及び災害メトリクス、並びに切替えを阻止することに関連して受信された応答（群）を含むような、災害復旧データのログを取ってもよい。２１４から、方法は、２０４へ戻って、オペレーション及びデータを監視することを再開してもよい。切替えが始動された場合、方法は、割り当てられているクラウドベースのメディア資源への切替え作業２１６へ進む。このことは、加入メディアシステムのメディア・サプライ・チェーンへ割当て資源をマッピングすることを含んでもよい。また、対応する災害復旧データはメモリに記録されてもよい。また、システムが災害復旧モードで動作する合計時間に基づいて、追加のチャージが加入メディアシステムによって負担させられてもよい。

オペレーションは、終了して加入メディアシステムオペレーションへスイッチバックされるまで、災害復旧モードを維持してもよい。スイッチバックは、（例えば、許可されたユーザーによる）ユーザー入力に応答して、又は、加入メディアシステムについて災害復旧状態がもはや存在しないことを（例えば、２０４で、再開された監視を介して）自動的に感知することに応答して、実行されてもよい。災害復旧モードの間、受信リアルタイムメディア資産からメタデータが抽出されてもよく、また、予測されるリアルタイムメディア資産を取り替えるためのコンティンジェンシーメディア資産が、抽出されたメタデータに基づいて選択されてもよい。

上述したことを考慮すれば、複数の加入者を同時に受け入れることのできる、仮想化された災害復旧サービスを提供するためのシステム及び方法が開示されている。更に、地理的に分散した同時災害の蓋然性は低いので、クラウド内の資源は、全国にわたって異なる加入者にシン・プロビジョニングされてもよい。資源のこのようなシン・プロビジョニングは、利用可能なストレージ要件を超えるものを含むとともに、メディア・サプライ・チェーンにおいて実行される他のハードウェア資源を含むことができる。

上述したのは例示である。構成要素又は方法の考え得る全ての組合せを記述することはもちろん可能ではないが、当該技術において通常の知識を有する者は、多くの更なる組合せ及び置換が可能であることを認識するであろう。したがって、本発明は、請求の範囲を含む本願の範囲内に属するこのような変更、修正及び変形の全てを包含するものとする。更に、本開示又は請求の範囲が、「１つの」、「第１の」若しくは「別の」要素、又はその均等物を引用する場合、それは、１つ又は１つより多いそのような要素を含むように解釈されるべきであり、２つ又は複数のそのような要素を要するものでも排除するものでもない。本明細書で使用されたように、用語「含む」は、含むが制限されない、を意味する。用語「に基づいて」は、少なくとも部分的に基づいて、を意味する。

Claims (9)

1. 放送メディアプロバイダに災害復旧サービスを提供する方法であって、前記方法は、
   それぞれのメディアプロバイダのメディア・サプライ・チェーン内の災害復旧状態を感知することと、
   前記メディア・サプライ・チェーンにおける相応のオペレーションへの切替えのために、前記それぞれのメディアプロバイダに対する受信リアルタイムメディア資産の定義に基づいて、クラウドコンピューティング環境における資源を準備して割り当てることと、
   前記それぞれのメディアプロバイダに対して確定的な災害復旧メディアオペレーションを提供するべく、トリガーを受信することに応答して、前記それぞれのメディアプロバイダの前記メディア・サプライ・チェーンにおけるオペレーションを、前記クラウドコンピューティング環境における前記割り当てられた資源へ切り替えることと、
   を含む方法。
2. 請求項１に記載の方法であって、準備して割り当てることは、
   前記メディア資産の前記定義に基づいてルールを選択することと、
   前記選択されたルールに基づいて、前記災害復旧状態のための前記資源の割当て及びマッピングを制御することと、
   を更に含む方法。
3. 前記受信リアルタイムメディア資産からメタデータを抽出することと、
   前記抽出されたメタデータに基づいて前記メディア資産の前記定義を生成することと、
   を更に含む、請求項２に記載の方法。
4. 請求項２に記載のシステムであって、前記受信リアルタイムメディア資産はライブメディア資産に対応し、前記ルールは、前記災害復旧状態の間に前記ライブメディア資産が配信され得ない場合、前記メディア資産の前記定義に基づいて、関連するコンティンジェンシーメディア資産を取得することを可能にするように選択されるシステム。
5. 前記それぞれのメディアシステムに対する前記受信リアルタイムメディア資産からメタデータを抽出することと、
   予測されるリアルタイムメディア資産を前記災害復旧メディアオペレーションの間に取り替えるべく、前記抽出されたメタデータに基づいてコンティンジェンシーメディア資産を選択することと、
   を更に含む、請求項１に記載の方法。
6. 関連するルールに基づいて、前記それぞれのメディアプロバイダに割り当てられたクラウドストレージ資源へ前記リアルタイムメディア資産を配信することを更に含む、請求項１に記載の方法。
7. メディア資産が低下した災害復旧データレートで前記クラウドストレージ資源に記憶されるように、前記リアルタイムメディア資産を前記低下した災害復旧データレートへトランスコードすることを更に含む、請求項６に記載の方法。
8. 前記災害復旧状態を感知することに応答してアラート通知を送信することを更に含む請求項１に記載の方法であって、前記トリガーは、前記アラート通知に応答したユーザー入力に応答して受信される方法。
9. 前記それぞれのメディアプロバイダの前記メディア・サプライ・チェーンにおけるオートメーション及び資産管理機能を複製するべく、少なくとも１つのメディア資源を割り当てることを更に含む、請求項１に記載の方法。
   

Images