JP2012529875A - 配信バックボーン - Google Patents

Abstract

配信バックボーンシステムを使用してメディアコンテンツをデジタル配信する方法は、クライアントプロフィールを含むメディアコンテンツに対する要求をクライアントから受信する段階と、クライアントプロフィールを通して反復的に進むことによってソースアセットの在庫及び解析を行って出力を作成する段階と、一連の規則がソースアセットをクライアントプロフィールにマップすることを可能にする機能マッピングを行う段階と、クライアントからのメディアコンテンツに対する要求に応答してマップされた機能から作業項目及び実行段階を判断する製造工程を計画する段階とを含む。
【選択図】図３

Description

本発明は、デジタルメディアに関し、より具体的には、メディアのデジタル配信に関する。

メディア生成及び配信が完全デジタル化に急速に向う中で、ワークフローの自動化及び様々なデジタルフォーマット／デバイスの互換性に備えることは有利であると考えられるが、これらには、ソフトウエア及びハードウエアの両方の統合が必要である。しかし、メディア生成の分野においてワークフローの自動化及び様々なデジタルフォーマット／デバイスの互換性の具備にはいくつかの障害がある。例えば、現在、ワークフローの統合の欠如、規格の欠如、異種のソフトウエア及びハードウエアソリューション、及びワークフローの手動的性質に取って代わるドライブの一般的な欠如が存在する。

本発明の実施形態は、配信バックボーンシステムを使用してメディアコンテンツをデジタル配信することに対して備えるものである。

一実施例では、配信バックボーンシステムを使用してメディアコンテンツをデジタル配信する方法を開示する。本方法は、クライアントプロフィールを含むメディアコンテンツに対する要求をクライアントから受信する段階と、クライアントプロフィールを通して反復的に進むことによってソースアセットの在庫及び解析を行って出力を作成する段階と、一連の規則がソースアセットをクライアントプロフィールにマップすることを可能にする機能マッピングを行う段階と、クライアントからのメディアコンテンツに対する要求に応答してマップされた機能から作業項目及び実行段階を判断する製造工程を計画する段階とを含む。

別の実施例では、配信バックボーンシステムを開示する。システムは、クライアントプロフィールを含むメディアコンテンツに対する要求をクライアントから受信する製造解析エンジンであって、製造解析が、クライアントプロフィールを通して反復的に進むことによってソースアセットの在庫及び解析を実行して解析出力を発生するように作動する製造解析エンジンと、解析出力を使用して作業項目及び実行段階を判断するように構成された製造計画エンジンとを含む。

更に別の実施例では、メディアコンテンツをデジタル配信するためのコンピュータプログラムを格納するコンピュータ可読記憶媒体を開示する。コンピュータプログラムは、コンピュータをして、クライアントプロフィールを含むメディアコンテンツに対する要求をクライアントから受信し、クライアントプロフィールを通して反復的に進むことによってソースアセットの在庫及び解析を実行して出力を作成し、一連の規則がソースアセットをクライアントプロフィールにマップすることを可能にする機能マッピングを実行し、かつクライアントからのメディアコンテンツに対する要求に応答してマップされた機能から作業項目及び実行段階を判断する製造工程を計画させる実行可能命令を含む。

本発明の他の特徴及び利点は、以下の詳細説明及び添付図面を精査した後で当業者に容易に明らかになるであろう。

本発明の一実施例による配信バックボーンシステムを使用するメディアコンテンツのデジタル配信の処理を示す流れ図である。 本発明の一実施例による配信バックボーンシステムのブロック図である。 本発明の一実施例による配信バックボーンシステムを使用するメディアコンテンツのデジタル配信の技術を示す流れ図である。 製造計画に寄与する配送要件及びクライアントプロフィールの詳細なレイアウトを示す図である。 クライアントプロフィールの例示的な使用事例を示す図である。 クライアントが受諾することができる配送品の範囲を表す複数の組のソースプリファレンス及び技術仕様を示す図である。 在庫の状態の一例を示す図である。 見出された時にデータがソースアセットから抽出される例示的な使用事例を示す図である。 マテリアル解析問い合わせにおいて識別されたアセットから収集されたデータを示す図である。 機能マッピングの特定の使用事例を示す図である。 製造計画の特定の使用事例を示す図である。 コンピュータシステム及びユーザの図を示す図である。 配信バックボーン処理をホストするコンピュータシステムを示す機能ブロック図である。 どのようにパートナー及びクライアントがクライアントプロフィール、仕様、及び構成と関連することが予想されるかを示すサンプルエンティティ関係図である。 要求維持モジュールへの主要な入力を表示する図である。 ２つのアルファ（監督のカット及び劇場初公開）を有する表題と監督のカットアルファにサービス提供するように識別されると考えられるコンポーネントの群との間に存在するサンプル階層を示す図である。 アセットが仮にこのコンポーネントタイプに対して考慮される場合に制限されると考えられる縦横比値のリストを示す図である。 斜線付きのボックスが要求者によって定められる選択であるＤＢＢを有するワークフローマスターデータの役割を説明する図である。 機能グループ分けに説明されるワークフロータスク及びそれらの構成の処理を示す図である。 ストレージ層の間にファイルを移動する機能を含む管理多層ストレージ環境（ＭＭＳＥ）機能性の使用を示す図である。 ＤＢＢにより編成すべきである符号化及び取り込み管理処理を概説する図である。 クライアントプロフィール、その関連のメタデータ仕様、及びその仕様に従ってパッケージメタデータをアセンブルするのに必要とされるサポートデータの間の関係を示すサンプルエンティティ関係図である。 どのようにパッケージがクライアントプロフィール及び仕様と関連することが予想されるかを示すサンプルエンティティ関係図である。

本明細書で開示する実施例では、デジタル的にコンテンツを取り込んでクライアントへの配送を通じてシームレスにコンテンツを管理するワークフローの自動化をもたらすデジタルコンテンツ配信用システム、方法、及び装置に関して説明する。この説明を読んだ後に、様々な代替的な実施例及び代替用途において本発明を実行する方法が明らかになるであろう。しかし、本発明の様々な実施例を本明細書に説明するが、これらの実施例は、一例としてのみ示されており、制限しないことが理解される。従って、様々な代替的な実施例のこの詳細説明は、本発明の範囲又は幅を制限すると解釈すべきでない。

図１は、本発明の一実施例による配信バックボーンシステムを使用するメディアコンテンツのデジタル配信の処理を示す流れ図１００である。メディアコンテンツの例には、映画、歌、ソフトウエア、及びゲームがある。

図１の示す実施例では、要求は、コンテンツのライセンス供与に向けて及びライセンシーにそのコンテンツの充足に向けてボックス１１０で生成及び提出される。これらの要求は、提出側組織の変動及びライセンス契約のタイプに基づいて多くの形態を取る。履行作動では、コンテンツ（表題／アルファという）の識別、サービスが提供すべきクライアント及び支払期日のようなサービス提供の条件に関する重要な情報を識別するための必要な解析を提供する。

履行処理の次の段階は、ボックス１２０での在庫要件の解析である。ライセンシーにより必要とされる配送品の作成をもたらすことになる製造計画を生成するために、在庫の解析は、各表題／アルファに対して行われる。この解析は、ライセンシー（すなわち、製品）により必要とされる最終配送品、及び生成により作成される元のマスターに即して個別のビデオ、オーディオ、及びテキストコンポーネントに複写マスターから製品を生成するのに使用されるコンポーネントの各レベルを通じた処理の定義で始まる。各クライアント要件に対して、この処理は、様々な形でサービス提供作業又は配送業者により着手される。

各表題／アルファに対して、在庫の状態が分ると、ボックス１３０で製造計画を定義及び生成する。この計画は、複製及び出荷要件のような少数の段階を伴う可能性があり、又は複製及び出荷前に逓降変換、音声再生、及び字幕適用のような処理を伴う可能な製造の複雑化が必要である可能性がある。製造計画は、既存の在庫コンポーネント及び製造ワークフローに関する知識に基づいて判断される。在庫解析及び製造計画に対して以下で詳細に説明する。

製造計画が承認された状態で、それは、ボックス１４０で実行に向けて放出される。この処理は、調達関連の活動、又は標準化されたデータインタフェースによって制御されるファイル管理、トランスコーディング、パッケージング、及び配送のようなコンテンツ処理技術の自動管理を含む企業内製造などを伴っている。

パッケージング及び配送処理（ボックス１５０で行われる）は、履行処理の自動化の継続をサポートする。製品は、クライアントコンテンツ管理システムにより消費することができるようにサポートメディア及びメタデータと共に厳しい規格に従って配送される。これらの規格の変動には、情報及びサポートメディアの管理における柔軟性が必要である。

図２は、本発明の一実施例による配信バックボーンシステム２００のブロック図である。図２の示す実施例では、ブロック図は、マテリアル解析を行って製造計画を生成するのに必要とされるエンティティ及び処理を示している。従って、配信バックボーンシステム２００は、クライアント配送品仕様２３０（クライアントプロフィール２１０を含む）、製造解析エンジン２４０、製造計画エンジン２５０、サポート在庫データ２６０、及びワークフローマスターデータ２７０を含む。製造計画エンジン２５０は、コンポーネントアセットソース２５２、ワークフロー処理２５２、及びコスト及びリードタイム解析２５６を行うか又は使用する。

一実施例では、ワークフローの自動化は、いくつかの在庫及びコンテンツ処理ワークフローにわたって維持されるマスターデータ２７０（詳細説明に対しては付録５を参照されたい）によりサポートされる。製造計画エンジン２５０は、このマスターデータ２７０を利用してクライアントからの要求に応答して特定の製造計画を生成する。これらの製造計画は、コンテンツ処理を管理してコスト及びリードタイム推定に必要とされる情報の要点を生成するコア命令セットを表している。

製造解析エンジン２４０は、要求モジュール（詳細説明に対して付録２を参照されたい）からの入力と共に、ワークフローマスターデータ２７０及びサポート在庫データ２６０（詳細説明に対して付録４を参照されたい）を利用し、要求モジュールは、パートナーとクライアントの関係及び要求が生成される方法を処理する。クライアント配送品仕様２３０を使用して、製造解析エンジン２４０は、適切なワークフローを識別する。ワークフロー内で、クライアント仕様を作成するのに必要とされる全てのタスクが定められる。更に、各タスクに関する全ての必要とされたコンポーネントタイプは、適用可能である場合に定められる。この情報を用いて、エンジン２４０は、まずマテリアル解析を提供する。配信バックボーンシステム２００は、指定の表題／アルファ２２０及びクライアント配送品仕様２３０に対して、必要とされるコンポーネントの在庫に問い合わせる。この解析の結果により、必要とされるワークフローを完了するのに必要であるタスクが判断される。

付録５に説明するように、クライアント仕様に基づくワークフローは、在庫シナリオを考慮すべきである。これらのワークフローは、配送までの必要とされる在庫コンポーネントの符号化及び取り込みを対象とすべきである。本質的にはモジュール式であって必要とされた在庫がより大きな即応性の段階にあるシナリオを処理する柔軟性を達成すべきである。製造解析エンジン２４０は、必要とされる製品を作成するのに必要な特定のワークフローを判断するためにマテリアル解析を提供する。

配信バックボーンワークフローは、次に、パッケージ及び配送される低解像度ファイルへの高解像度ファイルのトランスコーディングを含むことができる。更に、配信バックボーン作業により、低解像度ファイルを作成して制限付き使用代替解像度マスターとしてファイルストレージシステムに記憶することができる。この場合、ワークフローは在庫に質問し、低解像度ファイルが存在するように判断し、高解像度ファイルからのトランスコードではなく低解像度ファイルをコピー及び配送する代替ワークフローを選択することが必要がされる。

詳細設計に基づいて、アセット在庫の動的性質のために、実際のワークフローを実行する前にコスト及びリードタイム目的のために製造計画を再実行することが必要である場合がある。

図３は、本発明の一実施例による配信バックボーンシステムを使用するメディアコンテンツのデジタル配信の技術を示す流れ図３００である。図３の示す実施例では、デジタル配信技術は、ボックス３１０で配送要件及びクライアントプロフィールを収集する段階と、要件の組を反復的に進むことによってボックス３２０でソースアセットの在庫及び解析を行って出力を作成する段階（マテリアル解析の特定の使用事例に対しては図６及び図７の説明を参照されたい）と、ボックス３３０で機能マッピングを行う段階（機能マッピングの特定の使用事例に対しては図８〜図１０の説明を参照されたい）と、ボックス３４０で製造工程を計画する段階（製造計画の詳細説明に対しては図１１の説明を参照されたい）と、ボックス３５０で最適化を行う段階（詳細に対して下記を参照されたい）とを含む。

配送要件及びクライアントプロフィールは、クライアントのコンテンツ、配送、及びメタデータ要件に対して特定の要件の組／仕様を定める。クライアントプロフィールは、コンテンツ配送に関する各クライアントの要件を定めるために使用される。１つ又はそれよりも多くのクライアントプロフィールは、そのクライアントに対して複数のビジネスモデルを表すために、テリトリー別に変える要件を表すために、又は他のビジネス上の理由／技術的な理由からクライアント毎に設定することができる。仕様は、自動化されたワークフロー及び手動のワークフローをサポートするのに必要とされる重要な変数及び要件を定める。仕様マスターが維持されるので、単一の仕様を複数のクライアントに関連付けることができる。機能マッピングは、ソースアセットがクライアント仕様にマップされることを可能にする一連の規則を含む。製造計画により、作業項目、実行段階、及び最適化が判断される。別の実施例では、配信バックボーンシステムは、必要とされるソースアセットを識別し、クライアント仕様に基づいてコンテンツが配送されることになる製造計画を作成する。

図４は、製造計画に寄与する配送要件及びクライアントプロフィールの詳細なレイアウトを示している。上述のように、クライアントプロフィールは、クライアントに対してコンテンツ、配送、及びメタデータ要件を定める特定の要件の組である。一実施例では、クライアントプロフィールは、パッケージ仕様４１０、プリファレンス４２０、技術仕様４３０、及びアセンブリ仕様４４０を含む。パッケージ仕様４１０は、クライアントにより行われた要求をもたらすためにクライアントに配送すべきである個別の項目を定め、かつコンテンツ仕様４１２及びメタデータ仕様４１４を含む。プリファレンス４２０は、ソースアセットの選択を案内して配信バックボーン製造機能を制限するか又は緩和するクライアント特定の要件である。技術仕様４３０は、コーデック、フレームレート、画像解像度、及び他のファイルベースの技術パラメータを定める非コンテンツベースの要件である。アセンブリ仕様４４０は、ロゴ交換、プル／修正のためのブラック、又は追加カードのようないずれかの非線形編集要件を定める。コンテンツ仕様４１２は、再使用可能な技術仕様、アセンブリ仕様、及びプリファレンスデータを含む。

図５〜図８に示すクライアントプロフィールの一例示的使用事例において、クライアント、ＣｉｎｅｍａＳｐａｃｅ、及び国内販売（ＤＳＴ）のためのクライアントプロフィールが、表題「飛行機」及びアルファ「劇場のための」に対してユーザにより識別される。図５において、技術仕様は、１６ｘ９の縦横比及び２３．９８のフレームレートでコンテンツに対するクライアントの希望を示すために示されている。しかし、更に別の技術仕様は、異なるフォーマットを取る機能が表題／アルファに対する有効在庫に基づくことも示している。アセンブリ仕様は、技術仕様からデータと共にトランスコードプロフィールを作成する際に使用される製造計画に直接にデータを供給する。

図６に示すコンテンツ仕様は、クライアントが受諾することができる様々な配送品を表す複数の組のソースプリファレンス及び技術仕様を示している。これらも、クライアントのプリファレンスを表すためにランク付けされる。ソースプリファレンスは、使用することができるソースアセットを見つけるために使用される。図に示す例示的なデータは、同じコンテンツ仕様が４ｘ３又は１６ｘ９である表題を処理することを可能にする。表題「飛行機」は、４×３人のビデオマスターしか有することができない古い方のカタログ表題に選択されたものである。

製造プリファレンスにより、オンボードオペレータは、クライアントプリファレンスに基づいて配信バックボーン機能をオン又はオフにすることができる。従って、図６に示す例において、製造プリファレンスは、３：２の除去、すなわち、２３．９８のフィルムフレームレートから２９．９７のビデオフレームレートへの引き落としを示していない。

図７は、表題「飛行機」７０２及びアルファ「劇場のための」７０４の在庫７００の状態の一例を示している。ボックス７１０、７１２は、表題／アルファに対して存在するソースアセットを表している。ボックス７２０、７２２は、全てのソースアセットがマスター仕様に適合していることを示すために存在する。マテリアル解析が行われた時に、ソースアセット又はコンポーネント仕様を見つけることができる。コンポーネント仕様が見出されれば、結果として表題、アルファ及びコンポーネント仕様情報を含むコンポーネント要件が得られる。コンポーネント要件は、取り込みを管理するのに必要とされるタスク管理ツールである。キット７３０は、コンポーネントが協働することができるように適合及び同期化されたコンポーネント（例えば、オーディオコンポーネント及びビデオコンポーネント）のグループ分けである。協働するように判断されたコンポーネントは、ワークフローマスターデータがキットタイプを指示することを可能にするように編成される。アルファの下では、キットにより、協働するアセットの特定の確認が可能である。キットは、いずれかのオーディオがそのキット内でビデオと協働することになる場合に、１つのビデオコンポーネント及び１つ又はそれよりも多くのオーディオコンポーネントを一般的に有する。クライアント仕様によりサポートされたワークフローマスターデータは、どのオーディオ又はサポートマテリアルがキット内から使用されるかの変動を処理する。

図７に照らして図６を参照すると、マテリアル解析は、技術仕様によって定められた望ましい出力を生成するために行われる。上述のように、マテリアル解析は、システム機能に基づいて、望ましい出力を生成するのに使用することができるアセットが見出されるまでソースプリファレンス及び技術仕様を進む反復処理である。図６に示すように、ソースプリファレンスは、クライアントに対して非技術的プリファレンス又はコンテンツプリファレンスを表す基準の組である。

図６及び図７を再び参照すると、マテリアル解析は、例示的な使用事例に関して行われる。最初に、ランク１のソースプリファレンスは、在庫７００に問い合わせるために使用される。図７に示す例示的な在庫７００において、システムは、１６×９のビデオソース及びステレオ英語オーディオソースを検索する。問い合わせでは、これらのアセットがキット化されることも必要である。しかし、１６×９ビデオアセットがないので、この問い合わせは失敗する。従って、ランク２のソースプリファレンスが、次に、在庫７００を問い合わせるために使用される。この場合、システムは、４×３のビデオソース及びステレオ英語のオーディオソースを検索する。問い合わせでは、これらのアセットがキット化されることも必要である。今度は、問い合わせは成功する。

上述のように行われるマテリアル解析を用いて、機能マッピングが次に行われる。機能マッピングは、技術仕様基準をソースアセット基準に従ってマップすることを可能にする一連の規則である。図８を参照すると、ソースアセットが見出された時に、それらのアセットからデータが抽出される。データは、技術仕様からも抽出される。このペイロードは、規則エンジン８００に供給される。結果は、全ての必要とされた変換が適合することができるという確認及び必要とされた変換の識別である。製造プリファレンスは、クライアントプリファレンスに基づいてシステム機能を不適格と見なす場合がある解析に含まれる。

図８に示す例示的な機能マッピングにおいて、データは、４×３のビデオソース及びステレオ英語オーディオソースが識別かつキット化されたマテリアル解析問い合わせにおいて識別されたアセットから収集される。データは、ランク１技術仕様８１０からも収集されて機能マッピング規則エンジン８００に供給される。この反復は、４×３の画像マスターを１６ｘ９に変換する機能はないので失敗する。ファイルのタイプ変更を定める規則は、網羅的に特定の組合せを認めない下位規則８４０を作成することによって簡素化することができることに注意されたい。それによって全ての可能な基準マッピングの組合せを表す必要性が軽減される。

図９をここで参照すると、データは、ランク２技術仕様８２０からのデータと共にマテリアル解析問い合わせにおいて識別されたアセットから収集されて機能マッピング規則エンジン８００に供給される。この反復は、ここでもまた、（１）４ｘ３の画像マスターを１６ｘ９に変換する機能が前と同様に存在せず、及び（２）クライアントは、他の場合では配信バックボーンシステムの機能であるソフトウエアに基づく３：２除去又はプルダウン９００を通じて処理していないコンテンツを受信するのを好むという２つの理由から失敗する。

図１０をここで参照すると、データは、ランク３技術仕様８３０からのデータと共にマテリアル解析問い合わせにおいて識別されたアセットから収集されて機能マッピング規則エンジン８００に供給される。この反復は、マスターファイルコーデックから技術仕様コーデックに必要とされる変換１０００のみがあって成功する。

図１１は、システム規則及び／又は論理回路を使用して１組の製造機能を導出するための例示的なソース要件１１００、キット１１１０、及び技術仕様１１２０の関連付けを示している。各製造機能は、次に、可能な作業項目テンプレートのリストにマップする製造機能タイプの例である。製造機能は、１つよりも多い可能な作業項目テンプレートをもたらすことができる。図１１の例は、メディアトランスコーディングソリューションをもたらすための２つの作業項目テンプレート、すなわち、サービス１及びサービス２を示している。システムによって定められた規則に基づいて、単一の適切な作業項目、すなわち、サービス１が選択される。作業項目は、「Ｆｒｏｍ」パラメータ（例えば、１６ｘ９）、「Ｔｏ」パラメータ（４ｘ３）、使用すべきシステム（例えば、サービス１）に関する情報を含む。各作業項目テンプレートは、実行段階テンプレート内の１組の対応する実行段階に関連している。図１１の例において、以下の段階、すなわち、作業区域を構成すること、アセンブリマテリアルの位置付けること、及びプロフィールを有するサービス１（ＭＰＥＧ ４）が含まれる。従って、実行段階テンプレートへの作業項目テンプレートのマッピングに基づいて、望ましい実行段階が導出される。

実行段階が識別された状態で、製造計画は、様々な方法で最適化することができる。例えば、製造計画において複雑な複数の段階による変換を伴う事例により、結果として複数の作業項目テンプレートが識別される（冗長性最適化）。これらのテンプレートは、「アセンブリマテリアルを位置付ける」のような冗長な実行段階を有する場合がある。これらの冗長な段階は、冗長性最適化において大幅に低減又は排除することができる。更に、複雑な事例において、一部の実行段階は、並行して又は「フォーマット変換」及び「１６ｘ９から４×３への変換」のような単一の作業で実施することができる。これらの段階は、組合せ最適化中に単一の作業に結合することができる。最適化後に、製造計画は、完全なものである。実行されると、計画は、識別されたソースマテリアルを所要のクライアント配送品に変換する必要なワークフロー編成を生成するのに使用される。

図１２Ａは、コンピュータシステム１２００及びユーザ１２０２の図を示している。ユーザ１２０２は、デジタル配信機能を実行するためにコンピュータシステム１２００を使用する。コンピュータシステム１２００は、デジタル配信処理１２９０を記憶及び実行する。

図１２Ｂは、デジタル配信処理１２９０をホストするコンピュータシステム１２００を示す機能ブロック図である。コントローラ１２１０は、プログラマブルプロセッサであり、コンピュータシステム１２００及びそのコンポーネントの作動を制御する。コントローラ１２１０は、メモリ１２２０又は内蔵型コントローラメモリ（図示せず）から命令（例えば、コンピュータプログラムの形態で）を取り込み、これらの命令を実行してシステムを制御する。その実行において、コントローラ１２１０は、マテリアル解析及び製造計画を行うためなどのソフトウエア処理としてデジタル配信処理１２９０を提供する。代替的に、このサービスは、コントローラ１２１０又はコンピュータシステム１２００内の別々のハードウエアコンポーネントとして実行することができる。

メモリ１２２０は、コンピュータシステム１２００の他のコンポーネントによる使用に向けて一時的にデータを記憶する。一実施例では、メモリ１２２０は、ＲＡＭとして実行される。一実施例では、メモリ１２２０は、フラッシュメモリ及び／又はＲＯＭのような長期的又は永久メモリも含む。

ストレージ１２３０は、デジタル配信処理システム１２９０によって使用されるデータを記憶するためなどにコンピュータシステム１２００の他のコンポーネントによる使用に向けて一時的に又は長期的にデータを記憶する。一実施例では、ストレージ１２３０は、ハードディスクドライブである。

媒体デバイス１２４０は、取外し可能な媒体を受け取り、挿入された媒体にデータを読み及び／又は書きする。一実施例では、例えば、媒体デバイス１２４０は、光ディスクドライブである。

ユーザインタフェース１２５０は、コンピュータシステム１２００のユーザからユーザ入力を受諾してユーザに情報を示すコンポーネントを含む。一実施例では、ユーザインタフェース１２５０は、キーボード、マウス、オーディオスピーカ、及びディスプレイを含む。コントローラ１２１０は、ユーザからの入力を使用してコンピュータシステム１２００の作動を調節する。

Ｉ／Ｏインタフェース１２６０は、外部ストレージ又は補足的なデバイス（例えば、プリンタ又はＰＤＡ）のような対応する入出力デバイスに接続される１つ又はそれよりも多くのＩ／Ｏポートを含む。一実施例では、Ｉ／Ｏインタフェース１２６０のポートには、ＵＳＢポート、ＰＣＭＣＩＡポート、シリアルポート、及び／又はパラレルポートのようなポートを含む。別の実施例では、Ｉ／Ｏインタフェース１２６０は、無線での外部デバイスとの通信用無線インタフェースを含む。

ネットワークインタフェース１２７０は、「イーサネット（登録商標）」接続をサポートするＲＪ−４５又は「Ｗｉ−Ｆｉ」インタフェース（１２０２．１１を含むがこれに限定されない）のような有線及び／又は無線ネットワーク接続を含む。

コンピュータシステム１２００は、コンピュータシステム（例えば、電力、冷却、作動システム）に典型的な付加的なハードウエア及びソフトウエアを含むが、これらのコンポーネントは、簡潔さを期すために図８Ｂでは具体的には示されていない。他の実施例では、コンピュータシステムの異なる構成（例えば、異なるバス又はストレージ構成又は多重プロセッサ構成）を使用することができる。

開示する実施例の以上の説明は、どの当業者であっても本発明を作るか又は使用することを可能にするために示したものである。これらの実施例に対する様々な修正は、当業者に容易に明らかであるし、本明細書に説明する一般的な原理は、本発明の精神又は範囲から逸脱することなく他の実施例に適用することができる。従って、付加的な実施例及び変形も本発明の範囲である。更に、本明細書に示す説明及び図面は、本発明により広義に考えられる主題を表すことを理解すべきである。本発明の範囲は、当業者に明らかであると考えられる他の実施例を漏れなく包含し、かつ本発明の範囲は特許請求の範囲以外のいかなるものによっても相応に制限されないことは更に理解されるものとする。

付録１．デジタル供給チェーンの基礎
「配信バックボーン（ＤＢＢ）」は、ソニーがエンターテインメント供給チェーンサービスにおいてその存在をデジタルへ拡大するための原動力を表している。この原動力の重要性は、デジタル供給チェーンがどのように時間と共に進化して知識及び経験を利用しているかを示している。高度技術、ライフサイクル管理及び実行努力結果からの計画及び解析活動の有効な分離を目標としながら、供給チェーンＫＰＩ（連続的な改良型）、供給チェーン案内原則を利用することによる供給チェーン性能、柔軟性及び２つのサービスの追求がある。ソニー及び多くのパートナーにおける供給チェーンの専門知識は、ＤＢＢがどのように初期公開後に前進してコンテンツ処理機能の高度自動に加えて主導的な運用実施方法を適用すべきであるかに関する考え方が得られるように引き出されることになる。

製品ライフサイクル管理
固有の特性に加えて、製品は、追従することになる一般的なライフサイクルも有する。このライフサイクルは、任意的な蘇生を伴いながら最終期まで遙かに製品の初めから追跡することができる。光学媒体上のエンターテインメントコンテンツの物理的製造からの教示は、需要においてはアイスホッケーのためのスティック的な増加があり、次に、様々な減衰率による減衰曲線があることを教えてくれている。このような知識により、機能強化された機能計画が可能である。

デジタル供給チェーンサービスのプロバイダとして、ソニーは、ＤＢＢに関連する計画活動に供給するデータ点としての顧客の製品ライフサイクルにおいて既得権益を有すると考えられる。このタイプの認識は、ＤＢＢが適切なコストで主導的なサービスレベルを配送しながら非常に高いレベルの効率で運用されることを可能にすると考えられるものである。Ｂ２Ｂ及びＤＢＢのデジタル態様は、製品ライフサイクルの動的特性を変えるが、類似の原理を様々なレベルで適用することができる。例えば、管理多層ストレージ環境は、製品リリース窓を知っていることから恩典を受け、かつオンラインストレージ層において検索待ち時間、並びにストレージのコストを最小にするために層間にファイルの動きを先取りすることができる。更に、製品群は、以下に説明するように、製品のライフサイクルの特性に影響を与える可能性がある。付加的なライフサイクル情報は、表題が業界レベルでのファイルタイプのシフトのような後編又は前編、並びに一般的な状況に即したイベントであるか否かのような属性から導出することができる。

製品群
製品タイプ、処理段階、フォーマットタイプ、ビットレート、及び配送仕様要件の解析は、パターンの識別に至る可能性がある場合が多い。パターンの更に別の吟味は、用語の物理的で実際上の意味において、製造中の製品の固有の特性に基づくグループ分けに至る場合が多い。これらのグループ分けにより、製品を異なる処理及び実行規則を適用することができる群にグループ分けするのに使用することができる自然なセグメント化が得られる。

ＤＢＢは、柔軟であり、かつこれらの製品群に従って編成ワークフローのカスタム化をサポートすべきである。殆どのセグメント化努力結果の場合と同様に、製品群に即したワークフローのアラインメントにより、固有の事例及び例外の全体数が低減される。目標は、実行パイプラインを合理化して柔軟にすることである。それによって供給チェーン内に価値を引き起こす中核になる処理への集中が可能である。

一例として、運用データの解析により、製品の２つの大きなグループ分け、特集と各エピソードの間の共通性が分る可能性がある。各タイプの製品は、そのワーカビリティ（以下で定義）を補助する理想的流れを有することができる。同様に、得られたコンテンツは、生成されたコンテンツと比較すると代替処理又は編成ワークフローから恩典を受けることができる。

ワーカビリティ及びマイルストーン管理
デジタル供給チェーンの構成は、従来の供給チェーンと類似の多くの処理段階の調節を伴っている。活動は、計画が実行に移された状態で合理化された実行を可能にする基礎を築くことを重視して、実行の前に計画される。これらの計画内の主要管理点を定めることにより、より簡単に管理かつ追跡することができる個別のユニットが考えられている。潜在的な遅れを解析すると根本原因まで追跡することができる。従って、主要管理点管理により、ワーカビリティが改善し、実行中の妨げ又は例外が回避される。

ＤＢＢにより行われるワーカビリティ及び主要管理点管理サポートを有することは、ソニーが真にデジタル供給チェーンの顧客とパートナーになることによって卓越した調査拠点になることを可能にする際の中心的柱になる。ＤＢＢは、入力パラメータにより調節されるタイムラインに即して計画されたデフォルト処理段階をもたらすテンプレートを利用することができる。目標日時が確立されると現品に照らして追跡し、調節の影響を相互に理解した上で統一された目標を満たすための共同調査の機会を得ることができる。

ＤＢＢは、マスタリング群からマスターを取得することのようなワーカビリティに影響を与えることができる外部タッチポイントへの依存を有することになる。マスターを受信する主要管理点は、劇場のための表題と各エピソード表題の間の異なるマスタリングリードタイムのような製品群に関連するパラメータを有するテンプレートにおいて捕捉することができる。作業全体を主要管理点に細分化することにより、時間通りに完了されない要件の根本原因を識別しやすくすることができる。これらの要件の解析により、特定の製品群に遅延を関連付けているパターンが見出され（例えば、得られたコンテンツのマスターは、取得を通じて通過するソースマテリアルの管理されていないか又は未知の品質のために遅延が発生する場合があることが多い）、特定の製品群まで遡ることができるその特定のセグメントに関する処理又はシステムの改良に努力を集中することによってワーカビリティに対応しやすくすることができる。

実行戦略及び最適化
これらの重要な基礎が置かれた状態で、更に、最適化を実行することができる。基礎的な要素は、パターンの付加的な識別、並びに人々により駆動された継続的な改善に至る高度な解析を通じて処理することができるデータ点になる。次に、これらのパターン及び処理改良を用いて実行戦略として供給される様々な異なるレベルで規則の組を定めることができる。

柔軟性は、ＤＢＢが固執すべきである重要な信条であり、柔軟性により、最終的に、先に定められた実行戦略の有効な使用が可能になる。システムレベルでは、供給チェーンを最適化する規則の組を適用する機能は、システムの中核になる機能、及び理想的にはＤＢＢの外側でさえも全ての供給チェーンシステムにわたって利用することができるものでなければならない。機能強化された供給チェーン実施方法をサポートするこの拡張性は、ＤＢＢに限定されずに、卓越したエンターテインメント供給チェーン調査拠点を通した統合に利用可能なものにすべきである。

ソニーは、ＤＢＢの初公開に向けてできる限り実行戦略及び最適化を組み込むために既存の知識をプールするつもりである。この知識は、既存のシステム及び処理のデータ点から得られ、かつ今後のソリューションに向けて組み込まれることになる。差し迫った影響は、最高の利益を引き起こす表題及びクライアントが確実にＤＢＢにインポート及び搭載されるように移動実行戦略がどのように定められるかに見られるであろう。最初に、得られた規則は、半自動化された手順で適用することができるが、ソニーの長期的目標は、有用である時にどこでも含まれた自動化で、より組織的に真に実行戦略及び最適化を適用することである。

付録２．パートナーとクライアントの間の関係
１．概要
「配信バックボーン（ＤＢＢ）」には、パートナーにコンテンツ配信の必要性に対応する機能を与えるという考え方をもたらすために特定のタイプのデータの維持が必要である。パートナー、クライアント、クライアントプロフィール、仕様、及び構成は、データがＤＢＢに記憶かつ管理すべきであるいくつかの重要なエンティティである。

２．説明
図１３は、どのようにパートナー及びクライアントがクライアントプロフィール、仕様、及び構成と関連することが予想されるかを示すサンプルエンティティ関係図である。この図の目的は、最終設計を定めることが意図されるのではなく、状態処理マップを満たすために予想される関係のタイプを説明しやすくすることが意図されている。

パートナーは、ＤＢＢのコンテンツ所有者及び顧客である。パートナーは、ユーザを委託し、かつ要求及びワークフロー状態に対する可視性を生成するためにＤＢＢへのアクセスを許可する。各パートナーは、１つ又は複数のクライアントにコンテンツを配信する機能を有する。

クライアントは、コンテンツを受信するパートナーと契約している企業である。クライアント記録は、企業体を定めるのに必要な情報を定めるものである。連絡先情報がこのレベルで存在する場合があるが、連絡先は、以下に説明するようにクライアントプロフィールに関連付けることができる。

単一のクライアントは、例えば、複数のパートナーと取引し、例えば、アマゾンは、ソニー及びパラマウントと取引することができる。個別のクライアント記録が、各パートナーに対して維持される。しかし、複数のパートナーで同じ企業を表す全てのクライアント記録は、全てのパートナーにわたってそのクライアントの概観が得られるように関連付けられるべきである。サンプルクライアントには、アップルとアマゾン（ＤＤＩ）、ＣｏｍｃａｓｔとＡＸＮ（ブロードキャスト）がある。クライアントは、コンテンツ配信に対するパートナー要求をもたらすのに必要に応じてＤＢＢに追加される。

クライアントプロフィールは、コンテンツ配送に関する各クライアントの要件を定めるために使用される。１つ又はそれよりも多くのクライアントプロフィールは、そのクライアントに対して複数のビジネスモデル、例えば、ＤＳＴ、ＤＤＩ、ＶＯＤを表すためにクライアント毎に、又は要件がテリトリー別に又は他のビジネス／理由により変わる時に設定することができる。上述のように、連絡先情報は、複数の連絡先がクライアントに対して存在する場合クライアントプロフィールに関連付けることができる。クライアントプロフィールは、ＤＢＢ管理者により作成されることになる。

仕様は、自動化されたワークフロー及び手動のワークフローをサポートするのに必要とされる重要な変数及び要件を定める。仕様情報は、多くのクライアントにわたって共通であるとすることができる。仕様マスターは、複数のクライアントへの単一の仕様の関連付けを可能にするために維持される。仕様の修正は、クライアントレベルで又はマスターレベルで許可すべきである。従って、クライアントレベルでの修正により、仕様マスター内に新しい記録を得ることができる。マスターレベルでの修正は、変更をその仕様に従って関連付けられた全てのクライアントに伝播させることができる。検証を置いて、複製仕様が作成されないことを保証すべきである。

仕様の機能要件は、コンテンツ処理及び配信をサポートすべきであるが、仕様データの人間が可読な抽出は、精査及び通信を目的としてパートナーが利用可能である。

変数−仕様と関連して一部の情報は、各プロフィールに固有のものであるとして定めることができる。仕様内のこの情報は、クライアントプロフィールに関連付け時に入力変数として定めることができる。例えば、配送仕様は、配送手段を定めることができ、クライアント特定の変数は、縦横比プリファレンスを含むことができる。

構成−構成は、各クライアントプロフィールに対して個々に作成される情報の組である。仕様は、クライアントプロフィールに関連付けることができる再使用可能な情報の組を表し、一方、構成は、クライアントプロフィール特定の及び固有のものとすることができる。一部の事例において、「標準的な構成」は、複数のクライアントプロフィールにわたって再利用することができる。

仕様タイプ−ＤＢＢは、コンテンツ変換及び配送をサポートして複数のタイプの仕様を記憶及び管理する。仕様のタイプには、以下が含まれるが、これらに限定されない。

ａ．製品仕様−ビデオ、オーディオ、画像、キャプション、字幕スーパーなどを含むことができる最終配信製品を作成するのに必要とされる技術的なメタデータを定める。この仕様では、適合技術仕様を有する最終製品を生成するためにトランスコーディングのようなＤＢＢサービスを利用してＤＢＢサービスと共有する。この仕様は、ビットレート、フレームレート、ファイルタイプなどを含む。

ｂ．メタデータ仕様−メタデータ配送品／ファイルを生成するのに必要とされる情報を定める。メタデータ仕様内の入手可能な情報を利用して、システムは、終了状態のメタデータファイルのタイプ（例えば、ＸＭＬ、Ｅｘｃｅｌ、ＣＳＶなど）、並びに特定の表題／アルファに対して含まれるべき特定のメタデータファイル及び値を判断する。メタデータ仕様がメタデータの適切な終了構造を実施するための検証として作用することに注意することが重要である。特定のフィールドが必要とされ、特定のフォーマット（ＹＹＹＹＭＭ−ＤＤ）で供給すべきデータを実施する場合がある。他のフィールドは、反復する値及び管理された語彙を受諾するように定めることができる。メタデータ仕様は、ＤＢＢエンタープライズ正準メタデータリポジトリを解釈するのに必要とされたマッピング及び変換規則を示す。この仕様内で定められたフィールドは、エンタープライズ正準ＤＢＢメタデータＩＤを使用して参照されることになる。

ｃ．他の仕様−付加的な必要とされる仕様は、設計／実施中に識別することができる。

構成のタイプ−ＤＢＢは、コンテンツ変換及び配送をサポートして複数のタイプの仕構成を記憶及び管理する。仕様のタイプには、以下が含まれるが、これらに限定されない。

ａ．アセンブリ構成−コンテンツ処理特定のものであり、製品本質に関する仕様とアセンブリのための構成との分離がある。アセンブリ構成は、コンテンツ、及びロゴ、視聴率、警告コマーシャルブラックのような追加物の外観のアセンブリ及び順序を定める。この情報は、クライアント必要性に基づいてこれらの構成の変動増大のために製品の仕様から分離される。複数のクライアントは、同じファイル仕様及びビットレートを取るが、異なるアセンブリ構成を必要とする場合がある。アセンブリ構成項目の例は、ロゴ、視聴率、バグ、及びオーバーレイ、警告カード挿入、バールトーン及びコマーシャルブラックである。

ｂ．パッケージ構成−パッケージを生成するのに必要とされる情報を定める。パッケージ関連情報には、パッケージングマニフェスト位置／フォーマット、パッケージングコンテンツ命名規則、コンテンツディレクトリ経路、出力パッケージディレクトリ経路、及びパッケージラッバー型定義（例えば、ＭＸＦ、ＺＩＰ、ディレクトリ構造、又はルースファイル）を含むことができる。

ｃ．配送構成−パッケージを配送するのに必要とされる情報を定める。意図するものはデジタル配送（例えば、Ａｓｐｅｒａ、ＳｍａｒｔＪｏｇ、ＦＴＰ）であるが、配送構成では物理的出力を処理することができる。例は、ハードドライブにパッケージを出力して物理アドレスに出荷してもらうことである。この例において、配送構成方法は、「ハードドライブ」である。

ＦＴＰ配送構成が生成されると仮定すると、ＦＴＰのような方法の選択は構成の一部である。ＩＰアドレス、ユーザ名、パスワード、及びポートのような付加的な入力が、配送方法を完全に定めるために入力される。この情報は、クライアントプロフィールに関連のデータの組として記憶される。

ハードドライブ又はＡｓｐｅｒａのための第２の構成をクライアントプロフィールに対して追加することができる。各構成に必要とされるデータは、選択された配送方法に特定のものである。

クライアント／プロフィールステータス−ＤＢＢがクライアント又はクライアントプロフィールにサービスを提供することができるか否かを制御するために、ステータス及び関連の規則は構成可能でなければならない。

プロフィール／仕様の関連付け−クライアントプロフィール内では、複数の仕様を上述の各カテゴリ内で割り当てることができる。類の１つの仕様は、デフォルトとして確立されるが、ユーザは、デフォルトに上書きしてクライアントプロフィールに関連付けられた異なる入手可能な仕様を選択することができる。

一例において、クライアントプロフィールのためのデフォルトの配送仕様はＦＴＰであるが、特定の要求のサイズが大きいために、要求者は、ハードドライブを代替配送仕様として選択することができる。

表題タイプ−上述のように、複数の製品仕様が存在する場合がある。クライアントプロフィールへの製品仕様の関連付け中に、表題タイプの定義付けを可能にする変数がある。それによって特定のタイプの製品、例えば、特集、エピソード、又は予告編に対して仕様を割り当てることができる。処理に向けて選択された各表題は、特集又はエピソードの場合にはデフォルト表題タイプを有するか、又は予告編のみの要求の場合には、表題タイプの選択を可能にする。この変数は、製品仕様が異なれば異なるタイプの表題を処理する必要性をサポートする。

３．ユーザインタフェース
ユーザインタフェースの観点から、管理側パートナー、クライアント、及びクライアントプロフィールは、ユーザインタフェースを通じて処理されることが予想される。これらの特徴は、内部ＤＢＢビジネス解析により主として管理される。しかし、仕様は、本質的に技術的なものであり、ＤＢＢ技術リソースにより一部の場合には管理され、かつ必要であればＸＭＬ内で管理される可能性がある。

４．サービス
サービスは、管理側パートナー、クライアント、クライアントプロフィール、仕様、及び構成に向けてＵＩを通じて以外ではＤＢＢにより公開されない。このデータの管理は、ＤＢＢ内からのみ処理される。

５．インタフェース接続のシステム
パートナー、クライアント、クライアントプロフィール、仕様、又は構成では、外部システムとのインタフェースを利用しない。

６．マルチテナント
パートナーとクライアントの関係に関して上述した概念は、本質的にＤＢＢに対してマルチテナント要件を定めるものである。管理プログラムは、上述の階層関係の作成を可能にすべきである。

付録３．要求管理
１．概要
ＤＢＢでは、ユーザインタフェースは、様々な形態のコンテンツ処理に関する要求の入力を有効化すべきである。要求管理により、クライアント及び必要とされた配送品を識別するのに必要とされる機能性が得られる。このユーザインタフェースは、受注から入金管理までの一連の作業の実施を担うビジネスユーザとＤＢＢの間の主要な相互作用点である。技術情報であれ、ビジネス関連情報であれ、ＤＢＢにより必要とされる全ての明確化情報は、このインタフェースを通じて管理される。事業体の全ての状態要件は、このインタフェースを通じてアドレス指定される。達成可能な範囲で、このインタフェースは、ユーザがより一般的な情報を入力し、要件をもたらすためにＤＢＢにより必要な特異性のレベルにシステムにより案内又はサポートされることを可能にする収集情報を作成するために後述するデータ構造を利用することが意図される。

要求管理は、ここに説明するＵＩに及び以下に説明するようなＤＢＢワークフローの詳細のより粒度の細かいレベルへの許可されたユーザに対するアクセスを許可する１連のユーザインタフェース（ＵＩ）である。

２．説明
図１４は、要求維持モジュールへの主要な入力を示している。

ＬＯＢ入力−ＬＯＢ又は「営業科目」入力は、発信者、例えば、ソニー営業部を表している。これらの部門は、様々な顧客にコンテンツを使用許諾し、要求者からの充足感（例えば、全世界的製品充足感（ＷＰＦ））を必要とする。要求者は、ＤＢＢを使用してこのコンテンツを作成及び配送する。高レベルで、ＬＯＢにより、ライセンス窓、放送日、ライセンスタイプのような取引条項及び他の意義がある情報が得られる。この情報は、要求者により提出される要求に含まれる。更に、ＬＯＢは要求、表題、及びクライアントに関する主要な入力が得られる。一般的に及びパートナーに適用可能なものとして、これは、パッケージメタデータにおいて含まれるか又は課金トランザクションをサポートするのに必要とされる可能性があるビジネス関連情報である。

クライアント−発信者は、特定の要求のために処理すべき１つ又はそれよりも多くのクライアントを指定する。ＤＢＢ要求者は、単一のクライアントが複数のプロフィールを有する事例において、要求内の適切なクライアントプロフィールを判断することになる。クライアント／クライアントプロフィールは、特定の表題に対してＬＯＢと契約をしたコンテンツライセンサを表している。要求作成の前に、クライアントが搭載され、かつ全ての適切なプロフィール及び仕様は作成されたことが仮定される。仕様情報は、プロフィール選択をサポートするために要求者に表示特定のフォーマットで提供すべきである。

表題／アルファ−要求内の不可欠な指令は、１つ又はそれよりも多くのクライアントに１つ又はそれよりも多くの指定の表題を配送することである。付録４．在庫組織化に説明するように、アルファは、特定のテリトリー又は市場に特定のものとすることができる表題内のコンテンツレベルの変動を表している。例えば、「垣根の上に」表題に対して、１つのキャラクターがゴルフクラブで別のキャラクターを叩くシーンは、日本において劇場のための配信のために変更される。この要件に基づいて、いずれかの日本の顧客に全てのポスト劇場のための配信では、同じ編集済みバージョン又はアルファを使用する。

表題／アルファ選択−表題が１つよりも多くを有する事例における特定のアルファの選択は要求者により行われることが仮定される。しかし、この選択は、クライアントプロフィールレベルで及びアルファレベルで存在するメタデータに依存するビジネス規則に基づいてサポート及び／又は自動化することができる。

仕様／構成の選択−コンテンツ仕様及び構成は、定められてクライアントプロフィールに関連付けられる。配送される表題タイプに基づいてクライアントプロフィールに関連付けられた複数の仕様及び構成がある場合がある。付録２．パートナーとクライアントの間の関係に示したように、デフォルトを含む複数の仕様及び構成が存在する場合がある。要求者は、要求内の代替承認仕様を選択することができる。仕様の選択をサポート／自動化する情報が入手可能である。例えば、複数の製品仕様は、クライアントに対してエピソードのコンテンツに対して１つ、特徴コンテンツに対して１つ定められる。クライアントプロフィール維持において、適切な仕様の選択に関するビジネス規則が定められる。これは、この例の目的のために「表題タイプ」値で行うことができる。この同じメタデータは、要求で選択される表題に関連付けられ、それによって表題／クライアント組合せにより必要とされるように本質仕様の識別が容易にされる。

複数の表題／複数のクライアントの要求−要求は、いくつかの異なる方法で生成することができる。以下のもの、すなわち、１つの表題及び１つのクライアント、１つの表題と複数のクライアント、１つのクライアントと複数の表題、及び複数の表題と複数のクライアントは、その例の一部である。

最も複雑なシナリオは、複数の表題／複数のクライアントである。このシナリオの複雑性を最小にするために、複数の表題が選択された時に、全ての選択された表題が各々の選択されたクライアントに提供されることを保証することが望ましい。要求者は、どの表題がどのクライアントに関連付けるかを形成する機能を有していない。全ての表題が全てのクライアントに対して提供されるわけではない事例においては、複数の要求を行わなければならない。

３．ユーザインタフェース
ユーザインタフェース適用により、ユーザは、様々な要求に対して状態を作成、更新、取り消し、及び取得することができる。検索及び要約表示は、同様に仮定される。クライアント／プロフィールの定義及び表題選択には、選択の付加的なサポート及び自動化が必要な事例において、これらは、ウィザードフォーマットで処理され、ユーザは、発注を完了するのに必要な深度まで意思決定処理を進むように誘導される。この深度は、特定のコンポーネント検索及び選択、並びに手動による仕様選択のレベルまでに至るべきである。ユーザに許可される判断の深度は、構成可能であるべきである。特定のソースコンポーネントに関してのような特定のレベルの選択は、運用職員の責任下にあると判断することができる。

４．サービス
要求モジュールサービスは、ＤＢＢ内のみで公開されるように意図され、正式なＡＰＩは、他のシステムとの結びつきを可能にする必要はない。しかし、アーキテクチャは、直接にいずれかのパートナーからの要求データフローを除外すべきでない。

５．インタフェース接続のシステム
要求モジュールは、顧客マスター、表題マスター、ワークフローマスター、及びタスク管理で機能的関係を有する。これらのデータセットは、バックボーン内にあり、適用アーキテクチャのためにインタフェースで接続されない。唯一の例外は、ＧＰＭＳ表題インタフェースである。表題／アルファ情報は、インタフェースで接続され、かつ配信をサポートするのに必要な範囲でバックボーンの内部で記憶される。要求モジュールには、ＤＢＢに記憶されていない付加的な表題情報を表示するためにＧＰＭＳへの直接の問い合わせが必要である場合がある。

６．マルチテナント
ＤＢＢは、付録２．パートナー−クライアント関係において上述したように、マルチテナント機能を有する。複数の「パートナー」には、要求ＵＩへのアクセスが必要になる。ログイン及びセキュリティ特権は、各パートナーユーザ群に対して独立して維持すべきである。データは、本明細書に説明する全てのレベルの情報に対して完全に分離すべきである。

付録４．在庫管理
１．概要
コンテンツ処理自動化技術の使用に加えて、ＤＢＢの重要な目標は、充足ワークフローの全ての面への規則に基づく自動化の拡張を含む。既存のフィルム式エンターテインメント在庫メタデータモデルでは、ソースアセット特定の領域において自動化をサポートするのに必要とされる厳しい編成が所有されていない。アセット受信及びストレージ処理及び一般的に記録されるメタデータには重要な誤り率が発生している。生成実行時間に正しいソースアセットを識別するのに必要とされる得られた手動による試みは、既存のデジタル充足における重要な障害になっている。メタデータ制御の厳密化及び精密化の実行により、アセット選択の自動化を可能にし、かつ手動による介入及び全体的な収量を大幅に低減することができる。

明瞭な在庫をサポートするためにより多くの構造を必要とする２つの重要な概念が識別されている。バージョンという概念は、ソニー用語において「アルファ」に改名されている。この概念は、特定の表題に対して在庫に存在する場合があるコンテンツの変動を表している。この概念に構造を追加することによって在庫の質問の正確化が可能になり、特定の表題内での在庫の互換性のある「キット」を作成される。アルファ組織内では、コンポーネントに基づく在庫では、従来の製造規範がサポートするワークフローとのソースアセットの結びつきをサポートすることによって従来の製造規範を利用する。これらの概念により、部品表により従来の製造の自動化がサポートするのと同様にメディアコンテンツ処理の自動化がサポートされる。

在庫可視性の範囲は、ＤＢＢのＤＡＭソリューション内のデジタルアセットを包含し、パートナー物理アセット管理ソリューション内の外部物理及びデジタルコンポーネントまで拡張される。本明細書に説明する組織化原理が物理アセットに実行される範囲は、コスト及びリードタイム解析に対するビジネス必要性が満たされるように柔軟なものでなければならない。

２．説明
図１５は、２つのアルファ（監督のカット及び劇場初公開）を有する表題と監督のカットアルファにサービスを提供するために識別されると思われるコンポーネントの群との間に存在するサンプル階層を示している。

アルファ−アルファ概念は、ＤＢＢ内の２つの重要な要件、すなわち、バージョンに基づくビデオ又はオーディオコンテンツ変動を伴い、かつそれらの変動にサービスを提供するのに必要とされるアセット在庫の組織化原理としての表題に対するクライアント必要性の識別を容易にするものである。

アルファは、一般的に表題の異なるバージョンを説明するものである。これらの差は、一般的に、表題／アルファをどこにかつどのようにして配信することができるかに関連する。アルファは、特定のテリトリー、市場、又はメディアにおいて表題を表示するのに必要とされる規格及び実施方法編集に基づいて作成することができる。各顧客が自分のプロフィール内に市場、メディア、及びテリトリーの定義を有すると、アルファとの同じデータの関連付けは、選択されたクライアントに対して適切なバージョンの識別の間自動化をサポートすることができる。各アルファとの配信規則の様々な概念の関連付けが必要である。例えば、映画の「レートなし」バージョンは、全世界的なリリースに向けて、ただし、デジタル販売専用に許可することができる。特定の暴力シーン又は不敬なシーンを除去した同じ映画の編集物は、１つ又はそれよりも多くの外国のテリトリーにおけるＴＶ配信のために許可された唯一のバージョンとすることができる。従って、ＤＢＢは、ＤＳＴクライアントのためにレートなしバージョンを、英国ブロードキャスト顧客のために編集済みのバージョンを選択することができる。

アルファはまた、デジタル及び物理の両方でアセット在庫の組織化ツールとしても使用されることになる。既存のビジネス処理により、結果として各アルファに供されるのに必要とされたアセットの群が作成される。様々な縦横比及び規格の画素が、特定の表題の下に各アルファに対して作成される。オーディオアセット及びテキストアセットが、次に、これらの映画アセットに適合するように作成される。特定のアルファにサービスを提供するために作成される全てのアセットの作成、関連付け、及びを包含をサポートする処理が必要である。少なくとも、取り込みでは、ＤＢＢに追加される全てのアセットに対して特定のアルファの識別が必要であることになる。

アルファ概念は、予告編の識別にも拡張される。特定のクライアントに使用する予告編の識別は、様々な完全プログラムコンテンツに適用されるのと同じ規則に従う。

キット−協働するように決められた（適合及び同期）コンポーネントは、まとめるべきである。それによってワークフローマスターデータは、キットタイプを指示することができる。アルファの下では、キットにより、協働するアセットの特定の確認が可能である。キットは、いずれかのオーディオがそのキット内でビデオと協働することになる場合に、１つのビデオコンポーネント及び１つ又は複数のオーディオコンポーネントを一般的に有する。ワークフローマスターデータ（クライアント仕様によりサポート）は、どのオーディオ又はサポートマテリアルがキット内から使用されるかの変動を処理することになる。既存のＤＩＡＭＯＮＤＳアセット（多重オーディオ及びビデオ）は、単一のキットである。

キットタイプは、ワークフローマスターデータに既知であるべきであり、かつ縦横比及び規格のような重要な値に基づいて正しいキットの選択を可能にする属性を有するべきである。

コンポーネント−コンポーネントは、コンテンツ処理のためのソースアセットとして記憶される個別のオーディオ、ビデオ、テキスト、及び／又は結合アセットを表している。コンポーネント概念は、アーカイブ又は保護アセットに拡張することができるが、その主な役割は、特定の製造工程に必要とされるアセットの明確な識別を可能にすることである。コンポーネントは、多くの点において、従来の製造における「部品番号」と類似のものと考えることができる。コンポーネント組織は、重要な物理アセットに可視性をもたらすためにＤＢＢから拡張される場合がある。

ＤＢＢへのアセットの入力は、３つの異なる部分を有する。

ａ．コンポーネントタイプ−コンポーネントタイプは、できるだけ詳細にアセットを説明する仕様を表している。仕様は、コンテンツ処理の鍵であるメタデータフィールドの値の許容範囲を判断する。ＤＢＢに取り込まれる全てのコンポーネントが製造用語におけるマテリアル受け入れと同様にコンポーネントタイプに対して受諾すべきであるように意図している。例えば、１６ｘ９レターボックスＳＤビデオアセットを表すコンポーネントタイプは、各重要フィールドをコンポーネントに対して受け入られるものに適合する値に限定することを可能にする柔軟な仕様を有する。図１６は、アセットが仮にこのコンポーネントタイプに対して考慮される場合に制限される縦横比値のリストを示している。技術データのこのような定義は、コンテンツ処理の鍵である在庫メタデータ値キーに拡張される。

ｂ．コンポーネント要件−コンポーネント要件（ＣＲ）は、特定の表題／アルファ内の特定のコンポーネントタイプに対する要求である。それは、ＣＲがＤＢＢへのアセットの作成及び取り込みを駆動するように考えられている。ＣＲは、要求（付録２．パートナー−クライアント関係）の結果として作成することができ、又はマスタリング群が配信のために表題／アルファを準備するのに必要なＣＲをもたらす製造計画活動を通じて作成することができる。例えば、スパイダーマン４の劇場用アルファは、劇場用配信後のために生成中である。計画群は、８つのビデオコンポーネントに対してバックボーンのためにビデオアセット要件を識別する。これらは、下流側ＤＢＢ生成をサポートするために全て必要とされる、縦横比及び規格が変わるＤＢＢマスター仕様ビデオアセットである。従って、それによってマスタリング群によって提供される８つのＣＲが作成される。アセットがコンポーネント仕様に即して作成されて取り込みに向けて配送された時に、仕様要件に照らした吟味に基づいて取り込みの前に受諾又は拒否される。受諾されると、アセットは、ＣＲをもたらす。

ｃ．コンポーネント（充足された）−ＣＲがアセットの受諾及び取り込みを通じて充足された状態で、コンポーネントは、処理に向けてＤＢＢが利用可能になる。付録５．ワークフローマスターデータにおいて上述したように、各コンテンツ処理仕様は、最終製品を作成するのに必要とされる１つ又はそれよりも多くのコンポーネントを識別することができる。充足コンポーネントが特定の表題／アルファに対して存在する時に限り、コンテンツ処理仕様を実行することができる。

アセット−バックボーン内の豊富なメディアアセットは、上述のようにコンポーネントの本質を表している。アセットは、殆どのＭＡＭ／ＰＡＭシステムにおいて共通であるように独立したメタデータと共に維持される。ＤＢＢにおいて、アセットは、アセット取り込み時に照らし合わされた特定のコンポーネントにも関連付けられる。アセットメタデータにより、ＤＢＢは、表題の間に存在する場合があるコンテンツ処理変数を解釈することができる。

親子関係−親アセットが符号化及び取り込み中に記録されることが必要である。新規マスターコンポーネントがＤＢＢ内の作成される場合にもこの情報を記録することが必要である。この情報リンク機構は、ユーザが、いずれかのＤＢＢアセットを作成するのに使用した実際のアセットを符号化後の物理マスター又は取り込み後のファイルまで遡ることを可能にすべきである。

コンポーネント継続−明瞭な在庫を維持するために、コンポーネントの交換を制御してＤＢＢ内への重複の入力を防止することが重要である。コンポーネント要件が作成されて同じコンポーネント及び表題／アルファの下にアセットがＤＢＢに存在する時に、システムは、重複を識別して解決ワークフローを必要とすることを示すことによって継続を管理する。

３．ユーザインタフェース
ＤＢＢが表題／アルファ生成に向けてパートナーの表題マスターにインタフェースで接続されている間、ＤＢＢのＵＩは、表題及び関連のアルファの直接の作成をサポートすることになる。表題（例えば、表題タイプ）及びアルファ（例えば、縦横比）に関連のパラメータは、ＤＢＢのＵＩを通じて入力する必要があることに注意すべきである。

アルファをサポートするユーザインタフェースには、アルファタイプを作成するのに必要とされる管理構成プログラムが必要である。これらのタイプにより、劇場のためのカット又は監督カットのような共通のアルファタイプを全ての適切な表題にわたって標準化して使用することができる。これらの管理プログラムにより、上述のテリトリー及び市場適用性の概念に関するビジネス規則定義が可能である。共通のビジネス規則に向けてアルファテンプレートを作成するために、付加的なレベルの管理プログラムを必要とする場合がある。

コンポーネントタイプ仕様の作成は、付録５．ワークフローマスターデータと密接に関係があり、かつＵＩの統合された組に含めることができる。このＵＩには、メディアソースが指定されたワークフローをサポートするために満たさなければならない技術要件を含む記録を作成する機能が必要である。これらの記録は、ワークフローに連結され、統合在庫及びコンテンツ処理情報が作成される。

４．サービス
ＤＢＢは、パートナーの表題マスターとインタフェースで接続することができる公開済みのサービスを有するべきである。特にソニーに関しては、これらのサービスは、上述のように表題、アルファ、及び関連の規則をサポートする。

５．インタフェース接続のシステム
ソニー映画エンターテインメント実施に対して、ＧＰＭＳ（グローバル製品マスターシステム）とのインタフェースが望ましい。ＤＢＢは、操作上必要である表題／アルファデータを記憶する。ＤＢＢは、Ｒ１に向けてＧＰＭＳからのインタフェースをサポートするが、パートナーがＤＢＢに表題データをインタフェースで接続することを可能にするＡＰＩに拡張可能でなければならない。ＧＯＬＤシステム（全世界発注ライブラリデータベース）とのインタフェースは、重要物理アセットへのコンポーネント可視性をＤＢＢに与えるのに必要になる。高価である製造シナリオに可視性を与えるために、高解像度ビデオマスター又は吹き替えオーディオ言語のような重要アセットにＤＢＢコンポーネント可視性を拡張することが必要である場合がある。

６．マルチテナント
各パートナーは、ＤＢＢ内にいずれかの数の表題を有する。在庫は、各パートナーの以下の表題の組織化に基づいて分離される。ユーザは、パートナーにより委託しなければならず、そのパートナーに基づいて表題及び関連のアセットに対する権利が与えられる。

付録５．ワークフローマスターデータ
１．概要
ＤＢＢは、できる限りワークフローの自動化をサポートする。既存の履行処理の精査により、一部の処理に対して、ソースアセット選択、コンテンツ処理要件、及び更にはパッケージングに関する判断が特定の規則によって定めることができる。他の処理に対して、曖昧さを明確にするために人間の介入が必要である場合がある。クライアント配送品仕様の継続的な統合及びコンテンツ処理技術により有効化されるソース在庫の簡略化で、ワークフロー処理に関する規則の内在化が可能であり、かつ益々望ましくなる。

更に、自動コンテンツ処理システムに正確な仕様の詳細を供給することが必要とされる。「特注」モデルによりもたらされたエラーがあると、ＤＢＢにおいて仮定される効率の多くのサポートが行われない。技術職員によるコンテンツ処理ワークフローの作成、試験、及び実行により、一貫した性能のための優れたプラットフォームが得られる。簡略化された規則を使用してこれらのワークフローを呼び出す機能により、顧客サービス及びコンテンツ処理を改善する試みの有効な分離が可能になる。

ワークフローマスターデータにより、製造計画をサポートするワークフローを中心としてメタデータが得られる。このメタデータは、クライアント仕様をサポートするのに必要とされるワークフローを識別する。更に、所要のキット及びコンポーネント情報は、在庫の有効な質問を可能にするためにワークフローデータ外でサポートされる。このサポート情報で、クライアント仕様の定義及び必要とされる表題／アルファにより、製造解析エンジンは、製品を作成するのに必要とされた適切なソース在庫要件及びワークフローを判断することができる。ワークフローマスターデータは、製造計画（付録６．製造計画を参照されたい）の要件をサポートするために在庫メタデータ組織化（付録４．在庫組織化を参照されたい）に合わせて作用する。

完全自動化が望ましいが、作戦環境内の柔軟性も重要な要件である。ＤＢＢサービス及びＤＢＢサービスを調節するワークフローは、モジュール式に設計される。ワークフローは、端末相互間処理において入力パラメータ、アクション、及び複数のサービスの出力を調節することができるが、ＤＢＢの基本サービスにアクセス可能であるようにもすべきである。重要タスクは、製造計画を必要としない直接的なＵＩ要件を有することができる作業である。ファイル検索、トランスコーディング、及びパッケージングなどのようなこれらのタスクは、利用者定義パラメータに基づいて実行可能でなければならない。それによって完全には自動化することができない中間ワークフロー又は特殊ワークフローを処理するために、運用職員によるＤＢＢサービスの完全な使用が可能である。

２．説明
図１７は、ＤＢＢでのワークフローマスターデータの役割を説明する。斜線付きのボックスは、要求者によって定められる選択である。斜線なしのボックス内の情報は、ＤＢＢ在庫及びワークフローマスターデータから導出される。

ワークフロー−図１７に示すエンティティ関係は、中核になる要件が製造計画の定義からコンテンツ及びクライアントの識別を分離することであるメタデータ管理の手法を示している。要求者がクライアントプロフィールを識別すると、ＤＢＢは、クライアント仕様を識別することができる。この情報で、ＤＢＢは、指定の製品配送品を作成するのに使用すべきワークフローを判断することができる。これらの処理は、管理職員により作成されて搭載中の処理を通じて綿密に調べられる。

クライアント仕様に基づくワークフロー−製造計画は、クライアント仕様及び表題／アルファの識別に基づいている。ワークフローマスターデータは、クライアント仕様を完成するのに必要なワークフローを定め、かつ各ワークフローの在庫要件を定める。このデータにより、「仮定」シナリオをワークフロー自体のビジネス規則を行使することなくバックボーンを通じて実行することができる。

クライアント仕様に基づくワークフローは、実際には、特定の表題アルファに対して在庫の状態に適合するように設計される一連のワークフローであることになる。例えば、８ＭＢのＭｐｅｇ２出力を作成するように設計されたワークフローは、そのファイルがＤＢＢに存在しない場合、マスタービデオファイルを符号化及び取り込む段階を含むことになる。ファイルがＤＢＢに存在する場合、これらの段階は飛び越されて、ワークフローは、ファイル検索段階で始まる。

ＵＩに基づくワークフロー又は重要タスク−ワークフロー編成ツールは、ＤＢＢサービスとの重要な相互作用点になる。クライアント仕様に基づくワークフローが配信シナリオの規範であることが望ましいが、ＤＢＢ内の全ての重要タスクは運用職員が利用可能でなければならない。例えば、ドイツ語クライアントのための８ＭＢのＭＰＥＧ２の製造計画には、適合済みかつ同期済みのドイツ語のオーディオトラックが必要である。この仕様にサービスを提供するのに必要とされる既存のキットは、軌道を逸している。注文殺到のために、適合済みかつ同期済みトラックは、運用職員に直接に配送され、運用職員は、次に、ＤＢＢからの特定のファイルの検索、適切なトランスコード仕様の選択及び実行、クライアントへのパッケージング及び配送を可能にするように設計された重要タスクを実行する。

重要タスクは、共通の作業をサポートするように特別に設計され、かつ特定のビジネス必要性に基づいて、自動化することができない生成の要件をサポートする。

編成−ワークフロー編成ツールは、ワークフローを実行するのに必要とされるタスクを作成、管理、及び編成するのに使用されるように仮定されている。このツールは、コンテンツ特定、クライアント特定、又はその他に特定である場合があり、ワークフローがどのように実行されるか、及び／又はワークフロー内のどのタスクが必要かに実質的に影響を与えるビジネス規則の介在及び質問を可能にすべきである。

サポートデータ−ワークフローは、編成すべきタスク及びその依存を定める。これらのワークフローは、在庫選択及び課金要件及び他の入力を容易にするサポートデータと対話する。このデータには、以下が含まれるがこれらに限定されないこととする。

これらのワークフローは、以下の情報を一般的に含む。

ａ．タスク−タスクは、ソースマスター要素から最終クライアント配送品まで進むのに必要とされるワークフロー内のいずれかの段階として定められる。これらのタスクには、符号化、取り込み、ＱＣ、トランスコード、ウォーターマークなどが含まれる。ワークフロー編成ソリューションは、新しいコンテンツ処理技術及び自動化の拡張をサポートするのに必要とされたタスクの柔軟な作成／構成を可能にする。タスクは、コンテンツ処理編成の主な構成ブロックである。各タスクは、手動又は自動化とすることができ、かつ状態及び状態に関連のプリファレンスを有する。完全な説明に対しては付録７タスク管理を参照されたい。

ｂ．課金トランザクション−行われた作業は、ＤＢＢ内の支払い請求可能なサービスに関連付けられるべきである。課金トランザクションは、課金システムによる料金表情報の質問に必要とされる情報を含むことになる。付録１３．財務処理では、課金トランザクションがバックボーンによりどのように管理されるかを概説している。ワークフローは、ワークフローが完了する時に課金トランザクションが作成及び報告（又は「ステータス化」）されるように、財務報告の必要性に適合するように設計される。

ｃ．キット−協働するように判断された（適合及び同期された）コンポーネントは、一括して編成される。それによってワークフローマスターデータは、キットタイプを指示することができる。アルファの下では、キットにより、協働するアセットの特定の確認が可能である。キットは、いずれかのオーディオがそのキット内でビデオと協働することになる場合に、１つ又はそれよりも多くのビデオコンポーネント及び１つ又はそれよりも多くのオーディオコンポーネントを有する。ワークフローマスターデータ（クライアント仕様によりサポート）は、どのオーディオ又はサポートマテリアルがキット内から使用されるかの変動を処理する。既存のＤＩＡＭＯＮＤＳアセット（多重オーディオ及びビデオ）は、単一のキットである。キットはまた、字幕使用、字幕スーパー、及び他のコンテンツタイプを含むことができる。

ｄ．コンポーネントタイプ−必要な時に、タスクにより必要とされる入力コンポーネントタイプを識別すべきである。この情報は、表題／アルファが要求内で指定された時に、アセット在庫の解析をサポートする。この情報は、製造計画及び実行（付録６．製造計画、付録７．タスク管理、及び付録８．管理多層ストレージ環境を参照されたい）の中核になる要件を表している。

ワークフロー変数−ワークフローにより、コンテンツ処理事例に対して変数の構成が可能である。例えば、異なる表題の２つのビデオアセットは、共通のコンポーネントタイプを共有することができる。しかし、アセットレベルのメタデータは、コンテンツ処理に影響を与える差異を示すことができる。ワークフローマスターデータ内の変数は、２つのソースファイルにおいて差異に基づいて異なるコンテンツ処理タスク又はタスクの組の選択が可能である。

図示の処理流れ図は、ワークフローメタデータにより制御すべき作業の範囲を対象とする。ワークフローの一般的なカテゴリは、以下の通りである。
ａ．符号化／取り込み−ＤＢＢへのソースアセットの入力。
ｂ．製品変換−自動化及び手動によるコンテンツ処理。
ｃ．メタデータ作成−クライアント特定のメタデータの作成。
ｄ．サポートメディアの検索−サポート画像、チャプター静止画のような手動又は自動化による検索
ｅ．パッケージング−製品、メタデータ、及びサポートメディアへのパッケージング仕様の適用。
ｆ．配送−クライアントへのパッケージの配送。

３．ユーザインタフェース
ワークフローマスターデータの作成及び維持には、コンテンツ処理仕様を識別して特定のワークフローに組込みかつリンクさせることを可能にする柔軟なユーザインタフェースがある。ＵＩは、ワークフローを表す記録の作成を可能にするものであり、かつ各ワークフローを適切なクライアント仕様及びコンポーネントタイプとリンクさせることを可能にすべきである（付録２．パートナー−クライアント関係を参照されたい）。ワークフロー及び関連のマスターデータは、簡単にコピーかつ再構成すべきである。在庫組織化情報がワークフローマスターデータを維持及び実行するツールセット／サービスと完全に一体化されたことがＲ１において仮定されていないことに注意すべきである。

重要タスクユーザインタフェースは、ＤＢＢ内のサービスに直接アクセス可能であるようにすることが必要である。これらのＵＩに関しては、付録６．製造計画、付録７．タスク管理、及び付録８．管理多層ストレージ環境においてより詳細に説明する。

４．サービス
製造計画エンジンは、データにアクセスするが、最終アーキテクチャ判断に基づいて、単一のデータベース呼び出しでデータにアクセス可能である。

５．マルチテナント
ワークフローマスターデータの共有は、共通の配送品に使用されるワークフローが複数のパートナーにより利用されることを可能にするパートナーインスタンスにわたって行うことができる。しかし、この機能は、本質的に管理的であると考えられる。ＵＩ及びデータ層は、パートナーインスタンスにおいて完全に分離すべきである。料金表情報は、上述のように、パートナーによる変動、同じく一部の場合には特殊取引料率をサポートすべきである。

付録６．製造計画
１．概要
ワークフロー自動化は、付録４．在庫組織化及び付録５．ワークフローマスターデータで上述したように、マスターデータによりサポートされるべきである。これらの節及びそれらの要件では、全ての在庫及びコンテンツ処理ワークフローにわたって維持されるマスターデータを説明する。ＤＢＢは、このマスターデータを利用して要求維持モジュールからの要求に応答して特定の製造計画を生成する。これらの製造計画は、コンテンツ処理の編成の中核になる命令セットを表しかつこの計画により、コスト及びリードタイム推定に必要とされる情報の要点が生成される。

ユーザの介入がなくても製造計画を作成及び実行することが望ましいが、これらの計画の運用上の操作が、一般的ではない事例を処理するのに必要であることが理解される。この情報層及びそのコンピュータの機能は、頻繁な運用上の介入がＤＢＢの耐用期間の早期においてサポートされるように、変わりなく柔軟でなければならず、この頻度が下がる時に高度な計画の完全自動化もサポートすることができる。

２．説明
図２は、ＤＢＢにおいて製造計画を作成するのに必要とされるエンティティ及び処理を説明するものである。製造解析エンジンは、付録２．パートナー−クライアント関係に説明した要求モジュールからの入力と共に、付録４．在庫組織化及び付録５．ワークフローマスターデータに説明したワークフローマスターデータ及びサポート在庫データを利用する。クライアント仕様により、エンジンは、必要とされる適切なワークフローを識別することができる。ワークフロー内で、クライアント仕様を作成するのに必要とされる全てのタスクが定められる。更に、各タスクに関する全ての必要とされたコンポーネントタイプが、適用可能な場合に定められる。この情報で、エンジンは、まずマテリアル解析を提供する。ＤＢＢは、指定の表題／アルファ及びクライアント仕様に向けて必要とされたコンポーネントがないかＤＢＢ在庫を問い合わせる。この解析の結果により、必要とされるワークフローを完了するのに必要であるタスクが判断される。

付録５．ワークフローマスターデータにおいて上述したように、クライアント仕様に基づくワークフローは、全ての可能な在庫シナリオを考慮すべきであることになる。これらのワークフローは、配送までの必要とされる在庫コンポーネントの符号化及び取り込みを対象とすべきである。それらは、本質的にはモジュール式であり、かつ必要とされた在庫がより大きな即応性の段階にあるシナリオを処理する柔軟性を提供すべきである。製造解析エンジンは、必要とされる製品を作成するのに必要な特定のワークフローを判断するためにマテリアル解析を提供する。

ＤＢＢワークフローは、次に、パッケージ及び配送される低解像度ファイルへの高解像度ファイルのトランスコーディングを含むことができる。配信バックボーン作業により、低解像度ファイルを作成して制限付き使用代替解像度マスターとしてファイルストレージシステムに記憶することができる。この場合、ワークフローは在庫に質問して、低解像度ファイルが存在するように判断し、高解像度ファイルからのトランスコードではなく低解像度ファイルをコピー及び配送する代替ワークフローを選択することが必要とされる。例えば、スパイダーマン３に対して、８ＭＢのＭＰＥＧ２ファイルが作成され、かつファイルストレージシステムに記憶される。所要のワークフロー内では、ビデオマスターファイルの符号化及び取り込み、検索及び８ＭＭファイルへのトランスコードのタスクは、８ＭＢ、すなわち、制限付き大体解像度マスターが存在するので不要になる。この場合、ワークフローは切り詰められる。スパイダーマン４に対して、全てのワークフローは、代替使用ファイルが存在しないので符号化以降から必要であると考えられる。

詳細設計に基づいて、実際のワークフローを実行する前にコスト及びリードタイム目的のために製造計画を再実行することが必要である場合がある。これに関する理由は、アセット在庫の動的な性質である。製造計画により、結果としてパートナーに対して厳しい資金の支出になる場合があり、従って、実行前に承認を必要とする場合がある。クライアントによる起動をサポートする単一の要求には、複数の承認が必要である場合がある。承認期間中に、条件はＤＢＢ内で変わる可能性がある。必要とされたマスターファイルの取り込みが発生した可能性があるか、又は既存のマスターファイルはＱＣＨＯＬＤ上に設けられている可能性がある。従って、初期解析により、ＤＢＢ外でＣＯＦＡのために使用されるコスト及びリードする時間の予想のみが得られる可能性がある（付録１３．財務処理を参照されたい）。承認された状態で、製造解析エンジンは、第２の解析を実行し、実質的な変更がないかを精査し、何も存在しない場合、製造計画を実行する。

コスト推定−付録５．ワークフローマスターデータ及び付録１３．財務処理に説明するように、ＤＢＢは、料金表を記憶することになる課金システムとインタフェースで接続する。課金トランザクションは、価格設定計算を容易にするために料金表データを利用する。製造計画が作成される時に、価格設定計算に必要とされる変数は、マテリアル解析の結果に基づいて収集され、価格設定は、識別されたワークフローにより判断されるとして定められる。この情報は、承認ワークフローにおける使用に向けて捕捉される。

リードタイム推定−各処理のリードタイムを推定しなければならず、ワークフローの総合リードタイムを作成しなければならない。計算の方法は、まだ分かっていない。真の潜在的な可能性計画は、ＤＢＢの初期範囲を超える場合がある。しかし、最近の歴史的なデータの解析を行ってリードタイムを推定することができると考えられる。

要求モジュール対話−この情報は、承認を得るために要求者に示されることになる。リードタイムは、矛盾の可能性又はより高い優先度の必要性にフラグを付けるために支払期日と比較されることになる。コストが示されており、コストにより、ユーザは、承認ワークフローを開始することができる。

製造計画修正及びリリース−製造計画は、ソースコンポーネント要件、課金トランザクション、リードタイム推定、及び所要のワークフローから構成される。ＤＢＢ運転群による手動の精査及びリリースに向けてフラグを付ける場合があるビジネス規則により吟味されることが製造計画に必要である。これは、特定のタスクの存在に基づく可能性があるか、又は特殊な状況に基づいて要求レベルでフラグを付される可能性がある。製造計画の運用上の精査の規則は、柔軟かつ構成可能でなければならない。この段階は、計画が固有又は曖昧な状況を考慮するようにＤＢＢ運転群により修正されるように必要である。例えば、特定のワークフローは、特定のソースコンポーネントを指定する場合がある。しかし、クライアント承認で、異なる質の劣るソースファイルを使用することができる。これらの代替ソースファイルは、ＤＢＢに存在する。要求は、運用上の精査に向けてフラグが付され、この処理中に計画内のソースアセットは修正される。修正が完了すると、計画は、実行に向けてリリースされる。

３．ユーザインタフェース
１つ又はそれよりも多くのＵＩは、ＣＯＦＡ承認の前に製造計画の精査、修正、及びリリースをサポートするのに必要である。ＵＩはまた、ＣＯＦＡ承認前又は後に課金トランザクションを修正することも必要になる。課金トランザクション要件の完全な説明に対して、付録１３．財務処理を参照されたい。

４．サービス
要求レベルデータは、ウェブサービスを通じて提出することができる。製造解析エンジンは、次に、必要な情報を生成すると共に要求応答することができる。ＤＢＢと記載された課金システムオプションの間の可能なサービスに関しては、付録１３．財務処理を参照されたい。

５．インタフェース接続のシステム
製造解析処理では、在庫入手可能性を判断するためにソニーのＧＯＬＤ及び／又はＣｉｎｅＳｈａｒｅアプリケーションのようなサポートシステムへの問い合わせが必要である場合がある。

６．マルチテナント
一貫した収量を維持するために、パートナー間のレベル読み込み及びタスクの優先順位付けが望ましい。

付録７．タスク管理
１．概要
ＤＢＢには、ワークフローマスターデータによって定められるようにワークフローを編成する機能が必要である。製造計画により、実行のためのワークフローのアセンブリ、作動的修正／綿密な調査、承認、及び提出が可能である。提出されると、タスク管理機能は、ＤＢＢのサービス層と対話して、タスクを提出し、応答を取得し、必要に応じて更新、記録、及び通知を提供する。

ワークフロー及びそれぞれのタスクにより、ＤＢＢへのソースコンポーネントの取り込みが管理される。更に、ＤＢＢは、物理的在庫の重要なコンポーネントをモニタし、ワークフロー管理により、手動のマスタリング又はアセット調査／検索活動に通信層が拡張される。この広い適用範囲において、いずれかのタスクによりＤＢＢプロバイダ又は販売業者へ手動のワークフロー命令が与えられるように構成することができると仮定される。技術及びコスト利益解析により、いずれかの処理が自動化される範囲が判断される。重要な要件は、重要物理的アセット作成から配送確認までの全てのワークフローに関するタスクのステータス及び依存性がＤＢＢ内で可視であるべきであることである。

２．説明
命令がＤＢＢにおいて開始された時に、製造計画が生成される（付録６．製造計画を参照されたい）。提出の承認時に、製造計画により、待ち行列管理機能にタスクが提出される。ワークフロータスク及び構成の処理は、図１８に示す機能グループ分けに説明している。これらの機能の技術的な構成は、詳細設計及び実行上の問題によって変わる場合がある。

ワークフロータスク−付録６．製造計画において上述したように、製造計画は、承認された要求をもたらすのに必要なワークフローを含む。時点に関わらず、複数のワークフローが進行中である場合があり、その多くでは、類似のタスクが同じＤＢＢサービスによりにより完了する必要がある。待ち行列を管理し、優先度を制御し、ステータスを可視にするために、ワークフロータスクは、ＤＢＢ内で具体化すべきである。ワークフロータスクは、ワークフロー編成ツールにより適切な待ち行列に追加される。データは、ステータス、処理の順序、開始及び終了時間、及びタスクの性質及びその親ワークフロー及び要求を定めるのに必要とされる運用情報に関してこれらのタスク内に維持される。

優先度−要求レベル優先度は、構成可能なユーザ権限及び／又はパートナー構成に基づいて要求モジュールにおいて割り当てることができる。要求レベル優先度は、付録６．製造計画に説明した製造計画修正段階中に変更することができる。優先度は、表題／アルファレベルで修正することができ、それによってユーザは、他と異なる方法で要求内の１つ又はそれよりも多くのライン項目に優先順位を付けることができる。ワークフロータスクレベル優先度は、以下に説明するタスク待ち行列管理機能内でも修正することができる。タスク依存性は、定めているワークフロー内でセットに基づくものである。

ワークフロータスク構成−ワークフロータスクにより、ＤＢＢに存在する様々なサービスの実行が管理される。ワークフロータスクには優先順位を付けることができるが、タスクの実行の順序の解析は、サービスに対して待ち行列に入れられた全てのタスクが優先度の順序で処理されるようにサービスレベルで行われる。タスク構成により、タスク管理機能が解析を行って開始時刻から設定された持続時間を超えた遅れたタスクに関して報告することを可能にする閾値をモニタすることがサポートされる。タスクカテゴリには、以下が含まれるがこれらに限定されない。

ａ．手動のタスク管理−ＤＢＢタスクＵＩにより、ＤＢＢパートナー／販売業者サービスプロバイダへの手動のタスクの連絡が可能である。このウェブ対応ＵＩにより、ＤＢＢワークフローをサポートして提供すべきタスクに関する作業待ち行列情報が供給される。例えば、このポータルにより、ＤＢＢ内への入力のためのアセットの配送を容易にするファイル移動機能が得られる。このタスクタイプにより財務以外の精査及び承認ワークフローも容易にされる。電子メール通知がこれらの処理をサポートするように構成可能であるように仮定されている。

ｂ．符号化／取り込みワークフロー管理−コンポーネント要求作成、符号化、記録、及び付録１０．取り込み／符号化管理に説明するような取り込みを含むＤＢＢ内へのアセットの入力をサポートするのに必要な全てのタスクが必要である。これらのタスクのいくつかは、上述の手動のタスク管理を通じて編成することができる。

ｃ．外部参照ファイル配送及び適合済みコンポーネント検索−適合済みアセットの外部作成をサポートするために、オーディオ又はビデオ参照ファイルは、配送に使用される添付ＵＲＬと共に販売業者に配送することができる。これは、適合済み／同期済みコンポーネントの作成の構造体になる提案中のワークフローサポートである。

ｄ．外部ウェブサービス統合−ＤＢＢは、多くの目的のために外部システムでウェブサービス統合をサポートする。初公開に向けて仮定された１次目的は、Ｒ１に向けて及び後のリリースにおける他の第三者システムのためのＣｉｎｅＳｈａｒｅ、ＧＯＬＤＧＰＭＳからの画像、チャプター静止画、表題レベルメタデータ、及び他のパッケージ要件の検索である。

ｅ．ファイル管理−タスクは、ファイルの検索及びＤＢＢストレージシステムへの及びそこからのａｓｐ移動を制御し、かつポリシー及びワークフロー要件に基づいてＷＩＰストレージからのファイルのパージ処理をサポートする。

ｆ．コンテンツ処理−全ての識別された形式のコンテンツ処理デバイスとの対話。

ｇ．パッケージング−顧客仕様に基づくパッケージメタデータの生成及び配送のためのパッケージの作成。

ｈ．配送−識別された方法によるクライアントへのパッケージの配送。

財務更新−いずれかのワークフローは、財務処理を容易にするためにステータス及び／又は他の必要とされたデータを供給するように構成することができる（付録１３．財務処理を参照されたい）。

要求ステータス−ワークフローは、ワークフロービジネス規則において構成されたように要求にタスク進行状況を提供すべきである。

以下の機能は、ワークフロー編成ツール内に埋め込むことができるが、ＤＢＢを通じてタスクの収量を管理することが必要である。

待ち行列管理−待ち行列管理機能は、ＤＢＢ内の様々な列の収量をモニタ及び維持して優先度及び依存性に基づいて実行の順序を判断する。この機能は、ＤＢＢサービス層との対話を通じてタスクの速度／流れを制御する。

タスク更新−ＤＢＢサービス層は、各タスクに対してステータスを示す。ステータスを受信すると、タスク更新機能は、適切なステータスにタスクを更新して記録及び通知関数を供給する。

タスクモニタ−この機能は、全てのタスク管理機能及び待ち行列をモニタし、誤差報告を提供し、時間解析を処理し、かつ一般的に待ち行列処理の一体性をサポートする。

タスク管理運用ＵＩ−ＤＢＢ管理者として、手動及び自動化によるワークフロー及びタスクの管理が必要である。管理優先度及びタスクの順序は、コンテンツ供給チェーンを効率的に稼動させておくために管理者を使用する中核になる機能性のうちの１つである。

通知−電子メール通知は、タスクレベルで構成可能である。これらの通知は、運用中の必要性に基づいて規則により又は要求（要求者／クライアント通知）の必要性により駆動される。

重要タスク−付録４．ワークフローマスターデータにおいて上述したように、重要タスクは、運用職員により直接に実行することができるワークフローである。これらのワークフローで、ＵＩは、入力パラメータの直接の入力を可能にすることが要である。ＵＩでは、重要タスク内での処理に向けてソース在庫の直接の識別が必要である。重要タスクの一部の例は、ファイル検索、コンテンツ処理及び配送であり、かついずれかのコンテンツ処理活動を含むことができる。

３．ユーザインタフェース
タスク管理運用ＵＩは、運用職員のための精査及び解析の高度な方法を提供する。タスクは、それを超えた状態で警報をトリガし、次に、作業に即して精査可能である許容範囲レベルで構成することができる。タスクタイプ、ワークフロー、コンテンツ処理ファーム、クライアント、パートナー、又は要求のような様々な基準によるタスクの選択及び精査は、問題を迅速に識別及び解決するのに必要になる。

重要タスクＵＩは、ワークフローのモジュール性に依存しており、重要タスクＵＩにより、入力パラメータに直接アクセス可能であるようになる。これらのプログラムは、在庫検索、識別及び検索が殆どの重要タスクと共通であるので類似のテンプレートから機能することができる。付加的なワークフローＵＩは、この基本的なＵＩに取り付けることができる。

４．サービス
ワークフロー編成ツールは、ＤＢＢのサービス層と対話してタスクを提出し、例外を管理、記録、通知などをするのに使用することができる。このツールでは、以前のタスクタイプを実行するために様々なサービスが必要である。

５．インタフェース接続のシステム
基準アーキテクチャは、Ｒｌのための全ての計画的なインタフェースを示すが、タスク管理は、画像、チャプター静止画、及び他の豊富でないメディアの検索のためにＣｉｎｅＳｈａｒｅ、並びに表題レベルメタデータのためにＧＰＭＳとインタフェースで接続することができる。財務トランザクションを制御する処理に向けて、かつ在庫可視性に向けて、ＤＢＢは、ソニーのＸｙｔｅｃｈ実施であるＧＯＬＤとインタフェースで接続する。

６．マルチテナント
ワークフロー及びタスク管理ＵＩ及びサービスは、クラスター式であるが、単一のインスタンス及びバージョンであり、かつ配信される機能を有することが好ましい。それによって機器セットが１つのパートナー特定であるか又は複数のパートナーの間に共有される場合には、ＤＢＢは、個別のコンテンツ処理機器セットに関して複数のパートナーのために作業に優先順位を付けることができる。ワークフロー規則は、要求を開始したパートナーに基づく異なる行動を考慮するものである。

付録８．管理多層ストレージ環境
１．概要
ＤＢＢでは、多量のデータを管理して、デジタルストレージ上に記憶する機能が必要である。デジタルファイルは、ビデオ、オーディオ、画像、テキスト、又はＤＢＢクライアントへの配信に向けてパッケージすることができるいずれかの他のメディアタイプとすることができる。ストレージの既存のコスト及びファイルの予想容積／サイズを考慮すると、管理多層ストレージ環境（ＭＭＳＥ）を含むストレージシステムが要件であることが予想される。それは、ファイルは異なる層／タイプのストレージ上に記憶することができるので完全にオンラインのソリューションより経済的であるストレージの中心点を提供すべきである。

２．説明
ＤＢＢは、ファイルのデジタルリポジトリーを有するので、ファイル管理に関連するサービスが必要であると考えられる。１つのこのようなサービスは、アップロード／取り込みサービスである（付録１０．取り込み／符号化管理を参照されたい）。ＤＢＢにファイルをポピュレートするために、アップロード処理が、外部ソースからＤＢＢストレージの位置付けられたインスタンスにファイルを移動するのに必要である。全てのファイルは、ＷＩＰストレージにファイルを移動する承認されたサービス要求が生成されたか、又はポリシーによりＭＭＳＥ内の他の層にファイルを移動される時間まで初期取り込みで層１ストレージに移動すべきである。

ＤＢＢの必要とされる別のサービスは、進行中作業（ＷＩＰ）検索処理である。コンテンツ情報処理サービスをサポートするために、ＭＭＳＥ上に常駐するファイルは、最初に、ＷＩＰストレージの区域にコピーする必要があり、次に、ファイルは、コンテンツ処理サーバ（例えば、トランスコーディング、パッケージング）に直接アクセス可能である。ＤＢＢＷＩＰストレージへのこのファイルのステージングは、作業命令は完全に承認され、製造計画タスクに対応するコンテンツは処理のための待ち行列に追加された時に限り実行すべきである。

ＤＢＢは、ストレージのどの層に存在するかに対してファイルの各インスタンスを認識しているべきである。ＤＢＢは、不要なテープ活動を低減するために生成待ち行列においてどのファイル必要とされたか理解すべきである（すなわち、特定のソースファイルが命令＃１２で要求されて同じファイルが命令＃２１５でも要求された場合、パージポリシーではその第２の命令を考慮すべきである）。

ＷＩＰストレージ内の機能を維持するために、保持及びパージ処理ポリシーを設定することが必要になる。これらのパージ処理ポリシーは、ＷＩＰストレージ固有のものになり、以下を含むいくつかの主要な要素に基づくことができる。

ａ．時限式満了−ファイルサービス提供が行われ、このファイルの使用を必要とする未処理の承認済み製造タスクがないと、時限式パージ処理イベントが起動すべきである。この時限式イベントは、ファイルが手付かずのまま３０日を過ぎるとファイルはパージされるという内容とすることができる。

ｂ．作業命令ステータスタイプ−サービス提供イベントの完了は、いくつかのの異なる作業命令タイプにより識別することができ、かつ保持ポリシーの解析をトリガする（すなわち、一部の場合には、時限式満了をトリガする）ことができる。「キャンセル」作業命令タイプは、作業がもはや続行されず、従って、ファイルは、もはや作業を完了するのに必要ではないことを示している。次に、「完了」作業命令ステータスは、デジタルコンテンツの配送及び受信を含む全ての活動が完了したことを示している。サービス提供完了をトリガするために他の作業命令タイプを識別することができ、これらは、その適用において構成可能であるべきであることに注意すべきである。

ｃ．未処理承認済みサービス提供タスク−時点に関わらず、ＷＩＰストレージ上に常駐する既存ファイルの使用を必要とする承認済み製造／サービス提供タスクは、時限式満了カウントをリセットすることができる。このファイルは、次に、パージされる懸念なく、タスクが優先順位を付けられて実行されるまでＷＩＰストレージ上のままである。

ｄ．ファイルメタデータ−保持ポリシーは、ファイルに関連のメタデータにより引き起こすことができる。この例において、予告編又は他のメディアは、長時間のためのビデオより長い保持ポリシーを有することができる。この使用は、非常に多い可能性があるが、満了／保持ポリシーは基準としてファイルメタデータを利用することができるべきである。必要なメタデータを有するのでコンポーネントのみがこの特徴を利用することができることに注意すべきである。

ＤＢＢは、ＭＭＳＥソリューションを使用してデジタルコンテンツを記憶するためのコスト効率が高い拡張性のあるソリューションをもたらす。メディア及びエンターテインメント業界は、符号化／ビットレート／実行時間に基づいて潜在的にファイル当たり５００ギガバイトを超える大きいファイルと連動する。こういう理由から、コスト及び拡張容易性は、この上なく重要である。ＤＢＢには、ストレージ層（例えば、ニアライン→オンライン、オフライン→オンライン）間にファイルを移動し、並びにＭＭＳＥソリューション内で機能計画をサポートする予定ファイル保守規則を設定する標準的なＭＭＳＥ機能性の使用が必要である。ＤＢＢのためのストレージ層は、層１ａ−オンライン−高速回転ディスク、層１ｂ−オンライン−低速回転ディスク、層２−ニアライン−自動化可能な検索があるテープライブラリ、層３−オフライン−手動の検索によるテープライブラリ外である。詳細に対しては図１９を参照されたい。

規則は、ＤＢＢ内で網羅的にコンテンツを管理するものである。規則は、ファイル／コンポーネントタイプに基づいてストレージ層間のファイルの動きを予定するように設定される。各ファイル／コンポーネントタイプは、ストレージの各層に関する満了持続時間、並びにディスク利用高ウォーターマークを付して設定される。この機能性は、パートナー優先度による修正に向けてユーザインタフェースを通じて拡張されることが予想される。

ストレージシステムの層１内の１つの区域は、進行中作業（ＷＩＰ）ストレージ特定であり、かつＤＢＢにより管理すべきである。このＷＩＰストレージは、トランスコーディングのような様々なコンテンツ情報処理サービスによって使用される。これらのサービスに使用される機器がデータを処理する前にローカルストレージに時折最初にコンテンツを移動するが、データストア間にこれらのマルチギガバイトの大きいファイルを移動する必要性を除去することによって処理時間を改善することが期待される。これには、層１ストレージとコンテンツ処理サーバの間の超高速接続が成功すべきである。

ＭＭＳＥは、ＭＭＳＥ健全性に関してより積極的なフィードバックを行うためにインフラストラクチャー管理サービスと一体化している。これらのサービスはまた、ＤＢＢがより良好にサービスを編成して管理者にポテンシャル問題に対して注意を喚起することをサポートするためにＣＰＵ、帯域幅、及び他の基準を評価しやすいように他のＤＢＢハードウエア（例えば、コンテンツ処理サーバ）とも一体化している。

ＭＭＳＥソリューションでは、テープ上に記憶されたコンテンツに関していくつかの規則、すなわち、アセットを記憶することが絶対に必要でない限り複数のテープにわたってスパンされる（すなわち、アセットが未使用空白テープのサイズを超える）のを防止する機能、テープ上でコンテンツタイプを分離する（すなわち、テープ上でグループ分けされた特定のタイプの要素を有することのみが選択され、従って、単に１つの小さい要素にアクセスするために無関係なテープにテープスロットを埋めさせる必要性が防止される）機能、アイドル時間及び特定の維持窓でＤＲが行われるようにテープの複数のコピーを有する機能を考慮する。

３．ユーザインタフェース
設計に基づいて、エンドユーザインタフェースの必要性が殆どない場合がある。システム管理者がＤＢＢ環境にわたってメディアを管理するためのデフォルト規則を設定するのではないかという期待がある。これらが管理者のみが利用可能な制御であるので、この機能性には、厳しいユーザインタフェース指針がなく、及び独創的な機能性を殆ど使用するものと予想される。しかし、ＤＢＢパートナーにインタフェースを通じて公開される特定の特徴があるように考えられている。例えば、パートナー優先度に基づいて、特定のコンテンツオーナは、全てのコンテンツがニアライン又はオフラインストレージに移動されるのではなくオンラインストレージ上のままであることを求めるように考えられている。更に、ある一定の「ホットな表題」は、規格表題よりも長い期間にわたってオンライン上にあることを必要とするように考えられている。これらのプリファレンスを設定することにより、ＤＢＢは、これらの判断を可能にする作る値／パラメータを通すようにＭＭＳＥと対話することができるべきである。

殆どのファイル管理活動は、ＤＢＢのエンドユーザに継目なしであってユーザインタフェースは不要とすべきである。ＭＭＳＥ内の層間のファイルの移動及びＷＩＰストレージへの移動は、自動的に行われるべきである。ユーザが気付かせるべき唯一の情報は、ファイル準備（例えば、ステージング環境への移動）及びファイルサービス提供（例えば、変換）に必要とされた予想処理時間に存在する。ユーザインタフェースが予想される１つのシナリオは、サポートメディアのアップロード／取り込みの場合である。アップロード／取り込み、ＦＴＰ、ウェブベースのアップロード、及び他の配送ツール（例えば、Ａｓｐｅｒａ、Ｓｉｇｎｉａｎｔ）に向けていくつかの機構が存在することも注意すべきである。

４．サービス
サービスとしてＤＢＢに公開すべきある一定のＭＭＳＥ特徴がある。サービスとして公開されると予想される特徴は、以下である。
ａ．ストレージ層間のファイル移動
ｂ．メタデータを用いる満了ポリシーの設定（デフォルト規則の上書き）

全てのファイル管理活動は、ＤＢＢ公開のサービスを通じて管理すべきである。本節において上述のファイル管理要件を処理するために、以下のサービスを公開する必要がある。

ａ．ファイルアップロードサービス−このサービスでは、パートナー特定のテナントパーティションに向けてパートナー指定の位置から層１ストレージにファイルを移動すべきである。このサービスへの入力では、ファイル名が同じままであるべきか、又はファイル名変換表現に従うべきか指定すべきである。

ｂ．ＷＩＰサービスに即したファイル検索−このサービスは、入力として、移動すべきファイル及びファイルの得られる宛先位置を指定するファイルポインタを受信すべきである。宛先位置は、ＷＩＰストレージのテナントパーティションであることになる。

ｃ．手動のパージ処理サービス−このサービスは、入力として、ファイルポインタを受信すべきである。自分のコンテンツをパージする要求を手動で要求を開始するパートナーの場合には、このサービスでは、作業確認後にＭＭＳＥ上で常駐する全ての適合するコンテンツをパージすべきである。

ｄ．保持サービス−ＭＭＳＥは、保持ポリシーでストレージを管理すべきである。これがＭＭＳＥ機能性又は公開されたサービスであるか否かに関わらず、両方のストレージ環境は、コンテンツの移動／パージ処理をトリガする前に複数の基準を評価すべきである。本明細書において上述のこれらの基準は、このサービスへの入力であるべきであり、かつ作業命令ステータスタイプ、ファイルメタデータ、未処理承認済みサービス提供タスクの存在、及び時限式満了を含むべきである。

ＭＭＳＥは、ＤＢＢにサービスを通じて統合すべきである。これらのサービスは、例えば、ＤＢＢのＤＡＭを含むシステム又はＤＢＢ製造計画を管理するシステムからの呼び出しを有効化するためＤＢＢに組み込まれる。

ＤＢＢの設計に基づいて、インタフェースは、殆どのファイル管理の特徴をサポートするために存在しなくてもよい場合がある。メタデータに対する多くの依存性が保持基準としてあるが、このデータ全てのＤＢＢに利用可能であるべきであり、外部インタフェースは、不要であることが予想される。アップロード／取り込みは、システムインタフェースを必要とすると思われる唯一の特徴であるが、これらのインタフェースは、デジタル配送ツール（例えば、Ｓｍａｒｔｌｏｇ、Ｓｉｇｎｉａｎｔ）を通じて処理され、かつ殆どは構成を通じて設定される。

６．マルチテナント
ＭＭＳＥ及び全体的なストレージソリューションは、パートナーのための両方の専用インフラストラクチャー、並びにＤＡＤＣが共有ストレージプールからの複数のテナントに供される共有モデルをサポートすべきである。ＤＢＢ内で管理中のデジタルファイルの影響を受けやすい性質を考慮すると、マルチテナントアーキテクチャは、コンテンツサービス提供に必要とされた全ての潜在的なファイル移動を処理するように設計及び設定すべきである。ＭＭＳＥストレージは、交差汚染を防止するために仮想的に及び論理的に分割することができるべきであり、ファイル管理活動は、使用中の適切なパーティションを常に認識すべきである。

７．所有権及び運用の総コスト
ＭＭＳＥは、ＤＢＢの中核になる権能付与的な基礎である。ＭＭＳＥにより、ＤＢＢにより目標とされる財務利益を減らさない所有権及び運用総コストが示されている。ＭＭＳＥは、ＤＡＤＣにより目標とされる第三者ビジネスにも即応するものである。

付録９．検索
１．概要
ＤＢＢには、そのインフラストラクチャーを通して検索機能性が必要である。検索は、内部ＤＢＢデータ（例えば、パートナー、クライアント）にかつ外部データリポジトリとのインタフェースにわたって行われるべきである。しかし、検索の今後の適用は、ＤＡＭシステム及び知的所有権管理システムを含むがこれらに限らない他のインタフェースに適合すべきである。これらの要件を満たす機構は、判断されておらず、ソリューションは、様々になる可能性がある。

２．説明
ＤＢＢに関する検索は、２つのタイプ、すなわち、エンドユーザによる検索及びシステムによる検索に分割することができる。

エンドユーザによる検索は、検索の特徴を説明する時に一般的に考えられるものである。エンドユーザは、多くの異なる理由からＤＢＢにわたって検索を提供する。以下は、予想エンドユーザによる検索の特徴のリストである。

ａ．表題／アルファ検索−適切な表題又は要求中の表題／アルファを選択するためにパートナーによって使用される。これには、パートナーの表題／ＩＰ管理システムとのインタフェースが必要であり、かつ以下を含むがこれらに限定されない複数の入力基準が必要である。
ａ．表題（完全なテキストワイルドカード検索）

ｂ．表題タイプ（例えば、特集、エピソード）−値の制御されたリスト

ｃ．仕様検索−適切な仕様を見つけるためにＤＢＢ管理者によって使用される。仕様は、多くの仕様の差異が非常に軽微であると考えられる詳細を含む。適切な仕様が使用されるように完全な適合を見つけるために迅速に仕様を検索及びフィルタリングする機能は非常に重要である。

ｄ．コンポーネント検索−ＤＢＢに存在するコンポーネントを調査するためにパートナーによって使用される。コンポーネントは、固有に各コンポーネントを説明する多くのメタデータフィールドを含む。コンポーネント検索機構は、全てのメタデータフィールドにわたって検索して結果をフィルタリングし、正確なコンポーネント適合を固有に識別する機能を提供すべきである。

ｅ．サポートマテリアル検索−ＤＢＢに追加されたサポートマテリアルを検索するためにパートナーによって使用される。これらのサポートマテリアルは、コンポーネントと比較すると極小のメタデータを有する。メタデータのレベルは、文書リポジトリーがどのようにこのタイプのメディアを管理するかに依存する。少なくとも、検索は、ファイル名又はフォルダディレクトリ構造のようないずれかの入手可能なメタデータを含むべきである。

ｆ．クライアントプロフィール検索−要求に対して適切なプロフィールを検索するためにパートナーによって使用される。この機能性は、パートナーが階層（例えば、クライアント＞クライアントプロフィール）を通じてクライアントプロフィールをナビゲートすることができるテキスト検索又は閲覧検索を通じて提供することができる。

ｇ．クライアント検索−充足に向けてクライアントを選択するためにパートナーによって使用される。これは、クライアント名に関する簡単なテキスト検索、又はＤＢＢ内の入手可能なクライアントをスクロールする閲覧機能であるべきである。

ｈ．要求検索−進行中又は提出済みの要求を見つけるために要求側によって使用される。

ｉ．製造計画検索−製造計画がワークフロー及びタスクレベル（特にステータス別に）で行われることになる提出後として定義／作成された時に、オペレータ又は要求側によって使用される。

システムによる検索は、その内蔵機能を実行するためにＤＢＢにより行われる。この最も良好な例は、ＤＢＢ製造計画機能性を見ることによって説明することができる。例えば、要求を生成するために、パートナーは、配送に向けて表題／アルファ及びクライアントプロフィールを指定する。この入力があると、ＤＢＢは、ファイル及び物理的の両方である既存のコンポーネントにわたって検索を提供し、かつ多くのビジネス規則に従う必要がある。これらの検索は、システム管理者によって構成可能であり、かつ製造計画見積もり時に実行する必要がある。

以下は、予想されるＤＢＢシステム検索のリストである。

ａ．コンポーネント検索−いくつかのメタデータ基準が与えられると、最も良好に適合するコンポーネントを見つけるためにＤＢＢにより行われる問い合わせ。検索のための入力としてＤＢＢによって供給されるデータは、複数のソースから引き出すことができるが、一般的に要求又は関連の情報により判断される。入力には、以下が含まれるがこれらに限定されない。
○表題ＩＤ−これは、要求処理中にパートナーにより選択されるデータである。
○アルファ−これは、要求処理中にパートナーにより選択されるデータである。
○パートナーＩＤ−これは、特に特定のパートナーにより作成されるコンポーネントを検索するためにフィルタとして使用すべきである。注：コンポーネントは、パートナー間には共有されない。
○付加的な仕様メタデータ−これは、クライアントプロフィールに関連の仕様において指定されたデータである。この情報は、要求によりパートナーがクライアントプロフィールを選択する必要がある時に見出される。サンプル仕様情報は、ビットレート及びフォーマットのような技術的なメタデータを含むことができる。

３．ユーザインタフェース
設計に関わらず、特定の検索基準入力には、エンドユーザ入力が必要である。検索インタフェースには、できるだけ最小のユーザとの対話が必要であるべきである。ユーザインタフェース画面に基づいて、いくつかの設計概念が、有効なＵＩを有効化するために可能であるべきである。全ての検索タイプに対して、「ワイルドカード」又は部分適合化の使用が利用可能であるべきである（例えば、「Ｓｐｉｄ」では、「スパイダーマン」の全ての結果が得られるように結果が表示される）。

ａ．基本検索−テキストによる入力を行うために１つのテキストボックスが使用される最も一般的な検索インタフェースであるが、いくつかの所定のフィールドにわたる検索。

ｂ．上級検索−より多くの定められた検索基準（例えば、日付範囲、マルチ選択）を作成するために実行前にいくつかのメタデータフィールドのために検索パラメータを指定することによるデータソースにわたって検索。

ｃ．ファセットに基づく検索−動的に結果セットをフィルタリングすることができる付加的な関連の属性が得られる検索オプション。検索された結果のカウントは、各「ファセット」の隣に表示されるべきである。

ｄ．検索精緻化−結果を精緻化するために、表示された結果セット内で追加された基準を検索する機能。

ｅ．提案−ファジー適合又は論理のための機能。「…という意味でしたか？」というタイプの論理を特徴とする。理想的には、インデックスに基づく「先読み」提案が利用可能であると考えられる。

ｆ．結果ナビゲーション−定められた分類／グループ分けにより設定された検索結果を横断する機能。

検索結果は、その全体において又は自動ページ化戦略を通じて精査することができるセットで表示すべきである。更に、結果セットが定められる閾値を超える場合には、システムは、ユーザに検索基準を精緻化するように促すことになる。

更に、検索サービスの速度／応答性は、ＤＢＢの操作性及び効率に極めて重要である。

４．サービス
内部／外部システムにわたって検索を有効化するために、検索サービスは、各外部／内部データソースに向けて作成されかつＤＢＢに公開する必要がある。サービスとしてこれらの検索インタフェースを公開する理由は、インタフェースがＤＢＢを通して異なる目的のために一部の場合に複数のシナリオに使用されることになるからである。共通のサービスを作成することにより、これらは、より簡単に利用されることになる。各データソースに対して、各タイプのデータを問い合わせるサービスが公開すべきである。更に、必要な応答時間をもたらすために、データソース及びサービスに及ぶインデックスを作成することを必要とする場合があるであろう。

サービスは、特定のデータタイプ（セキュリティ許容）に対して全ての利用可能なメタデータの問い合わせ及びデータ検索を行うために拡張可能であるべきである。例えば、外部知的所有権管理システム（例えば、ソニーの場合はＧＰＭＳ）に問い合わせるサービスが作成された場合、入力は、入力の複数の基準（例えば、表題名及び表題タイプ）が得られるように十分な情報を含むべきである。サービスは、出力に向けて望ましいメタデータフィールド（例えば、表題、年）を指定するための手段にもなるべきである。

５．インタフェース接続のシステム
いくつかのシステム／サブシステムは、データ共有を有効化するために問い合わせを受けることが予想される。識別されるシステムのいくつかは、以下である。

ａ．メディアアセット管理−製造計画推定のためにマテリアル解析を行う時に、ＤＢＢ内部メディアアセット管理サブシステム及びその構成サービスに問い合わせる必要がある。

ｂ．ＧＯＬＤ／アセット管理−ＤＢＢシステムは、製造計画中にアセットメタデータを検索すべきソースに向けて外部既存のアセット管理システムＧＯＬＤとインタフェースすべきである。

ｃ．作業命令−ＤＢＢシステムは、適切にタスクを割り当てて、次に、完了された作業に対してパートナーの代金請求を容易にするためにデータを結合するためにＤＢＢにより行われている作業に関連するデータを記憶すべきである。パートナーのために二重入力を最小にするために、ＤＢＢは、可能な場合システム統合を通じて作業命令ライン項目／要求を受信するように注視する。

６．マルチテナント
渡された値としてパートナー別の検索結果をフィルタリングすることができるという必要性以外に、検索に対しては特定のマルチテナント要件はない。

付録１０．取り込み／符号化管理
１．概要
ＤＢＢは、符号化（又は捕捉）の処理ワークフロー、次に、コンポーネントの取り込みを管理する。この編成において、ＤＢＢへの受諾を通じた製造計画における新設コンポーネントの作成の要求で始まって、メタデータは、清浄なデータ及び従って明瞭な在庫の作成をサポートするために継続され、捕捉され、かつ手動及び自動化による処理を通じて確認される。

捕捉とも呼ばれる符号化は、物理テープから通常マスターファイルを作成するが、ファイルからも作成することができる主にして手動の処理である。これは、ステータスが特殊又は符号化の組に対して既知であるような管理された処理であることが重要である。更に、外部販売業者がその後に所要のメタデータを入力し、かつ処理の次の段階取り込みをトリガするようにファイルを伝達すると、管理ワークフローは、同様に調節されるように追跡されることを可能にする。

本明細書に定めるような取り込み処理は、一部の場合にラッバー内での符号化されたコンポーネント又は符号化されたコンポーネントの組の受信で開始される。稀な例外フロー以外では、コンポーネントは、製造計画を通じて（反応処理）又はファイルマスタリング要求から（積極的作成処理において）作成された待機中コンポーネント要件なしでＤＢＢに取り込みすることができないように意図されている。ファイル受信段階から受信したファイルは、ファイルの一体性を検証し、品質検査を提供し、技術的な記録処理を実行し、次に、ＤＢＢストレージシステムに正式にファイルを取り込んで待機中コンポーネント要件内のコンポーネントに対して必要なメタデータを更新／作成するためにいくつかの自動化及び手動による段階を通過する。

２．説明
図２０は、ＤＢＢにより編成すべきである符号化及び取り込み管理処理を概説するものである。

要求及び管理されたワークフローを通じて制御される仕様に基づく符号化及び取り込みは、自動化を容易にするために、良好に形成された在庫を必要なメタデータ及び関係で維持することに関連するのでＤＢＢに関する重要コンセプトである。コンポーネントタイプ仕様は、到来アセットの作成、及び次に到来アセットの受信を要求するための一般的なテンプレート及び制御としてマスタリング／アセット管理群によって定められるような作業により作成及び維持することができる。コンポーネント要件は、表題／アルファに対する識別タイプのコンポーネントの要求を表すものであり、コンポーネント要件により、コンポーネント要件に照らして受信すべきシェル記録が作成される。それによって在庫メタデータの均一性を保証する規則を所定の位置に置くことができる。

コンポーネント要件は、主として２つの方法で要求を通じて作成される：
ａ．反応的に、コンポーネントを符号化し、次に、未処理順序での使用に向けて取り込みすることを可能にする製造計画から、及び
ｂ．積極的に、新規デジタル公開（特集及びＴＶコンテンツ）のためのコンポーネントの作成をもたらすマスタリング計画に基づいて。

販売業者は、マスター仕様内に定められているように、取り込み処理を開始する販売業者に拡張されたアプリケーションインタフェースを通じてＤＢＢへのファイルの転送を開始する前に定められた量のコンテンツＱＣを提供する。販売業者で又は遠隔操作で行われるサービスは、販売業者がコンポーネントに対して所要のメタデータを入力し、並びにファイルの移動があっても確実に不正行為又は打切りがもたらされないようにするために転送後に検証すべきファイルに対してチェックサムを計算することを可能にする方法にもなる。

取り込み処理は、通常は符号化完了後にファイル受信開始で開始する。取り込み処理では、必要であればコンテンツを開封することを含め、チェックサムを自動的に確認する（符号化販売業者からの配送パッケージ仕様の未処理最終定義）。

チェックサム検証の完了の後に、コンポーネントメタデータ及びファイルは、アセットの定められた特性がコンポーネントタイプ仕様の許容範囲内であることを確認するために品質検査される。技術特性は、ファイルから自動的に抽出され、メタデータは、自動技術及びコンテンツＱＣにおいて達成可能であることに基づいて検証される。いずれかの自動ＱＣ処理から結果のログは、今後の参考のためにシステムに記憶及び保持すべきである。

コンポーネントの一体性が確認された状態で、待機中コンポーネント要件との適合化が、販売業者からのファイルに伴うべきであるメタデータに対してシステム内のコンポーネント要件記録上のメタデータに基づいて受信したファイルに対して行われる。これは、関連付けに殆どの場合は確認のみが必要であるアシスト型の手動の処理であるが、複数のオプションを系統的に識別すべきであるか（通常は不良な到来メタデータの結果として）、又は検索を通じてオプションがシステムにより識別されない場合は、リスト内のコンポーネント要件に手動でアセット記録を適合させることができることも必要とされる。

次の処理は、以下の段階に使用すべき高忠実度フレーム正確プロキシを生成することである。プロキシを使用して、オーディオトラック及び縦横比及びＤＢＢへの最終取り込み前のそのメタデータの確認のようなファイルの一部の量の付加的な手動の検査がある。

次の段階は、コンポーネントに関する技術的なロギングである。これは、現在、ビデオコンポーネント（及び同じ取り込み処理内である場合は関連のオーディオコンポーネント）に対してのみ考えらおり、手動の活動として考えられる。技術的ロギング機能は、各セグメント（内外のポイント）に関するタイムコード情報及び必要に応じてクロッピング座標と共にコンポーネントセグメント識別（すなわち、バー／トーン、コマーシャルブラック、ロゴ、プログラム）の捕捉を伴っている。更に、この技術的ロギング処理は、ファイルサイズが特にＨＤに対して扱いにくくなるのでフレーム正確プロキシ対実際の本質ファイル上で行われることが好ましい。更に、これは手動のタスクとして計画されるが、手動の努力を主に技術的ロギングデータの確認／調節に変えることができるセグメントの一部の量の割り出し及び自動適合化／識別が提案されることも望ましい。

指紋鑑定は、表題／アルファを固有に識別するために後で使用することができるファイルに対して固有の署名を作成するためにファイル上でその後に行われる処理である。これは、製造計画がこのアセットを待って待ち行列に入れることができるのでその方が効率的であるが、実際には、ファイルがＤＢＢのストレージシステム内に入った後に行われる場合もあり、そうでない場合もある。

取り込み処理内の最終段階には、ファイル一体性の検証、最初に捕捉されたチェックサムの比較、次に、管理のためのＤＢＢストレージシステムへの取り込み処理位置からのファイルの転送が含まれる。コンポーネント要件データ及びコンポーネントファイルに伴う到来メタデータの最終確認が行われ、かつオペレータにより検証することができる。更に、システム内では、コンポーネント要件は、更新されて充足されたステータスであり、システムを通してその可視性を提供する。

適合済みビデオ及びオーディオコンポーネントがまとめて取り込まれた時に対して、オーディオだけ又はクローズトキャプション（ＣＣ）コンポーネントだけが取り込み管理処理に通される場合に、この処理に一部の変動がある。以前と同様に、一部の変動は、要求の結果であり、かつ管理符号化処理から現れる。このフローにおける大きな相違点は、これらのコンポーネントがビデオアセットに適合することになることを保証するために、ビデオアセットに関連付けられることが意図されており、オーディオの基準コピーに照らして確認する必要があるという点である。これは、オーディオ及び／又はＣＣの適合の確認に向けて作成された規定のプロキシを通じてサーバ側上で行うことができる。代替的に、これは、ローカルに行うことができるが、ローカルでは、ＤＢＢからワークステーションへ基準ビデオを移動させるという要件のために好適度が劣る。

オーディオのみ又はＣＣコンポーネントがストレージシステムに取り込まれた状態で、単一又は複数のキットに関連付けられることがこのタイプのアセットに必要とされる。この処理は手動であるように意図され、コンポーネント要件を使用して在庫制御機能の一部として予め又はコンポーネント要件がもたらされた時に、取り込み後に行われる。

最後に、システムに既に存在するが、拒否又は再マスタリング努力のために入れ替えられるアセットに対して必要なビジネス及びシステム論理を考慮するために、これらのワークフローの特定の「入れ替え」変形があることになる。

３．ユーザインタフェース
ユーザインタフェース（ＵＩ）は、内部を含む場合もあればそうでない場合もある異なる販売業者とすることができる符号化及び取り込みオペレータがアクセス可能である必要がある。従って、豊富かつ対話型でありながら、インタフェースは、外部ユーザに確実に示されるべきであり、かつ外部販売業者による訓練は異なると仮定することができるので直観的でもあるべきであることが必要である。このＵＩを使用する異なる販売業者は、他の販売業者により作用されたファイルに対して可視性を有するべきではない。更に、好ましくは、ＵＩによる上述のようなサービスは、メタデータ入力及びチェックサム計算のような初期コンポーネント転送前の準備に対して符号化販売業者をサポートすることが必要である。

また、上述のキット作成／更新要件を満たすために、ＵＩは、関連の充足済みコンポーネント及びキットに対するオーディオアセットのみ及びＣＣアセットに関するコンポーネント要件に即して必要である。

４．サービス
符号化ワークフロー及び取り込みワークフローをサポートするのに必要とされるいくつかのサービスがある。最も基本的な部分では、これらの処理が、管理ワークフローであるので、ワークフロー編成サービスは、この処理内のタスクを容易にして処理測定基準を捕捉するのに利用すべきである。符号化サービス自体は、ＤＢＢの一部と直接的には考えられず、マスターファイル定義内に定められているようにコンポーネントファイルを作成するために販売業者により利用される第三者ツールであることが予想される。しかし、符号化転送前サービス／アプリケーションは、ファイルの一体性を保証するために取り込み処理にファイルを移動する前に販売業者がチェックサムを作成することを可能にするのに必要とされる。

取り込み内では、いくつかのサービスがあることが必要であり、集中化されるサービスもあり、又はローカルに実行されるサービスもあると考えられる。これらのサービスには、ファイル移動チェックサム、指紋鑑定、技術的及びコンテンツＱＣの自動化、コンテンツ処理（必要に応じて）、メタデータ検証、及び技術的ロギングがある。

取り込み処理の終わりに、ファイル管理、ストレージ管理、及びメタデータ管理サービスは、そのストレージシステム内のＤＢＢの管理下にファイル、並びに対応するメタデータを置くために呼び出される。

キット関連付け機能は、メタデータ管理サービスを主として利用する。

５．インタフェース接続のシステム
この機能性に必要とされる直接的なインタフェース接続のシステムはない。しかし、ＤＢＢ内の在庫がＧＯＬＤにおいて反映されることが意図されたので、到来コンポーネントのためのメタデータは、同期化されてそのシステムに更新する必要がある。

更に、直接的にはＤＢＢの一部ではないこの処理に使用されるコンポーネント／ツールセットが全体システムといずれかのリモートデータ及び対話をより緊密に統合するためにインタフェースで接続されることが理想的であると考えられる。

６．マルチテナント
システムは、複数の位置から符号化中及び取り込み中であるコンテンツをサポートすることができ、かつコンテンツがどのパートナーに属するかを識別する（メタデータを通じて）ことができなければならないこと以外、特定のマルチテナント要件はない。

付録１１．パッケージメタデータ
１．概要
本明細書では、パッケージの一部として配送に必要とされる様々なタイプのメタデータをアセンブルするのに必要とされる処理及び機能性を説明する。

２．説明
図２１は、クライアントプロフィール、その関連のメタデータ仕様、及びその仕様に従ってパッケージメタデータをアセンブルするのに必要とされるサポートデータの関係を示すサンプルエンティティ関係図である。この図の目的は、最終設計を定めることを意図するのではなく、ＳＰＥ将来的ステータス処理マップを満たすために予想される関係のタイプを説明しやすくすることを意図している。

クライアントプロフィール−クライアントプロフィールは、作成中のものが確実にクライアント要件に適合に適応させるためにＤＢＢ製造工程全体を通して調節源として作用する。

メタデータ仕様−特定のクライアントプロフィールに関するメタデータ要件を定める。メタデータ仕様は、どのメタデータを必要とするか、各データ要素がどこに位置するか、どのようにＤＢＢメタデータ正準にマップされたか、及びあるとしても、クライアントの好ましいフォーマットにおいてメタデータを供給するためにどのような変換を必要とするかを示している。

サポートデータ−サポートデータは、パッケージの一部として配送されるのに必要とされるデータの全てを形成する。このデータは、様々なＤＢＢデータストア、すなわち、要求、表題／マスター、及びファイルリポジトリー内に見つけることができ、かつメタデータ仕様にマップすべきである。それは、ＤＢＢ外の追加データを必要とするイベントにおいて、インタフェース（ユーザ向き又はシステム間）を通じて各要求にサポートマテリアルとして供給されることになる。

表題マスターデータ−表題は、要求をもたらすために検索、取り出し、及び製造することを可能にするコンテンツに関する最高水準の組織としてＤＢＢ内に維持された知的所有権を説明するマスターデータである。例示的には、表題、概要、タレント、ジャンル、視聴率、及び著作権ラインがある。

要求データ−要求データは、要求を生成するのに使用された契約条件特定の情報を含む。例示的には、販売開始日、販売終了日付、及び価格がある。

技術データ−パッケージに含まれるアセット及び／又はファイル特定のメタデータを定め、かつアセットタイプ、ファイル名、ファイルサイズ、及びチェックサムのような要素を含む。

パッケージマニフェスト−パッケージのコンテンツを定める。これには、各表題に対して供給されたアセットの全ての一覧表を含むことができる。

他のデータ−様々なクライアントは、チャプター化メタデータのような説明しなかった付加的なメタデータ要件を有する場合がある。こういう理由から、メタデータ仕様は、完全に柔軟である必要があり、それによってクライアント必要性をサポートするためにデータの追加又は除去が可能である。

メタデータ正準性
ＤＢＢは、変動を除去し、かつ共通のメタデータ言語が確実にフィールドレベルで及び値レベルで話されるようにするために厳しい語彙目録を課すメタデータ正準性が必要である。パートナーメタデータ仕様は、個々のクライアントメタデータ仕様へのマッピングを最終的に容易にする一貫した基準点が得られるようにこの正準に照らしてマップされる。メタデータ正準性は、複数の言語及び他の地域特定のデータタイプ（例えば、日付、通貨など）をサポートすべきである。

メタデータマッピング
各ソースＤＢＢメタデータ属性及びパートナーメタデータ仕様の関連の値は、メタデータ正準性に即してマップすべきである。同様に、各クライアントメタデータ仕様は、ＤＢＢメタデータ正準に即してマップすべきである。これは、クライアントにコンテンツを配信する各パートナー当たりに一度づつではなく、一度クライアントにマップしさえすればよいという効率を提供する。これはまた、経時的なデータモデル変更からマッピングを保護する抽象化の層を追加する。

メタデータ変換
各クライアントは、特定のデータ要素が供給される方法を取り囲む特定の要件を有する場合がある。これは、特定の日付タイプと同じ程度に単純であるか、又は特定の変換規則などよりも複雑なものである可能性がある。例えば、クライアントは、コンテンツを分類するために固有のジャンルを有する場合がある。この場合、ジャンル値は、ＤＢＢジャンルから変換しなければならなくなる。これらの変換規則は、管理しやすい必要があり、可能であれば技術的開発に制限されずに実施すべきである。

メタデータバージョン化
メタデータの変更は、監査すべきであり、履歴データは、維持すべきである。どのメタデータがパッケージの一部としてクライアントに送られたかを知ることが重要である。しかし、クライアントは「不良な」メタデータのためにパッケージを拒否する場合がある。同じ「不良な」メタデータが再送されないことを保証するために、何が送られたかを正確に理解することが必要である。逆に、データがその後に変更された可能性があるとしても、最初に送られたものを正確に再送することを必要とする場合がある。パッケージが無期限に維持されないので、送られたメタデータを再構成することは、初期クライアントに送られた全てのメタデータを見つける機能であるべきである。一部のクライアントには、クライアントプロフィールに基づいて、最新のメタデータを送ることが必要である場合がある。

３．ユーザインタフェース
メタデータ正準性に即してＤＢＢ内のパートナー特定のメタデータ要素のマッピングを管理するユーザインタフェースが存在すべきである。同様に、正準性に即してクライアント特定のパッケージメタデータ要素をマップする方法が存在すべきである。更に、ＤＢＢ内だけに存在するメタデータを追加又は編集することを可能にするユーザインタフェースがなければならない。

４．インタフェース接続のシステム
ＤＢＢは、パッケージメタデータに含まれるデータのタイプのために固有のデータストアを維持する。それにも関わらず、ＤＢＢは、パッケージメタデータ（例えば、ＧＰＭＳ）を供給するために付加的なシステムとインタフェースで接続する必要がある場合がある。

５．マルチテナント要件
将来的なパートナーは、メタデータ正準性、メタデータマッピング、及びメタデータ変換に影響を与える特定のパッケージメタデータ要件を有する場合がある。

付録１２．パッケージ作成／管理
１．概要
本明細書は、パッケージを作成及び維持するのに必要とされる処理及び機能性を説明する。パッケージは、パートナーとクライアント間の契約に従って必要とされるいずれかの追加マテリアルと共にクライアント仕様に即して作成された１つ又はそれよりも多くの製品の編集物を表している。

２．説明
図２２は、パッケージがどのようにクライアントプロフィール及び仕様と関連することが予想されるかを示すサンプルエンティティ関係図である。青色のエンティティは、他の白書において定められ、一方、緑がかった青色のエンティティは、本明細書において導入されることになる。この図の目的は、最終設計を定めることを意図するのではなく、ＳＰＥステータス処理マップを満たすために予想される関係のタイプを説明しやすくすることが意図されている。

クライアントプロフィール−１組のクライアント特定の配送品要件を定めて、配送、ステータス追跡、課金、及び製品／パッケージ作成に向けてワークフローの自動化をサポートする。これは、構成、仕様（表題タイプ当たり）、及びプロフィールレベルのメタデータを含む。

パッケージ−１つ又はそれよりも多くの製品、及び要求充足の一部として最終的に配送されるパートナーとクライアント間の契約に従って必要とされるいずれかの付加的なマテリアル又はコンテンツの編集物を定める。

パッケージ仕様−コンテンツ又は完全であると考えられるようにパッケージに必要とされるパッケージ要素を定める。パッケージ仕様は、２つの主要な基準、すなわち、配送される製品のタイプ及び製品の配送先であるクライアントに基づいて変化する。例えば、特集のためのパッケージ仕様は、テレビジョンエピソードのためのものと異なる場合がある。同様に、ｉＴｕｎｅのための特集パッケージ仕様は、ブロードキャストクライアントのためのものと異なる場合がある。

パッケージ要素−クライアントパッケージの一部であるのに必要とされるコンテンツの個別の部分を定める。各パッケージ要素は、コンテンツのタイプ又は要素タイプに基づいて固有の仕様を有する。例えば、メタデータパッケージ要素であればメタデータ仕様を有し、Ｐａｃｋｓｈｏｔであれば画像仕様を有するであろう。

要素タイプ−要素のタイプ、すなわち、予告編、チャプター静止画、Ｐａｃｋｓｈｏｔ、メタデータ、音楽ビデオなどを定める。

パッケージ作成処理は、以下のように３つのサブ処理、すなわち、コンテンツ収集、パッケージアセンブリ、及びパッケージ維持に論理的に分割することができる。コンテンツ収集は、要求内の所要のパッケージ要素の全てを識別し、及び／又はローカライズすることを担う活動を表している。パッケージアセンブリは、全ての所要のパッケージ要素が収集されたことを確認して、クライアント仕様にパッケージ要素を適合するのに必要とされるいずれかの処理（すなわち、トランスコーディング、ウォーターマーク付け、ＸＭＬ変換、ＤＲＭなど）を行い、パッケージ仕様に従ってパッケージ要素をまとめるものである。パッケージ維持は、作成後にパッケージを制御する処理を表している。

コンテンツ収集は、要求内の製品に対して所要のパッケージ要素の全てを識別し、及び／又はローカライズすることを担う活動を表している。パッケージ仕様は、収集する必要があるものに関してコンテンツ収集を知らせる機構として仮定される。パッケージ仕様は、以下の情報を含む必要がある。
ａ．どのパッケージ要素を含める必要があるのか、すなわち、予告編、画像、メタデータなど。
ｂ．各パッケージ要素のうちのいくつが必要であるのか、予告編２つ、画像４つ、メタデータ１つ。
ｃ．どこでパッケージ要素の各々を見つけることができるか、かつそれを見つけるためにどの基準を用いるのか（ファイルシステム位置、ＤＡＭ検索基準、ウェブサービス呼び出しなど）。
ｄ．各パッケージ要素のクライアント命名規則。
ｅ．パッケージ要素の運用上の方式（すなわち、ルースファイル、製品別にＺＩＰタイプの圧縮、特定のディレクトリ構造など）。

コンテンツ収集は、パッケージ要素が特定の要求に利用可能か否かを判断することによって始まる。ＤＢＢは、要求ＵＩ内から各パッケージ要素のステータスを表面化させるべきであり、それによって適切なユーザは、要求を満足させるために何をまだ収集する必要があるかを見ることができる。

パッケージ要素を収集するためにＤＢＢは実際にどこを見るかは、設計上の意思決定になる。１つのオプションは、要求に必要とされる全てのコンテンツが示される要求に基づくＷＩＰ区域とすることができる。別のオプションは、ＤＡＭに全ての所要のコンテンツを記憶することである。これによって標準的なメタデータ正準性は、要求と、要求表題、要求テリトリー、及びパッケージテンプレートコンテンツタイプ（すなわち、表題＝慰めの報酬、テリトリー＝ＵＳ、及びコンテンツタイプ＝Ｐａｃｋｓｈｏｔ）のようなパッケージテンプレート属性の組合せに基づいてコンテンツを位置付けることを可能にすることが必要である。処理は、最小数のコンテンツ移動でできるだけ自動化すべきである。従って、ＤＡＭソリューションは、コンテンツが取り込まれた状態で複数の要求のために再利用することができるという点において固有の利点を有し、一方、手動でポピュレートしたＷＩＰの区域は、処理される各要求に対して再びポピュレートする必要がある。

先に明記したように、ファイル命名規則は、クライアント配送要件を満たすためにＤＢＢ内で特定の場合に自動的に生成する必要もある。これらのファイル命名規則は、配信クライアントで変化し、かつ一般的にアセットを説明する一連の短縮かつ連結されたメタデータ値で構成される。命名規則は、特定のクライアントに特定のものであるが、パートナーの必要性に即して構成可能でもあるべきである。ファイル命名規則を定めるために、ＤＢＢユーザは、一連のメタデータフィールド（例えば、表題、縦横比）、固定ストリング（例えば、「＿」「−」）、又は他の定義済み変数（例えば、現在の日付、現在の時間）を選択することができるべきである。メタデータ入力から生じるテキストは、ＤＢＢユーザにより指定されたいくつかの異なる基準に基づいて修正することができる。これらの基準の各々は、個々に使用するか又は連続して組み合わせることができる（例えば、母音を除去して１０文字の最大長に切り詰める）。

以下の基準は、特定のメタデータ入力又は表現全体に適用することができる。
ａ．長さに切り詰める−（例えば、表題フィールド１０文字に切り詰める。「Ｔｒａｎｓｆｏｒｍｅｒｓ」であれば「Ｔｒａｎｓｆｏｒｍｅ」になる）
ｂ．母音を除去する−（例えば、表題フィールドから母音を除去する。「Ｔｒａｎｓｆｏｒｍｅｒｓ」は、「Ｔｒｓｆｒｍｒｓ」になる）
ｃ．大文字／小文字−（例えば、表題フィールド大文字。「Ｔｒａｎｓｆｏｒｍｅｒｓ」は、「ＴＲＡＮＳＦＯＲＭＥＲＳ」になる）
ｄ．特殊文字を除去する−（例えば、表題からコロンを除去する。「Ｓｔａｒｇａｔｅ：Ｉｎｆｉｎｉｔｙ」であれば「Ｓｔａｒｇａｔｅ Ｉｎｆｉｎｉｔｙ」になる）

このデータ操作に必要とされる柔軟性を考慮すると、複雑な操作は、正規表現（例えば、ＲｅｇＥｘ）プロセッサを使用して最も良好に処理することができる。

コンテンツ収集は、全ての所要のパッケージ要素が識別され、及び／又は示された時に完了である。しかし、パッケージを作成することを可能にし、従って、特定のパッケージ要素が利用可能でない時でさえも、要求をもたらすことを可能にするために何らかのレベルの運用上の制御が維持すべきである。これは、たとえコンテンツ収集処理が完了しなかったとしても、許可されたオペレータにはパッケージアセンブリ処理を開始する機能が必要であることを意味する。これらの要件の一部は、どのパッケージ要素が配送に向けて真に必要とされるかを示すビジネス規則によって充足することができる。最高水準で、オペレータは、パッケージ仕様がどのような指示であるかに関係なく、「現状のままで」送ることができなければならない。

パッケージアセンブリは、パッケージ要素が収集された状態で始めることができる。その目的は、仕様に説明されるようにパッケージコンテンツを準備してまとめることである。各パッケージ要素は、固有の仕様を有することになる。例えば、予告編は、特定のフォーマット、縦横比、及びビットレートで配送する必要がある場合があり、メタデータは、クライアント特定のフォーマットに変換する必要がある場合がある。ＤＢＢは、どの変換を適用する必要があるかを知るために適切な仕様を利用することが予想される。パッケージをアセンブルする際には、ＤＢＢは、パッケージ仕様及びパッケージ要素仕様に基づいて以下の何らかの組合せを行うことになる。
ａ．暗号化が必要であるか否か、かつどのレベル（パッケージ又はパッケージ要素）かを判断し、必要に応じて適用する。
ｂ．画像、サポートビデオ要素（すなわち、予告編、音楽ビデオなど）、及びメタデータを変換する。
ｃ．必要であれば法医学ウォーターマーク付けを適用する。
ｄ．必要であれば製品にＤＲＭを適用する。
ｅ．必要であればパッケージ要素にクライアント特定の命名規則を適用する。
ｆ．パッケージ要素をディレクトリ構造にまとめる。
ｇ．パッケージ要素（すなわち、Ｚｉｐ、ｓｔｕｆｆｉｔ、ＭＸＦ）を結合又はラッピングする。パッケージアセンブリは、全ての所要のパッケージ要素が適切な仕様に即して処理された時に完了である。しかし、パッケージを作成することを可能にし、従って、特定のパッケージ要素が収集及び／又はアセンブルされなかった時でさえも、要求をもたらすことを可能にするために何らかのレベルの運用上の制御を維持すべきである。

パッケージ維持は、パッケージアセンブリ後を管理するのに必要とされる以下の処理から構成される。
ａ．ＱＣのためのパッケージステージング−ＱＣ位置にパッケージを移動させて、パッケージがＱＣの待機ステータスであることを適切な当事者に通知することを伴っている。
ｂ．配送のためのパッケージステージング−アセンブル済み及び必要な時には品質検査済みのパッケージを配送ステージング位置に移動させる。
ｃ．パッケージ保持−パッケージに対してパージ／保持ポリシーを実施する。これらのポリシーは、クライアント又はパートナー特定のものである場合がある。
ｄ．パッケージ管理−管理者が手動でパッケージにアクセス又はパージすることを可能にする。

３．ユーザインタフェース
ユーザインタフェースは、パッケージ仕様をアセンブルすることを通じて要素タイプ作成からパッケージ仕様の全ての面を管理するために存在すべきである。パッケージ仕様の作成、検閲、及び公開は、全体的な搭載処理の一部であるように仮定されている。

更に、要求及び／又は管理者／パートナーポータルは、特定の要求内の各パッケージ要素のステータスを表面化させるべきであり、それによって許可されたユーザは、要求充足が進むことを可能にするために何をまだ収集する必要があるかを見ることができる。

最後に、パッケージ作成では、パッケージ要素を供給してパッケージＱＣを行うことを担う当事者に通知を潜在的に送る可能性がある。

４．インタフェース接続のシステム
ＤＢＢは、パッケージに必要とされたパッケージ要素を収容するＤＡＭ又はファイルシステムとインタフェースすべきである。

５．マルチテナント
ＤＢＢは、必要なパッケージ要素を収集するためにパートナーＤＡＭシステムとインタフェース接続すべきである。しかし、別のオプションは、ＤＢＢへのパッケージ要素の直接の取り込みを可能にするパートナーポータルを設けることである。

付録１３．財務処理
１．概要
ＤＢＢには、コスト推定が得られるか、財務承認を容易にするか、又は課金又はコスト転送処理を実行し、かつ必要な場合に財務トランザクションの調節を容易にするためにソニー及びパートナーの財務システムとの対話が必要がある。

財務処理のＤＢＢモデルは、ＳＰＥ、会社間のモデル、並びにパートナーモデル、より従来形の顧客／販売業者モデルとのビジネス関係をサポートすべきである。付録３．要求管理に説明したセルフサービス概念は、説明するような会社間モデルと第三者モデルの両方に適用されるように考えられている。しかし、パートナーが従来のＰＯを供給することができるＤＢＢ顧客サービス層に関する要件を含むことも必要であると考えられる。この顧客サービス層は、次に、セルフサービスモデルに説明するように要求モジュールを通じてＤＢＢと対話する。

全てのＤＢＢ財務モデルは、これらのシステムのコア機能性を利用し、かつできる限りＤＢＢ本体から中核になる財務要件を排除するために、ＳＰＥ又はパートナー財務システムとのインタフェースを可能にする。ＧＡＡＰ又はＳＯＸ準拠の財務システムの要件からのコンテンツ管理及び配信プラットフォームとしてのＤＢＢの分離が望ましい。

ＧＯＬＤ、「Ｘｙｔｅｃｈ ＭｅｄｉａＰｕｌｓｅ」、及びＤＡＤＣのＣＯＭシステムに関わっている特定のアーキテクチャオプションを以下のシステムアーキテクチャオプションにおいて概説する。これには、インタフェースの描写及びＤＢＢの実施態様が含まれる。

２．説明
財務統合概念
以下の節では、ＤＢＢ財務目の流れ機能別コンポーネントを示している。これらのコンポーネントの一部が利用可能な複数のオプションがある。これらのオプションは、この節の最後に説明する。

料金表−付録６．製造計画に説明し、付録５．ワークフローマスターデータ及び付録７．タスク管理においては詳細したように、ＤＢＢは、アーキテクチャ内で料金表をサポートする機能を有するか、又は料金表をサポートするシステムとインタフェース接続するようにも意図している。この料金表は、コンテンツ処理商務に共通である様々な価格設定シナリオを考慮すべきである。これらのシナリオには、以下が含まれるべきであるが、これに限定されない。

ａ．パートナーによる料金表−料金表は、パートナーがＳＰＥであれ第三者であれ、そのパートナーによる固有の価格設定を行うように構成可能でなければならない。料金表は、パートナー価格設定のコピー及び修正、及び全体百分率又は個別価格変更による料率変更の適用をサポートすべきである。多くのサービス価格のグループ分け及び修正が必要である。

ｂ．プロジェクト価格設定−この価格設定は、特定の取引が交渉される時にパートナーの料金表に上書きされる。

ｃ．価格設定タイプ−以下の価格設定タイプをサポートすべきである。
数量価格設定−多量化に対する割引の適用を含む。
均一料金価格設定−数量又は単位が価格の計算において考慮されないサービスを含む。
最小数量価格設定−最小数量が到達されるまで均一料金が課金され、次に、数量又は標準単位価格設定が用いられる。

ｄ．価格設定変数−以下の変数は、料金表マッピングに使用されるべきである。
数量−作成された項目の数、例えば、５つのＭｐｅｇ２ファイル。
ユニット−数量が掛けられる場合もあれば、掛けられない場合もあるユニット数、例えば、５つのＭｐｅｇ２ファイルの１０回の配送。あらゆる汎用ユニットに基づくサービスにも使用される。
実行時間−コンテンツの実行時間。
ソース及び出力タイプ−ソースファイルタイプ、例えば、ＨＤ対ＳＤソース、出力トランスコードフォーマット。
注文タイプ−必要とされるサービスレベル及び注文のためのトランザクションタイプ、例えば、大急ぎの注目、課金不可能。
サービスタイプ−要求に向けて実行されるサービスのタイプ、例えば、トランスコード、３：２のプルダウン等々。
ビットレート−コンテンツのビットレート。
ファイルサイズ−処理されたコンテンツのファイルサイズ。

課金トランザクション−ＤＢＢタスクと料金表間のマッピングを通じて、課金トランザクションは、ＤＢＢによって生成される。これらのトランザクションは、自動的に製造計画により、又は付録６．製造計画及び付録５．ワークフローマスターデータにおいて上述したように製造計画の修正を通じて生成することができる。しかし、課金トランザクションは、製造計画のコスト推定コンポーネントを含み、かつ代金請求又はコスト転送処理をサポートする。

製造計画ＰＯインタフェース−ソニーモデル内では、ＢＢにおいて要求者により承認されると、製造計画は、所要の財務データによりサポートされる課金トランザクションを生成する。次に、ＷＰＦ充足システムＧＯＬＤにこの情報をエクスポートする。従って、このインタフェースにより、ＧＯＬＤ内にメディア発注書が作成される。ＳＰＥ表題／アルファＩＤのようなサポート情報が必要とされ、他の財務情報は、要求モジュール設計（例えば、テリトリー、市場）に含めることができ、また、インタフェース内にも示される。パートナー要件をサポートするために、このインタフェースは、構成されて複数のパートナーに再配備することができる標準化されたスキーマ及びウェブサービス機能性をサポートする。製造指示及びソースアセットは、情報を目的としてのみインタフェース内に含めることができる。ＤＢＢにより作成されるＧＯＬＤのＰＯ（又はパートナーＰＯ）は、課金手段として意図されるが、作業を行うための指示として意図されるのではない。配信処理の詳細を報告することは、ＤＢＢ要件であり、パートナーＰＯシステムの要件ではない。基準詳細は、両システムにおいて必要とされる。

製造計画が作成されてインタフェースメッセージが送られた状態で、計画は、インタフェースを通じて承認されるまで保留のままになる。製造計画コストのＣＯＦＡ承認は、ＧＯＬＤ（又はパートナーＰＯシステム）において実行されることになる。承認された状態で、メッセージは、製造計画を公開するＤＢＢに送り戻されることになる。

Ｒ１要件には、ＧＯＬＤとのインタフェース及び第三者ＰＯシステムへの拡張性が含まれる。第三者ＰＯインタフェースの設計及び構成は、Ｒ１に対しては適用範囲ではない。

製造実行及びコスト転送インタフェース−ＣＯＦＡ承認がインタフェースを通じて受信された状態で、製造計画が実行されることになる。実行中に発生する場合がある製造計画の実質的変更は、インタフェース接続のＰＯのそれに続く反復をもたらす場合がある。課金処理をサポートするために、改訂が送られ、かつ承認を受けることができる。作業が完了した時に、ＤＢＢは、コスト転送機能を実行するＧＯＬＤにメッセージを送ることになる。この機能は、インボイス記録が作成、承認、かつＳＡＰへのエクスポートに向けてポスティングされるＧＯＬＤシステムにおける現在の手動処理を映し出すことになる。トランザクションの会社間の性質及びＤＢＢ課金トランザクションがＧＯＬＤのＰＯトランザクションに等しいというインタフェースによる保証により、この処理は、完全に自動化することができる。この処理の自動化は、Ｒ１の適用範囲であるが、ＳＡＰとの既存のＧＯＬＤインタフェースが利用され、ＳＡＰとの新設インタフェースは不要であるように仮定されている。

ＤＡＤＣ売掛金−パートナーモデルに向けて選択されたオプションに関係なく、ＤＢＢ内の課金トランザクションは、売掛金及び総勘定元帳の目的のためにＤＡＤＣ財務システムＣＯＭとインタフェースで接続されるように仮定されている。ＳＰＥモデルにおいて、これらのＡ／Ｒトランザクションは、ＳＰＥとＤＡＤＣの間のコスト転送の調節をサポートするのに使用される。パートナーモデルにおいて、ＣＯＭは、標準的な代金請求及び売掛金機能をもたらす。

財務モデル変数
ＳＰＥモデルとパートナーモデルの間に存在する場合がある変数は、以下を含むがこれらに限定されない。

製造計画ＰＯインタフェーシング−パートナーへの製造推定のインタフェースは、このモデルの要件ではなく、オプションである。先に簡単に説明したように、パートナーは、要求モジュールを直接に使用する場合もあれば使用しない場合もある。使用しない場合、パートナーのためにＤＢＢ要求モジュールと直接に対話するＤＡＤＣ顧客サービス代表と取り引きする。この場合、従来のパートナーＰＯの必要性は、作業実施前に必要とされる場合がある。これは、より従来的な顧客／販売業者対話であることになる。この処理は、Ｒ１要件に直接に影響を与えるものではないが、使用事例は考慮すべきである。

課金／コスト転送−パートナーに対して、上述のＳＰＥモデルに説明したような製造実行及びコスト転送インタフェースは、Ｒ１に対して適用範囲ではない集中統合プロジェクトなしでは可能でないことになる。従来のインボイス処理は、ＣＯＭシステムからＤＡＤＣにより行われるように仮定されている。料金表、課金トランザクション、及びＣＯＭのＡ／Ｒ間の全て内部対話は、説明した通りのままとすることができる。

システムアーキテクチャオプション
料金表及び課金トランザクション−現在のオプションは、ＤＡＤＣインフラストラクチャー内で独立であると考えられる「Ｘｙｔｅｃｈ ＭｅｄｉａＰｕｌｓｅ」実施の統合を含む。このオプションにおいて、Ｘｙｔｅｃｈ製品内の豊かな料金表及び課金機能は、財務トランザクションを処理し、かつ上述のようにＳＰＥ側のＧＯＬＤ及びＤＡＤＣ側のＣＯＭとインタフェースで接続するのに利用される。

第２のオプションは、料金表及び課金トランザクションをＣＯＭシステム内に維持することができることである。これは、ＣＯＭが、上述のように全ての価格設定関連の概念をサポートし、かつＧＯＬＤとインタフェースすることを要求する。

ＭｅｄｉａＰｕｌｓｅにおけるＣＯＭ及び課金トランザクションにおいて料金表をサポートするオプションは、実用的には思えない。純粋に財務のために使用される場合、これらのシステムは、サポートシステムと考えられ、ＤＢＢプロジェクト要件は、財務モデルをサポートするのに必要なインタフェースに基づくものになる。これらのシステムへの統合は、Ｒ１の適用範囲であると考えられる。これは、課金システムのみとしてのＭｅｄｉａＰｕｌｓｅインスタンスの実施を具体的に除外する。

第３のオプションは、「Ｘｙｔｅｃｈ ＭｅｄｉａＰｕｌｓｅ」が、要求モジュール、製造計画、タスク管理及び在庫管理のような中核になるＤＢＢコンテンツ処理機能に使用されると考えられることである。ＭｅｄｉａＰｕｌｓｅがこれらの領域におけるソリューションとして呈示された場合、料金表及び課金トランザクション機能は、ＭｅｄｉａＰｕｌｓｅアーキテクチャ内のそれらの緊密な統合によって適用範囲になると考えられる。

３．ユーザインタフェース
処理フローのどの点でも課金トランザクションを修正する機能が要求される。このインタフェースは、計画の修正に関して付録６．製造計画においても説明されている。運用職員は、製造計画の仕上げの前に又は製造計画ＰＯインタフェースのいずれかの反復の前に又はパートナーに対しては代金請求の前に課金トランザクションを精査して修正することができなければならないことが、明瞭さを期すために具体的に定められている。

４．サービス
最終設計に基づいて、具体的には「Ｘｙｔｅｃｈ ＭｅｄｉａＰｕｌｓｅ」のいずれかの使用に対して、ＤＢＢは、課金トランザクションデータのインタフェースのためのサービスを要求することになる。このサービスでは、料金表情報にアクセスし、推定されたタスクにマッピングを適用し、得られた課金トランザクションを作成する必要がある。このサービスは、必要に応じて純粋に見積もりのためにかつ配信をサポートするためだけではなく、ＤＢＢ内で実行可能でなければならない。

５．インタフェース接続のシステム
システムアーキテクチャオプションの解像度に基づいて、ＧＯＬＤシステムとのＤＢＢインタフェースは、上述のＣＯＦＡ承認及びコスト転送活動をサポートすることが必要である。ＭｅｄｉａＰｕｌｓｅが運用上ＤＢＢの一部として含まれるか否かは、ＤＡＤＣのＣＯＭシステムとのインタフェースの性質に影響を与える。このインタフェースは、料金表、課金トランザクション、ＣＯＦＡ承認及びコスト転送の全般を含むことができ、又は単に課金トランザクションがＭｅｄｉａＰｕｌｓｅからインタフェースで接続されることが必要である場合がある。

６．マルチテナント
財務フローにおける変動に関連する時のパートナーの問題は、この節を通して取り上げられている。財務データが収集又は処理される全ての領域において、所有側のパートナーが定められ、かつこのパートナー指定は、本明細書に説明する様々な処理の適用を可能にすることになる。

３００ メディアコンテンツのデジタル配信の技術を示す流れ図
３１０ 配送要件及びクライアントプロフィールを受信するボックス
３２０ ソースアセットの在庫及び解析を提供するボックス
３３０ 配信バックボーンの機能をマップするボックス

Claims (27)

1. 配信バックボーンシステムを使用してメディアコンテンツをデジタル配信する方法であって、
   クライアントプロフィールを含むメディアコンテンツに対する要求をクライアントから受信する段階と、
   前記クライアントプロフィールを通して反復的に進むことにより、ソースアセットの在庫及び解析を行って出力を作成する段階と、
   一連の規則が前記ソースアセットを前記クライアントプロフィールにマップすることを可能にする機能マッピングを行う段階と、
   前記クライアントからのメディアコンテンツの前記要求に応答してマップされた機能から作業項目及び実行段階を判断する製造工程を計画する段階と、
   を含むことを特徴とする方法。
2. 前記クライアントプロフィールは、前記メディアコンテンツに関する仕様又は前記クライアントに対するメタデータ要件の特定の組を定めることを特徴とする請求項１に記載の方法。
3. 前記特定の組の仕様は、自動化されたワークフローをサポートするのに必要な重要な変数及び要件を定めることを特徴とする請求項２に記載の方法。
4. 前記クライアントプロフィールは、前記メディアコンテンツの配送に関する前記クライアントの要件を定めることを特徴とする請求項１に記載の方法。
5. １つ又はそれよりも多くのクライアントプロフィールが、そのクライアントに関する複数のビジネスモデル及びテリトリー別に変わる要件のうちの少なくとも一方を表すように各クライアントに対して設定されることを特徴とする請求項１に記載の方法。
6. 前記製造工程において判断された前記作業項目及び実行段階の最適化を行う段階、
   を更に含むことを特徴とする請求項１に記載の方法。
7. メディアコンテンツのライセンス供与を担う作業により、ライセンシーへのそのメディアコンテンツの充足を担う作業に対して前記要求を生成する段階、
   を更に含むことを特徴とする請求項１に記載の方法。
8. 前記メディアコンテンツの識別、サービス提供される前記クライアント、及び支払期日を含むサービス提供の条件に関する重要な情報を識別する解析を行う段階、
   を更に含むことを特徴とする請求項１に記載の方法。
9. コンテンツ処理技術の自動管理を含む調達関連活動を行う段階、
   を更に含むことを特徴とする請求項１に記載の方法。
10. コンテンツ処理技術の前記自動管理は、標準化されたデータインタフェースによって制御されるファイル管理、トランスコーディング、パッケージング、及び配送を含むことを特徴とする請求項９に記載の方法。
11. 配信バックボーンシステムであって、
    クライアントプロフィールを含むメディアコンテンツに対する要求をクライアントから受信する製造解析エンジンであって、該製造解析が、該クライアントプロフィールを通して反復的に進むことにより、ソースアセットの在庫及び解析を行って解析出力を生成するように作動する製造解析エンジンと、
    前記解析出力を使用して作業項目及び実行段階を判断するように構成された製造計画エンジンと、
    を含むことを特徴とするシステム。
12. 前記製造計画エンジンは、コンポーネントアセットソースと、ワークフロー処理と、コスト及びリードタイム解析とを行うか又は使用するモジュールを含むことを特徴とする請求項１１に記載の配信バックボーンシステム。
13. 前記クライアントプロフィールは、
    メディアコンテンツに対する前記要求を充足させるために前記クライアントに配送すべきである個別の項目を定めるパッケージ仕様と、
    前記ソースアセットの選択を案内して製造機能を制限するクライアント特定の要件である製造プリファレンスと、
    コーデック、フレームレート、画像解像度、及び他のファイルベースの技術パラメータを定める非コンテンツベースの要件である技術仕様と、
    非線形編集要件を定めるアセンブリ仕様と、
    を含む、
    ことを特徴とする請求項１１に記載の配信バックボーンシステム。
14. 前記非線形編集要件は、ロゴ交換、プルのためのブラック、又は追加カードを含むことを特徴とする請求項１３に記載の配信バックボーンシステム。
15. 前記パッケージ仕様は、コンテンツ仕様及びメタデータ仕様を含むことを特徴とする請求項１３に記載の配信バックボーンシステム。
16. 前記コンテンツ仕様は、再使用可能な技術仕様、アセンブリ仕様、及びプリファレンスデータを含むことを特徴とする請求項１５に記載の配信バックボーンシステム。
17. 前記解析出力は、取り込みを管理するのに必要なタスク管理ツールであるコンポーネント要件を含むことを特徴とする請求項１１に記載の配信バックボーンシステム。
18. 前記製造解析エンジンは、クライアント配送品仕様、サポート在庫データ、及びワークフローマスターデータを受信するモジュールを含むことを特徴とする請求項１１に記載の配信バックボーンシステム。
19. 前記製造解析エンジンは、前記クライアント配送品仕様を使用して適切なワークフローを識別することを特徴とする請求項１８に記載の配信バックボーンシステム。
20. グループ分けされたコンポーネントを含み、かつ該コンポーネントが協働することができるように適合かつ同期されたキット、
    を更に含み、
    協働するように判断された前記コンポーネントは、前記ワークフローマスターデータを前記キットに向けるように編成される、
    ことを特徴とする請求項１８に記載の配信バックボーンシステム。
21. 前記キットは、１つのビデオコンポーネント及び１つ又はそれよりも多くのオーディオコンポーネントを含むことを特徴とする請求項２０に記載の配信バックボーンシステム。
22. メディアコンテンツをデジタル配信するためのコンピュータプログラムを格納するコンピュータ可読記憶媒体であって、
    コンピュータプログラムが、コンピュータをして、
    クライアントプロフィールを含むメディアコンテンツに対する要求をクライアントから受信し、
    前記クライアントプロフィールを通して反復的に進むことにより、ソースアセットの在庫及び解析を行って出力を作成し、
    一連の規則が前記ソースアセットを前記クライアントプロフィールにマップすることを可能にする機能マッピングを行い、かつ
    前記クライアントからのメディアコンテンツの前記要求に応答してマップされた機能から作業項目及び実行段階を判断する製造工程を計画させる、
    実行可能命令を含む、
    ことを特徴とするコンピュータ可読記憶媒体。
23. コンピュータをして、
    前記製造工程において判断された前記作業項目及び実行段階の最適化を行わせる、
    実行可能命令を更に含むことを特徴とする請求項２２に記載のコンピュータ可読記憶媒体。
24. コンピュータをして、
    メディアコンテンツのライセンス供与を担う作業により、ライセンシーへのそのメディアコンテンツの充足を担う作業への前記要求を生成させる、
    実行可能命令を更に含むことを特徴とする請求項２２に記載のコンピュータ可読記憶媒体。
25. コンピュータをして、
    前記メディアコンテンツの識別、サービス提供される前記クライアント、及び支払期日を含むサービス提供の条件に関する重要な情報を識別する解析を行わせる、
    実行可能命令を更に含むことを特徴とする請求項２２に記載のコンピュータ可読記憶媒体。
26. コンピュータをして、
    コンテンツ処理技術の自動管理を含む調達関連活動を行わせる、
    実行可能命令を更に含むことを特徴とする請求項２２に記載のコンピュータ可読記憶媒体。
27. コンピュータをしてコンテンツ処理技術の自動管理を行わせる実行可能命令が、コンピュータをして、
    標準化されたデータインタフェースによって制御されるファイル管理、トランスコーディング、パッケージング、及び配送を行わせる、
    実行可能命令を含むことを特徴とする請求項２２に記載のコンピュータ可読記憶媒体。

Images