MXPA06007796A

MXPA06007796A - Programa y alertas de datos y corrientes de datos auxiliares en un sistema de difusion de canales multiples.

Info

Publication number: MXPA06007796A
Application number: MXPA06007796A
Authority: MX
Inventors: Kevin Mitzel; Jeff Lockledge; John Dombrowski; David Birks; Ray Lowe; Jerry Tarpley
Original assignee: Sirius Satellite Radio Inc
Priority date: 2004-01-06
Filing date: 2005-01-06
Publication date: 2007-03-07
Also published as: CA2551718C; US7995673B2; WO2005069569A1; US20090124193A1; CA2551718A1

Abstract

Un sistema y un metodo (130, 135 y 140) para un usuario de un servicio de difusion de canales multiples que escucha un canal particular proporcionan alertas sobre el contenido actualmente disponible en otros canales, los cuales son de interes para el usuario. Se pueden presentar corrientes de datos auxiliares de interes para presentarse junto con la transmision de audio de un canal relacionado o no relacionado. El sistema y el metodo incluyen almacenar criterios asociados con la programacion o contenido auxiliar de interes para un usuario y buscar identificadores unicos dentro de la senal de difusion significando la disponibilidad de contenido que satisfaga los criterios. El contenido de interes puede ser, por ejemplo, informacion sobre trafico (105, 110, 120, 111 y 125), juegos deportivos disponibles en otros canales, puntajes de juegos, inventario u otros precios de instrumentos de comercio, encabezados de noticias o informacion sobre viajes.

Description

PROGRAMAS Y ALERTAS DE DATOS Y CORRIENTES DE DATOS AUXILIARES EN UN SISTEMA DE DIFUSIÓN DE CANALES MÚLTIPLES REFERENCIA CRUZADA A OTRAS SOLICITUDES Está solicitud reclama el beneficio de la Solicitud de Patente Provisional de los Estados Unidos 60/534,751, presentada el 6 de Enero del 2004, la descripción se incorpora aquí por referencia.

CAMPO TÉCNICO La presente invención se refiere a sistemas de difusión de canales múltiples, y más particularmente a proporcionar a un usuario un sistema de difusión de canales múltiples con programa y/o alertas de datos con respecto a información disponible en otros canales dentro del sistema de difusión de canales múltiples así como con corrientes de datos auxiliares que pueden ser de interés al usuario.

INFORMACIÓN DE ANTECEDENTES Con la llegada de la tecnología de satélite terrestre, ahora existe disponible un número de servicios de radio de satélite digital que difunden cientos de canales de programación a suscriptores en automóviles, botes y otras ubicaciones de base terrestre. Los consumidores disfrutan la claridad de la señal de tales sistemas de difusión de canales múltiples, así como la conveniencia de no tener que escuchar comerciales, ya que estos servicios generalmente están basados en un modelo de negocio libre de comercial y de cuota de suscriptor. Aunque existe una gran variedad de canales de programación disponibles, los suscriptores tienden a escuchar pocos canales, y generalmente, un canal la mayoría del tiempo. Sin embargo, ya que existe de alguna forma un contenido de cruce entre canales, así como el hecho que muchos usuarios tienen múltiples intereses a través de una gran variedad de música y otros géneros de contenido de canal, es poco probable que mientras un consumidor particular escucha un canal, el contenido de otros canales puede ser de interés para él ó ella. Adicionalmente, en el mundo de la televisión, los consumidores de medios se han acostumbrado a ver un programa en una ventana de vista principal y simultáneamente tener disponible una corriente de datos a base de textos que continuamente corre a través de la parte inferior de la pantalla. Por ejemplo, esto se ve en noticias de medio y difusiones deportivas mayores tal como el canal de noticias de Fox, el canal ESPN o Bloomberg. La característica análoga para radio de satélite es la capacidad de escuchar un canal mientras tiene información auxiliar tal como puntajes de juegos, últimos precios de inventario, alertas de clima, etc. simultáneamente disponibles en una presentación de receptor. Convencionalmente, una forma de encontrar más eficientemente programación de interés a un oyente particular sería para obtener programaciones de programa detallado antes y cambios de canal para escuchar siempre canales particulares, o simplemente revisar continuamente a través de varios canales como se hace con los dispositivos de control remoto de televisión, y manteniéndolo cambiante hasta que se localiza una canción, artista, noticias, o canal de deporte de interés. Dado el hecho que los sistemas de difusión de canales múltiples, tal como, por ejemplo, servicios de radio de satélite digital, pueden procesar, distribuir y formatear las corrientes de bits, difunden en numerosas formas, tienen oportunidades para proporcionar, junto con corrientes de bits de audio particulares, datos de texto y otros datos no de audio que pueden ser de interés a un usuario. Un ejemplo para el cual se ha utilizado esta capacidad es la descripción de los audio clips (audio corto) que se reproducen. En tales implementaciones, los datos de texto se pueden fijar dentro de la corriente de bits de audio de cada uno de los canales de audio de difusión. Tales datos de textos frecuentemente se denominan como Texto descriptivo de programa ó "PDT". El PDT se puede utilizar para presentar información a un usuario que es descriptivo del contenido de audio que él o ella está actualmente escuchando. Tales datos pueden incluir, por ejemplo, el nombre de la canción, el artista que reproduce, el compositor y otra información asociada. Alternativamente, los datos PDT, se pueden enviar en una corriente de bits separada de los datos de audio en un canal de servicio asociado. La Solicitud de Patente de E.U.A. No.09/900, 935, bajo la asignación común con la misma, contiene una descripción detallada de cómo un receptor puede buscar a través de PDT transmitido para todos los canales en un sistema de difusión de canales múltiples, los datos ya sea al analizar el PDT de canal de servicios o PDT fijo dentro de cada canal de audio, y determinar si cualquiera de los datos de PDT concuerda con cualquiera de las elecciones de audio en una lista de reproducción definida por el usuario. Si se encuentra tal concordancia como, un receptor, basándose en clasificaciones definidas por usuario relativo de reproducción de audio actualmente escuchada y la reproducción de audio que recientemente concordó, puede sintonizar automáticamente el canal en donde se está reproduciendo la sección de audio con cordada. La descripción de la Solicitud de Patente E.U.A. No. 09/900,935, se incorpora aquí completamente por esta referencia. Además de la utilidad de tal característica, existen otras elecciones posibles además de utilizar PDT para localizar concordancias en una lista de reproducción y después ya sea cambiar estaciones o no cambiar estaciones basándose en reglas definidas por usuarios. La capacidad de sistema de difusión de canales múltiples de transmitir simultáneamente audio así como texto y otros datos también se puede utilizar para proporcionar a los usuarios una variedad de otros servicios deseables. Por ejemplo, los oyentes que desean continuar escuchando un canal particular sin cambiar a un juego de deportes dado de interés para ellos. Sin embargo, pueden desear alertarse si el puntaje cambia, o al menos cuando ocurre un cambio significativo en el puntaje. O, por ejemplo, un usuario puede desear mantenerse alerta en los índices de marcado de inventario, o un cierto número de inventarios en particular, mientras disfruta otra programación de audio. O, por ejemplo, mientras maneja a un destino en donde existen varias rutas posibles puede desear estar alertado cuando está disponible un reporte de tráfico y después, una vez que ha escuchado el reporte, ser capaz de convenientemente regresar al canal anterior. De esa forma se desea tener en la técnica un sistema y método que puedan proporcionar eficazmente a los usuarios de sistemas de difusión de canales múltiples formas alternativas para seleccionar contenido de audio de interés en un canal particular que no se está reproduciendo actualmente así como proporcionar corrientes de datos auxiliares para presentarse junto con programaciones de audio relacionadas y no relacionadas.

COMPENDIO DE LA INVENCIÓN Las modalidades ilustrativas de la presente invención proporcionan un sistema y método para un usuario de un servicio de difusión de canales múltiples que escucha un canal particular con alertas sobre el contenido actualmente disponible en otros canales, que son de interés para el usuario. Además, las corrientes de datos auxiliares de interés se pueden presentar para presentarse junto con la transmisión de audio de un canal relacionado o no relacionado. El método incluye, por ejemplo, almacenar criterios asociados con programación o contenido auxiliar de interés para un usuario y buscar identificadores únicos dentro de la señal de transmisión que significa la capacidad de contenido que satisface el criterio. En modalidades ilustrativas de la presente invención, tales identificadores únicos pueden estar contenidos en un canal de servicios. El método además puede incluir alertar a un usuario de en qué canal de tal contenido de interés que satisface tal criterio se localiza, automáticamente dirigido a un usuario a tal canal, y para corrientes de datos auxiliares, presentar los datos en una presentación de receptor. En modalidades ilustrativas de la presente invención, el contenido de interés, puede, por ejemplo, ser información de tráfico, juegos de deportes disponibles en otros canales, puntajes de deportes, inventario u otros precios de instrumentos de comercio, encabezados de noticias o información de viajes.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 ilustra una adquisición de mensaje de tráfico ilustrativa y sistema de entrega de acuerdo con una modalidad ilustrativa de la presente invención; La Figura 2 ilustra un formato de mensaje de descriptor de datos ilustrativos de acuerdo con una modalidad ilustrativa de la presente invención; La Figura 3 ilustra una estructura de marco PDT ilustrativa de acuerdo con una modalidad ilustrativa de la presente invención; La Figura 4 ilustra un formato de marco de PDT de observación ilustrativo de acuerdo con una modalidad ilustrativa de la presente invención; La Figura 5 ilustra un flujo de procedimiento ilustrativo para construir una lista de mercado de tráfico de acuerdo con una modalidad ilustrativa de la presente invención; La Figura 6 ilustra un flujo de procedimiento ilustrativo para una búsqueda de botón de salto en modo de tráfico de acuerdo con una modalidad ilustrativa de la presente invención; La Figura 7 ilustra un flujo de procedimiento de alerta de juego ilustrativo de acuerdo con una modalidad ilustrativa de la presente invención; Las Figuras 8-15 son instantáneas ilustrativas que ilustran operación de una característica de botón de salto de acuerdo con una modalidad ilustrativa de la presente invención; La Figura 16 ilustra códigos de ciudad de tres letras ilustrativos para uso en una función de alerta de tráfico de acuerdo con una modalidad ilustrativa de la presente invención; La Figura 17(a) ilustra identificadores únicos ilustrativos para juegos de deportes de acuerdo con una modalidad ilustrativa de la presente invención; La Figura 17(b) ilustra formatos de actualización de puntaje de deportes de acuerdo con una modalidad ilustrativa de la presente invención; Las Figuras 18-21 ilustran varias designaciones de equipo ilustrativas para usarse en una función de alerta de deportes ilustrativa de acuerdo con una modalidad ilustrativa de la presente invención; Las Figuras 22-26 ilustran formatos de datos para una corriente de datos de precio de inventario auxiliar ilustrativo de acuerdo con una modalidad ilustrativa de la presente invención.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN En modalidades ilustrativas de la presente invención, además de canales de audio con contenidos de entretenimiento, los sistemas de difusión de canales múltiples también pueden proporcionar a los usuarios con noticias y otro contenido de información crítico en tiempo. Por ejemplo, si la información de tráfico está disponible a través de un sistema de difusión de canales múltiples para una variedad de locales, un suscriptor que viaja dentro de uno o a través de muchos de tales locales desearía acceder actualizaciones para tal información de tráfico mientras se hacen disponibles. Adicionalmente, durante un día de comercio dado un suscriptor puede ser avisado si una o mas seguridades designadas se ha ido arriba o abajo en precio por un intervalo importante. O, un oyente puede desear ser avisado del puntaje en uno ó más juegos de deporte de interés.

Sin importar eso, tal usuario puede no desear simplemente escuchar un canal de audio que no proporciona nada más que información de tráfico de difusión o precios de mercado de inventario. Adicionalmente, puede no desear escuchar la difusión completa de un juego de deporte. Tal oyente puede preferir escuchar sus canales de entretenimiento favoritos y solo cambiar a las estaciones cuando aquellos bits de información que son de interés para el se hacen disponibles en un canal financiero de tráfico, deportes o noticias. Alternativamente, él puede desear cambiar todos, pero más que eso puede continuar recibiendo información auxiliar en una forma de texto ó gráfico en una presentación de receptor. En modalidades ilustrativas de la presente invención, varías aplicaciones en un receptor de sistema de difusión de canales múltiples, por ejemplo, puede utilizar banderas o corrientes de bit de identificación de programa dentro de una corriente de difusión como identificador único. En tales modalidades, estos identificadores únicos se pueden utilizar para notificar a un usuario de una concordancia de un favorito almacenado, tal como, por ejemplo, una canción, un artista, un equipo de deportes, un espectáculo, ó de una actualización de difusión auxiliar, tal como, por ejemplo, condiciones de tráfico, clima, puntajes de deportes, un avance o disminución en el precio de mercado de un instrumento comerciado, etc. En modalidades ilustrativas de la presente invención, tales banderas o identificadores, por ejemplo, se pueden transmitir en un canal decodificado selectivamente, tal como una música dedicada, canal de plática o datos, o en un canal decodificado universalmente, tal como, por ejemplo, un canal de servicio.

Canción Favorita, Audio Clip o Artista En modalidades ilustrativas de acuerdo con la presente invención un identificador único, puede por ejemplo, estar asociado con cada canción o audio (se nota que la presente invención no está restringida a música, pero igualmente aplica a cualquier tipo de contenido recibido), o incluso con cada artista que graba, compositor o anfitrión de espectáculos. Adicionalmente, estos identificadores únicos pueden ser independientes, y enviar en diferentes campos de datos, o pueden estar interconectados en un sistema jerárquico, tal como, por ejemplo, en donde el número particular de bits en un identificador significa un artista que graba y otra porción del identificador significa una canción o un audio particular. Al utilizar las tecnologías de interfase de usuario convencionales, un usuario, por ejemplo, puede almacenar en una memoria de receptor un número de tales identíficadores favoritos en estructura de datos apropiados. Al utilizar las tecnologías de datos convencionales, un receptor también puede buscar automáticamente una corriente de bit entrante para localizar concordancias a la lista almacenada de identificadores. Al utilizar tales identificadores únicos y tales métodos de búsqueda, en modalidades ilustrativas en la presente invención una aplicación de receptor puede alertar a los usuarios cuando está reproduciéndose una canción o artista favorito en otro canal dentro del servicio de difusión de canales múltiples. Existen varios métodos para transmitir tales ¡dentificadores sónicos. Por ejemplo, se pueden fijar dentro de los datos descriptivos de programa, como se describirá posteriormente. En modalidades ilustrativas de la presente invención, un canal de audio, por ejemplo, puede tener datos de Texto Descriptivo de Programa ("PDT") asociados con él. Los datos de PDT pueden contener información sobre cada audio reproducido en el canal, tal como, por ejemplo, título de canción, nombre de artista, duración de canción, compositor, etc. Tales datos de PDT también pueden contener, por ejemplo, un campo llamado ID de programa ("PID"). Que pueden, por ejemplo, asociar un identificador único con una canción particular, y, por ejemplo, un campo llamado ID de artista ("AID") asociado con un artista que graba particular o personalidad de espectáculos. El PDT para un canal dado, por ejemplo, puede estar fijo en los datos de audio de canal o por ejemplo, puede ser transmitido globalmente en una o más servicios de sistema o canales de envío de mensajes. Adicionalmente, por ejemplo, el PDT se puede transmitir en ambas de estas corrientes de datos. Una ventaja de transmitir PDT globalmente es el hecho que todo el PDT para todos los canales en el sistema se puede enviar a todos los receptores en todo el tiempo, de esa forma les permite procesar estos datos en una variedad de forma. Una posibilidad de procesamiento con un canal de PDT global es buscar continuamente ¡dentificadores únicos de acuerdo con los métodos de la presente invención. Tal corriente de bits de transmisión de PDT global se debe denominar aquí como una corriente de bit de "PDT de Observación" ("LAPDT"). El LAPDT se denomina así debido a que permite a un receptor sintonizado en un canal "observar" a un amplio sistema en los contenidos de todos los otros canales simplemente procesar la corriente de bit de LAPDT. Al utilizar los datos de LAPDT, en modalidades ilustrativas de la presente invención una aplicación de receptor, por ejemplo, puede revisar el PDT de todos los canales para PIDs que concuerdan con aquellos guardados por el usuario como favorito. Una vez que se localizan tales PIDs, una aplicación de receptor puede, por ejemplo, alertar un usuario al generar un tono audible a un mensaje así como al presentar un mensaje de texto en una pantalla de presentación. Tal mensaje, por ejemplo, puede informar al usuario que canal del contenido asociado con el PID asociado está reproduciendo actualmente ó está próximo a reproducirse. Como se notó anteriormente, en modalidades ilustrativas de acuerdo con la presente invención, un campo de PDT adicional llamada ID de artista ("AID") puede contener análogamente un número asociado con un artista o grupo particular. Por consiguiente, el receptor puede revisar LAPDT de todo los canales de un AID particular. Como se notó, en modalidades ilustrativas de la presente invención, un AID puede ser un PID truncado para simplificar la cuenta de bits si es deseado. Los datos de PDT así como los datos de mayúsculas LAPDT se pueden organizar en una estructura de datos de transmisión en una variedad de formatos, que utilizan técnicas conocidas.

Alerta de Tráfico y Actualización En una forma similar como se describió anteriormente en el contexto de una alerta de canción o artista, un usuario también se alerta cuando la información de tráfico de interés para el usuario está disponible en un canal diferente. Sin embargo, en un contexto de mensaje de tráfico, existen algunas diferencias de búsqueda de un PID estático asociado con una canción o artista dado para localizar contenido de interés que se debe considerar. Por ejemplo, cada mensaje de tráfico es único, y su valor para un usuario generalmente depende del tiempo. De esa forma, en modalidades ilustrativas de acuerdo con la presente invención, la información de tráfico textual puede estar incluida en el PDT de un canal de audio particular (tal como un canal de tráfico dedicado) y también o alternativamente en LA-PDT en un canal de servicios. Alternativamente, puede haber algunos canales de tipo de plática o noticias en donde la información de tráfico se proporciona en ciertos intervalos de tiempo y puede haber PDT asociado con las porciones de tráfico de tales canales. De esa forma los PIDs de mensaje de tráfico, por ejemplo, se pueden transmitir en PDT y LA-PDT, con el valor de PID articulado para cada nuevo mensaje de tráfico. Se entiende que un PID en este contexto puede referirse a un identificador único asociado con un mensaje de tráfico dado, como se describe más adelante. Sin embargo, debido a que cada PID de mensaje usualmente es diferente, un sistema puede no simplemente desear buscar un PID estático como en el artista o escenario de canción favorito. Por consiguiente, se pueden implementar varios algoritmos para proporcionar a un usuario señales o alertas de actualizaciones de tráfico automática. Por ejemplo, un usuario puede almacenar en un receptor un grupo de criterios para determinar que tipos de mensajes de tráfico un usuario desea que se actualicen. En tales modalidades ilustrativas, en cualquier momento que se reciban nuevos datos de tráfico que satisfagan esté grupo almacenado, el usuario recibe una alerta. Tal criterio puede incluir, por ejemplo ciudad o ubicación, tipo de incidente de tráfico, seguridad de la situación de tráfico, mensaje que se relaciona a un local especifico dentro de una ubicación particular, etc. Las banderas y/ o campos de datos en un PID de mensaje de tráfico, por ejemplo, puede transportar propiedades en el mensaje de tráfico y se puede utilizar, por ejemplo, como entradas para un algoritmo de búsqueda. Por ejemplo, un PID de mensaje de tráfico puede tener un campo para un local, que se puede referir, a la ciudad, pueblo, o vecindario que es el sujeto de mensaje de tráfico. Adicionalmente, PID de mensaje de tráfico puede tener campos para severidad e incidente, sub local (tal como por ejemplo, la autopista de ventura, santabárbara, century city, hollywood en norte, etc. como sub locales en el área de los Ángeles), tipo de incidentes (tal como, por ejemplo, accidente, congestión, condiciones de clima, etc.), estampa de tiempo o cualquier otro campo que refleja sumarias de interés o categorías. Al utilizar tai sistema, que analiza un grupo del usuario de criterio reduce la concordancia de una o más de los campos dentro de los PIDs. La Figura 1 ilustra un sistema de entrega de mensaje de tráfico ilustrativo de acuerdo con la modalidad ilustrativa de la presente invención. Con referencia a la Figura 1, se ilustra una arquitectura de sistema de tráfico ilustrativo total. La información de tráfico, por ejemplo, se puede recolectar y agregar en 100 para una variedad de locales. En general un proveedor de contenido de tráfico de tercera parte puede proporcionar información de tráfico a un servicio de difusión de canales múltiples. Se puede cargar la información de tráfico a un Servidor de Proveedor de tráfico 105 para transmisión a través del muro interno 110 mediante Internet 120 y a través del muro externo 111 a un Servidor de Datos 125. El servidor de datos 125, por ejemplo, es en donde el sistema de difusión de canales múltiples recibe primero los datos de tráfico cuando se utiliza un proveedor de contenido de tráfico de tercera parte. El Servidor de Datos 125 puede transmitir la información de tráfico al Sistema de Difusión 130 del sistema de difusión de canales múltiples, tal como se opera por el asignado aquí, Sirius Satellite Radio Inc. En el Sistema de difusión 130, la información de tráfico, por ejemplo, se puede fijar como datos PDT en una o más canales de tráfico y también, alternativamente, como datos de LAPDT en un canal de servicios, como se describió anteriormente. Como resultado, la información de tráfico se puede enviar en la señal de difusión a través de satélites 135 a los suscriptores 140. Al implementar los datos de tráfico como datos de PDT en conexión con un canal de tráfico en el sistema, o simplemente como una corriente de datos auxiliar lo PIDs de información de tráfico se pueden hacer para ajustarse dentro de un nuevo protocolo o un protocolo preexistente para la transmisión de datos PDT. Estos pueden ser útil para la compatibilidad hacia atrás con receptores que no fácilmente pueden actualizarse para procesar un nuevo sistema de mensaje en un canal de servicio o envío de mensaje, que frecuentemente es el caso. Mientras existan varias implementaciones ilustrativas de los métodos de la presente invención, en muchos sistemas de difusión existentes, la implementación más eficiente y óptima no siempre puede ser realizada debido a los asuntos de compatibilidad hacia atrás. La presente invención, en contraste puede permitir tal compatibilidad hacía atrás. Se describen aquí dos tipos de implementación de alertas de programa y datos. Estas implementaciones incluyen en donde un protocolo separado para envío de mensajes se crea para la categoría de datos, tal como mensajes para tráfico, instrumentos de comercio, deportes, etc.; e implementaciones en donde una categoría de mensaje dado, por ejemplo, tráfico deportes, se envía en un protocolo existente designado para transferir otro tipo de datos tal como, por ejemplo, LAPDT. Adicionalmente, se describen aquí dos tipos fundamentales o categorías de datos. Estos dos tipos incluyen datos que se relacionan al contenido disponible en otros canales, tal como puntajes de deportes o PID e información de AID y datos que son auxiliares, y no están simultáneamente disponibles en algún canal de audio dentro del sistema, tal como, por ejemplo, precios de inventarios. Algunos datos también podrían pertenecer a más categorías tal como por ejemplo, datos de tráfico. Como un ejemplo, puede haber PIDS de tráfico que transportan información disponible en canales de tráfico así como actualizaciones de tráfico más detalladas sólo disponibles como una opción premium (por ejemplo, actualizaciones de condición en tiempo real de información de navegación, etc.) que se podría proporcionar como una corriente de datos auxiliar. Mientras se proporcionan ejemplos para cada tipo de datos y cada tipo de implementación, no toda la implementación para cada tipo de datos posibles se presenta, si se entiende que cada tipo de datos se puede implementar al utilizar cualquier tipo de implementación.

Otras Aplicaciones Las siguientes aplicaciones son similares al contexto de mensaje de tráfico y pueden involucrar contenido de información que es dinámico, y se pueden rastrear mejor al utilizar PIDs dinámicos. De esa forma modalidades ilustrativas de la presente invención, un usuario sin embargo se puede alertar para el contenido de interés de una forma similar a la descrita anteriormente en el contexto de mensaje de tráfico. En modalidades ilustrativas de la presente invención, un usuario se puede actualizar en cualquier momento que se reciben nuevos datos de puntaje de deportes que satisface un grupo de específico de criterio (tal como, por ejemplo, equipo, liga, oponente, ultimo puntaje que estaba dentro o fuera de una cierta extensión de punto, etc.) se puede especificar por un usuario. Las banderas y / o campos de datos en la información de puntaje de deportes transmitida se puede concentrar en ó de otra forma está incluida en un IDD Puntaje de Deportes ("SSID") por ejemplo, puede transportar propiedades de el mensaje de puntaje de deportes que se puede utilizar como entradas para un algoritmo de búsqueda. En modalidades ilustrativas de acuerdo con la presente invención, un usuario también se puede actualizar en cualquier momento que se reciben nuevos datos de clima que satisfacen un grupo especifico de criterios (tal como, por ejemplo, ciudad/ubicación, consejeros/severidad, etc.) las banderas y/o campos de identificador único en la información de clima transmitido transportar propiedades del mensaje de clima que se puede utilizar como entradas para un algoritmo de búsqueda. En modalidades ilustrativas de acuerdo con la presente invención, un usuario se puede actualizar en cualquier momento que se reciben nuevos datos de precio para una seguridad o comodidad dada ("mensajes financieros") que satisfacen un grupo específico de criterios (tal como, por ejemplo, símbolo de tele impresor, índice, ganancia más alta, volumen más alto, aumento importante o caída etc.). Las banderas y/o identificadores únicos en la información de seguridad de su comodidad transmitida pueden transportar propiedades del mensaje financiero y de esa forma ser entrada para un algoritmo de búsqueda.

Alerta de Juego y Categorías Virtuales En modalidades ilustrativas de la presente invención, un usuario se puede alertar cuando un juego de deportes de interés está disponible en otro canal. En una modalidad ilustrativa de la presente invención, se puede utilizar un protocolo de mensaje de datos separado para enviar está información en un canal de servicio global. En otra modalidad ilustrativa estos datos se pueden ajustar en un protocolo existente para enviar LAPDT para facilitar compatibilidad hacia atrás. Este ejemplo último ahora se da descrito. Como se noto un campo de PDT de PID en un protocolo de LAPDT en un canal de servicios se puede utilizar para transmitir datos de tráfico, juego por juego de deportes, y otro contenido especializado. Tal campo de PDT de PID se puede utilizar para soportar una característica de búsqueda de canción como se describió en la Solicitud de patente de E.U.A. No. 09/900,935 (la 'solicitud '935").

Adaptación de LAPDT La Figura 2 ilustra un protocolo de envío de mensaje ilustrativo para un canal de servicio, llamado un Mensaje de descriptor de datos, con campos definidos como se muestra. Este mensaje representa, por ejemplo, un formato estándar para enviar información globalmente en un canal de servicios. En este protocolo ilustrativo, puede haber un campo de SEQ_ID que indica si la CARGA UTIL (por ejemplo, contenido) contenido en el mensaje es (1) auto contenido (SEQ_ID = 3), (ii) el primero en una secuencia de mensajes (SEQ_ID=1), (iii) el intermedio en una secuencia de mensajes (SEQ_ID = 0), o (iv) el último en una secuencia de mensajes (SEQ_ID = 2). En este protocolo, solo existe una secuencia de mensajes múltiples en un momento. Por ejemplo, si una secuencia se inicia con SEQ_ID=1 y otra SEQ_ID = 1 se encuentra antes de que se encuentra SEQ_ID = 2, la primera secuencia se debe reclamar inválida y descartar. Sin embargo, un mensaje de SEQ_ID = 3 puede llegar en cualquier momento, incluso durante una secuencia de mensajes múlti les. Un campo de CARGA UTIL_TIPO indica el formato de CARGA UTIL. Por ejemplo, si CARGA UTIL_TIPO igual a cero los datos se descomprimen. Si CARGA UTIL_T1P0 = 1, los datos se pueden comprimir utilizando un algoritmo de compresión conocido tal como compresión RHC. Para soportar muchos tipos diferentes de datos, se puede utilizar un campo DOSC_ID para indicar el tipo de datos contenidos en el campo CARGA UTIL del Mensajes descriptor de datos. Por ejemplo, se DOSC_ID es 0, el mensaje puede transportar LAPDT, y si DOSC_ID es 1 el mensaje puede transportar tiempo y datos de fecha para sincronización de receptor. El campo SEQ_NUM contiene, por ejemplo, un número de secuencia 256 de módulo utilizado para rastrear mensajes que requieren cargas útiles múltiples. El SEQ_NUM solo se debe incrementar cuando SEQ_ID no es igual a 3. El campo SEQ_NUM no se restablece para cada secuencia de mensaje para permitir que el receptor distinga fácilmente entre masajes en una secuencia particular y de secuencia en secuencia. Por ejemplo, para una secuencia de tres mensajes con valores de SEQ_NUM 255,0, y 1, la siguiente secuencia de cuatro mensajes tendría valores de SEQ_NUM de 2, 3, 4, y 5. El campo de CARGA UTIL contiene la carga útil de datos real. El formato de campo CARGA UTIL depende del valor de DOSC_ID. Para PDT de observación, una longitud de secuencia de mensaje generalmente es un mensaje (por ejemplo, SEQ_ID = 3). Para PDT de observación, el campo de CARGA UTIL_FORMATO DEL Mensaje Descriptor de datos se puede establecer a 0 (descomprimidos) o 1 (comprimido). Si CARGA UTIL_FORMATO = 1 , el campo CARGA UTIL contenido en el Mensaje descriptor de datos se debe descomprimir antes de procesar. La Figura 3 ilustra un formato ilustrativo para una estructura de PDT en un canal de audio, (por ejemplo, no PDT en un canal de servicios). Una carga útil descomprimida ilustrativa para PDT de observación se muestra en el Cuadro a más adelante. La carga útil consiste de, por ejemplo, un orden de PDT para N canales, cada uno de los cuales contiene un número de canal y una Estructura de PDT. Esta Estructura de PDT se modifica de la mostrada Figura 3 a esa mostrada Figura 4 para optimizar ancho de banda en el canal de servicio.

Cuadro A- Carga útil para PDT de observación La Figura 4 difiere de la Figura 3 en la que los marcadores de BOF y EOF se remueven y se remueven los de limitantes de campo (0x13). Esto es, por ejemplo, debido a que un receptor puede utilizar los valores de Tipo de campo como un delimitante entre los campos de PDT. Al final de la Estructura de PDT está un carácter de control EOF de LAPDT (OxFF). Esto se puede utilizar por un receptor, por ejemplo, para determinar el final de la Estructura PDT para cada canal. El primer Tipo de campo PDT limpio nunca se debe enviar en PDT de observación. Los Tipo de campo para Texto promocional se pueden delinear de 0x20-0x23 a 0x90-0x93 como se muestra en la Figura 4. Si un Artista y títulos son iguales (por ejemplo, el nombre del contenido de audio es el mismo que el realizador, tal como para un espectáculo llamado por el anfitrión), un Tipo de campo de 0x94 se puede utilizar para indicar un campo que contiene tanto un Artista como un título más que utilizar campos separados para Artista y título. Si un Tipo de campo sigue inmediatamente por otro Tipo de campo o LAPDT EOF, los Datos de campo para el Tipos de campo se deben asumir como nulos. Estos se utilizan para aclarar los datos para ese Tipo de campo en particular. La longitud de Estructura de PDT máxima en este ejemplo es 56 Bytes que incluyen Todos los valores de tipo de campo y el LAPDT EOF. Si la estructura es más larga que 56 Bytes, la estructura PDT se puede truncar utilizando el siguiente esquema ilustrativo: 1.- Si la Estructura PDT contiene un campo de compositor, solo el apellido del compositor se debe mantener. El apellido se encuentra al remover cualquiera de los espacios de prueba del extremo de la fila. Después, la búsqueda para este primer carácter de espacio del final de la fila y mantener cada uno después de que (no incluyendo los espacios de prueba removidos anteriormente) como el nuevo campo de Compositor. Si la estructura de PDT resultante con el campo de Compositor truncado tiene una longitud de 56 Bytes ó menos, no se necesitan ninguna otra truncación. 2.- El número de Tipos de Campo se debe limitar a ID de canción Título, artista, y compositor. Si en la estructura PDT resultante y tiene una longitud de 56 Bytes ó menos, no es necesaria ninguna otra truncación. 3.- Todos los campos en la estructura PDT se debe truncar bajo 10 Bytes (incluye el Tipo de campo). Después, 1 Byte se debe agregar de nuevo a cada campo o hasta que ya sea que cualquier Datos de campo para cada campo está de regreso a su longitud original ó la longitud de estructura total igual a 56 Bytes. En modalidades ilustrativas de la presente invención un nuevo formato de PID que mantiene la propiedad única de PIDs utilizados para identificación de canción y que también es compatible hacia atrás con una cacterística de búsqueda de canción se definirá y utilizara con un DOSC_ID = 0, o tipo de mensaje LAPDT. Por ejemplo, en un protocolo de LAPDT en donde PID se refiere a caracteres de bandera especiales de 1 ID de canción, por ejemplo, se puede utilizar en el campo de PID para indicar contenido especializado. De esa forma, por ejemplo, el tráfico se puede identificar únicamente con el carácter "*" en la primera posición del campo de PID. El juego juego de deportes, por ejemplo, se puede identificar únicamente con el carácter "@" en la primera posición del carácter del campo PID y en deporte o liga, por ejemplo, después se puede identificar por un carácter único en la segunda posición de carácter en el campo de PID. Los deportes profesionales por ejemplo, pueden utilizar y Deportes colegiales, por ejemplo, pueden utilizar letras minúsculas. Tal sistema de identificadores únicos ilustrativos se proporcionan en el Cuadro B más adelante: Cuadro B Otro contenido especializado, por ejemplo, se puede agregar como sea necesaria al utilizar identificadores únicos en la primera posición del carácter del campo PID. Los caracteres que siguen el identificador único pueden proporcionar información más detallada con respecto tipo de programa que se transmite dentro de cada categoría de contenido especializado.

Formato de PID para mercados de tráfico En modalidades ilustrativas de la presente invención, un formato de PID para mercados de tráfico puede llenar el campo de PID con los cuatro caracteres: "*XXX". Como se noto, el primer carácter, por ejemplo, puede ser "*" (un asterisco-ASCII 0x2A) y los últimos tres caracteres ("XXX") pueden ser un designador de tres letras (todas mayúsculas) para la ciudad / mercado (amortiguado con un carácter bajo marcador si es necesario). El carácter "*" de esa forma se puede utilizar para garantizar cualidad única de programas de tráfico. El cuadro C más adelante proporciona PIDs ilustrativas para algunos mercados ilustrativos soportados por un sistema de difusión de canales múltiples ilustrativos (_indica un carácter bajo marcador - ASCII 0x5F): Cuadro C De esa forma, por ejemplo, los PIDs ilustrativos para un canal que alternativamente transporta difusiones de tráfico / clima para Washington DC y Baltimore pueden tener los siguientes formatos:*DC_y *Bal.

Formato de PID para juegos de juego por juego En modalidades ilustrativas de la presente invención, un sistema puede elegir difundir juegos de deportes de juego por juego en una variedad de canales, no solo en canales asignados a una categoría de "DEPORTES". Tales canales, por ejemplo, pueden transportar contenido sin deportes a una mayoría de tiempo y se puede asignar a otras categorías. De esa forma, es útil identificar dinámicamente cuando los juegos de juego por juego se están difundiendo en estos canales y así alertar a los usuarios. Para deportes de equipo, por ejemplo un sistema puede difundir el juego en un canal que elige la alimentación de difusión de uno de los dos equipos por ejemplo, recoger la alimentación de Detroit para un juego de la NBA de las redes de los pistones de Detroit / Nueva Jersey. Ó, por ejemplo, un sistema puede difundir el juego en dos canales que utilizan las alimentaciones de transmisión de ambos de los dos equipos. Por ejemplo, poner la alimentación de Chicago para los Osos de Chicago / Gigantes de Nueva York en un canal y poner la alimentación de Nueva York en otro canal. La siguiente discusión proporciona formatos de PID ilustrativos para cada una de estas situaciones ilustrativas.

Difusión individual por juego (Canal individual) El formato de PID para juego por juego para difusiones individuales puede ser similar al formato de PID de tráfico. El campo de PID se llena, por ejemplo, con ocho caracteres:"@XYYYZZZ". El primer carácter es "@" (en símbolo - ASCII 0x40) para designar juego por juego de deportes, el segundo carácter "x" es el deporte único / identificador de liga [por ejemplo, "F" (ASCII 0x46) para designar NFL], los siguientes tres caracteres 1!???" SOn el designador de tres letras (todas mayúsculas) para uno de los dos equipos (acolchonado con un carácter bajo puntaje si es necesario), y los últimos tres caracteres "ZZZ" son el designador de tres letras (todas mayúsculas) del otro equipo (amortiguado con un carácter bajo puntajes si es necesario). El carácter "@" se puede utilizar para garantizar cualidad única de programas de juego por juego de deporte. El cuadro D más adelante ilustra un PID para una difusión basada en un juego de NBA de las Avispas de Nueva Orleans / Caballos de Indiana.

Cuadro D Dos difusiones por juego (dos canales) El formato PID para juegos de juego por juego para dos difusiones es similar al formato de PID de tráfico. El campo de PID en cada canal se puede llenar de cinco caracteres: "@XYYY". El primer carácter es "@" (en símbolo - ASCII 0x40) para designar juego por juego de deportes, el segundo carácter, "X" es el deporte único / identificador de liga [por ejemplo, "F"(ASCII 0x46) para subrayado para designar NFL] y los últimos tres caracteres son designador de tres letras (todas mayúsculas) para el equipo cuya alimentación de transmisión se utiliza (amortiguado con un carácter bajo puntaje si es necesario). El carácter "@" se utiliza para garantizar cualidad única de programas juego por juego de deportes. El cuadro E más adelante ilustra un PID ilustrativo para una difusión basada en un juego de NFL de los Leones de Detroit / Jefes de Kansas City.

Cuadro D Característica en el botón de salto en modo de tráfico En modalidades ilustrativas de la presente invención, se puede implementar un botón de salto para cambiar a un canal en respuesta a una alerta. Se ilustra un botón de salto ilustrativo en la Figura 8 y además se describe más adelante en conexión con la Figura 8. Está característica puede permitir la selección de un botón de receptor para causar que la información deseada se proporcione al usuario. Como un ejemplo, un botón de salto en modo de tráfico involucra varios pasos. El primer paso es para que el receptor recolecte, por ejemplo, los mercados de tráfico, por ejemplo, la señal de Sirius con el fin de construir la lista de levantamiento de menú de mercados de tráfico. El segundo paso es buscar los cambios de PID entrantes para una concordancia con el mercado seleccionado por el usuario después de que se activa Botones alto en un mundo de tráfico. La lista de mercado de tráfico se puede purgar con una actualización de mapa de canal. Asegura que si el sistema de difusión cambia los mercados para los cuales la información de tráfico se difunden, el receptor no listará ninguno de los mercados antiguos / eliminados después del cambio. Después de que se completa la actualización de mapa de canal, el receptor busca los cambios de PID entrantes para PIDs de tráfico, y agrega cualquiera de los nuevos mercados a la lista de mercados de tráfico presentados al usuario. Se debe notar que ya que los reportes de tráfico pueden ser hasta cuatro minutos de longitud, y dos mercados pueden compartir tiempo de un canal individual, el procedimiento para recolectar la lista completa de difusión de mercados de tráfico por el sistema puede tomar ocho minutos (o más). La lista de mercado presentada al usuario simplemente los designadores de mercado tres letras de la difusión en formación dentro del PID de tráfico (bajo puntaje de prueba removido antes de la presentación). Esto no es información codificada en el receptor. Se ilustra un procedimiento de construcción de lista de mercado de tráfico ilustrativo en la Figura 5, que muestra recepción de PIDs de tráfico por el receptor par construir dinámicamente una lista de mercado de tráfico cada vez que el receptor se enciende. Con la activación de botón de salto en el modo de tráfico, el receptor puede realizar una revisión de PID de todos los canales (tráfico) para buscar el reporte de tráfico de mercado particular. Si se encuentra una concordancia para el mercado de tráfico en está revisión inicial, el receptor automáticamente sintoniza el canal con la concordancia. Si no se encuentra ninguna concordancia en la revisión inicial, el receptor después busca los cambios PID entrantes para un PID de tráfico y una concordancia para el mercado de tráfico deseado. Una vez que se encuentra una concordancia, el receptor automáticamente sintoniza el canal con la concordancia. Se ilustra un diagrama de flujo simplificado ilustrativo de un procedimiento de búsqueda PID de tráfico en la Figura 6, que muestra el procesamiento por el receptor después que un usuario refleja el botón de salto para buscar el PID de tráfico asociado con el botón de salto.

Alerta de Juego En modalidades ilustrativas de la presente invención, se puede proporcionar una funcionalidad de alerta de juego ("Alerta de Juego"). Existen dos componentes para una Alerta de Juego. Un componente es la selección del usuario de un equipo favorito (equipo / logotipo de NFL) en un menú principal. El otro es una operación de búsqueda para un equipo guardado. En modalidades ilustrativas de la presente invención, las selección de equipo favorito, la lista de designadores de tres letras para cada equipo de NFL (ver sección en Designadores para Equipo de NFL más adelante en esté documento) se pueden codificar en un receptor (asociado con los nombres de equipo). Esto puede ser la única información codificada en el receptor (por ejemplo, ningún otro designador de mercado de tráfico ó información de designador de equipos está codificado en el receptor). Una vez que el usuario guarda un equipo favorito el receptor continuamente buscara los cambios de PID entrantes para un juego de juego por juego de NFL (PID comenzando con "@F") que contiene el designador de tres letras "WWW" para el equipo favorito del usuario. Buscara ambos PIDs de difusión individual (formato de PID "@FYYYZZZ") y PIDs de difusión doble (formato de PID "@FYYY") para una concordancia (YYY=WWW o ZZZ=WWW). Sise encuentra una concordancia, por ejemplo, una Aleta de juego de aparición instantánea se puede presentar a un usuario. El segundo componente es la operación de buscar por equipos guardados. Cuando el usuario realiza un guardado (por ejemplo, a través de una operación de MEM de presión / sostenimiento) durante una difusión de juego por juego de deportes, el receptor, por ejemplo puede guardar el identificador de deporte / liga y uno de los identificadores de equipo (si hay alguno) (obtenido de la difusión de información del PID de deportes) en memoria (mismas que el PDT). Si está presente más de un identificador de equipo, el receptor impulsara al usuario para elegir entre los dos equipos al presentar ambos designadores de tres letras de equipo (bajo puntaje de pruebas no presentadas) si permite a los radios seleccionar uno de ellos. En la pantalla de recordamíento de memoria, el receptor presentará la liga / deporte y el código de equipo de tres letras (bajo puntaje de prueba no presentado) más que el PDT. (Esto proporciona mejor reconocimiento por el usuario). Cuando se habilitó una función de búsqueda para la entrada de juego por juego de deportes, el receptor buscará continuamente los cambios de PID entrantes para una concordancia al deporte / liga y equipos. (El PIDs entrante contendrá uno o dos equipos). Si se encuentra una concordancia se puede presentar una Alerta de Juego de aparición instantánea al usuario. Una Alerta de Juego ilustrativa de este procedimiento se ilustra en la Figura 7.

Categorías Virtuales La característica de la categoría virtual extiende la operación de categoría de un receptor dado a categorías de construcción de canales dinámicamente por el receptor en cada encendido. Para mejorar la experiencia en el usuario, se pueden agregar más categorías a la función de categoría al buscarlas los cambio de PID entrantes, y construir categorías "virtuales" basándose en la información contenida dentro de está. Un grupo de categorías virtuales puede incluir Tráfico (por ejemplo, canales con información de tráfico, PID comienza con "*"), Zona de NFL (por ejemplo, canales con juego por juego de NFL, PID comienza con "@H"), Zona NBA (por ejemplo, canales con juego por juego de NBA, PID, comienza con "@B"), Zona NHL (por ejemplo, canales con juego por juego de NHL, PID comienza con "@H"), y Otros (por ejemplo, canales con otros juego por juego de deportes, PID comienza con "@" pero no para NFL / NBA / NHL). Una categoría virtual es solo presentada se existe al menos una entrada de canal activo.

En cada encendido, las categorías virtuales se pueden iniciar para hacer listas vacías. El receptor debe monítorear continuamente cambios de PID para manejar la lista de canales en cada categoría virtual: 1.- Si un PID satisface el criterio para una de las cinco categorías virtuales y su canal correspondiente actualmente no es un miembro de esa categoría virtual, se agrega a la categoría virtual. 2.- Si un PID se reciba para un canal que pertenece a uno de las cinco categorías virtuales y el PID ya no satisface el criterio para esa categoría virtual, se elimina de la categoría virtual. Ambas revisiones se deben realizar en cada cambio PID entrante. Si se determina que el algoritmo anterior es demasiado intensivo computacionalmente, en modalidades ilustrativas alternas de la presente invención, un receptor puede realizar simplemente una revisión periódica de PID separa a todos los canales y construir la lista de canal para cada una de las cinco categorías virtuales de los resultados de la revisión. Si este método se elige, la revisión se debe realizar al menos una vez por dos minutos.

Designadores Ilustrativos Para Equipos de NFL Los designadores proporcionados en el Cuadro F más adelante están codificados en asociación con los nombres de equipo presentado para elegir equipo favorito de la Pantalla de exhibición y características de Alerta de juego.

Cuadro F Designadores ilustrativos para equipos de NBA En modalidades ilustrativas de la presente invención los designadores en Cuadro G más adelante se pueden utilizar equipos de NBA. Estos designadores no necesitan codificarse en el receptor.

Cuadro G Designadores ilustrativos para Equipos de NHL En modalidades ilustrativas de la presente invención los designadores en el Cuadro H más adelante se pueden utilizar para equipos de NBA. Estos designadores no necesitan ser codificados en el receptor.

Cuadro H Debido a que existe un identificador para la liga de deportes, un receptor puede buscar y recopilar una lista de todos los juegos de Jugar por Jugar de difusión por la liga de deportes. De esa forma, en modalidades ilustrativas de la presente invención, el contenido para cualquier categoría se puede localizar en cualquier canal en el sistema de difusión y enlazar por el identificador utilizado por la categoría virtual.

En modalidades ilustrativas también puede existir, por ejemplo, cualquier número de categorías virtuales tal como las siguientes: TRAFICO ZONA NFL ZONA DE NBA ZONA DE NHL MAS DEPORTES FÚTBOL COLEGIAL BASKETBALL COLEGIAL MAS DEPORTES COLEGIALES Ml ZONA DE JUEGO En modalidades ilustrativas de la presente invención, la funcionalidad de receptor, mientras en cualquiera de las categorías virtuales puede ser la misma que categorías regulares, una categoría virtual sólo se presenta si existe al menos una concordancia a la categoría virtual. "Mas Deportes" puede incluir todos los juegos de Juego por Juego de deportes profesional que no pertenecen a NFL; NBA o NHL.

Puede incluir, por ejemplo, juegos presentados en Radio de ESPN para MLB, carreras, etc. "Más deportes colegiales" pueden incluir otros juegos colegiales tal como baseball, lacrosse, volleyball, etc. "Mí zona de juego", por ejemplo, puede incluir de juegos de juego por juegos por los equipos que el usuario selecciono para equipos "alerta de juego" así como todos los equipos guardados para entradas de búsqueda. Por ejemplo, el presionar un botón de presentación en el receptor un usuario puede articular los nombres de equipo con puntajes actuales y estados de juego (por ejemplo, uno para el primer cuarto, primer periodo, OT para Tiempo extra). La Figura 17(a) ilustra un sistema jerárquico ilustrativo para identificadores únicos para PIDs de deportes que se pueden implementar en mensajes LAPDT (al utilizar los PIDs ilustrados en la Figura 17(a) como el campo de PID de un mensaje de LAPDT, tal como por ejemplo, el campo de "ID de canción" de la Figura 4). En el sistema ilustrado, todos los deportes comparten un primer carácter único "@" y cada deporte tiene un identificador único en el segundo lugar de caracteres. Para juegos de difusión doble, los siguientes tres caracteres son una designación de ciudad / equipo que representa la alimentación de audio de esa ciudad (por ejemplo, el juego por juego de audio de equipo de "casa"), y para los juegos de difusión individual ambas ciudades / equipo involucrados se codifican, como se muestra, que resulten el uso de los ocho caracteres. La Figura 17(b) ilustra formatos ilustrativos para presentar puntajes de deportes en una pantalla de receptor en modalidades ilustrativas de la presente invención, y una llave que explica los términos utilizados en lo formatos ilustrativos. De esa forma, como se notó un usuario puede no desear sintonizar el canal difunde el juego, sin embargo puede desear mantenerse al tanto del puntaje. En una modalidad ilustrativa de la presente invención, estos formatos también se pueden implementar como parte de un mensaje de LAPDT, que utiliza a los campos de Artista y Título (0x1 y 0x2 en la Figura 4, respectivamente) de un mensaje de LAPDT. Esto facilita la compatibilidad hacia atrás, como se notó. Alternativamente, un tipo de mensaje de datos separado (por ejemplo, nuevo) (similar a los tipos de mensaje de impresor de inventario descrito más adelante) se puede definir para puntajes de deportes. Tal formato de mensajes no se debe forzar para ajustarse en los campos de LAPDT, y pueden ser el tipo de ID de DOSC de puntajes de deportes, pueden tener una carga útil ilustrativa definida, por ejemplo, con los siguientes campos: identificador de liga, identificador de equipo 1, puntaje de equipo 1, identíficador de equipo 2, puntaje de equipo 2, identificador de periodo / cuarto / entrada. Puede ser útil incluir una fecha para el juego así como ser capaz de enviar / distinguir juegos para múltiples fechas. El identificador de equipos simplemente podría ser una fila de ASCII o puede se índice en un cuadro de filas ASCII. El cuadro puede ser un cuadro estático (incluido en el receptor de producción) o un cuadro dinámico con provisión para actualizaciones en el aire (por ejemplo, a través de otros mensajes DOSC_ID como un ejemplo, como se describió en la descripción de impresor de inventario más adelante). Los anchos de bit apropiado de cada campo se pueden elegir para (a) acomodar el número máximo de combinaciones contempladas para cada campo (con algún cuarto para expansión futura) y (b) optimizar eficiencia de banda ancha. Las Figuras 18-21 ilustran designaciones ilustrativas que se pueden utilizar en modalidades ilustrativas de la presente invención. Los códigos de ciudad se pueden obtener al monitorear y adquirir PIDs, y no codificar los siguientes nombres. Estos nombres son mercado de ciudad actualmente disponibles y pueden o no ser futuros mercados para el sistema de difusión de canales múltiples. Para abreviaciones de ciudad que solo contienen dos letras se puede agregar un espacio antes de difundir para mantener consistencia. La Figura 18 es una lista de equipo de NFL ilustrativa, la Figura 19 una lista NHL ilustrativa, la Figura 20 una lista de NBA ilustrativa, y finalmente la Figura 21, una lista ilustrativa para uso con puntajes de deportes colegiales.

II. Botón de Salto En modalidades ilustrativas de acuerdo con la presente invención, se puede proporcionar otra característica que permite a un usuario sintonizar fácilmente información de tráfico / clima para esta ciudad de interés, y después regresar a la programación de música / plática / deportes que estaba escuchando previamente. Esto se puede implementar, por ejemplo, por un botón de salto. Un botón de salto es un botón preestablecido único que permite a un usuario sintonizar un canal específico y sintonizar de nuevo el canal previo con la cantidad mínima de interacción de usuario. En modalidades ilustrativas de la presente invención para lograr una interfase de usuario simple, se puede crear un botón extra para servir como el botón de Salto. En la Figura 8 se muestra un botón de salto ilustrativo en la parte inferior de una interfase de usuario de receptor.

Opciones de Menú Por ejemplo, puede haber una Opción de Menú en la presentación de receptor llamada "Configuraciones de Salto" en un árbol de Opciones de Menú principal, como se muestra en la Figura 9(a). Una vez que un usuario presiona el botón de Seleccionar para ingresar la pantalla de "Configuración de Salto", una presentación, tal como se ilustra en la Figura 9(b), por ejemplo, puede aparecer durante 2 segundos proporcionando direcciones para la selección de usuario y después mostrar dos opciones para el usuario como se muestra en la Figura 9(c): Tráfico: XXX y Establecimiento de Salto, en donde XXX es la abreviación de 3 letras de una ciudad en donde el reporte de tráfico / clima está disponible (la pantalla ilustrativa ilustrada en la Figura 9(c) muestra "ATL" para Atlanta). La barra resaltada, así como el icono de botón de Salto debe estar en la selección de usuario actual. En modalidades ilustrativas de la presente invención un botón de Salto se puede programar para funcionar como una de dos opciones proporcionadas anteriormente, pero no ambas. En tales modalidades, el icono de botón de Salto siempre debe aparecer a la izquierda de la función de botón de Salto seleccionado de usuario.

Tráfico Al desplazar la barra resaltada a "Tráfico: XXX", como se muestra en la Figura 10(a) y al presionar y liberar, por ejemplo, un botón de Seleccionar, un usuario se mueve una capa más abajo en el menú de selección de ciudad. Aquí, como se muestra en la Figura 10(b), por ejemplo, una línea superior puede presentar. "Elegir mercado de tráfico" con todas las listas de ciudad disponibles de ciudad, en su forma de abreviación de tres letras, en orden alfabético. La vara resaltada predetermina la selección de ciudad actual. Controlar la interfase de receptor, para rotar la perilla decodificadora ó presionar el botón de CH+/CH-, se desplaza a través de la lista de ciudad y cada ciudad se resalta para selección. El usuario puede presionar de Seleccionar mientras se resalta la selección de ciudad para confirmar una selección. La ID de ciudad después se guarda para característica de Altos. Si el usuario elige cancelar la acción si hacer una selección (al presionar el Menú para regresar para el menú principal), se retiene a selección de ID de ciudad. Ya que la abreviación de tres letras de mercado de ciudad se recolecta a través del monitoreo de recolección de PDT después de cada actualización de información de control de global de sistema, habrá casos para cuando el usuario pretende hacer una selección de ciudad antes de que estén disponibles todos los mercados de ciudad. En el caso en donde no se ha recolectado ninguna de las IDS de ciudad, por ejemplo, una aparición instantánea puede aparecer indicando "actualizar lista de ciudad" durante dos segundos como se muestra en la Figura 10(c) y después regresar al usuario a la opción de menú previa. Con una actualización de canal de difusión, se puede reconstruir una nueva lista de ciudad. La lista de ciudad se puede guardar a memoria y de esa forma puede estar disponible en el siguiente encendido, hasta la siguiente actualización de canal.

Tipo de salto En modalidades ilustrativas de la presente invención, desplazar la barra resaltada a "Tráfico: XXX" y presionar y liberar el botón de Seleccionar Confirma que el botón de Saltos se utilizara para función de Grupo de saltó. La presentación puede aparecer, por ejemplo durante dos segundos, proporcionando direcciones para establecer el canal de Grupo de Saltos, antes de regresar a la pantalla de "seleccionar configuración de saltos". El icono de botón Salto debe aparecer después de "grupo de saltos" en vez del "Tráfico: XXX". Está secuencia se ilustra en las Figuras 11(a)-(c).

Activación Inicial Cuando se presiona el Botón de Salto o se presione mantiene durante el primer momento (por ejemplo, en primer uso o reestablecimiento de fábrica), puede aparecer un mensaje instantáneo que indica "Botón de saltó" durante dos segundos, antes de llevar al usuario a la pantalla de "configuración de saltos" de Opciones de menú. Un usuario después puede seguir los pasos descritos para elegir la funcionalidad de botón de saltó. Está funcionalidad se ilustra en las Figuras 12 (a)-(c). El icono de botón de Salto usualmente no aparecerá después de cualquier opción hasta que el usuario hace una selección, como se muestra en la Figura 12 (c). Si un usuario sale si hacer una selección, el estado de "Activación inicial" debe aplicarse hasta que se hace una selección.

Sintonización y Alerta Mientras se escucha cualquier programación de audio, una presión o liberación del botón Salto una presión y mantenimiento de I Botón de salto puede activar la funcionalidad de botón de Salto. Si se determina que está es la primera vez que se activa el botón de Salto, después aplica la descripción de Activación inicial. De otra forma el receptor puede reconocer si el botón de Salto se ha establecido al reporte de tráfico de ciudad ó simplemente como un botón de Grupo de Salto.

Mercado de tráfico / ciudad Una vez que se determina que el botón de saltó se establece a Tráfico (Mercado de ciudad), el receptor, por ejemplo, puede detectar si se ha establecido una ID de ciudad. Si no se ha seleccionado ninguna ID de ciudad, por ejemplo, un usuario regresa a la pantalla de activación inicial sin establecer una ciudad, por ejemplo, puede aparecer un mensaje instantáneo que indica "Botón no establecido" como se muestra en la Figura 13(a).

En el caso que se establezca ID de ciudad, el receptor debe iniciar inmediatamente la revisión de todos los canales para una ID de ciudad que concuerda en el campo de PID. La Figura 13(b) muestra una interfase de usuario ilustrativa en el comienzo de tal búsqueda, en donde el canal actual, artista, y canción se presenta. Mientras se busca la ID de ciudad, aparece un mensaje instantáneo, con "XXX pendientes", en donde XXX es la abreviación de tres letras del nombre de ciudad, durante dos segundos que sesifican que el receptor de hecho está buscando y esperando el reporte de tráfico / clima deseado. Por ejemplo, esto se muestra en la instantánea ilustrativa de la Figura 13(c). El indicador de banda del botón derecho de la pantalla de esa forma cambia al icono de botón de Alto para significar que el receptor está en un modo de búsqueda como se muestra en la Figura 13(d). El icono de botón de salto, por ejemplo, puede alternar en Encendido y Apagado cada un segundo mientras la búsqueda este activa. En modalidades ilustrativas de la presente invención, presionar el botón de la primera Salto de nuevo durante la búsqueda cancela la búsqueda y regresa al modo de operación normal y se restablece el icono de botón de salto. El receptor continúa la búsqueda hasta que se encuentra una concordancia o el usuario ingresa cualquier modo de lista (lista de canal, lista de categoría, y Las primeras opciones de Menú) antes de que se encuentre una concordancia. Cuando existe cualquiera de modo de lista y regresa a la modo de operación normal, se resume la búsqueda ID de ciudad, Una vez que se encuentra una concordancia, se puede presentar un mensaje instantáneo durante un segundo que indica "saltar a XXX", en donde XXX es la abreviación de tres letras del nombre de ciudad, como se muestra, por ejemplo, para la ciudad de Nueva York, en la Figura 29(e). En modalidades ilustrativas de la presente invención, un receptor en este punto puede sintonizar el canal de tráfico deseado inmediatamente y sonar un tono audible confirmatorio. Después se restablece el icono de botón de Alto. Antes de cualquier sintonización subsecuente a canales, si el usuario impresiona de nuevo el botón Alto, el receptor sintoniza el canal previo. Si ningún canal previo está disponible, por ejemplo, primer canal sintonizado para después de un ciclo de energía, por ejemplo, puede haber un sonido audible y al receptor puede permanecer sintonizado al canal actual.

Grupo de Salto El Grupo de Salto cuando el botón de Salto se elige para actuar como un botón Preestablecido mejorado. Establecer el Grupo de salto puede ser lo mismo que cualquier otro botón de preestableció convencional: mientras escucha cualquiera de los canales de sistema, una presión y mantenimiento del botón de Alto guarda el canal actual como el canal de grupo de saltos. Cuando se guarda un canal como un Grupo de Salto, el indicador de banda cambiara al icono de botón de Alto para indicar que el canal actual está asociado con el botón de Alto, como se muestra en la Figura 14(a).

Si se determina la Configuración de botón de salto para hacer un grupo de salto antes de que se elija un canal de Grupo de salto, presionar y liberar el botón de Salto genera un mensaje Instantáneo de "Botón no establecido" como se muestra en la Figura 14(b). Si se establece el canal, presionar y liberar el botón de Alto sintoniza el receptor al canal de Grupo de Salto inmediatamente. Si el canal es el canal actual el receptor sintoniza el canal previo. Sí ningún canal previo está disponible, por ejemplo, primer canal sintonizado para después de un ciclo de energía debe haber un sonido audible y el receptor permanece sintonizado al canal actual. Cuando se establece el canal de Grupo de Salto puede funcionar como cualquier otro preestablecido en un Modo de sintonización preestablecido. El canal de Grupo de Saltos se puede presentar en la vista Preestablecida antes del banco A, y puede estar disponible a través de CH+/CH- antes del banco A o después del banco C.

Reemplazo En modalidades ilustrativas de la presente invención, una ID de ciudad de tráfico se puede reemplazar al cambiarla en la opción de menú, configuración de salto, elegir mercado de tráfico, como se describió anteriormente. El canal de Grupo de saltos se puede reemplazar al programar otro canal como el canal Grupo de Salto. Para resumir la descripción anterior, la Figura 15 ilustra el flujo de procedimiento interfase de usuario mientras se utiliza el botón de Salto. En modalidades ilustrativas de la presente invención, un receptor puede tener una memoria interna para almacenar las IDS de ciudad de tráfico para en mapa de canal actual, La elección deseada de usuario y cualquier canal de Grupo de Salto seleccionado por usuario. La Figura 16 ilustra códigos de ciudad de tres letras para uso en designaciones de tráfico en modalidades ilustrativas de la presente invención. lll. Corrientes de Datos Auxiliares En lo que se ha descrito de esa forma, el contenido con respecto a lo que un usuario se puede alertar está disponible en algún otro canal dentro del sistema de difusión de canales múltiples. De esa forma un usuario tiene la opción, ya sea de brincar, por ejemplo, un reporte de tráfico o un juego de deportes particular, o simplemente tener un puntaje de deportes virtual o mensaje de tráfico presentado sin cambiar canales. Lo que se describe más adelante son corrientes de datos auxiliares ilustrativas, no asociadas con ningún contenido de canal particular, que se puede presentar como texto en una pantalla de presentación de receptor mientras un usuario escucha un canal dado de interés.

Datos de Inventario y Financieros En modalidades ilustrativas de la presente invención, se puede enviar una corriente de datos de impresor de inventario en una serie de mensajes de canal de servicios. Lo que se describe más adelante es la arquitectura física, sintaxis de mensaje metodologías de control entre un servido de impresor de inventario y un sistema de difusión de canales múltiples para soportar corriente en tiempo real de símbolos de inventario. La modalidad ilustrativa descrita se debe referir algunas veces como "Impresor de inventarios". En modalidades ilustrativas, un servicio de difusión, por ejemplo, puede enfrentarse a un tiempo real, ó minuto 20 en tiempo real retrasado, el proveedor de información de precio de inventario y, por ejemplo, puede filtrarlo para proporcionar el precio para inventarios individuales de los tres intercambios E.U.A. principales, Intercambio de Inventario Americano, NYSE y NASDAQ. Adicionalmente, los índices mayores también se pueden transportar en el servicio, tal como DJIA, S&P 500, etc. en una modalidad ilustrativa de la presente invención, se espera que aproximadamente se 6600 valores de instrumento se puedan transmitir y que tales valores puedan cambiar cada 2.5 minutos. Está información se puede transportar en un canal de servicio, por ejemplo, como un tipo distinto de un mensaje de Canal de Servicios Sobre Datos (DOSC). En una modalidad ilustrativa de la presente invención, un receptor un receptor puede proporcionar un mecanismo para elegir hasta 20 inventarios para presentar en un impresor de desplazamiento. El receptor, por ejemplo, puede presentar un símbolo de impresor, precio y cambio de precio desde la apertura de la sesión. El receptor, por ejemplo, puede contener una lista de 6500 inventarios activos en ROM y facilitar la selección de estos inventarios aún impresor personalizado. Para facilitar los nuevos inventarios (IPO's etc.) siendo agregados a la lista, un sistema ilustrativo también, por ejemplo, puede transmitir una lista de nuevos símbolos de inventario como una tabla de actualización cada 15 a 30 minutos. Está tabla de actualización, por ejemplo, se puede almacenar en memoria no volátil en el receptor. En una modalidad ilustrativa de la presente invención, el número de inventarios cubierto por el servicio puede ser aproximadamente 6600. En crecimiento más grande mientras se agregan más inventarios. La información para cada inventario, por ejemplo, puede incluir lo siguiente: índice de inventario, un número de 14 bits utilizado como un identificador único dentro de este servicio. Esto permite que se controlen hasta 16348 símbolos de inventarios únicos. Impresor de inventario, típicamente una fila de 1-8 caracteres en mayúscula. Se permite hasta 28 caracteres. Precio de inventario en centavos, cualquier entero en el rango de 0 a $168512.04. Cambio diario en centavos, cualquier entero con magnitud que no excede $739.88. En algunas modalidades de la presente invención, en donde el ancho de banda de envío de mensaje de canal de servicios se utiliza completamente, con el fin de transportar carga útil adicional, se puede necesitar cambios para modos de canal de servios que pueden causar una reducción de ancho de banda disponible para canales de audio. El formato de Mensaje de descriptor de datos de la figura 2, en modalidades ilustrativas de la presente invención, se puede modificar ligeramente como se notó más adelante para transportar datos de instrumento financiera tal como Impresor de Inventario. La CARGA ÚTIL _ TIPO, como por ejemplo, se puede extender para incluir Tipo 2= compresión que utiliza algoritmo de impresor de inventario (TBD) y Tipo =Compresión que utiliza algoritmo de cuadro de actualización. Adicionalmente, en modalidades ilustrativas de la presente invención los valores de DOSC_ID pueden por ejemplo extenderse para incluir 2 nuevos tipos de mensaje 4 y 5 como se presenta en el Cuadro I más adelante. En ei Mensaje Descriptor de datos, el campo SEQ__ID indica si la CARGA UTIL contenida en el mensaje está auto contenida (SEQ_ID = 3), la primera en una secuencia de mensaje (SEQ_ID = 1), la intermedia en una secuencia de mensajes (SEQ_ID = 0), o la ultima en una secuencia de mensajes (SEQ_ID = 2). En Impresor de Inventario, por ejemplo, solo debe haber una secuencia de mensajes múltiples en cualquier momento. Por ejemplo, si una secuencia se inicia con SEQ_ID = 1 y otra SEQ_ID = 1 se encuentra antes de que encuentre una SEQ_ID = 2, la primera secuencia se debe reclamar inválida y descartar. Sin embargo, un mensaje de SEQ_ID = 3 puede llegar en cualquier momento incluso durante una secuencia de mensajes múltiples. El campo de CARGA UTIL-BAJO TIPO indica el formato de CARGA UTIL. Si la CARAG UTIL_TIPO = 0, los datos se descomprimen. Si CARGA UTIL_TIPO = 1, los datos se comprimen utilizado con presión RHC. Si la CARGA UTIL_TlPO = 2, los datos se comprimen utilizando algoritmo de compresión de Impresor de Inventario (TBD). Si CARGA UTIL_TIPO = 3, los datos se comprimen utilizando algoritmo de compresión de Tabla de Actualización (TBD). Para soportar muchos tipos diferentes de datos, el campo de DOSC_ID, de esa forma se puede utilizar para indicar el tipo de datos contenido en el campo CARGA UTIL del Mensaje Descriptor de datos. El Cuadro 1 contiene valore validos ilustrativos para DOSC_ID en una modalidad ilustrativa de la presente invención que implementa LAPDT, tiempo y datos, y envío de mensajes de Impresor de Inventarios. Como se describe anteriormente, el envío de mensaje de LAPDT también se puede utilizar para alertas de tráfico y juego, así como para proporcionar una corriente de datos ilustrativa de puntajes de deportes.

Cuadro I: Valores válidos para DOSC ID El campo de SEQ_NUM contiene un número de secuencia de módulo-256. En modalidades ilustrativas de la presente invención, el SEQ_NUM solo se debe incrementar cuando el SEQ_ID no es igual a 3. El campo SEQ_NUM usualmente, por ejemplo, no se reestablecerá para cada secuencia de mensaje para permitir al receptor distinguir fácilmente entre mensajes en una secuencia particular y de secuencia a secuencia. Por ejemplo, par una secuencia de tres mensajes con valores de SEQ_NUM de 255, 0, y 1, la siguiente secuencia de cuatro mensajes tendrá valores de SEQ_NUM de 2, 3, 4, 5. El campo de CARGA UTIL contiene la carga útil de datos reales. El formato de campo de CARGA UTIL depende del valor de DOSCJD.

Nuevos tipos de datos de DOSC Impresor de Inventario (DOSC_lD = 4) En modalidades ilustrativas de la presente invención para facilitar la transmisión de información de precio de impresor de inventario se puede definir un nuevo tipo de mensaje de DOSC con DOSCJD = 4.

Tipo de Secuencia En modalidades ilustrativas para Impresor de Inventario, la longitud de secuencia de mensajes siempre es un mensaje (es decir, SEQ_lD = 3).

Formato de Carga Útil La Figura 23 ¡lustra un formato de carga útil ilustrativa para Impresor de Inventario. Para Impresor de Inventario, el campo de CARGA UTIL_FORMATO del Mensaje Descriptor de Datos se puede establecer a cero (comprimido) ó 2 (comprimido TBD de algoritmo de Impresor de Inventario). Si CAGA UTIL_FORMATO = 2, el campo de CARGA UTIL contenido en el Mensaje descriptor de Datos se puede descomprimir antes de procesarse en modalidades ilustrativas. Sin embargo el INVENTARIOJNDICE e INVENTARIOS_EN_MEBSAJES siempre pueden estar descomprimidos y pueden examinarse para determinar si un inventario de interés está contenido en un mensaje actual. Para evitar los gastos de enviar símbolos de inventario ASCII para cada inventario se puede asignar por ejemplo un valor de índice y mantener por un servidor de Impresor de Inventarios. Cada valor de índice es único y, por ejemplo, también se puede almacenar en memoria no volátil en el receptor. El campo de INVENTARIO_INDICE puede contener un valor no registrado de 14 bits que representa la observación de símbolo de inventario para el primer precio de almacenamiento y cambiar el valor en la CARGA UTIL. Todos los inventarios contenidos dentro del mensaje, por ejemplo, pueden tener valores concurrentes, para que solo un valor de índice necesite transmitirse por mensaje. Si un radio recibe un valor de 1NVENTARI0_INDICE que actualmente no está en la memoria del receptor, puede, en tal modalidad ilustrativa ser descartado. El campo de INVENTARIO_EN_MENSAJE, por ejemplo, puede contener un valor de 8 bits que es la cuenta de número de precios de inventario y pares de valor de cambio contenidos en el mensaje actual. El campo de CARGA UTIL puede contener precio de inventario y valores de cambio empaquetados como se especifica más adelante.

Rango de Valor y Precio de Inventario Para codificar un precio de inventario se puede utilizar por ejemplo un VALOR _ RANGO (VR) seguido por un INVENTARIO PRECIO, expresado en centavos, como sigue en el Cuadro J: Cuadro J-Rango de valor y Valor de Inventario Cambio de Precio para Precio de Apertura En modalidades ilustrativas de la presente invención un radio, por ejemplo, puede presentar símbolo, precio de inventario y cambio para el precio de apertura. Los campos de CAMBIO _ VALOR, SIGNO_BIT y VALOR_RANGO_CAMBIO se pueden codificar como se muestra más adelante.

Cuadro K-Símbolo de Cambio de precio Cuadro L-Cambio de Valor de Rango Se nota que cuando el CAMBIO _ VALOR = 0. es decir el INVENTARIO _ PRECIO es el mismo que el inicio de precio de día, solo se necesita transmitir VALOR _ RANGO _ CAMBIO = "11" y el CAMBIO _ VALOR se puede omitir del mensaje. La Figura 24 ilustra un mensaje de carga útil de típico ilustrativo con un INVENTARIO _ ÍNDICE e INVENTARIO _ PRECIO en el rango de $2.56 - $84.52 y un VALOR _ RANGO _ CAMBIO $2.56 - $84.52. En modalidades ilustrativas de la presente invención, frecuentemente es deseable maximizar el número de pares de INVENTARIO _ PRECIO / CAMBIO _ VALOR que se pueden ajustar en el tamaño de mensaje máximo, mientras solo se envia un INVENTARIO _ ÍNDICE individual en cada mensaje.

Calculo de Carga Útil En modalidades ilustrativas de la presente invención, el tamaño de mensajes de DOSC máximo es 255 Bytes para un mensaje en donde SEQ _ ID = 3 (mensaje individual) el encabezado de mensaje de Descriptor de datos = 2 bytes de esa forma deja 253 bytes para encabezar en carga útil de Inventario. Si se asume que el inventario promedio está en el rango de precio 2.56 - 84.52 y su cambio está en el rango +/- $2.56 a 23.04 entonces (2 + 13 + 1+2 + 13) = 13 bits inventario se requiere. El INVENTARIO _ ÍNDICE e INVENTARIO EN MENSAJE requieren 14+18 = 22 bits. Debido a que en esta modalidad ilustrativa están disponibles 256 Bytes (igual a 2024 bits), 2024-22 = 2002 bits están disponibles para información de inventario. 2002/31 bits / inventario genera un máximo de 64 inventarios en un mensaje promedio. De esa forma, la velocidad total para 64 inventarios es (bits por 64 inventarios) + (Encabezado de mensajes de inventarios) + (Encabezado descriptor de Datos) = (64*31) + 22 + 16 = 2022 bits. Por lo tanto, los bits totales para 6600 inventarios es (2002/64)*6600 = 208518 bits. Se transmite en un ciclo de 2.5 por minuto después esto sería 1390 bps.

Cuadro de Símbolo de Actualización (DOSC_ID = 5) Para facilitar la adición futura de Símbolos de inventarios (IPO's, y cambios de símbolo) en modalidades ilustrativas de la presente invención, un receptor también soportará la noción de un cuadro de símbolo de actualización. El índice de este cuadro seguirá secuencialmente del cuadro de símbolo de inventario principal, para que si la última entrada en el cuadro de símbolo de inventario fue N, la primera entrada en el cuadro de Símbolos de actualización es N + 1. El cuadro de símbolo de actualización, por ejemplo, se puede difundir menos frecuentemente que los precios de inventario. El cuadro de actualización, por ejemplo, se puede almacenar en el radio en memoria no volátil. Para facilitar la transmisión de información de precio de impresor de inventario se puede definir, por ejemplo, un nuevo tipo de mensaje de DOSC con DOSC _ ID = 5. Además de un CUADRO _ NUMERO para identificación, el cuerpo del cuadro de actualización, por ejemplo, puede contener un INVENTARIO _ ÍNDICE de 14 bits y algún número de longitud de funcionamiento delimitado INVENTARIO _ SÍMBOLO (s).

Tipo de Secuencia Para el Cuadro de Símbolo de Actualización, la longitud de secuencia de mensaje puede estar contenida en un mensaje individual (es decir SEQ _ ID = 3), o puede separar mensajes múltiples (SEQ _ ID = 1) para el primero en una secuencia de mensajes, el intermedio en una secuencia de mensajes (SEQ _ ID = 0) o el último en una secuencia de mensajes (SEQ _ ID = 2). Solo debe haber una secuencia de mensajes múltiples en un momento. Por ejemplo, si una secuencia se inicia con SEQ _ ID = 1 y otra SEQ _ ID = 1 se encuentra antes de que se encuentre SEQ _ ID = 2, la primera secuencia se debe reclamar invalida y descartar. Sin embargo, un mensaje SEQ _ ID = 3 puede llegar en cualquier momento, incluso durante una secuencia de mensajes múltiples.

Formato de Carga Útil Para el Impresor de Inventario el campo de CARGA UTIL _ FORMATO del Mensaje descriptor de datos se puede establecer a 0 (descomprimido) o 3 (comprimido con TBD Cuadro de Actualización). Si CARGA UTIL _ FORMATO = 3, el campo de CARGA UTIL contenido en el mensaje descriptor de datos debe descomprimirse antes de procesar. Sin embargo, los campo de CUADRO _ NUMERO y FINALIZAR usualmente están descomprimidos y se pueden examinar para determinar si el mensaje se puede procesar. La Figura 25 ilustra un Mensaje de Cuadro de Símbolos de Actualización Ilustrativo para Impresor de Inventario. Con referencia a la figura 25, en modalidades ilustrativas de la presente invención, se pueden definir los campos como siguen. CUADRO _ NUMERO pueden contener un valor de 6 bits para identificar el cuadro, iniciando en CUADRO NUMERO = "000000". Un servidor de Impresor de Inventario, por ejemplo, puede anexar inventarios a este cuadro hasta que se haga una decisión para FINALIZAR el cuadro. Una vez que se ha FINALIZADO el cuadro, por ejemplo, no se puede permitir INVENTARIOS _ SÍMBOLOS o INVENTARIOS _ ÍNDICE para que se agregue al cuadro. De esa forma se puede agregar nuevos inventarios a un siguiente cuadro, tal como, por ejemplo, en donde CUADRO _ NUMERO = "000001". Está última característica previene a un Cuadro de Actualización de hacerse incluso más grande. Por ejemplo, puede permitir que se transmitan Cuadros de Actualización durante un periodo de tiempo, y después descontinuar cuando todos los receptores se reclaman para tener la actualización. Por ejemplo, los receptores pueden ignorar un mensaje de cuadro de actualización finalizado una vez que se sincronizan con una copia finalizada. Los campos restantes en la figura 25 se pueden definir como siguen: FINALIZAR 0 = Cuadro de Actualización NO finalizado, disponible para anexar Símbolos de Inventario. 1 = Cuadro de Actualización Finalizado, no se puede anexar información adicional.

EXTENDIDO _ LONGITUD DE FUNCIONAMIENTO 0 = Contador de Longitud de Funcionamiento de símbolo de Inventario (SRLC 3 bits para este mensaje (hasta 8 Caracteres para Símbolo de Inventario) 1 = Contador de Longitud de Funcionamiento de Símbolo de Inventario (SRLC) de 6 bits para este mensaje (hasta 28 Caracteres por símbolo de inventario). Actualmente todos los símbolos de inventario de los 3 intercambios de CUA tienen un símbolo de inventario corto de 8 caracteres o menos. Sin embargo están disponibles hasta 28 caracteres, en modalidades ilustrativas de la presente invención, para está información. Para facilitar esto, por ejemplo, mientras se introducen nuevos inventarios, o para símbolos que no conformar a este límite, EXTENDIDO _ LONGITUD DE FUNCIONAMIENTO = 1 cubre este caso. La Figura 26 ilustra un Mensaje de Cuadros de Símbolo de Actualización típico ilustrativo. Con referencia a esto, los campos se describen como sigue. Un campo de INVENTARIO _ ÍNDICE puede contener un índice de 14 bits único para el primer INVENTARIO _ SÍMBOLO en el mensaje actual. Un campo de INVENTARIOS EN MENSAJE, por ejemplo, puede contener un valor de 8 bits que es la cuenta del número de SRLC y pares de INVENTARIO _ SÍMBOLO contenidos en el mensaje actual. En modalidades ilustrativas de la presente invención, no se debe enviar pares de INVENTARIO _ SÍMBOLO (s) parciales / SRLC. El ultimo byte de una carga útil, por ejemplo, se puede llenar con 0's como sea necesario para que el byte se alinie y se ignore por el receptor. El SRLC- Contador de longitud de Funcionamiento de Inventario puede ser un valor de longitud de funcionamiento de 3 u 8 bits para el siguiente inventarío. En modalidades ilustrativas de la presente invención solo se permite un tipo de longitud de funcionamiento (ya sea 3 u 8) por mensaje. El Cuadro M más adelante es un cuadro de longitud de funcionamiento ilustrativo para el contador de 3 bits.

Cuadro M- Cuadro de Longitud de Funcionamiento de Inventario SRLC Cuadro de Símbolo de Inventario Un INVENTARIO _ SÍMBOLO, por ejemplo, puede se 1-28 caracteres si codificado, valore de 5 bits como se muestra en el Cuadro N: Cuadro N-Cuadro de Símbolo de Inventario Cuadro de Símbolo de Inventario Extendido Actualmente todas las igualdades de E.U.A. tienen caracteres alpha y se pueden describir completamente en el Cuadro N, sin embargo para facilitar la ansiedad de soportar símbolos de índice de inventarío (tal como S & P), que no requieren valores numéricos así como otras necesidades futuras, un cuadro Extensión de símbolo de inventario, por ejemplo, se puede definir en el Cuadro mas adelante. Esto niega la necesidad definir un cuadro de símbolos más largo para más inventario.

Cuadro O - Cuadro de Símbolo de Inventario Extendido De esa forma, en modalidades ilustrativas de la presente invención, una construcción de mensaje ilustrativo para mensajes de Impresor de Inventario, por ejemplo, puede ser como sigue: ...<Valor de Símbolo de lnventario> <Comienza Secuencia de Cuadro Extendido (11110)> <Símbolo de Cuadro Extendido> <Símbolo de Cuadro Extendido> <Termina Secuencia de Cuadro Extendido (11111)> <Valor de Símbolos de Inventarios;».

Interfase de Usuario En modalidades ilustrativas de la presente invención se puede alertar a un usuario y puede ingresar su criterio para actualización de sedas utilizando una variedad de ¡nterfases de usuarios / receptor de acuerdo con técnicas convencionales. Por ejemplo, tales modalidades de interfase pueden incluir, en el lado de salida (por ejemplo, salida aun usuario), mensajes de alerta audible, tal como, por ejemplo, tonos, campanas, o texto hablado generado por un sintetizador de voz en el receptor, así como, por ejemplo, presentaciones de texto. En el lado de entrada (por ejemplo, entrada de un usuario) un usuario puede interactuar, por ejemplo, con presentaciones conducidas por menú con botones de selección, teclas de flecha o perillas, para almacenar grupos definidos por usuarios de criterios de los varios tipos de mensaje como se describió anteriormente. La presente invención se describió en conexión con modalidades ilustrativas e implementaciones, solo como ejemplo. Se entiende por aquellos expertos en la técnica que se pueden hacer fácilmente modificaciones a cualquiera de las modalidades o implementaciones ilustrativas si apartarse materialmente del alcance o espíritu de la presente invención. 71 una entrada de acción al receptor. 5.- El método de acuerdo con la reivindicación 4, en donde los contenidos predeterminados pertenecen a una categoría virtual seleccionada por un usuario. 6.- El método de cuerdo con la reivindicación 1, en donde el contenido predeterminado de esta información de tráfico satisface ciertos criterios definidos por usuario. 7.- El método de acuerdo con la reivindicación 6, en donde dicho criterio definido por usuario incluye una ó más de ubicación, sub-ubicación, tipo de incidente de tráfico, y severidad de tráfico. 8.- El método de acuerdo con la reivindicación 1, en donde el contenido predeterminado se localiza al procesar uno o más sub-campos del identificador único de acuerdo con las reglas predeterminadas. 9.- El método de acuerdo con la reivindicación 1, en donde el identificador único se fija al menos en uno de: texto descriptivo de programa transmitido dentro del canal de audio; y texto descriptivo de programa de observación transmitido en un mensaje de canal de servicio. 10.- El método de acuerdo con la reivindicación 1, en donde el identíficador único se fija en un mensaje de canal de servicio de no LAPDT 11.- El método de acuerdo con la reivindicación 1, en donde el identificador único está asociado con tráfico o contenido de deportes

Claims

R El VI N D I CAC IONES 1.- En un sistema de difusión de canales múltiples, un método de alertar a un usuario de contenido predeterminado diferente al contenido proporcionado en un canal que actualmente se reproduce a un usuario, que comprende: asociar el contenido predeterminado con un identificador único; almacenar el identificador único asociado con el contenido predeterminado en un receptor; recibir el identificador único en el receptor; identificar el identificador único recibido como una concordancia para el usuario; y al menos uno de cambiar al usuario al canal en donde se proporciona el contenido predeterminado, que alerta al usuario al canal en donde se proporciona el contenido predeterminado, y proporcionar al usuario el contenido predeterminado a través de una presentación de texto y gráfica. 2.- El método de acuerdo con la reivindicación 1, en donde el contenido predeterminado es una pluralidad de contenidos predeterminados identificados por un usuario. 3.- El método de acuerdo con la reivindicación 2, en donde cada uno de la pluralidad de contenidos predeterminados tiene un identificador único respectivo. 4.- El método de acuerdo con la reivindicación 1, en donde dicha asociación de contenido predeterminado está en respuesta a en un canal que actualmente no se recibe. 12.- El método de acuerdo con la reivindicación 11, en donde el identificador único tiene un formato por el cual se puede distinguir claramente de un campo en un mensaje de texto descriptivo de programa. 13.- El método de acuerdo con la reivindicación 1, en donde el identificador único está asociado con datos auxiliares no transmitidos en ningún canal de audio en el sistema. 14.- En un sistema de difusión de audio de canales múltiples, un método para proporcionar datos auxiliares de interés para los usuarios, que comprende: enviar una corriente de datos de datos auxiliares en un canal de servicio; asociar cada dato en la corriente de datos con un identificador único; proporcionar datos a un usuario cuando el identificador único concuerda con una categoría seleccionada por el usuario. 15.- El método de acuerdo con la reivindicación 14, en donde la categoría es una categoría virtual. 16.- El método de acuerdo con la reivindicación 14, en donde los datos auxiliares son al menos uno de datos de tráfico premium, precios de instrumento comerciado, clima y puntajes de deportes. 17.- El método de acuerdo con la reivindicación 14, en donde los datos auxiliares se envían en un formato de mensaje de canal de servicio preexistente. 18.- El método de acuerdo con la reivindicación 17, en donde el formato de mensaje de canal preexistente transmite texto descriptivo de programa. RESUMEN Un sistema y un método (130, 135 y 140) para un usuario de un servicio de difusión de canales múltiples que escucha un canal particular proporcionan alertas sobre el contenido actualmente disponible en otros canales, los cuales son de interés para el usuario. Se pueden presentar corrientes de datos auxiliares de interés para presentarse junto con la transmisión de audio de un canal relacionado o no relacionado. El sistema y el método incluyen almacenar criterios asociados con la programación de contenido auxiliar de interés para un usuario y buscar identificadores únicos dentro de la señal de difusión significando la posibilidad de contenido que satisfaga los criterios. El contenido de interés puede ser, por ejemplo, información sobre tráfico (105, 110, 120, 111, 125), juegos deportivos disponibles en otros canales, puntajes de juegos, inventario u otros precios de instrumento de comercio encabezados de noticias o información sobre viajes. 2/25 MSG ID SECJD CARGA UTIL TIPO RSVD DOSCJD SECjNUM CARGA UTIL (3 bits) (2 bits) (3 bits) (1 bit) (7 bits) • (0 or 8 bits) (N*8 bits) Longitud Total = N+3 Bytes si SECJD = 0,1, o 2 N+2 Bytes si SECJD = 3 SGJD-"101" para indicar Mensaje descriptor de datos SECJD- ID de secuencia definido como sigue: 0 = mensaje intermedio en secuencia de mensaje 1 = primer mensaje en secuencia de mensaje 2 = ultimo mensaje en secuencia de mensaje 3= mensaje solo es mensaje en secuencia de mensaje CARGA UTIL _ TIPO- tipo de CARGA UTIL, definido como sigue: 0 = no comprimido 1 = comprimido utilizando algoritmo RHC 2-7 = reservado RSVD- reservado para uso futuro DOSCJD- tipo de datos DOSC SEC_NUM- número de secuencia que es módulo-256 (solo presente cuando SEQJD 1 = 3) CARGA UTIL- contiene N Bytes de datos en formato especificado por CARGA UTILJTIPO FIG. 2: Mensaje descriptor de datos