MX2015001908A - Aparato y metodo para procesar un servicio interactivo. - Google Patents

Aparato y metodo para procesar un servicio interactivo.

Info

Publication number
MX2015001908A
MX2015001908A MX2015001908A MX2015001908A MX2015001908A MX 2015001908 A MX2015001908 A MX 2015001908A MX 2015001908 A MX2015001908 A MX 2015001908A MX 2015001908 A MX2015001908 A MX 2015001908A MX 2015001908 A MX2015001908 A MX 2015001908A
Authority
MX
Mexico
Prior art keywords
activation
activator
time
event
receiver
Prior art date
Application number
MX2015001908A
Other languages
English (en)
Other versions
MX343885B (es
Inventor
Sejin Oh
Kyoungsoo Moon
Seungjoo An
Jinwon Lee
Jinpil Kim
Kyungho Kim
Original Assignee
Lg Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lg Electronics Inc filed Critical Lg Electronics Inc
Publication of MX2015001908A publication Critical patent/MX2015001908A/es
Publication of MX343885B publication Critical patent/MX343885B/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
    • H04N21/23892—Multiplex stream processing, e.g. multiplex stream encrypting involving embedding information at multiplex stream level, e.g. embedding a watermark at packet level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44008—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8358—Generation of protective data, e.g. certificates involving watermark
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Se describen un método para procesar un servicio interactivo y un aparato del mismo. La presente invención incluye recibir contenido de audio sin comprimir o contenido de video sin comprimir desde una unidad de descodificación externa, extraer identificadores de tramas desde el contenido recibido periódicamente, enviar solicitudes que contienen los identificadores y recibir un activador para el contenido cuando se detecta un nuevo segmento o cuando la activación de evento necesita comunicarse al receptor, en donde el activador indica el momento actual de los contenidos y referencia un evento interactivo particular en una tabla de parámetro de aplicación o señala que el evento va a ejecutarse ahora o en un momento futuro especificado, en donde la tabla de parámetro de aplicación incluye información acerca de al menos una de las aplicaciones.

Description

APARATO Y MÉTODO PARA PROCESAR UN SERVICIO INTERACTIVO Campo Téenico La presente invención se relaciona con un método y aparato para proporcionar, recibir y procesar un servicio de difusión, y más particularmente, con un método y aparato para proporcionar un servicio complementario relacionado con un contenido de difusión.
Técnica Antecedente Las televisiones aparecieron primero al final del siglo 19 y se han vuelto el aparato de distribución de información más popular desde el fin del siglo 20 como método de pantalla de visualización o diseño de la misma se ha desarrollado continuamente. Sin embargo, las televisiones generalmente permiten a los espectadores recibir información unidireccional desde una estación de difusión. Tales limitaciones de la televisión se han vuelto problemáticas ya que las computadoras personales (PC) y el Internet se han popularizado en uso desde los 90's. Por lo tanto, las televisiones se han desarrollado para ser capaces de proporcionar un servicio interactivo.
Sin embargo, actualmente, existe un sistema para proporcionar un servicio interactivo entre un proveedor de contenido y un espectador. En particular, para proporcionar tal servicio interactivo, existe una necesidad de un método para ejecutar una aplicación relacionada con la difusión de contenido, la cual se difunde actualmente, en un momento especifico y proporciona la información relacionada al espectador a través de procesamiento de información especial.
Descripción Problema Téenico Un objeto de la presente invención ideado para resolver el problema yace en la información complementaria relacionada con el contenido de difusión en un momento apropiado durante un periodo cuando el contenido de difusión se reproduce.
Solución Técnica El objeto de la presente invención puede lograrse al proporcionar un método para procesar un servicio interactivo en un receptor de acuerdo con la presente invención que incluye recibir contenido de audio sin comprimir o contenido de audio sin comprimir desde una unidad de descodificación externa, extraer identificadores o tramas desde el contenido recibido periódicamente, enviar solicitudes que contienen los identificadores y recibir un activador para contenido cuando se detecta un nuevo segmento o cuando una activación de evento necesita comunicarse al receptor, en donde el activador indica el tiempo actual del contenido y se refiere a un evento interactivo particular en una tabla de parámetro de aplicación o señala que el evento va a ejecutarse ahora o en un momento especifico en el futuro, en donde la tabla de parámetro de aplicación incluye información acerca de al menos una de las aplicaciones.
De preferencia, el activador es un activador basado en tiempo cuando el identificador corresponde al nuevo segmento, y el activador basado en tiempo se utiliza para permitir al receptor obtener una nueva tabla de parámetro de aplicación asociado con el nuevo segmento.
De preferencia, el activador es un activador de activación cuando el evento debe activarse, y el activador de activación establece una sincronización de activador para el evento.
De preferencia, el activador de activación se recibe por adelantado del momento cuando el receptor necesita aplicar el activador de activación.
De preferencia, el evento se activa inmediatamente tras recepción del activador de activación, cuando el activador de activación se recibe después del momento de activación De preferencia, el método además comprende descargar una nueva tabla de parámetro de aplicación inmediatamente, a menos de que el receptor haya recuperado la nueva tabla de parámetro de aplicación utilizando información de URL distribuida con la tabla de parámetro de aplicación, cuando el activador incluye un identificador de tabla de parámetro de aplicación el cual identifica la nueva tabla de parámetro de aplicación.
De preferencia, el activador de activación se aplica una vez, cuando el receptor recibe más de un activador de activación para la misma activación del evento.
De preferencia, el tiempo es un tiempo de medios, y el tiempo de medios es un parámetro que referencia un punto en la reproducción del elemento de contenido.
De preferencia, la aplicación es un Objeto Declarativo o Declarative Object, un Objeto Declarativo Activado o Triggered Declarative Object, un Objeto Declarativo en Tiempo no Real o Non-Real Time Declarative Object, o un Objeto Declarativo no Enlazado o Unbound Declarative Object.
En otro aspecto de la presente invención, se proporciona un aparato en la presente para procesar un servicio interactivo de acuerdo con la presente invención que incluye un módulo de recepción configurado para recibir contenido de audio sin comprimir o contenido de audio sin comprimir desde una unidad de descodificación externa, un módulo de extracción de identificador configurado para extraer identificadores o tramas desde el contenido recibido periódicamente, y una interfaz de red configurada para enviar solicitudes que contienen los identificadores y recibir un activador para contenido cuando se detecta un nuevo segmento o cuando una activación de evento necesita comunicarse al aparato, en donde el activador indica el tiempo actual del contenido y se refiere a un evento interactivo particular en una tabla de parámetro de aplicación o señala que el evento va a ejecutarse ahora o en un momento especifico en el futuro, en donde la tabla de parámetro de aplicación incluye información acerca de al menos una de las aplicaciones.
De preferencia, el activador es un activador basado en tiempo cuando el identificador corresponde al nuevo segmento, y el activador basado en tiempo se utiliza para permitir al aparato obtener una nueva tabla de parámetro de aplicación asociado con el nuevo segmento.
De preferencia, el activador es un activador de activación cuando el evento debe activarse, y el activador de activación establece un momento de activación para el evento.
De preferencia, el activador de activación se recibe por antes del momento en que el aparato necesita aplicar el activador de activación.
De preferencia, el evento se activa inmediatamente tras recepción del activador de activación, cuando el activador de activación se recibe después del momento de activación.
De preferencia, la interfaz de red además se configura para descargar una nueva tabla de parámetro de aplicación inmediatamente, a menos de que el aparato haya recuperado la nueva tabla de parámetro de aplicación utilizando información URL distribuida con la tabla de parámetro de aplicación, cuando el activador incluye un identificador de tabla de parámetro de aplicación el cual identifica la nueva tabla de parámetro de aplicación.
De preferencia, el activador de activación se aplica una vez, cuando el receptor recibe más de un activador de activación para la misma activación del evento.
De preferencia, el tiempo es un tiempo de medios, y el tiempo de medios es un parámetro que referencia un punto en la reproducción del elemento de contenido.
De preferencia, la aplicación es un Objeto Declarativo, un Objeto Declarativo Activado, un Objeto Declarativo en Tiempo no Real o un Objeto Declarativo no Enlazado.
Efectos Ventajosos De acuerdo con la presente invención, es posible proporcionar información complementaria relacionada con el contenido de difusión utilizando un sistema de difusión convencional.
De acuerdo con la presente invención, es posible detectar un momento en el que la información complementaria relacionada con el contenido de difusión necesita desplegarse y proporciona la información complementaria a un usuario en un momento apropiado.
De acuerdo con la presente invención, es posible proporcionar información complementaria relacionad con contenido de difusión para los receptores que tienen conexiones de Internet y que solamente tienen acceso a audio y video sin comprimir desde las transmisiones continuas de difusión.
Descripción de los Dibujos Los dibujos anexos, los cuales se incluyen para proporcionar un entendimiento adicional de la invención se incorporan en y constituyen una parte de esta aplicación, ilustrar modalidades de la invención y junto con la descripción sirven para explicar los principios de la invención. En los dibujos: La Figura 1 es un diagrama que muestra una modalidad de una corriente de difusión típica; la Figura 2 es un diagrama que muestra una modalidad de una sincronización de activador en caso de un contenido pre-producido; la Figura 3 es un diagrama que muestra una modalidad de una sincronización de activador en caso de un contenido en vivo; la Figura 4 es un diagrama que muestra una modalidad de una sintaxis activa; la Figura 5 es un diagrama que muestra una modalidad de una tabla de parámetro de TDO; la Figura 6 es un diagrama que muestra una modalidad de una tabla de parámetro de TDO; la Figura 7 es un diagrama que muestra el significado de los valores del atributo "Frequency of Use"; la Figura 8 es un diagrama que muestra el significado de los valores del atributo "destination"; la Figura 9 es un diagrama que muestra una modalidad de la sintaxis de la forma binaria de la Tabla de Parámetros de TDO; la Figura 10 es un diagrama que muestra una modalidad de la sintaxis de la forma binaria de la Tabla de Parámetros de TDO; la Figura 11 es un diagrama que muestra una modalidad de la sintaxis de la forma binaria de la Tabla de Parámetros de TDO; la Figura 12 es un diagrama que muestra una modalidad de la sintaxis de la forma binaria de la Tabla de Parámetros de TDO; la Figura 13 es un diagrama que muestra una modalidad de la sintaxis de la forma binaria de la Tabla de Parámetros de TDO; la Figura 14 es un diagrama que muestra una modalidad de una estructura de tabla de mensaje de activación r la Figura 15 es un diagrama que muestra una modalidad del diagrama estructural de Lista de URL; la Figura 16 es un diagrama que muestra una modalidad del formato binario para las secciones privadas que contienen las TPT; la Figura 17 es un diagrama que muestra una modalidad de una lista de URL codificadas como un documento XML; la Figura 18 es un diagrama que muestra una modalidad de addTriggerEventListener; la Figura 19 es un diagrama que muestra una modalidad para remover TriggerEventListener; la Figura 20 es un diagrama que muestra una modalidad de la definición del tipo EventListener; la Figura 21 es un diagrama que muestra una modalidad de la definición del tipo TriggerEvent; la Figura 22 es un diagrama que muestra una modalidad de una arquitectura para un procedimiento de WM; la Figura 23 es un diagrama que muestra una modalidad de una arquitectura para un procedimiento de FP; la Figura 24 es un diagrama que muestra una modalidad de una activación estática en un caso de solicitud/respuesta de ACR; la Figura 25 es un diagrama que muestra una modalidad de una activación estática en un caso de solicitud/respuesta de ACR; la Figura 26 es un diagrama que muestra una modalidad de una activación dinámica en un caso de solicitud/respuesta; la Figura 27 es un diagrama que muestra una modalidad de una activación dinámica en un caso de solicitud/respuesta; la Figura 28 es un diagrama que muestra una modalidad de arquitectura para activaciones de servidor de ACR; la Figura 29 es un diagrama que muestra una modalidad de Activadores de Activación en caso (b) y caso (a) sin EndTime; la Figura 30 es un diagrama que muestra una modalidad de activadores de activación en caso (b) y caso (a) sin EndTime; la Figura 31 es un diagrama que muestra una modalidad de activadores de activación en caso (a) con EndTime; la Figura 32 es un diagrama que muestra una modalidad de activadores de activación en caso (a) con EndTime; la Figura 33 es un diagrama que muestra una modalidad de activadores de activación para el caso (c); la Figura 34 es un diagrama que muestra una modalidad de activadores de activación para el caso (c); la Figura 35 es un diagrama que muestra una modalidad de Activadores de Activación dinámica distribuidos en el último minuto; la Figura 36 es un diagrama que muestra una modalidad de activadores de activación dinámica distribuidos en el último minuto; la Figura 37 es un diagrama de secuencia entre un cliente ACR y otros servidores en un caso de solicitud/respuesta; la Figura 38 es un diagrama de secuencia entre un cliente ACR y otros servidores en un caso de ACR dirigido por evento; la Figura 39 es un diagrama que muestra una modalidad de un método para procesar un servicio interactivo en un receptor en un modelo dirigido por evento. la FIGURA 40 es un diagrama que muestra la estructura de un receptor de acuerdo con una modalidad de la presente invención; la Figura 41 es un diagrama que muestra la estructura de un receptor de acuerdo con una modalidad de la presente invención en el caso en el que una caja de convertidor-descodificador recibe una difusión mediante una interfaz multimedia de alta definición (HDMI) o una interfaz externa. la Figura 42 es un diagrama que muestra una modalidad de un aparato para procesar un servicio interactivo en un modelo dirigido por evento.
Mejor Modo Aunque los términos utilizados en la presente invención se seleccionan desde términos generalmente conocidos y utilizados, los términos utilizados en la presente pueden variar dependiendo en intención o costumbres del operador en la téenica, aparición de una nueva tecnología, o similares Además, algunos de los términos mencionados en la descripción de la presente invención se han seleccionado por discreción del solicitante, significados detallados de los cuales se describen en las partes relevantes de la descripción presente. Además, se requiere que la presente invención se entienda, no simplemente por los términos utilizados reales sino por los significados que yacen dentro de cada término.
En la presente especificación, el término tiempo de medios se refiere a un parámetro que hace referencia a un punto en la reproducción de un elemento de contenido de audio/video o audio. ACR significa Reconocimiento automático de Contenido. AMT significa Tabla de Mensajes de Activación. API significa Interfaz de Programa de Aplicación DAE significa Ambiente de Aplicación Declarativa. DO significa Objeto Declarativo. FLUTE significa Archivo de Entrega Sobre Transporte Unidireccional. GPS significa Sistema de Posicionamiento Global. HTTP significa Protocolo de Transferencia de Hipertexto. IP significa Protocolo de Internet. IPTV significa Televisión de Protocolo de Internet, iTV Televisión Interactiva. MIME significa Tipo de Medio de Internet. NDO significa Objeto Declarativo de NRT. NRT significa Tiempo No Real. SMT significa Tabla de Mapa de Servicio. SSC significa Servicio de Canal de Señalización. TDO significa Objeto Declarativo Activado. TPT significa Tablas de Parámetros de TDO. UDO significa Objeto Declarativo no Enlazado. UPnP significa Plug and Play del Usuario. URI significa Identificador de Recurso Uniforme. URL significa Localizador de Recurso Uniforme. XML significa Lenguaje Marcador Extensible. TFT significa Tabla de Fragmento de Texto. Detalles de los mismos se describirán a continuación.
En esta especificación, DO, TDO, NDO, UDO, Link and Packaged App tienen los siguientes significados.
DO (Objeto Declarativo) puede ser una colección que constituye una aplicación interactiva. (Por ejemplo, HTML, JavaScript, CSS, XML y archivos multimedia) El término "Objeto Declarativo Activado" (TDO) se utiliza para designar un Objeto Declarativo que ha iniciado con un Activador en un servicio de datos adjuntos interactivos Activados, o un DO que ha iniciado por un Activador, y asi iterativamente.
El término "Objeto Declarativo de NRT" (NDO) se utiliza para designar un Objeto Declarativo que ha iniciado como parte de un servicio de NRT que no es un servicio de datos interactivos Activados.
El término "Objeto Declarativo Sin Limite" (UDO) se utiliza para designar un Objeto Declarativo que no se limita a un servicio, tal como Packaged App o un DO iniciado por un Link, o un DO que ha iniciado por un DO, y asi iterativamente.
El "Link" o "Enlace" es una URL proporcionada por el difusor que señala a un sitio web que proporciona información en linea o funcionalidad relacionada con la programación de TV o servicio de NRT.
La "Packaged App" o "Aplicación Empaquetada" es un Objeto Declarativo proporcionado por el difusor (DO) que proporciona información o funcionalidad que el difusor quiere ofrecer a los espectadores, y que se empaqueta en un solo archivo para que los espectadores lo descarguen e instalen.
Detalles de los mismos se describirán a continuación.
En esta especificación, un mensaje de tiempo base incluye un activador de tiempo base y un equivalente del mismo. Por consiguiente, el término "mensaje de tiempo base" o "time base message" puede utilizarse de manera intercambiable con el término "activador de tiempo base" o "time base trigger".
En esta especificación, un mensaje de activación incluye la información de distribución que provoca la activación, tal como un elemento de activación en una AMT y/o un activador de activación.
La Figura 1 es un diagrama que muestra una modalidad de una corriente de difusión típica; Una corriente de difusión típica incluye una secuencia de programas de TV. Cada programa de TV incluye un programa subyacente, el cual típicamente se divide en bloques separados por anuncios y/u otro material intersticial.
En la Figura 1, es Segmento del Programa A, Anuncio 1, Anuncio 2, Segmento del Programa B, etc. se incluyen de manera secuencial en la corriente. Los segmentos que configuran cada programa pueden denominarse como contenido del programa y Anuncios pueden denominarse como contenido intersticial.
Cada programa o pieza de materia intersticial puede o no tener un servicio de datos adjunto interactivo asociado con el mismo.
El término "segmento de servicio interactivo", o solamente "segmento", se utilizará en esa especificación para referirse a una porción de un servicio adjunto interactivo que se trata por un difusor como una unidad integrada. Un segmento de servicio interactivo es típicamente, pero no de forma necesaria, asociado con un solo programa o una sola pieza del material intersticial.
Para ejecutar tal servicio de datos adjunto interactivo, existen dos modelos: Modelo de ejecución directa y modelo de objeto declarativo activado (TDO).
En el modelo de ejecución directo, un objeto declarativo (DO) puede iniciarse automáticamente tan pronto como se selecciona el canal virtual. Puede comunicarse a través de la Internet con un servidor de cabecera para obtener instrucciones detalladas para proporcionar características interactivas creando visualizaciones en ubicaciones específicas de la pantalla, conduciendo sondeos, iniciando otros DO especializados, etc., todo sincronizado con el programa de audio-video.
En el modelo TDO, las señales pueden distribuirse en la corriente de difusión o mediante la Internet para iniciar los eventos de TDO, tal como el inicio de una TDO, terminando una TDO, o solicitar una tarea por un TDO. Estos eventos pueden iniciar los momentos específicos, típicamente sincronizados con el programa de audio-video. Cuando se inicia un TDO; puede proporcionar las características interactivas que está programado para proporcionar.
Un concepto básico detrás del modelo TDO es que los archivos que componen una TDO, y los archivos de datos a utilizarse por una TDO para tomar una acción, todos necesitan alguna cantidad de tiempo para distribuirse a un receptor, dado su tamaño. Mientras la experiencia del usuario de los elementos interactivos puede originarse antes de la difusión del contenido, ciertos comportamientos deben medirse cuidadosamente para coincidir con eventos en el programa mismo, por ejemplo, la ocurrencia de un segmento de anuncios comerciales.
El modelo TDO separa la distribución de objetos declarativos y datos asociados, guiones, texto y gráficos desde la señalización del tiempo específico de la reproducción de eventos interactivos.
El elemento que establece el tiempo de eventos interactivo es el activador.
La información acerca de los TDO utilizados en el segmento y los eventos de TDO asociados que se inician por los activadores se proporciona por una estructura de datos denominada "Tabla de Parámetros TDO" (TPT).
La Figura 2 es un diagrama que muestra una modalidad de una sincronización de activador en caso de contenido pre-producido; El activador es un elemento de señalización cuya función es identificar la señalización y establecer el tiempo de reproducción de eventos interactivos.
El activador incluye un activador por tiempo el cual sirve para indicar un tiempo de medios de un segmento relacionado con el servicio interactivo y un activador de activación el cual sirve para indicar el momento de ocurrencia de un evento de una aplicación relacionada con el servicio interactivo.
Los activadores pueden realizar diversas funciones de señalización relacionadas con el tiempo en apoyo a los servicios interactivos. Los activadores pueden ser multi-funcionales; dependiendo de su estructura, una instancia de Trigger o Activador particular puede realizar una o más de las siguientes funciones. 1. Señalar la ubicación de una TPT (accesible mediante una sesión de FLUTE en la transmisión continua de emisión, mediante un servidor de Internet, o ambos); 2. Indicar el contenido interactivo para un segmento de programa próximo disponible para pre-cargarse; 3. Indicar el Tiempo de Medios o Media Time actual del contenido de audio/video o solamente audio asociados. 4. Se hace referencia a un evento interactivo particular en una TPT y señal que el evento va a ejecutarse ahora o en un Tiempo de Medios futuro especifico; 5. Indicar que el acceso a un servidor de internet se extenderá aleatoriamente sobre un intervalo de tiempo especificado para evitar un pico en la demanda.
La Figura 2 ilustra Activadores distribuidos en asociación con dos segmentos de programación. En este ejemplo, ambos segmentos son "pre-producidos", lo que significa que el contenido no proviene de una difusión en vivo; elementos interactivos se han agregado en post producción.
Como se muestra, un tiempo corto antes de la ocurrencia del segmento 1 de programación, un Activador "pre cargado" puede distribuirse para permitir a los receptores una oportunidad de adquirir la TPT y el contenido interactivo asociado con el segmento 1 de programación. Si el Activador pre-cargado no se transmite, los receptores pueden esperar utilizar el primer Activador que vean dentro del segmento para adquirir el contenido.
Los Activadores pueden enviarse a través del segmento 1, como se muestra, para indicar el Tiempo de Medios actual (etiquetado "m" en la figura) relativa al segmento. La distribución periódica de Activadores de Tiempo de Medios o Media Time Triggers puede ser necesaria para permitir a los receptores que solo encuentran el canal para sincronizar y adquirir el contenido interactivo.
Justo antes del inicio del segmento 2, se envía un Activador de pre-carga para ese segmento próximo.
En el caso de contenido pre-producido (no en vivo), la TPT que el receptor puede adquirir después de procesar el primer Activador puede definir el tiempo de todos los elementos de la experiencia interactiva para ese segmento. Todo lo que se necesita para el receptor y TDO para producir los elementos interactivos puede ser del conocimiento del tiempo de medios; la TPT puede describir eventos interactivos relativos a Tiempo de Medios.
La Figura 3 es un diagrama que muestra una modalidad de sincronización de activador en caso de contenido en vivo; Para el caso de contenido en vivo, la TPT todavía contiene datos e información pertinente a diferentes eventos interactivos, sin embargo, el tiempo de producción para estos eventos puede no conocerse hasta que la acción en el programa se despliega durante la difusión. Para el caso en vivo, se utiliza la función "temporización de evento" o "event timing" del Activador. En este modo, el Activador puede señalar que un evento interactivo especificado va a re-temporizarse a un nuevo valor específico del Tiempo de Medios. Alternativamente, el Activador puede indicar que un cierto evento va a ejecutarse inmediatamente.
En la Figura 3, las funciones de los activadores del segmento 3 se describirán.
Un primer activador es un activador de pre-carga, el cual se refiere a un directorio capaz de los archivos del segmento 3.
Un segundo activador es un activador de medios el cual se utiliza para indicar un tiempo de medios de reproducción del segmento 3.
Un tercer activador es un activador de re-temporización de evento que indica que el evento con eventID = 2 en la TPT va a re-temporizarse para ocurrir en Tiempo de Medios 240. El área entramada indica el intervalo de tiempo previo a 240 sobre el cual el Activador #3 puede distribuirse a los receptores.
Un cuarto activador es un activador de tiempo de medios.
Un quinto activador es un activador de re-temporización de evento que indica que el evento con eventID = 5 en la TPT va a re-temporizarse para ocurrir en Tiempo de Medios 444.
Un sexto y séptimo activadores son activadores de tiempo de medios.
Un octavo activador es un Activador de evento e indica que el evento con eventID = 12 en la TPT va a ejecutarse inmediatamente.
Un noveno activador es un Activador de re-temporización de evento que indica que el evento con eventID = 89 en la TPT va a re-temporizarse para ocurrir en Tiempo de Medios 900.
En lo sucesivo, se describirá el ciclo de vida, estado y evento de cambio de estado de la TDO.
Una TDO puede existir en cuatro diferentes estados: Liberado Released, Disponible o Ready, Activo o Active y Suspendido o Suspended. Un número de factores diferentes puede provocar una transición de un estado a otro (activador, acción del usuario, canales cambiantes, etc.).
La TDO puede incluir los siguientes cuatro estados. Los cuatro estados son Disponible, Activo, Suspendido y Liberado. El estado Disponible significa que la TDO se descargó y está preparado para la ejecución, pero todavía no se ejecuta. El estado Activo significa que la TDO se está ejecutando. El estado Suspendido significa que la TDO se suspende temporalmente de la ejecución, con su estado guardado. El estado Liberado significa que TDO no está Disponible, Activo o Suspendido.
Los siguientes son algunos de los eventos que pueden provocar un cambio en el estado de una TDO: 1. Activador ¿"preparar"? o ¿"prepare"? El dispositivo recibe un activador (en el canal virtual primario seleccionado actualmente) que solicita que TDO se prepare para ejecutarse (asignar recursos, cargar en la memoria principal, etc.). 2. Activador ¿"ejecutar"? o ¿"execute"? Los dispositivos reciben un activador (en el canal virtual primario seleccionado actualmente) el cual solicita que se active una TDO: 3. Activador ¿"suspender"? o ¿"suspend"? Los dispositivos reciben un activador (en el canal virtual primario seleccionado actualmente) que indica que el TDO a suspenderse 4. Activador ¿"terminar"? o ¿"kill"? Los dispositivos reciben un activador (en el canal virtual primario seleccionado actualmente) que indica que el TDO a terminarse La Figura 4 es un diagrama que muestra una modalidad de la sintaxis activa; Tanto los mensajes Activación o Activation como los mensajes Tiempo Base o Time Base pueden tener un formato de "Activador" general bajo ciertas circunstancias de distribución.
La definición sintáctica aquí se describe utilizando una gramática de Formulario Ampliado de Backus-Naur (ABNF), excepto en que el símbolo barra vertical "| " se utiliza para designar alternativas. Las reglas se separan de las definiciones por un igual "=", la sangría se utiliza para continuar una definición de regla sobre más de una linea, los literales se citan con paréntesis "("and")" se utilizan para agrupar elementos, elementos opcionales se encierran en "[" and "]" corchetes, y elementos pueden precederse con <n>* para designar n o más repeticiones del siguiente elemento; n es predeterminado a 0. Y los elementos pueden precederse con <n>*<m> designando n o más repeticiones y m o menos repeticiones del siguiente elemento.
Esta sintaxis del Activador se basa en el Identificador de Recurso Uniforme (URI): Sintaxis Genérica, que excluye el <esquema> y la porción con restricciones adicionales.
El activador puede incluir locator_part y términos. Los términos pueden omitirse. Si los términos están presentes, locator_part y términos pueden conectarse por '?'.
El locator_part puede incluir una parte de nombre del host y una parte de path_segments, la cual puede conectarse por '/'.
El nombre de servidor puede incluir domainlabel y toplabel, y domainlabel puede repetir 0 veces o más junto con '.'. Es decir, el nombre de servidor puede incluir domainlabel repetido conectado con toplabel o incluir solamente toplabel. domainlabel puede incluir un alfanumérico o incluir alfanumérico o insertados repetidamente entre alfanuméricos y alfanuméricos 0 veces o más.
Aquí, alfanumérico puede significar letra o dígito.
Aquí, letras puede ser una minúscula o mayúscula. Aquí, minúsculas puede ser alguna de a, b, c, d, e, b *3 r h, i, j, k, 1, m, n, o, p, q, r, s, t, u, v, w, x, y, y z.
Aquí, mayúsculas pueden ser alguna 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 O, 1, 2, 3, 4, 5, 6, 7, 8, y 9. toplabel incluye una letra o incluye alfanuméricos o insertados repetidamente entre letras y alfanuméricos 0 veces o más. path_segments incluye un segmento, el cual se sigue por el segmento repetido 0 veces o más. En este momento, los segmentos pueden conectarse por '/'.
Aquí, el segmento incluye alfanuméricos los cuales se repiten una vez o más.
Los términos pueden incluir uno de event_time o media_time, los cuales pueden seguirse por spread u otros. Spread y otros pueden omitirse. Si spread y otros están presentes, pueden colocarse antes de spread y otros y spread y otros pueden colocarse después de event_time o media_time.
Aquí, spread puede incluir dígitos repetidos una vez o más después de 's='.
Event_time puede incluir dígitos repetidos una vez o más después de 'e=' o incluir dígitos hexadecimales repetidos una vez o más o siete veces o menos de '&t=' '&t=' y la parte anterior del mismo pueden omitirse.
Aquí, dígitos hexadecimales pueden ser uno de 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e y f.
Media_time también puede incluir hexadecimales repetidos una vez o más o menos de siete veces después de 'm= ' .
Otros pueden incluir "other" u "other" seguido por y "other".
Aquí, other puede incluir resv_cmd y alfanuméricos los cuales se repiten una vez o más y se conectan por Aquí, resv_cmd puede ser un alfanumérico que excluye 'c ', 'e ', ? ', 'm', ' ', 's', 'S', 't ' y 'T '.
La longitud del activador puede no exceder 52 bytes. Además, la porción del nombre de servidor del Activador puede ser un nombre de dominio de Internet registrado.
Un Activador puede considerarse que incluye en otras partes. <domain ñame part> / <directory path> [? <parameters>] La <domain ñame part> puede ser un nombre de dominio registrado, <directory path> puede ser una trayectoria como aparecería en una URI.
La <domain ñame part> puede hacer referencia a un nombre de dominio de Internet registrado. La <directory path> puede ser una cadena de características arbitrarias que identifican una trayectoria bajo control y gestión de la entidad que tiene los derechos del nombre de dominio identificado.
En el modelo TDO, la combinación de <domain ñame part> y <directory path> puede identificar únicamente una TPT que puede procesarse por un receptor para agregar interactividad al contenido asociado.
La combinación de <domain ñame part> y <directory path> puede ser la URL de una ubicación de Internet donde la TPT para el segmento actual puede obtenerse.
Es decir, el activador puede identificar la TPT utilizando <domain ñame part> y <directory path>. A través de <domain ñame part> y <directory path>, es posible confirmar la TPT a la que se aplica el activador. El rol desempeñado al aplicar el activador a la TPT depende de <parameters>.
En lo sucesivo, <parameters> se describirá. <parameters> puede incluir uno o más de "event_time", "media_time", o "spread" A continuación, "event_time", "media_time" y "spread" de la sintaxis mostrada en la Figura 4 se describirán event_time = "e=" l*digito ["&t=" l*7hexadecimal] media_time = "m=" l*7hexadecimal spread = "s=" l*digito El término "event_time" puede utilizarse en un activador de Activación o Activation para identificar el evento objetivo ("e="término) y el tiempo que el evento debería activarse (término "t="). Cuando el término "t=" está ausente, significa que el evento debería activarse al momento en que el activador llegue.
Es decir, "e=", el cual es un término de ID de evento interactivo, puede hacer referencia al appID en la TPT asociada de la TDO destinada por el evento, el eventID del evento específico y el dataID del elemento Datos o Data a utilizarse por esta activación de evento. "t=" el cual es un término de valor de temporización opcional, puede indicar un nuevo tiempo de medios para el evento designado. Si la parte "t=" no está presente, esto puede significar que la temporización para el evento designado es el tiempo de llegada del Activador.
El término "media__time" (término "m=") puede utilizarse en un activador de tiempo base para identificar el tiempo actual en relación al tiempo base representado por el activador de Tiempo base o Time base. La información de identificador de contenido (término "c=") para identificar contenido mostrado actualmente además puede incluirse en media_time. Para el término "c=", el modelo de ejecución directo se describirá a continuación.
Es decir, "m=" el cual es el término de la marca de tiempo de medios, seguido por una cadena de caracteres de 1 a 8 caracteres de longitud que representa un número hexadecimal, puede indicar un Tiempo de Medios actual.
El término "spread" puede utilizarse para indicar que cualquier acción tomada en respuesta a un activador de Tiempo base(tal como recuperar una TPT de un servidor) o un activador de Activación (tal como provocar que una TDO acceda a un servidor) deberá demorarse una cantidad aleatoria de tiempo, para distribuir la carga de trabajo en el servidor. el término "s=" puede indicar un número de segundos de tiempo sobre los cuales todos los receptores deberán intentar acceder al servidor de Internet identificado en el Activador. Cada receptor individual puede esperarse a derivar un tiempo aleatorio dentro del intervalo designado y demorar la solicitud de acceso por esta cantidad, por lo que extiende en el tiempo el pico de la demanda que podría ocurrir de otra forma en la primera aparición de un Activador en el receptor.
Un Activador que contiene un parámetro <media time> puede denominarse un activador de Tiempo base, debido a que se utiliza para establecer un tiempo base para los tiempos del evento.
Un Activador que contiene un parámetro de <event time> puede denominarse un Activador de Activación o Activation Trigger, debido a que establece un tiempo de activación por un evento.
La Figura 5 y la Figura 6 son diagramas que muestra una modalidad de una tabla de parámetro de TDO; Una Tabla de Parámetros de TDO (TPT) que contiene metadatos acerca del TDOs de un segmento y los Eventos o Events destinados a ellos.
En lo sucesivo, los campos incluidos en la tabla se describirán. Los tamaños de los campos y los tipos de los campos incluidos en la tabla pueden agregarse o cambiarse de acuerdo con la intención del diseñador.
Las semánticas detalladas de los campos en la estructura de la TPT es la siguiente.
Tabla de parámetros de TDO (TPT) puede incluir los atributos a @ma orProtocolVersion, @minorProtocolVersion, @id, @tptVersion, @expireDate, @updatingTime, @serviceID, @baseURL, Capabilities, LiveTrigger, y/o el elemento TDO.
TPT es el elemento raíz de la TPT. Un elemento TPT describe todo o una porción (en el tiempo) de un segmento de programación.
MajorProtocolVersion el cual puede ser un atributo de 4 bits puede indicar el número de versión principal de la definición de la tabla. El número de versión principal puede establecerse en 1. Se espera que los receptores descarten las instancias de la TPT que indican los valores de versión principal que no se equipan para soporte.
Cuando se encuentra presente, @MinorProtocolVersion la cual puede ser un atributo de 4 bits puede indicar un número de versión menor de la definición de tabla. Cuando no está presente, el valor se predetermina a 0. El número de versión menor puede establecerse en 0. Se espera que los receptores no descarten las instancias de la TPT que indica los valores de versión menor que no se equipan para soporte. En este caso se espera que ignoren cualesquier elementos o atributos individuales que no soportan. @id, el cual es URI, puede identificar únicamente el segmento de programación interactivo al que este elemento de TPT pertenece. @id sirve como un identificador de un segmento. Por consiguiente, después de que un receptor analice la TPT, un activador, un AMT, etc. relacionado con un segmento puede coincidir con la TPT que tiene el @id para identificar el segmento que utiliza la información de @id. Por consiguiente, un segmento al que el activador y el AMT aplicará puede encontrarse. Los detalles de la AMT se describirán a continuación. @tptVersion, el cual puede ser un entero de 8 bits, puede indicar el número de versión del elemento de la TPT identificado por el atributo id. La tptVersion puede aumentarse cuando se hace cualquier cambio a la TPT.
Cuando se encuentra presente, el atributo @expireDate del elemento de la TPT puede indicar la fecha y hora de expiración de la información incluida en esta instancia de TPT. Si el receptor almacena memoria caché en la TPT, puede reutilizarse hasta expireDate.
Cuando se encuentra presente, @updatingTime puede ser un elemento de 16 bits que puede indicar que la TPT se somete a revisión, y dará el intervalo recomendado en segundos para descargar la TPT de nuevo y revisar si la TPT es cargada recientemente es una versión nueva.
Cuando está presente, @serviceID puede ser una entrada de 16 bits puede indicar un service_id asociado con el servicio interactivo descrito en esta instancia de TPT. Esto es necesario para que los receptores obtengan los parámetros de FLUTE desde la Tabla del Mapa de Servicio o Service Map Table cuando los archivos para este servicio interactivo se distribuyen en las transmisiones continuas de difusión.
Cuando se encuentra presente, el atributo @baseURL puede dar una base URL que, cuando se concatena al frente de cualesquiera de los URL relativos que aparecen en esta TPT. Puede dar los URL absolutos de los archivos Cuando se encuentra presente, el elemento Capabilities para indicar las capacidades que son esenciales para una presentación significativa del servicio interactivo asociado con la TPT. Los receptores que no tienen uno o más de las capacidades requeridas se espera no intenten presentar el servicio.
El elemento LiveTrigger se presenta sólo si la distribución de Activadores de Activación mediante la Internet se encuentra disponible. Cuando está presente, puede proporcionar información necesaria por un receptor para obtener los Activadores de Activación. El elemento secundario del atributo de LiveTrigger se describirá a continuación.
TDO el cual es un elemento secundario del elemento TPT puede representar una aplicación (por ejemplo, comando TDO), que proporciona parte del servicio interactivo durante el seguimiento descrito por esta instancia de TPT. El elemento secundario y el atributo del TDO se describirán a continuación.
El elemento LiveTrigger puede incluir el atributo @URL y/o @pollPeriod.
Como se describe en lo anterior, el elemento LiveTrigger se presenta solo si la distribución de Activadores de Activación mediante Internet se encuentra disponible. Cuando está presente, puede proporcionar información necesaria por un receptor para obtener los Activadores de Activación.
@URL, que es un atributo del elemento LiveTrigger, puede indicar la muestra URL de un servidor que puede distribuir Activadores de Activación mediante el Internet.
Los Activadores de Activación pueden distribuirse mediante el Internet utilizando el sondeo corto de HTTP, sondeo largo de HTTP, o transmisión continua de HTTP, en la opción del proveedor de servicio interactivo.
Cuando está presente, @pollPeriod, el cual es un atributo del elemento LiveTrigger, puede indicar que está utilizándose el sondeo corto para distribuir Activadores de Activación, y el valor del atributo pollPeriod puede indicar el tiempo recomendado en segundos para que el receptor utilice como un periodo de sondeo.
Si el elemento LiveTrigger se encuentra presente, el receptor puede analizar las TPT y obtener información utilizada para distribuir el activador de activación utilizando el Internet. El URL del servidor que puede recibir el activador de activación puede utilizarse utilizando información de ©URL. A través de la información de @pollPeriod o la información que indica que el atributo @pollPeriod no está presente, un método de distribución del activador de activación pueden obtenerse mediante el Internet y la información acerca del periodo de sondeo. @destination, se describirá a detalle a continuación.
El elemento TDO puede incluir los atributos @appID, @appType, @appName, @globalID, @appVersion, @cookieSpace, @f requencyOfUse, @expireDate, @testTD0, @availlnternet, @availBroadcast, URL, Capabilities, Contentitem, y/o el elemento Event.
Como se describe en lo anterior, TDO el cual es un elemento secundario del elemento TPT puede representar una aplicación (por ejemplo, una TDO), que proporciona parte del servicio interactivo durante el seguimiento descrito por esta instancia de TPT. @appID, el cual puede ser un entero de 16 bit, puede identificar la aplicación de forma única dentro del alcance de las TPT.
Un Activador de Activación identifica la aplicación objetivo para el Activador por medio de una referencia al appID. @appID es un identificador de una aplicación. Una TPT puede incluir diversas aplicaciones (tal como TDO). Por consiguiente, después de analizar TPT, la aplicación puede identificarse utilizando información de @appID. El activador, AMT, etc., como se aplicará a una solicitud puede coincidir con una solicitud que tiene @appID para identificar la aplicación. Por consiguiente, la aplicación a la que el activador AMT aplicará puede encontrarse. La AMT se describirá a detalle a continuación. @appType, el cual puede ser un entero de 8 bit como puede indicar en el tipo de formato de la aplicación. El valor predeterminado puede ser 1, el cual puede representar un TDO. Otros valores pueden representar otros formatos. @appName, el cual es un atributo del elemento TDO, el cual puede ser un nombre elegible por humano que puede desplegarse a un espectador cuando se busca el permiso de un espectador para iniciar la aplicación. @appName, el cual es un atributo del elemento TDO, puede ser un identificador único globalmente de la aplicación. En muchos casos, un receptor almacenará en la memoria cache una aplicación que podrá utilizarse de nuevo antes de tiempo. Para que esto sea útil, el receptor debe ser capaz de reconocer una aplicación la siguiente vez que aparezca. El globalID se necesita para que el receptor sea capaz de reconocer la aplicación cuando aparezca de nuevo en un nuevo segmento. @appVersion, el cual es un atributo del elemento TDO, puede ser una versión de aplicación. El valor de appVersion puede aumentar cuando la aplicación (se identifica por el globalID) cambia. El atributo appVersion puede no estar presente si el atributo globalID no está presente. @cookieSpace, el cual puede ser un entero de 8-bit, puede indicar cuanto espacio necesita la aplicación para almacenar datos persistentes entre invocaciones. @frequencyOfUse, el cual puede ser un entero de 4-bit, puede indicar aproximadamente que tan frecuente se utilizará la aplicación en la difusión, para proporcionar guia para receptores para manejar su espacio de almacenamiento en cache de código de aplicación. '@frequencyOfUse' se describirá a detalle a continuación. @expireDate, el cual es un atributo del elemento TDO, que puede indicar una fecha y horas después de la que el receptor puede eliminar la forma segura de aplicación y puede cambiar cualesquier cursos relacionados.
Cuando se encuentra presente con el valor "true", @testTDO, el cual es un atributo Booleano o Boolean puede indicar que la aplicación es solamente para propósito de prueba, y que puede ignorarse por los receptores ordinarios.
El valor "true" para el tributo Savaillnternet puede indicar que la aplicación se encuentra disponible para descarga a través del Internet. El valor "false" puede indicar que la aplicación no está disponible para descargar a través del Internet. Cuando el atributo no está presente, el valor predeterminado puede ser "true".
El valor "true" el atributo @availBroadcast puede indicar que la aplicación está disponible para la extracción desde la difusión. El valor "false" puede indicar que la aplicación no está disponible por la extensión desde la difusión. Cuando el atributo no está presente, el valor predeterminado puede ser "true".
Cada instancia de URL, un elemento secundario del elemento TDO puede identificar un archivo que es parte de una nueva solicitud. El elemento URL puede incluir el atributo @entry. @entry un atributo para el elemento URL, tiene un valor "true" que puede indicar que URL es un punto de entrada para la aplicación? es decir, un archivo que puede iniciarse para iniciar la aplicación. Cuando tiene el valor "false", se puede indicar que URL no es un punto de entrada para la aplicación. El valor predeterminado cuando el atributo no aparece puede ser "false". El URL el cual es el elemento secundario del elemento TDO identifica un archivo que configura la aplicación como se describe en lo anterior. El receptor analiza las muestras TPT para obtener información URL. Accede al servidor utilizando la información URL, y descarga una aplicación indicada por la información de URL.
Cuando se encuentra presente, Capabilities, el cual es un elemento secundario del elemento TDO, puede indicar las 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 no intenten presentar un inicio de la aplicación.
Contentltem, un elemento secundario del elemento TDO, puede indicar un elemento de contenido que incluye uno o más archivos de datos que se necesitan para la aplicación. El elemento Contentltem tiene información acerca de los archivos de datos requeridos por una aplicación indicada por el elemento TDO al que pertenece este elemento. El receptor puede descargar archivos de datos requeridos por la aplicación utilizando información URL, etcétera de Contentltem, el elemento Contentltem se encuentra presente después de análisis. El elemento secundario del atributo de Contentltem se describirá a continuación.
Event, un elemento secundario del elemento TDO puede representar un evento para la aplicación. El elemento Event indica un evento de una aplicación real que este elemento pertenece. El elemento event contiene información que indica si se encuentran presentes eventos, que datos están presentes, que acción está presente, etcétera. El receptor puede necesitar el elemento de evento para obtener información acerca del evento de la aplicación. El elemento secundario y atributo del evento se describirá a continuación.
El receptor puede recibir y analizar la TPT para obtener el elemento secundario del TDO y la información acerca de los atributos.
El elemento de Contentltem el cual es un elemento secundario del elemento TDO puede incluir los atributos @updateAvail, @pollPeriod, @size, @availlnternet, @availBroadcast y/o el elemento URL.
Aquí, el elemento URL puede incluir el atributo @entry. Cada instancia de URL, un elemento secundario del elemento Contentltem, puede identificar un archivo que es parte del artículo de contenido. El elemento URL puede incluir atributo @entry. @entry, un atributo del elemento URL, tiene valor de "true", que puede indicar que la URL es un punto de entrada para el articulo de contenido es decir, un archivo que puede iniciarse para iniciar el articulo de contenido ? Cuando tiene el valor "false", se puede indicar que URL no es un punto de entrada para el articulo de contenido. El valor predeterminado cuando el atributo no aparece puede ser "false". El receptor puede descargar archivos de datos requeridos por la aplicación utilizando información URL de Contentltem después del análisis. En este proceso, la información tal vez como otros atributos descritos en lo anterior pueden utilizarse. (üupdatesAvail, el cual es un atributo booleano del elemento de Contentltem, puede indicar si el articulo de contenido se actualizará de vez en vez o no. es decir si el articulo de contenido incluye archivos estáticos o si es una limitación de datos en tiempo real. Cuando el valor es "true", el articulo de contenido se actualizará de vez en vez; cuando el valor es "false" el articulo de contenido no se actualizará. El valor predeterminado cuando este atributo no aparece puede ser "false". @pollPeriod, el cual es un atributo del elemento de Contentltem, puede estar presente solamente cuando el valor updatesAvail es "true". La presencia del atributo pollPeriod puede indicar el sondeo corto que se utiliza para distribuir Activadores de Activación, y el valor del atributo pollPeriod puede indicar el tiempo recomendado en segundos para que el receptor lo utilice como un periodo de sondeo.
@Size, el cual es un atributo del elemento de Contentltem puede indicar el tamaño del articulo de contenido.
El valor "true" para el atributo @availlnternet puede indicar que en el articulo de contenido se encuentra disponible para su descarga a través del Internet. El valor "false" puede indicar que el articulo de contendido no está disponible para su descarga a través del Internet. Cuando este atributo no está presente, el valor predeterminado puede ser "true".
El valor "true" para el atributo @availBroadcast puede indicar que el articulo de contenido se encuentra disponible para su extracción desde la difusión. El valor "false" puede indicar que el articulo de contenido no se encuentra disponible para su extracción desde la difusión. Cuando este atributo no está presente, el valor predeterminado puede ser "true".
El elemento de evento contiene información acerca del evento de la aplicación indicada por el elemento TDO al que el elemento de evento pertenece. El receptor puede analizar en elemento de evento para obtener información acerca del evento.
El elemento de evento el cual es un elemento secundario del elemento TDO puede incluir los atributos @eventID, @action, @destination, @diffusion y/o el elemento de datos. Aquí, el elemento de datos puede incluir el atributo @dataID. @eventlD, el cual puede ser un atributo entero de 16 bit del elemento Event como pueden identificar el evento únicamente dentro del alcance del elemento TDO que lo contiene. Un Activador de Activación (o un elemento de activación en AMT) puede identificar la aplicación objetivo y evento por el Activador por la combinación de appID y eventID. Cuando el evento se activa, los receptores pasan el evento a la aplicación. @eventID sirve como un identificador de un evento. Utilizando información de @eventID, un activador, AMT, etc. para activar el evento puede coincidir una aplicación que tiene @eventID para identificar el evento. Es decir, un Activador de Activación (o elemento de activación en AMT) puede identificar la aplicación objetivo y evento por el Activador por la combinación de appID y eventID. Cuando el evento se activa, los receptores pasan el evento a la aplicación. La AMT se describirá a detalle a continuación. @action, el cual es un atributo del elemento Event, puede indicar el tipo de acción a aplicarse cuando el evento se activa. Los valores permitidos pueden ser "prep", "exec", susp", y "kill". "prep" puede corresponder a la acción "Trig prep". Si el estado de la aplicación seleccionada es "Released, " esta acción puede provocar un cambio de estado en "Ready." "exec" puede corresponder a la acción "Trig exec". El estado de la aplicación seleccionada puede volverse "Active" tras la recepción de este activador. "susp" puede corresponder a la acción "Trig susp". Si el estado de la aplicación es "Active," el estado puede cambiar a "Suspended" tras la recepción de este activador, de otra forma no hay cambio. "kill" puede corresponder a la acción "Trig kill". El estado de la aplicación seleccionada puede volverse "Released" tras la recepción de este activador. @action, puede indicar el tipo de acción a aplicarse cuando el evento se activa. @destination, el cual es un atributo del elemento Event, puede indicar el dispositivo objetivo para el evento. @destination se describirá en detalle en lo siguiente.
Cuando se encuentra presente, @diffusion, el cual puede ser un atributo entero de 8 bits de un elemento Evento, puede representar un periodo T de tiempo en segundos. El propósito del parámetro de difusión es uniformar picos en la carga del servidor. El receptor puede esperarse a calcular un tiempo aleatorio en el margen de 0-T, en aumento de 10 milisegundos, y demorar esta cantidad antes de acceder a un servidor de Internet para recuperar contenido referenciado por las URL en la TPT.
Cuando se encuentra presente, Datos el cual es un elemento secundario del elemento Evento puede proporcionar datos relacionados con el evento. Diferentes activaciones del Evento pueden tener diferentes elementos Data asociados con ellos. El elemento data puede incluir el atributo @dataID. @dataID, el cual es un atributo entero de 16 bits, puede identificar al elemento Data únicamente dentro del alcance del elemento Evento que lo contiene. Cuando una activación de un evento tiene los datos asociados con éste, el Activador de Activación puede identificar el elemento Data por la combinación de AppID, EventID, y DatalD. El elemento data indica datos utilizados para el evento. Un elemento event puede tener diversos elementos de datos. Datos se identifica utilizando el atributo @dataID del eleménto de datos. En el receptor, si el evento relacionado con los datos se activa, el Activador de Activación (o elemento de activación en AMT) puede identificar el elemento Datos por la combinación de AppID, EventID, y DatalD. AMT se describirá a detalle a continuación. la Figura 7 es un diagrama que muestra el significado de los valores del atributo "Frequency of Use".
La columna "Meaning" indica la frecuencia de ocurrencia de los segmentos que contienen esta aplicación. (Un atributo puede aparecer múltiples veces dentro de un solo segmento, desde luego). El atributo frequencyOfUse no puede presentarse si el atributo globalID no está presente. Si la aplicación va a aumentar la memoria caché y utilizarse de nuevo después, el receptor necesita reconocer que es la misma aplicación cuando aparece de nuevo. Esto requiere el atributo globalID. la Figura 8 es un diagrama que muestra el significado de los valores del atributo "destino" o "destination".
Como se muestra en la Figura 8, el valor del atributo destination de 0 indica "reserved" o "reservado", el valor del atributo destination de 1 indica solamente el dispositivo primario, el valor del atributo destination de 2 indica solamente uno o más dispositivos secundarios 2, y el valor del atributo destination de 3 indica el dispositivo Primario y uno o más dispositivos secundarios. la Figura 9, Figura 10, Figura 11, Figura 12 y Figura 13 son diagramas que muestran una modalidad de la sintaxis de la forma binaria de la Tabla de Parámetros de TDO; Este es el formato binario de la estructura TPT descrita en lo anterior. Esta estructura es un formato necesario cuando la TPT se transmite en NRT y se hace de manera que la estructura XML dela TPT se transmite en forma adecuada en NRT.
Los siguientes elementos y/o atributos contenidos en la versión XML de la TPT pueden omitirse de la versión binaria, debido a que pueden proporcionarse por el encabezado de encapsulación para la distribución de la tabla binaria en la corriente de difusión: @ProtocolVersion (mayor/menor), @serviceID y/o @tptVersion.
Las semánticas de los campos son los siguientes. Los campos en el formato binario de la tabla de parámetros de TDO de la Figura 9, Figura 10, Figura 11, Figura 12 y Figura 13 se describirán secuencialmente. expire_date_included, el cual puede ser un campo de 1 bit, puede indicar si el campo de expire_date está incluido.
El valor ? ' puede significar que se incluye; el valor '0' puede significar que no se incluye. segment_id_length, el cual puede ser un campo de 5 bits, puede indicar la longitud en bytes del campo segment_id. segment_id, el cual es un campo de longitud variable, puede contener los bytes id del segmento, los cuales pueden tener la misma semántica que el atributo "id" del formato TPT XML. base_URL_length, el cual puede ser un campo de 8 bits, puede indicar la longitud en bytes del campo base URL. base_URL, el cual es un campo de longitud variable, puede contener los bytes del URL base, los cuales pueden tener la misma semántica que el atributo baseURL del formato TPT XML.
Cuando se encuentra presente, expire_date, el cual puede ser un campo de 32 bits, puede indicar la fecha y hora de expiración de la información incluida en esta instancia de TPT. Si el receptor almacena memoria caché en la TPT, puede reutilizarse hasta expireDate. El entero sin firmar puede interpretarse como el número de segundos de GPS a partir de 00:00:00 UTC, 6 de enero de 1980, menos el GPS-UTC__offset. El desplazamiento de GPS-UTC puede ser un entero sin firmar de 8 bits que define el desplazamiento actual en segundos completos entre los estándares de tiempo de GPS y UTC. trigger_server_URL_length, el cual puede ser un campo de 8 bits, puede indicar la longitud en bytes del campo trigger_server_URL. Cuando el valor en este campo es 0, puede indicar que la distribución por internet de Activadores de Activación individual no se encuentra disponible. trigger_server_URL, cuando el valor del campo trigger_server_URL_length no es 0, puede contener los bytes de la URL del Trigger Server o Servidor de Activador, los cuales pueden tener la misma semántica que el atributo URL del elemento LiveTrigger del formato TPT X L. trigger_delivery_type, el cual puede ser un campo de 1 bit, puede indicar el modo de distribución de Activadores de Activación individuales a través de la Internet. El valor ? ' puede indicar que se está utilizando el sondeo corto de HTTP; el valor '1' puede indicar que se está utilizando ya sea el sondeo de HTTP o la transmisión continua de HTTP. poll_period, el cual puede ser un entero de 8 bits, puede indicar el número recomendado de segundos entre sondeos, cuando se está utilizando el sondeo corto de HTTP. num_apps_in_table, el cual puede ser un campo de 8 bits puede indicar el número de aplicaciones (TDO) descritas en esa instancia de TPT. app_id, el cual puede ser un campo de 16 bits, puede contener un identificador para esta aplicación (la aplicación descrita en esta iteración puede ser el circuito de num_apps_in_table). Puede ser único dentro de esta instancia de TPT. app_type_included, el cual puede ser un campo de 1 bit, puede indicar si el campo de app_type se incluye para esta aplicación. El valor '1' puede significar que se incluye; el valor *0' puede significar que no se incluye. app_name_included, el cual puede ser un campo de 1 bit, puede indicar si el campo de app_name se incluye para esta aplicación. El valor ? ' puede significar que se incluye; el valor '0' puede significar que no se incluye. global_id_included, el cual puede ser un campo de 1 bit, puede indicar si el campo global_id se incluye para esta aplicación. El valor '1' puede significar que se incluye; el valor '0' puede significar que no se incluye. app_version_included, el cual puede ser un campo de 1 bit, puede indicar si el campo app_versión se incluye para esta aplicación. El valor '1' puede significar que se incluye; el valor '0' puede significar que no se incluye. cookie_space_included, el cual puede ser un campo de 1 bit, puede indicar si el campo cookie_space se incluye para esta aplicación. El valor '1* puede significar que se incluye; el valor '0' puede significar que no se incluye. frequency_of_use_included, el cual puede ser un campo de 1 bit, puede indicar si el campo frequency_of_use se incluye para esta aplicación. El valor '1' puede significar que se incluye; el valor *0' puede significar que no se incluye. expire_date_included, el cual puede ser un campo de 1 bit, puede indicar si el campo expire_date se incluye para esta aplicación. El valor 11' puede significar que se incluye; el valor *0' puede significar que no se incluye.
Cuando se encuentra presente, app_type el cual puede ser un campo de 8 bits, puede indicar el tipo de formato para esta aplicación. El valor 0 puede indicar que esta aplicación es una TDO. Si el campo no está presente, el valor puede ser determinado a 0 . Otros valores pueden representar otros formatos.
Cuando se encuentra presente, app_name_length, el cual puede ser un campo de 8 bits, puede indicar la longitud en bytes del campo app_name que le sigue inmediatamente. El valor 0 para este campo puede indicar que no se encuentra presente el campo app_name para esta aplicación.
Cuando se encuentra presente, app_name, el cual es un campo de longitud variable, puede tener la misma semántica que el atributo appName del elemento TDO en el formato TPT XML.
Cuando se encuentra presente, global_id_length, el cual puede ser un campo de 8 bits, puede indicar la longitud en bytes del campo global_id que le sigue inmediatamente. El valor 0 para este campo puede indicar que no se encuentra presente el campo global_id para esta aplicación.
Cuando se encuentra presente, global_id, el cual es un campo de longitud variable, puede tener la misma semántica que el atributo globalID del elemento TDO en el formato TPT XML.
Cuando se encuentra presente, app_version, el cual puede ser un campo de 8 bits, tiene la misma semántica que el atributo appVersion del elemento TDO en el formato TPT XML.
Cuando se encuentra presente, cookie_space, el cual puede ser un campo de 8 bits, puede tener la misma semántica que el atributo cookieSpace del elemento TDO en el formato TPT XML.
Cuando se encuentra presente, frequency_of_use, el cual puede ser un campo de 8 bits, puede tener la misma semántica que el atributo frequency_Of_Use del elemento TDO en el formato TPT XML.
Cuando se encuentra presente, expire_date, el cual puede ser un campo de 8 bits, puede tener la misma semántica que el atributo expireData del elemento TDO en el formato TPT XML. test_app, el cual puede ser un campo de 1 bit, puede indicar si esta es una aplicación de prueba o no, destinada a ignorarse por receptores ordinarios. El valor '1' puede significar que esta es una aplicación de prueba; el valor 'O' puede significar que esta no es una aplicación de prueba. available_on_internet, el cual puede ser un campo de 1 bit, puede indicar si la aplicación se encuentra disponible mediante la Internet o no. El valor '1' puede significar que se encuentra disponible mediante la Internet; el valor 'O' puede significar que no se encuentra disponible mediante la Internet. available in broadcast, el cual puede ser un campo de 1 bit, puede indicar si esta aplicación se encuentra disponible mediante difusión o no. El valor '1' puede significar que se encuentra disponible mediante la difusión; el valor 'O' puede significar que no está disponible mediante la difusión. number_URL el cual puede ser un campo de 4 bits puede indicar el número de archivos que componen esta aplicación.
URL_length, el cual puede ser un campo de 8 bits, puede indicar la longitud del campo URL siguiente.
URL, el cual puede ser un campo de longitud variable, puede tener la misma semántica que el atributo URL del elemento TDO en el formato TPT XML. number_content_items, el cual puede ser un campo de 8 bits, puede indicar el número de artículos de contenido que pueden descargarse para su uso por esta aplicación. updates_avail, el cual puede ser un campo de 1 bit, puede indicar si este artículo de contenido se actualizará de vez en vez? es decir, si un conjunto de archivos estáticos o una alimentación de datos en tiempo real. El valor '1' puede indicar que se actualizará; el valor 'O' puede indicar que no se actualizará. available_internet, el cual puede ser un campo de 1 bit, puede indicar si los archivos que comprenden estos artículos de contenido pueden descargarse mediante la Internet o no. El valor puede significar que se encuentran disponibles para su descarga mediante la Internet; el valor '0' puede significar que no se encuentran disponibles. available_broadcast, el cual puede ser un campo de 1 bit, puede indicar si los archivos que comprenden este articulo de contenido pueden descargarse mediante la difusión o no. El valor '1* puede significar que se encuentran disponibles para descarga mediante la difusión; el valor '0' puede significar que no se encuentran disponibles. content_size_included, el cual puede ser un campo de 1 bit, puede indicar si el campo content_size se incluye para esta aplicación o no. El valor '1' puede significar que se incluye; el valor '0' puede significar que no se incluye. number_URLs el cual puede ser un campo de 4 bits puede indicar el número de archivos que comprenden este tipo archivos de contenido.
URL_length, el cual puede ser un campo de 8 bits, puede indicar la longitud del campo URL que le sigue.
URL, el cual es un campo de longitud variable, puede tener la misma semántica que el atributo URL del elemento secundario Contentltem, del elemento TDO en el formato TPT XML. content_size, el cual puede ser un campo de 24 bits puede tener la misma semántica que el atributo ContentSize del elemento secundario Contentltem del elemento TDO en el formato TPT XML. num_content_descriptors, el cual puede ser un campo de 8 bits, puede indicar el número de descriptores de contenido en el circuito descriptor que le sigue inmediatamente. content_descriptor(), el cual es un campo de longitud variable, puede ser un descriptor que conforma el formato de descriptor MPEG-2 (indicador, longitud, datos). Puede proporcionarse información adicional acerca de este articulo de contenido. Dentro de los descriptores que pueden incluirse en este circuito de descriptor puede ser descriptor Capabilities, que indica las capacidades del receptor necesarias para una presentación significativa del articulo de contenido. number_events, el cual puede ser un campo de 8 bits puede indicar el número de eventos definidos por esta TDO. event_id, el cual puede ser un campo de 16 bits, puede contener un identificador para este evento (el evento descrito en esta iteración del circuito de number_events). Puede ser único dentro del alcance de esta aplicación. El evento puede referenciarse dentro de Activadores de Activación por la combinación de app_id y event_id. action, el cual puede ser un campo de 5 bits puede tener la misma semántica que el atributo action del elemento secundario Evento del elemento TDO en el formato TPT XML. destination_included, el cual puede ser un campo de 1 bit, puede indicar si el campo de destino se incluye para este evento o no. El valor '1' puede indicar que se incluye; el valor '0' puede indicar que no se incluye. diffusion_included, el cual puede ser un campo de 1 bit, puede indicar si el campo de difusión se incluye para este evento o no. El valor *1* puede indicar que se incluye; el valor '0' puede indicar que no se incluye. data_included, el cual puede ser un campo de 1 bit, puede indicar si los campos data_size y data_bytes se incluyen para este evento. El valor '1* puede indicar que se incluyen; el valor '0' puede indicar que no se incluyen.
Cuando se encuentra presente, la semántica del campo de destino puede ser la misma que la semántica del atributo de destino del elemento secundario Evento del elemento TDO en el formato TPT XML.
Cuando se encuentra presente, la semántica del campo de difusión puede ser la misma que la semántica del atributo de difusión del elemento secundario Evento para el elemento TDO en el formato TPT XML.
Cuando se encuentra presente, el campo data_size puede indicar el tamaño del campo data_bytes que le sigue inmediatamente.
Cuando se encuentra presente, el campo data_bytes puede proporcionar datos relacionados con este evento. Cuando este evento se activa, la aplicación objetivo será capaz de leer los datos y utilizarlos para ayudar a llevar a cabo la acción deseada. El contenido de este campo puede ser idéntico al contenido del elemento secundario Datos del elemento secundario Evento correspondiente del elemento TDO correspondiente en el formato TPT XML, excepto que este campo puede contener un valor binario en fila, y el elemento Datos en el formato TPT XML puede contener una codificación en base 64 del valor binario. num_app_descriptors, el cual puede ser un campo de 8 bits, puede indicar el número de descriptores en el circuito descriptor que le sigue inmediatamente. app_descriptor(), el cual es un campo de longitud variable, puede ser un descriptor que conforma el formato de descriptor MPEG-2 (indicador, longitud, datos). Puede proporcionar información adicional acerca de esta aplicación (TDO). Dentro de los descriptores que pueden incluirse en este circuito de descriptor se encuentra el descriptor Capabilities, que indica las capacidades del receptor necesarias para una presentación significativa de esta aplicación. num_TPT_descriptors, el cual puede ser un campo de 8 bits, puede indicar el número de descriptores en el circuito descriptor que le sigue inmediatamente.
TPT_descriptor(), el cual es un campo de longitud variable, puede ser un descriptor que conforma el formato de descriptor MPEG-2 (indicador, longitud, datos). Puede proporcionar información adicional acerca de esta TPT. Dentro de los descriptores que pueden incluirse en este circuito de descriptor se encuentra el descriptor Capabilities, que indica las capacidades del receptor necesarias para una presentación significativa del servicio interactivo representado por esta TPT.
La Figura 14 es un diagrama que muestra una modalidad de una estructura de tabla de mensaje de activación. En lo sucesivo, los campos incluidos en la tabla se describirán. Los tamaños de los campos y los tipos de los campos incluidos en la tabla pueden agregarse o cambiarse de acuerdo con la intención del diseñador.
Una Tabla de Mensajes de Activación (AMT) puede contener el equivalente del Activadores de Activación para un segmento. Bajo ciertas circunstancias pueden distribuirse a los receptores en lugar de Activadores de Activación. Un activador puede distribuirse por una corriente de subtítulos, por servidores ACR, por un servidor "live trigger", y mediante AMT.
La semántica detallada de los campos en la estructura de AMT es la siguiente.
Una Tabla de Mensaje de Activación (AMT) puede incluir los aattrriibbuuttooss @majorProtocolVersion, @minorProtocolVersion, @segmentID, @beginMT y/o el elemento Activación. @majorProtocolVersion, el cual puede ser un atributo de 4 bits del elemento AMT puede indicar el número de versión principal de la definición AMT. El número de versión principal puede establecerse en 1. Los receptores pueden esperar descartar instancias de la AMT que indican valores de versión mayor que no se equipan para soporte.
Cuando se encuentra presente, @minorProtocolVersion, el cual puede ser un atributo de 4 bits del elemento AMT puede indicar el número de versión menor de la definición AMT. Cuando no se encuentra presente, el valor puede predeterminarse a 0. El número de versión menor puede establecerse en 0. Puede esperarse que los receptores no descarten instancias de la AMT que indican valores de versión menor que no se equipan para soporte. En este caso se espera que ignoren cualesquier elementos o atributos individuales que ellos no soporten. @segmentID, el cual es un identificador de la AMT, coincide el identificador de la TPT las aplicaciones y eventos a los que las Activaciones en este AMT aplican. @segmentID puede servir como un identificador de la AMT. Por consiguiente, el receptor puede recibir y analizar la AMT para identificar la AMT mediante la información de @segmentID. @segmentID contiene información que indica a qué segmento aplica la AMT, coincide @id de la TPT relacionada con el segmento, y sirve para conectar la AMT y la TPT. Además, el segmento puede identificarse para proporcionar información básica necesaria para identificar la TDO objetivo y el evento del elemento de activación de la AMT.
Cuando se encuentra presente, @beginMT, el cual es un atributo del elemento AMT, puede indicar el inicio de Media Time del segmento para el que esta instancia de AMT proporciona tiempos de activación. @beginMT puede indicar el inicio del tiempo de medios con respecto a un segmento al que se aplicará la AMT. Por lo tanto, es posible decidir un criterio de tiempo cuando la activación indicada por el elemento de activación ocurre. Por consiguiente, si se encuentra presente @beginMT, el atributo @startTime en el elemento de activación puede influenciarse por el comienzo del tiempo de medios indicado por @beginMT.
Cada instancia del elemento Activación de la AMT puede representar el comando para activar un cierto evento en un cierto momento, con ciertos datos asociados con el evento. Una pluralidad de elementos de activación puede encontrarse presente en la AMT. Cada elemento de activación realiza un rol similar al del activador de activación. El elemento de activación puede aplicar al segmento indicado @segmentID en la AMT. Los atributos del elemento de activación pueden contener información acerca de qué aplicación de activación ocurre, en qué activación de evento ocurre, cuándo ocurre la activación, etc. Los atributos del elemento de activación se describirán a detalle a continuación.
El elemento de activación puede incluir los atributos @targetTDO, @targetEvent, @targetData, @startTime y/o @endTime. @targetTDO, el cual es un atributo del elemento de Activación, puede coincidir con el atributo appID de un elemento de TDO en la TPT con la que se asocia la AMT, por lo que identifica la aplicación objetivo para el comando de activación. @targetTDO puede contener información a la que la aplicación del elemento de activación de AMT aplica. El receptor puede recibir y analizar AMT para obtener @targetTDO y encontrar @applD en el elemento TDO de la TPT que coincide para identificar la aplicación a la que el elemento de activación se aplicará. @targetEvent, el cual es un atributo del elemento Activación, puede coincidir el atributo eventID de un elemento Evento contenido en el elemento TDO identificado por el atributo targetTDO, por lo que identifica el evento objetivo del comando de activación. @targetEvent puede contener información en la que el evento al cual la aplicación del elemento de activación de la AMT aplica. El receptor puede recibir y analizar la AMT para obtener @targetEvent y encontrar @eventID en el elemento TDO de la TPT coincidente para identificar el evento al que el elemento de activación aplicará. @targetData, el cual es un atributo del elemento Activación, puede coincidir el atributo dataID de un elemento Datos contenido en el elemento Evento identificado por los atributos targetTDO y targetEvent, por lo que identifican al Datos que no se asociará con el evento objetivo cuando el comando de activación aplica. @targetData puede identificar los datos relacionados con el evento objetivo cuando el comando de activación aplica. El receptor puede recibir y analizar la AMT para obtener @targetData y encontrar @dataID en el elemento de evento de la TPT. @startTime, el cual es el atributo del elemento de evento, puede indicar el inicio del periodo de tiempo válido por el evento con relación al Tiempo de Medios. Los receptores pueden esperarse a ejecutar el comando cuando Tiempo de Medios alcance el valor en startTime, o tan pronto como esto sea posible. @startTime puede indicar el inicio del tiempo cuando ocurre el evento. Este tiempo de inicio se basa en el tiempo de medios. El receptor puede analizar la AMT para obtener la información de @startTime y confirmar el momento cuando el evento ocurre utilizando @startTime. El receptor puede activar el evento si el tiempo de medios alcanza el startTime basado en el tiempo de medios del segmento identificado por @segmentID. Si startTime ya ha respondido, el evento puede activarse tan pronto como sea posible.
Cuando se encuentra presente, @endTime, el cual es un atributo del elemento evento, puede indicar el final del periodo de tiempo valido para el evento relativo al Tiempo de Medios. Puede esperarse que el receptor no ejecute el comando cuando Tiempo de Medios ha pasado el valor de endTime. @endTime puede indicar el tiempo de finalización del evento. Si el tiempo de medios alcanza endTime, el receptor puede no realizar el evento.
Los elementos Activación en la AMT pueden aparecer en orden de valores de startTime ascendentes.
Cuando un receptor activa los eventos de acuerdo con Activaciones en un AMT, puede esperarse aplicar cada activación en su startTime, o tan pronto como después de esto sea posible (por ejemplo, en el caso cuando un receptor une el servicio y recibe el AMT en algún momento después de startTime y antes del endTime). Si el atributo "action" del elemento de evento en TPT es "exec", entonces puede esperarse que el receptor pase un TriggerEvent en la aplicación objetivo. TriggerEvent se describirá a continuación en la parte relacionada con API.
La Figura 15 es un diagrama que muestra una modalidad del diagrama estructural de Lista de URL.
Una Lista de URL puede contener ciertos URL de uso potencial para el receptor. La lista de URL puede incluir los siguientes URL, etc. 1. URL para los TPT para uno o más segmentos futuros, que permiten a un receptor pre-descargar archivos. 2. URL de un Servidor de Señalización NRT desde el que la información acerca de los servicios de NRT independientes en la corriente de difusión puedan recuperarse, permitiendo un receptor accesar a aquellos servicios incluso si no tiene acceso a distribución de señalización del servicio NRT en la corriente de difusión. 3. URL del Servidor de Reporte de Uso al que los reportes de uso pueden enviarse por un canal virtual, permitiendo a un receptor enviar tales reportes incluso si no tiene acceso a la distribución de esta URL en la corriente de difusión. 4. URL de la Tabla PDI-Q para un canal virtual, que permite a un receptor personalizar la experiencia de visualización incluso si no tiene acceso a la Tabla de PDI-Q distribuida en la corriente de difusión. (La Tabla PDI-Q se relaciona con la personalización para proporcionar un servicio personalizado para el usuario en provisión al servicio interactivo. Es posible preguntar al usuario acerca de la personalización mediante la tabla PDI-Q).
Entre otros, el URL puede hacerse con respecto al elemento UrsUrl de manera que además indique el URL del servidor para informe de uso, para utilizar datos preferidos y el tipo de contenido visto y consumido actualmente a través del receptor en negocios. El elemento Ursürl incluido en la lista de URL puede interpretarse de forma diversa como sigue.
Primero, en caso de un servidor de informe 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.) con el URL del servidor de informe de uso.
Segundo, debe existir una TDO ejecutada en el navegador web del receptor. En este caso, esto indica la ubicación de la TDO del Informe de Uso. En este caso, la TDO puede recolectar directamente e informar información acerca del contenido almacenado en el receptor consumido actualmente utilizando la API (por ejemplo, las API de archivo o las API de informe de uso) del navegador web del receptor. La TDO puede transmitir los datos recolectados utilizando API JavaScript llamado XMLHttpRequest.
URLlist puede incluir UrIList, TptUrl, Ursürl, y/o PdiUrl. Las semánticas de estos elementos son como sigue.
TptUrl, la cual es un elemento del elemento UrIList, puede contener el URL de una TPT para un segmento futuro en el servicio adjunto interactivo actual. Cuando múltiples elementos TptUrl se incluyen, pueden disponerse para la apariencia de los segmentos en la difusión.
NrtSignalingUrl, el cual es un elemento del elemento UrIList, puede contener el URL de un servidor al que los receptores pueden obtener tablas de señalización de NRT para todos los canales virtuales en la corriente de transporte actual.
UrsUrl, el cual es un elemento del elemento UrIList, puede contener el URL de un servidor al que los receptores pueden enviar informes de uso (medición de audiencia) para el canal virtual actual.
PdiUrl, el cual es un elemento del elemento UrIList, puede contener el URL de la tabla PDI-Q pra el canal virtual actual.
La Figura 16 es un diagrama que muestra una modalidad del formato binario para las secciones privadas que contienen las TPT. La Figura 16 ilustra un caso en el que una TPT se distribuye en una corriente de difusión en un mecanismo de distribución el cual se describirá a continuación. Los detalles se describen posteriormente.
Se dará una descripción de un mecanismo de distribución para distribuir un activador, una TPT, etc. La salida desde la Creación de Servicio Interactivo, Distribución de Activadores en Corriente de Difusión, Distribución de Activadores de Tiempo base mediante la Internet, Distribución de Activadores de Activación mediante Internet (Escenario ACR), Distribución de las TPT en Corriente de Difusión, Distribución de las TPT mediante Internet, Mover las TDO y Artículos de Contenido, Combinar Múltiples Segmentos en Un Segmento se describirán secuencialmente.
En lo sucesivo, la Salida de Creación de Servicio Interactivo se describirá.
El proceso de creación de servicio para un segmento puede resultar en la carpeta que contiene todas las TDO y otros artículos de contenido, archivo TPT en el formato XML y archivo AMT en el formato XML. Los otros resultados pueden crearse.
En lo sucesivo, se describirá la Distribución de Activadores en la Corriente de Difusión.
Cuando se distribuyen en la corriente de difusión, pueden distribuirse Activadores en el canal de Subtítulos DTV, en el Servicio #6, en el comando URLString.
Si el Activador es menor que o igual a 26 caracteres de longitud, puede enviarse sin segmentar (Tipo 11). Si el Activador es de 27 a 52 caracteres de longitud, pueden enviarse en dos segmentos (el primer segmento en un segmento Tipo=00 y el segundo segmento en un segmento Tipo=10).
El tipo de URI distribuido en cualquier instancia dada del comando puede darse por un comando de 8 bits.
Para los servicios interactivos que utilizan el modelo TDO, el tipo URI de la estructura de datos URI puede establecerse en 0 (Activador de TV Interactivo para el modelo TDO). Este mecanismo de distribución incluye tanto los activadores basados en Tiempo base como los Activadores de Activación.
En el caso en el que el activador base se distribuye mediante una corriente de difusión (en el servicio #6 de subtítulos), si el término "m=" se encuentra ausente, el activador de Tiempo base puede simplemente distribuir el URL del Servidor de Señalización. Y si el término "m=" se encuentra ausente, entonces el término "t=" deberá estar ausente de los activadores de Activación.
En el caso en el que el activador de activación se distribuye mediante una corriente de difusión (en el servicio #6 de subtítulos), es decir, en el caso del formato "Activador", con el término "e=", con o sin el término "t=", si el término "t=" está presente, el tiempo de activación puede ser el indicador de tiempo relativo a un tiempo base. Y si el término "t=" se encuentra ausente, el tiempo de activación puede ser el tiempo de llegada del mensaje.
En el caso en el que el activador de tiempo base y el activador de activación se distribuye mediante el servicio #6 de CC, puede haber tres posibles formas para los difusores para manejar activadores de Tiempo Base y de Activación. Las tres formas son 'Modo de segmento sin base de tiempo explícito', 'Modo de segmento con un tiempo base explícito' y 'Modo de servicio con tiempo base explícito'.
Estos pueden mezclarse dentro de una difusión, en una base segmento a segmento.
En el modo de segmento sin tiempo base explícito, los mensajes de Activación no incluyen una marca de tiempo, de manera que el tiempo de activación para cada mensaje puede ser el tiempo de distribución del mensaje, y los mensajes Tiempo Base tampoco incluyen una marca de tiempo, de manera que su único propósito es proporcionar el URL del servidor de Señalización que puede distribuir los archivos TPT. Los mensajes Tiempo Base pueden incluso omitirse completamente en este modo, confiando en el URL en los mensajes de Activación para proporcionar el URL del Signaling Server, pero entonces los receptores no serán capaces de recuperar una TPT e iniciar la descarga de las TDO hasta después de que el primer mensaje Activación aparezca, demorando la respuesta del primer mensaje Activación un poco.
En este caso los mensajes Tiempo Base que pueden aparecer en el servicio #6 de CC pueden contener el "locator_part" del formato "Activador" y posiblemente el término "spread", pero no el término "media_time", y los mensajes Activación que pueden aparecer en el servicio #6 de CC pueden contener el "locator_part" del formato "Activador", el término "event time", y posiblemente el término "spread", pero sin la parte "t=" en el término "event time". El "locator_part" de tanto los mensajes Tiempo Base como Activación pueden ser el segmentld actual. Esta URL también puede utilizarse para recuperar la TPT para el segmento mediante la Internet.
En el modo de segmento con tiempo base explícito, los mensajes Tiempo Base incluyen una marca de tiempo, que define un tiempo base, y los mensajes Activación pueden incluir una marca de tiempo, para definir el tiempo de activación relativo al tiempo base, o pueden no incluir una marca de tiempo, que indique que el tiempo de activación es el tiempo de llegada del mensaje.
En este caso los mensajes Tiempo Base que pueden aparecer en el servicio #6 de CC pueden contener el "locator_part" del formato "Activador", el término "media_time", y posiblemente el término "spread" y los mensajes Activación que pueden aparecer en el servicio #6 de CC pueden contener el "locator_part" del formato "Activador", el término "event_time", y posiblemente el término "spread", con o sin la parte "t=" en el término "event_time". La "locator_part" de tanto mensajes Tiempo Base como Activación puede ser el segmentld actual, y el tiempo base se especifica en el segmento. Esta URL también puede utilizarse para recuperar la TPT para el segmento mediante la internet.
En el modo de servicio con tiempo base explícito, los mensajes Tiempo Base incluyen una marca de tiempo, para definir un tiempo base, y mensajes Activación pueden o no incluir una marca de tiempo. El tiempo base puede extenderse a través de múltiple segmentos, en lugar de ser específico a un sólo segmento. El "locator_part" de los mensajes Tiempo Base pueden ser un identificador del tiempo base, y también un URL que puede utilizarse para recuperar las TPT para el servicio mediante la Internet.
En cualquier caso el Servidor de Inserción de Activador o Trigger Insertion Server que inserta los activadores en el servicio #6 de CC deberá funcionar para la AMT, trasladar los mensajes Activación desde el formato XML en el AMT en el formato de activador especificado para la distribución en el servicio #6 de CC. En el caso de un elemento Activación sin el atributo endTime, un solo activador puede insertarse con el tiempo de activación igual al atributo startTime. En el caso de un elemento Activación con ambos de los elementos startTime y endTime, una secuencia de activadores puede insertarse con el mismo objetivo. El primer activador en la secuencia puede tener tiempo de activación igual al atributo startTime, el último activador en la secuencia puede tener un tiempo de activación igual al atributo endTime, y pueden haber intervalos de tiempo fijos entre los tiempos de activación de los activadores en la secuencia (excepto en que el penúltimo y último activador en la secuencia serán más cortos. La longitud de ese intervalo de tiempo fijo puede configurarse.
Cuando los mensajes Tiempo Base y Activación se encuentran en el modo de segmento, el tiempo base puede ser especifico al segmento. Puede iniciar con el valor "beginMT" al inicio del segmento, y correr a través del segmento. Los valores "startTime" y "endTime" de Activaciones individuales pueden ser relativos al valor "beginMT". Cuando los mensajes Tiempo Base y Activación se encuentran en modo de servicio, el tiempo base puede extender los segmentos, y el valor "beginMT" para cada segmento puede ajustarse para tomar en cuenta el tiempo base de servicio y el horario de difusión.
En lo sucesivo, se describirán los activadores Distribución de Tiempo mediante la Internet.
La distribución por Internet de activador de Tiempo base pueden ser útiles en situaciones también llamadas Reconocimiento de Contenido Automático (ACR), en donde el receptor de los activadores de Tiempo base no tiene acceso al Servicio #6 de Subtítulos. En estas situaciones, el receptor necesita utilizar ACR para reconocer tramas de video y sincronizar el tiempo base con ellas. En situaciones de ACR los mensajes de Tiempo Base pueden obtenerse desde marcas de agua o de los servidores ACR. En caso de recepción desde el servidor ACR, los mensajes de Tiempo Base de distribuyen como respuestas desde el servidor ACR.
En lo sucesivo, se describirá Distribución de Activadores de Activación mediante la Internet (Escenario ACR).
Los mensajes Activación pueden distribuirse mediante un sondeo corto, sondeo largo o transmisión continua, pero todos esos pueden imponer una gran sobrecarga en los receptores y el servidor. Los mensajes Activación también pueden distribuirse en la forma de una AMT, pero esto puede proporcionar una buena cantidad de información acerca de la longitud de segmentos, facilitando eliminadores de anuncios. Pueden existir otras alternativas.
En el caso en el que el mensaje de activación se distribuye en la forma del activador de activación, es decir, en caso del formato "Activador" con el término "e=", con o sin el término "t=", esto puede distribuirse mediante un sondeo corto, sondeo largo o transmisión continua de HTTP.
Cuando se distribuye mediante la internet, los mensajes Activación puede distribuirse utilizando cualquiera o ambos del mecanismo Individual Activador de Distribución de Activación y el mecanismo Activador en Masa de Distribución de Activación.
En adelante, se describirá Distribución Individual Activador de Activación.
Como se describe en lo anterior, cuando los Activadores de Activación individuales se distribuyen mediante la Internet, pueden distribuirse utilizando un sondeo corto, sondeo largo o transmisión continua de HTTP. El formato de Activador de Activación puede ser exactamente el mismo que cuando se distribuye mediante el servicio #6 de DTVCC.
En caso de sondeo corto, el periodo de sondeo deberá especificarse. En este periodo, una operación de sondeo corto puede establecerse utilizando pollPeriod incluido en la TPT como se describe a continuación.
Cuando la distribución por Internet de Activadores de Activación se encuentra disponible, el atributo URL del elemento LiveTrigger en la TPT puede indicar el Activador de Activación Server al gue el activador de activación puede distribuirse. Si el atributo pollPeriod del elemento LiveTrigger se encuentra presente en la TPT, esto puede indicar gue el sonde corto de HTTP se está utilizando, y puede indicar el periodo de sondeo gue un receptor deberá utilizar. Si el atributo pollPeriod del elemento LiveTrigger no se representa en la TPT, esto puede indicar gue cualguiera del sondeo largo de HTTP o transmisión continua de HTTP se está utilizando.
Sin importar el protocolo que se está utilizando, puede esperarse que el receptor emita una solicitud de HTTP al Servidor de Activador de Activación con el término de consulta: ?mt=<media time> en donde <media_time> puede ser el tiempo de medios actual del contenido viéndose.
Si está utilizando el sondeo corto, la respuesta desde el Servidor de Activador de Activación puede contener todos los Activadores que se han emitido dentro del intervalo de tiempo de la longitud de pollPeriod que termina en <media_time>. Si más de una Activación de Activador se regresa, pueden separarse por uno o más caracteres de espacio en blanco. Si no se regresa ningún Activador de Activación, la respuesta puede ser vacia.
Si se está utilizando un sondeo largo de HTTP o transmisión continua de HTTP, el Servidor de Activador de Activación puede esperar a regresar en respuesta hasta que el tiempo de medios cuando el Activador de Activación deberá distribuirse en la corriente de difusión. En este momento puede regresar el Activador de Activación.
Si se está utilizando el sondeo largo de HTTP, el Servidor de Activador de Activación puede cerrar la sesión después de regresar un Activador de Activación. Puede esperarse que el receptor emita inmediatamente otra solicitud, con un tiempo de medios actualizado Si la transmisión continua de HTTP se está utilizando, el Servidor de Activador de Activación puede mantener la sesión abierta después de regresar cada Activador de Activación, y distribuir Activador de Activación adicionales a través de la sesión cuando llega el momento para que ellos se distribuyan.
En todos los casos, la respuesta de HTTP puede contener un Campo de Encabezado de Respuesta de HTTP de una de las siguientes formas para señalar el modo de distribución: ATSC-Delivery-Mode: ShortPolling [<poll-period>] ATSC-Delivery-Mode: LongPolling ATSC-Delivery-Mode: Streaming El parámetro <poll-period> puede indicar el intervalo recomendado entre los sondeos para la sucesión de los sondeos. El <poll-period> puede omitirse.
En lo sucesivo, se describirá Distribución de Activador de Activación en Masa.
Cuando Activadores de Activación se distribuyen mediante la Internet en masa, los Activadores de Activación para un segmento pueden distribuirse mediante HTTP junto con la TPT para el segmento, en la forma de un mensaje MIME de partes múltiples, 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á la Distribución de las TPT en Corriente de Difusión.
Cuando se distribuye la corriente de difusión, las TPT pueden trasladarse desde su formato XML a un formato de tabla de señalización de estilo NRT binario equivalente y encapsularse en secciones privadas estilo NRT, una TPT por instancia de tabla. La TPT para el segmento actual se encuentra siempre presente. Las TPT para uno o más segmentos futuros también pueden estar presentes. La instancia TPT se define por el valor de su campo segment_id. Para referencia, el formato binario de la tabla de parámetro TDO se describió en lo anterior. Aquí, la sección privada estilo NRT puede corresponder a tpt_section() de la Figura 16.
En resumen, para transmitir la estructura binaria de la TPT en NRT, la TPT puede tener una estructura de sección adecuada para la transmisión de NRT. En lo sucesivo, este proceso se describirá a detalle.
Cada TPT puede encapsularse en secciones privadas de estilo NRT al dividir cada TPT en bloques e insertar los bloques en los campos tpt_bytes() de las secciones que tienen un valor común de los campos table_id, protocol_version TPT_data_version y sequence_number. Los bloques pueden insertarse en las secciones en el orden de valores de campo section number ascendente. Las secciones privadas pueden llevarse en el Canal de Señalización de Servicio o Service Signaling Channel (SSC) de la subred IP del canal virtual al que pertenece la TPT. Aquí, "Service Signaling Channel" se define en el estándar ATSC-NRT y significa un canal que tiene una dirección IP especifica y un número de puerto. Los campos sequence_number en las secciones pueden utilizarse para distinguir diferentes instancias de TPT llevadas en el mismo SSC.
En lo sucesivo, se describirán los campos de la Figura 16.
La sección privada (tpt_section()) puede incluir table_id, protocol_version, sequence_number, TPT_data_version, current_next_indicator, section_number, last_section_number, service_id, y/o información tpt_bytes(). table_id, la cual puede ser un campo de 8 bits, puede identificar esta sección de tabla como perteneciendo a una instancia de Tabla de Parámetros de TDO. protocol_version puede dividirse en dos partes. El orden de 4 bits alto de este campo entero sin firmar de 8 bits puede indicar el número de versión mayor de la definición de esta tabla y la instancia de TPT llevada en esta, y los 4 bits de orden bajo pueden indicar un número de versión menor. El número de versión principal puede establecerse en 1. Los receptores pueden esperar descartar instancias de la AMT que indican valores de versión mayor que no se equipan para soporte. El número de versión menor puede establecerse en 0. Puede esperarse que los receptores no descarten instancias de la AMT que indican valores de versión menor que no se equipan para soporte. En este caso puede esperarse que ignoren cualesquier descriptores que no reconozcan, e ignorar cualesquier campos que no soportan. sequence_number puede ser un campo de 8 bits. El valor de sequence_number puede ser el mismo que el sequence_number de todas las secciones de esta instancia TPT y diferente de la sequence_number de todas las secciones de cualquiera de las instancias TPT en este Canal de Señalización de Servicio. Por consiguiente, este campo puede realizar un rol diferente al de otras instancias TPT, el campo sequence_number puede indicar una subred IP asociada con un canal de señalización en esta sección. Los valores de los campos sequence_number de las diferentes instancias TPT pueden reflejar el orden en el que aparecerán los segmentos en la corriente de distribución.
TPT_data_version, el cual puede ser un campo de 5 bits, puede indicar el número de versión de esta instancia de TPT, donde la instancia TPT puede definirse por su segment_id. Debido a que la versión TPT se conoce por adelantado para determinar si los datos de sección TPT son una nueva versión de TPT, el campo TPT_data_version puede presentarse en la tabla de sección. El número de versión puede aumentar por 1 el módulo 32 cuando cualquier campo en la instancia de TPT cambia. current_next_indicator, el cual puede ser un indicador de 1 bit, puede establecerse siempre en '1 ' para las secciones TPT, indicando que la TPT enviada siempre es la misma TPT actual para el segmento identificado por su segment_id. section_number, la cual puede ser un campo de 8 bits, puede dar el número de versión de esta sección de instancia de TPT, donde la instancia TPT puede identificarse por su segment_id. El section_number de la primera sección en una instancia TPT puede ser 0x00. El section_number puede aumentar por 1 con cada sección adicional en la instancia TPT. last_section_number, el cual puede ser un campo de 8 bits, puede dar el número de la última sección (es decir, la sección con el section_number mayor) de la instancia TPT instancia del cual esta sección es una parte. service_id, el cual puede ser un campo de 16 bits, puede especificar el service_id asociado con el servicio interactivo que ofrecen los artículos de contenido descritos en esta instancia de tabla. tpt_bytes(), el cual es un campo de longitud variable, puede incluir un bloque de la instancia de TPT llevada en parte por esta sección. Cuando los campos tpt_bytes() de todas las secciones de esta instancia de tabla se concatenan en el orden de subcampos de section_number, el resultado puede ser la instancia de TPT completa.
Es decir, después de que se utiliza el formato binario de la TPT o el formato XML se cambia a un formato binario, la TPT puede dividirse para ser adecuada para la transmisión NRT, incluida en el campo tpt_bytes() de la sección privada, y transmitirse en NRT. En este momento, si se divide TPT en diversas secciones privadas, la sección privada puede tener el mismo valor table_id, protocol_version TPT_data_version y sequence_number. Los bloques de TPT divididos pueden insertarse en el orden de los valores del campo section_number.
El receptor puede analizar las secciones privadas recibidas. Para combinar las secciones privadas en una TPT de nuevo, las secciones privadas que tienen los mismos valores table_id, protocol_version TPT_data_version and sequence_number pueden utilizarse. En ese momento, la información del orden capaz de obtenerse desde la información de section_number y last_section_number puede utilizarse. Si tpt_bytes() de todas las secciones privadas que tienen los mismos valores table_id, protocol_version TPT_data_version and sequence_number se conectan secuencialmente, puede crearse una TPT.
La distribución de las TPT mediante la Internet se describirá a detalle con referencia a la Figura 17.
En lo sucesivo, se describirán Mover los TDO y Artículos de Contenido.
Las redes y estaciones a menudo necesitarán proporcionar sus propios servidores de HTTP para la distribución de los TDO y artículos de contenido (archivos) utilizados por los TDO. Cuando esto se hace, la baseURL en la TPT puede ajustarse para reflejar la ubicación del servidor.
En lo sucesivo, Combinar Múltiples Segmentos en Un Segmento se describirá.
Para ocultar completamente los límites entre los segmentos, las TPT y AMT para segmentos múltiples pueden combinarse en una sola TPT y AMT. Las siguientes etapas pueden realizarse. 1. Identificar el conjunto de segmentos a combinarse. 2. Crear una nueva TPT con un nuevo segmentld. 3. Si cualquiera de los segmentos combinados tiene activaciones en vivo, proporcionar un servidor de retransmisión que proporcione acceso a todos ellos, y poner los parámetros para este servidor en el elemento "Live Activador". 4. Aplicar la baseURL para cada segmento según se necesite para obtener todas las URL de TDO y Contentltem. (Puede ser posible identificar una baseURL más corto que es común a todos los segmentos combinándose, y mantenga esto como una baseURL para el segmento combinado). 5. Revisar los valores appID según sea necesario para remover conflictos. 6. Insertar en la nueva TPT todos los elementos de TDO revisados para todos los segmentos combinándose. 7. Crear una nueva AMT con segmentld igual al nuevo segmentld de la TPT combinada. 8. Seleccionar un nuevo valor "beginMT" apropiado para la nueva AMT. 9. Ajustar los valores targetld de todos los elementos Activación en los archivos AMT para los segmentos combinándose para reflejar cualesquier cambios en los valores appID. 10. Ajustar los valores de startTime y endTime de todos los elementos Activación en los archivos AMT para los segmentos combinándose para reflejar el nuevo valor "beginMT" y el horario de difusión para los segmentos combinándose. 11. Insertar todos los elementos Activación revisados en una nueva AMT.
La Figura 17 es un diagrama que muestra una modalidad de una lista de los URL codificados como un documento XML.
En lo sucesivo, se describirá la Distribución de las TPT mediante la Internet.
Cuando se distribuyen a través de la Internet, las TPT pueden distribuirse mediante HTTP. El URL de la TPT para el segmento actual puede ser "<domain ñame part>/<directory path>" en mensajes Tiempo Base. La respuesta a una solicitud para una TPT puede incluir solamente la TPT, o puede incluir mensajes MIME de dos vías, con la TPT solicitada en la primera parte y una lista de los URL en la segunda parte, como un documento XML. (La respuesta a una solicitud siempre incluirá la TPT para el segmento actual. Puede incluir las TPT para uno o más segmentos futuros también).
Los URL como la segunda parte de la respuesta descrita en lo anterior puede tener el formato mostrado en la Figura 17.
Las semánticas de los elementos en la Figura 17 se describirán.
"UrlList" puede contener una lista de los URL que son útiles para un receptor.
"TptUrl" puede contener el URL de una TPT para un segmento futuro. Cuando múltiples elementos TptUrl se incluyen, pueden disponerse en orden de aparición de los segmentos en la difusión.
"NrtSignalingUrl" puede contener el URL de un servidor en donde los receptores pueden obtener tablas de señalización NRT para todos los canales virtuales en la corriente de difusión actual.
La Figura 18 es un diagrama que muestra una modalidad de addTriggerEventListener.
En lo sucesivo, se describirán ATSC JavaScript API para un entorno para ejecutar DO.
Para soportar la sincronización de acciones de Declarative Object para programas de difusión, pueden soportarse métodos adicionales para el objeto de video/difusión.
Si la TPT se recibe mediante DTVCC o la Internet, diversos eventos para ejecutar TDO pueden darse en la TPT y estos eventos pueden activarse por el activador de activación.
Para procesar este evento, una función de Listener puede registrarse en una base por eventID. Por consiguiente, como los 'métodos adicionales' descritos en lo anterior, las dos funciones, addTriggerEventListener y removeTriggerEventListener, para registrar la función de Listener están presentes.
En la Figura 18, se describe addTriggerEventListener y formato, argumentos, etc. se muestran.
La función addTriggerEventListener puede registrar una función de llamada de regreso (función de listener) para procesar un evento generado en una base por eventID. La función addTriggerEventListener puede recibir al oyente del tipo EventListener y eventID del tipo Número o Número como argumento. El tipo eventListener se describirá a continuación. La función addTriggerEventListener puede no tener un valor de regreso (inválido). Aquí, el argumento eventID puede ser el ID del evento del elemento del evento de TPT. Aquí, el argumento oyente puede ser un oyente para el evento.
El módulo de procesamiento de activador del receptor puede registrar la función de oyente en una base por eventID utilizando la función "addTriggerEventListener" en cuanto se reciba el mensaje de activación. Si se activa el evento, la función de oyente registrado puede ser llamada. En este momento, el objeto del tipo TriggerEvent puede distribuirse a la función del oyente. El tipo TriggerEvent se describirá a continuación.
La Figura 19 es un diagrama que muestra una modalidad para de removeTriggerEventListener.
En la Figura 19, se describe removeTriggerEventListener y formato, argumentos, etc. se muestran.
La función removeTriggerEventListener puede cancelar el registrar de una función de llamada de regreso (función de oyente) para procesar un evento generado en una base por eventID. La función removeTriggerEventListener puede recibir al oyente del tipo EventListener y eventID del tipo Número como argumento. El tipo eventListener se describirá a continuación. La función removeTriggerEventListener puede no tener un valor de regreso (inválido). Aquí, el argumento eventID puede ser el ID del evento en el elemento de evento de TPT. Aquí, el argumento oyente puede ser un oyente para el evento.
En el programa javascript, si el evento que puede generarse en una base por eventID desea recibirse o si el programa "DestroyWindow" termina, la función del oyente registrada utilizando "removeTriggerEventListener" puede cancelarse.
La Figura 20 es un diagrama que muestra una modalidad de la definición del tipo EventListener; Aquí, la definición del tipo EventListener conforma el lenguaje de definición de Interfaz Web (Weg IDL). Web IDL puede utilizarse para describir interfaces que pretenden implementarse en navegadores web. Web IDL es una variante IDL con un número de características que permiten el comportamiento de objetos de programación comunes en la plataforma web para especificarse más fácilmente.
EventListener puede ser un objeto de interfaz. El tipo EventListener puede tener un evento de tipo TriggerEvent como un argumento.
La Figura 21 es un diagrama que muestra una modalidad de la definición del tipo TriggerEven.
El tipo TriggerEvent puede contener información acerca del evento.
El tipo TriggerEvent puede tener eventID, datos y estados como propiedades. Aquí, eventID puede ser eventID en el elemento de 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 "activador", esto significa un estado en el que el evento se activa el activador de activación. Si el valor del estado es "error", esto significa un estado en el que ocurre un error.
El modelo TDO se ha descrito. En lo sucesivo, el modelo de Direct Execution o Ejecución Directa se describirá.
En el modelo Ejecución Directa, un Objeto Declarativo (DO) puede iniciarse automáticamente tan pronto como se selecciona el canal virtual. Puede comunicarse a través de la Internet con un servidor de cabecera para obtener instrucciones detalladas para proporcionar características interactivas creando visualizaciones en ubicaciones específicas de la pantalla, conduciendo sondeos, iniciando otros DO especializados, etc., todo sincronizado con el programa de audio-video.
En lo sucesivo, se describirá la operación de activador en el modelo de ejecución directa.
El rol, función y sintaxis del activador ya no cambian en gran medida en el modelo de ejecución directa.
El rendimiento del activador es igual al descrito e lo anterior.
La sintaxis del activador es igual a la descrita en lo anterior.
Un Activador puede considerarse que incluye en otras partes. <domain ñame part>/<directory path>[?<parameters> En el modelo de ejecución directo, la combinación de <domain ñame part> y <directory path> pueden identificar únicamente el DO al mezclarse. <parameters> puede incluir uno o más de "event_time", "media_time", o "spread" En el modelo de ejecución directo, se inicia una aplicación automáticamente en cuanto se selecciona el canal virtual. La aplicación puede comunicarse a través de la Internet con un servidor de cabecera mediante un "Synchronized Content Protocol" o "Protocolo de Contenido Sincronizado". El servidor puede dar instrucciones detalladas para proporcionar característica interactiva, las cuales se sincronizan todas con el programa de audio-video.
En caso del modelo de ejecución directa, debido a que una aplicación se ejecuta inmediatamente, la información puede distribuirse a la aplicación ejecutada actualmente cuando se distribuye un activador en tiempo base. En este modelo, la aplicación necesita distribuir información continuamente acerca del contenido de difusión actualmente al servidor para sincronización. Para este fin, el activador del tipo base además puede incluir información especial diferente a la del modelo TDO. Esta información especial puede ser un identificador de contenido de difusión actual.
De forma similar, el identificador de contenido puede presentar en la parte del parámetro del activador en la forma de un parámetro.
De forma similar, el identificador de contenido puede presentarse en media_time del activador en la forma de un término. El término identificador de contenido, el cual puede llamarse content_id, el cual también puede designarse por "c =" seguido por una cadena de caracteres, puede representar un identificador para el contenido viéndose actualmente.
El término content_id puede destinarse para soportar el modelo Ejecución Directa de la implementación de servicio interactivo.
Como se describe en lo anterior, en este modelo, los activadores de Tiempo base con el término content_id pueden pasar en la aplicación después de que se inicien, y la aplicación puede distribuir content_id al servidor de cabecera para identificar el contexto de la interacción. La operación detallada de los mismos se describirá a continuación.
El mecanismo de distribución del activador en el módulo de ejecución directa es igual al descrito en lo anterior.
Sin embargo, en caso de Distribución de los Activadores en la Corriente de Difusión, los Activadores pueden distribuir en el canal de DTV de Subtítulos, en el Servicio #6, en el comando URLString. Y para servicios interactivos utilizando un modelo de Ejecución Directa, el campo URI_type puede establecerse para 2 (Activador de TV Interactivo para modelo de Ejecución Directa).
En lo sucesivo, se describirá la operación general del módulo de ejecución directa.
En un modelo para ejecutar el servicio interactivo, en el modelo de ejecución directa, una aplicación puede iniciar automáticamente en cuanto el canal virtual se seleccione. La aplicación puede comunicarse a través de la Internet con un servidor de cabecera mediante un "Synchronized Content Protocol". El servidor puede dar instrucciones detalladas para proporcionar características interactivas, creando visualizaciones en ubicaciones específicas en la pantalla, conduciendo sondeos, iniciando otros DO especializados, etc., todos sincronizados con el programa de audio-video.
La operación puede realizarse como sigue.
Primero, una aplicación puede iniciar. Entonces, se recibe un activador de tiempo base. El activador de tiempo base se distribuye con la aplicación después de que la aplicación se ha ejecutado. El término content_id del activador de tiempo base puede incluir contenido de información de identificación de contenido mostrado actualmente. La aplicación puede distribuir el content_id al servidor de cabecera para identificar el contexto de la interacción y para identificar el contenido viéndose actualmente.
Se ha descrito el Modelo Ejecución Directa.
La Figura 22 es un diagrama que muestra la arquitectura para un procedimiento WM.
Se dará una descripción de Delivery o Distribución mediante otras interfaces.
Protocolos y arquitecturas permiten adquisición de un servicio interactivo en entornos (por ejemplo, como se recibe desde una caja de convertidor-descodificador de cable o satélite) en la que solamente video y audio sin comprimir pueden accederse) se definen. La arquitectura y protocolos pueden designarse para uso por receptores que tienen conexiones a Internet y que solamente tienen acceso a audio y video desde la corriente de difusión. Desde luego, la arquitectura y protocolos pueden utilizase exitosamente si el proveedor de servicio interactivo elige soportar los mismos.
La arquitectura puede designarse para soportar dos procedimientos básicos para identificar el contenido observándose, de manera que cualesquier mejoras de datos de servicio interactivo asociados pueden distribuirse mediante la internet. Los dos procedimientos básicos pueden ser marca de agua y firma digital.
En los procedimientos de agua de marca y firma digital, el intento puede permitir a los receptores encontrar que programación está viendo actualmente y obtener la URL que puede utilizarse como el punto de inicio para obtener información adicional acerca de los servicios interactivos para la programación.
La Figura 22 ilustra una arquitectura para un procedimiento de WM.
En una arquitectura para un procedimiento WM, la arquitectura puede incluir un difusor 22010, un introductor 22011 de marca de agua, un MVPD 2202, un STB 22030, un receptor 22040, un cliente de WM 22050, un servidor de TPT 22060, o un servidor de contenido 22070.
El difusor 22010 puede ser una fuente que impulse corrientes de audio/video y servicios interactivos relacionados con las corrientes de audio/video. Una estación de televisión puede ser un ejemplo del difusor 22010. El difusor 22010 puede ser un productor o difusor de contenido de difusión. El difusor 22010 puede distribuir corrientes de difusión, contenido de audio/video, datos interactivos, horarios de difusión o AMT.
El insertor 22011 de marca de agua puede insertar marcas de agua en las tramas de difusión de audio/video. El insertor 22011 de marca de agua puede integrarse con el difusor 22010 o puede ser un módulo separado. Las marcas de agua pueden ser información necesaria para los receptores. Las marcas de agua pueden ser información tal como una URL. Las marcas de agua se describirán a detalle posteriormente.
El MVPD 22020 es una abreviación para el distribuidor de programa de video de multiprograma. El MVPD 22020 puede ser un operador de cable, un operador de satélite o un operador IPTV. El MVPD 22020 puede recibir la corriente de difusión desde el Difusor/Marca de Agua, con las marcas de agua insertadas por el Insertor 22011 de Marca de Agua en el caso del sistema de ACR de marca de agua. El MVPD 22020 a menudo extrae todos los programas de elementos diferentes a las pistas de audio y video, y envía la corriente resultante a las cajas de convertidor-descodificador (STB) en las instalaciones del cliente.
La STB 22030 típicamente descodifica (descomprime) el audio y video y envía el mismo a un televisor para su presentación a los espectadores. La STB puede enviar contenido de audio/video sin comprimir al receptor 22040. La STB puede ser una unidad de descodificación externa de acuerdo con una modalidad de la presente invención.
El receptor 22040 puede incluir un cliente 22050 de WM. El cliente 22050 de WM puede disponerse fuera del receptor 22040. Aquí, el receptor puede tener capacidad de marcas de agua. La estructura del receptor 22040 se describirá posteriormente.
El Cliente 22050 de WM puede obtener Activadores de Activación desde el Servidor de ACR (no mostrado) y pasar el mismo dentro del código receptor principal, utilizando proveedor de API para tal propósito. Normalmente, el Cliente 22050 de WM podría integrarse dentro del receptor, pero son posibles otras configuraciones. El cliente 22050 de WM puede extraer marcas de agua insertadas desde el contenido de audio/video sin comprimir. Todas las marcas de agua pueden ser información tal como una URL.
El servidor 22060 de 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 de ACR. Cuando las marcas de agua coinciden con las marcas de agua almacenadas en una base de datos (no mostrada), el receptor 22040 puede recibir un activador o activadores como una respuesta. Cuando el activador o activadores recibidos tienen el nuevo locator_part descrito en lo anterior o una TPT o tabla de parámetro de aplicación de una nueva versión se descubre, el receptor 22040 puede solicitar al servidor 22060 de TPT descargar una nueva TPT o tabla de parámetros de aplicación.
El servidor 22070 de contenido puede proporcionar aplicaciones y TDO necesarios para proporcionar servicios interactivos. Cuando una nueva aplicación o TDO se necesita, la nueva aplicación puede descargarse utilizando un URL y tabla de parámetros de aplicación.
En el procedimiento de marca de agua (WM) el introductor de difusor/marca de agua puede insertar marcas de agua en la difusión de tramas de audio o video. Estas marcas de agua pueden diseñarse para llevar una cantidad modesta de información a los receptores, mientras que es imperceptible o al menos mínimamente invasiva para los espectadores. Tales marcas de agua pueden proporcionar directamente la información que el receptor necesita, o podrían proporcionar solamente un valor de código que los receptores pueden enviar mediante una conexión de Internet a un servidor remoto para obtener información que necesitan.
La Figura 23 es un diagrama que muestra una modalidad de arquitectura para un procedimiento de FP.
En la arquitectura del enfoque de FP, la arquitectura puede incluir un difusor 23010, un MVPD 23020, un STB 23030, un receptor 23040, un cliente de FP 23050, un servidor de TPT 23060, un servidor de contenido 23070, un extractor de firma 23080 y/o un servidor FP 23090.
El difusor 23010 puede ser una fuente que impulse corrientes de audio/video y servicios interactivos relacionados con las corrientes de audio/video. Una estación de televisión puede ser un ejemplo del difusor 22010. El difusor 22010 puede ser un productor o difusor de contenido de difusión. El difusor 22010 puede distribuir corrientes de difusión, contenido de audio/video, datos interactivos, horarios de difusión o AMT.
El MVPD 23020 es la abreviación para el distribuidor de programa de video multiprograma. El MVPD 22020 puede ser un operador de cable, un operador de satélite o un operador IPTV. El MVPD 23020 a menudo extrae todos los programas de elementos diferentes a las pistas de audio y video, y envía la corriente resultante a las cajas de convertidor-descodificador (STB) en las instalaciones del cliente.
La STB 23030 típicamente descodifica (descomprime) el audio y video y envía el mismo a un televisor para su presentación a los espectadores. La STB puede enviar contenido de audio/video sin comprimir al receptor 23040. La STB 23030 puede ser una unidad de descodificación externa de acuerdo con una modalidad de la presente invención.
El receptor 23040 puede incluir un cliente 23050 FP. El cliente 23050 FP puede disponerse fuera del receptor 23040. Aquí, el receptor 23040 puede ser capaz de firma digital. La estructura del receptor 23040 se describirá posteriormente.
El Cliente 23050 de FP puede obtener Activadores de Activación desde el Server 23090 de FP y los pasa dentro del código receptor principal, utilizando proveedor de API proporcionado para tal propósito. Normalmente, el Cliente 23050 de FP podría integrarse dentro del receptor, pero son posibles otras configuraciones. El cliente 23050 de FP puede extraer una firma digital desde el contenido de audio/video sin comprimir. La firma digital se describirá a detalle posteriormente.
El servidor 23060 de TPT puede ser un servidor capaz de descargar una aplicación tal como una TPT. El receptor 23060 transmite la firma digital extraída al servidor 23090 de FP. Cuando la firma digital coincide con una firma del extractor 23080, el receptor 23040 puede recibir un activador o activadores como una respuesta. Cuando el activador o activadores recibidos tienen el nuevo locator_part descrito en lo anterior o una TPT o tabla de parámetro de aplicación de una nueva versión se descubre, el receptor 22040 puede solicitar al servidor 23060 de TPT descargar una nueva TPT o tabla de parámetros de aplicación.
El servidor 23070 de contenido puede proporcionar aplicaciones y TDO necesarios para proporcionar servicios interactivos. Cuando una nueva aplicación o TDO se necesita, la nueva aplicación puede descargarse utilizando un URL y tabla de parámetros de aplicación.
El extractor 23080 de firma puede recibir metadatos desde el difusor 23010. El extractor 23080 de firma puede extraer la firma de una trama desde los metadatos recibidos. Cuando la firma digital transmitida al servidor 23090 de FP coincide con la firma del extractor 23080 de firma, el extractor 23080 de firma puede distribuir los metadatos relacionados con la firma al servidor 23090 de FP.
El servidor 23090 de FP puede realizar una operación de coincidencia de firma con el extractor 23080 de firma. El servidor 23090 de FP puede coincidir la firma con la firma digital recibida desde el receptor 23040. Cuando la firma coincide con la firma digital, el servidor 23090 de FP puede recibir los metadatos relacionados con la firma desde el extractor 23080 de firma. El servidor 23090 de FP puede transmitir los metadatos al receptor 23040.
En el procedimiento de firma digital (FP), el Cliente 23050 de FP puede extraer firmas digitales (también pueden llamarse firmas) desde las tramas de audio o video y revisar las firmas digitales contra la base de datos de firmas digitales de tramas de difusión desde múltiples difusores en el área para encontrar la información que los receptores 23040 necesitan. Tales revisiones pueden realizarse por firmas a un servidor remoto y obtener de regreso un registro con la información deseada, o en algunos casos puede hacerse al revisar contra una base de datos de firmas que se han descargado dentro del receptor 23040. Aquí, el servidor remoto puede tener un servidor 23090 de FP.
Aunque las marcas de agua y firma digital pueden ser teenologías distintas, no se excluyen necesariamente una de la otra. Utilizando una combinación de las dos tecnologías es bastante imaginable. El término reconocimiento de contenido automático (ACR) puede utilizarse para denominar a cualquiera de estas tecnologías de forma separada o cualquier combinación de las mismas.
Un entorno en el que un receptor solamente tiene acceso a audio y video sin comprimir desde la corriente de difusión también se llama como un "entorno de ACR".
En ambos casos de WM y FP los receptores puede utilizar el URL como un punto de inicio para obtener contenido de servicio interactivo, incluyendo activadores.
En ambos casos WM y FP la información de temporización puede encontrarse en la forma de una marca de tiempo en relación a un reloj lateral de difusión que se utiliza para la especificación de temporización de eventos críticos para el canal, tal como marcas de tiempo de activación en activadores distribuidos a través de la Internet.
Se asume que los difusores pueden soportar típicamente la distribución de servicios interactivos directamente en la corriente de difusión, para el beneficio de los receptores que pueden obtener señales de televisión desde las antenas, y también soportan la distribución de servicios interactivos a través de la Internet como se describe en lo anterior, para beneficio de los receptores que obtiene audio y video sin comprimir, pero tienen una conexión a Internet. Sin embargo, los difusores pueden soportar cualquiera de estos dos mecanismos de distribución sin el otro.
Una arquitectura tipica para el procedimiento de marca de agua en el caso cuando la marca de agua proporciona solamente un valor de código deberá verse como una combinación de dos arquitecturas en la Figura 22 y Figura 23. Podría existir un Insertor de Marca de agua, como en la Figura 22, pero podría insertar un código, en lugar de la información necesaria para los receptores. También podría encontrarse un Servidor WM, desempeñando el mismo rol que el Servidor FP en la Figura 23. Los receptores podrían enviar sus códigos, en lugar de firmas, y podrían obtener la información que necesitan de regreso.
Se hará una descripción para acceder a los servicios interactivos.
La descripción de los servicios interactivos de acceso incluye descripciones del Modelo de Ejecución Directo, Modelo TDO con Activaciones Independientes para el Servidor ACR, Modelo TDO con Activaciones recibidas desde el servidor ACR. Mientras los modelos no se muestran, los modelos no se limitan a las descripciones y pueden cambiar de acuerdo con la intención de un diseñador.
Existe un número de formas diferentes para un receptor en un entorno de ACR para acceder a servicios interactivos, dependiendo en las elecciones del difusor y la naturaleza del sistema ACR. El modelo de servicio interactivo puede ser el modelo Ejecución Directa o el modelo TDO, y Activación en el caso del modelo TDO, Activadores pueden distribuirse independientemente del Servidor ACR, o pueden distribuirse por el Servidor ACR.
Se dará una descripción del Modelo de Ejecución Directa.
Un proceso de ACR para un canal virtual que contiene un servicio interactivo el cual es el Modelo de Ejecución Director puede proporcionar a los receptores ver ese canal para ver el equivalente de Activadores de Tiempo Base que incluye el término media_time ("m=") y el término content_id ("c="). Estos Activadores pueden identificarse como Activadores por un servicio interactivo con el modelo Ejecución Directa.
Cuando un receptor recibe primero tal Activador con una nueva locator_part, puede esperarse que la cargue en su navegador Objeto Declarativo (DO) señalado por locator_part del Activador. Típicamente, el DO habrá sido pre-instalado o descargado previamente y almacenado en la memoria temporal.
De otra forma, podría esperare que el receptor descargue el mismo, utilizando una solicitud de HTTP GET.
Entonces, el DO puede contactar al servidor de cabecera apropiado y proporcionar el servicio interactivo cuando se dirige por el servidor de cabecera.
Puede esperarse que el receptor haga que el Activador inicial y los Activadores subsiguientes se encuentren disponibles para el DO cuando se obtienen hasta el momento en que obtiene un Activador desde el servidor ACR que tiene un nuevo locator_part y/o que se identifica como un Activador para un servicio interactivo con el modelo TDO (cualquiera de los cuales indica típicamente un cambio de canal).
Se hará una descripción del Modelo TDO con Activaciones Independientes del Servidor ACR.
Un proceso de ACR para un canal virtual que puede contener un servicio interactivo al cual tiene el modelo TDO, y el cual proporciona activaciones de evento independientemente del Servidor ACR, puede proporcionar a los receptores la visualización del canal equivalente de Activadores de Tiempo Base que pueden incluir el término media_time ("m="). Estos Activadores pueden identificarse como Activadores para un servicio interactivo con el modelo TDO.
Cuando un receptor recibe primer primero un Activador con un nuevo locator_part, puede esperarse que recupere la Tabla de Parámetros TDO actual (TPT) desde el Servidor TPT puede señalarse por el locator_part del Activador, y utilizar el tiempo de medios en el que Activador y Activadores subsecuentes establecen un tiempo base de referencia para las activaciones de evento, en relación a las tramas de audio o video pueden identificarse por el proceso ACR.
Si un AMT (Tabla de Mensajes de Activación) se distribuyen junto con la TPT, el receptor puede esperar utilizar los elementos Activación individuales en la tabla para activar eventos en los momentos correctos en relación al tiempo base establecido por los términos de tiempo de medios en los Activadores. (Estos eventos pueden incluir cargar y ejecutar una TDO, provocando que una TDO tome una acción sincronizada particular, suspender una TDO, etc.).
Si un elemento LiveTrigger se incluye en la TPT, puede esperarse que el receptor recupere Activadores de Activación desde Live Servidor de Activador identificado por el URL en el elemento LiveTrigger, utilizando el método de sondeo señalado en el elemento LiveTrigger, y utilizar estos Activadores de Activación para activar eventos en los tiempos correctos en relación al tiempo base establecido por los términos de tiempo de medios en los Activadores.
Ambos de un AMT y un Live Servidor de Activador pueden utilizarse para el mismo servicio, típicamente con el primero proporcionando activaciones estáticas y el último proporcionando activaciones dinámicas. Alternativamente, un AMT puede utilizarse sólo cuando todas las activaciones para los segmentos son estáticas, o un Servidor de Activador en Vivo puede utilizarse sólo para distribuir ambas activaciones estática y dinámica.
Se dará una descripción del Modelo TDO con Activaciones Recibidas desde el servidor ACR.
Se describirá como los activadores de activación para un modelo de servicio interactivo se distribuyen sin un servidor de activador separado en un entorno de ACR.
Los sistemas de ACR de firma digital pueden incluir un servidor ACR. Los receptores pueden enviar firmas de trama a un servidor ACR, y el servidor de ACR puede identificar la trama representada por la firma y enviar de regreso la información necesaria a los receptores. Los sistemas de ACR de marca de agua pueden incluir un servidor de ACR en el caso donde las marcas de agua no incluyen más que los códigos que pueden enviarse a un servidor ACR para obtener información necesaria por los receptores. Los sistemas de ACR de marca de agua pueden incluir un servidor de ACR en el caso donde las marcas de agua mismas contienen la información necesaria por los receptores. En aquellos sistemas de ACR que incluyen un servidor de ACR, dos modelos diferentes pueden utilizarse para la comunicación entre los servidores de ACR y los receptores; un modelo de solicitud/respuesta y un modelo dirigido por evento.
Se asume que el difusor soporta el modelo de interacción de TDO.
Tres casos de un servidor de ACR utilizando un modelo de solicitud/respuesta, un servidor ACR utilizando un modelo dirigido por evento y un sistema de ACR de marca de agua inserta información directamente para asumirse.
En el caso de un servidor ACR, el método de ACR podría ser firma digital, en cuyo caso los receptores calculan algún tipo de firma (o firma digital) de tramas de audio o video y enviar las mismas a un servidor de ACR para su identificación, o podrían ser marcadas con agua, en cuyo caso los receptores extraen códigos en la forma de marcas de agua desde las tramas de audio o video y envía los códigos a un servidor de ACR para identificación.
Los términos de firmas digitales se describen para conveniencia. Sin embargo, el sistema opera de la misma manera que el caso de los códigos de marca de agua y la presente invención no se limita a firmas digitales.
La Figura 24 es un diagrama que muestra un ejemplo de activación estática en un caso de ACR de solicitud/respuesta.
Se dará una descripción en un caso en el que el servidor de ACR utiliza el modelo de solicitud/respuesta.
En el modelo de ACR de solicitud/respuesta, el receptor puede esperar generar firmas del contenido periódicamente, (por ejemplo, cada 5 segundos, lo cual es simplemente ejemplar y puede cambiarse por un diseñador) y envía solicitudes que contiene firmas al servidor de ACR. Cuando el servidor de ACR obtiene una solicitud desde un receptor, puede regresar una respuesta. La sesión de comunicaciones puede no mantenerse abierta entre las instancias de solicitud/respuesta. En este modelo, puede no ser factible para el servidor de ACR inicie mensajes con el cliente.
Para un servidor de ACR que utiliza este modelo de solicitud/respuesta y distribuye Activadores de Activación a los receptores, cada respuesta desde el servidor de ACR puede ser una de Nuil o Nulo, Activador de Tiempo Base y Activador de Activación.
Una respuesta Nuil puede indicar que la firma no es reconocida, o (si el Módulo de Ingesta de ACR incluye firmas para las tramas en los segmentos de programas sin servicio interactivo) que las firmas representan una trama que pertenece a un segmento que no tiene un servicio interactivo asociado con ésta. El módulo de ingesta de ACR se describirá a continuación.
Una respuesta de Activador de Tiempo Base puede indicar que no se agendó un evento de activación para para tomar lugar antes de la siguiente solicitud del cliente. Se espera que el cliente utilice el Activadores de Tiempo Base para mantener un reloj de tiempo de medios.
Una respuesta Activador de Activación puede indicar que una activación es la propiedad para tomar lugar pronto, con el tiempo de la activación indicado por el término "t=" en el Activador.
Cuando un recepto obtiene un Activador con una nueva locator_part, puede esperarse descargar la nueva TPT inmediatamente, a menos de que ya haya recuperado la misma utilizando una URLList distribuida con una TPT previa.
Cuando un receptor obtiene un Activador de Activación, puede esperarse activar el evento al momento indicado por el término "t=" en el Activador, relativa reloj de tiempo de medios.
La Figura 24 ilustra como este esquema funciona para la activación estática (o para la activación dinámica cuando el sistema ACR lo adquiere de la activación dinámica con la suficiente anticipación.
En la Figura 24, el receptor puede enviar firmas a las tramas a las cuales el servidor de ACR determina que tienen tiempo de medios MT1, MT2 y MT3. Para la trama con el tiempo de medios MT1 el receptor simplemente obtiene una respuesta que contiene un Activador de Tiempo Base. Para la trama con el tiempo de medios MT2, una activación estática es la propiedad en media__time MTa, de manera que el receptor obtiene una respuesta que contiene una Activador de Activación la cual tiene un término "t= Ta". Para la trama con el tiempo de medios MT3 el receptor solamente obtiene una respuesta que contiene un Activador de Tiempo Base.
Puede ocurrir que un receptor reciba más de un Activador de Activación para la misma activación de evento. Sin embargo, los tiempos de medios para cada uno de ellos serán el mismo, de manera que el receptor puede identificarlos como duplicados, y no aplicar uno de ellos.
La Figura 25 es un diagrama que muestra una modalidad de activación estática en un caso de solicitud/respuesta de ACR.
Se dará una descripción en un caso en el que el servidor de ACR utiliza el modelo de solicitud/respuesta.
En la Figura 25, el receptor puede enviar firmas para tramas vistas en los tiempos LC1, LC2, LC3, etc. de reloj local. El media_time para la trama vista en el tiempo LC1 del reloj local puede determinarse por el servidor de ACR para ser MT1, y el receptor solamente obtiene una respuesta que contiene un Activador sin media_time o event_time. La media_time para la trama vista en el tiempo LC2 de reloj local puede determinarse por el servidor de ACR para ser MT2, y el servidor de ACR sabe que una activación estética es adecuada en media_time MTa, de manera que el servidor de ACR envía una respuesta que contiene un Activador de Activación el cual tiene un término "d=<offset>", lo que significa que media_time MTa para la activación es <offset> en unidades de tiempo después de MT2. El receptor entonces agrega el <offset> al tiempo LC2 y obtiene LCa como el tiempo local que debería activar el evento.
La Figura 26 es un diagrama que muestra una modalidad de activación dinámica en un caso de solicitud/respuesta de ACR.
Se dará una descripción de un caso en el que la activación dinámica ocurre en el caso de solicitud/respuesta de ACR.
Para las activaciones dinámicas en situaciones donde el ACR System no obtiene de la activación del evento hasta que es muy tarde para enviar el Activador al receptor antes de tiempo, el Servidor de ACR necesita esperar hasta la siguiente solicitud, y entonces envía un Activador de Activación. La Figura 26 ilustra este caso. El efecto de esto es que las activaciones dinámicas pueden retardarse tanto como una solicitud de intervalo.
En la Figura 26, el receptor puede enviar firmas para tramas que el servidor de ACR determina que tiene tiempos MT1, MT2 y MT3 de medios. Para las tramas con los tiempos MT1 y MT2 de medios, el receptor solamente obtiene una respuesta que contiene un Activador de Tiempo Base. Cuando una activación dinámica con el tiempo MTa de activación se muestra poco antes de media_time MTa, el servidor de ACR no puede notificar al receptor acerca de éste hasta la siguiente solicitud del receptor, lo cual ocurre para la trama con el tiempo MT3 de medios. En ese momento, la respuesta del servidor de ACR contiene un Activador de Activación con el tiempo MTa de activación (el cual es un poco retrasado), en esta situación puede esperase que el receptor aplique en Activador de Activación tan pronto como llegue.
De nuevo aquí es posible que un receptor reciba más de un Activador de Activación para la misma activación de evento. Sin embargo, el tiempo de medios para cada uno de ellos será el mismo, de manera que el receptor puede identificarlos como duplicados, y no aplicar uno de ellos.
La Figura 27 es un diagrama que muestra una modalidad de activación dinámica en un caso de solicitud/respuesta de ACR.
Se dará una descripción de un caso en el que la activación dinámica ocurre en el caso de solicitud/respuesta de ACR.
En la Figura 27, el receptor puede enviar firmas para tramas vistas en los tiempos LC1, LC2, LC3, etc. de reloj local. El media_time para la trama vista en el tiempo LC1 del reloj local puede determinarse por el servidor de ACR para ser MT1, y el receptor solamente obtiene una respuesta que contiene un Activador sin media_time o event time. El media_time para la trama vista en el tiempo LC2 de reloj local puede determinarse por el servidor de ACR para ser MT2, y el servidor de ACR no sabe que una activación dinámica se mostrará en media_time MTa, de manera que el receptor solamente obtiene una respuesta que contiene un Activador sin media_time o event_time. Cuando una activación dinámica se muestra en media_time MTa, el servidor de ACR no puede notificar al receptor acerca de éste hasta la siguiente solicitud del receptor, lo cual ocurre en el tiempo LC3 local. En ese momento, la respuesta del servidor de ACR puede contener un Activador de Activación con un valor de <offset> negativo o contiene un activador de activación "do it now".
Se dará una descripción de un servidor de ACR utilizando un modelo dirigido por evento.
En el modelo de ACR dirigido por evento puede esperarse que el receptor inicie una conexión permanente con el servidor de ACR, genera firmas del contenido periódicamente (por ejemplo, cada 5 segundos), y envíe las firmas a través de la conexión. El servidor de ACR no responde a cada firma. Puede enviarse un mensaje al receptor cuando se detecta un nuevo segmento o cuando una activación de evento necesita comunicarse al receptor. En este modelo, es posible que el servidor de ACR inicie mensajes para el cliente en cualquier momento.
Para un servidor de ACR que está utilizando este modelo dirigido por evento y distribuye acciones para los receptores, las siguientes reglas pueden aplicarse para los mensajes desde el servidor de ACR.
En primera, cuando el servidor de ACR recibe una firma desde un receptor que corresponde a un nuevo segmento, el servidor de ACR puede enviar un Activador de Tiempo Base al receptor inmediatamente, sólo para habilitar que el receptor obtenga la TPT asociada.
En segunda, cuando el evento es adecuado para activarse, el servidor de ACR puede enviar un Activador de Activación al receptor. Si es posible, puede enviar el Activador de Activación ligeramente adelantado al tiempo en que el receptor necesita aplicar el mismo. (Esto es muy similar al comportamiento en el modelo de solicitud/respuesta). Si el servidor de ACR obtiene la activación muy tarde y no puede enviar un Activador de Activación muy por adelantado (lo cual puede ocurrir en el caso de una activación de evento dinámica), puede enviar una Activador de Activación tan pronto como pueda. En este caso, es posible que el cliente obtenga el mensaje ligeramente después del tiempo de activación, debido a las demoras en los mensajes, en cuyo caso puede esperarse que el receptor active un evento inmediatamente tras la recepción del mensaje.
Cuando un receptor obtiene un Activador con una nueva locator_part, puede esperarse descargar la nueva TPT inmediatamente, a menos de que ya haya recuperado la misma utilizando una URLList distribuida con una TPT previa.
Se dará una descripción de un sistema ACR de marca de agua para que inserte información directamente. Mientras el sistema ACR de marca de agua no se muestre, el sistema de ACR de marca de agua no se limita a la siguiente descripción y puede cambiarse por un diseñador.
En el caso de un sistema de marca de agua que inserta la información a receptores que necesitan directamente, la marca de agua asociada con una trama puede seguir las siguientes reglas como se establece en lo anterior para lo que un servidor de ACR de solicitud/respuesta deberá regresar para la misma trama como sigue. El servidor de ACR de solicitud/respuesta puede regresar uno de Nulo, Activador de Tiempo Base y Activador de Activación.
Una respuesta Nulo puede indicar que la firma no es reconocida, o (si el Módulo de Ingesta de ACR incluye firmas para las tramas en segmentos de programas sin servicio interactivo) que la firma representa una trama que pertenece a un segmento que no tiene un servicio interactivo asociado con ésta.
Una respuesta de Activador de Tiempo Base puede indicar que no se agendó un evento de activación para para tomar lugar antes de la siguiente solicitud del cliente. Se espera que el cliente utilice el Activadores de Tiempo Base para mantener un reloj de tiempo de medios.
Una respuesta Activador de Activación puede indicar que una activación es la propiedad para tomar lugar pronto, con el tiempo de la activación indicado por el término "t=" en el Activador.
En el caso de un sistema ACR de marca de agua que distribuye la información a los receptores necesita incluir lo mismo directamente en la marca de agua, de manera que no se necesita un servidor de ACR, un Ingest Module puede seguir las siguientes reglas como se describe para el modelo del servidor de solicitud/respuesta anterior para determinar el Activador para asociar con cada trama, pero después incluir la Activador en la marca de agua para la trama, en lugar de asociar el Activador con la trama en una Base de Datos. El módulo de ingesta y la base de datos se describirán posteriormente.
Se dará una descripción de soporte de los servicios de NRT individuales. Esto no se muestra pero la presente invención no se limita a la siguiente descripción y puede cambiarse por un diseñador.
Para recibir un entorno de ACR para obtener acceso a servidores de NRT independientes, el difusor puede necesitar soporte de acceso a Internet para los servicios NRT, y el receptor puede necesitar obtener SMT y las instancias de NRT-IT para los servicios.
Se dará una descripción de un protocolo de consulta para obtener tablas de PSIP y tablas de NRT a través del Internet.
Si un difusor soporta este protocolo para una corriente de difusión particular, entonces el receptor que conoce la URL del Signaling Server del difusor para la corriente de difusión puede tomar los siguientes pasos.
Primero, el receptor puede emitir una consulta para el "Basic NRT Set" de las tablas para la corriente de difusión, para un intervalo de tiempo futuro especificado (por ejemplo, las siguientes 12 horas).
Segundo, esto producirá la SMT e ILT para cada uno de los canales virtuales de NRT independientes, y las NRT-IT y las instancias de TF que cubren el intervalo de tiempo especificado.
Una forma en que un receptor puede descubrir la URL del Signaling Server para una corriente de difusión puede ser que el proveedor de un segmento de servicio interactivo en la corriente de difusión pueda elegir proporcionar la URL Signaling Server en un elemento URLList distribuido junto con la TPT.
Otra forma en que un receptor puede distribuir URL de Signaling Servers puede ser una pre-configuración. En la misma forma en que un fabricante del receptor de DTV pueda pre-configurar un receptor de DTV reconocer cómo encontrar un Servidor de ACR que cubre alguna área de difusión en particular, el fabricante de receptor de DTV puede pre configurar un receptor de DTV para saber cómo encontrar un "NRT Discovery Server" que cubre algún área de difusor particular. Tal NRT Discovery Server será capaz de dar al receptor una lista de las corrientes de difusión que contienen servicios de NRT independientes, junto con la URL Signaling Server para cada uno.
La Figura 28 es un diagrama que muestra una modalidad de una arquitectura para activación de servidor de ACR; Algunos sistemas de ACR incluyen un servidor de ACR, y algunos sistemas de ACR no lo hacen. En sistema de ACR de firma digital, los receptores pueden calcular y enviar firmas de trama a un servidor de ACR, y el servidor de ACR puede enviar información de regreso necesaria por los receptores. De este modo, los sistemas ACR de firma digital incluyen un servidor de ACR. En los sistemas de ACR de marca de agua, las marcas de agua pueden contener solamente códigos que identifican de forma única las tramas, o las marcas de agua pueden contener información completa necesaria por los receptores. Cuando las marcas de agua contienen solamente códigos, los receptores pueden extraer los códigos y enviar los mismos a un servidor de ACR, y el servidor de ACR envía la información de regreso necesaria por los receptores. En caso en que las marcas de agua incluyen información completa, los receptores pueden solo extraer la información que necesitan directamente desde las marcas de agua, y no se necesita un servidor de ACR: En aquellos sistemas de ACR que incluyen un servidor de ACR, dos modelos diferentes pueden utilizarse comúnmente para la comunicación entre los servidores de ACR y los receptores: un modelo de solicitud/respuesta y el modelo dirigido por evento.
En el modelo de servidor de ACR de solicitud/respuesta puede esperarse que el receptor calcule las firmas de, o extraer los códigos desde, el contenido periódicamente (por ejemplo, cada 5 segundos) y envíe solicitudes que contienen las firmas o códigos a un servidor de ACR. Cuando un servidor de ACR obtiene una solicitud desde un receptor, puede regresar una respuesta. La sesión de comunicaciones no se mantiene abierta entre las instancias de solicitud/respuesta. En este modelo, puede no ser factible que un servidor de ACR inicie mensajes para un receptor.
Se asume que el difusor del canal procesándose soporta el modelo de interacción de TDO.
Pueden existir dos tipos generales de activaciones de eventos: activaciones estáticas en las que el tubo de activación se conoce antes de la difusión del segmento inicie, y activaciones dinámicas en las que el tiempo de activación se determina dinámicamente como el segmento siendo difundido. En los segmentos pre-grabados todas las activaciones de evento pueden ser estáticas. En los segmentos que se difunden en vivo, algunas o todas las activaciones de evento pueden ser dinámicas. Las activaciones estáticas típicamente se enlistan en una Tabla de Mensajes de Activación (AMT), aunque pueden distribuirse a los receptores en la forma de Activadores de Activación. Las activaciones dinámicas pueden distribuirse en la forma de Activadores de Activación, debido a que su temporización no se conoce al momento en que la AMT se genera.
La Figura 28 muestra una arquitectura para soportar el sistema de ACR que utiliza un servidor de ACR. Esto es un diagrama de bloque lógico, no una arquitectura de implementación. Por ejemplo, el Módulo de Ingesta de ACR podría co-ubicarse con la fuente de difusión, o podría encontrarse en una ubicación separada.
En la arquitectura para soportar los sistemas de ACR que utilizan un servidor de ACR, la arquitectura puede incluir una fuente 28010 de difusión, un módulo 28020 de ingesta de ACR, un MVPD 28030, un STB 28040, un receptor 28050, un cliente de ACR 28060, un servidor 28070 de configuración de ACR, un servidor 28080 de ACR y/o una base de datos 28090.
La Fuente 28010 de Difusión puede ser un punto desde que la corriente de A/V y los servicios interactivos asociados se transmiten, por ejemplo, un punto de distribución de red o una estación de TV.
El Módulo 28020 de Ingesta de ACR puede calcular señales (firmas digitales) o tramas, en el caso de un sistema de ACR de firma digital o insertar marcas de agua que incluye códigos en las tramas, en el caso de un sistema de ACR de marca de agua que se basa en códigos. Este puede almacenar en la base de datos 28090 el media_time de cada trama asociada con una firma o código, junto con otros metadatos. El Módulo 28020 de Ingesta de ACR podría manejar un solo canal en una corriente de difusión, o toda una corriente de difusión, o múltiples corrientes de difusión, o cualquier combinación de los mismos. Para los propósitos, se asume que el Módulo 28020 de Ingesta de ACR procesa las tramas para los segmentos de programa que contienen un servicio interactivo. Sin embargo, es posible tener sistemas de ACR en las que todas las tramas se procesan, pero aquellas que no son parte de un segmento con un servicio interactivo tienen una indicación en su base de datos 28090 de entrada que no son parte de un segmento con un servicio interactivo.
Un Distribuidor de Programa de Video Multiprograma (MVPD) 28030 típicamente es un operador de cable, operador de satélite, o un operador de IPTV. Puede recibir la corriente de difusión desde la Broadcast Source en alguna forma, con las marcas de agua insertadas por el Módulo 28020 de Ingesta de ACR en el caso de un sistema de ACR de marca de agua, tal sistema a menudo retira todos los elementos de programa diferentes a las pistas de audio y video, y envía la corriente resultante a las cajas de convertidor-descodificador (STB) 28040 en las instalaciones del cliente.
La STB 28040 típicamente descodifica (descomprime) el audio y video y envía el mismo a un televisor para su presentación a los espectadores. Se asume que el servicio #6 de Subtítulos de DTV, el cual contiene Activadores de servicio interactivo, no se encuentra disponible para el televisor.
El receptor 28050 puede incluir un cliente 28060 de ACR. El cliente 28060 de ACR puede disponerse fuera del receptor 28050. La estructura del receptor 28050 se describirá posteriormente.
El Cliente 28060 de ACR en el receptor 28050 puede obtener Activadores de Activación desde el Servidor 28080 de ACR y pasar al código receptor principal, utilizando una API proporcionada por este propósito. Normalmente, el cliente 28060 de ACR podría integrarse dentro del receptor 28050, pero son posibles otras configuraciones.
El Servidor 28070 de Configuración de ACR puede proporcionar una forma para los clientes 28060 de ACR para determinar la ubicación de un Servidor 28080 de ACR adecuado. Este proceso de descubrimiento puede lograrse en otras formas.
El Servidor 28080 de ACR puede obtener firmas o códigos desde los receptores y regresar Activadores de Activación gn los momentos apropiados.
La base de datos 28090 puede ser un almacenamiento de datos de algún tipo, no necesariamente una base de datos en el sentido estricto del término, en el cual la información acerca de audio o video (o ambos) se almacena para el uso de los servidores 28080 de ACR.
La arquitectura de un sistema de ACR que utiliza distribución directa de información en marcas de agua podría no tener una Base de Datos y no un Servidor de ACR El Módulo de Ingesta de ACR podría insertar información directamente dentro de las tramas en la corriente de distribución, en la forma de marcas de agua, en lugar de insertarlas, en la solicitud de base de datos que contienen identificadores o tramas y la información asociada con los mismos. Los receptores podrían extraer esta información desde las tramas en la difusión, en lugar de obtener el mismo desde el servidor de ACR.
Se dará una descripción de la distribución de activadores de activación mediante los servidores de ACR de solicitud/respuesta etapa por etapa. Esta es una modalidad de la presente invención y una etapa puede omitirse o nuevas etapas pueden agregarse o una secuencia puede cambiar.
Una forma eficiente para implementar este comportamiento del Servidor de ACR es seguir el proceso descrito a continuación, donde los números de acciones en el proceso corresponden a los números en la arquitectura del diagrama de arquitectura anterior, como se muestra en la Figura 28. 1) La agenda de difusión para los segmentos de servicio interactivo y las AMT o sus equivalentes para cada segmento puede distribuirse al Módulo de Ingesta de ACR antes del momento en que los segmentos se difunden. La agenda de difusión pueden contener el ID de segmento, tiempo de inicio de GPS y tiempo de finalización de GPS de cada segmento que puede contener un servicio interactivo asociado con éste. Si existen cualesquier cambios de último minuto a la agenda de difusión, el Módulo de Ingesta de ACR puede notificarse de estos cambios inmediatamente. La agenda de difusión también podría contener el número de versión de la TPT para cada segmento, y el Módulo de Ingesta de ACR podría obtener notificación en tiempo real de cualquier cambio no agendado en una versión de TPT, de manera que puede insertar términos de "versión" ("v=") en los Activadores cuando sea necesario.
El Ingest Module o Módulo de Ingesta podría también configurarse para insertar los términos "spread" ("s=") en los Activadores en momentos adecuados, tal como durante un intervalo especificado en el inicio de cada segmento (cuando muchos receptores son propensos a solicitar nuevas TPT al mismo tiempo). 2) Si existen cualesquier activaciones dinámicas, pueden establecerse enlaces a partir de las fuentes de activaciones dinámicas al Módulo de Ingesta de ACR. 3) La corriente de difusión podría enrutarse al Módulo de Ingesta de ACR. 4) El Módulo de Ingesta de ACR puede extraer firmas desde las tramas (en el caso de un sistema de ACR de firmas digitales) o insertar códigos en las tramas (en los casos de un sistema de ACR de marca de agua), para todas las tramas contenidas en segmentos que tienen un servicio interactivo asociado con ellas. (El Módulo de Ingesta de ACR puede determinar si una trama se encuentra en tal segmento utilizando en un reloj de GPS y los tiempos de inicio y tiempos de finalización de los segmentos en la agenta de difusión). Para cada una de las tramas en el Módulo de Ingesta de ACR puede insertar un registro en la Base de Datos que puede incluir un Activador y la firma o código asociado con la trama. Las reglas para que Activador se inserta se describe al final de esa lista de acciones en el proceso. 5) Corriente de Difusión puede continuar en el MVPD. 6) MVPD puede enrutar la Corriente de Difusión al STB en la ubicación del suscriptor (retirando típicamente todo el contenido interactivo primero). 7) STB puede codificar el A/V y enviar el A/V sin comprimir al receptor de DTV. 8) Cuando el receptor se enciende primero, puede enviar su ubicación a un Servidor de Configuración de ACR. (El URL del Servidor de Configuración de ACR puede integrarse en el receptor). 9) El Servidor de Configuración de ACR puede enviar de regreso el URL de un Servidor de ACR para el receptor para uso. 10) El Cliente de ACR en el receptor puede iniciar la extracción de firmas digitales o códigos de marcas de agua y enviarlos al Servidor de ACR. 11) Cuando el Servidor de ACR recibe una firma o código, puede intentar coincidiría en la base de datos. 12) Si la firma o código no coincide cualquier firma o código en la Base de Datos, entonces el Servidor de ACR podría regresar un indicador de "sin coincidencia". Si la firma o código no coincide con una firma o código en la Base de Datos, entonces el Servidor de ACR puede obtener de regreso registro para la trama que coincide con la firma o código. En el último caso el registro en la Base de Datos puede contener un Activador de Tiempo Base, y/o puede contener uno o más Activadores de Activación, dependiendo de que se insertó en el registro para la trama por el Módulo de Ingesta de ACR. 13) Si el Servidor de ACR obtiene de regreso un indicador de "no match" desde la Base de Datos, puede regresar una respuesta NULL al Cliente de ACR. De otra manera el Servidor de ACR puede regresar al Cliente de ACR al Activador o Activadores se obtiene.
Las siguientes reglas pueden utilizarse para determinar que Activador o Activadores insertan el Módulo de Ingesta de ACR dentro de cada registro de trama en la Base de Datos.
La Figura 29 es un diagrama que muestra una modalidad de activadores de activación en caso (b) y caso (a) sin EndTime.
Puede asumirse que existe algún limite L1 en la longitud de los intervalos de solicitud utilizados por los clientes de ACR individuales en los receptores. (No es importante si los clientes de ACR saben si este limite es, tan largo como los que operan dentro de él en la práctica). Dejando que L2 sea la longitud de tiempo que toma un cliente de ACR típico en calcular la firma o extraer la marca de agua asociada con la trama, cuenta desde el momento en que la trama llega al receptor. Dejando L3 el tiempo de viaje redondo típico para que un mensaje vaya desde el cliente de ACR a un servidor de ACR y de regreso. Dejar M = L1 + L2 + L3. (Un valor ligeramente mayor M ¿podría utilizarse? la ventaja de un valor ligeramente mayor es que los receptores tienen un poco más de tiempo extra para reaccionar a los Activadores de Activación; la desventaja es que los receptores sean un poco más constantes al obtener múltiples Activadores de Activación para la misma activación de Evento activación ? lo cual no es tanto el problema, debido a que serán capaces de identificar si se duplican, como se explica a continuación, y solamente aplicarán la activación una vez).
El Módulo de Ingesta de ACR puede insertar solamente un Activador de Tiempo Base en el registro asociado con una trama a menos de que una de las siguientes tres condiciones se mantenga: (a) Existe un elemento Activación en la AMT de manera que media_time de la trama se encuentra en un intervalo de tiempo que inicia en una extensión M de tiempo antes de startTime del elemento Activación y termina en endTime del elemento de Activación. (Si un Activación no tiene endTime, el endTime se considera igual al startTime). (b) Un Activador de Activación dinámico se recibe por al menos un Ingest Module antes de que el intervalo de tiempo de la extensión M de tiempo que precede inmediatamente el tiempo de activación del Activador ( "t=<event_time>"), y la trama yace dentro del intervalo. (c) Una Activador de Activación dinámica se recibe por el módulo de Ingesta más tarde que el inicio del intervalo de la extensión M de tiempo que precede inmediatamente el tiempo de activación del Activador, y el media_time de la trama se encuentra en el intervalo de la extensión L1 de tiempo siguiendo inmediatamente la recepción del Activador.
Si cualquiera de las condiciones (a), (b) o (c) se mantienen, entonces una Activador de Activación puede incluirse en el registro, con un término "e=" para identificar el Evento a activarse, y el término "t=" indica el startTime del elemento Activación en la AMT (para la condición (a)) o el event_time del Activador dinámico (para la condición (b)). El Activador también puede contener un término versión ("v=").
La razón para continuar asociar Activadores de Activación con las tramas a través de intervalos desde startTime hasta endTime en caso (a), es acomodar los receptores que unen la parte del canal a través de intervalo.
Observe que este procedimiento no requiere inteligencia extra en la parte del Servidor de ACR. Simplemente regresa al Cliente de ACRe la información que encuentra en LA Base de Datos. Toda la inteligencia puede residir en el Módulo de Ingesta de ACR. Además, los cálculos del Módulo de Ingesta de ACR necesitan hacer puede ser muy simples.
Con este esquema es posible que un receptor pueda obtener más de un Activador de Activación (asociado con diferentes tramas) para la misma activación de evento. Sin embargo, un receptor puede observarse fácilmente desde los valores "t=" que todos tienen el mismo tiempo de activación, de manera que el receptor puede determinar que se duplican y el evento se activa solamente una vez.
En dos de las situaciones anteriores el término "t=" en el Activador de Activación puede tener un event_time antes que el media_time de la trama con la que se asocia. En la situación (a), si el endTime del elemento Activación es significativamente posterior que el startTime, entonces un receptor podría obtener típicamente múltiples Activadores de Activación a través del intervalo entre el startTime y el endTime, y estos podrían tener startTime como el tiempo de activación. En la situación (c), los Activadores de Activación para la activación podrían insertarse dentro de los registros de la trama tan tarde que el Activador de Activación que un receptor obtiene pueden llegar en respuesta a una solicitud con una firma para una trama que tiene media_time después del tiempo de activación. Cuando el receptor obtiene un Activador de Activación con un event_time antes que el media_time de la trama con la que asocia, puede esperarse que active el evento inmediatamente, a menos de que lo conozca como un duplicado de un Activador de Activación que ya se ha visto y utilizado para activar el evento.
El propósito de utilizar los valores de event_time en el pasado, en lugar de los Activadores "do it now", para la situación cuando el media_time de la trama es posterior al tiempo de event_activation es debido a que receptor puede obtener más de uno de estos Activadores de Activación "after the fact" (después del hecho). Los valores "t=" permiten al receptor determinar que todos tienen el mismo tiempo de activación, y activar el evento solamente una vez.
La Figura 29 ilustra la situación (b) y la situación (a) cuando el elemento Activación y la AMT no tiene un atributo de endTime.
La Figura 29 muestra un ejemplo de la situación (a) en la acción (4) anterior, en el caso cuando el elemento Activación y la AMT no tiene un endTime. Esto también puede ser un ejemplo de la situación (b) en la etapa (4) anterior, donde el Módulo de Ingesta de ACR se envía a un Activador de Activación dinámico al menos M unidades de tiempo antes de su tiempo de activación.
La Figura 29 muestra un tiempo de activación de evento sobre la línea de tiempo, con un intervalo de tiempo que abarca los intervalos de longitud de Ll, L2, y L3. Las flechas verticales debajo en la línea de tiempo muestran los tiempos de las tramas individuales. Cada trama que precede el inicio del intervalo de la longitud M, o sigue el tiempo de activación del evento, podría asociarse con ésta en la Base de Datos una Activador de Tiempo Base. Cada trama dentro del intervalo de longitud M podría tener asociado con ésta en la Base de Datos un Activador de Activación, de manera que los dos ejemplos (fl, f2) tal como la parte inferior de la figura. El término "t=" para cada trama debe indicar el tiempo de activación de evento con relación a media_time (indicado por el fl y f2 marcado).
Cuatro flechas verticales encerradas en un círculo pueden representar un ejemplo cuando un receptor típico envía una solicitud. En este ejemplo el receptor podría obtener dos Activadores de Activación para la misma activación de evento, pero podrían tener los mismos momentos de activación de evento, de manera que el receptor podría reconocerlos como duplicados y aplicar solamente el primero. Debido a que el intervalo entre la solicitud del receptor es menor que Ll, el receptor se garantiza para hacer al menos una solicitud con una firma para una trama en el intervalo Ll mostrado en el diagrama. Esto le da tiempo para calcular la firma, envía la solicitud al servidor de ACR, u obtiene el Activador de Activación de regreso en respuesta, todo antes del tiempo de activación. En este ejemplo, el primer Activador de Activación que el receptor obtiene podría distribuirse bien antes de tiempo; el segundo Activador de Activación que el receptor obtiene podría apenas llegar en tiempo (es un duplicado).
La Figura 30 es un diagrama que muestra una modalidad de activadores de activación en caso (b) y caso (a) sin EndTime.
Se da una descripción de activadores de activación en caso (b) y caso (a) sin EndTime.
La Figura 30 muestra un ejemplo de la situación (a) en la acción (4) anterior, en el caso cuando el elemento Activación en la AMT no tiene un endTime. Esto también es un ejemplo de la situación (b) en la etapa (4) anterior, donde el Módulo de Ingesta de ACR se envía a un Activador de Activación dinámico al menos M unidades de tiempo antes de su tiempo de activación.
La Figura 30 muestra un tiempo de activación de evento sobre la línea de tiempo, con un intervalo precedente de longitud M abarcando los intervalos de longitud de Ll, L2, y L3. Las flechas verticales debajo en la línea de tiempo muestran los tiempos de las tramas individuales. Cada trama que precede el inicio del intervalo de la longitud M, o sigue el tiempo de activación del evento, podría tener asociado con ésta en la Base de Datos un Activador sin términos <media time> o <event time>. Cada trama dentro del intervalo de longitud M podría tener asociado con éste en la Base de Datos un Activador de Activación, de manera que los dos ejemplos en la parte inferior de la figura. El término "d=" para cada trama podría indicar la longitud de tiempo entre la trama y el evento de activación de tiempo (indicado por el círculo fl y f2).
Cuatro flechas verticales encerradas en un círculo pueden representar un ejemplo cuando un receptor típico envía una solicitud, en este ejemplo el receptor podría obtener dos Activadores de Activación para la misma activación de evento, pero los tiempos de estimación calculados agregado al valor <dl> al tiempo local del receptor para la trama fl o agregar el valor <d2> al receptor de la trama f2 ambos dan el mismo resultado, de manera que el receptor podría reconocerlos como duplicados y aplicar solamente el primero. Debido a que el intervalo entre la solicitud del receptor es menor que Ll, el receptor se garantiza para hacer al menos una solicitud con una firma para una trama en el intervalo Ll mostrado en el diagrama. Esto le da tiempo para calcular la firma, envía la solicitud al servidor de ACR, y obtiene el Activador de Activación en respuesta, todo antes del tiempo de activación. En este ejemplo, el segundo Activador de Activación recibido por el receptor podría llegar después del punto de activación.
La Figura 31 es un diagrama que muestra una modalidad de activadores en caso (a) con EndTime.
La Figura 31 ilustra la situación (a) en la acción (4) anterior, en el caso cuando el elemento Activación en la A T tiene un endTime, asi como un startTime.
La figura muestra un startTime y endTime de activación de evento sobre la linea de tiempo, con un intervalo de longitud M presidiendo el startTime. Las flechas debajo de la linea de tiempo muestran los tiempos de tramas individuales. Cada trama que precede el inicio del intervalo de longitud M, o sigue el endTime de activación del evento, podría asociarse con ellos en Base de Datos un Activador de Tiempo Base. Cada trama dentro del intervalo de longitud M o entre el startTime y endTime de la activación de evento podría tener un Activador de Activación asociado con éste en la Base de Datos, en la forma mostrada en los tres ejemplos en la parte inferior de la figura. El término "t=" para cada trama puede indicar que el tiempo de activación del evento, relativo a línea de media_time (indicada por fl, f2 y f3 encerradas por un círculo).
Tres flechas verticales encerradas en un círculo pueden representar un ejemplo cuando un receptor típico envía una solicitud.
En ese caso el receptor podría obtener tres Activadores de Activación para la misma activación de evento, pero los momentos de activación podrían ser para los mismos, de manera que el receptor podría reconocerlos como el mismo como duplicado y aplicar solamente el primero.
Desde luego los primeros dos Activadores de Activación mostrados en el diagrama podrían no observarse del todo por un receptor que une el canal después de startTime y envía la firma de la trama f3 con su primera solicitud.
La Figura 32 es un diagrama que muestra una modalidad de activadores de activación en el caso (a) con EndTime.
Se da una descripción de activadores de activación en el caso (a) con EndTime.
La Figura 32 ilustra la situación (a) en la acción (4) anterior, en el caso cuando el elemento Activación en la AMT tiene un endTime, así como un startTime.
La figura muestra un startTime y endTime de activación de evento sobre la línea de tiempo, con un intervalo de longitud M precediendo el startTime.
Las flechas debajo de la línea de tiempo muestran los tiempos de tramas individuales.
Cada trama que precede el inicio del intervalo de la longitud M, o sigue el endTime de activación del evento, podría tener asociado con ésta en la Base de Datos un Activador sin términos <media_time> o <event_time>.
Cada trama dentro del intervalo de longitud M podría tener un Activador 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 trama podría indicar la longitud de tiempo entre la trama y el tiempo de activación de evento (indicado por las flechas verticales encerradas).
Las flechas verticales encerradas pueden representar un ejemplo cuando un receptor típico envía una solicitud.
En este caso, el receptor podría obtener tres Activadores de Activación para la misma activación de evento, pero los momentos de activación calculados al agregar el valor <dl> al tiempo local del receptor para la trama fl o al agregar el valor <d2> al tiempo local del receptor de la ama f2 o agregar el valor <d3> (negativo) al tiempo local del receptor de la trama f3 puede dar el mismo resultado, de manera que el receptor reconocerá la misma como duplicado y solamente se aplicará la primera.
Desde luego los primeros dos Activadores de Activación mostrados en el diagrama podrían no observarse del todo por un receptor que une el canal después de startTime y envía la firma de la trama f3 con su primera solicitud.
La Figura 33 es un diagrama que muestra una modalidad de activadores de activación para el caso (c).
La Figura 33 ilustra la situación (c) en la acción (4) anterior, donde un Activador de Activación dinámico se envía a Módulo de Ingesta de ACR después que M unidades de tiempo antes del Tiempo de Activación.
La Figura 33 muestra un tiempo de activación de evento dinámica sobre la línea de tiempo, y un tiempo que precede cortamente el tiempo de activación de evento cuando el Módulo de Ingesta de ACR obtiene de la activación de evento, con un intervalo de longitud L1 que sigue el tiempo cuando el Módulo de Ingesta de ACR obtiene la activación de evento. Las flechas verticales debajo en la línea de tiempo muestran los tiempos de las tramas individuales.
Cada trama precede el inicio de un intervalo de longitud Ll, o sigue el final del intervalo de longitud de Ll, podría tener un Time Base Activador aislado con este en la Base de Datos.
Cada trama dentro del intervalo de longitud Ll podría tener un Activador 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 trama puede indicar el tiempo de activación del evento, relativo a la línea de tiempo de medios (indicada por las flechas verticales encerradas).
Las flechas verticales encerradas pueden representar un ejemplo cuando un receptor típico envía una solicitud.
En este caso el receptor podría solo un Activador de Activación para la activación de evento.
Debido a que el tiempo de activación del Activador de Activación precede el tiempo en que se reciben, el receptor podría aplicar al Activador inmediatamente tras la recepción.
La Figura 34 es un diagrama que muestra una modalidad de activadores de activación para el caso (c).
Se dará una descripción de los activadores de activación para el caso (c) La Figura 34 ilustra una situación (c) en acción (4) anterior, en donde un Activador de Activación dinámico se envía a Módulo de Ingesta de ACR después de M unidades de tiempo después de Activación Time.
La Figura 34 muestra un tiempo de activación de evento dinámico sobre la línea de tiempo, y un tiempo que precede cortamente el tiempo de activación de evento cuando el Módulo de Ingesta de ACR obtiene la actuación del evento, con un intervalo de longitud M siguiendo el tiempo cuando el Módulo de Ingesta de ACR obtiene la activación del evento. Las flechas debajo de la línea de tiempo muestran los tiempos de tramas individuales. Cada trama precede el inicio del intervalo de longitud M, ó que sigue el final del intervalo de longitud M, deberá tener un Activador en Base de Datos sin los términos <media_time> o <event_time>. Cada trama dentro intervalo de longitud M deberá tener un Activador de Activación en la Base de Datos, tales como aquellos en los ejemplos en la parte inferior de la Figura. El término "d=" para cada trama podría indicar la longitud de tiempo entre esa trama y el tiempo de activación de evento (indicado por las flechas verticales encerradas). Las flechas verticales encerradas pueden representar un ejemplo cuando un receptor típico envía una solicitud. En este caso, el receptor deberá obtener dos Activadores de Activación para la misma activación de evento, pero los tiempos de activación calculados al agregar el valor <dl> (negativo) al tiempo local del receptor para la trama fl y agregar el valor <d2> (negativo) al tiempo local del receptor de la trama f2 ambos dando el mismo resultando, de manera que receptor los reconocerá como duplicados, y solamente aplicará el primer recibido. Puesto que el tiempo de activación del primer Activador se recibió antes de tiempo, el receptor podría aplicar el Activador inmediatamente cuando se reciba.
La Figura 35 es un diagrama que muestra una modalidad de activadores de activación dinámicos distribuidos en Last Minute.
En el modelo de ACR dirigido por evento, puede esperarse que el receptor inicie una conexión persistente con servidor de ACR, genere firmas asociadas con las tramas en intervalos regulares (por ejemplo, cada 5 segundos), y envíe las firmas a través de la conexión. El servidor de ACR no responde a cada firma. Puede enviar un mensaje al receptor cuando se detecte un nuevo segmento o cuando se necesite comunicar una activación de evento al receptor. En este modelo, es posible para el servidor de ACR iniciar mensajes para el cliente en cualquier momento a través de la conexión persistente.
Además, es directo para el servidor mantener una cierta cantidad de información acerca de cada receptor, tal como el ID de segmento (<locator_part> de un Activador) que corresponde al envió más reciente del receptor y los Activadores de Activación recientes enviados al receptor.
Para un servidor de ACR que utiliza este modelo dirigido por evento y distribuye las activaciones a los receptores, pueden aplicare las siguientes reglas para los mensajes del servidor de ACR.
En primer lugar, cuando el servidor de ACR recibe una firma de un receptor que corresponde a una trama en un nuevo segmento, el servidor de ACR puede enviar un mensaje al receptor con un Activador de Tiempo Base inmediatamente, para permitir al receptor obtener el TPT asociado.
En segundo lugar, cuando el servidor de ACR recibe una firma de un receptor que corresponde a una trama en una parte de un segmento que tiene un nuevo número de versión para el TPT (diferente a la versión más reciente que el receptor ha observado), el servidor de ACR puede enviar un mensaje inmediatamente al receptor con un Activador de Tiempo Base que tiene un término "v=" para permitir al receptor obtener la nueva versión del TPT asociado.
En tercer lugar, cuando un evento es adecuado para activarse, el servidor de ACR puede enviar un Activador de Activación al receptor. Si es posible, puede enviar el Activador de Activación ligeramente antes de tiempo cuando el receptor necesite aplicarlo, con un término "t=" en el Activador de Activación para indicar el tiempo de activación relativo a la linea de tiempo de medios. (Esto es muy similar al comportamiento en el modelo de solicitud/respuesta). Si el servidor de ACR obtiene la'activación muy tarde que no puede enviar un Activador de Activación antes de tiempo como es usual, puede enviar un Activador de Activación tan pronto como lo adquiera de la activación. (En este último caso, el receptor puede obtener un Activador de Activación después de su tiempo de activación, en cuyo caso puede esperarse activar el evento tan pronto como obtenga el Activador de Activación).
La arquitectura para el caso de Solicitud/Respuesta mostrado en la Figura 28 también es adecuada para este caso Evento Dirigido, con una diferencia. La diferencia es que para el caso Dirigido puede existir una nueva acción (2a). Si existen algunos Activador de Activación dinámicos, entonces las conexiones pueden establecerse entre el Módulo de Ingesta de ACR y todos ACR Servidores que utilicen la Base de Datos llena por el Módulo de Ingesta de ACR, de manera que el Módulo de Ingesta de ACR puede enviar Activador de Activación dinámicos seleccionados a los ACR Servidores.
Las acciones numeradas para el caso Dirigido pueden ser similares a aquellas para el caso Solicitud/Respuesta. Aunque la nueva acción (2a), la acción (4) es un poco diferente, la acción (13) es un poco diferente, y una nueva acción (14) se agrega.
En la acción (4) el Módulo de ingesta de ACR puede extraer las firmas desde las tramas (en el caso de un sistema de ACR de ¿?) o insertar códigos en las tramas (en el caso de un sistema de ACR de marca de agua), para todas las tramas contenidas en segmentos que tienen un servicio interactivo asociado con ellas. (El Módulo de Ingesta de ACR puede determinar si una trama se encuentra en tal segmento al utilizar un reloj de GPS y los tiempos de inicio y los tiempos de finalización de los segmentos en la agenda de difusión). Para cada trama, el Módulo de Ingesta de ACR puede insertar un registro en la Base de Datos que puede incluir la firma o código asociados con la trama y un Activador. El Activador incluido en el registro por el Módulo de Ingesta de ACR puede ser un Activador de Tiempo Base a menos de que al menos una de las siguientes dos condiciones contenga: (a) Existe un elemento Activación en la AMT de manera media_time de la trama se encuentra en el intervalo de tiempo que inicia en la expansión M de tiempo antes de startTime del elemento Activación y termina en el endTime del elemento Activación. (Si una activación no tiene endTime, el endTime se considera igual al startTime). (La misma condición (a) para el modelo ACR de Solicitud/Respuesta). (b) Un Activador de Activación dinámico se recibe en el Módulo de Ingesta antes de que el intervalo de tiempo de la expansión M de tiempo que precede inmediatamente el tiempo de activación del Activador ( "t=<event_time>"), y la trama yace dentro del intervalo. (Igual que en la condición (b) para el modelo ACR de Solicitud/Respuesta) Si cualquiera de las condiciones (a) o (b) se mantiene, entonces un Activador de Activación puede incluirse en el registro, con un término "e=" para identificar el evento a activarse, y un término "t=" para indicar startTime del elemento Activación en la AMT (para la condición (a)) o el event_time del Activador dinámico (para la condición (b)).
Si se recibe un Activador de Activación dinámico por el Módulo de Ingesta durante el intervalo de expansión M de tiempo que precede inmediatamente al tiempo de activación del Activador (en donde M tiene el mismo significado que en el caso del servidor de solicitud/respuesta), entonces el Módulo de Ingesta puede pasar al Activador de Activación en todos los ACR Servidores que utilizan la Base de Datos en las que el Módulo de Ingesta puede insertar los registros, sin poner nada en la Base de Datos que concierne al Activador de Activación dinámico. (Variaciones en esta arquitectura son posibles en las que los Activadores de Activación dinámicos pasan directamente desde las fuentes de Activador de Activación dinámicos hasta los servidores de ACR sin ir hacia el Ingest Modelo, pero los servidores de ACR obtienen los Activador de Activación dinámicos que llegan antes de M unidades de tiempo antes de tiempo de activación, de manera que puede enviar un mensaje a los receptores relevantes receivers inmediatamente. Puede ser muy tarde si se espera a los siguientes envíos del receptor).
En la acción (13), si el ACR Servidor obtiene de regreso un indicador "no match" desde la Base de Datos después de no recibir uno para el envío inmediatamente precedente, puede enviar un mensaje NULL al receptor. Si se obtiene de regreso un Activador con un <locator_part> que es diferente al <locator_part> obtiene de regreso para el envío precedente inmediatamente, puede enviar el Activador al receptor, en ambos casos esto puede decir que el receptor que cualquiera que sea el canal que se está viendo ha cambiado, o el segmento siendo visto ha llegado a su final, de manera que el receptor puede terminar cualquier TDO que se está ejecutando actualmente, y si es necesario descargar una nueva TPT. Si el ACR Servidor obtiene de regreso uno o más Activadores de Activación, puede enviarlos al receptor, descargando cualquiera que sea duplicados de Activadores de Activación que ya se han enviado al receptor. De otra forma, el ACR Servidor podría no hacer nada.
En una nueva acción (14), si un ACR Servidor recibe un Activador de Activación dinámico, puede compare el <locator_part> de los Activador de Activación dinámicos con el <locator_part> actual para cada uno de sus clientes ACR (en donde <locator_part> actual para un cliente es <locator_part> del Activador que el ACR Servidor obtiene de la Base de Datos para el envío más reciente desde el cliente ACR. Para cada cliente en donde <locator_part> coincide, el ACR Servidor puede enviar el Activador de Activación al cliente.
Las Figuras 29 y 31 muestran el manejo de los Activadores para activaciones estáticas y para activaciones dinámicas que se distribuyen por el Módulo de Ingesta de ACR al menos M unidades de tiempo antes de su tiempo de activación. La diferencia es que el ACR Servidor puede descargar Activadores de Activación duplicados, en lugar de enviarlos a los receptores.
La Figura 35 muestra un ejemplo del manejo de un Activador de Activación dinámico recibido en un aviso corto (menor a M unidades de tiempo antes de su tiempo de activación).
La Figura 35 muestra un tiempo de activación de evento dinámico anterior a la línea de tiempo, y un tiempo que precede en forma corta el tiempo de activación de evento cuando el Módulo de ingesta de ACR obtiene la activación del evento. Las flechas verticales debajo de la línea de tiempo muestran los tiempos de las tramas individuales. Tan pronto como el he ACR Servidor recibe el Activador de Activación desde el Módulo de Ingesta de ACR, puede enviar el Activador de Activación a todos los receptores que están viendo actualmente el segmento asociado con el Activador de Activación (como se identifica por el <locator_part> del Activador).
La Figura 36 es un diagrama que muestra una modalidad de activadores de activación dinámicos distribuidos en Last Minute o Último Minuto.
Se dará una descripción de activadores de activación dinámicos distribuidos en Último Minuto.
La Figura 36 muestra un ejemplo del manejo de un a Activador de Activación dinámico recibido en un aviso corto (menos de M unidades de tiempo antes de su tiempo de activación).
La Figura, Activadores de Activación Dinámicos Distribuidos en Último Minuto, muestra un tiempo de activación de evento dinámico sobre la línea de tiempo, y un tiempo que precede de forma corta el tiempo de activación de evento cuando el Módulo de Ingesta de ACR obtiene la activación del evento. Las flechas abajo de la linea de tiempo muestran los tiempos de tramas individuales. Tan pronto como el ACR Servidor recibe el Activador de Activación del Módulo de Ingesta de ACR, puede enviar el Activador de Activación a todos los receptores que están viendo actualmente segmento asociado con el Activador de Activación (como se define por el <locator_part> del Activador). Para cada receptor se ajusta el event_time del Activador a un <delay_time> relativo a la trama que corresponde a la firma enviada más recientemente desde el receptor.
La Figura 37 muestra un diagrama de secuencia entre un cliente de ACR y otros servidores en un caso de ACR de solicitud/respuesta.
La Figura 37 muestra a diagrama de secuencia de acuerdo con una modalidad de transmitir efectivamente un activador y un TPT de acuerdo con el protocolo de operación del servidor de ACR y el receptor (cliente de ACR) en el modelo de solicitud/respuesta.
Una operación ejemplar del modelo de solicitud/respuesta en el orden de solicitud y respuesta se describirá ahora.
El diagrama de secuencia entre el cliente de ACR y otros servidores en un caso de ACR de solicitud/respuesta puede incluir solicitud 1 de ACR (S37010), respuesta 1 de ACR (S37020), solicitud 2 de ACR (S37030), respuesta 2 de ACR (S37040), solicitud 1 de HTTP (S37050), respuesta 1 de HTTP (337060), solicitud 2 de HTTP (S37070), respuesta 2 de HTTP (S37080), solicitud 3 de ACR (S37090), respuesta 3 de ACR (S37100), solicitud 4 de ACR (S37110) y/o respuesta 4 de ACR (337120). solicitud 1 de ACR (S37010) es una etapa en la que el receptor transmite la firma de un programa visto actualmente en un servidor. El servidor puede ser el servidor de ACR descrito en lo anterior. La firma puede ser una firma de firma digital o una marca de agua. respuesta 1 de ACR (S37020) es una etapa en la que el servidor de ACR regresa NULL cuando la firma no se reconoce o un servicio interactivo relacionado no se encuentra presente. Esto puede ser un caso que corresponde al caso mencionado en lo anterior en el que se regresa una respuesta NULL.
La solicitud 2 de ACR (S37030) es una etapa en la que, cuando el canal o programa cambian, el receptor transmite la firma del programa cambiado al servidor de ACR. respuesta 2 de ACR (S37040) es una etapa en la que el servidor de ACR regresa un activador (por ejemplo xbc.com/tpt504) que incluye una dirección por la que un servicio interactivo relacionado con el programa correspondiente puede obtenerse. Esta etapa puede corresponder a un caso en el que la firma se reconoce y un servicio interactivo relacionado se encuentra presente, respuesta 1 de ACR sin enlace (S37020). Es decir, un activador se encuentra disponible en esta etapa. En este caso, el activador regresado puede ser un activador basado en tiempo que no tiene información acerca de media time. solicitud 1 de HTTP (S37050) es una etapa en la que el receptor solicita el servidor de TPT (por ejemplo http://xbc.com/tpt504) para proporcionar una TPT correspondiente utilizando la dirección recibida en respuesta 2 de ACR (S37040) a través del protocolo http. respuesta 1 de HTTP (S37060) es una etapa en la que el servidor de TPT transmite el TPT representado en XML en la solicitud del receptor. solicitud 2 de HTTP (S37070) es una etapa en la que el receptor solicita al servidor de contenido proporcionar una aplicación tal como TDO utilizando el protocolo http. El receptor puede analizar información relacionada de TDO incluida en la TPT. La información relacionada de TDO puede ser la URL del servidor de contenido a través del cual la TDO puede descargarse. Una solicitud puede enviarse utilizando la URL del servidor de contenido. respuesta 2 de HTTP (S37080) es una etapa en la que el servidor de contenido transmite la TDO correspondiente en la solicitud del receptor. solicitud 3 de ACR (S37090) es una etapa en la que el receptor envía la firma de una trama del programa visto actualmente al servidor de ACR. respuesta 3 de ACR (S37100) es una etapa en la que el servidor de ACR regresa un activador (por ejemplo xbc.com/tpt504) que incluye una dirección a través de la que un servicio interactivo relacionado con el programa correspondiente puede obtenerse. En este caso, la firma se reconoce y el servicio interactivo relacionado se encuentra presente, a diferencia de la respuesta 1 de ACR (S37020). Es decir, un activador se encuentra disponible en esta etapa. solicitud 4 de ACR (S37110) es una etapa en la que el receptor transmite la firma de una trama del programa visto actualmente al servidor de ACR. respuesta 4 de ACR (S37120) es una etapa en la que el servidor de ACR transmite un activador de activación relacionado con el servicio interactivo relacionado con la firma transmitida desde el receptor. Un evento específico puede activarse en un momento específico de acuerdo con el activador de activación.
La Figura 38 muestra un diagrama de secuencia entre el cliente de ACR y otros servidores en un caso de ACR dirigido por evento.
La Figura 38 muestra un diagrama de secuencia de acuerdo con una modalidad de transmitir efectivamente un activador y una TPT de acuerdo con el protocolo de operación del servidor de ACR y el receptor (cliente de ACR) en un modelo dirigido por evento.
Una operación ejemplar del modelo dirigido por evento en el orden de solicitud, respuesta a la solicitud y evento se describirá ahora.
El diagrama de secuencia entre el cliente de ACR y otros servidores en un caso de ACR dirigido por evento puede incluir solicitud 1 de ACR (S38010), solicitud 2 de ACR (S38020), evento 1 de ACR (S37030), solicitud 1 de HTTP (S38040), respuesta 1 de HTTP (S38050), solicitud 2 de HTTP (S38060), respuesta 2 de HTTP (S38070), solicitud 3 de ACR (S38080), evento 2 de ACR (S38090) y/o respuesta 4 de ACR (S38100). solicitud 1 de ACR (S38080) es una etapa en la que el receptor transmite la firma de un programa visto actualmente a un servidor. El servidor puede ser el servidor de ACR descrito en lo anterior. La firma puede ser una firma de firma digital o una marca de agua. Aquí, cuando la firma no se reconoce o un servicio interactivo relacionado no se encuentra presente, el servidor de ACR puede no enviar respuesta a la solicitud 1 de ACR sin regresar NULL, a diferencia de la secuencia de la Figura 37. solicitud 2 de ACR (S38020) es una etapa en la que, cuando el canal o programa cambia, el receptor transmite la firma del programa cambiado al servidor de ACR. evento 1 de ACR (S38030) es una etapa en la que el servidor de ACR regresa un activador (por ejemplo xbc.com/tpt504) que incluye una dirección por la que un servicio interactivo relacionado con el programa correspondiente puede obtenerse. Esta etapa puede corresponder a un caso en el que la firma se reconoce y un servicio interactivo relacionado se encuentra presente. Es decir, un activador se encuentra disponible en esta etapa. En este caso, el activador regresado puede ser un activador basado en tiempo que no tiene información acerca de media_time. solicitud 1 de HTTP (S38040) es una etapa en la que el receptor solicita al servidor de TPT (por ejemplo http://xbc.com/tpt504) proporcionar una TPT correspondiente utilizando la dirección recibida en el evento 1 de ACR (S38030) a través del protocolo http. respuesta 1 de HTTP (s38050) es una etapa en la que el servidor de TPT transmite la TPT representada en XML en la solicitud del receptor. solicitud 2 de HTTP (S38060) es una etapa en la que el receptor solicita al servidor de contenido proporcionar una aplicación tal como TDO utilizando el protocolo http. El receptor puede analizar información relacionada de TDO incluida en TPT. La información relacionada de TDO puede ser la URL del servidor de contenido a través de la que el TDO puede descargarse. Una solicitud puede enviarse utilizando la URL del servidor de contenido. respuesta 2 de HTTP (S38070) es una etapa en la que el servidor de contenido transmite la TDO correspondiente en la solicitud del receptor. solicitud 3 de ACR (S38080) es una etapa en la que el receptor envía la firma de una trama del programa visto actualmente al servidor de ACR. evento 2 de ACR (S38090) es una etapa en la que el servidor de ACR transmite un activador de activación relacionado con el servicio interactivo relacionado con la firma transmitida desde el receptor. Un evento específico puede activarse en un tiempo específico de acuerdo con el activador de activación. solicitud 4 de ACR (S38100) es una etapa en la que el receptor transmite la firma de una trama del programa visto actualmente al servidor de ACR.
La Figura 39 es un diagrama que muestra una modalidad de un método para procesar un servicio interactivo en un receptor en el modelo dirigido por evento.
Una modalidad de un método para procesar un servicio interactivo en el receptor en el modelo dirigido por evento puede incluir recibir contenido de audio sin comprimir o contenido de video sin comprimir (S39010), extraer identificadores (S39020), enviar solicitudes que contienen los identificadores (S39030) y/o recibir un activador para el contenido (S39040).
Recibir contenido de audio sin comprimir o contenido de video sin comprimir (S39010) es una etapa en la que el receptor recibe contenido de audio sin comprimir o contenido de video sin comprimir desde una unidad de descodificación externa.
Aquí, la unidad de descodificación externa puede ser la STB descrita en lo anterior. La STB se describirá en detalle posteriormente.
El contenido de audio sin comprimir o contenido de video sin comprimir puede ser contenido de audio/video transmitido desde la STB descrita en lo anterior (unidad de descodificación externa) al receptor.
La unidad de descodificación externa puede descomprimir contenido de A/B recibido desde una MVPD o similar y distribuir el contenido de A/B descomprimido en el receptor. El receptor puede recibir el contenido de audio sin comprimir o contenido de video sin comprimir desde la unidad de descodificación externa y mostrar el contenido recibido a un espectador. El contenido de audio sin comprimir o contenido de video sin comprimir pueden haberse procesado de acuerdo con el módulo de ingesta de ACR mencionado en lo anterior. Es decir el módulo de ingesta de ACR puede calcular la firmas (firma digital) de las tramas, en el caso de un sistema de ACR de firma digital, o insertar marcas de agua que incluyen códigos en las tramas, en el caso de un sistema de ACR de marca de agua que se basa en códigos. Aquí, las tramas pueden relacionarse al contenido de audio/video antes de descodificarse/descomprimirse por el STB. El módulo de ingesta de ACR puede almacenar, en la base de datos, el media_time de cada trama asociada con una firma o código, junto con otros metadatos.
Extraer identificadores (S39020) es una etapa en la que el receptor extrae periódicamente identificadores desde una pluralidad de tramas del contenido de audio sin comprimir o contenido de video sin comprimir recibido.
Un identificador puede identificar una trama del contenido recibido. El identificador puede ser una firma de firma digital o un código de marca de agua. La presente modalidad no se limita a la firma digital o marca de agua.
Aquí, 'extraer' o 'extracting' es un proceso para extraer periódicamente identificadores desde una pluralidad de tramas del contenido de audio sin comprimir o contenido de video sin comprimir recibido y puede corresponder a 'calcular la firma' o 'computing the signature', 'extraer la marca de agua' o 'extracting the watermark' y 'generar la firma' o 'generating the signature' descritos en lo anterior.
Además, 'extracting' puede ser una operación realizada por el cliente de ACR descrito en lo anterior. Sin embargo, éste es un ejemplo y el espíritu de la presente invención no se limita a éste y 'extracting' puede realizarse en otros módulos de acuerdo con la intención de un diseñador. El cliente de ACR puede disponerse en el receptor.
En extraer identificadores (S39020), un identíficador que corresponde a una sola trama puede extraerse. La extracción puede realizarse periódicamente. Los identificadores extraídos pueden enviarse al servidor de ACR, como se describe en lo anterior. El servidor de ACR puede coincidir con los identificadores recibidos con registros en una base de datos, como se describe en lo anterior. El servidor de ACR y la base de datos pueden ser el servidor de ACR descrito en lo anterior y la base de datos. Los registros en la base de datos pueden ser registros almacenados previamente por el módulo de ingesta de ACR.
En una modalidad de la presente invención, un ciclo de extracción del identificador puede ser de 5 segundos. El ciclo de extracción del identificador puede cambiarse de acuerdo con la intención del diseñador.
Enviar solicitudes que contienen los identificadores (S39030) es una etapa en la que las solicitudes que incluyen los identificadores extraídos se envían a un servidor.
Los identificadores extraídos pueden ser firmas de firma digital o códigos de marca de agua. La presente modalidad no se limita a firma digital o marca de agua.
Aquí, una solicitud puede incluir un identificador. El receptor puede transmitir periódicamente una solicitud a un servidor. Una simple solicitud puede incluir un solo identificador. Un periodo puede cambiarse por el diseñador.
El servidor puede ser el servidor de ACR descrito en lo anterior. El servidor puede recibir una solicitud y coincidir la solicitud con los registros en una base de datos. El servidor de ACR y la base de datos pueden ser el servidor de ACR y la base de datos mencionados en lo anterior. Los registros en la base de datos pueden ser registros almacenados previamente por el módulo de ingesta de ACR.
Recibir un activador para el contenido (S39040) es una etapa en la que un activador se recibe desde el servidor de acuerdo con si las solicitudes e identificadores enviados al servidor coinciden con los registros en la base de datos activadores presentes en los registros empatados o no.
El receptor no recibe una respuesta en cualquier caso de las solicitudes descritas en lo anterior. El receptor puede recibir el activador cuando se detecta un nuevo o cuando una activación de evento necesita comunicarse con el receptor. En otros casos, el receptor puede no recibir el activador. Sin embargo, el receptor puede recibir el activador en casos diferentes al caso mencionado en lo anterior de acuerdo con la intención del diseñador.
Aquí, el segmento puede ser el segmento de servicio interactivo mencionado en lo anterior.
El nuevo segmento puede referirse a un segmento a utilizarse después de la tabla de parámetro de aplicación actual o TPT.
Aquí, cuando la activación de evento necesita comunicarse al receptor puede significar un caso en el que la activación de evento se agenda o un caso en el que un evento que necesita activarse no se ha activado.
El activador puede relacionarse con el contenido recibido por receptor desde la STB.
El contenido puede ser el contenido recibido desde la STB.
Aquí, el activador puede indicar el tiempo actual del contenido y referenciar un evento interactivo particular en una tabla de parámetro de aplicación o señal que el evento va a ejecutarse ahora o en un momento especificado en el futuro.
Aquí, la tabla de parámetro de aplicación puede incluir información acerca de al menos una aplicación.
El servidor puede ser el servidor de ACR descrito en lo anterior. La base de datos puede ser la base de datos descrita en lo anterior. Los identificadores pueden ser firmas de firma digital o códigos de marca de agua. La presente modalidad no se limita a la firma digital o marca de agua.
El servidor puede coincidir las solicitudes/identificadores recibidos con los registros en la base de datos. Las solicitudes/identificadores pueden coincidir con los registros almacenados previamente en la base de datos por el módulo de ingesta de ACR. Cuando un identificador coincide con un identificador almacenado en la base de datos, el servidor puede recibir el registro relacionado con el identificador desde la base de datos. En este caso, el registro puede incluir un activador basado en tiempo o un activador de activación. Qué activador se incluye en el registro puede depender de qué activador se inserta previamente en el registro por módulo de ingesta de ACR. Tras la recepción del registro desde la base de datos, el servidor puede enviar el activador o activadores recibidos en el receptor. Aquí, el servidor puede enviar el activador o activadores sólo en el caso especifico limitado en lo anterior a diferencia del modelo de solicitud/respuesta. En otros casos, el servidor puede no transmitir respuesta al receptor.
En la modalidad de la presente invención, el activador puede ser un activador basado en tiempo cuando el identificador corresponde al nuevo segmento, y el he activador basado en tiempo puede utilizarse para permitir al receptor obtener una nueva tabla de parámetro de aplicación asociada con el nuevo segmento. El activador basado en tiempo puede conformar la operación de activador basado en tiempo descrita en lo anterior.
En la modalidad de la presente invención, el activador puede ser un activador de activación cuando el evento es adecuado para activarse, y el activador de activación establece un tiempo de activación para el evento. El activador de activación puede conformarse a la operación de activador de activación descrita en lo anterior. El activador de activación puede aplicarse en un evento de una aplicación para provocar la activación en un tiempo especifico. Un espectador puede proporcionarse con un servicio interactivo a través de la activación de evento. En el caso de la distribución de activador de activación de acuerdo con una modalidad de la presente invención, un servidor interactivo puede proporcionarse en los entornos de ACR descritos en lo anterior, es decir, cuando el receptor tiene conexión de Internet y acceso a audio y video sin comprimir desde una corriente de difusión.
En la modalidad de la presente invención, el activador de activación puede aplicarse una vez, cuando el receptor recibe más de un activador de activación para la activación de evento. Como se describe en lo anterior, el receptor puede recibir una pluralidad de activadores de activación para la misma activación de evento. De acuerdo con una modalidad de la presente invención, los identificadores pueden extraerse y transmitirse periódicamente al servidor. Aquí, una pluralidad de activadores de activación pueden recibirse como respuestas a solicitudes periódicas. En este caso, los activadores de activación tienen el mismo término "t=" y de este modo el receptor puede reconocer que los activadores de activación son duplicados y aplicar solamente un activador de aplicación, como se describe en lo anterior.
En la modalidad de la presente invención, el activador de activación puede recibirse antes del momento en que el receptor necesita aplicar el activador de activación. Al hacerlo, el evento puede activarse en el momento de activación correcto. Esta modalidad puede corresponder a la activación estática descrita en lo anterior.
En la modalidad de la presente invención, el evento puede activarse inmediatamente tras la recepción del activador de activación, cuando el activador de activación se recibe después del momento de activación. Esta modalidad puede corresponder a la activación dinámica descrita en lo anterior. Cuando el servidor reconoce la activación tardía de manera que el servidor no puede transmitir el activador de activación al receptor, el servidor puede esperar la siguiente solicitud del receptor y después enviar el activador de activación como una respuesta a la siguiente solicitud. En este caso, el activador de activación puede indicar el tiempo de activación previo. Aquí, el receptor puede aplicar el activador de activación tan pronto como el receptor reciba el activador de activación.
En la modalidad de la presente invención, el método para procesar un servicio interactivo además puede incluir descargar inmediatamente una nueva tabla de parámetro de aplicación. El receptor descarga inmediatamente la nueva tabla de parámetro de aplicación a menos que el receptor ya haya recuperado la nueva tabla de parámetro de aplicación utilizando la información de URL distribuida con la tabla de parámetro de aplicación, cuando el activador incluya un identificador de tabla de parámetro de aplicación que identifica la nueva tabla de parámetro de aplicación. Como se describe en lo anterior, cuando el receptor recibe un activador que tiene una nueva identificador de tabla de parámetro de aplicación , el receptor puede obtener nueva información en provisión de un servicio interactivo con respecto a un segmento relacionado al descargar la nueva tabla de parámetro de aplicación (por ejemplo, TPT). En una modalidad de la presente invención, el receptor puede solicitar un servidor de tabla de parámetro de aplicación para proporcionar una nueva tabla de parámetro de aplicación utilizando el protocolo http y descargar la nueva tabla de parámetro de aplicación. Aquí, la tabla de parámetro de aplicación puede ser un formato XML o binario de acuerdo con una modalidad de la presente invención. El identificador de tabla de parámetro de aplicación puede ser locator_part descrito en lo anterior. Aquí, la información URL puede ser URLList descrito en lo anterior.
En la modalidad de la presente invención, el tiempo puede ser un tiempo de medios y el tiempo de medios puede ser un parámetro que referencia un punto en la reproducción de un articulo de contenido.
En la modalidad de la presente invención, la aplicación es un Objeto Declarativo, un Objeto Declarativo Activado, un Objeto Declarativo no en tiempo Real o Objeto Declarativo sin Enlace.
En la modalidad de la presente invención, una sesión de comunicación puede cerrarse a menos que una solicitud y una respuesta se transmitan y reciban. La sesión de comunicación no se mantiene abierta entre las instancias de solicitud. El receptor puede recibir una respuesta a través de una sesión de comunicación cuando la sesión de comunicación se mantiene abierta.
En la modalidad de la presente invención, el servidor en lugar del receptor puede enviar un mensaje primero. Es decir, es posible para el servidor (por ejemplo, servidor de ACR) transmitir mensajes al cliente (por ejemplo, receptor) en cualquier momento.
En la modalidad de la presente invención, el servidor puede no necesitar inteligencia extra. El servidor puede distribuir simplemente información encontrada desde la base de datos al el receptor (por ejemplo, cliente de ACR). El módulo de ingesta de ACR puede tomar cargo de la inteligencia con respecto a la operación de la presente invención.
La Figura 40 es un diagrama que muestra la estructura de un receptor de acuerdo con una modalidad de la presente invención.
En la modalidad de la presente invención, el receptor puede incluir una antena rcvrlOlO, un sintonizador rcvrl020, un desmodulador VSB o DVB rcvrl030, un Descodificador rcvrl040 del Sistema MPEG-2TS, un módulo de rcvrl050 de subtítulos, un módulo rcvrl060 de activador, un web rcvrl070, una pila de protocolo de red rcvrl080, una interfaz de red rcvrl090, un módulo rcvrllOO de UI, un descodificador rcvrlllO de audio, un descodificador rcvrll20 de video, un altavoz rcvrll30, un módulo de rcvrll40 de visualización, un procesador rcvrll50 gráfico, un receptor rcvrll60 de controlador remoto y/o un controlador rcvrll70 remoto.
La antena rcvrlOlO puede recibir una señal de difusión de acuerdo con una corriente de difusión. Aquí, la antena rcvrlOlO puede ser una utilizada generalmente en el campo téenico.
El sintonizador rcvrl020 puede buscar o sintonizar un canal del receptor y puede incluir un amplificador de radiofrecuencia, un oscilador local, un circuito de conversión de frecuencia de entrada, un buscador, etc. El sintonizador rcvrl020 puede ser uno generalmente utilizado en el campo técnico.
El desmodulador rcvrl030 de VSB o DVB puede modular una señal de VSB o una señal de DVB. El desmodulador rcvrl030 de VSB o DVB puede restablecer la VSB o DVB modulada (por ejemplo, señal modulada por OFDM) a una señal original. El proceso de desmodulación del desmodulador rcvrl030 de VSB o DVB puede ser uno utilizado generalmente en el campo técnico.
El Descodificador rcvrl040 del Sistema MPEG-2TS descodifica la corriente de transporte (TS) de la señal desmodulada. El Descodificador rcvrl040 del Sistema MPEG-2TS puede obtener y distribuir una corriente de titulo desde la corriente de transporte al módulo rcvrl050 de subtitulo. El Descodificador rcvrl040 del Sistema MPEG-2TS puede enviar la señal de audio y video descodificada al descodificador rcvrll20 de audio/video.
El módulo rcvrl050 de subtítulos puede recibir la corriente de subtítulos. El módulo rcvrl050 de subtítulos puede monitorear el servicio #6 u otros servicios y determinar si el servicio #6 o los servicios para transmitir el activador se seleccionan y envían al módulo rcvrl060 del activador o si el texto de subtítulos se procesa y muestra en una pantalla. Los datos del activador pueden distribuirse al módulo rcvrl060 del activador. Otros servicios de subtítulos pueden someterse al procesamiento de texto de subtítulos y enviar al procesador rcvrll50 gráfico.
El módulo rcvrl060 del activador puede analizar el activador, la información de TPT y/o AMT y procesar los datos analizados. El módulo rcvrl060 del activador puede acceder a la red mediante la pila rcvrl080 de protocolo de red utilizando el valor de información de URIdl activador. El valor de información de URI puede ser la dirección del servidor de HTTP. El módulo rcvrl060 del activador puede analizar el contenido de archivo de TPT para obtener la TDO URL. Además, el módulo rcvrl060 del activador puede analizar la AMT para procesar los datos. Otra información puede obtenerse a través del análisis. Después que el mensaje de AMT se ha recibido, la URL de TDO que corresponde al navegador web se distribuye de acuerdo con un tiempo y operación predeterminados o la operación de TDO puede detenerse en un momento predeterminado. Esto corresponde a una acción de TDO y el módulo rcvrl060 del activador puede enviar un comando al navegador web para operar. La operación del módulo rcvrl060 del activador relacionado con la presente invención se describirá en detalle a continuación.
El navegador rcvrl070 web puede recibir el comando del el módulo rcvrl060 del activador, un código clave de navegador desde el módulo rcvrllOO de UI y un código clave de navegador desde el receptor rcvrll60 de controlador remoto y comunicarse con la pila rcvrl080 de protocolo de red.
La pila rcvrl080 de protocolo de red puede comunicarse con el módulo rcvrl060 de activador y el navegador web para acceder al servidor mediante la interfaz rcvrl090 de red.
La interfaz rcvrl090 de red realiza una conexión común de diversos aparatos o conexión a una computadora de red y una red externa. La interfaz de red puede conectarse al servidor para cargar una a TOO, una TPT, una AMT, etc. Aquí, la operación de la interfaz rcvrl090 de red puede ser operación de la interfaz rcvrl090 de red utilizada generalmente en el campo téenico. La operación de la interfaz rcvrl090 de red relacionada con la presente invención se describirá en detalle a continuación.
El módulo rcvrllOO de UI puede recibir información ingresada por un espectador utilizando controlador rcvrll70 remoto a través del receptor rcvrll60 remoto. Si la información recibida se relaciona con un servicio que utiliza la red, el código clave de navegador puede distribuirse al navegador web. Si la información recibida se relaciona con video mostrado actualmente, la señal puede distribuirse al módulo rcvrll40 de visualización mediante el procesador rcvrll50 gráfico.
El descodificador rcvrlllO de audio puede descodificar la señal de audio recibida desde el Descodificador rcvrl040 de Sistema MPEG-2TS. Después, la señal de audio descodificada puede enviarse al altavoz y producirse por el espectador. Aquí, el descodificador rcvrlllO de audio puede ser uno utilizado generalmente en el campo téenico.
El descodificador rcvrll20 de video puede descodificar la señal de video recibida desde el Descodificador rcvrl040 de Sistema MPEG-2TS. Después, la señal de video descodificada puede enviarse al módulo rcvrll40 de visualización para producirse al espectador. Aquí, el descodificador rcvrll20 de video puede ser uno generalmente utilizado en el campo técnico.
Los altavoces rcvrll30 pueden producir la señal de audio al espectador. El altavoz puede ser uno generalmente en utilizado en el campo técnico.
El módulo rcvrll40 de visualización puede producir la señal de video al espectador. El módulo rcvrll40 de visualización puede ser uno generalmente utilizado en el campo técnico. La operación del módulo rcvrll40 de visualización relacionada con la presente invención se describirá en detalle a continuación.
El procesador rcvrll50 gráfico puede realizar procesamiento gráfico con respecto al texto de subtítulos recibido desde el módulo rcvrl050 de subtítulos y el espectador información ingresada recibida desde el módulo rcvrllOO de UI. La información procesada puede distribuirse al módulo rcvrll40 de visualización. El procesador rcvrll50 gráfico puede ser uno generalmente utilizado en el campo téenico.
El receptor rcvrll60 remoto puede recibir información desde el controlador rcvrll70 remoto. En este momento, el código clave puede distribuirse al módulo rcvrllOO de UI y el código clave de navegador puede distribuirse al navegador web. El controlador rcvrll70 remoto distribuye la señal ingresada por el espectador al receptor rcvrll60 remoto. El controlador rcvrll70 remoto puede recibir entradas del espectador para cambiar un canal virtual. Además, el controlador remoto puede recibir información seleccionada por el espectador con respecto a la aplicación. El controlador rcvrll70 remoto puede distribuir información recibida al receptor rcvrll60 remoto. En este momento, la información puede distribuirse remotamente utilizando luz infrarroja (IR) a una distancia fuera de un margen predeterminado.
La Figura 41 es un diagrama que muestra la estructura de un receptor de acuerdo con una modalidad de la presente invención en el caso en el que una caja de convertidor-descodificador reciba una difusión mediante una interfaz multimedia de alta definición (HDMI) o una interfaz externa.
En la modalidad de la presente invención mostrada en la Figura 41, el receptor puede incluir antena rcvr2010, un sintonizador rcvr2020, una Caja de Convertidor-Descodificador rcvr2030, un desmodulador rcvr2040 VSB o DVB, un HDMI RCVR2050, un descodificador rcvr2060 de sistema MPEG-2 TS, un módulo rcvr2070 de subtítulos, un módulo rcvr2080 de activador, un navegador rcvr2090 web, una pila rcyr2100 de protocolo de red, una interfaz rcvr2110 de red, un módulo rcvr2120 de UI, un módulo rcvr2130 de ACR, un descodificador rcvr2140 de audio, un descodificador rcvr2150 de video, un altavoz rcvr2160, un módulo rcvr2170 de visualización, un procesador rcvr2180 gráfico, un receptor rcvr2190 de controlador remoto y/o un controlador rcvr2200 remoto.
En este caso, debido a que el video y audio de una corriente de difusión es de datos en bruto, un activador incluido en una corriente de subtítulos puede no recibirse. Detalles de la presente invención se describirán a continuación Aquí, los módulos que excluyen la Caja de Convertidor-Descodificador rcvr2030, el HDMI rcvr2050 y el módulo rcvr2130 de ACR son similares a los módulos descritos en la modalidad de la Figura 40 en términos del rol.
La Caja de Convertidor-Descodificador rcvr2030, el HDMI rcvr2050 y el módulo rcvr2130 de ACR se describirán ahora.
La Caja de Convertidor-Descodificador rcvr2030 puede restablecer una señal comprimida recibida desde el servidor de video a través de una red digital a un señal de video y audio original. La TV puede ser una interfaz de usuario de Internet.
El HDMI rcvr2050 puede ser una interfaz multimedia de alta definición la cual es una interfaz de video/audio digital sin compresión estándar. El HDMI rcvr2050 puede proporcionar una interfaz entre la Caja de Convertidor-Descodificador rcvr2030 y un aparato AV, es decir, el descodificador rcvr2140 de audio y el descodificador rcvr2150 de video.
El módulo rcvr2130 de ACR puede reconocer automáticamente el contenido de difusión desde el descodificador rcvr2140 de audio y el descodificador rcvr2150 de video. Basado en el contenido reconocido actualmente, una solicitud puede enviarse al servidor de ACR mediante el módulo rcvr2080 de activador y la interfaz rcvr2110 de red para recibir la TPT/AMT para el activador.
La Figura 42 es un diagrama que muestra una modalidad de un aparato para procesar un servicio interactivo en un modelo dirigido por evento.
Una modalidad del aparato para procesar un servicio interactivo en un modelo dirigido por evento de acuerdo con la presente invención puede incluir un módulo 42010 de recepción, un módulo 42020 de extracción de identificador y/o una interfaz 42030 de red.
El módulo 42010 de recepción recibe contenido de audio sin comprimir o contenido de video sin comprimir desde una unidad de descodificación externa.
La unidad de descodificación externa puede ser la STB descrita en lo anterior.
El contenido de audio sin comprimir o contenido de video sin comprimir puede ser contenido de audio/video transmitido desde la STB descrita en lo anterior (unidad de descodificación externa) a un receptor.
Aqui, el módulo 42010 de recepción puede corresponder a la HDMI de la Figura 41. El módulo 42010 de recepción puede ser un módulo que no se muestra en la Figura 40 o la Figura 41. El módulo 42010 de recepción puede ser modificado por el diseñador.
La unidad de descodificación externa puede descomprimir el contenido de A/V recibido desde una VPD o similar y distribuir el contenido de A/V descomprimido al módulo 42010 de recepción. El contenido de audio sin comprimir o contenido de video sin comprimir pueden haberse procesado de acuerdo con el módulo de ingesta de ACR descrito en lo anterior. Es decir, el módulo de ingesta de ACR puede calcular firmas (firmas digitales) de tramas, en el caso de un sistema de ACR de firma digital, o insertar marcas de agua que incluyen códigos en las tramas, en el caso de un sistema de ACR de marca de agua que se basa en códigos. Aquí, las tramas puede relacionar el contenido de audio/video antes de descodificarse/descomprimirse por la STB. El módulo de ingesta de ACR puede almacenarse en la base de datos el media_time de cada trama asociada con una firma o código, junto con otros metadatos.
El módulo 42020 de extracción de identificador extrae periódicamente identificadores desde una pluralidad de tramas del contenido de audio sin comprimir o contenido de video sin comprimir recibido por el módulo 42010 de recepción.
Un identificador püede identificar una trama del contenido recibido. El identificador puede ser una firma de firma digital o un código de marca de agua. La presente modalidad no se limita a firma digital o marca de agua.
Aquí, 'extracting' es un proceso de extraer identificadores periódicamente de una pluralidad de tramas del contenido de audio sin comprimir o contenido de video sin comprimir recibidos y puede corresponder a 'computing the firm', 'extracting the firm' y 'generating the firm' descritos en lo anterior.
El módulo 42020 de extracción de identificador extrae periódicamente un identificador que corresponde a una sola trama. Los identificadores extraídos pueden enviarse al servidor de ACR, como se describe en lo anterior. El servidor de ACR puede coincidir los identificadores recibidos con registros en la base de datos, como se describe en lo anterior. El servidor de ACR y la base de datos pueden ser el servidor de ACR y la base de datos descritos en lo anterior. Los registros en la base de datos pueden ser registros previamente almacenados por el módulo de ingesta de ACR.
El módulo 42020 de extracción de identificador puede corresponder al módulo de ACR de la Figura 41. De otra forma, el módulo 42020 de extracción de identificador puede ser un módulo que no se muestra en la Figura 40 o la Figura 41. El módulo 42020 de recepción puede modificarse por el diseñador.
En la modalidad de la presente invención, un ciclo de extracción del identificador puede ser de 5 segundos. El ciclo de extracción del identificador puede cambiarse de acuerdo con la intención del diseñador.
La interfaz 42030 de red envía solicitude4s que incluyen identificadores extraídos al servidor y recibe un activador del servidor de acuerdo con si las solicitudes e identificadores enviados al servidor coinciden con los registros en la base de datos o activadores presentes en los registros coinciden. Aquí, la interfaz 42030 de red puede recibir un activador basado en una solicitud.
La interfaz 42030 de red puede corresponder a la interfaz de red de la Figura 41. De otra forma, la interfaz 42030 de red es un módulo que no se muestra en la Figura 40 o la Figura 41. La interfaz 42030 de red puede modificarse por el diseñador.
Los identificadores extraídos pueden ser firma de firma digital o códigos de marca de agua. La presente modalidad no se limita a firma digital o marca de agua.
Aquí, una solicitud puede incluir un identificador. La interfaz 42030 de red puede transmitir periódicamente una solicitud al servidor. Una sola solicitud puede incluir un solo identificador. Un periodo puede cambiarse por el diseñador.
El servidor puede ser el servidor de ACR descrito en lo anterior. El servidor puede recibir una solicitud y coincidir la solicitud con registros en una base de datos. El servidor de ACR y la base de datos pueden ser el servidor de ACR y base de datos descritos en lo anterior. Los registros en la base de datos pueden ser registros previamente almacenados por el módulo de ingesta de ACR.
La interfaz 42030 de red no recibe una respuesta en cualquier caso para las solicitudes descritas en lo anterior. La interfaz 42030 de red puede recibir el activador cuando se detecta nuevo segmento o cuando necesita una activación de evento para comunicarse al aparato. En otros casos, el aparato puede no recibir el activador. Sin embargo, el aparato puede recibir el activador en cases diferentes al caso mencionado en lo anterior de acuerdo con intención del diseñador.
Aquí, el segmento puede ser el segmento de servicio interactivo descrito en lo anterior.
El nuevo segmento puede referirse a un segmento que puede utilizarse después de la tabla de parámetro de aplicación actual o TPT.
Aquí, la comunicación de una activación de evento al receptor puede significar un caso en el que la activación de evento se agenda o un caso en el que un evento que necesita activarse no se ha activado todavía.
El activador puede relacionarse con el contenido recibido por el módulo 42010 de recepción de la STB.
El contenido puede ser el contenido recibido de la STB.
Aquí, el activador can puede indicar el tiempo actual del contenido y referenciar un evento interactivo particular en una tabla de parámetro de aplicación o señal que el evento va a ejecutarse ahora o en un momento especificado en el futuro.
Aquí, la tabla de parámetro de aplicación puede incluir información acerca de al menos una aplicación.
El servidor puede ser el servidor de ACR descrito en lo anterior. La base de datos puede ser la base de datos descrita en lo anterior. Los identificadores pueden ser firma de firma digital o códigos de marca de agua. La presente modalidad no se limita a firma digital o marca de agua.
El servidor puede coincidir las solicitudes/identificadores recibidos con registros en la base de datos. Las solicitudes/identificadores pueden coincidir con registros previamente almacenados en la base de datos por el módulo de ingesta de ACR. Cuando un identificador coincide con un identificador almacenado en la base de datos, el servidor puede recibir el registro relacionado con el identificador desde la base de datos. En este caso, el registro puede incluir un activador basado en tiempo o un activador de activación. Qué activador se incluye en el registro puede depender en que un activador se inserte previamente en el registro por el módulo de ingesta de ACR. Tras la recepción del registro desde la base de datos, el servidor puede enviar el activador o activadores recibidos a la interfaz de red 39030.
En la modalidad de la presente invención, el activador puede ser un activador basado en tiempo cuando el identificador corresponde al nuevo segmento, y el activador basado en tiempo puede utilizarse para permitir al receptor obtener una nueva new tabla de parámetro de aplicación asociada con el nuevo segmento. El activador basado en tiempo puede conformarse a la operación de activador basado en tiempo descrita en lo anterior.
En la modalidad de la presente invención, el activador puede ser un activador de activación cuando el evento es adecuado para activarse, y el activador de activación establece un tiempo de activación para el evento. El activador de activación puede conformarse a la operación de activador de activación descrita en lo anterior. El activador de activación puede aplicarse a un evento de una aplicación para provocar la activación en un momento especifico. Un espectador puede proporcionarse con un servicio interactivo a través de la activación de evento. En el caso de la distribución del activador de activación de acuerdo con una modalidad de la presente invención, un servidor interactivo puede proporcionarse en los entornos de ACR descritos en lo anterior, es decir, cuando el receptor tiene conexiones de Internet y acceso a audio y video sin comprimir desde una corriente de difusión.
En la modalidad de la presente invención, el activador de activación puede aplicarse una vez, cuando el aparato recibe more más de un activador de activación para la misma activación de evento. Como se describe en lo anterior, el aparato puede recibir una pluralidad de activadores de activación para la misma activación de evento. De acuerdo con una modalidad de la presente invención, los identificadores pueden extraerse y transmitirse periódicamente al servidor. Aquí, una pluralidad de activadores de activación puede recibirse como respuesta a solicitudes periódicas. En este caso, los activadores de activación tienen el mismo término "t=" y de este modo, el aparato puede reconocer que los activadores de activación son duplicados y aplicar sólo una activador de aplicación, como se describe en lo anterior.
En la modalidad de la presente invención, el activador de activación puede recibirse antes del tiempo cuando el receptor necita aplicar el activador de activación. Al hacerlo, el evento puede activarse en el momento de activación correcto. Esta modalidad puede corresponder a la activación estática descrita en lo anterior.
En la modalidad de la presente invención, el evento puede activarse inmediatamente tras la recepción del activador de activación o cuando el activador de activación se recibe después del tiempo de activación. Esta modalidad puede corresponder a la activación dinámica descrita en lo anterior. Cuando el servidor reconoce la activación tarde de manera que el servidor no puede transmitir el activador de activación al aparato, el servidor puede esperar por la siguiente solicitud del aparato y entonces enviar el activador de activación como respuesta a la siguiente solicitud, en este caso, el activador de activación puede indicar un tiempo de activación pasado. Aquí, el aparato puede aplicar el activador de activación tan pronto como el aparato reciba el activador de activación.
En la modalidad de la presente invención, la interfaz 42030 de red además se configura para descargar una nueva tabla de parámetro de aplicación inmediatamente, a menos que el aparato ya haya recuperado la nueva tabla de parámetro de aplicación utilizando información de URL distribuida con la tabla de parámetro de aplicación, cuando el activador incluye un identificador de tabla de parámetro de aplicación que identifica la nueva tabla de parámetro de aplicación. Como se describe en lo anterior, cuando el aparato recibe un activador que tiene un nuevo identificador de tabla de parámetro de aplicación, el aparato puede obtener nueva información en provisión de un servicio interactivo con respecto a un segmento relacionado al descargar la nueva tabla de parámetro de aplicación (por ejemplo, TPT). En una modalidad de la presente invención, el aparato puede solicitar un servidor de tabla de parámetro de aplicación para proporcionar una nueva new tabla de parámetro de aplicación utilizando protocolo http y descarga la nueva tabla de parámetro de aplicación. Aquí, la tabla de parámetro de aplicación puede ser XML o formato binario de acuerdo con una modalidad de la presente invención. El identificador de tabla de parámetro de aplicación puede ser Locator part descrito en lo anterior. Aquí, la información de URL puede ser URLList descrita en lo anterior.
En la modalidad de la presente invención, el tiempo puede ser un tiempo de medios, y el tiempo de medios puede ser un parámetro que se referencia a un punto en la 1 reproducción del artículo de contenido.
En la modalidad de la presente invención, la aplicación es un Objeto Declarativo, un Objeto Declarativo Activado, un Objeto Declarativo no en Tiempo Real o un Objeto Declarativo sin Enlace.
En la modalidad de la presente invención, una sesión de comunicación puede cerrarse a menos de que una solicitud y una respuesta se transmitan y reciban. Las sesiones de comunicación no se mantienen abiertas entre las instancias de solicitud. El receptor puede recibir una respuesta a través de una sesión de comunicación cuando la sesión de comunicación se mantiene abierta.
En la modalidad de la presente invención, el servidor en lugar del receptor puede enviar un mensaje primero. Es decir, es posible para el servidor (por ejemplo, servidor de ACR) transmitir mensajes al cliente (por ejemplo, aparato) en cualquier momento.
En la modalidad de la presente invención, el servidor puede no necesitar inteligencia extra. El servidor puede simplemente distribuir información desde la base de datos a la interfaz 42030 de red. El módulo de ingesta de ACR puede hacerse cargo de la inteligencia con respecto a la operación de la presente invención.
Modalidades respectivamente descritas con referencia a las figuras pueden combinarse para implementar una nueva modalidad. Además, aquellos con experiencia en la téenica pueden diseñar medios de grabación que pueden leerse por un programa de almacenamiento por computadora para ejecutar las modalidades descritas en lo anterior sin apartarse del alcance de la presente invención.
El aparato y método de acuerdo con la presente invención no se limita a las modalidades descritas en lo anterior y las modalidades pueden combinarse selectivamente y modificarse en diversas formas.
El método para procesar un servicio interactivo relacionado con programas de difusión a los cuales la presente invención se aplica puede implementarse como códigos que pueden escribirse en un medio de grabación legible por computadora y de este modo leerse por un procesador. El medio de grabación legible por computadora puede ser cualquier tipo de dispositivo de grabación en el que los datos se almacenan en una forma legible por computadora. Ejemplos del medio de grabación legible por computadora incluyen una ROM, una RAM, un CD-ROM, una cinta magnética, un disco flexible, un almacenamiento de datos óptico, y una portadora, por ejemplo, transmisión de datos a través de Internet. Además, códigos, los cuales se distribuyen en dispositivo de computadora conectados a través de una red y pueden leerse por una computadora en una forma distribuida, se almacenan y ejecutan en el medio de registro legible por computadora.
Aquellos con experiencia en la téenica apreciarán que la presente invención puede llevarse a cabo en otras formas especificas que aquellas establecidas en la presente sin apartarse del espíritu y características esenciales de la presente invención. Las modalidades anteriores por lo tanto deben interpretarse en todos los aspectos como ilustrativas y no restrictivas. El alcance de la invención debe determinarse por las reivindicaciones anexas y sus equivalentes legales, y no por la descripción anterior, y todos los cambios que vengan dentro del significado y margen de equivalencia de la reivindicaciones anexas pretenden se abarquen en la presente.
Ambas invenciones de aparato y método se mencionan en esta especificación y descripciones de ambos de las invenciones de aparato y método pueden aplicarse en forma complementaria entre sí.
Modo para la invención Diversas modalidades se han descrito en el mejor modo para llevar a cabo la invención.
Aplicabilidad Industrial La presente invención se encuentra disponible para una serie de campos de provisión de servicio de difusión.
Será aparente para aquellos con experiencia en la téenica que diversas modificaciones y variaciones pueden hacerse en la presente invención sin apartarse del espíritu y alcance de la invención. De este modo, se pretende que la presente invención cubra las modificaciones y variaciones de esta invención proporcionadas que vienen dentro del alcance de las reivindicaciones anexas y sus equivalentes.

Claims (18)

REIVINDICACIONES
1. Un método para procesar un servicio interactivo en un receptor, el método caracterizado porque comprende: recibir contenido de audio sin comprimir o contenido de video sin comprimir desde una unidad de descodificación externa; extraer identificadores de tramas desde el contenido recibido periódicamente; emitir solicitudes que contengan los identificadores; y recibir un activador para el contenido cuando se detecta un nuevo segmento o cuando una activación de evento necesita comunicarse al receptor, en donde el activador indica el tiempo actual del contenido y referencia un evento interactivo particular en una tabla de parámetro de aplicación o señala que el evento va a ejecutarse ahora o en un momento futuro especificado, en donde la tabla de parámetro de aplicación incluye información acerca de al menos una aplicación.
2. El método de conformidad con la reivindicación 1, caracterizado porque el activador es un activador basado en tiempo cuando el identificador corresponde al nuevo segmento, en donde el activador basado en tiempo se utiliza para permitir al receptor obtener una nueva tabla de parámetro de aplicación asociada con el nuevo segmento.
3. El método de conformidad con la reivindicación 1, caracterizado porque el activador es un activador de activación cuando el evento es adecuado para activarse, en donde el activador de activación establece un momento de activación para el evento.
4. El método de conformidad con la reivindicación 3, caracterizado porque el activador de activación se recibe antes del momento cuando el receptor necesita aplicar el activador de activación.
5. El método de conformidad con la reivindicación 3, caracterizado porque el evento se activa inmediatamente tras la recepción del activador de activación, cuando el activador de activación se recibe después del momento de activación.
6. El método de conformidad con la reivindicación 1, el método caracterizado además porque comprende: descargar una nueva tabla de parámetro de aplicación inmediatamente, a menos que el receptor ya haya recuperado la nueva tabla de parámetro de aplicación utilizando la información de URL distribuida con la tabla de parámetro de aplicación, cuando el activador incluye un identificador de tabla de parámetro de aplicación que identifica la nueva tabla de parámetro de aplicación.
7. El método de conformidad con la reivindicación 3, caracterizado porque el activador de activación se aplica una vez, cuando el receptor recibe más de un activador de activación para la misma activación de evento.
8. El método de conformidad con la reivindicación 1, caracterizado porque el tiempo es un tiempo de medios, en donde el tiempo de medios es un parámetro que referencia un punto en la reproducción del articulo de contenido.
9. El método de conformidad con la reivindicación 1, caracterizado porque es un Objeto Declarativo, un Triggered declarative object, un Non-Real Time Objeto Declarativo o un Unbound Objeto Declarativo.
10. Un aparato para procesar un servicio interactivo, el aparato caracterizado porque comprende: un módulo de recepción configurado para recibir contenido de audio sin comprimir o contenido de video sin comprimir desde una unidad de descodificación externa; un módulo de extracción de identificador configurado para extraer identificadores de tramas desde el contenido recibido periódicamente; una interfaz de red configurada para enviar solicitudes que contienen los identificadores y recibir un activador para el contenido cuando se detecta un nuevo segmento o cuando una activación de evento necesita comunicarse al aparato, en donde el activador indica el tiempo actual del contenido y referencia a un evento interactivo particular en una tabla de parámetro de aplicación o señala que el evento va a ejecutarse ahora en un momento futuro especificado, en donde la tabla de parámetro de aplicación incluye información acerca de al menos una de las aplicaciones.
11. El aparato de conformidad con la reivindicación 10, caracterizado porque el activador es un activador basado en tiempo cuando el identificador corresponde al nuevo segmento, en donde el activador basado en tiempo se utiliza para permitir al aparato obtener una nueva tabla de parámetro de aplicación asociada con el nuevo segmento.
12. El aparato de conformidad con la reivindicación 10, caracterizado porque el activador es un activador de activación cuando el evento es apropiado para activarse, en donde el activador de activación establece un tiempo de activación para el evento.
13. El aparato de conformidad con la reivindicación 12, caracterizado porque el activador de activación se recibe antes del momento cuando el aparato necesita aplicar el activador de activación.
14. El aparato de conformidad con la reivindicación 12, caracterizado porque el evento se activa inmediatamente tras la recepción del activador de activación, cuando el activador de activación se recibe después del tiempo de activación.
15. El aparato de conformidad con la reivindicación 10, caracterizado porque la interfaz de red además se configura para descargar una nueva tabla de parámetro de aplicación inmediatamente, a menos que el aparato haya recuperado la nueva tabla de parámetro de aplicación utilizando información de URL distribuido con la tabla de parámetro de aplicación, cuando el activador incluye un identificador de tabla de parámetro de aplicación que identifica la nueva tabla de parámetro de aplicación.
16. El aparato de conformidad con la reivindicación 12, caracterizado porque el activador de activación se aplica una vez, cuando el aparato recibe más de un activador de activación para la misma activación de evento.
17. El aparato de conformidad con la reivindicación 10, caracterizado porque el tiempo es un tiempo de medios, en donde el tiempo de medios es un parámetro que referencia un punto en la reproducción de un articulo de contenido.
18. El aparato de conformidad con la reivindicación 10, caracterizado porque la aplicación es un Objeto Declarativo, un Objeto Declarativo Activado, un Non-Real Time Objeto Declarativo o un Unbound Objeto Declarativo. RESUMEN DE LA INVENCIÓN Se describen un método para procesar un servicio interactivo y un aparato del mismo. La presente invención incluye recibir contenido de audio sin comprimir o contenido de video sin comprimir desde una unidad de descodificación externa, extraer identificadores de tramas desde el contenido recibido periódicamente, enviar solicitudes que contienen los identificadores y recibir un activador para el contenido cuando se detecta un nuevo segmento o cuando la activación de evento necesita comunicarse al receptor, en donde el activador indica el momento actual de los contenidos y referencia un evento interactivo particular en una tabla de parámetro de aplicación o señala que el evento va a ejecutarse ahora o en un momento futuro especificado, en donde la tabla de parámetro de aplicación incluye información acerca de al menos una de las aplicaciones
MX2015001908A 2012-09-12 2013-08-28 Aparato y metodo para procesar un servicio interactivo. MX343885B (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201261700310P 2012-09-12 2012-09-12
US201261703749P 2012-09-20 2012-09-20
PCT/KR2013/007722 WO2014042368A1 (en) 2012-09-12 2013-08-28 Apparatus and method for processing an interactive service

Publications (2)

Publication Number Publication Date
MX2015001908A true MX2015001908A (es) 2015-06-05
MX343885B MX343885B (es) 2016-11-25

Family

ID=50234775

Family Applications (2)

Application Number Title Priority Date Filing Date
MX2015001908A MX343885B (es) 2012-09-12 2013-08-28 Aparato y metodo para procesar un servicio interactivo.
MX2016015474A MX368285B (es) 2012-09-12 2013-08-28 Aparato y metodo para procesar un servicio interactivo.

Family Applications After (1)

Application Number Title Priority Date Filing Date
MX2016015474A MX368285B (es) 2012-09-12 2013-08-28 Aparato y metodo para procesar un servicio interactivo.

Country Status (9)

Country Link
US (3) US9078042B2 (es)
EP (1) EP2896212B1 (es)
JP (1) JP6212557B2 (es)
KR (1) KR101939296B1 (es)
CN (1) CN104662925B (es)
CA (1) CA2880254C (es)
DE (1) DE112013004029B4 (es)
MX (2) MX343885B (es)
WO (1) WO2014042368A1 (es)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2527734A (en) * 2014-04-30 2016-01-06 Piksel Inc Device synchronization
KR102459246B1 (ko) 2014-08-01 2022-10-27 소니그룹주식회사 수신 장치, 수신 방법, 송신 장치 및 송신 방법
US10904617B1 (en) * 2015-02-19 2021-01-26 Amazon Technologies, Inc. Synchronizing a client device with media content for scene-specific notifications
KR101757878B1 (ko) 2015-12-10 2017-07-14 삼성전자주식회사 컨텐츠 처리장치, 그의 컨텐츠 처리방법, 서버, 서버의 정보 제공방법 및 정보제공 시스템
US10523244B2 (en) * 2016-08-11 2019-12-31 Zebware Ab Device and associated methodoloy for encoding and decoding of data for an erasure code
TWI640195B (zh) * 2016-12-14 2018-11-01 日商夏普股份有限公司 具有統一資源識別符訊息浮水印有效負載之廣播系統
US11095927B2 (en) * 2019-02-22 2021-08-17 The Nielsen Company (Us), Llc Dynamic watermarking of media based on transport-stream metadata, to facilitate action by downstream entity
TWI758729B (zh) * 2019-05-10 2022-03-21 美商六科股份有限公司 與內容修改系統結合使用之方法、非暫時性電腦可讀儲存媒體及計算系統
US11632598B2 (en) 2019-05-10 2023-04-18 Roku, Inc. Content-modification system with responsive transmission of reference fingerprint data feature
WO2020231821A1 (en) 2019-05-10 2020-11-19 The Nielsen Company (Us), Llc Content-modification system with fingerprint data match and mismatch detection feature
US11234050B2 (en) * 2019-06-18 2022-01-25 Roku, Inc. Use of steganographically-encoded data as basis to control dynamic content modification as to at least one modifiable-content segment identified based on fingerprint analysis
US11051057B2 (en) 2019-06-24 2021-06-29 The Nielsen Company (Us), Llc Use of steganographically-encoded time information as basis to establish a time offset, to facilitate taking content-related action
US11012757B1 (en) 2020-03-03 2021-05-18 The Nielsen Company (Us), Llc Timely addition of human-perceptible audio to mask an audio watermark
WO2023176997A1 (ko) 2022-03-17 2023-09-21 엘지전자 주식회사 디스플레이 장치

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6415438B1 (en) * 1999-10-05 2002-07-02 Webtv Networks, Inc. Trigger having a time attribute
WO2002062009A1 (en) * 2001-01-30 2002-08-08 Digimarc Corporation Efficient interactive tv
US20030192060A1 (en) * 2001-01-30 2003-10-09 Levy Kenneth L. Digital watermarking and television services
US8407752B2 (en) * 2004-03-18 2013-03-26 Digimarc Corporation Synchronizing broadcast content with corresponding network content
US20070072543A1 (en) * 2005-09-06 2007-03-29 Nokia Corporation Enhanced signaling of pre-configured interaction message in service guide
US20070074079A1 (en) * 2005-09-27 2007-03-29 Forster Darren P System and method for providing trigger information in a video signal and playing out a triggered event
US20070162399A1 (en) * 2005-12-22 2007-07-12 Alexander Medvinsky Method and apparatus for providing broadcast trigger messages
US8813152B2 (en) * 2008-08-26 2014-08-19 At&T Intellectual Property I, L.P. Methods, apparatus, and computer program products for providing interactive services
US20110154404A1 (en) * 2009-12-17 2011-06-23 At & T Intellectual Property I, L.P. Systems and Methods to Provide Data Services for Concurrent Display with Media Content Items
US8730301B2 (en) * 2010-03-12 2014-05-20 Sony Corporation Service linkage to caption disparity data transport
US8893210B2 (en) * 2010-08-20 2014-11-18 Sony Corporation Server load balancing for interactive television
BR112013004087A2 (pt) * 2010-08-30 2016-06-14 Sony Corp aparelho de recepção, método de recepção, e programa.
JP5691316B2 (ja) 2010-09-09 2015-04-01 新東工業株式会社 バケットエレベータ内部の結露または粉体の付着を予測及び検出する方法及び装置とそれに用いられる測定ユニット
US9078031B2 (en) 2010-10-01 2015-07-07 Sony Corporation Reception apparatus, reception method, and program
DE112011103903B4 (de) 2010-11-24 2016-06-23 Lg Electronics Inc. Methode zum Empfang eines bestimmten Services und Videowiedergabegerät dazu
KR101960314B1 (ko) * 2010-11-24 2019-03-20 엘지전자 주식회사 영상 표시 장치 및 그 제어 방법
EP2658248A4 (en) * 2010-12-26 2014-07-09 Lg Electronics Inc AUDIOVISUAL SERVICE TRANSMISSION METHOD, AUDIOVISUAL SERVICE RECEIVING METHOD, AND AUDIOVISUAL SERVICE RECEIVING APPARATUS
JP5783402B2 (ja) * 2011-01-25 2015-09-24 ソニー株式会社 受信装置、受信方法、供給装置、供給方法、プログラム、および放送システム
US9554175B2 (en) 2011-07-20 2017-01-24 Sony Corporation Method, computer program, reception apparatus, and information providing apparatus for trigger compaction
US9154840B2 (en) * 2012-07-31 2015-10-06 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method

Also Published As

Publication number Publication date
WO2014042368A1 (en) 2014-03-20
KR101939296B1 (ko) 2019-01-16
CA2880254A1 (en) 2014-03-20
CN104662925B (zh) 2018-12-04
CA2880254C (en) 2017-09-19
US20140075470A1 (en) 2014-03-13
MX368285B (es) 2019-09-27
JP6212557B2 (ja) 2017-10-11
US20150172782A1 (en) 2015-06-18
EP2896212A4 (en) 2016-03-16
US9078042B2 (en) 2015-07-07
US20150281786A1 (en) 2015-10-01
MX343885B (es) 2016-11-25
CN104662925A (zh) 2015-05-27
KR20150056523A (ko) 2015-05-26
EP2896212B1 (en) 2017-10-25
US9398341B2 (en) 2016-07-19
US9912995B2 (en) 2018-03-06
EP2896212A1 (en) 2015-07-22
JP2015532045A (ja) 2015-11-05
DE112013004029B4 (de) 2018-06-14
DE112013004029T5 (de) 2015-04-30

Similar Documents

Publication Publication Date Title
US9794645B2 (en) Apparatus and method for processing an interactive service
KR102068567B1 (ko) 양방향 서비스를 처리하는 장치 및 방법
US9912995B2 (en) Apparatus and method for processing an interactive service
MX2015004730A (es) Aparato y metodo para procesar un servicio interactivo.

Legal Events

Date Code Title Description
FG Grant or registration