ES2809237T3 - Procesamiento de contenido y servicios de redes para dispositivos móviles o fijos - Google Patents

Abstract

Un sistema para suministrar contenido de red a un dispositivo, comprendiendo el sistema (10): una primera interfaz para comunicarse con una pluralidad de fuentes de contenido de red para recuperar el contenido de la red; una segunda interfaz para comunicarse con el dispositivo para entregar contenido de red procesado al dispositivo; y una estructura de agente (30) conectada operativamente a la primera interfaz y a la segunda interfaz, operando la estructura de agente una pluralidad de agentes autónomos que incluyen: una pluralidad de agentes de recuperación de contenido (280) para recuperar el contenido de red de las fuentes de contenido de red a través de la primera interfaz, comprendiendo los agentes de recuperación de contenido, para cada uno de una pluralidad tipos de medios de contenido de red, al menos un agente de recuperación de contenido para recuperar el contenido de red de las fuentes de contenido de red correspondientes al tipo de medios de contenido de red; un agente de personalización de contenido (295), para procesar el contenido de red y producir contenido de red procesado, en donde dicho procesamiento del contenido de red comprende formatear el contenido de red para su presentación en el dispositivo; y un agente de entrega de contenido (290), para entregar el contenido de red procesado a un abonado a través de la segunda interfaz, el agente de entrega de contenido (290) configurado además para: identificar la dirección de un creador del contenido de la red; determinar si el creador del contenido de red coincide con una entrada en una lista de contactos personales incluida en los datos del usuario correspondientes al abonado y, en caso afirmativo, transmitir al menos una etiqueta al dispositivo, identificando la al menos una etiqueta la dirección del originador, en donde la al menos una etiqueta permite que el dispositivo inicie una respuesta de voz o texto al contenido de red procesado o permite que el dispositivo inicie un servicio transaccional en respuesta al contenido de red procesado.

Description

DESCRIPCIÓN

Procesamiento de contenido y servicios de redes para dispositivos móviles o fijos

Antecedentes de la invención

Campo de la invención

La invención se refiere, en general, a sistemas de comunicación de redes y, más concretamente, a sistemas para proporcionar acceso remoto a recursos de redes.

Descripción de la técnica relacionada

La mensajería electrónica (por ejemplo, correo electrónico, chat, SMS, MMS) se ha convertido en una herramienta crítica para hacer negocios: la capacidad de reaccionar rápidamente a los mensajes de clientes o colegas se traduce en una ventaja competitiva. En consecuencia, se han desarrollado muchas soluciones comerciales para permitir a los usuarios recibir mensajes electrónicos mientras están lejos de las estaciones de trabajo de su escritorio. Hubo un tiempo en que los dispositivos de propósito especial satisfacían esta necesidad, pero se utilizan cada vez más dispositivos de usos múltiples que proporcionan una variedad de servicios, incluyendo correo electrónico bidireccional, mensajería instantánea, telefonía y navegación web.

Muchos dispositivos especiales y de usos múltiples conocidos permiten la comunicación remota por correo electrónico. Sin embargo, dichas soluciones presentan inconvenientes críticos. Los asistentes de datos personales (“PDA” - Personal Data Assistants, en inglés), comúnmente conocidos en la actualidad como “teléfonos inteligentes”, y los dispositivos emergentes “combinados” tales como Pearl™, comercializado por Blackberry™ o iPhone™, comercializado por Apple™ son caros, y los cargos por servicios de red que soportan dichos dispositivos son prohibitivamente altos. En consecuencia, solo algunos de los miembros de empresas habituales se han beneficiado de dichos dispositivos. Aunque los teléfonos celulares de uso generalizado son capaces de recibir y enviar correos electrónicos, tienen pantallas pequeñas y teclados pequeños, por lo que son relativamente difíciles de utilizar para la mensajería electrónica.

A pesar del hecho de que los dispositivos conocidos proporcionan mensajes electrónicos remotos, no abordan la otra parte del problema: la sobrecarga es una queja común, ya que la mayoría de los usuarios corporativos reciben demasiados mensajes electrónicos a diario, lo que resulta en hábitos de trabajo ineficientes, ya que los usuarios son interrumpidos continuamente para verificar los mensajes entrantes. (Esto va más allá del problema del correo no deseado, que, en la mayoría de las empresas, actualmente se remedia en un 80% con soluciones de filtrado antispam y antivirus). La sobrecarga de mensajes electrónicos es un problema en dispositivos de mensajería móvil dedicados y, especialmente, en dispositivos de teléfonos celulares habituales con almacenamiento y espacio de visualización limitados, que hacen que la solución sea, en general, inutilizable.

Además, una mayoría cada vez mayor de usuarios de mensajería electrónica corporativa cae en una nueva categoría a veces llamada “prosumidores”: empleados corporativos con compromisos no corporativos que impactan fuertemente su desempeño en el trabajo, tal como el cuidado de niños y mensajes personales, familiares o de redes sociales. Para estos usuarios, un solo dispositivo que proporcione acceso tanto a mensajes corporativos como personales no ha estado disponible, que no reenvíe mensajes personales a la oficina (o viceversa), lo que, por razones de privacidad y/o gobernanza, hasta ahora no ha sido una opción aceptable.

Además, muchos escenarios corporativos involucran a “comunidades de interés” o a “grupos cerrados de usuarios”, donde los empleados colaboran en investigaciones compartidas u objetivos comunes. En dichos escenarios, los empleados pueden compartir responsabilidades, particularmente en su necesidad de actuar rápidamente sobre la nueva información. Además, cuando los miembros clave del grupo están fuera de sus oficinas, algunas comunicaciones destinadas a ellos deberían ser compartidas con otros delegados o con el grupo, en general. Sin embargo, las soluciones móviles conocidas que intentan cumplir estos requisitos requieren, en general, un esfuerzo significativo de configuración y, por lo tanto, no han tenido un especial éxito

Por lo tanto, existe la necesidad de una solución móvil que proporcione acceso combinado a múltiples cuentas y modalidades de mensajería, corporativas y personales (por ejemplo, correo electrónico, chat, correo web, grupos sociales, mensajes de Skype™), que actúe como interfaz con infraestructura corporativa y servidores de correo de Internet, que soporte de manera inteligente a los usuarios que colaboran, pero que es independiente del tipo de dispositivo móvil o auricular y es sensible a la sobrecarga de mensajes electrónicos mientras está en movimiento. Existe una necesidad adicional de una solución que miniaturice o adapte el contenido del mensaje para su representación en dispositivos móviles, en general.

De manera similar, la World Wide Web se utiliza ampliamente, en la actualidad, para todos los aspectos de los negocios, y la capacidad de conocer de manera oportuna la disponibilidad en la Web de nuevos contenidos y servicios contextualmente importantes proporciona una ventaja competitiva. En los casos en que un usuario está lejos de su estación de trabajo, habitualmente se utiliza un dispositivo portátil para buscar nuevos contenidos y servicios. Sin embargo, la mayoría de los dispositivos portátiles no son adecuados para mostrar o acceder a recursos web no diseñados específicamente, con las limitaciones de los dispositivos móviles en mente, y, en muchas áreas del mundo, los costes de navegación móvil son importantes. Si bien muchos servicios web proporcionan notificaciones de nuevo contenido a través de SMS/MMS y correo electrónico, la práctica más general es utilizar fuentes de RSS (o mecanismos competitivos). Dichas fuentes de RSS pueden ser procesadas en un navegador móvil (sujeto a los mismos costes de navegación importantes), pero requieren que el usuario verifique proactivamente el contenido nuevo. Además, no existen mecanismos en los que los agentes actúen como representantes de los usuarios para buscar nuevos servicios y entregar avisos en base a lo que encuentran en Internet.

Por lo tanto, existe la necesidad de una solución que proporcione notificaciones de contenido y servicios nuevos o actualizados automáticamente, a los dispositivos portátiles, que sea independiente del tipo de dispositivo móvil o portátil, y que miniaturice o adapte de otro modo el contenido web para representación en dispositivos móviles, en general.

Además, existen muchos servicios disponibles a través de Internet y de otras redes, aparte de la mensajería electrónica y la Web y, aunque actualmente no tienen un lugar tan importante como estos dos servicios en general, algunas empresas concretas a veces necesitarán servicios concretos no utilizados comúnmente, incluida la capacidad de recibir contenido no solicitado y transacciones de estos servicios de manera remota. Además, a medida que la informática de red y las telecomunicaciones evolucionan, se desarrollan y adoptan nuevos servicios a los que los usuarios pueden desear acceder de manera remota o recibir notificaciones de la utilización de dispositivos móviles portátiles.

Por lo tanto, existe la necesidad de una solución que proporcione una conexión directa automatizada de cambios a Internet o a otros recursos de la red de manera extensible, para satisfacer las necesidades concretas de un grupo concreto de usuarios, o para adaptarse al desarrollo de nuevos servicios, independientemente del tipo de dispositivo móvil o teléfono, y que miniaturice o adapte de otro modo las salidas de dichos servicios para su representación (rendering, en inglés) en dispositivos móviles o fijos, en general.

Además, es ventajoso un sistema tal como el que se describió anteriormente que es fácilmente capaz de ser implementado en contextos de portal web y de empresa, puesto que tanto los operadores de sistemas corporativos como los sistemas a los que se debe acceder sin problemas en un contexto más amplio podrán implementar el sistema sin personalización al contexto.

Además, es ventajoso un sistema tal como el que se describió anteriormente, que funciona con el dispositivo móvil para permitir una respuesta a la notificación o aviso utilizando capacidades alternativas del dispositivo móvil, tales como llamadas de voz o de texto en respuesta a un correo electrónico.

Se han propuesto varias soluciones que superan algunos, pero no todos, los problemas descritos anteriormente. Por ejemplo, la Patente de los Estados Unidos N° 6.499.021 de Abu-Hakima dan a conocer un sistema legible por ordenador y un método para interpretar y reenviar selectivamente un mensaje interpretado derivado del mensaje electrónico recibido de un usuario, tal como un correo electrónico, fax, voz convertida y mensajes de localización de personas, a un dispositivo de comunicaciones móviles del usuario. Sin embargo, la referencia no explica un sistema que esté adaptado para ser extensible a tipos de contenido alternativos y emergentes o a contenido de servicio transaccional, o que pueda reenviar un mensaje interpretado como múltiples partes más pequeñas cuando sea necesario para cumplir con las cambiantes capacidades del canal. Además, la referencia no explica un sistema que sea capaz de acceder a múltiples fuentes de mensajes, y que sea capaz de implementaciones tanto corporativas como de portal. Tampoco la referencia explica un sistema que sea capaz de reenviar mensajes interpretados que incorporen etiquetas de “contenido activo” que permitan un inicio simple de respuestas de voz o de texto a contenido o a servicios transaccionales.

De manera similar, las patentes de los Estados Unidos N° 6.820.237 y 6.823.331 de Abu-Hakima dan a conocer algunos, pero no todos, los aspectos de las soluciones necesarias descritas anteriormente. El documento US 6.820.237 describe un aparato y un método legible por ordenador para analizar y resaltar de manera inteligente palabras/frases clave, oraciones clave y/o componentes clave de un documento electrónico, mediante el reconocimiento y la utilización del contexto tanto del documento electrónico (que puede ser cualquier tipo de mensaje electrónico, tal como mensaje de correo electrónico, convertido a voz, fax o localización de personas, u otro tipo de documento electrónico) como del usuario. De manera similar, el documento US 6.823.331 da a conocer un sistema de identificación de conceptos útil para reducir y/o representar el contenido de texto de un documento electrónico y para resaltar el contenido del documento. Sin embargo, ninguna referencia explica un sistema que sea capaz de acceder a múltiples fuentes de mensajes o a servicios transaccionales, tanto de implementaciones corporativas como de portal, de múltiples modos de transmisión, de encontrar nuevos contenidos o servicios web, y de incorporar contenido activo agregado mediante el conocimiento del usuario.

El documento US 2004/030741 A1 da a conocer un sistema de agente personal modular e inteligente para búsqueda, navegación, control, recuperación, análisis y notificación de resultados en redes y bases de datos.

Por lo tanto, sigue existiendo la necesidad de una solución que proporcione notificaciones o alertas oportunas de mensajes electrónicos nuevos/actualizados y contenido o servicios web, que sea fácilmente extensible para proporcionar acceso a otros tipos de contenido y fuentes, que soporte grupos cerrados de usuarios, contenido activo para respuesta, y que soporte múltiples formas de llegar al dispositivo móvil según la disponibilidad y los factores de coste. La solución debe ser independiente del tipo de dispositivo móvil o de auricular y estar adaptada para miniaturizar o adaptar el contenido para representación (rendering, en inglés) en dispositivos móviles o fijos, en general. Además, la solución debe poder ser implementada fácilmente en contextos de portal web y de empresa. Finalmente, la solución debe ser dinámicamente extensible para manejar tipos de contenido y servicios de Internet nuevos e inesperados.

Breve compendio de la invención

Los inconvenientes descritos anteriormente se superan mediante la invención dada a conocer en el presente documento. Permite a los usuarios recibir notificaciones filtradas de manera inteligente o avisos de mensajes que llegan a buzones de correo tanto corporativos como personales y de fuentes de RSS web designadas y otros contenidos y transacciones de servicios web o automatizados. Las notificaciones pueden ser enviadas a cualquier dispositivo habilitado para SMS/MMS o correo electrónico, lo que significa esencialmente cualquier dispositivo móvil disponible actualmente. La notificación o alerta puede tener la forma de un resumen del mensaje, del mensaje o servicio original, tanto del resumen como del mensaje, o simplemente del remitente y del asunto: el formato se adapta al tamaño de la pantalla del dispositivo. Se proporcionan filtros inteligentes basados en el contexto para evitar sobrecargar al abonado con notificaciones de mensajes sin importancia mientras están en movimiento.

En un primer aspecto, la invención da a conocer un sistema según se expone en la reivindicación 1 adjunta.

En un segundo aspecto, la invención da a conocer un producto de programa informático según se expone en la reivindicación 13 adjunta.

En las reivindicaciones dependientes adjuntas se exponen características opcionales de la invención.

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;

la figura 2 muestra un diagrama esquemático que ilustra componentes de la estructura de agente del sistema a modo de ejemplo 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 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; y

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 contenido de red móvil ilustrado en la figura 5.

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 del sistema a modo de ejemplo que se describe 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

El sistema proporciona la determinación del contexto del usuario, la recuperación de los mensajes de un usuario y otro contenido seleccionado, 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/a los dispositivo(s). 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 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/los dispositivo(s) 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, 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.

Descripción general de componentes del sistema

La figura 1 muestra un diagrama esquemático que ilustra el sistema 10 a modo de ejemplo. Incluye uno o más servidores 20 que ejecutan sistemas operativos dentro de los cuales operan la estructura de agentes 30, el vigilante 40 y servidores de aplicaciones web 50. Una consola de administración 60 y un portal de autoadministración de usuario final 70 operan dentro de uno o más de los servidores de aplicaciones web 50. Una base de datos 80 para capturar y almacenar todos los datos de usuario se ejecuta 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) 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 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 (almacenes de correo corporativos 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 y SOAP para proporcionar comunicación a dispositivos móviles. 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.

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. 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.

Componente del portal de autoadministración de servicios

El portal de autoadministración 70 es una aplicación web que proporciona 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 la 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.

Componentes de la secuencia

El sistema ejecuta periódicamente varias secuencias 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.

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 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, y agentes de personalización de contenido (CPA - Content Personalization Agents, en inglés) 295. (Los últimos tres 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). Tal como se describe más adelante en el presente documento, estos agentes 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 puede ser utilizado para reenviar 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 el contenido es representado (renderized, en inglés) 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. 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).

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 575 (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 575 (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.

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 R^a 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.

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.

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(s) etiqueta(s) apropiada(s) 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.

Flujo de información

La figura 6 muestra un diagrama esquemático que ilustra el flujo de información a través 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.

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 técnica que se pueden realizar diversos cambios y modificaciones que lograrán algunas de las ventajas de la invención sin apartarse del verdadero alcance de la invención.

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 no limitan el alcance de la invención tal como se describe, sino que 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 técnica que se pueden realizar diversos cambios y modificaciones para adaptarse de manera apropiada a las necesidades y objetivos de otra aplicación y conseguir aún las ventajas de la invención; todos los cambios y modificaciones de este tipo pretenden caer dentro del alcance de la invención tal como se define por las reivindicaciones a continuación.

Claims (15)

REIVINDICACIONES

1. Un sistema para suministrar contenido de red a un dispositivo, comprendiendo el sistema (10):

una primera interfaz para comunicarse con una pluralidad de fuentes de contenido de red para recuperar el contenido de la red;

una segunda interfaz para comunicarse con el dispositivo para entregar contenido de red procesado al dispositivo; y una estructura de agente (30) conectada operativamente a la primera interfaz y a la segunda interfaz, operando la estructura de agente una pluralidad de agentes autónomos que incluyen:

una pluralidad de agentes de recuperación de contenido (280) para recuperar el contenido de red de las fuentes de contenido de red a través de la primera interfaz, comprendiendo los agentes de recuperación de contenido, para cada uno de una pluralidad tipos de medios de contenido de red, al menos un agente de recuperación de contenido para recuperar el contenido de red de las fuentes de contenido de red correspondientes al tipo de medios de contenido de red;

un agente de personalización de contenido (295), para procesar el contenido de red y producir contenido de red procesado, en donde dicho procesamiento del contenido de red comprende formatear el contenido de red para su presentación en el dispositivo; y

un agente de entrega de contenido (290), para entregar el contenido de red procesado a un abonado a través de la segunda interfaz, el agente de entrega de contenido (290) configurado además para:

identificar la dirección de un creador del contenido de la red;

determinar si el creador del contenido de red coincide con una entrada en una lista de contactos personales incluida en los datos del usuario correspondientes al abonado y, en caso afirmativo, transmitir al menos una etiqueta al dispositivo, identificando la al menos una etiqueta la dirección del originador, en donde la al menos una etiqueta permite que el dispositivo inicie una respuesta de voz o texto al contenido de red procesado o permite que el dispositivo inicie un servicio transaccional en respuesta al contenido de red procesado.

2. El sistema de acuerdo con la reivindicación 1, en donde la estructura de agente incluye un servicio de mensajes de pizarra digital (210) para proporcionar mensajes entre la pluralidad de agentes.

3. El sistema de acuerdo con la reivindicación 1, en donde al menos uno de los agentes de recuperación de contenido, el agente de personalización de contenido y el agente de entrega de contenido comprende: un administrador de grupos y una pluralidad de agentes agrupados, en donde los agentes agrupados realizan conjuntamente la recuperación, el procesamiento, o la entrega, respectivamente, de ese agente.

4. El sistema de acuerdo con la reivindicación 1, en donde el procesamiento del contenido de la red depende de las capacidades del dispositivo, de las capacidades del canal y de la preferencia del usuario y opcionalmente comprende:

extraer texto pasivo o activo del contenido de red;

resumir el texto en el contenido de red;

traducir el texto en el contenido de red;

enumerar los archivos adjuntos en el contenido de red;

especificar una URL que apunta a un servidor que proporciona representación de los archivos adjuntos en el contenido de red;

representar una versión de menor definición de una imagen en el contenido de red;

extraer una porción del contenido de red; o

filtrar todo o parte del contenido de red.

5. El sistema de acuerdo con la reivindicación 1, en donde la estructura de agente es extensible para operar un agente de recuperación de contenido adicional para recuperar contenido de red adicional de una fuente de contenido de red adicional, en donde la fuente de contenido de red adicional es inaccesible por la pluralidad de agentes de recuperación de contenido, y en donde el contenido adicional de la red es procesado por el agente de personalización de contenido, produciendo de este modo contenido de red procesado adicional para su entrega al dispositivo por el agente de entrega de contenido.

6. El sistema de acuerdo con la reivindicación 1, en donde la estructura de agente es extensible para operar un agente de personalización de contenido adicional para procesar contenido de red adicional y crear una nueva matriz adicional de contenido de red procesado adicional dependiente del dispositivo, en donde dicho procesamiento del contenido de red adicional comprende formatear el contenido de red adicional para su presentación en el dispositivo, en donde:

un tipo de contenido de red adicional es idéntico a un tipo de contenido de red, y el procesamiento del contenido de red adicional por parte del agente de personalización de contenido adicional es diferente del procesamiento del contenido de red por parte del agente de personalización de contenido; o

el tipo del contenido de red adicional es diferente del tipo del contenido de red;

en donde la pluralidad de agentes de recuperación de contenido están previstos, además, para recuperar el contenido de red adicional de una fuente de contenido de red adicional, y el agente de entrega de contenido está previsto, además, para entregar el contenido de red procesado adicional al dispositivo.

7. El sistema de acuerdo con la reivindicación 1, en donde la estructura de agente es extensible para operar un agente de entrega de contenido adicional para entregar contenido de red procesado adicional a un dispositivo adicional, en donde el dispositivo adicional es inaccesible para el agente de entrega de contenido, y en donde la pluralidad de agentes de recuperación de contenido están previstos, además, para recuperar contenido de red adicional de una fuente de contenido de red adicional, y en donde el agente de personalización de contenido está previsto, además, para procesar el contenido de red adicional y crear una nueva matriz adicional de contenido de red procesado adicional dependiente del dispositivo, en donde dicho procesamiento del contenido de red adicional comprende formatear el contenido de red adicional para su presentación en el dispositivo adicional.

8. El sistema de acuerdo con la reivindicación 1, que comprende además una tercera interfaz operativamente conectada a una base de datos de usuario (80) que contiene datos de usuario correspondientes a una pluralidad de usuarios, especificando los datos de usuario un nivel de servicio para cada usuario, en donde la estructura de agente opera, además, un agente de clase de servicio para la programación, en base a los niveles de servicio: la recuperación del contenido de red por la pluralidad de agentes de recuperación de contenido; el procesamiento del contenido de red para su presentación en el dispositivo por el agente de personalización de contenido; y la entrega del contenido de red procesado por el agente de entrega de contenido.

9. El sistema de acuerdo con la reivindicación 8, en donde la fuente de contenido de red incluye un almacén de mensajes de uno de los usuarios, y en donde la programación realizada por la clase de agente de servicio incluye determinar, en base a los niveles de servicio, una frecuencia a la que la pluralidad de agentes de recuperación de contenido sondean el almacén de mensajes.

10. El sistema de acuerdo con la reivindicación 8, en donde el contenido de red incluye un mensaje electrónico, el contenido de red procesado incluye un mensaje SMS o MMS correspondiente al mensaje electrónico, mediante el cual el agente de entrega de contenido reenvía el mensaje SMS o MMS al dispositivo, y en donde la clase de agente de servicio está prevista, además, para acceder a un almacén de mensajes de respuesta SMS/MMS para recibir una respuesta del dispositivo enviada al almacén de mensajes de respuesta SMS/MMS, y, además, en donde la respuesta es retransmitida al agente de entrega de contenido para su entrega a un remitente del mensaje electrónico.

11. El sistema de acuerdo con la reivindicación 8, en donde la clase de agente de servicio está prevista, además, para acceder a un almacén de mensajes de control remoto para recibir un mensaje electrónico desde el dispositivo enviado al almacén de mensajes de control remoto, conteniendo el mensaje electrónico un identificador del dispositivo y un comando para hacer que el sistema:

elimine de un almacén de mensajes de usuario otro mensaje electrónico correspondiente al contenido de red procesado entregado al dispositivo;

entregue al dispositivo una versión completa del contenido de red en donde el contenido de red procesado entregado al dispositivo incluye una versión resumida del contenido de red;

especifique al menos otro dispositivo para recibir el contenido de red procesado; o

active o desactive una notificación o aviso.

12. El sistema de acuerdo con la reivindicación 8, que comprende además un portal de autoadministración (70), conectado operativamente a la base de datos de usuarios para su uso por cada usuario:

para especificar la fuente de contenido de red para recuperar el contenido la red;

para seleccionar una opción de personalización, en donde el procesamiento del contenido de red por el agente de personalización de contenido se basa en la opción de personalización; o

para especificar el dispositivo para la entrega del contenido de red procesado.

13. Un producto de programa informático adaptado para permitir que un ordenador suministre contenido de red a un dispositivo, comprendiendo el producto de programa informático:

instrucciones de software, que, cuando son ejecutadas en el ordenador, proporcionan una estructura de agente, una pluralidad de agentes de recuperación de contenido, un agente de personalización de contenido y un agente de entrega de contenido, las instrucciones de software, cuando son ejecutadas en el ordenador, permiten que el ordenador realice operaciones predeterminadas; y

un medio legible por ordenador que contiene las instrucciones de software;

incluyendo las operaciones predeterminadas:

recuperar el contenido de red desde una fuente de contenido de red por la pluralidad de agentes de recuperación de contenido a través de una primera interfaz, comprendiendo los agentes de recuperación de contenido, para cada uno de una pluralidad de tipos de medios de contenido de red, al menos un agente de recuperación de contenido para recuperar el contenido de la red de las fuentes de contenido de red correspondientes al tipo de medio de contenido de red;

procesar el contenido de red y producir contenido de red procesado, en donde dicho procesamiento del contenido de red comprende formatear el contenido de red para su presentación en el dispositivo por el agente de personalización de contenido; y

entregar el contenido de red procesado a un abonado a través del dispositivo por el agente de entrega de contenido a través de una segunda interfaz, incluyendo la entrega el agente de entrega de contenido:

que identifica una dirección del creador del contenido de red;

que determina si el creador del contenido de red coincide con una entrada en una lista de contactos personales incluida en los datos de usuario correspondientes al abonado y, en caso afirmativo, transmitir al menos una etiqueta al dispositivo, identificando la al menos una etiqueta la dirección de origen, en donde al menos una etiqueta permite que el dispositivo inicie una respuesta de voz o texto al contenido de red procesado o que el dispositivo inicie un servicio transaccional en respuesta al contenido de red procesado;

en donde la pluralidad de agentes de recuperación de contenido, el agente de personalización de contenido y el agente de entrega de contenido operan todos dentro de la estructura de agente y se comunican a través de un servicio de mensajería de pizarra digital de la estructura de agente.

14. El producto de programa informático de acuerdo con la reivindicación 13, en donde la estructura de agente está conectada operativamente a una base de datos de usuario que contiene datos de usuario correspondientes a una pluralidad de usuarios, especificando los datos de usuario un nivel de servicio para cada usuario, y en donde las instrucciones de software proporcionan, además, una clase de agente de servicio que opera dentro de la estructura de agente y que comunica a través del servicio de mensajería de pizarra digital, las operaciones predeterminadas que incluyen además la programación, en base a los niveles de servicio, de: la recuperación de contenido de red por la pluralidad de agentes de recuperación de contenido; el procesamiento del contenido de red para su presentación en el dispositivo por el agente de personalización de contenido; y la entrega del contenido de red procesado por el agente de entrega de contenido, en donde la programación es realizada por la clase de agente de servicio.

15. El producto de programa informático de acuerdo con la reivindicación 14, que comprende además proporcionar un portal de autoadministración conectado operativamente a la base de datos de usuario para su uso por cada usuario:

para especificar la fuente de contenido de red para la recuperación de contenido de red;

para seleccionar una opción de personalización, en donde el procesamiento del contenido de red para su presentación en el dispositivo por parte del agente de personalización de contenido se basa en la opción de personalización; o

para especificar el dispositivo para la entrega del contenido de red procesado.