ES2784239T3 - Difusión de avisos a una pluralidad de diversos dispositivos de comunicaciones - Google Patents

Difusión de avisos a una pluralidad de diversos dispositivos de comunicaciones Download PDF

Info

Publication number
ES2784239T3
ES2784239T3 ES08857249T ES08857249T ES2784239T3 ES 2784239 T3 ES2784239 T3 ES 2784239T3 ES 08857249 T ES08857249 T ES 08857249T ES 08857249 T ES08857249 T ES 08857249T ES 2784239 T3 ES2784239 T3 ES 2784239T3
Authority
ES
Spain
Prior art keywords
message
devices
agent
recipients
content
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES08857249T
Other languages
English (en)
Inventor
Suhayya Abu-Hakima
Kenneth E Grigg
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from PCT/CA2007/002197 external-priority patent/WO2009070861A1/en
Priority claimed from US11/951,572 external-priority patent/US8051057B2/en
Application filed filed Critical
Application granted granted Critical
Publication of ES2784239T3 publication Critical patent/ES2784239T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1895—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for short real-time information, e.g. alarms, notifications, alerts, updates
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/004—Alarm propagated along alternative communication path or using alternative communication medium according to a hierarchy of available ways to communicate, e.g. if Wi-Fi not available use GSM
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/005—Alarm destination chosen according to a hierarchy of available destinations, e.g. if hospital does not answer send to police station
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B27/00—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
    • G08B27/005—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations with transmission via computer network
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B27/00—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
    • G08B27/006—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations with transmission via telephone network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/53—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
    • H04H20/59—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for emergency or urgency
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services

Abstract

Un sistema (710) para comunicar un mensaje de aviso a una pluralidad de destinatarios, estando asociado cada destinatario con un dispositivo de comunicaciones (790) respectivo, siendo cada dispositivo uno respectivo de una pluralidad de tipos de dispositivos, teniendo cada dispositivo una dirección respectiva, comprendiendo el sistema: un módulo de despacho (720) para recibir el mensaje de aviso, los datos del abonado del mensaje y los criterios de identificación del dispositivo, identificando los datos del abonado del mensaje recibidos de una base de datos (740) a los destinatarios registrados y las direcciones de sus dispositivos de comunicaciones asociados, en donde el módulo de despacho (720) es para compilar una lista de los destinatarios basada en parte en los datos del abonado del mensaje, y en donde el módulo de despacho (720) es para comunicarse con un nodo de comunicaciones (770) accesible al sistema para consultar o sondear dicho nodo de comunicaciones (770) y, en respuesta a ello, recibir directamente del nodo de comunicaciones (770) una identificación de los dispositivos de comunicaciones (790) actualmente accesibles a través de ese nodo de comunicaciones (770) en base a los criterios de identificación del dispositivo, en donde los criterios de identificación del dispositivo especifican una proximidad lógica o física del dispositivo al nodo de comunicaciones (770) o a una ubicación especificada, en la que el módulo de despacho (720) es además para compilar la lista de los destinatarios basada en parte en la identificación recibida del nodo de comunicaciones (770), en donde el nodo de comunicaciones (770) es un punto de acceso a la red que es cableado o inalámbrico, y la identificación recibida del nodo de comunicación incluye una dirección de, al menos, un dispositivo de comunicaciones (790) de un destinatario no registrado; un módulo de entrega (730) para recibir desde el módulo de despacho (720) el mensaje y la lista de destinatarios que comprende destinatarios registrados y, al menos, un destinatario no registrado, siendo, además, el módulo de entrega (730) para recibir las direcciones de dispositivo basadas en la lista de los destinatarios, siendo, además, el módulo de entrega (730) para comunicar el mensaje a los dispositivos especificados por la lista de destinatarios que comprende destinatarios registrados y, al menos, un destinatario no registrado, teniendo el módulo de entrega (730), para cada dispositivo, un submódulo de entrega correspondiente para comunicar el mensaje a los dispositivos de ese tipo de dispositivo; y la base de datos (740) para recibir y almacenar el mensaje, comprendiendo la lista de los destinatarios los destinatarios registrados y, al menos, un destinatario no registrado, incluyendo los tipos de dispositivo y las direcciones del dispositivo, los datos de abonado del mensaje que comprenden identificadores de los destinatarios registrados y sus direcciones de dispositivo asociadas y tipos de dispositivos.

Description

DESCRIPCIÓN
Difusión de avisos a una pluralidad de diversos dispositivos de comunicaciones
Antecedentes de la invención
Campo de la invención
La invención hace referencia, en general, a sistemas de comunicación y, más concretamente, a sistemas para proporcionar una difusión de avisos.
Descripción de la técnica relacionada
Es cada vez más importante y deseable que las autoridades sociales, gobiernos, universidades, hospitales, la policía y empresas de seguridad en grandes edificios de oficinas puedan notificar a las personas en la zona bajo su control un peligro específico e inesperado. Por ejemplo, si hay un tiroteo en la escuela, una toma de rehenes, un incendio, un derrame químico peligroso, una fuga de gas, un aviso Ámbar por un niño desaparecido o cualquier otro evento donde el peligro esté relacionado con la proximidad de una persona. Es crucial que las autoridades se puedan comunicar como sea con personas en la zona, para advertirles, darles instrucciones sobre la mejor manera de evitar el peligro y cómo evitar causar una desviación de los recursos de las autoridades enredándose en el peligro inicial o creando un nuevo peligro.
Desgraciadamente, los sistemas conocidos, tales como las difusiones públicas por radio o televisión, están dirigidos, habitualmente, a un conjunto fijo y limitado de dispositivos de comunicación y, por lo tanto, no tienen en cuenta la realidad moderna de que las personas utilizan una variedad de dispositivos de comunicación diferentes de acuerdo con el contexto. Por ejemplo, en el caso de un tiroteo escolar en una universidad, la policía o el servicio de seguridad de la universidad pueden emitir una advertencia a través de las estaciones de radio o televisión de la universidad; sin embargo, un estudiante que estudie en un rincón tranquilo de una sala del sótano de una biblioteca del campus podría no recibir esta advertencia, y es posible que la seguridad del campus o los transeúntes no lo noten. A menos que el estudiante se encuentre fortuitamente con otra persona que haya escuchado la advertencia, podría permanecer ajeno a un peligro que está peligrosamente cerca. Aunque el estudiante podría poseer algún otro medio de comunicación (por ejemplo, un teléfono celular o un ordenador portátil, conectado a la red de la escuela a través de WiFi), la disponibilidad de dicho medio tiene poco valor si las autoridades no están equipadas para transmitir avisos a través de dichos medios de comunicación, de manera eficiente y fiable.
El documento US 2006/273893 A1 da a conocer un sistema de aviso basado en la localidad para distribuir información de emergencia a los usuarios suscritos para recibir dicha información. El documento US 2002/129354 A1 da a conocer un sistema para detectar eventos y distribuir avisos informativos a sus usuarios, en respuesta a los eventos detectados de acuerdo con lo determinado en base a las definiciones de eventos y a la información de contacto y programación establecida por los usuarios del sistema. El documento DE 10032055 A1 da a conocer un sistema de avisos que emite un mensaje de aviso en respuesta a una situación de emergencia para su transmisión a un cierto número de respondedores, registra sus acuses de recibo y retransmite el mensaje tantas veces como el número de los acuses de recibo que recibe en un periodo que está por debajo de un mínimo preestablecido.
Por lo tanto, existe la necesidad de una solución que proporcione la difusión de avisos a una pluralidad de diversos dispositivos de comunicación, ya sean móviles o estacionarios, a través de una pluralidad de diversos medios de comunicación. Incluiría un medio para identificar a los destinatarios apropiados con respecto a cada tipo de dispositivo de comunicaciones, tal como, por ejemplo, mediante la selección de una lista o mediante la determinación de la presencia de cada destinatario en una zona concreta. La solución debe ser configurada para utilizar al máximo las capacidades de cualquier tipo de dispositivo, pero también debe tener en cuenta las limitaciones que presenta cualquier otro tipo de dispositivo y, específicamente, debe ser capaz de transmitir imágenes o documentos cuando estén disponibles. Asimismo, sería deseable que dicha solución pudiera confirmar la recepción del aviso, permitir una respuesta del destinatario a la fuente de difusión para proporcionar inteligencia situacional y permitir una interlocución bidireccional entre la fuente de transmisión y los destinatarios para ayuda a dirigirlos a través de la emergencia. Además, no debe permitir una nueva vía para que “spam” u otra información no solicitada o no deseada llegue al usuario.
Asimismo, dicha solución sería útil para situaciones orientadas a la comunidad, que no sean de emergencia, tales como avisos de anuncios públicos en las escuelas, de la policía sobre situaciones de tráfico, etc.
Breve compendio de la invención
La invención dada a conocer en el presente documento incluye un sistema que permite a una autoridad que utiliza el sistema, tal como un gobierno municipal, una universidad, un hospital, la policía o una empresa de seguridad, difundir un aviso a una pluralidad de usuarios que utilizan una diversidad de dispositivos de comunicación, a través de diversos medios de comunicación, para confirmar la recepción del aviso y para garantizar que no se crea una vía de comunicación adicional para spam u otra comunicación no deseada. El sistema es adaptable para transmitir un aviso a cualquier tecnología de comunicaciones deseada capaz de recibir y mostrar mensajes, tales como dispositivos fijos o móviles con conexión IP (por ejemplo, ordenadores móviles o estacionarios, dispositivos portátiles, teléfonos inteligentes, etc.), dispositivos con capacidad de SMS / MMS, dispositivos con capacidad de correo electrónico, dispositivos con capacidad de voz (teléfonos, radios, etc.) o dispositivos con capacidad de imagen (por ejemplo, televisores, monitores, pizarras inteligentes, etc.). Dichos mensajes de aviso pueden incluir texto, imágenes, video, voz o cualquier otro método de comunicaciones.
La invención permite una transmisión eficiente de mensajes a un gran número de dispositivos destinatarios, tanto móviles como estacionarios. Los destinatarios pueden ser seleccionados por su presencia en una lista dentro de una base de datos, dentro de un directorio, dentro de un conjunto de dispositivos asociados con un controlador de red inalámbrica o un punto de acceso, o dentro de un conjunto de dispositivos que se encuentran situados dentro de una región geográfica. Los mensajes de difusión pueden ser priorizados para indicar un orden de entrega preferencial. La recepción de la difusión puede ser confirmada de manera explícita por el destinatario (por ejemplo, mediante una señal de DTMF, mediante una respuesta de SMS / MMS o mediante una respuesta de correo electrónico), o, de manera implícita, ser confirmada por el cliente de la difusión.
La invención proporciona un sistema de acuerdo con la reivindicación 1 y un sistema de acuerdo con la reivindicación 13. Otros aspectos de la invención se exponen en las reivindicaciones dependientes.
Breve descripción de los dibujos
Se obtendrá una comprensión de las realizaciones a modo de ejemplo, a partir de la siguiente descripción, con referencia a los siguientes dibujos, en los que:
la figura 1 muestra un diagrama esquemático que ilustra un sistema a modo de ejemplo que emplea una estructura de agente configurada, especialmente, para la difusión de mensajes de aviso, de acuerdo con la presente invención;
la figura 2 muestra un diagrama esquemático que ilustra componentes de la estructura de agente del sistema ilustrado en la figura 1;
la figura 3 muestra un diagrama esquemático que ilustra una estructura de gestión del grupo de agentes empleada por la estructura de agente ilustrada en la figura 2;
la figura 4 muestra cómo un diagrama esquemático que ilustra un subconjunto de los agentes y componentes del sistema implicados en la gestión de la estructura de agente ilustrada en la figura 2; la figura 5 muestra un diagrama esquemático que ilustra los componentes del sistema ilustrado en la figura 1 implicados en la gestión de las cuentas de los abonados del sistema;
la figura 6 muestra un diagrama esquemático que ilustra el flujo de información a través del sistema con respecto al servicio de recuperación / reenvío de contenido ilustrado en la figura 5; y
la figura 7 muestra un diagrama esquemático de un sistema a modo de ejemplo para la difusión de mensajes de aviso a una pluralidad de diferentes tipos de dispositivos de destino, de acuerdo con la presente invención.
Descripción detallada de realizaciones a modo de ejemplo de la invención
Las ventajas de la invención se pueden obtener a través de los sistemas a modo de ejemplo que se describen a continuación, con referencia a los dibujos. En su caso, se utilizan los mismos números de referencia en los dibujos para indicar características similares en todos los dibujos.
Descripción general del sistema a modo de ejemplo
El sistema proporciona la difusión priorizada de mensajes de aviso a grupos seleccionados de destinatarios y a sus dispositivos de comunicación. Los perfiles de los destinatarios se guardan de diversas maneras en bases de datos, directorios y nodos de comunicaciones accesibles por el sistema. Estas fuentes son consultadas para la identificación de grupos seleccionables que, a continuación, son presentados a un despachador (por ejemplo, un administrador del sistema u otra autoridad de difusión) para elegir los destinatarios. El mensaje de aviso es proporcionado a continuación a un módulo de entrega que emplea una pluralidad de módulos incluidos, cada uno de los cuales está configurado para comunicar el mensaje de aviso a un tipo de dispositivo de destino correspondiente. A continuación, un módulo de gestión de respuestas recibe respuestas de los dispositivos de destino para su posterior notificación.
El sistema proporciona, asimismo, la determinación del contexto del destinatario y el procesamiento de mensajes de aviso para la miniaturización inteligente u otra adaptación de los mismos para el dispositivo de comunicaciones del destinatario o para un conjunto de dispositivos de los delegados, y el reenvío del contenido procesado al dispositivo o dispositivos de destino.
Componentes a modo de ejemplo del sistema
La figura 7 muestra un diagrama esquemático que ilustra un sistema 710 a modo de ejemplo para difundir mensajes de aviso a una pluralidad de dispositivos de comunicaciones. El sistema incluye un módulo de despacho 720, un módulo de entrega 730 y una base de datos 740; el sistema también puede incluir un servidor de claves 750 y un gestor de respuestas 760. Tal como se describe a continuación en el presente documento, el sistema 710 puede interconectar uno o más nodos de comunicaciones 770 (por ejemplo, conmutadores y enrutadores de red cableados / inalámbricos y puntos de acceso cableados o inalámbricos) y uno o más directorios externos directorios 780 (por ejemplo, bases de datos utilizadas para identificar identidades de dispositivos personales y conectados a la red en una red corporativa / campus, directorios telefónicos, directorios de nombres de ordenadores centrales de cliente configurados en un dominio de red, o listas de distribución). El sistema 710 se comunica, además, con una pluralidad de dispositivos de comunicaciones de destino 790. Tal como se describe a continuación en el presente documento, los dispositivos de destino 790 pueden incluir cualquier dispositivo de comunicaciones capaz de recibir un mensaje de aviso del sistema 710.
El módulo de entrega 730 puede incluir o estar asociado con cualquier número de módulos subsidiarios (800, 810, 820, 830, 860), cada uno de los cuales es específico de una tecnología de comunicaciones concreta. Por ejemplo, el módulo de entrega 730 puede incluir un módulo de entrega de correo electrónico 800, un módulo de entrega de SMS / MMS 810, un módulo de entrega de IP 820, un módulo de entrega de voz 830 y/o un módulo de entrega de HTTP 860. Tal como se describe más adelante, en el presente documento, el módulo de entrega 730 puede ser extensible para incluir cualquier módulo adicional para tecnologías y medios de comunicación más conocidos o aún desconocidos.
Módulo de despacho
El módulo de despacho 720 proporciona funcionalidad para permitir que un despachador (por ejemplo, un administrador del sistema u otra autoridad de difusión) formule un mensaje de aviso para difusión, para seleccionar los destinatarios del mensaje de aviso y para seleccionar los métodos mediante los cuales los destinatarios recibirán el mensaje de aviso. El módulo de despacho 720, por lo tanto, incluye la funcionalidad para compilar grupos seleccionables de destinatarios de una pluralidad de fuentes para su selección por parte del despachador. Se puede emplear cualquier medio para presentar al despachador dichas listas seleccionables, para permitir al despachador seleccionar o procesar dichas listas para facilitar la selección, o para permitir que el módulo de despacho realice dichas selecciones de manera automática, en base a un conjunto preconfigurado de criterios de selección.
Las listas seleccionables pueden incluir listas de abonados que se hayan registrado o suscrito previamente, o que hayan indicado que desean recibir difusiones de avisos del sistema. Por ejemplo, la base de datos 740 del sistema puede almacenar los detalles de los destinatarios que se han registrado previamente para recibir difusiones de avisos, y el sistema puede incluir cualquier medio adecuado para permitir dicha suscripción o registro por parte de los posibles destinatarios, o interactuar con el mismo. Los detalles del destinatario almacenados en la base de datos pueden incluir solo algún identificador del destinatario registrado, o también pueden incluir las direcciones de uno o más dispositivos de comunicación en los que el destinatario desea recibir dichos mensajes de aviso, y también pueden incluir las preferencias de entrega deseadas (por ejemplo, para especificar un orden de los dispositivos del destinatario donde el sistema debe intentar la entrega de un mensaje de aviso). En el caso de dichos destinatarios registrados, el módulo de despacho 720 recupera las listas de dichos destinatarios registrados de la base de datos 740 del sistema para su selección, tal como se explicó anteriormente.
Adicionalmente (o alternativamente, con fines de eficiencia) las listas seleccionables pueden incluir cualquier clave que se pueda buscar en cualquiera de la base de datos 740, los directorios 780 y/o los nodos de comunicaciones 770. Por ejemplo, la base de datos puede asociar abonados con operadores inalámbricos específicos, dominios de correo electrónico específicos, servidores centrales específicos, etc. Un directorio puede asociar abonados, no abonados, y/o dispositivos (ordenadores) con grupos o ubicaciones corporativas específicas. Y un nodo de comunicación podría asociar dispositivos específicos con una LAN específica, una LAN virtual, un punto de acceso inalámbrico, etc. Dichas claves pueden especificar criterios para identificar los dispositivos de los destinatarios en lugar de identificar destinatarios específicos.
Para tal propósito, el módulo de despacho 720 puede realizar un sondeo, en la creación de instancias del despachador, automáticamente de manera periódica, o, por el contrario, uno o más de los directorios 780, y recuperar listas seleccionables de destinatarios. Dichos directorios externos pueden incluir directorios telefónicos, un directorio de nombres de ordenadores centrales clientes configurados en un dominio de red (que puede estar organizado, además, en el directorio, por ejemplo, por la ubicación), listas de distribución de destinatarios que pueden tener referencias cruzadas en la base de datos 740 para apuntar a direcciones MAC del dispositivo, números de teléfono, nombres de ordenadores centrales, etc., o directorios de abonados proporcionados por proveedores de servicios de terceros, tales como servidores de correo electrónico o proveedores de servicios de Internet.
Adicionalmente, para dichos propósitos, el módulo de despacho 720 también puede interconectar uno o más nodos de comunicaciones 770 accesibles para el sistema 710 que son capaces, a través de dicha interfaz, de proporcionar información sobre grupos seleccionables de destinatarios no necesariamente incluidos en la base de datos del sistema 740 (por ejemplo, que no se han registrado para recibir difusiones de avisos). En general, el sistema 710 puede emplear cualquier medio conocido para determinar desde uno o más nodos de comunicaciones 770 destinatarios a los que se puede acceder a través de cualquiera de los medios disponibles para el módulo de entrega 730.
Por ejemplo, un nodo de comunicaciones 770 puede ser un punto de acceso a la red (por ejemplo, una puerta de enlace de red WiFi / WiMAX, un punto de acceso WiFi/WiMAX o un módem de cable doméstico/de empresa o una interfaz de DSL), y el módulo de despacho 720 puede realizar un sondeo en el punto de acceso de red para obtener una lista de direcciones MAC o de IP, o nombres de anfitrión accesibles a través de ese punto de acceso. En el caso de que un dispositivo identificado de este modo esté asociado en la base de datos 740 a un abonado registrado, el módulo de despacho 720 también puede recuperar cualquier otra de las direcciones de dispositivo de ese abonado (por ejemplo, número de teléfono móvil, dirección de correo electrónico) registrada en la base de datos 740 para utilizar en la selección de criterios de destino del mensaje de difusión. Por ejemplo, se podría enviar un aviso por SMS a los teléfonos móviles de los abonados cuyo dispositivo móvil (por ejemplo, un ordenador portátil o un teléfono inteligente) esté asociado a un punto de acceso WiFi específico.
De manera similar, se podría enviar un aviso basado en IP a los dispositivos móviles de todos los usuarios asociados con todos los puntos de acceso inalámbrico accesibles dentro de un radio específico de una ubicación geográfica (donde el nodo de comunicación puede proporcionar coordenadas geográficas de cada punto de acceso). De manera similar, para destinatarios que utilizan dispositivos en una proximidad lógica o física, tales como los teléfonos móviles conectados de manera inalámbrica a un nodo dado de la red celular (uno de los nodos de comunicaciones 770), los cables telefónicos a un nodo de distribución dado (uno de los nodos de comunicaciones 770), u ordenadores conectados de manera inalámbrica a un nodo WiFi (uno de los nodos de comunicaciones 770), dichos nodos pueden estar configurados para colaborar con el sistema de modo que el sistema pueda consultar o realizar sondeos en dichos nodos para obtener información sobre cualquier dispositivo de destino al que se pueda acceder actualmente a través de dicho nodo, incluidas las direcciones de cualquiera de dichos dispositivos. Dicha información del destinatario y la dirección del dispositivo pueden estar incluidas en los grupos seleccionables para su selección en el módulo de despacho 720. En dicho caso, se puede enviar un mensaje de aviso a todos o a una parte de dichos dispositivos relacionados por una cierta proximidad lógica o física a un determinado nodo de comunicaciones. Por ejemplo, en el caso de que los dispositivos incluyan teléfonos móviles y/o terrestres, un mensaje de aviso puede ser entregado por el módulo de entrega 830 de voz (y/o de entrega de SMS / MMS 810, por ejemplo, para teléfonos móviles habilitados para SMS / MMS) a todos o a una parte de dichos dispositivos que son atendidos por un nodo concreto de la red celular o un determinado nodo de la red telefónica terrestre.
El despachador, o el módulo de despacho 720 automatizado, según sea el caso, selecciona, a continuación, de entre los grupos seleccionables compilados en el módulo de despacho 720 los destinatarios o las características de los destinatarios para recibir un mensaje de aviso de difusión. A continuación, el módulo de despacho 720 transmite la lista, el mensaje de aviso y los tipos de dispositivos móviles en un paquete de datos o en cualquier otra forma adecuada, al módulo de entrega 730 para la entrega a los dispositivos de destino 790 de los destinatarios.
Por ejemplo, el módulo de despacho 720 puede especificar las características de los destinatarios como clientes de un proveedor inalámbrico específico en un conjunto específico de códigos de área, siendo el objetivo sus direcciones de correo electrónico. A continuación, las direcciones de correo electrónico de esos destinatarios son recuperadas por el módulo de entrega 730, de la base de datos 740; cuando un destinatario va a recibir el mensaje de aviso mediante transmisión de SMS / MMS, la dirección de SMS del destinatario es recuperada de la infraestructura de red de la dirección MAC del dispositivo de ese destinatario que está asociado con un punto de acceso concreto en la infraestructura de red; donde el dispositivo de un receptor está conectado a través de IP a un punto de acceso en la infraestructura de red, entonces la dirección IP de ese dispositivo puede ser recuperada de la infraestructura de red; de manera similar, el nombre de anfitrión para el dispositivo del destinatario que está registrado en un dominio concreto (por ejemplo, en un edificio específico) puede ser recuperado de un directorio; cuando el dispositivo de un destinatario es un teléfono, el número de teléfono del destinatario puede ser recuperado de un directorio, incluida una lista de distribución concreta en el directorio.
Se debe apreciar que el módulo de despacho 720 puede proporcionar al despachador la capacidad de generar y despachar mensajes de aviso desde una ubicación remota con respecto al sistema 710. Por ejemplo, el módulo de despacho 720 puede proporcionar adicionalmente un portal web accesible a través de Internet y un navegador web, o una interfaz de telefonía accesible llamando a un número y, además, una interfaz utilizable por el despacho para generar un mensaje de aviso, compilar una lista de destinatarios, tal como se explicó anteriormente, iniciar la comunicación del mensaje de aviso a los destinatarios y recibir y trabajar con informes de respuesta (tal como se explica a continuación).
Módulo de entrega
En general, el módulo de entrega 730 recibe el mensaje de aviso, las características del destinatario (direcciones reales del dispositivo o una o más claves que pueden ser consultadas en cualquiera de las bases de datos 740, los directorios 780 y/o los nodos de comunicaciones 770) y el tipo o tipos de dispositivos de destino preferidos (que pueden estar incluidos en un paquete de datos, tal como se indicó anteriormente), tal como se describió anteriormente, desde el módulo de despacho 720.
Si el módulo de despacho 720 proporciona solo las características de los receptores de transmisión al módulo de entrega 730, el módulo de entrega 730 consulta la base de datos 740, los directorios 780 y/o los nodos de comunicaciones 770, según corresponda, para obtener la dirección específica del dispositivo para cada dispositivo de destino 790 asociado con cada destinatario para recibir el mensaje de aviso.
Tal como se indicó anteriormente, el módulo de entrega 730 puede incluir o estar asociado con cualquier número de módulos subsidiarios, cada uno de los cuales es específico para una tecnología de comunicaciones concreta. Dichos módulos específicos pueden incluir un módulo de entrega de correo electrónico 800, un módulo de entrega de SMS / MMS 810, un módulo de entrega de IP 820, un módulo de entrega de HTTP 860, y/o un módulo de entrega de voz 830, y puede incluir, además, cualquier otro módulo dirigido a otra tecnología o medio de comunicaciones, canal o ruta diferente o relacionado. En dicho caso, el módulo de entrega 730, tras la recepción del mensaje de aviso del módulo de despacho 720, determina con respecto a cada dispositivo de destino las capacidades de comunicación y el rendimiento del dispositivo. Dichas capacidades pueden estar especificadas en el paquete de datos con respecto a cada destinatario y, si las direcciones del dispositivo de destino son proporcionadas por el módulo de despacho 720 en el paquete de datos, a cada dispositivo de destino. Alternativamente, el módulo de entrega 730 puede, consultar la base de datos 740, los directorios 780 o los nodos de comunicación 770, según corresponda, para dichas capacidades, en base a la información del destinatario.
En general, cada uno de los módulos de entrega 800, 810, 820, 830, 860 específicos pueden realizar sus funciones mediante un conjunto de submódulos o subprocesos generados de manera dinámica. Además, cada módulo de entrega específico puede contener una funcionalidad para adaptar el contenido del mensaje de aviso a fin de que pueda ser recibido y/o que sea más adecuado para su visualización por los tipos de dispositivos de destino asociados con ese módulo de entrega específico. Por ejemplo, los avisos enviados por correo electrónico pueden estar formateadas en HTML con logotipos incrustados, imágenes / videos / audio adjuntos, o pueden estar encriptados. Los avisos enviados por SMS pueden estar preparados para tener en cuenta las diferentes capacidades de tipo de proveedor y/o dispositivo inalámbrico (por ejemplo, algunos requieren identificación del originador en el cuerpo, porque no reflejan adecuadamente al emisor). Los avisos enviados por IP pueden contener texto, imágenes, video o audio formateados para renderización en dispositivos específicos.
Para comunicar el mensaje de aviso a los dispositivos de destino 790 capaces de recibir mensajes de correo electrónico, el módulo de entrega 730 puede emplear el módulo de entrega de correo electrónico 800. Si los detalles recibidos por el módulo de entrega 730 para cualquier destinatario concreto no incluyen la dirección de correo electrónico del destinatario, el módulo de entrega puede consultar la base de datos 740, los directorios 780 y/o los nodos de comunicaciones 770 para las direcciones de correo electrónico de ese destinatario. A continuación, el módulo de entrega de correo electrónico 800 transmite el mensaje de aviso al dispositivo de destino 790 de cada destinatario a través de un agente de transferencia de mensajes SMTP opcional o puerta de enlace 840 y a través del servidor de correo electrónico de ese destinatario. La base de datos 740 se puede actualizar, a continuación, para registrar que dichos mensajes han sido enviados. El módulo de entrega de correo electrónico 800 también puede generar una pluralidad de submódulos agrupados para dividir dichas tareas de entrega por volumen, interfaz o cualquier otro criterio deseado.
Para comunicar el mensaje de aviso a los dispositivos de destino 790 capaces de recibir mensajes a través de un nodo de red, en general, (por ejemplo, ordenadores móviles o estacionarios conectados a un punto de acceso a la red), el módulo de entrega de IP 820 puede consultar la base de datos 740, los directorios 780 y/o los nodos de comunicaciones 770 en busca de nombres de anfitrión y/o direcciones IP de los dispositivos de destino 790 correspondientes. El módulo de entrega de IP 820 transmitirá el mensaje a los dispositivos de destino 790, y puede hacerlo mediante unidifusión / multidifusión / difusión a las aplicaciones cliente que operan en los dispositivos. Las transmisiones de unidifusión se pueden realizar a través del protocolo de enlace basado en TCP u otro protocolo de punto a punto (por ejemplo, tales como los que utilizan los sistemas OnStarTM). Las transmisiones de multidifusión se pueden realizar a través de IP o de otra transmisión unidireccional de punto a multipunto. Las transmisiones de difusión pueden ser llevadas a cabo a través de IP o de otro punto unidireccional a todas las estaciones de transmisión. A continuación, el módulo de entrega de IP 820 puede comunicar una actualización a la base de datos 740 que indica la transmisión del mensaje de aviso a esos destinatarios. El módulo de entrega de IP 820 también puede generar una pluralidad de submódulos agrupados para dividir dichas tareas de entrega por volumen, interfaz relevante o cualquier criterio deseado.
El módulo de entrega de IP 820 se puede comunicar, alternativa o adicionalmente, con un servicio de red a través de una puerta de enlace de red 870 (que puede ser uno de los nodos de comunicaciones 770, o cuya funcionalidad es proporcionada por uno de los nodos de comunicaciones 770), donde el servicio de red envía posteriormente el mensaje a dispositivos de destino no accesibles por IP 790 a través de otro protocolo de comunicaciones. Por ejemplo, los dispositivos WiFi conocidos por un punto de acceso WiFi, pero no autenticados se conocen como “dispositivos no asociados”. Un cliente en un dispositivo no asociado de este tipo podría ser accesible a través de métodos de comunicaciones de capa 2, para recibir el mensaje de aviso desde el punto de acceso.
Para comunicar el mensaje de aviso a los dispositivos objetivo 790 capaces de recibir mensajes a través de un nodo de red, en general, pero no configurado con un cliente compatible (ver más abajo) (por ejemplo, ordenadores móviles o estacionarios conectados a un punto de acceso a la red), el módulo de entrega HTTP 860 puede consultar la base de datos 740, los directorios 780 y/o los nodos de comunicaciones 770 en busca de nombres de anfitrión y/o direcciones IP de las correspondientes puertas de enlace de red 870. A continuación, el módulo de entrega de HTTP 860 transmitirá las características del mensaje y del destinatario a la puerta de enlace de red 870. La puerta de enlace de red 870 se encarga de entregar el mensaje a los destinatarios específicos utilizando métodos específicos de implementación. El módulo de entrega HTTP 860 puede comunicar una actualización a la base de datos 740 que indica la transmisión del mensaje de aviso a esos destinatarios. El módulo de entrega HTTP 860 también puede generar una pluralidad de submódulos agrupados para dividir dichas tareas de entrega por volumen, interfaz relevante o cualquier otro criterio deseado.
Para comunicar el mensaje de aviso a los dispositivos de destino 790 capaces de recibir mensajes SMS / MMS (por ejemplo, teléfonos móviles o teléfonos inteligentes), el mensaje de aviso puede ser manejado por el módulo de entrega de SMS / MMS 810. Este módulo puede consultar la base de datos 740, los directorios 780 y/o los nodos de comunicaciones 770 para buscar números de teléfono o direcciones de SMS / MMS, y transmitir el mensaje de aviso a los dispositivos de destino 790 a través de una puerta de enlace SMS o módem. A continuación, el módulo de entrega de SMS / MMS 810 puede comunicar una actualización a la base de datos 740 que indica la transmisión del mensaje de aviso a esos destinatarios. El módulo de entrega de SMS / MMS 810 también puede generar una pluralidad de submódulos agrupados para dividir dichas tareas de entrega por volumen, interfaz o cualquier otro criterio deseado.
Para comunicar el mensaje de aviso a los dispositivos de destino 790 capaces de recibir y reproducir grabaciones de audio (por ejemplo, teléfonos, sistemas de anuncios públicos), el mensaje de aviso puede ser manejado por el módulo de entrega de voz 830. Este módulo recibe el mensaje de aviso y, si el mensaje de aviso aún no identifica por referencia (o adjuntando) un mensaje de audio pregrabado, convierte el mensaje de aviso en una grabación de audio que incluye un mensaje de voz basado en el mensaje de aviso textual utilizando cualquier método disponible de conversión de texto a voz. El módulo de entrega de voz 830 puede consultar la base de datos 740 (por ejemplo, para buscar los números de teléfono de los abonados), los directorios 780 (por ejemplo, los directorios de números de teléfono, incluidas las listas de distribución) y/o los nodos de comunicaciones 770 (por ejemplo, un nodo del sistema telefónico que puede indicar todos los números de teléfono accesibles a través de ese nodo) para buscar las direcciones de los dispositivos de destino 790 (por ejemplo, números de teléfono), en el caso de que el módulo de despacho 720 no proporcione dichas direcciones en el paquete de mensajes de aviso. El módulo de entrega de voz puede generar una pluralidad de módulos o hilos agrupados para comunicar el mensaje de audio a los dispositivos objetivo 790. En particular, cada módulo o hilo agrupado se puede comunicar con una instancia concreta del equipo de comunicaciones para comunicarse con tipos correspondientes de dispositivos objetivo 790. Por ejemplo, cada módulo o subproceso agrupado se puede comunicar con un dispositivo de marcación de DTMF / VoIP para marcar el número de teléfono de un dispositivo de destino para recibir el mensaje de audio. Cada uno de estos módulos o subprocesos agrupados se puede configurar para realizar cualquier número deseado de intentos para completar la comunicación en caso de que reciba, por ejemplo, una señal de ocupado, o si no se responde una llamada. En general, dichos módulos / subprocesos agrupados se pueden generar y distribuir las tareas de entrega del módulo de acuerdo con cualquier criterio deseado. El módulo de entrega de voz 830 puede comunicar una actualización a la base de datos 740, indicando la transmisión del mensaje de aviso a esos destinatarios.
Una vez que se completa la entrega de un mensaje de aviso (incluyendo, opcionalmente, la recepción de confirmaciones de entrega de los dispositivos de destino 790 - ver a continuación), el módulo de entrega 730 puede registrar dicha entrega en la base de datos 740. Por ejemplo, en el caso de comunicación mediante el módulo de entrega de voz 830, dicho módulo puede actualizar la base de datos 740 para registrar el resultado de un intento de comunicación con un dispositivo de destino 790 concreto, por ejemplo, un intento de llamada a un teléfono, con un resultado tal que incluye, por ejemplo, sin respuesta, ocupado, escuchado, respondiendo.
Aplicación del cliente
El sistema 710 también puede estar configurado para colaborar con los clientes de difusión de avisos correspondientes residentes en uno o más de los dispositivos de destino 790. Dichos clientes pueden estar configurados para recibir el mensaje de aviso y cualquier información asociada de un módulo de entrega 800, 810, 820, 830, 860 específico correspondiente asociado con el módulo de entrega 730. El cliente puede estar configurado para recuperar o tomar medidas activas para obtener el mensaje de aviso (por ejemplo, realizar un sondeo en el servidor de correo electrónico del destinatario 840, escuchar conexiones entrantes desde el módulo de entrega de IP 820, o escuchar los SMS entrantes desde el módulo de entrega de SMS / MMS 810), y puede proporcionar la funcionalidad de colaboración tal como se describe a continuación, en el presente documento, por ejemplo para proporcionar un mecanismo de confirmación y respuesta de recepción, y/o para proporcionar autenticación y seguridad de mensajes. El sistema 710, que incluye el módulo de entrega 730 y los módulos de entrega específicos asociados 800, 810, 820, 830, 860 se puede configurar para preparar cualquier comunicación concreta a un dispositivo de destino 790 para colaborar con dicho cliente o, en su lugar, puede preparar la comunicación suponiendo que dicho cliente no está operando en el dispositivo de destino 790 (es decir, que solo se basa en una capacidad mínima establecida para ese dispositivo).
Por ejemplo, un cliente en un dispositivo habilitado para WiFi (asociado o no asociado) puede escuchar las conexiones entrantes desde el módulo de entrega de IP 820, aceptar las conexiones, recibir y procesar la carga útil (opcionalmente autenticar, confirmar recepción, mostrar), a continuación, desconectar, volver a conectar al gestor de respuestas 760 con una respuesta del usuario (cuando corresponda) y, luego, prepararse para conexiones posteriores. (Los dispositivos no asociados pueden tener que esperar una asociación WiFi antes de proporcionar una confirmación y/o una respuesta). Un cliente en una puerta de enlace de red 870 podría funcionar de manera similar, escuchando las conexiones del módulo de entrega de HTTP 860 y/o el módulo de entrega de IP. Un cliente en un dispositivo habilitado para SMS / MMS escucharía los mensajes entrantes del módulo de entrega de SMS / MMS 810, recibiría y procesaría la carga útil del mensaje de manera similar, pero la recepción y la respuesta del usuario serían devueltos al gestor de respuestas 760 como un mensaje de SMS si está configurado para hacerlo. Gestor de respuestas
El sistema 710 puede incluir un gestor de respuestas 760 para recibir mensajes de acuse de recibo de recepción desde los dispositivos de destino 790 y proporcionar informes del mismo al despachador, incluso por medio de la generación de informes 850. Cualquier dispositivo de destino 790 que tiene un cliente de difusión de avisos instalado o que opera de otra manera en el dispositivo puede proporcionar un acuse de recibo u otra respuesta de manera automática o por orden del destinatario, por medio del cliente.
En el caso de la comunicación de un mensaje de aviso a un dispositivo de destino 790 capaz de recibir un mensaje de correo electrónico, ese dispositivo de destino 790 puede enviar, de manera automática o por orden del destinatario que opera ese dispositivo, un mensaje de respuesta a un buzón de correo de gestión de las respuestas; dicho mensaje de respuesta puede incluir simplemente un acuse de recibo del mensaje de aviso, o también puede incluir un acuse de recibo de que el mensaje de aviso ha sido leído, y/o una indicación de que el destinatario está realizando alguna acción que también puede ser especificada en el mensaje de respuesta.
En el caso de la comunicación de un mensaje de aviso a un dispositivo de destino 790 capaz de recibir un mensaje SMS / MMS, ese dispositivo de destino 790 puede enviar, de manera automática o por orden del destinatario que opera ese dispositivo, un mensaje de respuesta a un buzón de correo del gestor de respuestas, si el dispositivo tiene capacidad de correo electrónico, o un código corto SMS / MMS monitorizado por el gestor de respuestas 760.
En el caso de la comunicación de un mensaje de aviso a un dispositivo de destino 790 capaz de recibir un mensaje de audio y también de responder con un mensaje de audio (por ejemplo, un teléfono), el destinatario puede utilizar el dispositivo de destino para responder con tonos de DTMF o comandos reconocidos por voz para reconocer que el mensaje de aviso codificado en audio fue recibido (por ejemplo, escuchado), y también puede indicar que están tomando medidas en respuesta al mensaje de aviso, lo que puede proporcionar una indicación de qué medidas están tomando.
En general, cualquier dispositivo de destino 790 concreto que tenga capacidad suficiente puede operar una aplicación de cliente de transmisión de avisos configurada para recibir y procesar el mensaje de aviso y comunicar uno o más de los recibos de recibo, lectura y acción descritos anteriormente, según sea el caso, de manera automática o por orden del destinatario que opera el dispositivo de destino. Además, el dispositivo de destino 790 se puede utilizar para comunicar información situacional adicional al despachador, tal como un mensaje de texto, una imagen, un video o un audio. Dichas respuestas informativas se podrían utilizar para proporcionar contenido para transmisiones posteriores a los destinatarios objetivo en una situación de emergencia, con el fin de proporcionar orientación o simplemente más información.
Además, en la medida en que la recepción por parte del gestor de respuestas 760 de un acuse de recibo desde un dispositivo de destino 790 concreto indica que dicho dispositivo de destino 790 está “vivo” y listo para recibir más comunicación, el despachador, tras la recepción de una notificación del gestor de respuestas 760 de que el dispositivo de destino 790 concreto está vivo, puede iniciar comunicaciones bidireccionales con dicho dispositivo 790 a través del módulo de respuesta 730, por ejemplo, generando un mensaje de aviso adicional y compilando una lista de destinatarios que contenga solo ese dispositivo 790, o de algún otro modo. Dicha instalación es particularmente ventajosa cuando el dispositivo de destino 790 concreto había respondido originalmente al gestor de respuestas 760 con información situacional, y el despachador ha podido determinar a partir de dicha información situacional que el usuario de ese dispositivo de destino requiere instrucciones específicas para evitar un peligro, o puede tener o ser capaz de obtener más información útil.
Una vez que el gestor de respuestas 760 recibe un acuse de recibo u otro mensaje de respuesta desde un dispositivo de destino 790, puede actualizar la base de datos 740 con los detalles de dicho acuse de recibo o respuesta, y a continuación, puede informar al despachador del contenido de la respuesta por medio del módulo de informes 850 o de algún otro modo.
Módulo de notificación
El sistema 710 puede incluir un módulo de notificación 850 para generar informes basados en los contenidos de la base de datos 740 o en base a cualquier otra información que pueda recibir el sistema 710. Dichos informes pueden incluir información sobre los destinatarios para los que se intentó comunicar el mensaje de aviso, el tipo o los tipos de los dispositivos objetivo de cada destinatario. 790, la dirección o direcciones de dicho dispositivo o dispositivos 790, y cualquier acuse de recibo o respuesta recibido del dispositivo o los dispositivos 790 por medio del gestor de respuestas 760 o de algún otro modo. Dichos informes también pueden particularizar los vínculos entre múltiples avisos y sus respuestas para proporcionar una pista de auditoría de respuesta a un incidente.
Autenticación de mensajes / Servidor de claves
El sistema 710 puede incluir un módulo de servidor de claves 750 para proporcionar la autenticación de mensajes de aviso emitidos y evitar la creación de rutas adicionales para el correo no deseado hacia los dispositivos de destino 790. Se puede emplear cualquier metodología de autenticación adecuada, incluida la autenticación que emplea encriptado público-privado de claves. En tal realización, el módulo de despacho 720 comunica una solicitud al servidor de claves 750 para una etiqueta de mensaje y una clave privada. El servidor de claves 750 genera, a continuación, un nuevo par de claves pública-privada y una etiqueta asociada, y comunica la etiqueta y la clave privada al módulo de difusión 720.
Cuando se prepara el mensaje de aviso para la comunicación a los dispositivos de destino 790 a través del módulo de entrega 730, el módulo de despacho 720 encripta alguna parte del paquete de mensajes utilizando la clave privada y, a continuación, empaqueta los identificadores de los destinatarios (y las direcciones, según sea el caso, véase lo anterior), el mensaje de aviso y la etiqueta del mensaje. Por ejemplo, una marca de tiempo incluida en el mensaje de aviso, o cualquier otra parte predeterminada del mensaje de aviso, puede ser encriptada. A continuación, el paquete es comunicado al módulo de entrega 730 para la comunicación con los dispositivos de destino 790.
T ras la recepción del mensaje de aviso y de la etiqueta de mensaje, cualquier dispositivo de destino 790 configurado para autenticar el mensaje de aviso (por ejemplo, operar una aplicación de cliente de mensaje de aviso configurada para tal propósito - véase lo anterior) se puede comunicar con el servidor de claves 750 para recuperar la clave pública asociada con la clave privada utilizada para encriptar una parte del mensaje de aviso. La clave pública puede ser recuperada del servidor de claves 750 por medio de la etiqueta de mensaje (es decir, comunicando la etiqueta de mensaje al servidor de claves 750). El dispositivo de destino 790 puede desencriptar la parte encriptada del mensaje de aviso utilizando la clave pública para autenticar el mensaje de aviso. Por ejemplo, si la porción encriptada del mensaje de aviso es una marca de tiempo incluida en el mismo, el dispositivo de destino 790 desencriptaría dicha porción utilizando la clave pública, que, en tal caso podría tener un límite de tiempo. (Limitar la clave pública a un momento concreto, en dicho caso, serviría para evitar la reutilización ilícita si la clave privada ha sido puesta en peligro o robada). El dispositivo de destino 790, o el cliente de mensaje de aviso que opera allí, puede identificar el mensaje de aviso como autenticado solo si la marca de tiempo desencriptada cae dentro de un intervalo de fecha / hora predeterminado. En otras palabras, si la marca de tiempo desencriptada está demasiado lejos en el pasado, o está en el futuro, el dispositivo de destino 790, o un cliente de mensaje posterior, puede considerar que dicho mensaje no es auténtico. En general, el sistema y el dispositivo de destino pueden emplear cualquier autenticación, tal como la criptografía de clave simétrica.
En dicha realización, el servidor de clave pública es “bien conocido” por los destinatarios previstos. Por ejemplo, se puede determinar “fuera de banda” (preconfigurado) para evitar que los originadores ilícitos establezcan un servidor sombra de claves. Alternativamente, todos los clientes de mensajes de aviso pueden estar preconfigurados con una dirección o identidad del servidor de claves públicas. Dicha dirección o identidad puede incluir un nombre de anfitrión predeterminado y conocido, con la ventaja de que se puede acceder al servidor de claves públicas, por ejemplo, en puntos de acceso WiFi públicos.
El mensaje de autenticación, tal como el descrito anteriormente, en general solo se realizará en los dispositivos de destino que tienen un cliente de mensajes de aviso instalado / operativo. Puesto que no todos los dispositivos de destino serán capaces, ordinariamente, de un cliente de este tipo (por ejemplo, un teléfono de voz simple), la parte principal del propio mensaje de alerta habitualmente no está encriptado. No obstante, en casos especiales en los que el despachador tiene la suficiente confianza de que todos los destinatarios previstos están, o deberían estar, operando un cliente de mensajes de aviso de colaboración, cualquier parte, incluida la totalidad, del mensaje de aviso puede ser encriptada.
El sistema 710 también puede estar configurado para realizar la detección de engaños en caso de que uno o más dispositivos de destino 790 reciban un mensaje de aviso de falsificación. Por ejemplo, el gestor de respuestas 710 puede estar configurado para comparar el acuse de recibo u otra información de respuesta recibida desde un dispositivo de destino con la información almacenada en la base de datos 740 con respecto a cualquier mensaje de aviso transmitido reciente o previamente, e identificar incoherencias sospechosas. Por ejemplo, si un dispositivo de destino 790 transmite un acuse de recibo al gestor de respuestas 760, pero no se ha transmitido ningún mensaje de aviso recientemente, el gestor de respuestas 760 puede indicar el acuse de recibo y generar un informe a través del módulo de informe 850 o transmitir un mensaje al módulo de despacho 720 para, por ejemplo, la consideración del despachador. Cualquier cliente de mensajes de aviso instalado y que funcione en un dispositivo de destino también puede estar configurado para incluir en un acuse de recibo del dispositivo de destino una copia del mensaje de aviso recibido; dicha copia puede ser comparada, a continuación, por el gestor de respuestas 760, con una copia del mensaje de aviso original almacenada en la base de datos 740. Dicha técnica de comparación también puede ser empleada cuando el dispositivo de destino recibe un correo electrónico o mensaje SMS / MMS, y responde a un buzón de correo de respuestas o un código abreviado de SMS / MMS.
Base de datos
Tal como se explicó anteriormente, la base de datos 740 almacena registros para cada destinatario que se registró / suscribió para recibir mensajes de aviso. La base de datos 740 también puede almacenar información sobre cualquier otro destinatario o dispositivo de destino no registrado / suscrito para recibir mensajes de aviso, pero cuya identidad y/o dirección o direcciones del dispositivo de destino fueron determinadas mediante cualquiera de los medios explicados anteriormente. Dichas direcciones de dispositivo pueden incluir una dirección de MAC, un número de teléfono (incluido un número de teléfono móvil), un nombre de usuario de dominio corporativo, un identificador de interfaz de red, etc. La base de datos también contiene la información recibida por el gestor de respuestas 760, con el fin de proporcionar información para el módulo de notificación 850.
Realización de entrega de HTTP
Con el fin de identificar tantos posibles destinatarios como sea posible en una proximidad física o lógica para recibir un mensaje de aviso, cualquier sistema puede emplear métodos conocidos. Por ejemplo, es conocido para los despliegues de WiFi en áreas públicas, autenticar a nuevos usuarios con el propósito, por ejemplo, de obtener información de pago y autorización de privilegios de acceso. Tal como se describió anteriormente, dichas técnicas también pueden ser empleadas en el presente sistema para identificar posibles destinatarios de mensajes de aviso conectados a dicho nodo de comunicaciones y realizar la entrega de mensajes de aviso para ellos. A continuación, se proporcionan detalles adicionales de dicha realización.
Por ejemplo, un destinatario dado puede estar utilizando un ordenador o un dispositivo inalámbrico de mano (es decir, el dispositivo de destino 790 del destinatario) que está conectado en red de manera inalámbrica utilizando WiFi o WiMAX o un sistema inalámbrico similar (es decir, un nodo de comunicaciones 770) accesible por el módulo de despacho 720 y el módulo de entrega 730 a través de la puerta de enlace de red 870. En dicho caso, el sistema 710 proporciona el mensaje de aviso a la puerta de enlace de red 870, y puede hacer que el nodo de comunicaciones, a través de la puerta de enlace de red 870, redirija la sesión de HTTP del ordenador destinatario a un sitio web que se ha actualizado para contener el mensaje de aviso, o que requiere que el destinatario descargue e instale una aplicación cliente de mensajes de aviso para recibir el mensaje de aviso. De esta manera, el cliente instalado puede ser utilizado para recibir y autenticar el mensaje de aviso comunicado posteriormente. (En dicho caso, el cliente descargado puede estar preconfigurado con la identidad y/o dirección, por ejemplo, de un servidor de claves públicas, donde la autenticación se realiza mediante criptografía de clave pública - privada tal como se describió anteriormente). En el proceso, el módulo de despacho 720 también puede capturar y registrar en la base de datos 740 la dirección de ese dispositivo de destino, y comunicar un identificador de destinatario y, tal vez, también la dirección del dispositivo al módulo de entrega 730 para la comunicación del mensaje de aviso al dispositivo de destino 790.
En consecuencia, los grupos de destinatarios seleccionables disponibles para el módulo de despacho 720 puede incluir una lista de puertas de enlace de red 870. Dicha puerta de enlace de red 870 puede estar preconfigurada con una página para contener el mensaje de aviso de difusión, y puede requerir, además, dispositivos asociados con puntos de acceso conectados para ver la página del mensaje, e incluso puede requerir dispositivos no asociados con puntos de acceso conectados de destino para asociar y, a continuación, ver la página del mensaje. Tanto en casos asociados como no asociados, la puerta de enlace de red 870 también puede realizar un seguimiento de los dispositivos de destino conectados a ella y notificar al módulo de despacho una indicación de cualquier dispositivo que haya recibido un mensaje de aviso.
Implementación física
El sistema 710 puede ser implementado en cualquier combinación de hardware y/o software, según se considere ventajoso y deseable en cualquier aplicación concreta. La totalidad del módulo de despacho 720, el módulo de respuesta 730, la base de datos 740, el módulo de servidor de claves 750, el gestor de respuestas 760 y el módulo de notificación 850 pueden residir y operar en un solo ordenador, o pueden residir y operar en una pluralidad de ordenadores conectados unos a otros. Además, cualquiera de las funcionalidades de los diversos modelos puede estar incorporada en instrucciones de software informático que residen en una memoria o un medio legible por ordenador en comunicación con un ordenador, o alternativamente, puede estar incorporada en hardware de propósito especial construido específicamente para realizar dicha funcionalidad. Cualquiera de las diversas interfaces entre los diversos módulos y componentes ilustrados en la figura 7 puede estar incorporado como conexiones lógicas entre componentes o construcciones de software, o puede estar incorporado como un medio de comunicación física (por ejemplo, una conexión de red física u otra conexión de datos, tal como una conexión de datos a un marcador de DTMF). En general, una persona experta en la técnica relevante puede implementar la funcionalidad lógica de las diversas partes del sistema ilustradas en la figura 7 y descritas en el presente documento para adaptarse a cualquier aplicación concreta.
Realización específica que emplea una estructura de agente
El sistema descrito anteriormente puede ser implementado en cualquier configuración específica de hardware / software que se considera más ventajosa en cualquier contexto concreto. Por ejemplo, el sistema puede estar incorporado en un sistema tal como el descrito en la Solicitud Internacional N° PCT/CA2007/002197 del solicitante en tramitación con la presente. Los detalles de dicha realización específica se exponen a continuación. Con el fin de distinguir y/o describir las relaciones entre la realización general descrita anteriormente y la realización específica que se describe a continuación, las realizaciones se denominarán en adelante en el presente documento “sistema general” o “realización general” por un lado, y “sistema” o “presente realización”, por otro lado.
La presente realización que se describe a continuación contempla la provisión de difusión de mensajes de aviso, tal como se describió anteriormente, como parte de un sistema también dirigido, en general, a proporcionar servicios de comunicaciones más amplios a los usuarios finales. La inclusión de la difusión de mensajes de aviso en dicho sistema es especialmente ventajosa, en el sentido de que proporciona una integración y, por lo tanto, una simplificación, de los servicios de comunicaciones necesarios y/o deseados por un usuario final.
Específicamente, el sistema permite a los usuarios finales recuperar mensajes y otros contenidos seleccionados de entre una pluralidad de fuentes y para el procesamiento de dichos mensajes o de otro contenido para la miniaturización inteligente u otra adaptación de los mismos para el dispositivo móvil del usuario o un conjunto de dispositivos móviles de delegados designados, y el reenvío del contenido procesado al dispositivo o dispositivos. Dicho contenido puede incluir: contenido pasivo, por ejemplo, extraído de mensajes y de naturaleza informativa); o contenido activo, por ejemplo, también extraído de mensajes, que el usuario puede utilizar para activar acciones tales como realizar una llamada, iniciar un chat, ordenar el pago de un servicio o producto, etc.
El sistema proporciona, además, la difusión priorizada de mensajes de aviso a grupos seleccionados de usuarios y a sus dispositivos. Los perfiles de usuario se mantienen de manera diversa en bases de datos, directorios y otros nodos de comunicaciones (tal como en la realización general). Estas fuentes son consultadas para la identificación de grupos seleccionables, que a continuación, son presentados al administrador del sistema (por ejemplo, el despachador) para elegir los destinatarios. El mensaje de aviso es proporcionado a los agentes de difusión dentro de una estructura de agentes que, a continuación, genera agentes agrupados específicos para cada tipo de dispositivo de destino para entregar el mensaje utilizando los canales de mensajería apropiados. A continuación, los agentes de respuesta de difusión observan y recopilan respuestas para notificaciones posteriores.
Una ventaja particular es que el sistema es adaptable para recuperar mensajes de cualquier fuente a la que puede acceder el sistema a través de una red que incluye, entre otros, Internet. Dichas fuentes incluyen agentes de transferencia de correo de Internet (“MTA”) y puertas de enlace de SMS, servidores de correo externos e internos, incluidas fuentes de RSS, páginas web nativas, bases de datos, servicios web e Internet.
El sistema proporciona el mantenimiento de un perfil para cada usuario, donde dicho perfil influye en la recogida, el procesamiento y el reenvío de mensajes y de otro contenido al dispositivo de usuario. El sistema contempla múltiples niveles de usuario en los que dichos parámetros tales como frecuencia de sondeo del buzón de correo de mensajes, prioridad de procesamiento de mensajes y asignación de recursos del sistema son influenciados por un nivel de usuario. En, al menos, una realización, el perfil del usuario es accesible, al menos en parte, por el usuario, para permitirle seleccionar, directamente, preferencias relativas a: buzones de correo u otras fuentes para la recuperación de contenido; el modo en el que dicho contenido es procesado, miniaturizado o adaptado de otro modo para su presentación en el dispositivo o dispositivos de usuario; y los dispositivos a los que dicho contenido procesado debe ser reenviado mientras es móvil.
El sistema proporciona el mantenimiento de perfiles para grupos de usuarios cerrados que influyen en el procesamiento, el análisis de contexto y el reenvío de mensajes y otro contenido a los dispositivos de los usuarios en dichos grupos.
Para lograr las funciones descritas anteriormente, el sistema incluye una estructura colaborativa de múltiples agentes en la que agentes configurables por el usuario, interdependientes, pero esencialmente autónomos, realizan muchas de las funciones. La estructura interactúa y colabora con componentes internos y externos al sistema, tal como se describe más adelante en el presente documento. Un servicio que proporciona contenido o servicios accesibles en red a dispositivos móviles se implementa como una aplicación en la estructura de agentes. Este servicio aprovecha la estructura para proporcionar una capacidad escalable para que los usuarios finales registrados puedan autogestionar qué contenido específico llega a su dispositivo móvil, incluida la forma en que se transmite. La estructura escalable de múltiples agentes soporta cientos, miles o millones de usuarios a través de la integración de un agente de programación inteligente, un agente de conexión de base de datos y un soporte de estructura para grupos de agentes que contienen números variables de agentes para realizar tareas de procesamiento. Los agentes se basan en esta estructura para proporcionar conexión a fuentes de contenido (por ejemplo, buzones de correo o servidores), para aplicar preferencias de usuario en base al contexto, con respecto al filtrado y el procesamiento de contenido, para transmitir notificaciones o avisos a los dispositivos, para activar servicios de Internet en base a contenido activo y para monitorizar problemas que pueden requerir la intervención del usuario.
El sistema también permite a los usuarios móviles responder a las notificaciones mediante la utilización de canales de mensajería de vuelta a la estructura de agentes desde el dispositivo móvil. Estos canales incluyen mensajería electrónica, SMS, mensajería instantánea, conexiones IP directas, canales de voz o navegación web. En algunos casos, las respuestas a las notificaciones se pueden mejorar mediante la utilización de agentes móviles basados en el cliente, conocidos por la estructura. Un usuario podría, por ejemplo, querer enviar una respuesta “enlatada” al remitente, o puede querer recibir el texto completo de un mensaje en varios mensajes posteriores si la notificación original incluye solo un pequeño resumen. El sistema también permite a los usuarios móviles responder a notificaciones mediante la utilización de contenido activo proporcionado dentro de la notificación. Dicho contenido activo se utiliza para habilitar métodos de comunicación nativos para los dispositivos, tales como el inicio de llamadas de voz o sesiones de chat en un teléfono móvil. El contenido activo también puede desencadenar servicios transaccionales, tales como el pago de un producto o servicio por parte de un usuario a través de un agente proxy con autorización del usuario para realizar dicho pago.
Componentes del sistema
La figura 1 muestra un diagrama esquemático que ilustra un sistema 10 a modo de ejemplo de acuerdo con la presente realización. El sistema 10 incluye uno o más servidores 20 que ejecutan sistemas operativos dentro de los cuales operan la estructura de agentes 30, vigilante 40 y servidor de aplicaciones web 50. Una consola de administración 60, un portal de autoadministración de usuario final 70 y un gestor de respuestas 75 operan dentro de uno o más de los servidores de aplicaciones web 50, una base de datos 80 para capturar y almacenar todas las ejecuciones de datos de usuario en otro servidor o grupo de servidores. También se incluyen secuencias 90 para realizar tareas administrativas tal como se describe más adelante en el presente documento.
El sistema 10 interactúa con los clientes 100 de HTTP (por ejemplo, navegadores web operados por usuarios finales en dispositivos fijos y/o móviles) a través de un portal de autoadministración 70, mediante el cual los usuarios finales pueden ver y modificar su perfil y estado tal como están almacenados en la base de datos 80. También interactúa a través de HTTP (fijo y/o móvil) con los usuarios administradores a través de una consola de administración 60, por lo que los administradores pueden monitorizar y configurar el perfil del servicio en la base de datos 80, la estructura de agentes 30 y el vigilante 40. Tal como se describe a continuación en el presente documento, la consola de administración 60 también emplea un adaptador de gestión 65 para interactuar con la estructura de agentes 30. El sistema 10 también interactúa con fuentes de contenido pasivo (servidores de directorios corporativos, almacenes de correo y servicios de información 110, y almacenes de correo de Internet y fuentes de información 120) y contenido activo (por ejemplo, corredores de servicios de Internet que ofrecen un servicio o producto a los usuarios finales tras un pago electrónico) a través de protocolos estándar y patentados para recuperar contenido nuevo o actualizado. Finalmente, también interactúa con las puertas de enlace a través de protocolos estándar, tales como SMTP, SMPP y SOAP, e interactúa con cualquier otra interfaz de comunicación proporcionada 125 (por ejemplo, equipo de red local que proporciona acceso a redes de comunicación, equipo de telefonía de voz) para proporcionar comunicación a dispositivos de usuario final tanto móviles como fijos.
Se incluyen una puerta de enlace de SMTP 130, que se utiliza para comunicarse con agentes de transferencia de correo de SMTP externos (“MTA”) 140 para acceder a fuentes de mensajes externos, y puertas de enlace de proveedor de servicios externos SMS / MMS 150 (que pueden incluir correo electrónico) a puertas de enlace de SMS / MMS) para interactuar con dispositivos móviles a través del protocolo de SMS / MMS.
Cuando se realiza su funcionalidad de difusión de avisos, las fuentes externas o destinatarios accesibles por el sistema, identificados anteriormente, pueden estar incluidos en cualquiera de las fuentes o destinatarios descritos en conexión con el sistema general. Por ejemplo, los directorios 127 pueden incluir los servidores de directorio corporativo identificados anteriormente, así como cualquier otro directorio 780, tal como se describe en conexión con el sistema general. Del mismo modo, las interfaces de comunicaciones 125 pueden estar incluidas en cualquiera de los nodos de comunicaciones 770 o en la puerta de enlace de red 870 en conexión con el sistema general. De manera similar, la puerta de enlace de SMTP 130 y/o los MTA de SMTP 140 pueden estar incluidas en el MTA o en la puerta de enlace de SMTP 840 del sistema general.
La estructura de agentes 30 se ejecuta dentro de un entorno seguro (por ejemplo, una máquina virtual de Java) y, en general, se implementa como un sistema cerrado y seguro, pero el entorno operativo típico está en un servidor 20 detrás de un cortafuegos seguro de red 160. No depende de ninguna funcionalidad específica del cortafuegos, pero una instalación típica garantizará el bloqueo de todos los puertos de acceso, excepto los requeridos por HTTP, SMTP, POP3 e IMAP, y sus variantes encriptadas.
La estructura de agentes 30 proporciona un entorno para el desarrollo de aplicaciones en forma de agentes colaboradores. Las capacidades incluyen: creación de instancias, gestión y destrucción de agentes, soporte para la gestión de grupos de agentes trabajadores clonados, comunicación entre agentes, gestión de temporizadores y registro.
Los componentes de gestión externos a la estructura de agentes 30 incluyen dos aplicaciones web que se ejecutan en un servidor de aplicaciones web 50. El primero es un portal de autoadministración 70 al que accede el usuario final, mediante el cual los usuarios se suscriben al servicio y administran su perfil. Este componente solo interactúa con la base de datos 80. El segundo es una consola de administración 60 que se proporciona a los administradores para administrar el sistema. La consola de administración 60 aprovecha dos componentes adicionales: un centinela vigilante 40, que inicia, detiene y garantiza la robustez de la estructura de agentes 30 y el servicio; y un adaptador de gestión 65, que proporciona una interfaz en tiempo real en el servicio. El adaptador de gestión 65, a su vez, se comunica con un agente de gestión dentro de la estructura de agentes 30, para recuperar el estado en tiempo real de los agentes que componen el servicio. Adicionalmente, externo a la estructura de agentes 30, las secuencias 90 periódicas son ejecutadas para mantener la base de datos 80 y proporcionar funciones de notificaciones adicionales, tales como proporcionar actualizaciones periódicas a los usuarios de la actividad del servicio con respecto a sus propios perfiles.
El servicio puede ser implementado como una aplicación de empresa (es decir, proporcionar servicios a un grupo de usuarios autenticados en dominios corporativos locales) o como una aplicación administrada por un proveedor de servicios (es decir, proporcionar servicios a abonados externos que no son miembros de un dominio de autenticación cohesivo). En el caso de una implementación corporativa, los usuarios finales se autentican para la autogestión utilizando la autenticación de dominio contra un servicio de directorio. En una implementación de proveedor de servicios, el servicio proporciona autenticación interna y gestión de contraseñas. Además de esta diferencia, los componentes del servicio son indiferentes al escenario de despliegue.
En las implementaciones tanto de empresas como de proveedores de servicios, el sistema puede consistir en múltiples estructuras de agentes 30, cada una controlada por un vigilante 40 e interconectadas con un adaptador de gestión 65. Cada una de estas estructuras de agentes 30 se identifica mediante un ID del servicio, y cada abonado se asigna a un ID de servicio, pero se puede mover de un ID de servicio a otro para permitir el equilibrio de carga entre diferentes instancias. Dichas estructuras de agentes distribuidas funcionan de manera independiente, pero comparten la base de datos de usuarios 80, las secuencias 90 de comandos asociadas, el portal de autoadministración 70 y la consola de administración 60. En general, no obstante, la totalidad de la estructura de agentes 30, el vigilante 40, la consola de administración 60, el adaptador de gestión 65, el portal de autoadministración 70, la base de datos 80 y los componentes de secuencias 90 se pueden combinar en un solo servidor o dividir en una solución de múltiples servidores. En un escenario de múltiples servidores, los componentes estructura de agentes 30 y vigilante 40 están situados, en general, conjuntamente y pueden estar duplicados para fines de escalabilidad y/o redundancia. Del mismo modo, en los casos en los que la base de datos 80 está distribuida a través de múltiples servidores, cada segmento o porción de este tipo estará acompañada, en general, por secuencias 90 para el mantenimiento de esa porción o segmento. Múltiples servidores de aplicaciones web 50 también pueden estar provistos de cada uno operando la correspondiente consola de administración 60 y/o portal de autoadministración 70. El portal de autoadministración 70 de usuario final y la consola de administración 60 están construidos para reconocer e interactuar con múltiples combinaciones de estructura / vigilante.
A continuación, se describirán los componentes de administración del sistema y la estructura de agentes, seguidos de una descripción de los componentes del servicio y su funcionamiento.
Componentes de la consola de administración del servicio
La consola de administración 60 proporciona una interfaz para que los administradores supervisen y administren el servicio, y para generar mensajes de aviso para su difusión (es decir, como un despachador en el sistema general). La consola 60 es una aplicación web que puede soportar múltiples instancias de los entornos de estructura de agentes / vigilante / Adaptador de gestión, a los que acceden los administradores especificando el ID del servicio.
La consola de administración 60 se conecta localmente o a través de una red con el adaptador de gestión 65 para acceder a la información de estado en tiempo real sobre la estructura de agentes 30, para acceder a los archivos de configuración del agente, para acceder a la interfaz del vigilante 40 y para acceder a utilidades que proporcionan procesamiento local de comandos más largos (tal como difundir un mensaje a todos los abonados con un ID de servicio específico).
La consola 60 también interactúa directamente con la base de datos de usuarios 80, para permitir a los administradores monitorizar y modificar los datos de la cuenta del abonado y procesar los resultados.
Cuando se realiza la funcionalidad de difusión de avisos del sistema 10, la consola 60 puede interconectar, además, para consultar la base de datos de usuarios 80 (para recuperar, por ejemplo, atributos del grupo de usuarios como proveedor de servicios inalámbricos, proveedor de correo electrónico) y/o interfaces de comunicaciones 125 (por ejemplo, Controlador / conmutador WiFi) y directorios 127 (por ejemplo, para recuperar listas de distribución, nombres de ubicaciones) por medio del adaptador de gestión 65 y la estructura de agentes 30 (tal como se describe más adelante en este documento) para obtener información sobre posibles receptores de transmisión de avisos. La consola 60, además, interconecta la estructura de agentes 30, por medio del adaptador de gestión 65, para crear el mensaje de aviso que se va a difundir, y para iniciar la difusión del aviso pasando un “paquete de difusión” que contiene el mensaje a los agentes correspondientes en la estructura de agentes 30, tal como se describe más adelante en el presente documento.
En concreto, la consola 60 se puede emplear para seleccionar o afectar a la prioridad operacional del sistema 10 con respecto a su manejo de difusiones de mensajes de aviso. Tal como se describe en el presente documento, el sistema 10 también puede incluir y realizar funciones generales de contenido y reenvío de usuarios y, tal como se describe a continuación, las prioridades operativas de dicha funcionalidad se pueden determinar por clases de servicio de usuario y otros parámetros de programación. Cuando se realiza la difusión de un aviso, un despachador que utiliza la consola 60 puede asignar a la tarea de difusión de avisos cualquier prioridad deseada para anular dicha programación, a fin de garantizar la entrega rápida de una difusión de aviso. Alternativamente, el sistema 10 puede estar preconfigurado para proporcionar a las difusiones de avisos la máxima prioridad, es decir, realizarlas primero con preferencia sobre las funciones generales de recuperación y entrega de contenido del usuario del sistema 10.
El sistema 10 puede incluir o proporcionar a través de la consola 60 un conjunto de plantillas u otras herramientas para permitir o ayudar a un despachador a construir un mensaje de aviso para su difusión utilizando el sistema 10. Las plantillas o herramientas pueden corresponder de diversas maneras con dispositivos de usuario de destino concretos de modo que, cuando se utiliza una plantilla o herramienta correspondiente, el contenido del mensaje de aviso podrá ser recibido y visualizado / ejecutado por ese dispositivo. Por ejemplo, una plantilla puede limitar el mensaje de aviso a textos de un número máximo de caracteres para garantizar que pueda ser recibido y visualizado por dispositivos capaces de recibir mensajes de SMS. Alternativamente, el sistema 10 puede emplear un agente de personalización de contenido 295, tal como se describe más adelante, para “adaptar” cualquier mensaje de aviso preparado y enviado por la consola 60 a la estructura de agentes 30 para que pueda ser recibido y visualizado / ejecutado por cualquier dispositivo de usuario de destino particular.
La funcionalidad de notificación 850 del sistema general 710 también se puede implementar en la consola de administración 60 o como un agente en la estructura de agentes 30 configurada para dicho propósito.
Componente del portal de autoadministración de servicios
El portal de autoadministración 70 es una aplicación web accesible a través de clientes de HTTP fijos o móviles que proporcionan a los abonados una forma de personalizar las capacidades de servicios para que se adapten a las fuentes de contenido que son importantes para ellos, y de formatear ese contenido para sus dispositivos particulares. El portal es independiente de las Id de servicio específicas e interactúa solo con la base de datos de usuarios 80 para leer los datos de usuario y almacenar cualquier modificación. Los abonados no tienen necesidad de conocer el ID de servicio específica en la que se procesa su cuenta.
La autenticación del abonado en el portal aprovecha los servicios de directorio en los que existe, tal como en una implementación de empresa o en un entorno de proveedor de servicios habilitado para LDAP. En dichos casos, el dominio, el nombre de usuario y la contraseña del abonado se utilizan no solo para autenticarse en el Portal, sino también para acceder a la fuente de contenido principal (normalmente un buzón de correo de empresa).
Una vez autenticados, los abonados reciben una interfaz de usuario que les permite ver el estado del acceso del servicio a cada una de sus fuentes de contenido, incluido cualquier estado de error persistente, la hora del último contenido reenviado, la cantidad de mensajes de contenido reenviados y otras estadísticas. También pueden agregar / eliminar fuentes de contenido, pueden modificar sus dispositivos móviles y pueden modificar la configuración de personalización de reenvío y formateo.
El portal de autoadministración 70 soporta, asimismo, la suscripción automática, si está habilitado por el escenario de implementación (es decir, si el agente de recuperación de directorio 570 (que se describe más adelante) está deshabilitado). En esta circunstancia, un abonado puede acceder al portal 70 de manera anónima, y puede completar un formulario de registro que requiere la identificación de una fuente de contenido principal (normalmente un buzón de correo de empresa) y un dispositivo de destino.
El portal de autoadministración 70 permite, además, a un abonado suscribirse a, y especificar cualquier parámetro relacionado con un servicio de transmisión de avisos del sistema 10. Por ejemplo, un abonado puede especificar dispositivos particulares en los que el abonado desea recibir avisos, o proporcionar cualquier otra especificación o selección que pueda utilizar el sistema cuando selecciona el abonado como destinatario de una emisión de aviso y envío de un mensaje de aviso al dispositivo o los dispositivos del abonado.
Componentes de la secuencia
El sistema ejecuta periódicamente varias secuencias (o pequeños programas de utilidad) para mantener la base de datos de usuarios 80 y proporcionar otras tareas administrativas. Estas secuencias de comandos incluyen las capacidades para:
cambiar el acuerdo de nivel de servicio de los usuarios cuyo intervalo de pago ha terminado (por ejemplo, cambiar de pagado a gratuito);
agregar y eliminar usuarios (solo suscripciones por lotes: los usuarios individuales son procesados en tiempo real); validar a los usuarios de un sistema de comercio electrónico externo (en un entorno de proveedor de servicios); realizar una copia de seguridad de la base de datos;
recorte los datos relacionados con las notificaciones (transacciones) de la base de datos; y
enviar mensajes no solicitados, por ejemplo:
a abonados de servicios gratuitos: por ejemplo, anuncios para el servicio pago;
a todos los abonados: por ejemplo, mensajes de estado que indican el procesamiento y las notificaciones realizadas por el servicio para ellos durante la última semana o mes;
a abonados específicos: anuncios para terceros;
a abonados vencidos: advirtiendo que su servicio pago está a punto de caducar y que el usuario será degradado a servicios gratuitos; y
para dar la bienvenida a nuevos usuarios.
Estructura colaborativa de agentes
La figura 2 muestra un diagrama esquemático que ilustra los componentes de la estructura de agentes 30, agentes del servicio que opera en la estructura 30, y varios de los componentes del sistema externos a la estructura que ya han sido introducido. La estructura de agentes 30 soporta dos formas de agentes: agentes de instancia única (singleton, en inglés) y agentes agrupados. Cualquier función que requiera un agente puede ser realizada por un agente de instancia única; sin embargo, en el sistema a modo de ejemplo, los agentes agrupados (que se describen más adelante) se utilizan normalmente para realizar funciones de servicio que se pueden escalar a través de múltiples actividades simultáneas, y los agentes de instancia única habitualmente proporcionan control de aplicaciones o acceso y administración de recursos restringidos (como los agentes agrupados).
Los agentes de instancia única que proporcionan control sobre los agentes agrupados hacen uso de las instalaciones de gestión de grupos de la estructura que soporta la creación, distribución de trabajo, verificación de la seguridad, destrucción y reencarnación (es decir, reactivación cuando se demora excesivamente en entregar un resultado) de los agentes agrupados. La estructura de agentes 30 proporciona la capacidad de gestionar el rendimiento y la escalabilidad mediante la gestión del grupo de agentes. Con referencia a la figura 3, el gestor de grupo 310 manipula el número de subprocesos proporcionados por un agente para realizar el trabajo. La función del gestor de grupo 310 es actuar como un puente al permitir que un grupo de agentes 320 tome el lugar de un solo agente, mientras se mantiene la misma interfaz que el agente único. Gestiona la delegación de eventos recibidos para los agentes agrupados 320, y responde normalmente a los eventos del agente reemplazado. Dichos eventos se procesan en paralelo a través del grupo de agentes.
El gestor de grupo 310 tiene parámetros operativos que limitan el número de agentes dentro de un grupo. El número mínimo de agentes (es decir, la marca de “nivel bajo de agentes” 330) es instanciada automáticamente tras la inicialización del grupo. El gestor de grupo 310 puede crear más agentes según sea necesario para gestionar las solicitudes entrantes, sujeto a la limitación del número máximo de agentes (es decir, la marca de “nivel alto de agentes” 340). En la descripción y las figuras, se puede hacer referencia alternativamente a un “agente agrupable” o al gestor de grupo de dichos agentes, pero se apreciará que cualquiera de las referencias incluye cualquier alternativa.
Con referencia de nuevo a la figura 2, la estructura de agentes 30 proporciona un sistema de mensajería Pizarra digital 210 para la interacción del agente. La estructura de agentes 30 también proporciona servicios de gestión de temporizadores que soportan la creación y destrucción de temporizadores, así como el manejo de los tiempos de espera. También proporciona servicios de registro para conectar el servicio al mecanismo de registro del sistema operativo del anfitrión. Finalmente, la estructura de agentes 30 proporciona un mecanismo para recibir comandos de inicio, apagado normal, apagado inmediato y verificación de la seguridad de una entidad externa (por ejemplo, el vigilante 40).
Las aplicaciones que se ejecutan dentro de la estructura de agentes 30 se desarrollan utilizando las interfaces definidas de la estructura, que requieren que las aplicaciones implementen interfaces conocidas para la inicialización, la destrucción y las verificaciones de la seguridad. Los agentes de servicio se integran en la estructura mediante la preconfiguración del agente de monitorización de servicio 220 o mediante una inyección externa del vigilante 40. El agente de monitorización de servicio 220 maneja el inicio, la detención y la verificación de la seguridad de los agentes de servicio en la solicitud del vigilante 40. Los agentes de servicio aprovechan las interfaces de Pizarra digital 210 para comunicaciones, temporizadores, gestión de grupos y registro.
Los agentes implementados utilizando la estructura de agentes 30 están diseñados para ser controlados por eventos, esperando recibir eventos (mensajes y eventos de temporizador), procesando cada uno hasta su finalización, esperando, a continuación, el próximo evento. Los agentes, habitualmente mantienen los datos de configuración persistentes en archivos de propiedades (archivos planos). Cuando se inicia el agente, inicializa todos sus valores de configuración desde su almacenamiento persistente y, a continuación, notifica que está listo para comenzar a procesar eventos. Cuando recibe un evento de apagado, escribirá cualquier dato de configuración nuevo en el almacenamiento persistente antes de apagarlo.
Los componentes de la estructura ahora se analizarán a continuación con mayor detalle.
Estructura Pizarra digital
La pizarra digital 210 es el servicio de mensajería para proporcionar mensajes entre los agentes. Los eventos se envían a la pizarra digital 210 desde cualquier agente y se envían a las colas de los agentes que se hayan registrado para recibir dichos eventos. Los agentes de recepción procesan las notificaciones en orden, hasta su finalización, como parte de su ciclo de eventos. Este mecanismo permite a los agentes publicar eventos específicos de mensajes de contenido enriquecido y solicitar notificación de la publicación de eventos específicos. Por ejemplo, un agente de trabajador que ha completado el trabajo podría publicar un mensaje de completar recuperación de contenido, y cualquier agente de aplicación en espera recibiría el mensaje.
Se proporcionan múltiples colas para que cada agente soporte mensajes de diferentes prioridades, con el número definido por los requisitos de la aplicación. El agente solo tiene una interfaz única para las colas: la pizarra digital 210 garantiza que los eventos de mayor prioridad se manejen antes que los mensajes de menor prioridad.
La pizarra digital 210 también es capaz de mover colas de mensajes entre instancias de agentes. Esto se realiza automáticamente cuando el agente de monitorización de servicio (SMA - Service Monitor Agent, en inglés) 220 considera que un agente es “no seguro”, tal como se describe a continuación. Después de crear un nuevo clon del agente, se le indica a la pizarra digital que entregue la cola de mensajes entrantes del original al nuevo agente. Gestión de la estructura
La estructura de agentes 30 proporciona un agente de supervisión de servicios (SMA) 220 para la gestión de aplicaciones. Proporciona el punto de acceso de inicio, estado y apagado para los agentes dentro de estructura de agentes 30. Los agentes se crean de diversas maneras mediante las propiedades de configuración de SMA 220, por medio de la inyección del vigilante 40 al SMA 220 (donde está la ruta al software del agente identificado), o mediante codificación en la lista de inicio de SMA 220. En el inicio de la estructura, el SMA 220 escucha una conexión del vigilante 40 para controlar el servicio y, una vez conectado, responde a los comandos del vigilante 40 para iniciar, detener y realizar un sondeo en los agentes.
Con referencia a la figura 3 y la figura 4, la última muestra un subconjunto de los agentes y los componentes del sistema implicados en la gestión de la estructura, el SMA 220 sondea a los agentes 230 gestionables (que representan a cualquiera de los agentes del servicio que se muestran en la figura 2) tras la solicitud del vigilante 40, para determinar si todos siguen activos y pueden procesar eventos. Si se detecta un fallo persistente de agente irrecuperable, el SMA 220 iniciará un cierre del servicio y notificará este evento al vigilante 40. Cuando recibe el comando, el SMA 220 inicia un cierre pidiendo a cada agente 230 que cierre (en su cola de mensajes de alta prioridad) y espera sus respuestas. Cualquier agente 230 que no responda dentro de un tiempo configurado es eliminado. Los datos se pueden perder si no se controla el apagado y el agente 230 tiene que ser terminado.
Si un solo agente se considera inseguro, la pizarra digital 210 retendrá mensajes para dicho agente hasta que la nueva instancia esté en funcionamiento. Se creará e inicializará una nueva instancia del agente. La cola del nuevo agente se completará con los mensajes recuperados del agente que se está desactivando a través de la pizarra digital 210.
Gestión del temporizador de la estructura
La estructura 30 proporciona a los agentes la capacidad de iniciar, detener y manejar las interrupciones de los temporizadores, utilizados, en general, para proporcionar servicios periódicos y recuperarse de problemas de la red. Una función de gestión de temporizadores de la estructura permite que un agente cliente cree cualquier número de temporizadores, que pueden ser de disparo único (un tiempo de espera) o repetitivos (comienza de nuevo después del primer tiempo de espera). Cuando un temporizador expira, vuelve a llamar a una interfaz que el agente proporciona a la instalación de administración del temporizador. Para mejorar la eficiencia de la utilización de la CPU, el agente especifica la resolución más baja del temporizador que se desea (la “longitud de la marca”). La instalación de gestión del temporizador puede minimizar el procesamiento en cada una de las interrupciones del temporizador a nivel del sistema, lo que permite temporizadores eficientes de alta y baja resolución.
Registro de la estructura
La estructura proporciona a los agentes una función de registro para registrar la actividad en los mecanismos del sistema operativo local o en un servidor central si se utilizan múltiples ID de servicio. Soporta la determinación del método de registro en tiempo de ejecución y ofrece un modelo de creación de instancias desde fábrica, donde los agentes pueden crear sus propias cabeceras de registro para identificar claramente el originador de cada registro. Adicionalmente, los registros de varias estructuras de agentes se pueden combinar y ubicar de forma centralizada si es necesario.
Componente vigilante
Operando como un “centinela” persistente dentro de cada servidor colaborador, el vigilante 40 se inicia y se detiene bajo el control del administrador y se reinicia automáticamente cuando se reinicia el servidor. El vigilante 40 garantiza la robustez del servicio manteniendo una conexión con el agente de monitorización de servicios 220 correspondiente que opera dentro de la estructura de agentes 30, ofreciendo recuperación de problemas con la estructura de agentes 30 que fueron imprevistos, tales como formatos inesperados de mensajes y/o problemas de red eso podría hacer que el sistema se ralentizase o se quedase sin memoria.
En una frecuencia sintonizable, el vigilante 40 solicita una verificación de la seguridad de la estructura, que devuelve un estado, por ejemplo, de rojo / amarillo / verde. Las aplicaciones de la estructura de agentes 30 determinan qué constituye una situación amarilla o roja, respondiendo al agente de monitorización de servicios 220 que, a su vez, responde al vigilante 40 con un resumen de los estados de las aplicaciones individuales. El vigilante 40 responde a los estados acumulativos reiniciando la estructura de agentes 30 si se devuelve un estado rojo, o en el caso de un número configurable de estados amarillos repetidos. También trata la falta de respuesta como un estado rojo, lo que obliga a reiniciar la estructura de agentes 30.
Adicionalmente, el vigilante 40 produce avisos para informar a los administradores sobre la recuperación automatizada de problemas y cuando es necesaria la asistencia del administrador. El vigilante 40 proporciona además una interfaz de consola para iniciar / detener / reiniciar manualmente el servicio y verificar su estado, aunque habitualmente los administradores interactúan con el vigilante 40 a través de una consola de administración específica de la aplicación.
Agente de gestión de servicios
El agente de administración (MA) 240 es responsable de gestionar todas las consultas de gestión en tiempo real desde el componente de adaptador de gestión 65 (es decir, desde la consola de administración 60). Puede solicitar que todos los agentes gestionables informen de su estado y puede enviar información a un agente específi ajustar la configuración mientras el sistema está activo. También escucha los errores críticos del sistema, tales como el fallo de conexión SMTP, e informa al adaptador de gestión 65 para que le notifique al administrador cuándo se produce dicho fallo.
El agente de gestión 240 procesa adicionalmente la información de difusión de avisos recibida desde la consola de administración 60 a través del adaptador de gestión 65. Específicamente, tal como se describe en relación con la realización general, el agente de gestión 240 puede recibir un paquete de mensajes de aviso que incluye un mensaje de aviso para la comunicación a los destinatarios previstos, y la información que identifica a dichos destinatarios, que también puede incluir direcciones del dispositivo o los dispositivos de comunicación de dichos destinatarios. El agente de gestión 240 se puede comunicar, a través de la pizarra blanca 210, con otros agentes en la estructura de agentes 30 para obtener más direcciones de dispositivos de destino, según sea necesario, para procesar el mensaje de aviso para tipos particulares de dispositivos de destino, para comunicar los mensajes de aviso procesados a los dispositivos de destino, y para recibir y procesar las respuestas recibidas de dichos dispositivos de destino o de otros.
Descripción general de aplicación de servicio
Con referencia de nuevo a la figura 2, la aplicación de servicio incluye una aplicación de servicio de contenido de red móvil que opera en la estructura de agentes 30, que consiste en un conjunto de tipos de agentes colaboradores: agentes de gestión (MA - Management Agents) 240, agentes de gestión de usuarios (UMA - User Management Agents, en inglés) 250, agentes de clase de servicio (CSA - Class of Service Agents, en inglés) 260, agentes de estado de usuario (USA - User Status Agents, en inglés 270, agentes de respuesta de difusión (BRA - Broadcast Response Agents, en inglés) 275, agentes de recuperación de contenido (CRA - Content Retrieval Agents, en inglés) 280, agentes de entrega de contenido (CDA - Content Delivery Agents, en inglés) 290, agentes de personalización de contenido (CPA - Content Personalization Agents, en inglés) 295 y agentes de difusión (BA -Broadcast Agents, en inglés) 297. (Los últimos cuatro se muestran como gestores de grupo correspondiente; tal como se explicó anteriormente, estos agentes son, preferiblemente, agentes agrupables para gestionar el rendimiento y la escalabilidad.) También se incluyen los agentes de servidor de claves (KSA - Key Server Agents, en inglés) 298, tal como se describe a continuación en el presente documento. Tal como se describe más adelante en el presente documento, estos agentes colaboran para proporcionar difusión en tiempo real de mensajes de aviso a una pluralidad de diversos dispositivos de usuario. También colaboran para proporcionar a los usuarios suscritos contenido de interés, accesible a través de la red, en sus dispositivos móviles, en un formato apropiado para el dispositivo en tiempo casi real.
El servicio se puede utilizar para transmitir un mensaje de aviso a una pluralidad de dispositivos móviles o fijos. Como en el caso del contenido renderizado, que se explica a continuación, el servicio puede emplear cualquier formato apropiado para el dispositivo. El servicio reenvía estos mensajes de aviso de difusión en tiempo real, iniciando la transmisión inmediatamente después de la recepción del mensaje.
El servicio puede ser utilizado, además, para enviar a un dispositivo móvil cualquier contenido accesible por el servidor en el que residen los agentes de servicio. Ejemplos son: correo electrónico desde buzones de correo de almacenamiento de correo; contenido del blog de fuentes de RSS (u otros métodos); contenido web de acceso WAP o HTTP (u otros métodos); contenido activo de Internet que requiere respuesta o autorización del usuario, por ejemplo, para el pago de un servicio o producto; datos textuales de consultas de bases de datos o consultas de arquitectura orientada a servicios (SOA - Service-Oriented Architecture, en inglés) (u otros métodos); y documentos, textos e imágenes de documentos de servidores de archivos y almacenes de documentos. El contenido se considera “de interés” si cumple con alguna de las preferencias configuradas del abonado, lo que implica filtrar los metadatos del contenido. Los ejemplos son el originador del contenido o una frase incluida en una “lista de permitidos” y no en una “lista de bloqueados” o, si el contenido aparece dentro de un período de tiempo específico o el contenido tiene un formato específico (por ejemplo, un mensaje de voz).
Cuando se procesa el contenido para reenviarlo a un dispositivo móvil, el servicio puede emplear cualquier formato apropiado para el dispositivo, incluyendo cualquier cosa, desde el asunto de un correo electrónico o el título de una publicación de blog hasta un documento completo de procesamiento de secuencia o un mensaje de voz o video, dependiendo de las capacidades del dispositivo móvil (por ejemplo, tamaño de pantalla, aplicaciones a bordo, canales de comunicación) y las preferencias del abonado. Puesto que los dispositivos móviles proporcionan, en general, un subconjunto de capacidades de escritorio, el formato preferido suele ser un resumen, una instantánea o una representación de menor resolución del contenido.
El servicio, preferiblemente, reenvía contenido “casi en tiempo real”, lo que significa que el servicio está sondeando las fuentes de contenido configuradas por el abonado a la velocidad dada en un acuerdo de nivel de servicio (SLA -Service Level Agreement, en inglés, que se describe más adelante en el presente documento), normalmente en la escala de minutos. Cuando se detecta contenido nuevo en cualquiera de las fuentes de contenido configuradas, se procesa de acuerdo con las preferencias del abonado y, si tiene garantías, se reenvía de forma apropiada al dispositivo móvil del abonado.
Además del sondeo, el servicio soporta el reenvío de abonados contenido, por ejemplo, para procesar el correo electrónico que llega a un buzón de correo al que no pueden acceder los protocolos POP3 o IMAP, o para procesar avisos de una solución que no proporciona acceso programático. Todo ese contenido llega a un “buzón de correo de reenvío”, uno para cada nivel del acuerdo de nivel de servicio, que a continuación, se sondea regularmente para obtener contenido nuevo. Asimismo, se proporciona un “buzón de correo de error” en todo el servicio para detectar los rebotes de mensajes y otros problemas de los dispositivos a los que se llega a través de SMTP. Este buzón de correo también es sondeado regularmente, y cualquier error analizable se procesa automáticamente y se agrega a los registros de la base de datos de abonados afectados para el tratamiento posterior de notificaciones de problemas.
Los componentes del servicio se describirán a continuación con mayor detalle.
Agente de clase de servicio del servicio
Con referencia de nuevo a la figura 2, y a la figura 5 que muestra los componentes del sistema implicados en la gestión de las cuentas de abonado, el agente de clase de servicio (COSA - Class-Of-Service Agent, en inglés) 260 controla el flujo entrante de trabajo al servicio y actúa como un punto de coordinación para la administración de la cuenta a medida que se procesa cada cuenta de abonado. No obstante, con respecto a la función de difusión de avisos del sistema, el COSA no necesita ser empleado ya que, cuando se realiza dicha funcionalidad, el despachador de mensajes de aviso, que opera a través de la consola de administración 60, puede gestionar y/o seleccionar las prioridades de comunicación que rigen la difusión de mensajes de aviso.
El sistema contempla que los usuarios se clasifiquen de acuerdo con un acuerdo de nivel de servicio (SLA); por ejemplo, algunos usuarios pueden recibir el servicio sin cargo, mientras que otros usuarios pagan una tarifa. El COSA programa el trabajo de la misma manera para todos los abonados en una clase de servicio específica de acuerdo con el SLA, pero, en general le da prioridad temporal y de procesamiento, por ejemplo, a abonados de pago sobre los abonados no de pago.
Cada abonado del servicio habrá identificado una o más fuentes de contenido que quiere enviar a su dispositivo móvil. El COSA programa el trabajo (una “transacción”) para cada fuente de contenido por separado. Se coordina con el agente de gestión de usuarios 250 para verificar la salida (es decir, reservar) una lista de fuentes de contenido que procesa (es decir, recupera contenido) simultáneamente. El algoritmo para verificar la salida de una fuente de contenido puede o no depender del abonado: en general, las fuentes de contenido de un solo abonado están programadas para su recuperación antes de que se consideren las fuentes de otro abonado, pero el COSA tiene información sobre cuántas transacciones de cada tipo de medio están activas, y puede aprovechar esto para mejorar la eficiencia general del procesamiento cuando se programan diferentes tipos de medios entre diferentes abonados, ya que intenta mantener el SLA de cada abonado.
La decisión del COSA de procesar una cuenta determinada en un momento determinado tiene en cuenta los siguientes factores:
1. la clase de servicio del abonado (es decir, premium, gratuito, etc.) y, por lo tanto, la prioridad del abonado;
2. la imparcialidad, de modo que todos los usuarios en un SLA específico reciben la misma frecuencia de sondeo, con la excepción de cuando una encuesta se demora más que la frecuencia de sondeo (en cuyo caso el sondeo de la cuenta comienza lo más pronto posible después del tiempo de espera del sondeo anterior);
3. el tipo de cuenta que se procesa: cuenta de abonado de sondeo, cuenta de reenvío compartido o cuenta de error (se describe a continuación en el presente documento); y
4. el volumen de mensajes actualmente en el sistema.
Si el sistema está demasiado ocupado, debido a factores tales como la detección de poca memoria, se recibe demasiado contenido del abonado (un buen indicador de poca memoria inminente), todos los agentes agrupados en uso, una situación de espera impuesta por el operador, etc., el COSA deja de programar nuevas transacciones hasta que la situación desaparece.
Hay cuatro fuentes de contenido de abonado “especiales” que el COSA debe procesar de formas particulares: una cuenta “reenviada”, una cuenta de “error”, cero o más cuentas de “respuesta de SMS / MMS” y una cuenta de “control remoto”. Estas pueden residir en cualquier servidor de mensajes accesible por el sistema. La cuenta “reenviada” identifica un buzón de correo del servicio con un nombre que los abonados identifican como una de sus fuentes de contenido. En este caso, cuando se recupera el nuevo correo electrónico para esta cuenta, el COSA separa el correo electrónico en “transacciones secundarias” individuales para cada abonado de origen encontrado, verificando la salida de cada abonado para cada transacción secundaria. (Los mensajes de reenviadores desconocidos son descartados). Las transacciones, que incluyen el conjunto de mensajes y los datos de usuario del abonado real, se envían al agente de personalización de contenido (CPA) 295 (y posteriormente al agente de entrega de contenido (CDA) 290 para la personalización) y la entrega, según corresponda. Cuando se completan todas las transacciones individuales, se cierra la transacción de la cuenta principal “reenviada”.
De manera similar, la cuenta “error” identifica otro buzón de correo del servicio con nombre que recibe errores de rebote de mensajes para notificaciones transmitidas por SMTP enviadas por el servicio. El COSA 260 recibe el nuevo mensaje de este buzón de correo del agente de recuperación de contenido (CRA) 280, identifica a los abonados afectados mediante la coincidencia de la dirección de correo electrónico del dispositivo en el correo electrónico de error. A continuación, el COSA 260 envía eventos de “transacción perdida” al agente de estado del usuario (USA - User Status Agent, en inglés) 270 por cada transmisión fallida, y el USA, a su vez, actualiza el estado de error de cada abonado.
De manera similar, la cuenta de “Respuesta de SMS / MMS” identifica uno o más buzones de correo de servicio con nombre que reciben respuestas a mensajes de dispositivos de abonados habilitados para SMS / MMS. Las respuestas de estos dispositivos se envían desde un controlador de puerta de enlace SMS / MMS (por ejemplo, una pequeña aplicación web que opera en el servidor de aplicaciones web 50 que recibe publicaciones desde la puerta de enlace del proveedor de servicios SMS / MMS 150 y los traduce al correo electrónico). Cuando el COSA recibe nuevos mensajes de este buzón de correo del CRA, extrae el índice de mensaje SMS del mensaje que fue respondido desde el correo, y el asunto y el texto de la respuesta del abonado de cada correo. Los índices de SMS se comparan con los registros de transacciones almacenados en la base de datos de usuarios, y el originador de contenido es recuperado del registro coincidente. A continuación, el COSA crea una transacción para el abonado y la reenvía al CDA para su entrega por mensajería electrónica al remitente original del mensaje.
De manera similar, la cuenta de “control remoto” identifica un buzón de correo de servicio con nombre que proporciona un canal de respuesta de abonado a servicio para el control remoto del servicio mientras es móvil. Esto puede estar soportado para dispositivos habilitados para correo electrónico directamente, y para dispositivos habilitados para SMS / MMS a través del mismo mecanismo utilizado por el método de respuesta de SMS / MMS. Cuando el COSA recupera un nuevo correo electrónico de este buzón de correo del CRA, extrae la dirección del dispositivo de origen, un comando y, opcionalmente, un identificador (por ejemplo, ID de SMS o asunto del correo electrónico). La dirección de origen se hace coincidir con una cuenta de abonado y, si está presente, el identificador se hace coincidir con una de las transacciones de abonado. Esta capacidad soporta comandos tales como: borrar el correo electrónico que se ha reenviado al dispositivo desde un buzón de correo;
solicitar el texto completo del contenido resumido que se reenviará;
selección de un dispositivo alternativo (cuando se han configurado previamente varios);
activar o desactivar la notificación del servicio.
Para los comandos que requieren acceso a un buzón de correo, el COSA origina una transacción para el abonado, anulando las preferencias normales del usuario contenidas en los datos del usuario. En caso contrario, COSA simplemente actualiza los datos de usuario en la memoria caché.
Por lo tanto, las responsabilidades estándar de COSA son:
determinar con qué frecuencia se sondean los buzones de correo de reenvío y de error en relación con la frecuencia de sondeo de las cuentas de abonados;
garantizar que cada cuenta de abonado se abre, procesa y cierra con éxito de acuerdo con el SLA;
reconocer la carga cambiante y adaptar la velocidad de programación a medida que los abonados apagan o activan la notificación, y a medida que se agregan nuevos abonados;
opcionalmente, limitar la cantidad máxima de mensajes reenviados y la cantidad máxima de bytes procesados por usuario y día;
opcionalmente, limitar la cantidad total de bytes procesados;
si un abonado está en modo de “notificación desactivada”, no enviar una solicitud a través del sistema, ya sea originada desde el procesamiento normal del abonado o desde el buzón de correo reenviado; y
manejar los errores encontrados durante el procesamiento de cada cuenta de abonado, permitiendo que el sistema se recupere adecuadamente.
Cuando los abonados configuran sus buzones de correo de reenvío de mensajes automáticamente a uno de varios buzones de correo comunales (uno por SLA) (en lugar de hacer que el servicio sondee el buzón de correo de abonados), las responsabilidades de COSA son:
ordenar los mensajes por nombre de usuario y tiempo recibido;
validar las identidades de los usuarios, filtrar cualquier correo no deseado y otros mensajes de no abonado; y agrupar mensajes por usuario y enviar cada conjunto de correo al gestor de grupos de agentes de personalización de contenido apropiado para su análisis y procesamiento.
Agente de gestión de usuarios de servicio
El agente de gestión de usuarios (UMA) 250, mostrado en las figuras 2 y 5, coordina todos los accesos por parte de los agentes de servicio a las cuentas de abonado dentro de la base de datos de usuarios 80. Proporciona una API que soporta los diversos tipos de consulta requeridos por los otros agentes, tales como agregar o eliminar abonados, verificar la existencia de un abonado en particular, hacer coincidir un nombre de abonado con su contraseña y la recuperación y el almacenamiento de objetos de datos de usuario que contienen toda la información requerida para procesar un abonado (detalles de la cuenta, fuentes de contenido, dispositivos móviles y preferencias de personalización).
Tal como se ilustra en la figura 5, el UMA guarda copias en la memoria caché 510, 520 de los datos de usuario 530 y los datos de la clase de servicio (COS - Class of Service, en inglés, es decir, SLA) 540, así como una memoria caché de mensajes 550 de mensajes de usuario final, en la base de datos de usuarios 80 a través de un controlador de memoria caché 560. El controlador de memoria caché 560 mantiene de forma independiente las memorias cachés 510, 520, 530 sincronizándolas periódicamente con la base de datos de usuarios 80. Para mayor eficiencia, el UMA 250 también guarda copias de solo lectura de los datos de usuario 530 para las cuentas de abonados que están en un estado de “reenvío” (es decir no los que han desactivado temporalmente el servicio). A medida que los datos de usuario 530 cambian del procesamiento de transacción, se vuelven a escribir en la memoria caché de datos de usuario 510, que, a continuación, se sincroniza con la base de datos de usuarios 80 en algún momento posterior. De manera similar, si la memoria caché de datos de usuarios 510 se actualiza desde la base de datos de usuarios 80, los cambios se propagan a las copias de solo lectura para la siguiente transacción del abonado.
El UMA 250, opcionalmente, colabora con un agente de recuperación de directorio (DRA) 570 opcional (que se explica con más detalle en el presente documento) con el fin de gestionar la población de abonados en la base de datos de usuarios 80. Si no se utiliza el DRA 570, la población de abonados en la base de datos de usuarios 80 se gestiona a través del portal de autoadministración 70.
El UMA 250 colabora con el COSA 260 para el propósito de programar el procesamiento del abonado estando listo para atender una solicitud para que el siguiente usuario procese desde la memoria caché de datos de usuario 510. La solicitud para el siguiente usuario podría especificarse como el siguiente usuario de un SLA especificado, como la cuenta de reenvío para un SLA específico, o como la cuenta de error para el sistema.
El UMA 250 colabora además con el COSA 260 para guardar representaciones coherentes de las fuentes de contenido de los abonados y actualizar dinámicamente información sobre el procesamiento de las cuentas de abonado, tal como el recuento de mensajes procesados, el número y tipo de errores encontrados, y el éxito / fracaso de cada ciclo de proceso (transacción), utilizado para propósitos de notificación. Las representaciones de las fuentes de contenido de los abonados implican, en general, tomar una instantánea del estado actual. Por ejemplo, una representación del estado del buzón de correo incluiría la fecha de llegada del último correo recibido en el momento del sondeo, y una representación del estado del blog incluiría la fecha de publicación del último mensaje en el momento del sondeo, y una representación del almacén de documentos incluiría la fecha del último documento actualizado en el momento del sondeo.
El UMA implementa la memoria caché de la base de datos descrita anteriormente por razones de eficiencia. La memoria caché se actualiza en un ciclo periódico y contiene los conjuntos de datos de usuario para cada nivel de SLA, los errores encontrados por abonado, los registros de transacciones, los parámetros para cada nivel de SLA y la lista de mensajes de notificación proporcionados a los abonados y administradores en condiciones de error. La memoria caché proporciona los siguientes métodos de acceso:
verificación de salida: leer los datos almacenados en la memoria caché y aplicar el bloqueo de escritura (no se permite una verificación adicional y no se permiten escrituras hasta que se registre el registro);
lectura: solo lectura sin bloqueo en los datos;
escritura: escritura de datos no relacionados con la transacción en la memoria caché (en cola si hay un bloqueo de escritura en su lugar);
registro: escritura en la memoria caché, eliminación del bloqueo de escritura y procesamiento de cualquier escritura en cola; y
actualización: escribir los datos almacenados en la memoria caché que se han cambiado en la base de datos y leer los nuevos datos proporcionados por fuentes externas (tales como el portal de autoadministración o la consola de administración).
Cuando se realiza su funcionalidad de difusión de avisos, el sistema 10 puede emplear el agente de gestión de usuarios 250 para recuperar de la base de datos 80 las direcciones de dispositivo de cualquier dispositivo de usuario abonado u otro dispositivo de usuario final. En particular, si un paquete de difusión de mensaje de aviso recibido por el agente de difusión 297 identifica los dispositivos de usuario final de destino, pero no especifica también la dirección del dispositivo de dicho usuario final, el agente de difusión 297 puede consultar la base de datos 80 a través del agente de gestión de usuarios 250 para dicha dirección.
Agente de recuperación de directorio de servicios
Tal como se indicó anteriormente, el servicio incluye, opcionalmente, un agente de recuperación de directorio (DRA) 570 para administrar la población de abonados. Accede periódicamente a un recurso de directorio de red 127 (por ejemplo, un servidor de directorio corporativo), opcionalmente a través de un canal encriptado, para monitorizar la membresía en una lista de distribución con nombre, a continuación, sincroniza la membresía de esa lista con los abonados que se encuentran en el agente de gestión de usuarios (UMA) 250, incluida cualquier información modificada, tal como el nombre de usuario, el nombre del buzón de correo y el servidor del buzón de correo.
Para encontrar la lista de distribución con nombre, el DRA 570 accede al servidor de directorio 127 (por ejemplo, a través del protocolo ligero de acceso a directorios) y realiza una búsqueda en la lista de miembros. Una vez que se encuentra la lista, se recorre para encontrar todos los miembros, incluidos los que están en listas de distribución anidadas. Se utiliza una profundidad máxima de anidación para evitar la posibilidad de que una lista de distribución anide una segunda lista de distribución que contenga la primera. Se realiza una verificación adicional para garantizar que no haya duplicación de miembros y que todos los atributos necesarios (nombre de usuario, nombre de buzón de correo y servidor de buzones de correo) estén presentes.
La sincronización de la lista de miembros con la lista de abonados se logra verificando la existencia de cada miembro en la base de datos de usuarios 80 (por medio del agente de gestión de usuarios 250). Si el miembro no está suscrito, es agregado a la base de datos de usuarios 80. Si el miembro ya está suscrito, los atributos del abonado se comparan con los atributos del directorio y se aplican actualizaciones, si es necesario. Si un abonado no está en la lista de miembros, se considera que no está suscrito, y se le solicita al agente de gestión de usuarios 250 que cambie el estado de la cuenta del abonado a no suscrito.
Cuando se realiza su funcionalidad de transmisión de avisos, el sistema 10 puede emplear el agente de recuperación de directorio 570 para recuperar de los directorios 127 las direcciones de dispositivo de cualquier dispositivo de usuario abonado u otro dispositivo de usuario final. En particular, si un paquete de difusión de mensajes de aviso recibido por el agente de difusión 297 identifica los dispositivos de usuario final de destino, pero no especifica también la dirección del dispositivo de dicho usuario final, el agente de difusión 297 puede consultar los directorios 127 por medio del agente de recuperación de directorios 570 para dicha dirección.
Agente de estado del usuario del servicio
El agente de estado del usuario (USA) 270 realiza un seguimiento del estado de la cuenta del abonado, guardando el estado de la cuenta del abonado en la base de datos de usuarios 80 para la monitorización administrativa y el aviso a los abonados de problemas persistentes experimentados con su cuenta de servicio. También es responsable de extraer la información del abonado de los mensajes de rebote / fallo recuperados del buzón de correo de error del sistema.
El USA recibe eventos de todos los agentes de procesamiento de transacciones en la aplicación (agente de recuperación de contenido 280, agente de personalización de contenido 295 y agente de entrega de contenido 290) para la indicación de actualizaciones de estado de transacción del abonado. Las responsabilidades específicas son: actualiza el estado del abonado después de que se haya recuperado el contenido, después de que se haya entregado el contenido y cada vez que se pierden las transacciones;
decide cuándo determinados abonados están en estado de error en base a los parámetros del acuerdo de nivel de servicio y los eventos de estado;
elimina a los abonados del estado de error una vez se han cumplido las condiciones del acuerdo de nivel de servicio; informa a los abonados mediante el envío de notificaciones (mensajes de correo electrónico) acerca de los problemas encontrados al procesar su correo electrónico; y
monitoriza las transacciones de la cuenta del abonado y escribe las transacciones cerradas en la base de datos. Agentes de recuperación de contenido de servicio
El agente de recuperación de contenido (CRA) 280 es un objeto que puede ser agrupado. Cuando se le proporciona una descripción de la fuente de contenido de un abonado, envía un agente agrupado apropiado para el tipo de contenido multimedia. Por ejemplo, una fuente de buzón de correo es atendida por un agente agrupado de recuperación de correo electrónico, mientras que una fuente de contenido web puede ser atendida por un agente agrupado de recuperación de RSS.
El agente agrupado se conecta a la fuente de contenido de ese abonado y descarga cualquier contenido nuevo que aún no haya visto, lo que, en general, significa contenido que ha aparecido desde el último sondeo. El método para realizarlo es diferente entre los diferentes tipos de contenido y los protocolos de acceso estándar / patentados, de ahí la necesidad de agentes agrupados específicos de los medios. Una vez completada la recuperación, el CRA 280 crea una matriz de elementos de contenido y los devuelve al agente de clase de servicio 260 para su posterior procesamiento. Por ejemplo, el CRA recibe la información del buzón de correo de un abonado del agente de clase de servicio 260. Utiliza esta información para conectarse mediante un protocolo de recuperación de correo electrónico (tal como IMAP o POP3 seguro, o un método patentado tal como MAPI de Microsoft) al servidor de correo remoto (por ejemplo, almacenes de correo de Internet 120 que se muestra en la figura 1) y, a continuación, descarga el correo electrónico que ha llegado más tarde que el momento del sondeo anterior desde la bandeja de entrada del abonado (u otra carpeta). (Nota: para la recuperación de POP3, se debe descargar y filtrar toda la carpeta de correo para encontrar los nuevos mensajes.) Todo el contenido se deja intacto en el servidor.
Por lo tanto, las responsabilidades del CRA estándar son:
asignar un agente agrupado apropiado para el tipo de contenido;
conectarse a fuentes de contenido de abonados, para identificar contenido recién llegado comparándolo con resultados de encuestas anteriores;
capturar el nuevo estado de la fuente de contenido, para enviar el resultado del procesamiento al COSA; y enviar un mensaje de estado de recuperación al agente de estado del usuario.
Para los abonados que seleccionan una fuente de contenido de correo electrónico reenviado (en la que acuerdan enviar el correo electrónico a un buzón de correo de servicio designado), la solicitud del COSA al c Ra incluye la información de la cuenta del buzón de correo compartido (es decir, como un abonado “especial”). El agente agrupado de correo electrónico de CRA recopila todo este correo, lo elimina del buzón de correo de servicio designado y lo devuelve al COSA para el procesamiento “reenviado”. Se utiliza un enfoque similar para el buzón de correo de “error”, donde la información de la cuenta del buzón de correo de error del servicio (es decir, como otro abonado “especial”) se procesa y se devuelve al COSA para el procesamiento de “error”.
Por lo tanto, las responsabilidades del CRA en estas situaciones son:
conectarse al buzón de correo comunal; recuperar todos los mensajes reenviados o de error y eliminarlos del servidor;
obtener el remitente original (o la dirección del dispositivo móvil) de los cuerpos de mensajes; y
enviar los resultados del procesamiento al COSA.
Se apreciará que, a medida que están disponibles nuevos tipos de contenido, tipos de medios y fuentes de contenido, el servicio puede actualizarse dinámicamente simplemente mediante la especificación y provisión de nuevos agentes de recuperación de contenido configurados para procesar dichas nuevas fuentes. En particular, la estructura del agente es extensible para operar dichos nuevos agentes de recuperación de contenido para recuperar contenido de las nuevas fuentes. En consecuencia, el resto del sistema puede permanecer ignorante e indiferente a los medios mediante los cuales se recupera el contenido de la red para su procesamiento y reenvío a los dispositivos móviles; incluso cuando se introduce un nuevo agente de recuperación de contenido, se pueden utilizar los mismos agentes de personalización de contenido y agentes de entrega de contenido.
En general, el agente de recuperación de contenido 280 no necesita ser utilizado en relación con la funcionalidad de transmisión de avisos del sistema, en la medida en que el contenido del despachador proporciona un mensaje de aviso a través de la consola de administración 60, tal como se describe en este documento. No obstante, se contempla que el agente de recuperación de contenido 280 se puede utilizar para proporcionar la funcionalidad de transmisión de avisos del sistema 10. Por ejemplo, el mensaje de aviso puede ser construido por el despachador para incorporar cierto contenido a recuperar de una fuente externa (por ejemplo, una imagen gráfica que muestra un mapa de una zona afectada, o una ruta de escape segura, o un archivo de audio que contiene un anuncio policial). En dicho caso, el agente de difusión 297, que se describe más adelante, puede emplear el agente de recuperación de contenido 280 para obtener dicho contenido de origen externo para su incorporación al mensaje de aviso antes de comunicar el mensaje al dispositivo de usuario de destino. En general, el agente de recuperación de contenido 280 se puede emplear normalmente como un medio para obtener contenido de cualquier fuente accesible por el sistema 10.
Agentes de personalización de contenido de servicio
El agente de personalización de contenido (CPA) 295 es un objeto que puede ser agrupado para aplicar las preferencias del usuario para filtrar y formatear contenido fuente. Cuando se le proporciona contenido de un abonado de una fuente específica del agente de recuperación de contenido 280 a través del agente de clase de servicio 260, el CPA despacha un agente agrupado apropiado para el tipo de contenido multimedia. Por ejemplo, una fuente de buzón de correo es atendida por un agente agrupado compatible con el correo electrónico, mientras que una fuente de contenido web o aviso de servicio puede ser atendida por un agente agrupado compatible con HTML. El CPA procesa el conjunto de contenido y crea una nueva matriz de contenido dependiente del dispositivo que se entregará al dispositivo del abonado. Una vez que ha terminado de procesarlo, reemplaza el conjunto de contenido recuperado en el objeto carga útil con la matriz de contenido que se reenviará. La carga útil se reenvía al agente de entrega de contenido 290.
El CPA realiza dos funciones generales: determinar si un elemento de contenido específico puede ser reenviado, y formatear el contenido para su presentación en el dispositivo. Determinar si un mensaje puede ser reenviado se implementa en varias etapas. En primer lugar, la dirección de origen se compara (con un soporte comodín) contra una “lista blanca de direcciones”, en la que una coincidencia indica que el contenido debe ser reenviado. Si la “lista blanca de direcciones” está vacía, la coincidencia se considera verdadera. Si no se encuentra ninguna coincidencia, el texto del contenido (por ejemplo, asunto, secuencia del cuerpo, títulos de los archivos adjuntos y, opcionalmente, secuencia y metadatos del archivo adjunto) se compara con comodines en una “lista blanca de frases”. Si no se encuentra ninguna coincidencia, se considera que el contenido no puede ser reenviado. Si se encuentra una coincidencia, la dirección de origen se compara con una “lista negra de direcciones” (de nuevo con compatibilidad con comodines), y el texto del contenido se compara con una “lista negra de frases”. Si ocurre una coincidencia en cualquiera de las listas negras, se considera que el contenido no puede ser reenviado. De lo contrario, se reenviará al dispositivo. Estos métodos de filtrado son extensibles de varias maneras. Por ejemplo, las listas blancas y las listas negras pueden ser complementadas con listas de todo el servicio proporcionadas por un oficial de cumplimiento corporativo, o podrían ser proporcionadas en forma de coincidencias de categoría, donde el CPA coincide con las listas de palabras o los filtros bayesianos si los datos del usuario lo especifican, o incluso listas blancas y listas negras proporcionadas en servidores de directorio centralizados (por ejemplo, la lista de contactos de un abonado en el directorio corporativo).
Si el contenido puede ser reenviado, el CPA lo formatea para su presentación en el dispositivo. El resultado formateado puede consistir, de diversas maneras, dependiendo de las capacidades del dispositivo, de las capacidades del canal y de la preferencia del usuario, de cualquiera de los siguientes conjuntos limitados de ejemplos:
todo el contenido (incluidos los archivos adjuntos);
solo el texto pasivo o activo extraído del contenido;
un resumen del texto del contenido;
traducciones de texto del contenido (o de resúmenes del contenido);
una lista de cualquier nombre de archivo adjunto;
varias URL que apuntan a un servidor que proporciona representación móvil de archivos adjuntos;
resúmenes de archivos de texto adjuntos;
traducciones de archivos adjuntos (o de resúmenes de archivos adjuntos);
versiones de imágenes de menor definición, por ejemplo, en archivos adjuntos; y/o
porciones extraídas del contenido o archivos adjuntos (por ejemplo, primeros N bytes / N segundos de una transmisión de medios).
Además, el CPA puede filtrar todo o parte del contenido de la red de acuerdo con las preferencias del usuario o de otra manera.
Después de que el contenido es procesado, el CPA 295 reenvía la recopilación junto con los datos del usuario al agente de entrega de contenido 290 para su entrega si es necesario.
Se apreciará que, a medida que estén disponibles nuevos contenidos y tipos de medios, así como nuevos métodos de procesamiento o personalización de dicho contenido, el servicio puede ser actualizado dinámicamente simplemente mediante la especificación y provisión de nuevos agentes de personalización de contenido configurados para realizar dicho procesamiento o personalización. En particular, la estructura del agente es extensible para operar dichos nuevos agentes de personalización de contenido. En consecuencia, el resto del sistema puede permanecer ignorante e indiferente a los medios por los cuales el contenido de red recuperado es procesado para reenviarlo a los dispositivos móviles; incluso cuando se introduce un nuevo agente de personalización de contenido, se pueden utilizar los mismos agentes de recuperación de contenido y agentes de entrega de contenido.
Cuando se realiza su funcionalidad de transmisión de avisos, el sistema 10 puede ser configurado de modo que, cuando se prepara el mensaje de aviso y el paquete de difusión, el despachador utilizando la consola de administración 60, selecciona el formato del mensaje de aviso con la ayuda de plantillas de mensajes que limitan o predeterminan el contenido y la forma del mensaje de aviso para que sea adecuado para la comunicación y visualización / rendimiento en un tipo de dispositivo de usuario / de destino relacionado. Dichas plantillas pueden ser tan simples como que especifican que el mensaje de aviso puede ser solo texto, por ejemplo, de un número limitado de caracteres. En dicho caso, el sistema 10 no necesita emplear el agente de personalización de contenido 295. Alternativamente, un mensaje de aviso recibido de la consola de administración 60 puede ser procesado, a petición del agente de difusión 297 o, en caso contrario, por el agente de personalización de contenido 295, para hacer, por ejemplo, que el mensaje sea visualizable / ejecutable en un dispositivo de usuario de destino determinado, o adecuado al contexto para la ubicación lógica o física de un dispositivo de usuario de destino. Cualquiera de las funciones descritas anteriormente en relación con la funcionalidad de recuperación y reenvío de contenido del sistema puede ser empleada para tal propósito.
Agentes de entrega de contenido de servicio
El agente de entrega de contenido (CDA) 290 es un agente que puede ser agrupado. Su función es reenviar el contenido procesado a los dispositivos de los abonados. Con la recepción de una carga útil de contenido procesado del agente de personalización de contenido 295, el CDA 290 envía un agente agrupado apropiado para el tipo de canal disponible para llegar al dispositivo (correo electrónico, correo electrónico de transmisión directa (push e-mail, en inglés), SMS, MMS, propietario, etc.) El agente agrupado determina la dirección del dispositivo (y otros parámetros de protocolo) a partir de los datos de usuario enviados junto con el contenido. A continuación, envía el contenido procesado al dispositivo. Por ejemplo, un dispositivo habilitado para correo electrónico recibe el contenido a través de una puerta de enlace de SMTP (por ejemplo, un MTA de SMTP 140 tal como se muestra en la figura 1), y un dispositivo habilitado para SMS recibe el contenido a través de una puerta de enlace de SMS (por ejemplo, una puerta de enlace de SMS 150 del proveedor de servicios, también como se muestra en la figura 1). El CDA 290 observa los detalles pertinentes, tales como la dirección del originador del contenido y, si corresponde, el ID de SMS para almacenar en el registro de la transacción que es almacenada en la base de datos de usuarios 80. (Esto es utilizado por el mecanismo de cuenta de “respuesta de SMS / MMS”.)
Cuando el contenido procesado se envía al dispositivo de un abonado, las direcciones “de” y/o “responder a” se configuran como las del remitente original, según corresponda. Por ejemplo, con el reenvío de correo electrónico, esto le permite al abonado responder al originador directamente desde su dispositivo. Para el ejemplo en el que el correo electrónico se reenvía a través desde una puerta de enlace de SMS, la dirección de respuesta se asigna a uno de un conjunto de direcciones de SMS específicas que reenvían la respuesta recibida junto con la dirección de SMS del dispositivo a uno de un conjunto de buzones de correo especiales para respuestas. Estos buzones de correo son atendidos por cuentas especiales de abonado de “SMS / MMS respuesta” en el servicio, en los que las respuestas son recuperadas y, a continuación, emparejadas al abonado y reenviadas al creador por el agente de clase de servicio (COSA).
Cuando el contenido personalizado es demasiado grande para un mensaje de dispositivo individual (por ejemplo, para SMS, un mensaje tiene solo aproximadamente 150 caracteres, o aproximadamente 15 palabras), el contenido puede ser enviado en varios mensajes, sujeto a la personalización del usuario en la definición del dispositivo. Los ejemplos de personalización incluyen el tamaño máximo del mensaje, el número máximo de mensajes separados y si el contenido debe ser truncarse o no para caber.
Las respuestas de error del dispositivo se manejan de manera específica para el protocolo. Los protocolos tales como SMS y correo electrónico pueden experimentar errores inmediatos o retardados. Los errores inmediatos son manejados intentando la entrega a un dispositivo alternativo si uno está configurado (lo que requiere un manejo especial de errores por parte del COSA si el dispositivo alternativo tiene un canal de entrega diferente), o mediante el inicio inmediato de un mensaje de “transacción perdida” al agente de estado de usuario, o marcando de nuevo la transacción como fallida, al COSA. Errores retardados, por ejemplo, los causados por un rebote de correo electrónico o un dispositivo inaccesible durante varias horas, son manejados mediante el método de cuenta de abonado de “error”.
La entrega segura de contenido al dispositivo móvil se consigue de una manera específica de protocolo. Para dispositivos habilitados para correo electrónico, si el dispositivo soporta correo electrónico encriptado, el abonado proporciona su clave pública al servicio tras la identificación del dispositivo móvil, y al mismo tiempo recibe la clave pública del servicio del proceso de suscripción. (Un correo electrónico no encriptado contiene La clave se envía al dispositivo.) Cuando se entrega el contenido, el CDA encripta el correo. Para dispositivos habilitados para SMS o MMS, se utiliza un mecanismo similar, pero se requiere un complemento de cliente específico en el dispositivo. Este complemento también permite la concatenación de múltiples mensajes juntos para formar un mensaje más grande de lo que de otro modo se permitiría dado el pequeño tamaño de los mensajes de SMS. En este caso, el CDA encripta todo el contenido personalizado, enviándolo en partes al dispositivo, donde cada parte está etiquetada secuencialmente para que el complemento lo analice. Después de recibir todas las partes, el complemento desencripta el mensaje para mostrarlo al abonado.
Este complemento de dispositivo se puede utilizar para proporcionar una funcionalidad adicional, tal como reconocer “etiquetas activas” que identifican el número de teléfono o el identificador de chat de mensajes instantáneos del originador del mensaje. Las etiquetas activas también se pueden utilizar para activar una acción de utilización, tal como el pago de un producto o servicio. Para dispositivos habilitados con dicho complemento, el CDA adjunta la etiqueta o etiquetas apropiadas para el originador si coincide con una en una lista de contactos personales incluida en los datos de usuario proporcionados por el COSA. Cuando el complemento detecta la presencia de una de estas etiquetas, permitiría al abonado iniciar una llamada de voz o chat de mensajería instantánea con solo presionar un botón mientras lee el contenido reenviado.
Se apreciará que, puesto que las capacidades de los dispositivos móviles los dispositivos evolucionan y, a medida que los modos de comunicación cambian, el servicio se puede actualizar dinámicamente de una manera fácil, mediante la especificación y la provisión de nuevos agentes de entrega de contenido configurados para realizar dicha entrega. Particularmente, la estructura del agente es extensible para operar dichos nuevos agentes de entrega de contenido. En consecuencia, el resto del sistema puede permanecer ignorante e indiferente a los medios por los cuales el contenido de red recuperado y procesado es reenviado a los dispositivos móviles; incluso cuando se introduce un nuevo agente de entrega de contenido, se pueden utilizar los mismos agentes de recuperación de contenido y agentes de personalización de contenido.
Cuando se realizar la difusión de avisos, el sistema 10 puede emplear el agente de entrega de contenido 290 tal como se describió anteriormente, donde, por ejemplo, el agente de difusión 297 entrega un mensaje de aviso (que puede haber sido procesado por el agente de personalización de contenido 295, tal como se describió anteriormente) al agente de entrega de contenido 290 para comunicación con los dispositivos del usuario de destino. Alternativamente, y tal como se explica a continuación, el agente de entrega de contenido 290 no necesita ser utilizado para dicho propósito, y el mensaje de aviso puede ser comunicado a los dispositivos de usuario objetivo de otra manera (por ejemplo, por un agente de difusión 297 generado para dicho propósito).
Agentes de difusión de servicio
El agente de difusión (BA) 297 es un agente que puede ser agrupado. En general, el agente de difusión 297 puede estar configurado para realizar la totalidad o una parte de la funcionalidad del módulo de entrega 730 del sistema general 710. Su función es entregar mensajes de aviso de difusión a los dispositivos de destino. Con la recepción de una carga útil de mensajes desde la consola de administración 60 a través del adaptador de gestión 65 y del agente de administración 240, tal como se describió anteriormente, el BA 297 puede recuperar las direcciones del dispositivo de destino de la información enviada junto con el contenido del mensaje. Estas direcciones se recuperan de manera diversa del agente de administración de usuarios 250, del agente de recuperación de directorio 570, o directamente de un equipo de red local (tal como un controlador de WiFi), tal como se describió anteriormente en este documento. A continuación, el BA 297 pasa el mensaje y las direcciones de los dispositivos de destino a los conjuntos de agentes agrupados que gestiona. En una realización en la que la funcionalidad de los submódulos de entrega 800, 810, 820, 830, 860 específicos del sistema general 710 se implementa en el BA, se activan varios subtipos diferentes de agentes agrupados para comunicarse con cualquier dispositivo en particular en base al protocolo o la ruta de comunicación requerida para llegar a ese dispositivo, por ejemplo, SMS, MMS, SMTP, IP (propietario), voz (propietario / VolP). Por ejemplo, una pequeña cantidad de agentes agrupados con capacidad de SMTP pueden llegar a una gran cantidad de dispositivos accesibles mediante correo electrónico, mientras que una gran cantidad de agentes agrupados con capacidad de IP se utilizarían para alcanzar una gran cantidad de dispositivos accesibles con WiFi. Alternativamente, tal como se describió anteriormente, el BA 297 puede contratar al agente de entrega de contenido 290 para reenviar el mensaje de aviso a los dispositivos de destino especificados.
De manera similar, el agente de respuesta de difusión 275 también es un agente que puede ser agrupado. El agente de respuesta de difusión 275 puede implementar la totalidad o una parte de la funcionalidad del gestor de respuestas 760 del sistema general 710. Alternativamente, dicha funcionalidad puede ser implementada de diversas maneras en otros agentes y se describe a continuación en el presente documento.
Cuando un mensaje de aviso a difundir es recibido por el BA 297, recupera las direcciones de los dispositivos de destino de los destinatarios. Los destinatarios se especifican de varias maneras, por ejemplo, mediante atributos dentro de la base de datos de servicios 80 (por ejemplo, el ID del servicio, el operador inalámbrico utilizado, el dominio de origen del correo electrónico, etc.); mediante atributos dentro de un directorio 127 (por ejemplo, un directorio corporativo que proporciona ubicación, pertenencia a una lista de distribución, etc.); mediante asociaciones en una infraestructura de red (por ejemplo, accesible a través de las interfaces de comunicaciones 125, tales como una asociación con un punto de acceso, pertenencia a un dominio, etc.). Para los atributos relacionados con la base de datos, el BA 297 puede solicitar la lista de direcciones del abonado de destino (direcciones de correo electrónico y/o direcciones IP y/o nombres de anfitrión y/o direcciones MAC y/o números de teléfono que pueden ser resueltos con DNS) al agente de gestión de usuarios (UMA) 250. Esta lista puede incluir opcionalmente prioridades de dispositivo especificadas por el abonado, que el BA 297 puede utilizar para determinar a qué dispositivos apuntar para cada abonado. Para los atributos basados en el directorio, el BA 297 puede solicitar la lista de direcciones (nombres de anfitrión y/o direcciones de correo electrónico y/o números de teléfono) de un directorio 127. Para los atributos asociados a la red, el BA 297 solicita la lista de direcciones (direcciones IP y/o nombres de anfitrión) de un directorio 127 y/o Interfaces de comunicaciones 125 (por ejemplo, controladores de la red inalámbrica). Esto puede incluir una solicitud de asignación de direcciones MAC recibidas del UMA 250 en la dirección IP asignada actualmente.
El BA 297 también puede combinar atributos para determinar las direcciones del dispositivo de destino. Por ejemplo, un mensaje de aviso de difusión puede estar dirigido a los dispositivos de SMS de todos los abonados cuyas direcciones MAC de dispositivo grabadas están asociadas con un conjunto específico de puntos de acceso WiFi. En tal caso, el BA 297 haría coincidir las direcciones MAC para los puntos de acceso dados recuperados de un controlador LAN inalámbrico, con las direcciones MAC asociadas con los datos de abonado devueltos desde el UMA 250, para determinar la lista de direcciones de SMS a las que están dirigidos.
Lo siguiente proporciona detalles de la funcionalidad del agente de difusión 297 cuando implementa la funcionalidad de los submódulos de entrega 800, 810, 820, 830, 860 del sistema general 710, en lugar de emplear el agente de entrega de contenido 290, tal como se describió anteriormente.
Para la entrega a direcciones de correo electrónico, el BA 297 proporciona el conjunto completo de direcciones de correo electrónico de destino a un único agente agrupado compatible con SMTP. Este agente agrupado de SMTP puede dividir la lista grande de manera uniforme en varias listas más pequeñas, en base a un tamaño máximo de lista configurado localmente y, a continuación, inicia un correo electrónico al MTA local (puerta de enlace de correo electrónico), realizando una copia oculta a cada uno de los destinatarios en las listas más pequeñas. A continuación, el MTA transfiere el correo electrónico al correo electrónico de destino de la manera más eficiente posible en base al número de transferencias simultáneas habilitadas en el MTA. El agente agrupado enumera el éxito / fracaso para cada entrega de dirección de correo electrónico en un informe al agente de gestión 240 una vez finalizado. En otra realización, el agente de respuesta de difusión 275 puede recibir u obtener mensajes de correo electrónico de respuesta de los dispositivos de destino para informar al agente de gestión 240.
Para la entrega a direcciones SMS / MMS, el BA 297 divide la lista de números de teléfono específicos en listas más pequeñas por operador, cada una de hasta un tamaño máximo configurado. Estas listas más pequeñas se dividen entre los agentes agrupados con capacidad de SMS / MMS disponibles, hasta un máximo configurado. (Dicho máximo permite la opción de transmitir una multiplicidad de mensajes de aviso diferentes de manera simultánea). A continuación, cada agente agrupado inicia una conexión a la puerta de enlace del operador (por ejemplo, las puertas de enlace del proveedor de servicios SMS / MMS 150) e inicia la transferencia de los mensajes. La transferencia se puede realizar en base a las características previamente conocidas de la capacidad de manejo del tráfico de la puerta de enlace del operador. El agente agrupado enumera el éxito / fracaso de cada entrega de SMS / MMS en un informe al agente de gestión 240, periódicamente si la entrega se realiza durante un período de tiempo prolongado y tras la finalización. En una realización, el agente de respuesta de difusión 275 está configurado para recibir mensajes SMS / MMS de respuesta de los dispositivos de usuario objetivo para informar al agente de gestión 240.
Para la entrega por voz a dispositivos basados en telefonía, el BA 297 divide la lista grande de manera uniforme en un número preconfigurado de agentes agrupados disponibles con capacidad de marcado, por ejemplo, un agente por cada marcador, hasta un máximo configurado para permitir transmisiones simultáneas. A continuación, estos agentes agrupados solicitan sus marcadores externos preconfigurados (por ejemplo, en las interfaces de comunicaciones 125) para iniciar llamadas de voz salientes a través de enlaces troncales o conexiones de VoIP (SIP), utilizando una carga útil de mensajes codificados por voz. A continuación, el marcador llama a cada destinatario, transcodifica el mensaje de voz a los usuarios finales cuando se responde a cada llamada. El marcador opcionalmente puede aprovechar los receptores de DTMF para permitir que los destinatarios confirmen la recepción. El agente de marcación enumera el éxito / fracaso de cada llamada en un informe al agente agrupado tras la finalización. A continuación, el agente agrupado devuelve este informe al agente de gestión 240. En otra realización, el agente de respuesta de difusión 275 recibe información del marcador que indica éxito / fallo para cada llamada e informa de lo mismo al agente de gestión 240.
Para la entrega a dispositivos de la red IP, el BA 297 divide la lista de direcciones IP y/o nombres de anfitrión de manera uniforme entre los agentes agrupados disponibles con capacidad de IP, de nuevo hasta un máximo configurado para garantizar el soporte de múltiples difusiones simultáneas. En el caso de que el sistema emplee la autenticación de mensajes de aviso, el BA 297, en primer lugar, solicita una etiqueta y una clave privada al agente del servidor de claves 298, y utiliza la clave para encriptar una parte del mensaje, que puede ser la hora actual. La etiqueta y el tiempo encriptado son pasados junto con el mensaje, los archivos adjuntos y la lista de direcciones de destino a los agentes agrupados. A continuación, los agentes agrupados intentan conectarse a cada dispositivo de IP a su vez en un puerto bien conocido, esperando una respuesta durante un tiempo configurado. Cuando un dispositivo acepta la conexión, el agente agrupado transfiere la carga útil del mensaje, cierra la conexión e inicia una conexión con el siguiente dispositivo de su lista. Para cualquier dispositivo inalcanzable, el agente agrupado vuelve a intentar la conexión un número configurable de veces antes de darse por vencido. Esto es en caso de que el dispositivo entre y salga de una zona inalámbrica específica o, de lo contrario, no pueda responder temporalmente. El agente agrupado enumera el éxito / fracaso de cada dispositivo en red en un informe al agente de gestión 240 tras la finalización. En otra realización, el agente de respuesta de difusión 275 recibe información de los dispositivos de destino o de los nodos o interfaces de comunicaciones intermedias que indican éxito / fallo para cada intento de comunicación, y lo notifica al agente de gestión 240.
El agente residente en los dispositivos en la red de IP puede estar preconfigurado para iniciarse cuando se inicia el sistema operativo del dispositivo, y preferiblemente, está configurado para escuchar en un puerto conocido las conexiones entrantes. Cuando se recupera una carga útil de mensajes del BA 297, el agente del dispositivo inicia una conexión de IP con el agente del servidor de claves 298 preconfigurado (se explica con más detalle, a continuación) y pasa la etiqueta proporcionada por el agente agrupado BA 297. El agente del servidor de claves 298 responde con una clave pública, que el agente del dispositivo utiliza para desencriptar la marca de tiempo del mensaje. Si la marca de tiempo es desencriptada con éxito y se encuentra dentro de una ventana preconfigurada de la hora actual en el dispositivo, el agente del dispositivo muestra el mensaje al usuario, opcionalmente con una campana o tono de advertencia. Este mecanismo está destinado a rechazar la inhabilitación, la reproducción y la dirección de ataques de suplantación de identidad.
Este método de clave pública se puede utilizar para cualquier dispositivo habilitado para redes de datos, incluidos teléfonos inteligentes, teléfonos inalámbricos locales, PC móviles / no móviles, etc. Otros dispositivos (tales como los teléfonos móviles solo con SMS / MMS) pueden ser protegidos en un nivel inferior mediante la preconfiguración de teclas simétricas (o una lista de teclas simétricas para ser utilizadas en orden). En este caso, el agente residente en el dispositivo desencriptaría la marca de tiempo del mensaje utilizando la clave almacenada localmente en lugar de solicitar la clave del agente de servidor de claves 298. Como en el caso de la clave pública, la marca de tiempo se compararía, a continuación, con el tiempo del dispositivo local, y el mensaje solo se mostrará si el tiempo coincide dentro de una ventana configurada. Los dispositivos sin un agente proporcionarán el mensaje al usuario final sin ninguna autenticación.
Tenga en cuenta que cada agente agrupado se puede implementar de una manera específica de protocolo tal como se describió anteriormente, o se puede implementar para adaptarse a cualquier protocolo que se le solicite.
Agentes de servidor de claves de servicio
El Agente de servidor de claves (KSA) 298 proporciona un método para que los destinatarios autentiquen los mensajes recibidos del servicio. Se considera principalmente como un método para proteger dispositivos de transmisiones falsas de avisos tal como se describió anteriormente, pero también podría ser utilizado para encriptar y autenticar de manera segura las notificaciones de contenido de un solo usuario.
El KSA 298 guarda una lista de pares de claves sensibles al tiempo, indexada por etiquetas. El KSA 298 crea un par de claves utilizando algoritmos de clave pública junto con su etiqueta de indexación a petición del agente de difusión 297 (o del dispositivo de destino) cuando se está preparando para originar un mensaje. El KSA 298 responde con la etiqueta y la clave privada, que el agente solicitante utiliza para encriptar la totalidad o parte del mensaje. El KSA 298 guarda el par de claves durante un período de tiempo preconfigurado, normalmente del orden de minutos. Una vida corta reduce la posibilidad de intentos de reproducir claves inhabilitadas para proporcionar una autenticación positiva falsa de las difusiones.
El KSA 298 también escucha en un puerto conocido las conexiones externas de los dispositivos, recibe una etiqueta y responde con la clave pública correspondiente, si aún existe. Los dispositivos utilizan esta clave para desencriptar la parte encriptada del mensaje recibido del agente de transmisión. Si la clave no existe o no es desencriptada correctamente, el mensaje no se muestra al usuario final del dispositivo.
Agentes de respuesta de difusión de servicio
El agente de respuesta de difusión 275 es un agente que puede ser agrupado y recopila las respuestas a las emisiones (confirmaciones de recepción). Puede ser empleado para realizar la totalidad o parte de la funcionalidad del gestor de respuestas 760 del sistema general 710, tal como se describió anteriormente. En general, el agente de respuesta de difusión 275 puede ser empleado para recibir u obtener mensajes de respuesta de los dispositivos de usuario de destino que acusan recibo del mensaje de aviso comunicado y que también pueden proporcionar cualquier información deseada al agente de respuesta de difusión 275.
Por ejemplo, el agente de respuesta de difusión puede recopilar respuestas de dispositivos de usuario final conectados de manera asíncrona (por ejemplo, dispositivos de correo electrónico / SMS / MMS). Puede crear agentes agrupados para escuchar las respuestas entrantes de SMS, por ejemplo, las puertas de enlace del proveedor de servicios de SMS / MMS 150, y periódicamente sondea un buzón de correo de respuesta de correo electrónico preconfigurado, creado y guardado para dicho propósito (por ejemplo, en almacenes de correo corporativos 110), para las respuestas del usuario final (o puede solicitar al agente recuperación de contenido 280 que lo haga). Las confirmaciones de respuesta se pueden enviar al agente de gestión 240 para su recopilación y transmisión a la consola de administración 60 para su visualización y notificación.
Flujo de información - Funcionalidad de recuperación / reenvío de contenido
La figura 6 muestra un diagrama esquemático que ilustra el flujo de información a través del sistema junto con la funcionalidad de recuperación y reenvío de contenido del sistema. Los flujos de información en la figura se muestran como flechas abiertas numeradas y se referencian, a continuación, mediante la inclusión entre paréntesis del número que identifica el flujo. Las flechas sombreadas en la figura muestran, en general, el flujo de información entre los diversos componentes. En general, cuando un perfil de abonado especifica el contenido externo al que debe acceder el sistema, el sistema no recuperará el contenido que llegue a dichas fuentes hasta que las fuentes sean sondeadas por el sistema. Tal como se describió anteriormente, el agente de clase de servicio (COSA) 260 está configurado para programar el sondeo de las fuentes de contenido del usuario de acuerdo con los acuerdos de nivel de servicio (SLA) y con otros parámetros almacenados en la base de datos de usuarios 80. Por lo tanto, el COSA 260 accede a la base de datos de usuarios 80 periódicamente a través del administrador de usuarios 250 (flujo [1]) para determinar y actualizar dicha programación.
Cuando está programado que se realice el sondeo de las fuentes de contenido de un abonado, el COSA 260 notifica al gestor de agrupaciones de agentes de recuperación de contenido (CRA) 280 (a través de la pizarra digital 210, como es toda la comunicación entre agentes) (flujo [2]) para recuperar contenido de las fuentes configuradas. El mensaje enviado al gestor de agrupaciones de CRA 280 incluye los datos de usuario del abonado recuperados de la base de datos del usuario 80. El gestor de agrupaciones de CRA 280 selecciona, a continuación, el siguiente agente agrupado disponible del tipo de medio apropiado para realizar la recuperación. El contenido recuperado, en general, se deja intacto (es decir, una copia es recuperada por el CRA 280), pero en los casos apropiados (por ejemplo, correo electrónico), si las preferencias del abonado así lo dirigen, el contenido puede ser eliminado opcionalmente de la fuente. Una vez que el agente agrupado de CRA finaliza su trabajo, el gestor de agrupaciones de CRA 280 devuelve, a continuación, una recopilación de contenido a COSA (flujo [3]) (de nuevo, a través de la pizarra digital 210) y envía una actualización de estado al agente de estado del usuario (USA) 270 (flujo [4]).
El COSA 260, a su vez, reenvía el contenido recuperado junto con los datos del usuario al gestor de agrupaciones de agentes de personalización de contenido (CPA) 295 (flujo [5]) para su procesamiento. Se selecciona un agente agrupado de CPA apropiado para los medios, que analiza la relevancia del contenido individual para el abonado (de acuerdo con las preferencias especificadas en los datos del usuario) y, a continuación, cuando es relevante, resume o formatea el contenido como un mensaje separado para el dispositivo de abonado. A continuación, el CPA 295 reenvía la recopilación de mensajes junto con los datos del usuario al gestor de agrupaciones de agentes de entrega de contenido (CDA) 290 (flujo [6]) y envía una actualización de estado a los USA (flujo [7]).
A continuación, gestor de agrupaciones de CDA 290 selecciona un agente agrupado apropiado para el canal para entregar cualquier contenido que puede ser reenviado al dispositivo del abonado. El agente agrupado formatea la “envolvente” del canal (por ejemplo, el remitente de protocolo SMTP y la cabecera de la respuesta, la cabecera del originador de la cabecera de SMS, etc.) para indicar una dirección de retorno adecuada, lo que permite al abonado responder al mensaje, si corresponde. Tras la finalización de la transmisión, el CDA 290 envía una notificación al COSA 260 (flujo [8]) y al agente de estado del usuario 270 (flujo [9]) (para monitorizar el estado de la cuenta del abonado).
Cuando el COSA 260 recibe una notificación de finalización de esa solicitud, la cuenta se vuelve a registrar en la base de datos.
Las expiraciones del temporizador en cualquier etapa del procesamiento de la transacción conducirán a que una transacción se marque como “perdida”. Dependiendo del escenario del protocolo, los tiempos de espera pueden requerir que un agente agrupado sea terminado por la fuerza (y, después reencarnado) por el administrador de agrupaciones (por ejemplo, un tiempo de espera cuando se recupera el correo electrónico de un buzón de correo POP3). Los protocolos más inteligentes proporcionan sus propios temporizadores, lo que permite al agente agrupado recuperarse. En ambos casos, el mensaje de “transacción perdida” se envía a los USA, y el mensaje de respuesta apropiado se envía al COSA para indicar que la transacción se ha completado (aunque sin éxito).
Muchas transacciones de abonados pueden estar en proceso en el servicio de manera simultánea, unidas por las marcas de nivel alto de agentes de los números de agentes de recuperación, procesamiento y entrega de contenido. Cada transacción sigue el flujo de información descrito anteriormente.
Opciones de realización
Aunque se han dado a conocer diversas realizaciones a modo de ejemplo de la invención, debería ser evidente para los expertos en la materia que se pueden realizar diversos cambios y modificaciones.
Las realizaciones de la invención pueden ser implementadas en cualquier lenguaje de programación informática convencional. Por ejemplo, las realizaciones preferidas pueden ser implementadas en un lenguaje de programación de procedimiento (por ejemplo, “C”) o en un lenguaje orientado a objetos (por ejemplo, “C++”). Las realizaciones alternativas de la invención pueden ser implementadas como elementos de hardware preprogramados, otros componentes relacionados, o como una combinación de componentes de hardware y software.
Las realizaciones pueden ser implementadas como un producto de programa informático para utilizar con un sistema informático. Dicha implementación puede incluir una serie de instrucciones informáticas fijadas en un medio tangible, tal como un medio legible por ordenador (por ejemplo, un disquete, CD-ROM, ROM o disco fijo) o que pueden ser transmitidas a un sistema informático, a través de un módem o de otro dispositivo de interfaz, tal como un adaptador de comunicaciones conectado a una red a través de un medio. El medio puede ser un medio tangible (por ejemplo, líneas de comunicaciones ópticas o eléctricas) o un medio implementado con técnicas inalámbricas (por ejemplo, microondas, infrarrojos u otras técnicas de transmisión). La serie de instrucciones informáticas incorpora la totalidad o parte de la funcionalidad descrita anteriormente en este documento. Los expertos en la materia deberían apreciar que dichas instrucciones informáticas se pueden escribir en varios idiomas de programación para utilizar con muchas arquitecturas informáticas o sistemas operativos. Además, dichas instrucciones pueden ser almacenadas en cualquier dispositivo de memoria, tal como semiconductores, dispositivos magnéticos, ópticos u otros dispositivos de memoria, y pueden ser transmitidas utilizando cualquier tecnología de comunicaciones, tal como óptica, infrarroja, microondas u otras tecnologías de transmisión. Se espera que dicho producto de programa informático pueda ser distribuido como un medio extraíble con la documentación impresa o electrónica que lo acompaña (por ejemplo, software empaquetado), precargado con un sistema informático (por ejemplo, en la ROM del sistema o disco fijo) o distribuido desde un servidor a través de la red (por ejemplo, Internet o World Wide Web). Por supuesto, algunas realizaciones de la invención pueden ser implementadas como una combinación de software (por ejemplo, un producto de programa informático) y hardware. Otras realizaciones adicionales de la invención pueden ser implementadas como completamente de hardware o completamente de software (por ejemplo, un producto de programa informático).
Se debe apreciar que las cabeceras de sección que han aparecido anteriormente en el presente documento simplemente pretenden organizar la descripción en aras de la claridad.
Con las realizaciones anteriores a modo de ejemplo que se han dado a conocer, será evidente para los expertos en la materia que se pueden realizar diversos cambios y modificaciones para conseguir aún las ventajas de la invención.

Claims (14)

REIVINDICACIONES
1. Un sistema (710) para comunicar un mensaje de aviso a una pluralidad de destinatarios,
estando asociado cada destinatario con un dispositivo de comunicaciones (790) respectivo,
siendo cada dispositivo uno respectivo de una pluralidad de tipos de dispositivos, teniendo cada dispositivo una dirección respectiva, comprendiendo el sistema:
un módulo de despacho (720) para recibir el mensaje de aviso, los datos del abonado del mensaje y los criterios de identificación del dispositivo, identificando los datos del abonado del mensaje recibidos de una base de datos (740) a los destinatarios registrados y las direcciones de sus dispositivos de comunicaciones asociados, en donde el módulo de despacho (720) es para compilar una lista de los destinatarios basada en parte en los datos del abonado del mensaje, y en donde el módulo de despacho (720) es para comunicarse con un nodo de comunicaciones (770) accesible al sistema para consultar o sondear dicho nodo de comunicaciones (770) y, en respuesta a ello, recibir directamente del nodo de comunicaciones (770) una identificación de los dispositivos de comunicaciones (790) actualmente accesibles a través de ese nodo de comunicaciones (770) en base a los criterios de identificación del dispositivo, en donde los criterios de identificación del dispositivo especifican una proximidad lógica o física del dispositivo al nodo de comunicaciones (770) o a una ubicación especificada, en la que el módulo de despacho (720) es además para compilar la lista de los destinatarios basada en parte en la identificación recibida del nodo de comunicaciones (770), en donde el nodo de comunicaciones (770) es un punto de acceso a la red que es cableado o inalámbrico, y la identificación recibida del nodo de comunicación incluye una dirección de, al menos, un dispositivo de comunicaciones (790) de un destinatario no registrado;
un módulo de entrega (730) para recibir desde el módulo de despacho (720) el mensaje y la lista de destinatarios que comprende destinatarios registrados y, al menos, un destinatario no registrado, siendo, además, el módulo de entrega (730) para recibir las direcciones de dispositivo basadas en la lista de los destinatarios, siendo, además, el módulo de entrega (730) para comunicar el mensaje a los dispositivos especificados por la lista de destinatarios que comprende destinatarios registrados y, al menos, un destinatario no registrado, teniendo el módulo de entrega (730), para cada dispositivo, un submódulo de entrega correspondiente para comunicar el mensaje a los dispositivos de ese tipo de dispositivo; y
la base de datos (740) para recibir y almacenar el mensaje, comprendiendo la lista de los destinatarios los destinatarios registrados y, al menos, un destinatario no registrado, incluyendo los tipos de dispositivo y las direcciones del dispositivo, los datos de abonado del mensaje que comprenden identificadores de los destinatarios registrados y sus direcciones de dispositivo asociadas y tipos de dispositivos.
2. El sistema de acuerdo con la reivindicación 1,
en el que el módulo de despacho (720) es, además, para compilar la lista de los destinatarios en base a los datos recibidos desde un directorio externo (780) accesible por el sistema.
3. El sistema de acuerdo con la reivindicación 2,
en el que el módulo de despacho (720) compila la lista de los destinatarios sondeando el directorio externo (780) que incluye un directorio telefónico, un directorio de nombres de anfitrión del equipo cliente configurado en un dominio de red o una lista de distribución.
4. El sistema de acuerdo con la reivindicación 1,
en el que el módulo de despacho (720) o el módulo de entrega (730) son, además, para consultar la base de datos (740), un directorio externo (780) o el nodo de comunicaciones (770) para las direcciones de dispositivo en base a los criterios de identificación del dispositivo.
5. El sistema de acuerdo con la reivindicación 1,
en el que el punto de acceso a la red es un punto de acceso a la red inalámbrico, y los dispositivos accesibles a través del punto de acceso a la red inalámbrico son capaces de recibir mensajes de SMS o MMS, y en el que, al menos, uno de los dispositivos accesibles a través del punto de acceso a la red inalámbrica es un teléfono celular.
6. El sistema de acuerdo con la reivindicación 1,
en el que los tipos de dispositivo incluyen dispositivos capaces de recibir mensajes de correo electrónico, mensajes de SMS o MMS, mensajes de voz, mensajes de IP o mensajes a través de HTTP.
7. El sistema de acuerdo con la reivindicación 1,
en el que, al menos, un tipo de dispositivo es capaz de operar una aplicación cliente para recibir el mensaje de aviso desde el módulo de entrega, siendo, además, la aplicación cliente, para autenticar el mensaje de aviso, comprendiendo, además, el sistema, un módulo de servidor de claves (750) para generar una nueva clave privada, una nueva clave pública correspondiente a la clave privada y una nueva etiqueta de mensaje asociada con la clave privada y la clave pública, comunicando, además, el módulo del servidor de claves la clave privada y la etiqueta del mensaje al módulo de despacho (720), siendo, además, el módulo de despacho (720) para encriptar una parte del mensaje de aviso en base a la clave privada, siendo, además, el módulo de entrega (730) para recibir la etiqueta de mensaje desde el módulo de despacho (720) y para comunicar la marca del mensaje a los dispositivos, al menos, de un tipo de dispositivo capaz de operar la aplicación cliente, siendo, además, la aplicación cliente, para consultar el módulo del servidor de claves (750) en base a la etiqueta del mensaje para la clave pública correspondiente a la clave privada y para desencriptar la parte encriptada del mensaje de aviso en base a la clave pública, autenticando de este modo el mensaje de aviso.
8. El sistema de acuerdo con la reivindicación 7,
en el que, al menos, un tipo de dispositivo es capaz de recibir mensajes de voz, el mensaje de aviso incluye un mensaje de texto y el módulo de entrega (730) es, además, para convertir el mensaje de texto en una grabación de audio y comunicar la grabación de audio a los dispositivos de ese tipo de dispositivo,
en donde, al menos, uno de los dispositivos del tipo de dispositivo capaz de recibir mensajes de voz es un teléfono, un teléfono móvil o un ordenador.
9. El sistema de acuerdo con la reivindicación 1,
que comprende, además, un gestor de respuestas para recibir mensajes de acuse de recibo respectivos de cada uno de los dispositivos, en el que la base de datos es, además, para almacenar los mensajes de acuse de recibo respectivos,
en donde, al menos, uno de los mensajes de acuse de recibo es un mensaje de correo electrónico, un código corto de SMS o MMS, una serie de tonos de DTMF o un comando reconocido por voz.
10. El sistema de acuerdo con la reivindicación 1,
que comprende, además, un gestor de respuestas (760), para recibir mensajes de acuse de recibo respectivos de cada uno de los dispositivos, en donde la base de datos (740) es, además, para almacenar los mensajes de acuse de recibo respectivos,
en donde el módulo de despacho (720) es, además, para establecer una comunicación bidireccional con, al menos, uno de los dispositivos desde los cuales el gestor de respuestas (760) ha recibido un mensaje de acuse de recibo respectivo.
11. El sistema de acuerdo con la reivindicación 1, que comprende, además:
un gestor de respuestas (760) para recibir mensajes de acuse de recibo respectivos de cada uno de los dispositivos, en el que la base de datos (740) es, además, para almacenar los mensajes de acuse de recibo respectivos; y un módulo de notificación (850) para generar informes que indican un éxito o un fallo de la comunicación del mensaje, al menos, a uno de los dispositivos.
12. El sistema de acuerdo con la reivindicación 1,
en el que, al menos, uno de los dispositivos accesibles a través del punto de acceso a la red no está asociado con el punto de acceso a la red.
13. Un sistema (10) para comunicar un mensaje de aviso a una pluralidad de destinatarios, estando asociado cada destinatario con un dispositivo de comunicaciones respectivo, siendo cada dispositivo uno respectivo de una pluralidad de tipos de dispositivos, teniendo cada dispositivo una dirección respectiva, comprendiendo el sistema: un medio de despacho (60), para recibir el mensaje de aviso, los datos del abonado del mensaje y los criterios de identificación del dispositivo, los datos del abonado del mensaje recibidos de una base de datos (80) e identificar los destinatarios registrados y las direcciones de sus dispositivos de comunicaciones asociados, en donde el medio de despacho es para compilar una lista de los destinatarios basada, en parte, en los datos del abonado del mensaje, y en donde el medio de envío es para comunicarse con un nodo de comunicaciones accesible para el sistema, para consultar o sondear dicho nodo de comunicaciones y, en respuesta al mismo, recibir directamente del nodo de comunicaciones una identificación de dispositivos de comunicaciones actualmente accesibles a través de ese nodo de comunicaciones en base a los criterios de identificación del dispositivo, en donde los criterios de identificación del dispositivo especifican una proximidad lógica o física del dispositivo al nodo de comunicaciones o una ubicación especificada, en donde el medio de despacho es, además, para compilar la lista de los destinatarios basada, en parte, en la identificación recibida del nodo de comunicaciones, en donde el nodo de comunicaciones es un punto de acceso a la red que es cableado o inalámbrico, y la identificación recibida del nodo de comunicaciones incluye una dirección de, al menos, un dispositivo de comunicaciones de un receptor no registrado;
una estructura de agentes (30), conectada operativamente al medio de despacho (60), operando la estructura de agentes una pluralidad de agentes autónomos que incluyen:
un agente de difusión (297), para recibir del medio de despacho el mensaje de aviso y la lista de destinatarios, siendo, además, el agente de transmisión, para recibir las direcciones del dispositivo;
un agente de entrega de contenido (290) para comunicar el mensaje de aviso a los dispositivos, teniendo el agente de entrega de contenido un agente agrupado correspondiente para cada tipo de dispositivo, para comunicar el mensaje de aviso a los dispositivos de ese tipo de dispositivo; y
la base de datos (80), para recibir y almacenar el mensaje de aviso, la lista de destinatarios, los tipos de dispositivo y las direcciones de dispositivo, incluidos los datos de abonado del mensaje que comprenden identificadores de los destinatarios registrados y sus direcciones de dispositivo y tipos de dispositivo asociados.
14. El sistema de acuerdo con la reivindicación 13,
en el que la pluralidad de agentes autónomos incluye, además:
un agente de recuperación de contenido (280), para recuperar contenido de una fuente externa, en el que el agente de difusión (210) es, además, para recibir el contenido del agente de recuperación de contenido (280) y para asociar el contenido con el mensaje de aviso, y en donde el agente de entrega de contenido (290) es, además, para recibir el contenido y comunicar el contenido a los dispositivos en asociación con el mensaje de aviso.
ES08857249T 2007-12-06 2008-12-05 Difusión de avisos a una pluralidad de diversos dispositivos de comunicaciones Active ES2784239T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
PCT/CA2007/002197 WO2009070861A1 (en) 2007-12-06 2007-12-06 Processing of network content and services for mobile or fixed devices
US11/951,572 US8051057B2 (en) 2007-12-06 2007-12-06 Processing of network content and services for mobile or fixed devices
PCT/CA2008/002119 WO2009070882A1 (en) 2007-12-06 2008-12-05 Alert broadcasting to a plurality of diverse communications devices

Publications (1)

Publication Number Publication Date
ES2784239T3 true ES2784239T3 (es) 2020-09-23

Family

ID=40717229

Family Applications (1)

Application Number Title Priority Date Filing Date
ES08857249T Active ES2784239T3 (es) 2007-12-06 2008-12-05 Difusión de avisos a una pluralidad de diversos dispositivos de comunicaciones

Country Status (3)

Country Link
EP (1) EP2227871B1 (es)
ES (1) ES2784239T3 (es)
WO (1) WO2009070882A1 (es)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9338597B2 (en) 2007-12-06 2016-05-10 Suhayya Abu-Hakima Alert broadcasting to unconfigured communications devices
US8051057B2 (en) 2007-12-06 2011-11-01 Suhayya Abu-Hakima Processing of network content and services for mobile or fixed devices
CA2707536C (en) 2007-12-06 2015-05-12 Suhayya Abu-Hakima Processing of network content and services for mobile or fixed devices
US9215217B2 (en) 2008-12-05 2015-12-15 Suhayya Abu-Hakima and Kenneth E. Grigg Auto-discovery of diverse communications devices for alert broadcasting
WO2011123919A1 (en) 2010-04-09 2011-10-13 Suhayya Abu-Hakima Auto-discovery of diverse communications devices for alert broadcasting
US8943146B2 (en) 2010-09-21 2015-01-27 Benbria Corporation Method and system and apparatus for mass notification and instructions to computing devices
WO2012037636A1 (en) * 2010-09-21 2012-03-29 Benbria Corporation Method and system and apparatus for mass notification and instructions to computing devices
US10528914B2 (en) 2012-04-27 2020-01-07 Benbria Corporation System and method for rule-based information routing and participation
US9094282B2 (en) 2012-04-27 2015-07-28 Benbria Corporation System and method for rule-based information routing and participation
US8943061B2 (en) 2012-04-27 2015-01-27 Benbria Corporation System for extracting customer feedback from a microblog site
US20140214979A1 (en) * 2013-01-29 2014-07-31 Talk.to FZC Providing alerts on communication devices
GB2511067B (en) * 2013-02-21 2017-02-08 Vdt Direct Ltd Alarm notification system

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10032055C2 (de) 2000-07-05 2003-09-25 Vierling Electronics Gmbh & Co Alarmierungssystem zur Weiterleitung von Alarmmeldungen an eine Gruppe von Mobilstationen oder Teilnehmerendeinrichtungen
US7133869B2 (en) * 2001-03-06 2006-11-07 Knowledge Vector, Inc. Methods and systems for and defining and distributing information alerts
US20060053465A1 (en) * 2002-11-15 2006-03-09 Mears Mark G Apparatus and method for providing alert outputs
FR2849948B1 (fr) * 2003-01-14 2008-07-11 Cii Ind Procede et systeme de transmission d'un message d'informations et support d'enregistrement pour la mise en oeuvre du procede
US6845324B2 (en) * 2003-03-01 2005-01-18 User-Centric Enterprises, Inc. Rotating map and user-centric weather prediction
CA2453709A1 (en) * 2003-12-18 2005-06-18 Bce Inc System, apparatus and method for wireless notification
US7277018B2 (en) * 2004-09-17 2007-10-02 Incident Alert Systems, Llc Computer-enabled, networked, facility emergency notification, management and alarm system
US7603432B2 (en) * 2005-06-06 2009-10-13 Aa, Llc Locality based alert method and apparatus

Also Published As

Publication number Publication date
EP2227871A1 (en) 2010-09-15
WO2009070882A1 (en) 2009-06-11
EP2227871B1 (en) 2020-01-22
EP2227871A4 (en) 2013-10-09

Similar Documents

Publication Publication Date Title
US8291011B2 (en) Alert broadcasting to a plurality of diverse communications devices
ES2784239T3 (es) Difusión de avisos a una pluralidad de diversos dispositivos de comunicaciones
US10278049B2 (en) Alert broadcasting to unconfigured communications devices
US9215217B2 (en) Auto-discovery of diverse communications devices for alert broadcasting
US9705841B2 (en) Private mobile messaging and data communications apparatus and method of managing organizational messaging
US8051057B2 (en) Processing of network content and services for mobile or fixed devices
EP1021896B1 (en) Electronic mail forwarding system and method
US6618763B1 (en) Virtual private wireless network implementing message delivery preferences of the user
US8509729B2 (en) Interactive personal emergency communications
JP2020519144A (ja) サービス能力公開機能（ｓｃｅｆ）ベースのインターネットオブシングス（ｉｏｔ）通信の方法とシステム
US20140162684A1 (en) Long Term Evolution Advanced Location-Sensitive Information Management
US9049166B2 (en) System and method for messaging content delivery
US9356896B2 (en) Automated announcement-and-bulletins system
CA2707575C (en) Alert broadcasting to a plurality of diverse communications devices
CA2795079C (en) Auto-discovery of diverse communications devices for alert broadcasting
CA2908146C (en) Alert broadcasting to unconfigured communications devices
EP3701685A1 (en) Combination system and method
Li A Fifth Generation Messaging System
Park et al. A Test-bed for the Convergence Services of TV with IP-based STB and Mobile Services in the IPbased network