MX2015004659A

MX2015004659A - Aparato y metodo para procesar un servicio interactivo.

Info

Publication number: MX2015004659A
Application number: MX2015004659A
Authority: MX
Inventors: Sejin Oh; Kyoungsoo Moon; Seungjoo An; Jinpil Kim; Kyungho Kim; Minsoo Lee; Jangwoong Park; Seungryul Yang; Janghun Bae; Jaekoo Lee; Younghwan Kwon; Hyeonjae Lee
Original assignee: Lg Electronics Inc
Priority date: 2012-10-18
Filing date: 2013-10-17
Publication date: 2015-08-07
Also published as: EP2910030A4; US20150058905A1; KR20150073987A; JP6133997B2; CA2887653A1; EP2910029A1; JP2016503599A; CN104737549B; CN104737549A; EP2910030B1; MX346770B; US20150026743A1; WO2014062018A1; CA2887659A1; EP2910029B1; US20140115644A1; CA2887659C; MX2015004730A; US9578391B2; US20140115060A1

Abstract

Se describe un método de procesar un servicio interactivo y un aparato del mismo. La presente invención incluye enviar un mensaje de descubrimiento a una segunda aplicación de pantalla, recibir una solicitud para las descripciones de los servicios de soporte de la segunda pantalla, enviar una respuesta con las descripciones, recibir un disparador, y entregar el disparador al segundo dispositivo usando un servicio del disparador.

Description

APARATO Y MÉTODO PARA PROCESAR UN SERVICIO INTERACTIVO CAMPO TÉCNICO La presente invención se refiere a un método y aparato para proporcionar, recibir y procesar un servicio de radiodifusión, y más particularmente, a un método y aparato para proporcionar un servicio suplementario relacionado a un contenido de radiodifusión.

ARTE ANTECEDENTE Las primeras Televisiones aparecieron a finales del siglo diecinueve, y se han vuelto el aparato de suministro de información más popular ya que a finales del siglo veinte se ha desarrollado continuamente un método o diseño de visualización en pantalla de los mismos. Sin embargo, las Televisiones permiten generalmente a los espectadores recibir información unidireccional desde una estación de radiodifusión. Tales limitaciones de las televisiones se han vuelto problemáticas conforme los ordenadores personales (PCs) y el internet han entrado en uso generalizado desde 1990. Por lo tanto, las Televisiones se han desarrollado para proporcionar un servicio interactivo.

Sin embargo, actualmente, no hay sistema que proporcione un servicio interactivo entre un contenido del proveedor y uno del espectador. En particular, para proporcionar tal servicio interactivo, hay una necesidad de un método de ejecutar una aplicación relacionada al contenido de radiodifusión, que se transmite actualmente, en un tiempo especifico y que proporciona información relacionada a un espectador a través del procesamiento de información especial.

DESCRIPCIÓN DE LA INVENCIÓN Problema Téenico Un objetivo de la presente invención ideado para resolver el problema se encuentra en la información suplementaria relacionada al contenido de radiodifusión en un tiempo apropiado durante un periodo cuando se reproduce el contenido de radiodifusión.

Solución al Problema El objetivo de la presente invención se puede lograr por proporcionar un método de procesar un servicio interactivo en un primer dispositivo que incluye, enviar un mensaje de descubrimiento a una segunda aplicación en pantalla que se ejecuta en un segundo dispositivo, en donde el mensaje de descubrimiento anuncia los segundos servicios de soporte en pantalla que puede proporcionar el primer dispositivo, recibir una solicitud para las descripciones de los segundos servicios de soporte en pantalla desde la segunda aplicación en pantalla, enviar una respuesta con las descripciones a la segunda aplicación en pantalla, recibir un disparador desde un flujo de radiodifusión o un servidor de internet y suministrar el disparador al segundo dispositivo que usa un servicio del disparador, en donde el servicio del disparador es uno de los segundos servicios de soporte en pantalla, en donde el servicio del disparador es para suministrar el disparador, en donde el disparador es un elemento de señalización cuya función es identificar la señalización y estabilización del tiempo de emisión de los eventos interactivos dirigidos a aplicaciones para un segmento descrito por una tabla del parámetro de aplicación, en donde el disparador es uno de un disparador de tiempo base, un disparador de activación, un disparador de interacción o un disparador de cambio de canal, en donde el disparador de tiempo base se usa para establecer una base de tiempo para el evento, en donde el disparador de activación ajusta un tiempo de activación para el evento, en donde el disparador de interacción se usa para los modelos de interacción diferentes de un modelo de interacción de Objetivo Declarativo Disparado, en donde se suministra el disparador de cambio de canal cada vez que se cambia un canal.

Preferiblemente, el método además comprende, recibir un mensaje de búsqueda para buscar dispositivos que incluyen el primer dispositivo que ofrece los segundos servicios de soporte en pantalla antes de enviar el mensaje de descubrimiento.

Preferiblemente, el disparador de servicio ofrece una opción de flujo sin filtrar, y la opción de flujo sin filtrar es una opción que suministra todos los tipos del disparador.

Preferiblemente, el primer dispositivo suministra todos los tipos del disparador tan pronto como el disparador se recibe por el primer dispositivo.

Preferiblemente, el suministro del disparador incluye, combinar información desde el disparador de activación con información desde la tabla del parámetro de aplicación que genera un disparador de activación aumentado y que envía el disparador de activación aumentada generado a la segunda aplicación en pantalla.

Preferiblemente, el disparador de servicio ofrece una opción de flujo filtrado, y la opción de flujo filtrado es una opción que suministra el disparador que es uno del disparador de activación aumentada, del disparador de interacción o del disparador de cambio de canal.

Preferiblemente, el disparador de activación aumentada incluye una información de la URL de aplicación que tiene el mismo valor con un elemento de la URL de un elemento de aplicación en la tabla del parámetro de aplicación, el elemento de la URL identifica un archivo que es parte de la aplicación, y el elemento de aplicación se identifica por el disparador de activación.

Preferiblemente, el disparador de activación aumentada además incluye una información del evento que representa un elemento del evento en la tabla del parámetro de la aplicación, en donde el elemento del evento identificado por el disparador de activación representa el evento para la aplicación, en donde la información del evento incluye una información de acción que tiene el mismo valor con un atributo de acción del elemento del evento identificado por el disparador de activación, y en donde el atributo de acción indica el tipo de una acción a aplicar cuando se activa el evento.

Preferiblemente, el primer dispositivo suministra el disparador de activación aumentada en el tiempo de activación del disparador de activación aumentada, en donde el primer dispositivo suministra el disparador de interacción cuando el disparador de interacción se recibe por el primer dispositivo, y en donde el primer dispositivo suministra el disparador de cambio de canal cuando se cambia el canal.

En otro aspecto de la presente invención, aquí se proporciona un método de procesar un servicio interactivo en una segunda aplicación en pantalla que se ejecuta en un segundo dispositivo, que incluye recibir un mensaje de descubrimiento desde un primer dispositivo, en donde el mensaje de descubrimiento anuncia los segundos servicios de soporte en pantalla que el primer dispositivo puede proporcionar, enviar una solicitud para las descripciones de los segundos servicios de soporte en pantalla al primer dispositivo, recibir una respuesta con las descripciones desde el primer dispositivo, acceder a un disparador de servicio que usa información dada en las descripciones y recibir un disparador desde el primer dispositivo que usa el disparador de servicio, en donde el servicio del disparador es uno de los segundos servicios de soporte en pantalla, en donde el disparador es un elemento de señalización cuya función es identificar la señalización y estabilización del tiempo de emisión de eventos interactivos dirigidos a aplicaciones por un segmento descrito por una tabla del parámetro de la aplicación, en donde el disparador es uno de un disparador de tiempo base, un disparador de activación, un disparador de interacción o un disparador de cambio de canal, en donde el disparador de tiempo base se usa para estabilizar una base de tiempo para el evento, en donde el disparador de activación establece un tiempo de activación para el evento, en donde se usa el disparador de interacción para los modelos de interacción diferentes de un modelo de interacción de Objetivo Declarativo Disparado, en donde se suministra el disparador de cambio de canal cada vez que se cambia un canal.

Preferiblemente, el método además comprende, multidifusión de un mensaje de búsqueda para buscar dispositivos que incluyen el primer dispositivo que ofrece los segundos servicios de soporte en pantalla antes de recibir el mensaje de descubrimiento.

Preferiblemente, el servicio del disparador ofrece una opción de flujo sin filtrar, y la opción de flujo sin filtrar es una opción que suministra todos los tipos del disparador.

Preferiblemente, todos los tipos del disparador se suministran tan pronto como sea posible.

Preferiblemente, la recepción del disparador incluye, recibir un disparador de activación aumentada generado por combinar información desde el disparador de activación con información desde la tabla del parámetro de la aplicación.

Preferiblemente, el servicio del disparador ofrece una opción de flujo filtrado, y la opción de flujo filtrado es una opción que suministra el disparador que es uno del disparador de activación aumentada, el disparador de interacción o el disparador de cambio de canal.

Preferiblemente, el disparador de activación aumentada incluye una información URL de aplicación que tiene el mismo valor con un elemento URL de un elemento de aplicación en la tabla del parámetro de la aplicación, en donde elemento URL identifica un archivo que es parte de la aplicación, y en donde se identifica el elemento de aplicación por el disparador de activación.

Preferiblemente, el disparador de activación aumentada se suministra en el tiempo de activación del disparador de activación aumentada, el disparador de interacción se suministra tan pronto como sea posible, y el disparador de cambio de canal se suministra cuando se cambia el canal.

En otro aspecto de la presente invención, aquí se proporciona un aparato para procesar un servicio interactivo como un primer dispositivo que incluye un primer módulo configurado para recibir un disparador desde un flujo de radiodifusión o desde un servidor de internet y un segundo módulo configurado para enviar un mensaje de descubrimiento a una segunda aplicación en pantalla que se ejecuta en un segundo dispositivo, en donde el mensaje de descubrimiento anuncia los segundos servicios de soporte en pantalla que puede proporcionar el primer dispositivo, recibir una solicitud para las descripciones de los segundos servicios de soporte en pantalla desde la segunda aplicación en pantalla, enviar una respuesta con las descripciones a la segunda aplicación en pantalla, y suministrar el disparador al segundo disparador usando un servicio del disparador, en donde el servicio del disparador es uno de los segundos servicios de soporte en pantalla, en donde el disparador de servicio es para suministrar el disparador, en donde el disparador es un elemento de señalización cuya función es identificar la señalización y estabilización de tiempo de emisión de eventos interactivos dirigidos a aplicaciones para un segmento descrito por una tabla del parámetro de la aplicación, en donde el disparador es uno de un disparador de tiempo base, un disparador de activación, un disparador de interacción o un disparador de interacción o un disparador de cambio de canal, en donde el disparador de tiempo base se usa para establecer una base de tiempo para el evento, en donde el disparador de activación ajusta un tiempo de activación para el evento, en donde el disparador de interacción se usa para modelos de interacción otros que un modelo de interacción de Objetivo Declarativo Disparado, en donde el disparador de cambio de canal se suministra cada vez que se cambia un canal.

Preferiblemente, el segundo módulo además se configura para recibir un mensaje de búsqueda para buscar dispositivos que incluyen el primer dispositivo que ofrece lo segundos servicios de soporte en pantalla antes de enviar el mensaje de descubrimiento.

Preferiblemente, el servicio del disparador ofrece una opción de flujo sin filtrar, y en donde la opción de flujo sin filtrar es una opción que suministra todos los tipos del disparador.

Preferiblemente, el segundo módulo suministra todos los tipos del disparador tan pronto como el disparador se recibe por el primer módulo.

Preferiblemente, el segundo módulo además configurado para combinar información desde el disparador de activación con información desde la tabla del parámetro de aplicación para generar un disparador de activación aumentada y enviar el disparador de activación aumentada generada a la segunda aplicación en pantalla.

Preferiblemente, el servicio del disparador ofrece una opción de flujo filtrado, y en donde la opción de flujo filtrado es una opción que suministra el disparador que es uno del disparador de activación aumentada, el disparador de interacción o el disparador de cambio de canal.

Preferiblemente, el disparador de activación aumentada incluye una información de la URL de aplicación que tiene el mismo valor con un elemento de la URL de un elemento de aplicación en la tabla del parámetro de la aplicación, en donde el elemento de la URL identifica un archivo que es parte de la aplicación, y en donde el elemento de aplicación se identifica por el disparador de activación.

Preferiblemente, el segundo módulo suministra el disparador de activación aumentada en el tiempo de activación del disparador de activación aumentada, el segundo módulo suministra el disparador de interacción cuando el disparador de interacción se recibe por el primer módulo, y el segundo módulo suministra el disparador de cambio de canal cuando se cambia el canal.

En otro aspecto de la presente invención, se proporciona aquí un aparato para procesar un servicio interactivo como una segunda aplicación en pantalla que se ejecuta en un segundo dispositivo que incluye un primer módulo configurado para recibir un mensaje de descubrimiento desde un primer dispositivo, en donde el mensaje de descubrimiento anuncia los segundos servicios de soporte en pantalla que el primer dispositivo puede proporcionar, enviar una solicitud para las descripciones de los segundos servicios de soporte en pantalla al primer dispositivo, y recibir una respuesta con las descripciones desde el primer dispositivo y un segundo módulo configurado para acceder a un disparador de servicio que usa información dada en las descripciones, y recibir un disparador desde el primer dispositivo que usa el disparador de servicio, en donde el disparador de servicio es uno de los segundos servicios de soporte en pantalla, en donde el disparador es un elemento de señalización cuya función es identificar la señalización y estabilización del tiempo de emisión de eventos interactivos dirigidos a aplicaciones para un segmento descrito por una tabla del parámetro de la aplicación, en donde el disparador es uno de un disparador de tiempo base, un disparador de activación, un disparador de interacción o un disparador de cambio de canal, en donde la base de tiempo se usa para establecer una base de tiempo para el evento, en donde el disparador de activación ajusta un tiempo de activación para el evento, en donde el disparador de interacción se usa para los modelos de interacción diferentes de un modelo de interacción Objetivo Declarativo Disparado, en donde el disparador de cambio de canal se suministra cada vez que se cambia un canal.

Preferiblemente, el primer módulo además configurado para multidifusión de un mensaje de búsqueda para buscar dispositivos que incluye el primer dispositivo que ofrece lo segundos servicios de soporte en pantalla antes de recibir el mensaje de descubrimiento.

Preferiblemente, el segundo módulo además configurado para recibir un disparador de activación aumentada por combinar información desde el disparador de activación con información desde la tabla de parámetro de la aplicación.

Preferiblemente, el disparador de activación aumentada incluye una información de la URL de aplicación que tiene el mismo valor con un elemento de la URL de un elemento de aplicación en la tabla del parámetro de aplicación, en donde el elemento de la URL identifica un archivo que es parte de la aplicación, y en donde el elemento de aplicación se identifica por el disparador de activación.

Preferiblemente, el disparador de activación aumentada además incluye una información del evento que representa un elemento del evento en la tabla del parámetro de aplicación, en donde el elemento del evento identificado por el disparador de activación representa el evento para la aplicación, en donde la información del evento incluye una información de acción que tiene el mismo valor con un atributo de acción del elemento del evento identificado por el disparador de activación, y en donde el atributo de acción indica el tipo de una acción a aplicar cuando se activa el evento.

Preferiblemente, el disparador de activación aumentada se suministra en el tiempo de activación del disparador de activación aumentada, en donde el disparador de interacción se suministra tan pronto como sea posible, y en donde el disparador de cambio de canal se suministra cuando se cambia el canal.

Se entiende que tanto la descripción general siguiente y la descripción detallada siguiente de la presente invención son ejemplares y explicativas, y se pretende proporcionar explicación adicional de la invención como se reivindica.

Efectos Ventajosos de la Invención De acuerdo a la presente invención, es posible proporcionar información suplementaria relacionada al contenido de radiodifusión que usa un sistema de radiodifusión convencional.

De acuerdo a la presente invención, es posible detectar un tiempo en que la información suplementaria relacionada al contenido de radiodifusión necesita ser proyectado y provisto en la información suplementaria a un usuario en un tiempo apropiado.

De acuerdo a la presente invención, es posible proporcionar información suplementaria relacionada al contenido de radiodifusión a un segundo dispositivo en pantalla.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Los dibujos adjuntos, los cuales se incluyen para proporcionar un entendimiento adicional de la invención, ilustran modalidades de la invención y junto con el servicio de descripción explicar el principio de la invención.

En los dibujos: La figura 1 es un diagrama que muestra una modalidad de un flujo de radiodifusión tipica; La figura 2 es un diagrama que muestra una modalidad del tiempo del disparador en el caso del contenido pre-producido.

La figura 3 es un diagrama que muestra una modalidad del tiempo del disparador en caso del contenido en vivo; La figura 4 es un diagrama que muestra una modalidad de la sintaxis del disparador; La figura 5 es un diagrama que muestra una modalidad de una tabla del parámetro TDO; La figura 6 es un diagrama que muestra una modalidad de una tabla del parámetro TDO; La figura 7 es un diagrama que muestra el significado de los valores de atributo de "Frecuencia de Uso"; La figura 8 es un diagrama que muestra el significado de valores de atributo de "destino": La figura 9 es un diagrama que muestra una modalidad de la sintaxis de forma binaria de una Tabla de los Parámetros TDO; La figura 10 es un diagrama que muestra una modalidad de * la sintaxis de la forma binaria de una Tabla de los Parámetros TDO; La figura 11 es un diagrama que muestra una modalidad de la sintaxis de la forma binaria de una Tabla de los Parámetros TDO; La figura 12 es un diagrama que muestra una modalidad de la sintaxis de la forma binaria de una Tabla de los Parámetros TDO; La figura 13 es un diagrama que muestra una modalidad de la sintaxis de la forma binaria de una Tabla de los Parámetros TDO; La figura 14 es un diagrama que muestra una modalidad de una estructura de tabla de mensaje de activación; La figura 15 es un diagrama que muestra una modalidad de un diagrama estructural de la Lista de la URL; La figura 16 es un diagrama que muestra una modalidad del formato binario para las secciones privadas que contienen TPTs; La figura 17 es un diagrama que muestra una modalidad de una lista de las URLs codificadas como un documento XML; La figura 18 es un diagrama que muestra una modalidad de añadirDisparadorEventoDetector; La figura 19 es un diagrama que muestra una modalidad de removerDisparadorEventoDetector; La figura 20 es un diagrama que muestra una modalidad de la definición del tipo de EventoDetector; La figura 21 es un diagrama que muestra una modalidad de la definición del tipo de DisparadorEvento; La figura 22 es un diagrama que muestra una modalidad de una arquitectura para un enfoque WM; La figura 23 es un diagrama que muestra una modalidad de una arquitectura para un enfoque FP; La figura 24 es un diagrama que muestra una modalidad de activación estática en un caso ACR de solicitud/respuesta; La figura 25 es un diagrama que muestra una modalidad de activación estática en un caso ACR de solicitud/respuesta; La figura 26 es un diagrama que muestra una modalidad de activación dinámica en un caso de solicitud/respuesta; La figura 27 es un diagrama que muestra una modalidad de activación dinámica en un caso de solicitud/respuesta; La figura 28 es un diagrama que muestra una modalidad de arquitectura para las activaciones del servidor ACR; La figura 29 es un diagrama que muestra una modalidad de los disparadores de activación en el caso (b) y el caso (a) sin FinTiempo; La figura 30 es un diagrama que muestra una modalidad de los disparadores de activación en el caso (b) y el caso (a) sin FinTiempo; La figura 31 es un diagrama que muestra una modalidad de los disparadores de activación en el caso (a) sin FinTiempo; La figura 32 es un diagrama que muestra una modalidad de los disparadores de activación en el caso (a) sin FinTiempo; La figura 33 es un diagrama que muestra una modalidad de los disparadores de activación para el caso (c); La figura 34 es un diagrama que muestra una modalidad de los disparadores de activación para el caso (c); La figura 35 es un diagrama que muestra una modalidad de los disparadores de activación dinámica suministrados en el último minuto; La figura 36 es un diagrama que muestra una modalidad de los disparadores de activación dinámica suministrados en el último minuto; La figura 37 es un diagrama de secuencia entre una ACR del cliente y otros servidores en un caso de solicitud/respuesta; La figura 38 es un diagrama de secuencia entre una ACR del cliente y otros servidores en un caso ACR por eventos; La figura 39 es un diagrama que muestra una modalidad de una Lista de Acción de un Servicio de Cliente RemotoUI UPnP; La figura 40 es un diagrama que muestra una modalidad de un Servicio de Cliente RemotoUI UPnP; La figura 41 es un diagrama que muestra una modalidad de un Disparador en el Servicio DTVCC Número 6; La figura 42 es un diagrama que muestra una modalidad de una arquitectura de sistema para un segundo escenario en pantalla; La figura 43 es un diagrama que muestra una modalidad de topología entre un Receptor ATSC 2.0 y una segunda pantalla (Conexión Directa); La figura 44 es un diagrama que muestra una modalidad de la topología entre un Receptor ATSC 2.0 y una segunda pantalla (Conexión Indirecta); La figura 45 es un diagrama que muestra una Capa de Software de una Segunda Aplicación del Servicio de la Pantalla; La figura 46 es un diagrama que muestra una Capa de Software de una Segunda Aplicación de Servicio de la Pantalla.

La figura 47 es un diagrama que muestra una tabla que muestra una diferencia entre una orden de transmisión de acuerdo a la administración del Ciclo de Vida de la Segunda Aplicación en pantalla y a los datos transmitidos; La figura 48 es un diagrama que muestra el concepto operacional de un modelo de Ejecución Centralizado; La figura 49 es un diagrama que muestra el flujo de Ínter funcionamiento entre un modelo de Ejecución Centralizado basado en el receptor y una segunda pantalla; La figura 50 es un diagrama que muestra una modalidad de un método de, en un receptor, notificar un segundo dispositivo en pantalla de la información UI; La figura 51 es un diagrama que muestra una modalidad de un método de, en un receptor, notificar un segundo dispositivo en pantalla de información UI; La figura 52 es un diagrama que muestra una modalidad de Señalización de Radiodifusión para un Servicio del Servidor RemotoUI; La figura 53 es un diagrama que muestra el concepto operacional de un modelo de Ejecución Distribuido; La figura 54 es un diagrama que muestra el flujo de ínter funcionamiento entre un modelo de Ejecución Distribuido basado en el receptor y en una segunda pantalla; La figura 55 es un diagrama que muestra el flujo de ínter funcionamiento entre un modelo de Ejecución Distribuida basado en el receptor y en una segunda pantalla; La figura 56 es un diagrama que muestra una modalidad de un método de, en un receptor, notificar un segundo dispositivo en pantalla de TDO e información del Evento; La figura 57 es un diagrama que muestra una modalidad de un método de, en un segundo dispositivo en pantalla, acceder un TPT y la Segunda Aplicación en pantalla; La figura 58 es un diagrama que muestra una modalidad de un método de, en un segundo dispositivo en pantalla, acceder un TPT y la Segunda Aplicación en pantalla; La figura 59 es un diagrama que muestra otra modalidad de Señalización de Radiodifusión para un servicio del servidor RemotoUI; La figura 60 es un diagrama que muestra una modalidad del Descubrimiento del Dispositivo y el Intercambio de Capacidad del Dispositivo para un Segundo Servicio de la Pantalla; La figura 61 es un diagrama que muestra una modalidad del Esquema XML del DispositivoPerfil del Foro UPnP; La figura 62 es un diagrama que muestra una modalidad de un perfil del dispositivo de un Segundo dispositivo en pantalla; La figura 63 es un diagrama que muestra una modalidad de una descripción de Protocololnformación para un Segundo Servicio en pantalla; La figura 64 es un diagrama que muestra una modalidad de UIListado mientras que una acción de AñadirUILlistado y una acción de RemotoUIListado se ejecutan en un segundo dispositivo en pantalla; La figura 65 es un diagrama que muestra una modalidad de Señalización de Unidifusión para un servicio del cliente RemotoUI ; La figura 66 es un diagrama que muestra una modalidad de Señalización de Unidifusión para un Servicio del Cliente RemotoUI; La figura 67 es un diagrama que muestra una modalidad de Señalización de Unidifusión para un Servicio del Cliente RemotoUI; La figura 68 es un diagrama que muestra una modalidad de información de "Eventolnformación" dirigida a un segundo dispositivo en pantalla por una acción de ProcesoEntrada; La figura 69 es un diagrama que muestra la configuración entre un receptor y un segundo dispositivo en pantalla; La figura 70 es un diagrama que muestra una modalidad de Tipos de Servicio e IDs de Servicio de los Servicios; La figura 71 es un diagrama que muestra el concepto operacional de un servicio de suministra del disparador; La figura 72 es un diagrama que muestra una modalidad de un proceso de generar un disparador de activación expandido; La figura 73 es un diagrama que muestra una modalidad de una Descripción de Esquema XML para un Disparador de Activación Aumentada; La figura 74 es un diagrama que muestra una modalidad de una Descripción de Esquema XML para los Disparadores que no se aumentan; La figura 75 es un diagrama que muestra una modalidad de un formato de un Disparador de Activación Aumentada; La figura 76 es un diagrama que muestra una modalidad de un formato de un Disparador de Activación Aumentada; La figura 77 es un diagrama que muestra una modalidad de un formato de un Disparador de Activación Aumentada; La figura 78 es un diagrama que muestra una modalidad de un formato de un Disparador de Activación Aumentada; La figura 79 es un diagrama que muestra una modalidad de las variables de estado del disparador de servicio; La figura 80 es un diagrama que muestra una modalidad de las variables de estado del disparador de servicio; La figura 81 es un diagrama que muestra una modalidad de Acciones de Disparador de servicio; La figura 82 es un diagrama que muestra una modalidad del Argumento de una Acción de RecibirUltimaSinfiltrarDisparador; La figura 83 es un diagrama que muestra una modalidad del Argumento de una Acción de RecibirUltimaFiltradaDisparador; La figura 84 es un diagrama que muestra una modalidad de las Acciones del Disparador de servicio; La figura 85 es un diagrama que muestra una modalidad de una operación de una segunda pantalla cuando adquiere un disparador mediante un servicio de suministra del disparador; La figura 86 es un diagrama que muestra el concepto operacional de un servicio de suministra del disparador; La figura 87 es un diagrama que muestra las Variables de Estado del Servicio AplicaciónURL; La figura 88 es un diagrama que muestra una Acción de Servicio AplicaciónURL; La figura 89 es un diagrama que muestra Argumentos de una Acción de RecibirAplicaciónURL; La figura 90 es un diagrama que muestra el concepto operacional de un servicio del Servidor HTTP Proxy; La figura 91 es un diagrama que muestra una modalidad de una Variable de Estado del Servicio del Servidor Proxy; La figura 92 es un diagrama que muestra una modalidad de una Acción del Servicio del Servidor Proxy; La figura 93 es un diagrama que muestra una modalidad de Argumentos de una Acción de RecibirProxyURL; La figura 94 es un diagrama que muestra una modalidad de AplicaciónArchivos(); La figura 95 es un diagrama que muestra una modalidad de una Arquitectura del Segundo Dispositivo en pantalla; La figura 96 es un diagrama que muestra una modalidad de la estructura simplificada de un receptor; La figura 97 es un diagrama que muestra una modalidad de la estructura de un segundo dispositivo en pantalla; La figura 98 es un diagrama que muestra un segundo escenario del servicio en pantalla; La figura 99 es un diagrama que muestra un método de procesar un servicio interactivo en un primer dispositivo; La figura 100 es un diagrama que muestra un método de procesamiento de un servicio interactivo en una segunda aplicación en pantalla que se ejecuta en un segundo dispositivo; La figura 101 es un diagrama que muestra una modalidad de un aparato para procesar un servicio interactivo como un primer dispositivo, y La figura 102 es un diagrama que muestra una modalidad de un aparato para procesar un servicio interactivo como una segunda aplicación en pantalla se ejecuta en un segundo dispositivo.

MEJOR MODO PARA LLEVAR A CABO LA INVENCIÓN Aunque los términos usados en la presente invención se seleccionan de términos conocidos y usados generalmente, los términos usados aquí pueden ser variables que dependen de la intención o costumbres del operador en el arte, la apariencia de una nueva teenología, o los similares. Además, algunos de los términos mencionados en la descripción de la presente invención se han seleccionado por el solicitante a su discreción, los significados detallados de los cuales se describen en las partes relevantes de la descripción en la misma. Además, se requiere que se entienda la presente invención, no simplemente por los términos actuales usados sino por los significados de cada término que cae dentro.

En la presente especificación, el término tiempo en los medios representa un parámetro que referencia un punto en la emisión de un Contenidoarticulo de audio/video o audio. La ACR representa el Reconocimiento de Contenido Automático. La AMT representa la Tabla de Mensajes de Activación. API representa la Interface de Programación de Aplicación. La DAE representa el Ambiente de Aplicación Declarativa. El DO representa el Objetivo Declarativo. FLUTE representa Suministro de Archivos sobre el Transporte Unidireccional. El GPS representa el Sistema de Posicionamiento Global. HTTP representa el Protocolo de Transferencia de Hipertexto. IP representa el Protocolo de Internet. IPVT representa la Televisión del Protocolo de Internet. iTV representa Televisor Interactivo. MIME representa Tipo de Medios de Internet. NDO representa Objeto Declarativo NRT. NRT representa en Tiempo No Real. SMT representa Tabla de Mapa de Servicio. SSC representa Canal de Señalización de Servicio. TDO representa Objetivo Declarativo del Disparador. TPT representa la Tabla de los Parámetros TDO. UDO representa Objetivo Declarativo Sin Consolidar. UPnP representa Conector y Reproductor del Usuario. URI representa Identificador de Recurso Uniforme. URL representa el Localizador de Recurso Uniforme. XML representa el Lenguaje Extensible de Marcado. TFT representa la Tabla de Fragmento de Texto. Los detalles de los mismos se describirán a continuación.

En esta especificación, DO, TDO, NDO, UDO, Enlace y Aplicación Empaquetada tienen los siguientes significados.

DO (Objetivo Declarativo) puede ser una colección que constituye una aplicación interactiva. (Por ejemplo, HTML, JavaScript, CSS, XML y archivos multimedia) El término "Objetivo Declarativo Disparado" (TDO) se usa para designar un Objetivo Declarativo que se ha iniciado por un Disparador en un servicio de datos adjuntos interactivos Disparados, o un DO que se ha iniciado por un DO que se ha iniciado por un Disparador, y asi sucesivamente iterativamente.

El término "Objetivo Declarativo NRT" (NDO) se usa para designar un Objetivo Declarativo que se ha iniciado como parte de un servicio NRT que no es un servicio de datos interactivo disparado.

El término "Objetivo Declarativo Sin Consolidar" (UDO) se usa para designar un Objetivo Declarativo que no se une a un servicio, tal como una Aplicación Empaquetada o un DO iniciado por un enlace, o un DO que se ha enlazado por tal DO, y asi sucesivamente iterativamente.

El "Enlace" es una URL provista por el radiodifusor que apunta a un sitio de red que proporciona información sobre la linea o la funcionalidad relacionada a la programación del televisor actual o al servicio NRT.

La "Aplicación Empaquetada" o "App Empaquetada" es un Objetivo Declarativo (DO) provisto por el radiodifusor que proporciona información o funcionalidad la cual el radiodifusor quiere ofrecer a los espectadores, y que se empaqueta en un solo archivo para que los espectadores se descargan e instalan.

Los detalles del mismo se describirán a continuación.

En esta especificación, un mensaje de tiempo base incluye un disparador de tiempo base y un equivalente del mismo. En consecuencia, el término "mensaje de tiempo base" se puede usar intercambiablemente con el término "disparador de tiempo base".

En esta especificación, un mensaje de activación incluye toda la información de suministra que hace la activación, tal como un elemento de activación en un AMT y/o un disparador de activación.

La figura 1 es un diagrama que muestra una modalidad de un flujo de radiodifusión típico.

Un flujo de radiodifusión típico incluye una secuencia de programas de televisión. Cada programa de televisión incluye una demostración subyacente, que se rompe típicamente en bloques separados por anuncios y/u otro material intersticial.

En la figura 1, el Segmento del Programa A, Adl, Ad2, el Segmento del Programa B, etcétera se incluyen secuencialmente en el flujo de radiodifusión. Los segmentos que configuran cada programa se pueden referir a ellos como contenido de programa, y los Anuncios se pueden referir a ellos como contenido intersticial.

Cada programa o pieza de material intersticial puede o podría no tener un servicio de datos adjunto interactivo asociado con él.

El término "segmento de servicio interactivo" o solo "segmento", se usará en esta especificación para referirse a una porción de un servicio adjunto interactivo que se trata por el radiodifusor como una unidad integrada. Un segmento de servicio interactivo es típicamente, pero no necesariamente, asociado con un solo programa o una sola pieza del material intersticial.

Para ejecutar tal servicio de datos adjunto interactivo, hay dos modelos: modelo de ejecución Directo y modelo (TDO) de objetivo declarativo disparado.

En el modelo de ejecución directa, un objetivo (DO) declarativo se puede iniciar automáticamente tan pronto como se selecciona el canal virtual. Este se puede comunicar sobre el Internet con un servidor de servicio para obtener las instrucciones detalladas que proporcionan las características interactivas - crear visualizaciones en locaciones específicas en la pantalla, realización de sondeos, iniciar otros Dos especializados, etcétera, todos sincronizados con el programa de audio-video.

En el modelo TDO, las señales se pueden suministrar en el flujo de radiodifusión o mediante el Internet para iniciar eventos TDO, tal como iniciar una TDO, terminar una TDO, o provocar alguna tarea por una TDO. Esos eventos se pueden iniciar en los tiempos específicos, sincronizados típicamente con el programa de audio-video. Cuando se inicia una TDO, se pueden proporcionar las características interactivas que se programan para proporcionarlas.

Un concepto básico detrás del modelo TDO es que los archivos que hacen una TDO, y los archivos de datos a usar por una TDO toman alguna acción, todos necesitan una cierta cantidad de tiempo para suministrarse a un receptor, dado su tamaño. Mientras que la experiencia del usuario de los elementos interactivos se puede escribir antes de la radiodifusión del contenido, ciertos comportamientos se deben programar cuidadosamente para coincidir con los eventos en el propio programa, por ejemplo la ocurrencia de un segmento de publicidad comercial.

El modelo TDO separa la suministra de objetivos declarativos y datos asociados, guiones, texto y gráficas desde la señalización del tiempo específico de la emisión de eventos interactivos.

El elemento que establece el tiempo de los eventos interactivos es el Disparador.

La información acerca de los TDOs usados en un segmento y los eventos TDO asociados que se inician por Disparadores se proporcionan por una estructura de dato llamada la "Tabla de Parámetros TDO" (TPT).

La figura 2 es un diagrama que muestra una modalidad del tiempo de disparo en caso del contenido pre-producido.

El disparador es un elemento de señalización cuya función es identificar la señalización y estabilización del tiempo de emisión de los eventos interactivos.

El disparador incluye un disparador de tiempo base que sirve para indicar un tiempo en los medios de un segmento relacionado a un servicio interactivo y un disparador de activación que sirve para indicar un tiempo de ocurrencia de evento de una aplicación relacionada a un servicio interactivo.

Los disparadores pueden realizar varias funciones de señalización relacionadas al tiempo en el soporte de servicios interactivos. Los disparadores pueden ser multifuncionales; que dependen de su estructura, un caso del Disparador particular puede realizar una o más de las funciones siguientes: 1. Señalar la locación de un TPT (accesible mediante una sesión FLUTE en el flujo de emisión, mediante un servidor de Internet, o ambos); 2. Indicar que el contenido interactivo para un segmento de programa próximo está disponible a ser precargado; 3. Indicar el Tiempo en los Medios actual del contenido de audio/video o de solo audio asociado; 4. Hacer referencia a un evento interactivo particular en un TPT y señala que el evento se ejecuta ahora o en un Tiempo en los Medios futuros especificados; 5. Indicar que los accesos a un servidor de Internet se deben esparcir aleatoriamente sobre un intervalo de tiempo especificado para evitar un pico en la demanda.

La figura 2 ilustra Disparadores suministrados en asociación con dos segmentos de programación. En este ejemplo, ambos segmentos se "pre-producen", significa que el contenido no es de una radiodifusión en vivo; los elementos interactivos se han añadido en la postproducción.

Como se muestra, un tiempo corto previo a la ocurrencia del segmento 1 de programación, un Disparador "precargado" se puede suministrar para permitir a los receptores una oportunidad de adquirir la TPT y el contenido interactivo asociado con el segmento 1 de programación. Si no se transmite un Disparador precargado, los receptores pueden esperar que se use el primer Disparador que ve dentro del segmento para adquirir el contenido.

Los disparadores se pueden enviar a través del segmento 1, como se muestra, para indicar el Tiempo en los Medios actual (etiquetado "m" en la figura) en relación al segmento. El suministro periódico de los Disparadores de Tiempo en los Medios puede ser necesario para permitir a los receptores que apenas están encontrando el canal para sincronizar y adquirir el contenido interactivo.

Justo previo al principio del segmento 2, un Disparador de precarga para enviar el segmento próximo.

En el caso del contenido pre-producido (no en vivo), la TPT que el receptor puede adquirir después del procesamiento del primer Disparador puede definir el tiempo de todos los elementos de la experiencia interactiva para ese segmento. Todo eso es necesario para que el receptor y el TDO emitan los elementos interactivos que puede ser el conocimiento del tiempo en los medios; la TPT puede describir los eventos interactivos en relación al Tiempo en los Medios.

La figura 3 es un diagrama que muestra una modalidad del tiempo del disparador en el caso del contenido en vivo.

Para el caso del contenido en vivo, la TPT aun contiene datos e información pertinente a diferentes eventos interactivos, sin embargo el tiempo de emisión de aquellos eventos no se puede conocer hasta que la acción en el programa se desarrolla durante la radiodifusión. Para el caso en vivo, se utiliza la función del "tiempo del evento" del Disparador. En este modo, el Disparador puede señalar que un evento interactivo especificado es reprogramado a un nuevo valor especificado del Tiempo en los Medios. Alternativamente, el Disparador puede indicar que un cierto evento se ejecuta inmediatamente .

En la figura 3, se describirán ahora las funciones de los disparadores del segmento 3.

Un primer Disparador es un disparador precargado, el cual hace referencia a un directorio capaz de archivos del segmento 3.

Un segundo Disparador es un disparador de tiempo en los medios el cual se usa para indicar el tiempo de emisión del segmento 3.

Un tercer disparador es un disparador de resincronización de evento e indica que el evento con el eventoID = 2 en la TPT se reprograma para ocurrir en el Tiempo 240 en los Medios. El área rayada indica el intervalo de tiempo previo a 240 sobre el cual el Disparador #3 se puede suministrar a los receptores.

Un cuarto disparador es un disparador de tiempo en los medios.

Un quinto disparador es un disparador de re sincronización e indica que el evento con eventoID = 5 en la TPT se re-sincroniza para ocurrir en el Tiempo 444 en los Medios.

Un sexo y séptimo disparadores son disparadores de tiempo en los medios.

Un octavo disparador es un Disparador de evento e indica que el evento con el eventoID = 12 en la TPT se ejecuta inmediatamente .

Un noveno disparador es un Disparador de resincronización de evento, e indica que el evento con eventoID = 89 en la TPT también se re-sincroniza para ocurrir en el Tiempo 900 en los Medios.

En lo sucesivo, el ciclo de vida, se describirá el estado y el evento de cambio de estado da TDO.

Una TDO puede existir en cuatro diferentes estados: Liberado, Listo, Activo y Suspendido. Un número de diferentes factores puede hacer una transición desde un estado a otro (disparador, acción del usuario, canales de cambio, etcétera).

La TDO puede incluir los siguientes cuatro estados. Los cuatro estados son Listo, Activo, Suspendido y Liberado. El estado Listo significa que la TDO se descarga y prepara para la ejecución, pero aún no se ejecuta. El estado Activo significa que la TDO se ejecuta. El estado Suspendido significa que la TDO se suspende temporalmente desde la ejecución, con este estado guardado. El estado Liberado significa que la TDO no está Lista, Activa o Suspendida.

Los siguientes son algunos de los eventos que pueden hacer un cambio de estado para una TDO: 1. El disparador "prepara" - El dispositivo recibe un disparador (en el canal virtual primario seleccionado actualmente) que solicita que la TDO se prepare para ejecutar (asignar recursos, cargar en la memoria principal, etcétera). 2. El disparador "ejecuta"- El dispositivo recibe un disparador (en el canal virtual primario seleccionado actualmente) el cual solicita que se active la TDO. 3. El disparador "suspende"- El dispositivo recibe un disparador (en el canal virtual primario seleccionado actualmente) que dirige a la TDO a suspenderse. 4. El disparador "elimina"- el dispositivo recibe un disparador (en el canal virtual primario seleccionado actualmente) el cual dirige a la TDO a terminarse.

La figura 4 es un diagrama que muestra una modalidad de la sintaxis del disparador.

Tanto los mensajes de Activación como los mensajes a Base de Tiempo pueden tener el formato "Disparador" general bajo ciertas circunstancias de suministro.

La definición sintáctica se describe aquí usando la forma gramática Backus-Naur aumentada (ABNF, excepto que el símbolo "I" de barra vertical se usa para designar alternativas. Las reglas se separan de definiciones por un igual "=", la sangría se usa para continuar una definición de regla sobre más de una línea, las literales se cotizan con paréntesis "("y")" se usan para elementos de grupos, elementos opcionales se encierran en "["y"]" paréntesis, y los elementos pueden ser precedentes con <n>* para designar n o más repeticiones del siguiente elemento; n por defecto a 0. Y los elementos pueden preceder con <n>*<m> designado n o más repeticiones y m o menos repeticiones del siguiente elemento.

Esta sintaxis del Disparador se basa en el Identificador de Recurso Uniforme (URI): Sintaxis Genérica, excluye el <esquema> y la porción con restricciones adicionales.

El disparador puede incluir localizador_parte y términos. Los términos se pueden omitir.

El disparador puede incluir localizador_parte y términos. Los términos se pueden omitir. Si los términos están presentes, el localizador_parte y términos se pueden conectar por '?'.

El localizador_parte puede incluir una parte del nombre host y una parte trayectoria_segmentos, que se puede conectar por '/'.

El nombre del host puede incluir etiqueta de dominio y etiqueta superior, y la etiqueta de dominio se puede repetir 0 veces o más a lo largo con Esto es, el nombre del host puede incluir etiqueta de dominio repetida conectada con la etiqueta superior o incluir solo la etiqueta superior.

La etiqueta de dominio puede incluir un alfanumérico o incluir un alfanumérico o insertado repetidamente entre el alfanumérico y alfanumérico 0 veces o más.

Aquí, el alfanumérico puede significar letras o dígitos. Aquí, la letra puede ser una del alfabeto en minúsculas o del alfabeto en mayúsculas.

Aquí, alfabeto en minúsculas puede ser uno de 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, Y z· Aquí, alfabeto en mayúsculas puede ser uno de 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, y z.

Aquí, el dígito puede ser uno de 0, 1, 2, 3, 4, 5, 6, 7, 8, y 9.

El alfabeto en mayúsculas incluye una letra o incluye alfanumérico o insertado repetidamente entre la letra y el alfanumérico 0 veces o más.

La trayectoria_segmentos incluye un segmento, que es seguido por el segmento repetido 0 veces o más. En este momento, los segmentos se pueden conectar por '/'.

Aquí, el segmento incluye alfanumérico que se repite una vez o más. Los términos pueden incluir uno del evento_tiempo o medios_tiempo. Que se pueden seguir por difusión u otros. La difusión y otros se pueden omitir. Si la difusión y otros se presentan, se pueden colocar delante de la difusión y otros, y la difusión y otros se puede colocar después del evento_tiempo o medios_tiempo.

Aquí, la difusión puede incluir el dígito repetido una vez o más después de 's='.

El evento_tiempo puede incluir dígitos repetidos una vez o más después de 'e=' o incluir el hexdígito repetido una vez o más o siete veces o menos después '&t='. '&t=' y la parte posterior del mismo se pueden omitir.

Aquí, el hexdígito puede ser uno de 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e y f.

Los medios_tiempo pueden incluir hexdigitos repetidos una vez o más o menos que siete veces después 'm='.

Otros pueden incluir uno "otro" u "otro" seguido por y "otro".

Aquí, otro puede incluir resv_cmd y alfanumérico que se repite una vez o más y se conectan por '='.

Aquí, resv_cmd puede ser alfanumérico que excluye 'c', 'e', ?', 'm', 'M', 's', 'S', 't' y 'T'.

La longitud del disparador puede no exceder 52 bitios. Además, la porción del nombre del host del Disparador puede ser un nombre de dominio de Internet registrado.

Un Disparador se puede considerar incluir tres partes. <parte del nombre de dominio>/<trayectoria del directorio> [? <parámetros>] La <parte del nombre del dominio> puede ser un nombre del dominio registrado, <trayectoria del directorio> puede ser un trayectoria tal y como aparecería en una URI.

La <parte del nombre del dominio> puede referenciar un nombre del dominio de Internet registrado. La <trayectoria del directorio> puede ser una cadena de caracteres arbitraria que identifica una trayectoria del directorio bajo el control y administración de la entidad que posee los derechos sobre el nombre de dominio identificado.

En el modelo TDO, la combinación de la <parte de nombre del dominio> y el <trayectoria del directorio> pueden identificar únicamente una TPT que se puede procesar por un receptor para añadir la interactividad al contenido asociado.

La combinación de <parte de nombre del dominio> y la trayectoria del directorio> puede ser la URL de una locación de Internet donde se puede obtener la TPT para el segmento actual.

Esto es, el disparador puede identificar la TPT que usa la <parte del nombre del dominio> y el Ctrayectoria del directorio>. A través de la Cparte del nombre del dominio> y la ctrayectoria del directorio>, es posible confirmar la TPT a la que el disparador aplica. El papel realizado por aplicar el disparador a la TPT depende de los Cparámetros>.

En lo sucesivo, se describirán los Cparámetros>.

Los Cparámetros> pueden incluir uno o más del "evento_tiempo", los "medios_tiempo", o la "difusión".

Después, se describirán el "evento_tiempo", los "medios_tiempo" y la "difusión" de la sintaxis mostrada en la figura 4. evento_tiempo = "e=" l*dígito ["&t=" l*7hexdígitos] medios_tiempo = "m=" l*7hedígitos difusión = "s=m" l*digito El término "evento_tiempo" se puede usar en un disparador de Activación para identificar el evento dirigido (término "e=") y el tiempo del evento se deberá activar (término "t=").

Cuando el término "t=" es ausente, significa que el evento se deberá activar en el tiempo que el disparador llega.

Esto es, "e=", que es un término ID de evento interactivo, puede referenciar la aplicaciónID en la TPT asociada da TDO dirigido por el evento, el eventoID del evento especifico, y los datosID del elemento de Datos a usar por esta activación del evento. "t=", es un término del valor de tiempo opcional, que puede indicar un tiempo en los medios nuevo para el evento designado. Si la parte "t=" no está presente, puede significar el tiempo para el evento designado es el tiempo de llegada del Disparador.

El término de "medios_tiempo" (término "m=") se puede usar en un disparador de Tiempo base para identificar el tiempo actual relativo a la base de tiempo representada por el disparador de Tiempo base. La información del identificador de contenido (término "c=") para identificar el contenido visualizado actualmente se puede incluir además en los medios_tiempo. Para el término "c=", el modelo de ejecución directo se describirá a continuación.

Esto es, "m=", que es un término de marca de tiempo en los medios, seguido por una cadena de caracteres de 1 a 8 caracteres en longitud que representa un número hexadecimal, puede indicar el Tiempo en los Medios actual.

El término "difusión" se puede usar para indicar que cualquier acción tomada en respuesta a un disparador de Tiempo base (tal como recuperar una TPT desde un servidor) o un disparador de Activación (tal como hacer una TDO al acceso de un Servidor) deberá retrasarse una cantidad al azar de tiempo, para extender la carga de trabajo sobre el servidor.

El término "s=" puede indicar el número de segundos de tiempo sobre el cual todos los receptores deben intentar acceder al servidor de Internet identificado en el disparador. Cada receptor individual puede esperar que se derive un tiempo al azar dentro del intervalo designado y el retraso del acceso de aplicación por esa cantidad, por lo que se extiende en el tiempo del pico en demanda que puede de otra manera ocurrir en la primera apariencia de un disparador en el recibidor.

Un Disparador que contiene un parámetro del <tiempo en los medios> se puede llamar un disparador de Tiempo base, mientras que se usa para estabilizar una base de tiempo para tiempos del evento.

Un Disparador que contiene un parámetro <tiempo del evento puede llamar un Disparador de Activación, ya que envía un tiempo de activación para un evento.

La figura 5 y la figura 6 son diagramas que muestran una modalidad de una tabla de parámetro TDO.

Una Tabla (TPT) de Parámetros TDO contiene metadatos acerca de los TDOs de un segmento y los Eventos dirigidos a ella.

En lo sucesivo, se describirán los campos incluidos en la tabla. Los tamaños de los campos y los tipos de los campos incluidos en la tabla se pueden añadir o cambiar de acuerdo a la intensión del diseñador.

Los detalles semánticos de los campos en la estructura TPT son como a continuación.

La tabla de parámetro TDO (TPT) puede incluir @mayorProtocolVersion, @menorProtocolVersion, @id, @tptVersion, @expiraFecha, @actualizaciónTiempo, @servicioID, atributos de SbaseURL, Capacidades, EnvivoDisparador, y/o elemento TDO.

TPT es un elemento raíz de la TPT. Un elemento TPT describe toda o una porción (de tiempo) de un segmento de programación.

MayorProtocoloVersión que puede ser un atributo de 4 bitios que puede indicar el número mayor de versión de la tabla de definición. El número mayor de versión se puede ajustar a 1. Los receptores esperan descartar casos en que la TPT indica valores mayores de versión que no están equipados para soportarse.

Cuando está presente, @MenorProtocolVersion que puede ser un atributo de 4 bitios que puede indicar el número menor de versión de la tabla de definición. Cuando no está presente, el valor establecido a 0. El número menor de versión se puede ajustar a 0. Los receptores esperan no descartar casos en que la TPT indica valores menores de versión que no están equipados para soportarse. @id, el cual es URI, puede identificar únicamente el segmento de programación interactivo que Este elemento TPT pertenece a. @id sirve como un identificador de un segmento. En consecuencia, después un receptor analiza la TPT, un disparador, un AMT, etcétera relacionado a un segmento puede coincidir con la TPT que tiene @id para identificar el segmento que usa información de @id. En consecuencia, se puede encontrar un segmento al que el disparador y la AMT aplicarán. Los detalles de la AMT se describirán a continuación.

La QtptVersión, puede ser entero de 8 bitios, puede indicar el número de versión del elemento de TPT identificado por el atributo id. La tptVersión se puede incrementar siempre que se haga cualquier cambio a la TPT.

Cuando está presente, el atributo de @expiraFecha del elemento de la TPT puede indicar la fecha y tiempo de la expiración de la información incluida en este caso de la TPT. Si el receptor almacena en caché la TPT, lo puede volver a usar hasta la expiraciónFecha.

Cuando está presente, @actualizaciónTiempo el cual puede ser un elemento de 16 bitios que puede indicar que la TPT está sujeta a revisión, y da el intervalo recomendado en segundos para descargar la TPT de nuevo y verificar si la TPT descargada nuevamente es una versión nueva.

Cuando está presente, @servicioID el cual puede ser un entero de 16 bitios que puede indicar el servicio_id de NRT asociado con el servicio interactivo descrito en este caso de la TPT. Esto es necesario para que los receptores obtengan parámetros FLUTE desde la Tabla del Mapa del Servicio cuando los archivos para este servicio interactivo se suministran en el flujo de radiodifusión.

Cuando está presente, el atributo SbaseüRL puede dar una base URL la cual, al concatenarse sobre el frente de cualesquier URLs relativa que aparece en esta TPT. Esta puede dar las URLs absolutas de los archivos.

Cuando está presente, las capacidades del elemento pueden indicar capacidades que son esenciales para una presentación significativa del servicio interactivo asociado con esta TPT. Los receptores que no tienen una o más de las capacidades requeridas esperan no intentar presentar el servicio.

El elemento EnvivoDisparador se presenta si y solo si la suministra de los Disparadores de Activación mediante Internet está disponible. Cuando está presente, se puede proporcionar la información necesaria por un receptor para obtener los Disparadores de Activación. El elemento pequeño y el atributo de EnvivoDisparador se describirán a continuación.

La TDO que es un elemento pequeño del elemento de la TPT puede representar una aplicación (por ejemplo, una TDO), que proporciona parte del servicio interactivo durante el segmento descrito por este caso de la TPT. El elemento pequeño y el atributo da TDO se describirán a continuación.

El elemento EnvivoDisparador puede incluir @URL y/o el atributo @sondeoPeríodo.

Como se describe anteriormente, el elemento EnvivoDisparador se presenta si y solo si la suministra de los Disparadores de Activación mediante Internet está disponible. Cuando está presente, se puede proporcionar la información necesaria por un receptor para obtener los Disparadores de Activación.

La @URL, la cual es un atributo del elemento EnvivoDisparador, puede indicar la URL de un servidor que puede suministrar los Disparadores de Activación mediante Internet. Los Disparadores de Activación se pueden suministrar mediante Internet usando sondeo corto HTTP, sondeo largo HTTP, o transmisión HTTP, en la opción del proveedor del servicio interactivo.

Cuando está presente, @sondeoPeríodo, el cual es un atributo del elemento EnvivoDisparador, puede indicar que el sondeo corto es usado para suministrar los Disparadores de Activación, y el valor del atributo de sondeoPeriodo puede indicar el tiempo recomendado en los segundos en que el receptor lo usa como un periodo de sondeo.

Si el elemento EnvivoDisparador está presente, el receptor puede analizar la TPT y obtener información usada para suministrar el disparador de activación usando el Internet. La URL del servidor que puede recibir el disparador de activación se puede usar el que usa información @URL. A través de la información @sondeoPeríodo o información indica que el atributo @sondeoPeríodo no está presente, un método de suministrar el disparador de activación mediante el Internet y la información acerca del periodo se pueden obtener. El @sondeoPeriodo se describirá en detalle a continuación.

El elemento TDO puede incluir el atributo de @actualizaciónID, de la QappNombre, de la @globalID, de la @aplicaciónVersión, de la OcookieEspacio (un paquete de datos establecido por un servidor de internet para un buscador, que es regresado por el buscador cada vez que tiene acceso al mismo servidor), de @frecuenciaDeUso, de la @expiraFecha, de la SpruebaTDO, la @disponibleInternet, de la @disponibleRadiodifusión, la URL, las Capacidades, el articulo de Contenido, y/o el elemento de Evento.

Como se describe anteriormente, la TDO que es un elemento pequeño del elemento TPT puede representar una aplicación (por ejemplo, una TDO), proporciona parte del servicio interactivo durante el segmento descrito por este caso TPT.

La @appID, puede ser un entero de 16 bitios, puede identificar la aplicación únicamente dentro de la cercanía de la TPT. Un Disparador de Activación identifica la aplicación objetivo para el Disparador por medio de una referencia a la SappID o aplicaciónID. La @appID es un identificador de una aplicación. Una TPT puede incluir varias aplicaciones (tales como TDO). En consecuencia, después que analiza la TPT, la aplicación se puede identificar usando información de @appID. El disparador, la AMT, etcétera que aplicará a una aplicación puede coincidir con una aplicación que tiene @appID para identificar la aplicación. En consecuencia, se puede encontrar la aplicación a la que el disparador y la AMT aplicarán. La AMT se describirá en detalle a continuación.

La @appTipo, puede ser entero de 8 bitios, puede indicar el tipo de formato de aplicación. El valor predeterminado puede ser 1, el cual representa una TDO. Otros valores pueden representar otros formatos.

La @appNombre, la cual es un atributo del elemento de TDO, puede ser un nombre legible por un humano el cual se puede proyectar a un espectador cuando un permiso del espectador pretende poner en marcha la aplicación.

La @globalID, la cual es un atributo del elemento TDO, puede ser un identificador globalmente único de la aplicación. En muchos casos un receptor mantendrá en caché una aplicación que se va a usar de nuevo en poco tiempo. Para esto será útil, que el receptor deba permitir reconocer la aplicación la siguiente vez que aparezca. Una globalID es necesaria para que el receptor sea capaz de reconocer la aplicación cuando aparezca de nuevo en un segmento nuevo.

La QappVersion o @aplicaciónVersión, la cual es el atributo del elemento TDO, puede ser el número de versión de la aplicación. El valor de aplicaciónVersión puede incrementar si la aplicación (como es identificada por la globalID) cambia. El atributo de aplicaciónVersión no puede estar presente si el atributo globalID no está presente.

El @cookieEspacio, el cual puede ser un entero de 8 bitios, puede indicar cuánto espacio necesita la aplicación para almacenar datos persistentes entre las invocaciones.

La @frecuenciaDeUso, el cual puede ser un entero de 4 bitios, puede indicar aproximadamente la frecuencia que se usará la aplicación en la radiodifusión, para proporcionar guia a los receptores en la administración de su espacio caché del código de la aplicación. '@frecuenciaDeUso' se describirá en detalle a continuación.

La @expiraFecha, la cual es el atributo del elemento TDO, puede indicar unos datos y tiempo después que el receptor pueda borrar seguramente la aplicación y cualesquier recursos relacionados.

Cuando se presenta con el valor "verdadero", la @pruebaTDO, que es el atributo Booleano, puede indicar que la aplicación es para propósitos de prueba solamente, y que se puede ignorar por los receptores ordinarios.

El valor "verdadero" para el atributo @disponibleInternet puede indicar que la aplicación está disponible para descargar en el Internet. El valor "falso" puede indicar que la aplicación no está disponible para descargar en el Internet. Cuando el atributo no está presente, el valor predeterminado puede ser "verdadero".

El valor "verdadero" para el atributo @disponibleRadiodifusión puede indicar que la aplicación está disponible para la extracción desde la radiodifusión. El valor "falso" puede indicar que la aplicación no está disponible para la extracción desde la radiodifusión. Cuando el atributo no está presente, el valor predeterminado puede ser "verdadero".

Cada caso de la URL, un elemento pequeño del elemento TDO, puede identificar un archivo el cual es parte de la aplicación. El elemento de la URL puede incluir el Qatributo de entrada, @entrada, un atributo del elemento de la URL, tiene el valor "verdadero", puede indicar que la URL es un punto de entrada para la aplicación, es decir, un archivo que se puede iniciar para iniciar la aplicación. El valor predeterminado cuando el atributo no aparece puede ser "falso". El elemento URL el cual es el elemento pequeño del elemento TDO identifica un archivo que configura la aplicación como se describe anteriormente. El receptor analiza la TPT para obtener la información de la URL, acede al servidor usando la información URL, y descarga una aplicación indicada por la información URL.

Cuando está presente, las Capacidades, que son el elemento pequeño del elemento TDO, pueden indicar capacidades que son esenciales para una presentación significativa de esta aplicación. Los receptores que no tienen una o más de las capacidades requeridas se espera que no intenten presentar el inicio de la aplicación.

El ContenidoArtículo, un elemento pequeño del elemento TDO, puede indicar un articulo de contenido que incluye uno o más archivos de datos que se necesitan por la aplicación. El elemento del ContenidoArtículo tiene información acerca de los archivos de datos requeridos por la aplicación que usa información URL, etcétera del ContenidoArtículo, sí el elemento de ContenidoArtículo está presente después del análisis. El elemento pequeño y el atributo del ContenidoArtículo se describirán a continuación.

El evento, un elemento pequeño del elemento TDO puede representar un evento para la aplicación. El elemento del evento indica un evento de una aplicación al que este elemento pertenece. El elemento del evento contiene información que indica que el evento está presente, que los datos están presentes, que la acción está presente, etcétera. El receptor puede analizar el elemento del evento para obtener información acerca del evento de la aplicación. El elemento pequeño y el atributo del evento se describirán a continuación.

El receptor puede recibir y analizar la TPT para obtener el elemento pequeño da TDO y la información acerca de los atributos.

El elemento de ContenidoArtículo que es el elemento pequeño del elemento de TDO puede incluir el atributo @updatesAvail, @pollPeriod, @size, el atributo @availlnternet, @availBroadcast y/o el elemento de la URL.

Aquí, el elemento de la URL puede incluir el atributo de @entrada. Cada caso de la URL, un elemento pequeño del elemento de ContenidoArtículo, puede identificar un archivo que es parte del artículo de contenido. El elemento de la URL puede incluir el atributo de @enty. La @entrada, un atributo del elemento de la URL, tiene el valor "verdadero", puede indicar que la URL es un punto de entrada para el articulo de contenido, es decir, un archivo puede iniciar para iniciar el artículo de contenido. Cuando tiene el valor "falso", puede indicar que la URL no es un punto de entrada para el artículo de contenido. El valor predeterminado cuando el atributo no aparece puede ser "falso". El receptor puede descargar archivos de datos requeridos por la aplicación usando información de la URL del ContenidoArtículo después de ser analizados. En este proceso, se puede usar la información tal como la descrita anteriormente de los otros atributos.

La @actualizaciónDisp, la cual es un atributo booleano del elemento de ContenidoArtículo, puede indicar sí o no el artículo de contenido se actualizara de vez en cuando, es decir, sí el artículo de contenido incluye archivos estáticos o sí es una alimentación de datos en tiempo real. Cuando el valor es "verdadero" el artículo de contenido se actualizara de vez en cuando; cuando el valor es "falso" el artículo de contenido no se actualizará. El valor predeterminado cuando este atributo no aparece puede ser falso.

El QsondeoPeriod, el cual es un atributo del elemento de ContenidoArtículo, se puede presentar solo cuando el valor del atributo actualizaciónDisponible es "verdadero". La presencia del atributo de sondeoPeriodo puede indicar que el sondeo corto se usa para suministrar los Disparadores de Activación, y el valor del atributo de sondeoPeriodo puede indicar el tiempo recomendado en segundos para que el receptor lo use como un periodo de sondeo.

El ©Tamaño, el cual es un atributo del elemento de ContenidoArtículo, puede indicar el tamaño del articulo de contenido.

El valor "verdadero" para el atributo ©disponiblelnternet puede indicar que el articulo de contenido está disponible para descargar en el internet. El valor "falso" puede indicar que el articulo de contenido no está disponible para descargar en el internet. Cuando este atributo no está presente, el valor predeterminado puede ser "verdadero".

El elemento del evento contiene información acerca del evento de la aplicación indicada por el elemento TDO al que el elemento del evento pertenece. El receptor puede analizar el elemento del evento para obtener información acerca del evento.

El elemento del evento que es el elemento pequeño del elemento de TDO puede incluir el atributo del ©eventoID, de la @Acción, del ©destino, el atributo de @difusión y/o el elemento de los datos. Aquí, el elemento de los datos puede incluir el atributo de @dataID.

El @eventoID, el cual puede ser un atributo entero de 16 bitios del elemento del Evento, puede identificar el evento únicamente dentro de la cercanía del elemento TDO que lo contiene. Un Disparador de Activación (o elemento de activación en la AMT) puede identificar la aplicación objetivo y el evento para el Disparador por la combinación de aplicaciónID y el eventoID. Cuando se activa un evento, los receptores pasan el evento en la aplicación. El QeventoID sirve como identificador de un evento que usa información del @eventoID, un disparador, una AMT, etcétera para que la activación del evento pueda coincidir con una aplicación que tiene @eventoID para identificar el evento. Esto es, un Disparador de Activación (o elemento de activación en la AMT) puede identificar la aplicación objetivo y el evento para el Disparador por la combinación de aplicaciónID y el eventoID. Cuando se activa el evento, los receptores pasan el evento en la aplicación. La AMT se describirá en detalle a continuación.

La ©Acción, la cual es un atributo del elemento del evento, puede indicar el tipo de acción a aplicar cuando se activa el evento. Los valores permitidos pueden ser "prep", "exec", "susp" y ''eliminar". "prep" puede corresponder a la acción "Trig prep". Si el estado de la aplicación dirigida se "Libera", esta acción puede hacer que un estado cambie a "Listo". "exec" puede corresponder a la acción "Trig exec". El estado de la aplicación dirigida es "Activa" hasta la recepción de este disparador. "susp" puede corresponder a la acción "Trig susp". Si el estado de la aplicación dirigida es "Activo", el estado puede cambiar a "Suspendido" hasta la recepción de este disparador, de otra manera no hay cambio. "eliminar" puede corresponder a la acción "Trig eliminar". El estado de la aplicación dirigida se puede volver "Liberada" hasta la recepción de este disparador.

La @Acción puede indicar el tipo de acción a aplicar cuando se activa el evento.

La ©Destino, la cual es un atributo del elemento del evento, puede indicar que el dispositivo objetivo para el evento. ©Destino se describirá en detalle a continuación.

Cuando está presente, la ©difusión, puede ser un atributo entero de 8 bitios del elemento del evento, puede representar un periodo T de tiempo en segundos. El propósito del parámetro de difusión es suavizar los picos en la carga del servidor. El receptor puede esperar que se calcule un tiempo al azar en el rango de 0-T, en incrementos de 10 milisegundos, y retrasa esta cantidad antes de acceder un servidor de Internet para recuperar contenidos referenciados por las URLs en la TPT.

Cuando están presentes, los datos los cuales son un elemento pequeño del elemento del Evento pueden proporcionar datos relacionados al evento. Las diferentes activaciones del Evento pueden tener diferentes elementos de Datos asociados con ellos. El elemento de datos puede incluir el atributo de QdatosID. Los @datosID, son un atributo entero de 16 bitios, puede identificar el elemento de Datos único dentro de la cercanía del elemento del Evento que lo contiene. Cuando una activación de un evento tiene datos asociados con ella, el Disparador de Activación puede identificar el elemento de Datos por la combinación de la AplicaciónID, el EventoID, y DatosID. El elemento de datos indica datos usados para el evento. Un elemento del evento puede tener varios elementos de datos. Los datos identificados usan el atributo de @datosID del elemento de datos. En el receptor, si el evento relacionado a los datos se ¾a^tiva, el Disparador de Activación (o el elemento de activación en AMT) puede identificar el elemento de Datos por la combinación del AplicaciónID, el EventoID, y los DatosID. La AMT se describirá en detalle a continuación .

La figura 7 es un diagrama que muestra el significado de los valores de atributo de "Frecuencia de Uso".

El "significado" de la columna indica la frecuencia de ocurrencia de los segmentos contienen esta aplicación. (Un atributo puede aparecer múltiples veces dentro de un solo segmento, por supuesto). El atributo de frecuenciaDeUso no se puede presentar si el atributo globalID no está presente. Si la aplicación se va almacenar en caché y usar de nuevo después, el receptor necesita reconocer que esta es la misma aplicación cuando este aparece de nuevo. Esto requiere el atributo globalld.

La figura 8 es un diagrama que muestra el significado de los valores de atributo de la "destino".

Como se muestra en la figura 8, el valor del atributo de destino de 0 indica "reservado", el valor de atributo de destino de 1 indica solo el dispositivo primario, el valor del atributo de destino de 2 indica uno o más dispositivos secundarios solo 2, y el valor del atributo de destino de 3 indica el dispositivo Primario y/o uno o más dispositivos secundarios.

La figura 9, la figura 10, la figura 11, la figura 12 y la figura 13 son diagramas muestran una modalidad de la sintaxis de forma binaria desde una Tabla de Parámetros TDO.

Este es el formato en binario de la estructura TPT descrita anteriormente. Esta estructura es un formato necesario cuando se trasmite la TPT en la NRT y se hace tal que la estructura XML de la TPT se transmite adecuadamente en la NTR.

Los elementos siguientes y/o los atributos contenidos en la versión XML de la TPT se puede omitir de la versión binaria, ya que se puede proporcionar por el encabezado encapsulado para suministrar la tabla binaria en el flujo de radiodifusión: @protocolVersion (mayor/menor), @servicioID y/o QtptVersion.

La semántica de los campos es como sigue. Los campos del formato binario de la tabla de parámetro TDO de la figura 9, la figura 10, la figura 11, la figura 12 y la figura 13 se describirá secuencialmente.

La expiración_datos_incluidos, la cual puede ser el campo de 1 bitio, puede indicar si se incluye el campo de expiración_datos. El valor ?' puede significar que está incluido; el valor ?' puede significar que no está incluido.

El segmento_id_longitud, el cual puede ser un campo de 5 bitios, puede indicar la longitud de bitios del campo de segmento_id.

El segmento_id, el cual es un campo de longitud variable, puede contener los bitios de la identificación de segmento, el cual puede tener la misma semántica como el atributo "id" del formato XML TPT.

La base_URL__longitud, la cual puede ser un campo de 8 bitios, puede indicar la longitud de bitios del campo de base URL.

La base_URL, la cual es un campo de longitud variable, puede contener los bitios de la base URL, puede tener la misma semántica como el atributo de baseURL del formato XML TPT.

Cuando está presente, la expiración_fecha, la cual puede ser el campo de 32 bitios, puede indicar la fecha y el tiempo de expiración de la información incluida en este caso de TPT. Si el receptor almacena en caché la TPT, se puede volver a usar hasta la expiraciónFecha. El entero sin usar puede ser interpretado como el número de segundos GPS desde 00:00:00 UTC, 6 de Enero de 1980, menos el GPS-UTC_ desplazamiento. El desplazamiento de GPS UTC puede ser un entero sin signo de 8 bitios define el desplazamiento actual en segundos completos entre estándares de tiempo GPS y UTC.

El disparador_servidor_URL_longitud, el cual puede ser un campo de 8 bitios, puede indicar la longitud en bitios del campo del disparador_servidor_URL. Cuando el valor de este campo es 0, se puede indicar suministra del internet de los Disparadores de Activación individuales no está disponible.

El disparador_servidor_URL, cuando el valor del campo del disparador_servidor_URL_longitud no es 0, puede contener lo bitios de la URL del Servidor del Disparador, el cual puede tener la misma semántica como el atributo de la URL del elemento EnvivoDisparador del formato XML TPT.

El disparador_suministra_tipo, el cual puede ser un campo de 1 bitio, puede indicar el modo de suministra de los Disparadores de Activación individuales en el Internet. El valor ?' puede indicar que se usa el sondeo corto de HTTP; el valor ?' puede indicar que se empieza a usar cualquiera el sondeo largo de HTTP o la transmisión HTTP.

El sondeo_periodo, el cual puede ser un entero de 8 bitios, puede indicar el número recomendado de los segundos entre sondeos, cuando se empieza a usar el sondeo corto.

El num_aplicaciones en_tabla, el cual puede ser un campo de 8 bitios, puede indicar el número de aplicaciones (TDOs) descritas en este caso TPT.

La aplicación_id, la cual puede ser un campo de 16 bitios, puede contener un identificador para esta aplicación (la aplicación descrita en esta iteración del lazo num_aplicaciones_en_tabla). Esto puede ser único dentro de este caso TPT.

La aplicación_tipo_incluida, la cual puede ser un campo de bitios, puede indicar si el campo de aplicación_tipo se incluye para esta aplicación. El valor ?' puede significar que se incluye; el valor ?' puede significar que no se incluye.

La aplicación_nombre_incluido, el cual puede ser un campo de un bitio, puede indicar si el campo de aplicación_nombre se incluye para esta aplicación. El valor ?' puede significar que se incluye; el valor ?' puede significar que no se incluye.

La global_id_incluida, la cual puede ser un campo de 1 bitio, puede indicar si el campo global_id se incluye para esta aplicación. El valor ?' puede significar que se incluye; el valor ?' puede significar que no se incluye.

La aplicación_versión_incluida, la cual puede ser un campo de 1 bitio, puede indicar si el campo de aplicación_versión se incluye para esta aplicación. El valor ?' puede significar que se incluye; el valor ?' puede significar que no se incluye.

La cookie_espacio_incluido, el cual puede ser un campo de 1 bitio, puede indicar si el campo cookie_espacio se incluye para esta aplicación. El valor ?' puede significar que se incluye; el valor '0' que significa que no se incluye.

La frecuencia_de_usu_incluida, la cual puede ser un campo de 1 bitio, puede indicar si el campo frecuencia_de_uso se incluye para esta aplicación. El valor ?' puede significar que se incluye; el valor ?' puede significar que no se incluye.

La experiencia_datos_incluidos, los cuales pueden ser un campo de 1 bitio, puede indicar si el campo de expiración_datos se incluye para esta aplicación. El valor ?' puede significar que se incluye; el valor ?' puede significar que no se incluye.

Cuando está presente, la aplicación_tipo, la cual puede ser un campo de 8 bitios, puede indicar el tipo de formato de esta aplicación. El valor 0 puede indicar que la aplicación es una TDO. Si este campo no está presente, el valor se puede predeterminar a 0. Otros valores pueden representar otros formatos.

Cuando está presente, aplicación_nombre_longitud, el cual puede ser un campo de 8 bitios, puede indicar la longitud en bitios del campo de aplicación_nombre sigue inmediatamente a este. El valor 0 para este campo puede indicar que no se presenta el campo de aplicación_no bre para esta aplicación.

Cuando está presente, la aplicación_nombre, la cual es un campo de longitud variable, puede tener la misma semántica como el atributo de aplicaciónNombre del elemento TDO en el formato XML TPT.

Cuando está presente, global_id_longitud, el cual puede ser un campo de 8 bitios, puede indicar la longitud en bitios del campo global_id seguido inmediatamente a este. El valor 0 para este campo puede indicar que no se presenta el campo global__id para esta aplicación.

Cuando está presente, la global_id, la cual es un campo de longitud variable, puede tener la misma semántica como el atributo globalID del elemento TDO en el formato XML TPT.

Cuando está presente, la aplicación_versión, el cual puede ser un campo de 8 bitios, tiene la misma semántica como el atributo de aplicaciónVersion del elemento TDO en el formato XML TPT.

Cuando está presente, el cookie_espacio, el cual puede ser un campo de 8 bitios, puede tener la misma semántica como el atributo de cookieEspacio del elemento TDO en el formato XML TPT.

Cuando está presente, la frecuencia_de_uso, el cual puede ser un campo de 8 bitios, puede tener la misma semántica como el atributo de frencuenciaDeUso del elemento TDO en el formato XML TPT.

Cuando está presente, la experiencia_datos, la cual puede ser un campo de 8 bitios, puede tener la misma semántica como el atributo de expiraciónDatos del elemento TDO en el formato TPT XML.

La prueba_aplicación, la cual puede ser un campo de 1 bitio, puede indicar si o no esta aplicación es una aplicación de prueba, pretendida a ignorar por los receptores ordinarios. El valor ?' puede significar que es una aplicación de prueba; el valor ?' puede significar que no es una aplicación de prueba. disponible_en_internet, el cual puede ser un campo de 1 bitio, puede indicar si o no esta aplicación está disponible mediante el Internet o no. El valor ?' puede significar que está disponible mediante el internet; el valor ?' puede significar que no está disponible mediante el internet. disponible en radiodifusión, el cual pude ser un campo de 1 bitio, puede indicar si o no esta aplicación mediante la radiodifusión o no. el valor ?' puede significar que está disponible mediante la radiodifusión; el valor ?' puede significar que no está disponible mediante la radiodifusión. Los números_URLs, el cual puede ser un campo de 4 bitios, puede indicar el número de archivos comprende esta aplicación.

La URL_longitud, la cual puede ser un campo de 8 bitios, puede indicar la longitud del campo de la URL como sigue.

La URL, la cual es un campo de longitud variable, puede tener la misma semántica como el atributo de la URL del elemento TDO en el formato XML TPT.

El número_contenido_articulos, el cual puede ser un campo de 8 bitios, puede indicar el número de artículos de contenido que se descargaron para usar por esta aplicación.

La actualización_disponible, la cual puede ser un campo de 1 bitio, puede indicar sí este artículo de contenido se actualizara de vez en cuando, es decir, sí un conjunto de archivos estáticos o una alimentación de datos en tiempo real. El valor ?' puede indicar que se actualizará: el valor '0' puede indicar que no se actualizará. disponible_internet, el cual puede ser un campo de 1 bitio, puede indicar sí el(los) archivo(s) comprende(n) este artículo de contenido se puede descargar mediante el Internet o no. El valor ?' puede significar que no está disponible para descargar mediante el Internet; el valor ?' puede significar que no está disponible. disponible_radiodifusón, el cual puede ser un campo de 1 bitio, puede indicar si los archivo(s) comprende este articulo de contenido se puede descargar mediante la radiodifusión o no. El valor ?' puede significar que está disponible para descargar mediante la radiodifusión; el valor ?' puede significar que no está disponible.

El contenido_tamaño_incluido, el cual puede ser un campo de 1 bitio, puede indicar si o no el campo de contenido_tamaño se incluye o no para esta aplicación. El valor ?' puede significar que se incluye; el valor ?' puede significar que no se incluye.

El número_URLs, el cual puede ser un campo de 4 bitios, puede indicar el número de archivos comprende este articulo de contenido.

La URL_longitud, la cual puede ser un campo de 8 bitios, puede indicar la longitud del campo de URL siguiente.

La URL, la cual es un campo de longitud variable, puede tener la misma semántica como el atributo URL del ContenidoArtículo, elemento pequeño del elemento TDO en el formato XML TPT.

El contenido_tamaño, el cual puede ser un campo de 24 bitios, puede tener la misma semántica como el atributo contenidoTamaño del elemento pequeño del ContenidoArtículo del elemento TDO en el formato XML TPT.

El num_contenido_descriptores, el cual puede ser un campo de 8 bitios, puede indicar el número de descriptores de contenido en el lazo del descriptor inmediatamente después de este.

El contenido_descriptor(), el cual es un campo de longitud variable, puede ser un descriptor conforma al formato del descriptor MPEG-2 (etiqueta, longitud, datos). Puede proporcionar información adicional acerca de este articulo de contenido. Entre los descriptores pueden incluir en este lazo del descriptor puede ser el descriptor de Capacidades, indica las capacidades del receptor necesitados para una presentación significativa de este articulo de contenido.

El número_eventos, el cual puede ser un campo de 8 bitios, puede indicar el número de eventos definidos por este TDO.

El evento_íd, el cual puede ser un campo de 16 bitios, puede contener un identificador para este evento (el evento descrito en esta iteración del lazo de número_eventos). Este puede ser único dentro de la cercanía de esta aplicación. El evento se puede referenciar dentro de los Disparadores de Activación por la combinación de la aplicación_id y el evento_id.

La acción, la cual puede ser un campo de 5 bitios, puede tener la misma semántica como el atributo de acción del elemento pequeño del Evento del elemento TDO en el formato XML TPT.

El destino_incluido, el cual puede ser un campo de 1 bitio, puede indicar si o no el campo de destino se incluye para este evento. El valor ?' puede indicar que se incluye; el valor ?' puede indicar que no se incluye.

Los datos_incluidos, los cuales pueden ser un campo de 1 bitio, puede indicar si o no los datos_tamaño y los campos de datos_bitios se incluyen para este evento. El valor ?' puede indicar que se incluyen; el valor ?' puede indicar que no se incluye.

Cuando está presente, la semántica del campo de destino puede ser la misma como la semántica del atributo de destino del elemento pequeño del Evento del elemento TDO en el formato XML TPT.

Cuando está presente, la semántica del campo de difusión puede ser la misma como la semántica del atributo de difusión del elemento de niña del Evento del elemento TDO en el formato XML TPT.

Cuando está presente, el campo de datos_tamaño puede indicar el tamaño del campo de datos_bitios inmediatamente seguido a esto.

Cuando está presente, el campo de datos_bitios que puede proporcionar datos relacionados a este evento. Siempre que se active el evento, la aplicación objetivo será capaz de leer los datos y usar para ayudar a llevar a cabo la acción deseada. El contenido de este campo puede ser idéntico al contenido del elemento pequeño de Datos correspondiente del elemento pequeño de Evento correspondiente del elemento TDO correspondiente en el formato XML TPT, excepto que este campo puede contener el valor binario, y el elemento de Datos en el formato XML TPT puede contener una codificación base64 del valor binario.

El num_aplicación_descriptores, el cual puede ser un campo de 8 bitios, puede indicar el número de descriptores en el lazo del descriptor inmediatamente seguido a este.

La aplicación_descriptor(), la cual es un campo de longitud variable, puede ser un descriptor conforma al formato del descriptor MPEG-2 (etiqueta, longitud, datos). Se puede proporcionar la información adicional acerca de esta aplicación (TDO). Entre los descriptores que pueden incluir en este lazo del descriptor es el descriptor de Capacidades, indica las capacidades del receptor necesarias para una presentación significativa de esta aplicación.

El num_TPT_descriptores, el cual puede ser un campo de 8 bitios, puede indicar el número de descriptores en el lazo del descriptor inmediatamente seguido a esto.

La TPT_descriptor(), la cual es un campo de longitud variable, puede ser un descriptor que conforma el formato del descriptor MPEG-2 (etiqueta, longitud, datos). Puede proporcionar información adicional acerca de esta TPT. Entre los descriptores pueden incluir en este lazo del descriptor que es el descriptor de las Capacidades, que indica capacidades del receptor necesarias para una presentación significativa del servicio interactivo representado por este TPT.

La figura 14 es un diagrama que muestra una modalidad de una estructura de tabla de mensaje de activación. En lo sucesivo, se describirán los campos incluidos en la tabla. Los tamaños de los campos y los tipos de los campos incluidos en la tabla se pueden añadir o cambiar de acuerdo a la intención del diseñador.

Una Tabla de Mensajes de Activación (AMT) puede contener el equivalente de los Disparadores de Activación para un segmento. Bajo ciertas circunstancias se pueden suministrar a los receptores en lugar de los Disparadores de Activación. Un disparador se puede suministrar en el flujo de subtitulo, por los servidores ACR, por un servidor "disparador en vivo", y mediante la AMT.

La semántica detallada de los campos en la estructura AMT es como sigue: Una Tabla de Mensajes de Activación (AMT) puede incluir el atributo del @mayorProtocolVersion, del (ümenorProtocolVersion, del @segmentoID, de @esMT y/o del elemento de activación.

El UmayorProtocolVersion, el cual puede ser un atributo de 4 bitios del elemento de la AMT, puede indicar el número de versión mayor de la definición de la AMT. El número de versión mayor se puede ajustar a 1. Los receptores pueden esperar que se descarten los casos de la AMT indica los valores de versión mayor que no se equipan al soporte.

Cuando está presente, el @menorProtocolVersion, el cual puede ser un atributo de 4 bitios del elemento de la AMT, puede indicar el número de versión menor de la definición de la AMT. Cuando no se presenta, el valor se puede predeterminar a 0. El número de versión menor se puede ajustar a 0. Los receptores pueden esperar que no se descarten los casos en que la AMT indica valores de versión menores que no se equipan al soporte. En este caso pueden esperar que se ignoren cualesquier elementos o atributos individuales los cuales no se soportan.

El QsegmentoID, el cual es un identificador de la AMT, coincide el identificador de la TPT el cual contiene las aplicaciones y eventos a los cuales las Activaciones en esta AMT aplican. SsegmentoID puede servir como un identificador de la AMT. En consecuencia, el receptor puede recibir y analizar la AMT para identificar la AMT mediante información de @segmentoID. El @segmentoID contiene información indica que el segmento de la AMT se aplica, coincide @id de la TPT relacionada al segmento, y sirve para conectar la AMT y la TPT. Además, el segmento puede identificar la información básica provista necesaria para identificar a TDO objetivo y el evento del elemento de activación de la AMT.

Cuando está presente, el @esMT, el cual es un atributo del elemento de la AMT, puede indicar el principio del Tiempo en los Medios del segmento para el cual este caso AMT proporciona los tiempos de activación. @esMT puede indicar el principio del tiempo en los medios con respecto a un segmento al cual la AMT se aplicará. Por lo tanto, es posible decidir un criterio de un tiempo cuando la activación indicada por el elemento de activación ocurre. En consecuencia, si el @esMT está presente, el atributo @inicioTiempo en el elemento de activación puede ser influenciada por el principio del tiempo en los medios indicado por @esMT.

Cada caso del elemento de Activación de la AMT puede representar un comando para activar un cierto evento en un cierto tiempo, con ciertos datos asociados con el evento. Una pluralidad de elementos de activación se puede presentar en la AMT. Cada elemento de activación desempeña un papel similar al del disparador de activación. El elemento de activación puede aplicar al segmento indicado por el Qsegmentold en la AMT. Los atributos del elemento de activación pueden contener información acerca de que la activación de la aplicación ocurre, en que la activación del evento ocurre, cuando la activación ocurre, etcétera. Los atributos del elemento de activación se describirán en detalle a continuación.

El elemento de activación puede incluir el atributo del SobjetivoTDO, del @objetivoEvento, del @objetivoDatos, del @inicioTiempo y/o del atributo de @fin de tiempo.

El @objetivoTDO, el cual es un atributo del elemento de Activación, puede coincidir con el atributo de aplicaciónID de un elemento TDO en la TPT con el cual se asocia la AMT, por lo cual identifica la aplicación objetivo para el comando de activación. El @objetivoTDO puede contener información al que la aplicación del elemento de activación de la AMT se aplica.

El receptor puede recibir y analizar la AMT para obtener OobjetivoTDO y encontrar la QappID en el elemento TDO de la TPT de coincidencia para identificar la aplicación al que se aplicará el elemento de activación.

El @objetivoEvento, es un atributo del elemento de Activación, puede coincidir con el atributo de eventoID de un elemento de Evento contenido en el elemento TDO identificado por el atributo de objetivoTDO, por lo que identificar el evento objetivo para el comando de activación. El @objetivoEvento puede contener información al que el evento del que la aplicación del elemento de activación de la AMT aplica. El receptor puede recibir y analizar la AMT para obtener el (üobjetivoEvento y encontrar el @eventoID en el elemento TDO de la TPT de coincidencia para identificar el evento al que se aplicará el elemento de activación.

El @objetivoDatos, el cual es un atributo del elemento de activación, puede coincidir con el atributo de datosID de un elemento de Datos contenidos en el elemento de Evento identificado por el objetivo TDO y los atributos objetivoEvento, por lo que identifica los Datos que se asocia con el evento objetivo cuando el comando de activación aplica. El @objetivoDatos puede identificar los datos relacionados al evento objetivo cuando el comando de activación aplica. El receptor puede recibir y analizar la AMT para obtener el @objetivoDatos y encontrar los @dataID en el elemento de evento de la TPT.

SinicioTiempo, el cual es un atributo del elemento del evento, puede indicar el inicio del periodo de tiempo valido para el evento en relación al Tiempo en los Medios. Los receptores pueden esperar que se ejecute el comando cuando el Tiempo en los Medios alcanza el valor en el inicioTiempo, o tan pronto como sea posible después del mismo. El SinicioTiempo puede indicar un inicio de tiempo cuando el evento acurre. Este inicio de tiempo se basa en el tiempo en los medios. El receptor puede analizar la AMT para obtener información de SinicioTiempo y confirmar el tiempo cuando el evento ocurre usando el SinicioTiempo. El receptor puede activar el evento si el tiempo en los medios alcanza el inicioTiempo basado en el tiempo en los medios del segmentos identificado por el SsegmentoID. Si el inicioTiempo ya se ha transcurrido, el evento se puede activar tan pronto como sea posible.

Cuando está presente, el gfinTiempo, el cual es un atributo del elemento del evento, puede indicar el fin del periodo de tiempo valido para el evento en relación al Tiempo en los Medios. El receptor puede esperar que no ejecute el comando cuando el Tiempo en los Medios es pasado el valor en el finTiempo. El @finTiempo se puede indicar el tiempo final del evento. Si el tiempo en los medios alcanza el finTiempo, el receptor puede no realizar el evento.

Los elementos de Activación en la AMT puede aparecer para los valores inicioTiempo ascendente.

Cuando un receptor es la activación de eventos de acuerdo a la activación en una AMT, se puede esperar que aplique cada activación en su inicioTiempo, o tan pronto como sea posible desde el mismo (por ejemplo, en el caso cuando un receptor une el servicio y recibe la AMT en algún tiempo después que el inicioTiempo y antes del finTiempo). Si el atributo "acción" del elemento del evento en la TPT es "exec", entonces el receptor puede esperar que pase un DisparadorEvento en la aplicación objetivo. El DisparadorEvento se describirá a continuación en la parte relacionada a la API.

La figura 15 es un diagrama que muestra una modalidad de un diagrama estructural de Lista de la URL.

Una Lista de la URL puede contener ciertas URLs de uso potencial a un receptor. La lista de la URL puede incluir los ÜRLs siguientes, etcétera. 1. La URL para las TPTs para uno o más segmentos futuros, permite a un receptor precargar los archivos. 2. La URL de un Servidor de Señalización de NRT desde la cual la información acerca de los servicios NRT independientes en el flujo de radiodifusión se pueden recuperar, permite a un receptor para acceder a aquellos servicios incluso sí no tiene acceso al suministro de la señalización del servicio NRT en el flujo de radiodifusión. 3. La URL de un Servidor de Informes de Uso se pueden enviar por un canal virtual, permite a un receptor enviar en tales reportes si no tiene acceso a la entrega de esta URL en el flujo de radiodifusión. 4. La URL de la Tabla PDI-Q para un canal virtual, permite a un receptor personalizar la experiencia de visualización incluso si no tiene acceso a la Tabla PDI-Q suministrada en el flujo de radiodifusión. (La Tabla PDI-Q se refiere a la personalización para proporcionar un servicio personalizado para el usuario en la provisión del servicio interactivo. Es posible preguntar al usuario acerca de la personalización mediante la tabla de PDI-Q).

Entre otros, la lista URL se puede hacer con respecto al elemento UrsUrl de modo que además indica la URL del servidor para informes de uso, para usar los datos preferidos y el tipo de contenido vistos y consumidos actualmente aunque el receptor en los negocios. El elemento Ursürl incluido en la lista de la URL se puede interpretar diversamente como sigue.

Primero, en el caso de un servidor de informes de uso, el receptor puede realizar la función de informe de uso del receptor por un protocolo predeterminado (por ejemplo, estructura de datos, archivo XML, etcétera) con la URL del servidor de informe de uso.

Segundo, puede ser una TDO ejecutado en el navegador de red del receptor. En este caso, esto indica la locación da TDO de Informe de Uso. En este caso, a TDO puede colectar y reportar directamente información acerca del contenido almacenado en el receptor o consumido actualmente usando la API (por ejemplo, las APIs de archivo o las APIs de informe de uso) del navegador de red del receptor. La TDO puede transmitir los datos colectados usando JavaScript API llamando XMLHttpSolicitud.

La URLlista puede incluir la URlLista, la TptURl, la UrsURl, y/o la PdiURl. La semántica de ese elemento es como sigue.

TptUrl, el cual es un elemento del elemento de UrlLista, puede contener la URL de una TPT para un segmento futuro en el servicio adjunto interactivo actual. Cuando se incluyen los elementos TptUrl múltiples, se puede disponer para la apariencia de los segmentos en la radiodifusión.

La NrtSeñalizaciónURl, la cual es un elemento del elemento de UrlLista, puede contener la URL de un servidor desde el cual los receptores pueden obtener las tablas de señalización NRT para todos los canales virtuales en el flujo de transporte actual.

El UrsUrl, el cual es un elemento del elemento de UrlLista, puede contener la URL de un servidor al que los receptores pueden enviar los informes de uso (medición de audiencia) para el canal virtual actual.

El PdiUrl, el cual es un elemento del elemento de UrlLista, puede contener la URL de la tabla PDI-Q para el canal virtual actual.

La figura 16 es un diagrama que muestra una modalidad del formato binario para las secciones privadas que contienen TPTs. La figura 16 ilustra un caso en que una TPT se suministra en un flujo de radiodifusión en un mecanismo de suministro el cual se describirá a continuación. Los detalles se describirán después.

Una descripción se dará de un mecanismo de suministro para la entrega de un disparador, una TPT, etcétera. La salida desde la Creación del Servicio Interactivo, el Suministro de los Disparadores en el Flujo de Radiodifusión, el Suministro de los disparadores de base de Tiempo mediante el Internet, el Suministro de los Disparadores de Activación mediante Internet (escenario ACR), el Suministro de la TPTs en el Flujo de Radiodifusión, el Suministro de la TPTs mediante el Internet, Moviendo los Artículos de Contenido y de TDOs, Combinando Múltiples Segmentos en Un Segmentos se describirán secuencialmente.

En lo sucesivo, se describirá la Salida de la desde la Creación del Servicio Interactivo.

El proceso de creación del servicio para un segmento puede resultar en una carpeta que contiene todos los TDOs y otros artículos de contenido, el archivo TPT en el formato XML y el archivo AMT en el formato XML. Los otros resultados se pueden crear.

En lo sucesivo, el Suministro de los Disparadores en el Flujo de Radiodifusión se describirá.

Cuando se suministra en el flujo de radiodifusión, los Disparadores se pueden suministrar en el canal de Subtítulos de DTV, en el Servicio #6, en el comando URLCadena.

Si el Disparador es menor o igual a 26 caracteres en longitud, se puede enviar (Tipo=ll) no segmentado. Si el Disparador es de 27 a 52 caracteres de longitud, se puede enviar en dos segmentos (el primer segmento en un segmento Tipo=00 y el segundo segmento en un segmento Tipo=10).

El tipo de URI suministrado en cualquier caso dado del comando se puede dar por un parámetro de 8 bitios.

Para los servicios interactivos que usan el modelo de TDO, el tipo de URI de la estructura de datos URI se puede ajustar a 0 (Disparador de Televisión interactiva para el modelo TDO). Este mecanismo de suministro incluye tanto los disparadores de Tiempo base como los Disparadores de Activación.

En el caso en que el disparador de tiempo base se suministra mediante un flujo de radiodifusión (en el servicio #6 de subtítulos), si el término "m=" está ausente, los disparadores de Tiempo base puede suministrar simplemente la URL del Servidor de Señalización. Y si el término "m=" está ausente, entonces el término "t=" debe estar ausente desde los disparadores de Activación.

En el caso en que el disparador de activación se suministra mediante un flujo de radiodifusión (en el servicio #6 de subtítulos), esto es, en el caso del formato "Disparador", con el término "e=", con o sin el término "t=", si el término "t=" se presenta, el tiempo de activación puede ser la marca de tiempo en relación a una base de tiempo. Y si el término "t=" está ausente, el tiempo de activación puede ser el tiempo de llegada del mensaje.

En el caso en que el disparador de tiempo base y el disparador de activación se suministra mediante el servicio #6 CC, puede haber tres posibles maneras para que el radiodifusor administre la Base de Tiempo y los Disparadores de activación. Las tres maneras son 'El modo de segmento sin base de tiempo explícito', 'El modo de segmento con base de tiempo explícito' y ?1 modo de servicio sin base de tiempo explícito'.

Eso se puede mezclar sin una radiodifusión, en un segmento por la base del segmento.

En el segmento de modo sin base de tiempo explícito, los mensajes de Activación incluidos sin marca de tiempo, de modo que el tiempo de activación de cada mensaje puede ser el tiempo de suministro del mensaje, y los mensajes de Tiempo Base tampoco incluye marca de tiempo, de modo que su propósito solo puede ser provisto de la URL del Servidor de Señalización que puede suministrar archivos TPT. Los mensajes de Tiempo Base se puede incluso omitir completamente en este modo, basándose en la URL en los mensajes de Activación para proporcionar la URL del Servidor de Señalización, per o entonces los receptores no serán capaces de recuperar una TPT e iniciar la descarga de TDOs hasta después que el primer mensaje de Activación aparece, basándose en la respuesta del primer mensaje de Activación por un largo trecho.

En este caso los mensajes de Tiempo Base que puede aparecer en el servicio #6 CC puede contener el "localizador_parte" del formato del "Disparador" y posiblemente el término "difusión", pero no el término "medios_tiempo", y los mensajes de Activación que pueden aparecer en el servicio #6 CC que puede contener el "localizador_parte" del formato del "Disparador", el término "evento_tiempo", y posiblemente el término "difusión", pero no con la parte "t=" en el término "evento_tiempo". La "localizador_parte" de tanto la Base de tiempo como los mensajes de Activación puede ser el segmentold actual. Esta URL también se puede usar para recuperar la TPT para el segmento mediante el internet.

En el modo de segmento con base de tiempo explícito, los mensajes de Tiempo base incluye un sello de tiempo, para definir una base de tiempo, y los mensajes de Activación pueden incluir un sello de tiempo para definir el tiempo de activación en relación a la base de tiempo, o ellos pueden no incluir el sello de tiempo, indicando gue el tiempo de activación es el tiempo de llegada del mensaje.

En este caso los mensajes de Tiempo Base que pueden aparecer en el servicio #6 CC puede contener el "localizador_parte" del formato "Disparador", el término de "medios_tiempo" y posiblemente el término "difusión", y los mensajes de Activación que puede aparecer en el servicio #6 CC puede contener el "localizador_parte" del formato del "Disparador", el término "evento_tiempo", y posiblemente el término "difusión", con o sin la parte "t=" en el término "evento_tiempo" . El "localizador_parte" de tanto la Base de Tiempo y los mensajes de Activación pueden ser el segmentold actual, y la base de tiempo es específica para el segmento. Esta URL también se puede usar para recuperar la TPT para el segmento mediante el Internet.

En el modo de servicio con la base de tiempo explícito, los mensajes de Tiempo Base incluye un sello de tiempo, para definir una base de tiempo, los mensajes de Activación pueden o no incluir un sello de tiempo. La base de tiempo se puede extender a través de los múltiples segmentos, en lugar de ser especifica a un segmento solo. El "localizador_parte" de los mensajes de Base de Tiempo puede ser un identificador de la base de tiempo, y también una URL que se puede usar para recuperar la TPTs por el servicio mediante el internet.

En cualquier caso el Servidor de Inserción del Disparador inserta los disparadores en el servicio #6 CC deberá trabajar desde la AMT, trasladar los mensajes de Activación desde el formato XML en la AMT en el formato del disparador especificado para suministrar en el servicio #6 CC. En el caso de que un elemento de Activación sin atributo de finTiempo, un solo disparador se puede insertar con el tiempo de activación igual al atributo de inicioTiempo. En el caso de un elemento de Activación tanto con el inicioTiempo como con el finTiempo, una secuencia de los disparadores se puede insertar con el mismo objetivo. El primer disparador en la secuencia puede tener el tiempo de activación igual al atributo de inicioTiempo, el ultimo disparador en la secuencia puede tener el tiempo de activación igual al atributo de finTiempo, y puede ser un intervalo de tiempo fijo entre los tiempos de activación de los disparadores en la secuencia (excepto que el intervalo entre el penúltimo y el penúltimo disparador en la secuencia puede ser corto). La longitud de este intervalo de tiempo fijo puede ser configurable.

Cuando la Base de Tiempo y los mensajes de Activación están en el modo del segmento, la base de tiempo puede especificar al segmento. Se puede iniciar con el valor de "principioMT" en el principio del segmento, y correr a través del segmento. Los valores de "inicioTiempo" y de "finTiempo" de las Activaciones individuales se pueden referir al valor de "principioMT". Cuando la Base de Tiempo y los mensajes de Activación están en el modo de servicio, la base de tiempo puede abarcar los segmentos, y el valor "principioMT" para cada segmento se puede ajustar para tomar en cuenta la base de tiempo del servicio y el horario de radiodifusión.

En lo sucesivo, el Suministro de los disparadores de Tiempo base mediante el Internet se describirán.

El suministro de internet de los disparadores de tiempo base pueden ser útiles en las también llamadas situaciones de Reconocimiento de Contenido Automático (ACR), donde el recipiente de los disparadores de Tiempo base no tienen acceso al servicio #6 de Subtítulos. En estas situaciones el receptor necesita usar la ACR para reconocer los cuadros de video y sincronizar la base de tiempo con el mismo. En las situaciones de ACR en que los mensajes de Tiempo Base se pueden obtener desde las marcas de agua o desde los servidores de ACR. En el caso de recepción desde el servidor de ACR, los mensajes de Base de Tiempo se suministran como respuestas desde un servidor de ACR.

En lo sucesivo, se describirá el Suministro de los Disparadores de Activación mediante Internet (Escenario de ACR).

Los mensajes de Activación se pueden suministrar mediante el sondeo corto, el sondeo largo o la transmisión, pero todos ellos pueden imponer muchos encabezados en los receptores y en el servidor. Los mensajes de Activación también se pueden suministrar en la forma de una AMT, pero esto puede proporcionar una buena cantidad de información acerca de la longitud de los segmentos, facilitando borrar los anuncios. Puede haber otras alternativas.

En el caso en que el mensaje de activación se suministra en la forma del disparador de activación, esto es, en el caso del formato del "Disparador" con el término "e=", con o sin el término "t=", esto se puede suministrar mediante el sondeo corto, el sondeo largo o la transmisión HTTP.

Cuando se suministra mediante el Internet, los mensajes de Activación se pueden suministrar usando cualquiera o ambos de los mecanismos, el mecanismo de Suministro del Disparador de Activación Individual y el mecanismo de Suministro del Disparador de Activación Mayor.

En lo sucesivo, se describirá el Suministro del Disparador de Activación Individual.

Como se describe anteriormente, cuando los Disparadores de Activación Individual se suministran mediante el Internet, ellos se pueden suministrar usando sondeo corto, sondeo largo o transmisión HTTP. El formato del Disparador de Activación puede ser exactamente el mismo como cuando se suministra mediante el servicio #6 DTVCC.

En caso del sondeo corto, el periodo del sondeo se debe especificar. En este periodo, una operación de sondeo corto se puede ajustar usando sondeoPeriodo incluido en la TPT como se describe anteriormente.

Cuando está disponible el suministro de Internet de los Disparadores de Activación, el atributo de la URL del elemento EnvivoDisparador en la TPT puede indicar el Servidor del Disparador de Activación que puede ser el disparador de activación de suministro. Si el atributo de sondeoPeriodo del elemento EnvivoDisparador está presente en la TPT, esto puede indicar que se empieza a usar el sondeo corto HTTP, y puede indicar el periodo de sondeo que un receptor debe usar. Si el atributo de sondeoPeriodo del elemento EnvivoDisparador no está presente en la TPT, esto puede indicar que ya sea el sondeo largo HTTP o la transmisión HTTP se empiezan a usar.

Independientemente de cual protocolo se use, el receptor puede esperar emitir una solicitud HTTP al Servidor del Disparador de Activación con el término de pregunta: ?mt=<medios_tiempo> donde <medios__tiempo> pueden ser el tiempo en los medios actual del contenido visto.

Si se empieza a usar el sondeo corto, la respuesta desde el Servidor de Disparador de Activación puede contener todos los disparadores que se han emitido dentro del intervalo de tiempo de la codificación del sondeo de codificación de longitud terminar en <medios_tiempo>. Si más que un Disparador de Activación se regresa, se pueden separar por uno o más caracteres de espacios en blanco. Si no se regresan los Disparadores de Activación, la respuesta puede estar vacia.

Si el sondeo largo HTTP o la transmisión HTTP se empieza a usar, el Servidor del Disparador de Activación puede esperar a que regrese una respuesta hasta que el tiempo en los medios cuando un Disparador de Activación podría ser suministrado en el flujo de radiodifusión. En este momento se puede regresar el Disparador de Activación.

Si se empieza a usar el sondeo largo HTTP, el Servidor del Disparador de Activación puede cerrar la sesión después de regresar un Disparador de Activación. El receptor puede esperar que se emita inmediatamente otra solicitud, con un tiempo en los medios actualizado.

Si se usa la transmisión HTTP, el Servidor del Disparador de Activación puede mantener la sesión abierta después de regresar a cada Disparador de Activación, y puede suministrar los Disparadores de Activación adicionales sobre la sesión conforme el tiempo llegar por ellos a ser suministrados.

En todos los casos la respuesta HTTP puede contener un Campo de Encabezado de Respuesta HTTP de una de las siguientes formas para señalar el modo de suministro: Modo de Suministro ATSC: SondeoCorto [<sondeo_periodo>] Modo de Suministro ATSC: LargoSondeo Modo de suministro ATSC: Transmisión o flujo de datos El parámetro <sondeo-periodo> puede indicar el intervalo recomendado entre sondeos para los sondeos subsiguientes. El <sondeo-periodo> se puede omitir.

En lo sucesivo, se describirá el Suministro de Disparador de Activación Mayor.

Cuando se suministran los Disparadores de Activación mediante el Internet al por mayor, los Disparadores de Activación para un segmento se pueden suministrar mediante la HTTP a lo largo junto con la TPT para el segmento, en la forma de un mensaje MIME de múltiples partes, con la TPT como la primera parte del mensaje, y una Tabla de Mensajes de Activación (AMT) como la segunda parte del mensaje.

En lo sucesivo, se describirá el Suministro de las TPTs en el Flujo de Radiodifusión.

Cuando se suministra en el flujo del suministro, las TPTs se pueden trasladar desde su formato XML en un formato de tabla de señalización de estilo NRT binario equivalente y encapsulado en las secciones privadas de estilo NRT, una de la TPT por caso de tabla. La TPT para el segmento actual está siempre presente. Las TPTs para uno o más segmentos futuros también se pueden presentar. El caso de la TPT se define por el valor de su campo de segmento_id. Por referencia, el formato en binario de la tabla del parámetro TDO se describió anteriormente. Aquí, la sección privada de estilo NRT puede corresponder a la tpt_sección() de la figura 16.

En resumen, para transmitir la estructura de la TPT en la NRT, la TPT puede tener una estructura de sección adecuada para la transmisión NRT. En lo sucesivo, este proceso se describirá en detalle.

Cada TPT se puede encapsular en las secciones privadas de estilo NRT dividiendo cada TPT en bloques e insertar los bloques en los campos tpt_bitios() de las secciones tienen un valor común de la tabla_id, los campos de protocolo_versión, de TPT_datos_versión y de secuencía_número. Los bloques se pueden inseratr en las secciones para valores de campo de sección_número ascendente. Las secciones privadas se pueden llevar a cabo en el Canal de señalización de Servicio (SSC) de la subred IP del canal virtual al que la TPT pertenece. Aquí, el "Canal de Señalización de Servicio" se define en el estándar ATSC-NRT y los medios de un canal que tiene una dirección IP especifica y un número del puerto. Los campos de secuencia_número en las secciones se pueden usar para distinguir diferentes casos de TPT llevados a cabo en la misma ssc.

En lo sucesivo, los campos de la figura 16 se describirán.

La sección privada (tpt_sección()) puede incuir la información de la tabla_id, del protocolo_versión, de la secuencia_número, de la TPT_datos_version, del actual_después_indicador, de la sección_número, de la ultima_sección_número, del servicio_id, y/o del tpt_bitios().

La tabla_id, la cual puede ser un campo de 8 bitios, puede identificar esta sección de la tabla como que pertenece un caso de la Tabla de los Parámetros TDO.

El protocolo_versión se puede dividir en dos partes. Los 4 bitios de orden mayor de este campo del entero sin asignar de 8 bitios que puede indicar el número de versión mayor de la definición de esta tabla y el caso de la TPT llevado a cabo en el mismo, y los 4 bitios de orden bajo indican el número de versión menor. El número de versión mayor se puede ajustar a 1. Los receptores se pueden esperar que se descarten los casos de los valores de versión mayor indica la AMT ellos no se equipan al soporte. El número de versión menor se puede ajustar a 0. Los receptores se puede esperar que no descarten los casos de los valores de versión menor indica la AMT ellos no se equipan al soporte. En este caso ellos se esperan ignorar cualesquier descripciones no se reconocen, e ignoran cualesquier campos que ellos no se soportan.

La secuencia_número puede ser un campo de 8 bitios. El valor de la secuencia_nú ero puede ser la misma como la secuencia_número de todas las otras secciones de este caso de la TPT y diferente de la secuencia_número de todas las secciones de cualquier otro caso de la TPT en este Canal de Señalización de Servicio. En consecuencia, este campo puede realizar un papel diferente que del otro caso de la TPT. El campo de la secuencia__número puede indicar una subred IP asociada con un canal de señalización de servicio en esta sección. Los valores de los campos de la secuencia_número de los diferentes casos TPT puede reflejar el orden en el cual los segmentos aparecen en el flujo de radiodifusión.

La TPT_datos_versión, la cual puede ser un campo de 5 bitios, puede indicar el número de versión de este caso de la TPT, donde el caso de la TPT se puede definir por su segmento_id. Mientras que la versión de la TPT se conoce por adelantado para determinar si los datos de sección de la TPT son una versión de la TPT nueva, el campo de la TPT_datos_versión se pueden presentar en la tabla de la sección. El número de versión puede incrementar por 1 módulo 32 cuando cualquier campo en el caso de la TPT cambia.

El actual_despues_indicador, el cual puede ser indicador de 1 bitio, siempre se puede ajustar a ?' para las secciones de la TPT, indica que la TPT se envía siempre la TPT actual para identificar el segmento por su segmento_id.

La sección_número, la cual puede ser un campo de 8 bitios, puede dar el número de sección de esta sección del caso de la TPT, donde el caso de la TPT se puede identificar por su segmento_id. La sección_número de la primera sección en un caso TPT puede ser 0x00. La sección_número se puede incrementar por 1 con cada sección adicional en el caso de la TPT.

La última_sección_número, la cual puede ser un campo de 8 bitios, puede dar el número de la última sección (es decir, la sección con la sección_número más grande) del caso de la TPT del cual esta sección es una parte.

El servicio_id puede ser un campo de 16 bitios, puede especificar el servicio_id asociado con el servicio interactivo ofrecen los artículos de contenido descritos en este caso de la tabla.

La tpt_bitios (), la cual es un campo de longitud variable, puede incluir un bloque del caso de la TPT llevado en parte por esta sección. Cuando los campos de la tpt_bitios() de todas las secciones de este caso de la tabla se concatenan para sus campos de la sección_número, el resultado puede ser el caso de la TPT completa.

Esto es, después que se usa el formato en binario de la TPT o después que se cambia el formato XML a un formato binario, la TPT se puede dividir para serla transmisión NRT adecuada, incluida en el campo tpt_bitios() de la sección privada, y transmitida en NRT. En este momento, si una TPT se divide en varias secciones privadas, la sección privada puede tener la misma tabla-id, el protocolo _versión de la TPT_datos_versión y el valor de secuencia_número. Los bloques de la TPT divididos se pueden insertar en el orden de los valores del campo de la sección_número.

El receptor puede analizar las secciones privadas recibidas. Para combinar las secciones privadas en una TPT de nuevo, las secciones privadas tiene la misma tabla_id, el protocolo_versión de la TPT_datos_versión y los valores de la secuencia_númerose pueden usar. En este momento, la información de orden capaz de ser obtenido desde la sección número y la información de última_sección_número se pueden usar. Si la tpt_bitíos() de todas las secciones privadas que tienen la misma tabla_id, el protocolo_versión de la TPT_datos_versión y los valores de secuencia_número se conectan secuencialmente, una TPT se puede crear.

La Entrega de las TPTs mediante Internet se describirá en detalle con referencia a la figura 17.

En lo sucesivo, se describirán las TDOs de Movimiento y los Artículos de Contenido.

Las redes y estaciones a menudo necesitarán proporcionar sus propios servidores HTTP para suministrar los TDOs y artículos de contenido (archivos) usados por los TDOs. Cuando esto se hace, la baseURL en la TPT se puede ajustar para reflejar la locación del servidor.

En lo sucesivo, se describirá la Combinación de Segmentos Múltiples en Un Segmento.

Para ofuscar a fondo fronteras entre los segmentos, las TPTs y las AMTs para segmentos múltiples se pueden combinar en una sola TPT y la AMT. Los pasos siguientes se pueden realizar. 1. Identificar el paso de los segmentos a combinar. 2. Crear una TPT nueva con un segmentold nuevo. 3. Si cualguiera de los segmentos que se combina tiene activaciones en vivo, proporciona un servidor de retransmisión que proporciona acceso a todos del mismo, y pone los parámetros para este servidor en el elemento "EnvivoDisparador". 4. Aplicar la baseURL para cada segmento como sea necesario para obtener la TDO completa y las URLs tiendaArticulo. (Puede ser posible identificar una baseURL más corta que es común para todos los segmentos que se combinan, y retienen como una baseURL para el segmento combinado). 5. Revisar los valores de aplicaciónld según sea necesario para eliminar los conflictos. 6. Insertar en la TPT nueva todos los elementos TDO revisados para todos los segmentos que se combinan. 7. Crear una AMT nueva con el segmentold igual al segmentold nuevo de la TPT combinada. 8. Seleccionar un valor "principioMT" nuevo apropiado para la AMT nueva. 9. Ajustar los valores del objetivold de todos los elementos de Activación en los archivos AMT para los segmentos que se combinaron para reflejar cualesquier cambios en los valores de aplicaciónld. 10. Ajustar los valores inicioTiempo y el finTiempo de todos los elementos de Activación en los archivos AMT para los segmentos que se combinaron para reflejar el valor "principioMT" nuevo y el horario de radiodifusión para los segmentos que se combinaron. 11. Insertar todos los elementos de Activación revisados en la AMT nueva.

La figura 17 es un diagrama que muestra una modalidad de una lista de las URLs codificadas como un documento XML.

En lo sucesivo, se describirá el Suministro de las TPTs mediante Internet.

Cuando se suministran en el internet, las TPTs se pueden suministrar mediante HTTP. La URL de la TPT para el segmento actual puede ser "<parte del nombre del dominio>/<trayectoria del directorio>" en los mensajes de Tiempo Base. La respuesta a una solicitud para una TPT puede incluir solo la TPT, o puede incluir un mensaje MIME de 2 partes, con la TPT solicitada en la primera parte y una lista de las URLs en la segunda parte, codificado como un documento XML. (La respuesta a una solicitud siempre incluirá la TPT por el segmento actual. Esta puede incluir TPTs para uno o más segmentos futuros también).

Las URLs como la segunda parte de la respuesta descrita anteriormente puede tener el formato mostrado en la figura 17.

La semántica de los elementos de la figura 18 se describirá.

La "UrlLista" puede contener una lista de las URLs que son útiles para un receptor.

La "TptUrl" puede contener la URL de una TPT para un segmento futuro. Cuando se incluyen los elementos de la TptUrl múltiples, ellos se pueden disponer en el orden de la apariencia de los segmentos en la radiodifusión.

La "NrtSeñalizaciónURl" puede contener la URL de un servidor donde los receptores pueden obtener las tablas de señalización NRT para todos los canales virtuales en el flujo de radiodifusión actual.

La figura 18 es un diagrama que muestra una modalidad de añadirDisparadorEventoDetector.

En lo sucesivo, se describirán las APIs JavaScript ATSC para un ambiente para ejecutar el DO.

Para soportar la sincronización de las acciones del Objetivo Declarativo para transmitir la programación, se pueden soportar los métodos adicionales para el objetivo de video/radiodifusión .

Si la TPT se recibe mediante la DTVCC o el Internet, varios eventos para ejecutar la TDO se pueden presentar en la TPT y esos eventos se pueden activar por el disparador de activación.

Para procesar este evento, una función del Detector se puede registrar en una base del eventoID. En consecuencia, como los 'métodos adicionales' descritos anteriormente, las dos funciones, de añadirDisparadorEventoDetector y de removerDisparadorEventoDetector, para registrar la función del Disparador se pueden presentar.

En la figura 18, se describe añadirDisparadorEventoDetector y se muestran el formato, los argumentos, etcétera.

La función de añadirDisparadorEventoDetector puede registrar una función de devolución (función del detector) para procesar un evento generado en una base por eventold. La función de añadirDisparadorEventoDetector puede recibir el detector del tipo de EventoDetector y el eventold del tipo de Número como argumento. El tipo de evetoDetector se describirá a continuación. La función de añadirDisparadorEventoDetector puede no tener un valor de retorno (nulo). Aquí, el argumento eventold puede ser ID de evento en el elemento del evento de la TPT. Aquí, el argumento del detector puede ser un detector para el evento.

El módulo de procesamiento del disparador del receptor puede registrar la función del detector en una base por eventold que usa la función "añadirDisparadorEventoDetector" tan pronto como se recibe el mensaje de activación. Si el evento se activa, se puede llamar la función del detector registrada. En este momento, el objetivo del tipo de DisparadorEvento se puede suministrar a la función del disparador. El tipo de DisparadorEvento se describirá a continuación.

La figura 19 es un diagrama que muestra una modalidad de removerDisparadorEventoDetector.

En la figura 19, se describe removerDisparadorEventoDetector y se muestran el formato, los argumentos, etcétera.

La función de removerDísparadorEventoDetector puede cancelar el registro de una función de devolución (función del detector) para procesar un evento generado en una base por eventold. La función de removerDisparadorEventoDetector puede recibir el detector del tipo de EventoDetector y el eventold del tipo de Número como argumento. El tipo de eventoDetector se describirá a continuación. La función de removerDisparadorEventoDetector puede no tener un valor de retorno (nulo). Aquí, el argumento del eventold puede ser la ID del evento en el elemento del evento de la TPT. Aquí, el argumento del detector puede ser un detector para el evento.

En el programa javascript, si el evento el cual se puede generar en una base por eventold se desea ya no ser recibido o si el programa "DestruirVentana" se finaliza, la función del detector registrada usando "removerDisparadorEventoDetector" se puede cancelar.

La figura 20 es un diagrama que muestra una modalidad de la definición del tipo de EventoDetector.

Aquí, la definición del tipo de EventoDetector conforma al Lenguaje de definición de Interfaz de Red (Weg IDL). La IDL de Red se puede usar para describir interfaces que no se pretenden implementar en navegadores de red. La IDL de red es una IDL variante con un número de características que permiten el comportamiento de la escritura de objetos comunes en la plataforma de red a especificar más fácilmente.

El EventoDetector puede ser un objeto de interfaz. El Tipo de EventoDetector puede tener un evento del tipo de DisparadorEvento como un argumento.

La figura 21 es un diagrama que muestra una modalidad de la definición del tipo de DisparadorEvento.

El tipo de DisparadorEvento puede contener información acerca del evento.

El tipo de DisparadorEvento puede tener el eventold, datos y estado como propiedades. Aquí, el eventold puede ser el eventoID en el elemento del evento de la TPT. Aquí, los datos pueden ser datos para esta activación del evento. Aquí, los datos pueden ser hexadecimales. Aquí, el estado puede significar el estado del evento. Aquí, si el valor del estado es el "disparador", esto significa un estado en que el evento se activa por el disparador de activación. Si el valor de estado es "error", esto significa un estado en el cual ocurre un error.

El modelo TDO se ha descrito. En lo sucesivo, se describirá el modelo de Ejecución Directa.

En el modelo de Ejecución Directa, un Objetivo Declarativo (DO) se puede poner en marcha automáticamente tan pronto como se selecciona el canal virtual. Se puede comunicar sobre el Internet con un servidor de servicio para obtener instrucciones detalladas para proporcionar características interactivas-creación de pantalla en las locaciones especificas en la pantalla, la realización de sondeos, lanzar otros DOs especializados, etcétera, todos sincronizados con el programa de audio-video.

En lo sucesivo, se describirá la operación del disparador en el modelo de ejecución directo.

El rol, la función y la sintaxis del disparador no se cambian grandemente en el modelo de ejecución directa.

El rendimiento del disparador es igual al que se describe anteriormente .

La sintaxis del Disparador es igual al que se describe anteriormente .

Un Disparador se puede considerar que incluye tres partes. <parte del nombre del dominio>/<trayectoria del directorio>[?<parámetros>] En el modelo de ejecución directa, la combinación de la <parte del nombre del dominio> y la trayectoria del directorio> puede identificar únicamente el DO a poner en marcha.

Los <parámetros> pueden incluir uno o más del "evento_tiempo", "medios_tiempo", o "difusión".

En el modelo de ejecución directa, una aplicación se pone en marcha tan pronto como se selecciona el canal virtual. La Aplicación se puede comunicar en internet con un servidor de servicio mediante un "Protocolo de Contenido Sincronizado". El servidor puede dar instrucciones detalladas por proporcionar la característica interactiva, la cual se sincroniza toda con el programa de audio-video.

En el caso del modelo de ejecución directa, ya que una aplicación se ejecuta inmediatamente, la información se puede suministrar a la aplicación ejecutada actualmente conforme se suministra un disparador de tiempo base. En este modelo, la aplicación necesita información suministrada continuamente acerca del contenido transmitido actualmente al servidor para la sincronización. Para este fin, el disparador de tiempo base además puede incluir información especial diferente de la del modelo da TDO. Esta información especial puede ser un identificador del contenido transmitido actualmente.

Similarmente, el identificador del contenido puede estar presente en la parte del parámetro del disparador en la forma de un parámetro.

Similarmente, el identificador de contenido puede estar presente en los medios_tiepo del disparador en la forma de un término. El término del identificador de contenido, el cual puede llamar el contenido_id, el cual se puede designar por "c=" seguido por una cadena de caracteres, puede representar un identificador para el contenido que se está viendo actualmente.

El término de contenido_id puede pretender soportar el modelo de Ejecución Directa de implementación de servicio interactivo.

Como se describe anteriormente, en este modelo, los disparadores de Tiempo base con el término de contenido_id puede pasar a la aplicación después que se pone en marcha, y la aplicación puede suministrar el contenido_id al servidor de servicio para identificar el contexto para la interacción. La operación detallada del mismo se describirá a continuación.

El mecanismo de suministro del disparador en el módulo de ejecución directa es igual al que se describe anteriormente.

Sin embargo, en el caso del Suministro de los Disparadores en el Flujo de Radiodifusión, los Disparadores se pueden suministrar en el Canal de Subtítulos de DTV, en el Servicio #6, en el comando de la URLCadena. Y para servicios interactivos que usan el modelo de Ejecución Directa, el campo de la URL_tipo se puede ajustar a 2 (Disparador de la Televisión Interactiva para el modelo de Ejecución Directa).

En lo sucesivo, se describirá la operación total del módulo de ejecución directa.

Como un modelo para ejecutar el servicio interactivo, en el modelo de ejecución directa, una aplicación se puede poner en marcha automáticamente tan pronto como se selecciona el canal virtual. La aplicación se puede comunicar en el Internet con un servidor de servicio mediante un "Protocolo de Contenido Sincronizado". Las instrucciones detalladas dadas para proporcionar características interactivas-crear pantallas en las localizaciones especificas en la pantalla, la realización de sondeos, poner en marcha otros Dos especializados, etcétera, todos sincronizados con el programa de audio-video.

La Operación se puede realizar como sigue.

En primer lugar, una aplicación se puede poner en marcha. Entonces, se recibe un disparador de tiempo base. El disparador de tiempo base se suministra a la aplicación después que se ha ejecutado la aplicación. El término de contenido_id del disparador de tiempo base puede incluir la información de identificación de contenido del contenido visualizado actualmente. La aplicación puede suministrar el contenido_id al servidor de servicio para identificar el contexto para la interacción, y para identificar el contenido que se ve actualmente.

Se ha descrito el Modelo de Ejecución Directa.

La figura 22 es un diagrama que muestra la arquitectura para el enfoque WM.

Se dará una descripción del Suministro mediante otras interfaces.

Se definen los protocolos y la arquitectura que permiten la adquisición de un servicio interactivo en ambientes (por ejemplo, conforme se recibe desde un cable o el decodificador de satélite) en que solo el video y audio sin comprimir son accesibles). La arquitectura y los protocolos se pueden designar para usar por los receptores que tienen conexiones de Internet y que solo tienen acceso al audio y video sin comprimir desde el flujo de radiodifusión. Por supuesto, la arquitectura y los protocolos se pueden usar exitosamente si el proveedor de servicio interactivo elige soportar al mismo.

La arquitectura se puede designar para soportar dos enfoques básicos para identificar el contenido que se está viendo, de modo que cualesquier mejoras de los datos de servicio interactivo asociados se pueden suministrar mediante el Internet. Los dos enfoques básicos pueden ser marcas de agua y toma de huellas digitales.

En ambos enfoques de la marca de agua y de la toma de huellas digitales, la intención puede permitir a los receptores averiguar lo que la programación está actualmente viendo y obtener una URL que se puede usar como el punto de inicio para obtener la información adicional acerca de los servicios interactivos para la programación.

La figura 22 ilustra una arquitectura para un enfoque WM.

En una- arquitectura para un enfoque WM, la arquitectura puede incluir un radiodifusor 22010, una inserción 2011 de marca de agua, una MVPD 22020, un STB 22030, un receptor 22040, un cliente 22050 WM, un servidor 22060 de la TPT y/o un servidor 22070 de contenido.

El radiodifusor 22010 puede ser una fuente de emisión de flujos de audio/video y en los servicios interactivos relacionados a los flujos de audio/video. Una estación de televisión puede ser un ejemplo del radiodifusor 22010. El radiodifusor 22010 puede ser un productor o productor de contenido de radiodifusión. El radiodifusor 22010 puede suministrar los flujos de radiodifusión, el contenido de audio/video, los datos interactivos, los horarios de radiodifusión o la AMT.

La inserción 22011 de marca de agua puede insertar marcas de agua en cuadros de audio/video de radiodifusión. La inserción 22011 de marca de agua se puede integrar con el radiodifusor 22010 o puede ser un módulo separado. Las marcas de agua pueden ser la información necesaria para los receptores. Las marcas de agua pueden ser información tal como la URL. Las marcas de agua se describirán en detalle después.

La MVPD 22020 es una abreviatura para el distribuidor del programa de video de programa múltiple. La MVPD 22020 puede ser un operador por cable, un operador por satélite o un operador por IPVT. La MVPD 22020 puede recibir el flujo de radiodifusión desde el Radiodifusor/Inserción de Marca de agua, con las marcas de agua insertadas por la Inserción 22011 de Marca de agua en el caso de un sistema de ACR de marca de agua. La MVPD a menudo necesitara todos los elementos de programa otros que las pistas de audio y video, y envía el flujo resultante a los decodificadores (STBs) en las instalaciones del cliente.

La STB 22030 típicamente decodifica (descomprime) el audio y el video enviado al mismo tiempo al conjunto de la Televisión para la presentación a los espectadores. La STB puede enviar el contenido de audio/video sin comprimir al receptor 22040. La STB puede ser una unidad de decodificación externa de acuerdo a una modalidad de la presente invención.

El receptor 22040 puede incluir el cliente 22050 WM. El cliente 22050 WM se puede disponer fuera del receptor 22040. Aquí, el receptor puede ser capaz de marca de agua. La estructura del receptor 22040 se describirá después.

El Cliente 22050 WM puede obtener los Disparadores de Activación desde el servidor de ACR (no mostrado) y pasa lo mismo en el código del receptor principal, usando una API provista para tal propósito. Normalmente, el Cliente 22050 WM deberá incorporarlo al receptor, pero otras configuraciones son posibles. El cliente 22050 WM puede extraer las marcas de agua desde el contenido de audio/video sin comprimir. Las marcas de agua puede ser información tal como una URL.

El servidor 22060 de la TPT puede ser un servidor capaz de descargar una aplicación tal como una TPT. El receptor 22040 transmite las marcas de agua extraídas al servidor ACR. Cuando las marcas de agua se hacen coincidir con las marcas de agua almacenadas en una base de datos (no mostrada), el receptor 22040 puede recibir un disparador o disparadores como una respuesta. Cuando el disparador o los disparadores recibidos tienen el localizador_parte nuevo descrito anteriormente o se descubre una TPT o la tabla del parámetro de aplicación de una nueva versión, el receptor 22040 puede solicitar al servidor 22060 de la TPT descargar una TPT nueva o la tabla del parámetro de aplicación.

El servidor 22070 de contenido puede proporcionar las aplicaciones y la TDO necesaria para proporcionar los servicios interactivos. Cuando una aplicación nueva o la TDO son necesarias, la aplicación nueva se puede descargar usando una URL en una TPT o la tabla del parámetro de aplicación.

En el enfoque (WM) de marca de agua la inserción del radiodifusor/marca de agua puede insertar marcas de agua en los cuadros de audio o video de radiodifusión. Esas marcas de agua se pueden designar para llevar una cantidad modesta de información a los receptores, mientras que sea imperceptible o al menos mínimamente invasiva para los espectadores. Tales marcas de agua podrían proporcionar directamente la información que los receptores necesitan, o pueden proporcionar solo un valor de código que los receptores pueden enviar mediante una conexión de Internet a un servidor remoto para obtener la información que ellos necesitan.

La figura 23 es un diagrama que muestra una modalidad de la arquitectura para el enfoque FP.

En la arquitectura para el enfoque FP, la arquitectura puede incluir un radiodifusor 23010, una MVPD 23020, una STB 23030, un receptor 23040, un cliente 23050 FP, un servidor 23060 de la TPT, un servidor 23070 de contenido, un extractor 23080 de firma y/o un servidor 23090 FP.

El radiodifusor 23010 puede ser una fuente emisión de flujos de audio/video y en servicios interactivos en relación al flujo de audio/video. Una estación de la Televisión puede ser un ejemplo del radiodifusor 22010. El radiodifusor 22010 puede ser un productor o distribuidor de contenido de radiodifusión. El radiodifusor 22010 puede suministrar los flujos de radiodifusión, de contenido de audio/video, de datos interactivos, el horario de radiodifusión o de la AMT.

La MVPD 23020 es la abreviación para el distribuidor de programa del video de programa múltiple. La MVPD 22020 puede ser un operador por cable, un operador por satélite o un operador por IPTV. La MVPD 23020 a menudo necesitaran de todos los elementos de programa otros que las pisas de audio y video, y envía el flujo resultante a los decodificadores (STBs) en las instalaciones del cliente.

La STB 23030 típicamente decodifica (descomprime) el audio y el video y envía los mismos a una Televisión para la presentación a los espectadores. La STB puede enviar el contenido de audio/video sin comprimir al receptor 23040. La STB 23030 puede ser una unidad de decodificación externa de acuerdo a una modalidad de la presente invención.

El receptor 23040 puede incluir el cliente 23050 FP. El cliente 23050 FP se puede disponer fuera del receptor 23040. Aquí, el receptor 23040 puede ser capaz de tomar la huella digital. La estructura del receptor 23040 se describirá después.

El cliente 23050 FP puede obtener los Disparadores de Activación desde el Servidor 23090 FP y los pasa en el código del receptor principal, usando una API provista para cada propósito. Normalmente el cliente 23050 FP se podría incorporar en el receptor, pero otras configuraciones son posibles. El cliente 23050 FP puede extraer una huella digital desde un contenido de audio/video sin comprimir. La toma de huella digital se describirá en detalle después.

El servidor 23060 de la TPT puede ser un servidor capaz de descargar una aplicación tal como una TPT. El receptor 23060 transmite la huella digital extraída al servidor 23090 FP. Cuando la huella digital coincide con una firma del extractor 23080 de firma, el receptor 23040 puede recibir un disparador o disparadores como una respuesta. Cuando se descubre el disparador o los disparadores tiene el localizador_parte nuevo descrito anteriormente o una TPT o tabla del parámetro de aplicación de una versión, el receptor 22040 puede solicitar el servidor 23060 de la TPT para descargar una nueva TPT o la tabla del parámetro de aplicación.

El servidor 23070 de contenido puede proporcionar aplicaciones y la TDO necesaria para proporcionar servicios interactivos. Cuando se necesita una aplicación nueva o una TDO, la aplicación nueva se puede descargar usando una URL en una TPT o la tabla del parámetro de aplicación.

El extractor 23080 de firma puede recibir metadatos desde el radiodifusor 23010. El extractor 23080 de firma puede extraer la firma de un cuadro desde los metadatos recibidos. Cuando la huella digital transmitida al servidor 23090 FP coincide con la firma del extractor 23080 de firma, el extractor 23080 de firma puede suministrar los metadatos relacionados a la firma al servidor 23090 FP.

El servidor 23090 FP puede realizar la operación de coincidencia de firma con el extractor 23080 de firma. El servidor 23090 FP puede coincidir con la firma de la huella digital recibida desde el receptor 23040. Cuando la firma coincide con la huella digital, el servidor 23090 FP puede recibir los metadatos relacionados a la firma desde el extractor 23080 de firma. El servidor 23090 FP puede transmitir los metadatos al receptor 23040.

En el enfoque de huella digital (FP), el cliente 23050 FP puede extraer las huellas digitales (también puede llamar firmas) desde los cuadros audio o video y comprueba las huellas digitales contra una base de datos de las huellas digitales de los cuadros de radiodifusión desde los radiodifusores múltiples en el área para encontrar la información de los receptores 23040 necesaria. Tales comprobaciones se pueden hacer por las firmas a un servidor remoto y volver a un registro de una base de datos de las firmas que se han descargado en el receptor 23040. Aquí, el servidor remoto puede ser el servidor 23090 FP.

Aunque la marca de agua y la huella digital puede ser de distintas teenologías, ellos pueden no necesariamente es excluyentes uno de otro. Usando una combinación de las dos tecnologías es bastante concebible. El termino reconocimiento de contenido automático (ACR) se puede usar para referirse ya sea a estas tecnologías separadamente o a cualquiera en combinación de las mismas.

Un ambiente en que un receptor solo tiene acceso al audio y video sin comprimir desde el flujo de radiodifusión se llama un "ambiente ACR".

En ambos casos WM y FP los receptores pueden usar la URL como un punto de inicio para obtener contenido de servicio interactivo, incluye los disparadores.

En ambos caso WM y FP la información puede estar en la forma de una marca de tiempo en relación a un reloj de lado de la radiodifusión que se usa para la especificación del tiempo de los eventos críticos de tiempo para el canal, tal como las marcas de tiempo de activación en los disparadores suministrados en el Internet.

Se asume que los radiodifusores pueden soportar típicamente el suministro de los servicios interactivos directamente en el flujo de radiodifusión, para el beneficio de los receptores consiguen señales de la televisión desde las antenas, y también soportan el suministro de los servicios interactivos sobre el Internet como se describe anteriormente, para el beneficio de los receptores consiguen el audio y video sin comprimir, pero tienen una conexión de Internet. Sin embargo, los radiodifusores pueden soportar tanto una de esos dos mecanismos de suministro sin el otro.

Una arquitectura típica para el enfoque de marca de agua en el caso cuando la marca de agua proporciona solo un calor de código podría ser algo como una combinación de las dos arquitecturas en la figura 22 y la figura 23. Podría ser una Inserción de Marca de agua, como en la figura 22, pero se podría insertar un código, en lugar de la información necesaria por los receptores. También podría ser un Servidor WM, desempeña el mismo papel como el Servidor FP en la figura 23. Los receptores podrían enviar códigos, en lugar de firmas, y podrían obtener de nuevo la información que ellos necesitan.

Se dará una descripción de los servicios interactivos de acceso.

La descripción de los servicios interactivos de acceso incluye las descripciones del Modelo de Ejecución Directo, el Modelo TDO con las Activaciones Independientes del Servidor ACR, el modelo TDO con las Activaciones recibidas desde el Servidor ACR. Mientras que no se muestren los modelos, los modelos no se limitan a las descripciones y se pueden cambiar de acuerdo a la intención de un diseñador.

Hay un número de maneras diferentes de un receptor en un ambiente ACR para acceder a los servicios interactivos, dependen de las elecciones del radiodifusor y la naturaleza del sistema ACR. El modelo de servicio interactivo puede ser el modelo de Ejecución Directa o el modelo TDO, y la Activación En el caso del modelo TDO, los disparadores se pueden suministrar independientemente del servidor ACR, o ellos se pueden suministrar por el servidor ACR.

Se dará una descripción del Modelo de Ejecución Directa.

Un proceso ACR para un canal virtual que contiene un servicio interactivo que tiene el Modelo de Ejecución Directa puede proporcionar a los receptores ven que el canal equivalente de los Disparadores de Tiempo Base incluyen el término medios_tiempo ("m=") y el término contenido_id ("c="). Esos Disparadores se pueden identificar como los Disparadores para un servicio interactivo con el modelo de Ejecución Directa.

Cuando el receptor recibe primero tal Disparador con un localizador_parte, se puede esperar que se carguen en su navegador el Objetivo Declarativo (DO) apuntado por el localizador_parte del Disparador. Típicamente el DO tendrá preinstalado o cargado previamente y almacenado en caché. De otra manera el receptor puede esperar que se cargue el mismo, usando una solicitud GET HTTP.

Entonces, el DO puede contactar el servidor principal apropiado y proporcionar el servicio interactivo según se dirige por el servidor principal.

El receptor puede esperar que el Disparador inicial y los Disparadores subsecuentes disponibles al DO conforme hagan que ellos se obtengan hasta tal tiempo conforme se pone un Disparador desde el servidor ACR tiene un localizador_parte nuevo y/o se identifica como un Disparador para un servicio interactivo con el modelo TDO (cualquiera de los cuales indica típicamente un cambio de canal).

Se dará una descripción del Modelo TDO con las Activaciones Independientes del Servidor ACR.

Un proceso ACR para un canal virtual puede contener un servicio interactivo tiene el modelo TDO, y el cual proporciona las activaciones de evento independientemente del Servidor ACR, puede proporcionar a los receptores ven que el canal del equivalente de los Disparadores de Tiempo de Base que puede incluir el término medios_tiempo ("m="). Esos Disparadores se pueden identificar como los Disparadores para un servicio interactivo con el modelo TDO.

Cuando un receptor recibe primero tal Disparador con un localizador_parte nuevo, se puede esperar que se recupere la Tabla de Parámetros TDO (TPT) desde el servidor TPT que se puede apuntar por el localizador_parte del Disparador, y usar el tiempo en los medios en el que el Disparador y los Disparadores subsecuentes estabilizan una base de tiempo de referencia para las activaciones del evento, en relación a los cuadros de audio o video se puede identificar por el proceso ACR.

Si una AMT (Tabla de Mensajes de Activación) se suministra a lo largo de la TPT, el receptor puede esperar que se usen los elementos de Activación individuales en la tabla para activar los eventos en los tiempos correctos en relación a la base de tiempo estabilizada por los términos de tiempo en los medios en los Disparadores. (Esos eventos pueden incluir cargar y ejecutar una TDO, hacer que una TDO tome una acción sincronizada particular, suspendiendo una TDO, etcétera).

Si un elemento EnvivoDisparador se incluye en la TPT, el receptor puede esperar que se recuperen los Disparadores de Activación desde el Servidor del Disparador En Vivo identificado por la URL en el elemento EnvivoDisparador, usar el método de sondeo señalado en el elemento EnvivoDisparador, y usar los Disparadores de Activación para activar eventos en el tiempo correcto en relación a la base de tiempo establecido por los términos de tiempo en los medios en los Disparadores.

Ambos una AMT y un Servidor del Disparador En Vivo se puede usar por el mismo servicio, típicamente con las activaciones estáticas que el anterior proporciona las activaciones estáticas y el posterior proporciona activaciones dinámicas.

Se dará una descripción del Modelo TDO con las Activaciones recibidas desde el servidor ACR.

Como se describe los disparadores de activación para un modelo de servicio interactivo TDO se suministran sin el servidor del disparador separado en un ambiente ACR.

Los sistemas ACR de huella digital pueden incluir un servidor ACR. Los receptores pueden enviar firmas de cuadro a un servidor ACR, y el servidor ACR puede identificar el cuadro representado por la firma y envía de nuevo la información necesaria por los receptores. Los sistemas ACR de marca de agua pueden incluir un servidor ACR en el caso cuando las marcas de agua no incluyen más códigos que se pueden enviar a un servidor ACR para obtener la información necesaria por los receptores. Los sistemas ACR de marca de agua pueden no incluir un servidor ACR en el caso cuando las marcas de agua ellas mismas contienen la información necesitada por los receptores. En aquellos sistemas ACR que incluyen un servidor ACR, dos modelos diferentes se pueden usar para la comunicación entre los servidores y los receptores ACR: un modelo solicitud/respuesta y un modelo orientado al evento.

Se asume que el radiodifusor soporta el modelo de interacción TDO.

Se pueden asumir tres casos de un servidor ACR que usa un modelo de solicitud/respuesta, un servidor ACR que usa un modelo orientado al evento y un sistema ACR de marca de agua inserta información directamente.

En el caso de un servidor de ACR, el método de ACR podría ser la toma de huella digital, en cuyo caso los receptores computan alguna especie de firma (o huella digital) de cuadros de audio o de video y presentan el mismo que un servidor para la identificación, o podría ser marca de agua, en cuyo caso los receptores extraen códigos en la forma de las marcas de agua desde los cuadros de audio o de video y presentan los códigos a un servidor ACR para la identificación.

Los términos de las firmas de huella digital se describen para la conveniencia. Sin embargo, el sistema opera en la misma manera que el caso de los códigos de marca de agua y la presente invención no se limita a huella digital.

La figura 24 es un diagrama que muestra un ejemplo de activación estática en un caso ACR de solicitud/respuesta.

Se dará una descripción de un caso en que un servidor ACR usa el modelo de solicitud/respuesta.

En el modelo ACR de solicitud/respuesta, el receptor puede esperar que se generen las firmas del contenido periódicamente (por ejemplo cada 5 segundos, el cual es meramente ejemplar y se puede cambiar por un diseñador) y envía solicitudes que contienen las firmas al servidor ACR. Cuando el servidor ACR obtiene una solicitud desde un receptor, puede regresar una respuesta. Las comunicaciones de sesión no la pueden mantener abierta entre los casos de solicitud/respuesta. En este modelo, puede que no sea factible que el servidor ACR inicie los mensajes del cliente.

Para un servidor ACR usa este modelo solicitud/respuesta y que suministra los Disparadores de Activación a los receptores, cada respuesta desde el servidor ACR puede ser uno de Nulo, Disparador de Tiempo Base y del Deparador de Activación .

Una respuesta nula puede indicar que no se reconoce la firma, o (si Módulo de Ingesta de ACR incluye firmas para los cuadros en los segmentos de programa sin el servicio interactivo) que la firma representa un cuadro que pertenece a un segmento que no tiene un servicio interactivo asociado con el mismo. El módulo de ingesta ACR se describirá a continuación.

Una respuesta del Disparador de Tiempo Base puede indicar que la activación del evento no está prevista que toma lugar antes de la siguiente solicitud del cliente. El cliente puede esperar que se usen los Disparadores de Tiempo Base para mantener un reloj de tiempo en los medios.

Una respuesta del Disparador de Activación puede indicar que tendrá lugar en breve, con el tiempo de la activación indicada por el término "t=" en el Disparador.

Sin embargo un receptor obtiene un Disparador con un localizador_parte nuevo, se puede esperar que se descargue inmediatamente la TPT nueva, a menos que ya se haya recuperado la misma usando una URLLista suministrada con una TPT previa.

Siempre que un receptor obtiene un Disparador de Activación, se puede esperar que se active el evento en el tiempo indicado por el término "t=" en el Disparador, en relación al reloj del tiempo en los medios.

La figura 24 ilustra como este esquema trabaja para la activación estática (o para la activación dinámica cuando el sistema ACR aprende de la activación dinámica con suficiente antelación de tiempo).

En la figura 24, el receptor puede enviar firmas para los cuadros que el servidor ACR determina tener los tiempos MT1, MT2 y MT3 en los medios. Para el cuadro con el tiempo MTl en los medios el receptor simplemente obtiene una respuesta que contiene un Disparador de Tiempo Base. Por el cuadro con el tiempo MT2 en los medios, una activación estática es debido al MTa de medios_tiempo, de modo que el receptor obtiene una respuesta que contiene un Disparador de Activación el cual tiene un término "t=MTa". Por el cuadro con el tiempo MT3 en los medios el receptor solo obtiene una respuesta que contiene un Disparador de Tiempo Base.

Puede hacer que un receptor reciba más que un Disparador de Activación para la misma activación del evento. Sin embargo, los tiempos en los medios para cada uno de ellos será el mismo, de modo que el receptor puede identificar como duplicados, y solo aplicar uno de ellos.

La figura 25 es un diagrama que muestra una modalidad de activación estática en un caso ACR de solicitud/respuesta.

Se dará una descripción se dará de un caso en que el servidor ACR usa el modelo de solicitud/respuesta.

En la figura 25, el receptor puede enviar firmas para los cuadros vistos en los tiempos LC1, LC2, LC3 del reloj local, etcétera. Los medios_tiempo para el cuadro visto en el tiempo LC1 de reloj local se puede determinar por el servidor ACR a ser MTl, y el receptor solo obtiene una respuesta que contiene un Disparador sin los medios_tiempo o el evento_tiempo. Los medios_tiempo para el cuadro visto en el tiempo LC2 de reloj local se puede determinar por el servidor ACR a ser MT2, y el servidor ACR conoce que una activación estática se debe a la MTa de medios_tiempo, de modo que el servidor ACR envía una respuesta que contiene un Disparador de Activación que tiene un término "d=<desplazamiento>", significa que la MTa de medios_tiempo para la activación es <desplazamiento> de unidades de tiempo después de la MT2. El receptor entonces añade el <desplazamiento> al tiempo LC2 y obtiene la LCa como el tiempo local se deberá activar el evento.

La figura 26 es un diagrama que muestra una modalidad de activación dinámica en un caso ACR de solicitud/respuesta.

Se dará una descripción de un caso en que la activación dinámica ocurre en el caso ACR solicitud/respuesta.

Para las activaciones dinámicas en situaciones cuando el sistema ACR no aprende de la activación de evento hasta que es tarde para enviar el Disparador al receptor por delante del tiempo, el Servidor ACR necesita esperar hasta la siguiente solicitud, y entonces envía un Disparador de Activación. La figura 26 ilustra este caso. El efecto de esto es que las activaciones dinámicas se pueden retrasar tanto como un intervalo de solicitud.

En la figura 26, el receptor puede enviar las firmas para los cuadros que el servidor ACR determina tener los tiempos MT1, MT2 y MT3 en los medios. Para los cuadros con los tiempos MT1 y MT2 en los medios, el receptor solo obtiene una respuesta que contiene un Disparador de Tiempo Base. Cuando una activación dinámica con el tiempo MTa de activación se presenta un poco antes de la MTa de medios_tiempo, el servidor ACR no puede notificar al receptor acerca de la siguiente solicitud desde el receptor, el cual ocurre para el marco con el tiempo MT3 en los medios. En ese tiempo la respuesta del servidor ACR contiene un Disparador de Activación con el tiempo MTa de activación (el cual es un poco en el pasado). En esta situación el receptor puede esperar aplicar el Disparador de Activación tan pronto como llega.

Aquí de nuevo es posible que un receptor reciba más que un Disparador de Activación para la misma activación de evento. Sin embargo, el tiempo en los medios para cada uno de ellos será el mismo, de modo que el receptor puede identificarlos como duplicados, y solo aplicar uno de ellos.

La figura 27 es un diagrama que muestra una modalidad de la activación dinámica en un caso ACR de solicitud/respuesta.

Se dará una descripción de un caso en que ocurre la activación dinámica en el caso ACR de solicitud/respuesta.

En la figura 27, el receptor puede enviar las firmas para los cuadros vistos en tiempos LC1, LC2, LC3, etcétera del reloj local. Los medios_tiempo para el cuadro visto en el tiempo LC1 del reloj local se puede determinar por el servidor ACR a ser MT1, y el receptor solo obtiene una respuesta que contiene un Disparador sin los medios_tiempo o el evento_tiempo. Los medios_tiempo para el cuadro visitado en el tiempo LC2 de reloj local se puede determinar por el servidor ACR a ser MT2, y el servidor ACR no se conoce que una activación dinámica se mostrara en la MTa de medios_tiempo, de modo que el receptor solo obtiene una respuesta que contiene un Disparador sin los medios_tiempo o el evento_tiempo. Cuando una activación dinámica muestra la MTa de medios_tiempo, el servidor ACR no puede notificar el receptor acerca de la siguiente solicitud desde el receptor, el cual ocurre en el tiempo LC3 local. En ese tiempo la respuesta del servidor ACR puede contener un Disparador de Activación con un valor de <desplazamiento> negativo o contiene un disparador de activación "hacerlo ahora".

Se dará una descripción de un servidor ACR que usa un modelo de emisión del evento.

En el modelo ACR de impulsión del evento el receptor puede esperar que inicie una conexión al servidor ACR, genera firmas del contenido periódicamente (por ejemplo, cada 5 segundos), y presenta las firmas sobre la conexión. El servidor ACR no responde a cada firma. Se puede enviar un mensaje al receptor cuando se detecta un segmento nuevo o cuando una activación de evento necesita comunicar al receptor. En este modelo, es posible por el servidor ACR iniciar los mensajes para el cliente en cualquier momento.

Para un servidor ACR que usa este modelo de emisión de evento y se suministra las activaciones al receptor, las reglas siguientes pueden aplicar para los mensajes desde el servidor ACR.

En primer lugar, cuando el servidor ACR recibe una firma desde un receptor que corresponde a un segmento nuevo, el servidor ACR puede enviar un Disparador de Tiempo Base al receptor inmediatamente, solo para permitir que el receptor obtenga la TPT asociada.

En segundo lugar, siempre que un evento se debe activar, el servidor ACR puede enviar un Disparador de Activación al receptor. Si es posible, se puede enviar el Disparador de Activación ligeramente arriba del tiempo cuando el receptor necesita aplicar la misma. (Esto es muy similar al comportamiento en el modelo solicitud/respuesta). Si el servidor ACR aprende de la activación tan tarde que no puede enviar un Disparador de Activación muy por delante del tiempo (el cual puede pasar en el caso de una activación de evento dinámico), aun puede enviar un Disparador de Activación tan pronto como sea posible. En este caso posterior, es posible que el cliente recibirá el mensaje ligeramente después del tiempo de activación, debido a que el mensaje se retrasa, en el caso que el receptor puede esperar que active el evento inmediatamente hasta la recepción del mensaje.

Siempre que un receptor obtiene un Disparador con un localizador_parte nueva, se puede esperar que descargue la TPT nueva inmediatamente, a menos que ya se retrasó usando una URLLista suministrada con una TPT previa.

Se dará una descripción de un sistema ACR de marca de agua que inserta información directamente. Mientras que no se muestra el sistema ACR de marca de agua, el sistema ACR de marca de agua no se limita a la descripción siguiente y se puede cambiar por un diseñador.

En el caso de un sistema de marca de agua que inserta los receptores de información necesarios directamente, la marca de agua asociada con un cuadro puede seguir las mismas reglas como se establece anteriormente por lo que ese servidor ACR de solicitud/respuesta se deberá regresar a ese cuadro como sigue. El servidor ACR de solicitud/respuesta puede regresar a uno desde Nulo, el Disparador de Tiempo Base y el Disparador de Activación.

Una respuesta Nula puede indicar que no se reconoce la firma, o (si el Módulo de Ingesta ACR incluye firmas para los cuadros en los segmentos del programa sin el servicio interactivo) que la firma representa un cuadro que pertenece a un segmento que no tiene un servicio interactivo asociado con este.

Una respuesta del Disparador de Tiempo Base puede indicar que no está prevista la activación del evento después de tomar lugar la siguiente respuesta del cliente. El cliente puede esperar que se usen los Disparadores de Tiempo Base para mantener un reloj de tiempo en los medios.

Una respuesta del Disparador de Activación puede indicar que una activación debe tomar lugar pronto, con el tiempo de la activación indicada por el término "t=" en el Disparador.

En el caso de un sistema ACR de marca de agua suministra la información de los receptores necesaria por incluir la misma directamente en las marcas de agua, de modo que no es necesario el servidor ACR, un Módulo de Ingesta puede seguir las mismas reglas como se describe para el modelo del servidor de solicitud/respuesta antes de determinar el Disparador para asociar con cada cuadro, pero entonces incluye el Disparador en la marca de agua para el cuadro, en lugar de asociar el Disparador con el cuadro en una Base de Datos. El módulo de ingesta y la base de datos se describirán después.

Se dará una descripción del soporte de los servicios NRT independientes. Esto no se muestra pero la presente invención no se limita a la descripción siguiente y se puede cambiar por un diseñador.

Para que un receptor en un ambiente de ACR obtenga acceso a los servicios NRT independientes, el radiodifusor puede necesitar soportar el acceso de Internet a los servicios NRT, y el receptor puede necesitar obtener la SMT y los casos NRT-IT para los servicios.

Se dará una descripción de un protocolo de pregunta para obtener las tablas PSIP y las tablas NRT del Internet.

Sí un radiodifusor soporta este protocolo para un flujo de radiodifusión particular, entonces un receptor conoce la URL desde el Servidor de Señalización del radiodifusor para que el flujo de radiodifusión pueda tomar los pasos siguientes.

Primero, el receptor puede emitir una pregunta para el "conjunto NRT Básico" de las tablas para el flujo de radiodifusión, para un intervalo de tiempo futuro especificado (por ejemplo, después de las 12 horas).

Segundo, Esto procederá a la SMT y a la ILT para cada uno de los canales virtuales NRT independientes, y los casos de NRT-IT y de TFT cubren el intervalo de tiempo especificado.

Una forma en que un receptor puede descubrir la URL del Servidor de Señalización para un flujo de radiodifusión puede ser el del proveedor de un segmento de servicio interactivo en el flujo de radiodifusión puede elegir proporcionar la URL del Servidor de Señalización en un elemento de la URLLista suministrado a lo largo de la TPT.

De otra forma un receptor puede descubrir las URLs de los Servidores de Señalización puede ser por la pre-configuración. En la misma manera que un fabricante de DTV puede preconfigurar un receptor de DTV conocido como para encontrar un Servidor ACR puede cubrir cualquier área de radiodifusión particular, un fabricante del receptor DVT puede pre- configurar un receptor DTV para conocer cómo encontrar un "Servidor de Suministro NRT" que cubre cualquier área de radiodifusión particular. Tal Servidor de Suministro NRT podrá estar disponible para dar al receptor una lista de los flujos de radiodifusión que contienen servicios NRT independientes, a lo largo con la URL del Servidor de Señalización para cada uno.

La figura 28 es un diagrama que muestra una modalidad de una arquitectura para la activación del servidor ACR.

Algunos sistemas ACR incluyen un servidor ACR, y algunos sistemas ACR no lo incluyen. En los sistemas ACR de huella digital, los receptores pueden computar y enviar las firmas de cuadro a un servidor ACR, y el servidor ACR puede enviar de nuevo la información necesaria por los receptores. Por tanto, los sistemas ACR de huella digital incluyen un servidor ACR. En los sistemas ACR de marca de agua, las marcas de agua pueden contener solo códigos que identifican únicamente los cuadros, o las marcas de agua pueden contener la información completa necesaria por los receptores. Cuando las marcas de agua contienen solo códigos, los receptores pueden extraer los códigos y enviar los mismos a un servidor ACR, y el servidor ACR envía de nuevo la información necesaria a los receptores. En el caso cuando las marcas de agua incluyen la información completa, los receptores pueden extraer solo la información que ellos necesitan directamente desde las marcas de agua, y el servidor ACR no es necesario.

En aquellos sistemas ACR que incluyen un servidor ACR, los dos diferentes modelos se pueden usar comúnmente para la comunicación entre los servidores y los receptores: un modelo de solicitud/respuesta y un modelo orientado a eventos.

En el modelo del servidor ACR de solicitud/respuesta el receptor puede esperar que se computen las firmas de, o códigos extraídos de, el contenido periódicamente (por ejemplo cada 5 segundos) y enviar solicitudes que contienen las firmas o códigos a un servidor ACR. Cuando un servidor ACR obtiene una solicitud desde un receptor, este puede regresar una respuesta. La sesión de comunicaciones no se puede mantener abierta entre los casos de solicitud/respuesta. En este modelo, puede que no sea factible para un servidor ACR que inicie los mensajes a un receptor.

Se asume que el radiodifusor del canal es procesado que soporta el modelo de interacción TDO.

Puede haber dos tipos generales de activaciones del evento: las activaciones estáticas en que el tiempo de activación se conoce antes de que la radiodifusión del segmento empieza, y las activaciones dinámicas en que el tiempo de activación determinado dinámicamente conforme el segmento se transmite. En todos los segmentos pregrabados de las activaciones del evento pueden ser estáticas. En los segmentos que se transmiten en programas en vivo, algunas o todas de las activaciones del evento pueden ser dinámicas. Las activaciones estáticas se enlistan típicamente en la Tabla de Mensajes de Activación (AMT), aunque no podrían ser suministradas a los receptores en la forma de Disparadores de Activación. Las activaciones dinámicas se pueden suministrar en la forma de los Disparadores de Activación, ya que su tiempo no se conoce en el tiempo que se genera la AMT.

La figura 28 muestra una arquitectura que soporta los sistemas ACR que usa un servidor ACR. Este es un diagrama de bloques lógico, y no una arquitectura de implementación. Por ejemplo, el Módulo de Ingesta ACR se podría co-localizar con la fuente de radiodifusión, o podría estar en una locación separada.

En la arquitectura que soporta los sistemas ACR que usa un servidor ACR, la arquitectura puede incluir una fuente 28010 de radiodifusión, un módulo 28020 de ingesta ACR, una MVPD 28030, una STB 28040, un receptor 28050, un cliente 28060 de ACR, un servidor 28070 de configuración de ACR, un servidor 28080 de ACR y/o una base de datos 28090.

La Fuente 28010 de Radiodifusión puede ser un punto desde el cual el flujo A/V y se transmiten los servicios interactivos asociados, por ejemplo un punto de distribución de red o una estación de Televisión.

El Módulo 28020 de Ingesta de ACR puede computar firmas (huellas digitales) o cuadros, en el caso de un sistema ACR de huella digital, o insertar las marcas de agua que incluye códigos en los cuadros, en el caso de un sistema ACR de marca de agua que se basa en códigos. Se puede almacenar la base de datos 28090 los medios_tiempode cada cuadro asociado con una firma o código, junto con otros metadatos. El Módulo 28020 de Ingesta ACR podría administrar un solo canal en un flujo de radiodifusión, o un flujo de radiodifusión completo, o flujos de radiodifusión múltiples, o cualquier combinación de los mismos. Para los propósitos, se asume que el Módulo 28020 de Ingesta ACR procesa cuadros para los segmentos del programa que contiene un servicio interactivo. Sin embargo, es posible tener sistemas ACR en que todos los cuadros se procesan, pero aquellos que no son parte de un segmento con un servicio interactivo tienen una indicación que en su entrada de base de datos 28090 que ellos no son parte de un segmento con un servicio interactivo.

Un Distribuidor 28030 del Programa de Video del Programa Múltiple (MVPD) es típicamente un operador por cable, un operador por satélite, o un operador por IPTV. Este puede recibir el flujo de radiodifusión desde la Fuente de Radiodifusión en alguna manera, con las marcas de agua insertadas por el Módulo 28020 de Ingesta ACR en el caso de un sistema ACR de marca de agua, tal sistema despoja a menudo todos los elementos del programa otros que las pistas de audio y video, y envía el flujo resultante a los decodificadores 28040 (STBs) en las instalaciones del cliente.

La STB 28040 típicamente decodifica (descomprime) el audio y el video, y envía los mismos a un conjunto de la Televisión para la presentación a los espectadores. Ellos asumirán que el servicio #6 de Subtítulos DTV, el cual contiene los Disparadores de servicio interactivo, no está disponible al conjunto de la Televisión.

El receptor 28050 puede incluir el cliente 28060 ACR. El cliente 28060 ACR se puede disponer fuera del receptor 28050. La estructura del receptor 28050 se describirá después.

El Cliente 28060 ACR en el receptor 28050 puede obtener los Disparadores de Activación desde el Servidor 28080 ACR y pasa los mismos al código del receptor principal, usando una API provista por ese propósito. Normalmente el cliente 28060 ACR se podría incorporar en el receptor 28050, pero otras configuraciones son posibles.

El Servidor 28070 de configuración ACR puede proporcionar una manera para que los clientes 28060 ACR determinen la locación de un Servidor 28080 de ACR adecuado. Este proceso de descubrimiento se puede lograr en otras formas.

El servidor 28080 ACR puede obtener firmas o códigos desde los receptores y regresa los Disparadores de Activación en tiempos apropiados.

La base de datos 28090 pueden ser unos datos almacenados de algún tipo, no necesariamente una base de datos en el sentido estricto del término, en que la información acerca de los cuadros de audio o video (o ambos) se almacena para el uso de los servidores 28080 de ACR.

La arquitectura de un sistema ACR que usa suministro directo de información en marcas de agua podría no tener la Base de Datos ni el Servidor ACR. El Módulo de Ingesta ACR podría insertar información directamente en los cuadros en el flujo de radiodifusión, en la forma de marcas de agua, en vez de insertar, en unos registros de base de datos que contienen identificadores de cuadros y de la información asociada con los mismos. Los receptores podrían entonces extraer esta información desde los cuadros en la radiodifusión, en vez de obtener la misma desde un servidor ACR.

Se dará una descripción del suministro de los disparadores de activación mediante los servidores ACR de solicitud/respuesta paso a paso. Esta es una modalidad de la presente invención y se puede omitir un paso o se pueden añadir nuevos pasos o se puede cambiar una secuencia.

Una manera eficiente para implementar este comportamiento del servidor ACR es seguir el proceso descrito anteriormente, donde los números de las acciones en el proceso corresponden a los números en el diagrama de arquitectura anterior, como se muestra en la figura 28. 1) El horario de radiodifusión para los segmentos de servicio interactivo y las AMTs o sus equivalentes para cada segmento se puede suministrar al Módulo de Ingesta ACR antes del tiempo que se transmiten los segmentos. El horario de radiodifusión puede contener el segmento ID, el tiempo de inicio del GPS y el tiempo de fin del GPS de cada segmento que puede contener un servicio interactivo asociado con este. Si hay cualesquier cambios de último minuto del horario de radiodifusión, el Módulo de Ingesta ACR puede notificar de esos cambios inmediatamente. El horario de radiodifusión también podría contener el número de versión de la TPT para cada segmento, y el Módulo de Ingesta ACR podría obtener la notificación en tiempo real de cualesquier cambios sin el horario en una versión TPT, de modo que se puede insertar los términos "versión" ("v=") en los Disparadores cuando sea necesario. El Módulo de Ingesta también se podría configurar para insertar los términos "difusión" ("s=") en los disparadores en tiempos adecuados, tal como durante un intervalo especificado en el principio de cada segmento (cuando algunos receptores es probable que soliciten TPTs nuevas al mismo tiempo). 2) Si hay activaciones dinámicas, los enlaces se pueden configurar desde las fuentes de las activaciones dinámicas al Módulo de Ingesta ACR. 3) El flujo de radiodifusión puede dirigir al Módulo de Ingesta ACR. 4) El Módulo de Ingesta ACR puede extraer firmas desde los cuadros (en el caso de un sistema ACR de huella digital) o insertar códigos en los cuadros (en el caso de un sistema ACR de marca de agua), para todos los cuadros contenidos en los segmentos que tienen un servicio interactivo asociados con el mismo. (El Módulo de Ingesta ACR puede determinar si un cuadro está en tal segmento por usar un reloj GPS y los tiempos de inicio y los tiempos de fin de los segmentos en el horario de radiodifusión). Para cada cuadro el Módulo de Ingesta ACR puede insertar un registro en la Base de Datos que puede incluir un Disparador y la firma o código asociado con el cuadro. Las reglas para que el Disparador se inserte se describen en el fin de esta lista de acciones en el proceso. 5) El Flujo de Radiodifusión puede continuar en la MVPD. 6) La MVPD puede dirigir el Flujo de Radiodifusión a la STB en una locación del suscriptor (típicamente excluyendo todo el primer contenido interactivo). 7) La STB puede decodificar la A/V y enviar la A/V sin comprimir al receptor DTV. 8) Cuando el receptor se enciende primero, puede enviar su locación a un Servidor de Configuración ACR. (La URL del Servidor de Configuración ACR se puede incorporar en el receptor). 9) El servidor de Configuración ACR puede enviar de nuevo la URL de un Servidor ACR al receptor para su uso. 10) El cliente ACR en el receptor puede iniciar la extracción de firmas de huella digital o códigos de marca de agua y enviarlos al servidor ACR. 11) Cuando el Servidor ACR recibe una firma o código, puede intentar hacer la coincidencia en la Base de Datos. 12) Si la firma o código no coincide con ninguna firma o código en la Base de Datos, entonces el servidor puede devolver un indicador de "no coincidencia". Si la firma o código coincide con una firma o código en la Base de Datos, entonces el Servidor ACR puede devolver el registro para el cuadro que tiene la firma o código de coincidencia. En el caso posterior el registro en la Base de Datos puede contener un Disparador de Tiempo Base, y/o puede contener uno o más Disparadores de Activación, dependiendo de que si se insertaron en el registro para el cuadro por el Módulo de Ingesta ACR. 13) Si el Servidor ACR obtiene de nuevo un indicador de "no coincidencia" desde la Base de Datos, puede regresar una respuesta NULA al Cliente de ACR. De otra manera el Servidor ACR puede regresar al Cliente ACR el Disparador o Disparadores que se obtienen.

Las siguientes reglas se pueden usar para determinar que el Disparador o Disparadores del Módulo de Ingesta ACR se insertan en cada registro de cuadro en la Base de Datos.

La figura 29 es un diagrama que muestra una modalidad de los disparadores de activación en el caso (b) y el caso (a) sin FinTiempo .

Se puede asumir que hay algún limite Ll superior en la longitud de los intervalos de solicitud usado por clientes ACR individuales en los receptores. (No es importante si los clientes ACR conocen que este es el limite, siempre que operen dentro de la practica). Dejar a L2 ser la longitud de tiempo que toma un cliente ACR típico para computar la firma o extraer la marca de agua asociada con un cuadro, contar desde el tiempo en que el cuadro llega al receptor. Dejar a L3 ser el tiempo de ida y vuelta típico para que un mensaje vaya desde un cliente ACR a un servidor ACR y regrese. Dejar a M = Ll + L2 + L3. (un valor ligeramente mayor de M también se podría usar - la ventaja de un valor ligeramente mayor es que los receptores tienen un pequeño tiempo extra para reaccionar a los Disparadores de Activación; la desventaja es que los receptores son un poco más probables a obtener los Disparadores de Activación múltiples para la misma activación de evento - lo cual no es mucho problema, ya que serán capaces de detectar que se duplica, como se explica anteriormente, y solo aplica la activación una vez).

El Módulo de Ingesta ACR puede insertar solo un Disparador de Tiempo Base en el registro asociado con el cuadro a no ser que al menos una de las siguientes tres condiciones se mantenga: (a) Hay un elemento de Activación en la AMT tal que los medios_tiempo del cuadro está en el principio de intervalo de tiempo en el lapso M de tiempo antes del inicioTiempo del elemento de Activación y terminar en el finTiempo del elemento de activación. (Si una Activación no tiene finTiempo, el finTiempo se considera igual al inicioTiempo). (b) Un Disparador de Activación dinámica se recibió por el Módulo de Ingesta antes gue el intervalo de tiempo del lapso M de tiempo precede inmediatamente al tiempo de activación del Disparador ( "t=<evento_tiempo>"), y el cuadro se encuentra dentro del intervalo. (c) Un Disparador de Activación dinámica se recibió por el Módulo de Ingesta después del principio del intervalo del lapso M de tiempo un poco antes del tiempo de activación del Disparador, y los medios_tiempo del cuadro está en el intervalo del lapso L1 de tiempo que sigue inmediatamente la recepción del Disparador.

Sí cualquiera de las condiciones (a), (b) o (c) se mantiene, entonces un Disparador de Activación se puede incluir en el registro, con un término "e=" para identificar el Evento a activar, y un término "t=" indica el inicioTiempo del elemento de Activación en la AMT (para la condición (a)) o el evento_tiempo del Disparador dinámico (para la condición (b)). El Disparador también puede contener un término de versión ("V=").

La razón para continuar asociando los Disparadores de Activación con cuadros a través del intervalo del inicioTiempo al finTiempo en el caso (a), es acomodar los receptores que unen hasta la mitad del canal a través del intervalo.

Observe que este enfoque no requiere de inteligencia adicional sobre la parte del servidor ACR. Simplemente regresa al Cliente ACR la información que encuentra en la Base de Datos. Toda la inteligencia puede residir en el Módulo de Ingesta ACR. Además, las computaciones del Módulo de Ingesta ACR necesitan ser muy simples.

Con este esquema es posible que un receptor pueda obtener más que un Disparador de Activación (asociado con diferentes cuadros) para la misma activación de evento. Sin embargo, un receptor puede ver fácilmente los valores de "t=" que tienen el mismo tiempo de activación, de modo que el receptor puede determinar que se duplican y activan el evento solo una vez.

En dos de las situaciones anteriores el término "t=" en el Disparador de Activación puede tener un evento_tiempo antes de los medios_tiempo del cuadro con el cual se asocia. En la sitacion (A), si el finTiempo del elemento de Activación es significativamente después que el inicioTiempo, entonces un receptor puede obtener típicamente los Disparadores de Activación a través del intervalo entre el inicioTiempo y el finTiempo, y ellos pueden tener el inicioTiempo como los tiempos de activación. En la situación (c), los Disparadores de Activación para la activación puede ser insertada en los registros de cuadro más tarde que el Disparador de Activación de un receptor puede venir en respuesta a una solicitud con una firma para un cuadro que tiene medios_tiempo después del tiempo de activación. Cuando un receptor obtiene un Disparador de Activación con un evento_tiempo antes de los medios_tiempo del cuadro con el cual este se asocia, se puede esperar que se active el evento inmediatamente, a menos que se reconozca como un duplicado de un Disparador de Activación que ya se ha visto y usado para activar el evento.

El propósito de usar los valores del evento_tiempo en el pasado, en lugar de que los Disparadores "hacerlo ahora", para la situación cuando los medios_tiempo de cuadro se tarda más que el tiempo del evento_activacion es porque un receptor puede obtener más que uno de esos Disparadores de Activación "después del hecho". Los valores "t=" permiten al receptor determinar que todos ellos tengan el mismo tiempo de activación, y activar el evento solo una vez.

La figura 29 ilustra la situación (b) y la situación (a) cuando el elemento de Activación en la AMT no tiene el atributo finTiempo.

La figura 29 muestra un ejemplo de la situación (a) en la acción (4) anterior, en el caso cuando el elemento de Activación en la MAT no tiene un finTiempo. Esto también puede ser un ejemplo de la situación (b) en el paso (4) anterior, donde el Módulo de ingesta ACR se envía a un Disparador de Activación dinámica al menos unidades de tiempo M antes de su tiempo de activación.

La figura 29 muestra un tiempo de activación del evento encima de la linea de tiempo, con un intervalo de longitud M precedente, abarcando intervalos de longitudes Ll, L2 y L3. Las flechas verticales encima de la línea de tiempo muestran los tiempos de los cuadros individuales. Cada cuadro precede el principio del intervalo de longitud M, o sigue el tiempo de activación del evento, podría estar asociado con este en la Base de Datos de un Disparador de Tiempo Base. Cada cuadro dentro del intervalo de longitud M podría estar asociado con este en la Base de Datos de un Disparador de Activación, tal como los dos ejemplos (fl, f2) en el parte inferior de la figura. El término "t=" para cada cuadro podría indicar el tiempo de activación del evento en relación a los medios_tiempo (indicado por el círculo fl y f2).

Cuatro flechas verticales en el círculo pueden representar un ejemplo cuando un receptor tipio envía una respuesta. En este ejemplo el receptor podría obtener dos Disparadores de Activación para el mismo evento de activación, pero ellos podrían tener los mismos tiempos de activación del evento, de modo que el receptor podría reconocerlo como el duplicado y solo aplicar el primero. Debido a que el intervalo entre las solicitudes del receptor es menor que Ll, el receptor garantiza hacer al menos una solicitud con una firma para un cuadro en el intervalo L1 mostrado en el diagrama. Esto le da tiempo para computar la firma, enviar la solicitud al servidor ACR, y obtener el Disparador de Activación de nuevo en respuesta, todo antes del tiempo de activación. En este ejemplo, el primer Disparador de Activación el receptor podría suministrar mucho antes del tiempo (esto es un duplicado).

La figura 30 es un diagrama que muestra una modalidad de los disparadores de activación en el caso (b) y el caso (a) sin FinTiempo.

Se dará una descripción de los disparadores de activación en el caso (b) y el caso (a) sin FinTiempo.

La figura 30 muestra un ejemplo de la situación (a) en la acción (4) anterior, en el caso cuando el elemento de Activación en la AMT no tiene un finTiempo. Esto también es un ejemplo de la situación (b) en el paso (4) anterior, donde el Módulo de Ingesta ACR se envía un Disparador de Activación dinámica al menos las unidades de tiempo M antes de su tiempo de activación.

La figura 30 muestra un tiempo de activación del evento encima de la línea de tiempo, con un intervalo precedente de la longitud M, abarcando los intervalos de las longitudes Ll, L2 y L3. Las flechas debajo de la línea de tiempo muestran los tiempos de los cuadros individuales. Cada cuadro precede el principio del intervalo de longitud M, o siguiente del tiempo de activación del evento, podría estar asociado con este en la Base de Datos de un Disparador sin los <medios_tiempo> o <evento_tiempo>. Cada cuadro interior del intervalo de la longitud M podría estar asociado con este en la Base de Datos de un Disparador de Activación, tal como los dos ejemplos en la parte inferior de la figura. El término "d=" para cada cuadro podría indicar la longitud del tiempo entre el del cuadro y el del tiempo de activación (indicado por el círculo fl y f2).

Cuatro flechas verticales en el círculo pueden representar un ejemplo cuando un receptor típico envía una solicitud. En este ejemplo el receptor podría obtener dos Disparadores de Activación por la misma activación del evento, pero los tiempos de activación computados por añadir el valor <dl> al tiempo local del receptor para el cuadro fl o añadir el valor <d2> al tiempo local del receptor del cuadro f2 ambos dan el mismo resultado, de modo que el receptor puede reconocerlo como el duplicado y solo aplicar el primero. Debido a que el intervalo entre las solicitudes del receptor es menor que Ll, el receptor garantiza hacer al menos una solicitud con una firma para un cuadro en el intervalo Ll mostrado en el diagrama. Esto da tiempo para computar la firma, enviar la solicitud al servidor ACR, y obtener el Disparador de Activación en respuesta, todo antes del tiempo de activación. En este ejemplo, el segundo Disparador de Activación recibido por el receptor podría llegar después del tiempo de activación.

La figura 31 es un diagrama que muestra una modalidad de los disparadores de activación en el caso (a) con FinTiempo.

La figura 31 ilustra la situación (a) en la acción (4) anterior, en el caso cuando el elemento de Activación en la AMT tiene un finTiempo, así como un inicioTiempo.

La figura muestra un inicioTiempo y finTiempo de activación del evento encima de la línea de tiempo, con un intervalo de longitud precedente del inicioTiempo. Las flechas debajo de la línea de tiempo muestran los tiempos de los cuadros individuales. Cada cuadro precedente al principio del intervalo de longitud M, o lo siguiente del finTiempo de la activación del evento, podría estar asociado con este en la Base de Datos de un Disparador de Tiempo Base. Cada cuadro dentro del intervalo de la longitud M o entre el inicioTiempo y el finTiempo de la activación del evento podría tener un Disparador de Activación asociado con este en la Base de Datos, en la forma mostrada por los tres ejemplos en la parte inferior de la figura. El término "t=" para cada cuadro podría indicar el tiempo de activación del evento, en relación a la línea de medios_tiempo (indicado por el círculo fl, f2 y f3).

Tres flechas verticales en el círculo pueden presentar un ejemplo cuando un receptor típico envía una solicitud. En este caso el receptor podría obtener tres disparadores de Activación para la misma activación del evento, pero los tiempos de activación podrían ser los mismos, de modo que el receptor podría reconocer el mismo duplicado y solo aplicar al primero.

Por supuesto, el primero de los dos Disparadores de Activación mostrados en el diagrama podrían no verse todos por un receptor que une el canal después del inicioTiempo y envía la firma del cuadro f3 con su primera solicitud.

La figura 32 es un diagrama que muestra una modalidad de los disparadores de activación en el caso (a) con el FinTiempo.

Se dará una descripción de los disparadores de activación en el caso (a) con el FinTiempo.

La figura 32 ilustra la situación (a) en la acción (4) anterior, en el caso cuando el elemento de Activación en la AMT tiene un finTiempo, así como un inicioTiempo.

La figura muestra un inicioTiempo y finTiempo de activación del evento encima de la línea de tiempo, con un intervalo de la longitud M precedente del inicioTiempo. Las flechas encima de la línea de tiempo muestran los tiempos de los cuadros individuales. Cada cuadro precedente al principio del intervalo de la longitud M, o siguiente al finTiempo de activación del evento, podría estar asociado con este en la Base de Datos de un Disparador sin los términos medios tiempo> o <evento tiempo>. Cada cuadro dentro del intervalo de la longitud M podría tener un Disparador de Activación en la Base de Datos, en la forma mostrada por los dos ejemplos en la parte inferior de la figura. El término "d=" para cada cuadro podría indicar la longitud de tiempo entre ese cuadro y el tiempo de activación del evento (indicado por flechas verticales en el círculo).

Las flechas verticales en el círculo pueden representar un ejemplo cuando un receptor típico envía una solicitud. En este caso el receptor podría obtener tres Disparadores de Activación para la misma activación del evento, pero los tiempos de activación computados por añadir el valor <dl> al tiempo local del receptor para el cuadro fl o añadir el valor <d2> al tiempo local del receptor o el cuadro f2 o por añadir el valor <d3> (negativo) al tiempo local del receptor del cuadro f3 todos dan el mismo resultado, tal que el receptor podría reconocer el mismo como duplicado y solo aplicar el primero .

La figura 33 es un diagrama que muestra una modalidad de los disparadores de activación para el caso ©.

La figura 33 ilustra la situación (c) en la acción (4) anterior, donde un Disparador de Activación dinámica se envía al Módulo de Ingesta ACR más tarde que las unidades de tiempo M antes del Tiempo de Activación.

La figura 33 muestra un tiempo de activación del evento dinámica encima de la linea de tiempo, y un tiempo precedente más corto del tiempo de activación del evento cuando el Módulo de Ingesta ACR aprende de la actuación del evento, con un intervalo de longitud Ll seguido por el tiempo cuando el Módulo de Ingesta ACR aprende de la activación del evento. Las flechas verticales encima de la línea de tiempo muestran los tiempos de los cuadros individuales. Cada cuadro precedente del principio del intervalo de la longitud Ll, o seguido del fin del intervalo de longitud Ll, podría tener un Disparador de Tiempo Base asociado con este en la Base de Datos. Cada cuadro dentro del intervalo de la longitud Ll podría tener un Disparador de Activación en la Base de Datos, tal como uno en el ejemplo en la parte inferior de la figura. El término "t=" para cada cuadro podría indicar el tiempo de activación del evento, en relación a la línea de tiempo en los medios (indicada por las flechas verticales en el círculo). Las flechas verticales en el circulo pueden representar un ejemplo cuando un receptor típico envía una solicitud. En este caso el receptor podría ser solo un Disparador de Activación para la activación del evento. Ya que se recibió el tiempo de activación del Disparador de Activación precede el tiempo, el receptor podría aplicar el Disparador inmediatamente hasta la recepción.

La figura 34 es un diagrama que muestra una modalidad de los disparadores de activación para el caso (c).

Se dará una descripción de los disparadores de activación para el caso (C).

La figura 34 ilustra la situación (c) en la acción (4) anterior, donde un Disparador de Activación dinámica se envía al Módulo de Ingesta ACR más tarde que las unidades de tiempo M antes del Tiempo de Activación.

La figura 34 muestra un tiempo de activación del evento dinámico encima de la línea de tiempo, y un tiempo más corto precedente del tiempo de activación del evento cuando el Módulo de Ingesta ACR aprende de la actuación del evento, con un intervalo de la longitud M seguida del tiempo cuando el Módulo de Ingesta ACR aprende de la activación del evento. Las flechas encima de la línea de tiempo muestran los cuadros individuales. Cada cuadro precedente del principio del intervalo de longitud M, o seguido del extremo del intervalo de la longitud M, podría tener un Disparador en la Base de Datos sin los términos <medios_tiempo> o <evento_tiempo>. Cada cuadro dentro del intervalo de la longitud M podría tener un Disparador de Activación en la Base de Datos, tal como aquellos en los dos ejemplos en la parte inferior de la figura. El término "d=" para cada cuadro podría indicar la longitud de tiempo entre ese cuadro y el tiempo de activación del evento (indicado por flechas verticales en el circulo). Las flechas verticales en el circulo pueden representar un ejemplo cuando un receptor típico envía una solicitud. En este caso el receptor podría obtener dos Disparadores de Activación para la misma activación del evento, pero los tiempos de activación computados por añadir el valor <dl> (negativo) al tiempo local del receptor para el cuadro fl y añadir el valor <d2> (negativo) al tiempo local del receptor de cuadro f2 ambos dan el mismo resultado, de modo que el receptor podrá reconocer el mismo como duplicado, y solo aplicar el primero recibido. Ya que el tiempo de activación del primer Disparador es antes de que se recibió el tiempo, el receptor podría aplicar el Disparador inmediatamente cuando este se recibe.

La figura 35 es un diagrama que muestra una modalidad de los disparadores de activación dinámica suministrados al Último Minuto.

En el modelo ACR de emisión de evento del receptor puede esperar que inicie una conexión persistente al servidor ACR, generar firmas asociadas con los cuadros en intervalos regulares (por ejemplo, cada 5 segundos), y presentar las firmas sobre la conexión. El servidor ACR no responde a cada firma.

Se puede enviar un mensaje al receptor cuando un segmento nuevo se detecta o cuando una activación de evento necesita comunicar al receptor. En este modelo, es posible por el servidor ACR iniciar los mensajes del cliente en cualquier tiempo sobre la conexión persistente.

Además, es sencillo para el servidor mantener una cierta cantidad de información acerca de cada receptor, tal como el segmento ID (<localizador_parte> de un Disparador) que corresponde a la presentación más reciente desde el receptor y los Disparadores de Activación enviados al receptor.

Para un servidor ACR que usa este modelo de emisión de evento y se suministran las activaciones a los receptores, las reglas siguientes pueden aplicar para los mensajes desde el servidor ACR.

Primero, cuando el servidor ACR recibe una firma desde un receptor que corresponde a un cuadro en un segmento nuevo, el servidor ACR puede enviar un mensaje al receptor con un Disparador de Tiempo Base inmediatamente, permitir al receptor obtener la TPT asociada.

Segundo, cuando el servidor ACR recibe una firma desde un receptor que corresponde a un cuadro en una parte de un segmento que tiene un número de versión nuevo para la TPT (diferente de la versión más reciente que el receptor ha visto), el servidor ACR puede enviar un mensaje inmediatamente al receptor con un Disparador de Tiempo Base que tiene un término "v=" que permite al receptor obtener la versión nueva de la TPT asociada.

Tercero, cuando un evento se debe activar, el servidor ACR puede enviar un Disparador de Activación al receptor. Si es posible, puede enviar el Disparador de Activación ligeramente encima del tiempo cuando el receptor necesita aplicarlo, con un término "t=" en el Disparador de Activación que indica el tiempo de activación en relación a la linea de tiempo media. (Esto es muy similar al comportamiento en el modelo de solicitud/respuesta). Si el servidor ACR aprende de la activación tan tarde que no puede enviar un Disparador de Activación en la medida encima del tiempo como usual, puede enviar el Disparador de Activación tan pronto como se aprende de la activación. (En este caso posterior, el receptor podría obtener el Disparador de Activación después de su tiempo de activación, en que el caso puede esperar activar el evento tan pronto como se obtiene el Disparador de Activación).

La arquitectura para el caso Solicitud/Respuesta mostrado en la figura 28 también es adecuado para este caso de Emisión del Evento, con una diferencia. La diferencia es que para el caso de Emisión del Evento puede ser una acción (2a) nueva. Si hay cualesquier Disparadores de Activación dinámica, entonces las conexiones se pueden establecer entre el Módulo de Ingesta ACR y todos los Servidores ACR que usan la Base de Datos poblada por el Módulo de Ingesta ACR, de modo que el Módulo de Ingesta ACR puede enviar los Disparadores de Activación dinámica seleccionada para los Servidores ACR.

Las acciones numeradas por el caso de Emisión del Evento pueden ser similares a aquellas del caso de Solicitud/Respuesta. Además la acción (2a), la acción (4) es un poco diferente, la acción (13) es un poco diferente, y se añade una acción (14 nueva.

En la acción (4) el Módulo de Ingesta ACR puede extraer firmas desde los cuadros (en el caso de un sistema ACR de huella digital) o inserta los códigos en los cuadros (en el caso de un sistema ACR de marca de agua), para todos los cuadros contenidos en los segmentos que tienen un servicio interactivo asociado con el mismo. (El Módulo de Ingesta ACR puede determinar si un cuadro está en tal segmento por usar un reloj GPS y los tiempos de inicio y los tiempos de fin de los segmentos en el horario de radiodifusión). Para cada cuadro del Módulo de Ingesta ACR puede insertar un registro en la Base de Datos que puede incluir la firma o código asociado con el Cuadro y un Disparador. El Disparador incluido en el registro por el Módulo de Ingesta ACR puede ser un Disparador de Tiempo Base a menos que una de las siguientes dos condiciones se mantenga: (a) Hay un elemento de Activación en la AMT tal que los medios_tiempo del cuadro están en el principio del intervalo de tiempo en el lapso M de tiempo antes del inicioTiempo del elemento de Activación y terminar en el finTiempo del elemento de Activación. (Si una activación no tiene finTiempo, el finTiempo se considera igual al inicioTiempo). (La misma como la condición (a) para el modelo de ACR Solicitud/Respuesta) (b) Un Disparador de Activación dinámica se recibe por el Módulo de ingesta antes que el intervalo del lapso M de tiempo inmediatamente precedente al tiempo de activación del Disparador ( "t=<evento_tiempo>"), y el cuadro se encuentra dentro de ese intervalo. (Alguna como la condición (b) para el modelo ACR de Solicitud/Respuesta) Si cualquiera de las condiciones (a) o (b) se mantiene, entonces un Disparador de Activación se puede incluir en el registro, con un término "e=" identifica el Evento a activar, y un término "t=" para indicar el inicioTiempo del elemento de Activación en la AMT (para la condición (a)) o el evento_tiempo del Disparador dinámico (para la condición (b)).

Si se recibe un Disparador de Activación dinámica por el Módulo de Ingesta durante el intervalo del lapso M de tiempo inmediatamente precedente al tiempo de activación del Disparador (donde M tiene el mismo significado como en el caso del servidor de solicitud/respuesta), entonces el Módulo de Ingesta puede pasar el Disparador de Activación sobre todos los Servidores ACR que usan la Base de Datos en el que el Módulo de Ingesta puede insertar los registros, sin poner cualquier cosa en la Base de Datos que concierne al Disparador de Activación dinámica. (Las variaciones en esta arquitectura son posibles en los que los Disparadores de Activación dinámica se pasan directamente desde las fuentes del Disparador de Activación dinámica a los servidores ACR sin ir a través del Módulo de Ingesta, pero los servidores ACR obtienen los Disparadores de Activación dinámica que llega más tarde que las unidades de tiempo M encima del tiempo de activación, de modo que puede enviar un mensaje a los receptores inmediatamente relevantes. Puede ser demasiado tarde si espera hasta las próximas presentaciones del receptor).

En la acción (13), si el servidor ACR obtiene de nuevo un indicador "sin coincidencia" desde la Base de Datos después de no recibir uno para la presentación inmediatamente precedente, se puede enviar un mensaje NULO al receptor. Si se obtiene de nuevo un Disparador con un <localizador_parte> que es diferente del <localizador_parte> que va de nuevo por la presentación inmediatamente precedente, se puede enviar el Disparador al receptor. En ambos casos esto puede indicar al receptor que cualquier canal que se está viendo se ha cambiado, o el segmento que se está viendo ha llegado a su fin, de modo que el receptor puede terminar cualquier TDO que se ejecuta actualmente, y si es necesario descargar una TPT nueva. Si el Servidor ACR obtiene de nuevo uno o más Disparadores de Activación, se puede enviar el mismo al receptor, descartar cualquiera que se duplique de los Disparadores de Activación que ya se ha enviado al receptor. De otra manera el Servidor ACR puede ser nada.

En una acción (14) nueva, si un Servidor ACR recibe un Disparador de Activación dinámica, se puede comparar el <localizador_parte> del Disparador de Activación dinámica con el <localizador_parte>actual para cada uno de sus clientes ACR (donde el <localizador_parte> actual para un cliente es el <localizador_parte> del Disparador que el Servidor ACR va desde la Base de Datos para la presentación más reciente desde el cliente ACR. Para cada cliente donde el <localizador_parte> coincide, el Servidor ACR puede enviar el Disparador de Activación al cliente.

La figura 29 y 31 muestran la administración de los Disparadores para las activaciones estáticas y para las activaciones dinámicas que se suministran al Módulo de Ingesta ACR al menos en las unidades de tiempo M antes de su tiempo de activación. La diferencia es que el Servidor ACR puede descartar los Disparadores de activación duplicados, en lugar de enviarlos a los receptores.

La figura 35 muestra un ejemplo de la administración de un Disparador de Activación dinámica recibida sobre una noticia corta (menos que las unidades de tiempo M antes de su tiempo de activación).

La figura 35 muestra un tiempo de activación del evento dinámico encima de la linea de tiempo, y un tiempo poco antes del tiempo de activación del evento cuando el Módulo de Ingesta ACR aprende de la actuación del evento. Las flechas verticales encima de la linea de tiempo muestran los tiempos de los cuadros individuales. Tan pronto como el Servidor ACR recibe el Disparador de Activación desde el Módulo de Ingesta ACR, se puede enviar el Disparador de Activación para todos los receptores que ven actualmente el segmento asociado con el Disparador de Activación (como se identifica por el <localizador_parte> del Disparador).

La figura 36 es un diagrama que muestra una modalidad de los disparadores de activación dinámica suministrados al Último Minuto.

Se dará una descripción de los disparadores de activación dinámica suministrados al Último Minuto.

La figura 36 muestra un ejemplo de la administración de un Disparador de Activación dinámica a corto plazo (menos que las unidades de tiempo M antes de su tiempo de activación).

La figura, los Disparadores de Activación Dinámica Suministrados a Último Minuto, muestran un tiempo de activación del evento encima de la linea de tiempo, y un tiempo un poco precedente al tiempo de activación del evento cuando el Módulo de Ingesta ACR aprende del accionamiento del evento. Las flechas encima de la linea de tiempo muestran los tiempos de los cuadros individuales. Tan pronto como el servidor ACR recibe el Disparador de Activación desde el Módulo de Ingesta ACR, se puede enviar el Disparador de Activación a todos los receptores que se ven actualmente de los segmentos asociado con el Disparador de Activación (como se identifica por el <localizador_parte> del Disparador). Para cada receptor se ajusta el evento_tiempo del Disparador a un <retraso_tiempo> en relación al cuadro correspondiente a la firma presentada más recientemente desde el receptor.

La figura 37 muestra un diagrama de secuencia entre un cliente ACR y otros servidores en un caso ACR de solicitud/respuesta.

La figura 37 muestra un diagrama de secuencia de acuerdo a una modalidad de transmisión efectiva de un disparador y una TPT de acuerdo al protocolo de operación del servidor ACR y al receptor (cliente ACR) en el modelo solicitud/respuesta.

Se describirá ahora una operación ejemplar del modelo de solicitud/respuesta en el orden de la solicitud y la respuesta.

El diagrama de secuencia entre el cliente ACR y otros servidores en un caso ACR de solicitud/respuesta puede incluir la solicitud 1 ACR (S37010), la respuesta 1 ACR (S37020), la solicitud 2 ACR (S37030), la respuesta 2 ACR (S37040), la solicitud 1 HTTP (S37050), la respuesta 1 HTTP (S37060), la solicitud 2 HTTP (S37070), la respuesta 2 HTTP (S37080), la solicitud 3 ACR (S37090), la respuesta 3 ACR (S37100), la solicitud 4 ACR (S37110) y /o la respuesta ACR 4 (S37120).

La solicitud 1 ACR (S37010) es un paso en que el receptor transmite la firma de un programa visto actualmente a un servidor. El Servidor puede ser el servidor ACR descrito anteriormente. La firma puede ser una firma de huella digital o una marca de agua.

La respuesta 1 ACR (S37020) es un paso en que el servidor ACR regresa NULO cuando la firma no se reconoce o un servidor interactivo no está presente. Esto puede ser un caso correspondiente al caso mencionado anteriormente en el cual una respuesta NULA se regresa.

La solicitud 2 ACR (S37030) es un paso en que, cuando el canal o programa se camia, el receptor transmite la firma del programa cambiado al servidor ACR.

La respuesta 2 ACR (S37040) es un paso en que el servidor ACR regresa un disparador (por ejemplo xbc.com/tpt504) incluye una dirección por la que se puede obtener un servicio interactivo relacionado al programa correspondiente. Este paso puede corresponder a un caso en que la firma se reconoce y un servicio interactivo relacionado está presente, la respuesta 1 ACR sin enlace (S37020). Esto es, un disparador está disponible en este paso. En este caso, el disparador regresado puede ser una base de tiempo que no tiene información acerca de los medios_tiempo.

La solicitud 1 HTTP (S37050) es un paso en que el receptor solicita el servidor TPT (por ejemplo http://xbc.com/tpt504) para proporcionar una TPT correspondiente usando la dirección recibida en la respuesta 2 ACR (S37040) a través del protocolo http.

La respuesta 1 HTTP (s37060) es un paso en que el servidor TPT transmite la TPT representada en la XML en la solicitud del receptor.

La solicitud 2 HTTP (S37070) es un paso en que el receptor solicita al servidor del contenido proporcionar una aplicación tal como la TDO que usa el protocolo http. El receptor puede analizar la información relacionada da TDO incluida en la TPT. La información relacionada de la TDO puede ser la URL del servidor de contenido a través del cual una TDO se puede descargar. Una solicitud se puede enviar usando la URL del servidor de contenido.

La respuesta 2 HTTP (S37080) es un paso en que el servidor de contenido transmite la TDO correspondiente en la solicitud del servidor.

La solicitud 3 ACR (S37090) es un paso en que el receptor envía la firma de un cuadro del programa visto actualmente al servidor ACR.

La respuesta 3 (S37100) es un paso en que el servidor ACR regresa un disparador (por ejemplo xbv.com/tpt504) que incluye una dirección a través de la cual se obtiene un servicio interactivo relacionado al programa correspondiente. En este caso, la firma se reconoce y el servicio interactivo relacionado está presente, la respuesta 1 ACR diferente (S37020). Esto es, un disparador está disponible en este paso.

La solicitud 4 ACR (S37110) es un paso en que el receptor transmite la firma de un cuadro del programa visto actualmente al servidor ACR.

La respuesta 4 (S37120) es un paso en que el servidor ACR transmite un disparador de activación relacionado al servicio interactivo relacionado a la firma transmitida desde el receptor. Un evento especifico se puede activar en un tiempo especifico de acuerdo al disparador de activación.

La figura 38 muestra un diagrama de secuencia entre el cliente ACR y los otros servidores en un caso ACR de emisión de evento.

La figura 38 muestra un diagrama de secuencia de acuerdo a una modalidad de transmitir efectivamente un disparador y una TPT de acuerdo al protocolo de operación del servidor ACR y al receptor (cliente ACR) en un modelo de emisión de evento.

Una operación ejemplar del modelo de impulsión de evento en el orden de la solicitud, respuesta a la solicitud y el evento se describirá ahora.

El diagrama de secuencia entre el cliente ACR y los otros servidores en un caso ACR de emisión de evento puede incluir la solicitud 1 ACR (S38010), la solicitud 2 ACR (S38020), el evento 1 ACR (S38030), la solicitud 1 HTTP (S38040), la respuesta 1 HTTP (S38050), la solicitud 2 HTTP (S38060), la respuesta 2 HTTP (S28070), la solicitud 3 ACR (S38080), el evento 2 ACR (S38090) y/o la respuesta 4 ACR (S38100).

La solicitud 1 ACR (S38010) es un paso en que el receptor transmite la firma de un programa visto actualmente a un servidor. La firma puede ser una firma de huella digital o una marca de agua. Aquí, cuando la firma no se reconoce o un servicio interactivo relacionado no está presente, el servidor ACR puede no enviar respuesta a la solicitud 1 ACR sin regresar a NULO, a diferencia de la secuencia de la figura 37.

La solicitud 2 ACR (S38020) es un paso en que, cuando se cambia el canal o el programa, el receptor transmite la firma del programa cambiado al servidor ACR.

El evento 1 de ACR (S38030) es un paso en que el servidor ACR regresa un disparador (por ejemplo xbc.com/tot504) incluye una dirección por la cual un servicio interactivo relacionado al programa correspondiente se puede obtener. Este paso puede corresponder a un caso en que la firma se reconoce y un servicio interactivo relacionado está presente. Esto es, un disparador está disponible en este paso. En este caso, el disparador regresado puede ser un disparador de tiempo base no tiene información acerca de los medios_tiempo.

La solicitud HTTP (S38040) es un paso en que el receptor solicita al servidor TPT (por ejemplo http://xbc.com/tpt504) proporcionar una TPT correspondiente usando la dirección recibida en el evento 1 ACR (S38030) a través del protocolo http.

La respuesta 1 HTTP (s38050) es un paso en que el servidor TPT transmite la TPT representada en la CML en la solicitud del receptor.

La solicitud 2 HTTP (S38060) es un paso en que el receptor solicita al servidor de contenido proporcionar una aplicación tal como TDO usando el protocolo http. El receptor puede analizar la información relacionada TDO incluida en la TPT. La información relacionada TDO puede ser la URL del servidor de contenido a través del cual una TDO se puede descargar. Una solicitud se puede enviar usando la URL desde el servidor de contenido.

La respuesta 2 HTTP (S38070) es un paso en que el servidor de contenido transmite la TDO correspondiente en la solicitud del receptor.

La solicitud 3 ACR (S38080) es un paso en que el receptor envía la firma de un cuadro del programa visto actualmente al servidor ACR.

El evento 2 (S38090) es un paso en el que el servidor ACR transmite un disparador de activación relacionado al servicio interactivo relacionado a la firma transmitida desde el receptor. Un evento específico se puede activar en un tiempo específico de acuerdo al disparador de activación.

La solicitud 4 ACR (S38100) es un paso en que el receptor transmite la firma de un cuadro del programa visto actualmente al servidor ACR.

La figura 39 es un diagrama que muestra una modalidad de una Lista de Acción de un Servicio del Cliente RemotoUI UPnP.

El segundo soporte de pantalla se refiere a un método de, en un receptor, proporcionar un servicio de un radiodifusor o servicio suplementario adecuado para un programa provisto por el radiodifusor a un segundo dispositivo de pantalla. El contenido suplementario se puede proporcionar mediante una aplicación y la aplicación se puede visualizar en una pantalla de televisión tal que un usuario utiliza el contenido suplementario por manipular un controlador remoto. Sin embargo, recientemente, mediante los instrumentos de información personalizados (teléfonos inteligentes, tabletas inteligentes y ordenadores portátiles), los servicios suplementarios se pueden visualizar en el segundo dispositivo de pantalla mientras que visualiza el contenido reproducido de nuevo en la pantalla de televisión. Por lo tanto, el usuario puede utilizar personalmente los servicios suplementarios sin interrumpir el contenido de radiodifusión. Si tales datos o información suplementaria se visualiza y procesa en el segundo dispositivo de pantalla, cuando varias personas miran la televisión juntos, solo una persona interesada en un servicio suplementario puede obtener el contenido suplementario sin interrumpir la visualización de la televisión de las otras personas. El segundo soporte de pantalla se puede usar variadamente además de los efectos descritos anteriormente.

Para la conexión y el control de un dispositivo a otros dispositivos, primero, que los dispositivos se incluyen en una red doméstica se deberán determinar. En consecuencia, uno o más dispositivos transmiten periódicamente mensajes a la red doméstica de modo que notifica que los dispositivos están presentes en la red doméstica. Si un dispositivo se conecta nuevamente a la red doméstica, el dispositivo puede preguntar que dispositivos están presentes en la red doméstica antes de notificar que el dispositivo se conecta nuevamente. Tales métodos de conexión puede ayudar a reconocer fácilmente y rápidamente la presencia de los dispositivos. El descubrimiento del dispositivo UPnP es un método que logra esto. Si un dispositivo se detecta, otros dispositivos de interesados en el dispositivo detectado pueden requerir información acerca del cual los servicios pueden proporcionar a ese dispositivo. Los aparatos electrónicos en el que un marco UPnP se instala pueden confirmar funciones mutuas y soportar rangos de función. Esta información se puede definir en un Perfil del Dispositivo UPnP tal que los dispositivos confirman atributos de los servicios provistos mutuamente. Siempre se puede esperar un dispositivo para proporcionar un servicio especifico. Si el dispositivo para proporcionar el servicio especifico se detecta, es posible preguntar qué servicios se incluyen en el dispositivo detectado. Si un servicio deseado está presente en el dispositivo detectado, el dispositivo detectado se puede conectar inmediatamente para realizar la comunicación. Como se define en el Descriptor de Servicio UPnP, los servicios se pueden definir e intercambiar.

Ya que un dispositivo tiene un servicio solo o una pluralidad de servicios, el(los) servicio (s) se puede controlar y utilizar por otros dispositivos. Si el dispositivo tiene una o más funciones, una pluralidad de servicios que corresponden a las funciones se incluye y controlan por otros dispositivos. La definición del dispositivo puede tener información única a cerca del dispositivo. Por ejemplo, la información única acerca del dispositivo puede incluir información tal como el Nombre del Modelo, Número de Serie, Número de Modelo, Nombre del Fabricante CE y el Sitio de Red. La información puede tener un valor único para cada dispositivo y no se puede cambiar generalmente. El servicio es una operación realizada por un dispositivo, el cual se refiere a él como una acción, y cada dispositivo puede tener una o más acciones. La acción tiene un valor del parámetro tal como una función y puede tener uno o más valores del parámetro. La acción se realiza por un servicio de un dispositivo y un valor de retorno definido según sea necesario puede regresar después de realizar la acción.

Como un ejemplo de una acción, la figura 39 muestra los tipos de acciones de un servicio de Cliente RemotoUI UPnP y una descripción del mismo. La conexión/desconexión puede ser una acción para regresar los estados de conexión actuales.

ObtenerActualConexión puede ser una acción para regresar una lista de conexión actual. ObtenerDispositivoPerfil puede ser una acción para regresar un dispositivo de perfil expresado en XML. ObtenerUILista puede ser una acción para regresar una lista UI compatible expresada en XML. AñadirUIlista/RemoverUILista puede ser una acción para añadir una URL de una UI remota a una lista UI o remver la URL de la UI remota desde la lista UI. El ProcesoEntrada puede ser una acción para enviar datos a un servicio de Cliente RemotoUI. La PantallaMensaje puede ser una acción para visualizar un mensaje en un dispositivo que incluye un servicio de Cliente RemotoUI.

La figura 40 es un diagrama que muestra una modalidad de un Servicio de Cliente RemotoUI UPnP.

En la UPnP, un formato del mensaje XML tal como SOAP se puede usar para transmitir las acciones descritas anteriormente y los valores de parámetros necesarios y SOAP se pueden usar para realizar remotamente un procedimiento remoto. Esos mensajes se pueden transmitir usando una HTTP.

Las acciones del Cliente RemotoUI descrito anteriormente se pueden realizar como se muestra en la figura 40. Las acciones mostradas en la figura 40 son solo ejemplos de las acciones descritas anteriormente.

Una modalidad del Servicio del Cliente RemotoUI UPnP se puede dividir en un Proceso de Descubrimiento UPnP y las Acciones del Cliente RemotoUI.

El Proceso de Descubrimiento UPnP puede incluir ejecutar una aplicación UPnP para un segundo servicio de pantalla (s40001), encontrar los dispositivos UPnP (s40010), encontrar un RemotoUICliente (s40020), solicitar una descripción del dispositivo (s40030), recibir una descripción del dispositivo (s40040), solicitar una descripción del control de servicio (s40050) y/o recibir una descripción de control del servicio (S40060).

Las Acciones del Cliente RemotoUI pueden incluir solicitar un perfil del dispositivo (s40070), recibir un perfil del dispositivo (s40080), poner una URL de un UI Remoto (s40090), enviar una respuestal (s40100), enviar un mensaje al Servicio del Cliente RemotoUI (s40110), enviar una respuesta2 (s40120) y/o el usuario presiona el botón en la pantalla (S40130).

Ejecutar una aplicación UPnP para un segundo servicio de pantalla (s40001) puede incluir ejecutar una aplicación UPnP en un segundo dispositivo de la pantalla (Cliente RemotoUI).

Encontrar los dispositivos UPnP (s40010) puede incluir un dispositivo de multidifusión primario de un mensaje de descubrimiento a las aplicaciones que se ejecutan en el segundo dispositivo de pantalla. Por este paso, el segundo dispositivo de la pantalla en la red se puede encontrar. El dispositivo primario puede indicar un segundo servicio de soporte de pantalla provista de ese modo mediante el mensaje de descubrimiento.

Encontrar un RemotorUICliente (s40020) puede incluir el segundo dispositivo de la pantalla que recibe el mensaje de descubrimiento y enviar un mensaje de notificación al dispositivo primario.

Solicitar una Descripción del Dispositivo (s40030) puede incluir la solicitud del dispositivo primario de una descripción del dispositivo para el segundo dispositivo de la pantalla desde el segundo dispositivo de pantalla.

Recibir una descripción del dispositivo (s40040) puede incluir la recepción del dispositivo primario del perfil del dispositivo del segundo dispositivo de la pantalla cuando el segundo dispositivo de la pantalla transmite el perfil del dispositivo del segundo dispositivo de la pantalla en respuesta a la solicitud de Descripción del Dispositivo (S40030).

Solicitar una descripción del control de servicio (s40050) puede incluir la solicitud del dispositivo primario de una descripción de control del servicio desde el segundo dispositivo de pantalla.

Recibir una descripción de control del servicio (s40060) puede incluir la recepción del dispositivo primario de la descripción de control del servicio solicitado desde el segundo dispositivo de pantalla.

El dispositivo primario y el segundo dispositivo de la pantalla presentes en la red pueden encontrar y reconocer entre si el Proceso de Descubrimiento UPnP. Además, el dispositivo primario y el segundo dispositivo de la pantalla pueden conectarse uno con otro.

Solicitar un perfil del dispositivo (s40070) puede incluir la solicitud del perfil de dispositivo del segundo dispositivo de pantalla. La acción de ObtenerDispositivoPerfil descrito anteriormente se puede utilizar.

Recibir un perfil del dispositivo (s40080) puede incluir la recepción del dispositivo primario del perfil del dispositivo solicitado del segundo dispositivo de pantalla. Un dispositivo (segundo dispositivo de la pantalla y Cliente RemotoUI) que tiene "Servicio de Cliente RemotoUI" puede ser responsable de encontrar y visualizar una dirección URL de una UI en la pantalla si un dispositivo remoto (dispositivo primario) envía la dirección URL de la UI. Además, el dispositivo tiene el "Servicio del Servidor RemotoUI" puede ser la multidifusión de la dirección URL de la UI para notificar los dispositivos interesados de la dirección de la URL. Sin embargo, en este caso, ya que las UIs remotas se hacen para un dispositivo específico, la UI remota adecuada para el dispositivo específico se deberá proporcionar. En consecuencia, la información del perfil del dispositivo también necesita transmitir y solicitar el perfil del dispositivo (s40070) y recibir el perfil del dispositivo (s40080) puede ser necesaria.

Poner una URL de una UI Remoto (s40090) puede incluir notificar el segundo dispositivo de la pantalla de la dirección URL de la UI Remota. La acción AñadirUILista descrita anteriormente se puede utilizar. El segundo dispositivo de la pantalla puede añadir la dirección URL de la UI remota a la UILista.

Enviar una respuestal (s40100) puede incluir enviar el resultado de poner la URL de la UI Remota (s40090). De acuerdo a la circunstancia, una respuesta tal como HTTP/1.1200 OK (la solicitud se procesa exitosamente), el Método HTTP/1.15010 No Implementado (una función necesaria para procesar la solicitud no se implementa), y HTTP/1.1 400 No Encontrada (Los archivos/fuentes Solicitadas no se presentan) se puede enviar.

Enviar un mensaje al Servicio del Cliente RemotoUI (s40110) puede incluir la transmisión del dispositivo primario de un mensaje de pantalla al segundo dispositivo de pantalla. La PantallaMensaje descrito anteriormente se puede utilizar. El segundo dispositivo de la pantalla puede proyectar el mensaje en la segunda pantalla de acuerdo al mensaje de pantalla.

Enviar una respuesta2 (s40120) puede incluir enviar un resultado de enviar el mensaje al Servicio del Cliente RemotoUI (s40110). Similarmente al enviar la respuestal (s40100), una respuesta tal como HTTP/1.1 200 OK se puede enviar.

El usuario presiona el botón en la pantalla (s40130) puede incluir la realización de selección del usuario de acuerdo al mensaje proyectado en la segunda pantalla.

Las Acciones del cliente RemotoUI describe el proceso de operación del servicio del Cliente RemotoUI mediante las acciones descritas anteriormente.

En la descripción de la interfaz de usuario remota, las funciones que se pueden usar en un sistema de PC existente se pueden simplificar en consideración de las fuentes de un aparato electrónico, la función de la cual se añade o restringe tal que una aplicación de base HTML se puede usar en los aparatos electrónicos. Esta descripción puede incluir grandemente dos puntos de vista: aplicar una HTML visualizada en una pantalla para los electrónicos del consumidor y definir un navegador API que es aplicable a los electrónicos del consumidor. El navegador API se puede llamar y usar desde la JavaScript, que se usa ampliamente un lenguaje de programación. Como un resultado, la API llamada desde el JavaScript llama una función de un receptor.

Entre otros, el dispositivo UPnP descrito anteriormente y los servicios se pueden ejecutar por la JavaScript ejecutada en el navegador. Hay una necesidad para una API nueva para suministrar otros parámetros a los dispositivos UPnP en el navegador .

La figura 41 es un diagrama que muestra una modalidad de un Disparador en el Servicio DTVCC Número 6.

Como se describe anteriormente, el disparador descrito anteriormente se puede transmitir usando un servicio de subtítulos de Televisión digital (DTVCC). El disparador puede tener un valor de cadena URL y se puede recibir como las series #6 de servicio DTVCC. Un procesador 41010 de transporte MPEG-2 puede recibir el disparador como la serie #6 de servicio DTVCC y transmite el disparador a un módulo 41040 DTV-CC mediante un controlador 41020 del procesador del transporte. En este momento, los datos del usuario pueden pasar a través de una memoria intermedia 41030. El módulo 41040 de DTV-CC puede servir como un Decodificador DTVCC. El módulo 41040 de DTV-CC puede enviar el disparador que tiene un valor de cadena URI a un módulo 41050 del servicio adjunto. El módulo 41050 del servicio adjunto es un módulo del disparador que puede detectar un valor de Cadena URI de modo que adquiere la TPT descrita anteriormente (tabla de los Parámetros TDO). Como se describe anteriormente, es posible para proporcionar un servicio adjunto usando el disparador la TPT y a TDO.

La figura 42 es un diagrama que muestra una modalidad de una arquitectura del sistema para un segundo escenario de pantalla.

Para el segundo soporte de pantalla, puede haber varios requerimientos. 1) El receptor se puede conectar a uno o más segundos dispositivos de pantalla.2) El segundo dispositivo de la pantalla puede ser un dispositivo portable tal como un ordenador portátil, tableta, teléfono inteligente, o PDA.3) El contenido primario de la segunda pantalla puede ser HTML, Texto, Video, Audio, etcétera.4) El contenido reproducido de nuevo en la segunda pantalla se puede designar de modo que no interrumpe un programa de radiodifusión del dispositivo primario (receptor).5) La segunda pantalla se puede conectar a un receptor ATSC 2.0 directamente o indirectamente mediante una red 3GPP. 6) El proveedor puede visualizar el contenido especifico de señal solo en la segunda pantalla.7) de acuerdo a las circunstancias, el contenido reproducido de nuevo por el receptor se puede designar para volver a reproducirse por la segunda pantalla. 8) La segunda pantalla sujeta a autentificación y autorización puede usar un segundo servicio de pantalla. 9) El uso de Audiencia del contenido de la segunda pantalla se puede medir. (En este caso, para obtener tal información, se debe obtener el consentimiento del usuario y una función para tal información puede ser necesaria) y 10) Esto se puede proporcionar mediante un dispositivo capaz de mejorar el lenguaje o contenido secundario.

Esta especificación puede describir los servicios que se pueden proporcionar por un Receptor para soportar la pantalla del contenido relacionado a una radiodifusión A/V por las aplicaciones que se ejecutan en los segundos dispositivos de pantalla (teléfonos inteligentes, tabletas, ordenadores portátiles, etcétera), incluyendo contenidos sincronizados con la programación se transmite. El servicio se describe basado en la Arquitectura del Dispositivo UPnP.

En esta especificación, el receptor ATSC 2.0 puede ser un receptor de televisión o un receptor normal. Además, el receptor ATSC 2.0 puede ser un receptor en la DVB, ATSC, etcétera.

La Arquitectura del Dispositivo UPnP define los protocolos para la comunicación en una red IP entre los "dispositivos controlados" que proporcionan servicios y "puntos de control" que utilizan aquellos servicios. En el escenario de la "segunda pantalla", un receptor de Televisión puede desempeñar el papel de un "dispositivo controlado", y un segundo dispositivo de la pantalla puede desempeñar el papel de un "punto de control" y viceversa.

La Arquitectura del Dispositivo UPnP especifica, los protocolos del "descubrimiento" para los puntos de control para descubrir los dispositivos controlados de interés, los protocolos de "descripción" para los puntos de control aprenden detalles acerca de los dispositivos y servicios controlados, los protocolos de "control" por los puntos de control invocan las "acciones" (métodos) sobre los dispositivos controlados, y los protocolos del "evento" para los dispositivos controlados para suministrar notificaciones asincronas a los puntos de control. Las acciones y eventos se pueden proporcionar por los servicios del dispositivo.

Cuando un dispositivo controlado UPnP une una red, puede ser multidifusión de mensajes de descubrimiento una "mejor conocida" dirección y puerto de multidifusión IP. Esos mensajes pueden identificar el tipo del dispositivo y los tipos de servicio ofrecidos por el dispositivo, y ellos pueden dar URLs donde las descripciones del dispositivo y se pueden obtener los servicios.

Cuando un punto de control UPnP une una red, puede ser multidifusión de unos dispositivos controlados de pregunta de mensaje de búsqueda para los mismos anuncios. El mensaje de búsqueda puede especificar los tipos de dispositivo y/o los tipos de servicio de interés. Los dispositivos relevantes se pueden responder por enviar mensajes de descubrimiento de unidifusión al punto de control.

Una vez que un punto de control obtiene los mensajes de descubrimiento acerca de los dispositivos y servicios de interés, se pueden usar las URLs en los mensajes que solicitan descripciones de los dispositivos y servicios. Esas descripciones pueden incluir las URLs que se pueden usar para invocar las acciones y suscribir a los eventos para los servicios.

Típicamente los Escenarios de Descubrimiento de la Segunda Pantalla se puede dividir grandemente en el Escenario A y el Escenario B. En el caso del Escenario A, el usuario tiene una aplicación de la segunda pantalla que se ejecuta en su segundo dispositivo de la pantalla cuando el receptor de la Televisión une la red (el cual tal vez sucede cuando el receptor de la Televisión se enciende, o sucede cuando la interfaz de red está disponible). En el caso del Escenario B, el usuario no tiene una aplicación de la segunda pantalla que se ejecuta en su segundo dispositivo de la pantalla cuando el receptor de la Televisión une la red.

El Escenario puede ser como sigue. 1) Un receptor de Televisión que proporciona el soporte de la segunda pantalla une la red. 2) El receptor de la Televisión hace la multidifusión de sus mensajes de descubrimiento que anuncian sus servicios de soporte de la segunda pantalla.3) La segunda aplicación de la segunda pantalla que se ejecuta en el segundo dispositivo de la pantalla recibe la multidifusión de los mensajes de descubrimiento y envía al receptor de Televisión una solicitud para las descripciones de sus servicios.4) El receptor de Televisión responde con las descripciones de sus servicios. 5) La aplicación de la segunda pantalla usa la información dada en las descripciones para acceder a los servicios apropiados y proporcionar una experiencia interactiva sincronizada con la programación de la Televisión.

El Escenario B puede ser como sigue.1) La programación de la Televisión se ve en los receptores de Televisión entra en un segmento del programa que ofrece el soporte de la segunda pantalla. (Esto podría ser tan pronto como el conjunto de la Televisión se enciente, o cuando un cambio de canal va desde un segmento del programa que no ofrece un servicio de datos interactivos con el soporte de la segunda pantalla a un segmento que lo ofrece). 2) Esto hace que el receptor de Televisión informe a los espectadores en alguna manera que el soporte de la segunda pantalla está disponible - por ejemplo, por un icono pequeño en una esquina de la pantalla. 3) El espectador decide tomar ventaja del soporte de la segunda pantalla y activar una aplicación de la segunda pantalla en su segundo dispositivo de la pantalla. La aplicación de la segunda pantalla entonces hace la multidifusión de un mensaje de búsqueda para los dispositivos que ofrecen el soporte de la segunda pantalla. El receptor de Televisión responde a este mensaje con sus mensajes de descubrimiento. 4) Cuando la aplicación de la segunda pantalla recibe los mensajes de descubrimiento, envía los receptores de la Televisión de una solicitud para las descripciones de sus servicios. 5) El receptor de la Televisión responde con las descripciones de sus servicios.6) La aplicación de la segunda pantalla usa la información dada en las descripciones para acceder los servicios apropiados y proporcionar una experiencia interactiva sincronizada con la programación de la Televisión.

El escenario A también puede ser como sigue. 1) Un conjunto de la Televisión que proporciona el soporte de la segunda pantalla de unión a la red. (Esto podría ser cuando el conjunto de la Televisión se enciende, o cuando se permite su interfaz de red).2) Esto hace al receptor de Televisión hacer la multidifusión de sus mensajes de descubrimiento que anuncia al mismo y sus segundos servicios de soporte de la pantalla. 3) Sí un usuario tiene una Aplicación de la Segunda Pantalla ejecuta su segundo dispositivo de la pantalla en este tiempo, la aplicación recibe la multidifusión de mensajes de descubrimiento y procede al paso (7).4) La programación de la Televisión se ve en el receptor de la Televisión entra a un segmento del programa que ofrece el soporte de la segunda pantalla. (Esto podría ser tan pronto como el conjunto de la Televisión se enciende, o cuando un cambio del canal va desde un canal que no ofrece un servicio de datos interactivos con el soporte de la segunda pantalla a uno de los que sí lo ofrece, o cuando el canal se ve que va desde un segmento del programa que no ofrece un servicio de datos interactivo con el segundo soporte de pantalla a un segmento que lo ofrece).5) Esto hace que el receptor de la Televisión informa a los espectadores en alguna manera que está disponible desde el soporte de la segunda pantalla - por ejemplo, por un icono pequeño en una esquina de la pantalla.6) Sí un espectador ya no tiene una Aplicación de la Segunda Pantalla que se ejecuta en su segundo dispositivo de la pantalla, el espectador puede decidir tomar la ventaja del soporte de la segunda pantalla y activa una Aplicación de la Segunda Pantalla en su segundo dispositivo de la pantalla. La Aplicación de la Segunda Pantalla entonces puede hacer la multidifusión de un mensaje de búsgueda para los dispositivos que ofrecen el soporte de la segunda pantalla. El receptor de la Televisión responde a este mensaje con sus mensajes de descubrimiento. 7) Cuando la Aplicación de la Segunda Pantalla recibe los mensajes de descubrimiento, envía al receptor de la Televisión de una solicitud para las descripciones de sus servicios. 8) El receptor de la Televisión responde con las descripciones de sus servicios. Eso hará a un servicio del Disparador y opcionalmente a un servicio del Servidor Proxy HTTP. 9) La Aplicación de la Segunda Pantalla se suscribirá a la característica del "evento" del servicio del Disparador. Si se ofrece el modelo de interacción del servicio de los datos interactivos este es el modelo de Ejecución Directa, el servicio del Disparador enviará todos los Disparadores al segundo dispositivo de la pantalla conforme se recibe por el receptor de la Televisión. Sí el modelo de interacción del servicio de datos interactivos es el modelo TDO, el servicio del disparador enviará un Disparador de Activación a la Aplicación de la Segunda Pantalla sí el tiempo de activación de un Disparador de Activación llega.10) La aplicación de la Segunda Pantalla actuará en los Disparadores, descargando los TDOs y los otros servicios según sea necesario, ya sea desde un enlace de Internet o desde el servicio del Servidor Proxy HTTP ofrecido por el receptor de la Televisión, y proporcionar el servicio interactivo al usuario del segundo dispositivo de la pantalla. 11) Si la programación de la Televisión en el receptor de la Televisión va a un segmento que no ofrece un servicio de datos interactivos con el soporte de la segunda pantalla, el servicio del Disparador enviará un "Disparador nulo" a la Aplicación de la Segunda Pantalla notificarlo en un servicio de datos interactivo para el segundo dispositivo de la pantalla ya no está disponible.12) El usuario del segundo dispositivo de la pantalla puede entonces cierra la Aplicación de la Segunda Pantalla o deja que se ejecute para resumir la interactividad siempre que la programación en el receptor de la Televisión entra a otro segmento que ofrece el soporte de la segunda pantalla.

En cualquier escenario puede ser posible que el umbral tiene más que uno del receptor de la Televisión en la red doméstica. Este caso de la aplicación de la segunda pantalla recibe los mensajes de descubrimiento desde los receptores diferentes múltiples. Si eso sucede, la aplicación de la segunda pantalla a puede preguntar al usuario que uno interactúa con (la información de visualización desde los mensajes de la descripción para ayudar a decidir al usuario).

Un receptor de la Televisión proporciona el soporte de la segunda pantalla que puede ofrecer varios servicios UPnP para el uso de las aplicaciones de la segunda pantalla. Los servicios UPnP pueden ser el "servicio de suministro del Disparador" desde el receptor a una aplicación de la segunda pantalla, "el servicio de comunicaciones de dos maneras" entre los Objetivos Declarativos (DOs) que se ejecutan en el receptor y en una aplicación de la segunda pantalla y en el "servicio del servidor proxy HTTP". Esos servicios pueden ser opcionales dependiendo de la configuración.

Esos servicios pueden designar al soporte una amplia variedad de los diferentes tipos de las aplicaciones de la segunda pantalla, obtenidos de una amplia variedad de las diferentes fuentes, ejecutadas en una amplia variedad de diferentes ambientes de operación en una amplia variedad de los diferentes tipos de los dispositivos de la segunda pantalla.

Un escenario de las aplicaciones empaquetadas de la segunda pantalla típica es como sigue.1) Un punto de control en un segundo dispositivo de la pantalla se suscribe a un servicio de las Aplicaciones Empaquetadas en un dispositivo de la primera pantalla.2) Un consumidor inicia una Aplicación Empaquetada en el Dispositivo de la primera pantalla.3) La aplicación Empaquetada hace el nombre de una aplicación de la segunda pantalla y la URL de la aplicación de la segunda pantalla disponible para el servicio de la Aplicación Empaquetada. 4) El punto de control en el segundo dispositivo de la pantalla recibe el nombre de la aplicación de compañero y la URL. 5) El punto de control ajusta un marcador sobre la segunda pantalla indica al consumidor la acción necesaria.6) El consumidor revisa el nombre de la aplicación de la segunda pantalla y lo selecciona. 7) El punto de control lanza la aplicación de la segunda pantalla indicada.

Un dispositivo de la primera pantalla que proporciona el soporte de la segunda pantalla puede ofrecer varios servicios UPnP para el uso de las aplicaciones de la segunda pantalla. Uno de los servicios UPnP es el "servicio URL de Aplicación" que proporciona el nombre y la URL de la aplicación de la segunda pantalla compañera a ejecutar en el segundo dispositivo de la pantalla.

La arquitectura del sistema para el escenario de la segunda pantalla se describirá.

La arquitectura del sistema para el escenario de la pantalla puede incluir un sistema 42010 de radiodifusión, un servidor 42040 de ACR, un servidor 42030 del radiodifusor ATSC 2.0 iTV, un receptor 42040 ATSC 2.0 y/o los dispositivos 42050 de la segunda pantalla.

El sistema 42010 de radiodifusión puede ser un sistema de radiodifusión normal y puede suministrar los disparadores, A/V, TPTs y/u otros archivos de datos mediante una red de radiodifusión. El disparador se puede transmitir mediante la DTVCC como se describe anteriormente.

El servidor 42020 ACR es un servidor para administrar la ACR de datos relacionados del contenido de radiodifusión, y puede transmitir un disparador al receptor 42040 de ATSC 2.0 tal que el receptor 42040 ATSC 2.0 adquiere un servicio interactivo como se solicite o sea necesario. Esto puede ser igual al servidor ACR descrito anteriormente.

El servidor 42030 de ITV ATSC 2.0 del radiodifusor es un servidor para generar y mantener un servicio interactivo, y puede administrar a TDO/archivos asociado y generar y administrar una tabla de parámetro TDO (TPT) que incluye información acerca da TDO/archivos asociado.

El Receptor 42040 ATSC 2.0 puede recibir el disparador relacionado a A/V de radiodifusión y al servicio interactivo y adquirir y proporcionar el servicio interactivo en la pantalla usando el disparador. Esto puede ser igual al receptor descrito anteriormente.

Los dispositivos 42050 de la segunda pantalla pueden incluir un teléfono móvil, una tableta, un ordenador portátil, etcétera los cuales son los dispositivos de la segunda pantalla. Esto puede ser igual al segundo dispositivo de la pantalla descrita anteriormente.

Los disparadores se pueden suministrar al receptor (42040) ATSC 2.0 mediante el canal DTVCC o mediante un proceso ACR o desde un servidor (42030) de la Televisión interactiva del Radiodifusor (iTV). En todos los casos los Disparadores se pasan desde el receptor (42040) ASTC 2.0 a los dispositivos (42050) de la segunda pantalla en los tiempos apropiados. Esta especificación describe los mecanismos para los Disparadores para pasar a los dispositivos (42050) de la segunda pantalla. También se describen los mecanismos para los DOs que se ejecutan en un receptor (42040) ATSC 2.0 para estabilizar las comunicaciones de dos maneras con los dispositivos (42050) de la segunda pantalla.

Las Aplicaciones y otros archivos que están disponibles mediante Internet se pueden recuperar por los dispositivos (42050) de la segunda pantalla mediante la red doméstica, mediante una red 3GPP separada, o mediante un Servidor Proxy HTTP (no mostrado) en el receptor (42040) ATSC 2.0 si este ofrece ese servicio. Las Aplicaciones ejecutadas en los dispositivos de la primera pantalla pueden ser Aplicaciones Empaquetadas descargadas desde el Internet o las aplicaciones transmitidas a través de la radiodifusión.

Las Aplicaciones y otros archivos que están disponibles mediante las sesiones FLUTE en la radiodifusión se puede recuperar por los dispositivos (42050) de la segunda pantalla solo si el receptor (42040) ATSC ofrece un Servidor Proxy HTTP que suministraran los archivos FLUTE cuando se solicita (asumiendo que el dispositivo (42050) de la segunda pantalla no incluye un receptor de la Televisión).

Esta especificación también describe un mecanismo para las Aplicaciones Empaquetadas que ejecutan en un receptor (42040) ATSC 2.0 soportan el lanzamiento de las aplicaciones de los dispositivos (42050) de la segunda pantalla.

La figura 43 es un diagrama que muestra una modalidad de la Topología entre el Receptor ATSC 2.0 y una segunda pantalla (Conexión Directa).

La figura 43 ilustra la conexión directa entre el receptor ATSC 2.0 y el segundo dispositivo de la pantalla.

La modalidad de la topología entre el receptor ATSC 2.0 y la segunda pantalla (Conexión Directa) puede incluir un sistema 43010 de radiodifusión, un servidor 43020 ATSC 2.0 del radiodifusor, un receptor 43030 ATSC 2.0 y/o los dispositivos 43040 de la segunda pantalla.

El sistema 43010 de radiodifusión puede ser igual al sistema 42010 de radiodifusión.

El servidor 43020 ATSC 2.0 del radiodifusor puede ser igual al servidor 42030 iTV ATSC 2.0 del radiodifusor.

El receptor 43030 ATSC 2.0 puede ser igual al receptor 42040 ATSC 2.0.

Los dispositivos 43040 de la segunda pantalla pueden ser iguales a los dispositivos 42050 de la segunda pantalla.

El receptor 43040 ATSC 2.0 se puede conectar a una red de radiodifusión para recibir directamente una radiodifusión terrestre. En consecuencia el receptor 43030 ATSC 2.0 puede extraer la cadena de la URL del mensaje iTV transmitido mediante el DTVCC desde el servicio DTVCC Número 6. Además, el receptor 43030 ATSC 2.0 se puede conectar a un portal de acceso para acceder el Internet según sea necesario. El receptor 43030 ATSC 2.0 se puede comunicar con los dispositivos conectados en otras redes domésticas usando la teenología de red doméstica (UPnP).

Los dispositivos 43040 de la segunda pantalla todos se conectan al portal de acceso para comunicar con los dispositivos y tener acceso libre al Internet. El portal de acceso puede incluir todas las funciones para soportar el Ethernet y la Wi-Fi.

Un radiodifusor puede proporcionar un servicio suplementario mediante un servidor de Internet para un servicio interactivo. El receptor 43030 ATSC 2.0 o los dispositivos 43040 de la segunda pantalla pueden acceder al servidor para descargar una TDO o una página de red para un dispositivo móvil. En caso del receptor 43030 ATSC 2.0, una página de red se puede traducir a la resolución de una Televisión, en el caso de los dispositivos 43040 de la segunda pantalla, una página de red se puede traducir a la resolución y de diferentes APIs de aquellos de la Televisión.

La figura 44 es un diagrama que muestra una modalidad de la topología entre un Receptor y una segunda pantalla (Conexión Indirecta).

La figura 44 ilustra la conexión indirecta entre el receptor ATSC 2.0 y el segundo dispositivo de la pantalla.

La modalidad de la topología entre el receptor ATSC 2.0 y la segunda pantalla (Conexión Indirecta) puede incluir un sistema 44010 de radiodifusión, un servidor 4020 ATSC 2.0 del radiodifusor, un dispositivo 44030 de administración de sesión del radiodifusor, un receptor 44040 de ATSC 2.0 y/o los dispositivos 44050 de la segunda pantalla.

El sistema 44010 de radiodifusión puede ser igual al sistema 42010 de radiodifusión.

El servidor 44020 ATSC 2.0 del radiodifusor puede ser igual al servidor 42030 ITV ATSC 2.0 del radiodifusor.

El dispositivo 44030 de administración de sesión del radiodifusor puede servir para administrar la conexión indirecta entre el dispositivo 44050 de la segunda pantalla y el receptor 44040 ATSC 2.0.

El receptor 44040 ATSC 2.0 puede ser igual al receptor 42040 ATSC 2.0.

Los dispositivos 44050 de la segunda pantalla pueden ser igual a los dispositivos 42050 de la segunda pantalla.

La conexión indirecta de la figura 44 no indica que los dispositivos 44050 de la segunda pantalla se conectan al receptor 44040 ATSC 2.0 mediante el portal de acceso pero indica que los dispositivos 44050 de la segunda pantalla se conectan directamente a la red 3GPP para conectar al receptor 44040 ATSC 2.0 sobre la red doméstica. En este caso, es difícil conectar los dispositivos 44050 de la segunda pantalla a la red doméstica o a una interfaz que soporta la red puede no estar presente.

En este caso, los dispositivos 44050 de la segunda pantalla pueden requerir información acerca del receptor 44040 ATSC 2.0 almacenado en un servidor de Internet externo. Además, el receptor 44040 ATSC 2.0 reporta la dirección de acceso al servidor de Internet externo hasta la operación.

La figura 45 es un diagrama que muestra una modalidad de una Capa de Software de una Aplicación de Servicio de la Segunda Pantalla.

Los dispositivos de la segunda pantalla generalmente ejecutan las aplicaciones usando OSs. En general, algunas funciones de OSs para los dispositivos móviles pueden no estar incluidas, por el propósito de peso ligero. En consecuencia, las funciones, que no se soportan por la OSs, necesitan incluirse en las aplicaciones.

La capa de software de la figura 45 muestra la estructura de software de una aplicación de servicio de la segunda pantalla necesaria para el servicio de la segunda pantalla. La figura 45 puede mostrar el caso en que el receptor administra el ciclo de vida de la aplicación de la segunda pantalla.

Ya que el segundo dispositivo de la pantalla puede reproducir el contenido de Internet de nuevo, la OS puede proporcionar un ambiente, en el cual una aplicación de red se puede ejecutar, a los programadores usando una plataforma SDK. El ambiente se puede proporcionar en la forma de la SDK tal que la aplicación ejecutada por la OS directamente reproduce el contenido de Internet.

En la figura 45, la Aplicación de Servicio de la Segunda Pantalla se puede ejecutar en el Segundo dispositivo de la pantalla. Esta aplicación se puede descargar desde una Tienda de Aplicaciones (o algún tipo de mercado de aplicaciones). La Aplicación del Servicio de la Segunda Pantalla puede incluir el Cliente ACR y usar el micrófono y la cámara para capturar datos de audio y de video y enviar una firma de los medios al servidor ACR. La Aplicación de Servicio de la Segunda Pantalla se puede ejecutar en la OS e incluye un protocolo tal como HTTP, SSDP o Evento de Multidifusión, de acuerdo al cual un cuadro de trabajo de la UPnP puede operar, y un módulo del navegador puede incluir realizar una reproducción de una aplicación de red.

El módulo del navegador puede ser un módulo para traducir las páginas de red de Internet. El módulo del navegador es una parte central del motor del navegador de red para traducir la aplicación de Red (por ejemplo, ECMAEscritura, HTML y XHTML). Además, el módulo del navegador puede significar un módulo de software para proporcionar una función igual o similar a un navegador provisto por la OS. El método de utilizar el navegador y las funciones controlables difieren entre las OSs.

La Aplicación de la Segunda Pantalla puede ser una aplicación de red que se diseña para los Dispositivos de la Segunda Pantalla, la Aplicación de la Segunda Pantalla puede ser una aplicación de red para llamar las funciones de acuerdo a ECMAEscritura o una aplicación de red, el tamaño del cual se controla por ejecutar en el módulo del navegador provisto por un OS móvil. Esta aplicación de red se puede ejecutar en la Aplicación de Servicio de la Segunda Pantalla.

El sistema de operación para el dispositivo móvil se puede componer del hardware que soporta los controladores y los controladores incluidos para unos servicios específicos del núcleo. Fundamentalmente, es posible soportar solo los protocolos IP, TCP y UDP. Una pila de protocolo de red está presente encima de la OS. En el caso de la UPnP, se puede transmitir una HTTP usando una UDP.

Un cuadro de trabajo DCP de la UPnP puede significar puntos de control del dispositivo definidos en el foro de la UPnP.

Una SSDP (Protocolo de Descubrimiento de Servicio Simple) puede buscar para uno o más servicios de acuerdo al dispositivo conectado a la red en la red doméstica.

La figura 46 es un diagrama que muestra una Capa del Software de una Aplicación de Servicio de la Segunda Pantalla.

La capa del software de la figura 46 muestra la estructura del software de la aplicación de servicio de la segunda pantalla necesaria para el servicio de la segunda pantalla. La figura 46 puede mostrar el caso en que la aplicación de servicio de la segunda pantalla administra el sid o de vida de la aplicación de la segunda pantalla.

La descripción de cada entidad de la figura 46 puede ser igual que la de la figura 45 en términos del papel y la función.

El Cliente del Disparador ATSC 2.0 puede significar un módulo para recibir y procesar el disparador descrito anteriormente, la TPT, la AMT, etcétera. Este módulo se puede incluir en el segundo dispositivo de la pantalla de acuerdo a la circunstancia. Si este módulo se incluye en el segundo dispositivo de la pantalla, este módulo puede procesar directamente la TPT y la AMT para verificar directamente el ciclo de vida de la aplicación.

La figura 47 es un diagrama que muestra una tabla que muestra una diferencia entre un orden de transmisión de acuerdo al Ciclo de Vida de la Aplicación de la Segunda Pantalla y transmitir datos.

El receptor puede servir directamente la TPT y la AMT usando el DTVCC sobre la red de radiodifusión o descargar la TPT y la AMT sobre la red de Internet y procesar la TPT y la AMT. Como se describe anteriormente, la TPT incluye información del evento, y la información del evento puede incluir Eventold, Acción, Destino e información de Datos. El "Evento@Destino" puede indicar para que dispositivo se genera esta información del evento. Por ejemplo, el destino puede ser un receptor o un segundo dispositivo de la pantalla. Si el destino se ajusta al segundo dispositivo de la pantalla, el receptor deberá suministrar la información del evento al segundo dispositivo de la pantalla.

En consecuencia, hay una necesidad de un método de suministro de esta información al segundo dispositivo de la pantalla. El ciclo de vida de la aplicación de la segunda pantalla se puede administrar por el receptor o la aplicación de servicio de la segunda pantalla.

La tabla de la figura 47 muestra el resumen de los métodos de suministro de información dependiendo de qué entidad administra el ciclo de vida de la aplicación de la segunda pantalla.

La primera flecha puede ser un resumen de una descripción del caso descrito anteriormente de la figura 51 y una descripción detallada del mismo se dará a continuación.

Una segunda flecha puede ser un resumen de una descripción del caso en que el receptor administra el ciclo de vida de la aplicación de la segunda pantalla y una descripción detallada del mismo se dará a continuación.

Una tercera flecha puede ser un resumen de una descripción del caso en que el receptor filtra (aumenta) y suministra la información del disparador necesaria para la aplicación de la segunda pantalla y una descripción detallada del mismo se dará a continuación.

Una cuarta flecha puede ser un resumen de una descripción del caso descrito anteriormente de la figura 50 y una descripción detallada del mismo se dará a continuación.

Una quinta flecha puede ser un resumen de una descripción del caso descrito anteriormente de la figura 57 y una descripción detallada del mismo se dará a continuación.

La figura 48 es un diagrama que muestra el concepto operacional de un modelo de Ejecución Centralizada.

Un método de suministrar eficientemente un servicio interactivo a un segundo dispositivo de la pantalla puede incluir un modelo de ejecución centralizada y un modelo de ejecución distribuida.

Como se muestra en el diagrama que muestra el concepto operacional del modelo de ejecución centralizada, un conjunto de Televisión puede generar y actualizar una RUI a reproducir en cada segundo dispositivo de la pantalla usando un mecanismo RUI de la UPnP y transmitir la RUI sobre una red. Cada segundo dispositivo de la pantalla puede recibir la RUI mediante un cliente de la RUI en tiempo real y visualiza la RUI en una pantalla. A diferencia del modelo de ejecución distribuida, un DAE puede estar presente en el dispositivo primario.

La figura 49 es un diagrama gue muestra el flujo del ínter funcionamiento entre un modelo de Ejecución Centralizada basado en el receptor y una segunda pantalla.

El flujo de la figura 49 puede ser una operación cuando un mecanismo del modelo de ejecución centralizada se aplica en un ambiente en que un receptor es capaz de adquirir un servicio interactivo mediante una red de radiodifusión y los ínter funcionamientos con un segundo dispositivo de la pantalla en la modalidad del concepto operacional del modelo de ejecución centralizada.

El flujo de la figura 49 puede ser una operación cuando un mecanismo del modelo de ejecución centralizada se aplica en un ambiente en que un receptor es capaz de adquirir un servicio interactivo mediante una red de radiodifusión e Ínter funcionamientos con el segundo dispositivo de la pantalla en la modalidad del concepto operacional del modelo de ejecución centralizada.

La modalidad del flujo del ínter funcionamiento entre el modelo de ejecución centralizada y la segunda pantalla puede incluir enviar un disparador (s49010) de tiempo base, solicitar una TPT (s49020), transmitir una TPT como una respuesta (s49030), analizar una TPT (s49040), enviar un disparador de ejecución para la segunda pantalla (s49050), descargar TDOs/Archivos (s49060), generar una RUI (s49070), enviar una RUI mediante un protocolo de la RUI (s49080), visualizar una UI en la pantalla (s49090), el usuario presiona un enlace para una nueva página (s49100), enviar datos de entrada (s(49110), descargar un nuevo TDO/archivo (s49120), actualizar una RUI (s49130), enviar una RUI mediante un protocolo RUI (s49140) y/o visualizar una UI en la pantalla (s49150).

Enviar un disparador de tiempo base (s49010)puede incluir que el receptor reciba el disparador de tiempo base mediante un servidor DTVCC o ACR. El disparador de tiempo base se describió anteriormente.

Solicitar una TPT (s49020) puede incluir que el receptor interprete el disparador recibido, adquirir una URL de un servidor capaz de adquirir la TPT, y solicitar la TPT.

Transmitir una TPT como una respuesta (S49030) puede incluir transmitir la TPT en respuesta a la solicitud en la solicitud TPT (S49020).

Dividir una TPT (s49040) puede incluir que el receptor analiza la TPT solicitada.

Enviar un disparador de ejecución para una segunda pantalla (s49050) puede incluir que el receptor recibe el disparador de ejecución para la segunda pantalla mediante el servidor DTVCC o ACR. El disparador de ejecución puede ser igual al disparador de activación descrito anteriormente.

Descargar TDOs/Archivos (s49060) puede incluir que el receptor adquiere la información acerca de los TDOs y los archivos asociados con el disparador de tiempo base o el disparador de ejecución desde la TPT recibida y descargar los TDOs y los archivos indicados por el disparador desde un servidor de contenido.

Generar una RUI (s49070) puede incluir la generación de la RUI para los TDOs y los archivos descargados.

Enviar la RUI mediante un protocolo RUI (s49080) puede incluir la transmisión del receptor de la RUI generada en la segunda pantalla usando el protocolo RUI.

Visualizar una UI en la pantalla (s49090) puede incluir visualizar la RUI recibida en la segunda pantalla.

El usuario presiona un enlace para una página nueva (s49100) puede incluir presionar un enlace especifico en la RUI por la selección del usuario en la segunda pantalla.

Enviar datos de entrada (s49100) puede incluir suministrar información de entrada del usuario al receptor si un enlace especifico presionado se conecta a otra página.

Descargar una TDO/archivo nuevo (s49120) puede incluir los TDOs y los archivos descargados por el receptor asociados con la entrada del usuario.

Actualizar una RUI (s49130) puede incluir actualizar la RUI de acuerdo a los TDOs y los archivos descargados.

Enviar una RUI mediante un protocolo RUI (s49140) puede incluir la transmisión del receptor de la RUI actualizada a la segunda pantalla usando el protocolo RUI.

Visualizar una UI en la pantalla (s49150) puede incluir visualizar la RUI actualizada en la segunda pantalla.

La figura 50 es un diagrama que muestra una modalidad de un método de, en un receptor, notificar una pantalla de la segunda pantalla de la información UI.

La figura 50 muestra un orden lógico en que el receptor recibe el disparador desde el radiodifusor y suministra el disparador al segundo dispositivo de la pantalla.

Este proceso puede incluir recibir un disparador para un receptor (s50010), recibir un disparador para un servicio de la segunda pantalla (s50020), enviar la notificación acerca de la información UI actualizada (s50030), solicitar la información UI actualizada (s50040), transmitir la información UI compatible como una respuesta (s50050) y recibir otro disparador por el receptor (s50060).

Recibir un disparador para un receptor (s50010) puede incluir la recepción del dispositivo primario del disparador por el receptor, esto es, el dispositivo primario, desde el radiodifusor mediante la corriente de radiodifusión.

Recibir un disparador para un receptor (s50020) puede incluir la recepción del dispositivo primario del disparador por el receptor, esto es, el dispositivo primario, desde el radiodifusor mediante la corriente de radiodifusión.

Enviar la notificación acera de la información UI actualizada (s50030) puede incluir notificar acerca de la UI actualizada. Como se describe anteriormente, si el disparador se recibe mientras que se visualiza un programa de radiodifusión, el receptor puede analizar si el disparador es para el segundo dispositivo de la pantalla en el dispositivo primario. En este momento, si el disparador es para el segundo dispositivo de la pantalla, todos los dispositivos UPnP o solo un dispositivo UPnP especifico pueden notificar de una actualización de información UI nueva. Esto puede corresponder al caso en que el segundo dispositivo de la pantalla se suscribe usando el protocolo UPnP.

Solicitar la información UI actualizada (s50040) puede incluir la información UI actualizada que solicita el segundo dispositivo de la pantalla desde el dispositivo primario.

Transmitir la información UI compatible como una respuesta (s50050) puede incluir el dispositivo primario que transmite la información UI compatible al segundo dispositivo de la pantalla.

Recibir otro disparador por el receptor (s50060) puede ser igual a recibir un disparador por el receptor (s50010. Esto es, la operación descrita anteriormente se puede realizar de nuevo.

Ya que el receptor puede incluir un modelo del disparador, el receptor puede recibir un archivo XML tal como la TPT y la AMT sobre una red de radiodifusión o una red de Internet, analizar el archivo XML, y realizar una operación apropiada. Si se encuentra el segundo dispositivo de la pantalla, la Acción, la URL TDO y los Datos suministrados al segundo dispositivo de la pantalla se puede reconocer usando un campo Evento@Destino. El segundo dispositivo de la pantalla puede no recibir directamente el archivo XML tal como la TPT o la MAT y por tanto puede no incluir el módulo del disparador. Si un Servicio de Cliente RemotoUI se incluye, el receptor puede administrar los ciclos de vida de todas las aplicaciones de la segunda pantalla. En contraste, si varios dispositivos de la segunda pantalla se conectan, los datos para controlar la aplicación de la segunda pantalla se transmiten varias veces.

La figura 51 es un diagrama que muestra una modalidad de un método de, en un receptor, notificar a un segundo dispositivo de la pantalla de la información UI.

A diferencia de la figura 50, la figura 51 muestra el caso en que toda la información UI para el segundo dispositivo de la pantalla, que se determina ser usada adecuadamente para el segundo dispositivo de la pantalla, se suministra directamente. Esto es, las URLs TDO para el segundo dispositivo de la pantalla se pueden transmitir.

Este proceso puede incluir recibir un disparador por el receptor (s51010), recibir un disparador por el servicio de la segunda pantalla (s51020), notificar acerca de la información UI (s51030), enviar una respuesta "ok" (s51040), recibir un disparador por el receptor (s51050), recibir un disparador por el receptor (s51060), recibir un disparador por el servicio de la segunda pantalla (s51070), notificar acerca de la información UI (s51080) y/enviar una respuesta "ok" (s51090).

Recibir un disparador por el receptor (s51010) puede ser igual a recibir un disparador por el receptor (s50010).

Recibir un disparador por el servicio de la segunda pantalla (s51020) puede ser igual a recibir un disparador por el servicio de la segunda pantalla (s50020).

Notificar acerca de la información UI (s51030) puede incluir notificar acerca de la actualización de la información UI.

Enviar una respuesta ”ok" (s51040) puede incluir transmitir un mensaje de indicación que se ha recibido la notificación UI.

Recibir un disparador por el receptor (s51050) y recibir un disparador por el receptor (s51060) puede ser igual a recibir un disparador por el receptor (s50010). Esto es, la operación descrita anteriormente se puede realizar de nuevo.

Recibir un disparador por el servicio de la segunda pantalla (s51070) puede ser igual a recibir un disparador por el servicio de la segunda pantalla (s50020). Esto es, la operación descrita anteriormente se puede realizar de nuevo.

Notificar acerca de la información UI (s51080) puede ser igual a notificar acerca de la información UI (s51030). Esto es, la operación descrita anteriormente se puede realizar de nuevo.

Enviar una respuesta "ok" (s51090) puede ser igual a enviar una respuesta "ok" (s51040). Esto es, la operación descrita anteriormente se puede realizar de nuevo.

En el método de la figura 51, el receptor podrá conocer que dispositivo UPnP es un segundo dispositivo de la pantalla y que perfil del dispositivo se incluye. En particular, los receptores podría conocer sí el segundo dispositivo de la pantalla soporta el servicio de la segunda pantalla.

El método (el caso de la figura 50) de notificar acerca de la información UI después de determinar sí el disparador es por el segundo dispositivo de la pantalla o el dispositivo primario y el método (el caso de la figura 51) de entregar toda la información UI por el segundo dispositivo de la pantalla, el cual se determina usar adecuadamente por el segundo dispositivo de la pantalla, puede ser igual en ese proceso del receptor de la TPT y el disparador y suministra solo la URL TDO al segundo dispositivo de la pantalla. Esos dos métodos pueden diferir en que el receptor suministra indirectamente la TDO al segundo dispositivo de la pantalla o el receptor graba directamente el perfil de cada dispositivo y notifica solo el segundo dispositivo de la pantalla de la locación de la aplicación de la segunda pantalla.

La figura 52 es un diagrama que muestra una modalidad de la Señalización de Radiodifusión para un Servicio del Servidor RemotoUI.

Una modalidad de la señalización de la radiodifusión de un Servicio del Servidor RemotoUI puede incluir el dispositivo UPnP y el descubrimiento del servicio (s52010), solicitar la UILista (s52020), enviar la UILista (s52030), suscribir a un evento (s52040), regresar un mensaje HTTP (s52050), enviar un mensaje UIListaActualización (s52060), solicitar UILista (s52070) y/o regresar la UILista (s52080).

El dispositivo UPnP y el descubrimiento del servicio (s52010) puede incluir el descubrimiento del receptor y el segundo dispositivo de la pantalla. Un dispositivo conectado nuevamente a la red doméstica o un dispositivo ya conectado a la red doméstica (el receptor o el segundo dispositivo de la pantalla) puede hacer la multidifusión de un mensaje para el descubrimiento. En este momento, un servicio deseado se puede buscar usando la multidifusión de todos los servicios que se pueden buscar con respecto a una pluralidad de dispositivos UPnP sin especificar. Esto puede cambiar dependiendo de qué servicio se proporciona por el dispositivo. En este paso, el segundo dispositivo de la pantalla puede ser consiente del perfil del dispositivo del dispositivo primario. El dispositivo primario puede procesar el perfil del dispositivo y construir la UILista apropiada. El servidor RemotoUI puede dar el segundo dispositivo de la pantalla del esquema XSD CompatibleUIs. Este esquema puede incluir la URL de la Aplicación, la identificación única para esta UI ("uilD"), nombre, protocololnfo y asi sucesivamente.

Solicitar la UILista (s52020) puede incluir transmitir el segundo dispositivo de la pantalla al perfil del dispositivo del mismo y solicitar UILista. Una acción de ObtenerCompativleUIs capaz de obtener una UI compatible se puede usar. (La UIFiltro puede ser opcional) Una descripción detallada del mismo se describirá a continuación.

Enviar la UILista (s52030) puede incluir la transmisión del dispositivo primario apropiada de UI lista al segundo dispositivo de la pantalla de acuerdo a la solicitud. Una descripción detallada del mismo se describirá a continuación.

Suscribir a un evento (s52040) puede incluir suscribir a un Evento expuesto previamente del dispositivo primario. Suscribir a un evento (s52040) se puede realizar selectivamente para recibir la "UIListaActualización" que es la información del evento provisto por el Servicio del Servidor RemotoUI. En la devolución de la UILista (s52080), el segundo dispositivo de la pantalla se puede notificar que la dirección de la RemotoUI se ha cambiado o que la UI se ha cambiado. Esto es, ya que el segundo dispositivo de la pantalla se notifica solo que la UI se ha cambiado, si la locación detallada o la información adicional se requiere, la acción de "ObtenerCompatibleUIs" se deberá transmitir al receptor para obtener el valor "UILista".

Regresar un mensaje HTTP (s52050) puede incluir enviar un resultado de suscribir a un evento (s52040). Similarmente enviar una respuesta 1 (s40100), una respuesta tal como HTTP/1.1 200 OK se puede enviar de acuerdo a la circunstancia.

Enviar un mensaje UIListaActualización (s52060) puede incluir transmitir un mensaje "UIListaActualización" a los suscriptores.

Solicitar la UILista (s52070) puede incluir la transmisión del segundo dispositivo de la pantalla del perfil del dispositivo del mismo y solicitar la UILista. Se puede usar una acción de ObtenerCompatibleUIs capaz de obtener una UI compatible. Enviar un mensaje UIListaActualización (s53060) y solicitar la UILista (s52070) puede incluir realizar el ajuste de tiempo tal que la aplicación de la segunda pantalla no se cambia y son posibles selectivamente solo cuando se soportan por el servidor. Este paso es opcional. Este método puede ser un método de, en el receptor, notificar todos los dispositivos de la segunda pantalla que el servicio de la segunda pantalla está presente usando el evento UPnP. Esto es, todos los dispositivos de la segunda pantalla en la red doméstica pueden notificar que la UI se ha cambiado en asociación con el servicio de la segunda pantalla. Si todos los dispositivos de la segunda pantalla se notifican de una variable "UIListaActualización" usando el evento UPnP, los dispositivos de la segunda pantalla pueden confirmar que la UI se ha actualizado nuevamente. Por lo tanto, el segundo dispositivo de la pantalla puede realizar la Acción "obtenerCompatibleUIs", seleccionar una UI adecuada para el hardware del dispositivo, y ejecutar la UI refiriéndose al perfil del dispositivo.

Regresar la UILista (s52080) puede incluir la transmisión del dispositivo primario de la lista UI apropiada al segundo dispositivo de la pantalla de acuerdo a la solicitud. Como se describe anteriormente, regresar la UILista (s52080) puede incluir notificar a la suscripción del segundo dispositivo de la pantalla que la dirección de la RemotoUI se ha cambiado o que la UI se ha cambiado. Esto es, ya que el segundo dispositivo de la pantalla se notificó que solo la UI se ha cambiado, si se requiere la locación detallada o la información adicional, una Acción de "ObtenerCompatibleUIs" se deberá transmitir al receptor para obtener el valor de la "UILista".

Cuando el Servicio del Servidor RemotoUI opera, el receptor debe proporcionar la información UI remota de acuerdo al perfil del dispositivo del dispositivo que lo solicita. Desde el punto de vista de la compatibilidad con versiones anteriores, el perfil del dispositivo "Dispositivolnfo" se intercambia y la URL envía por el Servicio del Servidor RemotoUI se puede cambiar de acuerdo al perfil del cliente que lo solicita cuando solicita la acción de "ObtenerCompatibleUIs" desde el receptor posterior. Si el dispositivo UPnP del legado solicita la acción de "ObtenerCompatibleUIs" desde el Servidor RemotoUI, se deberá proporcionar una UI adecuada para el Dispositivolnfo del dispositivo UPnP del legado. Sin embargo, si el dispositivo soporta las solicitudes de servicio de la segunda pantalla de la acción de "ObtenerCompatibleUIs", el dispositivo del Servicio del Servidor RemotoUI deberá transmitir también la información URL.

El receptor puede obtener información del disparador mediante la DTVCC y obtener el tiempo en los medios y la información del tiempo del evento desde la información del disparador. En este momento, la "aplicaciónID", la "URL" (TD0_URL), el "eventoID", la "acción" y, opcionalmente, los "Datos" para la TDO o un tiempo de ejecución se puede confirmar usando la sintaxis de "t=medios_tiempo". Si el receptor administra el ciclo de vida de la aplicación de la segunda pantalla, la cantidad de información a procesar por la aplicación del servicio de la segunda pantalla se puede reducir. En contraste, si la aplicación del servicio de la segunda pantalla administra directamente el ciclo de vida de la aplicación de la segunda pantalla, la información necesaria se puede incrementar.

La figura 53 es un diagrama que muestra el concepto operacional de un modelo de Ejecución Distribuido.

Como un método de suministrar eficientemente el servicio interactivo al segundo dispositivo de la pantalla, el modelo de ejecución distribuida se describirá.

Como se muestra en el diagrama gue muestra el concepto operacional del modelo de Ejecución Distribuido, un conjunto de Televisión puede suministrar la información tal como un disparador al segundo dispositivo de la pantalla usando UPnP, etcétera. Cada segundo dispositivo de la pantalla tiene un manejador del disparador y puede procesar información tal como un disparador recibido mediante el manejador del disparador en tiempo real. El navegador puede ejecutar un servicio interactivo asociado con el mismo.

A diferencia del modelo de Ejecución Centralizado, un DAE puede estar presente en cada segundo dispositivo de la pantalla.

Un proceso de suministrar un servicio interactivo a un segundo dispositivo de la pantalla basado en el modelo de Ejecución Distribuida se puede realizar en el siguiente orden. 1. El receptor es el segmento de presentación con el soporte de la segunda Pantalla. 2. El receptor reproduce alguna indicación de gue el soporte de la segunda Pantalla está disponible. 3. El usuario inicia la aplicación de la segunda pantalla en el segundo dispositivo de la pantalla. 4. El receptor y el segundo dispositivo de la pantalla descubre a cada uno de los mecanismos ÜPnP (realizados por el código nativo en el receptor y la aplicación de la segunda Pantalla en el dispositivo).5. El conjunto de la Televisión obtiene el Disparador (desde el flujo DTVCC o ACR) para iniciar la TDO en el segundo dispositivo de la pantalla. 6. El conjunto de la Televisión combina el Disparador con la información desde la TPT y se envía al segundo dispositivo de la pantalla en el en el tiempo de activación. 7. El segundo dispositivo de la pantalla descarga una TDO (uno o más archivos) y lo ejecuta en este navegador.8. El usuario interactúa con a TDO, que puede hacer al TDO descargar archivos adicionales. 9. El receptor obtiene el Disparador para generar el Evento para a TDO en el segundo dispositivo de la pantalla.10. El receptor combina el Disparador con la información desde la TPT y envía al segundo dispositivo de la pantalla en el tiempo de activación.11. El segundo dispositivo de la pantalla genera el DisparadorEvento (similar FlujoEvento DVB) para a TDO en el navegador.12. A TDO lleva acabo la acción solicitada por el DisparadorEvento, el cual puede hacer la descarga del(los) archivo(s) de datos.

La figura 54 es un diagrama que muestra el flujo del ínter funcionamiento entre un modelo de Ejecución Distribuida basado en el receptor y una segunda pantalla.

El flujo del modelo de ejecución distribuida puede ser un flujo de datos en el caso en que el receptor transmite la información recibida mediante el servidor DTVCC o ACR a la segunda pantalla sin cambiar. El flujo detallado se describirá ahora.

La modalidad del flujo para el ínter funcionamiento entre el modelo de ejecución distribuida y la segunda pantalla puede incluir enviar un disparador de tiempo base (s54010), enviar un disparador de tiempo base (s54020), solicitar una TPT (s54030), transmitir una TPT como una respuesta (s54040), analizar una TPT (s54050), enviar un disparador de ejecución a una segunda pantalla (s54060), enviar un disparador de ejecución (s54070), descargar TDOs/archivos (s54080), ejecutar una TDO en el navegador (s54090), el usuario presiona un link para una página nueva (s54100), descargar una TDO/archivo nuevo (s54110) y/o ejecutar una TDO nuevo en el navegador (s54120).

Enviar un disparador de tiempo base (s54010) puede ser igual a enviar un disparador de tiempo base (s49010).

Enviar un disparador de tiempo base (s54020) puede incluir la transmisión del receptor del disparador recibido a la segunda pantalla sin cambio.

Solicitar la TPT (s54030) puede incluir la interpretación de la segunda pantalla el disparador recibido, adquirir una URL de un servicio capaz de adquirir una TPT y solicitar la TPT.

Transmitir una TPT como una respuesta (s54040) puede incluir transmitir la TPT en respuesta a la solicitud en la TPT solicitar la TPT (s54030).

Analizar una TPT (s54050) puede incluir analizar la TPT solicitada.

Enviar un disparador de ejecución para una segunda pantalla (s54060) puede ser igual a enviar un disparador de ejecución por una segunda pantalla (s49050).

Enviar un disparador de ejecución (s54070) puede incluir la transmisión del receptor del disparador recibido a la segunda pantalla sin cambiar.

Descargar los TDOs/archivos (s54080) puede incluir la adquisición de los TDOs/archivos de la segunda pantalla asocada con el disparador desde la TPT y descargar los TDOs/archivos desde el servidor de contenido.

Ejecutar una TDO en el navegador (s54090) puede incluir ejecutar los TODs y los archivos descargados en el navegador.

El usuario presiona un enlace para una página nueva (s54100) puede incluir que el usuario presiones un enlace especifico en a TDO ejecutado.

Descargar una TDO/archivo nuevo (s54110) puede incluir descargar a TDO/archivo asociado si un enlace especifico u otro TDO se estableció.

Ejecutar una TDO nuevo en el navegador (s54120) puede incluir ejecutar la TDO asociada y el archivo en el navegador.

La figura 55 es un diagrama que muestra el flujo de ínter funcionamiento entre un modelo de Ejecución Distribuida basado por el receptor y una segunda pantalla.

El flujo del modelo de ejecución distribuido puede ser un flujo de datos en el caso en que el receptor no transmite la información mediante el servidor DTVCC o ACR a la segunda pantalla sin cambiar pero inserta información necesaria de acuerdo a un disparador adecuado para la segunda pantalla, cambia la información a un disparador expandido, y transmite la información a la segunda pantalla. El flujo detallado se describirá ahora.

La modalidad del flujo para ínter funcionamiento entre el modelo de ejecución distribuida basado en el receptor y la segunda pantalla se puede incluir enviando un disparador de tiempo base (s55010), solicitar una TPT (s55020), transmitir una TPT como una respuesta (s55030), analizar la TPT (s55040), enviar un disparador de ejecución para una segunda pantalla (s55050), generar un disparador expandido (s55060), enviar un disparador expandido (s55070), descargar los TDOs/Archívos (s55080), ejecutar una TDO en el navegador (s55090), el usuario presiona un enlace para una página nueva (s55100), descargar una TDO/Archivo nuevo (s55110) y/o ejecutar una TDO nuevo en el navegador (s55120).

Enviar un disparador de tiempo base (s55010) puede ser igual a enviar un disparador de tiempo base (s54010).

Solicitar una TPT (s55020) puede ser igual a solicitar una TPT (s54030 ) .

Transmitir una TPT como una respuesta (s55030) puede ser igual a transmitir una TPT como una respuesta (s54040).

Analizar una TPT (s55040) puede ser igual a analizar una TPT (s54050).

Enviar un disparador de ejecución para una segunda pantalla (s55050) puede ser igual a enviar un disparador de ejecución para una segunda pantalla (s54060).

Generar un disparador expandido (s55060) puede incluir la información de adquisición del receptor acerca de los TDOS y los archivos asociados con el disparador desde la TPT y generar un disparador expandido que incluye el mismo.

Enviar un disparador expandido (s55070) puede incluir la transmisión del disparador expandido generado a la segunda pantalla.

Descargar los TDOs/archivos (s55080) puede ser igual a descargar TDOs/archivos (s54080).

Ejecutar a TDO en el navegador (s55090) puede ser igual a ejecutar a TDO en el navegador (s54090).

El usuario presiona un enlace para una página nueva (s55100) puede ser igual a que el usuario presiona un enlace para una página nueva (s54100).

Descargar una TDO/archivo nuevo (s55110) puede ser igual a descargar una TDO/archivo nuevo (s54110).

Ejecutar una TDO nuevo en el navegador (s55120) puede ser igual a ejecutar una TDO nuevo en el navegador (s54120).

La figura 56 es un diagrama que muestra una modalidad de un método de, en un receptor, notificar un dispositivo del segundo dispositivo da TDO y la información del Evento.

La figura 56 muestra un método de, en el receptor, recibir el disparador y la TPT, realizar el procesamiento de acuerdo al disparador, comparando el disparador con la TPT cuando ha llegado el disparador para el segundo dispositivo de la pantalla, extraer y configurar información, que necesita reconocer por el segundo dispositivo de la pantalla, en la forma de un archivo XML, y transmitir la información al segundo dispositivo de la pantalla. Este método puede ser ventajoso en que el segundo dispositivo de la pantalla puede operar activamente y realizar una predicción.

Este proceso puede incluir recibir un disparador por el receptor (s56010), recibir un disparador por el servicio de la segunda pantalla (s56020), traducir una TPT y un disparador y generar información del evento (s56030), enviar a TDO y la información del evento (s56040), enviar una respuesta "ok" (s56050), recibir un disparador por el receptor (s56060), recibir un disparador por el receptor (s56070), recibir un disparador por el servicio de la segunda pantalla (s56080), trasladar una TPT y un disparador y generar información del evento (s56090), enviar una TDO y la información del evento (s56100) y/o enviar una respuesta "ok" (s56110).

Recibir un disparador por el receptor (s56010) puede ser igual a recibir un disparador por el receptor (s50010).

Recibir un disparador por el servicio de la segunda pantalla (s56020) puede ser igual a recibir un disparador por el servicio de la segunda pantalla (s50020).

Trasladar una TPT y un disparador y generar información del evento (s56030) puede incluir interpretar la TPT y el disparador y generar información del evento. La información generada se puede usar para combinar la información incluida en la TPT y el disparador para generación de una estructura de datos nueva y puede incluir información acerca de que TDO se generó o cuando la TDO se generó. Esta estructura de datos se describirá a continuación. Si se decide la estructura de los datos nuevos, una variedad de información necesaria se puede transmitir además de la URL TDO.

Enviar a TDO y la información del evento (s56040) puede incluir transmitir la información del evento generado y a TDO al segundo dispositivo de la pantalla.

Enviar una respuesta "ok" (s56050) puede incluir transmitir un mensaje que indica que la TDO recibida y la información del evento se han recibido.

Recibir un disparador por el receptor (s56060) y recibir un disparador por el receptor (s56070) puede ser igual a recibir un disparador por el receptor (s50010).

Recibir un disparador por el servicio de la segunda pantalla (s56080) puede ser igual a recibir un disparador por el servicio de la segunda pantalla (s50020).

Trasladar una TPT y un disparador y generar la información del evento (s56090) puede ser igual a trasladar una TPT y un disparador y generar la información del evento (S56030).

Enviar a TDO y la información del evento (s56100) puede ser igual a enviar TDO e información del evento (s56040).

Enviar una respuesta "ok" (s56110) puede ser igual a enviar una respuesta "ok" (s56050).

Recibir un disparador por el receptor (s56060), recibir un disparador por el receptor (s56070), recibir un disparador por el servicio de la segunda pantalla (s56080), trasladar una TPT y un disparador y generar la información del evento (s56090), enviar la TDO y la información del evento (s56100) y enviar una respuesta "ok" (s56110) pueden ser iguales a las operaciones descritas anteriormente.

La figura 57 es un diagrama gue muestra una modalidad de un método de, en un segundo dispositivo de la pantalla, acceder una TPT y una aplicación de la segunda pantalla.

El segundo dispositivo de la pantalla es un dispositivo independiente, que puede ejecutar directamente la aplicación de la segunda pantalla si el receptor recibe el archivo XML tal como TPT y AMT o conocidos como las direcciones del servidor TPT y AMT mediante el Internet. En este caso, el módulo del disparador se incluye en el segundo dispositivo de la pantalla, el segundo dispositivo de la pantalla puede recibir la cadena de URI para un mensaje iTV recibido por el receptor. Este mensaje es aplicable a ambos 1) el método de transmitir la cadena de UIR para el mensaje iTV (disparador) en el caso del Servicio del Servidor RemotoUI y 2) el método de transmitir la cadena URI para el mensaje iTV (disparador) en el caso del servicio del Cliente RemotoUI.

Primero, el método de transmitir la cadena URI para el mensaje iTV (disparador) en el caso del Servicio del Servidor RemotoUI se describirá.

Este proceso puede incluir recibir un disparador por el receptor (s57010), recibir un disparador por el servicio de la segunda pantalla (s57020), enviar la notificación acerca de la información UI actualizada (s57030), solicitar la información UI actualizada (s57040), transmitir la información UI como una respuesta (s57050), solicitar un archivo XML de la TPT (s57060), regresar un archivo XML de la TPT (s57070), recibir un disparador por el servicio de la segunda pantalla (S57080), enviar la notificación acerca de la información UI actualizada (s57090), solicitar la información UI actualizada (s57100), transmitir la información UI como una respuesta (s57110), recibir un disparador por el servidor de la segunda pantalla (s57120), enviar la notificación acerca de la información UI actualizada (s57130), solicitar la información UI actualizada (s57140), transmitir la información UI como una respuesta (s57150), solicitar una aplicación de la segunda pantalla s57160) y/o regresar una aplicación de la segunda pantalla (s57170).

Recibir un disparador para el receptor (s57010) puede ser igual a recibir un disparador para el receptor (s50010). Mientras que el primer disparador no es por el segundo dispositivo de la pantalla, el receptor no suministra el disparador al segundo dispositivo de la pantalla.

Recibir un disparador por el servicio de la segunda pantalla (s57020) puede ser igual a recibir un disparador por el servidor de la segunda pantalla (s50020). El disparador puede tener información acerca de un tiempo en los medios por el servicio de la segunda pantalla. El segundo disparador puede servir como el disparador precargado descrito anteriormente.

Enviar la notificación acerca de la información UI actualizada (s57030) puede incluir notificar acerca de la información UI actualizada. El receptor puede transmitir la UIRCadena recibida al segundo dispositivo de la pantalla debido a que el segundo disparador es por el servicio de la segunda pantalla. En este momento, el segundo dispositivo de la pantalla puede informar que la información nueva está presente y puede permitir leer apropiadamente esta información.

Solicitar la información UI actualizada (s57040) puede ser igual solicitar la información UI actualizada (s50040).

Transmitir la información UI como una respuesta (s57050) puede incluir transmitir información UI del dispositivo primario al segundo dispositivo de la pantalla. En este momento, el segundo disparador se puede transmitir.

Solicitar un archivo XML de la TPT (s57060) puede incluir analizar la información del segundo dispositivo de la pantalla (segundo disparador) recibida desde el dispositivo primario y solicitar un archivo XML de la TPT desde el servidor de la TPT.

Regresar un archivo XML de la TPT (s57070) puede incluir la descarga del archivo XML de la TPT solicitado del segundo dispositivo de la pantalla desde el servidor de la TPT.

Recibir un disparador para el servicio de la segunda pantalla (s57080) puede ser igual que recibir un disparador por el servicio de la segunda pantalla (s50020). El tercer Disparador se asocia con el segundo dispositivo de la pantalla y puede tener información con respecto a un tiempo en los medios. El tercer disparador es un disparador de tiempo en los medios, que puede realizar la misma función como el disparador de tiempo base descrito anteriormente.

Enviar la notificación acerca de la información UI actualizada (s57090) puede incluir notificar acerca de la información UI actualizada. Ya que se determina que el tercer disparador se asocia con el segundo dispositivo de la pantalla, el receptor puede notificar al segundo dispositivo de la pantalla acerca del tercer disparador.

Solicitar la información UI actualizada (s57100) puede ser igual solicitar la información UI actualizar (s50040).

Transmitir la información UI como una respuesta (s57110) puede incluir transmitir la información UI del dispositivo primario al segundo dispositivo de la pantalla. En este momento, el tercer disparador se puede transmitir. Sin embargo, ya que el tercer disparador es un disparador de tiempo en los medios, es posible controlar solo el tiempo en los medios del segundo dispositivo de la pantalla. Por lo tanto, es posible realizar la sincronización de tiempo en los medios entre el segundo dispositivo de la pantalla y el receptor.

Recibir un disparador por el servicio de la segunda pantalla (s57120) puede ser igual a recibir un disparador para el servicio de la segunda pantalla (s50020). El cuarto disparador se asocia con el segundo dispositivo de la pantalla y puede tener información acerca de un tiempo del evento. El cuarto disparador es un disparador de tiempo del evento, el cual puede realizar la misma función como el disparador de activación descrito anteriormente.

Enviar la notificación acerca de la información UI actualizada (s57130) puede incluir notificar UI actualizada. Ya que se determina que el cuarto disparador se asocia con el segundo dispositivo de la pantalla, el receptor puede notificar el segundo dispositivo de la pantalla del cuarto disparador.

Solicitar la información UI actualizada (s57140) puede ser igual a solicitar la información UI actualizada (s50040).

Transmitir la información UI como una respuesta (s57150) puede incluir transmitir información UI del dispositivo al segundo dispositivo de la pantalla. En este momento, el cuarto disparador se puede transmitir.

Solicitar una aplicación de la segunda pantalla (s57160) puede incluir analizar información del segundo dispositivo de la pantalla acerca del cuarto disparador y solicitar la aplicación de la segunda pantalla desde el servidor de la aplicación para descargar la aplicación de la segunda pantalla de la locación de la URL TDO.

Regresar una aplicación de la segunda pantalla (s57170) puede incluir descargar la aplicación de la segunda pantalla de acuerdo a la solicitud. La aplicación de la segunda pantalla se puede descargar para realizar el Evento@Acción. En este momento, mientras que el servidor de la aplicación se informa de la información acerca del navegador del segundo dispositivo de la pantalla, el servidor de aplicación puede verificar fácilmente que se conecta el segundo dispositivo de la pantalla. En consecuencia, la aplicación se puede seleccionar y descargar automáticamente desde el servidor.

En resumen, si la cadena URI para el mensaje iTV se recibe mediante la DTVCC, el receptor puede transmitir, al segundo dispositivo de la pantalla encontrada, un evento indica que una UI nueva se ha actualizado. Los dispositivos de la segunda pantalla puede analizar la información del evento y enviar una Acción de "ObtenerCompatibleUIs" en para obtener la información UI nueva. El receptor puede enviar la información URI recibida del servidor TPT. Por este método, el segundo dispositivo de la pantalla puede recibir la información URI, procesa directamente la información TPT y AMT, y controla directamente la aplicación de la segunda pantalla.

Este proceso es posible si el Cliente del Disparador ATSC 2.0 se incluye en la aplicación del servicio de la segunda pantalla.

La figura 58 es un diagrama que muestra una modalidad de un método de, en un segundo dispositivo de la pantalla, acceder una TPT y la Aplicación de la Segunda Pantalla.

Entre los dos métodos descritos anteriormente, el método de transmitir la cadena URI para el mensaje iTV (Disparador) en el caso del Servicio del Cliente RemotoUI se describirá.

Este proceso puede incluir recibir un disparador por el receptor (s58010), recibir un disparador para el servicio de la segunda pantalla (s58020), notificar acerca de un disparador (s58030), enviar una respuesta "ok" (s58040), solicitar un archivo XML de la TPT (s58050), regresar un archivo XML de la TPT (s58060), recibir un disparador por el servicio de la segunda pantalla (s58070), notificar acerca de un disparador (s58080), enviar una respuesta "ok" (s58090), recibir un disparador por el servicio de la segunda pantalla (s58100), notificar un disparador (s58110), enviar una respuesta "ok" (s58120), solicitar una aplicación de la segunda pantalla (s58130) y/o regresar una aplicación de la segunda pantalla (S58140).

Recibir un disparador para el receptor (s58010) puede incluir recibir el disparador del el dispositivo primario por el receptor, esto es, el dispositivo primario, desde el radiodifusor mediante la corriente de radiodifusión. Ya que el primer disparador se para el receptor, el primer disparador no se suministra al segundo dispositivo de la pantalla.

Recibir un disparado por el servicio de la segunda pantalla (s58020) puede ser igual a recibir un disparador por el servicio de la segunda pantalla (s50020). El segundo disparador es un disparador para el servicio de la segunda pantalla y puede tener información acerca de un tiempo en los medios. El segundo disparador puede servir como el disparador precargado descrito anteriormente.

Notificar acerca de un disparador (s58030) puede incluir transmitir inmediatamente al receptor el disparador al segundo dispositivo de la pantalla a diferencia de la figura 57. Si la cadena de URI para el mensaje iTV se recibe mediante la DTVCC, el receptor puede suministrar el valor ÜRI recibido por el receptor al segundo dispositivo de la pantalla usando la Acción "AñadirUILista".

Enviar una respuesta "ok" (s58040) puede incluir transmitir un mensaje que indica que el disparador se ha recibido.

Solicitar un archivo XML de la TPT (s58050) puede ser igual a solicitar un archivo XML de la TPT (s57060). El módulo del disparador incluido en el segundo dispositivo de la pantalla puede acceder al servidor de la TPT que usa el valor ÜRI recibido, descargar los archivos TPT y AMT, y controlar directamente la aplicación de la segunda pantalla.

Regresar un archivo XML de la TPT (s58060) puede ser igual a regresar un archivo XML de la TPT (s57070).

Recibir un disparador para el servicio de la segunda pantalla (s58070) puede ser igual a recibir el disparador para el servicio de la segunda pantalla (s50020). El tercer disparador se asocia con el segundo dispositivo de la pantalla y puede tener información acerca de un tiempo en los medios. El tercer disparador es un disparador de tiempo en los medios, que puede realizar la misma función como el disparador de tiempo base descrito anteriormente.

Notificar acerca de un disparador (s58080) puede incluir suministrar el disparador similarmente a notificar acerca de un disparador (s580030).

Enviar una respuesta "ok" (s58090) puede ser igual a enviar una respuesta "ok" (s58040).

Recibir un disparador para el servicio de la segunda pantalla (s58100) puede ser igual a recibir un disparador para el servicio de la segunda pantalla (s50020). El cuarto disparador se asocia con el segundo dispositivo de la pantalla y puede tener información acerca de un tiempo del evento. El cuarto disparador es un disparador del tiempo del evento, que puede realizar la misma función como el disparador de activación descrito anteriormente.

Notificar acerca de un disparador (s58110) puede incluir suministrar el disparador similarmente a notificar acerca de un disparador (s58030).

Enviar una respuesta "ok" (s58120) puede ser igual a enviar una respuesta "ok" (s58040).

Solicitar una aplicación de la segunda pantalla (s58130) puede ser igual a la aplicación de la segunda pantalla (s57160).

Regresar una aplicación de la segunda pantalla (s58140) puede ser igual a regresar una aplicación de la segunda pantalla (s57170).

Esto es, el receptor puede siempre suministrar el disparador que tiene la información del evento asociada con el servicio de la segunda pantalla al segundo dispositivo de la pantalla y el segundo dispositivo de la pantalla puede operar inmediatamente usando la información de la TPT descargada. Ya que el disparador del tiempo en los medios se suministra periódicamente usando la DTVCC, el receptor deberá suministrar continuamente esta información.

Ya que el dispositivo primario o el dispositivo de pantalla secundario tienen el XML TPT, la AMT también se puede recibir cuando el disparador del evento se recibe desde el servidor del Disparador En Vivo en tiempo real.

Los dos métodos descritos anteriormente pueden realizarse diferentemente dependiendo de qué valor de la URL se aplica y la operación del receptor o la estructura y operación de la aplicación de servicio de la segunda pantalla se puede cambiar.

Los mecanismos de señalización del servicio de la segunda pantalla se describirán.

El servicio de la segunda pantalla se pueden señalar usando dos métodos: un primer método de, en el receptor, notificar que el servicio de la segunda pantalla está presente y un segundo método de buscar un dispositivo y servicio para detectar un aparato electrónico para proporcionar el servicio de la segunda pantalla cuando el segundo dispositivo de la pantalla se conecta a la red doméstica. Alternativamente, el receptor puede confirmar un descriptor de un aparato electrónico nuevo y solicita un descriptor del servicio.

La Señalización de Radiodifusión y la Señalización de Unidifusión se describirán en lo sucesivo.

En el caso de la Señalización de Radiodifusión, el segundo dispositivo de pantalla detecta el servicio del servidor RemotoUI, confirma al descriptor del dispositivo y solicita un perfil Dispositivolnfo compatible con el servicio de la segunda pantalla. Se puede recibir un evento y una URL de una TDO (aplicación interactiva) cambiada de acuerdo a un programa visto mediante el receptor se puede recibir.

En contraste, en el caso de Señalización de Unidifusión, el receptor puede confirmar si el Dispositivolnfo del segundo dispositivo de pantalla es compatible y transmite una URL de TDO compatible. La Acción RemoverUILista se puede transmitir para terminar la aplicación de la segunda pantalla ejecutada actualmente de modo que soporta las acciones tal como el mensaje de visualización y termina la UI ejecutada actualmente. El Evento@data suplementario se analiza y procesa por el receptor puede suministrar a la aplicación del servicio de la segunda pantalla por la Acción de ProcesoEntrada.

La Señalización de Radiodifusión y la Señalización de Unidifusión se describirán a continuación.

La figura 59 es un diagrama que muestra otra modalidad de la Señalización de Radiodifusión por un servicio del servidor RemotoUI.

En la señalización de radiodifusión se conecta primero a la red doméstica, el receptor puede notificar a todos los aparatos electrónicos del descriptor del dispositivo y el descriptor del servicio del mismo o recibir una solicitud desde otro punto de control y transmitir el descriptor del dispositivo y el descriptor del servicio del mismo.

Otra modalidad de la señalización de radiodifusión por el servicio del servidor RemotoUI puede incluir el descubrimiento del dispositivo y del servicio UPnP (s59010), enviar UILista (s59020), enviar UILista (s59030), solicitar UILista (s59040) y/o regresar la UILista (s59050).

El descubrimiento del dispositivo y el servicio UPnP (s59010) puede ser igual al descubrimiento del dispositivo y servicio UPnP (s52010).

Enviar UILista (s59020) puede incluir transmitir un mensaje "UIListaActualización" a todos los dispositivos UPnP. El dispositivo primario puede enviar el anuncio de la UIListaActualización a los Dispositivos UPnP en una lista "uilD" única. El segundo dispositivo de pantalla puede recibir este mensaje y verificar la uilD. Sin embargo, debido a la desalineación con una uilD especifica, el segundo dispositivo de la pantalla puede no realizar la actualización de la UI.

Enviar UILista (s59030) puede incluir la transmisión de un mensaje "UIListaActualización" a todos los dispositivos UPnP. A diferencia de enviar la UILista (S59020), se puede presentar la coincidencia uilD.

Solicitar la UILista (s59040) puede incluir la transmisión del segundo dispositivo de pantalla del perfil del dispositivo del mismo y solicitar la UILista, debido a que la coincidencia uilD está presente en la UILista en el envió (s59030). La acción de ObtenerCompatibleUIs capaz de obtener una UI compatible se puede usar.

Regresar la UILista (s59050) puede incluir la lista UI apropiada de la transmisión del dispositivo al segundo dispositivo de la pantalla de acuerdo a la solicitud.

La figura 60 es un diagrama que muestra una modalidad del Intercambio de la Capacidad del Dispositivo y del Descubrimiento del Dispositivo por un Servicio de la Segunda Pantalla.

Como se describe anteriormente, si el receptor se conecta primero a la red doméstica, el receptor puede notificar todos los aparatos electrónicos del descriptor del dispositivo y el descriptor del servicio del mismo o recibir una solicitud de otro punto de control y transmitir el descriptor del dispositivo y el descriptor del servicio del mismo.

Cada uno de los dispositivos UPnP conectados a la red doméstica, que recibe el descriptor del dispositivo y el descriptor del servidor del receptor, puede enviar la locación del descriptor del dispositivo del mismo usando el encabezado "LOCACIÓN" de la HTTP. Esto es, el dispositivo UPnP puede transmitir la locación del descriptor del dispositivo UPnP. Si una solicitud OBTENER HTTP se hace usando "LOCACIÓN", un archivo XML incluye información acerca del dispositivo se puede recibir.

En el dispositivo UPnP y el descubrimiento del servicio, un método de, en el dispositivo primario, detectar el segundo dispositivo de pantalla capaz de proporcionar el servicio de la segunda pantalla se introducirá. Esto se puede dividir grandemente en los dos métodos. Como un primer método, el segundo dispositivo prepara dos perfiles del dispositivo y notifica acerca de un archivo XML de los perfiles del dispositivo usando un encabezado HTTP. Asumir que un dispositivo primario incompatible ignora un encabezado HTT. Como un segundo método, en el perfil del dispositivo, la información llamada del segundo dispositivo de pantalla proporciona el servicio de la segunda pantalla se puede incluir en la "Información del Protocolo".

La figura 60 muestra un primer método En una modalidad del descubrimiento del dispositivo y la capacidad de intercambio del dispositivo para el servicio de la segunda pantalla puede incluir ejecutar una aplicación UPnP para el servicio de la segunda pantalla (s60001), encontrar los dispositivos UPnP (s60010), encontrar un RemotoUICliente (s60020), solicitar una descripción del dispositivo (s60030), recibir una descripción del dispositivo (s60040), solicitar una descripción de control de servicio (s60050), recibir una descripción de control de servicio (s60060), solicitar un perfil del dispositivo (s60070), recibir un perfil del dispositivo (s60080), poner una URL de una UI remoto (s60090), enviar una respuestal (s60100), enviar un mensaje al Servicio de Cliente RemotoUI (s60110), enviar una respuesta2 (s60120) y/o el usuario presiona el botón de la pantalla (S60130).

Ejecutar una aplicación UPnP para el servicio de la segunda pantalla (s60001), encontrar los dispositivos UPnP (s60010), encontrar un RemotoUICliente (s60020), solicitar una descripción del dispositivo (s60030), recibir una descripción del dispositivo (s60040), solicitar una descripción de control del servicio (s60050), recibir una descripción de control del servicio (s60060), solicitar un perfil del dispositivo (s60070), recibir un perfil del dispositivo (s60080), poner una URL de una UI remota (s60090), enviar una respuestal (s60100), enviar un mensaje al servicio del cliente RemotoUI (s60110), enviar una respuesta2 (S60120) y el usuario presiona el botón de la pantalla (s60130) puede ser igual a ejecutar una aplicación UPnP para el servicio de la segunda pantalla (s40001), encontrar los dispositivos UPnP (s40010), encontrar un RemotoUICliente (s40020), solicitar una descripción del dispositivo (s40030), recibir una descripción del dispositivo (s40040), solicitar una descripción del control del servicio (s40050), recibir una descripción del control del servicio (s40060), solicitar un perfil del dispositivo (s40070), recibir un perfil del dispositivo (s40080), poner una URL de una UI remota (s40090), enviar una respuestal (S40100), enviar un mensaje al Servicio del Cliente RemotoUI (s40110), enviar una respuesta2 (s40120) y el usuario presiona el botón en la pantalla (s40130), respectivamente.

En el primer método, como se muestra en la figura 60, después de encontrar los dispositivos UPnP (s60010), la notificación acerca de la locación del soporte del perfil del dispositivo del servicio de la segunda pantalla usando "X-ATSC-COMPAÑERO-LOCACIÓN" obtenida desde el encabezado HTTP se puede realizar. La parte representada por X-ATSC-COMPAÑERO-LOCACIÓN: http://10.177.56.36:37900/ATSC2ndScreenRemoteUIClientel.xml\r\ n es un "X-ATSC-COMPAÑERO-LOCACIÓN". El receptor puede ignorar el encabezado "LOCACIÓN" y en su lugar obtener el perfil del dispositivo del segundo dispositivo de pantalla que se desea por el receptor.

Entre el método, el dispositivo primario, detectar el segundo dispositivo de la pantalla capaz de proporcionar el servicio de la segunda pantalla, en el segundo método descrito anteriormente, el perfil del dispositivo se puede obtener en la locación del encabezado "LOCACIÓN" y el valor de la "Información del Protocolo" del segundo dispositivo de la pantalla se puede analizar y procesar dentro del perfil del dispositivo. Esto se puede realizar en la UILista en la solicitud (s52020) de la modalidad de la señalización de radiodifusión para el Servicio #1 del Servidor RemotoUI.

En el dispositivo descriptor de un dispositivo UPnP especifico, una lista de servicios proporcionables están presentes y una o una pluralidad de servicios pueden ser proporcionados. Cada servicio del dispositivo UPnP se puede controlar por otro dispositivo UPnP remoto y un evento se puede recibir. El evento se puede recibir solo cuando se notifique el servicio proporcionado utilizando el evento. Es posible notificar sobre el URL tal que los servicios proporcionados por el dispositivo UPnP se controlen y se genere un evento.

La Figura 61 es un diagrama que muestra una modalidad del esquema DispositivoPerfil X L del foro UPnP.

En la modalidad de señalización de radiodifusión para el Servicio #1 de Servidor RemotoUI, solicitando UILista (s52020) que se describirá adicionalmente. Este paso puede incluir el segundo dispositivo de pantalla preguntando al receptor que tiene el servicio de servidor RemotoUI si un UI adecuado para el segundo dispositivo de pantalla está presente. El "EntradaDispositivoPerfil" deberla estar en el formato de un archivo XSD mostrado en la Figura 61.

En consecuencia, el segundo dispositivo de pantalla deberá transmitir información acerca del perfil de dispositivo del mismo o el receptor en el formato de la Figura 61.

La Figura 62 es un diagrama que muestra una modalidad del Perfil de Dispositivo de un segundo Dispositivo de Pantalla.

En la modalidad de la señalización de difusión para el Servicio #1 de Servidor RemotoUI, solicitando UILista (s52020) que será descrito adicionalmente. La Figura 62 muestra un ejemplo de un perfil de dispositivo. Al solicitar el UILista (s52020), la información tal como el perfil de dispositivo mostrado se puede enviar al receptor.

Determinando si el segundo servicio se pantalla del perfil de dispositivo, el cual se desea que sea detectado por el segundo dispositivo de pantalla, está presente en el receptor, la información mostrada puede ser almacenada en el "EntradaDispositivoPerfil" variable y puede ser transmitida. El receptor puede confirmar la información "EntradaDispositivoPerfil" para definir el tipo de servicio para ser proporcionado, versión, resolución del segundo dispositivo de pantalla, un método de codificación de imagen por cobrar, etc.

La Figura 63 es un diagrama que muestra una modalidad de una descripción del Protocololnformación para un Segundo Servicio de Pantalla.

En la modalidad de la señalización de difusión para el Servicio #1 de Servidor RemotoUI, solicitando UILista (s52020) y Enviar UILista (s52030) será adicionalmente descrito.

Como se describió anteriormente, el receptor puede confirmar la información "EntradaDispositivoPerfil" para definir el tipo de servicio para ser provisto, la versión, resolución del segundo dispositivo de pantalla, un método de codificación de imagen por cobrar, etc. Una modalidad de "Una descripción del Protocololnformación para el Segundo Servicio de Pantalla" puede ser una modalidad de la información "EntradaDispositivoPerfil".

Cuando se suministra la información mostrada al receptor (solicitando UILista (s52020)), información UILista en XML que se transmite al segundo dispositivo de pantalla (enviar UIListado (s52030)).

Si el servicio de servidor RemotoUI no soporta el segundo dispositivo de pantalla deseado, en enviar UILista (s52030), se puede regresar la información de error para indicar que el servicio de servidor RemotoUI no puede apoyar el segundo dispositivo de pantalla.

La Figura 64 es un diagrama que muestra una modalidad de UILista mientras las acciones AgregarUILista y RemotoUILista están siendo ejecutadas en un segundo dispositivo de pantalla.

En la modalidad de señalización de difusión para el Servicio #1 de Servidor RemotoUI, solicitando UILista (s52020) y Enviar UILista (s52030) que se describirán adicionalmente.

Después de la solicitud UILista (s52020), el receptor puede detectar y suministrar la información RemotoUI compatible al segundo dispositivo de pantalla solicitante (enviar UILista (s52030)). La información recibida en enviar UILista (s52030) se muestra en la Figura 64.

Cuando se puede transmitir la información recibida del receptor a la segunda pantalla, el TPT y el ?MR se pueden procesar para insertar el TDO URL. En consecuencia, el segundo dispositivo de pantalla puede obtener solo la información sobre el UI remoto del receptor y la segunda aplicación de pantalla se puede descargar y ejecutar del servidor de aplicación de Internet fuera de la red del hogar. En este tiempo, se puede ejecutar la aplicación por la segunda aplicación de servicio de pantalla.

El locutor puede transmitir la segunda aplicación de pantalla para el segundo dispositivo de pantalla para el receptor sobre la red de difusión. En este caso, el receptor puede almacenar la aplicación para el segundo dispositivo de pantalla y proporcionar directamente la aplicación. En este caso, el servidor web puede operar en el receptor e imagen asociada y los datos se pueden descargar de un servidor de aplicación externa en lugar del receptor o la red del hogar. Si el DO es un NDO, NDO y los archivos de recurso asociados se pueden transmitir sobre la red de radiodifusión en el ATSC-NRT y el segundo servicio de pantalla se puede proporcionar.

En el caso de la señalización de difusión, el ciclo de vida de la segunda aplicación de pantalla se puede manejar por el receptor o la segunda aplicación del servicio de pantalla.

Primero, el método de, en el receptor, se describirá la gestión del ciclo de vida de la segunda aplicación de pantalla.

El receptor puede procesar la información sobre el disparador de tiempo de los medios de comunicación utilizando el DTVCC y luego notificar inmediatamente todos los dispositivos en la red del hogar de la variable "UIListaActualización" cuando el evento asociado con la segunda pantalla se presenta y este evento se ejecuta. Los dispositivos que describen al evento pueden checar la información UI que se ha actualizado y realizar la acción "ObtenerCompatiblesUIs" con la finalidad de obtener la información necesaria. En este tiempo, el servidor RemotoUI del receptor puede suministrar inmediatamente la dirección TDO.

Segundo, el método de, en la segunda aplicación del servicio de pantalla, gestionando el ciclo de vida de la segunda aplicación de pantalla se describirá.

En este caso, el receptor puede suministrar la información recibida al segundo dispositivo de pantalla y la segunda aplicación de servicio de pantalla será ejecutada. En caso de radiodifusión, si el cliente para el segundo dispositivo de pantalla solicita la acción "ObtenerCompatibleUIs", el receptor puede regresar directamente el URICadena de un mensaje iTV (disparador) recibido a través del DTVCC y el segundo dispositivo de pantalla puede descargar el archivo TPT utilizando el URICadena recibido e interpretar el TPT para operar similarmente al receptor. El receptor puede cambiar inmediatamente la variable "UIListaActualización" y transmitir la variable cambiada a todos los dispositivos siempre que el disparador de tiempo de medios o el evento disparador de tiempo se reciba utilizando el DTVCC, tal que los dispositivos realicen la acción "ConseguirCompatiblesUIs" para recibir el nuevo URICadena del mensaje (Disparador) de iTV.

La Figura 65 es un diagrama que muestra una modalidad de la señalización de unifidusión para un servicio de cliente RemotoUI.

Se describirá la señalización de unidifusión.

En este método, el servicio RemotoUICliente se incluye en el segundo dispositivo de pantalla. Si el dispositivo UPnP se conecta primero a la red doméstica, el dispositivo UPnP notifica a los otros dispositivos que el nuevo dispositivo ha sido conectado a la red doméstica. Como otro método, si una notificación periódica de solicitud de mensaje sobre un nuevo dispositivo se suministra o suministro a todos los dispositivos conectados a la red doméstica, todos los dispositivos conectados a la red domestica pueden enviar un mensaje de NOTIFICACIÓN a todos los dispositivos en respuesta a esta información. Primero, si el segundo dispositivo de pantalla soporta el segundo dispositivo de pantalla deberá ser determinado.

Una modalidad de la Señalización de unidifusión para el servicio cliente RemotoUI que puede incluir el dispositivo UPnP y el descubrimiento de servicios (s65010), solicitando un perfil de dispositivo (s65020), regresar un perfil de dispositivo (s65030), enviar la información TDO URL (s65040), regresar un mensaje HTTP (s65050), enviar un mensaje de pantalla (s65060) y/o regresar un mensaje HTTP (s65070).

Dispositivo UPnP y el descubrimiento de servicios (s65010) puede ser igual al dispositivo UPnP y el descubrimiento de servicios (s52010).

Solicitar un perfil de dispositivos (s65020) puede incluir el receptor la transmisión de información "EstáticoDispositivoInformación" al segundo dispositivo de pantalla detectado recientemente con la finalidad de determinar si el segundo dispositivo de pantalla soporta el segundo dispositivo de pantalla.

Devolver un perfil de dispositivo (s65030) es una respuesta para solicitar un perfil dispositivo (s65020), el cual obtiene el perfil dispositivo del segundo dispositivo de pantalla. Si se determina que el perfil dispositivo enviado por el segundo dispositivo de pantalla detectado recientemente no coincide "Estático Dispositivolnformación" o el segundo dispositivo de pantalla detectado recientemente no soporta el segundo servicio de pantalla, el segundo servicio de pantalla no puede iniciar.

"EstáticoDispositivoInformación" puede ser igual a "Dispositivolnformación" definido anteriormente. El receptor puede determinar si "EstáticoDispositivoInformación" igual a Dispositivolnformación. Si el número de los segundos dispositivos de pantalla detectados recientemente en la red doméstica es uno o más, se repite este proceso. Incluso cuando el segundo dispositivo de pantalla detectado no soporte el segundo servicio de pantalla, este proceso se realiza continuamente. Una o más piezas del software se pueden instalar dentro o eliminar del segundo dispositivo de pantalla y el valor resultado de este proceso se puede cambiar dependiendo en si el usuario ejecuta el software. Si se ha realizado la segunda aplicación del servicio de pantalla, se puede realizar el envió de información TDO URL (s65040).

Enviar la información TDO URL (s65040) puede incluir la información TDO URL de transmisión del receptor, la cual es el resultado de analizar el TPT y AMT. "AgregarUICadena" definida en el servicio cliente UPnP RemotoUI que puede ser utilizado. "AgregarUICadena" puede ser una acción ejecutada si el segundo dispositivo de pantalla satisface el Dispositivolnformación del segundo servicio de pantalla. El TDO URL puede incluir uno o más URLs. En caso de uno o más URLs, el URL para la ejecución inmediata se puede transmitir. En este momento, enviar un mensaje (s65060) de pantalla que se puede realizar selectivamente.

Regresar un mensaje (s65060) HTTP puede incluir enviar el resultado de enviar información TDO URL (s65040). Similarmente para enviar una respuestal (s40100), una respuesta tal como HTTP/1.1 200 OK puede ser enviado conforme a la circunstancia.

Enviar un mensaje de pantalla (s65060) puede incluir transmitir el mensaje de pantalla para el segundo dispositivo de pantalla. Ya que el servicio cliente RemotoUI tiene una Acción MostrarMensaje capaz de mostrar un mensaje en la pantalla del segundo dispositivo de pantalla, el TDO URL puede ser transmitido al segundo dispositivo de pantalla y un mensaje indicando que la segunda aplicación de pantalla asociada con el programa de Radiodifusión revisado actualmente está presente, que puede ser visto utilizando la Acción MostrarMensaje. Si el usuario confirma este mensaje, se puede ejecutar inmediatamente la segunda aplicación de pantalla.

Regresar un mensaje HTTP (s65070) puede incluir transmitir el resultado de enviar un mensaje (s65060) de pantalla. Similarmente para enviar una respuestal (s40100), una respuesta tal como HTTP/1.1200 OK que puede ser enviado conforme a la circunstancia.

La Figura 66 es un diagrama que muestra una modalidad de la Señalización de unidifusión para un Servicio del Cliente RemotoUI.

Cuando sea que se agregue el URL de un nuevo UI al UIListado del segundo dispositivo de pantalla, la segunda aplicación de servicio de pantalla puede proporcionar un ambiente en el cual se ejecute la nueva segunda aplicación de pantalla.

Una modalidad de la Señalización de unidifusión para el servicio de cliente RemotoUI de la Figura 66 muestra el proceso de terminar la segunda aplicación de pantalla ejecutada y ejecutar la nueva segunda aplicación de pantalla.

Una modalidad de la Señalización de unidifusión para el servicio de cliente RemotoUI puede incluir enviar una acción de EliminarUILista (s66010), regresar un mensaje HTTP (s66020), enviar un mensaje (s66030) de pantalla, regresar un mensaje HTTP (s66040), enviar la información (s66050) TDO URL, regresar un mensaje (s66060) HTTP, enviar un mensaje (s66070) de pantalla y/o regresar un mensaje (s66080) HTTP.

Enviar una acción (s66010) RemoverUILista puede incluir terminar la segunda aplicación de pantalla la cual está siendo ejecutada en la segunda aplicación de servicio de pantalla utilizando la acción "EliminarUILista" definida en el servicio de cliente RemotoUI. La segunda aplicación de servicio de pantalla puede estar consciente que la acción EliminarUILista se envía cuando el receptor termina el uso de la aplicación ejecutada recientemente del UI. En consecuencia, la segunda aplicación de servicio de pantalla podría terminar inmediatamente la segunda aplicación de pantalla ejecutada recientemente si el segundo dispositivo de pantalla recibe la acción EliminarUILista.

Regresar un mensaje HTTP (s66020) puede incluir enviar el resultado de enviar una acción EliminarUILista (s66010). Similarmente para enviar una respuestal (s40100), una respuesta tal como HTTP/1.1200 OK puede ser enviada conforme a la circunstancia.

Enviar un mensaje de pantalla (s66030) puede incluir enviar un mensaje de pantalla para el segundo dispositivo de pantalla. Después de enviar una acción EliminarUILista (s66010), un mensaje indicando la terminación de ejecución puede ser mostrado en la pantalla del segundo dispositivo de pantalla. En este caso, un mensaje apropiado puede ser mostrado en la pantalla utilizando la Acción PantallaMensaje.

Regresar un mensaje HTTP (s66040) puede incluir enviar el resultado de enviar un mensaje de pantalla (s66030). Similarmente para enviar una respuestal (s40100), una respuesta tal como HTTP/1.1200 OK puede ser enviada conforme a la circunstancia.

Enviar la información TDO URL (s66050) puede incluir realizar la acción AgregarUILista tal que el receptor transmita el TDO URL del UI para que se realice nuevamente. Cuando se ejecuta la segunda aplicación de pantalla, la segunda aplicación de servicio de pantalla puede ser ejecutada tan pronto como el TDO URL se agregue a UIListado. Por referencia, el TDO URL relaciona a la segunda aplicación de pantalla la cual se puede descargar directamente y ejecutar del receptor o solo se pueden descargar algunos datos de recursos del servidor de Internet. En adición, el TDO URL puede indicar una dirección de servidor de Internet externa. Si el TDO URL indica la dirección de servidor de Internet externa, la segunda aplicación de pantalla y todos los datos necesarios para la ejecución pueden ser descargados del servidor de Internet.

Regresar un mensaje HTTP (s66060) puede incluir enviar el resultado de enviar la información TDO URL (s66050). Similarmente para enviar una respuestal (s40100), una respuesta tal como HTTP/1.1200 OK puede ser enviada conforme a la circunstancia.

Enviar un mensaje de pantalla (s66070) puede incluir enviar el mensaje de pantalla al segundo dispositivo de pantalla. Después de enviar la información TDO URL (s66050), un mensaje indicando que se proporciona un nuevo segundo servicio de pantalla que se puede mostrar en la pantalla del segundo dispositivo de pantalla. Similarmente para enviar un mensaje de pantalla (s66030), se puede mostrar un mensaje apropiado en la pantalla utilizando la Acción PantallaMensaje.

Regresar un mensaje HTTP (s66080) puede incluir enviar el resultado de enviar el mensaje de pantalla (s66070). Similarmente para enviar una respuestal (s40100), una respuesta tal como HTTP/1.1 200 OK que puede ser enviada conforme a la circunstancia.

En caso de la señalización de unidifusión, se puede manejar el ciclo de vida de la segunda aplicación de pantalla administrada por el receptor o la segunda aplicación de servicio de pantalla.

Primero, el método de, en el receptor, será descrito la administración del ciclo de vida de la segunda aplicación de pantalla.

La segunda aplicación de servicio de pantalla puede estar consiente de solo la información "URL"(TDO_URL). En consecuencia, el receptor puede realizar la acción "AgregarUILista" con respecto al servicio del cliente RemotoUI en el segundo dispositivo de pantalla y ejecutar la segunda aplicación de pantalla en el segundo dispositivo de pantalla en un tiempo predeterminado. Si se termina la segunda aplicación de pantalla, la acción "EliminarUILista" se puede llevar a cabo para terminar la segunda aplicación de pantalla dentro de un tiempo predeterminado.

Si la información de tiempo de medios para realizar un TDO se proporciona en adición a un URL para el tiempo detallado, la segunda aplicación de servicio de pantalla puede ser ejecutada en un tiempo predeterminado. Sin embargo, ya que el tiempo en los medios es un tiempo relativo de medios está siendo reproducida actualmente por el receptor, este tiempo necesita ser cambiado a un tiempo absoluto entendido por cada dispositivo. El protocolo de tiempo de red (NTP) u otra información de tiempo que puede ser utilizada y un tiempo cuando se realice la acción se puede obtener agregando el tiempo de medios que tienen información de tiempo futura al NTP u otra información de tiempo. En el segundo dispositivo de pantalla, ya que la acción incluye la ejecución y terminación, esto se puede cambiar conforme a la implementación de la acción AgregarUILista y EliminarUILista.

Segundo, el método de, en la segunda aplicación de servicio de pantalla, será descrito la administración del ciclo de vida de la segunda aplicación de pantalla.

La segunda aplicación de servicio de pantalla deberá estar informada de la información con respecto a un evento o en tiempo cuando se ejecute la segunda aplicación de pantalla y se termine en el segundo dispositivo de pantalla. Por lo tanto, como se describió anteriormente, la segunda aplicación de servicio de pantalla incluye el cliente disparador y el receptor puede transmitir el UTICadena de la información mensaje iTV (Disparador) recibida utilizando el DTVCC conforme al Dispositivolnformación (Perfil de Dispositivo) del receptor.

El método de transmisión se puede dividir en gran parte en dos métodos: un primer método de transmitir un mensaje de disparo transmitido utilizando el DTVCC y procesado por el receptor sin cambio y un segundo método de, en el receptor, colectando solo la información necesaria para el segundo dispositivo de pantalla y suministrar solo la información necesaria y los datos en XML.

Primero, el método de, en el receptor, se describirá la suministra del disparador al segundo dispositivo de pantalla sin cambios.

Este método se puede terminar realizando la acción "AgregarUILista" con respecto al disparador recibido. El Servicio de Cliente RemotoUI puede suministrar esta información al cliente disparador y el cliente disparador puede descargar y procesar un TPT como en el receptor. El receptor deberá suministrar el disparador de tiempo de medios al segundo dispositivo de pantalla cuando se reciba el disparador de tiempo de medios utilizando el DTVCC. El receptor puede confirmar "appID", "eventoID", y "evento@destino" y no puede suministrar el disparador al segundo dispositivo de pantalla si el segundo dispositivo de pantalla no necesita recibir el disparador.

Segundo, el método de, en el receptor, filtrando y suministrando la información de disparo necesaria para el segundo dispositivo de pantalla que será descrito.

En este método, el receptor puede procesar el archivo TPT y el disparador y generar y suministrar los datos para ser procesados por el segundo dispositivo de pantalla. Este método se puede realizar incluso cuando el cliente disparador no opere en la segunda aplicación de servicio de pantalla y el archivo XML pueda ser transmitido y procesado a través de la acción "ProgresoEntrada". Es decir, la segunda aplicación de servicio de pantalla no procesa el TPT general y procesa solo los datos necesarios para el procesamiento actual o futuro, el cual se filtra por el receptor. Este método es ventajoso en que el "Evento@Datos" archivados también se puedan suministrar.

La Figura 67 es un diagrama que muestra una modalidad de Señalización De unidifusión para un Servicio de Cliente RemotoUI.

La Figura 67 muestra el segundo método descrito anteriormente, es decir, el método de, en el receptor, filtrar y suministrar la información de disparo necesaria para el segundo dispositivo de pantalla.

Una modalidad de la señalización de unidifusión para el servicio del cliente RemotoUI puede incluir enviar la información 1 del evento (s67010), regresar un mensaje HTTP (s67020), enviar información del evento 2 (s67030), regresar un mensaje HTTP (s67040), enviar información del evento 3 (s67050) y/o regresar un mensaje HTTP (s67060).

Enviar la información del evento 1 (s67010) que puede incluir enviar al receptor la información del evento recibida a la segunda pantalla. Como se describió anteriormente, el receptor puede procesar el archivo TPT y el disparador y generar y suministrar los datos para ser procesados por el segundo dispositivo de pantalla. En la segunda aplicación del servicio de pantalla, el cliente disparador no puede operar y el archivo XML puede ser recibido y procesado a través de la acción "ProgresoEntrada".

Regresar un mensaje HTTP (s67020) puede incluir enviar el resultado de la información (s67010) del evento 1. Similarmente para enviar una respuestal (s40100), una respuesta tal como HTTP/1.1 200 OK puede ser enviada conforme a la circunstancia.

Enviar la información (s67030) de evento 2 puede incluir enviar información sobre el evento similarmente para enviar la información (s67010) de evento 1. Como en TPT XML, los datos se pueden suministrar para el TDO conforme al evento. En este paso, la información sobre el evento 2 puede ser suministrada.

Regresar un mensaje HTTP (s67040) puede incluir enviar el resultado de enviar la información 2 del evento (s67030). Similarmente para enviar una respuestal (s40100), una respuesta tal como HTTP/1.1200 OK puede ser enviada conforme a la circunstancia.

Similarmente, enviar la información (s67050) del evento puede incluir enviar la información sobre el evento 3.

Regresar un mensaje (s67060) HTTP puede incluir enviar el resultado de enviar la información (s67050) del evento.

Similarmente para enviar una respuestal (s40100), una respuesta tal como HTTP/1.1 200 OK puede ser enviada conforme a la circunstancia.

En el segundo método descrito anteriormente, el receptor puede administrar el ciclo de vida de la segunda aplicación de pantalla. El ciclo de vida del segundo dispositivo de pantalla puede significar el proceso de analizar y procesar el TPT y la información AMT del segundo dispositivo de pantalla.

La Figura 68 es un diagrama que muestra una modalidad de la información "Eventolnformación" suministrada a un segundo dispositivo de pantalla por una acción ProcesoEntrada.

La Figura 68 muestra un ejemplo de una estructura de datos XML de la información de evento cuando el receptor procesa el archivo TPT y el disparador y genera y suministra los datos para ser procesados por el segundo dispositivo de pantalla en el método descrito anteriormente, en el receptor, filtrando y suministrando la información necesaria para el segundo dispositivo de pantalla.

Es decir, si el receptor maneja el ciclo de vida de la segunda aplicación de pantalla, la información de evento puede ser suministrada al cliente RemotoUI a través del archivo XML que tiene la estructura de datos de la Figura 68 utilizando la acción ProcesoEntrada. Incluso cuando el receptor recibe el disparador en vivo, similarmente, se puede procesar el disparador en vivo y solo la información acerca de un tiempo de ejecución y un TDO URL se pueden suministrar al segundo dispositivo de pantalla.

En la tabla de la Figura 68, @appID, URL, Evento, @eventoID, @acción y Datos pueden ser igual a la información sobre el disparador o el AMT recibido por el receptor. Sin embargo, "@mediosTiempo", "@inicioTiempo" y "@finTiempo" deberán procesarse especialmente por el receptor. Conforme a "@mediosTiempo", la información de la sintaxis "tiempo=" (o "@inicioMT" información del AMT) del disparador transmitido utilizando el DTVCC se puede procesar para determinar "@inicioTiempo" y "@finTiempo" otra vez. Ya que el receptor y el segundo dispositivo de pantalla no pueden utilizar la misma información de tiempo absoluta (hora de reloj de pared), el segundo dispositivo de pantalla puede operar conforme al tiempo de medios del contenido. Es decir, si se asume que la información de tiempo tal como un tiempo de inicio de ejecución y tiempo terminal de la acción se ajusta entre el receptor y el segundo dispositivo de pantalla conforme al NTP actual, una operación de conversión se puede realizar por el receptor antes de la transmisión.

Se describirán la suministra de transmisión y la estimación de tiempo de medios.

Como se describió anteriormente, ya que @inicioTiempo y @finTiempo se crean relativamente y se transmiten en base de un valor mediosTiempo actual cuando se transmite del receptor al segundo dispositivo de pantalla, la pérdida de tiempo generada sobre la transmisión pueden ser el valor "Fecha" del encabezamiento HTTP y la respuesta HTTP. Utilizando una diferencia en el valor de tiempo de llegada, el segundo dispositivo de pantalla puede encontrar un valor de tiempo más preciso. Ya que la diferencia entre el tiempo de medios actual y el @mediosTiempo es un tiempo de suministra de transmisión, se puede obtener el tiempo de medios actual por la siguiente ecuación. tiempo en los medios actuales = tiempo de suministra de transmisión (valor de tiempo sobre la recepción - valor "Fecha" de encabezamiento HTTP) + @mediosTiempo Por lo tanto, es posible estimar el valor de tiempo de medios actuales del receptor actual.

La Figura 69 es un diagrama que muestra la configuración entre el receptor y un segundo dispositivo de pantalla.

La configuración entre el receptor y el segundo dispositivo de pantalla se muestra. El receptor puede ser un Dispositivo (Servidor) Controlado. Un segundo Dispositivo de Pantalla es un Punto de Control (Cliente).

En la etapa de descubrimiento, el receptor puede multidifundir una lista de servicio y unirse a una red, y la segunda aplicación de pantalla puede multidifundir una solicitud para la lista de servicio y la puesta en marcha.

En el paso de la descripción, la segunda aplicación de pantalla puede solicitar la descripción de servicio del receptor.

En la presente invención, un nuevo dispositivo UPnP y el servicio pueden ser definidos con la finalidad de, a través del segundo dispositivo de pantalla, adquirir un servicio interactivo asociado con el contenido de Radiodifusión A/V recibido por medio de un televisor, es decir, un receptor, en base del UPnP.

La Figura 70 es un diagrama que muestra una modalidad de los Tipos de Servicios y los IDs de Servicios de los Servicios.

Un Receptor puede soportar un servicio Disparador, un servicio de Comunicación de Dos Maneras, y un servicio AppURL. También puede soportar un servicio de Servidor Apoderado HTTP. Tipos de Servicio y los IDs de servicio se muestran en la Figura 70.

El servicio de comunicación de dos vías puede permitir un segundo dispositivo de pantalla para determinar si hay un DO que esta ejecutado por el dispositivo primario que se prepara para emplear en la comunicación de dos vías con las aplicaciones en los segundos dispositivos de pantalla.

Un servicio Disparador, un servicio AppURL y un servicio de Servidor Proxy HTTP que será descrito más adelante.

La Figura 71 es un diagrama que muestra el concepto operacional de un servicio de suministra de disparador.

El servicio de suministra del disparador que puede significar un servicio para, a través del segundo dispositivo de pantalla, adquirir el servicio interactivo asociado con el contenido de Radiodifusión A/V recibido por medio del receptor TV en base del UPnP.

La Figura 71 muestra un proceso de, en el receptor, adquirir el disparador del DTVCC o el servidor ACR y transmitir el disparador al segundo dispositivo de pantalla sin cambios o en un estado de cambiar (expandir) el disparador al formato adecuado por el segundo dispositivo de pantalla.

Cada vez que se cambie el disparador, el disparador o el disparador expandido deberán estar transmitidos del receptor al segundo dispositivo de pantalla en tiempo real.

La Figura 72 es un diagrama que muestra una modalidad de un proceso de generar un disparador de activación expandido.

El disparador expandido (disparador de activación expandido) puede ser generado combinando el disparador adquirido del flujo DTVCC o el Servidor ACR y la información en el TPT. El disparador expandido puede ser generado combinando el TDO ID y ID de Evento, ID de Datos y el tiempo de Activación incluido en el disparador y el TDO URL, los atributos TDO, Evento, Acción, Difusión y datos en el TPT. La información en el TDO puede ser la información sobre el TDO y el evento asociado con la información en el disparador.

Aquí, el disparador expandido se puede referir como a un disparador aumentado.

La Figura 73 es un diagrama que muestra una modalidad de una Descripción de Esquema XML para un Disparador de Activación Aumentado.

La Especificación del Servicio Disparador será descrita.

El servicio Disparador puede ofrecer Disparadores, los Disparadores pueden ser adquiridos por el Televisor del (a) proceso ACR, (b) servicio #6 DTV CC del canal que está siendo visto actualmente, (c) servidor "disparador en vivo" Remoto o (d) Tabla (AMT) de Mensajes de Activación. Que puede depender de las circunstancias.

El Servicio Disparador también puede suministrar un Disparador "cambio de canal" especial cuando sea que se cambie el canal. El disparador de cambio de canal será descrito más adelante. Puede haber básicamente cuatro tipos de Disparadores para ser suministrados, 1) Disparadores en Base de Tiempo para el modelo de servicio interactivo TDO, 2) Disparadores de Activación para el modelo de servicio interactivo TDO, 3) Disparadores para el modelo de servicio interactivo de Ejecución Directa y 4) Disparadores "cambio de canal" Especiales.

Para la flexibilidad máxima, puede ser deseable tener la opción de suministrar todos los tipos de Disparadores a los segundos dispositivos de pantalla, y para suministrarlos tan pronto como llegue al Receptor.

Sin embargo, para que las segundas aplicaciones de pantalla se designen para proporcionar interacción de la misma manera como los receptores proporcionan interacción, puede ser deseable omitir los Disparadores Base de Tiempo para el modelo de interacción TDO y para suministrar cada Disparador de Activación para el modelo de interacción TDO y su tiempo de activación. Esto puede salvar estas segundas aplicaciones de pantalla de la necesidad para mantener las bases de tiempo y calcular los tiempos de activación. También puede ser deseable aumentar cada Disparador de Activación combinando la información del Disparador con la información del TPT sobre el elemento TDO y su elemento pequeño de Evento referenciado en el Disparador, de este modo guardar estas segundas aplicaciones de pantalla de la necesidad de tratar con el TPT.

Por lo tanto, el servicio de Disparo puede ofrecer dos opciones para la suministra de Disparo. Uno de ellos puede ser una opción de "flujo no filtrado" que el receptor suministra todos los Disparadores (sin aumento). Y el otro puede ser la opción "flujo filtrado" que suministra solo los Disparadores de Activación Aumentados para el modelo de interacción TDO. Todos los disparadores para los modelos de interacción diferentes del modelo de interacción TDO y los Disparadores de cambio de canal Especial.

El tiempo de suministra objetivo para cada Disparador de Activación Aumentado para el modelo de interacción TDO que puede ser su tiempo de activación. El tiempo de suministra objetivo para todos los otros Disparadores (incluyendo los Disparadores de Activación sin aumento en la opción de flujo no filtrado) que puede ser el tiempo que reciben por el Receptor. El tiempo de suministra objetivo de cada Disparador de cambio de canal especial puede ser el tiempo del cambio de canal.

El formato de suministra objetivo del servicio disparador se puede dividir en el formato de suministra para un Disparador de Activación Aumentado y el formato de suministra para todos los otros Disparadores.

La Figura 73 muestra el formato de suministra para un Aumento de Activación Aumentado. El formato de suministra para todos los otros disparadores será descrito más adelante.

El formato de suministra para un Disparador de Activación Aumentado puede incluir el atributo (©interacciónModelo, @appURL, y/o @cookieEspacio y Capacidades y/o elemento de Evento.

Las semánticas de los campos son como sigue.

El valor del atributo (©interacciónModelo puede ser el código numérico para el modelo de interacción asociado con el Disparador, utilizando el mismo código como para el campo cmdID en el comando SDOPrivadoDatos en el Servicio #6 del canal DTVCC utilizado para suministrar el Disparador.

El valor del atributo @appURL puede ser el valor del primer elemento pequeño URL del elemento TPT TDO que se identifica por el evento termino ("e=") en el Disparador.

El atributo @cookieEspacio puede estar presente cuando el elemento TPT TDO se identifique por el termino ("e=") de evento en el Disparador que contiene un atributo @cookieEspacio, y puede tener el mismo valor como aquel atributo.

El elemento de Capacidades puede estar presente cuando sea que el elemento TPT TDO se identifique por el termino ("e=") de evento en el Disparador contiene un elemento de Capacidades, y puede ser idéntico a aquel elemento.

El elemento de Evento puede representar el elemento del Evento identificado por el termino ("e=") del evento en el Disparador. (Estrictamente hablando, el termino evento en el Disparador identifica un elemento TDO en el TPT y un elemento pequeño de Evento del elemento TDO. Esto se refiere aquí como el elemento de Evento identificado por el término de evento en el Disparador.) El valor del atributo @acción puede ser el mismo como el valor del atributo de acción del elemento de Evento identificado por el termino ("e=") de evento en el Disparador.

El (©destino puede estar presente cuando sea que el elemento de Evento se identifique por el termino ("e=") de evento en el Disparador que contiene un atributo destino, y puede tener el mismo valor como aquel atributo.

El atributo (©difusión puede estar presente cuando sea que se identifique el elemento de Evento por el termino ("e=") de evento en el Disparador que contiene un atributo de difusión, y puede tener el mismo valor como aquel atributo.

El atributo (©datos puede estar presente cuando sea que el elemento pequeño de Datos del elemento de Evento se identifique por el termino ("e=") en el Disparador, y puede tener el mismo valor como aquel elemento.

Como se describió anteriormente, el disparador aumentado puede estar generado por combinar la información en el TPT y el disparador adquirido del flujo DTVCC o el Servidor ACR.

Como se describió anteriormente, el disparador expandido también puede ser llamado un disparador aumentado.

La Figura 74 es un diagrama que muestra una modalidad de una Descripción de Esquema XML para los Disparadores que no están aumentados.

Esto puede ser un formato XML del disparador el cual no está aumentado. El disparador "cambio de canal" especial descrito anteriormente también puede seguir este formato.

Una modalidad de la Descripción de Esquema XML para los Disparadores no aumentados pueden incluir el atributo @interacciónModelo y/o los atributos @DisparadorCadena.

Los semánticos de los campos son como sigue.

El atributo @interacciónModelo no puede estar presente para un disparador "cambio de canal" especial. Para otros disparadores, la interacciónModelo puede estar presente, y su valor puede ser el código numérico para el modelo de interacción asociado con el Disparador, utilizando el mismo código como para el campo cmdID en el comando SDOPrivadosDatos en el canal DTVCC. El @interacciónModelo para un Disparador adquirido de un servidor de disparador en vivo o derivado de un AMT que puede ser considerado para ser el modelo TDO.

El valor del atributo @DisparadorCadena puede ser la representación de cadena del Disparador. La representación de cadena del Disparador fue descrita en la sintaxis del disparador. Sin embargo, el disparador "cambio de canal" especial puede ser diferente. El atributo @disparadorCadena para un disparador "cambio de canal" especial puede tener un valor "**<mayor_núm>.<menor_núm>", donde <mayor_núm> puede ser el número de canal mayor original del nuevo canal (ya que se transmitió por la estación de televisión), y <menor_núm> puede ser el número de canal menor original del nuevo canal (ya que se transmitió por la estación de televisión), y <menor_núm> que puede ser el menor número de canal original del nuevo canal (ya que se transmitió por la estación de Televisión). Si el número de canal no es conocido, e¾ ese caso los valores <mayor_núm> y <menor_núm> pueden ser ambos "0".

La Figura 75 es un diagrama que muestra una modalidad de un formato de un Disparador de Activación Aumentado.

Esta puede ser otra modalidad del formato del disparador aumentado descrito anteriormente. @cookieEspacio, Capacidades, Eventos, (©acción, (©destino, @difusión y @datos que se describieron anteriormente. @activaciónTiempo puede ser el tiempo de activación, en la escala de tiempo de medios. @tdoURL puede ser igual al @appURL descrito anteriormente.

La Figura 76 es un diagrama que muestra una modalidad de un formato de un Disparador de Activación Aumentado.

Este puede ser otra modalidad del formato del disparador aumentado descrito anteriormente. @activaciónTiempo, (©tdoURL, (©cookieEspacio, Capacidades, Evento, (©acción, (©destino, (©difusión y (©datos que fueron descritos anteriormente. (©disponiblelnternet y (©disponibleDifusión (o @disponibleRadiodifusión) pueden ser de TPT. (©disponiblelnternet y (©disponibleDifusión que fueron descritos anteriormente.

La Figura 77 es un diagrama que muestra una modalidad de un formato de un Disparador de Activación Aumentado.

Esto puede ser otra modalidad del formato del disparador aumentado descrito anteriormente. (©activaciónTiempo, (©tdoURL, (©cookieEspacio, Capacidades, Evento, (©acción, (©destino, (©difusión y (©datos fueron descritos anteriormente.

El elemento ContenidoArticulo, el atributo (©actualizarDisponible, (SsondeoPeriodo, (©tamaño, (©disponiblelnternet, y (©disponibleDifusión pueden ser iguales a los elementos y atributos del TPT cuando se genere el disparador aumentado. Los elementos ContenidoArticulo, (©actualiacionesVentaja, (SsondeoPeriodo, (©tamaño, (©disponiblelnternet y (©disponibleRadiodifusión fueron descritos anteriormente.

La Figura 78 es un diagrama que muestra una modalidad de un formato de un Disparador de Activación Aumentado.

Esto puede ser otra modalidad del formato del disparador aumentado descrito anteriormente.

Las capacidades (©cookieEspacio, (©disponiblelnternet, (©disponibleRadiodifusión, ContenidoArticulo, (©actualizacionesDisponible, (SsondeoPeriodo, (©tamaño, (©disponiblelnternet, (©disponibleRadiodifusión, Evento, (©acción, (©destino y (©datos que fueron descritos anteriormente. @appID, @appTipo, @appNombre, @globalId, @appVersion, @frecuenciaDeUso, @expiraFecha, @pruebaTDO, URTL en el elemento TDO y el URL en el elemento ContenidoArticulo puede ser igual a los elementos y atributos del TPT cuando se genera el disparador aumentado. @appID, @appTipo, @appNombre, @globalId, @appVersion, @frecuenciaDeUso, @expiraFecha, @pruebaTDO, el URL en el elemento TDO y el URL en el elemento ContenidoArticulo será descrito más adelante.

La Figura 79 es un diagrama gue muestra una modalidad de las variables estado de servicio disparador.

Una modalidad de las variables estado de servicio disparador pueden definir el las variables estado de servicio disparador mostrado. El servicio Disparador puede tener las variables de estado listadas en la Figura 79.

El valor de la variable de estado ÚltimoNofiltradoDisparador que puede representar el Disparador en el flujo filtrado con el tiempo de suministra objetivo más reciente. Cuando es un Disparador de Activación, puede ser aumentado por la información de combinación en el Disparador de Activación con la información en el TPT para producir un documento XML confirmando al esquema XML representado por la Tabla descrita en la Figura 73. Cuando es un Disparador con el modelo de interacción diferente al TDO, puede tener la forma de un documento XML confirmando al esquema descrito en la Figura 74. Cuando es un Disparador de cambio de canal especial, el formato puede ser "**<mayor_núm>.<menor_núm>", como se describió anteriormente.

El valor de la variable de estado NofiltradaDisparadorSuministraTiempo puede ser el tiempo de suministra del Disparador en el flujo no filtrado con el tiempo de suministra objetivo más reciente.

El valor de la variable de estado FiltradoDisparadorSuministraTiempo puede ser el tiempo de suministra del Disparador en el flujo filtrado con el tiempo de suministra objetivo más reciente.

La Figura 80 es un diagrama que muestra una modalidad de las variables de estado de servicio de disparador.

Otra modalidad de las variables de estado de servicio disparador pueden tener las mismas variables de estado como la Figura 80.

El valor de la variable de estado ActualDisparador puede depender en cuál de las siguientes tres situaciones está en efecto. 1) no hay servicio de datos adjuntos interactivos asociados con programar actualmente los que está siendo visto en la pantalla primaria. 2) hay un servicio de datos adjuntos interactivos asociados con programar actualmente lo que está siendo visto en la pantalla primaria, y tiene el modelo de interacción de Ejecución Directa.3) Hay un servicio de datos adjuntos interactivos asociado con programar actualmente lo que está siendo visto en la pantalla primaria, y tiene el modelo de interacción TDO.

En el caso (1), el valor de la variable de estado ActualDisparador puede ser una cadena nula.

En el caso (2), el valor de la variable de estado ActualDisparador puede ser el Disparador más reciente que ha sido recibido por el televisor para programar actualmente los que esta siendo visto en la pantalla primaria.

En el caso (3), el valor de la variable de estado ActualDisparador puede ser una forma aumentada del más reciente Disparador de Activación aumentado entre los Disparadores de Activación que han sido recibidos por el televisor para programar actualmente lo que está siendo visto en la pantalla primaria (por ejemplo, un Disparador de Activación puede ser la base para la variable de estado ActualDisparador cuando llegue su tiempo de activación, y puede permanecer la base hasta que el Disparador de Activación alcance su tiempo de activación.) La forma aumentada del Disparador de Activación puede ser obtenida combinando la información en el Disparador de Activación con la información en el TPT. La forma aumentada puede ser igual a uno de los formatos de disparo aumentados descritos anteriormente.

La definición de la variable de estado ActualDisparador puede implicar que para los Disparadores de Activación de modelo de interacción TDO se suministran a los clientes UPnP en los tiempos de activación del Disparador.

En otra modalidad de las variables de estado de servicio de disparo, cuando sea que el disparador se cambie, con la finalidad de transmitir el disparador o el disparador expandido del receptor al segundo dispositivo de pantalla en tiempo real, ATSCDisparador y ATSCExpandidoDisparador puede estar definido como la variable de estado.

La variable de estado ATSCDisparador puede contener una referencia, en la forma de un URI, para el disparador recibido del flujo DTVCC o el servidor ACR. Esta variable puede incluir una URL para TPT (tabla de parámetros TDO), TDO ID, ID de Evento, ID de Datos, tiempo de medios, ID de contenidos, un tiempo de activación para el evento dirigido, y asi sucesivamente.

La variable de estado ATSCExpandidoDisparador puede contener los metadatos, en la forma de un Fragmento XML, asociado con TDO para el segundo dispositivo de pantalla. Estos metadatos podrían haber sido extraídos de tanto el TPT y el disparador recibido del flujo DTVCC o el servidor ACR. Esta variable puede tener el mismo esquema XML como la modalidad de la Figura 78.

El valor cambiado del ATSCDisparador definido anteriormente y el ATSCExpandidoDisparador puede ser adquirido en tiempo real cuando el receptor cambie la variable de estado basada en el mecanismo de Concurso Completo de UPnP.

La Figura 81 es un diagrama que muestra una modalidad de las Acciones de Servicio del Disparador.

Estas acciones pueden estar definidas tal que el segundo dispositivo de pantalla o el receptor lea arbitrariamente el valor de la variable de estado de servicio de disparador.

Una modalidad de las acciones de servicio de disparador puede definir la acción ConseguirÓltimoNofiltradoDisparador y ConseguírÚltimoFiltradoDisparador.

La Figura 82 es un diagrama que muestra una modalidad del argumento de una Acción ConseguirÚlti oNofiltradoDisparador.

El valor del argumento de salida ÚltimoNofiltradoDisparador puede ser el valor de la variable de estado ÚltimaNofiltradaDisparador.

La segunda aplicación de pantalla puede obtener el valor de la variable de estado ÚltimaNofiltradaDisparador, es decir, el disparador en el flujo no filtrado con el tiempo de suministra objetivo más reciente, utilizando la Acción ConseguirÚltimoNofiltradoDisparador.

La Figura 83 es un diagrama que muestra una modalidad de argumento de una Acción ConseguirÚltimaFiltradoDisparador.

El valor del argumento de salida ÚltimoFiltradoDisparador puede ser el valor de la variable de estado ÚltimoFiltradoDisparador.

La segunda aplicación de pantalla puede obtener el valor de la variable de estado ÚltimoFiltradoDisparador, es decir, el Disparador en el flujo filtrado con el tiempo de suministra objetivo más reciente, utilizando la Acción ConseguirÚltimoFiltradoDisparador.

La Figura 84 es un diagrama que muestra una modalidad de las Acciones de Servicio de Disparador.

En otra modalidad de las variables de estado de servicio de disparador descrito anteriormente, en la cual el ATSCDisparador y ATSCExpandidoDisparador se definen como la variable de estado, las acciones de servicio de disparador serán descritas.

Incluso en esta modalidad, la acción puede ser definida tal que el segundo dispositivo de pantalla o el receptor escribe arbitrariamente o lee el valor de ATSCDisparador y ATSCExpandidoDisparador.

La acción AjustarDisparador() puede permitir el uso del valor del ATSCDisparador. ActualDisparador puede ser argumento.

La acción AjustarExpandidoDisparador() puede permitir el uso del valor del ATSCExpandidoDisparador. ActualDisparador puede ser aumentado.

La acción de ConseguirDisparador() puede permitir leer el valor del ATSCDisparador. ActualDisparador puede ser argumento.

ObtenerExpandidoDisparador() puede permitir la lectura del valor de ATSCExpandidoDisparador. ActualDisparador puede ser argumento.

La Figura 85 es un diagrama que muestra una modalidad de una operación en una segunda pantalla cuando se adquiere un disparador a través de un servicio de suministra de disparador.

Como el segundo dispositivo de pantalla opera conforme a la información de acción incluida en el disparador o el disparador de activación expandido recibido del segundo dispositivo de pantalla a través del servicio de suministra del disparador que puede ser mostrado.

El disparador de la acción de ejecución/terminación puede ser adquirido a través del servicio de suministra del disparador.

El segundo dispositivo de pantalla puede adquirir el disparador de la acción de ejecución/terminación a través del servicio de suministra de pantalla y suministrar el URL del TDO objetivo y la información asociada del disparador adquirido para el DAE/navegador. El navegador puede realizar la acción incluida en el disparador, tal como la ejecución o terminación.

La Figura 86 es un diagrama que muestra el concepto operacional de un servicio de suministra de disparador.

Como el segundo dispositivo de pantalla opera conforme a la información de acción incluida en el disparador o el disparador de activación expandido del segundo dispositivo de pantalla a través del servicio de suministra del disparador que puede ser mostrado.

El segundo dispositivo de pantalla puede adquirir el disparador de la acción de evento del disparador a través del servicio de suministra del disparador y la información de extracción tal como el ID de Datos del disparador adquirido. Después de eso, los datos pueden ser suministrados al TDO ejecutado actualmente utilizando AJAX. El TDO puede realizar una operación apropiada conforme a los datos recibidos.

En otra modalidad de las variables de estado de servicio de disparador descrito anteriormente, en la cual el ATSCDisparador y el ATSCExpandidoDisparador se definen como la variable de estado, el concepto operacional del servicio de suministra del disparador será descrito.

En esta modalidad, en el caso del Modelo de Ejecución Directo, si el contenido, es decir, "c=", se incluye en el disparador recibido a través del flujo DTVCC o el servidor ACR, el receptor puede ajustar el valor de disparador base de tiempo recibido al valor de la variable de estado ATSCDisparador. Cuando el disparador base de tiempo llegue al receptor, el valor de la variable de estado se puede cambiar inmediatamente o se puede suministrar al segundo dispositivo de pantalla a través de la acción AjustarDisparador.

En la presente modalidad, en el caso del Modelo TDO, si el contenido id, es decir, "c=", no se incluye en el disparador recibido a través del flujo DTVCC o el servidor ACR, el receptor recibe el disparador de activación y luego extrae y combina la información asociada del TPT y la información del disparador para generar el disparador expandido. Después de eso, en (o antes) del tiempo de activación del disparador expandido, el valor de la variable de estado ATSCExpandidoDisparador se puede ajustar o suministrar al segundo dispositivo de pantalla a través de la acción AjustarExpandidoDisparador.

La Figura 87 es un diagrama que muestra las Variables de Estado de Servicio AppURL.

El servicio AppURL puede permitir los segundos dispositivos de pantalla determinar el URL base y el nombre de la segunda aplicación de pantalla asociada con el DO de ejecución actualmente.

El servicio UPnP AppURL puede tener dos variables de estado, AppURL y AppNombre.

El valor de la variable de estado AppURL puede ser la URL base de la segunda aplicación de pantalla asociada con el DO de ejecución actual. Cuando no hay DO con la ejecución de la segunda aplicación de pantalla asociada en el primer dispositivo de pantalla, el valor de la variable de estado AppURL puede ser la cadena nula.

El valor de la variable de estado AppNombre puede ser el nombre de la segunda aplicación de pantalla asociada con el DO de ejecución actualmente. Cuando no hay DO con la ejecución segunda aplicación de pantalla asociada en el primer dispositivo de pantalla, el valor de la variable de estado AppNombre puede ser la cadena nula.

La Figura 88 es un diagrama que muestra una Acción de Servicio AppURL.

El servicio AppURL puede tener una Acción, ConseguirAppURL.

La Figura 89 es un diagrama que muestra los Argumentos de una Acción ConseguirAppURL.

La Acción ConseguirAppURL puede tener dos argumentos, AppURL y AppNombre.

El argumento de salida AppURL puede ser el valor actual de la variable de estado AppURL. Y el argumento de salida AppNombre puede ser el valor actual de la variable de estado AppNombre.

En consecuencia, es posible obtener el valor actual de la variable de estado AppURL y el valor actual de la variable de estado AppNombre a través de la acción ConseguirAppURL.

La Figura 90 es un diagrama que muestra el concepto operacional de un servicio de Servidor HTTP Proxy.

Un Receptor puede soportar el servicio de Servidor HTTP Proxy. El servicio de servidor HTTP proxy puede significar un servicio para adquirir los TDOs/archivos a través de un receptor de Televisión si el segundo dispositivo de pantalla transmite los TDOs/archivos a través de una red de difusión.

El diagrama muestra el concepto operacional del servicio de Servidor HTTP proxy que puede incluir un sistema 90010 de envió, un servidor 90020 ACR, un servidor 90030 iTV ATSC 2.0 locutor, un receptor 90040 ATSC 2.0 y/o los segundos Dispositivos 90050 de pantalla.

El sistema 90010 de radiodifusión puede ser igual al sistema 42010 de radiodifusión.

El servidor 90020 ACR puede ser igual al servidor 42020 ACR.

El servidor 90030 ATSC 2.0 iTV emisora puede ser igual al servidor 420302.0 iTV ATSC emisora.

El receptor 90040 ATSC 2.0 puede recibir el disparador asociado con la Radiodifusión A/V y el servicio interactivo, adquirir el servicio interactivo utilizando el disparador, y proporcionar el servicio interactivo en la pantalla. Esto puede ser igual al receptor descrito anteriormente. El servicio de servidor HTTP apoderado puede permitir el receptor 90040 ATSC 2.0 para realizar la función similar a aquella del servidor apoderado, con la finalidad de proporcionar eficientemente el archivo requerido por el segundo dispositivo de pantalla para el segundo dispositivo de pantalla.

Los segundos dispositivos 90050 de pantalla pueden ser igual a los segundos dispositivos 42050 de pantalla.

El servicio de servidor HTTP proxy puede permitir al receptor acceder al flujo de difusión o el archivo sobre el Internet a través del segundo dispositivo de pantalla y permitir al segundo dispositivo de pantalla accesar al contenido transmitido a través del flujo de difusión. Si una pluralidad de los segundos dispositivos de pantalla entran al mismo archivo a través del Internet, es posible minimizar el acceso de los segundos dispositivos de pantalla al mismo archivo.

La Figura 91 es un diagrama que muestra una modalidad de una Variable de Estado de Servicio del Servidor Proxy.

El servicio de Servidor Proxy UPnP puede proporcionar un servidor apoderado HTTP, para permitir a los segundos dispositivos de pantalla accesar los archivos que se suministran al receptor de TV en la Radiodifusión a través de las sesiones FLAUTA, y para hacer la recuperación de los archivos de los servidores de Internet por los segundos dispositivos de pantalla más eficientes en casos cuando los segundos dispositivos de pantalla múltiples en un hogar están recuperando los mismos archivos simultáneamente.

La variable de estado y acción pueden estar definidos con la finalidad de lograr esto.

El servicio de Servidor Proxy HTTP UPnP puede tener una sola variable de estado, ProxyServidorURL.

El valor de la variable de estado ProxyServidorURL puede ser el URL del Servidor Proxy HTTP, por ejemplo, el URL para el cual HTTP solicita para que sea dirigido con la finalidad de encaminar las solicitudes a través del servidor proxy.

La Figura 92 es un diagrama que muestra una modalidad de una Acción de Servicio de Servidor Proxy.

El servicio de Servidor Proxy UPnP puede tener una sola Acción, ObtenerProxyURL.

La Figura 93 es un diagrama que muestra una modalidad de Argumentos de una Acción ObtenerProxyURL.

La Acción ObtenerProxyURL puede tener un solo argumento, ProxyURL.

El argumento de salida ProxyURL puede ser el valor actual de la variable de estado ProxyServidorURL.

En consecuencia, es posible obtener el valor actual de la variable de estado ProxyServidorURL a través de la acción de ObtenerProxyURL.

La Figura 94 es un diagrama que muestra una modalidad de SolicitudArchivos().

En otra modalidad de la variable de estado de servicio de Servidor Proxy UPnP HTTP, la Variable de Estado de Servicio del Servidor Proxy UPnP HTTP llamado ATSCProxyServidorURL puede ser definido. En adición, en esta modalidad, la acción llamada ObtenerProxyServidorURL() puede ser definido.

La variable de estado ATSCProxyServidorURL puede contener una referencia, en la forma de un URI, para el servidor proxy en el receptor. El servidor proxy tiene la solicitud HTTP para un archivo de un segundo dispositivo de pantalla y recupera el archivo de las sesiones FLAUTA en el flujo de difusión o el Internet. Luego, el servidor proxy envía el archivo recuperado al segundo dispositivo de pantalla como respuesta HTTP.

ObtenerProxyServidorURL() puede ser una acción que permite la lectura del valor del ProxyServidorURL. El ProxyServidorURL puede ser incluido como un argumento.

En otra modalidad de la variable de estado de servicio de servidor proxy UPnP HTTO, la variable de estado de servicio de servidor proxy HTTP UPnP llamado ATSCArchivoLista puede ser definido. En adición, en esta modalidad, la acción llamada SolicitudArchivos() pueden ser definidos.

El archivo incluido en el flujo de difusión se puede adquirir solo por el receptor capaza de recibir el contenido de Radiodifusión. Por tanto, con la finalidad de permitir el segundo dispositivo de pantalla, el cual no puede recibir el contenido de Radiodifusión, para accesar al archivo incluido en el contenido de Radiodifusión, se pueden definir las variables de estado UPnP y las acciones. Es decir, ATSCArchivoLista el cual es una lista de archivo para que sea descargada a través de la sesión de FLAUTA que se establece como la variable de estado UPnP o el segundo dispositivo de pantalla que se puede activar para adquirir un archivo especifico o una pluralidad de archivos a través de la acción SolicitudArchivos() solicitando los archivos del receptor.

La variable de estado ATSCArchivoLista puede contener la lista CSV de los archivos requeridos para el servidor proxy en el receptor.

La SolicitudArchivos() puede ser una acción pedida para descargar un archivo especifico incluido en el flujo de difusión a través del Internet. En particular, en caso de un archivo incluido en el flujo de difusión, el archivo requerido puede ser descargado a través de la sesión de FLAUTA.

La Figura 95 es un diagrama que muestra una modalidad de una Arquitectura del Segundo Dispositivo de Pantalla.

La teoría de operación será descrita.

Puede haber dos modos de operación: uno donde una aplicación (TDO) de disparo ejecute sobre el servidor de Televisión, y el otro donde una aplicación (App empaquetada) sin disparos ejecute en el receptor de Televisión.

En el caso de la ejecución de la aplicación disparada sobre el receptor de Televisión, cuando la programación se está revisando actualmente en un receptor de Televisión que tiene un servicio de datos interactivos asociados con el segundo soporte de pantalla, un usuario de un segundo dispositivo de pantalla puede activar una aplicación apropiada sobre el dispositivo. Esta aplicación puede ir a través del descubrimiento UPnP y el proceso de descripción para descubrir el servicio de Disparo, el servicio de Comunicaciones de Dos vías, y el servicio del Servidor Proxy en el receptor de Televisión.

La segunda aplicación de pantalla puede entonces suscribir al "concurso completo" UPnP para el servicio de Disparo para tener notificaciones de los Disparadores listos para suministrar, y puedan utilizar la Acción ObtenerÚltimoNofiltradoDisparador o la Acción ObtenerÚltimoFiltradoDisparador para tener los disparadores que se designan para utilizar. El resultado de esto es que la segunda aplicación de pantalla pueda obtener los Disparadores apropiados en los tiempos apropiados. La aplicación puede entonces actuar en estos Disparadores en cualquier manera que se diseñe para utilizarlos.

La segunda aplicación de pantalla también puede suscribir al "concurso completo" UPnP para el servicio de Comunicaciones de Dos vías para tener notificación de la dirección TCP/IP y el puerto a utilizar para solicitar una conexión para las comunicaciones de dos vías, y las notificaciones de cuando hay un DO ejecutando en el dispositivo primario que se prepara para comunicar. Entonces la aplicación puede emplear en las comunicaciones de dos vías con cualquier DO que soporte tales comunicaciones.

Las acciones causadas por los Disparadores y/o las comunicaciones de dos vías pueden requerir con frecuencia la segunda aplicación de pantalla para descargar archivos. Estos archivos pueden estar disponibles de los servidores HTTP en el Internet, o pueden estar disponibles de una sesión d en la Radiodifusión de Televisión o ambos.

Si todos los archivos deseados están disponibles a través del Internet, y si el segundo dispositivo de pantalla tiene una buena conectividad a la red, la aplicación simplemente puede recuperar los archivos directamente.

Si algunos o todos de los archivos deseados están disponibles solo por medio de la Radiodifusión de Televisión, y si el Receptor ofrece un servicio de Servidor Proxy HTTP, entonces la aplicación puede tener el URL de servidor proxy con la Acción ObtenerProxyURL y recuperar los archivos deseados a través del servidor proxy. La aplicación podría también escoger el uso del servidor proxy en otras situaciones donde podría ser más conveniente recuperar los archivos de esa manera en lugar de directamente.

En el caso de la ejecución de la aplicación no disparada en el receptor de Televisión, Independientemente de gue la programación este actualmente siendo revisada, un usuario puede activar un DO en el receptor de Televisión el cual, entre otras cosas, hace disponible el nombre y la locación de una aplicación complementaria para estar en marcha en un segundo dispositivo de pantalla a través del servicio AppURL.

Un punto de control en el segundo dispositivo de pantalla puede suscribir al "concurso completo" UPnP asociado con el servicio AppURL para tener notificación de cambios a la AppURL y las variables AppNombre. El punto de control podría entonces indicar al usuario del segundo dispositivo de pantalla que un servicio disponible está pendiente. Subsecuentemente, el usuario podría ver la AppNombre y seleccionar el servicio, resultando en la segunda aplicación de pantalla acompañante para estar en marcha en el segundo dispositivo de pantalla.

Las segundas aplicaciones de pantalla pueden estar asociadas con una ejecución DO en el receptor ATSC 2.0, incluso cuando aquel DO es un locutor proporcionado por la App Empaquetada previamente descargada al receptor cuyo ciclo de vida se controla por el consumidor en lugar del locutor. En la ausencia de los disparadores para identificar una segunda aplicación de pantalla acompañante, el receptor ofrece un servicio AppURL que permite un punto de control en el segundo dispositivo de pantalla para usar una acción ConseguirAppURL para entrar a una segunda aplicación URL de pantalla publicada y ponerla en marcha en el segundo dispositivo de pantalla.

Una modalidad de la arquitectura del segundo dispositivo de pantalla muestra la segunda aplicación de pantalla y el segundo dispositivo de pantalla interfuncionando con el receptor.

Una modalidad de la arquitectura del segundo dispositivo de pantalla puede incluir un servidor 95010 de contenido remoto, un receptor 95020 de televisión y/o un segundo dispositivo 95030 de pantalla.

El servidor 95010 de contenido remoto puede proporcionar contenido. El contenido puede ser previsto al receptor 95020 o el segundo dispositivo 95030 de pantalla.

El receptor 95020 de Televisión puede proporcionar el servicio de disparador UPnP y el servicio del servidor proxy UPnP. El receptor puede ser igual al receptor descrito anteriormente.

El segundo dispositivo 95030 de pantalla puede tener una segunda aplicación de pantalla (App ATSC 2.0) y la segunda aplicación de pantalla puede tener un módulo de Punto (CP) de Control UPnP en el manejador de disparador. El módulo (CP) del Punto de Control UPnP maneja todas las comunicaciones UPnP entre la Segunda Aplicación (App ATSC 2.0) de Pantalla y el disparador de Servicio y el servicio del Servidor Proxy en el Receptor(95020) de Televisión. Puede gestionar el proceso de descubrimiento, obtener el URL del servidor proxy, y suscribirse al concurso completo del servicio del Disparador.

Los disparadores que llegan del Disparador de servicio UPnP se pueden suministrar al Manejador del Disparador. Si un Disparador indica que un nuevo Objeto (DO) Declarativo es para que se descargue y se ejecute en el DAE (Ambiente de Aplicación Declarativa por ejemplo, navegador), el Manejador del Disparador puede tener cuidado de eso. Si un disparador indica que el DO ya a la ejecución en el navegador deberá tomar alguna acción, el Manejador del Disparador puede pasar el Disparador en el DO. El usuario del segundo dispositivo de pantalla puede interactuar con el Dos. El Manejador del Disparador puede ser invisible al usuario.

La Segunda App de Pantalla puede ejecutar las siguientes funciones como se necesite.1) Uso del descubrimiento UPnP y los protocolos de descripción para encontrar el servicio de Disparador y, si está disponible, el servicio del Servidor Proxy en el receptor de Televisión. 2) Usar el protocolo SUSCRIBIR UPnP para suscribir al concurso completo del Disparador. 3) Invocar la Acción ConseguirProxyURL del servicio de Servidor Proxy para tener el URL del servidor proxy HTTP (si está disponible). 4) Recibir los Disparadores suministrados a través de los eventos de servicio del Disparador. 5) Si un Disparador de Ejecución Directa se recibe, y el DO definido en el Disparador ya no está corriendo en el DAE, iniciarlo ejecutándolo en el DAE (descargando si primero si es necesario). 6) Pasar cada Disparador de Ejecución Directo recibido en el DO identificado en el Disparador (después de descargar e iniciar el DO si se necesita). 7) Si se recibe un Disparador TDO, y si el atributo de Acción del Disparador es cualquiera que sea diferente al "DisparadorEvento", realizar la Acción (por ejemplo, preparar para ejecutar un TDO, ejecutar un TDO, terminar un TDO, etc.). 8) Si se recibe un Disparador TDO, y si el atributo de Acción del Disparador es "DisparadorEvento", pasa el Disparador en el TDO identificado como el objetivo del Disparador. Si el TDO no se está ejecutando en el DAE, descartar el Disparador. 9) Descargar archivos (incluyendo TDOs) como se necesite, ya sea a través de una conexión de Internet directa o a través del servicio de Servidor Proxy en el Receptor de Televisión.

Los Disparadores de Ejecución Directo y el Disparador TDO pueden estar actuados en inmediatamente cuando se reciban, a menos que contengan un atributo de "propagación" o "difusión". Cuando un Disparador contenga un atributo de "propagación" o "difusión", la acción puede ser suministrada para un intervalo al azar.

La Figura 96 es un diagrama que muestra una modalidad de la estructura simplificada de un receptor.

El diagrama muestra la estructura simplificada del receptor que puede incluir una antena (rcvr2010), un sintonizador (rcvr2020), un EPG (rcvr2030), un Demodulador VSB o DVB (rcvr2040), un administrador de canales (rcvr2050), un módulo SI (rcvr2051), un decodificador (rcvr2060) del sistema MPEG-2 TS, un módulo (rcvr2070) lcyenda, un módulo (rcvr2080) de disparador, un navegador (rcvr2090) web, un marco (rcvr2091) UPnP, una pila (rcvr2100) protocolo de red, una interfaz (rcvr2110) de red, un módulo (rcvr2120) UI, un decodificador (rcvr2140) de audio, un decodificador (rcvr2150) de video, altavoces (rcvr2160), un módulo (rcvr2170) de pantalla, un procesador (rcvr2180) gráfico, un receptor (rcvr2190) de controlador remoto y/o un controlador (rcvr2200) remoto.

La antena (rcvr2010) puede recibir una señal de Radiodifusión conforme a un flujo de Radiodifusión. Aquí, la antena (rcvr2010) puede ser una generalmente utilizada en el campo téenico.

El sintonizador (rcvr2020) puede solicitar o acordar a un canal del receptor y puede incluir un amplificador de frecuencia de radio, un oscilador local, una conversión de frecuencia y circuito de entrada, un buscador, etc. El Sintonizador (rcvr2020) puede ser uno generalmente utilizado en el campo técnico.

El EPG(rcvr2030) puede ser un servicio de guia de programa de difusión para proporcionar un tiempo de difusión de programa de Televisión, contenido, e información de actor utilizando una frecuencia vacia de una Radiodifusión de Televisión o canal suplementario (guia de programa electrónico). El dato EPG recibido se almacena y el espectador manipula el EPG utilizando el control remoto para selecciona y reservar un programa, de este modo realizando el pago por orden de programa visto, búsqueda de programa por sujeto o tipo, grabación de video, etc. El EPG recibido también puede ser suministrado al módulo UI.

El Demodulador (rcvr2040) VSB o DVB puede modular una señal VSB o una señal DVB. El demodulador (rcvr2040) VSB o DVB puede restaurar el VSB o DVB modulado (por ejemplo, la señal modulada OFDM) a una señal original. El proceso de demodulación de VSB o el Demodulador (rcvr2040) DVB puede ser uno originalmente utilizado en el campo téenico.

El administrador (rcvr2050) de canal puede realizar la administración de canal utilizando el EPG recibido. El EPG procesado por el módulo SI puede ser suministrado. El administrador de canal puede servir como un administrador de canal general.

El módulo (rcvr2051) SI puede confirmar la información especifica de programa si el flujo de Radiodifusión se recibe por medio del Decodificador (rcvr2060) del Sistema MPEG-2 TS. Utilizando la información confirmada, cuantos subtítulos están presentes en el programa de difusión y la presencia del disparador en el servicio #6 que puede ser determinada.

El Decodificador (rcvr2060) del Sistema MPEG-2 TS puede decodificar el flujo (TS) de transporte de la señal demodulada. El Decodificador rcvr2060 del Sistema MPEG-2TS puede obtener y suministrar un flujo de subtítulos del flujo de transporte al módulo rcvr2070 de subtitulo. El Decodificador rcvr2060 del Sistema MPEG-2TS puede enviar la señal de audio y de vídeo decodificadas al decodificador de audio/video.

El Módulo (rcvr2070) de Lcyenda puede recibir el flujo de subtítulos. El módulo rcvr2070 de subtítulos puede monitorear el servicio #6 u otros servicios y determinar si el servicio #6 o los servicios para transmitir el disparador se seleccionan y envía al módulo rcvr2080 del disparador o si el texto de lcyenda se procesa y se muestra en una pantalla. Los datos del disparador se pueden suministrar al módulo rcvr2080 del disparador. Otros servicios de texto pueden estar sometidos al procesamiento de texto de leyenda y enviar al procesador rcvr2180 gráfico. El módulo (rcvr2070) de subtítulos suministra el disparador al módulo (rcvr2080) del disparador a través de la información confirmada si el disparador se incluye en el texto digital recibido actualmente.

El Módulo (rcvr2080) del Disparador puede analizar el disparador, TPT y/o la información AMT y procesar los datos analizados. El módulo rcvr2080 del disparador puede entrar la red a través de la pila rcvr2100 del protocolo de red utilizando el valor de información URI del disparador. El valor de información URI puede ser la dirección del servidor HTTP. El módulo rcvr2080 del disparador puede analizar el contenido del archivo TPT para obtener el TDO URL. En adición, el módulo rcvr2080 del disparador puede analizar el AMT para procesar datos. Se puede obtener otra información a través del análisis. Después de que se ha recibido el mensaje AMT, el TDO URL correspondiente al navegador web se suministra conforme a una operación y tiempo predeterminado o el TDO operativo actualmente que se puede parar en un tiempo predeterminado. Esto corresponde a una acción TDO y el módulo rcvr2080 del disparador se puede enviar a un comando al navegador web para operar. La operación del módulo rcvr2080 del disparador relacionado a la invención presente que será descrito con detalle más adelante. El módulo (rcvr2080) del disparador puede entrar directamente o indirectamente al servidor de Internet a través de la pila (rcvr2100) del protocolo de red. El módulo (rcvr2080) del disparador puede interpretar inmediatamente el disparador recibido a través del DTVCC y descargar y procesar el archivo TPT del Internet a través de la interfaz (rcvr2110) de red como necesario. Se puede procesar inmediatamente el archivo TPT después de la descarga, de este modo se realiza una operación necesaria. En este momento, si el disparador asociado con la segunda pantalla y el evento asociado se presentan, como se describió anteriormente, se puede realizar la comunicación con el segundo dispositivo de pantalla utilizando varios métodos. Tal comunicación se puede realizar por el marco (rcvr2091) UPnP descrito más adelante.

El Navegador (rcvr2090) Web puede recibir el comando del módulo rcvr2080 del disparador, un código clave del navegador del módulo rcvr2120 UI y un código clave del navegador del receptor rcvr2190 del controlador remoto y comunica con el montón rcvr2100 del protocolo red.

El Marco (rcvr2091) UPnP puede detectar el segundo dispositivo de pantalla y transmitir el disparador o regenerar y transmitir información necesaria para el segundo dispositivo de pantalla. Como se describió anteriormente, cuando se recibe el disparador a través de la interfaz (rcvr2110) de red, si el disparador asociado con la segunda pantalla y el evento asociado se presentan, el marco (rcvr2091) UPnP puede realizar la comunicación con el segundo dispositivo de pantalla.

La Pila (rcvr2100) del Protocolo de Red puede comunicar con el módulo rcvr2080 del disparador y el navegador web para entrar al servidor a través de la interfaz rcvr2110 de red.

La Interfaz (rcvr2110) de red realiza la conexión común de varias otras aperturas o la conexión de un equipo de red y una red externa. La interfaz de red se puede conectar al servidor para descargar un TDO, un TPT, un AMT, etc. Aquí, la operación de la interfaz rcvr2110 de red puede ser la operación de la interfaz rcvr2110 de red una generalmente utilizada en el campo téenico. La operación de la interfaz rcvrl090 de red relacionada a la presente invención será descrita con más detalle.

El Módulo (rcvr2120) UI puede recibir entrada de información por un espectador utilizando el controlador rcvr2200 remoto a través del receptor rcvr2190 del controlador remoto. Si la información recibida se relaciona a un servicio utilizando la red, el código clave del navegador se puede suministrar al navegador web. Si la información recibida se relaciona al video mostrado recientemente, se puede suministrar la señal al módulo rcvr2170 de visualización a través del procesador rcvr2180 gráfico.

El Decodificador (rcvr2140) de Audio puede decodificar la señal de audio recibida del Decodificador rcvr2060 del Sistema MPEG-2TS. Después de eso, se puede enviar la señal de audio decodificada al altavoz y emitirla al espectador. Aquí, el decodificador rcvr2140 de audio puede ser uno generalmente utilizado en el campo téenico.

El Decodificador (rcvr2150) de Vídeo puede decodificar la señal de vídeo recibida del Decodificador rcvr2060 del Sistema MPEG-2TS. Después de eso, la señal de vídeo decodificada se puede enviar al módulo rcvr2170 de visualización para que se emita al espectador. Aquí, el decodificador rcvr2150 de vídeo puede ser uno generalmente utilizado en el campo técnico.

Los altavoces (rcvr2160) pueden emitir la señal de audio al espectador. El altavoz puede ser uno generalmente utilizado en el campo técnico.

El Módulo (rcvr2170) de Visualización puede emitir la señal de vídeo al espectador. El módulo rcvr2170 de visualización puede ser uno generalmente utilizado en el campo técnico.

El procesador (rcvr2180) Gráfico, puede ejecutar el procesamiento con respecto al texto de lcyenda recibido del módulo rcvr2070 de texto y la información de entrada del espectador recibida del módulo rcvr2120 UI. La información procesada puede ser suministrada para el módulo rcvr2170 de visualización. El procesador rcvr2180 gráfico puede ser uno generalmente utilizado en el campo téenico.

El Receptor (rcvr2190) del Controlador Remoto puede recibir información del controlador rcvr2200 remoto. En este momento, el código clave se puede suministrar al módulo rcvr2120 UI y el código clave del navegador se puede suministrar al navegador web.

El Controlador (rcvr2200) Remoto suministra la señal de entrada por el espectador al receptor rcvr2190 del controlador remoto. El controlador rcvr2200 remoto puede recibir entrada del espectador para cambiar un canal virtual. En adición, el controlador remoto puede recibir información seleccionada por el espectador con respecto a la aplicación. El controlador rcvr2200 remoto puede suministrar la información recibida al receptor rcvr2190 de controlador remoto. En este momento, la información se puede suministrar de forma remota utilizando una luz (IR) infrarroja en una distancia fuera de un intervalo predeterminado.

La Figura 97 es un diagrama que muestra una modalidad de la estructura de un segundo dispositivo de pantalla.

Una modalidad de la estructura del segundo dispositivo de pantalla puede incluir un subsistema 97010 10, un sistema 97020 de archivo, un subsistema 97030 del protocolo de red y módulos 97040 básicos.

El subsistema 97010 10 se puede conectar con todos los dispositivos los cuales se montan en el segundo dispositivo de pantalla para la conexión externa. El subsistema 97010 10 se puede conectar con un teclado, una pantalla, un micrófono, un altavoz, estéreo estándar, un sensor de movimiento, un sensor de luz, un GPS y una cámara. Cada dispositivo 1/0 se puede controlar por un módulo clave, un módulo de control de visualización, un módulo de control de audio, un sensor de módulo de control y/o una cámara de módulo de control. Cada dispositivo I/O se controla por un controlador de dispositivo y cada sensor o cámara puede acceder a cualquier programa si una función se llama por el subsistema 9701010 en la forma de un SDK. En algunos casos, se puede restringir tal acceso es posible solo en una aplicación nativa.

El sistema 97020 de archivo puede leer y escribir un archivo para una tarjeta SD externa y se puede conectar a un USB para ejecutar la comunicación de datos. Un dispositivo tal como una tarjeta SD, una memoria flash o un USB se pueden conectar. Esto se puede controlar por la interfaz SD, el Control de Memoria Flash o el Control USB BUS.

El subsistema 97030 del protocolo de red puede realizar la comunicación a través del 3GPP, Wi-Fi y/o Bluetooth.

Los módulos 97040 básicos pueden ser incluidos en el segundo dispositivo. Un administrador de batería puede administrar la cantidad de batería del segundo dispositivo de pantalla y se puede utilizar un módulo de notificación cuando un proveedor de comunicación o un fabricante proporcione una notificación al segundo dispositivo de pantalla. En adición, se puede utilizar un módulo de almacenamiento para comprar aplicaciones para una segunda pantalla hechas utilizando un SDK abierto previsto por el segundo dispositivo de pantalla. Un administrador de aplicación puede administrar una aplicación instalada utilizando el módulo de almacenamiento y notificar sobre la actualización de la aplicación. En adición, se puede incluir un módulo web tal que el segundo dispositivo de pantalla realice el acceso a Internet. Varias funciones de la segunda pantalla se pueden ajustar conforme a la preferencia del personal y un programa de preferencia del usuario se puede utilizar.

Los módulos 97040 básicos tienen varias funciones y pueden ser programas instalados en el segundo dispositivo de pantalla. Sin embargo, los módulos denotados por las líneas punteadas pueden ser módulos de software instalados selectivamente por el usuario Por ejemplo, el módulo de marco UPnP se puede estar apoyado por el segundo dispositivo de pantalla o se puede instalar en el segundo dispositivo de pantalla. Si el módulo de marco UPnP se instala, también se instala una aplicación nativa o se ejecuta fácilmente una operación UPnP. Sin embargo, en la estructura del receptor, el marco UPnP puede permitir al usuario instalar una segunda aplicación de servicio de pantalla o una aplicación apoyando el marco UPnP. Es posible encontrar un receptor capaz de recibir una onda terrestre a través del módulo de marco UPnP.

La Figura 98 es un diagrama gue muestra un segundo escenario de servicio de pantalla.

Una modalidad del segundo Escenario de servicio de pantalla será descrita.

Una modalidad del segundo escenario del servicio de pantalla puede incluir recibir un disparador (s98010), solicitar un TPT (s98020), transmitir un TPT como una respuesta (s98030), solicitar un TDO (s98040), transmitir un TDO como una respuesta (s98050), ejecutar un TDO (s98060), enviar un mensaje escanearDispositivoLista (s98070), llamar una función de descubrimiento (s98080), notificar una aplicación (s98090) UPnP, múltiple Radiodifusión de un mensaje de búsqueda (s98100), notificar un marco (s98110) UPnP, regresar una lista (s98120) de dispositivos, regresar un identificador (s98130) de dispositivo, enviar un mensaje (s98140) escanearServicioLista, llamar una función (s98150) de lista de servicios, enviar un mensaje (s98160) ObtenerServicioDescripción, enviar un mensaje (s98170) HTTP, regresar una lista (s98180) de servicios, regresar una lista de mango (s98190) de servicio, enviar un mensaje (s98200) hnMango, llamar una función (s98210) de lista de servicio, enviar un mensaje (s98220) ObtenerDispositivoPerfil, enviar un mensaje (s98230) HTTP, regresar una repuesta XML (s98250) rápida, analizar una respuesta (s98260) rápida, enviar un mensaje (s98270) hnManejo, llamar una función (s98280) de Lista de servicio, enviar un mensaje (s98290) EntradaUILista, enviar un mensaje (s98300) HTTP, regresar una respuesta (s98310) jabón, regresar TiempoDeVida (s98320), enviar un mensaje (s98330) hnMango, llamar una función (s98340) de Lista de servicio, enviar un MostrarMensaje (s98350), enviar un mensaje (s98360) HTTP, volver Nulo (s98370), retorno Nulo (s98380) y/o ejecutar una segunda aplicación (s98390) de pantalla.

Recibir un disparador (s98010) puede incluir recibir el disparador del locutor utilizando un mensaje DTVCC iTV a través del flujo de difusión.

Solicitar un TPT (s98020) puede incluir analizar e interpretar el disparador recibido y solicitar el TPT relacionado al servidor de Internet del locutor.

Transmitir un TPT como una respuesta (s98030) puede incluir transmitir el TPT como una respuesta.

Solicitar un TDO (s98040) puede incluir solicitar el TDO del servidor de Internet del locutor si el TDO relacionado necesita ser descargado.

Transmitir un TDO como una respuesta (s98050) puede incluir transmitir el TDO requerido.

Ejecutar un TDO (s98060) puede incluir el módulo del disparador ejecutando el TDO.

Enviar un mensaje (s98070) escanearDispositivoLista puede incluir el DO ejecutado (o TDO) enviando un mensaje para solicitar la exploración de lista de dispositivos.

Llamar una función (s98080) de descubrimiento puede incluir llamar la función de descubrimiento del marco de UPnP para el descubrimiento del dispositivo.

Ejecutar una aplicación (s98090) UPnP puede incluir el segundo dispositivo de pantalla ejecutando una aplicación UPnP para una puesta en marcha del segundo servicio de pantalla. Este paso es independiente del dispositivo primario y se puede realizar antes de ejecutar una aplicación UPnP (s98090).

La Radiodifusión múltiple de un mensaje (s98100) de búsqueda puede incluir la multidifusión del marco UPnP del mensaje de búsqueda para la búsqueda para el segundo dispositivo de pantalla en la red del hogar.

Notificar un marco UPnP (s98110) puede incluir el segundo dispositivo de pantalla, el cual recibe el mensaje de búsqueda, transmitiendo un mensaje de notificación al dispositivo primario. Asi, es posible notificar sobre la presencia del segundo dispositivo de pantalla.

Regresar una lista de dispositivo (s98120) puede incluir el retorno del marco UPnP para la lista de dispositivo después del descubrimiento del dispositivo.

Regresar el mango (s98130) del dispositivo puede incluir suministrar la lista de dispositivo recibido para el DO.

Enviar un mensaje escanearServicioLista (s98140) puede incluir el DO ejecutado (o TDO) transmitiendo un mensaje para solicitar el escaneo del servicio de lista.

Llamar una función (s98150) de lista de servicio puede incluir llamar la función de lista de servicio del marco UPnP para el descubrimiento del servicio.

Enviar un mensaje ObtenerServicioDescripción (s98160) puede incluir solicitar la descripción del servicio del segundo dispositivo de pantalla del segundo dispositivo de pantalla.

Enviar un mensaje HTTP (s98170) puede incluir enviar el resultado de enviar el mensaje ObtenerServicioDescripción (s98160). Como se describió anteriormente, un mensaje tal como HTTP(1.1 200 OK (éxito) puede ser enviado. La descripción del servicio puede ser recibida en XML.

Regresar una lista de servicio (s98180) puede incluir regresar la lista de servicio después de que el marco UPnP reciba la descripción del servicio.

Regresar una lista del mango de servicio (s98190) puede incluir regresar la lista de servicio recibida.

Enviar un mensaje hnMango (s98200) puede incluir enviar un mensaje con la finalidad de obtener un perfil del dispositivo.

Llamar una función (s98210) de lista de servicio puede incluir llamar una función de lista de servicio del marco UPnP para el descubrimiento del servicio.

Enviar un mensaje ObtenerDispositivoPerfil (s98220) puede incluir solicitar la descripción del servicio del segundo dispositivo de pantalla del segundo dispositivo de pantalla. Enviar un mensaje HTTP (s98230) puede incluir enviar el resultado solicitud en enviar un mensaje ObtenerDispositivoPerfil (s98220). Como se describió anteriormente, un mensaje tal como HTTP/1.1200 OK (éxito) que puede ser enviado. Se puede recibir un perfil del dispositivo.

Regresar una respuesta rápida (s98240) puede incluir regresar el perfil del dispositivo recibido.

Regresar una respuesta XML rápida (s98250) puede incluir regresar el perfil del dispositivo recibido en XML.

Analizar una respuesta rápida (s98260) puede incluir el análisis DO del mensaje JABÓN.

Enviar un mensaje hnMango (s98270) que puede incluir enviar un mensaje con la finalidad de notificar el segundo dispositivo de pantalla de la dirección URL del segundo servicio de pantalla.

Llamar una función de Lista de servicio (s98280) que puede incluir llamar la función de lista de servicio del marco UPnP.

Enviar un mensaje EntradaUILista (s98290) puede incluir notificar el segundo dispositivo de pantalla de la dirección URL del segundo servicio de pantalla. La acción AgregarUILista descrita anteriormente se puede utilizar. El segundo dispositivo de pantalla puede agregar el URL adquirido al UIListado.

Enviar un mensaje HTTP (s98300) puede incluir enviar el resultado de solicitud en enviar un mensaje (s98290) de EntradaUILista. Como se describió anteriormente, un mensaje tal como HTTP/1.1200 OK (éxito) puede ser enviado.

Regresar una respuesta (soap) jabón (s98310) puede incluir una devolución de un mensaje indicando que el URL ha sido transmitido.

Regresar el TiempoDeVida (s98320) puede incluir enviar el resultado de solicitud en enviar un mensaje EntradaUILista (s98290), similarmente para enviar un mensaje HTTP (s98300).

Enviar un mensaje hnMango (s98330) puede incluir enviar un mensaje con la finalidad de suministrar un mensaje de la pantalla al segundo dispositivo de pantalla.

Llamar una función de Lista de servicio (s98340) puede incluir llamar la función de lista de servicio del marco UPnP.

Enviar un PantallaMensaje (s98350) puede incluir transmitir el mensaje de la pantalla al segundo dispositivo de pantalla. El mensaje de la pantalla puede incluir información tal como el tipo de mensaje. La acción PantallaMensaje descrita anteriormente puede ser utilizada. El segundo dispositivo de pantalla puede muestra el mensaje de la segunda pantalla conforme al mensaje de pantalla.

Enviar un mensaje HTTP (s98360) puede incluir enviar el resultado de enviar una MuestraMensaje (s98350). Como se describió anteriormente, un mensaje tal como HTTP/1.1 200 OK (éxito) puede ser enviado.

Regresar nulo (s98370) puede incluir regresar nulo si HTTP/1.1 200 OK se recibe.

Devolver nulo (s98380) puede incluir devolver inválido para el DO si inválido se recibe como una respuesta.

Ejecutar una segunda aplicación de pantalla (s98390) puede incluir el segundo dispositivo de pantalla ejecutando la segunda aplicación de pantalla.

La Figura 99 es un diagrama que muestra un método de procesamiento de un servicio interactivo en un primer dispositivo.

Una modalidad de un método de procesar un servicio interactivo en un primer dispositivo puede incluir enviar un mensaje de descubrimiento (s99010), recibir una solicitud para las descripciones (s990209, enviar una respuesta con las descripciones (s99030), recibir un disparador (s99040), combinar información para generar un disparador de activación aumentado (s99050) y/o enviar el disparador de activación aumentado generado (s99060).

Enviar un mensaje de descubrimiento (s99010) puede incluir enviar el mensaje de descubrimiento a una segunda aplicación de pantalla que corre en un segundo dispositivo. El mensaje de descubrimiento puede indicar el segundo servicio de soporte de pantalla proporcionado por el primer dispositivo. Aquí, el primer dispositivo puede ser el dispositivo primario descrito anteriormente o el receptor de Televisión. Aquí, el mensaje de descubrimiento no puede ser transmitido a un solo segundo dispositivo de pantalla pero puede ser multidifundido a una pluralidad de segundos dispositivos de pantalla. Aquí, el segundo servicio de soporte de pantalla puede ser el segundo servicio de pantalla descrito anteriormente. Enviar un mensaje de descubrimiento (s99010) puede ser incluido en el paso de descubrimiento de dispositivo descrito anteriormente.

Recibir una solicitud para las descripciones (s99020) puede incluir recibir una solicitud para las descripciones del segundo servicio de soporte de pantalla previsto por el primer dispositivo. El segundo dispositivo puede ser el segundo dispositivo de pantalla descrito anteriormente. La segunda aplicación de pantalla la cual se ejecuta en el segundo dispositivo de pantalla puede solicitar descripciones del segundo servicio de soporte de pantalla por el primer dispositivo del primer dispositivo. Recibir una solicitud para las descripciones (s99020) puede incluir el primer dispositivo recibiendo la solicitud. Esto puede ser incluido en el paso de descubrimiento de dispositivo descrito anteriormente.

Enviar una respuesta con las descripciones (s99030) puede incluir el primer dispositivo que transmite las descripciones a la segunda aplicación de pantalla en respuesta a la solicitud en recibir una solicitud para las descripciones (s99020). Esta respuesta puede incluir otra información en adición a las descripciones. Esto puede ser incluido en el paso de detección de dispositivos descrito anteriormente.

Recibir un disparador (s99040) puede incluir el primer dispositivo que recibe el disparador descrito anteriormente a través del flujo de radiodifusión o un servidor de internet. El flujo de difusión puede ser recibido a través del DTVCC como se describió anteriormente. Si el flujo de radiodifusión se recibe a través del servidor de Internet, como se describió anteriormente, esto puede ser recibido en la forma de un mensaje iTV o por medio del proceso ACR. Este disparador se puede suministrar a la segunda aplicación de pantalla por el servicio de disparador descrito anteriormente. Como se describió anteriormente, el servicio de disparador puede ser uno de los segundos servicios de soporte de pantalla. Como se describió anteriormente, el disparador puede ser un elemento de señalización cuya función es identificar la señalización y establecer el tiempo de disposición de eventos interactivos dirigidos a las aplicaciones para un segmento descrito por una tabla de parámetro de aplicación. El disparador recibido puede ser cualguiera de un disparador de tiempo base, un disparador de activación, un disparador de interacción y/o un disparador de cambio de canal. El disparador de interacción puede ser un disparador para un modelo de interacción diferente a un modelo de interacción TDO. Por ejemplo, un disparador puede tener un término id de contenido en el modelo de ejecución directo. El disparador de cambio de canal puede ser el disparador de cambio de canal especial descrito anteriormente, el cual puede ser recibido cuando el canal se cambie.

Combinar información para generar un disparador de activación aumentado (s99050) puede incluir extraer y combinar la información en el disparador de activación y la información en el TPT entre los disparadores recibidos. Esto puede ser igual al paso de generar el disparador aumentado, el disparador de activación aumentado y el disparador expandido. El formato en o después del proceso de generar el disparador de activación aumentado, se describió anteriormente.

Enviar el disparador de activación aumentado (s99060) puede incluir transmitir el disparador de activación aumentado generado a la segunda aplicación de pantalla. Esto puede ser la opción de flujo filtrado descrito anteriormente entre el disparador de servicios.

En una modalidad de la presente invención, el paso de recibir un mensaje de búsqueda se puede llevar a cabo antes de enviar el mensaje de descubrimiento. Se puede utilizar el mensaje de descubrimiento para encontrar un dispositivo para proporcionar un segundo servicio de soporte de pantalla. Se puede transmitir el mensaje de búsqueda utilizando un método de de unidifusión y Radiodifusión múltiple. Por este paso, el segundo dispositivo de pantalla puede detectar el primero dispositivo.

En otra modalidad de la presente invención, un servicio de disparador puede suministrar un disparador como una opción de flujo no filtrada. La opción de flujo no filtrada puede suministrar todos los tipos de disparadores al segundo dispositivo de pantalla como se describió anteriormente.

En otra modalidad de la presente invención, en la opción de flujo no filtrada, el primer dispositivo puede transmitir todos los disparadores a la segunda aplicación de pantalla tan pronto como se reciba el disparador.

En otra modalidad de la presente invención, el servicio de disparador puede proporcionar una opción de flujo filtrada. Como se describió anteriormente, la opción de flujo filtrada puede suministrar un disparador de activación aumentado, un disparador de interacción y/o un disparador de cambio de canal .

En otra modalidad de la presente invención, el disparador de activación aumentado incluye la información URL de aplicación que tiene el mismo valor con un elemento URL de un elemento de aplicación en la tabla de parámetro de aplicación. El elemento URL identifica un archivo el cual es parte de la aplicación, y el elemento de aplicación se identifica por el disparador de activación. La tabla del parámetro de aplicación puede ser el TPT descrito anteriormente. La aplicación puede ser un TDO. Aqui, la información URL de aplicación puede ser @appURL del disparador de activación aumentado descrito anteriormente. Aqui, el elemento URL puede ser un elemento URL en un elemento TDO del TPT. El disparador de activación aumentado se puede obtener de un valor de elemento URL en el elemento TDO del TPT asociado con el disparador de activación en un proceso de generación y la información URL de aplicación y el elemento URL puede tener el mismo valor.

En otra modalidad de la presente invención, el disparador de activación aumentado incluye además una información de evento representando un elemento de evento en la tabla de parámetro de aplicación, el elemento de evento identificado por el disparador de activación representa el evento para la aplicación, la información del evento incluye una información de acción que tiene el mismo valor con un atributo de acción del elemento de evento identificado por el disparador de activación, y el atributo de acción indica el tipo de acción para ser aplicado cuando se active el evento. La tabla del parámetro de aplicación puede ser el TPT descrito anteriormente. La aplicación puede ser un TDO. Aquí, la información de evento puede ser el elemento de evento del disparador de activación aumentado descrito anteriormente. Aqui, el elemento de evento puede ser un elemento de evento en un elemento TDO del TPT. La información de acción puede ser @acción del disparador de activación aumentado descrito arriba. Aqui, el atributo de acción puede ser @acción del elemento de evento del TPT. El disparador de activación aumentado se puede obtener de un valor de elemento de evento y el valor de @acción en el elemento TDO del TPT asociado con el disparador de activación en un proceso de generación y la información de acción y el atributo de acción puede tener el mismo valor.

En otra modalidad de la presente invención, el primer dispositivo suministra el disparador de activación aumentado en el tiempo de activación del disparador de activación aumentado, el primer dispositivo suministra el disparador de interacción cuando se recibe el disparador de interacción por el primer dispositivo, y el primer dispositivo suministra el disparador de cambio de canal cuando se cambie el canal. El disparador de activación aumentado puede ser suministrado en o antes del tiempo de activación como se describió arriba, el disparador de interacción puede ser suministrado a la segunda aplicación de pantalla tan pronto como se reciba el primer dispositivo y el disparador de cambio de canal pueda ser suministrado cuando se cambie el canal.

La Figura 100 es un diagrama que muestra una modalidad de un método de procesamiento en un servicio interactivo en una segunda aplicación de pantalla ejecutando en un segundo dispositivo.

Una modalidad de un método de procesar un servicio interactivo en una segunda aplicación de pantalla ejecutando en un segundo dispositivo puede incluir recibir un mensaje de descubrimiento (sl0010), enviar una solicitud para las descripciones (sl0020), recibir una respuesta con las descripciones (sl0030), entrar en un servicio de disparador (sl0040) y/o recibir un disparador del primero dispositivo (sl0050).

Recibir un mensaje de descubrimiento (sl0010) puede incluir recibir el mensaje de descubrimiento del primero dispositivo. Como se describió anteriormente, el primer dispositivo puede ser un dispositivo primario o un receptor de Televisión. El segundo dispositivo puede ser un segundo dispositivo de pantalla descrito anteriormente. El mensaje de descubrimiento puede servir para indicar el segundo servicio de soporte de pantalla provisto por el primer dispositivo. El primer dispositivo puede enviar el mensaje de descubrimiento a solo el segundo dispositivo o puede multi difundir el mensaje de descubrimiento a todos los dispositivos en la red del hogar. Este paso puede ser incluido en el dispositivo del paso de detección de dispositivos. Este paso puede ser el segundo dispositivo que recibe el mensaje de detección del primer dispositivo. Enviar un mensaje de detección (s99010) puede ser descrito desde el punto de vista de la segunda aplicación de pantalla.

Enviar una solicitud para las descripciones (sl0020) puede incluir solicitar descripciones del segundo servicio de soporte de pantalla proporcionado por el primer dispositivo del primer dispositivo. Recibir una solicitud para las descripciones (s99020) pueden ser descritas desde el punto de vista de la segunda aplicación de pantalla. Este paso se puede incluir en la detección del dispositivo descrito anteriormente.

Recibir una respuesta con las descripciones (sl0030) puede incluir recibir las descripciones del servicio como una respuesta a la solicitud enviada en el paso de enviar una solicitud para descripciones (sl0020). El primer dispositivo puede transmitir la descripción del servicio de los mismos a la segunda aplicación de pantalla. Enviar una respuesta con las descripciones (s99030) puede ser descrita desde el punto de vista de la segunda aplicación de pantalla. Este paso se puede incluir en el paso de detección de dispositivos descrito anteriormente .

Acceso de un servicio de disparados (sl0040) puede incluir entrar el servicio de disparador el cual es uno de los segundos servicios de soporte de pantalla. El primer dispositivo puede ser usado para recibir el disparador del flujo de radiodifusión o el servidor de Internet. El acceso al servicio de disparador se puede llevar a cabo en base de las descripciones recibidas en el paso de recibir una respuesta con las descripciones (sl0030). Entre las descripciones recibidas en el paso de recibir una respuesta con las descripciones (sl0030), las descripciones del servicio de disparador se puede utilizar.

Recibir un disparador del primer dispositivo (sl0050) puede incluir recibir el disparador del primer dispositivo utilizando el servicio de disparador visitado. Aquí, el servicio de disparador puede ser uno de los segundos servicios de soporte de pantalla. El disparador puede ser un elemento de señalización cuya función es identificar la señalización y establecer el tiempo de disposición de los eventos interactivos dirigidos a las aplicaciones para un segmento descrito por una tabla de parámetro de aplicación. Aqui, el disparador puede ser uno de un disparador de base de tiempo, un disparador de activación, un disparador de interacción y/o un disparador de cambio de canal. El disparador de interacción puede ser un disparador para un modelo de interacción diferente a un modelo de interacción TDO. Por ejemplo, el disparador puede tener un término id de contenido en el modelo de ejecución directo. El disparador de cambio de canal puede ser el disparador de cambio de canal especial descrito anteriormente y puede ser recibido cuando se cambie el canal.

En una modalidad de la presente invención, un paso de multidifusión de un mensaje de búsqueda además se puede incluir. Este paso se puede llevar a cabo antes de recibir el mensaje de detección. El mensaje de búsqueda se puede utilizar para detectar un dispositivo para proporcionar un segundo servicio de soporte de pantalla. Conforme a la modalidad, el mensaje de búsqueda se puede unidifundir. Por este paso, el segundo dispositivo puede detectar el primer dispositivo.

En otra modalidad de la presente invención, el disparador de servicio puede suministrar el disparador como una opción de flujo no filtrada. El flujo no filtrado puede suministrar todos los tipos de disparadores a la segunda aplicación de pantalla como se describió anteriormente.

En otra modalidad de la presente invención, en la opción de flujo no filtrada, todos los disparadores se pueden suministrar a la segunda aplicación de pantalla tan pronto como se reciba por el primer dispositivo.

En otra modalidad de la presente invención, recibir el disparador de activación aumentado del primer dispositivo se puede además incluir. El disparador de activación aumentado puede ser generado por extraer y combinar la información en el disparador de activación y la información en el TPT en el primer dispositivo. Esto puede ser igual a un proceso de generar el disparador aumentado descrito anteriormente, el disparador de activación aumentado y el disparador expandido. El proceso de generar el disparador de activación aumentado y el formato del mismo después de la generación que se describieron anteriormente.

En otra modalidad de la presente invención, el servicio de disparador puede proporcionar una opción de flujo filtrada. Como se describió anteriormente, la opción de flujo filtrada puede suministrar el disparador de activación aumentado, el disparador de interacción y/o el disparador de cambio de canal.

En otra modalidad de la presente invención, el disparador de activación aumentado incluye la información URL de aplicación que tiene el mismo valor con un elemento URL de un elemento de aplicación en la tabla del parámetro de aplicación. El elemento URL identifica un archivo el cual es parte de la aplicación, y el elemento de aplicación se identifica por el disparador de activación. La tabla del parámetro de aplicación puede ser el TPT descrito anteriormente. La aplicación puede ser un TDO. Aquí, la información URL de aplicación puede ser @appURL del disparador de activación aumentado descrito anteriormente. Aquí, el elemento URL puede ser un elemento URL en el elemento TDO del TPT. El disparador de activación aumentado se puede obtener de un valor del elemento URL en el elemento TDO del TPT asociado con el disparador de activación en un proceso de generación y la información URL de aplicación y el elemento URL puede tener el mismo valor.

En otra modalidad de la presente invención, el disparador de activación aumentado incluye además una información de evento que representa un elemento de evento en la tabla de parámetro de aplicación, el elemento de evento identificado por el disparador de activación representa el evento para la aplicación, la información del evento incluye una información de acción que tiene el mismo valor con un atributo de acción del elemento de evento identificado por el disparador de activación, y el atributo de acción indica el tipo de una acción para ser aplicada cuando se active el evento. La tabla del parámetro de aplicación puede ser el TPT descrito anteriormente. La aplicación puede ser un TDO. Aquí, la información del evento puede ser un elemento de evento del disparador de activación aumentado descrito anteriormente. Aquí, el elemento de evento puede ser un elemento de evento en el elemento TDO del TPT. Aqui, la información de acción puede ser @acción del disparador de activación aumentado descrito anteriormente. Aqui, el atributo de acción puede ser @acción en el elemento de evento del TPT. El disparador de activación aumentado se puede obtener de un valor de elemento de evento y el valor de @acción en el elemento TDO del TPT asociado con el disparador de activación en un proceso de generación y la información de acción y el atributo de acción puede tener el mismo valor.

En otra modalidad de la presente invención, el disparador de activación aumentado se suministra en el tiempo de activación del disparador de activación aumentado, el disparador de interacción se suministra tan pronto como sea posible, y el disparador de cambio de canal se suministra cuando se cambie el canal. El disparador de activación aumentado se puede suministrar en o antes del tiempo de activación como se describió anteriormente, el disparador de interacción se puede suministrar a la segunda aplicación de pantalla tan pronto como se reciba por el primer dispositivo y el disparador de cambio de canal se pueda suministrar cuando se cambie el canal.

La Figura 101 es un diagrama que muestra un aparato para procesar un servicio interactivo como el primer dispositivo.

Una modalidad de un aparato para procesar un servicio interactivo como un primer dispositivo puede incluir un primer módulo 101010 y/o un segundo módulo 101020.

Aquí, el primer dispositivo puede ser el dispositivo primario descrito anteriormente o el receptor de Televisión.

El primer módulo 101010 se puede configurar para recibir un disparador de un flujo de radiodifusión o un servidor de Internet. Aquí, el primer módulo 101010 es un módulo de recepción del disparador en el primer dispositivo y puede ser el sintonizador descrito anteriormente o el servidor de Internet. El flujo de difusión se puede recibir a través del DTVCC como se describió anteriormente. Si se recibe el flujo de radiodifusión a través del servidor de Internet, como se describió anteriormente, el flujo de difusión se puede recibir en la forma de un mensaje iTV o a través de un proceso ACR. El disparador se puede suministrar a la segunda aplicación de pantalla más tarde por el disparador de servicio descrito anteriormente. Como se describió anteriormente, el disparador de servicio puede ser uno de los segundos servicios de soporte de pantalla. Como se describió anteriormente, el disparador puede ser un elemento de señalización cuya función es para identificar la señalización y establecer el tiempo de reproducción de los eventos interactivos dirigidos a las aplicaciones para un segmento descrito por una tabla de parámetro de aplicación. El disparador recibido puede ser uno de un disparador de base de tiempo, un disparador de activación, un disparador de activación y/o un disparador de cambio de canal. El disparador de interacción puede ser un disparador para un modelo de interacción diferente a un modelo de interacción TDO. Por ejemplo, el disparador puede tener un término id de contenido en el modelo de ejecución directa. El disparador de cambio de canal puede ser el disparador de cambio de canal especial descrito anteriormente y se puede recibir cuando se cambie el canal.

El segundo módulo 101020 puede enviar el mensaje de detección, recibir una solicitud para las descripciones de servicio y enviar una respuesta de las mismas. En adición, el segundo módulo puede enviar el disparador al segundo dispositivo. El segundo módulo 101020 puede ser el módulo de marco UPnP descrito anteriormente.

El segundo módulo 101020 se puede configurar para enviar un mensaje de detección a una segunda aplicación de pantalla ejecutando en un segundo dispositivo. El mensaje de detección puede servir para indicar el segundo servicio de soporte de pantalla proporcionado por el primer dispositivo. Aquí, el mensaje de detección no se puede transmitir a solo el segundo dispositivo de pantalla pero se puede multidifundir a una pluralidad de segundos dispositivos de pantalla. Aquí, cada uno de los segundos servicios de soporte de pantalla puede ser el segundo servicio de pantalla. Esta operación se realiza para detectar el dispositivo.

El segundo módulo 101020 se puede configurar para recibir una solicitud para las descripciones de los segundos servicios de soporte de pantalla de la segunda aplicación de pantalla. El segundo módulo puede recibir la solicitud para las descripciones del segundo servicio de soporte de pantalla previsto por el primer dispositivo. La segunda aplicación de pantalla ejecutada por el segundo dispositivo de pantalla puede solicitar las descripciones del segundo servicio de soporte de pantalla previsto por el primer dispositivo del primer dispositivo. Esta solicitud se puede recibir. Esta operación se puede llevar a cabo por la detección del dispositivo.

El segundo módulo 101020 se puede configurar para enviar una respuesta con las descripciones a la segunda aplicación de pantalla. Como una respuesta a las solicitudes recibidas, las descripciones se pueden transmitir a la segunda aplicación de pantalla. Esta respuesta puede incluir otra información en adición a las descripciones. Esta operación se puede realizar para la detección del dispositivo.

El segundo módulo 101020 se puede configurar para suministrar el disparador al segundo dispositivo utilizando un servicio de disparador. El servicio de disparador puede ser uno de los segundos servicios de soporte de pantalla.

En una modalidad de la presente invención, el segundo módulo 101020 puede recibir el mensaje de búsqueda. Esta operación se puede realizar antes de enviar el mensaje de búsqueda. El mensaje de búsqueda se puede utilizar para detectar un dispositivo para proporcionar el segundo servicio de soporte de pantalla. El mensaje de búsqueda se puede transmitir utilizando un método de unidifusión o ultidifusión. Por lo tanto, el segundo dispositivo de pantalla puede detectar el primer dispositivo.

En otra modalidad de la presente invención, el disparador de servicio puede suministrar el disparador como la opción de flujo no filtrada. La opción de flujo no filtrada puede suministrar todos los tipos de disparadores al segundo dispositivo de pantalla como se describió anteriormente.

En otra modalidad de la presente invención, el segundo módulo 101020 puede suministrar todos los disparadores a la segunda aplicación de pantalla tan pronto como el primer módulo 101010 reciba los disparadores en la opción de flujo no filtrada.

En otra modalidad de la presente invención, el segundo módulo 101020 puede generar y suministrar el disparador de activación aumentada a la segunda aplicación de pantalla. El segundo módulo 101020 puede extraer y combinar a información en el disparador de activación y la información en el TPT entre los disparadores recibidos. Esto puede ser igual a la operación para generar el disparador aumentado descrito anteriormente, el disparador de activación aumentado y el disparador expandido. El proceso de generar el disparador de activación aumentada y el formato de los mismos después de la generación que fueron descritos anteriormente.

En otra modalidad de la presente invención, el disparador de servicio puede proporcionar una opción de flujo filtrado. Como se describió anteriormente, la opción de flujo filtrada puede suministrar el disparador de activación aumentado, el disparador de interacción y/o el disparador de cambio de canal.

En otra modalidad de la presente invención, el disparador de activación aumentado incluye la información URL de aplicación que tiene el mismo valor con un elemento URL de un elemento de aplicación en la tabla del parámetro de aplicación. El elemento URL identifica un archivo el cual es parte de la aplicación, y el elemento de aplicación se identifica por el disparador de activación. La tabla del parámetro de aplicación puede ser el TPT descrito anteriormente. La aplicación puede ser un TDO. Aquí, la información URL de aplicación puede ser @appURL del disparador de activación aumentado descrito anteriormente. Aquí, el elemento URL puede ser un elemento URL en un elemento TDO del TPT. El disparador de activación aumentado se puede obtener de un valor del elemento URL en el elemento TDO del TPT asociado con el disparador de activación en un proceso de generación y la información URL de aplicación y el elemento URL puede tener el mismo valor.

En otra modalidad de la presente invención, el disparador de activación aumentado incluye además una información de evento representando un elemento de evento en la tabla del parámetro de aplicación, el elemento de evento identificado por el disparador de activación, representa el evento para la aplicación, la información del evento incluye una información de acción que tiene el mismo valor con un atributo de acción del elemento de evento identificado por el disparador de activación, y el atributo de acción indica el tipo de una acción para que se aplique cuando se active el evento. La tabla del parámetro de aplicación puede ser el TPT descrito anteriormente. La aplicación puede ser un TDO. Aquí, la información del evento puede ser el elemento de evento del disparador de activación aumentado descrito anteriormente. Aquí, el elemento de evento puede ser un elemento de evento en un elemento TDO del TPT. La información de acción puede ser la @acción del disparador de activación aumentado descrito anteriormente. Aquí, el atributo de acción puede ser la @acción del elemento de evento del TPT. El disparador de activación aumentado se puede obtener de un valor de elemento de evento y el valor de @acción en el elemento TDO del TPT asociado con el disparador de activación en un proceso de generación y la información de acción y el atributo de acción puede tener el mismo valor.

En otra modalidad de la presente invención, el segundo módulo 101020 suministra el disparador de activación aumentado en el tiempo de activación del disparador de activación aumentado, el segundo módulo 101020 suministra el disparador de interacción cuando el disparador de interacción se reciba por el primer módulo, y el segundo módulo 101020 suministre el disparador de cambio de canal cuando se cambie el canal. El disparador de activación aumentado se puede suministrar en o antes del tiempo de activación como se describió anteriormente, el disparador de interacción se puede suministrar a la segunda aplicación de pantalla tan pronto como se reciba por el primer dispositivo y el disparador de cambio de canal pueda ser suministrado cuando se cambie el canal.

La Figura 102 es un diagrama que muestra un aparato para procesar un servicio interactivo como una segunda aplicación de pantalla ejecutándose en un segundo dispositivo.

Aquí, el segundo dispositivo puede ser el segundo dispositivo de pantalla descrito anteriormente.

Una modalidad de un aparato para procesar un servicio interactivo como una segunda aplicación de pantalla ejecutándose en un segundo dispositivo puede incluir un primer módulo 102010 y/o un segundo módulo 102020.

El primer módulo 102010 puede recibir un mensaje de detección, descripciones de servicio de solicitud y recibir una respuesta de los mismos. Aquí, el primer módulo 102010 puede ser el módulo de marco UPnP del segundo dispositivo de pantalla descrito anteriormente.

El primer módulo (102010) se puede configurar para recibir un mensaje de detección de un primer dispositivo. El mensaje de detección puede servir para indicar el segundo servicio de soporte de pantalla proporcionado por el primer dispositivo. El primer dispositivo puede enviar el mensaje de detección para solo el segundo dispositivo o puede difundir el mensaje de detección a todos los dispositivos en la red del hogar. Esta operación se puede realizar para detectar el dispositivo.

El primer módulo 102010 se puede configurar para enviar una solicitud para las descripciones de los segundos servicios de soporte de pantalla al primer dispositivo. El primer módulo 102010 puede solicitar las descripciones del segundo servicio de soporte de pantalla previsto por el primer dispositivo del primer dispositivo. Esta operación se puede llevar a cabo para detectar el dispositivo.

El primer módulo 102010 se puede configurar para recibir una respuesta con las descripciones del primer dispositivo. El primer módulo 102010 puede recibir las descripciones del servicio como una respuesta a la solicitud transmitida. El primer dispositivo puede transmitir las descripciones del servicio de los mismos a la segunda aplicación de pantalla. Se pueden recibir las descripciones. Esta operación se puede realizar para detectar el dispositivo.

El segundo módulo 102020 puede entrar al servicio de disparador y recibir el disparador. El segundo módulo 102020 puede ser el subsistema del protocolo de red descrito con anterioridad.

El segundo módulo 102020 se puede configurar para entrar al servicio del disparador utilizando la información dada en las descripciones. El segundo módulo 102020 puede entrar al servicio de disparador el cual es uno de los segundos servicios de soporte de pantalla. El primer dispositivo puede recibir el disparador del flujo de difusión o el servidor de internet. Entrar al servicio del disparador se puede llevar a cabo en base de las descripciones recibidas del primer dispositivo. Entre las descripciones recibidas, la descripción del servicio del disparador se puede utilizar.

El segundo módulo 102020 se puede configurar para recibir un disparador del primer dispositivo utilizando el servicio del disparador. El segundo módulo 102020 puede recibir el disparador del primer dispositivo utilizando el servicio del disparador. Aqui, el servicio del disparador puede ser uno de los segundos servicios de soporte de pantalla. El disparador puede ser un elemento de señalización cuya función es identificar la señalización y establecer la sincronización de disposición de los eventos interactivos dirigidos a las aplicaciones para un segmento descrito por una tabla de parámetro de aplicación. Aqui, el disparador puede ser uno de un disparador de base de tiempo, un disparador de activación, un disparador de interacción y/o un disparador de cambio de canal. El disparador de interacción puede ser un disparador para un modelo de interacción diferente a un modelo de interacción TDO. Por ejemplo, el disparador puede tener un término id de contenido en el modelo de ejecución directa. El disparador de cambio de canal puede ser el disparador de cambio de canal especial descrito anteriormente y puede ser recibido cuando se cambie el canal.

En una modalidad de la presente invención, el primer módulo 102010 también puede multidifundir el mensaje de búsqueda. La multidifusión se puede llevar a cabo antes de recibir el mensaje de detección. El mensaje de búsqueda se puede utilizar para detectar un dispositivo para proporcionar un segundo servicio de soporte de pantalla. Conforme a la modalidad, el mensaje de búsqueda puede ser unidifundido. Para este paso, el segundo dispositivo puede detectar el primer dispositivo.

En otra modalidad de la presente invención, el servicio del disparador puede suministrar el disparador como una opción de flujo no filtrada. La opción de flujo no filtrada puede suministrar todos los tipos de disparadores a la segunda aplicación de pantalla como se describió anteriormente.

En otra modalidad de la presente invención, el primer módulo 102010 también puede recibir el disparador de activación aumentado del primer dispositivo. El disparador de activación aumentado puede ser generado por extraer y combinar la información en el disparador de activación y la información en el TPT en el primer dispositivo. Esto puede ser igual a un proceso de generar el disparador aumentado descrito anteriormente, el disparador de activación aumentado y el disparador expandido. El proceso de generar el disparador de activación aumentado y el formato del mismo después de la generación fueron descritos anteriormente.

En otra modalidad de la presente invención, el servicio del disparador puede proporcionar una opción de flujo filtrada. Como se describió anteriormente, la opción de flujo filtrada puede suministrar el disparador de activación aumentado, el disparador de interacción y/o el disparador de cambio de canal.

En otra modalidad de la presente invención, el disparador de activación aumentado incluye la información URL de aplicación que tiene el mismo valor con un elemento URL de un elemento de aplicación en la tabla del parámetro de aplicación. El elemento URL identifica un archivo el cual es parte de la aplicación, y el elemento de aplicación se identifica por el disparador de activación. La tabla del parámetro de aplicación puede ser el TPT descrito anteriormente. La aplicación puede ser un TDO. Aquí, la información URL de aplicación puede ser @appURL del disparador de activación aumentado descrito anteriormente. Aquí, el elemento URL puede ser un elemento URL en el elemento TDO del TPT. El disparador de activación aumentado se puede obtener de un valor de elemento URL en el elemento TDO del TPT asociado con el disparador de activación en un proceso de generación y la información URL de aplicación y el elemento URL puede tener el mismo valor.

En otra modalidad de la presente invención, el disparador de activación aumentado incluye además una información de evento que representa un elemento de evento en la tabla del parámetro de aplicación, el elemento de evento identificado por el disparador de activación representa el evento para la aplicación, la información del evento incluye una información de acción que tiene el mismo valor con un atributo de acción del elemento de evento identificado por el disparador de activación, el atributo de acción indica el tipo de una acción para ser aplicado cuando se active el evento. La tabla del parámetro de aplicación puede ser el TPT descrito anteriormente. La aplicación puede ser un TDO. Aquí, la información de evento puede ser un elemento de evento del disparador de activación aumentado descrito anteriormente. Aquí, el elemento de evento puede ser un elemento de evento en el elemento TDO del TPT. Aquí, la información de acción puede ser la @acción del disparador de activación aumentada descrita con anterioridad. Aquí, el atributo de acción puede ser la (©acción en el elemento de evento del TPT. El disparador de activación aumentado se puede obtener de un valor de elemento de evento y el valor de @acción en el elemento TDO del TPT asociado con el disparador de acción en un proceso de generación y la información de acción y el atributo de acción puede tener el mismo valor.

En otra modalidad de la presente invención, el disparador de activación aumentado se suministra en el tiempo de activación del disparador de activación aumentado, se suministra el disparador de interacción tan pronto como sea posible, y el disparador de cambio de canal se suministra cuando se cambie el canal. El disparador de activación aumentado se puede suministrar en o antes del tiempo de activación como se describió anteriormente, el disparador de interacción se puede suministrar a la segunda aplicación de pantalla tan pronto como se reciba por el primer dispositivo y el disparador de cambio de canal se pueda suministrar cuando se cambie el canal.

La presente invención se relaciona a un método de ínter trabajar con un segundo dispositivo de pantalla mientras se recibe un servicio de difusión. Si se monta un marco UPnP en un receptor y un módulo adicional capaz de un segundo servicio de pantalla mientras sea compatible con el marco UPnP que se monta en el segundo dispositivo de pantalla, es posible para un locutor simplemente implementar el servicio de pantalla de servicio.

Esta provisto el marco UPnP para conectar los aparatos electrónicos a una red del hogar y servir funciones conforme a los aparatos electrónicos. La presente invención relaciona la extensión de un Servicio del Cliente RemotoUI UPnP existente y el Cliente de Servidor RemotoUI UPnP. En consecuencia, es posible recibir el segundo servicio de pantalla mientras es compatible con los aparatos UPnP existentes.

Modo para la Invención Se han descrito varias modalidades en el mejor modo para llevar a cabo la invención.

Aplicabilidad Industrial La presente invención está disponible para una serie de campos de provisión de servicio de difusión.

Será aparente para aquellos expertos en la téenica que varias modificaciones y variaciones se pueden hacer en la presente invención sin salirse del espíritu del alcance de la invención. Así, se pretende que la presente invención cubra las modificaciones y variaciones de esta invención provistas que vienen dentro del alcance de las reivindicaciones adjuntas y sus equivalentes.

Claims

REIVINDICACIONES

1. Un método de procesar un servicio interactivo en un primer dispositivo, el método caracterizado en que comprende: enviar un mensaje de detección a una segunda aplicación de pantalla que se ejecuta en un segundo dispositivo, en donde el mensaje de detección anuncia los servicios del segundo soporte de pantalla que el primer dispositivo puede proporcionar; recibir una solicitud para las descripciones de los servicios del segundo soporte de pantalla de la segunda aplicación de pantalla; enviar una respuesta con las descripciones a la segunda aplicación de pantalla; recibir un disparador de un flujo de radiodifusión o un servidor de internet; y suministrar el disparador al segundo dispositivo utilizando un servicio de disparador, en donde el servicio del disparador es uno de los segundos servicios de apoyo de pantalla, en donde el servicio de disparador es para suministrar el disparador, en donde el disparador es un elemento de señalización cuya función es para identificar la señalización y establecer el tiempo de automatización de los eventos interactivos dirigidos a las aplicaciones para un segmento descrito por una tabla de parámetro de aplicación, en donde el disparador es uno de un disparador de base de tiempo, un disparador de activación, un disparador de interacción o un disparador de cambio de canal, en donde el disparador de base de tiempo se use para establecer una base de tiempo para el evento, en donde el disparador de activación ajuste un tiempo de activación para el evento, en donde el disparador de interacción se use para los modelos de interacción diferentes al modelo de interacción de Objeto Declarativo Desencadenado, en donde el disparador de cambio de canal se suministra cuando sea que se cambie el canal.

2. El método de la reivindicación 1, el método caracterizado en que comprende además: recibir un mensaje de búsqueda para los dispositivos de búsqueda que incluyen el primer dispositivo que ofrece los servicios del segundo soporte de pantalla antes de enviar el mensaje de búsqueda.

3. El método de la reivindicación 1, caracterizado en que el servicio de disparador ofrece una opción de flujo no filtrada, y en donde la opción de flujo no filtrada es una opción que suministra todos los tipos del disparador.

4. El método de la reivindicación 3, caracterizado en que el primer tipo suministra todos los tipos de disparadores tan pronto como el disparador sea recibido por el primer dispositivo.

5. El método de la reivindicación 1, caracterizado en que el suministro del disparador incluye: combinar información del disparador de activación con la información de la tabla del parámetro de aplicación para generar un disparador de activación aumentado; y enviar el disparador de activación aumentado generado a la segunda aplicación de pantalla.

6. El método de la reivindicación 5, caracterizado en que el servicio del disparador ofrece una opción de flujo filtrado, y en donde la opción de flujo filtrado es una opción de suministrar el disparador el cual es uno del disparador de activación aumentado, el disparador de interacción o el disparador de cambio de canal.

7. El método de la reivindicación 6, caracterizado en que el disparador de activación aumentado incluya una información URL de aplicación que tiene el mismo valor con un elemento URL de un elemento de aplicación en la tabla del parámetro de aplicación, en donde el elemento URL identifique un archivo el cual es parte de la aplicación, y en donde el elemento de aplicación se identifique por el disparador de activación.

8. El método de la reivindicación 7, caracterizado en que el disparador de activación aumentado incluya además una información de evento representando un elemento de evento en la tabla del parámetro de aplicación, en donde el elemento de evento identificado por el disparador de activación representa el evento para la aplicación, en donde la información del evento incluya una información de acción teniendo el mismo valor con un atributo de acción del elemento de evento identificado por el disparador de activación, y en donde el atributo de acción indica el tiempo de una acción para que se aplique cuando se active el evento.

9. El método de la reivindicación 6, caracterizado en que el primer dispositivo suministra el disparador de activación aumentado en el momento de activación del disparador de activación aumentado, en donde el primer dispositivo suministra el disparador de interacción cuando se recibe el disparador de interacción por el primer dispositivo, y en donde el primer dispositivo entregue el disparador de cambio de canal cuando se cambie el canal.

10. Un método para procesar un servicio interactivo en una segunda aplicación de pantalla ejecutando en un segundo dispositivo, el método caracterizado en que comprende: recibir un mensaje de detección de un primer dispositivo, en donde el mensaje de detección anuncie los servicios del segundo soporte de pantalla que el primer dispositivo puede proporcionar; enviar una solicitud para las descripciones de los servicios del segundo soporte de pantalla al primer dispositivo; recibir una respuesta con las descripciones del primer dispositivo; ingresar un servicio del disparador usando la información dada en las descripciones; y recibir un disparador del primer dispositivo usando el servicio del disparador, en donde el servicio del disparador es uno de los servicios del segundo soporte de pantalla, en donde el disparador es un elemento de señalización cuya función es identificar la señalización y establecer el tiempo de transmisión de los eventos interactivos dirigidos a las aplicaciones para un segmento descrito por una tabla de parámetro de aplicación, en donde el disparador es de un disparador de base de tiempo, un disparador de activación, un disparador de interacción o un disparador de cambio de canal, en donde el disparador de base de tiempo se utiliza para establecer una base de tiempo para el evento, en donde el disparador de activación ajusta un tiempo de activación para el evento, en donde el disparador de interacción se utiliza para los modelos de interacción diferentes al modelo de interacción de Objeto Declarativo Disparado, en donde el disparador de cambio de canal se suministre cuando sea que cambie el canal.

11. El método de la reivindicación 10, el método además caracterizado en que comprende: multidifundir un mensaje de búsqueda para los dispositivos de búsqueda incluyendo el primer dispositivo que ofrece los servicios del segundo soporte de pantalla antes de recibir el mensaje de detección.

12. El método de la reivindicación 10, caracterizado en que el servicio del disparador ofrece una opción de flujo no filtrado, y en donde la opción de flujo no filtrado es una opción que suministre todos los tipos de disparador.

13. El método de la reivindicación 12, caracterizado en que todos los tipos del disparador se suministran tan pronto como sea posible.

14. El método de la reivindicación 10, caracterizado en que la recepción del disparador incluye: recibir un disparador de activación aumentado generado combinando la información del disparador de activación con la información de la tabla de parámetros de aplicación.

15. El método de la reivindicación 14, caracterizado en que el servicio del disparador ofrece una opción de flujo filtrada, y en donde la opción de flujo filtrada es una opción que suministre el disparador el cual es uno de los disparadores de activación aumentados, el disparador de interacción o el disparador de cambio de canal.

16. El método de la reivindicación 15, caracterizado en que el disparador de activación aumentado incluye una información URL de aplicación que tiene el mismo valor con un elemento URL de un elemento de aplicación en la tabla del parámetro de aplicación, en donde el elemento URL identifica un archivo el cual es parte de la aplicación, y en donde el elemento de aplicación se identifica por el disparador de activación.

17. El método de la reivindicación 16, caracterizado en que el disparador de activación aumentado incluye además una información de evento representando un elemento de evento en la tabla del parámetro de aplicación, en donde el elemento de evento identificado por el disparador de activación que representa el evento para la aplicación, en donde la información del evento incluye una información de acción teniendo el mismo valor con un atributo de acción del elemento de evento identificado por el disparador de activación, y en donde el atributo de acción indica el tipo de una acción para ser aplicada cuando se active el evento.

18. El método de la reivindicación 15, caracterizado en que el disparador de activación aumentado se suministra en el tiempo de activación del disparador de activación aumentado, en donde se suministre el disparador de interacción tan pronto como sea posible, y en donde el disparador de cambio de canal se suministre cuando se cambie el canal.

19. Un aparato para procesar un servicio interactivo como un primer dispositivo, el aparato caracterizado en que comprende: un primer módulo configurado para recibir un disparador de un flujo de difusión o un servidor de internet; y un segundo módulo configurado para enviar un mensaje de detección a una segunda aplicación de pantalla ejecutando en un segundo dispositivo, en donde el mensaje de detección anuncia servicios de segundo soporte de pantalla que el primer dispositivo puede proporcionar, recibir una solicitud para las descripciones de los servicios del segundo soporte de pantalla de la segunda aplicación de pantalla, enviar una respuesta con las descripciones a la segunda aplicación de pantalla, y suministrar al disparador el segundo dispositivo utilizando un servicio de disparador, en donde el servicio del disparador es uno de los servicios del segundo soporte de pantalla, en donde el servicio de disparador es para suministrar el disparador, en donde el disparador es un elemento de señalización cuya función es identificar la señalización y establecer el tiempo de reproducción de los eventos interactivos dirigidos a las aplicaciones para un segmento descrito por una tabla de parámetro de aplicación, en donde el disparador es uno de un disparador de base de tiempo, un disparador de activación, un disparador de interacción o un disparador de cambio de canal, en donde el disparador de base de tiempo se usa para establecer una base de tiempo para el evento, en donde el disparador de interacción se utiliza para los modelos de interacción diferentes al modelo de interacción de objeto Declarativo Disparado, en donde el disparador de cambio de canal se suministra siempre que se cambie el canal.

20. El aparato de la reivindicación 19, caracterizado en que el segundo módulo está configurado además para recibir un mensaje de búsqueda para los dispositivos de búsqueda incluyendo el primer dispositivo que ofrece los servicios del segundo soporte de pantalla enviando el mensaje de detección.

21. El aparato de la reivindicación 19, caracterizado en que el servicio del disparador ofrece una opción de flujo no filtrada, y en donde la opción de flujo no filtrada es una opción que suministra todos los tipos del disparador.

22. El aparato de la reivindicación 21, caracterizado en que el segundo módulo suministra todos los tipos del disparador tan pronto como se reciba el disparador por el primer módulo.

23. El aparato de la reivindicación 19, caracterizado en que el segundo módulo adicional configurado a combinar la información del disparador de activación con la información de la tabla del parámetro de aplicación para generar un disparador de activación aumentado; y enviar el disparador de activación aumentado a la segunda aplicación de la pantalla.

24. El aparato de la reivindicación 23, caracterizado en que el servicio de disparadores ofrece una opción de flujo filtrado, y en donde la opción de flujo filtrado es una opción que suministra el disparador el cual es un disparador de activación aumentado, el disparador de interacción o el disparador de cambio de canal.

25. El aparato de la reivindicación 24, caracterizado en que el disparador de activación aumentado incluye una información URL de aplicación que tiene el mismo valor de un elemento URL de un elemento de aplicación en la tabla del parámetro de aplicación, en donde el elemento URL identifica un archivo el cual es parte de la aplicación, y en donde el elemento de aplicación se identifica por el disparador de activación.

26. El aparato de la reivindicación 25, caracterizado en que el disparador de activación aumentado incluye además una información de evento representando un elemento de evento en la tabla del parámetro de aplicación, en donde el elemento de evento identificado por el disparador de activación representa el evento para la aplicación, en donde la información del evento incluye una información de acción teniendo el mismo valor con un atributo de acción del elemento del evento identificado por el disparador de activación, y en donde el atributo de acción indica el tipo de una acción para que se aplique cuando se active el evento.

27. El aparato de la reivindicación 24, caracterizado en que el segundo módulo suministra el disparador de activación aumentado en el tiempo de activación del disparador de activación aumentado, en donde el segundo módulo suministra el disparador de interacción cuando se recibe el disparador de interacción por el primer módulo, y en donde el segundo módulo suministra el disparador de cambio de canal cuando se cambia el canal.

28. Un aparato para procesar un servicio interactivo como una segunda aplicación de pantalla ejecutándose en un segundo dispositivo, el aparato caracterizado en que comprende: un primer módulo configurado para recibir un mensaje de detección de un primer dispositivo, en donde el mensaje de detección anuncie los servicios del segundo soporte de pantalla que el primer dispositivo puede proporcionar, enviar una solicitud para las descripciones de los servicios del segundo soporte de pantalla para el primer dispositivo, y recibir una respuesta con las descripciones del primer dispositivo; y un segundo módulo configurado para ingresar a un servicio del disparador utilizando la información dada en las descripciones, y recibir un disparador del primer dispositivo utilizando el servicio del disparador, en donde el servicio del disparador es uno de los servicios del segundo soporte de pantalla, en donde el disparador es un elemento de señalización cuya función es para identificar la señalización y establecer el tiempo de disponibilidad de los eventos interactivos dirigidos a las aplicaciones para un segmento descrito por una tabla del parámetro de aplicación, en donde el disparador es uno de un disparador de base de tiempo, un disparador de activación, un disparador de interacción o un disparador de cambio de canal, en donde el disparador de base de tiempo se utiliza para establecer una base de tiempo para el evento, en donde el disparador de activación ajusta un tiempo de activación para el evento, en donde el disparador de interacción se utiliza para los modelos de interacción diferentes al modelo de interacción de Objeto Declarativo Disparado, en donde el disparador de cambio de canal se suministra cada vez que se cambia un canal.

29. El aparato de la reivindicación 28, caracterizado en que el primer módulo adicional configurado para, multidifundir un mensaje de búsqueda para buscar dispositivos incluyendo el primer dispositivo que ofrece los servicios del segundo soporte de apoyo antes de recibir el mensaje de detección.

30. El aparato de la reivindicación 28, caracterizado en que el servicio del disparador ofrece una opción de flujo no filtrada, y en donde la opción de flujo no filtrada es una opción que suministra todos los tipos del disparador.

31. El aparato de la reivindicación 30, caracterizado en que todos los tipos del disparador se suministran tan pronto como sea posible.

32. El aparato de la reivindicación 28, caracterizado en que el segundo módulo adicional configurado para recibir un disparador de activación aumentado generado mediante la combinación de información del disparador de activación con la información de la tabla del parámetro de aplicación.

33. El aparato de la reivindicación 32, caracterizado en que el servicio del disparador ofrece una opción de flujo filtrada, y en donde la opción de flujo filtrada es una opción que ibera el disparador el cual es uno de los disparadores de activación aumentados, el disparador de interacción o el disparador de cambio de canal.

34. El aparato de la reivindicación 33, caracterizado en que el disparador de activación aumentado incluye una información URL de aplicación teniendo el mismo valor con un elemento URL de un elemento de aplicación en la tabla del parámetro de aplicación, en donde el elemento URL identifique un archivo el cual es parte de la aplicación, y en donde el elemento de aplicación se identifique por el disparador de aplicación.

35. El aparato de la reivindicación 34, caracterizado en que el disparador de activación aumentado incluye además una información de evento representando un elemento de evento en la tabla del parámetro de aplicación, en donde el elemento del evento identificado por el disparador de activación representa el evento para la aplicación, en donde la información de evento incluye una información de acción teniendo el mismo valor con un atributo de acción del elemento del evento identificado por el disparador de activación, y en donde el atributo de acción indica el tipo de una acción para que sea aplicado cuando se active el evento.

36. El aparato de la reivindicación 33, caracterizado en que el disparador de activación aumentado se suministra en el tiempo de activación del disparador de activación aumentado, en donde el disparador de interacción se suministra tan pronto como sea posible, y en donde el disparador de cambio de canal se suministra cuando se cambia el canal. RESUMEN DE LA INVENCIÓN Se describe un método de procesar un servicio interactivo y un aparato del mismo. La presente invención incluye enviar un mensaje de descubrimiento a una segunda aplicación de pantalla, recibir una solicitud para las descripciones de los servicios de soporte de la segunda pantalla, enviar una respuesta con las descripciones, recibir un disparador, y entregar el disparador al segundo dispositivo usando un servicio del disparador.