УСТРОЙСТВО И СПОСОБ ДЛЯ ОБРАБОТКИ ИНТЕРАКТИВНОЙ УСЛУГИ Российский патент 2016 года по МПК H04N21/4782 H04N21/858 H04H20/93 

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

[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, оба дают один и тот же результат, так что приемник будет распознавать их как дубликаты и применять только первый. Так как интервал между запросами приемника меньше L1, гарантируется, что приемник делает, по меньшей мере, один запрос с сигнатурой для кадра в интервале L1, показанном на схеме. Это дает ему время на вычисление сигнатуры, отправку запроса серверу ACR, и получение Activation Trigger в ответ, причем все перед временем активации. В данном примере, второй Activation Trigger, принимаемый приемником, будет пребывать после времени активации.

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

[0688] Фиг. 31 иллюстрирует ситуацию (a) в действие (4) выше, в случае, когда элемент Activation в AMT имеет endTime, как впрочем, и startTime.

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

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

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

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

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

[0694] Фиг. 32 иллюстрирует ситуацию (a) в действие (4) выше, в случае, когда элемент Activation в AMT имеет endTime, как впрочем, и startTime.

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

[0696] Обведенные вертикальные стрелки могут представлять собой пример, когда типичный приемник отправляет запрос. В данном случае приемник будет получать три Activation Trigger для одной и той же активации события, но времена активации, вычисленные посредством сложения значения <d1> с локальным временем приемника для кадра f1 или сложения значения <d2> с локальным временем приемника кадра f2 или сложением (отрицательного) значения <d3> с локальным временем приемника кадра f3, все дает один и тот же результат, так что приемник будет распознавать их как дубликаты и применять только первый.

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

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

[0699] Фиг. 33 иллюстрирует ситуацию (c) в действие (4) выше, где динамический Activation Trigger отправляется Модулю Захвата ACR позже чем за M единиц времени перед Временем Активации.

[0700] Фиг. 33 показывает время динамической активации события выше линии времени, и время незадолго предшествующее времени активации события, когда Модуль Захвата ACR узнает об активации события, с интервалом продолжительностью L1, следующим за временем, когда Модуль Захвата ACR узнает об активации события. Вертикальные стрелки ниже линии времени показывают времена индивидуальных кадров. Каждый кадр, предшествующий началу интервала продолжительностью L1, или следующий за концом интервала продолжительностью L1, будет иметь Time Base Trigger, ассоциированный с ним в Базе данных. Каждый кадр внутри интервала продолжительностью L1 будет иметь Activation Trigger в Базе данных, такой как тот, что в примере в нижней части фигуры. Терм «t=» для каждого кадра будет указывать время активации события, относительно линии времени мультимедиа (указано обведенными вертикальными стрелками). Обведенные вертикальные стрелки могут представлять собой пример, когда типичный приемник отправляет запрос. В данном случае приемник будет получать только один Activation Trigger для активации события. Поскольку время активации Activation Trigger предшествует времени, когда он был принят, приемник будет применять Trigger немедленно по приему.

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

[0702] Будет приведено описание триггеров активации для случая (c).

[0703] Фиг. 34 иллюстрирует ситуацию (c) в действие (4) выше, где динамический Activation Trigger отправляется Модулю Захвата ACR позже чем за M единиц времени перед Временем Активации.

[0704] Фиг. 34 показывает время динамической активации события выше линии времени, и время незадолго предшествующее времени активации события, когда Модуль Захвата ACR узнает об активации события, с интервалом продолжительностью M, следующим за временем, когда Модуль Захвата ACR узнает об активации события. Стрелки ниже линии времени показывают времена индивидуальных кадров. Каждый кадр, предшествующий началу интервала продолжительностью M, или следующий за концом интервала продолжительностью M, будет иметь Trigger в Базе данных без термов <media_time> и <event_time>. Каждый кадр внутри интервала продолжительностью M будет иметь Activation Trigger в Базе данных, такой как те, что в двух примерах в нижней части фигуры. Терм «d=» для каждого кадра будет указывать продолжительность времени между этим кадром и временем активации события (указано обведенными вертикальными стрелками). Обведенные вертикальные стрелки могут представлять собой пример, когда типичный приемник отправляет запрос. В данном случае приемник будет получать два Activation Trigger для одной и той же активации события, но времена активации, вычисленные посредством сложения (отрицательного) значения <d1> с локальным временем приемника кадра f1 и сложения (отрицательного) значения <d2> с локальным временем приемника кадра f2, оба дают один и то же результат, так что приемник будет распознавать их как дубликаты, и применять только первый, который он принял. Поскольку время активации первого Trigger находится перед временем, когда он был принят, приемник будет применять Trigger немедленно, когда он принимается.

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

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

[0707] Более того, серверу легко сохранять некоторый объем информации о каждом приемнике, такой как ID сегмента (<locator_part> у Trigger), соответствующую самому последнему представлению от приемника и последние Activation Trigger, отправленные приемнику.

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

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

[0710] Во-вторых, когда сервер ACR принимает сигнатуру от приемника, которая соответствует кадру в части сегмента, которой имеет новый номер версии для TPT (отличный от самой последней версии, которую видел приемник), сервер ACR может немедленно отправлять сообщение приемнику с Time Base Trigger, который имеет терм «v=», чтобы позволить приемнику получить новую версию ассоциированной TPT.

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

[0712] Архитектура случая Запроса/Ответа, показанная на Фиг. 28, также подходит для данного Событийно-Управляемого случая, с одним отличием. Отличие состоит в том, что для Событийно-Управляемого случая, может существовать новое действие (2a). Если присутствуют любые динамические Activation Trigger, тогда могут быть настроены соединения между Модулем Захвата ACR и всеми Серверами ACR, которые используют Базу данных, наполняемую Модулем Захвата ACR, так что Модуль Захвата ACR может отправлять выбранные динамические Activation Trigger Серверам ACR.

[0713] Пронумерованные действия для Событийно-Управляемого случая могут быть подобными тем, что для случая Запроса/Ответа. Кроме нового действия (2a), незначительно отличается действие (4), незначительно отличается действие (13), и добавляется новое действие (14).

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

[0715] (a) Присутствует элемент Activation в AMT такой, что media_time кадра находится в интервале времени, начинающемся в промежуток M времени перед startTime элемента Activation и заканчивающийся в endTime элемента Activation. (Если, у активации отсутствует endTime, endTime считается равным startTime). (Такое же, что и условие (a) для модели ACR Запроса/Ответа).

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

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

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

[0719] На действие (13), если Сервер ACR получает обратно индикатор «нет сопоставления» от Базы данных после того, как не принимает один для немедленного предшествующего предоставления, он может отправить приемнику сообщение NULL. Если он получает назад Trigger с <locator_part>, которая отличается от <locator_part>, которую он получил назад для немедленного предшествующего предоставления, он может отправить Trigger приемнику, причем в обоих случаях это может говорить приемнику о том, что, либо просматриваемый канал был изменен, либо просматриваемый сегмент подошел к концу, так что приемник может завершить любой TDO, который исполняется в настоящий момент, и при необходимости загрузить новую TPT. Если Сервер ACR получает обратно один или более Activation Trigger, он может отправить их приемнику, отбрасывая любые, которые являются дубликатами Activation Trigger, которые он уже отправил приемнику. В противном случае Сервер ACR может ничего не делать.

[0720] В новом действии (14), если Сервер ACR принимает динамический Activation Trigger, он может сравнивать <locator_part> динамического Activation Trigger с текущей <locator_part> для каждого из его клиентов ACR (где текущей <locator_part> для клиента является <locator_part> у Trigger, который Сервер ACR получил от Базы данных для самого последнего предоставления от клиента ACR. Для каждого клиента где <locator_part> сопоставлен, Сервер ACR может отправлять Activation Trigger клиенту.

[0721] Фиг. 29 и 31 показывают обработку Trigger для статических активаций и для динамических активаций, которые доставляются Модулю Захвата ACR, по меньшей мере, за M единиц времени перед их временем активации. Различие состоит в том, что Сервер ACR может отбрасывать дубликаты Activation Trigger, вместо отправки их приемникам.

[0722] Фиг. 35 показывает пример обработки динамического Activation Trigger, принятого в кратчайшие сроки (меньше чем за M единиц времени перед его временем активации).

[0723] Фиг. 35 показывает время динамической активации события выше линии времени, и время незначительно предшествует времени активации события, когда Модуль Захвата ACR узнает об активации события. Вертикальные стрелки ниже линии времени показывают времена индивидуальных кадров. Как только Сервер ACR принимает Activation Trigger от Модуля Захвата ACR, он может отправлять Activation Trigger всем приемникам, которые в настоящий момент просматривают сегмент, ассоциированный с Activation Trigger (как идентифицируется <locator_part> у Trigger).

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

[0725] Будет приведено описание динамических триггеров активации, доставленных в Последнюю минуту.

[0726] Фиг. 36 показывает пример обработки динамического Activation Trigger, принятого в кратчайшие сроки (меньше чем за M единиц времени перед его временем активации).

[0727] Фигура, Динамические Activation Trigger Доставленные в Последнюю минуту, показывает время динамической активации события выше линии времени, и время незначительно предшествующее времени активации события, когда Модуль Захвата ACR узнает об активации события. Стрелки ниже линии времени показывают времена индивидуальных кадров. Как только Сервер ACR принимает Activation Trigger от Модуля Захвата ACR, он может отправлять Activation Trigger всем приемникам, которые в настоящий момент просматривают сегмент ассоциированный с Activation Trigger (как идентифицируется <locator_part> у Trigger). Для каждого приемника он регулирует event_time у Trigger на <delay_time> относительно кадра, соответствующего самой последней предоставленной сигнатуре от приемника.

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

[0729] Фиг. 37 показывает циклограмму в соответствии с вариантом осуществления эффективной передачи триггера и TPT в соответствии с протоколом работы сервера ACR и приемника (клиента ACR) в модели запроса/ответа.

[0730] Теперь будет описана примерная работа модели запроса/ответа в очередности запроса и ответа.

[0731] Циклограмма между клиентом ACR и другими серверами в случае ACR запроса/ответа может включать в себя ACR запрос 1 (S37010), ACR ответ 1 (S37020), ACR запрос 2 (S37030), ACR ответ 2 (S37040), HTTP запрос 1 (S37050), HTTP ответ 1 (S37060), HTTP запрос 2 (S37070), HTTP ответ 2 (S37080), ACR запрос 3 (S37090), ACR ответ 3 (S37100), ACR запрос 4 (S37110), и/или ACR ответ 4 (S37120).

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

[0733] ACR ответ 1 (S37020) является этапом, на котором ACR сервер возвращает NULL, когда сигнатура не распознается или не присутствует имеющая отношение интерактивная услуга. Это может быть случаем, соответствующим упомянутому выше случаю, при котором возвращается ответ NULL.

[0734] ACR запрос 2 (S37030) является этапом, на котором, когда изменяется канал или программа, приемник передает сигнатуру измененной программы серверу ACR.

[0735] ACR ответ 2 (S37040) является этапом, на котором сервер ACR возвращает триггер (например, xbc.com/tpt504), включающий в себя адрес, по которому может быть получена интерактивная услуга, которая относится к соответствующей программе. Данный этап может соответствовать случаю, при котором сигнатура распознается, и имеющая отношение интерактивная услуга присутствует, в отличие от ACR ответу 1 (S37020). Т.е., на данном этапе триггер доступен. В данном случае, возвращенный триггер может быть основанным на времени триггером без информации о media_time.

[0736] HTTP запрос 1 (S37050) является этапом, на котором приемник запрашивает у сервера TPT (например, http://xbc.com/tpt504) предоставление соответствующей TPT, используя адрес, принятый в ACR ответе 2 (S37040) посредством протокола http.

[0737] HTTP ответ 1 (S37060) является этапом, на котором сервер TPT передает TPT представленную в XML на запрос приемника.

[0738] HTTP запрос 2 (S37070) является этапом, на котором приемник запрашивает у сервера контента предоставление приложения, такого как TDO, используя протокол http. Приемник может анализировать относящуюся к TDO информацию, включенную в TPT. Относящаяся к TDO информация может быть URL сервера контента, посредством которого может быть загружен TDO. Запрос может быть отправлен, используя URL сервера контента.

[0739] HTTP ответ 2 (S37080) является этапом, на котором сервер контента передает соответствующий TDO на запрос приемника.

[0740] ACR запрос 3 (S37090) является этапом, на котором приемник отправляет сигнатуру кадра просматриваемой в настоящий момент программы серверу ACR.

[0741] ACR ответ 3 (S37100) является этапом, на котором сервер ACR возвращает триггер (например, xbc.com/tpt504), включающий в себя адрес, посредством которого может быть получена интерактивная услуга, которая относится к соответствующей программе. В данном случае, сигнатура распознается, и имеющая отношение интерактивная услуга присутствует, в отличие от ACR ответу 1 (S37020). Т.е., на данном этапе триггер доступен.

[0742] ACR запрос 4 (S37110) является этапом, на котором приемник передает сигнатуру кадра просматриваемой в настоящий момент программы серверу ACR.

[0743] ACR ответ 4 (S37120) является этапом, на котором сервер ACR передает триггер активации, который относится к интерактивной услуге, которая относится к сигнатуре, переданной от приемника. Конкретное событие может быть активировано в конкретное время в соответствии с триггером активации.

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

[0745] Фиг. 38 показывает циклограмму в соответствии с вариантом осуществления эффективной передачи триггера и TPT в соответствии с протоколом работы сервера ACR и приемника (клиента ACR) в событийно-управляемой модели.

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

[0747] Циклограмма между клиентом ACR и другими серверами в событийно-управляемом случае ACR может включать в себя ACR запрос 1 (S38010), ACR запрос 2 (S38020), ACR событие 1 (S38030), HTTP запрос 1 (S38040), HTTP ответ 1 (S38050), HTTP запрос 2 (S38060), HTTP ответ 2 (S38070), ACR запрос 3 (S38080), ACR событие 2 (S38090) и/или ACR ответ 4 (S38100).

[0748] ACR запрос 1 (S38010), является этапом, на котором приемник передает сигнатуру просматриваемой в настоящий момент программы серверу. Сервер может быть описанным выше сервером ACR. Сигнатура может быть сигнатурой отпечатка пальцев или водяным знаком. Здесь, когда сигнатура не распознается или имеющая отношение интерактивная услуга не присутствует, сервер ACR может не отправлять ответа на ACR запрос 1 без возвращения NULL, в отличие от последовательности на Фиг. 37.

[0749] ACR запрос 2 (S38020) является этапом, на котором когда изменяется канал или программа, приемник передает сигнатуру измененной программы серверу ACR.

[0750] ACR событие 1 (S38030) является этапом, на котором сервер ACR возвращает триггер (например, xbc.com/tpt504), включающий в себя адрес, посредством которого может быть получена интерактивная услуга, которая относится к соответствующей программе. Данный этап может соответствовать случаю, при котором сигнатура распознается, и имеющая отношение интерактивная услуга присутствует. Т.е., на данном этапе триггер доступен. В данном случае, возвращаемым триггером может быть основанный на времени триггер без информации о media_time.

[0751] HTTP запрос 1 (S38040) является этапом, на котором приемник запрашивает у сервера TPT (например, http://xbc.com/tpt504) предоставление соответствующей TPT, используя адрес, принятый в ACR событии 1 (S38030) посредством протокола http.

[0752] HTTP ответ 1 (S38050) является этапом, на котором сервер TPT передает TPT представленную в XML на запрос приемника.

[0753] HTTP запрос 2 (S38060) является этапом, на котором приемник запрашивает у сервера контента предоставление приложения, такого как TDO, используя протокол http. Приемник может анализировать относящуюся к TDO информацию, включенную в TPT. Относящаяся к TDO информация может быть URL сервера контента, посредством которого может быть загружен TDO. Запрос может быть отправлен, используя URL сервера контента.

[0754] HTTP ответ 2 (S38070) является этапом, на котором сервер контента передает соответствующий TDO на запрос приемника.

[0755] ACR запрос 3 (S38080) является этапом, на котором приемник отправляет сигнатуру кадра просматриваемой в настоящий момент программы серверу ACR.

[0756] ACR событие 2 (S38090) является этапом, на котором сервер ACR передает триггер активации, который относится к интерактивной услуге, которая относится к сигнатуре, переданной от приемника. Конкретное событие может быть активировано в конкретное время в соответствии с триггером активации.

[0757] ACR запрос 4 (S38100) является этапом, на котором приемник передает сигнатуру кадра просматриваемой в настоящий момент программы серверу ACR.

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

[0759] Поддержка второго экрана относится к способу, на приемнике, предоставления услуги вещательной компании или добавочной услуги пригодной для программы, предоставляемой вещательной компанией, устройству второго экрана. Добавочный контент может быть предоставлен через приложение и приложение может быть отображено на TV экране таким образом, что пользователь использует добавочный контент посредством манипулирования пультом дистанционного управления. Тем не менее, в настоящее время, через персонализированные инструменты информации (интеллектуальные телефоны, интеллектуальные планшеты и компьютеры класса лэптоп с уменьшенными габаритами и весом), добавочные услуги могут быть отображены на устройстве второго экрана при отображении воспроизводимого контента на TV экране. Вследствие этого, пользователь может персонально использовать добавочные услуги, не прерывая вещательного контента. Если такие добавочные данные или информация отображаются и обрабатываются на устройстве второго экрана, когда несколько человек вместе просматривают TV, то только человек заинтересованный в добавочной услуге может получать добавочный контент не нарушая просмотр TV другими людьми. Поддержка второго экрана может по-разному использоваться в дополнение к описанным выше эффектам.

[0760] Для соединения и управления одного устройства с другими устройствами, сначала, должно быть выявлено, какие устройства включены в домашнюю сеть. Соответственно, одно или более устройства периодически переедают сообщения в домашнюю сеть с тем, чтобы уведомлять о том, что устройства присутствуют в домашней сети. Если одно устройство является вновь подключенным к домашней сети, устройство может спрашивать о том, какие устройства присутствуют в домашней сети перед уведомлением о том, что устройство является вновь соединенным. Такие способы соединения могут способствовать простому и быстрому распознаванию присутствия устройств. Обнаружение устройств UPnP является одним из способов достижения этого. Если устройство детектировано, другим устройствам, заинтересованным в детектированном устройстве, может потребоваться информация о том, какие услуги могут быть предоставлены этому устройству. Электронные устройства, в которых инсталлирована инфраструктура UPnP, могут подтверждать взаимные функции и поддерживаемые диапазоны функции. Данная информация может быть определена в Профиле Устройства UPnP таким образом, что устройства подтверждают атрибуты взаимно предоставляемых услуг. Всегда может быть ожидаемо устройство для предоставления конкретной услуги. Если детектируется устройство для предоставления конкретной услуги, существует возможность спросить о том, какие услуги включены в детектированное устройство. Если присутствует требуемая услуга в детектированном устройстве, может быть выполнено немедленное соединение с детектированным устройством для осуществления связи. Как определено в Дескрипторе Услуги UPnP, может осуществлять определение и обмен услугами.

[0761] Поскольку одно устройство имеет одну услугу или множество услуг, может осуществляться управление и использование услуг(и) другими устройствами. Если устройство имеет одну или более функции, множество услуг, другими устройствами осуществляется включение и управление соответствующими функциями. Определение устройство может обладать уникальной информацией об устройстве. Например, уникальная информация об устройстве может включать в себя информацию, такую как Имя Модели, Серийный Номер, Номер Модели, Имя Изготовителя CE и Web-сайт. Данная информация может иметь уникальное значение для каждого устройства и, как правило, не может быть изменена. Услуга является операцией, выполняемой устройством, которая именуется действием, и каждое устройство может обладать одним или более действиями. Действие обладает значением параметра, таким как функция, и может обладать одним или более значениями параметров. Действие выполняется услугой устройства и возвращаемое значение, определенное как требуемое, может быть возвращено после выполнения действия.

[0762] В качестве примера действия, Фиг. 39 показывает типы действий услуги Клиента RemoteUI UPnP и их описания. Соединение/разъединение может быть действием для возвращения текущих состояний соединения. GetCurrentConnection может быть действием для возвращения текущего списка соединения. GetDeviceProfile может быть действием для возвращения профиля устройства как выраженного в XML. GetUIListing может быть действием для возвращения списка совместимого UI как выраженного в XML. AddUIListing/RemoveUIListing может быть действием для добавления URL удаленного UI в список UI или удаления URL удаленного UI из списка UI. ProcessInput может быть действием для отправки данных услуге Клиента RemoteUI. DisplayMessage может быть действием для отображения сообщения на устройстве, включающем услугу Клиента RemoteUI.

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

[0764] В UPnP, формат сообщения XML, такой как SOAP, может быть использован для передачи описанных выше действий и необходимых значений параметров, и SOAP может быть использован для удаленного выполнения удаленной процедуры. Эти сообщения могут быть переданы используя HTTP.

[0765] Действия описанного выше Клиента RemoteUI могут быть выполнены как показано на Фиг. 40. Действия, показанные на Фиг. 40, являются лишь примерами описанных выше действий.

[0766] Один вариант осуществления Услуги Клиента RemoteUI UPnP может быть разделен на Процесс Обнаружения UPnP и Action Клиента RemoteUI.

[0767] Процесс Обнаружения UPnP может включать в себя исполнение (s40001) приложения UPnP для услуги второго экрана, нахождение (s40010) устройств UPnP, нахождение (s40020) RemoteUIClient, запрос (s40030) описания устройства, прием (S40040) описания устройства, запрос описания управления услугой (s40050) и/или прием (s40060) описания управления услугой.

[0768] Action Клиента RemoteUI могут включать в себя запрос (s40070) профиля устройства, прием (s40080) профиля устройства, введение (s40090) URL Remote UI, отправку (s40100) response1 (ответ 1), отправку (s40110) сообщения Услуге Клиента RemoteUI, отправку (s40120) response2 (ответ 2) и/или щелчок (s40130) пользователя по кнопке на экране.

[0769] Исполнение (s40001) приложения UPnP для услуги второго экрана может включать в себя исполнение приложения UPnP в устройстве второго экрана (Клиент RemoteUI).

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

[0771] Нахождение (s40020) RemoteUIClient может включать в себя прием устройством второго экрана сообщения обнаружения и отправку сообщения уведомления основному устройству.

[0772] Запрос (s40030) Описания Устройства может включать в себя запрос основным устройством описания устройства применительно к устройству второго экрана у устройства второго экрана.

[0773] Прием (S40040) описания устройства может включать в себя прием основным устройством профиля устройства устройства второго экрана, когда устройство второго экрана передает профиль устройства устройства второго экрана в ответ на запрос (s40030) Описания Устройства.

[0774] Запрос (s40050) описания управления услугой может включать в себя запрос основным устройством описания управления услугой у устройства второго экрана.

[0775] Прием (s40060) описания управления услугой может включать в себя прием основным устройством запрошенного описания управления услугой от устройства второго экрана.

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

[0777] Запрос (s40070) профиля устройства может включать в себя запрос профиля устройства устройства второго экрана. Может быть использовано описанное выше действие GetDeviceProfile.

[0778] Прием (s40080) профиля устройства может включать в себя прием основным устройством запрошенного профиля устройства устройства второго экрана. Устройство (устройство второго экрана и Клиент RemoteUI) с «Услугой Клиента RemoteUI» может быть отвечающим за нахождение и отображение URL адреса UI на экране, если удаленное устройство (основное устройство) отправляет URL-адрес UI. В дополнение, устройство с «Услугой Сервера RemoteUI» может осуществлять многоадресную передачу URL адреса UI для уведомления заинтересованных устройств об URL адресе. Тем не менее в данном случае, поскольку удаленные UI выполняются для конкретного устройства, должно быть предоставлен удаленный UI, подходящий для конкретного устройства. Соответственно, также требуется чтобы была передана информация о профиле устройства, и могут потребоваться запрос (s40070) профиля устройства и прием (s40080) профиля устройства.

[0779] Введение (s40090) URL Remote UI может включать в себя уведомление устройства второго экрана о URL адресе Удаленного UI. Может быть использовано описанное выше действие AddUIListing. Устройство второго экрана может добавлять URL адрес удаленного UI в UIListing.

[0780] Отправка (s40100) response1 может включать в себя отправку результат введения (s40090) URL Удаленного UI. В зависимости от обстоятельств, может быть отправлен ответ, такой как HTTP/1.1 200 OK (запрос успешно обработан), HTTP/1.1 501 Способ Не Реализован (Не реализована функция, необходимая для обработки запроса), и HTTP/1.1 400 Не Найден (Запрашиваемые файлы/ресурсы не присутствуют).

[0781] Отправка (s40110) сообщения Услуге Клиента RemoteUI может включать в себя передачу основным устройством сообщения отображения устройству второго экрана. Сообщение отображения может включать в себя информацию, такую как тип сообщения. Может быть использовано описанное выше действие DisplayMessage. Устройство второго экрана может отображать сообщение на втором экране в соответствии с сообщением отображения.

[0782] Отправка (s40120) response2 может включать в себя отправку результата отправки (s40110) сообщения Услуге Клиента RemoteUI. Подобно (s40100) отправке responce1, может быть отправлен ответ такой как HTTP/1.1 200 OK.

[0783] Щелчок (s40130) пользователя по кнопке на экране может включать в себя выполнение пользователем выбора в соответствии с отображаемым сообщением на втором экране.

[0784] Action Клиента RemoteUI описывают процесс работы услуги Клиента RemoteUI через описанные выше действия.

[0785] При описании удаленного интерфейса пользователя, функции, которые могут быть использованы в существующей системе PC, могут быть упрощены принимая во внимание ресурсы электронного устройства, функция которого добавляется или ограничивается таким образом, что основанное на HTML приложение может быть использовано в электронном устройство. Данное описание в значительной степени включает две точки зрения: применение HTML отображаемого на экране потребительской электроники и определение API браузера, который применим к потребительской электронике. API браузера может именоваться и используется из JavaScript, который является широко используемым языком написания сценариев. В результате, API, вызываемый из JavaScript, вызывает функцию приемника.

[0786] Среди прочего, описанные выше устройство UPnP и услуги могут быть исполнены посредством JavaScript, исполняемого в браузере. Существует потребность в новом API для доставки других параметров устройств UPnP в браузер.

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

[0788] Как описано выше, описанный выше триггер может быть передан, используя услугу закрытых субтитров цифрового TV (DTVCC). Триггер может иметь одно значение строки URL и может быть принят в качестве услуги серии #6 DTVCC. Процессор 41010 Транспорта MPEG-2 может принимать триггер в качестве Услуги Серии #6 DTVCC и передавать триггер модулю 41040 DTV-CC через драйвер 41020 процессора транспорта. На этот раз, данные пользователя могут проходить через буфер 41030. Модуль 41040 DTV-CC может служить в качестве Декодера DTVCC. Модуль 41040 DTV-CC может отправлять триггер со значением Строки URI модулю 41050 вспомогательной услуги. Модуль 41050 вспомогательной услуги является модулем триггера, который может детектировать значение Строки URI с тем, чтобы получать описанную выше TPT (Таблицу Параметров TDO). Как описано выше, существует возможность предоставления вспомогательной услуги, используя триггер, TPT и TDO.

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

[0790] Для поддержки второго экрана, может существовать несколько требований. 1) Приемник может быть соединен с одним или более устройствами второго экрана. 2) Устройство второго экрана может быть портативным устройством, таким как компьютер класса лэптоп, планшет, интеллектуальный телефон, или PDA. 3) Основным контентом второго экрана может быть HTML, Текст, Видео, Аудио, и т.д. 4) Контент, воспроизводимый на втором экране, может быть разработан таким образом, чтобы не прерывать вещательную программу основного устройства (приемника). 5) Второй экран может быть соединен с приемником ATSC 2.0 непосредственно или опосредованно через сеть 3GPP. 6) Поставщик может сигнализировать конкретный контент, который должен быть отображен только на втором экране. 7) В зависимости от обстоятельств, контент, воспроизводимый приемником, может быть разработан для воспроизведения вторым экраном. 8) Второй экран, подвергнутый аутентификации и авторизации может использовать услугу второго экрана. 9) Может быть измерена аудитория использования контента второго экрана. (В данном случае, для того, чтобы получить такую информацию, должно быть получено согласие пользователя и может потребоваться функция для такой информации) и 10) Это может быть предоставлено через устройство, выполненное с возможностью расширения вторичного языка или контента.

[0791] Данное техническое описание может описывать услуги, которые могут быть предоставлены Приемником для поддержки отображения контента, который относится к A/V вещанию посредством приложений, работающих на устройствах второго экрана (интеллектуальных телефонах, планшетах, лэптопах, и т.д.), включая контент, синхронизированный с программами вещания, которые вещаются. Услуга описывается на основании Архитектуры Устройства UPnP.

[0792] В данном техническом описании, Приемник ATSC 2.0 может быть TV приемником или нормальным приемником. В дополнение, Приемник ATSC 2.0 может быть приемником в DVB, ATSC, и т.д.

[0793] Архитектура Устройства UPnP определяет протоколы для связи в IP-сети между «управляемыми устройствами», которые предоставляют услуги, и «точками управления» которые используют эти услуги. В сценарии «второго экрана», TV приемник может играть роль «управляемого устройства», а устройство второго экрана может играть роль «точки управления» и наоборот.

[0794] Архитектура Устройства UPnP указывает, протоколы «обнаружения» для точек управления с целью обнаружения интересующих управляемых устройств, протоколы «описания» для точек управления с целью изучения подробностей касательно управляемых устройств и услуг, протоколы «управления» для точек управления с целью вызова «действий» (способов) на управляемых устройствах, и протоколы «обработки событий» для управляемых устройств с целью доставки асинхронных уведомлений точкам управления. Действия и события могут быть предоставлены услугами устройства.

[0795] Когда управляемое устройство UPnP присоединяется к сети, оно может осуществлять многоадресную передачу сообщений обнаружения по «хорошо известному» многоадресному IP-адресу и порту. Эти сообщения могут идентифицировать тип устройства и типы услуг, предлагаемых устройством, и они могут давать URL, по которым могут быть получены описания устройства и услуг.

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

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

[0798] Типичные Сценарии Обнаружения Второго Экрана могут быть в основном разделены на Сценарий A и сценарий B. В случае Сценария A, пользователь имеет приложение второго экрана, работающее на его/ее устройстве второго экрана, когда TV приемник присоединяется к сети (что возможно происходит, когда TV приемник включается, или возможно, когда разблокирован его сетевой интерфейс). В случае Сценария B, пользователь не имеет приложения второго экрана, работающего на его/ее устройстве второго экрана, когда TV приемник присоединяется к сети.

[0799] Сценарий A может быть следующим. 1) TV приемник, который предоставляет поддержку второго экрана присоединяется к сети. 2) TV приемник осуществляет многоадресную передачу своих сообщений обнаружения, которые анонсируют его услуги поддержки второго экрана. 3) Приложение второго экрана, работающее на устройстве второго экрана, принимает многоадресные сообщения обнаружения и отправляет TV приемнику запрос в отношении описаний его услуг. 4) TV приемник отвечает с помощью описаний его услуг. 5) Приложение второго экрана использует информацию, заданную в описаниях, для получения доступа к подходящим услугам и обеспечивает интерактивное восприятие, синхронизированное с TV программами вещания.

[0800] Сценарий B может быть следующим. 1) TV программы вещания, просматриваемые на TV приемнике, входят в сегмент программы, который предлагает поддержку второго экрана. (Это может происходить, как только телевизор включается, или, когда изменение канала переходит от канала, который не предлагает интерактивную услугу данных с поддержкой второго экрана, к тому, который это предлагает, или, когда просматриваемый канала переходит от сегмента программы, который не предлагает интерактивную услугу данных с поддержкой второго экрана, к сегменту, который это предлагает). 2) Это предписывает TV приемнику проинформировать зрителей неким образом о том, что доступна поддержка второго экрана - например, посредством небольшой пиктограммы в углу экран. 3) Зритель решает воспользоваться преимуществом поддержки второго экрана и активирует приложение второго экрана на его/ее устройстве второго экрана. Приложение второго экрана затем осуществляет многоадресную передачу сообщения, осуществляющего поиск устройств, которые предлагают поддержку второго экрана. TV приемник отвечает на данное сообщение с помощью своих сообщений обнаружения. 4) Когда приложение второго экрана принимает сообщения обнаружения, оно отправляет TV приемнику запрос в отношении описаний его услуг. 5) TV приемник отвечает с помощью описаний его услуг. 6) Приложение второго экрана использует информацию, заданную в описаниях, для получения доступа к подходящим услугам и предоставляет интерактивное восприятие, синхронизированное с TV программами вещания.

[0801] Сценарий A также может быть следующим. 1) Телевизор, который предоставляет поддержку второго экрана присоединяется к сети. (Это может происходить, когда телевизор включается, или, когда происходит разблокировка его сетевой интерфейс). 2) Это предписывает TV приемнику выполнить многоадресную передачу своих сообщений обнаружения, которые анонсируют его и его услуги поддержки второго экрана. 3) Если пользователь имеет Приложение Второго Экрана, работающее на его/ее устройстве второго экрана, на этот раз, приложение принимает многоадресные сообщения обнаружения и переходит к этапу (7). 4) TV программы вещания, просматриваемые на TV приемнике, входят в сегмент программы, который предлагает поддержку второго экрана. (Это может происходить, как только телевизор включается, или, когда изменение канала переходит от канала, который не предлагает интерактивную услугу данных с поддержкой второго экрана, к тому, который это предлагает, или, когда просматриваемый канала переходит от сегмента программы, который не предлагает интерактивную услугу данных с поддержкой второго экрана, к сегменту, который это предлагает). 5) Это предписывает TV приемнику проинформировать зрителей неким образом о том, что доступна поддержка второго экрана - например, посредством небольшой пиктограммы в углу экрана. 6) Если зритель еще не имеет Приложения Второго Экрана, работающего на его/ее устройстве второго экрана, зритель может решить воспользоваться преимуществом поддержки второго экрана и активировать Приложение Второго Экрана на его/ее устройстве второго экрана. Затем Приложение Второго Экрана осуществляет многоадресную передачу сообщения, осуществляющего поиск устройств, которые предлагают поддержку второго экрана. TV приемник отвечает на данное сообщение с помощью его сообщений обнаружения. 7) Когда Приложение Второго Экрана принимает сообщения обнаружения, оно отправляет TV приемнику запрос в отношении описаний его услуг. 8) TV приемник отвечает с помощью описаний его услуг. Это будет услуга Trigger и опционально услуга Прокси-Сервера HTTP. 9) Приложение Второго Экрана будет подписываться на свойство «управления событием» услуги Trigger. Если моделью взаимодействия предлагаемой интерактивной услуги данных является модель Непосредственного Исполнения, услуга Trigger будет отправлять все Trigger устройству второго экрана по мере того, как они принимаются TV приемником. Если моделью взаимодействия интерактивной услуги данных является модель TDO, услуга Trigger будет отправлять Activation Trigger Приложению Второго Экрана всякий раз, когда наступает время нового Activation Trigger. 10) Приложение Второго Экрана будет реагировать на Trigger, загружая TDO и другие файлы при необходимости, либо по Интернет ссылке, либо через услугу Прокси-Сервера HTTP, предлагаемую TV приемником, и предоставляя интерактивную услугу пользователю устройства второго экрана. 11) Всякий раз, когда TV программы вещания на TV приемнике переходят к сегменту, который не предлагает интерактивную услугу данных с поддержкой второго экрана, услуга Trigger будет отправлять «null Trigger» (пустой триггер) Приложению Второго Экрана для уведомления его о том, что интерактивная услуга данных для устройства второго экрана более недоступна. 12) Пользователь устройства второго экрана затем может закрывать Приложение Второго Экрана или оставлять его работающим для возобновления интерактивности всякий раз, когда программы вещания на TV приемнике входят в другой сегмент, который предлагает поддержку второго экрана.

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

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

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

[0805] Типичным сценарием упакованных приложений второго экрана является следующий. 1) Точка управления в устройстве второго экрана подписывается на услугу Упакованных Приложений в устройстве первого экрана. 2) Потребитель запускает Упакованное Приложение на устройстве первого экрана. 3) Упакованное Приложение делает доступным имя приложения второго экрана и URL приложения второго экран услуге Упакованного Приложения. 4) Точка управления в устройстве второго экрана принимает имя и URL приложения-компаньона. 5) Точка управления устанавливает маркер на втором экране, указывающий необходимость действия потребителя. 6) Потребитель просматривает имя приложения второго экрана и выбирает его. 7) Точка управления запускает указанное приложение второго экрана.

[0806] Устройство первого экрана, которое предоставляет поддержку второго экрана, может предлагать несколько услуг UPnP для использования приложениями второго экрана. Одной из услуг UPnP является «услуга URL Приложения», которая является предоставляющей имя и URL приложения-компаньона второго экрана, которое должно быть исполнено в устройстве второго экрана.

[0807] Будет описана архитектура системы для сценария второго экрана.

[0808] Архитектура системы для сценария второго экрана может включать в себя систему 42010 вещания, сервер 42020 ACR, сервер 42030 вещательной компании ATSC 2.0 iTV, приемник 42040 ATSC 2.0 и/или устройства 42050 второго экрана.

[0809] Система 42010 вещания может быть нормальной вещательной системой и может доставлять триггеры, A/V, TPT и/или другие файлы данных через вещательную сеть. Триггер может быть передан через DTVCC, как описано выше.

[0810] Сервер 42020 ACR является сервером для управления относящимися к ACR данными вещательного контента, и может передавать триггер приемнику 42040 ATSC 2.0 таким образом, что приемник 42040 ATSC 2/0 получает интерактивную услугу как запрашивается или требуется. Он может быть равен описанному выше серверу ACR.

[0811] Сервер 42030 вещательной компании ATSC 2.0 iTV является сервером для генерирования и управления интерактивной услугой, и может осуществлять управление ассоциированными TDO/файлами и генерировать и управлять таблицей параметров TDO (TPT), включающей в себя информацию об ассоциированных TDO/файлах.

[0812] Приемник 42040 ATSC 2.0 может принимать триггер, который относится к вещательному A/V и интерактивной услуге, и получать и предоставлять интерактивную услугу на экране, используя триггер. Он может быть равен описанному выше приемнику.

[0813] Устройства 42050 второго экрана могут включать в себя мобильный телефон, планшет, лэптоп, и т.д., которые являются устройствами второго экрана. Они могут быть равны описанному выше устройству второго экрана.

[0814] Trigger могут быть доставлены приемнику (42040) ATSC 2.0 через канал DTVCC или через процесс ACR или от Сервера (42030) Вещательной Компании интерактивного TV (iTV). Во всех случаях Trigger проходят от приемника (42040) ATSC 2.0 к устройствам (42050) второго экрана в подходящие времена. Данное техническое описание описывает механизм для того, чтобы Trigger проходили к устройствам (42050) второго экрана. Оно также описывает механизмы, чтобы DO, работающие в приемнике (42040) ATSC 2.0, создавали двустороннюю связь с устройствами (42050) второго экрана.

[0815] Приложения и другие файлы, которые доступны через сеть Интернет, могут быть извлечены устройствами (42050) второго экрана через домашнюю сеть, через отдельную сеть 3GPP, или через Прокси-Сервер HTTP (не показан) в приемнике (42040) ATSC 2.0, если он предлагает эту услугу. Приложения, исполняемые на устройствах первого экрана, могут быть Упакованными Приложениями, загружаемыми из сети Интернет, или приложениями, передаваемыми посредством вещания.

[0816] Приложения и другие файлы, которые доступны только через сеансы FLUTE в вещании, могут быть извлечены устройствами (42050) второго экрана только, если приемник (42040) ATSC 2.0 предлагает Прокси-Сервер HTTP, который будет доставлять файлы FLUTE, когда запрашиваются (предполагая, что устройства (4205) второго экрана не включают в себя TV приемник).

[0817] Данное техническое описание также описывает механизм, посредством которого Упакованные приложения, работающие на приемнике (4200) ATSC 2.0, поддерживают запуск приложений на устройствах (42050) второго экрана.

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

[0819] Фиг. 43 иллюстрирует прямое соединение между приемником ATSC 2.0 и устройством второго экрана.

[0820] Вариант осуществления топологии между приемником ATSC 2.0 и вторым экраном (Прямое Соединение) может включать в себя систему 43010 вещания, сервер 43020 вещательной компании ATSC 2.0, приемник 43030 ATSC 2.0 и/или устройства 43040 второго экрана.

[0821] Система 43010 вещания может быть равна системе 42010 вещания.

[0822] Сервер 43020 вещательной компании ATSC 2.0 может быть равен серверу 42030 вещательной компании ATSC 2.0 iTV.

[0823] Приемник 43030 ATSC 2.0 может быть равен приемнику 42040 ATSC 2.0.

[0824] Устройства 43040 второго экрана могут быть равны устройствам 42050 второго экрана.

[0825] Приемник 43030 ATSC 2.0 может быть соединен с вещательной сетью для непосредственного приема наземного вещания. Соответственно, приемник 43030 ATSC 2.0 может извлекать строку URL сообщения iTV, передаваемого через DTVCC от Услуги Номер 6 DTVCC. В дополнение, приемник 43030 ATSC 2.0 может быть соединен с домашним шлюзом для получения доступа к сети Интернет при необходимости. Приемник 43030 ATSC 2.0 может осуществлять связь с устройствами, соединенными с другими домашними сетями, используя технологию организации домашней сети (UPnP).

[0826] Устройства 43040 второго экрана все соединены с домашним шлюзом для осуществления связи с устройствами и свободного доступа к сети интернет. Домашний шлюз может включать в себя все функции для обеспечения Ethernet и Wi-Fi.

[0827] Вещательная компания может предоставлять добавочную услугу через Интернет сервер применительно к интерактивной услуге. Приемник 43030 ATSC 2.0 или устройства 43040 второго экрана могут получать доступ к серверу для загрузки TDO или web-страницы для мобильного устройства. В случае приемника 43030 ATSC 2.0, web-страница может быть визуализирована с разрешением TV, а в случае устройств 43040 второго экрана, web-страница может быть визуализирована с разрешение и API отличными от тех, что у TV.

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

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

[0830] Фиг. 44 иллюстрирует непрямое соединение между приемником ATSC 2.0 и устройством второго экрана.

[0831] Вариант осуществления топологии между приемником ATSC 2.0 и вторым экраном (Непрямое Соединение) может включать в себя систему 44010 вещания, сервер 4020 вещательной компании ATSC 2.0, устройство 44030 управления сеансом вещательной компании, приемник 44040 ATSC 2.0 и/или устройства 44050 второго экрана.

[0832] Система 44010 вещания может быть равна системе 42010 вещания.

[0833] Сервер 44020 вещательной компании ATSC 2.0 может быть равен серверу 42030 вещательной компании ATSC 2.0 iTV.

[0834] Устройство 44030 управления сеансом вещательной компании может служить для управления непрямым соединением между устройством 44050 второго экрана и приемником 44040 ATSC 2.0.

[0835] Приемник 44040 ATSC 2.0 может быть равен приемнику 42040 ATSC 2.0.

[0836] Устройства 44050 второго экрана могут быть равны устройствам 42050 второго экрана.

[0837] Непрямое соединение на Фиг. 44 не указывает на то, что устройства 44050 второго экрана соединяются с приемником 44040 ATSC 2.0 через домашний шлюз, а указывают на то, что устройства 44050 второго экрана непосредственно соединены с сетью 3GPP, чтобы быть соединенными с приемником 44040 ATSC 2.0 через домашнюю сеть. В данном случае, сложно соединить устройства 44050 второго экрана с домашней сетью или может не присутствовать сетевой интерфейс, поддерживающий домашнюю сеть.

[0838] В данном случае, устройствам 44050 второго экрана может требоваться информация о приемнике 44040 ATSC 2.0, хранящаяся на внешнем Интернет сервере. В дополнение, приемник 44040 ATSC 2.0 представляет отчет с адресом доступа внешнему Интернет серверу после начала работы.

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

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

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

[0842] Поскольку устройство второго экрана может воспроизводить Интернет контент, OS может предоставлять среду, в которой может быть исполнено web-приложение, для программистов, используя платформу SDK. Среда может быть предоставлена в форме SDK, так что приложение, исполняемое OS непосредственно отображает Интернет контент.

[0843] На Фиг. 45, Приложение Услуги Второго Экрана может работать на Устройстве Второго Экрана. Данное приложение может быть загружено из AppStore (или некоторого вида магазина приложений). Положение Услуги Второго Экрана может включать в себя Клиента ACR и использовать микрофон и камеру для захвата видео и аудио данных с телевизора. Более того, клиент ACR может производить выборку видео и аудио данных и отправлять мультимедиа сигнатуру серверу ACR. Приложение Услуги Второго Экрана может работать под управление OS и включать в себя протокол, такой как HTTP, SSDP или Многоадресное Событие, в соответствии с которым может работать Инфраструктура UPnP, и может быть включен модуль браузера для того, чтобы выполнять и отображать web-приложение.

[0844] Модуль браузера может быть модулем для визуализации web-страниц сети Интернет. Модуль браузера является базовой частью машины web-браузера для визуализации Web-приложения (например, ECMAScript, HTML и XHTML). В дополнение, модуль браузера может означать модуль программного обеспечения для предоставления функции равной или аналогичной браузеру, предоставляемому OS. Способ использования браузера и управляемые функции отличаются в зависимости от OS.

[0845] Приложение Второго Экрана может быть web-приложением, которое разработано для устройств Второго Экрана. Приложение Второго Экрана может быть web-приложением для вызова функций в соответствии с ECMAScript и web-приложением, размер которого управляется, чтобы быть исполненным в модуле браузера, предоставляемом мобильной OS. Данное web-приложение может быть исполнено в Приложении Услуги Второго Экрана.

[0846] Операционная система для мобильного устройства может состоять из драйверов, поддерживающих аппаратное обеспечение, и включать в себя драйверы для услуги для конкретного ядра. По существу, существует возможность поддержки только протоколов IP, TCP и UDP. Стек сетевых протоколов присутствует над OS. В случае UPnP, HTTP может быть передан при помощи UDP.

[0847] Инфраструктура DCP UPnP может означать точки управления устройством, определенные в Форуме UPnP.

[0848] SSDP (Простой Протокол Обнаружения Услуги) может осуществлять поиск одной или более услуг в соответствии с устройством, соединенным с сетью в домашней сети.

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

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

[0851] Описание каждого объекта на Фиг. 46 может быть равно тому, что приведено для Фиг. 45 в плане роли и функции.

[0852] Клиент Trigger ATSC 2.0 может означать модуль для приема и обработки описанных выше триггеров, TPT, AMT, и т.д. Данный модуль может быть включен в устройство второго экрана в зависимости от обстоятельств. Если данный модуль включен в устройство второго экрана, данный модуль может непосредственно обрабатывать TPT и AMT для непосредственной проверки жизненного цикла приложения.

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

[0854] Приемник может непосредственно принимать TPT и AMT, используя DVTCC через вещательную сеть или загружать TPT и AMT через сеть Интернет и обрабатывать TPT и AMT. Как описано выше, TPT включает в себя информацию события и информация события включает в себя информацию EventId, Action, Destination и Data. «Event@Destination» может указывать на то, для какого устройства сгенерирована данная информация события. Например, получателем может быть приемник или устройство второго экрана. Если получателем установлено устройство второго экрана, приемник должен доставить информацию события устройству второго экрана.

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

[0856] Таблица на Фиг. 47 показывает краткое изложение способов доставки информации в зависимости от того, какой объект управляет жизненным циклом приложения второго экрана.

[0857] Первой строкой может быть краткое изложение описания описываемого ниже случая с Фиг. 51 и его подробное описание будет приведено ниже.

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

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

[0860] Четвертая строка может быть кратким изложением описания описываемого ниже случая с Фиг. 58 и его подробное описание будет приведено ниже.

[0861] Пятая строка может быть кратким изложением описания описываемого ниже случая с Фиг. 57 и его подробное описание будет приведено ниже.

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

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

[0864] Как показано на схеме, показывающей рабочую концепцию модели централизованного исполнения, телевизор может генерировать и обновлять RUI, который должен быть отображен на каждом устройстве второго экрана, используя механизм RUI UPnP, и передавать RUI через сеть. Каждое устройство второго экрана может принимать RUI через клиента RUI в режиме реального времени и отображать RUI на экране. В отличие от модели распределенного исполнения, в основном устройстве может присутствовать DAE.

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

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

[0867] Вариант осуществления потока согласованной работы между приемником, основанным на модели централизованного исполнения, и вторым экраном может включать в себя отправку (s49010) триггера координаты времени, запрос (s49020) TPT, передачу (s49030) TPT в качестве ответа, анализ (s49040) TPT, отправку (s49050) триггера исполнения для второго экрана, загрузку (s49060) TDO/Файлов, генерирование (s49070) RUI, отправку (s49080) RUI через протокол RUI, отображение (s49090) UI на экране, щелчок (s49100) пользователя по ссылке в отношении новой страницы, отправку (s49110) данных ввода, загрузку (s49120) нового TDO/файла, обновление (s49130) RUI, отправку (s49140) RUI через протокол RUI и/или отображение (s49150) UI на экране.

[0868] Отправка (s49010) триггера координаты времени может включать в себя прием приемником триггера координаты времени через DTVCC или сервер ACR. Триггер координаты времени был описан выше.

[0869] Запрос (s49020) TPT может включать в себя интерпретирование приемником принятого триггера, получение URL сервера, выполненного с возможностью получения TPT, и запрос TPT.

[0870] Передача (s49030) TPT в качестве ответа может включать в себя передачу TPT в ответ на запрос при запросе (S49020) TPT.

[0871] Анализ (s49040) TPT может включать в себя анализ приемником запрошенной TPT.

[0872] Отправка (s49050) триггера исполнения для второго экрана может включать в себя прием приемником триггера исполнения для второго экрана через DTVCC или сервер ACR. Триггер исполнения может быть равен описанному выше триггеру активации.

[0873] Загрузка (s49060) TDO/Файлов может включать в себя получение приемником информации о TDO и файлах, ассоциированных с триггером координаты времени, или триггера исполнения из принятой TPT и загрузку TDO и файлов, указанных триггером с сервера контента.

[0874] Генерирование (s49070) RUI может включать в себя генерирование RUI для загруженных TDO и файлов.

[0875] Отправка (s49080) RUI через протокол RUI может включать в себя отправку приемником сгенерированного RUI на второй экран, используя протокол RUI.

[0876] Отображение (s49090) UI на экране, может включать в себя отображение принятого RUI на втором экране.

[0877] Щелчок (s49100) пользователя по ссылке в отношении новой страницы может включать в себя щелчок по конкретной ссылке в RUI посредством выбора пользователя на втором экране.

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

[0879] Загрузка (s49120) нового TDO/файла может включать в себя загрузку приемником TDO и файлов, ассоциированных с вводом пользователя.

[0880] Обновление (s49130) RUI может включать в себя обновление RUI в соответствии с загруженными TDO и файлами.

[0881] Отправка (s49140) RUI через протокол RUI может включать в себя передачу приемником обновленного RUI второму экрану, используя протокол RUI.

[0882] Отображение (s49150) UI на экране может включать в себя отображение обновленного RUI на втором экране.

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

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

[0885] Данный процесс может включать в себя прием (s50010) триггера для приемника, прием (s50020) триггера для услуги второго экрана, отправку (s50030) уведомления об информации обновленного UI, запрос (s50040) информации обновленного UI, передачу (s50050) информации совместимого UI в качестве ответа и прием (s50060) другого триггера для приемника.

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

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

[0888] Отправка (s50030) уведомления об информации обновленного UI может включать в себя уведомление об обновленном UI. Как описано выше, если триггер принимается во время просмотра вещательной программы, приемник может проверять, является ли триггер для устройства второго экрана или основного устройства. На этот раз, если триггер является для устройства второго экрана, все устройства UPnP или только конкретное устройство UPnP может быть уведомлено о новом обновлении информации UI. Это может соответствовать случаю, при котором устройство второго экрана подписывается, используя протокол UPnP.

[0889] Запрос (s50040) информации обновленного UI может включать в себя запрос устройством второго экрана информации обновленного UI у основного устройства.

[0890] Передача (s50050) информации совместимого UI в качестве ответа может включать в себя передачу основным устройством информации совместимого UI устройству второго экрана.

[0891] Прием (s50060) другого триггера для приемника может быть равен приему (s50010) триггера для приемника. Т.е., описанная выше операция может быть выполнена вновь.

[0892] Поскольку приемник может включать в себя модуль триггера, приемник может принимать файл XML, такой как TPT и AMT, через вещательную сеть или сеть Интернет, анализировать файл XML, и выполнять подходящую операцию. Если найдено устройство второго экрана, Action, TDO URL и Data, доставленные устройству второго экрана, могут быть распознаны, используя поле Event@Destination. Устройство второго экрана не может непосредственно принимать файл XML, такой как TPT или AMT, и, следовательно, может не включать в себя модуль триггера. Если включена Услуга Клиента RemoteUI, приемник может управлять жизненным циклом всех приложений второго экрана. В противоположность, если соединено несколько устройств второго экрана, данные для управления приложением второго экрана должны быть переданы несколько раз.

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

[0894] В отличие от Фиг. 50, Фиг. 51 показывает случай, при котором вся информация UI для устройства второго экрана, которая выявляется как подходящая для использования устройством второго экрана, доставляется непосредственным образом. Т.е., могут быть переданы TDO URL для устройства второго экрана.

[0895] Данный процесс может включать в себя прием (s51010) триггера для приемника, прием (s51020) триггера для услуги второго экрана, уведомление (s51030) об информации UI, отправка (s51040) ответа «ok», прием (s51050) триггера для приемника, прием (s51060) триггера для приемника, прием (s51070) триггера для устройства второго экрана, уведомление (s51080) об информации UI и/или отправка (s51090) ответа «ok».

[0896] Прием (s51010) триггера для приемника может быть равен приему (s50010) триггера для приемника.

[0897] Прием (s51020) триггера для услуги второго экрана может быть равен приему (s50020) триггера для услуги второго экрана.

[0898] Уведомление (s51030) об информации UI может включать в себя уведомление об обновлении информации UI.

[0899] Отправка (s51040) ответа «ok» может включать в себя передачу сообщения, указывающего на то, что уведомление UI было принято.

[0900] Прием (s51050) триггера для приемника и прием (s51060) триггера для приемника могут быть равны приему (s50010) триггера для приемника. Т.е., описанная выше операция может быть выполнена вновь.

[0901] Прием (s51070) триггера для устройства второго экрана может быть равен приему (s50020) триггера для устройства второго экрана. Т.е., описанная выше операция может быть выполнена вновь.

[0902] Уведомление (s51080) об информации UI может быть равно уведомлению (s51030) об информации UI. Т.е., описанная выше операция может быть выполнена вновь.

[0903] Отправка (s51090) ответа «ok» может быть равная отправке (s51040) ответа «ok». Т.е., описанная выше операция может быть выполнена вновь.

[0904] В способе с Фиг. 51, приемник должен знать, какое устройство UPnP является устройством второго экрана и какой включен профиль устройства. В частности, приемник должен знать, поддерживает ли устройство второго экрана услугу второго экрана.

[0905] Способ (случай с Фиг. 50) уведомления об информации UI после выявления, является ли триггер для устройства второго экрана или основного устройства, и способ (случай с Фиг. 51) доставки всей информации UI для устройства второго экрана, которая выявляется как пригодная для использования устройством второго экрана, могут быть эквивалентны в том, что приемник обрабатывает TPT и триггер и доставляет только TDO URL устройству второго экрана. Эти два способа могут отличаться в том, что приемник не на прямую доставляет TDO устройству второго экрана или приемник непосредственно записывает профиль устройства каждого устройства и уведомляет только устройство второго экрана местоположения приложения второго экрана.

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

[0907] Один вариант осуществления вещательной сигнализации для Услуги Сервера RemoteUI может включать в себя обнаружение (s52010) устройства UPnP и услуги, запрос (s52020) UIListing, отправку (s52030) UIListing, подписку (s52040) на событие, возвращение (s52050) сообщения HTTP, отправку (s52060) сообщения UIListingUpdate, запрос (s52070) UIListing и/или возвращение (s52080) UIListing.

[0908] Обнаружение (s52010) устройства UPnP и услуги может включать в себя обнаружение приемника и устройства второго экрана. Устройство вновь соединенное с домашней сетью или устройство уже соединенное с домашней сетью (приемник или устройство второго экрана) может осуществлять многоадресную передачу сообщения для обнаружения. На этот раз, может осуществляться поиск требуемой услуги, используя многоадресную передачу, и может осуществляться поиск всех услуг в отношении множества неконкретных устройств UPnP. Это может быть изменено в зависимости от того, какая услуга предоставляется устройством. На данном этапе, устройство второго экрана может быть осведомлено о профиле устройства основного устройства. Основное устройство может обрабатывать профиль устройства и строить соответствующий UIListing. Сервер RemoteUI может давать устройству второго экрана схему CompatibleUI XSD. Данная схема может включать в себя URL Приложения, уникальный id для данного UI («uiID»), имя, protocolInfo и т.д.

[0909] Запрос (s52020) UIListing может включать в себя передачу устройством второго экрана его профиля устройства и запрос UIListing. Может быть использовано действие GetCompatibleUIs, способное получить совместимый UI. (UIFilter может быть опциональным). Его подробное описание буде приведено ниже.

[0910] Отправка (s52030) UIListing может включать в себя передачу основным устройством подходящего перечня UI устройству второго экрана в соответствии с запросом. Его подробное описание будет приведено ниже.

[0911] Подписка (s52040) на событие может включать в себя подписку на правильно раскрытое Event основного устройства. Подписка (s52040) на событие может быть выборочно выполнена для того, чтобы принимать «UIListingUpdate», которая является информацией события, предоставляемой Услугой Сервера RemoteUI. При возвращении (s52080) UIListing, устройство второго экрана может быть уведомлено о том, что изменился адрес RemoteUI или изменился UI. Т.е., поскольку устройство второго экрана уведомляется только о том, что изменился UI, если требуется подробное местоположение или дополнительная информация, то для получения значения «UIListing», приемнику должно быть передано Action «GetCompatibleUIs».

[0912] Возвращение (s52050) сообщения HTTP может включать в себя отправку результата подписки (s52040) на событие. Подобно отправке (s40100) response1, в зависимости от обстоятельств может быть отправлен ответ, такой как HTTP/1.1 200 OK.

[0913] Отправка (s52060) сообщения UIListingUpdate может включать в себя передачу сообщения «UIListingUpdate» абонентам.

[0914] Запрос (s52070) UIListing может включать в себя передачу устройством второго экрана его профиля устройства и запроса UIListing. Может быть использовано действие GetCompatibleUIs, выполненное с возможностью получения UI. Отправка (s52060) сообщения UIListingUpdate и запрос (s52070) UIListing могут включать в себя выполнение установки времени таким образом, что приложение второго экрана не изменяется, и возможны только выборочно, когда поддерживаются сервером. Данный этап является опциональным. Данный способ может быть способом, на приемнике, уведомления всех устройство второго экрана о том, что присутствует услуга второго экрана, используя событие UPnP. Т.е., все вторые устройства в домашней сети могут быть уведомлены о том, что изменился UI в связи с услугой второго экрана. Если все устройства второго экрана уведомляются переменной «UIListingUpdate» при помощи события UPnP, устройства второго экрана могут подтвердить, что UI был недавно обновлен. Вследствие этого, устройство второго экрана может выполнить Action «GetCompatibleUIs», выбрать UI подходящий к аппаратному обеспечению устройства, и исполнить UI, посредством обращения к профилю устройства.

[0915] Возвращение (s52080) UIListing может включать в себя передачу основным устройством соответствующего перечня UI устройству второго экрана в соответствии с запросом. Как описано выше, возвращение (s52080) UIListing может включать в себя уведомления подписывающегося устройства второго экрана о том, что изменился адрес RemoteUI или изменился UI. Т.е., поскольку устройство второго экрана уведомляется только о том, что изменился UI, то если требуется подробное местоположение или дополнительная информация, то для получения значения «UIListing» приемнику должно быть передано Action «GetCompatibleUIs».

[0916] Когда работает Услуга Сервера RemoteUI, приемник должен предоставлять информацию удаленного UI в соответствии с профилем устройства запрашивающего устройства. С точки зрения обратной совместимости, осуществляется обмен профилем устройства «DeviceInfo» и URL, отправляемый Услугой Сервера RemoteUI, может быть изменен в соответствии с профилем запрашивающего клиента, при запросе действия «GetCompatibleUIs» у приемника позже. Если унаследованное устройство UPnP запрашивает действие «GetCompatibleUIs» у Сервера RemoteUI, должен быть предоставлен UI подходящий для DeviceInfo унаследованного устройства UPnP. Тем не менее, если действие «GetCompatibleUIs» запрашивает устройство, поддерживающее услугу второго экрана, устройство Услуги Сервера RemoteUI также должно передавать информацию URL.

[0917] Приемник может получать информацию триггера через DTVCC и получать информацию о времени мультимедиа и времени события из информации триггера. На этот раз, «appID», «URL» (TDO_URL), «eventID», «action», и, опционально, «Data» для TDO или время исполнения, могут быть подтверждены, используя синтаксис «t=media_time». Если приемник управляет жизненным циклом приложения второго экрана, может быть сокращен объем информации, который должен обрабатываться приложением услуги второго экрана. В противоположность, если непосредственно приложение услуги второго экрана управляет жизненным циклом приложения второго экрана, необходимая информация может быть увеличена.

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

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

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

[0921] В отличие от модели Централизованного Исполнения, DAE может присутствовать в каждом устройстве второго экрана.

[0922] Процесс доставки интерактивной услуги устройству второго экрана, основанный на модели Распределенного Исполнения, может быть выполнен в следующей очередности. 1. Приемник представляет сегмент с поддержкой 2-ого экрана. 2. Приемник отображает некоторое указание о том, что доступна поддержка 2-ого экрана. 3. Пользователь запускает приложение 2-ого Экрана на устройстве 2-ого экрана. Приемник и устройство 2-ого Экрана обнаруживают друг друга через механизм UPnP (выполняемый посредством машинного кода в приемнике и приложения 2-ого Экрана в устройстве). 5. Телевизор получает Trigger (из потока DTVCC или ACR) для запуска TDO и устройства 2-ого Экрана. 6. Телевизор объединяет Trigger с информацией из TPT и отправляет устройству 2-ого Экрана время активации. 7. Устройство 2-ого экрана загружает TDO (один или более файлы) и исполняет его в браузере. 8. Пользователь взаимодействует с TDO, что может предписывать TDO загрузку дополнительных файлов. 9. Приемник получает Trigger для генерирования Event для TDO на устройстве 2-ого Экрана. 10. Приемник объединяет Trigger с информацией из TPT и отправляет устройству 2-ого экрана время активации. 11. Устройство 2-ого экрана генерирует TriggerEvent (подобно DVB StreamEvent) для TDO в браузере. 12. TDO выполняет действие, запрашиваемое TriggerEvent, которое может предписывать ему загрузку файла(ов) данных.

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

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

[0925] Вариант осуществления потока для согласованной работы между приемником, основанным на модели распределенного исполнения, и вторым экраном может включать в себя отправку (s54010) триггера координаты времени, отправку (s54020) триггера координаты времени, запрос (s54030) TPT, передачу (s54040) TPT в качестве ответа, анализ (s54050) TPT, отправку (s54060) триггера исполнения для второго экрана, отправку (s54070) триггера исполнения, загрузку (s54080) TDO/Файлов, исполнение (s54090) TDO в браузере, щелчок (s54100) пользователя по ссылке в отношении новой страницы, загрузку (s54110) нового TDO/файла и/или исполнение (s54120) нового TDO в браузере.

[0926] Отправка (s54010) триггера координаты времени может быть равна отправке (s49010) триггера координаты времени.

[0927] Отправка (s54020) триггера координаты времени может включать в себя передачу приемником принятого триггера второму экрану без изменения.

[0928] Запрос (s54030) TPT может включать в себя интерпретирование вторым экраном принятого триггера, получение URL услуги, выполненной с возможностью получения TPT, и запрос TPT.

[0929] Передача (s54040) TPT в качестве ответа может включать в себя передачу TPT в ответ на запрос в запросе (s54030) TPT.

[0930] Анализ (s54050) TPT может включать в себя анализ запрошенной TPT.

[0931] Отправка (s54060) триггера исполнения для второго экрана может быть равна отправке (s49050) триггера исполнения для второго экрана.

[0932] Отправка (s54070) триггера исполнения может включать в себя передачу приемником принятого триггера второму экрану без изменения.

[0933] Загрузка (s54080) TDO/Файлов может включать в себя получение вторым экраном TDO/файлов, ассоциированных с триггером из TPT и загрузку TDO/файлов с сервера контента.

[0934] Исполнение (s54090) TDO в браузере может включать в себя исполнение загруженных TDO и файлов в браузере.

[0935] Щелчок (s54100) пользователя по ссылке в отношении новой страницы может включать в себя щелчок пользователя по конкретной ссылке в исполняемом TDO.

[0936] Загрузка (s54110) нового TDO/файла может включать в себя загрузку ассоциированного TDO/файла, если создана конкретная ссылка на другой TDO.

[0937] Исполнение (s54120) нового TDO в браузере может включать в себя исполнение ассоциированного TDO и файла в браузере.

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

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

[0940] Вариант осуществления потока для согласованной работы между приемником, основанным на модели распределенного исполнения, и вторым экраном, может включать в себя отправку (s55010) триггера координаты времени, запрос (s55020) TPT, передачу (s55030) TPT в качестве ответа, анализ (s55040) TPT, отправку (s55050) триггера исполнения для второго экрана, генерирование (s55060) расширенного триггера, отправку (s55070) расширенного триггера, загрузку (s55080) TDO/Файлов, исполнение (s55090) TDO в браузере, щелчок (s55100) пользователя по ссылке в отношении новой страницы, загрузку (s55110) нового TDO/Файлов и/или исполнение (s55120) нового TDO в браузере.

[0941] Отправка (s55010) триггера координаты времени может быть равна отправке (s54010) триггера координаты времени.

[0942] Запрос (s55020) TPT может быть равен запросу (s54030) TPT.

[0943] Передача (s55030) TPT в качестве ответа может быть равна передаче (s54040) TPT в качестве ответа.

[0944] Анализ (s55040) TPT может быть равен анализу (s54050) TPT.

[0945] Отправка (s55050) триггера исполнения для второго экрана может быть равна отправке (s54060) триггера исполнения для второго экрана.

[0946] Генерирование (s55060) расширенного триггера может включать в себя получение приемником информации о TDO и файлах, ассоциированных с триггером, из TPT и генерирование расширенного триггера, ее включающего.

[0947] Отправка (s55070) расширенного триггера может включать в себя передачу приемником сгенерированного расширенного триггера второму экрану.

[0948] Загрузка (s55080) TDO/Файлов может быть равна загрузке (s54080) TDO/Файлов.

[0949] Исполнение (s55090) TDO в браузере может быть равно исполнению (s54090) TDO в браузере.

[0950] Щелчок (s55100) пользователя по ссылке в отношении новой страницы может быть равен щелчку (s54100) пользователя по ссылке в отношении новой страницы.

[0951] Загрузка (s55110) нового TDO/Файлов может быть равна загрузке (s54110) нового TDO/Файлов.

[0952] Исполнение (s55120) нового TDO в браузере может быть равно исполнению (s54120) нового TDO в браузере.

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

[0954] Фиг. 56 показывает способ, на приемнике, приема триггера и TPT, выполнения обработки в соответствии с триггером, сравнения триггера с TPT, когда прибывает триггер для устройства второго экрана, извлечения и конфигурирования информации, которая должна быть распознана устройством второго экрана, в форме файла XML, и передачи информации устройству второго экрана. Данный способ может обладать преимуществом в том, что устройство второго экрана может активно работать и выполнять предсказание.

[0955] Процесс может включать в себя прием (s56010) триггера для приемника, прием (s56020) триггера для услуги второго экрана, перевод (s56030) TPT и триггера, и генерирование информации события, отправку (s56040) TDO и информации события, отправку (s56050) ответа «ok», прием (s56060) триггера для приемника, прием (s56070) триггера для приемника, прием (s56080) триггера для услуги второго экрана, перевод (s56090) TPT и триггера и генерирование информации события, отправку (s56100) TDO и информации события и/или отправку (s56110) ответа «ok».

[0956] Прием (s56010) триггера для приемника может быть равен приему (s50010) триггера для приемника.

[0957] Прием (s56020) триггера для услуги второго экрана может быть равен приему (s50020) триггера для услуги второго экрана.

[0958] Перевод (s56030) TPT и триггера, и генерирование информации события может включать в себя интерпретирование TPT и триггера и генерирование информации события. Сгенерированная информация может быть использована для объединения информации, включенной в TPT и триггер, для генерирования новой структуры данных и может включать в себя информацию о том, какой TDO был сгенерирован или когда TDO был сгенерирован. Данная структура данных будет описана ниже. Если принимается решение в отношении новой структуры данных, многообразие необходимой информации может быть передано в дополнение к TDO URL.

[0959] Отправка (s56040) TDO и информации события может включать в себя передачу сгенерированной информации события и TDO устройству второго экрана.

[0960] Отправка (s56050) ответа «ok» может включать в себя передачу сообщения, указывающего на то, что были приняты принятая TDO и информация события.

[0961] Прием (s56060) триггера для приемника и прием (s56070) триггера для приемника могут быть равны приему (s50010) триггера для приемника.

[0962] Прием (s56080) триггера для услуги второго экрана может быть равен приему (s50020) триггера для услуги второго экрана.

[0963] Перевод (s56090) TPT и триггера и генерирование информации события может быть равен переводу (s56030) TPT и триггера и генерированию информации события.

[0964] Отправка (s56100) TDO и информации события может быть равна отправке (s56040) TDO и информации события.

[0965] Отправка (s56110) ответа «ok» может быть равна отправке (s56050) ответа «ok».

[0966] Прием (s56060) триггера для приемника, прием (s56070) триггера для приемника, прием (s56080) триггера для услуги второго экрана, перевод (s56090) TPT и триггера и генерирование информации события, отправка (s56100) TDO и информации события и отправка (s56110) ответа «ok» могут быть равны описанным выше операциям.

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

[0968] Устройство второго экрана является независимым устройством, которое может непосредственно исполнять приложение второго экрана, если приемник принимает файл XML, такой как TPT и AMT, или знает адрес сервера TPT и AMT через сеть Интернет. В данном случае, модуль триггера включен в устройство второго экрана. Устройство второго экрана может принимать строку URI для сообщения iTV, принятого приемником. Данное сообщение применимо как к 1) способу передачи строки URI для сообщения iTV (триггер) в случае Услуги Сервера RemoteUI, так и 2) способу передачи строки URI для сообщения iTV (триггер) в случае Услуги Клиента RemoteUI.

[0969] Сначала, будет описан способ передачи строки URI для сообщения iTV (триггер) в случае Услуги Сервера RemoteUI.

[0970] Данный процесс может включать в себя прием (s57010) триггера для приемника, прием (s57020) триггера для услуги второго экрана, отправку (s57030) уведомления об информации обновленного UI, запрос (s57040) информации обновленного UI, передачу (s57050) информации UI в качестве ответа, запрос (s57060) файла XML TPT, возвращение (s57070) файла XML TPT, прием (s57080) триггера для услуги второго экрана, отправку (s57090) уведомления об информации обновленного UI, запрос (s57100) информации обновленного UI, передачу (s57110) информации UI в качестве ответа, прием (s57120) триггера для услуги второго экрана, отправку (s57130) уведомления об информации обновленного UI, запрос (s57140) информации обновленного UI, передачу (s57150) информации UI в качестве ответа, запрос (s57160) приложения второго экрана, и/или возвращение (s57170) приложения второго экрана.

[0971] Прием (s57010) триггера для приемника может быть равен приему (s50010) триггера для приемника. Поскольку первый триггер не для устройства второго экрана, приемник не доставляет триггер устройству второго экрана.

[0972] Прием (s57020) триггера для услуги второго экрана может быть равен приему (s50020) триггера для услуги второго экрана. Триггер может иметь информацию об времени мультимедиа для услуги второго экрана. Второй триггер может служить в качестве описанного выше триггера предварительной загрузки.

[0973] Отправка (s57030) уведомления об информации обновленного UI может включать в себя уведомление об информации обновленного UI. Приемник может передавать принятый URIString устройству второго экрана, так как второй триггер служит для услуги второго экрана. На этот раз, устройство второго экрана может быть проинформировано о том, что присутствует новая информация и может быть задействовано для непосредственного считывания данной информации.

[0974] Запрос (s57040) информации обновленного UI может быть равен запросу (s50040) информации Обновленного UI.

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

[0976] Запрос (s57060) файла XML TPT может включать в себя анализ устройством второго экрана информации (второго триггера), принятой от основного устройства, и запрос файла XML TPT у сервера TPT.

[0977] Возвращение (s57070) файла XML TPT может включать в себя загрузку устройством второго экрана запрашиваемого файла XML TPT с сервера TPT.

[0978] Прием (s57080) триггера для услуги второго экрана может быть равен приему (s50020) триггера для услуги второго экрана. Третий Trigger ассоциирован с устройством второго экрана и может иметь информацию, которая касается времени мультимедиа. Третий триггер является триггером координаты времени, который может выполнять точно такую же функцию, что и описанный выше триггер координаты времени.

[0979] Отправка (s57090) уведомления об информации обновленного UI может включать в себя уведомление об информации обновленного UI. Поскольку выявляется, что третий триггер ассоциирован с устройством второго экрана, приемник может уведомлять устройство второго экрана о третьем триггере.

[0980] Запрос (s57100) информации обновленного UI может быть эквивалентен запросу (s50040) информации Обновленного UI.

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

[0982] Прием (s57120) триггера для услуги второго экрана может быть равен приему (s50020) триггера для услуги второго экрана. Четвертый триггер ассоциирован с устройством второго экрана и может иметь информацию о времени события. Четвертый триггер является триггером времени события, который может выполнять точно такую же функцию, что и описанный выше триггер активации.

[0983] Отправка (s57130) уведомления об информации обновленного UI может включать в себя уведомление об обновленном UI. Поскольку выявляется, что четвертый триггер ассоциирован с устройством второго экрана, приемник может уведомлять устройство второго экрана о четвертом триггере.

[0984] Запрос (s57140) информации обновленного UI может быть равен запросу (s50040) информации обновленного UI.

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

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

[0987] Возвращение (s57170) приложения второго экрана может включать в себя загрузку приложения второго экрана в соответствии с запросом. Приложение второго экрана может быть загружено для выполнения Event@Action. На этот раз, поскольку сервер приложения информируется об информации касательно браузера устройства второго экрана, сервер приложения может легко проверить то, какое устройство второго экрана соединяется. Соответственно, приложение может быть автоматически выбрано и загружено с сервера.

[0988] Вкратце, если строка URI для сообщения iTV принимается через DTVCC, приемник может передавать, найденному устройству второго экрана, событие, указывающее на то, что был обновлен новый UI. Устройства второго экрана могут проверять информацию события и отправлять Action «GetCompatibleUIs» для того, чтобы получить новую информацию UI. Приемник может отправлять принятую информацию URI сервера TPT. Посредством данного способа, устройство второго экрана может принимать информацию URI, непосредственно обрабатывать информацию TPT и AMT, и непосредственно управлять приложением второго экрана.

[0989] Данный процесс возможен, если Клиент Trigger ATSC 2.0 включен в приложение услуги второго экрана.

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

[0991] Между описанными выше двумя способами, будет описан способ передачи строки URI для сообщения iTV (Trigger) в случае Услуги Клиента RemoteUI.

[0992] Данный процесс может включать в себя прием (s58010) триггера для приемника, прием (s58020) триггера для услуги второго экрана, уведомление (s58030) о триггере, отправку (s58040) ответа «ok», запрос (s58050) файла XML TPT, возвращение (s58060) файла XML TPT, прием (s58070) триггера для услуги второго экрана, уведомление (s58080) о триггере, отправку (s58090) ответа «ok», прием (s58100) триггера для услуги второго экрана, уведомление (s58110) о триггере, отправку (s58120) ответа «ok», запрос (s58130) приложения второго экрана и/или возвращение (s58140) приложения второго экрана.

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

[0994] Прием (s58020) триггера для услуги второго экрана может быть равен приему (s50020) триггера для услуги второго экрана. Второй триггер является триггером для услуги второго экрана и может иметь информацию о времени мультимедиа. Второй триггер может служить в качестве описанного выше триггера предварительной загрузки.

[0995] Уведомление (s58030) о триггере может включать в себя немедленную передачу приемником триггера устройству второго экрана в отличие от Фиг. 57. Если через DTVCC принимается строка URI для сообщения iTV, приемник может доставлять значение URI, принятое приемником, устройству второго экрана, используя Action «AddUIListing».

[0996] Отправка (s58040) ответа «ok» может включать в себя передачу сообщения, указывающего на то, что был принят триггер.

[0997] Запрос (s58050) файла XML TPT может быть равен запросу (s57060) файла XML TPT. Модуль триггера, включенный в устройство второго экрана, может получать доступ к серверу TPT, используя принятое значение URI, загружать файл TPT и AMT, и непосредственно управлять приложением второго экрана.

[0998] Возвращение (s58060) файла XML TPT может быть равно возвращению (s57070) файла XML TPT.

[0999] Прием (s58070) триггера для услуги второго экрана может быть равен приему (s50020) триггера для услуги второго экрана. Третий триггер ассоциирован с устройством второго экрана и может иметь информацию об времени мультимедиа. Третий триггер является триггером времени мультимедиа, который может выполнять точно такую же функцию, что и описанный выше триггер координаты времени.

[1000] Уведомление (s58080) о триггере может включать в себя доставку триггера аналогично уведомлению (s58030) о триггере.

[1001] Отправка (s58090) ответа «ok» может быть равна отправке (s58040) ответа «ok».

[1002] Прием (s58100) триггера для услуги второго экрана может быть равен приему (s50020) триггера для услуги второго экрана. Четвертый триггер ассоциирован с устройством второго экрана и может иметь информацию о времени события. Четвертый триггер является триггером времени события, который может выполнять точно такую же функцию, что и описанный выше триггер активации.

[1003] Уведомление (s58110) о триггере может включать в себя доставку триггера аналогично уведомлению (s58030) о триггере.

[1004] Отправка (s58120) ответа «ok» может быть равна отправке (s58040) ответа «ok».

[1005] Запрос (s58130) приложения второго экрана может быть равен запросу (s57160) приложения второго экрана.

[1006] Возвращение (s58140) приложения второго экрана может быть равно возвращению (s57170) приложения второго экрана.

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

[1008] Поскольку основное устройство или устройство второго экрана имеет XML TPT, AMT также может быть принята, когда триггер события принимается от сервера Live Trigger в режиме реального времени.

[1009] Описанные выше два способа могут быть по-разному выполнены в зависимости от того, какое значение URL применяется, и могут быть изменены работа приемника или структура и работа приложения услуги второго экрана.

[1010] Будут описаны механизмы сигнализации услуги второго экрана.

[1011] Услуга второго экрана может быть просигнализирована двумя способами: первым способом, на приемнике, уведомления о том, что присутствует услуга второго экрана, и вторым способом поиска устройства и услуги для того, чтобы детектировать электронное устройство для предоставления услуги второго экрана, когда устройство второго экрана соединяется с домашней сетью. В качестве альтернативы, приемник может подтверждать дескриптор устройства нового электронного устройства и запрашивать дескриптор услуги.

[1012] Далее будет описана Вещательная Сигнализация и Одноадресная Сигнализация.

[1013] В случае Вещательной Сигнализации, устройство второго экрана детектирует услугу сервера RemoteUI, подтверждает дескриптор устройства и запрашивает профиль DeviceInfo совместимый с услугой второго экрана. Может быть принято событие и может быть принят URL у TDO (интерактивное приложение), измененного в соответствии с программой, просматриваемой через приемник.

[1014] В противоположность, в случае Одноадресной Сигнализации, приемник может подтверждать, совместимо ли DeviceInfo устройства второго экрана, и передавать совместимый TDO URL. Action RemoteUIListing может быть передано для завершения исполняемого в настоящей момент приложения второго экрана с тем, чтобы поддерживать действия, такие как отображение сообщения и чтобы завершить исполняемый в настоящий момент UI. Добавочные Event@data анализируемые и обрабатываемые приемником могут быть доставлены приложению услуги второго экрана посредством Action ProccesInput.

[1015] Ниже будет описана Вещательная Сигнализация и Одноадресная Сигнализация.

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

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

[1018] Другой вариант осуществления вещательной Сигнализации для Услуги Сервера RemoteUI, может включать в себя обнаружение (s59010) устройства UPnP и услуги, отправку (s59020) UIListing, отправку (s59030) UIListing, запрос (s59040) UIListing и/или возвращение (s59050) UILIsting.

[1019] Обнаружение (s59010) устройства UPnP и услуги может быть равно обнаружению (s52010) устройства UPnP и услуги.

[1020] Отправка (s59020) UIListing может включать в себя передачу сообщения «UIListingUpdate» всем устройствам UPnP. Основное устройство может отправлять объявление UIListingUpdate Устройствам UPnP в уникальном списке «uiID». Устройство второго экрана может принимать данное сообщение и проверять uiID. Тем не менее, из-за отсутствия сопоставления с конкретным uiID, устройство второго экрана не может выполнять обновление UI.

[1021] Отправка (s59030) UIListing может включать в себя передачу сообщения «UIListingUpdate» всем устройствам UPnP. В отличие от отправки (s59020) UIListing, может присутствовать сопоставленный uiID.

[1022] Запрос (s59040) UIListing может включать в себя передачу устройством второго экрана его профиля устройства и запрос UIListing, так как сопоставленный uiID присутствует в отправке (s59030) UIListing. Может быть использовано действие GetCompatibleUIs, выполненное с возможностью получения совместимого UI.

[1023] Возвращение (s59050) UILIsting может включать в себя передачу основным устройством подходящего Перечня UI устройству второго экрана в соответствии с запросом.

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

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

[1026] Каждое устройство UPnP, соединенное с домашней сетью, которое принимает дескриптор устройства и дескриптор услуги приемника, может отправлять местоположение его дескриптора устройства, используя заголовок «LOCATION» (МЕСТОПОЛОЖЕНИЕ) в HTTP. Т.е., устройство UPnP может передавать местоположение дескриптора устройства UPnP. Если HTTP запрос GET выполнен используя «LOCATION», может быть принят файл XML, включающий в себя информацию об устройстве.

[1027] При обнаружении устройства UPnP и услуги, будет представлен способа, на основном устройстве, детектирования устройства второго экрана, выполненного с возможностью предоставления услуги второго экрана. Данный способ может быть в основном разделен на два способа. В качестве первого способа, устройство второго экрана подготавливает два профиля устройства и уведомляет о файле XML профилей устройства, используя заголовок HTTP. Предположим, что несовместимое основное устройство игнорирует непонятный заголовок HTTP. В качестве второго способа, в профиле устройства, в «Protocol Info» (Информация Протокола) может быть включена информация, называющая устройство второго экрана для предоставления услуги второго экрана.

[1028] Фиг. 60 показывает первый способ.

[1029] Один вариант осуществления обнаружения устройства и обмена возможностями устройства применительно к услуге второго экрана может включать в себя исполнение (s60001) приложения UPnP для услуги второго экрана, нахождение (s60010) устройств UPnP, нахождение (s60020) RemoteUIClient, запрос (s60030) описания устройства, прием (s60040) описания устройства, запрос (s60050) описания управления услугой, прием (s60060) описания управления услугой, запрос (s60070) профиля устройства, прием (s60080) профиля устройства, введение (s60090) URL удаленного UI, отправку (s60100) response1, отправку (s60110) сообщения Услуге Клиента RemoteUI, отправку (s60120) response2 и/или щелчок (s60130) пользователя по кнопке на экране.

[1030] Исполнение (s60001) приложения UPnP для услуги второго экрана, нахождение (s60010) устройств UPnP, нахождение (s60020) RemoteUIClient, запрос (s60030) описания устройства, прием (s60040) описания устройства, запрос (s60050) описания управления услугой, прием (s60060) описания управления услугой, запрос (s60070) профиля устройства, прием (s60080) профиля устройства, введение (s60090) URL удаленного UI, отправка (s60100) response1, отправка (s60110) сообщения Услуге Клиента RemoteUI, отправка (s60120) response2 и щелчок (s60130) пользователя по кнопке на экране могут быть равны исполнению (s40001) приложения UPnP для услуги второго экрана, нахождению (s40010) устройств UPnP, нахождению (s40020) RemoteUIClient, запросу (s40030) описания устройства, приему (s40040) описания устройства, запросу (s40050) описания управления услугой, приему (s40060) описания управления услугой, запросу (s40070) профиля устройства, приему (s40080) профиля устройства, введению (s40090) URL удаленного UI, отправке (s40100) response1, отправке (s40110) сообщения Услуге Клиента RemoteUI, отправке (s40120) response2 и щелчку (s40130) пользователя по кнопке на экране, соответственно.

[1031] В первом способе, как показано на Фиг. 60, после нахождения (s60010) устройств UPnP, может быть выполнено уведомление о местоположении профиля устройства, поддерживающего услугу второго экрана, используя «X-ATSC-COMPANION-LOCATION», полученное из Заголовка HTTP. Часть, представленная X-ATSC-COMPANION-LOCATION: http://10.177.56.36:37900/ATSC2ndScreenRemoteUIClientl.xml\r\n является «X-ATSC-COMPANION-LOCATION». Приемник может игнорировать заголовок «LOCATION» и вместо этого получать профиль устройства устройства второго экрана, которое требуется приемнику.

[1032] Из числа методов, посредством которых основное устройство детектирует устройство второго экрана, выполненное с возможностью предоставления услуги второго экрана, в описанном выше втором способе, профиль устройства может быть получен в местоположении заголовка «LOCATION» и значение «Protocol Info» устройства второго экрана может быть проанализировано и обработано в профиле устройства. Это может быть выполнено при запросе (s52020) UIListing варианта осуществления вещательной сигнализации для Услуги #1 Сервера RemoteUI.

[1033] В дескрипторе устройства конкретного устройства UPnP, присутствует список предоставляемых услуг и может быть предоставлена одна или множество услуг. Управление каждой услугой устройства UPnP может осуществляться посредством другого удаленного устройства UPnP и может быть принято событие. Событие может быть принято только при уведомлении о предоставляемой услуге, используя событие. Существует возможность уведомления о URL таким образом, что осуществляется управление услугами, предоставляемыми устройством UPnP, и генерируется событие.

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

[1035] В варианте осуществления вещательной сигнализации для Услуги #1 Сервера RemoteUI, дополнительно будет описан запрос (s52020) UIListing. Данный этап может включать в себя этап, на котором устройство второго экрана спрашивает приемник, имеющий услугу сервера RemoteUI, присутствует ли подходящий UI для устройства второго экрана. «InputDeviceProfile» должен быть в формате файла XSD, показанном на Фиг. 61.

[1036] Соответственно, устройство второго экрана должно передавать информацию о его профиле устройства приемнику в формате Фиг. 61.

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

[1038] В варианте осуществления вещательной сигнализации Услуги #1 Сервера RemoteUI, дополнительно будет описан запрос (s52020) UIListing. Фиг. 62 показывает пример профиля устройства. При запросе (s52020) UIListing, приемнику может быть отправлена информация, такая как показанный профиль устройства.

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

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

[1041] В варианте осуществления вещательной сигнализации Услуги #1 Сервера RemoteUI, дополнительно будут описаны запрос (s52020) UIListing и Отправка (s52030) UIListing.

[1042] Как описано выше, приемник может подтверждать информацию «InputDeviceProfile» с тем, чтобы определять тип услуги, который должен быть предоставлен, версию, разрешение устройства второго экрана, приемлемый способ кодирования изображения, и т.д. Один вариант осуществления «Описания ProtocolInfo для Услуги Второго Экрана» может быть одним вариантом осуществления информации «InputDeviceProfile».

[1043] Когда показанная информация доставляется приемнику (запрос (s52020) UIListing), информация UIListing в XML передается устройству второго экрана (отправка (s52030) UIListing).

[1044] Если услуга сервера RemoteUI не поддерживает требуемое устройство второго экрана, при отправке (s52030) UIListing, может быть возвращена информация ошибки для указания того, что услуга сервера RemoteUI не может поддерживать услугу второго экрана.

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

[1046] В варианте осуществления вещательной сигнализации для Услуги #1 Сервера RemoteUI, будут дополнительно описаны запрос (s52020) UIListing и Отправка (s52030) UIListing.

[1047] После запроса (s52020) UIListing, приемник может детектировать и доставлять информацию совместимого RemoteUI запрашивающему устройству второго экрана (отправка (s52030) UIListing). Информация, принимаемая при отправке (s52030) UIListing, показана на Фиг. 64.

[1048] Когда принятая информация может быть передана от приемника к второму экрану, TPT и AMT могут быть обработаны для вставки TDO URL. Соответственно, устройство второго экрана может получать только информацию об удаленном UI от приемника и приложение второго экрана может быть загружено и исполнено из сервера приложения Интернет вне домашней сети. На этот раз, приложение может быть исполнено приложением услуги второго экрана.

[1049] Вещательная компания может передавать приложение второго экрана для устройства второго экрана приемнику через вещательную сеть. В данном случае, приемник может сохранять приложение для услуги второго экрана и непосредственно предоставлять приложение. В данном случае, web-сервер может работать в приемнике, а ассоциированное изображение и данные могут быть загружены с внешнего сервера приложений вместо приемника или домашней сети. Если DO является NDO, NDO и ассоциированные файлы ресурсов могут быть переданы через вещательную сеть в ATSC-NRT и может быть предоставлена услуга второго экрана.

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

[1051] Во-первых, будет описан способ, на приемнике, управления жизненным циклом приложения второго экрана.

[1052] Приемник может обрабатывать информацию о триггере времени мультимедиа, передаваемом при помощи DTVCC, и затем немедленно уведомлять все устройства в домашней сети о переменной «UIListingUpdate», когда присутствует событие, ассоциированное со вторым экраном и данное событие исполняется. Устройства, которые подписаны на событие, могут проверять, что информация UI была обновлена, и выполнять действие «GetCompatibleUIs» для того, чтобы получить необходимую информацию. На этот раз, сервер RemoteUI приемника может немедленно доставлять адрес TDO.

[1053] Во-вторых, будет описан способ, в приложении услуги второго экрана, управления жизненным циклом приложения второго экрана.

[1054] В данном случае, приемник может доставлять принятую информацию устройству второго экрана и может быть исполнено приложение услуги второго экрана. В случае вещательной передачи, если клиент для услуги второго экрана запрашивает действие «GetCompatibleUIs», приемник может непосредственно возвращать URIString сообщения iTV (Trigger), принятое через DTVCC, и устройство второго экрана может загружать файл TPT, используя принятую URIString и интерпретировать TPT для работы подобно приемнику. Приемник может немедленно изменять переменную «UIListingUpdate» и передавать измененную переменную всем устройствам всякий раз, когда при помощи DTVCC принимается триггер времени мультимедиа или триггер времени события, так что устройства выполняют действие «GetCompatibleUIs» с тем, чтобы принять новую URIString сообщения iTV (Trigger).

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

[1056] Будет описана одноадресная сигнализация.

[1057] В данном способе, услуга RemoteUIClient включена в устройство второго экрана. Если устройство UPnP впервые соединяется с домашней сетью, устройство UPnP уведомляет другие устройства о том, что новое устройство было соединено с домашней сетью. В качестве другого способа, если сообщение, запрашивающее периодическое уведомление о новом устройстве, доставляется всем устройствам, соединенным с домашней сетью, все устройства, соединенные с домашней сетью могут отправлять сообщение NOTIFY всем устройствам в ответ на данную информацию. Сначала должно быть выявлено, поддерживает ли устройство второго экрана услугу второго экрана.

[1058] Вариант осуществления одноадресной Сигнализации услуги клиента RemoteUI может вкачать в себя обнаружение (s65010) устройства UPnP и услуги, запрос (s65020) профиля устройства, возвращение (s65030) профиля устройства, отправку (s65040) информации TDO URL, возвращение (s65050) сообщения HTTP, отправку (s65060) сообщения отображения и/или возвращение (s65070) сообщения HTTP.

[1059] Обнаружение (s65010) устройства UPnP и услуги может быть равно обнаружению (s52010) устройства UPnP и услуги.

[1060] Запрос (s65020) профиля устройства может включать в себя передачу приемником информации «StaticDeviceInfo» вновь детектированному устройству второго экрана для того, чтобы выявить, поддерживает ли устройство второго экрана услугу второго экрана.

[1061] Возвращение (s65030) профиля устройства является ответом на запрос (s65020) профиля устройства, который получает профиль устройства устройства второго экрана. Если выявляется, что профиль устройства, отправленный вновь детектированным устройством второго экрана, не сопоставлен с «StaticDeviceInfo» или вновь детектированное устройство второго экрана не поддерживает услугу второго экрана, услуга второго экрана может не запускаться. «StaticDeviceInfo» может быть равна определенной выше «DeviceInfo». Приемник может выявлять, сопоставлен ли «StaticDeviceInfo» с DeviceInfo. Если количество вновь детектированных в домашней сети устройств второго экрана равно одному или более, данный процесс повторяется. Даже когда детектированное устройство второго экрана не поддерживает услугу второго экрана, данный процесс выполняется непрерывно. Один или более фрагменты программного обеспечения могут быть инсталлированы в или удалены из устройства второго экрана и значение результата данного процесса может быть изменено в зависимости от того, исполняет ли пользователь программное обеспечение. Если выполняется приложение услуги второго экрана, может быть выполнена отправка (s65040) информации TDO URL.

[1062] Отправка (s65040) информации TDO URL может включать в себя передачу приемником информации TDO URL, которая является результатом анализа TPT и AMT. Может быть использовано «AddUIString», определенное в услуге клиента RemoteUI UPnP. «AddUIString» может быть действием, которое исполняется, если устройство второго экрана удовлетворяет DeviceInfo услуги второго экрана. TDO URL может включать в себя один или более URL. В случае одного или более URL, может быть переда URL для немедленного исполнения. На этот раз, выборочно может быть выполнена отправка (s65060) сообщения отображения.

[1063] Возвращение (s65050) сообщения HTTP может включать в себя отправку результата отправки (s65040) информации TDO URL. Подобно отправке (s40100) response1, в зависимости от обстоятельств может быть отправлен ответ, такой как HTTP/1.1 200 OK.

[1064] Отправка (s65060) сообщения отображения может включать в себя передачу сообщения отображения устройству второго экрана. Поскольку услуга клиента RemoteUI имеет Action DisplayMessage выполненное с возможностью отображения сообщения на экране устройства второго экрана, TDO URL может быть передан устройству второго экрана и сообщение, указывающее на то, что присутствует приложение второго экрана, ассоциированное с просматриваемой в настоящий момент вещательной программой, может быть отображено, используя Action DisplayMessage. Если пользователь подтверждает данное сообщение, немедленно может быть исполнено приложение второго экрана.

[1065] Возвращение (s65070) сообщения HTTP может включать в себя передачу результата отправки (s65060) сообщения отображения. Подобно отправке (s40100) response1, в зависимости от обстоятельств может быть отправлен ответ, такой как HTTP/1.1 200 OK.

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

[1067] Всякий раз, когда в UIListing устройства второго экрана добавляется URL нового UI, приложение услуги второго экрана может предоставлять среду, в которой исполняется новое приложение второго экрана.

[1068] Один вариант осуществления одноадресной Сигнализации для услуги клиента RemoteUI с Фиг. 66 показывает процесс завершения исполняемого приложения второго экрана и исполнение нового приложения второго экрана.

[1069] Один вариант осуществления одноадресной Сигнализации для услуги клиента Remote UI может включать в себя отправку (s66010) действия RemoveUIListing, возвращение (s66020) сообщения HTTP, отправку (s66030) сообщения отображения, возвращение (s66040) сообщения HTTP, отправку (s66050) информации TDO URL, возвращение (s66060) сообщения HTTP, отправку (s66070) сообщения отображения и/или возвращение (s66080) сообщения HTTP.

[1070] Отправка (s66010) действия RemoveUIListing может включать в себя завершение приложения второго экрана, которое исполнялось в приложении услуги второго экрана, используя действие «RemoveUIListing», определенное в услуге клиента RemoteUI. Приложение услуги второго экрана может быть осведомлено о том, что отправлено действие RemoveUIListing, когда приемник завершает использование исполняемого в настоящий момент приложения UI. Соответственно, приложение услуги второго экрана должно немедленно завершать исполняемое в настоящий момент приложение второго экрана, если устройство второго экрана принимает действие RemoveUIListing.

[1071] Возвращение (s66020) сообщения HTTP может включать в себя отправку результата отправки (s66010) действия RemoveUIListing. Подобно отправке (s40100) response1, в зависимости от обстоятельств может быть отправлен ответ, такой как HTTP/1.1 200 OK.

[1072] Отправка (s66030) сообщения отображения может включать в себя отправку сообщения отображения устройству второго экрана. После отправки (s66010) действия RemoveUIListing, сообщение, указывающее завершение исполнения, может быть отображено на экране устройства второго экрана. В данном случае, подходящее сообщение может быть отображено на экране, используя Action DisplayMessage.

[1073] Возвращение (s66040) сообщения HTTP может включать в себя отправку результата отправки (s66030) сообщения отображения. Подобно отправке (s40100) response1, в зависимости от обстоятельств может быть отправлен ответ, такой как HTTP/1.1 200 OK.

[1074] Отправка (s66050) информации TDO URL может включать в себя выполнение действия AddUIListing таким образом, что приемник передает TDO URL UI, который должен быть вновь выполнен. Когда исполняется новое приложение второго экрана, приложение услуги второго экрана может быть исполнено как только TDO URL добавляется в UIListing. Для ссылки, TDO URL относится к приложению второго экрана, которое может быть непосредственно загружено и исполнено с приемника или лишь некоторые данные ресурса могут быть загружены с Интернет сервера. В дополнение, TDO URL может указывать адрес внешнего Интернет сервера. Если TDO URL указывает адрес внешнего Интернет сервера, приложение второго экрана и все данные, необходимые для исполнения, могут быть загружены с Интернет сервера.

[1075] Возвращение (s66060) сообщения HTTP может включать в себя отправку результата отправки (s66050) информации TDO URL. Подобно отправке (s40100) response1, в зависимости от обстоятельств может быть отправлен ответ, такой как HTTP/1.1 200 OK.

[1076] Отправка (s66070) сообщения отображения может включать в себя отправку сообщения отображения устройству второго экрана. После отправки (s66050) информации TDO URL, сообщение, указывающее на то, что предоставляется новая услуга второго экрана, может быть отображено на экране устройства второго экрана. Подобно отправке (s66030) сообщения отображения, подходящее сообщение может быть отображено на экране, используя Action DisplayMessage.

[1077] Возвращение (s66080) сообщения HTTP может включать в себя отправку результата отправки (s66070) сообщения отображения. Подобно отправке (s40100) response1, в зависимости от обстоятельств может быть отправлен ответ, такой как HTTP/1.1 200 OK.

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

[1079] Во-первых, будет описан способ, на приемнике, управления жизненным циклом приложения второго экрана.

[1080] Приложение услуги второго экрана может быть осведомлено только об информации «URL» (TDO_URL). Соответственно, приемник может выполнять действие «AddUIListing» в отношении услуги клиента RemoteUI в устройстве второго экрана и исполнять приложение второго экрана на устройстве второго экрана в предварительно определенное время. Если приложение второго экрана завершается, действие «RemoveUIListing» может быть выполнено для завершения приложения второго экрана в предварительно определенное время.

[1081] Если информация времени мультимедиа для выполнения TDO предоставляется в дополнение к URL в отношении подробного распределения во времени, приложение услуги второго экрана может быть исполнено в предварительно определенное время. Тем не менее, поскольку время мультимедиа является относительным временем мультимедиа, которое в настоящий момент воспроизводится приемником, требуется, чтобы данное время было изменено на абсолютное время, понятное каждому устройству. Протокол сетевого времени (NTP) или другая информация времени может быть использована и время, когда выполняется действие, может быть получено посредством сложения времени мультимедиа, обладающего будущей информацией времени, с NTP или другой информацией времени. В устройстве второго экрана, поскольку действие включает в себя исполнение и завершение, это может быть изменено в соответствии с реализацией действия AddUIListing и RemoveUIListing.

[1082] Во-вторых, будет описан способ, в приложении услуги второго экрана, управления жизненным циклом приложения второго экрана.

[1083] Приложение услуги второго экрана должно быть осведомлено об информации, которая касается события или времени, когда приложение второго экрана исполняется и завершается в устройстве второго экрана. Вследствие этого, как описано выше, приложение услуги второго экрана включает клиента триггера и приемник может передавать URIString информации сообщения iTV (Trigger), используя DTVCC в соответствии с DeviceInfo (Профиль Устройства) приемника.

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

[1085] Во-первых, будет описан способ, на приемнике, доставки триггера устройству второго экрана без изменения.

[1086] Способ может быть обработан посредством выполнения действия «AddUIListing» в отношении принятого триггера. Услуга Клиента RemoteUI может доставлять данную информацию клиенту триггера и клиент триггера может загружать и обрабатывать TPT как в приемнике. Приемник должен доставлять триггер времени мультимедиа устройству второго экрана всякий раз, когда триггер времени мультимедиа принимается при помощи DTVCC. Приемник может подтверждать «appID», «eventID» и «event@destination» и может не доставлять триггер устройству второго экрана, если устройству второго экрана не требуется принимать триггер.

[1087] Во-вторых, будет описан способ, на приемнике, фильтрации и доставки информации триггера, необходимой устройству второго экрана.

[1088] В данном способе, приемник может обрабатывать файл TPT и триггер и генерировать и доставлять данные, которые должны быть обработаны устройством второго экрана. Данный способ может быть выполнен даже когда клиент триггера не работает в приложении услуги второго экрана и файл XML может быть передан и обработан через действие «ProgressInput». Т.е., приложение услуги второго экрана не обрабатывает всю TPT, а обрабатывает только данные, необходимые для текущей или будущей обработки, которые фильтруются приемником. Данный способ имеет преимущество, которое состоит в том, что также может быть доставлено поле «Event@Data».

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

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

[1091] Один вариант осуществления одноадресной сигнализации для услуги клиента RemoteUI может включать в себя отправку (s67010) информации события 1, возвращение (s67020) сообщения HTTP, отправку (s67030) информации события 2, возвращение (s67040) сообщения HTTP, отправку (s67050) информации события 3 и/или возвращение (s67060) сообщения HTTP.

[1092] Отправка (s67010) информации события 1 может включать в себя отправку приемником принятой информации события второму экрану. Как описано выше, приемник может обрабатывать файл TPT и триггер и генерировать и доставлять данные, которые должны быть обработаны устройством второго экрана. В приложении услуги второго экрана, клиент триггера может не работать и файл XML может быть принят и обработан через действие «ProgressInput».

[1093] Возвращение (s67020) сообщения HTTP может включать в себя отправку результата отправки (s67010) информации события 1. Подобно отправке (s40100) response1, в зависимости от обстоятельств может быть отправлен ответ, такой как HTTP/1.1 200 OK.

[1094] Отправка (s67030) информации события 2 может включать в себя отправку информации о событии подобно отправке (s67010) информации события 1. Как в TPT XML, данные могут быть доставлены TDO в соответствии с событием. На данном этапе, может быть доставлена информация о событии 2.

[1095] Возвращение (s67040) сообщения HTTP может включать в себя отправку результата отправки (s67030) информации события 2. Подобно отправке (s40100) response1, в зависимости от обстоятельств может быть отправлен ответ, такой как HTTP/1.1 200 OK.

[1096] Аналогичным образом, отправка (s67050) информации события 3 может включать в себя отправку информации о событии 3.

[1097] Возвращение (s67060) сообщения HTTP может включать в себя отправку результата отправки (s67050) информации события 3. Подобно отправке (s40100) response1, в зависимости от обстоятельств может быть отправлен ответ, такой как HTTP/1.1 200 OK.

[1098] В описанном выше втором способе, приемник может управлять жизненным циклом приложения второго экрана. Жизненный цикл приложения второго экрана может означать процесс анализа и обработки информации TPT и AMT устройства второго экрана.

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

[1100] Фиг. 68 показывает пример структуры данных XML информации события, когда приемник обрабатывает файл TPT и триггер и генерирует и доставляет данные, которые должны быть обработаны устройством второго экрана в описанном выше способе, в приемнике, фильтрации и доставки информации триггера, необходимой для устройства второго экрана.

[1101] Т.е., если приемник управляет жизненным циклом приложения второго экрана, информация события может быть доставлена клиенту RemoteUI через файл XML со структурой данных Фиг. 68, используя действие ProgressInput. Даже когда приемник принимает триггер прямого эфира, подобным образом, триггер прямого эфира может быть обработан и устройству второго экрана может быть доставлена только информация о времени исполнения и TDO URL.

[1102] В таблице на Фиг. 68, @appID, URL, Event, @eventID, @action и Data могут быть равны информации о триггере или AMT, принятой приемником. Тем не менее, «@mediaTime», «@startTime» и «@endTime» должны быть особым образом обработаны приемником. В соответствии с «@mediaTime», информация синтаксиса «time=» (или информация «@beginMT» в AMT) триггера, переданного используя DTVCC, может быть обработана для выявления «@startTime» и «@endTime» вновь. Поскольку приемник и устройство второго экрана могут не использовать одинаковую информацию абсолютного времени (время настенных часов (wall clock time)), устройство второго экрана может работать в соответствии со временем мультимедиа контента. Т.е., если предполагается, что информация времени, такая как время начала и время конца исполнения действия устанавливаются между приемником и устройством второго экрана в соответствии с фактическим NTP, операция преобразования может быть выполнена приемником перед передачей.

[1103] Будут описаны задержка передачи и оценка времени мультимедиа

[1104] Как описано выше, поскольку @startTime и @endTime являются установленными относительно и передаются на основании значения mediaTime, при передаче от приемника к устройству второго экрана, потеря времени, генерируемая при передаче, может быть значением «Date» заголовка HTTP и HTTP ответа. Используя разность в значении времени прибытия, устройство второго экрана может находить более точное значение времени. Поскольку разность между текущим временем мультимедиа и @mediaTime является временем задержки передачи, текущее время мультимедиа может быть получено посредством следующего уравнения.

[1105] текущее время мультимедиа = время задержки передачи (значение времени по приему - значение «Date» заголовка HTTP) + @mediaTime.

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

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

[1108] Показана конфигурация между приемником и устройством второго экрана. Приемник может быть Управляемым Устройством (Сервером). Устройство второго Экрана может быть Точкой Управления (Клиентом).

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

[1110] На этапе описания, приложение второго экрана может запрашивать описание услуги приемника.

[1111] В настоящем изобретении, новое устройство UPnP и услуга могут быть определены для того, чтобы, через устройство второго экрана, получать интерактивную услугу, ассоциированную с A/V вещательным контентом, принимаемым через телевизор, т.е., приемник, на основании UPnP.

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

[1113] Приемник может поддерживать услугу Trigger, услугу Двусторонней Связи, и услугу AppURL. Он также может поддерживать услугу Прокси-Сервера HTTP. Типы Услуг и ID услуг показаны на Фиг. 70.

[1114] Услуга двусторонней связи может позволять устройствам второго экрана выявлять, присутствует ли DO, исполняемый основным устройством, который готов участвовать в двусторонней связи с приложениями в устройствах второго экрана.

[1115] Услуга Trigger, услуга AppURL и услуга Прокси-Сервера HTTP будут описаны ниже.

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

[1117] Услуга доставки триггера может означать услугу для, через устройство второго экрана, получения интерактивной услуги, ассоциированной с A/V вещательным контентом, принимаемым через TV приемник, основанный на UPnP.

[1118] Фиг. 71 показывает процесс, на приемнике, получения триггера от DTVCC или сервера ACR и передачи триггера устройству второго экрана без изменения или в состоянии изменения (расширения) триггера до формата, пригодного для устройства второго экрана.

[1119] Всякий раз, когда триггер изменяется, триггер или расширенный триггер должен быть передан от приемника устройству второго экрана в режиме реального времени.

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

[1121] Расширенный триггер (расширенный триггер активации) может быть сгенерирован посредством объединения триггера, полученного из потока DTVCC или Сервера ACR, и информации в TPT. Расширенный триггер может быть сгенерирован посредством объединения TDO ID и Event ID, и времени Activation, включенных в триггер, и TDO URL, атрибутов TDO, Event, Action, Diffusion и данных в TPT. Информация в TDO может быть информацией о TDO и событии, ассоциированном с информацией в триггере.

[1122] Здесь, расширенный триггер может именоваться дополненным триггером.

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

[1124] Будет описана спецификация Услуги Trigger.

[1125] Услуга Trigger может доставлять Trigger. Trigger может быть получен телевизором из (a) процесса ACR, (b) услуги #6 DTV CC просматриваемого в настоящий момент канала, (c) Удаленного сервера «триггера прямого эфира» или (d) Таблицы Сообщений Активации (AMT). Это может зависеть от обстоятельств.

[1126] Услуга Trigger также может доставлять особый Trigger «изменения канала» всякий раз, когда изменяется канал. Триггер изменения канала будет описан ниже. По существу, может существовать четыре типа Trigger, которые должны быть доставлены, 1) Time Base Trigger для модели интерактивной услуги TDO, 2) Activation Trigger для модели интерактивной услуги TDO, 3) Trigger для модели интерактивной услуги Непосредственного Исполнения и 4) Особые Trigger «изменения канала».

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

[1128] Тем не менее, для приложений второго экрана, которые разработаны для обеспечения взаимодействия по большей части способом аналогичным тому, которым обеспечивает взаимодействие приемник, желательно опустить Time Base Trigger для модели взаимодействия TDO и доставлять каждый Activation Trigger для модели взаимодействия TDO в его время активации. Это может уберечь приложения второго экрана от необходимости поддержания координат времени и вычисления времен активации. Также может быть желательным дополнять каждый Activation Trigger посредством объединения информации из Trigger с информацией из TPT об элементе TDO и элементе-потомке Event, на который ссылаются в Trigger, тем самым уберегая эти приложения второго экрана от необходимости иметь дело с TPT.

[1129] Вследствие этого, услуга Trigger может предлагать две опции доставки Trigger. Одна из них может быть опцией «Нефильтрованного потока», при которой приемник доставляет все Trigger (без дополнения). А другой может быть опция «Фильтрованного потока», при которой доставляются только Дополненные Activation Trigger для модели взаимодействия TDO, Все триггеры для моделей взаимодействия отличной от модели взаимодействия TDO, и Особые Trigger изменения канала.

[1130] Целевым временем доставки для каждого Дополненного Activation Trigger для модели взаимодействия TDO может быть его время активации. Целевым временем доставки для всех других Trigger (включая Activation Trigger доставляемые без дополнения в опции нефильтрованного потока) может быть время, когда они принимаются Приемником. Целевым временем доставки каждого особого Trigger изменения канала может быть время изменения канала.

[1131] Формат доставки триггера услуги триггера может быть разделен на формат доставки для Дополненного Activation Trigger и формат доставки для всех других Trigger.

[1132] Фиг. 73 показывает формат доставки для Дополненного Activation Trigger. Формат доставки для всех других Trigger будет описан ниже.

[1133] Формат доставки для Дополненного Activation Trigger может включать в себя атрибуты @interactionModel, @appURL, и/или @cookieSpace и элемент Capabilities и/или Event.

[1134] Элемент Event может включать в себя атрибуты @action, @destination, @diffusion и/или @data.

[1135] Семантика полей следующая.

[1136] Значение атрибута @interactionModel может быть числовым кодом для модели взаимодействия, ассоциированной с Trigger, используя некоторое кодирование, как для поля cmdID в команде SDOPrivatData в Услуге #6 канала DTVCC, используемой для доставки Trigger.

[1137] Значение атрибута @appURL может быть значением первого элемента-потомка URL элемента TDO TPT, который определяется посредством терма («e=») события в Trigger.

[1138] Атрибут @cookieSpace может присутствовать всякий раз, когда элемент TDO TPT, который идентифицируется термом («e=») события в Trigger, содержит атрибут @cookieSpace, и он может иметь точно такое же значение, как и тот атрибут.

[1139] Элемент Capabilities может присутствовать всякий раз, когда элемент TDO TPT, который идентифицируется термом («e=») события в Trigger, содержит элемент Capabilities и он может быть идентичен тому элементу.

[1140] Элемент Event может представлять собой элемент Event, идентифицируемый термом («e=») события в Trigger. (Строго говоря, терм события в Trigger идентифицирует элемент TDO в TPT и элемент-потомок Event этого элемента TDO. Это именуется здесь как элемент Event идентифицируемый термом события в Trigger).

[1141] Значение атрибута @action может быть точно таким же, как значение атрибута action элемента Event, идентифицируемого термом («e=») события в Trigger.

[1142] @destination может присутствовать всякий раз, когда элемент Event, который идентифицируется термом («e=») события в Trigger, содержит атрибут destination, и он может иметь точно такое же значение, как и тот атрибут.

[1143] Атрибут @diffusion может присутствовать всякий раз, когда элемент Event, который идентифицируется термом («e=») события в Trigger, содержит атрибут diffusion, и он может иметь точно такое же значение, как и тот атрибут.

[1144] Атрибут @data может присутствовать всякий раз когда элемент-потомок Data элемента Event идентифицируется термом («e=») события в Trigger, и он может иметь точно такое же значение, как и тот элемент.

[1145] Как описано выше, дополненный триггер может быть сгенерирован посредством объединения информации в TPT и триггере, полученном из потока DTVCC или от Сервера ACR.

[1146] Как описано выше, расширенный триггер также может именоваться дополненным триггером.

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

[1148] Это может быть форматом XML триггера, который не дополнен. Описанный выше особый Trigger «изменения канала» также может следовать данному формату.

[1149] Один вариант осуществления Описания Схемы XML для Trigger, которые не дополнены, может включать в себя атрибут @interactionModel и/или атрибуты @triggerString.

[1150] Семантика полей следующая.

[1151] Атрибут @interactionModel не может присутствовать для особого триггера «изменения канала». Для других Trigger, interactionModel может присутствовать, и его значение может быть числовым кодом для модели взаимодействия, связанной с Trigger, используя точно такое же кодирование, как для поля cmdID в команде SDOPrivateData в канале DTVCC. @interactionModel для Trigger, полученного от сервера триггера прямого эфира или извлеченного из AMT может считаться моделью TDO.

[1152] Значением атрибута @triggerString может быть строковое представление Trigger. Строковое представление Trigger было описано в синтаксисе триггера. Тем не менее, особый триггер «изменения канала» может отличаться. Атрибут @triggerString для особого триггера «изменения канала» может иметь значение «**<major_num>.<minor_num>», где <major_num> может быть исходным основным номером канала нового канала (как он вещался TV станцией), а <minor_num> может быть исходным дополнительным номером канала нового канала (как он вещался TV станцией). Если номер канала неизвестен, тогда оба значения <major_num> и <minor_num> могут быть «0».

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

[1154] Это может быть другим вариантом осуществления формата описанного выше дополненного триггера.

[1155] @cookieSpace, Capabilities, Event, @action, @destination, @diffusion и @data были описаны выше.

[1156] @activationTime может быть временем активации, по шкале времени мультимедиа.

[1157] @tdoURL может быть равен описанному выше @appURL.

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

[1159] Это может быть другим вариантом осуществления формата описанного выше дополненного триггера.

[1160] @activationTime, @tdoURL, @cookieSpace, Capabilities, Event, @action, @destination, @diffusion и @data были описаны выше.

[1161] @availInternet и @availBroadcast могут быть из TPT. @availInternet и @availBroadcast были описаны выше.

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

[1163] Это может быть другим вариантом осуществления формата описанного выше дополненного триггера.

[1164] @activationTime, @tdoURL, @cookieSpace, Capabilities, Event, @action, @destination, @diffusion и @data были описаны выше.

[1165] Элемент ContentItem, атрибуты @updatesAvail, @pollPeriod, @size, @availInternet, и @availBroadcast могут быть равны элементам и атрибутам TPT, при генерировании дополненного триггера. Элемент ContentItem, @updatesAvail, @pollPeriod, @size, @availInternet, и @availBroadcast были описаны выше.

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

[1167] Это может быть другим вариантом осуществления формата описанного выше дополненного триггера.

[1168] @cookieSpace, @availInternet, @availBroadcast, Capabilities, ContentItem, @updatesAvail, @pollPeriod, @size, @availInternet, @availBroadcast, Event, @action, @destination и @data были описаны выше.

[1169] @appID, @appType, @appName, @globalId, @appVersion, @frequencyOfUse, @expireDate, @testTDO, URTL в элементе TDO и URL в элементе ContentItem могут быть равны элементам и атрибутам TPT при генерировании дополненного триггера. @appID, @appType, @appName, @globalId, @appVersion, @frequencyOfUse, @expireDate, @testTDO, URL в элементе TDO и URL в элементе ContentItem будут описаны ниже.

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

[1171] Один вариант осуществления переменных состояния услуги триггера может определять показанные переменные состояния услуги триггера. Услуга Trigger может иметь переменные состояния, перечисленные на Фиг. 79.

[1172] Значение переменной LatestUnfilteredTrigger состояния может представлять собой Trigger в нефильтрованном потоке с самым последним целевым временем доставки. Формат данной переменной состояния может быть документом XML, согласующимся со схемой, описанной на Фиг. 74.

[1173] Значение переменной LatestFilteredTrigger состояния может представлять собой Trigger в фильтрованном потоке с самым последним целевым временем доставки. Когда он является Activation Trigger, он может быть дополнен посредством объединения информации в Activation Trigger с информацией в TPT для создания документа XML, согласующегося со схемой XML, представленной Таблицей, описанной на Фиг. 73. Когда он является Trigger с моделью взаимодействия отличной от TDO, он может иметь формат документа XML, согласующегося со схемой, описанной на Фиг. 74. Когда он является особым Trigger изменения канала, форматом может быть «**<major_num>.<minor_num>», как описано до этого.

[1174] Значение переменной UnfilteredTriggerDeliveryTime состояния может быть временем доставки Trigger в нефильтрованном потоке с самым последним целевым временем доставки.

[1175] Значение переменной FilteredTriggerDeliveryTime состояния может быть временем доставки Trigger в фильтрованном потоке с самым последним целевым временем доставки.

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

[1177] Другой вариант осуществления переменных состояния услуги триггера может иметь точно такие же переменные состояния, как на Фиг. 80.

[1178] Значение переменной CurrentTrigger состояния может зависеть от того, какая из следующих трех ситуаций имеет силу. 1) Отсутствует интерактивная вспомогательная услуга данных, ассоциированная с программами вещания, которые в настоящее время просматриваются на основном экране. 2) Присутствует интерактивная вспомогательная услуга данных, ассоциированная с программами вещания, которые в настоящее время просматриваются на основном экране, и она имеет модель взаимодействия Непосредственного Исполнения. 3) Присутствует интерактивная вспомогательная услуга данных, ассоциированная с программами вещания, которые в настоящее время просматриваются на основном экране, и она имеет модель взаимодействия TDO.

[1179] В случае (1), значение переменной CurrentTrigger состояния может быть пустой строкой.

[1180] В случае (2), значение переменной CurrentTrigger состояния может быть самым последним Trigger, который был принят телевизором для программ вещания, которые в настоящий момент просматриваются на основном экране.

[1181] В случае (3), значение переменной CurrentTrigger состояния может быть дополненной формой самого последнего активированного Activation Trigger из Activation Trigger, которые были приняты телевизором для программ вещания, которые в настоящий момент просматриваются на основном экране. (т.е., Activation Trigger может стать базой для переменной CurrentTrigger состояния, когда наступает его время активации, и он может оставаться базой до тех пор, пока другой Activation Trigger не достигает своего времени активации). Дополненная форма Activation Trigger может быть получена посредством объединения информации в Activation Trigger с информацией в TPT. Дополненная форма может быть равна одному из описанных выше форматов дополненного триггера.

[1182] Определение переменной CurrentTrigger состояния может предполагать, что Activation Trigger модели взаимодействия TDO доставляются клиентам UPnP в времена активации Trigger.

[1183] В другом варианте осуществления переменных состояния услуги триггера, всякий раз, когда изменяется триггер, для того чтобы передать триггер или расширенный триггер от приемника к устройству второго экрана в режиме реального времени, в качестве переменной состояния могут быть определены ATSCTrigger и ATSCExpandedTrigger.

[1184] Переменная ATSCTrigger состояния может содержать ссылку, в форме URI, на триггер, принятый из потока DTVCC или от сервера ACR. Данная переменная может включать в себя URL для TPT (таблицы параметров TDO), TDO ID, Event ID, Data ID, время мультимедиа, content ID, время активации для целевого события, и т.д.

[1185] Переменная ATSCExpandedTrigger состояния может содержать метаданные, в форме Фрагмента XML, ассоциированные с TDO для устройства второго экрана. Эти метаданные могут быть извлечены как из TPT, так и триггера, принятого из потока DTVCC или от сервера ACR. Данная переменная может иметь точно такую же схему XML, как и вариант осуществления на Фиг. 78.

[1186] Измененное значение определенных выше ATSCTrigger и ATSCExpandedTrigger может быть получено в режиме реального времени, когда приемник изменяет переменную состояния на основании механизма Обработки Событий UPnP.

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

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

[1189] Один вариант осуществления действий услуги триггера может определять действие GetLatestUnfilteredTrigger и GetLatestFilteredTrigger.

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

[1191] Значение выходного аргумента LatestUnfilteredTrigger может быть значение переменной LatestUnfilteredTrigger состояния.

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

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

[1194] Значение выходного аргумента LatestFilteredTrigger может быть значением переменной LatestFilteredTrigger состояния.

[1195] Приложение второго экрана может получать значение переменной LatestFilteredTrigger состояния, т.е., Trigger в фильтрованном потоке с самым последним целевым временем доставки, используя Action GetLatestFilteredTrigger.

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

[1197] Будут описаны действия услуги триггера в другом варианте осуществления описанных выше переменных состояния услуги триггера, в котором в качестве переменной состояния определены ATSCTrigger и ATSCExpandedTrigger.

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

[1199] Действие SetTrigger() может разрешать использование значения ATSCTrigger. Аргументом может быть CurrentTrigger.

[1200] Действие SetExpandedTrigger() может разрешать использование значения ATSCExpandedTrigger. Аргументом может быть CurrentTrigger.

[1201] Действие GetTrigger() может разрешать считывание значения ATSCTrigger. Аргументом может быть CurrentTrigger.

[1202] GetExpandedTrigger() может разрешать считывание значения ATSCExpandedTrigger. Аргументом может быть CurrentTrigger.

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

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

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

[1206] Устройство второго экрана может получать триггер действия исполнения/завершения через услугу доставки триггера и доставлять URL целевого TDO и ассоциированную информацию из полученного триггера DAE/браузеру. Браузер может выполнять действие, включенное в триггер, такое как исполнение или завершение.

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

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

[1209] Устройство второго экрана может получать триггер действия события триггера через услугу доставки триггера и затем извлекать информацию, такую как Data ID из полученного триггера. Затем, данные могут быть доставлены исполняемому в настоящий момент TDO, используя AJAX. TDO может выполнить соответствующую операцию в соответствии с принятыми данными.

[1210] Будет описана рабочая концепция услуги доставки триггера в другом варианте осуществления описанных выше переменных состояния услуги триггера, в котором в качестве переменной состояния определены ATSCTrigger и ATSCExpandedTrigger.

[1211] В данном варианте осуществления, в случае Модели Непосредственного Исполнения, если content id, т.е., «c=», включен в триггер, принятый через поток DTVCC или сервер ACR, приемник может устанавливать принятое значение триггера координаты времени в значение переменной ATSCTrigger состояния. Когда триггер координаты времени пребывает на приемник, значение переменной состояния может быть немедленного изменено или может быть доставлено устройству второго экрана через действие SetTrigger.

[1212] В настоящем варианте осуществления, в случае Модели TDO, если content id, т.е., «c=», не включен в триггер, принятый через поток DTVCC или сервер ACR, приемник принимает триггер активации и затем извлекает и объединяет ассоциированную информацию из TPT и информацию триггера, чтобы сгенерировать расширенный триггер. Затем, во (или перед) время активации расширенного триггера, значение переменной ATSCExpandedTrigger состояния может быть установлено или доставлено устройству второго экрана через действие SetExpandedTrigger.

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

[1214] Услуга AppURL может предоставлять устройствам второго экрана возможность выявления базового URL и имени приложения второго экрана, ассоциированного с исполняемым в настоящий момент DO.

[1215] Услуга AppURL UPnP может иметь две переменные состояния, AppURL и AppName.

[1216] Значение переменной AppURL состояния может быть базовым URL приложения второго экрана, ассоциированным с исполняемым в настоящий момент DO. Когда отсутствует DO с ассоциированным приложением второго экрана, исполняемым на устройстве первого экрана, значение переменной AppURL состояния может быть нулевой строкой.

[1217] Значение переменной AppName состояния может быть именем приложения второго экрана, ассоциированным с исполняемым в настоящий момент DO. Когда отсутствует DO с ассоциированным приложением второго экрана, исполняемым на устройстве первого экрана, значение переменной AppName состояния может быть нулевой строкой.

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

[1219] Услуга AppURL может иметь действие, GetAppURL.

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

[1221] Action GetAppURL может иметь два аргумента, AppURL и AppName.

[1222] Выходной аргумент AppURL может быть текущим значение переменной AppURL состояния. А выходной аргумент AppName может быть текущим значением переменной AppName состояния.

[1223] Соответственно, существует возможность получения текущего значения переменной AppURL состояния и текущего значения переменной AppName состояния через действие GetAppURL.

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

[1225] Приемник может поддерживать услугу Прокси-Сервера HTTP. Услуга прокси-сервера HTTP может означать услугу для получения TDO/файлов через TV приемник, если устройство второго экрана передает TDO/файлы через вещательную сеть.

[1226] Схема, показывающая рабочую концепцию услуги прокси-Сервера HTTP, может включать в себя систему 90010 вещания, сервер 90020 ACR, сервер 90030 вещательной компании ATSC 2.0 iTV, приемник 90040 ATSC 2.0 и/или Устройства 90050 второго экрана.

[1227] Система 90010 вещания может быть равна системе 42010 вещания.

[1228] Сервер 90020 ACR может быть равен серверу 42020 ACR.

[1229] Сервер 90030 вещательной компании ATSC 2.0 iTV может быть равен серверу 42030 вещательной компании ATSC 2.0 iTV.

[1230] Приемник 90040 ATSC 2.0 может принимать триггер, ассоциированный с вещательным A/V и интерактивной услугой, получать интерактивную услугу, используя триггер, и предоставлять интерактивную услугу на экране. Это может быть равно описанному выше приемнику. Услуга прокси-сервера HTTP может предоставлять приемнику 90040 ATSC 2.0 возможность выполнения функции, аналогичной той, что у прокси-сервера, для того, чтобы эффективно предоставлять файл, запрашиваемый устройством второго экрана, устройству второго экрана.

[1231] Устройства 90050 второго экрана могут быть равны устройствам 42050 второго экрана.

[1232] Услуга прокси-сервера HTTP может предоставлять приемнику возможность доступа к вещательному потоку или файлу через сеть Интернет через устройство второго экрана и предоставлять устройству второго экрана возможность доступа к контенту, передаваемому через вещательный поток. Если множество устройств второго экрана получает доступ к одному и тому же файлу через сеть Интернет, существует возможность минимизации доступа устройств второго экрана к одному и тому же файлу.

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

[1234] Услуга Прокси-Сервера UPnP может предоставлять прокси-сервер HTTP, чтобы предоставить возможность устройствам второго экрана доступа к файлам, которые доставляются на TV приемник в вещании через сеансы FLUTE, и сделать извлечение файлов с серверов Интернет устройствами второго экрана более эффективным в случаях, когда несколько устройств второго экрана в домашнем хозяйстве извлекают одновременно одни и те же файлы.

[1235] Переменная состояния и действие могут быть определены для достижения этого.

[1236] Услуга Прокси-Сервера HTTP UPnP может иметь одну переменную состояния, ProxyServerURL.

[1237] Значение переменной ProxyServerURL состояния может быть URL Прокси-Сервера HTTP - т.е., URL на который HTTP запросы должны доставляться для того, чтобы осуществлять маршрутизацию запросов посредством прокси-сервера.

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

[1239] Услуга Прокси-Сервера UPnP может иметь одно Action, GetProxyURL.

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

[1241] Action GetProxyURL может иметь один аргумент, ProxyURL.

[1242] Выходной аргумент ProxyURL может быть текущим значением переменной ProxyServerURL состояния.

[1243] Соответственно, существует возможность получения текущего значения переменной ProxyServerURL состояния через действие GetProxyURL.

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

[1245] В другом варианте осуществления переменной состояния услуги Прокси-Сервера HTTP UPnP, может быть определена Переменная Состояния услуги Прокси-Сервера HTTP UPnP, именуемая ATSCProxySeverURL. В дополнение, в данном варианте осуществления, может быть определено действие, именуемое GetProxyServerURL().

[1246] Переменная ATSCProxySeverURL может содержать ссылку, в форме URI, на прокси-сервер в приемнике. Прокси-сервер получает HTTP запрос в отношении файла от устройства второго экрана и извлекает файл из сеансов FLUTE в вещательном потоке или Интернет. Затем, прокси-сервер отправляет извлеченный файл устройству второго экрана в качестве HTTP ответа.

[1247] GetProxyServerURL() может быть действием, обеспечивающим считывание значения ProxyServerURL. ProxyServerURL может быть включена в качестве аргумента.

[1248] В другом варианте осуществления переменной состояния услуги прокси-сервера HTTP UPnP, может быть определена переменная состояния услуги прокси-сервера HTTP UPnP, именуемая ATSCFileList. В дополнение, в данном варианте осуществления, может быть определено действие, именуемое RequestFiles().

[1249] Файлы, включенные в вещательный поток, могут быть получены только посредством приемника, выполненного с возможностью приема вещательного контента. Вследствие этого, для того, чтобы предоставить возможность устройству второго экрана, которое не может принимать вещательный контент, доступа к файлу, включенному в вещательный контент, могут быть определены необходимые переменные состояния UPnP и действия. Т.е., ATSCFileList, которая является списком файлов, которые должны быть загружены через сеанс FLUTE, устанавливается в качестве переменной состояния UPnP или устройство второго экрана может быть выполнено с возможностью получения конкретного файла или множества файлов через действие RequestFiles(), запрашивающее файлы от приемника.

[1250] Переменная ATSCFileList состояния может содержать список CSV из запрашиваемых файлов для прокси-севера в приемнике.

[1251] RequestFiles() может быть действием, запрашивающим загрузку конкретного файла, включенного в вещательный поток, через сеть Интернет. В частности, в случае файла, включенного в вещательный поток, запрошенный файл может быть загружен через сеанс FLUTE.

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

[1253] Будет описана теория работы.

[1254] Может существовать два режима работы: один, при котором триггерное приложение (TDO) исполняется на TV приемнике, и второй, при котором не триггерное приложение (Упакованное Приложение) исполняется на TV приемнике.

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

[1256] Приложение второго экрана затем может подписаться на «обработку событий» UPnP применительно к услуге Trigger для получения уведомлений о Trigger готовых к доставке, и оно может использовать Action GetLatestUnfilteredTrigger или GetLatestFilteredTrigger для получения Trigger, которое оно предназначено использовать. Результатом этого является то, что приложение второго экрана может получать соответствующие Trigger в подходящие времена. Затем приложение может действовать по этим Trigger, любым образом, которым оно предназначено использовать.

[1257] Приложение второго экрана также может подписаться на «обработку событий» UPnP применительно к услуге Двусторонней Связи для получения уведомления об адресе TCP/IP и порте для использования для запроса соединения применительно к двусторонней связи, и уведомлений о том, когда присутствует DO, исполняемый на основном устройстве, который готов к осуществлению связи. Приложение затем может задействовать двустороннюю связь с любым DO, который поддерживает такую связь.

[1258] Действия, вызываемые Trigger, и/или двусторонней связью часто могут требовать загрузки файлов приложением второго экран. Эти файлы могут быть доступны от серверов HTTP в сети Интернет, или они могут быть доступны из a d сеанс в TV вещании (или обоими способами).

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

[1260] Если некоторые или все требуемые файлы доступны только через TV вещание, и если Приемник предлагает услугу Прокси-Сервера HTTP, тогда приложение может получать URL прокси-сервера с помощью Action GetProxyURL и извлекать требуемые файлы через прокси-сервер. Приложение также может выбирать использование прокси-сервера в других ситуациях, где может быть более удобным извлекать файлы таким образом, нежели непосредственно.

[1261] В случае исполнения на TV приемнике не-триггерного приложения, Независимо от программ вещания в настоящий момент просматриваемых, пользователь может активировать DO на TV приемнике, который, среди прочего, делает доступным имя и местоположение приложения-компаньона, которое должно быть загружено на устройство второго экрана посредством услуги AppURL.

[1262] Точка управления в устройстве второго экрана может подписаться на «обработку событий» UPnP, ассоциированную с услугой AppURL, для получения уведомления об изменениях переменных AppURL и AppName. Затем точка управления будет указывать пользователю устройства второго экрана о том, что ожидает решения доступная услуга. Впоследствии, пользователь будет просматривать AppName и выбирать услугу, приводя к запуску приложения-компаньона второго экрана на устройстве второго экрана.

[1263] Приложения второго экрана могут быть ассоциированы с DO, исполняемым на приемнике ATSC 2.0, даже когда этот DO является ранее загруженным на приемник предоставляемым вещательной компанией Упакованным Приложением, чей жизненный цикл управляется потребителем вместо вещательной компании. В отсутствие триггеров для идентификации приложения-компаньона второго экрана, приемник предлагает услугу AppURL, которая позволяет точке управления в устройстве второго экрана использовать действие GetAppURL для получения доступа к опубликованному URL приложения второго экрана и запуска его на устройстве второго экрана.

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

[1265] Один вариант осуществления архитектуры устройства второго экрана может включать в себя удаленный сервер 95010 контента, TV приемник 95020 и/или устройство 95030 второго экрана.

[1266] Удаленный сервер 95010 контента может предоставлять контент. Контент может быть предоставлен приемнику 95020 или устройству 95030 второго экрана.

[1267] TV приемник 95020 может предоставлять услугу триггера UPnP и услугу прокси-сервера UPnP. Данный приемник может быть равен описанному выше приемнику.

[1268] Устройство 95030 второго экрана может иметь приложение второго экрана (Приложение ATSC 2.0) и приложение второго экрана может иметь модуль Точки Управления (CP) UPnP в обработчике триггера. Модуль Точки Управления (CP) UPnP обрабатывает всю связь UPnP между Приложением Второго Экрана (Приложение ATSC 2.0) и услугой Trigger и услугой Прокси-Сервера в TV Приемнике (95020). Он может управлять процессом обнаружения, получать URL прокси-сервера, и подписываться на обработку событий услуги Trigger.

[1269] Trigger, которые прибывают от услуги Trigger UPnP, могут быть переданы в Обработчик Trigger. Если Trigger указывает на то, что новый Декларативный Объект (DO) должен быть загружен и исполнен в DAE (Декларативная Прикладная Среда - т.е. браузер), Обработчик Trigger может об этом позаботиться. Если Trigger указывает на то, что DO уже исполняемый в браузере должен предпринять некоторое действие, Обработчик Trigger может пропустить Trigger в DO. Пользователь устройства второго экрана может взаимодействовать с DO. Обработчик Trigger может быть невидимым для пользователя.

[1270] Приложение Второго Экрана может выполнять следующие функции при необходимости. 1) Использовать протоколы обнаружения и описания UPnP для нахождения услуги Trigger и, если доступно, услуги Прокси-Сервер на TV приемнике. 2) Использовать протокол SUBSCRIBE (ПОДПИСКА) UPnP для подписки на обработку событий услуги Trigger. 3) Вызывать Action GetProxyURL услуги Прокси-Сервера для получения URL прокси-сервера HTTP (если доступно). 4) Принимать Trigger, доставляемые через события услуги Trigger. 5) Если принимается Trigger Непосредственного Исполнения, и DO, идентифицированный в Trigger, уже не работает в DAE, запускать его в DAE (загружая его сначала при необходимости). 6) Пропускать каждый принятый Trigger Непосредственного Исполнения к DO, идентифицированному в Trigger (после загрузки и запуска DO при необходимости). 7) Если принимается Trigger TDO, и если атрибутом Action у Trigger является нечто другое, а не «TriggerEvent», выполнять Action (например, подготавливать к запуску TDO, запускать TDO, завершать TDO, и т.д.). 8) Если принимается Trigger TDO, и если атрибутом Action у Trigger является «TriggerEvent», пропускать Trigger к TDO, идентифицируемому в качестве цели Trigger. Если TDO уже не работает в DAE, отбрасывать Trigger. 9) Загружать файлы (включая TDO) при необходимости, либо через прямое Интернет соединение, либо через услугу Прокси-Сервера на TV приемнике.

[1271] Trigger Непосредственного Исполнения и Trigger TDO могут выполняться немедленно когда принимаются в том случае, если они не содержат атрибута «spread» или «diffusion». Когда Trigger содержит атрибут «spread» или «diffusion», действие может быть отложено на произвольный интервал.

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

[1273] Схема, показывающая упрощенную структуру приемника, может включать в себя антенну (rcvr2010), тюнер (rcvr2020), EPG (rcvr2030), Демодулятор (rcvr2040) VSB или DVB, модуль (rcvr2050) управления каналом, модуль (rcvr2051) SI, декодер (rcvr2060) системы MPEG-2 TS, модуль (rcvr2070) субтитров, модуль (rcvr2080) триггера, web-браузер (rcvr2090), инфраструктуру (rcvr2091) UPnP, стек (rcvr2100) сетевых протоколов, сетевой интерфейс (rcvr2110), модуль (rcvr2120) UI, декодер (rcvr2140) аудио, декодер (rcvr2150) видео, громкоговорители (rcvr2160), модуль (rcvr2170) отображения, графический процессор (rcvr2180), приемник (rcvr2190) пульта дистанционного управления и/или пульт (rcvr2200) дистанционного управления.

[1274] Антенна (rcvr2010) может принимать вещательный сигнал в соответствии с вещательным потоком. Здесь, антенна (rcvr2010) может быть той, что обычно используется в данной области техники.

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

[1276] EPG (rcvr2030) может быть услугой расписания вещательных программ для предоставления времени вещания TV программы, контента, и информации об актере, используя пустую частоту TV вещания или добавочный канал (Электронное расписание программ). Принятые данные EPG сохраняются и зритель манипулирует EPG, используя пульт дистанционного управления для выбора и резервирования программы, тем самым выполняя оплату за заказ просмотра программы, поиск программы по теме или типу, запись видео, и т.д. Принятое EPG также может быть доставлено в модуль UI.

[1277] Демодулятор (rcvr2040) VSB или DVB может модулировать сигнал VSB или сигнал DVB. Демодулятор (rcvr2040) VSB или DVB может восстанавливать модулированный VSB или DVB (например, OFDM-модулированный сигнал) в исходный сигнал. Процесс демодуляции Демодулятора (rcvr2040) VSB или DVB может быть тем, что обычно используется в данной области техники.

[1278] Модуль (rcvr2050) управления каналом может выполнять управление каналом, используя принятое EPG. Может быть доставлено EPG обработанное модулем SI. Модуль управления каналом может служить в качестве общего модуля управления каналом.

[1279] Модуль (rcvr2051) SI может подтверждать информацию особую для программы, если вещательный поток принимается через Декодер (rcvr2060) Системы MPEG-2 TS. Используя подтвержденную информацию, может быть выявлено как много субтитров присутствует в вещательной программе и присутствие триггера в услуге #6.

[1280] Декодер (rcvr2060) Системы MPEG-2 TS может декодировать транспортный поток (TS) демодулированного сигнала. Декодер rcvr2060 Системы MPEG-2 TS может получать и доставлять поток субтитров из транспортного потока модулю rcvr2070 субтитров. Декодер rcvr2060 Системы MPEG-2 TS может отправлять декодированный аудио и видео сигнал декодеру аудио/видео.

[1281] Модуль (rcvr2070) Субтитров может принимать поток субтитров. Модуль rcvr2070 субтитров может наблюдать за услугой #6 или другими услугами и выявлять, выбрана ли услуга #6 или услуги для передачи триггера, и отправлять модулю rcvr2080 триггера, или обрабатывается ли текст субтитров и отображается на экране. Данные триггера могут быть доставлены модулю rcvr2080 триггера. Другие услуги субтитров могут быть подвергнуты обработке текста субтитров и отправлены на графический процессор rcvr2180. Модуль (rcvr2070) субтитров доставляет триггер модулю (rcvr2080) триггера через подтвержденную информацию, если триггер включен в принятые в настоящий момент цифровые субтитры.

[1282] Модуль (rcvr2080) триггера может анализировать информацию триггера, TPT и/или AMT и обрабатывать проанализированные данные. Модуль rcvr2080 триггера может получать доступ к сети через стек rcvr2100 сетевых протоколов, используя значение информации URI триггера. Значение информации URI может быть адресом сервера HTTP. Модуль rcvr2080 триггера может анализировать контент файла TPT для получения TDO URL. В дополнение, модуль rcvr2080 триггера может анализировать AMT для обработки данных. Посредством анализа может быть получена другая информация. После приема сообщения AMT, TDO URL, соответствующий web-браузеру, доставляется в соответствии с предварительно определенным временем и работа или работающий в настоящий момент TDO может быть остановлен в предварительно определенное время. Это соответствует действию TDO и модуль rcvr2080 триггера отправляет команду web-браузеру для работы. Работа модуля rcvr2080 триггера, которая относится к настоящему изобретению, будет подробно описана ниже. Модуль (rcvr2080) триггера может непосредственно или опосредованного получать доступ к Интернет серверу через стек (rcvr2100) сетевых протоколов. Модуль (rcvr2080) триггера может немедленно интерпретировать триггер, принятый через DTVCC, и загружать и обрабатывать файл TPT из сети Интернет через сетевой интерфейс (rcvr2110) при необходимости. Файл TPT может быть немедленно обработан после загрузки, тем самым выполняя необходимую операцию. На этот раз, если присутствует триггер, ассоциированный со вторым экраном, и ассоциированное событие, как описано выше, может быть осуществлена связь с устройством второго экрана, используя различные способы. Такая связь может быть осуществлена посредством описываемой ниже Инфраструктуры (rcvr2091) UPnP.

[1283] Web-браузер (rcvr2090) может принимать команду от модуля rcvr2080 триггера, код клавиши браузера от модуля rcvr2120 UI и код клавиши браузера от приемника rcvr2190 пульта дистанционного управления и осуществлять связь со стеком rcvr2100 сетевых протоколов.

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

[1285] Стек (rcvr2100) Сетевых Протоколов может осуществлять связь с модулем rcvr2080 триггера и web-браузером для получения доступа к серверу через сетевой интерфейс rcvr2110.

[1286] Сетевой Интерфейс (rcvr2110) осуществляет общее соединение нескольких других устройств или соединение сетевого компьютера и внешней сети. Сетевой интерфейс может быть соединен с сервером для загрузки TDO, TPT, AMT и т.д. Здесь, работа сетевого интерфейса rcvr2110 может быть работой сетевого интерфейса rcvr2110, которая обычна используется в данной области техники. Работа сетевой интерфейса rcvr2110, которая относится к настоящему изобретению, будет подробно описана ниже.

[1287] Модуль (rcvr2120) UI может принимать ввод информации зрителем при помощи пульта rcvr2200 дистанционного управления через приемник rcvr2190 пульта дистанционного управления. Если принятая информация относится к услуге, использующей сеть, код клавиши браузера может быть доставлен web-браузеру. Если принятая информация относится к отображаемому в настоящий момент видео, сигнал может быть доставлен модулю rcvr2170 отображения через графический процессор rcvr2180.

[1288] Декодер (rcvr2140) аудио может декодировать аудио сигнал, принятый от Декодера (rcvr2060) Системы MPEG-2 TS. Затем, декодированный аудио сигнал может быть отправлен на громкоговоритель и выведен зрителю. Здесь, декодер rcvr2140 аудио может быть тем, что обычно используется в данной области техники.

[1289] Декодер (rcvr2150) видео может декодировать видео сигнал, принятый от Декодера rcvr2060 Системы MPEG-2 TS. Затем, декодированный видео сигнал может быть отправлен в модуль rcvr2170 отображения для вывода зрителю. Здесь, декодер rcvr2150 видео может быть тем, что обычно используется в данной области техники.

[1290] Громкоговорители (rcvr2160) могут выводить аудио сигнал зрителю. Громкоговоритель может быть тем, что обычно используется в данной области техники.

[1291] Модуль (rcvr2170) отображения может выводить видео сигнал зрителю. Модуль rcvr2170 отображения может быть тем, что обычно используется в данной области техники.

[1292] Графический Процессор (rcvr2180), может выполнять графическую обработку в отношении текста субтитров, принятого от модуля rcvr2070 субтитров и информации ввода пользователя, принятой от модуля rcvr2120 UI. Обработанная информация может быть доставлена модулю rcvr2170 отображения. Графический процессор rcvr2180 может быть тем, что обычно используется в данной области техники.

[1293] Приемник (rcvr2190) Пульта Дистанционного Управления может принимать информацию от пульта rcvr2200 дистанционного управления. На этот раз, код клавиши может быть доставлен модулю rcvr2120 UI и код клавиши браузера может быть доставлен web-браузеру.

[1294] Пульт (rcvr2200) Дистанционного Управления доставляет сигнал, введенный зрителем приемнику rcvr2190 пульта дистанционного управления. Пульт (rcvr2200) дистанционного управления может принимать ввод пользователя в отношении изменения виртуального канала. В дополнение, пульт дистанционного управления может принимать информацию, выбранную зрителем, в отношении приложения. Пульт rcvr2200 дистанционного управления может доставлять принятую информацию приемнику rcvr2190 пульта дистанционного управления. На этот раз, информация может дистанционно доставляться используя инфракрасный (IR) свет на расстоянии в пределах предварительно определенного диапазона.

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

[1296] Один вариант осуществления структуры устройства второго экрана может включать в себя подсистему 97010 IO, файловую систему 97020, подсистему 97030 сетевого протокола и базовые модули 97040.

[1297] Подсистема 97010 IO может быть соединена со всеми устройствами, которые могут быть установлены в устройстве второго экрана для внешнего соединения. Подсистема 97010 IO может быть соединена с клавишной панелью, дисплеем, микрофоном, громкоговорителем, стерео разъемом, датчиком движения, датчиком света, GPS и камерой. Управление каждым устройством I/O может осуществляться посредством модуля клавиши, модуля управления отображением, модуля управления аудио, модуля управления датчиком и/или модулем управления камерой. Управление каждым устройством I/O осуществляется посредством драйвера устройства и каждый датчик или камера могут получить доступ к любой программе, если посредством подсистемы 97010 IO вызывается функция в форме SDK. В некоторых случаях, функция может быть ограничена таким образом, что доступ возможен только в собственном приложении.

[1298] Файловая система 97020 может считывать и записывать файл применительно к внешней SD карте и может быть соединена с USB для осуществления связи с целью передачи данных. Может быть соединено устройство, такое как SD карта, флэш память или USB. Управление этим может осуществляться посредством Интерфейса SD, Управления Флэш Памятью или Управления ШИНОЙ USB.

[1299] Подсистема 97030 сетевого протокола может осуществлять связь через 3GPP, Wi-Fi и/или Bluetooth.

[1300] Базовые модули 97040 могут быть включены во второе устройство. Модуль управления батареей может управлять объемом батареи устройства второго экрана, а модуль уведомления может быть использован, когда поставщик связи или изготовитель предоставляет уведомление устройству второго экрана. В дополнение, модуль магазина может быть использован для покупки приложений применительно ко второму экрану, выполненных при помощи открытого SDK, предоставляемого устройством второго экрана. Модуль управления приложением может управлять приложением, инсталлированным при помощи модуля магазина, и уведомлять об обновлении приложения. В дополнение, может быть включен web-модуль с тем, чтобы устройство второго экрана выполняло доступ к сети Интернет. Различные функции второго экрана могут быть установлены в соответствии с персональными предпочтениями и может быть использована программа предпочтений пользователя.

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

[1302] Например, модуль инфраструктуры UPnP может не поддерживаться устройством второго экрана или может быть инсталлирован в устройстве второго экрана. Если модуль инфраструктуры UPnP инсталлирован, собственное приложение также инсталлируется для простого выполнения операции UPnP. Тем не менее, в структуре приемника, инфраструктура UPnP может предоставлять пользователю возможность инсталляции приложения услуги второго экрана или приложения, поддерживающего инфраструктуру UPnP. Через модуль инфраструктуры UPnP существует возможность нахождения приемника, выполненного с возможностью приема наземной волны.

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

[1304] Будет описан один вариант осуществления Сценария услуги второго экрана.

[1305] Один вариант осуществления сценария услуги второго экрана может включать в себя прием (s98010) триггера, запрос (s98020) TPT, передачу (s98030) TPT в качестве ответа, запрос (s98040) TDO, передачу (s98050) TDO в качестве ответа, исполнение (s98060) TDO, отправку (s98070) сообщения scanDeviceList, вызов (s98080) функции обнаружения, исполнение (s98090) приложения UPnP, многоадресную передачу (s98100) сообщения поиска, уведомление (s98110) Инфраструктуры UPnP, возвращение (s98120) списка устройств, возвращение (s98130) дескриптора устройства, отправку (s98140) сообщения scanServiceList, вызов (s98150) функции списка услуг, отправку (s98160) сообщения GetServiceDescription, отправку (s98170) сообщения HTTP, возвращение (s98180) списка услуг, возвращение (s98190) списка дескрипторов услуг, отправку (s98200) сообщения hnHandle, вызов (s98210) функции списка услуг, отправку (s98220) сообщения GetDeviceProfile, отправку (s98230) сообщения HTTP, возвращение (s98240) ответа SOAP, возвращение (s98250) ответа SOAP XML, анализ (s98260) ответа SOAP, отправку (s98270) сообщения hnHandle, вызов (s98280) функции List услуги, отправку (s98290) сообщения InputUIListing, отправку (s98300) сообщения HTTP, возвращение (s98310) ответа SOAP, возвращение (s98320) TimeToLive, отправку (s98330) сообщения hnHandle, вызов (s98340) функции List услуги, отправку (s98350) DisplayMessage, отправку (s98360) сообщения HTTP, возвращение (s98370) Null, возвращение (s98380) Null и/или исполнение (s98390) приложения второго экрана.

[1306] Прием (s98010) триггера может включать в себя прием триггера от вещательной компании, используя сообщение DTVCC iTV через вещательный поток.

[1307] Запрос (s98020) TPT может включать в себя анализ и интерпретацию принятого триггера и запрос имеющей отношение TPT у Интернет сервера вещательной компании.

[1308] Передача (s98030) TPT в качестве ответа может включать в себя передачу TPT в качестве ответа.

[1309] Запрос (s98040) TDO может включать в себя запрос TDO у сервера Интернет вещательной компании, если требуется загрузка имеющего отношения TDO.

[1310] Передача (s98050) TDO в качестве ответа может включать в себя передачу запрошенного TDO.

[1311] Исполнение (s98060) TDO может включать в себя исполнение модулем триггера TDO.

[1312] Отправка (s98070) сообщения scanDeviceList может включать в себя отправку исполняемым DO (или TDO) сообщения для запроса сканирования списка устройств.

[1313] Вызов (s98080) функции обнаружения может включать в себя вызов функции обнаружения инфраструктуры UPnP для обнаружения устройства.

[1314] Исполнение (s98090) приложения UPnP может включать в себя исполнение устройством второго экрана приложения UPnP для модуля запуска услуги второго экрана. Данный этап является независимым от основного устройства и может быть выполнен перед исполнением (s98090) приложения UPnP.

[1315] Многоадресная передача (s98100) сообщения поиска может включать в себя многоадресную передачу инфраструктурой UPnP сообщения поиска для поиска устройства второго экрана в домашней сети.

[1316] Уведомление (s98110) Инфраструктуры UPnP может включать в себя передачу устройством второго экрана, которое принимает сообщение поиска, сообщения уведомления основному устройству. Таким образом, существует возможность уведомления о присутствии устройства второго экрана.

[1317] Возвращение (s98120) списка устройств может включать в себя возвращение инфраструктурой UPnP списка устройств после обнаружений устройства.

[1318] Возвращение (s98130) дескриптора устройства может включать в себя доставку принятого списка устройств к DO.

[1319] Отправка (s98140) сообщения scanServiceList может включать в себя передачу исполняемым DO (или TDO) сообщения для запроса сканирования списка услуг.

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

[1321] Отправка (s98160) сообщения GetServiceDescription может включать в себя запрос описания услуги устройства второго экрана у устройства второго экрана.

[1322] Отправка (s98170) сообщения HTTP может включать в себя отправку результата отправки (s98160) сообщения GetServiceDescription. Как описано выше, может быть отправлено сообщение, такое как HTTP/1.1 200 OK (успешно). Описание услуги может быть принято в XML.

[1323] Возвращение (s98180) списка услуг может включать в себя возвращение списка услуг после того, как инфраструктура UPnP принимает описание услуги.

[1324] Возвращение (s98190) списка дескрипторов услуг может включать в себя возвращение принятого списка услуг.

[1325] Отправка (s98200) сообщения hnHandle может включать в себя отправку сообщения для того, чтобы получить профиль устройства.

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

[1327] Отправка (s98220) сообщения GetDeviceProfile может включать в себя запрос описания услуги устройства второго экрана у устройства второго экрана. Отправка (s98230) сообщения HTTP может включать в себя отправку результата запроса в отправке (s98220) сообщения GetDeviceProfile. Как описано выше, может быть отправлено сообщение, такое как HTTP/1.1 200 OK (успешно). Может быть принят профиль устройства.

[1328] Возвращение (s98240) ответа SOAP может включать в себя возвращение принятого профиля устройства.

[1329] Возвращение (s98250) ответа SOAP XML может включать в себя возвращение принятого профиля устройства в XML.

[1330] Анализ (s98260) ответа SOAP может включать в себя анализ DO принятого сообщения SOAP.

[1331] Отправка (s98270) сообщения hnHandle может включать в себя отправку сообщения для того, чтобы уведомить устройство второго экрана об URL адресе услуги второго экрана.

[1332] Вызов (s98280) функции List услуги может включать в себя вызов функции списка услуг инфраструктуры UPnP.

[1333] Отправка (s98290) сообщения InputUIListing может включать в себя уведомление устройства второго экрана об URL адресе услуги второго экрана. Может быть использовано описанное выше действие AddUIListing. Устройство второго экрана может добавлять полученный URL в UIListing.

[1334] Отправка (s98300) сообщения HTTP может включать в себя отправку результата запроса в отправке (s98290) сообщения InputUIListing. Как описано выше, может быть отправлено сообщение, такое как HTTP/1.1 200 OK (успешно).

[1335] Возвращение (s98310) ответа SOAP может включать в себя возвращение сообщения, указывающего на то, что URL был передан.

[1336] Возвращение (s98320) TimeToLive может включать в себя отправку результата запроса в отправке (s98290) сообщения InputUIListing, подобно отправке (s98300) сообщения HTTP.

[1337] Отправка (s98330) сообщения hnHandle может включать в себя отправку сообщения для того, чтобы доставить сообщение отображения устройству второго экрана.

[1338] Вызов (s98340) функции List услуги может включать в себя вызов функции списка услуг инфраструктуры UPnP.

[1339] Отправка (s98350) DisplayMessage может включать в себя передачу сообщения отображения устройству второго экрана. Сообщение отображения может включать в себя информацию, такую как тип сообщения. Может быть использовано описанное выше действие DisplayMessage. Устройство второго экрана может отображать сообщение на втором экране, в соответствии с сообщением отображения.

[1340] Отправка (s98360) сообщения HTTP может включать в себя отправку результата отправки (s98350) DisplayMessage. Как описано выше, может быть отправлено сообщение, такое как HTTP/1.1 200 OK (успешно).

[1341] Возвращение (s98370) Null может включать в себя возвращение Null если принимается HTTP/1.1 200 OK.

[1342] Возвращение (s98380) Null может включать в себя возвращение Null для DO, если Null принимается в качестве ответа.

[1343] Исполнение (s98390) приложения второго экрана может включать в себя исполнение устройством второго экрана приложения второго экрана.

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

[1345] Один вариант осуществления способа обработки интерактивной услуги на первом устройстве может включать в себя отправку (s99010) сообщения обнаружения, прием (s99020) запроса в отношении описаний, отправку (s99030) ответа с описаниями, предоставление (s99040) прокси-сервера HTTP, прием (s99050) файлов из вещательного потока и доставку (s99060) файлов второму устройству.

[1346] Отправка (s99010) сообщения обнаружения может включать в себя отправку сообщения обнаружения приложению второго экрана, работающему на втором устройстве. Сообщение обнаружения может служить для указания услуги поддержки второго экрана, предоставляемой первым устройством. Здесь, первое устройство может быть описанным выше основным устройством или TV приемником. Здесь, сообщение обнаружения может не передаваться одному устройству второго экрана, а может осуществляться его многоадресная передача множеству устройств второго экрана. Здесь, услуга поддержки второго экрана может быть описанной выше услугой второго экрана. Отправка (s99010) сообщения обнаружения может быть включена в описанный выше этап обнаружения устройства.

[1347] Прием (s99020) запроса в отношении описаний может включать в себя прием запроса в отношении описаний услуги поддержки второго экрана, предоставляемой первым устройством. Второе устройство может быть описанным выше устройством второго экрана. Приложение второго экрана, которое исполняется на устройстве второго экрана, может запрашивать описания услуги поддержки второго экрана, предоставляемой первым устройством, у первого устройства. Прием (s99020) запроса в отношении описаний может включать в себя прием первым устройством запроса. Это может быть включено в описанный выше этап обнаружения устройства.

[1348] Отправка (s99030) ответа с описаниями может включать в себя передачу первым устройством описаний приложению второго экрана в ответ на запрос в приеме (s99020) запроса в отношении описаний. Данный ответ может включать в себя другую информацию в дополнение к описаниям. Это может быть включено в описанный выше этап обнаружения устройства.

[1349] Предоставление (s99040) прокси-сервера HTTP может включать в себя генерирование первым устройством и предоставление прокси-сервера HTTP второму устройству. Прокси-сервер HTTP может быть предоставлен услугой прокси-сервера HTTP, доступ к которой получает второе устройство. Здесь, услуга прокси-сервера HTTP может быть одной из услуг поддержки второго экрана.

[1350] Прием (s99050) файлов из вещательного потока может включать в себя прием первым устройством данных, таких как TDO или приложение, из вещательного потока. Такие данные могут быть использованы для второго устройства.

[1351] Доставка (s99060) файлов второму устройству может включать в себя доставку первым устройством файлов, принятых на этапе приема (s99050) файлов из вещательного потока через прокси-сервер, предоставленный на этапе предоставления (s99040) прокси-сервера HTTP. Как описано выше, второе устройство может принимать данные через вещательный поток.

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

[1353] В другом варианте осуществления настоящего изобретения, сначала может быть доставлен URL прокси-сервера HTTP перед тем, как первое устройство доставляет файлы второму устройству. Второе устройство может использовать действие GetProxyURL услуги прокси-сервера HTTP первого устройства. Услуга прокси-сервера HTTP и действие GetProxyURL были описаны выше.

[1354] В другом варианте осуществления настоящего изобретения, триггер может быть принят из вещательного потока или от Интернет сервера и принятый триггер может быть доставлен второму устройству, используя услугу триггера. Здесь, услуга триггера может быть одной из услуг поддержки второго экрана. Триггер был описан выше. Доставленный триггер может быть применен к приложению во втором устройстве, в качестве описанного выше триггера координаты времени или триггера активации. Соответственно, существует возможность исполнения события приложения в конкретное время.

[1355] В другом варианте осуществления настоящего изобретения, приложение может быть Декларативным Объектом, Триггерным Декларативным Объектом, Декларативным Объектом не в режиме Реального Времени или Несвязанным Декларативным Объектом.

[1356] В другом варианте осуществления настоящего изобретения, сначала, второе устройство может быть уведомлено о том, что изменились URL и имя приложения-компаньона. Здесь, приложение-компаньон может означать приложение, которое зависит от приложения, которое исполняется в первом устройстве. Приложение-компаньон может быть одним из приложений второго экрана. Вследствие этого, URL и имя приложения-компаньона могут быть доставлены второму устройству и приложение-компаньон может быть доставлено второму устройству, используя прокси-сервер HTTP. На этот раз, прокси-сервер HTTP может быть сгенерирован используя услугу прокси-сервера HTTP. В данном варианте осуществления, второе устройство может использовать действие GetAppURL услуги AppURL первого устройства. Услуга AppURL и действие GetAppURL были описаны выше. Услуга AppURL может быть одной из услуг поддержки второго экрана.

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

[1358] Один вариант осуществления способа обработки интерактивной услуги в приложении второго экрана, работающем во втором устройстве, может включать в себя прием (s10010) сообщения обнаружения, отправку (s10020) запроса в отношении описаний, прием (s10030) ответа с описаниями, получение доступа (s10040) к услуге прокси-сервера HTTP и/или прием (s10050) файлов от первого устройства.

[1359] Прием (s10010) сообщения обнаружения может включать в себя прием сообщения обнаружения от первого устройства. Как описано выше, первое устройство может быть основным устройством или TV приемником. Второе устройство может быть описанным выше устройством второго экрана. Сообщение обнаружение может служить для указания услуги поддержки второго экрана, предоставляемой первым устройством. Первое устройство может отправлять сообщение обнаружения только второму устройству или может осуществлять многоадресную передачу сообщения обнаружения всем устройствам в домашней сети. Данный этап может быть включен в описанный выше этап обнаружения устройства. Данный этап может быть приемом вторым устройством сообщения обнаружения от первого устройства. Отправка (s99010) сообщения обнаружения может быть описана с точки зрения приложения второго экрана.

[1360] Отправка (s10020) запроса в отношении описаний может включать в себя запрос описаний услуги поддержки второго экрана, предоставляемой первым устройством, у первого устройства. Прием (s99020) запроса в отношении описаний может быть описан с точки зрения приложения второго экрана. Данный этап может быть включен в описанное выше обнаружение устройства.

[1361] Прием (s10030) ответа с описаниями может включать в себя прием описаний услуги в качестве ответа на запрос, отправленный на этапе отправки (s10020) запроса в отношении описаний. Первое устройство может передавать описание его услуги приложению второго экрана. Отправка (s99030) ответа с описаниями может быть описана с точки зрения приложения второго экрана. Данный этап может быть включен в описанный выше этап обнаружения устройства.

[1362] Получение доступа (s10040) к услуге прокси-сервера HTTP может включать в себя получение доступа к услуге прокси-сервера HTTP, которая является одной из услуг поддержки второго экрана. Первое устройство может принимать файлы из вещательного потока. Получение доступа к услуге прокси-сервера HTTP может быть выполнено на основании описаний, принятых на этапе приема (s10030) ответа с описаниями. Среди описаний, принятых на этапе приема (s10030) ответа с описаниями, может быть использовано описание услуги прокси-сервера HTTP.

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

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

[1365] В другом варианте осуществления настоящего изобретения, URL прокси-сервера HTTP может быть принят от первого устройства перед тем, как приложение второго экрана принимает файлы. Приложение второго экрана может использовать действие GetProxyURL услуги прокси-сервера HTTP первого устройства. Услуга прокси-сервера HTTP и действие GetProxyURL были описаны выше.

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

[1367] В другом варианте осуществления настоящего изобретения, приложение может быть Декларативным Объектом, Триггерным Декларативным Объектом, Декларативным Объектом не в режиме Реального Времени или Несвязанным Декларативным Объектом.

[1368] В другом варианте осуществления настоящего изобретения, сначала, может быть принято уведомление об изменении URL и имени приложения-компаньона. Здесь, приложение-компаньон может означать приложение, которое зависит от приложения, которое исполняется в первом устройстве. Приложение-компаньон может быть одним из приложений второго экрана. Вследствие этого, URL и имя приложения-компаньона могут быть приняты и приложение-компаньон может быть принято, используя прокси-сервер HTTP. На этот раз, прокси-сервер HTTP может быть сгенерирован используя услугу прокси-сервера HTTP. В данном варианте осуществления, второе устройство может использовать действие GetAppURL услуги AppURL первого устройства. Услуга AppURL и действие GetAppURL были описаны выше. Услуга AppURL может быть одной из услуг поддержки второго экрана.

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

[1370] Один вариант осуществления устройства для обработки интерактивной услуги в качестве первого устройства может включать в себя первый модуль 101010, второй модуль 101020 и третий модуль 101030.

[1371] Здесь, первое устройство может быть описанным выше основным устройством или TV приемником.

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

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

[1374] Первый модуль 101010 может быть выполнен с возможностью приема первого запроса в отношении описаний услуг поддержки второго экрана от приложения второго экрана. Может быть принят запрос в отношении описаний услуги поддержки второго экрана, предоставляемой первым устройством. Приложение второго экрана, исполняемое устройством второго экрана, может запросить описания услуги поддержки второго экрана, предоставляемой первым устройством, у первого устройства. Данный запрос может быть принят. Данная операция может быть выполнена для обнаружения устройства.

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

[1376] Второй модуль 101020 может служить для приема файлов из вещательного потока. Если принимается вещательный поток, это может быть принято через DTVCC, как описано выше. Второй модуль 101020 может быть описанным выше тюнером. Файлы могут включать в себя приложение, TDO, и т.д. Такие данные могут быть использованы для второго устройства.

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

[1378] Третий модуль 101030 может быть выполнен с возможностью доставки файлов второму устройству через прокси-сервер HTTP. Третий модуль 101030 может доставлять файлы, принятые из вещательного потока, второму модулю 101020 через прокси-сервер. Как описано выше, посредством данного способа, второе устройство может принимать данные через вещательный поток.

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

[1380] В другом варианте осуществления настоящего изобретения, перед тем, как третий модуль 101030 доставляет файлы второму устройству, сначала может быть предоставлен URL прокси-сервера HTTP. Второе устройство может использовать действие GetProxyURL услуги прокси-сервера HTTP первого устройства. Услуга прокси-сервера HTTP и действие GetProxyURL были описаны выше.

[1381] В другом варианте осуществления настоящего изобретения, устройство может дополнительно включать в себя четвертый модуль 101040. Четвертый модуль 101040 может принимать триггер из вещательного потока или от Интернет сервера. Первый модуль 101010 может доставлять триггер, принятый четвертым модулем 101040, второму устройству, используя услугу триггера. Здесь, услуга триггера может быть одной из услуг поддержки второго экрана. Триггер был описан выше. Доставленный триггер может быть применен к приложению во втором устройстве в качестве описанного выше триггера координаты времени или триггера активации. Соответственно, существует возможность исполнения события приложения в конкретное время. Здесь, описанный выше второй модуль 101020 может быть включен в четвертый модуль 101040 в зависимости от намерения разработчика. Т.е., четвертый модуль 101040 может быть описанным выше тюнером, если файлы принимаются через вещательный поток, и может быть описанным выше сетевым интерфейсом, если файлы принимаются через сеть Интернет. Соответственно, четвертый модуль 101040 может быть разработан для выполнения функции второго модуля 101020 для приема файлов через вещательный поток.

[1382] В другом варианте осуществления настоящего изобретения, приложение может быть Декларативным Объектом, Триггерным Декларативным Объектом, Декларативным Объектом не в режиме Реального Времени или Несвязанным Декларативным Объектом.

[1383] В другом варианте осуществления настоящего изобретения, сначала, третий модуль 101030 может уведомлять второе устройство о том, что изменился URL и имя приложения-компаньона. Здесь, приложение-компаньон может означать приложение, которое зависит от приложения, которое исполняется в первом устройстве. Приложение-компаньон может быть одним из приложений второго экрана. Вследствие этого, URL и имя приложения-компаньона могут быть доставлены второму устройству и приложение-компаньон может быть доставлено второму устройству, используя прокси-сервер HTTP. На этот раз, прокси-сервер HTTP может быть сгенерирован используя услугу прокси-сервера HTTP. В данном варианте осуществления, второе устройство может использовать действие GetAppURL услуги AppURL первого устройства. Услуга AppURL и действие GetAppURL были описаны выше. Услуга AppURL может быть одной из услуг поддержки второго экрана.

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

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

[1386] Здесь, второе устройство может быть описанным выше устройством второго экрана.

[1387] Первый модуль 102010 может принимать сообщение обнаружения, запрашивать описания услуги и принимать ответ по ним. Здесь, первый модуль 102010 может быть модулем инфраструктуры UPnP в устройстве второго экрана.

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

[1389] Первый модуль 102010 может быть выполнен с возможностью отправки запроса в отношении описаний услуг поддержки второго экрана первому устройству. Первый модуль 102010 может запрашивать описания услуги поддержки второго экрана, предоставляемой первым устройством, у первого устройства. Данная операция может быть выполнена для обнаружения устройства.

[1390] Первый модуль 102010 может быть выполнен с возможностью приема ответа с описаниями от первого устройства. Первый модуль 102010 может принимать описания услуги в качестве ответа на отправленный запрос. Первое устройство может передавать описания его услуги приложению второго экрана. Описания могут быть приняты. Данная операция может быть выполнена для обнаружения устройства.

[1391] Второй модуль 102020 может получать доступ к услуге прокси-сервера HTTP и принимать файлы через прокси-сервер HTTP. Второй модуль 102020 может быть описанной выше Подсистемой Сетевого Протокола.

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

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

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

[1395] В другом варианте осуществления настоящего изобретения, второй модуль 102020 может принимать URL прокси-сервера HTTP от первого устройства перед тем, как приложение второго экрана принимает файлы. Приложение второго экрана может использовать действие GetProxyURL услуги прокси-сервера HTTP первого устройства. Услуга прокси-сервера HTTP и действие GetProxyURL были описаны выше.

[1396] В другом варианте осуществления настоящего изобретения, второй модуль 102020 может получать доступ к услуге триггера, используя принятые описания, и принимать триггер от первого устройства. Здесь, услуга триггера может быть одной из услуг поддержки второго экрана. Триггер был описан выше. Принятый триггер может быть применен к приложению во втором устройстве в качестве описанного выше триггера координаты времени или триггера активации. Соответственно, существует возможность исполнения события приложения в конкретное время.

[1397] В другом варианте осуществления настоящего изобретения, приложение может быть Декларативным Объектом, Триггерным Декларативным Объектом, Декларативным Объектом не в режиме Реального Времени или Несвязанным Декларативным Объектом.

[1398] В другом варианте осуществления настоящего изобретения, сначала, второй модуль 102020 может принимать уведомление об изменении URL и имени приложения-компаньона. Здесь, приложение-компаньон может означать приложение, которое зависит от приложения, которое исполняется в первом устройстве. Приложение-компаньон может быть одним из приложений второго экрана. Вследствие этого, второй модуль 102020 может принимать URL и имя приложения-компаньона и принимать приложение-компаньон, используя прокси-сервер HTTP. На этот раз, прокси-сервер HTTP может быть сгенерирован, используя услугу прокси-сервера HTTP. В данном варианте осуществления, второе устройство может использовать действие GetAppURL услуги AppURL первого устройства. Услуга AppURL и действие GetAppURL были описаны выше. Услуга AppURL может быть одной из услуг поддержки второго экрана.

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

[1399] Варианты осуществления были описаны в предпочтительном варианте осуществления изобретения.

Промышленная применимость

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

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

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

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

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

3. Способ по п. 1, в котором этап, на котором доставляют файлы, включает в себя этап, на котором: доставляют URL для прокси-сервера HTTP приложению второго экрана.

4. Способ по п. 1, в котором файлы включают в себя приложения.

5. Способ по п. 1, в котором приложение является Декларативным Объектом, Триггерным Декларативным Объектом, Декларативным Объектом не в режиме Реального Времени или Несвязанным Декларативным Объектом.

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

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

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

9. Способ по п. 7, в котором этап, на котором принимают файлы, включает в себя этап, на котором: принимают URL для прокси-сервера HTTP от первичного устройства.

10. Способ по п. 7, в котором файлы включают в себя приложения.

11. Способ по п. 7, в котором приложение является Декларативным Объектом, Триггерным Декларативным Объектом, Декларативным Объектом не в режиме Реального Времени или Несвязанным Декларативным Объектом.

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

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

14. Устройство по п. 13, в котором первый модуль дополнительно принимает сообщение поиска для поиска устройств, которые предлагают услуги поддержки второго экрана.

15. Устройство по п. 13, в котором третий модуль дополнительно доставляет URL для прокси-сервера HTTP приложению второго экрана.

16. Устройство по п. 13, при этом файлы включают в себя приложения.

17. Устройство по п. 13, в котором приложение является Декларативным Объектом, Триггерным Декларативным Объектом, Декларативным Объектом не в режиме Реального Времени или Несвязанным Декларативным Объектом.

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

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

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

21. Устройство по п. 19, в котором второй модуль дополнительно принимает URL для прокси-сервера HTTP от первичного устройства.

22. Устройство по п. 19, в котором файлы включают в себя приложения.

23. Устройство по п. 19, в котором приложение является Декларативным Объектом, Триггерным Декларативным Объектом, Декларативным Объектом не в режиме Реального Времени или Несвязанным Декларативным Объектом.

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