JP2015507780A - 蓄積メディアの配信のためのメディアサービス及び方法 - Google Patents

Abstract

システム（１００）は、ストレージ媒体（１３４）に位置するデータコンテンツ（１３０）を指定するトランザクション要求（１２０）を処理するように構成されたアプリケーション・プログラミング・インターフェイス（ＡＰＩ）（１１０）を含む。ＡＰＩ（１１０）に関連付けられたリクエストプロセッサ（１４０）は、トランザクション要求（１２０）に応答して、データコンテンツに対して配信フォーマットを決定するように構成されてもよい。ファイルコンバータ（１５０）は、トランザクション要求（１２０）にしたがってデータコンテンツ（１３０）を配信フォーマットへ変換するように構成されてもよい。

Description

本開示は、蓄積メディアの配信のためのメディアサービス及び方法に関する。

例えば大規模なクラウドベースシステムのような現在のデータストレージシステムは、厳密なデータストレージ要件へ指向され、データは、それが受信される正にそのフォーマットで蓄積されなければならない。一例では、クラウドを形成する大規模サーバ群は加入者のためにデータを蓄積することができ、サーバ群において、データは、そのデータが受信されたフォーマットで各加入者のために蓄積されている。別の例では、オーディオ又はビデオファイルのようなメディアファイルは、加入者がそのようなファイルを所定のアプリケーションに適したフォーマット及び品質でクラウドから取得することができるように、様々な圧縮形式で冗長的に蓄積されなければならない場合がある。加入者は、どのフォーマットで蓄積すべきか、また、どのフォーマットが例えば再生解像度のような所望の品質を提供するか、について混乱することがあるだけでなく、このようにして（例えば冗長的に）ファイルを蓄積することは、そうでない場合に必要とされるよりも多大なストレージ能力の要件をもたらしかねない。

蓄積メディアの配信のためのメディアサービス及び方法が開示される。一例では、システムは、ストレージ媒体に位置するメディアデータコンテンツを指定するトランザクション要求を処理するように構成されたアプリケーション・プログラミング・インターフェイス（ＡＰＩ）を含む。ＡＰＩに関連付けられたリクエストプロセッサは、トランザクション要求に応答してメディアデータコンテンツのための配信フォーマットを決定するように構成されてもよい。ファイルコンバータは、トランザクション要求に従ってメディアデータコンテンツを配信フォーマットへ変換するように構成されてもよい。

別の例では、方法は、ストレージ媒体に蓄積されたメディアデータファイルについてのトランザクション要求を受信することを含む。この方法は、トランザクション要求に応答してメディアデータファイルのための配信フォーマットを決定することを含む。また、方法は、トランザクション要求に適合した配信フォーマットでメディアデータファイルを出力することを含む。

更に別の例では、システムは、メディアデータファイルを、ストレージ媒体のストレージ要件を緩和するストレージフォーマットへトランスコードするように構成された入力アプリケーション・プログラミング・インターフェイス（ＡＰＩ）を含む。システムは、ストレージ媒体からのメディアデータファイルについてのトランザクション要求を処理するように構成されたトランザクション・アプリケーション・プログラミング・インターフェイス（ＡＰＩ）を含む。トランザクションＡＰＩに関連付けられたファイルコンバータは、メディアデータファイルを、トランザクション要求に適合するフォーマットへ変換するように構成されてもよい。

図１は、メディアデータの仮想フォーマットストレージ及び配信を提供するためのシステムの一例を示す。 図２は、入力アプリケーション・プログラミング・インターフェイスを利用してデータをメディアサービスへアップロードするシステムの一例を示す。 図３は、メディアデータを単一フォーマットで蓄積するとともに、そのようなデータを要求に基づいて所望のフォーマットで配信するための、クラウドベースネットワークの一例を示す。 図４は、プレイリスト要件に従ってメディアデータファイルを配信する一例を示す。 図５は、メディアデータの仮想フォーマットストレージ及び配信を提供するための例示的な方法を示す。

本開示は、蓄積メディアの配信のためのメディアサービス及び方法に関する。本メディアサービス及び方法は、仮想化されたストレージ環境において実現することができ、要求に基づいて様々なフォーマットに従ってデータを配信する。一例によれば、オーディオ又はビデオファイルのようなメディアデータは、例えば複数の利用可能な圧縮形式に従ってデータをトランスコード及び／又はトランスレートするように、ストレージ媒体のストレージ要件を緩和するフォーマットで蓄積されてもよい。ファイルは、単一のストレージフォーマットで蓄積されてもよい。データを蓄積した後、加入者は、要求に基づいてデータを取得することができる。このような要求は、メディアデータを取得するためのフォーマット要件を指定してもよく、また、要求側のプロファイルは、メディアデータが配信される方法を指定してもよい。加入者の要求に基づき、かつオンデマンドでメディアデータを書式設定することによって、加入者は、メディアデータを最初に蓄積するための複雑な要件を決定しなければならないことから解放される一方、ファイルが共通のストレージフォーマットに従ってより効率的に蓄積され得るので、媒体のストレージ性能は改善され得る。

図１は、メディアデータの仮想フォーマットストレージ及び配信を提供するためのシステム１００の一例を示す。システム１００は、メディアデータコンテンツ１３０を指定するトランザクション要求１２０を受信するように構成されたトランザクション・アプリケーション・プログラミング・インターフェイス（ＡＰＩ）１１０を含む。ＡＰＩ１１０は、要求１２０に応答して、要求されたコンテンツをストレージ媒体１３４から取得するとともにコンテンツを処理して１つ又は複数の対応する配信フォーマットにするべく、メディアサービス１３６に関連付けられた機能性を公開することができる。ストレージ媒体１３４は、従来のストレージシステムに対して蓄積された複数バージョンのメディアデータコンテンツではなく、単一バージョンのメディアデータコンテンツ１３０のような１つのストレージフォーマットで、メディアデータコンテンツ１３０を蓄積することができる。例えば、ストレージフォーマットは、高解像度（例えば、ネイティブ）バージョンのメディアデータコンテンツでもよいし、ストレージ媒体１３４に対するストレージ要件を緩和するべく、トランスコードされたバージョンでもよい。メディアデータコンテンツ１３０は、例えばオーディオ及びビデオコンポーネントを有するテレビ番組、オーディオコンポーネントを有するラジオ番組などの、ディジタルメディア資産を含んでいてもよい。

メディアサービス１３６中のリクエストプロセッサ１４０は、トランザクション要求１２０に応答して、ストレージ媒体１３４で蓄積されたメディアデータコンテンツ１３０に対する配信フォーマットを決定するように構成されてもよい。ファイルコンバータ１５０は、１６０においてトランザクション要求にしたがってメディアデータコンテンツ１３０をストレージ媒体１３４のストレージフォーマットから配信フォーマットへ変換するように構成されてもよく、メディアデータコンテンツは所望のフォーマット及び／又は後述する他の仕様で配信される。メディアサービス１３６は、所定の要求に対して各々の配信フォーマットをそれぞれ有する、複数の異なるバージョンのメディアコンテンツを出力することができ、メディアコンテンツは、単一の出力ファイルで提供されてもよいし、それぞれ個別のファイル群で提供されてもよい。

配信フォーマットは、トランザクション要求１２０に応えるのに相応しい実質的に任意のフォーマットでよい。例えば、ストレージフォーマットがＭＰＥＧ４形式、１０８０ｉ解像度であるとすると、配信フォーマットは、（例えば、コンバータ１５０のトランスコード及びトランスレート機能を介して）ＭＯＶ形式、７２０ｐ解像度になるであろう。上述したように、配信フォーマットは、トランザクション要求１２０に基づいてストレージ媒体１３４のストレージフォーマットから変換される、複数の異なるフォーマットを含んでもよい。ただし、トランザクション要求１２０（又は後述の関連する要求プロファイル）は、メディアデータコンテンツ１３０のコピーバージョンを補充しない。トランザクション要求１２０（又はプロファイル）は、ファイルコンバータ１５０によってオンデマンドで生成される所望のメディア及び場合によっては配信フォーマットを指定するにすぎない。

一例では、１６０においてファイルコンバータ１５０によって配信されるメディアデータコンテンツ１３０についての配信フォーマットは、トランザクション要求１２０において特定されてもよい。別の例では、配信フォーマットは、トランザクション要求１２０に関連付けられた加入者プロファイル（図示せず）において指定されてもよい。例えば、加入者プロファイルは、ストレージ媒体１３４に関連付けられたメモリに記憶され、トランザクション要求１２０が受信されるときに処理されてもよい。加入者プロファイルのそのような処理の後、リクエストプロセッサ１４０は、本明細書で開示されたような所望の配信フォーマットを決定してもよい。更に別の例では、配信フォーマットは、トランザクション要求１２０において部分的に指定され、かつ、トランザクション要求に関連付けられた加入者プロファイルによって部分的に指定されてもよい。換言すれば、トランザクション要求１２０及び加入者プロファイルの双方は、協働して、結果として得られる配信フォーマットと、メディアデータコンテンツ１３０が１６０において供給されるべき方法と、を指定して制御することができる。

例として、特定のメディアデータコンテンツ１３０（例えば、オーディオファイル、ビデオファイルなど）は、任意の所定メディア資産についての放送品質メディアコンテンツの配信のために１つのフォーマットでのみストレージ媒体に蓄積される。例えば、異なるストレージフォーマットを有する複数の複製を蓄積するのではなく、単一のストレージフォーマット（例えば、高品質ストレージフォーマット及び／又は圧縮ストレージフォーマット）にしたがって単一のファイルが蓄積される。更に、プロキシは、ストレージ媒体１３４中の各資産に関連付けられて、低解像度バージョンのメディアコンテンツを提供してもよく、かかる低解像度バージョンは、例えばディジタル資産管理ツール、スケジューリングシステム、又は、ユーザーが例えば完全な放送品質バージョンにアクセスすることなくタイトルを調べ、オフライン編集決定をし、利用可能なコンテンツのオフライン編集を実行するだけでよい他のシステム、による使用のために取得される。メディアデータコンテンツ１３０（例えばメディア資産）がメディアサービス１３６から要求されると、所定のプロファイルが、そのメディアコンテンツに対する所定の要求を処理するために利用されて、例えばそのメディアコンテンツの配信フォーマットへの変換を制御するようにしてもよい（例えば、要求側の要件に適合させるべくトランスコード及びラップされてもよい）。このことは、メディアを複数の異なるフォーマットでストレージ媒体１３４（又は後述するクラウド）に保存する必要性を緩和し、その結果として、ストレージ及び帯域幅要件を引き下げることによってコストを下げる。ＡＰＩ１１０を介したメディアサービス１３６の加入者又はユーザーにとって、要求された各メディア資産は、彼らが必要とするどのような配信フォーマット又は配信フォーマット群においても利用可能であるように見える。というのは、ファイルコンバータ１５０は、１６０において、オンデマンドでメディアデータコンテンツ１３０をストレージフォーマットからそれぞれの配信フォーマットへシームレスに変換するからである。

別の例では、トランザクション要求１２０はプレイリストを含んでもよい。プレイリストは、１つ又は複数のメディア資産の識別のほかに、要求されたメディア資産の配信フォーマットに対する対応のタイミング要件を含んでもよい。実質的に任意のタイプの要件が指定されてよく、例えば送信すべき各セグメントデータクリップの長さ、連結させるべきセグメントの数、指定されたコンテンツセグメントの間に挿入されるべきブランクスペースの数及び長さなどである。他の例では、プレイリストは、プログラミングセグメント、削除されるべきメディアデータコンテンツ１３０のセグメント、メディアデータコンテンツに付加されるべきバー、リーダ又はヘッダ、メディアデータコンテンツへのブラックスペースの挿入、メディアデータコンテンツ中のブレイク、メディアデータコンテンツへのカレンダーや時刻の挿入、あるいは、メディアデータコンテンツへのデータスポットの挿入を指定することができる。このように、プレイリストに対する配信フォーマットは、放送対応（あるいは、ほぼ放送に対応する）バージョンの１つ又は複数のメディア資産を含んでもよい。プレイリストの例示的フォーマットは、本明細書において図４に関連して開示される。

また、トランザクション要求１２０は、メディアデータコンテンツ１３０が、対応するメディアデータコンテンツ１３０に関連付けられたストレージ媒体に蓄積されているメタデータ仕様に応じて配信されるべきであることを指定することができる。例えば、メディアデータコンテンツ１３０がストレージ媒体１３４において蓄積されているとき、関連するメタデータフィアルもまた、メタデータ仕様とともに蓄積されてよい。メタデータ仕様は、トランザクション要求１２０を満足させるべく、条件付きでターゲットプロファイルにマッピングされてよく、条件付きマッピングは、メタデータ仕様のうちどれが満たされるべきかを決定するためにトランザクション要求を処理することを含む。別の例では、メタデータ仕様は、メディアデータコンテンツ１３０に対する拡張認証プロトコル（ＥＡＰ）（保護されたＥＡＰすなわちＰＥＡＰを含む）、メディアデータコンテンツに対するプログラム及びシステム情報プロトコル（ＰＳＩＰ）、又はメディアデータコンテンツに対する一時的コンポーネントを指定することができる。

一般に、ＥＡＰは、ＥＡＰメソッドによって生成されたキー材料及びパラメータの転送及び使用について規定する認証フレームワークである。したがって、ＥＡＰはワイヤープロトコルではない。その代わり、ＥＡＰはメッセージフォーマットを定義する。ＥＡＰを使用する各プロトコルは、例えば、当該プロトコルのメッセージ内のＥＡＰメッセージをカプセル化する手法を定義する。ＰＳＩＰに関して、このプロトコルは、各チャネルに関するメタデータをテレビ局の放送転送ストリームに入れて搬送するために、また、視聴者がタイトルと概要によって試聴番組を選択することができるようにテレビ番組に関する情報を公表するために、ディジタルテレビジョンシステムにおいて用いられる。ＰＳＩＰは、仮想チャネル及びコンテンツレーティングのほかに、復号されて表示されるべきタイトル及び（オプションで）概要付きの電子番組ガイドを、定義することができる。このようなＥＡＰ及びＰＳＩＰプロトコルは、トランザクション要求１２０において及び／又は加入者プロファイルにおいて指定されて、ファイルコンバータ１５０が対応メタデータをメディアデータコンテンツ１３０と合成する方法と、このように合成されたコンテンツが所定の要求に応答して１６０において書式設定されて配信される方法と、を制御してもよい。

追加的に又は代替的に、メディアサービス１３６は、要求されたメディアデータコンテンツ及びプロファイルのサイズに基づいて、及び／又は、メディアコンテンツを期待される配信フォーマットにするために求められる処理に基づいて、メディアデータコンテンツ１３０の取得に対するトランザクションベースの課金を行うことができる。あるいは、メディアサービス１３６は、媒体１３４に蓄積されたメディアデータコンテンツのサイズ又は要求されたメディアデータコンテンツのタイプに基づいて、メディアデータコンテンツ１３０に対するストレージベース課金を行うことができる。課金は、例えば、トランザクションごとに電子的に生成されてもよいし、複数のトランザクションが発生した後に定期的に生成されてもよい。ファイルコンバータ１５０は、トランザクション要求に応答して蓄積メディアデータコンテンツを所望の配信フォーマットへ変換するように構成されてもよい。このようなコンテンツ変換は、メディアが配信されているときに、オンザフライで実行されてもよい。本明細書で用いられるとき、オンザフライの用語は、コンピュータプログラムの進行中の動作に関し、例えばプログラムの他の動作と同時に（例えば、バックグラウンド又はフォアグラウンドタスクの間に）ファイルコンバータ１５０の変換動作を実行する。符号化されたデータストレージについて使用されるとき、オンザフライデータストリームは、例えば、プログラムにとって透明に、そのデータストリームが書き込まれるときに自動的に符号化され、再び読み出されるときに復号される。本明細書において記述されるファイルコンバータ１５０に対する全ての動作は、オンザフライで実行されてよい。

ファイルコンバータのためのオンザフライ変換オプションは、トランスコーディング、解像度変換（例えばトランスレーティング）、トランスラッピング、メタデータ変換のほか、トランザクション要求１２０に基づく他のメディア変換を、含んでもよい。トランスコーディングは、圧縮されたエッセンスタイプを変換するためのプロセスであり、例えば動画データファイルやオーディオファイルについて、１つの符号化の別の符号化への直接的ディジタル−ディジタルデータ変換と考えられる。解像度変換は、例えば、メディアデータコンテンツ１３０における画像サイズやアスペクト比を変更することに関係し得る。トランスラッピングは、一例ではセキュア・ソケット・レイヤを使用して、別の例では保護されていないラッパーを利用して、メディアデータコンテンツを転送するためのファイルコンテナタイプを変更することに関係する。メタデータ変換は、書式設定されたデータコンテンツが所定の要求に応じて１６０において配信されているとき、トランスラッピングとともにオンザフライで実行されてもよい。

ファイルコンバータ１５０は、ファイル固有のプロセス及びエッセンス固有のプロセスを含む、幾つかのプロセスを動作させることができる。ファイル固有のプロセスは、ファイル形式（例えば、．ＭＸＦから．ＭＯＶへ）やエッセンスラッパー（例えば、ＭＰＥＧプログラムストリームからＭＰＥＧ基本ストリームへ）を変更するためのトランスラッピングを含む。これは、メタデータを変更／再マッピングするためのメタデータ変換と、タイムスタンプを押し、トランザクションｉｄを提供し、「電子受領書」を生成する等のためのメタデータ生成／変換と、を含む。エッセンス固有のプロセスは、ビットレートを変更するためのトランスレーティングと、圧縮規格を変更するためのトランスコーディングと、を含む。また、これらのプロセスは、画像サイズを変更するためのスケーリング、フレームレートを（例えば３０ＦＰＳから２５ＦＰＳへ）変更するためのレート変換、及び、メタデータ（例えば、トランザクション、所有者情報）を埋め込むための透かし入れを含んでもよい。

更なる例として、透かし入れに関して、このような符号化は、認証情報を配信フォーマットペイロード（例えば、配信ファイルやメタデータ）に埋め込むべく、トランザクション要求に応答して（トランザクション毎に、かつオンデマンドで）動的にオンザフライで実行されてもよい。このように埋め込まれた及び／又は符号化された情報は、以前に配信された所定ファイルが承認又は認証済みソースによって生成されたかどうかを追跡するために利用されてもよい。ファイルやメタデータに組み込まれた透かし情報に加え、認証情報は、タイムスタンプ情報、トランザクション識別情報、プログラム情報、作成者情報、製作者情報、タグ、又は、所定のトランザクション要求に応答して配信されたファイルのソースを識別するための他の符号化された情報、を含んでもよい。したがって、動的に挿入される認証情報は、誤りを含むことが判明したメディアコンテンツを探し出して修正するために用いられてもよいし、他の目的に使用されてもよい。

メディアサービス１３６は、大規模ストレージ及び配信サービスとして提供されてもよく、例えば、ストレージクラウド及び関連するクラウド配信アプリケーションを含むものとして集合的に構成されたサーバからなるストレージメディアファームによって提供されてもよい。クラウドストレージは、ネットワーク化されたオンラインストレージのモデルと考えられ、データは、一般に第三者によってホスティングされる仮想化ストレージプールに蓄積され得る。ホスティング会社は大規模データセンターを稼働させることができ、自己のデータがホスティングされることを求める使用者又は加入者は、ストレージ容量を購入したりリースしたりして、それを自己のストレージニーズのために利用する。データセンターのオペレータは、バックグラウンドで動作しており、加入者の要件にしたがってストレージ及び配信資源を仮想化し、それらを（例えばＡＰＩ１１０を介して）ストレージプールとして公開することができ、加入者は、ストレージプールを自ら利用して、選択されたファイルやデータオブジェクトを蓄積して取得することができる。しかし、本明細書で開示されるように、配信のために複数バージョンの所定資産を蓄積するのではなく、メディアサービスは、要求側にとってシームレスに各要求の配信要件に応えるために用いられる単一バージョンの資産を蓄積してもよい。物理的に、資源は複数サーバにまたがってもよい。クラウドストレージサービスは、例えば、ＡＰＩ１１０や図２に関連して後述する入力ＡＰＩのような、ウェブサービスＡＰＩを介してアクセスされてもよいし、あるいは、ウェブベースのユーザーインターフェイスを介してアクセスされてもよい。

説明の簡略化のため、本実施形態では、本明細書において記述されるシステムの異なる構成要素は、異なる機能を発揮するものとして説明されている。しかし、当該技術における当業者は、説明された構成要素の機能が異なる構成要素によって実行され得ること、また、複数の構成要素の機能性が、単一の構成要素に結合されて実行されてもよいし、より多くの構成要素にわたって更に分散されてもよいことを、理解し認識するであろう。構成要素は、例えば、コンピュータで実行可能な命令（例えば、ソフトウェア、ファームウェア）、ハードウェア（例えば、ＣＰＵ、特定用途集積回路）として、又は両者の組み合わせとして実現されてもよい。他の例では、構成要素は、例えばネットワークに亘る遠隔デバイスの間に分散されてもよい。

図２は、入力アプリケーション・プログラミング・インターフェイス２０４を利用して、メディアデータサービス２３６への蓄積のためにデータをアップロードするシステム２００の一例を示す。上述したシステム１００と同様に、システム２００は、メディアサービス２３６内のストレージ媒体２３４にあるメディアデータコンテンツ２３０を指定するトランザクション要求２２０を受信するように構成されたトランザクション・アプリケーション・プログラミング・インターフェイス（ＡＰＩ）２１０を含む。トランザクション要求２２０は、例えば、どのメディアデータコンテンツ２３０を取得すべきか、また、そのメディアデータコンテンツに対する所望の書式設定を、指定することができる。メディアサービス２３６におけるリクエストプロセッサは、トランザクション要求２２０に応答して、ストレージ媒体２３４で蓄積されたメディアデータコンテンツ２３０について配信フォーマットを決定するように構成されてもよい。図１に関して述べたように、これは、所定のトランザクション要求に対して複数の配信フォーマットを含んでもよい。ファイルコンバータ２５０は、例えばトランザクション要求に応えるべく、メディアデータコンテンツ２３０を２６０で示された配信フォーマット（群）へ変換するように構成されてもよく、メディアデータコンテンツは、所望の配信フォーマット及び／又は本明細書で記述された他の仕様で配信される。

入力アプリケーション・プログラミング・インターフェイス（ＡＰＩ）２０４は、メディアデータコンテンツ２３０を、メディアサービス２３６において動作している対応アプリケーションへアップロードするように構成されてもよい。入力ＡＰＩ２０４は、集合的に２７０で示される、ストレージ要求及びアップロードすべきデータコンテンツを受信することができる。クラウドプロセッサ２７４は、２７０においてアップロードされるべきデータコンテンツを、メディアデータコンテンツのストレージ要件を緩和するストレージ媒体２３４のストレージフォーマットへ変換することができる。例えば、変換は、ストレージ媒体２３４への蓄積のために、供給されている入力データコンテンツ２７０を、異なるストレージフォーマット及び所望の解像度（例えば、ＭＰＥＧやＭＯＶ形式）を有するメディアデータコンテンツ２３０へトランスコードすることを含んでもよい。例えば、クラウドプロセッサ２７４は、コンテンツソースからのデータコンテンツ２７０を、ストレージ媒体２３４に適合する単一のストレージフォーマットへトランスコードするとともに、メディアデータコンテンツに関連付けられたメタデータファイルを蓄積するように構成されてもよい。一例として、クラウドプロセッサ２７４は、ストレージ要求を介して指定されたネイティブのストレージフォーマットにしたがって、ストレージ媒体２３４でメディアコンテンツ２７０を蓄積することができる。

更なる例として、メディアコンテンツ２７０は、例えば所定の複数の配信フォーマットをサポートしたり、そのような複数フォーマットでコンテンツを蓄積する旨の要求を含めて考えたりするために、複数のストレージフォーマットで供給されることがある。そのような要求及び複数バージョンの所定メディア資産に応じて、クラウドプロセッサ２７４はそれでもなお、コンテンツ２７０を単一（例えば、利用可能な最高の又はネイティブの）フォーマットで蓄積して、複数バージョンの資産が蓄積されるような状況におけるストレージ要件を下げることができる。また、各メディア資産について、プロキシバージョンの資産が媒体２３４に蓄積されてもよい。クラウドプロセッサ２７４は、本明細書において開示されるように、所望の配信フォーマットを識別する情報を、蓄積コンテンツについてのトランザクション要求に関連付けられ得るようなプロファイル情報の一部分として、及び／又は対応するプロファイルに、記憶することができる。

以下、図２のシステム２００を参照して、データコンテンツを蓄積して取り出す例示的プロセスについて簡潔な説明を行う。最初に、加入者又は使用者は、入力ＡＰＩ２０４を介して１つ又は複数のファイルを（例えばＸＭＬ要求を介して）蓄積するべく、クライアントストレージ要求を生成する。ストレージ要求は、ユーザーＩＤ及びファイルのほか、メディア資産に関連付けられたメタデータを、含んでもよい。あるいは、要求は、蓄積されるべき各ファイルを含む資源の場所を識別するデータ（リソースロケータ）を含んでもよい。メディアデータコンテンツ２３０のメディアアップロードが開始する。クラウドプロセッサ２７４は、ネイティブのファイルストレージフォーマットや、ＡＰＩを介して提供された要求及び情報に基づく他のストレージフォーマットで、メディア資産を蓄積することができる。クラウドプロセッサ２７４は、クラウドストレージを割り当てるとともに、処理部（図示せず）をインスタンス化してストレージ要求２７０の処理を開始できるようにする。これは、例えば、ファイルフォーマットやメタデータパーサなどに基づいて発見された固有のメディアフォーマットを決定することを含んでもよい。クラウドプロセッサ２７４は、最初の蓄積要求２７０に基づいて、例えば更新済みのメディア資産情報を、メディア資産管理（ＭＡＭ）データベースに追加することができる。また、これは品質検証ステージを含み、例えばメディア整合性及びフォーマットが検証されてもよい（例えばマイナーなエラー、修復された構文など）。メディアアップロードが完了した後、配信レシートが生成されてユーザー又は加入者に返信されてもよく、例えば入力ＡＰＩ２０４や他のメッセージ配信メカニズム（例えば電子メール、インスタントメッセージ）を介して提供されてもよい。

ユーザー又は加入者が、メディアサービス２３６に蓄積されているメディアデータコンテンツ２３０を取得することを希望すると、トランザクションＡＰＩ２１０を介してトランザクション要求２２０が生成される。また、そのようなトランザクション要求２２０は、例えばＸＭＬのような、共通のフォーマットで記述されてもよい。一例として、要求２２０は、ユーザーＩＤを、他のパラメータとともに含んでもよく、他のパラメータは、例えば要求された出力解像度（例えばスケール）、要求されたコーデック（例えばトランスコード）、要求された配信フォーマット（例えばラッパー、．ＭＦＸ、．ＡＶＩなど）、要求されたメタデータ構造、部分的フルフィルメント（例えばインポイント及び期間）、及び／又は処理されて指定の出力配信フォーマット（例えば編集、ＢＸＦ、編集決定リスト（ＥＤＬ）ベースのフルフィルメント）に適合した複数のメディアフィアルソースからのコンテンツである。別の例として、配信フォーマットについての他のパラメータは、例えばメディアサービスに蓄積されたプロファイルにおいて指定されてもよく、メディアサービスは、要求２２０に応答してアクセスされて、配信フォーマット要件を決定してもよい。

要求２２０が受信された後、ストレージ媒体２３４における更なるクラウドプロセッシングは、クラウドプロセッサ２７４をインスタンス化して要求２２０の処理を開始することを含んでもよい。これは、ファイル又はストリーム転送を開始して要求に応じることと、トランザクションＡＰＩ２１０を介してユーザー又は加入者システムへの配信レシートを生成することと、を含んでもよい。また、これは、ＭＡＭデータベースを更新して受信者及び配信フルフィルメントの詳細を示すことを含んでもよい。また、このようなトランザクションは、例えば、メディアサービス２３６のための自動請求及び／又はインボイス作成システムに紐付けされてもよく、トランザクション要求２２０の完了後直ちに生成されてもよい。

図３は、メディアデータを単一のストレージフォーマットで蓄積し、要求に応答してかかるデータを所望の配信フォーマットで配信するためのクラウドベースネットワークの一例を示す。この例において、メディアサービスは、メディアファイルを蓄積するための１つ又は複数のデータベースを含むクラウドシステム３００（クラウドとも言う）を含むものとして実現される。この例において、３１０で示されて「ザ・ロス・ショー」と題される放送メディア資産（例えばテレビ番組）は、クラウド３００へ転送され、ＭＰＥＧ２ Ｉ−フレーム形式で１００Ｍｂｓで蓄積される。理解されるように、クラウド３００に対するストレージフォーマットのために他の圧縮形式及びフレームレートが利用されてもよく、また、ストレージフォーマットは、所定のメディア資産に対してどのような情報が利用可能であるかに応じて変わってもよい。将来のある時点で、３１０で蓄積されたザ・ロス・ショーは、クラウド３００から取得され得る。

３２０における１つの取得例では、ザ・ロス・ショーは、要求に基づいて取得され、ビデオ・オン・デマンド（ＶＯＤ）再生として配信され、ＡＡＣオーディオを含む４Ｍｂｓ、Ｈ．２６４プロファイルの配信フォーマットでクラウド３００から加入者へ転送されてもよい。かかる配信書式設定は、３２０においてザ・ロス・ショーを受信するためのトランザクション要求に基づいてもよく、及び／又は、要求及び／又は要求側に対する配信要件を規定するプロファイル中にあってもよい。３３０で、ザ・ロス・ショーはまた、ハイライト・リール・アプリケーションのために配信されてもよく、また、オーディオについてドルビーＥ技術を利用して、５０Ｍｂｓ Ｉ−フレーム・プロファイルでクラウドから転送される。３１０、３２０で示された例示に加えて、あるいはそのような例示に代わって、複数の様々な配信フォーマットがクラウド３００から提供されてもよい。かかる配信フォーマットは、上述したファイルコンバータによって、要求及び／又はプロファイル仕様に基づいて生成されてもよい。複数の配信フルフィルメントは、資産を求める単一の要求に応じたものでもよい。あるいは、資産の各出力は、資産を求める個々の要求に応じて個別に行われてもよい。

図４は、プレイリストトランザクション要求に応じるべくメディアデータファイルを配信する一例を示す。図示されるように、クラウドメディアサービス４００は、プレイリストトランザクション要求で指定されたメディアセグメントでザ・ロス・ショーを転送する。例示的な要求処理方法は、クラウドサービス４００内で実行されるコンピュータで実行可能な命令として実現され得るところ、４０２において要求を取得すること、及び、４０４においてセグメント抽出を行うことを含んでもよい。セグメント抽出は、要求を構文解析して、例えばテレビショー又はオーディオ・スニペット、広告ブレイクなどの、１つ又は複数のメディア資産のためのプレイアウトパラメータを規定するべく結合する個々のプレイリスト要素を決定することを含んでもよい。プレイリストのためのセグメントが４０４で抽出されたとき、コンテンツ挿入及び／又は重ね合わせプロシージャが開始してもよい。これは、一時的に（例えばストリーム１，ストリーム２など）幾つかのセグメントを連結することを含むことがあり、また、コンテンツ（例えば、クラウドサービス４００に蓄積された他のメディア資産）を他のコンテンツの一部分に重ね合わせることを含んでもよく、例えばテキストやグラフィックスの一部を既存の背景シーンのトップに重ね合わせることを含むことがある。

プレイリストトランザクション要求に応答して取得された対応する各メディア資産は更に、本明細書に開示されたような適切な配信フォーマット（群）へ変換されてもよい。また、要求プロセッシングは、コンテンツアセンブリ及びパッケージング４０８を含み、要求プレイリストにおける指定セグメントが結合されて対応の出力配信コンテンツになる。例えば、組み合わされたメディアコンテンツは、各プレイリスト要素のための集合ファイルとして、又は加入者への配信のための連続ストリームとして、４１０で始まる具体例に示されるような配信フォーマットでプレイアウトのために配信されてもよい。あるいは、クラウドサービスは、各メディアコンテンツを、各プレイリスト要素のための配信フォーマットで、個別ファイルとして配信することができる。したがって、クラウドサービス４００は、プレイリストトランザクション要求のフルフィルメントのためにメディア資産の前処理を行うための機能及び方法をインスタンス化するようにプログラムされてもよい。

図示した例では、プレイリストトランザクション要求に対する結果として生じる配信コンテンツは、４１０でバー／トーンセグメントを含んでもよい。また、ロス・ショーと記されたバンパーは、要求に応答して４２０において配信コンテンツの一部分として配信されてもよい。ザ・ロス・ショーの第１コンテンツセグメントは４３０で配信される。暗い又は黒のセグメントが、４４０において２分間配信されてもよい。セグメント１に次いで、ザ・ロス・ショーについて第２コンテンツセグメントが４５０で配信される。次のショーについてのバンパーが４６０で配信され、４７０において更に２分の黒の期間が続く。理解されるように、複数のプレイリスト、プレイリストセグメント、及びプレイリスト構成は、クラウド４００からメディアファイルを取得するための要求における、及び／又はプログラミング要件を指定することもできるクラウドサービス４００に蓄積されたプロファイルにおける、ユーザー仕様にしたがって、指定されて配信されてもよい。更に、コンテンツの各単位はそれぞれの配信フォーマットを含んでもよく、配信フォーマットはコンテンツのタイプに応じて変わってもよい。本明細書において開示されるように、配信フォーマットはまた、例えば指定の配信命令及び／又はクラウド４００に蓄積されることがあるプロファイル情報にしたがったプレイリストトランザクション要求に基づいて変わってもよい。

上述した構造上及び機能上の特徴を考慮し、例示的方法は、図５を参照することでより良く理解されるであろう。説明の簡潔性のため、方法はシリアルに実行されるものとして図示され記述されるものの、方法の一部は、本明細書で記述された順序とは異なる順序で、及び／又は同時に、生じ得るので、方法は図示された順序に限られないことが理解され把握されるべきである。かかる方法は、例えば、ＩＣ又はコントローラに配置された様々な構成要素によって実行されてよい。

図５は、メディアデータの仮想フォーマットストレージ及び配信を提供するメディアサービスのための例示的な方法５００を示す。方法５００は、５１０において、（例えば図１のＡＰＩ１１０を介して）あるストレージフォーマットでストレージ媒体に蓄積されたメディアデータファイルのトランザクション要求を受信することを含む。５２０において、方法５００は、（例えば、図１のリクエストプロセッサ１４０を介して）トランザクション要求に応答して、メディアデータファイルについて配信フォーマットを決定することを含む。５３０において、方法５００は、（例えば、図１のファイルコンバータ１５０を介して）メディアデータファイルをストレージフォーマットから配信フォーマットへ変換して、トランザクション要求を完了することを含む。図示されていないが、方法５００の他の例は、配信フォーマットがトランザクション要求において指定されることを含んでもよい。また、これは、配信フォーマットが、トランザクション要求や要求側に関連付けられたプロファイルにおいて指定されること含んでもよい。また、方法５００は、ストレージ媒体のストレージ要件が既存のシステムに対して減少されるように、メディアデータファイルからなるコンテンツを単一のストレージフォーマットから任意の複数の配信フォーマットへトランスコードし、トランスレートし、トランスラップし、及び／又はその他に修正することを含んでもよい。

上述した事項は例示である。構成要素又は方法論の考え得るあらゆる組合せを記述することはもちろん可能ではないが、当該技術における当業者は、多くの更なる組合せ及び置換が可能であることを認識するであろう。したがって、本開示は、特許請求の範囲を含む、この出願の範囲に該当するかかる変更、修正、及び変形を全て包含することを意図している。本明細書で用いられるように、用語「含む」は、含むを意味するがこれに限られず、用語「含んでいる」は、含んでいるを意味するがこれに限られない。用語「基づいて」は、少なくとも部分的に基づいてを意味する。更に、本開示又は特許請求の範囲が「１つの」（"a"、"an"）、「第１の」若しくは「別の」要素、又はその均等物を引用する場合、１つ又は複数の１つのかかる要素を含むものと解釈されるべきであり、２つ又はそれ以上のかかる要素を必要としないし排除もしない。

Claims (9)

1. 複数のメディア資産に対するメディアデータコンテンツを１つのストレージフォーマットで蓄積するように構成されたストレージ媒体と、
   所定メディア資産のトランザクション要求を処理し、前記トランザクション要求に応答して対応メディアデータコンテンツのための配信フォーマットを決定するように構成されたリクエストプロセッサと、
   前記ストレージ媒体からの前記所定メディア資産についての前記メディアデータコンテンツにアクセスし、前記対応メディアデータコンテンツを前記ストレージフォーマットから前記配信フォーマットへ変換するように構成されたファイルコンバータと、
   を備えたメディアサービス。
2. 請求項１のシステムであって、前記配信フォーマットは、前記トランザクション要求において指定されているシステム。
3. 請求項１のシステムであって、前記配信フォーマットは、前記トランザクション要求に関連付けられた加入者プロファイルにおいて指定されているシステム。
4. 請求項１のシステムであって、前記トランザクション要求は、前記メディアデータコンテンツのうち少なくとも１つのメディア資産に対して配列セグメントを指定するプレイリスト 要求を備えているシステム。
5. 請求項１のシステムであって、前記トランザクション要求は、前記メディアデータコンテンツが、前記所定メディア資産についての前記メディアデータコンテンツに関連付けられて蓄積されているメタデータ仕様に応じて配信されるように指定するシステム。
6. 請求項１のシステムであって、前記メディアサービスは、要求された前記所定メディア資産及びプロファイルに対する前記メディアデータコンテンツのサイズに基づいて、前記メディアデータコンテンツの取得に対してトランザクションベースの課金を行い、又は、ＡＰＩは、前記メディアデータコンテンツの前記サイズ若しくは要求された前記メディアデータコンテンツのタイプに基づいて、前記メディアデータコンテンツに対して蓄積ベースの課金を行うシステム。
7. 請求項１のシステムであって、前記ファイルコンバータは、前記トランザクション要求に基づいて、トランスコーディング、解像度変換、トランスラッピング、又はメタデータ変換のうち少なくとも１つを実行するように構成されているシステム。
8. １つのストレージフォーマットでストレージ媒体に蓄積されたメディアデータファイルのトランザクション要求を受信することと、
   前記トランザクション要求に応答して前記メディアデータファイルに対する配信フォーマットを決定することと、
   前記トランザクション要求を完了させるべく、前記ストレージフォーマットから前記配信フォーマットへ前記メディアデータファイルを変換することと、
   を備えた方法。
9. 前記メディアデータファイルを、前記ストレージ媒体のストレージ要件を緩和する単一のストレージフォーマットへトランスコードすることを更に備えた請求項８に記載の方法。
   

Images