ES2900746T3 - Sistemas y métodos para distribuir eficazmente mensajes de alerta - Google Patents

Abstract

Método para facilitar la distribución eficaz de alertas electrónicas a clientes mediante proveedores de servicios intermediarios; el método comprende: recibir, por parte de uno o de varios procesadores de un proveedor de información centralizado, un texto que describe un evento de actualidad (202) ; recibir por parte del único o de los varios procesadores, reglas semánticas para procesar texto (204), en donde cada una de las reglas semánticas, si satisfechas, especifican una correspondencia con uno o varios atributos de cliente. aplicar, por parte del único o los varios procesadores, reglas semánticas al texto para determinar a qué atributos de cliente corresponde el texto (206) ; extraer, por parte del único o los varios procesadores a partir de una base de datos electrónica, (i) identificadores para una pluralidad de clientes, (ii) un conjunto de atributos de cliente para cada uno de la pluralidad de clientes, y (iii) para cada uno de la pluralidad de clientes, un identificador que sea respectivo de uno de una multiplicidad de proveedores de servicio (208) generar, por parte del único o los varios procesadores para cada uno de la pluralidad de clientes, una métrica de relevancia respectiva del evento de actualidad, basada en los atributos de cliente del cliente y en los atributos de cliente a los cuales se determinó que corresponde el texto (210); y transmitir, a la multiplicidad de proveedores de servicios por parte de uno o más procesadores, un mensaje electrónico de alerta respectivo que describe el evento de actualidad y una indicación de un conjunto de clientes del proveedor de servicio respectivo cuyas métricas de relevancia superan un determinado umbral, para su distribución por parte del proveedor de servicios a una parte o a todo el conjunto de clientes (214)

Description

DESCRIPCIÓN

Sistemas y métodos para distribuir eficazmente mensajes de alerta

CAMPO DE LA INVENCIÓN

[0001] La siguiente invención se refiere en general a los sistemas y métodos para generar y distribuir mensajes de alerta relacionados con eventos de actualidad y más particularmente para determinar automáticamente cómo se deberán distribuir las alertas a los clientes utilizando el procesamiento de reglas semánticas.

ANTECEDENTES

[0002] La descripción de los antecedentes de este documento pretende en general, presentar el contexto de la invención. El trabajo de los inventores que aquí se citan, con el alcance en que es descrito en esta sección de antecedentes, así como en los aspectos de la descripción, y que de otra forma no podría calificar como parte del estado de la técnica en el momento del depósito de la solicitud, no se admite que esté expresa o implícitamente dentro del estado de la técnica en contra de la presente invención.

[0003] Los proveedores de servicios profesionales tales como contabilidad, medicina, derecho etc. suelen notificar a sus clientes noticias relevantes de industria, de desarrollos prácticos recientes y de cambios en la normativa o la tecnología. Para ello, los proveedores suelen examinar gran cantidad de documentos de fuentes distintas. En ciertos casos incluso los proveedores se suscriben a actualizaciones de editores o a agregadores de noticias. Estas actualizaciones pueden ser sobre un tema específico o un área de interés, por ejemplo, sobre fiscalidad. Aunque suscribirse a tales actualizaciones sea generalmente más eficaz que la revisión de fuentes primarias, las actualizaciones siguen exigiendo a los proveedores de servicios profesionales procesar gran cantidad de información al objeto de identificar a clientes específicos o potenciales interesados en estas actualizaciones. Además, los proveedores adaptan a menudo la presentación de estas actualizaciones para receptores individuales. Más aún, teniendo en cuenta que los proveedores de servicios profesionales pueden desplegar varias herramientas de búsqueda o de procesamiento de texto, este procesamiento es generalmente ineficaz en términos informáticos debido al gran número de nodos en los que ocurre.

[0004] El documento US 2015/074191 A1 divulga una plataforma unificada de notificación al usuario-final que emite alertas de eventos a diferentes tipos de clientes, donde están incluidos los dispositivos móviles y los clientes HTTP. Los usuarios pueden suscribirse a una pluralidad de canales de notificación y seleccionar de entre las distintas opciones de entrega asociadas, mediante un único interfaz de usuario. Los eventos los recibe la plataforma de notificación unificada, la cual hace coincidir los eventos con los datos de suscripción de usuario para identificar los suscriptores y sus respectivas opciones de entrega. Las correspondientes alertas de eventos se generan en función de las opciones especificadas por el usuario o suscriptor. Las múltiples alertas de eventos que corresponden a canales de notificación de datos públicos y privados se procuran a un dispositivo de usuario a través de una única conexión.

SUMARIO

[0005] Este sumario se ofrece para introducir de una forma simplificada una selección de conceptos que más adelante serán descritos en la descripción detallada. Este sumario no pretende identificar características clave o características esenciales del objeto de materia reivindicada, ni pretende que se utilice para limitar el alcance del objeto de la materia reivindicada.

[0006] La invención queda definida por el objeto de materia de las reivindicaciones independientes. Las realizaciones adicionales son el objeto de materia de las reivindicaciones dependientes.

[0007] Generalmente hablando, un sistema de la presente invención distribuye eficazmente alertas electrónicas relacionadas con diversos inventos, desde un proveedor de información centralizado, a clientes mediante proveedores de servicios intermedios. Para ello, el proveedor de información centralizado, de acuerdo a un ejemplo de implementación, recibe conjuntos de datos anonimizados especificando diversos atributos de clientes de los proveedores de servicio, recibe información "bruta" describiendo eventos potencialmente relevantes de varias fuentes, procesa la información utilizando reglas semánticas para identificar de forma automática atributos de la información que corresponden a los atributos de los clientes, y genera métricas de relevancia de la información para los clientes. El proveedor de información centralizado distribuye luego alertas electrónicas descriptivas de la información recibida junto con las métricas de relevancia generadas para que después, los proveedores de servicio puedan distribuir las alertas a sus respectivos clientes de manera coherente, fiable y eficaz. El sistema de esta invención elimina la necesidad de procesar la información en múltiples nodos de la red, y por ello aumenta la eficacia global de la distribución de alertas y más concretamente, disminuye el coste de procesamiento y el uso de memoria en los sistemas informáticos de los proveedores de servicios. Además, el proveedor de información centralizado puede aplicar un conjunto más robusto de reglas semánticas que los proveedores de servicios individuales lo que aumenta la probabilidad de que las alertas relevantes se distribuyan con precisión a los clientes.

[0008] Un ejemplo de realización de estas técnicas es un método para facilitar la distribución eficaz de alertas electrónicas los clientes por medio de proveedores de servicios intermediarios. El método incluye recibir, por uno o varios procesadores de un proveedor de información centralizado, un texto que describe un evento de actualidad. El método incluye además recibir, por los uno o varios procesadores, reglas semánticas para procesar texto, en donde cada una de las reglas semánticas, si satisfechas, especifican una correspondencia con uno o varios atributos de cliente y aplicar, por los uno o varios procesadores, reglas semánticas al texto para determinar a qué atributos de cliente corresponde el texto; todavía más, el método incluye extraer, por los uno o varios procesadores a partir de una base de datos electrónica, (i) identificadores para múltiples clientes, (ii) un conjunto de atributos de cliente para cada uno de los clientes, y (iii) para cada uno de los clientes, un identificador de un respectivo proveedor de servicio respectivo; generar, por el único o los varios procesadores para cada uno delos clientes, una métrica de relevancia respectiva del evento de actualidad basada en los atributos de cliente del cliente, y de los atributos del cliente, los cuales se determinaron que corresponde el texto; y transmitir, al menos a un proveedor de servicio mediante uno o varios procesadores, un mensaje de alerta electrónico descriptivo del evento de actualidad y una indicación de un conjunto de clientes del proveedor de servicios cuyas métricas de relevancia superan un determinado umbral, para su distribución a una parte o a todo el conjunto de clientes.

[0009] En varias implementaciones, el método descrito anteriormente también incluye uno o varios de los pasos o actos siguientes. Transmitir los atributos de cliente a los que se ha determinado corresponde el texto, junto con el mensaje de alerta y la indicación de un conjunto de clientes, a al menos un proveedor de servicios. Proporcionar, al menos a un proveedor de servicios, una interfaz de usuario de proveedor que incluye al menos uno de un primer control para transmitir un correo electrónico masivo basado en el mensaje de alerta a algunos o todos los clientes, y un segundo control para crear tareas internas relacionadas con el mensaje de alerta para un conjunto de clientes y vincular el conjunto de clientes con el mensaje de alerta para su posterior seguimiento. Proporcionar a un operador del proveedor de información centralizado a través de una estación de trabajo, una interfaz de usuario de proveedor que incluye un control para modificar las reglas semánticas a aplicar al evento de actualidad. Aplicar las reglas semánticas mediante el procesamiento de lenguaje natural (PLN) que incluye identificar conceptos semánticos (por ejemplo, "organización", “valor monetario" o "fecha") y varios nombres de entidades e, o ciertas combinaciones de conceptos semánticos dentro de un ámbito determinado, tal que una frase o párrafo, para activar las acciones convenientes. Aplicar un enfoque de búsqueda de palabra en lugar del PLN incluye analizar la sintaxis del texto para detectar la presencia de uno o varios patrones de palabras, en donde cada patrón de palabra incluye una o varias palabras clave con una disposición relativa especifica. Generar, utilizando los atributos de cliente a los que se ha determinado corresponde el texto, un perfil de un cliente potencial para la distribución del evento de actualidad, y transmitir el perfil del cliente potencial al menos a un proveedor de servicios. Poblar automáticamente la base de datos electrónica con información referente a clientes, utilizando un conjunto de documentos electrónicos, que incluye analizar la sintaxis del conjunto de documentos electrónicos usando segundas reglas semánticas.

[0010] Otro ejemplo de realización de estas técnicas es un método para distribuir alertas electrónicas de manera eficaz. El método incluye proporcionar, desde un sistema informático asociado a un proveedor de servicios a un proveedor de información centralizado, a través de una red de comunicación, datos anonimizados que incluyen los atributos de cliente, respectivos de cada uno de los múltiples clientes, donde cada uno de los atributos se selecciona de un conjunto predefinido. Los datos anonimizados de acuerdo con varias implementaciones se transforman en una representación semántica que permite al proveedor de información generar alertas de manera más eficaz. El método incluye además recibir, desde el proveedor de información centralizada, una alerta sobre un evento de actualidad, donde la alerta incluye (i) un componente textual que describe el evento de actualidad y (ii) una indicación de clientes, seleccionada de entre los múltiples clientes, para los que se determinó el evento de actualidad tenía una métrica de relevancia por encima de un determinado umbral, utilizando los respectivos atributos de cliente. El método también incluye determinar, en el sistema informático, las identidades de los clientes identificados en la alerta recibida; proporcionar un listado de los clientes identificados mediante una interfaz de usuario, incluyendo proporcionar un control para seleccionar o deseleccionar clientes individuales para la distribución de la alerta, y distribuir la alerta a través de la red de comunicación a uno o varios clientes seleccionados mediante la interfaz de usuario.

[0011] Otro ejemplo de realizaciones de las técnicas de esta invención son sistemas informáticos que incluyen hardware de procesamiento y una memoria no transitoria legible por ordenador. La memoria almacena instrucciones que, al ser ejecutadas por el hardware de procesamiento, ejecuta cualquiera de los métodos antes mencionados.

[0012] Las características y ventajas descritas en este sumario y en la siguiente descripción no son todo-incluido. Muchas de las características y ventajas adicionales serán evidentes para un técnico ordinario en la materia, a la vista de los dibujos, la especificación y las reivindicaciones indicadas.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

[0013] Las Figuras descritas a continuación muestran varios aspectos del sistema y varios métodos que se divulgan en este documento. Debe entenderse que cada Figura representa una realización de un aspecto particular del sistema y métodos divulgados, pretendiendo que cada una de las Figuras sea acorde con una posible realización de estos. Además, siempre que sea posible, la siguiente descripción hace referencia a números que están incluidos en las siguientes Figuras, y las características que se muestran en varias Figuras están designadas con números de referencia coherentes.

[0014] Las disposiciones mostradas en los dibujos están comentadas en este documento, no obstante, debe entenderse que las presentes realizaciones no se limitan específicamente a las disposiciones e instrumentos mostrados, en donde:

La Figura 1 es un diagrama de bloques de un sistema en el cual se pueden implementar técnicas de distribución de alertas a clientes

La Figura 2 es un diagrama de bloques de ejemplo de detección de evento y de motores para perfilar clientes, que pueden implementarse en el sistema de la Figura 1;

La Figura 3 es un diagrama conceptual de un ejemplo del flujo de información entre los diferentes nodos que operan en el sistema de la Figura 1;

La Figura 4 es un diagrama de flujo de un método de ejemplo para procesar eventos y determinar a qué clientes es probable se envíe la alerta correspondiente, el cual puede implementarse en el sistema servidor ilustrado en el sistema de la Figura 1;

La Figura 5 es un diagrama de flujo de un método de ejemplo para procesar eventos y generar un perfil de un hipotético cliente que es probable que esté interesado en la alerta, el cual también puede implementarse en el sistema servidor ilustrado en el sistema de la Figura 1;

La Figura 6 es un diagrama de flujo de un método de ejemplo para recibir input del operador y modificar el dato de evento en vista del input del operador recibido, el cual puede implementarse en el sistema servidor que ilustra el sistema de la Figura 1;

La Figura 7 es un diagrama de un ejemplo de pantalla de la interfaz de usuario para presentar el evento a través de una interfaz de operador, el cual puede implementarse en el sistema del proveedor de servicios ilustrado en el sistema de la Figura 1;

La Figura 8 es un diagrama de flujo de un método de ejemplo para modificar o construir una consulta de evento utilizando el input recibido a través de una interfaz de operador, el cual puede implementarse en el sistema servidor ilustrado en el sistema de la Figura 1;

La Figura 9 es un método de ejemplo para recibir alertas desde el proveedor de información centralizado en respuesta a datos anonimizados, el cual puede implementarse en el sistema del proveedor de servicios ilustrado en el sistema de la Figura 1;

La Figura 10 es un ejemplo de widget para revisar las alertas recibidas, el cual puede ser mostrado como parte de una interfaz de proveedor de servicios en el sistema de la Figura 1;

La Figura 11 ilustra un ejemplo de pantalla de la interfaz de usuario para revisar el dato de evento, la cual puede mostrarse como parte de una interfaz del proveedor de servicios en el sistema de la Figura 1; y

La Figura 12 es un ejemplo de widget para revisar el criterio de evento, el cual puede implementarse como parte de la interfaz de proveedor de servicios en el sistema de la Figura 1.

DESCRIPCIÓN DETALLADA

Visión general

[0015] Las técnicas que se comentan a continuación se pueden aplicar a un entorno donde un proveedor de información centralizado, tal que una empresa editorial, por ejemplo, transmite alertas de actualidad a proveedores de servicios que puede ser de contabilidad, atención médica, asesoramiento jurídico, etc., la cual que a su vez distribuye la información a sus clientes, que pueden ser particulares, empresas y otras organizaciones. Estas técnicas reducen la complejidad computacional asociada a la identificación de información relevante y dirigir la información relevante a través de redes de comunicación, mejoran en general la precisión en la entrega de alertas relevantes, proporcionan interfaces de usuario que mejoran la eficacia, por ejemplo, al soportar operaciones simultáneas en múltiples clientes, y proporcionan otras ventajas técnicas.

[0016] Como se comenta a continuación, un sistema servidor del proveedor de información centralizado puede distribuir alertas de actualidad junto con metadatos que especifican de manera probabilística como deben distribuirse después las alertas. En otras palabras, el sistema servidor especifica clientes anonimizados y/o perfiles de clientes que es probable estén interesados en la alerta concreta. El sistema servidor puede recibir información de varias fuentes, tales que agencias de comunicación de noticias, ruedas de prensa, publicaciones de los organismos reguladores, etc., y aplicar reglas semánticas a la información recibida para identificar varios atributos de clientes que es probable estén interesados en recibir la información ( por ejemplo, "sociedad constituida entre el 1/1/2016 y el 31/12/2016", "empresa con 200.000 dólares o menos de ingresos anuales", "empresa de construcción"). En algunos casos, el sistema servidor utiliza luego los datos anonimizados de los proveedores de servicios que describen varios atributos de cliente para identificar a los clientes de cara a una potencial notificación. En otros escenarios, el sistema servidor genera automáticamente un perfil de un cliente que probablemente deba ser notificado, y distribuye el perfil a varios proveedores de servicios junto con una alerta basada en la información recibida, para su posterior distribución a clientes relevantes.

[0017] El sistema servidor puede proporcionar una interfaz de usuario interactiva ("IU de operador”) mediante la cual, los operadores del proveedor de información centralizada pueden revisar automáticamente eventos detectados, añadir o eliminar atributos del evento, afinar automáticamente las consultas creadas o incluso construir nuevas consultas de búsqueda especificando en algunos casos varios criterios por los cuales deberían seleccionarse los clientes para la notificación, etc. Los operadores también pueden utilizar la interfaz de usuario para vincular información adicional a los eventos, crear y editar propuestas de cartas a clientes, y generar otro contenido del evento. Mas en general, los operadores pueden utilizar el operador IU para modificar el contenido, los tiempos y los objetivos de la notificación del evento.

[0018] Además, el sistema servidor puede proporcionar una interfaz de usuario interactiva diferente a los proveedores de servicios ("IU de proveedor de servicios"). Mediante la IU de proveedor de servicios, un proveedor de servicios puede revisar las alertas de actualidad recibidas del proveedor de información centralizada, revisar las coincidencias identificadas entre los clientes del proveedor de servicios y la alerta de actualidad, ajustar las coincidencias identificadas de forma automática para añadir o eliminar clientes, e iniciar la notificación automática a los clientes. La IU de proveedor de servicios puede soportar la distribución masiva de alertas a múltiples clientes, mejorando así la eficacia del sistema proveedor de servicios correspondiente. En algunas implementaciones, realizaciones, una alerta de actualidad incluye un texto sugerido para notificarlo al cliente, y la interfaz de usuario expuesta a los proveedores de servicio incluye controles para revisar y modificar el texto sugerido.

[0019] Un ejemplo de entorno informático donde pueden implementarse estas técnicas se comenta en referencia a la Figura 1, y los ejemplos de motores de procesamiento que operan en este entorno informático se comentan en referencia a la Figura 2, y luego se comenta el flujo de datos en el entorno informático. Los ejemplos de métodos, interfaces de operador que pueden proporcionarse en el proveedor de información centralizada, e interfaces de proveedor de servicios que pueden proporcionarse como sistemas de proveedor de servicios se comentaran después con referencia al resto de Figuras.

Ejemplo de Entorno Informático

[0020] En referencia a la Figura 1, un ejemplo de entorno informático 10 incluye un sistema servidor 12 asociado a un proveedor de información, tal que una empresa editorial. El sistema servidor 12 puede incluir uno o varios servidores acoplados a una red de comunicación 14, mediante el cual el sistema servidor 12 puede acceder a varias fuentes de información, tal que registros públicos 16 y fuentes de noticias 18. Las fuentes 16 y 18 pueden incluir sitios web, servidores de correo, grupos de noticias, etc., mantenidos por organismos reguladores del gobierno que publican anuncios sobre nueva normativa, asociaciones de sectores industriales, agencias de noticias, tribunales, etc. Dependiendo de la implementación, el sistema servidor 12 puede sondear las fuentes 16 y 18 para conseguir nueva información en un horario determinado, tal que cada hora, o el sistema servidor 12 puede suscribirse a notificaciones en tiempo real de las fuentes 16 y 18.

[0021] El entorno informático 10 incluye además sistemas proveedores de servicios 20. Cada uno de los sistemas 20 puede incluir uno o varios servidores que incluyen procesador(es) y memoria no transitoria legible por ordenador o, en algunas implementaciones, una cuenta asociada por ejemplo a un servicio en la nube. Los sistemas 20 pueden ser operados por proveedores de servicios profesionales tal que, de contabilidad, atención médica, etc. Los sistemas proveedores de servicios 20 pueden comunicarse con los servicios de correo electrónico del cliente 22 a través de la red de comunicación 14, en donde los servicios de correo electrónico del cliente 22 los operan varios clientes o suscriptores del servicio a proveedores.

[0022] El sistema servidor 12 puede estar acoplado a bases de datos electrónicas tales como una base de datos de proveedores de servicios y clientes 30 que almacena información relacionada con varios proveedores de servicios y datos anonimizados de clientes, por ejemplo. Un repositorio de eventos 32 puede almacenar datos de eventos que genera el sistema servidor 12, a partir de la información "bruta" recibida desde las fuentes 16 y 18. Una base de datos de reglas semánticas 34 almacena las definiciones de varias reglas para que el sistema 12 las aplique a la información bruta y a los datos anonimizados de clientes y determinar la relevancia de la información en varios clientes. Cada una de las bases de datos 30, 32 y 34 puede implementarse como una base de datos separada o como parte de una única base de datos, las cuales pueden implementarse utilizando cualquier técnica adecuada (por ejemplo, utilizar un conjunto de tablas interconectadas por índices para definir una base de datos).

[0023] Un ejemplo de registro de datos 40 almacenado en la base de datos del proveedor de servicios 30 describe atributos de un determinado cliente. El registro de datos 40 incluye un identificador de cliente anonimizado junto con un identificador del proveedor de servicios al cual está asociado el cliente. Aunque el identificador anonimizado del cliente no revela la identidad del cliente al sistema servidor 12, el proveedor de servicios al que se hace referencia en el registro de datos 40 puede utilizar el identificador de cliente anonimizado para identificar al cliente. El registro de datos 40 también incluye atributos de ejemplo tales como el nivel de ingresos de cliente, una bandera que indica si el cliente tiene más de 50 empleados, un campo que identifica el tipo de negocio al que se dedica el cliente.

[0024] Un ejemplo de registro de datos 42 almacenado en la base de datos 32 describe un evento procesado por el sistema servidor 12. El registro de datos 42 incluye campos para indicar la fecha asociada con el evento (por ejemplo, la fecha en que un determinado cambio legislativo entrará en vigor y/o la fecha en que se recibió la información sobre el próximo cambio), el tipo de evento, la fuente de información referente al evento, el texto que se distribuirá a los proveedores de servicios con relación al evento, los atributos del evento que el sistema servidor 12 determina en función de la información de origen, etc.

[0025] Continuando con la referencia a la Figura 1, el sistema de servidor 12 incluye uno o varios procesadores 50 y una memoria no transitoria 52 legible por uno o varios procesadores 50. La memoria 52 puede almacenar instrucciones que implementan un motor de perfilado de cliente 62, un motor de detección de evento 64, y un generador de interfaces 66. Cada uno de los sistemas proveedores de servicios 20 también puede incluir uno o varios procesadores y una memoria no transitoria que almacena instrucciones para implementar un anonimizador 60. La memoria no transitoria de los sistemas proveedores de servicios 20 también puede almacenar navegadores web u otras aplicaciones que permite a los proveedores de servicios acceder a diversas funciones del sistema servidor 12. Los sistemas proveedores de servicios 20 pueden obtener las instrucciones que implementen el anonimizador 60 invocando una función adecuada, por ejemplo, la interfaz de programación de aplicaciones (IPA) expuesta por el sistema servidor 12.

[0026] En funcionamiento, los sistemas proveedores de servicio 20 invocan al anonimizador 60 para eliminar los identificadores de cliente que existen en los datos de cliente, y sustituir identificadores de cliente por identificadores temporales tales como cadenas alfanuméricas que aparecen de manera aleatoria, generar una representación semántica de los datos anonimizados y proporcionar la representación semántica de los datos anonimizados sistema servidor 12. El sistema servidor 12 recibe la nueva información desde las fuentes 16 y 18 e identifica un evento nuevo. Los motores 62 y 64 determinan a qué clientes anonimizados corresponde el evento nuevo, y el sistema servidor 12 genera mensajes de alerta para algunos o todos los sistemas proveedores de servidores 20 relacionados con el evento. El generador de interfaz 66 proporciona una IU de operador 70 con la cual un operador del sistema servidor 12 puede ajustar los criterios del evento para seleccionar o deseleccionar varios atributos del evento, formular e iniciar consultas, etc. El generador de interfaz 66 también puede proporcionar una web basada en IPA para que los sistemas de los proveedores de servicios 20 puedan interactuar con el sistema servidor 12. Cuando se invoca, IPA puede generar pantallas IU de proveedor de servicios 72. De este modo, los proveedores de servicios pueden, por ejemplo, revisar las alertas recibidas y distribuir de manera automática las alertas a los clientes.

Ejemplo de Componentes para el Procesamiento de Eventos v Datos de Clientes

[0027] En referencia ahora a la Figura 2, un ejemplo de entorno de procesamiento 100 puede, por ejemplo, implementarse en el sistema servidor 12. En general, los componentes del entorno de procesamiento 100 puede implementarse en un único servidor o en múltiples servidores, a ser posible, en una disposición remota entre ellos.

[0028] El entorno de procesamiento 100 incluye un motor de detección de eventos 102 en comunicación con un motor de perfilado del cliente 104. El motor de detección de eventos 102 incluye un procesador de reglas semánticas 108 y un procesador de lenguaje natural 110. El motor de detección de eventos 102 puede recibir input y emitir output a la IU de operador 106 (el cual puede ser similar a la IU 70 de operador comentado en la Figura 1).

El motor de detección de eventos 102 recibe datos de varias fuentes de datos 1, 2, ... N. Volviendo a la Figura 1, las fuentes de datos 1, 2, ... N, pueden incluir a registros públicos 16 y fuentes de noticias 18. Estos datos pueden incluir texto y, en algunas implementaciones, otros medios tales como imágenes, audio, vídeo, etc. En algunos casos, múltiples fuentes de datos 1,2, ... N pueden proporcionar información que el motor de detección de eventos 102 consolida como un solo evento (por ejemplo, múltiples agencias de noticias pueden informar sobre el mismo desarrollo).

[0029] El motor de detección de eventos 102 también recibe reglas semánticas y conceptos de dominio especifico (por ejemplo, el año fiscal en el dominio de los documentos fiscales, el peso en el dominio de la historia clínica), que el procesador de reglas semánticas 108 utiliza para determinar si el texto que se recibe de las fuentes de datos incluye ciertos atributos que activan la notificación de eventos. De forma más general, el procesador de lenguaje natural 110 puede proporcionar datos semánticos al procesador de reglas semánticas 108, el cual luego puede ejecutar reglas para determinar si la idea expresada por los datos semánticos y las características de afinamiento representan un cambio impactante que debería activar una alerta. Como parte de su output, el procesador de lenguaje natural 110 puede especificar fechas, cantidades de dinero, localizaciones, etc. Las reglas semánticas pueden almacenarse en una base de datos como la base de datos 34 ilustrada en la Figura 1. Las reglas semánticas pueden ser formateadas de cualquier manera adecuada para especificar, por ejemplo, que un determinado concepto de dominio semántico que aparece en el documento debe provocar que el motor de detección de eventos 102 asigne un determinado atributo (por ejemplo, "agrícola regulación") afinando las características al evento correspondiente. Así, una regla semántica puede especificar que ciertos datos semánticos o combinaciones particulares o disposiciones semánticas de datos de un texto hagan muy probable que el texto sea relevante para las empresas con ingresos superiores a 500.000 dólares al año, aunque el texto no contenga la cifra de 500.000 dólares.

[0030] Como ejemplo más específico, una agencia federal responsable de regular la producción agrícola puede publicar un boletín en un sitio web especialmente designado para ello, y el motor de detección de eventos 102 puede asignar ciertos atributos al evento basándose en la fuente de la información. De acuerdo con reglas semánticas adicionales, el motor de detección de eventos 102 puede asignar atributos más específicos al evento, como el tipo de actividad agrícola, si el nuevo desarrollo realiza importaciones o exportaciones, si el nuevo desarrollo concierne a agricultores, proveedores, distribuidores, etc. Además, según la aplicación o escenario, las reglas semánticas pueden especificar si el motor de detección de eventos 102 debe identificar específicamente cambios en la normativa o prácticas existentes, identificar sólo los cambios importantes en la normativa o práctica ya existente, o activar la notificación cualquiera que sea la normativa o la práctica.

[0031] Utilizando la IU 106 de operador, un operador puede añadir, eliminar o modificar la semántica y controlar la aplicación de determinadas reglas semánticas en diversas fuentes de datos. El operador en algunos casos puede utilizar la IU de operador 106 para anular la determinación automática de atributos, atributos remotos, o eliminar manualmente los atributos. Además, la IU 106 de operador puede dejar a los operadores modificar o construir consultas utilizando atributos.

[0032] En general, el uso de PLN con reglas semánticas permite al motor de detección de eventos 102 detectar automáticamente las ideas que se expresan de formas distintas cuando el texto no se ciñe reglas rígidas que requieren de palabras clave específicas. Por ejemplo, el procesador de lenguaje natural 110 puede reconocer el concepto "cuidador de niños", y expresiones equivalentes cuando el código regulado correspondiente utilizado en los documentos estándar es cuidado de niños _trabajador. Además, el procesador de lenguaje natural 110 puede identificar el concepto "cuidador de niños" junto con nombres de jurisdicciones (por ejemplo, el estado de Nueva York), fechas y otros conceptos como "formación" y "cumplimiento", por ejemplo. La disposición de estos conceptos semánticos puede corresponder a un determinado identificador de una regla que especifica cómo debe evaluarse la expresión resultante.

[0033] El motor de detección de eventos 102 genera una lista de atributos para un evento y proporciona estos atributos al motor de perfil de cliente 104. Como se ilustra en la Figura 2, el motor de perfil 104 puede incluir un generador de métricas de relevancia 120, un perfilador automático de clientes 122, y una IPA 124 para extraer la información de los clientes que encajan. El motor de perfiles de clientes 104 puede incluir en otras implementaciones componentes de IU adicionales o, por el contrario, omitir algunos de los componentes ilustrados en la Figura 2. El motor del perfil del cliente 104 recibe atributos de cliente, datos de proveedor de servicios como inputs, y comandos de la IU 106 de operador como inputs. Los outputs del motor de perfil de cliente 104 IU pueden incluir detalles de alerta, indicadores de clientes objetivo, y una plantilla de notificación para notificar a los clientes.

[0034] El perfilador automático de clientes 122 puede operar sobre formularios, documentos y otros artefactos específicos del dominio que se transforman en un modelo semántico específico del dominio. Cada artefacto puede definirse como un perfil compuesto por elementos vinculados a los atributos del cliente. En el ejemplo, el perfilador automático de clientes 122 procesa las declaraciones de la renta para determinar numerosos atributos de un cliente. Las declaraciones de la renta pueden ajustarse a un formato electrónico estándar en el cual los registros de datos se pueblan de acuerdo con ciertas reglas documentadas. De manera similar, existen hoy en día múltiples formatos bien documentados, como HL7, para las historias clínicas, y el perfilador automático de clientes 122 puede generar un perfil de cliente basado en conjuntos de datos anonimizados que se reciben de los hospitales. El sistema 100 también puede crear modelos semánticos y transformar los textos de documentos de la política de Ley de Portabilidad y Responsabilidad del Seguro Médico (en ingles HIPAA), listas de comprobación del cumplimiento, etc. De forma similar a la detección de eventos 102, el sistema automático de perfilador de clientes 122 puede aplicar reglas semánticas y/o procesos de lenguaje natural para extraer atributos de cliente. Una vez recuperados, los atributos de cliente pueden almacenarse por ejemplo en la base de datos 30 ilustrada en la Figura 1. El perfilador automático de clientes 122 puede operar en un lote para procesar los datos del cliente de acuerdo con un programa determinado y por ejemplo, almacenar los atributos del cliente para uso posterior, o el perfilador automático de clientes 122 puede operar sustancialmente en tiempo real para extraer los atributos del cliente cuando un evento de actualidad se encuentra disponible.

[0035] El generador de métricas de relevancia 120 puede recibir atributos del evento desde el motor de detección 102 y comparar los atributos del evento con los atributos del cliente generados por el perfilador automático de clientes 122. Por ejemplo, si uno de los atributos de un evento es "ingresos menores de 100.000 dólares al año", y si el perfil de un determinado cliente también incluye este atributo, el generador de métricas de relevancia 120 puede aumentar el contador de atributos coincidentes. En algunas implementaciones, el generador de métricas de relevancia 120 asigna ponderaciones a los atributos. El generador de métricas de relevancia 120 puede asignar las ponderaciones de acuerdo con la especificidad del atributo, por ejemplo. Así, un atributo que comparten muchos clientes (por ejemplo, el estado de constitución de la compañía= "Delaware"') puede tener un peso menor que un atributo que relativamente pocos clientes comparten (por ejemplo, tipo de negocio = "estudio de danza").

[0036] Algunas de las reglas semánticas que se aplican en el motor de detección de eventos 102 y/o en el motor de creación de perfiles 104 pueden corresponder a criterios de eventos definidos por los operadores y/o que han sido almacenados en una base de datos. Por ejemplo, un determinado criterio de evento puede ser que, la nueva información se refiera a empresas con pérdidas de producción primaria declaradas en el último año fiscal superiores a 50.000 dólares. La regla correspondiente especifica qué conceptos semánticos, y en qué disposición relativa, satisfacen este criterio. Además, un criterio de evento puede ser parametrizado por un número para permitir coincidencias aproximadas y permitir escuchas de golpes. Para continuar con el ejemplo de arriba, 50.000 dólares puede ser un parámetro del criterio "una empresa con pérdidas de producción primaria declaradas en el último año fiscal superiores a X". Aplicando la correspondiente regla semántica, el motor de detección de eventos 102 puede detectar una referencia a las pérdidas de producción primaria declaradas en el último año fiscal superiores a 40.000 dólares. El motor de detección de eventos 102 puede entonces determinar lo cerca que el valor 40.000 dólares está del parámetro 50.000 dólares, y generar una indicación de coincidencia aproximada. Alternativamente, el motor de detección de eventos 102 puede detectar una coincidencia entre el atributo del evento y el atributo del cliente, aunque asigna una ponderación a la coincidencia en proporción a la cantidad de error que define la diferencia entre 40.000 y 50.000 dólares.

[0037] Basándose en el solapamiento entre los atributos del evento y los atributos del cliente, el generador de métricas de relevancia 120 puede determinar si el evento podría ser de interés para el cliente. En algunas implementaciones, el generador de métricas de relevancia 120 puede comparar el número de atributos coincidentes con el número total de atributos del cliente y/o el número total de atributos del evento. Por ejemplo, según una realización, para que el generador de métricas de relevancia 120 determine que el evento puede ser de interés para el cliente, la proporción de atributos coincidentes N con el número total de atributos disponibles para el cliente M deberá superar un número de umbral determinado. En algunas realizaciones, el número de umbral T se establece individualmente para cada evento.

[0038] Siguiendo con referencia a la Figura 2, los proveedores de servicios pueden invocar la IPA 124 de identificación de clientes para generar notificaciones por correo electrónico a clientes individuales o múltiples, de acuerdo con los comandos recibidos de la IU 106 de operador. Por ejemplo, un operador puede editar el texto de una alerta, y la IPA 124 puede además generar una plantilla de notificación que incluye el texto y los atributos de los clientes a los que puede distribuirse el texto.

Ejemplo de Flujo de Datos en un Sistema para Distribuir Mensajes de Alerta

[0039] Para mayor claridad, la Figura 3 ilustra de forma esquemática el flujo de datos en el entorno 10 o en un entorno informático similar. Una topología 150 incluye un proveedor de información 152 que se comunica con los proveedores de servicios 154A, 154B, etc., y cada uno se comunica a su vez con los respectivos sistemas de cliente 160A-C, 160D-160F, etc. Estas entidades pueden ser similares respecto a las que operan el sistema de servicios 12, el proveedor de sistemas de servicios 20 y los servicios de correo electrónico de clientes 22, (véase la Figura 1).

[0040] Como se ilustra en la Figura 1, la representación semántica de los datos anonimizados del cliente viaja por ejemplo "aguas arriba" en la topología 150 desde los proveedores de servicios 154A y 154B. Un mensaje de alerta que incluye información sobre el evento y metadatos que especifican a clientes anonimizados, perfiles de cliente, atributos coincidentes, etc. viaja "aguas abajo" desde el proveedor de información 152 hasta los proveedores de servicios 154A y 154B, y la información de eventos viaja a algunos de los sistemas de clientes 160A-F.

[0041] Se observa que esta disposición permite de manera ventajosa que el procesamiento semántico de eventos ocurra en un solo nodo, el proveedor de información 152, reduciendo así carga computacional en los otros nodos. En otras palabras, esta disposición elimina la necesidad de realizar operaciones similares, a menudo sobre los mismos datos, en los proveedores de servicios 154A y 154B para determinar los atributos de evento.

[0042] Además, la disposición de la Figura 3 define un esquema de enrutamiento probabilístico en el cual se transmite un mensaje de alerta a un nodo intermedio (por ejemplo, desde el proveedor de servicios 154A 154A) junto con una lista de probables destinatarios del mensaje de alerta, o puntos finales. El nodo intermedio 154A recibe así información sobre la recomendación subsiguiente de enrutamiento del mensaje de alerta, pero el nodo intermedio 154A no siempre reenvía el mensaje de alerta a cada punto final identificado por el proveedor de información 152. Aún más, aunque el proveedor de información 152 pueda identificar los atributos del destinatario final del mensaje de alerta, el proveedor de información 152 (al menos en algunas realizaciones) no es consciente de las identidades de estos destinatarios finales.

Ejemplos de Métodos de Operador e Interfaces de Usuario

[0043] En referencia ahora a la Figura 4, un método de ejemplo 200 para procesar eventos y determinar a qué clientes es probable el envío de la alerta correspondiente puede aplicarse, por ejemplo, en el sistema servidor 12 de la Figura 1, o en otro sistema adecuado. El método 200 puede implementarse como un conjunto de instrucciones almacenadas en un soporte de memoria no transitoria- legible por ordenador y ejecutable por uno o varios procesadores, por ejemplo.

[0044] El método 200 comienza en el bloque 202, donde se recibe el texto que describe un posible evento de actualidad. Como se ha comentado anteriormente, el texto puede provenir de cualquier fuente adecuada (por ejemplo, de las fuentes 16 o 18 de la Figura 1) y, en algunos casos, se pueden recibir múltiples textos de diferentes fuentes para el mismo evento.

[0045] En los bloques 204 y 206, se obtienen las reglas semánticas de tratamiento del texto y que se aplican respectivamente al texto. Cada regla semántica puede requerir que uno o varios conceptos semánticos estén presentes en el texto en una disposición relativa determinada, y que se especifique un atributo a asignar al evento si se cumple la regla semántica. Las reglas semánticas pueden definirse para un dominio o una industria concreta, tal que "construcción" o "servicios de hostelería", de modo que el mismo concepto semántico coincidente genera diferentes atributos para diferentes industrias. Si se desea, el sistema donde que se implementa el método 200 puede usar tanto reglas semánticas como procesamiento de lenguaje natural para extraer atributos de eventos.

[0046] En el bloque 208 se recuperen datos de cliente que especifican los atributos de cliente. En algunas realizaciones los datos de cliente están anonimizados. Un módulo como el perfilador automático de clientes 122 de la Figura 2 puede procesar el conjunto de datos de cliente estando desconectado (por lotes) en un momento anterior y poblar una base de datos (por ejemplo, la base de datos 30 ilustrada en la Figura 1). Mas en general, en varias realizaciones, el bloque 208 puede ejecutarse antes que los bloques 202 y 204, después de los bloques 202 y 204, o en paralelo a los bloques 202 y 204.

[0047] Una vez se dispone de los atributos de cliente y de los atributos de evento, se generan en el bloque 210 las métricas de relevancia del evento de actualidad para varios clientes. Como se comentó antes, cada métrica puede reflejar el número de atributos de cliente que coinciden con los atributos de evento, y algunos de los atributos pueden tener una mayor ponderación.

[0048] En el bloque 212 se identifica un conjunto de clientes con métricas que superan un determinado valor de umbral. El valor de umbral puede definirse en términos absolutos (por ejemplo, "5 o más atributos coincidentes"), en términos relativos (por ejemplo, "el 60% o más de los atributos del evento coinciden con los atributos del cliente), o de cualquier otra forma adecuada.

[0049] En el bloque 214, se transmite un mensaje de alerta que incluye una descripción del evento de actualidad, así como indicaciones relativas a la propuesta de distribución del mensaje de alerta a uno o varios proveedores de servicios. En algunos casos puede generarse automáticamente la descripción del evento de actualidad en base al texto recibido en el bloque 202. En otros casos, un operador puede editar manualmente la descripción a través de la IU de operador (por ejemplo, la IU 106 de operador comentada con referencia a la Figura 2). Las indicaciones referentes a la distribución de la propuesta de alerta pueden incluir referencias anonimizadas de clientes, que los proveedores de servicios correspondientes pueden utilizar para determinar la identidad del cliente.

[0050] Sin embargo, en algunos casos, no se pueden identificar a clientes específicos para distribuir alertas debido a que no se dispone de los datos del cliente, por ejemplo, o porque ninguno de los clientes del conjunto de datos disponible tiene un número suficiente de atributos de cliente que coinciden con los atributos de evento para un determinado evento de actualidad. Refiriéndose a la Figura 5, un método 250 es generalmente similar al método 200, excepto en que lo que se transmite a uno o varios proveedores de servicios es un perfil de cliente en lugar de identificadores de clientes.

[0051] En particular, los bloques 252-256 son similares a los bloques 202-206 como se ha comentado anteriormente. En el bloque 258, se selecciona un subconjunto de los atributos de evento identificados en vista de las ponderaciones de los atributos respectivos, y se genera un perfil de cliente basado en los atributos de evento seleccionados en el bloque 260. En una implementación del método 250 las ponderaciones de los atributos son las mismas para todos los atributos. En algunas realizaciones, el perfil de cliente incluye todos los atributos de evento identificados.

[0052] En el bloque 262, se transmite a uno o varios proveedores de servicios un mensaje de alerta con una descripción del evento junto al perfil de cliente generado. Los proveedores de servicios pueden por ejemplo utilizar entonces el cliente recibido para identificar automáticamente los clientes distribuir alertas utilizando una base de datos no expuesta en el proveedor de información centralizado.

[0053] A continuación, la Figura 6 representa un diagrama de flujo de un método de ejemplo 300 que recibe input de operador y la modificación de los datos del evento en vista del input de operador recibido, que el sistema servidor 12 de la Figura 1 puede implementar, por ejemplo, mediante instrucciones de software. Volviendo a la Figura 2, las inputs y outputs del operador pueden recibirse a través de la IU 106 de operador.

[0054] En los bloques 302 y 304, se proporcionan listados de documentos fuente detectados recientemente y de eventos detectados recientemente a través de la interfaz del operador. Hay que tener en cuenta que no todos los documentos fuente de documentos incluyen necesariamente conceptos semánticos que el motor de detección de eventos 102, por ejemplo (véase la Figura 2) pueda identificar que coinciden con una o varias reglas semánticas o reconocer utilizando el procesamiento de lenguaje natural. Consecuentemente, en una implementación, la interfaz de usuario del operador enumera ambos, los documentos fuente que fueron reconocidos automáticamente como base de un evento de actualidad, y los documentos fuente que se usaron para generar el evento de actualidad. El operador puede revisar ambos tipos de documentos y, si lo desea, anular los resultados del tratamiento automático.

[0055] El operador puede modificar los criterios de evento en el bloque 306. Por ejemplo, el operador puede añadir, eliminar o editar los criterios del evento para modificar los atributos asignados al mismo. Como respuesta, el sistema puede modificar los datos del evento de acuerdo con el input de operador en el bloque 308.

[0056] La Figura 7 ilustra un ejemplo de pantalla de interfaz de usuario 400, que la IU 70 de operador o 106 (véanse las Figuras 1 y 2) puede proporcionar a un operador de información centralizada para revisar un evento en particular. En un escenario de ejemplo, la IU de operador presenta un listado de búsqueda de eventos actuales y pasados al operador, y genera la pantalla 400 como respuesta al operador que selecciona uno de estos eventos.

[0057] La pantalla 400 puede indicar el estado del evento (por ejemplo, Recuperado, Pendiente, Eliminado) en el proveedor de información centralizado. En este escenario de ejemplo, el evento ya ha sido recuperado hacia los proveedores de servicios. La pantalla 400 también indica el tipo de evento (en este caso, Cambio Legislativo), el título del evento, las fechas de creación y de última modificación, la fuente (s) del evento, el nombre del colaborador y una breve descripción. De manera más general, la pantalla 400 puede mostrar cualquier número deseado de campos informativos para cada evento.

[0058] Como se ilustra en la Figura 7, la pantalla de ejemplo 400 incluye además pestañas bajo las cuales se organizan los respectivos grupos de funciones y campos informativos. En la pestaña Detalles, activada en la vista representada en la Figura 7, el operador puede acceder a documentos fuente tanto en formato original como enriquecido o anotado. Por ejemplo, el documento fuente puede ser el texto original de una decisión judicial importante, y el formato anotado puede mostrar los conceptos semánticos que detectó el motor de detección de eventos 102 o un componente detectado similar, varias fechas y números identificados en el documento fuente, etc. Además, la pestaña Detalles puede incluir una lista interactiva de términos mencionados en el evento y una lista interactiva de conceptos más amplios detectados en el evento. El operador puede eliminar y añadir selectivamente estos términos y conceptos.

[0059] La pestaña de Eventos Relacionados puede incluir enlaces a otros eventos para permitir al operador revisar y modificar el listado de eventos que se determinaron estaban relacionados. Por ejemplo, el motor de detección de eventos 102 puede determinar que dos eventos recientes comparten múltiples atributos de evento y automáticamente cruzar las referencias de estos eventos para el operador. La pestaña Criterios de Eventos puede incluir un listado interactivo de criterios de eventos que el operador puede revisar y ajustar.

[0060] Por ejemplo, para permitir al operador modificar los criterios de eventos, el sistema servidor 12 de la Figura 1 puede implementar un método de ejemplo tal que 450. El método 450 comienza en el bloque 452, donde por ejemplo, se recibe una solicitud de modificación de los criterios de los eventos en respuesta a la activación que ha hecho el operador de los Criterios de Evento. En el bloque 454 se presenta una interfaz interactiva para modificar o construir una consulta. La interfaz de consulta interactiva puede incluir controles para especificar eventos y las relaciones entre los criterios. Por ejemplo, el operador puede especificar que él o ella desean buscar declaraciones de impuestos individuales de clientes que indican uno de los siguientes: el menor ingreso de producción primario neto es 2,1, la cuota de ingresos netos de fideicomisos es 10%, las pérdidas declaradas de producción primaria de este año fiscal son 50.000 dólares, etc. En una realización, estos criterios están predefinidos y almacenados en la base de datos, y el operador sólo suministra los parámetros numéricos (2,1, 10%, 50.000 dólares, etc.). Las relaciones entre los criterios que el operador selecciona pueden incluir, por ejemplo, "debe tener al menos uno de", "debe tener todos de" o "debe tener al menos uno de ellos".

[0061] En el bloque 456, se reciben las selecciones de atributos y se ejecuta la consulta según los atributos seleccionados para obtener un conjunto de clientes que coinciden en el bloque 458. El conjunto obtenido puede utilizarse en la distribución de alertas del bloque 460.

Ejemplos de Métodos de Proveedor de Servicio e Interfaces de Usuario

[0062] La Figura 9 representa un diagrama de flujo de un método de ejemplo 500 para recibir alertas desde un proveedor de información centralizado en respuesta a datos anonimizados, que puede ser implementado, por ejemplo, en uno de los sistemas de proveedores de servicios 20 de la Figura 1. De forma similar a los otros métodos de esta divulgación, el método 500 puede implementarse como un conjunto de instrucciones almacenadas en un medio legible por ordenador y ejecutables por uno o varios procesadores.

[0063] El método 500 comienza en el bloque 502, donde se proporciona al proveedor de información centralizada una representación semántica de un dato de cliente anonimizado. El dato anonimizado de cliente puede incluir, por ejemplo, declaraciones de la renta en formato estándar electrónico para su análisis por ordenador junto con los datos identificativos de clientes reemplazados por identificadores temporales. En el bloque 504, se recibe una alerta de actualidad del proveedor de información centralizado. La alerta de actualidad puede incluir un componente textual (y, si se desea, otros medios tal como imágenes) junto con metadatos para determinar qué clientes del proveedor de servicios pueden estar interesados en la alerta de actualidad. Los metadatos pueden incluir identificadores temporales de clientes, que son suministrados como parte de los datos de clientes anonimizados. Adicional o alternativamente, los metadatos pueden incluir un perfil de cliente con múltiples atributos de un cliente ficticio potencialmente interesado en la alerta de actualidad.

[0064] En el bloque 506, se proporciona una IU de operador de servicios como parte de una interfaz basada en internet, por ejemplo. A continuación, se reciben los comandos de distribución a través de la IU del operador de servicios en el bloque 508, y la alerta de actualidad se distribuye de acuerdo con las órdenes de distribución recibidas en bloque 510.

[0065] Para mayor claridad, la Figura 10 ilustra un widget de ejemplo 500 en el que la IU de operador de servicios puede proporcionar la revisión de las alertas recibidas. El widget 550 incluye un listado de eventos recibidos desde el proveedor de información centralizado, una indicación de cómo muchos clientes del proveedor de servicios han coincidido con el evento en función de sus atributos, la fecha en que se anunciaron los eventos, etc. El widget 550 de ejemplo permite al proveedor de servicios clasificar los eventos en función del número de clientes coincidentes.

[0066] Así, el proveedor de servicios puede determinar cuántos clientes están potencialmente afectados por la alerta de actualidad utilizando los metadatos recibidos, sin analizar el evento de actualidad localmente. Además, los metadatos permiten que la interfaz de usuario del proveedor de servicios priorice automáticamente la alerta mensajes en función del número de clientes con impacto potencial.

[0067] A continuación, la Figura 11 ilustra un ejemplo de pantalla de interfaz de usuario 600 que puede generar la IU de proveedor de servicio para revisar datos de eventos. Para cada evento, la pantalla 600 puede incluir una descripción del evento, un perfil de cliente, una declaración de impacto del cliente propuesto, de propuesta de impacto de cliente y una propuesta de carta de cliente recibidas desde el proveedor de información centralizada, etc. El proveedor de servicio puede utilizar las funciones accesibles a través de la pantalla 600 para modificar los perfiles de los clientes a los cuales se va a distribuir la alerta de actualidad, el texto que recibirán los clientes, etc.

[0068] Además, como se ilustra en la Figura 12, el proveedor de servicios puede ver los criterios del evento detectados en el proveedor de información centralizado y, si lo desea, anular estos criterios. Un widget de ejemplo tal que 650 puede ser proporcionado como parte de la interfaz de usuario del proveedor de servicios y puede incluir un listado de criterios de eventos individuales e indicaciones de cuántos clientes tienen los criterios de cliente que coinciden. En este escenario de ejemplo, el widget 650 indica que el evento que el proveedor de servicios está revisando en la pantalla 600 es aplicable a empresas con ingresos accesibles de 200.000 dólares o menos, empresas que declararon una compensación por investigación y desarrollo, etc. En algunas implementaciones el proveedor de servicios puede anular tanto algunos como todos los criterios de eventos y generar comentarios para el proveedor de información centralizada. El proveedor de información centralizada, a su vez, puede generar una alerta adecuada hacia un operador si un determinado número o porcentaje de proveedores de servicios no están de acuerdo con un determinado criterio de evento.

Consideraciones Adicionales

[0069] Las siguientes consideraciones adicionales aplican a la exposición anterior. A lo largo de esta especificación, las instancias plurales pueden implementar funciones, componentes, operaciones o estructuras que están descritas como una sola instancia. Aunque las funciones individuales e instrucciones de uno o varios métodos se ilustren y describan como operaciones separadas, una o varias operaciones individuales pueden realizarse simultáneamente, y no se necesita que las operaciones se realicen en el orden ilustrado. Las estructuras y funcionalidades presentadas como componentes separados en configuraciones ejemplares pueden implementarse como una estructura o componente combinado. Del mismo modo, las estructuras y funcionalidades presentadas en un solo componente pueden implementarse en componentes separados. Estas y otras variaciones, modificaciones, adiciones y mejoras entran dentro del ámbito del objeto de la materia.

[0070] Por ejemplo, la red puede incluir, pero no se limita a, cualquier combinación de una LAN, una MAN, una WAN, una móvil, una red alámbrica o inalámbrica, una red privada o una red privada virtual. Además, se entenderá que soporta cualquier número de ordenadores de cliente o dispositivos de pantalla en comunicación con el sistema de datos 104.

[0071] Además, el presente documento describe varias realizaciones que incluyen una lógica o un número de funciones, componentes, módulos, bloques o mecanismos. Las funciones pueden constituir módulos de software (por ejemplo, el código no transitorio almacenado en un soporte tangible legible como medio de almacenamiento ) o módulos de hardware. Un módulo de hardware es una unidad tangible capaz de realizar operaciones determinadas y puede estar configurado o dispuesto de una determinada forma. En las realizaciones de ejemplo, uno o varios sistemas informáticos (por ejemplo, un sistema independiente sistema informático de cliente o de servidor) o uno o varios módulos de hardware de un sistema informático (por ejemplo, un procesador o un grupo de procesadores) pueden configurarse mediante software (por ejemplo, una aplicación o una parte de la aplicación) como un módulo de hardware que funciona para realizar determinadas operaciones como se describe en este documento.

[0072] Por lo tanto, el término "hardware" debe entenderse como una entidad tangible, que puede ser una entidad construida físicamente, configurada permanentemente (por ejemplo, por cableado), o configurado temporalmente (por ejemplo, programado) para operar de una determinada manera o para realizar ciertas operaciones descritas en el presente documento. Se considera que en las realizaciones con módulos de hardware configurados temporalmente (por ejemplo, programados), cada uno de los módulos de hardware no necesitan ser configurados o ejecutados en un momento dado. Por ejemplo, cuando los módulos de hardware comprenden un procesador de propósito general configurado mediante software, el procesador de propósito general puede configurarse como módulos de hardware diferentes respectivos de momentos diferentes. Por lo tanto, el software puede configurar un procesador, por ejemplo, para constituir un módulo de hardware particular en un momento del tiempo y constituir un módulo de hardware en un momento del tiempo diferente.

[0073] Los módulos de hardware y software pueden proporcionar información hacia, y recibir información de otros módulos de hardware y/o software. Por lo tanto, los módulos de hardware descritos pueden considerarse acoplados de manera comunicativa. Cuando se dan simultáneamente varios modelos de hardware o software, las comunicaciones pueden lograrse trasmitiendo señales (por ejemplo, a través de circuitos y buses adecuados) que conectan los módulos de hardware o software. En las realizaciones en las que múltiples módulos de hardware o software se configuran o ejecutan en momentos diferentes, las comunicaciones entre dichos módulos de hardware o software puede lograrse, por ejemplo, almacenando y recuperando la información en las estructuras de memoria a las que tienen acceso los múltiples módulos de hardware o software. Por ejemplo, un módulo de hardware o software puede realizar una operación y almacenar el output de esa operación en un dispositivo de memoria acoplado de manera comunicativa. Un módulo de hardware o software adicional puede entonces, en un momento posterior, acceder al dispositivo de memoria para extraer y procesar el output almacenado. Los módulos de hardware y software también pueden iniciar comunicaciones con dispositivos de input u output, y pueden operar en un recurso (por ejemplo, en una colección de información).

[0074] Las diversas operaciones de las funciones y métodos ejemplares aquí descritos pueden ser realizadas, al menos parcialmente, por uno o varios procesadores que estén configurados temporalmente (por ejemplo, mediante software) o configurados permanentemente para realizar las operaciones correspondientes. Independientemente de que estén configurados temporal o permanentemente, dichos procesadores pueden constituir módulos que operan para llevar a cabo una o varias operaciones o funciones. Los módulos a los que se hace referencia en el presente documento pueden, en algunas realizaciones ejemplares, comprender módulos implementados por procesador.

[0075] Del mismo modo, los métodos o funciones aquí descritos pueden ser al menos parcialmente, implementados por procesador. Por ejemplo, al menos algunas de las funciones de un método pueden ser realizadas por uno o varios procesadores o módulos de hardware implementados por procesador. La ejecución de algunas de las funciones puede distribuirse entre uno o varios procesadores, que residen no sólo en una sola máquina, sino que se despliegan en varias máquinas. En algunas realizaciones ejemplares, el procesador o los procesadores pueden estar ubicados en una sola ubicación (por ejemplo, dentro de un entorno doméstico, un entorno de oficina o como una granja de servidores), mientras que, en otras realizaciones, los procesadores pueden estar distribuidos en lugares distintos.

[0076] El único o los varios procesadores también pueden operar para apoyar la actuación de las operaciones relevantes en un entorno de "informática en la nube" o como "software como un servicio" (SaaS). Por ejemplo al menos, algunas de las funciones las puede realizar un grupo de ordenadores (como ejemplos de máquinas que incluyen procesadores). Estas operaciones son accesibles a través de una red (por ejemplo, de Internet) y a través de una o varias interfaces adecuadas ( por ejemplo, interfaces de programación de aplicaciones (IPA)).

[0077] La actuación de determinadas operaciones puede estar distribuida entre el o los procesadores, que residan no sólo en una sola máquina, sino que se desplieguen en una serie de máquinas. En algunas realizaciones ejemplares, el único o los varios procesadores o módulos implementados de procesador, los módulos pueden estar situados en una única ubicación geográfica (por ejemplo, dentro entorno de un hogar, un entorno de oficina o una granja de servidores). En otras realizaciones ejemplares, el único o los varios procesadores o módulos implementados en el procesador pueden estar distribuidos a lo largo de varias ubicaciones geográficas.

[0078] Algunas partes de esta especificación se presentan en términos de algoritmos o de representaciones de operaciones sobre datos y estructuras de datos almacenados como bits o señales digitales binarias dentro de la memoria de una máquina (por ejemplo, la memoria de un ordenador). Estos algoritmos o representaciones simbólicas son ejemplos de técnicas utilizadas por los expertos en la técnica de procesamiento de datos para transmitir la esencia de su trabajo a otros expertos en la materia. Tal y como se utiliza en el presente documento, una "función" o un "algoritmo" o una "rutina" es una secuencia auto consistente de operaciones o procesamientos similares que conducen a un resultado deseado. En este contexto, las funciones de los algoritmos, las rutinas y las operaciones implican la manipulación física de cantidades físicas. Típicamente, aunque no necesariamente, tales cantidades pueden tomar la forma de señales eléctricas, magnéticas u ópticas capaces de ser almacenadas, accedidas, transferidas, combinadas, comparadas o de otra forma manipuladas por una máquina. A veces es conveniente, principalmente por razones de uso común, referirse a dichas señales utilizando palabras como "datos", "contenido", "bits" "valores", "elementos", "símbolos", "caracteres", "términos", "números" o similares. Sin embargo, estas palabras no son más que etiquetas convenientes y deben asociarse a cantidades físicas adecuadas.

[0079] A menos que se indique específicamente lo contrario, las exposiciones del presente documento que utilizan palabras como "procesar", "computar", "calcular", "determinar", "presentar", "mostrar" o similares pueden referirse a acciones o procesos de una máquina (por ejemplo, un ordenador) que manipula o transforma los datos representados como cantidades físicas (por ejemplo, electrónicas, magnéticas u ópticas) dentro de una o varias memorias (por ejemplo, memoria volátil, memoria no volátil, o una combinación de las mismas), registros u otros componentes de máquina que reciben, almacenan, transmiten o muestran información.

[0080] Tal como se utiliza en el presente documento, cualquier referencia a "algunas realizaciones" o "una realización" o "realización" significa que un elemento, rasgo, estructura o característica particular descrita en relación con la realización, se incluye al menos en una realización. Cuando aparece la frase "en una realización" en varios lugares de la especificación no necesariamente todas se refieren a la misma realización.

[0081] Algunas realizaciones pueden describirse utilizando la expresión "acoplado" y "conectado" junto con sus derivados. Por ejemplo, algunas realizaciones pueden describirse utilizando el término "acoplado" para indicar que dos o más elementos están en contacto físico directo o contacto eléctrico. El término "acoplado", sin embargo, también puede significar que dos o más elementos no estén en contacto directo entre sí, pero sí que siguen cooperando o interactuando entre sí. Las realizaciones no están limitadas en este contexto.

[0082] Tal y como se utiliza en el presente documento, los términos "comprende", " comprendiendo", "incluye", "incluyendo" "tiene", "teniendo" o cualquier otra variante, están destinados a cubrir una inclusión. Por ejemplo, una función, un proceso, un método, un artículo o un aparato que comprende una lista de los elementos no se limita necesariamente a ellos, sino que puede incluir otros elementos que no estén expresamente enumerados o no sean inherentes a dicho proceso, método, artículo o aparato. Además, a menos que se indique expresamente lo contrario, "o" se refiere a un inclusivo o, y no a un exclusivo o. Por ejemplo, una condición A o B se satisface con cualquiera de las siguientes: A es verdadera (o está presente) y B es falsa (o no está presente), A es falsa (o no está presente) y B es verdadero (o está presente), y ambos A y B son verdaderos (o están presentes).

[0083] Además, el uso de "un" o "una" se emplea para describir elementos y componentes de las realizaciones del presente documento. Esto se hace simplemente por conveniencia y para dar un sentido general de la descripción. Esta descripción debe ser leída para incluir uno o al menos uno y el singular incluye también el plural a menos que sea obvio que se quiere decir otra cosa.

[0084] Además, las Figuras describen formas de realización preferidas de un sistema informático 100 con propósitos meramente ilustrativos. Una persona con conocimientos ordinarios en la técnica reconocerá fácilmente a partir de la presente exposición que se pueden emplear de forma alternativa las estructuras y los métodos ilustrados aquí sin apartarse de los principios descritos en el documento.

[0085] Al leer esta invención, aquellos expertos de la técnica apreciarán todavía más diseños estructurales y diseños funcionales alternativos para un sistema y un proceso para distribuir eficazmente mensajes de alerta teniendo en cuenta los principios divulgados en el documento. Por lo tanto, aunque se han ilustrado y descrito formas de realización y las aplicaciones particulares, debe entenderse que las realizaciones divulgadas no se limitan a la construcción y los componentes concretos divulgados aquí. Se podrán realizar modificaciones, cambios y variaciones, que serán evidentes para los expertos en la materia, relativos a la disposición, el funcionamiento y los detalles del método y aparatos aquí divulgados sin apartarse del ámbito de aplicación definido en las reivindicaciones anexas.

Claims (15)

REIVINDICACIONES

1. Método para facilitar la distribución eficaz de alertas electrónicas a clientes mediante proveedores de servicios intermediarios; el método comprende:

recibir, por parte de uno o de varios procesadores de un proveedor de información centralizado, un texto que describe un evento de actualidad (202) ;

recibir por parte del único o de los varios procesadores, reglas semánticas para procesar texto (204), en donde cada una de las reglas semánticas, si satisfechas, especifican una correspondencia con uno o varios atributos de cliente.

aplicar, por parte del único o los varios procesadores, reglas semánticas al texto para determinar a qué atributos de cliente corresponde el texto (206) ;

extraer, por parte del único o los varios procesadores a partir de una base de datos electrónica, (i) identificadores para una pluralidad de clientes, (ii) un conjunto de atributos de cliente para cada uno de la pluralidad de clientes, y (iii) para cada uno de la pluralidad de clientes, un identificador que sea respectivo de uno de una multiplicidad de proveedores de servicio (208)

generar, por parte del único o los varios procesadores para cada uno de la pluralidad de clientes, una métrica de relevancia respectiva del evento de actualidad, basada en los atributos de cliente del cliente y en los atributos de cliente a los cuales se determinó que corresponde el texto (210); y

transmitir, a la multiplicidad de proveedores de servicios por parte de uno o más procesadores, un mensaje electrónico de alerta respectivo que describe el evento de actualidad y una indicación de un conjunto de clientes del proveedor de servicio respectivo cuyas métricas de relevancia superan un determinado umbral, para su distribución por parte del proveedor de servicios a una parte o a todo el conjunto de clientes (214)

2. El método de la reivindicación 1, el cual comprende además la transmisión de los atributos de cliente a los que se ha determinado que corresponde el texto, junto con el mensaje de alerta y la indicación de un conjunto de clientes.

3. El método de la reivindicación 1, el cual comprende además:

proporcionar, a la multiplicidad de proveedores de servicios, una interfaz de usuario de proveedor que incluye al menos uno de:

un primer control para transmitir un correo electrónico masivo basado en el mensaje de alerta a algunos o todos los clientes, y

un segundo control para crear tareas internas relacionadas con el mensaje de alerta para un conjunto de clientes y vincular el conjunto de clientes con el mensaje de alerta para su posterior seguimiento.

4. El método de la reivindicación 1, el método comprende, además:

proporcionar, a un operador en una estación de trabajo, una interfaz de usuario de operador que incluye un control para modificar las reglas semánticas aplicadas al evento de actualidad.

5. El método de la reivindicación 4, el cual además de proporcionar la interfaz de usuario del operador, proporciona un control para modificar o construir una consulta compuesta de numerosos criterios, para identificar a los clientes que cumplen con los numerosos criterios.

6. El método de la reivindicación 1, en donde aplicar las reglas semánticas incluye analizar el texto para detectar la presencia de cierta disposición en uno o varios conceptos semánticos.

7. El método de la reivindicación 1, que comprende, además:

generar, mediante los atributos del cliente a los cuales se determinó que correspondía el texto, un perfil de clientes potenciales para distribuir el evento de actualidad, y

transmitir el perfil del cliente potencial al menos, a un proveedor de servicios.

8. El método de la reivindicación 1, en donde las reglas semánticas son reglas semánticas primeras, el método comprende, además:

poblar automáticamente la base de datos electrónica, por medio de uno o más procesadores, con información referente a la pluralidad de clientes utilizando un conjunto de documentos electrónicos, que incluye analizar el conjunto de documentos electrónicos utilizando segundas reglas semánticas.

9. Un método para distribuir eficazmente alertas electrónicas, el método comprende:

determinar, en el sistema informático, las identidades de los clientes indicados en la alerta; proporcionar un listado de los clientes identificados a través de una interfaz de usuario, incluyendo proporcionar un control para seleccionar o deseleccionar clientes individuales para la distribución de la alerta; y

distribuir la alerta a través de la red de comunicación a uno o varios clientes seleccionados a través de la interfaz de usuario.

10. El método de la reivindicación 9, en donde la recepción del mensaje de alerta incluye recibir luego un conjunto de atributos de eventos que el proveedor de información centralizado determinó para el evento de actualidad.

11. El método de la reivindicación 10, en donde proporcionar el listado de los clientes identificados a través de la interfaz de usuario incluye proporcionar, para cada uno de los clientes, aquellos atributos de cliente que coinciden con los atributos de cliente.

12. El método de la reivindicación 9, que comprende, además:

recibir una pluralidad de mensajes de alerta de una pluralidad de eventos de actualidad respectivos, incluyendo recibir, para cada uno de la pluralidad de mensajes de alerta, una indicación de clientes para los cuales, quedó determinado que el evento de actualidad tenía una métrica de relevancia superior a un determinado umbral; y

enumerar la pluralidad de mensajes de alerta a través de la interfaz de usuario de acuerdo con número de clientes para los cuales, el evento de actualidad se determinó tenía una métrica de relevancia superior a un determinado umbral.

13. El método de la reivindicación 9, comprende además:

recibir una plantilla de texto para distribuirla como parte de la alerta a uno o varios clientes, y proporcionar un control interactivo para editar la plantilla de texto.

14. El método de la reivindicación 9, que comprende además recibir un perfil de un potencial cliente para la distribución del evento de actualidad, el perfil incluye un conjunto de atributos.

15. Un sistema para facilitar la distribución eficaz de alertas electrónicas a clientes mediante proveedores de servicios intermediarios, el sistema comprende:

material hardware de procesamiento; y

una memoria no transitoria legible por ordenador que almacena en ella instrucciones que, al ser ejecutadas por el material hardware de procesamiento, produce que el sistema:

implemente un método según cualquiera de las reivindicaciones 1-8.