ES2651328T3 - Un dispositivo operado con baterías, aplicación en la nube y métodos relacionados para transmitir/recibir mensajes de datos por una red de bajo rendimiento - Google Patents

Abstract

Un dispositivo operado con baterías (1) para transmitir mensajes de datos (100), dicho dispositivo (1) comprende: - una interfaz de red de bajo rendimiento (10), adaptada para enviar dichos mensajes de datos (100) a una aplicación en la nube (2) por una conexión de bajo rendimiento (3); - un receptor de acuse de recibo (11), adaptado para: - recibir por dicha conexión de bajo rendimiento (3) un mensaje de acuse de recibo (200) generado por dicha aplicación en la nube (2) y que contiene información de acuse de recibo para uno o más de dichos mensajes de datos (100); y - interpretar dicho mensaje de acuse de recibo (200); caracterizado porque dicho dispositivo operado con baterías (1) comprende además un generador de solicitud de acuse de recibo (12) adaptado para generar y enviar una solicitud (101) sobre dicha conexión de bajo rendimiento (3) a dicha aplicación en la nube (2) para dicho mensaje de acuse de recibo (200).

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Un dispositivo operado con baterías, aplicación en la nube y métodos relacionados para transmitir/recibir mensajes de datos por una red de bajo rendimiento

Campo de la invención

La presente invención se refiere al campo de las comunicaciones de radiofrecuencia de baja energía, y particularmente al campo de las comunicaciones de banda ultraestrecha por redes de bajo rendimiento como se define por ejemplo en las Especificaciones del Grupo del Instituto Europeo de Normas de Telecomunicaciones.

Antecedentes de la invención

La Red de Bajo Rendimiento, denominada además como tecnología LTN, es una red inalámbrica bidireccional de área amplia con algunas características específicas. LTN permite una transmisión de datos de largo rango, a distancias hasta varias decenas de kilómetros en campo abierto, y/o la comunicación con equipamiento enterrado bajo tierra. Los dispositivos que se comunican sobre lTn son típicamente operados con baterías. LTN opera con un mínimo consumo de energía permitiendo varios años de funcionamiento sin reemplazar las baterías aún con baterías estándares. Esta tecnología implementa además un bajo rendimiento junto con un procesamiento de señal avanzado que proporciona una protección efectiva contra las interferencias. De este modo, LTN es particularmente adecuado para la comunicación entre máquinas de bajo rendimiento donde el volumen de datos está limitado y la baja latencia no es un requerimiento muy importante. Las aplicaciones incluyen mediciones remotas, la medición inteligente de la distribución de agua, gas o electricidad o las aplicaciones de ciudades inteligentes tales como el monitoreo de la contaminación de aire o la iluminación pública en comunicación con varios sensores tales como detectores de humo, etc. Las aplicaciones pudieran además incluir una cooperación con redes celulares para dirigir los casos de uso donde es necesaria la conectividad redundante, complementaria o alternativa. Las especificaciones de las redes de bajo rendimiento se entienden como las especificaciones de la Red de Bajo rendimiento definida por el Instituto Europeo de Normas de Telecomunicaciones y denominada además ETSI LTN. Las especificaciones de ETSI LTN se listan en el reporte de Especificaciones del Grupo que describe la arquitectura funcional del LTN, titulado "ETSI GS LTN 002 V1.1.1" y publicado por ETSI en Septiembre 2014.

En la arquitectura LTN, los puntos de acceso LTN y los puntos de extremo LTN se comunican a través de una interfaz de radio. Se prevén dos implementaciones que se incluyen en la arquitectura LTN: La implementación de UNB que depende de la comunicación de Banda Ultraestrecha, y la implementación de OSSS que usa las tecnologías de Espectro de Propagación de Secuencia Ortogonal. La interfaz de radio UNB u OSSS proporciona un rango de transmisión aumentado con una cantidad limitada de energía gastada por el punto de extremo. El UNB u OSSS permite un gran número de puntos de extremo en una celda dada sin interferencia del espectro. Los enlaces ascendentes y descendentes son posibles con la solución UNB u OSSS.

Un esquema de modulación, conocido como LoRa, de largo alcance, usa una tecnología de radio basada en el Espectro de Propagación de Secuencia Ortogonal para conectar los dispositivos a su red de estaciones base. El uso de OSSS es esencial para proporcionar una red escalable, de alta capacidad, con consumo de energía muy bajo, mientras mantiene una infraestructura de celda basada en estrella simple y fácil de implementar. La red opera en las bandas Industriales, Científicas y Médicas disponibles globalmente, denominadas además bandas ISM, y coexiste en estas frecuencias con otras tecnologías de radio, pero sin ningún riesgo de colisiones o problemas de capacidad. LoRa usa actualmente la banda ISM Europea más popular de 868MHz así como la banda de 902-928MHz en EE.UU.

SIGFOX usa una tecnología de radio basada en Banda Ultraestrecha para conectar los dispositivos a su red global. El uso de UNB es esencial para proporcionar una red escalable, de alta capacidad, con consumo de energía muy bajo, mientras mantiene una infraestructura en estrella simple y fácil de implementar. La red SIGFOX opera en las bandas ISM globalmente disponibles, y coexiste en estas frecuencias con otras radiotecnologías, pero sin ningún riesgo de colisiones o problemas de capacidad. SIGFOX usa actualmente la banda Europea ISM más popular de 868MHz así como la banda de 902-928MHz en EE.UU., en dependencia de las regulaciones regionales específicas. La comunicación por SIGFOX se asegura de muchas maneras, incluyendo por ejemplo anti-replay, aleatorización de mensaje, secuenciación, etc. El aspecto más importante de la seguridad de transmisión es sin embargo que solamente los vendedores del dispositivo entienden los datos reales intercambiados entre el dispositivo y el sistema de Tecnología de la Información o TI. SIGFOX actúa solamente como una canal de transporte, que transporta los datos hacia el sistema de TI del cliente. Una ventaja importante proporcionada por el uso de la tecnología de banda estrecha es la flexibilidad que ofrece en términos de diseño de antena. En el extremo de la infraestructura de redes se permite el uso de antenas pequeñas y simples, pero más importante, se permite que los dispositivos usen antenas poco costosas y fácilmente personalizables.

La integridad de los datos de los mensajes unidireccionales por una LTN varía significativamente de acuerdo con la cobertura de la red geográfica y la posible presencia de puntos ciegos locales, para disminuir las condiciones de RF o aumentar la atenuación de la señal RF debido a la localización del dispositivo, la velocidad del dispositivo, la aceleración del dispositivo, las fuerzas de la naturaleza, la congestión de la infraestructura de redes, un fallo técnico o interrupción

5

10

15

20

25

30

35

40

45

50

55

60

65

de un servidor, al hecho de que se use la banda ISM y necesite compartirse con otros dispositivos, a las fuertes interferencias RF con otras señales RF, etc. Los puntos ciegos pueden encontrarse por ejemplo a lo largo de la trayectoria geográfica de un contenedor en un camión, o un avión, o un barco, o de cualquier otro objeto cuya posición geográfica cambia en el tiempo. Un dispositivo que rastrea la posición de un contenedor móvil o un objeto móvil envía un mensaje de datos por ejemplo que contiene información indicativa de la posición geográfica del contenedor o del objeto. Debido a la presencia aleatoria de los puntos ciegos, los mensajes de datos pueden no recibirse. El dispositivo intenta de este modo la retransmisión de los mensajes de datos múltiples veces para aumentar la posibilidad de que el mensaje se reciba para compensar la posible presencia de los puntos ciegos. Estas múltiples retransmisiones aumenta dramáticamente el consumo de energía del dispositivo a través de un uso excesivo e ineficiente de su batería, y de este modo reduce considerablemente la vida de su batería. Adicionalmente no existe garantía de que se reciban los mensajes unidireccionales transmitidos por el dispositivo, lo que limita fuertemente la integridad de los datos que puede lograrse. Además, cuando se usan los mensajes bidireccionales, solamente un número dado de intercambios bidireccionales están disponibles por día, lo que es insuficiente para la mayor parte de las aplicaciones que esperan el acuse de recibo de hasta cientos de mensajes que se transmiten por día.La solicitud de patente US2011/0295102 de Tensorcom Inc., titulada "Systems and methods for networked wearable medical sensors", publicada el 1ro de diciembre de 2011, describe un sistema sensor médico que comprende una puerta de enlace y al menos un sensor usable. Un sensor usable transmite una trama de datos del sensor hacia la puerta de enlace. Después de enviar la trama de datos del sensor, el sensor espera un período predeterminado y enciende su receptor de banda estrecha. La puerta de enlace es capaz de recibir y demodular la trama de datos del sensor usable. La puerta de enlace reconoce luego la recepción de la trama de datos del sensor transmitiendo una trama de acuse de recibo de regreso por el espectro de banda estrecha usando un transmisor de banda estrecha. En otras palabras, la puerta de enlace genera y envía una trama de acuse de recibo por trama de datos recibida del sensor, es decir la puerta de enlace genera y envía tantas tramas de acuse de recibo a medida que se recibe el número de tramas de datos del sensor. La puerta de enlace envía las tramas de acuse de recibo para todas las tramas de datos recibidas. La potencia de la batería se consume, además en el caso de que la integridad de los datos no se requiera al nivel de los mensajes de datos individuales. El receptor de banda estrecha del sensor usable debe permanecer encendido - por ejemplo por varios segundos o varios minutos, o varias horas - después que el sensor usable transmite una trama de datos del sensor para recibir una trama de acuse de recibo desde la puerta de enlace para la trama de datos del sensor respectiva. Esto aumenta el uso de la batería de los sensores usables y arriesga la vida útil a largo plazo de la batería del sensor usable. Además, si un sensor usable no recibe un acuse de recibo dentro de un período de tiempo dado, el sensor usable puede esperar un tiempo aleatorio e intentar la retransmisión del paquete de posicionamiento en un intervalo de tiempo diferente. Los mensajes se retransmiten de este modo múltiples veces para aumentar la posibilidad de que la puerta de enlace los reciba. Esto aumenta dramáticamente el consumo de energía del sensor usable a través de un uso excesivo e ineficiente de su batería, y de este modo reduce considerablemente la vida de la batería del sensor usable. Adicionalmente no existe garantía de que los mensajes unidireccionales transmitidos por el sensor usable se reciben por la puerta de enlace, lo que limita fuertemente la integridad de los datos que puede lograrse. La solicitud de patente GB2359225 describe una técnica de comunicación que permite la transmisión de datos por un bajo ancho de banda y/o enlace de comunicaciones con demoras de tiempo y minimiza el tiempo inactivo del enlace de comunicaciones usando un acuse de recibo diferido de paquetes de mensaje para el empaquetamiento temporal en el enlace de comunicaciones. De manera similar, en el documento GB2359225, si no se recibe un acuse de recibo oportuno después del período de expiración asociado a un conjunto de mensajes, todos los mensajes que han expirado se reenvían.

Es un objetivo describir un dispositivo, una aplicación en la nube y los métodos relacionados que superan los inconvenientes de las soluciones existentes anteriormente identificados. Más particularmente, es un objetivo describir tal dispositivo, una aplicación en la nube y los métodos para proporcionar al dispositivo de manera más confiable y robusta un acuse de recibo de recepción de los mensajes transmitidos por el dispositivo a la aplicación en la nube. Es un objetivo adicional describir tal dispositivo, una aplicación en la nube y los métodos relacionados que aseguran la integridad de los mensajes transmitidos, aun cuando la posición geográfica del dispositivo cambia con el tiempo, sin la necesidad de múltiples retransmisiones de todos los mensajes. Es un objetivo adicional optimizar el uso de la batería del dispositivo que transmite los mensajes para preservar la vida de su batería. Es un objetivo adicional describir tal dispositivo, una aplicación en la nube y los métodos relacionados para acusar recibo de los mensajes de una manera flexible, eficiente, fiable y adaptable en dependencia de la cobertura de la red geográfica y del nivel de la batería del dispositivo.

Resumen de la invención

De acuerdo con un primer aspecto de la presente invención, los objetivos definidos anteriormente se llevan a cabo por un dispositivo operado con baterías para transmitir los mensajes de datos de acuerdo con la reivindicación 1, el dispositivo comprende:

- una interfaz de red de bajo rendimiento, adaptada para enviar los mensajes de datos a una aplicación en la nube

sobre una conexión de bajo rendimiento;

- un receptor de acuse de recibo, adaptado para:

- recibir por la conexión de bajo rendimiento un mensaje de acuse de recibo generado por la aplicación en la nube y que contiene la información de acuse de recibo para uno o más mensajes de datos; e

- interpretar el mensaje de acuse de recibo;

5

10

15

20

25

30

35

40

45

50

55

60

65

caracterizado porque el dispositivo operado con baterías comprende además un generador de solicitud de acuse de recibo adaptado para generar y enviar una solicitud sobre la red de bajo rendimiento a la aplicación en la nube para el mensaje de acuse de recibo.

De acuerdo con la presente invención, la integridad de los datos de los mensajes de datos durante la transmisión de un dispositivo operado con baterías a una aplicación en la nube se garantiza siempre que se desea. De hecho, el dispositivo operado con baterías solicita el acuse de recibo de los mensajes de datos que el dispositivo operado con baterías envía a la aplicación en la nube. Después de recibir la solicitud, la aplicación en la nube envía mensajes de acuse de recibo que contienen información acusando recibo de los mensajes de datos desde el dispositivo operado con baterías. Los mensajes de acuse de recibo generados por la aplicación en la nube se interpretan luego por el dispositivo operado con baterías para identificar los mensajes de datos que se enviaron a la aplicación en la nube pero no se reciben por la aplicación en la nube, por ejemplo debido a una baja cobertura de la red geográfica, la presencia de los puntos ciegos locales, condiciones de baja RF debido a la localización del dispositivo, a la velocidad del dispositivo, etc. De esta manera, el dispositivo operado con baterías está al tanto de los mensajes de datos que no se recibieron por la aplicación en la nube y que necesitan retransmitirse para garantizar la integridad de los datos siempre que el dispositivo operado con baterías lo desee. El dispositivo operado con baterías luego retransmite selectivamente los mensajes de datos cuya recepción no se acusó por la aplicación en la nube. Además, el uso de la batería del dispositivo operado con baterías se optimiza para aumentar su tiempo de vida. De hecho, la generación de los mensajes de acuse de recibo por la aplicación en la nube se activa por la recepción de una solicitud generada por el dispositivo operado con baterías. Para la aplicación para la cual no es obligatorio recibir un mensaje de acuse de recibo para todos los mensajes de datos enviados, el dispositivo operado con baterías no envía una solicitud a la aplicación en la nube para acusar recibo de todos los mensajes de datos. Si el dispositivo operado con baterías decide ahorrar batería, el dispositivo operado con baterías no envía una solicitud. Si el dispositivo operado con baterías decide asegurar la integridad de los datos de su transmisión, el dispositivo operado con baterías decide cuándo enviar una solicitud para acusar recibo a la aplicación en la nube. Esto evita que la aplicación en la nube genere y envíe un mensaje de acuse de recibo al dispositivo operado con baterías en un momento en el tiempo cuando el dispositivo operado con baterías no esté disponible o no se alcance, o cuando la red de bajo rendimiento está ocupada, o cuando la aplicación en donde el dispositivo operado con baterías se usa no requiere la integridad de los datos. De esta manera, la comunicación asegura que un mensaje de acuse de recibo se reciba por el dispositivo operado con baterías cuando el dispositivo operado con baterías está disponible. Esto reduce el gasto de la batería del dispositivo ya que el dispositivo operado con baterías elige el momento en el que escucha un mensaje de acuse de recibo desde la aplicación en la nube. El dispositivo operado con baterías de este modo no necesita permanecer encendido para recibir el mensaje de acuse de recibo. Además, ya que el pico de corriente en un dispositivo de acuerdo con la presente invención es por ejemplo mucho menor que por ejemplo en un teléfono, el diseño de la batería de tal dispositivo puede optimizarse y miniaturizarse, lo que reduce drásticamente los costos asociados a su producción. Además, el dispositivo operado con baterías solamente retransmite los mensajes de datos selectivamente de acuerdo con la información contenida en el mensaje de acuse de recibo, y de este modo no necesita retransmitir todos los mensajes de datos múltiples veces. Esto reduce drásticamente el consumo de energía del dispositivo operado con baterías y aumenta la vida de la batería del dispositivo operado con baterías. Una batería de un dispositivo de acuerdo con la presente invención puede en cambio durar varios años, incluso decenas de años. La flexibilidad se proporciona además a la comunicación entre el dispositivo operado con baterías y la aplicación en la nube, a medida que el dispositivo operado con baterías elige cuándo enviar la solicitud para un mensaje de acuse de recibo. La transmisión de la solicitud puede programarse en el tiempo, o puede planearse en dependencia del número de mensajes de datos que ya se han enviado. La solicitud inicia un procedimiento de transferencia bidireccional entre el dispositivo operado con baterías y la aplicación en la nube. La aplicación en la nube puede recoger estadísticas sobre el número de retransmisiones, en el número de mensajes total transmitidos por el dispositivo operado con baterías, etc.

Las especificaciones de la red de bajo rendimiento de acuerdo con la presente invención se entienden como las especificaciones de la red de bajo rendimiento definida por el Instituto Europeo de Normas de Telecomunicaciones y denominada además ETSI LTN. Las especificaciones de ETSI LTN se listan en el reporte de Especificaciones del Grupo que describe la arquitectura funcional del LTN, titulado "ETSI GS LTN 002 V1.1.1" y publicado por ETSI en Septiembre 2014. Las propiedades de la red de bajo rendimiento de acuerdo con la presente invención comprenden de este modo por ejemplo un rendimiento alrededor de 200 Bytes por día a 5 kBytes por día y/o un tamaño de la carga de 12 Bytes, con un máximo de 255 Bytes y/o un rendimiento instantáneo con un pico de entre 10 y 1000 bps y con un máximo de 50 kbps y/o la capacidad de manejar 10 objetos conectados por habitante y/o la capacidad de proporcionar funciones de seguridad entre el objeto de la red de bajo rendimiento y la plataforma del proveedor de la aplicación, tal como protección contra spoofing, robo, manipulación, de código variable, etc. Esto es solamente un ejemplo de un LTN. Las propiedades de la red de bajo rendimiento de acuerdo con la presente invención comprenden además futuras extensiones de las propiedades de una red de bajo rendimiento con respecto al estándar ETSI LTN actual y/o cualquier versión futura de las especificaciones del estándar ETSI LTN. Por ejemplo, las propiedades de una red de bajo rendimiento pudiera además comprender un rendimiento de alrededor de 100 Bytes por día a 10 kBytes por día y/o un tamaño de la carga de 6 Bytes, con un máximo de 510 Bytes y/o un rendimiento instantáneo pico de entre 5 y 500 bps y con un máximo de 100 kbps y/o la capacidad de manejar hasta 20 objetos conectados por habitante y/o la capacidad de proporcionar funciones de seguridad entre el objeto de red de bajo rendimiento y la plataforma del proveedor de la aplicación, tal como protección contra spoofing, robos, manipulación, de código variable, etc. Esto es solamente un ejemplo de un LTN futuro. De acuerdo con la presente invención, un dispositivo operado con baterías es cualquier dispositivo adecuado con conectividad de datos inalámbricos. Un dispositivo operado con baterías puede por ejemplo

5

10

15

20

25

30

35

40

45

50

55

60

65

ser un teléfono, un sensor, un detector, tal como un detector de humo o un detector de fuego o un detector de fuga de gas o fuga de agua o un detector de presencia, o un dispositivo de rastreo de la localización. El dispositivo puede operarse mediante la batería de un carro, de un tren, de un camión, de un plano, de una bicicleta, mediante baterías USB, mediante celdas solares, etc. De acuerdo con la presente invención, los mensajes de datos pueden contener datos indicativos de una característica del dispositivo operado con baterías, y/o los datos indicativos de las mediciones realizadas por el dispositivo operado con baterías, por ejemplo la localización detectada del dispositivo operado con baterías, una concentración medida de un componente químico dado en una fase gaseosa, la detección de un movimiento en las cercanías del dispositivo operado con baterías, etc. Alternativamente, un mensaje de datos no contiene ningún dato como tal, sino que debe entenderse como una parte de un protocolo. De acuerdo con la presente invención, los mensajes de acuse de recibo se generan por la aplicación en la nube y se envían al dispositivo operado con baterías sobre la conexión de bajo rendimiento. De acuerdo la presente invención, el generador de la solicitud de acuse de recibo genera una solicitud de mensajes de acuse de recibo que contienen información de acuse de recibo para el uno o más mensajes de datos enviados. La información de acuse de recibo para los mensajes de datos de acuerdo con la presente invención es por ejemplo las identidades de los mensajes de datos transmitidos por el dispositivo operado con baterías y recibidos por la aplicación en la nube. Alternativamente, la información de acuse de recibo para los mensajes de datos es por ejemplo las identidades de los mensajes de los mensajes de datos enviados por el dispositivo operado con baterías y que no se recibieron por la aplicación en la nube. De hecho, la aplicación en la nube puede recibir en la solicitud enviada por la batería, la información operada indicativa de los mensajes de datos que se enviaron por el mismo dispositivo operado con baterías. La aplicación en la nube es capaz de identificar las identidades de los mensajes de datos que recibe del dispositivo operado con baterías y/o puede además ser capaz de identificar las identidades de los mensajes de datos que se enviaron por el dispositivo operado con baterías pero que no están. De acuerdo con la invención, la solicitud se envía por la red de bajo rendimiento.

De acuerdo con una modalidad óptima, el receptor de acuse de recibo se adapta adicionalmente a recibir e interpretar un único mensaje de acuse de recibo que contiene información de acuse de recibo para una pluralidad de los mensajes de datos.

De esta manera, el tiempo de vida de la batería del dispositivo se preserva adicionalmente. De hecho, el dispositivo operado con baterías recibe un único mensaje de acuse de recibo para una pluralidad de mensajes de datos, en lugar de recibir un mensaje de acuse de recibo para cada mensaje de datos que envía el dispositivo operado con baterías. Esto significa que el dispositivo operado con baterías no usa su batería para enviar una solicitud y para recibir un mensaje de acuse de recibo después de cada transmisión, sino que el dispositivo operado con baterías puede elegir cuándo recibir un único mensaje de acuse de recibo para una pluralidad de mensajes de datos que envía el dispositivo operado con baterías. Esto optimiza el uso de la batería del dispositivo operado con baterías. La solicitud puede contener información indicativa de la pluralidad de mensajes de datos para los cuales se desea un acuse de recibo, o la aplicación en la nube puede enviar automáticamente el acuse de recibo para la pluralidad de mensajes de datos, por ejemplo los últimos mensajes de datos, por ejemplo los últimos 10 mensajes o los últimos 64 mensajes, todos los mensajes recibidos dentro de un intervalo de tiempo, por ejemplo dentro del último segundo, o dentro del último minuto, o dentro de la ultima hora, o dentro del último día, etc.

De acuerdo con una modalidad opcional, la solicitud es uno de los mensajes de datos.

De esta manera, la solicitud se envía por la red de bajo rendimiento como uno de los mensajes de datos. Esto facilita la generación de la solicitud mediante el dispositivo operado con baterías a medida que el formato de la solicitud sea similar al formato de cualquier otro mensaje de datos, y facilita además la interpretación de la solicitud por la aplicación en la nube. De hecho, la aplicación en la nube no necesita convertir un formato diferente al de los mensajes de datos para interpretar la solicitud, que acelera y simplifica la interpretación de la aplicación en la nube.

De acuerdo con una modalidad opcional, uno de dichos mensajes de datos comprende dicha solicitud.

De esta manera, el dispositivo operado con baterías no necesita generar una solicitud independiente a medida que la solicitud se incluye en uno de los mensajes de datos. Esto ahorra la batería del dispositivo operado con baterías.

De acuerdo con una modalidad opcional, el dispositivo comprende además:

- un generador de la identidad de mensaje, adaptado para generar una identidad de mensaje para cada uno de los mensajes de datos;

y en donde:

- la identidad del mensaje es un valor numérico.

De esta manera, cada mensaje de datos unidireccional comprende una única identidad del mensaje. Un tamaño adecuado y/o una localización adecuada de la identidad del mensaje pueden elegirse arbitrariamente en dependencia de la aplicación. Por ejemplo, una identidad del mensaje de 6 bits de longitud puede usarse para maximizar la eficiencia de la comunicación en mensajes bidireccionales de 8 bytes. Una identidad del mensaje se asocia a cada mensaje de datos durante la creación de los mensajes de datos respectivos. La identidad del mensaje es un valor numérico que puede por ejemplo elegirse de una lista de valores de identidad del mensaje disponibles. Por ejemplo, en el caso de identidades del mensaje de 6-bits de longitud, existen 26, es decir 64, identidades del mensaje posibles para los

5

10

15

20

25

30

35

40

45

50

55

60

65

mensajes de datos. Para cada mensaje de datos en el caso de las identidades del mensaje de 6-bits de longitud, el generador de la identidad del mensaje elige una identidad del mensaje única y disponible con respecto a las 64 posibles. Por ejemplo, el valor de la identidad del mensaje del primer mensaje de datos transmitido puede ser 0, el valor de la identidad del mensaje del segundo mensaje de datos transmitido puede ser 1, el valor de la identidad del mensaje del tercer mensaje de datos transmitido puede ser 2, y así sucesivamente. En este caso, el valor numérico de la identidad del mensaje es un dígito incrementado en 1 para cada uno de los próximos mensajes de datos transmitidos. Alternativamente, el valor numérico de la identidad del mensaje es un valor numérico incrementado un valor numérico diferente a 1. Alternativamente, en el caso de las identidades del mensaje de 6-bits de longitud, el valor de la identidad del mensaje del primer mensaje de datos transmitido puede ser 64, el valor de la identidad del mensaje del segundo mensaje de datos transmitido puede ser 63, el valor de la identidad del mensaje del tercer mensaje de datos transmitido puede ser 62, y así sucesivamente. En este caso, el valor numérico de la identidad del mensaje es un dígito decrementado en 1 para cada uno de los próximos mensajes de datos transmitidos. Alternativamente, el valor numérico de la identidad del mensaje es un valor numérico decrementado un valor numérico diferente a 1. Alternativamente, el valor numérico de la identidad del mensaje de un mensaje de datos puede ser cualquier valor numérico aleatorio, y la asignación de la identidad de los mensajes de datos hacia los mensajes de datos puede ser aleatoria de manera que la identidad de los mensajes de datos de los primeros mensajes de datos transmitidos se elige arbitrariamente, y la identidad del mensaje del segundo mensaje de datos transmitido se elige además arbitrariamente y así sucesivamente. De esta manera, cada mensaje de datos puede identificarse individualmente por el dispositivo operado con baterías y por la aplicación en la nube.

De acuerdo con una modalidad opcional:

- la solicitud comprende un valor de conteo de la identidad del mensaje indicativo de las identidades del mensaje de los mensajes de datos enviados por el dispositivo operado con baterías; y

- el generador de solicitud de acuse de recibo de adapta para generar un mensaje de acuse de recibo cuya longitud en bits corresponde a la identidad máxima del valor de conteo de la identidad del mensaje.

De esta manera, el dispositivo operado con baterías está al tanto del número de mensajes de datos que se transmiten a la aplicación en la nube y de las identidades del mensaje de los mensajes de datos transmitidos a la aplicación en la nube. El tamaño y la localización de la identidad del valor de conteo de la identidad del mensaje pueden elegirse arbitrariamente en dependencia de la aplicación. Además, la aplicación en la nube se adapta para recuperar la identidad del valor de conteo de la identidad del mensaje de la solicitud. La aplicación en la nube luego se pone al tanto del número de mensajes de datos que se enviaron por el dispositivo operado con baterías así como de las identidades del mensaje de los mensajes de datos que se transmitieron. Esta mejora el tiempo de vida de la batería debido a que es una manera compacta, codificada de acusar recibo de un gran número de mensajes con un único mensaje de acuse de recibo. Esto mejora la integridad de los datos de la comunicación entre el dispositivo operado con baterías y la aplicación en la nube, ya que la aplicación en la nube es capaz de comparar las identidades de los mensajes de datos que recibe con las identidades del mensaje comprendidas en el valor de conteo de la identidad del mensaje. Si la aplicación en la nube no encuentra todas las identidades del mensaje comprendidas en la identidad del valor de conteo en los mensajes de datos que recibe la aplicación en la nube concluye que algunos mensajes de datos que fueron enviados por el dispositivo operado con baterías no se recibieron por la aplicación en la nube. Si la aplicación en la nube encuentra todas las identidades del mensaje comprendidas en la identidad del valor de conteo en los mensajes de datos que recibe, entonces la integridad de los datos se asegura y es igual a 100 %. Cada identidad de los mensajes de datos enviados por el dispositivo operado con baterías corresponde a un bit en el mensaje de acuse de recibo. Por ejemplo, la codificación del mensaje de enlace descendente de 8 bytes se formatea como un bit por identidad del mensaje. Cada localización en el mensaje de acuse de recibo corresponde a una identidad del mensaje. El mapeo de las identidades del mensaje en el mensaje de acuse de recibo es flexible y puede elegirse arbitrariamente. Por ejemplo, los 64 bits coinciden con la identidad del mensaje de 6 bits de los mensajes unidireccionales. De esta manera, la interpretación del mensaje de acuse de recibo se hace simple para el dispositivo operado con baterías ya que cada bit del mensaje de acuse de recibo corresponde a un mensaje de datos que envía el dispositivo operado con baterías. Por ejemplo, un bit igual a 1 en el mensaje de acuse de recibo indica que los mensajes de datos se han recibido por la aplicación en la nube, y un bit igual a 0 en el mensaje de acuse de recibo indica que los mensajes de datos no se han recibido por la aplicación en la nube.

De acuerdo con una modalidad opcional, el dispositivo comprende además:

- Una máquina de extracción de la identidad del mensaje, se adapta para extraer las identidades del mensaje de acuse de recibo y para identificar las identidades de los mensajes de datos que no están en el mensaje de acuse de recibo; y

en donde el dispositivo operado con baterías se adapta adicionalmente para reenviar un mensaje de datos cuya identidad del mensaje no está en el mensaje de acuse de recibo.

De esta manera, el dispositivo operado con baterías es capaz de extraer del mensaje de acuse de recibo las identidades de los mensajes de datos que no se recibieron por la aplicación en la nube. El dispositivo operado con baterías luego envía selectivamente los mensajes de datos perdidos de regreso a la aplicación en la nube. Esto ahorra el tiempo de vida de la batería del dispositivo ya que el dispositivo no necesita enviar todos los mensajes de datos múltiples veces.

De acuerdo con una modalidad opcional, el dispositivo comprende además una caché del dispositivo adaptada para

5

10

15

20

25

30

35

40

45

50

55

60

65

almacenar los mensajes de datos, y en donde el dispositivo se adapta adicionalmente para borrar un mensaje de datos para el cual se ha recibido el acuse de recibo.

De esta manera, el dispositivo operado con baterías es capaz de almacenar los mensajes de datos hasta que la aplicación en la nube acusa recibo de los mismos mensajes de datos. Esto optimiza el uso de la caché del lado del dispositivo operado con baterías ya que los mensajes de datos de acuse de recibo no permanecen almacenados. De esta manera, las identidades del mensaje de los mensajes de datos borrados se vuelven disponibles nuevamente y pueden atribuirse a los nuevos mensajes de datos. Los mensajes de datos restantes que no se recibieron por la aplicación en la nube se ponen en cola para la transmisión y no se altera la identidad de los mensajes. Además, esta permite que los dispositivos operados con batería recuperen los mensajes de datos en una etapa posterior si fuera necesario, de manera que los mensajes de datos puedan retransmitirse si no se reciben por la aplicación en la nube. Para las aplicaciones en las cuales no es necesario almacenar todos los mensajes de datos en la caché del dispositivo, no todos los mensajes de datos que se enviaron a la aplicación en la nube se almacenan en la caché. Esto ahorra energía de procesamiento y ahorra además el tiempo de vida de la batería del dispositivo.

De acuerdo con una modalidad opcional, el dispositivo comprende además:

- Un generador de mensajes de acuse de recibo del dispositivo, adaptado para generar automáticamente un mensaje de acuse de recibo del dispositivo que acusa recibo de los mensajes de acuse de recibo y que envía el mensaje de acuse de recibo del dispositivo a la aplicación en la nube.

De esta manera, la aplicación en la nube está al tanto de si el mensaje de acuse de recibo se recibe por el dispositivo operado con baterías. Esto mejora la fiabilidad de la comunicación entre el dispositivo operado con baterías y la aplicación en la nube ya que la aplicación en la nube recibe una confirmación de que el dispositivo operado con baterías está al tanto de los mensajes de datos perdidos. Por ejemplo, el mensaje de acuse de recibo del dispositivo comprende 8 bits con parámetros de configuración. De acuerdo con una modalidad alternativa, un mensaje de datos comprende el mensaje de acuse de recibo del dispositivo que acusa recibo del mensaje de acuse de recibo.

De acuerdo con una modalidad opcional:

- el dispositivo operado con baterías se adapta adicionalmente para generar una solicitud de configuración a la aplicación en la nube;

- la aplicación en la nube se adapta adicionalmente para generar un mensaje de configuración que contiene información indicativa de los parámetros de configuración y para enviar el mensaje de configuración al dispositivo operado con baterías;

- el dispositivo operado con baterías se adapta adicionalmente para generar un mensaje de configuración de acuse de recibo que contiene información de acuse de recibo para el mensaje de configuración.

La solicitud de configuración enviada por el dispositivo operado con baterías a la aplicación en la nube comprende una solicitud de configuración para preguntar a la aplicación en la nube si una actualización de la configuración está disponible. Una comunicación bidireccional entre el dispositivo operado con baterías y la aplicación en la nube se inicia de este modo. Después de recibir la solicitud de configuración, la aplicación en la nube genera un mensaje de configuración que comprende uno o más de los parámetros de configuración y por ejemplo una única identidad del parámetro de configuración. Después de recibir el mensaje de configuración, el dispositivo operado con baterías extrae la identidad del parámetro de configuración del mensaje de configuración. El dispositivo operado con baterías acepta luego el mensaje de configuración y confirma la recepción del mensaje de configuración si la identidad del parámetro de configuración extraída es correcto, o rechaza el mensaje de configuración si la identidad extraída del parámetro de configuración no es correcta. Para confirmar la recepción del mensaje de configuración, el dispositivo operado con baterías genera un mensaje de configuración de acuse de recibo y envía este mensaje de configuración de acuse de recibo a la aplicación en la nube junto con uno o más mensajes de datos. El uso de la solicitud de configuración hace que la comunicación entre el dispositivo operado con baterías y la aplicación en la nube sea muy fiable y garantiza una integridad de los datos de hasta 100 %. De hecho, la recepción de los mensajes de datos generados por el dispositivo operado con baterías así como la recepción de los mensajes de configuración generados por la aplicación en la nube se reconocen respectivamente por la aplicación en la nube y el dispositivo operado con baterías. Por ejemplo, si la solicitud enviada por el dispositivo operado con baterías no se recibe por la aplicación en la nube, el dispositivo operado con baterías envía la solicitud de configuración nuevamente a la aplicación en la nube. Además, si por ejemplo el mensaje de configuración generado por la aplicación en la nube no se recibe por el dispositivo operado con baterías, el dispositivo operado con baterías está al tanto de que no recibió un mensaje de configuración y de este modo, el dispositivo operado con baterías envía nuevamente la solicitud de configuración a la aplicación en la nube. La aplicación en la nube se mantiene luego enviando el mismo mensaje de configuración al dispositivo operado con baterías. Por ejemplo, si el dispositivo operado con baterías no acepta el mensaje de configuración, ningún mensaje de configuración de acuse de recibo indicativo de recepción del mensaje de configuración se genera por el dispositivo operado con baterías. Después de recibir los mensajes de datos del dispositivo operado con baterías, la aplicación en la nube genera los mensajes de acuse de recibo desde el cual el dispositivo operado con baterías está al tanto de si los mensajes de datos se recibieron o no por la aplicación en la nube. Si no, los mensajes de datos se envían nuevamente. Por ejemplo, si la aplicación en la nube no recibe una solicitud para mensajes de acuse de recibo, el dispositivo operado con baterías está al tanto de que la aplicación en la nube no lo recibió ya que el dispositivo operado con baterías no recibe los mensajes de acuse de recibo. El dispositivo operado con baterías envía de este modo la solicitud de mensajes de acuse

5

10

15

20

25

30

35

40

45

50

55

60

65

de recibo a la aplicación en la nube nuevamente. Es decir, el dispositivo operado con baterías y la aplicación en la nube están siempre al tanto de que se sincronizan entre sí.

De acuerdo con un segundo aspecto de la presente invención, se proporciona un método de transmisión de mensajes de datos desde un dispositivo operado con batería de acuerdo con la reivindicación 11.

De acuerdo con la presente invención, la integridad de los datos de los mensajes de datos durante la transmisión de un dispositivo operado con baterías a una aplicación en la nube se garantiza siempre que se desea. De hecho, el dispositivo operado con baterías solicita el acuse de recibo de los mensajes de datos que el dispositivo operado con baterías envía a la aplicación en la nube. Después de recibir la solicitud, la aplicación en la nube envía mensajes de acuse de recibo que contienen información acusando recibo de los mensajes de datos desde el dispositivo operado con baterías. Los mensajes de acuse de recibo generados por la aplicación en la nube se interpretan luego por el dispositivo operado con baterías para identificar los mensajes de datos que se enviaron a la aplicación en la nube pero no se reciben por la aplicación en la nube, por ejemplo debido a una baja cobertura de la red geográfica, la presencia de los puntos ciegos locales, condiciones de baja RF debido a la localización del dispositivo, a la velocidad del dispositivo, etc. De esta manera, el dispositivo operado con baterías está al tanto de los mensajes de datos que no se recibieron por la aplicación en la nube y que necesitan retransmitirse para garantizar la integridad de los datos siempre que el dispositivo operado con baterías lo desee. El dispositivo operado con baterías luego retransmite selectivamente los mensajes de datos cuya recepción no se acusó por la aplicación en la nube. Además, el uso de la batería del dispositivo operado con baterías se optimiza para aumentar su tiempo de vida. De hecho, la generación de los mensajes de acuse de recibo por la aplicación en la nube se activa por la recepción de una solicitud generada por el dispositivo operado con baterías. Para la aplicación para la cual no es obligatorio recibir un mensaje de acuse de recibo para todos los mensajes de datos enviados, el dispositivo operado con baterías no envía una solicitud a la aplicación en la nube para acusar recibo de todos los mensajes de datos. Si el dispositivo operado con baterías decide ahorrar batería, el dispositivo operado con baterías no envía una solicitud. Si el dispositivo operado con baterías decide asegurar la integridad de los datos de su transmisión, el dispositivo operado con baterías decide cuándo enviar una solicitud para acusar recibo a la aplicación en la nube. Esto evita que la aplicación en la nube genere y envíe un mensaje de acuse de recibo al dispositivo operado con baterías en un momento en el tiempo cuando el dispositivo operado con baterías no esté disponible o no se alcance, o cuando la red de bajo rendimiento está ocupada, o cuando la aplicación en donde el dispositivo operado con baterías se usa no requiere la integridad de los datos. De esta manera, la comunicación asegura que un mensaje de acuse de recibo se reciba por el dispositivo operado con baterías cuando el dispositivo operado con baterías está disponible. Esto reduce el gasto de la batería del dispositivo ya que el dispositivo operado con baterías elige el momento en el que escucha un mensaje de acuse de recibo desde la aplicación en la nube. El dispositivo operado con baterías de este modo no necesita permanecer encendido para recibir un mensaje de acuse de recibo. Además, ya que el pico de corriente en un dispositivo de acuerdo con la presente invención es por ejemplo mucho menor que por ejemplo en un teléfono, el diseño de la batería de tal dispositivo puede optimizarse y miniaturizarse, lo que reduce drásticamente los costos asociados a su producción. Además, el dispositivo operado con baterías solamente retransmite los mensajes de datos selectivamente de acuerdo con la información contenida en el mensaje de acuse de recibo, y de este modo no necesita retransmitir todos los mensajes de datos múltiples veces. Esto reduce drásticamente el consumo de energía del dispositivo operado con baterías y aumenta la vida de la batería del dispositivo operado con baterías. Una batería de un dispositivo de acuerdo con la presente invención puede en cambio durar varios años, incluso decenas de años. La flexibilidad se proporciona además a la comunicación entre el dispositivo operado con baterías y la aplicación en la nube, a medida que el dispositivo operado con baterías elige cuándo enviar la solicitud para un mensaje de acuse de recibo. La transmisión de la solicitud puede programarse en el tiempo, o puede planearse en dependencia del número de mensajes de datos que ya se han enviado. La solicitud inicia un procedimiento de transferencia bidireccional entre el dispositivo operado con baterías y la aplicación en la nube. La aplicación en la nube puede recoger estadísticas sobre el número de retransmisiones, en el número de mensajes total transmitidos por el dispositivo operado con baterías, etc.

De acuerdo con un tercer aspecto de la presente invención, los objetivos definidos anteriormente se llevan a cabo mediante un sistema informático para alojar una aplicación en la nube de acuerdo con la reivindicación 12.

De acuerdo con la presente invención, la integridad de los datos de los mensajes de datos durante la transmisión de un dispositivo operado con baterías a una aplicación en la nube se garantiza siempre que se desea. De hecho, el dispositivo operado con baterías solicita el acuse de recibo de los mensajes de datos que el dispositivo operado con baterías envía a la aplicación en la nube. Después de recibir la solicitud, la aplicación en la nube envía mensajes de acuse de recibo que contienen información acusando recibo de los mensajes de datos desde el dispositivo operado con baterías. Los mensajes de acuse de recibo generados por la aplicación en la nube se interpretan luego por el dispositivo operado con baterías para identificar los mensajes de datos que se enviaron a la aplicación en la nube pero no se reciben por la aplicación en la nube, por ejemplo debido a una baja cobertura de la red geográfica, la presencia de los puntos ciegos locales, condiciones de baja RF debido a la localización del dispositivo, a la velocidad del dispositivo, etc. De esta manera, el dispositivo operado con baterías está al tanto de los mensajes de datos que no se recibieron por la aplicación en la nube y que necesitan retransmitirse para garantizar la integridad de los datos siempre que el dispositivo operado con baterías lo desee. El dispositivo operado con baterías luego retransmite selectivamente los mensajes de datos cuya recepción no se acusó por la aplicación en la nube. Además, el uso de la batería del dispositivo operado con baterías se optimiza para aumentar su tiempo de vida. De hecho, la generación de los mensajes de acuse de recibo por la aplicación en la nube se activa por la recepción de una solicitud generada por el dispositivo operado con baterías.

5

10

15

20

25

30

35

40

45

50

55

60

65

Para la aplicación para la cual no es obligatorio recibir un mensaje de acuse de recibo para todos los mensajes de datos enviados, el dispositivo operado con baterías no envía una solicitud a la aplicación en la nube para acusar recibo de todos los mensajes de datos. Si el dispositivo operado con baterías decide ahorrar batería, el dispositivo operado con baterías no envía una solicitud. Si el dispositivo operado con baterías decide asegurar la integridad de los datos de su transmisión, el dispositivo operado con baterías decide cuándo enviar una solicitud para acusar recibo a la aplicación en la nube. Esto evita que la aplicación en la nube genere y envíe un mensaje de acuse de recibo al dispositivo operado con baterías en un momento en el tiempo cuando el dispositivo operado con baterías no esté disponible o no se alcance, o cuando la red de bajo rendimiento está ocupada, o cuando la aplicación en donde el dispositivo operado con baterías se usa no requiere la integridad de los datos. De esta manera, la comunicación asegura que un mensaje de acuse de recibo se reciba por el dispositivo operado con baterías cuando el dispositivo operado con baterías está disponible. Esto reduce el gasto de la batería del dispositivo ya que el dispositivo operado con baterías elige el momento en el que escucha un mensaje de acuse de recibo desde la aplicación en la nube. El dispositivo operado con baterías de este modo no necesita permanecer encendido para recibir un mensaje de acuse de recibo. Además, ya que el pico de corriente en un dispositivo de acuerdo con la presente invención es por ejemplo mucho menor que por ejemplo en un teléfono, el diseño de la batería de tal dispositivo puede optimizarse y miniaturizarse, lo que reduce drásticamente los costos asociados a su producción. Además, el dispositivo operado con baterías solamente retransmite los mensajes de datos selectivamente de acuerdo con la información contenida en el mensaje de acuse de recibo, y de este modo no necesita retransmitir todos los mensajes de datos múltiples veces. Esto reduce drásticamente el consumo de energía del dispositivo operado con baterías y aumenta la vida de la batería del dispositivo operado con baterías. Una batería de un dispositivo de acuerdo con la presente invención puede en cambio durar varios años, incluso decenas de años. La flexibilidad se proporciona además a la comunicación entre el dispositivo operado con baterías y la aplicación en la nube, a medida que el dispositivo operado con baterías elige cuándo enviar la solicitud para un mensaje de acuse de recibo. La transmisión de la solicitud puede programarse en el tiempo, o puede planearse en dependencia del número de mensajes de datos que ya se han enviado. La solicitud inicia un procedimiento de transferencia bidireccional entre el dispositivo operado con baterías y la aplicación en la nube. La aplicación en la nube puede recoger estadísticas sobre el número de retransmisiones, en el número de mensajes total transmitidos por el dispositivo operado con baterías, etc.

De acuerdo con una modalidad opcional, en donde el generador de acuse de recibo se adapta adicionalmente para generar un único mensaje de acuse de recibo que contiene información de acuse de recibo para una pluralidad de los mensajes de datos.

De esta manera, se preserva el tiempo de vida de la batería del dispositivo. De hecho, el dispositivo operado con baterías recibe un único mensaje de acuse de recibo para una pluralidad de mensajes de datos, en lugar de recibir un mensaje de acuse de recibo para cada mensaje de datos que envía el dispositivo operado con baterías. Esto implica que el dispositivo operado con baterías no usa su batería para recibir un mensaje de acuse de recibo después de cada transmisión, pero el dispositivo operado con baterías puede elegir cuándo recibir un único mensaje de acuse de recibo para una pluralidad de mensajes de datos enviados por el dispositivo operado con baterías. Esto optimiza el uso de la batería del dispositivo operado con baterías. Este además reduce el consumo de energía de la aplicación en la nube que solamente genera un único mensaje de acuse de recibo para una pluralidad de mensajes de datos. De este modo se disminuyen los costos asociados a su implementación.

De acuerdo con una modalidad opcional:

- un extractor de la identidad del mensaje adaptado para extraer una identidad del mensaje de cada mensaje de datos recibido;

- un intérprete de la solicitud adaptado para interpretar la solicitud y aprender qué acuse de recibo de los mensajes de datos se solicita;

y en donde el generador de acuse de recibo se adapta adicionalmente para generar un mensaje de acuse de recibo para los mensajes de datos recibidos.

De esta manera, el dispositivo operado con baterías está al tanto del número de mensajes de datos que se transmiten a la aplicación en la nube y de las identidades del mensaje de los mensajes de datos transmitidos a la aplicación en la nube. El tamaño y la localización de la identidad del valor de conteo de la identidad del mensaje pueden elegirse arbitrariamente en dependencia de la aplicación. Además, la aplicación en la nube se adapta para recuperar la identidad del valor de conteo de la identidad del mensaje de la solicitud. La aplicación en la nube luego se pone al tanto del número de mensajes de datos que se enviaron por el dispositivo operado con baterías así como de las identidades del mensaje de los mensajes de datos que se transmitieron. Esto mejora la integridad de los datos de la comunicación entre el dispositivo operado con baterías y la aplicación en la nube, ya que la aplicación en la nube es capaz de comparar las identidades de los mensajes de datos que recibe con las identidades del mensaje comprendidas en el valor de conteo de la identidad del mensaje. Si la aplicación en la nube no encuentra todas las identidades del mensaje comprendidas en la identidad del valor de conteo en los mensajes de datos que recibe la aplicación en la nube concluye que algunos mensajes de datos que fueron enviados por el dispositivo operado con baterías no se recibieron por la aplicación en la nube.Si la aplicación en la nube encuentra todas las identidades del mensaje comprendidas en la identidad del valor de conteo en los mensajes de datos que recibe, entonces la integridad de los datos se asegura y es igual a 100 %. Cada identidad de los mensajes de datos enviados por el dispositivo operado con baterías corresponde a un bit en el mensaje de acuse de recibo. Por ejemplo, la codificación del mensaje de enlace descendente de 8 bytes se formatea como un bit por identidad del mensaje. Cada localización en el mensaje de acuse de recibo corresponde a una identidad del

5

10

15

20

25

30

35

40

45

50

55

60

65

mensaje. El mapeo de las identidades del mensaje en el mensaje de acuse de recibo es flexible y puede elegirse arbitrariamente. Por ejemplo, los 64 bits coinciden con la identidad del mensaje de 6 bits de los mensajes unidireccionales. De esta manera, la interpretación del mensaje de acuse de recibo se hace simple para el dispositivo operado con baterías ya que cada bit del mensaje de acuse de recibo corresponde a un mensaje de datos que envía el dispositivo operado con baterías. Por ejemplo, un bit igual a 1 en el mensaje de acuse de recibo indica que los mensajes de datos se han recibido por la aplicación en la nube, y un bit igual a 0 en el mensaje de acuse de recibo indica que los mensajes de datos no se han recibido por la aplicación en la nube.

De acuerdo con una modalidad opcional, la aplicación en la nube comprende además un mensaje de acuse de recibo del receptor del dispositivo adaptado para recibir un mensaje de acuse de recibo del dispositivo generado por el dispositivo operado con baterías que contiene información de acuse de recibo para el mensaje de acuse de recibo.

De esta manera, la aplicación en la nube está al tanto de si el mensaje de acuse de recibo se recibe por el dispositivo operado con baterías. Esto mejora la fiabilidad de la comunicación entre el dispositivo operado con baterías y la aplicación en la nube ya que la aplicación en la nube recibe una confirmación de que el dispositivo operado con baterías está al tanto de los mensajes de datos perdidos. Por ejemplo, el mensaje de acuse de recibo del dispositivo comprende 8 bits con parámetros de configuración. De acuerdo con una modalidad alternativa, un mensaje de datos comprende el mensaje de acuse de recibo del dispositivo que acusa recibo del mensaje de acuse de recibo. La aplicación en la nube está al tanto de la recepción de un primer mensaje de acuse de recibo cuando una segunda solicitud de acuse de recibo desde el dispositivo operado con baterías comprende una identidad del valor de conteo diferente de la identidad del mensaje.

De acuerdo con una modalidad opcional, la aplicación en la nube se adapta adicionalmente para:

- almacenar una primera identidad del valor de conteo de la identidad del mensaje;

- almacenar un primer mensaje de acuse de recibo enviado al dispositivo operado con baterías correspondiente a la primera identidad del valor de conteo de la identidad del mensaje;

- después de recibir una segunda solicitud del dispositivo operado con baterías que comprende una segunda identidad del valor de conteo de la identidad del mensaje, enviar el primer mensaje de acuse de recibo cuando la segunda identidad del valor de conteo de la identidad del mensaje no difiere de la primera identidad del valor de conteo de la identidad del mensaje; y

- después de recibir una segunda solicitud del dispositivo operado con baterías que comprende una segunda identidad del valor de conteo de la identidad del mensaje, extraer las identidades del mensaje de los mensajes de datos recibidos y generar un segundo mensaje de acuse de recibo cuando la segunda identidad del valor de conteo de la identidad del mensaje difiere de la primera identidad del valor de conteo de la identidad del mensaje.

De esta manera, la aplicación en la nube identifica si el dispositivo operado con baterías recibió el mensaje de acuse de recibo. Un dispositivo operado con baterías envía mensajes de datos a la aplicación en la nube. El dispositivo envía luego una solicitud para acusar recibo de la recepción a la aplicación en la nube, en donde la solicitud comprende una primera identidad del valor de conteo de la identidad del mensaje. La aplicación en la nube genera un mensaje de acuse de recibo basado en esta primera identidad del valor de conteo de la identidad del mensaje. El dispositivo operado con baterías espera por el mensaje de acuse de recibo que contiene información indicativa de la recepción de los mensajes de datos. Existe una ventana de tiempo de espera definida por la red durante el cual el mensaje de acuse de recibo puede recibirse por el dispositivo operado con baterías. Si esta expira, el intercambio bidireccional entre el dispositivo operado con baterías y la aplicación en la nube falla: el dispositivo está al tanto de que no recibió el mensaje de acuse de recibo, pero la aplicación en la nube no. El dispositivo operado con baterías intenta luego enviar la misma identidad del contador de mensajes a la aplicación en la nube. La aplicación en la nube recibe de este modo una segunda solicitud de acuse de recibo que contiene la primera identidad del valor de conteo de la identidad del mensaje y de este modo está al tanto de que el primer mensaje de acuse de recibo no se recibió por el dispositivo operado con baterías. La aplicación en la nube genera el mensaje de acuse de recibo correcto correspondiente a los mensajes de datos para los cuales el acuse de recibo de la recepción se solicitó por la primera solicitud de acuse de recibo, es decir para los mensajes de datos correspondientes a la primera identidad del valor de conteo de la identidad del mensaje. Cuando el mensaje de acuse de recibo se recibe correctamente por el dispositivo operado con baterías, la identidad del valor de conteo de la identidad del mensaje de la próxima solicitud de acuse de recibo es entonces diferente de la primera identidad del valor de conteo de la identidad del mensaje recibido por la aplicación en la nube. La aplicación en la nube está entonces al tanto de que el mensaje de acuse de recibo se recibió luego por el dispositivo operado con baterías. La aplicación en la nube conoce luego para cuál de los acuses de recibo de los mensajes de datos recibidos últimamente se solicita y de este modo genera un mensaje de acuse de recibo correcto correspondiente a la nueva identidad del valor de conteo de la identidad del mensaje. De esta manera, los mensajes de datos en el dispositivo operado con baterías y en la aplicación en la nube se mantienen sincronizados.

De acuerdo con un cuarto aspecto de la presente invención, se proporciona un método en la nube de acuerdo con la reivindicación 17.

De acuerdo con la presente invención, la integridad de los datos de los mensajes de datos durante la transmisión de un dispositivo operado con baterías a una aplicación en la nube se garantiza siempre que se desea. De hecho, el dispositivo operado con baterías solicita el acuse de recibo de los mensajes de datos que el dispositivo operado con

5

10

15

20

25

30

35

40

45

50

55

60

65

baterías envía a la aplicación en la nube. Después de recibir la solicitud, la aplicación en la nube envía mensajes de acuse de recibo que contienen información acusando recibo de los mensajes de datos desde el dispositivo operado con baterías. Los mensajes de acuse de recibo generados por la aplicación en la nube se interpretan luego por el dispositivo operado con baterías para identificar los mensajes de datos que se enviaron a la aplicación en la nube pero no se reciben por la aplicación en la nube, por ejemplo debido a una baja cobertura de la red geográfica, la presencia de los puntos ciegos locales, condiciones de baja RF debido a la localización del dispositivo, a la velocidad del dispositivo, etc. De esta manera, el dispositivo operado con baterías está al tanto de los mensajes de datos que no se recibieron por la aplicación en la nube y que necesitan retransmitirse para garantizar la integridad de los datos siempre que el dispositivo operado con baterías lo desee. El dispositivo operado con baterías luego retransmite selectivamente los mensajes de datos cuya recepción no se acusó por la aplicación en la nube. Además, el uso de la batería del dispositivo operado con baterías se optimiza para aumentar su tiempo de vida. De hecho, la generación de los mensajes de acuse de recibo por la aplicación en la nube se activa por la recepción de una solicitud generada por el dispositivo operado con baterías. Para la aplicación para la cual no es obligatorio recibir un mensaje de acuse de recibo para todos los mensajes de datos enviados, el dispositivo operado con baterías no envía una solicitud a la aplicación en la nube para acusar recibo de todos los mensajes de datos. Si el dispositivo operado con baterías decide ahorrar batería, el dispositivo operado con baterías no envía una solicitud. Si el dispositivo operado con baterías decide asegurar la integridad de los datos de su transmisión, el dispositivo operado con baterías decide cuándo enviar una solicitud para acusar recibo a la aplicación en la nube. Esto evita que la aplicación en la nube genere y envíe un mensaje de acuse de recibo al dispositivo operado con baterías en un momento en el tiempo cuando el dispositivo operado con baterías no esté disponible o no se alcance, o cuando la red de bajo rendimiento está ocupada, o cuando la aplicación en donde el dispositivo operado con baterías se usa no requiere la integridad de los datos. De esta manera, la comunicación asegura que un mensaje de acuse de recibo se reciba por el dispositivo operado con baterías cuando el dispositivo operado con baterías está disponible. Esto reduce el gasto de la batería del dispositivo ya que el dispositivo operado con baterías elige el momento en el que escucha un mensaje de acuse de recibo desde la aplicación en la nube. El dispositivo operado con baterías de este modo no necesita permanecer encendido para recibir un mensaje de acuse de recibo. Además, ya que el pico de corriente en un dispositivo de acuerdo con la presente invención es por ejemplo mucho menor que por ejemplo en un teléfono, el diseño de la batería de tal dispositivo puede optimizarse y miniaturizarse, lo que reduce drásticamente los costos asociados a su producción. Además, el dispositivo operado con baterías solamente retransmite los mensajes de datos selectivamente de acuerdo con la información contenida en el mensaje de acuse de recibo, y de este modo no necesita retransmitir todos los mensajes de datos múltiples veces. Esto reduce drásticamente el consumo de energía del dispositivo operado con baterías y aumenta la vida de la batería del dispositivo operado con baterías. Una batería de un dispositivo de acuerdo con la presente invención puede en cambio durar varios años, incluso decenas de años. La flexibilidad se proporciona además a la comunicación entre el dispositivo operado con baterías y la aplicación en la nube, a medida que el dispositivo operado con baterías elige cuándo enviar la solicitud para un mensaje de acuse de recibo. La transmisión de la solicitud puede programarse en el tiempo, o puede planearse en dependencia del número de mensajes de datos que ya se han enviado. La solicitud inicia un procedimiento de transferencia bidireccional entre el dispositivo operado con baterías y la aplicación en la nube. La aplicación en la nube puede recoger estadísticas sobre el número de retransmisiones, en el número de mensajes total transmitidos por el dispositivo operado con baterías, etc.

Breve descripción de las figuras

La Figura 1 ilustra esquemáticamente una modalidad de un dispositivo operado con baterías y una aplicación en la nube para acusar recibo de la transmisión de los mensajes de datos sobre una red de bajo rendimiento.

La Figura 2 ilustra esquemáticamente una modalidad de un dispositivo operado con baterías y una aplicación en la nube para acusar recibo de la transmisión de cinco mensajes de datos por una red de bajo rendimiento, donde un mensaje de datos no se recibe por la aplicación en la nube.

La Figura 3 ilustra esquemáticamente una modalidad de un dispositivo operado con baterías y una aplicación en la nube donde el dispositivo operado con baterías envía una solicitud de configuración para una actualización de la configuración a la aplicación en la nube.

La Figura 4 ilustra esquemáticamente un sistema informático adecuado para alojar el dispositivo operado con baterías o la aplicación en la nube de la Figura 1.

Descripción detallada de la(s) modalidad(es)

De acuerdo con una modalidad mostrada en la Figura 1, un dispositivo operado con baterías 1 transmite una pluralidad de mensajes de datos 100 a una aplicación en la nube 2 por una red de bajo rendimiento 3. El dispositivo operado con baterías 1 comprende una interfaz de red de bajo rendimiento 10, un receptor de acuse de recibo 11, una solicitud de receptor de acuse de recibo 12, un generador de la identidad del mensaje 13, una máquina de extracción de la identidad del mensaje 14, una caché del dispositivo 15 y un generador de mensaje de acuse de recibo del dispositivo 16. La aplicación en la nube 2 comprende una interfaz de red de bajo rendimiento 20, un generador de acuse de recibo 21, un receptor de acuse de recibo 22, un extractor de la identidad del mensaje 23, un intérprete de la solicitud 24 y un receptor del mensaje de acuse de recibo del dispositivo 25. Los mensajes de datos 100 pueden por ejemplo almacenarse en la caché del dispositivo 15 del dispositivo operado con baterías 1. La interfaz de red de bajo rendimiento 10 se adapta para

5

10

15

20

25

30

35

40

45

50

55

60

65

recuperar los mensajes de datos 100 de la caché del dispositivo 15. Alternativamente, los mensajes de datos 100 pueden generarse por el dispositivo operado con baterías 1. Como se describió en la Figura 1, la interfaz de red de bajo rendimiento 10 se adapta para enviar dos mensajes de datos 100 a la aplicación en la nube 2 por la red de bajo rendimiento 3. De acuerdo con una modalidad alternativa, el dispositivo operado con baterías 1 transmite un mensaje de datos 100 a la aplicación en la nube 2. De acuerdo con una modalidad alternativa, el dispositivo operado con baterías 1 transmite decenas o cientos de mensajes de datos 100 a la aplicación en la nube 2. El generador de la identidad del mensaje 13 genera una única identidad del mensaje 102 para cada mensaje de datos 100. La interfaz de red de bajo rendimiento 20 de la aplicación en la nube 2 recibe los mensajes de datos 100. El generador de solicitud de acuse de recibo 11 del dispositivo operado con baterías 1 además genera y envía una solicitud 101 a la aplicación en la nube 2 para un mensaje de acuse de recibo desde la aplicación en la nube 2. Alternativamente, la solicitud 101 está comprendida en un mensaje de datos 100. De acuerdo con una modalidad alternativa adicional, la solicitud 101 es uno de los mensajes de datos 100. La solicitud 101 se interpreta por el intérprete de la solicitud 24 de la aplicación en la nube 2 de manera que la aplicación en la nube aprende para cuáles mensajes de datos 100 se solicita el acuse de recibo. El extractor de la identidad del mensaje 23 extrae las identidades del mensaje 102 de cada mensaje de datos recibido 100. Después de recibir la solicitud 101 por el receptor de solicitud de acuse de recibo 22, el generador de acuse de recibo 21 de la aplicación en la nube 2 genera un mensaje de acuse de recibo 200 y lo envía al dispositivo operado con baterías 1. De acuerdo con las modalidades alternativas, la aplicación en la nube 2 genera una pluralidad de mensajes de acuse de recibo 200. El mensaje de acuse de recibo 200 contiene información indicativa de la recepción de los mensajes de datos 100. El mensaje de acuse de recibo 200 se recibe por el receptor de acuse de recibo 11 del dispositivo operado con baterías 1. La máquina de extracción de la identidad del mensaje 14 interpreta el mensaje de acuse de recibo 200 extrayendo las identidades del mensaje 102 de los mensajes de datos 100 desde el mensaje de acuse de recibo 200. La máquina de extracción de la identidad del mensaje 14 identifica las identidades del mensaje 102 de los mensajes de datos 100 que no se recibieron por la aplicación en la nube 2 y que de este modo están contenidos en la información del mensaje de acuse de recibo 200. Alternativamente, la máquina de extracción de la identidad del mensaje 14 identifica las identidades del mensaje 102 de los mensajes de datos 100 perdidos de los mensajes de acuse de recibo 200 e interpreta que los mensajes de datos correspondientes 100 no se recibieron por la aplicación en la nube 2. Después de recibir el mensaje de acuse de recibo 200, el generador de acuse de recibo 16 del dispositivo operado con baterías 1 genera automáticamente un mensaje de acuse de recibo del dispositivo 104 que acusa recibo del mensaje de acuse de recibo y envía el mensaje de acuse de recibo del dispositivo 104 a la aplicación en la nube 2. El mensaje de acuse de recibo del receptor del dispositivo 25 recibe e interpreta el mensaje de acuse de recibo del dispositivo 104. La solicitud 101 y el mensaje de acuse de recibo 200 se envían por la red de bajo rendimiento 3.

De acuerdo con una modalidad mostrada en la Figura 2, un dispositivo operado con baterías 1 envía los mensajes de datos caracterizados por una identidad del mensaje 102. Una línea de tiempo 4 descrita en la Figura 2 indica la cronología de los eventos de la Figura 2. A cada mensaje de datos se le asocia una identidad del mensaje 102. Como se describió en la Figura 2, el primer mensaje de datos tiene la identidad del mensaje 102 etiquetado ID=1, el segundo mensaje de datos tiene la identidad del mensaje 102 etiquetado ID=2, etc. hasta el quinto mensaje de datos que tiene la identidad del mensaje 102 etiquetado ID=5. El dispositivo operado con baterías 1 transmite estos cinco mensajes de datos a la aplicación en la nube 2 por la red de bajo rendimiento 3. El dispositivo operado con baterías 1 genera y envía una solicitud 101 etiquetada ID=1 a la aplicación en la nube 2 para recibir el acuse de recibo de los mensajes de datos de la aplicación en la nube 2. La solicitud 101 etiquetada ID=1 comprende una identidad del valor de conteo de la identidad del mensaje 103 que comprende las identidades del mensaje 102 de los mensajes de datos 100 enviados por el dispositivo operado con baterías 1. Alternativamente, la solicitud 101 etiquetada iD=1 está comprendida en un mensaje de datos 100. De acuerdo con una modalidad alternativa, la solicitud 101 etiquetada ID=1 es un mensaje de datos 100. Después de recibir la solicitud 101, la aplicación en la nube 2 genera un mensaje de acuse de recibo 200. De acuerdo con una modalidad alternativa, la aplicación en la nube 2 genera más de un mensaje de acuse de recibo 200. La aplicación en la nube 2 recibe los mensajes de datos y extrae las identidades de los mensajes de datos que recibe. Como se describió en la Figura 2, la aplicación en la nube 2 identifica las identidades del mensaje 102 etiquetadas ID=1 a ID=5, excepto la identidad del mensaje 102 etiquetada ID=4. Esto indica que los mensajes de datos correspondientes a la identidad del mensaje 102 etiquetada ID=4 no se recibe por la aplicación en la nube 2. El mensaje de acuse de recibo 200 comprende las identidades del mensaje 102 de los mensajes de datos que se recibieron por la aplicación en la nube 2. Como se describió en la Figura 2, el mensaje de acuse de recibo 200 comprende las identidades del mensaje etiquetadas ID=1,2,3,5. De acuerdo con una modalidad alternativa, el mensaje de acuse de recibo 200 comprende las identidades del mensaje 102 de los mensajes de datos que no se recibieron por la aplicación en la nube 2, es decir la identidad del mensaje 102 etiquetada ID=4. El dispositivo operado con baterías 1 recibe el mensaje de acuse de recibo 200 e interpreta el mensaje de acuse de recibo 200. En otras palabras, el dispositivo operado con baterías 1 extrae las identidades del mensaje 102 del uno o más mensajes de datos que se enviaron pero que no se recibieron por la aplicación en la nube 1. Cuando la aplicación en la nube 2 acusa recibo de todos los mensajes de datos que se enviaron por el dispositivo operado con baterías 1, la integridad de los datos de la comunicación entre el dispositivo operado con baterías 1 y la aplicación en la nube 2 es igual a 100 %. El dispositivo operado con baterías 1 pone en cola el uno o más mensajes de datos correspondientes a las identidades perdidas del mensaje 102 para su retransmisión. El dispositivo operado con baterías 1 retransmite luego tres mensajes de datos correspondientes a las identidades del mensaje 102 etiquetadas ID=1,2,4. El dispositivo operado con baterías 1 genera y envía una solicitud 101 etiquetada ID=2 a la aplicación en la nube 2 para recibir el acuse de recibo de los mensajes de datos de la aplicación en la nube 2. La solicitud 101 etiquetada ID=2 comprende una identidad del valor de conteo de la identidad del mensaje 103 que

5

10

15

20

25

30

35

40

45

50

55

60

65

comprende las identidades del mensaje 102 de los mensajes de datos 100 que se retransmitieron por el dispositivo operado con baterías 1. Alternativamente, la solicitud 101 etiquetada ID=2 está comprendida en un mensaje de datos 100. De acuerdo con una modalidad alternativa, la solicitud 101 etiquetada ID=2 es un mensaje de datos 100. Después de recibir la solicitud 101, la aplicación en la nube 2 genera un mensaje de acuse de recibo 200 que contiene las identidades del mensaje 102 de los mensajes de datos correspondientes que se recibieron por la aplicación en la nube 2, es decir las identidades del mensaje 102 etiquetadas ID=1,2,4.

De acuerdo con una modalidad mostrada en la Figura 3, un dispositivo operado con baterías 1 envía una solicitud de configuración 105 a la aplicación en la nube 2 para preguntar a la aplicación en la nube 2 si está disponible una actualización de la configuración. La línea de tiempo 4 descrita en la Figura 3 indica la cronología de los eventos de la Figura 3. La aplicación en la nube 2 genera un mensaje de configuración 106 y envía el mensaje de configuración 106 al dispositivo operado con baterías 1. El mensaje de configuración 106 comprende un parámetro de configuración, tal como por ejemplo DATA=0x48 que corresponde a la actualización de la configuración para el dispositivo operado con baterías 1. El mensaje de configuración 106 comprende además una única identidad del parámetro de configuración, que se describe en la Figura 3 como CFG ID=3. Después de recibir el mensaje de configuración 106, el dispositivo 1 extrae la identidad del parámetro de configuración y acepta el mensaje de configuración 106 si la identidad del parámetro de configuración es correcta. El dispositivo operado con baterías 1 genera luego un mensaje de datos, etiquetado con una identidad del mensaje ID=1 como se describió en la Figura 3 y genera además un mensaje de configuración de acuse de recibo 107 de recepción del mensaje de configuración 106. El mensaje de configuración de acuse de recibo 107 comprende la identidad del parámetro de configuración etiquetada ID=3. El dispositivo operado con baterías 1 envía el mensaje de datos correspondiente a la identidad del mensaje 102 y el mensaje de configuración de acuse de recibo 107 a la aplicación en la nube 2. Después de una cantidad dada de tiempo o después de enviar un número dado de mensajes de datos a la aplicación en la nube 2, el dispositivo operado con baterías 1 envía una solicitud 101 a la aplicación en la nube 2 para los mensajes de acuse de recibo 200. La solicitud 101 comprende una identidad del valor de conteo de la identidad del mensaje 103. Después de recibir la solicitud 101, la aplicación en la nube 2 genera un mensaje de acuse de recibo 200 acusando recibo de la recepción de los mensajes de datos correspondientes a la identidad del mensaje 102 etiquetada ID=1.

La Figura 4 muestra un sistema informático adecuado 800 para alojar el dispositivo operado con baterías 1 o la aplicación en la nube 2 de la Figura 1. El sistema informático 800 puede en general formarse como un ordenador de propósito general adecuado y puede comprender un bus 510, un procesador 502, una memoria local 504, una o más interfaces de entrada opcionales 514, una o más interfaces de salida opcionales 516 una interfaz de comunicación 512, una interfaz del elemento de almacenamiento 506 y uno o más elementos de almacenamiento 508. El bus 510 puede comprender uno o más conductores que permitan la comunicación entre los componentes del sistema informático. El procesador 502 puede incluir cualquier tipo de procesador o microprocesador convencionales que interpretan y ejecutan las instrucciones de programación. La memoria local 504 puede incluir una memoria de acceso aleatorio (RAM) u otro tipo de dispositivo de almacenamiento dinámico que almacena información e instrucciones para ejecutar por un procesador 502 y/o una memoria de solo lectura (ROM) u otro tipo de almacenamiento estático que almacena información estática e instrucciones para su uso por el procesador 504. La interfaz de entrada 514 puede comprender uno o más mecanismos convencionales que permiten que un operador introduzca información al dispositivo informático 800, tal como un teclado 520, un ratón 530, una pluma, reconocimiento de voz y/o mecanismos biométricos, etc. La interfaz de salida 516 puede comprender uno o más mecanismos convencionales que emiten información al operador, tal como una pantalla 540, una impresora 550, una bocina, etc. La interfaz de comunicación 512 puede comprender cualquier mecanismo similar a un transceptortal como por ejemplo dos interfaces Ethernet de 1 Gb que permiten que el sistema informático 800 se comunique con otros dispositivos y/o sistemas, por ejemplo mecanismos para comunicarse con uno o más de otros sistema informáticos 900. La interfaz de comunicación 512 del sistema informático 800 puede conectarse a dicho otro sistema informático por medio de una red de área local (LAN) o una red de área amplia (WAN, tal como por ejemplo Internet), en cuyo caso el otro sistema informático 580 puede comprender por ejemplo un servidor web adecuado. La interfaz del elemento de almacenamiento 506 puede comprender una interfaz de almacenamiento tal como por ejemplo una interfaz tipo SATA (Serial Advanced Technology Attachment) o una interfaz tipo SCSI (Small Computer System Interface) para conectar el bus 510 a uno o más elementos de almacenamiento 508, tal como uno o más discos locales, por ejemplo un disco SATA de 1 TB SATA acciona, y controla la lectura y escritura de los datos hacia y/o desde estos elementos de almacenamiento 508. Aunque los elementos de almacenamiento 508 anteriores se describen como un disco local, en general pudiera usarse cualquier otro medio legible por ordenador adecuado tal como un disco magnético extraíble, medios de almacenamiento óptico tales como un CD o DVD, disco -ROM, controladores de estado sólido, tarjetas de memoria flash, ....

El dispositivo operado con baterías 1 o la aplicación en la nube 2 de la Figura 1 pueden implementarse como instrucciones de programación almacenadas en la memoria local 504 del sistema informático 800 para su ejecución por el procesador 502. Alternativamente el dispositivo operado con baterías 1 o la aplicación en la nube 2 de la Figura 1 pudiera almacenarse en el elemento de almacenamiento 508 o accederse desde otro sistema informático 900 a través de la interfaz de comunicación 512.

Aunque la presente invención se ha ilustrado como referencia a las modalidades específicas, será evidente para los expertos en la técnica que la invención no se limita a los detalles de las modalidades ilustrativas anteriores, y que la presente invención se puede incorporar con varios cambios y modificaciones sin alejarse del alcance de las

reivindicaciones. Las presentes modalidades deben considerarse de este modo en todos los aspectos como ilustrativas y no como restricción, siendo el alcance de la invención indicado por las reivindicaciones adjuntas y no por la descripción. Se deberá entender además por el lector de esta solicitud de patente que las palabras "que comprende" o "comprende" no excluyen otros elementos o etapas, que las palabras "uno" o "una" no excluyen una pluralidad, y que un 5 solo elemento, tal como un sistema de computadora, un procesador, u otra unidad integrada puede cumplir con las funciones de varios medios enumerados en las reivindicaciones. Cualquier signo de referencia en las reivindicaciones no se deberá interpretar como limitante de las reivindicaciones respectivas interesadas. Los términos "primero", "segundo", "tercero", "a", "b", "c", y similares, cuando se usan en la descripción o en las reivindicaciones se introducen para distinguir entre elementos o etapas similares y no necesariamente describen un orden secuencial o cronológico. De 10 forma similar, los términos "superior", "inferior", "sobre", "bajo", y similares se introducen por propósitos descriptivos y no necesariamente para denotar posiciones relativas. Se debe entender que los términos usados así son intercambiables bajo circunstancias adecuadas y las modalidades de la invención son capaces de operar de acuerdo con la presente invención en otras secuencias, o en orientaciones diferentes de la(s) descrita(s) o ilustrada(s) anteriormente.

15

Claims (17)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   55

   60

   65

   Reivindicaciones

   1. Un dispositivo operado con baterías (1) para transmitir mensajes de datos (100), dicho dispositivo (1) comprende:

   - una interfaz de red de bajo rendimiento (10), adaptada para enviar dichos mensajes de datos (100) a una aplicación en la nube (2) por una conexión de bajo rendimiento (3);

   - un receptor de acuse de recibo (11), adaptado para:

   - recibir por dicha conexión de bajo rendimiento (3) un mensaje de acuse de recibo (200) generado por dicha aplicación en la nube (2) y que contiene información de acuse de recibo para uno o más de dichos mensajes de datos (100); y

   - interpretar dicho mensaje de acuse de recibo (200);

   caracterizado porque dicho dispositivo operado con baterías (1) comprende además un generador de solicitud de acuse de recibo (12) adaptado para generar y enviar una solicitud (101) sobre dicha conexión de bajo rendimiento (3) a dicha aplicación en la nube (2) para dicho mensaje de acuse de recibo (200).
2. 2. Un dispositivo operado con baterías (1) de acuerdo con la reivindicación 1, en donde dicho receptor de acuse de recibo (11) se adapta adicionalmente para recibir e interpretar un único mensaje de acuse de recibo (200) que contiene información de acuse de recibo para una pluralidad de dichos mensajes de datos (100).
3. 3. Un dispositivo operado con baterías (1) de acuerdo con la reivindicación 1, en donde uno de dichos mensajes de datos (100) comprende dicha solicitud (101).
4. 4. Un dispositivo operado con baterías (1) de acuerdo con la reivindicación 1, en donde dicha solicitud (101) es uno de dichos mensajes de datos (100).
5. 5. Un dispositivo operado con baterías (1) de acuerdo con la reivindicación 1, en donde dicho comprende además:

   - un generador de la identidad del mensaje (13), adaptado para generar una identidad del para cada mensaje de datos (100);

   y en donde:

   - dicha identidad del mensaje (102) es un valor numérico.
6. 6. Un dispositivo operado con baterías (1) de acuerdo con la reivindicación 5, en donde:

   - dicha solicitud (101) comprende una identidad del valor de conteo de la identidad del mensaje (103) indicativa para dichas identidades del mensaje (102) de dichos mensajes de datos (100) enviados por dicho dispositivo operado con baterías (1); y

   - dicho generador de solicitudes de acuse de recibo (12) se adapta para generar un mensaje de acuse de recibo (200) cuya longitud en bits corresponde a la identidad máxima del valor de conteo de la identidad del mensaje (103).
7. 7. Un dispositivo operado con baterías (1) de acuerdo con la reivindicación 6, en donde dicho dispositivo comprende además:

   - una máquina de extracción de la identidad del mensaje recibido (14), adaptada para extraer las identidades del mensaje (102) de dicho mensaje de acuse de recibo (200) y para identificar las identidades del mensaje (102) de dichos mensajes de datos (100) que faltan en dicho mensaje de acuse de recibo (200); y

   en donde dicho dispositivo operado con baterías (1) se adapta adicionalmente para reenviar un mensaje de datos cuya identidad del mensaje no está en dicho mensaje de acuse de recibo (200).
8. 8. Un dispositivo operado con baterías (1) de acuerdo con la reivindicación 1, en donde dicho dispositivo (1) comprende además una caché del dispositivo (15) adaptada para almacenar dichos mensajes de datos (100), y en donde dicho dispositivo (1) se adapta adicionalmente para borrar los mensajes de datos para los cuales se ha recibido el acuse de recibo.
9. 9. Un dispositivo operado con baterías (1) de acuerdo con la reivindicación 1, en donde dicho dispositivo (1) comprende además:

   - un generador de mensaje de acuse de recibo del dispositivo (16), adaptado para generar automáticamente un mensaje de acuse de recibo del dispositivo (104) acusando recibo de dicho mensaje de acuse de recibo (200) y para enviar dicho mensaje de acuse de recibo del dispositivo (104) a dicha aplicación en la nube (2).
10. 10. Un dispositivo operado con baterías (1) de acuerdo con la reivindicación 1, en donde:

    - dicho dispositivo operado con baterías (1) se adapta adicionalmente para generar una solicitud de configuración (105) a dicha aplicación en la nube (2);

    - dicha aplicación en la nube (2) se adapta adicionalmente para generar un mensaje de configuración (106) que contiene información indicativa para los parámetros de configuración y para enviar dicho mensaje de configuración (106) a dicho dispositivo operado con baterías (1);

    dispositivo (1) mensaje (102)

    5

    10

    15

    20

    25

    30

    35

    40

    45

    50

    55

    60

    65

    - dicho dispositivo operado con baterías (1) se adapta adicionalmente para generar un mensaje de configuración de acuse de recibo (107) que contiene información de acuse de recibo para dicho mensaje de configuración (106).
11. 11. Un método para transmitir mensajes de datos (100) desde un dispositivo operado con baterías (1), dicho método comprende las etapas de:

    - enviar dichos mensajes de datos (100) a una aplicación en la nube (2) por una conexión de bajo rendimiento (3) a través de una interfaz de red de bajo rendimiento;

    caracterizado porque:

    - genera en el dispositivo operado con baterías (1) una solicitud (101) para un mensaje de acuse de recibo (200) indicativo de la recepción de uno o más de dichos mensajes de datos (100);

    - envía dicha solicitud (101) para dicho mensaje de acuse de recibo (200) a dicha aplicación en la nube (2) por dicha conexión de bajo rendimiento (3); y

    - recibe dicho mensaje de acuse de recibo (200) por dicha conexión de bajo rendimiento (3) en el dispositivo operado con baterías (1) e interpretar la información de acuse de recibo contenida en el mismo.
12. 12. Un sistema informático para alojar una aplicación en la nube (2) para recibir mensajes de datos (100) enviados por un dispositivo operado con baterías (1) por una conexión de bajo rendimiento (3), dicha aplicación en la nube (2) comprende:

    - una interfaz de red de bajo rendimiento (20), adaptada para recibir dichos mensajes de datos (100) desde el dispositivo operado con baterías (1) por la conexión de bajo rendimiento (3);

    - un generador de acuse de recibo (21), adaptado para generar y enviar al dispositivo operado con baterías (1) un mensaje de acuse de recibo (200) que contiene información de acuse de recibo para uno o más de dichos mensajes de datos (100) por dicha red de bajo rendimiento (3);

    caracterizado porque dicha aplicación en la nube (2) comprende además una solicitud de receptor de acuse de recibo (22) adaptado para recibir una solicitud (101) por dicha red de bajo rendimiento (3) desde el dispositivo operado con baterías para dicho mensaje de acuse de recibo (100) y en donde dicho generador de acuse de recibo (21) se adapta adicionalmente para generar dicho mensaje de acuse de recibo (200) solamente después de recibir dicha solicitud (101).
13. 13. Una aplicación en la nube (2) de acuerdo con la reivindicación 12, en donde dicho generador de acuse de recibo (21) se adapta adicionalmente para generar un único mensaje de acuse de recibo (200) que contiene información de acuse de recibo para una pluralidad de dichos mensajes de datos (100).
14. 14. Una aplicación en la nube (2) de acuerdo con la reivindicación 12, en donde dicha aplicación en la nube (2) comprende:

    - una extractor de la identidad del mensaje (23) adaptado para extraer una identidad del mensaje (102) de cada mensaje de datos recibido (100);

    - un intérprete de la solicitud (24) adaptado para interpretar dicha solicitud (101) y aprender para cuáles mensajes de datos (100) se solicita el acuse de recibo;

    y en donde dicho generador de acuse de recibo (21) se adapta adicionalmente para generar un mensaje de acuse de recibo (200) para los mensajes de datos recibidos.
15. 15. Una aplicación en la nube (2) de acuerdo con la reivindicación 12, en donde dicha aplicación en la nube (2) comprende además un mensaje de acuse de recibo del receptor del dispositivo (25) adaptado para recibir un mensaje de acuse de recibo del dispositivo (104) generado por dicho dispositivo operado con baterías (1) que contiene información de acuse de recibo para dicho mensaje de acuse de recibo (200).
16. 16. Una aplicación en la nube (2) de acuerdo con las reivindicaciones 15, en donde dicha aplicación en la nube (2) se adapta adicionalmente para:

    - almacenar una primera identidad del valor de conteo de la identidad del mensaje (103);

    - almacenar un primer mensaje de acuse de recibo (200) enviado a dicho dispositivo operado con baterías (1) correspondiente a dicha primera identidad del valor de conteo de la identidad del mensaje (103);

    - después de recibir una segunda solicitud (101) de dicho dispositivo operado con baterías (1) que comprende una segunda identidad del valor de conteo de la identidad del mensaje (103), enviar de regreso dicho primer mensaje de acuse de recibo (200) cuando dicha segunda identidad del valor de conteo de la identidad del mensaje (103) no difiere de dicha primera identidad del valor de conteo de la identidad del mensaje (103); y

    - después de recibir una segunda solicitud (101) de dicho dispositivo operado con baterías (1) que comprende una segunda identidad del valor de conteo de la identidad del mensaje (103), extraer dichas identidades del mensaje (102) de dichos mensajes de datos (100) recibidos y generar un segundo mensaje de acuse de recibo (200) cuando dicha segunda identidad del valor de conteo de la identidad del mensaje (103) difiere de dicha primera identidad del valor de conteo de la identidad del mensaje (103).
17. 17. Un método en la nube para recibir mensajes de datos (100), dicho método comprende las etapas de:

    10

    recibir dichos mensajes de datos (100) enviados por un dispositivo operado con baterías (1) por una conexión de bajo rendimiento (3) en una aplicación en la nube (2) a través de una interfaz de red de bajo rendimiento;

    caracterizado porque dicho método en la nube comprende además las etapas de:

    recibir una solicitud (101) por dicha conexión de bajo rendimiento (3) desde el dispositivo operado con baterías (1) en la aplicación en la nube (2) para un mensaje de acuse de recibo (200) que contiene información de acuse de recibo para uno o más de dichos mensajes de datos (100); generar dicho mensaje de acuse de recibo (200) en la aplicación en la nube; y

    enviar dicho mensaje de acuse de recibo (200) por dicha conexión de bajo rendimiento (3) al dispositivo operado con baterías (1).