ES2367084T3 - Dispositivo y procedimiento para transmitir mensajes de notificación y dispositivo y procedimiento correspondiente para recibir mensajes de notificación. - Google Patents

Dispositivo y procedimiento para transmitir mensajes de notificación y dispositivo y procedimiento correspondiente para recibir mensajes de notificación. Download PDF

Info

Publication number
ES2367084T3
ES2367084T3 ES08719501T ES08719501T ES2367084T3 ES 2367084 T3 ES2367084 T3 ES 2367084T3 ES 08719501 T ES08719501 T ES 08719501T ES 08719501 T ES08719501 T ES 08719501T ES 2367084 T3 ES2367084 T3 ES 2367084T3
Authority
ES
Spain
Prior art keywords
filter
notification
notification messages
terminal
definition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES08719501T
Other languages
English (en)
Inventor
Jozef P. Van Gassel
Gilein De Nijs
Vojkan Mihajlovic
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips Electronics NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips Electronics NV filed Critical Koninklijke Philips Electronics NV
Application granted granted Critical
Publication of ES2367084T3 publication Critical patent/ES2367084T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W68/00User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/02Arrangements for increasing efficiency of notification or paging channel
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/212Monitoring or handling of messages using filtering or selective blocking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1895Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for short real-time information, e.g. alarms, notifications, alerts, updates

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Circuits Of Receivers In General (AREA)

Abstract

Transmisor (100) para transmitir mensajes (165) de notificación a un terminal (160), comprendiendo el trasmisor: una primera entrada (130) para recibir una definición (135) de filtro que define un tipo de filtro para su uso en el filtrado de los mensajes de notificación, transmitiendo por señales cómo debe interpretar el terminal los valores de los elementos de filtro en los mensajes de notificación durante el filtrado de los mensajes de notificación; una segunda entrada (140) para recibir datos (145) de entrada de notificación; y un procesador (110) configurado - para transmitir la definición de filtro al terminal; - para determinar los elementos (175) de filtro que se corresponden con los datos de entrada de notificación; - para generar los mensajes de notificación que comprenden los elementos de filtro; y - para transmitir los mensajes de notificación al terminal, mediante lo que el terminal puede filtrar los mensajes de notificación mientras que una CPU (240) principal del terminal puede permanecer apagada, para encenderse sólo cuando se recibe un mensaje de notificación de interés.

Description

CAMPO DE LA INVENCIÓN
La invención se refiere a la transmisión de mensajes de notificación a un terminal, y a la recepción de mensajes de notificación.
ANTECEDENTES DE LA INVENCIÓN
El documento US 2005101306 da a conocer cómo evitar telecomunicaciones inalámbricas no deseadas que se implementan (preferiblemente) en la red del operador de telecomunicaciones, que cumple con los requisitos de consumidor asociados con el filtrado de correo basura de telecomunicaciones inalámbricas a través de la utilización de un algoritmo de filtrado progresivo. Este algoritmo ofrece tanto al abonado como al proveedor de servicio la capacidad de bloquear y/o extraer SMS, MMS y otros mensajes de este tipo no solicitados o perjudiciales potencialmente perjudiciales o no solicitados basándose de un intervalo exhaustivo de parámetros y reglas.
La Fase 2 de DVB–CBMS es un mecanismo de notificación normalizando para entregar mensajes que contienen información relevante para el usuario o terminal que no se está transportando actualmente a través de canales convencionales. Este mecanismo de notificación puede usarse para informar al usuario o al dispositivo móvil acerca de ciertas situaciones o cambios de situación, o bien relacionadas con un servicio específico o bien de una naturaleza más general. Ejemplos de notificaciones relativas al servicio incluyen el inicio de un cierto programa de TV, el inicio de un artículo específico en una retransmisión (por ejemplo, el resumen de un partido de fútbol específico), o una notificación específica en una retransmisión en directo (por ejemplo, un momento importante en una competición deportiva: ‘los nadadores se aproximan a la línea de llegada’). Notificaciones más generales incluyen artículos de noticias o tableros de cotizaciones de la bolsa. Las notificaciones también pueden usarse para informar al propio dispositivo móvil para que realice una cierta acción. Por ejemplo, si se actualiza el manual electrónico de usuario (ESG; Electronic Service Guide), el dispositivo puede recibir un evento acerca de esto y a su vez obtener la versión actualizada.
El número de mensajes de notificación que se espera transmitir sobre retransmisión de datos basada en protocolo de Internet (IPDC; Internet Protocol Data Cast) sobre DVB–H/DVB puede llegar a ser muy alto, si bien un terminal o usuario sólo podría estar interesado en algunos de ellos. En este sentido el grupo DVB–CBMS ha definido un requisito técnico para un mecanismo para filtrar fácilmente mensajes de notificación. Sin embargo, aunque se ha observado el requisito técnico no se ha propuesto aún ninguna implementación o realización. El objetivo es crear una norma que implemente una notificación eficaz, tal como la versión 2.0 o posterior de DVB–IPDC.
Una consideración adicional es que cuando el terminal está en un modo de bajo consumo (espera), el terminal puede todavía querer recibir algunas notificaciones para alertar al usuario de eventos importantes. Por tanto, una recepción eficaz y de bajo consumo es un importante objetivo a lograr.
Una solución trivial puede ser la inserción de un valor en una ubicación predeterminada en la cabecera de cada mensaje, de manera que el hardware de nivel bajo puede filtrar en este valor. Un procedimiento de este tipo se usa para filtrar los paquetes de flujo de transporte correctos para un servicio específico en una retransmisión de DVB, conocida como filtrado de PID o selección de servicio. Sin embargo, debido a que los mensajes de notificación pueden contener muchas clases diferentes de información, el filtrado sólo será útil si un mensaje de notificación puede contener varios criterios de filtrado diferentes. Es necesario un procedimiento para aportar un enfoque flexible aunque eficaz para la transmisión de mensajes de notificación.
Los inventores que reconocen este problema concibieron la presente invención.
SUMARIO DE LA INVENCIÓN
Sería ventajoso lograr un enfoque flexible aunque eficaz para la transmisión de mensajes de notificación a un terminal. La invención se define mediante las reivindicaciones independientes. Las reivindicaciones dependientes definen realizaciones ventajosas.
La invención se basa en la comprensión de que el filtrado de mensajes de notificación basándose en varios criterios es eficaz de manera inherente a un nivel bajo. Si este filtrado puede realizarse en hardware o posiblemente en una pila de software de bajo nivel, la CPU principal del terminal puede permanecer apagada, para encenderse sólo cuando se recibe un mensaje de notificación de interés. Según la invención se proporciona una definición de filtro para distinguir diferentes tipos de filtro, en otras palabras los criterios de filtrado. La definición de filtro proporciona una manera de transmitir por señales la manera en la que un valor de filtro de notificación debe interpretarse por el terminal. El terminal puede usar la definición de filtro para interpretar los requisitos del filtro y configurar el filtro apropiadamente. En ese sentido, existe una separación de la definición de la semántica de los elementos de filtro respecto de la transmisión de los parámetros de los elementos de filtro. Esta separación permite que se realice el filtrado sin un conocimiento de nivel superior. En otras palabras, una vez que el filtro se ha configurado apropiadamente el procesador ya no necesita recibir todos los mensajes de notificación, sino sólo aquellos que querría recibir. La separación de la transmisión de la semántica del filtro y los valores de parámetro del filtro permite las posibilidades de filtrado eficaz en hardware.
imagen1
En una realización, un tipo de filtro puede definir la sintaxis y la semántica de un filtro que va a definirse y un procesador de transmisor puede transmitir la sintaxis y la semántica del filtro que va a definirse al terminal por medio de la definición de filtro. Esto es ventajoso puesto que permite que se filtren mensajes de notificación en el nivel más bajo posible en un terminal.
En una realización adicional, la definición de filtro puede comprender un identificador de tipo de filtro para identificar un tipo de filtro particular y un procesador de transmisor puede transmitir el identificador de tipo de filtro al terminal por medio de la definición de filtro. Esto es ventajoso puesto que permite la transmisión de mensajes de notificación por medio de simplemente un nombre y un par de valores. El nombre puede basarse en el identificador de tipo de filtro y el valor se basa en un parámetro asociado que va a transmitirse.
En otra realización, los elementos de filtro pueden comprender un identificador de tipo de filtro adicional que se corresponde con el identificador de tipo de filtro y un procesador de transmisor puede transmitir el identificador de tipo de filtro adicional al terminal por medio de los elementos de filtro. Esto es ventajoso puesto que el terminal puede filtrar mensajes de notificación basándose en el identificador de tipo de filtro de una manera sencilla.
En otra realización más, puede proporcionarse una tercera entrada para recibir datos de entrada de configuración y un procesador de transmisor puede transmitir los datos de entrada de configuración en combinación con la definición de filtro como datos de configuración. Esto es ventajoso puesto que los datos de configuración ya se han enviado al terminal. Por ejemplo, tales datos de configuración puede ser un manual de usuario. La infraestructura proporcionada actualmente puede reutilizarse entonces para transmitir también los mensajes de notificación.
En una realización, un procesador de transmisor puede configurarse para transmitir los mensajes de notificación usando un protocolo que se corresponde con una retransmisión de datos basada en protocolo de Internet sobre DVB–H. Este protocolo permite que se ofrezcan muchos servicios avanzados a los consumidores de una manera compatible y normalizada.
En otra realización, el módulo de comunicación comprende el filtro. Esto es una construcción de muy bajo consumo mediante la que los mensajes de notificación pueden filtrarse en el nivel más bajo posible. Por ejemplo, esto puede ser a nivel de hardware.
En otra realización, puede proporcionarse un coprocesador y el coprocesador puede comprender el filtro. Esto ofrece la posibilidad de un filtro más flexible que puede configurarse para manejar filtros de mensaje de notificación compleja.
En una realización adicional, la definición de filtro puede comprender un identificador de tipo de filtro para identificar un tipo de filtro particular y puede configurarse el procesador de terminal para configurar el filtro para filtrar los mensajes de notificación basándose en el identificador de tipo de filtro. Esto es ventajoso puesto que permite queuna comunicación de la definición de filtro continúe de una manera fácil. Éste es especialmente el caso cuando el tipo de filtro particular es un tipo de filtro convencional o un tipo de filtro conocido por un dispositivo de transmisión y el terminal.
En una realización, los elementos de filtro pueden comprender un identificador de tipo de filtro adicional que se corresponde con el identificador de tipo de filtro y el filtro puede configurarse para pasar mensajes de notificación filtrados cuando el identificador de tipo de filtro adicional se corresponde con el identificador de tipo de filtro. Esto es ventajoso puesto que permite que se filtren los mensajes de notificación en el nivel más bajo posible en un terminal.
En otra realización, los elementos de filtro pueden comprender un valor de elemento de filtro y el procesador puede configurarse para configurar el filtro para filtrar adicionalmente los mensajes de notificación basándose en el valor de elemento de filtro. Esto permite al terminal en el lado cliente filtrar basándose en estos valores de elemento de filtro. También puede usarse para evaluar expresiones que se definen, por ejemplo, por el terminal 160 o el propio usuario final.
En una realización adicional, el módulo de comunicación puede comprender además una señal de control de procesador para controlar el funcionamiento del procesador de terminal basándose en el filtrado de los mensajes de notificación en el dispositivo. Esto permite a la comunicación reducir el consumo de potencia del terminal apagando el procesador de terminal hasta que se reciban mensajes de notificación relevantes.
En otra realización, el módulo de comunicación puede configurarse para recibir los mensajes de notificación usando un protocolo que se corresponde con una retransmisión de datos basada en protocolo de Internet sobre DVB–H. Este protocolo permite que se ofrezcan muchos servicios avanzados a los consumidores de una manera compatible y normalizada.
En una realización adicional, puede realizarse un dispositivo según la invención tal como al menos uno del grupo que consiste de un dispositivo de grabación de vídeo digital, un dispositivo habilitado en red, un sistema de acceso condicional, un reproductor de audio portátil, un reproductor de vídeo portátil, un teléfono móvil, un reproductor de DVD, un reproductor de CD, un reproductor multimedia basado en disco duro, un dispositivo de radio de Internet, un ordenador, una televisión, un dispositivo de entretenimiento público y un reproductor de MP3. Sin embargo, estas aplicaciones son sólo a modo de ejemplo.
imagen2
El procesamiento de datos requerido según la invención puede realizarse mediante un programa informático, es decir por software, o usando uno o más circuitos de optimización electrónica especial, es decir en hardware, o en forma híbrida, es decir por medio de componentes de software y de componentes de hardware.
Los aspectos definidos anteriormente y aspectos adicionales de la invención son evidentes a partir de los ejemplos de la realización que va a describirse a continuación en el presente documento y se explican con referencia a estos ejemplos de la realización.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La invención se describirá en más detalle a continuación en el presente documento con referencia a ejemplos de realización pero a los que no se limita la invención.
La figura 1 ilustra una realización de un dispositivo para transmitir mensajes de notificación a un terminal.
La figura 2 ilustra una realización de un dispositivo para recibir mensajes de notificación.
La figura 3 ilustra una realización adicional de un dispositivo para recibir mensajes de notificación.
La figura 4 ilustra una realización de un dispositivo para recibir mensajes de notificación y filtrar dichos mensajes de notificación.
La figura 5 ilustra una realización de un mensaje de notificación.
La figura 6 ilustra una realización de una definición de filtro.
Las figuras 7a, 7b y 7c en combinación ilustran una realización adicional de una definición de filtro.
La figura 8 ilustra una realización adicional de una definición de filtro.
La figura 9 ilustra una realización detallada de un mensaje de notificación.
La figura 10 ilustra una realización detallada adicional de un mensaje de notificación.
La figura 11 ilustra una realización de un procedimiento para transmitir mensajes de notificación.
La figura 12 ilustra una realización de un procedimiento para recibir mensajes de notificación.
Las figuras están dibujadas esquemáticamente y no a verdadera escala, y los números de referencia idénticos en diferentes figuras se refieren a elementos que se corresponden. Será obvio para los expertos en la técnica, que son posibles realizaciones alternativas pero equivalentes de la invención sin desviarse del verdadero concepto de la invención, y que el alcance de la invención se limitará sólo por las reivindicaciones.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
La figura 1 ilustra una realización de un dispositivo para transmitir 100 mensajes 165 de notificación a un terminal 160. Un procesador 110, que puede denominarse procesador de transmisor, puede configurarse para recibir datos 125 de entrada de configuración en una entrada 120 de datos de configuración. Los datos 155 de configuración pueden estar en forma de un manual de usuario, SG, o un manual electrónico de usuario, ESG. Un manual de usuario o manual electrónico de usuario de este tipo ya se conoce dentro del contexto de la normalización de DVB–H. Por ejemplo, esto se conoce a partir de la norma de ETSI TS 102 471 “Digital Video Broadcasting (DVB); IP Datacast over DVB–H: Electronic service guide (ESG)”. El procesador 110 también puede configurarse para recibir una definición 135 de filtro en una entrada 130 de definición de filtro. La definición 135 de filtro también puede denominarse información de tipo de filtro.
La definición 135 de filtro puede comprender el tipo y significado de un valor de cada elemento 175 de filtro de notificación. Este tipo y significado pueden conocerse mediante el tipo de filtro y pueden determinarse mediante un identificador 600 de tipo de filtro o identificador de filtro. Estos pueden considerarse campos usados en el filtrado de la notificación. Este identificador puede hacer referencia a una enumeración por servicio de diferentes tipos, denominados unas descripciones de tipo de filtro o listas de filtro. Debe observarse que las notificaciones ‘agnósticas con respecto al servicio’ también pueden considerarse un servicio en sí mismo. La estructura de esta lista de tipo de filtros puede conocerse como una estructura de lista de filtros. Esta enumeración puede presentarse en el ESG, o puede recuperarse sobre HTTP. También son posibles otros mecanismos de entrega. Los identificadores de tipo de filtro pueden ser únicos dentro de un cierto ámbito. Esto es útil puesto que evita la confusión. El ámbito de los identificadores puede ser por ejemplo el de una única ESG, o el de un proveedor de ESG, o el de una plataforma de IP. También puede ser el de un servicio, un paquete de servicios, o un dominio IPDC, o un país. Alternativamente, un identificador puede ser globalmente único, o contenido dentro de una cierta estructura organizativa.
El procesador 110 puede transmitir los datos 155 de configuración, que comprenden los datos 125 de entrada de configuración y la definición 135 de filtro, al terminal 160 haciendo uso de una instalación 150 de retransmisión. La instalación 150 de retransmisión debe, evidentemente, comprender los módulos de componentes necesarios tales como un modulador, un amplificador, una antena etc.
imagen3
El procesador 110 puede comprender una entrada 140 de datos de notificación tras la que pueden recibirse los datos 145 de entrada de notificación. Los datos 145 de entrada de notificación pueden ser a continuación más de una señal de disparo, pero también pueden comprender información desde una fuente externa. Por ejemplo, pueden comprender precios actuales del mercado de valores o marcadores actuales en un evento deportivo. El procesador 110 puede recibir los datos 145 de entrada de notificación y generar mensajes 165 de notificación basándose en los datos 145 de entrada de notificación. La generación puede tener en cuenta la definición 135 de filtro. El procesador 110 puede determinar los elementos 175 de filtro de notificación en los que los elementos 175 de filtro de notificación corresponden a los parámetros obtenidos a partir de la definición 135 de filtro. El valor de los parámetros puede corresponderse con los datos 145 de entrada de notificación. Por ejemplo, los parámetros pueden ser las cotizaciones de bolsa actuales o los últimos marcadores. Los elementos 175 de filtro de notificación pueden ser entonces la información en la que se realiza la acción de filtrado real, en tanto que la definición 135 de filtro puede proporcionar sólo la sintaxis o construcción lógica del filtro 260. El mensaje 165 de notificación puede comprender una cabecera 170 de notificación que indica ampliamente el contenido del mensaje 165 de notificación. Esto puede permitir un filtrado eficaz. La cabecera 170 de notificación se muestra en más detalle en la figura 9.
El mensaje 165 de notificación también puede comprender una carga 180 útil de notificación. Debe observarse que los elementos 175 de filtro de notificación de un mensaje 165 de notificación pueden contener ya toda la información presente en el mensaje 165 de notificación. La carga 180 útil de notificación de un mensaje 165 de notificación por tanto puede estar vacía. Si consideramos los elementos 175 de filtro de notificación como parte de la carga 180 útil de notificación, la carga 180 útil de notificación puede consistir sólo en elementos 175 de filtro de notificación. El procesador 110 puede transmitir los mensajes 165 de notificación al terminal 160 haciendo uso de una instalación 150 de retransmisión.
En la figura 2 se ilustra una realización de un dispositivo para recibir mensajes 165 de notificación. Esto puede realizarse mediante el terminal 160. Una aplicación puede ejecutarse en el procesador 240 de aplicación. Esta aplicación puede recibir la definición 135 de filtro. Esto puede realizarse a través del uso de la antena 210 de terminal. La definición 135 de filtro puede denominarse información de tipo de filtro. La definición 135 de filtro puede leerse a partir de los datos 155 de configuración. Los datos 155 de configuración se reciben generalmente en forma de un manual de usuario, SG, o un manual electrónico de usuario, ESG. Los datos 155 de configuración y los mensajes 165 de notificación se envían generalmente ambos al terminal 160 de manera continua. Esto se produce normalmente de una manera multiplexada en el tiempo. Esto se denomina segmentación de tiempo y permite al terminal 160 funcionar de una manera con bajo consumo. El terminal 160 no tiene que prestar atención a los datos 155 de configuración de manera continua, incluso aunque los datos 155 de configuración se están enviando continuamente. La aplicación que se ejecuta en el procesador 240 de aplicación puede ordenar al módulo 220 de comunicación que filtre en cierto tipo de filtros y ciertos valores o intervalos de valores. Esto puede lograrse usando un bus 230 interno. El bus 230 interno puede basarse en PCI, SPI, USB o similares. Otras interconexiones propietarias pueden lograr el mismo objetivo. El módulo 220 de comunicación puede ser un módulo de DVB–H configurado para recibir datos según la norma DVB–H. Por ejemplo, esto se conoce a partir de la norma de ETSI EN 302 304 “Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB–H)”. El módulo 220 de comunicación puede comprender un filtro 260 para realizar el filtrado de los mensajes 165 de notificación.
Los mensajes 165 de notificación pueden contener un filtro de notificación, que consiste en uno o más de los elementos 175 de filtro de notificación. Cada uno de los elementos 175 de filtro de notificación puede tener un tipo de filtro específico. El tipo de filtro específico puede definir la sintaxis y la semántica del filtro. También puede identificarse por el identificador de tipo de filtro. La definición 135 de filtro, también denominada descripciones de tipo de filtro, puede transmitirse dentro de o en paralelo con el ESG. Pueden describir la sintaxis y la semántica de los tipos de filtro y de nuevo pueden identificarse por el identificador de tipo de filtro. Las descripciones de tipo de filtro también pueden denominarse listas de filtro. La estructura de la forma en que están contenidas estas descripciones, dentro del ESG o de otra manera, puede denominarse estructura de lista de filtros o estructura de descripción de tipo de filtro.
En la figura 3 se muestra una realización adicional de un dispositivo para recibir mensajes 165 de notificación. De acuerdo con la realización de la figura 2 una aplicación puede ejecutarse en el procesador 240 de aplicación y el dispositivo realizarse como el terminal 160. El terminal 160 puede comprender un coprocesador 310 para liberar al procesador 240 de aplicación de la carga de alguna de las tareas. Por ejemplo, el coprocesador puede poder decodificar audio y vídeo y comunicación con el módulo 220 de comunicación de una manera completamente independiente. Por ejemplo, el coprocesador 310 también puede ejecutar una pila de software de soporte intermedio que entiende el protocolo de DVB–H. Cualquier comunicación entre módulos dentro del terminal 160 puede lograrse usando el bus 230 interno. La aplicación puede recibir la definición 135 de filtro del coprocesador 310 o directamente del módulo 220 de comunicación, aunque el último no se muestra en la figura 3. La aplicación que se ejecuta en el procesador 240 de aplicación puede ordenar al coprocesador 310 que filtre en ciertos tipos de filtro y ciertos valores o intervalos de valores. El coprocesador 310 puede comprender el filtro 260 para realizar el filtrado de los mensajes 165 de notificación. El uso del coprocesador permite que se implemente el filtro 260 de una manera flexible tal que pueden construirse filtros tanto sencillos como complejos. También permite que se creen y se distribuyan al terminal 160 nuevos tipos de filtro convencionales sin que se requiera una revisión de hardware. El proceso real de filtrado de los mensajes 165 de notificación se produce de una manera similar a la de la realización de la figura 2.
imagen4
En la figura 4 se muestra una realización de un dispositivo para recibir mensajes 165 de notificación y filtrar los mensajes 165 de notificación. Durante el proceso de filtrado puede apagarse el procesador 240 de aplicación. Por ejemplo, esto puede lograrse proporcionando una señal 410 de control de procesador entre el módulo 220 de comunicación y el procesador 240 de aplicación. Tal control también puede implementarse haciendo uso del bus 230 interno. Si se recibe un mensaje de notificación que corresponde a los criterios mediante el módulo 220 de comunicación entonces este mensaje de notificación será un mensaje 400 de notificación filtrado. El procesador 240 de aplicación puede encenderse para procesar el mensaje 400 de notificación filtrado. Lo mismo puede aplicarse a la realización de la figura 3. En este caso el coprocesador 310 que ejecuta la pila de soporte intermedio puede activar el procesador 240 de aplicación cuando se detecta mediante el coprocesador 310 un mensaje de notificación que corresponde a los criterios. De nuevo, un mensaje de notificación de este tipo se considerará como el mensaje 400 de notificación filtrado. De nuevo, el procesador 240 de aplicación puede encenderse para procesar el mensaje 400 de notificación filtrado.
Un mensaje 165 de notificación puede ser la carga útil de un paquete que encapsula la notificación. El formato de mensaje es agnóstico con respecto al protocolo subyacente. Ejemplos de protocolos adecuados son FLUTE, ALC o RTP, pero incluso UDP (con ampliaciones propietarias) podría ser suficiente. Las ampliaciones al protocolo de transporte subyacente no siempre son necesarias pero podrían ser beneficiosas en algunos casos. En el caso de que se use RTP como protocolo de encapsulamiento, puede realizarse un paquete RTP tal como se muestra en la figura 5.
En la figura 5 se muestra una posible realización de un mensaje 165 de notificación que usa RTP como un protocolo de transporte subyacente. En este caso se usa un formato de carga útil de RTP especial para notificación que consiste en una cabecera 170 de notificación, unos elementos 175 de filtro de notificación y una carga 180 útil de notificación. Obsérvese que todos los tres pueden contenerse en la carga útil del protocolo subyacente. En el ejemplo de RTP también puede usarse la ampliación de cabecera del propio RTP. En algún caso esto se recomienda sólo con fines experimentales. Debe observarse que también pueden usarse otros protocolos, como por ejemplo FLUTE, ALC o ampliaciones propietarias por encima de UDP.
La carga 180 útil de notificación (u objeto de notificación) puede consistir en o bien una referencia a un objeto (externo) o bien el propio objeto. En otras palabras, los objetos de notificación reales pueden transportarse fuera de banda. En tales casos el objeto de notificación transportado fuera de banda puede acompañarse por un descriptor de objeto. Este descriptor de objeto puede separarse de la cabecera 170 de notificación, e incluso posiblemente separarse de la carga 180 útil de notificación. Ejemplos de tales cargas 180 útiles de notificación son: texto, HTML, datos RSS, SVG, audio, vídeo e imágenes. Para referencias a los objetos de notificación puede usarse un identificador universal de recursos (URI; Universal Resource Identifier). En el caso en el que el mensaje 165 de notificación se refiere a un objeto de notificación externo, algunos elementos de la cabecera 170 de notificación pueden estar disponibles tanto en el paquete que lleva la propia referencia (por ejemplo el paquete RTP en el ejemplo anterior), como encapsulados con el carga 180 útil/objeto de notificación real posiblemente en un protocolo de transporte diferente. Una tercera opción es que el descriptor de objeto de notificación se lleve separado de la referencia y de la carga útil de notificación real.
El mensaje 165 de notificación puede consistir en una cabecera 170 de notificación (o descriptor de notificación) y una carga 180 útil de notificación. El mensaje 165 de notificación puede incluir instrumentos para un mecanismo de filtrado eficaz que puede considerarse parte de la cabecera 170 de notificación o parte de la carga 180 útil de notificación. En el último caso, la cabecera 170 de notificación puede incluir un indicador u otros medios de señalización para indicar que se presenta información de filtrado. Tal como se mencionó, los instrumentos para el filtrado también puede ser una ampliación (de cabecera) al protocolo de transporte subyacente (por ejemplo FLUTE
o RTP). El propio mecanismo de filtro consiste en añadir uno o más elementos 175 de filtro al mensaje 165 de notificación, que contienen información que el cliente o terminal 160 que la recibe puede usar para decidir si el mensaje es de interés.
Los elementos 175 de filtro pueden llevar variables de filtro que pueden ser escalares sencillos o tipos de variable de filtro más complejas. En el lado cliente estos valores de filtro (o campos de clave) pueden usarse para evaluar expresiones que se definen, por ejemplo, por el terminal 160 o el usuario final. Estas expresiones de filtro o reglas de filtro pueden consistir simplemente en comparar variables con valores predefinidos pero también son posibles expresiones más avanzadas que usan operadores (lógicos) más complejos. Los elementos 175 de filtro pueden contener un identificador de filtro, es decir un ID, que se corresponde con un elemento en una enumeración. Por ejemplo, una enumeración con equipos deportivos, coordenadas de GPS, horarios de apertura de un sitio de interés, símbolo de un valor, o precio de valores. La solución propuesta separa la definición de la semántica de los elementos de filtro respecto de la transmisión, así el filtrado puede realizarse sin conocimiento de nivel superior. Esto habilita las posibilidades de un filtrado eficaz en hardware.
En el caso en el que el mensaje 165 de notificación y posiblemente sus elementos 175 de filtro, son más grandes que la unidad de transmisión máxima, MTU (Maximum Transmission Unit), del protocolo de transporte subyacente, puede usarse alguna forma de fragmentación de la carga útil para distribuir la carga útil sobre múltiples paquetes del protocolo subyacente. Por otro lado, también puede ser posible que puedan agregarse varios mensajes pequeños que incluyen elementos de filtro a una única carga útil. Esto se mantiene sin pérdida de generalidad del concepto descrito.
imagen5
Es posible que se cifren o expongan los elementos 175 de filtro en esquemas complejos de corrección de error por consideraciones de privacidad, protección de contenido y fiabilidad de datos. Sin embargo, si esto se hiciera debe tenerse cuidado para garantizar que el filtrado de bajo nivel de los mensajes basados en los criterios siga siendo eficaz.
La figura 6 ilustra en detalle una realización de la definición 135 de filtro. La definición 135 de filtro, o descripción de tipo de filtro, puede contener al menos el identificador 600 de tipo de filtro del tipo de filtro, la longitud 610 del valor de elemento de filtro, la interpretación por máquina y el significado semántico. A modo de ejemplos, la interpretación por máquina puede ser de tipo int, float, enum, etc. Adicionalmente, la descripción también puede contener la unidad del valor (por ejemplo, dólares americanos, kilómetros), un intervalo de valores (por ejemplo con valores máximos y mínimos), un tamaño de paso del valor, un nombre y una descripción legible por una persona, y otra información. También son posibles tipos de filtro compuesto, caso en el que de la definición 135 de filtro puede comprender una secuencia de entradas que contienen la longitud, la interpretación por máquina, y el significado semántico. La definición 135 de filtro puede representarse en un fragmento de XML. Un ejemplo de un fragmento de XML que contiene una descripción de tipo básico y una descripción de tipo compuesto se muestra en la figura 6. El fragmento de XML de la figura 6 puede incluirse en el ESG o en otra parte, caso en el que puede necesitarse que se amplíe el esquema de XML del ESG u de otro posible documento padre.
Las figuras 7a, 7b y 7c en combinación ilustran una realización adicional de una definición de filtro que ilustra un posible esquema de XML. Debe observarse que esta no es una definición completa y se proporciona sólo para su ilustración. El esquema permite que se definan tanto un tipo 710 de filtro complejo como un tipo 710 de filtro sencillo en la definición 135 de filtro.
La figura 8 ilustra una realización adicional de una definición de filtro en un nivel más generalizado. La descripción de los tipos de filtro puede expresarse en la estructura de árbol mostrada en la figura 8. Tanto la definición 135 de filtro como los correspondientes mensajes 165 de notificación pueden referirse a un objeto 800 de filtro de notificación. El objeto 800 de filtro de notificación puede ejemplificarse como un objeto 810 de filtro de notificación simple que se corresponde con un tipo 710 de filtro simple o puede ejemplificarse como un objeto 820 de filtro de notificación complejo que se corresponde con un tipo 700 de filtro complejo.
Dentro de la jerarquía del objeto 810 de filtro de notificación simple puede crearse una clasificación adicional de elementos 830 de filtro de notificación primitivo y elementos 840 de filtro de notificación compuesto. Los elementos 830 de filtro de notificación primitivo pueden ser una elección 850 de una pluralidad de tipos conocidos o convencionales. Por ejemplo, los elementos 830 de filtro de notificación primitivo pueden seleccionarse a partir de integers, doubles, strings, etc. Los elementos 840 de filtro de notificación compuesto pueden comprender una secuencia 860 de tipos conocidos o convencionales de elementos 830 de filtro de notificación primitivo. Dentro de la jerarquía del objeto 820 de filtro de notificación complejo puede comprenderse una secuencia 860 de una pluralidad de los objetos 810 de filtro de notificación simple.
Para tipos de filtro básicos, la longitud 910 del tipo de filtro básico puede estar en el elemento 175 de filtro de notificación. La definición 135 de filtro, o las descripciones de tipo de filtro, o las estructuras de filtro o estructuras de tipo de filtro, pueden describir la siguiente lista no exhaustiva de interpretaciones por máquina (o “tipos de datos”
o “tipos de variables” o “tipo”):
duration, dateTime, time, date, boolean, base64Binary, hexBinary, float, double, anyURI, string, normalizedString, token, language, Name, ID, IDREF, ENTITY, decimal, integer, nonPositiveInteger, negativeInteger, long, int, short, byte, nonNegativeInteger, unsignedLong, unsignedInt, unsignedShort, unsignedByte, positiveInteger, fixedPoint, array.
Además, esta lista puede ampliarse con tipos de datos de TV–Anytime y tipos de datos de MPEG–7.
También, puede definirse un tipo de dato de longitud cero o un tipo de longitud cero o tipo de valor cero o un indicador o tipo sin valor. Tal tipo especial puede no tener un valor, así que la longitud del valor del elemento 175 de filtro de notificación que contiene este tipo puede ser cero. La presencia de este tipo en el elemento 175 de filtro de notificación de un mensaje 165 de notificación puede ser significativa. En otras palabras, el terminal 160 puede estar interesado simplemente en mensajes que llevan un elemento 175 de filtro de notificación de este tipo. Alternativamente, pueden predefinirse varios tipos, como un entero de 32 bits. Esto es útil si la semántica del valor está determinada de manera implícita por el servicio y/o por la aplicación que está ejecutándose en el terminal 160. De este modo, la definición de tipo de filtro puede comunicarse de manera implícita al terminal 160 y no se necesita que esté presente el campo de longitud en el elemento 175 de filtro de notificación. Pueden reservarse varios ID para este uso. Por ejemplo, pueden reservarse los primeros 15 números de ID para este fin.
Es funcionalmente equivalente usar un elemento 175 de filtro de notificación por mensaje 165 de notificación que comprende un tipo compuesto (que consiste en otros subelementos de filtro), o usar múltiples elementos de filtro por mensaje 165 de notificación que consisten en tipos básicos. Ambos enfoques tienen sus ventajas y desventajas. La ventaja principal del uso de un elemento por mensaje de notificación, en el que el elemento puede ser o bien compuesto o bien básico, es que la capa de aplicación conoce exactamente el diseño de la parte de filtro del mensaje 165 de notificación y por tanto puede ordenar al filtro 260 qué filtrar de manera muy precisa. Por ejemplo, puede ordenar al filtro 260 que filtre “el valor en los bits del 16 al 31 debe ser mayor que 231”. El filtrado puede entonces ser muy eficaz, especialmente cuando se realiza en hardware. El uso de múltiples elementos de filtro por mensaje 165 de notificación da como resultado instrucciones menos concisas. Por ejemplo, puede ordenarse al filtro 260 que filtre “el elemento de filtro con el identificador 5 de tipo de filtro debe ser mayor que 231”. Caso en el que el filtro 260 tiene que revisar en todos los elementos 175 de filtro de notificación para ver si coinciden con los criterios. Para ello, el filtro 260, o el hardware, necesita conocer la longitud de cada elemento. En este caso es beneficioso que los elementos 175 de filtro de notificación o bien sean de una longitud fija o bien contengan su propia longitud o bien tengan un separador conocido entre los elementos.
imagen6
La implementación preferida puede permitir múltiples elementos 175 de filtro de notificación por mensaje 165 de notificación. Los elementos 175 de filtro de notificación pueden consistir en este caso del identificador 600 de tipo de filtro, la longitud 610 del valor del elemento de filtro y el valor 920 real. El filtrado tendrá lugar en las combinaciones de valor de ID (algunas veces denominado valor de nombre o pares de valores de clave), en el que las comparaciones tanto del ID como del valor pueden implementarse usando máscaras de bits.
La figura 9 ilustra una realización detallada de un mensaje de notificación. Se muestran el ID y pares de valores en los que puede basarse el filtrado. Los elementos 175 de filtro de notificación pueden contener una indicación de la longitud 610 del valor de elemento de filtro. Esto puede estar en bits o bytes. Esto da protección contra elementos de filtro desconocidos. La implementación de filtro puede entonces omitir o saltarse los elementos desconocidos, ya que siempre se conocerá la longitud del elemento. Esto permite que procedimiento se amplíe de una manera compatible con versiones anteriores. Además dentro de un servicio el conjunto de elementos de filtro de notificación de un servicio de notificación específica pueden cambiar de manera dinámica con el tiempo.
Existen muchas realizaciones posibles de la cabecera 170 de notificación. Algunos de los elementos son opcionales y las asignaciones de bits mostradas en la figura 9 son simples ejemplos. Algunos de los elementos de campo de cabecera pueden codificarse con codificación de longitud variable. La cabecera 170 de notificación puede contener:
Indicador 900 de filtro presente (F): 1 bit
Este campo puede indicar si el mensaje 165 de notificación contiene elementos 175 de filtro de notificación. Este indicador puede ser conveniente si hay un bit sobrante disponible en la cabecera 170 de notificación.
Longitud 910 de filtro (FIL_LEN): 6–8 bits
Longitud total de la parte de filtro del mensaje 165 de notificación. La longitud de este campo puede depender de cuantos bits se dejan convenientemente en la cabecera 170 de notificación. Si hay un indicador de filtro presente definido, no es necesario que este campo esté presente si F = 0. Si se define un indicador de filtro presente, FIL_LEN es la longitud total de la parte de filtro del mensaje menos uno. Como una alternativa al uso de F, FIL_LEN puede estar siempre presente con un valor de cero lo que indica que no hay elementos de filtro.
Los elementos 175 de filtro de notificación pueden ser una repetición de lo siguiente, o bien en la cabecera 170 de notificación o bien en la carga 180 útil de notificación:
Identificador 600 de tipo de filtro (FE_ID): 6 bits
Una referencia a la descripción exacta con respecto a la sintaxis y la semántica del tipo del valor contenido en el elemento de filtro. Esta descripción puede estar en un fragmento de XML (es decir fuera de banda), o bien contenida en el ESG (autocarga) o bien puede obtenerse en otra parte.
Longitud 610 de valor de elemento de filtro (L): 2 bits
Indicación del número de bits en FE_VAL. La longitud de FE_VAL puede determinarse por (2^L) * 8 bits. Alternativamente, la longitud del valor de elemento de filtro de notificación puede codificarse mediante la codificación de bit más significativo en primer lugar de entero sin signo de longitud variable. El bit de signo puede indicar si el siguiente byte también contribuye a la longitud. Esto se usa comúnmente en numerosas especificaciones de DVB. Esto es necesario en caso de elementos de filtro de longitud variable tales como strings. Obsérvese que este valor también puede suprimirse de la cabecera 170 de notificación puesto que también se indica en la descripción exacta. Sin embargo para simplificar el análisis sintáctico puede llevarse de manera explícita.
Valor 920 de elemento de filtro (FE_VAL): 8, 16, 32 ó 64 bits
El valor real del elemento 175 de filtro de notificación. El tipo y significado pueden encontrarse en el descriptor de tipo de filtro o en la definición 135 de filtro y tiene como referencia a FE_ID. La longitud del campo FE_VAL es de (2^L) bytes si está presente, de otra manera la longitud se obtiene de la descripción exacta del elemento de filtro.
La figura 10 ilustra una realización detallada adicional de un mensaje de notificación. En el ejemplo mostrado en la figura 10, se muestra un mensaje 175 de notificación que contiene una actualización del marcador de un partido de fútbol entre Alemania y Francia. El mensaje 175 de notificación puede incluir (al menos) los siguientes dos elementos de filtro, basándose en el fragmento de ESG de ejemplo de las figuras 7a, 7b y 7c. El identificador 600 de tipo de filtro tiene un valor de 2, en este ejemplo. La longitud 610 de valor de elemento de filtro, L, tiene un valor de cero puesto que un filtro con el identificador 600 de tipo de filtro que tiene un valor de 2 es un filtro convencional. El valor 920 de elemento de filtro, FE_VAL, tiene un valor de 1. Por tanto, Alemania ha marcado 1 gol. Un valor de elemento de filtro posterior, FE_VAL, de 2 indica que Francia ha marcado 2 goles. La figura 10 también ilustra una representación 1000 binaria del ejemplo recién descrito.
imagen7
Si se usa FLUTE como protocolo de transporte subyacente, la solución propuesta puede usarse de igual modo. Los mensajes 165 de notificación pueden ser independientes de la capa de transporte. En el caso de FLUTE, sin embargo, los elementos 175 de filtro de notificación también pueden incluirse en la tabla de descriptor de archivo (FDT; File Descriptor Table) del protocolo de FLUTE. Puesto que esta tabla siempre necesita recuperarse antes de recuperar otros objetos de FLUTE, tal como los mensajes 165 de notificación, entonces los elementos 175 de filtro de notificación ya pueden dotar al terminal 160 de información acerca de qué mensajes 165 de notificación necesitan recuperarse a partir de la sesión de FLUTE. Para implementar esto, puede necesitarse definir etiquetas y/o atributos adecuados en el esquema de XML para un ejemplo de FDT. En este caso se hace referencia a la sección 3.4.2 de la norma de RFC 3926. Estas etiquetas y/o atributos pueden tener la etiqueta FDT-Instance como padre, o la etiqueta File como padre, o cualquier otra etiqueta adecuada. En otras palabras los elementos 175 de filtro de notificación pueden definirse a nivel de FDT o a nivel de file. Alternativamente, pueden incluirse los elementos 175 de filtro de notificación en el transporte de codificación por capas (Layered Coding Transport), LCT, las ampliaciones de cabeceras en las cabeceras de paquetes de LCT específicos que contienen los mensajes 165 de notificación o partes del mismo. Se hace referencia al documento de Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., y
J. Crowcroft, “Layered Coding Transport (LCT) Building Block”, norma de RFC 3451, diciembre de 2002. Esto es cierto de manera similar para la codificación asíncrona por capas (Asynchronous Layered Coding), ALC. Se hace referencia al documento de Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., y J. Crowcroft, “Asynchronous Layered Coding (ALC) Protocol Instantiation”, norma de RFC 3450, diciembre de 2002. Por ejemplo puede usarse una ampliación de cabecera de ALC/LCT (HET) de un tipo recién definido EXT_FLT para llevar los elementos de filtrado de una manera transparente.
En resumen, la invención da a conocer procedimientos y dispositivos para transmitir mensajes de notificación y procedimientos y dispositivos correspondientes para recibir tales mensajes de notificación. Un dispositivo de transmisión puede recibir una definición de filtro que define un tipo de filtro para su uso en el filtrado de los mensajes de notificación. La definición de filtro puede transmitirse a un terminal a través de una instalación de retransmisión. El terminal puede configurar un filtro basándose en la definición de filtro. Cuando va a enviarse una notificación pueden recibirse datos de entrada de notificación y pueden determinarse elementos de filtro. Los elementos de filtro pueden corresponderse con parámetros obtenidos a partir de la definición de filtro. El valor de los parámetros puede corresponderse con los datos de entrada de notificación. Los mensajes de notificación pueden comprender los elementos de filtro y pueden generarse y enviarse al terminal. El terminal puede filtrar los mensajes de notificación usando el filtro, en el que el filtrado puede basarse en los elementos de filtro.
A modo de ejemplo, la figura 11 ilustra una realización de un procedimiento para transmitir mensajes de notificación. En la etapa 1100 puede recibirse la definición 135 de filtro que define un tipo de filtro para su uso en el filtrado de los mensajes 165 de notificación. Posteriormente, la definición 135 de filtro puede transmitirse en la etapa 1110 al terminal 160 a través de una instalación 150 de retransmisión. Cuando va a enviarse una notificación pueden recibirse los datos 145 de entrada de notificación y pueden determinarse los elementos 175 de filtro de notificación en la etapa 1120. Los elementos 175 de filtro de notificación pueden corresponderse con parámetros obtenidos a partir de la definición 135 de filtro. El valor de los parámetros puede corresponderse con los datos 145 de entrada de notificación. Los mensajes 165 de notificación pueden comprender los elementos 175 de filtro de notificación y pueden generarse en la etapa 1130 y enviarse al terminal 160 en la etapa 1140 transmitiéndolos usando la instalación 150 de retransmisión una vez más. Debe observarse que en una implementación práctica tanto la definición 135 de filtro como los mensajes 165 de notificación pueden transmitirse de una manera multiplexada en el tiempo. Por tanto, sustancialmente pueden transmitirse nuevas definiciones de filtro de manera simultánea con los mensajes 165 de notificación según una definición de filtro transmitida previamente. Debe tenerse la precaución, evidentemente, de asegurar que la experiencia del usuario permanece entendible.
A modo de ejemplo adicional, la figura 12 ilustra una realización de un procedimiento para recibir mensajes de notificación. El terminal 160 puede recibir la definición 135 de filtro en la etapa 1200 y configurar el filtro 260 basándose en la definición 135 de filtro. El terminal 160 puede, en algún momento posterior, recibir mensajes 165 de notificación en la etapa 1220. Los mensajes 165 de notificación pueden comprender los elementos 175 de filtro de notificación que permiten al terminal 160 filtrar los mensajes 165 de notificación de una manera eficaz usando el filtro 260 que se ha configurado apropiadamente. Esto se produce en la etapa 1230. De manera opcional, el terminal 160 puede, tras filtrar los mensajes 165 de notificación usando el filtro 260, controlar también el funcionamiento del procesador 240 de aplicación. Tal control puede implementarse de manera que el procesador 240 de aplicación se apaga y funciona a una velocidad reducida para ahorrar energía hasta el momento hasta que el mensaje 165 de notificación va a procesarse. El funcionamiento del procesador 240 de aplicación puede dispararse entonces para procesar el mensaje 410 de notificación filtrado.
Debe observarse que las realizaciones mencionadas anteriormente ilustran más que limitan la invención, y que los expertos en la técnica serán capaces de diseñar muchas realizaciones alternativas sin apartarse del alcance de la invención tal como se definió mediante las reivindicaciones adjuntas. Además, cualquiera de las realizaciones descritas comprende características implícitas, tales como un suministro de corriente interno, por ejemplo, una batería o un acumulador. En las reivindicaciones, ningún número de referencia situado entre paréntesis debe interpretarse como limitativo de las reivindicaciones. Las palabras “que comprende/comprendiendo” y “comprende”, y similares, no excluyen la presencia de elementos o etapas distintos a los enumerados en cualquier reivindicación o en la memoria descriptiva en su conjunto. La referencia en singular de un elemento no excluye la referencia en plural de tales elementos y viceversa. En una reivindicación de dispositivo que enumera varios medios, varios de estos medios pueden realizarse por uno y el mismo elemento de hardware. El simple hecho que ciertas medidas se mencionen en reivindicaciones dependientes diferentes entre sí no indica que una combinación de estas medidas no pueda usarse de manera ventajosa.
imagen8
imagen9

Claims (14)

  1. REIVINDICACIONES
    1. Transmisor (100) para transmitir mensajes (165) de notificación a un terminal (160), comprendiendo el trasmisor:
    una primera entrada (130) para recibir una definición (135) de filtro que define un tipo de filtro para su uso en el filtrado de los mensajes de notificación, transmitiendo por señales cómo debe interpretar el terminal los valores de los elementos de filtro en los mensajes de notificación durante el filtrado de los mensajes de notificación;
    una segunda entrada (140) para recibir datos (145) de entrada de notificación; y
    un procesador (110) configurado
    para transmitir la definición de filtro al terminal;
    para determinar los elementos (175) de filtro que se corresponden con los datos de entrada de notificación;
    para generar los mensajes de notificación que comprenden los elementos de filtro; y
    para transmitir los mensajes de notificación al terminal,
    mediante lo que el terminal puede filtrar los mensajes de notificación mientras que una CPU (240) principal
    del terminal puede permanecer apagada, para encenderse sólo cuando se recibe un mensaje de
    notificación de interés.
  2. 2.
    Transmisor según la reivindicación 1, en el que el tipo de filtro define la sintaxis y la semántica de un filtro que va a definirse, y el procesador transmite la sintaxis y la semántica del filtro que va a definirse al terminal por medio de la definición de filtro.
  3. 3.
    Transmisor según la reivindicación 1, en el que la definición de filtro comprende un identificador (600) de tipo de filtro para identificar un tipo de filtro particular y el procesador transmite el identificador de tipo de filtro al terminal por medio de la definición de filtro.
  4. 4.
    Transmisor según la reivindicación 3, en el que los elementos de filtro comprende un identificador de tipo de filtro adicional que se corresponde con el identificador de tipo de filtro y el procesador transmite el identificador de tipo de filtro adicional al terminal por medio de los elementos de filtro.
  5. 5.
    Transmisor según la reivindicación 1, que comprende además una tercera entrada (120) para recibir datos
    (125) de entrada de configuración y en el que el procesador transmite los datos de entrada de configuración en combinación con la definición de filtro como datos (155) de configuración.
  6. 6.
    Transmisor según la reivindicación 1, en el que el procesador está configurado para transmitir los mensajes de notificación usando un protocolo que se corresponde con una retransmisión de datos basada en protocolo de Internet sobre DVB–H.
  7. 7.
    Terminal (160) para filtrar mensajes (165) de notificación, comprendiendo el terminal:
    un módulo (220) de comunicación que tiene una entrada (210) para recibir desde un transmisor los mensajes de notificación y una definición (135) de filtro, definiendo la definición de filtro un tipo de filtro para su uso en el filtrado de los mensajes de notificación, transmitiendo por señales cómo debe interpretar el terminal los valores de los elementos de filtro en los mensajes de notificación durante el filtrado de los mensajes de notificación;
    un procesador (240) acoplado en comunicación con el módulo de comunicación para configurar un filtro (260) en el terminal basándose en la definición de filtro;
    en el que el filtro (260) está configurado para
    recibir los mensajes de notificación, que comprenden los elementos (175) de filtro que van a usarse durante el filtrado de los mensajes de notificación por el filtro; y
    filtrar los mensajes de notificación basándose en los elementos de filtro,
    mediante lo que los mensajes de notificación se filtran por el filtro (260) mientras que una CPU (240) principal del terminal puede permanecer apagada, para encenderse sólo cuando se recibe un mensaje de notificación de interés.
  8. 8.
    Terminal según la reivindicación 7, en el que la definición de filtro comprende un identificador (600) de tipo de filtro para identificar un tipo de filtro particular, y el procesador está configurado para configurar el filtro para filtrar los mensajes de notificación basándose en el identificador de tipo de filtro.
  9. 9.
    Terminal según la reivindicación 8, en el que los elementos de filtro comprenden un identificador de tipo de filtro adicional que se corresponde con el identificador de tipo de filtro y el filtro está configurado para pasar mensajes (400) de notificación filtrados cuando el identificador de tipo de filtro adicional se corresponde con el identificador de tipo de filtro.
  10. 10.
    Terminal según la reivindicación 8, en el que los elementos de filtro comprenden un valor (920) de elemento de filtro, y el procesador está configurado para configurar el filtro para filtrar adicionalmente los mensajes de notificación basándose en el valor de elemento de filtro.
  11. 11.
    Terminal según la reivindicación 7, en el que el módulo de comunicación comprende además una señal
    (410) de control de procesador para controlar el funcionamiento del procesador basándose en el filtrado de los mensajes de notificación en el dispositivo.
  12. 12.
    Terminal según la reivindicación 7, en el que el módulo de comunicación está configurado para recibir los mensajes de notificación usando un protocolo que se corresponde con una retransmisión de datos basada en protocolo de Internet sobre DVB–H.
  13. 13.
    Procedimiento realizado por un transmisor para transmitir mensajes (165) de notificación a un terminal (160), comprendiendo el procedimiento:
    imagen1
    recibir (1100) una definición (135) de filtro que define un tipo de filtro para su uso en el filtrado de los mensajes de notificación, transmitiendo por señales cómo debe interpretar el terminal los valores de los elementos de filtro en los mensajes de notificación durante el filtrado de los mensajes de notificación;
    transmitir (1110) la definición de filtro al terminal;
    recibir los datos (145) de entrada de notificación;
    determinar (1120) los elementos (175) de filtro que se corresponden con los datos de entrada de notificación;
    generar (1130) los mensajes de notificación, que comprenden los elementos de filtro; y
    transmitir (1140) los mensajes de notificación al terminal,
    mediante lo que el terminal puede filtrar los mensajes de notificación mientras que una CPU (240) principal del terminal puede permanecer apagada, para encenderse sólo cuando se recibe un mensaje de notificación de interés.
  14. 14. Método para filtrar mensajes (165) de notificación en un terminal (160), comprendiendo el método:
    recibir (1200) desde un transmisor una definición (135) de filtro que define un tipo de filtro para su uso en el filtrado de los mensajes de notificación, transmitiendo por señales cómo debe interpretar el terminal los valores de los elementos de filtro en los mensajes de notificación durante el filtrado de los mensajes de notificación;
    configurar (1210) un filtro (260) en el terminal basándose en la definición de filtro;
    recibir (1220) desde el transmisor los mensajes de notificación que comprenden los elementos
    (175) de filtro; y
    filtrar (1230) los mensajes de notificación usando el filtro (260) y basándose en los elementos de filtro,
    mediante lo que los mensajes de notificación se filtran por el filtro (260) mientras que una CPU (240) principal del terminal puede permanecer apagada, para encenderse sólo cuando se recibe un mensaje de notificación de interés.
ES08719501T 2007-03-08 2008-02-28 Dispositivo y procedimiento para transmitir mensajes de notificación y dispositivo y procedimiento correspondiente para recibir mensajes de notificación. Active ES2367084T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP07103786 2007-03-08
EP07103786 2007-03-08

Publications (1)

Publication Number Publication Date
ES2367084T3 true ES2367084T3 (es) 2011-10-28

Family

ID=39591980

Family Applications (1)

Application Number Title Priority Date Filing Date
ES08719501T Active ES2367084T3 (es) 2007-03-08 2008-02-28 Dispositivo y procedimiento para transmitir mensajes de notificación y dispositivo y procedimiento correspondiente para recibir mensajes de notificación.

Country Status (12)

Country Link
US (1) US8438236B2 (es)
EP (1) EP2122949B1 (es)
JP (1) JP5200267B2 (es)
KR (1) KR20090127157A (es)
CN (1) CN101627590A (es)
AT (1) ATE511279T1 (es)
BR (1) BRPI0808505A2 (es)
ES (1) ES2367084T3 (es)
MX (1) MX2009009420A (es)
RU (1) RU2464737C2 (es)
TW (1) TW200845740A (es)
WO (1) WO2008107824A1 (es)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101981928B (zh) * 2008-02-19 2013-04-03 诺基亚公司 多层消息过滤
WO2015161284A1 (en) 2014-04-18 2015-10-22 Personally, Inc. Dynamic directory and content communication
US9622176B2 (en) * 2014-06-23 2017-04-11 Qualcomm Incorporated Packet filtering for saving power at a user equipment
JP6429542B2 (ja) * 2014-09-09 2018-11-28 みこらった株式会社 スポーツ競技ライブ観戦システム、スポーツ競技ライブ観戦システムの映像収集配信設備装置及び観戦者端末
US20180152744A1 (en) * 2015-05-26 2018-05-31 Sharp Kabushiki Kaisha Message Protocol Sequence for Primary Device and Companion Device Communication
CN105956038A (zh) * 2016-04-26 2016-09-21 宇龙计算机通信科技(深圳)有限公司 通知消息的管理方法、管理装置和终端
US12238109B2 (en) * 2022-04-27 2025-02-25 Capital One Services, Llc Cloud service-based secured data workflow integration and methods thereof

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5566357A (en) 1994-10-06 1996-10-15 Qualcomm Incorporated Power reduction in a cellular radiotelephone
SE518376C2 (sv) 1997-10-20 2002-10-01 Ericsson Telefon Ab L M Förfarande och anordning i ett radiokommunikationsnätverk
EP0917356A1 (en) * 1997-11-17 1999-05-19 CANAL+ Société Anonyme Packet filtering
WO1999035778A2 (en) * 1998-01-07 1999-07-15 Microsoft Corporation Low level content filtering
CN1272272A (zh) * 1998-05-13 2000-11-01 索尼株式会社 内容提供系统
US7073129B1 (en) 1998-12-18 2006-07-04 Tangis Corporation Automated selection of appropriate information based on a computer user's context
US20010012286A1 (en) 1999-01-29 2001-08-09 Emmanuel L. Huna Method and apparatus for computer alert of device independent messages
DE10228103A1 (de) 2002-06-24 2004-01-15 Bayer Cropscience Ag Fungizide Wirkstoffkombinationen
WO2004095273A2 (en) * 2003-04-24 2004-11-04 Koninklijke Philips Electronics N.V. Alert filtering
US7721104B2 (en) * 2003-10-20 2010-05-18 Nokia Corporation System, method and computer program product for downloading pushed content
US7409203B2 (en) 2003-11-12 2008-08-05 Redknee Inc. Method and system for the prevention of unwanted wireless telecommunications
US20060128331A1 (en) * 2004-12-13 2006-06-15 Rooyen Pieter V Method and system for mobile architecture supporting cellular or wireless networks and broadcast utilizing a single chip cellular and single chip broadcast silicon solution
RU54446U1 (ru) * 2006-02-14 2006-06-27 Игорь Талгатович Фаррахов Система маркировки и передачи электронных сообщений
US20090094333A1 (en) * 2007-10-03 2009-04-09 Nikos Kyprianou Collaborative Electronic Mail Filtering

Also Published As

Publication number Publication date
EP2122949A1 (en) 2009-11-25
US20100106796A1 (en) 2010-04-29
WO2008107824A1 (en) 2008-09-12
RU2464737C2 (ru) 2012-10-20
TW200845740A (en) 2008-11-16
ATE511279T1 (de) 2011-06-15
BRPI0808505A2 (pt) 2014-08-19
EP2122949B1 (en) 2011-05-25
JP2010522910A (ja) 2010-07-08
RU2009137139A (ru) 2011-04-20
MX2009009420A (es) 2009-09-14
CN101627590A (zh) 2010-01-13
KR20090127157A (ko) 2009-12-09
JP5200267B2 (ja) 2013-06-05
US8438236B2 (en) 2013-05-07

Similar Documents

Publication Publication Date Title
ES2367084T3 (es) Dispositivo y procedimiento para transmitir mensajes de notificación y dispositivo y procedimiento correspondiente para recibir mensajes de notificación.
ES2435648T3 (es) Provisión de mensajes de notificación generales y específicos en un sistema de difusión basado en IP.
KR102114625B1 (ko) 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
US9525637B1 (en) System and method for location based interaction with a device
US10028034B2 (en) Apparatus for providing urgent alarm service through broadcast system and method therefor
US9609375B2 (en) Method for mapping between signaling information and announcement information and broadcast receiver
US20190174204A1 (en) Systems and methods for signaling of emergency alert messages
CN109661821B (zh) 用于用信号发送紧急警报消息的系统和方法
WO2008155712A2 (en) System and method for the signaling of session characteristics in a communication session
US20190289370A1 (en) Systems and methods for signaling of emergency alert messages
KR20120058465A (ko) 서비스 가이드의 프레젠테이션을 구성하는 방법, 장치 및 컴퓨터 판독 가능 저장 매체
CN101282504B (zh) 一种通过cmmb紧急广播表传输紧急广播消息的方法
Niebla et al. Design aspects in multi-channel public warning systems
ES2430331T3 (es) Método y dispositivo para proporcionar información de activación a diversos clientes usando una guía electrónica
EP2280523B1 (en) Method for transmitting and receiving notification message and apparatus thereof
RU2378795C2 (ru) Способ и устройство для предоставления сообщения оповещения в системе широковещательной передачи
CN101145928B (zh) 用于获取默认通知消息的实现方法、服务器和用户终端
KR101165636B1 (ko) 개인별 아이피 서비스 제공 방법 및 이를 위한 시스템 및이를 위한 방송용 단말기
CN109923869A (zh) 动态事件信令
CN101438588A (zh) 在数据分发业务中利用更改对象来传输静态对象的更改的方法、以及发送器和接收器
Standard A/153 Part 10, Mobile Emergency Alert System (A/153 Part 10: 2013)