10.08.2016
216.015.532a

Устройство и способ для обработки интерактивной услуги

Вид РИД

Изобретение

Юридическая информация Свернуть Развернуть
Краткое описание РИД Свернуть Развернуть
Аннотация: Изобретение к относится к способу и устройству для предоставления добавочной интерактивной услуги, которая относится к вещательному контенту. Техническим результатом является обеспечение способа исполнения приложения, которое относится к вещательному контенту, вещание которого осуществляется в настоящий момент, в конкретное время, и предоставлении соответствующей информации зрителю посредством особой обработки информации. Предложен способ обработки интерактивной услуги, который включает: отправку сообщения обнаружения приложению второго экрана, работающему на втором устройстве, при этом сообщение обнаружения анонсирует услуги поддержки второго экрана, которые может предоставлять первое устройство, прием запроса в отношении описаний услуг поддержки второго экрана от приложения второго экрана, отправку ответа с описаниями приложению второго экрана, предоставление прокси-сервера HTTP, используя услугу прокси-сервера HTTP, предоставляющую второму устройству возможность доступа к файлам, которые принимаются первым устройством в вещательном потоке, при этом услуга прокси-сервера HTTP является одной из услуг поддержки второго экрана, прием файлов из вещательного потока и доставку файлов второму устройству через прокси-сервер HTTP. 4 н. и 20 з.п. ф-лы, 102 ил.
Реферат Свернуть Развернуть

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

[0001] Настоящее изобретение относится к способу и устройству для предоставления, приема и обработки вещательной услуги, и в частности, к способу и устройству для предоставления добавочной услуги, которая относится к вещательному контенту.

Уровень техники изобретения

[0002] TV впервые появились в конце 19-го века и стали самым популярным устройством доставки информации с конца 20-го века, в то время как непрерывно развивались их способ отображения на экране или дизайн. Тем не менее, TV, обычно, позволяют зрителям принимать однонаправленную информацию от вещательной компании. Таким образом, ограничения TV стали проблематичными в то время как с 1990-х широкое применение получили персональные компьютеры (PC) и Интернет. Вследствие этого, были разработаны TV, способные предоставлять интерактивную услугу.

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

Сущность изобретения

Техническая задача

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

Решение задачи

[0005] Задача настоящего изобретения может быть решена посредством предоставления способа обработки интерактивной услуги в первом устройстве, включающего в себя этапы, на которых: отправляют сообщение обнаружения приложению второго экрана, работающему на втором устройстве, при этом сообщение обнаружения анонсирует услуги поддержки второго экрана, которые может предоставлять первое устройство; принимают запрос в отношении описаний услуг поддержки второго экрана от приложения второго экрана; отправляют ответ с описаниями приложению второго экрана; принимают триггер из вещательного потока или от интернет сервера и доставляют триггер второму устройству, используя услугу триггера, при этом услуга триггера является одной из услуг поддержки второго экрана, при этом услуга триггера служит для доставки триггера, при этом триггер является элементом сигнализации, чья функция состоит в идентификации сигнализации и установлении распределения во времени воспроизведения интерактивных событий, нацеленных на приложения для сегмента, описываемых таблицей параметров приложения, при этом триггер является одним из: триггера координаты времени, триггера активации, триггера взаимодействия или триггера изменения канала, при этом триггер координаты времени используется для установления координаты времени для события, при этом триггер активации устанавливает время активации для события, при этом триггер взаимодействия используется для моделей взаимодействия отличных от модели взаимодействия Триггерного Декларативного Объекта, при этом триггер изменения канала доставляется всякий раз, когда изменяется канал.

[0006] Предпочтительно, способ дополнительно содержит этап, на котором принимают сообщение поиска для поиска устройств, включая первое устройство, которые предлагают услуги поддержки второго экрана, перед этапом, на котором отправляют сообщение обнаружения.

[0007] Предпочтительно, услуга триггера предлагает опцию нефильтрованного потока, и опция нефильтрованного потока является опцией, при которой доставляются все типы триггера.

[0008] Предпочтительно, первое устройство доставляет все типы триггера как только триггер принимается первым устройством.

[0009] Предпочтительно, этап, на котором доставляют триггер, включает в себя этапы, на которых: объединяют информацию из триггера активации с информацией из таблицы параметров приложения, чтобы сгенерировать дополненный триггер активации, и отправляют сгенерированный дополненный триггер активации приложению второго экрана.

[0010] Предпочтительно, услуга триггера предлагает опцию фильтрованного потока, и опция фильтрованного потока является опцией, при которой доставляется триггер, который является одним из: дополненного триггера активации, триггера взаимодействия или триггера изменения канала.

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

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

[0013] Предпочтительно, первое устройство доставляет дополненный триггер активации во время активации дополненного триггера активации, при этом первое устройство доставляет триггер взаимодействия, когда триггер взаимодействия принимается первым устройством, и при этом первое устройство доставляет триггер изменения канала, когда изменяется канал.

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

[0015] Предпочтительно, способ дополнительно содержит этап, на котором осуществляют многоадресную передачу сообщения поиска для поиска устройств, включая первое устройство, которые предлагают услуги поддержки второго экрана, перед этапом, на котором принимают сообщение обнаружения.

[0016] Предпочтительно, услуга триггера предлагает опцию нефильтрованного потока, и опция нефильтрованного потока является опцией, при которой доставляются все типы триггера.

[0017] Предпочтительно, все типы триггера доставляются как можно быстрее.

[0018] Предпочтительно, этап, на котором принимают триггер, включает в себя этап, на котором принимают дополненный триггер активации, сгенерированный посредством объединения информации из триггера активации с информацией из таблицы параметров приложения.

[0019] Предпочтительно, услуга триггера предлагает опцию фильтрованного потока, и опция фильтрованного потока является опцией, при которой доставляется триггер, который является одним из: дополненного триггера активации, триггера взаимодействия или триггера изменения канала.

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

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

[0022] Предпочтительно, дополненный триггер активации доставляется во время активации дополненного триггера активации, при этом триггер взаимодействия доставляется как можно быстрее, а триггер изменения канала доставляется, когда изменяется канал.

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

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

[0025] Предпочтительно, услуга триггера предлагает опцию нефильтрованного потока, и опция нефильтрованного потока является опцией, при которой доставляются все типы триггера.

[0026] Предпочтительно, второй модуль доставляет все типы триггера как только триггер принимается первым модулем.

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

[0028] Предпочтительно, услуга триггера предлагает опцию фильтрованного потока, и при этом опция фильтрованного потока является опцией, при которой доставляется триггер, который является одним из: дополненного триггера активации, триггера взаимодействия или триггера изменения канала.

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

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

[0031] Предпочтительно, второй модуль доставляет дополненный триггер активации во время активации дополненного триггера активации, при этом второй модуль доставляет триггер взаимодействия, когда триггер взаимодействия принимается первым модулем, и при этом второй модуль доставляет триггер изменения канала, когда изменяется канал.

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

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

[0034] Предпочтительно, услуга триггера предлагает опцию нефильтрованного потока, и при этом опция нефильтрованного потока является опцией, при которой доставляются все типы триггера.

[0035] Предпочтительно, все типы триггера доставляются как можно быстрее.

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

[0037] Предпочтительно, услуга триггера предлагает опцию фильтрованного потока, и при этом опция фильтрованного потока является опцией, при которой доставляется триггер, который является одним из: дополненного триггера активации, триггера взаимодействия или триггера изменения канала.

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

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

[0040] Предпочтительно, дополненный триггер активации доставляется во время активации дополненного триггера активации, при этом триггер взаимодействия доставляется как можно быстрее, и при этом триггер изменения канала доставляется, когда изменяется канал.

Преимущественные эффекты изобретения

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

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

[0043] В соответствии с настоящим изобретением, существует возможность предоставления добавочной информации, которая относится к вещательному контенту, устройству второго экрана.

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

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

[0045] На чертежах:

[0046] Фиг. 1 является схемой, показывающей вариант осуществления типичного вещательного потока;

[0047] Фиг. 2 является схемой, показывающей вариант осуществления распределения во времени триггера в случае предварительно произведенного контента;

[0048] Фиг. 3 является схемой, показывающей вариант осуществления распределения во времени триггера в случае контента прямого эфира;

[0049] Фиг. 4 является схемой, показывающей вариант осуществления синтаксиса триггера;

[0050] Фиг. 5 является схемой, показывающей вариант осуществления таблицы параметров TDO;

[0051] Фиг. 6 является схемой, показывающей вариант осуществления таблицы параметров TDO;

[0052] Фиг. 7 является схемой, показывающей смысл значений атрибута «Frequency of Use» (Частота Использования);

[0053] Фиг. 8 является схемой, показывающей смысл значений атрибута «destination» (получатель);

[0054] Фиг. 9 является схемой, показывающей вариант осуществления синтаксиса двоичного вида Таблицы Параметров TDO;

[0055] Фиг. 10 является схемой, показывающей вариант осуществления синтаксиса двоичного вида Таблицы Параметров TDO;

[0056] Фиг. 11 является схемой, показывающей вариант осуществления синтаксиса двоичного вида Таблицы Параметров TDO;

[0057] Фиг. 12 является схемой, показывающей вариант осуществления синтаксиса двоичного вида Таблицы Параметров TDO;

[0058] Фиг. 13 является схемой, показывающей вариант осуществления синтаксиса двоичного вида Таблицы Параметров TDO;

[0059] Фиг. 14 является схемой, показывающей вариант осуществления структуры таблицы сообщения активации;

[0060] Фиг. 15 является схемой, показывающей вариант осуществления структурной схемы Списка URL;

[0061] Фиг. 16 является схемой, показывающей вариант осуществления двоичного формата для частных секций, содержащих TPT;

[0062] Фиг. 17 является схемой, показывающей вариант осуществления списка URL, закодированного в качестве документа XML;

[0063] Фиг. 18 является схемой, показывающей вариант осуществления addTriggerEventListener;

[0064] Фиг. 19 является схемой, показывающей вариант осуществления removeTriggerEventListener;

[0065] Фиг. 20 является схемой, показывающей вариант осуществления определения типа EventListener;

[0066] Фиг. 21 является схемой, показывающей вариант осуществления определения типа TriggerEvent;

[0067] Фиг. 22 является схемой, показывающей вариант осуществления архитектуры для подхода WM;

[0068] Фиг. 23 является схемой, показывающей вариант осуществления архитектуры для подхода FP;

[0069] Фиг. 24 является схемой, показывающей вариант осуществления статической активации в случае запроса/ответа ACR;

[0070] Фиг. 25 является схемой, показывающей вариант осуществления статической активации в случае запроса/ответа ACR;

[0071] Фиг. 26 является схемой, показывающей вариант осуществления динамической активации в случае запроса/ответа;

[0072] Фиг. 27 является схемой, показывающей вариант осуществления динамической активации в случае запроса/ответа;

[0073] Фиг. 28 является схемой, показывающей вариант осуществления архитектуры для активаций сервера ACR;

[0074] Фиг. 29 является схемой, показывающей вариант осуществления триггеров активации в случае (b) и случае (a) без EndTime;

[0075] Фиг. 30 является схемой, показывающей вариант осуществления триггеров активации в случае (b) и случае (a) без EndTime;

[0076] Фиг. 31 является схемой, показывающей вариант осуществления триггеров активации в случае (a) с EndTime;

[0077] Фиг. 32 является схемой, показывающей вариант осуществления триггеров активации в случае (a) с EndTime;

[0078] Фиг. 33 является схемой, показывающей вариант осуществления триггеров активации для случая (c);

[0079] Фиг. 34 является схемой, показывающей вариант осуществления триггеров активации для случая (c);

[0080] Фиг. 35 является схемой, показывающей вариант осуществления динамических триггеров активации, доставляемых в последнюю минуту;

[0081] Фиг. 36 является схемой, показывающей вариант осуществления динамических триггеров активации, доставляемых в последнюю минуту;

[0082] Фиг. 37 является циклограммой между клиентом ACR и другими серверами в случае запроса/ответа;

[0083] Фиг. 38 является циклограммой между клиентом ACR и другими серверами в случае событийно-управляемого ACR;

[0084] Фиг. 39 является схемой, показывающей вариант осуществления Списка Action (Действие) Услуги Клиента RemoteUI UPnP;

[0085] Фиг. 40 является схемой, показывающей вариант осуществления Услуги Клиента RemoteUI UPnP;

[0086] Фиг. 41 является схемой, показывающей вариант осуществления Trigger (Триггер) в Услуге Номер 6 DTVCC;

[0087] Фиг. 42 является схемой, показывающей вариант осуществления архитектуры системы для сценария второго экрана;

[0088] Фиг. 43 является схемой, показывающей вариант осуществления топологии между Приемником ATSC 2.0 и вторым экраном (Прямое Соединение);

[0089] Фиг. 44 является схемой, показывающей вариант осуществления топологии между Приемником ATSC 2.0 и вторым экраном (Непрямое Соединение);

[0090] Фиг. 45 является схемой, показывающей вариант осуществления Слоя Программного Обеспечения Приложения Услуги Второго Экрана;

[0091] Фиг. 46 является схемой, показывающей Слой Программного Обеспечения Приложения Услуги Второго Экрана;

[0092] Фиг. 47 является схемой, показывающей таблицу, показывающую разницу между очередностью передачи в соответствии с управлением Жизненным Циклом Приложения Второго Экрана и передаваемыми данными;

[0093] Фиг. 48 является схемой, показывающей рабочую концепцию модели Централизованного Исполнения;

[0094] Фиг. 49 является схемой, показывающей поток согласованной работы между приемником, основанным на модели Централизованного Исполнения, и вторым экраном;

[0095] Фиг. 50 является схемой, показывающей вариант осуществления способа, на приемнике, уведомления устройства второго экрана об информации UI;

[0096] Фиг. 51 является схемой, показывающей вариант осуществления способа, на приемнике, уведомления устройства второго экрана об информации UI;

[0097] Фиг. 52 является схемой, показывающей вариант осуществления Вещательной Сигнализации для Услуги Сервера RemoteUI;

[0098] Фиг. 53 является схемой, показывающей рабочую концепцию модели Распределенного Исполнения;

[0099] Фиг. 54 является схемой, показывающей поток согласованной работы между приемником, основанным на модели Распределенного Исполнения, и вторым экраном;

[0100] Фиг. 55 является схемой, показывающей поток согласованной работы между приемником, основанным на модели Распределенного Исполнения, и вторым экраном;

[0101] Фиг. 56 является схемой, показывающей вариант осуществления способа, на приемнике, уведомления устройства второго экрана о TDO и информации Event (Событие);

[0102] Фиг. 57 является схемой, показывающей вариант осуществления способа, на устройстве второго экрана, доступа к TPT и Приложению Второго Экрана;

[0103] Фиг. 58 является схемой, показывающей вариант осуществления способа, на устройстве второго экрана, доступа к TPT и Приложению Второго Экрана;

[0104] Фиг. 59 является схемой, показывающей другой вариант осуществления Вещательной Сигнализации для услуги сервера RemoteUI;

[0105] Фиг. 60 является схемой, показывающей вариант осуществления Обнаружения Устройства и Обмена Возможностями Устройства для Услуги Второго Экрана;

[0106] Фиг. 61 является схемой, показывающей вариант осуществления Схемы XML DeviceProfile Форума UpnP;

[0107] Фиг. 62 является схемой, показывающей вариант осуществления профиля устройства у устройства Второго Экрана;

[0108] Фиг. 63 является схемой, показывающей вариант осуществления описанная ProtocolInfo для Услуги Второго Экрана;

[0109] Фиг. 64 является схемой, показывающей вариант осуществления UIListing в то время как действие AddUIListing и RemoteUIListing исполняется на устройстве второго экрана;

[0110] Фиг. 65 является схемой, показывающей вариант осуществления одноадресной сигнализации для услуги клиента RemoteUI;

[0111] Фиг. 66 является схемой, показывающей вариант осуществления Одноадресной Сигнализации для Услуги Клиента RemoteUI;

[0112] Фиг. 67 является схемой, показывающей вариант осуществления Одноадресной Сигнализации для Услуги Клиента RemoteUI;

[0113] Фиг. 68 является схемой, показывающей вариант осуществления информации «EventInfo», доставляемой устройству второго экрана посредством действия ProcessInput;

[0114] Фиг. 69 является схемой, показывающей конфигурацию между приемником и устройством второго дисплея;

[0115] Фиг. 70 является схемой, показывающей вариант осуществления Типов Услуги и ID Услуги для Услуг;

[0116] Фиг. 71 является схемой, показывающей рабочую концепцию услуги доставки триггера;

[0117] Фиг. 72 является схемой, показывающей вариант осуществления процесса генерирования расширенного триггера активации;

[0118] Фиг. 73 является схемой, показывающей вариант осуществления Описания Схемы XML для Дополненного Activation Trigger (Триггер Активации);

[0119] Фиг. 74 является схемой, показывающей вариант осуществления Описания Схемы XML для Trigger, которые не являются дополненными;

[0120] Фиг. 75 является схемой, показывающей вариант осуществления формата Дополненного Activation Trigger;

[0121] Фиг. 76 является схемой, показывающей вариант осуществления формата Дополненного Activation Trigger;

[0122] Фиг. 77 является схемой, показывающей вариант осуществления формата Дополненного Activation Trigger;

[0123] Фиг. 78 является схемой, показывающей вариант осуществления формата Дополненного Activation Trigger;

[0124] Фиг. 79 является схемой, показывающей вариант осуществления переменных состояния услуги триггера;

[0125] Фиг. 80 является схемой, показывающей вариант осуществления переменных состояния услуги триггера;

[0126] Фиг. 81 является схемой, показывающей вариант осуществления Action Услуги Trigger;

[0127] Фиг. 82 является схемой, показывающей вариант осуществления Аргумента Action GetLatestUnfilteredTrigger;

[0128] Фиг. 83 является схемой, показывающей вариант осуществления Аргумента Action GetLatestFilteredTrigger;

[0129] Фиг. 84 является схемой, показывающей вариант осуществления Action Услуги Trigger;

[0130] Фиг. 85 является схемой, показывающей вариант осуществления операции на втором экране при получении триггера через услугу доставки триггера;

[0131] Фиг. 86 является схемой, показывающей рабочую концепцию услуги доставки триггера;

[0132] Фиг. 87 является схемой, показывающей Переменные Состояния Услуги AppURL;

[0133] Фиг. 88 является схемой, показывающей Action Услуги AppURL;

[0134] Фиг. 89 является схемой, показывающей Аргументы Action GetAppURL;

[0135] Фиг. 90 является схемой, показывающей рабочую концепцию услуги Прокси-Сервера HTTP;

[0136] Фиг. 91 является схемой, показывающей вариант осуществления Переменной Состояния Услуги Прокси-Сервера;

[0137] Фиг. 92 является схемой, показывающей вариант осуществления Action Услуги Прокси-Сервера;

[0138] Фиг. 93 является схемой, показывающей вариант осуществления Аргументов Action GetProxyURL;

[0139] Фиг. 94 является схемой, показывающей вариант осуществления RequestFiles();

[0140] Фиг. 95 является схемой, показывающей вариант осуществления Архитектуры Устройства Второго Экрана;

[0141] Фиг. 96 является схемой, показывающей вариант осуществления упрощенной структуры приемника;

[0142] Фиг. 97 является схемой, показывающей вариант осуществления структуры устройства второго экрана;

[0143] Фиг. 98 является схемой, показывающей сценарий услуги второго экрана;

[0144] Фиг. 99 является схемой, показывающей способ обработки интерактивной услуги в первом устройстве;

[0145] Фиг. 100 является схемой, показывающей способ обработки интерактивной услуги в приложении второго экрана, работающем на втором устройстве;

[0146] Фиг. 101 является схемой, показывающей вариант осуществления устройства для обработки интерактивной услуги в качестве первого устройства; и

[0147] Фиг. 102 является схемой, показывающей вариант осуществления устройства для обработки интерактивной услуги в качестве приложения второго экрана, работающего на втором устройстве.

Предпочтительный вариант осуществления изобретения

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

[0149] В настоящем техническом описании, понятие время мультимедиа (media time) обозначает параметр, ссылающийся на точку в воспроизведении компонента аудио/видео или аудио контента. ACR обозначает Автоматическое Распознавание Контента. AMT обозначает Таблицу Сообщений Активации. API обозначает Интерфейс Прикладного Программирования. DAE обозначает Декларативную Прикладную Среду. DO обозначает Декларативный Объект. FLUTE обозначает Доставку Файла через Однонаправленный Транспорт. GPS обозначает Глобальную Систему Позиционирования. HTTP обозначает Протокол Передачи Гипертекста. IP обозначает Интернет Протокол. IPTV обозначает Телевидение по Интернет Протоколу. iTV обозначает Интерактивное Телевидение. MIME обозначает Тип Средств Интернет. NDO обозначает Декларативный Объект NRT. NRT обозначает Не в режиме Реального Времени. SMT обозначает Таблицу Карты Услуги. SSC обозначает Канал Сигнализации Услуги. TDO обозначает Триггерный Декларативный Объект. TPT обозначает Таблицу Параметров TDO. UDO обозначает Несвязанный Декларативный Объект. UPnP обозначает Пользовательскую технологию Подключи и Работай. URI обозначает Унифицированный Идентификатор Ресурса. URL обозначает Унифицированный Указатель Ресурса. XML обозначает Расширяемый Язык Разметки. TFT обозначает Таблицу Фрагментов Текста. Подробности этого будут описаны ниже.

[0150] В данном техническом описании, DO, TDO, NDO, Ссылка и Упакованное Приложение имеют следующий смысл.

[0151] DO (Декларативный Объект) может быть совокупностью, составляющей интерактивное приложение. (Например, HTML, JavaScript, CSS, XML и мультимедийными файлами)

[0152] Понятие «Триггерный Декларативный Объект» (TDO) используется для обозначения Декларативного Объекта, который был запущен Trigger в Триггерной интерактивной вспомогательной услуге данных, или DO, который был запущен посредством DO, который был запущен Trigger или т.д. итеративно.

[0153] Понятие «Декларативный Объект NRT» (NDO) используется для обозначения Декларативного Объекта, который был запущен как часть услуги NRT, которая не является Триггерной интерактивной услугой данных.

[0154] Понятие «Несвязанный Декларативный Объект» (UDO) используется для обозначения Декларативного Объекта, который не связан с услугой, такого как Упакованное Приложение или DO, запускаемый посредством Ссылки, или DO, который был запущен посредством такого DO, и т.д. итеративно.

[0155] «Ссылка» является предоставленным вещательной компанией URL, который указывает на web-сайт, который предоставляет онлайновую информацию или функциональные возможности, которые относятся к текущим TV программам вещания (programming) или услуге NRT.

[0156] «Упакованное Приложение» является предоставленным вещательной компанией Декларативным Объектом (DO), который предоставляет информацию или функциональные возможности, которые вещательная компания желает предложить зрителям, и который упакован в один файл для зрителей для загрузки и инсталляции.

[0157] Подробности этого будут описаны ниже.

[0158] В данном техническом описании сообщение координаты времени включает в себя триггер координаты времени и его эквивалент. Соответственно, понятие «сообщение координаты времени» может быть взаимозаменяемо использовано с понятием «триггер координаты времени».

[0159] В данном техническом описании, сообщение активации включает в себя всю доставку информации, вызывающую активацию, как например, элемент активации в AMT и/или триггер активации.

[0160] Фиг. 1 является схемой, показывающей вариант осуществления типичного вещательного потока.

[0161] Типичный вещательный поток включает в себя последовательность TV программ. Каждая TV программа включает в себя лежащее в ее основе представление, которое, как правило, разбито на блоки, разделенные рекламными блоками (ads) и/или другим промежуточным материалом.

[0162] На Фиг. 1, Сегмент Представления A, Ad1, Ad2, Сегмент Представления B, и т.д., последовательно включены в вещательный поток. Сегменты, конфигурирующие каждое представление, могут именоваться контентом представления, а Рекламные блоки могут именоваться промежуточным контентом.

[0163] Каждое представление или отрезок промежуточного материала могут или могут не иметь ассоциированную с ним интерактивную вспомогательную услугу данных.

[0164] Понятие «сегмент интерактивной услуги» или просто «сегмент», будет использовано в данном техническом описании для обозначения участка интерактивной вспомогательной услуги, который рассматривается вещательной компанией как единое целое. Сегмент интерактивной услуги, как правило, но не обязательно, ассоциирован с одним представлением или отрезком промежуточного материала.

[0165] Для того чтобы исполнять такую интерактивную вспомогательную услугу данных, существует две модели: Модель непосредственного исполнения и модуль триггерного декларативного объекта (TDO).

[0166] В модели непосредственного исполнения, декларативный объект (DO) может быть запущен автоматически как только выбирается виртуальный канал. Он может осуществлять связь через Интернет со вторичным (backend) сервером для получения подробных инструкций в отношении предоставления интерактивных возможностей - создания отображений в конкретных местоположениях на экране, проведения опросов, запуска других специализированных DO, и т.д., при этом все синхронизировано с аудио-видео программой.

[0167] В модели TDO, сигналы могут быть доставлены в вещательном потоке или через Интернет для того, чтобы инициировать события TDO, такие как запуск TDO, завершение TDO, или вызов некоторой задачи посредством TDO. Эти события могут быть инициированы конкретными временами, как правило, синхронизированными с аудио-видео программой. Когда TDO запускается, он может предоставлять интерактивные возможности, которые он запрограммирован предоставлять.

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

[0169] Модель TDO отделяет доставку декларативных объектов и ассоциированных данных, сценариев, текста и графики от сигнализации конкретного распределения во времени воспроизведения интерактивных событий.

[0170] Элементом, который устанавливает распределение во времени интерактивных событий, является Trigger.

[0171] Информация о TDO, использованных в сегменте, и ассоциированных событиях TDO, которые инициируются Trigger, предоставляется посредством структуры данных, именуемой «Таблицей Параметров TDO» (TPT).

[0172] Фиг. 2 является схемой, показывающей вариант осуществления распределения во времени триггера в случае предварительно произведенного контента.

[0173] Trigger является элементом сигнализации, чья функция состоит в идентификации сигнализации и установлении распределения во времени воспроизведения интерактивных событий.

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

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

[0176] 1. Сигнализировать местоположение TPT (доступную через сеанс FLUTE в потоке излучения, через Интернет сервер, или обоими способами);

[0177] 2. Указывать, что интерактивный контент для предстоящего сегмента программы доступен для предварительной загрузки;

[0178] 3. Указывать текущее Время Мультимедиа ассоциированного аудио/видео или только аудио контента;

[0179] 4. Ссылаться на конкретное интерактивное событие в TPT и сигнализировать то, что событие должно быть исполнено сейчас или в указанное будущее Время Мультимедиа;

[0180] 5. Указывать то, что доступы к Интернет серверу должны быть произвольно растянуты в течение указанного интервала времени для того, чтобы избежать пика спроса.

[0181] Фиг. 2 иллюстрирует Trigger, доставляемые в ассоциации с двумя сегментами программ вещания. В этом примере, оба сегмента являются «предварительно произведенными», означая что контент исходит не из вещания в прямом эфире; интерактивные элементы были добавлены при постпроизводстве.

[0182] Как показано, за небольшое время до возникновения сегмента 1 программ вещания, может быть доставлен Trigger «предварительной загрузки» чтобы предоставить приемникам возможность получения TPT и интерактивного контента, ассоциированного с сегментом 1 программ вещания. Если Trigger предварительной загрузки не передается, можно предположить, что приемники должны использовать первый Trigger, который они видят в сегменте, для получения контента.

[0183] Trigger могут быть отправлены на всем протяжении сегмента 1, как показано, для указания текущего Времени Мультимедиа (помеченного «m» на фигуре) относительно сегмента. Периодическая доставка Media Time Trigger (Триггер Времени Мультимедиа) может быть необходима для того, чтобы позволить приемникам, которые только столкнулись с каналом, синхронизировать и получить интерактивный контент.

[0184] Непосредственно до начала сегмента 2, отправляется Trigger предварительной загрузки для этого предстоящего сегмента.

[0185] В случае предварительно произведенного контента (не в прямом эфире), TPT, которую приемник может получить после обработки первого Trigger, может определять распределение во времени всех элементов интерактивного восприятия для этого сегмента. Все что требуется приемнику и TDO для воспроизведения интерактивных элементов, может быть знанием распределения во времени мультимедиа; TPT может описывать интерактивные события относительно Времени мультимедиа.

[0186] Фиг. 3 является схемой, показывающей вариант осуществления распределения во времени триггера в случае контента прямого эфира.

[0187] Применительно к случаю контента прямого эфира, TPT по-прежнему содержит данные и информацию, которые относятся к разным интерактивным событиям, тем не менее, распределение во времени воспроизведения этих событий не может быть известно до тех пор, пока действие в программе не раскрывается во время вещания. Применительно к случаю прямого эфира, используется функция «событийного распределения во времени» Trigger. В данном режиме, Trigger может сигнализировать то, что указанное интерактивное событие должно быть повторно синхронизировано с указанным новым значением Времени Мультимедиа. В качестве альтернативы, Trigger может указывать на то, что определенное событие должно быть исполнено немедленно.

[0188] На Фиг. 3, теперь будут описаны функции триггеров сегмента 3.

[0189] Первый триггер является триггером предварительной загрузки, который отсылает к каталогу содержащему файлы сегмента 3.

[0190] Второй триггер является триггером времени мультимедиа, который используется для указания распределения во времени воспроизведения сегмента 3.

[0191] Третий триггер является триггером повторного распределения во времени события и указывает на то, что событие с eventID = 2 в TPT должно быть повторно синхронизировано с тем, чтобы произойти во Время мультимедиа 240. Заштрихованная зона указывает интервал времени до 240 в течение которого Trigger #3 может быть доставлен приемникам.

[0192] Четвертый триггер является триггером времени мультимедиа.

[0193] Пятый триггер является триггером повторного распределения во времени события и указывает на то, что событие с eventID = 5 в TPT должно быть повторно синхронизировано с тем, чтобы произойти во Время мультимедиа 444.

[0194] Шестой и седьмой триггеры являются триггерами времени мультимедиа.

[0195] Восьмой триггер является Trigger события и указывает на то, что событие с eventID = 12 в TPT должно быть исполнено немедленно.

[0196] Девятый триггер является Trigger повторного распределения во времени события и указывает на то, что событие с eventID = 89 в TPT должно быть повторно синхронизировано с тем, чтобы произойти во Время Мультимедиа 900.

[0197] Далее, будут описаны жизненный цикл, состояние и событие изменения состояния TDO.

[0198] TDO может существовать в четырех разных состояниях: Разъединенном, Готовом, Активном и Приостановленном. Ряд разных факторов может вызывать переход из одного состояния в другое (триггер, действие пользователя, изменение каналов, и т.д.).

[0199] TDO может включать в себя следующие четыре состояния. Четырьмя состояниями являются: Готовое, Активное, Приостановленное и Разъединенное. Активное состояние означает то, что TDO является исполняющим. Приостановленное состояние означает что TDO временно приостановлен по исполнению, с сохраненным его состоянием. Разъединенное состояние означает, что TDO не Готов, Активен или Приостановлен.

[0200] Нижеследующее является некоторыми событиями, которые могут вызвать изменение состояния для TDO:

[0201] 1. Trigger «подготовить» - Устройство принимает триггер (в выбранном в настоящий момент первичном виртуальном канале), который запрашивает, чтобы TDO был подготовлен к исполнению (выделить ресурсы, загрузить в основную память, и т.д.)

[0202] 2. Trigger «исполнить» - Устройство принимает триггер (в выбранном в настоящий момент первичном виртуальном канале), который запрашивает, чтобы TDO был активирован

[0203] 3. Trigger «приостановить» - Устройство принимает триггер (в выбранном в настоящий момент первичном виртуальном канале), который предписывает то, что TDO должен быть приостановлен

[0204] 4. Trigger «прекратить исполнение» - Устройство принимает триггер (в выбранном в настоящий момент первичном виртуальном канале), который предписывает то, что TDO должен быть завершен.

[0205] Фиг. 4 является схемой, показывающей вариант осуществления синтаксиса триггера.

[0206] Как сообщения Activation (Активация), так и сообщения Time Base (Координата времени) могут иметь общий формат «Trigger» при определенных обстоятельствах доставки.

[0207] Здесь синтаксическое определение описывается при помощи грамматики Дополненной Нормальной Формы Бэкуса-Наура, за исключением того, что символ вертикальной черты «|» используется для обозначения альтернатив. Правила отделяются от определений посредством равно «=», отступы используются для продолжения определения правила на более чем одной строке, литералы помещены в кавычки «», круглые скобки «(» и «)» используются для группировки элементов, опциональные элементы заключены в квадратные скобки «[» и «]», и элементам может предшествовать <n>* для обозначения n или более повторений следующего элемента; значение n по умолчанию равно 0. И элементам может предшествовать <n>*<m>, обозначая n или более повторений и m или менее повторений следующего элемента.

[0208] Данный синтаксис Trigger основан на Унифицированном Идентификаторе Ресурса (URI): Общий Синтаксис, за исключением участка <scheme> (схема) и «://», с дополнительными ограничениями.

[0209] Триггер может включать в себя locator_part (часть указателя) и terms (термы). Термы могут быть опущены. Если термы присутствуют, locator_part и термы могут быть соединены посредством '?'.

[0210] Locator_part может включать в себя часть hostname (имя хоста) и часть path_segments (сегменты пути), которые могут быть соединены посредством '/'.

[0211] Hostname может включать в себя domainlabel (метка домена) и toplabel (верхняя метка), и domainlabel может быть повторена 0 раз или более наряду с '.'. Т.е., hostname может включать в себя повторяющуюся domainlabel, соединенную с toplabel или включать в себя только toplabel.

[0212] Domainlabel может включать в себя alphanum (алфавитно-цифровой символ) или включать в себя alphanum или «-», неоднократно вставленный между alphanum и alphanum 0 раз или более.

[0213] Здесь, alphanum может означать alpha (алфавитный символ) или digit (цифра).

[0214] Здесь, alpha может быть одним из lowalpha (строчный алфавитный символ) или upalpha (прописной алфавитный символ).

[0215] Здесь, lowalpha может быть одним из a, b, c, d, e, f, g, h, i, j, k, 1, m, n, o, p, q, r, s, t, u, v, w, x, y, и z.

[0216] Здесь, upalpha может быть одним из A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, и Z.

[0217] Здесь, digit может быть одним из 0, 1, 2, 3, 4, 5, 6, 7, 8, и 9.

[0218] Toplabel включает в себя один alpha или включает в себя alphanum или «-» неоднократно вставленный между alpha и alphanum 0 раз или более.

[0219] Path_segments включают в себя один сегмент, за которым следует сегмент повторенный 0 раз или более. На этот раз, сегменты могут быть соединены посредством '/'.

[0220] Здесь, сегмент включает в себя alphanum, который повторяется единожды или более.

[0221] Термы могут включать в себя один из event_time или media_time, за которыми могут следовать spread (растяжение) и others (другие). spread и others могут быть опущены. Если spread и others присутствуют, то '&' может быть помещен впереди spread и others и spread и others могут быть помещены после event_time или media_time.

[0222] Здесь, spread может включать в себя digit, повторяемый единожды или более после 's='.

[0223] Event_time может включать в себя digit, повторяемый единожды или более после 'e=' или включать в себя hexdigit (шестнадцатеричная цифра), повторяемый единожды или более или семь раз или менее после '&t='. '&t=' и его задняя часть могут быть опущены.

[0224] Здесь, hexdigit может быть одним из 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e и f.

[0225] Media_time может включать в себя hexdigit, повторяемый единожды или более или менее семи раз после 'm='.

[0226] Others может включать в себя «other» (другой) или «other» за которым следует '&' и «other».

[0227] Здесь, other может включать в себя resv_cmd и alphanum, которые повторяется единожды или более и соединяются посредством '='.

[0228] Здесь, resv_cmd может быть alphanum, за исключением 'c', 'e', 'E', 'm', 'M', 's', 'S', 't', и 'T'.

[0229] Длинна триггера не может превышать 52 байта. В дополнение, участок hostname в Trigger может быть зарегистрированным доменным именем сети Интернет.

[0230] Можно считать, что Trigger включает в себя три части.

[0231] <domain name part> (часть доменного имени)/<directory path> (путь директории) [?<parameters>] (параметры)

[0232] <domain name part> может быть зарегистрированным доменным именем, <directory path> может быть путем, как он будет отображаться в URI.

[0233] <domain name part> может ссылаться на зарегистрированное доменное имя сети Интернет. <directory path> может быть произвольной строкой символов, идентифицирующей путь директории под управлением и администрированием объекта, который владеет правами на идентифицируемое доменное имя.

[0234] В модели TDO, сочетание <domain name part> и <directory path> может уникальным образом идентифицировать TPT, которая может быть обработана приемником для добавления интерактивности ассоциированному контенту.

[0235] Сочетание <domain name part> и <directory path> может быть URL местоположения в сети Интернет, где может быть получена TPT для текущего сегмента.

[0236] Т.е., триггер может идентифицировать TPT посредством использования <domain name part> и <directory path>. Посредством <domain name part> и <directory path>, существует возможность подтверждения TPT, к которой применяется триггер. Роль, которая выполняется посредством применения триггера к TPT, зависит от <parameters>.

[0237] Далее будет описана <parameters>.

[0238] <parameters> может включать в себя одно или более из «event_time», «media_time», или «spread»

[0239] Далее будут описаны, «event_time», «media_time», или «spread» синтаксиса, показанного на Фиг. 4.

[0240] event_time = «e=» l*digit [ «&t=» l*7hexdigit ]

[0241] media_time = «m=» 1*7hexdigit

[0242] spread = «s=» 1*digit

[0243] Терм «event_time» может быть использован в триггере Activation для идентификации целевого события (терм «e=») и времени, в которое должно быть активировано событие (терм «t=»). Когда терм «t=» отсутствует, это означает, что событие должно быть активировано в момент прибытия триггера.

[0244] Т.е., «e=», который является термом ID интерактивного события, может ссылаться на appID в ассоциированной TPT у TDO на который является целевым для события, eventID конкретного события, и dataID элемента Data (данные), которые должны быть использованы для данной активации события.

[0245] «t=», который является опциональным термом значения распределения во времени, может указывать новое распределение во времени времени мультимедиа для назначенного события. Если часть «t=» не присутствует, это может означать, что распределением во времени для назначенного события является время прибытия Trigger.

[0246] Терм «media_time» (терм «m=») может быть использован в триггере Time Base для идентификации текущего времени относительно координаты времени, представленной триггером Time Base. Информация идентификатора контента (терм «c=») для идентификации отображаемого в настоящий момент контента может быть дополнительно включен в media_time. Применительно к терму «c=», ниже будет описана модель непосредственного исполнения.

[0247] Т.е., «m=», который является термом временной метки мультимедиа, за которым следует строка символов из 1 до 8 символов в длину, представляющих собой шестнадцатеричное число, может указывать текущее Media Time.

[0248] Терм «spread» может быть использован для указания того, что любое действие, предпринятое в ответ на триггер Time Base (как например, извлечение TPT с сервера) или триггер Activation (как например, предписывающий TDO получить доступ к серверу), должны иметь задержку на произвольную величину времени, чтобы растягивать по времени загрузку сервера.

[0249] Терм «s=» может указывать количество секунд времени в течение которого все приемники должны предпринимать попытку доступа к Интернет серверу, идентифицируемому в Trigger. Можно предположить, что каждый индивидуальный приемник извлекает произвольное время в пределах назначенного интервала и задерживает запрос доступа на эту величину, тем самым растягивая по времени пик спроса, который в противном случае происходит при первом появлении Trigger на приемнике.

[0250] Trigger, содержащий параметр <media time> может именоваться триггером Time Base, поскольку он используется для установления координаты времени для моментов времени события.

[0251] Trigger содержащий параметр <event time> может именоваться Activation Trigger, поскольку он устанавливает время активации для события.

[0252] Фиг. 5 и Фиг. 6 являются схемами, показывающими вариант осуществления таблицы параметров TDO.

[0253] Таблица Параметров TDO (TPT) содержит метаданные о TDO сегмента и Event, нацеленных на них.

[0254] Далее, будут описаны поля, включенные в таблицу. Размеры полей и типы полей, включенных в таблицу, могут быть добавлены или изменены в соответствии с намерениями разработчика.

[0255] Подробная семантика полей в структуре TPT следующая.

[0256] Таблица параметров TDO (TPT) может включать в себя атрибут @majorProtocolVersion, @minorProtocolVersion, @id, @tptVersion, @expireDate, @updatingTime, @serviceID, @baseURL, элемент Capabilities (Возможности), LiveTrigger, и/или TDO.

[0257] TPT является корневым элементом TPT. Один элемент TPT описывает весь или участок (по времени) одного сегмента программ вещания.

[0258] MajorProtocolVersion, который может быть 4-битным атрибутом, может указывать номер основной версии определения таблицы. Номер основной версии может быть установлен равным 1. Предполагается, что приемники отбрасывают экземпляры TPT, указывающие значения основной версии, которые они не оборудованы поддерживать.

[0259] Когда присутствует, @MinorProtocolVersion, который может быть 4-битным атрибутом, может указывать номер дополнительной версии определения таблицы. Когда не присутствует, значение по умолчанию равно 0. Номер дополнительной версии может быть установлен равным 0. Предполагается, что приемники не отбрасывают экземпляры TPT, указывающие значения дополнительной версии, которые они не оборудованы поддерживать. В данном случае предполагается, что они игнорируют любые индивидуальные элементы или атрибуты, которые они не поддерживают.

[0260] @id, который является URI, может уникальным образом идентифицировать интерактивный сегмент программ вещания, к которому относится данный элемент TPT. @id служит в качестве идентификатора сегмента. Соответственно, после того как приемник анализирует TPT, триггер, AMT, и т.д., которые относятся к одному сегменту, он может сопоставить TPT с @id для идентификации сегмента, используя информацию @id. Соответственно, может быть найден сегмент, к которому будет применяться триггер и AMT. Подробности в отношении AMT будут описаны ниже.

[0261] @tptVersion, который может быть 8-битным целым числом, может указывать номер версии элемента TPT, идентифицируемого посредством атрибута id. tptVersion может быть увеличен всякий раз, когда вносятся любые изменения в TPT.

[0262] Когда присутствует, атрибут @expireDate элемента TPT может указывать дату и время истечения информации, включенной в данный экземпляр TPT. Если приемник кэширует TPT, то она может быть повторно использована до expireDate.

[0263] Когда присутствует, @updatingTime, который может быть 16-битным элементом, может указывать на то, что TPT подлежит пересмотру, и он задает рекомендованный интервал в секундах для загрузки TPT вновь и проверяет, является ли вновь загруженная TPT новой версией.

[0264] Когда присутствует, @serviceID, который может быть 16-битным целым числом, может указывать service_id NRT, ассоциированный с интерактивной услугой, описываемой в данном экземпляре TPT. Это требуется приемнику для получения параметров FLUTE из Таблицы Карты Услуги, когда файлы для данной интерактивной услуги доставляются в вещательном потоке.

[0265] Когда присутствует, атрибут @baseURL может задавать базовый URL, который когда прицепляется спереди любого относительного URL, который присутствует в данной TPT, может давать абсолютный URL файлов.

[0266] Когда присутствует, элемент Capabilities может указывать возможности, которые являются неотъемлемыми для содержательного представления интерактивной услуги, ассоциированной с данной TPT. Предполагается, что приемники, которые не обладают одной или более требуемыми возможностями, не пытаются предоставить услугу.

[0267] Элемент LiveTrigger присутствует если и только если доступна доставка Activation Trigger через сеть Интернет. Когда присутствует, он может предоставлять информацию, требуемую приемнику для получения Activation Trigger. Элемент-потомок и атрибут LiveTrigger будут описаны ниже.

[0268] TDO, который является элементом-потомком элемента TPT может представлять собой приложение (например, TDO), которое предоставляет часть интерактивной услуги в течение сегмента, описываемого данным экземпляром TPT. Элемент-потомок и атрибут TDO будут описаны ниже.

[0269] Элемент LiveTrigger может включать в себя атрибут @URL и/или @pollPeriod.

[0270] Как описано выше, элемент LiveTrigger присутствует, если и только если доступна доставка Activation Trigger через сеть Интернет. Когда присутствует, он может предоставлять информацию, требуемую приемнику для получения Activation Trigger.

[0271] @URL, который является атрибутом элемента LiveTrigger, может указывать URL сервера, который может доставлять Activation Trigger через сеть Интернет. Activation Trigger могут быть доставлены через сеть Интернет, используя короткий опрос HTTP, длинный опрос HTTP, или потоковую передачу HTTP, по выбору поставщика интерактивной услуги.

[0272] Когда присутствует, @pollPeriod, который является атрибутом элемента LiveTrigger, может указывать на то, что короткий опрос используется для доставки Activation Trigger, и значение атрибута pollPeriod может указывать рекомендованное время в секундах для приемника для использования в качестве периода опроса.

[0273] Если присутствует элемент LiveTrigger, приемник может анализировать TPT и получать информацию, используемую для доставки триггера активации при помощи сети Интернет. URL сервера, который может принимать триггер активации, может быть использован, используя информацию @URL. Посредством информации @pollPeriod или информации, указывающей на то, что атрибут @pollPeriod не присутствует, могут быть получены способ доставки триггера активации через сеть Интернет и информация о периоде опроса. @pollPeriod будет подробно описан ниже.

[0274] Элемент TDO может включать в себя атрибут @appID, @appType, @appName, @globalID, @app Version, @cookieSpace, @frequencyOfUse, @expireDate, @testTDO, @availInternet, @availBroadcast, элемент URL, Capabilities, Contentitem, и/или
Event.

[0275] Как описано выше, TDO, который является элементом-потомком элемента TPT, может представлять собой приложение (например, TDO), которое предоставляет часть интерактивной услуги в течение сегмента, описываемого данным экземпляром TPT.

[0276] @appID, который может быть 16-битным целым числом, может идентифицировать приложение уникальным образом в пределах объема TPT. Activation Trigger идентифицирует целевое приложение для Trigger посредством обращения к appID. @appID является идентификатором приложения. Одна TPT может включать в себя несколько приложений (таких как TDO). Соответственно, после анализа TPT, приложение может быть идентифицировано при помощи информации @appID. Триггер, AMT, и т.д., которые будут применяться к одному приложению, могут сопоставлять приложение с @appID для идентификации приложения. Соответственно, может быть найдено приложение, к которому будет применяться триггер и AMT. AMT будет более подробно описана ниже.

[0277] @appType, который может быть 8-битным целым числом, может указывать тип формата приложения. Значением по умолчанию может быть 1, которое может представлять TDO. Другие значения могут представлять другие форматы.

[0278] @appName, который является атрибутом элемента TDO, может быть понятным человеку именем, которое может быть отображено зрителю, когда испрашивается разрешение зрителя на запуск приложения.

[0279] @globalID, который является атрибутом элемента TDO, может быть глобальным уникальным идентификатором приложения. Во многих случаях приемник будет кэшировать приложение, которое собираются долго использовать повторно. Чтобы это было удобно, приемник должен иметь возможность распознавания приложения в следующий раз, когда оно появляется. globalID требуется приемнику, чтобы он имел возможность распознавания приложения, когда оно появляется вновь в новом сегменте.

[0280] @appVersion, который является атрибутом элемента TDO, может быть номером версии приложения. Значение appVersion может быть увеличено всякий раз, когда приложение (идентифицируемое globalID) меняется. Атрибут appVersion не может присутствовать, если не присутствует атрибут globalID.

[0281] @cookieSpace, который может быть 8-битным целым числом, может указывать то, сколько пространства требуется приложению для хранения постоянных данных между вызовами.

[0282] @frequencyOfUse, который является 4-битным целым числом, может указывать приблизительно насколько часто приложение будет использоваться при вещании, для предоставления подсказки приемникам касательно управления их пространством кэширования кода приложения. '@frequencyOfUse' будет подробно описан ниже.

[0283] @expireDate, который является атрибутом элемента TDO, может указывать дату и время, после которых приемник может безопасно удалять приложение и любые, относящиеся к нему ресурсы.

[0284] Когда присутствует со значение «истина», @testTDO, который является логическим атрибутом, может указывать на то, что приложение только для целей тестирования, и что оно может быть проигнорировано обычными приемниками.

[0285] Значение «истина» для атрибута @availInternet может указывать на то, что приложение доступно для загрузки через сеть Интернет. Значение «ложь» может указывать на то, что приложение не доступно для загрузки через сеть Интернет. Когда атрибут не присутствует, значением по умолчанию может быть «истина».

[0286] Значение «истина» для атрибута @availBroadcast может указывать на то, что приложение доступно для извлечения из вещания. Значение «ложь» может указывать на то, что приложение не доступно для извлечения из вещания. Когда атрибут не присутствует, значением по умолчанию может быть «истина».

[0287] Каждый экземпляр URL, элемента-потомка элемента TDO, может идентифицировать файл, который является частью приложения. Элемент URL может включать в себя атрибут @entry. @entry, атрибут элемента URL, имеет значение «истина», которое указывает на то, что URL является точкой входа для приложения - т.е., файлом, который может быть запущен для того, чтобы запустить приложение. Когда он имеет значение «ложь», это может указывать на то, что URL не является точкой входа для приложения. Значением по умолчанию, когда атрибут не представляется, может быть «ложь». Элемент URL, который является элементом-потомком элемента TDO, идентифицирует файл, конфигурирующий приложение как описано выше. Приемник анализирует TPT для получения информации URL, получает доступ к серверу, используя информацию URL, и загружает приложение, указываемое информацией URL.

[0288] Когда присутствует, Capabilities, который является элементом-потомком элемента TDO, может указывать возможности, которые являются неотъемлемыми для содержательного представления данного приложения. Предполагается, что приемники, которые не обладают одной или более требуемыми возможностями, не пытаются запускать приложение.

[0289] ContentItem, элемент-потомок элемента TDO, может указывать компонент контента, включающий в себя один или более файлы данных, которые требуются приложению. Элемент ContentItem обладает информацией о файлах данных, требуемых приложению, указываемому элементом TDO, к которому данный элемент принадлежит. Приемник может загружать файлы данных, требуемые приложению, используя информацию URL, и т.д. в ContentItem, если после анализа присутствует элемент ContentItem. Элемент-потомок и атрибут ContentItem будут описаны ниже.

[0290] Event, элемент-потомок элемента TDO, может представлять собой событие для приложения. Элемент Event указывает событие приложения, к которому данный элемент принадлежит. Элемент события содержит информацию, указывающую на то, какие присутствуют события, какие присутствуют данные, какие присутствуют действия, и т.д. Приемник может анализировать элемент события для получения информации о событии приложения. Элемент-потомок и атрибут события будут описаны ниже.

[0291] Приемник может принимать и анализировать TPT для получения элемента-потомка TDO и информации об атрибутах.

[0292] Элемент ContentItem, который является элементом-потомком элемента TDO, может включать в себя атрибут @updatesAvail, @pollPeriod, @size, @availInternet, @availBroadcast и/или элемент URL.

[0293] Здесь, элемент URL может включать в себя атрибут @entry. Каждый экземпляр URL, элемента-потомка элемента ContentItem, может идентифицировать файл, который является частью компонента контента. Элемент URL может включать в себя атрибут @entry. @entry, атрибут элемента URL, имеет значение «истина», которое может указывать на то, что URL является точкой входа для компонента контента - т.е., файлом, который может быть запущен для того, чтобы запустить компонент контента. Когда он имеет значение «ложь», это может указывать на то, что URL не является точкой входа для компонента контента. Значением по умолчанию, когда атрибут не предоставляется, может быть «ложь». Приемник может загружать файлы данных, требуемые приложению, используя информацию URL из ContentItem после анализа. В данном процессе, может быть использована информация, такая как в описанных выше других атрибутах.

[0294] @updatesAvail, который является логическим атрибутом элемента ContentItem, может указывать на то, будет или нет время от времени обновляться компонент контента - т.е., включает ли в себя компонент контента статические файлы или является ли он каналом данных в режиме реального времени. Когда значение соответствует «истина» компонент контента будет обновляться время от времени; когда значение соответствует «ложь», компонент контента не будет обновляться. Значением по умолчанию, когда данный атрибут не предоставляется, может быть ложь.

[0295] @pollPeriod, который является атрибутом элемента ContentItem, может присутствовать только когда значение атрибута updatesAvail соответствует «истина». Присутствие атрибута pollPeriod может указывать на то, что короткий опрос используется для доставки Activation Trigger, и значение атрибута pollPeriod может указывать рекомендуемое время в секундах для приемника для использования в качестве периода опроса.

[0296] @Size, который является атрибутом элемента ContentItem, может указывать размер компонента контента.

[0297] Значение «истина» для атрибута @availInternet может указывать на то, что компонент контента доступен для загрузки через сеть Интернет. Значение «ложь» может указывать на то, что компонент контента не доступен для загрузки через сеть Интернет. Когда данный атрибут не присутствует, значением по умолчанию может быть «истина».

[0298] Значение «истина» для атрибута @availBroadcast может указывать на то, что компонент контента доступен для извлечения из вещания. Значение «ложь» может указывать на то, что компонент контента не доступен для извлечения из вещания. Когда данный атрибут не присутствует, значением по умолчанию может быть «истина».

[0299] Элемент события содержит информацию о событии приложения, указываемого элементом TDO, к которому принадлежит элемент события. Приемник может анализировать элемент события для получения информации о событии.

[0300] Элемент события, который является элементом-потомком элемента TDO, может включать в себя атрибут @eventID, @action, @destination, @diffusion (рассеяния) и/или элемент Data. Здесь, элемент данных может включать в себя атрибут @dataID.

[0301] @eventID, который может быть 16-битным целочисленным атрибутом элемента Event, может идентифицировать событие уникальным образом в пределах объема элемента TDO его содержащего. Activation Trigger (или элемент активации в AMT) может идентифицировать целевое приложение и событие для Trigger посредством сочетания appID и eventID. Когда событие активируется, приемник анализирует событие в приложении. @eventID служит в качестве идентификатора события. Используя информацию @eventID, триггер, AMT и т.д., для активации события могут сопоставлять приложение с @eventID для идентификации события. Т.е., Activation Trigger (или элемент активации в AMT) может идентифицировать целевое приложение и событие для Trigger посредством сочетания appID и eventID. Когда событие активируется, приемник анализирует событие в приложении. AMT будет подробно описана ниже.

[0302] @action, который является атрибутом элемента Event, может указывать тип действия, которое должно быть применено, когда активируется событие. Разрешенными значения могут быть «prep», «exec», «susp», и «kill».

[0303] «prep» может соответствовать действию «Trig prep». Если состоянием целевого приложения является «Разъединенное», данное действие может вызвать изменение состояния на «Готовое».

[0304] «exec» может соответствовать действию «Trig exec». Состояние целевого приложения может стать «Активным» по приему данного триггера.

[0305] «susp» может соответствовать действию «Trig susp». Если состоянием целевого приложения является «Активное», состояние может измениться на «Приостановленное» по приему данного триггера, в противном случае изменение не происходит.

[0306] «kill» может соответствовать действию «Trig kill». Состояние целевого приложения может стать «Разъединенным» по приему данного триггера.

[0307] @action может указывать тип действия, которое должно быть применено, когда событие активируется.

[0308] @destination, который является атрибутом элемента Event, может указывать целевое устройство для события. @destination будет подробно описано ниже.

[0309] Когда присутствует, @diffusion, который может быть 8-битным целочисленным атрибутом элемента Event, может представлять период T времени в секундах. Целью параметра рассеяния является сглаживание пиков при нагрузке сервера. Можно предположить, что приемник вычисляет произвольное время в диапазоне 0-T, с приращениями в 10 миллисекунд, и выполняет задержку на данную величину перед получением доступа к Интернет серверу для извлечения контента, на который ссылаются URL в TPT.

[0310] Когда присутствует, Data, который является элементом-потомком элемента Event, может предоставлять данные, которые относятся к событию. Разные активации Event могут иметь разные элементы Data, ассоциированные с ними. Элемент данных может включать в себя атрибут @dataID. @dataID, который является 16-битным целочисленным атрибутом, может идентифицировать элемент Data уникальным образом в пределах объема элемента Event, его содержащего. Когда активация события имеет ассоциированные с ней данные, Activation Trigger может идентифицировать элемент Data посредством сочетания AppID, EventID, и DataID. Элемент данных указывает данные, используемые для события. Один элемент события может иметь несколько элементов данных. Данные идентифицируется при помощи атрибута @dataID элемента данных. В приемнике, если активируется событие, которое относится к данным, Activation Trigger (или элемент активации в AMT) может идентифицировать элемент Data посредством сочетания AppID, EventID, и DataID. AMT будет подробно описана ниже.

[0311] Фиг. 7 является схемой, показывающей смысл значений атрибута «Frequency of Use».

[0312] Столбец «Смысл» указывает частоту возникновения сегментов, которые содержат данное приложение. (Атрибут может появляться несколько раз в пределах одного сегмента, конечно). Атрибут frequencyOfUse не может присутствовать, если не присутствует атрибут globalID. Если планируют кэшировать приложение и использовать вновь позже, приемнику требуется распознать, что это то же самое приложение, когда оно появляется вновь. Это требует атрибута globalID.

[0313] Фиг. 8 является схемой, показывающей смысл значений атрибута «destination».

[0314] Как показано на Фиг. 8, значение атрибута destination равное 0 указывает «зарезервировано», значение атрибута destination равное 1 указывает только первичное устройство, значение атрибута destination равное 2 указывает только 2 одно или более вторичные устройства, и значение атрибута destination равное 3 указывает Первичное устройство и/или одно или более вторичные устройства.

[0315] Фиг. 9, Фиг. 10, Фиг. 11, Фиг. 12 и Фиг. 13 являются схемами, показывающими вариант осуществления синтаксиса двоичного вида Таблицы Параметров TDO.

[0316] Это двоичный формат описанной выше структуры TPT. Данная структура является форматом, который необходим при передаче TPT в NRT, и выполнен таким образом, что структура XML у TPT подходящим образом передается в NRT.

[0317] Следующие элементы и/или атрибуты, содержащиеся в версии XML TPT могут быть опущены в двоичной версии, поскольку они могут быть предоставлены в заголовке инкапсуляции для доставки двоичной таблицы в вещательном потоке: @protocolVersion (основная/дополнительная), @serviceID и/или @tptVersion.

[0318] Семантика полей является следующей. Поля двоичного формата таблицы параметров TDO с Фиг. 9, Фиг. 10, Фиг. 12 и Фиг. 13 будет описана последовательно.

[0319] expire_date_included, которое может быть 1-битным полем, может указывать на то, включено ли поле expire_date. Значение '1' может означать, что оно включено; значение '0' может означать, что оно не включено.

[0320] segment_id_length, которое может быть 5-битным полем, может указывать длину в байтах поля segment_id.

[0321] segment_id, которое является полем переменной длины, может содержать байты id сегмента, которые могут иметь точно такую же семантику, что и атрибут «id» в TPT формата XML.

[0322] base_URL_length, которое может быть 8-битным полем, может указывать длину в байтах поля base_URL.

[0323] base_URL, которое является полем переменной длины, может содержать байты базового URL, которые могут иметь точно такую же семантику, что и атрибут baseURL в TPT формата XML.

[0324] Когда присутствует, expire_date, которое может быть 32-битным полем, может указывать дату и время истечения информации, включенной в данный экземпляр TPT. Если приемник кэширует TPT, она может быть повторно использована до expireDate. Беззнаковая целочисленная величина может быть интерпретирована как число секунд GPS с момента 00:00:00 UTC, 06 января 1980 г., минус GPS-UTS_offset. GPS-UTC_offset может быть 8-битной беззнаковой целочисленной величиной, которая определяет текущее смещение в полных секундах между стандартами времени GPS и UTC.

[0325] trigger_server_URL_length, которое может быть 8-битным полем, может указывать длину в байтах поля trigger_server_URL. Когда значение данного поля равно 0, оно может указывать на то, что доставка по сети Интернет индивидуальных Activation Trigger недоступна.

[0326] trigger_server_URL, когда значение поля trigger_server_URL_length не равно 0, может содержать байты URL Сервера Trigger, которые могут иметь точно такую же семантику что и атрибут URL элемента LiveTrigger в TPT формата XML.

[0327] trigger_delivery_type, которое может быть 1-битным полем, может указывать режим доставки индивидуальных Activation Trigger через сеть Интернет. Значение '0' может указывать на то, что используется короткий опрос HTTP; значение '1' может указывать на то, что используется либо длинный опрос HTTP, либо потоковый HTTP.

[0328] poll_period, которое может быть 8-битным целым числом, может указывать рекомендуемое количество секунд между опросами, когда используется короткий опрос HTTP.

[0329] num_app_in_table, которое может быть 8-битным полем, может указывать количество приложений (TDO), описываемых в данном экземпляре TPT.

[0330] app_id, которое может быть 16-битным полем, может содержать идентификатор для данного приложения (приложения, описываемого в данной итерации num_app_in_table_loop). Оно может быть уникальным в пределах данного экземпляра TPT.

[0331] app_type_included, которое может быть 1-битным полем, может указывать на то, включено ли поле app_type для данного приложения. Значение '1' может означать, что оно включено; значение '0' может означать, что оно не включено.

[0332] app_name_included, которое может быть 1-битным полем, может указывать на то, включено ли поле app_name для данного приложения. Значение '1' может означать, что оно включено; значение '0' может означать, что оно не включено.

[0333] global_id_included, которое может быть 1-битным полем, может указывать на то, включено ли поле global_id для данного приложения. Значение '1' может означать, что оно включено; значение '0' может означать, что оно не включено.

[0334] app_version_included, которое может быть 1-битным полем, может указывать на то, включено ли поле app_version для данного приложения. Значение '1' может означать, что оно включено; значение '0' может означать, что оно не включено.

[0335] cookie_space_included, которое может быть 1-битным полем, может указывать на то, включено ли поле cookie_space для данного приложения. Значение '1' может означать, что оно включено; значение '0' может означать, что оно не включено.

[0336] frequency_of_use_included, которое может быть 1-битным полем, может указывать на то, включено ли поле frequency_of_use для данного приложения. Значение '1' может означать, что оно включено; значение '0' может означать, что оно не включено.

[0337] expire_date_included, которое может быть 1-битным полем, может указывать на то, включено ли поле expire_date для данного приложения. Значение '1' может означать, что оно включено; значение '0' может означать, что оно не включено.

[0338] Когда присутствует, app_type, которое может быть 8-битным полем, может указывать тип формата данного приложения. Значение 0 может указывать на то, что приложение является TDO. Если данное поле не присутствует, значение может по умолчанию интерпретироваться как 0. Прочие значения могут представлять собой другие форматы.

[0339] Когда присутствует, app_name_length, которое может быть 8-битным полем, может указывать длину в байтах поля app_name, которое немедленно следует за ним. Значение 0 для данного поля может указывать на то, что поле app_name не присутствует для данного приложения.

[0340] Когда присутствует, app_name, которое является полем переменной длины, может иметь точно такую же семантику что и атрибут appName элемента TDO в TPT формата XML.

[0341] Когда присутствует, global_id_length, которое может быть 8-битным полем, может указывать длину в байтах поля global_id, которое немедленно следует за ним. Значение 0 для данного поля может указывать на то, что поле global_id не присутствует для данного приложения.

[0342] Когда присутствует, global_id, которое является полем переменной длины, может иметь точно такую же семантику, что и у атрибута globalId элемента TDO в TPT формата XML.

[0343] Когда присутствует, app_version, которое может быть 8-битным полем, имеет точно такую же семантику, что и атрибут appVersion элемента TDO в TPT формата XML.

[0344] Когда присутствует, cookie_space, которое может быть 8-битным полем, может иметь точно такую же семантику, что и атрибут cookieSpace элемента TDO в TPT формата XML.

[0345] Когда присутствует, frequencu_of_use, которое может быть 8-битным полем, может иметь точно такую же семантику, что и атрибут frequencyOfUse элемента TDO в TPT формата XML.

[0346] Когда присутствует, expire_date, которое может быть 8-битным полем, может иметь точно такую же семантику, что и атрибут expireDate элемента TDO в TPT формата XML.

[0347] test_app, которое может быть 1-битным полем, может указывать на то, является или нет данное приложение тестовым приложением, которое должно игнорироваться обычными приемниками. Значение '1' может означать, что оно является тестовым приложением; значение '0' может означать, что оно не является тестовым приложением.

[0348] available_on_internet, которое может быть 1-битным полем, может указывать на то, доступно или нет данное приложение через сеть Интернет. Значение '1' может означать, что оно доступно через сеть Интернет; значение '0' может означать, что оно недоступно через сеть Интернет.

[0349] available_in_broadcast, которое может быть 1-битным полем, может указывать на то доступно или нет данное приложение через вещание. Значение '1' может означать что оно доступно через вещание; значение '0' может означать, что оно недоступно через вещание.

number_URL, которое может быть 4-битным полем, может указывать количество файлов, которое содержит данное приложение.

[0350] URL_length, которое может быть 8-битным полем, может указывать длину поля URL, которое следует за ним.

[0351] URL, которое является полем переменной длины, может иметь точно такую же семантику, что и атрибут URL элемента TDO в TPT формата XML.

[0352] number_content_items, которое может быть 8-битным полем, может указывать количество компонентов контента, которые должны быть загружены для использования данным приложением.

[0353] updates_avail, которое может быть 1-битным полем, может указывать, будет ли данный компонент контента обновляться время от времени - т.е., является ли он набором статических файлов или каналом данных в режиме реального времени. Значение '1' может указывать на то, что он будет обновляться; значение '0' может указывать на то, что он не будет обновляться.

[0354] avail_internet, которое может быть 1-битным полем, может указывать на то, может ли файл(ы), который содержит данный компонент контента, быть загружен через сеть Интернет или нет. Значение '1' может означать, что они доступны для загрузки через сеть Интернет; значение '0' может означать, что они недоступны.

[0355] avail_broadcast, которое может быть 1-битным полем, может указывать на то, может ли файл(ы), который содержит данный компонент контента, быть загружен через вещание или нет. Значение '1' может означать, что они доступны для загрузки через вещание; значение '0' может означать, что они не доступны.

[0356] content_size_included, которое может быть 1-битным полем, может указывать на то, включено или нет поле content_size для данного приложения. Значение '1' может означать, что оно включено; значение '0' может означать, что оно не включено.

[0357] number_URL, которое может быть 4-битным полем, может указывать количество файлов, которое содержит данное приложение.

[0358] URL_length, которое может быть 8-битным полем, может указывать длину поля URL, которое следует за ним.

[0359] URL, которое является полем переменной длины, может иметь точно такую же семантику, что и атрибут URL элемента-потомка ContentItem элемента TDO в TPT формата XML.

[0360] content_size, которое может быть 24-битным полем, может иметь точно такую же семантику, что и у атрибута contentSize элемента-потомка ContentItem элемента TDO в TPT формата XML. [0361] num_content_descriptors, которое может быть 8-битным полем, может указывать количество дескрипторов контента в цикле дескриптора, который немедленно следует за ним.

[0362] content_descriptor(), который является полем переменной длины, может быть дескриптором, согласующимся с форматом дескриптора MPEG-2 (тэг, длина, данные). Он может предоставлять дополнительную информацию о данном компоненте контента. Среди дескрипторов, которые могут быть включены в данный цикл дескриптора, могут быть дескриптор Capabilities, указывающий возможности приемника, требуемые для содержательного представления данного компонента контента.

[0363] number_events, которое может быть 8-битным полем, может указывать количество событий, определенных для данного TDO.

[0364] event_id, которое может быть 16-битным полем, может содержать идентификатор для данного события (события, описываемого в данной итерации цикла number_events). Оно может быть уникальным в пределах объема данного приложения. К событию можно обращаться в Activation Trigger посредством сочетания app_id и even_id.

[0365] action, которое может быть 5-битным полем, может иметь точно такую же семантику, что и у атрибута action элемента-потомка Event элемента TDO в TPT формата XML.

[0366] destination_included, которое может быть 1-битным полем, может указывать на то, включено или нет поле destination для данного события. Значение '1' может указывать, что оно включено; значение '0' может указывать, что оно не включено.

[0367] diffusion_included, которое может быть 1-битным полем, может указывать на то, включено или нет поле diffusion для данного события. Значение '1' может указывать, что оно включено; значение '0' может указывать, что оно не включено.

[0368] data_included, которое может быть 1-битным полем, может указывать на то, включены или нет поля data_size и data_bytes для данного события. Значение '1' может указывать, что они включены; значение '0' может указывать, что они не включены.

[0369] Когда присутствует, семантика поля destination может быть точно такой же, как у атрибута destination элемента-потомка Event элемента TDO в TPT формата XML.

[0370] Когда присутствует, семантика поля diffusion может быть точно такой же, как у атрибута diffusion элемента-потомка Event элемента TDO в TPT формата XML.

[0371] Когда присутствует, поле data_size может указывать размер поля data_bytes, которое немедленно следует за ним.

[0372] Когда присутствует, поле data_bytes может предоставлять данные, которые относятся в данному событию. Всякий раз, когда активируется событие, целевое приложение будет иметь возможность считывания данных и использования их для содействия при выполнении требуемого действия. Контент данного поля может быть идентичен контенту соответствующего элемента-потомка Data соответствующего элемента-потомка Event соответствующего элемента TDO в TPT формата XML, за исключением того, что данное поле может содержать необработанное двоичное значение, а элемент Data в TPT формата XML может содержать кодирование в формате base64 двоичного значения.

[0373] num_app_descriptors, которое может быть 8-битным полем, может указывать количество дескрипторов в цикле дескриптора, который немедленно следует за ним.

[0374] app_descriptor(), который является полем переменной длины, может быть дескриптором, согласующимся с форматом дескриптора MPEG-2 (тэг, длина, данные). Он может предоставлять дополнительную информацию о данном приложении (TDO). Среди дескрипторов, которые могут быть включены в данный цикл дескриптора, находится дескриптор Capabilities, указывающий приемнику возможности, требуемые для содержательного представления данного приложения.

[0375] num_TPT_descriptors, которое может быть 8-битным полем, может указывать количество дескрипторов в цикле дескриптора, который немедленно следует за ним.

[0376] TPT_descriptor(), которое является полем переменной длины, может быть дескриптором, согласующимся с форматом дескриптора MPEG-2 (тэг, длина, данные). Он может предоставлять дополнительную информацию о данной TPT. Среди дескрипторов, которые могут быть включены в данный цикл дескриптора, находится дескриптор Capabilities, указывающий приемнику возможности, требуемые для содержательного представления интерактивной услуги, представляемой данной TPT.

[0377] Фиг. 14 является схемой, показывающей вариант осуществления структуры таблицы сообщения активации. Далее, будут описаны поля, включенные в таблицу. Размер полей и типы полей, включенных в таблицу, могут быть добавлены или изменены в соответствии с замыслом разработчика.

[0378] Таблица Сообщений Активации (AMT) может содержать эквивалент Activation Trigger для сегмента. При определенных обстоятельствах она может быт доставлена приемникам вместо Activation Trigger. Триггер может быть доставлен в потоке скрытых субтитров, посредством серверов ACR, посредством сервера «триггера прямого эфира», и через AMT.

[0379] Подробная семантика полей в структуре AMT следующая:

[0380] Таблица Сообщений Активации (AMT) может включать в себя атрибут @majorProtocolVersion, @minorProtocolVersion, @segmentId, @beginMT и/или элемент Activation.

[0381] @majorProtocolVersion, который может быть 4-битным атрибутом элемента AMT, может указывать номер основной версии определения AMT. Номер основной версии может быть установлен равным 1. Можно предположить, что приемники отбрасывают экземпляры AMT, указывающие значения основной версии, которые они не оборудованы поддерживать.

[0382] Когда присутствует, @minorProtocolVersion, который может быть 4-битным атрибутом элемента AMT, может указывать номер дополнительной версии определения AMT. Когда не присутствует, значение может быть по умолчанию равно 0. Номер дополнительной версии может быть установлен равным 0. Можно предположить, что приемники не отбрасывают экземпляры AMT, указывающие значения дополнительной версии, которые они не оборудованы поддерживать. В данном случае можно предположить, что они игнорируют любые индивидуальные элементы или атрибуты, которые они не поддерживают.

[0383] @segmentId, который является идентификатором AMT, сопоставляет идентификатор TPT, которая содержит приложения и события, к которому применяется Activation данной AMT. @segmentId может служить в качестве идентификатора AMT. Соответственно, приемник может принимать и анализировать AMT для идентификации AMT посредством информации @segmentId. @segmentId содержит информацию, указывающую то, к какому сегменту применяется AMT, сопоставляет @id у TPT, которая относится к сегменту, и служит для соединения AMT и TPT. Кроме того, сегмент может быть идентифицирован для предоставления базовой информации, требуемой для идентификации целевого TDO и события элемента активации AMT.

[0384] Когда присутствует, @beginMT, который является атрибутом элемента AMT, может указывать начало Media Time сегмента для которого данный экземпляр AMT предоставляет времена активации. @beginMT может указывать начало времени мультимедиа по отношению к сегменту, к которому будет применяться AMT. Вследствие этого, существует возможность принятия решения в отношении критерия времени, когда происходит активация, указываемая элементом активации. Соответственно, если присутствует @beginMT, то атрибут @startTime в элементе активации может зависеть от начала времени мультимедиа, указываемого @beginMT.

[0385] Каждый экземпляр элемента Activation в AMT может представлять собой команду для активации определенного события в определенное время, с определенными данными, ассоциированными с событием. Множество элементов активации может быть представлено в AMT. Каждый элемент активации выполняет роль, подобную той, что у триггера активации. Элемент активации может применяться к сегменту, который указывается @segmentId в AMT. Атрибуты элемента активации могут содержать информацию о том, в каком приложении происходит активация, в каком событии происходит активация, когда происходит активация, и т.д. Атрибуты элемента активации подробно будут описаны ниже.

[0386] Элемент активации может включать в себя атрибут @targetTDO, @targetEvent, @targetData, @startTime и/или @endTime.

[0387] @targetTDO, который является атрибутом элемента активации, может сопоставлять атрибут appID элемента TDO в TPT, с которой ассоциирована AMT, тем самым идентифицируя целевое приложение для команды активации. @targetData может содержать информацию, к какому приложению применяется элемент активации AMT. Приемник, может принимать и анализировать AMT для получения @targetTDO и находить @appID в элементе TDO сопоставленной TPT для идентификации приложения, к которому будет применен элемент активации.

[0388] @targetEvent, который является атрибутом элемента Activation, может сопоставлять атрибут eventID элемента Event, который содержится в элементе TDO, идентифицируемом атрибутом targeTDO, тем самым идентифицируя целевое событие для команды активации. @targetEvent может содержать информацию о том, к какому событию какого приложения применяется элемент активации AMT. Приемник может принимать и анализировать AMT для получения @targetEvent и находить @eventID в элементе TDO сопоставленной TPT для идентификации события, к которому будет применяться элемент активации.

[0389] @targetData, который является атрибутом элемента Activation, может сопоставлять атрибут dataID элемента Data, который содержится в элементе Event, идентифицируемом атрибутами targetTDO и targetEvent, тем самым идентифицируя Data, который должен быть ассоциирован с целевым событием, когда применяется команда активации. @targetData может идентифицировать данные, которые относятся к целевому событию, когда применяется команда активации. Приемник может принимать и анализировать AMT для получения @targetData и @dataID в элементе события TPT.

[0390] @startTime, который является атрибутом элемента события, может указывать начало действительного периода времени для события относительно Media Time. Можно предположить, что приемники исполняют команду, когда Media Time достигает значения в startTimer, или как можно раньше после этого. @starTime может включать в себя время начала, когда происходит событие. Данное время начала основано на времени мультимедиа. Приемник может анализировать AMT для получения информации @startTime и подтверждения времени, когда происходит событие, используя @startTime. Приемник может активировать событие, если время мультимедиа достигает startTime на основании времени мультимедиа сегмента, идентифицируемого посредством @segmentId. Если starTime уже истекло, событие может быть активировано как можно раньше.

[0391] Когда присутствует, @endTime, который является атрибутом элемента события, может указывать конец действительного периода времени для события относительно Media Time. Можно предположить, что приемник не исполняет команду, когда Media Time проходит значение в endTime. @endTime может указывать время окончания события. Если время мультимедиа достигает endTime, приемник может не выполнять событие.

[0392] Элементы Activation в AMT могут появляться в очередности по возрастанию значений startTime.

[0393] Когда приемник активирует события в соответствии с Activation в AMT, можно предположить, что он применяет каждую активацию в ее startTime, или как можно раньше после этого (например, в случае, когда приемник присоединяется к услуге и принимает AMT в некоторый момент времени после startTime и перед endTime). Если атрибут «action» элемента события в TPT соответствует «exec», тогда можно предположить, что приемник проходит к TriggerEvent в целевом приложении. TriggerEvent будет описан ниже в части, которая относится к API.

[0394] Фиг. 15 является схемой, показывающей вариант осуществления структурной схемы Список URL.

[0395] Список URL может содержать URL потенциального использования приемником. Список URL может включать в себя следующие URL, и т.д.

[0396] 1. URL для TPT для одного или более будущих сегментов, позволяющий приемнику предварительно загружать файлы.

[0397] 2. URL Сервера Сигнализации NRT, из которого может быть извлечена информация об автономных услугах NRT в вещательном потоке, позволяющий приемнику получать доступ к этим услугам даже если он не имеет доступа к доставке сигнализации услуги NRT в вещательном потоке.

[0398] 3. URL Сервера Отчетности по Использованию, на который могут быть отправлены отчеты по использованию для виртуального канала, позволяющий приемнику отправлять в таких отчетах даже, если он не имеет доступа к доставке данного URL в вещательном потоке.

[0399] 4. URL Таблицы PDI-Q для виртуального канала, позволяющий приемнику персонализировать восприятие от просмотра даже, если он не имеет доступа к Таблице PDI-Q, которая доставляется в вещательном потоке. (Таблица PDI-Q относится к персонализации для предоставления услуги настроенной для пользователя при предоставлении интерактивной услуги. Существует возможность опроса пользователя о персонализации через таблицу PDI-Q).

[0400] Среди прочего, список URL может быть выполнен в отношении элемента UsrUrl с тем, чтобы дополнительно указать URL сервера для отчетности по использованию, для того, чтобы использовать предпочтительные данные и тип контента просматриваемого и потребляемого в настоящий момент посредством приемника в деле. Элемент UrsUrl, включенный в список URL, может по-разному интерпретироваться в соответствии со следующим.

[0401] Во-первых, в случае сервера отчетности по использованию, приемник может выполнять функцию отчетности по использованию приемника посредством предварительно определенного протокола (например, структуры данных, файла XML, и т.д.) с URL сервера отчетности по использованию.

[0402] Во-вторых, может существовать TDO исполняемый в web-браузере приемника. В данном случае, это указывает местоположение TDO Отчетности по Использованию. В данном случае, TDO может непосредственно собирать и представлять отчет по информации о контенте, который хранится в приемнике или потребляется в настоящий момент, используя API (например, API файла или API отчетности по использованию) web-браузера приемника. TDO может передавать собранные данные, используя Javascript API, именуемый XMLHttpRequest.

[0403] URLlist может включать в себя UrlList, TptUrl, UrsUrl, и/или PdiUrl. Семантика этих элементов следующая.

[0404] TptUrl, который является элементом элемента UrlList, может содержать URL TPT для будущего сегмента в текущей интерактивной вспомогательной услуге. Когда включено несколько элементов TptUrl, они могут быть скомпонованы в очередности появления сегментов в вещании.

[0405] NrtSignalingUrl, который является элементом элемента UrlList, может содержать URL сервера, от которого приемники могут получать таблицы сигнализации NRT для всех виртуальных каналов в текущем транспортном потоке.

[0406] UrsUrl, который является элементом элемента UrlList, может содержать URL сервера, которому приемники могут отправлять отчеты по использованию (исследование аудитории) применительно к текущему виртуальному каналу.

[0407] PdiUrl, который является элементом элемента UrlList, может содержать URL таблицы PDI-Q применительно к текущему виртуальному каналу.

[0408] Фиг. 16 является схемой, показывающей вариант осуществления двоичного формата для частных секций, содержащих TPT. Фиг. 16 иллюстрирует случай, при котором TPT доставляется в вещательном потоке при механизме доставки, который будет описан ниже. Подробности описываются позже.

[0409] Будет приведено описание механизма доставки для доставки триггера, TPT, и т.д. Последовательно будет описан Вывод из Создания Интерактивной Услуги, Доставка Trigger в Вещательном Потоке, Доставка триггеров Time Base через сеть Интернет, Доставка Activation Trigger через сеть Интернет (Сценарий ACR), Доставка TPT в Вещательном Потоке, Доставка TPT через сеть Интернет, Перемещение TDO и Компонентов Контента, Объединение Нескольких Сегментов в Один Сегмент.

[0410] Далее, будет описан Вывод из Создания Интерактивной Услуги.

[0411] Процесс создания услуги для сегмента может иметь результатом папку, содержащую все TDO и прочие компоненты контента, файл TPT в формате XML и файл AMT в формате XML. Могут быть созданы другие результаты.

[0412] Далее, будет описана Доставка Trigger в Вещательном Потоке.

[0413] Когда доставляются в вещательном потоке, Trigger могут быть доставлены в канале Скрытых Субтитров DTV, в Услуге #6, в команде URLString.

[0414] Если Trigger меньше либо равен в длину 26 символам, он может быть отправлен не сегментированным (Тип=11). Если Trigger в длину составляет от 27 до 52 символов, он может быть отправлен в двух сегментах (первый сегмент в сегменте Типа=00, а второй сегмент в сегменте Типа=10).

[0415] Тип URI, доставляемого в любом заданном экземпляре команды, может быть задан посредством 8-битного параметра.

[0416] Для интерактивных услуг использующих модель TDO, тип URI структуры данных URI может быть установлен равным 0 (Trigger Интерактивного TV для модели TDO). Данный механизм доставки включает в себя как триггеры Time Base, так и Activation Trigger.

[0417] В случае, при котором триггер координаты времени доставляется через вещательный поток (в услуге #6 скрытых субтитров), если терм «m=» отсутствует, триггеры Time Base могут просто доставлять URL Сервера Сигнализации. И если терм «m=» отсутствует, тогда терм «t=» должен отсутствовать в триггерах Activation.

[0418] В случае, когда триггер активации доставляется через вещательный поток (в услуге #6 закрытых субтитров), т.е., в случае формата «Trigger», с термом «e=», с или без термом «t=», если терм «t=» присутствует, время активации может быть временной меткой, относительно координаты времени. А если терм «t=» отсутствует, время активации может быть временем прибытия сообщения.

[0419] В случае, когда триггер координаты времени и триггер активации доставляются через услугу #6 СС, у вещательных компаний может существовать три возможных способа для обработки триггеров Time Base и Activation. Тремя способами являются 'Режим сегмента без явной координаты времени', 'Режим сегмента с явной координатой времени' и 'Режим услуги с явной координатой времени'.

[0420] Они могут быть смешаны в пределах вещания, на основе сегмент за сегментом.

[0421] В режиме сегмента без явной координаты времени, сообщения Activation не включают в себя временную метку, так что временем активации каждого сообщения может быть время доставки сообщения, и сообщения Time Base также не включают в себя временную метку, так что их единственной целью может быть предоставление URL Сервера Сигнализации, который может доставлять файлы TPT. Сообщения Time Base даже могут быть полностью опущены в данном режиме, опираясь на URL в сообщениях Activation для предоставления URL Сервера Сигнализации, но тогда приемники будут не иметь возможности извлечения TPT и начала загрузки TDO кроме как после того как появляется первое сообщение Activation, задерживая на немного ответ на первое сообщение Activation.

[0422] В данном случае сообщения Time Base, которые могут появляться в услуге #6 CC, могут содержать «locator_part» формата «Trigger» и возможно терм «spread», но не терм «media_time», а сообщения Activation, которые могут появляться в услуге #6 CC, могут содержать «locator_part» формата «Trigger», терм «event_time», и возможно терм «spread», но без части «t=» в терме «event_time». «locator_part» в сообщениях как Time Base, так и Activation может быть текущим segmentId. Данный URL также может быть использован для извлечения TPT для сегмента через сеть Интернет.

[0423] В режиме сегмента с явной координатой времени, сообщения Time Base включают в себя временную метку, для определения координаты времени, и сообщения Activation могут включать временную метку, для определения времени активации относительно координаты времени, или они могут не включать в себя временную метку, указывая на то, что временем активации является время прибытия сообщения.

[0424] В данном случае сообщения Time Base, которые могут появляться в услуге #6 CC, могут содержать «locator_part» формата «Trigger», терм «media_time», и возможно терм «spread», а сообщения Activation, которые могут появляться в услуге #6 CC, могут содержать «locator_part» формата «Trigger», терм «event_time», и возможно терм «spread», с или без части «t=» в терме «event_time». «locator_part» сообщений как Time Base, так и Activation может быть текущим segmentId, а координата времени конкретной для сегмента. Данный URL также может быть использован для извлечения TPT для сегмента через сеть Интернет.

[0425] В режиме услуги с явной координатой времени, сообщения Time Base включают в себя временную метку, для определения координаты времени, а сообщения Activation могут или не могут включать в себя временную метку. Координата времени может проходить по нескольким сегментам, вместо того, чтобы быть конкретной для одного сегмента. «locator_part» сообщения Time Base может быть идентификатором координаты времени, а также URL, который может быть использован для извлечения TPT для услуги через сеть Интернет.

[0426] В любом случае Услуга Вставки Trigger, которая вставляет триггеры в услугу #6 CC, должна работать из AMT, переводя сообщения Activation из формата XML в AMT в формат триггера, указанный для доставки в услуге #6 CC. В случае элемента Activation без атрибута endTime, один триггер может быть вставлен со временем активации равным атрибуту startTime. В случае элемента Activation с элементами как startTime, так и endTime, с той же целью может быть вставлена последовательность триггеров. Первый триггер в последовательности может иметь время активации равное атрибуту startTime, последний триггер в последовательности может иметь время активации равное атрибуту endTime, и может присутствовать фиксированный интервал времени между временами активации триггеров в последовательности (за исключением того, что интервал между следующим за последним и последним триггером в последовательности может быть короче). Продолжительность данного фиксированного интервала времени может быть конфигурируемой.

[0427] Когда сообщения Time Base и Activation находятся в режиме сегмента, координата времени может быть конкретной для сегмента. Она может начинаться со значения «beginMT» в начале сегмента, и проходить через сегмент. Значения «startTime» и «endTime» отдельных Activation могут быть относительными к значению «beginMT». Когда сообщения Time Base и Activation находятся в режиме услуги, координата времени может охватывать сегменты, и значение «beginMT» для каждого сегмента может быть отрегулировано для учета координаты времени услуги и расписания вещания.

[0428] Далее, будут описана Доставка триггеров Time Base через сеть Интернет.

[0429] Интернет доставка триггеров Time Base может быть полезна в так называемых ситуациях Автоматического Распознавания Контента (ACR), где адресат триггеров Time Base не имеет доступа к услуге #6 Закрытых Субтитров. В данных ситуациях приемнику требуется использовать ACR для того, чтобы распознать видео кадры и синхронизировать координату времени с ними. В ситуациях ACR сообщения Time Base могут быть получены из водяных знаков или от серверов ACR. В случае прием от сервера ACR, сообщения Time Base доставляются в качестве ответов от сервера ACR.

[0430] Далее, будет описана Доставка Activation Trigger через сеть Интернет (Сценарий ACR).

[0431] Сообщения активации могут быть доставлены посредством короткого опроса, длинного опроса или потоковой передачи, но все эти способы могут накладывать много служебной информации на приемники и сервер. Сообщения Activation также могут быть доставлены в форме AMT, но это может предоставлять большое количество информации о длине сегментов, содействуя средствам устранения рекламы. Могут существовать другие альтернативы.

[0432] В случае, при котором сообщение активации доставляется в форме триггера активации, т.е., в случае формата «Trigger» с термом «e=», с или без терма «t=», это может быть доставлено через короткий опрос, длинный опрос или потоковую передачу HTTP.

[0433] Когда доставляются через сеть Интернет, сообщения Activation могут быть доставлены используя любой из или оба механизма, а именно механизм Индивидуальной Доставки Activation Trigger и механизм Массовой Доставки Activation Trigger.

[0434] Далее, будет описана Индивидуальная Доставка Activation Trigger.

[0435] Как описано выше, когда индивидуальные Activation Trigger доставляются через сеть Интернет, они могут быть доставлены, используя короткий опрос, длинный опрос и потоковую передачу HTTP. Формат Activation Trigger может быть точно таким же, как когда они доставляются через услугу #6 CC DTV.

[0436] В случае короткого опроса, должен быть указан период опроса. В этот период, операция короткого опроса может быть установлена, используя pollPeriod, включенный в TPT, как описывается ниже.

[0437] Когда Интернет доставка Activation Trigger доступна, атрибут URL элемента LiveTrigger в TPT может указывать Сервер Activation Trigger, который может доставлять триггер активации. Если атрибут pollPeriod элемента LiveTrigger присутствует в TPT, это может указывать на то, что используется короткий опрос HTTP, и может указывать период опроса, который должен использовать приемник. Если атрибут pollPeriod элемента LiveTrigger не присутствует в TPT, это может указывать на то, что используется либо длинный опрос HTTP, либо потоковая передача HTTP.

[0438] Независимо от того, какой протокол используется, можно предположить, что приемник выдает HTTP запрос Серверу Activation Trigger с помощью терма запроса:

[0439] ?mt=<media_time>

[0440] где <media_time> может быть текущим временем мультимедиа просматриваемого контента.

[0441] Если используется короткий опрос, ответ от Сервера Activation Trigger может содержать все Trigger, которые были выданы в пределах интервала времени длиной pollPeriod, заканчивающегося в <media_time>. Если возвращается более одного Activation Trigger, они могут быть разделены посредством одного или более символов пробела. Если не возвращается ни один из Activation Trigger, ответ может быть пустым.

[0442] Если используется длинный опрос HTTP или потоковая передача HTTP, Сервер Activation Trigger может ожидать по возврату ответа до момента времени мультимедиа, когда будет доставляться Activation Trigger в вещательном потоке. На этот раз он может возвращать Activation Trigger.

[0443] Если используется длинный опрос HTTP, Сервер Activation Trigger может закрывать сеанс после возвращения Activation Trigger. Можно предположить, что приемник немедленно выдает другой запрос, с обновленным временем мультимедиа.

[0444] Если используется потоковая передача HTTP, Сервер Activation Trigger может сохранять сеанс открытым после возвращения каждого Activation Trigger, и он может доставлять дополнительные Activation Trigger в течении сеанса по мере того как наступает время их доставки.

[0445] Во всех случаях, HTTP ответ может содержать Поле Заголовка HTTP Ответа одного из следующих видов для сигнализации режима доставки:

[0446] ATSC-Delivery-Mode: ShortPolling [<poll-period>] (Короткий опрос)

[0447] ATSC-Delivery-Mode: LongPolling (Длинный опрос)

[0448] ATSC-Delivery-Mode: Streaming (Потоковая передача)

[0449] Параметр <poll-period> может указывать рекомендуемый интервал между опросами для последующих опросов. <poll-period> может быть опущен.

[0450] Далее будет описана Массовая Доставка Activation Trigger

[0451] Когда Activation Trigger доставляются через сеть интернет в массе, Activation Trigger для сегмента могут быть доставлены через HTTP наряду с TPT для сегмента, в виде MIME-сообщения из нескольких частей, с TPT в качестве первой части сообщения, и Таблицей Сообщений Активации (AMT) в качестве второй части сообщения.

[0452] Далее, будет описана Доставка TPT в Вещательном Потоке.

[0453] Когда доставляются в вещательном потоке, TPT могут быть переведены из их формата XML в эквивалентный двоичный NRT-стиля формат таблицы сигнализации и инкапсулированы в NRT-стиля частные секции, одна TPT на экземпляр таблицы. Всегда присутствует TPT для текущего сегмента. Также могут присутствовать TPT для одного или более будущих сегментов. Экземпляр TPT определяется посредством значения его поля segment_id. Для справки, выше был описан двоичный формат таблицы параметров TDO. Здесь, NRT-стиля частная секция может соответствовать tpt_section() с Фиг. 16.

[0454] И так, чтобы передать двоичную структуру TPT в NRT, TPT может иметь структуру секции, пригодную для передачи NRT. Далее, подробно будет описан данный процесс.

[0455] Каждая TPT может быть инкапсулирована в NRT-стиля частные секции посредством разделения каждой TPT на блоки и вставки блоков в поля tpt_bytes() секций, которые имеют общее значение полей table_id, protocol_version, TPT_data_version и sequence_number. Блоки могут быть вставлены в секции в очередности возрастания значений поля section_number. Частные секции могут быть перенесены в Канале Сигнализации Услуги (SSC) IP-подсети виртуального канала, к которому относится TPT. Здесь, «Канал Сигнализации Услуги» определяется в стандарте ATSC-NRT и означает канал с конкретным IP-адресом и номером порта. Поля sequence_number в секциях могут быть использованы для того, чтобы различать разные экземпляры TPT, переносимые в одной и той же SSC.

[0456] Далее, будут описаны поля с Фиг. 16.

[0457] Частная секция (tpt_section()) может включать в себя table_id, protocol_version, sequence_number, TPT_data_version, current_next_indicator, section_number, last_section_number, service_id, и/или tpt_bytes() информацию.

[0458] table_id, которое может быть 8-битным полем, может идентифицировать данную секцию таблицы как принадлежащую к экземпляру Таблицы Параметров TDO.

[0459] protocol_version может быть разделено на две части. 4 бита старшего порядка из 8-битного беззнакового целочисленного поля могут указывать номер основной версии определения данной таблицы и экземпляра TPT переносимого в ней, а 4 бита младшего порядка могут указывать номер дополнительный версии. Номер основной версии может быть установлен равным 1. Можно предположить, что приемники отбрасывают экземпляры AMT, указывающие значения основной версии, которые они не оборудованы поддерживать. Номер дополнительной версии может быть установлен равным 0. Можно предположить, что приемники не отбрасывают экземпляры AMT, указывающие значения дополнительной версии, которые они не оборудованы поддерживать. В данном случае, можно предположить, что они игнорируют любые дескрипторы, которые они не распознают, и игнорируют любые поля, которые они не поддерживают.

[0460] sequence_number может быть 8-битным полем. Значение sequence_number может быть точно таким же, как sequence_number всех других секций данного экземпляра TPT и отличаться от sequence_number всех секций любого другого экземпляра TPT в данном Канале Сигнализации Услуги. Соответственно, данное поле может выполнять роль отличную от той, что в другом экземпляре TPT. Поле sequence_number может указывать IP подсети, ассоциированный с каналом сигнализации услуги в данной секции. Значения полей sequence_number разных экземпляров TPT могут отражать очередность, в которой сегменты появляются в вещательном потоке.

[0461] TPT_data_version, которое может быть 5-битным полем, может указывать номер версии данного экземпляра TPT, где экземпляр TPT может быть определен посредством его segment_id. Поскольку версия TPT известна заранее для того, чтобы выявлять, являются ли данные секции TPT новой версией TPT, поле TPT_data_version может присутствовать в таблице секции. Номер версии может увеличиваться на 1 по модулю 32, когда изменяется любое поле в экземпляре TPT.

[0462] current_next_indicator, который может быть 1-битным индикатором, может быть всегда установлен равным '1' для секций TPT, указывая на то, что отправленная TPT всегда является текущей TPT для сегмента, идентифицируемого посредством его segment_id.

[0463] section_number, которое может быть 8-битным полем, может задавать номер секции для данной секции экземпляра TPT, где экземпляр TPT может быть идентифицирован посредством его segment_id. section_number первой секции в экземпляре TPT может соответствовать 0x00. section_number может быть увеличен на 1 с каждой дополнительной секцией в экземпляре TPT.

[0464] last_section_number, которое может быть 8-битным полем, может задавать номер последней секции (т.е., секции с наивысшим section_number) экземпляра TPT частью которого является данная секция.

[0465] service_id, которое может быть 16-битным полем, может указывать service_id ассоциированный с интерактивной услугой, предлагающей компоненты контента, описываемые в данном экземпляре таблицы.

[0466] tpt_bytes(), которое является полем переменной длины, может включать в себя блок экземпляра TPT, переносимый частично данной секцией. Когда поля tpt_bytes() всех секций данного экземпляра таблицы сцеплены в очередности их полей section_number, результатом может быть полный экземпляр TPT.

[0467] Т.е., после того как используется двоичный формат TPT или формат XML изменяется на двоичный формат, TPT может быть разделена, чтобы подходить для передачи NRT, заключена в поле tpt_bytes() частной секции, и передана в NRT. На этот раз, если одна TPT делится на несколько частных секций, частная секция может иметь точно такое же значение table_id, protocol_version, TPT_data_version и sequence_number. Разделенные блоки TPT могут быть вставлены в очередности значений поля section_number.

[0468] Приемник может анализировать принятые частные секции. Для того чтобы объединить частные секции вновь в одну TPT, могут быть использованы частные секции с одинаковыми значениями table_id, protocol_version, TPT_data_version и sequence_number. На этот раз, может быть использована информация об очередности, которую можно получить из информации section_number и last_section_number. Если последовательно соединяются tpt_bytes() всех частных секций с одинаковыми значениями table_id, protocol_version, TPT_data_version и sequence_number, может быть создана одна TPT.

[0469] Со ссылкой на Фиг. 17 будет подробно описана доставка TPT через сеть Интернет.

[0470] Далее будет описано Перемещение TDO и Компонентов Контента.

[0471] Сетям и станциям часто будет требоваться предоставлять свои собственные HTTP серверы для доставки TDO и компонентов контента (файлов), используемых TDO. Когда это происходит, baseURL в TPT может быть отрегулировано для отражения местоположения сервера.

[0472] Далее, будет описано Объединение Нескольких Сегментов в Один Сегмент.

[0473] Для того чтобы тщательно скрыть границы между сегментами, TPT и AMT для нескольких сегментов могут быть объединены в единую TPT и AMT. Могут быть выполнены следующие этапы.

[0474] 1. Идентифицируют набор сегментов, которые должны быть объединены.

[0475] 2. Создают новую TPT с новым segmentId.

[0476] 3. Если любой из объединенных сегментов имеет активации в прямом эфире, предоставляют сервер-ретранслятор, который предоставляет доступ ко всем из них, и помещают параметры для данного сервера в элемент «LiveTrigger».

[0477] 4. Применяют baseURL для каждого сегмента при необходимости для получения полных TDO URL и ContentItem. (Может существовать возможность идентификации более короткого baseURL, который является общим для всех объединяемых сегментов, и сохранения его в качестве baseURL для объединенного сегмента).

[0478] 5. Исправляют значения appId при необходимости для удаления конфликтов.

[0479] 6. Вставляют в новую TPT все исправленные элементы TDO для всех объединяемых сегментов.

[0480] 7. Создают новую AMT с segmentId равным новому segmentId объединенной TPT.

[0481] 8. Выбирают соответствующее новое значение «beginMT» для новой AMT.

[0482] 9. Регулируют значения targetId всех элементов Activation в файлах AMT для объединенных сегментов для отражения любых изменений в значениях appId.

[0483] 10. Регулируют значения startTime и endTime всех элементов Activation в файлах AMT для объединенных сегментов для отражения нового значения «beginMT» и расписание вещания для объединенных сегментов.

[0484] 11. Вставляют исправленные элементы Activation в новую AMT.

[0485] Фиг. 17 является схемой, показывающей вариант осуществления по меньшей мере URL, закодированных в качестве документа XML.

[0486] Далее будет описана Доставка TPT через сеть Интернет.

[0487] Когда доставляются через сеть Интернет, TPT могут быть доставлены через HTTP. URL у TPT для текущего сегмента может быть «<domain name part>/<directory path>» в сообщении Time Base. Ответ на запрос в отношении TPT может включать в себя только TPT, или он может включать в себя сообщение MIME из 2 частей, с запрашиваемой TPT в первой части и списком URL во второй части, закодированное в качестве документа XML. (Ответ на запрос всегда будет включать в себя TPT для текущего сегмента. Он, впрочем, может включать в себя TPT для одного или более будущих сегментов).

[0488] URL, как вторая часть описанного выше ответа, могут иметь формат, показанный на Фиг. 17.

[0489] Будет описана семантика элементов с Фиг. 17.

[0490] «UrlList» может содержать список URL, которые полезны для приемника.

[0491] «TptUrl» может содержать URL для TPT применительно к будущему сегменту. Когда включено несколько элементов TptUrl, они могут быть скомпонованы в очередности появления сегментов в вещании.

[0492] «NrtSignalingUrl» может содержать URL сервера, где приемники могут получать таблицы сигнализации NRT для всех виртуальных каналов в текущем вещательном потоке.

[0493] Фиг. 18 является схемой, показывающей вариант осуществления addTriggerEventListener.

[0494] Далее, будет описаны ATSC JavaScript API применительно к среде для исполнения DO.

[0495] Чтобы обеспечивать синхронизацию действий Декларативного Объекта с вещанием программ вещания, дополнительные способы могут поддерживаться для видео/вещательного объекта.

[0496] Если TPT принимается через DTVCC или сеть Интернет, в TPT может присутствовать несколько событий для исполнения TDO и эти события могут быть активированы посредством триггера активации.

[0497] Для того чтобы обработать данное событие на основе каждого eventID может быть зарегистрирована функция Listener (Перехватчик). Соответственно, в качестве описанных выше 'дополнительных способов' могут присутствовать две функции, addTriggerEventListener и removeTriggerEventListener, для регистрации функции Listener.

[0498] На Фиг. 18, описывается addTriggerEventListener и показаны форматы, аргументы и т.д.

[0499] Функция addTriggerEventListener может регистрировать функцию обратного вызова (функция listener) для обработки события, генерируемого на основе каждого из eventId. Функция addTriggerEventListener может принимать в качестве аргумента listener типа EventListener и eventId типа Number. Ниже будет описан тип eventListener. Функция addTriggerEventListener может не иметь возвращаемого значения (void). Здесь аргумент eventId может быть ID события в элементе события в TPT. Здесь, аргумент listener может быть перехватчиком для события.

[0500] Модуль обработки триггера приемника может регистрировать функцию listener на основе каждого eventId используя функцию «addTriggerEventListener» как только принимается сообщение активации. Если активируется событие, может быть вызвана зарегистрированная функция listener. На этот раз, объект типа TriggerEvent может быть доставлен функции listener. Тип TriggerEvent будет описан ниже.

[0501] Фиг. 19 является схемой, показывающей вариант осуществления removeTriggerEventListener.

[0502] На Фиг. 19, описывается removeTriggerEventListener и показаны формат, аргументы, и т.д.

[0503] Функция removeTriggerEventListener может отменять регистрацию функции обратного вызова (функция listener) для обработки события, генерируемого на основании каждого eventId. Функция removeTriggerEventListener может принимать в качестве аргумента listener типа EventListener и eventId типа Number. Тип eventListener будет описан ниже. Функция removeTriggerEventListener может не иметь возвращаемого значения (void). Здесь аргумент eventId может быть ID события в элементе события в TPT. Здесь, аргумент listener может быть перехватчиком для события.

[0504] В программе javascript, если в отношении события, которое может быть сгенерировано на основании каждого eventId, не требуется чтобы оно далее принималось или если закончена программа «DestroyWindow», может быть отменена функция listener, зарегистрированная при помощи «removeTriggerEventListener».

[0505] Фиг. 20 является схемой, показывающей вариант осуществления определения типа EventListener.

[0506] Здесь, определение типа EventListener соответствует Web-Языку Определения Интерфейса (Web IDL). Web IDL может быть использован для описания интерфейсов, которые предназначены быть реализованными в web-браузерах. Web IDL является вариантом IDL с некоторым количеством особенностей, которые позволяют более быстро указать поведения общих объектов сценария в web-платформе.

[0507] EventListener может быть объектом интерфейса. Тип EventListener может иметь в качестве аргумента событие типа TriggerEvent.

[0508] Фиг. 21 является схемой, показывающей вариант осуществления определения типа TriggerEvent.

[0509] Тип TriggerEvent может содержать информацию о событии.

[0510] Тип TriggerEvent может иметь в качестве свойств eventId, data и status (статус). Здесь eventId может быть eventID в элементе события TPT. Здесь, data могут быть данными для данной активации события. Здесь, data могут быть в шестнадцатеричной системе исчисления. Здесь, status может означать статус события. Здесь, если значением status является «trigger», это означает статус, при котором событие активируется триггером активации. Если значение status является «error», это означает статус, при котором возникает ошибка.

[0511] Была описана модель TDO. Далее будет описана модель Непосредственного Исполнения.

[0512] В модели Непосредственного Исполнения, Декларативный Объект (DO) может быть запущен автоматически как только выбирается виртуальный канал. Он может осуществлять связь через сеть Интернет со вторичным сервером для получения подробных инструкций для предоставления интерактивных свойств - создания отображений в конкретных местоположениях на экране, проведения опросов, запуска других специализированных DO, и т.д., при этом все синхронизировано с аудио-видео программой.

[0513] Далее будет описана работа триггера в модели непосредственного исполнения.

[0514] Роль, функция и синтаксис триггера значительно не изменяется в модели непосредственного исполнения.

[0515] Исполнение триггера равно тому, что описано выше.

[0516] Синтаксис триггера равен тому, что описан выше.

[0517] Можно считать, что Trigger включает в себя три части.

[0518] <domain name part> / <directory path> [?<parameters>]

[0519] В модели непосредственного исполнения, сочетание <domain name part> и <directory path> может уникальным образом идентифицировать DO, который должен быть запущен.

[0520] <parameters> может включать в себя одно или более из «event_time», «media_time», или «spread».

[0521] В модели непосредственного исполнения, приложение запускается автоматически, как только выбирается виртуальный канал. Приложение может осуществлять связь через сеть Интернет со вторичным сервером через «Протокол Синхронизированного Контента». Сервер может выдавать подробные инструкции для обеспечения интерактивных свойств, при этом все синхронизированы с аудио-видео программой.

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

[0523] Аналогичным образом, идентификатор контента может присутствовать в части параметров триггера в форме параметра.

[0524] Аналогичным образом, идентификатор контента может присутствовать в media_time триггера в форме одного терма. Терм идентификатора контента, который может именоваться content_id, который может быть назначен посредством «c=», за которой следует строка символов, может представлять собой идентификатор контента, который просматривается в настоящий момент.

[0525] Терм content_id может быть предназначен для поддержки модели Непосредственного Исполнения реализации интерактивной услуги.

[0526] Как описано выше, в данной модели, триггеры Time Base с термом content_id могут передаваться в приложение после того, как оно запускается, и приложение может доставлять content_id вторичному серверу для того, чтобы идентифицировать контекст для взаимодействия. Его подробная работа будет описан ниже.

[0527] Механизм доставки триггера в модуле непосредственного исполнения равен тому, что описан выше.

[0528] Тем не менее, в случае Доставки Trigger в Вещательном Потоке, Trigger могут быть доставлены в канале Закрытых Субтитров DTV, в Услуге #6, в команде URLString. А применительно к интерактивным услугам, использующим модель Непосредственного Исполнения, поле URI_type может быть установлено равным 2 (Trigger Интерактивного TV для модели Непосредственного Исполнения).

[0529] Далее, будет описана общая работа модуля непосредственного исполнения.

[0530] В качестве одной модели для исполнения интерактивной услуги, в модели непосредственного исполнения, приложение может быть запущено автоматически, как только выбирается виртуальный канал. Приложение может осуществлять связь через сеть Интернет со вторичным сервером через «Протокол Синхронизированного Контента». Сервер может выдавать подробные инструкции для предоставления интерактивных свойств - создания отображений в конкретных местоположениях на экране, проведения опросов, запуска других специализированных DO, и т.д., при этом все синхронизировано с аудио-видео программой.

[0531] Работа может выполняться следующим образом.

[0532] Прежде всего, может быть запущено приложение. Затем принимается триггер координаты времени. Триггер координаты времени доставляется приложению после того как приложение было исполнено. Терм content_id триггера координаты времени может включать в себя информацию идентификации отображаемого в настоящий момент контента. Приложение может доставлять content_id вторичному серверу для того, чтобы идентифицировать контекст для взаимодействия, и для того, чтобы идентифицировать контент, который просматривается в настоящий момент.

[0533] Была описана Модель Непосредственного Исполнения.

[0534] Фиг. 22 является схемой, показывающей Архитектуру для подхода WM.

[0535] Будет приведено описание Доставки через другие интерфейсы.

[0536] Определяются протоколы и архитектура, обеспечивающие получение интерактивной услуги в средах (например, таких как принимаемые от кабельной или спутниковой телевизионной абонентской приставки), в которых доступ можно получить только к несжатому видео или аудио. Архитектура и протоколы могут быть предназначены для использования приемниками, которые имеют Интернет соединения и которые имеют доступ только к несжатому аудио и видео из вещательного потока. Конечно, архитектура и протоколы могут быть успешно использованы если поставщик интерактивной услуги выбирает поддержку того же самого.

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

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

[0539] Фиг. 22 иллюстрирует архитектуру для подхода WM.

[0540] В архитектуре для подхода WM, архитектура может включать в себя вещательную компанию 22010, модуль 22011 вставки водяных знаков, MVPD 22020, STB 22030, приемник 22040, клиента 22050 WM, сервер 22060 TPT и/или сервер 22070 контента.

[0541] Вещательная компания 22010 может быть источником, который выводит аудио/видео потоки и интерактивные услуги, которые относятся к аудио/видео потокам. TV станция может быть примером вещательной компании 22010. Вещательная компания 22010 может быть средством создания или распространения вещательного контента. Вещательная компания 22010 может доставлять вещательные потоки, аудио/видео контент, интерактивные данные, расписания вещания или AMT.

[0542] Модуль 22011 вставки водяных знаков может вставлять водяные знаки в аудио/видео кадры вещания. Модуль 22011 вставки водяных знаков может быть интегрирован с вещательной компанией 22010 или может быть отдельным модулем. Водяные знаки могут быть информацией, которая необходима для приемников. Водяные знаки могут быть информацией, такой как URL. Водяные знаки будут подробно описаны позже.

[0543] MVPD 22020 является аббревиатурой для многопрограммного распространителя видео программ. MVPD 22020 может быть кабельным оператором, спутниковым оператором или оператором IPTV. MVPD 22020 может принимать вещательный поток от Вещательной компании/Модуля Вставки Водяных Знаков, с водяными знаками, вставленными Модулем 22011 Вставки Водяных Знаков в случае системы ACR с методом водяных знаков. MVPD 22020 часто удаляет все элементы программы отличные от аудио и видео дорожек, и отправляет результирующий поток на телевизионные абонентские приставки (STB) в помещениях потребителя.

[0544] STB 22030, как правило, декодирует (восстанавливает из сжатого состояния) аудио и видео и отправляет их на телевизор для представления зрителям. STB может отправлять несжатый аудио/видео контент на приемник 22040. STB может быть внешним декодирующим блоком в соответствии с вариантом осуществления настоящего изобретения.

[0545] Приемник 22040 может включать в себя клиента 22050 WM. Клиент 22050 WM может быть расположен вне приемника 22040. Здесь, приемник может быть с возможностями обработки водяных знаков. Структура приемника 22040 будет описана позже.

[0546] Клиент 22050 WM может получать Activation Trigger от Сервера ACR (не показан) и переводить их в код основного приемника, используя API, предоставленный для таких целей. Обычно, Клиент 22050 WM будет встроен в приемник, но возможны другие конфигурации. Клиент 22050 WM может извлекать вставленные водяные знаки из несжатого аудио/видео контента. Водяные знаки могут быть информацией, такой как URL.

[0547] Сервер 22060 TPT может быть сервером, выполненным с возможностью загрузки приложения, такого как TPT. Приемник 22040 передает извлеченные водяные знаки серверу ACR. Когда водяные знаки сопоставляются с водяными знаками, хранящимися в базе данных (не показана), приемник 22040 может принимать триггер или триггеры в ответ. Когда принятый триггер или триггеры имеют описанную выше новую locator_part или обнаруживается новая версия TPT или таблицы параметров приложения, приемник 22040 может запросить сервер 22060 TPT загрузить новую TPT или таблицу параметров приложения.

[0548] Сервер 22070 контента может предоставлять приложения и TDO необходимые для предоставления интерактивных услуг. Когда требуется новое приложение или TDO, новое приложение может быть загружено, используя URL в TPT или таблице параметров приложения.

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

[0550] Фиг. 23 является схемой, показывающей вариант осуществления архитектуры для подхода FP.

[0551] В архитектуре для подхода FP, архитектура может включать в себя вещательную компанию 23010, MVPD 23020, STB 23030, приемник 23040, клиента 23050 FP, сервер 23060 TPT, сервер 23070 контента, модуль 23080 извлечения сигнатуры и/или сервер 23090 FP.

[0552] Вещательная компания 23010 может быть источником, который выводит аудио/видео потоки и интерактивные услуги, которые относятся к аудио/видео потокам. TV станция может быть примером вещательной компании 23010. Вещательная компания 23010 может быть средством создания или распространения вещательного контента. Вещательная компания 23010 может доставлять вещательные потоки, аудио/видео контент, интерактивные данные, расписания вещания или AMT.

[0553] MVPD 23020 является аббревиатурой для многопрограммного распространителя видео программ. MVPD 23020 может быть кабельным оператором, спутниковым оператором или оператором IPTV. MVPD 23020 часто удаляет все элементы программы отличные от аудио и видео дорожек, и отправляет результирующий поток на телевизионные абонентские приставки (STB) в помещениях потребителя.

[0554] STB 23030, как правило, декодирует (восстанавливает из сжатого состояния) аудио и видео и отправляет их на телевизор для представления зрителям. STB может отправлять несжатый аудио/видео контент на приемник 23040. STB 23030 может быть внешним декодирующим блоком в соответствии с вариантом осуществления настоящего изобретения.

[0555] Приемник 23040 может включать в себя клиента 23050 FP. Клиент 23050 FP может быть расположен вне приемника 23040. Здесь, приемник 23040 может быть с возможностями обработки отпечатков пальцев. Структура приемника 23040 будет описана позже.

[0556] Клиент 23050 FP может получать Activation Trigger от Сервера 23090 FP и переводить их в код основного приемника, используя API, предоставленный для таких целей. Обычно, Клиент 23050 FP будет встроен в приемник, но возможны другие конфигурации. Клиент 23050 FP может извлекать отпечаток пальца из несжатого аудио/видео контента. Отпечаток пальца будет подробно описан позже.

[0557] Сервер 23060 TPT может быть сервером, выполненным с возможностью загрузки приложения, такого как TPT. Приемник 23060 передает извлеченный отпечаток пальца серверу 23090 FP. Когда отпечаток пальца сопоставляется с сигнатурой модуля 23080 извлечения сигнатуры, приемник 23040 может принимать триггер или триггеры в ответ. Когда принятый триггер или триггеры имеют описанную выше новую locator_part или обнаруживается новая версия TPT или таблицы параметров приложения, приемник 23040 может запросить сервер 23060 TPT загрузить новую TPT или таблицу параметров приложения.

[0558] Сервер 23070 контента может предоставлять приложения и TDO необходимые для предоставления интерактивных услуг. Когда требуется новое приложение или TDO, новое приложение может быть загружено, используя URL в TPT или таблице параметров приложения.

[0559] Модуль 23080 извлечения сигнатуры может принимать метаданные от вещательной компании 23010. Модуль 23080 извлечения сигнатуры может извлекать сигнатуру кадра из принятых метаданных. Когда отпечаток пальца, переданный серверу 23090 FP, сопоставляется с сигнатурой модуля 23080 извлечения сигнатуры, модуль 23080 извлечения сигнатуры может доставлять метаданные, которые относятся к сигнатуре, серверу 23090 FP.

[0560] Сервер 23090 FP может выполнять операцию сопоставления сигнатуры с модулем 23080 извлечения сигнатуры. Сервер 23090 FP может сопоставлять сигнатуру с отпечатком пальца, принятым от приемника 23040. Когда сигнатура сопоставлена с отпечатком пальца, сервер 23090 FP может принимать метаданные, которые относятся к сигнатуре от модуля 23080 извлечения сигнатуры. Сервер 23090 FP может передавать метаданные приемнику 23040.

[0561] В подходе метода отпечатков пальцев (FP), Клиент 23050 FP может извлекать отпечатки пальцев (также могут именоваться сигнатурами) из аудио или видео кадров и проверять отпечатки пальцев относительно базы данных отпечатков пальцев вещательных кадров от нескольких вещательных компаний в зоне для нахождения информации, требуемой приемникам 23040. Такие проверки могут быть выполнены посредством передачи сигнатуры удаленному серверу и получения назад записи с требуемой информацией, или в некоторых случаях они могут быть выполнены посредством проверки относительно базы данных сигнатур, которая была загружена на приемник 23040. Здесь, удаленный сервер может быть сервером 23090 FP.

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

[0563] Среда, в которой приемник имеет доступ только к несжатому аудио и видео из вещательного потока именуется «средой ACR».

[0564] Как в случае WM, так и в случае FP приемники могут использовать URL в качестве начальной точки для получения контента интерактивной услуги, включающей триггеры.

[0565] Как в случае WM, так и в случае FP информация о распределении во времени может быть представлена в виде временной метки относительно часов вещательной стороны, которые используются для указания распределения во времени критичных по времени событий для канала, таких как временные метки активации в триггерах, доставляемых через сеть Интернет.

[0566] Предполагается что вещательные компании могут, как правило, поддерживать доставку интерактивных услуг непосредственно в вещательном потоке, в интересах приемников, которые получают TV сигналы от антенн, и также поддерживают доставку интерактивных услуг через сеть Интернет, как описано выше, в интересах приемников, которые получают несжатое аудио и видео, но имеют Интернет соединение. Тем не менее, вещательные компании могут поддерживать любой один из этих двух механизмов доставки без другого.

[0567] Типичная архитектура для подхода с методом водяных знаков в случае, когда водяные знаки предоставляют только значение кода, будет похожа неким образом на сочетание двух архитектур на Фиг. 22 и Фиг. 23. Будет присутствовать Модуль Вставки Водяных Знаков, как на Фиг. 22, но он будет вставлять код, вместо информации, требуемой приемникам. Также будет присутствовать Сервер WM, больше играющий такую же роль, что и Сервер FP на Фиг. 23. Приемники будут отправлять эти коды, вместо сигнатур, и будут получать обратно требуемую им информацию.

[0568] Будет приведено описание получения доступа к интерактивным услугам.

[0569] Описание получения доступа к интерактивным услугам включает в себя описания Модели Непосредственного Исполнения, Модели TDO с Activation Независимыми от Сервера ACR, Модели TDO с Activation, принимаемыми от Сервера ACR. Несмотря на то, что модели не показаны, модели не ограничиваются описаниями и могут быть изменены в соответствии с намерениями разработчика.

[0570] Существует некоторое число разных способов посредством которых, приемник в среде ACR получает доступ к интерактивным услугам, в зависимости от выборов вещательных компаний и природы системы ACR. Моделью интерактивной услуги может быть модель Непосредственного Исполнения или модель TDO, и Activation Trigger, в случае модели TDO, могут быть доставлены независимо от Сервера ACR, или они могут быть доставлены посредством Сервера ACR.

[0571] Будет приведено описание Модели Непосредственного Исполнения.

[0572] Процесс ACR для виртуального канала, который содержит интерактивную услугу, которая обладает Моделью Непосредственного Исполнения, может предоставлять приемникам, просматривающим этот канал, эквивалент Time Base Trigger (Триггер Координаты времени), которые включают в себя терм media_time («m=») и терм content_id («c=»). Эти Trigger могут быть идентифицированы как Trigger для интерактивной услуги с моделью Непосредственного Исполнения.

[0573] Когда приемник сначала принимает такой Trigger с новой locator_part, можно предположить, что он загружает в свой браузер Декларативный Объект (DO), на который указывает locator_part Trigger. Как правило, DO будет предварительно инсталлирован или ранее загружен и кэширован. В противном случае, можно предположить, что приемник загружает его, используя HTTP запрос GET.

[0574] Затем, DO может контактировать с соответствующим вторичным сервером и предоставлять интерактивную услугу по указанию вторичного сервера.

[0575] Можно предположить, что приемник делает доступными DO исходный Trigger и последующие Trigger по мере того как они получены до такого времени, как он получает Trigger от сервера ACR, который имеет новую locator_part и/или который идентифицируется как Trigger для интерактивной услуги с моделью TDO (любой из которых, как правило, указывает изменение канала).

[0576] Будет приведено описание Модели TDO с Activation Независимыми от Сервера ACR.

[0577] Процесс ACR для виртуального канала, который может содержать интерактивную услугу, которая имеет модель TDO, и которая обеспечивает активации события независимо от Сервера ACR, может предоставлять приемникам, просматривающим этот канал эквивалент Time Base Trigger, которые могут включать в себя терм media_time («m=»). Эти Trigger могут быть идентифицированы как Trigger для интерактивной услуги с моделью TDO.

[0578] Когда приемник сначала принимает такой Trigger с новым locator_part, можно предположить, что он извлекает текущую Таблицу Параметров TDO (TPT) из Сервера TPT, на который может указывать locator_part Trigger, и процессом ACR может быть идентифицировано использование времени мультимедиа в этом Trigger и последующих Trigger для установления опорного времени мультимедиа для активаций события, относительно аудио или видео кадров.

[0579] Если (Таблица Сообщений Активации) AMT доставляется наряду с TPT, можно предположить, что приемник использует индивидуальные элементы Activation в таблице для активации событий в правильные времена относительно координаты времени установленной термами времени мультимедиа в Trigger. (Эти события могут включать в себя загрузку и исполнение TDO, предписание TDO предпринять конкретное синхронизированное действие, приостановление TDO, и т.д.)

[0580] Если в TPT включен элемент LiveTrigger, можно предположить, что приемник извлекает Activation Trigger из Сервера Live Trigger (Триггера Прямого Эфира), идентифицируемого посредством URL в элементе LiveTrigger, используя способ опроса, сигнализируемый в элементе LiveTrigger, и использует эти Activation Trigger для активации событий в правильные времена относительно координаты времени, установленной термами времени мультимедиа в Trigger.

[0581] Как AMT, так и Сервер Live Trigger могут быть использованы для одной и той же услуги, при этом, как правило, первая обеспечивающая статические активации, а последний обеспечивающий динамические активации. В качестве альтернативы, может быть использована только AMT, когда все активации для сегмента являются статическими, или может быть использован только Сервер Live Trigger для доставки как статических, так и динамических активаций.

[0582] Будет приведено описание Модели TDO с Activation, Принимаемыми от сервера ACR.

[0583] Описывается то, каким образом триггеры активации для модели интерактивной услуги TDO доставляются без отдельного сервера триггера в среде ACR.

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

[0585] Предполагается, что вещательная компания поддерживает модель взаимодействия TDO.

[0586] Можно предположить три случая из: сервера ACR, использующего модель запроса/ответа, сервера ACR, использующего событийно-управляемую модель, и систему ACR с методом водяных знаков, непосредственно вставляющую информацию.

[0587] В случае сервера ACR, способ ACR может быть методом отпечатков пальцев, и в этом случае приемники вычисляют некоторого рода сигнатуру (или отпечаток пальцев) аудио или видео кадров и подают его же серверу ACR для идентификации, или, способ может быть методом водяных знаков, и в этом случае приемники извлекают коды в форме водяных знаков из аудио или видео кадров и подают коды серверу ACR для идентификации.

[0588] Понятия сигнатур метода отпечатков пальцев описаны для удобства. Тем не менее, система работает точно таким же образом, как и в случае кодов метода водяных знаков и настоящее изобретение не ограничивается методом отпечатков пальцев.

[0589] Фиг. 24 является схемой, показывающей пример статической активации в случае запроса/ответа ACR.

[0590] Будет приведено описание случая, при котором сервер ACR использует модель запроса/ответа.

[0591] В модели запроса/ответа, можно предположить, что приемник генерирует сигнатуры контента периодически (например, каждые 5 секунд, что является лишь примерным и может быть изменено разработчиком) и отправляет запросы, содержащие сигнатуры, серверу ACR. Когда сервер ACR получает запрос от приемника, он может вернуть ответ. Сеанс связи может не оставаться открытым между экземплярами запроса/ответа. В данной модели, серверу ACR невозможно инициировать сообщения для клиента.

[0592] Для сервера ACR, который использует модель запроса/ответа) и доставляет Activation Trigger приемникам, каждый ответ от сервера ACR может быть одним из: Null (пустой указатель), Time Base Trigger и Activation Trigger.

[0593] Ответ Null может указывать на то, что сигнатура не распознана, или (если Модуль Захвата ACR включает в себя сигнатуры для кадров в сегментах программы с отсутствующей интерактивной услугой) что сигнатура представляет собой кадр, который принадлежит к сегменту, который не имеет ассоциированной с ним интерактивной услуги. Модуль захвата ACR будет описан ниже.

[0594] Ответ Time Base Trigger может указывать на то, что не запланировано ни какой активации события до следующего запроса клиента. Можно предположить, что клиент использует Time Base Trigger для поддержания часов времени мультимедиа.

[0595] Ответ Activation Trigger может указывать на то, что в ближайшее время должна состояться активация, при этом время активации указывается термом «t=» в Trigger.

[0596] Всякий раз, когда приемник принимает Trigger с новой locator_part, можно предположить, что он немедленно загружает новую TPT, если он только уже не извлек ее, используя URLList доставленный с предыдущей TPT.

[0597] Всякий раз, когда приемник получает Activation Trigger, можно предположить, что он активирует событие во время, указываемое термом «t=» в Trigger, относительно часов времени мультимедиа.

[0598] Фиг. 24 иллюстрирует то, каким образом данная схема работает для статической активации (или для динамической активации, когда система ACR узнает о динамической активации в достаточной мере досрочно).

[0599] На Фиг. 24, приемник может отправлять сигнатуры для кадров, в отношении которых сервер ACR выявляет, что они имеют времена мультимедиа MT1, MT2 и MT3. Для кадра с временем MT1 мультимедиа приемник просто получает ответ, который содержит Time Base Trigger. Для кадра с временем MT2 мультимедиа, должна состояться статическая активация в media_time MTa, так что приемник получает ответ, который содержит Activation Trigger, который имеет терм «t=MTa». Для кадра с временем MT3 мультимедиа приемник лишь получает ответ, который содержит Time Base Trigger.

[0600] Может случиться так, что приемник принимает более одного Activation Trigger для одной и той же активации события. Тем не менее, времена мультимедиа для каждого из них будут одинаковые, так что приемник может идентифицировать их как дубликаты, и применять только один из них.

[0601] Фиг. 25 является схемой, показывающей вариант осуществления статической активации в случае запроса/ответа ACR.

[0602] Будет приведено описание случая, при котором сервер ACR использует модель запроса/ответа.

[0603] На Фиг. 25, приемник может быть отправляющим сигнатуры для кадров, просматриваемых во времена LC1, LC2, LC3, и т.д. локальных часов. media_time для кадра, просматриваемого во время LC1 локальных часов, может быть выявлено сервером ACR как MT1, и приемник лишь получает ответ, который содержит Trigger без media_time или event_time. media_time для кадра, просматриваемого во время LC2 локальных часов, может быть выявлено сервером ACR как MT2, и сервер ACR знает, что статическая активация должна состояться в media_time MTa, так что сервер ACR отправляет ответ, который содержит Activation Trigger, который имеет терм «d=<offset>», означающий, что media_time MTa для активации находится через <offset> (смещение) единиц времени после MT2. Приемник затем добавляет <offset> к LC2 и получает LCa в качестве локального времени, в которое он должен активировать событие.

[0604] Фиг. 26 является схемой, показывающей вариант осуществления динамической активации в случае запроса/ответа ACR.

[0605] Будет приведено описание случая, при котором динамическая активация происходит в случае запроса/ответа ACR.

[0606] Применительно к динамическим активациям в ситуация, когда Система ACR не узнает об активации события до тех пор, когда уже поздно отправлять Trigger приемнику досрочно, Сервер ACR требуется ждать до следующего запроса, и затем отправлять Activation Trigger. Фиг. 26 иллюстрирует данный случай. Результатом этого является то, что динамические активации могут быть задержаны на целый один интервал запроса.

[0607] На Фиг. 26, приемник может быть отправляющим сигнатуры для кадров, которые сервер ACR выявляет как имеющие времена мультимедиа MT1, MT2 и MT3. Для кадров с временами мультимедиа MT1 и MT2, приемник лишь получает ответ, который содержит Time Base Trigger. Когда динамическая активация со временем MTa активации появляется в или незадолго до media_time MTa, сервер ACR не может уведомить приемник о ней до следующего запроса от приемника, который происходит для кадра с временем мультимедиа MT3. В это время ответ сервера ACR содержит Activation Trigger с временем MTa активации (которое немного в прошлом). В данной ситуации можно предположить, что приемник применяет Activation Trigger как только он прибывает.

[0608] Здесь вновь существует возможность того, что приемник принимает более одного Activation Trigger для одной и той же активации события. Тем не менее, время мультимедиа для каждого из них будет одним и тем же, так что приемник может идентифицировать их как дубликаты, и применять только один из них.

[0609] Фиг. 27 является схемой, показывающей вариант осуществления динамической активации в случае запроса/ответа ACR.

[0610] Будет приведено описание случая, при котором динамическая активация происходит в случае запроса/ответа ACR.

[0611] На Фиг. 27, приемник может отправлять сигнатуры для кадров, просматриваемых во времена LC1, LC2, LC3, и т.д. локальных часов. media_time для кадра, просматриваемого во время LC1 локальных часов, может быть выявлено сервером ACR, как MT1, и приемник лишь получает ответ, который содержит Trigger без media_time и event_time. media_time для кадра, просматриваемого во время LC2 локальных часов может быть выявлено сервером ACR как MT2, и сервер ACR не знает о том, что динамическая активация появится в media_time MTa, так что приемник лишь получает ответ, который содержит Trigger без media_time и event_time. Когда динамическая активация появляется в media_time MTa, сервер ACR не может уведомить приемник о ней до следующего запроса от приемника, который происходит в локальное время LC3. В это время ответ сервера ACR может содержать Activation Trigger с отрицательным значение <offset> или содержать триггер активации «do it now» (сделай это сейчас).

[0612] Будет приведено описание сервера ACR, использующего событийно-управляемую модель.

[0613] В событийно-управляемой модели ACR можно предположить что приемник инициирует долговременное соединение с сервером ACR, генерирует сигнатуры контента периодически (например, каждые 5 секунд), и представляет сигнатуры через соединение. Сервер ACR не отвечает на каждую сигнатуру. Он может отправлять сообщение приемнику, когда детектируется новый сегмент или когда требуется сообщить приемнику активацию события. В данной модели, сервер ACR имеет возможность инициирования сообщений клиенту в любое время.

[0614] Применительно к серверу ACR, использующему данную событийно-управляемую модель и доставляющему активации приемникам, следующие правила могут применяться к сообщениям от сервера ACR.

[0615] В первую очередь, когда сервер ACR принимает сигнатуру от приемника, которая соответствует новому сегменту, сервер ACR может немедленно отправлять Time Base Trigger приемнику, лишь для того, чтобы предоставить приемнику возможность получения ассоциированной TPT.

[0616] Во вторую очередь, всякий раз, когда должно быть активировано событие, сервер ACR может отправлять Activation Trigger приемнику. По возможности, он может отправлять Activation Trigger незначительно досрочно по отношению к тому, когда приемнику требуется применить его. (Это очень похоже на поведение при модели запроса/ответа). Если сервер ACR узнает об активации настолько поздно, что он не может отправить Activation Trigger значительно досрочно (что может произойти в случае динамической активации события), он все же может отправить Activation Trigger, как только он может. В данном последнем случае, существует возможность того, что клиент получит сообщение незначительно после времени активации, из-за задержек сообщения, и в этом случае можно предположить, что приемник активирует событие немедленно по приему сообщения.

[0617] Всякий раз, когда приемник получает Trigger с новым locator_part, можно предположить, что он немедленно загружает новую TPT, если только он уже не извлек ее, используя URLList, доставленный с предыдущей TPT.

[0618] Будет приведено описание системы ACR с методом водяных знаков, непосредственно вставляющей информацию. Несмотря на то, что система ACR с методом водяных знаков не показана, система ACR с методом водяных знаков не ограничивается следующим описанием и может быть изменена разработчиком.

[0619] В случае системы с методом водяных знаков, которая непосредственно вставляет информацию, требуемую приемникам, водяной знак, ассоциированный с кадром, может следовать тем же правилам, что указаны выше, для чего сервер ACR запроса/ответа будет возвращать для этого кадра следующим образом. Сервер ACR запроса/ответа может возвращать Null, Time Base Trigger и Activation Trigger.

[0620] Ответ Null может указывать на то, что сигнатура не распознана, или (если Модуль Захвата ACR включает в себя сигнатуры для кадров в сегментах программы с отсутствующей интерактивной услугой) что сигнатура представляет собой кадр, который принадлежит к сегменту, который не имеет ассоциированной с ним интерактивной услуги.

[0621] Ответ Time Base Trigger может указывать на то, что не запланировано ни какой активации события до следующего запроса клиента. Можно предположить, что клиент использует Time Base Trigger для поддержания часов времени мультимедиа.

[0622] Ответ Activation Trigger может указывать на то, что в ближайшее время должна состояться активация, при этом время активации указывается термом «t=» в Trigger.

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

[0624] Будет приведено описание поддержки автономных услуг NRT. Это не показано, однако настоящее изобретение не ограничивается следующим описанием и может быть изменено разработчиком.

[0625] Для того, чтобы приемник в среде ACR получал доступ к автономным услугам NRT, вещательной компании может требоваться поддержка Интернет доступа к услугам NRT, и приемнику может требоваться получать SMT и экземпляры NRT-IT для услуг.

[0626] Будет приведено описание протокола запроса для получения таблиц PSIP и таблиц NRT через сеть Интернет.

[0627] Если вещательная компания поддерживает данный протокол для конкретного вещательного потока, тогда приемник, который знает URL Сервера Сигнализации вещательной компании для этого вещательного потока, может предпринимать следующие этапы.

[0628] Во-первых, приемник может выдавать запрос в отношении «Базового Набора NRT» таблиц для вещательного потока, для указанного будущего интервала времени (например, следующих 12 часов).

[0629] Во-вторых, это будет создавать SMT и ILT для каждого из виртуальных каналов автономной NRT, и экземпляры NRT-IT и TFT, охватывающие указанный интервал времени.

[0630] Одним способом, посредством которого приемник может обнаружить URL Сервера Сигнализации для вещательного потока, может быть то, что поставщик сегмента интерактивной услуги в вещательном потоке может выбирать предоставление URL Сервера Сигнализации в элементе URLList, который доставляется наряду с TPT.

[0631] Другим способом, посредством которого приемник может обнаружить URL Серверов Сигнализации, может быть посредством предварительной конфигурации. Образом аналогичным тому, посредством которого изготовители приемника DTV могут предварительно конфигурировать приемник DTV, чтобы он знал то, каким образом найти Сервер ACR, охватывающий любую конкретную зону вещания, изготовитель приемника DTV может предварительно конфигурировать приемник DTV, чтобы он знал то, каким образом найти «Сервер Обнаружения NRT», охватывающий любую конкретную зону вещания. Такой Сервер Обнаружения NRT будет выполнен с возможностью предоставления приемнику списка вещательных потоков, которые содержат автономные услуги NRT, наряду с URL Сервера Сигнализации для каждого.

[0632] Фиг. 28 является схемой, показывающей вариант осуществления архитектуры для активации сервера ACR.

[0633] Некоторые системы ACR включают в себя сервер ACR, а некоторые системы ACR не включают. В системах ACR с методикой отпечатков пальцев, приемники могут вычислять и отправлять сигнатуры на сервер ACR, и сервер ACR может отправлять назад информацию, требуемую приемникам. Таким образом, системы ACR с методикой отпечатков пальцев включают в себя сервер ACR. В системах ACR с методом водяных знаков, водяные знаки могут содержать только коды, которые уникальным образом идентифицирую кадры, или водяные знаки могут содержать полную информацию, требуемую приемникам. Когда водяные знаки содержат только коды, приемники могут извлекать коды и отправлять их серверу ACR, а сервер ACR отправляет назад информацию, требуемую приемникам. В случае, когда водяные знаки включают в себя всю информацию, приемники лишь извлекают информацию, которая им требуется непосредственно из водяных знаков, и сервер ACR не требуется.

[0634] В тех системах ACR, которые включают в себя сервер ACR, две разные модели могут быть обычно использованы для осуществления связи между серверами ACR и приемниками: модель запроса/ответа и событийно-управляемая модель.

[0635] В модели сервера ACR запроса/ответа можно предположить, что приемник вычисляет сигнатуры, или извлекает коды из, контента периодически (например, каждые 5 секунд) и отправляет запросы, содержащие сигнатуры, серверу ACR. Когда сервер ACR получает запрос от приемника, он может вернуть ответ. Сеанс связи не сохраняется открытым между экземплярами запроса/ответа. В данной модели, серверу ACR невозможно инициировать сообщения для приемника.

[0636] Предполагается, что вещательная компания обрабатываемого канала поддерживает модель взаимодействия TDO.

[0637] Может существовать два основных типа активаций события: статические активации, при которых время активации известно перед тем как начинается вещание сегмента, и динамические активации, при которых время активации выявляется динамически по мере того как осуществляется вещание сегмента. В предварительно записанных сегментах все активации события могут быть статическими. В сегментах, которые осуществляют вещание представлений в прямом эфире, некоторые или все из активаций события могут быть динамическими. Статические активации, как правило, перечислены в Таблице Сообщений Активации (AMT), несмотря на то, что они могут доставляться приемникам в форме Activation Trigger. Динамические активации не могут быть доставлены в форме Activation Trigger, поскольку их распределение во времени не известно в то время как генерируется AMT.

[0638] Фиг. 28 показывает архитектуру для поддержки систем ACR, которые используют сервер ACR. Это логическая структурная схема, а не архитектура реализации. Например, Модуль Захвата ACR может совместно использовать местоположение с источником вещания, или он может находиться в отдельном местоположении.

[0639] В архитектуре для поддержки систем ACR, которые используют сервер ACR, архитектура может включать в себя источник 28010 вещания, модуль 28020 захвата ACR, MVPD 28030, STB 28040, приемник 28050, клиента 28060 ACR, сервер 28070 конфигурации ACR, сервер 28080 ACR и/или базу 28090 данных.

[0640] Источник 28010 Вещания может быть точкой, из которой передается A/V поток и ассоциированные интерактивные услуги, например, точкой сетевого распространения или TV станцией.

[0641] Модуль 28020 Захвата ACR может вычислять сигнатуры (отпечатки пальцев) кадров, в случае системы ACR с методом отпечатков пальцев, или вставлять водяные знаки, включающие в себя коды, в кадры, в случае систем ACR с методом водяных знаков, которые основаны на кодах. Он может хранить в базе 28090 данных media_time каждого кадра, ассоциированного с сигнатурой или кодом, совместно с другими метаданными. Модуль 28020 Захвата ACR может обрабатывать один канал в вещательном потоке, или весь вещательный поток, или несколько вещательных потоков, или любое их сочетание. Для этих целей, предполагается, что модуль 28020 Захвата ACR обрабатывает кадры для сегментов программы, которые содержат интерактивную услугу. Тем не менее, существует возможность наличия систем ACR, в которых обрабатываются все кадры, но те, что не являются частью сегмента с интерактивной услугой, имеют указание в их записи в базе 28090 данных о том, что они не являются частью сегмента с интерактивной услугой.

[0642] Многопрограммный Распространитель 28030 Видео Программ (MVPD), как правило, является кабельным оператором, спутниковым оператором, или оператором IPTV. Он может принимать вещательный поток от Источника Вещания некоторым образом, со вставленными Модулем 28020 Захвата ACR водяными знаками в случае системы ACR с методом водяных знаков, при этом такая система часто удаляет все элементы программы отличные от аудио и видео дорожек, и отправляет результирующий поток на телевизионные абонентские приставки 28040 (STB) в помещениях потребителя.

[0643] STB 28040, как правило, декодирует (восстанавливает из сжатого состояния) аудио и видео и отправляет их на телевизор для представления зрителям. Мы предполагаем, что услуга #6 Закрытых Субтитров DTV, которая содержит Trigger интерактивной услуги, недоступна телевизору.

[0644] Приемник 28050 может включать в себя клиента 28060 ACR. Клиент 28060 ACR может быть расположен вне приемника 28050. Структура приемника 28050 будет описана позже.

[0645] Клиент 28060 ACR в приемнике 28050 может получать Activation Trigger от Сервера 28080 ACR и переводить их в код основного приемника, используя API, предоставленный для таких целей. Обычно, клиент 28060 ACR будет встроен в приемник 28050, но возможны другие конфигурации.

[0646] Сервер 28070 Конфигурации ACR может обеспечивать для клиентов 28060 ACR способ выявления местоположения подходящего Сервера 28080 ACR. Этот процесс обнаружения может быть достигнут другими способами.

[0647] Сервер 28080 ACR может получать сигнатуры или коды от приемников и возвращать Activation Trigger в соответствующие времена.

[0648] База 28090 данных может быть хранилищем данных некоторого рода, не обязательно базой данной в строгом соответствии с понятием, в котором хранится информация об аудио и или видео кадрах (или обоих) для использования серверами 28080 ACR.

[0649] Архитектура системы ACR, которая использует непосредственную доставку информации в водяных знаках, может не иметь ни Базы данных ни Сервера ACR. Модуль Захвата ACR может вставлять информацию непосредственно в кадры в вещательном потоке, в форме водяных знаков, вместо вставки, в базу данных записей, которые содержат идентификаторы кадров и информацию, ассоциированную с ними. Приемники затем могут извлекать данную информацию из кадров в вещании, вместо получения ее от сервера ACR.

[0650] Будет приведено поэтапное описание доставки триггеров активации через серверы ACR запроса/ответа. Это является вариантом осуществления настоящего изобретения и этап может быть опущен или новый этап может быть добавлен или может быть изменена последовательность.

[0651] Эффективным способом реализации данного поведения Сервера ACR является следование описанному ниже процессу, где номера действий в процессе соответствуют номерам на схеме архитектуры выше, как показано на Фиг. 28.

[0652] 1) Расписание вещания для сегментов интерактивной услуги и AMT или их эквиваленты для каждого сегмента могут быть доставлены Модулю Захвата ACR досрочно по отношению к тому, когда осуществляется вещание сегментов. Расписание вещания может содержать ID сегмента, время начала GPS и время конца GPS каждого сегмента, который содержит ассоциированную с ним интерактивную услугу. Если присутствуют любые сиюминутные изменения в расписании вещания, Модуль Захвата ACR может быть немедленно уведомлен об этих изменениях. Расписание вещания также может содержать номер версии TPT для каждого сегмента, и Модуль Захвата ACR может получать уведомление в режиме реального времени о любых незапланированных изменениях в версии TPT, так что он может вставлять терм «version» (версия) («v=») в Trigger при необходимости. Модуль Захвата также может быть выполнен с возможностью вставки термов «spread» («s=») в Trigger в подходящие времена, как например во время указанного интервала в начале каждого сегмента (когда вероятно, что много приемников будет запрашивать новые TPT одновременно).

[0653] 2) Если присутствуют любые динамические активации, могут быть настроены ссылки от источников динамических активаций к Модулю Захвата ACR.

[0654] 3) Может осуществляться маршрутизация вещательного потока к Модулю Захвата ACR.

[0655] 4) Модуль Захвата ACR может извлекать сигнатуры из кадров (в случае системы ACR с методом отпечатков пальцев) или вставлять коды в кадры (в случае системы ACR с методом водяных знаков), для всех кадров, которые содержатся в сегментах, которые имеют ассоциированную с ними интерактивную услугу. (Модуль Захвата ACR может выявлять, находится ли кадр в таком сегменте посредством использования часов GPS и времен начала и времен конца сегментов в расписании вещания). Для каждого такого кадра Модуль Захвата ACR может вставлять запись в Базу данных, которая может включать в себя Trigger и сигнатуру или код ассоциированный с кадром. Правила в отношении того, какой Trigger вставляется, описываются в конце данного списка действий в процессе.

[0656] 5) Вещательный Поток может проходить к MVPD.

[0657] 6) MVPD может осуществлять маршрутизацию Вещательного Потока к STB в местоположении абонента (как правило, сначала удаляя весь интерактивный контент).

[0658] 7) STB может декодировать A/V и отправлять несжатое A/V приемнику DTV.

[0659] 8) Когда приемник впервые включается, он может отправлять свое местоположение Серверу Конфигурации ACR. (URL Сервера Конфигурации ACR может быть встроен в приемник).

[0660] 9) Сервер Конфигурации ACR может отправлять назад URL Сервера ACR для использования приемником.

[0661] 10) Клиент ACR в приемнике может начинать извлечение сигнатур отпечатков пальцев или кодов водяных знаков и отправку их Серверу ACR.

[0662] 11) Когда Сервер ACR принимает сигнатуру или код, он может попытаться сопоставить его с Базой данных.

[0663] 12) Если сигнатура или код не сопоставлен ни с одной сигнатурой или кодом в Базе данных, тогда Сервер ACR может вернуть назад индикатор «нет сопоставления». Если сигнатура или код сопоставлен с сигнатурой или кодом в Базе данных, тогда Сервер ACR может возвращать назад запись для кадра, который обладает сопоставленной сигнатурой или кодом. В последнем случае, запись в Базе данных может содержать Time Base Trigger, и/или она может содержать один или более Activation Trigger, в зависимости от того, что было вставлено в запись для кадра Модулем Захвата ACR.

[0664] 13) Если Сервер ACR получает назад индикатор «нет сопоставления» от Базы данных, он может вернуть ответ NULL Клиенту ACR. В противном случае Сервер ACR может вернуть Клиенту ACR полученный им Trigger или несколько Trigger.

[0665] Следующие правила могут быть использованы для выявления того какой Trigger или несколько Trigger вставляет Модуль Захвата ACR в каждую запись кадра в Базе данных.

[0666] Фиг. 29 является схемой, показывающей вариант осуществления триггеров активации в случае (b) и случае (a) без EndTime.

[0667] Можно предположить, что присутствует некоторая верхняя граница L1 по продолжительности интервалов запроса, используемых индивидуальными клиентами ACR в приемниках. (Не важно, знают ли клиенты ACR о том какова данная граница, поскольку на практике они работают в ее пределах). Пусть L2 будет продолжительностью времени, которая затрачивает типичный клиент ACR для вычисления сигнатуры или извлечения водяного знака, ассоциированного с кадром, считая от времени, когда кадр прибывает в приемник. Пусть L3 будет типичным временем кругового обращения для сообщения для прохождения от клиента ACR к серверу ACR и обратно. Пусть M = L1 + L2 + L3. (Незначительно большее значение M также может быть использовано - преимущество незначительно большего значения состоит в том, что приемники получаю небольшое дополнительное время для реагирования на Activation Trigger; недостаток состоит в том, что приемники чуть с большей вероятностью получают несколько Activation Trigger для одной и той же активации Event - что не является большой проблемой, поскольку они будут иметь возможность детектирования того, что они являются дубликатами, как объясняется ниже, и применяют активацию лишь единожды).

[0668] Модуль Захвата ACR может вставлять только Time Base Trigger в запись, ассоциированную с кадром, до тех пор, пока выполняется, по меньшей мере, одно из следующих трех условий:

[0669] (a) В AMT присутствует элемент Activation такой, что media_time кадра находится в интервале времени, начинающемся в промежуток M времени перед startTime элемента Activation и заканчивающийся в endTime элемента Activation. (Если Activation не имеет endTime, endTime считается равным startTime).

[0670] (b) Модулем Захвата был принят динамический Activation Trigger перед интервалом времени промежутка M времени немедленно предшествующем времени активации Trigger («t=< event_time>»), и кадр лежит в пределах интервала.

[0671] (c) Динамический Activation Trigger был принят Модулем Захвата позже начала интервала промежутка M времени немедленно предшествующего времени активации Trigger, и media_time кадра находится в интервале промежутка L1 времени немедленно следующем за приемом Trigger.

[0672] Если выполняется любое из условий (a), (b) или (c), тогда Activation Trigger может быть включен в запись, с термом «e=» для идентификации Event, которое должно быть активировано, и термом «t=», для указания startTime элемента Activation в AMT (для условия (a)) или event_time динамического Trigger (для условия (b)). Trigger также может содержать терм версии («v=»).

[0673] Причиной для продолжения ассоциирования Activation Trigger с кадрами на всем протяжении интервала от startTime до endTime в случае (a), является принятие приемников, которые присоединяются к каналу на полпути интервала.

[0674] Следует отметить, что данный подход не требует дополнительной развитой логики на стороне Сервера ACR. Он просто возвращает Клиенту ACR информацию, которую он находит в Базе данных. Вся развитая логика может размещаться в Модуле Захвата ACR. Более того, вычисления, которые требуется выполнять Модулю Захвата ACR, могут быть очень простыми.

[0675] С помощью данной схемы существует возможность того, что приемник может получить более одного Activation Trigger (ассоциированного с разными кадрами) для одной и той же активации события. Тем не менее, приемник может легко увидеть по значениям «t=», что все они имеют одно и тоже время активации, так что приемник может выявлять, что они являются дубликатами и активировать событие только единожды.

[0676] В двух из вышеприведенных ситуациях терм «t=» в Activation Trigger может иметь event_time раньше media_time кадра, с которым он ассоциирован. В ситуации (a), если endTime элемента Activation находится значительно позже startTime, тогда приемник может, как правило, получить несколько Activation Trigger на всем протяжении интервала между startTime и endTime, и все они могут иметь startTime в качестве времен активации. В ситуации (c), Activation Trigger для активации могут быть вставлены в записи кадров настолько поздно, что Activation Trigger, который получает приемник, может приходить в ответ на запрос с сигнатурой для кадра, который имеет media_time после времени активации. Когда приемник получает Activation Trigger с event_time раньше media_time кадра, с которым он ассоциирован, можно предположить, что он активирует событие немедленно, если только он не распознает его как дубликат Activation Trigger, который он уже видел и использовал для активации события.

[0677] Цель использования значений event_time в прошлом, вместо Trigger «do it now» для ситуаций, когда media_time кадра находится позже времени event_activation, состоит в том что приемник может получить более одного их этих «после факта» Activation Trigger. Значения «t=» позволяют приемнику выявлять то, что все они имеют одно и то же время активации, и активировать событие только единожды.

[0678] Фиг. 29 иллюстрирует ситуацию (b) и ситуацию (a), когда элемент Activation в AMT не имеет атрибута endTime.

[0679] Фиг. 29 показывает пример ситуации (a) в действие (4) выше, в случае, когда элемент Activation в AMT не имеет endTime. Это также может быть примером ситуации (b) на этапе (4) выше, где Модуль Захвата ACR отправляет динамический Activation Trigger, по меньшей мере, M единиц времени перед его временем активации.

[0680] Фиг. 29 показывает время активации события выше линии времени, с интервалом продолжительностью M, предшествующим ему, охватывающим интервалы продолжительностью L1, L2, и L3. Вертикальные стрелки ниже линии времени показывают времена индивидуальных кадров. Каждый кадр, предшествующий началу интервала продолжительностью M, или следующий за временем активации события, будет иметь ассоциированный с ним в Базе данных Time Base Trigger. Каждый кадр внутри интервала продолжительностью M будет иметь ассоциированный с ним в Базе данных Activation Trigger, как например два примера (f1, f2) в нижней части фигуры. Терм «t=» для каждого кадра будет указывать время активации события относительно media_time (указанное обведенными f1 и f2).

[0681] Четыре обведенные вертикальные стрелки могут представлять собой пример того, когда типичный приемник отправляет запрос. В данном примере приемник будет получать два Activation Trigger для одной и той же активации события, но они будут иметь одинаковые времена активации события, так что приемник будет распознавать их как дубликаты и применять только один из них. Так как интервал между запросами приемника меньше L1, гарантируется что приемник делает, по меньшей мере, один запрос с сигнатурой для кадра в интервал L1, показанный на схеме. Это дает ему время вычислить сигнатуру, отправить запрос серверу ACR, и получить назад Activation Trigger в ответ, причем все до времени активации. В данном примере, первый Activation Trigger, который получает приемник будет доставлен значительно досрочно; второй Activation Trigger, который получает приемник, будет всего лишь прибывать вовремя (это дубликат).

[0682] Фиг. 30 является схемой, показывающей вариант осуществления триггеров активации в случае (b) и случае (a) без EndTime.

[0683] Будет приведено описание триггеров активации в случае (b) и случае (a) без EndTime.

[0684] Фиг. 30 показывает пример ситуации (a) в действие (4) выше, в случае, когда элемент Activation в AMT не имеет endTime. Это также является примером ситуации (b) на этапе (4) выше, где Модуль Захвата ACR отправляет динамический Activation Trigger, по меньшей мере, M единиц времени перед его временем активации.

[0685] Фиг. 30 показывает время активации события выше линии времени, с предшествующим интервалом продолжительностью M, охватывающим интервалы продолжительностей L1, L2, и L3. Стрелки ниже линии времени показывают времена индивидуальных кадров. Каждый кадр, предшествующий началу интервала продолжительностью M, или следующий за временем активации события, будет иметь ассоциированный с ним в Базе данных Trigger без термов <media_time> и <event_time>. Каждый кадр внутри интервала продолжительностью M будет иметь ассоциированный с ним в Базе данных Activation Trigger, такой как два примера в нижней части фигуры. Терм «d=» для каждого кадра будет указывать продолжительность времени между этим кадром и временем активации события (указанное обведенными f1 и f2).

[0686] Четыре обведенные вертикальные стрелки могут представлять собой пример, когда типичный приемник отправляет запрос. В данном примере приемник будет получать два Activation Trigger для одной и той же активации события, но времена активации, вычисленные посредством сложения значения <d1> с локальным временем приемника для кадра f1 или сложением значения <d2> с локальным временем приемника кадра f2, оба дают один и тот же результат, так что приемник будет распознавать их как дубликаты и применять только первый. Та