(57)【要約】【課題】  ビデオライフサイクルの管理を簡素化する。【解決手段】  本発明の一実施形態は、「ビデオライフサイクル」の管理を簡素化する。一実施形態は、ビデオ公開、ビデオを更新すること、ビデオを非公開にすること、ビデオに関する統計の読み出し、ビデオを処理するための承認、ビデオの検証、ビデオメタデータ処理、ビデオトランスコーディング及び／又はビデオ送信などの技術的ステップを抽象化することによってビデオ公開プロセスを効率化する１又は複数のモジュールを含む。他の実施形態が本願明細書において説明される。【選択図】  図１１
2018088682.tif 000002
【特許請求の範囲】
【請求項１】
ビデオを受信するステップと、
ユーザからのユーザ入力に応答して、前記ビデオが第１の配信チャネル及び第２の配信チャネルに配信され、しかし第３の配信チャネルに配信されないべきであると決定するステップと、
前記ビデオについての第１の特性及び第２の特性を決定するステップであり、前記第１の特性及び前記第２の特性は、ファイルタイプ、コンテナタイプ、ビデオ継続時間、ビデオ解像度、フレームレート、ビデオ圧縮ビットレート及びオーディオ圧縮ビットレートを含む群から選択される、ステップと、
前記ユーザ入力に応答して、前記ビデオを前記第１の配信チャネルに対応する第１のフォーマットを有するトランスコードされた第１のビデオにトランスコードし、前記ビデオを前記第２の配信チャネルに対応する第２のフォーマットを有するトランスコードされた第２のビデオにトランスコードし、前記第１のフォーマットは前記第２のフォーマットに等しくなく、前記ビデオを前記第３の配信チャネルに対応する第３のフォーマットを有するトランスコードされた第３のビデオにトランスコードしないステップと、
前記ユーザ入力に応答して、第１のメタデータと前記トランスコードされた第１のビデオとを第１のコンテナに、第２のメタデータと前記トランスコードされた第２のビデオとを第２のコンテナにパッケージ化するステップと、
前記ユーザ入力に応答して、前記第１のコンテナを前記第１の配信チャネルに、前記第２のコンテナを前記第２の配信チャネルに公開するステップと、
前記の公開された第１のコンテナについての第１のメトリックデータと前記の公開された第２のコンテナについての第２のメトリックデータとを受信するステップであり、前記第１のメトリックデータは、前記第２のメトリックデータとは別様にフォーマットを整えられる、ステップと、
前記第１のメトリックデータ及び前記第２のメトリックデータを、前記第１のメトリックデータと前記第２のメトリックデータとの双方に対応する共通の正規化されたデータに正規化するステップと、
を含む方法をコンピューティング装置に実行させるコンピュータプログラム。
【請求項２】
前記方法は、
前記ユーザから、前記第１の配信チャネルに対応する第１のアカウントクレデンシャルと前記第２の配信チャネルに対応する第２のアカウントクレデンシャルとを受信するステップと、
前記第１のアカウントクレデンシャルを介して前記第１の配信チャネルに、前記第２のアカウントクレデンシャルを介して前記第２の配信チャネルにアクセスするステップと、
前記第１の配信チャネル及び前記第２の配信チャネルにアクセスすることに応答して、前記第１のコンテナを前記第１の配信チャネルに、前記第２のコンテナを前記第２の配信チャネルに公開するステップと、
を含む、請求項１に記載のコンピュータプログラム。
【請求項３】
前記方法は、
前記ユーザ入力に応答して、どの第１のチャネル情報が前記第１の配信チャネルに必要であり、どの第２のチャネル情報が前記第２の配信チャネルに必要であるかを決定するステップと、
どの第１のチャネル情報が前記第１の配信チャネルに必要であり、どの第２のチャネル情報が前記第２の配信チャネルに必要であるかを決定した後、前記ユーザからの前記第１のチャネル情報及び前記第２のチャネル情報を要求するステップと、
を含み、
前記第１のチャネル情報は前記第２のチャネル情報に等しくない、
請求項１に記載のコンピュータプログラム。
【請求項４】
前記方法は、
前記第１の配信チャネル及び前記第２の配信チャネルのためのメタデータ要件を決定するステップ、
を含み、
前記第１の配信チャネル及び前記第２の配信チャネルのためのメタデータ要件を決定することに応答して、前記方法は、
前記ユーザから前記第１の配信チャネルに固有のメタデータ情報を受信するステップと、
前記メタデータ情報の検証が不成功に終わるステップと、
前記メタデータ情報の検証が不成功に終わることに応答して、前記第１の配信チャネルに固有のさらなるメタデータ情報について前記ユーザに促すステップと、
を含む、請求項１に記載のコンピュータプログラム。
【請求項５】
前記方法は、
前記ユーザ入力に応答して、前記ユーザが前記第１の配信チャネル及び前記第２の配信チャネルにコンテンツを配信することを承認されると決定するステップ、
を含み、
前記ユーザが前記第１の配信チャネルにコンテンツを配信することを承認されると決定することは、前記ユーザ入力に応答して、（ａ）第１の認証方法を使用して前記ユーザが前記第１の配信チャネルにコンテンツを配信することを承認されると決定するように決定することであって、前記第１の認証方法は、前記第１の配信チャネルに対応し、しかし前記第２の配信チャネルに対応しない、ことと、（ｂ）第１の認証方法及び前記第１の配信チャネルに固有のさらなる認証クレデンシャルについて前記ユーザに促すことと、を含み、
前記ユーザが前記第２の配信チャネルにコンテンツを配信することを承認されると決定することは、前記ユーザ入力に応答して、（ａ）前記第１の認証方法に等しくない第２の認証方法を使用して前記ユーザが前記第２の配信チャネルにコンテンツを配信することを承認されると決定するように決定することであって、前記第２の認証方法は、前記第２の配信チャネルに対応し、しかし前記第１の配信チャネルに対応しない、ことと、を含む、
請求項１に記載のコンピュータプログラム。
【請求項６】
コンピューティング装置により実施される方法であって、
ビデオを受信するステップと、
ユーザからのユーザ入力に応答して、前記ビデオが第１の配信チャネル及び第２の配信チャネルに配信され、しかし第３の配信チャネルに配信されないべきであると決定するステップと、
前記ビデオについての第１の特性及び第２の特性を決定するステップであり、前記第１の特性及び前記第２の特性は、ファイルタイプ、コンテナタイプ、ビデオ継続時間、ビデオ解像度、フレームレート、ビデオ圧縮ビットレート及びオーディオ圧縮ビットレートを含む群から選択される、ステップと、
前記ユーザ入力に応答して、前記ビデオを前記第１の配信チャネルに対応する第１のフォーマットを有するトランスコードされた第１のビデオにトランスコードし、前記ビデオを前記第２の配信チャネルに対応する第２のフォーマットを有するトランスコードされた第２のビデオにトランスコードし、前記第１のフォーマットは前記第２のフォーマットに等しくなく、前記ビデオを前記第３の配信チャネルに対応する第３のフォーマットを有するトランスコードされた第３のビデオにトランスコードしないステップと、
前記ユーザ入力に応答して、第１のメタデータと前記トランスコードされた第１のビデオとを第１のコンテナに、第２のメタデータと前記トランスコードされた第２のビデオとを第２のコンテナにパッケージ化するステップと、
前記ユーザ入力に応答して、前記第１のコンテナを前記第１の配信チャネルに、前記第２のコンテナを前記第２の配信チャネルに公開するステップと、
前記の公開された第１のコンテナについての第１のメトリックデータと前記の公開された第２のコンテナについての第２のメトリックデータとを受信するステップであり、前記第１のメトリックデータは、前記第２のメトリックデータとは別様にフォーマットを整えられる、ステップと、
前記第１のメトリックデータ及び前記第２のメトリックデータを、前記第１のメトリックデータと前記第２のメトリックデータとの双方に対応する共通の正規化されたデータに正規化するステップと、
を含む方法。
【請求項７】
ビデオを受信するステップと、
ユーザからのユーザ入力に応答して、前記ビデオが第１の配信チャネル及び第２の配信チャネルに配信され、しかし第３の配信チャネルに配信されないべきであると決定するステップと、
前記ビデオについての第１の特性及び第２の特性を決定するステップであり、前記第１の特性及び前記第２の特性は、ファイルタイプ、コンテナタイプ、ビデオ継続時間、ビデオ解像度、フレームレート、ビデオ圧縮ビットレート及びオーディオ圧縮ビットレートを含む群から選択される、ステップと、
前記ユーザ入力に応答して、前記ビデオを前記第１の配信チャネルに対応する第１のフォーマットを有するトランスコードされた第１のビデオにトランスコードし、前記ビデオを前記第２の配信チャネルに対応する第２のフォーマットを有するトランスコードされた第２のビデオにトランスコードし、前記第１のフォーマットは前記第２のフォーマットに等しくなく、前記ビデオを前記第３の配信チャネルに対応する第３のフォーマットを有するトランスコードされた第３のビデオにトランスコードしないステップと、
前記ユーザ入力に応答して、第１のメタデータと前記トランスコードされた第１のビデオとを第１のコンテナに、第２のメタデータと前記トランスコードされた第２のビデオとを第２のコンテナにパッケージ化するステップと、
前記ユーザ入力に応答して、前記第１のコンテナを前記第１の配信チャネルに、前記第２のコンテナを前記第２の配信チャネルに公開するステップと、
前記第１の配信チャネル及び前記第２の配信チャネルのためのメタデータ要件を決定するステップと、
前記第１の配信チャネル及び前記第２の配信チャネルのためのメタデータ要件を決定することに応答して、
前記ユーザから前記第１の配信チャネルに固有のメタデータ情報を受信するステップと、
前記メタデータ情報の検証が不成功に終わるステップと、
前記メタデータ情報の検証が不成功に終わることに応答して、前記第１の配信チャネルに固有のさらなるメタデータ情報について前記ユーザに促すステップと、
を含む方法をコンピューティング装置に実行させるコンピュータプログラム。
【請求項８】
コンピューティング装置により実施される方法であって、
ビデオを受信するステップと、
ユーザからのユーザ入力に応答して、前記ビデオが第１の配信チャネル及び第２の配信チャネルに配信され、しかし第３の配信チャネルに配信されないべきであると決定するステップと、
前記ビデオについての第１の特性及び第２の特性を決定するステップであり、前記第１の特性及び前記第２の特性は、ファイルタイプ、コンテナタイプ、ビデオ継続時間、ビデオ解像度、フレームレート、ビデオ圧縮ビットレート及びオーディオ圧縮ビットレートを含む群から選択される、ステップと、
前記ユーザ入力に応答して、前記ビデオを前記第１の配信チャネルに対応する第１のフォーマットを有するトランスコードされた第１のビデオにトランスコードし、前記ビデオを前記第２の配信チャネルに対応する第２のフォーマットを有するトランスコードされた第２のビデオにトランスコードし、前記第１のフォーマットは前記第２のフォーマットに等しくなく、前記ビデオを前記第３の配信チャネルに対応する第３のフォーマットを有するトランスコードされた第３のビデオにトランスコードしないステップと、
前記ユーザ入力に応答して、第１のメタデータと前記トランスコードされた第１のビデオとを第１のコンテナに、第２のメタデータと前記トランスコードされた第２のビデオとを第２のコンテナにパッケージ化するステップと、
前記ユーザ入力に応答して、前記第１のコンテナを前記第１の配信チャネルに、前記第２のコンテナを前記第２の配信チャネルに公開するステップと、
前記第１の配信チャネル及び前記第２の配信チャネルのためのメタデータ要件を決定するステップと、
前記第１の配信チャネル及び前記第２の配信チャネルのためのメタデータ要件を決定することに応答して、
前記ユーザから前記第１の配信チャネルに固有のメタデータ情報を受信するステップと、
前記メタデータ情報の検証が不成功に終わるステップと、
前記メタデータ情報の検証が不成功に終わることに応答して、前記第１の配信チャネルに固有のさらなるメタデータ情報について前記ユーザに促すステップと、
を含む方法。
【発明の詳細な説明】
【背景技術】
【０００１】
配信プラットフォーム（例えば、ＹｏｕＴｕｂｅ（登録商標）、Ｎｅｔｆｌｉｘ（登録商標）及びｉＴｕｎｅｓ（登録商標））の成功は、ビデオコンテンツの消費をより簡素化している。しかしながら、コンテンツを生み出し、配信し、かつ／あるいは管理することは、複雑なプロセスのままである。同時に、ビデオの偏在は、ソーシャルネットワーク、モバイル装置などを使用する新たに出現した視聴者を十分に生かすようにビデオストラテジを具現化する（又は強化する）ための編成を必要とする。連続的にシフトする技術的要件との組み合わせで、成功裏にビデオを作成し配信するプロセスは、既存のブランドと新規参入者とに関して同様に、人及びテクノロジーの投資を必要とする。ビデオの「ライフサイクル」を管理することは、複雑である。
【図面の簡単な説明】
【０００２】
本発明の実施形態の特徴及び利点は、別記の請求項、下記の１又は複数の例示的な実施形態の詳細な説明、及び対応する図面から明らかになるであろう。
【図１】本発明の一実施形態に係る公開ワークフロー図を含む。
【図２】本発明の一実施形態に係る更新ワークフロー図を含む。
【図３】本発明の一実施形態に係る非公開ワークフロー図を含む。
【図４】本発明の一実施形態に係る統計収集ワークフロー図を含む。
【図５】本発明の一実施形態に係るより詳細な承認ワークフロー図を含む。
【図６】本発明の一実施形態に係るより詳細なメタデータ検証ワークフロー図を含む。
【図７】本発明の一実施形態に係るより詳細なトランスコードワークフロー図を含む。
【図８】本発明の一実施形態に係るより詳細な送信ワークフロー図を含む。
【図９】本発明の一実施形態におけるグラフィカルユーザインターフェース（ＧＵＩ）を含む。
【図１０】本発明の一実施形態に係る配信ワークフロー図を含む。
【図１１】本発明の実施形態を実施するシステムを含む。
【発明を実施するための形態】
【０００３】
下記の説明において多数の具体的な詳細が明記されるが、本発明の実施形態はこうした具体的な詳細の範囲外で実施されてもよい。周知の回路、構造及び技法は、本説明の理解を分かりにくくしないように、詳細には示されていない。「一実施形態」「様々な実施形態」などは、そのように説明される（１又は複数の）実施形態が特定の特徴、構造又は特性を含み得るが、必ずしもあらゆる実施形態が上記特徴、構造又は特性を含みはしないことを示す。いくつかの実施形態が、他の実施形態のために説明された特徴のうちいくつか又はすべてを有してもよく、あるいはひとつも有さなくてもよい。「第１」「第２」「第３」などは、共通のオブジェクトを説明し、同様のオブジェクトの異なるインスタンスが参照されていることを示す。こうした形容詞は、そのように説明されるオブジェクトが時間的に、空間的に、ランキングで又は任意の他の態様でのいずれかにおいて所与の順にあるべきであることを示すものではない。「接続される」は、要素が互いに直接物理的又は電気的に接触していることを意味することがあり、「結合される」は、要素が互いに協同し又は相互作用するが、上記要素が直接物理的又は電気的に接触してもしなくてもよいことを意味することがある。また、同様の又同一の番号が、異なる図における同一の又は同様の部分を指定することに使用されることがあるが、このようにすることは、同様の又は同一の番号を含むすべての図が単一の又は同一の実施形態を構成することを意味するものではない。本明細書において、場合により、説明が一度にいくつかの異なる図をカバーする。図面はコンポーネントを含み、明りょうさのために、最上位の値が、該コンポーネントを含む図を表す（例えば、要素３ＸＸは図３に見られるであろうし、要素４ＸＸは図４に見られるであろう）。
【０００４】
本発明の一実施形態は、「ビデオライフサイクル」などの管理を簡素化する。一実施形態が、ビデオ公開、ビデオを更新すること、ビデオを非公開にすること、ビデオに関する読み出し又は統計、ビデオを処理するための承認、ビデオの検証、ビデオメタデータ処理、ビデオトランスコーディング（transcoding）及び／又はビデオ送信などの技術的ステップを抽象化することによってビデオ公開プロセスを効率化する１又は複数のモジュールを含む。
【０００５】
ビデオライフサイクル
本発明の一実施形態の観点から、ビデオライフサイクルは、少なくとも４つのプロセス、すなわち、公開すること、更新すること、非公開にすること及び統計読み出しを含む。上記プロセスのすべては、１又は複数の「宛先（destinations）」、すなわち、前述のプロセスのいくつかの組み合わせを可能にする配信プラットフォームと連携して生じる。（例えば、いくつかの宛先は、公開すること及び非公開にすることのみサポートし、統計を報告せず、あるいはエンドユーザがビデオを更新することを可能にしない。）一実施形態は、プロセスの１つを始める前、あるいはいったんプロセスが起動されると、あるいは双方において、ユーザが１又は複数の宛先を承認することを可能にする。
【０００６】
公開プロセスは、「ビデオファイル」が利用可能であるときに始まる。このファイルは、カメラ又は製作物からの編集されていないカットと同様に簡素であってもよく、共同制作者又はクライアントからの承認を必要とする仕上げられた編集であってもよく、配信の準備ができている最終版であってもよく、あるいはこれらの間の段階のいずれかのものであってもよい。
【０００７】
クライアントアプリケーション又はエンドユーザは、様々な方法で本発明の一実施形態に対してビデオファイルを提供することができる。ビデオファイルは、ハードドライブ、ＤＶＤ−ＲＯＭ又はテープフォーマットなどの物理記憶媒体を介して送付されてよい。別法として、ビデオファイルは、ＨＴＴＰ又はＦＴＰなどの他のネットワークプロトコルを介してネットワークを通じて送付されてもよい。最後、実施形態が上記ファイルに対してローカルアクセスを有する場合、ローカルファイルパスが提供されてもよい。
【０００８】
この時点では、一実施形態において、ビデオは、個々の宛先プラットフォームに従ってパッケージ化される（packaged）。エンドユーザが選択する各宛先について、一実施形態は、適切な次ステップを決定することができる。ビデオは、１又は複数の必要とされるフォーマットへのトランスコーディングを必要とすることがある。ビデオファイルは、ネットワーク（例えば、ファイルトランスファープロトコル（ＦＴＰ）、コンテンツデリバリネットワーク（ＣＤＮ）、アプリケーションプログラムインターフェース（ＡＰＩ）など）を介した送付を必要としてもよい。最後、末端の宛先は、末端のプロバイダにより命じられる様々な順列においてビデオメタデータを投入されてもよい。このプロセスは、変化するＡＰＩ要件、ビデオサポートギャップ及びネットワークの失敗に対して細心の注意を必要とする。
【０００９】
いったんビデオが１又は複数の宛先プラットフォームに対して公開されると、メタデータとビデオファイル自体との双方が、更新の対象となってよい。例えば、エンドユーザがビデオのタイトルを変更しようと決めた場合、一実施形態は、メタデータを再パッケージ化し、それを送付仕様を介して再提出する。この実施形態は、各宛先プラットフォームについての更新可能リソースのリストを管理することができ、上記リストは、エンドユーザのアカウントタイプに基づいて可変であってよい。
【００１０】
多くの宛先プラットフォームは、ビデオ及びユーザインタラクションに関する統計を追跡する。例えば、ＹｏｕＴｕｂｅ（登録商標）は、ビデオが再生されるたびに「ビュー」カウントを増加させる。こうした宛先のいくつかは、上記統計を読み出す方法を含む（ＡＰＩ又は月々の報告など）。こうした場合、一実施形態は、上記統計を読み出し、宛先にわたって値を正規化することができ、したがって、一実施形態のエンドユーザは、ユーザインタラクションを比較し、どの宛先が十分に（又は不十分に）機能しているかを判定することができる。特定メトリックの重要度は、各ユーザの成功の解釈に依存してもよい。
【００１１】
最終的に、ビデオは、（コンテンツにおけるエラーか、あるいは単にもはや関連しないことに起因して、）宛先プラットフォームからの削除を必要とすることがある。一実施形態は、ビデオをサポートする任意の宛先からビデオを削除すること（又は、「非公開にすること」）をサポートすることができる。
【００１２】
ビデオは、アーカイバルを必要としてもよい。いかなる将来の配信も従前の技術的な制限に起因して損害を受けないように、とり得る最高のビデオ品質が保持されることをユーザは所望することがある。例えば、Ａｐｐｌｅ（登録商標）の“ＡｐｐｌｅＴＶ（登録商標）”製品の第一世代は、垂直解像度７２０画素（７２０Ｐとして知られる）を有するプログレッシブビデオだけサポートしていた。しかしながら、ＡｐｐｌｅＴＶ（登録商標）の最近のバージョンは、１０８０画素（１０８０Ｐとして知られる）の高さの解像度をサポートしている。元のビデオ品質を記憶することによって、一実施形態は、最高品質を同様に将来届けることができることを確保する。
【００１３】
システム抽象化
一実施形態は、様々な下層のシステムを抽象化する。ＡｐｐｌｅＴＶ（登録商標）の例で参照されたとおり、ビデオ送付要件は頻繁に変わる。５年前に支配的であったフォーマット及び標準が、将来あまり関係なくなる可能性があり（例えば、ＦＬＶ、Ｆｌａｓｈ（登録商標）、ＲＴＭＰ）、新しい配信フォーマット及びプラットフォームが頻繁に出現する（例えば、ＭＰＥＧ  ＤＡＳＨ、ＨＬＳ、ＯＴＴなど）。ゆえに、一実施形態は、下層のシステム要件の知識を有することなく簡素化された操作（「公開」又は「更新」など）をエンドユーザが容易に実行することを可能にする抽象化されたリソースのシステム（「ビデオ」又は「宛先」など）を双方提供する。例えば、一実施形態は、ビデオファイルをトランスコードすること（あるビデオを再圧縮し、別のものへ再パッケージ化すること）を、ビデオを公開すること又は更新することの「暗黙」部として隠すことを選んでもよい。
【００１４】
一実施形態は、リソースの分離されたインターフェースになり、該インターフェースは、ストレージレイヤ（例えば、ストレージレイヤは、クラウドストレージ、ＦＴＰ送付、ＣＤＮなどのテクノロジーを活用することができる）から、公開レイヤ（公開レイヤは、すべてのサポートされるプラットフォーム要件、ＡＰＩ、トランスコード（transcode）詳細を、並列な一連の宛先へと抽象化することができる）に対して、統計レイヤ（統計レイヤは、各プラットフォームから視聴者メトリックを集計することができる）に対して、ビデオライフサイクルを簡素化する。この抽象化は、ＨＴＴＰベースのＲＥＳＴ  ＡＰＩなどのネットワークテクノロジーを利用することによって、グラフィカルアプリケーションを介したエンドユーザかクライアントアプリケーションのためのプログラム的インターフェースかのいずれかに対して表面化してよい。
【００１５】
公開ワークフロー
図１は、本発明の一実施形態におけるビデオを宛先に公開するプロセスワークフローを含む。ブロック１００において、エンドユーザ（又は、ＡＰＩのクライアントアプリケーション）は、ビデオファイルを一実施形態に提供する。このファイルは、宛先による使用のためにトランスコードされるべき高品質マスタファイルであってよい。エンドユーザは、クライアントアプリケーションに対するローカルアクセスを通じて、あるいはＨＴＴＰベースのＡＰＩ又はＦＴＰなどのネットワークプロトコルを介して、あるいはデジタルテープフォーマットを介してでさえ、ファイルを提供することができる。
【００１６】
ブロック１０１において、一実施形態は、ビデオの（１又は複数の）特性を決定する。例えば、一実施形態は、アップロードされたビデオから情報を抽出し、データベース又は他のファイルベースの記憶システムに記憶する。上記情報は、限定ではなく例えば、ファイルタイプ（例えば、ＭＰＥＧ−４  Ｐａｒｔ１４コンテナ）、ビデオコーデック（例えば、Ｈ．２６４／ＡＶＣ、ＭＰＥＧ２など）、ビデオコーデックプロファイル（例えば、メイン、ベースラインなど）、オーディオコーデック（例えば、ＭＰ３、ＰＣＭなど）、ビデオ継続時間、ビデオ解像度、フレームレート、ビデオ圧縮ビットレート、オーディオ圧縮ビットレート、並びに公開及び他のプロセスに必要な他の情報を含む群から選択される特性に関係してよい。
【００１７】
ブロック１０２において、一実施形態は、公開に使用すべき１又は複数の宛先に関してエンドユーザ又はクライアントアプリケーションに促すことができる。クライアントアプリケーションにおいて、これは、１又は複数のグラフィカルユーザインターフェースワークフローであってよく、該ワークフローにおいて、ユーザは、１又は複数の所望される宛先を「クリック」し、あるいはその他の方法で示すことができる。ブロック１０３において、選択された各宛先についての公開要件が、データベース、構成ファイル、外部ＡＰＩ又は他の場所から必要に応じて収集されてよい。上記要件は、これらに限定されないが、（１又は複数の）トランスコードフォーマット、メタデータ要件、認証要件などを含んでよい。
【００１８】
ブロック１０４−１０７は、（１又は複数の）選択された宛先が承認されているかを判定する。１又は複数の宛先が承認されておらず、かつ承認されることが可能である場合、承認プロセスが利用される。プロセス１０４は、宛先が現在承認されているかを判定し、このプロセスは、外部ＡＰＩと対照してクレデンシャルを検証すること、データベースから情報を抽出することによってスケジュールされた認証タスクの結果を確認すること、又は宛先の能力によって決定される他の方法を含んでよい。プロセス１０５は、プロセス１０４の結果を解析し、エンドユーザ又はクライアントアプリケーションが承認する能力があることを確保する（例えば、外部の宛先の認証サービスが応答する、アプリケーション制限に到達していない、など）。（プロセス１０６のさらなる詳細については承認ワークフローを参照。）ブロック１０７において、承認の結果が確認される。承認プロセスが成功した場合、一実施形態は、ブロック１０８に続くことができる。そうでない場合、一実施形態は、要求を失敗するか、あるいはエンドユーザ又はクライアントアプリケーションに承認を再度試みるように促すかのいずれかをすることができる。
【００１９】
ブロック１０８は、ビデオのためのメタデータ（ブロック１０１において収集されたものとエンドユーザ又はクライアントアプリケーションから収集されたものとの双方）が提供され、検証されたことを確保する。（さらなる詳細については検証ワークフローを参照。）このステップに必要なメタデータ要件は、ブロック１０３から収集されている。いったんメタデータが各々のビデオと宛先との組み合わせについて検証されると、該メタデータは、送信に使用される準備ができている。
【００２０】
ブロック１０９は、末端の宛先により必要とされるいかなるトランスコーディングをもカプセル化する。広範な入力ビデオファイルをサポートする宛先もあれば（ＹｏｕＴｕｂｅ（登録商標）など）、特定のコンテナフォーマット、ビデオ及びオーディオコーデック、解像度、並びにビデオ圧縮の他の態様を必要とする宛先もある。例えば、Ｈｕｌｕ（登録商標）は、ＨＤマテリアルに関して、３０−５０ＭｂｐｓのＭＰＥＧ−２ビデオストリームを含むＭＰＥＧ−２プログラムストリームファイルを現在必要とする。ユーザ又はクライアントアプリケーションが、１又は複数の宛先のトランスコード要件にマッチしないビデオファイルを提供した場合、送信へと進む前に、追加のトランスコードが生成されてよい。（さらなる詳細についてはトランスコードワークフローを参照。）トランスコーディングの後、結果的なファイルは、送信だけでなく将来の使用のためにも記憶されてよい。
【００２１】
いったん（１又は複数の）適切なトランスコードが生成されると、一実施形態は、ブロック１１０−１１５を採用して、エンドユーザ又はクライアントアプリケーションからの追加的な必要ファイルを要求することができる。いくつかの宛先は、これらに限定されないが、サムネイル画像、代替言語のオーディオストリーム又は文書を含む補足ファイルを必要とする。ブロック１１０は、ブロック１０３において収集された宛先要件を調査し、追加ファイルが必要かを判定する。さらに、一実施形態は、ユーザに促すことなく特定の必要な追加ファイルを生成することができてもよい。
【００２２】
ユーザ又はクライアントアプリケーションが（１又は複数の）ファイルを提供すべきである場合、ブロック１１１は、グラフィカルインターフェースを備えるユーザ又は必要ファイルを提供する方法を備えるクライアントアプリケーションに促すことを含む。一実施形態は、いったん追加ファイルに対するアクセスを有すると、該ファイルを分析し、アーカイバル及び変換のために記憶することができる（ブロック１１２）。元のファイルを記憶することは、高品質ビデオマスタを記憶することと同様の目的を果たし、任意の将来の変換が、より高い品質のソースファイルからの恩恵を受ける。
【００２３】
ビデオファイルと同様に、宛先は、追加ファイルが送信され得る前に、該追加ファイルを変換する必要があることがある（これは、ブロック１１３において判定される）。この変換は、これらに限定されないが、画像コンバージョン（ＰＮＧからＪＰＥＧへ）、オーディオ圧縮（ＰＣＭからＭＰ３へ）又は文書コンバージョン（Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄ（登録商標）からＰＤＦへ）を含む。上記が必要とされる場合、ブロック１１４は、１又は複数の変換されたファイルをもたらすべきである。一実施形態は、サードパーティの変換ツール又は独自ソフトウェアライブラリを利用して上記変換を行うことができる。
【００２４】
一実施形態は、ブロック１１５において、変換されたファイルを将来の使用のために記憶することができる。一実施形態は、ローカルのファイル記憶装置、ネットワークストレージ、Ａｍａｚｏｎ（登録商標）、Ｒａｃｋｓｐａｃｅ（登録商標）などのクラウドストレージパートナーを利用してもよい。上記ファイルは、任意の将来の公開又は更新操作が既存の変換されたファイルを使用することができるように、宛先及びビデオを参照して記憶されてよい。
【００２５】
ブロック１１６は、パッケージ化及び送信ステップを識別する。各宛先は、（１又は複数の）ファイル及びメタデータを送信する一意的な方法を提供することができる。さらに、各ビデオのためのメタデータは、送信され得る前に、各宛先のために変換される必要があってもよい。（さらなる詳細については送信ワークフローを参照。）送信が成功した場合、一実施形態は、ブロック１１７において、宛先から返された任意の情報を集め、記憶することができる。上記情報は、更新、統計読み出し及び非公開などの将来のプロセスに使用されてもよい。
【００２６】
一実施形態は、エンドユーザ又はクライアントアプリケーションに対する任意の成功情報と、公開を完成させるために必要であり得る任意の最終的なステップとを送信することができる。例えば、Ａｐｐｌｅ（登録商標）  ｉＴｕｎｅｓ（登録商標）ポッドキャストは、ｉＴｕｎｅｓ（登録商標）クライアントアプリケーションにおけるフィード提出を必要とする。一実施形態は、最終的なステップとしてｉＴｕｎｅｓストアに提出するためのフィードＵＲＬをエンドユーザに提供することができる。
【００２７】
公開操作のうちいずれかの部分が（ブロック１０５及び１０７により示されるように）失敗した場合、一実施形態は、ブロック１１８において公開操作を拒否し、ブロック１１７と同様のシリアライゼーション及び送信ストラテジを使用してクライアントアプリケーション又はエンドユーザに失敗情報を返すことができる。
【００２８】
更新ワークフロー
図２は、本発明の一実施形態における１又は複数の宛先において公開されたビデオを更新するプロセスを含む。ブロック２０１において、エンドユーザ又はクライアントアプリケーションはビデオの態様を更新し、該更新は、これらに限定されないが、ビデオマスタファイルを置換すること、ビデオメタデータを更新すること、又は追加ファイルを置換することを含む。
【００２９】
ブロック２０２において、ブロック１０３と同様に、一実施形態は、すべての宛先要件をデータベース、構成などから収集することができる。さらに、この実施形態は、公開されたビデオの現在のステータスを判定するために、公開された情報（外部の宛先ｉｄ、ＵＲＬなど）を収集してもよい。
【００３０】
宛先と相互作用するために承認が必要とされる場合、ブロック２０３−２０６は、１０４−１０７と同様の認証ワークフローを実行する。ブロック２０３は、ブロック２０２からの要件をチェックすることによって宛先のために承認が必要とされることを確認し、ネットワークＡＰＩを（宛先がＡＰＩを提供する場合に）介して宛先と通信して事前操作からの記憶済みクレデンシャルをチェックしてもよい。いくつかの宛先がクレデンシャルを無効化し、サービスを無効にし得るため、ブロック２０４は、宛先が実際に承認され得ることを確認する。ブロック２０５は、必要に応じてエンドユーザ又はクライアントアプリケーションからのクレデンシャルを要求し、承認を行う。（さらなる詳細については承認ワークフローを参照。）承認が失敗した場合、一実施形態は更新要求を拒否することができ、あるいは、ユーザが別の承認試行に関して促されてもよい。
【００３１】
ブロック２０７は、１０８と同様の検証ワークフローを実行する。一実施形態は、ブロック２０７を実施して、ビデオメタデータ又は宛先要件のいずれかにおけるいかなる変更も更新プロセスを無効化しないことを確保する（さらなる詳細については検証プロセスを参照）。
【００３２】
ブロック２０８により判定されたときにビデオファイルが変更されていた場合（これは、ファイルコンテンツを比較すること、事前に記憶された値をデータベースから読み出すことなどによって達成することができる）、あるいは、宛先のためのトランスコード要件が変更されていた場合、（再）トランスコーディングが必要とされてもよい。ブロック２０９及び２１０は、宛先のための（１又は複数の）トランスコードを更新するワークフローを識別する。いくつかの宛先は、ビデオコンテンツの置換をサポートしない（ＹｏｕＴｕｂｅ（登録商標）など）が、ブロック２１０を行う宛先に関しては、ブロック１０９と同じトランスコードワークフローを参照する（さらなる詳細についてはトランスコードワークフローを参照）。
【００３３】
宛先が新たな追加ファイルを必要とする場合、あるいは事前に提供された任意の追加ファイルが変更された場合（ブロック２０８と同様の方法でブロック２１１によって判定される）、ブロック２１２−２１４は、ブロック１１３−１１５と同様のファイル変換ワークフローを定める。ブロック２１２によって判定されたとおり、ファイル変換が宛先構成によって許可されると仮定すると、ブロック２１３は、エンドユーザ又はクライアントアプリケーションによって提供された後に一実施形態によって記憶されたいかなる元ファイルをも変換する。ブロック２１４は、送信及び将来の使用のために、任意の（再）変換されたファイルを記憶する。ファイルが変更されず、かつ宛先がいかなる追加ファイルも必要としない場合、一実施形態は、公開プロセスの間に記憶された変換されたファイルを使用してもよい。
【００３４】
いったん更新されたメタデータが検証され、宛先が承認され、ファイルが宛先構成に従って準備されると、ブロック２１５は、ブロック１１６と同様の送信ワークフローを実行する。（さらなる詳細については送信ワークフローを参照。）１つの差は、宛先のＡＰＩ又はサービスエンドポイント上の更新インターフェースが、公開操作とは異なる操作を必要とすることであり得る。例えば、宛先がＨＴＴＰベースのＲＥＳＴ  ＡＰＩを提供する場合、最初の公開操作は、ＰＯＳＴ要求がリソースコンテナに提出される（submitted）ことを必要とした可能性があり、更新操作は、上記ＰＯＳＴ要求によって返されるリソースＵＲＬに対してＰＵＴ要求が提出されることを必要とし得る。さらに、メタデータが、更新操作のために、公開操作のためとは異なるパッケージ構造を必要としてもよい。
【００３５】
更新プロセスが成功した場合、ブロック２１６は、一実施形態が任意の更新された情報を将来のプロセスにおける使用のためにデータベース又は他のファイルベースのストレージに記憶することができると識別する。いずれかの追加ステップがある場合、一実施形態は、その情報をエンドユーザ又はクライアントアプリケーションに返すことができる。
【００３６】
更新プロセスが（ブロック２０４及び２０６によって示されるように）いずれかのポイントで失敗した場合、一実施形態は、ブロック２１７において、更新プロセスを拒否し、エンドユーザ又はクライアントアプリケーションに失敗情報を返すことができる。
【００３７】
非公開ワークフロー
図３は、本発明の一実施形態における宛先からビデオを削除する方法を含む。ブロック３０１において、エンドユーザ又はクライアントアプリケーションは、ビデオを宛先から削除する（又は「非公開にする」）ことを要求する。ブロック３０２は、１０３及び２０２と同様に、要求された操作を行うために必要とされるであろう任意の宛先構成又はビデオメタデータをデータベース、構成ファイルなどから収集する。
【００３８】
宛先が、非公開にすることに関して承認を必要とする場合、ブロック３０３−３０６は、ブロック２０３−２０６及び１０４−１０７と同様の操作を行う。（さらなる詳細については承認ワークフローを参照。）承認が必要とされるが失敗した場合、一実施形態は、削除要求を拒否することができ、あるいは、さらなる承認試行に関してエンドユーザ又はクライアントアプリケーションに促すことができる。
【００３９】
ブロック３０７は、宛先エンドポイント又はＡＰＩが削除要求を知らされ得るポイントを識別する。各宛先は、１又は複数の通知方法を必要としてもよい。例えば、宛先が（ＹｏｕＴｕｂｅ（登録商標）又はＶｉｍｅｏ（登録商標）のように）ＨＴＴＰベースのＡＰＩを採用する場合、ＤＥＬＥＴＥ要求がリソースＵＲＬに対して発行されてよい。しかしながら、宛先がｉＴｕｎｅｓ（登録商標）  Ｐｏｄｃａｓｔのようにフィードを監視する場合、一実施形態は、フィードからエントリを削除することのみ必要とされることがあり、宛先は、次にフィードを解析したときに該宛先からビデオを削除することになる。削除情報を送信する（１又は複数の）具体的な方法が、ブロック３０２の間に収集される。
【００４０】
多くの宛先がユーザインターフェース又はＡＰＩを提供するため、本発明の一実施形態は、ビデオが宛先から既に削除された場合を受動的に継承することを選んでもよい。例えば、エンドユーザがＹｏｕＴｕｂｅ（登録商標）にログインし、ビデオを削除し、それから一実施形態に削除要求を発行する場合、この実施形態は、ビデオがＹｏｕＴｕｂｅ（登録商標）上になお存在するかを確認することができる。ビデオが存在しない場合、この実施形態は、宛先におけるビデオ「消失」に起因してエラーを上げることに代わって、削除の次の段階に進むことができる。
【００４１】
ブロック３０８−３１０は、公開及び更新プロセスにわたって作成された任意の特別な（extra）リソースを削除するために実施されてよい。例えば、一実施形態がブロック１０９、１１２、１１５、２１０又は２１４においてファイルを記憶した場合、該ファイルは、記憶装置から削除される必要があり得る。ブロック３０８は、上記ファイルがビデオ又は宛先にわたって共有されているかを判定することを含む。（例えば、２つの宛先が同じトランスコードを共有しているが、ビデオは１つの宛先からしか削除されていない場合、このトランスコードは削除される必要がない可能性がある。）いったんファイルが削除に関して確認されると、一実施形態は、実際の削除プロセスのためのブロック３０９に進むことができる。記憶の方法に依存して、このステップは、ローカルの記憶装置からファイルを単純に削除すること、又は、Ａｍａｚｏｎ（登録商標）のＳ３若しくはＲａｃｋｓｐａｃｅ（登録商標）のＣｌｏｕｄＦｉｌｅｓなどのクラウドストレージソリューションからファイルを削除するための一連のネットワーク操作を含んでよい。さらに、ブロック３１０において、一実施形態は、構成ファイル又はデータベースなどの記憶装置から必要に応じて任意の公開された情報を削除することができる。
【００４２】
削除操作が成功した場合、一実施形態は、ブロック３１１において、成功情報又は任意の追加ステップ（必要な場合）をエンドユーザ又はクライアントアプリケーションに送ることができる。そうでない場合、一実施形態は、ブロック３１２において、削除操作を拒否し、失敗情報をエンドユーザ又はクライアントアプリケーションに送ることができる。
【００４３】
統計読み出しワークフロー
図４００は、本発明の一実施形態における宛先から統計を読み出す方法を含む。ブロック４０１において、エンドユーザ又はクライアントアプリケーションが、公開されたビデオについての統計を要求する。この要求は、時間範囲、特定の統計（「再生」又は「感想」など）、地理的データ、関与（engagement）データ、又は必要とされる追加のメトリックを含んでよい。さらに、上記要求は、ＧＵＩにおけるインターフェース要素を通してパラメータを選択すること、ＨＴＴＰベースのＡＰＩを通じてＪＳＯＮシリアライズパラメータを提供することなどによって起動されてもよい。
【００４４】
ブロック４０２は、３０２、２０２及び１０３と同様に、構成ファイル、データベースなどから宛先構成及びビデオ情報を抽出する。宛先構成は、認証の方法（これらに限定されないが、ＯＡｕｔｈ、ＢａｓｉｃＡｕｔｈ又は予め共有されたクレデンシャルを含む）と、宛先によりサポートされる具体的なメトリックとを識別するべきである。さらに、宛先と通信するために必要な任意の情報（ビデオｉｄ又はリソースＵＲＬなど）が収集されてもよい。
【００４５】
ブロック４０３において、一実施形態は、保存されている可能性がある任意の既存の値を検索して、ユーザが要求した値が既に利用可能ではないことを確保することができる。上記値は、ファイル構造において、ｍｅｍｃａｃｈｅｄなどのメモリベースのキャッシュソリューション、ＭｙＳＱＬ（登録商標）などのリレーショナルデータベース、又は任意の他の記憶方法において記憶されてよい。上記値は、エンドユーザ又はクライアントアプリケーションによる事前の統計要求に起因して、あるいは、オフライン又はＵｎｉｘ（登録商標）型オペレーティングシステムにおけるｃｒｏｎジョブなどの定期プロセスの間に読み出されていてもよい。
【００４６】
上記値がシステムに既に存在しない場合、一実施形態は、統計を取得するための２つの主な方法の間で選ぶことができる。ブロック４０４により判定されるとおり、宛先がＡＰＩ又はサービスエンドポイントを提供する場合（このことを一実施形態は宛先構成の中に示すことができる）、一実施形態は承認に進むことができる。ブロック４０５において、宛先が既に承認されているかを（ＡＰＩエンドポイントと対照してクレデンシャルを利用すること、データベースに記憶された事前の検証属性を確認することなどによって）判定した後、ブロック４０６−４０８において、承認が、これまでの操作３０４−３０６、２０４−２０６及び１０５−１０７と同じように進む。（さらなる詳細については承認ワークフローを参照。）いったん承認されると、ブロック４０９−４１０において、所望される値が宛先から要求されてよい。要求の具体的な詳細は、宛先間で変化する。例えば、ＹｏｕＴｕｂｅ（登録商標）はＨＴＴＰベースのＡＰＩを提供し、これにおいて、複数国にわたるビデオ「ビュー」の詳細な内訳を要求し、特定の時間範囲にわたって集計することができる。この結果はＣＳＶとして記憶され、該ＣＳＶはＺＩＰアーカイブにパッケージ化される。上記ＺＩＰアーカイブは、解凍され、それから解析されてもよい。しかしながら、他のプラットフォームは、別の方法を通してビューの合計数のみ提供することがある（Ｊａｖａｓｃｒｉｐｔ（登録商標）起動のブラウザ要求に対するＪＳＯＮ応答など）。一実施形態は、クライアントアプリケーション又はエンドユーザの要求を満たすために、宛先のエンドポイントに対する１又は複数の要求における統計を要求することを選ぶことができる。ブロック４０９は、要求データをＪＳＯＮにシリアライズすること、ＨＴＴＰ要求パッケージを形成することなどを表し、ブロック４１０は、ＡＰＩからの応答の実際の送信及びデシリアライゼーションを表す（戻りのＪＳＯＮを解析すること、（１又は複数の）ＺＩＰアーカイブ内のＣＳＶから値を抽出することなど）。
【００４７】
宛先がＡＰＩを見せておらず、しかし代わって、ブロック４１１において宛先構成を調査することによって判定されるとおり、別の集計を要求する場合、一実施形態は、ブロック４１２−４１４を実施することができる。例えば、ｉＴｕｎｅｓ（登録商標）は、何個のポッドキャストが見られたかを判定する方法を見せてはいない。しかし、一実施形態がＣＤＮ又は他のネットワークサーバを介してトランスコードを果たす場合、ログファイルが存在する可能性があり、該ログファイルは、ファイルがｉＴｕｎｅｓ（登録商標）クライアントを介してダウンロードされた回数を判定するように解析することができる。
【００４８】
データが事前の集計から利用可能ではない場合、集計プロセスが適切な情報を抽出することができるような方法でビデオ情報がパッケージ化されてもよい（ブロック４１２）。いったんパッケージが形成されると、ブロック４１３において、適切な集計プロセスが実行される。例えば、ｉＴｕｎｅｓ（登録商標）ポッドキャストの場合、１又は複数のトランスコードＵＲＬが提供されることがあり、したがって、ブロック４１３におけるログ解析操作は、どのネットワーク要求が「再生」を構成するかを判定することができる。さらに、要求のタイプが分析されてもよく（多くのメディアクライアントがＨＥＡＤ要求を利用してビデオが存在することを確認するためだが、これはユーザがビデオをダウンロードし、あるいは観たことを意味するものではない）、伝送されたバイト数（これは、ビデオのうち何パーセントをユーザが見ることができたかを伝え得る）、（ボット又は他の自動化されたビューアを除外するための）ユーザエージェントなどの要求についての他の属性も分析されてもよい。
【００４９】
要求された値がログファイルなどの別のソースからいったん抽出されていると、一実施形態は、ブロック４１３において、その値を将来の要求のために集計手順の最終部分として記憶することを選ぶことができる。さらに、一実施形態は、統計要求又は集計ワークフロー全体をオフラインのスケジュールされた方法で実行して、エンドユーザ又はクライアントアプリケーションのための統計要求が迅速であることを確保することができる。
【００５０】
データが事前の集計から利用可能である場合（ブロック４１４）、その値は、ブロック４１３において実行された記憶により利用された同じ記憶場所から抽出することができる。
【００５１】
ブロック４１５において、統計は、統計読み出しプロセスから返される値に依存して正規化を必要としてもよい。例えば、ある宛先は、「関与」（ユーザが見たビデオの部分）値をタイムスタンプにおいて提供することができ、別の宛先は、上記値をパーセンテージにおいて提供する。時間ベースの値が、次ステップにおいて集計を実行するためにビデオの既知の継続時間を利用してパーセンテージにコンバートされてもよい。
【００５２】
ブロック４１６において、正規化された値は、提供されたパラメータに従って集計されてもよい。一例において、エンドユーザ又はクライアントアプリケーションは、ある時間範囲にわたる各宛先についてのビューの合計数を要求することができる。ビデオＡが、宛先Ｂにおいて１２ビュー、宛先Ｃの４８ビューを受け、ビデオＤが、宛先Ｂにおいて１０ビューを受け、宛先Ｃにおいてビューを受けなかった場合、これら値は総計されてよく、したがって、この実施形態は、宛先Ｂについての２２ビューと宛先Ｃについての４８ビューとを返す。あるいは、ビューは、ビデオ、時間などごとに集計されてもよい。
【００５３】
一実施形態は、ブロック４１７において、エンドユーザ又はクライアントアプリケーションに値を返すことができる。これは、ＧＵＩアプリケーションにおける視覚的なグラフィカル表現、ＨＴＴＰ  ＡＰＩに対するＪＳＯＮシリアライズ応答、又は必要に応じた他の方法であってよい。
【００５４】
ブロック４０６又は４０８などのいずれかの事前のプロセスによって失敗が示される場合、一実施形態は、ブロック４１８において、統計要求全体を拒否し、失敗情報をクライアントアプリケーション又はエンドユーザに返すことができる。
【００５５】
承認ワークフロー
図５は、本発明の一実施形態のための承認ワークフローを詳述する。承認プロセスのパターンを作るのには標準が役立ち得るが、承認は、複数宛先にわたって大きく変化する。ブロック５０１において、宛先構成と既存の宛先メタデータとを利用して、一実施形態は、エンドユーザ又はクライアントアプリケーションのための最適な承認方法を選択することができる。一般的なＨＴＴＰベースの承認方法は、ＯＡｕｔｈ、ＢａｓｉｃＡｕｔｈ、及び予め共有されたクレデンシャルである。送付メカニズム（ＦＴＰ又は他のＴＣＰベースのシステムなど）に結び付けられた別の承認方法が、宛先によって利用されてもよい。独自の認証方法もまた一般的である。
【００５６】
いったん適切な認証方法が決定されると、ブロック５０２は、追加情報がエンドユーザ又はクライアントアプリケーションから必要とされるかを判定するために、提供された構成及び宛先情報を分析することを必要としてもよい。そうである場合、ブロック５０３は、情報が取得され得る前にエンドユーザが別個の認証サービスを訪れるべきであるかを識別する。これは、ＯＡｕｔｈなどの認証方法において必要とされ、この認証方法において、ユーザは、自身の代わりにアプリケーションが宛先と相互作用することを明示的に許可しなければならない。標準のＯＡｕｔｈ実装において、ユーザは、宛先により提供されるウェブサイトにリダイレクトされなければならず、ゆえに、一実施形態は、ブロック５０４において、ユーザに一時的認証ゲートウェイインターフェースを提供することができる。これは、エンドユーザにサービスを提供して、ＨＴＴＰを通じてあるウェブページに向けることを含み（ブロック５０５）、上記ウェブページは、ロケーションヘッダ又は別のリダイレクト方法を使用して該ユーザを宛先にリダイレクトすることができる（ブロック５０６）。さらに、この一時的サービスは、宛先がユーザを後方の一時的認証ゲートウェイにリダイレクトする場合、成功又は失敗情報を抽出することができてもよい。操作が成功した場合（ブロック５０７で、リダイレクトの間に宛先によって提供される値を調査することによって判定される）、承認試行からのクレデンシャルが、連続使用のために抽出され、記憶されてもよい（ブロック５０８）。
【００５７】
宛先が、ユーザを外部認証サービスに送ることを必要としないが、追加のクレデンシャル（ＢａｓｉｃＡｕｔｈ  ＨＴＴＰサービス又はＦＴＰアカウントのためのユーザ名及びパスワードなど）をなお必要とする場合、一実施形態は、クライアントアプリケーションからのこうしたクレデンシャルを要求することができ、あるいは、投入するためのグラフィカルインターフェースをエンドユーザに提供することができる。例えば、一実施形態は、ブロック５０９において、１又は複数のグラフィカルインターフェースをエンドユーザに提供してクレデンシャルを集めることができ、あるいは、ＨＴＴＰベースのＡＰＩが、この実施形態にクレデンシャルを伝えるようにクライアントアプリケーションに利用可能にされてもよい。ブロック５１０は、エンドユーザが要求されたクレデンシャルを（大抵、グラフィカルインターフェースに）能動的に提供することを表し、ブロック５１１は、グラフィカルインターフェースが一実施形態自体ではなく外部のクライアントアプリケーションにより提供されている場合、クライアントアプリケーションが（ＡＰＩ又は別の方法を介して）該実施形態にクレデンシャルを渡すことを含んでもよい。
【００５８】
外部サービスから又はクライアントアプリケーション／グラフィカルインターフェースからのいずれかで、いったんクレデンシャルが集められると、宛先は、追加の検証ステップを必要としてもよい。このことは、ブロック５１２において、宛先構成又は他の提供される要件を分析することによって判定される。追加検証が必要と考えられる場合、この検証は、ブロック５１３において行われてもよい。例えば、ＯＡｕｔｈ実装は、アプリケーションとのエンドユーザの相互作用に対して非同期的に操作を行うために、永続的なトークンのための一時的アクセスコードを伝送することをしばしば必要とする。ＢａｓｉｃＡｕｔｈにおいて、特別な検証は、単に認証された要求であって、クレデンシャルが妥当であることとアプリケーションが宛先に対して適切な呼び出しを行うことを承認されていることとを確保することができる。
【００５９】
承認又は検証ステップが不成功であった場合（ブロック５１４において、５１３における検証ステップの結果を分析することによって判定される）、実施形態は、承認要求を拒否することができる（ブロック５１５）。これは、グラフィカルアプリケーションにおけるエラーメッセージ、クライアントアプリケーションによるＨＴＴＰベースのＡＰＩ要求に対するＪＳＯＮシリアライズ応答などであってよい。別法として、一実施形態は、別の試行をユーザに提供して宛先を承認することができる。
【００６０】
いったん承認が成功すると、一実施形態は、将来の使用のためにクレデンシャルを記憶することができる（ブロック５１６）。クレデンシャルは、ローカルファイル、データベースなどに記憶されてよい。一実施形態は、これら値を記憶する前に追加的セキュリティのために暗号化することができる。
【００６１】
必要に応じて、承認ワークフローは、ブロック５１７により識別されるとおり、外のプロセス（公開、更新など）による使用のためにクレデンシャルを返すことを必要としてもよい。
【００６２】
メタデータ検証ワークフロー
図６は、本発明の一実施形態におけるメタデータ検証ワークフローを詳述する。宛先は、ビデオが正しく記憶され、表示されることを確保するためにさまざまな順列のメタデータを必要とし、一実施形態は、ユーザエクスペリエンスの容易さとメタデータの宛先承認との双方を確保するように、正規化されたメタデータの検証を必要としてもよい。
【００６３】
ブロック６０１は、一実施形態のこれまでに言及されたプロセス又は他のワークフローのいずれかにより、検証ワークフローの起動を識別する。検証すべきメタデータは（該データは、宛先固有とビデオ固有との双方であってよい）、任意の宛先構成及び要件に加えて、実行すべき検証の（１又は複数の）方法を判定するために提供されてもよい。
【００６４】
ブロック６０２は、公開及び更新操作において収集された宛先構成と提供されたビデオメタデータとの比較を必要とする。このビデオメタデータは、ビデオファイル自体から抽出されていてもよく（例えば、一方法が、メタデータ記憶をサポートする様々なコンテナフォーマットを手段としてよい）、あるいは、グラフィカルインターフェース又はクライアントアプリケーションを通してエンドユーザにより提供されていてもよい。例えば、基本のメタデータ要件は、（これらに限定されないが）ビデオ「タイトル」、「説明」、又は一組の「タグ」若しくは「キーワード」と作者情報とを一般に含む。宛先構成が、実施形態内のタクソノミによって識別される必要なメタデータフィールドの組と任意的なメタデータフィールドの組とを示してもよい。さらに、宛先自体が、メタデータを必要としてもよい。例えば、一実施形態は、ｉＴｕｎｅｓ（登録商標）ポッドキャストを宛先として利用可能にすることができる。ポッドキャストは、タイトル、作成者、１又は複数のカテゴリ、説明、及び他のフィールドを必要とする。
【００６５】
宛先メタデータが妥当でなく、あるいは追加の値を必要とする場合（ブロック６０３により判定される）、一実施形態は、追加クレデンシャルの要求でクライアントアプリケーションに応答し、あるいは宛先構成に基づいてエンドユーザにグラフィカルインターフェースを提供することができる（ブロック６０４）。例えば、宛先構成が、「作者」についての追加メタデータフィールドを示す場合、このことは、その値が「文字列」であるべきことも示し得る。これは、完了するべき適切なインターフェース要素をユーザに対してグラフィカルインターフェースが表示することを可能にする。
【００６６】
いったんクライアントが新しい／更新されたメタデータを提供すると（ブロック６０５）、該メタデータは、ブロック６０６において、宛先構成に従って検証されてよい。例えば、提供された作者が１４８文字の長さであり、ユニコード文字を含み、宛先はユニコードを許可せず、１２７文字未満を求める場合、実施形態は、戻ることによってブロック６０３及び６０４を通して妥当なメタデータを提供する別の機会をクライアントアプリケーション又はエンドユーザに促すことができる。
【００６７】
このプロセスは、すべての宛先メタデータが供給され、妥当になるまで繰り返される。それから、一実施形態は、ビデオメタデータで同様のプロセスを実行することができる（ブロック６０７−６１０）。公開され又は更新されている各ビデオについて、エンドユーザは、（ブロック６０８においてクライアントアプリケーションにより要求され、ブロック６０９においてエンドユーザにより提供されるとおり、）宛先構成が期待するすべての必要なビデオメタデータを提供することができる。さらに、宛先メタデータと同様に、ブロック６１０において、提供される各値は、値がいったん宛先のエンドポイントに送信されると拒否されなくなることを確保するために、宛先の構成と対照して検証されてもよい。
【００６８】
一実施形態は、すべてのビデオメタデータを簡素化されたモデルの正規化されたメタデータに制約して、最も簡素なユーザエクスペリエンスを確保することができる。このことは、システムにおけるタイトルなしが、すべての宛先にわたって最も短い許されるタイトルより長くなり得ることを要するであろうが、検証により必要とされる訂正の発生も低減するであろう。
【００６９】
いったんすべての宛先及びビデオメタデータが検証されていると、一実施形態は、ブロック６１１により識別されるとおり、その値を将来の使用のためにローカルファイル、データベースなどに記憶することができる。このことは、宛先についてのメタデータ要件が変化し、あるいはエンドユーザがメタデータを変更しない限り、将来の更新プロセスを簡素化する。
【００７０】
それから、一実施形態は、ブロック６１２において、これまでのオペレーションと同様のシリアライゼーション及び送信ストラテジに従うことによって、検証されたメタデータを他のプロセス（公開又は更新など）に返すことができる。
【００７１】
トランスコードワークフロー
図７は、本発明の一実施形態におけるビデオをトランスコードするプロセスを詳述する。トランスコードは、配信におけるより技術的なプロセスの１つであり、同時に、多くのエンドユーザが具体的なビデオフォーマット及び属性に関する知識を欠くことに起因して、抽象化についての強力な候補である。後に、一実施形態は、トランスコードすることを、エンドユーザがプロセスに関する判断を行う必要がないようなシステムの暗黙的態様にすることができる。
【００７２】
ブロック７００は、一実施形態が、宛先のためのトランスコード要件を宛先の構成から抽出することができることを示す。この構成は、許容トランスコードを示す属性閾値の配列を含むべきであり、上記属性は、これらに限定されないが、コンテナ又はカプセル化フォーマット、ファイルサイズ、ビデオ圧縮フォーマット、ビデオ継続時間、ビデオ解像度、フレームレート、ビデオ圧縮プロファイル、ビデオ圧縮ビットレート、スキャンタイプ、オーディオ圧縮フォーマット、オーディオサンプルレート、オーディオ圧縮ビットレート、オーディオチャネルなどを含む。
【００７３】
トランスコードされるビデオファイルに関する情報を抽出した後、一実施形態は、ブロック７０１において、ビデオファイルがトランスコードされることができることを確保することができる。ビデオファイルは、様々な理由でトランスコードされることができない可能性があり、すなわち、ファイルの品質が必要なトランスコードのいずれに対してもあまりに低い、ビデオファイルが必要な（１又は複数の）オーディオトラックを消失している、実施形態により利用されるトランスコードソフトウェアがビデオを読むことができない、あまりに多くのビデオ又はオーディオトラックが存在する、などである。様々なアプリケーション（ｍｅｄｉａｉｎｆｏ又はｆｆｍｐｅｇなど）が、宛先のための特定トランスコードプロファイルに対するその適用性を判定するように、ファイルからメディアメタデータを抽出する能力を提供している。ビデオファイルがトランスコードされることができない場合、一実施形態は、トランスコード要求を拒否することができる（ブロック７０２）。
【００７４】
宛先により必要とされるあらゆるトランスコードについて（これは、ブロック７０３において、宛先要件又は他の提供される構成を解析することによって判定することができる）、一実施形態は、元のビデオを処理してどのパラメータをトランスコードソフトウェアに提供すべきかを判定することができる。各トランスコードは、トランスコード「テンプレート」に対応し、該テンプレートは、最終的なトランスコードが準拠すべき特定の属性を識別する。ブロック７０４において、上記テンプレートの各々は、宛先要件をまた再度解析することによって、編集され（compiled）てもよい。ブロック７０５において、プライマリ（primary）ビデオトラックが元のメディアファイルから抽出され、あるいは流され（streamed）てよく、ブロック７０６において、上記ビデオトラックは、トランスコードされるべきか否かを判定するためにトランスコードテンプレートと比較されてよい。例えば、ビデオファイルがＨ．２６４ビデオトラックで、１９２０×１０８０の解像度で、１０Ｍｂｐｓのビットレート及び３０ｆｐｓのプログレッシブフレームレートにおいて提供され、しかしトランスコードテンプレートは１８２０×７２０の解像度を有するＨ．２６４ビデオトラックを必要とする場合、ビデオトラックは、テンプレートの仕様にトランスコードされなければならない。しかしながら、宛先が、１９２０×１０８０のＨ．２６４を許す第２のトランスコードテンプレートを有する場合、ビデオトラックは、第２のテンプレートのために、トランスコードされなくてもよい。一実施形態のための宛先構成が、特定の値に代わって、ビットレート又はフレームレート閾値、解像度についての許容範囲などを定義してもよい。多くの場合、特に、宛先がプレイバックに関して特定のハードウェア環境に依存する場合（Ａｐｐｌｅ（登録商標）のＡｐｐｌｅＴＶ（登録商標）など）、トランスコードテンプレート構成にマッチしないたった一つの属性が、トランスコードすることを必要とする。
【００７５】
ビデオトラックのトランスコードが必要とされる場合、一実施形態は、利用されている特定のトランスコードソフトウェアのための新しいトランスコード要件をパッケージ化することができる。トランスコードテンプレートの要件に基づいて、特定のトランスコードソフトウェアが同様に必要とされてもよい。宛先とほぼ同様に、種々のトランスコードアプリケーションが、新しいトランスコードを要求するための様々な方法を有する。ネットワークベースのＡＰＩを見せるトランスコードアプリケーションもあれば、指示が引数を介して実行ファイルに提供される実行可能バイナリであるトランスコードアプリケーションもあれば、共有フォルダを利用して事前に構成されたトランスコードプロファイルに基づいてトランスコードを起動するトランスコードアプリケーションもある。一実施形態は、最も多種多様なソースファイル及びトランスコードテンプレートを処理するように、様々なトランスコードソリューションを統合することを選ぶことができる。ブロック７０７の結果は、トランスコードテンプレート仕様に準拠するビデオトラックであるべきである。
【００７６】
トランスコードが必要とされない場合、ブロック７０８において、ビデオトラック情報がコピーされる。このことは、オーディオ及びビデオを独立してトランスコードすることを可能にし、最終的なファイルは、最後のステップとして「多重化をやり直される（remuxed）」（個々のオーディオ及びビデオトラックが単一のファイルに結合される）ことになる。
【００７７】
いったんビデオトラックが生成されると、同様のプロセスが（１又は複数の）オーディオトラックに対して採用されてもよい。トランスコードテンプレートに基づいて、オーディオトラックが抽出され又は流され（ブロック７０９）、それから分析され、トランスコードテンプレート要件と比較されてトランスコードが必要であるかを確かめられる（ブロック７１０）。属性はかなり異なり得るが（オーディオサンプルレート、チャネルの数、オーディオ圧縮フォーマット、オーディオ圧縮ビットレートなど）、プロセスは同じである。すなわち、オーディオトラックがトランスコードテンプレート要件にマッチしない場合、トランスコード命令は、実施形態により利用されているトランスコードソフトウェアのためにパッケージ化されてよく、宛先のトランスコードテンプレート要件に準拠する新しいオーディオトラックが生成される（ブロック７１１）。そうでない場合、ブロック７１２において、適切な（１又は複数の）オーディオトラックが、これまでのステップからのビデオトラックと結合するためにコピーされる。
【００７８】
ブロック７１３において、ビデオトラック及びオーディオトラックは、トランスコードテンプレートにより示されるカプセル化フォーマットを利用して単一のファイルに結合される。このファイルは、ＭＰＥＧ−４  Ｐａｒｔ１４ファイル、又はＭＰＥＧ−２プログラムストリーム、ＷｅｂＭコンテナファイルなどであってよい。
【００７９】
いったんファイルが生成されていると、ファイルを宛先が正しく利用することができることを確保するように、追加のステップが必要であってもよい（ブロック７１４において宛先構成を調査することによって判定される）。例えば、ＭＰＥＧ−４ファイルは、ＨＴＴＰプログレッシブストリーミング（フィードベースの宛先又はウェブプレーヤにおいて頻繁に使用される）を対象とし、ビデオファイルインデックス情報（“ｍｏｏｖ”アトムに入っている）は、ビデオファイルがダウンロードを終える前に再生を始めることができるように、ファイルの先頭付近に移動されなければならない。ファイルが完成と見なされる前に、ブロック７１５において、上記及び他の操作が必要とされてもよい。
【００８０】
いったんトランスコードが完成されると、該トランスコードは記憶されてもよい（ブロック７１６）。一実施形態は、将来におけるより迅速な更新操作のためにトランスコードを記憶することができる。さらに、いくつかの宛先がトランスコードテンプレートを共有してもよい。すなわち、トランスコードが記憶され、ビデオが同じトランスコードテンプレートを必要とする宛先に公開される場合、トランスコードワークフロー全体が回避され、既存のトランスコードが代わって使用されてもよい。トランスコードに加えて、一実施形態は、ブロック７１７において、トランスコードパラメータと、フィードなどの他の環境において使用され得るファイルサイズなどの任意のさらなるメタデータとを記憶することができる。
【００８１】
すべてのトランスコードが生成された後、ブロック７１８において、一実施形態は、外のプロセスに、（１又は複数の）トランスコードの場所と任意のトランスコードパラメータ又は追加のメタデータとを返すことができる。
【００８２】
送信ワークフロー
図８は、本発明の一実施形態における宛先送信ワークフローを詳述する。公開要求を送信すること又は既存のビデオを更新することは、様々なプロトコル及び宛先要件と相互作用することを必要とし、エンドユーザ及びクライアントアプリケーションのためのリソースにわたってハイレベルの抽象化を維持すると同時に特定の送信ロジックをカプセル化することを含む。
【００８３】
メタデータ及びファイルが宛先に対する送信の準備ができたとき、一実施形態は、ブロック８０１において、メタデータを宛先固有の言語に変換することができる。例えば、ＹｏｕＴｕｂｅ（登録商標）、Ｂｌｉｐ（登録商標）及びＤａｉｌｙＭｏｔｉｏｎ（登録商標）は、固有のカテゴリ体系を各々維持する。一実施形態は、ビデオに対する正規化されたカテゴリ選択を、宛先によりサポートされる特定のカテゴリに翻訳することができ、したがって、“Ａｕｔｏｍｏｔｉｖｅ”などの汎用的なカテゴリは、Ｂｌｉｐ（登録商標）においてカテゴリ番号“２９”に、ＹｏｕＴｕｂｅ（登録商標）において“Ａｕｔｏｓ＆Ｖｅｈｉｃｌｅｓ”になる。
【００８４】
各宛先は、変換されたメタデータ及びファイルを送信する１又は複数の方法を必要としてもよい。宛先がＡＰＩを提供する場合（ブロック８０２において、宛先構成を分析することによって判定される）、特定のＡＰＩ操作が適切な順序において行われなければならない。例えば、ビデオをＨＴＴＰ  ＡＰＩに提出することは、最初、セッションベースのトークンを用いてクレデンシャルを交換することを必要とし得る（ブロック８０３）。これは、クレデンシャルをＵＲＬエンコードされた形式の値として提供する単純なＰＯＳＴ操作であってもよい。いったんトークンが取得されていると、各ＨＴＴＰ要求は、ヘッダにおいてかＵＲＬの一部としてかのいずれかで、トークンを利用しなければならない。宛先は、１又は複数のトランスコードされたビデオファイルのバイトをアップロードするためにＰＵＴ要求を必要としてもよい。いったん（１又は複数の）ビデオファイルがアップロードされていると、宛先は、該宛先において上記ビデオを表す一意ｉｄを返してもよい。それから、さらなるＰＯＳＴ要求が、「タイトル」、「説明」、「タグ」及び「カテゴリ」の値を有するＪＳＯＮとしてメタデータをシリアライズすることによってメタデータを更新することに使用されてもよい。このプロセスを通して、提出されるメタデータのシリアライゼーション（ブロック８０４）とシリアライズされた及び／又は生のトランスコードされたビデオデータの送信（ブロック８０５）との双方が行われる。
【００８５】
ブロック８０６は、送信されたメタデータを宛先のＡＰＩが受け入れるかを判定する。この判定は、ＨＴＴＰサービスのステータスコード（例えば、２００は成功操作をしばしば示す）、応答ボディ（この中で、シリアライズされた成功／失敗情報を伝えてもよい）を確認すること、ＨＴＴＰコールバックを（一実施形態により生成されるウェブサービスを通して）受け入れること、又は他の方法を含んでもよい。送信が成功した場合、応答情報は、将来の更新、非公開及び統計読み出し操作のために実施形態によって記憶されてもよい（ブロック８０７）。
【００８６】
宛先が、パッケージ化されたファイル、例えば、（１又は複数の）トランスコード、サムネイル画像、及びＸＭＬのシリアライズされたメタデータなどのＺＩＰアーカイブの送付を必要とする場合（ブロック８０８において判定される）、一実施形態は、関連する送信プロセスを行うことができる。ブロック８０９において、最終的なパッケージ化されたコンテンツを提出するのに必要な任意のクレデンシャルが、これまでの承認ステップからか、あるいはエンドユーザ又はクライアントアプリケーションに促すことによってかのいずれかで収集されてよい。本例において、ブロック８０１において提供されるメタデータは、ＸＭＬファイルを生成するよう変換されてよく、該ＸＭＬファイルは、必要に応じて、トランスコードされたビデオ及び任意の追加ファイルと共に圧縮されてよい（ブロック８１０）。最後、宛先のために提供されるクレデンシャルを利用することによって、最終的なパッケージ化されたコンテンツが宛先に提出されてよい（ブロック８１１）。このファイル送付は、ＦＴＰ又はＨＴＴＰなどのプロトコルを通じたものであってよく、ＦＴＰの場合、クレデンシャルはユーザ名、パスワード及びＦＴＰホストであろうし、ＨＴＴＰの場合、ＯＡｕｔｈ又はＢａｓｉｃＡｕｔｈクレデンシャルが利用されてよい。最後、物理ハードドライブなどの別の送付方法が必要とされてもよく、これには、宛先ドライブが適切な宛先に送られる前に、パッケージ化されたファイルと任意の追加的なマニフェストファイルとを該ドライブにコピーすることを含む。
【００８７】
パッケージ化されたファイルが正しく送付されたと判定されることができる場合（ブロック８１２）、一実施形態は、必要に応じて、送信要求を失敗するか、あるいは送信方法を処理し続けるかのいずれかをすることができる。例えば、宛先のＦＴＰサーバがＺＩＰアーカイブの送信失敗を報告する場合、一実施形態は、いかなる追加の送信操作も中止し、要求を拒否することを選ぶことができる。別法として、アーカイブが成功裏にコピーされた場合、一実施形態は、送信操作を通しで処理し続けることができる。
【００８８】
宛先が、ウェブサイト又はＲＳＳフィードなどのホスト型（hosted）エンドポイントを必要とする場合（ブロック８１３）、一実施形態は、コンテンツをホストするウェブサービスを実施してもよい。このウェブサービスは、ＰＨＰ、Ｒｕｂｙ、Ｊａｖａ、ＨＴＭＬ、Ｊａｖａｓｃｒｉｐｔなどの様々な言語及びテクノロジーにおいて実装されてよい。上記テクノロジーを利用することによって、一実施形態は、メタデータを、ブロック８０１において判定された宛先固有の言語から、ウェブサービスのための必要な構造に翻訳することができる。例えば、標準ＲＳＳフィードは、＜ｐｕｂＤａｔｅ＞要素を大抵実装しており、該要素は、ＲＦＣ８２２に従って「公開された」日付及び時間を表示すべきである。一実施形態は、元の公開日付及び時刻を単純なタイムスタンプとして記憶していることがあり、この場合、該日付及び時刻が、フィードにおいて利用され得る前にコンバートされてもよい。それから、選択される特定のテクノロジーが、必要とされるＲＳＳの「特色」によって判定されるとおり、変換されたメタデータを適切なＸＭＬへとフォーマットを整え（format）てもよい（ブロック８１４）。
【００８９】
メタデータのフォーマットを整えることに加えて、ホスト型エンドポイントは、送付されているトランスコードの連続的な送付及びアーカイバルを確保するために、ＣＤＮ又はクラウドストレージなどの外部サービスを必要としてもよい（ブロック８１５）。ブロック８１６において、フォーマットを整えられたメタデータ（例えば、最終的なＲＳＳファイル又はウェブページ）が、宛先により判定されるとおり、適切なプロトコル（ＨＴＴＰ、ＳＳＬ上のＨＴＴＰなど）を通じて送信されてよい。Ａｐａｃｈｅ、ＩＩＳ（登録商標）及び他のＨＴＴＰサーバなどのさらなるソフトウェアが、ウェブサービスコンポーネントを送信するために様々なキャパシティにおいて使用されてよい。
【００９０】
いったん宛先のＡＰＩが通知され、パッケージ化されたファイルが送付され、かつ／あるいはホスト型エンドポイントが構成されてサービスを提供されていると、一実施形態は、公開、非公開又は統計読み出しなどの将来の操作を容易にするように、公開された情報を記憶することができる（ブロック８１７）。公開操作が成功しなかった場合（無効な認証クレデンシャル、無効なメタデータ、ネットワークの問題など）、ブロック８１９において、送信要求は失敗してよい。そうでない場合、一実施形態は、ブロック８１８において、宛先ＡＰＩ又は他の送信ステップから読み出される成功送信情報（宛先についての一意ビデオｉｄ、ビデオリソースＵＲＬなど）を返すことができる。
【００９１】
配信フロー
図１０は、本発明の一実施形態におけるコンテンツ配信の方法を含む。プロセス１０００において、少なくとも１つのマシン可読媒体（例えば、単一の物理的なメモリモジュールに含まれる、分散コンピューティングシステムにおいて複数の物理的なメモリモジュールに散在する、など）が、コンピューティング装置上で実行されると以下に説明される方法をコンピューティング装置に実行させる命令を含む。
【００９２】
ブロック１００５において、コンピューティング装置（例えば、デスクトップ、サーバ、ノートブック、ウルトラブック、ラップトップ、携帯電話、スマートフォン、分散コンピューティングクラスタなど）は、ビデオを受信する。一実施形態は、ビデオを第１、第２及び第３の配信チャネルに配信する選択肢をユーザに同時に提供するＧＵＩの単一インスタンス（すなわち、単一のページ）を表示することができる。例えば、図９において、ＧＵＩ９００は、６つの異なるチャネル、すなわち、チャネル９０５（ＹｏｕＴｕｂｅ（登録商標））、９０６（Ｂｌｉｎｋｘ（登録商標））、９０７（Ｂｏｘｅｅ（登録商標））、９０８（ｈｕｌｕ（登録商標））、９０９（Ｒｏｋｕ（登録商標））、９１０（Ｓｏｎｙ  Ｂｒａｖｉａ（登録商標））のためのグラフィック要素の部分を含む。ＧＵＩ９００を介して供給されるユーザ入力に応答して（例えば、ユーザは配信チャネルを「クリックし」、あるいはその他の方法で選択する）、一実施形態は、例えば、ビデオが第１及び第２の配信チャネル９０５、９０６に配信され、しかし第３の配信チャネル９０７に配信されないべきかを判定する。
【００９３】
一実施形態において、ブロック１０１０は、ビデオについての第１及び第２の特性を決定する。例えば、一実施形態は、アップロードされたビデオから情報を抽出し、記憶する。この情報が、第１及び第２の特性に関係してよく、該特性は、限定ではなく例えば、ファイルタイプ（ＭＰＥＧ４（ＨＤ）、Ｗｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ（ＨＤ）、Ａｐｐｌｅ  ＰｒｏＲｅｓ（ＳＤ）など）、コンテナタイプ、ビデオ継続時間、ビデオ解像度、フレームレート、ビデオ圧縮ビットレート及びオーディオ圧縮ビットレートを含む群から選択される。第１及び第２の特性は、メタデータを分析することによって決定されてもよく（しかし、必ずしも必要ではない）、該メタデータは、ファイルについてのメタデータなどであり、必ずしもビデオのコンテンツではない。第１及び第２の特性は、ビデオタイトル、キーワード、説明及びビデオカテゴリなどの、正規化された方法（ＡＰＩユーザ入力）において保証されたメタデータによって決定されてもよい（しかし、必ずしも必要ではない）。特性は、ビデオのプリイメージ（preimage）（例えば、ビデオのビデオコンテンツのうち選択されたフレーム）に関係してもよい。
【００９４】
ブロック１０１０は、抽出された／分析された情報に基づいてビデオを検査してプラットフォーム（例えば、プラットフォームをサポートするプロセッサベースシステムの代表例については図１１を参照）がビデオをサポートするかを判定することを含んでよい。例えば、ＧＵＩ９００は、ビデオを第１、第２及び第３の配信チャネル（９０５、９０６、９０７）と第４の配信チャネル（９０８）（例えば、ｈｕｌｕ（登録商標））とに配信する選択肢をユーザに同時に提供することができる。ＧＵＩ９００を介して供給されるユーザ入力に応答して、一実施形態は、ユーザがビデオを第４の配信チャネルに配信することを望むと決定することができる。しかしながら、プラットフォームは、ビデオに関して決定された特性のうち１つを分析することに応じて、上記ビデオを第４の配信チャネル９０８に対応する第４のフォーマットを有するトランスコードされた第４のビデオへとトランスコードしないと決定してもよい。例えば、ビデオのファイルフォーマット又は圧縮スキームが、上記ビデオをチャネル９０８に適合するようにトランスコードすることができないようなものである可能性がある。
【００９５】
いかなる不適合性も救済するために、プラットフォームは、事前に選択されたチャネル（９０５、９０６）で空所又は問題を塞ぐようにユーザからのさらなる情報を求めてもよい。例えば、一実施形態におけるプロセスにおけるこのポイントにおいて、プラットフォームは、ビデオファイル、ビデオに関する情報（例えば、ファイルと共にアップロードされたメタデータ、ファイルがアップロードされた後にファイルから導出されたメタデータ、及び、ファイルと共にアップロードされ、あるいはファイルから導出された他のデータ）を含む。例えば、ＧＵＩ９００を介して供給されるユーザ入力に応じて、プラットフォームは（チャネル９０５、９０６が所望されるが他のチャネルは所望されないことを知っているため）、どの第１の追加チャネル情報が第１のチャネル９０５のために必要であるかと、どの第２のチャネル情報が第２のチャネル９０６のために必要であるかとを判定してもよい。第１のチャネル情報は、第２のチャネル情報と等しくなくてもよい。例えば、第１のチャネル情報は、ユーザクレデンシャル（例えば、ユーザ名、パスワード）、フィードタイトル、ファイルポインタ及びビデオからの代表フレームのうち１つを含んでよい。チャネル９０６は、ファイルポインタを必要としないことがあり、ゆえに、チャネル９０６だけが選択されている場合、プラットフォームはこうした情報のためにユーザを煩わせないであろう。
【００９６】
本動作例において（ユーザはチャネル９０５、９０６を介してビデオを配信することを選んでいる）、実施形態は、ビデオがプラットフォームに対して互換性がある（あるいは、キャパシティ又はポテンシャルを有する）と判定することができる。したがって、ブロック１０２０において（ブロック１０１５は以下でさらに論じられる）、プラットフォームは、トランスコードすることがなお必要とされるかを判定する。例えば、アップロードされたビデオは、チャネル９０５、９０６のいずれについてもトランスコードする必要がない可能性があり、このビデオは、上記チャネルに対して単にパススルーされる（passed  through）ことがある（ブロック１０２５）。しかしながら、トランスコードすることが必要とされる場合、ブロック１０３０において、このトランスコーディングが生じる。プラットフォームは、ビデオを第１の配信チャネル（チャネル９０５）に対応する第１のフォーマットを有するトランスコードされた第１のビデオへとトランスコードする。プラットフォームは、さらに、ビデオを第２の配信チャネル（チャネル９０６）に対応する第２のフォーマットを有するトランスコードされた第２のビデオへとトランスコードする。第１のフォーマット（例えば、ＭＰＥＧ−２）は、第２のフォーマット（例えば、Ｈ．２６４）と等しくなくてもよい。実施形態は、（例えば）不適合性に基づいて、あるいはユーザがそのチャネルへの配信を望まないという理由で、ビデオを第３の配信チャネル（９０７）に対応する第３のフォーマットを有するトランスコードされた第３のビデオへとトランスコードしないことを選ぶことができる。このことは、すべてのあり得るチャネルフォーマットへの総当たりのトランスコーディングよりもむしろ労力を節約する。
【００９７】
チャネル９０５、９０６のためのトランスコーディングは、「トランスコードキュー」を利用してもよい。ビデオは、エンベロープ（envelope）変更（例えば、Ｗｉｎｄｏｗｓメディアファイルを、ＹｏｕＴｕｂｅ／チャネル９０５に適した新しいオーディオ及び新しいビデオを有するエンベロープに変更する）を介して、フォーマット０から（チャネル９０５に対応する）フォーマット１にトランスコードされてよい。このトランスコーディングは、所望されるチャネルに対応するトランスコーダ（例えば、Ｒｈｏｚｅｔ（登録商標））を介して扱われるビットレートを調整することをさらに含んでもよい。チャネル９０６に関して、ビデオは、Ｈ．２６４からＦＦＭＰＥＧ又はＭＰＥＧ−２へのエンベロープ変更を介して、フォーマット０から（チャネル９０６に対応する）フォーマット２にトランスコードされてよい。
【００９８】
ユーザにより選択されたチャネルに対するトランスコーディングの後、ブロック１０３５は、第１のメタデータ（例えば、ファイルのためのキーワード、ビデオの説明、ビデオの圧縮レート、ビデオの再生時間の継続時間）とトランスコードされた第１のビデオとを第１のコンテナへと、第２のメタデータとトランスコードされた第２のビデオとを第２のコンテナへとパッケージ化し、第１のコンテナを第１のチャネルに、第２のコンテナを第２のチャネルに公開する（ブロック１０４０）。公開は、チャネルごとに異なるものになってよい。例えば、チャネル９０５について、プラットフォームはファイルを単に供給してよく、しかしチャネル９０６（又はいくつかの他のチャネル）について、ファイルはフィードを介して利用可能にされることができ、チャネル９０７については、プラットフォームはファイルをホストするＵＲＬを単に提供すればよい（しかし、チャネルに直接ファイルを供給しなくてよい）。
【００９９】
ブロック１０４５において、上記方法は、公開される第１のコンテナのための第１のメトリックデータと、公開される第２のコンテナのための第２のメトリックデータとを受信することを含み、これにおいて、第１のメトリックデータは、第２のメトリックデータとは別様にフォーマットを整えられる。上記メトリックデータは、ヒット数／平日（チャネル９０５により供給され、これは、ヒット数／１日のうちの時間を供給しない）とヒット数／１日のうちの時間（チャネル９０６により供給され、これは、ヒット数／平日を供給しない）となどの統計を含んでよい。他のメトリックデータには、例えば、再生の平均継続時間を含んでよい（例えば、ユーザが平均してビデオのうち１０％を観ているか、あるいは、その平均は９０％に近いか）。プロセスにおいて先に、プラットフォームがビデオをチャネルにアップロードした後ずっとチャネルに「つながれた（tethered）」ままとなることを可能にするように、プラットフォームがチャネル９０５、９０６の各々についてのユーザのＩＤ（例えば、アカウントクレデンシャル）に関してユーザに尋ねている（ブロック１０１０）ため、上記データにアクセスすることが可能であり得る。
【０１００】
ブロック１０５０は、第１及び第２のメトリックデータを、第１及び第２のメトリックデータの双方に対応する共通の正規化されたデータへと正規化することを含む。例えば、チャネル９０５がヒット数／平日を有し、チャネル９０６がヒット数／１日のうちの時間を有することをユーザに示すだけに代わって、プラットフォームは、チャネル９０５とのより良い比較のためにチャネル９０６についての１日あたりのヒット数を示すようにデータを正規化してよい。このデータを用いて、ユーザは、各チャネルについての有効性（例えば、視聴者が大幅にチャネル９０５をより好むと思われる場合、なぜチャネル９０６向けにビデオのフォーマットを整えることに時間を費やすのか）に基づいて、１つのチャネルのための（しかし、他のチャネル向けでない）ビデオを開発することが意味をなすと判断することができる。
【０１０１】
さらに、プラットフォームはチャネル９０５、９０６につながれたままであるため、ユーザは、配信されるビデオを容易に更新し、あるいは管理することができる。例えば、ブロック１０１０において取得されるＩＤ情報を使用して、ユーザは、上記チャネルにアクセスしてビデオを更新すること（例えば、従前のビデオに５分のビデオコンテンツを追加する、検索のためのキーワードなどのビデオに関連するデータを更新する）、ビデオを削除することなどができる。
【０１０２】
次に、ブロック１０１５に着目する。ブロック１０１５において、上記方法は、第１、第２及び第３のプロセッサベースシステム（例えば、サーバ、ワークステーションなど）を含むハードウェア群から、ユーザ入力に応答して、第１及び第２のプロセッサベースシステムを選択し、しかし第３のプロセッサベースシステムは選択しない。例えば、ユーザは、単一の短いビデオファイルをアップロードしていて、このビデオをチャネル９０５にアップロードすることを単に望む。このことは、比較的わずかしかコンピューティングリソースを必要としない可能性があり、したがって、たった１つのプロセッサベースシステムがこの製作物を扱うように配置されてもよい。しかしながら、別の例において、ユーザは、３０本のビデオ（各ファイルが数メガバイトのデータを含む）を含む販売トレーニングビデオシリーズをアップロードしたい大企業であり得、該ビデオは８つの異なるチャネルに配信される必要があり得る。このことは、はるかに多くのコンピュータリソースを要する可能性がある。したがって、プラットフォームは、この負荷を認識し、より大量のリソースを選択してビデオの製作物を扱うことができる。上記の大部分は並行して生じてよく、したがってユーザは、ビデオをチャネル９０５に公開すると同時に該ビデオ（又は別のビデオ）をチャネル９０６に公開する。こうして、一実施形態において、上記方法は、ビデオを第２のプロセッサベースシステムを介してトランスコードされた第２のビデオにトランスコードすることと並行してビデオを第１のプロセッサベースシステムを介してトランスコードされた第１のビデオにトランスコードすることを含む。上記トランスコードは同時に生じてもよい。
【０１０３】
こうして、一実施形態は、マルチフォーマットビデオ及びメタデータ取り入れ、マルチフォーマットエンコード及びマルチプラットフォーム公開のための単一の構成可能プロセスを、プロセスを起動し、追跡するユーザインターフェースと共に含む。本願実施形態は、ビデオ及びメタデータがウェブサイト、ＩＰテレビシステム、モバイル装置などに対して正しくレンダリングされず、手動のステップを通して各ファイルを別個に扱うための時間やお金をビデオ所有者に費やさせるという問題を解決する。さらに、一実施形態において、フォーマットを整えることがクラウドにおいて行われるため、時間節約及び並行マシン処理において大きな利点があり、ビデオ所有者がビデオ及びメタデータのフォーマットを整えるために行わなければならないハードウェア及びソフトウェア投資を劇的に低減させる。
【０１０４】
一実施形態は、（１）協働、（２）編成及びパッケージ化、（３）公開及び配信、（４）及び／又は（４）つながれた測定及び分析などの操作を扱うプラットフォームを提供する。
【０１０５】
（１）協働に関して、ビデオを作成することは協働的な努力であり得る。ビデオアセットは複数組織にわたって散在することがある。プラットフォームの一実施形態は、チームが一緒に作業し、アクティビティ（例えば、ビデオ編集、オーディオファイル、メタデータ及びグラフィック）を追跡するための共有空間を提供する。プラットフォームは、プロセスを正規化し、アセットを１つの場所に維持することを可能にする。プラットフォームはさらに、複数の作成者及びベンダから、直接ユーザに「仮想スタジオ」として見えるものへと、様々なフォーマット及びコーデックスキームを取り入れるための協調及び正規化を可能にする。ユーザは、自身のブラウザ、ＦＴＰなどを通して単にアップロードする。ビデオコンテンツは、多数の変わる（moving）部分を有する複合体であってもよい。一実施形態は、ビデオ取り入れに対してリアルタイムのインテリジェントな検証を適用して、ビデオの正しい部分すべてが損なわれていないことを確保し、理想的なアセット未満のものがプラットフォームのビデオライブラリに入ることを防止する。ユーザは、作成者、パートナー及び／又は共同作業者のうち選ばれたグループとビデオを共有することができる。ユーザは、上記共有を、電子メールリンクを介してプライベートに、ユーザの自身のサイトにおける組み込み可能プレーヤを介して、あるいは（プラットフォームによりホストされる）「プライベート上映ルーム」を介して行うことができる。プライベート上映空間においてホストされる間、ユーザは、同僚、顧客又はパートナーと、ラフカットを通して繰り返すことができる。ユーザは、アクセス及び許可を管理することができ、ゆえにユーザは、ビデオがリリースされる前に該ビデオが必要とする承認を得ることができる。
【０１０６】
（２）編成及びパッケージ化に関して、いったんビデオが作成されると、プラットフォームの一実施形態は、ユーザのファイルのための編成されたホーム（例えば、ファイルがユーザのチーム／パートナーに対して利用可能でありアクセス可能であるところの単一の場所）を作成する。
【０１０７】
ビデオメタデータは非常に多様であり、プラットフォームの一実施形態は、各宛先（すなわちチャネル）についての正確な情報及び画像を捕捉し、マッピングすることによって、メタデータのカオスを簡素化する。複数の宛先／チャネルにわたるビデオ発見のためにメタデータを管理し、最適化することは、時間を消費し、複雑である。しかし、プラットフォームは、ユーザが１つの場所において効率的に管理し、更新し、テストすることを可能にする。一実施形態は、ユーザがビデオを持続的なバケット（すなわち「コレクション」）に編成することを可能にする。
【０１０８】
（３）公開及び配信に関して、ビデオを公開し、配信することは、フィードだけよりも多くを必要とする。単一のビデオプレーヤ内におけるワークフローを管理することは十分挑戦的であり得るが、複数のビデオ、複数の宛先並びに多くの種々のフォーマット及びメタデータ要件を混合物に追加することは、さらなる複雑性を加える。一実施形態は、オンライン及びオフラインで、公開及び配信プロセスからのタスク及び複雑性の負荷をなくす（off-load）のに役立つ。
【０１０９】
一実施形態は、速く、多くの宛先ポイントに高品質ビデオを送付する。この実施形態は、多くのオープンの宛先に自動接続することができ、既存の関係がない他の配信パートナーに送付する能力がある。
【０１１０】
多くの宛先における最適なパフォーマンスのためにビデオをトランスコードすることは、エンコードソフトウェア及びコーデック要件に一定の変更を必要としてもよい。一実施形態は、クラウドを介して、需要に対してビデオを送付する。品質、スピード及び冗長性が、この実施形態のための成功要因である。一実施形態は、ＣＤＮと共に動作して、ビデオが迅速に送付されることを確保する。
【０１１１】
一実施形態は、様々なモバイル装置、ウェブブラウザ又はソーシャルメディアサイトにビデオを送付する。この実施形態は、（例えば）ＨＴＭＬ５、Ｆｌａｓｈ又はＱｕｉｃｋＴｉｍｅ間で動的に変わる（moving）、エンドポイントに適合するインテリジェントなプレーヤを提供する。上記プレーヤは、ユーザの区分、ウェブサイト設計、広告ネットワーク（ad  network）又はＣＤＮにさえマッチするようにカスタマイズされてよい。
【０１１２】
（４）つながれた測定及び分析に関して、１つの宛先だけにおける１つのビデオだけの成功を測定することは、負担となり得る。複数のビデオ及び複数の宛先を種々の統計と共に追加すると、その負担は増加する。一実施形態は、複数の宛先／チャネルにわたってビデオ統計（メトリック）を集計する。この実施形態は、公開された宛先にわたってビデオについてのコンテンツパフォーマンス統計を集め、集計することによって、メトリック追跡の負担を小さくする。こうすることで、ユーザは、ビデオのロード・トゥ・プレイ（load-to-play）からのコンバージョンと、最も多く見られ又は共有されたビデオと、より好まれる時間の長さとを含め、自身のビデオ投資が如何に機能しているかを理解することが可能となる。使いやすい報告インターフェースが、ユーザがビューを最適化し、結果をエクスポートすることを可能にする。ユーザは、宛先のパフォーマンス又はビデオのコレクションを比較して、ビジネスストラテジをより良くマッピングすることができる。
【０１１３】
本願実施形態は、多くの種々のシステムタイプにおいて実施されてよい。次に図１１を参照して、本発明の一実施形態に従うシステム（例えば、サーバ、デスクトップ、分散クラスタ、タブレット、ノートブック、モバイルコンピューティング装置、スマートフォン、パーソナルデジタルアシスタント）のブロック図を示す。マルチプロセッサシステム１１００は、ポイントツーポイント相互接続システムであり、ポイントツーポイント相互接続１１５０を介して結合される第１のプロセッサ１１７０及び第２のプロセッサ１１８０を含む。プロセッサ１１７０及び１１８０の各々は、マルチコアプロセッサであってもよい。用語「プロセッサ」は、レジスタ及び／又はメモリからの電子データを処理して該電子データを他の電子データに変換する任意の装置又は装置の部分を示すことがあり、上記他の電子データは、レジスタ及び／又はメモリに記憶されてもよい。第１のプロセッサ１１７０は、メモリコントローラハブ（ＭＣＨ）及びポイントツーポイント（Ｐ−Ｐ）インターフェースを含んでもよい。同様にして、第２のプロセッサ１１８０は、ＭＣＨ及びＰ−Ｐインターフェースを含んでもよい。ＭＣＨは、プロセッサをそれぞれのメモリ、すなわちメモリ１１３２とメモリ１１３４とに結合することができ、これらメモリは、それぞれのプロセッサに対してローカルに取り付けられたメインメモリ（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ））の部分であってもよい。第１のプロセッサ１１７０と第２のプロセッサ１１８０とは、それぞれ、Ｐ−Ｐ相互接続を介してチップセット１１９０に結合されてもよい。チップセット１１９０は、Ｐ−Ｐインターフェースを含んでもよい。さらに、チップセット１１９０は、インターフェースを介して第１のバス１１１６に結合されてもよい。様々な入力／出力（Ｉ／Ｏ）装置１１１４が、バスブリッジ１１１８と共に、第１のバス１１１６に結合されてもよく、バスブリッジ１１１８は、第１のバス１１１６を第２のバス１１２０に結合する。様々な装置が第２のバス１１２０に結合されてもよく、例えば、キーボード／マウス１１２２、通信装置１１２６、及びディスクドライブ又は他の大容量記憶装置などのデータ記憶ユニット１１２８を含み、一実施形態において、データ記憶ユニット１１２８はコード１１３０を含んでもよい。コードは、ネットワークなどを介してシステム１１００にメモリ結合されたメモリ１１２８、１１３２、１１３４を含む１又は複数のメモリに含まれてもよい。さらに、オーディオＩ／Ｏ１１２４が第２のバス１１２０に結合されてもよい。
【０１１４】
本願実施形態は、コードにおいて実施されてもよく、命令を記憶させた記憶媒体に記憶されてもよく、記憶媒体は、上記命令を実行するようにシステムをプログラムすることに使用することができる。記憶媒体には、これらに限定されないが、フロッピーディスク、光ディスク、ソリッドステートドライブ（ＳＳＤ）、コンパクトディスク読取専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスク再書き込み可能（ＣＤ−ＲＷ）及び光磁気ディスクを含む任意のタイプのディスク、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、消去可能プログラマブル読取専用メモリ（ＥＰＲＯＭ）、フラッシュメモリ、電気的消去可能プログラマブル読取専用メモリ（ＥＥＰＲＯＭ）、磁気カード若しくは光カードなどの読取専用メモリ（ＲＯＭ）やランダムアクセスメモリ（ＲＡＭ）などの半導体装置、又は電子的命令を記憶することに適した任意の他のタイプの媒体を含んでよい。
【０１１５】
本発明の実施形態は、本明細書において、命令、関数、手順、データ構造、アプリケーションプログラム、構成設定、コードなどのデータを参照して説明されることがある。データがマシンによってアクセスされると、このマシンは、本明細書においてかなり詳細に説明されたとおり、タスクを実行すること、抽象データタイプを定義すること、低レベルハードウェアコンテキストを確立すること及び／又は他の操作を実行することによって応答することができる。データは、揮発性及び／又は不揮発性のデータ記憶装置に記憶されてよい。用語「コード」又は「プログラム」は、アプリケーション、ドライバ、プロセス、ルーチン、メソッド、モジュール及びサブプログラムを含む広範囲のコンポーネント及び構築物をカバーし、処理システムによって実行されると所望の１又は複数の操作を実行する命令の任意の集合を示すことがある。さらに、別の実施形態が、開示された操作の全体よりも少数を用いるプロセス、追加操作を用いるプロセス、別のシーケンスにおける同じ操作を用いるプロセス、及び、本明細書に開示された個々の操作が組み合わせられ、細分され、あるいはその他の方法で変えられたプロセスを含んでもよい。一実施形態において、用語の制御ロジックの使用は、トランジスタ、レジスタ又は他のハードウェアなどのハードウェアを含み、例えば、プログラマブルロジックデバイス（１１３５）などである。しかしながら、別の実施形態において、ロジックは、ソフトウェア又はコード（１１３１）をさらに含む。こうしたロジックは、ハードウェアに統合されてもよく、例えば、ファームウェア又はマイクロコード（１１３６）などである。プロセッサ又はコントローラは、その分野において知られる様々な制御ロジックのうち任意のものを表すことが意図された制御ロジックを含んでよく、そのようなものとして、マイクロプロセッサ、マイクロコントローラ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）などとして実装されてもよい。
【０１１６】
モジュールは、本明細書において使用されるとき、任意のハードウェア、ソフトウェア、ファームウェア又はこれらの組み合わせを示す。しばしば、別個として図示されるモジュール境界は、一般に変化し、オーバーラップする可能性がある。例えば、第１及び第２のモジュールが、いくつかの独立したハードウェア、ソフトウェア又はファームウェアを保有する可能性があると同時に、ハードウェア、ソフトウェア、ファームウェア又はこれらの組み合わせを共有してもよい。一実施形態において、用語のロジックの使用は、トランジスタ、レジスタ又は他のハードウェアなどのハードウェアを含み、例えば、プログラマブルロジックデバイスなどである。しかしながら、別の実施形態において、ロジックは、ハードウェアに統合されたソフトウェア又はコードをさらに含み、例えば、ファームウェア又はマイクロコードである。
【０１１７】
一般に、本願において、特に別記の請求項（例えば、別記の請求項の主文）において使用される用語は、「開放」用語として一般に意図されることが当業者に理解されるであろう（例えば、用語「含める」は「これらに限定されないが含める」として解釈されるべきであり、用語「有する」は「少なくとも有する」として解釈されるべきであり、用語「含む」は「これらに限定されないが含む」として解釈されるべきである、など）。さらに、指定数の前置きを付けられたクレーム列挙が意図される場合、こうした意図は請求項に明示的に列挙されることになり、こうした列挙が無い場合、上記のような意図は存在しないことが当業者に理解されるであろう。例えば、理解の助けとして、別記の請求項は、クレーム列挙に前置きを付けるように前置きフレーズ「少なくとも１つの」及び「１又は複数の」の使用を含むことがある。しかしながら、こうしたフレーズの使用は、クレームが前置きフレーズ「１又は複数の」又は「少なくとも１つの」と「一の」などの不定冠詞とを含む場合でさえ、不定冠詞「一の」によるクレーム列挙の前置きが、こうした前置きを付けられたクレーム列挙を含む特定クレームを上記列挙を１つだけ含む発明に限定することを示すものとみなされるべきではない（例えば、「一の」は、通常、「少なくとも１つの」又は「１又は複数の」を意味すると解釈されるべきである）。同じことが、クレーム列挙に前置きを付けるように用いられる定冠詞の使用にも当てはまる。さらに、指定数の前置きを付けられたクレーム列挙が明示的に列挙される場合でさえ、こうした列挙は少なくとも列挙された数を意味すると通常解釈されるべきであることを当業者は認識するであろう（例えば、「２つの列挙」のありのままの列挙は、他の修飾子なしに、少なくとも２つの列挙、あるいは２又はそれ以上の列挙を通常意味する）。「Ａ、Ｂ又はＣなどのうち少なくとも１つ」に似た手法が使用される例において、一般に、こうした構文は、当業者が上記手法を理解するであろう意味で意図される（例えば、「Ａ、Ｂ又はＣのうち少なくとも１つを有するシステム」は、これらに限定されないが、Ａを単体で、Ｂを単体で、Ｃを単体で、Ａ及びＢを一緒に、Ａ及びＣを一緒に、Ｂ及びＣを一緒に、かつ／あるいはＡ、Ｂ及びＣを一緒に有するシステムを含むであろう、など）。さらに、仮想的に、複数の代替的な用語を表す任意の離接的な語及び／又はフレーズは、説明か、クレームか又は図面かにおいて、用語のうち１つ、用語のいずれか、又は双方の用語を含む可能性を考えるように理解されるべきであることが、当業者に理解されるであろう。例えば、フレーズ「Ａ又はＢ」は、「Ａ」若しくは「Ｂ」又は「Ａ及びＢ」の可能性を含むように理解されることになる。
【０１１８】
本発明の実施形態は、限定された数の実施形態に関して説明されているが、当業者は、これら実施形態からの多数の変更及び変形を十分理解するであろう。別記の請求項は、本発明の実施形態の適正な主旨及び範囲内に入るすべてのこうした変更及び変形をカバーすることが意図される。
以下を付記として残しておく。
［付記１］
命令を含む少なくとも１つのマシン可読媒体であって、前記命令はコンピューティング装置において実行されると前記コンピューティング装置に
ビデオを受信するステップと、
前記ビデオを第１の配信チャネル、第２の配信チャネル及び第３の配信チャネルに配信する選択肢をユーザに同時に提供する単一インスタンスのグラフィカルユーザインターフェース（ＧＵＩ）を表示するステップと、
前記単一インスタンスのＧＵＩを介して供給されるユーザ入力に応答して、前記ビデオが前記第１の配信チャネル及び前記第２の配信チャネルに配信され、前記第３の配信チャネルに配信されないべきであると決定するステップと、
前記ビデオについての第１の特性及び第２の特性を決定するステップであり、前記第１の特性及び前記第２の特性は、ファイルタイプ、コンテナタイプ、ビデオ継続時間、ビデオ解像度、フレームレート、ビデオ圧縮ビットレート及びオーディオ圧縮ビットレートを含む群から選択される、ステップと、
前記ビデオを前記第１の配信チャネルに対応する第１のフォーマットを有するトランスコードされた第１のビデオにトランスコードし、前記ビデオを前記第２の配信チャネルに対応する第２のフォーマットを有するトランスコードされた第２のビデオにトランスコードし、前記第１のフォーマットは前記第２のフォーマットに等しくなく、前記ビデオを前記第３の配信チャネルに対応する第３のフォーマットを有するトランスコードされた第３のビデオにトランスコードしないステップと、
第１のメタデータと前記トランスコードされた第１のビデオとを第１のコンテナに、第２のメタデータと前記トランスコードされた第２のビデオとを第２のコンテナにパッケージ化するステップと、
前記第１のコンテナを前記第１の配信チャネルに、前記第２のコンテナを前記第２の配信チャネルに公開するステップと、
を含む方法を実行させる、少なくとも１つの媒体。
［付記２］
前記方法は、前記の公開された第１のコンテナについての第１のメトリックデータと前記の公開された第２のコンテナについての第２のメトリックデータとを受信するステップを含み、前記第１のメトリックデータは、前記第２のメトリックデータとは別様にフォーマットを整えられる、付記１に記載の少なくとも１つの媒体。
［付記３］
前記方法は、前記第１のメトリックデータ及び前記第２のメトリックデータを、前記第１のメトリックデータと前記第２のメトリックデータとの双方に対応する共通の正規化されたデータに正規化するステップを含む、付記２に記載の少なくとも１つの媒体。
［付記４］
前記方法は、第１のプロセッサベースシステム、第２のプロセッサベースシステム及び第３のプロセッサベースシステムを含むハードウェア群から、前記ユーザ入力に応答して、前記第１のプロセッサベースシステム及び前記第２のプロセッサベースシステムを選択し、しかし前記第３のプロセッサベースシステムを選択しないステップを含む、付記１に記載の少なくとも１つの媒体。
［付記５］
前記方法は、前記ビデオを前記第２のプロセッサベースシステムを介して前記トランスコードされた第２のビデオにトランスコードすることと並行して、前記ビデオを前記第１のプロセッサベースシステムを介して前記トランスコードされた第１のビデオにトランスコードすることを含む、付記４に記載の少なくとも１つの媒体。
［付記６］
前記方法は、
前記ビデオを前記第１の配信チャネル、前記第２の配信チャネル及び前記第３の配信チャネルと第４の配信チャネルとに配信する選択肢を前記ユーザに同時に提供する前記単一インスタンスのＧＵＩを表示するステップと、
前記単一インスタンスのＧＵＩを介して供給されるユーザ入力に応答して、前記ビデオが前記第４の配信チャネルに配信されるべきであると決定するステップと、
前記の決定された第１の特性及び第２の特性のうち１つを分析することに応答して、前記ビデオを前記第４の配信チャネルに対応する第４のフォーマットを有するトランスコードされた第４のビデオにトランスコードしないと決定するステップと、
を含む、付記１に記載の少なくとも１つの媒体。
［付記７］
前記方法は、
前記ユーザから、前記第１の配信チャネルに対応する第１のアカウントクレデンシャルと前記第２の配信チャネルに対応する第２のアカウントクレデンシャルとを受信するステップと、
前記第１のアカウントクレデンシャルを介して前記第１の配信チャネルに、前記第２のアカウントクレデンシャルを介して前記第２の配信チャネルにアクセスするステップと、
前記第１の配信チャネル及び前記第２の配信チャネルにアクセスすることに応答して、前記第１のコンテナを前記第１の配信チャネルに、前記第２のコンテナを前記第２の配信チャネルに公開するステップと、
を含む、付記１に記載の少なくとも１つの媒体。
［付記８］
前記方法は、
前記単一インスタンスのＧＵＩを介して供給されるユーザ入力に応答して、どの第１のチャネル情報が前記第１の配信チャネルに必要であり、どの第２のチャネル情報が前記第２の配信チャネルに必要であるかを決定するステップと、
どの第１のチャネル情報が前記第１の配信チャネルに必要であり、どの第２のチャネル情報が前記第２の配信チャネルに必要であるかを決定した後、前記ユーザからの前記第１のチャネル情報及び前記第２のチャネル情報を要求するステップと、
を含み、
前記第１のチャネル情報は前記第２のチャネル情報に等しくない、
付記１に記載の少なくとも１つの媒体。
［付記９］
前記第１のチャネル情報は、ユーザ名、パスワード、フィードタイトル、ファイルポインタ及び前記ビデオからの代表フレームのうち１つを含む、付記８に記載の少なくとも１つの媒体。
［付記１０］
前記第１のフォーマットは、第１のビットレートを含み、前記第２のフォーマットは、前記第１のビットレートに等しくない第２のビットレートを含む、付記１に記載の少なくとも１つの媒体。
［付記１１］
命令を含む少なくとも１つのマシン可読媒体であって、前記命令はコンピューティング装置において実行されると前記コンピューティング装置に
ユーザの入力に応答して、ビデオが第１の配信チャネル及び第２の配信チャネルに配信され、しかし第３の配信チャネルに配信されるべきでないと決定するステップと、
前記ビデオについての第１の特性及び第２の特性を決定するステップと、
前記ビデオを前記第１の配信チャネルに対応する第１のフォーマットを有するトランスコードされた第１のビデオにトランスコードし、前記ビデオを前記第２の配信チャネルに対応する第２のフォーマットを有するトランスコードされた第２のビデオにトランスコードし、前記第１のフォーマットは前記第２のフォーマットに等しくなく、前記ビデオを前記第３の配信チャネルに対応する第３のフォーマットを有するトランスコードされた第３のビデオにトランスコードしないステップと、
を含む方法を実行させる、少なくとも１つの媒体。
［付記１２］
前記方法は、第１のメタデータと前記トランスコードされた第１のビデオとを第１のコンテナに、第２のメタデータと前記トランスコードされた第２のビデオとを第２のコンテナにパッケージ化するステップを含む、付記１１に記載の少なくとも１つの媒体。
［付記１３］
前記方法は、前記第１のコンテナを前記第１の配信チャネルに、前記第２のコンテナを前記第２の配信チャネルに公開するステップを含む、付記１２に記載の少なくとも１つの媒体。
［付記１４］
前記方法は、前記の公開された第１のコンテナについての第１のメトリックデータと前記の公開された第２のコンテナについての第２のメトリックデータとを受信するステップを含み、前記第１のメトリックデータは、前記第２のメトリックデータとは別様にフォーマットを整えられる、付記１３に記載の少なくとも１つの媒体。
［付記１５］
前記方法は、前記第１のメトリックデータ及び前記第２のメトリックデータを、前記第１のメトリックデータと前記第２のメトリックデータとの双方に対応する共通の正規化されたデータに正規化するステップを含む、付記１４に記載の少なくとも１つの媒体。
［付記１６］
前記方法は、
ユーザ入力に応答して、前記ビデオが第４の配信チャネルに配信されるべきであると決定するステップと、
前記の決定された第１の特性及び第２の特性のうち１つを分析することに応答して、前記ビデオを前記第４の配信チャネルに対応する第４のフォーマットを有するトランスコードされた第４のビデオにトランスコードしないと決定するステップと、
を含む、付記１１に記載の少なくとも１つの媒体。
［付記１７］
前記方法は、
前記ユーザから、前記第１の配信チャネルに対応する第１のアカウントクレデンシャルと前記第２の配信チャネルに対応する第２のアカウントクレデンシャルとを受信するステップと、
前記第１のアカウントクレデンシャルを介して前記第１の配信チャネルに、前記第２のアカウントクレデンシャルを介して前記第２の配信チャネルにアクセスするステップと、
を含む、付記１１に記載の少なくとも１つの媒体。
［付記１８］
前記方法は、
どの第１のチャネル情報が前記第１の配信チャネルに必要であり、どの第２のチャネル情報が前記第２の配信チャネルに必要であるかを決定するステップと、
どの第１のチャネル情報が前記第１の配信チャネルに必要であり、どの第２のチャネル情報が前記第２の配信チャネルに必要であるかを決定した後、前記ユーザからの前記第１のチャネル情報及び前記第２のチャネル情報を要求するステップと、
を含み、
前記第１のチャネル情報は前記第２のチャネル情報に等しくない、
付記１１に記載の少なくとも１つの媒体。
［付記１９］
前記第１のチャネル情報は、ユーザ名、パスワード、フィードタイトル、ファイルポインタ及び前記ビデオからの代表フレームのうち１つを含む、付記１８に記載の少なくとも１つの媒体。
［付記２０］
前記第１のフォーマットは、第１のビットレートを含み、前記第２のフォーマットは、前記第１のビットレートに等しくない第２のビットレートを含む、付記１１に記載の少なくとも１つの媒体。
【図１】
2018088682.tif 000003
【図２】
2018088682.tif 000004
【図３】
2018088682.tif 000005
【図４】
2018088682.tif 000006
【図５】
2018088682.tif 000007
【図６】
2018088682.tif 000008
【図７】
2018088682.tif 000009
【図８】
2018088682.tif 000010
【図９】
2018088682.tif 000011
【図１０】
2018088682.tif 000012
【図１１】
2018088682.tif 000013
【外国語明細書】
2018088682000001.pdf