МАГИСТРАЛЬ РАСПРЕДЕЛЕНИЯ Российский патент 2013 года по МПК G06F17/00 G06Q50/00 

Область техники, к которой относится изобретение

Настоящее изобретение относится к цифровым мультимедийным данным, а более конкретно - к цифровому распределению мультимедийных данных.

Уровень техники

С развитием производства и распределения мультимедийных данных, быстро продвигающихся в сторону полностью цифровых, было бы целесообразно предусмотреть автоматизацию рабочих процессов и совместимость различных цифровых форматов/устройств, которые требуют интеграции как программных, так и аппаратных средств. Однако существует несколько препятствий на пути автоматизаци технологического процесса и совместимости различных цифровых форматов/устройств в области производства мультимедийных данных. Например, в настоящее время отсутствует комплексная система технологического процесса, отсутствуют стандарты, существуют разрозненные решения относительно программных и аппаратных средств, а также наблюдается общее отсутствие механизма замены ручного труда, характерного для технологического процесса.

Раскрытие изобретения

В вариантах осуществления настоящего изобретения предложено цифровое распределение медиа-контента с использованием системы магистрали распределения.

В одном варианте осуществления раскрыт способ цифрового распределения медиа-контента с использованием системы магистрали распределения. Способ включает в себя этапы, на которых: принимают запрос на медиа-контент от клиента, причем запрос включает в себя профиль клиента; выполняют инвентаризацию и анализ активов источника с помощью итерационного прохождения через профиль клиента для создания выходных данных; выполняют отображение возможностей, при котором ряд правил позволяет отображать активы источника на профиль клиента; и планируют производственный процесс, который определяет элементы работы и этапы выполнения на основе возможностей, отображенных в ответ на запрос медиа-контента от клиента.

В другом варианте осуществления раскрыта система магистрали распределения. Система включает в себя: механизм анализа производства для приема запроса медиа-контента от клиента, включающего в себя профиль клиента, при этом анализ производства предназначен для выполнения инвентаризации и анализа активов источника с помощью итерационного прохождения через профиль клиента для выработки выходных данных анализа; и механизм планирования производства, выполненный с возможностью определения элементов работы и этапов выполнения с использованием выходных данных анализа.

В еще одном варианте осуществления, раскрыт машиночитаемый носитель информации, хранящий компьютерную программу для цифрового распределения медиа-контента. Компьютерная программа включает в себя исполняемые команды, которые заставляют компьютер; получать запрос медиа-контента от клиента, причем запрос включает в себя профиль клиента; выполнять инвентаризацию и анализ активов источника с помощью итерационного прохождения через профиль клиента для создания выходных данных; выполнять отображение возможностей, при котором ряд правил позволяет отображать активы источника на профиль клиента; и планировать производственный процесс, который определяет элементы работы и этапы выполнения на основе возможностей, отображаемых в ответ на запрос медиа-контента от клиента.

Другие особенности и преимущества настоящего изобретения станут более очевидны специалистам в этой области техники после рассмотрения следующего подробного описания и сопроводительных чертежей.

Краткое описание чертежей

Фиг.1 - схема последовательности операций, иллюстрирующая процесс цифрового распределения медиа-контента с использованием системы магистрали распределения, согласно одному варианту осуществления настоящего изобретения.

Фиг.2 - блок-схема системы магистрали распределения, согласно одному варианту осуществления настоящего изобретения.

Фиг.3 - алгоритм, иллюстрирующий технологию цифрового распределения медиа-контента с использованием системы магистрали распределения, согласно одному варианту осуществления настоящего изобретения.

Фиг.4 - подробная схема требований доставки и профилей клиентов, которые содействуют планированию производства.

Фиг.5 - случай образцового примера использования профиля клиента.

Фиг.6 - многочисленные наборы предпочтений источника и технических характеристик, которые изображают диапазон результатов, которые может принять клиент.

Фиг.7 - один из примеров состояния инвентаризации.

Фиг.8 - случай образцового использования, где данные извлекают из активов источника при их обнаружении.

Фиг.9 - данные, собранные из активов, идентифицированных в запросе анализа материалов.

Фиг.10 - случай конкретного использования отображения возможностей.

Фиг.11 - случай конкретного использования планирования производства.

Фиг.12А иллюстрирует представление компьютерной системы и пользователя.

Фиг.12В - функциональная блок-схема, иллюстрирующая компьютерную систему, выполняющую хостинг процесса для магистрали распределения.

Фиг.13 - образцовая схема взаимосвязи объектов, изображающая, как Партнеры и Клиенты предположительно связаны с Профилями клиента, Спецификациями и Конфигурациями.

Фиг.14 отображает первичные вводы в модуле Обслуживания Запроса.

Фиг.15 отображает образцовую иерархию, которая существует между названием, которое имеет два Альфа (Режиссерская версия и Театральная версия), и семейством компонентов, которые будут идентифицированы для обслуживания Режиссерской Версии Альфа.

Фиг.16 - список значений Формата изображения, который будет ограничивать актив, если он будет рассматриваться для этого Типа компонента.

Фиг.17 - описывает роль Мастер-данных технологического процесса с помощью DBB. Заштрихованные блоки представляют собой выборы, определенные Запрашивающей стороной.

Фиг.18 показывает обработку задач технологического процесса и их состав, описанный в функциональных группированиях.

Фиг.19 показывает, как использовать функциональные возможности Управляемой многоуровневой среды для хранения данных (MMSE), включающей в себя возможность перемещения файлов между уровнями хранения.

Фиг.20 изображает процесс Кодирования и Управления Загрузкой контента, который должен быть оркестрован с помощью DBB.

Фиг.21 - образцовая схема взаимосвязи объектов, изображающая взаимосвязи между профилем клиента, связанной с ним спецификацией метаданных и вспомогательными данными, которые требуются для сборки пакетных метаданных в соответствии с этой спецификацией.

Фиг.22 - образцовая схема взаимосвязи объектов, изображающая, как Пакеты предположительно связаны с Профилями клиентов и Спецификациями.

Осуществление изобретения

Варианты осуществления, которые раскрыты здесь, описывают системы, способы и устройство для цифрового распределения контента, которые обеспечивают автоматизацию технологического процесса, который выполняет загрузку контента в цифровом формате и управляет им бесшовно путем доставки клиенту. После прочтения этого описания станет ясно, как реализовать изобретение в различных альтернативных вариантах осуществления и альтернативных приложениях. Однако, несмотря на различные варианты осуществления настоящего изобретения, которые будут описаны в настоящем изобретении, следует понимать, что эти варианты осуществления представлены только в качестве примера, а не ограничения. Как таковое, это подробное описание различных альтернативных вариантов осуществления не должно быть истолковано для ограничения объема или охвата настоящего изобретения.

На фиг.1 изображена схема 100 последовательности операций, иллюстрирующая процесс цифрового распределения медиа-контента с использованием системы магистрали распределения, согласно одному варианту осуществления настоящего изобретения. Примеры медиа-контента включают в себя фильмы, песни, программное обеспечение и игры.

В изображенном на фиг.1 варианте осуществления запросы вырабатываются и представляются в блоке 110 для лицензирования контента и для выполнения этого контента для лицензиатов. Эти запросы принимают многочисленные формы в зависимости от изменений подающих организаций и типов лицензионных соглашений. Операция выполнения выполняет необходимый анализ для идентификации ключевой информации об идентификации контента (которая называется Название/Альфа), клиенте, который будет обслуживаться, и сроках обслуживания, таких как срок выполнения.

Следующим этапом в процессе выполнения является анализ требований к инвентаризации в блоке 120. Для выработки производственного плана, который приведет к созданию результатов, необходимых для лицензиата, анализ инвентаризации проводится для каждого Названия/Альфа. Этот анализ начинается с определения окончательных результатов (т.е. продукции), требуемых лицензиатом, и процессов на каждом уровне компонентов, используемых для выработки продукции от мастера копирования в дискретное видео, аудио и текстовые компоненты до мастера оригинала, созданного на производстве. Для каждого требования клиента этот процесс в различных формах осуществляется с помощью операции обслуживания или поставщика.

После того, как становится известным статус инвентаризации для каждого Названия/Альфа, в блоке 130 определяется и вырабатывается производственный план.

Этот план может включать в себя небольшое количество этапов, таких как для требования копирования и отгрузки, или может потребовать более сложного производства, которое может включать такие процессы, как преобразование с понижением частоты, воспроизведение аудио и применение субтитров перед копированием и отгрузкой. Производственный план определяется на основании существующих компонентов инвентаризации и знания производственного технологического процесса. Анализ инвентаризации и планирование производства, более подробно описаны ниже.

Сразу после одобрения производственного плана, он выдается для выполнения в блоке 140. Этот процесс включает в себя деятельность, к которой относится приобретение, или собственное производство, включающее в себя автоматизацию управления технологиями обработки контента, такими как управление файлами, транскодирование, упаковка и доставка, которыми управляют с помощью стандартных интерфейсов данных.

Процесс упаковки и доставки (который выполняется в блоке 150) поддерживает непрерывную автоматизацию процесса выполнения. Продукция доставляется в соответствии со стандартом при поддержке медиа и метаданных для того, чтобы их могла использовать система управления контентом клиента. Изменение этих стандартов требует гибкости в управлении информацией и поддержке медиа.

На фиг.2 представлена блок-схема системы 200 магистрали распределения, согласно одному варианту осуществления настоящего изобретения. В изображенном на фигуре 2 варианте осуществления блок-схема иллюстрирует объекты и процессы, необходимые для выполнения анализа материалов и выработки производственного плана. Таким образом, система 200 магистрали распределения включает в себя спецификацию 230, доставляемую клиенту (включающую в себя профиль 210 клиента), механизм 240 анализа производства, механизм 250 планирования производства, инвентаризационные вспомогательные данные 260 и мастер-данные 270 технологического процесса. Механизм 250 планирования производства выполняет или использует источник 252 активов компонентов, технологические процессы 254 и анализ 256 затрат и времени производственного цикла.

В одном варианте осуществления, автоматизированный технологический процесс опирается на мастер-данные 270 (см. приложение 5 к подробному описанию) и поддерживает параллельно несколько технологических процессов инвентаризации и обработки контента. Механизм 250 планирования производства использует эти мастер-данные 270 для выработки конкретных производственных планов в ответ на запросы от клиентов. Эти производственные планы представляют собой основной набор команд для управления обработки контента и выработки информационных пунктов, требуемых для оценки затрат и времени производственного цикла.

Механизм 240 анализа производства использует мастер-данные 270 технологического процесса и инвентаризационные вспомогательные данные 260 (см. приложение 4 к подробному описанию) наряду с вводом из модуля запросов (см. приложение 2 к подробному описанию), который имеет дело с отношениями партнер-клиент и с тем, как вырабатываются запросы. Используя спецификацию 230, доставляемую клиенту, механизм 240 анализа производства идентифицирует соответствующий технологический процесс. В рамках технологического процесса определяют все задачи, необходимые для создания спецификации клиента. Кроме того, определяют с возможностью использования все необходимые типы компонентов для каждой задачи. Обладая этой информацией, механизм 240 сначала выполняет анализ материалов. Система 200 магистрали распределения запрашивает инвентаризацию для необходимых компонентов для специфицированного Названия/Альфа 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, клиент КиноКосмос (CinemaSpace) и профиль клиента для внутренних сквозных продаж (DST) были идентифицированы пользователем для Названия "Самолет" и Альфа "Театральный". На фиг.5, технические спецификации приведены для иллюстрации желания клиента получить контент с форматом изображения 16×9 и частотой кадров 23, 98. Однако дополнительные технические спецификации также показывают, что способность принимать различные форматы основана на доступной инвентаризации для Названия/Альфа. Спецификация сборки предусматривает данные непосредственно в производственном плане для использования при создании профиля транскода, а также данные из технической спецификации.

Спецификация контента, представленная на фиг.6, показывает многочисленные наборы предпочтений источника и технические спецификации, которые представляют диапазон результатов, которые клиент может принять. Их также ранжируют для того, чтобы выразить предпочтения клиента. Предпочтения источника используются для отыскания активов источника, которые можно использовать. Образцовые данные, показанные на фигуре, учитывают ту же самую спецификацию контента для обработки названий, которые изначально составляли 4×3 или 16×9. Название "Самолет" было выбрано в качестве более раннего названия каталога, которое может иметь только мастер видео 4×3.

Предпочтения производства допускают адаптацию операторов для подключения или отключения возможностей магистрали распределения на основании предпочтений клиентов. Таким образом, в примере, показанном на фигуре 6, предпочтение производства указывает на отсутствие замены 3:2 или уменьшение частоты кадров фильма 23,98 на частоту кадров видео 29,97.

На фиг.7 показан один пример состояния инвентаризации 700 для Названия "Самолет" 702 и Альфа "Театральный" 704. Блоки 710, 712 представляют собой активы источника, которые представлены для Названия/Альфа. Блоки 720, 722 представлены для иллюстрации того, что все активы источника соответствуют мастер-спецификации. Когда анализ материалов выполнен, можно отыскать актив источника или спецификацию компонента. Нахождение спецификации компонента приведет к требованию компонента, включающего в себя Название, Альфа и информацию о спецификации компонента. Требование компонента представляет собой инструмент управления задачами, необходимый для управления загрузкой. Комплект 730 представляет собой группировку компонентов (например, аудио компонент и видео компонент), который соответствует и синхронизирован таким образом, чтобы компоненты могли работать вместе. Компоненты, которые определены для совместной работы, будут организованы с возможностью указания типа комплекта для мастер-данных технологического процесса. Под управлением Альфа комплект разрешит конкретное подтверждение активов, которые будут работать совместно. Обычно комплект будет иметь один видео компонент и один или более аудио компонентов, где любое аудио будет работать с видео в этом комплекте. Мастер-данные технологического процесса, поддерживаемые спецификациями клиента, будут обрабатываться, причем их изменчивость аудио или вспомогательный материал используют из комплекта.

Как показано на фиг.6 с учетом фиг.7, анализ материалов проводится для получения желаемых выходных результатов под управлением технических спецификаций. Как отмечалось выше, анализ материалов представляет собой итерационный процесс, который проходит через предпочтения источника и технические спецификации до тех пор, пока активы не обнаружат, на основании возможностей системы, возможность использования выработки желаемых результатов. Как показано на фигуре 6, предпочтения источника являются наборами критериев, которые представляют собой нетехнические предпочтения или предпочтения контента для клиента.

Возвращаясь к фиг.6 и фиг.7, анализ материалов выполняется в случае образцового использования. Сначала предпочтения источника с рангом 1 используются для запроса инвентаризации 700. В примере инвентаризации 700, показанном на фигуре 7, система осуществляет поиск источника видео 16×9 и источника аудио стерео на английском языке. Запрос также требует, чтобы эти активы были представлены в виде комплекта. Однако этот запрос не удается, потому что отсутствует актив видео 16×9. Соответственно, предпочтения источник с рангом 2 используются затем для запроса инвентаризации 700. В этом случае, система осуществляет поиск источника видео 4×3 и источника аудио стерео на английском языке. Запрос также требует, чтобы эти активы были представлены в виде комплекта. На этот раз, запрос был выполнен успешно.

Затем выполняется отображение возможности с использованием проведенного анализа материалов, как описано выше. Отображение возможности представляет собой ряд правил, которые позволяют отобразить критерии актива источника в критериях технической спецификации. Ссылаясь на фиг.8, когда активы источника найдены, из этих активов извлекают данные. Данные также извлекают из технической спецификации. Эта полезная нагрузка подается в механизм 800 правил. Результатом является подтверждение того, что все необходимые преобразования могут быть размещены, и идентификация необходимых преобразований. Предпочтения производства включаются в анализ, который может дисквалифицировать возможности системы, основанной на предпочтениях клиентов.

В отображении образцовых возможностей, показанном на фиг.8, сбор данных производят из активов, идентифицированных в запросе анализа материалов, в котором источник видео 4×3 и источник аудио стерео на английском языке идентифицированы и представлены в виде комплекта. Данные также собираются из технической спецификации 810 с рангом 1 и подаются в механизм 800 правил отображения возможностей. Это итерация становится неудачной из-за отсутствия возможности преобразования мастера изображения из 4×3 в 16×9. Следует отметить, что правила, которые управляют изменениями формата файла, можно упростить путем создания зависимых правил 840, которые глобально запрещают определенные комбинации. Это избавляет от необходимости выражать все возможные комбинации отображения критериев.

Как показано на фиг.9, данные собираются из активов, идентифицированных в запросе анализа материалов, наряду с данными из технической спецификации 820 с рангом 2, и подаются в механизм 800 правил отображения возможностей. Эта итерация по-прежнему остается неудачной по двум причинам: (1) как и прежде отсутствует возможность преобразования мастера изображения 4×3 в 16×9, и (2) клиент предпочитает получать контент, который не был обработан через удаление 3:2 на основе программного обеспечения или разъединения 900, которое в противном случае представляет собой возможность системы магистрали распределения.

Как показано на фиг.10, данные собираются из активов, идентифицированных в запросе анализа материалов, наряду с данными из технической спецификации 830 с рангом 3 и подаются в механизм 800 правил отображения возможностей. Эта итерация становится успешной только с помощью преобразования 1000, запрашиваемого из ко дека мастер-файла в кодеке технической спецификации.

На фиг.11 показана взаимосвязь связь образцового требования 1100 источника, набора 1110 и технической спецификации 1120 для получения набора производственных функций, использующих правила системы и/или логику. Каждая функция производства является примером типа функции производства, которая затем отображается в списке возможных шаблонов элементов работы. Функция производства может вырабатывать более чем одного из возможных шаблонов элементов работы. В примере на фигуре 11 показаны два шаблона элементов работы, Услуга 1 и Услуга 2 для получения решения транскодирования медиа. На основании правил, определенных системой, выбирается один подходящий элемент работы, а именно Услуга 1. Элементы работы включают в себя информацию относительно параметра «Из» (например, 16×9), параметра "В" (4×3) и системы для использования (например, Услуги 1). Каждый шаблон элемента работы связан с набором соответствующих этапов выполнения в рамках шаблона этапа выполнения. Пример, изображенный на фигуре 11, включает в себя следующие этапы:

Построение рабочей зоны; Определение местонахождения материалов для сборки; и Услугу 1 с профилем (MPEG 4). Поэтому, на основании отображения шаблона элемента работы для выполнения шаблона этапа, получаются требуемые этапы выполнения.

Сразу после идентификации этапов выполнения, производственный план можно оптимизировать различными способами. Например, случи со сложными многоэтапными преобразованиями в производственном плане могут привести к идентификации многочисленных шаблонов элементов работы (избыточная оптимизация). Эти шаблоны могут иметь избыточные этапы выполнения, такие как "Определение местоположения материалов для сборки). Эти избыточные этапы можно по существу уменьшить или исключить при оптимизации избыточности. Кроме того, в сложных случаях некоторые этапы выполнения можно выполнять параллельно или в одной операции, такой как "преобразование формата" и "преобразование 6×9 в 4×3". Эти этапы можно объединить в одной операции во время комбинационной оптимизации. После оптимизации выполняется производственный план. После его выполнения, план используется для выработки необходимой оркестровки технологического процесса, который будет преобразовывать идентифицированные материалы источника в требуемый продукт, доставляемый клиенту.

На фиг.12А изображены компьютерная система 1200 и пользователь 1202. Пользователь 1202 использует компьютерную систему 1200 для выполнения функций распределения цифрового контента. Компьютерная система 1200 сохраняет и выполняет цифровую обработку 1290 распределения.

Фиг.12В изображает функциональную блок-схему, иллюстрирующую компьютерную систему 1200, выполняющую цифровую обработку 1290 распределения. Контроллер 1210 является программируемым процессором и управляет работой компьютерной системы 1200 и ее компонентами. Контроллер 1210 загружает команды (например, в виде компьютерной программы) из памяти 1220 или встроенной памяти контроллера (не показана) и выполняет эти команды для управления системой. При их исполнении, контроллер 1210 выполняет цифровую обработку 1290 распределения в виде программной обработки, такой как для обеспечения анализа материалов и планирования производства. Альтернативно, эту услугу можно реализовать в виде отдельных аппаратных компонентов в контроллере 1210 или компьютерной системе 1200.

Память 1220 временно хранит данные для использования другими компонентами компьютерной системы 1200. В одном варианте осуществления, память 1220 реализована в виде ОЗУ. В одном варианте осуществления, память 1220 также включает в себя долговременную или постоянную память, такую как флэш-память и/или ПЗУ.

Запоминающее устройство 1230 временно или долговременно хранит данные для использования другими компонентами компьютерной системы 1200, такой как для хранения данных, которые используются системой 1290 цифровой обработки распределения. В одном варианте осуществления, запоминающее устройство 1230 является накопителем на жестком диске.

Медиа-устройство 1240 принимает съемный носитель информации и считывает или записывает данные на вставленный носитель информации. В одном варианте осуществления, например, устройство 1240 хранения данных является накопителем на оптическом диске.

Пользовательский интерфейс 1250 включает в себя компоненты для приема пользовательского ввода от пользователя компьютерной системы 1200 и представления информации пользователю. В одном варианте осуществления, пользовательский интерфейс 1250 включает в себя клавиатуру, мышь, аудио громкоговорители и устройство отображения. Контроллер 1210 использует ввод от пользователя для управления работой компьютерной системы 1200.

Интерфейс 1260 ввода-вывода включает в себя один или более портов ввода-вывода для подсоединения к соответствующим устройствам ввода-вывода, таким как внешнее запоминающее устройство или дополнительное устройство (например, принтер или персональный цифровой помощник (PDA)). В одном варианте осуществления, порты интерфейса 1260 ввода-вывода включают в себя порты, такие как порты USB, порты PCMCIA, последовательные порты и/или параллельные порты. В другом варианте осуществления, интерфейс 1260 ввода-вывода включает в себя беспроводный интерфейс для поддержания беспроводной связи с внешними устройствами.

Сетевой интерфейс 1270 включает в себя проводное и/или беспроводное сетевое подсоединение, такое как RJ-45 или интерфейс "Wi-Fi", включающий в себя, но неограниченный 1202.11), поддерживающий соединение по сети Ethernet.

Компьютерная система 1200 включает в себя дополнительные аппаратные средства и программные средства, типичные для компьютерных систем (например, питание, охлаждение, операционная система), хотя эти компоненты не показаны на фигуре 8 В для простоты. В других вариантах осуществления можно использовать другие конфигурации компьютерной системы (например, различные конфигурации шины или запоминающего устройства или многопроцессорную конфигурацию).

Приведенное выше описание раскрытых вариантов осуществлений выполнено для того, чтобы любой специалист в данной области техники мог выполнить или использовать настоящее изобретение. Различные модификации к этим вариантам осуществления будут очевидны специалистам в данной области техники, и общие принципы, описанные здесь, можно применить к другим осуществлениям без отклонения от сущности или объема настоящего изобретения. Соответственно, дополнительные осуществления или изменения также находятся в пределах объема настоящего изобретения. Кроме того, следует понимать, что описание и чертежи, представленные здесь, представляют собой предмет изобретения, который широко рассмотрен настоящим изобретением. Кроме того, следует понимать, что объем настоящего изобретения полностью охватывает другие варианты осуществления, которые могут стать очевидными специалистам в данной области техники, и этот объем настоящего изобретения соответственно не ограничен ни чем, кроме прилагаемой формулы изобретения.

Приложение 1. Основы цепочки цифровой доставки

Для компании Сони (Sony) магистраль распределения (DBB) представляет собой механизм расширения своего присутствия в цепочке цифровой доставки услуг развлечений. Важность этого механизма приобретает предвидение того, как цепочка цифровой доставки будет развиваться со временем и использовать знания и опыт. Стремление к повышению производительности цепочки доставки проявляется в гибкости и Услуге 2 через использование ключевых показателей эффективности (KPI) (постоянно улучшаемых) цепочки доставки, руководящих принципов цепочки доставки, ориентации на передовые технологии, управлении сроком службы и эффективном разделении планирования и анализа деятельности по результатам выполнения. Опыт цепочки доставки, накопленный в компании Сони и у многих партнеров, обеспечивает перспективу того, как DBB должна продвигаться вперед после своего первого выпуска и применять передовой опыт работы в дополнение к усовершенствованным функциям автоматизированной обработки контента.

Управление сроком службы продукта

В дополнение к внутренним характеристикам, продукт будет также иметь типичный Срок службы, которого он будет придерживаться. Этот Срок службы можно проследить с самого начала продукта на всем его пути до конца срока службы с дополнительной возможностью продления. Уроки, извлеченные из физического производства развлекательного контента на оптических носителях информации, учат, что обычно происходит резкое увеличение спроса на продукцию, за которым следует спад с различным темпом падения. Такое знание позволяет расширить возможности планирования.

В качестве провайдера цифровых услуг по цепочке доставки компания Сони будет иметь сильную заинтересованность в сроках службы продуктов своих покупателей в качестве точки ввода данных для ввода в планирование деятельности, которая относится к DBB. Этот тип информированности представляет собой то, что позволит DBB работать на очень высоких уровнях эффективности при доставке на уровнях передовых услуг с приемлемой стоимостью. В2В и цифровые аспекты DBB изменяют динамику управления сроком службы продукта, но подобные принципы можно применить на различных уровнях. Например, управляемая многоуровневая среда хранения может извлечь выгоду из знания версии продукта Windows и упредить перемещение файлов между уровнями, чтобы минимизировать задержки поиска, а также стоимость хранения на уровне хранения в режиме прямого доступа. Кроме того. Семейства продуктов, как описано ниже может повлиять на характеристики срока службы продукта. Дополнительную информацию о Сроке службы можно получить из атрибутов, таких как является ли название продолжением или предысторией, а также общих контекстных событий, таких как изменение формата файла на промышленном уровне.

Семейства продуктов

Анализ типов продукции, этапов обработки, типов форматов, скоростей передачи битов и требований к спецификациям доставки может часто приводить к идентификации образцов. Дальнейшее изучение образцов будет часто приводить к группированию на основании внутренних характеристик продукта, который производится в настоящее время, как в физическом, так и в виртуальном значениях этого термина. Эти группирования обеспечивают естественную сегментацию, которую можно использовать для группирования продуктов по семействам, для которых можно применить различные процессы и правила выполнения.

DBB должна быть гибкой и поддерживать требования заказчика к оркестрованным технологическим процессам в соответствии с этим семейством продукции. Как и с большей частью результатов сегментации, выравнивание технологических процессов для семейства продуктов уменьшает общее количество уникальных случаев и исключений. Целью является модернизация исполнительных конвейеров и создание их гибкими. Это, в свою очередь, позволяет сосредоточиться на основных процессах, которые повышают ценность внутри цепочки доставки.

Представленный в качестве примера анализ оперативных данных должен, скорее всего, выявить общность между двумя главными группировками продуктов: характерные признаки в отличие от эпизодических. Каждый тип продукта может иметь идеальные технологические процессы, которые улучшают их Технологичность (как определено ниже). Подобным образом, приобретенный контент позволяет извлечь выгоду из альтернативных процессов или оркестрованных технологических процессов по сравнению с произведенным контентом.

Технологичность и управление контрольными точками

Построение цифровой цепочки доставки включает в себя координацию многочисленных этапов обработки, похожих на традиционные цепочки доставки. Деятельность планируют перед выполнением с акцентом на закладку фундамента для обеспечения модернизированного выполнения сразу после осуществления плана. Определение контрольных точек в рамках этих планов учитывает дискретные модули, которыми можно гораздо легче управлять и отследить. Потенциальные задержки можно проанализировать и отследить для выявления причин. Поэтому управление контрольными точками повышает технологичность, что позволяет избежать спада и исключительных ситуаций во время их выполнения.

Наличие технологичности и поддержки управления контрольными точками, выполняемого с помощью DBB, будет основным фундаментом, позволяющим компании Сони стать центром передового опыта, по настоящему становясь партнером для своих заказчиков цепочки цифровой доставки. DBB может использовать Шаблоны, выполняющие этапы обработки по умолчанию, запланированные в графике работ, который корректируется с помощью входных параметров. Установленные намеченные сроки можно сравнить с фактическими и обеспечить возможность для координации совместной деятельности для решения единых задач при взаимопонимании результатов регулировки.

DBB будет зависеть от внешних точек соприкосновения, которые могут оказывать влияние на технологичность, такую как получение Мастеров из группы Мастеринга. Контрольные точки приема Мастера можно зарегистрировать в Шаблоне с помощью параметров, которые относятся к Семейству продуктов, таких как изменение сроков мастеринга между театральными эпизодическими названиями. Прекращение общей работы в Контрольных точках может помочь идентифицировать основную причину заявок, которые не были выполнены во время. Анализ этих заявок может показать образцы, связывающие задержки с конкретным Семейством продуктов (например, Мастеры для приобретенного контента могут часто сталкиваться с задержками из-за неуправляемого или неизвестного качества исходных материалов, обнаруженных в процессе приобретения) и помочь обратить внимание на Технологичность, сосредоточив усилия на улучшение процессов или систем для этого конкретного сегмента, который можно отследить вплоть до конкретного Семейства продуктов.

Стратегия и оптимизация управления

Используя эти важные основы вместе, можно осуществить дополнительную оптимизацию. Основополагающие элементы предусматривают базовые точки, которые можно обработать с использованием современных методов анализа, которые приводят к дополнительному выявлению закономерностей, а также людей, которыми движет постоянное совершенствование. Эти модели усовершенствования процесса можно использовать для определения наборов правил на различных уровнях, которые подаются в качестве Стратегий управления.

Гибкость является ключевым принципом DBB, которой необходимо придерживаться, и она, в конечном счете позволит эффективно использовать Стратегии управления, определенные выше. На системном уровне, возможность применения наборов правил, которые оптимизируют цепочку доставки, должна быть основной возможностью системы и тем, что можно идеально использовать для всех систем цепочек доставки, даже вне DBB. Эта возможность наращивания, которая опирается на усовершенствованную практику цепочек доставки, не должна ограничиваться DBB, но должна быть доступна для интеграции всего развлекательного Центра цепочки доставки Высокого качества.

Компания Сони планирует объединить существующие знания для включения Стратегий и оптимизаций управления, по возможности, при любых обстоятельствах для начального развертывания DBB. Это знание будет поступать из базовых точек существующих систем и процессов и будет объединено для будущего решения. Непосредственное воздействие будет видно от того, так как будет определена Стратегия управления миграцией, чтобы гарантировать, что названия и клиенты, которые обеспечивают самую высокую прибыль, будут импортированы и адаптированы в DBB. Первоначально, полученные в результате правила можно применить полуавтоматизированным процедурным способом, но долгосрочная цель компании Сони заключается в действительном применении стратегий и оптимизаций управления более систематическим способом с помощью автоматизации, включенной везде, где это выгодно.

Приложение 2. Отношения между партнерами и клиентами

1. Обзор

Магистраль распределения DBB требует поддержки определенных типов данных для того, чтобы осуществить свою концепцию обеспечения Партнеров возможностью обслуживания из потребностей при распределении контента. Партнеры, Клиенты, Профили клиентов, Спецификации и Конфигурации представляют собой несколько ключевых объектов, для которых данные должны быть сохранены, и данными необходимо управлять в рамках DBB.

2. Описание

На фиг.13 изображена образцовая схема отношения объектов, показывающая как Партнеры и Клиенты должны относиться к Профилям клиента. Спецификациям и Конфигурациям. Цель этой схемы не предполагает определить окончательные конструкции, но предполагает помочь описать типы отношения, чтобы, как предполагается, удовлетворить карты процесса состояний.

Партнеры являются владельцами контента и заказчиками DBB. Партнеры будут спонсировать пользователей и предоставлять им доступ к DBB для того, чтобы вырабатывать запросы и видимость статуса технологического процесса. Каждый партнер будет иметь возможность распределять контент одному или многочисленным клиентам.

Клиенты представляют собой компании, работающие по контракту с партнерами для приема контента. Запись клиента определяет информацию, необходимую для определения организационно-правовой формы хозяйствования. Хотя контактная информация может существовать на этом уровне, Контакты могут также ассоциироваться с профилями клиента, как будет описано ниже.

Один клиент может не заниматься с многочисленными партнерами, например, Amazon с компанией Сони и Paramaunt. Отдельная запись клиента будет сохраняться для каждого партнера, однако все записи клиента, представляющие собой одну и ту же компанию под многочисленными партнерами, должны быть связаны для обеспечения представления о том, что Клиент напротив всех Партнеров. Образцовые Клиенты включают в себя Apple и Amazon (DDI), Comcact и AXN (широковещание). Клиенты будут добавлены в DBB, при необходимости, на основании для того, чтобы выполнить запросы Партнера для распределения контента.

Профили клиента используются для определения требований, каждого клиента для доставки контента. Один или более профилей клиента можно установить из расчета на одного клиента, чтобы представить многочисленные бизнес-модели для этого клиента, например, DST, DDI, VOD или при необходимости, изменить на основании территории или других бизнес/технических причин. Как установлено выше, контактная информация может быть связана с Профилем клиента, если многочисленные контакты существуют для клиента. Профили клиента будут создаваться с помощью Администраторов DBB.

Спецификации определяют ключевые переменные и требования, необходимые для поддержки автоматизированных ручных технологических процессов. Информация о спецификации может быть общей для всех многочисленных клиентов. Мастер спецификации будет поддерживаться с возможностью связи одной спецификации с многочисленными клиентами. Модификация Спецификации должна быть разрешена на уровне Клиента или на уровне мастера. Модификация на уровне Клиента может привести в результате к новой записи в пределах мастера спецификаций. Модификация на уровне мастера позволит распространить изменения на всех клиентов, связанных с этой спецификацией. Проверки достоверности должны выполняться вместе для гарантии того, что дублированные спецификации не создаются.

Хотя функциональное требование спецификации заключается в поддержке обработки и распределении контента, человекочитаемая абстракция данных спецификации будет доступна для Партнера в целях просмотра и связи.

Переменные - В связи со Спецификацией, некоторую информацию можно определить в качестве уникальной для каждого профиля. Эту информацию в рамках спецификации можно определить в качестве входных переменных при связи с Профилем клиента. Например, спецификация доставки позволяет определить средство доставки, но переменные, специфические для Клиента, могут включать в себя предпочтения формата изображения.

Конфигурации - конфигурации, которые представляют собой наборы информации, созданные индивидуально для каждого Профиля клиента. Хотя спецификации представляют собой повторно используемые наборы информации, которые могут быть связаны с Профилями клиента, Конфигурации могут быть специфическими и уникальными для Профиля клиента. В этих случаях, "стандартные конфигурации" можно повторно использовать для всех многочисленных профилей клиентов.

Типы спецификации - DBB хранит и управляет многочисленными типами спецификаций при поддержке преобразования и доставке контента. Типы спецификации включают в себя, но не ограничиваются следующим:

а. Спецификация продукта - определяет технические метаданные, которые требуются для создания окончательно распределенного продукта, который может включать в себя Видео, Аудио, Изображения, Титры, Субтитры и т.д. Спецификация используется с выгодой и совместно используется с услугами DBB, такими как транскодирование, для того, чтобы производить конечный продукт в соответствии с техническими спецификациями. Спецификации включают в себя скорость передачи битов, частоту кадров, формат файла и т.д.

b. Спецификация метаданных - определяет информацию, которая требуется для выработки доставляемых метаданных/файла. При использовании для достижения цели информации, доступной в рамках спецификации метаданных, система определяет формат файла метаданных в конечном состоянии (например, XML, XL Excel, CSV и т.д.), а также специфические области метаданных и значения, которые будут включены для специфического Названия/Альфа. Важно отметить, что спецификация метаданных действует как проверка достоверности данных, обеспечивающая соблюдение соответствующих конечной структуры метаданных. Могут потребоваться определенные области, в которые необходимо вводить данные, представленные в определенном формате (ГГГГММ-ДД). Можно определить другие области для приема повторяющихся значений и нормативной лексики. Спецификация метаданных обеспечивает соответствие и правила преобразований, которые необходимы для интерпретации корпоративного канонического хранилища метаданных DBB. Области, ограниченные рамками спецификации, будут упоминаться с использованием ID корпоративных канонических метаданных DBB.

с. Другие спецификации - дополнительные требуемые Спецификации можно идентифицировать во время проектирования/реализации.

Типы конфигурации - DBB хранит и управляет многочисленными типами конфигураций при поддержке обработки и доставки контента. Типы спецификации включают в себя, но не ограничиваются следующим:

а. Конфигурация сборки - конкретно для обработки контента, существует разделение между спецификацией для сущности Продукта и Конфигурацией для сборки. Конфигурация для сборки определяет сборку и порядок внешнего вида контента и добавлений, таких как логотипы, паспортные данные, знаки безопасности с сигнальным черным цветом и т.д. Эта информация отделена от Спецификации для Продукта из-за большого разнообразия этих конфигураций, основанных на потребностях клиентов. Многочисленные клиенты могут использовать одинаковую спецификацию файла и скорость передачи данных, но требовать различные конфигурации сборки. Примерами пунктов конфигурации сборки являются Логотипы, паспортные данные, сбои и оверлеи, вставка карт предупреждения, градация тонов штрих-кода и знаки безопасности с сигнальным черным цветом.

b. Конфигурация пакета - определяет информацию, которая требуется для выработки пакета. Информация, которая относится к пакету, может включать в себя местоположение/формат спецификации упаковки, договор о наименовании контента упаковки, путь к каталогу контента, путь к каталогу выходного пакета и определение типа упаковщика пакета (например, MXF, ZIP, структура каталога или свободные файлы).

с.Конфигурация доставки - определяет информацию, которая требуется для доставки пакета. Хотя цель заключается в доставке в цифровом формате (например, Aspera, SmartJog, FTP), конфигурация доставки позволяет обработать физический выход. Примером является вывод пакета в накопителе на жестких дисках и отправление его по физическому адресу. В этом примере, способ Конфигурации доставки является "накопителем на жестких дисках".

Предполагается, что вырабатывается Конфигурация доставки FTP, Выбор способа, такой как FTP, является частью Конфигурации. Дополнительные входы, такие как адрес IP, Имя пользователя. Пароль и Порт вводятся для полной определенности способа доставки. Эта информация хранится в виде набора данных, связанных с Профилем клиента.

Вторую Конфигурацию для носителя на жестких дисках или Aspera можно добавить в Профиль клиента. Данные, которые требуются для каждой конфигурации являются специфическими для выбранного способа доставки.

Статус Клиента/Профиля - чтобы управлять возможностью DBB обслуживать Клиента или Профиль клиента статусы и связанные с ними правила должны быть конфигурируемыми.

Связь Профиль/Спецификации - в рамках Профиля клиента, многочисленные спецификации можно назначить в рамках каждой категории, упомянутой выше. Одна спецификация каждого вида устанавливается по умолчанию, но пользователь может отменить "по умолчанию" и выбрать другую допустимую спецификацию, которая была связана с Профилем клиента.

В одном примере, спецификация доставки по умолчанию для Профиля клиента является спецификацией FTP, но из-за большого размера конкретного Запроса, запрашивающая сторона может выбрать Накопитель на жестких дисках в качестве альтернативной спецификации доставки.

Тип Названия - многочисленные спецификации продуктов могут существовать, как описано выше. Во время связи спецификации продукта с Профилем клиента существует переменная, которая позволяет определить Тип названия. Это позволяет назначить спецификацию для специфического типа Продукта, например, Особенность, Эпизод или Анонс. Каждое Название, выбранное для обработки имеет Тип Названия по умолчанию в случае Особенности или Эпизода или позволяет выбрать Тип Названия в случае Анонса только по запросу. Эта переменная поддерживает необходимость обработки различных типов названий с различными Спецификациями продуктов.

Пользовательский интерфейс

С точки зрения пользовательского интерфейса, управление Партнерами, Клиентами и Профилями клиентов будет предположительно обрабатываться через пользовательский интерфейс. Этими особенностями будут в большинстве случаев управлять с помощью внутренних бизнес-аналитиков DBB. Однако спецификации являются по существу техническими, и ими будут, вероятно, управлять с помощью технического ресурса DBB и, если потребуется, будут управляться в рамках XML.

4. Услуги

Услуги не подвергаются воздействию DBB, кроме как через ПИ для управления Партнерами, Клиентами, Профилями клиентов. Спецификациями и Конфигурациями. Управление этими данными будет осуществляться из DBB.

5. Интерфейсные системы

Во внешних системах не будут использоваться Интерфейсы партнеров. Клиентов, Профилей клиентов, Спецификаций и Конфигураций.

6. Мультипользователь

Концепции, обсужденные выше относительно отношений Партнер/Клиент, по существу определяют требования к мультипользователям для DBB. Административные программы должны обеспечить возможность создания иерархических отношений, описанных выше.

Приложение 3. Управление запросами

1. Обзор

Для DBB требуется пользовательский интерфейс с возможностью ввода запросов для различных форм обработки содержания. Управление запросами обеспечивает функциональные возможности, необходимые для идентификации клиентов и их необходимые продукты в окончательной форме. Этот пользовательский интерфейс является первичной точкой взаимодействия между бизнес-пользователями, ответственными за выполнение DBB. Через этот интерфейс управляют всей необходимой для DBB уточняющей информацией, технической или относящейся к бизнесу. Все требования к статусу бизнес-модуля направляются через этот интерфейс. По возможности подразумевается, что этот интерфейс использует структуры данных, которые описаны ниже, для создания развитой логики, которая позволяет пользователю вводить больше общей информации и позволяет системе направлять и оказывать помощью пользователю на уровне специфичности, необходимой DBB для выполнения требований.

Управление запросами является набором пользовательских интерфейсов (ПИ), которые позволяют обеспечить для авторизованных пользователей доступ к ПИ, описанных здесь, и к более детализированным уровням деталей технологического процесса DBB, как описано ниже.

2. Описание

Фиг.14 изображает первичные вводы в модуль поддержки запросов.

Вводы LOB - вводы LOB или "сферы деятельности" представляют собой Организатора, например, отделения продаж компании Сони. Эти отделения дают право на использование контента различным заказчикам и требует выполнения от Запрашивающих сторон, например, всемирное выполнение продукции (WPF). Запрашивающие стороны будут использовать DBB для создания и доставки этого контента. На высоком уровне LOB условия сделки, такое как лицензионное окно, дата эфира, тип лицензии и другая значимая информация. Эта информация будет включена в запрос, представленный на рассмотрение Запрашивающими сторонами. Кроме того, LOB обеспечивает первичные вводы для запросов. Названий и Клиентов. В общих чертах и так, как это применимо к Партнерам, это является бизнесом, который относится к информации, которая может потребоваться для того, чтобы включить ее в Пакетные метаданные или для поддержки операций по выписке счетов.

Клиенты - Организатор будет указывать одного или более клиентов, которые будут обрабатываться для данного запроса. Запрашивающие стороны DBB будут определять соответствующие профили клиентов в пределах запроса в случаях, где один клиент имеет многочисленные профили. Профили Клиент/Клиент представляют собой лицензиаров контента, которые заключили договор с LOB для специфических Названий. Перед созданием запроса предполагается, что клиенты были адаптированы и были созданы все соответствующие Профили и Спецификации. Информация о Спецификации должна быть доступной только с точки зрения формата у Запрашивающей стороны для того, чтобы облегчить выбор Профиля.

Название/Альфа - существенная директива в рамках Запроса заключается в доставке одного или более точно определенных названий одному или более Клиентам. Как описано в приложении 4 "Организация инвентаризации", Альфа представляет собой изменения уровня контента в рамках названия, которое может быть специфическим для заданной территории или рынка. Например, для названия "Поверх барьеров", сцена, где один персонаж бьет другого персонажа клюшкой для гольфа, изменяется для театрального распределения в Японии. На основании этого требования, все почтовое театральное распределение любому японскому заказчику использует одинаковую отредактированную версию или Альфа.

Выбор Названия/Альфа - предполагается, что выбор специфического Альфа в случаях, где Название имеет больше одного, будет выполняться Запрашивающей стороной. Однако этому выбору можно оказать помощь и/или его можно автоматизировать на основании бизнес-правил, которые опираются на наличии метаданных на уровне профиля клиента и на уровне Альфа.

Выбор спецификация/конфигурация - спецификации и конфигурации Контента будут определены и связаны с Профилями клиента. Возможны многочисленные спецификации и конфигурации, связанные с профилем клиента на основании Типа названия, который будет в дальнейшем доставлен. Как установлено в приложении 2 "Отношения между партнером и клиентом", можно предоставить многочисленные спецификации и конфигурации, включающие в себя функцию по умолчанию. Запрашивающая сторона может выбрать альтернативные утвержденные спецификации в рамках Запроса. Информация доступна для оказания помощи/автоматизации выбора спецификаций. Например, Многочисленные спецификации продукта определены для клиента, одни для Эпизодического контента и другие для Характерного контента. В рамках поддержки Профиля клиента определены бизнес-правила для выбора соответствующей спецификации. Это можно сделать с помощью значения "Тип названия" в целях этого примера. Эти одинаковые метаданные будут связаны с Названием, выбранным по запросу, облегчая идентификацию описания сущности, как этого требует комбинация Название/Клиент.

Запрос Многочисленные названия/Многочисленные клиенты - Запросы можно выработать несколькими различными способами. Некоторыми примерами являются: Одно название и Один клиент, Одно название и Многочисленные клиенты; Один клиент и Многочисленные названия; и Многочисленные названия и Многочисленные клиенты.

Наиболее сложный сценарий представляет собой Многочисленные названия/Многочисленные клиенты. Для минимизации сложности сценария желательно гарантировать, что когда выбирают Многочисленные названия, все выбранные названия будут выполнены для каждого выбранного Клиента. Запрашивающая сторона не будет иметь возможности конфигурировать то, какие названия будут связаны с каким клиентом. В случаях, где не все Названия выполнены для всех Клиентов, будут обязательно выполнены многочисленные Запросы.

3. Пользовательский интерфейс

Применение пользовательского интерфейса позволяет пользователям создать, обновлять, отменять и получать статус для различных запросов. Кроме того, предполагается поиск и краткое отображение. В случаях, где определение Клиента/Профиля и выбор Названия требуют дополнительных с оказанием помощи/автоматизации выборов, они обрабатываются в формате мастера подсказок, который направляет пользователя в процессе принятия решения до глубины, необходимой для завершения заказа. Эта глубина должна достигнуть уровня специфического поиска Компонента и выбора, а также ручного выбора спецификации. Глубина определения, допустимая для пользователя, должна быть конфигурируемой. Определенные уровни выбора, такие как для специфических Компонентов источника, можно определить как обязанности рабочего персонала.

4. Услуги

Предполагается, что услуги модуля Запроса будут открыты только в рамках DBB и не требуют формальных API для разрешения связи с другими системами. Однако архитектура должна исключать поток данных запросов непосредственно от любого Партнера.

5. Интерфейсные системы

Модуль Запросов будет иметь функциональные связи с Мастером заказчика, Мастером названия. Мастером технологических процессов и Управлением задачами. Эти наборы данных будут находиться в пределах магистрали или сопрягаться в целях архитектуры приложения. Только исключительная ситуация будет представлять собой интерфейс Названия GPMS. Информация Названия/Альфа будет сопрягаться и храниться внутри магистрали в степени, необходимой для поддержки распределения. Модуль Запроса может потребовать прямого запроса в GPMS для того, чтобы просмотреть дополнительную информацию о названии, которая не хранится в DBB.

6. Мультипользователь

DBB имеет мультидоменные возможности, как описано в приложении 2 "Отношения между партнерами и клиентами". Многочисленные "Партнеры" будут требовать доступа к ПИ запроса. Имя пользователя и привилегии безопасности должны поддерживаться независимо для каждой пользовательской группы Партнера. Данные должны быть полностью разделены для всех уровней информации, описанных здесь.

Приложение 4. Управление инвентаризацией

1. Обзор

В дополнение к использованию технологий автоматизированной обработки контента, основные цели DBB включают в себя расширение автоматизации на основе правил для всех аспектов выполняемого технологического процесса. Современные модели метаданных инвентаризации киноиндустрии не обладают строгой организацией, необходимой для поддержки автоматизации в областях идентификации активов источника. Процессы получения и хранения активов и метаданные, которые записаны обычным способом, подвержены значительной частоте появления ошибок. В результате, ручной труд, который требуется для идентификации правильных активов источника в течение производственного периода, стал в значительной степени узким местом в современном цифровом исполнении. Внедрение более жесткого и строгого контроля метаданных позволяет автоматизировать выбор активов и значительно сократить ручное вмешательство и увеличить в целом производительность.

Для того, чтобы поддержать однозначную инвентаризацию, были идентифицированы две основные концепции, которые требуют большие структуры. Концепция "Версия" была переименована в номенклатуре компании Сони в "Альфа". Эта концепция представляет изменение контента, который может существовать в рамках инвентаризации для данного названия. Добавление структуры к этой концепции предоставит возможность более точного опроса инвентаризации, создающей совместимые "Комплекты" инвентаризации в рамках данного названия. В рамках организации Альфа, инвентаризация на основании компонента использует традиционные производственные дисциплины путем облегчения связи активов источника с производственными процессами, которые они поддерживают.Эти концепции поддерживают автоматизированную обработку медиа-контента тем же самым способом, как накладная на материалы поддерживает автоматизацию традиционного производства.

Объем видимости инвентаризации будет охватывать цифровые активы в пределах решения DBB DAM и будет также распространяться на внешние физические и цифровые компоненты в рамках решения Управления физическими активами партнера. Пределы, для которых организационные принципы, описанные здесь, реализованы в физических активах, должны быть гибкими для того, чтобы можно было удовлетворить потребности бизнеса для анализа стоимости и времени производственного цикла.

2. Описание

Фиг.15 отображает образцовую иерархию, которая существует между названием, которое имеет два Альфа (режиссерская версия и театральная версия), и семейство компонентов, которые будут идентифицированы для обслуживания Режиссерской версии Альфа.

Альфа - Концепция Альфа облегчает два основных требования в пределах DBB, идентификацию потребности клиента для названия с помощью версии, основанной на видео или на изменении видео или аудио контента и в виде организационного принципа инвентаризации актива, необходимого для обслуживания этих изменений.

Обычно Альфа описывает различные версии названия. Эти различия обычно связаны с тем, где и как можно распределить Название/Альфа. Альфа можно создать на основании редакций Стандартов и Правил эксплуатации, которая требуется для отображения названия на конкретной территории, рынке или медиа. Поскольку каждый заказчик будет обладать рынком, медиа и территориальным определением в рамках своего профиля, связь тех же самых данных с Альфа может оказать содействие в автоматизированной идентификации соответствующей версии для выбранного клиента. Требуется связь различных концепций правил распределения с каждой Альфа. Например, версия фильма без возрастных ограничений может быть разрешена для всемирного показа, но только для цифровой продажи. Редактирование одного и то же фильма, удаление специфических сцен насилия или ненормативной лексики может быть только версией, разрешенной для телевизионного распределения на одной или более зарубежных территориях. В результате, DBB может выбрать Неоцененную версию для клиента DST и отредактированную версию для широковещательного заказчика из Соединенного Королевства.

Альфа будет также использоваться в качестве организационного инструмента для инвентаризации активов как цифровых, так и физических. Современные бизнес-процессы приводят к созданию семейств-активов, необходимых для обслуживания каждого Альфа. Элементы изображения с различными форматами изображения и стандартами созданы для каждого Альфа под заданным названием. Аудио и текстовые активы затем создают для соответствия этим активам изображения. Имеется потребность в процессах, которые поддерживают создание, связь и удержание всех активов, созданных для обслуживания конкретных Альфа. Как минимум, потребуется загрузка идентификации специфических Альфа для конкретных активов, добавленных в DBB.

Понятие Альфа также распространяется на идентификацию Анонсов. Идентификация Анонса, который будет использоваться для специфического клиента следует тем же самым правилам, которые будут применяться к переменному полному контенту программы.

Комплекты - компоненты, определенные для совместной работы (которые соответствуют и синхронизированы) должны быть организованы. Это позволит мастер-данным технологического процесса указать Тип комплекта. Под Альфа, комплект разрешит специфическое подтверждение активов, которые будут работать вместе. Комплект имеет одну видео компоненту или одну или многочисленные аудио компоненты, где любое аудио будет работать с видео в рамках этого комплекта. Будут обрабатываться мастер-данные технологического процесса (которые поддерживаются спецификациями клиента), изменчивость которых материал аудио или поддержки используют из этого комплекта. Современные активы АЛМАЗЫ (смешанные аудио и видео) представляют собой один комплект.

Тип комплекта должен быть известен мастер-данным Технологического процесса и должен иметь атрибуты, которые предоставят возможность выбора правильного комплекта на основании ключевых значений, таких как формат изображения и стандарт.

Компоненты представляют собой отдельные аудио, видео, текстовые и/или объединенные активы, которые хранятся в качестве активов источника для обработки контента. Хотя понятие Компонент может распространяться на архивные или защищенные активы, их основная роль заключается в том, чтобы однозначно идентифицировать те активы, которые требуются для специфических производственных процессов. Компоненты можно рассматривать во многих отношениях, подобно "серийному номеру изделия" в традиционном производстве. Компонентная организация может исходить из DBB для обеспечения видимости в ключевых физических активах.

Ввод актива в DBB имеет три отдельных части.

а. Тип компонента - Тип компонента представляет собой спецификацию, которая описывает актив настолько подробно, насколько это возможно. Спецификация определит приемлемый диапазон значений для областей метаданных, которые являются ключевыми к обработке контента. Предполагается, что все компоненты, загружаемые в DBB должны быть приняты с Типами компонентов подобным способом в приеме материала в терминах производства. Например, Тип компонента, представляющий собой актив видео SD с технологией почтового ящика 16×9, имеет гибкие спецификации, которые позволят ограничить каждую основную область до значения, которое соответствует тому, что приемлемо для компонента. На фиг.16 показан список значений Формата изображения, до которых будет ограничен актив, если его будут рассматривать для этого типа компонентов. Такие определения технических данных будут распространяться на все значения метаданных инвентаризации, которые являются основными для обработки контента.

b. Требование к компонентам - Требование к компонентам (ТК) представляет собой запрос для специфического Типа компонента в рамках специфического Названия/Альфа. Предполагается, что ТК будут стимулировать создание и загрузку активов в DBB. ТК можно создать в результате Запросов (см. приложение 2 "Отношения между партнерами и клиентами") или можно создать в результате деятельности по планированию производства, где группа мастеринга будет выполнять ТК, необходимые для подготовки Названия/Альфа для распределения. Например, Театральная Альфа для Человека-паука 4 находится в производстве в период после кинопроката. Группа планирования определяет требование к видео активам для магистрали для восьми видео Компонентов. Они представляют собой видео активы с мастер-спецификацией DBB, изменяющейся по формату изображения и стандарту, каждый из которых необходим для поддержки производства DBB в основном направлении. Это приводит, в результате, к созданию восьми ТК, которые выполняет группа мастеринга. Когда активы созданы для спецификации компонентов и доставлены для загрузки, они будут приняты или отклонены перед загрузкой на основании проверки требований спецификаций. Сразу после принятия актив будет выполнять ТК.

с.Компонент (выполненный) - после того, как ТК выполнит принятие и подкачку, Компонент получит доступ к DBB для обработки. Как описано в приложении 5 "Мастер-данные технологического процесса", каждая спецификация по обработке контента позволяет идентифицировать один или более компонентов, которые требуются для создания конечного продукта. Только тогда, когда существуют выполненные Компоненты для конкретного Названия/Альфа можно выполнить спецификацию обработки контента.

Активы - Как описано выше, Активы медиа с богатыми возможностями в рамках магистрали представляют собой сущность(и) Компонентов. Активы поддерживаются с помощью независимых метаданных, которые являются общими в большинстве систем МАМ/РАМ. В DBB активы также связаны со специфическим компонентом, причем их подкачка была выполнена напротив. Метаданные Актива позволят DBB интерпретировать переменные для обработки контента, которые могут существовать между названиями.

Происхождение - необходимо для того, чтобы исходные активы были записаны во время кодирования и загрузки. Кроме того, необходимо записать эту информацию для того, чтобы создать новые Компоненты мастера в рамках DBB. Эта связь с информацией должна позволить пользователям отследить фактические активы, используемые для создания любого актива DBB обратно в кодированном физическом мастере или подкачанном файле.

Преемственность компонентов - Для того, чтобы сохранить однозначную инвентаризацию важно управлять заменой Компонентов и предотвратить проникновение копии в DBB. Когда созданы Требования к компонентам и существует актив, присутствующий в DBB под тем же самым Компонентом и Названием/Альфа, система будет управлять преемственностью путем идентификации копии и указания того, что технологический процесс требует разрешения.

3. Пользовательский интерфейс

Хотя DBB сопряжен с мастером Названия партнера для создания Названия/Альфа, ПИ DBB будет поддерживать непосредственное создание названий и связанных с ними Альфа. Следует отметить, что параметры, связанные как с Названиями (например, Тип названия) и Альфа (например. Формат изображения) необходимы для ввода через ПИ DBB.

Пользовательские интерфейсы, поддерживающие Альфа, требуют административных программ конфигурации, необходимых для создания типов Альфа. Эти типы допускают общие типы Альфа, такие как театральные или режисерская версия, которые будут стандартизированы и использованы для всех соответствующих названий. Эти административные программы допускают определение правил бизнеса, относящихся к концепции применимости к Территории и Рынку, описанным выше. Дополнительный уровень административных программ может быть необходим для создания шаблонов Альфа для общих правил бизнеса.

Создание спецификаций Тип компоненты тесно связано с приложением 5 "Мастер-данные технологического процесса" и могут содержаться в интегрированном пакете ПИ. Для этого ПИ требуется возможность создания записи, которая включает технические требования, причем источник медиа должен удовлетворять им для того, чтобы поддерживать назначенные технологические процессы. Эти записи связаны с технологическими процессами, создающими интегрированную инвентаризацию и информацию об обработке контента.

4. Услуги

DBB должен обладать открытыми услугами, допускающими сопряжение с мастером Названия партнера. Более конкретно, эти услуги для компании Сони поддерживают Название, Альфа и связанные с ними правила, которые описаны выше.

5. Интерфейсная система

Для осуществления планов компании Сони Пикчерс Интертейменд (Sony Pictures Entertainment) желателен интерфейс для GPMS (глобальная система мастера продуктов). DBB будет сохранять данные Названия/Альфа, которые необходимы для работы. DBB будет поддерживать интерфейс из GPMS для R1, но должна быть расширяемой до API, что позволят партнерам сопрягать данные названия в DBB. Интерфейс для системы GOLD (глобальный заказ и библиотечная база данных) будет необходим для того, чтобы обеспечить DBB видимостью Компонентов для основных физических активов. Для того, чтобы обеспечить видимость для дорогостоящих сценариев производства, это может быть необходимо для расширения видимости компонентов DBB для основных активов, таких как мастера видео высокого разрешения или дублированные языки аудио.

6. Мультипользователь

Каждый партнер владеет каким-либо количеством названий в рамках DBB. Инвентаризация отделена на основании организации Названий под каждым партнером. Пользователи должны спонсироваться Партнером и обеспечивают права для названий и связанными с ними активами на основании этого Партнера.

Приложение 5. Мастер-данные технологического процесса

1. Обзор

DBB поддерживает по возможности автоматизированный технологический процесс. Обзор современных процессов выполнения показывает, что некоторые процессы, решения, относящиеся к выбору активов источника, требования к обработке контента и даже упаковка могут регулироваться определенными правилами. Для других процессов может потребоваться вмешательство человека для уточнения неясностей. В условиях продолжающейся консолидации спецификаций, доставляемых Клиенту, и упрощение инвентаризации источника, разрешенной технологиями обработки контента, интернационализация правил, относящихся к технологическим процессам, становится возможной и все более желательной.

Кроме того, обеспечение точных деталей спецификации для автоматизированных систем обработки контента является необходимостью. Ошибки, внесенные моделью "выполнение на заказ", не поддерживают большую эффективность, предусмотренную в DBB. Создание, тестирование и реализация технологических процессов обработки контента с помощью инженерно-технического персонала обеспечивает превосходную платформу для последовательной работы. Возможность вызова этих технологических процессов через использование упрощенных правил предоставит эффективное разделение труда, которое позволит повысить как уровень обслуживания клиентов, так и обработку контента.

Мастер-данные технологического процесса обеспечивает метаданные вокруг технологических процессов, которые поддерживают планирование производства. Эти метаданные идентифицируют технологический процесс, необходимый для поддержки Спецификации клиента. Кроме того, требуемая информация о Наборе и Компонентах поддерживается вне данных технологического процесса для того, чтобы обеспечить эффективный опрос инвентаризации. С помощью этой информации поддержки, определение Спецификации клиента и требуемое Название/Альфа позволит механизму анализа производства определить соответствующие требования инвентаризации источника и технологические процессы, необходимые для создания Продуктов. Мастер-данных технологического процесса действует во взаимодействии с организацией метаданных инвентаризации (см. приложение 4 "Организация инвентаризации") для того, чтобы поддержать требования планирования производства (см. приложение 6 "Планирование производства").

Хотя желательно иметь полную информацию, гибкость в рабочей среде является также основным требованием. Услуги DBB и технологические процессы, которые координируют их, будут спроектированы по модульному принципу. Хотя технологические процессы могут координировать входные параметры, действия и выходы многочисленных услуг в сквозном процессе, они могут также обеспечить доступ к основным услугам DBB. Основными задачами являются операции, которые могут иметь требования к ПИ, которые не включают в себя производственный план. Эти задачи, такие как поиск и выборка файлов, транскодирование, пакетирование и другие должны выполняться на основе параметров, определенных пользователем. Это предоставляет рабочему персоналу возможность полного использования услуг DBB для того, чтобы иметь дело с временными или специальными технологическими процессами, которые нельзя полностью автоматизировать.

2. Описание

Фиг.17 изображает роль мастер-данных технологического процесса с помощью DBB. Затененные блоки представляют собой выборы, определенные запрашивающей стороной. Информация в незатененных блоках извлекается из инвентаризационных запасов DBB и мастер-данных Технологического процесса.

Технологические процессы - отношения объектов, показанные на фигуре 17, отображают подход к управлению метаданными, где основное требование заключается в разделении идентификации Контента и Клиента от определения производственного плана. Так как Запрашивающая сторона идентифицирует Профиль клиента, DBB может идентифицировать Спецификацию клиента. С помощью этой информации DBB может определить технологический процесс, который будет использоваться для создания доставляемого специфицированного продукта. Эти процессы будут создаваться и регулироваться с помощью административного персонала и будут проверяться через процесс адаптации.

Технологические процессы на основе спецификации клиента - планирование производства базируется на идентификации спецификации клиента и Названия и Альфа. Мастер-данных технологических процессов определяет технологические процессы, необходимые для завершения спецификации клиента и определяет требования к инвентаризации каждого технологического процесса. Эти данные позволяют выполнить сценарии "что если бы" через магистраль без контроля бизнес-правил самих технологических процессов.

Технологический процесс на основе спецификации клиента будет фактически представлять собой ряд технологических процессов, которые будут обозначены для соответствия состояния инвентаризации для данного Названия/Альфа. Например, технологический процесс, предназначенный для создания выходного результата MPEG2 8 Мбайт будет включать в себя этапы кодирования и подкачки мастер видео файла в случае, если этот файл не присутствует в рамках DBB. Если файл присутствует в DBB, эти этапы будут пропущены и технологический процесс начнется с этапа поиска файла.

Технологические процессы на основе ПИ, или Ключевые задачи - инструмент оркестровки технологического процесса будет ключевой точкой взаимодействия с услугами DBB. Хотя желательно, чтобы технологические процессы на основе спецификаций клиента были нормой для сценариев распределения, при этом все Ключевые задачи в пределах DBB должны быть доступны рабочему персоналу. Например, производственный план для MPEG2 8 Мбайт для клиента на немецком языке требует соответствующей и синхронизированной звуковой дорожки на немецком языке. Текущий набор, необходимый для обслуживания этой спецификации представляет собой отсутствующую дорожку. Вследствие срочного заказа, соответствующая и синхронизированная звуковая дорожка доставляется непосредственно рабочему персоналу, который затем выполняет Ключевую Задачу, предназначенную для того, чтобы дать возможность отыскать специфические файлы из DBB, выбрать и выполнить соответствующую спецификацию транскодирования, упаковать и доставить клиенту.

Ключевые Задачи будут конкретно предназначены для поддержки общих операций и будут поддерживать требования производства, которые нельзя автоматизировать на основании специфических потребностях бизнеса.

Оркестровка - Предполагается, что инструмент оркестровки технологического процесса будет использоваться для создания, управления и оркестровки задач, требуемых для выполнения технологических процессов. Этот инструмент должен учитывать включения и опрос бизнес-правил, которые могут представлять собой контент, клиента или иную специфику и которые будут материально влиять на то, как технологический процесс будет выполняться и/или какие задачи необходимы в рамках технологического процесса.

Вспомогательные данные - Технологические процессы будут управлять оркеструемыми Задачами и их подчиненностью. Эти технологические процессы будут взаимодействовать с вспомогательными данными, которые облегчат выбор инвентаризации и требования на выставление счетов и другие входы. Эти данные будут включать в себя, но не ограничивать нижеследующее.

Эти технологические процессы будут обычно включать в себя следующую информацию:

а. Задачи - Задача определена как любой этап в рамках технологического процесса, который требуется для продвижения от элементов мастера источника до доставки готового продукта клиенту. Эти задачи будут включать в себя Кодирование, Подкачку, QC, Транскодирование, Цифровые водяные знаки и т.д. Решение относительно оркестровки технологического процесса сделает возможным гибкое создание/конфигурирование задач, необходимых для поддержки как новых технологий обработки контента, так и расширенной автоматизации. Задачи представляют собой первичные компоновочные блоки оркестровки обработки контента. Каждая задача может быть ручной или автоматизированной и будет иметь статус и приоритет, связанный с ней. Смотри приложение 7 "Управление задачами" для полноты описания.

b. Операции по выставлению счетов - Выполняемая работа должна быть связана с услугами по выставлению счетов в рамках DBB. Операции по выставлению счетов будут содержать информацию, которая требуется для запроса информации о прейскуранте с помощью системы для выставления счетов. В приложении 13 "Финансовые процессы" описано как будут управлять Операциями по Выставлению счетов с помощью магистрали. Технологические процессы предназначены для обеспечения потребностей финансового отчета для того, чтобы можно было создать и получить отчет (или "статус") по операциям по выставлению счетов при завершении технологического процесса.

с. Комплекты - Компоненты, определенные для совместной работы (согласованной и синхронизированной), объединены вместе. Это позволяет мастер-данным технологического процесса указать Тип комплекта. Под Альфа комплект позволяет обеспечить специфическое подтверждение активов, которые будут работать вместе. Комплект может иметь один или более компонентов и один или более аудио компонентов, где любое аудио будет работать с видео в рамках этого комплекта. Мастер-данные технологического процесса (поддерживаемые спецификациями клиента) будут обрабатываться с изменчивостью, с которой аудио и вспомогательный материал используется из комплекта. Текущие активы АЛМАЗЫ (объединенные аудио и видео) представляют собой один комплект. Комплект может также включать в себя скрытые титры, субтитры или другие типы контента.

d. Типы компонентов - При необходимости введенные Типы компонентов, которые требуются для Задачи, должны быть идентифицированы. Эта информация поддерживает анализ инвентаризации активов, когда Название/Альфа точно определено в рамках запроса. Эта информация представляет собой основное требование для планирования производства и выполнения (см. приложение 6 "Планирование производства", приложение 7 "Управление задачами" и приложение 8 "Управляемая многоуровневая среда хранения").

Переменные технологического процесса - Технологические процессы позволяют обеспечить конфигурацию переменных для случаев обработки контента. Например, два видео актива для различных названий могут использоваться совместно с общим Типом компонентов. Однако метаданные уровня активов могут указывать на различия, которые будут воздействовать на обработку контента. Переменные в рамках Мастер-данных технологического процесса сделают возможным выбор Задачи обработки различного контента или набора или Задачи, основанной на различиях в двух файлах источника.

Схемы последовательности операций процесса, которые охватывают объем работы, управляемой с помощью Метаданных технологического процесса. Общие категории технологического процесса, представлены ниже:

а. Кодирование/Загрузка - ввод активов источника в DBB.

b. Преобразование продукта - автоматизированная и ручная обработка контента.

с.Создание метаданных - создание специфических метаданных Клиента.

d. Поиск вспомогательного медиа - ручной или автоматический поиск вспомогательных изображений, рекламных кадров сюжета и т.д.

е. Пакетирование - применение спецификаций пакетирования для Продукта, метаданных и вспомогательных медиа.

f. Доставка - доставка пакетов клиентам.

3. Пользовательский интерфейс

Создание и поддержка Мастер-данных технологического процесса имеет гибкий пользовательский интерфейс, который позволяет идентифицировать, включать и связывать в специфическом Технологическом процессе спецификации обработки контента. ПИ делает возможным создание записей, которые представляют собой технологические процессы, и должен связать каждый технологический процесс с соответствующими Спецификациями клиента и Типами компонентов (см. приложение 2 "Отношения между партнерами и клиентами"). Технологические процессы и связанные с ними мастер-данные должны легко копироваться и реконфигурироваться. Следует отметить, что в R1 не предполагается, чтобы информация об организации инвентаризации была полностью интегрирована с набором инструментов/услугами, которые поддерживают и выполняют мастер-данные технологического процесса.

Пользовательские интерфейсы Ключевых задач потребуют обеспечения прямого доступа к услугам в рамках DBB. Эти ПИ будут обсуждены более подробно в приложении 6 "Планирование производства", приложении 7 "Управление задачами" и приложении 8 "Управление многоуровневой средой хранения".

4. Услуги

Механизм планирования Производства будет осуществлять доступ к данным, но может выполнить это с помощью простых вызовов базы данных в зависимости от окончательных решений относительно архитектуры.

5. Мультипользователь

Совместное использование мастер-данных технологического процесса может иметь место для всех примеров Партнера, которые позволяют использовать многочисленным партнерам технологический процесс, который используется для общей доставки. Однако эта функция будет по своей природе административной. Как ПИ, так и уровни данных должны быть полностью разделены в примерах Партнера. Информация о прейскуранте, как указано выше, должна поддерживать изменение с помощью партнера, а также, возможно, с помощью специальных норм сделок.

Приложение 6. Планирование производства

1. Обзор

Автоматизация технологического процесса должна поддерживаться с помощью мастер-данных, как описано в приложении 4 "Организация инвентаризации" и приложении 5 "Мастер-данные технологического процесса". Эти разделы и их требования описывают мастер-данные, которые поддерживаются в течение всей инвентаризации и технологических процессов обработки контента. DBB будет использовать эти мастер-данные для создания специфических производственных планов в ответ на запросы из модуля поддержки запросов. Эти производственные планы представляют собой набор основных инструкций для оркестровки обработки контента и будут вырабатывать точки информации, которые необходимы для оценки себестоимости и времени выполнения заказа.

Хотя желательно создать и выполнить производственные планы без вмешательства пользователя, понятно, что оперативное манипулирование этими планами будет необходимо в необычных случаях. Этот уровень информации и вычислительные способности должны оставаться гибкими для того, чтобы можно было поддерживать высокие темпы оперативного вмешательства в начале срока службы DBB и, поскольку эти темпы снижаются, также поддержать высокие темпы полностью автоматизированного планирования.

2. Описание

На фиг.2 изображены объекты и процессы, необходимые для создания производственного плана в DBB. Механизм анализа производства использует Мастер-данные технологического процесса и Данные вспомогательной инвентаризации, описанные в приложении 4 "Организация инвентаризации" и приложении 5 "Мастер-данные технологического процесса", наряду с вводом из модуля запросов, который описан в приложении 2 "Отношения между партнерами и клиентами". С помощью спецификации клиента механизм может идентифицировать соответствующий требуемый технологический процесс.В рамках технологического процесса определены все Задачи, необходимые для создания спецификации клиента. Кроме того, все необходимые типы компонентов для каждой задачи определены там, где это возможно. С помощью этой информации, механизм сначала выполняет Анализ материала. DBB запрашивает инвентаризацию DBB для необходимых компонентов для специфицированного Названия/Альфа и Спецификации клиента. Результаты этого анализа определяют Задачи, которые необходимы для завершения требуемого Технологического процесса.

Как описано в приложении 5 "Мастер-данные технологического процесса", Спецификация клиента, основанная на технологических процессах, должна отвечать за все возможные сценарии инвентаризации. Эти технологические процессы должны охватывать кодирование и подкачку необходимого компонента инвентаризации через доставку. Они могут быть по своей природе модульными и обеспечивать гибкость для обработки сценариев, где необходимая инвентаризация находится на более высоких стадиях готовности. Механизм планирования производства будет выполнять Анализ материала для того, чтобы определить специфические технологические процессы, необходимые для создания необходимого Продукта.

Технологический процесс DBB может включать в себя транскодирование файла с более высоким разрешением в файл с более низким разрешением, который затем пакетируется и доставляется. Операции DBB могут создавать файл с низким разрешением и хранить его в системе хранений файлов DBB в качестве мастера альтернативного разрешения с ограниченным использованием. В этом случае технологический процесс потребует запроса инвентаризации, определение того, что файл с более низким разрешением присутствует, и скорее закрытие альтернативного технологического процесса для копирования и доставки файла с более низким разрешением, чем транскодирование из файла с более высоким разрешением. Например, для «Человека-паука 3», файл формата MPEG2 8 Мбайт был создан и сохранен в системе хранения файлов. В рамках требуемого технологического процесса будут необязательны Задачи для кодирования загрузки, поиск и транскодирование файла мастера видео в файл 8 Мбайт, так как уже существует мастер альтернативного разрешения с ограниченным использованием 8 Мбайт. В этом случае, технологический процесс будет укорочен. Для «Человека-паука 4» может потребоваться весь технологический процесс от Кодирования с упреждением, так как файл для альтернативного использования не существует.

В зависимости от детального проектирования, может потребоваться перезапуск производственного плана с учетом стоимости и времени выполнения заказа перед выполнением действующих Технологических процессов. Причиной этому является динамический характер инвентаризации активов. Производственные планы могут привести к расходам основных фондов для Партнеров, и, в результате, перед выполнением может потребоваться дополнительное разрешение. В период утверждения могут изменяться условия в рамках DBB. Может произойти подкачка необходимого мастер-файла, или существующий мастер-файл можно разместить в QC HOLD. В результате, предварительный анализ может привести только к оценке себестоимости и времени выполнения заказа, который будет использоваться для целей СОРА вне DBB (см. приложение 13 "Финансовые процессы"). После утверждения Механизм анализа производства запустит второй анализ, проверку для существенных изменений и, если их нет, выполнение производственного плана.

Оценка себестоимости - Как описано в приложении 5 "Мастер-данные технологического процесса" и приложении 13 "Финансовые процессы", DBB будет сопряжена с системой выписки счетов, которая будет хранить прейскуранты. Операции по выставлению счетов будут использовать данные Прейскурантов для того, чтобы облегчить расчет цен. Когда Производственный план создан, сбор переменных, необходимых для вычисления цен, производится на основании результатов анализа материалов, и ценообразование определяется в качестве определенного с помощью идентифицированных Технологических процессов. Эта информация будет зарегистрирована для использования в утвержденном технологическом процессе.

Оценки времени выполнения заказа - Время выполнения заказа для каждого процесса должно быть оценено, и должно быть разработано общее время выполнения заказа для Технологического процесса. Способ вычисления еще не известен. Планирование правильной производительности может быть за пределами первоначального объема DBB. Однако считается, что анализ последних исторических данных можно использовать для оценки времени выполнения заказа.

Взаимодействие модуля запросов - Эта информация будет представлена Запрашивающей стороне для утверждения. Время выполнения заказа будет сравниваться со сроком выполнения для сигнализации любых потенциальных конфликтов или необходимости установления более высоких приоритетов. Затраты будут приемлемыми и позволят пользователю инициировать технологический процесс Утверждения.

Версия и модификация производственного плана - Производственный план будет состоять из Требований к компонентам источника, операций по выставлению счетов, оценок времени выполнения заказа и требуемого производственного процесса. Необходимо, чтобы производственный план был проверен с помощью бизнес-правил, которые могут отметить его для ручного просмотра и выпуска с помощью рабочей группы DBB. Это может быть основано на существовании определенных задач, или может быть отмечено на уровне запроса, исходя из особых обстоятельств. Правила для оперативного просмотра производственных планов должны быть гибкими и конфигурируемыми. Этот этап требуется для того, чтобы план можно было модифицировать с помощью рабочей группы DBB для того, чтобы отвечать за уникальные или определенные обстоятельства. Например, заданный технологический процесс позволяет специфицировать конкретную компоненту источника. Однако, в случае утверждения клиентом, необходимо использовать другой файл источника с более низким качеством. Эти альтернативные файлы источников присутствуют в DBB. Запрос отмечается для действующего просмотра, и во время этого процесса, активы источника в рамках плана модифицируются. Сразу после завершения модификации, План выпускается для выполнения.

3. Пользовательский интерфейс

Один или более ПИ необходимы для поддержки просмотра, модификации и версии производственных планов перед утверждением COFA. ПИ будут также необходимы для модификаций операций по выставлению счетов перед и после утверждения COFA. См. приложение 13 "Финансовые процессы" для полного описания требований к операциям по выставлению счетов.

4. Услуги

Данные уровня запросов можно представить на рассмотрение через веб-услугу. Затем, механизм анализа производства может выработать необходимую информацию и отреагировать на запрос. См. приложение 13 "Финансовые процессы" для возможных услуг между DBB и перечисленными опциями Системы для выставления счетов.

5. Интерфейсные системы

Процесс анализа производства может потребовать запросы в системах поддержки, таких как GOLD Сони и/или приложения CineShare (Киносовместное использование) для того, чтобы определить возможность использования инвентаризации.

6. Мультипользователь

Нагрузка уровня и установление приоритетов Задач между партнерами желательны для того, чтобы поддерживать постоянную производительность.

Приложение 7. Управление задачами

1. Обзор

DBB требует возможности оркестровки Технологических процессов, которые определены Мастер-данными технологического процесса. Производственные планы предусматривают сборку, оперативную модификацию/проверку, утверждение и предоставление технологических процессов для выполнения. Сразу после подачи документов, функция управления задачами взаимодействует с уровнем услуг DBB, представляя на рассмотрение Задачи, получая ответы, обновляя, регистрируя и, при необходимости, уведомляя.

Технологические процессы и их соответствующие Задачи управляют Загрузкой Компонентов источников в DBB. Кроме того, DBB имеет видимость в ключевых Компонентах физической инвентаризации, и Управление технологическим процессом продлевает уровень связи до ручного мастеринга или деятельности по исследованию/поиску активов. В рамках этого широкого охвата, предполагается, что любую задачу можно будет сконфигурировать для предоставления инструкций по ручному технологическому процессу провайдеру DBB или продавцу.

Анализ стоимости и эффективности технологии определяет степень, до которой можно автоматизировать любой процесс. Основное требование состоит в том, чтобы статус Задач и их взаимозависимости для всех технологических процессов от создания основных физических активов до подтверждения доставки были видны в рамках DBB.

2. Описание

Производственный план вырабатывается в случае, когда инициируется заказ в DBB (см. приложение 6 "Планирование производства"). После утвержденной подачи документов, производственный план будет передавать задачи в функцию Управления очередью. Обработка задач технологического процесса и их состава описана в функциональном группировании, показанном на фиг.18. Технический состав этих функций может изменяться в зависимости от детальной конструкции и проблем реализации.

Задачи технологического процесса - Как обсуждено в приложении 6 "Планирование производства", производственный план включает в себя Технологические процессы, необходимые для того, чтобы выполнить Утвержденный запрос.В любое время многочисленные производственные процессы могут находиться в ходе их выполнения, многие из которых требуют подобных задач, которые будут завершаться с помощью одинаковой услуги DBB. Для того, чтобы управлять очередями, приоритет управления и видимость обеспечения в статусе Задач технологического процесса должны материализоваться в рамках DBB. Задачи технологического процесс добавляются в соответствующие очереди с помощью инструмента оркестровки технологического процесса. Данные поддерживаются в рамках этих задач, относящихся к статусу, порядок обработки, время начала и окончания и оперативная информация, необходимая для определения характера задачи и его исходного Технологического процесса и Запроса.

Приоритет - Приоритет уровня запроса может быть назначен в модуле запросов на основании конфигурируемого пользовательского полномочия и/или конфигурации Партнера. Приоритет уровня Запроса можно изменить во время этапа модификации производственного плана, описанного в приложении 6 "Планирование производства". Приоритет можно модифицировать на уровне Название/Альфа, позволяющим пользователям назначить приоритет одному или более элементам строки в рамках Запроса, иначе, чем другие. Приоритет уровня задачи технологического процесса можно также модифицировать в рамках функции управления очередью задач, описанной ниже. Взаимозависимости задач представляют собой набор, основанный в рамках управления Технологическим процессом.

Конфигурация задач технологического процесса - Задачи технологического процесса управляют выполнением различных услуг, присутствующих в рамка DBB. Хотя можно назначить приоритеты задачам технологических процессов, анализ порядка выполнения Задачи выполняется на уровне услуги для того, чтобы все Задачи, которые образуют очередь с заданной услугой, обрабатывались в порядке приоритета. Конфигурация Задачи поддерживает контроль порогов, которые позволяют функциям Управления задачами выполнять анализ и составлять отчет по последним задачам или задачам, которые с их времени начала превысили установленную продолжительность. Категории задач включают в себя, но не ограничивают следующее:

а. Ручное управление задачами - ПИ задач DBB позволяет поддерживать связь ручных задач с провайдерами услуг Партнер/Продавец DBB. Этот ПИ, подключенный к всемирной паутине веб, обеспечивает информацию об очереди работ относительно задач, которые будут выполняться при поддержке технологического процесса DBB. Например, этот портал обеспечивает возможность перемещения файла, облегчая доставку активов для ввода в DBB. Этот тип задачи также облегчает нефинансовый обзор и утвержденный технологический процесс. Предполагается, что уведомление об электронной почте будет сконфигурировано с возможностью поддержки этих процессов.

b. Управление технологическим процессом кодирования/подкачки - Требуются все Задачи, необходимые для ввода активов в DBB, включающие в себя Создание запросов, Компоненты, Кодирование, Регистрацию и Подкачку, как описано в приложении 10 "Управление подкачкой/кодированием". Несколько из этих задач можно оркестровать через управление ручными задачами, описанными выше.

с. Доставка файла внешней ссылки и поиск соответствующих компонентов - Для того, чтобы поддерживать внешнее создание согласованных активов, файлы ссылок на аудио или видео можно доставить продавцу с сопроводительным URL, который будет использоваться для доставки. Это является предлагаемой поддержкой технологического процесса, которая будет обеспечивать структуру для создания согласованных/синхронизированных компонентов.

d. Интеграция внешних веб-услуг - DBB поддерживает интеграцию веб-услуг с внешними системами для многочисленных целей. Основной целью, предусмотренной для первоначального выпуска, является поиск изображений, рекламных кадров сюжета, метаданных уровня Названия и других требований к пакетам из CineShare (Киносовместное использование), GOLD GPMS для R1 и для других третьесторонних систем последних выпусков.

е. Управление файлами - Задачи управляют поиском и перемещением файлов в и из системы хранения DBB и поддерживают удаление файлов из памяти WIP на основании политики и требований к технологическому процессу.

f. Обработка контента - взаимодействие со всеми идентифицированными видами устройств обработки контента.

g. Пакетирование - выработка пакетных метаданных на основании спецификации заказчика и создания Пакетов для доставки.

h. Доставка - доставка пакетов Клиентам с помощью идентифицированных способов.

Финансовое обновление - любой технологический процесс можно выполнить с возможностью обеспечения статуса и/или других необходимых данных для облегчения финансовых процессов (см. приложение 13 "Финансовые процессы").

Статус запросов - технологические процессы должны обеспечивать продвижение задач в Запросы, как предписано бизнес-правилами технологического процесса.

Следующие функции могут быть внедрены в рамках инструмента оркестровки технологического процесса, но требуют управления производительностью задач через DBB.

Управление очередью - Функции управления очередью контролирует и поддерживает производительность различных очередей в рамках DBB и определяет порядок выполнения на основания приоритета и зависимости. Эта функция управляет скоростью/потоком задач через взаимодействие с уровнем услуг DBB.

Обновление задач - Уровень услуги DBB обеспечивает статус для каждой Задачи. После получения статуса, функция Обновление задач обновляет задачи в соответствующем статусе и обеспечивает функции регистрация и уведомления.

Контроль задач - Эта функция контролирует все функции управления Задачами и очереди, обеспечивающие отсчет ошибок, аналитику времени обработки и, в общем, поддержку целостности обработки очередей.

ПИ действующий для управления задачами - В качестве администратора DBB требуется управление технологическими процессами и их задачами, которые являются как ручными, так и автоматизированными. Управление приоритетами и порядок задач представляет собой использование одного из администраторов основных функциональных возможностей для сохранения эффективного управления цепочкой доставки контента.

Уведомление - уведомление Электронной почты конфигурируется на уровне Задач. Эти уведомления направляются с помощью правил на основании оперативных потребностей или с помощью потребностей Запроса (Уведомление Запрашивающей стороны/Клиента).

Ключевые задачи - Как описано в приложении 4 "Мастер-данные технологического процесса", Ключевые задачи представляют собой технологические процессы, которые можно выполнить непосредственно с помощью рабочего персонала. Эти технологические процессы требуют ПИ, который обеспечивает прямой ввод входных параметров. ПИ требует прямой идентификации инвентаризации источника для обработки в рамках Ключевой задачи. Некоторыми примерами Ключевых задач являются поиск файла, обработка контента и доставка, и они могут включать в себя любую деятельность, связанную с обработкой контента.

3. Пользовательский интерфейс

ПИ, действующий для управления задачами, обеспечивает передовые способы просмотра и анализа рабочего персонала. Задачи можно выполнить с уровнями допуска, которые после превышения, инициируют предупреждения и затем проверяются для операций. Выбор и просмотр задач с помощью различных критериев, таких как тип задачи, технологический процесс, конгломерат устройств обработки контента Клиент, Партнер или Запрос будет необходимы для того, чтобы быстро идентифицировать и решать проблемы.

Ключевая задача ПИ опирается на модульность технологических процессов и обеспечивает прямой доступ к входным параметрам. Эти программы могут работать с подобным шаблоном, как поиск инвентаризации, причем идентификация и поиск являются общими для большинства Ключевых задач. ПИ дополнительных технологических процессов можно прикрепить к этому базовому ПИ.

4. Услуги

Инструмент оркестровки технологического процесса можно использовать для взаимодействия с уровнем услуг DBB, предоставляемыми на рассмотрение задачами, особыми ситуациями управления, регистрации, уведомления и т.д. Этот инструмент требует разнообразия услуг для того, чтобы выполнить приведенные выше задачи.

5. Интерфейсная система

Эталонная архитектура изображает все запланированные интерфейсы для R1, но управление задачами может также граничить с CineShare для поиска изображения, рекламных кадров сюжета и других медиа с отсутствием богатых возможностей, а также в GPMS для метаданных уровня Названия. Для процессов, управляющих финансовыми операциями, и для видимости инвентаризации DBB граничит с реализацией XytechCoHH, GOLD.

6. Мультипользователь

Предпочтительно, чтобы ПИ управления технологическими процессами и задачами и услуги были одним примером и версией, хотя бы групповой и имели бы возможность распределения. Это позволяет DBB устанавливать приоритеты работ для многочисленных Партнеров для отдельных наборов оборудования для обработки контента в случаях, где набор оборудования выделен одному Партнеру или совместно используется среди многочисленных Партнеров. Правила технологического процесса учитывают различное поведение, основанное на поведении Партнера, который инициировал Запрос.

Приложение 8. Управляемая многоуровневая среда хранения

1. Обзор

DBB требует возможности управления и хранения большого количества данных в цифровом запоминающем устройстве. Цифровые файлы могут представлять собой видео, аудио, изображения, текст или любой другой тип медиа, который можно пакетизировать для распределения клиенту DBB. Учитывая текущие расходы на хранение и ожидаемый объем/размер файлов, предполагается, что система хранения, которая включает в себя управляемую многоуровневую среду хранения (MMSE) будет нормой. Она должна предусматривать центральный пункт хранения, который является более экономичным, чем полностью решение в режиме прямого доступа, так как файлы можно хранить на изменяющихся уровнях/типах запоминающего устройства.

2. Описание

Поскольку DBB имеет цифровое хранилище файлов, потребуются услуги, которые относятся к управлению файлов. Одно такое устройство представляет собой услугу загрузки/подкачки (см. приложение 10 "Управление подкачкой/кодированием"). Для того, чтобы заполнить DBB файлами, процесс подкачки необходим для перемещения файла из внешнего источника в локализованный элемент запоминающего устройства DBB. Все файлы должны быть перемещены в запоминающее устройство Уровня 1 после первоначальной загрузки до тех пор, пока утвержденный запрос на услугу не будет выработан для перемещения файла в запоминающее устройство WIP, или политика не переместит файл на другие уровни в рамках MMSE.

Другой необходимой услугой DBB является процесс поиска В процессе производства (WIP). Для того, чтобы поддержать услуги обработки контента, файлы, постоянно хранящийся в MMSE, будут сначала необходимы для копирования в области запоминающего устройства WIP, где они непосредственно получат доступ к услугам обработки контента (например, транскодированию и пакетированию). Установка этого файла в запоминающее устройство WIPDBB должна быть выполнена сразу после полного утверждения Порядка работы и добавления задачи производственного плана по обслуживанию контента в очередь для обработки.

DBB должна быть осведомлена о каждом элементе файла независимо от того, на каком уровне запоминающего устройства он существует.DBB должна быть осведомлена о том, какие файлы требуются в своей очереди производства для того, чтобы уменьшить необязательную ленточную активность (то есть, если конкретный файл источника будет затребован по заказу №12, и тот же самый файл был затребован по заказу №215, политика удаления должна принять во внимание второй заказ).

Для того, чтобы поддержать емкость внутри запоминающего устройства WIP, необходимо установить политики сохранения и удаления. Эти политики удаления будут уникальны для запоминающего устройства WIP и могут быть основаны на нескольких основных факторах, включающих в себя следующее:

а. Окончание срока - После того, как файл был обслужен, и утвержденные производственные задачи, не находящиеся в режиме ожидания, требуют использования этого файла, следует активизировать события удаления, спланированные по времени. Это спланированное по времени событие может, например, установить, что после 30 дней файл оставался нетронутым, и файл следует удалить.

b. Типы статуса заказа работы - Завершение события обслуживания можно идентифицировать с помощью пары различных типов заказов работы, и можно запустить анализ политик сохранения (то есть, более вероятный запуск истечения срока). Тип заказа работы "Отмена", показывает, что работа больше не будет продолжаться и, следовательно, файл больше не нужен для завершения работы. Во-вторых, статус заказ работы "Завершение" будет показывать, что вся деятельность, включающая в себя доставку и получение цифрового контента, была завершена. Следует отметить, что другие типы заказов работы можно идентифицировать для запуска завершения на обслуживания, и они должны быть конфигурируемыми в рамках приложения.

с. Незавершенная утвержденная задача обслуживания - В любой момент времени утвержденная задача производства/обслуживания, требующая использования существующего файла, постоянно хранящегося в запоминающем устройстве WIP, может сбросить счетчик окончания срока. Затем этот файл будет оставаться в запоминающем устройстве WIP, не заботясь об удалении, до тех пор, пока не будет назначен приоритет для задачи, и она не будет выполнена.

d. Метаданные файла - Управлять политиками сохранения можно с помощью метаданных, связанных с файлом. В этом примере, анонсы или другие медиа могут иметь более продолжительную политику сохранения, чем продолжительное по форме видео. Использование этого может быть многочисленным, но политики окончания/сохранения должны иметь возможность использования метаданных файла, в качестве критерия. Следует отметить, что только компоненты имеют возможность использования этой особенности, так как они имеют необходимые метаданные.

DBB использует решение MMSE для обеспечения рентабельного масштабированного решения для хранения своего цифрового контента. Индустрия развлечений и медиа работает с большими файлами, потенциально превышающими 500 гигабайтов на файл в зависимости от кодирования/скоростей передачи битов/времени выполнения. По этой причине себестоимость и масштабируемость являются наиболее важными. DBB требует использования стандартных функциональных возможностей MMSE, включающих в себя возможность перемещения файлов между уровнями хранения (например, режим доступа по запросу → режим прямого доступа, режим отсутствия доступа → режим прямого доступа), а также установка запланированных правил поддержки файла в рамках решения MMSE для оказания помощи с возможностью планирования. Уровнями хранения для DBB являются: Уровень 1a - режим прямого доступа - быстро вращающийся диск; Уровень 1b - Режим прямого доступа - медленно вращающийся диск; Уровень 2 - Режим доступа по запросу - Библиотека лент с автоматическим поиском; Уровень 3 - Режим отсутствия доступа - Вне библиотеки лент с ручным поиском. См. фиг.19 для более подробной информации.

Правила управляют контентом на глобальном уровне в DBB. Правила устанавливают для планирования перемещения файлов между уровнем хранения на основании типа файла/компонента. Каждый тип файла/компонента устанавливают с длительностью окончания для каждого уровня хранения, а также с цифровым водяным знаком высокого качества использование диска. Предполагается, что эта функциональная возможность будет расширяться через пользовательский интерфейс для модификации путем предпочтения Партнера.

Одна область в пределах Уровня 1 Системы хранения должна быть выделена запоминающему устройству "Процесса производства" (WIP) и управляться с помощью DBB. Запоминающие устройства WIP используются различными услугами обработки контента, такими как Транскодирование. Хотя оборудование, используемое для этих услуг периодически сначала перемещает контент в локальное запоминающее устройство перед обработкой данных, надеждой является уточнение времени обработки путем устранения потребности перемещения этих больших мультигигабайтовых файлов между складами данных. Для успешного выполнения требуется очень высокая скорость соединения между запоминающим устройством Уровня 1 и серверы для обработки контента.

MMSE интегрируются с услугами управления инфраструктурой для обеспечения более активной обратной связи относительно работоспособности MMSE. Эти услуги также интегрируются с другими аппаратными средствами DBB (например, с серверами для обработки контента) для оказания помощи в оценке ЦПУ, Полосы пропускания и других критериев для того, чтобы помочь DBB лучше оркестровать их услуги и администраторов предупреждений о возможных проблемах.

Решение MMSE учитывает ряд правил относительно контента, хранящегося на ленте: Возможность предотвращения распространения активов через многочисленные ленты за исключением абсолютно необходимых для хранения актива (то есть, актив превышает размер целой пустой ленты в пуле); возможность разделения по типам контента на лентах (то есть, выбора для того, чтобы только иметь определенные типы элементов, сгруппированных на лентах), тем самым предотвращая необходимость иметь несовместимые ленты, заполняющие места для лент для простого доступа к одному маленькому элементу. Возможность иметь многочисленные копии лент для DR для того, чтобы иметь место во время простоя и в специфических окнах технического обслуживания.

3. Пользовательский интерфейс

В зависимости от конструкции может быть маленькая потребность в интерфейсе конечного пользователя. Существует ожидание того, что системные администраторы будут иметь возможность установки правил по умолчанию для управления медиа через окружающую среду DBB. Поскольку эти элементы управления доступны только для администратора, эта функциональная возможность не имеет строгих нормативов для пользовательского интерфейса и, главным образом, предполагается использование функциональной возможности готового решения. Однако возможны некоторые особенности, которые показывают через интерфейс для партнеров DBB. Например, в зависимости от предпочтений Партнера, определенные собственники контента могут требовать, чтобы весь контент оставался в запоминающем устройстве в режиме прямого доступа, а не перемещался в запоминающее устройство в режиме отсутствия доступа или в режиме отсутствия доступа. Соответственно, могут потребоваться определенные "горячие названия" для того, чтобы оставаться в режиме прямого доступа в течение более длительных периодов времени, чем стандартные названия. Путем установки этих предпочтений, DBB будет иметь возможность взаимодействия с MMSE для передачи значений/параметров, которые делают решения возможными.

Большая часть деятельности по управлению файлов должна быть бесшовной для конечного пользователя DBB и не требует пользовательского интерфейса. Перемещение файла между уровнем в рамках MMSE и перемещение в запоминающее устройство WIP следует проводить автоматическим способом. Только информация, которой пользователь должен быть осведомлен, представляет собой ожидаемое время обработки, которое требуется для подготовки (например, перемещения в обстановку подготовки производства), и обслуживание файла (например, преобразование). Один сценарий, где предполагается пользовательский интерфейс, служит для загрузки/подкачки вспомогательных медиа. Следует также отметить, что существует несколько механизмов для закгрузки/подкачи, FTP, загрузки на основе веб и других инструментов доставки (например, Aspera, Signiant).

4. Услуги

Существуют некоторые особенности MMSE, которые должны проявляться в DBB в виде услуги. Особенности, которые, как предполагается, будут проявляться в виде услуги, представляют собой следующее:

а. Перемещение файлов между уровнями хранения

b. Установка политик истечения срока на основе метаданных (правила перезаписи по умолчанию).

Всей деятельностью управления файлов следует управлять через услуги, предусмотренные в DBB. Для обработки требования управления файлом, обсужденных ранее в этом разделе, необходимо представить следующие услуги:

а. Услуга загрузки файла - Эта услуга должна перемещать файл из местоположения, точно определенного партнером, в запоминающее устройство уровня 1 для специфического разделения домена Партнера. Вход в эту услугу следует точно определить, если имя файла должно оставаться тем же самым или следовать выражению преобразования имени файла.

b. Поиск файла в услуге WIP - Эту услугу следует принимать в виде ввода указателя файла, точно определяющего файл, который будет перемещаться, и полученное в результате местоназначение файла. Местоназначение будет представлять собой раздел клиента запоминающего устройства WIP.

с. Услуга ручного удаления - Эту услугу следует принимать в виде ввода указателя файла. В случае партнера, инициирующего вручную запрос удаления своего контента, эта услуга должна удалить все соответствующие контенты, постоянно хранящиеся в 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 по многочисленным различным причинам. Ниже представлен список предполагаемых особенностей поиска, задаваемого конечным пользователем:

а. Поиск Названия/Альфа - используется партнерами для выбора соответствующего запрашивающего Названия или Названия/Альфа. Это запрашивает интерфейс в системе управления названием/IP партнера и запрашивает многочисленные входные критерии, включающие в себя, но не ограничивающие следующее:

а. Название (полный текстовой поиск по групповым символам);

b. Тип названия (например, особенность, эпизод) - управляемый список значений;

с.Поиск спецификации - используется с помощью администраторов DBB для нахождения соответствующей спецификации. Спецификации содержат большое количество подробностей, где различия между спецификациями могут быть очень минимальными. Способность быстрого поиска и фильтрация спецификаций для нахождения точного совпадения очень важна, поэтому используются соответствующие спецификации.

d. Поиск компонентов - используется Партнерами для исследования компонентов, существующих в DBB. Компоненты содержат многочисленные области метаданных, уникально описывающих каждый компонент. Механизм поиска компонентов должен обеспечивать возможность сквозного поиска всех областей метаданных и фильтрацией результатов для уникальной идентификации точного совпадения компонентов.

е. Поддержка поиска материалов - используется Партнерами для поиска вспомогательных материалов, добавленных в DBB. Эти вспомогательные материалы имеют минимальные метаданные по сравнению с Компонентами. Уровень метаданных зависит от того, как хранилище документов управляет этим типом медиа. Минимальный поиск должен включать в себя любые доступные метаданные, такие как имя файла и структуры директории папки.

f. Поиск Профиля клиента - используется Партнерами для поиска соответствующего профиля запроса. Эту функциональную возможность можно достигнуть через текстовой поиск или просмотровый поиск, где партнер может осуществлять навигацию Профилей клиента через иерархию (например, Клиент > Профиль клиента).

g. Поиск Клиента - используется Клиентом для выбора Клиента для выполнения. Это должен быть простой текстовой поиск по именам Клиента или особенностью просмотра для прокрутки через имеющихся Клиентов в рамках DBB.

h. Поиск запроса - используется запрашивающими сторонами для нахождения исполняемых в текущий момент времени или представленных запросов.

i. Поиск производственного плана - используется операторами или запрашивающими сторонами, когда производственные планы определяются/создаются, а также после представления, которое произойдет на уровне Технологического процесса и Задачи (особенно по статусу).

Поиски, управляемые системой проводятся с помощью DBB для выполнения своего построения по признакам. Лучший пример этого позволяет объяснить с помощью просмотра функциональной возможности производственного плана DBB. Например, для выработки запроса. Партнер точно определяет Название/Альфа и Профиль клиента для доставки. Учитывая этот ввод, DBB должна проводить сквозные поиски существующих компонентов, как файла, так и физических, и следовать многочисленным бизнес-правилам. Эти поиски должны конфигурироваться администраторами системы и выполняться после оценки производственного плана.

Ниже приведен список предполагаемых поисков системы DBB:

а. Поиск компонентов - запросы, проводимые DBB для нахождения компонента, более всего соответствующего заданному числу критериев метаданных. Данные, предоставленные в виде входных данных для поиска, могут быть извлечены из многочисленных источников, но обычно приводятся с помощью Запроса и связаны с ним информацией. Входные данные включают в себя, но не ограничивают следующее:

- ID Названия - это данные Партнера в процессе Запроса.

- Альфа - это данные, выбранные партнером в процессе Запроса.

- ID Партнера - Это следует использовать в качестве фильтра для специфического поиска Компонентов, созданных специфическим партнером. Следует отметить:

Компоненты не используются совместно партнерами.

- Дополнительные метаданные спецификации - это данные, точно определенные в Спецификации, связанной с Профилем клиента. Эта информация будет известна в качестве запроса, который будет требовать Партнер для выбора Профиля клиента. Информация об образцовой спецификации будет включать в себя технические метаданные, такие как скорость передачи битов и форма.

3. Пользовательский интерфейс

Независимо от дизайна некоторые входные данные для критериев поиска требуют ввода конечного пользователя. Такой интерфейс должен требовать по возможности минимального взаимодействия с пользователем. В зависимости от экрана ПИ, несколько концепций дизайна должны, по возможности обеспечить эффективный ПИ. Для всех типов поиска должно быть доступно использование "специальных символов" или частичное совпадение (например, "Пау" возвращает результаты для всех результатов "Человек-паук").

а. Базовый поиск - наиболее распространенный поисковый интерфейс, где одно текстовое окно используется для ввода текста, но поиск осуществляется по ряду предопределенных областей.

b. Расширенный поиск - поиск по источнику(ам) данных путем назначения параметров поиска для ряда областей метаданных перед выполнением для создания более определенных критериев поиска (например, диапазоны данных, мультивыбор).

с. Поиск на основе фасетов - опция поиска, которая предусматривает дополнительный, относящийся к данному вопросу атрибут, позволяющий фильтровать наборы результатов динамическим способом. Подсчет полученных результатов должен быть указан рядом с каждый "фасетом".

d. Уточнение поиска - возможность поиска в рамках критериев добавления наборов возвращенных результатов для того, чтобы уточнить результаты.

е. Предложения - возможность для нечеткого совпадения или логики, характеризуются логикой типа "Вы имели ввиду..." в идеале, будет доступен индекс, основанный на «опережающих» предложениях.

f. Навигация по результатам - возможность перемещения по набору результата Поиска с помощью определенной таксономии/группирований.

Результаты поиска должны возвращаться в набор, который можно просмотреть в полном объеме или с использованием методики нумерации страниц. Кроме того, если набор результатов превысил порог, который будет определен, система предложит пользователю уточнить свои критерии поиска.

Кроме того, скорость быстрота реагирования услуг Поиска имеет решающее значение для практичности и эффективности DBB.

4. Услуги

Для того, чтобы разрешить поиск во внутренней и внешней системах, должны быть созданы услуги поиска и необходимо подвергнуть воздействию DBB для каждого внешнего/внутреннего источника данных. Причина для воздействия на эти поисковые интерфейсы в виде услуг состоит в том, что интерфейсы будут скорее всего использоваться в многочисленных сценариях для различных целей во всей DBB. Путем создания общих услуг, их будет гораздо легче использовать для каждого источника данных, услуга должна подвергаться воздействию для запроса каждого типа данных. Кроме того, это могут быть запросы, которые будут создавать индексы, которые охватывают источники данных и услуги для того, чтобы обеспечить необходимое время отклика.

Услуги должны быть расширяемыми для выполнения запросов и поиска данных всех доступных метаданных для конкретного типа данных (обеспечение безопасности). Например, если услуга создается для выдачи запроса внешней системе управления интеллектуальной собственностью (например, GPMS для компании Сони), ввод должен быть интеллектуальным достаточным для обеспечения многочисленных критериев для ввода (например, Имя Названия и Тип Названия). Услуга должна также обеспечить средства точного определения областей метаданных, желаемых для вывода (например, Названия, Год).

5. Интерфейсные системы

Предполагается, что несколько систем/подсистем будут выполнять запросы для обеспечения совместного использования данных. Некоторые идентифицируемые системы представляют собой следующее:

а. Управление медиа-активами - внутренняя подсистема управления медиа-активами DBB и составляющие услуги, необходимые для выполнения запросов при проведении анализа материалов для оценки производственного плана.

b. Управление GOLD/Активами - система DBB нуждается в интерфейсе с внешней существующей системой управления активами, GOLD для источников для поиска метаданных активов во время планирования производства.

с.Заказ работы - система DBB нуждается в сохранении данных, которые относятся к работе, проводимой DBB для того, чтобы правильно назначить задачи и затем состыковать данные для облегчения фактурирования Партнеров для завершаемой работы. Для того, чтобы минимизировать двойной ввод Партнеров, DBB выполняет просмотр для приема элементов/запросов линейки заказов работ через интеграцию системы там, где это возможно.

6. Мультипользователь

Отсутствуют специфические многопользовательские требования для поиска за пределами потребности, которая обеспечит фильтрацию результатов поиска с помощью Партнера в качестве просмотренного значения.

Приложение 10. Управление подкачкой/кодированием

1. Обзор

DBB управляет технологическим процессом обработки для Кодирования (или захвата) и затем подкачкой Компонентов. В этой оркестрации, запуск с помощью запроса для создания новых компонентов в Производственном плане через их принятие в DBB, метаданные будут унаследованы, захвачены и проверены через ручные и автоматизированные процессы для поддержки и создания чистых данных и, таким образом, однозначно для инвентаризации.

Кодирование, известное также как захват, является, в значительной степени, ручным процессом создания мастер-файлов обычно из физической ленты, но их можно также создавать из файла. Важно, чтобы это был управляемый процесс для того, чтобы можно было узнать статус относительно конкретных или наборов, кодирований. Кроме того, в качестве внешнего поставщика будут затем вводиться требуемые метаданные и передаваться в файл для запуска следующей фазы в процессе подкачки, а также управляемый технологический процесс будет учитывать, что будет отслеживаться в качестве скоординированного.

Процесс Подкачки, который определен в рамках этого документа, начинается с получения Кодированного Компонента или Набора Компонентов, вероятно в рамках упаковщика. Предполагается, что за пределами редкого исключительного технологического процесса, компонент нельзя будет подкачивать в DBB без ожидания Требования к компонентам, который был создан с использованием Производственного плана (Процесс реагирования) или из запроса мастеринга файла (в процессе, Упреждающего создание). С этапа получения файл(ов) принятый файл(ы) проходят через ряд автоматизированных и ручных этапов для подтверждения целостности файла, выполнения проверок качества, выполнения технического процесса регистрации и затем формальной подкачке файла(ов) в системе хранения DBB и обновления/создания необходимых метаданных для компонента при ожидании Требования компонента.

2. Описание

На фиг.20 изображен процесс управления кодированием и подкачкой, который должен быть оркестрован с помощью DBB.

Спецификация, основанная на Кодировании и подкачке, управляемая через запросы и управляемый технологический процесс, представляет из себя основную концепцию для DBB, так как она имеет отношение к поддержанию хорошо сформированной инвентаризации с необходимыми метаданными и отношениями для облегчения автоматизации. Спецификацию Типа компонента можно создать и поддержать с помощью операций. Спецификацию Типа компонента можно создать и поддерживать с помощью операций так, как определено группой Управление мастерингом/активами в качестве общего шаблона и управления для запроса создания и затем приема поступающих активов. Требование к компоненту представляет собой запрос для специфического типа Компонента(ов) напротив Названия/Альфа и создает запись оболочки, которая будет приниматься напротив Требования к компоненту. Это разрешает правила, которые будут введены в действие и обеспечат единообразие метаданных инвентаризации.

Требования к компонентам создаются с использованием запросов двумя основными способами:

а. С реагированием из Производственных планов, которые позволяют кодировать Компоненты и затем Подкачивать для использования выжидающих заказов, и

b. С упреждением на основании планов мастеринга, которые приводят к созданию компонентов для новых цифровых выпусков (Особенностей и Телевизионного контента).

Продавец выполняет определенное количество контента QC перед инициализацией передачи файла(ов), которые определены в Мастер-спецификации для DBB через интерфейс приложения, с расширением для поставщика, который начинает процесс Подкачки. Услуга, выполняемая у поставщика или дистанционно, будет также выполнять способ для поставщика для ввода требуемых метаданных относительно Компоненты(ов), а также для обеспечения контрольных сумм, которые будут вычисляться для файла(ов) для проверки правильности данных после передачи для обеспечения перемещения файла(ов), которые не вводят искажения или прерывания.

Процесс Подкачки начинается с начального получения файла(ов) обычно после завершения кодирования. Процесс Подкачки автоматически проверяет контрольную сумму, включающую в себя разворачивание контента при необходимости (ожидание окончательного определения спецификации пакета доставки от поставщиков Кодирования).

После завершения проверки контрольной суммы проверяют качество метаданных Компонента и файла(ов) для того, чтобы гарантировать, что определенные характеристики актива находятся в пределах допусков спецификации типа компонентов. Технические характеристики автоматически извлекаются из файла(ов) и метаданные подтверждаются на основании того, что достигается в автоматизированном Техническом QC и QC Контента. Регистрация записи из любого автоматизированного процесса QC должна фиксироваться и сохраняться в системе для дальнейшего использования.

Сразу после проверки целостности Компонента(ов) выполняют согласование для принятого файла(ов) с ожидающимся Требованием к компонентам на основании метаданных по записи Требования к компонентам в системе напротив метаданные, которые должны сопровождать файл(ы) от поставщика. Это является вспомогательным ручным процессом, посредством чего связь только требует подтверждения в большинстве случае, но также требует, чтобы запись актива можно было вручную согласовать с Требованием компонента в списке, в котором многочисленные опции должны быть систематически идентифицированы (обычно в результате плохих поступивших метаданных) или, если опция не идентифицирована системой через поиск.

Следующий процесс предназначен для высококачественного воспроизведения, модуля доступа с покадровой точностью, которая будет использоваться на следующих этапах. Используя модуль доступа, будет некоторое количество дополнительной ручной проверки файла(ов), такое как контроль аудио треков и формата изображения и их метаданные перед окончательной подкачкой в DBB.

Следующий этап представляет собой техническую регистрацию для Компонента. В настоящее время это только предполагается для видео Компонентов и (связанных с этим аудио Компонентов, если они находятся в одном и том же процессе Подкачки) и рассматривается в качестве ручной деятельности. Функция технической регистрации включает в себя захват идентификации сегмента Компонентов (то есть, штрихи, оттенки, знаки безопасности с сигнальным черным цветом, логотипы, программа) наряду с информацией о временных кодах для каждого сегмента (в и из точек) и при необходимости координаты кадрирования. Кроме того, предпочтительно, чтобы этот процесс технической регистрации проводился в модуле доступа с покадровой точностью в отличие от фактически существующего файла в качестве размера файла, особенно для HD, будет становиться громоздким. Кроме того, хотя это планировалось в качестве ручной задачи, также желательно, чтобы некоторое количество индексации и автоматизации/идентификации сегментов было предложено так, чтобы можно было сократить ручную работу в значительной степени для верификации/настройки данных технической регистрации.

Снятие отпечатков пальцев является процессом, который затем выполняется по отношению к файлу(ам) для создания уникальной подписи для файла, который будет позже использоваться для уникальной идентификации Названия/Альфа. Фактически это может или не может происходить после того, как файл действительно находится внутри системы хранения DBB, так как это может быть более эффективным, так как производственные планы могут находиться в очереди, ожидая этот актив.

Окончательный этап в процессе Подкачки включает в себя проверку достоверности целостности файла, сравнение первоначально захваченных контрольных сумм и затем передача файла из местоположения процесса Подкачки в систему хранения DBB для управления. Окончательное подтверждение данных Требования к компонентам и поступающие метаданные, сопровождающие файл(ы) Компонентов будут выполняться и могут подтвердить правильность с помощью оператора. Кроме того, в рамках системы Требование к компонентам будет обновлять выполненный статус и обеспечивать эту видимость через всю систему.

Существуют некоторые изменения в этом процессе в случаях, где Компоненты только аудио или скрытые титры (СС) соединяются через управляемый процесс Подкачки по сравнению с тем, когда согласованные видео и аудио Компоненты подкачиваются вместе. Как и прежде, они представляют собой результаты запросов и выходят из управляемого процесс Кодирования. Основное отличие в этом технологическом процессе заключается в том, что для того, чтобы эти компоненты были согласованы с активом видео, предполагая, что они связаны с ним, необходимо подтвердить эталонную копию аудио. Это может произойти на стороне сервера с использованием специфического модуля доступа, созданного для верификации соответствия для аудио и/или СС. С другой стороны, это можно выполнить локально, хотя это менее предпочтительно из-за требования перемещения эталонного видео из DBB в рабочую станцию.

Сразу после подкачки компонента только аудио или СС в систему хранения требуется, чтобы этот тип актива был связан с одним или многочисленными комплектами. Этот процесс будет предположительно ручным и будет выполняться либо заранее, как часть функции Управления Инвентаризацией с использованием Требования к компонентам или после Подкачки, когда выполняется Требования к компонентам.

В итоге, будут существовать специфические варианты "Замены" этих технологических процессов, которые учитывают необходимую логику бизнеса и системы для активов, которые уже находятся в системе, но заменяются из-за отклонения или попыток повторного мастеринга.

3. Пользовательский интерфейс

К пользовательскому интерфейсу (ПИ) должен быть доступ, как оператора Кодирования, так и Подкачки, которые могут быть различными продавцами, которые могут или не могут быть, в том числе, внутренними. Таким образом, требуется, чтобы при наличии богатых возможностей и интерактивности, интерфейс был надежно представлен своим внешним пользователям, а также был интуитивным, так как можно предположить, что профессиональная подготовка внешних продавцов будет меняться. Различные продавцы, использующие этот ПИ, не должны иметь доступ к файлам, которые задействованы другими. Кроме того, услуга, как упомянуто выше, предпочтительно с ПИ, потребуется для оказания помощи продавцам Кодирования с первоначальной подготовкой предварительной передачи Компонента, такой как ввод метаданных и вычисление контрольной суммы.

Кроме того, чтобы удовлетворить требования создания/обновления Комплекта, упомянутого выше, ПИ необходимо поддерживать связь с выполненными Компонентами и Требований к компонентам для активов только аудио и СС в Комплектах.

4. Услуги

Существует целый ряд услуг, которые необходимы для поддержки технологических процессов Кодирования и Подкачки. На самом большом основании, так как эти процессы управляют технологическими процессами, услуги по Оркестровке технологических процессов должны использоваться для облегчения задач в рамках этого процесса и метрики процесса захвата. Сами Услуги Кодирования непосредственно не рассматриваются как часть DBB и будут предположительно инструментами третьей стороны, которая используется продавцом для создания файла(ов) Компонентов, как определено в определении Мастер-файла. Однако Услуга/Приложение предварительно передачи Кодирования потребуется для того, чтобы дать возможность продавцу создать контрольную сумму перед перемещением файлов в процесс Подкачки для обеспечения целостности файла.

В рамках процесса Подкачки, необходимо иметь несколько услуг, некоторые из которых будут централизованными или другими, которые необходимо выполнить локально. Эти услуги включают в себя контрольную сумму перемещения файла. Снятие отпечатков пальца, автоматизированная техническая QC и 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 может отличаться от той, которая предназначена для широковещательного клиента.

Элемент пакета - определяет дискретный фрагмент контента, который запрашивается как часть пакета клиента. Каждый элемент пакета будет иметь свою собственную спецификацию на основании своего типа контента или Типа элемента. Например, элемент пакета Метаданных будет иметь Спецификацию метаданных, причем, Фотография рекламируемого продукта крупным планом будет иметь Спецификацию изображения.

Тип элемента - определяет тип элемента, то есть анонс, рекламный кадр сюжета, Фотографию рекламируемого продукта крупным планом. Метаданные, Музыкальное видео и т.д.

Процесс Создания пакета можно логически разделить на три подпроцесса, которые представлены ниже: Сбор контента; Сборка пакета; и Поддержка пакета. Сбор контента представляет собой деятельность, которая отвечает за идентификацию или локализацию всех требуемых элементов пакета внутри запроса. Сборка Пакета гарантирует, что все требуемые элементы пакета были собраны, выполняет любую обработку, которая требуется для подтверждения элементов пакета в спецификации клиента (то есть, транскодирование, снабжение водяным знаком, преобразование XML, DRM и т.д.), и организует элементы пакета в соответствии со спецификацией пакета. Поддержка пакета представляет собой процессы, которые управляют пакетом после его создания.

Сбор контента представляет собой деятельность, которая отвечает за идентификацию и/или локализацию всех требуемых элементов пакета для продуктов внутри запроса. Спецификации пакета представлены в виде механизма для информирования процесса Сбора контента как то, что необходимо собрать. Спецификация пакета должна содержать следующую информацию:

а. Какие должны быть включены элементы пакета, то есть, анонс, изображение, метаданные и т.д.

b. Сколько требуется для каждого элемента пакета, то есть, два анонса, четыре изображения, одни метаданные.

с.Где можно найти каждый из элементов пакета, и какие критерии используются для его нахождения (местоположение системы файлов, критерии поиска DAM, вызов веб-услуги и т.д.).

d. Соглашение о наименовании клиента каждого элемента пакета.

е. Организационная схема элементов пакета (то есть, свободные файлы, архивированные с помощью продукта, специфическая структура директорий и т.д.).

Сбор Контента начинается с определения того, доступны или нет элементы пакета для данного запроса. DBB должен обнаружить статус каждого элемента пакета внутри ПИ запроса, позволяющего соответствующему пользователю(ям) просматривать, что еще необходимо для сбора и выполнения Запроса.

Там, где DBB действительно осуществляет просмотр для сбора элементов пакета, будет проектное решение. Одной опцией может быть запрос, основанный на области WIP, где весь контент, который требуется для Запроса, разбивается на этапы. Другой опцией будет сохранение всего требуемого контента в DAM. Это потребует стандартных метаданных в канонической форме для того, чтобы позволить DBB разместить контент на основании комбинации Запроса и атрибутов Шаблона пакета, таких как Название запроса, Территория запроса и Тип контента Шаблона пакета (то есть, Название=Квант милосердия, Территория=США и Тип контента=Фотография рекламируемого продукта крупным планом). Процесс должен быть, по возможности, автоматизированным с помощью минимального числа перемещений контента. Соответственно, решение DAM имеет характерные преимущества в том, что контент можно загрузить один раз и повторно использовать для многочисленных запросов, тогда как вручную заполненные области WIP необходимы для дальнейшего повторного заполнения для каждого Запроса, который обрабатывается.

Как точно определено выше, соглашения относительно наименования файла будут также необходимы для дальнейшей автоматической выработки в определенных случаях в рамках DBB для того, чтобы удовлетворить требованиям доставки Клиенту. Эти соглашения относительно наименования файлов изменяются между распределенными клиентами и обычно состоят из ряда сокращенных и соединенных значений метаданных, описывающих актив. Соглашения относительно наименования должны быть специфическими для конкретного клиента, но также должны быть конфигурируемые для потребностей клиента. Для того, чтобы определить соглашения о наименовании файлов, пользователь DBB должен выбрать ряд областей метаданных (например, Название, Формат изображения, фиксированные строки, например, "_" "-"), или другие определенные переменные (например, текущая дата, текущее время). Текст, возникающий в результате из вводов метаданных, можно модифицировать на основании ряда различных критериев, точно определенных пользователем DBB. Каждый из этих критериев можно использовать отдельно или совместно по порядку (например, удаление гласных, затем вырезание до максимальной длины 10 знаков).

Следующие критерии можно также применить для ввода специфических метаданных или полного выражения:

а. Сократить до длины - например, сократить область Названия до 10 знаков. "Преобразователи" будут выглядеть как "Преобразовать".

b. Удаление гласных - (например, удаление гласных из области Названия. "Преобразователи" станут "Прбрзвтл").

с. В случае заглавных/прописных - (например, в случае прописных в области Названия. "Преобразователи" станут "преобразователи").

d. Удаление специальных знаков - (например, удаление двоеточия из Названия. "Звездные врата: бесконечность" станут "Звездные врата Бесконечность")

Учитывая гибкость, требуемую для этой манипуляции данных, сложные манипуляции можно лучше обработать с использованием процессора Регулярных выражений (например, RegEx).

Сбор контента завершается, когда все требуемые элементы пакета были идентифицированы и/или разбиты на этапы. Однако некоторый уровень оперативного управления необходимо поддерживать для того, чтобы иметь возможность создания пакета, и, следовательно, выполнения запроса даже в случае, когда определенные элементы пакета недоступны. Это означает, что авторизованный оператор запрашивает возможность начала процесса Сборки Пакета даже в случае, если процесс Сбора Контента не был завершен. Некоторые из этих требований можно выполнить с помощью бизнес-правил, которые показывают, какие элементы пакета действительно требуются для доставки. На самом высоком уровне оператор должен иметь возможность послать "как есть" независимо от того, что предписывает спецификация пакета.

Сборку Пакета можно начинать сразу после сбора элементов пакета. Цель ее состоит в подготовке организации содержания, как описано в спецификации пакета. Каждый элемент пакета будет иметь свою собственную спецификацию. Например, анонс может быть необходим для доставки в специфическом формате, формате изображения и скоростью передачи битов; метаданные могут быть преобразованы в специфический формат клиента. DBB предполагается для использования соответствующих спецификаций для того, чтобы узнать, какие преобразования необходимо выполнять в дальнейшем. При сборке пакета, DBB будет выполнять некоторую комбинацию нижеследующего, на основании спецификации пакета и спецификаций элемента пакета:

а. Определяют, требуется ли, и на каком уровне шифрование (пакета или элемента пакета) и применяют там, где это необходимо.

b. Преобразуют изображение, поддерживают элементы видео (то есть, анонс, музыкальное видео и т.д.) и метаданные.

с. Применяют судебные водяные знаки, если требуется.

d. Применяют DRM для продуктов, если требуется.

е. Применяют соглашения относительно специфического наименования клиента для упаковки элементов по требованию.

f. Организуют элементы пакета структуры директории.

g. Объединение или упаковка элементов пакета, то есть Zip, программа-архиватор stuffit. Сборка пакета MXF, завершается тогда, когда все требуемые элементы пакета были обработаны до их соответствующей спецификации. Однако некоторый уровень оперативного управления необходимо поддерживать для обеспечения возможности создания пакета и, следовательно, запроса для выполнения даже в случае, когда определенные элементы пакета не были собраны и/или скомплектованы.

Поддержка пакета состоит из следующих процессов, которые требуются для управления послесборочной упаковки:

а. Стадии упаковки для QC - вызывают перемещение пакета в местоположения QC и уведомляют соответствующую часть, в которой готов пакет для QC.

b. Разбиение на этапы пакета для доставки - перемещают собранный и, по необходимости, качественно проверенный пакет в местоположении с поэтапной доставкой.

с. Сохранение пакета - обеспечивают соблюдение политик удаления/сохранения для пакетов. Эти политики могут представлять собой клиента или специфического партнера.

d. Управление пакетом - позволяет администратору вручную осуществлять доступ или удалять пакеты.

3. Пользовательский интерфейс

Пользовательский интерфейс должен существовать для управления всеми аспектами спецификаций пакета от создания типа элемента до сборки спецификации пакета. Создание, просмотр и публикация спецификаций пакета рассматриваются как часть полной адаптации процесса.

Кроме того, запрос и/или портал Администратор/Партнер будут обнаруживать статус каждого элемента пакета в пределах конкретного запроса, позволяющего авторизованным пользователям видеть, что все еще необходимо для сбора, который позволяет продолжить выполнение Запроса.

Наконец, создание Пакета позволяет потенциально посылать уведомления сторонам, ответственным за обеспечение элементов пакета и выполнение QC пакета.

4. Интерфейсные системы

DBB должна взаимодействовать с DAM или файловой системой, которая размещает элементы пакета, требуемые для пакетов.

5. Мультипользователь

DBB должна взаимодействовать с системами DAM партнера для того, чтобы производить сбор необходимых элементов пакета. Однако другая опция заключается в обеспечении портала Партнера, который разрешил прямую подкачку элементов пакета в DBB.

Приложение 13. Финансовые процессы

1. Обзор

DBB запрашивает взаимодействие с финансовыми системами компании Сони или партнерами для того, чтобы обеспечить оценки стоимости, облегчить финансовое утверждение, выполнить выписку счетов или процесса переноса стоимости и для облегчения согласования финансовых операций там, где это необходимо.

Модель DBB финансовых процессов должна поддерживать взаимоотношение бизнеса с SPE, межфирменную модель, а также модель партнера, модель наиболее традиционного заказчика/продавца. Концепции самообслуживания, обсужденные в приложении 3 "Управление запросами" можно применить как межфирменные модели, так и к третьесторонним моделям, которые также будут описаны. Однако также считается необходимым включение требований для уровня услуги заказчика DBB, на котором Партнеры могут обеспечить традиционные РО. Этот уровень услуги заказчика будет затем взаимодействовать с DBB через Модуль запроса, как описано модели самообслуживания.

Все финансовые модели DBB будут учитывать интерфейсы с ПИ или финансовыми системами партнера для того, чтобы использовать основные функциональные возможности этих систем и для устранения основных финансовых требований из правильного DBB там, где это возможно. В отделении DBB в качестве управления контентом и платформы для распределения из требований GAAP или управляемых финансовых систем SOX желательно.

Специфические архитектурные опции, включающие в себя GOLD, Xytech МедиаИмпульс и Систему DADC СОМ, представлены в виде опций Архитектуры Системы ниже. Они включают в себя изображение интерфейса и аспекта осуществления DBB.

2. Описание

Концепции финансовой интеграции

Следующие ниже разделы документируют функциональные компоненты финансового потока DBB. Существуют многочисленные опции, доступные некоторым из этих компонентов. Эти опции обсуждаются в конце этого раздела.

Прейскурант - Как обсуждено в приложении 6 "Планирование производства" и детально разобрано в приложении 5 "Мастер-данные технологического процесса" и приложении 7 "Управления задачами", предполагается, что DBB будет обладать возможностью поддерживать прейскурант в пределах своей архитектуры или будет сопряжена с системой, которая поддерживает прейскурант. Этот прейскурант должен учитывать различные сценарии ценообразования, общие для коммерции обработки контента. Эти сценарии должны включать в себя, но не ограничивать следующее:

а. Прейскурант, согласно Партнеру - прейскурант должен быть конфигурируемым для выполнения уникального ценообразования с помощью партнера, причем этот партнер может быть SPE или третьей стороной. Прейскурант должен поддерживать копию и модификацию ценообразования партнера и применения изменений нормы выработки с полным процентным содержанием или с индивидуальными изменениями цены. Требуется группирование и модификация большого числа цен услуг.

b. Ценообразование проекта - это ценообразование заменяет прейскурант Партнера, когда договариваются об условиях специфической сделки.

с. Типы ценообразования - следующие типы ценообразования должны поддерживаться.

Ценообразование количества - включает в себя применение скидок на большое количество.

Ценообразование фиксированного вознаграждения - включает в себя услуги, для которых количество или части не рассматриваются при вычислении цены.

Ценообразование минимального количества - Фиксированное вознаграждение оплачивается до тех пор, пока не достигнет минимального количества, затем используется количество или ценообразование стандартных модулей.

d. Переменное ценообразование - Следующие переменные должны использоваться при отображении прейскуранта.

Количество - число созданных элементов, например, пять файлов Mpeg2.

Модули - число модулей, которое можно или нельзя умножить на количество, например, 10 поставщиков 5 файлов Mpeg2. Они также используются для любой услуги на основании общего модуля.

Время выполнения - время выполнения контента.

Источник и тип вывода - тип файла источника, например, HD в зависимости от источника SD, выходной формат транскодирования.

Тип заказа - требуемый уровень услуги и тип сделки для заказа, например, срочные заказы, неоплачиваемые.

Тип услуги - тип услуги (услуг), выполняемых для запроса, например, транскодирование, ослабление 3:2 и т.д.

Скорость передачи битов - скорость передачи битов контента.

Размер файла - размер файла обрабатываемого контента.

Операции по выписке счетов - Посредством отображения между Задачами DBB и прейскурантом. Операции по выставлению счетов будут вырабатываться с помощью DBB. Эти операции могут вырабатываться с помощью производственного плана автоматизированным способом или посредством модификации производственного плана, как описано в приложении 6 "Планирование производства" и приложении 5 "Мастер-данные технологического процесса". Однако операции по выставлению счетов будут содержать компоненты оценки стоимости Производственного плана и будут поддерживать фактурирование или процессы переноса стоимости.

Интерфейс РО производственного плана - В рамках модели компании Сони производственный план после одобрения Запрашивающей стороной в DBB, будет вырабатывать Операции выставления счетов, которые поддерживаются требуемыми финансовыми данными. Затем она будет экспортировать эту информацию в систему выполнения WPF, GOLD. Этот интерфейс приведет к созданию Заказа для покупки медиа в GOLD. Требуется вспомогательная информация, такая как Название SPE/ID Альфа, другая финансовая информация может быть включена в конструкцию Модуля запроса (например, территория, рынок) и будет также представлена в интерфейсе. Для того, чтобы поддержать требование Партнера, этот интерфейс будет поддерживать стандартную схему и функциональные возможности веб-услуги, которые можно сконфигурировать и переместить многочисленным партнерам. Производственные инструкции и Активы источника можно включить в интерфейс только для целей информации. GOLD PO (или РО партнера), созданная с помощью DBB, предназначена в качестве транспортного средства для выставления счетов, а не в качестве инструкции для выполнения работы. Отчет о деталях процесса распределения будет представлять собой требования DBB, а не систему РО партнера. Деталь, на которую дана ссылка, потребуется в обеих системах.

Сразу после создания производственного плана и отправки интерфейсных сообщений, план будет отложен до утверждения через интерфейс. Утверждение СОРА затрат производственного плана будет выполняться в GOLD (или в системе РО партнера). После утверждения сообщение будет отправлено обратно в DBB, деблокируя Производственный план.

Требования к R1 включают в себя интерфейс в GOLD и расширяемость до третьесторонних систем РО. Разработка и построение третьестороннего интерфейса РО не находится в сфере рассмотрения для R1.

Интерфейс выполнения производства и перенос стоимости - Сразу после приема утверждения СОРА через интерфейс будет выполняться производственный план. Существенные изменения в Производственном плане, которые могут встречаться во время выполнения, могут приводить к последующей итерации интерфейсного РО. Пересмотр можно отправить и одобрить для того, чтобы поддержать процесс выставления счетов. После завершения работы DBB будет посылать сообщение в GOLD, выполняющую функцию переноса стоимости. Эта функция будет отражать текущий ручной процесс в системе GOLD, с помощью которого создается регистрация счета, утвержденного и отсроченного для экспорта в SAP. Из-за внутрифирменного характера операций и гарантии с помощью интерфейса, что Операции по выставлению счетов DBB будут равны операциям GOLD РО, этот процесс можно полностью автоматизировать. Автоматизация этого процесса находится в сфере действия R1, но предполагается, что будет использоваться текущий Интерфейс GOLD в SAP, и новый интерфейс в SAP не потребуется.

Принимаемые счета DADC - Независимо от опций, выбранных для моделей партнера, предполагается, что Операции по выставлению счетов в рамках DBB будут сопряжены с Финансовой системой DADC, СОМ, для принимаемых счетов и универсальной бухгалтерской книги. В модели SPE эти операции A/R будут использоваться для поддержания согласования переноса стоимости между SPE и DADC. В модели Партнера, SOM будет обеспечивать стандартное фактурирование и функции приема счетов.

Финансовые модели переменных

Переменные, которые могут существовать между Моделью SPE и Моделью партнера, включают в себя, но не ограничивают следующее:

Сопряжение РО с производственным планом - Интерфейс производства, который производит оценку Партнеров, является опцией, но не требованием этой модели. Как кратко рассмотрено выше, Партнеры могут или не могут непосредственно использовать Модуль запросов. Если они не могут использовать, то они будут иметь дело с представителями Службы заказчика DADC, которые непосредственно будут взаимодействовать с модулем запроса DBB от имени Партнера. В этом случае, перед выполнением работы может потребоваться необходимость в традиционном РО партнера. Это будет более традиционное взаимодействие заказчик/продавец. Хотя этот процесс непосредственно не влияет на требование R1, необходимо рассмотреть случай использования.

Перенос счетов/стоимости - Для Партнера Интерфейс выполнения производственного плана и переноса стоимости, как описано выше в модели SPE, будет невозможен без целенаправленного проекта интеграции, который не входит в сферу для R1. Предполагается, что обработка традиционных счетов будет проводиться с помощью DADC из системы СОМ. Все внутренние операции между Прейскурантом, Операциями по выставлению счетов и СОМ A/R могут оставаться в таком состоянии, как описано выше.

Опции архитектуры системы

Прейскурант и Операции по выписке счетов - Текущие опции включают в себя интеграцию реализации Xytech МедиаИмпульс, которые будут находиться одни в рамках инфраструктуры DBB. Богатые функциональные возможности прейскуранта и выставления счетов в продукте Xytech будут использоваться для обработки финансовых операций и для сопряжения с GOLD на стороне SPE и СОМ на стороне DADC, как описано выше.

Вторая опция заключается в том, что прейскурант и Операции по выставлению счетов можно также поддерживать в рамках системы СОМ. Это потребует для СОМ поддержки всего ценообразования, которое относится к концепциям, и для сопряжения с GOLD, как описано выше.

Опция поддержки Прейскуранта в СОМ и Операций по выставлению счетов в МедиаИмпульс выглядит нецелесообразной. Если это используется исключительно для финансовых целей, эти системы будут рассматриваться как вспомогательные системы, и требования к проекту DBB будут базироваться на интерфейсах, необходимых для поддержки финансовой модели. Интеграция в этих системах будет находиться в сфере Rl. Более конкретно, это исключает осуществление примера МедиаИмпульс в качестве только системы выставления счетов.

Третья опция заключается в том, что Xytech МедиаИмпульс будет использоваться в основных функциях обработки контента DBB, таких как Модуль запроса, Планирование производства, Управление задачами и Управление инвентаризацией. МедиаИмпульс следует представить в качестве решения в этих областях, функции Прейскуранта и Операции по выставлению счетов будут находиться в области действия из-за их плотной интеграции в рамках архитектуры МедиаИмпульс.

3. Пользовательский интерфейс

Необходимо предусмотреть возможность модификации операции выставления счетов в любой точке в последовательности операций процесса. Этот интерфейс также раскрыт в приложении 6 "Планирование производства" относительно модификации плана. Более конкретно изложено для ясности, что рабочий персонал должен иметь возможность просмотра и модификации операций по выставлению счетов перед окончанием производственного плана или перед любой итерацией интерфейса РО производственного плана или для Партнеров перед фактурированием.

4. Услуги

В зависимости от окончательной конструкции, более конкретно относительно любого использования Xytech МедиаИмпульс, DBB потребует услуги для интерфейса данных Операций по выставлению счетов. Эта услуга должна иметь доступ к информации о прейскурантах, применять отображения для оцененных задач и создавать полученные в результате операции по выставлению счетов. Эта услуга должна выполняться в рамках DBB исключительно для целей оценки, при необходимости, а не только для поддержки распределения.

5. Интерфейсная система

В зависимости от разрешения опций архитектуры системы, интерфейс DBB в системе GOLD потребует поддержки в Утверждении COFA и деятельности по Переносу стоимости, как описано выше. Если МедиаИмпульс включен в виде части DBB для оперативных целей, то он влияет на характер интерфейса в системе DADC СОМ. Этот интерфейс может включать в себя полную область действия Прейскуранта, Операций по выставлению счетов, Утверждения СОМ и Переноса стоимости, или может просто потребовать сопряжения Операций по выставлению счетов из МедиаИмпульс.

6. Мультипользователь

На всем протяжении Раздела обращается внимание на Вопросы партнеров, которые относятся к изменениям в финансовом потоке. Во всех областях, где производится сбор или обработка финансовых данных, относительно определения принадлежности Партнера и назначения этого Партнера, станет возможным применение обработки переменных, которая описана здесь.

Изобретение относится к цифровым мультимедийным данным, а более конкретно к цифровому распределению мультимедийных данных. Техническим результатом является обеспечение автоматизации технологического процесса, который выполняет загрузку контента в цифровом формате и управляет им бесшовно путем доставки клиенту. Способ цифрового распределения медиа-контента с использованием системы магистрали распределения содержит этапы, на которых осуществляют: прием запроса на медиа-контент от клиента, причем запрос включает в себя профиль клиента; выполнение инвентаризации и анализа активов источника с помощью итерационного прохождения через профиль клиента для создания выходных данных; выполнение отображения возможностей, при котором ряд правил обеспечивают отображение активов источника на профиль клиента; и планирование процесса производства, определяющего элементы работы и этапы выполнения на основе возможностей, отображаемых в ответ на запрос медиа-контента от клиента. 3 н. и 24 з.п. ф-лы, 23 ил.

1. Способ цифрового распределения медиа-контента с использованием системы магистрали распределения, содержащий этапы, на которых:
принимают запрос медиа-контента от клиента, причем запрос включает в себя профиль клиента;
выполняют инвентаризацию и анализ активов источника путем итерационного прохождения через профиль клиента для создания выходных данных;
выполняют отображение возможностей, при котором ряд правил позволяет отображать активы источника на профиль клиента;
планируют производственный процесс, который определяет элементы работы и этапы выполнения на основе возможностей, отображенных в ответ на запрос медиа-контента от клиента.

2. Способ по п.1, в котором профиль клиента задает определенный набор спецификаций в отношении требований к медиа-контенту или метаданным для клиента.

3. Способ по п.2, в котором определенный набор спецификаций задает ключевые переменные и требования, необходимые для поддержки автоматизированных технологических процессов.

4. Способ по п.1, в котором профиль клиента задает требования клиента к доставке медиа-контента.

5. Способ по п.1, в котором устанавливают для каждого клиента один или более профилей клиента, с тем чтобы представить многочисленные бизнес-модели для клиента и/или требования, меняющиеся в зависимости от территории.

6. Способ по п.1, дополнительно содержащий этап, на котором:
выполняют оптимизацию элементов работы и этапов выполнения, определенных в производственном процессе.

7. Способ по п.1, дополнительно содержащий этап, на котором:
вырабатывают запрос с помощью операций, отвечающих за лицензирование медиа-контента, в отношении операций, отвечающих за выполнение медиа-контента для лицензиатов.

8. Способ по п.1, дополнительно содержащий этап, на котором:
выполняют анализ для идентификации ключевой информации относительно идентификации медиа-контента, клиента, подлежащего обслуживанию, и условий обслуживания, включающих в себя срок выполнения.

9. Способ по п.1, дополнительно содержащий этап, на котором:
выполняют действия, относящиеся к поставке, которые включают в себя автоматизированное управление технологиями обработки контента.

10. Способ по п.9, в котором автоматизированное управление технологиями обработки контента включает в себя действия по управлению файлами, транскодированию, упаковке и доставке, которыми управляют с помощью стандартизованных интерфейсов данных.

11. Система магистрали распределения, содержащая:
механизм анализа производства для приема от клиента запроса медиа-контента, включающего в себя профиль клиента,
при этом анализ производства обеспечивает выполнение инвентаризации и анализ активов источника с помощью итерационного прохождения через профиль клиента для выработки выходных данных анализа; и
механизм планирования производства, выполненный с возможностью определения элементов работы и этапов выполнения с использованием выходных данных анализа.

12. Система магистрали распределения по п.11, в которой механизм планирования производства содержит модули для выполнения или использования источника активов компонентов, технологические процессы и анализ стоимости и времени производственного цикла.

13. Система магистрали распределения по п.11, в которой профиль клиента включает в себя:
спецификацию пакета, задающую отдельные элементы, подлежащие доставке клиенту для выполнения запроса медиа-контента;
предпочтения производства, которые представляют собой специфические требования клиента, определяющие выбор активов источника и ограничивающие возможности производства;
техническую спецификацию, которая представляет собой не основанные на контенте требования, задающие кодек, частоту кадров, разрешение изображения и другие технические параметры на основе файлов; и
спецификацию сборки, задающую требования к нелинейному монтажу.

14. Система магистрали распределения по п.13, в которой требования к нелинейному монтажу включают в себя замену логотипа, наложение затемнения или добавление сообщений.

15. Система магистрали распределения по п.13, в которой спецификация пакета включает в себя спецификацию контента и спецификацию метаданных.

16. Система магистрали распределения по п.15, в которой спецификация контента включает в себя повторно используемые технические спецификации, спецификации сборки и данные о предпочтениях.

17. Система магистрали распределения по п.11, в которой выходные данные анализа включают в себя требование к компонентам, которое представляет собой инструмент управления задачами, необходимый для управления подкачкой.

18. Система магистрали распределения по п.11, в которой механизм анализа производства включает в себя модули для приема спецификации, доставляемой клиенту, вспомогательных данных инвентаризации и мастер-данных технологического процесса.

19. Система магистрали распределения по п.18, в которой механизм анализа производства выполнен с возможностью идентифицировать соответствующий технологический процесс с помощью спецификации, доставляемой клиенту.

20. Система магистрали распределения по п.18, дополнительно содержащая комплект, включающий в себя сгруппированные компоненты и согласованный и синхронизированный для совместной работы компонентов, при этом компоненты, определяемые для совместной работы, организованы так, чтобы обеспечить указание мастер-данными технологического процесса упомянутого комплекта.

21. Система магистрали распределения по п.20, в которой комплект включает в себя один видеокомпонент и один или более аудиокомпонентов.

22. Машиночитаемый носитель информации, содержащий компьютерную программу для цифрового распределения медиа-контента, причем компьютерная программа содержит исполняемые команды, которые вызывают в компьютере:
прием запроса медиа-контента от клиента, причем запрос включает в себя профиль клиента;
выполнение инвентаризации и анализа активов источника путем итерационного прохождения через профиль клиента для создания выходных данных;
выполнение отображения возможностей, при котором ряд правил обеспечивают отображение активов источника на профиль клиента; и
планирование процесса производства, определяющего элементы работы и этапы выполнения на основе возможностей, отображенных в ответ на запрос медиа-контента от клиента.

23. Машиночитаемый носитель информации по п.22, дополнительно содержащий исполняемые команды, вызывающие в компьютере
выполнение оптимизации элементов работы и этапов выполнения, определенных в процессе производства.

24. Машиночитаемый носитель информации по п.22, дополнительно содержащий исполняемые команды, вызывающие в компьютере
выработку запроса с помощью операций, отвечающих за лицензирование медиа-контента, в отношении операций, отвечающих за выполнение медиа-контента для лицензиатов.

25. Машиночитаемый носитель информации по п.22, дополнительно содержащий исполняемые команды, вызывающие в компьютере
выполнение анализа для идентификации ключевой информации, относящейся к идентификации медиа-контента, клиента, подлежащего обслуживанию, и условий обслуживания, включающих в себя срок выполнения.

26. Машиночитаемый носитель информации по п.22, дополнительно содержащий исполняемые команды, вызывающие в компьютере
выполнение действий, относящихся к поставке, которые включают в себя автоматизированное управление технологиями обработки контента.

27. Машиночитаемый носитель информации по п.22, в котором исполняемые команды, вызывающие в компьютере выполнение автоматизированного управления технологиями обработки контента, включают в себя исполняемые команды, вызывающие в компьютере
выполнение управления файлами, транскодирования, упаковки и доставки, управляемых с помощью стандартизованных интерфейсов данных.