(57)【要約】  テレビショーをライン制作するためのシステム（１０）は、ニュースルームコンピュータシステム（ＮＲＣＳ１４）を含むことができ、このニュースルームコンピュータシステム（ＮＲＣＳ１４）は、コンテンツを転用するためのコンテンツセグメント内に含まれる時間的イベントに対応する時間的メタデータを、ユーザが指定できるようにするマークアップツールを含む。マークアップツールの使用により、ジャーナリストまたはウェブ制作者は、既存のＮＲＣＳなどを使用して、制作プロセスに必要な静的で時間的な配信メタデータを指定することができる。したがって、制作中の変更の際には、ＮＲＣＳは、以前に確立された時間的メタデータを使用して正確かつ自動的にコンテンツを転用することができる。
2011517231.tif 000002
【特許請求の範囲】
【請求項１】
制作前プロセスにおいて展開のためのメタデータをビデオコンテンツに関連付けるための方法であって、
少なくとも１つのコンテンツセグメントの入力を受信すると、前記コンテンツセグメントを配信用に転用するのに必要なメタデータを確立するステップと、
特定のメタデータを前記コンテンツセグメントに自動的に関連付けるステップと、
前記確立されたメタデータに従って、前記コンテンツセグメントをライブ配信用に転用するステップと
を含むことを特徴とする方法。
【請求項２】
前記メタデータを確立するステップは、
オーディオおよびビデオをキャプチャするステップと、
キャプチャされた未圧縮の前記オーディオおよびビデオを符号化して、オーディオビジュアルコンテンツファイルを作成するステップと、
オーディオビジュアルコンテンツ内の少なくとも１つのセグメントの開始と終了を登録するステップと、
前記少なくとも１つのセグメント内の少なくとも１つの時間的イベントを記録して、該セグメントのメタデータを確立するステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記メタデータは、ショーのレベル設定、ショーのタイトル、ショーのサブタイトル、コンテンツの格付け、コンテンツの宛先、ネットワーク系列、著作権情報、および免責事項情報のうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記確立するステップは、デフォルトのメタデータを確立するステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記メタデータをユーザコマンドの下で修正するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
データページ、ＲＳＳ（Ｒｅａｌｌｙ  Ｓｉｍｐｌｅ  Ｓｙｎｄｉｃａｔｉｏｎ）フィード、およびティッカーのうちの少なくとも１つをコンテンツストリームに組み込むステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記コンテンツストリーム内に組み込まれたデータページ、ＲＳＳフィード、およびティッカーのうちの少なくとも１つを修正するステップをさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記転用されたコンテンツを、複数の出力モードのうちの少なくとも１つの出力モードに対して展開するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記出力モードをユーザコマンドの下で修正するステップをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１０】
コンテンツセグメントを配信用に転用するのに必要なメタデータを確立するための手段と、
特定のメタデータを前記コンテンツセグメントに自動的に関連付けるための手段と、
前記確立されたメタデータに従って、コンテンツをライブ配信用に転用するための手段と
を備えたことを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００８年４月１４日に出願された米国仮特許出願６１／１２３，９１７の優先権を主張するものであり、その教示は本明細書に組み込まれている。
本発明は、コンテンツに関連付けられたメタデータを使用してコンテンツを転用（re-purposing）する。
【背景技術】
【０００２】
配信用のコンテンツを準備する際の最大のチャレンジは、関連する時間的メタデータ（temporal metadata）がほとんどないか全くないソース資料（source material）を取り扱うことである。例としては、生放送のニュース、トークショー、スポーツイベント、および厳格な時系列に従うことができない性質の他の動的なアクティビティが含まれる。ソースビデオにおけるシーンの変化を検出する自動化されたツールは存在するが、実際に制作されたコンテンツのセグメントは、典型的にそのような遷移（transition）をそのコンテンツ自体の一部として有する。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
したがって、ソースコンテンツの基本的なシーンの変化と、所望のセグメントに対する実際の開始および終了とを区別する際に困難が生じる。
【課題を解決するための手段】
【０００４】
本原理の第１の実施形態により、メタデータをオーディオビジュアルコンテンツに関連付けるための方法を提供する。この方法は、少なくとも１つのコンテンツセグメントを受信すると、コンテンツセグメントを配信用に転用するのに必要なメタデータを確立することによって開始する。確立されたメタデータを自動的に、上記少なくとも１つのコンテンツセグメントに関連付ける。その後、その少なくとも１つのコンテンツセグメントを、確立されたメタデータに従ってライブ配信用に転用する。
【図面の簡単な説明】
【０００５】
【図１】本原理のコンテンツ挿入方法を実施するためのシステムのブロック概略図である。
【図２】本原理に従ってコンテンツを転用するための一方法を示すフロー図である。
【図３】本原理に従ってショーを修正するための例示的な方法を示すフロー図である。
【図４】本原理に従ってコンテンツを修正するための例示的な方法を示すフロー図である。
【図５】本原理に従って新たな遷移マクロイベントを実装するための例示的な方法を示すフロー図である。
【発明を実施するための形態】
【０００６】
図１は、ライブショーからのコンテンツを、限定でないが、例えばインターネット配信などの通信モードを介した配信用に転用するための本発明の例示的な実施形態に係るライブショー制作システム（live show production system）１０のブロック概略図を示す。ショーのライブ制作には、典型的に以下の段階がある。  
１．制作前（Pre-production）
２．制作（Production）
３．制作後（Post-production）
４．配布（Publication）
ライブショー制作システム１０の理解を容易にするために、その要素の役割について（１）制作前段階、（２）制作段階、（３）制作後段階、（４）配布段階との関連で、このシステムの要素を説明する。段階２および４は、広告トラフィックおよび課金アクティビティの双方と対話する可能性がある。
【０００７】
制作前
テレビのニュース番組などのショーのためのライブコンテンツの制作前段階は、通常、コンテンツセグメント（例えば、ニュース記事（news story））および関連するメタデータの収集を必要とする。ライブショーの制作前段階を容易にするために、ライブショー制作システム１０は、少なくとも１つの、好ましくは複数のデータ入力表示装置を含み、この各装置により、オペレータはデータを入力し、少なくとも以下のアクティビティに関して表示された情報を受信することができる。  
（１）ウェブ制作および編集
（２）ニュースルーム（newsroom）制作
（３）デジタルニュースの制作および資産管理
オペレータは、単一のデータ入力表示装置を使用して、データを入力し、これらの３つのアクティビティ全て（加えて、他の機能）に関する情報を受信することができる。実際、しばしば別々のオペレータが、（１）ウェブ制作および編集、（２）ニュースルーム制作、ならびに（３）デジタルニュースの制作および資産管理を、データ入力表示装置１２1、１２2、１２3のうちそれぞれ対応する１つのデータ入力表示装置を用いて処理することがある。データ入力表示装置１２1、１２2、１２3の各々は、典型的に、関連付けられたキーボードを有する従来のビデオ表示端末の形をとる。あるいはまた、データ入力表示装置は、デスクトップコンピュータやラップトップコンピュータ、ＰＤＡ（Personal Data Assistant）などの異なる形をとることもできる。（１）ウェブ制作および編集アクティビティ、（２）ニュースルーム制作アクティビティ、（３）デジタルニュース制作および資産管理アクティビティのうちの１つまたは複数が２以上のオペレータを必要とする場合には、ライブショー制作システム１０は、そのアクティビティに関連付けられた追加のデータ入力表示装置を含むことができる。
【０００８】
データ入力表示装置１２1−１２3はそれぞれ、ニュースルームのコンピュータシステム（ＮＲＣＳ：news room computer system）１４にリンクする。ＮＲＣＳ１４は、典型的に、１つまたは複数のプロセッサ（図示せず）、１つまたは複数のサーバ（図示せず）、ならびに他の装置を含み、これらはすべて、ニュースの収集に関連付けられた様々なアクティビティを自動化するように機能する１つまたは複数の制御プログラムの下で動作する。例えば、ＮＲＣＳ１４は、典型的に、レポーター、カメラオペレータなど様々な個人の間の記事の割り当て（story assignment）を管理し、追跡する。さらに、ＮＲＣＳ１４は、ニュース記事、台本（transcript）、およびメタデータのエントリポイント（例えば、取り込みポイント（ingest point））として機能して、自動放送システム２２およびエンコーダ２４の双方を駆動する。さらに、ＮＲＣＳ１４は、レポーターや編集者を含めニュースルームの人々に、自動放送システム２２またはワークフローマネージャ３４によってトリガされるグラフィックの追加を含め、少なくとも一部の編集操作を行う能力を提供し、これにより、その人々が、ＮＲＣＳ１４によって格納されるコンテンツセグメントを作成することが可能になる。
【０００９】
前述したように、ライブショーは、典型的に、コンテンツセグメントの間に使用（play out）するための１つまたは複数の広告を含む。ほとんどのテレビ局は、トラフィック管理システム１６によって最も良く例示される、広告が表示される時間およびその広告の使用のために契約した関係者に対する費用の支払いに関して広告のスケジューリングを管理するための１つまたは複数のシステムを利用する。典型的に、テレビ局は、広告に対して、その広告が表示される番組に応じて異なる金額を課すこととなる。したがって、多くの視聴者を有する番組には、典型的に、あまり人気のない番組よりも高い広告費が設定される。同様に、特定の時間の間に表示される番組には、他の時間の間に表示される番組よりも高い広告費を設定することもできる。さらに、ニュース放送の特定のセグメント、すなわち天気、トップ記事、スポーツなどは、ニュース放送の他の部分よりも高い収入を引き出す可能性がある。
【００１０】
トラフィック管理システム１６は、ブラウザ１８に対するリンクを有し、このブラウザ１８は、典型的に、ビデオ表示端末またはパーソナルコンピュータの形式であり、そしてレポートを提供するため、および該トラフィックシステムとシステム１０内の他の要素（後述）との間のインタフェースを提供するためのディスプレイに関連付けられている。ブラウザ１８は、適切な許可を有するユーザがリモートからトラフィック情報および課金情報にアクセスできるようにするファイアウォール１９にもリンクする。
【００１１】
制作
ライブショー制作の制作段階は、通常、一連のコンテンツセグメントを組み立てて使用するのに、スクリプトの作成およびその後の実行を必要とする。一例として、ライブのテレビのニュース番組の制作は、典型的に、ライブショット（live shot）が組み込まれ、そして放送中のタレント、現地のレポーターのライブショット、および／またはライブネットワークからの映像（live network feed）のオーディオを伴う、事前に記録されたコンテンツセグメントの使用を必要とする。「制作」段階を容易にするために、システム１０は、フロリダ州のジャクソンビルにある、本件出願人であるトムソン社のグラスバレー（Grass Valley）部門から入手可能なＩｎｇｉｔｅ自動制作システム（Automated Production System）として提供されるような、標準の手動ワークフローまたは自動のワークフローのいずれかにより提供する放送制作システム（broadcast production system）２２を含む。放送制作システム２２は、ＮＲＣＳ１４から、典型的にはメディアオブジェクトサーバ（ＭＯＳ：Media Object Server）プロトコルを介して渡されるコンテンツセグメントを受信する。放送制作システム２２は、典型的に、１つまたは複数のコンピュータの組み合わせを備え、このようなコンピュータの制御の下にある記憶装置などの周辺装置、ならびに例えばカメラ、ビデオスイッチャ、オーディオミキサなどの１つまたは複数の放送制作装置（図示せず）に関連付けられている。放送制作システム２２は、自動化されたランダウン（rundown）のために（例えば、スクリプトの実行のために）コンテンツセグメントの作成およびスクリプトへの組み立てを制御し、配信用（すなわち、配布）のテレビ番組を作成する。ライブショーの「制作」段階を容易にするために、図１のライブショー制作システム１０は、自動放送システム２２によって生成されたライブオーディオビジュアルコンテンツを、Ｗｉｎｄｏｗｓ（登録商標）メディアビデオ（ＷＭＶ）などの特定の符号化フォーマットを使用して符号化することが可能な第１のエンコーダ２４も含み、これによりインターネット、あるいはＬＡＮやＷＡＮなどの１つまたは複数のネットワークを介した加入者への後の配信のために、上記コンテンツを第１のファイアウォール２６へ伝送することを容易にする。トランスコーディングシステム２８は、エンコーダ２４からの符号化されたコンテンツを、例えばＭＰＥＧ２、Ｈ．２６４、Ａｐｐｌｅ（登録商標）社のＱｕｉｃｋ  Ｔｉｍｅなどの他のフォーマットに変換し、これにより、地上テレビ放送（terrestrial over-the-air broadcast）および／または衛星配信および／またはケーブルテレビシステムなどの１つまたは複数のチャネルを介した後の配信のために、上記フォーマットで符号化されたコンテンツのファイアウォール２６への伝送を容易にする。トランスコーディングシステム２８は、出力ファイルに直接組み込まれる（stitch）こととなるプレロール（pre-roll）コンテンツまたはポストロール（post-roll）コンテンツを指定する機能も有する。プレロールコンテンツまたはポストロールコンテンツは、ワークフローマネージャ３４に格納されている広告またはプロモーションクリップのいずれかとすることができる。
【００１２】
図１のライブショー生成システム１０は、未圧縮の形式の広告および代替的なソース資料を符号化して、インターネットを介した後の配信のためにファイアフォール２６に配信するのにＷｉｎｄｏｗｓ（登録商標）メディアビデオフォーマットなどの所与のフォーマットにするための第２のエンコーダ３０も含むことができる。追加のトランスコーダ（図示せず）をトランスコーディングシステムに追加して並列変換の非同期処理を可能にすることもできる。
【００１３】
制作後
ライブショー制作の「制作後」段階は、例えば編集などの特定のタスクを実行するためにコンテンツの操作を必要とする。本原理のライブショー制作システム１０の図示された実施形態では、そのようなコンテンツの操作は、連続するコンテンツセグメント間のタイムスロットへの広告または新たなコンテンツの挿入を含むことができる。
【００１４】
ライブのテレビ番組作成の「制作後」段階を容易にするために、図１のシステム１０は、典型的には、データ入力表示装置１２1、１２2、および１２3、ならびにエンコーダ２４、および３０、トランスコーディングシステム２８にリンクされる、プログラムされたコンピュータなどの形をとるワークフローマネージャ３４を含む。ワークフローマネージャ３４は、広告の管理や記憶、およびコンテンツセグメントの操作を含め、様々なタスクを実行して、コンテンツセグメント間の所与のタイムスロットへの広告の挿入を容易にする。ワークフローマネージャ３４は、デジタルニュース制作システム（図示せず）と、コンテンツストリーミングシステム（図示せず）と、管理（administration）システム（図示せず）とに対するインタフェースとしても機能する。ワークフローマネージャ３４は、適切な許可を有するユーザが、該ワークフローマネージャによって生成された情報に対するリモートアクセスを取得することを可能にする、ファイアウォール３５へのリンクを有する。
【００１５】
典型的にビデオ端末および関連するキーボードの形の少なくとも１つの管理ブラウズ装置３６は、ワークフローマネージャ３４にリンクして、オペレータが該ワークフローマネージャにアクセスして、コンテンツの管理および配信を制御することを含め様々なタスクを実行することを可能にする。少なくとも１つの承認ワークステーション（approve workstation）３８も、ワークフローマネージャ３４へのリンクを有し、オペレータがライブコンテンツとノンリニア編集された（non-linear edited）コンテンツとの両方をレビューして、配布のための承認を与えることを可能にする。
【００１６】
配布
ライブショー制作の「配布」段階は、典型的に視聴者へのコンテンツの配信を必要とする。伝統的に、ライブで制作されたテレビ番組の配信は、地上伝送、あるいは１つまたは複数の通信衛星やケーブルシステムへの伝送を必要としていた。上述のように、ライブショー制作システム１０は、インターネットなどの１つまたは複数のネットワークを介してコンテンツを配信することができる利点がある。インターネット上の配布（すなわち、配信）を容易にするために、システム１０は、前述したように、テレビ番組を、関心のある加入者に渡すポータルとして機能するファイアウォール１９を含む。説明したように、ファイアウォール２６および３５は、適切な許可を有するユーザが、ライブショー制作システム１０にアクセスして、システムオペレーションに関連する特定の情報を取得することを可能にする。
【００１７】
以下でさらに詳細に説明されるように、ライブショー制作システム１０は、ライブコンテンツの制作の効率、特にそのようなライブコンテンツを、インターネット、およびインターネットプロトコルや他のデータプロトコルを用いたような他の同様の配信機構を介した配信用に（例えば、展開（deployment））転用することの効率を著しく向上させることができる。
【００１８】
制作後プロセスの人員を増やして強引にコンテンツをより早く転用する代わりに、本原理の技術は、ニュース放送の制作を完了する前に、転用するタスクの少なくとも一部を完了できるようにする。上述のように、ＮＲＣＳ１４は、ライブニュースの制作前段階に対処する。実際、ＮＲＣＳは、マサチューセッツ州のチュークスベリのＡｖｉｄ社から入手可能なｉＮｅｗｓ（登録商標）またはＡＰ  ＥＮＰＳ（登録商標）の形とすることができる。ＮＲＣＳを使用して、ジャーナリストは、記事を入力し、必要に応じてコンテンツを関連付ける。ＮＲＣＳ１４は、コンテンツを転用するのに特有のマークアップツールを含み、これにより、ジャーナリストまたはウェブ制作者は、既存のＮＲＣＳを使用して、制作プロセスに必要とされる静的で時間的な配信メタデータを指定することができる。以下で図２においてより詳述されるように、マークアップツールは、様々な機能を実行して時間的なイベント（temporal event）を記録し、コンテンツとの関連付けのためのメタデータを確立する。
【００１９】
ライブコンテンツ制作
コンテンツ（限定ではないがニュース番組などのテレビショーを含むオーディオ／ビジュアル情報）が、必要な制作メタデータのすべてを用いてマークアップされると、図１の放送制作システム２２は、ＮＲＣＳ１４からのコンテンツをインポートして、該コンテンツを適宜正確な結果を用いて実行することができる。コンテンツを実行すると、未圧縮のオーディオおよびビデオをキャプチャして、制作後にコンテンツを転用するのに必要な高解像度のマスターショーファイル（master show file）に符号化する。
【００２０】
静的な配信メタデータは、コンテンツの制作前プロセスにおいて入力され、そして各コンテンツセグメントをレビューして、最終的にはシームレスなワークフローのための制作後プロセスを遂行することができる。しかしながら、作業における大幅な効率は、放送制作システム２２によりワークフローに挿入される正確な時間的メタデータの追加によって得られる。各コンテンツセグメントの開始および終了は、放送制作システム２２による実行のためにセグメントとして登録される。各セグメント内の時間的イベントは正確に、所望のＵＲＬ、ＲＳＳ、またはウェブ制作者によって指定されたサーベイ（survey）とともに記録される。そのようなアクティビティの結果により、全ての静的な配信および時間的メタデータとともにマスターファイル内に格納されたコンテンツの少なくとも１つのコピーが得られ、正確かつ自動的にコンテンツを転用することができる。
【００２１】
図２は、本原理に従ってコンテンツを転用するための例示のステップをフローチャートの形式で図示している。上述のように、未圧縮のオーディオおよびビデオは、ステップ４２において、キャプチャおよび符号化されて高解像度のマスターショーファイルとなる。ステップ４４において、各セグメントの開始および終了が登録される。時間的イベント、ならびに各セグメント内の関連するメタデータが、ステップ４６において、所望のＵＲＬ、ＲＳＳ、またはウェブ制作者によって指定されたサーベイとともに記録される。この記録するステップにより、静的、配信および時間的メタデータとともにマスターファイル内に格納されたコンテンツのコピーが得られ、コンテンツの正確かつ自動的な転用が可能になる（図２の要素４８）。以下でさらに詳述するように、メタデータは、例として、レベル設定、ショーのタイトル、ショーのサブタイトル、コンテンツの格付け（rating）、コンテンツの宛先、ネットワーク系列（network affiliation）、著作権情報、および免責事項（disclaimer）情報などの情報のうちのいずれかまたは全てを含むことができる。メタデータは、事前に特定された項目の一部または全部に代えて、あるいはそれらに加えて、追加の情報を含むことができる。
【００２２】
図３は、例示的なレベル設定を使用して、テレビショーを含むコンテンツを修正するための方法６００のステップをフローチャート形式で図示している。テレビショーに対する全ての設定は保存可能とすべきでる。この処理は、ウェブ制作者が、ステップ６０２において、図１のライブショー制作システム１０に関連付けられたグラフィカルユーザインタフェース（図示せず）内の「ショー（Show）」タブを、典型的には周知のＡｃｔｉｖｅＸコントロールを使用して選択すると開始する。このとき、ステップ６０４において、ショーのレベル設定を修正するか否かを判断するチェックが行われる。上記判断でＹＥＳの場合、処理はステップ６０６に進む。デフォルトのショータイトルをユーザに対して表示すべきである。このタイトルは、準備すべきテンプレートに基づいて自動的に生成される。ここでは、ユーザが午後６時に始まるニュース放送に関連付けられたテンプレートを準備している、という例について検討する。この場合、出力名は、「２００９年１１月７日木曜日  午後６時  ニュース放送（6PM Newscast Thursday 09/11/07）」として表示される。ユーザは、ショーの準備の際にユーザ修正されたタイトルが代替的なタイトルとなるように、タイトルを変更する能力を有するべきである。ショーのタイトルは、修正されると、ステップ６０７においてデータベース６１０に保存され、図１の放送制作システム２２は、ステップ６０８において該システム自身を更新する。以下から明らかになるように、いずれかのタイトル修正が行なわれると、この修正は保存され、そしてこの修正に応答してデータベース６１０の表示が行われる。
【００２３】
ユーザは、ショーのサブタイトルを修正することができ、このような修正がステップ６１２において検出されると、修正されたサブタイトルが、ステップ６１３においてデータベース６１０に保存される。この後、図１の放送制作システム２２は、ステップ６０８において該システム自身を更新する。データベース６１０は、修正されたサブタイトルを示すこととなる。
【００２４】
ショーの準備のときに使用されるテンプレートは、自動的にショーの格付けを指定することになる。しかしながら、インターネットによるライブ放送の格付けを示す、ショーのレベルの格付けを指定することができる。ドロップダウンボックスが可能な格付けを表示し、これによりユーザは、Ｇ、ＰＧ、ＰＧ−１３などを選択することができる。ユーザはショーの格付けを修正することができ、このような修正がステップ６１４において検出されると、修正された格付けは、ステップ６１５においてデータベース１０に保存される。その後、図１の放送制作システム２２は、ステップ６０８において該システム自身を更新する。データベース６１０は、修正された格付けを示すこととなる。
【００２５】
データベース６１０は、テレビ局、またはコンテンツを発信した他のソース局（source station）を示す設定を含む。しかしながら、ウェブ制作者がコンテンツを加盟者（affiliate）に提供することを望む場合、あるいは、なんらかのやり方で標準の展開以外に配給することを望む場合、ウェブ制作者は、異なるコンテンツソースを指定する能力を有すべきである。ユーザは、委託時に、放送制作システム２２がコンテンツを作成することができる局のリストを確立する能力を有すべきである。局のリストは、ＡｃｔｉｖｅＸコントロールの下でドロップダウンボックスに表示されることとなる。しかしながら、ユーザは、局をテキストボックス内に手動で指定する能力も有すべきである。したがって、ユーザはコンテンツのソースを修正することができ、このような修正がステップ６１６において検出されると、修正された局がステップ６１７においてデータベース６１０に保存される。その後、図１の放送制作システム２２は、ステップ６０８において自身を更新する。データベース６１０は、修正された局を示すこととなる。
【００２６】
データベース６１０は、コンテンツを作成したテレビ局のネットワーク系列に関する情報も含み、このネットワーク系列は通常、ショーの準備の最初に自動的に割り当てられる。しかしながら、ウェブ制作者はやはり、自動的に指定された値をオーバーライドする能力も有すべきである。したがって、ユーザはその系列を修正することができ、このような修正がステップ６１８において検出されると、修正された系列がステップ６１９においてデータベース６１０に保存される。その後、図１の放送制作システム２２は、ステップ６０８において自身を更新する。データベース６１０は、修正された系列を示すこととなる。
【００２７】
データベース６１０は、典型的にはグローバルコンテンツの配信を許可する著作権情報も格納する。しかしながら、非標準的な配信のためにコンテンツを提供する場合、ウェブ制作者は、このショーのデフォルトの著作権を修正する能力を有すべきである。ドロップダウンボックスは、全ての利用可能な所定の著作権をリストする。したがって、ユーザは著作権情報を修正することができ、このような修正がステップ６２０において検出されると、修正された著作権情報がステップ６２１においてデータベースに保存される。その後、図１の放送制作システム２２は、ステップ６０８において自身を更新する。データベース６１０は、修正された著作権情報を示すこととなる。
【００２８】
ユーザは、データベースで指定されたデフォルトの免責事項からいずれかを選択し、あるいはテキストボックスから異なる免責事項を手動で入力する能力を有すべきである。ステップ６２２において修正された免責事項が検出されると、修正された免責事項の情報が、ステップ６２３においてデータベース６１０に保存される。その後、図１の放送制作システム２２は、ステップ６０８において自身を更新する。データベース６１０は、修正された免責事項情報を示すこととなる。
【００２９】
セグメントデータ情報は、図１のＮＲＣＳ１４に直接格納される。セグメントに関する情報は、ＮＲＣＳ１４内のページのスクリプトテキストフィールドに直接組み込まれる、ＭＯＳでフォーマットされたメッセージに表示される。ユーザが、ある記事を選択するとき、該ユーザは、スクリプトテキスト内のＭＯＳでフォーマットされたメッセージを見る能力を有すべきであり、そしてそのＭＯＳメッセージをダブルクリックする能力を有すべきである。この時点で、ＡｃｔｉｖｅＸコントロールは、その記事内の全てのコンテンツに対する全ての適用可能な情報を示すべきである。
【００３０】
図４は、本原理に従ってセグメントデータを修正するための例示的な方法７００のステップをフローチャート形式で図示している。最初にユーザは、ステップ７０２において図１のＮＲＣＳ１４内のＡｃｔｉｖｅＸコントロールにアクセスし、ユーザは、ステップ７０４においてセグメントレベル設定を修正する能力を取得する。ユーザが、セグメントレベル設定を修正するオプションを選択すると、ステップ７０６において該ユーザに、テンプレートをロードするかどうかを尋ねる。ユーザがテンプレートをロードすることを選択すると、ステップ７０８において、テンプレート設定が全ての適切なフィールドにロードされ、ステップ７１０において、ユーザは、メジャー／マイナーの分類（Major/Minor classification）を行うオプションを受信する。
【００３１】
セグメント情報は、セグメントによって異なる可能性があるので（例えば、分類、格付け、キーワードなど）、ユーザは、テンプレートをロードして保存する能力を有すべきである。デフォルトの情報は、「全て」適用可能なフィールドのテンプレート内に存在する。ステップ７０６においてテンプレートが選択されると、ステップ７０８において、デフォルトの情報が自動的に様々なテキストフィールドに追加され、ユーザ修正を可能にするようドロップダウンボックスが表示されることとなる。
【００３２】
このプロセスをより良く理解するために、ユーザが高校のバスケットボールのゲームなどのスポーツショーのテンプレートを作成する例を検討する。そのようなテンプレートは、正確なメジャーとマイナーの分類と、スポーツ、高校、バスケットボール、およびＧの格付けなどのキーワードに対するデフォルト値と、デフォルトの７日間の有効期限と、デフォルトの著作権と、補助データウィンドウ（Auxiliary data window）を追加するスポーツティッカー（sports ticker）とを含むであろう。
【００３３】
テンプレート作成プロセスの間、ユーザは、全ての利用可能なメジャーとマイナーの分類を含む２つのドロップダウンボックスを追加する能力を有すべきである。ユーザが異なるメジャー分類を選択すると、メマイナー分類のドロップダウンボックスは、そのメジャー分類に関連付けられた正しいマイナー分類を反映するように更新されるべきである。メジャー／マイナー分類は、選択されると、ステップ７１２において保存される。
【００３４】
ニュース記事を含むコンテンツはしばしば、「スラッグ（slug）」を有することがあり、これは記事のタイトルや日付などの情報を含む非視覚的に表示される部分である。実際、図１のＮＲＣＳ１４はデフォルトでスラッグを提供する。しかしながら、ユーザは、テキストエリアにより、ウェブプレイヤ用に記事／スラッグのテキストを変更する能力を有すべきである。ユーザは、スラッグテキストをイタリックやボールドなどの簡単なＨＴＭＬを用いてマークアップする能力も有すべきであり、これが行われると、スラッグに対する変更がステップ７１５において保存される。
【００３５】
好適な実施形態では、ユーザは、ステップ７１６において、拡張されたプレイクリップ（extended play clip）（「アセット（asset）」と呼ばれることもある）を選択する能力も有すべきである。このようなクリップは、ＡｃｔｉｖｅＸコントロール内のペインの下でサムネイルの形で表示されるべきである。サムネイルおよび関連するアセット識別（「アセットＩＤ」と呼ばれる）は、典型的に、図１の放送制作システム２２に設置されたビデオサーバ（図示せず）から自動的に取り出される。その選択が行われると、クリップは、ステップ７１７において、拡張されたプレイ特性を有するものとしてアセットでフラグを付けられるが、そのアセットＩＤは、ＭＯＳスクリプト情報に挿入されるべきである。
【００３６】
例示的な実施形態では、ユーザは、ステップ７１８において、ＵＲＬをメディアストリーム（例えば、コンテンツストリーム）に組み込む能力を有すべきである。ユーザが、省略されていない（fully-qualified）ＵＲＬを手動で入力することを可能にするテキストボックスが表示される。しかしながら、典型的には、ユーザが事前作成されたコンテンツをメディアストリームに容易に組み込むことを可能にする、いくつかの共通のリンクが存在する。手動のＵＲＬ入力のためのテキストボックスに加えて、ユーザは、適切な利用可能なリンクを用いてドロップダウンボックスを追加する能力を有すべきである。より具体的には、ユーザは、次のエントリを作成する能力を有するべきである。  
・データページ（ステップ７２０）
・ＲＳＳ（Really Simple Syndication）フィード（ステップ７２２）
・ティッカー（ステップ７２４）
ステップ７２０においてＵＲＬのドロップダウンボックスからデータページが選択されると、利用可能なデータページのリストが、ユーザによるブラウズおよび選択のために表示される。あるデータページが選択されると、ユーザは、そのページをプレビューし、そのページに対する修正を行い、そしてこれらを保存してＳＯＡＰメッセージによりデータページサーバに返すための能力を有すべきである。
【００３７】
ステップ７２２においてＲＳＳフィードが選択されると、ユーザは、利用可能な公知のＲＳＳフィードのドロップダウンリストを受信すべきである。典型的には、１つまたは複数のＲＳＳフィードが存在する。多数のＲＳＳフィードが存在する可能性もあるため、メジャーとマイナーの分類は、フィードのリストを要求するときの引数（argument）として表示され、その記事に対して利用可能なフィードがコンテンツとの関係を有することを確実にする。ＲＳＳフィードは、選択されると、ステップ７２３においてＵＲＬとして保存される。ユーザは、補助データウィンドウ内の任意の自動コンテンツまたは所定のコンテンツを使用しないことを選択する可能性がある。したがってシステムは、ステップ７２５において、記憶するための省略されていないＵＲＬをユーザが手動でタイプするテキストエリアを提供すべきである。
【００３８】
ユーザは、ステップ７２６において、補助データウィンドウ内に含めるためのティッカー（ticker）を指定する能力を有すべきである。ティッカーは、ニュース放送に特有の個々の種類（branding）を有し、そのため、午後６時の天気のティッカーが存在し、さらに、例えば午後６時−金融（Financial）−株（Stock）−ＴＭＳなど、多くの多様なティッカーのサブカテゴリが存在する可能性もある。このため、ティッカーは、いくつかのレベルを有すべきである。実際、ユーザは、組み込むためのティッカーが見つかるまでそれぞれの個々のレベルをブラウズすることができる、ツリー分岐（tree break-down）を受信することができる。ユーザが、ステップ７２６においてティッカーを選択した場合、このティッカーはステップ７２７において組み込まれる。
【００３９】
ユーザが、ステップ７２６においてティッカーを選択しなかった場合、ユーザは、典型的に、その後ステップ７２８において、サーベイを指定するオプションを取得する。ユーザは、サーベイを指定して補助データウィンドウ内に表示する能力を有すべきである。インタフェースを使用する容易性により、ユーザが、ポール（poll）を指定して記事に関連付けることを可能にすべきである。サーベイがまだ存在してないとき、ユーザは、放送制作システム２２によって提供されるものと同様にインタフェースを受信すべきであり、この場合、ユーザは、新たなサーベイを作成して、質問と回答の両方を指定することができる。ユーザは、ポールが作成されたあとに、それらの値を修正する能力を有するべきである。さらに、ユーザは、その結果が記事内に表示されている完了したサーベイを指定する能力を有すべきである。例えば、ユーザが、以前に行われたが、現在の記事に関連するサーベイを指定することを望むことがある。ユーザは、ポールの結果を呼び出して表示する能力を有すべきである。
【００４０】
ユーザは、個々の出力モードまたは複数の出力モードを選択する能力を有すべきである。この点において、ユーザは、「ウェブ出力」、モバイル装置、アーカイブなど、そのような出力モードに関していくつかのチェックボックスを与えられるべきである。選択された出力方法は、ステップ７３５において保存される。
【００４１】
スクリプトテキストは、図１のＮＲＣＳ１４によって提供されたトランスクリプトによって自動的に追加される、大きなテキストエリアを有すべきである。しかしながら、ユーザは、任意のトランスクリプト情報を手動で上書きして相応に編集する能力を有すべきである。ユーザは、テキストを再フォーマットして、これをイタリックやボールドなどの簡単なＨＴＭＬを用いてマープアップする能力も有すべきである。選択または修正の後、スクリプトテキストは、ステップ７３７において保存される。
【００４２】
ユーザは、著作権情報を含むテキストフィールドにアクセスすべきである。実際、ショーの著作権情報は、テキストフィールドに著作権報を提供する。ユーザは、著作権情報をセグメントレベル毎に修正する能力を有すべきである。そのような著作権は、予め定義されドロップダウンにより選択され、あるいはテキストフィールドにより手動で更新され、その後ステップ７３９において保存される。
【００４３】
ショーの情報は、自動的に格付け情報を提供するが、ユーザは、ドロップダウンボックスから、特に記事に対する格付けを選択する能力を有すべきである。これらの格付けは、検索中のウェブプレイヤ（図示せず）からのアクセスのため、および利用可能なセグメントリストの表示のために記事とともに格納されるべきである。格付けに対する全ての変更または修正は、ステップ７４１において保存される。
【００４４】
ショーの情報は、自動的にデフォルトのセグメントの有効期限を提供すべきであるが、ユーザは、記事の有効期限を修正する能力を有するべきである。ユーザは、単純なグラフィカルカレンダを受信し、これにより該ユーザは、その個々のセグメントの有効期限の日付を変更することが可能になる。ユーザによって行われた全ての変更は、ステップ７４３において保存される。
【００４５】
実際、ユーザがセグメントのテンプレートを選択すると、自動的にキーワードが追加される。しかしながら、ユーザは、キーワードをテキストエリアに手動で入力して、その後キーワードを保存する（７４５）能力を有するべきである。
【００４６】
図５は、ユーザがテレビショーを作成し、およびコンテンツの転用を含め該ショーを処理することができる、本原理による例示的なプロセス８００のステップをフローチャート形式で図示している。ステップ８０２において、ユーザが、制作前のツールを使用してショーのランダウン（例えば、スクリプト）をマークアップする。その後、図１の放送制作システム２２は、図１のＮＲＣＳ１４と通信して、ステップ８０４においてランダウン（スクリプト）を生成し、ステップ８０６において放送制作システムが、このランダウン（スクリプト）を使用して遷移マクロイベント（ＴＭＥ：Transition Macro Event）を実行して、後述される手法でコンテンツを転用する。
【００４７】
当業者には、本原理をハードウェア、ソフトウェア、ファームウェア、特殊目的のプロセッサ、またはこれらの組み合わせの様々な形式で実装することができることが理解されよう。好ましくは、ハードウェアとソフトウェアの組み合わせを使用して実装することができる。さらに、そのようなソフトウェアは、典型的に、プログラム記憶装置において具現化されるアプリケーションプログラムとして存在する。アプリケーションプログラムは、典型的に、任意の適切なアーキテクチャを備えたマシンによって実行される。好ましくは、マシンは、１つまたは複数の中央処理ユニット（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）、入出力（Ｉ／Ｏ）インタフェースなどのハードウェアを有するコンピュータプラットフォームを備える。このコンピュータプラットフォームは、オペレーティングシステムおよびマイクロ命令コードを含むことができる。本明細書で説明された様々な処理および機能は、オペレーティングシステムにより実行されるマイクロ命令コードの一部またはアプリケーションプログラムの一部（あるいはそれらの組み合わせ）を備えることができる。さらに、追加のデータ記憶装置および印刷装置などのコンピュータプラットフォームに接続するための他の様々な周辺装置も存在することができる。
【００４８】
当業者は、構成システムコンポーネントおよび添付の図面内に図示された方法のステップの一部の機能は、ソフトウェア内にあり、システムコンポーネント（または処理ステップ間）の実際の接続は、そのようなソフトウェアによる上記機能の実行に応じて異なるものとすることができることを認識されたい。本明細書における教示により、関連する技術分野の当業者は、本原理のこれらおよび同様の実装または構成を容易に考え出すことが可能である。
【００４９】
上記説明では複数の実装を説明してきた。当業者は、それでもなお様々な修正があり得ることを認識されたい。例えば、様々な実装の要素を組み合わせ、補完し、修正し、あるいは除去して他の実装を作り出すことができる。さらに、当業者には、他の構造および処理を、開示された構造または処理と置き換えることができ、その結果得られた実装が、実質的に同じ機能を実質的に同じ方法で実行して、開示された実装と実質的に同じ結果を達成するであろうことが理解されよう。したがって、これらおよび他の実装が特許請求の範囲内にある。
【図１】
2011517231.tif 000003
【図２】
2011517231.tif 000004
【図３】
2011517231.tif 000005
【図４】
2011517231.tif 000006
【図５】
2011517231.tif 000007
【国際調査報告】
2011517231.tif 000008
2011517231.tif 000009
2011517231.tif 000010
2011517231.tif 000011