CN102804221A - 发行骨干 - Google Patents

Abstract

利用发行骨干系统来数字地发行媒体内容包括：接收来自客户的对媒体内容的请求，该请求包括客户简档；通过迭代地遍历客户简档来执行源资产的盘存和分析以创建输出；执行能力映射，其中一系列规则允许源资产被映射到客户简档；以及规划制造过程，其根据响应于来自客户的对媒体内容的请求而映射的能力来确定工作项目和执行步骤。

Description

发行骨干

技术领域

本发明涉及数字媒体，更具体而言涉及媒体的数字发行。

背景技术

随着媒体的制作和发行迅速地朝着完全数字化前进，支持要求集成软件和硬件两者的各种数字格式/设备的自动化工作流和兼容将是有利的。然而，对于在媒体制作领域提供各种数字格式/设备的自动化工作流和兼容，有若干个障碍。例如，当前，没有集成的工作流，缺乏标准，软件和硬件方案各不相同，并且总体上没有更换工作流的手动性质的动力。

发明内容

本发明的实施例支持利用发行骨干(distribution backbone)系统来数字地发行媒体内容。

在一种实现方式中，公开了一种利用发行骨干系统来数字地发行媒体内容的方法。该方法包括：接收来自客户的对媒体内容的请求，该请求包括客户简档(客户简档)；通过迭代地遍历客户简档执行源资产的盘存和分析来创建输出；执行能力映射，其中一系列规则允许源资产被映射到客户简档；以及规划制造过程，其根据响应于来自客户的对媒体内容的请求而映射的能力来确定工作项目和执行步骤。

在另一实现方式中，公开了一种发行骨干系统。该系统包括：制造分析引擎，其接收来自客户的对媒体内容的请求，该请求包括客户简档，其中该制造分析进行操作以通过迭代地遍历客户简档执行源资产的盘存和分析来生成分析输出；以及制造规划引擎，其被配置为利用分析输出来确定工作项目和执行步骤。

在另一实现方式中，公开了一种存储用于数字地发行媒体内容的计算机程序的计算机可读存储介质。该计算机程序包括使得计算机执行以下操作的可执行指令：接收来自客户的对媒体内容的请求，该请求包括客户简档；通过迭代地遍历客户简档来执行源资产的盘存和分析以创建输出；执行能力映射，其中一系列规则允许源资产被映射到客户简档；以及规划制造过程，其根据响应于来自客户的对媒体内容的请求而映射的能力来确定工作项目和执行步骤。

在阅读以下详细描述和附图后本领域的普通技术人员将更容易清楚本发明的其他特征和优点。

附图说明

图1是示出根据本发明的一种实现方式的用于利用发行骨干系统的媒体内容的数字发行的过程的流程图。

图2是根据本发明的一种实现方式的发行骨干系统的框图。

图3是示出根据本发明的一种实现方式的用于利用发行骨干系统的媒体内容的数字发行的技术的流程图。

图4示出了对于制造规划起作用的交付要求和客户简档的详细布局。

图5示出了客户简档的示例性使用案例。

图6示出了表达客户可接受的某一范围的可交付物的源偏好和技术规格的多个集合。

图7示出了库存的状态的一个示例。

图8示出了当找到源资产时从源资产中提取数据的示例性使用案例。

图9示出了从在素材分析查询中识别的资产收集数据。

图10示出了能力映射的特定使用案例。

图11示出了制造规划的特定使用案例。

图12A示出了计算机系统和用户的表示。

图12B示出了容宿发行骨干过程的计算机系统的功能框图。

图13是示出预期合作者和客户如何与客户简档、规格和配置相关的样本实体关系图。

图14显示了对请求维护模块的主要输入。

图15显示了存在于具有两个Alpha(导演剪辑版和剧场发布版)的标题与将被识别来为导演剪辑版Alpha服务的组件的家族之间的样本层次体系。

图16示出了如果资产对于此组件类型将被考虑则该资产将被限制到的宽高比值的列表。

图17描述了具有DBB的工作流主控数据的作用。阴影方框是由请求者定义的选择。

图18示出了按功能分组描述的工作流任务及其构成的处理。

图19示出了包括在存储层级之间移动文件的能力的受管理多层级存储环境(MMSE)的使用。

图20概略示出DBB应当协调的编码和摄取管理过程。

图21是示出客户简档、其相关联的元数据规格和根据该规格组装包裹元数据所要求的支持数据之间的关系的样本实体关系图。

图22是示出预期包裹如何与客户简档和规格相关的样本实体关系图。

具体实施方式

这里公开的实现方式描述了用于数字内容发行的系统、方法和装置，其提供了数字地摄取内容并且通过交付到客户来无缝地管理内容的自动化工作流。在阅读这里的描述后，将清楚如何在各种替换实现方式和替换应用中实现本发明。然而，虽然这里将描述本发明的各种实现方式，但要理解这些实现方式仅是作为示例而不是限制给出的。因此，这里对各种替换实现方式的详细描述不应被解释为限制本发明的范围或广度。

图1是示出根据本发明的一种实现方式的用于利用发行骨干系统的媒体内容的数字发行的过程的流程图100。媒体内容的示例包括电影、歌曲、软件和游戏。

在图1所示的实现方式中，在方框110，生成和提交对于内容的许可和对于将该内容履行给被许可者的请求。这些请求可基于提交的组织和许可协议的类型的变化而采取许多形式。履行操作执行必要的分析以识别关于内容的标识(称为标题/Alpha)、要服务的客户以及诸如到期日之类的服务条款的关键信息。

履行过程中的下一步骤是在方框120对库存要求的分析。为了生成将会致使创建被许可者需要的可交付物的制造计划，对于每个标题/Alpha执行对库存的分析。此分析开始于对被许可者所要求的最终可交付物(即产品)的定义，并且处理经过用于生成该产品的组件的每个级别，从复制母版到离散的视频、音频和文本组件到通过制作创建的原始母版。对于每个客户要求，采取各种形式的此过程由服务操作或供应者进行。

对于每个标题/Alpha，一旦知道了库存的状态，就在方框130定义和生成制造计划。此计划可涉及少量的步骤，例如针对复制和装运要求，或者可要求更复杂的制造，这种更复杂的制造可涉及在复制和装运之前的诸如下变频、音频重放和字幕应用之类的过程。制造计划是基于现有的库存组件和关于制造工作流的知识来确定的。在下文中详细描述库存分析和制造规划。

一旦制造计划得到批准，其就在方框140被发布以供执行。此过程涉及采购相关活动或内部制造，包括内容处理技术的自动化管理，例如文件管理、代码转换、打包和交付，这些由标准化数据接口控制。

打包和交付过程(在方框150执行)支持履行过程的持续自动化。产品按照严格标准与支持媒体和元数据一起被交付，使得它们可以被客户的内容管理系统所消耗。这些标准的变化要求信息和支持媒体的管理中的灵活性。

图2是根据本发明的一种实现方式的发行骨干系统200的框图。在图2所示的实现方式中，该框图示出了执行素材分析和生成制造计划所需要的实体和过程。从而，发行骨干系统200包括客户可交付物规格230(包括客户简档210)、制造分析引擎240、制造规划引擎250、支持库存数据260以及工作流主控数据270。制造规划引擎250执行或使用组件资产资源252、工作流过程252以及成本和交货时间分析256。

在一种实现方式中，自动化工作流由跨若干个库存和内容处理工作流维护的主控数据270(参见附录5，有对其的详细描述)支持。制造规划引擎250利用此主控数据270来响应于来自客户的请求而生成特定的制造计划。这些制造计划表示用于管理内容处理和生成成本和交货时间估计所要求的信息点的核心指令集。

制造分析引擎240利用工作流主控数据270和支持库存数据260(参见附录4，有对其的详细描述)以及来自请求模块(参见附录2，有对其的详细描述)的输入，该请求模块处理合作者-客户关系以及如何生成请求。利用客户可交付物规格230，制造分析引擎240识别适当的工作流。在该工作流内，定义了创建客户规格所需要的所有任务。另外，在适用的情况下，定义每个任务的所有需要的组件类型。利用此信息，引擎240首先执行素材分析。发行骨干系统200针对指定的标题/Alpha 220和客户可交付物规格230，就所需要的组件查询库存。此分析的结果确定了完成所要求的工作流所必需的任务。

如附录5中所述，基于客户规格的工作流应当考虑到库存情景。这些工作流应当覆盖所需要的库存组件的编码和摄取直到交付。它们应当是模块性的，并且提供灵活性来应对所需要的库存处于更高的准备阶段的情景。制造分析引擎240执行素材分析以便确定创建所需要的产品所必需的特定工作流。

发行骨干工作流可包括较高分辨率文件到较低分辨率文件的代码转换，该较低分辨率文件随后被打包和交付。另外，发行骨干操作可创建较低分辨率文件并将其存储在文件存储系统中作为限制使用替换分辨率母版。在此情况下，将要求工作流询问库存，确定较低分辨率文件存在，并且选择替换工作流来拷贝和交付较低分辨率文件，而不是从较高分辨率文件进行代码转换。

取决于详细设计，因为资产库存的动态性，在执行实际工作流之前，出于成本和交货时间目的，可能必须重新运行制造计划。

图3是示出根据本发明的一种实现方式的用于利用发行骨干系统的媒体内容的数字发行的技术的流程图300。在图3所示的实现方式中，数字发行技术包括：在方框310，收集交付要求和客户简档；在方框320，通过迭代地遍历要求集合来执行源资产的盘存和分析以创建输出(关于素材分析的特定使用案例，参见对图6和图7的描述)；在方框330，执行能力映射(关于能力映射的特定使用案例，参见对图8至图10的描述)；在方框340，规划制造过程(关于对制造规划的详细描述，参见对图11的描述)；以及在方框350，提供优化(详情见下)。

交付要求和客户简档定义了客户的内容、交付和元数据要求的特定要求/规格集合。客户简档被用于定义每个客户对于内容交付的要求。对于每个客户可设立一个或多个客户简档来表示该客户的多个业务模型，以表示按地域变化的要求，或者出于其他业务/技术原因。规格定义了支持自动化和手动工作流所需要的关键变量和要求。由于维护了规格主控，所以单个规格可与多个客户相关联。能力映射包括允许源资产被映射到客户规格的一系列规则。制造规划确定工作项目、执行步骤和优化。在另一实现方式中，发行骨干系统识别所需要的源资产并且创建将基于客户规格来交付内容的制造计划。

图4示出了对于制造规划起作用的交付要求和客户简档的详细布局。如上所述，客户简档是定义客户的内容、交付和元数据要求的特定要求集合。在一种实现方式中，客户简档包括包裹规格410、偏好420、技术规格430以及组装规格440。包裹规格410定义了必须被交付到客户以履行客户所作出的请求的离散项目，并且包括内容规格412和元数据规格414。偏好420是引导源资产的选择并且限制或放松发行骨干制造能力的客户特定要求。技术规格430是定义编解码器、帧率、图片分辨率和其他基于文件的技术参数的非基于内容的要求。组装规格440定义了任何非线性编辑要求，例如徽标替换、拉出/修改黑屏或添加卡片。内容规格412包括可重用的技术规格、组装规格和偏好数据。

在图5至图8所示的客户简档的一个示例性使用案例中，用户已针对标题“飞机”和Alpha“剧场版”识别了客户CinemaSpace和国内销售(Domestic Sell Through，DST)的客户简档。在图5中，技术规格被示为例示了客户对于具有16×9的宽高比和23.98的帧率的内容的需求。然而，额外的技术规格也表明了基于对于该标题/Alpha的可用库存而接受不同格式的能力。组装规格直接向制造计划提供数据，以与来自技术规格的数据一起用于创建代码转换简档。

图6中所示的内容规格示出了表达客户可接受的某一范围的可交付物的源偏好和技术规格的多个集合。它们也被排名以便表达客户的偏好。源偏好被用于找出可使用的源资产。图中所示的示例性数据允许同一内容规格应对本来是4×3或16×9的标题。标题“飞机”已被选择作为可只具有4×3视频母版的较旧分类的标题。

制造偏好允许了装载操作者基于客户偏好开启或关闭发行骨干能力。从而，在图6所示的示例中，制造偏好指示没有从23.98的胶片帧率到29.97的视频帧率的3:2去除或下拉。

图7示出了标题“飞机”702和Alpha“剧场版”704的库存700的状态的一个示例。方框710、712表示对于该标题/Alpha存在的源资产。方框720、722存在是为了例示所有源资产都被匹配到母版规格。当执行素材分析时，可以找到源资产或组件规格。找到组件规格将导致组件要求，包括标题、Alpha和组件规格信息。组件要求是管理摄取所需要的任务管理工具。套件730是一组组件(例如音频组件和视频组件)，该组组件是相容和同步的，以使得组件能够一起工作。被确定为一起工作的组件将被组织以允许工作流主控数据指向套件类型。在Alpha下，该套件将允许对将会一起工作的资产的具体确认。套件一般将具有一个视频组件和一个或多个音频组件，其中任何音频将与该套件内的视频一起工作。客户规格所支持的工作流主控数据将应对关于使用来自套件内的哪个音频或支持素材的可变性。

参考图6并同时考虑图7，执行素材分析以生成受技术规格约束的期望输出。如上所述，素材分析是一个迭代的过程，其遍历源偏好和技术规格，直到找到基于系统能力能够被用于生成期望输出的资产为止。如图6中所示，源偏好是表示客户的非技术或内容偏好的标准的集合。

返回参考图6和图7，对示例性使用案例执行素材分析。最初，排名第1的源偏好被用于查询库存700。在图7中所示的示例性库存700中，系统搜索16×9视频源和立体声英语音频源。该查询还要求这些资产是成套的。然而，此查询失败，因为没有16×9视频资产。因此，接下来使用排名第2的源偏好来查询库存700。在此情况下，系统搜索4×3视频源和立体声英语音频源。该查询也要求这些资产是成套的。这一次，查询成功了。

利用如上所述执行的素材分析，接下来执行能力映射。能力映射是允许源资产标准被映射到技术规格标准的一系列规则。参考图8，当找到源资产时，从这些资产中提取数据。也从技术规格中提取数据。此有效载荷被馈送到规则引擎800。结果是对所有需要的变换都能够被容适的确认以及对所需要的变换的识别。在该分析中包括了制造偏好，制造偏好可基于客户偏好而认定一系统能力不合适。

在图8中所示的示例性能力映射中，从在素材分析查询中识别的资产收集数据，其中在该素材分析查询中，4×3视频源和立体声英语音频原被识别且成套。还从排名第1的技术规格810中收集数据并将该数据馈送到能力映射规则引擎800。此迭代失败，因为我们没有将4×3图片母版变换到16×9的能力。注意，通过创建总体不允许某些组合的从属规则840，可以简化约束文件格式改变的规则。这减轻了表达所有可能的标准映射组合的需要。

现在参考图9，连同来自排名第2的技术规格820的数据，从在素材分析查询中识别的资产收集数据，并将其馈送到能力映射规则引擎800中。此迭代仍失败，这是由于两个原因：(1)将4×3图片母版变换到16×9的能力像之前那样不存在；以及(2)客户偏好接收未通过基于软件的3:2去除或下拉处理的内容900，而这不然就是发行骨干系统的能力。

现在参考图10，连同来自排名第3的技术规格830的数据，从在素材分析查询中识别的资产收集数据，并将其馈送到能力映射规则引擎800中。此迭代成功，只需要从母版文件编解码器到技术规格编解码器的变换1000。

图11示出了利用系统规则和/或逻辑得出一组制造功能的示例性源要求1100、套件1110和技术规格1120的关联。每个制造功能是随后映射到可能的工作项目模板的列表的制造功能类型的实例。一制造功能可以产生不止一个可能的工作项目模板。图11的示例示出了用于提供媒体代码转换方案的两个工作项目模板，服务1和服务2。基于系统定义的规则，选择单个适当的工作项目，即服务1。该工作项目包括关于“From”参数(例如16×9)、“To”参数(4×3)和要使用的系统(例如服务1)的信息。每个工作项目模板与执行步骤模板内的一组相应的执行步骤相关联。在图11的示例中，包括以下步骤：构造工作区域；本地化组装素材；以及带简档的服务1(MPEG 4)。因此，基于工作项目模板到执行步骤模板的映射，得出期望的执行步骤。

一旦识别了执行步骤，就可以通过各种方式来优化制造计划。例如，在制造计划中具有复杂的多步骤变换的案例可致使识别多个工作项目模板(冗余优化)。这些模板可具有冗余的执行步骤，例如“本地化组装素材”。在冗余优化中，可以实质性地减少或消除这些冗余步骤。另外，在复杂的案例中，一些执行步骤可被并行运行或在单个操作中运行，例如“格式变换”和“16×9到4×3变换”。这些步骤在组合性优化期间可被组合到单个操作。在优化之后，制造计划完成。在执行时，该计划被用于生成将会把所识别的源素材变换成所要求的客户可交付物的必要工作流协调。

图12A示出了计算机系统1200和用户1202的表示。用户1202使用计算机系统1200来执行数字发行功能。计算机系统1200存储和执行数字发行处理1290。

图12B是示出了容宿数字发行处理1290的计算机系统1200的功能框图。控制器1210是可编程处理器并且控制计算机系统1200及其组件的操作。控制器1210从存储器1220或嵌入式控制器存储器(未示出)加载指令(例如以计算机程序的形式)并且执行这些指令以控制系统。在其执行中，控制器1210以软件处理的形式提供数字发行处理1290，以例如提供素材分析和制造规划。或者，此服务可被实现为控制器1210或计算机系统1200中的单独的硬件组件。

存储器1220临时存储数据以供计算机系统1200的其他组件使用。在一种实现方式中，存储器1220被实现为RAM。在一种实现方式中，存储器1220还包括长期或永久存储器，例如闪存和/或ROM。

存储装置1230临时或长期存储数据以供计算机系统1200的其他组件使用，例如用于存储被数字发行处理系统1290使用的数据。在一种实现方式中，存储装置1230是硬盘驱动器。

介质设备1240接收可移除介质并且读取和/或写入数据到插入的介质。在一种实现方式中，例如，介质设备1240是光盘驱动器。

用户接口1250包括用于接受来自计算机系统1200的用户的用户输入并且向用户呈现信息的组件。在一种实现方式中，用户接口1250包括键盘、鼠标、音频扬声器和显示器。控制器1210使用来自用户的输入来调整计算机系统1200的操作。

I/O接口1260包括一个或多个I/O端口，用于连接到相应的I/O设备，例如外部存储装置或补充设备(例如打印机或PDA)。在一种实现方式中，I/O接口1260的端口包括诸如以下端口：USB端口、PCMCIA端口、串行端口和/或并行端口。在另一实现方式中，I/O接口1260包括用于与外部设备无线通信的无线接口。

网络接口1270包括有线和/或无线网络连接，例如支持以太网连接的RJ-45或“Wi-Fi”接口(包括但不限于1202.11)。

计算机系统1200包括计算机系统典型的另外硬件和软件(例如电源、冷却装置、操作系统)，但为了简明在图8B中没有具体示出这些组件。在其他实现方式中，可以使用计算机系统的不同配置(例如不同的总线或存储配置或多处理器配置)。

提供对所公开的实现方式的以上描述，以使得本领域的任何技术人员能够做出或使用本发明。本领域的技术人员将容易清楚对这些实现方式的各种修改，并且这里描述的一般原理可被应用到其他实现方式，而不脱离本发明的精神或范围。因此，另外的实现方式和变化也在本发明的范围内。此外，要理解，这里给出的描述和附图代表了本发明所广泛设想到的主题。还要理解，本发明的范围完全涵盖了本领域的技术人员可显而易见的其他实现方式，并且本发明的范围因此仅由所附权利要求来限制。

附录1数字供应链基本原理

发行骨干(DBB)代表了Sony将其在娱乐供应链服务中的存在扩展到数字的推进力。此推进力的重要性指示了对于数字供应链如何随着时间而演变以及利用知识和经验的远见。通过利用供应链KPI(持续改进中)、供应链引导原理、针对性先进技术、生命周期管理以及规划和分析活动与执行工作的有效分离对于供应链性能、灵活性和服务2的追寻。Sony和许多合作者内的供应链专门技术将被取出来提供关于DBB在其最初发布之后必须如何进步的展望，并且应用领先的操作实践，以及先进的自动化内容处理功能。

产品生命周期管理

除了固有特性以外，产品还将具有其将遵循的典型生命周期。可从产品的开端一直到其生命的结束(有可选的再生)跟踪此生命周期。来自光介质上的娱乐内容的物理制造的教训教导我们，通常将存在需求的球棍状上升，之后是衰减曲线，下降速率各有不同。这种知识使能了增强的容量规划。

作为数字供应链服务的提供商，Sony将具有对于其顾客的产品生命周期的既定兴趣，作为馈送到与DBB有关的规划活动中的数据点。此类意识将允许DBB以非常高级别的效率操作，同时以合理的成本交付领先的服务级别。B2B和DBB的数字方面更改了产品生命周期管理的动态特性，但类似的原理可在各种级别被应用。例如，受管理多层级存储环境可受益于知道产品发布窗口和在层级之间抢先移动文件以最小化检索等待时间以及在在线存储层级中存储的成本。另外，产品家族如下所说明可影响产品的生命周期的特性。从诸如标题是续集还是前传之类的属性以及一般情境事件(比如工业级别的文件格式的转换)中可得出额外的生命周期信息。

产品家族

对产品类型、处理步骤、格式类型、比特率和交付规格要求的分析通常可导致对模式的识别。对模式的进一步审查通常将导致基于正制造的产品的固有特性的分组(就物理和虚拟意义两者而言)。这些分组提供了自然分割，这种自然分割可用于将产品分组成家族，对于这些家族可应用不同的过程和执行规则。

DBB必须灵活并根据这些产品家族支持协调工作流的定制。与大多数的分割工作一样，工作流与产品家族的匹配将减少唯一案例和例外的总体数目。目标是使执行流水线成为流线型的并使其灵活。这进而使得能够专注于供应链内驱动价值的核心过程。

作为示例，对操作数据的分析可能揭示产品的两个主要分组之间的共性：正片与剧集。每类产品可具有将有助于其可工作性(下文定义)的理想流程。类似地，所采集的内容与所产生的内容相比可受益于替换的过程或协调工作流。

可工作性和重要事件管理

构建数字供应链涉及与传统供应链类似的许多过程步骤的协作。在执行之前规划活动，重点在于打下根基，以使得一旦计划被实施，就可流线型地执行。在这些计划内定义重要事件允许了能够更容易管理和跟踪的离散单元。潜在的延迟可被分析和跟踪直到根本原因。重要事件管理因此改进了可工作性，避免了执行期间的退步或例外。

使DBB提供可工作性和重要事件管理支持将是允许Sony通过真正成为其数字供应链顾客的合作者而成为卓越中心的核心支柱。DBB可利用提供针对受输入参数调整的时间线规划的默认过程步骤的模板。目标日期被确立并对照实际被跟踪，并且提供了合作以达成统一目的机会，同时相互理解调整的效果。

DBB将具有对外部触摸点的依从性，这些外部触摸点可影响可工作性，例如从母版制作组获得母版。在具有与产品家族相关的参数(例如剧场版和剧集版标题之间的不同的母版制作交货时间)的模板中可捕捉接收母版的重要事件。将整个工作分解成重要事件可帮助识别未能准时完成请求的根本原因。对这些请求的分析可示出将延迟关联到特定的产品家族的模式(例如，由于经由采集而得到的源素材的不受控制或未知的质量，所采集的内容的母版可经常遭遇延迟)，并且通过使精力集中于针对可被跟踪到特定产品家族的该特定片段改进过程或系统来帮助解决可工作性。

运行策略和优化

有了这些至关重要的基础后，可以实现进一步优化。基础元素提供数据点，这些数据点可通过精密的解析被处理，从而导致对模式的额外识别以及由人驱动的持续改进。这些模式和过程改进随后可用于定义作为运行策略馈入的各种级别的规则集合。

灵活性是DBB必须坚持的关键宗旨并且其最终将允许对以上定义的运行策略的有效使用。在系统级，应用优化供应链的规则集合的能力必须是系统的核心能力，并且是理想情况下在所有供应链系统上甚至是DBB外部都能够利用的能力。支持增强的供应链实践的这个可扩展性不应限于DBB，而是应可用于遍及整个娱乐供应链卓越中心的集成。

Sony预期集中现有知识以对于DBB的初始展出在可能时并入运行策略和优化。此知识将来自现有系统和过程的数据点并且将针对未来的方案被并入。将会看到对于以下事项的直接影响：即，迁移运行策略将如何被定义来确保驱动最高利益的标题和客户将被导入和装载到DBB中。最初，所得到的规则可以按半自动化过程方式来应用，但Sony的长期目标是以更系统的方式应用运行策略和优化，并且一旦有益即包括自动化。

附录2合作者与客户之间的关系

1.概述

发行骨干(DBB)要求维护某些类型的数据以便实现其向合作者提供服务其内容发行需要的能力的设想。合作者、客户、客户简档、规格和配置是在DBB内必须为其存储和管理数据的若干个关键实体。

2.描述

图13是示出预期合作者和客户如何与客户简档、规格和配置相关的样本实体关系图。此图的目的不是想要定义最终设计，而是想要帮助描述预期满足状态过程映射图的关系的类型。

合作者是DBB的内容拥有者和顾客。合作者将赞助用户并向它们授予对DBB的访问权限，以便生成请求和对工作流状态的可见性。每个合作者将具有向一个或多个客户发行内容的能力。

客户是与合作者订立合约接收内容的公司。客户记录定义了定义业务实体所需要的信息。虽然在这个级别可存在联络人信息，但联络人也可与客户简档相关联，如下所述。

单个客户可与多个合作者有业务，例如Amazon与Sony和Paramount。对于每个合作者将维护单独的客户记录。然而，在多个合作者下表示同一公司的所有客户记录必须被关联起来以提供跨所有合作者的该客户的视图。样本客户包括Apple和Amazon(DDI)、Comcast和AXN(Broadcast)。客户将按照需要被添加到DBB以便履行合作者对于内容发行的请求。

客户简档用于定义每个客户对于内容交付的要求。对于每个客户可设立一个或多个客户简档以表示该客户的多个业务模型，例如DST、DDI、VOD或者随着要求按地域或其他业务/技术原因的变化。如上所述，如果对于客户存在多个联络人，则联络人信息可被关联到客户简档。客户简档可由DBB管理员创建。

规格定义了支持自动化和手动工作流所需要的关键变量和要求。规格信息可以是许多客户共同的。将维护一规格母版来允许将单个规格关联到多个客户。必须在客户级或在母版级允许对规格的修改。客户级的修改可产生规格母版内的新记录。母版级的修改将允许改变被传播到与该规格相关联的所有客户。应当有确证来确保不创建重复的规格。

虽然规格的功能要求是支持内容处理和发行，但出于审阅和通信目的，合作者将可获得规格数据的人类可读摘要。

变量-联合规格，一些信息可被定义为每个简档所特有的。规格内的此信息可被定义为在关联到客户简档时的输入变量。例如，交付规格可定义交付的手段，但依客户而定的变量可包括宽高比偏好。

配置-配置是为每个客户简档单独创建的信息的集合。规格表示可被关联到客户简档的可重用的信息集合，而配置可以是依客户简档而定并且是其所特有的。在一些情况下，“标准配置”可以跨多个客户简档被重用。

规格类型-DBB存储和管理多种类型的规格以支持内容变换和交付。规格类型包括但不限于：

a.产品规格-定义了创建最终发行的产品所要求的技术元数据，最终发行的产品可包括视频、音频、图像、字幕等等。该规格利用像代码转换这样的DBB服务并与之共享，以便产生具有匹配的技术规格的最终产品。该规格包括比特率、帧率、文件格式等等。

b.元数据规格-定义了生成元数据可交付物/文件所要求的信息。利用元数据规格内可用的信息，系统确定最终状态元数据文件格式(例如XML、Excel、CSV等等)以及对于特定的标题/Alpha可包括的特定元数据字段和值。注意到以下这点是重要的：元数据规格充当对实行元数据的适当最终结构的确证。某些字段可以是要求的并且强制以某种格式(YYYYMM-DD)提供数据。其他字段可被定义为接受重复的值和受控制的词汇。元数据规格提供了解释DBB企业典范元数据仓库所需要的映射和变换规则。将利用企业典范DBB元数据ID来引用在规格内定义的字段。

c.其他规格-在设计/实现期间可识别额外的所要求的规格。

配置类型-DBB存储和管理多种类型的配置以支持内容处理和交付。规格类型包括但不限于：

a.组装配置-是依内容处理而定的，在用于产品实质的规格和用于组装的配置之间存在分离。组装配置定义了内容的组装和出现顺序以及诸如徽标、分级、警告、广告黑屏等等之类的添加。此信息由于基于客户需要的这些配置的更大可变性而与用于产品的规格相分离。多个客户可采取相同的文件规格和比特率，但要求不同的组装配置。组装配置项目的示例包括徽标、分级、漏洞以及覆盖、警告卡插入、色带及音调以及广告黑屏。

b.包裹配置-定义了生成包裹所要求的信息。与包裹有关的信息可包括打包声明位置/格式、打包内容命名规约、内容目录路径、输出包裹目录路径以及包裹包装类型定义(例如MXF、ZIP、目录结构或松散文件)。

c.交付配置-定义了交付包裹所要求的信息。虽然意图是数字交付(例如Aspera、SmartJog、FTP)，但交付配置能够应对物理输出。一个示例是将包裹输出到硬盘驱动器并且使其被装运到物理地址。在此示例中，交付配置方法是“硬盘驱动器”。

假定FTP交付配置被生成，则对诸如FTP这样的方法的选择是配置的一部分。诸如IP地址、用户名、口令和端口之类的额外输入被输入来完全定义交付方法。此信息被存储为关联到客户简档的数据的集合。

对于客户简档可添加关于硬盘驱动器或Aspera的第二配置。每个配置所要求的数据是依所选择的交付方法而定的。

客户/简档状态-为了控制DBB是否可服务于客户或客户简档，状态和相关联的规则必须是可配置的。

简档/规格关联-在客户简档内，在以上所述的每个类别内可指派多个规格。每个种类的一个规格被确立为默认的，但是用户可推翻该默认并且选择已被关联到该客户简档的另一不同的可用规格。

在一个示例中，客户简档的默认交付规格是FTP，但是由于特定请求的大小较大，所以请求者可选择硬盘驱动器作为替换的交付规格。

标题类型-如上所述可存在多个产品规格。在将产品规格关联到客户简档期间，存在允许定义标题类型的变量。这允许了为特定类型的产品(例如正片、剧集或预告片)指派规格。被选择来处理的每个标题在正片或剧集的情况下具有默认标题类型或者在仅限预告片的请求的情况下允许选择标题类型。此变量支持处理具有不同的产品规格的不同类型的标题的需要。

3.用户接口

从用户接口的角度来看，预期经由用户接口来处理对合作者、客户和客户简档的管理。这些特征将大多由内部DBB业务分析员管理。然而，规格是技术性的并且将最有可能由DBB技术资源管理并且如果要求的话可在XML内管理。

4.服务

除了通过用于管理合作者、客户、客户简档、规格和配置的UI以外，DBB不暴露服务。将仅从DBB内处理对此数据的管理。

5.接口的系统

合作者、客户、客户简档、规格或配置将不会利用到外部系统的接口。

6.多租户

以上所述的关于合作者/客户关系的概念固有地定义了对DBB的多租户要求。管理程序必须允许创建以上所述的层次关系。

附录3请求管理

1.概述

DBB要求用户接口使能输入对各种形式的内容处理的请求。请求管理提供了识别客户及其需要的可交付物所需要的功能。此用户接口是负责履行的业务用户与DBB之间的交互的主要点。DBB所需要的所有澄清信息，无论是关于技术的还是关于业务的，都是通过此接口来管理的。业务单元的所有状态要求都是通过此接口来解决的。在可行的范围内，希望此接口利用稍后所述的数据结构来创建允许用户输入更一般的信息并被系统引导或辅助到DBB履行要求所需要的特异级别中的智能。

请求管理是一套用户接口(UI)，其允许了经授权的用户对这里描述的UI和如下所述的DBB工作流细节的更粒状级别的访问。

2.描述

图14显示了对请求维护模块的主要输入。

LOB输入-LOB或“业务范围”输入表示发起者人，Sony销售部门。这些部门许可内容给各种顾客并且要求来自请求者的履行，例如全球产品履行(WPF)。请求者将使用DBB来创建和交付此内容。在高级别，LOB提供交易条款，例如许可窗口、播放日期、许可类型和其他有意义的信息。此信息将被包括在请求者所提交的请求中。另外，LOB提供了对于请求、标题和客户的主输入。一般来说，如适用于合作者的，这是可被要求被包括在包裹元数据中或支持计费交易的业务相关信息。

客户-发起者将指定对于给定的请求要处理的一个或多个客户。DBB请求者将在请求内确定适当的客户简档，如果单个客户具有多个简档的话。客户/客户简档表示已就特定标题与LOB订立合约的内容许可者。在请求创建之前假定客户已被装载并且所有适当的简档和规格已被创建。必须使规格信息以仅限查看格式对请求者可用，以便帮助简档选择。

标题/Alpha-请求内的实质命令是交付一个或多个指定的标题给一个或多个客户。如“附录4库存组织”中所述，Alpha表示标题内的可能是依给定的地域或市场而定的内容级别变化。例如，对于标题“Over theHedge”，对于日本的剧场发行，改变了其中一个人物用高尔夫球棍击打另一人物的场景。基于此要求，到任何日本顾客的所有后剧场发行都使用相同的编辑版本或Alpha。

标题/Alpha选择-假定在标题具有多于一个Alpha的情况下对特定Alpha的选择将由请求者执行。然而，可基于依赖于在客户简档级别和alpha级别存在的元数据的业务规则来辅助和/或自动化此选择。

规格/配置选择-内容规格和配置将被定义并与客户简档相关联。基于要交付的标题类型，可有多个规格和配置被关联到一客户简档。如“附录2合作者-客户关系”中所述，可存在包括默认在内的多个规格和配置。请求者可选择请求内的替换的经批准的规格。有信息可用于辅助/自动化对规格的选择。例如，对于客户定义多个产品规格，一个用于剧集内容，一个用于正片内容。在客户简档维护内，定义了关于适当规格的选择的业务规则。对于此示例而言，这可利用“标题类型”值来进行。同样的这个元数据可被关联到在请求上选择的标题，从而帮助识别标题/客户组合所要求的实质规格。

多标题/多客户请求-可以按若干不同的方式生成请求。以下是一些示例：一个标题和一个客户；一个标题和多个客户；一个客户和多个标题；以及多个标题和多个客户。

最复杂的情景是多标题/多客户。为了最小化此情景的复杂度，希望确保当多个标题被选择时，所有被选择的标题都将被履行到每个被选择的客户。请求者不会具有配置哪些标题将与哪个客户相关联的能力。在不是对所有客户履行所有标题的情况下，将必须作出多个请求。

3.用户接口

用户接口应用允许了用户对于各种请求创建、更新、取消和获得状态。也假定了搜索和总结显示。在客户/简档的定义和标题选择要求额外的辅助/自动化选择的情况下，这些是以向导格式来处理的，引导用户经过作决定的过程，直到完成订单所必要的深度。这个深度应当达到特定的组件搜索和选择以及手动规格选择的级别。允许给用户的确定的深度应当是可配置的。某些级别的选择，例如对特定源组件的选择，可被确定为是操作人员的职责。

4.服务

请求模块服务被假定为仅在DBB内暴露并且不要求正式API来允许与其他系统相配合。然而，该体系结构将不会排除直接来自任何合作者的请求数据流。

5.接口的系统

请求模块将具有与顾客主控、标题主控、工作流主控和任务管理的功能关系。出于应用体系结构的目的，这些数据集合将在骨干内并且不被接口。唯一例外是GPMS标题接口。标题/Alpha信息将被接口并且在支持发行所必要的程度上将被存储在骨干内部。请求模块将要求直接查询GPMS以便查看未存储在DBB中的额外标题信息。

6.多租户

DBB具有如“附录2合作者-客户关系”中描述的多租户能力。多个“合作者”将要求访问请求UI。必须对每个合作者用户组独立维护登录和安全权限。对于这里描述的所有级别的信息，必须完全隔离数据。

附录4库存管理

1.概述

除了自动化内容处理技术的使用以外，DBB的关键目标还包括将基于规则的自动化扩展到履行工作流的所有方面。当前拍摄的娱乐库存元数据模型未拥有在源资产识别的领域中支持自动化的严格组织。资产接收和存储过程和通常记录的元数据遭遇相当大的差错率。由此导致的在生产运行时识别正确源资产所要求的手动劳动已成为了当前数字履行中的重大瓶颈。更严厉且严格的元数据控制的实现可使能资产选择的自动化并大大减少手动干预和整体吞吐量。

已识别了要求更多结构以便支持明确的库存的两个关键概念。在Sony的命名体系中将版本的概念重命名为“Alpha”。此概念表示对于给定的标题在库存内可存在的内容的变化。向此概念添加结构将允许对库存的更准确询问，从而在给定标题内创建库存的兼容“套件”。在Alpha组织内，基于组件的库存通过帮助将源资产链接到其支持的工作流而利用了传统的制造纪律。这些概念以与素材清单支持传统制造自动化相同的方式支持自动化媒体内容处理。

库存可视性的范围将涵盖DBB DAM方案内的数字资产并且还将扩展到合作者的物理资产管理方案内的外部物理和数字组件。这里描述的组织原理被实现到物理资产中的程度必须是灵活的，以便可以满足对于成本和交货时间分析的业务需要。

2.描述

图15显示了存在于具有两个Alpha(导演剪辑版和剧场发布版)的标题与将被识别来为导演剪辑版Alpha服务的组件的家族之间的样本层次体系。

Alpha-alpha概念帮助了DBB内的两个关键要求；识别客户对于具有基于版本的视频或音频内容变化的标题的需要，以及作为为这些变化服务所需要的资产库存的组织原理。

Alpha通常描述标题的不同版本。这些差异通常与标题/Alpha可在何处以及如何被发行有关。可基于在特定地域、市场或介质中显示标题所要求的标准和实践编辑来创建Alpha。由于每个顾客将在其简档内拥有市场、介质和地域定义，所以将相同数据关联到alpha可辅助为所选客户自动识别适当的版本。要求将发行规则的各种概念关联到每个Alpha。例如，某个电影的“未分级”版本将被准予全球发布，但仅针对数字销售。去除了暴力和脏话的特定场景的同一电影的编辑可以是仅有的被准予在一个或多个外国地域TV发行的版本。结果，DBB可为DST客户选择未分级版本，并且为UK广播顾客选择经编辑的版本。

Alpha也将被用作数字和物理的资产库存的组织工具。当前的业务过程导致了对为每个Alpha服务所需要的资产的家族的创建。为给定标题下的每个Alpha创建各种宽高比和标准的图片元素。随后创建音频和文本资产以符合这些图片资产。要求支持被创建来为特定Alpha服务的所有资产的创建、关联和包含的过程。在最低限度上，摄取将要求对被添加到DBB的所有资产识别特定alpha。

Alpha概念还扩展到对预告片的识别。针对特定客户对要使用的预告片的识别遵循与将被应用到可变完全节目内容相同的规则。

套件-被确定一起工作(相容且同步)的组件应当被组织。这将允许工作流主控数据指向套件类型。在Alpha下，套件将允许对将一起工作的资产的具体确认。套件具有一个视频组件和一个或多个音频组件，其中任何音频将与该套件内的视频一起工作。工作流主控数据(由客户规格支持)将应对从套件内使用哪个音频或支持素材的可变性。当前的DIAMONDS资产(多路复用的音频和视频)是单个套件。

套件类型必须是工作流主控数据已知的并且必须具有将允许基于诸如宽高比和标准之类的关键值来选择正确套件的属性。

组件-组件表示离散的音频、视频、文本和/或组合资产，它们被存储为源资产，用于内容处理。虽然组件概念可被扩展到档案或保护资产，但其主要作用是允许对特定制造过程所要求的资产的明确识别。组件在许多方面可被认为与传统制造中的“零件号”类似。组件组织可从DBB扩展到提供对关键物理资产中的可见性。

资产到DBB中的输入具有三个不同的部分。

a.组件类型-组件类型表示尽可能详细地描述资产的规格。该规格将确定作为内容处理的关键的元数据字段的值的可接受范围。设想被摄取到DBB中的所有组件必须被对照组件类型来接受，其方式类似于就制造而言的素材接收。例如，表示16×9宽银幕式SD视频资产的组件类型具有将允许每个关键字段被限于与该组件可接受的相匹配的值的灵活规格。图16示出了如果资产对于此组件类型将被考虑则该资产将被限制到的宽高比值的列表。对于技术数据的这种定义将扩展到对于内容处理关键的所有库存元数据值。

b.组件要求-组件要求(CR)是对特定标题/Alpha内的特定组件类型的请求。设想CR将会驱动创建和摄取资产到DBB中。CR可作为请求的结果被创建(“附录2合作者-客户关系”)或者可通过制造规划活动被创建，其中母版制作组将履行使标题/Alpha为发行做好准备所必要的CR。例如，Spider-man 4的剧场Alpha处于为后剧场发行而进行的制作中。规划组对于八个视频组件，识别对于骨干的视频资产要求。这些是在宽高比和标准上有变化的DBB母版规格视频资产，它们全都是支持下游DBB制作所需要的。这导致创建由母版制作组履行的八个CR。当资产根据组件规格被创建并被交付供摄取时，它们将基于对照规格要求的检查而在摄取之前被接受或拒绝。一旦被接受，资产就将履行CR。

c.组件(已履行)-一旦通过资产的接受和摄取履行了CR，组件就将变得对于DBB可用以供处理。如“附录5工作流主控数据”中所述，每个内容处理规格可识别创建最终产品所要求的一个或多个组件。仅当对于特定标题/Alpha存在已履行的组件时，才可执行内容处理规格。

资产-骨干内的丰富媒体资产表示如上所述的组件的(一个或多个)实质。如同大多数MAM/PAM系统中常见的那样，利用独立的元数据来维护资产。在DBB中，资产还与其被对照来摄取的特定组件相关联。资产元数据将允许DBB解释可存在于标题之间的内容处理变量。

亲子关系-必须在编码和摄取期间记录父资产。如果在DBB内创建了新的主控组件，则也必须记录此信息。此信息链接必须允许用户追溯用于创建任何DBB资产的实际资产以回到编码的物理母版或摄取的文件。

组件继承-为了保护明确的库存，控制组件的替换并且防止复制品进入到DBB中是重要的。当组件要求被创建并且在DBB中在同一组件和标题/Alpha下存在资产时，系统将通过识别复制并且指示要求解决工作流来管理继承。

3.用户接口

虽然DBB被接口到合作者的标题主控用于标题/Alpha生成，DBB UI将支持标题及其相关联的Alpha的直接创建。应当注意，与标题(例如标题类型)和Alpha(例如宽高比)两者相关联的参数需要经由DBB UI来输入。

支持Alpha的用户接口要求创建Alpha类型所需要的管理配置程序。这些类型允许了诸如剧场版或导演剪辑版之类的常见Alpha类型被标准化并用在所有适当的标题上。这些管理程序允许了关于以上所述的地域和市场适用性的概念的业务规则定义。为常见业务规则创建Alpha模板可能需要额外一级管理程序。

组件类型规格的创建与“附录5工作流主控数据”紧密链接，并且可被包含在UI的集成套组内。此UI要求创建记录的能力，该记录包括媒体源为了支持指定的工作流而必须满足的技术要求。这些记录被链接到工作流，创建了集成的库存和内容处理信息。

4.服务

DBB应当拥有能够与合作者的标题主控相接口的暴露的服务。具体对于Sony，这些服务支持如上所述的标题、Alpha和相关联的规则。

5.接口的系统

对于Sony Pictures Entertainment实现，希望有到GPMS(全球产品主控系统)的接口。DBB将存储操作上必要的标题/Alpha数据。DBB对于R1将支持从GPMS的接口，但必须可扩展到将允许合作者把标题数据接口到DBB中的API。为了向DBB提供对关键物理资产的组件可见性，到GOLD系统(全球订购和库数据库)的接口将是必要的。为了支持对成本高昂的制造情景的可见性，可能必须将DBB组件可见性扩展到诸如高清晰度视频母版或配音音频语言之类的关键资产。

6.多租户

每个合作者拥有DBB内的任何数目的标题。基于每个合作者下的标题的组织来分离库存。用户必须由合作者赞助并且基于该合作者被提供对标题及其相关联的资产的权利。

附录5工作流主控数据

1.概述

DBB一旦可能即支持自动化工作流。对当前履行过程的审阅表明，对于一些过程，关于源资产选择、内容处理要求以及甚至打包的决定可受某些规则的约束。对于其他过程，为了澄清含糊之处，可能要求人类干预。随着由内容处理技术使能的客户可交付物规格的持续整合和源库存的简化，关于工作流过程的规则的内在化变得可能并且越来越合乎需要了。

此外，向自动化内容处理系统提供确切的规格细节是必要的。由“按订单生产”模型引入的差错不支持DBB中设想的许多效率。工程人员对内容处理工作流的创建、测试和实现提供了一致性能的优良平台。通过使用简化的规则调用这些工作流的能力将允许将增强顾客服务和内容处理两者的劳动的高效分离。

工作流主控数据提供了支持制造规划的围绕工作流的元数据。此元数据标识了支持客户规格所需要的工作流。此外，在工作流数据外支持所要求的套件和组件信息以便允许对库存的高效询问。利用此支持信息，客户规格的定义和所要求的标题/Alpha允许了制造分析引擎确定适当的源库存要求和创建产品所需要的工作流。工作流主控数据与库存元数据组织(参见“附录4库存组织”)协同动作以便支持制造规划的要求(参见“附录6制造规划”)。

虽然希望完全自动化，但操作环境中的灵活性也是关键要求。将以模块化方式来设计DBB服务和协调它们的工作流。虽然工作流可在端到端过程中协调多个服务的输入参数、动作和输出，但它们也必须提供对DBB的基本服务的访问。关键任务是可具有不涉及制造计划的直接UI要求的操作。这些任务，例如文件检索、代码转换、打包和其他，必须基于用户定义的参数可执行。这允许了操作人员对DBB服务的完全使用，以便应对不能完全自动化的中间或特殊工作流。

2.描述

图17描述了工作流主控数据对于DBB的作用。阴影方框是由请求者定义的选择。无阴影方框中的信息是从DBB库存和工作流主控数据得出的。

工作流-图17中所示的实体关系显示了元数据管理的方法，其中核心要求是将内容和客户的识别与制造计划的定义相分离。由于请求者识别客户简档，所以DBB能够识别客户规格。利用此信息，DBB能够确定要用于创建指定的产品可交付物的工作流。这些过程将由管理人员创建和管理并且将通过装载过程被审查。

基于客户规格的工作流-制造规划是基于对客户规格和标题/Alpha的识别的。工作流主控数据定义了完成客户规格所必需的工作流并且定义了每个工作流的库存要求。此数据允许了通过骨干运行“如果怎样将会怎样”情景，而无需运用工作流本身的业务规则。

基于客户规格的工作流实际上将是将被设计来针对给定的标题alpha符合库存的状态的一系列工作流。例如，被设计来创建8MB Mpeg2输出的工作流将包括编码和摄取母版视频文件的步骤，如果该文件不存在于DBB内的话。如果文件存在于DBB内，则这些步骤将被跳过并且工作流将开始于文件检索步骤。

基于UI的工作流或关键任务-工作流协调工具将是与DBB服务的交互的关键点。虽然希望基于客户规格的工作流是发行情景的规范，但DBB内的所有关键任务必须对操作人员可用。例如，用于德语客户的8MBMPEG2的制造计划要求相容且同步的德语音轨。为此规格服务所需要的当前套件缺少了该音轨。由于订单匆忙，相容、同步的音轨被直接交付给操作人员，操作人员随后执行被设计来允许从DBB检索特定文件、选择和执行适当的代码转换规格、打包和交付到客户的关键任务。

关键任务将被具体设计来支持常见操作并且将支持基于特定业务需要不能自动化的制作要求。

协调-设想工作流协调工具将被用于创建、管理和协调执行工作流所要求的任务。此工具应当允许包括和询问业务规则，这些业务规则可以是依内容、依客户或依其他而定的，并且将实质性地影响工作流如何被执行和/或工作流内的哪些任务是必要的。

支持数据-工作流将约束要协调的任务及其依从性。这些工作流将与将帮助库存选择和计费要求的支持数据和其他输入交互。此数据将包括但不限于以下的。

这些工作流一般将包括以下信息：

a.任务-任务被定义为从源母版元素进行到最终客户可交付物所要求的工作流内的任何步骤。这些任务将包括编码、摄取、QC、代码转换、水印添加等等。工作流协调方案将允许支持新内容处理技术和扩展的自动化两者所需要的任务的灵活创建/配置。任务是内容处理协调的主要构建块。每个任务可以是手动的或者自动化的并且将具有与之相关联的状态和优先级。参见“附录7任务管理”，有完整描述。

b.计费交易-所执行的工作必须与DBB内的可计费服务相关联。计费交易将包含计费系统询问费率卡信息所要求的信息。“附录13金融过程”概述了骨干将如何管理计费交易。工作流被设计为容适金融报告的需要，使得当工作流完成时计费交易可被创建和报告(或“确定状态”)。

c.套件-被确定为一起工作(相容且同步)的组件应当被组织在一起。这允许了工作流主控数据指向套件类型。在Alpha下，套件允许了对将一起工作的资产的具体确认。套件可具有一个或多个视频组件和一个或多个音频组件，其中任何音频将与该套件内的视频一起工作。工作流主控数据(由客户规格支持)将应对从套件内使用哪个音频或支持素材的可变性。当前的DIAMONDS资产(多路复用的音频和视频)是单个套件。套件也可包括闭合字幕、字幕和其他内容类型。

d.组件类型-在必要时，应当识别任务所要求的输入组件类型。当在请求内指定了标题/Alpha时，此信息支持对资产库存的分析。此信息表示对于制造规划和执行的核心要求(参见“附录6制造规划”、“附录7任务管理”以及“附录8受管理多层级存储环境”)。

工作流变量-工作流允许对内容处理案例的变量的配置。例如，用于不同标题的两个视频资产可共享共同的组件类型。然而，资产级元数据可指示将影响内容处理的差异。工作流主控数据内的变量将允许基于两个源文件中的差异来选择不同的内容处理任务或集合或任务。

所提供的过程流程图覆盖了工作流元数据要控制的工作的范围。工作流的一般类别如下：

a.编码/摄取-源资产输入到DBB中。

b.产品变换-自动化和手动内容处理。

c.元数据创建-客户特定元数据的创建。

d.支持媒体的检索-支持图像、章节照片等等的手动或自动化检索。

e.打包-向产品、元数据和支持媒体应用打包规格。

f.交付-将包裹交付到客户。

3.用户接口

工作流主控数据的创建和维护具有灵活的用户接口，其允许了内容处理规格被识别、结合和链接到特定工作流中。该UI允许了创建表示工作流的记录并且必须允许每个工作流被链接到适当的客户规格和组件类型(参见“附录2合作者-客户关系”)。工作流和关联主控数据必须容易被拷贝和重配置。应当注意，在R1中没有假定库存组织信息完全与维护和执行工作流主控数据的工具集合/服务相集成。

将要求关键任务用户接口提供到DBB内的服务的直接访问。在“附录6制造规划”、“附录7任务管理”和“附录8受管理多层级存储环境”中将更详细论述这些UI。

4.服务

制造规划引擎将访问数据，但取决于最终体系结构决定可利用简单数据库调用来访问数据。

5.多租户

工作流主控数据的共享可发生在合作者实例间，从而允许用于共同的可交付物的工作流被多个合作者利用。然而，此功能将是管理性的。UI和数据层在合作者实例中都必须被完全隔离。费率卡信息如上所述必须支持按合作者的变化以及可能的特惠费率。

附录6制造规划

1.概述

如“附录4库存组织”和“附录5工作流主控数据”中所述，主控数据必须支持工作流自动化。这些部分及其要求描述了跨所有库存和内容处理工作流维护的主控数据。DBB将利用此主控数据来响应于来自请求维护模块的请求而创建特定的制造计划。这些制造计划表示用于内容处理的协调的核心指令集并且将生成成本和交货时间估计所要求的信息点。

虽然希望在没有用户干预的情况下创建和执行制造计划，但要理解，为了应对非常情况，对这些计划的操作操纵将是必要的。此信息层及其计算能力必须保持灵活，以使得DBB的生命周期中早期的高费率操作干预可得到支持，并且随着这些费率下降，高费率的完全自动化规划也可得到支持。

2.描述

图2描述了在DBB中创建制造计划所需要的实体和过程。制造分析引擎利用“附录4库存组织”和“附录5工作流主控数据”中描述的工作流主控数据和支持库存数据以及来自“附录2合作者-客户关系”中描述的请求模块的输入。利用客户规格，该引擎可识别所要求的适当工作流。在工作流内，定义了创建客户规格所需要的所有任务。另外，在适用时定义对于每个任务所有需要的组件类型。利用此信息，该引擎首先执行素材分析。DBB针对指定的标题/Alpha和客户规格，就所需要的组件查询DBB库存。此分析的结果确定了完成所要求的工作流所必需的任务。

如“附录5工作流主控数据”中所述，基于客户规格的工作流将必须考虑到所有可能的库存情景。这些工作流必须覆盖所需要的库存组件的编码和摄取直到交付。它们必须是模块性的，并且提供灵活性来应对所需要的库存处于更高的准备阶段的情景。制造规划引擎将执行素材分析以便确定创建所需要的产品所必需的特定工作流。

DBB工作流可包括较高分辨率文件到较低分辨率文件的代码转换，该较低分辨率文件随后被打包和交付。DBB操作可创建较低分辨率文件并将其存储在DBB文件存储系统中作为限制使用替换分辨率母版。在此情况下，工作流将需要询问库存，确定较低分辨率文件存在，并且选择替换工作流来拷贝和交付较低分辨率文件，而不是从较高分辨率文件进行代码转换。例如，对于Spider-man 3，8MB MPEG2文件已被创建并存储在文件存储系统中。在所要求的工作流内，编码和摄取、检索和将视频母版文件代码转换成8MM文件的任务将不是必要的，因为8MB限制使用替换分辨率母版已经存在。在此情况下，工作流将被截短。对于Spider-man 4，由于不存在替换使用文件，所以可能要求从编码起的整个工作流。

取决于详细设计，在执行实际工作流之前，出于成本和交货时间目的，可能必须重新运行制造计划。其原因是资产库存的动态性。制造计划可导致花费合作者的大笔资金，因此在执行之前可要求批准。支持客户起动的单个请求可要求多个批准。在批准时段期间，DBB内条件可变化。可能发生了所需要的母版文件的摄取，或者现有的母版文件可能被放在QCHOLD上。结果，初始的分析可能仅产生对成本和交货时间的估计，其将被用于DBB外的COFA(参见“附录13金融过程”)。一旦被批准，制造分析引擎就将运行第二次分析，检查实质变化，并且如果不存在，则执行制造计划。

成本估计-如“附录5工作流主控数据”和“附录13金融过程”中所述，DBB将与计费系统相接口，该计费系统将存储费率卡。计费交易将利用费率卡数据以便帮助定价计算。当创建制造计划时，基于素材分析的结果来收集定价计算所需要的变量，并且按照所识别的工作流所确定的来定义定价。此信息将被捕捉以用于批准工作流中。

交货时间估计-必须估计每个过程的交货时间并且必须形成工作流的总交货时间。尚不知道计算的方法。真实容量规划可超出DBB的初始范围。然而，认为对最近的历史数据的分析可用于估计交货时间。

请求模块交互-此信息将被呈现给请求者供批准。交货时间将被与到期日相比较以标记出任何潜在的冲突或对更高优先级的需要。将使成本可用，并且其将允许用户发起批准工作流。

制造计划修改和发布-制造计划将由源组件要求、计费交易、交货时间估计和所要求的工作流构成。制造计划必须被业务规则审查，业务规则可将其标记为供DBB操作组手动审阅和发布。这可基于某些任务的存在，或者可在请求级基于特殊情况被标记。关于制造计划的操作审阅的规则必须是灵活且可配置的。此步骤是必需的，以使得计划可被DBB操作组修改，以便考虑到唯一的或含糊的情况。例如，给定的工作流可指定特定的源组件。然而，在客户批准时，将使用一不同的较低质量的源文件。这些替换源文件存在于DBB中。请求被标记来供操作审阅，并且在此过程期间，计划内的源资产被修改。一旦修改完成，计划就被发布来供执行。

3.用户接口

为了支持在COFA批准之前对制造计划的审阅、修改和发布，一个或多个UI是必要的。为了在COFA批准之前或之后修改计费交易，UI也是必要的。关于对计费交易要求的完整描述，参见“附录13金融过程”。

4.服务

请求级数据可经由web服务提交。制造分析引擎随后可产生必要信息并响应请求。关于DBB与列出的计费系统选项之间的可能服务，参见“附录13金融过程”。

5.接口的系统

制造分析过程可要求查询到诸如Sony的GOLD和/或CineShare应用之类的支持系统中以便确定库存可用性。

6.多租户

为了维护一致的吞吐量，希望有级别加载和合作者之间的任务的优先级区分。

附录7任务管理

1.概述

DBB要求如工作流主控数据定义的那样协调工作流的能力。制造计划允许了组装、操作修改/审查、批准和提交工作流以供执行。一旦被提交，任务管理功能就与DBB的服务层交互，从而提交任务、获得响应、更新、记录日志和根据需要通知。

工作流及其各自的任务对将源组件摄取到DBB中进行管理。另外，DBB具有对物理库存的关键组件中的可见性，并且工作流管理将通信层扩展到手动母版制作或资产研究/检索活动。在此宽范围内，假定任何任务可被配置为向DBB提供商或厂商提供手动工作流指令。技术和成本利益分析确定任何过程被自动化的程度。关键要求是任务的状态及其对于从关键物理资产创建到交付确认的所有工作流的依从性在DBB内是可见的。

2.描述

当在DBB中发起订单时，生成制造计划(参见“附录6制造规划”)。在批准提交后，制造计划将向队列管理功能提交任务。工作流任务的处理及其构造在图18中所示的功能分组中描述。这些功能的技术构造可依据详细设计和实现问题而变。

工作流任务-如“附录6制造规划”中所述，制造计划包括为了履行批准的请求而必要的工作流。在任何时间，多个工作流可在进行中，其中的许多个要求相似的任务被同一DBB服务完成。为了管理队列、控制优先级和提供对状态的可见性，工作流任务必须在DBB内被具体化。工作流任务被工作流协调工具添加到适当的队列。在这些任务内维护关于状态、处理顺序、开始和结束时间以及定义该任务及其父工作流和请求的性质所需要的操作信息的数据。

优先级-请求级优先级可在请求模块中基于可配置的用户权力和/或合作者配置来指派。请求级优先级可在“附录6制造规划”中描述的制造计划修改阶段期间被改变。优先级可在标题/Alpha级被修改，从而允许用户向请求内的一个或多个行项目赋予与其他不同的优先级。工作流任务级优先级也可在下文所述的任务队列管理功能内被修改。任务依从性是基于约束的工作流内设置的。

工作流任务配置-工作流任务管理DBB内存在的各种服务的执行。虽然工作流任务可被区分优先级，但对任务的执行顺序的分析是在服务级执行的，以使得针对给定服务排队的所有任务都按优先级顺序被处理。任务配置支持监视阈值，这些监视阈值允许了任务管理功能对迟晚的任务或者从其开始时起就已超过了设置的期间的任务执行分析和报告。任务类别包括但不限于以下的：

a.手动任务管理-DBB任务UI允许了将手动任务传达给DBB合作者/厂商服务提供商。这个具备web能力的UI提供了关于为支持DBB工作流而要完成的任务的工作队列信息。例如，此门户提供了文件移动能力，其帮助了交付资产以进入到DBB中。此任务类型还帮助了非金融审阅和批准工作流。假定电子邮件通知将可被配置为支持这些过程。

b.编码/摄取工作流管理-要求支持资产进入到DBB中所必要的所有任务，包括如“附录10摄取/编码管理”中描述的组件请求创建、编码、日志记录和摄取。可通过上述的手动任务管理来协调这些任务中的若干个。

c.外部参考文件交付和相容组件检索-为了支持相容资产的外部创建，音频或视频参考文件可伴随要用于交付的URL一起被交付到厂商。这是建议的工作流助手，其将提供用于相容/同步的组件的创建的结构。

d.外部web服务集成-DBB支持出于许多目的而与外部系统的web服务集成。对于初始发布设想的主要目的是检索图像、章节照片、标题级元数据和来自CineShare、GOLD和GPMS对于R1以及在以后的发布中对于其他第三方系统的其他包裹要求。

e.文件管理-任务控制检索文件以及向和从DBB存储系统移动文件，并且支持基于策略和工作流要求从WIP存储中清除文件。

f.内容处理-与识别出的所有形式的内容处理设备交互。

g.打包-基于顾客规格生成包裹元数据以及创建包裹供交付。

h.交付-通过识别出的方法将包裹交付到客户。

金融更新-任何工作流可被配置为提供状态和/或其他需要的数据来帮助金融过程(参见“附录13金融过程”)。

请求状态-工作流必须向请求提供任务进展，如工作流业务规则中所配置的那样。

以下功能可被嵌入在工作流协调工具内，但被要求通过DBB管理任务的吞吐量。

队列管理-队列管理功能监视和维护DBB内的各种队列的吞吐量并且基于优先级和依从性来确定执行的顺序。此功能通过与DBB服务层交互来控制任务的速率/流动。

任务更新-DBB服务层为每个任务提供状态。在接收到状态后，任务更新功能将任务更新到适当的状态并且提供日志记录和通知功能。

任务监视器-此功能监视所有任务管理功能和队列，提供差错报告、处理时间解析并且总体支持队列处理完整性。

任务管理操作UI-作为DBB管理员，要求对手动和自动化的工作流及其任务的管理。管理任务的优先级和顺序是管理员使用来保持内容供应链高效运行的核心功能之一。

通知-电子邮件通知是在任务级可配置的。这些通知由规则基于操作需要驱动或由请求的需要驱动(请求者/客户通知)。

关键任务-如“附录4工作流主控数据”中所述，关键任务是可由操作人员直接执行的工作流。这些工作流要求UI允许输入参数的直接输入。UI要求直接识别源库存以用于关键任务内处理。关键任务的一些示例是文件检索、内容处理和交付，并且可包括任何内容处理活动。

3.用户接口

任务管理操作UI为操作人员提供了审阅和分析的精密方法。任务可被配置有容忍级别，这些容忍级别一旦被超过就触发警报并随后对于操作可审阅。为了迅速地识别和解决问题，按诸如任务类型、工作流、内容处理场、客户、合作者或请求之类的各种标准对任务的选择和审阅将是必要的。

关键任务UI依赖于工作流的模块性并且提供对输入参数的直接访问。这些程序可从相似的模板工作，因为库存搜索、识别和检索是大多数关键任务共同的。额外的工作流UI可被附加到此基本UI。

4.服务

工作流协调工具可用于与DBB的服务层交互，以提交任务、管理例外、记录日志、通知等等。此工具要求多种服务以便执行以上的任务类型。

5.接口的系统

参考体系结构对于R1描绘了所有规划的接口，但任务管理也可与CineShare相接口以便检索图像、章节照片和其他非丰富媒体以及接口到GPMS以获得标题级元数据。对于控制金融交易的过程，以及为了库存可见性，DBB与Sony的Xytech实现GOLD相接口。

6.多租户

优选工作流和任务管理UI和服务是单个实例和版本，虽然它们是集群的并且具有被分布的能力。这允许了DBB在设备集合专用于一个合作者或者在多个合作者间共享的情况下，针对分开的内容处理设备集合为多个合作者区分工作优先级。工作流规则允许了基于发起请求的合作者的不同行为。

附录8受管理多层级存储环境

1.概述

DBB要求管理和在数字存储上存储大量数据的能力。数字文件可以是视频、音频、图像、文本或任何其他可被打包以用于发行到DBB客户的媒体类型。给定存储的当前成本以及文件的预期量/大小，预期包括受管理多层级存储环境(MMSE)的存储系统是必要的。其必须提供中心存储点，这比完全在线的方案更经济，因为文件可被存储在不同层级/类型的存储上。

2.描述

由于DBB具有文件的数字仓库，所以将要求与文件管理相关的服务。一个这种服务是上载/摄取服务(参见“附录10摄取/编码管理”)。为了用文件填充DBB，需要上载过程来将文件从外部源移动到DBB存储的本地化实例。所有文件在初始摄取时都应当被移动到层级1存储，直到批准的服务请求已被生成来将文件移动到WIP存储或者策略将文件移动到MMSE内的其他层级时为止。

DBB要求的另一服务是半成品(Work-In-Progress，WIP)检索过程。为了支持内容处理服务，存在于MMSE上的文件将首先需要被拷贝到WIP存储区域，在该处它们将能够直接访问内容处理服务器(例如代码转换、打包)。此文件到DBB WIP存储的集结应当仅在工作订单已被完全批准并且内容服务制造计划任务已被添加到队列以供处理时才被执行。

DBB应当知晓文件的每个实例，无论其存在于存储的哪个层级上。DBB应当知晓为了减少不必要的磁带活动在其生产队列中要求什么文件(即，如果在订单#12上请求了特定的源文件并且在订单#215上请求了同一文件，则清除策略应当考虑到该第二订单)。

为了维护WIP存储内的容量，将需要设立保持和清除策略。这些清除策略将是WIP存储所特有的并且可基于包括以下在内的若干个关键因素：

a.定时的期满-一旦文件已被服务并且没有未决的已批准制造任务要求使用此文件，定时的清除事件就应当被激活。此定时的事件例如可以规定在文件30天都未被触及后，文件应当被清除。

b.工作订单状态类型-服务事件的完成可由几个不同的工作订单类型来识别并且可触发对保持策略的分析(即最有可能触发定时的期满)。“取消”工作订单类型指示出工作将不再继续并且因此文件不再是完成工作所需要的。第二，“完成”工作订单状态将指示出包括数字内容的交付和接收在内的所有活动都已完成。应当注意，其他工作订单类型可被识别为触发服务完成并且这些应当是可在应用内配置的。

c.未决的已批准服务任务-在任何时间点，要求使用存在于WIP存储上的现有文件的已批准制造/服务任务将重置定时期满计数器。此文件随后将保持在WIP存储上，而无需担心被清除，直到任务被区分优先级并且被对照执行为止。

d.文件元数据-保持策略可由关联到文件的元数据来驱动。在此示例中，预告片或其他媒体可具有比长形式视频更长的保持策略。其使用可以很多，但期满/保持策略应当能够利用文件元数据作为标准。应当注意，只有组件能够利用此特征，因为它们具有必要的元数据。

DBB使用MMSE方案来提供用于存储其数字内容的成本效率高的可伸缩方案。媒体和娱乐产业以大文件工作，取决于编码/比特率/运行时间，每个文件可能超过500千兆字节。由于此原因，成本和可伸缩性极为重要。DBB要求使用标准MMSE功能，包括在存储层级之间移动文件的能力(例如，近线->在线，离线->在线)，以及在MMSE方案内设立所安排的文件维护规则来帮助容量规划。DBB的存储层级是：层级1a-在线-快转盘；层级1b-在线-慢转盘；层级2-近线-带有可自动化检索的磁带库；层级3-离线-在磁带库外，带有手动检索。关于细节，参见图19。

规则在DBB内全局地管理内容。规则被设立为基于文件/组件类型安排文件在存储层级之间的移动。每个文件/组件类型被设立有针对存储的每个层级的期满期间以及盘利用率的高水位。预期经由用户接口扩展此功能以按合作者偏好来修改。

存储系统的层级1内的一个区域应当专用于半成品(WIP)存储并由DBB管理。此WIP存储被像代码转换这样的各种内容处理服务所使用。虽然用于这些服务的设备有时在处理数据之前首先将内容移动到本地存储，但希望的是通过消除在数据存储库之间移动这些大的若干千兆字节的文件的需要来改善处理时间。这要求层级1存储和内容处理服务器之间有非常快速的连接才能成功。

MMSE与基础设施管理服务相集成以提供关于MMSE健康状况的更主动的反馈。这些服务还与其他DBB硬件(例如内容处理服务器)相集成以帮助评估CPU、带宽和其他标准来帮助DBB更好地协调其服务并就潜在问题警告管理员。

MMSE方案允许了关于磁带上存储的内容的若干个规则：能够防止资产跨越多个磁带，除非绝对有必要存储资产(即，资产超过池中的整个空白磁带的大小)；能够隔离磁带上的内容类型(即，选择仅让某些类型的元素在磁带上被分组)，从而防止需要有额外的磁带填满磁带槽，而只是为了访问一个小元素；能够有磁带的多个拷贝以便DR在空闲时间和特定的维护窗口发生。

3.用户接口

取决于设计，可能几乎不需要最终用户接口。期望系统管理员将能够设置用于在DBB环境上管理媒体的默认规则。由于有仅管理员可用的控件，所以此功能不具有严格的用户接口方针并且我们预期大多使用开箱即用功能。然而，可能有某些特征经由接口被暴露给DBB合作者。例如，取决于合作者偏好，某些内容拥有者可要求所有内容保持在在线存储上，而不是被移动到近线或离线存储。此外，某些“热门标题”可被要求比标准标题更长时间段地保持在线。通过设置这些偏好，DBB应当能够与MMSE交互以传递使得这些决定成为可能的值/参数。

大多数文件管理活动应当对于DBB的最终用户是无缝的并且不要求用户接口。MMSE内层级之间文件的移动以及到WIP存储的移动应当以自动化方式进行。应当使用户知晓的唯一信息是文件准备(例如移动到集结环境)和文件服务(例如变换)所要求的预期处理时间。预期用户接口的一个情景是用于支持媒体的上载/摄取。还应当注意，对于上载/摄取、FTP、基于Web的上载和其他交付工具(例如Aspera、Signiant)，存在若干个机制。

4.服务

存在某些应当作为服务被暴露给DBB的MMSE特征。预期作为服务暴露的特征如下：

a.在存储层级之间移动文件

b.设置基于元数据的期满策略(覆盖默认规则)

所有文件管理活动都应当经由被暴露给DBB的服务来管理。为了应对这一节早先论述的文件管理要求，需要暴露以下服务：

a.文件上载服务-此服务应当将文件从合作者指定的位置移动到层级1存储以用于合作者特定租户分区。此服务的输入应当指定文件名是应当保持相同还是遵守文件命名变换表达式。

b.文件检索到WIP服务-此服务应当接收指定要移动的文件的文件指针和由此得到的文件目的地位置作为输入。目的地位置将是WIP存储的租户分区。

c.手动清除服务-此服务应当接收文件指针作为输入。在合作者手动发起清除其内容的请求的情况下，此服务应当在操作确认之后清除存在于MMSE上的所有匹配的内容。

d.保持服务-MMSE将需要利用保持策略管理其存储。无论这是MMSE功能还是暴露的服务，两个存储环境在触发内容的移动/清除之前都将需要评估多个标准。在本文档中早先描述的这些标准应当被输入到此服务中并且包括工作订单状态类型、文件元数据、未决已批准服务任务的存在以及定时期满。

5.接口的系统

MMSE应当经由服务被集成到DBB。这些服务被集成到DBB中以使能来自包括例如DBB DAM或管理DBB制造计划的系统在内的系统的调用。

取决于DBB的设计，支持大多数文件管理特征可能并不需要接口存在。虽然有对于作为保持标准的数据的大量依从性，但此数据应当都是在DBB内可用的，并且预期不要求外部接口。上载/摄取是仅有的会要求系统接口的特征，然而这些接口将经由数字交付工具(例如SmartJog、Signiant)来应对并且大多经由配置来设立。

6.多租户

MMSE和整个存储方案必须既支持合作者的专用基础设施，又支持共享模型，在该共享模型下DADC为来自共享存储池的多个租户服务。给定在DBB内管理的数字文件的敏感性质，多租户体系结构应当被设计并设立来应对内容服务所要求的所有潜在的文件移动。MMSE存储应当能够被虚拟且逻辑地分区以防止交叉污染并且文件管理活动应当始终知晓所使用的适当分区。

7.拥有和操作的总成本

MMSE是DBB的核心使能基础。MMSE提供了不减少DBB所瞄准的金融利益的拥有和操作的总成本。它也符合DADC所瞄准的第三方业务。

附录9搜索

1.概述

DBB在其整个基础设施中各处都要求搜索功能。需要在内部DBB数据(例如合作者、客户)上以及跨到外部数据仓库的接口进行搜索。然而，搜索的未来应用将需要容适其他接口，包括但不限于DAM系统和知识产权管理系统。满足这些要求的机制未被确定并且方案可以是各种各样的。

2.描述

关于DBB的搜索可被分解成两种类型：最终用户驱动的搜索和系统驱动的搜索。

最终用户驱动的搜索是在描述搜索特征时通常想到的东西。最终用户出于许多不同的原因在DBB上进行搜索。以下是预期的最终用户驱动搜索特征的列表：

a.标题/Alpha搜索-被合作者用来选择所请求的适当标题或标题/Alpha。这要求到合作者的标题/IP管理系统的接口并且要求多个输入标准，包括但不限于：

a.标题(全文通配符搜索)

b.标题类型(例如正片、剧集)-受控值列表

c.规格搜索-被DBB管理员用来找到适当的规格。规格包含大量的细节，其中规格之间的差异可能是最低限度的。迅速搜索和过滤规格以找到确切匹配的能力是非常重要的，这样适当的规格被使用。

d.组件搜索-被合作者用来研究存在于DBB中的组件。组件包含许多唯一地描述每个组件的元数据字段。组件搜索机制应当提供跨所有元数据字段搜索并且过滤结果以唯一地识别确切的组件匹配的能力。

e.支持素材搜索-被合作者用来搜索被添加到DBB的支持素材。这些支持素材与组件相比具有最低限度的元数据。元数据的级别取决于文档仓库如何管理此类媒体。在最低限度上，搜索应当包括任何可用的元数据，比如文件名或文件夹目录结构。

f.客户简档搜索-被合作者用来搜索供请求的适当简档。此功能可经由文本搜索或浏览搜索来实现，其中合作者可经由层次体系来巡览客户简档(例如客户>客户简档)。

g.客户搜索-被合作者用来选择供履行的客户。这应当是对客户名称的简单文本搜索或者浏览特征以滚动经过DBB内的可用客户。

h.请求搜索-被请求者用来找到在进行中或已提交的请求。

i.制造计划搜索-在制造计划正被定义/创建时以及提交之后被操作者或请求者使用，这将发生在工作流和任务级(尤其是按状态)。

系统驱动的搜索由DBB进行来执行其内置的特征。其最佳示例可通过查看DBB制造计划功能来说明。例如，为了生成请求，合作者指定标题/Alpha和客户简档供交付。给定此输入，DBB需要跨现有的组件(文件的和物理的)进行搜索，并且遵循许多业务规则。这些搜索需要可被系统管理员配置并且在制造计划估计时被执行。

以下是预期的DBB系统搜索的列表：

a.组件搜索-被DBB进行来在给定数个元数据标准的情况下找到最佳匹配组件的查询。DBB提供的作为搜索的输入的数据可以是从多个源中拉出的，但一般是由请求或相关信息驱动的。输入包括但不限于：

o标题ID-这是在请求过程期间由合作者选择的数据。

o Alpha-这是在请求过程期间由合作者选择的数据。

o合作者ID-这应当被用作过滤器以具体地搜索由特定合作者创建的组件。注意：在合作者之间不共享组件。

o额外的规格元数据-这是在关联到客户简档的规格中指定的数据。此信息将是已知的，因为请求将要求合作者选择客户简档。样本规格信息可包括技术元数据，比如比特率和格式。

3.用户接口

无论设计如何，某些搜索标准输入要求最终用户输入。搜索接口应当要求尽可能少的用户交互。取决于UI屏幕，若干个设计概念应当是可能的以使能有效的UI。对于所有搜索类型，“通配符”或部分匹配的使用应当是可用的(例如，“Spid”返回“Spiderman”的所有结果)。

a.基本搜索-最常见的搜索接口，其中一个文本框被用于提供文本输入，但跨数个预定字段搜索。

b.高级搜索-通过在执行前为数个元数据字段指定搜索参数以创建更限定的搜索标准(例如日期范围、多重选择)来跨(一个或多个)数据源搜索。

c.基于方面的搜索-提供能够以动态方式过滤结果集合的额外相关属性的搜索选项。应当在每个“方面”旁边指示检索到的结果的计数。

d.搜索细化-在返回的结果集合内搜索的能力。添加标准以便细化结果。

e.建议-模糊匹配或逻辑的能力。其特征是“您的意思是不是…？”型逻辑。理想情况下，基于索引的“预测未来”建议将是可用的。

f.结果巡览-按定义的分类/分组详细研究搜索结果集合的能力。

应当在能够被整体审阅或经由分页策略审阅的集合中返回搜索结果。此外，如果结果集合超过定义的阈值，则系统将提示用户细化其搜索标准。

此外，搜索服务的速度/响应度对于DBB的可使用性和效率是关键的。

4.服务

为了使能跨内部和外部系统的搜索，对于每个外部/内部数据源，搜索服务需要被创建并暴露给DBB。将这些搜索接口作为服务暴露的原因是因为这些接口将最有可能在整个DBB中各处在多种情景中为了不同的目的被使用。通过创建共同的服务，它们将更容易被利用。对于每个数据源，服务应当被暴露来查询每类数据。此外，可能要求创建跨越数据源和服务的索引以便提供必要的响应时间。

服务应当可扩展以提供针对特定数据类型的所有可用元数据的查询和数据检索(安全许可)。例如，如果创建服务来查询外部知识产权管理系统(例如Sony的GPMS)，则输入应当足够智能以提供多个标准用于输入(例如标题名称和标题类型)。服务还应当提供指定希望输出的元数据字段(例如标题、年)的手段。

5.接口的系统

预期查询若干个系统/子系统来使能数据共享。所识别的系统中的一些是以下的：

a.媒体资产管理-当为了制造计划估计而进行素材分析时，需要查询DBB内部媒体资产管理子系统及其构成服务。

b.GOLD/资产管理-DBB系统需要与外部现有资产管理系统GOLD相接口以便源在制造规划期间检索资产元数据。

c.工作订单-DBB系统需要存储与DBB所进行的工作有关的数据以便适当地指派任务并随后接口数据以帮助就完成的工作给合作者开据发票。为了使合作者的重复输入达到最低限度，DBB期望如有可能就经由系统集成来接收工作订单行项目/请求。

6.多租户

除了需要能够作为传递的值由合作者过滤搜索结果以外，对于搜索没有特定的多租户要求。

附录10摄取/编码管理

1.概述

DBB为组件的编码(或捕捉)和随后的摄取管理过程工作流。在此协调中，开始于制造计划中新组件创建的请求，直到其被接受到DBB中，元数据将经由手动和自动化过程被继承、捕捉和验证，以支持创建干净的数据并从而创建明确的库存。

编码也称为捕捉是通常从物理磁带但也可从文件创建母版文件的大部分手动的过程。重要的是这是一个受管理的过程，以使得可以知道关于特定的一个或一组编码的状态。此外，由于外部厂商随后将输入所要求的元数据并且传送文件以触发过程中的下一阶段“摄取”，所以受管理的工作流将允许其被跟踪以及协调。

本文档中定义的摄取过程开始于接收一个或一组经编码的组件，其可能在包装物内。希望除了罕见的例外流程以外，组件如果没有经由制造计划(反应性过程)或从文件母版制作请求(在主动创建过程中)创建的等待组件要求，则不能被摄取到DBB中。从接收到(一个或多个)文件的步骤起，接收到的(一个或多个)文件经过数个自动化和手动步骤以确证文件的完整性，执行质量检查，执行技术日志记录过程，然后正式将(一个或多个)文件摄取到DBB存储系统中并且在等待组件要求中为组件更新/创建必要的元数据。

2.描述

图20概略示出DBB应当协调的编码和摄取管理过程。

经由请求和受管理的工作流控制的基于规格的编码和摄取是DBB的关键概念，因为其涉及维护具有必要的元数据和关系的良构的库存以帮助自动化。组件类型规格可由母版制作/资产管理组定义的操作来创建和维护，作为用于请求创建并随后接收进入的资产的通用模板和控件。组件要求表示对照标题/Alpha对特定类型的(一个或多个)组件的请求并且创建了要对照组件要求接收的壳记录。这允许了实现确保库存元数据的统一性的规则。

组件要求是以两种主要方式经由请求创建的：

a.从允许组件被编码并随后被摄取以用于未决的订单中的制造计划反应性地创建，以及

b.基于使得创建组件以用于新的数字发布(正片和TV内容)的母版制作计划主动创建。

厂商在发起经由一应用接口将如母版规格中定义的(一个或多个)文件传送到DBB之前，执行限定量的内容QC，该应用接口被扩展到开始摄取的过程的厂商。在厂商处或在远程运行的服务也将提供一种方法，供厂商输入所要求的关于(一个或多个)组件的元数据以及允许在传送后为要确证的(一个或多个)计算校验和以确保(一个或多个)文件的移动不引入损坏或截短。

摄取过程开始于通常在编码完成之后开始接收(一个或多个)文件。摄取过程自动验证校验和，包括如果必要则展开内容(等待来自编码厂商的交付包裹规格的最终定义)。

在完成校验和确证之后，组件元数据和(一个或多个)文件被进行质量检查以确保所定义的资产特性在组件类型规格的容限内。从(一个或多个)文件中自动提取技术特性并且基于在自动化技术和内容QC中可实现的来确证元数据。来自任何自动化QC过程的结果的日志应当被保持并存储在系统中以供将来参考。

一旦验证了(一个或多个)组件的完整性，就基于系统中的组件要求记录上的元数据，对照来自厂商的应当伴随(一个或多个)文件的元数据，来对接收到的(一个或多个)文件执行与等待组件要求的匹配。这是被辅助的手动过程，由此关联在大多数情况下只要求确认，但也要求资产记录可被手动匹配到列表中的组件要求，如果多个选项被系统地识别的话(通常是作为不良的进入元数据的结果)，或者如果系统经由搜索没有识别选项的话。

下一过程是生成要用在接下来的步骤中的高保真帧精确代理。利用该代理，在最终摄取到DBB中之前，将有对该(一个或多个)文件(例如验证音轨和宽高比)及其元数据的一些额外手动审查。

下一步骤是对于组件的技术日志记录。目前这仅对视频组件(以及相关联的音频组件，如果它们在相同的摄取过程中的话)设想了，并且被设想为手动活动。技术日志记录功能涉及捕捉组件片段标识(即色带/音调、广告黑屏、徽标、程序)以及每个片段的时间码信息(入点和出点)并且根据需要修剪坐标。此外，优选此技术日志记录过程在帧精确代理上进行，而不是在实际实质文件上进行，因为文件大小(尤其是对于HD)将变得笨重难处理。此外，虽然这被规划为手动任务，但也希望建议对片段的一些索引编制和自动匹配/识别，这可将手动劳动减少到大多是技术日志记录数据的验证/调整。

指纹识别是随后对该(一个或多个)文件执行以为文件创建唯一签名的过程，该签名随后可用于唯一地识别标题/Alpha。这可以在文件实际在DBB的存储系统内之后实际发生或不实际发生，因为那将是更高效的，因为制造计划可被排队以等待此资产。

摄取过程中的最终步骤包括文件完整性确证，比较原始捕捉的检验和，然后将文件从摄取过程位置传送到DBB存储系统中以便管理。对组件要求数据和伴随(一个或多个)组件文件的进入元数据的最终确认将被执行并可被操作者确证。此外，在系统内，组件要求将被更新为已履行状态并且在整个系统中各处提供该可见性。

与相容的视频和音频组件被一起摄取时相比，在仅含音频或闭合字幕(CC)组件经过摄取受管理过程的情况下，此过程有一些变化。与之前一样，它们是请求的结果并且来自于受管理的编码过程。此流程中的主要差别在于为了确保这些组件将与视频资产相容，希望与其相关联，其将需要被对照音频的参考拷贝来加以确认。这可在服务器侧经由为音频和/或CC的相容性的验证而创建的特定代理发生。或者，这可在本地执行，但本地执行不那么优选，因为要求将参考视频从DBB移动到工作站。

一旦仅含音频或CC组件被摄取到存储系统中，还要求此类资产与单个或多个套件相关联。此过程被假定为是手动的，并且或者将作为使用组件要求的库存控制功能的一部分被提早进行，或者将在摄取之后在组件要求被履行时进行。

最终，将存在这些工作流的特定的“替换”变体，以允许用于已经在系统中但由于拒绝或母版重制作工作而正被替换的资产的必要业务和系统逻辑。

3.用户接口

用户接口(UI)需要对于编码和摄取操作者都是可访问的，编码和摄取操作者可以是不同的厂商，这些厂商可以包括或不包括内部。从而，要求该接口在丰富和交互性的同时，应当被安全地呈现给其外部用户并且还是直观的，因为可以假定外部厂商训练将是不同的。使用此UI的不同厂商不应具有对被其他厂商操作的文件的可见性。此外，将要求有如上所述的优选具有UI的服务，以辅助编码厂商进行初始组件传送前准备，例如元数据输入和校验和计算。

另外，为了满足如上所述的套件创建/更新要求，需要一UI来将仅含音频和CC资产的已履行组件和组件要求关联到套件。

4.服务

要求数个服务来支持编码和摄取工作流。最基本的，由于这些过程是受管理的工作流，所以工作流协调服务应当被利用来帮助此过程内的任务并捕捉过程度量。编码服务本身不被直接认为是DBB的一部分并且预期是被厂商利用来创建如母版文件定义中所定义的(一个或多个)组件文件的第三方工具。然而，将要求编码传送前服务/应用来允许厂商在将文件移动到摄取过程中之前创建校验和以确保文件完整性。

在摄取过程内，将需要有若干个服务，其中一些将被集中化，而其他的可能需要在本地运行。这些服务包括文件移动校验和、指纹识别、自动化技术和内容QC、内容处理(根据需要)、元数据确证以及技术日志记录。

在摄取过程结束时，文件管理、存储管理和元数据管理服务被调用来将在DBB的管理下的(一个或多个)文件及其相应的元数据放在其存储系统内。

套件关联功能将主要利用元数据管理服务。

5.接口的系统

对于此功能不要求直接接口的系统。然而，由于希望DBB中的库存被反映在GOLD中，所以关于进入的组件的元数据需要被同步/更新到该系统中。

此外，理想的是，此过程中使用的不直接作为DBB的一部分的组件/工具集被接口，以更紧密地集成整个系统和任何远程数据和交互。

6.多租户

没有特定的多租户要求，除了系统必须能够支持内容被从多个位置编码和摄取以及能够(经由元数据)识别内容属于哪个合作者以外。

附录11包裹元数据

1.概述

本文档描述了将交付所要求的各种类型的元数据组装为包裹的一部分所要求的过程和功能。

2.描述

图21是示出客户简档、其相关联的元数据规格和根据该规格组装包裹元数据所要求的支持数据之间的关系的样本实体关系图。此图的目的不是想要定义最终设计，而是想要帮助描述预期满足SPE未来状态过程映射图的关系的类型。

客户简档-客户简档充当整个DBB制造过程中各处的整合的源，以确保所创建的匹配客户要求。

元数据规格-定义特定客户简档的元数据要求。元数据规格指示出要求什么元数据，每个数据元素位于何处，其如何被映射到DBB元数据规范，以及以客户优选的格式提供元数据要求什么变换(如果有任何变换的话)。

支持数据-支持数据构成要求作为包裹的一部分交付的所有数据。此数据可在各处DBB数据存储库中找到，即请求、标题/主控和文件仓库，并且必须被映射到元数据规格。在要求DBB外的额外数据的情况下，其将作为支持素材经由(面向用户的或系统到系统的)接口被提供给每个请求。

标题主控数据-标题是主控数据，描述在DBB内作为其内容的最高组织级别维护的知识产权，允许其被搜索、检索和对照制造以便履行请求。示例包括标题、纲要、才能、体裁、分级和版权行。

请求数据-请求数据包含依用于生成请求的交易条款而定的信息。示例包括销售开始日期、销售结束日期和价格。

技术数据-定义依包裹中包括的资产和/或文件而定的元数据并且包含诸如资产类型、文件名、文件大小和校验和之类的元素。

包裹声明-定义包裹的内容。这可包括为每个标题提供的所有资产的列表。

其他数据-各种客户可以有我们没有论述的额外元数据要求，例如章节元数据。因此，元数据规格需要是完全灵活的，以允许添加或删除数据来支持客户需要。

元数据规范

DBB要求元数据规范，其去除可变性并且施行严格的词库，以确保在字段和值的级别都使用共同的元数据语言。合作者元数据规格被对照此规范进行映射以提供一致的参考点，该参考点最终将帮助映射到个体客户元数据规格。元数据规范必须支持多种语言和其他地区特定数据格式(例如日期、汇率等等)。

元数据映射

合作者元数据规格的每个源DBB元数据属性及其相关联的值必须被映射到元数据规范。类似地，每个客户元数据规格应当被映射到DBB元数据规范。这提供了效率，即只需要映射客户一次，而不是对于向其发行内容的每个合作者都映射一次。它还添加了一层抽象，以保护映射免受随时间流逝而发生的数据模型变化的影响。

元数据变换

每个客户可具有围绕如何提供特定数据元素的特定要求。这可以简单到特定的日期格式，或者复杂到比如具体的转化规则。例如，客户可以有其自己体裁来给内容分类。在此情况下，将必须从DBB体裁转化体裁值。这些变换规则必须易于管理并且如果可能的话应当不受技术发展限制地实现。

元数据版本控制

必须审核对元数据的改变并且必须维护历史数据。重要的是要知道什么元数据作为包裹的一部分被发送到客户。然而，客户可由于“不良”元数据而拒绝包裹。必须确切了解发送了什么以确保不会重发送相同的“不良”元数据。相反，可能要求重发送的与原本发送的完全相同，即使数据随后可能被改变了。由于包裹不是被无限期地维护的，所以重建曾发送的元数据应当是找出原本发送到客户的所有元数据的功能。一些客户取决于其客户简档可要求发送最新近的元数据。

3.用户接口

必须存在用户接口来管理DBB内的合作者特定元数据元素到元数据规范的映射。类似地，必须存在方法来将客户特定包裹元数据元素映射到规范。此外，必须有允许添加或编辑仅存在于DBB内的元数据的用户接口。

4.接口的系统

DBB将为将被包括在包裹元数据中的数据的类型维护其自己的数据存储库。然而，DBB可能需要与额外的系统相接口以提供包裹元数据(例如GPMS)。

5.多租户要求

未来的合作者可以有将影响元数据规范、元数据映射和元数据变换的特定包裹元数据要求。

附录12包裹创建/管理

1.概述

本文档描述创建和维护包裹所要求的过程和功能。包裹表示根据客户规格创建的一个或多个产品以及按照合作者与客户之间的协议而要求的任何额外素材的汇编。

2.描述

图22是示出预期包裹如何与客户简档和规格相关的样本实体关系图。蓝色的实体在其他白皮书中定义，而青色的那些则将在本文档中介绍。此图的目的不是想要定义最终设计，而是想要帮助描述预期满足SPE未来状态过程映射图的关系的类型。

客户简档-定义一组依客户而定的可交付物要求，并且支持自动化工作流，用于交付、状态跟踪、计费和产品/包裹创建。包括配置、规格(每标题类型)以及简档级元数据。

包裹-定义最终将作为请求履行的一部分被交付的一个或多个产品加上按照合作者与客户之间的协议而要求的任何额外素材或内容的汇编。

包裹规格-定义包裹要被认为完整而要求的内容或包裹元素。包裹规格将基于两个主要标准而变化：所交付的产品的类型，以及其将被交付到的客户。例如，正片的包裹规格可不同于电视剧集的包裹规格。类似的，用于iTunes的正片包裹规格可不同于用于广播客户的。

包裹元素-定义被要求是客户包裹的一部分的离散的一段内容。每个包裹元素将基于其内容类型或元素类型而具有其自己的规格。例如，元数据包裹元素将具有元数据规格，Packshot将具有图像规格。

元素类型-定义元素的类型，即预告片、章节照片、Packshot、元数据、音乐视频等等。

包裹创建过程可被逻辑地划分成三个子过程，如下：内容收集；包裹组装；以及包裹维护。内容收集表示负责识别和/或本地化一请求内所有要求的包裹元素的活动。包裹组装确保已收集了所有要求的包裹元素，执行使包裹元素符合客户规格所要求的任何处理(即代码转换、水印添加、XML变换、DRM等等)并且根据包裹规格来组织包裹元素。包裹维护表示在包裹被创建之后控制包裹的过程。

内容收集表示负责识别和/或本地化一请求内对于产品的所有要求的包裹元素的活动。包裹规格被设想为告知内容收集过程需要收集什么的机制。包裹规格需要包含以下信息：

a.需要包括哪些包裹元素，即预告片、图像、元数据等等。

b.每种包裹元素要求多少个，即2个预告片、4个图像、1个元数据。

c.在何处可找到每个包裹元素以及使用什么标准来找到它(文件系统位置、DAM搜索标准、web服务调用，等等)。

d.每个包裹元素的客户命名规约。

e.包裹元素的组织方案(即，松散文件、按产品压缩、特定目录结构等等)。

内容收集开始于确定包裹元素对于给定的请求是否可用。DBB应当在请求UI内披露每个包裹元素的状态，以使得(一个或多个)适当的用户能够明了为了履行请求还需要收集什么。

DBB实际期望在何处收集包裹元素将是一个设计决定。一个选项可以是基于请求的WIP区域，其中集结了一请求所要求的所有内容。另一个选项将是将所有要求的内容存储在DAM中。这将要求一标准元数据规范来使得DBB能够基于诸如请求标题、请求地域和包裹模板内容类型之类的请求和包裹模板属性的组合(即，标题＝Quantum of Solace，地域＝US，并且内容类型＝Packshot)来定位内容。该过程应当尽可能自动化，其中内容移动的次数达到最低限度。因此，DAM方案具有固有的优点，即内容可被摄取一次并重用于多个请求，而手动填充的WIP区域将需要对于每个处理的请求被重填充。

如上所述，在DBB内在一些情况下也需要自动生成文件命名规约以便满足客户交付要求。这些文件命名规约在发行客户之间是不同的，并且一般由描述资产的一系列缩写且串接的元数据值组成。命名规约应当是依特定客户而定的，但也可根据合作者需要配置。为了定义文件命名规约，DBB用户应当能够选择一系列元数据字段(例如标题、宽高比)、固定字符串(例如“_”“-”)或其他定义的变量(例如当前日期、当前时间)。可基于DBB用户指定的数个不同标准来修改从元数据输入得到的文本。这些标准中的每一个可被单独使用或被串行组合(例如去除元音，然后修剪到10个字符的最大长度)。

以下标准也可被应用到特定元数据输入或整个表达式：

a.修剪到长度-(例如将标题字段修剪到10个字符。“Transformers”将是“Transforme”)

b.去除元音-(例如从标题字段中去除元音。“Transformers”将变成“Trnsfrmrs”)

c.小写/大写-(例如标题字段大写。“Transformers”将变成“TRANSFORMERS”)

d.去除特殊字段-(例如从标题中去除冒号。“Stargate：Infinity”将变成“Stargate Infinity”)

给定此数据操纵所要求的灵活性，利用正则表达式(例如RegEx)处理器可最好地应对复杂的操纵。

当已识别和/或集结了所有要求的包裹元素时，内容收集完成。然而，必须维护一些级别的操作控制，以使得即使当某些包裹元素不可用时也能够创建包裹并因此能够履行请求。这意味着经授权的操作者要求有即使在内容收集过程尚未完成的情况下也能够开始包裹组装过程的能力。这些要求中的一些可通过指示出哪些包裹元素确实要求交付的业务规则来履行。在最高级别，操作者必须能够“照原样”发送，而无论包裹规格规定了什么。

一旦已收集了包裹元素，就可开始包裹组装。其目的是准备和组织如包裹规格中所描述的内容。每个包裹元素将具有其自己的规格。例如，预告片可能需要以特定的格式、宽高比和比特率来交付；元数据可能需要被变换成客户特定格式。预期DBB利用适当的规格以便知道需要应用什么变换。在组装包裹时，DBB将基于包裹规格和包裹元素规格执行以下的一些组合：

a.确定是否要求加密以及在什么级别上(包裹或包裹元素)要求加密并且在必要时应用。

b.变换图像、支持视频元素(即预告片，音乐视频等等)和元数据

c.应用鉴证水印添加，如果要求的话。

d.向产品应用DRM，如果要求的话。

e.向包裹元素应用客户特定命名规约，如果要求的话。

f.将包裹元素组织成目录结构。

g.组合或包装包裹元素，即Zip、stuffit、MXF。当所有要求的包裹元素都被处理成符合其适当的规格时，包裹组装完成。然而，必须维护一些级别的操作控制以使得即使当没有收集和/或组装某些包裹元素时也能够创建包裹并因此能够履行请求。

包裹维护由在包裹组装后进行管理所要求的以下过程构成：

a.针对QC的包裹集结-要求将包裹移动到QC位置并且通知适当当事人包裹准备好进行QC

b.针对交付的包裹集结-将经组装的并且在必要时经质量检查的包裹移动到交付集结位置

c.包裹保持-对于包裹实行清除/保持策略。这些策略可以是依客户或合作者而定的。

d.包裹管理-使得管理员能够手动访问或清除包裹。

3.用户接口

必须存在用户接口来管理包裹规格的所有方面，从元素类型创建到组装包裹规格。包裹规格的创建、审阅和发表被设想成是整个装载过程的一部分。

另外，请求和/或管理/合作者门户应当在特定请求内披露每个包裹元素的状态，以使得经授权的用户能够明了为了允许请求履行继续进行还需要收集什么。

最后，包裹创建有可能向负责提供包裹元素和执行包裹QC的当事人发送通知。

4.接口的系统

DBB需要与容纳包裹所要求的包裹元素的DAM或文件系统相接口。

5.多租户

DBB需要与合作者DAM系统相接口以便收集必要的包裹元素。然而，另一选项将是提供合作者门户，其允许将包裹元素直接摄取到DBB中。

附录13金融过程

1.概述

DBB要求与Sony的和合作者的金融系统交互以便提供成本估计、帮助金融批准、执行计费或成本转移过程以及在必要时帮助金融交易的整合。

金融过程的DBB模型必须支持与SPE、公司间模型以及合作者模型、更传统的顾客/厂商模型的业务关系。“附录3请求管理”中论述的自助服务概念如下文将描述的可应用到公司间和第三方模型两者。然而，包括对于合作者可向其提供传统PO的DBB顾客服务层的要求也被认为是必要的。此顾客服务层随后将通过自助服务模型中描述的请求模块与DBB交互。

所有DBB金融模型都将允许接口到SPE或合作者金融系统以便利用这些系统的核心功能并且一旦可能则消除来自DBB规范的核心金融要求。希望将DBB作为内容管理和发行平台从GAAP或SOX约束的金融系统的要求分离。

在以下的系统体系结构选项中概述了涉及GOLD、Xytech MediaPulse和DADC的COM系统的特定体系结构选项。这包括描绘DBB的接口和实现方面。

2.描述

金融集成概念

以下部分记载了DBB金融流程的功能组件。对于这些组件中的一些有多个选项可用。这些选项在本部分结尾处论述。

费率卡-如“附录6制造规划”中论述和“附录5工作流主控数据”和“附录7任务管理”中详细阐述的，假定DBB或者将拥有在其体系结构内支持费率卡的能力，或者将与支持费率卡的系统相接口。此费率卡必须允许内容处理商务常见的各种定价情景。这些情景必须包括但不限于以下的：

a.合作者的费率卡-费率卡必须可被配置来提供由合作者进行的唯一定价，无论该合作者是SPE还是第三方。费率卡必须支持对合作者定价的拷贝和修改以及按整体百分比或按个体价格变化的费率变化的应用。要求对大量服务价格的分组和修改。

b.项目定价-当协商了特定的待遇时，此定价推翻合作者的费率卡。

c.定价类型-必须支持以下定价类型。

数量定价-包括对于较大的数量应用折扣。

固定费用定价-包括在计算价格时不考虑数量或单位的服务。

最小数量定价-收取固定费用直到达到最小数量为止，然后使用数量或标准单位定价。

d.定价变量-在费率卡映射中必须使用以下变量。

数量-所创建项的数目，例如五个Mpeg2文件。

单位-可被乘以或不乘以数量的单位数目，例如10次交付，每次5个Mpeg2文件。也用于任何基于通用单位的服务。

运行时间-内容的运行时间。

源和输出类型-源文件的类型，例如HD源和SD源，输出代码转换格式。

订单类型-订单所要求的服务级别和交易类型，例如急迫订单、不可计费的。

服务类型-对于请求执行的(一个或多个)服务的类型，例如代码转换、3:2下拉等等……

比特率-内容的比特率。

文件大小-所处理的内容的文件大小。

计费交易-通过DBB任务和费率卡之间的映射，DBB将生成计费交易。这些交易可由制造计划以自动化方式生成，或者通过如“附录6制造规划”和“附录5工作流主控数据”中所述修改制造计划来生成。然而，计费交易将包含制造计划的成本估计组件并且将支持发票开据或成本转移过程。

制造计划PO接口-在Sony模型内，制造计划一旦被DBB中的请求者批准，就将生成所要求的金融数据所支持的计费交易。其随后将把此信息导出到WPF履行系统GOLD。此接口将致使在GOLD中创建媒体购买订单。要求诸如SPE标题/Alpha ID之类的支持信息，其他金融信息可被包括在请求模块设计(例如地域、市场)中并且也将在该接口中提供。为了支持合作者要求，此接口将支持可针对多个合作者来配置和重部署的标准化架构和web服务功能。制造指令和源资产可被包括在接口中，仅用于信息目的。由DBB创建的GOLD PO(或合作者PO)仅打算作为计费媒介，而不打算作为执行工作的指令。报告发行过程的细节将是DBB的要求，而不是合作者PO系统的要求。两个系统中都将要求参考细节。

一旦创建了制造计划并且发送了接口消息，该计划就将保持挂起，直到通过接口得到批准为止。对制造计划成本的COFA批准将在GOLD(或合作者PO系统)中执行。一旦得到批准，一消息就将被发送回DBB，以发布制造计划。

R1要求包括到GOLD的接口以及到第三方PO系统的可扩展性。第三方PO接口的设计和构建不在R1的范围中。

制造执行和成本转移接口-一旦通过接口接收到COFA批准，就将执行制造计划。在执行期间可遇到的对于制造计划的实质性改变可导致所接口的PO的随后的迭代。可发送并批准修订以便支持计费过程。当工作已完成时，DBB将向执行成本转移功能的GOLD发送消息。此功能将反映出GOLD系统中的用以创建、批准和张贴发票记录以便导出到SAP的当前手动过程。由于交易的公司间性质以及接口对于DBB计费交易等于GOLD PO交易的确保，此过程可以是完全自动化的。此过程的自动化在R1的范围内，但假定了将利用当前GOLD到SAP的接口，而不要求到SAP的新接口。

DADC账户应收款项-无论对于合作者模型选择的选项如何，出于账户应收款项和总分类帐的目的，都假定DBB内的计费交易将被接口到DADC金融系统COM。在SPE模型中，这些A/R交易将被用于支持SPE与DADC之间的成本转移的对账。在合作者模型中，COM将提供标准发票开据和账户应收款项功能。

金融模型变量

可存在于SPE模型与合作者模型之间的变量包括但不限于以下的：

制造计划PO接口-制造估计到合作者的接口是此模型的一个选项但不是要求。如以上简要描述的，合作者可以直接使用或不直接使用请求模块。如果它们不直接使用，则它们将应对DADC顾客服务代表，这些代表将代表合作者直接与DBB请求模块交互。在此情况下，可要求在执行工作前对于传统的合作者PO的需要。这将是更传统的顾客/厂商交互。虽然此过程不直接影响R1要求，但必须考虑该使用案例。

计费/成本转移-对于合作者，如果没有不在R1的范围中的聚焦集成项目，则以上的SPE模型中所述的制造执行和成本转移接口将是不可能的。假定传统的发票处理将由DADC从COM系统进行。费率卡、计费交易与COM A/R之间的所有内部交互可保持像所描述的那样。

系统体系结构选项

费率卡和计费交易-当前的选项包括集成将在DADC基础设施内保持独立的Xytech MediaPulse实现。在此选项中，Xytech产品中的丰富费率卡和计费功能将被利用来处理金融交易并且如上所述与SPE侧的GOLD和DADC侧的COM相接口。

第二选项是也可在COM系统内维护费率卡和计费交易。这将要求COM支持所有定价相关概念并且如上所述与GOLD相接口。

在COM中支持费率卡和在MediaPulse中支持计费交易的选项看起来是不实际的。如果单纯用于金融目的，则这些系统将被认为是支持系统并且DBB项目要求将基于支持金融模型所需要的接口。集成到这些系统将在R1的范围中。这具体地排除了将MediaPulse实例仅实现为计费系统。

第三选项是Xytech MediaPulse将被用在诸如请求模块、制造规划、任务管理和库存管理之类的核心DBB内容处理功能中。如果MediaPulse被提供作为这些领域中的解决方案，那么费率卡和计费交易功能将在范围内，因为它们被紧密集成在MediaPulse体系结构内。

3.用户接口

要求在过程流中的任何点修改计费交易的能力。在“附录6制造规划”中关于对计划的修改的部分也涵盖了此接口。为了清楚具体陈述了操作人必须能够在制造计划的定案之前或者在制造计划PO接口的任何迭代之前或者对于合作者在开据发票之前审阅和修改计费交易。

4.服务

取决于最终设计，具体关于Xytech MediaPulse的任何使用，DBB将要求针对计费交易数据的接口的服务。此服务必须访问费率卡信息，向估计的任务应用映射，并且创建由此得到的计费交易。此服务必须可在DBB内执行，如果必要则单纯出于估计目的，而不仅支持发行。

5.接口的系统

取决于对系统体系结构选项的决定，将要求DBB到GOLD系统的接口来支持上述的COFA批准和成本转移活动。MediaPulse是否出于操作目的而被包括作为DBB的一部分影响着到DADC COM系统的接口的性质。此接口可包括费率卡、计费交易、COFA批准和成本转移的整个范围，或者可以只是要求从MediaPulse接口计费交易。

6.多租户

在本节各处解决了合作者涉及金融流程中的变化的问题。在收集或处理金融数据的所有领域中，拥有的合作者将被定义，并且此合作者指定将允许应用这里描述的可变处理。

Claims (26)

1.一种利用发行骨干系统来数字地发行媒体内容的方法，该方法包括：

接收来自客户的对媒体内容的请求，该请求包括客户简档；

通过迭代地遍历所述客户简档来执行源资产的盘存和分析以创建输出；

执行能力映射，其中一系列规则允许所述源资产被映射到所述客户简档；以及

规划制造过程，其根据响应于来自所述客户的所述对媒体内容的请求而映射的能力来确定工作项目和执行步骤。

2.如权利要求1所述的方法，其中，所述客户简档为所述客户定义了针对所述媒体内容或元数据要求的特定规格集合。

3.如权利要求2所述的方法，其中，所述特定规格集合定义支持自动化工作流所需要的关键变量和要求。

4.如权利要求1所述的方法，其中，所述客户简档定义了所述客户对于所述媒体内容的交付的要求。

5.如权利要求1所述的方法，其中，对于每个客户设立一个或多个客户简档以表示以下各项中的至少一个：该客户的多个业务模型以及按地域变化的要求。

6.如权利要求1所述的方法，还包括：

执行对在所述制造过程中确定的工作项目和执行步骤的优化。

7.如权利要求1所述的方法，还包括：

通过负责许可媒体内容的操作到负责将该媒体内容履行给被许可者的操作来生成所述请求。

8.如权利要求1所述的方法，还包括：

执行分析以识别关于所述媒体内容的标识、要服务的客户以及包括到期日在内的服务条款的关键信息。

8.如权利要求1所述的方法，还包括：

执行包括内容处理技术的自动化管理在内的采购相关活动。

9.如权利要求8所述的方法，其中，所述内容处理技术的自动化管理包括由标准化数据接口控制的文件管理、代码转换、打包和交付。

10.一种发行骨干系统，包括：

制造分析引擎，其接收来自客户的对媒体内容的请求，该请求包括客户简档，

其中所述制造分析进行操作以通过迭代地遍历所述客户简档执行源资产的盘存和分析来生成分析输出；以及

制造规划引擎，其被配置为利用所述分析输出来确定工作项目和执行步骤。

11.如权利要求10所述的发行骨干系统，其中，所述制造规划引擎包括执行或使用组件资产源、工作流过程以及成本和交货时间分析的模块。

12.如权利要求10所述的发行骨干系统，其中，所述客户简档包括：

包裹规格，其定义了必须被交付到所述客户以履行所述对媒体内容的请求的离散项目；

制造偏好，其是引导对所述源资产的选择并且限制制造能力的客户特定要求；

技术规格，其是定义编解码器、帧率、图片分辨率和其他基于文件的技术参数的非基于内容的要求；以及

组装规格，其定义了非线性编辑要求。

13.如权利要求12所述的发行骨干系统，其中，所述非线性编辑要求包括徽标替换、拉出黑屏或添加卡片。

14.如权利要求12所述的发行骨干系统，其中，所述包裹规格包括内容规格和元数据规格。

15.如权利要求14所述的发行骨干系统，其中，所述内容规格包括可重用的技术规格、组装规格和偏好数据。

16.如权利要求10所述的发行骨干系统，其中，所述分析输出包括组件要求，该组件要求是管理摄取所需要的任务管理工具。

17.如权利要求10所述的发行骨干系统，其中，所述制造分析引擎包括接收客户可交付物规格、支持库存数据和工作流主控数据的模块。

18.如权利要求17所述的发行骨干系统，其中，所述制造分析引擎利用所述客户可交付物规格来识别适当的工作流。

19.如权利要求17所述的发行骨干系统，还包括：

套件，该套件包括被分组的组件，并且以使得这些组件能够一起工作被相容和同步，

其中，被确定为一起工作的组件被组织成允许所述工作流主控数据指向所述套件。

20.如权利要求19所述的发行骨干系统，其中，所述套件包括一个视频组件和一个或多个音频组件。

21.一种存储用于数字地发行媒体内容的计算机程序的计算机可读存储介质，所述计算机程序包括使得计算机执行以下操作的可执行指令：

接收来自客户的对媒体内容的请求，该请求包括客户简档；

通过迭代地遍历所述客户简档来执行源资产的盘存和分析以创建输出；

执行能力映射，其中一系列规则允许所述源资产被映射到所述客户简档；以及

规划制造过程，其根据响应于来自所述客户的所述对媒体内容的请求而映射的能力来确定工作项目和执行步骤。

22.如权利要求21所述的计算机可读存储介质，还包括使得计算机执行以下操作的可执行指令：

执行对在所述制造过程中确定的工作项目和执行步骤的优化。

23.如权利要求21所述的计算机可读存储介质，还包括使得计算机执行以下操作的可执行指令：

通过负责许可媒体内容的操作到负责将该媒体内容履行给被许可者的操作来生成所述请求。

24.如权利要求21所述的计算机可读存储介质，还包括使得计算机执行以下操作的可执行指令：

执行分析以识别关于所述媒体内容的标识、要服务的客户以及包括到期日在内的服务条款的关键信息。

25.如权利要求21所述的计算机可读存储介质，还包括使得计算机执行以下操作的可执行指令：

执行包括内容处理技术的自动化管理在内的采购相关活动。

26.如权利要求21所述的计算机可读存储介质，其中，使得计算机执行内容处理技术的自动化管理的可执行指令包括使得计算机执行以下操作的可执行指令：

执行由标准化数据接口控制的文件管理、代码转换、打包和交付。

Images